Français
OCLMetrics
Document Actions
Our metamodeling analysis environment has been designed with an extensible architecture. It has been developed as a set of plug-ins for Eclipse. The components of this architecture are the following:
- Preprocessing Core: This component realizes the preprocessing step to obtain a .oclxmi file of the OCL invariants for every metamodel. It provides utilities for preprocessing the different possible formats:
- An extractor of OCL constraints from Ecore metamodels, using Xpath.
- An extractor of OCL constraints from XMI files based on the UML schema, using Xpath.
- An extractor of OCL constraints from XMI files based on the CMOF schema, using Xpath.
- A transformer from MOF 1.1 to Ecore.
- A transformer from CMOF (Complete MOF) 2.0 to Ecore.
- A wrapper for the Eclipse OCL parser of individual constraints
- A wrapper for the Eclipse OCL parser of documents of constraints (.ocl files)
- A wrapper of the Eclipse OCL persisting mechanism in order to save a parsed version of an OCL expression as an instance of the OCL abstract syntax metamodel (.oclxmi files).
- A wrapper to the Kermeta Metamodel Pruner. This is an utility that allows the preprocessor to prune a metamodel to include only a set of required classes and properties given as input [24]. This component provides an extension point to use these utilities.
- Metamodel Loaders: For our study, we have created loaders for each one of the specifications in our experimental setup; for example, the UML Metamodels Loader uses the preprocessing core’s utilities to load the 13 UML metamodels. Each loader is an Eclipse plug-in that makes use of the extension point provided by the preprocessing core component. Every metamodel can define its MOF and OCL artifacts in a single file, a file for each, or multiple files for both. Each metamodel loader takes care of loading this set of files, and then it invokes the utilities in order to extract constraints, validate them and parse them, and then persist them in order to have them in the .oclxmi format, which is suitable to perform the metrics analysis. In the case of specifications DWF, CSPF, ERRE, HRC, RBAC, MTEP, XMS, SAM, which provide the domain structure in a single .ecore file and define the integral set of invariants a single .ocl file, a single loader was built (called “OCL Document Loader”). Loaders for additional metamodels can be built to include them in the sample and run OCLMETRICS on them. It only takes declaring the extension to the preprocessor core’s extension point in the plug-in’s configuration file. In the figure, as an example the Corba Component Metamodel uses the service to extract the OCL invariants embedded in an Ecore file, as well as the parsing of each individual invariant and persistence. The RBAC Metamodel, as there was an available source file of OCL invariants as an .ocl file, uses the service of parsing such file type and secondly to persist them.
- OCLMETRICS: At the root of the architecture, the OCLMETRICS component makes use of the Preprocessing Core, because it depends on the output format of the metamodels (.ecore for the MOF part and .oclxmi for the OCL part) to perform the measurement of metrics. The data sets and metrics specified in the previous section were implemented in the OCLMETRICS tool. OCLMETRICS considers a domain structure defined in Ecore and the associated OCL. The tool can then analyze both parts of a metamodel, to automatically extract the data sets and compute the metrics.