Особенности построения функциональной модели с использованием IDEF. Общая характеристика DFD.

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

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

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

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

Различают следующие виды разветвлений:

• Классификация объектов, которая уточняет тип обрабатываемого в дальнейшем объекта. Например, класс объектов Заказ делится на подклассы Заказ нового клиента, Заказ старого клиента (рис.3.4). Разветвление в этом случае обеспечивает альтернативность путей выполнения процесса реализации заказа клиента. При этом каждый путь должен быть помечен именем подтипа объекта.

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

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

п»ї

Объединение путей на диаграмме соответственно обеспечивает:

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

• Агрегация объектов, когда несколько компонентов образуют один объект.

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

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

• Повтор операций после контроля и отбраковки объектов. Например, повторная поставка товара после неакцепта накладной

 

27. Особенности построения функциональной модели с использованием DFD. Сущность объектно-ориентированное моделирование бизнес-процес­сов с использованием ППП.

Объектно-ориентированная методология предполагает разработку моделей бизнес-процессов на нескольких уровнях детализации:

• П-модели (Use - Case Model) - модели прецедентов использования,

• О-модели (Object Model) – объектной модели,

• В-модели (Object Interaction Model) – модели взаимодействия объектов.

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

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

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

 

28. Модель прецедентов использования (П-мо­дель).

 

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

Актор инициирует выполнение прецедента и получает от него результаты. Взаимодействие (ассоциация) актора с прецедентом осуществляется путем обмена сообщениями или посредством коммуникации (рис. 5.1.)

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

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

 

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