Добавлен: 15.11.2018
Просмотров: 1530
Скачиваний: 5
Рис. 19. Диаграмма дерева узлов
Для создания диаграммы дерева узлов следует выбрать в меню пункт Insert/Node Tree. Возникает диалог формирования диаграммы дерева узлов Node Tree Definition.
Каркас содержит заголовок (верхняя часть рамки) и подвал (нижняя часть). Заголовок каркаса используется для отслеживания диаграммы процессе моделирования. Нижняя часть используется для идентификации позиционирования в иерархии диаграммы.
Смысл элементов каркаса приведен в табл. 1.2 и 1.3.
Таблица 1.2. Поля заголовка каркаса (слева направо)
Поле
|
Смысл
|
||
Used At
|
Используется для указания на родительскую работу в случае, если на текущую диаграмму ссылались посредством стрелки вызова |
||
Autor, Date, Rev, Project
|
Имя создателя диаграммы, дата создания и имя проекта, в рамках которого была создана диаграмма. REV-дата последнего редактирования диаграммы |
||
Notes 12345678910
|
Используется при проведении сеанса экспертизы. Эксперт должен (на бумажной копии диаграммы) указать число замечаний, вычеркивая цифру из списка каждый раз при внесении нового замечания
|
||
Status
|
Статус отображает стадию создания диаграммы, отображая все этапы публикации
|
||
Working
|
Новая диаграмма, кардинально обновленная диаграмма или новый автор диаграммы
|
||
Draft
|
Диаграмма прошла первичную экспертизу и готова к дальнейшему обсуждению
|
||
Recommended
|
Диаграмма и все ее сопровождающие документы прошли экспертизу. Новых изменений не ожидается
|
||
Publication
|
Диаграмма готова к окончательной печати и публикации
|
||
Reader
|
Имя читателя (эксперта)
|
||
Date
|
Дата прочтения (экспертизы)
|
||
Context
|
Схема расположения работ в диаграмме верхнего уровня. Работа, являющаяся родительской, показана темным прямоугольником, остальные - светлым. На контекстной диаграмме (А-0) показывается надпись ТОР. В левом нижнем углу показывается номер по узлу родительской диаграммы: |
||
|
|
Таблица 1.3. Поля подвала каркаса (слева направо)
Поле
|
Смысл
|
Node
|
Номер узла диаграммы (номер родительской работы)
|
Title
|
Имя диаграммы. По умолчанию - имя родительской работы
|
Number
|
C-Number, уникальный номер версии диаграммы
|
Page
|
Номер страницы, может использоваться как номер страницы при формировании папки
|
Значения полей каркаса задаются в диалоге Diagram Properties (меню Edit/Diagram Properties) - рис. 21.
Рис. 21. Диалог Diagram Properties
Лабораторная работа N3
Задание. Продолжить построение модели для графического представления прецедентов, описанных в первой лабораторной работе. Выполнить слияние моделей двух прецедентов.
Внести замечания в диаграмму.
Теоретические сведения
1.2.7. Слияние и расщепление моделей
Возможность слияния и расщепления моделей обеспечивает коллективную работу над проектом. Так, руководитель проекта может создать декомпозицию верхнего уровня и дать задание аналитикам продолжить декомпозицию каждой ветви дерева в виде отдельных моделей. После окончания работы над отдельными ветвями все подмодели могут быть слиты в единую модель. С другой стороны, отдельная ветвь модели может быть отщеплена для использования в качестве независимой модели, для доработки или архивирования.
BPwin использует для слияния и разветвления моделей стрелки вызова.
Для слияния необходимо выполнить следующие условия:
• Обе сливаемые модели должны быть открыты в Bpwin.
• Имя модели-источника, которое присоединяют к модели-цели, должно совпадать с именем стрелки вызова работы в модели-цели (рис. 22).
• Стрелка вызова должна исходить из недекомпозируемой работы (работа должна иметь диагональную черту в левом верхнем углу) (рис. 23).
Имена контекстной работы подсоединяемой модели-источника и работы на модели-цели, к которой мы подсоединяем модель-источник, должны совпадать (рис. 22).
Модель-источник должна иметь по крайней мере одну диаграмму декомпозиции.
Рис. 22. Условия слияния моделей
Для слияния моделей нужно щелкнуть правой кнопкой мыши по работе со стрелкой вызова в модели-цели и во всплывающем меню выбрать пункт Merge Model.
Рис. 23. Стрелка вызова работы "Сборка изделия" модели-цели
Появляется диалог, в котором следует указать опции слияния модели (рис. 24). При слиянии моделей объединяются и словари стрелок и работ. В случае одинаковых определений возможна перезапись определений или принятие определений из модели-источника. То же относится к именам стрелок, хранилищам данных и внешним ссылкам. (Хранилища данных и внешние ссылки - объекты диаграмм потоков данных, DFD, будут рассмотрены ниже.)
7
Рис. 24. Диалог Continue with merge?
После подтверждения слияния (кнопка ОК) модель-источник подсоединяется к модели-цели, стрелка вызова исчезает, а работа, от которой отходила стрелка вызова, становится декомпозируемой - к ней подсоединяется диаграмма декомпозиции первого уровня модели-источника. Стрелки, касающиеся работы на диаграмме модели-цели, автоматически не мигрируют в декомпозицию, а отображаются как неразрешенные. Их следует тоннелировать вручную. На рис. 25 показано, как выглядят модели в окне Model Explorer после слияния.
В процессе слияния модель-источник остается неизменной и к модели-цели подключается фактически ее копия. Не нужно путать слияние моделей с синхронизацией. Если в дальнейшем модель-источник будет редактироваться, эти изменения автоматически не попадут в соответствующую ветвь модели-цели.
Разделение моделей производится аналогично. Для отщепления ветви от модели следует щелкнуть правой кнопкой мыши по декомпозированной работе (работа не должна иметь диагональной черты в левом верхнем углу) и выбрать во всплывающем меню пункт Split Model. В появившемся диалоге Split Options следует указать имя создаваемой модели. После подтверждения расщепления в старой модели работа станет недекомпозированной (признак - диагональная черта в левом верхнем углу), будет создана стрелка вызова, причем ее имя будет совпадать с именем новой модели, и. наконец, будет создана новая модель, причем имя контекстной работы будет совпадать с именем работы, от которой была "оторвана" декомпозиция.
Рис. 25. Модели после слияния
1.8. Рекомендации по рисованию диаграмм
В реальных диаграммах к каждой работе может подходить и от каждой может отходить около десятка стрелок. Если диаграмма содержит 6-8 работ, то она может содержать 30-40 стрелок, причем они могут сливаться, разветвляться и пресекаться. Такие диаграммы могут стать очень плохо читаемыми. В IDEF0 существуют соглашения по рисованию диаграмм, которые призваны облегчить чтение и экспертизу модели. Некоторые из этих правил BPwin поддерживает автоматически, выполнение других следует обеспечить вручную.
• Прямоугольники работ должны располагаться по диагонали с левого верхнего в правый нижний угол (порядок доминирования). При создании новой диаграммы декомпозиции BPwin автоматически располагает работы именно в таком порядке. В дальнейшем можно добавить новые работы или изменить расположение существующих, но нарушать диагональное расположение работ по возможности не следует. Порядок доминирования подчеркивает взаимосвязь работ, позволяет минимизировать изгибы и пересечения стрелок.
• Следует максимально увеличивать расстояние между входящими или выходящими стрелками на одной грани работы. Если включить опцию Line Drawing: Automatically space arrows на закладке Layout диалога Model Properties (меню Edit/Model Properties), BPwin будет располагать стрелки нужным образом автоматически.
Следует максимально увеличить расстояние между работами, поворотами и пересечениями стрелок. Если две стрелки проходят параллельно (начинаются из одной и той же грани одной работы и заканчиваются на одной и той же грани другой работы), то по возможности следует их объединить и назвать единым термином.
Обратные связи по входу рисуются "нижней" петлей, обратная связь по управлению - "верхней". BPwin автоматически рисует обратные связи нужным образом. Его можно "обмануть", но лучше этого не делать.
Циклические обратные связи следует рисовать только в случае крайней необходимости, когда подчеркивают значение повторно используемого объекта. Принято изображать такие связи на диаграмме декомпозиции. BPwin не позволяет создать циклическую обратную связь за один прием. Если все же необходимо изобразить такую связь, следует сначала создать обычную связь по входу, затем разветвить стрелку, направить новую ветвь обратно ко входу работы-источника и, наконец, удалить старую ветвь стрелки выхода (рис. 26).
Рис. 26. Пример обратной циклической связи
Следует минимизировать число пересечений, петель и поворотов стрелок. Это ручная и, в случае насыщенных диаграмм, творческая работа (рис. 27).
Рис. 27. Минимизация пересечений и поворотов стрелок
Если нужно изобразить связь по входу, необходимо избегать "нависания" работ друг над другом. В этом случае BPwin изображает связи по входу в виде петли, что затрудняет чтение диаграмм (рис. 28).
Рис. 28. Пример правильного (справа) и неправильного (слева) расположения работ при изображении связи по входу
1.9. Проведение экспертизы
Цикл автор-читатель. Цикл автор-читатель предназначен для обеспечения обратной связи при построении модели. Он включает определенные формализованные процедуры, предписывающие правила координации деятельности участников создания модели. В работе над моделью принимают участие специалисты разных специальностей - аналитики (авторы), эксперты предметной области (читатели), библиотекари и комитет технического контроля. Обычно библиотекарь выделяется для больших проектов. Цикл автор-читатель содержит следующие этапы:
На очередном этапе декомпозиции аналитик создает диаграмму на основе общих знаний, анализа документации и опроса экспертов. Общие знания не позволяют создать диаграмму достаточно корректно, поэтому она нуждается в уточнении и дополнении.
Все коммуникации при создании модели контролируются библиотекарем. Он ответственен за прохождение папок и архивирование диаграмм модели. После создания диаграмма посылается библиотекарю для помещения в архив.
Автором формируется папка и передается для распространения библиотекарю (одна копия направляется автору). В папку должна входить текущая диаграмма. Кроме того, в папку могут включаться сопутствующие отчеты, в том числе словарь стрелок и работ, диаграмма верхнего уровня, дерево узлов и любая необходимая дополнительная документация. На папке регистрируются входящие данные - дата, автор, данные читателя и т. д., после чего папка направляется эксперту предметной области (читателю).
Читатель рецензирует папку и записывает свои комментарии. Замечания вносятся в диаграмму по определенным правилам. Если читатель решил внести замечание, он должен указать номер замечания, затем внести текст замечания и в каркасе диаграммы в разделе Notes зачеркнуть цифру, соответствующую номеру замечания (рис. 29).
Рис. 29. Внесение замечаний в диаграмму
После рецензирования папки возвращаются библиотекарю. Библиотекарь должен обеспечивать проведение рецензирования в срок. Затем папки регистрируются и направляются автору. Автор вносит ответ на замечания и, если он согласен с замечаниями, вносит изменения в модель. На практике зачастую сеанс экспертизы проводится в форме устного собеседования между автором и экспертом. В этом случае особенно важно вносить замечания эксперта и комментарии автора в диаграмму для документирования всех идей, возникших в результате моделирования.
Если это необходимо, проводится дополнительная экспертиза у того же или у другого эксперта. После прохождения нескольких циклов число замечаний обычно уменьшается и диаграмма становится стабильной. В процессе изменения диаграмма может менять свой статус, который должен быть отражен в каркасе (см. табл. 1.2). Когда автор считает, что диаграмма уже достаточно проработана и достигла уровня "Recommended", он пересылает ее на утверждение в комитет технического контроля, где она проходит окончательную экспертизу. После внесения замечаний и окончательных изменений диаграмма (или набор диаграмм) окончательно утверждается, получает статус "Publication" и может быть распечатана и распространена среди участников проекта.
2. Создание отчетов в BPwin
BPwin имеет мощный инструмент генерации. Отчеты по модели вызываются из пункта меню Report. Всего имеется семь типов отчетов;
1. Model Report. Этот отчет уже упоминался в 1.1. Он включает информацию о контексте модели - имя модели, точку зрения, область, цель, имя автора, дату создания и др.
2. Diagram Report. Отчет по конкретной диаграмме. Включает список объектов (работ, стрелок, хранилищ данных, внешних ссылок и т. д.).
3. Diagram Object Report. Наиболее полный отчет по модели. Может включать полный список объектов модели (работ, стрелок с указанием их типа и др.) и свойства, определяемые пользователем.
4. Activity Cost Report. Отчет о результатах стоимостного анализа. Будет рассмотрен ниже.
5. Arrow Report. Отчет по стрелкам. Может содержать информацию из словаря стрелок, информацию о работе-источнике, работе-назначении стрелки и информацию о разветвлении и слиянии стрелок.
6. DataUsage Report. Отчет о результатах связывания модели процессов и модели данных. (Будет рассмотрен ниже.)
7. Model Consistency Report. Отчет, содержащий список синтаксических ошибок модели.
Синтаксические ошибки IDEF0 с точки зрения BPwin разделяются на три типа:
• Во-первых, это ошибки, которые BPwin выявить не в состоянии. Например, синтаксис IDEF0 требует, чтобы имя работы было выражено отглагольным существительным или глагольной формой, выражающей действие ("Изготовление изделия", "Обслуживание клиента", "Выписка счета" и т. д.), а имя стрелки также должно быть выражено существительным. BPwin не позволяет анализировать синтаксис естественного языка (английского и русского) и смысл имен объектов и поэтому игнорирует ошибки этого типа. Выявление таких ошибок - ручная работа, которая ложится на плечи аналитиков и должна контролироваться руководителем проекта.
• Ошибки второго типа BPwin просто не допускает. Например, каждая грань работы предназначена для определенного типа стрелок. BPwjn просто не позволит создать на диаграмме IDEF0 внутреннюю стрелку, выходящую из левой грани работы л входящую в правую грань.
• Третий тип ошибок BPwin позволяет допустить, но детектирует их. Полный их список можно получить в отчете Model Consistency Report.