 |
Пример выполнения лабораторной работы
|
|
|
|
Создавать диаграммы взаимодействия будем для сценария "Добавить новый заказ" прецедента "Работа с заказом". В этом сценарии кроме основного потока существуют еще и альтернативные потоки. Хотя стандарт языка UML допускает ветвления на диаграммах последовательности, мы, чтобы не загромождать наши диаграммы, ограничимся рассмотрением только случая, когда пользователь правильно вводит свой пароль, правильно заполняет необходимые поля и введенные данные без ошибок сохраняются в базе данных. В случае необходимости альтернативные потоки можно показать на дополнительных диаграммах последовательности.
Построение любой диаграммы взаимодействия начинается с определения перечня объектов, которые будут участвовать во взаимодействии. Для выбранного сценария в лабораторной работе № 2 была разработана диаграмма классов. Экземпляры классов этой диаграммы и будут участниками диаграмм взаимодействия.
Создание диаграммы последовательности для сценария "Добавить новый заказ" прецедента "Работа с заказом"
Для создания диаграммы последовательностей в диалоговом окне Добавление новой схемы выберите Диаграмма последовательностей UML (рис. 4.2).
Рис. 4.2 Создание диаграммы последовательности
Построение диаграммы последовательности начинается с размещения на ней линий жизни объектов, которые будут обмениваться сообщениями. Сначала необходимо разместить линии, которые посылают сообщения, а потом линии, получающие их. Инициатором взаимодействия выступает Менеджер по работе с клиентами. Поэтому на диаграмме он будет находится в левом углу. Далее размещаем:
· линия жизни OrderOptions (Параметры работы с заказом), отвечающая за выбор возможного действия с заказом в рассматриваемом прецеденте;
|
|
|
· линия жизни AddNewOrder (Добавление нового заказа), отвечающая за добавление заказа;
· линия жизни OrderManager (Менеджер по работе с заказами), отвечающая за обработку потока событий рассматриваемого прецедента;
· линия жизни Order (Заказ);
· линия жизни Client (Клиент);
· линия жизни ComponentPart (Комплектующее изделие).
Теперь на диаграмме следует разместить сообщения, которыми будут обмениваться объекты (рис. 4.3):
| Номер сообщения | Объект - отправитель сообщения | Объект - получатель сообщения | Название |
| Менеджер по работе с клиентами | OrderOptions | ввод пароля | |
| OrderOptions | Менеджер по работе с клиентами | проверка пароля | |
| Менеджер по работе с клиентами | OrderOptions | выбор операции "добавить" | |
| OrderOptions | AddNewOrder | отображение полей ввода | |
| Менеджер по работе с клиентами | AddNewOrder | выбор типа компьютера | |
| AddNewOrder | OrderManager | получение списка клиентов | |
| OrderManager | Client | получение списка клиентов | |
| Client | OrderManager | список клиентов | |
| OrderManager | AddNewOrder | отображение списка клиентов | |
| Менеджер по работе с клиентами | AddNewOrder | выбор клиента | |
| AddNewOrder | OrderManager | получение списка комплектующих | |
| OrderManager | ComponentPart | получение списка комплектующих | |
| ComponentPart | OrderManager | список комплектующих | |
| OrderManager | AddNewOrder | отображение списка комплектующих | |
| Менеджер по работе с клиентами | AddNewOrder | выбор необходимых комплектующих | |
| Менеджер по работе с клиентами | AddNewOrder | сохранить заказ | |
| AddNewOrder | OrderManager | передача управления | |
| OrderManager | Order | сохранить |
Рис. 4.3 Итоговая диаграмма последовательности
Лабораторная работа № 5
Создание диаграммы состояний
5.1 Цель работы: получить навыки построения диаграмм состояний.
Теоретическое введение
Диаграммы состояний (state diagrams) являются хорошо известным средством описания поведения систем. Они определяют все возможные состояния, в которых может находиться конкретный объект, а также процесс смены состояний объекта в результате влияния некоторых событий.
|
|
|
На рис. 5.1 показана диаграмма состояний UML, отражающая поведение отчета в системе управления проектами. На диаграмме изображены различные состояния, в которых может находиться отчет.
Рис. 5.1 Диаграмма состояний
Процесс начинается с начальной точки, затем следует самый первый переход в состояние «Проверка даты отчета». В поведении объекта в системе можно выделить действия, отображаемые переходами, и деятельности, отображаемые состояниями. Хотя и то и другое – это процессы, реализуемые, как правило, некоторым методом класса «Отчет», они трактуются различным образом. Действия связаны с переходами и рассматриваются, как мгновенные и непрерываемые. Деятельности связаны с состояниями и могут длиться достаточно долго. Деятельность может быть прервана в результате наступления некоторого события.
Переход может содержать метку. Если метка перехода не содержит никакого события, это означает, что переход происходит, как только завершается какая-либо деятельность, связанная с данным состоянием.
Из состояния «Проверка даты отчета» возможны два перехода. Метка одного из них включает условие. Условие - это логическое условие, которое может принимать два значения: «истина» или «ложь». Условный переход выполняется только в том случае, если условие принимает значение «истина», в противном случае выполняется переход, не помеченный условием.
Из конкретного состояния в данный момент времени может быть осуществлен только один переход; таким образом, условия являются взаимно исключающими для любого события.
Существует два особых состояния: вход и выход. Любое действие, связанное с событием входа, выполняется, когда объект входит в данное состояние. Событие выхода выполняется в том случае, когда объект выходит из данного состояния.
Диаграммы состояний хорошо использовать для описания поведения некоторого объекта в нескольких различных вариантах использования. Они не слишком пригодны для описания поведения ряда взаимодействующих объектов.
|
|
|
Рекомендуется строить диаграммы состояний только для тех классов, поведение которых влияет на общее поведение системы, например для классов пользовательского интерфейса и управляющих объектов.
|
|
|
