· TN_1104: Understanding the System Definition Model

· TN_1114: The Four Layers of Systems in the System Definition Model

· TN_1100: Understanding Applications and the Application Diagram

· TN_1105: Why Class Libraries are not shown on an Application Diagram

· TN_1109: Understanding Systems and the System Designer

· TN_1101: Understanding and Using the Default System

· TN_1110: Using Systems to Represent Services in a Service Oriented Archite cture

· TN_1112: System Portfolio Management

· TN_1102: Designing Substitutable Web Services

· TN_1113: Representing Connections to Manual, Physical and Other Kinds of S ystem

· TN_1111: Top-down System Design

· TN_1108: Connecting Applications to Web Services via Class Libraries

· TN_1106: Copying Endpoints vs Creating Endpoints from WSDL

· TN_1103: Web Service Endpoint Name Propagation

· TN_1107: Understanding, Using and Creating Toolbox Prototypes

· Why do ASP.NET WebService and ASP.NET WebApplication look alike on the Application Designer?

The Tech Notes didn’t print well for me (cutting off the right hand side) and could find no other “printer friendly” means of viewing the contents of these notes. I ended up just copying and pasting the contents of each note into a single Word document so that I could just print them all out and carry with me (I hate reading too much text on the screen). This ended up working out nicely getting the diagrams and all (it came to about 50+ pages.

Now, on to my thoughts on this new architecture/design feature in VS2005.

One of the biggest things I am finding with these designers is the simplicity of expression.

Unlike Visio, objects in the designers are more meaningful and are a breeze to arrange and connect, making the actual mechanics of laying out a diagram just easier and more efficient. Furthermore, and still unlike Visio, there is good “connectedness” between different layers giving seemless drill down through the different layers of nested systems. Finally, another big difference between Visio and the designers is the meaning behind the objects. The designers yield much more than a pretty picture, but a live and synchronized model of your applications and systems. They don’t get out of date or out of sync with the code.

These features and experience have led me to start thinking about all the other modeling techniques so prevalent in my industry and amongst my peers. Are modeling techniques found in the typical UML stack (4+1 diagrams, State, Sequence, Collaboration diagrams, etc) still relevant? I imagine pieces are, but probably more downstream from the definition of the applications and systems. Some of these disconnected modeling tools might be relevant in helping to define and structure the internals of individual applications where the designers are focused more on the interfaces between different applications and/or systems.

I haven’t formed an opinion just yet, but one is forming as I am exposed more and more into using the new designer tools that were formerly referred to as Whitehorse.