Cjb0911008 Srinivas Csn505 Presentation

7/31/2019 Cjb0911008 Srinivas Csn505 Presentation

1/30

M. S. Ramaiah School of Advanced Studies 1

CSN505 AFM Presentation

Object Constraint Language

Srinivas T

FT 2011 Batch, Reg. No.: CJB0911008M. Sc. (Engg.) in Computer Science and Networking

Module Leader: Dr Hariharan Ramasangu

Module Name: Applied Formal Methods

Module Code : CSN505


2/30


Marking

Head Maximum Score

Technical Content 5

Grasp and Understanding 5

DeliveryTechnical and

General Aspects

5

Handling Questions 5

Total 20


3/30


Presentation Outline

History

Introduction to OCL

Why OCL ?

Where to use OCL OCL motivation

Conclusion

References


4/30


History

Object constraint language is the constraint

language of UML.

First developed in 1995 as IBEL by IBMs

Insurance division for business modelling.

It was developed by Jos Warmer and AnnekeKlepper, based on Steve Cook and John Danielss

syntropy language.

OCL was designed in the hope that it would be

simpler than languages such as VDM and Z, but it

actually ended up more complicated.

OCL was used to define further upgrades of UML.


5/30


Introduction to OCL

OCL notation allows Unified Modeling Language

(UML) users more specification precision.

OCL is Based on logic and discrete mathematics.

OCL is a modeling language not a programming

language. Evaluated OCL expressions can not have side effects.

OCL provides a way to develop more precise models

using UML. Initially OCL is an extension to UML, and now it is a

part of UML standard.


6/30


Why OCL?

A UML diagram, such as a class diagram, is

typically not refined enough to provide all the

relevant aspects of a specification.

There is a need to describe additional constraints

about the object in the model. Natural language is inherently unambiguous.

Traditional formal languages are difficult for the

average business or system modeler to use.

OCL is a formal language that remains easy to

read and write.


7/30 M. S. Ramaiah School of Advanced Studies 7

Where to Use OCL

The OCL language is used to express constraints specifyingconstant conditions for system being modeled.

To specify invariants on classes and types in the class model.

To specify type invariant for stereotypes.

To describe pre- and post conditions on Operations and

methods.

To specify constraints on operations.

What is a constraint in Object Constraint Language?A constraint is a restriction on one or more values of (part

of) an object-oriented model or system.



Object Constraint Language

Motivation

UML diagrams dont tell everything

Q: What does the following class diagram tell?

security

Person

Mortgage

House

11

0..*

0..*

0..*

1

mortgages

borrowerhouses

mortgages

owner



OCL --- Motivation

Is this a valid object diagram?

Whats the problem?

p1: Person

m1: Mortgage

h1: House p2: Person



OCL --- Motivation

Solution: Specify constraints explicitly

A person have a mortgage on a house only

if that house is owned by the person.

security

Person

Mortgage

House

1 1

0..*

0..*

0..*

1

mortgages

borrowerhouses

mortgages

owner

context Mortgage

inv: security.owner = borrower



OCL --- What Is It?

Standard add-on to UML

OCL expressions dependent on types from UML

diagrams

Language for expressing additional information (e.g.,

constraints and business rules) about UML models

Characteristics

Constraint and query languages

Math foundation (set and predicate) but no math

symbols

Strongly typed, declarative, and no side effect

High level of abstraction (platform independence)



Advantages of Constraints Better documentation

Constraints add information about the model elements andtheir relationships to the visual models used in UML

It is a way of documenting the model

More precision

OCL constraints have formal semantics, hence, can be used to

reduce the ambiguity in the UML models

Communication without misunderstanding

UML models are used to communicate between developers

Using OCL constraints modelers can communicate

unambiguously



OCL Constraints

OCL constraints are declarative

They specify what must be true not what must

be done.

OCL constraints have no side effects

Evaluating an OCL expression does not change

the state of the system.

OCL constraints have formal syntax and semantics

their interpretation is unambiguous.



Different kinds of Constraints

Class invariant

a constraint that must always be met by all

instances of the class.

Precondition of an operation

a constraint that must always be true BEFORE

the execution of the operation.

Postcondition of an operation

a constraint that must always be true AFTER

the execution of the operation.



Constraints (invariants), Contexts and Self

A constraint (invariant) is a boolean OCL expression

evaluates to true/false. Every constraint is bound to a specific type (class,

association class, interface) in the UML modelits context.

The context objects may be denoted within the expression

using the keyword self. The context can be specified by:

Context

A dashed note line connecting to the context figure in the

UML models A constraint might have a name following the keyword

invariant.



Invariants Using OCL we can specify class invariants such as

Customerage >= 18

As a convention we will write the OCL expressions in the

following form:

OCLcontext

OCLexpression

The class on which the invariant must hold is the invariant

context

Invariant has to hold for all instances of the class

For the above example, the expression age >= 18 is an invariant

of the Customer class, i.e. it holds for every instance of that

class



Invariants We can also write invariants on attributes of associated classes

In OCL you can use the rolename to refer to the object on the other endof an association.

If the rolename is not present, you can use the classname startingwith a lowercase letter

Examples:

Membership

card.owner = customer

CustomerCard

printedName = owner.title.concat( owner.name )



Choosing a Context The class on which the invariant must be put is the invariant

context

One can write the same invariant property in different contexts

For example

Customer

age >= 18

LoyaltyProgram

customer.forAll( age >= 18 )



Basics of OCL

Associating OCL expressions to UML models

Directly to diagrams as notes

Separate accompanying texts, e.g.,

context Person

inv: age >= 0

Specifying invariants

State conditions that must be always be met byall instances of context types (classes or

interfaces)



Basics of OCL --- Invariants

context Company inv:

self.numberOfEmployees > 50

contextc: Company inv:

c.numberOfEmployees > 50

context c: Company invenoughEmployees:

c.numberOfEmployees > 50

self: contextual instance, an

instance to which the OCLexpression is attached

self: contextual instance, an

instance to which the OCL

expression is attached

an optional label



Invariants

Determine a constraint that must be true for all instances of a type

Value of attribute noEmployees in instances of Company must be

less than or equal to 50

context Company inv:

self.noEmployees


22/30


Pre-conditions, Post-conditions

A pre/post-condition is defined for a method of a

class.

This methods is the context of the condition.

Context :: op(x1:t1, , xn:tn)pre:

post:


23/30


Pre- and Post-conditions

Constraints associated with an operation or other behavioral feature

Pre-condition: Constraint assumed to be true before the operation is executed Post-condition: Constraint satis ed after the operation is executed

Pre- and post-conditions associated to operation income in Person

context Person::income(): Integer

pre: self.age >= 18

post: result < 5000

self is an instance of the type which owns the operation or method

result denotes the result of the operation, if any

Type of result is the result type of the operation (Integer in the example)

A name can be given to the pre- and post-conditions

context Person::income(): Integer

pre adult: self.age >= 18

post resultOK: result < 5000


24/30


Specifying Pre and Post-conditions

Pre and post-conditions

Conditions that must be true at the moment when an

operation begins and ends its execution.

context Account::deposit(amt: Integer): void

pre: amt > 0

post: balance = balance@pre + amt

context Account::deposit(amt: Integer): void

preargumentOk: amt > 0postbalanceIncreased: balance = balance@pre + amt

pre-value, referring

to previous value

optional label


25/30


Referring to Pre-value and Result

@pre: denotes the value of a property at the

start of an operations

result: denotes the result of an operation

context Account::payInterest(rate: Real): voidpost: balance = balance@pre + calcInterest@pre(rate)

context Account::getBalance(): Integer

post: result = balance


26/30


Navigating in OCL Expressions

Use dot notation to navigate through associations

Direction and multiplicity matter

Use role names or class names

CustomerAccount0..* 1

accounts owner

context Account

inv: self.owner -- evaluate to a single Customer

self.Customer

context Customer

inv: self.accounts->size() -- evaluate to a collection

self.Account -- of accounts

Arrow notation for collection operations


27/30


Basic Values and Types

Several built-in types and operations

Type Values Operations

Boolean false, true or, and, xor, not, =, , implies

Integer -10, 0, 10, =, , , =, +, -, *, /, mod(),div(), abs(), max(), min(), round(),

floor()Real -1.5, 3.14,

String Carmen=, , concat(), size(), toLower(),

toUpper(), substring()


28/30


Conclusion

OCL improves the precision of UML.

OCL is a formal language that remains easy

to read and write.

OCL provides a way to develop more

precise models using UML.

OCL is key for formal methods, UML

models as first-class, strategic, reusable

artefacts and (future) automated code

generation.


29/30


References

Follow CU-Harvard Referencing style


30/30

30

Thank you

Documents

Cjb0911008 Srinivas Csn505 Presentation