3.2.5. Методологии структурного моделирования

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

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

В настоящее время успешно используются такие методологии, как структурный системный анализ Гейна-Сарсона, структурный анализ и проектирование Йордана-де Марко, SADT и другие.

Диаграммы потоков данных. Нотация Йордана-де Марко. Нотация Гейна-Сарсона.

Диаграммы потоков данных (DFD – Data Flow Diagramm) являются основным средством моделирования функциональных требований проектируемой системы.

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

Главная цель таких средств – продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами.

Для изображения DFD традиционно используются две различные нотации: Йордана-де Марко и Гейна-Сарсона.

Диаграммы потоков данных строятся из элементов, представленных в таблице:

Элемент	Нотация Йордона–де Марко	Нотация Гейна-Сарсона
Функция
Поток данных
Хранили-ще данных
Внешняя сущность

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

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

Важность этого объекта очевидна: он даёт название целому инструменту. Потоки на диаграммах обычно изображаются именованными стрелками, ориентация которых указывает направление движения информации.

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

Назначение функции состоит в продуцировании выходных потоков из входных потоков в соответствии с действием, задаваемым именем функции.

Это имя должно содержать глагол в неопределённой форме с последующим дополнением (например, «ВЫЧИСЛИТЬ МАКСИМАЛЬНУЮ ВЫСОТУ»).

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

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

Хранилище позволяет на определённых участках определять данные, которые будут сохраняться в памяти между процессами.

Фактически хранилище представляет «срезы» потоков данных во времени.

Информация, которую оно содержит, может использоваться в любое время после её определения, при этом данные могут выбираться в любом порядке.

Имя хранилища должно идентифицировать его содержимое и быть существительным.

В случае, когда поток данных входит или выходит в/из хранилища и его структура соответствует структуре хранилища, он должен иметь то же самое имя (что и хранилище), которое нет необходимости отражать на диаграмме.

Внешняя сущность представляет сущность вне контекста системы, являющуюся источником или приёмником системных данных. Её имя должно содержать существительное, (например, «СКЛАД ТОВАРОВ»).

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

Функции, хранилища и внешние сущности на DFD-диаграмме связываются дугами, представляющими потоки данных.

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

При интерпретации DFD-диаграммы используются следующие правила:

• функции преобразуют входящие потоки данных в выходящие;

• хранилища данных не изменяют потоки данных, а служат только для хранения поступающих объектов;

• преобразования потоков данных во внешних сущностях игнорируются.

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

Именно эта информация является исходной на следующем этапе проектирования – построении модели «сущность-связь».

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

Рассмотрим пример…

Рисунок 3.2.5.1 – Пример схемы БД

Здесь представлена DFD-диаграмма для предприятия, строящего свою деятельность по принципу «изготовление на заказ».

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

После изготовления продукции и проведения платежей, готовая продукция отправляется заказчику.

Эта диаграмма представляет самый верхний уровень функциональной модели. Естественно, это весьма грубое описание предметной области.

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

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

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