Практическая работа 1213 Построение диаграмм состояний на языке uml с помощью ms visio
 Скачать 3.46 Mb.
|
|
3 СОДЕРЖАНИЕ Практическая работа №12-13 Построение диаграмм состояний на языке UML с помощью MS Visio ...... 4 Практическая работа №14-15 Построение диаграмм деятельности на языке UML с помощью MS Visio ..................................................................................................................................................................... 14 Практическая работа №16-17 Построение диаграмм последовательностей на языке UML с помощью MS Visio ..................................................................................................................................................................... 24 Практическая работа №18 Разработка диаграмм прецедентов с помощью Visual Paradigm for UML ...... 29 Практическая работа №19 Разработка диаграмм классов с помощью Visual Paradigm for UML .............. 37 Практическая работа №20 Разработка диаграмм состояний с помощью Visual Paradigm for UML .......... 51 Практическая работа №21 Разработка диаграмм деятельности с помощью Visual Paradigm for UML ..... 64 Практическая работа №22 Разработка диаграмм последовательности с помощью Visual Paradigm for UML ..................................................................................................................................................................... 76 Документ подписан простой электронной подписью Информация о владельце: ФИО: Пономарева Светлана Викторовна Должность: Проректор по УР и НО Дата подписания: 03.08.2022 23:09:38 Уникальный программный ключ: bb52f959411e64617366ef2977b97e87139b1a2d 4 Практическая работа №12-13 Построение диаграмм состояний на языке UML с помощью MS Visio Цель: изучение основ создания диаграмм состояний на языке UML, получение навыков построения диаграмм состояний, применение приобретенных навыков для построения объектно-ориентированных моделей определенной предметной области. 1 Задачи Основными задачами практической работы являются: ‒ ознакомиться с теоретическими вопросами построения диаграмм состояний на языке UML; ‒ ознакомиться с теоретическими вопросами построения диаграмм состояний с помощью MS Visio. 2 Краткие теоретические сведения Диаграмма состояний описывает процесс изменения состояний только одного класса, а точнее – одного экземпляра определенного класса, т. е. моделирует все возможные изменения в состоянии конкретного объекта. При этом изменение состояния объекта может быть вызвано внешними воздействиями со стороны других объектов или извне. Именно для описания реакции объекта на подобные внешние воздействия и используются диаграммы состояний. Диаграмма состояний описывает возможные последовательности состояний и переходов, которые в совокупности характеризуют поведение элемента модели в течение его жизненного цикла. Диаграмма состояний представляет динамическое поведение сущностей, на основе спецификации их реакции на восприятие некоторых конкретных событий. Хотя диаграммы состояний чаще всего используются для описания поведения отдельных экземпляров классов (объектов), но они также могут быть применены для спецификации функциональности других компонентов моделей, таких как варианты использования, актеры, подсистемы, операции и методы. Диаграмма состояний по существу является графом специального вида, который представляет некоторый автомат. Понятие автомата в контексте UML обладает довольно специфической семантикой, основанной на теории автоматов. Вершинами этого графа являются состояния и некоторые другие типы элементов автомата (псевдосостояния), которые изображаются соответствующими графическими символами. Дуги графа служат для обозначения переходов из состояния в состояние. Диаграммы состояний могут быть вложены друг в друга, образуя вложенные диаграммы более детального представления отдельных элементов модели. Рисунок 1 – Пример диаграммы состояний для технического устройства типа «Компьютер» Состояние Под состоянием понимается абстрактный метакласс, используемый для моделирования отдельной ситуации, в течение которой имеет место выполнение некоторого условия. Состояние может быть задано в виде набора конкретных значений атрибутов класса или объекта, при этом изменение их отдельных значений будет отражать изменение состояния моделируемого класса или объекта. Рисунок 2 – Графическое обозначение состояния 5 Секция «Список внутренних действий» содержит перечень внутренних действий или деятельностей, которые выполняются в процессе нахождения моделируемого элемента в данном состоянии. Каждое из действий записывается в виде отдельной строки и имеет следующий формат: <метка-действия '/' выражение-действия> Метка действия указывает на обстоятельства или условия, при которых будет выполняться деятельность, определенная выражением действия: ‒ entry – эта метка указывает на действие, специфицированное следующим за ней выражением действия, которое выполняется в момент входа в данное состояние (входное действие); ‒ exit – эта метка указывает на действие, специфицированное следующим за ней выражением действия, которое выполняется в момент выхода из данного состояния (выходное действие); ‒ do – эта метка специфицирует выполняющуюся деятельность («doactivity»), которая выполняется в течение всего времени, пока объект находится в данном состоянии, или до тех пор, пока не закончится вычисление, специфицированное следующим за ней выражением действия. В последнем случае при завершении события генерируется соответствующий результат; ‒ include – эта метка используется для обращения к подавтомату, при этом следующее за ней выражение действия содержит имя этого подавтомата. Пример: Аутентификация входа Рисунок 3 – Состояние для ввода пароля Начальное и конечное состояния Начальное состояние представляет собой частный случай состояния, которое не содержит никаких внутренних действий (псевдосостояния). В этом состоянии находится объект по умолчанию в начальный момент времени. Оно служит для указания на диаграмме состояний графической области, от которой начинается процесс изменения состояний. Конечное (финальное) состояние представляет собой частный случай состояния, которое также не содержит никаких внутренних действий (псевдосостояния). В этом состоянии будет находиться объект по умолчанию после завершения работы автомата в конечный момент времени. Рисунок 4 – Графическое изображение начального и конечного состояний Переход Простой переход (simpletransition) представляет собой отношение между двумя последовательными состояниями, которое указывает на факт смены одного состояния другим. Пребывание моделируемого объекта в первом состоянии может сопровождаться выполнением некоторых действий, а переход во второе состояние будет возможен после завершения этих действий, а также после удовлетворения некоторых дополнительных условий. В этом случае говорят, что переход срабатывает, Или происходит срабатывание перехода. До срабатывания перехода объект находится в предыдущем от него состоянии, называемым исходным состоянием, или в источнике (не путать с начальным состоянием – это разные понятия), а после его срабатывания объект находится в последующем от него состоянии (целевом состоянии). Переход осуществляется при наступлении некоторого события: окончания выполнения деятельности (doactivity), получении объектом сообщения или приемом сигнала. На переходе указывается имя события. Кроме того, на переходе могут указываться действия, производимые объектом в ответ на внешние события при переходе из одного состояния в другое. Срабатывание перехода может зависеть не 6 только от наступления некоторого события, но и от выполнения определенного условия, называемого сторожевым условием. Объект перейдет из одного состояния в другое в том случае, если произошло указанное событие и сторожевое условие приняло значение «истина». На диаграмме состояний переход изображается сплошной линией со стрелкой, которая направлена в целевое состояние. Каждый переход может помечен строкой текста, которая имеет следующий общий формат: <сигнатура события>'['<сторожевое условие>']' <выражение действия> Событие Событие представляет собой спецификацию некоторого факта, имеющего место в пространстве и во времени. Про события говорят, что они «происходят», при этом отдельные события должны быть упорядочены во времени. После наступления некоторого события нельзя уже вернуться к предыдущим событиям, если такая возможность не предусмотрена явно в модели. События играют роль стимулов, которые инициируют переходы из одних состояний в другие. В качестве событий можно рассматривать сигналы, вызовы, окончание фиксированных промежутков времени или моменты окончания выполнения определенных действий. Имя события идентифицирует каждый отдельный переход на диаграмме состояний и может содержать строку текста, начинающуюся со строчной буквы. Сторожевое условие Сторожевое условие (guardcondition), если оно есть, всегда записывается в прямых скобках после события и представляет собой некоторое булевское выражение. Если сторожевое условие принимает значение «истина», то соответствующий переход может сработать, в результате чего объект перейдет в целевое состояние. Если же сторожевое условие принимает значение «ложь», то переход не может сработать, и при отсутствии других переходов объект не может перейти в целевое состояние по этому переходу. Однако вычисление истинности сторожевого условия происходит только после возникновения ассоциированного с ним события, инициирующего соответствующий переход. В общем случае из одного состояния может быть несколько переходов с одним и тем же событием- триггером. При этом никакие два сторожевых условия не должны одновременно принимать значение «истина». Каждое из сторожевых условий необходимо вычислять всякий раз при наступлении соответствующего события. Пример Рисунок 5 – Диаграмма состояний для моделирования почтовой программы клиента Составное состояние и подсостояние Составное состояние (compositestate) – такое сложное состояние, которое состоит из других вложенных в него состояний. Последние будут выступать по отношению к первому как подсостояния (substate). 7 Рисунок 6 – Графическое изображение составного состояния Последовательные подсостояния (sequential substates) используются для моделирования такого поведения объекта, во время которого в каждый момент времени объект может находиться в одном и только одном подсостояний. Поведение объекта в этом случае представляет собой последовательную смену подсостояний, начиная от начального и заканчивая конечным подсостояниями. Хотя объект продолжает находиться в составном состоянии, введение в рассмотрение последовательных подсостояний позволяет учесть более тонкие логические аспекты его внутреннего поведения. Рисунок 7 – Пример составного состояния с двумя вложенными последовательными подсостояниями Параллельные подсостояния (concurrentsubstates) позволяют специфицировать два и более подавтомата, которые могут выполняться параллельно внутри составного события. Каждый из подавтоматов занимает некоторую область (регион) внутри составного состояния, которая отделяется от остальных горизонтальной пунктирной линией. Если на диаграмме состояний имеется составное состояние с вложенными параллельными подсостояниями, то объект может одновременно находиться в каждом из этих подсостояний. 8 Рисунок 8 – Графическое изображение составного состояния с вложенными параллельными подсостояниями Синхронизирующие состояния Поведение параллельных подавтоматов независимо друг от друга, что позволяет реализовать многозадачность в программных системах. Однако в отдельных случаях может возникнуть необходимость учесть в модели синхронизацию наступления отдельных событий. Для этой цели в языке UML имеется специальное псевдосостояние, которое называется синхронизирующим состоянием. Синхронизирующее состояние (synch state) обозначается небольшой окружностью, внутри которой помещен символ звездочки "*". Оно используется совместно с переходом-соединением или переходом- ветвлением для того, чтобы явно указать события в других подавтоматах, оказывающие непосредственное влияние на поведение данного подавтомата. Для иллюстрации использования синхронизирующих состояний рассмотрим упрощенную ситуацию с моделированием процесса постройки дома. Предположим, что постройка дома включает в себя строительные работы (возведение фундамента и стен, возведение крыши и отделочные работы) и работы по электрификации дома (подведение электрической линии, прокладка скрытой электропроводки и установка осветительных ламп). Очевидно, два этих комплекса работ могут выполняться параллельно, однако между ними есть некоторая взаимосвязь. В частности, прокладка скрытой электропроводки может начаться лишь после того, как будет завершено возведение фундамента и стен. А отделочные работы следует начать лишь после того, как будет закончена прокладка скрытой электропроводки. В противном случае отделочные работы придется проводить повторно. Рассмотренные особенности синхронизации этих параллельных процессов учтены на соответствующей диаграмме состояний с помощью двух синхронизирующих состояний. Рисунок 9 – Диаграмма состояний для примера со строительством дома Примеры диаграмм состояний изображены на рисунках 10-12. 9 Рисунок 10 – Диаграмма состояний для моделирования запроса данных из БД Рисунок 11 – Диаграмма состояний для моделирования поведения банкомата 10 Рисунок 12 – Диаграмма состояний моделирования деятельности сотрудника банка 3 Методика выполнения В качестве примера рассматривается моделирование системы продажи товаров по каталогу. 1. Запустите MS Visio. 2. На экране выбора шаблона выберите категорию Программы и БД и в ней элемент Схема модели UML. Нажмите кнопку Создать в правой части экрана. 3. Окно программы примет вид, подобный рис. 13. Рисунок 13 – Окно MS Visio для работы с диаграммами состояний Клиент оформляет заказ. Класс Заказ имеет атрибут Статус. Проследим динамику движения заказов в системе с помощью диаграммы состояний, составленной для класса Заказ. 11 Данные о сформированном заказе поступают продавцу, который проверяет наличие товаров из заказа, проверяет оплату заказа, комплектует его и делает отметку о готовности. После оплаты заказа он выдается клиенту. Продавец делает отметку о том, что заказ выдан. Если после проверки кредитного рейтинга клиента, он окажется отрицательным, то заказ будет отклонен. Построим диаграмму состояний для класса Заказ. Для этого, в файле с диаграммой классов, созданной в практическом занятии 8, необходимо проделать следующие действия: 1. Щелкнуть правой кнопкой мыши по классу Заказ. 2. В контекстном меню выбрать пункт Схемы. 3. Т.к. в настоящее время уже созданных схем нет, нажать кнопку Создать и выбрать Схема состояний. 4. Переименовать созданный лист в Схема состояний-Заказ. 5. Построить диаграмму состояний для класса Заказ в соответствии с рисунком 14. После формирования заказа он должен быть оплачен. Обработка заказа подразумевает проверку наличия товара и проверку оплаты. Переход в одно из состояний На комплектации, Укомплектован, Выдан означает смену Статуса заказа. Рисунок 14 – Диаграмма состояний для класса Заказ Далее опишем с помощью диаграммы состояний процесс оплаты заказа клиентом, которому соответствует класс ЗаказОплата. Построим диаграмму состояний для проверки оплаты заказа. Чтобы проверить оплату заказа, необходимо определить, существует ли сам заказ. Результатом проверки оплаты заказа является вывод либо сообщения о произведенной оплате с параметрами (дата оплаты), либо сообщения об ожидании оплаты. Событием, предшествующим проверке оплаты заказа, является занесение информации о заказе в базу данных заказов. Чтобы построить диаграмму состояний для класса ЗаказОплаты, необходимо проделать действия, описанные в пунктах 1-4 построения диаграммы состояний для класса Заказ. Полученная диаграмма должна иметь вид, изображенный на рис. 15. 12 Рисунок 15 – Диаграмма состояний проверки платы заказа На этой диаграмме есть составное состояние «Проверить оплату заказа», т.к. оно включает в себя проверку кредитного рейтинга клиента и проверку выбора варианта оплаты клиентом. Оплату заказа может произвести только клиент с положительным кредитным рейтингом, поэтому необходимым условием проверки оплаты заказа является проверка кредитоспособности клиента. Если клиент имеет отрицательный кредитный рейтинг, то заказ отклоняется, и на этом дальнейшие события не имеют смысла. Если кредитный рейтинг клиента положительный, то необходимо проверить, выбрал ли клиент вариант оплаты. Событие, которое переводит систему в состояние ожидания выбора варианта оплаты клиентом, является получение сообщения о кредитоспособности клиента. Оплата может быть произведена наличными средствами в магазине или с помощью безналичного расчета. В первом случае необходимо договориться с клиентом о дате и времени его прибытия в магазин. Во втором случае необходимо сообщить клиенту о наличии/поступлении товара. Событие, которое переводит систему в состояние ожидания оплаты, является выбор клиентом варианта оплаты. Соответствующие диаграммы состояний имеют вид (рис. 16 и рис. 17). Для создания диаграмм состояний, которые входят в состав составного состояния, нужно: 1. Щелкнуть правой кнопкой мыши по Составному состоянию и выбрать пункт Схема. 2. Либо, в Проводнике по моделям выделить название составного состояния и создать новую страницу с помощью кнопки Рисунок 16 – Диаграмма состояний для проверки кредитного рейтинга клиента 13 Рисунок 17 – Диаграмма состояний для проверки варианта оплаты |