Функциональная спецификация программного средства

должна быть максимально точной (в науке есть такой термин, «математическая точность»). Она должна базироваться на понятиях, построенных как математические объекты и утверждениях, однозначно понимаемых разработчиками ПС. Часто формулируется на естественном языке. Тем не менее использование математических методов и формализованных языков желательно.

Функциональная спецификация состоит из 3х частей:

1. Описание внешней информационной среды, к которой должны применяться программы ПС. Здесь на концептуальном уровне должны быть определены все используемые каналы ввода-вывода, информационные объекты и связи между ними. Например, схема базы данных или описание сети датчиков и приборов.

2. Определение функции ПС определенных на множестве состояний информационной среды (внешние функции ПС). Вводятся обозначения всех определяемых функций, специфицируется определенные данные, включая указание типов данных (числа/текст) и ограничений на эти результаты. Далее, также определяется семантика каждой функции (наиболее трудная задача), она обычно описывается неформально.

3. Описание нежелательных ситуаций, возникающих при выполнении программ и реакций на эти ситуации. Перечислены все случаи, когда ПС не может нормально выполнить какую-то функцию (например, неправильно введенные данные). А также должна быть определена реакция ПС (т.е. то что должна делать ПС в данном случае).

Методы контроля внешнего описания пс

Разработка внешнего описания должна завершатся проведением контроля. Цель этапа – найти как можно больше ошибок.

Существуют следующие методы контроля:

1. Статический просмотр – это внимательное прочтение текста с целью проверки на полноту и непротиворечивость. Выявляет неточности и явные ошибки.

2. Смежный контроль – выделяют:

Смежный контроль спецификации сверху – это проверка со стороны разработчика требований ПС.

Контроль функциональной спецификации – это проверка разработчиками требований ПС и спецификации качества

Смежный контроль внешнего описания снизу – это его изучение и проверка разработчиками архитектуры ПС.

3. Пользовательский контроль. Если разработка требований ПС велась под управлением пользователя, то пользовательский контроль – это смежный контроль сверху. Поскольку пользователю трудно разобраться в нем, эту функцию берут на себя специальная группа разработчиков.

4. Ручная имитация представляет собой динамический контроль внешнего описания, проверяется имитацией будущего ПС путем имитации его поведения. Эта имитация выполняет специальный назначенный разработчик, выполняющий роль будущих программ ПС.

Архитектура программного средства

Архитектура ПС это его строение, т.е. как оно видно извне, т.е. представление ПС как системы состоящей из совокупности взаимодействующих подсистем. При разработке архитектуры ПС определяются следующие задачи:

1. Выделение программных подсистем и отображение их внешних функций

2. Определение способа взаимодействия между выделенными программными подсистемами

Различают следующие классы архитектур ПС:

1. Цельная программа – вырожденный случай архитектуры, когда в состав средства входит только одна программа. Эта архитектура свойственна в тех случаях, когда ПС должно выполнять одну ярко выраженную функцию и ее реализация не представляется слишком сложной. Архитектура не требует никакого описания (только одна программа).

2. Комплекс автономно выполняемых программ – состоит из набора программ, организованных следующим образом:

   1. Любая программа может быть активирована пользователем

   2. При выполнении одной программы, другие программы не могут быть активизированы до тех пор, пока не закончит выполнение запущенная программа

   3. Все программы применяются для одной и той же информационной среды

Таким образом каждая программа не взаимодействует друг с другом. Взаимодействие осуществляется только через общую информационную среду.

3. Слоистая программная система – состоит из упорядоченной совокупности подсистем. Системы формируют слои или уровни. Уровни отвечают следующим требованиям:

   1. На каждом слое ничего неизвестно, о свойствах последующих слоев (более высоких)

   2. Каждый слой может взаимодействовать только непосредственно с предшествующими слоями через строго определенный интерфейс, ничего не зная о всех других предшествующих слоях, таким образом можно реализовать некоторую абстракцию данных.

   3. Связи между слагаемыми ограничены передачами значений каждого слоя смежного снизу и передаче данных слою смежному выше.

   4. Использование глобальных данных (т.е. тех которые используются разными слоями) недопустимо.

Пример таких систем – операционная система; стеки коммуникационных протоколов компьютерных систем

4. Коллектив параллельно действующих программ – представляет собой набор программ, способных взаимодействовать друг с другом, одновременно находясь на стадиях выполнения. Это означает, что все они загружены в оперативную память и попеременно используют один или несколько процессоров. Обычно взаимодействие между ними осуществляется путем передачи друг другу некоторых сообщений. В простейшем случае такой архитектурой может являться конвейер, здесь единый поток данных передается от одной программы к следующей. В более сложном случае коллектив программ может быть организован в систему с портами сообщений. Код – это программная подсистема, обслуживающая очередь сообщений, она может принимать на хранение сообщения от других программ или передавать сообщения другим, для этого подсистема каждого порта находится в режиме ожидания и ждет соответствующих сообщений. Такая архитектура может быть, как жесткой конфигурации, так и гибкой (динамической). В жесткой конфигурации каждый порт связан с определенной программой. Система с гибкой конфигурацией связаны входные и выходные порты, структура которых может меняться.