Structural Design

What

A detailed design of the modules to be implemented

How

The Dish A detailed desig of each module to be implemented.

Ingredients

Use artefacts from

• Timebox Analysis
• Requirements
• Verification

Process

As for the process in Structural Analysis a module is a collection of related methods with accompanying attributes. If the programming language is object oriented these modules are classes. The instructions below if written with OO in mind, but can without problems be used in non-OO programming languages.

To gain insight in the system-to-be, you should first consider which views are necessary to describe the system.

• From the Subsystem Architecture Design we have a first impression of the subsystems. Consider carefully if more details are needed or some redesign needs to be performed.
• If the system-to-be is a distributed system using two or more processors to complete the system, it is necessary to draw a Deployment View which shows on which processors which objects (instances of classes or modules) should run. Also include necessary external resources such as displays, printers, sensors etc. to clarify the understanding of the system.
• If the system-to-be should have several tasks or threads, draw a Concurrency View with the active objects (and other relevant objects), which shows the tasks or threads. If any resources (like queues, semaphores etc.) are needed, include them in the view.
• If the system-to-be should operate in a safety-critical environment or in other ways should provide high reliability, draw a Reliability View. Focus on how the safety or reliability should be gained (watchdogs, comparators etc.).

Events

After having gained insight at system level, each class should be designed for implementation. Focus especially on the classes in the Problem Domain. Inspect the State Machine Diagram for each class. Identify private events and common events. Private events are events that only involve one object from the problem domain. Common events consequently involve two or more objects.

Since we have included the events in the state machine diagram, the events are important for the system and therefore we need to record necessary information carried with the event. Information can be as simple as a counter that should be incremented, a timestamp that records the time of the event or as complex as personal information about a person that should be recorded in the object. Do not record information that is never used unless a future improvement may require the information. The recorded information should enable the functionality of the system - no more.

Private Events can occur only once or several times. For single occurrence events, it is easy to represent the information in an attribute in the class. For multiple occurrence events a redesign is needed. It is necessary to add an extra class aggregated to the class in question - a so-called transaction class. For each time the event occurs a new object of the transaction class is generated and the information carried with the event is stored in the transaction object.

For common events, i.e. events that involve several objects, the representation of the event should be represented in the object that gives the simplest representation of the event. Thereafter, structures should be added between the objects (i.e. classes) to allow the other objects involved in the event to obtain the information carried with the event.

Generalise classes

After having focused on events, it is time to take a closer look at the class diagram. Consider for each class if it - in cooperation with others - can be generalised. Inspect the classes and consider if they can be generalised for instance by looking at the attributes. Can data kept in the attributes, which may have a slight difference, be generalised thereby enabling a generalisation structure? Are two or more classes practically similar? If so generalise the classes.

Inspect associations

Inspect the associations in the class diagram, especially the associations between classes where transaction classes have been introduced. Does the addition of the transaction class make the association superfluous? If so consider to remove the association.

Why

After having analysed the classes, it is time to design them. In the design phase focus is turned to how the classes should be implemented in the system-to-be in contrast to the analysis phase where the focus was on what the class should implement.

It is convenient to leave the Analysis Class Diagram and draw a new design diagram (or often the UML-tools enable you to import/copy classes from the architecture diagrams into new design diagrams). During the design phase some radical change may take place in the diagrams.

We use different views to understand the contents of the model and as a means to review the model.

Classes and objects are little things. It takes collaboration of many of them to compose a system with the expected behaviour. Because of most systems' complexity it is hard to develop systems without thinking in systemwide structures - the different views. But first some modelling concepts should be defined:

Components

Think of components as replaceable building blocks with a well-known interface and behaviour. Often, components can be bought as libraries to include into own systems, e.g. TCP/IP stacks, graphical libraries, databases, etc. Naturally, components can be home-brewed. Typically, the component is instantiatable and therefore consumes memory, CPU cycles, etc.

Packages

Packages are model elements of arbitrary type that, put together, structure the entire model into smaller, clearly visible units. In this context we compose the packages using the classes from the system. Packages are used to gain overview of the often complex system as represented in the class diagram. Packages are not instantiatable, but they add a namespace. Packages are normally the basic configuration item for configuration management tools.

Subsystems

Components, packages and classes can be composed - with other elements - into a Subsystem View. A subsystem is characterised by having a well-defined interface and that it hides its insides like structure and collaboration between internal parts. The purpose of subsystems is domain-specific system partitioning on a relatively coarse level.

Systems

The System represents the entire system under development. In certain circumstances more systems may be modelled, e.g. if the system-to-be consists of two or more completely individual systems that collaborate loosely and that are developed by separate groups of developers a total overview diagram may contain the different systems as individual ones. Typically, though, System is only represented once.

Views

In order to understand the system-to-be fully, several views may be drawn. The views represent different aspects of the same class diagram. Aspects can be subsystems view, process distribution, deployment view, etc. The goal for each view is to give the developer a deeper insight into the system. Please note: it is the class diagram that is filtered with respect to the wanted aspect. For instance, a process distribution view might show active objects and their distribution on the processors which the system-to-be consists of.

Having designed the classes in details Use Case Scenarios can be the next step.