Using UML for Writing and Reasoning about ODP Policies

Javier Herrador, Francisco Durán, Antonio VallecilloFelipe García, Manuel Roldán

Dept. Lenguajes y Ciencias de la Computación

Universidad de Málagaav@lcc.uma.es

POLICY 2003

Como, June 2003 POLICY 2003 2

Agenda

1. The ODP Enterprise Viewpoint 2. Modeling ODP E-L concepts in UML3. Maude – a formal notation4. Mapping the UML drawings to Maude

formal specifications5. A tool for automating the translation

(and for accessing some formal analysis tools from a UML environment)

Como, June 2003 POLICY 2003 3

The ODP Enterprise Viewpoint

The ODP viewpoint in charge of business system modeling

Focuses on the purpose, scope and policies for the system and its environment

Describes the business requirements and

how to meet them, abstracting away other considerations (implementation details, technology used, etc.)

Como, June 2003 POLICY 2003 4

The ODP enterprise specification Specifies the roles played by an IT

system in its organizational environment An object model of a social/commercial

organization, expressed in terms of communities (collections of enterprise objects) with a defined contract: Objective Structure (roles) Behavior Policies

Como, June 2003 POLICY 2003 5

Main concepts in EV specs Object -- a model of an entity Community -- configuration of E-objects Role -- identifier of a behavior Action -- something that happens Step -- abstraction of an action Process -- set of steps (->objective) Policy -- constraints on behavior/

membership Accountability -- parties, delegation, etc.

Como, June 2003 POLICY 2003 6

Building EV specs (one possible way)

1. Identify the communities, the roles in them, and their relationships

2. Identify the objects in each community, and how they fill the roles

3. Identify the possible actions, and the participant objects in those actions

4. Identify the system policies5. Identify the accountable parties for the

actions (principals, agents,...)

Como, June 2003 POLICY 2003 7

Policy concepts

Policy: “A set of rules related to a particular purpose”

Policies can be expressed in ODP as: Obligations Authorizations Permissions Prohibitions

Violation: an action (or inaction) contrary to a rule

Como, June 2003 POLICY 2003 8

Writing ODP E-L specifications RM-ODP does not prescribe any particular

notation for expressing viewpoint specifications

UML is sexy enough and widely accepted But its semantics are imprecise and

ambiguous

Formal methods are not widely accepted But they allow precise specifications, and nice

analysis of the systems being modeled

Como, June 2003 POLICY 2003 9

Our proposal Define a subset of UML that models the ODP

Enterprise Language concepts Formalize the concepts in a formal notation

(Maude) Define a mapping from the subset of UML to

Maude (i.e. provide a clear semantics to those UML concepts)

Build a tool that allows the user to “draw” the ODP enterprise specifications of a system In UML, but with precise semantics With access to some formal analysis tools (e.g., quick

prototyping and model-checking)

Como, June 2003 POLICY 2003 10

Modeling E-L structural concepts in UML

Enterprise object Object instance (of a class that inherits from the UML classes modeling the roles that the object may fulfill)

Role Class (stereotyped «role»)

Community Subsystem (stereotyped «community»)

Relationship among roles (from GRM)

Relationship/Assoc. class (stereotyped «relationship»)

Membership policies

Constraints /relationship multiplicity

Como, June 2003 POLICY 2003 11

Modeling E-L behavioral concepts in UML

Action Paired object diagram (“Snapshot”)(describing the participant objects and the effects of the action)

Process Set of snapshot diagrams (& strategies)

Policies Constraints and “guards” of snapshot diagrams

Violations Watchdog rules (snapshot diagrams)

Como, June 2003 POLICY 2003 12

A library example - structure

<<community>>

The Library

<<role>>Borrower

+bookLoanPeriod : Date+borrowedItems : int+fines : Money+maxLoans : int+periodicalLoanPeriod : Date+suspended : boolean

<<relationship>>Loan

+dueDate : Date+issueDate : Date

<<role>>Book

<<role>>Item

+free : boolean

<<role>>Library

<<role>>Periodical

<<role>>Calendar

+date : Date

1 * 1 1

** *

1

Policy 1:No more than one clock in the system

Policy 2:One item can only be borrowed by one borrowersimultaneously

Policy 3:A borrower may have several items on loan simultaneously

Como, June 2003 POLICY 2003 13

An action example: “return”

Return-before

L: Library

A: Loan

I: Item

free = false

B: Borrower

borrowedItems = N

Return-after

L: Library

I: Item

free = true

B: Borrower

borrowedItems = N - 1

return

Pre-conditions of

the action

Effects of the action

Como, June 2003 POLICY 2003 14

An action example: “borrow”

Borrow-after

B: Borrower

borrowedItems = N+1

I: Item

free = false

L: Library

A: Loan

dueDate = Today + BLissueDate = Today

C: Calendar

Borrow-before

B: Borrower

borrowedItems = Nsuspended = falsebookLoanPeriod = BLmaxLoans = ML

I: Item

free = true

L: LibraryC: Calendar

date = Today

if N < ML .borrow

Policy 4:Suspended borrowers are not allowed to borrow items(prohibition) Policy 6:

The number of borrowed items cannot exceed the borrower’s maximum allowances(prohibition)

Policy 5:Only free items can be borrowed(permission+ prohibition)

Como, June 2003 POLICY 2003 15

Maude

Formal notation (and system) that supports equational and rewriting logic specification and programming

Supports Object-Oriented specifications and computations objects: < O : C | a1 : v1, ..., an : vn > classes: class C | a1 : S1, ..., an : Sn . messages: msg id : S1 ... Sm -> Msg .

Como, June 2003 POLICY 2003 16

Maude “configurations”

A configuration is a multiset of objects and messages that evolves by rewriting rules

class Account | balance : Int .msg deposit : Oid Int -> Msg .

crl [1] : < O : Account | balance : N > deposit(O,M)

=> < O : Account | balance : N + M >

if M > 0 .

Como, June 2003 POLICY 2003 17

Translating UML concepts to Maude

Object instance Object (of a class modeling all the roles that the object may fullfil)

Class («role») ClassSubsystem («community»)

Module

Relationship («relationship»)

Class

Class Sort (ADT)Association (binary) Class attributesAssoc. multiplicity Sort of attributesConstraints “valid” configuration

sortPaired object diagram(“snapshot”)

Rewriting rule

Como, June 2003 POLICY 2003 18

The Library example in Maude

(omod TheLibrary is class Library | borrowers : Set(Oid), calendar : Oid, items : Set(Oid), loans : Set(Oid) . class Calendar | date : Date . class Item | free : Bool, loan : Default(Oid) . classes Periodical Book . subclasses Periodical Book < Item . .........

<<community>>

The Library

<<role>>Borrower

+bookLoanPeriod : Date+borrowedItems : int+fines : Money+maxLoans : int+periodicalLoanPeriod : Date+suspended : boolean

<<relationship>>Loan

+dueDate : Date+issueDate : Date

<<role>>Book

<<role>>Item

+free : boolean

<<role>>Library

<<role>>Periodical

<<role>>Calendar

+date : Date

1 * 1 1

** *

1

Como, June 2003 POLICY 2003 19

“Return”

Return-before

L: Library

A: Loan

I: Item

free = false

B: Borrower

borrowedItems = N

Return-after

L: Library

I: Item

free = true

B: Borrower

borrowedItems = N - 1

return

rl [return] : < L : Library | items : I IS,

loans : A LLS, borrowers: B BS > < B : Borrower | loans : A BLS, borrowedItems : N > < A : Loan | borrower : B, item : I > < I : Item | loan : A >=> < L : Library | loans : LLS > < B : Borrower | loans : BLS, borrowedItems : N – 1> < I : Item | free : true, loan : null > .

Como, June 2003 POLICY 2003 20

“Borrow” crl [borrow] : < B : Borrower | borrowedItems : N, maxLoans : ML, loans : BLS, bookLoanPeriod : BL, suspended : false > < I : Item | free : true, loan : null > < L : Library | items : I IS, calendar : C, borrowers : B BS, librarians : O OL, loans : LLS > < C : Calendar | date : Today > => < B : Borrower | loans : A BLS, borrowedItems : N + 1 > < I : Item | free : false, loan : A > < L : Library | loans : A LLS > < C : Calendar | > < A : Loan | borrower : B, item : I, dueDate : Today + BL, issueDate : Today > if N < ML .

Borrow-after

B: Borrower

borrowedItems = N+1

I: Item

free = false

L: Library

A: Loan

dueDate = Today + BLissueDate = Today

C: Calendar

Borrow-before

B: Borrower

borrowedItems = Nsuspended = falsebookLoanPeriod = BLmaxLoans = ML

I: Item

free = true

L: LibraryC: Calendar

date = Today

if N < ML .borrow

Como, June 2003 POLICY 2003 21

And now...what can we do?

Check that the UML Enterprise specifications are well-formed (attributes have correct types, association multiplicities are given, etc.)

“Execute” the specs (quick prototyping) Maude allows a wide variety of strategies for

execution (by default and user-defined) Reachability analysis (search)

Looking for specific violations/unwanted states Model checking

Using the Maude LTL model checker

Como, June 2003 POLICY 2003 22

Example of system execution

Init1-Before

J oe: Borrower

borrowedItems = 10fines = 0suspended = falsebookLoanPeriod = 40maxLoans = 24

Clock: Calendar

date = 10

Louis : Borrower

borrowedItems = 1fines = 100suspended = falsebookLoanPeriod = 30maxLoans = 16

Loan1: Loan

dueDate = 40issueDate = 10

Ulysses : Book{free = false}

Templeman: Library

Dubliners : Book{free = true}

Init1-After

50

Como, June 2003 POLICY 2003 23

Executing the system (result config)

Init1-After

Templeman: LibraryClock: Calendar

date = 42

J oe: Borrower

borrowedItems = 2fines = 0suspended = falsebookLoanPeriod = 82periodicalLoanPeriodmaxLoans = 24

Louis : Borrower

borrowedItems = 1fines = 100suspended = falsebookLoanPeriod = 30periodicalLoanPeriod = 20maxLoans = 16

Dubliners : Book{free = false}

Ulysses : Book{free = false}

Loan4: Loan

dueDate = 82issueDate = 42

Loan5: Loan

dueDate = 82issueDate = 42

Como, June 2003 POLICY 2003 24

Strategies for execution Maude’s refective capabilities are of

great help For knowing the actions in which objects can

engage in, both statically, and during run-time

Execution strategies can decide priorities for selecting the rules to apply in each situation

Rule execution can be monitored, detecting unwanted actions

But this process is not simple... We are working on making it accessible from

the UML environment

Como, June 2003 POLICY 2003 25

Checking policy violations Permissions/Authorizations

Only explicitly stated rules are permitted This implicitly forbids any action not specified by a rule

Prohibitions Either stated in the rule pre-conditions & guards (and

hence will never happen) Or can be checked by:

The type system, in case of invalid configurations Watchdog rules, that are triggered on the occurrence of

violations (they monitor the effects of the violating actions)

The search or model checking tools Obligations

Watchdog rules can check that the action is performed

Como, June 2003 POLICY 2003 26

Example of delegation

class NormalUser | ... .class AllowedUser | ... . rl [action] < O : AllowedUser | ... > ... => ... .

class Authority | ... .class Authorized | grantor : Oid .subclass Authorized < AllowedUser .rl [delegate] : < A : Authority | ... >

< O : NormalUser | ... > => < A : Authority | > < O : Authorized | grantor :

A, ... > if ... .

Como, June 2003 POLICY 2003 27

Conclusions We have presented a tool for the graphical

specification of business systems using the ODP Enterprise Viewpoint concepts

Better representation of ODP E-L concepts Configurations capture collective state and behavior Actions are not limited to object operations Policies are more than UML “notes”

More precise semantics for the UML drawings given by their Maude interpretation

Access to some formal analysis tools from UML well-formed specifications, system

execution/prototyping, model checking, ...

Como, June 2003 POLICY 2003 28

Current limitations & future work Our work is still at a preliminary stage

Encouraging results... but with simple examples only

No modular description of policies “Hard-coded” in the UML class & snapshot diagrams No expression for objectives so far

(in ODP, they are expressed as “preferences about future states”)

Limited detection (and resolution) of policy conflicts >> We are looking for an appropriate POLICY language!

Connection to other ODP viewpoints Information and Computational viewpoints New ISO work item on “Use of UML for ODP viewpoints

specifications”