Имя Операции (аргумент1: тип данных аргумента1, аргумент2: тип данных аргумента2,.): тип возвращаемого значения

Существуют четыре различных типа операций.

· Операции реализации (implementor operations) реализуют некоторые функции (процедуры). Такие операции выявляются путем анализа диаграмм взаимодействия UML.

· Операции управления (manager operations) управляют созданием и уничтожением объектов. В эту категорию попадают конструкторы и деструкторы классов.

· Атрибуты обычно бывают закрытыми или защищенными. Тем не менее, другие классы иногда должны просматривать или изменять их значения. Для этого существуют операции доступа (access operations).

· Вспомогательными (helper operations) называются такие операции класса, которые необходимы ему для выполнения его обязанностей, но о которых другие классы не должны ничего знать. Это закрытые и защищенные операции класса.

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

Полиморфизм — это способность скрывать множество различных реализаций под единственным общим интерфейсом.

Интерфейс — совокупность операций, определяющих набор услуг класса или компонента. Интерфейс не определяет внутреннюю структуру, все его операции имеют открытую видимость

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

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

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

· компонентом исходного кода;

· компонентом времени выполнения (run time);

· исполняемым компонентом.

Компонент обеспечивает физическую реализацию набора интерфейсов.

Между элементами объектной модели существуют различные виды связей. К основным типам связей относятся связи ассоциации, зависимости и обобщения.

Ассоциация (association) это семантическая связь между классами. Ее изображают на диаграмме классов в виде обыкновенной линии (рис. 2.39). Ассоциация отражает структурные связи между объектами различных классов.

Рис. 2.39. Ассоциация

Агрегация (aggregation) представляет собой форму ассоциации — более сильный тип связи между целым (составным) объектом и его частями (компонентными объектами).

Существуют четыре возможных семантики для агрегации:

1) агрегация типа «Безраздельно обладает»;

2) агрегация типа «Обладает»;

3) агрегация типа «Включает»;

4) агрегация типа «Участник».

Агрегация типа «Безраздельно обладает» устанавливает следующее:

· между компонентными объектами и их составными объектами установлено отношение зависимости по существованию (следовательно, удаление составного объекта распространяется вниз по иерархии отношения, так что связанные компонентные объекты также удаляются);

· агрегация транзитивна (если объект С1является частью объекта В1, а B1 — частью А1, тогда С1 является частью А1);

· агрегация асимметрична (нерефлексивна) (если объект В1является частью объекта А1, то объект A1 не является частью В1 );

· агрегация стационарна (если объект В1является частью объекта A1, то он не может быть частью объекта Ai(i 1)).

Агрегация типа «Обладает» поддерживает первые три свойства агрегации «Безраздельно обладает», к которым относятся:

· зависимость по существованию;

· транзитивность;

· асимметричность.

Агрегация типа «Включает» слабее, чем агрегация типа «Обладает», она поддерживает транзитивность и асимметричность.

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

Язык UML обеспечивает ограниченную поддержку агрегации. Сильная форма агрегации является в UML композицией. В композиции составной объект может физически содержать компонентные объекты. Компонентный объект может принадлежать только одному составному объекту. Композиция языка UML в большей или меньшей степени соответствует агрегациям типа «Безраздельно обладает» и «Обладает».

Слабая форма агрегации в UML называется просто агрегацией. При этом составной объект физически не содержит компонентный объект. Один компонентный объект может обладать несколькими связями ассоциации или агрегации. Иначе говоря, агрегация в языке UML соответствует агрегациям типа «Включает» и «Участник».

Агрегация изображается линией между классами с ромбом на стороне целого объекта (рис. 2.40). Сплошной ромб представляет композицию (рис. 2.41).

Рис. 2.40 Агрегация

Рис 2.41. Композиция

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

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

Связи можно уточнить с помощью имен связей или ролевых имен. Имя связи — это обычно глагол или глагольная фраза, описывающая, зачем она нужна. Например, между классом Person (человек) и классом Company (компания) может существовать ассоциация. Если человек является сотрудником компании, ассоциацию можно назвать «employs» (нанимает) (см. рис. 2.39).

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

Для уточнения роли, которую играет каждый класс в связях ассоциации или агрегации, применяют ролевые имена (рис. 2.42). Возвращаясь к примеру с классами Person и Company, можно сказать, что класс Person играет роль сотрудника класса Company. Ролевые имена — это обычно имена существительные или основанные на них фразы, их показывают на диаграмме рядом с классом, играющим соответствующую роль. Как правило, пользуются или ролевым именем, или именем связи, но не обоими сразу. Как и имена связей, ролевые имена не обязательны, их дают, только если смысл связи не очевиден.

Рис 2.42. Ролевые имена

Мощность (multiplicity) показывает, как много объектов участвует в связи. Мощность — это число объектов одного класса, связанных с одним объектом другого класса. Понятие мощности связи в объектной модели аналогично понятиям мощности и класса принадлежности связи в модели «сущность-связь» (с точностью до расположения показателя мощности на диаграмме). Для каждой связи можно обозначить два показателя мощности — по одному на каждом конце связи.

В языке UML приняты следующие нотации для обозначения мощности.


Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:  



double arrow
Сейчас читают про: