И. Соммервилл - Инженерия программного обеспечения (1133538), страница 49
Текст из файла (страница 49)
При обычном процессе разработки ПО стоимость аттестации системы составляет около 50% всей стонмоспг разработки, а стоимость проектирования и реализации системы в два раза больше стоимости разработки спецификации. При использовании формальной спецификации стоимости разработки спецификации и реализации системы соизмеримы, а стоимость аттестации значительно снижается, поскольку в процессе разработки формальной спецификации обнаруживаются и устраплются недоработки в требованиях, тем самым исключается переделка системы на последник стадиях ее создания. Существует два основных подхода к разработке формальной спецификации, которые используются для написания детализированных спецификаций нетривиальных про. граммных систем.
1. Алгебраический подход, при котором система описывается в терминах операций и нх отногпеннй. 9. Формальные спецификации ПО 191 2. Подход, ориентированный на моделирование, при котором иодель системы стро. итси с использованием математических конструкций, таких, как множества и по. следовательности, а системные операции определяются тем, как онн изменлют со. стояния системы. о а Без фсрмеианей слецифинции С формальной специФикацией Рис 9 3. Стоимососа рпзроботки ПО с форзоыышй согкийуикоцией Для разработки формальных спецификаций последовательных и параллельных систем в настоящее время создано несколько языков, представленных в табл.9.1. В атой главе описаны оба подхода. Приведенные далее примеры показывают, как построение фор.
мальпых спецификациИ приводит к точным и детализированным спецификациям, но здесь пе обсуждаются языки разработки спецификаций и методы специфицировании. Вы можете получить более полное описание языков разработки формальных спецификаций на ауеЬ.странице данной книги. Таблица 9.1. Языки разработки формальных спецификаций Тип языка Последовательные системы Параллельные системы Алгебраический [лгс!а [144, 145], ОВ] [123) Босое [52) Основанный на моделях Х [325), 70М [192], В [343] Сбр [163], сети Петри [277] 9.2. Специфицирование интерфейсов Большие системы обычно разбиваются на подсистемы, которые разрабатываются независимо друг от друга.
Подсистемы месут использовать другие полспстемы, позтол~у пс. обходимой частью процесса специфпцированил является определение интерфейсов подсистем. Если интерфейсы определены и согласованы, подсистемы можно разрабатывать независимо друг от друга. 192 'Часть 11. Требования Интерфейс подсистеиы часто определяется как набор абстрактных типов данных и объектов (рис.
9.4), прн этом только через интерфейс доступны описание данных и опе. рации над ними. Поэтому спецификацию интерфейса подсистемы можно рассматривать как объединение спецификаций компонентов, что в итоге и составит описание интерфейса подсистемы. Объвпн яяшрфейсов Ркс. 94. Обыкжгаинвмрфейшэ лодгисмак Точные спецификации интерфейсов подсистем необходимы для разработчиков, которые пиш)т программный код, обращающийся к сервисам других подсистем. Спецификации интерфейсов содержат информацию о том, какие сервисы доступны в других подсистемах и как получить к ним доступ. Ясный и однозначный интерфейс подсистем уменьшает вероятность ошибок во взаимоотношениях между ними.
Алгебраический подход первоначально был разработан для описания интерфейсов абстрактныхх типов данных, где типы данных определяются скорее спецификациями операций над данными, чеи способом представления самих данных. Это очень похоже на опре. детепнс классов объектов. Алгебраический подход к формальным спецификациям определлет абсгракгный тип данных в терминах операций над данными. Первый метод спецификации абстрактных типов данных описан в работе (143].
В [78] этот метод был расширен, чтобы предоставить возможность создания завершенной системной спецификации. Одновременно была разработана алгебраическая спецификация абстрактных типов данных (220]. В этой связи отметим, что, вероятгю, наилучшим из известных лзыков алгебраической спецификации является 1.АКСН ]145]. Структура спецификации объекта показана на рис. 9.5 и состоит иэ четырех компонентов. ° Введение, где объявляется класс (вой) объектов.
Класс — это общее название для множества объектов. Он обычно реализуется как тип данных. Ввсдсннс может также включать объявление импорта ()щрог(в), где указываются имена спецификаций, определяющие др!тис классы. Импортирование спецификаций делает зти классы доступными длл использования. ° Опнсатсльнал часть, в которой неформально описываются операции, ассоциированные с хаассом. Это делает формальную спецификацию более простой для понимания.
чормальная спецификация дополняет это описание, обеспечивая однозначны(! синтаксис и семантику операций. ° Часть сигнатур, в которой определяется синтаксис интерфейса объектного класса илн абстрактного типа данных. Здесь описываются имена операций, количество и типы нх параметров, а также классы выходных результатов операций. ° Часть аксиом, где определлется семантика операций посредством создания ряда аксиом, которые характеризуют поведение абстрактного типа данных. Эти аксио. 9. Формальные спецификации ПО 193 мы связывают операции создания объектов класса с операциями, проверяющими их значения. Рис 9.5.
Смрукэ(ура алмэракчэасэк скевификокии Процесс разработки формальной спецификации интерфейса подсистемы включает следующие действия. 1. С~п~укмуркрэваниг сягкнфккацик. Представление неформальной спецификации интерфейса в виде множества абстрактных типов данных или объектных классов. Также неформально определяются операции, ассоциированные с каждым классом. 2.
Икенээакие спецификаций Задаются имена для каждой спецификации абстрактного типа, определяются параметры спецификаций (если они необходимы) и имена оп- ределяемых классов. 3. Опредоиюи операций. На основании списка выполняемых интерфейсом функций для каждой спецификации определяется связанный с ней набор операций. Необходимо предусмотреть операции по созданию экземпляров классов, по изменению значений экземпляров классов и по проверке этих значений. Вероятно, придется добавить новые функции к первоначально определенному списку функций интерфейса.
4. Оеу)э)миыьнаэ сяехифккацкл ояэракий. Написание неформальной спецификации для каждой операции, где должно быть указано, как операции воздействуют на определяемый класс. 5. Определенна гинеакамл тирлкик. Определение синтаксиса и параметров для каждой операции. Это часть сигнатуры формальной спецификации. 6. Оиредэмяие аксиом. Определение семантики операций путем описания условий, ко- торые должны выполняться для различных комбинаций операций. Для пояснения методики алгебраической спецификации, рассмотрим простую структуру данных связанного списка, спецификация которого показана на рис.
9.6. Предположим, что первый этап разработки спецификации списка, а именно структурирование спецификации, выполнен. Имя спецификации и имя класса может быть одним и тем же, хотя полезно проводить различие между ними, используя какое-либо соглашение. Например, я использую заглавные буквы для имени спецификации ((.(ЗТ) и пропис. ные буквы с первой заглавной буквой для имени класса (0в1). Поскольку списки могут со. держать элементы разных типов, спецификация имеет общий параметр Е(ещ (Элемент). Тип Е(егп может представлять целое число, строку, список и т.д. 194 куасть П.
Требования ОЭТ (Веш) зотз (йт )шаата )НТЕВЕН Опредшиние списш, а шторам шаманты добазяяются а швец, а изшашняся ш яершины (шгаа) спишь Операция Сшзте (Сощать) создает пустой слисшс операция Сши (Конструироаание) создает нояьй саюк, содерхаций раззнныд злемею; (апой О(лике) зошрящэет размер списщ Ншб (Вершил элемент) зошрзщает элемент из вершины спишэ; операция Тау измшшет список путем удаления из него перва о элемшпа (алемана на вершине сшюш). Значения типа Ваи (Элемент) не опрелшшны, Сгеате -+ Взт Сопя (()Ц, Вем) -ь Ва Ныб ((й)) -ь Вее (епдй ((яЦ -+ Ыерег тзз(Взй -+ кй Неаб (Сто) = Опбершб еюеербоп (пустой список) Неаб (Сапз (В ч)) = й 'ь = Слете бмп ч е(зе Неаб (ь) (епрй (Сгеате) = 0 (елрй (Сопя ().
ч)) = (епрй (Ц +! Тау (Сгеате ) = Сгште Тай (Сшп ((. ч)) = р 'ь = Сгеае бмп Сгеате е)зе Сопя (Тэб (1), ч) Рис рб. Спвниугиклцилсвлзпннвгв сливка В общем случае длл каждого абстрактного типа данных набор необходимых операций должен содержать операцию по созданию нового экземпляра этого типа данных и операцию по конструированию экземпляра данного типа из имеющихся элсментоэ (э нашем примере это операции Сгеа!е и Соне). В случае применения списков также должны быть операции для получения значения первого элемента списка (н нашем примере операция Нааб), операция, которая изменяет список путем удаления его первого элемента (Тай), и операцил подсчета количества элементов а списке (Еники()т).
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
