A Model-driven Methodology for Generating and Verifying CSP-based Java Code no 1 ul N.N. Alborodo 2 Julio Mari ˜ Ra´ 1 Universidad Polit´ 2 IMDEA Software Institute ecnica de Madrid Babel research group raul.alborodo@imdea.org julio.marino@upm.es Communicating Process Architectures CPA2015 Canterbury, August 24 2015
summary the paper in a nutshell this paper is about: model-driven development of concurrent software specifying process interaction with formal models generating code from these models (semi-automatically), and verifying the resulting code our contributions: a textual syntax for specifying process interaction models (that we call shared resources ) as JML-annotated Java interfaces a couple of generic templates for translating these models into Java classes using the JCSP (CSP for Java) library an strategy for verification of the code generated according to these templates, and some experimental results on the mechanical verification using the KeY tool (initial) motivation: teaching trying to teach concurrency to undergrad students for more than 15 years J.Mari ˜ no & R.Alborodo (UPM & IMDEA) Model-based Code Generation Using JCSP CPA2015 2 / 31
model-driven software development work fl ows J.Mari ˜ no & R.Alborodo (UPM & IMDEA) Model-based Code Generation Using JCSP CPA2015 3 / 31
benefits of model-driven software development why adding may be necessary for simplifying things 1 Formalizing (part of) the requirements reduces ambiguity in the problem statement. 2 Formal models can be the subject of experiments aimed at early requirement validation . That is, a mathematical model can be formally verified for detecting inconsistencies or other fl aws. 3 Code is not written from scratch but generated or distilled (semiautomatically) from the model. This brings several bene fi ts. One of them is portability . This is specially relevant for concurrent software production, given the volatility of certain languages. A second bene fi t is robustness against changes in the requirements – modifying concurrent code by hand may introduce more errors than re-generating it. Finally, the generative approach may reduce production costs at this stage. 4 Models can help in the validation, veri fi cation and test case generation of the code obtained from the previous phases. J.Mari ˜ no & R.Alborodo (UPM & IMDEA) Model-based Code Generation Using JCSP CPA2015 4 / 31
shared resources what is so relevant that deserves to be modeled key abstractions concurrency = simultaneous execution + nondeterminism + interaction interaction = communication + synchronization synchronization = mutual exclusion serializability + condition synchronization P 1 P 4 R 1 R 2 P 7 P 2 Op 1 Op 2 P 5 Op 1 Op 2 P 3 P 6 J.Mari ˜ no & R.Alborodo (UPM & IMDEA) Model-based Code Generation Using JCSP CPA2015 5 / 31
shared resources by example readers & writers wrt 1 rdr 1 rdrs/wrts BR BW wrt 2 rdr 2 AR AW r w wrt 3 rdr 3 communication: takes place via change of the resource’s internal state, after applying a sequence of (serial) operations: w = 1 w = 0 w = 1 w = 0 AW BR BR r = 0 r = 0 r = 1 r = 2 ❀ ❀ ❀ synchronization: consists in restricting the set of valid sequences of operations (internal language of the shared resource): valid traces: BR; AR; BW; AW; BR; BR; AR; AR; BW; AW; . . . invalid traces: BR; BW; AW; BR; BR; AR; AR; BW; AW; AR; . . . J.Mari ˜ no & R.Alborodo (UPM & IMDEA) Model-based Code Generation Using JCSP CPA2015 6 / 31
formal specification of a shared resource readers & writers CADT ReadersWriters OPERATIONS ACTION BeforeRead;AfterRead;BeforeWrite;AfterWrite: preconditions ( PRE s) are often SEMANTICS independent from the resource’s DOMAIN: STATE: ( readers : N × writers : N ) state INVT: ( readers > 0 ⇒ writers = 0 ) ∧ The invariant ( INVARIANT ) maps ( writers > 0 ⇒ readers = 0 ∧ writers = 1 ) INITIAL: writers = 0 ∧ readers = 0 to the loop invariant within the CPRE: writers = 0 ∧ readers = 0 server code. BeforeWrite The concurrent or POST: writers = 1 synchronization pre-condition PRE: writers = 1 ( CPRE ) must hold right before CPRE: true entering the code for each AfterWrite POST: writers = 0 operation (might block CPRE: writers = 0 execution) BeforeRead POST: readers = 1 + readers in The post-condition (POST) must PRE: readers > 0 hold on exit of the code of each CPRE: true operation AfterRead POST: readers = readers in − 1 J.Mari ˜ no & R.Alborodo (UPM & IMDEA) Model-based Code Generation Using JCSP CPA2015 7 / 31
shared resources as abstract state machines readers & writers BW BR BR BR . . . 0/1 0/0 1/0 2/0 3/0 AW AR AR AR J.Mari ˜ no & R.Alborodo (UPM & IMDEA) Model-based Code Generation Using JCSP CPA2015 8 / 31
model-driven engineering revisited applying all of this to developing concurrent Java SW .tla .java .adb JML-annotated Java classfiles SR CC (JML interface) SR(s) .java .erl testing SPECS KeY code J.Mari ˜ no & R.Alborodo (UPM & IMDEA) Model-based Code Generation Using JCSP CPA2015 9 / 31
shared resource specifications as JML-annotated Java interfaces a textual, convenient and ready-to-compile representation package es.upm.babel.ccjml.samples.readerswriters.java; 1 2 public interface /*@ shared_resource @*/ ReadersWriters { 3 //@ public model instance int readers; 4 //@ public model instance int writers; 5 6 /*@ public instance invariant 7 @ readers >= 0 && writers >= 0 && 8 @ (readers > 0 ==> writers == 0) && 9 @ (writers > 0 ==> readers == 0 && writers == 1); 10 @*/ 11 12 //@ public initially readers == 0 && writers == 0; 13 14 /*@ public normal_behaviour 15 @ cond_sync writers == 0 && readers == 0; 16 @ assignable writers; 17 @ ensures writers == 1; 18 @*/ 19 public void beforeWrite(); 20 J.Mari ˜ no & R.Alborodo (UPM & IMDEA) Model-based Code Generation Using JCSP CPA2015 10 / 31
shared resource specifications as JML-annotated Java interfaces (cont’d.) a textual, convenient and ready-to-compile representation @ requires writers == 1; 1 @ assignable writers; 2 @ ensures writers == 0; 3 @*/ 4 public void afterWrite(); 5 6 /*@ public normal_behaviour 7 @ cond_sync writers == 0; 8 @ assignable readers; 9 @ ensures readers == \old(readers) + 1; 10 @*/ 11 public void beforeRead(); 12 13 /*@ public normal_behaviour 14 @ requires readers > 0; 15 @ assignable readers; 16 @ ensures readers == \old(readers) - 1; 17 @*/ 18 public void afterRead(); 19 } 20 J.Mari ˜ no & R.Alborodo (UPM & IMDEA) Model-based Code Generation Using JCSP CPA2015 11 / 31
implementing shared resources using JCSP client-server + RPC + . . . a view from the clients’ side: SHARED RESOURCE P 2 Wrapper OP 1 OP 2 Server Code P 3 P 1 Wrapper Receiving method invocations and propagating them as messages to the server through CSP channels; J.Mari ˜ no & R.Alborodo (UPM & IMDEA) Model-based Code Generation Using JCSP CPA2015 12 / 31
implementing shared resources using JCSP client-server + RPC + . . . server side: SHARED RESOURCE P 2 Wrapper OP 1 OP 2 Server Code P 3 P 1 Server Processing the requests received from the wrapper methods and modifying the shared resource inner state J.Mari ˜ no & R.Alborodo (UPM & IMDEA) Model-based Code Generation Using JCSP CPA2015 13 / 31
implementing the server the devil is in the CPRE s When shared resource operations take no arguments or the operation’s CPRE does not depend on them, one channel per operation and channel enabled when CPRE holds (see, for instance, readers & writers). When CPRE s may vary depending on the actual parameters operations can take there are two basic approaches: ◮ channel replication: Instantiate CPRE s with all their possible values, take classes modulo logical equivalence, then assign a channel to each class. Enable channels according to each CPRE . ◮ deferred requests: one (always open) channel per operation, requests are stored in the server until CPRE holds. J.Mari ˜ no & R.Alborodo (UPM & IMDEA) Model-based Code Generation Using JCSP CPA2015 14 / 31
CPRE s depending on their parameters multibuffer CADT Multibuffer OPERATIONS ACTION Put: Sequence ( ANY )[ i ] ACTION Get: N [ i ] × Sequence ( ANY )[ o ] SEMANTICS DOMAIN: STATE: self = Sequence ( ANY ) INVT: Length (self) ≤ MAX INITIAL: Length (self) = 0 PRE: 1 ≤ Length ( r ) ≤ ⌊ MAX / 2 ⌋ CPRE: 1 ≤ Length ( r ) ≤ MAX − Length (self) Put(r) POST: self = self in + r PRE: 1 ≤ n ≤ ⌊ MAX / 2 ⌋ CPRE: 1 ≤ n ≤ Length (self) Get(n, s) POST: self in = self + s J.Mari ˜ no & R.Alborodo (UPM & IMDEA) Model-based Code Generation Using JCSP CPA2015 15 / 31
� channel replication multibuffer Considering Multibuffer example with MAX = 4 MULTIBUFFER PUT GET CPRE put (2) CPRE get (1) Server Code CPRE put (1) CPRE get (2) pe i : E i → N px i : D x → E i pe put ([ a 1 , . . . , a n ]) = n px put ([ a 1 , . . . , a k ]) = [ 0 1 , . . . , 0 k ] pe get ( n ) = MAX / 2 + n px get ( n ) = n J.Mari ˜ no & R.Alborodo (UPM & IMDEA) Model-based Code Generation Using JCSP CPA2015 16 / 31
Recommend
More recommend
