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

Статья
02/20/2013

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Описания использования.Описание использования — это краткое описание для пользователей и других заинтересованных лиц какой-либо стороны поведения системы, которая будет включена в одну из итераций проекта.Типичное описание использования начинается со слов "Клиент сможет..." Описание использования может содержать группу вариантов использования или определять расширения вариантов использования, разработанных ранее.Определение или расширение вариантов использования помогает сделать описание использования яснее.
Запросы на изменения.Запрос на изменение в формальном проекте очень похож на описание использования в гибком проекте.При гибком подходе все требования считаются изменениями того, что было разработано в предыдущих итерациях.
Описание варианта использования.Вариант использования представляет какой-либо один способ взаимодействия пользователя с системой для достижения определенной цели.Полное описание включает цель, основную и альтернативную последовательности событий и возможные отклонения.Схема вариантов использования обобщает и обеспечивает общее представление вариантов использования.
Сценарии.Сценарий — это довольно подробное описание последовательности событий, показывающее, как взаимодействие системы, пользователей и других систем приводит к полезным для заказчика результатам.Описание может быть в виде показа слайдов пользовательского интерфейса или прототипа пользовательского интерфейса.Сценарий может описывать один вариант использования или последовательность вариантов использования.
Глоссарий.Глоссарий требований к проекту описывает слова, с помощью которых клиенты обсуждают свои деловые вопросы.Пользовательский интерфейс и модель требований должны также использовать эти термины.Схема классов помогает прояснить отношения между большинством этих терминов.Создание схем и глоссария не только снижает уровень недопонимания между пользователями и разработчиками, но почти всегда позволяет выявить недопонимания, возникающие между различными заинтересованными лицами со стороны бизнеса.
Бизнес-правила.Многие бизнес-правила могут быть выражены как инвариантные ограничения связей и атрибутов в модели классов требований и как ограничения на схемах последовательностей.
Структура высокого уровня.Описывает основные части и их взаиморасположение.Схемы компонентов, последовательностей и интерфейса являются основной частью структуры высокого уровня.
Шаблоны разработки.Описывают общие правила проектирования, использующиеся в различных частях системы.
Спецификации тестирования.Для скриптов тестирования и структур для кода тестирования можно использовать схемы активности и последовательностей, описывающие последовательности шагов теста.Системные тесты следует выражать в терминах модели требований, чтобы их можно было легко изменять при изменении требований.
План проекта.План проекта или план невыполненных работ определяет, когда будет реализована каждая из функций.Каждую функцию можно определить, указав, какие варианты использования и бизнес-правила она реализует или расширяет.На случаи использования и бизнес-правила можно ссылаться непосредственно в плане, либо можно определить набор функций в отдельном документе и использовать в плане заголовки функций.

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

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

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

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

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

Не моделируйте все в подробностях на ранних итерациях.Создайте для первой итерации схему классов для основных элементов в глоссарии пользователя, изобразите схему для основных вариантов использования и схему для основных компонентов.Не описывайте эти элементы подробно, потому что подробности изменятся по ходу развития проекта.Используйте термины, определенные в этой модели, для создания списка функций или основных описаний использования.Назначьте разработку функций на итерации, чтобы сбалансировать предполагаемую рабочую нагрузку во время выполнения проекта.Эти назначения изменятся по мере развития проекта.
Попытайтесь реализовать упрощенные версии всех наиболее важных вариантов использования в ранних итерациях.Расширьте их в последующих итерациях.Этот подход помогает снизить риск обнаружения дефекта в требованиях или архитектуре слишком поздно, чтобы успеть его исправить.
В конце каждой итерации организуйте обсуждение требований, чтобы подробно определить, какие требования или описания использования будут разработаны в следующей итерации.Пригласите пользователей и заинтересованных лиц от бизнеса, определяющих приоритеты, а также разработчиков и тест-инженеров системы.Отведите три часа для определения требований для итерации продолжительностью в 2 недели.
Задача обсуждения — прийти к всеобщему согласию о том, чтобы должно быть сделано к концу следующей итерации.Используйте модели как одно из средств уточнения требований.Результатом такого обсуждения является список работ итерации, то есть список задач разработки в Team Foundation и наборы тестов в Microsoft Test Manager.
При обсуждении требований говорите о структуре, только если это необходимо, чтобы оценить предстоящие задачи разработки.В остальных случаях ограничьтесь обсуждением только того поведения системы, с которым пользователи могут столкнуться непосредственно.Разделяйте модель требований и модель архитектуры.
Заинтересованные лица, не имеющие технического образования, обычно без труда понимают UML-схемы, сопровождаемые объяснениями.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Категория	Ссылки
Видеоклипы
Форумы	Visual Studio Visualization & Modeling Tools Visual Studio Visualization & Modeling SDK (DSL Tools)
Блоги	Visual Studio ALM + Блог Team Foundation Server
Технические статьи и журналы	The Architecture Journal - Issue 23: Architecture Modeling and Processes
Другие сайты	Центр архитекторов на MSDN Руководство по средствам проектирования архитектуры Visual Studio