Метод моделирования, используемый в технологии Rational Unified Process
Язык UML используется также в методе моделирования бизнес-процессов, являющемся частью технологии Rational Unified Process компании IBM Rational Software. Этот метод, направленный прежде всего на создание основы для формирования требований к ПО, предусматривает построение двух базовых моделей:
модели бизнес-процессов (Business Use Case Model);
модели бизнес-анализа (Business Analysis Model).
Модель бизнес-процессов - модель, описывающая бизнес-процессы организации в терминах ролей и их потребностей. Она представляет собой расширение модели вариантов использования (use case) UML за счет введения набора стереотипов - Business Actor (стереотип действующего лица) и Business Use Case (стереотип варианта использования).
Business Actor (действующее лицо бизнес-процессов) - это некоторая роль, внешняя по отношению к бизнес-процессам организации. Потенциальными кандидатами в действующие лица бизнес-процессов являются:
-акционеры;
-заказчики;
-поставщики;
-партнеры;
-потенциальные клиенты;
-местные органы власти;
-сотрудники подразделений организации, деятельность которых не охвачена моделью;
-внешние системы.
Список действующих лиц составляется путем ответа на следующие вопросы:
-Кто извлекает пользу из существования организации?
-Кто помогает организации осуществлять свою деятельность?
-Кому организация передает информацию и от кого получает?
Business Use Case (вариант использования с точки зрения бизнес-процессов) определяется как описание последовательности действий (потока событий) в рамках некоторого бизнес-процесса, приносящей ощутимый результат конкретному действующему лицу.
|
|
|
Это определение подобно общему определению бизнес-процесса, но имеет более точный смысл. В терминах объектной модели Business Use Case представляет собой класс, объектами которого являются конкретные потоки событий в рамках описываемого бизнес-процесса.
Данный метод концентрирует внимание в первую очередь на элементарных бизнес-процессах. Такой процесс можно определить как задачу, выполняемую одним человеком в одном месте в одно время в ответ на некоторое событие, приносящую конкретный результат и переводящую данные в некоторое устойчивое состояние (например, подтверждение платежа по кредитной карточке). Выполнение такой задачи обычно включает от пяти до десяти шагов и может занимать от нескольких минут до нескольких дней, но рассматривается как один сеанс взаимодействия действующего лица с исполнителями. Каждый Business Use Case отражает цель или потребность некоторого действующего лица.
Метод моделирования Rational Unified Process обладает следующими достоинствами:
|
|
|
-модель бизнес-процессов строится вокруг участников процессов (заинтересованных лиц) и их целей, помогая выявить все потребности клиентов организации. Нетрудно заметить, что такой подход в наибольшей степени применим для организаций, работающих в сфере
оказания услуг (торговые организации, банки, страховые компании и т.д.);
-моделирование на основе вариантов использования способствует хорошему пониманию бизнес-модели со стороны заказчиков;
-метод предусматривает достаточно простой переход от бизнес-модели к системным требованиям.
18. Модель бизнес-процессов UML. Стереотипы модели.
Метод Ericsson-Penker представляет интерес прежде всего в связи с попыткой применения языка объектного моделирования UML (изначально предназначенного для моделирования архитектуры систем ПО) для моделирования бизнес-процессов. Это стало возможным благодаря наличию в UML механизмов расширения.
UML обладает механизмами расширения, предназначенными для того, чтобы разработчики могли адаптировать язык моделирования к своим конкретным нуждам, не меняя при этом его метамодель. Наличие механизмов расширения принципиально отличает UML от таких средств моделирования, как IDEF0, IDEF1X, IDEF3, DFD и ERM. Перечисленные языки моделирования можно определить как сильно типизированные (по аналогии с языками программирования), поскольку они не допускают произвольной интерпретации семантики элементов моделей. UML, допуская такую интерпретацию (в основном за счет стереотипов), является слабо типизированным языком. К его механизмам расширения относятся:
|
|
|
-стереотипы;
-тегированные (именованные) значения;
-ограничения.
Стереотип - это новый тип элемента модели, который определяется на основе уже существующего элемента. Стереотипы расширяют нотацию модели и могут применяться к любым элементам модели. Стереотипы классов - это механизм, позволяющий разделять классы на категории. Разработчики ПО могут создавать свои собственные наборы стереотипов, формируя тем самым специализированные подмножества UML (например, для описания бизнес-процессов, Web-приложений, баз данных и т.д.). Такие подмножества (наборы стереотипов) в стандарте языка UML носят название профилей языка.
Именованное значение - это пара строк "тег = значение", или "имя = содержимое", в которых хранится дополнительная информация о каком-либо элементе системы, например, время создания, статус разработки или тестирования, время окончания работы над ним и т.п.
|
|
|
Ограничение - это семантическое ограничение, имеющее вид текстового выражения на естественном или формальном языке (OCL - Object Constraint Language), которое невозможно выразить с помощью нотации UML.
19. Спецификация требований к ПО.
Спецификация требований программного обеспечения (англ. Software Requirements Specification, SRS) — законченное описание поведения программы, которую требуется разработать.
Включает ряд пользовательских сценариев (англ. use cases), которые описывают все варианты взаимодействия между пользователями и программным обеспечением.
Пользовательские сценарии являются средством представления функциональных требований. В дополнение к пользовательским сценариям, спецификация также содержит нефункциональные требования, которые налагают ограничения на дизайн или реализацию (такие как требования производительности, стандарты качества, или проектные ограничения).
В стандарте IEEE 830 содержится рекомендации к структуре и методам описания программных требований — «Recommended Practice for Software Requirements Specifications».
Рекомендуемая стандартом IEEE 830[1] структура SRS
Введение
Цели
Соглашения о терминах
Предполагаемая аудитория и последовательность восприятия
Масштаб проекта
Ссылки на источники
Общее описание
Видение продукта
Функциональность продукта
Классы и характеристики пользователей
Среда функционирования продукта (операционная среда)
Рамки, ограничения, правила и стандарты
Документация для пользователей
Допущения и зависимости
Функциональность системы
Функциональный блок X (таких блоков может быть несколько)
-Описание и приоритет
-Причинно-следственные связи, алгоритмы (движение процессов, workflows)
-Функциональные требования
Дата добавления: 2018-02-15; просмотров: 908; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!