2.2.1 Выбор средств моделирования

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

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

Структурный подход

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

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

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

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

IDEF3. Методология моделирования IDEF3 позволяет описать процессы, фокусируя внимание на течении этих процессов, позволяет рассмотреть конкретный процесс с учетом последовательности выполняемых операций.

ER (Entity-Relationship Diagrams) диаграммы "сущность-связь". Методология описания данных (IDEF1X).

Выводы по практическому использованию

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

Выводы по диаграммам:

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

Модели SADT (IDEF0) наиболее удобны при построении функциональных моделей. Они наглядно отражают функциональную структуру объекта: производимые действия, связи между этими действиями. Таким образом, четко прослеживается логика и взаимодействие процессов организации.  Главным достоинством нотации является возможность получить полную информацию о каждой работе, благодаря ее жестко регламентированной структуре.  С ее помощью можно выявить все недостатки, касающиеся как самого процесса, так и то, с помощью чего он реализуется: дублирование функций, отсутствие механизмов, регламентирующих данный процесс, отсутствие контрольных переходов и т.д.

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

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

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

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

Объектно-ориентированный подход

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

Рисунок 2.2 – Сравнительный анализ объектно-ориентированной и функционально-ориентированной декомпозиций

В 90-е годы появилось большое количество различных методологий с собственными наборами нотаций.

Язык UML (Unified Modeling Language) представляет собой общецелевой язык визуального моделирования, который разработан для спецификации, визуализации, проектирования и документирования компонентов программного обеспечения, бизнес-процессов и других систем.[2,3]

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

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

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

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

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

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

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

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

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

Выводы по практическому использованию

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

Методология ARIS

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

Методология ARIS включает большое количество методов моделирования, в том числе известных как диаграммы Чена ERM, язык UML (Unified Modeling Language), методики ОМТ (Object Modeling Technique), BSC (Balanced Scorecard) и т.п.

К преимуществам  методологии ARIS разработчики относят следующие:

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

• богатство методов, позволяет моделировать широкий спектр систем;

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

Выводы по практическому использованию

 1.      Часто у аналитиков знакомящихся с методологией ARIS возникает чувство, что ARIS может все, она решает все проблемы. Это ошибочное мнение. Методология ARIS решает совершенно конкретный круг задач. Если потребности сильно отличаются от возможностей ARIS (например, сбор требований), то подойдет более специализированное и дешевое решение. ARIS в значительно большей степени предназначен для целей управленческого консалтинга и последующей поддержки решений. Использование ARIS в рамках проекта автоматизации противоречит целям, положенным в основу этой методологии ее создателем.

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

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

4.        В случае принятия решения о качественной необходимости использования методологии необходимо иметь ввиду, что ARIS нельзя отнести к интуитивно понятным, она требует времени  на изучение, на осмысленное применение (вопрос хотя бы в том, что методология содержит больше 100 моделей!). Для успешного применения должны быть разработаны внутренние соглашения о моделировании и документировании.

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

1.      Целей проекта;

2.      Требований к информации необходимой для анализа и принятия решений в рамках конкретного проекта;

3.      Возможностей  подхода с учетом требований п. 2;

4.      Особенностей разрабатываемой/внедряемой информационной системы.

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

В данной работе было принято решение использовать структурный подход к моделированию. Подход дает возможность проведения глубокого анализа бизнес – процессов, выявления узких мест: комплексное применение позволяет выявить все возможные рассогласования и неточности. Применение универсальных графических языков моделирования IDEF0, IDEF3, DFD обеспечивает логическую целостность и полноту описания, необходимую для достижения точных и непротиворечивых результатов при моделировании предметной области в контексте «как есть» и «как должно быть».