Файл: Проектирование ПО Структурный подход.docx

Нижегородский государственный архитектурно-строительный университет

Кислицын Дмитрий Игоревич

Курс лекций по дисциплине

«Проектирование программного обеспечения»

Часть 2

Структурный подход к проектированию программного обеспечения

Нижний Новгород – 2017

Раздел 5. Описание методологии DFD

Стандарт описания бизнес-процессов DFD - Data Flow Diagram переводится как диаграмма потоков данных и используется для описания процессов верхнего уровня и для описания реально существующих в организации потоков данных.

5.1. Использование и особенности DFD диаграмм

Созданные модели потоков данных организации могут быть использованы при решении таких задач, как:

1. определение существующих хранилищ данных (текстовые документы, файлы, Система управления базой данных — СУБД);

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

3. подготовка к созданию модели структуры данных организации, так называемая ERD-модель (IDEF1X);

4. выделение основных и вспомогательных бизнес-процессов организации.

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

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

5.2. Графический язык моделирования DFD диаграмм

Существуют две нотации DFD:

1) Йордана-Де Марко,

2) Гейна-Сарсона.

Их краткое описание представлено в таблице 5.1.

Требования к оформлению функций:

1. Каждая функция должна иметь идентификатор;

2. Названия работы нужно формулировать согласно следующее формуле:

Название работы = Действие + Объект, над которым действие осуществляется

Например, если эта работа связана с действием по продаже продукции, то ее нужно назвать «Продажа продукции».

3. Название работы должно быть по возможности кратким (не более 50 символов) и состоять из 2 - 3 слов. В сложных случаях также рекомендуется для каждого краткого названия работы сделать ее подробное описание, которое поместить в глоссарий.

Таблица 5.1.

Требования к оформлению потока данных:

1. Название потока нужно формулировать согласно следующей формуле:

Название потока = Объект, представляющий поток + Статус объекта

Например, если речь идет о продукции, которую отгрузили клиенту, то поток можно назвать <Продукция, отгруженная> или <Продукция, отгруженная клиенту>. В данном случае <Продукция> это объект, представляющий поток, а <отгруженная клиенту> — статус объекта.

2. Название должно быть по возможности кратким и состоять из 2 - 3 слов.

5.3. Построение DFD-модели

Построение DFD-модели базируется на принципе декомпозиции. DFD-модель включает в себя три документа, которые ссылаются друг на друга: Графические диаграммы, Миниспецификация, Словарь данных.

1. Контекстная диаграмма или иерархия контекстных диаграмм

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

Рис. 5.1.

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

• наличие большого количества внешних сущностей (десять и более);

• распределенная природа системы;

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

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

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

2. Детализация контекстной диаграммы

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

Рис. 5.2.

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

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

• правило нумерации - при детализации процессов должна поддерживаться их иерархическая нумерация;

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

Например, процессы, детализирующие процесс с номером 12, получают номера 12.1, 12.2, 12.3 и т.д.

3. Миниспецификация

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

Миниспецификация является конечной вершиной иерархии модели DFD. Решение о завершении детализации процесса и использовании миниспецификации принимается аналитиком исходя из следующих критериев:

• у процесса небольшое количество входных и выходных потоков данных (2-3 потока);

• процесс можно описать в виде последовательного алгоритма;

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

• описать логику процесса можно в виде миниспецификации небольшого объема (не более 20-30 строк).

4. Словарь данных

В словаре данных определяется структура и содержание всех потоков данных и накопителей данных, которые присутствуют на диаграммах.

Для каждого потока в словаре хранятся: имя потока, тип, атрибуты
(таблица 5.2).

Таблица 5.2.

5.4. Проверка DFD модели

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

Модель считается полной, если все ее объекты (подсистемы, процессы, потоки данных) подробно описаны и детализированы.

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

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

Рис. 5.3.

В деятельности ресторана выделены три функции:

1. обслуживание клиентов,

2. деятельность кухни,

3. управление финансами и производством.

Внешними сущностями по отношению к рассматриваемой (разрабатываемой) системе на данном уровне декомпозиции являются:

1. посетители,

2. поставщики.

В рамках рассматриваемой системы предусмотрены два хранилища данных, которые могут быть реализованы через таблицы базы данных:

1. меню,

2. заказы.

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

Раздел 6. Описание методологии ERD

Хранилище данных, указанное в методологии DFD, реализуется через базу данных (БД). Первым шагом при создании логической модели БД является построение диаграммы ERD (Entity Relationship Diagram). ERD-диаграммы состоят из трех частей: сущностей, атрибутов и взаимосвязей. Сущностями являются существительные, атрибуты - прилагательными или модификаторами, взаимосвязи - глаголами.

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

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

6.1. ERD-диаграммы

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

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

Рис. 6.1.

6.2. Определение сущностей и атрибутов

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

На рисунке 6.2 показана ERD-диаграмма, включающая в себя атрибуты сущностей.

Рис. 6.2.

6.3. Логические взаимосвязи

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

Некоторые примеры взаимосвязей:

• команда включает много игроков,

• самолет перевозит много пассажиров,

• продавец продает много продуктов.

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