IBM
Contents Index Previous Next



System Design Overview


One of the most important issues of software development, if not the most important of all, is to define the architecture of the system. Define how the system is built up of smaller parts that in turn may be composed of even smaller parts until each part is manageable by itself. The architecture is proposed in the system analysis architecture but the precise definition of this structure is the major task of the system design activity.

The components of a system may have several different important functions to fulfill:

The major inputs to the system design activity are the analysis object model and the analysis use case model produced in the system analysis activity. The system design is the process that based on these inputs define in detail how the system is decomposed into components and to define the interfaces between the different parts. This is illustrated in Figure 655 that also shows the three major artifacts developed in the system design; the design module structure, the architecture definition and the design use case model. In addition to these formalized descriptions there is often a need to specify non-functional aspects of the components in a textual design documentation.

Figure 655 : Inputs and outputs of the System Design activity

The architecture is in the system design formalized primarily using SDL. In SDL the major structuring concept is the block and the notation is the block diagram. Seen from an object-oriented point of view a block is a container of objects. The block can either be directly described by the objects that it contains or it is decomposed into lower level blocks. The block structuring mechanism is discussed more in Architecture Definition.

Where the logical architecture defines the decomposition of logical functionality the design module structure defines the decomposition into work items. It defines the different modules the design teams can start working on and also provides a mapping from the logical architecture to design modules. In SDL the design modules are usually SDL packages. The design module structure also takes a slightly broader perspective of the system to be built and describes how existing frameworks, tools and components are incorporated into the development structure.

The deployment description is a way to describe the physical distribution structure of the SDL system. It is also the place where the implementation strategy for different parts of the system can be described.

There should be a simple (if possible one-to-one) mapping between the top levels of the architecture definition and some of the modules in the design module structure. The benefit gained from a simple mapping is that the design modules define the possibilities to divide the work on different development teams and the logical blocks comprise well-defined sets of functionality and responsibilities. If they do not map to each other there is an obvious risk for complex interfaces between the development teams.

As always when a system is decomposed into smaller parts one very important issue is how the interface between the parts are defined. In particular if the components are used as division of work load and designed by different development teams the interface definition is the means to communicate between the different groups and a common understanding of the interface is crucial. There are two aspects of the interface:

Both aspects are important and the definition of them is a vital part of the system design activity.

In SOMT the major concepts used to define the static interface are the SDL concepts signals and remote procedures, and the dynamic aspect is a continued usage of use cases. However, since there very often is a need to design parts of a system using other techniques than SDL or to use existing modules, other interface definitions techniques are also used in SOMT.

The major tasks to be performed in system design in an SDL based project can thus essentially be summarized as the following:

  1. Create an (incomplete) SDL system that is a starting point for the formalization of the architecture of the application. This is further discussed in Architecture Definition.
  2. Define the design module structure. Draw a diagram that illustrates the structure and create the necessary packages etc. as described in Design Module Structure.
  3. Define the physical distribution strategy for the SDL system, see Deployment Description.
  4. Define the static interfaces as discussed further in Static Interface Definitions Using SDL.
  5. Define the dynamic aspects of the interfaces by a continued use of use cases. See section Design Use Case Model.

There is, as we will see in "Object Design" on page 3913, a close relation between the system design activity and the object design activity in the sense that the object design activity is concerned with the representation and behavior of the objects and the system design deals with the distribution of the objects into blocks and defining the communication paths between the objects.

The rest of this chapter will discuss the system design activity. SDL will frequently be used to define the architecture and interfaces and examples of SDL diagrams will be used throughout the chapter. A complete presentation of the SDL language is however outside the scope of this document. For more information, please consult either the Z.100 standard itself [24], or a text book about SDL like [28].


http://www.ibm.com/rational
Contents Index Previous Next