TN_1111: Top-Down System Design

Bill Gibson, Program Manager
Microsoft Corporation

This note describes a technique for designing systems from the top down using the System Designer. 

Introduction

In Visual Studio Team Edition for Software Architects, the System Designer is optimized for bottom-up ‘composition’ of systems from pre-existing applications or systems. However, top-down design of systems is also a valuable architectural design technique.  Using top-down design, a system architect first describes the overall behavior of a system and then progressively drills in to the design to identify further sub-systems or applications. The architect then assigns aspects of the system behavior to these system members.  Eventually, all system behavior are assigned to applications that will be or are already implemented.  Any number of levels of sub-systems might be defined using this process. 

While top-down design was not a key scenario for the first release of the System Designer, it does support a top-down or system ‘decomposition’ approach.  Ideally, you would be able to add endpoints to a system directly and then later delegate the behavior to endpoints on member systems or applications.  However, in Visual Studio 2005, you can only create system endpoints by adding them from the bottom up as 'proxy endpoints' for existing endpoints of member systems or applications.  However, with a little care and using a little-known feature, it is easy to overcome this limitation and design systems from the top down.  You will also see how the approach allows an iterative and agile process to be used; you should not confuse top-down design with a waterfall process.

Summary of the Approach

The top-down design approach is reasonably straightforward. First, you create a system and a 'shadow' application whose sole purpose is to define the behavior of the system.  You include this application in the system and expose all its endpoints from the system using proxy endpoints.  The system can now be included and connected within other higher-level systems if required.  Over time, as you determine how the system should be implemented, you define and include lower-level sub-systems or applications and progressively delegate the behavior of the system endpoints to the endpoints on these members instead of the shadow application.  As you can use this technique recursively to create and include new systems, you are able to progressively refine a design from the top down using any number of levels of nested systems.

Re-assigning a Delegation

A system is simply a configuration of its members.  An endpoint on a system exists solely to expose the behavior of a member, which is represented by the delegation of the system endpoint to a member endpoint.  For this reason, system endpoints are referred to as proxy endpoints.  The top-down design technique pivots on a feature that allows you to associate a different member endpoint with a proxy endpoint. This feature allows you to move the target of the delegation of the proxy endpoint from one member endpoint to another in a single action.  While you might be tempted to delete a delegation and then add another to achieve the same result, deleting the delegation also deletes the proxy endpoint. This action has a ripple effect in systems that include the system you’re editing as a member- it deletes from that system all connections to, delegations to, and proxies of that endpoint. Using the move delegation feature has no such ripple effect and makes top-down design a practical proposition.  

An Example Walkthrough

The remainder of this note walks through an example of top-down design and describes how to use the move delegation feature. In the example, we start by creating a high-level Auction system and describe some of its key behaviors that are exposed as system endpoints.  We add a Bidding system as a subsystem of the Auction system and then drill into the Bidding system to define a Bidding application. The Bidding application offers a Web service and a bid history database to implement the Bidding system's behavior.

First, let's define the Auction system.  You can create this by adding a new system diagram directly from the Solution Explorer. However, as we need to create an application inside the system, we'll create the application first and then add the system using the Application Designer, which will be a little easier.  In the Application Designer, we drag an ASP.NETWebService prototype onto the diagram to add an ASP.NETApplication and name it AuctionSystem_shadow. We then rename the default Web service endpoint as Bidding.  Next, we add additional Web service endpoints named Buyers, Sellers and Administration to support the other behaviors that the Auction system exposes.  Now we’re able to define the behavior of each endpoint.  At this point, the application looks like this.

Figure 1. The Auction system’s shadow application on the application diagram

On the Bidding endpoint, we add the operation SubmitBid with an input parameter NewBid of type Bid, which returns a Type BidAcknowledgement.  Note that you don't define the types yet; you only name them at this stage.  Detailed type definitions are required only once you generate code.  We could add other operations, but this one operation is enough for our example.  It is not required that you define the operations before you drill-down into the system design. In fact, endpoint behavior can be defined at any point in the process.  As a rule, you should create as few shadow applications as possible. These applications only exist as placeholders so that you can describe the system endpoints.  Once the shadow application behavior has been migrated to lower-level subsystems and applications, the shadow application will be deleted.  However, the shadow application can be updated as often as required during the design process by adding, removing, or updating endpoint definitions to keep the system specification current.

Now we select our shadow application and choose Design Application System.  In the dialog box, we name the new system AuctionSystem.  In the resulting system diagram, we visit each endpoint on AuctionSystem_shadow and add a proxy endpoint to the AuctionSystem.  You do this by dragging a delegation line from each endpoint to the system border or by right-clicking each endpoint to add a proxy endpoint.  The AuctionSystem now looks like this.

Figure 2. The Auction system with proxy endpoints delegating to its shadow application

You’ll see that we have defined our high-level system and described some of its behavior. We can now include this system in other higher-level system diagrams. In the diagram below, you can see how we can include this system in a higher-level system and connect consumers to the endpoints offered by the system even though we have not even remotely started to define how the Auction system will be implemented. 

Figure 3. The Auction system included in another system context

The next stage is to drill down into the Auction system and describe how it is to be implemented.  This can be done progressively and iteratively, so there is no need to proceed in a waterfall fashion.  In fact, we have done enough in our example to progress to a complete implementation of the SubmitBid behavior if we so choose. 

When you are ready to refine the system and define the next level of decomposition, we ‘migrate’ the behavior from the system's shadow application to other applications. These applications are those we either intend to implement or use as shadow applications of lower level systems.  The behavior is migrated as follows. 

On the application diagram, create or locate the application to which you will migrate the behavior.  Add copies of the appropriate endpoint(s) by copying and pasting them to the new application.  Note that you can migrate endpoints progressively over a period of time, so there is no requirement that they are all migrated at once.  This allows you to drill into some parts of a system but leave others aspects defined only at a high-level. 

So in our example, we will add a BiddingSystem_shadow application as above and copy the Bidding endpoint to it.  At this point, you should have the following two applications on the application diagram.

Figure 4. The two shadow applications on the application diagram

Now we select the BiddingSystem_shadow application and create the BiddingSystem in the same way we created the AuctionSystem before.  Then on the resulting system diagram, we expose the Bidding endpoint as a proxy endpoint.

Figure 5. The Bidding system with its shadow application

Next, we return to the AuctionSystem diagram and open the System View window if it's not already open.  This window provides us with a list of all the applications and systems in the solution that are available for inclusion in the auction system.  We locate the BiddingSystem under the Systems node and drag this to the system diagram as a peer of the AuctionSystem_shadow application.  At this point, the AuctionSystem looks like the image below with all its behavior delegated to the AuctionSystem_shadow application and an unconnected member, BiddingSystem, which has one endpoint, Bidding.  At this point, if we select the Bidding endpoint on the BiddingSystem and choose View Operations, we see that it defines the NewBid operation as does the Bidding endpoint on the AuctionSystem_shadow.

Figure 6. Bidding system included in the Auction system

Now we use the 'move delegation' feature to reassign the delegation so that a consumer of the bidding service is delegated to the new BiddingSystem.  Move the mouse over the Bidding endpoint on the AuctionSystem, press the ALT key and drag a new delegation line to the Bidding endpoint on the BiddingSystem.  In one step, the delegation to the shadow application is deleted and replaced with a delegation to the Bidding endpoint on the lower-level system. 

Figure 7. The Auction system with the Bidding endpoint delegated to the Bidding system

At this point, we can tidy up the shadow application and delete its Bidding endpoint. When we are ready to describe the implementation of the BiddingSystem, we go through the same process again.  We will implement the bidding system using an ASP.NETWebApplication with a Web service plus a database that will only be accessed through the Web service.  In this example, our shadow application can be used as the basis of the implementation, so it's enough to rename it BiddingManager, add the external BidHistory database, and connect it to BiddingManager.  You will need to rename the application on both the application diagram and the system diagram.  We then add the database to the Bidding system and connect it to the BiddingService application.  Note that by not exposing the database connection endpoint on the system, we have made the database private to BiddingSystem.  At this point, we would continue to flesh out the detail of the application using the Application Designer before implementing it as normal.  The final form of the BiddingSystem now looks like the following image. BiddingSystem remains delegated in the AuctionSystem, which is connected in the EnterpriseSystem.

Figure 8. The final configuration of the Bidding system

At this point, if the EnterpriseSystem were to be deployed according to these system definitions, the delegations and connections would all be resolved and the AuctionPortal application would be configured to connect to the BiddingManager.

Implementing the Shadow Applications

One interesting extension to this approach is to implement the shadow application with simple stubbed-out behavior.  This will allow you to do some limited testing of consumers of the system before you're ready to commit to the details of the system's implementation design.  In this way, you can adopt an agile programming approach even while you're doing top-down design. 

Summary

With a little additional effort, the System Designer supports top-down design and can be used to progressively design the implementation of a system, using both sub-systems and applications. The key to this is the ability to re-assign a delegation which allows behavior first defined at the level of a system to be migrated to the applications that will implement that system.