XCD – A Design-by-Contract Architecture 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 architectures 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 designers 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 Design by Contract (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