Разработка модели бизнес прецедентов

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

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

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

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

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

Диаграмма Use Case

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

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

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

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

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

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

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

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

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

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

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

Диаграммы бизнес-прецедентов, прецедентов и спецификации прецедента

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

На рисунках 3.1, 3.2, 3.3 представлены примеры диаграмм бизнес-прецедентов, прецедентов и спецификации прецедента.

Рис.3.1 Диаграмма бизнес-прецедентов

Рис. 3.2. Пример диаграммы прецедентов

Рис. 3.3. Пример спецификации прецедента

Диаграмма классов

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

Диаграмма классов представлена на рисунке 3.4. На рисунке 3.5 представлена структура спецификации класса.

Рис.3.4 Пример д иаграммы классов

Класс «Имя класса»

Рис. 3.5 Структура спецификации класса

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

Диаграмма последовательности является формой визуализации взаимодействия в модели ИС.

Фрагмент диаграммы последовательности представлен на рисунке 3.6.

Рис. 3.6 Фрагмент диаграммы последовательности

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

Диаграмма деятельностиобычно отображает алгоритм операции класса или сценарий прецедента.

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

Рис. 3.7. Диаграмма деятельности

Приложение 4. Требования к проектируемой информационной системе

Табл.1. Функциональные требования

Требования к функциям

Атрибуты требования

Табл.2. Требования к удобству использования

Требования к удобству использования

Атрибуты требования

Табл.3. Требования к надежности

Требования к надежности

Атрибуты требования

Табл.4. Требования к производительности

Требования к производительности

Атрибуты требования

Табл. 5. Требования к поддержке

Требования к поддержке

Атрибуты требования

Табл. 6. Ограничения

Ограничения

Атрибуты требования

Приложение 5. График выполнения курсовой работы и шаблон отзыва руководителя

Курсовая работа 1.

Источник: infopedia.su

Разработка модели использования. Диаграмма вариантов использования (диаграмма прецедентов)

Субъект (actor) — это некто или нечто (человек, машина и т.д.) взаимодействующее с системой. Субъект взаимодействует с прецедентом, ожидая получить некий полезный результат.

Типичным графическим изображением субъекта является «штриховой человечек». В общем случае субъект может быть показан в виде прямоугольного символа класса. Подобно обычному классу субъект может обладать атрибутами и операциями (связанными с событиями, сообщения о которых он отправляет и получает). На рисунке 1 показаны три субъекта: Klient (Клиент), TO (Туроператор) и Мanager (Менеджер).

Рисунок 1 — Субъекты системы «Туристическое агентство»

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

Рисунок 2 — Прецеденты системы «Турагентство»

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

Рисунок 3 — Диаграмма прецедентов для системы «Автосервис»

В таблице 1 представлены актеры и соответствующие им прецеденты.

Таблица 1 — Оборот актеров и прецедентов

Oplata_zakaza (оплата заказа), Registracia_na_oslugivanie (регистрация на обслуживание)

Vidacha_gotovogo_tyra (выдача готового тура), Zakaz_tyra (заказ тура), Obslugivanie (обслуживание)

Priem_zakaza (прием заказа), Grafik raboti (график работы), Registracia_klienta (регистрация клиента), Registracia_tyrov (регистрация туров), Proverka_nalichia_tyrov (проверка наличия туров), Ychet_tyrov (учет туров), Otpravka_zakaza_ТО (отправка заказа туроператору)

В таблице 2 представлено описание этих прецедентов, в таблице 3 — описательная спецификация прецедента Registracia_na_obslugivanie (регистрация на обслуживание).

Таблица 2 — Распределение требований по субъектам и прецедентам

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