Reference models in form of best practices are an essential element to ensured knowledge as design for reuse. Popular modeling approaches do not ofer mechanisms to embed reference models in a supporting way, let alone a repository of it. Therefore, it is hardly possible to profit from this expertise. The problem is that the reference models are not described formally enough to be helpful in developing solutions. Consequently, the challenge is about the process, how a user can be supported in designing dedicated solutions assisted by reference models. In this paper, we present a generic approach for the formal description of reference models using semantic technologies and their application. Our modeling assistant allows the construction of solution models using diferent techniques based on reference building blocks. This environment enables the subsequent verification of the developed designs against the reference models for conformity. Therefore, our reference modeling assistant highlights the interdependency. The application of these techniques contributes to the formalization of requirements and finally to quality assurance in context of maturity model. It is possible to use multiple reference models in context of system of system designs. The approach is evaluated in industrial area and it can be integrated into diferent modeling landscapes.
Reference models (RM) are used in many areas today and are becoming more and more popular.
The complexity of systems and their increasing interconnection require a high degree of
knowledge from various areas. Only a structured processing of this knowledge as well as
the consequent further development of this enables rapid technological progress. Thus, most
companies business initially rely on structures and processes that have proven themselves in
general, and later continuously adapt them to their needs. These generally accepted facts can be
called RM and can be found almost everywhere, also in collections [
The use of RM provides several advantages for organizations. One example is the service
of federated identity management [
RM are characterized by universality and reusability within its scope. The typical process of reuse consists of the adaptation, adoption and extension of the models, and difers depending on the design technique. Popular techniques are here for example the construction by configuration or the use of RM by aggregation.
It is not always easy to find the right RM for the specific application context. Sometimes models are constructed by using several RM, each of which describes only a partial aspect. In this case the term Building Blocks is usually used. After the construction of the solution model, another challenge is the comparison with the RM. It should not only be used as a modeling aid, but also for quality assurance and compatibility. Therefore, it must be traceable to what extent the recommendations of the RM have been implemented.
Such mechanisms are typically not found in commonly used modeling languages and
supporting tools for enterprise description, but some approaches based on ontologies respectively
knowledge graphs already exist [
In this paper we present a generic approach for the formal description of RM that can be integrated into diferent modeling landscapes. Our reference modeling assistant allows the construction of application models using diferent techniques and checks the resulting solutions against the RM for conformity. Thus, it combines best practices of reference modeling and ensures sustainability. The application of these techniques contributes to the formalization of requirements and finally to quality assurance in modeling.
The challenges of using RM is illustrated by a simplified example from the automotive industry. We design a RM for the development of vehicles. Similar configuration tools can be found on most of the car manufacturers’ websites, allowing customers to customize their new vehicle. Our RM in this scenario contains the following statements, which should apply to every vehicle (regardless of whether the statements are actually correct): 1. Each car has 4 wheels. 2. A vehicle has an automatic or manual transmission. 3. The car has at least one engine. It can have one combustion engine that runs on diesel, petrol or gas. In addition, it can be equipped with an electric motor (hybrid car) or it can be powered exclusively by one or more electric motors. 4. If the car is equipped with a combustion engine, it needs a fuel tank, and if it has an electric motor, it needs a battery to store energy. 5. Vehicles with electric motors can only be configured with automatic transmission.
Figure 1 shows an example visualization of the RM with its main components as an UML diagram. This RM can be described as an abstract configuration model in which the user can choose only between these elements. This model can be further enriched with instances for these classes, where a specific selection of such a component is possible. The challenge is now the application of this RM by the user, who wants to model a new vehicle based on these specified building blocks. The question arises how to ensure that all rules of the RM are followed during modeling. In addition, it must be checked which model aspects are relevant for the user and whether there exist already other solutions from this area that the user could use.
It is noticeable that the RM does not contain all the requirements described above.
Conditions 4 and 5 are not illustrated, but only described in text form. Even if these could have
been formulated in UML, it is often not described formally enough to be supported within
the modeling. Constraints are mostly supplemented by textual descriptions (e.g. automated
processing). Furthermore, the question arises how the RM can actually support the user in the
design of new models. Usually, the process of reuse consists of taking the results of a RM and
then being able to modify and extend them [
The lack of support in the application of RM has several reasons. The multitude of
heterogeneous modeling tools and languages makes it dificult to implement a universal approach. In
addition, there are diferent ways of using RM. Besides strongly restrictive techniques such as
configuration, the instantiation or placeholder technique allows for example some degrees of
freedom in the application [
Such problems lead to the fact that overarching RM are not formally described, but rather in natural language in the form of guidelines and illustrations. It is left to the user to interpret the contents correctly and to implement them in his modeling environment. In the end, it lacks user support for the use of the RM as well as verification mechanisms to ensure the correctness of the solution model.
One of the most popular languages for defining constraints for models is the Object Constraint
Language (OCL) [
The book [
Another possibility to realize content-specific restrictions is the development of a Domain Specific Language (DSL) . Tools such as MetaEdit+3 or ADOxx4 allow the addition of rules, which can create restrictions for the construction of the models. However, this approach is based on meta-modeling and is not comparable to the concept of reference modeling. Our considered problem requires the RM and the solution model in parallel at equivalent levels with a common metamodel.
In the field of process modeling, aggregation and hierarchy are common techniques for reusing RM. For example, the modeling languages ARIS and BPMN ofer the possibility to model processes that are referenced in other models by using only one aggregated element as inheritance that contains the corresponding process logic. Various process management and
workflow systems such as [
This work [
The approaches [
Specific instances of RM can be made via a configuration [
Further construction techniques as surveyed in [
In this section, we describe our generic approach to constrained-based design of RM. We show how requirements can be formalized and how solution models can be derived from RM and checked against them. Our approach is based on a closed world view to obtain a structural and functional connection.
An overview of the general principles is shown in Figure 2. The concept is to represent the
RM and the associated solution models using the Resource Description Framework (RDF) [
In this first stage, we form the basic structure of a RM. It consists of the creation of a RDF graph
with the elements, connectors and attributes relevant for the RM. We further use the vocabulary
of RDF-Schema (RDFS) [
For such a mapping, we have used a basic metamodel with essential concepts, which should be valid for most modeling languages. Thus, a model consists of a set of elements that have properties and are connected to each other via connectors. For the specification of a schema elements of the type "Class" are used, which can be related by means of the relation "subClassOf". Classes are used to represent the reference model. Derived solution models or single solution modules are described with the help of instances, which in turn are typed with classes of the RM. A representation of the metamodel as a UML profile is shown in Figure 3.
For each RM a graph needs to be created first. A URI node is automatically generated for each element contained in it. Each connector is also represented by a URI node. Furthermore, it is defined as a property in an RDF triple, which relates the source and target node. Element and connector attributes are created as RDF literals and assigned by triples to the corresponding nodes. Especially for the context of reference modeling, the elements are now distinguished into classes and instances. Classes can be hierarchically related via the subclass relationship and instances can be typed with classes. This distinction is common in the design of ontologies and helps us to diferentiate between abstract placeholders and concrete configuration elements in reference modeling. A hierarchical arrangement for properties is also possible. Optionally source and target elements of the relations can be defined using rdfs:domain and rdfs:range.
If the graph is generated from an existing model as in our example, it has to be defined individually how the distinction between classes and individuals is detected. This can be done by using certain annotations on the model. For our example we use the standard UML relation “instantiate” to recognize individuals and “generalization” to build a taxonomy using rdfs:subClassOf.
Each element and connector has a URI by which they can be identified. The attributes can be defined as RDF literals. A section of the resulting taxonomy from our vehicle example is shown in Figure 4, implemented with the tool Protegé. This also shows that the RM can already contain concrete instances for the diferent classes, which can be used for the configuration of the solution. In this example two types of diesel engines exist.
The second step is to define the constraints. A distinction is made between structural and valuebased constraints. Structural constraints refer to the existence of certain elements, relationships and attributes. Complex model relationships across several elements can thereby also be expressed as conditions. An example for a structural constraint could be: ’Each car requires at least one engine.’ The conditions described in our example are all structural constraints.
Value-based constraints, on the other hand, refer to specific attributes of elements and
connectors. An example could be: ’The sum of the weight of all car components must not
exceed 2.500 kg’. This is also used to ensure appropriate interfaces between elements. It is in
line with the general reference modeling methodology for building blocks and pattern [
Both types of constraints are achieved by comparing values obtained by SPARQL queries from the solution model. For structural requirements a number of existing elements or paths is usually determined. This can be done with aggregation functions like COUNT, GROUP BY and HAVING. The example from Listing 1 defines the condition described above for all vehicles. To shorten the example, we omit the definition of prefixes for the queries.
/ / g e t a l l c a r s q1 = SELECT DISTINCT ( COUNT ( ? c a r ) a s ? C a r s ) WHERE { ? c a r r d f : t y p e ex : Car } / / c a r s w i t h a t l e a s t o n e e n g i n e q2 = SELECT ? c a r WHERE { ? c a r r d f : t y p e ex : Car . ? e n g i n e a ex : e n g i n e .
? c a r ? c o n n e c t i o n ? e n g i n e . } GROUP BY ? c a r HAVING ( COUNT ( ? e n g i n e ) >= 1 ) / / r e q u i r e m e n t : ’ E a c h c a r h a s a t l e a s t o n e e n g i n e ’ r 1 : q1 = q2
There are a variety of diferent conditions that can be specified for a model. To express constraints, we have developed a specific grammar. An example is shown in Listing 2. It allows to link several conditions in a logical expression, so that complex constraints can be created based on the requests. Besides using query results, static values can also be used. Furthermore, it is possible to make calculations based on the values and then evaluate them within a constrained. This may be necessary for complex systems, where a large number of parameters influence the configuration of a solution model and possibly the optimal solution for a problem is searched for. Finally, every constraint returns the value ’true’ or ’false’.
The solution model is created using the reference ontology. For later verification with the RM and the constraints, it is important that there is a link between the reference and the solution. For this purpose, an ontology is created which contains the constructed model in the form of instances. First, it uses the instances that were specified by the RM itself. For all newly created instances it is mandatory to assign the corresponding classes from the reference ontology to sustain the connection.
R e q u i r e m e n t : : = ’ Not ’ ( R e q u i r e m e n t | S p a r q l Q u e r y _ A s k ) | R e q u i r e m e n t L o g i c a l E x p r e s s i o n R e q u i r e m e n t |
C o m p a r i s o n F u n c t i o n L o g i c a l E x p r e s s i o n : : =
’AND’ | ’OR ’ | ’XOR ’ | ’ − > ’ C o m p a r i s o n F u n c t i o n : : =
V a l u e R e l a t i o n a l O p e r a t o r V a l u e R e l a t i o n a l O p e r a t o r : : =
’ < ’ | ’ < = ’ | ’ = ’ | ’ > = ’ | ’ > ’ | ’ ! = ’ V a l u e : : =
F i x e d V a l u e | C a l c u l a t i o n | S p a r q l Q u e r y . . .
COUNT: all cars 1 COUNT: cars with 4 wheels 1 COUNT: cars with 1 transmission gear 1 ASK: transmission is a manual and an au- false tomatic transmission ASK: cars with less than one engine false ASK: cars with more than one combustion false engine COUNT: cars with at least one combustion 1 engine COUNT: cars with at least one electric en- 1 gine COUNT: cars with a combustion engine 1 and a fuel tank COUNT: cars with an electric engine and 0 a battery COUNT: cars with an electric engine and 0 a automatic transmission 4.4. Model Verification and Validation The final step of our approach includes the verification of the solution model based on the constraints associated with the RM. This verification is performed on the RDF representations of the models. An aligned ontology is generated by merging the reference ontology and the solution. Using an RDFS reasoner, the knowledge resulting from the transitivity of the subclass relationship is inferred. This ensures that instances of a subclass are also instances of the superordinate classes.
Finally, the constraints are verified. Therefore, the defined queries are executed on the merged ontology and the results are evaluated accordingly. The result is a listing of all conditions with their corresponding truth values and the retrieved values.
For our RM, 11 queries were formulated. The queries and the requirements defined in Section 2 would be evaluated as shown in Table 1.
For the validation of our concept we designed a prototype as a standalone application in C#,
called Reference Modeling Assistant (RMA). Figure 6 shows an overview of the diferent RM.
Besides the name and the description, it is possible to assign tags to the models in order to
facilitate the search for suitable models [
With RMA it is possible to create simple ontologies using dotNETRDF 5, an open source .NET library for working with RDF triples. An import of existing rdf or owl files is possible as well.
Once the RM have been constructed, a solution model can be created on their basis or an existing model can be validated against them. Figure 7 shows the Solution Builder. On the left side it displays the taxonomy with the classes of the RM and below the related instances. The other two tabs give a choice for the available relations and attributes.
The middle column shows the created solution model, as we already know it from Figure 5. Depending on which tab is selected, the respective items can be added, removed and edited.
On the right side the constraints of the RM are shown. These are validated directly when the solution is changed. We see the queries listed in Table 1 with their results and the constraints constructed from them. The tree view shows the nesting of the logical statements. A constrained is fulfilled when its upper node is displayed in green. Unfulfilled constraints (4 and 5) are shown in red and queries which only returned values are shown in grey.
On the upper level, this representation allows a quick check of the extent to which a solution conforms to the constraints of a RM. On the lower levels, the details of a query can be analyzed and appropriate corrections can be made to the model.
The result can be exported from the RMA as RDF file. Afterwards, the content can be integrated into the individual modeling environment via transformation.
To demonstrate this step, we have developed an Add-In for the modeling tool Sparx Enterprise Architect (EA). This allows the conversion of EA models as shown in Figure 1 and 5 to RDF models and vice versa.
With the representation of the RM as an ontology a cross-language provision of a semantically enriched vocabulary is achieved. The concepts and instances described within can be used to generate multiple solution models across diferent modeling languages. It has been observed that the form of the constraints is strongly coupled to the modeling language and frameworks used.
The formalization of a RM requires some efort. This is usually only profitable if the RM is reused often enough like in our example, where RMs are used to configure multiple vehicles. Hence, the use of this approach is especially suitable for recurring modeling tasks and for those where high demands are made on model verification.
In this paper, we presented a reference model design methodology. It begins with requirements engineering using RDF. In the process, it ofers diferent possibilities to formal describe specific conditions. The reference models can be described and formalized into an ontology. This reference design is used for the development of solution models. For this purpose, diferent building blocks are ofered. In particular, various methods can be used to derive a specific solution from the reference design. The process of reuse consists beside others of the adaptation, adoption and extension of the reference building blocks. We have taken best practices into account and embedded them in a process with formalization. Finally, our approach enables the subsequent verification and validation of the developed designs against the reference models for conformity. Our reference modeling assistant highlight the interdependency. Thus, it finally contributes to compatibility between designs and quality assurance in context of maturity model.
In the future, we will establish a more integrated tool chain for the usability of reference models. Beside this, we are working on a structured repository of reference models and their easy retrieval as well as adaptability. Nevertheless, we will establish our approach in the context of system of system designs.