Previous Next V-Model Official Homepage by IABG  
RE 2.2: Remodularization/Restructuring  

  RE2.2 - Remodularisierung / Restrukturierung

  • Product Flow
  • Handling
  • Product Flow

    From Product to
    Activity State Chapter Title Activity State
    External (1) - All Available source code - -
    RE1.5 accepted All User Demand - -
    - - All Implementation Document: SW Module RE2.3 being proc.
    - - All SW Module
    - - All Implementation Document: Database
    - - All Database


    Based on subproduct User Demand.Possible Solutions, this activity tries to improve the modular structure of the software to be processed, by taking into consideration modularization principles like separateness, confidentiality principle, data abstraction, packaging , interface specification and interface minimality, and making it distinct and testable.

    However, it must also be taken into consideration that, given today's technical possibilities, it will usually be the case that remodularization will be limited to split all SW Modules, which, on the basis of the criteria "Number of Statements" were judged to be too big, into several SW Modules. This splitting may be initiated by the control flow graph on the basis of which larger connected structures are specified and converted into a separate SW Modules. Links to these new SW Modules are replaced by call statements in the source code. When splitting SW Modules it is necessary to observe that all SW Modules only contain data that will be actually used (confidentiality principle).

    The remodularization is therefore always connected with a restructuring. Restructuring also includes such measures that-independent of the changes to the modular structure-contribute to the improvement of sequence and data structures and thus to the better understanding of source code.

    The sequence structures may be improved by taking into consideration the principles of structured programming, i. e. it is aimed at the exclusive use of control structures sequence, selection, iteration, and procedure call. In as far as this is advisable and possible, goto statements in the source code should be replace by structured control statements. Among the number of simple, restructuring measures are the movement or duplication of code blocks, the basic addition of else clauses, the restructuring of if statements, the indication of program loops, and the prevention of label variables.

    For example, the available data objects may be improved by dissolving inconsistencies and redundancy. Inconsistent are data objects having the same name but different tasks (homonyms). Redundant are data objects having different names but the same tasks (synonyms, alias names). Indicators for synonyms may be the same formats and the same value range of objects with different names. Homonyms can be detected by comparing characteristics of data objects with the same name. For example, if data objects with the same name have different formats and different value ranges, this might possibly point to homonyms. The dissolution of homonyms and synonyms must not take place mechanically. It is necessary that exact checks are made that make errors impossible. When new names are allocated for homonymous and synonymous objects it is important to observe that the new names/identifiers are user-level-oriented, so it will be possible to use the object's name/identifier to refer to its user-level task or to the type it represents. Since no user-level understanding of the software to be processed has been acquired at this time, the allocation of new identifiers can only take place in connection with the recommenting (activity RE 5.2: Recommenting).

    The results of this activity are documented in the products Implementation Document: Module and Implementation Document: Database.


    (1)   Customer

    Previous Next GDPA Online Last Updated 01.Jan.2002 Updated by Webmaster Last Revised 01.Jan.2002 Revised by Webmaster