Visual Software Modeling with Rules
In the last decades visual design methods have been gaining popularity and importance in Software Engineering. When it comes to practical software design, UML is de facto the standard for modeling software applications. Today, UML diagrams are typically not detailed enough to describe every aspect of the modeled system. This chapter concerns practical design issues of rule-based models integrated with business applications built using the Model-View-Controller architectural pattern and designed in UML. The main idea consists in the introduction of a visual UML representation for business rules modeling the application logic. A complete bidirectional translation between XTT and the UML representation is presented. It preserves the semantics of XTT in an UML-friendly fashion, allowing UML designers to approach the XTT-based rule logic model in a unified way. The implementation of practical translators is described, and the evaluation of this approach is given.
In the last decades visual design methods have been gaining popularity and importance in SE (Software Engineering)  as a mean of coping with the increasing complexity of software. Nowadays, visual modeling has become an essential part of the design in the SE processes. When it comes to practical software design, Unified Modeling Language (UML)  is de facto the standard for modeling software applications . UML attempts to be a universal visual notation for software design. Although the semantics of UML 2.0 is more precise than the one of UML 1.5, there are still many ambiguities. There is ongoing research, on precising, extending or redefining the UML semantics to overcome its limitations. Today, UML diagrams are typically not detailed enough to describe every aspect of the modeled system. Moreover, there are concepts e.g. constraints, which cannot be expressed in pure UML. A complete system model requires the use of the Object Constraint Language (OCL)  to provide consistency of the design. OCL is a formal language, which has been developed in order to avoid ambiguous constraint expressions. OCL syntax is a simple, textual notation whereas UML is a visual one.
This chapter concerns practical design issues of rule-based models integrated with business applications built using the Model-View-Controller (MVC)  architectural pattern and designed in UML. In Sect. 11.1, the detailed motivation for the research aimed at applying Semantic Knowledge Engineering in the field of SE is given. The main idea consists in the introduction of a visual UML representation for business rules modeling the application logic. The representation is based on XTT2. A translation from the ARD+ model is discussed in Sect. 11.2. A complete bidirectional translation between XTT2 and the UML representation is also presented. The translation preserves the semantics of XTT2 in a UML-friendly fashion, allowing UML designers to approach the XTT2-based rule logic model in a unified way. The implementation of practical translators is described in Sect. 11.3. The evaluation of this approach, using a practical example is presented in Sect. 11.4. The chapter ends with a summary and directions for future works in Sect. 11.5.
11.1 Integration of Rules with UML Design
The presented rule-based approach has several important features namely that the core logic of the application (the model) is clearly identified and separated. Moreover, it is built in a declarative way, which makes the design transparent and easier to follow, develop and update in the case of changing user requirements (which is often the case in real-life projects). Thanks to these features the approach increases the agility of the design process.
In the approach considered in this research the application is designed in the MVC design pattern and the model is designed with the use of Business Rules. The remaining parts of the application (Views and Controllers) including its interfaces are usually designed using UML. In this approach, the core logic of the application (Model) is clearly identified and separated. Moreover, it is built in a declarative way, which makes the design transparent, easier to follow and develop.
This approach has number of qualities. However, its practical application faces three important challenges: (A) the rule visualization problem, (B) the design representation mismatch, and (C) the model quality assurance problem.
The first problem concerns the fact that in the BR approach rules are captured using a textual notation, with no visualization. This limitation becomes a major obstacle once the number of rules grows, and dependencies between them become complex. Such a design specification is also incompatible with the visual nature of UML.
The second issue is related to the fact that concepts on which the rule representation is based cannot be directly modeled using UML constructs. In fact, the extended semantics of UML 2.0 diagram types does not directly corresponds to rule semantics. There is no UML diagram to model rules and there is no direct way to relate the rule-based model to the object-oriented one. In classic software engineering practice, both analytics and programmers use UML to specify and document the project. When some parts of the application are designed in a different way communication problems may occur.
The last challenge consists in providing effective verification techniques for the rule-based application logic. While in the software industry there are numerous methods and techniques aiming at providing certain quality assurance of software (mainly based on software verification and validation through testing, code review, etc. [6, 7]), they cannot be directly applied to a rule-based model. On the other hand, in the area of classic RBS a number of well-defined formalized verification methods exist. The use of these methods should be made available during the design process of RBS by some practical tools.
using an expressive visual rule design formalism (XTT2) (addresses problem A),
defining a direct translation between XTT2 and selected UML diagrams (addresses problem B),
implementing practical translators between the logical XTT2 model and the MOF-based (Meta-Object Facility)  UML model,
using verification features provided with the XTT2 framework to assure the quality of the rule base (addresses problem C).
It is important to emphasize that the proposed approach is not about modeling the whole application using rules. The semantics of a rule-based paradigm does not match the methods and tools of SE. Nevertheless, RBS logic specification can be complementary to the higher level specification of the system in SE . Moreover, this approach must not be confused with ideas to use the OCL to provide the consistency of the UML design. OCL is a formal language, which has been developed in order to avoid ambiguous constraint expressions. It aims at precising existing UML models whereas the approach presented here aims at modeling certain parts of the application for which existing UML diagrams are not suitable. This research considers a method of designing rule bases, which will be proper and consistent with UML. In order to provide the background for the work presented in this chapter, some important research areas were presented in Sect. 3.5. There, we discussed selected UML-based visual methods of rule representation, and on selected UML formalization attempts as well as methods of quality maintenance.
11.2 Representation of ARD+ and XTT2 with UML Diagrams
Expressing the ARD+ Model with UML Class Diagrams
In UML, classes describe sets of objects sharing the same specifications of features, constraints, and semantics. Attributes are one of class features. This also applies to properties in ARD+ which are described by attributes. According to the UML Superstructure , the purpose of classes is to specify: a classification of objects, and features that characterize the structure and behavior of these objects. Because ARD+ does not describe the behavior, there is no need to use operations in the UML representation of ARD+.
class corresponds to the simple property in ARD+,
abstract class with attributes corresponds to ARD+ complex property,
«derive» dependency corresponds to ARD+ dependency between attributes,
«refine» dependency corresponds to ARD+ finalization transformation,
aggregation corresponds to ARD+ split transformation.
Figure 11.1 shows an example of a simple ARD+ diagram and its UML representation. The corresponding representation of a TPH diagram is shown in Fig. 11.2. The interpretation of ARD+ is as follows: the property CashPointActivity can be derived from UserRequestedAction and ActionEnvironment. The TPH model shows the history of transformations: CashPoint is finalized into three properties UserRequestedAction, ActionEnvironment, and CashPointActivity. Then a split is made – a complex property is separated into two properties and a dependency between them is identified.
The proposed UML model is similar to the original ARD+. It is transparent and intuitive. This approach does not introduce custom elements, only standard UML artifacts are used.
Regarding the relations between the artifacts, UML is a much richer language than ARD+. There are some relationships which can be observed in ARD, but they are not distinguished. The first not distinguished relation is the relation of realization. If a conceptual attribute is finalized to a physical attribute, this is a quite different case than if it is finalized to some other conceptual attribute or attributes. The first case is an example of realization. It is so, because the physical attribute realizes the concept of the conceptual attribute. The second one is an example of some refinement.
The second relation which is not distinguished is a «trace» dependency. A trace relationship among model elements can be used in a TPH diagram to show elements representing the same concept at different levels of the design.
Metamodel of the ARD+ Model
There is a need to define a separate metamodel for TPH diagrams, based on the previous metamodel. Figure 11.4 shows the metamodel of the UML representation for TPH diagrams. The representation uses UML classes (with or without attributes), aggregations and the «refine» dependencies. This metamodel also requires some OCL constraints to specify the exact syntax of the TPH representation. All OCL expressions from the ARD+ metamodel are valid for the TPH metamodel (see  for details).
XTT2 Model with UML Activity Diagrams
In the XTT2 representation rules working in the same context (having the same attributes) are grouped in decision tables. Therefore, the fundamental issue for modeling XTT2 in UML is the representation of an XTT2 table (unit). The UML Superstructure Specification version 2.2  introduced in Appedix E the so-called Tabular Notation for Sequence Diagrams. However, it is not a representation of any custom table. It is rather a serialization of a Sequence Diagram to the tabular form, which can not be used for representing any XTT2 table in particular. A representation of such a table should use one of the behavior diagrams, such as a Use Case Diagram, an Activity Diagram or a State Machine Diagram, as well as one of the Diagrams of Interaction (a Sequence or Collaboration Diagram).
According to the discussion presented in  State Machine Diagrams and Activity Diagrams seem to be the best UML candidates for rule modeling. A State Machine Diagram shows the possible states of the object and the transitions that cause a change in the state. It focuses on an object undergoing a process (or on a process such as an object). The Activity Diagram, in turn, focuses on the flow of activities involved in a single process and shows the dependencies among them. Several preliminary approaches of such UML models of XTT2 have been presented in the technical report . Such a representation is not as expressive as XTT2. Especially, in the case of larger systems with a huge number of rules, using UML poses practical problems. However, it is possible to use it to express rules in the case of smaller systems.
Activity Parameter – the parameter representing an XTT2 attribute,
Action – sets the value of the output parameter,
Decision Node – enables checking the distinct values of the input parameter,
Merge Node – corresponds to logical or operation for flows,
Fork Node – enables to branch out and manifold the flow, and
Join Node – corresponds to logical and operation for flows.
The exemplary XTT2 table
\(\rightarrow \) tab2
\(\rightarrow \) tab2
\(\rightarrow \) tab3
Metamodel of the XTT2 Model
The metamodel does not enforce the order of nodes. It can be observed in the metamodel that it allows for generating models which do not match the XTT2 ones. The required order of nodes for the XTT2 model at the lower abstraction level is as follows (nodes which can occur optional are in brackets):
Activity Parameter Node \(\rightarrow \) Decision Node \(\rightarrow \) (Fork Node) \(\rightarrow \) Join Node 1 \(\rightarrow \) Fork Node 2 \(\rightarrow \) (Merge Node) \(\rightarrow \) Action \(\rightarrow \) (Merge Node) \(\rightarrow \) Activity Parameter Node.
At the higher abstraction level, the required order of nodes for the XTT2 model differs from the one stated above and is as follows:
Activity Parameter Node \(\rightarrow \) (Fork Node) \(\rightarrow \) X (Join Node) \(\rightarrow \) Action \(\rightarrow \) ((Decision Node) 3 \(\rightarrow \) back to X) \(\rightarrow \) (Fork Node) \(\rightarrow \) Activity Parameter Node.
The UML representation of XTT2 can be serialized to the XML-based XMI format.4 With it, it is possible to define practical model translations.
11.3 Selected Model Translations
XML Metadata Interchange (XMI)  is an XML-based OMG standard for exchanging metadata information. Although it can be used to represent any model or meta-model which is MOF compliant, it is mostly applied to encode UML models for model exchange between various tools. There is a variety of XMI formats and many UML tools store models in XMI using their own tool-specific XMI format. Moreover, the XMI Specification  does not define XML tags for every UML artifact, but specifies how to create them for the metamodel concepts.
For the purpose of the implementation the newest XMI 2.1 version has been adapted. This version is supported by several UML tools (e.g. Altova UModel,5 Visual Paradigm for UML 6). A detailed description of the XMI tags that represent UML artifacts can be found in . Although XMI is predominantly used to exchange model data between different UML tools , in this case it is considered as a format for serializing models for further translation and code generation.
The UML representation of XTT2 is serialized to the XMI file and the XTT2 model is stored in the HML file. Because both are XML compliant, the implementation of the proposed translation algorithms is done with the use of XSLT. Although there are some disadvantages of using XSLT (such as poor readability or poor error reporting), among various methods, XSLT is recommended for a couple reasons [17, 18]. It should be used when both source and target formats are XML-based and there is a need for matching elements from the source document with using its structure and associating them with the target document structure. But the key advantage of using XSLT is that there are many XSLT engines available. Algorithms used for the implementation of these translators are presented next.
Translation from XMI to ARD+
Every class without attributes becomes an ARD+ simple property.
Every abstract class becomes an ARD+ complex property.
Every «derive» dependency becomes an ARD+ dependency.
Every «refine» dependency becomes an ARD+ finalization.
Every aggregation becomes a part of an ARD+ split.
Every ARD+ property becomes a class with attributes (for complex property) or without (for simple property).
Every ARD+ dependency becomes a «derive» XMI dependency.
Every ARD+ finalization becomes the «refine» XMI dependency.
Every ARD+ split becomes an XMI aggregation.
Name of the table is saved.
Activity Parameter Nodes become attributes of the table.
- 3.In order to transform the rules, there is a need to simplify the representation. This can be done in the following way (the process is illustrated in Fig. 11.12):
For every input Activity Parameter Node, its id is stored in the ref attribute of the following Decision Node and the Parameter Node is removed.
For every Object Flow with the source in a Fork Node, the source of the incoming edge of the node becomes the source of the Object Flow (with nested guard element preserved) and the Fork Node is removed.
For every Object Flow of which a target element is a Merge Node, the target of the Merge Node becomes a target of the Object Flow, and the Merge Node is removed.
For every output Activity Parameter Node, its id is stored in the ref attribute of the precedent Action Node, and the Parameter Node is removed.
After the simplification of the model, it is much easier to transform the UML representation of the rules to HML.
- 4.1If there is more than one input Activity Parameter Join Nodes become rule elements in the following way. For every Join Node:
Every guard value in the incoming edges to the Join Node becomes the expression in the condition part for the proper rule attribute.
Every action name in the outgoing edge of the Join Node becomes the expression in the decision part for the proper rule attribute.
- 4.2.If there is only one input Activity Parameter, Object Flows which have the source in the Decision Node become rule elements in the following way:
Every guard value in the flow becomes the expression in the condition part for the proper rule attribute.
Every action name in the outgoing edge of the Join Node becomes the expression in the decision part for the proper rule attribute.
- 5.In order to simplify the transformation, there is a need to simplify the network of tables representation. This is done in the following way (the process is illustrated in Fig. 11.13):
For every Object Flow of which a target element is a Join Node, a target of the outcoming edge of the Join Node becomes the target of the Object Flow, and the Join Node is removed.
For every Object Flow which has its source in a Decision Node the source of the incoming edge of the Decision Node becomes the source of the Object Flow (a nested guard element is preserved), and the Decision Node is removed.
- 6.Following the simplification of the model, translation is straightforward. For every Action:
without Output Pin, the id of the following table is set as the transition target for every rule in the table.
with Output Pin, the id of the following tables are set as the transition targets for proper rules in the table, according to the guard in the Object Flow.
Next, the reversed algorithm is described.
Translation from XTT2 to XMI
All condition attributes become input Activity Parameter Nodes and decision attributes become output Activity Parameter Nodes.
- 2.For each condition attribute (input Activity Parameter Node) the Object Flow goes to a decision node and for each unique value of the attribute:
The Object Flow with this unique value as a Guard condition is introduced,
If the value occurs frequently, the flow is finished with a Fork Node.
- 3.If there is more than one condition attribute, for each XTT2 rule a Join Node is created, and:
For each condition attribute the proper Object Flow is connected to the Join Node (if the value of the considered condition attribute occurs frequently, the flow starts from the proper Fork Node),
- 3.2.Depending on the number of decision attributes:
If there is only one decision attribute: the proper Object Flow starts from the Join Node and is connected to the Action having a value corresponding to the decision attribute (if the value of the decision attribute occurs in the table more than once, a Merge Node is introduced and the connection is through this Merge Node),
Otherwise: a Fork Node is introduced and the Object Flow from the Join Node to this Fork Node is created.
- 4.If there is more than one decision attribute, from each Fork Node (corresponding to XTT2 rule) for each decision attribute the proper Object Flow from the Fork Node is introduced and connected to:
The proper Merge Node, if the value of the decision attribute occurs in the table more than once (if the proper Merge Node does not exist yet, it should be introduced). Then, the Object Flow from the Merge Node is introduced and connected to:
The Action (having a value corresponding to the value of the decision attribute in the rule).
For every decision attribute, outputs of Actions (having the values of particular attribute) are connected to a Merge Node and an Object Flow from the Merge Node leads to the corresponding output Activity Parameter Node.
For every XTT2 input and output system attributes, corresponding input and output Activity Parameter Nodes are created.
- 2.For every XTT2 table, the CallBehaviorAction is created, and:
if more than one table has the link to this table, a Join Node is created and the proper Object Flows from those tables to the Join Node are created,
if only one table has the link to this table, an Object Flow from that table to this table is created,
if the condition attribute of this table is the input system attribute, the Object Flow from the corresponding Activity Parameter Node to this table is created (if the attribute is the condition attribute in more than one table, a Fork Node is introduced and the connection is through this Fork Node).
- 3.For every output Activity Parameter Node an Object Flow from the proper CallBehaviorAction is created, according to the decision attributes of the XTT2 tables, and:
if the attribute is the decision attribute in more than one table, a Join Node is introduced and the connection is through this Join Node,
if it is not the only one decision attribute in the table, a Fork Node is introduced and the connection is through this Fork Node.
The application of translators is demonstrated next.
11.4 Evaluation Using a Case Study
To evaluate the discussed approach the Cashpoint system is used. The BL is modeled with rules represented in XTT2. Then, the UML representation is given for this model. Finally, the UML design for the user interface (View) and the Controller connecting it with the Model is given.
There is also a possibility of translating backwards, from the UML model to the XTT2 model. In this case, the UML model has to be defined and designed in a UML tool, which enables the generation of the XMI code. The model serialized to XMI can be translated using the UML2XTT2 XSLT translator to the HML representation, which allows for refining the design in HQEd and verification with HeaRT.
It can be observed that this benchmark case study has 11 rules, from which 6 constitute the final decision table. To show the quantitative difference between compared notations, one can observe that the final XTT2 decision table (cashPointActivityDetermining) has 6 rules and 6 attributes. This makes 36 cells with values in the decision table to fill in. In the presented UML model there is no redundancy of attribute values, therefore there is only 21 various values to fill in. It is worth noting that in textual notations, such as OCL, this would require the use of every 36 values and writing separate rules.
Evaluation of the Translation
The proposed UML model for rules is MOF compliant. It does not introduce any custom element, but uses only standard UML artifacts. This allows a user to use any of the existing UML tools, which supports model exporting to XMI. Although the model is not similar to the original XTT2, it shall be intuitive when one knows either the UML Activity Diagram semantics or the electronic logical gates (which perform the logical operations on logic inputs and produce a logic output).
This representation, as all solutions mentioned earlier, does not scale well. When the number of rules in the XTT2 table grows, the diagram becomes poorly readable. Due to the fact that visual rule representation faces the problem of scalability, in this field there is still space for new research. Although there exist methods for designing single rules, designing rule groups constitutes a problem. Groups of similar rules often can be modeled as a decision table and if it comes to readability, tables seem to be irreplaceable. Hence, they are so widely used in Knowledge Engineering.
It uses only standard UML elements, so any UML tool (that supports XMI generation) can be used for modeling the system.
In the model there is no redundancy of attribute values as it is in the XTT2 table.
The model transparently shows inputs and outputs of the system.
Decomposition of the rule base is provided through a bi-level hierarchy of diagrams in the model. The lower level model for the visual design of the rule set and the higher level model which stores the knowledge about control. This allows for the creation of more complex XTT2 trees, without the risk of losing readability and to ensure the efficiency of the system.
It should also be pointed out that the UML representation for XTT2 seems to be more useful when the rule-based logic is designed with XTT2 and then translated to UML. The reverse translation (from UML to XTT2) is also fully possible. However, it seems to be less useful in a practical design, because the semantics of XTT2 speeds up the rule design process. On the other hand, it could prove valuable in cases where there are some existing Business Logic models in UML the Activity Diagrams.
The entire design process is based on UML, including the specification of application logic. Because of the direct translation between XTT2 and UML representation, and the possibility of automatic logic implementation, the problem of design representation mismatch is also addressed. The proposed UML representation uses only standard UML artifacts and allows for representing the whole decision tables, not just single rules like in the case of URML. Its weakness is the visual scalability issue – the size of the activity diagrams grows with the size of the decision tables. On the other hand, this follows the limitations of the diagrams provided with UML 2.0.
Finally, because the rule model is expressed in a formal way, the SKE methodology provides an online verification of the model, thus dealing with the quality assurance problem. The provided verification checks are optimized for the rule representation. Since the XSLT model translation preserves the semantics, it does not alter any formal properties of the model. Thus, the obtained UML model preserves the previously verified formal properties.
The focus of the chapter is on the visual methods for designing software with knowledge-based components. The assumption is made that the UML-based representation should capture the whole system design. On the other hand, the core parts of the Business Logic could be designed in an optimal way using the Business Rules approach. In fact, it has been a common approach in recent years. However, the approach has several important limitations concerning an appropriate visual design specification for Business Rules. Such a representation should be semantically compatible with UML, while keeping all the qualities of the rule-based Model. At the same time the quality issues of the resulting hybrid Model should be considered as well as the appropriate knowledge integration problems addressed.
The proposed solution to these problems uses the XTT2 rule representation to design the application core logic. This logic is integrated with the remaining parts of the application using the MVC architectural pattern. Moreover, the XTT2 rule design can be translated to a corresponding visual UML Model. Simultaneously, formal properties of the designed Business Rules logic can be verified. In the presented rule-based approach the core logic of the application (the Model) is clearly identified and separated. The Model is built in a declarative way, which makes the design transparent, easier to follow, and update in the case of changing user requirements. Thanks to these features the approach increases the agility of the design process.
Based on the evaluation presented in this chapter, it can be observed that this solution is superior both to existing visual rule notations, as well as visual design tools for rules. It does not introduce any custom UML artifacts and can be used with standard UML tools. The resulting UML design can be analyzed by software designers familiar with UML. On the other hand, it can be easily refined by application architects using Business Rules semantics.
Currently, the Business Logic Model can be integrated with application interfaces that use the SKE framework. In this case the Business Logic is executed by HeaRT and linked with the interfaces on the runtime. Future works include possible generation of object-oriented code from the resulting UML Model. In this case, the complete application would be implemented in the same programming language (e.g. Java).
Element occurs when there is more than one input Activity Parameter node.
Element occurs when there is more than one output Activity Parameter node or there is the transition parameter node (which enables the transition to different tables).
Element occurs when previous Action has Output Pin.
- 2.OMG: Unified Modeling Language version 2.1.2. infrastructure. specification. Technical Report formal/2007-11-04, Object Management Group, November 2007. http://www.omg.org/cgi-bin/doc?formal/2007-11-04.pdf
- 3.Hunt, J.: Guide to the Unified Process Featuring UML. Java and design patterns. Springer, Berlin (2003)Google Scholar
- 4.Object Management Group: Object Constraint Language Version 2.0. Technical Report, OMG, May 2006Google Scholar
- 5.Burbeck, S.: Applications programming in Smalltalk-80(TM): How to use Model-View-Controller (MVC). Technical Report, Department of Computer Science, University of Illinois, Urbana-Champaign (1992)Google Scholar
- 6.Ammann, P., Offutt, J.: Introduction to Software Testing. Cambridge University Press (2008)Google Scholar
- 8.OMG: Meta object facility (MOF) version 2.0, core specification. Technical Report formal/2006-01-01, Object Management Group, January 2006. http://www.omg.org/cgi-bin/doc?formal/2006-01-01.pdf
- 10.Nalepa, G.J., Kluza, K.: UML representation proposal for XTT rule design method. In: Nalepa, G.J., Baumeister, J. (eds.) 4th Workshop on Knowledge Engineering and Software Engineering (KESE2008) at the 32nd German conference on Artificial Intelligence: September 23, 2008, pp. 31–42. Kaiserslautern, Germany, Kaiserslautern, Germany (2008)Google Scholar
- 11.Kluza, K., Nalepa, G.J.: Metody i narzędzia wizualnego projektowania reguł decyzyjnych. In: Grzech, A., et al. (eds.): Inżynieria Wiedzy i Systemy Ekspertowe. Problemy Współczesnej Nauki, Teoria i Zastosowania. Informatyka, Warszawa, Akademicka Oficyna Wydawnicza EXIT , pp. 197–208 (2009)Google Scholar
- 12.Kluza, K., Nalepa, G.J.: Analysis of UML representation for XTT and ARD rule design methods. Technical Report CSLTR 5/2009, AGH University of Science and Technology (2009)Google Scholar
- 13.OMG: Unified Modeling Language (OMG UML) version 2.2. superstructure. Technical Report formal/2009-02-02, Object Management Group, February 2009Google Scholar
- 14.Nalepa, G.J., Wojnicki, I.: Using UML for knowledge engineering – a critical overview. In Baumeister, J., Seipel, D. (eds.): 3rd Workshop on Knowledge Engineering and Software Engineering (KESE 2007) at the 30th Annual German conference on Artificial intelligence: September 10, 2007, pp. 37–46. Osnabrück, Germany, September 2007Google Scholar
- 15.OMG: MOF 2.0/XMI mapping version 2.1. specification. Technical Report formal/2005-09-01, Object Management Group, September 2005. http://www.omg.org/cgi-bin/doc?formal/2005-09-01.pdf
- 16.Daum, B., Merten, U.: System Architecture with XML. Morgan Kaufmann (2002)Google Scholar
- 17.Gerber, A., Lawley, M., Raymond, K., Steel, J., Wood, A.: Transformation: The missing link of MDA. In: Graph transformation: first international conference, ICGT 2002, pp. 252–265, Barcelona, Spain (2002)Google Scholar