Руководство по инструментам архитектуры Visual Studio. Сценарий — мне нужно изучить существующую систему

<<Перейти к содержанию

Сценарий изучения существующей системы

Описание

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

Visual Studio Ultimate может помочь нам в сценарии анализа существующего системы в ситуациях, таких, как:

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

Инструменты архитектуры в Visual Studio Ultimate помогают нам визуализировать организацию, связи, шаблоны проектирования и поведение (части) существующей системы программного обеспечения в последовательном, повторяемом и стандартизированном виде.

ВОПРОСЫ Почему важно определить шаблоны проектирования, которые используются в существующей системе? Зачем нам нужно представление проектирования высокого уровня?

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

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

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

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

1. Выявление моделей и общей структуры приложения на высоком уровне.
2. Понимание метода или конкретного потока в деталях на более низком уровне детализации.

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

ВОПРОСЫ Как мы начать сценарий обратного инжиниринга?

Это зависит от типа и уровня детализации, который вам нужен.

Например:

• Для изучения существующих зависимостей кода с целью выявления циклических ссылок или зависимости между сборками или пространствами имен, следует создать Dependency Graph.
• Для описания структуры приложения на высоком уровне и проверки, что детализирующий код соответствует этому дизайну высокого уровня, вы должны создать Layer Diagram.
• Чтобы получить обзор системы или найти существующий код, следует использовать Architecture Explorer или Solution Explorer.
• Чтобы изучить последовательность сообщений между типичными экземплярами классов следует сформировать Sequence Diagram.
• Чтобы увидеть структуру класса из существующего кода следует создать Class Diagram.
• Для визуализации системы в крупных блоках, чтобы помочь группе разработчиков понять существующий дизайн и развивать его, вы должны создать Component Diagram.

РЕКОМЕНДАЦИИ Смотрите «Сценарий — мне нужна повторно используемая (повторяемая) архитектура», прежде чем приступить к рабочему процессу обратного инжиниринга.

Рабочий процесс

ПРИМЕЧАНИЕ Миграция решения/проектов/ проекта моделирования является автоматическим процессом в Visual Studio 2012, который позволяет вам работать с Visual Studio 2010 и Visual Studio 2012. Исключение из этого правила совместимости являются расширения Visual Studio, поскольку они ориентированы на конкретный выпуск visual studio.

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

Рабочий процесс анализа существующей системы

Получить артефакты реализации

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

ПРИМЕЧАНИЕ Не обязательно добавлять типовой проект в решение для всех сценариев обратного инжиниринга – графы и диаграммы последовательностей не требуют этого-однако это обеспечивает удобное место для хранения всех моделей или изображений.

Смотрите «Сценарий — мне нужна повторно используемая (повторяемая) архитектура», для получения дополнительной информации о структуризации решения в содействии повторно используемой архитектуре.

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

Чтобы лучше понять отношения и организация в системе можно создавать графы зависимостей.

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

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

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

Легенды в DEV 11

НАБЛЮДЕНИЕ Параметр «генерировать для решения» для генерирования графика DGML считается наилучшей практикой. Она очень часто применяется при наличии нескольких пространств имен в сборке и особенно при использовании архитектуры на основе руководства шаблонов и практики приложений архитектуры 2.0, эта опция дает вам представление, которое сразу же показывает любые логические разделения в рамках архитектуры. Однако считать это наилучшей практикой является довольно субъективным – иногда представление решения служит вам лучше, если вы пытаетесь разобраться в перекрестных бинарных зависимостях, особенно если вы рассматриваете развертывание.

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

Вы можете найти узел по имени, используя для поиска через несколько уровней сгруппированных узлов. Нажмите CTRL + F для открытия окна поиска в графе зависимостей.

Поиск в графе зависимостей

Другие возможности для клавиатуры и мыши

Наконец в левой части документа также имеется элемент управления масштабом и кнопка масштабировать под размер окна.

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

• Исходный и компилированный код Visual C# .NET и .NET Visual Basic, такой как файлы .NET сборки (.dll) и исполняемые файлы (.exe)
• Исходный код, заголовки (.h или #include) Visual C# и Visual C++ и двоичные файлы (управляемые или машинные)

НАБЛЮДЕНИЕ При открытии решения, содержащего проекты Visual C# или Visual C++, может занять некоторое время для обновления базы данных IntelliSense. В это время, возможности генерирования графиков зависимости для файлов заголовка (.h или #include), могут быть недоступны, пока базы данных IntelliSense не закончит свое обновление. Вы можете контролировать ход выполнения этих обновлений в строке состояния Visual Studio. Для создания графов зависимостей для управляемого и машинного кода, необходимо использовать параметры «For Solution», и только для машинного кода использовать «For Include File».

Опции графа зависимостей

Обратите внимание, что:

• Импорт XMI является частью продукта
• Экспорта XMI нет в продукте, но доступно в виде исходного кода в примерах Vs VmSdk: XMI Exporter Extension for UML Designers

ПРИМЕЧАНИЕ Не обязательно добавлять проект моделирования в решение для всех сценариев обратного инжиниринга – графы и диаграммы последовательностей не требуют этого-однако это обеспечивает удобное место для хранения всех моделей или изображений.

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

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

Когда вы назначили артефакты кода слоям, вы можете рисовать стрелки для представления зависимости, которые вы хотите разрешить, или вы можете из Visual Studio сгенерировать текущие зависимости, а затем изменить их.

Диаграмма слоя может также использоваться для проверки архитектуры в будущем, обеспечивая, что изменения в коде не случайно вводят новые зависимости. СмотритеHow to: Validate Code Against Layer Diagrams и Layer Validation with the VSTS 2010 CTP для получения дополнительной информации.

Диаграмма слоев

Обозреватель архитектуры

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

Обозреватель архитектуры

Обозреватель решения

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

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

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

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

Команды обозревателя решений для изучения связей

Диаграммы последовательности

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

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

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

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

Диаграмма последовательностей

Схемы классов

Есть также два вида диаграмм классов:

• .NET диаграмма классов генерируется из кода, может быть добавлена к любому проекту кода и не является частью модели UML.
• UML-схема классов является частью модели UML и обычно создается вручную, чтобы помочь описать логические аспекты проектирования. Можно также создавать UML-схемы классов из кода. Путем перетаскивания классов из обозревателя архитектуры или обозревателя решений на схему классов, вы можете решить какие части кода вы хотели бы визуализировать.
• С использованием Visual Studio вы также сможете рассмотреть генерирование кода, которое позволяет вам создавать не только диаграмму из кода, но и из диаграммы также получать код.

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

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

Диаграмма классов .NET

Создание других диаграмм

Наконец если вы хотите реализовать новую функцию в существующей системе, можно использовать другие UML-диаграмм. Для получения дополнительных сведений о том, как использовать UML-диаграммы посетите Developing Models for Software Design в библиотеке MSDN.

РЕКОМЕНДАЦИИ Смотрите «Visual Studio 2012 Architecture Guidance – Reverse Engineering HOL» для пошаговой инструкции данного сценария.

<<Перейти к содержанию

Руководство по инструментам архитектуры Visual Studio. Сценарий — Мне необходимо начать разработку новой системы

<<Перейти к содержанию

РЕКОМЕНДАЦИИ Мы рекомендуем, чтобы вы рассмотрели сценарий «Сценарий — мне необходима повторно используемая (повторяемая) архитектура» перед переходом к сценарию с новой системой.

Visual Studio Ultimate поможет вам по пути успешного построения новой системы. Сочетание инструментов Unified Model Language (UML) и итеративный подход может помочь вам постепенно:

• Определить требования
• Создать многоуровневую архитектуру с подходящей абстракцией для объектно-ориентированного подхода
• Разработать потоки команд управления между компонентами и классами

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

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

Рабочий процесс сценария создания новой системы

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

Рекомендуется использовать итеративный подход и избегать попыток моделировать всю систему за один раз («Абсолютный большой дизайн»). Создайте наброски модели в первых итерациях и затем в каждой последующей итерации, детализируйте функциональные возможности, которые будут рассмотрены в этой итерации. Разрабатывайте тесты, которые отражают модель максимально близко и проверяйте код на основе этих тестов. Извлекайте уроки во время кодирования и отображайте их обратно в модели. Таким образом, процесс моделирования и процесс разработки синхронизируются с помощью итеративного подхода.

Рабочий процесс

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

1. Определение архитектуры – этот рабочий поток содержит мероприятия для синергизма форм системы: слои, компоненты и классы
2. Выявление субъектов/вариантов использования – этот рабочий поток содержит мероприятия, посредством которых мы определим пользователей и их цели использования системы
3. Определить поведение – этот рабочий поток содержит мероприятия для определения динамического поведения системы и связанной с ним архитектурой
4. Рецензирование модели – этот рабочий поток позволяет другим членам команды обеспечить понимание и дать комментарии для модели архитектуры
5. Разработка системы – этот рабочий поток содержит необходимые процесс для разработки куска модели и обеспечения обратной связи, так чтоб будущие активности моделирования оставались в синхронизации с кодом

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

Определение архитектуры

Многие типы приложений следуют установленным архитектурным шаблонам. Эти шаблоны предоставляют вам стандартные решения, которые имеют хорошие инженерные характеристики, такие как прозрачное разделение проблем. Использование знакомых шаблонов упрощает разработчикам понимание приложений и позволяет найти различные части функциональности. Например, диаграмма слоев на рисунке ниже может применяться для любого веб-приложения. Однако применяя этот шаблон к Pet Shop sample application держит нашу архитектуру прозрачной, по крайней мере на самом высоком уровне.

Архитектура слоев высокого уровня для Online Pet Shop

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

Детализированная диаграмма архитектуры слоев

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

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

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

Определение субъектов, вариантов использования и бизнес концепции

Субъект — тип внешней сущности, такая как пользователь или другая система, которая взаимодействует с вашей системой. Некоторые примеры субъектов для приложения веб-зоомагазин являются «Online Customer» и «PayPal». Поскольку приложение Pet Shop ориентировано на Интернет-коммерцию, «Online Customer» является лучшим наименованием субъекта, чем просто «Customer».

Частичная диаграмма вариантов использования для приложения Online Pet Shop

Определите цели каждого субъекта. Представьте каждую цель как вариант использования. Например, многие клиенты хотят просто посмотреть на фотографии собак и кошек прежде чем получить одного из них. Их цель – Просмотр тавара (или может быть «Обзор домашних животных» звучит лучше) до тех пор, пока они не находят нужного. Как только они находят, что они хотели, они, возможно, пожелают добавить в корзину и купить этого питомца.

Варианты использования обычно принимают форму глагола с последующим существительным. Схема вариантов использования на рисунке выше показывает несколько субъектов и вариантов использования для Интернет-зоомагазина. Вариант использования «Purchase Pet(s)» расширяет вариант использования «Browse Inventory» потому что он содержит все функции просмотра, а также некоторые дополнительную функциональность покупки.

Хороший ресурс, который вы можете рассмотреть «Agile Modeling», Scott Ambler.

Смотрите Modeling User Requirements для более подробной информации.

Определение бизнес концепции

Диаграмма классов бизнес-концепции описывает сущности и отношения, которые представляют интерес в разработке. Ключевой задачей является обеспечение понимания командой бизнес-требований, согласованности и использования общей терминологии (глоссария терминов) и что команда фактически строит правильную систему.

Эти классы представляют условия и отношения, которые определены и применимы пользователями. Диаграмма бизнес концепции отвечает на вопросы о требованиях заказчика, например «Товары это список видов животных или список отдельных животных?» или «Каждое животное оценивается индивидуально или оцениваются по виду?»

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

Диаграмма классов для бизнес-концепции

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

Полезно описать результаты каждого варианта использования в терминах сущностей и связей в схеме бизнес-концепции. Например:

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

Убедитесь, что вы можете описать важные результаты каждого варианта использования с точки зрения связей и атрибутов бизнес-концепции, предположений, общего высокого уровня потока требований, критериев успеха и часто встречающихся вариаций. Например, чтобы описать Обзор, требуются только классы Pet и Inventory. Чтобы описать покупку, вам нужно добавить Shopping Cart. Необходим также атрибут Price, который порождает вопрос о том положить его на Pet или Pet Type. Это вопрос, который может потребоваться обсудить с заказчиком, владельцем зоомагазина.

Убедитесь, что вы понимаете то, что вариант использования создает и удаляет все связи. Например, какой вариант использования удаляет связь между Pet и Inventory? Pet удаляется из Inventory как только он добавляется в Shopping Cart? Мы должны добавить к описанию Purchase Pet(s) «… и эти животные удаляются из списка товаров»? Как другой пример, какие варианты использования добавляют или удалять Pet Type из Catalog?

Смотрите UML Use Case Diagrams: Guidelines для получения дополнительной информации и примеров.

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

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

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

Определение поведения

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

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

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

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

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

В Visual Studio Ultimate поддерживаются два типа диаграмм последовательностей. UML-диаграммы последовательностей являются частью UML-модели.

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

Диаграмма последовательностей .Net сгенерированная из ProcessOrder приложения Pet Shop

Рецензирование моделей

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

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

РЕКОМЕНДАЦИИ Смотрите Visual Studio 2012 Architecture Guidance – New System HOL для пошаговой инструкции по этому сценарию.

<<Перейти к содержанию

Руководство по инструментам архитектуры Visual Studio. Сценарий — мне необходима повторно используемая (повторяемая) архитектура

<<Перейти к содержанию

ЦЕЛЬСделать процесс разработки архитектуры повторяемым и хорошо понимаемым для вашей команды. Они должны знать, где найти артефакты архитектуры, для того чтобы они могли использовать их позже в проекте для проверки, генерирования и т.д. Если у вас есть физические или виртуальные стенды, которая видимы для команды, убедитесь, что ключевые артефакты (модели) видимы для обсуждения и обратной связи.

Описание

Подготовка среды

Чтобы успешно реализовать повторяемую архитектуру с использованием средств архитектуры, необходима эталонная архитектура для вашей проблемной области. Можно создать собственные или использовать один из предоставляемых группой шаблонов и практик. Вы можете найти набор ссылок описания архитектуры по следующему адресу: Application Archetypes.

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

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

Шаблоны проекта моделирования Visual Studio

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

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

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

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

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

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

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

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

Проекты моделирования и ссылки решений

НАБЛЮДЕНИЕ Один побочный эффект этого подхода – это независимые друг от друга проекты моделирования (и их основных хранилищ). Это означает, что если разработчик, работающий в уровне представления, создает схему классов в рамках соответствующего проекта, они не будут отражены в общем проекте модели архитектуры в хранилище модели архитектора. Это благословение и проклятие. Таким образом, разработчик может использовать возможности моделирования без изменения в архитектуре, но с другой стороны, модель архитектуры и модели проектирования не могут ссылаться друг на друга. Можно, однако, синхронизировать это вручную или использовать расширяемые API для написания кода, которые позволяют делать это программно.

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

Наиболее часто используется структура, так называемая представление 4+1. Подробно об этом способе структурирования архитектурной документации смотрите в Интернете: 4+1 architectural view model.

Если вы создаете архитектуру на основе Unified Modeling Process и используете представление 4 + 1 для того чтобы разделить артефакты архитектуры, следующая структура модели UML будет хорошей отправной точкой:

Проект моделирования 4+1

После того как вы определили такую структуру для проекта моделирования архитектуры, вы можете сохранить все решение для использования в будущем в качестве шаблона. Чтобы сделать это, можно использовать плагин на сайте MSDN code gallery, который позволяет экспортировать решение Visual Studio как расширение VSIX, которое позволяет создавать позже другим архитекторам в других проектах.

Плагин можно найти в следующем месте: Export Template Wizard.

VS2012 ОПОВЕЩЕНИЕ | ПРЕДУПРЕЖДЕНИЕ Плагин может не быть доступен в бета-версии. В этом случае, вам просто нужно экспортировать шаблон как zip-файл (с использованием существующих команд VS в меню файл), а затем добавить файл zip, содержащий шаблон, в проект VSIX (Add Project | Extensibility | Empty VSIX project).

Следующие шаги показывают процесс создания такого шаблона:

РЕКОМЕНДАЦИИ Смотрите пошаговое руководство для этого сценария: Visual Studio Architecture Guidance – Reusable Architecture HOL

• Создайте новый проект моделирования и создайте структуру пакета, которую вы хотите использовать в качестве шаблона для будущих проектов, такая, как структура, показанная на приложение толстого клиента.
• Теперь в меню файл является новая команда Export Template as VSIX. Нажмите эту кнопку.

Export Template as VSIX

• Выберите проекты, которые вы хотите включить в шаблон

Мастер VSIX – выбор типа шаблона

• На следующей странице мастера укажите имя и описание шаблона

Мастер VSIX – выбор опций шаблона

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

Вы можете найти гораздо больше информации о создании и настройке шаблонов проектов и элементов Visual Studio в следующих местах: Create Reusable Project And Item Templates For Your Development Team

Если вы хотите в дальнейшем создавать шаблоны, можно рассмотреть Feature Builder Power Tool, который находится в галерее Visual Studio. Это позволит вам добавлять руководство и элементы пользовательского меню в шаблон.

Использование корректного UML-профиля

Профили позволяют настраивать UML для конкретных платформ или областей. В профиле вы определяете набор стереотипов UML. Стереотип является тегом, который может быть прикреплен к определенному элементу UML. Например, можно определить стереотип «VB», который пользователь может прикрепить к классу, чтобы пометить его как класс Visual Basic. Можно определить дополнительные свойства стереотипа: любой элемент, помеченный стереотипом, может иметь дополнительные свойства — например, стереотип «VB» может иметь свойство FileName.

Можно определить собственные профили, которые будут использоваться для ваших проектов моделирования. Для того чтобы сделать свой собственный профиль необходимо изменить XML-файл с расширением .profile и запаковать этот файл как VSIX-файл. Этот VSIX-файл затем может быть установлен в каждой среде Visual Studio и использовать профиль как указано.

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

Этот стереотип веб-службы добавляет одно свойство в UML-тип пакет с именем «implementation type» и имеет два различных значения «ASMX» и «WCF».

Определение xml для этого профиля выглядит следующим образом:

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

Для более подробной информации см.: How to: Define a Profile to Extend UML.

Можно генерировать код из модели UML. При создании кода, стереотипы предоставляют пользователю способы создания кода, например, создать веб-службу или класс Visual Basic из UML-класса. Для получения дополнительной информации см. How to Generate Files from a UML Model.

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

Свойства профиля проекта моделирования

Добавление преобразований в стереотипы

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

Это преобразование это то, что вы можете просто задокументировать в руководящем документе архитектуры. Но можно также генерировать код автоматически из вашей модели: How to Generate Files from a UML Model. Дополнительная поддержка в пакете Visual Studio Feature Pack June 2010. Это сейчас есть и в Visual Studio 11.

РЕКОМЕНДАЦИИ Концепцию генерирования кода из диаграмм и анализа кода через диаграммы будет отображено в будущих версиях Rangers Architecture Guidance and Hands-on-Lab (HOL)

Добавление диаграмм слоев в шаблон проекта моделирования

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

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

Диаграмма слоя как часть шаблона проекта моделирования

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

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

Для того чтобы иметь повторяемый шаблон архитектуры можно также сохранить диаграмму слоя для создания как шаблон. Смотрите Visual Studio Architecture Guidance — Extensibility Layer Diagrams – HOL, который показывает этот конкретный сценарий создания и сохранения диаграммы слоя как шаблон.

Существующие шаблоны слоев

Вы можете скачать набор стандартных приложений архитектуры в виде моделей слоев. Эти модели основаны на руководстве лучших практик Майкрософт Microsoft Application Architecture Guide.

Вы можете скачать их Application Architecture Guide Layer Diagrams. Текущий набор архитектур приложений:

• Веб-приложения
• Rich Client-приложение
• Rich Internet приложение
• Приложения служба
• Мобильное приложений

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

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

ПРИМЕЧАНИЕ Ничто не мешает вам создать нескольких решений, каждое из которых может ссылаться на те же проекты.

Меньше значит больше

Если вы хотите иметь эффективные решения Visual Studio и предоставить разработчикам наилучшие возможности, вы должны держать количество проектов в решении как можно меньшим. Это конкретные руководства на основе обратной связи от Microsoft Most Valued Professionals (специалисты MVP) в данной области, которое предлагает общее правило избегать количества проектов более 10 в решении для поддержания производительности и простоты поддержки.

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

ВАЖНОЕ ЗАМЕЧАНИЕ Руководство вокруг решения размера и структуры на основе обратной связи от «Microsoft Most Valued Professionals (MVP)» обеспечивает вам возможность использовать инструменты способами, которые помогут вам делать задачи лучше и получить лучший опыт. Важно подчеркнуть, что руководство не политики, мандат или наилучшие практики, но одно из многих возможных представлений этой области. Вам нужно сверять руководящие принципы на вашей среде и ваших практиках, регулируя их в случае необходимости.

С помощью Visual Studio 2010 и более ранних версий, загрузка файла решения с большим количеством проектов, как правило, занимает значительное время, особенно при использовании системы управления версиями, которая негативно влияет на общую производительность. Очевидно, чем более производительное оборудование сервера и рабочее место разработчика, тем меньше задержек пользователи будут испытывать при загрузке файлов решений и их проектов. Visual Studio 2012 года ввела «асинхронную загрузку решения», которая загружает проекты в фоновом режиме.

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

Разбиение решения на различные решения

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

Структура контроля версий

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

• -Продукт
  • -xx-< слой решения 1>
  • -xx-< слой решения 2>
  • -xx-< слой решения 3>
  • -xx-< слой решения x>
  • -98 – Решение модели
  • -99 — Общие

Структура решения архитектуры

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

• Решение моделирования
  • Проекта Моделирования Слоя слой 1
  • Проекта Моделирования Слоя слой 2
  • Проекта Моделирования Слоя слой x
  • Главный Проект Моделирования
    • UML-диаграммы

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

ОБЕСПЕЧЕНИЕ БЕЗОПАСНОСТИ АКТИВОВ Вы можете решить ограничить изменения схемы слоев только архитекторам. Это может быть сделано путем размещения конкретные разрешений на проект модели слоев в системе управления версиями.

Шаблоны структуры решений

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

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

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

Пример решения для создания компонента веб-сервиса

Ссылки на общие компоненты

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

Это общее расположение помещается в том же корневом месте управления версиями, где и ваше решение, и связывается элементами в решение вместо того, чтобы делать копию. Таким образом, вы держите единый источник для общих активов, и это позволяет вам обновлять файлы в одном месте. Чтобы добавить общий ресурс в проект, щелкните правой кнопкой мыши на проекте и используйте команду Add Existing Item и в диалоговом окне выберите Add as Link на кнопке открыть, как показано на следующем рисунке.

«Add as Link» в команде Add Existing Item

Ссылки на другие части системы не в текущем решении

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

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

РЕКОМЕНДАЦИИ Этот сценарий представляет концепцию создания шаблонов «ваших лучших практик» для вашей среды и кратко охватывает «Как сделать». Мы рекомендуем рассмотреть этот сценарий, прежде чем приступать к любому из других основных сценариев, таких как изучение существующей системы, трассировка, проверки и особенно сценарий новой системы.

<<Перейти к содержанию