OCLR: A More Expressive, Pattern-Based Temporal Extension of OCL
1. 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
2. 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
28. Dwyer’s Pattern System
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
65. OCLR - Response
“If P happens, then Q will happen.”
isCalled(Q) responding isCalled(P)
P Q S R { } S S
65
66. 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
67. 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
70. 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
72. 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
73. 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
74. 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.”
74
75. 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.”
75
76. 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.”
76
77. 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
78. 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
79. 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.”
79
80. 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.”
80
83. 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
84. Off-line trace checking
• Trace Model and OCLR meta-model
• Translation from OCLR to OCL
• OCLR expressions check with Eclipse OCL
• Preliminary evaluation
87. OCLR:
A More Expressive, Pattern-Based
Temporal Extension of OCL
Wei Dou, Domenico Bianculli, and Lionel Briand
SnT Centre — University of Luxembourg
wei.dou@uni.lu
SsoftwareV verificVation & va.lidlaution
