Business Rules Separation and Reuse Using MDA, OWL and AspectJ paper accept on 20th International Symposium on Software Reliability Engineering.

1. Business Rules Separation and Reuse
Using MDA, OWL and AspectJ
Jaguaraci B. Silva and Luciano P. Barreto
{jaguarac,lportoba}@ufba.br
Project: Deacouple Business Rules in the MDA
Models Building
Federal University of Bahia (UFBA)
Department of Computer Science (DCC)
Distributed Systems Laboratory (LaSiD)

2. Motivation
• To ensure business rules/domain properties does not
violate the specified properties in the application
domain.
• Allows developers to both describe and corroborate
domain properties at run-time.
• Increase dependability because of MDA growth up in
several applications context.
• The business rules could not typically have been
cared by the implementation code produced
automatically.
2009-11 ISSRE 2009 2

3. Objectives
• Business rules separation, allows secure and automatic
way to insert final application code generated by
independent models (PIM).
• The business rules are defined on ontology domain and
are transformed in aspectJ. The aspects are merged
and compiled in a specific model (PSM).
• OWLToAspectJ: a tool that automatically translates
ontology business rules (OWL:Restrictions) in aspectJ.
2009-11 ISSRE 2009 3

4. Development Process Outline
2009-11 ISSRE 2009 4

5. Process Overview
(1) An ontology about application domain is conceived using a
ontology tool (Protégé) ODM-based (Ontology Definition
Metamodel) .
(2) The domain ontology generated into a platform independent
model (PIM) then is converted to UML language using ODM-UML
profile bridge.
(3) The PIM business rules will be transformed in a PSM model across
of OWLtoAspectJ tool. Diverse PSMs models can be generated,
being at less one:
– for business rules
– for other application PSM wished (e.g. Java SE, Java EE, RMI,
Corba).
(4) Finally, the code application combines the business rules and
application PSM using weaving process (Aspect-oriented
Programming).
2009-11 ISSRE 2009 5

6. Contributions
• In making an approach to emerging technologies
(MDA, OWL and AOP), was built a tool specifically for
it (OWLtoAspectJ).
• In this boarding, was add a set of activities to orient
the development process using MDA, OWL and AOP.
• Our approach uses OWL-DL and a reasoner tool
(Racer) instead of OCL. It helps to verify the domain
properties in a formal way for critical systems. The
UML language does not support it actually.
2009-11 ISSRE 2009 6

7. Case Study – Furnace Management Application
2009-11 ISSRE 2009 7

8. Case Study – Overview of Industrial Process
• Reengineering of industrial furnace management
application of Ferroalloys (e.g. Ferrochrome).
• For each alloys iron exist a recipe that has inputs (e.g.
carbon, chromium, silicon). Theses inputs are put on
in the industrial ovens in according to recipe made by
production analyst.
• Sensors sends the plan data for a programmable
logic controller (PLC) system managed.
2009-11 ISSRE 2009 8

9. Case Study – Domain Engineering Process
• Conceptual modeling of application domain
– Functional requirements and business rules analysis
– UML for knowledge representation
– Domain modeling using ontology
– Verification of domain properties
1. Domain modeling
• Definition of concepts, axioms, properties, relationship
between concepts
2. Verification of domain properties
• Business rules definition using PAL (Protégé Axiomatic
Language)
• Instance creations and business rules satisfatibility using
reasoner for knowledge validation
2009-11 ISSRE 2009 9

10. Case Study – Functional Requirements Analisys
2009-11 ISSRE 2009 10

11. Case Study – Knowledge Representation in UML
2009-11 ISSRE 2009 11

12. Case Study – Translation business rules to PAL
Business rules PAL
1- An oven should only produce one ∀Product.Is_made_in_Oven exactly 1
product by time.
2- During charge of ovens them should =Oven.Makes_a_Product exactly 1
produce exactly one product, should have inputs =Oven.Has_a_Recipe exactly 1
that are part of one specific recipe to one kind of
product. ∀Oven.Has_a_Recipe only Recipe
3– The oven is charge by the operator. ∀Oven.Is_Charged_by_Operator only
Operator
4 – An recipe has at less one input. ∀Recipe.Has_Input some Input
2009-11 ISSRE 2009 12

13. Case Study – Verification of Domain (Instance)
2009-11 ISSRE 2009 13

14. Case Study – Business Rules Validation
2009-11 ISSRE 2009 14

15. Case Study – PSM Building
• Generation of application domain from ontology to
OWL
– Classes, properties, relationship between classes, axioms
• Building PSM model to Java platform
– UML backend (Protégé plugin for XMI)
– Generate from PIM UML model to application Java code
importing domain model XMI using UML tool
• Building PSM model to business rules
– Separation and generation automatically of business rules
from conceptual domain in OWL-DL format
2009-11 ISSRE 2009 15

16. Case Study – Business rules in OWL format
<owl:
<owl:Restriction>
<owl:
<owl:onProperty>
<owl:
<owl:ObjectProperty rdf:ID=“Is_Stored_in_the_Silo"/>
rdf:
</owl:
</owl:onProperty>
<owl:maxCardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int"> 1
<owl: rdf:datatype="http://www. org/2001
2001/XMLSchema#int">
</owl:
</owl:maxCardinality>
</owl:
</owl:Restriction>
<owl:
<owl:ObjectProperty rdf:about="#Is_Stored_in_the_Silo">
rdf:
<rdfs:
<rdfs:domain rdf:resource="#Input"/>
rdf:
<rdfs:
<rdfs:range rdf:resource="#Silo"/>
rdf:
<owl:
<owl:inverseOf rdf:resource="#Has_Input"/>
rdf:
</owl:
</owl:ObjectProperty>
2009-11 ISSRE 2009 16

17. Case Study – OWLtoAspectJ tool
2009-11 ISSRE 2009 17

18. Case Study – Business rules translated to aspectJ
package businessRules;
import furnace.Operator;
public aspect Oven_Is_Charged_by_Operator {
public pointcut Operator() :
call(* *.*Oven(..)) &&
(!(call(* *.getOven(*)) || call(* *.setOven(*))));
before():Operator() {
Object obj = thisJoinPoint.getTarget();
if (!(obj instanceof Operator)){
System.out.print("n Exception Rule:
FornoE_carregado_por_Operador");
}
}
}
2009-11 ISSRE 2009 18

19. Case Study – Business rules validation in run-time
2009-11 ISSRE 2009 19

20. Related works
• AOP and MDA:
– Crosscut concerns (non-functional requirements) and
business rules [CALA-INRIA]
– PSM models generation in LOA (Aspect-oriented Language)
[CALA-INRIA, LASID-UFBA]
• MDA and OWL:
– Domain modeling and reuse using ontology [OMG]
– Bridge between OWL and UML using ODM profile [LORE-
SFU Surrey]
– UML formalization using OWL-DL [Cin-UFPE, LASID-UFBA]
2009-11 ISSRE 2009 20

21. Conclusion
• Across of needs to check the domain properties
defined for dependability of critical systems, was
created a domain modeling process ontology-based.
• The definition of business rules by an ontology editor
and validations them using reasoner (Racer), has
warranty of functional requirements understading.
• Business rules extraction and validation before
generating the PSMs on PIM level (OWL ontology).
Improved reuse of business rules easier and can
avoid implementation code fail because it is
generates automatically in final application code.
2009-11 ISSRE 2009 21

22. Future works
• The business rules formalization before translates it
to aspectJ for full warranty dependability them.
• Aspects concorrency evaluation from view point of
business rules overlap.
• OWLtoAspectJ improve to standardize the violation
messages and building a rules repository to merge
rules in software produtc lines.
• Other works in progress in LASID involving formal
verification and model transformation.
2009-11 ISSRE 2009 22

23. Business Rules Separation and Reuse
Using MDA, OWL and AspectJ
Jaguaraci B. Silva and Luciano P. Barreto
{jaguarac,lportoba}@ufba.br
Project: Deacouple Business Rules in the MDA
Models Building
Federal University of Bahia (UFBA)
Department of Computer Science (DCC)
Distributed Systems Laboratory (LaSiD)