Моделирование описаний функциональности пользователей

Создание моделей может помочь команде изучить пользовательские описания функциональности, по которым предстоит выполнить оценку или разработку.Модели также можно использовать при обсуждении проекта с владельцем продукта по ходу разработки, если возникнут достаточно сложные вопросы.

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

Дополнительные сведения см. в разделе Моделирование требований пользователей.

Модель домена: пользовательские формулировки

Схемы доменных классов

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

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

Клиент выбирает меню для формирования заказа, затем создает в заказепозиции, выбирая среди позиций в меню.

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

Дополнительные сведения см. в разделе UML-схемы классов: правила работы.

Схемы деятельности

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

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

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

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

Дополнительные сведения см. в разделе UML-схемы деятельности: рекомендации.

Использование модели для выявления пробелов в описаниях

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

Создание модели поможет команде задать пользователям вопросы, которые иначе возникнут на существенно более позднем этапе разработки.Например, можно использовать следующие приемы:

• Задать вопросы по кардинальности схемы классов (например: "Может ли позиция в меню отображаться в нескольких меню?").

• Задать вопросы о замкнутых контурах на схеме классов (например: "Все позиции в меню, содержащиеся в заказе, должны быть взяты из одного и того же меню?").

Ответы на такие вопросы можно добавить в схему в виде комментариев.

Единообразие в рамках модели

Команда разработчиков может устранить двусмысленность, обеспечив соответствие схемы и описаний функциональности:

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

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

• В описаниях функциональности и действиях показано, как создается и уничтожается каждый класс и каждое отношение в схеме классов.Например, какое пользовательское описание функциональности создает позицию в меню?Когда уничтожается заказ?

Модели и список невыполненных работ по продукту

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

Дополнительные сведения см. в разделе Моделирование требований пользователей.

Модели и тесты

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

Любой элемент модели UML можно связать с любым рабочим элементом, таким как тест.При изменении любой части модели команда сможет найти связанные с ней тесты.

Используйте модель домена при создании тестов:

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

• Убедитесь, что протестированы все последовательности действий, описанные схемами деятельности.

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

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

Дополнительные сведения см. в разделе Разработка тестов из модели.