УЧРЕЖДЕНИЕ ОБРАЗОВАНИЯ

«ГОМЕЛЬСКИЙ ГОСУДАРСТВЕННЫЙ МАШИНОСТРОИТЕЛЬНЫЙ КОЛЛЕДЖ»

Технология разработки программного обеспечения

методические рекомендации по выполнению

ЛАБОРАТОРНОЙ РАБОТЫ № 6

Использование объектного подхода при проектировании программного продукта

специальность 2-40 01 01

"Программное обеспечение информационных технологий"

Разработчик преподаватель

______________ Е.И. Гридина

Обсуждено и одобрено на заседании

цикловой комиссии “Программное

обеспечение информационных

технологий”

“ ____ ” ___________ 2012 №___

___________________ Е. И. Гридина

Гомель 2012

Тема работы: Построение моделей разрабатываемого ПП с использованием унифицированного языка моделирования (UML). Построение диаграммы вариантов использования. Построение диаграммы классов. Построение диаграммы состояний. Построение диаграммы деятельности. Построение диаграмм последовательности и кооперации. Построение диаграмм реализации. Анализ разрабатываемого ПП с использованием построенных диаграмм.

Цель работы: Научиться выполнять построение моделей и диаграмм с использованием унифицированного языка моделирования (UML).

Оборудование: IBM – совместимый компьютер, Visio 6.0.

Теоретические сведения

UML - унифицированный язык моделирования.

UML вобрал в себя черты нотаций Грейди Буча (Grady Booch), Джима Румбаха (Jim Rumbaugh), Айвара Якобсона (Ivar Jacobson) и многих других.

Румбах присоединился к Бучу в Rational Inc. Они объединили свои нотации и создали первую версию UML. В 1995 году на конференции OOPSLA они представили его как Unified Method, который потом и получил название UML. Чуть позже к ним присоединился Якобсон, который добавил к результатам их труда элементы Objectory и начал работу над Rational Unified Process (RUP). В 1997 году UML был отправлен в Object Management Group (OMG) для стандартизации. Кроме трех нотаций "трех амиго" UML вобрал в себя элементы многих других методологий.

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

Занятие 1: Построение диаграммы вариантов использования

Представление использования описывает поведение подсистем, клас­сов или всей системы с точки зрения пользователя. При этом вся деятельность в рамках системы делится на транзакции, которые на­зываются вариантами использования (use cases). Вариант использо­вания описывает взаимодействие системы с одним или несколькими действующими лицами (Актерами) в виде последовательности со­общений. В понятие действующее лицо или Актер (actor) входят люди, компьютерные системы и процессы. На рис. 1 приведена не­сколько упрощенная диаграмма использования для программы про­даж по телефонному каталогу.

Актер

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

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

Актеры можно описывать иерархически, постепенно дополняя об­щее описание более конкретными чертами.

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

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

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

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

Описание варианта использования передастся в языке UML диа­граммами состояний, диаграммами последовательности, диаграм­мами кооперации или в виде текста, а реализация — в виде коопе­раций между классами. Класс может присутствовать в нескольких кооперациях, то есть в нескольких вариантах использования.

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

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

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

Одна из задач проектирования — найти для реализации вариантов использования те классы, которые играют нужные роли и не созда­ют при этом излишних сложностей. Реализацию варианта использо­вания можно смоделировать в виде одной или нескольких коопера­ций. Кооперация — это реализация варианта использования.

Помимо ассоциаций с Актерами, вариант использования может иметь еще несколько отношений (табл. 1).

На диаграммах вариант использования изображается в виде эллипса. Внутри эллипса или под ним указывается имя варианта использова­ния. Сплошные линии соединяют варианты использования с Актерами.

Таблица 1. Виды отношений вариантов использования

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

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

Один вариант использования может также рассматриваться как рас­ширение и дополнение исходного варианта использования (extend). У исходного варианта использования может быть несколько расши­ряющих вариантов, которые вносят дополнения в его семантику. Все эти варианты могут применяться вместе.

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

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

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

Рис. 2. Отношения вариантов использования

Диаграмма вариантов использования состоит из актеров, для которых система производит действие и собственно действия Use Case, которое описывает то, что актер хочет получить от системы. Актер обозначается значком человечка, а Use Case - овалом. Дополнительно в диаграммы могут быть добавлены комментарии.

Ответы на следующие вопросы позволят определить актеров, взаимодействующих с системой:

• кто взаимодействует с системой или использует систему;

• кто передает или принимает информацию в/из системы;

• кто является внешним по отношению к системе.

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

А вот еще один пример.