1 / 111

Modeling and Analysis of Software Architecture

Modeling and Analysis of Software Architecture. Robert T. Monroe. Carnegie Mellon University 5000 Forbes Ave. Pittsburgh, PA 15213 bmonroe@cs.cmu.edu. FreeMarkets Corp. One Oliver Plaza Pittsburgh, PA 15222 bmonroe@freemarkets.com. Acknowledgment.

masato
Download Presentation

Modeling and Analysis of Software Architecture

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Modeling and Analysis of Software Architecture Robert T. Monroe Carnegie Mellon University 5000 Forbes Ave. Pittsburgh, PA 15213 bmonroe@cs.cmu.edu FreeMarkets Corp. One Oliver Plaza Pittsburgh, PA 15222 bmonroe@freemarkets.com

  2. Acknowledgment Some of the material in this tutorial was drawn from a tutorial on Software Architecture developed by Mary Shaw and David Garlan. Some parts are adapted from a semester course on Software Architecture taught by Mary Shaw and David Garlan from 1992-1998. Robert Allen, of IBM, helped greatly in the creation of a previous version of this tutorial. The development of the tutorial was supported in part by grants from the US Department of Defense Advanced Research Project Agency. The underlying research has been supported by the US Department of Defense, the National Science Foundation, Siemens Corporation, The Eastman Kodak Corporation, and Carnegie Mellon University.

  3. Outline • Introduction to Software Architecture • Architectural Modeling • Architectural structure and topology • Properties and protocols • Architectural Analysis • Architectural Style • Overview of ADLs and Design Tools • Conclusions, opportunities & challenges

  4. Three Ideas To Take Away • Architecture description languages and toolkits (ADLs) are useful for describing, documenting, and reasoning about Software Architectures. • There are a number of interesting and useful architecture-level analyses that can be performed with existing ADLs and their associated toolkits. • There are further powerful analysis and generation capabilities on the horizon.

  5. Typical Descriptions ofSoftware Architectures • Descriptions of software systems often include a section on “the architecture of this system” • Usually informal prose plus box-and-line diagram • Lots of appeal to intuition • Little precision, rarely formal The Architecture of This System Next Section

  6. Typical Descriptions ofSoftware Architectures • "Camelot is based on the client-server model and uses remote procedure calls both locally and remotely to provide communication among applications and servers." [Spector 87] • "We have chosen a distributed, object-oriented approach to managing information." [Linton 87] • "The easiest way to make the canonical sequential compiler into a concurrent compiler is to pipeline the execution of the compiler phases over a number of processors." [Seshadri 88] • "The ARC network [follows] the general network architecture specified by the ISO in the Open Systems Interconnection Reference Model." [Paulk 85]

  7. Observations about Designers • They freely use informal patterns (idioms) • Very informal, imprecise semantics • Diagrams as well as prose, but no uniform rules • Communication takes place anyhow • Their vocabulary uses system-level abstractions • Overall organization (styles) • Kinds of components and interactions among them • They compose systems from subsystems • Tend to think about system structure statically • Often select organization by default, not by design

  8. Architectural Design Level of Software • Deals with the composition of software systems from module-scale elements • Gross decomposition of required function • What patterns of organization are useful? • Which organization fits the application best? • Assignment of function to design elements • What are the elements? • How do the elements interact? • Emergent system properties • Scaling and performance: Capacities, balance, schedules • Security • ... • Selection among design alternatives • Which implementations of elements will work best?

  9. Architectural Design Task interactions among parts implementations of parts structural properties computational properties declarative operational mostly static mostly dynamic system-level performance algorithmic performance outside module boundary inside module boundary composition of subsystems copy code or call libraries • Issues for architecture and programs differ • Architecture Programs

  10. Promised Benefits of Architectural Modeling • Clarify design intentions • Intended architecture is often lost. It's mostly informal, it's hard to communicate anyhow. • Provide basis for analysis in design • Engineering design entails performance prediction and design tuning. Routine practice. • Improve maintenance • Over half of maintenance effort goes into figuring out just what's there. • Address the hard questions • Even without formal methods, explicit architectural modelling can uncover fuzzy requirements, thinking, and design approaches

  11. (6%) review document update document (6%) define/analyze change (18%) Requirements Architecture trace logic (23%) implement change (19%) Design Code/Integ Test/Accept Maintenance Promised Benefits of Architectural Modeling • Clarify intentions • Make decisions and implications explicit • Permit system-level analysis test & debug (28%) Reduce maintenance costs, directly and indirectly

  12. Prospectus Planning and Architecture Phase Requirements Discovery Review Architecture High-Level Design Source: Joe Maranzano ATT Bell Labs Low-Level Design Architecture Review Architectural Design Reviews

  13. Elements of Architectural Descriptions • A system architecture identifies • Components: define the locus of computation • Examples: filters, databases, objects, clients/servers • Connectors: mediate component interactions • Examples: procedure call, pipes, event broadcast • Properties: specify info for construction & analysis • Examples: signatures, pre/post conds, RT specs • An architectural style defines a family of architectures constrained by • Component/connector vocabulary • Topology rules • Semantic constraints

  14. Example: Key Word In Context Problem Description: "The KWIC index system accepts an ordered set of lines, each line is an ordered set of words, and each word is an ordered set of characters. Any line may be ‘circularly shifted’ by repeatedly removing the first word and appending it at the end of the line. The KWIC index system outputs a listing of all circular shifts of all lines in alphabetical order." On the Criteria for Decomposing Systems into Modules. David Parnas. CACM, 1972

  15. KWIC: Key Word In Context • Inputs: Sequence of lines Pipes and Filters Architectures for Software Systems • Outputs: Sequence of lines, circularly shifted and alphabetized and Filters Pipes Architectures for Software Systems Filters Pipes and for Software Systems Architectures Pipes and Filters Software Systems Architectures for Systems Architectures for Software

  16. Direct Memory Access Master Control Subprogram Call System I/O Input Circular Shift Output Alphabetizer Alphabetized Characters Index Index Output Input Medium Medium KWIC: Shared Memory Solution Advantage: Good performance

  17. Subprogram Call Master Control System I/O Input Output Alphabetic Characters Circular Shift Shifts Input Output Medium Medium KWIC: ADT Solution Advantage: Information hiding simplifies implementation changes.

  18. Implicit Invocation Master Control Subprogram Call System I/O Circular Input Output Alphabetizer Shift Output Input Medium Medium Lines Lines KWIC: Event Solution Advantage: Tool separation supports function enhancements.

  19. Input Circular Input Medium Shift Pipe System I/O Output Output Alphabetizer Medium KWIC: Dataflow Solution Advantage: Tool separation eases functional enhancements.

  20. Design Considerations • Change in Algorithm • Eg., batch vs incremental • Change in Data Representation • Eg., line storage, explicit vs implicit shifts • Change in Function • Eg., eliminate lines starting with trivial words • Performance • Eg., space and time • Reuse • Eg., Sorting

  21. KWIC Comparisons Change in Algorithm Change in Data Repn Change in Function Performance Reuse Shared Memory ADT Events Dataflow _ _ + + _ _ + _ + + + _ + _ _ + _ + _ +

  22. Outline • Introduction to Software Architecture • Architectural Modeling • Architectural structure and topology • Properties and protocols • Architectural Analysis • Architectural Style • Overview of ADLs and Design Tools • Conclusions, opportunities & challenges

  23. system connector component port role Architectural Vocabulary (Structure)

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

  25. DesignVocabulary System Description TopologyDescription System Description Example (Acme) Component Type ClientT = { Port sendReq; … }; Component Type ServerT = { Port receiveReq; … }; Connector Type RPCT = { Roles {caller; callee}; … }; SystemSimpleClientServer = { Componentviewer : ClientT;Component database : ServerT;Connector conn : RPCT; Attachments = { viewer.sendReq to conn.caller; viewer.receiveReq to conn.callee; }; }; viewer database

  26. Architectural Structure:Hierarchical Descriptions • Representations • describe subsystems • may be architectural or external • Abstraction mappings • relate the inside and outside of architectural representations • bindings are special case

  27. Configuration Component Representations ... if(x>0) { write(out); x--; } ... ... ... ... Source code Formal specification Configuration (sub-architecture) Representations • Provide a description of a complete “view” of the design element • May be external [e.g. file, URL] or sub-architecture

  28. map representation Abstraction Maps

  29. Beyond Simple Structure • What else can we represent? • 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 ...

  30. Capturing Local Properties (with Acme) Component Type ServerT= { Port receiveReq : ODBCPortT = { Property supportsODBCLevel : int = 2; Property supportsConcurrentTrans : boolean = true; }; Property maxConcurrentTrans : int = 20; Property averageTransProcessingLatency : float; Property ODBCComplianceLevel : int; }; Connector Type RPCT= { Roles {caller; callee}; Property synchronous : boolean = true; };

  31. Capturing System Properties (with Acme) SystemSimpleClientServer = { Components{ viewer1 : ClientT; viewer2 : ClientT; } Component database : ServerT; Connector conn : RPCT; Attachments = { … }; Property viewerRequestDistribution = interleaved << origination = asserted; >>; Property transactionProcessingCapacity : float = 34.5 << units = transactions-per-second;origination = computed; >>; Property maxConcurrentViewers : int = 5 << origination = computed; >>; };

  32. Specifying Behavior (Protocols) • Events: request, newValue?y • Processes: P, WorldModel, Client, § • Sequence: e  P, P;Q • Choice: P Q, P [] Q • Quantification: [] x: S  P(x) Notation (based on CSP):

  33. Component types Connector types Instances Attachments WRIGHT Configuration • ConfigurationSimpleSimulation • ComponentWorldModel(map: Function) • PortProvide <provide protocol> • Computation<provide world model> • ComponentVehicleModel • PortEnvironment <value protocol> • Computation<Vehicle behavior> • ConnectorUpdateValues(n : 1.. ) • RoleModel1..n<1 model’s protocol> • Glue<data from one model to another> • Instances • Envt : WorldModel(<map>) • V : VehicleModel • Cn : UpdateValues(2) • Attachments • Envt.ProvideasCn.Model1 • V.EnvironmentasCn.Model2 Envt V Cn

  34. Example: What is “UpdateValues Connector”? • ConnectorUpdateValues(n : 1.. ) • RoleModel1..n = • Glue= <a model’s protocol> <data travels from one model to another>

  35. Example: What is “UpdateValues Connector”? • ConnectorUpdateValues(n : 1.. ) • RoleModel1..n = • Glue= (open requestnewVal?y update!x close

  36. Example: What is “UpdateValues Connector”? • ConnectorUpdateValues(n : 1.. ) • RoleModel1..n = • Glue= (open requestnewVal?y update!x close  Operate)

  37. Example: What is “UpdateValues Connector”? • ConnectorUpdateValues(n : 1.. ) • RoleModel1..n = • Glue= (open requestnewVal?y update!x close whereOperate =  Operate  Operate   Operate)

  38. Example: What is “UpdateValues Connector”? • ConnectorUpdateValues(n : 1.. ) • RoleModel1..n = • Glue= (open requestnewVal?y update!x close  Operate) whereOperate =  Operate  Operate 

  39. Example: What is “UpdateValues Connector”? • ConnectorUpdateValues(n : 1.. ) • RoleModel1..n = • Glue= (open requestnewVal?y update!x close whereOperate =  Operate  Operate   Operate)  § §

  40. Example: What is “UpdateValues Connector”? • ConnectorUpdateValues(n : 1.. ) • RoleModel1..n = • Glue= (open requestnewVal?y update!x close whereOperate =  Operate  Operate   Operate)  § § • StatevwhereStatev = • []i:1..n Modeli.open  Statev • [] []i:1..n Modeli.request Modeli.newVal!v Statev • [] []i:1..n Modeli.update?x  Statex • [] []i:1..n Modeli.close  Statev • [] §

  41. Example: What is “UpdateValues Connector”? • ConnectorUpdateValues(n : 1.. ) • RoleModel1..n = • Glue= (open requestnewVal?y update!x close whereOperate =  Operate  Operate   Operate)  § § • StatevwhereStatev = • []i:1..n Modeli.open  Statev • [] []i:1..n Modeli.request Modeli.newVal!v Statev • [] []i:1..n Modeli.update?x  Statex • [] []i:1..n Modeli.close  Statev • [] §

  42. Outline • Introduction to Software Architecture • Architectural Modeling • Architectural structure and topology • Properties and protocols • Architectural Analysis • Architectural Style • Overview of ADLs and Design Tools • Conclusions, opportunities & challenges

  43. Kinds of Analyses • Consistency • Do the parts fit together? • Completeness • Are parts missing? • Refinement • Can one architecture be substituted for another? • Verification • Does an implementation conform to the architecture? • System-wide behavior, performance, reliability, etc. • What is the aggregate behavior of a system, given the behaviors of the parts? • Evaluating design choices and trade-offs

  44. Analysis Strategies • Use existing specification languages & calculi • Examples: CSP, UML, Queuing Theory, Napkin/Envelope (back of) • Advantages: well understood, tools, reuse • Disadvantages: may not be expressive; may require a lot of initial “context building” before you can do anything useful • Develop new architectural specification languages & reasoning techniques • Examples: Rapide, Wright, Meta-H • Advantages: good match to the problem • Disadvantages: learning curve, proliferation of languages, analysis techniques, tools, mismatch of problem and technique

  45. ? Analysis: consistency & completeness • Consistency: do the parts fit together? • analog of type checking • depends on what you say about the parts • behavior example: does the behavior of a component conform to the protocols of a connector to which it is attached? • Completeness: are any parts missing? • connector roles? • unattached ports? • missing functionality?

  46. Consistency Check 1: Faulty Client • Trivial Client-Server system (1 client, 1 server) • Client should initialize before requesting, but it doesn’t do so. • Disaster detected and averted early ... • ConnectorFaulty • RoleClient = (requestresultClient)  § • Role Server = initializeOperate... • Glue= Client.initializeServer.initializeGlue • [] Client.requestServer.requestGlue • ...

  47. Consistency Check 2: Paused on Join HandlePauseS =  i: S [] Fedi.requestPause  ( i: S ; Fedi.schedulePause §) ; HandlePauseS Role JoinFed = joinFedExecution FedRunning FedRunning = requestPause FedRunning  schedulePause pauseAchieved FedPaused FedPaused = requestResume FedPaused  scheduleResume resumeAchieved FedRunning ___________ Glue

  48. Paused on Join Federate Federate (1) joinFedExecution (2) requestPause (3) schedulePause (4) pauseAchieved (5) joinFedExecution (6) requestPause RTI

  49. Oops! Federate Federate (1) joinFedExecution (2) requestPause (3) schedulePause (4) pauseAchieved (7) schedulePause (5) joinFedExecution (6) requestPause RTI

  50. Consistency Check 3Save Boundary Condition Federate1 Federate2 RTI internal } updateAttrValue (receive update) (commit to send) reflectAttrValue Save will be inconsistent RTI

More Related