XCD – A -by-Contract Description Language

Mert Ozkaya and Christos Kloukinas Department of Computer Science, City University London, London, EC1V 0HB, UK

Abstract— Software architecture description languages indicates that the languages developed in academia so far (ADL) have been proposed as a way to properly specify have not been very successful in practice. Practitioners the of complex software systems, in a way remarked that they need to analyze their systems for non- that allows both communication among the different stake- functional properties like performance or reliability, which holders and an early analysis of these systems for a number are not usually supported by ADL and their related tools. of properties. However, practitioners seem to have shunned They also considered the formal notations used in ADL as the ADL developed in academia and mainly use other imposing a learning curve that is too steep and having a low modeling languages, that were not originally created for return on investment in their eyes. describing architectures. In a recent survey, practitioners We take the view that both these issues are important have expressed a wish for analyzing their architectures but we cannot resolve the former without first resolving (esp. for non-functional properties) and at the same time the latter. This is because safety and liveness properties, expressed their dissatisfaction with existing ADL, finding like deadlock-freedom, are of a more basic nature than that the formal notations they use have a learning curve performance and reliability analyses – after all, a deadlocked that they perceive as being too steep. system has zero performance and zero reliability. Therefore In this paper we propose a new ADL, called XCD, that we need to design an ADL that allows practitioners to attempts to address these issues. To this end, XCD is a formal specify behaviors in a way that allows for formal verification language, allowing the formal analysis of systems. In its but without imposing upon them a notation that is unfamiliar current form, it focuses on safety and liveness properties to them. For this reason we have developed XCD, a new (deadlocks, etc.), leaving support for non-functional proper- ADL that follows a Design-by-Contract (DbC) approach ties, such as reliability or performance, for later. In order to [26]. XCD allows architects to specify the behaviors of avoid imposing a steep learning curve on practitioners, XCD their systems in a language that resembles a programming follows a Design-by-Contract (DbC) approach. DbC has the language, which should render the investment required in advantage of allowing practitioners to express formal models learning the new notation small enough for it to become a in a notation that resembles the programming languages they reasonable approach to consider. use. DbC has in fact already been embraced by practitioners, who so far use it mainly for improving their testing methods. 1.1 XCD Language Design Considerations Table 1 shows a number of ADL, covering both the major early ones (Darwin to XADL) and more recent ones 1. Introduction (PRISMA to CONNECT). It compares them against three characteristics that we believe to be important for supporting There has been significant work on architectural descrip- the architectural specification of complex systems, namely tion languages (ADL) from the early nineties as a way whether they allow formal behavior specification, whether of specifying the architecture of complex software systems they support complex connectors as first-class elements and [15], [30]. Rapide [21], Wright [1], Darwin [22], UniCon whether the architectures expressed in them are realisable. [34], ACME [14], XADL [10], and C2 [25] are widely- Most of these ADL do allow formal behavior specification, known early ADLs; LEDA [7], AADL [11], Koala [35], albeit in notations that practitioners have found to require a COSA [28], SOFA [31], RADL [32], PRISMA [29], π-ADL steep learning curve. The ones that do not support formal [27], PiLar [9], and Connect [18] are ones developed more behavior specification do so because they focus more on recently. These languages have explored different ways of direct code production from architectural descriptions. In- representing architectures, using component and connector terestingly, practitioners surveyed in [24] did not rate code abstractions or just component abstractions. Many among production as an important feature. them have been designed to facilitate formal analysis of Then we see that the ADLs in Table 1 are more or less safety and liveness properties, for which they require ar- divided between those that do support complex connectors chitects to specify the behaviors of system elements using as first-class elements and those that do not, either allowing some formal language, usually a form of a process algebra. a limited set of connectors only or requiring that architects A recent survey by Malavolta et al. [24] on the needs simulate these through components. We acknowledge that of the industry with respect to architectural specification, this is somewhat a question of taste, just like Java requires Table 1: Some important ADL characteristics are to behave in their environment and interact with other ADLs Formal First-class Realisable components; thus, it is very likely that those components are behaviour complex unable to be composed successfully to a whole system. specification connectors Darwin [22] FSP No Yes Having mentioned the importance of explicit complex Wright [1] CSP Yes Potentially no connectors in design, a careful reader will notice that in (glue centralised Table 1 each referred ADL supporting connectors as a first- controller element) class entity have a realisability problem. That is, centralised ACME [14] Possible with Yes Potentially no annotations (when Wright global constraints are allowed (if not forced) to be speci- connectors fied that coordinate the behaviour of components – which employed) however can never exist in distributed (i.e., decentralised) Rapide [21] Event patterns No Potentially no (global systems. In such a case, specifications would become un- architectural realisable that cannot easily be implemented in reality. constraints pattern) Separating the global constraints into distributed protocols UniCon [34] No No Yes C2 [25] Z No Yes for the participating components may avoid this, which may LEDA [7] pi-calculus No Yes however be impossible to do. Worse yet, no tool can warn OLAN [2] No No Yes that their design is potentially unrealisable, as the XADL [10] Possible with Yes Potentially no schema (when Wright realisability problem is undecidable in general. extension connectors Therefore, connectors in XCD are not specified with glue- employed) like centralised units. Instead, as depicted in Figure 1, we PRISMA [29] pi-calculus Yes Potentially no consider connectors as abstractions of decentralised roles, (when connector aspects are which represent the interaction behaviour of participating employed) components, and connector channels between the roles. RADL [32] Finite State No Yes Thus, architectural design of distributed systems is specified Machine in a decentralised manner without the restriction of using PiLar [9] process Yes Potentially no algebraic (when constraints centralised glues rendering them realisable by construction. notation are employed) In cases where glue-like centralised choreographers are π-ADL [27] pi-calculus Yes Potentially no desired, they are specified as explicit connector roles too. (when connector protocols are employed) 2. Architecture Specification with Design AADL [11] Automata No Yes Koala [35] No No Yes by Contract COSA [28] No Yes Potentially no (glue centralised (DbC) invented by Bertrand Meyer controller element) [26] is considered as an approach for specifying the be- SOFA [31] Behaviour No Yes Protocols haviour of software in terms of contracts consisting es- (simplified sentially of pre-conditions and post-conditions. A contract CSP) herein imposes on software units that if the required pre- CONNECT [18] FSP Yes Potentially no condition is satisfied by the caller of the unit, then the unit (glue centralised controller element) is executed and is ensured to meet certain post-condition. In this section, we focus on the idea of adopting and extending DbC for specifying software architectures that can that every procedure is specified as a method of some class be easily developed and formally analyzed. while C++ allows independent procedures too. As we do not like having to write Math.sqrt() in Java to call the square 2.1 Why Design-by-Contract (DbC) root function, we believe that it is better to not try to fit Formal specification DbC essentially promotes a formal everything into a single element and offer a separate notion specification of software behaviour in that the notion of con- to characterize protocols – connectors. tracts has its formal semantics based on Hoare’s logic [16] Indeed, when (complex) connectors are implicit entities and VDM’s rely-guarantee [3] specification approach. embedded in components (as is, for instance, the case with Familiar to developers DbC has been supported by various Darwin, Rapide, OLAN, LEDA, and RADL), they cannot programming languages and thus already known and used be re-used in different contexts. Furthermore, components by many developers. This highly aids in contractual speci- become less re-usable too being specific to certain interac- fications being more familiar among developers, compared tion protocols. Worse, when interaction protocols are omitted with process algebras requiring unusual concurrency oper- entirely in architectures, this results in architectural mis- ators such as parallel composition and (non)deterministic match [13] That is, it is not documented how the components choice operators. DbC has been widely utilized in test-driven contracts constraining the event/method actions performed via component ports. Likewise, the connector roles played by components are specified with contracts constraining their port-variables (representing the participating compo- nent ports – see section 2.2.2). Contracts, as depicted in Figure 1, are separated into functional and interaction units: the former is used to represent the functional behaviour of components and the latter represents either the interaction behaviour of components or the interaction protocols of connectors. The rest of this section further elaborates on Fig. 1: Meta-model of XCD contractual component and connector specifications.

Listing 1: Generic component structure developments with the purpose of improving fault detection 1 component Name { in software units. Indeed, there are ever-increasing attempts 2 data;* put on this field, e.g., [4], [6], [33]. Java Modeling Language 3 provided port Name { 4 @interaction{ (JML) [8] is one of most well-known work on DbC. Intended 5 accepts: pre-condition for Java language, JML allows for specifying the behaviour 6 rejects: pre-condition of Java modules (e.g., Java classes, methods, or interfaces) 7 ***OR*** 8 waits: pre-condition } with executable contracts. Hence, the behaviour of Java units 9 @functional{ can be formally specified using JML and further formally 10 requires: pre-condition verified [12]. Moreover, JML is found easy to use by the 11 ensures: post-condition } 12 method;+ software community in that it has been used in 13 };* teaching for undergraduates [19]. 14 required port Name { Gap in the field of software architecture Although DbC 15 @interaction{ 16 promises: pre-condition } has been widely considered for the implementation stage 17 @functional{ of software development, the situation is the contrary for 18 promises: pre-condition the software architecture of design stage. To our 19 requires: pre-condition 20 ensures: post-condition } knowledge, there is only a couple of ADLs developed so 21 method;+ far, i.e., RADL [32] and CBabel [5], which include in their 22 };* focus the DbC. However, their support is rather limited, 23 emitter port Name { 24 @interaction{ or, just like other ADLs, suffer from the above mentioned 25 promises: pre-condition } problems. Given the advantages of DbC in specifying formal 26 @functional{ behaviours and the importance of early formal verification, 27 promises: pre-condition 28 ensures: post-condition } we believe that this is a crucial gap not thoroughly addressed 29 event;+ so far. Indeed, if there was a DbC-based ADL providing 30 };* comprehensive support to specifying software architectures, 31 consumer port Name { 32 @interaction{ designers would be highly attracted enabling the formal 33 accepts: pre-condition verification of their architectures early on in the design stage. 34 rejects: pre-condition 35 ***OR*** 36 waits: pre-condition } 2.2 XCD– A DbC-based ADL 37 @functional{ With the main intent on specifying the behaviour of 38 requires: pre-condition 39 ensures: post-condition } implementation components, DbC contracts are, in general, 40 event;+ considered for methods provided by classes, just like JML 41 };* does. Though this is enough for specifying and verifying the 42 } implementation components, it is certainly not so at the level of software architecture design. Indeed, architectural compo- 2.2.1 Contractual Component Specifications nents includes not only the explicit specification of provided Components are used to specify at a high-level the func- services but also that of required services. Moreover, compo- tional units in software systems. Unlike AADL, XCD allows nents in software architectures may communicate explicitly designers to describe high-level components without impos- by emitting/receiving asynchronous events too. ing on them lower-level notions (e.g., threads, process). Therefore, following our initial attempt in [20], XCD Component types are essentially specified in terms of extends DbC to apply the notion of contracts to the software (i) ports representing the points of interaction with their architecture design. Component behaviour is specified with environment and (ii) data representing the component state. As depicted in Listing 1, four types of ports can be speci- rejection (rejects) conditions on an event receipt or the wait fied for a component: provided and required ports for receiv- condition for an event to be received. @functional contract ing and making method calls respectively; emitter and con- is specified with requires pre-condition and ensures post- sumer ports for emitting and receiving asynchronous events condition. requires states the condition on the received respectively from the component’s environment. Herein we actual parameters of the event whose satisfaction leads to extend DbC to allow for contractual specification of not only the ensures condition being met. Note that consumer ports provided ports, but also required ports and event ports. Fur- receive event asynchronously and do not send responses, as thermore, contracts are split into functional and interaction is the case with required ports communicating synchronous contracts, allowing to distinguish between the functional and methods. interaction behaviour. Both contract types are specified over component data and method/event action parameters. Listing 2: Generic connector structure The interaction contracts have precedence over functional; 1 connector Name { the former states when an event/method action can be taken 2 role Name { 3 data;* by a port, and the latter the functional behaviour that is the 4 required/provided port_variable Name { case upon successful execution of the action. 5 @interaction{ Provided ports – Provided ports are specified as a set 6 waits: pre-condition 7 ensures: post-condition } of synchronous method signatures, composed of return type, 8 method;+ id, parameters, and exceptions. Each method, as shown in 9 };* Listing 1, is specified using @interaction and @functional 10 emitter/consumer port_variable Name { 11 @interaction{ contract pair. @interaction is defined with a pre-condition 12 waits: pre-condition that can take two alternative forms. In the first form, it 13 ensures: post-condition } specifies when a call can be immediately accepted (accepts) 14 event;+ 15 };* or rejected (rejects), while in the second form it specifies 16 } wait condition which delays the caller before its method-call 17 channel;+ is accepted. @functional is specified with pre- and post- 18 } conditions, requires and ensures respectively. Herein, they are used to specify what actual parameters are required in 2.2.2 Contractual Connector Specifications the pre-state of the component that ensures certain specific As aforementioned, connectors in XCD are introduced to values for result/exception returned by the method-call. represent high-level complex interaction protocols which the Required ports – Likewise, required ports are spec- components interacting through connectors adhere to. ified with method signatures and contracts attached to the Connector types are specified via roles and channels.A methods. @interaction contract for a method herein is role acts as a component wrapper representing the interaction specified with a promised pre-condition that needs to behaviour of the participating component. It is described be satisfied before making the method-call. @functional with data and port-variables. The role port-variables es- contract herein is specified with promises, requires, and sentially represent the respective ports of the components ensures clauses: promises states the promised condition on adopting the role. Channels of a connector represent the the actual parameters for the method to be called, requires communication links between interacting roles and are de- states the pre-condition on the response received for the scribed with a pair of communicating role port-variables. method-call (e.g., whether exception or result is expected), As depicted in Listing 2, connector behaviour is specified ensures states the post-condition on the received response. at the role port-variable level. Port-variables are specified Emitter ports – Emitter port are specified similarly to with @interaction contracts attached to the event/method required ports. @interaction contract for an event herein actions. These interaction contracts are specified to constrain is specified with a promised pre-condition stating what port-variable actions so that the respective component ports needs to be met before the event is emitted. @functional behave in a particular manner (i.e., through execution of is specified with promises and ensures clauses: the former certain action order) that meet desired interaction protocols. states the pre-condition on the actual parameters of the event, In doing so, it can be avoided that components get involved the former states the condition on the component data after in unexpected interactions with other components associated the event emission with the promised actual parameters. Note with the same connector. The end result is then a set of that unlike required ports emitter port does not wait for a components interacting with their environments successfully response. to compose the whole system. Consumer ports – Consumer ports are specified As shown in Listing 2, @interaction contract for a similarly to provided ports. @interaction contract for an port-variable action is specified uniformly for each port- event is specified just like that of provided ports with the variable type, with waits and ensures clauses. Herein, same semantics. They state the acceptance (accepts) and waits defines a pre-condition which delays the execution of a port-variable action, namely the respective action of set, @functional in lines 38-41 is evaluated. If the the matching component port. When the wait condition is requirement that the received actual parameter data_arg satisfied, the method/event action may be executed. and the is greater than or equal to zero, then initialisedm is ensured ensures post-condition is then to be satisfied too. Note to be true and sh_data is assigned to data_arg. that when the interaction contracts for an action imposed via port-variable are met, then the interaction contracts of c) Shared-Data Connector Type: Connector type, component ports are evaluated before executing the action. sharedData, is specified in lines 45-90 which serves as a mediator between users and memory. It essentially 2.2.3 Shared-Data Access Case Study avoids memory from performing a chaotic behaviour. In Listing 1 below illustrates XCD’s DbC-based behavioral the sharedData, three roles are specified, userRole in lines specification on shared-data access. Two component types 47-53, initialiserRole in lines 55-69, and memoryRole are specified, user between lines 1-21 and memory between in lines 71-85, where the userRole and initialiserRole lines 22-44. User comprises a required port, puserr (lines are played by the user component instances and the 4-12), through which its instances call method get from the memoryRole by the memory instances. memory and an emitter port, pusere (lines 13-20), through Users playing the userRole can call method get or which event set is emitted. Memory comprises a provided emit event set in any orders. Indeed, the role port-variables port, pmem_p (lines 25-34), through which its instances pv_userr and pv_usere in lines 48-53 do not include accept calls for method get from users and a consumer port, contracts specified for the actions. pmemc (lines 35-43) through which event set is received. However, users playing the initialiserRole have to emit event set before calling get, thus first initialising the memory. The port-variable pv_init in lines 57-62 a) User Component Type: User’s required port puser is r r includes @interaction contract for method get stating that used to make a call for method get. These calls are delayed it cannot be called until the role data initialised_i is true; until the promised condition specified in @interaction is the pv_init in lines 63-68 also includes @interaction met. Since it is true in line 6, get can be called immediately. e allowing event set to be emitted immediately which then Next, the @functional in lines 7-10 is evaluated; since get ensures that the role data initialised_i is true. has no parameters, there is no promised actual parameters The memoryRole has two port-variables, pv_mem (promises condition in line 8 is true). Upon receiving p in lines 73-78 and pv_mem in lines 79-85. The former the response after calling get without parameters, if the c includes an @interaction contract for method get so that requirement that an exception is not thrown by the memory received method calls are delayed until the shared data is is true, then the received result are ensured to be stored in initialized; the latter includes @interaction for event set the data. so that when an event set is received, initialised_m is The user components emit event set through its emitter set to true. Therefore, memory components playing the port puser . Note that events are specified without return e memoryRole cannot accept calls for method get until types – they can only have identifier and parameters. The they receive event set first. The end result is a set of users emission of event set is delayed until the promised condition playing either userRole or initialiserRole interacting of @interaction in lines 14-15 is met. Since it is specified with a memory component that would not cause chaos. as true, emission is made immediately with the promised In lines 86-89, there are four channels specified to actual parameters specified in @functional (line 17). This indicate which role port-variable communicates with which then ensures that initialised_u is set to true. other role port-variable. The matching between connector roles and components b) Memory Component Type: Memory’s provided port are performed via the connector parameters, as specified in pmemp receives calls for method get. These calls are lines 45-46. At configuration time, when the sharedData accepted when the accepts condition in @interaction is is instantiated, the user and memory component instances met, initialised_m evaluating to true (line 27). Otherwise, are passed to first and last parameters respectively. the call is rejected when initialised_m is false (line 29) 1 component user{ leading to chaos. If the call is accepted, then @functional 2 bool initialised_u = false; in lines 30-32 is evaluated. There, it is ensured that the 3 int data; result value to be responded is equal to the sh_data. 4 required port puserr { 5 @interaction{ The memory components receive event set via the 6 promises : true; } consumer port pmemc. The receipt of the event set is de- 7 @functional{ layed until the promised condition is met in @interaction. 8 promises : true; 9 requires : !\exception Since it is specified as true in line 37, the set is re- 10 ensures : data = \result; } ceived immediately. Upon successful receipt of the event 11 int get(); 12 }; 83 set(int data_arg); 13 emitter port pusere { 84 }; 14 @interaction{ 85 }; 15 promises : true; } 86 channel user2memory_m(pv_userr, pv_memp); 16 @functional{ 87 channel user2memory_e(pv_usere, pv_memc); 17 promises : data_arg = 7; 88 channel init2memory_m(pv_initr, pv_memp); 18 ensures : intialised_u = true; } 89 channel init2memory_e(pv_inite, pv_memc); 19 set(int data_arg); 90 }; 20 }; 21 }; Listing 3: Shared-data Access in XCD 22 component memory { 23 bool initialised_m = false; 24 int sh_data = 0; 3. Formally Defined Semantics with FSP 25 provided port pmemp{ 26 @interaction{ The semantics of XCD are based on Finite State Process 27 accepts : initialised_m; 28 also : (FSP) [23]. FSP is essentially a process algebra allowing 29 rejects : !initialised_m; } to specify system behaviour formally with interacting pro- 30 @functional{ cesses. In this way, specifications with XCD can be trans- 31 requires : true; 32 ensures : \result = sh_data;} formed into formal FSP specifications which can further be 33 int get(); analyzed for safety and liveness properties (e.g., deadlock). 34 }; This section gives an initial flavor of the FSP mappings for 35 consumer port pmemc{ CD 36 @interaction{ X component and connector specifications in terms of 37 accepts : true; } parallel interaction (||) of FSP processes. 38 @functional{ Component Semantics The semantics of a component 39 requires : data_arg ≥ 0; 40 ensures : intialised_m = true with data D and ports p1,..., pn is the composite process:

41 && sh_data = data_arg; } PDc || Pp1 .. || Ppn (1) 42 set(int data_arg); where PDc is the data process and Pp1,..., Ppn each is a port 43 }; 44 }; process whose definition is:

45 connector sharedData(userRole{pv_userr/e}, PIC || PFCa1 .. || PFCam (2) 46 initialiserRole{pv_init }, memoryRole{pv_mem }) { r/e p/c where PIC is the interaction constraints process and 47 role userRole{ PFC ..,PFC each is a process for a functional constraints 48 required port_variable pv_userr{ a1 am 49 int get(); imposed on a single method/event action taken via the port. 50 }; Connector Semantics The semantics of a connector with 51 _ pv_user { emitter port variable e roles r ,..., r channels ch ,..., ch is the composite process: 52 set(int data_arg); 1 n 1 n 53 }; Pr1 .. || Prn (3) 54 }; where Pr1..., Prn each is a role process whose definition is: 55 initialiserRole{ role P || P .. || P (4) 56 bool initialised_i = false; Dr pv1 pvn

57 required port_variable pv_initr{ where PDr is the data process and Ppv1 ,..., Ppvn each 58 @interaction{ is a port-variable process that represents the interaction 59 when(intialised_i); waits : constraints imposed on method/event actions taken by the 60 ensures : true; } 61 int get(); port-variable. 62 }; Channels of a connector are mapped to FSP relabeling 63 _ pv_init { emitter port variable e function employed in the composite process corresponding 64 @interaction{ 65 waits : true; to the connector. The relabeling function, for each channel, 66 ensures : initialised_i = true; } re-names the actions taken by the provided/consumer port- 67 set(int data_arg); variable in one end of the channel to the names of the 68 }; 69 }; respective actions taken by the required/emitter port-variable 70 in the other end. Therefore, corresponding FSP processes can 71 memoryRole{ role synchronize on the actions they have been re-named to. 72 bool initialised_m = false; 73 provided port_variable pv_memp{ 74 @interaction{ 4. Conclusion and Future Work 75 waits : when(intialised_m); 76 ensures : true; } In this paper, we presented a new ADL, XCD, which 77 int get(); resolves three main problems either of which seems to be 78 }; 79 consumer port_variable pv_memc{ suffered by current ADLs: unfamiliar notations adopted in 80 @interaction{ specifying architectural behaviours, lack of support for com- 81 waits : true; plex connector specifications, and potentially unrealisable 82 ensures : initialised_m = true; } . In response to these problems, XCD is based on Design- [13] D. Garlan, R. Allen, and J. Ockerbloom. Architectural mismatch or by-Contract approach in specifying the behaviour of soft- why it’s hard to build systems out of existing parts. In ICSE, pages 179–185, 1995. ware architectures, instead of more abstract formal nota- [14] D. Garlan, R. T. Monroe, and D. Wile. Acme: An architecture tions (e.g., process algebras). Thus, software architectures description interchange language. In Proceedings of CASCON’97, can be specified with contracts that many developers are pages 169–183, Toronto, Ontario, November 1997. [15] D. Garlan and M. Shaw. An introduction to software architecture. In already familiar with. Furthermore, architectural connectors V. Ambriola and G. Tortora, editors, Advances in Software Engineer- in XCD can be used to specify either simple interconnection ing and Knowledge Engineering, pages 1–39, Singapore, 1993. World mechanisms or complex interaction protocols. So, large Scientific Publishing Company. [16] C. A. R. Hoare. An axiomatic basis for computer programming. and complex systems can be specified at a high level as Commun. ACM, 12(10):576–580, 1969. components interacting via complex interaction protocols [17] G. J. Holzmann. The SPIN Model Checker - primer and reference improving their development and analysis. Connectors are manual. Addison-Wesley, 2004. [18] V. Issarny, A. Bennaceur, and Y.-D. Bromberg. Middleware-layer specified in terms of decentralised roles played by the par- connector synthesis: Beyond state of the art in middleware interoper- ticipating components; there is no glue-like centralised units ability. In M. Bernardo and V. Issarny, editors, SFM, volume 6659 of forced in connector specifications. This leads to architectural Lecture Notes in Computer Science, pages 217–255. Springer, 2011. [19] J. R. Kiniry and D. M. Zimmerman. Secret ninja formal methods. designs that are realisable by construction. In J. Cuéllar, T. S. E. Maibaum, and K. Sere, editors, FM, volume To allow for formal analysis, we define the semantics 5014 of Lecture Notes in Computer Science, pages 214–228. Springer, of XCD using Finite State Process (FSP). We are currently 2008. [20] C. Kloukinas and M. Ozkaya. Xcd - Modular, realizable software exploring a definition of XCD semantics based on Promela architectures. In C. S. Pasareanu and G. Salaün, editors, FACS, volume [17], so as to take advantage of the SPIN model checker and 7684 of Lecture Notes in Computer Science, pages 152–169. Springer, better control the state- explosion problem. 2012. [21] D. C. Luckham. Rapide: A language and toolset for simulation of distributed systems by partial orderings of events. Technical report, 5. Acknowledgements. Stanford University, Stanford, CA, USA, 1996. [22] J. Magee and J. Kramer. Dynamic structure in software architectures. This work has been partially supported by the EU project In SIGSOFT FSE, pages 3–14, 1996. FP7-257367 IoT@Work – “Internet of Things at Work”. [23] J. Magee, J. Kramer, and D. Giannakopoulou. Analysing the behaviour of distributed software architectures: a case study. In FTDCS, pages 240–247. IEEE Computer Society, 1997. References [24] I. Malavolta, P. Lago, H. Muccini, P. Pelliccione, and A. Tang. What industry needs from architectural languages: A survey. IEEE [1] R. Allen and D. Garlan. A formal basis for architectural connection. Transactions on Software Engineering, 99, 2012. ACM Trans. Softw. Eng. Methodol., 6(3):213–249, 1997. [25] N. Medvidovic, P. Oreizy, J. E. Robbins, and R. N. Taylor. Using [2] L. Bellissard, N. De Palma, and D. Féliot. The olan architecture object-oriented typing to support architectural design in the c2 style. definition language. Technical report, C3DS Technical Report, 2000. In SIGSOFT FSE, pages 24–32, 1996. [3] D. Bjørner and C. B. Jones, editors. The Vienna Development Method: [26] B. Meyer. Applying “Design by Contract”. IEEE Computer, The Meta-Language, volume 61 of Lecture Notes in Computer Sci- 25(10):40–51, 1992. ence. Springer, 1978. [27] F. Oquendo. π-adl: an architecture description language based on [4] C. Boyapati, S. Khurshid, and D. Marinov. Korat: automated testing the higher-order typed π-calculus for specifying dynamic and mobile based on java predicates. In ISSTA, pages 123–133, 2002. software architectures. SIGSOFT Softw. Eng. Notes, 29(3):1–14, May [5] C. Braga and A. Sztajnberg. Towards a rewriting semantics for 2004. a software architecture description language. Electr. Notes Theor. [28] M. Oussalah, A. Smeda, and T. Khammaci. An explicit definition Comput. Sci., 95:149–168, 2004. of connectors for component-based software architecture. In ECBS, [6] L. C. Briand, Y. Labiche, and H. Sun. Investigating the use of analysis pages 44–51. IEEE Computer Society, 2004. contracts to improve the testability of object-oriented code. Softw., [29] J. Pérez, I. Ramos, J. J. Martínez, P. Letelier, and E. Navarro. Prisma: Pract. Exper., 33(7):637–672, 2003. Towards quality, aspect oriented and dynamic software architectures. [7] C. Canal, E. Pimentel, and J. M. Troya. Specification and refinement In QSIC, pages 59–66. IEEE Computer Society, 2003. of dynamic software architectures. In P. Donohoe, editor, WICSA, [30] D. E. Perry and A. L. Wolf. Foundations for the study of software volume 140 of IFIP Conference Proceedings, pages 107–126. Kluwer, architecture. SIGSOFT Softw. Eng. Notes, 17(4):40–52, Oct. 1992. 1999. [31] F. Plasil and S. Visnovsky. Behavior protocols for software compo- [8] P. Chalin, J. R. Kiniry, G. T. Leavens, and E. Poll. Beyond assertions: nents. IEEE Trans. Software Eng., 28(11):1056–1076, 2002. Advanced specification and verification with JML and ESC/Java2. In [32] R. Reussner, I. Poernomo, and H. W. Schmidt. Reasoning about FMCO’05 – Formal Methods for Comp. and Obj., volume 4111 of software architectures with contractually specified components. In LNCS, pages 342–363. Springer, 2006. A. Cechich, M. Piattini, and A. Vallecillo, editors, Component-Based [9] C. E. Cuesta, P. de la Fuente, M. Barrio-Solórzano, and M. E. B. Software Quality, volume 2693 of Lecture Notes in Computer Science, Gutiérrez. An "abstract process" approach to algebraic dynamic pages 287–325. Springer, 2003. architecture description. J. Log. Algebr. Program., 63(2):177–214, [33] D. S. Rosenblum. A practical approach to programming with 2005. assertions. IEEE Trans. Software Eng., 21(1):19–31, 1995. [10] E. M. Dashofy, A. van der Hoek, and R. N. Taylor. A highly- [34] M. Shaw, R. DeLine, D. V. Klein, T. L. Ross, D. M. Young, and extensible, xml-based architecture description language. In WICSA, G. Zelesnik. Abstractions for software architecture and tools to pages 103–112. IEEE Computer Society, 2001. support them. IEEE Trans. Software Eng., 21(4):314–335, 1995. [11] P. H. Feiler, D. P. Gluch, and J. J. Hudak. The Architecture Analysis [35] R. C. van Ommering, F. van der Linden, J. Kramer, and J. Magee. & Design Language (AADL): An Introduction. Technical report, The koala component model for consumer electronics software. IEEE Software Engineering Institute, 2006. Computer, 33(3):78–85, 2000. [12] C. Flanagan, K. R. M. Leino, M. Lillibridge, G. Nelson, J. B. Saxe, and R. Stata. Extended static checking for java. In J. Knoop and L. J. Hendren, editors, PLDI, pages 234–245. ACM, 2002.