Файл: Практикум по промышленному.docx

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

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

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

Чем дольше вы работаете с 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

Диаграмма	Цель диаграммы
Деятельности	Процедурное и параллельное поведение
Классов	Классы, свойства и отношения
Взаимодействия	Взаимодействие между объектами; акцент на связях
Компонентов	Структура и взаимосвязи между компонентами

Составных структур	Декомпозиция класса во время выполнения
Развертывания	Развертывание артефактов в узлы
Обзора взаимодействий	Комбинация диаграммы последовательности и диаграммы деятельности
Объектов	Вариант конфигурации экземпляров
Пакетов	Иерархическая структура времени компиляции
Последовательности	Взаимодействие между объектами; акцент на последовательности
Конечных автоматов	Как события изменяют объект в течение его жизни
Временная	Взаимодействие между объектами; акцент на синхронизации
Прецедентов	Как пользователи взаимодействуют с системой

---

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

---

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

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

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

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

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

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

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

Свойства

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

Атрибуты

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

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

Например:

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

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

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

) (package);

---