Отношение зависимости

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

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

рис. 11. Зависимости

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

Отношение ассоциации

Ассоциацией(Association) называется структурное отношение, показывающее, что объекты одного типа неким образом связаны с объектами другого типа. Если между двумя классами определена ассоциация, то можно перемещаться от объектов одного класса к объектам другого. Вполне допустимы случаи, когда оба конца ассоциации относятся к одному и тому же классу. Это означает, что с объектом некоторого класса позволительно связать другие объекты из того же класса. Ассоциация, связывающая два класса, называется бинарной. Можно, хотя это редко бывает необходимым, создавать ассоциации, связывающие сразу несколько классов; они называются n-арными. Графически ассоциация изображается в виде линии, соединяющей класс сам с собой или с другими классами. Используйте ассоциации, когда хотите показать структурные отношения. На рис. 12 изображено отношение ассоциации между актером «Клиент» и прецедентом «Сделать заказ».

рис. 12. Отношение ассоциации

Стереотип

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

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

рис. 13. Стереотипы

Шаблон описания прецедента Прецедент п1. Оформление продажи

[Наименованиепрецедента]

Статус.

В разработке.

[Статус сценария: в разработке, готов к проверке, в процессе проверки, подтвержден, отвергнут.]

Основной исполнитель. Кассир.

[Основной исполнитель – его задачи выполняются с использованием системы.]

Заинтересованные лица и их требования.

• Кассир. Хочет точно и быстро ввести данные, не допуская ошибок в платеже, поскольку недостача вычитается из его зарплаты.

• Продавец. Хочет получить свои комиссионные от продажи.

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

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

• Государственные налоговые службы. Хотят получать налог с каждой продажи.

[ Список заинтересованных лиц и их требований помогает понять, что должна делать система. Так как «система реализует соглашение между заинтересованными лицами».]

Предусловия.

Кассир идентифицирован и аутентифицирован.

[Предусловия – это перечень предпосылок, которые всегда должны выполняться до начала сценария прецедента. Предусловия не проверяются при реализации прецедента. То есть это условия, которые считаются истинными.]

Результаты (постусловия).

Данные о продаже сохранены. Налоги корректно вычислены. Бухгалтерские и складские данные обновлены. Комиссионные начислены. Чек сгенерирован. Авторизация платежа выполнена.

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

Основной процесс.

1. Покупатель подходит к кассовому аппарату с выбранными товарами.

2. Кассир открывает новую продажу.

3. Кассир вводит идентификатор товара.

4. Система записывает наименование товара и выдает его описание, цену и общую стоимость. Цена вычисляется на основе набора правил.

Кассир повторяет действия, описанные в пп. 3-4, для каждого наименования товара.

5. Система вычисляет общую стоимость покупки с налогом.

6. Кассир сообщает покупателю общую стоимость покупки и предлагает оплатить покупку.

7. Покупатель оплачивает покупку, система обрабатывает платеж.

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

9. Система выдает товарный чек.

10. Покупатель покидает магазин с чеком и товаром (если он что-то купил).

[Основной процесс – это типичная последовательность действий, приводящая к успешному завершению сценария и удовлетворяющая потребностям всех заинтересованных лиц. Чаще всего в этом разделе нет никаких условий и ветвлений.]

Альтернативные потоки.

*а. При каждом выходе системы из строя.

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

1. Кассир перезапускает систему, регистрируется и предлагает восстановить предыдущее состояние.

2. Система восстанавливает предыдущее состояние.

2а. Система определяет аномалию, повлекшую сбой.

1. Система уведомляет об ошибке кассира, регистрирует ошибку и переходит в начальное состояние.

2. Кассир начинает новую продажу.

3а. Неправильный идентификатор товара.

1. Система уведомляет об ошибке и отменяет ввод данного наименования товара.

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

1. Кассир может ввести идентификатор категории товара и количество единиц.

3-6а. Покупатель просит кассира отменить покупку одного из товаров.

1. Кассир водит идентификатор товара для удаления его из продажи.

2. Система отображает обновленную промежуточную стоимость.

3-6б. Покупатель просит кассира отменить продажу.

1. Кассир отменяет продажу.

3-6в. Кассир приостанавливает продажу.

2. Система записывает данные о продаже таким образом, чтобы они были доступны с любого терминала системы.

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

1. Кассир вводит команду об изменении цены.

2. Система вычисляет новую цену.

5а. Система выявляет сбой при коммуникации с внешней службой вычисления налога.

1. Система перезапускает службу с данного узла и продолжает работу.

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

1. Система сигнализирует об ошибке.

2. Кассир может вручную вычислить и ввести сумму налога либо отменить продажу.

5б. Покупатель сообщает о положенной ему скидке (например, для сотрудников данного предприятия или для постоянных покупателей).

1. Кассир отправляет запрос на скидку.

2. Кассир вводит идентификационные данные покупателя.

3. Система предоставляет сумму скидки, вычисленную на основе дисконтных правил.

…

7б. Оплата по кредитной карточке.

1. Покупатель вводит информацию о своей кредитной карточке.

2. Система отправляет запрос на авторизацию платежа внешней системе службы авторизации платежей и запрашивает подтверждение платежа.

2а. Система определяет сбой при взаимодействии с внешней системой.

1. Система сигнализирует об ошибке кассиру.

2. Кассир просит покупателя изменить тип платежа.

3. Система получает информацию о подтверждении платежа и сообщает об этом кассиру.

3а. Система получает информацию об отказе в выполнении платежа.

1. Система сообщает об отказе кассиру.

2. Кассир просит покупателя изменить тип платежа.

2. Система регистрирует платеж по кредитной карточке, включая информацию о подтверждении платежа.

3. Система предоставляет механизм ввода подписи для платежа по кредитной карточке.

4. Кассир просит покупателя подписать чек на оплату по кредитной карточке. Покупатель вводит подпись.

…

9а. Генерация чека.

1. Система выводит формы и чеки для каждого товара.

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

1. Кассир вводит запрос на подарочный чек, и система выдает его.

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

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

3а. Неправильный идентификатор.

1. Система уведомляет об ошибке и отменяет ввод товара.

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

1. Кассир может ввести идентификатор категории товара и количество единиц.

Описание расширения состоит из двух частей: условия и способа его обработки. Описывайте условия как факты, выявляемые системой или исполнителем.

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

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

7б. Точка расширения (Оплата по кредитной карточке).

Если необходимо записать условия, которые могут возникнуть в любой момент, то в обозначении пункта можно использовать символ «*».]

Специальные требования.

• Сенсорный экран с интерфейсом пользователя для большого плоского монитора. Текст должен быть виден с расстояния 1 метр.

• Отклик службы авторизации в 90% случаев проходит в течение 30 секунд.

• Возможность локализации (предоставления на различных языках) отображаемого текста.

• …

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

Однако на практике этот раздел помещают в один общий документ «Дополнительная спецификация», так как их удобнее читать и осмысливать, поскольку они рассматриваются в общем контексте в процессе анализа архитектуры.]

Список технологий и типов данных.

3а. Идентификатор товара считывается со штрих-кода (при наличии последнего) лазерным сканером, или вводится с клавиатуры.

3б. Идентификатор товара может определяться по схемам кодирования UPC,EAN,JANилиSKU.

…

[Здесь описываются технические ограничения, выдвигаемыми заинтересованными лицами для технологий ввода и вывода. А также возможные варианты типов данных, например, различных кодировок идентификации товаров. ]

Частота использования.

Почти постоянно.

[Частота использования прецедента.]

Открытые вопросы.

• Изучить законодательство по налогообложению.

• Исследовать вопрос восстановления удаленных служб.

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

• Должен ли кассир снимать кассу при выходе из системы.

[Список открытых вопросов, которые требуют ответа.]

Расширяемые варианты использования.

[Список расширяемых вариантов использования]

Включаемые варианты использования.

[Список включаемых вариантов использования]

14