Обзор сценария. Изменение проекта с помощью визуализации и моделирования

Чтобы убедиться, что ваше программное обеспечение отвечает потребностям своих пользователей, используйте инструменты визуализации и моделирования в Visual Studio Ultimate, чтобы упростить обновление или изменение конструкции системы. Эти инструменты включают Unified Modeling Language (UML) диаграммы, диаграмм слоев, графы зависимостей на основе кода, диаграммы последовательностей и диаграммы классов. Например, вы можете использовать эти инструменты для выполнения следующих задач:

• Выяснение требований пользователей и бизнес-процессов.

• Визуализация и изучение существующего кода.

• Описание изменений в существующей системе.

• Проверка соответствия системы требованиям.

• Поддержание соответствия кода и структуры.

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

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

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

Дополнительные сведения об этих средствах и поддерживаемых ими сценариях см. в разделах:

• Моделирование приложения

• Визуализация и понимание кода

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

Содержание раздела

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

Общие сведения о сценарии

В этом сценарии описываются эпизоды из жизненных циклов разработки программного обеспечения для двух вымышленных компаний: Dinner Now и Lucerne Publishing.Dinner Now предоставляет в Сиэтле услуги по доставке еды с заказом на веб-сайте.Клиенты могут заказывать еду и оплачивать эти заказы на веб-сайте компании Dinner Now.Затем заказы направляются в соответствующий местный ресторан для доставки.Расположенная в Нью-Йорке компания Lucerne Publishing имеет несколько направлений деятельности, как в Интернете, так и вне его.Например, у этой компании имеется веб-сайт, на котором клиенты могут размещать отзывы о ресторанах.

Компания Lucerne недавно приобрела компанию Dinner Now и хочет сделать указанные ниже изменения.

• Интегрировать свои веб-сайты, добавив возможность размещения отзывов о ресторанах для компании Dinner Now.

• Заменить платежную систему компании Dinner Now системой компании Lucerne.

• Разверните службы компании Dinner Now по всему региону.

В компании Dinner Now используются методологии SCRUM и экстремального программирования (XP).У них очень высокий объем протестированного кода и очень мало неподдерживаемого кода.Компания минимизировала риски, создавая небольшие, но работающие версии системы, и постепенно добавляя функциональные возможности.Разработка кода выполнялась путем коротких и частых итераций.Это позволяет уверенно вносить изменения, часто выполнять рефакторинг кода и избегать подхода с большими затратами на предварительное планирование структуры (BDUF).

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

Обе команды используют схемы моделирования в Visual Studio Ultimate, помогающие разрабатывать системы, соответствующие потребностям пользователей.Они используют Team Foundation Server совместно с другими инструментами, помогающими им планировать, организовывать, и управлять их работой.

Дополнительные сведения о Team Foundation Server см.:

• Планирование и отслеживание работы

• Тестирование, проверка и возврат обновленного кода

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

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

	Моделирование требований пользователей	Моделирование бизнес-процессов	Архитектура и дизайн системы	Визуализация и изучение кода	Проверка
Схема вариантов использования (UML)	√	√			√
Схема деятельности (UML)	√	√	√		√
Схема классов (UML)	√	√	√		√
Схема компонентов (UML)	√	√	√		√
Схема последовательностей (UML)	√	√	√		√
Схема доменного языка (DSL)	√	√	√
Схема слоев, проверка слоев			√	√	√
Граф зависимостей (на основе кода)			√	√	√
Схема последовательностей (на основе кода)				√	√
Конструктор классов (на основе кода)				√
Обозреватель архитектуры				√

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

Пример

• Практическое руководство. Создание проектов и схем для UML-моделирования

• Создание схем слоев из кода

• Визуализация зависимостей кода на графах зависимостей

• Визуализация кода путем создания на схем последовательностей

• Практическое руководство. Добавление схем классов в проекты (конструктор классов)

• Пакет SDK визуализации и моделирования — доменные языки

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

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

Пример

• Поддержание соответствия кода и дизайна

• Описание логической архитектуры: схемы слоев

• Проверка кода по схеме слоев

  Примечание
  Visual Studio Premium поддерживает проверку слоев, а также нередактируемые версии этих графов и схем для визуализации и моделирования.

Выяснение и передача сведения о системе

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

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

• Визуализация существующего кода.

• Обмен данными с компанией Lucerne о новых или обновленных пользовательских описаниях функциональности.

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

В компании Lucerne схемы используются для выполнения следующих задач.

• Получение сведений о бизнес-процессе компании Dinner Now.

• Понимание дизайна системы.

• Обмен данными с компанией Dinner Now о новых или обновленных пользовательских требованиях.

• Документирование обновлений системы.

Схемы интегрированы с Team Foundation Server, поэтому рабочие группы могут легко планировать и отслеживать свою работу. Например, они используют модели для определения тестовых случаев, задач разработки, и оценки их работы.Компания Lucerne связывает рабочие элементы Team Foundation Server с элементами модели, чтобы можно было контролировать процесс и обеспечивать соответствие системы требованиям пользователей.Например, они связывают варианты использования с рабочими элементами тестовых случаев, чтобы можно было контролировать выполнение вариантов использования после прохождения всех тестов.

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

Пример

• Понимание роли системы в бизнес-процессе

• Описание новых и обновленных требований пользователей

• Создание тестов из моделей

• Идентификация изменений в существующей системе

• Поддержание соответствия кода и дизайна

• Общие рекомендации по созданию и использованию моделей

• Планирование и отслеживание работы

• Тестирование, проверка и возврат обновленного кода

Понимание роли системы в бизнес-процессе

Компании Lucerne требуется получить больше сведений о бизнес-процессе компании Dinner Now.Они создают следующие схемы для улучшения взаимопонимания с компанией Dinner Now:

Схема	Описывает
Схема вариантов использования (UML) Пример UML-схемы вариантов использования: справочные материалы UML-схемы вариантов использования: правила работы	Виды деятельности, поддерживаемые системой компании Dinner Now Персонал и внешние системы, выполняющие эти виды деятельности Основные компоненты системы, которые обеспечивают поддержку каждого из видов деятельности Части бизнес-процесса, находящиеся за пределами области действия текущей системы, например доставка еды
Схема деятельности (UML) Пример UML-схемы деятельности: справочные материалы UML-схемы деятельности: рекомендации	Последовательность действий, выполняемых при создании заказа клиентом
Схема классов (UML) Пример UML-схемы классов: справочные материалы UML-схемы классов: правила работы	Бизнес-сущности и условия, используемые в обсуждении и во взаимоотношениях между этими сущностями.Например, в данном сценарии "Заказ" и "Позиция меню" являются часть словаря.

Например, компания Lucerne создает следующую схему вариантов использования, чтобы понять, какие задачи выполняются на веб-сайте компании Dinner Now и кто их выполняет:

UML-схема вариантов использования

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

UML-схема активности

В следующей схеме классов описываются сущности, участвующие в процессе заказа:

UML-схема классов

Описание новых и обновленных требований пользователей

Компания Lucerne хочет добавить в систему компании Dinner Now функциональность, позволяющую клиентам читать и оставлять отзывы о ресторанах.Ее сотрудники обновляют указанные ниже схемы, чтобы можно было описать и обсудить новые требования с компанией Dinner Now:

Схема	Описывает
Схема вариантов использования (UML) Пример UML-схемы вариантов использования: справочные материалы UML-схемы вариантов использования: правила работы	Новый вариант использования для функции "Написать отзыв о ресторане"
Схема деятельности (UML) Пример UML-схемы деятельности: справочные материалы UML-схемы деятельности: рекомендации	Шаги, выполняемые, когда клиент хочет написать отзыв о ресторане
Схема классов (UML) Пример UML-схемы классов: справочные материалы UML-схемы классов: правила работы	Данные, необходимые для сохранения отзыва

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

UML-схема вариантов использования

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

UML-схема деятельности

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

UML-схема классов

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

Обе команды согласились, что перед внесением каких-либо изменений требуется полный набор тестов системы и ее компонентов.В компании Lucerne имеется специальная команда, проводящая тестирование на уровне системы и на уровне компонентов.Они повторно используют тесты, созданные компанией Dinner Now, и структурируют эти тесты с помощью UML-схем.

• Каждый вариант использования представляется одним или несколькими тестами.Элементы на схемы вариантов использования связываются с рабочими элементами Test Case в Team Foundation Server.

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

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

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

Пример

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

• Проверка модели UML

Идентификация изменений в существующей системе

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

Граф или схема	Показывает
Граф зависимостей Пример Визуализация зависимостей кода на графах зависимостей Просмотр и реорганизация графов зависимостей Изменение и настройка графов зависимостей Поиск кода с помощью обозревателя архитектуры	Зависимости и другие связи в коде. Например, компания Dinner Now может начать с изучения графов зависимостей сборок, чтобы собрать общие сведения о сборках и их зависимостях.Можно подробно изучить графы для определения пространств имен и классов в этих сборках. Компания Dinner Now может также создать графы для изучения конкретных областей и других видов отношений в коде.Они используют обозреватель архитектуры или обозреватель решений, чтобы помочь им найти и выбрать области и связи, которые их интересуют.
Схема последовательностей, основанная на коде Дополнительные сведения см. в разделе Визуализация кода путем создания на схем последовательностей.	Последовательность взаимодействий между экземплярами. Схемы последовательностей создаются из определений методов и полезны для понимания того, как поведение метода реализуется в коде.
Схема классов, основанная на коде Дополнительные сведения см. в разделе Практическое руководство. Добавление схем классов в проекты (конструктор классов).	Существующие классы в коде

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

Граф зависимостей пространств имен

Разработчик разворачивает выбранные пространства имен для отображения их классов, методов и связей:

Развернутый граф зависимостей пространств имен с показанными связями между группами

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

Совет
Для просмотра влияния каждого изменения при его внесении заново создавайте из кода графы зависимостей и схемы последовательностей после внесения каждого изменения.

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

Схемы	Описывает
Схема деятельности (UML) Пример UML-схемы деятельности: справочные материалы UML-схемы деятельности: рекомендации	Последовательность шагов, выполняемых, когда система обнаруживает, что клиент повторно сделал заказ в ресторане, и предлагает клиенту написать отзыв.
Схема классов (UML) Пример UML-схемы классов: справочные материалы UML-схемы классов: правила работы	Логические классы и их связи.Например, добавляется новый класс для описания пункта Отзыв и его связи с другими сущностями, такими как Ресторан, Меню и Клиент. Чтобы связывать отзывы с клиентами, система должна хранить сведения о клиентах.UML-схема классов может помочь прояснить эти детали.
Схема классов, основанная на коде Дополнительные сведения см. в разделе Практическое руководство. Добавление схем классов в проекты (конструктор классов).	Существующие классы в коде.
Схема компонентов (UML) Пример Схемы компонентов UML: справочные материалы UML-схемы компонентов: правила работы	Высокоуровневые части системы, такие как веб-сайт компании Dinner Now, и их интерфейсы.Эти интерфейсы определяют, как компоненты взаимодействуют между собой через предоставляемые и потребляемые методы или службы.
Схема последовательностей (UML) Пример UML-схемы последовательностей: справочные материалы UML-схемы последовательностей: правила работы	Последовательность взаимодействий между экземплярами.

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

UML-схема компонентов

Следующая схема последовательностей показывает последовательность взаимодействий, возникающих, когда веб-сайт компании Dinner Now проверяет, делал ли ранее клиент заказы в этом ресторане.Если условие выполняется, сайт просит клиента создать отзыв, который отправляется в ресторан и публикуется на веб-сайте:

UML-схема последовательностей

Поддержание соответствия кода и дизайна

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

Схема

Описывает

Схема слоев Пример Создание схем слоев из кода Схемы слоев: справочные материалы Схемы слоев: рекомендации Проверка кода по схеме слоев

Логическая архитектура кода. Схема слоев упорядочивает артефакты в решении Visual Studio и сопоставляет их абстрактным группам, называемым слоями.Эти слои описывают роли, задачи или функции, выполняемые этими артефактами в системе. Схемы слоев полезны для описания требуемого дизайна системы и проверки создаваемого кода на соответствие этому дизайну. Чтобы создать слои, перетащите элементы из обозревателя решений, графов зависимостей или обозревателя архитектуры.Чтобы нарисовать новые слои, используйте панель элементов или щелкните правой кнопкой мыши на поверхности схемы. Чтобы просмотреть существующие зависимости, щелкните правой кнопкой мыши на поверхности схемы, затем выберите Создать зависимости.Чтобы указать требуемые зависимости, нарисуйте новые зависимости.

Например, следующая схема слоев описывает зависимости между слоями и рядом артефактов, связанных с каждым из этих слоев:

Схема слоев

Чтобы обеспечить отсутствие конфликтов с дизайном во время разработки кода, команды используют проверку слоев при построениях, выполняющихся на Team Foundation Build.Они также создали пользовательскую задачу MSBuild требующую проверку слоев перед принятием возвращенного кода.Для сбора ошибок проверки они используют отчеты построения.

Пример

• Определение процесса построения

• Определение процесса построения с условным возвратом для проверки изменений

• Разработка настраиваемого процесса построения

Общие рекомендации по созданию и использованию моделей

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

  Чтобы открыть панель элементов, в меню Вид выберите Панель элементов.

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

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

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

  Что бы увидеть модель, в меню Архитектура последовательно выберите пункты Окна и Обозреватель моделей UML.

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

• Visual Studio Ultimate поддерживает UML 2.1.2.В этом обзоре описываются только основные функции UML-схем в данном релизе, но существует много книг, в которых подробно рассматривается язык UML и его применение.

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

Планирование и отслеживание работы

Схемы моделирования в Visual Studio Ultimate интегрированы с Team Foundation Server, чтобы можно было планировать, управлять и отслеживать работу. Обе группы используются модели, чтобы определить тестовые случаи, задачи разработки и оценить их работу.Компания Lucerne создает и связывает рабочие элементы Team Foundation Server с элементами модели, такими как варианты использования или компоненты.Это помогает контролировать процесс и выполнять трассировку работы вплоть до требований пользователей.Такой подход помогает убедиться, что изменения продолжают удовлетворять этим требованиям.

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

• Ежедневные отчеты о сгорании, показывающие, будет ли запланированная работа завершена за ожидаемое время.Они создают другие аналогичные отчеты в Team Foundation Server для отслеживания хода устранения ошибок.

• Лист итераций, в котором используется Microsoft Excel, что бы помочь команде контролировать и распределять рабочую нагрузку своих членов.Этот лист связан с Team Foundation Server и обеспечивает фокус для обсуждения во время регулярных совещаний по ходу выполнения работы.

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

Пример

• Планирование и отслеживание проектов

• Отслеживание работ и управление рабочим процессом

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

• Создание, настройка отчетов для Visual Studio ALM и управление ими

• Планирование задач и назначение ресурсов с помощью Microsoft Project

Тестирование, проверка и возврат кода

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

• Он работает.

• Он не нарушает работу ранее работавшего кода.

• Он не противоречит дизайну.

Компания Dinner Now обладает большим набором автоматических тестов, которые могут использоваться компанией Lucerne, так как большинство из них по-прежнему применимы.Компания Lucerne может также переработать эти тесты и добавить новые тесты для охвата новой функциональности.Обе компании также используют Visual Studio Ultimate для выполнения ручных тестов.

Чтобы убедиться в том, что код соответствует дизайну команды настраивают их построения в Team Foundation Build, чтобы включить проверку слоев. Если возникают какие-либо конфликты, то создается отчет с подробными сведениями.

Пример

• Тестирование приложения

• Проверка системы в ходе разработки

• Использование управления версиями

• Построение приложения

Обновление системы с использованием визуализации и моделирования

Компании Lucerne и Dinner Now должны объединить свои платежные системы.В следующих разделах показано как схемы моделирования в Visual Studio Ultimate помогают им выполнить эту задачу:

• Понимание требований пользователей: схемы вариантов использования

• Понимание бизнес-процессов: схемы деятельности

• Описание структуры системы: схемы компонентов

• Описание взаимодействий: схемы последовательностей

• Визуализация существующего кода: графы зависимостей

• Определение глоссария типов: схемы классов

• Описание логической архитектуры: схемы слоев

Пример

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

• Визуализация и понимание кода

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

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

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

Понимание требований пользователей: схемы вариантов использования

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

• Клиенты создают заказы.

• Рестораны получают заказы.

• Шлюз внешней службы обработки платежей, используемый платежной системой компании Dinner Now для проверки платежей, не входит в область деятельности веб-сайта.

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

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

Если бы время разработки было коротким, команды могли бы обсудить, не следует ли позволить клиентам платить ресторанам напрямую.Чтобы показать это, они бы заменили вариант использования "Обработка платежа" вариантом, находящимся вне границ системы компании Dinner Now.Затем они связали бы Клиента непосредственно с Рестораном, указывая, что компания Dinner Now будет заниматься только обработкой заказов:

Изменение области действия платежа ресторану на схеме вариантов использования

Пример

• UML-схемы вариантов использования: справочные материалы

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

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

Схема вариантов использования имеет следующие основные составляющие.

• Субъекты представляют роли, выполняемые сотрудниками, организациями, оборудованием или программными системами.Например, Клиент, Ресторан и Платежная система компании Dinner Now являются субъектами.

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

• Ассоциации связывают субъекты с вариантами использования.

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

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

• Артефакты связывают элементы на схеме с другими схемами или документами.

Пример

• UML-схемы вариантов использования: справочные материалы

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

Сводка. Преимущества схем вариантов использования

Схемы вариантов использования помогают визуализировать следующее.

• Виды деятельности, поддерживаемые или не поддерживаемые системой

• Персонал и внешние системы, выполняющие эти виды деятельности

• Основные компоненты системы, поддерживающие каждый вид деятельности, которые можно представить в виде подсистем, вложенных в родительскую систему

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

Отношение к другим схемам

Схема	Описывает
Схема деятельности	Последовательность шагов в варианте использования, а также кто или что выполняет эти шаги в данном варианте использования. Имена вариантов использования часто отражают шаги на схеме деятельности.Схемы деятельности поддерживают такие элементы, как решения, объединения, ввод и вывод данных, параллельные потоки и т. п. Пример UML-схемы деятельности: справочные материалы UML-схемы деятельности: рекомендации
Схема последовательностей	Последовательность взаимодействий между участниками в варианте использования. Пример UML-схемы последовательностей: справочные материалы UML-схемы последовательностей: правила работы
Схема классов (UML)	Сущности или типы, участвующие в варианте использования. Пример UML-схемы классов: справочные материалы UML-схемы классов: правила работы

Понимание бизнес-процессов: схемы деятельности

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

Компания Lucerne обновляет приведенную ниже схему деятельности, чтобы показать, что компания Lucerne обрабатывает платеж и платит ресторану.Они заменяют платежную систему компании Dinner Now платежной системой компании Lucerne, как выделено на схеме:

Замена платежной системы компании Dinner Now на схеме деятельности

Обновленная схема помогает компаниям Lucerne и Dinner Now визуализировать место платежной системы компании Lucerne в бизнес-процессе.В этом выпуске комментарии используются для идентификации ролей, выполняющих шаги.Линии служат для создания дорожек, которые упорядочивают шаги по ролям.

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

Раньше в компании Dinner Now эти схемы рисовались на доске или в программе PowerPoint.Теперь они также используют Visual Studio Ultimate для создания этих схем, поэтому обе команды могут фиксировать и изучать детали, а также управлять ими.

Пример

• UML-схемы деятельности: справочные материалы

• UML-схемы деятельности: рекомендации

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

Схема деятельности имеет следующие основные составляющие.

• Начальный узел, указывающий первое действие деятельности.

  На схеме обязательно должен присутствовать один из таких узлов.

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

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

• Узлы принятия решения, представляющие условные ветви потока.

• Узлы ветвления, разделяющие единые потоки на параллельные потоки.

• Конечные узлы деятельности, обозначающие завершение деятельности.

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

Пример

• UML-схемы деятельности: справочные материалы

• UML-схемы деятельности: рекомендации

Сводка. Преимущества схем деятельности

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

Отношение к другим схемам

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

Описание структуры системы: схемы компонентов

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

Чтобы помочь компаниям Lucerne и Dinner Now визуализировать и обсуждать компоненты системы и их интерфейсы, были созданы следующие схемы компонентов:

Компоненты платежной системы компании Dinner Now

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

Для использования платежной системы компании Lucerne необходимо обновить веб-сайт компании Dinner Now, чтобы он использовал интерфейсы PaymentApproval и PayableInsertion платежной системы компании Lucerne.

На следующей схеме показана конкретная конфигурация компонентов для веб-сайта компании Dinner Now.Эта конфигурация показывает, что любой экземпляр этого веб-сайта состоит из четырех частей.

• CustomerProcessing

• OrderProcessing

• ReviewProcessing

• PaymentProcessing

Эти части являются экземплярами компонентов указанных типов и связаны следующим образом:

Компоненты внутри веб-сайта компании Dinner Now

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

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

Пример

• Схемы компонентов UML: справочные материалы

• UML-схемы компонентов: правила работы

Создание схемы компонентов

Схема компонентов имеет следующие основные составляющие.

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

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

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

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

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

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

Пример

• Схемы компонентов UML: справочные материалы

• UML-схемы компонентов: правила работы

Сводка. Преимущества схем компонентов

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

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

• Компоненты с четко определенными интерфейсами, что упрощает понимание и обновление дизайна при изменении требований.

Отношение к другим схемам

Схема	Описание
Граф зависимостей	Визуализация организации и связей в имеющемся коде. Чтобы идентифицировать кандидаты в компоненты, создайте граф зависимостей и сгруппируйте элементы по их функции в системе. Пример Визуализация зависимостей кода на графах зависимостей Изменение и настройка графов зависимостей
Схема последовательностей	Визуализация последовательности взаимодействий между компонентами или частями внутри компонента. Чтобы создать из компонента линию жизни на схеме последовательностей, щелкните правой кнопкой мыши компонент, затем выберите Создать линию жизни. Пример UML-схемы последовательностей: справочные материалы UML-схемы последовательностей: правила работы
Схема классов (UML)	Определение интерфейсов на предусмотренных или необходимых портах и классов, реализующих функциональность компонентов. Пример UML-схемы классов: справочные материалы UML-схемы классов: правила работы
Схема слоев	Описание логической архитектуры системы относительно компонентов.Выполните проверку слоев, чтобы удостовериться, что код соответствует дизайну. Пример Создание схем слоев из кода Схемы слоев: справочные материалы Схемы слоев: рекомендации Проверка кода по схеме слоев
Схема деятельности	Визуализация внутренней обработки, выполняемой компонентами в ответ на входящие сообщения. Пример UML-схемы деятельности: справочные материалы UML-схемы деятельности: рекомендации

Визуализация существующего кода: графы зависимостей

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

• Изучение незнакомого кода.

• Понимание места и способа возможного влияния изменения на имеющийся код.

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

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

На следующем графе показаны зависимости между классом PaymentProcessing и другими частями системы компании Dinner Now, которые выделены на графе:

Граф зависимостей для платежной системы компании Dinner Now

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

Методы внутри класса PaymentProcessing и их зависимости

Они создают следующий граф для платежной системы компании Lucerne, чтобы изучить ее классы, методы и зависимости.Команда обнаруживает, что система компании Lucerne также может потребовать доработки для взаимодействия с другими частями компании Dinner Now:

Граф зависимостей для платежной системы компании Lucerne

Обе команды совместно определяют изменения, необходимые для интеграции двух систем.Они решают произвести рефакторинг части кода, чтобы его было проще обновить.Класс PaymentApprover будет перемещен в пространство имен DinnerNow.Business и ему потребуются несколько новых методов.Классы Dinner Now, обрабатывающие транзакции, будут иметь собственное пространство имен.Команды создают и используют рабочие элементы для планирования, упорядочивания и отслеживания своей работы.Там, где это полезно, они связывают рабочие элементы с элементами модели.

После реорганизации кода команды создают новый граф зависимостей для просмотра обновленной структуры и связей:

Граф зависимостей с реорганизованным кодом

Этот граф показывает, что класс PaymentApprover теперь перемещен в пространство имен DinnerNow.Business и имеет несколько новых методов.Классы транзакций компании Dinner Now теперь имеют собственное пространство имен PaymentSystem, что упрощает последующую работу с кодом.

Создание графа зависимостей

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

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

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

  Дополнительные сведения см. в разделе Визуализация зависимостей кода на графах зависимостей.

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

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

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

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

• Чтобы сфокусироваться на определенных областях графа, настройте область действия, отфильтровав элементы или настроив их внешний вид.Дополнительные сведения см. в разделе Изменение и настройка графов зависимостей.

Сводка. Преимущества графов зависимостей

Графы зависимостей помогают в выполнении следующих задач.

• Изучение организации и связей в имеющемся коде.

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

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

Отношение к другим схемам

Схема	Описывает
Схема слоев	Логическая архитектура системы.Выполните проверку слоев, чтобы удостовериться, что код соответствует дизайну. Чтобы помочь идентифицировать существующие или предполагаемые слои, создайте граф зависимостей и сгруппируйте соответствующие элементы.Чтобы создать схему слоев, перетащите элементы из графа или обозревателя архитектуры. Пример Создание схем слоев из кода Схемы слоев: справочные материалы Схемы слоев: рекомендации Проверка кода по схеме слоев
схема компонентов	Компоненты, их интерфейсы и их отношения. Чтобы помочь идентифицировать кандидаты в компоненты, создайте граф зависимостей и сгруппируйте элементы по их функции в системе. Пример Схемы компонентов UML: справочные материалы UML-схемы компонентов: правила работы
Схема классов (UML)	Классы, их атрибуты и операции, а также их связи. Чтобы помочь идентифицировать эти элементы, создайте документ графа, показывающего эти элементы. Пример UML-схемы классов: справочные материалы UML-схемы классов: правила работы
Схема классов (основанная на коде)	Существующие классы в коде. Чтобы визуализировать и изменить существующий класс в коде, используйте конструктор классов. Дополнительные сведения см. в разделе Практическое руководство. Добавление схем классов в проекты (конструктор классов).

Описание взаимодействий: схемы последовательностей

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

Чтобы помочь компаниям Lucerne и Dinner Now описать и обсудить этапы в варианте использования "Обработка платежа", была создана следующая схема последовательностей на основе схемы компонентов.Линии жизни отражают компоненты веб-сайта компании Dinner Now и его части.Сообщения, отображаемые между линиями жизни, следуют соединениям на схемах компонентов:

Схема последовательностей для варианта использования "Обработка платежа"

Схема последовательностей показывает, что когда клиент создает заказ, веб-сайт компании Dinner Now вызывает метод ProcessOrder в экземпляре класса OrderProcessing.Затем класс OrderProcessing вызывает метод ProcessPayment класса PaymentProcessing.Это продолжается до тех пор, пока шлюз внешней службы обработки платежей не подтвердит платеж.Только после этого управление возвращается веб-сайту компании Dinner Now.

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

Пример

• UML-схемы последовательностей: справочные материалы

• UML-схемы последовательностей: правила работы

• Визуализация кода путем создания на схем последовательностей

Создание схемы последовательностей

Схема последовательностей имеет следующие основные составляющие.

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

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

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

• В случае синхронного сообщения объект-отправитель ожидает <<возврата>> управления, как при обычном вызове функции.В случае асинхронного сообщения отправитель может сразу же продолжить работу.

• Используйте сообщения <<создать>> для указания создания объектов другими объектами.Оно должно быть первым сообщением, отправленным объекту.

Пример

• UML-схемы последовательностей: справочные материалы

• UML-схемы последовательностей: правила работы

Сводка. Преимущества схем последовательностей

Схемы последовательностей помогают визуализировать следующее.

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

• Реализация вызова метода или сообщения.

Отношение к другим схемам

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

Определение глоссария типов: схемы классов

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

Чтобы помочь компании Lucerne описать и обсудить сущности, участвующие в варианте использования "Обработка платежа", была создана следующая схема классов:

Сущности обработки платежа на схеме классов

Эта схема показывает, что у клиента может быть много заказов и много способов оплаты заказов.BankAccount и CreditCard наследуют от класса Payment.

Во время разработки компания Lucerne использует следующую схему классов для описания и обсуждения деталей каждого класса:

Детали обработки платежа на схеме классов

Пример

• UML-схемы классов: справочные материалы

• UML-схемы классов: правила работы

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

Схема классов имеет следующие основные составляющие.

• Типы, такие как классы, интерфейсы и перечисления.

  • Класс — это определение объектов, совместно обладающих определенными характеристиками структуры и поведения.

  • Интерфейс определяет часть внешне видимого поведения объекта.

  • Перечисление — это классификатор, содержащий список литеральных значений.

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

• Операции — это методы или функции, которые могут выполняться экземплярами классификатора.

• Ассоциация указывает некоторый вид отношения между двумя классификаторами.

  • Агрегат — это ассоциация, указывающая на общее владение между классификаторами.

  • Композиция — это ассоциация, указывающая на отношение целого и части между классификаторами.

  Чтобы показать агрегаты или композиции, задайте свойство Агрегат у ассоциации.Общий указывает на агрегаты, а Составной указывает на композиции.

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

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

  Чтобы создать эти связи, используйте инструмент Наследование.Реализация может также представляться как интерфейс без описания операций.

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

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

Пример

• UML-схемы классов: справочные материалы

• UML-схемы классов: правила работы

• Практическое руководство. Добавление схем классов в проекты (конструктор классов)

Сводка. Преимущества схем классов

Схемы классов помогают определить следующее.

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

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

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

Отношение к другим схемам

Схема	Описание
Схема вариантов использования	Определение типов, используемых для описания целей и шагов в вариантах использования. Пример UML-схемы вариантов использования: справочные материалы UML-схемы вариантов использования: правила работы
Схема деятельности	Определение типов данных, передаваемых через узлы объекта, закрепления ввода, закрепления вывода и узлы параметров действий. Пример UML-схемы деятельности: справочные материалы UML-схемы деятельности: рекомендации
схема компонентов	Описание компонентов, их интерфейсов и отношений.Класс может также описывать полный компонент. Пример Схемы компонентов UML: справочные материалы UML-схемы компонентов: правила работы
Схема слоев	Определение логической архитектуры системы относительно классов. Выполните проверку слоев, чтобы удостовериться, что код соответствует дизайну. Пример Создание схем слоев из кода Схемы слоев: справочные материалы Схемы слоев: рекомендации Проверка кода по схеме слоев
Схема последовательностей	Определение типов линий жизни, а также операций, параметров и возвращаемых значений для всех сообщений, которые может принимать линия жизни. Чтобы создать линию жизни из типа на схеме классов, щелкните тип правой кнопкой мыши и выберите Создать линию жизни. Пример UML-схемы последовательностей: справочные материалы UML-схемы последовательностей: правила работы
Граф зависимостей	Визуализация организации и связей в имеющемся коде. Чтобы идентифицировать классы, их связи и методы, создайте документ графа, показывающего эти элементы. Пример Визуализация зависимостей кода на графах зависимостей Изменение и настройка графов зависимостей

Описание логической архитектуры: схемы слоев

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

Чтобы обеспечить соответствие кода дизайну, компании Dinner Now и Lucerne используют следующую схему слоев для проверки кода по мере его разработки:

Схема слоев для интеграции компании Dinner Now с компанией Lucerne

Слои на этой схеме связаны с соответствующими артефактами решений компаний Dinner Now и Lucerne.Например, слой "Бизнес" связан с пространством имен DinnerNow.Business и его членами, в число которых теперь входит класс PaymentApprover.Слой "Доступ к ресурсам" связан с пространством имен DinnerNow.Data.Стрелки, или зависимости, указывают, что функциональность слоя "Доступ к ресурсам" может использоваться только слоем "Бизнес".По мере того как команды обновляют свой код, регулярно выполняется проверка слоев для выявления возникающих конфликтов и их быстрого устранения командами.

Команды совместно работают для пошаговой интеграции и тестирования двух систем.Перед тем как начинать работать с PaymentProcessing, команды убеждаются, что класс PaymentApprover и остальная часть системы Dinner Now успешно работают друг с другом.

На следующем графе зависимостей показаны новые вызовы между системой компании Dinner Now и классом PaymentApprover:

Граф зависимостей с обновленными вызовами методов

После проверки правильности работы системы команда Dinner Now исключает код PaymentProcessing, переводя его в комментарии.Отчеты проверки слоев не содержат ошибок, и получающийся граф зависимостей показывает, что зависимостей от PaymentProcessing больше не существует:

Граф зависимостей без PaymentProcessing

Пример

• Создание схем слоев из кода

• Схемы слоев: справочные материалы

• Схемы слоев: рекомендации

• Проверка кода по схеме слоев

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

Схема слоев имеет следующие основные составляющие.

• Слои описывают логические группы артефактов.

• Связь — это ассоциация между слоем и артефактом.

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

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

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

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

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

  Для просмотра связанных со слоем артефактов щелкните слой правой кнопкой мыши и выберите Просмотр ссылок, чтобы открыть Обозреватель слоев.

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

  Чтобы отобразить существующие зависимости на схеме слоев, щелкните правой кнопкой мыши на поверхности схемы, затем выберите Создать зависимости.Чтобы описать требуемые зависимости, нарисуйте новые зависимости.

Пример

• Создание схем слоев из кода

• Схемы слоев: справочные материалы

• Схемы слоев: рекомендации

• Проверка кода по схеме слоев

Сводка. Преимущества схем слоев

Схемы слоев помогают выполнять следующие задачи.

• Описание логической архитектуры системы в соответствии с функциональностью ее артефактов.

• Обеспечение соответствия разрабатываемого кода указанному дизайну.

Отношение к другим схемам

Схема	Описание
Граф зависимостей	Визуализация организации и связей в имеющемся коде. Чтобы создать слои, создайте граф зависимостей, затем сгруппируйте элементы на графе как потенциальные слои.Перетащите группы с графа на схему слоев. Пример Визуализация зависимостей кода на графах зависимостей Просмотр и реорганизация графов зависимостей Изменение и настройка графов зависимостей
схема компонентов	Описание компонентов, их интерфейсов и отношений. Чтобы визуализировать слои, создайте схему компонентов, описывающую функции различных компонентов в системе. Пример Схемы компонентов 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

См. также

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

Визуализация и понимание кода

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

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

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

Проверка системы в ходе разработки

Расширение моделей и схем UML