Using UML for Writing and Reasoning about ODP Policies Javier Herrador, Francisco Durán, Antonio Vallecillo Felipe García, Manuel Roldán Dept. Lenguajes y Ciencias de la Computación Universidad de Málaga POLICY 2003

Como, June 2003POLICY Agenda 1.The ODP Enterprise Viewpoint 2.Modeling ODP E-L concepts in UML 3.Maude – a formal notation 4.Mapping the UML drawings to Maude formal specifications 5.A tool for automating the translation (and for accessing some formal analysis tools from a UML environment)

Como, June 2003POLICY 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 2003POLICY 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 2003POLICY 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 2003POLICY 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 policies 5. Identify the accountable parties for the actions (principals, agents,...)

Como, June 2003POLICY 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 2003POLICY 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 2003POLICY 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 2003POLICY 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 2003POLICY 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 2003POLICY A library example - structure Policy 1: No more than one clock in the system Policy 2: One item can only be borrowed by one borrower simultaneously Policy 3: A borrower may have several items on loan simultaneously

Como, June 2003POLICY An action example: “return” Pre-conditions of the action Effects of the action

Como, June 2003POLICY An action example: “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 2003POLICY Maude Formal notation (and system) that supports equational and rewriting logic specification and programming Supports Object-Oriented specifications and computations objects: classes: class C | a 1 : S 1,..., a n : S n. messages: msg id : S 1... S m -> Msg.

Como, June 2003POLICY 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] : deposit(O,M) => if M > 0.

Como, June 2003POLICY Translating UML concepts to Maude Object instance Object (of a class modeling all the roles that the object may fullfil) Class («role») Class Subsystem («community») Module Relationship («relationship») Class Sort (ADT) Association (binary) Class attributes Assoc. multiplicity Sort of attributes Constraints “valid” configuration sort Paired object diagram (“snapshot”) Rewriting rule

Como, June 2003POLICY 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

Como, June 2003POLICY “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 > => < B : Borrower | loans : BLS, borrowedItems : N – 1> < I : Item | free : true, loan : null >.

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

Como, June 2003POLICY 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 2003POLICY Example of system execution

Como, June 2003POLICY Executing the system (result config)

Como, June 2003POLICY 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 2003POLICY 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 2003POLICY Example of delegation class NormalUser |.... class AllowedUser |.... rl [action]... =>.... class Authority |.... class Authorized | grantor : Oid. subclass Authorized < AllowedUser. rl [delegate] : => if....

Como, June 2003POLICY 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 2003POLICY 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”