![[Cradle System]](images/sys1.gif)
Many systems have a software content. At some point in the lifecycle, the project will need to either generate source code from the design, or to validate the design against actual code. Once source code exists, engineers frequently make all subsequent changes directly in it. The project must therefore be able to assimilate source code changes into the design. Otherwise, the design process becomes a throw-away once only exercise.
A need exists for a mechanism to transform the detailed system design into source code which is as complete as possible. Once source code exists for a system, a need exists for mechanisms to recover the design from a suite of source files and subsequently allow the system to be modified within the design, and then completely regenerated as source code.
The source code management facilities in the Software Engineering Module exist to satisfy these needs.
Cradle provides a Code Generator and a Reverse Engineering tool. The latter recovers all possible design information from source code. The Code Generator has facilities both to generate new code and to re-engineer existing code. Both tools are designed to be used cyclically as often as desired.
For systems including software, detailed design defines the software architecture in a hierarchy of diagrams. Any of these diagrams can be code generated to produce skeletal AdaŽ, C, or Pascal source code. Type definitions can be produced by code generating the Data Dictionary. This process can be configured to produce code which is compliant with local coding standards.
Once source code exists (for legacy systems it may be all that exists), it can be reverse engineered to create new design diagrams, Data Dictionary entries and module specifications. By default, the source code in the original files is placed into frames in these items, so the source files become redundant.
All reverse engineering operations can produce a statistical analysis of code complexity, providing a range of source code metrics as an aid to judging code quality.
Mechanisms exist to allow routines within source files to be categorised as being a part of:
Techniques include regular expression (the most concise) and textual lookups in symbol tables. The mechanisms permit identification of routines and selective inclusion of these routines in design diagrams.
A variety of diagram construction and symbol display options allow project specific control over the format of the resulting design diagrams.
Once constructed, these diagrams can be browsed both vertically and horizontally within the design hierarchy using a range of navigation and code inspection facilities. These facilities include direct access within source files to routine declarations and traversal of the call tree between diagrams.
Being within items' frames, the source code can be browsed through the design, reported from it, and automatically configuration controlled by it.
All source files can be reconstructed on demand and automatically built. Any design changes can be reflected in the system by re-engineering the source code from the design, which reconstructs each source file but with all routine interfaces derived from the potentially modified design diagrams and data definitions.
Other frames in module specifications and DD definitions can be used to store build files, test data and results, and the results of specialist code analysis tools such as static analysers and test coverage analysers. By defining appropriate frame types the invocation of such tools can be made both fully automatic and mandatory, if required.
Requirements Management |
Systems Modelling | Performance
Modelling | Software Engineering
Document Composer | The
Cradle Core | 3SL | Home