Extracting ECA rules from UML

Extracting ECA Rules From UML

(HS-IDA-EA-01-111)

Júlía Pálmadóttir (

a96julpa@ida.his.se

)

Institutionen för datavetenskap

Högskolan i Skövde, Box 408

S-54128 Skövde, SWEDEN

Final year project in computer science 2001.

Supervisor: Dr. Mikael Berndtsson

Extracting ECA Rules from UML

Submitted by Júlía Pálmadóttir to Högskolan Skövde as a dissertation for the degree

of B.Sc., in the Department of Computer Science.

16 October 2001

I certify that all material in this dissertation which is not my own work has been

identified and that no material is included for which a degree has previously been

conferred on me.

Extracting ECA Rules from UML

Júlía Pálmadóttir (

a96julpa@ida.his.se

)

Abstract

Active technology in database management systems (DBMS) enables the movement

of behaviour dependent on the system’s state, from the application software to a rule

base in the DBMS. With active technology in database systems, the problem of how

to design active behaviour has become an important issue. Modelling processes do

not foresee support for design of active rules which can lead to conflicts between the

event-condition-action (ECA) rules representing the active behaviour and the

application systems, using the active DBMS The unified modelling language (UML)

is a widely used notation language and is the main subject in this project. Its features

will be investigated to acknowledge to what extend UML modelling diagrams provide

information that can be used to formulate ECA rules.

To achieve this, two methods where developed. One of the methods was applied on

use-case UML modelling diagrams. The use-case models were developed by means

of reflecting a real-life organisation. The results from applying the method on the

use-case models were that there are features in UML that can be expressed with ECA

rules.

1.

INTRODUCTION... 1

2

BACKGROUND... 3

2.1 U

NIFIED

M

ODELING

L

ANGUAGE

... 3

2.1.1

Class Diagram... 3

2.1.2

Object Diagram... 4

2.1.3

State chart Diagram ... 4

2.1.4

Activity Diagram ... 5

2.1.5

Sequence Diagram ... 6

2.1.6

Collaboration Diagram... 7

2.1.7

Use-Case Diagram... 7

2.1.8

Component Diagram ... 8

2.1.9

Deployment Diagram ... 8

2.2 A

CTIVE RULES

... 8

3

RELATED WORK ... 10

3.1 T

HE

IDEA M

ETHODOLOGY

... 10

3.2 T

HE THREE

-

LEVEL ARCHITECTURE

... 12

4

PROBLEM DESCRIPTION... 17

5

METHOD... 19

5.1 D

IRECT

-

ATTACK

... 19

5.2 S

IDE

-

ATTACK

... 23

5.3 C

OMPARISON OF METHODS

... 26

5.3.1

The direct-attack method... 26

5.3.2

The side-attack method... 26

5.4 C

HOICE OF METHOD

... 26

6

APPLYING THE METHOD ... 28

6.1 S

TEP I

: D

IAGRAM

’

S RELEVANCY

... 28

6.2 S

TEP II

: A

NALYSIS

... 29

6.3 S

TEP III

: G

ROUPING OF

ECA

CONSTITUENTS

... 31

6.4 S

TEP IV

: C

OMBINING

ECA C

ONSTITUENTS

... 32

6.5 S

TEP V

: C

OMBINING LOOSE

-ECA

RULES

... 35

6.6 A

NALYSIS OF RESULTS

... 36

7

CONCLUSIONS ... 38

7.1 C

ONTRIBUTIONS

... 38

7.2 P

ROBLEMS

... 38

7.3 D

ISCUSSION

... 38

8

FUTURE WORK ... 41

REFERENCES ... 42

APPENDIX A ... 43

APPENDIX B... 51

APPENDIX C ... 63

1

1. Introduction

It is common for software systems to use a database management system (DBMS) for

storing and processing data. A DBMS is an independent system, to which the

application system communicates when storing or retrieving data. A traditional

DBMS stores data in table records and provides mechanisms for implementation of

procedures that can be called from the application.

In 1996, Booch, Rumbaugh and Jacobsen (Eriksson and Penker, 2000) designed the

Unified Modeling Language (UML). UML is a notation language that supports the

object-oriented mechanism. UML was later standardized by the Object Management

Group, and today, many software development processes use UML as their notation.

UML provides nine diagrams, each serving a different part in a software development

process. The diagrams show how the system should be implemented, what operations

need to exist and how the flow of data is within the system. The UML notation is

useful for designers, programmers as well as customers.

When designing the structure of a database, UML’s class diagram is a valuable

source for which tables and which fields within those tables need to exist. Class

diagrams provide information concerning object’s characteristics and usually, a

database table record reflects those characteristics.

To date, all operations concerning insertion, deletion and modification of data are

processed by the software application, not by the DBMS. Different applications can

use a single DBMS. These applications may share some functionality and constraints

on attributes and tables. Those constraints have to be implemented and controlled in

each and every one of the applications. This leads to increased complexity of the

applications since different functionalities need to be implemented. When

considering the aims of modern software development, such as decreased complexity

and redundancy, the idea of moving conditional dependent operations from the

application system to the DBMS (Van den Berghe, 1999) was identified (for instance,

the deletion of customer lines records when the customer is deleted). Conditional

dependent operations are rules that are executed when the system is in a specified

state, those rules are called event-condition-action rules (ECA rules) and operate in

the way that when an event occurs a condition is evaluated and if true, an action is

executed. ECA rules are active since they are executed when the system reaches the

specified state, i.e. they are not called specifically like traditional operations and

procedures. A DBMS that uses active technology is an active DBMS (ADBMS).

Most ADBMS today are research prototypes, e.g. SAMOS (Gatziu and Dittrich,

1992) and few commercial ADBMS exist.

The opportunities that lie within an ADBMS have been recognised by Calestam

(1999) and Van den Berghe (1999) and the process of integrating the support for

active rules in programming languages has been successful (Gatziu and Dittrich,

1992). But the software development methodologies that were developed in the mid

1990’s only limitedly support the modelling of active rules.

The project done by Van den Berghe (1999) resulted in a design method for rules,

called the three level architecture. Rule requirements are expressed in an informal

2

language and then rule patterns are used to transform the expressions into an

executable formal language. He identified the problem of conflicts between different

modelling segments, like between classes and ECA rules, and developed a process

that aids in preventing the rise of those conflicts.

The IDEA methodology was presented by Ceri and Fraternali (1997). IDEA is a

software design process that concentrates on the data processing that is required from

the application system. It presents methods to formulate state chart diagrams into

active rules and represent them in Chimera, which is a conceptual language that was

developed during the IDEA project.

In this final year project, the coupling between active rules and UML is investigated.

In particular the features of UML that can be used as a source for the definition of

active rules, are identified. If the result from this work is that active rules cannot

easily be extracted from UML, the development of an extension to UML, or even the

development of a new notation language is justified. On the other hand, if the results

will show that a strong coupling exists between UML and active rules, then the

extraction of active rules from UML diagrams will enable modelling of all of the

systems components in a single design process.

To do this investigation, a method must be developed. The method will then be

applied on use-case UML modelling diagrams which represent an organisational

domain. The results from applying the method should give ideas about which features

in UML give information that can be used when designing active rules.

3

2 Background

The organization of this chapter is as follows; chapter 2.1 gives an overview of the

nine models of UML; chapter 2.2 discusses active rules and active technology and

chapter 2.3 gives a brief summary of related work.

2.1

Unified Modeling Language

The Unified Modeling Languages biggest contribution to software development is the

support for the object-oriented mechanism (Eriksson and Penker, 2000). This is

achieved through for example classes, association, aggregation and generalization.

As the name implies, objects are the main concept in an object-oriented software

design. An object is an instance of a class and multiple objects can be instantiated

from the same class.

2.1.1 Class

Diagram

Classes are the foundation for an object-oriented system design. A class might for

instance be a

Customer

, an

Employee

or a

Creditor

(figure 2.1). An object is

initiated from a class, e.g. the customer John Doe would be created as an object of the

class

Customer

. Objects have a unique identifier and characteristics that are stored

in the objects attribute, i.e. the class’s attributes.

Several concepts apply to the class diagram’s features that represent the relationship

and constraints between and within classes (Eriksson and Penker, 2000). The most

important concepts are described in the following paragraphs.

Attribute – When an object instance of a class is created, the attributes in that class

are created for the object and some of them (or all) given a value. Object attributes

can be seen as the objects characteristics (Eriksson and Penker, 2000). An attribute

value must be of a specified type, e.g. integer, string etc.

Operation – Operations are executed to modify, insert or delete data (Eriksson and

Penker, 2000). Operations can also be used to check conditions, like for instance to

check if a customer account is open or closed. This operation should be called before

any withdrawal or deposit of a customer. If the operation

customer::withdrawal(500)

is called,

customer::open()

is called within

that operation and if true, a customer line is created with the amount 500. Operations

have parameters (Eriksson and Penker, 2000), which are values that are passed to the

operation when it is called. They can also have a return type defined, like the

Customer::open()boolean

operation would have the return type boolean.

Operations have a visibility, i.e. they can be public, private or protected. A public

operation can be called from wherever within the system, while a private operation

can only be executed within its own object. A protected operation has defined what

objects can execute it.

Association – A class can be associated with other classes. Associations are defined

with the multiplicity attribute (Eriksson and Penker, 2000), i.e. how many object

instances of class

A

can be associated to an object of class

B

. In figure 2.1, the class

4

Customer

is associated to the

Customer Lines

class with the 1:N multiplicity,

which means that every

Customer

object can be linked to several

Customer

Lines

, but a

Customer Lines

object can only be linked to exact one object of the

Customer

class.

Generalization – Generalization is a so called super class, from which other classes

(subclasses) have been derived (Eriksson and Penker, 2000). In figure 2.1

Person

is

a super class and

Customer

,

Employee

and

Creditor

are derived classes

(subclasses). The subclasses inherit all of the super class attributes and operations.

The derived classes would have the attributes and operations of the parent class,

Person

, in common. Each class can have its own attributes and operations, like the

Employee

class has attributes like

startDate

,

salary

,

pension

etc.

Aggregation – When a number of objects of the same class or of different classes

have a relationship in that way that when one of these objects is discarded, all the

other objects will be discarded to (Eriksson and Penker, 2000).

Figure 2.1 A class diagram with class relationships

2.1.2 Object

Diagram

An object diagram shows the related object instances at a specific point in time

(Fowler and Scott, 2000). For instance, a sale order

ORD1

is made to the customer

John Doe

. This sale order consists of a number of products, and each one of those

products is associated to an object of the class Product. Since an object is an instance

of a class, an object diagram is often called an instance diagram (Fowler and Scott,

2000).

2.1.3 State chart Diagram

An object has numerous states. A state chart diagram shows all states that can occur

within an object’s lifecycle. The state chart also gives thorough information about the

flow within the software system and what behaviours are expected. When an object

changes from state

a

to state

b

, a transition (Fowler and Scott, 2000) is carried out on

Person Social Sec. Nr. Name Address Phone Number Employee Employee ID Start Date Salary Pension Customer Lines Customer ID Product ID Amount Quantity Creditor Creditor ID Contact Person Customer Customer ID Payment Method Credit Limit Open() WithDrawal(Amount)

1

*

5

the object which is in state

a

. The objects state is then transitioned from state

a

to

state

b

. A transition is associated to an

event

,

guard

and an

action

(Fowler and

Scott, 2000) (figure 2.2 shows the state of a payment object).

Event – An event takes place in an objects state. For example, when a customer

purchases items, a payment record must be registered on that customer in order for the

items to be delivered. When the payment object,

PAY01

is in the state

Authorizing

the authorization of a payment must be checked. If the authorization is valid, the

payment is authorized and the purchased items are delivered. Otherwise, the order line

is cancelled.

Guard – The guard acts as a condition for a transition to be fulfilled. If the guard is

not true, the transition is cancelled.

Action – The action is carried out if, and only if, the guard returns true.

Figure 2.2 State diagram (Fowler and Scott, 2000, p.125).

2.1.4 Activity

Diagram

Activity diagrams are useful for connecting workflow and in describing parallel

behaviour, (Eriksson and Penker, 2000, Fowler and Scott, 2000). Activity diagrams

do not relate to objects, rather, they relate to transactions of the occurrence of events.

They can be seen as the modelling of a transaction, since the opening element is an

event and the closing element is an event which represents the ending of the

transaction (Fowler and Scott, 2000).

The components of activity diagrams are: activity, fork, branch, guard, merge and

join (figure 2.3). An activity is a state, to which guard(s) can be bound. A fork

divides an activity into multiple activities and a branch connects multiple guards to an

activity. The branch must consist of guards that fulfil the if ... else if ... else

programming technique, i.e. only one guard can be true when an activity state is

Authorized

Delivered

Rejected

Authorizing

Do/check

payment

[Payment not OK]

6

reached. A merge must exist for every branch to close the opening of a branch, and

similarly a join must exist for every fork (Fowler and Scott, 2000).

The diagram has one opening state and one closing state. For every path from top to

bottom in the diagram, a transaction can exist. In simple activity diagrams, the

structure can be seen as: an event, a state, guard(s), state and an event (Figure 2.3).

The Activity diagram shows the workflow of the system. This considers both actions

from user and internal system actions. Activity Diagrams are of great use in systems

where processors run in parallel (Fowler and Scott 2000). The diagrams can aid

structuring priority and order of processors to improve the system’s performance.

Figure 2.3 Activity Diagram (based on Fowler and Penker (2000, p.130)).

2.1.5 Sequence

Diagram

Sequence Diagrams show the lifetime of an object (Fowler and Scott, 2000). The

sequence diagram is structured to show the message flow between objects of different

classes. The diagram shows at which event occurrence an object is created, when and

with what other objects it communicates, and when it is deleted. As the name

indicates, the message flow within a sequence diagram is shown in a sequential order.

When the diagram is made, it is preferred that class and state chart diagrams are

completed. This is because sequence diagrams are based on objects, and class

diagrams show the structure of objects while the state chart diagrams show the

interaction between objects (figure 2.4).

Receive Order Send Invoice Fill Order Receive Payment Regular Delivery Overnight Delivery Close Order

Start

Guard

Activity

Fork

Branch

Merge

Join

End

7

Figure 2.4 A Sequence Diagram.

2.1.6 Collaboration

Diagram

Collaboration diagrams are similar to sequence diagrams. They show the sequential

flow between objects with message numbering.

The advantage of using collaboration diagrams is the visualization of static

connection between objects and classes. The diagram can be structured to show

objects or simply the class names from which objects will be created (Fowler and

Penker, 2000).

2.1.7 Use-Case

Diagram

A use-case diagram is a set of scenarios. “A scenario is a sequence of steps

describing an interaction between a user and a system” (Fowler and Scott, 2000 p.39).

An example scenario of a phone salesman making a new sale order:

A customer contacts a salesman. The salesman creates a new order with

necessary information concerning the customer (customer number,

payment method etc), then adds an order-line for every product the

customer acquires. The customer chooses a transport method and the

salesman calculates the delivery date and finishes the order.

This scenario can be broken down into sequentially numbered steps:

1.

Customer contacts a salesman.

2.

The salesman creates an order with necessary information (customer

number, payment method etc.).

3.

An order line is created for every product.

4.

The customer chooses delivery date.

5.

The salesman calculates the delivery date, and

6.

finishes the order

This scenario might be called making order. This scenario would then be connected

to a salesman actor. An actor is a role within the system (Fowler and Penker, 2000),

e.g. a salesman, a manager, a financial consultant etc.

Payment

Payment Lines

Customer

Customer Line

Prepare()

CustomerExist:=check()

[CustomerExist] MakeDeposit

;

Return

Deletion

8

Use-case diagrams are made at the very first steps in analysis and design when

developing software. Use-cases are very flexible in use, it is up to each individual

how exact they are made and how many are assumed to be required.

2.1.8 Component

Diagram

A component diagram shows the dependencies between software module

components. Here, the physical dependencies are of interest, for instance, “a single

class may be present in multiple components, but that class can be defined in only one

package” (Fowler and Scott, 2000, p.143).

2.1.9 Deployment

Diagram

The physical relationship that exists between software and hardware components in

the respective system is represented in a deployment diagram (Eriksson and Penker,

2000). The diagram is useful for showing the physical interactions in the system, for

instance the communication flow between a database server and a web server.

2.2 Active

rules

Active technology can be defined as an automatic active behaviour responding to a

stimulus (Van den Berghe, 1999). This stimulus can for instance be an automatic

reminder which is sent to customers that have overdue their account limit. Active

technology has strong influences on different factors of a system (Ceri and Fraternali,

1997):

Automation

increases with increased number of active responses that the system

provides.

Reusability of components instead of having to add a number of functionality to

different applications or parts of an application it is sufficient to add

the behaviour to the an active rule base.

Maintenance administration of behaviour is performed with a single administration

tool.

knowledge independence when active behaviour is formed into rules and transferred

from the applications into the DBMS it increases knowledge

independence since the coupling between the applications is reduced,

and the “consequence of achieving full knowledge independence is

that data management policies can effectively evolve by modifying

rules instead of application programs”.

Active rules are rules that can create, delete and modify data. They “have the ability

to impose a unique and consistent behaviour, independent of the transaction that

causes their triggering and execution” (Ceri and Fraternali, 1997). Active rules are so

called triggers (Ceri and Fraternali, 1997), because they are triggered according to the

state of the DBMS.

9

Deductive rule: Calculate the average amount customer X shops

for each month.

Active rule:

When customer X has exceeded his credit limit

of $1000, close his account.

When a DBMS stores active rules, and by that increases the DBMS’s knowledge

independence, it is called an active DBMS (Van den Berghe, 1999). Figure 2.5 shows

clearly the difference between a traditional DBMS and an ADBMS. Instead of having

rule definition in every application program, the rules are gathered into a rule base,

where they can be maintained.

Figure 2.5 Movement of an action from application programs into the rule base (Van den

Berghe, 1999, p.2)

Active rules are usually called event-condition-action rules (ECA rules). An event is

also called a trigger. The state in the system when something happens, like an input,

modification or deletion of data. A condition can be either true or false. A condition

can be of a specific value (true) or an evaluation of an event parameter. An action is a

transaction that is executed if the condition is evaluated to true.

PASSIVE DATABASE

ACTIVE DATABASE

Data tables/Objects

Data tables/Objects

Rule base

....

Rule i covering action i

...

10

3 Related

Work

There are two related work within the area of designing active rules. The first one,

IDEA, was a project done in 1997 by Ceri and Fraternali and one of its contribution to

the design of active rules was the conceptual language Chimera. IDEA identifies

UML’s state chart diagram as a source for active rules and methods to achieve the

mapping of state chart diagrams were developed.

The three level architecture, developed by Van den Berghe (1999) focuses on

designing active rules with an informal language and then transforming the informally

written definition into an executable language. In the research, the connection

between the design of UML and the design of active rules is investigated and the risk

for conflicts between those two design moments are identified.

3.1

The IDEA Methodology

Ceri and Fraternali (1997) describes IDEA as follows:

Being driven by database technology, the IDEA Methodology takes a

data-centric approach: data design comes first, and application design follows.

Thus, the IDEA Methodology approaches object-oriented design from a new,

data-centric perspective; it may be considered as a new database design

methodology that takes advantage of object-oriented concepts, or as a new

object-oriented methodology targeted to the development of databases. (Ceri

and Fraternali, 1997, p.vii)

IDEA uses the Object Modelling Technique (OMT) for the design of diagrams. OMT

has its own notation but parts of it were adopted by UML, and therefore the notations

are not that different. OMT consists of three models: the object model which focuses

on the objects available in the system and defines an object’s attributes, operations

and internal relationship; the dynamic model represents an object’s states; and the

functional model which describes transformations of values.

In the IDEA project, the conceptual language Chimera was developed. IDEA

concentrates on expressing elements with Chimera which is an executable language

and supports the formulation of ECA rules. In the IDEA project, the formulation of

active rules is made primarily with Chimera and less emphasis is put on the design of

active rules.

Active rules are so called triggers. Triggers are transactions that are executed when

the system is in a certain state or a condition is true. A trigger definition statement is

used as the syntax for rules in Chimera;

trigger_rule::= “define”[trig_options] “trigger” trig_name

[“for”

class_name]

trigger_impl

“end;”

trigger_impl::= “events” events

“condition”

c_formula

“actions”

reaction

[priority_options]

(Ceri and Fraternali, 1997, p.89)

11

Rules can be targeted or untargeted. Targeted rules belong inside the scope of a

single class while untargeted rules are available for multiple classes. Rules in

Chimera consist of an event, condition, action and priorities.

Events are primitive operations that are applied to either a class or a class’s attributes.

“Primitive operations are: display, object creation, modification, deletion, and object

migration within generalization hierarchies (the classes shown in figure 2.1 form a

generalization hierarchy where the class

Person

is at the highest hierarchic level).”

(Ceri and Fraternali, 1997, p.90) (table 3.1) The last one mentioned, is used when

multiple objects of different classes with the same superclass (the classes

Customer

and

Employee

have the same superclass,

Person

) are migrated into one object. This

could for instance be the case when objects of the class

Customer

and

Person

are

created and having the same social security number, those two objects are migrated

into one object.

Primitive operation

Applies to

Constraint

Object creation

Classes

Not applicable on derived classes

Modification Attributes

Not

applicable on derived attributes

Deletion

Classes

Not applicable on derived classes

Object migration

Classes

Not applicable on derived classes

Table 3.1 How primitive operations are applicable.

A condition is expressed as a declarative formula. “Conditions are computed over

both the state of the database and relevant events” (Ceri and Fraternali, 1997, pp.90),

which means that the condition segments can refer to the specified state’s attributes or

to variables that are passed to the condition from the event as parameters. Conditions

can be set to the constant

true

, which affects the active rule in the way that when an

event occurs associated with the condition constant true, the relevant action(s) will

always be performed.

An action is a sequence of procedure calls, including amongst others, primitive

operations. When a condition is true and the action is called, variables from the

condition may be passed to the action call as parameters.

To avoid priority conflict, the rules can be defined with the optional priority clause.

The priority clause can declare

before

and

after

priority of the rule.

Example of an active rule definition in Chimera;

define trigger raiseBudget

events create(employee)

OR

modify(employee.salary)

OR

modify(department.members)

OR

modify(department.salaryBudget)

condition

department(D),

integer(I)

I = sum(E.salary where employee(E), E in

D.members),

I

>

D.salaryBudget

actions

modify(department.salaryBudget,D,I)

after

employee.adjustSalary

end;

12

The project identifies the potentials for formulation of ECA rules using information

from state diagrams. To do this, dynamic states and events of an object’s state chart

diagram must be identified and that is accomplished as follows (table 3.2):

• To map the dynamic state of an object’s class, the set of attributes representing all

possible states of the object class are enumerated.

• The events can be mapped into Chimera according to two strategies; purely

event-oriented or purely object-oriented. The event-oriented strategy maps every

event name in the state chart diagram is into a specific event class, which has the

attribute

target

that points to the object’s class (the class from which the object

is instantiated) that the state chart diagram represents. The event class can also

have attributes representing the event parameters. With the object-oriented

strategy, each event is mapped into an operation on the object’s class. The

operations do not have the “status” of objects, since they are invoked by

applications. The events this method produces are totally dependent on the

application, and using them in rules would therefore categorise the rules as

passive.

Two methods are introduced for the mapping of state chart diagrams into Chimera; a

trigger-based design and an operation-based design. With the trigger-based design,

each transition in the state chart diagram is mapped into one immediate

event-consuming trigger. The operation-based design gives the operation that raises an

event, the authority to perform the corresponding action. See Table 3.2 for a

comparison of those two design methods.

Trigger-based design

Operation-based design

Event

The event is of type create on the

suitable event class.

An operation invokes an event.

Condition

In the state transition diagram there is a condition on every state transition.

That condition is referred to here and evaluated to true or false.

Action

An action is performed when the condition is true, the action is in fact an

update of the attributes representing the object’s state.

Mapping strategy

Purely event-oriented

Purely object-oriented

Type of system

Relational system

Object-Oriented system

Table 3.2 Comparison of the trigger-based design and operation-based design.

Ceri and Fraternali identifies four groups of source for active rules; referential

integrity (e.g. when an object referencing other objects is deleted, all the referenced

objects must also be deleted), integrity constraints (repair rules, e.g. when a constraint

is broken and response other than rollback is specified), applications (business rules,

e.g. a value specifying the minimum stock of a product) and objects dynamic

behaviour (state chart diagrams).

3.2

The three-level architecture

Van den Berghe introduced the three-level architecture for designing active rules.

The architecture is developed from his suggestions that rules should be expressed at

different abstract levels. The three abstract levels are conceptual level, procedural

level and production level (figure 3.3).

13

When starting the analysis at the conceptual level, statements are written down in a

natural language. These statements can include restrictions on f ex attribute values,

objects relationships, constraints and more. At this step, the statements can be

understood by the customer and the developer. This is the beginning stage of active

rules design, and therefore, implementation and solution methods are disregarded.

Example:

The sale price of an item must exceed its purchase

price.

(Van den Berghe, 1999, p.26)

At the procedural level, the statements from the conceptual level are reformed into an

ECA rule form, i.e. event – condition – action, with help of rule patterns. Rule

patterns describe how the rule must be structured in order for the informal language to

be translated into a structured language.

Example:

ON the sale price is updated OR the purchase price

is updated OR a new item is introduced

IF sale price < purchase price

DO abort transaction

(Van den Berghe, 1999, p.28)

There can be complications when translating a rule statement from the conceptual

level to the procedural level such as: more than one procedural rule is required to

express a conceptual rule, a conceptual rule may be triggered by several events, and

the target technology may have its limitations.

The translation of procedural rules to production rules are quite simple, an application

system may even be capable to perform this translation. At the production level, Van

den Berghe uses the conceptual language Chimera for expressing rules.

Figure 3.3 Three levels of abstraction for rules (Van den Berghe, 1999, p.26)

Abstraction levels

Typical phases of development

Conceptual

Procedural

Production Implementation Design Analysis

14

Figure 3.4 Types of applications of active technology (Van den Berghe, 1999, p.12)

Van den Berghe acknowledges three levels of application types (figure 3.4).

Internal applications. “Internal applications concern the use of active rules for

implementing facilities provided by specific subsystems in conventional DBMSs”

(Van den Berghe, 1999, p.12). Those facilities may for instance be “the management

of integrity constraints, which state conditions that must always hold on data” (Van

den Berghe, 1999, p.12), controlling user authority and viewing maintenance (Van

den Berghe, 1999).

Extended applications. Rules applied by extended application provide features such

as workflow management (Van den Berghe, 1999). “A workflow management

system enables the description and the execution of computer-supported activities that

involve multiple “steps” of processing” (Van den Berghe, 1999, p.13 – he refers to

Ceri 1996). “Event-triggered rules allow to alleviate the system from monitoring the

processing of application-tasks. Thus workflow applications have not to poll

continuously the system for being informed of the end of task executions, as passive

systems” (Van den Berghe, 1999, p.13).

Example:

Step 1

ON

a customer places an order

IF

the customer is registered

DO

a clerk creates a new order

Step 2

ON

after the creation of a new order

IF

true

DO

a product specialist records the order details

and sends a confirmation letter

(Van den Berghe, 1999, p.13)

External applications. “External applications use rules for programming automatic

reactive behaviour for specific applications” (Van den Berghe, 1999, p.13). This

reactive behaviour might for instance be when salaries are increased according to

seniority (Van den Berghe, 1999).

External

applications

Extended

applications

Internal

applications

Domain-specific facilities

Additional DB facilities

Conventional DB facilities

15

Example: Each year, salaries are increased by (100* number of

years of service)

(Van den Berghe, 1999, p.13)

Rules applied by external applications are often called business rules because they

represent behaviour that is directly coupled to those business software that use the

DBMS. Extended applications hosting business rules might for instance be

“manufacturing automation, banking information systems, or geographic databases”

(Van den Berghe, 1999, p.14).

Van den Berghe (1999, p.35) defines four main categories of rules:

• constraint rules, relating to static requirements and mainly concerning internal

applications;

• control rules, relating to the dynamic aspects of the system and mainly

concerning extended applications;

• behaviour rules, relating to functional requirements and mainly concerning

external applications; and

• environment rules, expressing non-functional needs.

Van den Berghe evaluates the support UML’s state chart diagrams have for modelling

ECA rules. His conclusions were that state chart diagrams are not suitable for

abstract design of ECA rules. State chart diagrams are bound to objects which makes

them more suitable for describing object behaviour rather than defining requirements

for active rules and their implementation. Hence, state diagrams limit the support for

active rules to the scope of objects. This is especially noticeable during the early

stages of the development process when only actions associated with objects can be

described. Van den Berghe also points out that state chart diagrams “seem

meaningful for designing process-intensive applications in which processes play a

major role” (Van den Berghe, 1999, p.102). Rules, on the other hand “are more

convenient for data-intensive applications, which use active database technology”

(Van den Berghe, 1999, p.101).

Van den Berghe points out that “traditional modelling techniques do not provide the

expressiveness of rules” (Van den Berghe, 1999, p.102) and this motivates the

development of an extension to UML to support rules. Van den Berghe also

constitutes that rule semantics cannot be clearly derived from the existing UML

concepts, thus, an extension mechanism is not sufficient and new items must be

introduced to the UML metamodel. He presents a rule metamodel and also

demonstrates how the rule metamodel can be integrated to the UML metamodel.

Van den Berghe´s research shows that the rule modeling process interleaves with

other modelling moments, such as scenarios, class diagrams and operations. Thus, the

consistency between these elements is of high importance. Van den Berghe proposes

the active modelling process as “methodological recommendations for active

development through rule diagrams and rule patterns” (Van den Berghe, 1999, p.109).

He also introduces a pre-design step “for ensuring consistency between rules and

other components and finding the adequate technique for realising a specification”

16

(Van den Berghe, 1999, p.109). The active modelling process aids when integrating

active rules design into the software development cycle by given guidelines to when

to use rules and when to use other modelling moments (Van den Berghe, 1999).

The active modelling process emphasis the following steps:

• Requirements elicitation. The first step of the three-level architecture is

processed here, thus an informal description of constraints or dependencies in the

system is captured.

• Analysis phase. Here, class diagrams are designed. Rules are reformulated by

taken into count the class attributes that the rules apply to. At this stage, the rules

are in a half-conceptual and half-procedural formulation.

• Pre-design phase. The purpose of this stage is to “eliminate potential

redundancies and conflicts between rules and other components; decide to model

a requirement with rules or with other building blocks (balancing operations); and

check consistency between the rule diagram and other diagrams” (Van den

Berghe, 1999, p.119).

17

4 Problem

description

Today, DBMSs exist that support implementation of active rules, but modern design

methodologies addresses this concept poorly. As Van den Berghe (1999) has

identified in his work, active technology cannot be used to its fullest until design

methodologies acknowledge this powerful feature and provide full support for active

rules throughout the entire software development process.

Active rules are in the form of event-condition-action rules, i.e. ECA rules. The

purpose of defining ECA rules and integrating them into the ADBMS is to move

actions that depend on the DBMS state, from the application software to the DBMS.

The main benefits of this are increased reusability of operations, decreased

complexity of application software and lower maintenance cost since the centralized

administration of rules would make the software application more knowledge

independent, which basically means that the software systems are more independent

from each other. To date, ECA rules have been designed separately from the

operational system since modelling techniques do not foresee support for them.

UML is a popular notation method to use in modelling techniques for system

development. It provides a number of models for designing different parts of the

system. However, in UML the support for ECA rules is minimal. The importance of

deploying active rules design increases with ADBMS’s improvements. If ECA rules

could be designed as a part of the system design, the risk for unexpected problems

during implementation is reduced, compared to designing ECA rules independently or

implementing them directly without design modelling. This implies that the

debugging time of the implementation should shorten and reliability of the software

product increases while the software development cost decreases if ECA rules design

could be modelled within the software development process.

Related works in the area of designing ECA rules have focused on a design method

for active rules that is separated from other modelling segments, or expressing rules in

a conceptual programming language that is executable. Those related works have not

included an analysis of UML diagrams with respect to those features that provide

information which can be used to construct ECA rules.

Van den Berghe developed three abstraction levels to design active rules: conceptual

level, procedural level and production level. He focused on the transformation of

rules written in an informal language to production rules which are of an executable

form. He made a brief investigation of the support state chart diagrams have for

active rules, and concluded that state chart diagrams are not appropriate for designing

active rules. His treatment of the design of active rules is that they are analysed and

designed in parallel, yet separated, from the system design. Van den Berghe realised

that having two design processes might create problems concerning the consistency

between different modelling segments. To solve this, he developed a process for

active development, which is a development process using UML and includes the

design of active rules.

Ceri and Fraternali (1997) developed the IDEA methodology in which Chimera, the

conceptual language of IDEA, was developed. IDEA does not add any modelling

18

notations to UML or new diagrams. IDEA acknowledges the potentials of active

rules within state chart diagrams and defines two methods to map them directly to

Chimera, in which active rules can be represented as triggers. Other UML models are

not considered as relevant to the design of ECA rules in the project. The IDEA

project rarely addresses the modelling phase during a software development process

and concentrates on a design with Chimera.

The work presented in my project, will differ from Van den Berghe’s and IDEA in the

way that all UML diagrams will be considered when extracting ECA rules from

UML. Those features that may partially or fully define an ECA rule will be

recognised and a more precise view of the system’s functionality when using active

technology will be given, since the coupling between different elements of the system

will be strengthened, and therefore, any lack of specification concerning ECA rules

will be acknowledged. If features in UML, important to the design of ECA rules,

could be recognized and even internally connected, the additional information needed

to complete ECA rules design would be minimized. It is of essence to analyse UML

in whole and realise exactly what kind of information can be extracted to ECA rules

and where it lies within the different models. To achieve this analysis of UML’s

diagrams, a method must be developed. In order for the result from the method to be

investigated, the method must be applied on UML models.

It is not the aim to develop an extensive method for describing all possible situations

from which an ECA rule can be obtained, but mainly to investigate how much

information and where it lies within the UML design diagrams that can be used for

the modelling of ECA rules.

Aim. The main aim of this project is to find and evaluate a method for extracting

ECA rules from UML diagrams. The extraction of ECA rules will be investigated

considering the features that are integrated in UML diagrams and may be used to form

ECA rules.

Objectives:

• Develop a method to extract ECA rules from UML.

• Applying the developed method on example data and evaluate the results from

19

5 Method

UML provides nine diagrams and each of them has a number of features, and thus the

possibilities of a connection between different features in different diagrams to form

ECA rules, seems endless. In order to develop a method for investigating the support

UML has for extracting ECA rules, it is suitable to divide the problem into

subproblems (steps) and investigating each of UML’s diagrams according to those

steps separately. To eliminate those diagrams that are of minimal relevancy to the

extraction of ECA rules, it is convenient to start examine if a diagram is potential for

extracting ECA rules. The first step is therefore evaluation of a diagrams relevancy.

The next step is to extract ECA rules from each of the recognised diagrams, still

focusing on a single diagram instead of the whole UML. There are two methods to

attack this problem; the direct-attack and the side-attack. The direct-attack method

extracts ECA rules from a diagram even though definition for an ECA rule attribute

may be missing (for instance if no action part of an ECA rule can be found in the

associated diagram). The side-attack method decomposes ECA rule attributes into

three constituents; event, condition and action. Those constituents are combined at

later time into an ECA rule. The extracted ECA rules in both methods are called

loose-ECA rules to identify them as potential ECA rules, that may or may not be fully

defined. The loose-ECA rules are then processed, resulting in firm-ECA rules.

Firm-ECA rules are fully defined, i.e. the event-condition-action attributes all have a

definition. The third and last step is to develop algorithms, based on what method

was chosen in its resulting ECA rules.

During the solution of the direct-attack and the side-attack methods, the extracted

components may be several and to investigate the relationship between every two

extracted components may seem unstructured due to the number of extracted

components. To deploy more structure to the investigation of coupling between

extracted components, the three application types that Van den Berghe (1999)

identified will be used (figure 3.4, chapter 3.2).

The remainder of this chapter is structured as follows; section 5.1 describes the direct

attack, section 5.2 describes the side-attack, 5.3 discusses the comparison between the

two methods and in section 5.4 is a motivation of what method was chosen.

5.1 Direct-attack

In this approach, an ECA rule is treated as a single component as opposed to the

side-attack method, where each ECA rule constituent is treated individually. The

direct-attack is based on extracting loose-ECA rules from each of UML’s diagrams. To

minimize the number of relevant diagrams (a diagram such as a component diagram is

unsuitable for an analysis to extract loose-ECA rules since it does not express features

relevant to ECA rules), each of UML´s diagrams are evaluated to see which diagrams

have the potential to produce loose-ECA rules. The loose-ECA rules drawn from the

relevant diagrams are then processed to obtain a firm-ECA rule. An algorithm may

then be produced based on the resulting firm-ECA rules and further, be deployed on a

real-life UML diagrams.

20

The direct-attack includes the following steps:

i. Diagram’s

relevancy

ii. Analysis

iii.

Grouping loose-ECA rules

iv.

Combining loose-ECA rules

v.

Combining firm-ECA rules

vi.

Development of algorithm

vii. Validation

i) Diagram’s

relevancy

For a diagram to be recognised as suitable for extracting ECA rules, it has to provide

at least one of the following features:

Variables. A variable may be in the form of a class’s attribute, a constraint on

class association, constraint on a variable etc.

Functionality. Functionality can be operations, transitions, creation, deletion

and modification of a record.

Even though a diagram does support previously mentioned features, but after a

thorough consideration is not assumed suitable for further use, the diagram should be

concluded as not relevant to extracting ECA rules.

ii) Analysis. The UML diagrams are analysed to see if loose-ECA rules can be

produced from them. Even if the information extracted from a diagram is not

sufficient for formulating an ECA rule, the rule will still be presented in the

event-condition-action form (figure 5.1). The absence of a definition for the different part

of a loose-ECA rule is marked for later use. Each produced loose-ECA rule is linked

to its associated diagram, and its definition is outlined with both textual and graphical

representation.

iii)

Grouping loose-ECA rules.

After the analysis, loose-ECA rules coupled with diagrams have been obtained. To

enable the combination of loose-ECA rules into a firm-ECA rule, the loose-ECA rules

must be grouped according to what application type they belong to (figure 5.2). Each

loose-ECA rule is evaluated and grouped independently and may only be associated

with one application type.

21

Figure 5.1 The analysis phase of the direct-attack method.

Figure 5.2 The grouping of loose-ECA rules in the direct-attack method.

Grouping of loose-ECA rules

loose-ECA rules are grouped into three different application types according to

their functionality.

External

applications

e

-c

-a

e

-c

-a

e

-c

-a

Extended

applications

e

-c

-a

e

-c

-a

e

-c

-a

Internal

applications

e

-c

-a

e

-c

-a

Analysis

ECA rules are extracted from those diagrams types that have been marked as

relevant for extracting ECA rules.

DiagramType 1

e

-c

-a

e

-c

-a

e

-c

-a

DiagramType 2

e

-c

-a

e

-c

-a

DiagramType 3

e

-c

-a

e

-c

-a

e

-c

-a

22

Figure 5.3 The combination of loose-ECA rules in both direct-attack and side-attack method.

Figure 5.4 The figure describes how firm-ECA rules are combined according to the sharing

of the condition-action part of the rule. This applies to both direct-attack and side-attack

method.

iv)

Combining loose-ECA rules.

The loose-ECA rules in every application type must be investigated towards other

loose-ECA rules within the same application type, to combine loose-ECA rules in

order to achieve rules where the ECA components are all defined (figure 5.3). This is

done by searching for a mutual definition of the event component, or by recognising a

coupling between a number of loose-ECA rules by investigating their source (i.e. the

Combining firm-ECA rules

e

-c

-a

if c

= c

AND a

= a

e

e

-c

-a

c

-a

(i /

j)

e

If two different

ECA rules have the same condition-action part, they are combined.

Combining loose-ECA rules

The loose-ECA rules are formulated in the way that if definitions for a

component of the loose-ECA rule is missing, the component is marked

with the first letter of the component in capital for every instance of a

missing definition.

The resulting rules will have all their components defined (frim-ECA rules),

otherwise, the loose-ECA rules are unfit.

External

applications

e

-c

-a

e

-c

-a

Extended

applications

e

-c

-a

e

-c

-a

Internal

applications

e

-c

-a

e

-c

-a

External

applications

e

-C-a

E-c

-A

e

-c

-a

Extended

applications

e

-c

-a

E-c

-A

e

-C-a

Internal

applications

e

-c

-a

e

-c

-a

23

associated diagrams and their features). The resulting rules from this step are

firm-ECA rules, which indicates that all of a rule’s components have been defined.

v) Combining

firm-ECA rules.

The ECA rules produced from the previous step are combined by their mutual

condition-action part (figure 5.4). This combination minimizes the number of ECA

rules, since many events can share the same condition and actions. This combination

is important to the administration of rules since the less rules to administer, the better.

Also, the ECA rules must be stored in a rule base where the condition-action part is

linked to an event representing the system state and the same link can be shared by

those rules that have the same condition-action part.

vi)

Development of algorithm. A connection between diagrams producing

different components, is established. If more than one diagram includes the same

component definition, it must be decided which of the diagrams the respective

component definition should be produced from. The recognition of the connection

between different diagrams when considering the formulation of an ECA rule, is vital

to the development of algorithm since it can be assumed that a strong coupling may

be considered static (static coupling can be expressed with an algorithm). It is of high

importance during the solution of this phase that all extracted ECA rules and their

components can be traced back to its originating diagrams. The previous phases must

be looked at to recognise a coupling between the diagrams’s features regarding the

formulation of ECA rules. A coupling must be represented in an algorithmic way, in

order to achieve the final phase, the validation. This phase might be hard to solve,

and if so, it might be efficient to perform it parallel to the validation phase.

vii) Validation. The final step involves validating the resulting algorithm(s)

against real-life UML modelling diagrams. The requirements on those modelling

diagrams that will be is used are that all diagrams evaluated as relevant (see step i) in

section 5.1) are available.

5.2 Side-attack

With this method, the ECA rule form is decomposed into its three constituents; an

event, a condition and an action.

Event. An event is a change of the system state. The system state is a set of values

(Ceri and Fraternali, 1997) and if only one of these values changes, the system state is

changed to another state. Therefore, the assumption can be drown, that the changing

of a variable’s value may be interpreted as an event.

Condition. A condition is a constraint on a variable’s value. This variable can be an

attribute in a class, a variable representing multiplicity between classes (Ceri and

Fraternali, 1997) and also, a variable representing the changed value which triggered

the event associated with the condition. A condition may be a valuation between a

variable an a static value, or between two variables. In some cases, the condition is

set to the constant value true (Ceri and Fraternali, 1997) which causes the execution

of the action whenever the event is triggered.

24

Action. An action is an operation. An action can be an operation within the scope of

classes or belonging to the systems external functionality (f ex checking authority,

free space, status of the hardware, and so on).

The UML diagrams are analysed for each constituent. As in the direct-attack method,

each of UML’s diagrams must be evaluated as relevant or not. The diagrams must be

connected internally with respect to the ECA rule constituents that they produce, in

such a way that a complete ECA rule can be formulated.

To recognise the support UML has for formulation of decomposed ECA rules, the

following steps are taken:

i. Diagram’s

relevancy

ii. Analysis

iii.

Grouping of ECA constituents

iv.

Combining ECA constituents

v.

Combining loose-ECA rules

vi.

Combining firm-ECA rules

vii.

Development of algorithm

viii. Validation

i)

Diagram’s relevancy. Identical to step i in section 5.1.

ii) Analysis. Every relevant UML diagram is analysed with respect to each of

the three constituents of an ECA rule. The constituents extracted from a diagram

should not be coupled with other constituents in order to form a loose-ECA rule

(figure 5.5). The diagrams should be investigated against one constituent at a time,

i.e. extract all possible definitions for the event constituent, then extract the condition

constituent and finally the action constituent. The definition of a constituent and its

associated diagram is represented textually and graphically.

iii)

Grouping of ECA constituents. Each constituent must be looked at to

determine to which application type it belongs (figure 5.6). This is similar to step ii in

section 5.1, except that in the side-attack method the grouping concentrates on the

constituents in stead of loose-ECA rules as in the direct-attack method.

iv) Combining

ECA

constituents. To combine the ECA rule constituents so that

they form a complete ECA rule requires that each event constituent must be linked to

a condition and an action constituents (figure 5.7). Observe that the condition will not

be linked to an action, since the event is the trigger of the rule and its coupling to the

action is much stronger than the coupling between a condition and an action.

The only constraints on the linked constituents are that they have previously been

grouped into the same application type. When all constituents have been associated in

loose-ECA rules, the results are presented in a structured way where all ECA rules

constituents are linked to theirs originating diagram.

v)

Combining loose-ECA rules. Identical to step iv in section 5.1.

vi)

Combining firm-ECA rules. Identical to step v in section 5.1.

25

viii) Validation. Identical to step vii in section 5.1.

Figure 5.5 Extracting ECA rules when using ECA rule constituents.

Figure 5.6 The grouping of ECA constituents in the side-attack method.

Figure 5.7 The combination of ECA constituents to form loose-ECA rules in the side-attack

method.

Analysis

The constituents event, condition and action are extracted from UML diagrams

DiagramType 1

e

e

a

c

e

c

a

e

c

a

DiagramType 2

c

a

e

c

e

c

a

DiagramType 3

e

c

a

e

a

e

a

iv)

Combining ECA constituents

Each event constituent is analysed to investigate weather or not it can be linked to a

condition and an event constituent.

External

applications

e

-c

-a

e

-c

-a

e

-t-a

Extended

applications

e

-c

-a

e

-c

-0

e

-c

-a

Internal

applications

e

-c

-a

e

—c

—a

e

-c

-a

e

-t-a

Grouping of ECA constituents

The extracted constituents are grouped by application type.

External

applications

e

e

e

a

c

c

a

a

a

Extended

applications

e

e

c

c

c

a

a

Internal

applications

e

e

e

c

c

a

a