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

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

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

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

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

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

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

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

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

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

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

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

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

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

- диаграмм «сущность-связь» (ERD – Entity-Relationship Diagrams), описывающих базы данных разрабатываемой системы [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. Декомпозиция функции «Обработка случая срабатывания сигнализации»

 

Диаграмма потоков данных

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

В основе модели лежат понятия:

- внешняя сущность- материальный объект или физическое лицо, выступающие в качестве источников или приемников информации (заказчики, персонал, поставщики, клиенты, банк и т. п);

- процесс - преобразование входных потоков данных в выходные в соответствии с определенным алгоритмом. Каждый процесс в системе имеет свой номер и связан с исполнителем, который осуществляет данное преобразование;

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

- поток данных- процесс передачи некоторой информации от источника к приемнику [1].

Контекстная диаграмма для АИС «Отдел вневедомственной охраны», представленная на рисунке 2.6., включает: систему АИС «Отдел вневедомственной охраны»; внешние сущности – «Сотрудник», «Помещение», «Руководство»; потоки данных циркулирующих между системой и внешними сущностями.

Детализирующая диаграмма потоков данных АИС «Отдел вневедомственной охраны», представленная на рисунке 2.7., включает следующие процессы: «Работа с сотрудником», «Работа с помещением», «Работа с руководством»; а также хранилище данных «БД».
Для процесса «Работа с сотрудником» потоком данных является «Информация о сотруднике». Для процесса «Работа с помещением» потоками данных являются «Заявка на охрану», «Информация о помещении и клиенте», «Информация о сработавшей сигнализации», «Информация от патрульных о месте срабатывания сигнализации». Для процесса «Работа с руководством» потоком данных является «Запрос отчета». Потоками данных для хранилища «БД» являются «Регистрация сотрудника», «Список сотрудников в патрулировании», «Регистрация Помещения», «Договор об охране имущества», «Запись случая срабатывания сигнализации».

Детализирующая диаграмма потоков данных процесса «Работа с сотрудником» представлена на рисунке 2.8, которая включает хранилище данных «БД» и процессы «Регистрирование сотрудника», «графика патрулирования». Процесс «Регистрирование сотрудника» имеет поток данных «Информация о сотруднике». Процесс «Составление графика патрулирования» имеет поток данных «Запрос графика патрулирования». Потоками данных для хранилища «БД» являются: «Регистрация сотрудника», «список сотрудников в патрулировании».

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

 

Рис.2.6. Контекстная диаграмма для АИС «Отдел вневедомственной охраны»

Рис.2.7. Детализирующая диаграмма потоков данных АИС «Отдел вневедомственной охраны»

Рис.2.8. Детализирующая диаграмма потоков данных процесса «Работа с сотрудником»

 

Рис.2.9. Детализирующая диаграмма потоков данных процесса «Работа с помещением»

 

 

2.4. Диаграмма «сущность-связь»

Цель построения таких диаграмм является обеспечение разработчика концептуальной схемой БД.

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

- нотация П. Чена;

- нотация Р. Баркера;

- нотация IDEF 1 (более современный вариант этой нотации - IDEF1X
используется в CASE -системах, например в системе ERWin).

Базовыми понятиями модели данных являются:

- Сущность - реальный или воображаемый объект, имеющий существенное значение для рассматриваемой предметной области.

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

- Связь - поименованная ассоциация между двумя или более сущностями, значимая для рассматриваемой предметной области.

Логическая модель для АИС «Отдел вневедомственной охраны» представлена на рисунке 2.10. Логическая модель включает данные сущности: «Помещение», «Договор», «Журнал договоров», «Сотрудник», «Журнал сработавших сигнализаций», «Патруль», «Журнал патрулирования», «Акт о сработавшей сигнализации». Сущность «Помещения» включает в себя: первичные атрибуты - код помещения; и вторичные – адрес, серияномер паспорта клиента, описание планировки, контактные данные клиента, ФИО клиента. Сущность «Договор» включает в себя: первичные атрибуты - код договора, код помещения [ FK ], табельный номер [ FK ]; и вторичные – дата составления договора, срок действия договора. Сущность «Журнал договоров» включает в себя: первичные атрибуты – код журнала, код договора[ FK ], код помещения [ FK ], табельный номер [ FK ]; и вторичные – дата и время составления договора. Сущность «Сотрудник» включает в себя: первичный атрибут – табельный номер; и вторичные – ФИО сотрудника, телефон, должность, состояние здоровья. Сущность «Журнал сработавших сигнализаций» включает в себя: первичные атрибуты – код случая срабатывания; и вторичные – код помещения [ FK ]; время срабатывания. Сущность «Патруль» включает в себя: первичные атрибуты – код патруля, табельный номер [ FK ]; и вторичные – дата составления патруля. Сущность «Журнал патрулирования» включает в себя: первичные атрибуты - код журнала, код патруля[ FK ], табельный номер [ FK ]; и вторичные – дата и время патрулирования.Сущность «акт о сработавшей сигнализации» включает в себя: первичные атрибуты - код акта, табельный номер [ FK ], код случая срабатывания[ FK ], код патруля [ FK ]; и вторичные – дата составления, время прибытия патруля, причина срабатывания сигнализации.

Физическая модель для АИС «Отдел вневедомственной охраны» представлена на рисунке 2.11. Физическая модель включает данные сущности: «Помещение», «Журнал договоров», «Сотрудник», «Журнал сработавших сигнализаций», «Клиент», «Журнал патрулирования», «Акт о сработавшей сигнализации». Для атрибутов, отсутствие которых недопустимо, указывается признак NOT NULL (Табельный номер, коды, Ф.И.О. и т.д.)

Функциональная схема программного обеспечения системы охранного предприятия, предоставленная в приложении 1. Схема включает: Ручной ввод(заявку на охрану, запросы графика дежурств, запросы отчетов); данные (подсистема инициализации системы, подсистема оформления договоров и т.д.); дисплей (Вывод форм ввода, Вывод форм договора и т.д.); Запоминающее устройство с прямым доступом (База данных).

 

Рис.2.10. Логическая модель для АИС «Отдел вневедомственной охраны»

Рис.2.11. Физическая модель для АИС «Отдел вневедомственной охраны»

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