Предварительное описание
Каждый блог принадлежит одному пользователю и состоит из нескольких записей. В момент создания блога в нем записей нет. Пользователь может создавать записи лишь в собственном блоге. Читать записи любого пользователя может каждый пользователь. В каждой записи есть заголовок, дата, текст. На каждой странице блога находятся ссылка на профиль. На начальной странице блога отображаются 10 последних записей (или менее, если в блоге их недостаточно). Если записей в блоге больше 10, то с начальной страницы можно перейти на вторую, где отображается второй десяток записей и т. д.. Записи в блоге упорядочены по убыванию даты. Любая запись может быть отредактирована, но дата записи не может быть изменена. Запись может быть удалена автором.
Перейдя на страницу отдельной записи, пользователь может ее комментировать, независимо от того чужая это запись или его собственная. Комментарий состоит из текста и даты, указывающей, когда он написан. Комментарий может быть дан к записи блога или к ранее написанному комментарию. Пользователь может запретить комментирование любой записи в своем блоге. Комментарии, полученные раньше запрета, сохраняются. Запрет на комментирование может быть снят. Все комментарии к записи отображаются под ее текстом в виде дерева. Каждый комментарий помечен именем его автора. Имя может быть использовано для перехода к начальной странице блога с этим именем.
Комментарии не могут быть отредактированы, но могут быть удалены автором записи. При удалении комментария также стираются все ответы на него, если таковые были.
Любой желающий вести блог должен зарегистрироваться. При регистрации пользователь заполняет форму, указывая желаемое имя, пароль, список своих интересов, дату рождения, контакты, краткие сведения о себе. Если имя не занято, и форма заполнена полностью, система заводит блог нового пользователя.
Сведения из регистрационной формы (кроме пароля) отображаются на странице профиля пользователя. Пользователь может отредактировать собственный профиль, изменив в нем все, кроме имени. Пользователь может изменить свой пароль. Пароль не может быть короче 8 символов.
Зарегистрированный пользователь, осуществляет вход в собственный блог, указывая имя и пароль. Все описанные выше действия с записями, комментариями и собственным профилем, действия с друзьями доступны пользователю только после входа.
Пользователь может полностью удалить свой блог со всеми записями, комментариями и профилем. После удаления блога регистрационные данные стираются из системы.
Выделение прецедентов
Определение рамок системы
Для того чтобы яснее очертить рамки проектируемой системы, определим те функции, которые она не должна выполнять, т.е. определим внешних вспомогательных исполнителей.
Основной исполнитель (primary) – операционная система
Вспомогательный исполнитель (supporting) – браузер устройства, беспроводной роутер
Закулисный исполнитель (offstage) – база данных
Не проводит модерацию блога.
Не обеспечиваем компьютерными устройствами.
Не ограничиваем количество блогов, записей, комментариев и остальных данных.
Не организуем рекламную компанию для конкретного блога.
Мы не осуществляем контроля за соблюдением требований, предусмотренные федеральными законами.
Мы не несем ответственность за контент, выложенный пользователями.
Мы не обязаны распространять информацию в сети интернет, чтобы предоставить указанную информацию уполномоченным государственным органам.
Определение основных исполнителей и задач
Составим перечень исполнителей в виде таблицы, по которой можно определить основные прецеденты. Распишем, какие задачи они выполняют.
Исполнитель
Регистрирует собственный блог, Изменение данных собственного блога,
Комментирование записей, Удаление собственного блога
Из таблицы можно сделать вывод, что в разрабатываемой системе присутствует 1 исполнитель:
Поэтому в качестве прецедентов определим те, которые соответствуют задачам основных исполнителей.
Описание прецедентов
В данном разделе прецеденты описаны по следующим параметрам: рамки, основной исполнитель, заинтересованные лица, предусловия, результаты, то есть были определены границы системы, условия для выполнения данного прецедента, а также результат выполнения прецедента.
Описание прецедента «Аутентификация»:
Данный прецедент предоставляет пользователям возможность доступа в систему по индивидуальному логину и паролю.
Рамки текущего прецедента: главная страница сайта
Основной исполнитель: пользователь
Заинтересованные лица: сервер
Предусловия: отсутствие пользователя с идентичным именем пользователя
Описание прецедента «Регистрация собственного блога»:
Данный прецедент предоставляет созданный блог для «свободного» пользования.
Рамки текущего прецедента: система управления блогом
Основной исполнитель: пользователь
Заинтересованные лица: сервер и пользователь
Предусловия: отсутствие блога с таким же название
Описание прецедента «Комментирование»:
Данный прецедент предоставление возможности комментирования записей.
Рамки текущего прецедента: записи, находящиеся в блоге
Основной исполнитель: пользователь
Заинтересованные лица: пользователь
Предусловия: существование записей в блоге
Описание прецедента «Удаление собственного блога»:
Данный прецедент предоставляет возможность удаления блога из баз данных.
Рамки текущего прецедента: система управления богом
Основной исполнитель: пользователь
Заинтересованные лица: пользователь и сервер
Предусловия: существование блога
Успешный сценарий прецедента «Аутентификация»:
Ввод данных в поля «логин» и «пароль»
Система проверяет правильность ввода данных
Загрузка соответствующей страницы блога
Успешный сценарий прецедента «Регистрация собственного блога»:
Ввод личных данных в соответствующие поля:
Список своих интересов
Краткие сведения о себе
Система проверяет корректность введенных данных
Система сохраняет личную информацию
Успешный сценарий прецедента «Комментирование»:
Пользователь открывает запись, под которой хочет оставить комментарий
Система контролирует доступ к комментированию
Пользователь комментирует запись блога
Расширения (альтернативные потоки)
2а. Если комментирование запрещено, пользователь не может оставить комментарий под постом
Успешный сценарий прецедента «Удаление собственного блога»:
Пользователь входит в систему под индивидуальным логином и паролем
Пользователь заходит в раздел «Настройки»
Пользователь удаляет собственный блог по средствам нажатий соответствующих кнопок
Система удаляет блог, все записи и комментарии, принадлежащие блогу
Дает возможность доступа в систему
Регистрация собственного блога
Регистрирует пользователя в системе
Изменение данных собственного блога
Позволяет выкладывать записи, изменять личные данные и пароли, управлять комментированием записей
6) Объектно-ориентированное программирование 1
Объектно-ориентированное проектирование ПС (часть 1)
Декомпозиция системы (в частности- программной системы — ПС)
- Функциональная – на основе потока данных с выделением обрабатывающих функций
- Объектная – на основе выделения сущностей, обладающих собственными наборами данных, состояниями и наборами операций
- В первом случае внимание концентрируется на порядке происходящих событий (действиях)
- Во втором – на агентах, являющихся либо объектами, либо субъектами действий
Структурные единицы
- Основной структурной единицей при функциональной декомпозиции является процедура как программная реализация алгоритма
- Основной структурной единицей при объектно-ориентированной декомпозиции является объект как объединение данных и действий над ними
Начало проектирования
Представляются в виде диаграммы прецедентов, сопровождаемой описанием прецедентов
Следующий шаг – создание концептуальной модели системы
Концептуальная модель – это описание системы в терминах предметной области
Ключевые абстракции
В концептуальной модели используются ключевые абстракции предметной области
Ключевая абстракция — это класс или объект, который входит в словарь проблемной области
Выделение объектов
Ключевые абстракции определяют границы системы: выделяют то, что входит в нее и важно для нас, а также устраняют все лишнее
На более поздних этапах проектирования большинство ключевых абстракций будут отображены в программные классы
Пример разработки
Этот пример описан в книге Крэга Лармана «Применение UML и шаблонов проектирования»
Постановка задачи
Разработать программное обеспечение для системы организации товарооборота и обработки платежей в магазинах розничной торговли
Модель разработки
Разработка системы будет вестись в рамках модели RUP — адаптивного итеративного процесса с постепенным наращиванием функциональности ПС и уточнением требований посредством механизма обратной связи
Фазы процесса разработки
Начало – анализ проблемы, формирование представлений о функциях системы и основных требованиях к ней
Развитие –реализация базовой части системы и уточнение требований; осуществляется через последовательность итераций
Фазы процесса разработки
Конструирование – разработка системы в полном объеме и окончательная формулировка требований; осуществляется через последовательность итераций, каждая из которых завершается созданием релиза
Внедрение – развертывание системы и бета-тестирование
Этап Начало
Основные задачи:
формирование представления о проекте
формулирование исходных требований к системе
оценка стоимости проекта
идентификация основных рисков
Анализ предметной области
Предметная область – ро?зничная торго?вля (англ. retail)
Что делается – производится продажа товаров конечному потребителю (частному лицу)
Как делается – покупатель отбирает необходимые ему товары и производит оплату в кассе
Анализ предметной области
Где делается – основным предприятием розничной торговли является магазин (дискаунтер, универмаг, универсам и т.д.)
Кто делает – субъектами процесса розничной торговли являются продавец (менеджер торгового зала, кассир) и покупатель
Анализ предметной области
Когда делается – каждый магазин имеет фиксированный график работы
Зачем делается – розничная торговля обеспечивает удовлетворение потребностей населения в товарах различного назначения и получение торговой прибыли
Проблемы
Низкая скорость выполнения операции оплаты покупок
Ошибки кассиров при подсчете стоимости товаров и расчете с покупателями
Сложность ведения учета проданных товаров
Большие объемы работ по подготовке данных для системы анализа
Пути решения
Создание компьютеризированной системы оплаты покупок Point-Of-Sale (POS-система)
Интеграция этой системы с существующими компьютерными системами поддержки торговой деятельности – системой складского учета, системой анализа торговой деятельности, бухгалтерской системой
POS-терминал
POS-система реализуется в виде набора POS-терминалов
Каждый POS-терминал представляет собой программно-аппаратный комплекс, установленный на месте, где кассир осуществляет прием платежей от клиентов (АРМ кассира)
Аппаратная часть
Аппаратная часть POS-терминала включает:
системный блок ПК,
фискальный регистратор,
POS-монитор кассира,
денежный ящик,
программируемую клавиатуру, считыватель карт,
считыватель штрих-кодов
Интерфейс пользователя
POS-терминал должен иметь интерфейс взаимодействия с пользователем для
поиска нужного товара и получения его характеристик;
формирования и печати чеков;
подсчета сдачи;
выполнения различных отчетов
Определение границ системы
Границы системы проще всего определить установив основных исполнителей, потребности которых удовлетворяются данной системой
Для этого надо ответить на вопросы:
Кто будет снабжать систему информацией?
Кто будет получать информацию от системы?
Кто будет осуществлять поддержку и обслуживание системы?
Использует ли система внешние ресурсы?
Границы системы
Основные исполнители
Кассир
оформляет продажи,
выполняет возврат товара,
регистрирует выручку;
Системный администратор
редактирует список пользователей,
управляет безопасностью;
Основные исполнители
Менеджер
включает систему,
выключает систему
Система анализа торговой деятельности
анализирует информацию о продажах и оценивает производительность
Прецеденты
Следует иметь в виду, что прецеденты могут быть определены на разных уровнях детализации
При анализе требований следует сосредоточить внимание на уровне элементарных бизнес-процессов, т.е. задач достаточно высокого уровня
Основной сценарий таких прецедентов содержит 5 – 10 шагов
Прецеденты для POS-системы
Включение системы
Регистрация в системе
Оформление покупки
Возврат товара
Регистрация выручки
Управление списком пользователей
Управление безопасностью
Анализ деятельности
Выключение системы
Ранжирование прецедентов
Учитываются следующие факторы:
влияние на архитектуру (например, добавление новых классов);
наличие рискованных, срочных или сложных функций;
потребность в дополнительных исследованиях;
степень важности соответствующего бизнес-процесса
Ранжирование прецедентов
Функциональные требования
Требования этой категории исследуются и формулируются в процессе разработки модели прецедентов (вариантов использования)
Как правило, одной задаче исполнителя соответствует один прецедент
Диаграмма прецедентов
Описание прецедентов
Диаграмма прецедентов дает наглядное изображение системного контекста – границ системы, внешние по отношению к ней понятия и способы использования системы
Однако, для формулирования и анализа требований необходимо детальное текстовое описание прецедентов
Описание прецедентов
Текстовое описание прецедента может быть развернутым или кратким
На начальном этапе развернутое описание дается лишь для основных прецедентов (10-20% от их общего числа)
Пример развернутого описания для прецедента Оформление продажи
Сбор требований
Требования можно разбить на категории (модель FURPS+):
Functionality – функциональности,
Usability – эргономичности,
Reliability – надежности,
Performance – производительности,
Supportability – возможности поддержки,
+ – дополнительные требования (реализация, интерфейс, юридические вопросы и пр.)
Нефункциональные требования
Определяются в дополнительной спецификации
Приведем пример такой спецификации для POS-системы
Эргономичность
Для достижения высокой скорости обслуживания покупателей при его высоком качестве необходимо:
обеспечить минимальное время отклика системы,
текст должен быть виден с расстояния 1 м,
не должно быть мерцания экрана,
предупреждающие сообщения должны сопровождаться звуковыми сигналами
Надежность
При сбое в работе внешних систем (анализ деятельности) необходимо обеспечить возможность локальной обработки данных, их сохранение и последующую передачу
Этот вопрос требует дальнейшей проработки
Производительность
Покупатель хочет оформить покупку как можно быстрее
Одна из основных причин задержки – низкая скорость авторизации
Необходимо обеспечить выполнение авторизации менее, чем за 1 минуту в 90% случаев
Недостатки существующих решений
Не обеспечивается автоматический переход из интерактивного в автономный режим при сбоях внешних систем;
Отсутствие простой возможности интеграции с внешними системами;
Отсутствие поддержки новых терминальных технологий
Риски
Итоги этапа Начало
Выделены основные исполнители, задачи и прецеденты
Выполнено ранжирование и описание прецедентов
Произведена оценка рисков, связанных с основными прецедентами
Сформулированы в черновом варианте требования к системе
Этап Развитие
Создается базовая архитектура системы
Производится разрешение высоких рисков
Определяется большинство требований (до 80% прецедентов получают развернутое описание)
Полностью разрабатывается некоторый фрагмент системы
Первая итерация
Программная реализация базового сценария прецедента Оформление продажи
Реализация прецедента Включение системы (необходим для предыдущего)
Взаимодействие с внешними службами не реализуется
Словарь предметной области
Register – реестр (терминал)
Item – товар
Store – магазин
Sale – продажа
Sales LineItem – элемент продажи
Cashier –кассир
Customer – покупатель
Manager – менеджер
Словарь предметной области
Payment – платеж
Product Catalog – каталог товаров
Product Specification – спецификация товара
Поведение системы
Это описание действий, выполняемых системой, без детализации механизма их реализации
Для визуального представления поведения системы используют диаграмму последовательностей системы
Диаграмма последовательностей
Системные операции
Диаграмма последовательностей системы позволяет выделить набор системных операций
Операцией называется любое преобразование объекта или запрос к объекту
Операция называется системной, если в качестве объекта выступает система в целом
Описание операций
Операции требуют отдельного описания, если они достаточно сложны и их содержание не раскрыто в описании соответствующего прецедента
Структура описания операции
Категории постусловий
Создание или удаление экземпляра объекта
Модификация атрибута экземпляра объекта
Формирование или разрыв ассоциации
Системные операции POS
Системные операции POS
Концептуальная модель
Отображает наиболее важные для цели моделирования классы понятий (концептуальные классы) предметной области
Кроме того концептуальная модель может отображать
ассоциации между концептуальными классами,
атрибуты концептуальных классов
Классы и атрибуты
Концептуальная модель
Модель проектирования
Созданием концептуальной модели завершается анализ требований в рамках первой итерации
На следующем этапе внимание фокусируется на разработке проектного решения (модели проектирования ), удовлетворяющего требованиям данной итерации
Концептуальные и программные классы
Концептуальная модель содержит концептуальные классы с указанием их атрибутов
Модель проектирования содержит программные классы с указанием их атрибутов и методов
Распределение обязанностей
Основной задачей этапа проектирования является построение логики взаимодействия объектов, обеспечивающей выполнение системных требований
Это достигается путем распределения обязанностей объектов
Знания и действия
Обязанность определяется как контракт объекта и делятся на
знания (наличие информации об инкапсулированных данных, о связанных объектах)
действия (выполнение вычислений, создание экземпляра, инициирование действий других объектов или управление ими)
Реализация обязанностей
Обязанности реализуются посредством методов программных классов
Метод может реализовывать обязанность самостоятельно, либо во взаимодействии с методами других классов
Диаграммы взаимодействия
Для визуализации распределения обязанностей между объектами используют диаграммы взаимодействия двух видов:
диаграммы кооперации,
диаграммы последовательностей
В обоих случаях взаимодействие объектов представляется в виде обмена сообщениями
Шаблоны
Распределение обязанностей подчиняется ряду принципов, обобщающих практический опыт проектирования программных систем
Эти принципы формулируются в виде шаблонов проектирования (design patterns)
Шаблон Expert
Проблема Каков наиболее общий принцип распределения обязанностей?
Решение Назначить обязанность классу, владеющему информацией, необходимой для выполнения обязанности
Формулировка обязанности
Вычислить общую сумму продажи
Какая информация нужна для выполнения этой обязанности?
стоимость каждого вида товаров,
цену каждого вида товаров
Какой класс должен выполнять эту обязанность?
Вычисление общей стоимости
Распределение обязанностей
Класс Sale – эксперт для вычисления общей суммы продажи
Класс Sales LineItem– эксперт для вычисления промежуточной суммы элемента продажи
Класс Product Specification – эксперт для определения цены товара
Диаграмма кооперации
Создание программных объектов
Объекты программных классов должны быть созданы, чтобы их можно было использовать
Проблема Какие классы должны отвечать за создание объектов классов Sale, Sales LineItem, Product Specification?
Шаблон Creator
Выявление объекта-создателя
Шаблон Creator
Определяет способ распределения обязанностей, связанный с процессом создания объектов
Основное назначение – выявление объекта-создателя:
класс-контейнер
класс-регистратор
класс, владеющий информацией, необходимой при инициализации объекта
Диаграмма последовательностей
Обеспечение низкого сцепления
Необходимо создать объект Payment и связать его с объектом Sale
Возможны два альтернативных пути:
объект Payment создается объектом Register, который затем уведомляет об этом объект Sale;
объект Payment создается объектом Sale, который получает соответствующее указание от объекта Register
Два способа создания Payment
Шаблон Low Coupling
Этот шаблон поддерживает независимость классов и слабое сцепление между ними
В соответствии с данным шаблоном предпочтение следует отдать второму способу, т.к. при этом не возникает дополнительной связи между Register и Payment
Шаблон Low Coupling
Высокая степень связности объектов сама по себе не является проблемой
Рекомендуется избегать ее в двух случаях:
для классов, являющихся достаточно общими по своей природе и многократно используемыми;
для неустойчивых и подверженными частому изменению элементов системы
Шаблон High Cohesion
Проблема Как обеспечить управление сложностью?
Решение Распределить обязанности способом, обеспечивающим высокую степень функционального зацепления
Функциональное зацепление – это мера взаимосвязи обязанностей класса
Класс с низкой степенью зацепления выполняет много разнородных функций
Два способа создания Payment
Шаблон High Cohesion
Классы с высокой степенью зацепления просты в понимании, поддержке и повторном использовании
Связывание и зацепление взаимозависимы: неправильное связывание порождает слабое зацепление, и наоборот
Шаблон Controller
Проблема Кто должен отвечать за обработку системных сообщений?
Решение Обязанности по обработке системных сообщений назначаются классу, который:
представляет систему в целом;
представляет сценарий некоторого прецедента, в рамках которого обрабатываются системные сообщения
Контроллеры
Классы, обязанности которых состоят в обработке системных сообщений называются классами контроллера
Классы контроллера не относятся к интерфейсу пользователя
В рассматриваемом примере возможны два варианта решения
1-й вариант
Все системные операции выполняются одним внешним контроллером
2-й вариант
Системные операции распределены между несколькими контроллерами прецедента
Выбор варианта
Выбор между вариантом использования внешнего контроллера (facade controller) и вариантом контроллеров прецедентов определяется, в основном требованиями соблюдения малой связности и высокой степени зацепления
Конец лекции
Использование диаграммы вариантов использования UML при проектировании программного обеспечения
Проектирование – один из важных шагов при разработке программы, который очень часто игнорируется начинающими разработчиками. Обычно они пытаются удержать всё в голове или, в лучшем случае, записать некоторые важные сведения на листе бумаги. Как результат, у них нет чёткого плана дальнейших действий, и проект может быть отложен в долгий ящик.
Обычно при проектировании разработчики изображают систему графически, поскольку человеку легко разобраться в таком представлении. Именно поэтому вместо написания громоздких текстов про каждую возможность будущей программы разработчики строят различные диаграммы для описания своих систем. Это помогает им не забывать, что нужно реализовать в программе, и быстро вводить в курс дела своих коллег.
Сегодня мы разберемся с тем, как использовать диаграмму вариантов использования UML (англ. «Unified Modeling Language») – стандартизированный язык моделирования при проектировании программ.
Данная статья предназначена для начинающих разработчиков и для разработчиков, не знакомых с UML, поэтому никаких предварительных знаний о диаграмме вариантов использования не требуется. Со всеми необходимыми сведениями я познакомлю читателя по ходу статьи.
Когда разработчик создаёт своё приложение, он в первую очередь задумывается над двумя вопросами:
Что будет делать приложение?
Кто будет пользоваться этим приложением?
Некоторыми программами может пользоваться множество людей, поэтому часто необходимо выделять различные группы пользователей системы. У каждой такой группы могут быть свои права и возможности в системе.
Для того чтобы описать различные группы пользователей и их возможности в будущей программе, создаётся так называемая диаграмма вариантов использования.
Диаграмма вариантов использования
Диаграмма вариантов использования (англ. use-case diagram) – диаграмма, описывающая, какой функционал разрабатываемой программной системы доступен каждой группе пользователей.
По ходу этой статьи мы разберём элементы этой диаграммы, которые чаще всего применяются при построении, на множестве небольших примеров диаграмм и на примере одной большой диаграммы. Эта большая диаграмма будет использоваться при проектировании какой-нибудь программной системы. В качестве такой системы давайте выберем информационную систему для школы (можно рассматривать ее как сайт или как отдельное приложение). Пример, разумеется, демонстрационный и не претендует на законченность.
В этой системе можно выделить следующие группы пользователей:
В целом, в реальной жизни директор имеет множество обязанностей (пожалуй, не будем их перечислять). Однако в электронной системе каких-то особенных действий у него нет, поэтому мы не будем изображать его на нашей диаграмме.
Каждая из групп пользователей может пользоваться нашей системой по-своему.
Просматривать свои оценки
Размещать материалы для уроков
Выставлять оценки в электронный журнал
Классные руководители могут делать все то же самое, что и преподаватели плюс:
Составлять расписание родительских собраний
Заместители директора могут:
Публиковать посты с важной информацией
Кроме того, у системы есть функционал, который доступен всем группам пользователей. В разрабатываемой нами системе актуально будет добавить мессенджер, в котором можно будет быстро связываться с интересующим человеком. Получается, эта функциональность должна быть доступна каждому пользователю. Так и запишем. Все пользователи могут:
Получилось много пунктов, которые может быть сложно уложить в голове. Для того чтобы быстро ориентироваться в этих пунктах, мы и хотим научиться строить диаграммы вариантов использования.
А почему мы описываем так мало возможностей?
Заметьте, что на диаграмме мы хотим отобразить только ключевой функционал системы. Например, действия «войти в систему», «выйти из системы» или «восстановить пароль» могут присутствовать в любой системе, и их наличие не стоит дополнительно описывать, поскольку это загрязняет диаграмму несущественными элементами.
Вообще добавление некоторых действий на диаграмме зависит от глубины детализации. Если вам все же требуется изобразить некоторые стандартные действия, ничто не помешает быстро это сделать.
А теперь, когда мы выделили группы пользователей и функциональность системы, начнём строить диаграмму, чтобы зафиксировать и структурировать полученные данные.
Построение диаграммы
Каждая группа пользователей на диаграмме вариантов использования обозначается человечком, под которым записывается имя группы людей, которую он обозначает. Давайте изобразим группу пользователей «Преподаватели»:
Этот человечек обозначает всех преподавателей, которые будут пользоваться системой
Обратите внимание, что имя группы записывается в единственном числе. Символ человечка уже обозначает группу пользователей, поэтому не нужно дополнительно отражать это в имени.
В терминологии UML, этот человечек называется актёром (англ. «actor»). В общем случае, актёр обозначает любые сущности, использующие систему. Этими сущностями могут быть люди, технические устройства или даже другие системы.
Так же изобразим актёров для оставшихся групп пользователей:
Здесь изображены все группы пользователей, которые могут пользоваться нашей системой
Как я упоминал ранее, каждая группа пользователей использует определённые функции системы. На диаграмме вариантов использования функция системы изображается эллипсом, внутри которого записывается имя функции в форме глагола с пояснительными словами.
Этот эллипс представляет действие «Выставить оценки в электронный журнал»
В терминологии UML, этот эллипс называется вариантом использования (англ. «use-case»). В общем случае, вариант использования – набор действий, который может быть использован актёром для взаимодействия с системой.
Связи между элементами
На диаграммах UML для связывания элементов используются различные соединительные линии, которые называются отношениями. Каждое такое отношение имеет собственное название и используется для достижения определённой цели. В качестве справочной информации перечислю все виды отношений, которые мы будем использовать в этой статье.
Отношение ассоциации (англ. «association relationship») 
Отношение обобщения (англ. «generalization relationship») 
Отношение включения (англ. «include relationship») 
Отношение расширения (англ. «extend relationship»)
Отношение ассоциации
Мы хотим отображать на диаграмме информацию о том, какие варианты использования могут быть использованы каждым актёром. Сейчас, например, мы хотим показать, что выставлять оценки могут только преподаватели.
Изображаем на диаграмме информацию о том, что преподаватели могут выставлять оценки
Мы соединили актеров с вариантом использования с помощью сплошной линии без стрелки. Такая линия называется отношением ассоциации.
Отношение ассоциации предназначено только для соединения актёров и вариантов использования. Нет никакого смысла соединять отношением ассоциации двух актёров или два варианта использования.
Изображаем на диаграмме возможность покупателей оплачивать заказы
Если на диаграмме вариантов использования актёр соединен с вариантом использования с помощью отношения ассоциации, это означает, что данный актёр может выполнять действия, описанные вариантом использования.
Почему отношение ассоциации называется так и не иначе?
Чтобы лучше понять это отношение, вспомним, каким образом мы выделяли функционал для различных групп пользователей. Некоторые обязанности у нас ассоциируются с определённой группой людей, поэтому мы связываем актёров с ассоциируемыми с ними действиями.
Добавим еще вариантов использования и соединим их с соответствующими актёрами:
Первая версия диаграммы
Пока что наша диаграмма совсем не впечатляет, поэтому мы продолжим наполнять ее информацией. Заодно мы узнаем все возможности этого вида диаграмм.
Отношение обобщения
Заметим, что в нашей системе группы пользователей «Преподаватель» и «Классный руководитель» обладают схожими возможностями. Чтобы изобразить это на диаграмме, мы можем пойти одним из трёх путей:
Дублировать варианты использования, чтобы связать их с каждым схожим актёром (очевидно, неудачный вариант).
Соединить каждого актёра со всеми нужными вариантами использования. Это может породить множество пересечений линий, что не самым лучшим образом скажется на читаемости диаграммы.
Показать с помощью одного из видов отношений, что актёры связаны между собой. Это будет означать, что один из них может пользоваться всеми вариантами использования, с которыми соединён другой актёр.
Последний вариант похож на принцип повторного использования кода при написании программ или на наследование классов в ООП (Объектно-ориентированное программирование). Преимущество этого варианта в том, чтобы уменьшить количество связей на диаграмме.
Разумеется, мы воспользуемся третьим путём. В этом нам поможет, так называемое, отношение обобщения. Отношение обобщения обозначается сплошной линией с полой треугольной стрелкой.
Отношение обобщения означает, что некоторый актёр (вариант использования) может быть обобщён до другого актёра (варианта использования). Стрелка направлена от частного случая(специализации) к общему случаю.
Ниже представлены несколько примеров использования отношения обобщения.
Покупка горного и скоростного велосипеда — ЧАСТНЫЙ случай покупки велосипеда 
Физическое лицо и юридическое лицо можно ОБОБЩИТЬ до обычного покупателя
Как можно заметить, отношение обобщения используется, чтобы показать, что одно действие является частным случаем другого действия или что одну группу людей можно обобщить до другой группы.
Вернёмся к нашему основному примеру. Изобразим отношение обобщения от актёра «Кл. руководитель» к актёру «Преподаватель».
На рисунке сверху сразу видно, насколько понятнее становится диаграмма при использовании отношения обобщения: исчезли все повторы вариантов использования и пересечения линий. Разумеется, это огромный плюс для тех, кто будет читать эту диаграмму в дальнейшем.
Давайте обратим внимание на действие «Узнать свои оценки». Логично предположить, что обучающиеся захотят не только знать список своих оценок, но и знать свою среднюю оценку за некоторый период времени или среднюю оценку по определённому предмету.
Изобразим это на диаграмме. Для этого создадим два варианта использования «Узнать среднюю оценку за некоторый период времени» и «Узнать среднюю оценку по предмету» и соединим их с вариантом использования «Узнать свои оценки» отношением обобщения.
Уточняем на диаграмме, что у обучающихся есть возможность узнать среднюю оценку за некоторый период времени и средний балл по некоторому предмету
Присоединим это к основной диаграмме:
Вторая версия диаграммы
Отношение включения
Для заместителя директора мы отмечали, что ему нужно составлять расписания. Условно расписание можно поделить на три категории:
Всё это составляется заместителем директора, поэтому покажем это на диаграмме. Для этого будем использовать отношение включения. Отношение включения обозначается пунктирной линией с V-образной стрелкой на конце, над стрелкой добавляется надпись “include”.
В общем случае, отношение включения используется, чтобы показать, что некоторый вариант использования включает в себя другой вариант использования в качестве составной части.
Когда мы используем отношение включения, мы подразумеваем, что составные варианты использования ОБЯЗАТЕЛЬНО входят в состав общего варианта использования.
Поясню смысл и этого отношения на небольшом примере. Когда пользователь сохраняет результаты своей работы в файл, он указывает место сохранения и расширение файла (например, если он редактировал фотографию в photoshop, он может сохранить ее в различных форматах). Этот процесс можно изобразить на диаграмме вариантов использования следующим образом:
Отношение включения используется для изображения составного действия
Снова вернёмся к нашему основному примеру.
Составление расписания ВКЛЮЧАЕТ в себя составление расписания занятий, мероприятий, каникул(обязательно)
Как итог, наша диаграмма принимает следующий вид:
Третья версия диаграммы
В целом, на этом можно остановиться. Хоть наш пример и демонстрационный, он немного отражает функциональность реального приложения. Тем не менее, остался еще один элемент, который мы не рассмотрели.
Отношение расширения
Нужно сказать, что в диаграммах вариантов использования применяется ещё один вид связи – отношение расширения. На мой взгляд, применение отношение расширения несколько специфично, поскольку неправильное его использование может запутать читателя диаграммы. Тем не менее, для полноты картины мы всё равно рассмотрим применение этого отношения на практике. В последний раз модифицируем нашу диаграмму!
Во время дистанционного обучения школьникам необходимо выполнять домашние задания и присылать их в виде архива или фотографий учителям. Получается, нужно добавить возможность прикреплять файл к сообщению в нашей системе. Чтобы отобразить это на диаграмме мы будем использовать отношение расширения. Отношение расширения обозначается пунктирной линией с V-образной стрелкой на конце (похоже на отношение включения), над стрелкой добавляется надпись “extend ”.
Зачем над пунктирными линиями добавлять надписи “include” и “extend”?
В UML пунктирная линия с V-образной стрелкой, в общем случае, называется отношением зависимости. Для диаграммы вариантов использования выделяют различные виды зависимостей: отношение включения и отношение расширения. Чтобы их различать, над стрелками пунктирной линией пишут “include” и “extend” соответственно.
Чтобы лучше понять этот тип отношений рассмотрим пример. Допустим, вы делаете заказ в сети быстрого питания. Вы хотите заказать бургер. Вам, скорее всего, вам предложат расширить ваш заказ картошкой фри или соусом. Давайте изобразим процесс заказа на диаграмме вариантов использования.
На диаграмме предполагается, что к заказу МОЖЕТ БЫТЬ добавлена картошка фри или соус (необязательно)
Два нижних варианта использования описывают возможные «расширения» для базового варианта использования. Исходя из этого примера, мы можем сделать важное замечание.
Можно сказать, что отношение расширения — это выборочное отношение включения. Если отношение включения обозначает, что элемент обязательно включается в состав другого элемента, то в случае отношения расширения это включение необязательно.
Понимание этого критически важно для грамотного использования этого вида отношений.
Вернёмся к нашему основному примеру. Мы хотим, чтобы действие «прикрепить файл к сообщению» расширяло действие «отправить сообщение». На диаграмме это изображается следующим образом:
Расширяем функционал отправки сообщений с помощью функции прикрепления файлов к сообщению (Необязательно прикреплять файл к каждому сообщению)
Как итог, получим такую диаграмму:
Четвёртая версия диаграммы
Вот и всё. Я постарался рассказать вам про все моменты построения диаграммы вариантов использования при проектировании программных систем. В следующем вашем проекте обязательно попробуйте построить данную диаграмму на стадии проектирования. Ваши усилия обязательно окупятся!
Что делать, если я путаюсь в направлении стрелок?
При построении диаграмм UML часто возникает путаница, в какую сторону направлена та или иная стрелка. Это пройдёт после небольшой практики. Общая рекомендация к запоминанию правильного направления стрелок на диаграмме вариантов использования: стрелка обычно направлена от «зависимого» объекта к «независимому» (от специального к общему). Например:
Проектирование программы ЗАВИСИТ от составления функциональных требований, обдумывания функционала программы, выделения групп пользователей ,потому что ВКЛЮЧАЕТ в себя эти этапы
Программист на каждом следующем уровне должности ПЕРЕНИМАЕТ знания с предыдущих уровней, без которых не может развиваться дальше. Получается, что актёры ЗАВИСЯТ от предыдущих ступеней
Тем не менее, в любом правиле есть исключение. Этим исключением является отношение расширение:
Если DLC было куплено, то игра зависит от контента, который содержится в нём. Наше правило «зависимости» рушится 🙁
Диаграммы очень просто изменять. Не нужно пугаться того, что требования к программе могут измениться или что вы что-то забыли отобразить на диаграмме. Вы можете добавить элементы к диаграмме, когда вам угодно.
Не нужно засорять диаграмму слишком мелкими действиями. Объедините все общие действия в одну группу под общим названием, чтобы было просто читать диаграмму.
Старайтесь не допускать пересечений соединительных линий. Это может затруднить чтение диаграммы для вас и для ваших коллег.
Не дублируйте варианты использования на диаграмме. Если приходится дублировать варианты использования, то элементы диаграммы надо постараться расставить по-другому.
Пользуйтесь специальными компьютерными программами для построения диаграмм. Это существенно упростит весь процесс моделирования.