Модели UML, поясняющие функциональность системы

Какие модели использовать

Требования к оформлению результатов

Порядок выполнения работы

1. Провести интервью с представителем Заказчика (см. теоретические сведения к лабораторной работе 1).

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

3. Выявить варианты использования. Для каждого из экторов необходимо выявить максимально возможное количество вариантов использования. Каждому из них - сопоставить краткую (в одно предложение) формулировку.

4. Составить диаграммы вариантов использования. На усмотрение студента составляется одна общая или несколько частных диаграмм вариантов использования. Общее требование: каждый вариант использования и каждый эктор должны быть отражены хотя бы на одной диаграмме.

5. Оформить работу.

Результаты должны быть представлены в документе MS Word; структура и форматирование должны быть взяты в примере оформления работы № 2.

Теоретические сведения

Чтобы облегчить процесс формулировки и понимания требований для Заказчика, существует ряд приемов. Хорошим подспорьем в решении задачи является применение визуальных средств описания требований. На сегодня в арсенале аналитика существуют десятки методик, языков, визуальных представлений, позволяющих моделировать требования к системе.

Для моделирования анализа требований следует применять модели, наиболее адекватно проясняющие функциональность системы и особенности ее использования. Однако, аналитик волен выбирать те языки и методики, которые позволят добиться целевой функции: снижения рисков непонимания между Исполнителем и Заказчиком и размытия границ.

Диаграмма вариантов использования

Диаграмма вариантов использования UML, Use Case Diagram - одно из самых простых представлений системы. Ее базовые "строительные элементы" - экторы и варианты использования. Диаграмма задумана так, чтобы дать наиболее общее представление о функциональности системы, не вдаваясь в детали взаимосвязей функций. Поэтому основной вид отношения, используемый в диаграмме - ассоциация между эктором и вариантом использования (рис.2.1).

Рис.2.1. Ассоциации между эктором и вариантами использования

Другие виды отношений - отношение включения (include), расширения (extend) и обобщения/генерализации.

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

Рис.2.2. Использование отношения «включение»

Расширение (см.рис.2.3.) в точности соответствует точке расширения, используемой при описании варианта использования.

Рис.2.3. Использование отношения «расширение»

Отношение обобщения (см.рисунок 2.4) может применяться как к экторам, так и к вариантам использования, с целью указания специализации одних относительно других.

Рис.2.4. Использование отношения «обобщение»

Диаграмма действий (деятельности)

Если диаграмма вариантов использования дает "вид сверху" на функциональность системы, диаграмма действий UML, напротив, позволяет подробно иллюстрировать отдельный вариант использования и его сценарии.

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

Помимо стандартного формата описания, UML предлагает вариант с "плавательными дорожками". Этот формат удобен для описания случая, когда в варианте использования участвуют несколько экторов.

Рис.2.5. Пример диаграммы деятельности

Диаграмма состояний

Диаграмма состояний в анализе требований используется, когда требуется исследовать поведение системы, как конечного автомата. Это представление пришло в UML из теории систем. В общем случае диаграмма состояний описывает, как система себя ведет в более, чем одном варианте использования. Синтаксис диаграмм состояний во многом совпадает с синтаксисом диаграмм действий.

Основные компоненты описания системы:

• Простые состояния,
• Составные состояния,
• Символы "старт" и "стоп",
• Переходы,
• Линейки синхронизации.

В языке UML под состоянием понимается абстрактный метакласс, используемый для моделирования отдельной ситуации, в течение которой имеет место выполнение некоторого условия. Состояние может быть задано в виде набора конкретных значений атрибутов класса или объекта, при этом изменение их отдельных значений будет отражать изменение состояния моделируемого класса или объекта.

Переход системы из состояния в состояние осуществляется при наступлении событий. При этом говорится, что переход срабатывает. Переход может быть безальтернативным, либо содержать альтернативы. Во втором случае переход обусловлен наступлением сторожевых условий. Наконец, событие может сопровождаться выражением действия, которое происходит в случае, если срабатывает переход. Полный синтаксис описания перехода (надписи на стрелке) следующий: Событие [сторожевое условие] / выражение действия (см.рисунок 2.6.).

Рис.2.6. Диаграмма деятельности с отмеченным переходом.

Пример оформления лабораторной работы 2

Система диспетчеризации типографии

Поиск экторов и вариантов использования

Дата добавления: 2017-01-14