RIF/ReqIF is the new OMG standard for requirements interchange. RMF (currently in proposal phase) provides an EMF Ecore based metamodel implementation for the RIF/ReqIF XML format. The metamodel is a clean implementation of the format without any “XML noise”. The Ecore metamodel also conforms to the CMOF metamodel delivered by OMG (as it has been derived from it). The metamodel reads/writes RIF/ReqIF data in conformance with the RIF/ReqIF XML Schema.
The challenge in the Ecore based RIF/ReqIF implementation was the customization of loaders and serializers to make them RIF/ReqIF XML Schema conformant. EMF provides different ways of customizing the XML output.
1. Using ExtendedMetadata annotations.
Both approaches are quite tricky to implement when the expected XML output has structural differences compared to the Ecore metamodel. For example, the XML output has wrapper elements for lists (ELists) in the Ecore metamodel.
We went in for a third approach.
We imported RIF/ReqIF XML schema using EMF importer to create a RIF/ReqIF XML Ecore model (Anyone who has done this, knows it’s an “ugly” metamodel that EMF generates here). The next step was to create the real RIF/ReqIF metamodel, by importing RIF/ReqIF CMOF file. We then wrote a generic (of course reusable) Ecore XML to Ecore converter to do a model to model transformation in both directions. The whole processing is cleanly hidden in a new EMF Resource implementation such that the user hardly knows anything about these.
The following are the advantages we saw in the approach.
1. You don’t do customizations at a XML level, but at a higher EMF model API level. That is, you don’t hack some XML SAX events, but work with familiar EMF APIs.
2. The generic Ecore converter has enough hooks to plugin in the transformations.
3. Easy maintenance as the customizations are available in one place.
The drawback of this approach could be the processing involved in the model to model transformation. However, the highly optimized model to model transformation we implemented doesn’t make it all that slow. Our performance tests proves this (which would be the topic of my next blog post). It is infact upto 300 times faster than having the same data in the default XMI format (Yes I meant 300! Ed Merks is going to get back to me on this I hope ;) )
Ed did get back to me. With the performance optimizations applied to XMIResource loader to use cache for Intrinsic Ids and URIs, the performance improved dramatically. The XMI resource loader now takes only 22,2s to load a 32MB sample, compared to the earlier 70mins. I am glad that our RIF XMLResource however takes only 14,4s for the same contents.
Beginning of the year itemis opened its new location in Stuttgart. Now that we have settled down here, we made an official launch party. It was a nice little event attended by some of our customers and of course the itemikers. The event took place at “Stuttgarter Engineering Park (STEP)” where itemis has its new home.
- itemis was founded in 2003; 2006 in South Germany
- 10 locations in Europe now
- 150 employees in total, 18 at itemis Stuttgart
Markus Völter, then gave an excellent talk on “Model-Driven Development and DSLs“.During the one hour lively talk, he went on talking about the history of MDD and DSLs. What was even more interesting was when he displayed some DSLs he implemented for some real world applications like a “Pension Fund Specification” and “Fountains” (Fountain is no new buzzword, its the fountain you see at parks :) ).
The coffee break was a chance to get to know some new faces and welcome some familiar faces to our new location.
The second presentation of the day was from Andreas Graf and myself on “Requirements, Traceability & DSLs“. Andreas Graf’s “Presentation Zen style” slides appeared to catch everyone’s attention. He talked about the new activities at itemis on Requirements Engineering solutions. In between the talks, I managed to give a glimpse of the new tools with 3 demos.
The light dinner was again a chance to meet more people.
Thanks to all for attending. More images from the day can be found here.
Over the last few months some guys at itemis and Düsseldorf University have been working closely to bring out a solution to the open in an effort to lessen the big gap we have currently in Eclipse Ecosystem in the area of Requirements Management (RM). Requirements Modeling Framework (RMF) has been proposed to Eclipse Foundation as an open source project under Model Development Tools Project.
Scope of RMF
The scope of the project, as described in the proposal, is to provide an implementation for the OMG ReqIF standard (just as the Eclipse UML2 project provides an EMF based metamodel for OMG UML). Requirements management tools could then base their implementation on the provided ReqIF metamodel. It is also in the scope of the project to deliver a requirements authoring tool, again based on the ReqIF metamodel and optionally a generic traceability solution.
Significance of ReqIF
ReqIF (Requirements Interchange Format) is an open standard from OMG for requirements exchange (I had blogged a while ago on how we arrived at ReqIF (earlier called RIF)). Many tools like DOORS already support a snapshot export to this format. Having an EMF based metamodel for ReqIF, opens up the Eclipse framework for integration and new tool development in the area of Requirements Engineering.
ReqIF in a nutshell
ReqIF offers a generic metamodel to capture requirements (The generic nature is at times highly criticized. More on that later). The figure above shows a bird’s-eye view of the metamodel. The metamodel allows creation of requirement types (SpecType) with different attributes types and also instances for it (SpecObject). Since ReqIF also carries the metadata (in the form of SpecTypes), it makes it possible for any tool that understands ReqIF to process the data.
ReqIF also allows creating hierarchy for requirements, grouping them and controlling user access. To support rich text, the metamodel reuses XHTML.
Generic nature and “meta”ness of ReqIF
Anyone expecting a requirements metamodel might be surprised at first when they have a look at ReqIF. You hardly find a term called “requirement” in there. ReqIF is more at a higher meta-level, that is M1. It has been designed this way for a reason.
Requirements Management is an evolving field and until recently never crossed company boundaries. With tighter collaboration between partner companies the benefits of applying RM across company borders became known. The field being highly dominated by commercial products gave barely any chance for standardization. A group of companies in the automotive field, realized that with such a diversity existing hardly any unification is possible. They gave birth to this generic requirements interchange format which was later adopted by OMG and standardized.
The generic structure of ReqIF allows companies to use the tools of their choice to do requirements management and use ReqIF as the standard exchange mechanism and even do round trips. ReqIF is not the only standard to allow this generic nature in the field of Requirements Engineering. DOORS, for example, has an extensible database allowing users to add/delete attributes. The changes to the schema are often communicated to the partners by external means to replicate the changes in their database. Since ReqIF carries the meta-information with it, the changes are migrated automatically across tools/company boundaries. Transmitting the meta-information in ReqIF could however be controlled by tooling. This nevertheless would beat the purpose of ReqIF.
It is also questionable, why such a generic model is required when we have metamodels like UML or EMF already available. The reason for this is very much the same as why EMF co-exists with UML. ReqIF is not a general purpose modeling language like UML or EMF, but more focused on requirements domain.
RMF provides ReqIF as an EMF based metamodel. This could be used by tool vendors as the internal tool model or an export model by means of model to model transformation. The provided loaders and serializers make sure that the ReqIF file is read/written according to the ReqIF XML Schema.
Using ReqIF natively brings all the advantages of ReqIF to the tooling as well. For example, ReqIF based tools could model the requirements domain of the company within the tooling and share it with partners along with the instance data.
The initial code contribution is planned by early August 2011 and will be made available as soon as the IP review at Eclipse is complete. If you have any suggestions/comments about RMF, would like to contribute or like to be listed as an interested party, please provide it here.Images from FreeDigitalPhotos.net