Структура программы visual studio

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

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

Дисциплина «Технологии программирования» рассматривает вопросы, связанные с использованием технологий объектно-ориентированного программирования при проектировании Windows-приложений (сложных программных систем). Использование классов в технологиях объектно-ориентированного программирования (ООП) показывает, что класс может выполнять две функции – выступать в роли модуля программы или типа данных.

Структура программы и проекта на C#

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

С другой стороны класс это тип данных. Объектно-ориентированная разработка Windows-приложений основана на стиле, называемом проектированием от данных. Проектирование системы сводится к поиску абстракций данных, подходящих для конкретной задачи. Каждая из таких абстракций реализуется в виде класса, который и становится модулем – архитектурной единицей построения программной системы.

В большинстве разрабатываемых Windows-приложений классы выполняют обе функции, так что каждый модуль программной системы имеет вполне определенную смысловую нагрузку. Язык C# допускает как классы, являющиеся типами данных, так и классы, играющие единственную роль модуля. К классам модулям относятся, например, такие классы, как Console, Convert, Math.

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

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

Поэтому изучение дисциплины «Технологии программирования» мы начинаем со знакомства со средой программирования Visual Studio.NET при создании приложений для Windows (Windows Forms Application).

[C++ Урок 1] Структура программы

Понятие о событийном управлении Windows

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

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

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

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

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

Сообщение Windows является записью, которая содержит информацию о том, что произошло и дополнительную информацию (параметры) о произошедшем событии. Например, структура некоторого сообщения может включать дескриптор окна программы, код (идентификатор) сообщения, уточняющие параметры (например, координаты x и y курсора мыши) и время создания сообщения.

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

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

Обычно Windows-приложений имеет главное окно, в котором располагаются основные элементы управления – меню, кнопки, полосы прокрутки, флажки и т. д. Работая с приложением, пользователь выбирает строки меню, нажимает кнопки или используете другие элементы управления.

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

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

В приложениях, создаваемых для Windows, (File -> New -> Project -> Windows Forms Application), всегда используется два основных типа (классы пространства имен) – Form и Application.

Класс Application управляет поведением приложения – запускает метод Main(), в котором находится цикл обработки сообщений, выполняет необходимые действия при выборке сообщений и корректно завершает работу приложения (файл Program.cs).

Класс Form определяет пользовательский интерфейс приложения – он инициализирует окно формы и готовит приложение к работе (файл Form1.cs).

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

Рассмотрим последовательность действий при создании простого приложения для Windows .

Основные окна среды Visual Studio . Net

Условно процесс создания приложения для Windows включает два основных этапа.

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

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

Чтобы выполнить первый этап разработки приложения для Windows необходимо открыть среду разработки Visual Studio . Net (File -> New -> Project -> Windows Forms Application) – смотри рисунок 1.1. При выборе проекта вам необходимо указать название папки на рабочем столе, в которой будут размещаться создаваемые средой файлы.

Рисунок 1.1 – Среда разработки Visual Studio . Net

В центре рисунка 1.1 расположено окно Form 1, которое относится к пространству имен System.Windows.Forms. Пока окно этой формы пустое, но разрабатываемый проект уже можно запустить на выполнение. Для этого необходимо нажать клавишу F5 или выбрать режим работы среды Debug и в нем команду Start. Окно запущенного приложения смотрите на рисунке 1.2.

Пока закроем наш проект и рассмотрим подробнее назначение отдельных окон среды разработки Visual Studio . Net.

Окно Form1 имеет 4 страницы, которые используются в различных режимах редактирования проекта, например, Form1.cs[Design] используется для размещения элементов управления на форме, а окно Program.cs для редактирования кода программы.

Окно Properties – свойства элементов управления (в нашем примере это форма) или файлов, предварительно установленных в окне Server Explorer. Страницы этого окна сгруппированы либо по категориям, либо в алфавитном порядке, либо по свойствам и событиям.

Рисунок 1.2 – Рабочее окно программы

Окно Server Explorer (на рисунке 1.1 слева в свернутом состоянии) служит для доступа к источникам данных на вашем компьютере и на удаленном сервере (информация из журнала событий и др. служб системы).

Окно Toolbox (инструменты – на рисунке 1.1 слева в свернутом состоянии) содержит различные элементы управления, которые мы будем использовать для размещения на форме.

Окно Solution Explorer – на рисунке 1.1 справа, позволяет просматривать и редактировать файлы проекта. Просмотр может осуществляться по файлам или по классам.

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

Подробное описание работы со средой разработки Visual Studio .Net приведено в книге А.В. Фролов, Г.В. Фролов Визуальное проектирование приложений C#.

1.3 Основные структурные элементы разработки проекта C #

Язык C# является объектно-ориентированным языком программирования и основным понятием является понятие класса.

Определив класс, разработчик получает возможность динамически создавать объекты (переменные или экземпляры) класса.

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

Путаница понятий класса и объекта характерна и определений базового класса языка C#. Базовый класс в библиотеке FCL, являющийся прародителем всех классов как библиотечных, так и создаваемых разработчиком, назван именем Object.

Понятие пространство имен.

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

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

Пространства имен систематизирует структуру библиотеки FCL, которая содержит большое число различных пространств имен, объединяющих классы определенной тематики. Центральным пространством имен библиотеки FCL является пространство System – оно содержит другие пространства и классы, имеющие широкое употребление в различных проектах. Если рассматривать все пространства имен как некоторое иерархическое дерево классов и пространств имен, то пространство System, а в нем класс Object будут являться корнем такого дерева.

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

Так, если разработчик указывает, что он хочет построить проект типа «Windows Forms Application», то в состав каркаса проекта по умолчанию войдет класс Form1 – наследник библиотечного класса Form. Разработчик проекта наполнит созданную форму элементами управления – объектами соответствующих классов, тем самым расширив возможности класса, построенного по умолчанию.

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

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

В зависимости от выбранного типа проект может быть выполняемым или невыполняемым. К выполняемым проектам относятся, например, проекты типа Console или Windows. При построении каркаса выполняемого проекта в него включается класс, содержащий статический метод с именем Main. В результате компиляции такого проекта создается PE-файл (Portable Executable file) – выполняемый переносимый файл с уточнением exe. Напомним, что PE-файл может выполняться только на компьютерах, где установлен Framework .Net, поскольку это файл с управляемым кодом.

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

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

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

Каждый проект, создаваемый в Visual Studio. NET, помещается в некоторую оболочку, называемую Решением – Solution. Решение может содержать несколько проектов, как правило, связанных общей темой. Например, в одно Решение можно поместить три проекта: DLL с разработанными классами, определяющими содержательную сторону приложения, консольный проект решения задачи и проект под управлением Windows. Когда создается новый проект, он может быть помещен в уже существующее Решение или может быть создано новое Решение, содержащее проект.

Дата добавления: 2018-09-20 ; просмотров: 891 ; Мы поможем в написании вашей работы!

Источник: studopedia.net

Презентация, доклад Visual Studio 2010. Структура программы (С++). ЗАНЯТИЕ ПО ДИСЦИПЛИНЕ «Основы

Вы можете изучить и скачать доклад-презентацию на тему Visual Studio 2010. Структура программы (С++). ЗАНЯТИЕ ПО ДИСЦИПЛИНЕ «Основы. Презентация на заданную тему содержит 26 слайдов. Для просмотра воспользуйтесь проигрывателем, если материал оказался полезным для Вас — поделитесь им с друзьями с помощью социальных кнопок и добавьте наш сайт презентаций в закладки!

Презентации » Образование » Visual Studio 2010. Структура программы (С++). ЗАНЯТИЕ ПО ДИСЦИПЛИНЕ «Основы

int main() < int a, b; //описание» />

Слайды и текст этой презентации

Слайд 1

Описание слайда:

Слайд 2

Описание слайда:

План занятия 1. Теоретические аспекты программирования на языке С++ 2. Синтаксис и программные конструкции Visual C++. 3. Типы данных С++ 4. Структура программы

Слайд 3

Описание слайда:

Цели и задачи изучения темы: В результате изучения темы студент должен иметь представление: о создании программ на языке Visual C++; знать: цели и задачи прикладного программирования; этапы создания программ; — Структура программы на языке Visual C++ уметь: использовать инструменты прикладного программирования; — создавать программы на языке Visual C++.

Слайд 4

Описание слайда:

Основные положения Язык программирования – это формальная знаковая система, которая предназначена для написания программ, понятной для исполнителя (в нашем рассмотрении – это компьютер). Программа, написанная на языке программирования, состоит из команд (операторов), задающих последовательность действий. Эти действия выполняются над некоторыми объектами. Объектами могут быть числа, текстовые строки, переменные и другие.

Слайд 5

Описание слайда:
Этапы создания программы

Слайд 6

Описание слайда:

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

Слайд 7

Описание слайда:

Алфавит языка С++ Алфавит — это фиксированный для данного языка набор основных символов, т.е. «букв алфавита», из которых должен состоять любой текст на этом языке — никакие другие символы в тексте не допускаются. Прописные и строчные латинские буквы (различаются в именах), знак подчеркивания Цифры (0…9) Специальные знаки “ < >, | [ ] ( ) + — * / % ; ‘ : ? < = >! https://myslide.ru/presentation/Visual-Studio-2010-struktura-programmy-sx2Bx2B-zanyatie-po-discipline-osnovy» target=»_blank»]myslide.ru[/mask_link]

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

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

Posted by Shamrai Alexander на 22 января, 2013

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

Описание

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

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

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

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

ВОПРОСЫ Почему важно определить шаблоны проектирования, которые используются в существующей системе? Зачем нам нужно представление проектирования высокого уровня?

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

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

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

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

1. Выявление моделей и общей структуры приложения на высоком уровне.
2. Понимание метода или конкретного потока в деталях на более низком уровне детализации.

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

ВОПРОСЫ Как мы начать сценарий обратного инжиниринга?

Это зависит от типа и уровня детализации, который вам нужен.

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

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

Рабочий процесс

ПРИМЕЧАНИЕ Миграция решения/проектов/ проекта моделирования является автоматическим процессом в Visual Studio 2012, который позволяет вам работать с Visual Studio 2010 и Visual Studio 2012. Исключение из этого правила совместимости являются расширения Visual Studio, поскольку они ориентированы на конкретный выпуск visual studio.

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

Рабочий процесс анализа существующей системы

Получить артефакты реализации

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

ПРИМЕЧАНИЕ Не обязательно добавлять типовой проект в решение для всех сценариев обратного инжиниринга – графы и диаграммы последовательностей не требуют этого-однако это обеспечивает удобное место для хранения всех моделей или изображений.

Смотрите «Сценарий — мне нужна повторно используемая (повторяемая) архитектура», для получения дополнительной информации о структуризации решения в содействии повторно используемой архитектуре.

Графы зависимостей

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

Эти графы представляют элементы кода и их отношения как набор узлов, которые связаны ссылками или границами.

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

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

Легенды в DEV 11

НАБЛЮДЕНИЕ Параметр «генерировать для решения» для генерирования графика DGML считается наилучшей практикой. Она очень часто применяется при наличии нескольких пространств имен в сборке и особенно при использовании архитектуры на основе руководства шаблонов и практики приложений архитектуры 2.0, эта опция дает вам представление, которое сразу же показывает любые логические разделения в рамках архитектуры. Однако считать это наилучшей практикой является довольно субъективным – иногда представление решения служит вам лучше, если вы пытаетесь разобраться в перекрестных бинарных зависимостях, особенно если вы рассматриваете развертывание.

Граф зависимостей для решения

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

Поиск в графе зависимостей

Другие возможности для клавиатуры и мыши

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

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

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

НАБЛЮДЕНИЕ При открытии решения, содержащего проекты Visual C# или Visual C++, может занять некоторое время для обновления базы данных IntelliSense. В это время, возможности генерирования графиков зависимости для файлов заголовка (.h или #include), могут быть недоступны, пока базы данных IntelliSense не закончит свое обновление. Вы можете контролировать ход выполнения этих обновлений в строке состояния Visual Studio. Для создания графов зависимостей для управляемого и машинного кода, необходимо использовать параметры «For Solution», и только для машинного кода использовать «For Include File».

Опции графа зависимостей

Обратите внимание, что:

• Импорт XMI является частью продукта
• Экспорта XMI нет в продукте, но доступно в виде исходного кода в примерах Vs VmSdk: XMI Exporter Extension for UML Designers

ПРИМЕЧАНИЕ Не обязательно добавлять проект моделирования в решение для всех сценариев обратного инжиниринга – графы и диаграммы последовательностей не требуют этого-однако это обеспечивает удобное место для хранения всех моделей или изображений.

Открытие и сохранение логической архитектуры с использованием диаграмм слоев

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

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

Диаграмма слоя может также использоваться для проверки архитектуры в будущем, обеспечивая, что изменения в коде не случайно вводят новые зависимости. СмотритеHow to: Validate Code Against Layer Diagrams и Layer Validation with the VSTS 2010 CTP для получения дополнительной информации.

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

Обозреватель архитектуры

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

Обозреватель архитектуры

Обозреватель решения

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

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

Возможность поиска в обозревателе решения

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

Команды обозревателя решений для изучения связей

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

Диаграмма последовательности является идеальным инструментом для понимания (части) существующего кода.

Важно подчеркнуть, что существует два различных вида схем последовательностей:

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

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

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

Схемы классов

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

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

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

Схемы классов помогают вам объединять основные архитектурные аспекты существующей системы.

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

Создание других диаграмм

Наконец если вы хотите реализовать новую функцию в существующей системе, можно использовать другие UML-диаграмм. Для получения дополнительных сведений о том, как использовать UML-диаграммы посетите Developing Models for Software Design в библиотеке MSDN.

РЕКОМЕНДАЦИИ Смотрите «Visual Studio 2012 Architecture Guidance – Reverse Engineering HOL» для пошаговой инструкции данного сценария.

Источник: ashamray.wordpress.com