1. Achieving Critical System Qualities Through Software Architecture Dr. Stuart Faulk Computer and Information Science University of Oregon

2. Overview What is “software architecture” (and what isn’t)? The Role of Architecture –System and organizational properties are influenced by architectural choices –Sources of architectural requirements The Role of Software Engineering in Disciplined Development –A disciplined process –Using architectural structures to achieve design goals

3. Working Definition “The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them.” From Software Architecture in Practice, Bass, Clements, Kazman

4. Examples An architecture comprises a set of –Software components –Component interfaces –Relationships among them Examples StructureComponentsInterfacesRelationships Calls StructureProgramsProgram interface and parameter declarations. Invokes with parameters (A calls B) Data FlowFunctional tasksData types or structuresSends-data-to ProcessSequential program (process, thread, task) Scheduling and synchronization constraints Runs-concurrently-with, excludes, precedes

5. Implications of the Definition “The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them.” - Bass, Clements, Kazman Systems typically comprise more than one architecture –There is more than one useful decomposition into components and relationships –Each addresses different system properties or design goals It exists whether any thought goes into it or not! –Decisions are necessarily made if only implicitly –Issue is who makes them and when Many “architectural specifications” aren’t

6. Is it Architecture? Control Process (CP) Noise Model (MODN) Reverb Model (MODR) Prop Loss Model (MODP) Typical (but uninformative) architectural diagram What is the nature of the components? What is the significance of the link? What is the significance of the layout?

7.  # = O/C-M = Observability/Controllability Mechanisms Physical Resources Functions QoS Request Translator Multi Domain QoS Monitor & Visualization Net Resource Resource Allocation Management QoS Event/Perf Historical Analysis & Profiling QoS Steady State Data Collection Dyn Val Stress/Error/Threat Exerciser Dyn Val Data Collection Dyn Val Controller QoS Prediction QoS Request Manager Dyn Val Analysis Selected Domain Resource Management Support Functions Application QoS Requests ADVANCED VALIDATION Multi Domain Resource Management Controllability/ Observability Manager  # App  # Adap  # Middleware/Obj Mgmt  # OS  # Network Computing Resource Is it architecture?

8. The Role of Architecture What system or development characteristics are determined by the architecture? What system or development characteristics are determined by the architecture? What is the source of requirements? What is the source of requirements?

9. Fit in the Development Cycle Software Design System Integration and Testing Coding Deployment Maintenance and Evolution Requirements Analysis Software Architecture “…The earliest artifact that enables the priorities among competing concerns to be analyzed, and it is the artifact that manifests the concerns as system qualities.”

10. Effects of Architectural Decisions (What?) What kinds of system and development properties are affected by the architectures? System run-time properties? System static properties? Production properties? (effects on project) Business/Organizational properties?

11. Effects of Architectural Decisions (Who?) Who has a stake in what choices are made between architectural properties? Why is it important for architects to understand what is wanted, who wants it, and how important each issue is?

12. Importance of Stakeholders There are many interested parties (stakeholders) with many diverse and often conflicting interests Important because their interests tend to defy mutual satisfaction –There are inherently tradeoffs in most architectural choices –E.g. Performance vs. security, initial cost vs. maintainability Making successful tradeoffs requires understanding the nature, source and priority of these constraints.

13. Architectural Feedback Architecture influences the things that influence it Architecture influences organization –Influences organizational structure by work breakdown –Changing architectures requires reorganization Architecture influences future architectures –People understand what they have experience with –Organizational inertia Architecture influences business decisions –Facilitates some changes, discourages others –May influence customer requirements since it affects the cost and speed of subsequent development

14. Architecture Business Cycle Requirements Organizational GoalsArchitecture System Viewed in the business context, cycle, not waterfall Implies need to think about long term implications of architectural design decisions

15. Summary Earliest set of design decisions – hence, most influential and hardest to change Determines a wide range of critical system, production, and business properties A product of tradeoffs between conflicting demands by different stakeholders Requirements come from product/business goals and subsequently affect them Implication: good design is a balance of technical, business and social influences –Must understand the context –Must communicate effectively –Must negotiate the requirements –Must think strategically about the effects of decisions

16. Architectural Qualities

17. Terminology Avoid “functional” and non-functional" classification Behavioral Requirements - Any and all information necessary to determine if the run-time behavior of a given implementation constitutes an acceptable system. –All quantitative constraints on the system's run-time behavior –Other objective measures (safety, performance, fault-tolerance) –In theory all can be validated by observing the running system and measuring the results Developmental Quality Attributes - Any constraints on the system's static construction Developmental Quality Attributes - Any constraints on the system's static construction –Testing ease (testability), ease of change (mutability), maintainability, reusability –Measures of these qualities are necessarily relativistic (I.e., in comparison to something else

18. Behavioral vs. Developmental Behavioral (observable) PerformanceSecurity Availability (fault-tolerance) Security Usability (responsiveness?) Properties resulting from the properties of components, connectors and interfaces that exist at run time. Developmental Qualities ModifiabilityPortabilityReusabilityIntegrabilityTestabilityUnderstandability* Properties resulting from the properties components, connectors and interfaces that exist at design time whether or not they have any distinct run-time manifestation.

19. Behavioral vs. Developmental (2) Behavioral (observable) PerformanceSecurity Availability (fault-tolerance) Usability (responsiveness?) Developmental Qualities ModifiabilityPortabilityReusabilityIntegrabilityTestability Usefully viewed as distinct concerns Visible at different times Can focus on one at a time Often not easy to separate in practice Design time mechanisms often carried into run-time structures Real separation requires careful engineering Many mechanisms bind more than one attribute at a time or abstract from what we want to control. Examples? The “art” of design includes finding structures that: Address multiple concerns concurrently and/or Cleanly separate design from run-time constraints

20. Role of Software Engineering in Disciplined Development

21. SW Engineering of Software Architecture What are we trying to gain/maintain control of in the Architectural Design phase? Profoundly effect system and business qualities Requires making tradeoffs Control implies achieving system qualities by choice not chance –Understanding what the tradeoffs are –Understanding the consequences of each choice –Making appropriate choices at appropriate times

22. Implications for the Development Process Implies need for disciplined process for SW architecture covering these tasks Creating the “business case” for the system Understanding the requirements Designing the architecture Representing and communicating the architecture Analyzing or evaluating the architecture Implementing the system based on the architecture Ensuring the implementation conforms to the architecture

23. Related Design Questions Related Design Questions Create business case for the system –What is the “business” rationale or goal? Understanding the requirements –What is the design goal? Creating or selecting the architecture –What are appropriate components and relations? –What are the decomposition principles? Representing and communicating the architecture –How are the components and relations represented? Analyzing or evaluating the architecture –How do we decide if the architecture is any good?

24. Architectural Design What does “design an architecture” imply? 1.That we design to a (well-defined) purpose System qualities from requirements Strategic goals from business context 2.That we must choose appropriate components and relations for the required qualities 3.That we need appropriate representations to make the design decisions visible (support manipulation and communication) 4.That we need a decomposition method (design approach) Methods describing what to do and when Principles to guide making appropriate choices 5.That we need some metric of “goodness” relative to purpose

25. Architectural Structures To describe an architecture, we must answer: –What are the components? Relations? Interfaces? –To design one, must also know what it is good for - i.e., what quality attributes are determined by that structure. E.g., Calls Structure –Components: procedures –Relation: calls or invokes –Interface: procedure interface (parameters) and visible effects –Determines: execution flow (e.g., bottlenecks) Commonalties –Each portrays some aspects of the system, abstracts from others –The purpose is to support design of some attribute (or related set) of the system that is important to some stakeholder –Exactly what is visible and what is abstracted away depends on which attributes must be engineered

26. An Example: The FWS Module Structure

27. Floating Weather Stations (FWS) Floating weather stations are seagoing buoys that are equipped with sensors to monitor wind speed. Each FWS has an on-board computer that maintains a history of recent wind speed data. At regular intervals the buoy transmits the wind speed using a radio transmitter. We will be developing the software for a new class of low-cost floating weather stations. These stations are designed to be dropped from aircraft to drift with the currents. It is anticipated that we will produce floating weather stations in a variety of configurations to meet different customer needs. In particular, we will produce versions with a small number of sensors that are low cost but low accuracy. We will also develop higher cost versions with more sensors and/or more accurate sensors that produce more accurate results. Expected changes B ehavior V 1. The formula used for computing wind speed from the sensor readings may vary. In particular, the weights used for the high resolution and low resolution sensors may vary, and the number of readings of each sensor used (the history of the sensor) may vary. V2. The format of the messages that an FWS sends may vary. V3. The transmission period of messages from the FWS may vary. V4. The rate at which sensors are scanned may vary. Devices V4. The number and types of wind speed sensors on a FWS may vary. V5. The resolution of the wind speed sensors may vary. V6. The wind speed sensor hardware on a FWS may vary. V7. The transmitter hardware on a FR'S may vary. V8. The method used by sensors to indicate their reliability may vary.

28. Elements of Architectural Design Business rationale –What properties must the system have and why? Design goals –What are we trying to accomplish in the decomposition? Structure –What are the components, relations, interfaces? Method of communication –How are the choices of components, relations and interfaces communicated to the stakeholders? Decomposition principles –What decomposition principles support the objectives? –What do I do next? –Am I done yet? Evaluation criteria –How do I tell a good design from a bad one?

29. Summary Mapping Business Rationale What properties must the system have? 1.Support rapid, low cost development of new versions. 2.Support easy customization Design Goals What are we trying to accomplish in the decomposition? 1.Should be easy to understand what parts of the system need to change 2.Changes should be localized Structure What are the components, relations, interfaces? 1.Modules (objects) 2.Submodule-of 3.Services, assumptions, secrets of each module Method of Communication How are the choices of components, relations and interfaces communicated to the stakeholders? 1.Module Guide Document 2.Module Interface Specifications Decomposition Principle What decomposition principles support the objectives? 1.Information hiding 2.Abstraction Evaluation Criteria How do I tell a good design from a bad one? Evaluate against expected changes for: 1.Completeness 2.Ease of change

30. Module Structure Design Goals Divide software into set of work assignments with the following properties: –Easy to Understand: Each module’s structure should be simple enough that it can be understood fully. –Easy to Change (mutability): It should be possible to change the implementation of one module without knowledge of the implementation or affecting the behavior of other modules. –Proportion: Effort of making a change should be in (reasonably) direct proportion to the likelihood of that change being necessary. –Independence: It should be possible to make a major change as a set of independent changes to individual modules (except for interface changes)

31. Modular Structure Components –Called modules –Leaf modules are work assignments –Non-leaf modules are the union of their submodules Relations (connectors) –submodule-of => implements-secrets-of –The union of all submodules of a non-terminal module must implement all of the parent module’s secrets –Constrained to be acyclic tree (hierarchy) Interfaces (externally visible component behavior) –Defined in terms of access procedures (services or method) –Only access to internal state

32. Method of Communication Module Guide –Documents the module structure: The set of modules The responsibility of each module in terms of the module’s secret The “submodule-of relationship” The rationale for design decisions –Document purpose(s) Guide for finding the module responsible for some aspect of the system behavior –Where to find or put information –Determine where changes must occur Baseline design document Provides a record of design decisions (rationale)

33. Method of Communication Module Interface Specifications –Documents all assumptions user’s can make about the module’s externally visible behavior (of leaf modules) Access programs, events, types, undesired events Design issues, assumptions –Document purpose(s) Provide all the information needed to write a module’s programs or use the programs on a module’s interface (programmer’s guide, user’s guide) Specify required behavior by fully specifying behavior of the module’s access programs Define any constraints Define any assumptions Record design decisions

34. Decomposition Criteria Principle: information hiding –System details that are likely to change independently should be encapsulated in different modules. –The interface of a module reveals only those aspects considered unlikely to change. What do I do next? –For each module, determine if its secret contains information that is likely to change independently Stopping criteria –Each module is simple enough to be understood fully –Each module is small enough that it makes sense to throw it away rather than re-do.

35. FWS Modular Structure FWS Behavior Hiding Device Interface Software Decision Sensor Driver Transmitter Driver Controller Message Generation Message Format Sensor Monitor Data Banker Averager Submodule-of Encapsulates all changes to the message format Encapsulates all changes if transmitter protocol changes Module

36. Evaluation Criteria –Completeness Is every aspect of the system the responsibility of one module? Do the submodules of each module partition its secrets? –Ease change Is each likely change hidden by some module? Are only aspects of the system that are very unlikely to change embedded in the module structure? For each leaf module, are the module’s secrets revealed by it’s access programs? –Usability For any given change, can the appropriate module be found using the module guide? …etc.

37. Summary The critical problem is separating architectural concerns from other development issues Choosing an appropriate architectural structure depends on the particular system design goals to be addressed Effective deployment of any structure requires appropriate representation, method, principles, and evaluation criteria Understanding which structures to apply and how best to apply them requires both training and experience

38. Additional slides are needed to detail the design principles applied (modularization, information hiding, abstraction) © S. Faulk 2009 38

39. End