Сценарий изучения существующей системы
Описание
В прошлом мы должны были использовать обозреватель решения и различные инструменты, такие как Microsoft Visio, чтобы понять архитектурный дизайн из набора проектов и файлов кода и полагаться на соглашения по наименованиям проектов и файлов. Этот процесс зачастую затруднен, подвержен ошибкам и нестандартен, результаты проектирования и визуализации обратного инжиниринга, которые зачастую устаревшие, неполны или неточны. По существу процесс часто был «ручной» и чем больше мы можем автоматизировать трудоемкий и подверженный ошибкам процесс, тем лучше наше понимание моделей.
Visual Studio Ultimate может помочь нам в сценарии анализа существующего системы в ситуациях, таких, как:
- Нам нужно понять (части) существующей системы, чтобы быть в состоянии поддерживать или расширять ее.
- Нам нужно понять (части) существующей системы, чтобы иметь возможность сказать кое-что о ее качестве.
Инструменты архитектуры в Visual Studio Ultimate помогают нам визуализировать организацию, связи, шаблоны проектирования и поведение (части) существующей системы программного обеспечения в последовательном, повторяемом и стандартизированном виде.
| ВОПРОСЫ Почему важно определить шаблоны проектирования, которые используются в существующей системе? Зачем нам нужно представление проектирования высокого уровня? |
Если вы хотите расширить или изменить поведение приложения, важно понять, что такое все его части, что они делают и как они зависят друг от друга. Это необходимо не только потому, что вы можете определить, какие части должны быть изменены, но и потому что вы можете оценить, насколько любые изменения, которые вы могли бы внести, будут влиять на остальной проект.
Отношения между частями сложного проекта могут быть описаны с точки зрения шаблонов проектирования. Например, вы можете определить один объект в качестве наблюдателя другого. После того как вы определили эти шаблоны, намерения автора проектирования становятся яснее. Тогда будет легче придерживаться изначальным принципам проектирования, пока вы адаптируетесь и расширяете проект.
Во время изучения существующего кода, вы можете найти области, где можно улучшить проект, сделать его проще для изменений. Они могут быть определены и описаны в терминах анти-шаблонов, например, циклические зависимости или дублирования. Описывая любые недостатки, как анти-шаблоны, вы делает его легче для оценки трудностей, которые они могут вызвать, и обсудить возможные решения.
В случае нового требования или функции, вам нужно понять, как новые части будут взаимодействовать с существующими функциями и как часть существующего кода нужно изменить. Процесс разведочного обратного инжиниринга охватывает две формы понимания:
- Выявление моделей и общей структуры приложения на высоком уровне.
- Понимание метода или конкретного потока в деталях на более низком уровне детализации.
Можно создать схемы последовательностей из существующего кода и затем изменять их для реализации новых вариантов использования. От этих адаптированных диаграмм вы можете получить необходимые интерфейсы для каждого компонента. Вы также можете оценить влияние изменений на качество сервисных требований системы.
| ВОПРОСЫ Как мы начать сценарий обратного инжиниринга? |
Это зависит от типа и уровня детализации, который вам нужен.
Например:
- Для изучения существующих зависимостей кода с целью выявления циклических ссылок или зависимости между сборками или пространствами имен, следует создать 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.