2.8.2Использование диаграмм взаимодействия

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

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

Диаграммы последовательности и кооперации позволяют определить:

1. Классы, которые нужно создать.

2. Отношения между классами.

3. Операции каждого класса.

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

1. Объекты и сообщения. С помощью сообщения один объект запрашивает у другого выполнения какой-то конкретной функции. Например, напечатать отчёт.

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

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

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

2.8.3Диаграмма последовательности – Sequence diagram

Диаграмма последовательности – упорядоченная во времени диаграмма взаимодействия, читать её следует сверху вниз.

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

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

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

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

Сообщения транслируются в вызовы операций классов.

П ример:

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

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

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

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. Сообщение посылается нерегулярно. Оно может быть отправлено только один раз или несколько раз, но через разные промежутки времени.

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