Guidelines for the Component Design Process


updated: 18.09.99

Status: Work in Progress


  • Introduction
  • Design Objectives
  • Key Elements for Reuse
  • Making components simple to use
  • Making components well documented
  • Design Process
  • Requirement Analysis (RA)
  • Toplevel Design (TLD)
  • Detailed Design (DD)
  • Implementation
  • References
  • 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).


    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.


    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 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:

    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.

    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:

    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.

    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:


    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.


    Main Index Contents