Previous Next V-Model Official Homepage by IABG  
Part 3: Collection of Manuals Homepage  
OO  Homepage  

  OOS - Berücksichtigung objektorientierter Sprachen

Contents  
  • OOL.1 Overview
  • OOL.2 Effects of Object-Oriented Procedures
  • OOL.3 Using Ada 95
  • OOL.4 Using C++
  • OOL.5 Using other Object-Oriented or Object-Based Languages
  • OOL.1 Overview

    After comprehensively reviewing the effects of using object-oriented languages in the V-Model, the languages Ada 95 and C++(1) are paid particular consideration. It is illustrated how the job and support features of the V-Model are to be applied when using object-oriented languages. Special attention is given to the explanation of how the product structure of the V-Model can be applied as structuring help for object-oriented system and software design.

    OOL.2 Effects of Object-Oriented Procedures

    OOL.2.1 Basic Approach of the V-Model

    Principles allowing object-oriented procedures have already been explained in part 1 of the V-Model.(2) The elementary methods used in this connection are not dependent on languages, therefore they can be applied in connection with each of the languages handled in the following.

    When the V-Model is applied, both method concepts and the syntactic structuring means of the individual languages are oriented to the product structure as a structural frame. The allocation of methods to this frame is documented in the method allocation.

    Basically, the elements of the product structure are a structural and administration help for the system elements. Thus they are universally apt to be used in a way that is independent of the language.

    The V-Model regulations-and in particular the product structure-do not depend on the method and programming language used.

    OOL.2.2 Rules and Criteria for the Practical Realization

    Elements of the product structure relevant with regard to the use of a programming language are SW Units, SW Components, and SW Modules. Irrespective of the language used there must never be a direct connection from the syntax elements to the product structure, as set down as a standard by the V-Model (e. g. "each class is a SW Module").

    A rigid, schema-like allocation of product structure elements to visible means of a programming language is not possible. Essential factors during the allocation are the degree of the complexity of the system, and the degree of abstraction of the structuring level.

    Therefore, the result of the allocation will be a scale with overlapping allocations of V-Model structures to structures of the programming language.

    SW Unit

    The V-Model does not demand the structuring of SW Units. Therefore, it is not possible to ask for a "correct structure according to the V-Model". With regard to the V-Model, every structure is correct. It is a matter of the design task to find the most suitable architecture under the given design aspects and marginal conditions.

    The SW Unit is a structuring means to describe the architecture decisions in the V-Model. In this connection, organizational aspects are as important as aspects with regard to software engineering. It is possible, for example, to combine software parts allocated to a team into a SW Unit. The integration strategy as well (and thus the Assessment Plan) may offer arguments for the structuring of systems or segments into SW Units.

    It is not required that a SW Unit is loadable like an independent program or process. A SW Unit will in any case be administrated by the CM as an independent unit. (CM may also administer smaller units.)

    Structuring a user system into three SW Units (or levels) may, for example, be practical:

    1. 1. presentation level (Windows interface, GUI, handling of user interrupts, etc.),
    2. 2. user level (mostly SW parts based on special requests),
    3. 3. data level (files, access routines, data storage, etc.).

    SW Module

    SW Modules are identified by the conversion of typical modularization criteria like independence, small interfaces between modules, and close internal connection between functions. From outside, SW Modules are seen as isolated units that can be tested and maintained. Good module design is also recognized by good abstraction levels: to the outside, a software module offers a consistent, user-friendly interface that can be easily maintained; this interface is not dependent on the internal module structure.

    A typical SW Module is a module used to calculate tax surcharges. Its data are protected according to the currently valid tax rates. Its algorithms isolate the legally protected calculation procedures, including the rounding rules.

    SW Components

    Usually, components are collections of SW Modules, together, they may implement a set of functions. Typical SW Components are libraries (also the standard libraries of the applied software development environment), sets of related and re-usable SW Modules, module sets that are used by other SW Units, etc.

    The C or Ada standard library is a typical SW Component.

    Next, typical, language-dependent situations will be described in the form of solution examples.

    OOL.3 Using Ada 95

    OOL.3.1 The structural Means of Ada 95

    The library is the basis for the generation of Ada software. The Ada standard (/DIN ISO IEC 8652/) does not explicitly demand how a library should be structured. The basic idea with regard to the Ada library concept is that the library stores compiled program units that are contributions for a system that will be loadable at some later time. Compilation of program units and the linking of a program always take place within the context of a library, whereby consistency checks are realized beyond the limits of library units. An Ada implementation can support the linking of several libraries into one library hierarchy. Ada 95 does not specify structure and function of a program library in such a detailed way as Ada 83.

    Ada 95 observes the fact that a "program" is not necessarily bound for one single processor or for one single virtual address space. Today, a program rather means a number of modules that are implemented into a system and that, in general, run simultaneously on several hardware components. In Ada, these components are called partitions. In a conventional case, a program is identical with a partition. In the case a program consists of several partitions, it is referred to as a system.

    Ada 95 introduces the child library unit. This child library unit is a library unit that represents an extension of an already existing library unit. Child library units may be nested as desired. As language means, the child library units are the most important prerequisite that Ada can introduce the concepts of object orientation (tagged types, programming by extension), by taking into consideration Ada 83's upward compatibility. A complete hierarchy, consisting of library units, child library units, and subunits is referred to as an Ada subsystem. The term Ada subsystem therefore covers another area.

    In addition to the context clauses of Ada 83, the child library units offer the programmer more possibilities for the program structuring and for the easy extension of already existing systems.

    OOL.3.2 Mapping on Product Structure

    SW Module

    A SW Module is the smallest software unit identified by the configuration management. In Ada, this fact has its analogy in the library unit or in the child library unit. A (child) library unit in the sense of the product structure consists of Generic units are used to generate loadable program units from a program template by applying the method of generic generation. A generic unit is not a contribution to a running system, therefore a generic unit is not a part of the product structure either.

    As modules, library units include program units. For technical reasons, a program unit is not identical with a library unit.

    The language standard also includes program subunits. This is used for a better structuring of program units. A subunit always refers to a program unit from which it depends.

    SW Components

    The V-Model considers a SW Component as the combination of several SW Modules used for the solution of a sub-task. This is based on a structure of matching Ada library units. The connection is made by Ada's "with" clause. A SW Component is a collection of matching sub-systems including the implementation of the SW Component. In the case the SW Component is a loadable program, the partition is the Ada equivalent. If it is not a loadable system, one or several Ada subsystems are the equivalent.

    SW Unit

    A SW Unit in the sense of the V-Model is a more or less independent software unit which implements a defined function of the system. A SW Unit is a program unit that can be separately tested, and is usually loadable as well. This matches the definition of the program (generously defined in Ada 95). An Ada program is a set of communicating partitions. In general, a SW Unit is also realized by one or several Ada partitions. This definition comprises both distributed systems and one-processor systems.

    OOL.3.3 Overview

    Table OO.1 illustrates the allocation of Ada language elements as compared with the elements of the product structure. Thereby it is possible that several versions of the Ada elements are allocated to one element version of the product structure.

    Ada Language Element SW Unit SW Component SW Module
    Ada Program    
    Partition  
    Distributed System    
    Subsystem
    Library Unit    
    Child Library Unit    
    Subunit    

    Table OO.1: Allocation of Ada Language Elements to the Product Structure

    OOL.4 Using C++

    OOL.4.1 The Structural Means of C++

    Apart from the object-oriented language elements, C++ (/Ellis, 1990/, /ANSI Com. X3J16/) also offers elements known for procedural languages. Since the use of object-oriented elements in C++ is not mandatory, it is referred to as a "hybrid" object-oriented language. Therefore, mapping on the product structure of the V-Model is not only limited to object-oriented languages alone but also includes the procedural elements.

    The class is the central structuring means in C++. An object-oriented program consists of a set of class definitions, a main function, and the option of other functions. Apart from the possibility to link classes via "usage" and "inheritance" relationships, the language itself does not know any combination of classes into a library. This is based on the responsibility of the applied development standard and is often directly mapped on the file system. Also, class libraries are not a language construct but an administrational combination of classes.

    The idea of being able to compile is a decisive factor for the structuring of C++ program systems. (This is a result of the downward compatibility to C.) The visibility range of local variables and functions can be limited to a compilable file or be exported for the use in functions from other compilation units.

    The dependence of compilation units are not administrated by the language itself but by additional tools. (In most cases, tools like "make" will be applied.).

    OOL.4.2 Mapping on Product Structure

    SW Unit

    A selected SW Unit in C++ is one that contains the "main" function. Each application system has to include such a function. This SW Unit is loadable in as far as it can be loaded and started after the compilation-with corresponding saturation of the static references to other parts of the SW.

    Usually, such a SW Unit contains

    that are only needed for this particular SW Unit. (Elements that are also used by other SW Units, are integrated into separate, re-usable SW Units or SW Components for practical reasons.)

    When using a layer architecture, the services of one or several underlying SW Units can be used by this SW Unit. With the exception of the description of the main function, the same holds true for such SW Units.

    In general, a SW Unit consists of several SW Modules and thus of several files (see below). The CID of a SW Unit contains the identifiers of its SW Modules.

    SW Module

    Within a SW Unit the usual modularization criteria are applied for the structuring (separateness, ability to modify, slight coupling, etc.). This results in SW Modules that, as a rule, are comprised of the following: A specification file (according to convention a file with the ending "h"(3) ) should exist for each SW Module. This specification file should name the outer interface. The implementation file (ending "cxx", "cpp", or something similar) contains the realization of the specification with C++ syntax (which is the actual source file).

    It is not required to enter the number of classes and functions a SW Module should contain. However, it is practical if a SW Module introduces only a few classes at its interface (h-file; small interface, if possible). (It depends on the application if the publication of one class per SW Module represents an ideal solution).

    SW Modules in parallel may call each other without having to generate a layer construction over the software components (see below).

    SW Component

    Normally, SW Components combine SW Modules that are used by several SW Units or that are generally made available for being reused. Based on the efficient structuring of SW Units, SW Modules can also be combined into SW Components within one SW Unit. The same holds true for nested SW Components.

    OOL.4.3 Overview

    Table OOL.2 illustrates the allocation of C++ language elements to the elements of the production structure. Thereby, a SW Unit or a SW Module may contain several elements of the allocated C++ language elements.

    C++ Language Element SW Unit SW Components SW Modules
    Function  
    Data Element  
    Class  
    (Class) Library    

    Table OO.2: Allocation of C++ Language Elements to the Product Structure

    OOL.5 Using other Object-Oriented or Object-Based Languages

    Today, object-oriented (or object-based) extensions(4) exist for other classical programming languages like COBOL and FORTRAN which, because of recent developments, are oriented to Smalltalk, C++, or Ada 95. The above listed regulations and instructions are meant for these languages as well. Therefore, in the following, only the allocations for the language elements are illustrated in the tables.

    OOL.5.1 Overview of Language Allocation for OO-COBOL

    Table OO.3 illustrates the allocation of OO-COBOL language elements (/ANSI Com. X3J4/) to the elements of the product structure. A SW Unit or a SW Module may contain several elements of the allocated COBOL language elements.

    The description of compilation units and the integration of class libraries into the language is the same as for C++. In the same way, an ANSI draft standard exists for OO-COBOL as well as for C++.

    OO-COBOL Language Element SW Unit SW Components SW Modules
    Program  
    Subprogram  
    Class (syntactic "program")    
    (Class) Library  

    Table OO.3: Allocation of OO-COBOL Language Elements to the Product Structure

    OOL.5.2 Overview of Language Allocation for FORTRAN 90

    Table OO.4 illustrates the allocation of OO-FORTRAN language elements (/ANSI X3.198/) to the elements of the product structure. In this connection, several versions of the OO-FORTRAN elements can be allocated to one element version of the product structure.

    FORTRAN 90 is not an object-oriented language but an object-based language, since the concepts of inheritance and polymorphism are not supported. Based on the language philosophy, FORTRAN 90 can be compared more or less with the Ada 83 version. Therefore, in order to discuss the structuring means and the illustration of the product structure, it is referred to the information about Ada above.

    In the next table, the language elements of FORTRAN 90 are allocated to the product structure of the V-Model:

    FORTRAN Language Element SW Unit SW Component SW Module
    Program  
    Subroutine/Function  
    User-Defined Data Types  
    Libraries    

    Table OO.4: Allocation of FORTRAN Language Elements to the Product Structure


    Notes:

    (1) Supplementary to this, the languages OO-COBOL and FORTRAN 90 are taken into account.

    (2) In addition, an own scenario for the presentation of object-oriented procedures is described in the Scenarios manual (also in this Part 3 Collection of Manuals), which clarifies the effects of use of object-oriented technologies independent of the language employed.

    (3) The "h-files" are imported by a #include statement.

    (4) object-oriented=object based + inheritance;
        object based=modular + abstraction + instantiation

    Previous Next This page online  •  GDPA Online  •  Last Updated 03.Mar.2004 by C. Freericks