by Klaus Mertes, CAP debis SSP
Introduction Modular Design is a structured approach to the design phase in a product development cycle. It enables you to divide a system into independent, easy-to-understand pieces. This is a very effective way of controlling complexity. Task Design is a method for modelling the dynamic aspects of a target system and completes the static description of the system functionality. Both methods define independent design models which are linked to each other via traceability links.
The models described in MD and TD can only describe a snapshot of a design stage, but without any design history. Variant parts or different configuration possibilities (design families) can not be expressed in MD or TD, nor in the ProMod-PLUS tool set.
This deficiency will be solved by the integration of ProMod-PLUS and the PROTEUS Configuration Language (PCL). This integration will allow the user to define variants in a given design, store and retrieve them, with the help of the PCL tool set.
The next paragraphs briefly summarize the main concepts and elements of MD and TD, followed by the integration aspects.
Modular Design The model built using Modular Design is based on the principle of a tree structure, or hierarchy. This enables the problem to be systematically broken down into subsystems, modules and functions.
When the logical part systems have been thought out, the next step is to decide which individual jobs these part systems perform. Because this involves breaking down part systems into modules, it is called modularization.
Modules are based on the Òblack boxÓ principle, also known as Information HidingÓ. In a black box the inputs, outputs and the function of the box are known, but the details of how the function is carried out are unknown. Each part of the program can then be built and tested independently.
Interaction with other modules is carried out through controlled interfaces, where the information which may be exported and imported is exactly defined. Any later modifications in one module will have minimum effect on the other modules with which it communicates.
Structured Design means that the modules are broken down into individual processes. These processes enable the module to do the assigned job. In Modular Design they are called functions and are the smallest blocks of the system hierarchy. They can be described by pseudocode.
Task Design Task Design is a method for modelling the dynamic aspects of a target system and is as such a powerful enhancement to the Design Model produced with Modular Design. The Task Design Model shows the run-time aspects of a system design. The Task Design Model describes the dynamic organization of a system. For this reason the execution processes of a system and the incidents which have an impact on these processes have to be specified.
The execution processes are called Tasks and the incidents are called Events. The Tasks represent components of a system which fulfil a distinct purpose thereby working in parallel with others. Events can represent either impacts that come from the environment of the system (e.g. stimulations from the operating system or other systems which are not part of the system being designed) or technical mechanisms of synchronization inside the system (e.g. mailboxes, semaphores, queues).
The communication between Tasks and/or Events is modelled with Messages. Every Task or Event can send a Message to another Task or Event, which means that a Task or Event stimulates the object receiving the Message.
Modular Design guided Implementation ProMod-PLUS automates the transition between design and the target languages C and Fortran in both directions. Source Pilot is the tool name of this automated process. It converts the design model into the target languages and guards against programming mistakes at the critical points of a program, for instance interface definitions. Source Pilot does not only support new developments but also the maintenance of existing systems, because changes in the design of the source code can be integrated at any time into existing source code.
Design Families using MD ProMod-PLUS Modular Design and Task Design are well suited for the design of exactly one instance of a design family. To enable the user to define variability in the design, it is necessary to introduce configuration management aspects in ProMod-PLUS and make them available from within the design tools. In our case we decided to use the PROTEUS Configuration Language (PCL) for the modelling of the variability in MD and the PCL tool set (plus some special integration tools) for storing and manipulating the information belonging to the design family.
One of the major goals of the integration with PCL is to enable the building and reloading of one instance of a design family from within ProMod-PLUS. The user can define (in ProMod- PLUS) the variant specific attributes for a complete or part of an instance and save this configuration without any manual action. The generation or manipulation of the PCL description will be handled by the integration tools. The generated PCL description contains all structural information, while the textual files (stored in the PCL repository) linked to the PCL description, contain the full design information.
The same is valid for reloading instances (or part of them) into an empty or existing design. After reloading, the ProMod-PLUS analyser will check the consistency of the design.
With the help of the graphical PCL editor (accessible from ProMod-PLUS), the user can browse the complete design family. Changes to the design family should only be permitted from ProMod-PLUS, to avoid inconsistencies.
With all the enhancements described above, the integration of ProMod-PLUS and PCL will enable the user to build a consistent description of a design family, and to have a single entry point for manipulating and reusing design families.