И. Соммервилл - Инженерия программного обеспечения (1133538), страница 32
Текст из файла (страница 32)
Спецификация интерфейсов Подавляющсс большинство разрабатываемых программных систем должны взаимодействовать с другими, уже существующими систеиами. Для того чтобы новал система могла работать совместно с другими системами, необходимо специфицировать интор. фейсы этих систсм. Такие спсцификлцни создаются на раннсм этапе разработки систем и включаются (обычно в виде приложсния) в спецификацию системных требований. Различают трн типа специфицируемых интерфейсов.
1. Процедурные интерфейсы, когда существующие подсистемы предлагают набор сервисов, доступных посредством вызываемой интерфейсной процедуры. 2, Струкгуры (интерфейсные форматы) данных, которые пересылаются от одной подсистемы к другой. В этом случае может использоваться Р()1., основанный на языке программирования )ача, который позволяет описать кзассы данных с соотвстствующими полями, формирующими структуру данных.
Однако, я полагаю, для описания этого типа интерфейса наиболее подходят диаграммы "сущность-связь", описанные в главе 7. 3. Специэльныс представления данных, например в виде упорядоченной послсдоэатэльности двоичных разрядов. Язык )ача не поддерживает танис детальные описания данных, поэтому я не рекомендую в подобном случае использовать Р1)(., осно.
ванный на языке )ача. Формальные нотации, приведенные в главе 9, позволяют описать интерфейсы чстко и недвусмысленно. Однако такие спсцификации понятны только специалистам, обладаю. щим определенными знанияии. Формальные нотации редко используются на практике, хотя, с мосй точки зрения, они идеально подходят для создания спецификаций интсрфсйсоэ. Менее формальные спецификации интсрфсйсов, полученные с помощью РШ., являются компромиссом между понятностью и точностью описания интерфейсов. В листинге 5.2 представлен пример описания интерфейса первого типа (из псречнсленных выше). Это описание процедурного интсрфейса сервера печати. Оп управляст очередями на печать, осуществляемую несколькими принтерами.
Пользователи могут проверять очередь, соответствующую любому принтеру, и удалять свои файлы из очсрсдн. Они также могут псрсключать свои файлы с одного принтера на другой. Листинг 5.2. Описание интерфейса сервера печати с помон(ъю Р)И. фпгегбасе Ргфпгяегчег ( // определение абстрактного сервера печати // требуется: интерфейс Ргфпгег, интерфейс Ргфпгбос // предоставляет функции: фпфс1в)фхе (инициалиэация), // Ргзпс (печать), // йдэр1ауРг1пс()цеце (отображение очереди на печать), // сапсе1РгзпгаоЬ (удаление файла иэ очереди), // эифссЬРгфпсег (переключение ме;клу принтерами) чоЫ 1пфсфа11хе ( Рг1псег р ) чоЫ ргфпг ( Ргфпгег р, Ргфпгцос с) ) чоЫ бфэр1ауРг1пг()цеце ( Ргфпсег р ) чоЫ сапсе1РгфпсуоЬ ( Ргфпгег р, Ргфпс))ос д ) чоЫ вмфгсЬРгЫСег ( Ргфпсег р1, Ргфпгег р2, Ргфпгбос с) ) )//Ргйпгяегчег 122 'Часть 11. Требования Спецификация, приведеннэл в листинге 5,2, — абстрактная модель сервера печати без детализации интерфейсных частностей.
Интерфейсные функции можно описать с помо. щью структурированного естественного языка (квк показано во врезке 5.6), посредством Р(51., основанного на языке программированип )ата (см. листинг 5.1), либо с помощью формальных нотаций, которые описаны в главе 9. 5.4. Документирование системных требований Документ, содержащий требования, также называемый спецификацией системных требований, — зто официальное предписание для разработчиков программной системы. Он содержит пользовательские требования и детализированное описание системных требований.
В некоторых случаях пользовательские и системные требования могут не различаться, выступая совместно в виде однородного описания системы. В других случаях пользовательские требования приводятся во введении документаспецификацин. Если общее количество требований велико, детализированные системные требования всосут быть представлены в виде отдельного документа. Системную спецификацию читает множество разных людей, начиная от высшего руководства компании — заказчика системы и заканчивая рядовым разработчиком системы.
1йз рнс. 5З, взятом нз статьи ) 204), показаны категории читателей спецификации. 15сс 5.3, Читппилп сиспжиппи спсуифиппйии 5. Требования к программному обеспечению 123 Хенингер (Неп!пйег. [160]) сформулировал шесть условий, которым должна соответствовать спецификация програмлшой системы. ° Описывать только внешнее поведение системы. ° Указывать олрапичения, накладываемые на процесс реализации системы. ° Предусматривать возможность внесения изменений в спецификацию.
° Служить справочным средством в процессе сопровождения системы. ° Отображать весь жизненный ци«л систеллы. ° Предусматривать реакцшо системы и группы сопровождения на непредвиденные (нештатные) ситуации. Хотя со времени написания этих условий прошло более 20 лет, они не утратили своей актуальности и являются хорошим подспорьем при разработке спецификаций.
Вместе с тем подчас сложно или далкс невозможно описать систему только в терминах внешнего поведения, т.е. только посредством функций, которые она должна выполнять, посколылу в спецификации также должны быть отражены ограничения, накладывасмыс окружением уже существующих систем. Другое условие — охват всего жизненного цикла системы— принимается всеми разработчиками, по редко выполняется на практике.
Многие организации, такие, как Министерство обороллы СШЛ и Институт инженеров по электротехнике и радиоэлектронике 1ЕЕЕ, разработали собственные стандарты док>- мсптирования спецификаций. В монографии [89] описаны некоторые из этих сташшртов, а также проведено их сравнение. Наиболее известный стандарт разработан !ЕЕЕ и называется !ЕЕЕ/Д>члб! 830-1993 [!КЕЕ, 1993]. В кингс [334], содержащей великолепный обзор работ по технологии разработки требований, приведено полное описание этого стандарта. Данный стандарт предполагает след> ющую структуру спецификации.
1. Введение 1.1. Цели документа 1.2. Назначение программного продукта 1.3. Опредслснил, акронимы и аббревиатуры 1.4. Список литературы и других источников 1.5. Обзор спецификации 2. Общее описание 2.1. Описание программного продукта 2.2. Функции программного продукга 2.3. Пользовательские характеристики 2.4. Общие ограничения 2.5. Обоснования, предположения и допущения 3.
Спецификация требований охватывает функциональные. пефупкциопальпыс и интерфейсные трсбованпл. Это пзнболес значимал часть документа, но вследствие крайне пшрокого диапазона возможных требований, предъявляемых програлпшым системам, в стандарте нс определена стрултура этого раздела. Здесь молуг быть документпровапы внешние интерфейсы, описаны функциональные возможности системы, приведены требования, определяющие логическую структуру бал данных, ограничения, пакзздываемьлс на струкл>ру системы, описаны интеграционные свойства системы или се качествелшые характеристики.
124 Часть П. Требования 4. Приложения 5. Указатели Таблица 5.4. Структура спецификации требований Раздел Описание Предисловие Здесь определяется круг лиц, на которых рассчитан данный доку- мент. Описываются предыд)чцие версии разрабатываемого про. граммного продукта, а также изменения, внесенные в каждую вер- сию. Дается обоснование для создания новой версии продукта Здесь более развернуто обосновывается необходимость создания системы. Кратко перечисляются системные функции и объясня.
ется, как система будет работать совместно с другими системами. Должно быть показано, как разработка системы "вписывается" в общую бизнес-стратегию компании, эаказывающей программный продукт Дается описание технических терминов, используемых в докумен- те. Здесь не делается каких-либо предположений об уровне знаний илн практическом опьпе читателя документа Описываются сервисы, предоставляемые пользователям, и не- функциональные системные требования. Это описание может быть сделано на естественном языке с использованием диаграмм, блоксхем и других форм записи, понятных заказчику программ- ной системы.
Здесь также должны быть приведены стандарты на программный прод)ьт и процесс его разработки Здесь приводится высокоуровневое представление возможной системной архитектуры с указанием, как распределены системные функции по компонентам системы. Обязательно должны быть вы- делены повторно используемые (т.е. уже существующие) компо- ненты Введение Глоссарий Пользовательские требования Системнаяархитек- тура Системные требова- ния Подробно описываютсл функциональные и нефункциональные требования.
Если необходимо, нефункциональные требования до. полняются описанием интерфейсов других систем Здесь представлено несколько системных моделей, показывающих взаимоотношения между системными компонентами и между сис- темой и ее окружением. Это могут быть объектные модели, модели потоков данных или модели данных Систсмпыс модели Приводятся основные предположения и допущения, на которых ба- зируется система, а также ожидаемые (прогнозируемые) изменения в аппаратных средствах, в потребностях пользователей и т.п, Эволюцил системы Хотя стандарт 1ЕЕЕ не идеален, он может служить отправной точкой при написании спецификации.
Конечно, при ее написании необходимо также учитывать стандарты, принятые в орщниэации — разработчике ПО. В табл. 5.4 описаны возможные разделы спецификации, построенной на основании стандарта 1ЕЕЕ Я также включил раздел о возможной эволюции системы, как рекомендует Хенингер. Б. Требования к программному обеспечению 125 Окончание табл. 5.4 Раздел Приложения Описание Здесь приводится специализироаанная информация, относящаяся к разрабатываемой системе, например описание аппаратных средста или базы данных, с которыми должна работать система. При описании аппаратных средств необходимо показать мини- мальную и оптимальную конфигурации, при которых может рабо- тать программная система.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
