Designer Relationships and Team System Integration

Being presented with five new visual designers, each representing a different view of the overall system, you might be wondering how they all fit together. This section describes the important relationships between the designers, in the context of who uses which designer.

Note

Traditional methods of teaching visual modeling often present a set of notations that individually represent one aspect—or view—of the system without describing how those various views are interrelated. You might learn, for example, that a UML statechart shows transitions between states triggered by events; and that a UML sequence diagram shows messages being passed between objects; but without further guidance, how do you deduce that the events in the statechart are related to the messages in the sequence diagram?

In Figure 1-8, we have used a Visio UML Activity Diagram for convenience to show how various roles within your software development organization would typically use the visual designers, including the artifacts that would be produced or consumed at each stage.

Figure 1-8

Note

We've not used a Team System diagram because as yet there is no diagram suited to that purpose. That situation might change with future releases; in the meantime, we see a retained role for Visio in cases such as this.

You can read the diagram shown in Figure 1-8 in one of two ways:

• A process flow diagram (in bold) showing the activities performed by the various roles—that is, who uses which of the visual designers

• An object flow diagram (not bold) showing the objects produced and consumed by each activity—that is, the artifacts exchanged between the design tools

The following sections describe each of those perspectives in turn.

Process flow (roles and activities)

The role names that we have used are only indicative, because in reality the exact role names and the scopes of those roles will depend on the process that you follow: MSF for Agile Software Development, MSF for CMMI Process Improvement, the Unified Process, or whatever else you choose. Regardless of process, the order in which the designers are used and their interactions via artifacts are likely to be as shown in Figure 1-8.

Initially, the process flow branches into two parallel activities such that operations analysts may use Logical Datacenter Designer to define the logical infrastructure, and the application solution designer/architect may use Application Designer to define the overall shape of the system, completely independently.

Once the Application Design has been completed, the designer/developer can define the code structure for each application using Class Designer.

Once the Application Design and the Logical Datacenter Design have been completed, the application solution designer/architect can use System Designer to group applications into systems, and then use Deployment Designer to specify and evaluate how the application systems will be deployed on servers of the logical datacenter.

Object flow (artifacts)

The output from Application Designer is a set of Application Definitions expressed in SDM syntax and stored in an.ad file. If you generate projects, the SDM files that describe the applications are stored in the projects as.sdm files.

Class Designer may be used to refine and restructure the skeleton projects code and to define new code structures within those projects, resulting in final deliverable code.

System Designer accepts Application Definitions and enables you to compose systems as groups of applications, resulting in a set of System Definitions stored in an.sd file and again expressed in SDM syntax.

The output from Logical Datacenter Designer is a set of Logical Server Definitions expressed in SDM syntax and stored in an .ldd file.

Deployment Designer accepts System Definitions and enables you to map systems onto servers, resulting in a deployment map (as SDM) and a Deployment Report. The Deployment Report may be human-readable (as HTML) or machine-readable (as XML). The latter allows for automated deployment via scripting.

Settings and constraints

When you produce application definitions using Application Designer, you can specify settings and constraints for those applications, and these may be refined when you produce system definitions using System Designer. You can also specify settings and constraints when you produce logical server definitions using Logical Datacenter Designer.

What you need to understand is that the settings and constraints defined using Logical Datacenter Designer work in the opposite manner to those defined using Application Designer and System Designer. Application and System settings must be compatible with the constraints of the Logical Server that will host them. Logical server settings must be compatible with constraints of the applications and systems to be hosted.

By defining constraints on a server, the operations analyst is saying to the application architect, "If you want to host your application on this server of my logical datacenter, then you must satisfy these constraints via your settings." By defining constraints on an application or system, the application architect is saying to the operations analyst, "To host my application, you need to provide me with a server whose settings match the constraints of my application."

Source control and item tracking

Because the diagrams that you draw, and the application and server definitions that you produce, not to mention the project source code, are all stored in files, these may be checked in or out of the source control portion of the Team System and tracked as artifacts, in part to eliminate clashes during team working (i.e., two people trying to work on the same diagram at the same time) and in part to provide a versioned history of certain artifacts. For example, the operations team might want to baseline the logical datacenter diagram at various stages, by version controlling the .ldd files.

When controlling diagrams and files, you need to consider whether those items have an independent life cycle or whether they are intrinsically linked to specific Visual Studio solutions. For example, the .ldd files that define a logical datacenter are truly portable. Therefore, they may be included in any number of solutions or many can be contained within one solution. Conversely, the .ad files that define the application design are limited to one per solution, and tie into a specific solution once implemented. You can have as many class diagrams in a project as you like, but these are tied in absolutely to the source code that they visualize.