Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
ПИС.doc
Скачиваний:
23
Добавлен:
27.11.2019
Размер:
3 Мб
Скачать
☆

6.2. Диаграммы uml

UML 2.0 описывает 13 официальных типов диаграмм, перечисленных в табл. 6.1. Классификация диаграмм приведена на рис. 6.1. Допустимо присутствие элементов диаграммы одного типа в другой диаграмме.

Таблица 6.1. Официальные типы диаграмм UML

№

Диаграмма

Назначение диаграммы

1

Классов

Описывает классы и статические отношения между ними

2

Последовательность

Описывает взаимодействие между объектами (акцент на последовательность)

3

Объектов

Показывает взаимосвязи между объектами

4

Пакетов

Объединяет классы в группы

5

Развертывания

Показывает, на каком физическом оборудовании запускается та или иная часть ПО

6

Прецедентов (использования)

Определяет функциональные требования к ПО

7

Состояний (конечных автоматов)

Показывает как события изменяют объект в течение его жизни

8

Деятельности

Описывает логику процедур, бизнес-процессов и потоков работ

9

Коопераций

Описывает взаимодействие между объектами (акцент на обмене данными)

10

Составных структур

Разбивает класс на составляющие

11

Компонентов

Структура и взаимосвязи между компонентами, т.е. элементами ПО, которые независимо друг от друга можно обновить или купить

12

Обзора взаимодействий

Комбинация диаграммы последовательности и диаграммы деятельности

13

Временная

Описывает взаимодействие между объектами (акцент на временных ограничениях)

Далее будут рассмотрены основные элементы диаграмм прецедентов, классов, последовательностей, коммуникаций, состояний, деятельности и компонентов.

Рис. 6.1. Классификация диаграмм UML

6.3. Синтаксис и семантика основных объектов uml

Рассматриваются некоторые диаграммы языка объектного моделирования UML.

6.3.1. Диаграммы прецедентов

Диаграммы прецедентов описывают функциональность ИС, которая будет видна пользователям системы. Прецедент - это типичное взаимодействие пользователя с системой, которое при этом:

  • описывает видимую пользователем функцию;

  • может представлять различные уровни детализации;

  • обеспечивает достижение конкретной цели, важной для пользователя.

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

На диаграммах прецедентов, кроме связей между действующими лицами и прецедентами, используются связи между прецедентами. Наиболее часто эти связи имеют тип «использование» или «расширение» (рис. 6.2). Связь типа «расширение» применяется, когда один прецедент подобен другому, но несет несколько большую функциональную нагрузку. Ее следует применять при описании изменений в нормальном поведении системы. Связь типа «использование» позволяет выделить некий фрагмент поведения системы и включать его в различные прецеденты без повторного описания.

На рис. 6.2 показано, что при исполнении прецедента «Сформировать заказ» возможно использование информации из предыдущего заказа, что позволит не вводить все необходимые данные. А при исполнении прецедентов «Оценить риск сделки» и «Согласовать цену» необходимо выполнить одно и то же действие - рассчитать стоимость заказа.

Рис. 6.2. Связи на диаграммах прецедентов

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

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

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

Большая опасность прецедентов заключается в том, что разработчики делают их очень сложными и застревают на них.