Designing for Non-Functional Properties

1. Designing for Non-Functional Properties Chapter 12

2. What We’ve Learned So Far • Software Systems • Designing systems to satisfy all functional requirements is difficult. • Software Architectures help alleviate this task • Designing only for functional properties is essential, but insufficient • Must also design for Non-Functional Properties

3. Non-Functional Properties • Non-Functional Property (NFPs): A constraint on the manner in which the system implements and delivers its functionality

4. Functional vs. Non-Functional Properties • Functional Properties: what the system is supposed to do (‘the system shall do A, B, and C’). • Non-Functional Properties: what the system is supposed to be (‘the system shall be X, Y, and Z’). • Examples: • Efficiency • Complexity • Scalability • Adaptability • Dependability

5. Efficiency • Efficiency: A quality that reflects a software system’s ability to meet its performance requirements while minimizing its usage of resources. • Efficiency is also known as the measure of a system’s resource usage “economy”

6. Software Components and Efficiency • Keep Components Small • Should serve a single need/purpose for the system • Avoid using components where most of the services will not be used • Keep Component Interfaces Simple and Compact • Only expose components that were intended to be visible • Never expose internal states, unless an operation is intended to modify that state

7. Software Components and Efficiency • Allow Multiple Interfaces to the Same Functionality • Problem: • Components may need to provide services to multiple client components executed on different platforms that are implemented in different coding languages • Solutions: • 1. Implement multiple components that replicate each other’s functionality • 2. Wrap the component using an adapter connector • 3. Construct the component such that it natively exports multiple interfaces

8. Software Components and Efficiency Figure 12.1

9. Software Components and Efficiency • Separate Processing Components from Data • Allows internal representation to be fine-tuned or altered • Optimizes processing algorithms without affecting data representation • Separate Data from Meta-Data • Reduces the system run-time memory footprint

10. Software Connectors and Efficiency • Carefully Select Connectors • Software Connectors are first-class entities in a Software Architecture • Should encapsulate all interaction facilities in a system, especially in large, complex distributed systems • As such, connector selection is critical • Use Broadcast Connectors with Caution • Connectors capable of broadcasting data offer a wide range of Flexibility • May come at the expense of other NFPs, such as Security and Efficiency

11. Software Connectors and Efficiency • Make Use of Asynchronous Interaction Whenever Possible • May be difficult for some components to synchronize their processing to take place at an ideal time • Allows components to process interactions without dragging down system performance • Use Location Transparency Judiciously • Components should interact as if they are all located on one host

12. Architectural Configurations and Efficiency • Keep Frequently Interacting Components Close • Multiple indirections between components will hamper efficiency • Architectural Styles with many points of component indirection will work poorly • Carefully Select and Place Connectors in the Architecture • Large systems will likely comprise components with heterogeneous interaction requirements • Difficult to optimize larger, general purpose connectors

13. Architectural Configurations and Efficiency Figure 12.3

14. Architectural Configurations and Efficiency • Consider the Efficiency Impact of Selected Architectural Styles • Some styles are not a good match for certain problems • Examples: • Asynchronous interactions cannot be used effectively against real-time requirements • Large Repository Systems make it difficult to satisfy memory constraints • Batch Sequential Systems will be a poor fit if data must be delivered incrementally

15. Complexity • Complexity: The degree to which a software system or one of its components has a design or implementation that is difficult to understand and verify. (IEEE 1991) • This definition does not explain how complexity may be manifested in a system • System complexity is measured by an individual’s opinion rather than by a standard • Complexity: A software system’s property that is proportional to the size of the system, the number of its constituent elements, the size and internal structure of each element, and the number and nature of the elements’ interdependencies. • Size could be measured in terms of: • Lines of Source Code • Number of Modules • Number of Packages

16. Software Components and Complexity • How should Components be implemented with respect to Complexity? • Conventional software engineering wisdom suggests that each task should be assigned to a unique component • However, a system with more components is likely to become more complex • Conversely, a system with fewer components, but with many different types may also increase overall complexity.

17. Software Components and Complexity • Keep Only the Functionality Inside Components • Coupling data with interaction violates the principle of separation of concerns • May also decrease component reusability • Keep Components Cohesive • Components may in fact need to be complex if the functionality it provides is itself complex

18. Software Components and Complexity • Impact of Off-the-Shelf Components on Complexity • Two ways it may impact a system’s complexity: • 1. As a by-product of their own internal complexity • However, this can be avoided if the component is treated as a ‘black-box’ • 2. By requiring the use of Complex Connectors

19. Software Connectors and Complexity • How should Connectors be Implemented with respect to Complexity? • Treat Connectors Explicitly • Keep Only Interaction Facilities Inside Connectors • Separate Interaction Concerns into Different Connectors • Restrict Interactions Facilitated by Each Connector • Be Aware of the Impact of Off-the-Shelf Connectors on Complexity

20. Architectural Configurations and Complexity • Eliminating Unnecessary Dependencies • Larger software systems are typically more complex • Systems with more interdependencies between modules are often more complex than systems with fewer because: • 1. Greater possible number of interactions • 2. More difficult to predict and control system behavior because of the above • Manage All Dependencies Explicitly • Use Hierarchical Composition and Decomposition • Grouping components with similar components masks the complexity of the system • Produces more readily understandable system architectures, even at an architecture’s highest levels

21. Scalability and Heterogeneity • Scalability – Capability of a system to be adapted to meet new requirements of size and scope • Ability to grow/shrink functionality to meet system requirements • Heterogeneity • Quality of a software system consisting of multiple constituents • Ability to function in multiple environments

22. Scalability and Heterogeneity • Two perspectives of Heterogeneity: • 1. Internal – A system’s ability to accommodate multiple components and connectors • 2. External – A system’s ability to adjust to different platforms, operating systems, and infrastructures

23. Software Components and Scalability • Component design will directly affect a system’s ability to scale. • Six heuristics for achieving Component Scalability: • Give Each Component a Clearly Defined Purpose • Give Each Component a Simple and Understandable Interface • Do Not Burden Components with Interaction Responsibilities • Avoid Unnecessary Heterogeneity • Distribute the Data Sources • Replicate Data When Necessary

24. Software Connectors and Scalability • Adding Connectors may diminish Scalability • Keeping Connectors Scalable: • Use Explicit Connectors • Give Each Connector a Clearly Defined Responsibility • Choose the Simplest Connector Suited for the Task • Be Aware of Differences Between Direct and Indirect Dependencies • Do Not Place Application Functionality Inside Connectors • Leverage Explicit Connectors to Support Data Scalability

25. Architectural Configurations and Scalability • Avoid System Bottlenecks • Replicate Components to service some requests • Referred to as “Load Balancing” • Make Use of Parallel Processing Capabilities • Scalability achieved through distribution, though this may be at the significant expense of efficiency • Place the Data Sources Close to the Data Consumers • Make Distribution Transparent • Use Appropriate Architectural Styles

26. Adaptability • Adaptability – Ability to satisfy requirements and adjust to new operating conditions • Manual • Automated

27. Software Components and Adaptability • Adaptability occurs at the level of the system components, their interfaces, and their composition • Guidelines for Keeping Components Adaptable: • Give Each Component a Clearly Defined Purpose • Minimize Component Interdependencies • Avoid Burdening Components with Interaction Responsibilities • Separate Processing from Data • Separate Data from Meta-Data

28. Software Connectors and Adaptability • Connectors are also key enablers of Adaptability • Guidelines for Keeping Connectors Adaptable: • Give Each Connector a Clearly Defined Responsibility • Make Connectors Flexible • Support Connector Composability • Be Aware of Differences Between Direct and Indirect Dependencies

29. Architectural Configurations and Adaptability • Leverage Explicit Connectors • Since implicit connectors will be difficult to adapt across multiple system elements • Make Distribution Transparent • Makes modifications easier when components are oblivious of a system’s deployment profile • Use Appropriate Architectural Styles

30. Dependability • Composite NFP encompasses several other NFP’s: • Reliability – Probability of successful performance over a period of time • Availability – Probability that the system is operational at a particular time • Robustness – Ability to respond to unanticipated run-time conditions

31. Dependability • Fault-tolerance – Ability to respond to run-time failures • Fault Classifications: • Faults in System Environments (Outside the Architecture) • Faults in Components/Connectors • Component-connector mismatches

32. Dependability • Survivability – Ability to respond to mission-compromising threats • Types of Threats: • 1. Attacks – Deliberate Intrusions on a system • 2. Failures – Usually system deficiencies or defects • 3. Accidents – Random, but potentially damaging • Safety – System avoidance of destruction of property or loss of life

33. Software Components and Dependability • Guidelines for Keeping Components Dependable: • Carefully Control External Component Interdependencies • Provide Reflection Capabilities • Provide Exception Handling Mechanisms • Specify Component Key State Invariants

34. Software Connectors and Dependability • Guidelines for Keeping Connectors Dependable: • Employ Connectors that Strictly Control Component Dependencies • Provide Appropriate Component Interaction Guarantees • Support Dependability Techniques via Advanced Connectors

35. Architectural Configurations and Dependability • Avoid Single Points of Failure • Provide Back-Ups for Critical Functionality • Support Non-Intrusive System Health Monitoring • Support Dynamic Adaption

36. Conclusion • Good engineers will usually manage to produce almost any functional requirement – no matter how difficult or complex • What they struggle with are the Non-Functional aspects of the system • Though difficult, achieving desired Non-Functional Properties often marks the difference between a successful product and a failure