Особенности спецификации функциональных требований на диаграмме вариантов использования
Для иллюстрации особенностей спецификации функциональных требований на диаграмме вариантов использования можно рассмотреть модель обычного банкомата. Процесс функционирования этой системы хорошо знаком владельцам кредитных карточек, поэтому не требует дополнительного описания. Особенность отечественных банкоматов состоит в том, что в них отсутствует возможность перевода средств с одного счета на другой. Рассматриваемая система имеет двух актеров, один из которых является клиентом банкомата, а другой - Банком, который осуществляет выполнение соответствующих транзакций. Каждый из этих актеров взаимодействует с банкоматом, хотя главный актер Клиент, поскольку именно он инициирует функциональность банкомата.
Основные функциональные требования к банкомату заключаются в предоставлении клиенту возможности снятия наличных по кредитной карточке и получении справки о состоянии счета. Именно эти функциональные требования специфицируются отдельными вариантами использования, которые служат ключевыми элементами соответствующей концептуальной модели. Поскольку для выполнения этих вариантов использования необходимо аутентифицировать кредитную карточку, они оба обращаются к дополнительному сервису "Проверка ПИН-кода кредитной карточки". Как следует из существа выдвигаемых к банкомату функциональных требований, этот сервис может выступать в качестве отдельного варианта использования разрабатываемой диаграммы и соединяться с первыми двумя вариантами отношением включения. Соответствующая диаграмма вариантов использования может включать в себя только указанных двух актеров и три варианта использования (рис. 4.1).
Рис. 4.1. Диаграмма вариантов использования для модели банкомата
На следующем этапе разработки модели вариантов использования для рассматриваемой системы банкомата следует дополнить данную диаграмму текстовым сценарием, написанным на основе предложенного ранее шаблона (табл. 4.1). Этот сценарий будет дополнять диаграмму, раскрывая содержание и логическую последовательность отдельных действий , которые выполняются системой и актерами в процессе снятия наличных по кредитной карточке.
В этом случае сценарий удобно представить в виде трех таблиц, каждая из которых описывает отдельный раздел шаблона.
В главном разделе сценария (табл. 4.2) указывается имя рассматриваемого варианта использования, имена взаимосвязанных с ним актеров, цель выполнения варианта, условный тип и ссылки на другие варианты использования.
| Снятие наличных по кредитной карточке |
| Клиент, Банк |
| Получение требуемой суммы наличными |
| Клиент запрашивает требуемую сумму. Банкомат обеспечивает доступ к счету клиента. Банкомат выдает клиенту наличные. |
| Базовый |
Включает в себя ВИ:
|
1. Клиент вставляет кредитную карточку в устройство чтения банкомата Исключение №1: Кредитная карточка недействительна | 2. Банкомат проверяет кредитную карточку 3. Банкомат предлагает ввести ПИН-код |
4. Клиент вводит персональный PIN-код Исключение №2: Клиент вводит неверный ПИН-код | 5. Банкомат проверяет ПИН-код 6. Банкомат отображает опции меню |
7. Клиент выбирает снятие наличных со своего счета | 8. Система делает запрос в Банк и выясняет текущее состояние счета клиента 9. Банкомат предлагает ввести требуемую сумму |
10. Клиент вводит требуемую сумму 11. Банк проверяет введенную сумму Исключение №3: Требуемая сумма превышает сумму на счете клиента | 12. Банкомат изменяет состояние счета клиента, выдает наличные и чек |
13. Клиент получает наличные и чек | 14. Банкомат предлагает клиенту забрать кредитную карточку |
15. Клиент получает свою кредитную карточку | 16. Банкомат отображает сообщение о готовности к работе |
В третьем разделе сценария (табл. 4.4) описывается последовательность действий, выполняемых при возникновении исключительных ситуаций или исключений.
| Исключение №1. Кредитная карточка недействительна или неверно вставлена | |
3. Банкомат отображает информацию о неверно вставленной кредитной карточке 14. Банкомат возвращает клиенту его кредитную карточку | |
15. Клиент получает свою кредитную карточку | |
Исключение №2. Клиент вводит неверный ПИН-код | |
6. Банкомат отображает информацию о неверном ПИН-коде | |
4. Клиент вводит новый ПИН-код | |
Исключение №3. Требуемая сумма превышает сумму на счете клиента | |
12. Банкомат отображает информацию о превышении кредита | |
10. Клиент вводит новую требуемую сумму | |
Отдельные небольшие по своему объему сценарии могут быть размещены на диаграмме в форме примечаний.
Примечание (note) предназначено для включения в модель произвольной текстовой информации, имеющей непосредственное отношение к контексту разрабатываемого проекта.
В качестве такой информации могут быть комментарии разработчика (например, дата и версия разработки диаграммы или ее отдельных компонентов), ограничения (например, на значения отдельных связей или экземпляры сущностей) и помеченные значения. Применительно к диаграммам вариантов использования примечание может иметь уточняющую информацию, относящуюся к контексту тех или иных вариантов использования.
Графически примечания на всех типах диаграмм обозначаются прямоугольником с "загнутым" верхним правым уголком (рис. 4.2). Собственно текст примечания размещается внутри этого прямоугольника. Примечание может относиться к любому элементу диаграммы, в этом случае их соединяет пунктирная линия. Если примечание относится к нескольким элементам, то от него проводятся соответственно, несколько линий. Как уже отмечалось, примечания могут присутствовать не только на диаграмме вариантов использования, но и на других канонических диаграммах.
Рис. 4.2. Примеры примечаний на диаграммах вариантов использования
Если в примечании указывается ключевое слово <<constraint>>, то данное примечание является ограничением, налагаемым на соответствующий элемент модели, но не на саму диаграмму. При этом запись ограничения заключается в фигурные скобки и должна соответствовать правилам построения выражений языка OCL. Однако для диаграмм вариантов использования ограничения включать в модели не рекомендуется, поскольку они достаточно жестко регламентируют физические аспекты реализации системы, что противоречит концептуальному характеру общей модели вариантов использования.
В этом случае сценарий удобно представить в виде трех таблиц, каждая из которых описывает отдельный раздел шаблона.
В главном разделе сценария (табл. 4.2) указывается имя рассматриваемого варианта использования, имена взаимосвязанных с ним актеров, цель выполнения варианта, условный тип и ссылки на другие варианты использования.
| Снятие наличных по кредитной карточке |
| Клиент, Банк |
| Получение требуемой суммы наличными |
| Клиент запрашивает требуемую сумму. Банкомат обеспечивает доступ к счету клиента. Банкомат выдает клиенту наличные. |
| Базовый |
Включает в себя ВИ:
|
1. Клиент вставляет кредитную карточку в устройство чтения банкомата Исключение №1: Кредитная карточка недействительна | 2. Банкомат проверяет кредитную карточку 3. Банкомат предлагает ввести ПИН-код |
4. Клиент вводит персональный PIN-код Исключение №2: Клиент вводит неверный ПИН-код | 5. Банкомат проверяет ПИН-код 6. Банкомат отображает опции меню |
7. Клиент выбирает снятие наличных со своего счета | 8. Система делает запрос в Банк и выясняет текущее состояние счета клиента 9. Банкомат предлагает ввести требуемую сумму |
10. Клиент вводит требуемую сумму 11. Банк проверяет введенную сумму Исключение №3: Требуемая сумма превышает сумму на счете клиента | 12. Банкомат изменяет состояние счета клиента, выдает наличные и чек |
13. Клиент получает наличные и чек | 14. Банкомат предлагает клиенту забрать кредитную карточку |
15. Клиент получает свою кредитную карточку | 16. Банкомат отображает сообщение о готовности к работе |
В третьем разделе сценария (табл. 4.4) описывается последовательность действий, выполняемых при возникновении исключительных ситуаций или исключений.
| Исключение №1. Кредитная карточка недействительна или неверно вставлена | |
3. Банкомат отображает информацию о неверно вставленной кредитной карточке 14. Банкомат возвращает клиенту его кредитную карточку | |
15. Клиент получает свою кредитную карточку | |
Исключение №2. Клиент вводит неверный ПИН-код | |
6. Банкомат отображает информацию о неверном ПИН-коде | |
4. Клиент вводит новый ПИН-код | |
Исключение №3. Требуемая сумма превышает сумму на счете клиента | |
12. Банкомат отображает информацию о превышении кредита | |
10. Клиент вводит новую требуемую сумму | |
Отдельные небольшие по своему объему сценарии могут быть размещены на диаграмме в форме примечаний.
Примечание (note) предназначено для включения в модель произвольной текстовой информации, имеющей непосредственное отношение к контексту разрабатываемого проекта.
В качестве такой информации могут быть комментарии разработчика (например, дата и версия разработки диаграммы или ее отдельных компонентов), ограничения (например, на значения отдельных связей или экземпляры сущностей) и помеченные значения. Применительно к диаграммам вариантов использования примечание может иметь уточняющую информацию, относящуюся к контексту тех или иных вариантов использования.
Графически примечания на всех типах диаграмм обозначаются прямоугольником с "загнутым" верхним правым уголком (рис. 4.2). Собственно текст примечания размещается внутри этого прямоугольника. Примечание может относиться к любому элементу диаграммы, в этом случае их соединяет пунктирная линия. Если примечание относится к нескольким элементам, то от него проводятся соответственно, несколько линий. Как уже отмечалось, примечания могут присутствовать не только на диаграмме вариантов использования, но и на других канонических диаграммах.
Рис. 4.2. Примеры примечаний на диаграммах вариантов использования
Если в примечании указывается ключевое слово <<constraint>>, то данное примечание является ограничением, налагаемым на соответствующий элемент модели, но не на саму диаграмму. При этом запись ограничения заключается в фигурные скобки и должна соответствовать правилам построения выражений языка OCL. Однако для диаграмм вариантов использования ограничения включать в модели не рекомендуется, поскольку они достаточно жестко регламентируют физические аспекты реализации системы, что противоречит концептуальному характеру общей модели вариантов использования.
