Using Architecture Explorer to analyze applications and use hierarchy diagrams

Profiling an application using Architecture Explorer

Architecture Explorer and Dependency graphs can help us understand all the projects, including small projects and large projects. Architecture Explorer can be used to study existing code, and you can use dependency graphs to select and visualize the code you want to study.

Architecture Explorer represents a structure as a node, a relationship expressed as a connection, and a diagram under the Watin Framework Project:

The function of the first option on the leftmost side is to generate a new dependency graph file from all the nodes currently selected in the Architecture Explorer. If you want to include only the nodes in the current column, you must press and hold down the CTRL key before clicking this option.

The function of the second option is to add the selected node in the Architecture Explorer to the dependency graph that is currently visible in vs.

The third option is to export information from the Architecture Explorer into a. dgml file, which is the XML schema used to define the dependency graph.

The fourth option is to reset the architecture Explorer to the initialized state, thus achieving the purpose of clearing the window to start again.

By clicking on the filter, you can select one or more of these filter options to study the information contained in the column in different ways:

In addition to the above screening methods, we can also click on the types to expand the filter bar:

This column provides a number of options that can be used to determine the initial display of the column. Connection types can be divided into outbound and inbound, which describe the direction of the connection to the currently selected node. Outbound refers to a node that points to a related node from the current selection. Inbound refers to the node that is currently selected from the previous related node. Use the analysis option to view a circular reference or hub (for example, a class) that can be either not called or used. Use the grouping option to group by container, attribute.

Dependency graphs can be used to explore the relationships and organization of existing code. These graphs make it easy to understand new or unfamiliar code. The relationships in the diagram clearly illustrate the dependencies between the different regions of the code, and what code changes can have a potential impact.

Dependency graphs only show dependencies in the code that was generated by the successful compilation. Code that does not generate successfully will not appear in the dependency graph.

Indicates the relationship between namespaces, and other information can be extracted to derive the dependency graph you want to view, as shown in:

Hover over a node in the diagram, and you can also browse the details of that node. You can also jump to the node's method definition by right-clicking it.

The above creation dependency graph is used by architecture Explorer, and we can select Architecture--> Generate Dependency graph--> for solution in the VS menu to create a dependency graph:

By expanding, you can see the schema of the entire project, and the style displayed after the expansion is the same as using the code map effect.

Therefore, using Architecture Explorer in conjunction with dependency graphs and using the code map method can help us quickly understand the entire project code.

Using the hierarchy Chart

A hierarchy chart can be used not only to describe the structure of an application from a higher level, but also to verify that the code being developed meets the design of the upper layer. A very good feature of the hierarchy diagram is the ability to verify that the architecture of the application design is consistent with the codebase, ensuring that the code and schema always match during development.

The hierarchy diagram shows the main components of the architecture design, and the dependencies between components are also reflected in the hierarchy diagram. A graph consists of one or more nodes, called layers. A layer represents a logical grouping-for example, a namespace or class file.

Although the hierarchy diagram is within a modeling project, it can connect to any item in the current VS solution.

Each layer in the hierarchy is displayed as a rectangle, and different layers can be nested together, called groupings. Different layers in a hierarchy chart define logical groupings of items, including methods, classes, and namespaces.

As a general rule, items with the same dependencies should always be placed on the same layer. Items that can be updated independently (or items that are used in standalone applications) should be placed on different tiers.

Layer Explorer can be used to browse items that are connected to a particular layer, and they can be moved between layers.

After the layers are defined in the hierarchy, the next step is to identify the dependencies between the different tiers. There is a dependency between the two tiers, regardless of whether the item in one layer is a reference or an item in another layer.

A hierarchy chart can validate the schema. The validation of the hierarchy chart enables you to verify that all dependencies between layers are correct. This feature enforces rules and dependencies between different tiers. If the validation is successful, return as shown:

You can drag and drop any file or item contained in the Solution Explorer onto the hierarchy, creating a new layer with the same file name or project name and a connection to the file or project.

With Architecture Explorer, you can not only drill down into the information you are interested in (such as namespaces), but you can also drag and drop namespaces into a hierarchy, which will be represented as a layer on the hierarchy, and layers connected to that layer will also appear in the hierarchy.

You can also drag dependency graph information directly onto a hierarchy, which can also create layers.

Using Architecture Explorer to analyze applications and use hierarchy diagrams