Принципы объектного подхода (абстрагирование, инкапсуляция, модульность, иерархия)

CASE технологии

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

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

CASE-средства вместе с системным ПО и техническими средствами образуют полную среду разработки ИС.

Кроме того, CASE-средства обладают следующими характеристиками:

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

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

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

Все CASE-средства делятся на типы, категории и уровни.

Классификация по типам отражает функциональную ориентацию CASE-средств на те или иные процессы ЖЦ. Классификация по типам в основном совпадает с компонентным составом CASE-средств и включает следующие основные типы:

· средства анализа

· средства анализа и проектирования

· средства проектирования баз данных и файлов

· средства разработки приложений

· средства реинжиниринга

· средства окружения

· средства планирования управления проектом

· средства конфигурационного управления

· средства тестирования

· средства документирования

 

Классификация по категориям определяет уровень интегрированности по выполняемым функциям и включает:

· Вспомогательные программы

· Пакеты разработки

· Инструментальные средства

 

Помимо этого, CASE-средства можно классифицировать по следующим признакам:

 

· применяемым методологиям и моделям систем и БД;

· степени интегрированности с СУБД;

· доступным платформам.

 

Структурное проектирование, управляемое потоками данных

 

Структурное проектирование – состоит в детализации метода нисходящего проектирования.

Процесс декомпозиции в структурном проектировании основан на потоках данных в системе.

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

Процесс проектирования включает:

Шаг 1. Представление схемы потоков данных.

Шаг 2. Изображение структурной схемы проекта.

Шаг 3. Оценка проекта.

Шаг 4. Подготовка проекта для реализации.

 

Методы проектирования, управляемые структурами данных

 

Два метода проектирования, управляемые структурами данных:

- методология Джексона,

- методология Варнье-Орра.

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

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

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

 

Преимущества UML

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

-UML позволяет описать систему практически со всех возможных точек зрения и разные аспекты поведения системы;

Диаграммы UML сравнительно просты для чтения после достаточно быстрого ознакомления с его синтаксисом;

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

-UML получил широкое распространение и динамично развивается.

 

http://ooad.asf.ru/standarts/UML/ModelOrganizationsUML/

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

 

UML-модель применительно к бизнес-моделированию может включать в себя следующие диаграммы:

 1. Структурный аспект: Use-Case-диаграммы, идентифицирующие бизнес-процессы и бизнес-транзакции, их взаимосвязь, соподчиненность и взаимодействие; Package-диаграммы, структурно организующие предметную область и иерархически упорядоченную структуру организации.

 2. Динамический аспект: Behavior-диаграммы (Activity, Statechart, Collaboration, Sequence), описывающие поведение (жизненный цикл) бизнес-процесов в их взаимодействии во времени и в пространстве с привязкой к используемым ресурсам и получаемым результатам.

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

 

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

 

UML-модель в части бизнес-модели позволяет получить детальные ответы на ряд типичных вопросов деятельности организации:

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

- какие функционируют бизнес-процессы (функциональный аспект);

 -кто и где выполняет бизнес-процессы (организационный аспект);

 -как выполняются бизнес-процессы (методический аспект);

 -когда выполняются бизнес-процессы (динамический аспект);

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

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

Аспект моделирования---UML-диаграмма

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

Функциональный аспект---Use-Case-диаграммы

Организационный аспект---Package-диаграммы, Class-диаграммы

Методический аспект---Activity-диаграммы

Динамический аспект---Statechart-, Collaboration-, Sequence-диаграммы

Сущностно-элементный аспект---Class-диаграммы

Технологический аспект----Deployment-диаграммы

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

 

В UML используются следующие виды диаграмм

Структурные диаграммы:                                Диаграммы поведения:

Диаграмма классов                                                              Диаграмма деятельности

Диаграмма компонентов                                                      Диаграмма состояний

Композитной/составной структуры                                                   Диаграмма прецедентов

Диаграмма кооперации (UML2.0)

Диаграмма развёртывания

Диаграмма объектов

Диаграмма пакетов

Диаграмма профилей (UML2.2)

Диаграммы взаимодействия:

Диаграмма коммуникации (UML2.0) / Диаграмма кооперации (UML1.x)

Диаграмма обзора взаимодействия (UML2.0)

Диаграмма последовательности

Диаграмма синхронизации (UML2.0)

 

Диаграмма вариантов использования

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

В UML для вариантов использования и действующих лиц поддерживается несколько типов связей:

- связь коммуникаций (association relationship) – это связь между вариантами использования и действующим лицом

- включение (include relationship) – применяется в тех случаях, когда имеется какой-либо фрагмент поведения системы, которая повторяется более чем в одном варианте использования

- связь с расширением (extend relationship) – применяется при наличии изменений в нормальном поведении системы, которые также вносятся в отдельный вариант использования

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

 

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

 

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

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

Диаграммой последовательностей (Sequence diagram) называется диаграмма взаимодействия, на которой изображаются участвующие во взаимодействии объекты и последовательность сообщений, которыми они обмениваются. Одно из основных назначений данной диаграммы – отобразить последовательность действий для части или целого варианта использования (use case). На диаграмме последовательности объект изображается в виде прямоугольника на вершине пунктирной вертикальной линии. Эта линия называется "линией жизни" (life line) объекта. Сообщения появляются в том порядке, как они показаны на стрелке - сверху вниз.

 

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

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

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

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

 На переходе указывается имя события. Обозначения - в таблице.

Диаграмма компонентов

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

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

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

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

 

 

Диаграмма классов (Static Structure diagram) — статическая структурная диаграмма, описывающая структуру системы, демонстрирующая классы системы, их атрибуты, методы и зависимости между классами.

 

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

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

-точка зрения спецификации — диаграмма классов применяется при проектировании информационных систем;

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

 

Диаграмма компонентов

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

 

 

Диаграмма композитной/составной структуры (Composite structure diagram) — статическая структурная диаграмма, демонстрирует внутреннюю структуру классов и, по возможности, взаимодействие элементов (частей) внутренней структуры класса.

 

Подвидом диаграмм композитной структуры являются диаграммы кооперации (Collaboration diagram, введены в UML 2.0), которые показывают роли и взаимодействие классов в рамках кооперации. Кооперации удобны при моделировании шаблонов проектирования.

 

Диаграммы композитной структуры могут использоваться совместно с диаграммами классов.

 

Диаграмма развёртывания (Deployment diagram) — служит для моделирования работающих узлов (аппаратных средств, англ. node) и артефактов, развёрнутых на них. В UML 2 на узлах разворачиваются артефакты (англ. artifact), в то время как в UML 1 на узлах разворачивались компоненты. Между артефактом и логическим элементом (компонентом), который он реализует, устанавливается зависимость манифестации.

 

Диаграмма объектов ( Object diagram) — демонстрирует полный или частичный снимок моделируемой системы в заданный момент времени. На диаграмме объектов отображаются экземпляры классов (объекты) системы с указанием текущих значений их атрибутов и связей между объектами.

 

Диаграмма пакетов (Package diagram) — структурная диаграмма, основным содержанием которой являются пакеты и отношения между ними. Жёсткого разделения между разными структурными диаграммами не проводится, поэтому данное название предлагается исключительно для удобства и не имеет семантического значения (пакеты и диаграммы пакетов могут присутствовать на других структурных диаграммах). Диаграммы пакетов служат, в первую очередь, для организации элементов в группы по какому-либо признаку с целью упрощения структуры и организации работы с моделью системы.

 

Диаграмма деятельности (Activity diagram) — диаграмма, на которой показано разложение некоторой деятельности на её составные части. Под деятельностью (англ. activity) понимается спецификация исполняемого поведения в виде координированного последовательного и параллельного выполнения подчинённых элементов — вложенных видов деятельности и отдельных действий (англ. action), соединённых между собой потоками, которые идут от выходов одного узла к входам другого.

 

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

 

Диаграмма вариантов использования (Use case diagram) — диаграмма, на которой отражены отношения, существующие между акторами и вариантами использования.

 

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

 

Диаграмма автомата (State Machine diagram, диаграмма конечного автомата, диаграмма состояний) — диаграмма, на которой представлен конечный автомат с простыми состояниями, переходами и композитными состояниями.

 

Конечный автомат (англ. State machine) — спецификация последовательности состояний, через которые проходит объект или взаимодействие в ответ на события своей жизни, а также ответные действия объекта на эти события. Конечный автомат прикреплён к исходному элементу (классу, кооперации или методу) и служит для определения поведения его экземпляров.

 

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

 

Диаграмма коммуникации (Communication diagram, в UML 1.x — диаграмма кооперации, collaboration diagram) — диаграмма, на которой изображаются взаимодействия между частями композитной структуры или ролями кооперации. В отличие от диаграммы последовательности, на диаграмме коммуникации явно указываются отношения между элементами (объектами), а время как отдельное измерение не используется (применяются порядковые номера вызовов).

 

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

 

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

 

По причине того, что диаграммы Sequence и Collaboration являются разными взглядами на одни и те же процессы, Rational Rose позволяет создавать из Sequence диаграммы диаграмму Collaboration и наоборот, а также производит автоматическую синхронизацию этих диаграмм.

 

Диаграмма обзора взаимодействия (Interaction overview diagram) — разновидность диаграммы деятельности, включающая фрагменты диаграммы последовательности и конструкции потока управления.

 

Этот тип диаграмм включает в себя диаграммы Sequence diagram (диаграммы последовательностей действий) и Collaboration diagram (диаграммы сотрудничества). Эти диаграммы позволяют с разных точек зрения рассмотреть взаимодействие объектов в создаваемой системе.

 

Диаграмма синхронизации (Timing diagram) — альтернативное представление диаграммы последовательности, явным образом показывающее изменения состояния на линии жизни с заданной шкалой времени. Может быть полезна в приложениях реального времени.

 

 

13. Отличия UML от IDEF0, DFD

 

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

· структурный подход, поддерживаемый методологией системного анализа и проектирования Structure Analysis and Design Technique (SADT)-IDEF0, DFD;

· объектно-ориентированный подход, поддерживаемый методологией Rational Unified Process (RUP) и языком моделирования Unified Modeling Language (UML).

IDEF0 И DFD

 

Механизмы расширения UML предназначены для того, чтобы разработчики могли адаптировать язык моделирования к своим конкретным нуждам, не меняя при этом его метамодель. Наличие механизмов расширения принципиально отличает UML от таких средств моделирования, как IDEF0, IDEF1X, IDEF3, DFD и др. Перечисленные языки моделирования можно определить как сильно типизированные (по аналогии с языками программирования), поскольку они не допускают произвольной интерпретации семантики элементов моделей. UML, допуская такую интерпретацию (в основном за счет стереотипов), является слабо типизированным языком.

14. Основные понятия моделирования бизнес-процессов.

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

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

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

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

Моделью бизнес-процесса называется его формализованное (графическое, табличное,

текстовое, символьное) описание, отражающее реально существующую или предполагаемую деятельность предприятия. Модель, как правило, содержит следующие сведения о бизнес-процессе:

· набор составляющих процесс шагов — бизнес-функций

· порядок выполнения бизнес-функций;

· механизмы контроля и управления в рамках бизнес-процесса;

· исполнителей каждой бизнес-функции;

· входящие документы/информацию, исходящие документы/информацию;

· ресурсы, необходимые для выполнения каждой бизнес-функции;

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

· параметры, характеризующие выполнение бизнес-функций и процесса в целом.

Для моделирования бизнес-процессов можно использовать различные методы. Метод, или методология, моделирования включает в себя последовательность действий, которые необходимо выполнить для построения модели, т. е. процедуру моделирования, и применяемую нотацию (язык). Наиболее популярной методологией бизнес-моделирования является ARIS, но также известны Catalyst компании CSC, Business Genetics, SCOR (Supply \ Chain Operations Reference), POEM (Process Oriented Enterprise Modeling) и др. Язык моделирования имеет свой синтаксис (условные обозначения различных элементов и правила их сочетания) и семантику (правила толкования моделей и их элементов).

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

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

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

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

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

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

· функциональные, описывающие совокупность выполняемых системой функций и их входы и выходы;

· поведенческие, показывающие, когда