Заметки консультанта

Шамрай Александр Владимирович

Posts Tagged ‘архитектура’

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

Posted by Шамрай Александр на Апрель 26, 2013

Перевел очередное руководство от рейнджеров. Данное руководство рассказывает о концепции использования инструментов архитектуры и содержит возможные сценарии и лабораторные работы (переведено пока только руководство). Полный набор материалов по руководству архитектуры можно скачать здесь: http://vsararchitectguide.codeplex.com/

Содержание

    • Описание
    • Visual Studio ALM Rangers
    • Описание
      • Познакомимся со средой совместной работы
      • Некоторые основные принципы проектирования
      • Используйте хороший процесс для команды
      • Используйте передовые практики
      • Делайте общими артефакты
      • Выберите соответствующие сценарии этого руководства
    • Примеры кода, используемые как часть сценариев
    • Представление структуры архитектуры системы
    • Общее описание диаграмм
    • Первый взгляд на руководство
    • Описание
    • Шаблоны проекта моделирования Visual Studio
    • Использование корректного UML-профиля
    • Добавление преобразований в стереотипы
    • Добавление диаграмм слоев в шаблон проекта моделирования
      • Существующие шаблоны слоев
    • Как создать структуру решения, которая проста в обслуживании и имеет централизованные архитектурные артефакты
      • Меньше значит больше
      • Структура контроля версий
      • Структура решения архитектуры
    • Шаблоны структуры решений
      • Ссылки на общие компоненты
      • Ссылки на другие части системы не в текущем решении
    • Рабочий процесс
    • Определение архитектуры
    • Определение субъектов, вариантов использования и бизнес концепции
    • Определение поведения
    • Рецензирование моделей
    • Описание
    • Рабочий процесс
      • Получить артефакты реализации
      • Графы зависимостей
      • Открытие и сохранение логической архитектуры с использованием диаграмм слоев
      • Обозреватель архитектуры
      • Обозреватель решения
      • Диаграммы последовательности
      • Схемы классов
      • Создание других диаграмм
    • Связывание рабочих элементов требований с диаграммами вариантов использования
    • Связывание Варианта Использования с рабочим элементом
    • Обратная связь между рабочими элементами и элементами модели
    • Создание отчетов Трассировок
    • Использование отчетов трассировки для анализа влияния изменений
    • Валидация UML модели
    • Использование UML-модели для тестирования
      • Соображения
    • Валидация ключевых принципов проектирования и соображения
      • Соображения
      • Валидация слоев
      • Ручная валидация проектирования системы
    • Описание
    • Определение элемента графа
    • Последовательность настройки и генерирования DGML
    • Ручная настройка DGML
    • Описание
      • Что такое Domain-Specific Language?
      • Когда использовать язык для определенной области?
    • Роли
    • Жизненный цикл DSL
      • Определить проблемную область
      • Анализ области
      • Моделирование
      • Реализация
      • Развертывание
      • Использование продукта
    • Контрольный список Модели UML
      • Варианты использования / Диаграмма активностей
      • Диаграмма последовательности
      • Диаграмма классов

Posted in Architecture Tooling Guide, Microsoft, Team Foundation Server, Visual Studio | Отмечено: , , | Leave a Comment »

Руководство по инструментам архитектуры Visual Studio. Приложение

Posted by Шамрай Александр на Апрель 26, 2013

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

Контрольный список Модели UML

Следующие контрольные списки являются полезным руководством при проверке вариантов использования, последовательностей и схем классов как части сценария проверки. Контрольные списки были получены из Use Cases and Testing Parts 1,2 and 3 и расширены.

Варианты использования / Диаграмма активностей

ПРИМЕЧАНИЕ
Смотрите сценарий Валидация.

Тестирование синтаксиса

Полнота:

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

Если у вас есть схема классов бизнес-концепции:

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

Корректность:

  • Цели основного субъекта варианта использования выражены как фраза с активным глаголом?
  • Описан ли вариант использования на соответствующем уровне черного/белого ящика?
  • Обязательны ли предварительные условия? Могут они быть гарантированы системой?
  • Неудачные конечные условия защищают интересы всех заинтересованных сторон?
  • Конечные условия успеха удовлетворяют интересы всех заинтересованных сторон?
  • Проходит ли основной успешный сценарий от его триггера до успешного состояния в конце?
  • Правильна ли последовательность шагов действий?
  • Выражен ли каждый шаг в настоящей форме активного глагола как цель, которая движет процесс вперед?
  • Ясно где и почему альтернативные сценарии отходят от основного сценария?
  • Проектные решения (GUI, базы данных,…) исключены из варианта использования?
  • Вариант использования включает отношения «обобщение», «включать» и «расширить» в их полной мере и используются правильно?

Последовательность:

  • Может система фактически доставить к указанной цели?

Если вы описали ограничения к схеме классов бизнес-концепции:

  • Цели вариантов использования соответствуют этим ограничениям?

Тестирование экспертизы проблемной области

Полнота:

  • Все субъекты определены? Вы можете определить конкретного человека, который может играть роль каждого субъекта?
  • Это все, что необходимо разработать?
  • Все внешние к системе условия обрабатываются?
  • Все слова, которые предполагают неполноту («некоторые», «т.д.»…) были удалены?

Корректность:

  • Это то, что вы действительно хотите? Это все, что вы действительно хотите? Это больше, чем вы действительно хотите?

Последовательность:

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

Тестирование трассировки

Полнота:

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

Корректность:

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

Полнота:

  • Варианты использования определяют все функции в рамках системы и ничего вне рамок?
  • Мы можем отследить каждый вариант использования обратно к его требованию(ям)?
  • Можно проследить каждый вариант использования до своей диаграммы класса, последовательности и состояний?

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

ПРИМЕЧАНИЕ
Смотрите сценарий Валидация.

Тестирование синтаксиса

Полнота:

  • Каждый ли объект необходимый для взаимодействия существует на диаграмме?

Корректность:

  • Все не используемые во взаимодействии объекты были удалены со схемы?
  • Линия жизни каждого объекта начинается и заканчивается в надлежащее время?
  • Активация каждого объекта описана должным образом?
  • Если время жизни объекта заканчивается, это отмечается знаком X?
  • Каждое сообщение именовано сильным глаголом?
  • Соответствующие параметры включены для каждого сообщения?
  • Условные ветви отражены правильно?

Последовательность:

  • Условные операторы покрывают все варианты?
  • Любое дублирование условных операторов было удалено?

Тестирование экспертизы проблемной области

Полнота:

  • Все пути, которые могут идти правильно определены и правильно обрабатываются?
  • Все пути, которые могут пойти неправильно определены и правильно обрабатываются?
  • Проходит ли основной успешный сценарий от его триггера до успешного состояния в конце?

Корректность:

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

Тестирование трассировки

Последовательность:

  • Каждый вариант использования представлен по крайней мере одной диаграммой последовательности?
  • Каждый главный субъект существует по крайней мере на одной диаграмме последовательности?

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

ПРИМЕЧАНИЕ
Смотрите сценарий Валидация.

Тестирование синтаксиса

Полнота:

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

Корректность:

  • Все атрибуты частные?
  • Все параметры явные, а не встроены в имена методов?
  • Все подклассы реализуют отношения «разновидность» должным образом?
  • Все объекты представлены явно с помощью состояний и переходов, а не как подклассы?
  • В наследуемых структурах все атрибуты и методы продвинуты настолько высоко в структуру наследования как надлежаще?
  • Все полиморфные методы в пределах соответствующих подклассов названы идентично?
  • Каждая ассоциация отражает отношение, которое существует при жизни связанных объектов?

Последовательность:

  • Каждое отношение 0.. * и 1.. * реализуется контейнерами/коллекторами?
  • Количество элементов каждой ассоциации непротиворечиво (сразу и с течением времени)?

Тестирование экспертизы проблемной области

Полнота:

  • Каждый класс именован сильным существительному?
  • Все избыточные, неактуальные или расплывчатые классы были удалены со схемы?
  • Каждый атрибут определен внутри надлежащего класса? Он правильного типа?
  • Видимость каждого атрибута является правильным?
  • Значения по умолчанию для каждого атрибута указаны правильно?
  • Каждый атрибут необходим, а не вычисляем от других?
  • Каждый метод в правильном классе?
  • Имена всех методов сильные глаголы?
  • Каждый метод принимает правильные входные параметры и возвращает правильный выходной параметр?
  • Видимость каждого метода является правильной?
  • Каждый метод реализует одно и только одно поведение?
  • Публичные интерфейсы освобождены от ненужных методов?

Последовательность:

  • Диаграмма классов отображена на соответствующем уровне: концептуальный, спецификация или реализация?

Тестирование трассировки

Последовательность:

  • Каждый объект на схеме последовательности представлен с помощью класса на схеме классов?
  • Каждое сообщение на схеме последовательности отражено как метод в соответствующем классе?

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

Posted in Architecture Tooling Guide, Microsoft, Team Foundation Server, Visual Studio | Отмечено: , , | Leave a Comment »

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

Posted by Шамрай Александр на Апрель 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, и поэтому не должны восприниматься таковыми. Иллюстрация будет снова появляться с каждым основным сценарием, покрывающим соответствующую область, выделенную в настоящем руководстве, которую по нашему мнению отображает сценарий.

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

Первый взгляд на основные сценарии

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

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

Posted in Architecture Tooling Guide, Microsoft, Team Foundation Server, Visual Studio | Отмечено: , , | Leave a Comment »

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

Posted by Шамрай Александр на Апрель 23, 2013

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

ЦЕЛЬ
Этот сценарий ориентирован на архитекторов и разработчиков для понимания концепции DSL, подходов и как использовать Visual Studio Visualization and Modeling SDK (VsVmSdk) для создания мощных инструментов разработки на основе моделей, которые можно интегрировать в Visual Studio.

Описание

В отличие от языка моделирования общего назначения, таких как Unified Modeling Language (UML), или языка программирования общего назначения, например C#, Visual Basic, Java; Domain-Specific Language (DSL) — это язык программирования или язык спецификации, который предлагает использование соответствующих обозначений и абстракций, сосредотачиваясь на конкретной области и обычно ограничиваясь конкретной предметной областью.

Инструменты DSL

Domain-Specific Language (DSL) — нотации, которые вы проектируете для конкретной цели. В Visual Studio, обычно графически, можно использовать создание визуальных конструкторов, настроенных для вашей проблемной области.

Что такое Domain-Specific Language?

Domain

Области можно разделить на горизонтальные области и вертикальные области:

Представьте горизонтальные области как слои в архитектуре программного обеспечения. Visual Studio содержит Дизайнеры Специализированные для Области для GUI (Windows.Forms и WPF), для базы данных (платформа Entity framework) и ресурсов, и дизайнеров настроек, которые основаны на формах. У вас также есть ClassDiagram (мы могли бы сказать схема физических классов), которая является другим представление кода и конкретных языков. Однако, ClassDiagram уникальна в том смысле, что она двунаправленна.

Интересно видеть, что эти дизайнеры всегда генерируют код/артефакты, основываясь на некоторых платформах. Платформа предоставляет контракт. DSL пытается представить изменяемые точки для платформы.

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

Specific

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

Language

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

Когда использовать язык для определенной области?

Мы рассмотрели, что Domain-Specific Language создан специально для решения проблемы в конкретной области. Область также может быть бизнес-областью. Некоторые примеры сферы бизнеса:

  • dsl для информации о путешествиях
  • dsl для банковской администрации
  • dsl для расчета котировки

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

Роли

Описания ролей смотрите в руководстве Visual Studio ALM Rangers Personas and Scenarios.

Жизненный цикл DSL

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

Субъекты и жизненный цикл DSL

Определить проблемную область

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

Анализ области

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

Моделирование

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

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

Моделирование DSL идентификации с использованием VsVmSdk

РЕКОМЕНДАЦИИ
Хорошая абстракция имеет важное значение для реализации хорошо продуманного DSL, Visual Studio Visualization and Modeling SDK (VsVmSdk) включает дизайнеры, которые помогут вам создать модели для представления концепций в вашей бизнес-области.

Реализация

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

Развертывание

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

Использование продукта

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

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

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

Posted in Architecture Tooling Guide, Microsoft, Team Foundation Server, Visual Studio | Отмечено: , | Leave a Comment »

Руководство по инструментам архитектуры Visual Studio. Сценарий – мне необходимо настроить графы DGML

Posted by Шамрай Александр на Март 11, 2013

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

ЦЕЛЬ
Этот сценарий ориентирован на архитекторов и разработчиков для понимания концепций DGML и как настроить графы DGML для поддержки различных сценариев и как эта настройка может быть сделана с помощью Visual Studio 2012.

Описание

Графы DGML (Direct Graph Markup Language) используются для отображения отношения между элементами и их взаимосвязей в графах архитектуры Visual Studio 2012, но DGML графы могут использоваться в других сценариях, например, представлять структуру сайта SharePoint. DGML графы являются мощным инструментом для выражения различных типов информации в графах, основанных на узлах, контейнерах и взаимосвязях.

Начиная с Visual Studio 2010 набор инструментов для разработчиков программного обеспечения включает поддержку генерирования графов DGML из связей в коде и просмотр любого DGML-документа, созданного любым другим инструментом.

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

Файл DGML в основном состоит из узлов, ссылок, категорий, свойств и стилей, как показано на рисунке ниже. Полная схема XSD для DGML доступна на сайте http://schemas.microsoft.com/vs/2009/dgml/. DGML не только позволяет описывать узлы и ссылки на графе, но также Аннотировать эти узлы и связи с любыми определяемыми пользователем свойствами и/или категориями.

Основные Элементы DGML

Определение элемента графа

Xml представление файла DGML отображено на рисунке ниже.

Базовая структура DGML

Узлы: Список элементов графа представлены в узлах, каждый элемент является Node.

Ссылки: взаимосвязи между узлами представлены как ссылки.

ПРИМЕЧАНИЕ
Когда вы создаете ссылку на неопределенный элемент в <Link/>, граф создает автоматически элемент <Node/>

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

Свойства: Этот элемент содержит список элементов <Property/>. Каждый атрибут свойства вы можете использовать для присвоения значения для любого DGML элемента или атрибута, включая категории и другие свойства.

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

ПРИМЕЧАНИЕ
Пользовательские стили можно применять к следующим элементам:

  • Одному узлу и ссылке
  • Группам узлов и ссылок
  • Группам узлов и ссылок на основании определенных условий.

Последовательность настройки и генерирования DGML

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

Также вы можете использовать другие инструменты, ваш собственный код c# или шаблоны T4 как дополнительные источники, такие как xml, обычный файл или другие источники, и создать граф. В процессе вы можете написать код, чтобы применить условные стили к вашему графу, например, вам может быть необходимо выполнить обратный инжиниринг фермы SharePoint 2007 для подготовки обновления до 2010, можно написать собственный код для представления структуры SharePoint в DGML граф. Чтобы узнать больше об этом примере читайте эту запись блога.

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

Последовательность настройки и генерирования DGML

РЕКОМЕНДАЦИИ
Смотрите шаг 4 упражнения Visual Studio 2012 Architecture Guide — Customize DGML – HOL.docx об использовании шаблонов T4 для генерирования графа из файла xml.

Ручная настройка DGML

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

Смотрите Практическое руководство. Изменение и настройка диаграмм зависимостей, где вы можете найти темы, связанные с ручным редактирования DGML и настройку с помощью дизайнеров и исходников xml, на рисунке ниже показаны темы раскрытые в статье MSDN.

Редактирование и Настройка Графа Зависимостей на MSDN

РЕКОМЕНДАЦИИ
Смотрите шаг 3 упражнения Visual Studio 2012 Architecture Guide — Customize DGML – HOL.docx

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

Posted in Architecture Tooling Guide, Microsoft, Team Foundation Server, Visual Studio | Отмечено: , , | Leave a Comment »

Руководство по инструментам архитектуры Visual Studio. Сценарий – мне необходимо выполнить валидацию архитектуры системы

Posted by Шамрай Александр на Март 4, 2013

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

Валидация архитектуры системы

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

Этот сценарий проверки можно разделить на три отдельные слабо связанные сценария:

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

Валидация UML модели

Соображения

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

Цели тестирования особенно направленны на выявление ошибок, которые могут быть найдены в каждой фазе («как можно скорее»).

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

Смотрите также Acceptance Test Guidance of the Patterns and Practices Group для дополнительной информации.

Среды валидации

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

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

Валидация архитектуры

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

Для получения дополнительной информации см. Use Cases and Testing Ли Коупленда.

Записывайте ваши ошибка как рабочий элемент Ошибка в TFS.

«Бизнес тесты, которые направляют разработку системы являются системными приемочными тестами (также известными как тесты заказчика). Эти тесты разрабатываются на основе требований и само написание этих тестов может определить отсутствующие или неоднозначные требования. Когда мы (владелец продукта часто вместе с кем-то из команды разработчиков продукта) готовим эти тесты до начала разработки, мы можем быть уверены, что команда разработчиков продукта понимает, что им нужно разработать. Это известно, как Acceptance Test-Driven Development.

См. Разработка тестов из модели в библиотеке MSDN для получения дополнительной информации.

Пошаговое руководство

В этом сценарии хорошей отправной точкой для тестирования являются варианты использования, которые описывают различные субъекты и как они используют систему для достижения конкретных целей. Модель вариантов использование, которая представлена в Visual Studio 2012 в UML Model Explorer, обеспечивает четкое видение всех субъектов и варианты использования в проекте. Это идеальное место, с которого можно начать проверку.

UML Model Explorer

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

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

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

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

Проверка вариантов использования

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

  • Выберите вариант использования
  • Щелкните правой кнопкой мыши
  • Выберите создать новый рабочий элемент Ошибка
  • Заполните информацию об ошибке.

Создание рабочего элемента, связанного с вариантом использования

В результате будет форма ошибки, пример которой приведен ниже:

Новый рабочий элемент Ошибка

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

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

Соображения

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

Существует два общих методов проектирования тестов, которые используются для определения тестовых сценариев на основе UML. Во-первых, Тест цикла процесса, который использует диаграмму активности UML. Тест цикла процесса — это метод, который применяется в частности для тестирования характеристики качества пригодности, который измеряет, насколько хорошо информационная система интегрирована в бизнес организации. Другим методом является использование Тестов Вариантов Использования, который основан на диаграмме вариантов использования — смотрите ссылку для получения дополнительной информации.

В Microsoft Visual Studio Ultimate можно использовать требования и модели архитектуры, чтобы помочь вам организовать тесты для вашей системы и ее компонентов. Эта практика помогает обеспечить проверку требований, которые важны для пользователей и других заинтересованных сторон, и поможет вам быстро обновлять тесты при изменениях требований. Если вы используете Microsoft Test Manager, вы также можете поддерживать связи между моделями и тестами.

Как описано в приведенной выше цитате из библиотеки MSDN, можно связать тестовые сценарии, созданные в Microsoft Test Manager, к UML-модели Visual Studio.

Валидация ключевых принципов проектирования и соображения

Соображения

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

Одной из очень хорошей отправной точкой для архитектурных проверок будет Microsoft P&P Application Architecture Guide 2.0. Это руководство содержит контрольные списки, которые определяют некоторые основные принципы и наилучшие практики прочного архитектурного дизайна.

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

  • Разделение проблем
  • Принцип персональной ответственности
  • Принцип уменьшения знания
  • Не повторять себя
  • Минимизировать авансовый дизайн
  • Держите шаблоны проектирования непротиворечивыми в каждом слое.
  • Не дублировать функциональность в приложении.
  • Предпочитать композицию наследованию
  • Создать стиль кодирования и именования для разработки
  • Использование абстракция для реализации слабой связанности между слоями.
  • Быть четким в коммуникации слоев друг с другом
  • Не смешивать различные типы компонентов в одном и том же логическом слое
  • Держать пересекающийся код максимально абстрагируемым от бизнес-логики приложения

Валидация слоев

Хотя не все выше упомянутые архитектурные проверки могут проверяться на основе диаграммы слоя (или UML-диаграммы в Visual Studio) существует множество архитектурных проверок, которые могут.

Ручная валидация проектирования системы

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

Диаграмма компонентов

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

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

На рисунке ниже показана ручная валидация проектирования:

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

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

Ручная проверка результатов проектирования

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

Posted in Architecture Tooling Guide, Microsoft, Team Foundation Server, Visual Studio | Отмечено: , , | Leave a Comment »

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

Posted by Шамрай Александр на Февраль 11, 2013

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

НАБЛЮДЕНИЕ
Мы будем повторно рассматривать эту тему после первых выпусков Architecture Feature Packs.

Требования могут рассматриваться как состоящие из нескольких типов традиционно «SRS» (спецификация требований программного обеспечения). В Agile требования обычно регистрируются в виде описания пользовательской функциональности или сценариев.

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

  • Диаграмма вариантов использования
  • Концептуальная схема классов
  • Диаграмма активности
  • Диаграмма последовательности

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

Связывание рабочих элементов требований с диаграммами вариантов использования

Шаблоны из коробки, поставляемые Visual Studio Team Foundation Server (TFS), не содержат вариант использования как рабочий элемент. Это оставляет диаграмму вариантов использования без прямого сопоставления для структуры декомпозиции работ (СДР) созданной по рабочим элементам. Существует несколько вариантов для реализации трассировки в этом случае:

  • Создать рабочий элемент / тип рабочего элемента вариант использования (в MSF CMMI)
    • Это позволит создать структуру декомпозиции работ, которая аккуратно группирует Сценарии/Пользовательские Описания Функциональности в Варианты Использования;
    • Возможно использовать типизированные связи между высоким уровнем (Вариант Использования) и низкого уровня (Истории/Сценарии) (для получения дополнительной информации о типизированных ссылках, см. Руководство управлению требованиями Visual Studio Рейнджеров или документацию по продукту);
    • Запросы, отчеты и метрики управления проектом поднимаются до уровня Вариантов Использования;
    • Однако это создает дополнительное бремя для документирования и поддержки синхронизации модели UML и рабочего элемента. В идеале рабочий элемент просто будет представлением элемента модели UML. Другим решением может быть реализация Пользовательского обработчика ссылок рабочего элемента, который будет синхронизировать его по необходимости.
  • Ссылка на нескольких рабочих элементов Описание Функциональности Пользователя (или Требований типа Сценарий) как замена для рабочего элемента Вариант Использования.
    • Это позволит диаграмме Вариантов Использования использоваться в качестве агрегатора (в Agile терминах, «Эпическое») Пользовательских Описаний Функциональности/Сценариев;
    • Нет необходимости синхронизировать документацию с рабочим элементом и Вариантом Использования как в предыдущем сценарии;
    • Однако запросы, отчеты и метрики управления проектами не поднимутся до уровня Вариантов Использования, оставляя Планирование релизов на более детальном уровне;
    • Кроме того, ссылки не типизированы, поэтому иерархия от высокого уровня (Вариант Использования) до низкого уровня (Истории/Сценарии) не дадут никакой дополнительной информации кроме как ассоциации подразумеваемой ссылкой.
  • Ссылка из диаграммы Вариантов Использования к Задачам разработки
    • Это предложено в текущей документации Visual Studio 2012 в статье Using Models within the Development Process;
    • Это хороший вариант для UML-проектов, где все требования хранятся в Team Foundation Server и рабочие элементы Пользовательские Описания Функциональности/Сценарии не используются;
    • Однако он не позволяет вести хорошего управления релизами, обычно Вариант Использования, как правило, охватывает итерацию из-за их внутреннего размера (Writing Effective Use Cases, Advanced Use Case Modeling: Software Systems), и это создается большое количество связей на низший уровень декомпозиции с рабочими элементами Задача.
    • Кроме этого, ссылки не типизированы, поэтому иерархия с высокого уровня (Вариант Использования) до низкого уровня (Истории/Сценарии) является неявной.
  • Ссылка на документ, хранящийся на внешней системе
    • Это вариант, который имеет наименьшее количество встроенной трассировки, но может быть полезным для существующих проектов с обширной существующей документацией.

Связывание Варианта Использования с рабочим элементом

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

  • Из Варианта Использования:

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

  • Выбрать запрос по рабочим элементам:

Выбор запроса по рабочим элементам

  • Обновленные свойства Варианта Использования выглядят приблизительно так:

Свойства Варианта Использования

  • И диаграмма Вариантов Использования теперь показывает значок () на Варианте Использования, который связан с рабочим элементом:

Диаграмма Вариантов Использования и иконки связанных рабочих элементов

Обратите внимание на отсутствие типизированных ссылок. Чтобы получить двунаправленные ссылки между рабочими элементами требований и вариантами использования, необходимо установить TFS 11 (в Visual Studio 2010, вы должны были установить Visual Studio Feature Pack 2010). Без этого расширения нет ссылки из рабочего элемента обратно в элемент модели, что делает двунаправленную трассировку трудной задачей.

Для более подробной информации о том, как связать элементы, смотрите в документации:

Обратная связь между рабочими элементами и элементами модели

Пакет визуализации и моделирования Microsoft ® Visual Studio ®2010 предоставляет возможность связать рабочий элемент Team Foundation Server к элементу модели. Эта функция теперь поставляется в Visual Studio 2012.

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

Создание отчетов Трассировок

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

Одна проблема в создании отчетов в том, что информация о моделях UML публикуется в хранилище данных проекта исключительно как исходный код без других связанных семантических единиц: то есть, вся соответствующая UML информация остается с моделью. Поэтому шаги создания стандартного отчета для TFS не применимы, если для каждого элемента Варианта Использования мы не добавляем соответствующий рабочий элемент или тип Требования (в MSF CMMI). Это позволит нам использовать отчеты, описанные в документе Рейнджеров «Руководство управлению требованиями Visual Studio«.

НАБЛЮДЕНИЕ
Этот раздел определенно кандидат на использование расширяемости и область, которую мы будем рассматривать в будущих версиях этого руководства.

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

Руководство управлению требованиями Visual Studio Рейнджеров подробно объясняет, как создать отчеты трассировок. Основное дополнение здесь состоит в том, что самый легкий путь (в версии RTM) для реализации Вариант 1, чтобы обеспечить трассировку (раздел «Создать пользовательский Рабочий Элемент Варианта Использования / Тип Рабочего Элемента(в MSF CMMI)» выше). Это обеспечивает основу для отслеживания к задачам и коду, начиная с рабочих элементов требование. Чтобы создать отчеты для Варианта 2 и 3 в этом разделе, можно разработать расширение Visual Studio Team Architect, чтобы получить список затрагиваемых рабочих элементов.

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

Posted in Architecture Tooling Guide, Microsoft, Team Foundation Server, Visual Studio | Отмечено: , , , | Leave a Comment »

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

Posted by Шамрай Александр на Январь 22, 2013

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

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

Описание

В прошлом мы должны были использовать обозреватель решения и различные инструменты, такие как 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» для пошаговой инструкции данного сценария.

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

Posted in Architecture Tooling Guide, Microsoft, Team Foundation Server, Visual Studio | Отмечено: , | Leave a Comment »

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

Posted by Шамрай Александр на Январь 15, 2013

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

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

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 для пошаговой инструкции по этому сценарию.

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

Posted in Architecture Tooling Guide, Microsoft, Team Foundation Server, Visual Studio | Отмечено: , | Leave a Comment »

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

Posted by Шамрай Александр на Январь 10, 2013

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

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

Описание

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

Чтобы успешно реализовать повторяемую архитектуру с использованием средств архитектуры, необходима эталонная архитектура для вашей проблемной области. Можно создать собственные или использовать один из предоставляемых группой шаблонов и практик. Вы можете найти набор ссылок описания архитектуры по следующему адресу: 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

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

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

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

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

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

Posted in Architecture Tooling Guide, Microsoft, Team Foundation Server, Visual Studio | Отмечено: , | Leave a Comment »

 
%d такие блоггеры, как: