UML Use Case Diagrams – Modeling the System Functionality

UML Use case diagrams are used to illustrate the behavior of the system during requirements analysis, they show system wide use cases and point out which use case is performed for which actor.

A use case describes a sequence of actions that make up one or more business process and provide something of measurable value to an actor, an actor is a person, organization, or external system that plays a role in one or more interactions with your system.

In this post we’ll take a step by step tour through constructing a use case diagram and writing a use case.

Constructing a Use Case Diagram

Just after the system engineers are done translating the customer requests into system requirements - they start designing the business processes that will implement the requirements while taking advantage of the use-case diagram in order to describe the various business processes from the standing point of the user.

The figure bellow shows a use case diagram which present the processes involved in an ‘automatic threats detection’ system which periodically processes images coming from a surveillance video camera and uses an external threats evaluation system in order to detect threats approaching towards a secured area.

As you can see the diagram consist of 5 use cases that describe the 1) system initialization process which can be initiated by a simple user or by an operator user, 2) the login process which can be initiated only by an operator user, 3) the image processing process which is driven by a video stream coming from the surveillance camera, 4) the threat evaluation process which is part of the image processing process and uses a sub-system which is referred to as ‘threat evaluation system’, 5) the threats distribution process which is enabled only under some conditions.  

The Relationships

The ‘User’ actor is associated with the ‘Initiate System’ use case which implies that the there’s a business process that describes what happened during system initialization, and that the ‘User’ is one of the actors that can trigger it.

The ‘Evaluate Threat’ use case is associated with the ‘Threat Evaluation System’ actor which implies that during the threat evaluation process the ‘Threat Evaluation System’ is called into action. 

The generalization relationship between the ‘User’ and the ‘Operator’ actors implies that all the use cases associated with the ‘User’ (parent) actor are inherently associated with the ‘Operator’ (child) actor.

The ‘Login’ use case depend on the ‘Initiate System’ use case which means that the operator is not allowed to initiate the login process if the system wasn’t initialized before. The same goes for the ‘Process Camera Image’ use case that doesn’t start until the system in fully initialized.

The ‘Process Camera Image’ use case includes the ‘Evaluate Threat’ use case which implies that the behavior of the ‘Evaluate Threat’ use case is inserted into the behavior of the ‘Process Camera Image’ use case, or in other words, “The act of processing camera image includes a sub process of evaluating the image for threats”.

We often use the ‘Include’ association to extract common behaviors from multiple use cases into a single description, but it’s also common to use the ‘Include’ association to divide a use case (container) into several smaller use cases (parts).

The ‘Distribute Threats Information’ use case extends the ‘Evaluate Threat’ use case which implies that the behavior of the ‘Distribute Threats Information’ use case may be inserted in the ‘Evaluate Threat’ use case under some conditions, or in other words, “In case the distribution feature is enabled, the threats evaluation process is extended with the distribution of the detected threats”.

Writing a Use Case

After drawing an overall view of the system use-cases - we switch from the UML tool to our favorite document editor and start describing the use cases one by one. We’ll usually use a template that consist of several core sections that the engineering team agreed upon. The template that I use consists of the sections brought to you in the following description.

The ‘Per Conditions’ sections defines the conditions that must be met in order for the use case to execute. The ‘Triggers’ section defines one or more actions that can trigger the use case. The ‘Main Success Scenario’ sections describes the actions that make up the use case – one can be brief and provide few sentences summarizing the actions and one can provide in detail review of each action, include alternative paths etc. The ‘Post Conditions’ section describes what the change in state of the system will be after the use case completes.

Links

PPT - Use Case Diagrams

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’.