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
SsoftwareV verificVation & va.lidlaution

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

Model-driven Run-time
Verification of eGovernment
Business Processes

Temporal Properties
“If the registration at
the conference is
successful,
Order
then a confirmation
email will be sent out.”
8

Temporal Properties
“The registration
reminder will be sent
at least twice before
the conference
registration is closed.”
Number of
Occurrences
9

Temporal Logics
LTL CTL MTL
ITL MITL …
11

Temporal
Logics Practitioners
Limited Tool Support
Background in Formal Methods
12

How to support temporal
properties with OCL ?
16

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

State Of The Art
Features:
Linear Temporal Logic
Dwyer’s Pattern System
Timeout
20
ECEASST 2008

21
Features:
Linear Temporal Logic
Bounded existence
SLE 2012
State Of The Art

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

OCLR
An Expressive, Pattern-Based
27

Patterns 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 785 532 6350 +1 808 956 6107
+1 413 545 4251
dwyer@cis.ksu.edu avrunin@mat h. umass. edu corbett @hawaii.edu
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 specifi-cation
processes, notations, and strategies. In a recent
paper, we proposed a pattern-based approach to the
presentation, codification and reuse of property specifi-cations
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 verifica-tion
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 avail-able
for a variety of verification techniques including,
for example, techniques based on model checking [19],
bisimulation [4], language containment [14], flow anal-ysis
[lo], and inequality necessary conditions [l]. In
contrast to mechanical theorem proving, which often
requires guidance by an expert, most finite-state verifi-cation
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 ele-vator:
Between the time an elevator is called at a poor
and the time at opens its doors at that floor, the ele-vator
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

Pattern
29
Scope

30 {Globally
Before
After
Between-and
After-until
Scope

31 {Globally
Before
After
Between-and
After-until
Scope

32 {Before
Globally
After
Between-and
After-until
Scope

33 {Globally
Before
After
Between-and
After-until
Scope

Between-and vs. After-until
Q P P Q Q P Q P
Q P P Q Q Q P
34
P

Pattern
{Universality
Existence
Absence
Response
Precedence
35

Pattern
{Universality
Existence
Absence
Response
Precedence
36

Pattern
{Universality
Existence
Absence
Response
Precedence
37

Pattern
{Universality
Existence
Absence
Response
Precedence
38

grammar [11]. An hOCLR blocki comprises a set of conjuncted hTemporalClausesi beginning with the keyword ‘temporal’. Each temporal clause contains a tempo-ral
expression that consists of a hscopei and a hpatterni; the scope specifies the
time slot(s) during which the property described by the pattern should hold.
OCLR Syntax Excerpt
hOCLRBlocki ::= ‘temporal’ hTemporalClausei+
hTemporalClausei ::= [hsimpleNameCSi] ‘:’ [hQuantif i] hTemporalExpi
hQuantif i ::= ‘let’ hVariableDeclarationCSi ‘in’
hTemporalExpi ::= hScopei hPatterni
hScopei ::= ‘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]
hEventChainExpi
hBoundary1 i ::= [hIntegerLiteratureExpCSi] hSimpleEventi [hTimeDistanceExpi]
hBoundary2 i ::= [hIntegerLiteratureExpCSi] hSimpleEventi [‘at least’ IntegerLiteratureExpCS ‘tu’]
hEventChainExpi ::= hEventi (‘,’ [‘#’ hTimeDistanceExpi] hEventi)*
hTimeDistanceExpi ::= hComparingOpi hIntegerLiteratureExpCSi ‘tu’
hRepeatableEventExpi ::= [hComparingOpi hIntegerLiteratureExpCSi] hEventi
hComparingOpi ::= ‘at least’ | ‘at most’ | ‘exactly’
hEventi ::= (hSimpleEventi | hComplexEventi) [‘|’ Event]
hComplexEventi ::= ‘isCalled’ ‘(’ ‘anyOp’
[‘,’ ‘pre:’ hOCLExpressionCSi]
[‘,’ ‘post:’ hOCLExpressionCSi] 40
‘)’ [‘’ hEventi]
hSimpleEventi ::= hSimpleCallEventi | hSimpleChangeEventi

hEventChainExpi
hBoundary1 i ::= [hIntegerLiteratureExpCSi] hSimpleEventi [hTimeDistanceExpi]
hBoundary2 i OCLR ::= [hIntegerLiteratureExpCSi] [‘at least’ - <IntegerLiteratureExpCS Event>
hSimpleEventi ‘tu’]
hEventChainExpi ::= hEventi (‘,’ [‘#’ hTimeDistanceExpi] hEventi)*
hTimeDistanceExpi ::= hComparingOpi hIntegerLiteratureExpCSi ‘tu’
hRepeatableEventExpi ::= [hComparingOpi hIntegerLiteratureExpCSi] hEventi
hComparingOpi ::= ‘at least’ | ‘at most’ | ‘exactly’
hEventi ::= (hSimpleEventi | hComplexEventi) [‘|’ Event]
hComplexEventi ::= ‘isCalled’ ‘(’ ‘anyOp’
[‘,’ ‘pre:’ hOCLExpressionCSi]
[‘,’ ‘post:’ hOCLExpressionCSi] ‘)’ [‘’ hEventi]
hSimpleEventi ::= hSimpleCallEventi | hSimpleChangeEventi
hSimpleChangeEventi ::= ‘becomesTrue’ ‘(’ hOCLExpressionCSi ‘)’
hSimpleCallEventi ::= ‘isCalled’ ‘(’ hOperationCallExpCSi [‘,’ ‘pre:’ hOCLExpressionCSi]
[‘,’ ‘post:’ hOCLExpressionCSi] ‘)’
Fig. 1. Grammar of OCLR
41

OCLR - <SimpleEvent>
<SimpleEvent> ::= <SimpleCallEvent> | <SimpleChangeEvent>
42

OCLR - <SimpleCallEvent>
isCalled(P)
isCalled(P, pre: N=0, post: N=1)
43

OCLR - <SimpleChangeEvent>
becomesTrue(N=1)
equivalent to
isCalled(anyOp, N != 1, N = 1)
44

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>
<Boundary1> ::= [<Int>] <SimpleEvent>
[<TimeDistanceExp>]
<Boundary2> ::= [<Int>] <simpleEvent>
[‘at least’ <Int> tu]
47

OCLR - Globally
globally
Q P P Q Q P Q P
48

OCLR - Before
before isCalled(P)
Q P P Q Q P Q P
49

OCLR - Before
before 3 isCalled(P)
Q P P Q Q P Q P
50

Distance from scope boundaries
‘before’
[<Int>]
<SimpleEvent>
[<TimeDistanceExp>]
<TimeDistanceExp> ::=
(‘at least’|‘at most’|’exactly’) <Int> tu
51

OCLR - Before
before 3 isCalled(P) at least 2 tu
Q P P Q Q P Q P
52
2 time units

OCLR - Before
before 3 isCalled(P) at most 2 tu
Q P P Q Q P Q P
53
2 time units

OCLR - Before
before 3 isCalled(P) exactly 2 tu
Q P P Q Q P Q P
54
2 time units

OCLR - After
‘after’
[<Int>]
<SimpleEvent>
[<TimeDistanceExp>]
55

OCLR - Between-and
between isCalled(P) and isCalled(Q)
Q P P Q Q P Q P
57

OCLR - Between-and
between isCalled(P) at least 1 tu
and isCalled(Q) at least 1 tu
Q P P Q Q P Q P
1 time unit
1 time unit
58

OCLR - Between-and
between 2 isCalled(P) at least 1 tu
and 2 isCalled(Q) at least 1 tu
Q P P Q Q P Q P
1 time unit
1 time unit
59

OCLR - After-until
‘after’
[<Int>]
<SimpleEvent>
‘until’
[<Int>]
<SimpleEvent>
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
always isCalled(R)
R R R R { }
62

OCLR - Existence
eventually exactly 2 R
eventually at most 2 R
eventually at least 2 R
eventually R
P R R S { } R
63

OCLR - Absence
‘never’ [‘exactly’ <Int>] <Event>
64

OCLR - Response
“If P happens, then Q will happen.”
isCalled(Q) responding isCalled(P)
P Q S R { } S S
65

OCLR - Response
“If P happens, within 2 time units, then Q will happen.”
Q responding at most 2 tu P
P Q S R { } S
66
S
2 time units

OCLR - Response
“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 ”
isCalled(Q), # at least 5 tu isCalled(R)
responding at most 2 tu isCalled(P)
P Q S R { } S
67
S
2 time units
5 time units

OCLR - Precedence
<EventChainExp>
‘preceding’ [<TimeDistanceExp>]
<EventChainExp>
68

Identity Card Management
Enrollment CTIE
Agent/MFA Ministry of Foreign Affairs Applicant
Enroll a
new
application
Refuse
application
[reject]
Request [accept]
Apporve
Production
application
Send production
request
Resolve incident
[technique incident]
Finish
production
Send card
to MFA
Receive card
[expired] [incident]
Lose card
(lost/stolen)
Send card to
applicant
Set card
state to
"Cancelled"
Set card state to
"claimed"
Send card
return letter
Send card
to applicant
Change card state
to "In circulation"
[withdraw] [expired]
[renew]
Return
card
Request
residence
certificate
[renounce]
Acknowledge
card return
Set card
state to
"Expired"
Send card
to
production
Generate
residence
certificate
Destroy
card
[for diplomats]
Request
more info.
[pend]
Renew a
card
Set card
state to
"Lost/Stolen"
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

Request
temporal 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)
“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.”
73

Request
temporal R1:
let r : Request in
before
card is started.”
74

Request
temporal R1:
let r : Request in
before
card is started.”
75

Request
temporal R1:
let r : Request in
before
card is started.”
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

Expiration
temporal 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)
“Once a card expires, until the card is returned, the holder
is notified to return the card at most twice.”
78

Expiration
temporal E1:
let c:Card in
79

Expiration
temporal E1:
let c:Card in
80

Design time
Meta
Requirement
Specifications
Analyst
Vision
Use Case
Process Model
Data Model
Properties
Run time
OCLR
OCL templates
:Process model
Instantiator
RNL
Translate into
:OCL constraints
Comply
Observer
OCL Checker
+
:Conceptual model
Conceptual model
---------------------------
Process Model
Data Model
Type of properties
Generated by
Map to
Annotated-with
Platforms
Data Collector
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

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

OCLR:
A More Expressive, Pattern-Based
Wei Dou, Domenico Bianculli, and Lionel Briand
SnT Centre — University of Luxembourg
wei.dou@uni.lu
SsoftwareV verificVation & va.lidlaution

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

More Related Content

What's hot (20)

Similar to OCLR: A More Expressive, Pattern-Based Temporal Extension of OCL (20)

More from Lionel Briand (20)

Recently uploaded (20)

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