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

Функционально-ориентированные и объектно-ориентированные методологии описания предметной области

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

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

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

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

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

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

Методологию IDEF0 можно считать следующим этапом развития хорошо известного графического языка описания функциональных систем SADT (Structured Analysis and Design Teqnique).

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

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

Функциональный блок (Activity Box) представляет собой некоторую конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, «производить услуги»). На диаграмме функциональный блок изображается прямоугольником. Каждая из четырех сторон функционального блока имеет свое определенное значение (роль), при этом:

· верхняя сторона имеет значение «Управление» (Control);

· левая сторона имеет значение «Вход» (Input);

· правая сторона имеет значение «Выход» (Output);

· нижняя сторона имеет значение «Механизм» (Mechanism).

 Функциональный блок

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

С помощью интерфейсных дуг отображают различные объекты, в той или иной степени определяющие процессы, происходящие в системе. Обязательное наличие управляющих интерфейсных дуг является одним из главных отличий стандарта IDEF0 от других методологий классов DFD (Data Flow Diagram) и WFD (Work Flow Diagram).

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

Последним из понятий IDEF0 является глоссарий (Glossary). Для каждого из элементов IDEF0 — диаграмм, функциональных блоков, интерфейсных дуг — существующий стандарт подразумевает создание и поддержание набора соответствующих определений, ключевых слов, повествовательных изложений и т.д., которые характеризуют объект, отображенный данным элементом. Этот набор называется глоссарием и является описанием сущности данного элемента. Глоссарий гармонично дополняет наглядный графический язык, снабжая диаграммы необходимой дополнительной информацией.

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

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

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

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

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

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

· Создание модели группой специалистов, относящихся к различным сферам деятельности предприятия

· Распространение черновика для рассмотрения, согласований и комментариев.

· Официальное утверждение модели.  

 54. Функциональная методика потоков данных или

 Моделирование потоков данных (DFD).

Целью методики является построение модели рассматриваемой системы в виде диаграммы потоков данных (Data Flow Diagram — DFD), обеспечивающей правильное описание выходов (отклика системы в виде данных) при заданном воздействии на вход. Диаграммы потоков данных являются основным средством моделирования функциональных требований к проектируемой системе.

Для построения DFD традиционно используются две различ­ные нотации, соответствующие методам Йордона—ДеМарко и Гейна—Сэрсона.

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

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

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

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

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

Кроме основных элементов, в состав DFD входят словари данных и миниспецификации.

Процесс построения DFD начинается с создания так называемой основной диаграммы типа «звезда», на которой представлен моделируемый процесс и все внешние сущности, с которыми он взаимодействует.

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

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

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

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

К преимуществам методики DFD относятся:

· возможность однозначно определить внешние сущности, анализируя потоки информации внутри и вне системы;

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

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

К недостаткам модели:

· необходимость искусственного ввода управляющих процессов;

· отсутствие понятия времени.

 

55. Объектно-ориентированная методика

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

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

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

К основным понятиям объектно-ориентированного подхода (элементам объектной модели) относятся:

• объект;

• класс;

• атрибут;

• операция;

• полиморфизм (интерфейс);

• компонент;

• связи.

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

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

Язык UML

Промышленным объектно-ориентированным стандартом языка мо­делирования бизнес-процессов и систем с ориентацией на их дальней­шую реализацию в виде программного обеспечения является Unified Modeling Language (UML).

Унифицированный язык моделирования UML (Unified Modeling Language) представляет собой язык для определения, представле­ния, проектирования и документирования программных систем, организационно-экономических систем, технических систем и других систем различной природы. UML содержит стандартный набор диаграмм и нотаций самых разнообразных видов.

UML - это преемник того поколения методов объектно-ориентированного анализа и проектирования, которые появи­лись в конце 1980-х и начале 1990-х годов. UML является прямым объединением и унифика­цией методов Буча, Рамбо и Якобсона, однако дополняет их но­выми возможностями.

UML находится в процессе стандартизации, проводимом OMG (Object Management Group) — организацией по стандарти­зации в области объектно-ориентированных методов и техноло­гий, в настоящее время принят в качестве стандартного языка моделирования и получил широкую поддержку в индустрии ПО. UML принят на вооружение почти всеми крупнейшими компа­ниями — производителями ПО (Microsoft, IBM, Hewlett-Packard, Oracle, Sybase и др.).

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

UML содержит следующий набор диаграмм для определения представления, проектирования и документирования программных систем:

v диаграммы вариантов использования (use case diagrams) - для моделирования требований к системе;

v диаграммы классов (class diagrams) - для моделирования статической структуры классов системы и их взаимосвязей;

v диаграммы состояний (statechart diagrams) — для моделирования поведения объектов системы;

v диаграммы деятельностей (activity diagrams) — для моделирования поведения системы в рамках различных вариантов использования;

v диаграммы взаимодействия (interaction diagrams): диаграммы последовательности (sequence diagrams) и диаграммы коопера­ции (collaboration diagrams) — для моделирования процесса об­мена сообщениями между объектами;

v диаграммы компонентов (component diagrams) — для моделирования иерархии компонентов системы;

v диаграммы развертывания (deployment diagrams) — для модели­рования физической архитектуры системы.