Подход к разработке диаграммы последовательности

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

1.
Отображается информация высокого уровня, которая нужна пользователям проектируемой информационной системы. Сообщения никак не соотносятся с операциями, и объекты не соотносятся с классами. Это необходимо для согласования бизнес-логики с пользователями. Данный шаг проектирования может проводиться во время моделирования предметной области в представлении Use Case View.

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

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

Все диаграммы последовательности для одного варианта использования имеют один и тот же управляющий объект. Он не реализует никаких бизнес-процессов. Он только посылает сообщения другим объектам (делегирует сообщения). Такие объекты называют объектами-менеджерами (Manager Object).

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

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

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

Вариант 1. Логика приложения не отделена от логики базы данных (объект сам знает о базе данных).

Вариант 2. Логика приложения отделена от логики базы данных (в этом случае нужно создать специальный объект Менеджер транзакций – Transaction manager).

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

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

3. После создания всех объектов необходимо соотнести их с классами. Объекты можно связать с существующими классами или создать новые. К моменту генерации кода все объекты должны быть соотнесены с классами.

4. Задать устойчивость классов. В среде Rose для каждого класса можно задать его устойчивость (Persistence). Для назначения устойчивости следует в спецификации класса установить переключатель Persistence в одно из следующих положений:

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

- Static. Статичный объект сохраняется в памяти компьютера в течение всего времени работы программы. Он сохраняется после выполнения отображённых на диаграмме последовательности действий, но не сохраняется после прекращения работы программы.

- Transient. Временный объект сохраняется в памяти в течение очень короткого времени. Например, только на время процессов, определённых в диаграмме последовательности.

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

6. Существует возможность синхронизации посылаемых сообщений (операций). Это можно сделать в окне спецификации сообщения на вкладке Detail. Поддерживаются следующие варианты синхронизации:

- Simple. Простое сообщение используется по умолчанию. Означает, что все сообщения выполняются в одном потоке управления.

- Synchronous. Синхронное сообщение применяется, когда клиент посылает сообщение и ждёт ответа пользователя.

- Balking. С отказом становится в очередь. Клиент посылает сообщение серверу. Если сервер не может немедленно принять сообщение, оно отменяется.

- Timeout. С лимитированным временем ожидания. Клиент посылает сообщение серверу, а затем ждёт указанное время. Если в течение этого времени сервер не принимает сообщение, оно отменяется.

- Asynchronous. Асинхронное сообщение клиент посылает серверу и продолжает свою работу, не ожидая подтверждения о получении.

На той же вкладке Detail можно установить частоту сообщений:

- Periodic. Периодическое сообщение регулярно посылается через определённые промежутки времени (например, каждые 30 с).

- Aperiodic. Сообщение посылается нерегулярно. Оно может быть отправлено только один раз или несколько раз, но через разные промежутки времени.

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

2.8.5 Диаграмма кооперации – Collaboration Diagram

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

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

Rational Rose автоматически преобразует одну диаграмму в другую (клавиша <F5>), так что достаточно создать какую-нибудь одну из них.

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

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

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

Ещё одно важное пояснение. Инициировать сообщения могут только актёры (живые люди, устройства, другие системы, время) или управляющие объекты. Это требование соответствует трёхуровневому стилю архитектуры (пользовательский интерфейс, бизнес-логика и уровень данных).

2.9 ДИАГРАММЫ КЛАССОВ – CLASS DIAGRAMS

Диаграммы классов занимают центральное место в разработке логической модели системы. В этой главе рассматриваются:

1. Классы.

2. Стереотип класса.

3. Видимость класса.

4. Пакеты.

5. Диаграммы классов.

6. Создание диаграммы классов.

Дата добавления: 2014-01-07