Основы создания диаграммы классов
Диаграмма классов является основным источником платформенно-независимой информации (PIM) для формирования модели приложения в Borland MDA. Она занимает центральное место в объектно-ориентированном анализе и проектировании (ООАП) программных систем. Диаграмма классов описывает статическую структуру системы, то есть состав элементов (классов), состав их атрибутов и операций, а также связи между классами (отношения). В ней не содержится информация о развитии системы во времени.
В основе диаграммы классов лежит понятие класса. Не углубляясь сейчас в детали, будем считать, что понятие класса знакомо разработчикам, использующим методологию объектно-ориентированного программирования. Итак, класс изображается в UML-модели в виде прямоугольника, разделенного на две или три части (рис. 1). В верхней части отображается имя класса — это обязательный параметр. Во второй сверху части отображаются атрибуты класса, возможно — с указанием их типа и значения по умолчанию. В нижней части класса отображаются названия операций и, возможно, списки аргументов и тип возвращаемого результата. Атрибутов и операций у класса может быть несколько. С точки зрения программиста атрибуты и операции аналогичны соответственно свойствам и методам в объектно-ориентированном программировании (ООП). Класс, который не может иметь ни одного объекта (экземпляра), является абстрактным. В этом случае его название отображается курсивом.
Отношения (relationship) между классами в UML сводятся к четырем базовым типам:
• зависимость (dependency);
• ассоциация (association);
• обобщение (generalization);
• реализация (realization).
Рассмотрим сейчас только два из них — ассоциацию и обобщение.
Ассоциация указывает на наличие некоторой связи между классами, например, «отдел—сотрудники». Она отображается сплошной линией (рис. 2). Линия ассоциации может соединять два (бинарная ассоциация) или более (N-ассоциация) классов. В последнем случае место соединения нескольких ассоциаций обозначается ромбом (на рис. 2 представлена бинарная ассоциация). Ассоциация может иметь имя, в этом случае оно располагается над линией ассоциации (на рис. 2 имя отсутствует). Концам линии ассоциации — ролям — даются названия. В данном случае ассоциация обладает ролями «Включает» и «Работает в». Кроме того, концы линии ассоциации имеют обозначения размерности, которые указывают на кратность отношения. Так, из рис. 2 можно сделать следующие выводы относительно описываемой модели (то есть восстановить заложенные в нее бизнес-правила):
• каждый отдел включает одного или несколько сотрудников (размерность «1..n»);
• каждый сотрудник работает только в одном отделе (размерность «1»).
Легко заметить кажущуюся аналогию между ассоциацией в UML и реляционными отношениями типа «один ко многим» и «многие ко многим» в СУБД. Однако далеко эту аналогию провести не удастся. Во-первых, в реляционной БД связь «многие ко многим» не может соединять две таблицы — для этого обязательно требуется еще одна промежуточная таблица. В UML же это вполне допустимо. Во-вторых, кратность в UML в принципе может быть любой, в том числе и нулевой. Так, если бы мы на конце ассоциации, указывающей на сотрудника, написали «0..n», то это означало бы, что могут существовать отделы, не имеющие ни одного сотрудника. А если бы мы задали кратность «15..50», то это говорило бы о том, что численность сотрудников в отделе не может быть меньше 15 и больше 50.
Нельзя не упомянуть и еще об одном важном варианте использования ассоциации. Рассмотрим UML-модель, изображенную на рис. 3. В ней оба конца ассоциации подключены к одному и тому же классу и определяют следующие бизнес-правила:
• каждый сотрудник может находиться в подчинении только у одного сотрудника (например, в подчинении у руководителя) либо не подчиняться ни одному из сотрудников (если он сам является руководителем);
• каждый сотрудник может руководить несколькими сотрудниками (если он является руководителем) либо не руководить ни одним (если он является рядовым сотрудником).
Использование ассоциаций в таком варианте нередко встречается при создании моделей приложений.
Вторым типом рассматриваемых отношений является обобщение, или генерализация. Данный тип отношения указывает, что между классами существует связь типа «предок—потомок», аналогичная отношению наследования в ООП. Такая связь отображается линией со стрелкой в форме пустого треугольника, причем треугольник-стрелка указывает на «предка», то есть на родительский класс. Так, на рис. 4 показано отношение обобщения между родительским классом «Человек» и дочерним классом «Гражданин». При этом необходимо учитывать, что все атрибуты класса-родителя автоматически принадлежат и классу-потомку, хотя в нем не отображаются. Поэтому класс «Гражданин», кроме представленных в нем атрибутов «Гражданство» и «Номер удостоверения личности», будет включать и атрибуты «Имя», «Вес» и «Рост». Отношения обобщения довольно часто используются при построении моделей, при этом в качестве класса-родителя нередко выступает какой-нибудь абстрактный класс.
Итак, мы ознакомились с базовыми понятиями, используемыми при построении диаграмм классов. В дальнейшем мы поговорим и о некоторых других возможностях и свойствах UML.
 |
|
