TN_1113: Representing Connections to Manual, Physical and Other Kinds of Systems

Bill Gibson, Program Manager
Microsoft Corporation

This note discusses a way to improve the design of an application system by modeling other systems that lie just outside its boundaries. The principle mechanisms available to accomplish this are the use generic applications and custom-built system types. These peripheral systems may include manual and physical systems as well as other software systems.

What is a System?

The System Definition Model (SDM) adopts an encompassing definition of a system. SDM defines a system as an independently deployable configuration of resources. If a system offers access to its resources, or if its resources need to access services offered by resources in other systems, it exposes those resources via endpoints. SDM also defines the notion of atomic and composite systems. An atomic system is composed directly of resources, while a composite system is composed of other systems.

For application systems, resources represent directories and files, for example, binaries, XML files, configuration files, and SQL script files. For hardware systems, such as graphics systems, motherboards, and network interface cards, resources represent the physical pieces, for example, the actual boards, as well as the processor, memory, cooling, and other components on them.

This definition is not limited to software or hardware systems. In fact, almost any system fits this definition, including manual systems, physical systems, mechanical systems, and probably even biological systems! In a manual system, resources may include people, documents, devices, tools, and other artifacts. In a physical system, resources may include machines, vehicles, buildings, rooms, and people.

SDM is focused on modeling system structure, which is defined by describing compositions of systems and their interactions. SDM is not focused on modeling the behavior of these systems, which is described by extension models, if required. The Application Designer’s support for viewing and designing the operations on a Web service endpoint is an example of such an extension.

For a more information on SDM see Understanding the System Definition Model.

Why Model the Broader Context of an Application System?

Modeling all the points of interaction of an application system can help with the design of the systems. It is important to be able to consider the context in which an application system is used. Ultimately, a system design defines how the system interacts with other systems.

Representing each point of interaction with other systems helps ensure that all use cases are considered in the design process. It also helps visualize the intent of a system when communicating your designs to stakeholders inside and outside the development organization.

It also helps when we come to map a design to a datacenter model to ensure we have taken into account all the touch-points. If a system is required to interface with a specific device, is there a channel from the server to that device; if a system is required to be connected to by a user at a browser on the internet, is that communication channel supported by the datacenter?

If you are designing a system from the top down, identifying all the interactions at the high-level helps ensure they are not forgotten as you refine the design. Exposing each of the interaction points at the high-level more or less forces you to assign this responsibility to lower-level systems and applications as you go. And if you don’t, the omission will be obvious. For more information, see Top-down System Design.

System Designer and Application Designer

You can use the Application Designer to create applications, which are the lowest-level atomic systems that are composed into systems. SDM base models define the kinds of applications that you can create and include in a system. The Distributed System Designers load these base models when you first open an SDM diagram. For more information see Understanding Applications and the Application Diagram

You can use the System Designer to create (application) system definitions. Each definition is visualized by a single system diagram. The system diagram depicts the system as an outer shape that contains other shapes representing its member systems or applications, which you can connect through their endpoints. A system represents a configuration of its members. You can create any number of systems that can include the same or different applications or subsystems. Each system definition is stored in an SDM document with an .sd extension. This .sd file contains a single system definition that contains references to its member definitions. These member definitions are stored in other SDM documents. For more information, see The Role of the System Designer.

Using Generic Applications and Endpoints

A pre-defined generic application type is provided and available on the toolbox. This can be used to represent applications or systems that are not otherwise explicitly supported. The name you choose for a generic application will need to describe the specific application or system as well as give an indication of its type.

Generic endpoints are also provided and can be added to any of the pre-defined applications, generic or not. You can use these endpoints to represent any kind of connection. To create a connection using generic endpoints, first add a generic endpoint to the application that you consider to provide the ‘service’ and drag a connection between that endpoint and the application requiring the service. This will create a consumer endpoint on the other application. To create connections on the diagram, press the ALT key when moving the mouse over the application or endpoint, and then drag the connection. Note that you can create a connection from either ‘end’.

You can label the endpoint to describe its purpose and the type of connection it represents. For example, you might label an endpoint ‘UI’ to indicate that it represents a visual user interface on an application. Generic endpoints do have a single unrestricted text property pre-defined named Protocol. This can be used to describe the type of communications used.

You can add custom metadata to generic applications and endpoints using the Settings and Constraints Editor. Select an application or endpoint, then right-click the Custom node under the Settings node and select Add Custom Settings. When defining a custom setting, you can indicate whether it should also display in the Properties window. A limitation of generic types and these user-defined custom settings is that they are defined each time. As a workaround, you can define ‘template’ generic applications and endpoints with custom settings and then add these to the toolbox. Of course, this does not prevent you or anyone else deleting or changing the list of settings you have defined. To prevent this, you can use the SDM SDK and create custom application and endpoint types with your own pre-defined settings which become part of the type definition and cannot be modified.

Custom Application and Endpoint Types

Custom application and endpoints types created with the SDM SDK have an advantage over generic applications and endpoints in that they allow you to define, and thus intrinsically distinguish, the type of an application or endpoint. New application types will show up on the diagram with your type name clearly visible and with an icon of your choosing. While a generic application is limited to user-defined settings, which can be removed or renamed at any point, the settings, their names and properties on a custom type are pre-defined and cannot be modified. Of course, user-defined settings can still be added to custom types.

As part of the definition of a custom application type, you need to define which endpoint types it will support. You can define that your new application type simply supports generic endpoints, which will allow you to connect applications of this new type to any other applications that support generic endpoints, or you can define and reference new endpoint types. If you define new endpoint types, you will need to define which other application types support your new endpoint type so that you can connect applications of that type. Be aware that if you add new endpoint types to existing application types, anyone who wants to open a model that uses these endpoint types must have your custom types loaded.

For more information on the SDM SDK see the System Definition Model site.

Using the System Designer to Model Interaction with Other Systems

When you have decided how to represent peripheral systems using generic or custom application types, you can define how these systems interact with the application system that you are really interested in. Using the Application Designer, create an application to represent the peripheral system you want to model and connect it to the relevant application in your application system. This will create or require that you create a new peripheral endpoint on your application. Now you need to include these new applications and connect them to your application system using the System Designer.

There are two approaches you could use that are described below.

Variation 1, Use a Context System

With this approach you introduce a new system to represent a context in which the system you are designing is used. In this context system you include all the peripheral systems that interact with the system and connect them to the system. You might define multiple context systems if the system is used in markedly different contexts.

To do this, open the application system you’re designing and add proxy endpoints for each of the new ‘peripheral’ endpoints you’ve added. See figure 1.

Figure 1 Application system with peripheral endpoints exposed as proxy endpoints

Next create a new system that represents a context in which the application system you’re designing is used. To create the context system, you can select the peripheral systems in the Application Designer, right-click one of them and select Design Application System.

Now add the real application system you’re designing to the context system diagram by dragging from the System View. You can double-click on this system to drill into it to review it or make any changes at this point. You can return to the context system diagram by clicking Navigate Backward on the Visual studio toolbar.

Now connect each of the peripheral systems to the appropriate application system endpoints and you are done. See figure 2.

Figure 2 Context system showing the application system connected to peripheral manual and software systems

If you are designing a deployment, you can do that from the application system as normal. The peripheral endpoints will not be included in the validation process.

If you are using the top-down design approach described here, connect the peripheral systems to the shadow application first and then migrate the endpoints and behaviors like any other endpoint on the shadow application as you drill into the system’s design. (See the linked note on top-down design for a description of shadow applications and how to use them.)

Variation 2, Add the Peripheral Systems into the Application System

As a variation of the above, instead of creating a context system, you can add the peripheral systems directly to the application system and connect them directly to the appropriate members. See figure 3.

Figure 3 System with generic applications added to represent peripheral systems

Which Variation to Use?

Variation 1 has the advantage that you minimize modifications to the structure of the application system (you add endpoints and delegations only), so the system content is still focused on its application function. It also allows you to create multiple alternative context systems in which potentially different configurations of peripheral systems use the application system - obviously this is not possible with variation 2, although see below.

Variation 2 is arguably simpler, and, if the peripheral systems are modeled as roles, then it is still flexible. It also allows you to see the interaction more directly between application system and peripheral systems - in variation 1, you do not see the detail of both the context and the application system on the same diagram.

Modeling Manual Systems

The following comments describe how you might represent manual systems using this technique. The same ideas can be applied to modeling physical, mechanical or other kinds of systems.

Manual systems represent human resources that provide or consume behavior in some interesting way. With respect to application systems, our primary interest is in identifying the interaction points between the manual systems and application systems. A manual system might be as simple as a single person performing an ad hoc task or as complex as a multi-person organization. Using applications or systems, you can show how manual systems interact with the application system or even interactions among manual systems.

For simple cases, it is enough to use a single ‘manual application’ to represent a manual system, whether it represents a single person activity, and an organizational entity or the role of a person or entity.

For more complex situations where a person or organizational entity plays multiple roles, composite systems can be used in which an application representing the person or organizational entity is included repeatedly to represent each role it plays. Remember, however, that the goal is not to build an enterprise role model but to expose and help you think about the interactions with the system.

Summary

The ability to represent all kinds of systems with which an application system interacts on a system diagram can help during the design of the system and in communicating this design to others. The Distributed System Designers allow this ability through the use of generic applications provided with the tools and through the definition of new application and endpoint types using the SDM SDK.