2. Спецификации программного обеспечения при структурном подходе

Спецификациями называют точное формализованное описание функций и ограничений разрабатываемого программного обеспечения.

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

В рамках структурного подхода на этапе анализа и определения спецификаций используют три типа моделей:

- ориентированные на функции;

- ориентированные на данные;

- ориентированные на потоки данных.

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

Так методологии структурного анализа и проектирования обычно используют комплексное представление проектируемого программного обеспечения в виде совокупности моделей:

- спецификаций процессов;

- словаря терминов;

- диаграмм переходов состояний (STD – State Transition Diagrams), характеризующих поведение системы во времени;

- функциональных диаграмм SATD (Structured Analysis and Design Technique – технология структурного анализа и проектирования);

- диаграмм потоков данных (DFD – Data Flow Diagrams), описывающих взаимодействие источников и потребителей информации через процессы, которые должны быть реализованы в системе;

- диаграмм «сущность-связь» (ERD – Entity-Relationship Diagrams), описывающих базы данных разрабатываемой системы [1].

2.1. Дерево диаграмм

Диаграмма дерева узлов показывает иерархию работ в модели и позволяет рассмотреть всю модель целиком, но не показывает взаимосвязи между работами (стрелки). Процесс создания модели работ является итерационным, следовательно, работы могут менять свое расположение в дереве узлов многократно. Чтобы не запутаться и проверить способ декомпозиции, следует после каждого изменения создавать диаграмму дерева узлов [2].

Дерево диаграмм, представленное на рисунке 2.1, построена для АИС «Отдел вневедомственной охраны». Дерево диаграмм подразделяется на 4 уровня. На первом уровне находятся процессы: «Инициализация системы», «Функционирование отдела охраны», «Создание отчетов». Второй процесс «Функционирование отдела охраны» подразделяется на 4 подпроцесса: «Составление договоров», «Подключение к охранной системе», «Составление графиков патрулирования» и «Обработка случая срабатывания сигнализации». Четвертый процесс «Обработка случая срабатывания сигнализации» второго уровня также подразделяется на 2 подпроцесса: «Запись случая срабатывания сигнализации» и «Составление акта».

Рис.2.1. Дерево диаграмм

2.2. Структура sadt-модели

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

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

Каждый блок такой диаграммы соответствует некоторой функции, для которой должны быть определены:

- исходные данные;

- результаты;

- управляющая информация;

- механизмы её осуществления – человек или технические средства

Все связи функции представляются дугами, причем тип связи и ее направление строго регламентированы.

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

В функциональных диаграммах SADT различают пять типов влияний блоков друг на друга:

- вход - выход блока подается на вход блока с меньшим доминированием, т. е. следующего;

- управление - выход блока используется как управление для блока с меньшим доминированием (следующего);

- обратная связь по входу  выход блока подается на вход блока с большим доминированием (предыдущего);

- обратная связь по управлению  выход блока используется как управляющая информация для блока с большим доминированием (предыдущего);

- выход-исполнитель - выход блока используется как механизм для другого блока [1].

Общее представление системы «Отдел вневедомственной охраны» представлено в идее диаграммы нулевого уровня на рис.2.2. Диаграмма нулевого уровня включает в себя функциональный блок «Отдел вневедомственной охраны» и интерфейсные дуги: исходные данные, управление («ГОСТ на системы охраны и безопасности», «Внутренние инструкции», «ГОСТ на системы тревожной сигнализации»), механизм («Сотрудник отдела», и «АИС») и результаты.

Для более детального представления системы надо выполнить декомпозицию – когда каждая подсистема разбивается на более мелкие для достижения нужной системы детализации. Декомпозиция функции «АИС Отдел вневедомственной охраны», представленная на рис.2.3., включает в себя 3 процесса декомпозиции: «Инициализация системы», «Функционирование отдела охраны», «Создание отчетов». Для первого процесса «Инициализация системы» исходными данными являются: «Информация о сотрудниках». Для второго процесса «Функционирование отдела охраны» являются: «Список сотрудников предприятия», «Заявка на обеспечение охраны помещения», «Информация о помещении и имуществе», «Информация о клиенте», «Информация о месте срабатывания сигнализации», «Информация от патрульных о месте срабатывания сигнализации». Для третьего процесса «Создание отчетов» являются: «Журнал срабатывания сигнализации», «Список патрульных», «Список сотрудников предприятия», «Информация от патрульных о месте срабатывания сигнализации». Также во всех процессах сверху входит управление («ГОСТ на системы охраны и безопасности», «Внутренние инструкции», «ГОСТ на системы тревожной сигнализации»), а снизу в каждый процесс входит механизм («Сотрудник компании» и «АИС»). А справа выходят результаты, которые будут расписаны подробно для каждого процесса ниже.

Декомпозиция процесса «Функционирование отдела охраны», представленная на рис.2.4., разбивается на 4 процесса: «Составление договоров», «Подключение к охранной системе», «Составление графиков патрулирования» и «Обработка случая срабатывания сигнализации». Исходные данные предоставлены в абзаце выше.

Для первого процесса «Составление договоров» результатом является «Договор об охране имущества». Для второго процесса «Подключение к охранной системе» результатом является «Список охраняемых объектов». Для третьего процесса «Составление графика патрулирования» результатом является «Список патрульных». И для четвертого процесса «Обработка случая срабатывания сигнализации». результатами являются «Акт о случае срабатывания сигнализации», «Журнал срабатывания сигнализация».

Декомпозиция процесса «Обработка случая срабатывания сигнализации», представленная на рис.2.5., разбивается на 2 процесса: «Запись случая срабатывания сигнализации» и «Составление акта». Исходные данные предоставлены в абзаце выше.

Для первого процесса «Запись случая срабатывания сигнализации» результатом является «Журнал срабатывания сигнализации». Для второго процесса «Составление акта» результатом является «Акт о случае срабатывания сигнализации».

Рис.2.2. Нулевой уровень SADT-модели

Рис.2.3. Декомпозиция функции «Отдел вневедомственной охраны»

Рис.2.4. Декомпозиция функции «Функционирование отдела охраны»

Рис.2.5. Декомпозиция функции «Обработка случая срабатывания сигнализации»