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

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

Archive for Апрель 2013

Руководство по управлению тестовыми выпусками. Что такое Управление Тестовыми Выпусками?

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

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

Темы
  • Почему Управление Тестовыми Выпусками Необходимо
  • Краткое Описания Артефактов Тестирования
  • Цели Управления Тестовыми Выпусками
  • Альтернативные Классификации Рабочих Элементов

Потребность в Управлении Тестовыми Выпусками

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

  • Обеспечение отчетов тестирования для каждого спринта.
  • Поддержка снимка тестовых сценариев при выпуске.
  • Обеспечение отчетов тестирования по ветвям.
  • Минимизация издержек управления планами тестирования и рабочими элементами.

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

  • Планы тестирования
  • Тестовые наборы
  • Тестовые случаи
  • Общие шаги

Артефакты Тестирования

Следующий рисунок показывает, как тестовые наборы и тестовые случаи отображаются в плане тестирования в Microsoft Test Manager. Тестовые случаи отображаются в выбранном тестовом наборе.

Представление Плана Microsoft Test Manager, Содержимое

  • Планы тестирования и тестовые наборы не являются рабочими элементами Team Foundation Server. Они являются отдельными артефактами, хранящимися в репозитории Team Foundation Server.
  • Тестовые случаи – рабочие элементы, но шаги в тестового сценария не могут быть отредактированы в Visual Studio. Шаги тестирования должны редактироваться в Microsoft Test Manager или других инструментах, специально предназначенных для этой цели (см. ссылки ниже).
  • Общие шаги — рабочие элементы и шаги в них должны редактироваться так же, как и шаги тестового случая. Общие шаги могут использоваться в различных тестовых случаях.

Следующий рисунок показывает форму тестового случая в Microsoft Test Manager. Шаги тестирования и общие шаги отображаются на вкладке Шаги.

Форма Тестового Случая Microsoft Test Manager

Предупреждение Наборы на основе требовании и Базовые линии
Тщательно оценивайте использование наборов на основе требований. Особенно, если Ваша организация требует, чтобы Вы поддерживали тестовые случаи и результаты тестирования в их точном состоянии после выпуска программного обеспечения. Например, если Вы добавите регрессионный тестовый случай к пользовательской истории, которая является частью набора на основе требований в предшествующем выпуске, то результаты тестирования изменят состояние плана тестирования предшествующего выпуска. Функция Microsoft Test Manager 2012 TCM.exe /clone избегает это, преобразовывая наборы на основе требований в статические наборы. Другие опции включают клонируемые требования для каждого выпуска, а также тестовые случаи или использование наборов на основе требований.Наборы на основе требований (НОТ) и Тестовые случаи
Когда Вы удаляете тестовый случай из набора на основе требований, он также удаляет ссылку «тестирует/тестируется» из тестового случая к пользовательской истории (или PBI). Чтобы избежать это, начиная с Обновления Visual Studio №2, планы Microsoft вводят признак «Не Применимый», который может использоваться, чтобы отметить тестовый случай как «Не Применимый» для текущего цикла, но сохраняет трассируемость.

Цели Управления Тестовыми Выпусками

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

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

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

  • Спринтами
  • Фазами
  • Выпусками
  • Подкомандами
  • Компонентами
  • Базовыми линиями

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

Тип Поля классификации Комментарии
План Тестирования
  • Наименование
  • Путь области
  • Путь итерации
  • Используемое построение
  • Владелец
  • Состояние
  • Дата начала
  • Дата окончания
  • Состояние тестирования
Тип план тестирования не является рабочим элементом, но в действительности имеет часть таких же атрибутов. Например, у плана тестирования есть атрибуты состояния, пути области и пути итерации.Независимое «состояние тестирования» также обеспечено, которое может быть просмотрено и установлено только из окна содержимого плана в MTM.
Тестовый Набор
  • Наименование
  • Тип
  • Состояние тестирования
Различные типы наборов такие, как статичные, основанные на требованиях и основанные на запросе, ведут себя по-разному. См. предупреждение выше для наборов основанных на требованиях.»Состояние тестирования» также доступно для каждого набора.
Тестовый случай
  • Наименование
  • Кому назначено
  • Состояние
  • Причина
  • Приоритет
  • Состояние автоматизации
  • Путь области
  • Путь итерации
Тестовый случай — рабочий элемент и может быть выбран как другие типы рабочих элементов.Шаги тестов не могут быть отредактированы от Visual Studio.
Общие шаги
  • Наименование
  • Кому назначено
  • Состояние
  • Причина
  • Приоритет
  • Путь области
  • Путь итерации
Общие шаги – рабочий элемент и может быть выбран как другие типы рабочих элементов.Шаги общих шагов не могут быть отредактированы от Visual Studio.

Статус и аспекты классификации плана тестирования, наборов и тестовых случаев.

Примечание Рассмотрите документирование «Плана Управления Тестовыми Выпусками». Используйте этот план для распространения информации в вашей команде и как справку о том, как обновляются поля классификации артефактов тестирования, поля состояний и связи.

Альтернативы для Классификации Рабочих Элементов

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

  • Путь итерации
  • Путь области

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

Путь Итерации

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

  • Выпуск
  • Фаза
  • Спринт

Безопасность для пути итерации ограничена разрешениями на создание, редактирование, организацию и просмотр узлов дерева. Возможно иметь некоторую комбинацию выпусков, фаз и спринтов по пути итерации. Однако, у пути итерации будет множество значений. Это будет рассмотрено более подробно в разделе далее «Использование Путей Области и Итерации: Две Модели.»

Путь Области

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

  • Подкоманде
  • Компоненту продукта
  • Базовой линии продукта

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

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

  • Редактировать рабочие элементы в этом узле
  • Управлять планами тестирования
  • Просматривать рабочие элементы в этом узле

Использование Путей Итерации и Области: Две Модели

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

«Декларативная модель»

В Декларативной Модели активная работа назначается явной версии, определенной в начале проекта. Например, если проектная команда работает над спринтом 1 из выпуска 1.0, итеративный путь был бы [корень дерева итераций]\Release 1\Sprint01. Когда версия 1.0 выпущена, и начинается работа над следующей версией, итеративный путь для работы будет [корень дерева итераций] Release 2\Sprint01.

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

Пример иерархии пути итерации при использовании декларативной модели

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

Пример иерархии пути области при использовании декларативной модели

«Последняя модель»

В Последней Модели итеративный путь не используется для определения версии выпуска, только спринта. Активная работа всегда находится в корне пути области. Например, если проектная команда работает над спринтом 1 из выпуска 1.0, путь итерации будет [корень дерева итераций]\Sprint01 и путь области будет [корень дерева области]. Когда версии 1.0 выпущены после спринта 5, путь области для завершенной работы изменяется на [корень дерева области]\1.0. Работа над следующей версией начинается по пути итерации [корень дерева итераций]\Sprint06 и путь области остается тем же как раньше [корень дерева области].

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

Пример иерархии пути итерации при использовании последней модели

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

  • Путь итерации – период времени
  • Путь области – версия

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

Сравнение Декларативной и Последней Моделей

За и против для этих двух моделей:

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

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

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

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

Клонирование Рабочих Элементов

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

Тип рабочего элемента Клонирование Объяснение
Ошибка Активные ошибки Следуйте по принципу одна ошибка на базовую линию, предполагая, что у каждой базовой линии есть свое собственное ветвление кода. Фиксация должна быть применена в каждой базовой линии, даже если это та же ошибка.
Пользовательская история Только когда были изменены или когда найдены ошибки Смотрите раздел руководства «Когда Регрессионные Тесты Не Пройдены» далее.
Тестовый случай Готовые Тестовые Случаи Поддержка записей тестовых случаев на момент выпуска.
Общие шаги Активные Общие Шаги Поддержка записей общих шагов тестовых случаев на момент выпуска.

Предложенные практики клонирования для некоторых типов рабочих элементов

Руководство для клонирования рабочих элементов приведено ниже в документе.

Итоги

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

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

Реклама

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

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

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

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

Темы
  • Цели Историй и Персонажей этого документа
  • Персонаж Лидер Команды Тестирования
  • Истории Управления Тестовыми Выпусками

Цели Историй и Персонажей Этого Документа

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

Персонаж Лидер Команды Тестирования

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

Кристина — «Лидер Команды Тестирования»

Кристина представляет лидера команды тестирования проекта. Ее роль в проекте ответственна за:

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

Истории

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

Истории, затрагиваемые этим руководством:

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

Итоги

Этот раздел фокусируется на роли «Лидер Команды Тестирования» и управлении тестами через спринты, выпуски и ветви кода.

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

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

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

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