System Design Tools And Methods

Systems Design: Techniques for Designing Software Structure

Principal Architect, Payments Canada September 1, 2011

Structure Charts
The Structure Chart is a basic tool of Structured System Design. It is a graphic representation of a hierarchy of modules and the relationships between them. In Section 2 two types of Structure Charts were discussed; they were referred to as Structure Charts and Program Structure Charts. The first type represents the detailed functional breakdown of the software without taking packaging into account. The second type illustrates the actual programs and procedures to be developed.

A Structure Chart represents system structure. It can also be used to illustrate
flow of information between modules. It does not illustrate flow of control; it does
not provide any information about sequencing of events or about condition tests.

Program Structure Chart

The figure above provides an example of a Program Structure Chart. It illustrates the different symbols which can be used. A box represents a module; lines connecting the modules represent the calling hierarchy. Loops, conditional calls and parameters can also be illustrated on the Structure Charts using the symbols shown. Illustrated parameter passing can become messy and cumbersome; it may be preferable to describe the parameter passing in the Project Encyclopaedia.

Data Flow Oriented Design
Data flow oriented decomposition is a method of deriving the modular design based on the data flow diagram. It is the recommended method for processing oriented applications such as Accounting, Payroll and Inventory.

The procedure is as follows.
1. Define the top level module.
DFOD-step 1

2. Identify the major input streams, output streams, and the processing center. The processing center can often be identified by parallelism of data flow (see Figure below where transactions A, B, C are processed in parallel).

DFOD-step 2
3. Define a module for each input or output stream and the processing center. For the processing center, define a sub-module for each of the processes occurring in parallel.

DFOD-step 3
4. For each of the lowest level modules, take the corresponding portion of the DFD and repeat Step 2 and 3 until fully decomposed.
5. Refine the design to decrease the coupling and increase the cohesion of the modules. This is necessary because DFD's do not take into account control flow, trivial data paths or packaging considerations.

DFOD-step 5
For more information about this technique refer to Structured Systems Analysis: Tools and Techniques by Gane and Sarson.

Data Structure Oriented Design
Data Structure Oriented Design is a technique of modular decomposition which transforms a representation of a data structure into a representation of software.

This method can be used for systems with a well defined, hierarchical structure of information, heavy input/output flow and little processing logic; e.g., a library catalogue system.

Because this approach is not widely used it is not discussed here. The reader may refer to Data Structured Program Design by Kirk Hansen.

Object-Oriented Design
Object-Oriented Design is an approach to modular decomposition which views a problem in terms of objects and operations and defines the solution in the same terms. It is applicable to applications such as simulation systems, real time systems, and to systems with complex or dynamic entities which are difficult to represent using traditional techniques.

This approach requires a language in which real world objects can be represented. These languages typically build classes of an object in the application.

For each class, the attributes and properties that each object in the class shares are defined. The actions which each object can perform are described. These are written in the form of messages to which each object in the class can respond. As a result, all communication between any two objects, whether they are from the same class or not, is performed by sending messages. Thus, object-oriented languages have a very high degree of encapsulation, in that each object is responsible for its own operation, and no other object may access its structure directly. The net result is that each message is like a separate black-box, a property which makes system design more manageable.

New classes are introduced as specializations or generalizations of existing classes. For example, in a naval simulation system, a class SHIP could be introduced, and the attributes and properties of a ship defined. Specializations of this class, such as FRIGATE and DESTROYER, could then be introduced. These two new classes could inherit the properties of the class SHIP, while defining those properties which makes them unique.

Many object-oriented languages are now becoming available, such as SMALLTALK, LISP FLAVERS, Objective C, C++, ADA, and SIMULA.

The following is an example of a temperature monitoring system which will be used to illustrate Object Oriented Design. The system is described as follows:
'There are ten independent sensors which continually monitor temperature. Initially all of the sensors are disabled. If any of the enabled sensors register an out of limits value the system must immediately post an alarm condition. It must also record the status of all sensors every fifteen minutes. Asynchronously it must be able to get a user command to enable or disable a sensor, or set the temperature limits."

• Identify the objects and their attributes.

•    Alarm: Is set for out of limits condition.
•    Sensors: Each one
     –    is enabled or disabled,
     –    has upper and lower limits,
     –    is polled only when enabled.
•    Recording Device: The status of the sensors are logged.
•    Timer: Supplies an interrupt every 15 minutes.
•    User Commands: One of Enable, Disable, or Set Limits.

• Identify the operations applicable to each object.

•    Alarm
     –    Post out of limits condition
•    Sensors
     –    Disable
     –    Enable
     –    Set Limits
•    Recording Device
     –    Log the status of sensors
•    Timer
     –    Interrupt

• Define the solution.

This example was adapted from Software Engineering with Ada by Grady Booch.