19274

Методология ARIS. Диаграммы переходов состояний (State Transition Diagram, STD). Структурные карты Константайна

Лекция

Информатика, кибернетика и программирование

Лекция 6. Методология ARIS. Диаграммы переходов состояний State Transition Diagram STD. Структурные карты Константайна. Структурные карты Джексона. Метод EricssonPenker. Метод моделирования используемый в технологии Rational Unified Process 6.1. Методология ARIS Методология ARIS реализует принцип...

Русский

2013-07-11

196.42 KB

66 чел.

Лекция 6.

Методология ARIS. Диаграммы переходов состояний (State Transition Diagram, STD). Структурные карты Константайна. Структурные карты Джексона. Метод Ericsson-Penker. Метод моделирования, используемый в технологии Rational Unified Process

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

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

Методология ARIS основана на разработанной профессором А.-В. Шеером теории «Архитектура интегрированных информационных систем» (Architecture of Integrated Information SystemARIS).

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

Методология ARIS рассматривает предприятие как совокупность четырех взглядов (views):

  •  взгляд на организационную структуру;
  •  взгляд на функции;
  •  взгляд на данные;
  •  взгляд на процессы.

При этом каждый из этих взглядов разделяется еще на три подуровня:

  •  описание требований;
  •  описание спецификации;
  •  описание реализации.

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

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

Каждая модель ARIS содержит:

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

Модель может включать:

  •  внешние встроенные объекты, например, рисунки, документы текстовых редакторов и т.п.;
  •  текст, размещенный в любом месте модели;
  •  геометрические фигуры.

ARIS поддерживает четыре типа моделей, отражающих различные аспекты исследуемой системы:

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

Все диаграммы распределены по 5 фундаментальным группам ARIS. (слайд 2)

  1.  Организационная структура. Верхний элемент, крыша. Описывает вопросы класса «кто».
  2.  Данные. Левый элемент. Определяет, на основе чего ведутся процессы.
  3.  Процессы. Центральный элемент. Отвечает за то, каким образом ведется деятельность, определяет взаимодействие всех остальных элементов.
  4.  Функции. Правый элемент. Определяет то, что происходит в процессах.
  5.  Объекты и цели процессов. Нижний элемент. Определяет то, для чего происходят процессы.

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

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

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

При построении моделей методология ARIS требует соблюдения определенных принципов. К ним относятся:

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

Моделирование бизнес-процессов в ARIS

Основная бизнес-модель ARIS - eEPC (extended Event Driven Process Chain - расширенная модель цепочки процессов, управляемых событиями). По существу, она расширяет возможности IDEF0, IDEF3 и DFD, обладая всеми их достоинствами и недостатками. Применение большого числа различных объектов, связанных различными типами связей, может значительно увеличить размер модели и сделать ее плохо читаемой.

Бизнес-процесс в нотации eEPC представляет собой поток последовательно выполняемых работ (процедур, функций), расположенных в порядке их выполнения (слайд 3).

Таблица 6.1. Объекты модели еЕРС

Наименование объекта

Описание

Функция

Служит для описания функций (процедур, работ), выполняемых подразделениями/сотрудниками предприятия.

Событие

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

Организационная единица

Представляет различные организационные звенья предприятия (например, управление или отдел).

Документ

Отражает реальные носители информации, например бумажный документ.

Прикладная система

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

Кластер информации

Характеризует данные (набор сущностей и связей между ними). Используется для создания моделей данных.

Связь между объектами

Описывает тип отношений между некоторыми объектами, например, активацию выполнения функции некоторым событием.

Логический оператор

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

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

Связи между объектами имеют определенный смысл и отражают последовательность выполнения функций в рамках процесса. Нотация eEPC построена на определенных правилах:

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

Реальная длительность выполнения процедур в eEPC визуально не отражается. Это приводит к тому, что при создании моделей возможны ситуации, когда на одного исполнителя будет возложено выполнение двух задач одновременно. Используемые при построении модели символы логики позволяют отразить ветвление и слияние бизнес-процесса. Для получения информации о реальной длительности процессов необходимо использовать другие инструменты описания, например, графики Ганта в системе MS Project.

Преимущества методологии ARIS:

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

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

6.2. Диаграммы переходов состояний (State Transition Diagram, STD)

Структурное проектирование является мостом между структурным анализом и реализацией.

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

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

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

STD состоит из следующих объектов (слайд 4):

СОСТОЯНИЕ – рассматривается как устойчивое значение некоторого  свойства в течение определенного  времени. Находясь в определенном состоянии, мы имеем достаточно информации о прошлой истории системы, чтобы определить очередное состояние в зависимости от текущих входных событий. Имя состояния должно отражать реальную ситуацию, в которой находится система, например, НАГРЕВАНИЕ, ОХЛАЖДЕНИЕ и т.п.

НАЧАЛЬНОЕ СОСТОЯНИЕ - узел STD, являющийся стартовой точкой для начального системного перехода. STD имеет ровно одно начальное состояние, соответствующее состоянию системы после ее инсталляции, но перед началом реальной обработки, а также любое (конечное) число завершающих состояний.

ПЕРЕХОД определяет перемещение моделируемой системы из одного состояния в другое. При этом имя перехода идентифицирует событие, являющееся причиной перехода и управляющее им. Это событие обычно состоит из управляющего потока (сигнала), возникающего как во внешнем мире, так и внутри моделируемой системы при выполнении некоторого условия (например, СЧЕТЧИК=999 или КНОПКА НАЖАТА). Следует отметить, что, вообще говоря, не все события необходимо вызывают переходы из отдельных состояний. С другой стороны, одно и то же событие не всегда вызывает переход в то же самое состояние.

Управляющий поток –это «трубопровод», через который проходит управляющая информация. Имеются следующие типы управляющих потоков:

Т-поток (trigger flow) –поток управления процессом, который может вызвать выполнение процесса. При этом процесс включается одной короткой операцией. Это аналог выключателя света, единственным нажатием которого «запускается» процесс горения лампы.

А-поток (activator flow) -  поток управления процессом, который может изменять выполнение отдельного процесса. Используется для обеспечения непрерывности выполнения процесса до тех пор, пока поток «включен», с «выключением» потока выполнение процесса завершается. Это аналог переключателя лампы, которая может быть как включена, так и выключена.

Е/D-поток (enable/disable flow) –поток управления процессом, который может переключать выполнение отдельного процесса. Течение по Е-линии вызывает выполнение процесса, которое продолжается до тех пор, пока не возбуждается течение по D-линии. Это аналог выключателя с двумя кнопками: одной для включения света, другой –для его выключения. Можно использовать 3 типа таких потоков: Е-поток, D-поток, E/D-поток.

УСЛОВИЕ представляет собой событие (или события), вызывающее переход и идентифицируемое именем перехода. Если в условии участвует входной управляющий поток управляющего процесса-предка, то имя потока должно быть заключено в кавычки, например, "ПАРОЛЬ"=666, где ПАРОЛЬ - входной поток.

Кроме условия с переходом может связываться действие или ряд действий, выполняющихся, когда переход имеет место. ДЕЙСТВИЕ - это операция, которая может иметь место при выполнении перехода. Если действие необходимо для выбора выходного управляющего потока, то имя этого потока должно заключаться в кавычки, например: "ВВЕДЕННАЯ КАРТА" = TRUE , где ВВЕДЕННАЯ КАРТА - выходной поток.

Для спецификации А-, Т-, E/D-потоков имя запускаемого или переключаемого процесса также должно заключаться в кавычки.

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

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

При построении STD рекомендуется следовать нижеперечисленным правилам:

  •  строить STD на как можно более высоком уровне детализации DFD;
  •  строить как можно более простые STD;
  •  по возможности детализировать STD;
  •  использовать те же принципы именований состояний, событий и действий, что и при именовании процессов и потоков.

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

  •  все ли состояния определены и имеют уникальное имя?
  •  все ли состояния достижимы?
  •  все ли состояния имеют выход?
  •  (для каждого состояния) реагирует ли система соответствующим образом на все возможные условия (особенно на ненормальные)?
  •  все ли входные (выходные) потоки управляющего процесса отражены в условиях (действиях) на STD?

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

Матрица переходов состояний содержит по вертикали перечень состояний системы, а по горизонтали список условий. Каждый ее элемент содержит список действий, а также имя состояния, в которое осуществляется переход. Используется и другой вариант данной нотации: по вертикали указываются состояния, из которых осуществляется переход, а по горизонтали - состояния, в которые осуществляется переход. При этом каждый элемент матрицы содержит соответствующие условия и действия, обеспечивающие переход из “вертикального” состояния в “горизонтальное”.

Пример банковской задачи (слайд 5).

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

Для банковского обслуживания клиенту необходимо предоставить системе свою КРЕДИТНУЮ КАРТУ для автоматического считывания с нее информации (ПАРОЛЬ, ЛИМИТ ДЕНЕГ, ДЕТАЛИ КЛИЕНТА), а также сообщить свои КЛЮЧЕВЫЕ ДАННЫЕ, а именно ПАРОЛЬ и ЗАПРОС НА ОБСЛУЖИВАНИЕ, т.е. требуемую ему услугу (например, снятие со счета наличных денег). Банковское обслуживание с позиций клиента, в свою очередь, должно обеспечить следующее:

  •  выдать СООБЩЕНИЕ, приглашающее клиента ввести КЛЮЧЕВЫЕ ДАННЫЕ;
  •  выдать клиенту ДЕНЬГИ;
  •  выдать клиенту ВЫПИСКУ по проведенному обслуживанию

Диаграмма переходов состояний для примера банковской задачи приведена на слайде 5. Она содержит два состояния - ОЖИДАНИЕ и ОБРАБОТКА. Переход из состояния ОЖИДАНИЕ в состояние ОБРАБОТКА осуществляется при условии ввода кредитной карты (ВВЕДЕННАЯ КРЕДИТНАЯ КАРТА). При этом выполняется действие по запуску процесса ПОЛУЧИТЬ ПАРОЛЬ. Отметим, что для запуска используется А-поток, обеспечивающий непрерывность процесса 1.1, т.е. возможность повторного ввода пароля.

Переход из состояния ОБРАБОТКА в состояние ОЖИДАНИЕ осуществляется двумя различными способами. При условии ввода неверного пароля  кредитная карта удаляется из системы, при этом она переходит в режим ожидания очередного клиента. При условии КОРРЕКТНЫЙ ПАРОЛЬ выполняются действия по обеспечению требуемого сервиса и удалению кредитной карты, и затем переход в режим ожидания очередного клиента.

6.3. Структурные карты Константайна

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

Структурные карты Константайна (Constantine) предназначены для описания отношений между модулями.

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

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

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

Базовым элементом структурной карты является модуль. Возможно использовать различные типы модулей (слайд 7):

  1.  Собственно МОДУЛЬ. Используется для представления обрабатывающего фрагмента для его локализации на диаграмме.
  2.  ПОДСИСТЕМА. Ранее определенный модуль, детализированный посредством декомпозиции ранее определенных диаграмм. Может повторно использоваться любое число раз на любых структурных картах.
  3.  БИБЛИОТЕКА. Отличается от подсистемы тем, что определена вне проекта данной системы.
  4.  ОБЛАСТЬ ДАННЫХ. Используется для указания модулей, содержащих исключительно области глобальных/распределенных данных.

При построении структурных карт добавление модулей и увязывание их вместе осуществляется с использований потоков, демонстрирующих иерархию вызовов. (слайд 7) При последовательном вызове модули вызываются в порядке их следования. При параллельном вызове модули могут вызываться в любом порядке или одновременно (параллельно).

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

Условный узел используется для условного вызова модуля-потомка. Он изображается с помощью ромба, потоки - альтернативные вызовы изображаются выходящими из него. Таким образом, если из ромба выходят два потока, это соответствует конструкции IF-THEN-ELSE, если один поток - конструкции IF-THEN.

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

Связи по данным и управлению между модулями (передаваемые как параметры) раскрываются аннотированием потоков-вызовов (слайд 8). Стрелками отмечаются направления связей.

Пример структурной карты Константайна. (слайд 9)

6.3. Структурные карты Джексона  

Структурные карты Джексона (Jackson), предназначенные для описания внутренней структуры модулей.

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

По аналогии со структурными картами Константайна диаграмма Джексона может включать объекты следующих типов:

  •  СТРУКТУРНЫЙ блок (базовая компонента методологии) представляет частную функцию или блок кодов с одним входом и одним выходом.
  •  ПРОЦЕДУРНЫЙ блок является специальным видом структурного блока, представляющим вызов ранее определенной процедуры.
  •  БИБЛИОТЕЧНЫЙ блок аналогичен процедурному и представляет вызов библиотечного модуля.

Для взаимоувязывания блоков используются связи следующих типов:

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

Пример структурной карты Джексона. (слайд 10)

6.4. Метод Ericsson-Penker

Метод Ericsson-Penker представляет интерес прежде всего в связи с попыткой применения языка объектного моделирования UML (изначально предназначенного для моделирования архитектуры систем ПО) для моделирования бизнес-процессов. Это стало возможным благодаря наличию в UML механизмов расширения.

Авторы метода создали свой профиль UML для моделирования бизнес-процессов, введя набор стереотипов, описывающих процессы, ресурсы, правила и цели деятельности организации.    Основной диаграммой, используемой в этом подходе, является диаграмма деятельности (activity diagram). В результате получился процесс, альтернативный RUP, в котором не применяются варианты использования.

Метод использует четыре основные категории бизнес-модели:

  •  Ресурсы - различные объекты, используемые или участвующие в бизнес-процессах (люди, материалы, информация или продукты).
  •  Процессы - виды деятельности, изменяющие состояние ресурсов в соответствии с бизнес-правилами.
  •  Цели - назначение бизнес-процессов Цели могут быть разбиты на подцели и соотнесены с отдельными процессами.
  •  Бизнес-правила - условия или ограничения выполнения процессов (функциональные, поведенческие или структурные). Правила могут быть определены с использованием языка OCL.

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

Основной диаграммой UML, используемой в данном методе, является диаграмма деятельности.

Бизнес-процесс в самом простом виде может быть описан как множество деятельностей. Метод Eriksson-Penker представляет образец процесса на диаграмме деятельности (слайд 12) в виде деятельности со стереотипом "process" (в качестве основы данного образца использовано представление процесса в методе IDEF0, расширенное за счет введения цели процесса). Процесс использует входные ресурсы и формирует выходные ресурсы, показанные в виде объектов со стереотипом "resourse", соединенных с процессом связями зависимости. Ресурсы, играющие в методе IDEF0 роли "управления" и "механизма", также соединены с процессом связями зависимости со стереотипами "supply" и "control". Цель процесса показана как объект со стереотипом "goal".

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

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

Метод Ericsson-Penker активно использует набор образцов моделирования бизнес-процессов. Образец (pattern) можно определить как общее решение некоторой проблемной ситуации в заданном контексте. Образец состоит из четырех основных элементов: имя; проблема; решение; следствия.

6.5. Метод моделирования, используемый в технологии Rational Unified Process

Этот метод предусматривает построение двух базовых моделей:

  •  модели бизнес-процессов (Business Use Case Model);
  •  модели бизнес-анализа (Business Analysis Model).

Модель бизнес-процессов —модель, описывающая бизнес-процессы организации в терминах ролей и их потребностей. Она представляет собой расширение модели вариантов использования (use case) UML  за счет введения набора стереотипов —Business Actor (стереотип действующего лица) и Business Use Case (стереотип варианта использования).

Business Actor (действующее лицо бизнес-процессов) —это некоторая роль, внешняя по отношению к бизнес-процессам организации, это индивидуум, группа, организация, компания или система, которые взаимодействуют с моделируемой бизнес-системой, но не входят в нее, т.е. не являются частью моделируемой системы. Общее свойство бизнес-актеров состоит в том, что они являются инициаторами или клиентами бизнес-процессов моделируемой системы (слайд 13).

Бизнес-вариант использования (business use case) —описание последовательности действий (потока событий) в рамках некоторого бизнес-процесса, приносящей ощутимый результат конкретному действующему лицу. Общее свойство бизнес-вариантов использования состоит в том, что они являются концептуальной моделью отдельных бизнес-процессов моделируемой системы (слайд 13).

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

Каждый Business Use Case отражает цель или потребность некоторого действующего лица. Стереотипы связей явно показывают роль действующих лиц по отношению к вариантам использования.

Для каждого Business Use Case строится модель бизнес-анализа —объектная модель, описывающая реализацию бизнес-процесса в терминах взаимодействующих объектов (бизнес-объектов —Business Object), принадлежащих к двум классам —Business Worker и Business Entity.

Business Worker (исполнитель) —активный класс, представляющий собой абстракцию исполнителя, выполняющего некоторые действия в рамках бизнес-процесса; это класс, служащий на диаграмме классов для представления любого сотрудника, который является элементом бизнес-системы и взаимодействует с другими сотрудниками при реализации бизнес-процесса. Общее свойство сотрудников заключается в том то, что они являются субъектами и входят в состав моделируемой системы. Исполнители взаимодействуют между собой и манипулируют различными сущностями, участвуя в реализациях сценариев Business Use Case (слайд 13).

Business Entity (сущность) —пассивный класс, не инициирующий никаких взаимодействий. Этот класс служит для сохранения информации о результатах выполнения бизнес-процесса в моделируемой бизнес-системе или организации. Этот класс также может быть изображен в форме прямоугольника класса со стереотипом «business entity». Объект такого класса может участвовать в реализациях различных Business Use Case. Сущность является объектом различных действий со стороны исполнителей (слайд 13).

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

Кроме диаграммы классов, модель бизнес-анализа может включать:

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

Метод моделирования Rational Unified Process обладает следующими достоинствами:

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


 

А также другие работы, которые могут Вас заинтересовать

72323. Принципы правового регулирования конкуренции и монополий 30 KB
  Правовое регулирование конкуренции пронизывают основополагающие начала, то есть принципы конкурентного права. Они обеспечивают целенаправленное воздействие на конкуренцию и предпринимательскую деятельность её участников. Можно выделить общеправовые и специальные принципы регулирования конкуренции.
72324. Физиологические действия метеорологических условий на человека 15.56 KB
  Температура воздуха влияет на теплообмен. Низкая температура воздуха увеличивая теплоотдачу создает опасность переохлаждения организма возможность простудных заболеваний. Степень насыщения воздуха водяными парами называется влажностью.
72326. Терроризм и его проявления. Экстремальные ситуации социального характера 42.86 KB
  Терроризм -– насилие в отношении физических лиц или организаций а также уничтожение повреждение или угроза уничтожения повреждения имущества и других материальных объектов создающие опасность гибели людей. Если вы находитесь в местах большого скопления агрессивно настроенных людей митинги...
72327. Табачный дым, влияние табачного дыма на человека 13.34 KB
  Из них наиболее известен никотин – одно из самых ядовитых химических веществ из группы алкалоидов. Содержащийся в табаке никотин относится к ядам вызывающим сначала привыкание а затем болезненное влечение - токсикоманию.
72328. СПИД и его профилактика 13.54 KB
  Выявлены три пути передачи вируса СПИДа: половой; при переливании инфицированной крови или использовании нестерильных шприцев и игл; заражение плода или новорожденного ребенку от инфицированной матери.
72330. Последствия употребления наркотиков для здоровья человека 14.78 KB
  Нервные клетки под действием наркотиков теряют свою функцию резко снижаются защитные силы организма. Страдают буквально все органы и системы организма. Нарушается функция всех систем организма.
72331. Организация работы комиссии на ЧС объектах 53.17 KB
  Главной задачей военной службы является постоянная целенаправленная подготовка к вооруженной защите или вооруженная защита территории РФ. Одной из особенностей военной службы является обязательное принятие каждым гражданином военной присяги.