IBM
Contents Index Previous Next



Design Module Structure


The purpose of the design module structure is to show the actual components the application will be built from. The module structure should depict the actual source code modules etc. that the application will contain. A number of different aspects must be taken into account when defining the module structure:

Especially the reuse of existing architectural frameworks is very common and very beneficial. Most applications are not built from scratch, they are rather extensions/modifications of old applications and the design module structure is the place to show how this is done.

One notation that can be used in SOMT to describe the design module structure is object model instance diagrams, where the instances represent the different modules. Where relevant, the attribute field can be used to show what components of the logical architecture are contained in the modules. As an example consider a typical SDL application running on a small microprocessor where a proprietary real-time operating system is used. A possible module structure is shown in Figure 657.

Figure 657 : The module structure of the Access Control system using
an in-house real time operating system

In this example the top-level of the application is described in the SDL system AccessAppl which is defined using the types defined in the packages BasicOperation and OperatorMan, both of which uses common types defined in the UtilityTypes package. The application will run on the already existing real time operating system MyRTOS. To make the C code generated from the SDL system run on MyRTOS a C code module Adaptation is used that defines the necessary interfaces.

In this example it is very likely that some of the modules will be developed within the project (the AccessAppl and the modules it uses) while others are already existing (like the real time operating system) and some can be taken from previous projects and be modified to fit the current project (like the Adaptation module).

The most important aspect of the module structure is that it forms the basis for dividing the work load on different development teams. This is in many cases the major reason to decompose the system into design modules. However, another reason may be the issue of reuse.

The design for reuse can in this context be viewed as an activity that defines the design module structure based on other premises than the architecture as discussed so far in this chapter. Consider for example the access control system decomposed as in Figure 656, where the system is divided into three different parts according to essentially the physical distribution that is needed in the application. There may in this example exist concepts that can be used in more than one of the subsystems. Examples may include knowledge about some passive data structure, like the concept of a card, but also entire functionalities like the concept of time seen as a clock functionality.

The identification of these type of components is also a task of the system design. It is particularly important if the different subsystems are to be designed by different design teams. It is also important to identify common components to avoid duplicate work and lower the complexity of the individual subsystems.

The concept that is used to describe the different modules is the package. A package is essentially a container of SDL types, this may range from system types and block types over process types down to signals and data types. When a package is used by an SDL system the types defined in the package can be referenced from within the SDL system. For example, in the access control system we may decide that we need a package UtilityTypes (as in Figure 657) that defines the common data types needed in the different subsystems.

Another issue that needs to be handled in the system design is to analyze the consequences of the requirements on different configurations of the system. Are there any optional parts or functionality? In many cases the optional parts are captured by different modules in the system structure, but sometimes, like if there would be an optional requirements on a synchronized clock in all parts of the access control system, it is distributed over the different blocks in the system. If this is the case a package is the most useful concept to use to encapsulate the optional feature.

The discussion so far has been about reuse within one development project focused on one specific application. There is however also the issue of reuse outside the local project. When using an object-oriented approach to the analysis and design the objects tend to be fairly general and applicable in more than one project. If the objects in a particular part of the system are defined as types in a package this will form a good foundation for reusing the objects in future projects. This implies that there may be a reason to use a package structure that is different from the block structure of the system. The package structure reflects the decomposition into packages as defined by the possibility for reuse while the block structure defines the current system structure.


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