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

Для дополнения модели IDEFO диаграммой DFD нужно в процессе декомпозиции в диалоге Activity Box Count указать тип диаграммы DFD (рисунок 25).

Рисунок 25 – Диалог Activity Box Count

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

Рисунок 26 – DFD-декомпозиция работы «Выполнение запроса»

Согласно описанию системы проведем декомпозицию полученных блоков (рисунки 26– 29).

Рисунок 26 – Декомпозиция работы «Обработать запрос студента»

Рисунок 27 – Декомпозиция работы «Обработать запрос декана»

Рисунок 28 – Декомпозиция работы «Обработать запрос фирмы»

Рисунок 29 – Декомпозиция работы «Обработать запрос эксперта»

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

Проведем анализ полученных диаграмм. Рассматривая диаграмму, изображенную на рисунке 30, необходимо отметить наличие в ней лишнего блока «Обработать запрос администратора». При составлении первого варианта диаграммы работы были определены исходя из категорий пользователей. Это привело к возникновению конфликта с функциями системы и с точкой зрения на модель. Администратор не обслуживается системой как обычный клиент, он обеспечивает ее мониторинг. Администратор может добавлять пароли, изменять уровень доступа в систему, добавлять нового пользователя и т. д. С точки зрения клиента системы, деятельность администратора является второстепенной, поэтому на всех диаграммах отсутствует описание функций администратора, представляя его влияние как «механизм» для других функций. Поэтому принимаем решение удалить работу «Обработать запрос администратора».

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

Рисунок 30 – Декомпозиция работы «Обработать запрос студента» (вариант 2)

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

Рисунок 31 – Декомпозиция работы «Обработать запрос декана» (вариант 2)

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

Помимо указанных недостатков, диаграмма «Обработать запрос фирмы» имеет еще несколько. Можно объединить работы «Составить приглашение» и «Отослать студенту» в одну работу «Составить и отослать приглашение», упростив диаграмму.

Рисунок 32 – Декомпозиция работы «Обработать запрос фирмы» (вариант 2)

Рисунок 33 – Декомпозиция работы «Обработать запрос эксперта» (вариант 2)

Рисунок 34 – DFD-декомпозиция работы «Выполнение запроса» (вариант 3)

Диаграмма дерева узлов

Диаграмма дерева узлов показывает иерархию работ в модели и позволяет рассмотреть всю модель целиком, но не показывает взаимосвязи между процессами (стрелки) (рисунок 35). Чтобы не запутаться и проверить способ декомпозиции, следует после каждого изменения создавать диаграмму дерева узлов. BPwin имеет инструмент навигации по модели – Model Explorer, который позволяет представить иерархию работ и диаграмм в удобном и компактном виде. 

Рисунок 35 - Диаграмма дерева узлов

Для создания диаграммы дерева узлов следует выбрать в меню пункт Insert/Node Tree. Возникнет диалог формирования диаграммы дерева узлов Node Tree Definition (рисунок 36).

Рисунок 36 — Диалог настройки диаграммы дерева узлов

В диалоге Node Tree Definition следует указать глубину дерева – Number of Levels (по умолчанию 3) и корень дерева (по умолчанию – родительский процесс текущей диаграммы). По умолчанию нижний уровень декомпозиции показывается в виде списка, остальные процессы – в виде прямоугольников. Для отображения всего дерева в виде прямоугольников следует выбрать опцию Bullet Last level. Чтобы все прямоугольники были одного размера, следует выбрать All one size. При создании дерева узлов следует указать имя диаграммы Diagram Name.

Слияние и расщепление моделей

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

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

1. Обе сливаемые модели должны быть открыты в BPwin. 

2. Имя модели-источника, которое присоединяют к модели-цели, должно совпадать с именем стрелки вызова процесса в модели-цели. 

3. Стрелка вызова должна исходить из не декомпозируемого процесса (процесс должен иметь диагональную черту в левом верхнем углу). 

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

Рисунок 37 - Условия слияния моделей

Для слияния моделей нужно:

1. Щёлкнуть правой кнопкой мыши на процессе со стрелкой вызова в модели-цели и во всплывающем меню выбрать пункт Merge Model. 

2. В появившемся меню указать опции слияния модели (рисунок 38). 

Рисунок 39 - Диалог «Продолжить соединение моделей?»

После подтверждения слияния (кнопка OK) модель-источник присоединяется к модели-цели, стрелка вызова исчезает, а процесс, от которого отходила стрелка вызова, становится декомпозируемым – к нему подсоединяется диаграмма декомпозиции первого уровня модели-источника. Стрелки, касающиеся процесса на диаграмме модели-цели, автоматически не мигрируют в декомпозицию, а отображаются как неразрешенные. Их следует туннелировать вручную. На рисунке 38 показано, как выглядят модели в окне Model Explorer после слияния.

Рисунок 40 - Вид моделей в Model Explorer после слияния.

Выделены модель-источник и присоединенная ветвь модели-цели.

Разделение моделей производится аналогично. Для отщепления ветви от модели следует щелкнуть правой кнопкой мыши по декомпозированному процессу (процесс не должен иметь диагональной черты в левом верхнем углу) и выбрать во всплывающем меню пункт Split Model. В появившемся диалоге Split Options следует указать имя создаваемой модели.