Моделирование бизнес-процессов / Моделирование бизнес-процессов / ! Функционально-структурный анализ

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

• роли, которые выполняют эти объекты (например, агент, транспорт и т.д.);

• отношения между UOW в ходе выполнения сценария процесса;

• состояния и изменения, которым подвергаются объекты;

• время выполнения и контрольные точки синхронизации UOW;

• ресурсы, которые необходимы для выполнения UOW.

Представление UOW с помощью отдельной IDEF3-диаграммы. Каждый функциональный блок UOW может иметь последовательность декомпозиций, и, следовательно, может быть детализирован с любой необходимой точностью. Методология IDEF3 позволяет декомпозировать UOW у многократно, т. е. UOW может иметь множество дочерних UOW. Это позволяет в одной модели описать альтернативные по-токи. Декомпозиция формирует границы для описания процесса и каждый UOW элемент рас--сматривается как формальная граница некоторой части целой системы, которая описывает весь процесс. Декомпозированная диаграмма, называемая диаграммой потомком, более детально описывает процесс. Декомпозируемый UOW элемент называется родительским, а содержащая его диаграмма - соответственно родительской диаграммой. Итак, декомпозиция - это процесс создания диаграммы, детализирующей определенный UOW элемент. Результатом ее является описание, которое представляет собой дробление родительского UOW элемента на меньшие и более частные операции или функции. Декомпозиция обеспечивает средства организации более детального описания UOW элементов. Каждый UOW элемент может иметь любое число различных декомпозиций на том же самом уровне детализации с целью представления различных точек зрения или обеспечения большей подробности при описании исходного процесса. На рисунке 1 представлен пример декомпозиции модулей и принцип формирования их номеров. Для наглядности все модули представлены на одном рисунке, но в IDEF3 описании они будут представлены на трех диаграммах.

Чтобы отобразить различные варианты детализации действий или событий в IDEF3 предусмотрена возможность многократной декомпозиции одного функционального модуля. Как видно на рис. 1, в диаграмме декомпозиции первая цифра номера модуля указывает номер д-композируемого, то есть родительского модуля, а вторая цифра порядковый номер декомпозиции. Третья цифра указывает порядковый номер модуля в диаграммах описания процесса. На рисунке 2 представлен пример двух вариантов декомпозиции родительского модуля.

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

Пример нумерации UOB элементов при использовании декомпозиции и описания различных точек зрения на выполнение процессов показан на Рис 4.

Процесс декомпозиции диаграмм IDEF3, включает взаимодействие автора (аналитика) и одного или нескольких экспертов предметной области:

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

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

Исторически, понятие онтологии появилось в одной из ветвей философии, называемой метафизикой, которая изучает устройство реального мира. Основной характерной чертой он-тологического анализа является, в частности, разделение реального мира на составляющие и классы объектов (at its joints) и определение их онтологий, или же совокупности фундаментальных свойств, которые определяют их изменения и поведение. Таким образом, естествен-ная наука представляет собой типичный пример онтологического исследования. Например, атомная физика классифицирует и изучает свойства наиболее фундаментальных объектов реального мира, таких как элементарные частицы, а биология, в свою очередь, описывает характерные свойства живых организмов, населяющих планету. Однако фундаментальные и естественные науки не обладают достаточным инструментарием для того, чтобы полностью охватить область, представляющую интерес для онтологического исследования. Например, существует большое количество сложных формаций или систем, созданных и поддерживаемых человеком, таких как производственные фабрики, военные базы, коммерческие предприятия и т.д. Эти формации представляют собой совокупность взаи--мосвязанных между собой объектов и процессов, в которых эти объекты тем или иным образом участвуют. Онтологическое исследование подобных сложных систем позволяет накопить ценную информацию об их работе, результаты анализа которой будут иметь решающее мнение при проведении процесса реорганизации существующих и построении новых систем. Методология IDEF5 обеспечивает наглядное представление данных, полученных в результате обработки онтологических запросов в простой естественной графической форме.

Онтологический анализ обычно начинается с составления словаря терминов, который ис--пользуется при обсуждении и исследовании характеристик объектов и процессов, составляющих рассматриваемую систему, а также создания системы точных определений этих терминов. Кроме того, документируются основные логические взаимосвязи между соответствующими введенным терминам понятиями. Результатом этого анализа является ОНТОЛОГИЯ системы, или же совокупность словаря терминов, точных их определений взаимосвязей между ними. Таким образом, онтология включает в себя совокупность терминов и правила, согласно которым эти термины могут быть скомбинированы для построения достоверных утверждений о состоянии рассматриваемой системы в некоторый момент времени. Кроме того, на основе этих утверждений, могут быть сделаны соответствующие выводы, позволяющие вносить изменения в систему, для повышения эффективности её функционирования. В любой системе существует две основные категории предметов восприятия, такие как сами объекты, составляющие систему (физические и интеллектуальные) и взаимосвязи между этими объектами, характеризующие состояние системы. В терминах онтологии, понятие взаимосвязи, однозначно описывает или, другими словами, является точным дескриптором зависимости между объектами системы в реальном мире, а термины - являются, соответственно, точными дескрипторами самих реальных объектов. При построении онтологии, в первую очередь происходит создание списка или базы данных дескрипторов и с помощью них, если их набор достаточен, создается модель системы. Таким образом, на начальном этапе должны быть выполнены следующие задачи:

• создание и документирования словаря терминов;

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

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

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

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

2. Сбор и накапливание данных. На этом этапе происходит сбор и накапливание необходимых начальных данных для построения онтологии.

3. Анализ данных. Эта стадия заключается в анализе и группировке собранных данных и пред-назначена для облегчения построения терминологии.

4. Начальное развитие онтологии. На этом этапе формируется предварительная онтология, на основе отобранных данных.

5. Уточнение и утверждение онтологии.

Для поддержания процесса построения онтологий в IDEF5 существуют специальные онтологические языки: схематический язык (Schematic Language-SL) и язык доработок и уточнений (Elaboration Language-EL). SL является наглядным графическим языком, специально предназначенным для изложения компетентными специалистами в рассматриваемой области системы основных данных в форме онтологической информации (См. рисунок 1). Этот несложный язык позволяет естественным образом представлять основную информацию в начальном развитии онтологии и дополнять существующие онтологии новыми данными. EL представляет собой структурированный текстовой язык, который позволяет детально характеризовать элементы онтологии. Язык SL позволяет строить разнообразные типы диаграмм и схем в IDEF5. Основная цель всех этих диаграмм - наглядно и визуально представлять основную онтологическую информацию. Несмотря на кажущееся сходство, семантика и обозначения схематичного языка SL существенно отличается от семантики и обозначений других графических языков. Дело в том, что часть элементов графической схемы SL может быть изменен или вовсе не приниматься во внимание языком EL. Причина этого состоит в том, что основной целью применения SL является создание лишь вспомогательной структурированной конструкции онтологии, и графические элементы SL не несут достаточной информации для полного представления и анализа системы, тем самым они не предназначены для сохранения при конечном этапе проекта. Тщательный анализ, обеспечение полноты представления структуры данных, полученных в ре-зультате онтологического исследования, являются задачей применения языка EL.

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

1. Диаграмма классификации

Диаграмма классификации обеспечивает механизм для логиче-ской систематизации знаний, накопленных при изучении системы. Существует два типа таких диаграмм: диаграмма строгой классификации (Description Subsumption - DS) и диаграмма естественной или видовой классификации (Natural Kind Classification - NKC). Основное отличие диаграммы DS заключается в том, что определяющие свойства классов высшего и всех последующих уровней являются необходимым и достаточным признаком принадлежности объекта к тому или иному классу. На рисунке 2 приведен пример такой диаграммы, построенной на основе тривиальной возможности классификации многоугольников по количеству углов. Из геометрии известно точное математическое определение многоугольника, суть определяющих свойств родительского класса. Определяющим свойством каждого дочернего класса дополнительно является количество углов в многоугольнике. Очевидно, зная это определяющее свойство для любого многоугольника, можно однозначно отнести его к тому или иному дочернему классу. С помощью диаграмм DS, как правило, классифицируются логические объекты.

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

2. Композиционная схема

Композиционные схемы (Composition Schematics) являются механизмом графического представления состава классов онтологии и фактически представля-ют собой инструменты онтологического исследования по принципу "Что из чего состоит". В частности, композиционные схемы позволяют наглядно отображать состав объектов, относящихся к тому или иному классу. На рисунке 3 изображена композиционная схема шариковой ручки, относящейся к классу шариковых автоматических ручек. В данном случае ша-риковая ручка является системой, к которой мы применяем методы онтологического исследования. С помощью композиционной схемы мы наглядно документируем, что авторучка состоит из нижней и верхней трубки, нижняя трубка в свою очередь включает в себя кнопку и фиксирующий механизм, а верхняя трубка включает в себя стержень и пружину.

3. Схема взаимосвязей

Схемы взаимосвязей (Relation Schematics) позволяют разработчикам визуализировать и изучать взаимосвязи между различными классами объектов в системе. В некоторых случаях схемы взаимосвязей используются для отображения зависимостей между самими же классовыми взаимосвязями. Мотивацией для развития подобной возможности послужило то тривиальное правило, что все вновь разработанные концепции всегда базируются на уже существующих и изученных. Это тесно согласуется с теорией Новака и Гоуэна (Novak & Gowin, 1984), суть которой в том, что изучение любой системы часто происходит от частного к общему, то есть, происходит изыскание и исследование новой частной информации, влияющее на конечные характеристики более общей концеп-ции, к которой эта информация имела прямое отношение. Исходя из этой гипотезы, естественным образом изучения новой или плохо понимаемой взаимосвязи является соотнесение ее с достаточно изученной взаимосвязью, для исследования характеристик их сосуществования.

4. Диаграмма состояния объекта

Диаграмма состояния объекта (Object State Schemantic) позволяет документировать тот или иной процесс с точки зрения изменения состояния объек-та. В происходящих процессах могут произойти два типа изменения объекта: объект может поменять свое состояние или класс. Между этими двумя видами изменений по сути не существует принципиальной разницы: объекты, относящиеся к определенному классу K в начальном состоянии в течение процесса могут просто перейти к его дочернему или просто родственному классу. Например, полученная в процессе нагревания теплая вода, уже от-носится не к классу ВОДА, а к его дочернему классу ТЕПЛАЯ ВОДА. Однако при формальном описании процесса, во избежание путаницы, целесообразно разделять оба вида изменений, и для такого разделения используется обозначения следующего вида: "класс:состояние". Например теплая вода будет описываться следующим образом: "во-да:теплая", холодная - "вода:холодная" и так далее. Таким образом, диаграммы состояния в IDEF5 наглядно представляют изменения состояния или класса объекта в течение всего хода процесса. Пример такой диаграммы приведен на рис.4 Таким образом можно считать, что строение и свойства любой системы могут быть эффективно исследованы и задокументированы при помощи следующих средств: словаря терминов, используемых при описании характеристик объектов и процессов, имеющих отношение к рассматриваемой системе, точных и однозначных определений всех терминов этого словаря и классификации логических взаимосвязей между этими терминами. Набор этих средств, по сути, и является онтологией системы, а стандарт IDEF5 предоставляет структурированную методологию, с помощью которой можно наглядно и эффективно разрабатывать, поддерживать и изучать эту онтологию.IDEF9 - методологии моделирования требований.

Для решения задачи функционального моделирования на базе структурного анализа тра--диционно применяются два типа моделей: IDEF0-диаграммы и диаграммы потоков данных. Методология разработки процессных диаграмм обычно применяется при проведении обследований предприятий в рамках проектов управленческого консалтинга, а также в проектах автоматизации крупных объектов при экспресс-обследовании (обычно для составления развернутого плана работ). Нотация диаграмм потоков данных позволяет отображать на диаграмме как шаги бизнес-процесса, так и поток документов и управления (в основном, управления, поскольку на верхнем уровне описания процессных областей значение имеет передача управления). Также на диаграмме можно отображать средства автоматизации шагов бизнес-процессов. Обычно используется для отображения третьего и ниже уровня декомпозиции бизнес-процессов (первым уровнем считается идентифицированный перечень бизнес-процессов, а вторым - функции, выполняемые в рамках бизнес-процессов). Диаграммы потоков данных (Data flow diagramming, DFD):

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

• создаются для моделирования существующего процесса движения информации;

• используются для описания документооборота, обработки информации;

• применяются как дополнение к модели IDEFO для более наглядного отображения текущих операций документооборота (обмена информацией);

• обеспечивают проведение анализа и определения основных направлений реинжиниринга ИС.

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

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

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

3. Существуют и поддерживаются рядом CASE-инструментов алгоритмы автоматического пре-образования иерархии DFD в структурные карты, демонстрирующие межсистемные и внут-рисистемные связи, а также иерархию систем, что в совокупности с мини-спецификациями является завершенным заданием для программиста.

С помощью DFD-диаграмм требования к проектируемой ИС разбиваются на функциональные компоненты (процессы) и представляются в виде сети, связанной потоками данных. Главная цель декомпозиции DFD-функций - продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами. На схемах бизнес-процесса отображаются:

• функции процесса;

• входящая и исходящая информация, при описании документов;

• внешние бизнес-процессы, описанные на других диаграммах;

• точки разрыва при переходе процесса на другие страницы.

Если при моделировании по методологии IDEF0 система рассматривается как сеть взаи-мосвязанных функций, то при создании DFD-диаграммы система рассматривается как сеть связанных между собой функций, т.е. как совокупность сущностей (предметов). Структурный анализ - это системный пошаговый подход к анализу требований и проектированию спецификаций системы независимо от того, является ли она существующей или создается вновь. Методологии Гейна-Сарсона (Gane-Sarson) и Йордана/Де Марко (Yourdon/DeMarko) построения диаграмм потоков данных, осно-ванные на идее нисходящей иерархической организации, наиболее ярко демонстрируют этот подход. Целью этих двух методологий является преобразование общих, неясных знаний о требованиях к системе в точные (насколько это возможно) определения. Обе методологии фокусируют внимание на потоках данных, их главное назначение - создание базированных на графике документов по функциональным требованиям. Методологии поддерживаются традиционными нисходящими методами проектирования и обеспечивают один из лучших способов связи между аналитиками, разработчиками и пользователями системы за счет интеграции следующих средств:

1. Диаграмм потоков данных.

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

3. Миниспецификации обработки, описывающие DFD-процессы нижнего уровня и являющиеся базой для кодогенерации.