Дж. Арлоу, А. Нейштадт - UML 2 и Унифицированный процесс - Практический объектно-ориентированный анализ и проектирование (1158625), страница 31

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

Текст из файла (страница 31)

Пунктирная линия со стрелкой обозначает отношение зависимости, которому стереотип «instantiate» придает особое значение. Какбыло показано в главе 1, все, что находится во французских кавычках(«…»), называется стереотипом. Стереотипы – один из трех механизAccountnumber : Stringowner : Stringbalance : doubleклассwithdraw()deposit()«instantiate»«instantiate»fabsAccount:BankAccountjimsAccount:BankAccountобъектыnumber : "801"owner : "Jim"balance : 300.00number : "802"owner : "Fab"balance : 1000.00Рис. 7.6.

Отношение «instantiate»«instantiate»ilasAccount:BankAccountnumber : "803"owner : "Ila"balance : 310.00158Глава 7. Объекты и классымов расширения в UML. Стереотип – это способ настройки элементовмодели, способ создания вариантов с новой семантикой. В данном случае стереотип «instantiate» превращает обычную зависимость в отношение конкретизации между классом и объектами этого класса.«UML Reference Manual» [Rumbaugh 1] определяет зависимость как«отношение между двумя элементами, при котором изменение одногоэлемента (поставщика) может влиять или поставлять информацию, необходимую другому элементу (клиенту)».

Из рис. 7.6 очевидно, чтокласс Account должен быть поставщиком, потому что он определяетструктуру всех объектов этого класса, а объекты – это клиенты.7.4.2. Создание экземпляров классаСоздание экземпляров (instantiation) – это создание новых экземпляров элементов модели. В данном случае создаются объекты классов.Создаются новые экземпляры классов.При создании экземпляра класса создается новый объект. Класс используется как шаблон.UML старается быть универсальным, поэтому создание экземпляровприменяется не только к классам и объектам, но и к другим элементаммодели.

Понятие создания экземпляров, по сути, представляет общийпроцесс создания конкретного экземпляра чеголибо по шаблону.В большинстве ОО языков есть специальные операции, называемыеконструкторами, которые на самом деле принадлежат классу, а не объектам этого класса. Говорят, что область действия этих специальныхопераций – класс. Более подробно на области действия мы остановимсяв разделе 7.6. Назначение операции конструктор – создание новых экземпляров класса. Конструктор выделяет память для нового объекта,присваивает ему уникальный идентификатор и задает исходные значения атрибутов. Он также настраивает все связи с другими объектами.7.5. Нотация классов в UMLВизуальный синтаксис UML для класса очень богат.

Чтобы синтаксисбыл управляемым, в UML существует понятие необязательных дополнений. Обязательной частью в визуальном синтаксисе является только ячейка с именем класса. Все остальные ячейки и дополнения необязательны. Однако для справки на рис. 7.7 показано все.Показывайте только важные ячейки и дополнения.Какие ячейки и дополнения будут включены в класс на диаграммеклассов, зависит только от назначения диаграммы. Если интерес представляют лишь отношения между различными классами, тогда может1597.5.

Нотация классов в UMLимя класса«entity»BankAccountячейка имениячейка атрибутовячейка операцийстереотип!number : String!owner : String!balance : double = 0.0помеченное значение{ author = Jim,status = tested }исходное значение+create( theNumber : String, theOwner : String )+deposit( amount : double )+withdraw( amount : double )операция с областью+ getNumber() : Stringдействия – класс (подчеркнута)+ getOwner() : String+ getBalance() : doubleдополнение видимостиРис.

7.7. Нотация классов в UMLбыть достаточно ячейки с именем. Если диаграмма призвана проиллюстрировать поведение классов, тогда, вероятно, в каждый класс будетдобавлена ячейка с ключевыми операциями. С другой стороны, диаграмма может быть более «ориентированной на данные», напримерпредставлять проецирование классов в реляционные таблицы. В этомслучае должны быть показаны ячейки имени и атрибутов, возможно,и типы атрибутов.

Необходимо стремиться использовать эту гибкостьUML и размещать на диаграмме классов именно такой объем информации, который необходим для четкого и лаконичного представленияидеи.В аналитических моделях обычно необходимо показывать только:• имя класса;• ключевые атрибуты;• ключевые операции;• стереотипы (если они приносят пользу делу).Обычно не показывают следующее:• помеченные значения;• параметры операций;• видимость;• исходные значения (если только они не значимы для дела).В нескольких следующих подразделах будут более подробно рассмотрены ячейки имени, атрибутов и операций.7.5.1. Ячейка имениХотя UML не определяет для классов никаких обязательных соглашений о присваивании имен, существует общепринятое соглашение.160Глава 7.

Объекты и классы•Имя класса записывается в стиле UpperCamelCase: имя и все слова,его образующие, пишутся с заглавной буквы. Специальные символы, такие как знаки препинания, тире, подчеркивание, «&», «#»и слэш, никогда не используются.

Для этого есть достаточное основание: эти символы применяются в таких языках, как HTML и XML,и в операционных системах. Поэтому их применение в именахклассов или именах любых других элементов модели может привести к неожиданным последствиям при генерации из модели кодаили документации HTML/XML.Никогда не используйте аббревиатуры в именах классов, атрибутов илиопераций.•Во что бы то ни стало необходимо избегать сокращений. Именаклассов всегда должны отражать имена реальных сущностей без сокращений. Например, имя FlightSegment всегда более предпочтительно, чем FltSgmnt, DepositAccount предпочтительнее, чем DpstAccnt.Опять же причина этому очень простая – аббревиатуры затрудняютчтение модели (и результирующего кода).

Время, сэкономленноепри наборе, не сравнимо со временем, необходимым для обслуживания моделей или кода с сокращенными именами.•Если есть специальные акронимы данной предметной области (например, CRM (Customer Relationship Management – управление взаимоотношениями с клиентами)), широко используемые и понятныевсем пользователям модели, они могут применяться. Однако необходимо помнить, что полное имя, если оно делает модель более понятной, все равно предпочтительнее.Классы представляют «сущности», поэтому их имена должны быть существительными или именной группой, например Person (человек),Money (деньги), BankAccount (банковский счет).7.5.2.

Ячейка атрибутовЕдинственной обязательной частью UMLсинтаксиса для атрибутов(рис. 7.8) является имя атрибута. Имена атрибутов записываются в стиле lowerCamelCase, т. е. начинаются со строчной буквы, а далее большиеи малые буквы пишутся вперемежку. Обычно в качестве имен атрибутов используются имена существительные или именные группы, потому что атрибуты указывают на некоторую «сущность», например баланс счета.

Необходимо избегать специальных символов и сокращений.видимость имя : тип [множественность] = начальноеЗначениеобязателенРис. 7.8. UML+синтаксис для атрибутов1617.5. Нотация классов в UMLНеобязательные части синтаксиса атрибутов рассматриваются в следующих нескольких разделах.7.5.2.1. ВидимостьВидимость контролирует доступ к свойствам класса.Дополнение видимости (visibility) (табл.

7.3) применяется к атрибутам и операциям класса. Оно также может применяться к именам ролей в отношениях (глава 9). При анализе диаграммы обычно не загромождают видимостями, поскольку, по сути, это дополнение дает описание того «как», а не «что».Таблица 7.3Дополнение ВидимостьСемантика+Public (Открытый)Любой элемент, который имеет доступ к классу, имеет доступ к любойиз его возможностей, видимость которой public.–Private (Закрытый)Только операции класса имеют доступ к возможностям, имеющим видимость private.#Protected (Защищенный)Только операции класса или потомкакласса имеют доступ к возможностям, имеющим видимость protected.~Package (Пакетный)Любой элемент, находящийся в одном пакете с классом или во вложенном подпакете, имеет доступ ко всемего возможностям, видимость которых package.Языки реализации могут поразному интерпретировать все типы видимости UML, кроме public (открытый).

Это важно. Фактически языки программирования могут определять дополнительные типы видимости, которые UML не поддерживает по умолчанию. Обычно это непроблема. Самые распространенные ОО языки программирования, такие как С++ и Java, и даже популярные полуОО языки, например Visual Basic, замечательно справляются с видимостями public, private(закрытый), protected (защищенный) и package (пакетный), по крайней мере, в первом приближении.Давайте более подробно рассмотрим два ОО языка.

Характеристики

Список файлов книги