Использование моделей в процессе разработки

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

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

Модели могут помочь вам в нескольких способах:

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

• Работа с моделями помогает выявлять несоответствия в требованиях.

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

• Иногда можно использовать модели для создания кода или других артефактов, таких как схемы базы данных или документы. Например, компоненты моделирования Visual Studio создаются из модели. Дополнительные сведения см. в статье "Создание и настройка приложения из моделей".

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

Использование моделей для уменьшения неоднозначности

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

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

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

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

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

Модель сама по себе не является спецификацией требований или архитектурой. Это инструмент для выражения некоторых аспектов этих вещей более четко, но не все понятия, необходимые во время проектирования программного обеспечения, могут быть выражены. Поэтому модели должны использоваться вместе с другими средствами связи, такими как страницы OneNote или абзацы, документы Microsoft Office, рабочие элементы в Team Foundation или липкие заметки на стене комнаты проекта. Помимо последнего элемента, все эти типы объектов могут быть связаны с элементами модели.

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

• Истории пользователей. История пользователя — это краткое описание аспекта поведения системы, о котором ведутся обсуждения с пользователями и другими заинтересованными лицами, и который будет реализован в одной из итераций проекта. Типичная история пользователя начинается с "Клиент сможет...." История пользователя может представить группу вариантов использования или определить расширения вариантов использования, которые были разработаны ранее. Определение или расширение вариантов использования помогает сделать историю пользователя более четкой.

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

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

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

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

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

• Высокоуровневый дизайн. Описывает основные части и способ их объединения. Схемы компонентов, последовательностей и интерфейсов являются основной частью высокоуровневого проектирования.

• Шаблоны проектирования. Описать правила проектирования, которые совместно используются в разных частях системы.

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

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

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

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

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

Улучшайте фокус по мере приближения каждой итерации

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

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

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

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

• Цель семинара заключается в том, чтобы все согласились с тем, что будет достигнуто к концу следующей итерации. Используйте модели в качестве одного из средств для уточнения требований. Выходные данные семинара являются невыполненной работой по итерации: то есть список задач разработки в Team Foundation и наборы тестов в Microsoft Test Manager.

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

• Нетехнические заинтересованные стороны обычно не имеют проблем с пониманием диаграмм UML, с некоторыми рекомендациями от вас.

Связывание модели с рабочими элементами

После семинара по требованиям выясите подробные сведения о модели требований и свяжите ее с задачами разработки. Это можно сделать, связав рабочие элементы в Team Foundation с элементами в модели.

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

• Комментарии, описывающие бизнес-правила или требования к службе. Дополнительные сведения см. в разделе "Требования к пользователю модели".

Связывание модели с тестами

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

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

Оценка оставшихся работ

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

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

Уровни абстракции

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

Модель можно просматривать с помощью нескольких типов схем. Сведения о моделях и схемах см. в разделе "Создание моделей для приложения".

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

Уровень разработки	Типы схем
Бизнес-процесс Понимание контекста, в котором будет использоваться ваша система, помогает понять, что требуется пользователям.	— Концептуальные схемы классов описывают бизнес-понятия, используемые в бизнес-процессе.
Требования к пользователю Определение того, что требуется пользователям из вашей системы.	— Бизнес-правила и требования к обслуживанию можно описать в отдельных документах.
Высокий уровень проектирования Общая структура системы: основные компоненты и то, как они объединяются.	— Схемы зависимостей описывают структуру системы в взаимозависимые части. Вы можете проверить код программы на основе схем зависимостей, чтобы убедиться, что он соответствует архитектуре.
Анализ кода Схемы можно создать из кода.	— Схемы зависимостей показывают зависимости между классами. Обновленный код можно проверить на схеме зависимостей. — Схемы классов показывают классы в коде.

Внешние ресурсы

Категория	Links
Видеоролики	Видео MSDN "Как я это делаю": как создать и использовать модели и диаграммы UML (Visual Studio Ultimate) MSDN How Do I Series: UML Tools and Extensibility (Visual Studio Ultimate)
Форумах	- Средства визуализации и моделирования Visual Studio - Пакет SDK для визуализации и моделирования Visual Studio (средства DSL)
Блоги	Microsoft DevOps
Технические статьи и журналы	Центр архитектуры MSDN

Связанный контент

• Использование моделей в разработке Agile
• Создание моделей для приложения
• Требования к пользователю модели
• Модель архитектуры приложения
• Разработка тестов на основе модели
• Структура решения моделирования

Замечание

Компонент преобразования текстовых шаблонов автоматически устанавливается в рамках рабочей нагрузки разработки расширений Visual Studio . Вы также можете установить его на вкладке "Отдельные компоненты " Установщика Visual Studio в категориях SDK, библиотек и платформ . Установите компонент sdk для моделирования на вкладке "Отдельные компоненты ".