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