|3 Explanations of the Methods|
The Object Design Technique (ODT) is based on the papers of Booch /Booch, 1987/ and /Buhr, 1984/. Later, it was enlarged by aspects like hierarchical configuration, specification of trigger types, and various object types, etc.. A complete description of this subject was then set up in /ESA, 1989/ under the name "Hierarchical Object Oriented Design (HOOD)".
The definition according to /ESA, 1989/ was selected because it comprises a precise and compact description (p. 1-12) of the essential characteristics of the required application purpose (SD4 - Preliminary SW Design) including the aspect of the application of the method for "realtime-oriented systems with concurrent processes" (see footnote 21) in chapter 3.5 of the Methods Standard).
Notes about the Ada Relationship of the Method
The method is oriented on the basic concepts of the programming language Ada, according to its origins. The representation of the SW architecture is the core of the description on the referenced pages 1 to 12 from /ESA, 1989/. The reference to Ada as a programming language is not made earlier than page 13 in /ESA, 89/ ("text formalism"). This part is not required for the method allocation (SD4 - Preliminary SW Design), and has therefore been excluded from the identification/definition of the method in the Methods Standard. Only in the following SD5 - Detailed SW Design, the text specifications are required in form of method PCODE - Pseudocode which are defined as independent of any programming language, i. e. as not Ada-oriented.
Therefore, even in projects with other target languages as Ada, a design of the SW architecture according to ODT is adequate, i. e. if the system is a realtime system with concurrent processes. The following detailed design and implementation in a different programming language as Ada must then illustrate the listed SW architecture accordingly.Configuration Management (CM). The lack of these standardized methods is based on the fact that within the configuration management-contrary to the other submodels of the V-Model-an independent abstract method has not been developed. To support the product administration as the central activity in the configuration management, tools have been developed at an early stage, which utilize special mechanisms to administer revisions and versions of individual products and product structures. These mechanisms can only be sensibly applied together with the tools so a separate and tool-independent standardization cannot be recommended within the scope of the Methods Standard.
Therefore the tool-independent procedure for submodel Configuration Management is completely defined by the activities in the V-Model. The functional requirements for tools to support the configuration management are directly based on this procedure; they do not include any methodological elements.
|GDPA Online Last Updated 01.Jan.2002 Updated by Webmaster Last Revised 01.Jan.2002 Revised by Webmaster|