Моделирование отношений агрегации и композиции

Поиск агрегаций ведется параллельно с поиском ассоциаций. При объяснении отношения агрегации используют фразы “включает” (“has”) и “является частью” (“is part of”). Например, Книга “включает” Главу, Глава “является частью” Книги.

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

Моделирование отношений обобщения

Общие характеристики (атрибуты и операции) одного или более классов можно погрузить в более общий класс. Это явление известно как обобщение. Отношение обобщения соединяет базовый класс (суперкласс) с более специализированными классами (производными классами). Обобщение делает возможным наследование (многократное использование) характеристик суперкласса производным классом.

Помимо наследования обобщение преследует еще две цели:

1 Использование подстановки.

2 Использование полиморфизма.

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

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

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

Спецификация поведения

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

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

Вычисления можно смоделировать с помощью диаграмм видов деятельности.

Взаимодействие объектов можно задать с помощью диаграмм последовательностей или диаграмм кооперации.

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

Модели прецедентов должны нарабатываться итеративно и параллельно с моделями классов. Классы, введенные в спецификации состояний, подлежат дальнейшей детальной проработке, при этом обозначаются наиболее важные операции. Следует, однако, напомнить, что спецификация состояний определяет только классы сущностей (“бизнес-объектов”).

По мере создания моделей поведения появляются еще два уровня классов.

1 Классы, которые обслуживают события, инициируемые пользователями, и представляют бизнес-процессы (управляющие классы).

2 Классы, представляющие графические интерфейсы (пограничные классы).