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

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

Archive for Март 2013

Руководство по инструментам архитектуры 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 »

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