Лекция №3. Моделирование функций ПО. Нотация IDEF0. CASE-средство BPWin
План лекции
-История возникновения и развития подходов, связанных с графическим моделированием деятельности.
-Подход к моделированию функциональности систем StructuredAnalisysandDesigTechnique (SADT).
-Семейство стандартов IDEF.
-Стандарт IDEF0.
-Графические символы стандарта.
-Виды связей.
-Правила декомпозиции.
Введение
Методология SADT представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель SADT отражает структуру функций объекта (производимых им действий) и связи между этими действиями [22].
В основу методологии положены следующие концепции:
1. Моделируемая система рассматривается как произвольное подмножество Вселенной;
2. Система имеет границу, отделяющую ее от остальной вселенной. Взаимодействие системы с окружающим миром описывается следующими терминами:
Ø Вход (нечто перерабатываемое системой);
Ø Выход (результат деятельности системы);
Ø Управление (стратегии и процедуры, под управлением которых производится работа);
Ø Механизм (ресурсы, необходимые для проведения работы).
3. Находясь под управлением, система преобразует входы в выходы с использованием механизмов.
4. Графическое представление функциональной модели. В модели SADT функция представляется в виде блока, а интерфейсы входа-выхода представляются дугами. Взаимодействие блоков друг с другом описывается при помощи интерфейсных дуг, выражающих ограничения в выполнении и управлении функций.
5. Строгость и точность. Правила SADT включают:
Ø Ограничение числа блоков на каждой диаграмме (2 – 8 блоков).
Ø Связность диаграмм (структурная нумерация блоков).
Ø Уникальность меток и наименований.
Ø Синтаксические правила для графики (блоков и дуг).
Ø Разделение входов и управлений (определение роли данных).
6. Отделение организации от функции, то есть исключение влияния организационной структуры на функциональную модель.
Методология SADT может использоваться для моделирования и разработки различных систем, определения требований к ним и выполняемых ими функций. В уже существующих системах SADT может быть использована для анализа функций выполняемых системой, и указания механизмов, посредством которых они выполняются.
Перед построением модели следует определить область моделирования (Scope), которая включает в себя позицию, с которой рассматривается система (ViewPoint) и цель моделирования (Purpose). При описании области моделирования ее следует ограничить по широте (решить, что входит контекст системы, а что останется за ним) и по глубине (решить, на каком уровне детализации модель будет завершена).
Цель моделирования. Модель не может быть построена без четко сформулированной цели. Цель должна отвечать на вопросы:
· Почему эту систему надо моделировать?
· Что должна показывать модель?
· Что может получить читатель от модели?
Формулировка цели позволяет аналитикам сфокусировать усилия в нужном направлении. Примеры целей: «Идентифицировать роли и ответственность служащих для написания должностных инструкций», «Описать деятельность предприятия с целью создания спецификации информационной системы».
Точка зрения. Несмотря на то, что при моделировании системы учитываются мнения различных людей, модель должна строиться, исходя из единой точки зрения. Точка зрения может быть представлена как взгляд человека, который видит систему в нужном для моделирования аспекте. Точка зрения должна соответствовать цели моделирования. Точка зрения различных, участвующих в работе специалистов (например, финансистов и технологов) может быть различной, поэтому важно в процессе моделирования оставаться на единой точке зрения. Как правило, выбирается точка зрения лица, ответственного за моделируемую работу в целом. Если при выборе точки зрения необходимо задокументировать дополнительные альтернативные точки зрения, для этого используется диаграмма FEO (ForExpositionOnly).
Модели As-Is и To-Be. Модель As-Is – описание существующего положения дел в организации (системе). Модель To-Be строится для анализа альтернативных путей выполнения работ и документирования того, как система будет функционировать в будущем.
При разработке информационных систем принято использовать следующую последовательность работ:
1. Создание модели As-Is.
2. Ее анализ и улучшение бизнес-процессов (создание модели To-Be).
3. На основе модели To-Be – построение модели данных, прототипов и окончательных версий информационной системы.
4. Если различие между As-Is и To-Be велико и процесс перехода между ними неочевиден, то кроме As-Is и To-Be, строится третья модель, изображающая такой процесс.
Диаграммы IDEF0
Модель в IDEF0 представляет собой совокупность иерархически упорядоченных и взаимосвязанных диаграмм.
В IDEF0 выделяется 4 вида диаграмм:
· Контекстная диаграмма.
· Диаграмма декомпозиции.
· Диаграмма дерева узлов.
· Диаграмма только для экспозиции (FEO).
Основные символы и виды дуг изображены на рисунке 7.
Рисунок 7 – Функциональный блок и интерфейсные дуги в IDEF0
Работа (Activity) обозначает поименованный процесс, функцию или задачу, происходящую в течение определенного времени и имеющую распознаваемый результат. Имя работы должно выражаться отглагольным существительным, обозначающим действие (например, «Изготовление детали», «Прием заказа»).
Стрелки (Arrow) описывают взаимодействие системы с внешним миром и работой между собою. Стрелки представляют собой информацию или физические объекты и именуются существительными (например, «Заготовка», «Изделие», «Заказ»).
В IDEF0 различают 5 типов стрелок:
· Вход (Input) – материал или информация, использующаяся или преобразуемая работой для получения результатов. Стрелки такого типа изображаются входящими в левую грань блока функции.
· Управление (Control) – правила, стратегии, процедуры или стандарты, которыми руководствуется работа. Стрелки такого типа изображаются входящими в верхнюю грань блока функции.
· Выход (Output) – материал или информация, производящаяся работой. Стрелки такого типа изображаются выходящими из правой грани блока функции.
· Механизм (Mechanism) – ресурсы, которые выполняют работу (персонал предприятия, станки, устройства и т.п.). Стрелки этого типа изображаются входящими в нижнюю грань блока функции.
· Вызов (Call) – специальная стрелка, указывающая на другую модель работы. Стрелка рисуется исходящей из нижней грани блока.
Для дополнительной идентификации стрелок каждой из них присваивается ICOM-код (ICOM – аббревиатура от Input-Control-Output-Mechanism). Код стрелки содержит префикс, соответствующий типу стрелки (I, C, O или M) и ее порядковый номер.
Правила работы со словарем данных в IDEF0 аналогичны правилам, используемым в DFD.
Пример контекстной диаграммы IDEF0 для банковской задачи приведён на рисунке 8.
Виды связей в IDEF0
Функции в IDEF0 располагаются в порядке доминирования. Функция управляющая, или предшествующая располагается левее и выше управляемой функции [18].
Рисунок 8 – Контекстная диаграмма IDEF0 банковской задачи
Рисунок 9 –Виды связей в IDEF0.
В IDEF0 различают 5 видов связей между работами (рисунок 9):
· Связь по входу (output – input).
· Связь по управлению (output – control).
· Обратная связь по входу (output – inputfeedback).
· Обратная связь по управлению (output – controlfeedback).
· Связь выход-механизм (output – mechanism). Связь показывает, что одна работа подготавливает ресурсы, необходимые для проведения другой работы.
Примеры декомпозиции процессов банковской задачи при помощи диаграмм IDEF0 приведены на рисунках 10 и 11.
Рисунок 10 –Диаграмма первого уровня IDEF0 для банковской задачи
Рисунок 11 –Диаграмма IDEF0 для процесса «Обработать запрос на обслуживание»
Диаграмма дерева узлов
Диаграмма дерева узлов показывает иерархию работ в модели и позволяет рассмотреть всю модель целиком, но не показывает взаимосвязи между работами. Процесс создания модели работ является итерационным, следовательно, работы могут менять своё положение в дереве узлов.
Для сохранения контроля над структурой декомпозиции работ дерево узлов следует создавать для каждого варианта модели.
Диаграмма дерева узлов имеет вид традиционного иерархического дерева, где верхний узел (прямоугольник) соответствует работе с контекстной диаграммы, а последующие нижние узлы представляют собой дочерние уровни декомпозиции. Можно также создать диаграмму дерева узлов лишь для некоторой части модели, тогда верхним узлом диаграммы будет та работа декомпозиции, с которой вы захотите начать.
Дерево узлов для банковской задачи приведено на рисунке 12.
Рисунок 12 –Дерево узлов банковской задачи
CASE-средство BPWin
Для проведения анализа и реорганизации бизнес-процессов PLATINUM technology предлагает CASE-средство верхнего уровня BPwin, поддерживающее методологии IDEFO (функциональная модель), IDEF3 (WorkFlowDiagram) и DFD (DataFlowDiagram). Функциональная модель предназначена для описания существующих бизнес-процессов на предприятии (так называемая модель AS-IS) и идеального положения вещей - того, к чему нужно стремиться (модель ТО-ВЕ) [35,36]. Методология IDEF0 предписывает построение иерархической системы диаграмм - единичных описаний фрагментов системы. Сначала проводится описание системы в целом и ее взаимодействия с окружающим миром (контекстная диаграмма), после чего проводится функциональная декомпозиция - система разбивается на подсистемы и каждая подсистема описывается отдельно (диаграммы декомпозиции). Затем каждая подсистема разбивается на более мелкие и так далее До достижения нужной степени подробности. После каждого сеанса декомпозиции проводится сеанс экспертизы: каждая диаграмма проверяется экспертами предметной области, представителями заказчика, людьми, непосредственно участвующими в бизнес-процессе. Такая технология создания модели позволяет построить модель, адекватную предметной области на всех уровнях абстрагирования. Если в процессе моделирования нужно осветить специфические стороны технологии предприятия, BPwin позволяет переключиться на любой ветви модели на нотацию IDEF3 или DFD и создать смешанную модель. Нотация DFD включает такие понятия, как внешняя ссылка-и хранилище данных, что делает ее более удобной (по сравнению с IDEF0) для моделирования документооборота. Методология IDEF3 включает элемент "перекресток", что позволяет описать логику взаимодействия компонентов системы [27].
На основе модели BPwin можно построить модель данных. Для построения модели данных PLATINUM technology предлагает мощный и удобный инструмент - ERwin. Хотя процесс преобразования модели BPwin в модель данных плохо формализуется и поэтому полностью не автоматизирован, PLATINUM technology предлагает удобный инструмент для облегчения построения модели данных на основе функциональной модели - механизм двунаправленной связи BPwin - ERwin. ERwin имеет два уровня представления модели - логический и физический. На логическом уровне данные не связаны с конкретной СУБД, поэтому могут быть наглядно представлены даже для неспециалистов. Физический уровень данных - это по существу отображение системного каталога, который зависит от конкретной реализации СУБД. ERwin позволяет проводить процессы прямого и обратного проектирования БД[27]. Это означает, что по модели данных можно сгенерировать схему БД или автоматически создать модель данных на основе информации системного каталога.
Вопросы
1) Основные понятия. «Контекст», «точка зрения», «as-is» и «to-be».
2) Процесс. Декомпозиция и структурная нумерация процессов. Правило наименование процессов.
3) Стрелки. Назначение стрелок по типам. Виды связей.
4) Правила слияния/разветвления стрелок.
5) Диаграмма дерева узлов.
Дополнительная информация
1)http://www.cfin.ru/vernikov/idef/idef0.shtml
2) http://bpmsoft.org/idef0-and-idef3/
3) http://www.osp.ru/os/2003/01/182411/
4) http://quality.eup.ru/MATERIALY2/idef-or.htm
5) http://www.interface.ru/iarticle/files/35798_52840953.pdf