- эта проблема не имеет и не может иметь теоретического решения;
- методологии, направленные на разработку ПО в целом (например, RUP), предоставляют некоторые рекомендации и язык для описания проектирования, но в силу широкой ориентированности отображают этап проектирования в значительной степени с позиций реализации;
- предлагаемая Купером методология, во-первых, дает адекватные, средства описания взаимодействия, во вторых, представляет собой работающий инструмент, и, в-третьих, прекрасно согласуется с подходами, представляющимися на данный момент наиболее перспективными.
Таким образом, по отношению к RUP GDD можно рассматривать как методику реализации начальных этапов RUP. Уровень моделей UML, соответствующих GDD, – концептуальный, соответствующий класс диаграмм описания – диаграммы вариантов использования (use case diagram).
На рис. 5.1.приведено примерное соответствие терминов в RUP (UML) и GDD.
| GDD | Персонаж (Persona) | Цель | Сценарий (сжатое описание способов применения программного продукта персонажем для достижения цели |
| UML | Актер (Actor) | Вариант использования – описание некоторого аспекта поведения проектируемой системы | Сценарий (содержание варианта использования) |
Рис. 5.1. Примерное соответствие терминов в RUP (UML) и GDD
Соответствие приблизительное, так как в UML понятие цели непосредственно не отображается, а выражено через вариант использования. Кроме того, сценариям отводится разная роль: если в UML сценарий является дополнением к модели, то в GDD он рассматривается как основной элемент и по определению очень схож с вариантом использования. · Приведем также взгляд на проектирование взаимодействия с позиций практичного проектирования по Константайну.Здесь используются понятия пользовательских ролей, сценариев и вариантов использования.Пользовательская роль – абстрактный набор потребностей, интересов, ожиданий, предполагаемого поведения и обязательств, характеризующий взаимоотношения между некоторым классом или видом пользователей и системой. Очевидно, это аналог персонажа в GDD. Сценарий, в отличие от GDD, более свободен; это скорее повествовательный рассказ о совершаемых действиях, реалистичный и детальный. Поэтому авторы считают, что сценарии недостаточны для выделения и понимания основной сути взаимодействия. Модели Use Case расцениваются как «близкий родственник сценариев». Отмечается, что эти модели в своем исходном виде слишком сильно опираются на реализацию и в недостаточной мере заботятся о проблемах, выявленных пользователем». предлагается модификация моделей, суть которой состоит в смещении с действий пользователя на его цели, т.е. обобщении модели, и симбиозе изобразительных средств UML и сценариев. Новые формы модели именуются сущностными элементами Use Case. «Сущностный элемент Use Case – это структурированное повествование, выраженное на языке данной прикладной области и пользователей системы и содержащее упрощенное, обобщенное, абстрактное, не зависящее от технологии и реализации описание одной завершенной, наполненной смыслом и хорошо определенной с точки зрения пользователей задачи или взаимодействия. Предполагается, что пользователь играет определенную роль по отношению к системе, а в описании воплощаются цели и замыслы лежащего в его основе взаимодействия».
