Formal Modeling and Analysis of Software Architecture SFM 2003

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

2. Examples of Architecture Descriptions

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

9. The Problem How to bridge the gap between requirements and code? Requirements ??? Code

10. The Traditional Answer • Ad hoc • Requires gurus • Unpredictable • Costly Requirements A Miracle Happens! Code

11. Software Development Methods • Increased predictability • Some design guidance BUT • Limited applicability • Still requires gurus • Weak support for design analysis Requirements JSP OO SADT Code

12. The Role of Software Architecture • Composition of large-scale components • System-level abstractions • Reuse of system-level design idioms Requirements Software Architecture Code

13. Definitions of Software Architecture • Many definitions • Here is a typical one • But what structures? What is “behavior”? What kinds of relationships? 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.

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

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

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

17. lower split merge upper Example: Architectural Description(Component-and-Connector View) Components and Connectors

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

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

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

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

22. Elements of Architectural Descriptions: Styles • An architectural style defines a family of architecture instances including • Component/connector types • the vocabulary of architectural building blocks • Constraints on how the building blocks can be used, including • topological rules • interface standards • required properties Note: relationship between architectural styles and system instances is similar to that between types and instances

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

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

25. Dataflow pipe Couple Acquire To-XY Clip Measure Signal Trace Waveform Computation Measurement filter Data Flow:Pipes and Filters

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

27. Direct access Data Oriented Repository:Blackboard Computation Memory

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

29. Manager ADT obj obj op op op op op op obj Proc call obj op op obj op op op op op op obj obj op op obj Call-Return:Object-Oriented obj is a manager op is an invocation

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

31. Object or Process Loosely Coupled Components:Publish-Subscribe ! ? ? ! ? ? ! ! ! ? ! ! ? ? Publish-Subscribe

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

33. Client-Server Client-Server Tiers:3-Tiered Client Server Users Business Logic Databases

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

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

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

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

38. Architecture Description Languages • A number of architecture description languages (ADLs) have been developed that attempt to do this • Each language and supporting tool set • emphasizes different aspect of architecture • is good for some things; bad for others • Examples Rapide events with simulation and animation UniConemphasizing heterogeneity and compilation Wrightformal specification of connector interactions Aesopstyle-specific arch design languages Darwinservice-oriented architectures SADLSRI language emphasizing refinement Meta-H arch description for avionics domain C-2 arch style using implicit invocation

39. Tool Support for Architectural Design Tool Tool Tool ? ? ? ??? Architectural Design • Tools: • compatability checker • real-time analyser • etc... Designer

40. Example Environment: C2

41. Example Environment: Meta-H

42. Example Environment: Aesop/PF

43. Example Environment: ObjecTime

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

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

46. Acme: Modeling Architectural Structure • Components • computational elements • Ports • interface points for components • Connectors • interactions between components • Roles • interface points for connectors • Systems • graphs of component and connectors

47. port role Modeling Architectural Structure system connector component

48. client server Acme Structural Syntax 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; } }

49. Beyond Simple Structure • What else can we represent besides structure? • Local component or connector properties • Rates, capacities, latencies, etc. for individual components and connectors • Emergent system-wide properties • Overall system performance, reliability, security, etc. • Behavior • computations of components • protocols of connectors • Many forms and notations for semantics • property lists • protocol specifications • type systems ...

50. client server Acme Property Syntax 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”; }; … };