На этом шаге рассмотрим прямое и обратное проектирование диаграмм вариантов использования в UML.
Большинство других диаграмм UML, включая диаграммы классов, компонентов, состояний, – явные кандидаты на прямое и обратное проектирование, потому что каждая из них имеет некий аналог в исполняемой системе. Диаграммы вариантов использования в этом смысле стоят слегка особняком, потому что они скорее отражают, чем специфицируют реализацию системы, подсистемы или класса. Варианты использования описывают то, как ведет себя элемент, а не то, как он реализован, поэтому они не могут быть подвергнуты прямому и обратному проектированию.
Прямое проектирование (forward engineering) – это процесс трансформации модели в код путем ее отображения на язык реализации. Диаграмма вариантов использования может быть подвергнута прямому проектированию с целью формирования тестов для того элемента, который она описывает. Каждый вариант использования на такой диаграмме специфицирует поток событий с его вариациями, и все эти потоки описывают ожидаемое поведение элемента – то есть нечто такое, что подлежит тестированию. Хорошо структурированный вариант использования даже специфицирует пред- и постусловия, которые могут применяться в целях определения начального состояния теста и критериев его успешности. Для каждого варианта использования из диаграммы вы можете создать сценарий тестирования (test case), который будет выполняться при выпуске каждой новой версии данного элемента, таким образом подтверждая, что он работает надлежащим образом, прежде чем другие элементы смогут опираться на него в своей работе.
Чтобы осуществить прямое проектирование диаграммы вариантов использования, необходимо:
- идентифицировать объекты, которые взаимодействуют с системой. Попытайтесь идентифицировать различные роли, которые может играть каждый внешний объект;
- создать действующее лицо, представляющее каждую из отдельных взаимодействующих ролей;
- для каждого варианта использования на диаграмме идентифицировать основной и исключительный потоки событий;
- в зависимости от того, насколько тщательно вы собираетесь проводить тестирование, сгенерировать соответствующий сценарий для каждого потока, используя предусловие потока как начальное состояние теста и постусловие – как критерий успешности;
- при необходимости сгенерировать тестовую инфраструктуру, которая будет представлять каждое из действующих лиц, взаимодействующих с вариантом использования. Действующие лица, вводящие информацию для элемента либо производящие над ним какие-то действия, могут быть симулированы, или вместо них понадобится подставить некий эквивалент из реального мира;
- использовать инструментальные средства для запуска каждого из этих тестов всякий раз, когда вы реализуете элемент, к которому относится диаграмма вариантов использования.
Обратное проектирование (reverse engineering) – процесс трансформации кода в модель посредством его отображения из определенного языка реализации. Автоматически выполнить обратное проектирование диаграммы вариантов использования на данном этапе не представляется возможным, потому что на пути от спецификации поведения элемента к его реализации происходит потеря информации. Однако в ваших силах изучить существующую систему и распознать ее подразумеваемое поведение самостоятельно, с тем чтобы на этой основе оформить диаграмму вариантов использования. В любом случае неплохо это делать каждый раз, когда вы имеете дело с недокументированным программным обеспечением. Диаграммы вариантов использования UML просто предоставляют вам стандарт и выразительный язык, чтобы можно было зафиксировать то, что вы при этом обнаружите.
Чтобы осуществить обратное проектирование диаграммы вариантов использования, необходимо:
- идентифицировать каждое действующее лицо, взаимодействующее с системой;
- исследовать манеру взаимодействия каждого из них с системой, изменение ее состояния или состояния среды, реакцию на события;
- проследить поток событий в исполняемой системе относительно каждого действующего лица, начав с основных потоков и во вторую очередь изучив альтернативные;
- объединить в группы взаимосвязанные потоки, определяя соответствующие варианты использования. Рассмотреть варианты моделирования с применением связей расширения и моделирование похожих потоков с применением связей включения;
- отобразить эти варианты использования и действующие лица на диаграмме вариантов использования и установить их связи.
Когда вы создаете диаграммы вариантов использования в UML, помните, что каждая такая диаграмма – это просто графический срез статического представления вариантов использования системы. Отсюда следует, что нет необходимости в одной-единственной диаграмме, которая охватывала бы это представление целиком. Диаграммы вариантов использования, взятые в совокупности, формируют статическое представление вариантов использования системы; каждая из них в отдельности выражает только какой-то один аспект.
Хорошо структурированная диаграмма вариантов использования обладает следующими характеристиками:
- сконцентрирована на передаче одного аспекта представления системы с точки зрения вариантов использования;
- содержит только те варианты использования и действующие лица, которые важны для понимания данного аспекта;
- обеспечивает представление, соответствующее ее уровню абстракции: вы указываете только те дополнения (в частности, точки расширения), которые важны для понимания диаграммы;
- не настолько лаконична, чтобы читатель упустил из виду важную семантику.
Когда вы рисуете диаграмму вариантов использования:
- присваивайте ей имя, соответствующее ее назначению;
- расположите ее элементы так, чтобы пересекающихся линий было как можно меньше;
- организуйте элементы так, чтобы семантически близкие по поведению и ролям располагались рядом;
- используйте примечания и цветовое выделение для того, чтобы привлечь внимание читателя к важным особенностям;
- постарайтесь не показывать слишком много видов связей.
Вообще, если вы задействуете сложные связи включения и расширения, вынесите их в отдельную диаграмму.
На следующем шаге рассмотрим понятие диаграммы деятельности в UML.
