1. 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 av@lcc.uma.es POLICY 2003

2. Como, June 2003POLICY 20032 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)

3. Como, June 2003POLICY 20033 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.)

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

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

6. Como, June 2003POLICY 20036 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,...)

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

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

9. Como, June 2003POLICY 20039 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)

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

11. Como, June 2003POLICY 200311 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)

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

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

14. Como, June 2003POLICY 200314 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 )

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

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

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

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

19. Como, June 2003POLICY 200319 “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 >.

20. Como, June 2003POLICY 200320 “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.

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

22. Como, June 2003POLICY 200322 Example of system execution

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

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

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

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

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

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