Основной и альтернативный потоки событий

Конкретные детали вариантов использования отражены в основном (правильном) и альтернативных (дополнительных) потоках событий.

Поток событий – это поэтапное описание того, что происходит во время выполнения варианта использования.

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

· Процедуру начала варианта использования.

· Различные этапы исполнения варианта.

· Нормальный (основной) поток событий в варианте.

· Все отклонения (альтернативы) от основного потока событий.

· Все потоки ошибок.

· Процедуру завершения варианта использования.

Нормальный поток описывает наилучший сценарий, либо наиболее используемый путь исполнения варианта использования.

Альтернативный поток событий (расширение extended) специфицирует отклонения от основного потока, которые не рассматриваются как ошибочные.

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

Рассмотрим пример с вариантом использования «Покупка авиабилета» и обсудим потоки по каждому из сценариев [2].

 

Основной поток событий

Этапы основного потока событий:

1. Вариант использования начинается с выбора клиентом режима показа информации о рейсах.

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

3. Клиент вводит название городов отправления и назначения, дату вылета и возвращения.

4. Система показывает список доступных рейсов, включая стоимость билетов. А1.

5. Пользователь выбирает рейс, на который он хотел бы зарезервировать билет.

6. Система показывает все доступные варианты стоимости билетов на этот рейс.

7. Пользователь выбирает категорию билета для резервирования. А2 .

8. Система показывает цену, которую должен заплатить пользователь.

9. Пользователь подтверждает цену.

10. Система запрашивает тип кредитной карточки, ее номер, имя владельца и дату завершения срока действия.

11. Пользователь вводит тип кредитной карточки, ее номер, имя владельца и дату завершения срока действия.

12 Система подтверждает продажу по кредитной карточке. А6. А7.Е1 .

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

14. Система генерирует и показывает пользователю код подтверждения.

15. Пользователь подтверждает получение кода.

16. Вариант использования завершается.

Альтернативные потоки событий

А1: Нет нужного рейса. В этом случае:

1. Система выводит сообщение, что для введенных города отправления и назначения, а также для указанных дат на рейсах авиакомпании мест нет.

2. Пользователь подтверждает просмотр сообщения.

3. Поток возвращается на этап 2 основного потока событий.

А2: Пользователь выбрал бесплатный билет, предоставляемый членам клуба постоянных клиентов. В этом случае:

1. Система запрашивает идентификационный номер в клубе постоянных клиентов.

2. Пользователь вводит этот номер.

3. Система подтверждает правильность введенного номера. А3.

4. Система подтверждает, что расстояние, которое налетал пользователь на самолетах авиакомпании, позволяет предоставить бесплатный билет.. А4. А5.

5. Цена билета устанавливается в $0.

6. Поток возвращается на этап 8 основного потока.

А3: Неправильный идентификационный номер. В этом случае:

1. Система выводит сообщение о некорректном идентификационном номере.

2. Пользователь повторяет ввод номера или отказывается от запроса на бесплатный билет.

3. Если пользователь повторяет ввод номера, то поток возвращается на этап 1 альтернативного потока А2.

4. Если пользователь отказывается от запроса на бесплатный билет, то поток возвращается на этап 6 основного потока.

А4: Недостаточное расстояние для предоставления бесплатного билета. В этом случае:

1. Система выводит сообщение о том, что расстояние недостаточно для предоставления бесплатного билета. В сообщении указано это расстояние и расстояние, необходимое для предоставления бесплатного билета.

2. Поток возвращается на этап 6 основного потока событий.

А5: Нет бесплатных билетов. В этом случае:

1. Система выводит сообщение о том, что бесплатные билеты на выбранный рейс не предоставляются.

2. Поток возвращается на этап 6 основного потока событий.

А6: Счет пользователя не обнаружен. В этом случае:

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

2. Поток возвращается на этап 10 основного потока событий.

А7: Недостаточно денег на счете. В этом случае:

1. Система выводит сообщение о том, что остаток на кредитной карточке не позволяет завершить транзакцию.

2. Поток возвращается на этап 10 основного потока событий.

Потоки ошибок

Е1: Кредитная система недоступна. В этом случае:

1. Система выводит сообщение о недоступности кредитной системы.

2. Поток возвращается на этап 10 основного потока событий.

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

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

Уровень детализации

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

1. Заказчики. Документ о потоке событий должен быть детализирован настолько, чтобы разработчик и пользователи системы имели одинаковое его видение. Другими словами: «Уровень детализации должен быть настолько высоким, чтобы без него стала невозможной реализация».

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

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

Постусловия

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

Отношения

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

Ассоциативные отношения

Отношения между действующими лицами (акторами) и вариантами использования ассоциативны. В UML ассоциативные отношения показывают стрелкой:

 

В этом примере вариант использования инициирует взаимодействие с действующим лицом «кредитная система». Во время исполнения варианта использования «Продажа билетов» система бронирования инициирует обращение к кредитной системе для проверки кредитной карточки и завершения транзакции. Хотя информация передаётся в обоих направлениях (к кредитной системе и от неё к варианту использования), стрелка направлена от того объекта, который инициирует коммуникацию. Любой вариант использования обязан инициироваться действующим лицом.

Включающие отношения

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

Включающие отношения обозначаются стрелкой, направленной к общему (меньшему) варианту использования, и помечаются стереотипом «include» (см. рис.5.10).

 

Рис. 5.10. Включающее отношение:

1- включение «меньшего» варианта использования; 2- включение «общего» варианта использования.

 

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

Существует ещё одна трактовка отношения включения, использующая понятие абстрактный вариант использования. Процесс уточнения модели требований сводится к выявлению одинаковых частей (одинаковых потоков событий) в вариантах использования всей системы, и извлечения этих частей в отдельный вариант использования. Любые изменения в таком варианте использования будут автоматически влиять на все варианты, которые совместно используют его. Таким образом извлечённый вариант использования будет абстрактным. Абстрактные варианты не могут быть конкретизированы сами по себе, поскольку применяются для описания одинаковых частей в других, конкретных вариантах использования. Говорят, что конкретный вариант использования находится в отношении «включает» с абстрактным. Например, абстрактный вариант использования «Печать» для двух конкретных вариантов использования: «Оформление договора» и «Создание отчёта, специализируется на выполнении распечаток.

Более того, абстрактные элементы могут использоваться другими абстрактными вариантами использования, образуя иерархию. При построении иерархии абстрактных вариантов использования следует руководствоваться правилом: выделение таких элементов прекращается как только достигается уровень отдельных операций над объектами (по аналогии с функциональной декомпозицией).

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

Абстрактный актор – это общий фрагмент роли в нескольких конкретных акторах. Он служит для показа существования конкретных акторов.

Абстрактный актор выражает подобия в вариантах использования. Конкретные акторы находятся в отношении обобщения (как форма наследования) с абстрактным актором. Как показано на рис.5.11, наследниками Клиента являются действующие лица: Корпоративный клиент и Действующий клиент.

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

 

Рис.5.11. Обобщенные отношения действующих лиц

 

Расширяющие отношения

Приведём пример работы базового варианта использования " Сеанс работы" с другими, которые добавляются как расширяемые (рис.5.12).

Рис.5.12. Применение отношения расширения

 

Здесь мы видим только один базовый вариант использования, а другие три, добавлены как расширения, причём базовый вариант при этом остаётся почти без изменений. Отношение расширения определяет прерывание исполнения базового варианта в некоторой точке, называемой точкой расширения, для вставки в эту точку другого варианта использования, при этом базовый вариант не знает, будет выполняться прерывание или нет. Вычисление условий прерывания (расширения) происходит не в базовом варианте использования, а в реальном процессе, моделирование которого осуществляется данными вариантами использования.

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

Обычно расширения используются:

· для моделирования вариантных частей вариантов использования;

· для моделирования сложных и редко выполняемых альтернативных последовательностей событий;

· для моделирования подчинённых потоков событий, которые выполняются только в определённых случаях;

· для моделирования систем с выбором на основе меню.

Главное, что следует помнить: решение о выборе и подключении расширяющего варианта использования принимается вне базового варианта использования. В случае ввода в базовый вариант условной конструкции if либо конструкции выбора case, switch , придётся применять отношение включения (include). Это как раз тот случай, когда право выбора находится в компетенции базового варианта использования.

 

Обобщённые отношения

Обобщённые отношения служат для показа общих черт вариантовиспользования или действующих лиц. Не всегда необходимо формировать обобщенные отношения. В общем случае, они необходимы только тогда, когда необходимо подчеркнуть различия в поведении разных действующих лиц с точки зрения анализа системы. Если корпоративный клиент будет инициировать некоторые варианты использования, которые не способен инициировать индивидуальный клиент, то обычно не требуется обобщения действующего лица (актора). Обобщение не потребуется, если оба типа клиентов выполняют одинаковые варианты использования, но немного по-разному, если же оба типа клиентов выполняют одинаковые варианты использования, возможно, потребуется обобщение. Такие небольшие отличия документируются в потоке событий нужного варианта использования.

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

Другими словами, создаётся «пустой» обобщённый базовый (родительский) вариант использования для основного события и специализированный вариант использования для каждого изменения. Пустой обобщённый базовый вариант использования указывает на «что», но не говорит «как». В каждом специализированном варианте использования определяются его собственные события, как это делается. На рис.5.13, представлен пример такой нотации UML.

 

Рис.5.13. Обобщенные отношения вариантов использования

5.4.2. Диаграммы вариантов использования

Диаграмма Вариантов Использования показывает некоторые варианты использования в системе некоторых действующих лиц, и отношения между ними. Диаграмма представляет высокоуровневое описание системы (архитектуру системы), причём действующим лицом становится все и всё, что взаимодействует с разрабатываемой системой. Пример диаграммы Вариантов использования показан на рис 5.14. На диаграмме видны системные действующие лица, системные варианты использования и отношения между ними. Данная система предназначена для интерактивных и телефонных продаж авиабилетов, поэтому Клиент и Представитель службы сервиса могут инициировать одинаковые варианты использования. На диаграмме присутствуют включающие и одно расширяющее отношения. Вся функциональность системы может быть представлена набором из восьми вариантов использования: Приобретение билетов, Изменение заказа, Проверка кредита, Отказ от заказа, Просмотр маршрута пользователя, Бронирование номера в отеле, Заказ на аренду автомобиля и Установка расписания авиарейсов.

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

 

Рис.5.14. Пример диаграммы вариантов использования

 

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

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

 

В заключение данного раздела приведём ряд рекомендаций по созданию Диаграмм Вариантов использования:

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

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

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

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

· Базу данных, как обязательный компонент любой системы, следует считать уровнем, находящимся ниже всей диаграммы Вариантов использования (такое же положение распространяется и на диаграммы классов). Можно ввести информацию в базу данных в одном варианте использования, а затем получать эту информацию в другом. В этом случае не нужно показывать информационный поток между этими двумя вариантами использования.

· Хотя диаграмма является полезным артефактом разработки, без неё можно обойтись. При разработке вариантов использования не стоит прилагать много усилий для создания диаграммы вариантов использования. Вместо этого лучше сконцентрироваться на текстовом описании содержания вариантов использования;

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

 

5.4.3. Анализ вариантов использования

В данном разделе рассмотрим методику визуального моделирования

с использованием языка UML, для примера, представленного в прекрасной монографии Лешека А. Мацяшек [16], и связанного с работой Internet-магазина по продаже компьютеров. Цель состоит в том, чтобы продемонстрировать, каким образом функциональные требования отображаются непосредственно в варианты использования, а моделирование вариантов использования - приводит к моделированию классов системы.

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

Нашей задачей является: получить информацию (наставление) по работе магазина и обработке заказов клиентов; сформулировать функциональные требования и для каждого из них определить и специфицировать варианты использования для выделенных потоков событий; завершить анализ вариантов использования моделированием классов проектируемой системы.

Содержание наставления : Обработка заказов клиентов

Производитель компьютеров предлагает возможность приобретения своей продукции через Internet. Клиент может выбрать компьютер на Web-странице производителя. Компьютеры подразделяются на серверы, настольные и портативные. Заказчик может выбрать стандартную конфигурацию или построить требуемую конфигурацию в диалоговом режиме. Компоненты конфигурации представляются как список для выбора из доступных альтернатив. Для каждой новой конфигурации система может подсчитать цену.

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

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

1. Для знакомства со стандартной конфигурацией выбираемого сервера, настольного или портативного компьютера клиент использует Web-страницу Internet- магазина. При этом также приводится цена конфигурации.

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

3. Клиент может выбрать вариант заказа компьютера по Internet либо попросить, чтобы продавец связался с ним для объяснения деталей заказа, договорился о цене и т.п., прежде, чем заказ будет фактически размещён.

4. Для размещения заказа клиент должен заполнить электронную форму с адресами для доставки товара и отправки счет - фактуры, а также деталями, касающимися оплаты (кредитная карточка или чек).

5. После ввода заказа клиента в систему продавец отправляет на склад электронное требование, содержащее детали заказанной конфигурации.

6. Детали сделки, включая номер заказа, номер счёта клиента, отправляются по электронной почте клиенту, так что заказчик может проверить состояние заказа через Internet.

7. Склад получает счёт-фактуру от продавца и отгружает компьютер клиенту.

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

Таблица 5.4

Распределение требований по действующим лицам и вариантам использования

№	Требование	Действующее лицо	Вариант использования
	Для знакомства со стандартной конфигурацией выбираемого сервера, настольного или портативного компьютера клиент использует Web-страницу Internet- магазина. При этом также приводится цена конфигурации.	Клиент	Отображение стандартной конфигурации компьютера
	Клиент выбирает детали конфигурации, с которыми он хочет познакомиться, возможно, с намерением купить готовую или составить более подходящую конфигурацию. Цена для каждой конфигурации может быть подсчитана по требованию пользователя.	Клиент	Составление конфигурации компьютера
	Клиент может выбрать вариант заказа компьютера по Internet либо попросить, чтобы продавец связался с ним для объяснения деталей заказа, договорился о цене и т.п., прежде, чем заказ будет фактически размещён.	Продавец, Клиент	Заказ сконфигурированного компьютера
	Для размещения заказа клиент должен заполнить электронную форму с адресами для доставки товара и отправки счет-фактуры, а также деталями, касающимися оплаты (кредитная карточка или чек).	Клиент	Проверка и приём платежа от клиента
	После ввода заказа клиента в систему продавец отправляет на склад электронное требование, содержащее детали заказанной конфигурации.	Продавец, Склад	Информирование склада о заказе
	Детали сделки, включая номер заказа, номер счёта клиента, отправляются по электронной почте клиенту, так что заказчик может проверить состояние заказа через Internet.	Продавец, Клиент	Обновление состояния заказа
	Склад получает счёт-фактуру от продавца и отгружает компьютер клиенту.	Продавец, Склад	Печать счёт-фактуры

 

Каждый вариант использования должен быть описан с помощью документально зафиксированного потока событий. Этот документ определяет, что должна делать система, когда актор инициирует вариант использования. Этот документ будут развиваться по ходу разработки постепенно и инкрементно. В конце этапа спецификации требований документ может быть дополнен прототипами GUI-экранов.

Теперь подготовим документ, содержащий описание варианта использования " Заказ сконфигурированного компьютера" (табл.5.5)

Таблица 5.5

Описательная спецификация

варианта использования " Заказ сконфигурированного компьютера"

Вариант использования	Заказ сконфигурированного компьютера
Краткое описание	Вариант использования даёт возможность Клиенту ввести заказ на покупку. Заказ включает адреса доставки товара и оплаты счёта, а также детали условий оплаты.
Акторы	Клиент
Предусловие	Клиент с помощью Internet-браузера выбирает страницу производителя компьютеров для ввода заказа. На Web-странице отображается подробная информация о сконфигурированном компьютере вместе с его ценой.
Основной поток событий	Начало варианта использования совпадает с решением клиента заказать сконфигурированный компьютер с помощью выбора функции (или аналогичной функции) при отображении на экране детализированной информации, относящейся к заказу. Система просит клиента ввести детали покупки, в том числе: имя продавца (если оно известно); детали, касающиеся доставки (имя и адрес клиента); детальную информацию по оплате (если она отличается от информации о доставке); способ оплаты (кредитная карточка или чек) и произвольные комментарии. Клиент выбирает функцию Покупка (или аналогичную) для отправки заказа производителю. Система присваивает уникальный номер заказа и клиентский учётный номер заказу на покупку и запоминает информацию о заказе в базе данных. Система отправляет клиенту по электронной почте номер заказа и клиентский номер клиенту вместе со всеми деталями, относящимися к заказу, в качестве подтверждения принятия заказа.
Альтернативные потоки событий	Клиент инициирует функцию Покупка до того, как введёт всю обязательную информацию. Система отображает на экране сообщение об ошибке и просит ввести пропущенную информацию. Клиент выбирает функцию Сброс (или аналогичную) для того, чтобы вернуться к исходной форме заказа на покупку. Система даёт возможность Клиенту вновь ввести информацию.
Постусловие	Если выполнение варианта использования было успешным, детали заказа на покупку записываются в базу данных. В противном случае состояние системы остаётся неизменным

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

Приведённые рассуждения основаны на том, что систему образует системное состояние. Состояние является функцией содержимого системной информации в заданный момент времени - это функция системного текущего набора объектов-экземпляров классов. Определение внутреннего состояния системы даётся в модели классов. Таким образом, нам необходимо, используя спецификации всех вариантов использования, идентифицировать классы системы, что и представлено в таблице 5.6.

Таблица 5.6

Соответствие функциональных требований, вариантов использования и классов сущностей (Internet-магазин)

№	Требование	Вариант использования	Классы -сущности
	.Для знакомства со стандартной конфигурацией выбираемого сервера, настольного или портативного компьютера клиент использует Web-страницу Internet- магазина. При этом также приводится цена конфигурации.	Отображение стандартной конфигурации компьютера	Клиент, Компьютер, Стандартная конфигурация, Товар
	Клиент выбирает детали конфигурации, с которыми он хочет познакомиться, возможно с намерением купить готовую или составить более подходящую конфигурацию. Цена для каждой конфигурации может быть подсчитана по требованию пользователя.	Составление конфигурации компьютера	Клиент, Сконфигурированный компьютер, Укомплектованный товар, Элемент конфигурации
	Клиент может выбрать вариант заказа компьютера по Internet либо попросить, чтобы продавец связался с ним для объяснения деталей заказа, договорился о цене и т.п., прежде, чем заказ будет фактически размещён.	Заказ сконфигурированного компьютера	Клиент, Заказ, Продавец, Сконфигурированный компьютер
	Для размещения заказа клиент должен заполнить электронную форму с адресами для доставки товара и отправки счет-фактуры, а также деталями, касающимися оплаты (кредитная карточка или чек).	Проверка и приём платежа от клиента	Поставка, Счёт-фактура, Платёж, Клиент, Заказ
	После ввода заказа клиента в систему продавец отправляет на склад электронное требование, содержащее детали заказанной конфигурации.	Информирование склада о заказе	Клиент, Заказ, Продавец, Сконфигурированный Компьютер, Элемент конфигурации
	Детали сделки, включая номер заказа, номер счёта клиента, отправляются по электронной почте клиенту, так что заказчик может проверить состояние заказа через Internet.	Обновление состояния заказа	Заказ, Клиент Состояние заказа
	Склад получает счёт-фактуру от продавца и отгружает компьютер клиенту	Печать счёт-фактуры	Счёт-фактура, Поставка

Процедура выделения классов представляет собой итеративный процесс, и первоначальный перечень предполагаемых классов-сущностей, как правило, претерпевает изменения (Методики определения классов мы рассмотрели в главе 4 учебника). Выделенные в таблице классы – сущности могут вызвать некоторые сомнения. К примеру, следует задаться такими вопросами.

1. В чём различие между классами Сконфигурированный компьютер и Заказ? Наверное, нет смысла хранить информацию о сконфигурированном компьютере, пока заказ не размещён?

2. Совпадает ли смысл понятия Поставка, приведённый в требованиях 4 и 7? Необходим ли нам этот класс, если известно, что поставка является обязанностью склада и, таким образом, выходит за рамки приложения?

3. Не является ли понятие элемент конфигурации просто атрибутом понятия сконфигурированный компьютер?

4. Является ли понятие состояния заказа самостоятельным классом или же атрибутом класса Заказ?

5. Является ли понятие продавец самостоятельным классом или же атрибутом классов Заказ и Счёт-фактура?

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

С учётом сделанных замечаний, можно придти к следующей диаграмме классов для приложения Internet-магазин (рис. 5.15).

 

⇐ Предыдущая10111213141516171819Следующая ⇒

Поделиться: