Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

Старое ПППП / Лабораторная работа №1. UML / Лабораторная работа №1. UML

.pdf
Скачиваний:
80
Добавлен:
17.04.2018
Размер:
1.43 Mб
Скачать

Практикум по промышленному программированию ­ 2015. Лабораторная работа №1

Лабораторная работа №1 Основы языка UML. Диаграммы классов и

последовательности

Цель работы: ознакомиться с языком UML, его применением в проектировании ПО, освоить создание диаграмм классов, диаграмм последовательности.

Необходимое ПО для практической части: JDK 8; IntelliJ IDEA 14 Community Edition; плагин PlantUML integration; Graphviz.

Оглавление

Теоретические сведения Способы применения UML Диаграммы UML

Диаграмма классов (Class diagram) Свойства Атрибуты Кратность Операции Отношения

Зависимость

Ассоциация Двунаправленные ассоциации Агрегация и композиция

Обобщение

Реализация Примечания и комментарии Ключевые слова

Статические операции и атрибуты

Диаграмма последовательности (Sequence diagram) Создание и удаление участников Циклы, условия Синхронные и асинхронные вызовы

Практическая часть Инструментарий Начало работы

Создание первого проекта

Пример создания UML­диаграмм архитектуры проекта с помощью PlantUML Создание диаграммы классов Создание диаграммы последовательностей

Сценарий нахождения чего­либо в библиотеке по имени Сценарий удаления чего­либо из библиотеки по идентификатору

Коррекция диаграммы классов Задания для самостоятельной работы

Вариант №1, 16 Вариант №2, 17 Вариант №3, 18 Вариант №4, 19 Вариант №5, 20 Вариант №6, 21 Вариант №7, 22 Вариант №8, 23

­1­

Практикум по промышленному программированию ­ 2015. Лабораторная работа №1

Вариант №9, 24 Вариант №10, 25 Вариант №11, 26 Вариант №12, 27 Вариант №13, 28 Вариант №14, 29 Вариант №15, 30

Литература, ссылки

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

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

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

Способы применения UML

Основу роли UML в разработке программного обеспечения составляют разнообразные способы использования языка.

Определены три режима использования UML разработчиками:

режим эскиза;

режим проектирования;

режим языка программирования.

Безусловно, самый главный из трех – это режим использования UML для эскизирования. В этом режиме разработчики используют UML для обмена информацией о различных аспектах системы. В режиме проектирования можно использовать эскизы при прямой и обратной разработке. При прямой разработке (forward engineering) диаграммы рисуются до написания кода, а при обратной разработке (reverse engineering) диаграммы строятся на основании исходного кода, чтобы лучше понять его.

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

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

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

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

­2­

Практикум по промышленному программированию ­ 2015. Лабораторная работа №1

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

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

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

– как окончательные.

Чем дольше вы работаете с UML, а программирование становится все более механическим, тем очевиднее становится необходимость перехода к автоматизированному созданию программ. Действительно, многие CASE­средства (computer­aided software engineering – автоматизированная разработка программного обеспечения) так или иначе генерируют код, что позволяет автоматизировать построение значительной части системы. В конце концов, вы достигнете такой точки, когда сможете описать с помощью UML всю систему и перейдете в режим использования UML в качестве языка программирования. В такой среде разработчики рисуют диаграммы, которые компилируются прямо в исполняемый код, а UML становится исходным кодом. Очевидно, что такое применение UML требует особенно сложных инструментов. (Кроме того, нотации прямой и обратной разработки теряют всякий смысл, поскольку UML и исходный код становятся одним и тем же.).

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

Диаграммы UML

UML 2 описывает 13 официальных типов диаграмм, перечисленных в табл. 1, классификация которых приведена на рис. 1. Хотя эти виды диаграмм отражают различные подходы многих специалистов к UML, авторы UML не считают диаграммы центральной составляющей языка. Поэтому диаграммы определены не очень строго. Часто вполне допустимо присутствие элементов диаграммы одного типа в другой диаграмме. Стандарт UML указывает, что определенные элементы обычно рисуются в диаграммах соответствующего типа, но это не догма.

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

Таблица 1. Официальные типы диаграмм UML

Диаграмма

Цель диаграммы

 

 

Деятельности

Процедурное и параллельное поведение

 

 

Классов

Классы, свойства и отношения

 

 

Взаимодействия

Взаимодействие между объектами; акцент на связях

 

 

Компонентов

Структура и взаимосвязи между компонентами

 

 

­3­

 

Практикум по промышленному программированию ­ 2015. Лабораторная работа №1

 

 

Составных структур

Декомпозиция класса во время выполнения

 

 

Развертывания

Развертывание артефактов в узлы

 

 

Обзора взаимодействий

Комбинация диаграммы последовательности и диаграммы

 

деятельности

 

 

Объектов

Вариант конфигурации экземпляров

 

 

Пакетов

Иерархическая структура времени компиляции

 

 

Последовательности

Взаимодействие между объектами; акцент на

 

последовательности

 

 

Конечных автоматов

Как события изменяют объект в течение его жизни

 

 

Временная

Взаимодействие между объектами; акцент на синхронизации

 

 

Прецедентов

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

 

 

­4­

Практикум по промышленному программированию ­ 2015. Лабораторная работа №1

Рис. 1. Классификация типов диаграмм UML

Диаграмма классов (Class diagram)

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

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

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

2.секция свойств — содержит список описаний свойств класса;

3.секция операций — содержит список описаний операций класса.

Как и все основные сущности UML, класс обязательно имеет имя, а стало быть, секция имени не может быть опущена. Прочие секции могут быть пустыми или отсутствовать вовсе.

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

­5­

Практикум по промышленному программированию ­ 2015. Лабораторная работа №1

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

Свойства

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

Атрибуты

Атрибут описывает свойство в виде строки текста внутри прямоугольника класса. Полная форма атрибута:

видимость имя: тип кратность = значение по умолчанию {строка свойств}

Например:

­ имя: String [1] = "Без имени" {readOnly}

Обязательно только имя.

Метка видимости обозначает, относится ли атрибут к открытым (обозначается значком +) (public), закрытым (­) (private), защищенным (#) (protected), пакетным (~) (package);

Имя атрибута – способ ссылки класса на атрибут – приблизительно соответствует имени поля в языке программирования;

Тип атрибута накладывает ограничение на вид объекта, который может быть размещен в атрибуте. Можно считать его аналогом типа поля в языке программирования.

Кратность рассмотрена ниже.

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

Элемент {строка свойств} позволяет указывать дополнительные свойства атрибута. В примере он равен {readOnly}, то есть клиенты класса не могут изменять атрибут. Если он пропущен, то, как правило, атрибут можно модифицировать. Остальные строки свойств будут описаны позже.

­6­

Практикум по промышленному программированию ­ 2015. Лабораторная работа №1

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

Кратность

Кратность свойства обозначает количество объектов, которые могут заполнять данное свойство. Чаще всего встречаются следующие кратности:

1 (Заказ может представить только один клиент, т.е в классе “Заказ” (Order) может быть только один “Клиент” (Customer)

0..1 (Корпоративный клиент может иметь, а может и не иметь единственного торгового представителя.)

* (Клиент не обязан размещать заказ, и количество его заказов не ограничено. Он может разместить ноль или более заказов.)

Вбольшинстве случаев кратности определяются своими нижней и верхней границами, например 2..4. Нижняя граница может быть нулем или положительным числом, верхняя граница представляет собой положительное число или * (без ограничений). Если нижняя и верхняя границы совпадают, то можно указать одно число; поэтому 1 эквивалентно 1..1. Поскольку это общий случай, * является сокращением

0..*.

При рассмотрении атрибутов могут встретиться термины, имеющие отношение к кратности.

Optional (необязательный) предполагает нулевую нижнюю границу.

Mandatory (обязательный) подразумевает, что нижняя граница равна или больше 1.

­7­

Практикум по промышленному программированию ­ 2015. Лабораторная работа №1

Single­valued (однозначный) – для такого атрибута верхняя граница равна 1.

Multivalued (многозначный) имеет в виду, что верхняя граница больше 1; обычно *.

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

Кратность атрибута по умолчанию равна [1].

Операции

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

видимость имя (список параметров) : возвращаемый тип {строка свойств}

Метка видимости обозначает, относится ли операция к открытым (обозначается значком +) (public), закрытым (­) (private), защищенным (#) (protected), пакетным (~) (package);

Имя – это имя операции.

Список параметров – список параметров операции.

Возвращаемый тип – тип возвращаемого значения операции, если таковой есть.

Строка свойств – свойства, которые применяются к данной операции.

Параметры в списке параметров обозначаются таким же образом, что и для атрибутов. Они имеют

вид:

направление имя: тип = значение по умолчанию

Имя, тип и значение по умолчанию те же самые, что и для атрибутов.

Направление обозначает, является ли параметр входным (in), выходным (out) или тем и другим (inout). Если направление не указано, то предполагается in.

Например, в классе “Счет” операция может выглядеть так:

+ balanceOn (date: Date) : Money

Следует различать операции, изменяющие состояние системы, и операции, не делающие этого. Язык UML определяет запрос как некую операцию, результатом которой является некоторое значение, получаемое от класса; при этом состояние системы не изменяется, то есть данная операция не вызывает побочных эффектов. Такую операцию можно пометить строкой свойств {query} (запрос). Операции, изменяющие состояние, называются модификаторами, иначе ­ командами. Строго говоря, различие между запросом и модификаторами состоит в том, могут ли они изменять видимое состояние. Видимое состояние – это то, что можно наблюдать извне.

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

Другие термины, с которыми иногда приходится сталкиваться, – это методы получения значения, или геттеры (getting methods) и методы установки значения, или сеттеры (setting methods). Метод получения значения возвращает некоторое значение из поля класса (и не делает ничего больше). Метод установки значения помещает некоторое значение в поле класса (и не делает ничего больше). Клиент класса за пределами класса не способен определить, является ли запрос методом получения значения или модификатор – методом установки значений. Эта информация о методах является исключительно внутренней для каждого из классов.

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

­8­

Практикум по промышленному программированию ­ 2015. Лабораторная работа №1

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

Отношения

ВUML используются четыре основных типа отношений:

1.зависимость (dependency);

2.ассоциация (association);

3.обобщение (generalization);

4.реализация (realization)

Зависимость

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

Графически отношение зависимости изображается в виде пунктирной линии со стрелкой, направленной от зависимой сущности к независимой (например, как на рис. 3). Как правило, семантика конкретной зависимости уточняется в модели с помощью дополнительной информации. Например, зависимость со стереотипом «use» означает, что зависимая сущность использует (скажем, вызывает операцию) независимую сущность.

Рис.3. Пример зависимости

Ассоциация

Ассоциация — это наиболее часто используемый тип отношения между сущностями.

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

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

Рис. 4. Представление свойств заказа в виде атрибутов

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

­9­

Практикум по промышленному программированию ­ 2015. Лабораторная работа №1

Рис. 5. Представление свойств заказа в виде ассоциаций

Естественно, возникает вопрос: «Когда следует выбирать то или иное представление свойств?». Как правило, небольшие элементы, такие как даты или логические значения, – главным образом, типы значений, обозначаются при помощи атрибутов, а ассоциации обозначают более значимые классы, такие как клиенты или заказы. Предпочтительно также использовать прямоугольники классов для наиболее значимых классов диаграммы, а ассоциации и атрибуты для менее важных элементов.

Двунаправленные ассоциации

Двунаправленная ассоциация, показанная на рис. 6, – это пара свойств, связанных в противоположных направлениях. Класс Car (Автомобиль) имеет свойство owner:Person[1], а класс Person (Личность) имеет свойство cars:Car[*]. (Обратите внимание, что использована множественная форма имени свойства cars по причине того, что у свойства кратность больше 1.)

Рис. 6. Двунаправленная ассоциация

Агрегация и композиция

Простая ассоциация между двумя классами отражает структурное отношение между равноправными сущностями, когда оба класса находятся на одном концептуальном уровне и ни один не является более важным, чем другой. Но иногда приходится моделировать отношение типа "часть/целое", в котором один из классов имеет более высокий ранг (целое) и состоит из нескольких меньших по рангу (частей). К примеру, можно сказать, что двигатель и колеса представляют собой части автомобиля. Отношение такого типа называют агрегированием (aggregation); оно причислено к отношениям типа "имеет" (с учетом того, что объект­целое имеет несколько объектов­частей). Агрегирование является частным случаем ассоциации и изображается в виде простой ассоциации с незакрашенным ромбом со стороны "целого" (рис. 7).

Наряду с агрегацией в языке UML есть более определенное свойство – композиция (composition). Композиция — более строгий вариант агрегации. Композиция имеет жёсткую зависимость времени существования экземпляров класса­контейнера и экземпляров содержащихся классов. Если контейнер будет уничтожен, то всё его содержимое будет также уничтожено. Графически представляется так же, как и агрегация, но с закрашенным ромбиком.

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

­10­