Правила идентификации отношения агрегации

Вводить агрегацию следует в следующих случаях:

– время жизни компонента ограничено временем жизни составного объекта, т.е. есть зависимость создания/удаления (например, файл–каталог);

– в физическом или логическом агрегате очевидно наличие отношения «часть–целое» (например, машина–двигатель);

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

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

Порядок построения концептуальной модели

При построении концептуальной модели можно руководствоваться следующей последовательностью шагов:

1) составить список понятий;

2) идентифицировать их атрибуты;

3) идентифицировать ассоциации;

4) произвести разбиение на подтипы и выделение супертипов;

5) выделить отношения агрегации.

Эти шаги можно выполнять как для всей модели в целом, так и для ее частей.

Рекомендации по построению диаграмм понятий

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

Не стоит пытаться все вместить в одну диаграмму. Лучше разбить модель на несколько относительно независимых частей и построить несколько диаграмм. При этом некоторые части модели придется повторить на нескольких диаграммах – в этом нет ничего страшного. При разбиении имеет смысл придерживаться правила «7 ± 2». Именно такое количество понятий на диаграмме является оптимальным.

Каждая диаграмма должна акцентировать внимание на определенном аспекте системы. Для этого имеет смысл скрывать несущественные в данном контексте элементы модели (атрибуты, ассоциации, ограничения).

Располагайте понятия равномерно друг относительно друга. Линии отношений рисуйте параллельно осям координат. Не допускайте пересечения линий и излишних изломов (максимум 2). Некоторые аналитики совершенно напрасно пренебрегают эстетической стороной построения диаграмм. С моделями этих людей работать потом неприятно.

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

1. Что такое концептуальная модель?

2. Как выделять понятия и ассоциации?

3. Как правильно выделять атрибуты?

4. Для чего нужны роли?

5. В чем суть правил «100%» и «is_a»?

6. В чем особенность абстрактных понятий?

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

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

1. Подумайте, почему требуются два правила: «100%» и «is_a»? Почему не достаточно одного из них?

2. Подумайте, почему многомерная множественная классификация не используется в языках программирования?

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

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

Тема 6.5. Моделирование поведения системы и диаграмма последовательностей

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

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

1. Модель поведения системы, системные сообщения и системные операции.

2. Принцип черного ящика.

3. Диаграмма последовательностей.

4. Основные элементы диаграммы: объекты, линии жизни, сообщения, периоды активации.

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

6. Описание системных операций.

Модель поведения системы

Модель поведения системы завершает этап анализа. Данная модель строится в основном на базе модели прецедентов. Система в данном случае рассматривается как черный ящик. Основной целью построения модели поведения системы является определение системных операций и системных сообщений.

Определение. Системное сообщение – это входящее сообщение, сгенерированное актором для системы и переданное через ее границу.

Определение. Системная операция – это операция, выполняемая системой при получении системного сообщения.

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

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

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

Для построения диаграммы необходимо выделить из текста описания прецедента все генерируемые акторами сообщения и их параметры и отобразить их на диаграмме в порядке генерации. Таким образом, диаграмма последовательностей представляет собой формальное представление некоторого сценария прецедента. Пример диаграммы последовательностей для основного потока прецедента «Продажа товара» представлен на рис. 63.

Рис. 63. Диаграмма последовательностей для прецедента
«Продажа товара»

Основными элементами диаграммы последовательностей являются объекты (в т.ч. акторы) и сообщения.

Объекты

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

Рис. 64. Примеры объектов

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

У каждого объекта есть линия жизни, которая направлена сверху вниз. Линии жизни обычных объектов изображается при помощи тонкой или пунктирной линии. Для того чтобы подчеркнуть активную природу акторов, их линии жизни изображаются жирной линией. В UML также есть понятие активного объекта – объекта, владеющего потоком управления. Линии жизни активных объектов также изображаются при помощи жирных линий. Если объект уничтожается в ходе взаимодействия, то его линия жизни оканчивается крестом (рис. 65). В модели поведения системы данный элемент не используется.

Рис. 65. Линии жизни объектов

Сообщения

В языке UML определено следующих три типа сообщений: синхронные, асинхронные и ответные.

Определение. Синхронное сообщение – это сообщение, после отправки которого отправитель дожидается завершения его обработки.

Определение. Асинхронное сообщение – это сообщение, после отправки которого отправитель может выполнять другие действия, не дожидаясь завершения его обработки.

Определение. Ответное сообщение – это сообщение, уведомляющее отправителя о завершении обработки его сообщения. Может использоваться для передачи результата.

Синхронные сообщения обозначаются при помощи сплошной линии с закрашенным треугольником на конце, асинхронные – сплошной линией со стрелкой на конце, а ответные –пунктирной линией со стрелкой на конце (рис. 66).

Рис. 66. Типы сообщений

Каждое сообщение кроме ответных сообщений имеет имя и, при необходимости, параметры. Имена сообщений должны содержать глаголы в повелительном наклонении и отражать те действия, которые должны быть выполнены в ответ на сообщение (рис. 67).

Рис. 67. Имена и параметры сообщений

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

Рис. 68. Повторяющиеся сообщения

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

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

Рис. 69. Условные сообщения

Чаще всего условные сообщения встречаются в тех случаях, когда в зависимости от некоторого условия отправляется либо одно, либо другое (или одно из нескольких) сообщение. Такие сообщения называются альтернативными и изображаются на диаграмме при помощи условных сообщений, начала которых соединены (см. рис. 70).

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

Рис. 70. Альтернативные сообщения

Описание системных операций

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

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

В UML не определяется стандарта для описания системных операций. На практике рекомендуется использовать шаблон со следующими полями:

– имя – имя системной операции;

– обязанности – краткое описание того, за что отвечает данная системная операция;

– ссылки – прецеденты, в которых используется данная системная операция;

– примечание – комментарии, замечания о реализации и т.д.;

– исключения – возможные исключительные ситуации и реакции на них;

– предусловия – условия, которые должны быть выполнены перед началом операции;

– постусловия – описание изменений в системе, которые должны произойти после выполнения системной операции.

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

Рис. 71. Концептуальная модель продажи

Рассмотрим описание системных операций на примере операции «ввестиТоварнуюПозицию». Пусть данная операция используется в прецеденте «Продажа товара» для некоторой системы розничной торговли. На рис. 71 приведена часть концептуальной модели, которая понадобится для описания.

________________________________________________________________________________________________________________________________________

Имя: ввестиТоварнуюПозицию(код, количество)

Обязанности: Добавить товарную позицию к текущей продаже.

Ссылки: Прецедент «ПокупкаТовара»

Примечание: Использовать самый быстрый доступ к БД.

Исключения: Если код товара не известен, то запросить повторный ввод.

Предусловия: нет

Постусловия:

· Для новой продажи создан объект :Продажа (создание экземпляра).

· Для новой продажи объект :Продажа связан с объектом :СистРознТорговли (формирование связи).

· Создан объект :ТоварнаяПозиция (создание экземпляра).

· Объект :ТоварнаяПозиция связан с объектом:Продажа (формирование связи).

· Атрибут :ТоварнаяПозиция.Кол-во принял значение «количество» (модификация атрибута).

· Объект :ТоврнаяПозиция связан с объектом :ОписаниеТовара на основе соответствия кода товара (формирование связи).

________________________________________________________________________________________________________________________________________

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

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

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

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

1. В чем разница между системным сообщением и системной операцией? Что общего между ними?

2. В чем заключается принцип «черного ящика»?

3. Какие виды сообщений бывают и чем они различаются?

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

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

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

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

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

Рекомендации по построению диаграмм
последовательностей

При выборе имен системных сообщений используйте глаголы в повелительном наклонении, например: «создатьТоварнуюПозицию», «сохранитьДокумент», «получитьОстаток» и т.д.

Тема 6.6. Проектирование поведения системы и
диаграммы сотрудничества

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

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

1. Этап проектирования, основная цель этапа.

2. Два вида диаграмм взаимодействия: диаграммы последовательностей и диаграммы сотрудничества.

3. Диаграммы сотрудничества.

4. Понятия сотрудничества и взаимодействия.

5. Элементы диаграммы сотрудничества: объекты, связи, сообщения.

6. Работа со стандартными коллекциями.

7. Сообщения классам.

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

По завершении этапа анализа разработчик информационной системы должен получить ответ на вопрос «что надо сделать?» и иметь на руках следующий набор артефактов:

– модель прецедентов (описания прецедентов, диаграммы прецедентов);

– концептуальная модель (диаграммы понятий);

– модель поведения системы (диаграммы последовательностей, описания системных операций).

Следующим этапом является этап проектирования, на котором разрабатывается логическое решение задачи. Цель этапа проектирования – ответить на вопрос «как добиться требуемой функциональности системы?». Основными задачами данного этапа являются

– построение диаграмм взаимодействия,

– построение диаграмм классов.

Диаграммы взаимодействия

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

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

В UML определено два типа диаграмм взаимодействия: диаграмма последовательностей (SD – Sequence Diagram) и диаграмма сотрудничества (COD – Collaboration Diagram). Обе эти диаграммы одинаково выразительны, но делают акцент на различных аспектах взаимодействия.

Диаграммы последовательностей имеют выделенную ось времени и позволяют сосредоточить внимание на последовательности сообщений (рис. 72).

Рис. 72. Диаграмма последовательностей

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

Рис. 73. Диаграмма сотрудничества

На практике обычно отдается предпочтение диаграммам сотрудничества, т.к. они более компактны и явно определяют контекст взаимодействия, что на этапе проектирования немаловажно. Далее рассматриваются именно диаграммы сотрудничества.

Диаграмма сотрудничества

На диаграммах сотрудничества выделяют два аспекта – это сотрудничество и взаимодействие. Определим эти понятия.

Определение. Сотрудничество – это состав объектов взаимодействия и связи между ними.

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

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

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

Рис. 74. Пример неименованного и именованного объекта

В ходе взаимодействия объекты могут создаваться и уничтожаться. Созданные объекты помечаются как {new}, уничтоженные – {deleted}, а созданные и затем уничтоженные (временные) – {transient} (рис. 75).

Рис. 75. Пометка созданного объекта

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

Рис. 76. Пример связи

Допускается использование агрегации и ролей (рис. 77).

Для моделирования внешней среды используются акторы (рис. 78).

Рис. 77. Использование ролей и агрегации

Рис. 78. Моделирование внешней среды

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

Рис. 79. Отправка сообщений

Каждое сообщение имеет метку, которая включает как минимум имя сообщения и круглые скобки. Полный формат метки сообщения имеет следующий вид:

____________________________________________________________________

<Предшественники> / <Номер> [<Условие>]:
<Переменная>:= <Имя> (<Аргументы>)

____________________________________________________________________

Предшественники – это список номеров сообщений, обработка которых должна завершиться прежде, чем данное сообщение может быть послано. Если у сообщения есть предшественники, то после них ставится слэш. В примере на рис. 80 четыре класса обмениваются асинхронными сообщениями. Суть данного взаимодействия может сводиться, например, к следующему. По запросу пользователя объект класса А опрашивает состояние удаленных объектов б1 и б2, после чего результаты опроса сообщает объекту класса В. Соответственно, сообщение 3 может быть отправлено только после того, как объект класса А получит сообщения 1.1 и 1.2.

Рис. 80. Пример обмена асинхронными сообщениями

Номер сообщения определяет его положение в цепочке сообщений. Нумерация бывает плоской и иерархической. При плоской нумерации с каждым сообщением связывается натуральное число, определяющее абсолютный порядковый номер сообщения. Однако такую нумерацию неудобно использовать в случае с асинхронными сообщениями, т.к. в этом случае определить абсолютный порядковый номер бывает невозможно. В связи с этим на практике применяется иерархическая нумерация, при которой сообщению присваивается относительный номер «внутри» родительского сообщения – сообщения, в ходе обработки которого было сгенерировано данное. Например, сообщение сообщ_5 на рис. 80 было сгенерировано в ответ на сообщение сообщ_4 с номером 2 и, следовательно, имеет номер 2.1.

Для отображения параллельных сообщений к номеру сообщения дописывается буква, например, 3.1а и 3.1б. Это означает, что порядок отправки сообщений неважен (т.е. при наличии возможности их можно отсылать одновременно). Например, для сообщений сообщ_2 и сообщ_4 на рис. 80 порядок их отправки не важен, и диаграмму можно нарисовать так, как показано на рис. 81.

Рис. 81. Параллельные сообщения

Условие, как и на диаграммах последовательностей, определяет условие посылки сообщения, или итерацию, например, [продажа не создана] или *[для всех товарных позиций]. При помощи условий и параллельных сообщений можно организовать взаимоисключающие сообщения, например, 1a [условие] и 1б [not условие].

Переменная – это имя переменной, куда помещается результат обработки сообщения, например:

тп:= найтиТоварнуюПозицию(код)

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

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

Аргументы – это список параметров сообщения, заключенный в круглые скобки. Если сообщение не имеет параметров, то пишутся пустые скобочки.