UML

Модель (model) – это абстракция, описывающая суть сложной проблемы или структуры без акцента на несущественных для рассмотрения деталях, тем самым делая её более понятной.

Принятые обозначения, используемые для построения модели, являются нотациями (notation).

Информатика. 2 семестр. Тема 13. UML

Информатика. 2 семестр. Тема 13. UML

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

Информатика. 2 семестр. Тема 13. UML

Нотация выполняет три функции:

Унифицированный язык моделирования (Unified Modeling Language, UML) – расширяемая нотация, используемая на этапах анализа и проектирования

Риск – это степень нашего незнания какого-либо аспекта функционирования системы

Риски закреплены за каждой версией таким образом, чтобы успешное завершение версии уменьшало риск, закреплённый за ней

Время (разделение жизненного цикла на фазы и версии);
Компоненты процесса (создание необходимого набора средств для выполнения чётко определённых задач);

Информатика. 2 семестр. Тема 13. UML

Два направления структурирования:

Информатика. 2 семестр. Тема 13. UML

Работа над проектом состоит из следующих временных этапов:

Информатика. 2 семестр. Тема 13. UML

Работа над проектом состоит из следующих стадий:

Версии системы (прототипы) используются для проверки аналитических решений в области архитектуры системы

Никому не нужна система, которая ничего не автоматизирует или автоматизирует неправильные вещи…

Для начала проекта нужна идея:
«Наша система делает…»

Собираются и документируются идеи;
Предварительно описываются риски;
Описываются внешние интерфейсы;
Планируется общая функциональность системы;
Создаются тестовые прототипы для проверки общей концепции (proof of concept prototypes).

Решаемые задачи:

бизнес-требований;
доступных ресурсов;
возможностей использования различных технологий;
идей и пожеланий конкретных пользователей.

Анализ:

профессиональные и научные исследования
мозговой штурм;
анализ эффективности;
анализ функциональности;
создание прототипов.

Выработка целевой концепции системы, описание задач и приоритетов:

Первичное сокращение ресурсов и времени

Техническое (рабочее) наименование, отвечающее на вопрос «что делающая?»
Краткое описание, определяющее преимущества и особенности (ограничения);
Интерпретация основного процесса на естественном языке с предполагаемым распределением ролей.

2. Определить риски

3. Записать известные особенности работы системы:

Что могут делать пользователи (использование);
Какая информация выдается системой (содержание);
Какие ограничения на множества известны (количества);
Этапы (шаги) основного процесса;
Условия возникновения альтернативных процессов.

Определить актёров (actor) и их роли (возможности, обязанности) в системе;
Определить для актёров направления потоков данных (инициации взаимодействия);
Описать возможности взаимодействия актёров с системой (диалоги актёр-система) как прецеденты;
Записать потоки событий для прецедентов.

5. Установить отношения прецедентов

(продолжение)

6. Составить диаграммы прецедентов

7. Составить диаграммы действий (Activity diagram) как схем решения каких-нибудь задач в системе

ДД могут затрагивать сразу нескольких актёров, включать основные и альтернативные потоки событий прецедентов

Анализ поведения

10. При большом количестве классов создать пакеты

(продолжение)

11. Исследовать реализацию прецедентов через сценарии (scenario) – одиночные проходы по потоку событий

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

9. Определить стереотипы классов

Анализ структуры

Изучение взаимодействия объектов

диаграммы последовательности действий (sequence diagrams) – для просмотра сценария во времени;
диаграммы взаимодействий (collaboration diagrams) – для анализа взаимодействия объектов.

Определение отношений объектов

13. Проанализировать семантические отношения

ассоциативные;
агрегационные.

14. Определить мощность (multiplicity) отношений

15. При наличии в проекте пакетов, между ними отображаются отношения зависимости.

16. Определить поведение и структуру для классов

Описание:

Учебный процесс построен на свободной записи студентов на учебные курсы. Контролируется общее количество учебных часов.

Организация процесса регистрации:

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

Эффективность сохранения и получения информации об учебных планах и учёта студентов

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

Нотация языка UML для изображения актёра

Актёры

Актёры не являются частью системы – они представляют собой кого-то или что-то, то должно взаимодействовать с системой

Актёры могут:
только снабжать информацией систему;
только получать информацию из системы;
обмениваться информацией с системой.

Возможности актёров:
Студент хочет зарегистрироваться на курсы;
Преподаватель хочет выбрать курсы, которые будет читать;
Регистратор должен создать учебный план и составить каталог на семестр;
Регистратор должен хранить информацию о курсах, преподавателях и студентах;
Система оплаты должна получать информацию из системы регистрации.

Регистрация прецедента в Rational Rose

Поток событий должен определять:
когда и как прецедент начинается и заканчивается;
как он взаимодействует с актёром;
какие данные ему нужны;
нормальную последовательность событий для прецедента
описание потоков в альтернативных и исключительных ситуациях

1.1 Предусловия
Перед началом должен быть выполнен под-поток создание учебных курсов прецедента управление информацией о курсах
1.2 Главный поток
Прецедент начинает выполняться, когда преподаватель подключается к системе регистрации и вводит свой пароль.
Система проверяет правильность пароля (E-1) и просит преподавателя выбрать текущий или будущий семестр (E-2).
Преподаватель вводит нужный семестр.
Система предлагает выбрать требуемую операцию: добавить, удалить, посмотреть, напечатать или выйти.
Если выбрана операция добавить: выполняется поток добавить учебный курс (S-1).
Если выбрана операция удалить: выполняется поток удалить учебный курс (S-2).
Если выбрана операция посмотреть: выполняется поток посмотреть расписание (S-3).
Если выбрана операция напечатать: выполняется поток напечатать расписание (S-4).
Если выбрана операция выйти: прецедент завершается.

Связанный документ с описанием потока событий в Rational Rose

Стереотип (stereotype) – это способ добавления новых свойств к базовым элементам языка UML.
Имя стереотипа заключается в двойные треугольные скобки и помещается рядом с элементом.

Регистрация диаграммы действий в Rational Rose

Размещение переходов на диаграмме действий

Размещение элемента выбора на диаграмме действий

Для элемента выбора в качестве обязательного параметра (Specification) выступает условие (Guard Condition)

Условный переход на диаграмме действий

Для условного перехода необходимо определить условие перехода

Во многих случаях гораздо «привычнее» использовать «прямоугольный» (прямолинейный) режим отображения линий перехода

Линии синхронизации указывают на необходимость одновременного начала или завершения отдельных потоков управления

Объект (object) – это некая сущность реального мира или концептуальная сущность.
Объектом называется концепция, абстракция или вещь с чётко определёнными границами и значением для системы.
Каждый объект в системе имеет три характеристики:
Состояние;
Поведение;
Индивидуальность.

Нотация для обозначения класса содержит три секции: имя класса, структуру (атрибуты) и поведение (операции).

Регистрация класса в разделе LogicalView модели в Rational Rose

Базовые стереотипы классов – это класс-сущность, граничный класс, управляющий класс.
Собственные стереотипы задаются двойными треугольными скобками вокруг наименования стереотипа. UML допускает использование собственных обозначений (значков) для стереотипов классов.

Граничные классы (boundary class) обеспечивают взаимодействие между окружающей средой и внутренними элементами системы. Граничные классы предоставляют интерфейс для пользователя или другой системы (актёров).

Управляющие классы (control class) служат для моделирования последовательного поведения одного или нескольких прецедентов и координации событий, реализующих заложенное в них поведение. Управляющие классы «исполняют» прецедент и определяют его динамику.

Документирование (описание) класса поясняет его назначение, а не структуру. Трудности с описанием класса, скорее всего, свидетельствуют о том, что он – недостаточно хорошая абстракция.

Каждый пакет содержит интерфейс, реализуемый набором его общедоступных классов (public classes) – тех, с которыми могут общаться классы из других пакетов.
Остальные классы пакета – это классы реализации (implementation classes), которые не взаимодействуют с классами в других пакетах.

Регистрация пакета и перемещение класса

(Для сценария добавление учебного курса – внутреннего потока прецедента выбор предметов для преподавания)

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

Классы для сценария

Классы-сущности
Предмет, курс, преподаватель (данные)

Управляющие классы
Нужен всего один класс для обработки потока событий для прецедента – менеджер курсов преподавателя

Классы
Предмет, учебный курс, преподаватель, параметры курса преподавателя, добавление учебного курса, менеджер курсов преподавателя.

Пакеты

Группы
Объекты, специфические для университета;
Объекты, содержащие информацию о людях;
Интерфейсы для актёров.

Пакеты
Интерфейсы
Объекты университета
Сведения о людях

Главная диаграмма классов отображает пакеты системы

Главная диаграмма классов

Каждый пакет также имеет свою главную диаграмму классов, которая содержит общедоступные классы пакета

Для диаграмм классов может быть настроен режим «видимости пакета» в котором данный класс описан

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

Сценарий (scenario) – это элемент прецедента, представляющий собой одиночный проход по потоку событий для прецедента.

Каждый прецедент – это сплетение первичных (нормальный поток прецедента) и вторичных сценариев (ветвления, исключения, альтернативные потоки), порождаемых различными состояниями системы.

Начальный поиск сценариев ведётся примерно до 80% покрытия.

Регистрация реализации

Диаграмма последовательности действий (sequence diagram) – отображает взаимодействие объектов упорядоченное по времени.

Взаимодействие объектов

Диаграмма для сценария создание учебного предмета

Применение граничного класса

Так как главное назначение диаграммы последовательности действий – отображение объектов, их взаимодействия, сообщений между ними и функциональности, задаваемой сценарием

Моделирование условной логики (ЕСЛИ-ТО-ИНАЧЕ):
Если логика проста и требует небольшого количества сообщений, то её можно разместить на одной диаграмме с указанием выбора, который нужно сделать.

Как правило, лучше строить отдельные диаграммы для каждого варианта выбора (одну для ТО и одну для ИНАЧЕ)

Нотация языка UML для объектов, связей и сообщений на диаграмме взаимодействий

Диаграмма взаимодействий (collaboration diagram) – отображает организацию взаимодействия объектов и связи между ними.

Диаграмма взаимодействий

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

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

Схема классов, участвующих в прецеденте

Сценарий описывает реализацию прецедента в виде взаимодействия групп объектов. Сценарий – это экземпляр прецедента, одиночный «проход» по потому событий прецедента. Прецедент – это «сплетение» сценариев.

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

Поток событий для прецедента описывается словами, а сценарий – диаграммами взаимосвязи:

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

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

Необходимость отношений
Система состоит из большого числа классов и объектов.
Её поведение обеспечивается взаимодействием объектов.
Взаимодействие объектов часто описывают как отправку сообщений.
На этапе анализа выделяют два типа отношений – ассоциация и агрегация.

Ассоциация (association) – это двунаправленная семантическая связь между классами. Количество связанных объектов определяется мощностью связи.

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

Агрегационное отношение – это специальная форма ассоциации между целым и его частью или частями.
Агрегация описывается через фразы «часть от» или «содержит».
Класс-агрегат обозначается ромбом на линии связи.

Ассоциативная связь становится агрегационной, если можно утвердительно ответить на вопросы:
Можно ли применить фразу «часть от», чтобы описать отношение?
Происходит ли автоматическое применение некоторых операций над целым к его частям?
Существует ли выраженная асимметрия в отношении, когда один класс подчинён другому?

Например, отношение между предметом и учебным курсом моделируется как агрегация – предмет содержит несколько учебных курсов.

При выборе типа связи необходимо учитывать предметную область. Как связаны объекты в рамках моделируемых процессов?
Например, Автомобиль и шины в автомастерской связаны как «целое-и-часть», но в автомагазине отношение будет ассоциативным

Наименование ассоциативной связи должно быть ненаправленным.
Агрегационная связь всегда направлена – «имеет», «включает».

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

Обычно роль может читаться в двух направлениях:

преподаватель играет роль учителя для учебного курса;
учебный курс имеет отношение к преподавателю, играющему роль учителя.

1 – ровно один;
0…* – ноль или больше;
1…* – один или больше;
5…8 – диапазон (5,6, 7 или 8);
4…7, 9 – комбинация (4,5,6,7 или 9).

Например: один объект предмет, выступающий в качестве вводного курса (prerequisite), связан с нулём или большим количеством объектов предмет.

Для сценария добавить учебный курс можно определить следующие взаимодействующие объекты и типы отношений:

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

В сценарии добавить учебный курс класс добавление учебного курса отправляет сообщение классу менеджер курсов преподавателя. Это указывает на наличие связи между пакетами Интерфейсы и Объекты университета.

Структура (structure) объекта описывается атрибутами класса. Каждый атрибут – это поле данных, содержащееся в объекте класса. Объект, созданный на основе класса, наделён значениями всех атрибутов класса.

Если какой-либо объект класса не наделён атрибутами (не установлены значения), то необходимо проверить определение класса. Это может означать отсутствие целостности класса и необходимости его разделения.

Общее правило:
Класс должен представлять одну сущность.

Наименование операции должно использовать термины класса, выполняющего операцию, а не класса, запрашивающего её выполнение

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

Отношение между классами также может иметь структуру и поведение. Такое отношение моделируется с помощью ассоциативного класса (association class) который ведёт себя так же обычные классы и тоже может иметь отношения.