Лабораторная работа № 6 Создание диаграммы классов в среде проектирования Rational Rose
Диаграммы классов. Общая характеристика
Центральное место в объектно-ориентированном анализе и проектировании занимает разработка логической модели системы в виде диаграммы классов. Диаграмма классов служит для представления статической структуры модели системы.
Диаграмма классов – это диаграмма, на которой показано множество классов и статических связей между ними.
Класс – это описание совокупности объектов с общими атрибутами, операциями, отношениями и семантикой. Классы используются для составления словаря разрабатываемой системы. Это могут быть абстракции, являющиеся частью предметной области, или классы, на которые опирается реализация.
Графически класс изображается в виде прямоугольника, который может быть разделен на 3 раздела (рис. 6.1). В этих разделах указываются имя класса, атрибуты и операции (методы).
Рисунок 6.1 - Графическое изображение класса на диаграмме классов
Существует два основных вида статических связей: ассоциации и обобщения. Ассоциации представляют собой структурные отношения между классами. Обобщения связывают обобщенные классы со специализированными. Кроме этих видов связей, есть еще два вида: зависимость и реализации.
На диаграммах классов изображаются также атрибуты классов, операции классов и ограничения, накладываемые на связи между объектами.
Пример диаграммы классов приведен на рисунке 6.2.
Рисунок 6.2 - Диаграмма классов для системы обработки заказов клиентов
Существуют 3 различные точки зрения на построение диаграмм классов:
концептуальная точка зрения
точка зрения спецификации
точка зрения реализации.
С концептуальной точки зрения диаграммы классов отображают понятия изучаемой предметной области. Эти понятия могут соответствовать реализующим их классам, но прямое соответствие часто отсутствует. Концептуальная модель может не иметь никакого отношения к реализующему её программному обеспечению. Поэтому её можно рассматривать, как независимую от языка программирования.
При построении ДК с точки зрения спецификации учитывается ПО, но рассматриваются только интерфейсы, а не реализация.
При построении ДК с точки зрения реализации разработчики работают с уровнем реализации и диаграммы действительно отображают классы, использованные в программе.
Различия между точками зрения не слишком очевидны и часто разработчики смешивают разные точки зрения. На практике понимание точки зрения очень важно для построения и чтения диаграмм, так как каждый элемент диаграммы зависит от точки зрения. При построении диаграммы классов точка зрения должна быть ясной и единственной. При чтении диаграммы необходимо выяснить, с какой точки зрения она строилась.
Ассоциации
Ассоциации представляют собой структурные связи между классами. Вполне допустимы случаи, когда оба конца ассоциации относятся к одному и тому же классу. Это означает, что с объектом некоторого класса можно связать другие объекты из того же класса.
Рассмотрим ассоциации с разных точек зрения.
С концептуальной точки зрения ассоциации представляют собой концептуальные связи между классами. С этой точки зрения на диаграмме (рис. 6.2) видно, что Заказ должен поступить от единственного Клиента, а Клиент может сделать несколько Заказов. Каждый из Заказов содержит несколько Строк Заказа, а каждая Строка Заказа соответствует единственному Продукту.
Любая ассоциация обладает двумя ролями. Роль представляет направление ассоциации. Таким образом, ассоциация между Клиентом и Заказом содержит 2 роли – от Заказа к Клиенту и от Клиента к Заказу. Роль может быть поименована с помощью метки. Например, роль ассоциации от Заказа к Строкам Заказа называется «позиции Заказа». Если метки нет, то роли присваивается имя класса-цели, т.е. роль ассоциации от Заказа к Клиенту может быть названа «Клиент».
Роль обладает множественностью, которая показывает, сколько объектов может участвовать в данной связи. Множественность показывает нижнюю и верхнюю границы количества объектов, участвующих в связи. Символ * выражает диапазон «0 - ∞».
С точки зрения спецификации ассоциации представляют собой ответственности классов. В примере (рис. 6.2) подразумевается, что существует 1 или более методов, связанных с Клиентом, с помощью которых можно узнать, какие Заказы сделал данный Клиент. В классе Заказ существуют методы, с помощью которых можно узнать, какой Клиент сделал данный Заказ, и какие Строки Заказа входят в Заказ.
Если рассматривать наш пример с точки зрения реализации, то предполагается, что между связанными классами существуют указатели в обоих направлениях. Диаграмма классов показывает нам, что Заказ содержит поле, представляющее собой совокупность указателей на Строки Заказа и указатель на Клиента.
Обобщения
Обобщения – это отношения, которые связывают обобщенные классы (суперклассы) со специализированными (подклассами). Применительно к диаграмме классов данный вид связи описывает иерархическое строение классов и наследование их свойств и поведения. При этом предполагается, что класс-потомок обладает всеми свойствами и поведением класса-предка, а также имеет свои собственные свойства и поведение, которые отсутствуют у класса-предка. На диаграммах обобщение обозначается сплошной линией с треугольной стрелкой на одном из концов. Стрелка указывает на класс-предок (или суперкласс).
В нашем примере обобщенный класс Клиент (суперкласс) содержит одинаковые характеристики Частного и Корпоративного клиентов (подклассов). На концептуальном уровне подкласс является особым видом суперкласса. Все, что известно о суперклассе, справедливо и для подкласса.
В модели спецификации смысл обобщения заключается в том, что интерфейс подкласса должен включать все элементы интерфейса суперкласса.
С точки зрения реализации обобщение связано с понятием наследования в языках программирования. Подкласс наследует все методы и поля суперкласса и может переопределять наследуемые методы.
Атрибуты
Атрибут – это именованное свойство класса, включающее описание множества значений, которые могут принимать экземпляры этого класса. Класс может иметь любое число атрибутов или не иметь их совсем. Атрибут представляет некоторое свойство, общее для всех объектов данного класса. Атрибут является абстракцией данных объекта или его состояния.
На концептуальном уровне атрибут Имя клиента указывает на то, что Клиенты обладают именами.
На уровне спецификаций этот атрибут указывает на то, что объект Клиент может сообщить свое имя и обладает некоторым механизмом определения имени.
На уровне реализации класс Клиент содержит поле, соответствующее его имени.
На диаграммах обозначение атрибута может включать имя атрибута, тип и значение, присваиваемое по умолчанию. Синтаксис UML для атрибутов:
<признак видимости> <имя >:<тип> = <значение по умолчанию>
Видимость – это способность одной абстракции видеть другую и, таким образом, ссылаться на ее ресурсы извне. Абстракции видимы друг другу, только если они находятся в одном пространстве имен.
Признак видимости может принимать одно из 3 значений:
«+» - общий, открытый (public), т. е. видимый для всех классов и объектов;
«-» - закрытый, секретный (private), т.е. невидимый для других классов и объектов;
«#» - защищенный (protected), т.е. невидимый для всех других классов и объектов, за исключением подклассов,.
Видимость определяют для того, чтобы скрыть детали реализации атрибута и показать только те его особенности, которые необходимы для выполнения обязанностей, продекларированных абстракцией. При использовании видимости нужно применять правила того языка, на котором будет написана программа, т.к. разные языки программирования по-разному интерпретируют понятие «видимость».
Имя атрибута представляет собой строку текста, которая используется в качестве идентификатора соответствующего атрибута и поэтому должна быть уникальной в пределах данного класса. Имя атрибута является единственным обязательным элементом синтаксического обозначения атрибута.
Тип атрибута (необязательный элемент) указывается строкой текста, имеющей осмысленное значение в пределах модели, к которой относится рассматриваемый класс.
Значение по умолчанию служит для задания некоторого начального значения для соответствующего атрибута в момент создания отдельного экземпляра класса.
Операции
Операцией называется реализация услуги, которую можно запросить у любого объекта класса. Иначе говоря, операция – это абстракция того, что позволено делать с объектом.
Синтаксис UML для операций:
<признак видимости><имя>(<список параметров>):<тип выражения возвращающего значение >{<строка свойств>},
где признак видимости – тот же, что и для атрибутов,
имя – символьная строка,
список параметров – необязательные аргументы, синтаксис которых совпадает с синтаксисом атрибутов,
тип выражения возвращающего значение – является необязательной спецификацией и зависит от конкретного языка программирования,
строка свойств – показывает значения свойств, которые применяются к данной операции.
Пример операции: + кредитный Рейтинг():Строка
В концептуальной модели операции должны отражать принципиальное назначение класса.
Операции можно разделить на 2 вида:
Операции, не изменяющие состояние класса, они называются запросами. Их результат – некоторое извлекаемое из класса значение.
Операции, изменяющие наблюдаемое состояние объекта – модификаторы.
В языке UML существует различие между операцией и методом. Операции – это услуги, которые можно запросить у любого объекта класса для изменения поведения, а метод – это реализация операции.
Ограничения
В процессе построения диаграммы классов на ней отображаются различные ограничения. Например, в примере (рис. 6.2) показано, что Заказ может быть сделан одним Клиентом, что Корпоративный Клиент располагает Кредитным лимитом, а Частный Клиент – нет.
С помощью конструкций ассоциаций, атрибутов и множественности можно показать наиболее важные ограничения, но не все. Остальные ограничения тоже нужно отобразить. В языке UML нет строгого синтаксиса описания ограничений, кроме их помещения в фигурные скобки. Можно записывать ограничения на естественном языке, чтобы их было проще понимать, или использовать фрагменты программного кода.
Агрегирование и композиция
Простая ассоциация между двумя классами отражает структурное отношение между равноправными классами. Агрегация является частным случаем ассоциации. Агрегирование (агрегация) – это вид ассоциации, описывающий отношения между целым и частью.
Графически отношение агрегации изображается сплошной линией, один из концов которой представляет собой незакрашенный внутри ромб. Этот ромб указывает на тот из классов, который представляет собой «целое». Остальные классы являются его «частями» (рис.6.3).
Рисунок 6.3 - Графическое изображение отношения агрегации
в языке UML
Примером отношения агрегации может служить деление персонального компьютера на составные части: системный блок, монитор, клавиатуру и мышь. Используя язык UML, компонентный состав ПК можно представить в виде соответствующей диаграммы классов (рис.6.4), которая в данном случае иллюстрирует отношение агрегации.
Рисунок 6.4 - Диаграмма классов с использованием отношения агрегации
Существует вариация простого агрегирования – композиция.
Композиция – это форма агрегации, в которой целое владеет своими частями, имеющими одинаковое время жизни, т. е. с уничтожением целого уничтожаются и все его составные части.
В случае отношения композиции объект в любой момент времени может быть частью только одного целого, например, объект «рама» принадлежит только одному объекту «окно». При простом агрегировании часть может принадлежать одновременно нескольким целым, например, объект «стена» может принадлежать нескольким объектам «комната».
Графически отношение композиции изображается сплошной линией, один из концов которой представляет собой закрашенный внутри ромб. Этот ромб указывает на тот из классов, который представляет собой класс-композицию или «целое». Остальные классы являются его частями.
Пример диаграммы классов для класса Окно программы с использованием отношения композиции приведен на рисунке 6.5.
Рисунок 6.5 - Диаграмма классов с использованием отношения композиции