OCLR: A More Expressive, Pattern-Based Temporal Extension of OCL

OCLR: A More Expressive, Pattern-Based

Temporal Extension of OCL

Wei Dou, Domenico Bianculli, and Lionel Briand SnT Centre — University of Luxembourg

.lusoftware verification & validationVVS

CONTEXT

CTIE Centre des Technologies de l'Information de l'Etat

Model-driven Run-time Verification of eGovernment

Business Processes

Specification

TEMPORAL PROPERTIES

“If the registration at the conference is

successful, then a confirmation

email will be sent out.”

Order

Temporal Properties

8

“The registration reminder will be sent at least twice before the conference registration is closed.”

Number of Occurrences

Temporal Properties

9

TEMPORAL LOGICS

Temporal Logics

11

LTL CTL MTL

ITL MITL …

12

Temporal Logics Practitioners

Background in Formal MethodsLimited Tool Support

Model-driven Engineering

MDE PERSPECTIVE

How to support temporal properties with OCL ?

16

STATE OF THE ART

State Of The Art

Features:Timestamped event

always, sometime Real-time deadline, timeout

18

FME 2003

Features:

Past- and future-time Time bounds

19

SEFM 2004

State Of The Art

Features:Linear Temporal Logic

Dwyer’s Pattern System Timeout

20

ECEASST 2008

State Of The Art

21

Features:Linear Temporal Logic

Dwyer’s Pattern System Bounded existence

21

SLE 2012

State Of The Art

What is missing?

Specific occurrence of an event

“A password reset email will be sent to the user after the third incorrect login attempt”

23

Time distance from a boundary

“A speaker should be ready at most 10 minutes after the second keynote.”

24

(No) Tool support

OUR PROPOSAL

OCLR An Expressive, Pattern-Based Temporal Extension of OCL

27

Dwyer’s Pattern SystemPatterns in Property Specifications

for Finite-State Verification* Matthew B. Dwyer George S. Avrunin James C. Corbett

Kansas State University University of Massachusetts University of Hawai'i Department of Computing Department of Mathematics Department of Information and Information Sciences and Statistics and Computer Science

Manhattan, KS 66506-2302 Amherst, MA 01003-4515 Honolulu, HI 96822 +1 413 545 4251

[email protected] avrunin@mat h. umass. edu corbett @hawaii.edu +1 785 532 6350 +1 808 956 6107

ABSTRACT Model checkers and other finite-state verification tools allow developers to detect certain kinds of errors au- tomatically. Nevertheless, the transition of this tech- nology from research to practice has been slow. While there are a number of potential causes for reluctance to adopt such formal methods, we believe that a primary cause is that practitioners are unfamiliar with specification processes, notations, and strategies. In a recent paper, we proposed a pattern-based approach to the presentation, codification and reuse of property specifications for finite-state verification. Since then, we have carried out a survey of available specifications, collect- ing over 500 examples of property specifications. We found that most are instances of our proposed patterns. Furthermore, we have updated our pattern system to accommodate new patterns and variations of existing patterns encountered in this survey. This paper reports the results of the survey and the current status of our pattern system.

Keywords Patterns, finitestate verification, formal specification, concurrent systems

1 INTRODUCTION Although formal specification and verification methods offer practitioners some significant advantages over the current state-of-the-practice, they have not been widely adopted. Partly this is due to a lack of definitive ev- idence in support of the cost-saving benefits of formal methods, but a number of more pragmatic barriers to adoption of formal methods have been identified [22], including the lack of such things as good tool support, appropriate expertise, good training materials, and pro-

'This work was partially supported by NSF grants CCR- 9407182, CCR-9633388, CCR-9703094, and CCR-9708184 and by NASA grant NAG-02-1209.

Permission to make digilal or hard copies of all or part ol'this work tbr personal or classroom usc is granted without fee provided that copies are ,lot lnade or distributed fflr profit or coinmercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, 10 republish, to post on servers or to redistribule to lists. requires prior specific permission andior a fee. LCSE '99 Los Angeles CA Copyn'ght ACM 1999 1-581 13-074-0/99/05 ... $5.00

cess support for formal methods.

We believe that the recent availability of tool support for finite-state verification provides an opportunity to overcome some of these barriers. Finite-state verification refers to a set of techniques for proving properties of finite-state models of computer systems. Properties are typically specified with temporal logics or regular expressions, while systems are specified as finite-state transition systems of some kind. Tool support is available for a variety of verification techniques including, for example, techniques based on model checking [19], bisimulation [4], language containment [14], flow analysis [lo], and inequality necessary conditions [l]. In contrast to mechanical theorem proving, which often requires guidance by an expert, most finite-state verification techniques can be fully automated, relieving the user of the need to understand the inner workings of the verification process. Finite-state verification techniques are especially critical in the development of concurrent systems, where non-deterministic behavior makes test- ing especially problematic.

Despite the automation, users of finite-state verification tools still must be able to specify the system require- ments in the specification language of the tool. This is more challenging than it might at first appear. For example, consider the following requirement for an elevator: Between the time an elevator is called at a poor and the time at opens its doors at that floor, the elevator can arrive at that floor at most twice. To verify this property with a linear temporal logic (LTL) model checker, a developer would have to translate this infor- mal requirement into the following LTL formula:

D((cal1 A Oopen) + ((Tatfloor A lopen) U

(open V ((atfloor A lopen) U (open V ((Tatfloor A Yopen) U

(open V ((atfloor A Topen) U (open v (Tatfloor U OPe.))))))))))

Not only is this formula difficult to read and understand, it is even more difficult to write correctly without some expertise in the idioms of the specification language.

41 1

28

Dwyer’s Pattern System

Pattern

29

Scope


30

{Globally

Before

After

Between-and

After-until

Scope


31

{Globally

Before

After

Between-and

After-until

Scope


32

{Before

After

Between-and

After-until

Globally

Scope


33

{Globally

Before

After

Between-and

After-until

Scope

Between-and vs. After-until

34

Q P P Q Q Q P

Q P P PQ Q Q P

P


Pattern

35

{Universality

Existence

Absence

Response

Precedence


Pattern

36

{Universality

Existence

Absence

Response

Precedence


Pattern

37

{Universality

Existence

Absence

Response

Precedence


Pattern

38

{Universality

Existence

Absence

Response

Precedence

OCLR Syntax Excerpt

40

OCLR: a More Expressive, Pattern-based Temporal Extension of OCL 5

3.1 Syntax

The syntax of OCLR (also inspired by the one of Temporal OCL [12]) is shownin Fig. 1: non-terminals are enclosed in angle brackets, terminals are enclosed insingle quotes, and underlined italic words are non-terminals defined in the OCLgrammar [11]. An hOCLR blocki comprises a set of conjuncted hTemporalClausesibeginning with the keyword ‘temporal’. Each temporal clause contains a tempo-ral expression that consists of a hscopei and a hpatterni; the scope specifies thetime slot(s) during which the property described by the pattern should hold.

hOCLRBlocki ::= ‘temporal’ hTemporalClausei+hTemporalClausei ::= [hsimpleNameCSi] ‘:’ [hQuantif i] hTemporalExpihQuantif i ::= ‘let’ hVariableDeclarationCSi ‘in’hTemporalExpi ::= hScopei hPatternihScopei ::= ‘globally’

| ‘before’ hBoundary1 i| ‘after’ hBoundary1 i| ‘between’ hBoundary2 i ‘and’ hBoundary2 i| ‘after’ hBoundary2 i ‘until’ hBoundary2 i

hPatterni ::= ‘always’ hEventi| ‘eventually’ hRepeatableEventExpi| ‘never’ [‘exactly’ hIntegerLiteratureExpCSi] hEventi| hEventChainExpi ‘preceding’ [hTimeDistanceExpi]

hEventChainExpi| hEventChainExpi ‘responding’ [hTimeDistanceExpi]

hEventChainExpihBoundary1 i ::= [hIntegerLiteratureExpCSi] hSimpleEventi

[hTimeDistanceExpi]hBoundary2 i ::= [hIntegerLiteratureExpCSi] hSimpleEventi

[‘at least’ IntegerLiteratureExpCS ‘tu’]hEventChainExpi ::= hEventi (‘,’ [‘#’ hTimeDistanceExpi] hEventi)*hTimeDistanceExpi ::= hComparingOpi hIntegerLiteratureExpCSi ‘tu’hRepeatableEventExpi ::= [hComparingOpi hIntegerLiteratureExpCSi] hEventihComparingOpi ::= ‘at least’ | ‘at most’ | ‘exactly’hEventi ::= (hSimpleEventi | hComplexEventi) [‘|’ Event]hComplexEventi ::= ‘isCalled’ ‘(’ ‘anyOp’

[‘,’ ‘pre:’ hOCLExpressionCSi][‘,’ ‘post:’ hOCLExpressionCSi] ‘)’ [‘\’ hEventi]

hSimpleEventi ::= hSimpleCallEventi | hSimpleChangeEventihSimpleChangeEventi ::= ‘becomesTrue’ ‘(’ hOCLExpressionCSi ‘)’hSimpleCallEventi ::= ‘isCalled’ ‘(’ hOperationCallExpCSi

[‘,’ ‘pre:’ hOCLExpressionCSi][‘,’ ‘post:’ hOCLExpressionCSi] ‘)’

Fig. 1. Grammar of OCLR

OCLR - <Event>

41

OCLR: a More Expressive, Pattern-based Temporal Extension of OCL 5

3.1 Syntax

The syntax of OCLR (also inspired by the one of Temporal OCL [12]) is shownin Fig. 1: non-terminals are enclosed in angle brackets, terminals are enclosed insingle quotes, and underlined italic words are non-terminals defined in the OCLgrammar [11]. An hOCLR blocki comprises a set of conjuncted hTemporalClausesibeginning with the keyword ‘temporal’. Each temporal clause contains a tempo-ral expression that consists of a hscopei and a hpatterni; the scope specifies thetime slot(s) during which the property described by the pattern should hold.

hOCLRBlocki ::= ‘temporal’ hTemporalClausei+hTemporalClausei ::= [hsimpleNameCSi] ‘:’ [hQuantif i] hTemporalExpihQuantif i ::= ‘let’ hVariableDeclarationCSi ‘in’hTemporalExpi ::= hScopei hPatternihScopei ::= ‘globally’

| ‘before’ hBoundary1 i| ‘after’ hBoundary1 i| ‘between’ hBoundary2 i ‘and’ hBoundary2 i| ‘after’ hBoundary2 i ‘until’ hBoundary2 i

hPatterni ::= ‘always’ hEventi| ‘eventually’ hRepeatableEventExpi| ‘never’ [‘exactly’ hIntegerLiteratureExpCSi] hEventi| hEventChainExpi ‘preceding’ [hTimeDistanceExpi]

hEventChainExpi| hEventChainExpi ‘responding’ [hTimeDistanceExpi]

hEventChainExpihBoundary1 i ::= [hIntegerLiteratureExpCSi] hSimpleEventi

[hTimeDistanceExpi]hBoundary2 i ::= [hIntegerLiteratureExpCSi] hSimpleEventi

[‘at least’ IntegerLiteratureExpCS ‘tu’]hEventChainExpi ::= hEventi (‘,’ [‘#’ hTimeDistanceExpi] hEventi)*hTimeDistanceExpi ::= hComparingOpi hIntegerLiteratureExpCSi ‘tu’hRepeatableEventExpi ::= [hComparingOpi hIntegerLiteratureExpCSi] hEventihComparingOpi ::= ‘at least’ | ‘at most’ | ‘exactly’hEventi ::= (hSimpleEventi | hComplexEventi) [‘|’ Event]hComplexEventi ::= ‘isCalled’ ‘(’ ‘anyOp’

[‘,’ ‘pre:’ hOCLExpressionCSi][‘,’ ‘post:’ hOCLExpressionCSi] ‘)’ [‘\’ hEventi]

hSimpleEventi ::= hSimpleCallEventi | hSimpleChangeEventihSimpleChangeEventi ::= ‘becomesTrue’ ‘(’ hOCLExpressionCSi ‘)’hSimpleCallEventi ::= ‘isCalled’ ‘(’ hOperationCallExpCSi

[‘,’ ‘pre:’ hOCLExpressionCSi][‘,’ ‘post:’ hOCLExpressionCSi] ‘)’

Fig. 1. Grammar of OCLR

OCLR - <SimpleEvent>

<SimpleEvent> ::= <SimpleCallEvent> | <SimpleChangeEvent>

42

OCLR - <SimpleCallEvent>

isCalled(P)

43

isCalled(P, pre: N=0, post: N=1)

OCLR - <SimpleChangeEvent>

becomesTrue(N=1)

44

isCalled(anyOp, N != 1, N = 1)

equivalent to

OCLR - <Event>

Additional support for :

• Disjunction

• Exclusion

• Negation

OCLR - <TemporalExp>

<TemporalExp> ::= <Scope> <Pattern>

46

OCLR - <Scope><Scope> ::= ‘globally’

| ‘before’ <Boundary1>

| ‘after’ <Boundary1>

| ‘between’ <Boundary2> ‘and’ <Boundary2>

| ‘after’ <Boundary2> ‘until’ <Boundary2>

47

<Boundary1> ::= [<Int>] <SimpleEvent> [<TimeDistanceExp>]

<Boundary2> ::= [<Int>] <simpleEvent> [‘at least’ <Int> tu]

48

OCLR - Globally

globally

Q P P PQ Q Q P

OCLR - Before

49

before isCalled(P)

Q P P PQ Q Q P

OCLR - Before

50

before 3 isCalled(P)

Q P P PQ Q Q P

‘before’

[<Int>]

<SimpleEvent>

51

Distance from scope boundaries

[<TimeDistanceExp>]

<TimeDistanceExp> ::=

(‘at least’|‘at most’|’exactly’) <Int> tu

OCLR - Before

52

2 time units

before 3 isCalled(P) at least 2 tu

Q P P PQ Q Q P

OCLR - Before

53

2 time units

before 3 isCalled(P) at most 2 tu

Q P P PQ Q Q P

OCLR - Before

54

2 time units

before 3 isCalled(P) exactly 2 tu

Q P P PQ Q Q P

OCLR - After

‘after’

[<Int>]

<SimpleEvent>

[<TimeDistanceExp>]

55

OCLR - Between-and

56

OCLR - Between-and

between isCalled(P) and isCalled(Q)

Q P P PQ Q Q P

57

OCLR - Between-and

between isCalled(P) at least 1 tu

and isCalled(Q) at least 1 tu

1 time unit

Q P P PQ Q Q P

1 time unit

58

OCLR - Between-and

between 2 isCalled(P) at least 1 tu

and 2 isCalled(Q) at least 1 tu

1 time unit

Q P P PQ Q Q P

1 time unit

59

OCLR - After-until

‘after’

[<Int>]

<SimpleEvent>

[‘at least’ <Int> tu]

‘until’

[<Int>]

<SimpleEvent>

[‘at least’ <Int> tu]

60

OCLR - <Pattern><Pattern> ::= ‘always’ <Event> | ‘eventually’ <RepeatableEventExp> | ‘never’ [‘exactly’ <Int>] <Event> | <EventChainExp> ‘preceding’ [<TimeDistanceExp>] <EventChainExp> | <EventChainExp> ‘responding’ [<TimeDistanceExp>] <EventChainExp>

61

<RepeatableEventExp> ::= [(‘at least’ | ‘at most’ | ‘exactly’) <Int>] <Event>

<EventChainExp> ::= <Event> (‘,’ [‘#’ <TimeDistanceExp>] <Event>)*

OCLR - Universality

62

R R R R{ }always isCalled(R)

63

OCLR - Existence

eventually at least 2 R

P R R S{ }R

eventually at most 2 R

eventually exactly 2 R

eventually R

64

OCLR - Absence

‘never’ [‘exactly’ <Int>] <Event>

“If P happens, then Q will happen.”

65

isCalled(Q) responding isCalled(P)

OCLR - Response

P Q RS{ }SS

“If P happens, within 2 time units, then Q will happen.”

66

Q responding at most 2 tu P

OCLR - Response

P Q RS{ }S

2 time units

S

“If P happens, within 2 time units, then Q will happen followed by R, but the distance between

Q and R should be more than 5 time units ”

67

isCalled(Q), # at least 5 tu isCalled(R)

responding at most 2 tu isCalled(P)

OCLR - Response

P Q RS{ }S

2 time units

S

5 time units

68

OCLR - Precedence

<EventChainExp>

‘preceding’ [<TimeDistanceExp>]

<EventChainExp>

CASE STUDY

Identity Card ManagementCTIEEnrollment

Agent/MFA Ministry of Foreign Affairs Applicant

Enroll a new

application

Refuse application

[reject]

Apporve application

[accept]

Send production request

Resolve incident

[technique incident]

Finish production

Send card to MFA

Receive card

Lose card(lost/stolen)

Set card state to

"Cancelled"

Send cardreturn letter

Send card to applicant

Change card state to "In circulation"

[withdraw] [expired]

[renew]

Return card

Request residence certificate

[incident][expired]

[renounce]

Acknowledge card return

Set card state to "claimed"

Set card state to

"Expired"

Send card to applicant

Generate residence certificate

Send card to

productionDestroy

card

[for diplomats]

Request more info.

[pend]

Renew a card

Set card state to

"Lost/Stolen"

Request Production

Delivery

Expiration

Loss

70

47 temporal properties analyzed and translated into OCLR

71

Request

“Once a card request is approved, the applicant is notified within three days; this notification has to occur before the

production of the card is started.”

(Before + Response)72

Requesttemporal R1:

let r : Request in

before

becomesTrue(r.card.state = CardState::InProduction)

isCalled(notifyApproved(r.applicant))

responding at most 3 “days”

becomesTrue(r.state = RequestState::Approved)

73

“Once a card request is approved, the applicant is notified within three days; this notification has to occur before the production of the card is started.”

Requesttemporal R1:

let r : Request in

before





74


Requesttemporal R1:

let r : Request in

before





75


Requesttemporal R1:

let r : Request in

before





76


Expiration

“Once a card expires, until the card is returned, the holder is notified to return

the card at most twice.”

(After-until + Existence)

77

Expirationtemporal E1:

let c:Card in

after becomesTrue(c.state = CardState::Expired)

until becomesTrue(c.state = CardState::Returned)

eventually at most 2

isCalled(notifyReturnCard(c.cardHolder),

pre:c.state <> CardState::Returned)

78

“Once a card expires, until the card is returned, the holder is notified to return the card at most twice.”


let c:Card in






79



let c:Card in






80


NEXT STEPS…

Meta

Design time

Analyst

RequirementSpecifications

Use Case

Data Model

Process ModelProperties

Run time

OCLR

OCL templates

:Process model

Instantiator

RNL

:OCL constraints

Translate into

Observer

OCL Checker

Comply

+

:Conceptual model

Conceptual model---------------------------Process ModelData ModelType of properties

Generated byMap to

Annotated-with

Platforms

Data Collector

Vision

Revisiting model-driven engineering for run-time verification of business processes. In Proceedings of the 8th System Analysis and Modeling Conference (SAM 2014)

83

Off-line trace checking

• Trace Model and OCLR meta-model

• Translation from OCLR to OCL

• OCLR expressions check with Eclipse OCL

• Preliminary evaluation

SUMMARY

OCLR: A More Expressive, Pattern-Based

Temporal Extension of OCL

.lusoftware verification & validationVVS

Wei Dou, Domenico Bianculli, and Lionel Briand SnT Centre — University of Luxembourg

[email protected]

mailto:[email protected]

OCLR: A More Expressive, Pattern-Based Temporal Extension of OCL

Software

Transcript of OCLR: A More Expressive, Pattern-Based Temporal Extension of OCL