Работа с коллекциями объектов

Для стандартных коллекций объектов, таких как список, массив и пр., в UML введено специальное понятие мультиобъекта. Пример мультиобъекта приведен на рис. 82. В имени мультиобъекта после двоеточия указывается тип элементов коллекции.

Рис. 82. Пример мультиобъекта

Рис. 83. Примеры работы с коллекциями

Важно понимать разницу между мультиобъектом и специализированной коллекцией. Мультиобъект – это стандартная коллекция объектов, которая реализуется такими классами, как, например, ArrayList в.NET. Соответственно мультиобъекту можно отправлять только простые сообщения, типа добавить/удалить элемент, получить количество элементов и т.д. Если нужна сложная логика (например, получить все продажи за некоторый период), то необходимо создавать отдельный класс. На рис. 83 представлены некоторые примеры работы с коллекцией товарных позиций.

Сообщения классу

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

Рис. 84. Пример сообщения классу

Видимость объектов

Видимость между объектами является необходимым условием для обмена сообщениями. Для отправки сообщения объектом А объекту Б необходимо, чтобы объект Б был виден объекту А. Существуют следующие четыре способа обеспечения видимости объекта Б объектом А:

1. Посредством атрибутов (ассоциаций). Ссылка на объект Б является значением некоторого атрибута объекта А.

2. Посредством параметров. Ссылка на Б передается в качестве параметра в некоторый метод объекта А.

3. Локальная видимость. Ссылка на объект Б хранится в локальной переменной некоторого метода объекта А.

4. Глобальная видимость. Объект Б доступен глобально объекту А.

Кроме того, каждый объект видит сам себя. Способ обеспечения видимости между объектами пишется в кавычках со стороны видимого объекта (рис. 85). Если способ обеспечения видимости не указан, то подразумевается видимость посредством ассоциаций.

Рис. 85. Видимость между объектами

В представленном выше списке способы обеспечения видимости перечислены в порядке убывания их приоритета. Если некоторый объект виден несколькими способами, то следует на диаграмме указывать тот способ, который имеет больший приоритет. Например, на рис. 85 объект оп: ОписаниеТовара передается в качестве параметра конструктора при создании объекта тп: ТоварнаяПозиция, после чего между ними формируется связь, соответствующая ассоциации «ссылается на» (рис. 71). Поскольку видимость посредством ассоциации имеет больший приоритет, чем видимость посредством параметра, то на диаграмме (рис. 85) указывается именно она.

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

Вопросы для самоконтроля

1. В чем состоит основная цель этапа проектирования?

2. В чем разница между диаграммой последовательностей и диаграммой сотрудничества?

3. Что такое сотрудничество и взаимодействие? Как они связаны?

4. Какие сообщения можно посылать мультиобъектам?

5. Для чего нужна видимость между объектами?

6. Какие существуют способы обеспечения видимости?

Задания для самостоятельной работы

1. Постройте концептуальную модель диаграммы сотрудничества.

2. Постройте диаграммы сотрудничества для учебного задания.

Типичные ошибки

Типичной ошибкой является злоупотребление переменными. Если для реализации Вашего взаимодействия требуется много переменных, то, скорее всего, Ваши объекты обрабатывают не свои данные, что противоречит объектно-ориентированному подходу. Старайтесь свести количество сообщений к разумному минимуму.

Рекомендации по построению диаграмм
сотрудничества

Диаграммы сотрудничества – это самые сложные для восприятия диаграммы. Старайтесь делать их максимально наглядными и простыми.

Тема 6.7. Проектирование статической структуры системы и диаграмма классов

Тематический контекст

Краткое содержание

1. Диаграмма классов. Видимость членов класса.

2. Описание атрибутов и операций.

3. Параметризованные классы.

4. Квалифицированные ассоциации.

5. Правила построения диаграммы классов.

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

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

– каждому объекту на диаграмме сотрудничества должен соответствовать класс на диаграмме классов;

– каждому входящему сообщению должны соответствовать операция или свойство класса принимающего его объекта;

– для каждой связи между объектами типа «ассоциация» на диаграмме классов должна присутствовать ассоциация;

– для прочих типов связей между объектами на диаграмме классов должны присутствовать зависимости.

На рис. 86 представлена диаграмма классов, которая была построена на основе рассмотренных выше диаграмм сотрудничества.

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

Операции

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

Информация о типах

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