Open Library - открытая библиотека учебной информации

Открытая библиотека для школьников и студентов. Лекции, конспекты и учебные материалы по всем научным направлениям.

Категории

Дом Спецификация поведения
просмотров - 276

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


Читайте также


  • - Спецификация поведения задачи

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