Capturing Interactions in Architectural Patterns Dharmendra K Yadav Rushikesh K Joshi Department of Computer Science and Engineering Department of Computer Science and Engineering Indian Institute of Technology Bombay Indian Institute of Technology Bombay Powai, Mumbai 400076, India Powai, Mumbai 400076, India Email: [email protected] Email: [email protected] TABLE I Abstract—Patterns of software architecture help in describing ASUMMARY OF CCS COMBINATORS structural and functional properties of the system in terms of smaller components. The emphasis of this work is on capturing P rimitives & Descriptions Architectural the aspects of pattern descriptions and the properties of inter- Examples Significance component interactions including non-deterministic behavior. Prefix (.) Action sequence intra-component Through these descriptions we capture structural and behavioral p1.p2 sequential flow specifications as well as properties against which the specifications Summation (+) Nondeterminism choice within a component are verified. The patterns covered in this paper are variants of A1 + A2 Proxy, Chain, MVC, Acceptor-Connector, Publisher-Subscriber Composition (|) Connect matching multiple connected and Dinning Philosopher patterns. While the machines are CCS- A1 | A2 i/o ports in assembly components based, the properties have been described in Modal µ-Calculus. Restriction (\) Hiding ports from Internal The approach serves as a framework for precise architectural A\{p1, k1, ..} further composition features descriptions. Relabeling ([]) Renaming of ports syntactic renaming A[new/old, ..] I. INTRODUCTION In component/connector based architectural descriptions [6], [13], components are primary entities having identities in the represents interface points as ports uses a subset of CSP for system and connectors provide the means for communication it’s formal semantics. It allows architects to specify temporal between them. This view is very similar to the abstractions communication protocols and check properties such as dead- provided by CCS [12], in which, components can be seen as lock freedom. Besides special purpose ADLs, general purpose non-movable agents and connectors as channels. Specification modeling techniques such as UML have also been found to of software architectures from designer’s point of view occurs be useful for modeling high level software architectures [7], at different levels such as process, component, module and [9]. object levels. The focus of this work is on modeling some We take an ADL-like approach in describing architectures commonly occurring architectural patterns at the component in terms of components and connectors, and use CCS, a level in terms of CCS. µ-Calculus [8] is used to specify process calculus, to model and analyze software architectures example properties against which the architectural descriptions as it provides abstractions (agents and channels) which are can be verified. The CCS based approach effectively captures very similar to components and connector abstractions found interactions occurring at architectural level through its fea- commonly in software architecture descriptions. tures such as components and their compositions, input/output In CCS, agents have input and output ports. The processes actions over channels and non-deterministic behavior. The or agent expression for an agent is constructed from a set of machines described in this paper have been verified with the atomic actions involving ports. A port name with an overbar Concurrency Workbench [4]. The grammar used in specifica- such as p represents an output port. In the basic form of the tions of the properties is as provided in [14]. language, data values can not be passed unlike in the value passing form as in expression p(x). Agents communicate with II. RELATED WORK AND BACKGROUND each other via connected pairs of input and output ports. Basic Various approaches for specifying and verifying software combinators in CCS are summarized in Table I. architectures can be found in the literature. Architecture The formal semantics of the CCS [12] is given Description Language (ADL) based approaches consist of by transitional semantics. In this the general notion of languages defined to describe, model and implement software labeled transition system as given below is used architectures. A classification of ADL based languages can t (S,T, {→: t ∈ T }) be found in [11]. Some of these languages have formal semantics supporting formal analysis. For example, Darwin Which consists of a set S of states, a set T of t [10] is a general purpose configuration language for distributed transition labels, and a transition relation →⊆ S ×S for dynamic system that uses π-calculus to model the component each t ∈ T . In this transition system S is taken to be E, the interaction and composition properties. Wright [2], which agent expression, and T is taken to be Act, the actions. The TABLE II Syntax of modal mu-calculus prop Φ ::= tt | ff | X | Φ1 ∧ Φ2 | Φ1 ∨ Φ2 | [K]Φ | hKiΦ | νX.Φ | µX.Φ | not prop | (prop) | AG prop | AF prop | A (prop ∪ prop ) | A (prop W prop ) | EG prop | EF prop | E (prop ∪ prop ) | A (prop W prop ) α semantics for E consists in the definition of each transition → over E. The transitions of each composite agent is defined in terms of the transitions of its component agent or agents. The general rule of inference will be: α α Fig. 1. Caching Proxy Pattern From E → E′ infer E|F → E′|F and it can be written in the form α E→E′ α req.request.reply.ans.P roxy E|F →E′|F Server = request.reply.Server There will be one or more transition rules associated with each combinator. The set of transition rules are as follows: Arch = Client|P roxy|Server The names Act, Sum, Com, Res and Rel indicates that The desirable properties of interaction can be captured in the rules are associated respectively with Prefix, Summation, modal µ calculus. These properties can be used as verification Composition, Restriction and Relabeling. properties to model-check the architectural descriptions. Some α ′ Ej →Ej properties are outlined below. It can be noted that the proper- Act α Sumj α ′ (j ∈ I) α.E→E Ei→E ties are expressed in terms of τ actions that occur in the above Pi∈I j machine. For each τ action, a separate observation action α α l l E→E′ F →F ′ E→E′ F →F ′ is introduced in the machine. The properties below use these Com1 α Com2 α Com3 τ E|F →E′|F E|F →E|F ′ E|F →E′|F ′ observation actions. The property-friendly verifiable machine α α E→E′ E→E′ is listed subsequently. The properties mentioned below are Rel α ′ (α, α∈ / L) Res f(α) E\L→E \L E[f] → E′[f] necessary properties. They are not sufficient. Through these properties we have tried to capture some of the essential For the specification of properties, Modal µ-Calculus has behaviours of the patterns. been used. The modal calculus [16], [17] used here is µ prop P = AG(not htreqitt) ∨ AF (htansitt) an extension of Henessy-Milner logic with two fixed point 1 prop P = A(not(htansitt)W htreqitt) operators. These two operators, least fixed and 2 µX.φ(X) prop P = AG(not( htreqitt) ∨ AF (htansitt∨ greatest fixed points allow specification of iterative 3 νX.φ(X) htrequestitt)) behavior in the system, where is a state predicate in φ(X) prop p = max X = htihtreqihtihtrequestihtihtreplyihti which state predicate variable X can occur. The syntax of 4 htansiX modal µ calculus is summarized in Table II for reference. prop p5 = max Y = htihtreqihtihtansiY III. PROXY In the verifiable machine below, the observation actions In this section, the interactions occurring in a caching proxy introduced corresponding to the τ actions are tans, treq, [3] that hides the actual server and also caches information trequest, treply. The observation actions are introduced as from the server are modeled. When a client makes a request, input actions, and they are inserted uniformly immediately the reply may be handed over to the client either by the proxy following input actions of the corresponding τ actions. The or from the server through the proxy. The CCS model shown in same structure is followed for other patterns described in the Figure 1 captures the sequence of flow of messages. The CCS subsequent sections. model includes the two possibilities through non-deterministic summation. The pattern is a composition of three components. ′ The description of the components is given below. Client = req.ans.tans.Client P roxy = req.treq.′ans.P roxy + A. Pattern Description req.treq.′request.reply.treply.′ans.P roxy Server = request.trequest.′reply.Server Client = req.ans.Client Arch = (Client|P roxy|Server)\ P roxy = req.ans.P roxy + {req, ans, request, reply} The properties can be read as below. • Whenever a client makes a request, eventually there will Controller = change-m.Controller always be an answer to the client (P ). 1 Model = change-m.change-v.Model + • Whenever there is an answer to the client, there is a prior info-req.info-rep.Model request from the client (P2). • Immediately after a request, either an answer or a further V iew = change-v.info-req.info-rep.V iew request will be generated from the proxy component (P3). Arch = Controller|Model|V iew • There is a possibility of a request from client, followed by request generated from the proxy, followed by a reply B. Verification Properties from the server and finally an answer from the proxy. some of the interaction properties for the MVC patterns are This sequence of actions may repeat infinitely(P4). listed below. • There is a possibility of a request from client, followed • If there is a request for updated information, eventually by an answer from the proxy. This sequence of actions there will be a reply (P1). may also repeat infinitely(P5).