UML Deployment Diagrams – Modeling the System Physical Architecture

In the previous post we saw how component diagrams can be used to model the logical architecture of a system. In this post we’ll see how deployment diagrams are used to model the physical architecture of a system; we’ll start from the most simple use of the deployment diagram in which we only present the nodes and their inter-relationships, and complete the picture by including the components and the applications that run in the nodes.

Connecting the Nodes

Very early in the system life time - deployment diagrams are used to show the nodes (computers, virtual machines) and the external devices (if there are any) which construct the system. A ‘node’ usually refers to a computer which can be stereotyped as server, client, workstation etc. A ‘device’ is a subclass of ‘node’ which refers to a resource with processing capability such as camera, printer, measurement instrument etc. The nodes and the devices are usually wired though the ‘Communication Path’ connector which illustrates the exchange of signals and messages between both ends.

 

Notice that the client node is stereotyped as ‘pc-client’ (indicated by the icon) and the server node is stereotyped as ‘pc-server’.

The following diagram shows the deployment architecture of a scalable, fault tolerant ‘Camera control and image processing’ system . The system consist of N servers, load balancer with redundancy, and several clients.

The client machines present live state of all the cameras available in the system, and allow the user to control the cameras and initiate all kind of activities on the servers. The load balancer process the inputs that it receives from the clients and send the appropriate instructions to the appropriate server, it is designed to gracefully scale to increasing number of servers. Since the load balancer is a single point of failure, a passive load balancer (that maintains copy of the active load balancer state) run in the background, ready to replace the active load balancer in case of a crush.  All the servers run the same application, they support different kinds of cameras and can be configured to manage up to 200 cameras of different kinds.

Including the Components

In the next stage we are ready to put in the components that run in the physical nodes. As indicated in the previous post, when using components to model the physical architecture of a system (as in this case) the term ‘component’ refers to dll, or some executable.

The following figure shows snapshot of the above diagram with the addition of the components that reside in the nodes. 

As you can see the client node includes the ‘CamerasC2C.Client’ component which uses infrastructure level controls reside within ‘Company.Contorls’ which includes classes which derive from framework level controls (notice the use of stereotypes to divide the components to levels/layers).  The ‘CamerasC2C.Client’ component communicate with the load balancer ‘CamerasC2C.LoadBalance’ component, which transfer instructions to the appropriate server through the ‘IServer’ interface. The server consist of 3rd party components that were shipped with the cameras hardware, each component exposes interface though which the camera can be controlled, the ‘CamerasC2C.Server.Cameras’ component includes adapter classes which wrap the 3rd party interfaces and expose matching interfaces that fit to the systems requirements and speak the system language (uses system level classes etc), the ‘CamerasC2C.Server.Core’ component uses the interfaces exposed by the ‘CamerasC2C.Server.Cameras’ in order to command the cameras as appropriate.

Presenting the Applications

In order to show the applications that run on the different nodes and the components that make up the applications – we use artifact wired to nodes through the ‘deploy’ connector, and wired to components through the ‘manifest’ connecter.

 

Presenting External Applications

In order to show the way in which the system interact with external applications - artifacts can be used to represent the external application as illustrated in the following diagrams.

The ‘CamerasC2C.Server.Cameras’ component encapsulates the communication with external application called ‘BMC Camera Control Application’ which reside within the server ‘BLC Machine’.

UML 2.0 Component Diagrams – Modeling the System Logical Architecture

In UML 2.0 Component diagrams are used to model the logical architecture of a system by showing the system high level components and their inter-relationships. In the next post I will show how components are used in deployment diagrams to model the physical architecture of a system. 

A component is an encapsulated unit within a system which provide one or more interfaces. When using components to model the logical architecture (solely in component diagrams) of a system the term ‘component’ refers to collection of classes which can be reused and replaced as a whole, when a single logical component can scattered around multiple physical nodes. When using components to model the physical architecture of a system (usually in deployment diagrams, but some people that are still custom to UML 1.x still use it in component diagrams) the term ‘component’ refers to dll, or some executable.

Simple Wiring

Abstract Connector

The most simple and abstract way to illustrated relationships between components is by using the dependency connector which can refer to wide range of dependent relationships like realization and usage

By wiring two components with the dependency connector we state that some of the classes/interfaces in component2 are being required/realized/implemented by classes/interfaces from component1.

Generalization Connector

To show that some classes in component1 derive from classes in component2 we use the ‘generalization’ connector.

 

Overall Look

Lets see how component diagram with simple wiring can be used to model a simple orders management application which includes UI editors, repository, and web service.

Notice that stereotypes are being be used to divide the components to layers in order to distinguish between application components (views, controllers, presenters), domain components (business logic, data access layer) and infrastructure components.

The ‘Orders Management’ and ‘Admin’ components include application level classes such as UI editors and presentation logic classes, which derive from framework level classes that reside within ‘System.Windows.Forms’ (Control, Component, UserControl, Form etc). The ‘Orders’ component includes domain level classes such as repository which uses web-service classes from ‘WebServices.Orders’ component . Classes from both ‘Admin’ and ‘Orders’ components use the infrastructure level ‘Login’ component in order or login to the system.

Interfaces Wiring

In order to be more specific regarding to the relationships between the components - we show the interfaces that the components expose and require, and the way in which they are wired together.

Socket Connector

The socket connector which is new to UML 2.0 shows that a component requires a specific interface. The figure bellow shows that the component ‘Orders Management’ requires ‘Orders Repository’ interface.

Lollipop Connector

The lollipop connector shows that a component exposes a specific interface.

Wiring the Connectors - Realization

The connectors can be wired together to show that one (or more) of the classes/interfaces of a component realizes an interface exposed by other component. In this case the ‘Orders’ component contains a class that realizes the ‘IOrdersWebService’ interface exposed  by the ‘WebServices.Orders’ component.

 

Wiring the Connectors – Usage

In other cases the connectors can be wired together to show that one component requires an interface which the other component exposes. In this case the ‘Orders Management’ component requires the ‘Order Repository’ interface of the ‘Orders’ component.

 

UML 2.0 introduces the assembly connector that shows the exact same thing.

Overall Look

The following figure shows how the same architecture from the ‘simple wiring’ section can be modeled in more details by pointing out the interfaces that the components expose and require.

Now we can see that the ‘Orders’ component realizes the ‘IOrdersWebService’ interface and uses some of the classes of ‘WebServices.Orders’ component.

The ‘Orders’ and the ‘WebServices.Orders’ components execute on different nodes. The ‘Orders’ component (client) contains a proxy class which realizes the ‘IOrdersWebService’ interface. The ‘WebServices.Orders’ component (server) contains a web service class which also implements the ‘IOrdersWebService’ interface. The proxy initiate remote calls on the web service object through the ‘IOrdersWebService’ interface.

The ‘Login’ component exposes the ‘ILoginManager’ interface through which the ‘Orders Management’ and the ‘Admin’ components login to the system.

Both ‘Login’ and ‘Admin’ components contain proxy object that initiate remote calls on the the web service object that resides within ‘WebServices.Users’ through the ‘IUsersWebService’ interface.

Links

http://www.ibm.com/developerworks/rational/library/dec04/bell/