Диаграмма бизнес прецедентов это

Модель бизнес-прецедентов описывает бизнес-процессы с точки зрения внешнего пользователя, т.е. отражает взгляд на деятельность организации из вне.

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

Исполнитель (Действующее лицо, Actor ) – личность , организация или система, взаимодействующая с ИС; различают внешнего исполнителя (который использует или используется системой, т.е. порождает прецеденты деятельности) и внутреннего исполнителя (который обеспечивает реализацию прецедентов деятельности внутри системы). На диаграмме исполнитель представляется стилизованной фигуркой человека.

Класс — описание совокупности однородных объектов с их атрибутами, операциями, отношениями и семантикой. На диаграмме представляется прямоугольником, содержащим описания атрибутов и операций класса .

Ассоциация – связь между двумя элементами модели. На диаграмме представляется линией.

1. Диаграмма прецедентов

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

Агрегация – отношение между элементами модели, когда один элемент является частью другого элемента (агрегата). На диаграмме представляется стрелкой с ромбовидным концом.

Для иллюстрации этапов разработки проекта использованы адаптированные материалы проекта ИС медицинского центра [ рис. 12.2]. Назначение ИС – автоматизация ведения и использования клинических записей о пациентах. В настоящее время эта работа производится вручную персоналом центра. На рис.

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

Рис. 12.2. Общая диаграмма деятельности медицинского центра по обслуживанию пациента

Рис. 12.3. Модель бизнес-прецедентов, составляющих обслуживание пациента

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

• прецедент должен описывать, ЧТО нужно делать, а не КАК ;
• прецедент должен описывать действия с точки зрения ИСПОЛНИТЕЛЯ ;
• прецедент должен возвращать исполнителю некоторое СООБЩЕНИЕ ;
• последовательность действий внутри прецедента должна представлять собой одну НЕДЕЛИМУЮ цепочку.

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

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

Рис. 12.4. Диаграмма видов деятельности для прецедента «Оказание медицинской помощи»

UML Диаграмма Прецедентов (UML Use Case Diagrams)

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

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

Диаграмма подходит для описания действий как внешнего, так и внутреннего специалиста центра.

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

Источник: intuit.ru

Евгений / Лаб2_бизнес-прецеденты

Только сегодня: 300 рублей в подарок на первый заказ.
Какую работу нужно написать?

Другую работу

Помощник Анна

Лабораторная работа по бизнес-моделированию информационной системы средствами UML N2 «Построение модели бизнес — прецедентов» 1. Задачи и средства бизнес-моделирования Изучение деятельности компании — очень непростая задача.

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

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

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

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

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

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

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

На этапе бизнес-моделирования этот тип диаграмм используется в качестве основного источника информации при определе­нии ролей и прецедентов (Leffingwell and Widrig, 2000). Бизнес-модель должна ото­бражать деятельность как изнутри, так и извне, поэтому эта модель всегда состоит из нескольких диаграмм, представляющих различные стороны деятельности компании.

Основными элементами диаграмм прецедентов являются исполнители и преце­денты (рис. 1). Исполнители — это конечные пользователи системы. Прецеденты определяют последовательности действий, инициируемые одним или несколькими исполнителями с целью получения ими результата. Рис.

1. Основные элементы диаграммы прецедентов Конечно, может возникнуть законный вопрос: “А чем же бизнес-прецеденты отличаются от прецедентов?”. В качестве ответа на этот вопрос приведем определения понятий из книги Буча (Booch et аl., 1999): Исполнитель (Actor) — внешняя личность или система, которая взаимодействует с данной системой (т.е. использует систему или используется ею).

Бизнес-исполнитель или внешний исполнитель (Business actor) — внешний по от­ношению к определенному виду деятельности исполнитель. Прецедент (Use case) — законченная последовательность действий, инициирован­ная исполнителем. В результате выполнения прецедента система выдает испол­нителю некоторое значение.

Бизнес-прецедент (Business use case) — прецедент, инициированный внешним ис­полнителем на выполнение. Учебный пример. А теперь рассмотрим пример разработки диаграммы бизнес-прецедентов на примере работы патентного отдела (далее Отдела).В начале кратко опишем деятельность отдела.

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

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

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

Рис. 2. Общая модель бизнес-прецедентов для патентного отдела. В модели бизнес-прецедентов представлены бизнес-исполнители (фигурки с пере­черкиванием), бизнес-прецеденты (перечеркнутые эллипсы) и ассоциации между ними (стрелки).

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

Некоторые из исполни­телей очевидны, например, Патентовед, Начальник патентного отдела, Заявитель и т.п. Но есть и не­очевидные исполнители, например. Отправитель запроса, который не всегда совпадает с заявителем. Заметим, что модель, представленная на рис.

2, называется общей моделью бизнес-прецедентов (Jacobson et al., 1995), потому что каждый прецедент содержит в себе множество бизнес-прецедентов и видов деятельно­сти. Например, прецедент «Оказание посреднических услуг по получению патента» реализован через несколько других, более ограниченных бизнес-прецедентов.

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

Анализ деятельности Отдела дал нам более 30 по­тенциальных бизнес-прецедентов, что, конечно, слишком много для одного бизнес-прецедента. Поэтому отбросим некоторые из них, применив следующие критерии отбора («WAVE»): W(What) Прецедент должен описывать что нужно делать, а не как. A(Actor) Прецедент должен быть описан с точки зрения исполнителя.

(Value) Прецедент должен выдать исполнителю некоторое значение. E(Entire) Последовательность событий должна представлять собой один неделимый бизнес-процесс. Множество выявленных изначально «бизнес-прецедентов» прошли только один или два этапа процесса отбора, мы включили их в более крупные бизнес-прецеденты.

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

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

3. Модель бизнес-прецедентов для прецедента “Оказание посреднических услуг по получению патента” Данная модель дает более точное и реальное представление о деятельности Отдела. В процессе отбора в систему добавились новые исполнители – Эксперты (любые компании, осуществляющие проверку документов). В итерационном проектировании такое случается довольно часто.

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

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

4. Рис . 4. Основные элементы диаграммы видов деятельности Диаграммы видов деятельности проходят по конкретным прецедентам. С их по­мощью читатель может получить более глубокое представление о выполнении преце­дентов.

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

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

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

Пример диаграммы видов деятельности для прецедента “Оказание посреднических услуг по получению патента” показан в файле “Activity.mdl” и на рис.5. Рис . 5. Диаграмма видов деятельности оказание посреднических услуг После того как разработаны все остальные диаграммы видов деятельности, можно считать, что построение модели прецедентов закончено.

Однако хотелось бы в за­ключение уточнить смысл слова «закончен»: на данном этапе итерационного анали­за и процесса проектирования нет ничего полностью «законченного». Какие-то важные подробности можно выявить на более поздних этапах анализа и проектирования, что вполне закономерно.

Часто при этом приходится возвращаться назад, на преды­дущие этапы, и переделывать то, что считалось полностью «законченным». Подобные моменты огорчают проектировщика и несомненно отталкивают его от менеджмента, но все же такое развитие процесса — вполне нормальное явление, которое станет для вас со временем привычным.

Настройки Rational Rose 2000 для построения диаграмм бизнес-прецедентов и видов деятельности. 1. Запустите Rational Rose 2000. Нажмите “+” в окне броузера рядом с надписью Use Case View. 2. Разместив “Прецедент” или “Исполнителя” на диаграмме прецедентов дважды щелкните на его изображении мышью.

В появившемся меню выберите “Stereotype – business actor” или “Stereotype – business use case”. 3. Щелкните мышью в окне броузера над надписью “Logical View” и выберите “New – Activity diagram”.

Источник: studfile.net

Диаграмма вариантов использования (Use Case Diagram)

Что такое диаграмма вариантов использования?

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

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

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

Элементы диаграммы вариантов использования

Вариант использования

На диаграмме прецедентов варианты использования (Use Case) представляют собой эллипсы, которые отображают функциональные возможности системы или ее части. Они описывают конкретные задачи, которые система должна выполнять для достижения цели, и представляют собой сценарии использования системы с точки зрения ее пользователей.

Каждый вариант использования может иметь свои варианты выполнения (Alternate Flows). Они описывают возможные варианты поведения в определенных условиях, таких как ошибки ввода или некорректные данные. Эти варианты выполнения отображаются на диаграмме прецедентов в виде ветвей, которые выходят из основного эллипса варианта использования.

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

Акторы

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

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

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

Extension points

«Extension points» (точки расширения) — это особый элемент на диаграмме вариантов использования (use case diagram), который позволяет представить возможность расширения функциональности системы путем внедрения дополнительных вариантов использования (use cases) без изменения основной логики приложения.

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

Таким образом, использование «Extension points» позволяет лучше структурировать функциональность системы и уменьшить сложность ее разработки, позволяя добавлять новые варианты использования без внесения изменений в существующий код.

Отношения (связи)

Связи на диаграмме вариантов использования нужны для соединения элементов диаграммы между собой. Например для связи вариантов использования и акторов. Они показывают, как элементы взаимодействуют друг с другом и как они связаны с системой в целом.

Существует несколько типов отношений на диаграмме вариантов использования:

Отношение «ассоциации» (association) — используется для связи между прецедентами и акторами. Оно показывает, что актор взаимодействует с прецедентом. Отношение ассоциации связывает прецеденты с акторами и показывает, какой актор использует данный прецедент.

Отношение «включение» (include) — используется, когда один вариант использования использует функциональность другого варианта использования. Это отношение показывает, что один вариант использования является составной частью другого варианта использования.

Отношение «расширение» (extend) — используется, когда один вариант использования может быть расширен другим вариантом использования, если возникают определенные условия. Это отношение показывает, что расширенный вариант использования является необязательным и может быть выполнен только при определенных условиях.

Отношение «общий актор» (generalization) — используется, когда несколько акторов имеют общие характеристики, но один актор является более общим, чем другой. Например, акторы «Клиент» и «Администратор» могут быть представлены более общим автором «Пользователь».

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

Системная граница

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

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

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

Как построить диаграмму вариантов использования

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

Определить цели и задачи

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

На примере модуля авторизации пользователя цели и задачи могут быть следующими:

1. Идентифицировать и описать все возможные варианты использования для авторизации пользователя.
2. Выявить действия, которые пользователь может выполнять на каждом этапе авторизации.
3. Идентифицировать все взаимодействия между пользователями и системой, связанные с авторизацией.
4. Предоставить четкое понимание, как система реагирует на каждое действие пользователя, связанное с авторизацией.
5. Помочь уточнить требования к системе по авторизации пользователя и выявить возможные проблемы и улучшения.

Определить акторов

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

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

1. Клиент – пользователь, который использует систему для авторизации и входа в свой аккаунт.
2. Администратор – пользователь , который имеет права на управление настройками авторизации.

Определить основные варианты использования системы

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

Установить отношения (связи) между акторами и вариантами использования

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

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

Выявить расширенные варианты использования и установить связи с основными сценариями

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

Источник: itonboard.ru