Краткое описание методологии моделирования классов в языке UML

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

Также можно увидеть, что все вещи естественным образом разделяются по категориям (автомобили, мебель, стиральные машины и т.д.). Мы об­ращаемся к этим категориям как к классам. Класс – это категория или группа вещей, которая имеет сходные атрибуты и общие свойства. На­пример, любая вещь в классе стиральных машин имеет такие атрибуты, как производитель, номер изделия и емкость. Свойства вещей в этом классе включают операции «загрузить белье», «загрузить стиральный по­рошок», «включить» и «выгрузить белье».

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

 

СтиральнаяМашина

производитель

модель

серийныйНомер

мощность

объемБарабана

внутреннийТаймер

фильтр

двигатель

скоростьДвигателя

загрузитьБелье()

загрузитьПорошок()

выгрузитьБелье()

добавитьОтбеливатель()

задатьВремяЗамачивания()

задатьВремяСтирки()

задатьВремяСлива()

задатьВремяОтжима()

Рис. 16. Изображение класса в UML

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

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

Диаграмма объектов

Объект представляет собой экземпляр класса – особую сущность, кото­рая имеет заданные значения атрибутов и операций. Ваша стиральная машина, например, может иметь атрибуты: компания-производитель – Laundatorium, наименование модели – Washmeister, серийный номер из­делия – GL57774 и емкость – 16 фунтов.

На рис. 17 показано, как объект представляется в обозначениях UML. Отметим, что объект изображается прямоугольником, как в случае представления класса, но его имя подчеркнуто. Наименование экземпляра размещено слева от двоеточия, а наиме­нование класса – с правой стороны.

 

мояМашина: СтиральнаяМашина

 

 

Рис. 17. Представление объекта в UML

 

Прямоугольник – это условное обозначение класса в UML. Именем класса обычно является слово, начинающееся с прописной буквы. Оно располагается вверху прямоугольника. Если имя класса состоит из двух слов, объеди­ните их и второе слово тоже напишите с прописной буквы (например, Стиральная Машина, рис. 18).

 

СтиральнаяМашина

Рис. 18. Обозначение класса в UML

 

Атрибуты

Атрибут – это свойство класса. Атрибуты описывают перечень значе­ний, в рамках которых указываются свойства объектов (т.е. экземпляров) этого класса. Класс может не иметь атрибутов или содержать любое их количество. Имена атрибутов, состоящие из одного слова, принято обо­значать строчными буквами. Если имя состоит из нескольких слов, то эти слова объединяются, и каждое слово, за исключением первого, начи­нается с прописной буквы. Список имен атрибутов начинается ниже ли­нии, отделяющей их от имени класса (рис. 19, 20).

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

 

WashingMachine

brandName

modelName

serialName

capacity

Рис. 19. Класс и его атрибуты

 

myWasher: WashinqMashine

brandName = "Laundatorium"

modelName = "Washmeister"

serialNumber = "GL57774"

capacity =16

Рис. 20. Значения атрибутов класса

 

WashingMachine

brandName: String = "Laundatorium"

modelName: String

serialNumber: String

capacity: Integer

Рис. 21. Типы атрибутов и значения по умолчанию

 

Перечислимый тип представляет собой информацию, заданную списком именованных значений. Логический тип также является перечислимым, по­тому что он состоит из значений «истина» и «ложь». Можно определить свои собственные перечислимые типы (например, Состояние), образованные из значений «твердое», «жидкое» и «газообразное».

Операции

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

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

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

 

WashingMachine

brandName

modelName

serialNumber

capacity

addClothes()

removeClothes()

addDetergent()

turnOn()

Рис. 22. Операции класса и их сигнатуры

 

WashingMachine

brandName

modelName

serialNumber

capacity

addClothes(C:String)

removeClothes(С:String)

addDetergent(D:Integer)

turnOn():Boolean

Рис. 23. Сигнатуры операций класса

 

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

Стереотип является гибкой конструкцией, которую можно использовать по-разному. Например, если разместить его над именем класса, то можно ука­зать дополнительную информацию о роли этого класса.

WashingMachine

«идентификационные данные»

brandName

modelName

serialNumber

«данные о машине»

capacity

«для белья»

addClothes()

removeClothes()

addDetergent()

«для машины»

turnOn()

Рис. 24. Задание стереотипов

 

Обязанности и ограничения

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

На изображении класса его обязанности перечисляются ниже области операций (рис. 25).

 

WashingMachine

«идентификационные данные»

brandName

modelName

serialNumber

«данные о машине»

capacity

«для белья»

addClothes()

removeClothes()

addDetergent()

«для машины»

turnOn()

Обязанность:

взять грязное белье на входе

и выдать чистое

на выходе

Рис. 25. Обязанности класса

 

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

Более формальным путем решения задачи является добавление ограниче­ний в виде произвольного текста, заключенного в фигурные скобки. Этот текст задает одно или несколько правил класса, к которому он относится. Предположим, для класса WashingMachine нужно указать, что емкость барабана может составлять только 16, 18 или 20 фунтов (и таким образом «ограничить» атрибут емкости). Тогда рядом с изображением класса нужно написать (capacity = 16 или 18 или 20 фунтов). На рис. 26 показано, как это сделать.

 

WashingMachine
brandName
modelName
serialNumber
capacity	{capacity = 16 или 18 или 20 фунтов}
addClothes()
removeClothes()
addDetergent()
turnOn()

Рис. 26. Ограничения классов

 

Комментарии

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

Комментарии обычно связаны с атрибутами и операциями. На рис. 27 приведен комментарий, ссылающийся на правительственный Стандарт по формированию номеров изделий для объектов класса WashingMachine.

 

WashingMachine
brandName modelName serialNumber capacity		В соответствии с правительственным Стандартом EV-2241 о присвоении серийных номеров
addClothes () removeClothes () addDetergent () turnOn ()

Рис. 27. Типы атрибутов и значения по умолчанию

 

Комментарий наряду с текстом может содержать также и графические объекты.

Недостающая информация – это взаимодействие классов между собой. Если взглянуть на модель (рис. 28), то можно заметить отсутствие связи игрока с мячом. Из самой модели не понятно, как игроки образуют команду или как происходит игра. Сконструи­рован лишь список терминов, но не «снимок» предметной области.

Рассмотрим связи между классами, позволяющие дополнить карти­ну предметной области.

Ассоциации

Если классы концептуально взаимодействуют друг с другом, то такое взаимодействие называется ассоциацией. Исходная модель игры в баскетбол содержит несколько подобных примеров. Рассмотрим одну ассоциацию – между игроком икомандой. Ее можно охарактеризовать фразой «игрок играет в ко­манде» и отобразить в виде соединяющей два класса линии, указав имя ассо­циации (играет в) прямо над этой линией. Для наглядности с помощью за­крашенного треугольника указывается направление взаимосвязи. На рис. 28 показано, как изобразить ассоциацию «Играет в» между игроком и командой.

 

Рис. 28. Ассоциация между классами

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

 

Рис. 29. Роль класса в ассоциации

 

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

 

Рис. 30. Две ассоциации между классами

 

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

 

Рис. 31. Ассоциации нескольких классов с одним

 

Ограничения ассоциаций

Иногда ассоциация между двумя классами должна удовлетворять некоторому пра­вилу. Это правило заключается в размещении ограничения возле линии ассоциации. Например, Банковский Служащий обслуживает клиентов по очереди. Этот факт отра­жается в модели с помощью фразы {по очереди} в фигурных скобках возле класса Клиент – для отражения ограничения (рис. 32).

 

Рис. 32. Ограничения на ассоциацию

 

Другой тип ограничения представляется отношением ИЛИ, которое обозначается с помощью пунктирной линии, соединяющей две линии ассоциаций с надписью {или}. Модель на рис. 33 показывает студента, выбирающего бюджетную или ком­мерческую форму обучения.

 

Рис. 33. Отношение ИЛИ между двумя ассоциациями

 

Связи

Ассоциация (как и класс) характеризуется наличием экземпляров. Если предста­вить себе конкретного игрока, играющего в конкретной команде, отношение «Играет в» называется связью,которую изображают в виде линии, соединяющей два объекта. Имя этой связи, как и имя объекта, подчеркивается (рис. 34).

 

Рис. 34. Связь как элемент ассоциации

 

Кратность

Ассоциация между объектами Игрок и Команда предполагает, что два класса находятся в отношении «один к одному». Здравый смысл подсказывает, что это не единственный ва­риант взаимосвязи. В баскетбольной команде пять человек, не считая запасных игроков. Ассоциация «Включает» должна учитывать этот факт. С другой стороны, игрок может играть только в одной команде, что должно учитываться в ассоциации «Играет в».

 

Рис. 35. Кратность связи

 

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

Рис. 36. Возможные значения кратности

 

В этом примере приведен только один из вариантов кратности. Возможны также и другие значения кратности. Один класс может быть связан с другим различными спосо­бами: «один к одному», «один ко многим», «один к нескольким», «один к ограниченному интервалу» (например, «один к 5..10»), «один к заданному количеству» (как в рассматриваемом примере) или «один к набору» (например, «один к 9 или 10»).

Для представления понятия «много» в UML используется символ звездочки (*). Логическое ИЛИ передается двумя обозначениями: с помощью двух точек (1.. *), что означает «один или более», или запятой (5,10), что означает «5 или 10». На рис. 36 показаны изображения возможных значений кратности.

Если класс А находится в отношении «один к 0 или 1» с классом Б, то по­следний называется необязательным для класса А.

Квалификатор ассоциации

Если кратность ассоциации описывается отношением «один ко многим», возника­ет проблема поиска. Если объект одного класса для выполнения отведенной ему роли в ассоциации должен выбрать конкретный объект другого класса, то он может сделать это на основе некоторого заданного атрибута. Этот атрибут обычно представляет со­бой идентификатор, а точнее, числовой идентификатор. Когда вы резервируете место в гостинице, вам присваивается номер заказа. Если нужно узнать о наличии зарезерви­рованного места, необходимо сообщить номер заказа.

В UML идентифицирующая информация называется квалификатором. Он обозначается небольшим прямоугольником, который прилегает к обозначе­нию класса, выполняющего поиск (рис. 37). Такое изображение позволяет эффективно свести кратность «один ко многим» к случаю «один к одному».

 

Рис. 37. Квалификатор ассоциации

 

Рефлексивные ассоциации

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

 

Рис. 38. Рефлексивная ассоциация

 

Наследование и обобщение

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

В рамках объектно-ориентированного подхода такое положение вещей называется наследованием. В UML для наследования используется термин обобщение. Один класс (дочерний или подкласс) может наследовать атри­буты и операции другого (родительского класса или суперкласса). Роди­тельский класс является более общим по отношению к дочернему.

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

Иерархия наследования не ограничивается двумя уровнями: дочерний класс может вы­ступать в роли родительского класса для другого дочернего класса. Класс Млекопитающее является дочерним классом для класса Животное и родительским – для класса Лошадь.

В UML наследование отображается с помощью линии, которая соединяет родительский класс с дочерним. Конец линии, связанный с родительским классом, поме­чается не закрашенным треугольником, указывающим на родительский класс. Такая связь соответствует отношению – «является видом». Млекопитающее «является видом» жи­вотного, лошадь «является видом» млекопитающего. На рис. 39 представлены ранее описан­ная иерархия наследования и дополнительные классы. Обратите внимание на графи­ческое представление ситуации, когда родительский класс имеет несколько дочерних классов. Такая конструкция позволяет разгрузить диаграмму. Нужно отметить, что UML не за­прещает изображать все без исключения линии и треугольники и не требует указы­вать наследуемые атрибуты и операции в прямоугольниках подклассов, т.к. они уже представлены в обозначении суперкласса.

При моделировании наследования нужно убедиться, что дочерний класс удовлетворяет требованию «является видом» по отношению к родительско­му классу. Если связь классов описывается по-другому, нужно использовать другую ассоциацию.

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

Класс может не иметь родителя. В этом случае он называется базовым или корневым классом. Класс также может не иметь дочернего класса, и тогда он называется листовым классом. Если класс имеет только одного родителя, то говорят об одиночном наследовании, а если несколько – о множественном наследовании.

Рис. 39. Иерархия наследования

 

Зависимости

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

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

 

Рис. 40. Изображение зависимости