Главная | Обратная связь | Поможем написать вашу работу!
МегаЛекции

Пример выполнения лабораторной работы




Создавать диаграммы взаимодействия будем для сценария "Добавить новый заказ" прецедента "Работа с заказом". В этом сценарии кроме основного потока существуют еще и альтернативные потоки. Хотя стандарт языка 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 Диаграмма состояний

 

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

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

Из состояния «Проверка даты отчета» возможны два перехода. Метка одного из них включает условие. Условие - это логическое условие, которое может принимать два значения: «истина» или «ложь». Условный переход выполняется только в том случае, если условие принимает значение «истина», в противном случае выполняется переход, не помеченный условием.

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

Существует два особых состояния: вход и выход. Любое действие, связанное с событием входа, выполняется, когда объект входит в данное состояние. Событие выхода выполняется в том случае, когда объект выходит из данного состояния.

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

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

Поделиться:





Воспользуйтесь поиском по сайту:



©2015 - 2024 megalektsii.ru Все авторские права принадлежат авторам лекционных материалов. Обратная связь с нами...