Школа IT-менеджмента АНХ при Правительстве РФ
Опубликован: 11.03.2005 | Доступ: свободный | Студентов: 12255 / 4582 | Оценка: 4.32 / 3.95 | Длительность: 13:56:00
Лекция 4:

Спецификация требований и рекомендации по написанию эффективных вариантов использования

< Лекция 3 || Лекция 4: 123 || Лекция 5 >

Рекомендации по разработке диаграмм вариантов использования

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

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

  • Определить главных или первичных и второстепенных актеров
  • Определить цели главных актеров по отношению к системе
  • Сформулировать основные варианты использования, которые специфицируют функциональные требования к системе
  • Упорядочить варианты использования по степени убывания риска их реализации
  • Рассмотреть все базовые варианты использования в порядке убывания их степени риска
  • Выделить участников, интересы, предусловия и постусловия выполнения выбранного варианта использования
  • Написать успешный сценарий реализации выбранного варианта использования
  • Определить исключения или неуспех в выполнении сценария варианта использования
  • Написать сценарии для всех исключений
  • Выделить общие варианты использования и изобразить их взаимосвязи с базовыми со стереотипом <<include>>
  • Выделить варианты использования для исключений и изобразить их взаимосвязи с базовыми со стереотипом <<extend>>
  • Проверить диаграмму на отсутствие дублирования вариантов использования и актеров

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

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

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

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

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

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

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

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

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

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

< Лекция 3 || Лекция 4: 123 || Лекция 5 >
Евгений Сеничак
Евгений Сеничак

Здравствуйте!
Текущий курс изучает UML 1.5.
Современные версии UML 2.х. 
Разница существенна. Есть ли курс по более новым версиям UML?

Елена Михеенкова
Елена Михеенкова

В разделе Курсы и разделе Повышение квалификации есть курс Нотация и семантика языка UML. В курсах он бесплатный, а в повышение квалификации стоит 3000 руб. В чем различия?