Практикум для выполнения лабораторных работ состоит из семнадцати лабораторных работ по дисциплинам Спецификация, архитектура и проектирование программных систем
 Скачать 2.9 Mb.
|
|
Отношения Связи и взаимоотношения, существующие между эле- ментами модели, в UML описываются с помощью отношений, изображаемых на диаграммах. Отношение (relationship) — это семантическая связь между отдельными элементами модели. Между актерами и прецедентами диаграммы вариантов использования могут существовать отношения, показываю- щие, что экземпляры действующих лиц и вариантов использо- вания взаимодействуют друг с другом. 111 Действующие лица могут находиться в отношениях с не- сколькими прецедентами и между собой, равно как и прецеденты могут быть связаны между собой отношениями особого рода. Всего на диаграммах вариантов использования допусти- мыми являются следующие типы отношений: – обобщения (generalization relationship) — отношение меж- ду двумя актерами, либо двумя вариантами использования; – ассоциации (association relationship) — отношение меж- ду актером и вариантом использования; – включения (include relationship) — отношения между вариантами использования; – расширения (extend relationship) — отношения между вариантами использования. Ассоциация — это структурное отношение, показывающее, что объект неким образом связан с другим объектом. Отношение этого типа используется не только на диаграммах прецедентов, но и на других диаграммах. Ассоциативное отношение может быть направленным. В этом случае направление связи показыва- ет, кто является инициатором (актер или разрабатываемая си- стема). Например, если отношение направленно от актера к прецеденту, это означает, что актер инициирует выполнение прецедента. Обобщение(Generalization) — это отношение между об- щей сущностью и ее конкретным воплощением. На диаграммах обобщение обозначается стрелкой с не закрашенным тре- угольником на конце, направленной от частного элемента к общему. По смыслу это отношение очень похоже на отношение «является родителем» в ООП. Отношения включения и расширения связаны с допол- нительной информацией, сопутствующей диаграмме вариан- тов использования. Для более подробного (больше, чем имя) описания эле- ментов модели можно использовать следующие подходы: – краткое текстовое описание (в поле Documentation); – связанные диаграммы (контекстное меню Add diagram) — диаграммы, более подробно описывающие кон- кретный элемент модели (например, алгоритм действий в конкретном варианте использования); – вложения (Attachments) — прикреплённые документы (например, *.docx содержащие подробные описания). 112 Для описания элементов диаграммы вариантов исполь- зования часто используют: – связанные диаграммы последовательностей и коопе- раций; – вложенные документы — сценарии использования. Сценарии применяются для текстового описания потоков событий. Поток событий — это определенная последователь- ность действий, которая описывает действия актеров и пове- дение моделируемой системы в форме текста. Обычно потоки событий записываются в виде пронуме- рованной последовательности действий на естественном языке (хотя иногда применяют и псевдокод). Каждый сценарий состоит из описания основного потока событий, его вариантов и исключительного потока. Основной поток событий описывает ожидаемый вариант происходящих событий (например, все данные оказались пра- вильными, файлы были найдены, места на сервере хватило). Альтернативные потоки описывают различные вариан- ты отклонения от обычного потока (например, выборка списка товара по дате, а не виду) или необязательные шаги (выбор цвета товара дополнительно к цене). Исключительный поток показывает поведение системы в случае возникновения ошибок. Если описание потока событий занимает много места, оно теряет выразительность. В таких случаях применяют сле- дующие приёмы. Если часть потока событий повторяется в нескольких ва- риантах использования, эту часть выносят в отдельный вариант использования. Прецеденты, из которых удалили эту часть, соединяют с новым вариантом использования отношением «включает». В описании включающих прецедентов указывает- ся, что часть потока находится в другом прецеденте. Необязательные этапы потока событий можно вынести в отдельный прецедент. Тогда этот новый прецедент будет «расширять» оригинальный. В описании оригинального пото- ка указывается точка расширения — место в котором могут «подцепляться» прецеденты для расширения, а в расширяю- щих прецедентах указывается к какой именно точке расшире- ния они относятся. 113 Ход работы Для того, чтобы перейти к созданию диаграммы вари- антов использования разверните папку Use Case View и от- кройте диаграмму Main с помощью двойного щелчка. Обратите внимание, что панель инструментов теперь содер- жит инструменты для создания диаграммы вариантов ис- пользования (рис. 11.5): − Actor — создание новых актеров; − Association и Directed Association — создание ассоциа- ций и направленных ассоциаций; − Generalization — обобщение; − Include и Extend — включение (направлено от включа- ющего к включаемому) и расширение (направлено от расши- ряющего к расширяемому); − System Boundary — указание границ системы. Рис. 11.5. Панель инструментов для работы с Use Case диаграммой Пример диаграммы вариантов использования приведён на рис. 11.6. 114 Рис. 11.6. Диаграмма вариантов использования «АРМ Преподавателя» Фрагмент сценария к варианту использования «Работа с графиком лабораторных работ». 1. Пользователь выбирает дисциплину. 2. Система показывает график выдачи и срока сдачи всех лабораторных работ по выбранному предмету. 3. Точка расширения «Работа с лабораторными работами». 4. Пользователь нажимает «вернуться назад». 5. Система показывает экран работы с дисциплиной. 6. Варианты использования «Перенос срока сдачи лабо- раторных работ» и «Выдача лабораторных работ» расширяют этот вариант использования в точке «Работа с лабораторными работами», что должно быть указано в их сценарии. 7. Точка расширения «Работа с лабораторными работами». 8. Сроки выдачи и сдачи лабораторных работ показаны в виде прямоугольников на оси времени. 9. Пользователь перетягивает один из углов прямо- угольника, изображающего срок сдачи работы. 10. Срок сдачи лабораторной работы изменяется на графике. System Препод аватель Работа с графиком лабораторных работ Отмечание успеваемости Лектор Руковод итель Ассистент АС "Д еканат" Указание тем РГР, курсовых работ и проектов Отмечание посещения лекций Отмечание посещения лаб.работ Загрузка списков групп Созд ание лабораторных работ Созд ание РГР, курсовых работ и проектов Построенте отчётов успеваемости и посещаемости Выд ача лабораторных работ Перенос срока сд ачи лабораторных работ < < 11. Система показывает экран работы с дисциплиной. 12. Пользователь выбирает пункт «График лабораторных работ». Индивидуальные задания Выполнить задание в соответствии с темой исследова- ния. В отчёт должны входить: – одна или несколько диаграмм вариантов использова- ния по индивидуальной теме; – сценарии двух или трёх вариантов использования в ви- де текстового описания или псевдокода (основной, альтерна- тивные и исключительные потоки событий); – 2– 3 актеров; – 8– 10 вариантов использования; – желательно использование отношений включения, расширения, обобщения. Контрольные вопросы 1. Что называют Визуальным моделированием? 2. Что такое модель? 3. Перечислите основные диаграммы UML. 4. Что такое StarUML? 5. Для чего применяются диаграммы использования? 116 Лабораторная работа 12. UML. Диаграмма последовательности Цель работы Применить диаграмму последовательности для описания разрабатываемой системы. Ознакомиться с инструментами, позволяющими строить диаграммы последовательности. Теоретические сведения Одной из характерных особенностей систем различной природы и назначения является взаимодействие между собой отдельных элементов, из которых образованы эти системы. Различные составные элементы систем не существуют изолированно, а оказывают определенное влияние друг на друга, что и отличает систему как целостное образование от простой совокупности элементов. В языке UML взаимодействие элементов рассматривается в информационном аспекте их коммуникации, т. е. взаимодей- ствующие объекты обмениваются между собой некоторой информацией. При этом информация принимает форму закон- ченных сообщений. Хотя сообщение и имеет информационное содержание, оно приобретает дополнительное свойство оказывать направ- ленное влияние на своего получателя. Это хорошо согласуется с распространённым взглядом на ООП, когда любые виды информационного взаимодействия между элементами систе- мы сведётся к отправке и приему сообщений между ними. Диаграмма последовательности — это диаграмма взаи- модействия, которая выделяет упорядочение сообщений по времени. Ход работы Создание диаграммы последовательности в StarUML Для того, чтобы добавить диаграмму последовательно- сти, воспользуйтесь пунктом добавить диаграмму контекстно- го меню логического представления в навигаторе модели. 117 Основные элементы диаграммы последовательности Основными элементами последовательностей являются объекты с линиями жизни и сообщения (рис. 12.1). Рис. 12.1. Панель инструментов диаграммы последовательностей На диаграмме последовательности изображаются исклю- чительно те объекты, которые непосредственно участвуют во взаимодействии и не показываются возможные статические ассоциации с другими объектами. Для диаграммы последова- тельности ключевым моментом является именно динамика взаимодействия объектов во времени. При этом диаграмма по- следовательности имеет два измерения. Одно — слева направо в виде вертикальных линий, каждая из которых изображает линию жизни отдельного объекта, участвующего во взаимодействии. Крайним слева на диаграмме изображается объект, кото- рый является инициатором взаимодействия. Правее изобража- ется другой объект, который непосредственно взаимодействует с первым. Таким образом, все объекты на диаграмме последова- тельности образуют некоторый порядок, определяемый степе- нью активности этих объектов при взаимодействии друг с другом. Второе измерение диаграммы последовательности — вер- тикальная временная ось, направленная сверху вниз. Начальному моменту времени соответствует самая верхняя часть диаграммы. При этом взаимодействия объектов реализуются посредством сообщений, которые посылаются одними объектами другим. Сообщения изображаются в виде горизонтальных стрелок 118 с именем сообщения и также образуют порядок по времени своего возникновения. Сообщения, расположенные на диа- грамме последовательности выше, инициируются раньше тех, которые расположены ниже. При этом масштаб на оси времени не указывается, поскольку диаграмма последовательности моделирует лишь временную упорядоченность взаимодей- ствий типа «раньше-позже». Линия жизни объекта изображается пунктирной верти- кальной линией, ассоциированной с каждым объектом на диаграмме последовательности. Линия жизни служит для обозначения периода времени, в течение которого объект существует в системе и, следовательно, может потенциально участвовать во всех ее взаимодействиях. Если объект суще- ствует в системе постоянно, то и его линия жизни должна продолжаться по всей плоскости диаграммы последовательно- сти от самой верхней ее части до самой нижней Отдельные объекты, исполнив свою роль в системе, мо- гут быть уничтожены, чтобы освободить занимаемые ими ресурсы. Для таких объектов линия жизни обрывается в мо- мент его уничтожения. Для обозначения момента уничтоже- ния объекта в языке UML используется специальный символ — косой крест на конце линии жизни объекта. Ниже этого симво- ла пунктирная линия не изображается, поскольку соответ- ствующего объекта в системе уже нет, и этот объект должен быть исключен из всех последующих взаимодействий. Не обязательно создавать все объекты в начальный мо- мент времени. Отдельные объекты в системе могут создавать- ся по мере необходимости. В этом случае прямоугольник такого объекта изображается не в верхней части диаграммы последовательности, а в той ее части, которая соответствует моменту создания объекта. При этом прямоугольник объекта вертикально располагается в том месте диаграммы, которое по оси времени совпадает с моментом его возникновения в си- стеме. Объект обязательно создается со своей линией жизни и, возможно, с фокусом управления. В StarUML каждому объекту можно задать имя, выбрать класс из уже созданных в модели (свойство Classifier), указать, что элемент представляет совокупность объектов (IsMultiInstance). Все эти свойства задаются с помощью навигатора свойств объек- та (рис. 12.2). 119 Рис. 12.2. Навигатор свойств объекта Обратите внимание, что выбрать класс объекта (Classifier) можно только из уже созданных в модели классов ( рис. 12.3), например, на диаграмме классов. Рис. 12.3. Выбор существующего класса для объекта Фокус управления. В процессе функционирования объект- но-ориентированных систем одни объекты могут находиться в активном состоянии, непосредственно выполняя определенные действия или в состоянии пассивного ожидания сообщений от других объектов. Чтобы явно выделить подобную активность объектов, в языке UML применяется специальное понятие, получившее название фокуса управления. Фокус управления 120 изображается в форме вытянутого узкого прямоугольника, верхняя сторона которого обозначает начало получения фокуса управления объекта (начало активности), а ее нижняя сторо- на — окончание фокуса управления (окончание активности). Этот прямоугольник располагается ниже обозначения соответ- ствующего объекта и может заменять его линию жизни, если на всем ее протяжении он является активным. Периоды активности объекта могут чередоваться с пери- одами его пассивности или ожидания. В этом случае у такого объекта имеются несколько фокусов управления. Важно понимать, что получить фокус управления может только существующий объект, у которого в этот момент име- ется линия жизни. Если же некоторый объект был уничтожен, то вновь возникнуть в системе он уже не может. Вместо него лишь может быть создан другой экземпляр этого же класса, который, строго говоря, будет являться другим объектом. Границы фокус управления на диаграмме можно изменять с помощью перетаскивания. Иногда некоторый объект может инициировать рекурсивное взаимодействие с самим собой. Речь идет о том, что наличие во многих языках программирования специальных средств построения рекурсивных процедур требует визуализации соответствующих понятий в форме графических примитивов. На диаграмме последовательности рекурсия обо- значается небольшим прямоугольником, присоединенным к правой стороне фокуса управления того объекта, для которого изображается это рекурсивное взаимодействие. Сообщения. Рассматриваемые взаимодействия описыва- ется совокупностью сообщений, которыми участвующие в нем объекты обмениваются между собой. Сообщение представляет собой законченный фрагмент информации, который отправ- ляется одним объектом другому. При этом прием сообщения инициирует выполнение определенных действий, направлен- ных на решение отдельной задачи тем объектом, которому это сообщение отправлено. Таким образом, сообщения не только передают некоторую информацию, но и требуют или предполагают от принимающе- го объекта выполнения ожидаемых действий. Сообщения могут инициировать выполнение операций объектом соответствую- щего класса, а параметры этих операций передаются вместе с сообщением. На диаграмме последовательности все сообщения 121 упорядочены по времени своего возникновения в моделируе- мой системе. В языке UML могут встречаться несколько разновидно- стей сообщений: 1. Вызов (CALL) — используется для вызова процедур, вы- полнения операций или обозначения отдельных вложенных потоков управления. Принимающий сообщение объект получает фокус управления, становясь активным. Этот вид сообщений моделирует синхронные (блокирующие) взаимодействия. 2. Посылка сигнала (SEND) — используется для обозна- чения асинхронных взаимодействий. 3. Создание и удаление объекта (CREATE и DESTROY) — сообщения, которые обозначают начало и завершение линии жизни объекта. Используются в том случае, когда объект суще- ствует не на всём протяжении рассматриваемого взаимодей- ствия. 4. Возврата из вызова (RETURN) — примером может служить простое сообщение о завершении некоторых вычис- лений без предоставления результата расчетов объекту- клиенту. В процедурных потоках управления эта стрелка мо- жет быть опущена, поскольку ее наличие неявно предполага- ется в конце активизации объекта. В то же время считается, что каждый вызов процедуры имеет свою пару — возврат вызова. Для непроцедурных потоков управления, включая параллельные и асинхронные сообщения, стрелка возврата должна указываться явным образом. В StarUML тип сообщения задаётся в навигаторе свойств сообщения (рис. 12.4). Рис. 12.4. Навигатор свойств сообщения 122 Циклы и ветвления. Рассмотрим варианты изображения циклов и ветвлений на диаграмме последовательности. Условное выполнение или повторение отдельных сооб- щений можно показать с помощью специальных обозначений в надписи сообщения. Для того, чтобы добавить условие к сообщению, впишите требуемое условие в свойство Branch навигатора свойств со- общения. Для указания количества повторений сообщения используйте свойство Iteration. Обычно повторения записыва- ют в формате «n = 1..10», т. е. повторить десять раз для значе- ний n от 1 до десяти. Для обозначения условного выполнения группы сообще- ний или повторения целой последовательности сообщений используются фреймы (рис. 12.5, рис. 12.6). Для изображения цикла используйте инструмент CombinedFragment, указав ему свойство InteractionOperator — «loop». Для изображения условий добавьте в CombinedFragment с InteractionOperator «opt» несколько InteractionOperand. Рис. 12.5. Пример использования фреймов для создания цикла n=1..10 |