Designing new functionality on existing applications can be daunting. There are always differences between the original design and the current implementation.
The new Architecture tools within Visual Studio Team System 2010 help you understand the application you have, design new functionality you need, and validate that your design and your implementation do not deviate.
Understanding What You Have
Understanding the dependencies between parts of your application can be critical to determining where you may have problems. Additionally, having a visual graph can help you find the best place to implement new functionality.
You can get a big picture view of your solution by assembly, namespace, class or a custom filter in a Directed Graph Markup Language document (DGML) using the Generate Dependency Graph feature:
The DGML document generated from your solution can be visualized as a Dependency Matrix, Force Directed Layout, or as a Top to Bottom layout, as shown below. Each view can provide a different take on the structure of your project.
This high-level view is a great way to understand the overall shape of your architecture, but understanding the dependencies for an area you need to change can make the difference between a fifteen-minute change and a one-hour change. For instance, being able visualize the relationships around the Cart class can be very helpful in making changes to the shopping cart:
Another valuable way of understanding how your application works is to be able to visualize the sequence of calls that happen in key sections of your application. The Generate Sequence Diagram function, available in the code editor, will give you a view of the method calls your application makes. Below, you can see the sequence of calls that make up the Add method implementation within the shopping cart.
Designing New Functionality
Now that you have a more complete understanding of your existing application, you are in a better position to add functionality. Collaborating on design requires communicating in a standard way. Unified Modeling Language (UML) diagrams allow you to express your design in a way that others can understand. For instance, you can build UML Component and Class diagrams that describe the existing structural elements of your design, then add new elements to the diagrams to illustrate and document your changes. Below is how a completed Component diagram might look:
A Class diagram might look like this:
The Use Case diagram below enables teams to better understand and agree on the functions of the application.
Once you have a UML diagram, you can create or link designer elements to work items within Team Foundation Server’s (TFS) Work Item Tracking system.
Ensuring Application Validation
Over time, the code quality of a project can degrade if bug fixes and new feature implementations are not done with overall architecture in mind. This is where the Layer designer and Layer validation can help. The Layer designer enables you to define the logical layers and valid communication paths between layers of your project. Once you have associated assemblies, namespaces, and classes with layers in the Layer diagram, you can validate existing or new code against the layering constraints. For example, in this Layer diagram, it is valid for software within the Presentation layer to have dependencies on software within the Business Logic layer. However, since there is not a dependency line between Presentation and Resource Access, any software that attempts to take that dependency would cause a compile-time violation in the Error List.
You can validate layer constraints from the designer surface, command line, or from within the build process. Team Build’s gated check-in process ensures that layer constraint violations never make it into source control.
These are some of the features in Visual Studio Team System 2010’s architecture tools. You can get more information about these and other features at Cameron Skinner’s blog.