Конспект лекции № 6

Элементы диаграмм использования

Сущности:
• действующие лица
• варианты использования
• примечания
• пакеты
Отношения:
• ассоциация
• обобщение
• зависимости
Действующее лицо — это множество логически взаимосвязанных ролей.
• Стереотипный класс
• Находятся ВНЕ проектируемой системы

Типовые случаи: категории пользователей, внешние программные и аппаратные средства
Роль в UML — это контракт (сервисы), поддерживаемый данным классификатором в данной ассоциаций.
Вариант использования — множество возможных последовательностей событий/действий (сценариев), приводящих к значимому для действующего лица результату.
• Типичные случаи: пункты технического задания
• Если техническое задание смутное, его можно (и нужно!) попробовать переписать фразами субъект — предикат — объект

Отношения элементов диаграмм использования

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

Обобщение между действующими лицами
Обобщение между вариантами использования
Зависимость между вариантами использования
Зависимость между пакетами
Иерархия категорий пользователей ИС ОК (обобщение)

Абстрактное действующее лицо. Ещё один вариант использования — просмотр (2). Этим вариантом использования должны быть ассоциированы все категории пользователей, которые введены в систему. Абстрактное действующее лицо (1) является обобщением имевшихся раньше (3) и (4). За счёт этого модель становится более лаконичной.

Зависимости между вариантами использования

Применяется 2 стереотипных зависимости между вариантами использования: со стереотипом «include» и со стереотипом «extend». В обоих случаях речь идёт о том, что последовательность событий и действий, соответствующая одному варианту использования, подключается в качестве подпоследовательности в последовательность событий и действий, соответствующих другому варианту использования.

Комбинация отношений обобщения и зависимости
Можно провести зависимость только один раз от абстрактного варианта использования. За счёт обобщений, которые уже введены в модель, эта зависимость будет распространена на оба варианта использования.

Границы системы

Модель использования:
• внутренняя моделируемая система — варианты использования
• внешнееокружение — действующие лица
• связь между моделируемой системой и внешним окружением
Если нужно отделить применяется графический комментарий — Границы системы

Способы применения моделей использования

Действующим лицом может быть любая сущность, находящаяся вне моделируемой части системы. В частности любые внешние программные или аппаратные средства.

Реализация вариантов использования
Реализация варианта использования — это описание всех или некоторых сценариев, составляющих вариант использования.
• Метод описания — указание алгоритма
• Способы описания алгоритмов см. далее
Переход от анализа и постановки задачи к решению (проектированию)
Текстовые описания

Увольнение по собственному желанию
1. Сотрудник пишет заявление
2. Начальник подписывает заявление (а если нет?…)
3. Если есть неиспользованный отпуск,
то бухгалтерия рассчитывает компенсацию
4. Бухгалтерия рассчитывает выходное пособие
5. Системный администратор удаляет учетную запись
6. Менеджер штатного расписания обновляет базу
данных
«-» неточность, которая незаметна
Программы на псевдокоде

Реализация диаграммами деятельности (блок-схемами)
Например, возможны три различных типа сценария при приеме сотрудника на работу. Может быть проведён успешный прием, который заканчивается тем, что мы вносим информацию в базу данных (1). Прием может не состояться по той причине, что у нас нет подходящей позиции в штатном расписании (2). Прием также может состояться, если кандидат отвергает все сделанные ему предложения (3).

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

Реализация диаграммами взаимодействия
Прямо ведут к объектной модели
Целостность проектируемой системы
Возможность автоматизированного построения прототипов
НО

Позволяют реализовать только ОДИН сценарий — нужно МНОГО диаграмм
Сложная и непривычная нотация
Диаграмма последовательности для типового сценария

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

Диаграмма кооперации для исключительной ситуации

Сравнение способов реализации вариантов использования

Диаграммы деятельности

Псевдокод эквивалентен блок-схемам (с точностью до параллелизма)
Наглядно, но менее компактно
Почти не приближают к объектной модели
Диаграммы взаимодействия

Сложная и непривычная нотация
Диаграммы объектного уровня — описывают ОДИН сценарий — нужно МНОГО диаграмм
Прямо ведут к объектной модели
Полезные советы

Строить диаграммы взаимодействия для всех типовых сценариев вариантов использования
• Хотя бы для всех вариантов использования, выбранных для реализации в первой версии системы
Сопоставлять набор выявленных классов со словарем предметной области
• Если пересечение незначительно, то нужно приостановить проектирование и вернуться на фазу анализа.