Post on 29-Nov-2014
description
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
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
OCL
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
dwyer@cis.ksu.edu 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 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
Dwyer’s Pattern System
Pattern
29
Scope
Dwyer’s Pattern System
30
{Globally
Before
After
Between-and
After-until
Scope
Dwyer’s Pattern System
31
{Globally
Before
After
Between-and
After-until
Scope
Dwyer’s Pattern System
32
{Before
After
Between-and
After-until
Globally
Scope
Dwyer’s Pattern System
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
Dwyer’s Pattern System
Pattern
35
{Universality
Existence
Absence
Response
Precedence
Dwyer’s Pattern System
Pattern
36
{Universality
Existence
Absence
Response
Precedence
Dwyer’s Pattern System
Pattern
37
{Universality
Existence
Absence
Response
Precedence
Dwyer’s Pattern System
Pattern
38
{Universality
Existence
Absence
Response
Precedence
OCLR
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
becomesTrue(r.card.state = CardState::InProduction)
isCalled(notifyApproved(r.applicant))
responding at most 3 “days”
becomesTrue(r.state = RequestState::Approved)
74
“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
becomesTrue(r.card.state = CardState::InProduction)
isCalled(notifyApproved(r.applicant))
responding at most 3 “days”
becomesTrue(r.state = RequestState::Approved)
75
“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
becomesTrue(r.card.state = CardState::InProduction)
isCalled(notifyApproved(r.applicant))
responding at most 3 “days”
becomesTrue(r.state = RequestState::Approved)
76
“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.”
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.”
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)
79
“Once a card expires, until the card is returned, the holder is notified to return the card at most twice.”
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)
80
“Once a card expires, until the card is returned, the holder is notified to return the card at most twice.”
OCLR
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
wei.dou@uni.lu