A Visual Studio Team Edition for Software Architects Orcas Project Walkthrough

A small [I hope not to big] walkthrough of how you can work with Visual Studio Team Edition for Software Architects [VSTESA] Orcas, the PowerTool and some extra extensions [see this blogpost and this one].

First what kind a project we are working on.
The project is a new front-end for an existing backend system. The purpose of the application is to support the manual entry of scanned data, while guiding the user using a workflow based on a variable product structure.
The application has its own database, but relies heavily on interfaces to five other backend systems.
The application has four goals:

  1. Fast introduction of new products.
  2. Generic handling per product.
  3. Efficient handling of new accounts / orders through workflow.
  4. Management reports.

The backend system is a custom ESB with a message standard based on IFX [Interactive Financial eXchange], this means, allot of custom types and big XSD’s, but that isn’t the challenge. The challenge will be authorization and communication with this ESB. Mainly because the ESB is not yet working with .NET 2.0 or higher. So we have to make 1.1 services which will communicate with this bus. Behind that WCF services which will be consumed by the front-end. By this it’s going to be easy to throw the ASMX services away when the ESB is upgraded.

We start by defining the system / system of systems in the System Design [Top-Down Design].
This is different than the 2005 version of VSTESA, where you had to start with the Application diagram or the Logical Datacenter diagram.

Bill Gibson: Using top-down design a system architect can first describe the overall behavior of a system and then progressively drill in to the design and identify further sub-systems or applications, and then assign aspects of the system behavior to these system members. 


In the Orcas version you can start with defining systems, which is much more comfortable because at this stage we didn’t exactly know how the application landscape and the interaction between the applications would look.

When starting a new Distributed System Design an empty System Design will be opened by default. Within this “main” system design we will add other systems.
The first one will be called ESB_System and the second the Website. Within the ESB_System will be the ESB and the 1.1 services, those systems won’t be used for development during this project [actually the 1.1 services we do, but it is not possible with Orcas to create .NET 1.1 applications, so they will be developed on another VPC]. This system will expose five endpoints which the WCF service must consume.

This is how the ESB system will look like [picture at the right/ top], a generic application and a .NET Service application with five endpoints all with a proxy endpoint to the border of the system and off course a connection between the two applications. None of these applications will be implemented during this project, but during code generation they are useful for creating the service agents [see later on in this article]

The main system, with only the Website system and the ESB system will show those proxy endpoints. It is useful to think upfront about the naming of the systems, the applications and the endpoints, just because changing them after you have implemented them is hard.

sdLet's continue with the website system. The website has got its own database. So we will draw two systems in the website system, one called DatabaseSystem and the other FrontEnd.
The reason why separated them in two systems is that I think you have to look at systems as separated pieces of deployment. You want to be able to deploy [and visualize] the database without the website and vice versa. Later on you will see that it's useful, also because the website isn’t just only an ASP.NET site but it also exposes some functionality through services.

The next step is adding the WCF services to the systems, first I thought: one system is enough. But when I looked at the purpose of the services, I made two systems. One service had to do some batch working, while another did some authorization. Those are two completely different things; for sure the first one had to do some hard working while the other one had to be more secure. So two services systems, one with four applications and one with one application.


Finally the system design looks like this [picture below] the other two systems where added later on to the project and because of new insights some endpoints where changed. 

The "four services system" looks like the picture at the left. As you can see they consume endpoints and they expose endpoints bounded to the system border with proxies.serv

Up till now I didn’t do anything with the properties, settings and constrains. I only focused on the system, how it would look like and their names. What the connections are between the systems and what kind of applications or child systems there are within those systems.
But we do have a nice overview of the system of systems and their applications, you can dig in to a system and you can use it to present it to the stakeholders for some discussion. That’s where software architecture is about defined by the Software Engineering Institute:

“The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them.”[ Bass, L.; Clements, P.; & Kazman, R. Software Architecture in Practice, Second Edition.Boston, MA: Addison-Wesley, 2003.]

And more definitions see this post: “Extending Visual Studio Team Edition for Software Architects to meet real architectural goals.”


This story will continue with the  Application Diagram next post...

Add comment