DERI Innsbruck Seminar – March 2004 Robert Allen and David Garlan: A Formal Basis for Architectural Connection Uwe Keller

Folie - 2 Contents Introduction Motivation Architecural descriptions Basic idea Architectural Descriptions Requirements Connector specification Connector semantics Analyzing architectural descriptions Contents

Folie - 3 Motivation … Software systems become more and more complex A software architecture is extremely important (SA = How to achieve the requirements) is a central design problem Informal architectural descriptions are ubiquitous CS-organization, layered system, blackboard architecture, … Typically: box-and-line-drawings Drawback of informal approach Good for documentation, but … What do these descriptions precisely mean? Analyze architecural consistency? Detemine non-trivial properties of the architecture? Is the implementation faithful to the architectural design? Introduction

Folie - 4 Motivation (II) … Managing the complexity is crucial for building systems of high quality Do we understand what a designed system actually does? How can we deal with the complexity? Divide & conquer Software system = Components + Relationships (Glue) Use engineering techniques for software design (Model & Analysis) Requires: a formal basis for the description of software architectures! What do we gain? Predict important system properties (function., behaviour,...) Ensure Consistency & Completeness Introduction

Folie - 5 Describing System Architectures … Breaking down large software systems by decomposition Understanding properties of the parts allows reasoning about the overall proporties of the whole system Traditional approach: MIL/IDL Languages System = Modules + „definition/uses“ relationship Modules declare what they provide and what do they require „Glue“: Mapping between facilities that are provided and used „Implementation“-View (+) Can easily be mapped to programming languages, automated checks (type checking), „formal reasoning“ (pre/postcondition checks), Consistency & Completeness checks by prog. languages (-) Not suited for describing interaction relationships Introduction

Folie - 6 Describing SA (II) … Example: A Pipes & Filters – System „Capitalize“ Introduction ?? How do the modules actually interact ?? Fails to show the architectural connection! Where are the pipes & filters?

Folie - 7 Describing SA (III) … Breaking down large software systems by decomposition Understanding properties of the parts allows reasoning about the overall proporties of the whole system Alternative Approach: System = Modules + „interaction“ relationship Modules declare their behaviours and interactions between modules are defined by connectors „Glue“: Connects behaviour of interacting modules „Interaction“-View (+) Can be used to check compatibility of interacting elements (Can modules interact? - Consistency) and whether all assumption of all elements about their interactions are met (Completness) (-) Not suited for reasoning about correctness of functionality, not supported by programming languages themselves Introduction

Folie - 8 Describing SA (IV) … Example: A Pipes & Filters – System „Capitalize“ Introduction Pipe Filter Pipe Filter Pipe Highlights the abstract interaction between architectural components!

Folie - 9 In this paper … Focus on special relationships (glue) Interaction relations between architectural elements Model these interactions explicitly Find answers to questions like Can particular elements interact? (Consistency) A filter either reads or writes to a pipe? Filters agree on how to signal end-of-file? Does the reader expect more data than the writer will provide? Are the assumptions about interaction are met for all elements? (Completeness) Is a pipe intialized before the writer starts to write? Is the writer intialized exactly once? But so far these pictures are only informal depictions with loose semantics! Thus … Provide a formal basis for specifying the interactions among architectural components Introduction

Folie - 10 Basic idea …. In essence: Provide a notation and underlying theory that gives architectural connection explicit semantic status ► Concept of Connectors Describe connector types Protocols are common methods for specifying interaction between parts of a system Characterize the protocol of interaction between the architectural components Formal underpinning: Communicating Sequential Processes (CSP) - mathematical model of processes by Hoare (1985) Novelties … „Unusual“ & new application domain for protocols, distinguish types form instances, decomposition of connector descriptions into parts Introduction

Folie - 11 Requirements … What do we need for specifying architecural connection? Starting Point: System = Components + Connectors Expressiveness Common architecural interaction(Procedure call, pipes, event broadcast, shared variables …) Complex interactions among components Fine-grained distinctions between variations of connector Analytic capability Undestand the behaviour of a connector independent of the specific context of use Reason about composition of components and connectors Flexibility wrt. what components can be plugged to a connector Architecural Descriptions

Folie - 12 Describing an architecture … Use an architecture description language: WRIGHT Example: A simple client- server-system Architecural Descriptions Client request Server provide Connector server client s cs c Port = logical point of interaction Represents a role of a component in an interaction Obligations of each of the interacting parties! How a component actually behaves! (At this port / role) How the interaction is coordinated

Folie - 13 Connector specification … Roles = specification of behaviour of components Glue = Specification of their combinations How to describe the behaviour formally: Behaviour of a connector = Spec of interacting protocols Use a process algebra to model traces of communication events Specifically: A subset of CSP [Hoare, 1987] Process Notation Processes & events Process = Entity that can engage in communication events (P) Events may be primitive or can be associated with data (e?x, e!x) STOP = events that engages in no event (terminated process) √ = represents „success“ event α P = alphabet of process P Connector Descriptions

Folie - 14 Notation (I) … Prefixing: e  P represents a process P* that engages in event e and then becomes process P Alternative (external choice): P□Q a process that can behave like P or Q, where the choice is made by the environment (other process that interact with this process) Decision (internal choice): P∏Q a process that can behave like P or Q, where the choice is made (nondeterministically) by this process itself Named processes Names can be associated with a (recursive) process expression Parallel composition: P||Q Synchronous interaction of parallel processes by jointly engaging in events (in the intersection of their alphabets) Connector Descriptions

Folie - 15 Notation (II) … Example: (e  f  P □ g  Q) Semantically, in CSP a process P = (A, F, D) where A = alphabet of P (events that P can engage in) F = set of failures (pairs of a trace and a set of events that the process can refuse to engage in after having executed the trace) D = set of divergences (sets of traces after which a process can behave chaotically) Additional notation: § = successfully terminating process (formally: § = √  STOP ) Scoped process name: „let Q = process-expr in R“ Labeled events and processes: l.e (event e with label l), l:R (l labels all events of process R) Connector Descriptions

Folie - 16 Describing Connectors … For describing a connector type (e.g. Client-Server), we provide process descriptions of: Roles & Glue Example: Client-Server-Connector Connector Descriptions The server is not allowed to terminate until the environment requests it!

Folie - 17 Example (I) … A shared variable … Connector Descriptions I think that „ √ “ should be „§“ !

Folie - 18 Example (II) … A shared variable (a variation)… Connector Descriptions I think that „ √ “ should be „§“ !

Folie - 19 Example (III) … A shared variable (another variation)… Connector Descriptions Where is the problem ?

Folie - 20 Example (IV) … A more complex example: a pipe connector Connector Descriptions

Folie - 21 Connector Semantics … Now we have a notation for describing connectors But what does it precisely mean? Principle Map the description into CSP in order to defined the formal semantics of our descriptions? In particular, this makes precise, how the glue and the role specifications relate to each other in any connector specification! Basic Idea for formalizing connector specs: Treat roles as independent processes that are constrained only by the glue This leads to to the use of the parallel composition operator „||“ Connector Descriptions

Folie - 22 Connector Semantics (II) … Def: The meaning of a connector description with roles R1,…, Rn and glue G is the process G || (R1:R1 || R2:R2 || … || Rn:Rn) where Ri is the distinct name of the Role Ri and α G = R1:Σ U R2:Σ U … U Rn:Σ U {√} Notice: The definition of the glue’s alphabet allows the glue to interact with each role, but the roles can’t interact with each other directly (only indirectly via the glue!) Because the event “√” is not relabeled, every role and the glue must agree on the for it to occur: It’s not possible for one participant in the interaction to terminate without the other participant doing so! Connector Descriptions

Folie - 23 Ports and connector instantiation... Thus far: Only considered component types But to complete the picture: We must describe the ports of a component and how those ports are attached as specific connector roles in the complete software architecture In WRIGHT: Component ports are also specified as processes Defined the behaviour of the component at the point of interaction identified by the role Example: A simple data user Connector Descriptions

Folie - 24 Ports and conn. instantiation (II)... What happens if we connect a component to a connector? Map a port to a role The port protocol take the place of the role protocol in the resulting system The roles act as specifications for the ports: Provided that the ports satisfy the role specifications, they will stand for those roles in the running system. Thus, the semantics of of an attached connector is … the protocol that results from replacing the role processes with the associated port processes. Formally: The meaning of attaching ports P1, …, Pn as roles name R1, …, Rn of connector with glue G is the process G || (R1:P1 || R2:P2 || … || Rn:Pn) Connector Descriptions

Folie - 25 Ports and conn. instantiation (III)... Implicit assumption: Port protocols & role protocols are identical (replacement) But: For practicial cases it‘s also important to allow ports to differ from the roles that they replace (reuse of connectors!) Example: We want to be able to attach the „DataUser“ component to a shared-variable connector even if it only reads the value of a variable but never takes advantage of setting it Instead of „identical“ protocols we need „compatible“ processes! What does it „compatible“ processes precisely means? Connector Descriptions

Folie - 26 Analyzing architecural descriptions What kind of analyses and checking are made possible by our connector notation and formalism? Compatibility (of Port with Role) Deadlock freedom Compatibility of Ports with Roles Can two components safely communicate using a particular form of interaction? In our model: Can a given port be used in a given role? Informally: „When in a situation predicted by a protocol, then the port must always continue the protocol in a way the role could have“ IoW: The role process should be substitutable by the port in such a way that the that the rest of the connector interaction cannot detect the replacement Analyzing Descriptions

Folie - 27 Port-Role-Compatibility … Formally in CSP: „Refinement of processes“ A process P is refined by a process Q (P≤Q) if their alphabets are the same and the failures of P are a subset of the failures of Q and the divergences of P are a subset of the divergences of Q Example: But the refinment relation itself is not enough to define port-role compatibility: Alphabets of processes are assumed to be that same (no problem to resolve) We want to reuse connectors as often as possible: Process-definition might have incompatible behaviour with role in general, but this behaviour would be never arise in the context of a specific connector Thus: For compatibility we need to consider only traces described by the role: Any trace of the port not described by the role will not arise in a particular interaction described by the connector! Analyzing Descriptions

Folie - 28 Port-Role-Compatibility (II) … Formally in CSP: Deterministic version of process R: Compatibility: Example Analyzing Descriptions s { e }, Port

Folie - 29 Deadlock Freedom … Why did we choose this definition of compatibility? Idea Like type checking for prog languages, „compatibility“ for arch descriptions is intended to provide certain garantuees that the system is well-formed Important property wrt Interaction: Deadlock-freedom Deadlock-freeness Interacting elements can not get stuck during the interaction But: we want to allow terminating behaviour (global!) Formally: A connector process C is deadlock-free if whenever it is in a situation where it can‘t make progress, then the last event that has taken place must have been the success event „ √“ Analyzing Descriptions

Folie - 30 Deadlock Freedom (II) … Detecting deadlock-freedom for Connector C provides a sanity check for the CType-Definition But: In an actual systems we have connector instantiations! Can we carry over the deadlock-freedom result for the connector type to the instantiation (of roles by ports)? Trivial for: Role process = Port process (Unrealistic) Simple for: R≤P (CSP-Refinement) But we have deliberatly chosen a weaker condition than refinement for compatibility! Does it also hold there? NO! Not necessarily :‘- ( Analyzing Descriptions

Folie - 31 Deadlock Freedom (III) … Problem is: When glue allows behaviour outside those defined by the roles of the roles: Here: Compatible substitutions don‘t preserve DL-Freed. We need some additional constraint for the glue G: The glue is responsible for preventing behaviours that are not covered by the role specifications Analyzing Descriptions Glue G Role R1 Port P1

Folie - 32 Deadlock Freedom (IV) … Now we have: Significance of the theorem: Local compatibility checking is sufficient to maintain deadlock- freedom (allows reuse of Connector types & established properties) Soundness-check for the definition of compatibility: Under any execution, a compatibility-instantiated architectural description retains certain properties Analyzing Descriptions

Folie - 33 Automated checking … Desired Automated checking for well-formedness of connectors (conservative & deadlock-free) Ports are compatible with roles This is possible by applying Modelchecking (wellformedness) FDR (Tool that checks Refinement of CSP processes) Thus We have a tool for architectural descriptions that works similar to type checking in programming languages but on an architectural level. Analyzing Descriptions

Questions ?