Krzysztof Kluza kluza@agh.edu.pl, Grzegorz J. Nalepa gjn@agh.edu.pl

• Intro
• Basics
  • UML
  • MOF
  • OCL
• Challenges
• Rules in UML
  • URML
  • PRR
• BPMN & BR
• HeKatE
  • ARD & XTT rep
  • metamodel
  • future work

• abstract level of design
• visual modeling → this is not obvious! see Literate_programming
• programming paradigms → different design paradigms
• knowledge vs. software engineering
• declarative vs. procedural, etc.

• History of UML (1995-2009) Graph of OO methods and notations history

• UML predecessors: OMT (by Rumbaugh), Booch Diagrams (by Booch), OOSE (by Jacobson)

Example of Booch class diagram	Example of OMT object diagram

• general-purpose modeling language in the field of software engineering,
• 13 types of diagrams,
• includes a set of graphical notation techniques to create abstract models of specific systems.

• model - representation of something, constructed and used for a particular purpose,
  • the meaning of the model is related to the situation and context wherein the model is used,
• metamodel - a model that represents a modeling language,
• MOF
  • an OMG standard for model-driven engineering,
  • designed as a four-layered architecture,
  • UML & OCL are defined in MOF.

• language
  • declarative language for describing rules that apply to UML models,
  • a constraint language (OCL 1.4)
  • + general object query language (OCL 2.0)
• part of OMG UML standard (may be used with any MOF),
• makes a Meta-Object Facility model more precise,
• example:
  The academic grade of a persons supervisor must be greater than the academic grade of the supervised person.

context Person
   inv: self.supervisor.grade.value > self.grade.value

• UML/MOF → lang + metalang level. universal
• if MOF is a universal metalang, what about EBNF
• suitability for process modeling
• suitability for knowledge modeling with rules

• approaches in publications:
  • grammar visualization (mapping)
  • metamodel optimalization (semi-automatic)
    • after auto generation
    • before auto generation

• more: look for our research in wiki https://ai.ia.agh.edu.pl/wiki/student:msc2009_umlrep:ebnf_mof

program:	(vardefinition | assignment)*
vardefinition: 	type IDENT !SEMICOLON
type: 		(INT | FLOAT)
assignment: 	IDENT !BECOMES expression !SEMICOLON
expression: 	(IDENT | NUMBER) (PLUS expression)?

• developed by the REWERSE Working Group I1,
• allows visual rule modeling based on UML class models,
• supports the modeling of derivation rules conditions→conclusions, production rules conditions→action and reaction rules condition|event→action|postcondition,
• Strelka – a tool for making graphical URML models.

A bachelor is a male that is not a husband.

If the reservation date of a rental is 5 days before the start date of a rental, then grant the rental a discount of 10.

• http://rewerse.net/I1/oxygen.informatik.tu-cottbus.de/rewerse-i1/@q=urml.htm
• extends UML class diagrams,
• single rules,
• non-standard → tool support ( Strelka - plugin for Fujaba),
• rules serialized to R2ML,
• in the future translations: R2ML ↔ OCL and R2ML↔OWL/SWRL

A production rule is a statement of programming logic that specifies the execution of one or more actions in the case that its conditions are satisfied.

• PRR should improve the modeling of production rules, especially with respect to UML,
• PRR should allow interoperability across different vendors providing production rule implementations.

The production rule is typically represented as:

if [condition-list] then [action-list]

• English text: If there is no CD item in the customer shopping cart then add a hyperlink to the CD page in the customer web page.
• Proprietary rule language:

rule noCDItem {
 when { 
    ?customer1: Customer(); 
    ?shoppingCart1: ShoppingCart(customer == ?customer1); 
    not Item(type == ItemType.CD ; shoppingCart == ?shoppingCart1);
 } then { 
    modify ?customer1{ hyperlinkToCD = true; }
 } 
}

• PRR OCL:

Rule noCDItem
ruleVariable:
 ?customer: Customer = Customer->any()
 ?sCart: ShoppingCart = ShoppingCart->any(c:customer|c=?customer)
 ?cdItems: Set = ?sCart.items->select(e:items|e.type=ItemType.CD)
Condition:
 ?cdItems.isEmpty()
Action:
 ?customer.hyperlinkToCD = true

• no common agreement about the syntax of PRR,
• different syntaxes, but common metamodel ⇒ translation between different syntaxes,
• no defined PRR syntax ⇒ can be URML.

• a graphical notation for specifying business processes in a Business Process Diagram (BPD),
• is intuitive to business users and able to represent complex process semantics,
• provides a mapping between the graphics of the notation to the underlying constructs of execution languages, particularly Business Process Execution Language.

• notation dedicated for business org (semantic for business org),
• only one diagram BPD, but many artifacts → allows specify even complex processes,
• formal notation → simulation, optimalization & error detection,
• automatic generation of BPEL4WS (Business Process Execution Language for Web Services) code,
• lack of security support for data structure, users hierarchy and access to data.

• describe the operations, definitions and constraints that apply to an organization in achieving its goals,
• four categories of BR according to Business Rules Group:
  • definitions of business terms,
  • facts relating terms to each other,
  • constraints,
  • derivations.

Example of detailed business rule from http://www.agilemodeling.com/artifacts/businessRule.htm

The description defines the rule exactly (text, flow charts, UML activity diagrams, OCL, ILOG rules language, BRML…).

• UML model

• OCL – a formal language used to describe expressions on models eg. constraint:

The lower bound must be a non-negative integer literal.

lowerBound()->notEmpty() implies lowerBound() >= 0

• many dedicated approaches like presented URML, PRR…

UServ Financial Services case study:

• a benchmark case study from the Business Rules Forum,
• provides a full service portfolio of financial products of Insurance Company,
• contains many business rules and Business Process Models,
• more: hekate_case_userv.

Example for Eligibility Business Rules / Automobile Eligibility / Potential Theft Category eg.

• If all of the following are true, then the car's potential theft rating is moderate:
  • car's price is between $20,000 and $45,000,
  • car model is not on the list of “High Theft Probability Auto”.

• ARD & XTT representation in UML,
• ARD & XTT rules on UML diagrams presentation,
• integration of software & knowledge engineering methods.

Proposed model of ARD is based on component diagrams. ARD contains diferent kind of UML dependencies such as:

• «derive» specifies a derivation relationship among model elements, where one of them can be computed from the another,
• «refine» specifies a refinement relationship among model elements at different levels of development; refinement can be used to model transformation from one to another phase of a sequential model development,
• «trace» specifies a trace relationship among model elements represents the same concept in different models; it is mainly used for tracking changes across models.

Example of ARD diagram:
<graphviz file=“hekate:therm-a8.dot”></graphviz>

UML model of that ARD diagram:

Exemplary fragment of TPH diagram showing «trace» dependecy in model:

Proposed model of XTT is based on activity diagrams, which are related to flow diagrams and can illustrate the activities taking place in the system.

• Outline of XTT2UML translation algorithm (on the example of thermostat).
• UML2XTT translation is more complex. see: UML2XTT translation specification
• Proposed model and algorithm is developed also for more complex cases. see: Model of table with many outputs

All input attributes become input parameters and output attribute becomes output parameter of an activity
(for the sake of transparency the diagram can be divided into partitions with a swimlane).

For each attribute (activity parameter), if there is more than one unique value in the XTT add a decision node
and for every unique value of attribute needs to be added:

• the control flow with guard condition (with that unique value),
• if the value occurs frequently, the flow is finished with a fork node with number of outputs equal to the number of times the value appears in XTT table.

For each rule (a row in XTT) draw a join node with the number of inputs equal to the number of input parameters and one output. For each join node:

• inputs are connected using an adequate flow (in accordance with the values of attributes in the rule),
• outputs are connected (using a flow) with the action having a value corresponding to the output attribute in the rule:
  • directly, if the value of attribute occurred in XTT only once,
  • otherwise through a merge node.

Outputs of all actions are merged in a merge node and a flow is lead to output parameter of activity.

Activity diagram for the whole XTT of thermostat:

Proposed representation:

• shows both structure of dependecies in ARD and process of rules processing in XTT,
• doesn't extend UML diagrams (like URML),
• allows serialization to XMI.

• metamodel,
• XSTL translators,
• tools for verifing models with metamodel,
• work in progress…

Questions…