Когда я прочел статью Павла Сахарова и попытался ему возразить, то обнаружил, что для меня не так очевиден его основной тезис, несмотря на то, что он, казалось бы, четко сформулирован.
Продолжаем обсуждение публикации Павла Сахарова в ноябрьском номере «Директора». Приводим мнение одного из наших читателей по этой проблеме
Когда я прочел статью Павла Сахарова и попытался ему возразить, то обнаружил, что для меня не так очевиден его основной тезис, несмотря на то, что он, казалось бы, четко сформулирован. Пытался ли автор доказать, что Rational Rose как инструментальное средство менее удобно при моделировании бизнес-процессов, чем BPwin, как это явствует из заглавия его статьи?
Если так, то возражать неинтересно и, более того, бессмысленно, так как выбор средства — это, вообще говоря, дело вкуса. На самом же деле многие его аргументы направлены не против Rational Rose как средства, а против нотации UML и объектно-ориентированного подхода к моделированию в целом. Спрашивается тогда, а является ли нотация UML безусловно лучше (или хуже) для целей моделирования бизнес-процессов? Является ли объектно-ориентированный метод безусловно более (или менее) подходящим для этого? Конечно, нет, все зависит от тех условий, в которых проводится моделирование, и от целей, с которыми оно проводится.
Таким образом, при выборе средств моделирования бизнес-процессов мы должны исходить из конкретной ситуации, в которой будет проводиться моделирование, причем учитывать требования, предъявляемые в этой ситуации отдельно к методу моделирования, отдельно к нотации, применяемой при моделировании, и отдельно — к выбору инструментального средства моделирования. Если при дальнейшем обсуждении придерживаться этого подхода, можно избежать многих недоразумений и недопонимания.
В аргументах, которые автор приводит в доказательство преимущества IDEF0 и BPWin, надо обратить внимание на фактические неточности, касающиеся UML и Rational Rose. Например, нельзя согласиться с такими утверждениями, как «Rational Rose не поддерживает ни одну из известных методологий моделирования», «диаграммам UML не дается никакой интерпретации», а также предложение подкрашивать стрелки на диаграммах различными цветами, чтобы имитировать различные виды входов. Можно было бы сразу сказать, что семантика UML определена в его спецификации [3], а механизмы расширения языка [4] позволяют строго определить нотацию для бизнес-моделирования [5].
Однако я бы хотел обратить внимание на положения статьи, спорность которых не столь очевидна. В качестве основного преимущества IDEF0 и BPWin перед UML и Rational Rose автор называет возможность автоматической проверки получаемой модели на корректность с точки зрения формального синтаксиса. Но является ли на самом деле формальная корректность основным требованием к модели бизнес-процессов?
Обратимся к аналогии с программированием. Любая система программирования предоставляет средства для формальной проверки синтаксиса программ. Необходимость этого очевидна — ведь программы исполняются машинами. Однако, как известно, основной проблемой при программировании является достижение не формальной, а содержательной правильности программы.
Этого добиваются, делая программы понятными для людей, а не только для машин. Для этого разрабатываются новые языки программирования, имеющие все более мощные выразительные средства.
Аналогично при моделировании бизнес-процессов основным требованием является содержательная правильность модели, которая может быть достигнута только за счет ее понятности. Корректность же с точки зрения формального синтаксиса не так важна, поскольку модели предназначены для чтения прежде всего людьми, а не машинами. Для повышения понятности моделей разрабатываются новые языки моделирования, которые имеют все более развитые выразительные средства.
Далее я излагаю свою точку зрения. Суть ее состоит в том, что объектно-ориентированный подход мне кажется наиболее приемлемым, если модель предназначается для последовательного уточнения понимания предметной области, усовершенствования бизнес-процессов, повышения эффективности коллективной работы и обмена знаниями между участвующими сторонами. Я считаю, что при моделировании чаще всего преследуют именно эти цели. В других ситуациях соображения могут быть иными. Например, если требуется получить максимально формальную модель, требования к выбору средств моделирования закладываются в контракт или же определяются опытом и привычками участвующих сторон.
Требования к модели бизнес-процессов
Моделирование бизнес-процессов можно выполнять с применением различных подходов, методологий, нотаций и инструментальных средств — в зависимости от требований к модели в каждом конкретном случае. Чем определяются эти требования? Во многом — процессом создания системы автоматизации в целом, в рамках которого проводится моделирование предметной области. Этот процесс определяет, каким образом будет строиться, уточняться и использоваться модель.
Как правило, система создается коллективом людей. Эти люди имеют различные специальности, опыт, привычки, образование, предпочтения и личные качества. Модель бизнес-процессов строится для того, чтобы эти люди могли эффективно обмениваться знаниями и совместно принимать решения по ходу создания системы. Модель является языком общения между сторонами, участвующими в создании системы автоматизации, — заказчиками, экспертами, архитекторами и т. д. Она должна быть организована таким образом, чтобы каждая сторона, воспринимающая моделируемую систему с собственной точки зрения, могла эффективно вносить свой вклад в общее понимание предметной области. Подмножество модели, показывающее систему с той или иной точки зрения, должно быть логически замкнутым.
Процесс создания автоматизированной системы часто оказывается итеративным, поэтому модель должна допускать последовательные уточнения. В идеале модель должна строиться таким образом, чтобы при ее детализации не изменялись ранее построенные более общие элементы модели, а только добавлялись бы новые.
Модель должна быть устойчива к изменениям предметной области. Это значит, что она должна быть организована таким образом, чтобы при изменениях предметной области изменялся только некоторый минимально необходимый набор элементов модели. Более того, модель сама должна быть инструментом реорганизации бизнес-процессов в рамках создания системы автоматизации.
Рассмотрим теперь, как, пользуясь объектным подходом, можно построить модель, удовлетворяющую этим требованиям.
Подход к моделированию
Объектный подход к моделированию является одновременно и структурным в том смысле, что создаваемая модель представляет собой декомпозицию моделируемой системы на отдельные взаимосвязанные компоненты. Отличие же от структурного подхода в традиционном понимании состоит в том, что компоненты модели группируются вокруг участников моделируемых бизнес-процессов и тех целей, которые они преследуют, участвуя в этих процессах.
При объектном подходе к моделированию одним из основных средств описания действительности являются use cases (UC, часто переводится как «варианты использования»). Однако часто под UC понимают лишь эллипс на UC-диаграмме UML. Нередко при помощи UC-диаграмм пытаются описать динамические аспекты моделируемой системы, например сценарии взаимодействия участников системы. Когда это плохо удается, говорят, что UC плохо подходят для описания процессов.
Что же такое UC? При описании какой-либо программной системы UC часто соответствует режиму или экрану пользовательского интерфейса. Чем же является UC при описании системы бизнес-процессов? В [1] UC определяется как совокупность всех вариантов поведения системы в ответ на запрос некоторого участника процесса, преследующего этим конкретную цель.
UC-модель, таким образом, представляет собой систему взаимосвязанных целей участников процесса и является основой для организации всей модели описываемой системы бизнес-процессов. UC-диаграммы являются частными взглядами на UC-модель и показывают взаимосвязи между участниками процесса и их целями.
На рис. 1 в качестве примера приведена часть UC-модели, которая могла бы быть результатом моделирования работы кредитного отдела банка. Она состоит из основного UC «Воспользоваться банковским кредитом» (UC1) и связанного с ним UC «Принять решение о предоставлении кредита» (UC2). На рис. 2 показаны примеры UC-диаграмм, иллюстрирующих частные взгляды на UC-модель с точки зрения выдачи кредита и его погашения.
Как видно из рис. 1, каждый UC указывает основное действующее лицо — участника процесса, преследующего некоторую цель и инициировавшего для этого взаимодействие с системой. Например, клиент, желающий получить в банке кредит, является основным действующим лицом в UC1 «Воспользоваться банковским кредитом».
 |
| Рис. 1. Часть UC-модели кредитного отдела банка |
Кроме того, UC содержит совокупность всевозможных сценариев, которые могут последовать при достижении действующим лицом своей цели. При этом единственный основной сценарий соответствует нормальному развитию событий, то есть такому, при котором не возникает никаких нештатных ситуаций.
Например, в UC1 «Воспользоваться банковским кредитом» основным является сценарий, при котором банк дает положительное решение о предоставлении кредита, клиент получает кредит, а затем погашает его по установленному графику. Альтернативные сценарии начинаются так же, как и основной, но в какой-то момент развитие событий идет по другому пути. В нашем примере это может быть сценарий, при котором клиент не выплачивает очередной взнос, предусмотренный графиком погашения кредита (рис. 1, UC1, п. 2.2). При этом опять же вероятны альтернативные сценарии более низких уровней. Так, если клиент в течение льготного срока восстанавливает график погашения, то сценарий воссоединяется с основным сценарием, если же клиент не выплачивает задолженность, кредит считается просроченным и т. д.
Каждый сценарий UC состоит из ряда шагов. Причем на каждом шаге определенный участник процесса также преследует свою определенную цель, т. е. каждый шаг сценария может являться UC более низкого уровня. Например, при кредитовании банку необходимо принять обоснованное решение о возможности выдачи кредита с целью минимизации риска. Процесс принятия такого решения в нашей UC-модели отражен в описании UC2 (рис. 1).
Последовательно разрабатывая систему таких UC, мы постепенно получаем модель бизнес-процессов, построенную вокруг участников процессов и их целей. Причем на каждом шаге мы имеем модель определенного уровня детальности, которая, скорее всего, не будет изменяться при уточнении модели — к ней лишь будут добавляться дополнительные уровни при детализации шагов сценариев в UC. С помощью традиционных структурных методов создать модель, в которой построенные компоненты не изменялись бы при уточнении модели, на мой взгляд, гораздо сложнее.
Модель бизнес-процессов, помимо UC и действующих лиц, может содержать и другие элементы, помогающие лучше понять предметную область или обосновывать те или иные модельные решения. Описание UC1, например, ссылается на формы документов (пп. 1.1 и 1.3) и на бизнес-правила (п. 2.2.2).
Моделирование на основе UC, на мой взгляд, лучше способствует также пониманию модели бизнес-процессов людьми, которым предстоит ее читать, рецензировать и исправлять, развивать и, наконец, пользоваться ею. Цели участников бизнес-процессов являются своего рода движущей силой, и человеку, читающему модель, легко представить себе, что именно требуется сделать, чтобы достичь той или иной цели. В то же время из структуры процессов, получаемой структурными методами моделирования, бывает трудно понять, зачем применяется тот или иной процесс, а также увидеть недостатки модели или самого бизнес-процесса — нужна ли эта функция, можно ли ее заменить другой и чьи интересы это затронет.
Я попытался показать, что подход к осмыслению бизнес-процессов через понимание интересов их участников и соответствующая организация модели бизнес-процессов обладают преимуществами по сравнению с моделью, получаемой традиционными структурными методами. При этом речь шла об инструментах, предлагаемых самим объектно-ориентированным подходом, не касаясь какой-либо конкретной нотации.
Нотация представления моделей
Следуя предложенной ранее структуре, рассмотрим теперь способы представления моделей — нотации. В нотации UML для представления UC-моделей чаще всего используются UC-диаграммы, а также диаграммы деятельности и диаграммы последовательности (activity- и sequence-диаграммы соответственно). Часто возникают споры о выразительных возможностях этих диаграмм.
Пожалуй, больше всего нареканий вызывают UC-диаграммы как наименее выразительные. Однако, на мой взгляд, это происходит из-за того, что во многих учебниках по объектно-ориентированному моделированию эти диаграммы затронуты лишь вскользь, приведены лишь примитивные примеры и не объяснено, что же именно изображают эти диаграммы.
Если принять подход к организации модели, подобный описанному выше, то система UC-диаграмм окажется не чем иным, как оглавлением к модели. На UC-диаграммах могут быть показаны участники процессов и цели, которые они преследуют.
На диаграммах могут быть показаны взаимосвязи UC, то есть промежуточные цели, которые могут достигаться при достижении цели более высокого уровня (см., например, рис. 2). Однако только в простейших случаях UC-диаграмма отображает целиком структуру того или иного процесса, то есть все его подпроцессы. UC-диаграмма никогда не отображает последовательность действий в этом процессе.
Для отображения последовательности действий служат диаграммы деятельности и последовательности. Первые являются разновидностью блок-схем. С их помощью в принципе можно отобразить UC целиком, включая основной и все альтернативные сценарии. Диаграммы последовательности применяются для иллюстрации какого-то отдельного сценария.
Обе эти диаграммы имеют свои аналоги в структурных методах. Судить об их выразительности — это спорить о вкусах, нужно только принимать во внимание, что в UML заложены механизмы расширения, позволяющие доопределять семантику стандартных элементов диаграмм. Раскрашивать диаграммы при этом совершенно не обязательно. С помощью доопределенной семантики можно строить формальные модели, проверять их на полноту и непротиворечивость — подобно тому, как это делается для нотаций, применяемых в других методах.
Для представления сценариев, входящих в UC, можно выбирать любые другие способы. Мне кажется, что в большинстве случаев одни только диаграммы не могут ясно отобразить совокупность сценариев в сложных UC, даже если для описания одного UC использовать несколько диаграмм. Более подходящим способом представления событий, образующих UC, является не диаграмма, а структурированный текст.
Пример такого текстового описания приведен на рис. 1. Подобный подход описан, в частности, в [1], а также используется в RUP [2]. Формально это можно делать не выходя за рамки UML, так как любые текстовые описания по стандарту также являются элементами языка. Тем не менее диаграммы могут применяться для иллюстрации каких-нибудь особенно важных для понимания или наиболее запутанных моментов.
Инструментальные средства
Проводить сравнение инструментальных средств, поддерживающих тот или иной подход, ту или иную нотацию, довольно трудно. Я готов согласиться с критиками Rational Rose, что это средство не является ни лучшим, ни вообще достаточным инструментом для моделирования в целом и моделирования бизнес-процессов в частности. Дело здесь, видимо, и в том, что средства, поддерживающие структурные подходы, развивались уже много лет, а объектно-ориентированные средства моделирования еще достаточно молоды. Следует сказать, однако, что принципиальных препятствий к созданию средств, осуществляющих формальную проверку UML-моделей на полноту и непротиворечивость, а также получение по моделям различных отчетов, не существует.
Удобным, на мой взгляд, способом организации как текстовых описаний UC, так и диаграмм является репозитарий — система хранения документов, позволяющая создавать гипертекстовые связи между документами. Рис. 1 и 2 показывают, как могли бы выглядеть UC и диаграммы в репозитарии. Синим цветом на этих рисунках выделены гипертекстовые ссылки, связывающие элементы модели между собой.
Такая система могла бы не только организовывать и хранить элементы модели, но и строить на основе данных этой модели различные отчеты и проверять модель в соответствии с задаваемыми правилами. Существует успешный опыт организации такого репозитария на базе Lotus Notes.
Выбор подхода к моделированию непосредственно зависит от требований к модели, от способа ее использования. Наиболее часто модель бизнес-процессов используется для поддержки совместной работы людей, участвующих в создании автоматизированной системы, для обеспечения коллективного принятия решений.
Этой задаче отвечает модель, полученная при правильном применении объектно-ориентированного подхода. Однако выбор такого подхода не навязывает ни выбора какой-либо определенной нотации, ни тем более выбора инструментального средства. Тем не менее нотация UML может быть эффективно использована наряду с другими способами представления, например структурированным текстом. Что касается инструментальных средств, то тут, к сожалению, я не знаю средств объектно-ориентированного моделирования, которые были бы так же удобны в использовании, как известные средства, поддерживающие структурные методы.
Источник: www.osp.ru
Моделирование. Требования к моделям бизнес-процессов. Классификация моделей. Моделирование бизнеса на языке UML
Часть 2. Моделирование
Тема 2.1. Требования к моделям бизнес-процессов
Классификация моделей
Модель есть отображение (представление) объекта, системы или понятия в
некоторой форме, отличной от формы их реального существования
Модели
Из реальных объектов
(макеты, тренажеры)
Математические
закономерности
не учитывают
временной параметр
Реальные
Абстрактные
Формальные
Семантические
Статические
Динамические
Созданные средствами
мышления
Сохраняется смысл
(схемы, диаграммы)
отображают поток
событий
2. Состав модели бизнеса
Часть 2. Моделирование
Тема 2.1. Требования к моделям бизнес-процессов
Состав модели бизнеса
1. Функция компании во внешнем мире: описание окружения, основные
бизнес-процессы, а также взаимодействие процессов с окружением
2. Описание бизнес-процессов, отдельных шагов процессов (функций,
работ, операций).
3. Описание объектов, участвующих в выполнении бизнес-процессов
или обрабатываемых, создаваемых бизнесом и отношений между
объектами.
Требования к методологиям моделирования бизнеса:
• методология должна позволять строить понятные и обозримые модели;
• лучше использовать интегрированную методологию;
язык описания модели должен быть выразителен, но достаточно
формализован;
желательно, чтобы методология поддерживалась инструментальными
компьютерными системами
3. Объектно-ориентированный язык UML
Часть 2. Моделирование
Тема 2.2. Моделирование бизнеса на языке UML
Объектно-ориентированный язык UML
Язык UML был разработан для создания моделей информационных систем (ИС)
с целью их последующей реализации в виде объектно-ориентированных программ.
Все представления о модели сложной системы фиксируются в виде диаграмм специальных графических конструкций (схем, графов).
Имеется 8 основных типов диаграмм UML, отражающих различные аспекты:
процессы, выполняемые системой (предоставляемые пользователю сервисы),
последовательность выполняемых системой алгоритмических операций,
структуру программных объектов (состав атрибутов и процедур),
их взаимодействие (обмен сообщениями) и т.д.
В технологии РБП язык UML применяется не только и не столько для создания ИС,
сколько для анализа и перепроектирования бизнес-процессов:
вместо моделей процессов ИС строятся модели бизнес-процессов,
вместо программных объектов в моделях отражаются объекты бизнес-процессов
(исполнители, продукция, услуги и т.д.),
вместо окружения ИС (пользователей ИС) моделируется окружение бизнеса
(поставщики, партнеры, клиенты).
4. Прецедентная модель бизнес-процесса
Часть 2. Моделирование
Тема 2.2. Моделирование бизнеса на языке UML
Прецедентная модель бизнес-процесса
Внешняя диаграмма – диаграмма вариантов использования
(Use Case Diagram )
продукт
Распространитель
Актор
Маркетинг и
сбыт
сырье
Производство
Поставщик
продукт
Продажа
продукта
Клиент
проект
Партнер
Разработка
продукта
сервис
Сервисное
обслуживание
Прецедент
5. Прецедентная модель бизнес-процесса
Часть 2. Моделирование
Тема 2.2. Моделирование бизнеса на языке UML
Прецедентная модель бизнес-процесса
Прецедентом (вариантом использования) в UML называется законченная
совокупность действий моделируемой системы, начинающаяся при
получении стимула извне и заканчивающаяся предоставлением некоторого
продукта или сервиса актору – пользователю системы .
Экземпляр прецедента – конкретный прецедент,
класс прецедентов — обобщенный прецедент.
Акторами (субъектами) в модели бизнеса являются элементы окружения –
клиенты, партнеры, поставщики.
Класс акторов описывает общие характеристики некоторого типа акторов,
экземпляр – характеристики конкретного актора.
Между прецедентами и акторами могут быть установлены отношения
коммуникации (communicate).
Они отражают взаимосвязи прецедентов с окружением (материальные,
энергетические и информационные потоки).
6. Поток событий прецедента
Часть 2. Моделирование
Тема 2.2. Моделирование бизнеса на языке UML
Поток событий прецедента
Поток событий — описание прецедентов последовательностью шагов
Поток событий прецедента «Продажа продукта»:
1. Продавец получает заявку клиента
2. Если в заявке указан готовый продукт, то Продавец проверяет наличие
продукта на складе. Если продукта нет в наличии, прецедент заканчивается.
Если продукт есть на складе, то прецедент продолжается с шага 6.
3. Если в заявке указывается заказной продукт, то Продавец формирует заказ и
передает его Изготовителю продукта.
4. Изготовитель изготавливает продукт в соответствии с требованиями клиента и
сообщает о готовности Продавцу.
5. Изготовитель отправляет продукт на Склад.
6. Продавец сообщает Клиенту о готовности продукта и принимает от Клиента
оплату.
7. Продавец сообщает Отправителю количество продукта и адрес клиента и
заказывает транспорт.
8. Отправитель получает продукт со склада и доставляет его клиенту.
7. Диаграмма деятельности (Activity diagram)
Часть 2. Моделирование
Тема 2.2. Моделирование бизнеса на языке UML
Диаграмма деятельности (Activity diagram)
Получить заявку
Проверить заявку
Указан готовый продукт
Указан заказной продукт
Проверить
наличие на складе
Нет продукта
Передать заказ
изготовителю
Изготовить продукт
имеется
Отправить на склад
Принять оплату
Заказать транспорт
Доставить продукт
8. Структурирование прецедентов
Часть 2. Моделирование
Тема 2.2. Моделирование бизнеса на языке UML
Структурирование прецедентов
Первый способ — использовании отношения включения (include).
Диаграмма вариантов использования
Получить заявку
Проверить заявку
Указан готовый
продукт
Проверить
наличие на
складе
Указан заказной
продукт
Передать заказ
изготовителю
Изготовить
продукт
Нет
продукта
имеется
Отправить
на склад
Клиент
Диаграмма
деятельности
прецедента
«Продажа
продукта»
Продажа продукта
Исполнение заказа
Получить заявку
Диаграмма
деятельности
прецедента
«Исполнение
заказа»
Проверить заявку
Указан готовый продукт
Проверить
наличие на складе
Нет
продукта
Указан
заказной
продукт
Исполнение
заказа
имеется
Принять оплату
Принять оплату
Заказать транспорт
Заказать транспорт
Доставить продукт
Доставить продукт
Передать заказ
изготовителю
Изготовить
продукт
Отправить на
склад
9. Структурирование прецедентов
Часть 2. Моделирование
Тема 2.2. Моделирование бизнеса на языке UML
Структурирование прецедентов
Второй способ — использовании отношения обобщения (generalization)
Диаграмма деятельности
прецедента «Продажа
готового продукта»
Диаграмма вариантов
использования
Диаграмма деятельности
прецедента «Продажа
заказного продукта»
Клиент
Получить заявку
на готовый
продукт
Проверить
наличие на
складе
Нет
продукта
имеется
Принять оплату
Получить заявку
на заказной
продукт
Передать заказ
изготовителю
Изготовить
продукт
Отправить на
склад
Принять оплату
Заказать
транспорт
Заказать
транспорт
Доставить
продукт
Доставить
продукт
Продажа готового
продукта
Диаграмма деятельности
прецедента «Продажа
готового продукта»
Получить заявку
на готовый
продукт
Проверить
наличие на
складе
Нет
продукта
имеется
Общий вид
продаж
Общий вид
продаж
Диаграмма
деятельности
прецедента «Общий
вид продаж»
Принять
оплату
Заказать
транспорт
Доставить
продукт
Продажа заказного
продукта
Диаграмма деятельности
прецедента «Продажа
заказного продукта»
Получить заявку на
заказной продукт
Передать заказ
изготовителю
Изготовить продукт
Отправить на склад
Общий вид
продаж
10. Объектная модель бизнес-процесса
Часть 2. Моделирование
Тема 2.2. Моделирование бизнеса на языке UML
Объектная модель бизнес-процесса
Раскрывает внутреннее устройство бизнеса: какие виды ресурсов используются для
реализации прецедентов и каким образом они взаимодействуют.
Объекты представляют участников процессов (исполнителей, менеджеров) и
различного рода сущности (продукцию, предметы, задачи и т.д.).
Участники процессов называются активными объектами, сущности – пассивными.
Классы объектов описывают общие характеристики некоторого типа объектов,
экземпляры описывают характеристики конкретного объекта.
Выделяют следующие категории (роли) объектов:
1. Интерфейсные (Boundary) – активные объекты, взаимодействующие с
окружением, т.е. с акторами. Примеры – Продавец, Регистратор, Секретарь..
2. Управляющие (Control) – активные объекты, участвующие в выполнении
процессов, но не имеющие контакта с окружением. Примеры – Разработчик
продукции, Изготовитель, Менеджер проекта..
3. Объекты-сущности (Entity) – пассивные объекты, которые обрабатываются
бизнесом. Примеры – Продукция, Заказ, Извещение.
11. Статическая диаграмма взаимодействия
Часть 2. Моделирование
Тема 2.2. Моделирование бизнеса на языке UML
Статическая диаграмма взаимодействия
Диаграмма кооперации (Collaboration Diagram)
2: передача заказа
Продавец /и
1: подача заявки
5: сообщение
6: оплата
10: доставка
создает
3: сообщение о
готовности
использует
создает
использует
Заказ /с
7: заказ
транспорта
Клиент
Изготовитель /у
4: отправка
продукта
Продукт /с
доставляет
хранит
8: запрос
Отправитель /и
Склад /у
9: отгрузка
— отношение сообщения (message)
— отношение связи (link)
12. Динамическая диаграмма взаимодействия
Часть 2. Моделирование
Тема 2.2. Моделирование бизнеса на языке UML
Динамическая диаграмма взаимодействия
Диаграмма последовательности (Sequence Diagram)
Продавец
Изготовитель
Склад
Отправитель
Клиент
Подача
заявки
Передача заказа
Сообщение о
готовности
Сообщение
Оплата
Отправка
продукта
Заказ транспорта
Запрос
Отгрузка
Доставка продукта
13. Описание объектов
Часть 2. Моделирование
Тема 2.2. Моделирование бизнеса на языке UML
Описание объектов
Описание объекта состоит из 2х частей: описание свойств и поведения.
Для описания свойств используется диаграмма классов (Class diagram)
Отношение
обобщения
Атрибуты
Заказ
Документ
Клиент: Class
Продукт: Class
Отношение
включения
Клиент
ФИО: String
Адрес: String
Номер: Integer
Дата: String
Продукт
Наименование: String
Количество: Integer
Цвет: String
14. Описание объектов
Часть 2. Моделирование
Тема 2.2. Моделирование бизнеса на языке UML
Описание объектов
Описание поведения объекта заключается в выявлении всех его обязательств
Продажа заказного продукта
Продавец
подача заявки
сообщение
оплата
передача заказа
сообщение о
готовности
Все виды продаж
Продавец
подача заявки
заказ транспорта
запрос на склад
Продажа готового продукта
Продавец
подача заявки
сообщение
оплата
запрос на склад
сообщение о
наличии
заказ транспорта
передача заказа
сообщение
оплата
сообщение о
готовности
сообщение о
наличии
заказ транспорта
15. IDEF0-модель бизнес-процесса
Часть 2. Моделирование
Тема 2.2. Моделирование по методологии IDEF
IDEF0-модель бизнес-процесса
Диаграмма А-0 «Продажа заказного продукта»
Сроки
( )
Заявка
Инструкции
( )
Продажа
заказного
продукта
Деньги
Материалы
Транспорт
Оборудование
Продавец
Изготовитель
Отправитель
Склад
Доставленный
продукт
16. IDEF0-модель бизнес-процесса
Часть 2. Моделирование
Тема 2.2. Моделирование по методологии IDEF
IDEF0-модель бизнес-процесса
Диаграмма первого уровня
I1
заявка
I3
I2
Получить
заявку
А1
материалы
деньги
M1
продавец
заказ
адрес клиента
описание продукта
готовый продукт
Изготовить и
информация о
хранить
выполнении
продукт
А2
Получить
оплату
А3
M5
оборудование
M3
M2 склад
изготовитель
информация
об оплате
Доставить
продукт
А4
M4
отправитель
доставленный
продукт
M5
транспорт
O1
17. Функционально-стоимостной анализ бизнес-процесса
Часть 2. Моделирование
Тема 2.2. Моделирование по методологии IDEF
Функционально-стоимостной анализ
бизнес-процесса
Функционально-стоимостной анализ (ФСА, Activity Based Costing — ABC)
позволяет проанализировать себестоимость бизнес-процессов
Стоимостные объекты — выходы функциональных блоков IDEF0-модели.
Стоимость выходов равна стоимости выполнения соответствующей функции.
Стоимость выполнения функции определяется через стоимость используемых
ресурсов, представленных как входные дуги, дуги управления и механизмов
График работ
Сырье
Изготовление
изделия
Ресурсы
Оборудование
Персонал
Готовое
изделие
Стоимостной
объект
18. Функционально-стоимостной анализ бизнес-процесса
Часть 2. Моделирование
Тема 2.2. Моделирование по методологии IDEF
Функционально-стоимостной анализ
бизнес-процесса
Определение стоимости родительского блока через стоимости дочерних блоков
Рабочая сила = 6500
Оборудование = 3000
Материалы = 2500
Общая стоимость = 12000
Изготовление
изделия
Рабочая сила = 3000
Оборудование = 1500
Материалы = 2500
Общая стоимость = 7000
Изготовление
деталей
Рабочая сила = 2000
Оборудование = 1000
Материалы = 0
Общая стоимость = 3000
Сборка
изделия
Контроль
качества
Рабочая сила = 1500
Оборудование = 500
Материалы = 0
Общая стоимость = 2000
Центры
стоимости
Источник: ppt-online.org