Выявление агрегаций и композиций

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

При объяснении отношения агрегации лакмусовой бумажкойвыступают фразы «включает» («has») и «является частью» («is_part_of»).

При истолковании отношения сверху-вниз по иерархии классовиспользуется фраза «включает» (например, Книга «включает» Главу). Приинтерпретации снизу-вверх используется фраза «является частью»(например, Глава «является частью» Книги). Если предложение,описывающее отношение, прочитывается вслух с использованием этихфраз и оно лишено смысла на естественном языке, то это отношение неявляется агрегацией. Со структурной точки зрения агрегация частосвязывает воедино большое количество классов, тогда как ассоциациястепени выше двух бессмысленна. Когда требуется связать более двухклассов воедино, отличным вариантом моделирования может бытьагрегация типа Участник.

Спецификация агрегаций и композиций

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

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

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

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

Пример спецификации агрегации и композиции

Обратимся к системе Записи на университетские курсы.

Рассмотрим следующие дополнительные требования:

1. Академическая характеристика студента должна быть доступна потребованию. Характеристика должна включать информацию обоценках, полученных студентом по каждому из курсов, на которыезаписался студент (и которые он не покинул без взыскания, т. е.первые три недели с начала семестра).

2. За каждый курс отвечает преподаватель, однако этот курс могутвести и другие преподаватели. В течение разных семестров за одинкурс могут отвечать разные преподаватели; кроме того, в течениеразных семестров курс могут вести разные преподаватели.

На рисунке 2 показана модель классов, в которой выделено отношение

агрегации.

Понятие «студент» (объект Student) «включает» академическуюхарактеристику (объект AcademicRecord) — это описание композиции вязыке UML (с семантикой «по значению»). Каждый объектAcademicRecord физически помещен в один из объектов Student. Несмотряна существование ассоциации takes (брать [курс обучения]) объектAcademicRecord включает атрибут course_code (код курса).

Это необходимо, поскольку ассоциация takes реализуется спомощью атрибута takes_crsoff («берет» дисциплину) объекта Student,введенного как коллекция (collection), например, Set[CourseOffering].

Атрибут takes_crsoff не зависит от информации во вложенном объектеAcademicRecord, хотя он безусловно связывает объект Student с объектомCourse.

Понятие «курс» (объект Course) включает дисциплину (объектCourseOffering)» — это описание агрегации в языке UML (с семантикой«по ссылке»). Каждый объект CourseOffering только логическисодержится в одном из объектов Course. Объект CourseOffering можеттакже участвовать в других агрегациях и/или ассоциациях (например, собъектами Student и AcademicInCharge (ответственный преподаватель)).

Рисунок – 2 Модель классов с отношениями агрегации и композиции

Выявление обобщений

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

Различные ассоциации (даже принадлежащие одному и тому жеклассу) может потребоваться связать с классом на различных уровняхобобщения/специализации. Например, класс Course может быть связан склассом Student (StudenttakesCourse — студент берет курс), кроме того,этот класс может быть связан с классом TeachingAssistant(TeachingAssistantteachesCourse — ассистент ведет курс). Дальнейшийанализ может показать, что класс TeachingAssistant является подклассомStudent.

При поиске отношения обобщения лакмусовой бумажкой выступаютфразы «может быть» («can_be») и «это нечто вроде» («is_a_kind_of»). Приистолковании отношения сверху-вниз по иерархии классов используетсяфраза «может быть» (например, Student «can_be» a TeachingAssistant - «студент «может быть» ассистентом»). При интерпретации отношенияснизу-вверх используется фраза «это нечто вроде» (например,TeachingAssistant «is_a_kind_of» Student — «ассистент «это нечто вроде»студента»). Обратите внимание, что если также справедливо утверждениео том, что «ассистент - это «TeachingAssistant «is_a_kind_of» Teacher», томы установили множественное наследование.

Спецификация обобщений

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

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

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

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

Поведение системы – так как оно выглядит для внешнегопользователя – изображается в вид прецедентов. Модели прецедентовможно разрабатывать на различных уровнях абстракции. Их можноприменить к системе в целом для того, чтобы специфицировать основныефункциональные блоки разрабатываемого приложения. Их также можноиспользовать для фиксации поведения пакетов UML, частей пакетов илидаже класса внутри пакета.

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

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

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

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

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

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

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

Выявление прецедентов

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

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

2. Фрагмент внешне наблюдаемых функций (отличных отвнутренних функций).

3. Ортогональный фрагмент функциональных возможностей(прецеденты могут при выполнении совместно использоватьобъекты, но выполнение каждого прецедента независимо от другихпрецедентов).

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

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

Выявление прецедентов основано на анализе следующих источников информации:

1. Требования, определенные в документе описания требований.

2. Субъекты и их цели применительно к системе.

Требования представляются в отпечатанном виде.

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

Ответы на эти вопросы могут позволить обозначить прецеденты.

1. Каковы основные задачи, выполняемые каждым субъектом?

2. Должен ли субъект получать доступ к информации всистеме или модифицировать информацию?

3. Должен ли субъект информировать систему о любыхизменениях в других системах?

4. Должен ли субъект быть проинформирован онепредвиденных изменениях в системе?

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

Системные прецеденты извлекают все то общее, что присутствует впрецедентах субъектов, и дают возможность разработать общее решение,применимое (через механизм наследования) к области прецедентовсубъектов. «Субъектом» системного прецедента являетсяразработчик/программист, а не пользователь. Системные прецедентыидентифицируются на этапе проектирования.

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

Спецификация прецедентов включает графическое представлениесубъектов, прецедентов и четырех типов отношений, перечисленныхниже:

1. Ассоциация.

2. Включение.

3. Расширение.

4. Обобщение прецедента.

Отношение ассоциации устанавливает каналы связи междусубъектом и прецедентом. В качестве стереотипов для отношений«включает» (include) и «расширяет» (extend) используются слова «include» и «extend». Отношение обобщения позволяетспециализировать прецедент посредством изменения любого из аспектовбазового прецедента.

Отношение включения «include» позволяет вынести общееповедение за пределы включаемого прецедента. (Это отношение пришлона смену широко применяемой в более ранних версиях UML концепцииотношения «uses» (использует)). Отношение «extend» обеспечивает контролируемую форму расширения поведения прецедента с помощьюактивизации другого прецедента в определенных точках расширения.

Отношение «include» отличается от отношения «extend» в том, что«включаемый» прецедент является необходимым для завершения«активизирующего» прецедента.

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