Лекция 2.4. Общие механизмы: стереотипы, примечания, ограничения. Понятие образца и способ его описания

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

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

Стереотипы классов – это механизм, позволяющий разделять классы на категории. Например, основными стереотипами, используемыми в процессе анализа системы, являются: Boundary (граничный класс), Entity (класс-сущность) и Control (управляющий класс).

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

Именованное значение – это пара строк "тег = значение", или "имя = содержимое", в которых хранится дополнительная информация о каком-либо элементе системы, например, время создания, статус разработки или тестирования, время окончания работы над ним и т. п.

Примечание – элемент диаграммы для комментария или другой текстовой информации. Примечание может содержать дополнительные сведения об элементах модели (с ними его соединяет пунктирная линия).

Ограничение – это семантическое ограничение, имеющее вид текстового выражения на естественном или формальном языке (OCL – Object Constraint Language), которое невозможно выразить с помощью нотации UML. Средства OCL не предназначены для описания процессов вычисления выражений, а только лишь фиксируют необходимость выполнения тех или иных условий применительно к отдельным компонентам моделей. Он может быть использован для решения следующих задач:

1 описание инвариантов классов и типов в модели классов;

2 описание пред- и постусловий в операциях и методах;

3 описание ограничивающих условий элементов модели;

1. Буч Г., Якобсон А., Рамбо Дж. UML. Серия «Классика CS». 2-е изд.: Пер. с англ. – СПб.: Питре, 2006. – Глава 12.

2. Вендров А. М. Проектирование программного обеспечения экономических информационных систем. 2-е изд. – М.: Финансы и статистика, 2005. – Глава 2.

Раздел 3. Моделирование бизнес-процессов и спецификация требований к программному обеспечению

Лекция 3.1. Модель Business Use Case. Модель бизнес-анализа

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

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

Бизнес-модель – это формализованное графическое представление процессов, связанных с ресурсами и отражающих существующую или предполагаемую деятельность предприятия. Цели бизнес-моделирования:

1. обеспечить понимание структуры организации и динамики происходящих в ней процессов;

2. обеспечить понимание текущих проблем организации и возможностей их решения;

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

4. создать базу для формирования требований к будущему ПО организации.

Модель бизнес-процесса должна давать ответы на вопросы:

1. Какие процедуры (функции, работы) необходимо выполнить для получения заданного конечного результата?

2. В какой последовательности выполняются эти процедуры?

3. Какие механизмы контроля и управления существуют в рамках рассматриваемого бизнес-процесса?

5. Какие входящие документы/информацию использует каждая процедура процесса?

6. Какие исходящие документы/информацию генерирует процедура процесса?

7. Какие ресурсы необходимы для выполнения каждой процедуры процесса?

8. Какая документация/условия регламентирует выполнение процедуры?

Методика моделирования, являющаяся составной частью технологии Rational Unified Process, предусматривает построение двух моделей:

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

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

1. Вендров А. М. Проектирование программного обеспечения экономических информационных систем. 2-е изд. – М.: Финансы и статистика, 2005. – Глава 3.

Лекция 3.2. Определение требований к системе. Варианты использования

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

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

1. Коберн А. Современные методы описания функциональных требований к системам.: Пер. с англ. – М. Лори, 2002.

2. Кратчен Ф. Введение в Rational Unified Process. 2-е изд.: Пер. с англ. – М.: Вильямс, 2002. – Глава 9.

3. Соммервил И. Инженерия программного обеспечения. 6-е изд.: Пер. с англ. – М.: Вильямс, 2002. – Главы 5, 6.

4. Якобсон А., Буч Г., Рамбо Дж. Унифицированный процесс разработки программного обеспечения.: Пер. с англ. – СПб.: Питер, 2002. – Главы 6, 7.

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

Что делать, если нет взаимности? А теперь спустимся с небес на землю. Приземлились? Продолжаем разговор...

ЧТО И КАК ПИСАЛИ О МОДЕ В ЖУРНАЛАХ НАЧАЛА XX ВЕКА Первый номер журнала «Аполлон» за 1909 г. начинался, по сути, с программного заявления редакции журнала...

Система охраняемых территорий в США Изучение особо охраняемых природных территорий(ООПТ) США представляет особый интерес по многим причинам...

Не нашли то, что искали? Воспользуйтесь поиском гугл на сайте: