Architecture and design with Visual Studio 2005 Team System

This article was originally published in VSJ, which is now part of Developer Fusion.
Visual Studio 2005 Team System is much more than just the next version of the developer tool suite. It addresses the entire development lifecycle, from gathering requirements to testing and deployment. Microsoft has identified six major roles within this process, as shown in Figure 1.

Figure 1: The six major roles in the IT lifecycle
Figure 1: The six major roles in the IT lifecycle

Visual Studio 2005 Team System addresses the needs of these roles through the provision of an integrated set of functionality, including:

  • project management and work item tracking
  • analysis and design tools
  • a highly functional development IDE
  • unit testing and code coverage tools
  • code analysis tools
  • performance testing tools
  • an enterprise level SCM system
  • reporting and team communications
You can see the scope of Visual Studio 2005 Team System in Figure 2.

Figure 2: Visual Studio 2005 Team System
Figure 2: Visual Studio 2005 Team System

Whilst we could fill the entire magazine, and more, with an introduction to Team System, the remainder of this article is focused on the designers highlighted under the section labelled Visual Studio Team Architect.

The problems of architecture and design today – complexity in a service-oriented world

The applications that we are producing are becoming increasingly complex. Partially, this is down to their distributed nature, which will increase as we continue down the path towards service-oriented architecture. The fragmentary nature of these applications can make it very hard for us to visualise the communication paths, security boundaries and deployment scenarios.

If we cannot identify our applications clearly, and if we cannot accurately describe their mechanisms of communication, it makes it very difficult to reuse them across wider system implementations. In a service-oriented world, this is simply unacceptable.

“But it worked just fine in Dev”

Maybe you’ve been in one of those meetings. You know the one. It’s where you’re trying to deploy the application, but the operations guys (huh, it’s always their fault, right) have just told you that they’re not prepared to allow direct communication from the Web server in the public zone through to the main corporate database server. Of course, this wasn’t a problem in development because you were running both IIS and SQL Server on the same machine and everything worked just fine.

This scenario might sound somewhat fanciful, but it’s remarkably common to find that developers and solution architects are generally unaware of the corporate data centre policies that govern the infrastructure on which their applications will be deployed. Similarly, many operations staff aren’t well informed about the application frameworks, such as the .NET Framework, that are used by developers to build systems.

This failure in communications can lead to inappropriate designs being implemented and then failing at deployment time. Inevitably, this leads to time consuming and expensive reworking.

“Our designs are out of date the moment they hit the developer”

How many of you have seen countless UML diagrams that bear no relation to the actual system? The tendency towards agile and organic development processes doesn’t mean that we don’t want documentation; in fact, it is probably more important than ever that we have accurate information about the systems.

The Distributed System Designers

There are four designers within Visual Studio 2005 Team System that help you design and model your systems:
  • The Logical DataCenter Designer
  • The Application Connection Designer
  • The System Designer
  • The Deployment Designer
Each of these uses System Definition Model (SDM) language to define an aspect of the data centre, the applications that you are building for the data centre and how they will be deployed.

The Logical DataCenter Designer

The Logical DataCenter Designer (LDD) lets you model the servers and the allowed communication paths between them. You can see an example of a LDD diagram in Figure 3.

Figure 3: Logical DataCenter Designer
Figure 3: Logical DataCenter Designer

From the model you can see three zones (Public, DMZ and DataZone). In this example, each zone contains a single logical server, but they can contain as many servers as you have in that zone. A number of different server types are provided, including Windows, IIS Web, Database and Generic servers. Note that the model provides a layer of abstraction over the actual physical servers, where one logical server might be implemented by a cluster of physical servers.

The channels of communication between the servers and the zones are modelled with end points. Each zone and server can have a number of incoming and outgoing end points. For example, the DataZone has an incoming end point, labelled Port1433 in the diagram. You can model any constraints that might apply to the communication with this zone by clicking on the end point and then by using the Settings and Constraints editor, as shown in Figure 4.

Figure 4: EndPoint settings and constraints
Figure 4: EndPoint settings and constraints

In this case, we wanted to constrain the zone to only allow SQL Server’s Tabular Data Stream (TDS) communication, so only the TDSServerEndpoint option is checked.

Servers can also have their settings and constraints modelled. For example, you can configure the IIS settings for a Web server and also specify constraints on which features of ASP.NET are supported or required – see Figure 5.

Figure 5: Settings and Constraints Editor
Figure 5: Settings and Constraints Editor

When you are happy with the model, you can validate the diagram to ensure that the model is consistent.

The Application Connection Designer

The Application Connection Designer (ACD) lets you model the different applications that might be used within a system. Each application typically represents a single executable that can be hosted, either as a Windows application or as an ASP.NET Web application or service. The application will often map onto a single Visual Studio project, but there is nothing to stop you from having an application that is composed of a main project and which references many class libraries.

These applications that you are creating are known as internal applications, because you are responsible for their development and deployment. The ACD will also let you model external applications, such as databases and Web services upon which your application depends.

Figure 6 contains an example ACD diagram for a simple Web application that comprises a public Web site that uses an underlying Web service and a SQL Server database.

Figure 6: Application Connection Designer
Figure 6: Application Connection Designer

It is important to note that the ACD can reverse engineer existing Visual Studio projects into applications within the designer. It can also be used to generate a new project for each of the applications. This latter option is known as implementing the application, and it will generate the requisite template files using either Visual Basic or C#, depending on the settings for each application.

It is also worth noting that you can configure any Web service end point details, including the operations, their return types and their arguments, inside the ACD. An example of this is shown in Figure 7.

Figure 7: Configuring a Web Services endpoint
Figure 7: Configuring a Web Services endpoint

When you implement the application, the template methods will be generated for the service. However, this is not a one way process, and any changes made during development will be reflected back in the model.

This ability to keep the model in sync with the actual code solves one of the main problems that can arise when you use disparate modelling and development tools.

The System Designer

The System Designer (SD) lets you compose a system out of the applications that are present in the ACD, along with any defined sub-systems. This additional level of abstraction enables designers to build complex systems as an aggregation of smaller systems, as well as override constraints and settings for particular application deployments. For example, you could configure a different set of system settings for an application that is being deployed on an Intranet server than for its use on a public Web server.

You can see an example of a system design in Figure 8.

Figure 8: The System Designer
Figure 8: The System Designer

The Deployment Designer

When working in the System Designer, you can choose to define the deployment for the system. This launches the Deployment Designer, which consists of a readonly view of the logical data centre diagram that you will have created with the LDC designer.

You are also presented with a list of the applications that are the constituent parts of the system, as shown in Figure 9.

Figure 9: The Deployment Designer
Figure 9: The Deployment Designer

“Deploying” the system involves nothing more than dragging and dropping the applications onto the relevant servers. Of course, what makes the Deployment Designer so effective is that it will validate the settings and constraints established for each application against the constraints defined for the server that you are trying to deploy each application on. The designer will actually validate as you try to drag and drop the application onto the server, thus preventing you from deploying it incorrectly. Any incompatibilities that are introduced during subsequent editing are presented as errors in the Error List inside Visual Studio. Like all errors, you can double click on an item and Visual Studio will take you to the correct point in the diagrams so that you can examine and edit the problem.

The Deployment Designer will also fulfil another important role: it will generate reports that can be used to help automate the system deployment to the live data centre.

Turning designs into reality

So, you’ve modelled you data centre, designed and visualised your applications and are sitting back feeling pretty good about life. What happens next? Remember, the Application Connection Designer lets you implement one or more of the applications. Or rather, it will generate the template code in projects that you can then hand off to the developers for them to code the internals, as shown in Figure 10.

Figure 10: Application implementation
Figure 10: Application implementation

One of the main problems that we’ve had with diagramming tools in the past is that the models quickly become out of date. This is not the case in Visual Studio 2005 Team System. The model document files are maintained as part of the solution and the projects, so they can reside in the same SCM system as the implementation code. They also support round trip design and implementation. Thus a change to a Web service method in either the designer or in the code editor will be reflected in the model.

“Hey, I’m a developer too – where are my class diagrams?”

Visual Studio 2005 now comes with a class designer. Again, in keeping with the concept that the model and the code must be kept synchronised, you can edit and create classes in either the code editor or the class designer and have instant round trip support.

For those of you already familiar with class design tools, it will let you establish the normal class hierarchies, implement interfaces, override methods and so on. The designer is also aware of .NET specifics such as delegates and events. You can see an example of the new class designer in Figure 11.

Figure 11: The Class Designer
Figure 11: The Class Designer

It is worth noting that the designer doesn’t use standard UML notation, although if you are familiar with UML you will have no problem reading these diagrams. Many designers and developers also use other UML diagrams, such as use cases or state diagrams. Currently, there is no support for these diagram types other than through the use of external tools, such as Visio.

Conclusion

Communications between development and operations is one of the major problems when working on large, enterprise scale systems. It is critical that architects, designers and developers understand the constraints that their applications will have to comply with at the outset of a project. Similarly, operations need to gain a much greater awareness of an application’s requirements, even down to understanding when and why new servers will need to be introduced to cope with an application’s demands.

Modelling the data centre, and then architecting and designing applications so that they will actually deploy into that environment becomes a much more practical proposition with the Distributed System Designers that come with Visual Studio 2005 Team System, as both parties can now communicate these requirements using a common vocabulary._


Dave Wheeler is a Principal Technologist with QA, a Microsoft Gold Partner for Learning Solutions in the UK. He specialises in .NET application development and design. Dave will be presenting a number of sessions at DevWeek 2005 at the end of February, including a two-parter focusing specifically on Visual Studio Team System.


An introduction to System Definition Model

System Definition Model (SDM) is a modelling language that is used to document distributed systems. A distributed system is defined as the software and hardware that work together to achieve a common function, such as a line of business application or a corporate Web site.

SDM is used in three main areas within the IT lifecycle:

  • During design, where the model captures all of the configuration and deployment requirements for the system
  • During deployment, the model can be read to automatically configure and deploy servers and applications
  • Through the ongoing operational management of a system, where administrative tools will interact with the systems through the use of notification and management services

You might also like...

Comments

Contribute

Why not write for us? Or you could submit an event or a user group in your area. Alternatively just tell us what you think!

Our tools

We've got automatic conversion tools to convert C# to VB.NET, VB.NET to C#. Also you can compress javascript and compress css and generate sql connection strings.

“Beware of bugs in the above code; I have only proved it correct, not tried it.” - Donald Knuth