From Declarative to Imperative Operation Specifications (ER 2007)

From Declarative to Imperative UML/OCL Operation Specifications Jordi Cabot Open University of Catalonia

Index Introduction Motivation Our approach (1) : Disambiguate Our approach (2) : Generate Inherently ambiguous postconditions Discussion Conclusions

Introduction There are two different approaches to specify the effect of an operation over the system state: the declarative and the imperative approaches In an imperative specification the designer explicitly defines the set of actions (i.e. structural events:insert,update,delete) to be applied over the system state For declarative specifications the designer defines a contract (set of pre and postconditions). A postcondition states the set of conditions to be satisfied by the system state at the end of the operation execution From a specification point of view, declarative specifications are preferable (they are more concise and abstract) BUT: Declarative specifications are underspecifications (there are several possible final states satisfying the postcondition) This is specially relevant in OCL contracts due to the OCL expressiveness This hinders the practical use of declarative specifications

Motivation: Expected behavior of GoalEvaluation ? context Department::GoalEvaluation() post : self.sumSales=self.employee.sales.amount->sum() and if self.sumSales>self.goal then self.employee->forAll(e| e.salary= e.salary@pre + e.category.raise) else self.carFleet->excludesAll(Car::allInstances->select(c| c.type=‘Luxury’)) endif Or where we change the category where the employee belongs to Final states where not referenced objects are modified also satisfy the postcondition Or final states where we assign a zero value to sumSales and remove all sales from the employees Or where we remove the employees of a department Or final states where the id of the department is modified Or when we add/remove non-luxury cars to the department (or remove all cars) If employees have sold enough to fulfill the goal, their salary is increased as indicated by their category. Otherwise, employees are not longer allowed to use luxury cars

Motivation OCL WORKSHOP at MODELS’06 -- withdraw gives the customer money if there is enough money in the account. The return value indicates whether the withdrawal was successful or not. context ATMController::withdraw(amount:Real) : Boolean post : if (amount <= customer.account.balance) then customer.account.balance = customer.account.balance@pre – amount result:=true . . . BOOK: The Object Constraint Language. Kleppe and Warmer context LoyaltyProgram::addService(p: ProgramPartner, s: Service) pre: partners->includes( p ) post: partners.deliveredServices->includes( s ) . . .

My approach (1) : Disambiguate Given an operation op and an initial state s there exist a set of final states set s ’ that satisfy the postcondition of op. All states in set s ’ must be considered correct (from a theoretical point of view) But, most probably, only a small subset acc s  set s ’ would be regarded as correct by the designer. In general |acc s | = 1 (from the designer’s point of view there is only a possible final state when executing op over s ) GOAL1: To deduce the state s’  set s ’ that represents the expected behavior of the operation as intended by the designer Several heuristics to clarify the interpretation of declarative postconditions are proposed.

Heuristics The heuristics try to represent common assumptions used during the specification of operation contracts. Each heuristic disambiguates a problematic type of expression that may appear in a postcondition. The ambiguity is solved by providing a default interpretation for each expression. This default interpretation identifies, among all states satisfying it, the one that, most probably , represents what the modeler meant when defining it. With these heuristics, modelers do not need to write long and cumbersome postconditions to clearly specify the expected behavior of the operation. They can rely on our heuristic to be sure that, after the operation execution, the new state will be the one they intended.

Some heuristics X.a=Y (Order matters) Possible final states satisfying the postcondition: States where a takes the value of Y States where Y takes the value of a States where a value c is assigned to both a and Y Default interpretation: The desired state is the one where a takes the value of Y If X then Y (Do not falsify X) Possible final states satisfying the postcondition States where X is true and Y is true States where X is false Default interpretation: Do not falsify X Implementations where X is changed to ensure that it evaluates to false to avoid enforcing Y are not acceptable (even if it is easier!!)

Some heuristics X->forAll(Y) (Do not empty the source) Possible final states satisfying the postcondition: States where Y evaluates to true for all objects in X States where X is empty Default interpretation: Do not empty the collection X. A solution removing all objects in X is not acceptable X->includesAll(Y) (Minimum insertions) Possible final states satisfying the postcondition: States where Y is empty States where X includes all objects in Y States where X includes all objects in Y plus/less additional objects Default interpretation: No changes over Y and a maximum of Y->size() insertions over X

Some heuristics Other heuristics: Nothing else changes X->excludesAll(Y) | X->excludes(o) X.r1.r2…rn-1.rn=Y o.oclIsTypeOf(Cl) | o.oclIsKindOf(Cl) not o.oclIsTypeOf(Cl) | not o.oclIsKindOf(Cl)

Now, what is the expected behavior of Goal Evaluation ? If employees have sold enough to fulfill the goal, their salary is increased as indicated by their category. Otherwise, employees are not longer allowed to use luxury cars context Department::GoalEvaluation() post : self.sumSales=self.employee.sales.amount->sum() and if self.sumSales>self.goal then self.employee->forAll(e| e.salary= e.salary@pre + e.category.raise) else self.carFleet->excludesAll(Car::allInstances->select(c| c.type=‘Luxury’)) endif

My approach (2) : Generate In a MDD approach declarative operations must be transformed into imperative ones The imperative version of an operation op must evolve the initial state to a final state that satisfies the postcondition of op . We use the previous heuristics (or any other method!) to characterize the desired final state GOAL2: To deduce the minimal set of actions set ac to implement a given postcondition. Minimal= no proper subset of set ac suffices to satisfy the postcondition and reach the desired final state Several transformation patterns (one for each common type of OCL expression) are provided

UML Actions The exact translation depends on the imperative sublanguage of each modeling language List of actions (i.e. structural events) defined in the UML: CreateObject(Class c) DestroyObject(Object o) AddAttributeValue(Attribute at, Object o, Object value) RemoveAttributeValue(Attribute at, Object o) CreateLink(Association a, Object o1, …, Object on) CreateLinkObject(Association a, Object o1, …, Object on) D estroyLink(Association a, Object o1, …, Object on) RemoveLinkValue(AssociationEnd ae, Object o) R eclassifyObject(Object o, Class[] newClasses, Class[] oldClasses)

Some translation patterns o.oclIsNew() and o.oclIsTypeOf(Cl) o:=CreateObject(Cl); not o.oclIsTypeOf(OclAny) | Cl.allInstances()->excludes(o) DestroyObject (o); o.at=Y (where at is a univalued attribute) RemoveAttributeValue(at,o); AddAttributeValue(at,o,Y); o.oclIsKindOf(Cl) ReclassifyObject(o,Cl,[]); o.oclIsTypeOf(Cl) ReclassifyObject(o,Cl,Cl.generalization.specific);

Some translation patterns X->forAll(Y) foreach o in X do if not (o.Y) then Translate(o.Y) endif; endfor; o.r->includesAll(Y) foreach o’ in Y do CreateLink(r.association, o, o’) endfor; o.r->isEmpty() foreach o’ in o.r@pre DestroyLink(r.association,o,o’) endfor;

Imperative version of GoalEvaluation context Department::GoalEvaluation() { AddAttributeValue(sumSales, self, self.employee.sales.amount->sum()); if self.sumSales>self.goal then foreach e in self.employee AddAttributeValue(salary, e, e.salary@pre + e.category.raise); endfor; else foreach c in Car::allInstances->select(c| c.type=‘Luxury’) DestroyLink (DepartmentCar, self, c); endfor; endif }

Inherently ambiguous expressions For some postconditions we cannot define a default interpretation (there is not a final state clearly more appropriate than the others). It is worth identifying them since many times the designer is not aware of their ambiguity We provide a default translation but usually designers should select themselves the preferred one List of some inherently ambiguous expressions: Expression Ambiguity description post: B 1 or … or B n At least a B i condition should be true but it is not defined which one/s X<>Y, X>Y, X>=Y, X<Y, X<=Y The exact relation between the values of X and Y is not stated X+Y=W+Z (likewise with -,*,/,…) The exact relation between the values of the different variables is not stated. X->exists(Y) An element of X must verify Y but it is not defined which one X->any(Y)=Z Any element of X verifying Y could be the one equal to Z X.p->sum()=Y There exist many combinations of single values that once added may result in Y

Discussion: Facts  Ambiguity problems difficult a wider adoption of declarative specifications  We must deal with these ambiguities to ensure that the implementation of the operation behaves as expected by the designer (some of the states accepted by the post are not valid from the designer's point of view)  Regardless the proposed solution it is important to identify which are the ambiguities that may appear (many times designers are unaware of them)  No methods exist that provide a declarative-to-imperative translation of OCL specifications Tools admitting declarative specifications transform the contract into if-then clauses that check if the pre and postconditions are satisfied (and raise an exception otherwise). The actual body is not generated

Discussion: My solution Heuristic-based translation  Designers do not need to define additional information  Some of the heuristics are generally accepted  Evolving the schema does not affect the interpretation of existing operations X Consensus on the heuristics is required (at least within the particular company/group using this approach) X This solution does not cover (yet) all kinds of OCL expressions nor all combinations between them (rules to combine the basic patterns are required for elements appearing in different parts of the post)

Discussion: Alternatives (1) Frame axioms Designers explicitly define which parts of the system may (or may not) change during the operation  No hidden interpretations X Additional burden for the designer (feasible?) X Not all ambiguities solved (things that do change may change in different ways. Ex: multivalued properties) X Evolving the schema may imply adding new frame axioms (more things that “do not change”)

Discussion: Alternatives (2) Imperative constructs embedded in the declarative specification  No hidden interpretations X Additional burden for the designer X No clear separation between declarative and imperative specifications X Evolving the schema may require adding new constructs

Discussion: Alternatives (3) Computing all possible final states: Designers review them and select the one they prefer  No hidden interpretations X Additional burden for the designer ? Feasible? -> Risk of exponential combination of possible final states

Discussion: Alternatives (4) Force the designer to write non-ambiguous postconditions Avoiding some problematic OCL constructs and Adding many additional postconditions, specially with the @pre operator to reduce the possible set of final states  No hidden interpretations X Additional burden for the designer (feasible?) X Limits the usefulness of declarative specifications X Evolving the schema may imply adding new conditions X Needs a verification/validation method that ensures that the post is not ambiguous

Conclusions and Further work There is not a perfect solution. This method can be regarded as an alternative/complement of other methods (depending on the designers’ preferences) This method can be useful to: Leverage current model-driven development tools, which up to now only support code-generation from imperative specifications. Validate operation definitions since modelers could immediately check which would be the interpretation of their declarative specifications Further work: Richer translation patterns Considering integrity constraints Mixing different techniques depending on the designer requirements

From Declarative to Imperative Operation Specifications (ER 2007)

More Related Content

What's hot (7)

Viewers also liked (8)

Similar to From Declarative to Imperative Operation Specifications (ER 2007) (20)

More from Jordi Cabot (20)

Recently uploaded (20)

From Declarative to Imperative Operation Specifications (ER 2007)

Editor's Notes