Visual Software Modeling with Rules

Part of the Intelligent Systems Reference Library book series (ISRL, volume 130)


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) [1] 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)  [2] is de facto the standard for modeling software applications [3]. 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) [4] 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) [5] 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.

The research presented in this chapter aims at addressing all three problems (A, B, C). The solution to these problems consists in:
  • 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) [8] 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 [9]. 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

UML representation of ARD+ has been proposed in [10, 11]. The representation uses class diagrams to convey ARD+. Other preliminary approaches and more details can be found in [12].

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 [13], 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+.

Elements of the proposed UML model correspond to one-to-one to the properties in ARD+ (it is a bijective relation). In the proposed model:
  • 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.

The difference between a conceptual and a physical attribute is presented in the same form as in ARD+. The name of a conceptual attribute begins with a capital, while the name of a physical attribute begins with a lower case.
Fig. 11.1

Example of UML representation of ARD+ diagram

Fig. 11.2

UML representation of a TPH diagram corresponding to the previous ARD model

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

The abstract syntax of UML is defined by the metamodel. As the proposed model uses only a subset of UML artifacts and relationships, its metamodel can be created as a subset of the UML metamodel with constraints imposed [13].
Fig. 11.3

Metamodel for the UML representation of ARD+ diagrams

Figure 11.3 shows the metamodel of the UML representation for ARD+ diagrams. The representation uses only UML classes (with or without attributes) and the «derive» dependencies. Moreover, there is a need to define some OCL constraints in the metamodel, because the metamodel itself is not stated precisely enough (see [12] for details).
Fig. 11.4

Metamodel for the UML representation of TPH diagrams

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 [12] 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 [13] 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 [14] 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 [12]. 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.

The XTT2 representation in UML uses Activity Diagrams to express the XTT2 model (see [10] for more details on preliminary modeling attempts). These diagrams are related to flow diagrams and illustrate the activities in the system. At the lower level of the knowledge base a single XTT2 table is represented. An example of a UML representation (corresponding to the table in Fig. 11.5) is shown in Fig. 11.6. In the proposed UML model of the XTT2 table the following node types are used:
  • 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.

Fig. 11.5

Example of an XTT2 table

Fig. 11.6

UML representation of the XTT2 table from Fig. 11.5

Every XTT2 attribute is represented by an (input or output) Activity Parameter node. The whole Activity resembles a logical gate system, where Merge/Join Nodes behave like logical or/and gates. Values of attributes are checked in guard conditions by the Decision Nodes, and values of output parameters are set by Actions. In more complex cases, there is a possibility of different transitions from one table. In such a situation, a new transition output Activity Parameter is introduced, see Fig. 11.7. The diagram corresponds to the exemplary Table 11.1, where Par are attribute names.
Fig. 11.7

The lower level more complex model example

Table 11.1

The exemplary XTT2 table









\(\rightarrow \) tab2




\(\rightarrow \) tab2





\(\rightarrow \) tab3

At the higher level the whole XTT2 model consisting of linked tables is represented. In the model, every table has a corresponding Action, which calls the behavior modeled at the lower level. These Actions are connected as previously at the lower level model. If an action has an Output Pin on its output, it means that the corresponding table has transitions to more than one table (in accordance with each distinct value of transition attribute from the lower level). An example of such representation is shown in Fig. 11.8.
Fig. 11.8

The higher level model example

Metamodel of the XTT2 Model

The metamodel of the proposed model constitutes a subset of the UML Activity Diagram metamodel [13] with additional constraints imposed. Figure 11.9 shows the metamodel of the UML representation for the XTT2 diagrams. The presented metamodel is not yet precisely stated, because the UML diagrams themselves are typically not detailed enough to describe every aspect of a specification. To ensure the accuracy of models, some additional OCL constraints for the metamodel have to be provided.
Fig. 11.9

Metamodel for XTT2 diagrams

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 solution for the enforcement of this node order is to use OCL constraint expressions (see [12] for details). Moreover, the higher level model of XTT2 uses an additional Output Pin artifact (which is one of the UML standard artifacts; however not used in the lower level model of the XTT2). Thus, the XTT2  metamodel from Fig. 11.9 has to be extended by introducing an additional UML standard element, as shown in Fig. 11.10.
Fig. 11.10

Introducing the Output Pin to the metamodel of XTT2

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) [15] 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 [15] 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 [12]. Although XMI is predominantly used to exchange model data between different UML tools [16], 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+

In the case of XMI to ARD+  translation the algorithm is simple, and elements can be easily mapped as it is described in Sect. 11.2. This is done according to the following rules:
  1. 1.

    Every class without attributes becomes an ARD+ simple property.

  2. 2.

    Every abstract class becomes an ARD+ complex property.

  3. 3.

    Every «derive» dependency becomes an ARD+ dependency.

In the case of the TPH, in addition, one has to use two following rules:
  1. 4.

    Every «refine» dependency becomes an ARD+ finalization.

  2. 5.

    Every aggregation becomes a part of an ARD+ split.

Translation from ARD+ to XMI
In the case of ARD+ to XMI translation the algorithm is very similar to the XMI to ARD+ algorithm. The mapping between elements is the same, and the translation can be done according to the following rules:
  1. 1.

    Every ARD+ property becomes a class with attributes (for complex property) or without (for simple property).

  2. 2.

    Every ARD+ dependency becomes a «derive» XMI dependency.

In the case of the TPH, in addition, one has to use the two following rules:
  1. 1.

    Every ARD+ finalization becomes the «refine» XMI dependency.

  2. 2.

    Every ARD+ split becomes an XMI aggregation.

Translation from XMI to XTT2
In the XTT2 UML representation (serialized to XMI) UML artifacts have their own semantics, and the translation to XTT2 (serialized to HML) is not simple. It is not sufficient to perform the mapping of elements (between XMI and HML) – additional transformations have to be done. Figure 11.11 shows the flowchart of the translation.
Fig. 11.11

The flowchart presenting the translation from XMI to XTT2

Fig. 11.12

The process of simplification of the table representation

The algorithm for the lower level representation is as follows. For every table represented by the UML diagram:
  1. 1.

    Name of the table is saved.

  2. 2.

    Activity Parameter Nodes become attributes of the table.

  3. 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):
    1. 3.1.

      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.

    2. 3.2.

      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.

    3. 3.3.

      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.

    4. 3.4.

      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.

  1. 4.

    After the simplification of the model, it is much easier to transform the UML representation of the rules to HML.

    1. 4.1
      If there is more than one input Activity Parameter Join Nodes become rule elements in the following way. For every Join Node:
      1. 4.1.1.

        Every guard value in the incoming edges to the Join Node becomes the expression in the condition part for the proper rule attribute.

      2. 4.1.2.

        Every action name in the outgoing edge of the Join Node becomes the expression in the decision part for the proper rule attribute.

    2. 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:
      1. 4.2.1.

        Every guard value in the flow becomes the expression in the condition part for the proper rule attribute.

      2. 4.2.2.

        Every action name in the outgoing edge of the Join Node becomes the expression in the decision part for the proper rule attribute.

At this stage of the algorithm the table representation is finished. However, there are no links between tables. The algorithm for the higher level representation is:
  1. 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):
    1. 5.1.

      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.

    2. 5.2.

      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.

  2. 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.

Fig. 11.13

The process of simplification of the network of tables representation

Translation from XTT2 to XMI

The translation algorithm from XTT2 to XMI is more complicated than the previous ones. This section contains the refined version of the algorithm presented in [10] for XTT2 tables. Because of the semantics of the UML artifacts, some complex transformations have to be done.
Fig. 11.14

The translation from XTT2 to XMI for the lower level representation

The algorithm for the lower level representation is as follows (it is illustrated in Fig. 11.14). For every XTT2 table, Activity is created, and:
  1. 1.

    All condition attributes become input Activity Parameter Nodes and decision attributes become output Activity Parameter Nodes.

  2. 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:
    1. 2.1.

      The Object Flow with this unique value as a Guard condition is introduced,

    2. 2.2.

      If the value occurs frequently, the flow is finished with a Fork Node.

  3. 3.
    If there is more than one condition attribute, for each XTT2 rule a Join Node is created, and:
    1. 3.1.

      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),

    2. 3.2.
      Depending on the number of decision attributes:
      1. 3.2.1.

        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),

      2. 3.2.2.

        Otherwise: a Fork Node is introduced and the Object Flow from the Join Node to this Fork Node is created.

  4. 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:
    1. 4.1.

      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:

    2. 4.2.

      The Action (having a value corresponding to the value of the decision attribute in the rule).

  5. 5.

    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.

The algorithm for the higher level representation is as follows. The activity diagram for the whole system is created, and:
  1. 1.

    For every XTT2 input and output system attributes, corresponding input and output Activity Parameter Nodes are created.

  2. 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. 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.

Let us consider the XTT2 rule model as shown in Fig.  9.5. The network of decision tables represents the complete model for the system. The XTT2 model can be serialized to the XML-based HML notation suitable for the XSLT translation. Using XTT2UML XSLT translator the model can be transformed from HML to XMI and then opened in a UML tool. A set of diagrams for the UML model of the presented XTT2 Cashpoint model is shown in Fig. 11.15. These diagrams correspond to the previously defined decision tables. The domain model for the rule attributes can be observed in Fig. 11.16. The design conforms to the MVC pattern. In this case the model is responsible for storing domain data (see Fig. 11.16) as well as the system behavior (see Fig. 11.15). The detailed behavior description allows for responding to requests concerning information about the system state.
Fig. 11.15

UML representation of the Cashpoint XTT2 Model

Fig. 11.16

UML representation of the domain for the Cashpoint XTT2 Model

The View part of the system is responsible for a Graphical User Interface (GUI) and user interaction. This separation of the View from the Model allows for independent development and easy substitution of each layer. The exemplary View implementation specification is shown in Fig. 11.17. The GUI for this implementation is shown in Fig. 11.18 (PIN, Amount and Action Windows). It is an example implemented using the Qt library that heavily uses the MVC architectural pattern for the application design. For brevity, here we omit the detailed specification of the Controller. However, the logic of its behavior is presented in Fig. 11.19. Using features provided by Qt (or other application frameworks) it can be easily implemented.
Fig. 11.17

UML model of the View for Cashpoint

Fig. 11.18

Qt GUI for the Cashpoint application

Fig. 11.19

UML behavioral model of the Controller for Cashpoint application

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.

To summarize, the presented UML representation has several advantages:
  • 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.

11.5 Summary

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).


  1. 1.

    Element occurs when there is more than one input Activity Parameter node.

  2. 2.

    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).

  3. 3.

    Element occurs when previous Action has Output Pin.

  4. 4.
  5. 5.
  6. 6.


  1. 1.
    Sommerville, I.: Software Engineering. International computer science, 7th edn. Pearson Education Limited, Boston (2004)MATHGoogle Scholar
  2. 2.
    OMG: Unified Modeling Language version 2.1.2. infrastructure. specification. Technical Report formal/2007-11-04, Object Management Group, November 2007.
  3. 3.
    Hunt, J.: Guide to the Unified Process Featuring UML. Java and design patterns. Springer, Berlin (2003)Google Scholar
  4. 4.
    Object Management Group: Object Constraint Language Version 2.0. Technical Report, OMG, May 2006Google Scholar
  5. 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. 6.
    Ammann, P., Offutt, J.: Introduction to Software Testing. Cambridge University Press (2008)Google Scholar
  7. 7.
    Xu, D., Xu, W., Wong, W.E.: Automated test code generation from class state models. Int. J. Softw. Eng. Knowl. Eng. 19(4), 599–623 (2009)CrossRefGoogle Scholar
  8. 8.
    OMG: Meta object facility (MOF) version 2.0, core specification. Technical Report formal/2006-01-01, Object Management Group, January 2006.
  9. 9.
    Wan-Kadir, W.M.N., Loucopoulos, P.: Relating evolving business rules to software design. J. Syst. Arch. 50, 367–382 (2004)CrossRefGoogle Scholar
  10. 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. 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. 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. 13.
    OMG: Unified Modeling Language (OMG UML) version 2.2. superstructure. Technical Report formal/2009-02-02, Object Management Group, February 2009Google Scholar
  14. 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. 15.
    OMG: MOF 2.0/XMI mapping version 2.1. specification. Technical Report formal/2005-09-01, Object Management Group, September 2005.
  16. 16.
    Daum, B., Merten, U.: System Architecture with XML. Morgan Kaufmann (2002)Google Scholar
  17. 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
  18. 18.
    Fong, J., Shiu, H., Wong, J.: Methodology for data conversion from xml documents to relations using extensible stylesheet language transformation. Int. J. Softw. Eng. Knowl. Eng. 19(2), 249–281 (2009)CrossRefGoogle Scholar

Copyright information

© Springer International Publishing AG 2018

Authors and Affiliations

  1. 1.AGH University of Science and TechnologyKrakówPoland

Personalised recommendations