Использование моделей в процессе разработки
В Visual Studio можно использовать модель для изучения и изменения системы, приложения или компонента. Модель может помочь визуализировать среду, в которой работает система, уточнить требования пользователей, определить архитектуру системы, проанализировать код и убедиться, что код удовлетворяет этим требованиям.
Чтобы узнать, какие версии Visual Studio поддерживают каждый тип модели, см. раздел Version support for architecture and modeling tools.
Модели можно использовать несколькими способами:
Рисование схем моделирования помогает уточнять концепции, связанные с требованиями, архитектурой и высокоуровневой структурой. Дополнительные сведения см. в разделе "Требования к пользователю модели".
Работа с моделями помогает выявить несогласованность требований.
Взаимодействие с моделями помогает четко пояснять важные концепции на естественном языке. Дополнительные сведения см. в разделе "Модель архитектуры приложения".
Иногда можно использовать модели для создания кода или других артефактов, таких как документы или схемы баз данных. Например, компоненты моделирования Visual Studio создаются из модели. Дополнительные сведения см. в статье "Создание и настройка приложения из моделей".
Модели можно использовать в самых разнообразных процессах — от максимально гибких до предельно формальных.
Использование моделей для уменьшения неоднозначности
Язык моделирования менее неоднозначен, чем естественный язык, и предназначен для выражения идей, характерных для разработки программного обеспечения.
Если в проекте участвует небольшая команда, использующая гибкий подход к работе, можно использовать модели для уточнения пользовательских историй. При обсуждении с клиентом его потребностей создание модели помогает получать полезные вопросы намного быстрее и по более обширному ассортименту продуктов по сравнению с созданием копилки или кода прототипа.
Если проект большой и включает в себя команды в разных странах, можно использовать модели для более эффективного обмена сведениями о требованиях и архитектуре и по сравнению с обычным текстом.
В обоих случаях создание модели почти всегда позволяет значительно уменьшить число несоответствий и неоднозначностей. Разные заинтересованные лица часто имеют разное представление о производственной среде, в которой работает система, а разные разработчики часто по-разному понимают принципы работы системы. Использование модели в качестве основы для обсуждения обычно позволяет выявить эти различия. Дополнительные сведения об использовании модели для уменьшения несоответствий см. в разделе "Требования пользователей модели".
Использование моделей с другими артефактами
Сама по себе модель не является спецификацией требований или архитектурой. Это средство для более четкого выражения некоторых аспектов этих понятий, однако выразить можно далеко не все понятия, необходимые во время разработки программного обеспечения. Поэтому модели должны использоваться вместе с другими средствами связи, такими как страницы OneNote или абзацы, документы Microsoft Office, рабочие элементы в Team Foundation или липкие заметки на стене комнаты проекта. Кроме последнего, все эти типы объектов могут быть связаны с частями элементов модели.
Ниже перечислены другие аспекты спецификации, которые обычно используются вместе с моделями. В зависимости от масштаба и стиля проекта можно использовать лишь часть этих аспектов или не использовать их совсем:
Пользовательские истории. Пользовательская история — это согласованное с пользователями и другими заинтересованными лицами краткое описание какого-либо аспекта поведения системы, который будет реализован на одной из итераций проекта. Типичная история пользователя начинается с "Клиент сможет...." История пользователя может представить группу вариантов использования или определить расширения вариантов использования, которые были разработаны ранее. Определение или расширение вариантов использования помогает сделать пользовательскую историю яснее.
Запросы на изменение. Запрос на изменение в более формальном проекте очень похож на пользовательскую историю в проекте с гибким подходом к работе. При гибком подходе все требования рассматриваются как изменения для того, что было разработано в предыдущих итерациях.
Описание варианта использования. Вариант использования представляет один способ взаимодействия пользователя с системой для достижения определенной цели. Полное описание включает в себя цель, основную и альтернативную последовательность событий, а также исключительные результаты. Схема вариантов использования помогает подвести итог по вариантам использования.
Сценарии. Сценарий — это довольно подробное описание последовательности событий, показывающее совместную работу системы, пользователей и других систем в пользу заинтересованных лиц. Может принимать форму слайд-шоу пользовательского интерфейса или прототипа пользовательского интерфейса в форме. Сценарий может описывать один вариант использования или последовательность вариантов использования.
Глоссарий. Глоссарий требований проекта описывает слова, с помощью которых клиенты описывают свою рабочую среду. Эти термины также следует использовать в пользовательском интерфейсе и требованиях к модели. Схема классов может помочь прояснить отношения между большинством этих терминов. Создание схем и глоссария не только снижает число недопониманий между пользователями и разработчиками, но и почти всегда выявляет недопонимания между различными заинтересованными лицами.
Бизнес-правила. Многие бизнес-правила могут быть выражены как инвариантные ограничения ассоциаций и атрибутов в модели классов требований и как ограничения на схемах последовательностей.
Высокоуровневая структура. Описывает основные части и их совместную работу. Схемы компонентов, последовательностей и интерфейса являются основной частью высокоуровневой структуры.
Конструктивные шаблоны. Описывают правила проектирования, которые являются общими для различных частей системы.
Спецификации тестирования. В сценариях теста и структуре для кода теста можно активно применять схемы деятельности и последовательностей для описания последовательности шагов теста. Системные тесты должны выражаться в терминах модели требований, чтобы их можно было легко изменить при изменении требований.
План проекта. План проекта или невыполненная работа определяет, когда будет доставлена каждая из функций. Каждую функцию можно определить, указав, какие варианты использования и бизнес-правила она реализует или расширяет. Можно ссылаться на варианты использования и бизнес-правила непосредственно в плане или определить набор функций в отдельном документе, а в плане использовать названия функций.
Использование моделей в планировании итерации
Хотя все проекты отличаются по масштабу и организации, типичный проект планируется как серия итераций длительностью от двух до шести недель. Важно запланировать достаточно итераций, чтобы отзывы по ранним итерациям можно было использовать для корректировки области действия и планов на более поздних итерациях.
Следующие предложения могут помочь вам понять преимущества моделирования в итеративном проекте.
Острый фокус при каждом подходе к итерации
По мере приближения очередной итерации используйте модели, чтобы определить, что именно предоставляется в конце итерации.
Не применяйте детальное моделирование на ранних итерациях. В первой итерации создайте схему классов для основных элементов в глоссарии пользователя, нарисуйте схему для основных вариантов использования и схему для основных компонентов. Не описывайте эти элементы подробно, потому что отдельные детали изменятся позднее в ходе проекта. Используйте термины, определенные в этой модели, для создания списка функций или основных пользовательских историй. Назначьте функции итерациям, чтобы приблизительно сбалансировать предполагаемую рабочую нагрузку в рамках всего проекта. Эти назначения изменятся позднее в ходе проекта.
В ранних итерациях попытайтесь реализовать упрощенные версии всех наиболее важных вариантов использования. Расширьте эти варианты использования в последующих итерациях. Такой подход позволяет снизить риск запоздалого обнаружения недостатков в требованиях или архитектуре проекта, когда уже ничего нельзя сделать.
В конце каждой итерации проводите обсуждение требований, чтобы подробно определить требования или пользовательские истории, которые будут реализованы в следующей итерации. Пригласите пользователей и заинтересованных лиц из бизнес-среды, которые могут определить приоритеты, а также разработчиков и системных тест-инженеров. Отведите три часа на определение требований для 2-недельной итерации.
Задача обсуждения заключается в том, чтобы все участники договорились о том, что должно быть сделано к концу следующей итерации. Используйте модели как одно из средств для уточнения этих требований. Выходные данные семинара являются невыполненной работой по итерации: то есть список задач разработки в Team Foundation и наборы тестов в Microsoft Test Manager.
В обсуждение требований рассматривайте структуру только до такой степени, которая позволяет определить оценки для задач разработки. В противном случае обсуждайте поведение системы, с которым пользователи могут столкнуться непосредственно. Отделите модель требований от модели архитектуры.
У заинтересованных лиц, не имеющих технических навыков, обычно не возникает проблем с восприятием схем UML, сопровождаемых вашими пояснениями.
Связывание модели с рабочими элементами
После обсуждения требований уточните сведения о модели требований и свяжите ее с задачами разработки. Это можно сделать, связав рабочие элементы в Team Foundation с элементами в модели.
С рабочими элементами можно связать любой элемент, но наиболее полезными являются следующие элементы:
- Комментарии, описывающие бизнес-правила или требования к качеству обслуживания. Дополнительные сведения см. в разделе "Требования к пользователю модели".
Связывание модели с тестами
Используйте модель требований для управления разработкой тестов приемки. Создавайте эти тесты одновременно с разработкой.
Дополнительные сведения об этом методе см. в статье "Разработка тестов на основе модели".
Оценка оставшихся работ
Модель требований может помочь оценить общий размер проекта по сравнению с размером каждой итерации. Оценка числа и сложности вариантов использования и классов может помочь определить необходимый объем работ по разработке. После завершения нескольких первых итераций можно провести сравнение выполненных требований и требований, которые еще предстоит выполнить, чтобы приблизительно оценить стоимость и масштаб оставшейся части проекта.
В конце каждой итерации рассмотрите назначение требований для будущих итераций. Может оказаться полезным представлять состояние программного обеспечения в конце каждой итерации в виде подсистемы на схеме вариантов использования. Во время обсуждения можно перемещать варианты использования и расширения вариантов использования из одной такой подсистемы в другую.
Уровни абстракции
Модели имеют диапазон абстракции в отношении программного обеспечения. Наиболее конкретные модели непосредственно представляют код программы, а наиболее абстрактные модели представляют бизнес-концепции, которые могут быть как представлены, так и не представлены в коде.
Модель можно просмотреть с помощью нескольких типов схем. Сведения о моделях и схемах см. в разделе "Создание моделей для приложения".
Различные виды схем полезны для описания разработки на различных уровнях абстракции. Многие типы схем можно с пользой применять сразу на нескольких уровнях. В этой таблице показано, как можно использовать каждый тип схем.
| Уровень разработки | Типы схем |
|---|---|
| Бизнес-процесс Общее представление о контексте, в котором будет использоваться система, помогает понять потребности пользователей. |
— Концептуальные схемы классов описывают бизнес-понятия, используемые в бизнес-процессе. |
| Потребности пользователя Определение того, что нужно пользователям от вашей системы. |
— Бизнес-правила и требования к обслуживанию можно описать в отдельных документах. |
| Высокоуровневая структура Общая структура системы: основные компоненты и их взаимосвязи. |
— Схемы зависимостей описывают структуру системы в взаимозависимые части. Вы можете проверить код программы на основе схем зависимостей, чтобы убедиться, что он соответствует архитектуре. |
| Анализ кода Схемы можно создать из кода. |
— Схемы зависимостей показывают зависимости между классами. Обновленный код можно проверить на схеме зависимостей. — Схемы классов показывают классы в коде. |
Внешние ресурсы
Связанный контент
- Использование моделей в гибкой разработке
- Создание моделей для приложения
- Моделирование требований пользователей
- Моделирование архитектуры приложения
- Разработка тестов на основе модели
- Разработка структуры решения моделирования
Примечание.
Компонент Text Template Transformation (Преобразование текстовых шаблонов) автоматически устанавливается как часть рабочей нагрузки разработки расширений Visual Studio. Его также можно установить на вкладке Отдельные компоненты Visual Studio Installer в категории Пакеты SDK, библиотеки и платформы. Установите компонент Пакет SDK для моделирования со вкладки Отдельные компоненты.