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