Визуальное моделирование при анализе и проектировании. Основы Unified Modeling Language (UML)

5. Учебный пример. Постановка задачи

5.1. Система бронирования билетов для авиакомпании

5.1.1. Краткое описание

На рынок вышла новая авиакомпания "GlobalAvia". Менеджеры компании решили заказать у вашей фирмы разработку системы бронирования билетов. При заказе фирма поставила ряд условий, которые обязательно должны быть выполнены. В первой версии системы они хотят видеть две части. Работа первой части системы связана с занесением информации. Вторая часть системы предназначена для общения с клиентами.

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

5.1.2. Анализ постановки - полное описание

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

Объекты системы: распределенное хранилище рейсов, покупатель билетов, менеджер рейсов.

• Распределенное хранилище рейсов: название рейсов, номера и стоимость билетов.
• Покупатель: ФИО, сумма. Покупатель задает параметры, связанные с суммой, которую он хочет потратить. Система должна подобрать оптимальный маршрут. При отсутствии прямых маршрутов система должна попробовать найти маршруты с пересадками. Если таковых не находится, система должна сказать, что с такими ограничениями нельзя добраться до места назначения.

Среди причин:

• Отсутствие рейсов в желаемом направлении даже с учетом пересадок.
• Нехватка денег.

В ответ, пользователь должен иметь возможность поменять параметры с учетом предыстории.

Менеджер рейсов: должен иметь следующие возможности:

• создания и удаления аэропортов в системе.
• создания и удаления рейсов в аэропортах.

6. Визуальное описание функциональной модели средствами UML

6.1. Актеры и варианты использования в UML

Программная система не функционирует сама по себе. Программная система функционирует под воздействием актеров (Actor) - пользователей, машин и других программ. При этом актер ожидает, что система ведет себя строго определенным образом. Актер оказывает воздействие - система выдает ожидаемый результат. В случае, если ожидаемого результата нет, требования пользователя не удовлетворены со всеми вытекающими отсюда результатами. Таким образом, актер в UML - человек, машина или программа, воздействует на систему, является внешним по отношению к ней. Модель того, как воздействие приводит к результату, называется Вариантом использования (Use case). Актеры и варианты использования имеют специальные обозначения в UML:

Рис. 3.5.

Актеры и варианты использования общаются посредством посылки сообщений. Сообщения могут идти в обе стороны. Стрелка показывает инициатора общения (актер на рисунке) и может быть опущена.

Рис. 3.6.

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

Перечень Вариантов использования для нашей задачи может быть, например, таким:

• Забронировать билет.
• Подобрать рейс.
• Работать с данными.
• Управлять рейсами.
• Работать с БД аэропорта.

Для визуального представления актеров, вариантов использования и отношений между ними в UML предусмотрена специальная диаграмма - диаграмма вариантов использования. Ниже приведена диаграмма для рассматриваемого примера:

Рис. 3.7.

Приведем некоторые дополнительные соображения [3.3]:

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

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

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

Приведем пример соответствующей диаграммы для варианта использования Бронирование билетов в системе SRS.

Рис. 3.8.

7. Структура системы и ее описание средствами UML

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

7.1. Классы

Рис. 3.9.

Обозначения модификаторов доступа:

7.2. Шаблоны классов

Рис. 3.10.

7.3. Объекты

Рис. 3.11.

7.4. Интерфейсы

Определимся с тем, что мы в данном случае понимаем под Интерфейсом.

Интерфейс определяет границу между спецификацией того, что делает абстракция, и реализацией того, как она это делает [3.3].

Интерфейс - это набор операций, используемых для специфицирования услуг, предоставляемых классом или компонентом [3.3].

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

Во многих языках программирования понятие Интерфейс включено в объектную модель, что сообразно отражается на синтаксисе (Object Pascal, Java и др.). С++, к сожалению, не содержит понятия Интерфейс, поэтому Интерфейсы моделируются посредством использования классов.

увеличить изображение
Рис. 3.12.