Design Using UML

Design using UML

This is a short description of a design process where UML is used for representing the design. The process is exemplified by parts of a design for a handheld device, the SMSme (“esemesme”), with network capability.

The design process consists of the following phases:

Analysis: Identifies the problem to solve. The system functionality is modelled.

Design: A single solution to the problem.

Implementation/Translation: The hardware and software is generated.

Test: The resulting hardware and software is tested.

We will not have much to say about the last two steps in the process. They are mostly outside the scope of UML, using the UML models only as references and for verification.

The description follows the design process described in [Douglass 1999] and assumes a basic knowledge on the diagrams available in UML.

1.Analysis

1.1 Requirement analysis

The aim for this subphase is to capture the requirements for the design. The main tools and representations for doing this are use cases, scenarios, statecharts, constraints

Problem formulation:

The problem fomulation is a help to understand why you should design the system. A mobile phone is a complicated piece of equipment, expensive and difficult to use.

In this example we want to introduce a new type of device, much simpler to use than the mobile phone, a device where small messages can only be received, displayed and acknowledged.

Requirement specification:

SMSme is a wireless device where messages can be displayed. The colour of the device could be red or gold. When a message arrives the user is notified either by a sound or by a vibration. The last message sent or received is always displayed. A constraint is that the display is limited to 4 lines, 20 characters per line.

A number of ten messages can be stored and if this limit is reached the device will show a warning message on the display. Each device can be given a unique name. This name will be sent back when a message is acknowledged. The user communicates with SMSme using buttons.

Use case diagram:

We begin our excursion through the UML diagrams by using use cases to document who is doing what with the system, as seen from a user of the system. Ask yourself who the users of the systems are (actors), what they want to do with the system and what the system wants to do to the actors (use cases).

The use cases should also be documented in text.

A statechart helps understanding a use case. The statechart below exemplifies this by showing how repeated incoming messages are handled by executing the ReceiveMessage operation.

Scenario:

A scenario is an example of a use case in action. Two examples are given below.

“Reading a message”: SMSme makes a discrete sound and Kalle looks at the screen. It is Lisa who wants to join him for lunch. Kalle reads the message and acknowledges it by pressing “>” at the same time as he press “+”. He then deletes the message using the “-“ button.

“Naming the device”: Kalle. Wants to rename his SMSme. He starts the naming procedure by simultaneously pressing “+” and “-“. A set of characters appear on the screen and by using “<”, “>” and “+” Kalle selects a name. He quits the procedure by once again pressing “+” and “-“.

A sequence diagram is useful for describing a scenario in UML. The example show here is the “Reading a message” scenario.

1.1Systems analysis

The aim for systems analysis is to identify the main hardware and software subsystems. We use a UML deployment diagram to describe the hardware structure of the system using nodes and connections among them. We can add software elements of the system .

We might also skip the hardware nodes and use component diagrams or package diagrams to show only the structure of the software. A package is a logical grouping of elements while a component is strictly software units (files for source code, executable libraries,..).

1.2 Object analysis

At this stage an object-oriented analysis can be done (CRC cards, domain analysis, linguistic analysis…) to identify the essential classes and objects and their properties, i.e. the static structure of the system. The objects found are not necessarily the same objects that will be used for implementation after design. We are still trying to describe the problem to be solved.

A possible initial partial class diagram from this description is:

Each class diagram should be complemented by a class description as the table below (not all classes in the diagram above are described).

The class diagram shows only the static aspects of the problem. To stress dynamic behaviour a statechart, sequence diagram or collaboration diagram are used.

2. Design

In the design phase we design a solution matching the analysis. The result is one particular solution and details are added to the solution, as it is refined by stepwise procrastination.

The major representation for design is the class diagram and we refine the class diagram from the analysis by adding some more classes and operations. The class diagram should of course be accompanied by a description for each class (not shown here).

As for analysis statechart, sequence diagram or collaboration diagram can be used to describe dynamic aspects of the design. The state diagram below shows part of the dynamic behaviour of the SMSmeControl object.

Collaboration diagrams and sequence diagrams also do a good job of modelling the interaction between the objects. The example below describes the “Reading a message” scenario as a collaboration diagram. Note how methods in the receiving object are executed.

An activity diagram is preferably used for describing parallel actions. In the design one example is when a message is acknowledged. The diagram below shows a subsection of the behaviour of the SMSmeControl object.

3. References

[Douglass 1999] Bruce Powel Douglass, “Doing hard time, Developing Real-Time Systems with UML, Objects, Frameworks and Patterns”, Addison Wesley 1999, ISBN 0-201-49837-5