Layer Diagram

At TechEd2008 this year, the Rosario April CTP version of the VSTS Architecture Edition bits were demo'd during BillG's keynote by Brian Harry. Brian demonstrated the Architecture Explorer and the Layer Diagram. The Architecture Explorer is part of the April CTP, but the Layer Diagram did not make that CTP. I've received so many questions about that designer that I wanted to elaborate on the features of the diagram that you saw in the keynote, and describe the problem that diagram is out to help solve.

The Layer Diagram is designed to allow you to specify the various layers that make up your system's architecture. It is a way to describe what you believe your architecture is, and then provides you a way of discovering what it really is. :)

The diagram itself is very simple in notation, with only two main tools in the Layer palette, the "Layer" shape and the "Dependency" link. You can name those layers, describe allowed dependencies between those layers ( more on this later ), map your existing assets ( code, docs, what have you ) onto those layers, and validate that your architecture is conforming to the diagram.

Here's a very simple layer diagram that shows a typical system with a UI or Presentation, Business or Domain Logic, Data, and Logging layer:

Here is that same diagram "annotated" a bit, to describe some of the capabilities in the diagram:

There are a number of ways you can approach this diagram, below is one:

1. Create a new Layer diagram from scratch

2. Draw the various Layer shapes and name them appropriately

3. Use the Dependency connector to indicate the direction of allowed dependencies. As I mentioned in the annotated image, the lack of dependency links is also meaningful, in that you are indicating to the system that dependencies between two layers is not allowed.

4. Specify additional constraints per layer that you would like to see enforced. As an example, you will be able to indicate on a per layer basis what namespaces are allowed in that layer, and which are not allowed.

5. Map your physical assets to your specified layers. You map your assets ( code, documentation, entire projects or solutions ) via drag & drop from the Architectural Explorer and Solution Explorer. ( Later in the cycle, there will be more capabilities added around this step. )

6. Validate your architecture

This last step is where things get interesting. Steps 1-5 were all about specifying what you believe your architecture is and should be. Step 6 is all about telling you what it is.

But when does validation occur, and what do violations look like?

Validation can be done via a simple context menu gesture ( right click on the diagram and select "Validate" ), or as part of a check in policy, and as part of your build. The product will examine your Layer diagram ( you can have many by the way ), discover what assets are mapped and what constraints are being specified, and then analyze those assets with those constraints in mind.

A violation ( currently ), shows up in the Error window.

This should give you a better idea of what this diagram is all about, and you'll be able to take it for a test drive in our next CTP this fall.

Cheers,

Cameron

Comments

• Anonymous
  July 11, 2008
  PingBack from http://blog.a-foton.ru/2008/07/layer-diagram/
• Anonymous
  July 18, 2008
  Maor David on Teamprise 3.1 is now available Mitch Denny on The error code is 2738 Paul Hacker on SQL...
• Anonymous
  September 30, 2008
  In one of the articles that just hit recently around our upcoming "Architectural Validation" feature
• Anonymous
  January 29, 2009
  In the days long ago before I joined Microsoft, I was an itinerant consultant in UML. I'd wander the
• Anonymous
  February 01, 2009
  The comment has been removed
• Anonymous
  August 17, 2010
  Can you explain the steps of validating the layer design?