Contents

Abstract

This document is intended to summerize all guidelines which are relevent for a small component design process. The result of this process is input for the impelementation of a component (see implementation guidelines).

Introduction

The basic feature of a component is the reusability. This means the component may be build within the context of a project but normaly it is not known in advance, that the component will be reused later, unless the reusabilitiy iwas within the scope of the desgin (i.e. library functions). Due to the fact that during desgin it is not known, that there will be a need for reuse in the future certain rules should be followed in order to make reuse of the component more likely.

Design Objectives

The major objective of component design is to maximize the chance of reusing a piece of software. The term reuse means that the software piece may be used in a different system context without modification.

Note:

Changing the software component is excluded, because this means additionaly to the costs for understanding the function of the component the cost of understanding the implementation will arrise. These costs are quite high and will cause followon costs for testing, production and maintenanceas well.

Key Elements for Reuse

The whole issue is around pieces of software (i.e Ada packages, Libraries, Classes etc.). To ensure that such an software part has a good chance to be reused later, it has to be in some sense simple to use and well documented. Teh meaning of both terms needs to be clarified more detailed.

Making Components simple to use

Simple is used in the sense that the component behaives according to simple rules. The general defintion may be translated to the following criteria:

• The software part has a limited number of clearly defined states.
• State transitions are triggerd by methods from outside of the component.
• The number of states transitions triggered by one method should be as small as possible.
• The part hides the implementation of its internal data, by providing only a limited number of attributes to the outside. The attributes are set by means of set and query methods.
• Every part provides a minimal set of methods.
• Paramters are reduced to the minimum.
• The componet design follows some common known pattern.

The application developer which is has to reuse the component needs a simple model about the dynamic behaiviour of a component. Using states has been proven to be a powerfull tool for modelling. Everbody knowns i.e. the file model where a file is either in the state open or close. This model is reused for several resource like objects. Beside of using states it is usefull to define the states of a component following well known design patterns.

State transitions in general have to be associated with methods. There is an exception from this rule due toi the fact that a part may handle external signals and timers. In such an the component state changes without having the client to invoke any method.

The number of parameters per methods have to be limited, otherwise the behaiviour gets to compilcated.

Making Components well documented

Using states and state transitions simplifies the documentation of a software part as well, because the documentation can follow a standart pattern which looks like this:

• Introduction
• Definition of attributes
• Definition of states
• Description of methods
• Statetransition table
• Notes

Design Process

Within this section, a process will be described which yields software components meeting the criteria above. This process will be supported by the ACDE.

Every design process can be brocken up into the following phases. Each phase has defined input and output documents and is subject to planing.

• Requirement Analyis
  During this phase the requirements for the design are derived and put into a reviewable form, i.e. documents, pictures, use cases etc.
  
• Top Level Design (TLD)
  The result of the requirement analysis is input for this phase. Result of this phase is a archticture of the system, which mean in most cases a spcification of components within the system and there interface specifications.
  
• Detailed Design of the subcomponents
  This phase takes the results of the TLD an produces specifications of the system components by focussing on internal implementation issues. Normaly the interface specification from the TLD phase will be revised. Output of this phase is the detailed specification of the components of a larger system
  
• Implementation
  Based on the output of the detailed design, implementation of the software parts is done.
  
• Testing

For each step of the design process the topics important for component design will be explained in the following chapters.

Requirement Analysis

In general the the requirement analysis tries to identify objects which are subject of a software implementation. For these objects the requirements are translated into interface specifications covering the interface to the customer.

In the context of component desgin the requirements are normaly defined by an overlaying design projects. In such a case the requirement specificiation is produces by the overlaying project.

As a result of the requirement analysis, the followig information has to be available:

• A description of the object where the components is focused on. This normaly implies a list of data attributes.
• List of methods and the definition dynmical behaviour.
• Possible use cases of the component.

Top Level Design

During TLD the requirements are translated into an implementation architecture. The implementation architecture is specified by a list of functional entities and the internal an outside interfaces

In the context of the component desgin, theas mean the interfaces and the data has to be specified.

After this has been completed a profing step has to be performed. The intention of this step is to verfify that the specification is realy a component, or i.e. contains other components. In such an case the requirement analysis has to be done again.

• Basic presentation issues, i.e. Datatyes for attributes
• General behaiviour
• Defintion of Object States

This Information will be stored in the component header.

Detailed Design

After the function of the component has been fixed the implementation is prepared. The input for this phase is the output of the TLD step. The output of the detailed design are the following items:

• Description of selected Algorithms (documented in the component header)
• Precedure Tree (documented in the component header)
• Headers for all procedures/functions within the procedure

Implementation

Based upon the coding guidelines for components, the implementation of the component is done. Input for this step is the output of the detailed design.

References

Main Index Contents