Состав функциональной модели

 

Результатом применения методологии SADT является модель, которая состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга. Диаграммы – главные компоненты модели, все функции системы и интерфейсы на них представлены как блоки и дуги. Место соединения дуги с блоком определяет тип интерфейса. Управляющая информация входит в блок сверху, в то время как информация, которая подвергается обработке, показана с левой стороны блока, а результаты выхода показаны с правой стороны. Механизм (человек или автоматизированная система), который осуществляет операцию, представляется дугой, входящей в блок снизу (рисунок 1).

 

 

 

Рисунок 1 – Функциональный блок и интерфейсные дуги

 

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

Построение SADT-диаграммы заключается в выполнении следующих действий:

1. Сбор информации об объекте моделирования и определение его границ.

2. Определение цели и точки зрения.

3. Построение и декомпозиция диаграмм.

4. Критическая оценка, рецензирование и комментирование.

Построение SADT-модели начинается с представления всей системы в виде простейшей компоненты – одного блока и дуг, изображающих интерфейсы с функциями вне системы, это, так называемая, контекстная диаграмма. Поскольку единственный блок представляет всю систему как единое целое, имя, указанное в блоке, является общим. Это верно и для интерфейсных дуг – они также представляют полный набор внешних интерфейсов системы в целом. Затем блок, который представляет систему в качестве единого модуля, детализируется на другой диаграмме с помощью нескольких блоков, соединенных интерфейсными дугами. Эти блоки представляют основные подфункции исходной функции. Обычно, для достижения наглядности диаграмма ограничивается 3-6 блоками и детализация осуществляется постепенно. Данная декомпозиция выявляет полный набор подфункций, каждая из которых представлена как блок, границы которого определены интерфейсными дугами. Каждая из этих подфункций может быть декомпозирована подобным образом для более детального представления.

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

Таким образом, модель SADT представляет собой серию диаграмм с сопроводительной документацией, разбивающих сложный объект на составные части, которые представлены в виде блоков. Детали каждого из основных блоков показаны в виде блоков на других диаграммах. Каждая детальная диаграмма является декомпозицией блока из более общей диаграммы. На каждом шаге декомпозиции более общая диаграмма называется родительской для более детальной диаграммы. Дуги, входящие в блок и выходящие из него на диаграмме верхнего уровня, являются точно теми же самыми, что и дуги, входящие в диаграмму нижнего уровня и выходящие из нее, потому что блок и диаграмма представляют одну и ту же часть системы (см. рисунок 2) [2].

 

 

Рисунок 2 – Структура SADT-модели. Декомпозиция диаграмм

 

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

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

Рисунок 3 ­– Пример обратной связи

 

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

 

 

Рисунок 4 – Пример механизма

 

Каждый блок на диаграмме имеет свой номер. Для того, чтобы указать положение любой диаграммы или блока в иерархии, используются номера диаграмм. Например, А21 является диаграммой, которая детализирует блок 1 на диаграмме А2. Аналогично, А2 детализирует блок 2 на диаграмме А0, которая является самой верхней диаграммой модели.

Одним из важных моментов при проектировании ИС с помощью методологии SADT является точная согласованность типов связей между функциями.

 

3. СОЗДАНИЕ ФУНКЦИОНАЛЬНОЙ МОДЕЛИ В BP-WIN

Для проведения анализа и реорганизации бизнес-процессов фирма PLATINUM technology предлагает САSЕ-средство BP-win, поддерживающее методологии IDEF0 (функциональная модель), IDEF3 (Work Flow Diagram) и DFD (Data Flow Diagram). При написании данного раздела испльзовались монографии [3, 4].

На рисунке 5 и в таблице 1 приведена основная панель инструментов BP-winи описание содержащихся на ней элементов управления.

 

 

Рисунок 5 – Основная панель инструментов BP-win

Таблица 1 – Описание элементов управления панели инструментов

Соответствующий пункт меню	Описание
File/New	Создать новую модель
File/Open	Открыть модель
File/Save	Сохранить модель
File/Print	Напечатать модель
View/Zoom	Выбор масштаба
View/Zoom	Масштабирование
Tools/Spelling	Проверка правописания
View/Model Explorer	Отображать навигатор модели
ModelMart	Отображать панель ModelMart

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

 

Рисунок 6 – Диалог создания модели

 

В BP-win возможно построение смешанных моделей, т. е. модель, может со­держать одновременно как диаграммы IDEF0, так и IDEF3 и DFD. Состав палитры инструментов изменяется автоматически, когда происходит пере­ключение с одной нотации на другую.

В начале работы с пакетом необходимо выбрать типы и размер шрифтов, особенно это важно при необходимости использования русского языка в моделях (обычно используется шрифт Courier New). Для этого следует воспользоваться меню Tools\Default Fonts, после чего появляется каскадное меню, каждый пункт которого служит для установки шрифтов для определенного типа объектов:

Context Activity - работы на контекстной диаграмме;

Context Arrow - стрелки на контекстной диаграмме;

Decomposition Activity - работы на диаграмме декомпозиции;

Decomposition Arrow - стрелки на диаграмме декомпозиции;

Node Tree text - текст на диаграмме дерева узлов;

Frame User Text- текст, вносимый пользователем в каркасе диаграмм;

Frame System Text - системный текст в каркасе диаграмм;

Text Blocks - текстовые блоки;

Parent Diagram Text - текст родительской диаграммы;

Parent Diagram Title Text - текст заголовка родительской диаграммы;

Report Text - текст отчетов.

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

Под субъектом понимается сама система, при этом необходимо точно установить, что входит в систему, а что лежит за ее пределами, другими словами, мы должны определить, что будет рассматриваться как компоненты системы, а что как внешнее воздействие. На опреде­ление субъекта системы будет существенно влиять позиция, с которой рас­сматривается система, и цель моделирования - вопросы, на которые по­строенная модель должна дать ответ. Другими словами, первоначально не­обходимо определить область (Scope) моделирования.

Цель моделирования (Purpose). Модель не может быть построена без чет­ко сформулированной цели. Цель должна отвечать на следующие вопросы:

• Почему этот процесс должен быть смоделирован?

• Что должна показывать модель?

Формулировка цели позволяет команде аналитиков сфокусировать уси­лия в нужном направлении. Примерами формулирования цели могут быть следующие утверждения: "Иденти­фицировать роли и ответственность служащих для написания должностных инструкций", "Описать функциональность предприятия с целью написания спецификаций информационной системы".

Хотя при построении модели учитываются мнения различных людей, модель должна строиться с единой точки зрения. Точку зрения (Viewpoint) можно представить как взгляд человека, который видит систему в нужном для моделирования аспекте. Точка зрения должна соответствовать цели моделирования. Очевидно, что описание работы предприятия с точки зрения финансиста и технолога будет выглядеть совершенно по-разному, поэтому в течение моделирования важно оставаться на выбранной точке зрения. Как правило, выбирается точка зрения человека, ответствен­ного за моделируемую работу в целом.

Для внесе­ния области, цели и точки зрения в модели IDEF0 в BP-win следует выбрать пункт меню Edit\Model Properties, вызывающий диалог Model Properties (рисунок 7). В закладке Purpose следует внести цель и точку зрения, а в за­кладку Definition - определение модели (Definition) и описание границы области модели (Scope).

В закладке Status того же диалога можно описать статус модели (черновой вариант (Draft), рабочий (Working), рекомендуемый (Recommended), для публикации (Publication) или другое (Other)), время создания (Creation Data) и последнего редактирования (User last revision data), отслеживаемая в дальнейшем автоматически по системной дате. В закладке Source описываются источники информации для построе­ния модели (например, "Опрос экспертов предметной области и анализ документации").

Закладка General служит для внесения имени модели (Model Name) и проекта (Project), имени и инициалов автора (Author и Author Initials), а также временных рамок модели ­– AS-IS и ТО-ВЕ. Обычно сначала строится модель существую­щей организации работы, “как есть” (AS-IS). Модель AS-IS позволяет выяснить, "что мы делаем сегодня" перед тем, как перепрыг­нуть на то, "что мы будем делать завтра". Анализ функциональной модели позволяет понять, где находятся наиболее слабые места, в чем будут состо­ять преимущества новых бизнес-процессов и насколько глубоким измене­ниям подвергнется существующая структура организации бизнеса.

 

 

Рисунок 7 – Диалог задание свойства модели

 

Найденные в модели AS-IS недостатки можно исправить при созда­нии модели “как будет” (ТО-ВЕ) – модели новой организации бизнеспроцессов. Модель ТО-ВЕ нужна для анализа альтернативных (лучших) пу­тей выполнения работы.

Технология проектирования информационных систем обычно подразумевает сначала создание модели AS-IS, ее анализ и улучшение бизнес-процессов, т. е. создание модели ТО-ВЕ, а затем на основе модели ТО-ВЕ построение модели данных, прототип и окончательного варианта системы.

Результат описания модели можно получить в отчете Model Report. Диа­лог настройки отчета по модели вызывается из пункта меню Report\Model Report. В диалоге настройки следует выбрать необходимые поля, при этом автоматически отображается очередность вывода информации в отчет (рисунок 8).

 

 

Рисунок 8 – Отчет по модели

 

Модель может содержать четыре типа диаграмм:

• контекстную диаграмму (в каждой модели может быть только одна контекстная диаграмма);

• диаграммы декомпозиции;

• диаграммы дерева узлов;

• диаграммы только для экспозиции (FEO).

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

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

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

Работы обозначают поименованные процессы, функции или задачи, которые происходят в течение определенного времени и имеют распознаваемые результаты. Работы изображаются в виде прямоугольников. Все работы должны быть названы и определены. Имя работы должно быть выражено отглагольным существительным, обозначающим действие (например, "Изготовление детали", "Прием заказа" и т. д.). Работа "Изготовление детали" может иметь, например, следующее определение: "Работа относится к пол­ному циклу изготовления изделия от контроля качества сырья до отгрузки готового упакованного изделия". При создании новой модели (меню File\New) автоматически создается контекстная диаграмма с единственной работой, изображающей систему в целом (рисунок 9).

 

 

Рисунок 9 – Пример контекстной диаграммы

 

Для внесения имени работы следует щелкнуть по работе правой кноп­кой мыши, выбрать в меню Name Editor и в появившемся диалоге внести имя работы. Для описания других аспектов контекста служит диалог Model Properties (рисунок 10).

 

 

Рисунок 10 – Редактор задания свойств работы

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

Возникает диалог Activity Box Count (рисунок 11), в котором следует ука­зать нотацию новой диаграммы и количество работ на ней. Остановимся на нотации IDEF0 и щелкнем на ОК.

 

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

 

Появляется диаграмма декомпо­зиции (рисунок 12). Допустимый интервал числа работ 2-8. (диаграммы с количеством работ более восьми получаются перенасыщенными и плохо читаются). Для обес­печения наглядности и лучшего понимания моделируемых процессов реко­мендуется использовать от трех до шести блоков на одной диаграмме.

 

 

Рисунок 12 – Пример диаграммы декомпозиции

 

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

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

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

Взаимодействие работ с внешним миром и между собой описывается в виде стрелок. Стрелки представляют собой некую информацию и именуются существительными (например: "Заготовка". "Изделие". "Заказ).

В IDEF0 различают пять типов стрелок:

Вход (Input) - материал или информация, которые используются или преобразуется работой дня получения результата (выхода). Допускается, что работа может не иметь ни одной стрелки входа. Каждый тип стрелок под­ходит к определенной стороне прямоугольника, изображающего работу, или выходит из нее. Стрелка входа рисуется как входящая в левую грань работы. При описании технологических процессов (для этого и был приду­ман IDEF0) не возникает проблем определения входов. Действительно, "Сырье" на рисунке 12 – это нечто, что перерабатывается в процессе "Изготовление изделия" для получения результата. При моделировании информационных систем, когда стрелками являются не физические объекты, а данные, не все так очевидно. Например, при "Приеме пациента"карта пациента может быть и на входе и на выходе, между тем качество этих данных меняется. Другими словами, в нашем примере для того, чтобы оправдать свое назна­чение, стрелки входа и выхода должны быть точно определены с тем, чтобы указать на то, что данные действительно были переработаны (например, на выходе - " Заполненная карта пациента "). Очень часто сложно определить, являются ли данные входом или управлением, В этом случае подсказкой может служить то, перерабатываются / изменяются ли данные в работе или нет. Если изменяются, то, скорее всего, это вход, если нет – управление.

Управление (Control) - правила, стратегии, процедуры или стандарты, которыми руководствуется работа. "Каждая работа должна иметь хотя бы одну стрелку управления. Стрелка управления рисуется как входящая в верхнюю грань работы. На рисунке 9 стрелки " Задание " и " Чертеж "- управ­ление для работы " Изготовление изделия ". Управление влияет на работу, но не преобразуется работой. В случае возникновения неопределенности в статусе стрелки (управление или вход) рекомендуется рисовать стрелку управления.

Выход (Output) - материал или информация, которые производятся ра­ботой. Каждая работа должна иметь хотя бы одну стрелку выхода. Работа без результата не имеет смысла и не должна моделироваться. Стрелка вы­хода рисуется как исходящая из правой грани работы. На рисунке 9 стрелка " Готовое изделие " является выходом для работы " Изготовление изделия ".

Механизм (Mechanism) - ресурсы, которые выполняют работу, например персонал предприятия, станки, устройства и т. д. Стрелка механизма рису­ется как входящая в нижнюю грань работы. На рисунке 9 стрелка " Персонал предприятия " является механизмом для работы " Изготовление изделия ", По усмотрению аналитика стрелки механизма могут не изображаться в модели.

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

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

Для внесения граничной стрелки входа надо: щелкнуть по кнопке с символом стрелки в палитре инструментов следует перенести курсор к левой стороне эк­рана, пока не появится начальная штриховая полоска:

щелкнуть один раз по полоске (откуда выходит стрелка) и еще раз в левой части работы со стороны входа (где заканчивается стрелка);

вернуться в палитру инструментов и выбрать опцию редактирования стрелки , щелкнуть правой кнопкой мыши на линии стрелки, во всплывающем меню выбрать Name Editor и добавить имя стрелки в закладке Name диалога IDEF0 Arrow Properties (рисунок 13).

 

 

Рисунок 13 – Диалог IDEF0 Arrow Properties

 

Стрелки управления, входа, механизма и выхода изображаются ана­логично. Для рисования стрелки выхода, например, следует щелкнуть по кнопке с символом стрелки в палитре инструментов, щелкнуть в правой части работы со стороны выхода (где начинается стрелка), перенести курсор к правой стороне экрана, пока не появится начальная штриховая по­лоска, и щелкнуть один раз по штриховой полоске.

Имена вновь внесенных стрелок автоматически заносятся в словарь стрелок (Arrow Dictionary).

Словарь стрелок редактируется при помощи специального редакторе Arrow Dictionary Editor, доступном в меню Editor / Arrow Dictionary в котором определяется стрелка и вносится относящийся к ней комментарий (рисунок 14).

 

 

Рисунок 14 – Словарь стрелок

 

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

Содержимое словаря стрелок можно распечатать в виде отчета (меню Report \ Arrow Report…) и получить тем самым толковый словарь термине предметной области, использующихся в модели.

Рассмотрим несвязанные граничные стрелки (unconnected border arrow). При декомпозиции работы входящие в нее и исходящие из нее стрелки (кроме стрелки вызова) автоматически появляются на диаграмме декомпозиции (миграция стрелок), но при этом не касаются работ. Такие стрелки называются несвязанными и воспринимаются в BP-win как синтаксическая ошибка.

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

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

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

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

Смысл разветвляющихся и сливающихся стрелок передается именова­нием каждой ветви стрелок, существуют определенные правила именова­ния таких стрелок. Рассмотрим их на примере разветвляющихся стрелок. Если стрелка именована до разветвления, а после разветвления ни одна из ветвей не именована, то подразумевается, что каждая ветвь моделирует те же данные или объекты, что и ветвь до разветвления (рисунок 15).

 

 

Рисунок 15 – Пример именования разветвляющейся стрелки

 

Если стрелка именована до разветвления, а после разветвления какая-то из ветвей не именована, то подразумевается, что эти ветви соответствует именованию. Если при этом какая-либо ветвь после разветвления осталась неименованной, то подразумевается, что она моделирует те же данные или объекты, что и ветвь до разветвления (рисунок 16).

 

 

Рисунок 16 – Другой пример именования разветвляющейся стрелки

 

Недопустима ситуация, когда стрелка до разветвления не именована, а после разветвления не именована какая-либо из ветвей. BP-win определяет такую стрелку как синтаксическую ошибку (рисунок 17).

 

 

Рисунок 17 – Пример неверного именования разветвляющейся стрелки

 

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

Тоннелирование стрелок. Вновь внесенные граничные стрелки на диаграмме декомпозиции нижнего уровня изображаются в квадратных скобках и автоматически не появляются на диаграмме верхнего уровня (рисунок 18).

 

Рисунок 18 – Неразрешенная (Unresolved) стрелка

Для их “перетаскивания” наверх нужно сначала выбрать кнопку на палитре инструментов и щелкнуть по квадратным скобкам граничной стрелки. Появляется диалог Border Arrow Editor (рисунок 19).

 

 

Рисунок 19 – Диалог Border Arrow Editor

 

Если щелкнуть по кнопке Resolve Border Arrow, стрелка мигрирует на диаграмму верхнего уровня, если по кнопке Change To Tunnel - стрелка будет затоннелирована и не попадет на другую диаграмму. Тоннельная стрелка изображается с круглыми скобками на конце (рисунок 20).

Рисунок 20 – Тоннельная стрелка

 

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

Другим примером тоннелирования может быть ситуация, когда стрелка механизма мигрирует с верхнего уровня на нижний, причем на нижнем уровне этот механизм используется одинаково во всех работах без исклю­чения. В этом случае стрелка механизма на нижнем уровне может быть удалена, после чего на Родительской диаграмме она может быть затоннелирована, а в коммента­рии к стрелке или в словаре можно указать, что механизм будет использоваться во всех работах дочерней диаграммы декомпозиции. Такое тоннелирование называется "не-в-дочсрней-работе"

Диаграмма дерева узлов показывает иерархию работ в модели и позво­ляет рассмотреть всю модель целиком, но не показывает взаимосвязи меж­ду работами (стрелки) (рисунок 21). Процесс создания модели работ является итерационным, следовательно, работы могут менять свое расположение в дереве узлов многократно. Чтобы не запутаться и проверить способ деком­позиции, следует после каждого изменения создавать диаграмму дерева узлов. Впрочем, BP-win имеет мощный инструмент навигации по модели – Model Explorer, который позволяет представить иерархию работ и диаграмм в удобном и компактном виде, однако этот инструмент является состав­ляющей стандарта IDEF0.

 

 

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

 

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

 

 

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

 

В диалоге Node Tree Definition следует указать глубину дерева Number of Levels (по умолчанию 3) и корень дерева (по умолчанию - родительская работа текущей диаграммы). По умолчанию нижний уровень декомпозиции показывается в виде списка, остальные работы - в виде прямоугольнике. Для отображения всего дерева в виде прямоугольников следует выбор; опцию Bullet Last Levels. При создании дерева узлов следует указать имядиаграммы, поскольку, если в нескольких диаграммах в качестве корня дерева узлов использовать одну и ту же работу, все эти диаграммы получают одинаковый номер (номер узла + постфикс N. например А0М) и в списке открытых диаграмм (пункт меню Window) их можно будет различить только по имени.

Диаграммы "только для экспозиции" (FEO) часто используются в модели для иллюстрации других точек зрения, для отображения отдельных дет лей, которые не поддерживаются явно синтаксисом IDEF0. Диаграмм FEO позволяют нарушить любое синтаксическое правило, поскольку сути являются просто картинками - копиями стандартных диаграмм и включаются анализ синтаксиса. Например, работа на диаграмме FEO может не иметь стрелок управления и выхода. С целью обсуждения определенных аспектов модели с экспертом предметной области может быть создана диаграмма только с одной работой и одной стрелкой, поскольку стандартная диаграмма декомпозиции содержит множество деталей, не относя­щихся к теме обсуждения и дезориентирующих эксперта. Но если FEO ис­пользуется для иллюстрации альтернативных точек зрения (альтернативный контекст), рекомендуется все-таки придерживаться синтаксиса IDEF0. Для создания диаграммы FEO следует выбрать пункт меню Insert\FEO Diagram. В возникающем диалоге Create New FEO Diagram следует указать имя диаграммы FEO и тип родительской диаграммы (рисунок 23).

 

 

Рисунок 23 ­– Диалог создания FEO-диаграммы

 

Новая диаграмма получает номер, который генерируется автоматически (номер родительской диаграммы по узлу + постфикс F, например AIF).

На рисунке 12 показан типичный пример каркаса диаграммы декомпозиции.

Каркас содержит заголовок (верхняя часть рамки) и подвал (нижняя часть). Заголовок каркаса используется для отслеживания диаграммы в процессе моделирования. Нижняя часть используется для идентификации позиционирования в иерархии диаграммы.

Смысл элементов каркаса приведен в таблице 2.

Таблица 2 – Поля заголовка каркаса диаграммы

 

Поле	Смысл
Used At	Используется для указания на родительскую работу в случае, если на текущую диаграмму ссылались посредством стрелки вызова
Author, Date, Project, Rev	Имя создателя диаграммы, дата создания и имя проекта, в рамках которого была создана диаграмма. Дата последнего редактирования диаграммы.
Notes 1 2 3 4 5 6 7 8 9 10	Используется при проведении сеанса экспертизы. Эксперт должен на бумажной копии диаграммы указать число замечаний, вычеркивая число из списка каждый раз при внесении нового замечания
Status	Статус диаграммы, отражающий стадию ее создания
Working	Новая диаграмма
Draft	Диаграмма прошла первичную экспертизу
Recommended	Диаграмма прошла полную экспертизу
Publication	Диаграмма готовится к публикации
Data	Дата экспертизы
Context	Схема расположения работ в диаграмме верхнего уровня и родительская работа (закрашена)
Node	Номер узла диаграммы (родительской работы)
Title	Имя диаграммы (по умолчанию имя родительской работы)
Numbers	Номер версии диаграммы
Page	Номер страницы

 

Значение полей каркаса задаются в диалоге Diagram Properties (меню Edit\Diagram Properties) рисунок 24.

 

 

 

Рисунок 24 – Диалог Diagram Properties

Рекомендации по рисованию диаграмм. В реальных диаграммах к каждой работе может подходить и от каждой может отходить около десятка стрелок. Если диаграмма содержит 6-8 работ, то она может содержать 30-40 стрелок, причем они могут сливаться, раз­ветвляться и пресекаться. Такие диаграммы могут стать очень плохо читае­мыми. В IDEF0 существуют соглашения, но рисованию диаграмм, которые, признаны облегчить чтение и экспертизу модели. Некоторые из этих пра­вил BP-win поддерживает автоматически, выполнение других следует обес­печить вручную.

- Прямоугольники работ должны располагаться по диагонали с левого верхнего в правый нижний угол (порядок доминирования). При созда­нии новой диаграммы декомпозиции BP-win автоматически располагает работы именно в таком порядке. В дальнейшем можно добавить новые работы или изменить расположение существующих, но нарушать диаго­нальное расположение работ по возможности не следует. Порядок до­минирования подчеркивает взаимосвязь работ, позволяет минимизиро­вать изгибы и пересечения стрелок.

- Следует максимально увеличивать расстояние между входящими или выходящими стрелками на одной грани работы. Если включить опцию Line Drawing: Automatically space arrows на закладке Layout диалога Model Properties (меню Edit\Model Properties), BP-win будет располагать стрелки нужным образом автоматически.

- Следует максимально увеличить расстояние между работами, поворотами и пересечениями стрелок.

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

- Обратные связи по входу рисуются "нижней" петлей, обратная связь по управлению - "верхней". BP-win автоматически рисует обратные связи нужным образом.

- Циклические обратные связи следует рисовать только в случае крайней необходимости, когда подчеркивают значение повторно используемо объекта. BP-win не позволяет создать циклическую обратную связь за один прием. Если все же необходимо изобразить такую связь, следует сначала создать обычную связь по входу, затем разветвить стрелку, направить новую ветвь обратно к входу работы-источника и, наконец, удалить старую ветвь стрелки выхода (рисунок 25).

- Следует минимизировать числопересечений, петель и поворотов стрелок.

 

 

Рисунок 25 – Пример обратной циклической связи

 

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

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

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

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

Читатель рецензирует папку и записывает свои комментарии. Замечания вносятся и диаграмму по определенным правилам. Если читатель решил внести замечание, он должен указать номер замечания, затем внести текст замечания и в каркасе диаграммы в разделе Notes зачеркнуть цифру, соответствующую номеру замечания.

После рецензирования папки возвращаются библиотекарю. Библиоте­карь должен обеспечивать проведение рецензирования в срок. Затем папки регистрируются и направляются автору.

Автор вносит ответ на замечания и, если он согласен с замечаниями, вносит изменения в модель. На практике зачастую сеанс экспертизы про­водится в форме устного собеседования между автором и экспертом. В этом случае особенно важно вносить замечания эксперта и комментарии автора в диаграмму для документирования всех идей, возникших в резуль­тате моделирования.

Если это необходимо, проводится дополнительная экспертиза у того же или у другого эксперта.

После прохождения нескольких циклов число замечаний обычно уменьшается, и диаграмма становится стабильной. В процессе изменения диаграмма может менять свой статус, который должен быть отражен в кар­касе (см. таблица 2). Когда автор считает, что диаграмма уже достаточно проработана и достигла уровня "Recommended", он пересылает ее на ут­верждение в комитет технического контроля, где она проходит окончатель­ную экспертизу. После внесения замечаний и окончательных изменений диаграмма (или набор диаграмм) окончательно утверждается, получает ста­тус "Publication" и может быть распечатана и распространена среди участ­ников проекта.

Процесс создания SADT модели можно отразить на функциональной диаграмме [1].

 

 

Рисунок 25 – Процесс создания SADT-модели

Создание отчетов в BP-win. BP-win имеет мощный инструмент генерации отчетов. Отчеты по модели вызы­ваются из пункта меню Report. Всего имеется семь типов отчетов:

1. Model Report. Этот отчет уже упоминался в 1.2.1. Он включает инфор­мацию о контексте модели - имя модели, точку зрения, область, цель, имя автора, дату создания и др.

2. Diagram Report. Отчет по конкретной диаграмме. Включает список объ­ектов (работ, стрелок, хранилищ данных, внешних ссылок и т. д.).

3. Diagram Object Report. Наиболее полный отчет по модели. Может вклю­чать полный список объектов модели (работ, стрелок с указанием их типа и др.) и свойства, определяемые пользователем.

4. Activity Cost Report. Отчет о результатах стоимостного анализа. Будет рассмотрен ниже.

5. Arrow Report. Отчет по стрелкам. Может содержать информацию из сло­варя стрелок, информацию о работе-источнике, работе-назначении стрелки и информацию о разветвлении и слиянии стрелок.

6. Data Usage Report. Отчет о результатах связывания модели процессов и модели данных. (Будет рассмотрен ниже.)

7. Model Consistency Report. Отчет, содержащий список синтаксических ошибок модели.

Синтаксические ошибки IDEF0 с точки зрения BP-win разделяются на три типа:

- Во-первых, это ошибки, которые BP-win выявить не в состоянии. На­пример, синтаксис IDEF0 требует, чтобы имя работы было выражено отглагольным существительным или глагольной формой, выражающей действие (" Изготовление изделия ", " Обслуживаниеклиента ", " Выписка счета " и т. д.), а имя стрелки также должно быть выражено существи­тельным. BP-win не позволяет анализировать синтаксис естественного языка (английского и русского) и смысл имен объектов и поэтому игно­рирует ошибки этого типа. Выявление таких ошибок - ручная работа, которая ложится на плечи аналитиков и должна контролироваться руко­водителем проекта.

- Ошибки второго типа BP-win просто не допускает. Например, каждая грань работы предназначена для определенного типа стрелок. BP-win просто не позволит создать на диаграмме IDEF0 внутреннюю стрелку, выходящую из левой грани работы и входящую в правую грань.

- Третий тип ошибок BP-win позволяет допустить, но детектирует их. Полный их список можно получить в отчете Model Consistency Report.

Это единственный неопциональный отчет в BP-win.Список ошибок может содержать, например, неименованные работы и стрелки (Unconnected border arrow, unnamed activity), несвязанные стрелки (Unconnected border arrow), неразрешенные стрелки (unresolved (square tunneled)arrow connections), работы, не имеющие по крайней мере одной стрелки вы­хода и одной стрелки управления (Activity "Сборка блоков" has no Control, Activity "Сборка блоков" has no Output), и т. д.

При выборе пункта меню, который соответствует какому-либо отчету, появляется диалог настройки отчета. Для каждого из семи типов отчетов он выглядит по-своему. Рассмотрим типичный диалог Arrow Report (рисунок 27).

 

 

Рисунок 27 – Диалог Arrow Report

Раскрывающийся список Standard Report позволяет выбрать один из стандартных отчетов. Стандартный отчет - это запоминаемая комбинация переключателей, флажков и других элементов управления диалога. Для соз­дания собственного стандартного отчета необходимо задать опции отчета, ввести имя отчета в поле списка выбора и щелкнуть по кнопке New. BP-win сохраняет информацию о стандартном отчете в файле BPWINRPT.INI. Все определения этого файла доступны из любой модели. Единственное огра­ничение - свойства, определяемые пользователем (USER – Defined Properties). Они сохраняются в виде указателя и поэтому доступны только из "родной" модели.

Стандартный отчет можно изменить (кнопка Update) или удалить (кнопка Delete).

В правом верхнем углу диалога находится группа управляющих элемен­тов для выбора формата отчета. Доступны следующие форматы:

- Labeled - отчеты включают метку поля, затем, в следующей строке, пе­чатается содержимое поля;

- Fixed Column - каждое поле печатается в собственной колонке;

- Tab – Comma Delimited - каждое поле печатается в собственной колонке. Колонки разделяются знаком табуляции или запятыми;

- DDE Table - данные передаются по DDE приложению, например MS Word или Excel;

- RPTwin - отчет создается в формате Platinum RPTwin - специализиро­ванного генератора отчетов, который входит в поставку BP-win.

Опция Ordering (на отчете по стрелкам отсутствует) сортирует данные по какому-либо значению.

Опция Multi – Valued Format регулирует вывод полей в отчете при груп­пировке данных:

- Repeating Group - детальные данные объединяются в одно поле, между значениями вставляется +.

- Filled - дублирование данных для каждого заголовка группы;

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

 

4. ДИАГРАММЫ ПОТОКОВ ДАННЫХ (DATA FLOW DIAGRAMMING)

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

DFD описывает:

- функции обработки информации (работы);

- документы (стрелки, arrow), объекты, сотрудников или отделы, которые участвуют в обработке информации;

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

- таблицы для хранения документов (хранилище данных, data store).

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

Для того чтобы дополнить модель IDEF0 диаграммой DFD, нужно в процессе декомпозиции в диалоге Activity Box Count выбрать DFD. В палитре инструментов на новой диаграмме DFD появляют­ся новые кнопки:

– добавить в диаграмму внешнюю ссылку (External References). Внешняя ссылка является источником или приемником данных извне модели;

– добавить в диаграмму хранилище данных (Data store). Хранилище данных позволяет описать данные, которые необходимо сохранить в памя­ти прежде, чем использовать в работах;

­– ссылка на другую страницу. В отличие от IDEF0 в DFD стрелку можно направить на любую диаграмму (а не толь­ко на верхний уровень).

 

В отличие от стрелок IDEF0, которые представляют собой жесткие взаимосвязи, стрелки DFD показывают, как объекты (включая данные) двигаются от одной работы к другой. Это представление потоков совместно с хранилищами данных и внешними сущностями делает модели DFD более похожими на физические характеристики системы - движение объектов (data flow), хранение объектов (data stores), поставка и распространение объектов (external entities) (рисунок 28 ­– модель организации учебного процесса).

 

 

а)

 

б)

 

Рисунок 28 ­– модель организации учебного процесса).

 

В отличие от IDEF0, где система рассматривается как взаимосвязанные работы, DFD рассматривает систему как совокупность предметов. Контек­стная диаграмма часто включает работы и внешние ссылки. Работы, обычно, именуются по названию системы, например "Система обработки инфор­мации". Включение внешних ссылок в контекстную диаграмму не отменяет требования методологии четко определить цель, область и единую точку зрения на моделируемую систему.

Работы. В DFD работы представляют собой функции системы, преобразующие входы в выходы. Хотя работы изображаются прямоугольниками со скругленными углами, смысл их совпадает со смыслом работ IDEF0 и IDEF3. Так же как работы IDEF3, они имеют входы и выходы, но не под­держивают управления и механизмы, как IDEF0.

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

Стрелки (Потоки данных). Стрелки описывают движение объектов из одной части системы в другую. Поскольку в DFD каждая сторона работы не имеет четкого назначения, как в IDEF0, стрелки могут подходить и вы­ходить из любой грани прямоугольника работы. В DFD также применяются двунаправленные стрелки для описания диалогов типа "команда-ответ" между работами, между работой и внешней сущностью и между внешними сущностями (рисунок 29).

Рисунок 29 ­– использование двунаправленных стрелок

Для ввода стрелок различных типов необходимо установить курсор мыши на стрелку и дважды щелкнуть левой клавишей мыши, после чего в диалоговом окне DFD Arrow Properties выбрать вкладку Style на которой уставить нужный тип стрелок.

Хранилище данных. В отличие от стрелок, описывающих объекты в дви­жении, хранилища данных изображают объекты в покое.

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

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

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

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

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

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

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

Нумерация объектов. В DFD номер каждой работы может включать префикс, номер родительской работы (А) и номер объекта. Номер объекта - это уникальный номер работы на диаграмме. Например, работа может иметь номер А.12.4. Уникальный номер имеют хранилища данных и внешние сущности независимо от их расположения на диаграмме. Каждое хранили­ще данных имеет префикс D и уникальный номер, например D5. Каждая внешняя сущность имеет префикс Е и уникальный номер, например Е5.

 

ЛИТЕРАТУРА

 

1. Марк Д.А. и Мак-Гоуэн К. Методология структурного анализа и проектирования SADT. М.: Мета Технология, 1993.

2. Вендров А.М. Проектирование программного обеспечения экономических информационных систем. М.: Финансы и статистика, 2005.

3. Маклаков С.В. BPwin и Erwin. CASE-средства разработки информационных систем. М.: Диалог-МИФИ, 1999.

4. Маклаков С.В. Моделирование бизнес процессов с BPwin 4.0 М.: Диалог-МИФИ, 2002.

 

 

СОДЕРЖАНИЕ

 

 

ВВЕДЕНИЕ 3

1. МЕТОДОЛОГИЯ ФУНКЦИОНАЛЬНОГО МОДЕЛИРОВАНИЯ SADT 3 2. СОСТАВ ФУНКЦИОНАЛЬНОЙ МОДЕЛИ 4

3. СОЗДАНИЕ ФУНКЦИОНАЛЬНОЙ МОДЕЛИ В BP-WIN 8

4. ДИАГРАММЫ ПОТОКОВ ДАННЫХ (DATA FLOW DIAGRAMMING) 32

ЛИТЕРАТУРА 36