1.2.7 Пример выполнения практического задания

Описание предметной области «Формирование заказов»

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

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

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

В силу данного обстоятельства требуется не только формирование заказа контракта и счета клиента, но и формирование заявки для доставки соответствующих товаров на склад

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

Рис. 1.17 Контекстная диаграмма

Рис. 1.18 Диаграмма декомпозиции 1-го уровня

Рис. 1.19 Диаграмма декомпозиции 2-го уровня

(процесс «Произвести оформление документов на заказ»)

1.3. Дополнение созданной модели процессов диаграммами dfd

1.3.1. Диаграммы поисков данных (Data Flow Diagrams)

Диаграммы потоков данных (Data flow diagrams, DFD) известны очень давно. В фольклоре упоминается следующий пример использования DFD для реорганизации переполненного клерками офиса, относящийся к 20-м годам. Осуществлявший реорганизацию консультант обозначил кружком каждого клерка, а стрелкой - каждый документ, передаваемый между ними. Используя такую диаграмму, он предложил схему реорганизации, в соответствии с которой двое клерков, обменивающиеся множеством документов, были посажены рядом, а клерки с малым взаимодействием были посажены на большом расстоянии. Так родилась первая модель, представляющая собой потоковую диаграмму - предвестника DFD.

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

DFD показывает внешние по отношению к системе источники и стоки (адресаты) данных, идентифицирует логические функции (процессы) и группы элементов данных, связывающие одну функцию с другой (потоки), а также идентифицирует хранилища (накопители) данных, к которым осуществляется доступ. Структуры потоков данных и определения их компонент хранятся и анализируются в словаре данных. Каждая логическая функция (процесс) может быть детализирована с помощью DFD нижнего уровня; когда дальнейшая детализация перестает быть полезной, переходят к выражению логики функции при помощи спецификации процесса (миниспецификации). Содержимое каждого хранилища также сохраняют в словаре данных, модель данных хранилища раскрывается с помощью диаграмм "сущность-связь" (Entity-Relationship Diagrams, ERD).

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

Для изображения DFD традиционно используются две различные нотации: Йодана (Yourdon) и Гейна‑Сарсона (Gane‑Sarson).

В Ramus для построения диаграмм потоков данных используется нотация Гейна‑Сарсона.

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

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

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

Название символа	Изображение символа
Поток данных
Процесс
Хранилище
Внешняя сущность

Рис. 1.20 Основные символы диаграммы потоков данных

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

Хранилище (накопитель) данныхпозволяет на определенных участках определять данные, которые будут сохраняться в памяти между процессами. Фактически хранилище представляет «срезы» потоков данных во времени. Информация, которую оно содержит, может использоваться в любое время после ее определения, при этом данные могут выбираться в любом порядке. Имя хранилища должно идентифицировать его содержимое и быть существительным. В случае, когда поток данных входит или выходит в/из хранилища, и его структура соответствует структуре хранилища, он должен иметь то же самое имя, которое нет необходимости отражать на диаграмме.

Внешняя сущность (внешняя ссылка)представляет сущность внеконтекста системы, являющуюся источником или приемником системных данных. Ее имя должно содержать существительное, например,«Клиент». Предполагается, что объекты, представленные такими узлами, не должны участвовать ни в какой обработке.

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

Если создается независимая DFDмодель, то контекстная диаграмма содержит один процесс и внешние сущности (рис. 1.21).

Рис. 1.21 Пример контекстной DFDдиаграммы

В отличие от стрелок IDEF0, которые представляют собой жесткие взаимосвязи, стрелки DFD показывают, как данные двигаются от одной работы к другой. Это представление потоков совместно с хранилищами данных и внешними сущностями делает модели DFD более похожими на физические характеристики системы — движение данных, хранение данных, поставка и распространение данных (рис. 1.22).

Рис. 1.22 Пример DFD диаграммы

В отличие от IDEF0, где система рассматривается как взаимосвязанные работы, DFD система может рассматриваться как совокупность предметов. В этом случае функциональны блоки именуются по названию системы, например «Система обработки информации».

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

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

Альтернативным подходом является подход, популярный при создании программного обеспечения, называемый событийным разделением, в котором различные диаграммы DFD выстраивают модель системы. Во-первых, логическая модель строится как совокупность работ и документирования того, что они (эти работы) должны делать.

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

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

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