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

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

В Видео канала 9: С помощью архитектуры усовершенствовать моделирование разделе.

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

Модели можно использовать несколькими способами.

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

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

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

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

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

Использование моделей для сокращения неоднозначности

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заострение внимания по мере приближения очередной итерации

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

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

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

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

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

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

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

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

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

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

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

• Расширения вариантов использования.Если в итерации будет реализована только одна сторона варианта использования, можно разделить его на основной вариант использования и одно или несколько расширений.Расширения — это варианты использования, связанные с основным вариантом отношением "extend".Дополнительные сведения о расширениях вариантов использования см. в разделе UML-схемы вариантов использования: справочные материалы.

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

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

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

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

Оценка оставшихся трудозатрат

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

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

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

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

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

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

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

См. также

Основные понятия

Руководство по средствам проектирования архитектуры Visual Studio

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

Разработка моделей для программного проектирования

Моделирование требований пользователей

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

Разработка тестов из модели

Структирирование решений моделирования