|4.24 Elementary Method "Module Diagrams" (MODIAG)|
The method is used for the object-oriented system development. It can be applied during the physical software design. Its objective is to realize the allocation of classes and objects to modules and to detect compilation dependences between modules.
In this case, the term "module" must be understood as a program unit serving as a component for the physical software structure of a system. It is identified by means of a name and is expressed in the vocabulary of a certain programming language; it realizes one or all classes and objects of the logical software design. Normally, a module consists of two separate compiling units: its interface (specification) and its implementation (core).
Means of Representation
The method was defined by Grady Booch and is part of the complex method "Object-Oriented Analysis and Design (OOAD)" /Booch, 1994/.
The module structure of the software can be graphically represented in module diagrams. Symbols are predefined to identify main programs, specifications and cores with their names. If these symbols are not sufficient to differentiate between the separate compilation units for the programming language used then it is possible to define additional symbols. Detailed information for the specification of the individual modules can be stored as text in the supplementing module descriptions.
Specifications correspond, e. g., .h files in programming language C++, the cores are the .cpp files. The module names should match the names of the corresponding files. Sending files is not required since they would be redundant in connection with the symbol.
Ada 95 is the first standardized programming language supporting an object-oriented software development. In Ada, modules are expressed by program units. For program units it is also possible to differentiate between specifications and cores. Compilation dependences are expressed by arrows pointing to the modules for which a dependency exists. Examples are the "#include" relation in C++ and the "with" relation in Ada.
In complex systems, structuring into a number of modules may be required in the physical system design. In order to handle the complexity and the possible intricateness in the representation, physical subsystems can be defined with the help of a special symbol. These subsystems group physically matching modules for classes, objects, free subprograms and libraries.
The allocation of modules and classes is given when both a specification and a core are defined for each class. The allocation of objects, free subprograms, or libraries as well as the combination of classes into one module must be specified, however. This can be realized in the module programs by allocating identifiers to symbols, or, in text form, in separate class or module descriptions.
The physical system design defined by Booch has been integrated into the Unified Modeling Language (UML) /Booch, 1997/. The "Component Diagrams" defined there represent a generalized approach of the module diagrams.
The generation of the module diagrams has to be realized during the design phase when, with regard to the implemention technique, the relationship between the classes and objects are specified both from a logical and from a physical point of view. They have to be generated in close connection with the procedure of the applied complex development method and adjusted with the method COM - Class/Object Modeling and the method PRODIAG - Process Diagrams).
In the Booch method, the module diagrams are generated in iterative runs during the design. Each run results in detailed, improved or new or respectively modified modules and relations.
If the programming language to be used supports compilation units not covered by predefined symbols, it is necessary to define additional symbols.
|4.1||SD4.1 - SW Architecture Design||
With the help of module diagrams, SW Components and SW Modules can be specified from a physical point of view. SW Components can be symbolized as "physical subsystems". Module generation from a physical point of view has to be adjusted with the professional structure as realized by means of a subsystem modeling (compare method SSM - Subsystem Modeling) and the class/object modeling (compare method COM - Class/Object Modeling). In case different structures are used both from a logical and from a physical point of view they have to be adjusted. The allocation of main programs, classes, objects, free subprograms and libraries to modules has to be specified. Detailed information must be stored in the module descriptions.
In combination with methods "class/object modeling" and "subsystem modeling" the method covers subprojects SW Architecture.Solution Proposals and SW Architecture.Modularization/Database Design from the point of view of the architecture elements.
The compilation dependences represented in the module diagrams show which internal interfaces exist between the SW Modulees of a SW Unit. These information are integrated into subproduct Interface Overview.System-Internal Interfaces.
|4.2||SD5.1 - Description of SW Component/Module/Database||
Module diagrams and module descriptions define which classes and objects are allocated to a module; together with class/object models, subsystem models, state models and interaction models they are a source of information for the description of the SW Components and SW Modules in the SW Design (Module).
The method covers subproduct SW Design (Module).SW Component/SW Module Description from the point of view of the class and object allocation.
|No.||Interface||Observation||Information in Annex 1|
|5.1||MODIAG-COM||The classes and objects identified by method COM are allocated to physical program parts by method MODIAG. For active objects having an individual control flow, individual main programs can be specified.|
|5.2||MODIAG-SSM||The professional system structure realized with method SSM must be adjusted with the physical structure by means of method MODIAG.|
|5.3||MODIAG-PRODIAG||For each process defined in method PRODIAG a separate main program must be specified in method MODIAG.|
|GDPA Online Last Updated 01.Jan.2002 Updated by Webmaster Last Revised 01.Jan.2002 Revised by Webmaster|