Руководство по инструментам архитектуры Visual Studio. Введение
Posted by Shamrai Alexander на 25 апреля, 2013
Введение
Описание
|
Данное руководство следует использовать в сочетании с документацией по продукту в Microsoft Developer Network (MSDN) и устанавливается вместе с продуктом. |
Добро пожаловать в Руководство по инструментам архитектуры Visual Studio.
Это руководство описывает сценарии использования Visual Studio Ultimate, главным образом опираясь на инструменты моделирования, чтобы помочь вам понять инструменты и убедиться, что ваша система соответствует ожидаемым требованиям.
Сценарии включают понимание и изучение существующего решения и разработку с нуля нового решения. Это общие задачи, стоящие перед любым аналитиком или архитектором. Целью является не дать вам углубленный тур по возможностям продукта, а представить вам примеры, которые показывают, как эти инструменты могут помочь вам в распространенных сценариях и предоставить вам практическое руководство и справочные материалы.
Visual Studio ALM Rangers
Это руководство было создано в проекте Visual Studio ALM Rangers. Visual Studio ALM Rangers представляют собой особую группу, состоящую из членов группы продуктов Visual Studio, службы Майкрософт, Microsoft Most Valued Professionals (MVP) и Visual Studio Community Leads. Их миссия – обеспечить решения в виде практического руководства и расширений основных продуктов линейки.
Целевая аудитория этого руководства пользователи Visual Studio Ultimate «уровня 200-300»: средний и продвинутый пользователь, который имеет глубокое понимание возможностей продукта в реальной среде. Части этого руководства могут оказаться полезным для новичков и экспертов TFS, но пользователи на этих уровнях квалификации не являются целевой аудиторией данного руководства.
Сценарии
Описание
|
Основным фокусом данного руководства является не объяснение всех возможностей Visual Studio, а дать практическое руководство по эффективному использованию инструмента. |
В этом разделе приведены примеры общих ситуаций, которые команды могут найти для себя при проектировании нового решения (зеленое поле) или расширения существующего решения (коричневое поле). Сценарии, описанные здесь, должны позволить команде быстро понять архитектуру инструментов и параметров визуализации, которые доступны для них, и сценарии должны обеспечить необходимую платформу для команды в использовании инструментов для более эффективного решения их потребностей.
Важно отметить, что хотя эти сценарии представляют параметры для конкретных ситуаций, невозможно определить общий подход, который является столь же действительным для всех команд, действующих в различных средах и ограничениях.
Чтобы сделать большую часть этих сценариев, важно понять, как работают инструменты моделирования Visual Studio. Это руководство не объясняет, как работают инструменты в деталях, а скорее то, что вы можете достичь с ними. Смотрите MSDN для получения детальной информации о Visual Studio, управлении жизненным циклом приложения и инструментах архитектуры.
Если вы являетесь опытным пользователем среды совместного моделирования и интересуетесь основными сценариями, мы предполагаем, что вы пропустите раздел Описание и сосредоточитесь на выборе соответствующего сценария.
Познакомимся со средой совместной работы
Это руководство сосредоточено на практических путях эффективного использования Visual Studio 2012 Ultimate и других инструментов для создания нового или пересмотра существующего проектирования в рамках управления жизненным циклом приложений. Прежде чем мы перейдем к некоторым из общих сценариев, мы кратко отвлечемся на знакомство со средой совместной работы и выделим некоторые из основных принципов проектирования, которые мы должны принять при использовании инструментов.
Среда совместной работы имеет важное значение для достижения двух наших основных целей: понимание предметной области и прозрачное использование выводов и решений со всеми заинтересованными сторонами. Понимание этой проблемы включает в себя: анализ предметной области; определение потребностей; определение возможных решений. Прозрачное сотрудничество и коммуникации среди всех заинтересованных сторон необходимо для понимания и точного использования требований.
Чтобы быть в состоянии эффективно использовать требования и проектирование системы и архитектуры, вы можете воспользоваться инструментами, такими как доски; бумажные эскизы, UML диаграммы, презентации Microsoft Expression Blend Sketchflow и инструменты архитектуры и функции виртуализации Visual Studio Ultimate в общих рабочих презентациях.
Общие вопросы, которые могут быть в этом случае:
-
Кто должен принимать участие в общих рабочих презентациях?
- Оптимальны ли все заинтересованные стороны, включая архитекторов, разработчиков, тестировщиков, менеджеров продукта, маркетинг, клиентов, поставщиков, экспертов / консультантов и пользователей.
-
Какое оборудование мы должны подготовить?
- Доски.. никогда не может быть достаточно одной доски.
- Цифровая камера для записи диаграмм и примечаний, сделанных на доске.
- Проектор, с высоким разрешением (1024 x 768) должен быть в состоянии отображать диаграммы высокого качества и потенциально большой дизайн.
- Возможности для проведения конференций и совещаний (например, Microsoft LiveMeeting и единая служба конференций) если заинтересованные стороны географически удалены.
|
Цель открытого общения и обмена идеями – это не только точно понять требования и придумать лучшее решение, но что еще более важно создать общее видение для решения. |
Смотрите Планирование и отслеживание проектов для более детальной информации.
Некоторые основные принципы проектирования
После того, как у нас есть инфраструктура, оборудование и инструменты в одном месте, мы можем начать проектирование системы, моделирование и документирование. Ниже приведены некоторые основные принципы проектирования, которые мы должны принять в рамках этого руководства:
- Коллективная собственность. Архитектура системы, модели и артефакты должны принадлежать команде, снова продвижение прозрачности и обеспечение, что любой может работать с любым артефактом, если это необходимо.
- Открытое мышление. Проектирование, обсуждение и общение должны основываться на открытости. Поощрять обсуждения, вопросы о таких вещах, как решения по проектированию или технологические решения и изучение возможных вариантов. Прелесть использования визуализации и моделирования, например, является то, что возможно и экономически эффективно пересмотреть, изменить или даже переработать проектирование на раннем этапе жизненного цикла приложения.
- Придерживаться простоте. Лучший дизайн и лучшие модели являются те, которые интуитивно понятны и могут быть оценены и поняты с малыми усилиями или объяснениями. Придерживаться простоте: измените ваш дизайн и связанные модели, если сложность высока, следует избегать добавления ненужных моделей, содержимого в модели, аспекты и возможности.
- Централизованный и простой репозиторий. Артефакты проектирования должны храниться в одном и легко доступном хранилище.
- Создать соответствующие артефакты. Это точка, которая приближает нас к инструментам и практическим сценариям, на которых основано это руководство. Каждый артефакт, будь то документ word, UML-схема или тематическое исследование, имеет конкретную цель и используется для передачи тысяч слов в одной картине. Изучение вариантов проектирования лучше всего делать на доске и использовать такие инструменты, как Visual Studio Ultimate для создания различных схем, таких как UML диаграммы активности, компонентов и последовательности. Понимание, как эффективно использовать инструменты визуализации и моделирования Visual Studio Ultimate в различных общих сценариях, является основным фокусом данного руководства.
Смотрите Agile Principles and Values для более детальной информации.
Используйте хороший процесс для команды
Построение передовых технологий и конкурентоспособных систем является сложной задачей, особенно когда требования или выбор технологии являются неопределенными. Важно, чтобы вы дали вашей команде процесс или основу, которая способствует прозрачности, самоорганизации и сотрудничеству для получения оптимального результата от системы, которая основана на визуализации и моделировании с использованием UML-диаграмм. Рассмотрите agile процессы, такие как платформа Scrum. Смотрите Scrum для получения дополнительной информации.
|
«Рисунок представит мне то, что в книге изложено на целых десяти страницах» … было сказано персонажем романа Отцы и Дети у Ивана Тургенева в 1862. |
Используйте передовые практики
При использовании модели для визуализации системы с помощью модели исследуйте и обменивайтесь надлежащими практиками и опытом в команде для принятия эмпирического процесса. К примеру, очень полезно приложить краткие описания целей для варианта использования и рисовать схемы классов на основе существительных, упомянутых в описании вариантов использования.
Смотрите Определение терминов для описания требований для более детальной информации.
Делайте общими артефакты
Во время и после завершения сценария необходимо не только делиться и делать все артефакты легко доступными, но также публично отображать ключевые модели, диаграммы и визуализации. Найдите физические или виртуальные стены, на которых можно отобразить актуальную визуализацию для каждого, рассказать об этом и легко дать откровенный отзыв. Целью открытого обмена ключевыми артефактами должно быть максимально прозрачное выявление открытой обратной связи с точки зрения возникающей архитектуры, идей и потенциального влияния на другие и неизвестные среды.
Демпинг (скрытие) тысяч UML-диаграмм в электронное хранилище может служить политикам резервной копии и хранилища, но вряд ли вызовут обратную связь от команды. Однако отображение формирующейся архитектуры на доске в кофе-зоне будет поддерживать специализированное сотрудничества, обмен идеями и добавление комментариев в модели лицами, которым приятно пообщаться и выпить чашечку кофе в неформальной обстановке.
Выберите соответствующие сценарии этого руководства
Сценарии делятся на две основные категории, а именно сценарий «новой» и «существующей» системы.
Первый касается создания моделей для новых систем или новой документации, тогда как последний связан более с использованием инструмента для понимания существующей системы.
Выберите соответствующие сценарии из предыдущей схемы и перейдите по ссылке в таблице:
Примеры кода, используемые как часть сценариев
Примеры кода, которые использовались при подготовке этого руководства, основываются на примере приложения Microsoft Tailspin, который доступен как часть руководства HOL download и примера Pet Shop sample application.
Представление структуры архитектуры системы
Визуализация и диаграммы позволяют вам понять потребности пользователей и мир, в котором система должна работать; определить архитектуру для системы; выполнить анализ системы; и для проверки соответствия системы требованиям.
Прежде чем создавать визуализацию и диаграмму важно понять, как организовать их для лучшего эффекта.
Общий подход заключается в организации диаграмм сначала по типу, затем по модулям и — в зависимости от размера системы — на нескольких уровнях.
В данном документе рассматриваются сценарии сосредоточенные на организации артефактов архитектуры, например, организация артефактов проектирования и структуры решения с помощью представления модели 4 + 1.
Общее описание диаграмм
В следующей таблице приведено описание диаграмм, доступных в Visual Studio Ultimate:
| Диаграмма | Описание | Используется для … |
| UML Activity Diagram | Показывает рабочий процесс деятельности и действий. | Проектирования алгоритмов бизнес-процессов |
| UML Class Diagram | Показывает структуру классов и интерфейсов и поток данных между классами. | Высокоуровневого проектирования концепции требований |
| UML Component | Показывает структуру частей системы. | Проектирования высокого уровня. |
| UML Use Case Diagram | Показывает взаимодействие субъектов и внешних систем с системой | Описания требований пользователя |
| UML Sequence | Показывает взаимодействие объектов и последовательность сообщений | Проектирования высокого уровня. |
| .Net Sequence Diagram | Показывает взаимодействие объектов и последовательность сообщений | Анализа кода |
| .NET Class | Показывает классы и интерфейсы в коде | Анализа кода и визуализации проектирования высокого уровня |
| Dependency Graphs | Показывает комплексную структуру ваших классов и дерево вызовов | Анализа кода |
| Layer Diagram | Показывает структуру системы на высоком уровне и зависимости между классами | Анализа кода |
Проверки кода
Смотрите Использование моделей в процессе разработки для более детальной информации.
Первый взгляд на руководство
| ВАЖНОЕ ЗАМЕЧАНИЕ |
Основные сценарии и представление на рисунке Первый взгляд на основные сценарии основаны на обратной связи от специальных «Microsoft Most Valued Professionals (MVP)», чтобы обеспечить, что мы представляем руководство, основанное на различных группах, которые имеют хороший опыт разработки архитектуры для широкого круга клиентов в самых различных методологиях.
Ни визуализация, ни руководство основных сценариев не намереваются показать только одно решение проблемы. Как отмечалось в руководстве, очень важно проверить руководящие принципы на основе вашей окружающей среды и ваших практик, регулируя в случае необходимости.
Рисунок Первый взгляд на основные сценарии обобщает основные сценарии, как указано в настоящем руководстве, с одним из потенциально многих возможных естественных потоков и преобразования из одной типа диаграммы в другой.
Диаграмма не имеет ничего общего с любой методологией, такой как водопад, RUP, XP или Scrum, и поэтому не должны восприниматься таковыми. Иллюстрация будет снова появляться с каждым основным сценарием, покрывающим соответствующую область, выделенную в настоящем руководстве, которую по нашему мнению отображает сценарий.
Рисунок Среда моделирования архитектуры решения является иной точкой зрения, которая показывает то же руководство на более высоком уровне, без ссылки на предлагаемый естественный поток и преобразования в основном сценарии руководства.
Первый взгляд на основные сценарии
Среда моделирования архитектуры решения
Заметки консультанта 
Оставьте комментарий