designing for non-functional properties
Post on 22-Feb-2016
132 Views
Preview:
DESCRIPTION
TRANSCRIPT
Designing for Non-Functional PropertiesChapter 12
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
Non-Functional Properties
•Non-Functional Property (NFPs): A constraint on the manner in which the system implements and delivers its functionality
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
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”
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
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
Software Components and Efficiency
Figure 12.1
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
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
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
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
Architectural Configurations and Efficiency
Figure 12.3
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
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
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.
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
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
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
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
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
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
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
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
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
Adaptability•Adaptability – Ability to satisfy
requirements and adjust to new operating conditions
▫Manual
▫Automated
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
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
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
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
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
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
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
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
Architectural Configurations and Dependability•Avoid Single Points of Failure•Provide Back-Ups for Critical
Functionality•Support Non-Intrusive System Health
Monitoring•Support Dynamic Adaption
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
top related