Formal Modeling and Analysis of Software Architecture Components

Formal Modeling and Analysis of Software Architecture: Components, Connectors, and Events SFM 2003 Bertinoro, Italy David Garlan Carnegie Mellon University Software Architectures © David Garlan 1

Examples of Architecture Descriptions Software Architectures © David Garlan 2

Talk Outline p. Part 1: Overview of Software Architecture v What is software architecture? v What are essential architectural concepts? p. Part 2: Modeling and Analysis v Formal representations of architecture v Formal analysis and model checking of architectures v UML p. Part 3: Frontiers v Ubiquitous computing v Mobility v Two-tiered methods (MDA) v Others Software Architectures © David Garlan 8

The Problem Requirements How to bridge the gap between requirements and code? ? ? ? Code Software Architectures © David Garlan 9

The Traditional Answer Requirements p Ad A Miracle Happens! hoc p Requires gurus p Unpredictable p Costly Code Software Architectures © David Garlan 10

Software Development Methods Requirements p Increased JSP SADT OO predictability p Some design guidance BUT p Limited applicability p Still requires gurus p Weak support for design analysis Code Software Architectures © David Garlan 11

The Role of Software Architecture Requirements p Composition large-scale components p System-level abstractions p Reuse of systemlevel design idioms Software Architecture Code Software Architectures of © David Garlan 12

Definitions of Software Architecture p Many definitions p Here is a typical one A software architecture for a system is the structure or structures of the system, which comprise elements, their externally-visible behavior, and the relationships among them. p But what structures? What is “behavior”? What kinds of relationships? Software Architectures © David Garlan 13

Issues Addressed by an Architectural Design p Gross decomposition of a system into interacting components v typically hierarchical v using rich abstractions for component interaction (or system “glue”) v often using common design idioms/styles p Emergent system properties v performance, throughput, latencies v reliability, security, fault tolerance, evolvability p Rationale v relates and assignment of function to components requirements and implementations p Envelope of allowed change v “load-bearing walls”, limits of scalability and adaptation v design idioms and styles Software Architectures © David Garlan 14

Many Views of Architecture p There are many possible views of software systems v Module Fe. g. , structures: code/implementation structures class diagrams, work breakdown structures, “def-use” graphs v Deployment Fe. g. , processors , networks v Run-time Fe. g. , structures: physical/resources structures: system structure and behavior at run time clients, servers, databases, instances of objects p Each has its purpose in understanding the overall nature of a system v Modules good for reasoning about maintenance v Deployment good for reasoning about resources v Run-time good for reasoning about system behavior p In this lecture I will focus on run-time structures Software Architectures © David Garlan 15

Example: Alternating Characters (Module View) Produce alternating case of characters in a stream main split lower upper config merge input/output Definition/Use Modularization Software Architectures © David Garlan 16

Example: Architectural Description (Component-and-Connector View) lower split merge upper Components and Connectors Software Architectures © David Garlan 17

Why Formalize Software Architecture? p Understanding v. Precise definition of system v. Clarification of requirements p Analysis v. System-level analysis of critical properties p Construction v. Blueprint for construction; basis for code generation v. Identify opportunities for reuse p Evolution v. Define allowable envelope of change, ensure that system invariants are not violated Software Architectures © David Garlan 18

Software Architecture in Context Integrated product lines Component-based systems 2000 Software architecture Packages Pipes and filters Software development environments Inheritance 1980 Abstract data types objects Programming-in-the-large Information hiding NATO SE conference 1970 Separate compilation Subroutines 1950 Software Architectures 1960 1990 Programmingin-the-world Programmingin-the-large Programming -in-the-small Programmingany-which-way © David Garlan 19

Evolution of the Field Today v Recognition of the value of architects in software development organizations v Processes that require architectural design reviews and explicit architectural documentation v Emerging use of product line architectures, commercial architectural standards, component integration frameworks v Codification of vocabulary, notations & tools for architectural design v Books/courses on software architecture p Unfortunately v Little use of formal models, tools, analyses v Many gaps in our understanding about how to model and analyze key aspects of software architecture Software Architectures © David Garlan 20

Elements of Architectural Descriptions: Systems p. The architecture of an individual system identifies its principle v Components: define the locus of computation FExamples: filters, databases, objects, ADTs v Connectors: mediate interactions of components FExamples: procedure call, pipes, event broadcast v Properties: specify information for construction & analysis FExamples: signatures, pre/post conditions, RT specs, protocols, performance attributes Software Architectures © David Garlan 21

Elements of Architectural Descriptions: Styles p. An architectural style defines a family of architecture instances including v Component/connector types F the vocabulary of architectural building blocks v Constraints on how the building blocks can be used, including Ftopological rules Finterface standards Frequired properties Note: relationship between architectural styles and system instances is similar to that between types and instances Software Architectures © David Garlan 22

Taxonomy of Architectural Styles Data Flow Data-oriented repository Batch sequential Dataflow network (pipes&filters) Transactional databases True client/server acyclic, fanout, pipeline, Unix Blackboard Modern compiler Closed loop control Call-and-return Data-sharing Main program/subroutines Information hiding Compound documents Hypertext Fortran COMMON LW processes ADT, object, naive client/server Interacting processes Communicating processes LW processes, distrib objects, Event systems Hierarchical Layered implicit invocation, pure events Software Architectures Interpreter © David Garlan 23

Styles: Questions to Address p System v What Model is the overall organizational pattern? p Structure v What are the basic components and connectors? v What topologies are allowed? p Computation v What is the underlying computational model? v How is control and data transferred between components? p Properties v Why is this style useful? v What kinds of properties are exposed? p Analyses v What Software Architectures kinds of analysis does the style support? © David Garlan 24

Data Flow: Pipes and Filters Dataflow Signal Couple Acquire pipe To-XY Waveform Computation Software Architectures Trace Measure filter © David Garlan Clip Measurement 25

Pipes and Filters p Filter v Incrementally transform some amount of the data at inputs to data at outputs FStream-to-stream transformations v Use little local context in processing stream v Preserve no state between instantiations p Pipe v Move data from a filter output to a filter input v Pipes form data transmission graphs p Computational Model v Run pipes and filters (non-deterministically) until no more computations are possible. p Analysis v Functional Software Architectures composition; additive latencies; etc. © David Garlan 26

Data Oriented Repository: Blackboard Direct access Computation Memory Software Architectures © David Garlan 27

The Blackboard Model p Knowledge Sources v World and domain knowledge partitioned into separate, independent computations v Respond to changes in blackboard p Blackboard Data Structure v Entire state of problem solution v Hierarchical, non-homogeneous v Only means by which knowledge sources interact to yield solution p Computational Model v Changes to data in blackboard by one knowledge source trigger the actions of other knowledge sources to create new blackboard data Software Architectures © David Garlan 28

Call-Return: Object-Oriented Manager ADT obj op op Proc call obj op op op obj op op is an invocation Software Architectures op op op obj is a manager op op obj obj op obj © David Garlan 29

Call-Return Systems p Objects v Encapsulate representations v Provide interfaces to access services p Connectors v Call-return; service invocation p Computational v Services blocks Model requested from known service provider; Requester p Analysis v Correctness it invokes Software Architectures of a component depends on correctness of services © David Garlan 30

Loosely Coupled Components: Publish-Subscribe ! ? ! Object or Process ! ! ! ? ? ! ! ? ? ? ? Publish-Subscribe Software Architectures © David Garlan 31

Publish-Subscribe (Implicit Invocation) p Components v Objects, processes v Have a set of methods v Announce (publish) events – via multicast v Subscribe to events by associating a procedure to call p Connectors v Event space (bus) v Typically implemented as a dispatcher p Computational model v When an event is announced invoke associated procedures (in any order) v Correctness of a component should not depend on correctness of components that subscribe to its announced events. Software Architectures © David Garlan 32

Tiers: 3 -Tiered Client Server Users Client-Server Business Logic Client-Server Databases Software Architectures © David Garlan 33

Many Others p Often styles are used in combination v Example: each layer might be different style internally v Example: a component might have substructure defined in a different style than its surrounding p Many styles are closely tied to specific domains -- often by specializing a more generic style v sometimes called component integration frameworks v N-tiered MIS Systems v OSI Protocol Stack v Instrumentation Systems p In many cases these are specialized to a particular product family, v sometimes Software Architectures called a product line architecture © David Garlan 34

Talk Outline p. Part 1: Overview of Software Architecture v What is software architecture? v What are essential architectural concepts? p. Part 2: Modeling and Analysis v Formal representations of architecture v Formal analysis and model checking of architectures v UML p. Part 3: Frontiers v Ubiquitous computing v Mobility v Two-tiered methods (MDA) v Others Software Architectures © David Garlan 35

The Challenge for Architectural Description p Software Architecture frees us from the limitations of programming language abstractions v new kinds of components Fnot v new kinds of glue (connectors) Fnot v new just procedure call, data sharing patterns, idioms, styles for system structure Fnot v many Fnot Software Architectures just abstract data types, modules, and objects just for algorithms and data structure properties of interest just functional behavior © David Garlan 36

p How can we establish intellectual control over this new world? Ideally we would like to: (1) express arch descriptions precisely and intuitively Fboth syntax and semantics (2) develop soundness criteria & tools to check them Fwhat type checkers and linkers do for current systems (3) analyze architectures to determine key properties Fsuch as performance, reliability, change impact, interoperability (4) exploit patterns and styles Fwithout unnecessary proliferation and isolation of new design languages and tools Software Architectures © David Garlan 37

Architecture Description Languages p. A number of architecture description languages (ADLs) have been developed that attempt to do this p Each language and supporting tool set v emphasizes different aspect of architecture v is good for some things; bad for others p Examples Rapide events with simulation and animation Uni. Con emphasizing heterogeneity and compilation Wright formal specification of connector interactions Aesop style-specific arch design languages Darwin service-oriented architectures SADL SRI language emphasizing refinement Meta-H arch description for avionics domain C-2 arch style using implicit invocation Software Architectures © David Garlan 38

Tool Support for Architectural Design ? ? ? Designer Tool ? Architectural Design Tools: compatability checker real-time analyser etc. . . Software Architectures © David Garlan 39

Example Environment: C 2 Software Architectures © David Garlan 40

Example Environment: Meta-H Software Architectures © David Garlan 41

Example Environment: Aesop/PF Software Architectures © David Garlan 42

Example Environment: Objec. Time Software Architectures © David Garlan 43

Features of Modern ADLs p System structure is defined separately from individual components v parts are “context independent” v supports hierarchical design p New kinds of connectors can often be defined v need not be realizable directly by a single primitive of an implementation language v have rich semantics p Can express/analyze extra-functional properties v performance, p Support for architectural styles v reusable Software Architectures reliability, etc. architectural patterns © David Garlan 44

Acme ADL p. A good example of an ADL p Originally designed as an interchange language p Later became full-fledged ADL p Attempts to provide open-ended approach for architectural representation v Like XML for architecture p We’ll use that in the next few slides to illustrate modeling techniques and tools Software Architectures © David Garlan 45

Acme: Modeling Architectural Structure p Components v computational elements p Ports v interface points for components p Connectors v interactions between components p Roles v interface points for connectors p Systems v graphs Software Architectures of component and connectors © David Garlan 46

Modeling Architectural Structure system connector component port Software Architectures role © David Garlan 47

Acme Structural Syntax client server System simple-cs = { Component client = { port call-rpc; }; Component server = { port rpc-request; }; Connector rpc = { role client-side; role server-side; }; Attachments = { client. call-rpc to rpc. client-side; server. rpc-request to rpc. server-side; } } Software Architectures © David Garlan 48

Beyond Simple Structure p What else can we represent besides structure? v Local component or connector properties FRates, capacities, latencies, etc. for individual components and connectors v Emergent FOverall system-wide properties system performance, reliability, security, etc. v Behavior Fcomputations Fprotocols p Many of components of connectors forms and notations for semantics v property lists v protocol specifications v type Software Architectures systems. . . © David Garlan 49

Acme Property Syntax client server System simple-cs = { … Component server = { port rpc-request = { Property sync-requests : boolean = true; }; Property max-transactions-per-sec : int = 5; Property max-clients-supported : int = 100; }; Connector rpc = { … Property protocol : string = “aix-rpc”; }; … }; Software Architectures © David Garlan 50

Substructure p Provide p Can hierarchical element abstractions represent sub-architectures or “views” Configuration . . . Abstraction Map System (sub-architecture) Component Representation Software Architectures © David Garlan 51

Types and Styles p Types v Define a collection of related architectural elements v Subtyping and (multiple) inheritance v Formally, a type is just a predicate v Examples: filter component, pipe-connector, client-server connector, dataflow-input-port p Styles (called “Families” in Acme) v. A collection of types and a set of constraints v Types determine the “vocabulary” of the style v Constraints determine how that vocabulary can be used v Can be viewed as a type of a system v Example: pipe-filter family, client-server family Software Architectures © David Garlan 52

Element and Property Types p Examples of component types Component Type filter. T = { Ports {in, out} }; Component Type unix. Filter. T = filter. T extended with{ Port error; Property throughput : int; }; p Examples of property types Property Type point. T = record [x: int; y: int]; Property Type messages. T = seq<string>; Property Type Wright-spec. T = string; Property msgs : messages. T = <“start”, “stop”>; Software Architectures © David Garlan 53

Styles/Families p Example Family pipe. Filter. Fam = { Component Type filter. T = {…} Connector Type pipe. T = {…} Connector Template mk. Pipe(in: Port, out: Port)={…}; …} System pf : pipe. Filter. Fam = {…} Software Architectures © David Garlan 54

Constraints p Architectural documentation requires the ability to say what aspects of a description are invariant. p Examples v Topology v Properties v Types of elements v Behavior of system v Possible configurations during run-time Software Architectures © David Garlan 55

Acme Constraints p First-order predicate logic v Standard boolean operators and quantifiers v With special built-in functions for architecture p First class in the following sense v Explicitly defined in an architectural description v Checkable by tools v Can be named v Can be aggregated into larger units (e. g. , styles) p Unified with overall type system v. A type is simply a predicate v A style (family) is simply the type of a system v Similar in spirit to PVS p Two flavors: Invariants and Heuristics Software Architectures © David Garlan 56

Example: Defining a Component Type naïve-client = { Port Request = { Property protocol = rpc-client }; Property request-rate : integer << default = 0; units = “rate-per-sec” >>; Invariant forall p in self. Ports | (p. protocol = rpc-client); Invariant size(Ports) <= 5; Invariant request-rate >= 0; Heuristic request-rate <= 100; } Software Architectures © David Garlan 57

Example: Constraining a System simple. CS = { … // simple rule requiring a primary server Invariant exists c : server in self. components | c. is. Primary. Server == true; // simple performance heuristic Heuristic forall s : server in self. components | s. transaction. Rate >= 100; // do not allow client-client connections Function no-peer-connections(sys : System) = forall c 1, c 2 in sys. components | connected(c 1, c 2) -> !(declares. Type(c 1, client. T) and declares. Type(c 2, client. T)); … }; Software Architectures 58 © David Garlan

Example: Defining an Architectural Style naïve-client-server-style = { // declare vocabulary Component Type naïve-client = {. . . }; Component Type naïve-server = {. . . }; . . . // declare design analyses Function no-peer-connections(sys : System) = {. . . }; . . . // declare style-wide design rules Invariant no-peer-connections(self); Heuristic forall s : server in self. components| s. transaction. Rate >= 100; . . . } // end style definition Software Architectures © David Garlan 59

Larger Example and Demo p NASA Mission Data Systems (MDS) v Architectural style for NASA space software v To be used in 2009 mission to Mars v Primarily autonomous, mobile, robotics p The Style v Components: sensors, actuators, controllers v Connectors: state query, submit command v Constraints: over 39 constraints p Analyses and Tools v Style conformance v Performance v Code generation Software Architectures © David Garlan 60

Demo of MDS and Acme Studio Software Architectures © David Garlan 61