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

DERI Innsbruck Seminar – March 2004

Robert Allen and David Garlan:

A Formal Basis for Architectural Connection

Uwe Keller

Folie - 2

Contents

IntroductionMotivationArchitecural descriptionsBasic idea

Architectural DescriptionsRequirementsConnector specificationConnector semantics

Analyzing architectural descriptions

Contents

Folie - 3

Motivation …

Software systems become more and more complexA software architecture

is extremely important (SA = How to achieve the requirements)is a central design problem

Informal architectural descriptions are ubiquitousCS-organization, layered system, blackboard architecture, …Typically: box-and-line-drawings

Drawback of informal approachGood 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 & conquerSoftware 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 LanguagesSystem = 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 relationshipsIntroduction

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

Pipe

Filter

Filter

Filter

Pipe

Pipe

Filter

Pipe Pipe

Highlights the abstract interaction between architectural components!

Folie - 9

In this paper …

Focus on special relationships (glue)Interaction relations between architectural elementsModel these interactions explicitly

Find answers to questions likeCan 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 typesProtocols are common methods for specifying interaction between parts of a systemCharacterize the protocol of interaction between the architectural componentsFormal 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 partsIntroduction

Folie - 11

Requirements …

What do we need for specifying architecural connection?Starting Point: System = Components + Connectors

ExpressivenessCommon architecural interaction(Procedure call, pipes, event broadcast, shared variables …)Complex interactions among componentsFine-grained distinctions between variations of connector

Analytic capabilityUndestand the behaviour of a connector independent of the specific context of useReason about composition of components and connectorsFlexibility wrt. what components can be plugged to a connector

Architecural Descriptions

Folie - 12

Describing an architecture …

Use an architecture description language: WRIGHTExample: A simple client-server-system

Architecural Descriptions

Clientrequest

Serverprovide

Connectorserver

client

s

cs

c

Port = logical point of interactionRepresents 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 componentsGlue = Specification of their combinationsHow to describe the behaviour formally:

Behaviour of a connector = Spec of interacting protocolsUse a process algebra to model traces of communication eventsSpecifically: A subset of CSP [Hoare, 1987]

Process NotationProcesses & 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 PConnector Descriptions

Folie - 14

Notation (I) …

Prefixing: ePrepresents a process P* that engages in event e and then becomes process P

Alternative (external choice): P□Qa 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∏Qa process that can behave like P or Q, where the choice is made (nondeterministically) by this process itself

Named processesNames can be associated with a (recursive) process expression

Parallel composition: P||QSynchronous 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 & GlueExample: Client-Server-Connector


The server is not allowed to terminate until the environment requests it!

Folie - 17

Example (I) …

A shared variable …


I think that „ √“ should be „§“ !

Folie - 18

Example (II) …

A shared variable (a variation)…


I think that „ √“ should be „§“ !

Folie - 19

Example (III) …

A shared variable (another variation)…


Where is the problem ?

Folie - 20

Example (IV) …

A more complex example: a pipe connector


Folie - 21

Connector Semantics …

Now we have a notation for describing connectorsBut 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 „||“


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!


Folie - 23

Ports and connector instantiation ...

Thus far: Only considered component typesBut to complete the picture:

We must describe the ports of a componentand how those ports are attached as specific connector roles in the complete software architecture

In WRIGHT:Component ports are also specified as processesDefined the behaviour of the component at the point of interaction identified by the role

Example: A simple data user


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)


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?


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 RolesCan 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 andthe failures of P are a subset of the failures of Q andthe 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!


Folie - 28

Port-Role-Compatibility (II) …

Formally in CSP:Deterministic version of process R:

Compatibility:

Example


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-formedImportant property wrt Interaction: Deadlock-freedom

Deadlock-freeness Interacting elements can not get stuck during the interactionBut: 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 „ √“


Folie - 30

Deadlock Freedom (II) …

Detecting deadlock-freedom for Connector C provides a sanity check for the CType-DefinitionBut: 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 :‘- (


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


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


Folie - 33

Automated checking …

DesiredAutomated checking for

well-formedness of connectors (conservative & deadlock-free)Ports are compatible with roles

This is possible by applyingModelchecking (wellformedness)FDR (Tool that checks Refinement of CSP processes)

ThusWe have a tool for architectural descriptions that works similar to type checking in programming languages but on an architectural level.


Questions ?

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

Documents

system architectures

layered system

designed system

pipes filters system

milidl languages system

system traditional approach

system alternative approach

motivation software