Integration via meta model-based repositories
Open source and commercial development tools can be integrated by using a central meta model based-repository, assuring complete and in-depth traceability that encompasses all proprietary tool artifacts.
How does it work?
All artifacts from the individual development phases – including requirements, design elements, and test cases – can be viewed as model elements. Their structures, attributes, and basic dependencies, along with a description of the organization’s development process, are captured in a tool-independent meta model known as an Ecore model (= essential MOF).
The tools to be integrated are tied into to the central repository via transformers which translate the tool-specific artifacts into the tool-neutral meta model and vice versa, using a meta model designed for each particular tool. The specialized tools are still used to create and edit the artifacts, which are now managed by the central repository.
Unlike the closed systems regularly found in commercial tool suites, the underlying meta model for describing processes and artifacts is open and can be extended. The standardized, homogeneous MOF-based meta model is the basis for the tool-neutral integration.
All phases of the life cycle can be controlled at a central point, the so-called Cockpit. The Cockpit is the central GUI, and is based on the open source framework EMF (Eclipse Modeling Framework). All project-related information is accessible and controllable from it. The various tools are integrated into and monitored via the navigation bar of the Cockpit, in such a way that the transformers described above are transparent to the user during operation.
The (model) instances of all artifacts in the process and their relations to each other are stored persistently in a version control repository, e.g. Subversion. For Subversion, access is provided by the SVN Eclipse plugins Subversive or Subclipse.
Inter-tool traceability is realized by analyzing references contained in the tool-neutral meta models at transformation time. Trace information can be created automatically by tool and/or process rules, or manually by setting links within traceability matrices found in the individual tools. Furthermore, the visualization and maintenance of traceability information is possible in the repository independent of the individual tools, e.g. via traceability matrices in EXCEL.
What do you get?
The complete integration and traceability of artifacts across the entire life cycle can be guaranteed.
This approach in particular gives you the possibility of an incremental and future-oriented integration of existing and new tools, the final goal being a self-contained tool chain.
The resulting high level of integration helps you avoid interruptions between different development phases, thus laying the basis for an increase in process maturity level.
Integrated configuration management across all development phases can be obtained by employing open source or commercial version and change control tools.
Example
The central meta model, which forms the basis of the Cockpit, reflects the domain of the user. For our example customer, this includes requirements, use cases, test cases and components, along with their relations. The corresponding artifacts are created in Word, Enterprise Architect (“EA,” a UML tool), matlab/simulink (modeling tool for embedded systems) and Excel. However, each tool uses different proprietary file formats (“tool-specific” meta models), which can not be combined easily.
- Requirements are created with Word. Using a “simple” adapter, the Word document is parsed and converted into a representation conforming to the meta model used in the Cockpit.
- Due to the compatibility of the meta model to MOF and Ecore, use cases can be created directly from the requirements. QVT technology is utilized, which supports the transformation of MOF models. Within the Cockpit, the transformation is automated and carried out according to user-defined rules. For our example customer, a use case is created automatically for each functional requirement and shares its name. Additionally, a test case corresponding to each requirement is generated.
- Doubtlessly, the generated use cases are incomplete, because, for instance, you can’t assign actors solely on the basis of requirements. Therefore, in the next step the use cases are rounded out in EA. The EA adapter converts the internal model into a format which is “readable” for the UML tool. Depending on the mode of integration this may, for example, be done via the generation of XMI files. After completing the use cases in EA, a “reconversion” into the internal model (bidirectional adapter) takes place.
- At this point, further steps may be taken, as mandated by the organization’s development process: derivation of sequence charts from the use cases, high-level design of the components in EA, low- level design of the components in matlab, definition of test cases in EXCEL. etc.
The crucial point (in points 1 to 4) is that all actions are controlled in the Cockpit and relevant information is managed in a central MOF-based data pool, which is kept persistent due to the connection to Subversion (plugin/ team functions). At any time, it is possible to map what components originated from which requirements and to detect if modification of a requirement will interfere with any existing use cases or components (traceability). OCL constraints let you define and manage rules and keep the entire system in a consistent state during modifications.
