Размещено на http://www.allbest.ru/

Введение

Понимание взаимосвязей между классами в большом проекте может быть сложным процессом. В этой курсовой работе рассмотрено использование диаграмм DGML (Directed Graph Markup Language) в Visual Studio Ultimate 2013 для анализа кодовой базы и взаимосвязей между классами. Для выполнения курсовой работы понадобится виртуальная машина с Visual Studio 2013.

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

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

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

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

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

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

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

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

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

· Выявление моделей и общей структуры приложения на высоком уровне.

· Понимание метода или конкретного потока в деталях на более низком уровне детализации.

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

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

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

· Найти код, который имеет петли или циклические зависимости.

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

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

· Найти код, который не имеет зависимостей. Исследуйте эти области, чтобы увидеть являются ли они необходимыми или этот код следует удалить.

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

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

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

· Исходный и компилированный код Visual C# .NET и .NET Visual Basic, такой как файлы .NET сборки (.dll) и исполняемые файлы (.exe)

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

Для создания графов зависимостей для управляемого и машинного кода, необходимо использовать параметры «For Solution», и только для машинного кода использовать «For Include File».

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

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

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

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

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

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

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

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

2. UML-схема последовательностей является частью модели UML и в основном используется для разработки кода наперед.

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

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

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

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

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

Наконец если вы хотите реализовать новую функцию в существующей системе, можно использовать другие UML-диаграмм.

visual граф класс код

1. Настройка виртуальной машины

Т.к. я на моём компьютере установлена Windows 8.1, то нет необходимости отдельно скачивать Hyper-V, он входит в состав Windows. Необходимо только установить его. Заходим в Панель управления, Программы и Компоненты, Включение или отключение компонентов Windows. Ставим галочку напротив Hyper-V, после установки компьютер необходимо перезагрузить.

Рис. 1. Включение компонента Hyper-V

После перезагрузки запускаем диспетчер Hyper-V и импортируем скачанную виртуальную машину, включаем её.

2. Ход действий

Использование графиков зависимостей для визуализации взаимосвязей между классами

1. Входим под аккаунтом Julia (VSALM\Julia). Пароль: P2ssw0rd.

2. Запускаем Visual Studio 2013 и открываем Team Explorer.

3. Нажимаем на Connect to Team Projects.

Рис. 2. Подключение к командному проекту

4. В Team Explorer - Connect нажимаем два раза на Tailspin Toys.

Рис. 3. Проект Tailspin Toys

5. В Team Explorer - Home нажимаем два раза на третьем решении TailspinToys(ветка Main).

Рис. 3. Решение Tailspin Toys

6. Пересобираем решение (Build | Rebuild Solution).

7. Создаём новый график взаимосвязей (Architecture | Generate Dependency Graph | For Solution). График хранится в формате Directed Graph Markup Language (DGML), который позволяет работать с ним из Visual Studio 2013 и из других стандартных инструментов.

Рис. 4. График взаимосвязей

8. Разворачиваем Tailspin.Model.dll для просмотра пространств имен.

Рис. 5. График взаимосвязей

9. Разворачиваем Tailspin.Model.

Рис. 6. Узел на графике

10. Нажимаем на Quick Clusters Layout для просмотра всех классов и их взаимосвязей.

Рис. 7. Опция Quick Clusters Layout

Рис. 8. Представление типа Quick Clusters сгенерированного графика

11. Представление Quick Clusters дает представление о количестве классов в проектах TailspinToys и степень их связей. Найдем в нем узел по классу Product. Есть два способа сделать это.

a. Первая опция - приблизить изображение так, чтобы класс Product было четко видно.

Рис. 9. Приближение

b. Второй способ - произвести поиск, нажав CTRL+F и введя в появившееся текстовое поле Product. Нажимаем F3, пока нужный класс Product не будет подсвечен как выбранный.

Рис. 10. Поиск класса Product

12. Увидеть прямые взаимосвязи можно, выбрав узел Product, но разобраться, какие из них исходящие, а какие входящие, сложно. Изменим режим графика на Top to Bottom Layout.

Рис. 11. Режимы графика

Рис. 12. Режим Top to Bottom

13. Этот режим показывает входящие линии сверху, исходящие - снизу. Уже лучше, но есть визуальные помехи, например, взаимосвязь между классом Product и сборкой Tailspin.Test.Model. Нажмём на Layout | Advanced | Hide All Cross-Group Links.

Рис. 13. Скрытие всех кроссгрупповых ссылок

Выявление циркулярных ссылок

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

18. Вернёмся в исходный график (AssemblyDependencies1.dgml) и убедимся в том, что Product виден.

Рис. 19. График взаимосвязей с выбранным узлом Product

19. Нажмём на Legend.

Рис. 20. Кнопка Legend

20. Нажмём на + в верхней части Legend для просмотра доступных для добавления на диаграмму опций.

Рис. 21. Кнопка + в Legend

21. Нажмём на Analyzer | Circular References для добавления компонента на график. Этот компонент будет работать, даже если график будет изменен.

Рис. 22. Добавление компонента Circular References analyzer

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

Рис. 23. График с циркулярными ссылками между классами

Список литературы

1. Visual Studio 2013 Application Lifecycle Management Virtual Machine and Hands-on-Labs / Demo Scripts - Brian Keller - Site Home - MSDN Blogs

2. Серия лабораторных работ по разработке, тестированию и управлению жизненным циклом ПО для Visual Studio 2013 - Блог Стаса Павлова - Site Home - MSDN Blogs

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

Размещено на Allbest.ru