ВУЗ: Не указан

Категория: Методичка

Дисциплина: Проектирование информационных систем

Добавлен: 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.