ReqIF Meta-model, Model and Data
Initially it is important to understand that any project using the RIF/ReqIF standard is dealing with three abstraction levels:
- On the highest abstraction level, the RIF/ReqIF standard is a meta-model and as such covers the rules how object types and relation types are defined. The RIF/ReqIF standard is essentially an object-relational data modeling scheme with a high degree of flexibility. (Of course, it is less universal than a general relational database management system, but there are numerous advantages which will be presented later on).
- The model is designed to fit the needs of a particular application (i.e. a set of similar projects). It specifies the object types and relationship types between objects.
- The concrete project data, finally, are instances of the object and relationship types as defined in the model.
Basically, RIF/ReqIF data consists of Objects, Relations and Hierarchy-Entries, where all of these can have describing attributes. All objects are contained in a pool (or flat unordered list). Relations are directed and connect a source object to a target object. Hierarchies are used to organize objects in a tree similarly to a file system. Hierarchy-Entries are nested in a parent-child relationship: if a Hierarchy-Entry has one or more children, it is considered a folder, otherwise it is an object entry. However, in contrast to a file system, an object may be referenced in multiple trees or even several times in the same tree.
ReqIF Server: It's "Business Logic" is generated from the ReqIF schema defining the meta-model. So the ReqIF Server can import any RIF/ReqIF file without information loss. In addition, the "Business Logic" implements the historization (versioning), the access control and logging, so these characteristics are inherent to all RIF/ReqIF applications.
In a typical application, there are several types for Objects (blue), Relations (green) and Hierarchies (yellow). Every type is characterized by a unique set of attributes (brown). Each attribute definition specifies a data type for the value.
For example, in a given application we may need 2 object types 'System Component' and 'Requirement'. Also we may need 4 relationship types, namely
- 'contains' between two 'System Components',
- 'depends-on' and 'contradicts' between two instances of 'Requirement' and finally
- 'complies-with' pointing from a 'System Component' to a 'Requirement'.
The relation 'depends-on' may be used to show that a requirement depends on another, so it cannot be fulfilled without that the other one is fulfilled, as well. Or, the relation 'contains' signifies that a system component has a sub-component (or part).
A type for hierarchies named 'Tree' has been defined to organize the objects. The project data may include two trees of the same type: One for the 'Requirements' and another one for the 'System Components'.
In this example, a system component has two attributes 'name' and 'description', whereas a requirement has 5 attributes. Most relations don't need an attribute, just the relations of type 'contradicts' have a description to hold some explanation of the contradiction or ideas on how to overcome it.
ReqIF Server: Object and relationship types as well as hierarchies are dynamic. For this reason, the range of applications is much bigger than for requirement management alone. We propose to use the ReqIF standard and the ReqIF Server for system engineering models in general.
Please note that the model can be modified at runtime: If, for example, an additional attribute is needed, it can be created at any time and it is made available through the web-services at once. Changes to the model can be applied via an incremental import of a RIF/ReqIF file or via web-service, e.g. 'createSpecType' or 'createAttributeDefinition'.
Besides the model, a RIF/ReqIF file contains the concrete object, relation and hierarchy data of a project. When listed in a table, the requirements may be displayed in a row and the attributes are organized in columns. The figure shows some more requirement attributes, than in the model discussed above. The entries in the dropdown lists are the enumerated values as defined in the requirement's attribute definitions.
ReqIf Server: As discussed before, a RIF/ReqIF file contains both the model and the data of a project. A freshly installed ReqIF Server just needs to import a RIF/ReqIF file and is ready to run - no further setup is needed. Right away, the ReqIF Views, the supplied generic web user interface, lets a user browse the complete project and edit those attributes for which an 'edit' access policy is granted in the RIF/ReqIF file. In addition, every object can be queried and modified using the web-service interface in HTML, XML or JSON format.
This chapter has shown that the RIF/ReqIF standard defines a meta-model, whereas the data model with types for objects, relations and hierarchy-entries may be dynamically defined for an application (a set of similar projects). Finally, the concrete objects, relations and hierarchy entries belong to a particular project. Both the model and the data are contained in a RIF/ReqIF file.
Relations between Revisions of Objects
ReqIF stores objects and relations; their types are user-defined. For example, three object types may represent system components, requirements and test-cases. Two relation types may be be used to express that a system component 'satisfies' a requirement or a test-case 'verifies' a requirement.
When objects have revisions, a closer look is needed on how to handle the relations:
- In case of a 'satisfies' relation, the revisions of the respective objects are not important: If a 'satisfies' relation is appropriate for one revision of a requirement, it is equally appropriate for a newer revision of that requirement. For this case the ReqIF Server offers 'floating' relations: The relations automatically apply to the newest revisions of the system components and requirements.
- In case of a 'verifies' relation, the needs are different. If a given test-case revision verifies a given requirement revision, this is not necessarily the case for a newer revision of the requirement. Also, a test project for a given software release must reference specific requirement revisions. Even if a requirement is being further developed for future releases, the reference for the current test project must not change. For this case, the ReqIF Server offers 'fixed' relations: Such a relation sticks to a specific revision of an object; if the relation is to point to another object revision ('change request'), it must be explicitly updated.
Don't get afraid that it is too difficult for a user to deal with all this detail: In case of system specifications, for example, many relations can be automatically derived from model diagrams. For those which are created manually, there is program logic to support the user. So we are giving full control to the developer of a web-app ... and the end user can enjoy the benefits of a semantic net.
When conceiving a system to support objects and relations with their revisions, the question arises how to implement the versioning, more precisely the historizing of data.
- First, file versioning tools known from software development come into mind. A given state of data is kept in a ReqIF file (which is a text file in a special XML format) and can thus be easily submitted to a file versioning tool such as Subversion or MS Sharepoint. Thus, a state of data (similar to a baseline or a backup) is stored from time to time. Changes between baselines are not traceable and it needs quite some effort to extract a list of changes to an object, as all baselines must be loaded and searched. These limitations are fully acceptable for many simple applications.
- There are also software libraries supporting data historizing. The solution's data model keeps the actual data and for every update an entry is made in a 'change log'. Here, every change to an object is traceable and it is easy to extract a history of changes from the change log. However, it is virtually impossible to recreate the relations that have been in effect at a given point in time.
- For the ReqIF Server we have decided to weave the revisions into the data model. Every transaction creates a new revision of one or more objects and/or relations. Consequently, the full state of data of any point in time is readily accessible. No baselining is needed. The complexity is hidden in the server and a web-app may or may not consider the revisions.
On a workstation with typically a single user, the most light-weight system stack is used. All needed infrastructure, such as embedded database and local web-server, are included in the installer. The size of the installer package is much smaller than an office suite.
A user can use the local installation in the same way as a remote server.
This configuration shares a server and does not need any installation on the client workstations; it can be used with a common web-browser.
The ReqIF Server respects the relevant standards of Java Enterprise Edition to allow for a wide range of configurations and platforms.
|The most simple way to use the ReqIF Server is in an installation within a combined HTTP-Server and Servlet-Container, such as Apache Tomcat.||To improve performance at higher loads, an HTTP-Server may hand requests to a separate Servlet-Container or even distribute requests to several ones installed in parallel. Again, Apache Tomcat is a popular choice in this case.||In an enterprise environment the ReqIF Server is typically installed on a cluster of Application Servers such as Glassfish or JBoss, while the user requests are handled by Web-UIs in a Servlet-Container or by Portlets in a Web-Portal. Various technologies exist to implement Web-UIs and Portlets.|
Model-Driven Software Development
The ReqIF Server is being developed with model driven methods (MDD). The execution platform is the proven and tested business object framework orchideo|objects by eXXcellent solutions GmbH, Ulm. It maps the business objects to database tables and is responsible for persistence, data quality, logging and similar base services.
The RIF/ReqIF Schema, as standardized and provided by the Object Management Group (OMG), drives code-generators creating an exactly matching transaction engine with object versioning and access control. It establishes a common meta-model for requirement-management and system specifications. The meta-model is equally suited for business process models (BPNM or other standards) and system maps.
At runtime, the RIF/ReqIF Data holds both the object types and instances of the particular project. The object types are a model of a particular system specification - typical examples are 'Requirement', 'System Component' and 'Process Step'. Also, the relationship types between object types, such as 'depends-on" or "realizes" are defined. The object and the relationship instances finally are the concrete project data.
In most traditional systems, the model is hard-coded, wheras RIF/ReqIF and the ReqIF Server offer a dynamic data model for system specifications. The ReqIF Views and the Web-Services are also dynamically built from the RIF/ReqIF data. Thus, a new object type can be defined or another attribute can be added to an object at runtime.
The advantages of the approach are:
- 100% compatibility with the RIF/ReqIF standard.
- Dynamic data model significantly shortens the time to set-up a new application or project.
- Systematic, model-driven approach assures that all objects and relations behave alike.
- Application structure (model) comes with the data → „zero-setup“.
The ReqIF Server is both a versatile and easy-to-use software product based on open standards. Being built using model-driven-software-development methods, it is of exceptionally high quality. The ReqIF Server is being developed and licensed by eXXcellent solutions GmbH, Ulm.