Лабораторная работа 1 Тема: Функциональное моделирование и построение моделей с помощью platinum bPwin. Построение диаграммы idef0. Построение диаграммы dfd

Цель: рассмотреть функциональное моделирование предприятия с помощью PLATINUM BPwin, построение диаграмм.

Теоретические сведения

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

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

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

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

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

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

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

• SADT (Structured Analysis and Design Technique) - модели и соответствующие функциональные диаграммы (подмножеством SADT является IDEF0); 

• FD (Data Flow Diagrams) – диаграммы потоков данных; 

• ERD (Entity-Relationship Diagrams) – диаграммы «сущность-связь». 

На стадии проектирования системы модели расширяются, уточняются и дополняются диаграммами, отражающими ее структуру.

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

Программный продукт BPWin 4.0 (Computer Associates corp.) является мощным инструментом для создания моделей, позволяющих анализировать, документировать и планировать изменения сложных бизнес-процессов. BPwin 4.0 является средством сбора необходимой информации о работе предприятия и графического изображения этой информации в виде целостной и непротиворечивой модели. BРwin–модель является графическим представлением действительности, то есть средством документирования и формализации бизнес–процессов. BPWin 4.0 — это современное CASE–средство (Computer Aid Software Engineering), позволяющие анализировать бизнес–процесс с трех ключевых точек зрения: 

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

2. С точки зрения потоков информации в системе. Диаграммы DFD (Data Flow Diagram) дополняют функциональные IDEF0–модели, поскольку они описывают потоки данных, позволяя проследить, каким образом происходит обмен информацией между бизнес-функциями внутри системы. Также модели потоков данных могут использоваться как самостоятельное средство при проектировании информационных систем или описании бизнес–процесса, но в DFD-модели акцент ставится на поток данных, его структуру, место и вид хранения данных в системе.

3. С точки зрения последовательности этапов выполняемых работ — методология событийного моделирования IDEF3. Этот метод привлекает внимание к очередности выполнения этапов работ или изменения состояний. В IDEF3 включены элементы логики, что позволяет моделировать и анализировать альтернативные сценарии развития бизнес-процесса.

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

Методология функционального моделирования IDEF0

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

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

Каждая IDEFO-диаграмма содержит блоки и дуги (стрелки). Блоки изображают функции моделируемой системы. Дуги связывают блоки вместе и отображают взаимодействия и взаимосвязи между ними.

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

Каждый функциональный блок в рамках единой рассматриваемой системы должен иметь свой уникальный идентификационный номер, который присваивается автоматически. Все блоки должны быть названы и определены. Имя блока должно отражать действие и задается только в виде глагола, например, ИЗГОТОВИТЬ ДЕТАЛЬ, СОБРАТЬ ДАННЫЕ.

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

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

Для того чтобы задать другие свойства блока необходимо нажать правой клавишей мыши на изображении блока и выбрать нужное свойство «Activity properties» (рисунок 2).

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

Второй основной элемент IDEF0–методологии — это стрелка. Стрелка бывает четырех типов: стрелка–вход, выход, механизм и управление.

1. Вход (Input) рисуется, как входящая в левую грань функционального блока. Вход показывает, что требуется для выполнения функции, например, СВЕДЕНИЯ О КЛИЕНТЕ, ЗАГОТОВКА.

2. Выход (Output) – исходящая из правой грани блока. Выход — результат функции, например, ГОТОВАЯ ДЕТАЛЬ, ОТЧЕТ.

3. Механизм (Mechanism) входящая в нижнюю грань стрелка. Механизм с помощью чего или кого выполняется функция, например, СОТРУДНИК, КОМПЬЮТЕР.

4. Управление (Control) рисуется входящей в верхнюю грань блока. Управление ограничивает (регламентирует) выполнение функции), например, УСТАВ, ГОСТы.

Также существует пятый тип стрелки — это стрелка вызова, которая носит технический характер и служит для слияния и расщепления моделей. Стрелка вызова рисуется также как стрелка–механизма, но имеет противоположное направление. Имена вновь внесенных стрелок автоматически заносятся в словарь (Arrow Dictionary).

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

Для внесения граничной стрелки надо:

• Щелкнуть по кнопке с символом стрелки в палитре инструментов, затем следует перенести курсор к левой стороне экрана, пока не появится начальная штриховая полоска; 

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

• Вернуться в палитру инструментов и выбрать опцию редактирования стрелки

• Щелкнуть правой кнопкой мыши на линии стрелки, во всплывающем меню выбрать Name и добавить имя стрелки в закладке Name диалога Arrow Properties.

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

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

Существуют определенные правила именования таких стрелок. Если стрелка именована до разветвления, а после разветвления ни одна из ветвей не именована, то подразумевается, что каждая ветвь моделирует те же данные или объекты, что и ветвь до разветвления. Если стрелка именована до разветвления, а после разветвления какая-либо из ветвей, то подразумевается, что именованная ветвь моделирует данные соответствующие ее имени, а не именованная те же данные, что и ветвь до разветвления. Недопустима ситуация, когда стрелка до разветвления не именована, и после разветвления не именована какая-либо из ветвей. BPWin 4.0 определяет такую стрелку как синтаксическую ошибку. Правила именования сливающихся стрелок аналогичны.

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

Рисунок 3 - Неразрешенная стрелка

Для их «перетаскивания» наверх нужно щелкнуть правой кнопкой мыши по квадратным скобкам граничной стрелки и выбрать из выпадающего меню Arrow Tunnel. Появится диалоговое окно Border Arrow Editor.

Рисунок 4 - Диалог Border Arrow Editor

Если выбрать resolve it to border arrow, то стрелка мигрирует на диаграмму верхнего уровня. Если выбрать Change it to resolve rounded tunnel, то стрелка будет затуннелирована и не попадет на другую диаграмму. Тоннельная стрелка изображается с круглыми скобками на конце. Туннелирование может быть применено для изображения малозначимых стрелок. Если на какой-либо диаграмме нижнего уровня необходимо изобразить малозначимые данные или объекты, которые не обрабатываются или не используются процессами на текущем уровне, то их необходимо направить на вышестоящий уровень (родительскую диаграмму).

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

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

Создание иерархии диаграмм

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

Рисунок 5 - Диалог Activity Box Count

Для создания дополнительных блоков нужно нажать на кнопку  и указать расположение блока.

Функциональные блоки автоматически нумеруются в соответствии со значением параметра Numbering (Нумерация), установленным в разделе Model Properties в меню Model. Номер блока записывается в правом нижнем углу блока.

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

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

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

Расположение блоков на странице отражает авторское определение доминирования. Таким образом, топология диаграммы показывает, какие функции оказывают большее влияние на остальные. Чтобы подчеркнуть это, аналитик может перенумеровать блоки в соответствии с порядком их доминирования. Порядок доминирования может обозначаться цифрой, размещенной в правом нижнем углу каждого прямоугольника: 1 будет указывать на наибольшее доминирование, 2 – на следующее и т. д.

В методологии IDEFO требуется только пять типов взаимодействий между блоками для описания их отношений: вход (рисунок 6), управление (рисунок 7), обратная связь по входу (рисунок 8), обратная связь по управлению (рисунок 9), выход-механизм (рисунок 10). Связи по управлению и входу являются простейшими, поскольку они отражают прямые воздействия, которые интуитивно понятны и очень просты.

Рисунок 6 – Связь по входу

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

Рисунок 7 – Связь по управлению

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

Рисунок 8 – Обратная связь по входу

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

Рисунок 9 – Обратная связь по управлению

Связи «выход-механизм» встречаются нечасто. Они отражают ситуацию, при которой выход одной функции становится средством достижения цели для другой.

Связи «выход-механизм» характерны при распределении источников ресурсов (например, требуемые инструменты, обученный персонал, физическое пространство, оборудование, финансирование, материалы).

Рисунок 10 – Связь выход-механизм

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

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

• непомеченные ветви содержат все объекты, указанные в метке дуги перед разветвлением;

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

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

• непомеченные ветви содержат все объекты, указанные в общей метке дуги после слияния;

• помеченные перед слиянием ветви содержат все или некоторые объекты из перечисленных в общей метке после слияния.