Основы UML - Диаграммы - Диаграмма классов

E-mail Печать PDF
Рейтинг пользователей: / 8
ХудшийЛучший 
Индекс материала
Основы UML
Способы применения UML
Модель и ее элементы
Диаграммы
Диаграммы - Классификация
Диаграммы - Диаграмма классов
Диаграммы - Диаграмма прецендентов
Диаграммы - Диаграмма объектов
Диаграммы - Диаграмма деятельности
Диаграммы - Диаграмма последовательности
Диаграммы - Диаграмма размещения
Диаграммы - Диаграмма пакетов
Все страницы

Диаграмма классов

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

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

Основные элементы нотации, применяемые на диаграмме классов, показаны на рисунке:

Свойства

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

Атрибуты

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

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

Например:

+ наименование: String = “не задано” {readOnly}

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

·         Метка видимость обозначает, относится ли атрибут к открытым (+) (public) или закрытым (-) (private).

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

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

Ассоциации

Другая часть свойств – это ассоциации. Ассоциация это непрерывная линия между двумя классами, направленная от исходного класса к целевому. Имя свойства (вместе с кратностью) располагается на целевом конце.

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

Кратность

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

·         1 (Заказ может предоставить только один клиент.)

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

·         * (Клиент может разместить ноль или более заказов.)

Операции

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

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

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

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

+ balanceOn (date: Date) : Money

Обобщения

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

Важным принципом эффективного использования наследования является замещаемость. Это означает, что если программа рассчитана на использование класса Клиент, то она может работать с любыми его подтипами (это является «Принципом подстановки Лискоу»).

Зависимости

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

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



 

Добавьтe Ваш комментарий

Ваше имя (псевдоним):
Ваш адрес почты:
Заголовок:
Комментарий:

Комментарии, категория: "IT"

Интересное




Похожие материалы

Партнёры