Designing Non-Functional Properties
• Def 1: (author’s) A non-functional property of a software
system is a constraint on the manner in which the
system implements and delivers the functionality
• Def2: (mine) A non-functional property of a system is a
constraint placed on the system’s behavior and/or
construct.
• Non-functional properties are usually
–
–
–
–
–
difficult to define
possibly multi-dimensional (has sub-characteristics)
do not have “universally accepted” definition
difficult to measure (designing meaningful metric is “hard”)
Sometimes, optimizing one may cause a conflict with others
(prioritization is important)
Try defining complexity , reliability or usability
Some “common” Non-Functional Properties
•
•

•
•


•
•


Reliability
Security
Efficiency
Availability
Maintainability
Complexity
Scalability
 ---- we will cover these in
Usability
this lesson
Reusability
Adaptability
Dependability (this is a composite property)
How would we “design” for these properties when they are “not-well” defined?
Is there some guideline?
Efficiency (definition)
• Efficiency is a characteristic that reflects a software
system’s ability to meet its “performance requirements”
(throughput, response time, etc.) while minimizing its
usage of the resources in its computing environment. (It
is a measure of the system’s resource usage economy.)
– Assuming that the system functions correctly
• We will explore the characteristic in terms of 3 aspects:
– components
– connectors
– configuration
Efficiency (design guidance)
• Component Guidance:
– Keep component size small to serve single purpose and single need
(resembles the notion of “cohesion” property) ; this will eliminate some
“extra” resources that may not be needed. (always true?)
– Keep component interface simple and compact; having complex and broad
interface may drag in extra resources such as adaptors and wrappers
• This guideline needs to be applied cautiously so that other properties such as scalability
or reusability are not impacted
• This guideline may also be viewed in terms of “coupling”- (content, common, etc.)
– Allow multiple interfaces to the same functional component (see figure on
page 453 of your text)
– Separate processing component from data, allowing more efficient design
of processing algorithm and more efficient data design (BUT --- is this
counter to OO design?!)
– Separate data from meta data (e.g. data format), making the movement of
data more efficient
•
this consideration is especially relevant for distributed systems where the meta data
may be sent once and the actual data may be repeatedly sent without the meta data; the
representation (rendering) of data may be done at the receiving end
Efficiency (design guideline)
• Connector Guidance:
– Careful selection of connectors - ensuring that there is no “extra”
functionalities embedded --- selecting simple and specific ones for
connecting just 2 components while more complex ones (with
redundancy) may be needed for real-time and life threatening case
– Use broadcast connectors with caution – not always needed even
though it is easier to connect; use alternate connectors such as publishsubscribe mechanism to connect to just the subscribers.
– Use asynchronous interaction whenever possible – synchronous
processing ties up all the resources and many are in “wait” state; note
that some asynchronous processing is such that resources are just put
into “suspense state” and not really freed up.
– Use location transparency judiciously – connectors that provide
location transparency may be a performance “hog”; sometimes it is
better to distinguish local from remote connectors, even at the expense
of some complexity.
Efficiency (design guideline)
• Configuration guidance:
– Keep frequently interacting components “close” – use less indirection
if possible; especially beware of the layered style where there may be
multiple layers to go through until the desired layer is reached.
– Place connectors with care – use multiple specialized connectors to
connect components that are close to each other and use broad,
universal connectors only when necessary (because the universal
connectors tend to use unnecessary resources).
– Consider the architecture style and patterns choices – i) asynchronous
interactions such as publish-subscribe may not work for real-time, ii)
large repository and blackboard architecture may be cause a memory
problem, iii) decompose and compose streams of data is costly, iv)
pipe-filter and batch processing styles are not a good fit for data that
needs to be delivered incrementally
Complexity (definition)
• Def 1: (IEEE) Complexity is the degree to which a software
system or one of its component has a design or
implementation that is difficult to understand and verify.
– Whose definition do we use to gauge “difficult to understand?”
• Def 2: (text author) Complexity is a software system’s
property that is proportional to the size of the system, the
number of constituent elements, the size and internal
structure of each element, and the number and nature of the
elements interdependence.
– What is size (loc ?; number of modules?; etc.)
– What is internal structure ? (loop, case, etc.? data structure?)
– What is interdependencies? (calls?, passing parameters?, using db?)
Your thoughts on “Complexity” attribute ? ------
Complexity (design guide)
• Component guidance:
– Separate concerns into different components – abstraction, modularity
and separation of concern is the basis for this; when all other
parameters are equal, the component of smaller size is less complex.
• Different concerns (functionality) should be placed in different components, or
component should be cohesive
• A large number of different types of components causes increase in
interdependence, or coupling
– Keep functionality inside the component, not interaction
• Move the interaction, or coupling, out of component and into the connectors
– Keep component cohesive – single purpose and self contained
• There are many ways to measure this structural property of cohesion; each method
should be cohesive (intra-method cohesion) and so should the whole class 9intermethod cohesion).
– Beware of “off-the-shelf component – these are often made for
universal usage and thus “large” and complex
– Insulate process component from data change – data formats often
change and processing should be shielded from these complexities
Complexity (design guidance)
• Connectors guidance:
– Treat connectors explicitly – application-dependent interaction and data
should be separated from application-independent interactions;
application independent interactions are candidates to be placed into the
connectors
– Keep only application-independent interaction facilities inside the
connectors
– Separate interaction concerns (functionalities) into different connectors –
there may be different connector concerns, in which case separate those
concerns into different connectors (e.g. transmission connector and data
compaction connectors should be separated out as opposed to merged
into one --- cohesion of connector)
– Restrict interactions facilitated by each connector – ensure that
unnecessary components are not brought into the interaction by the
connector
– Beware of off-the-shelf connectors – same concern as off-the-shelf
component
Complexity (design guidance)
• Configuration guidance:
– Eliminate unnecessary dependencies – the less number of
components and connectors the smaller the potential number of
interaction paths, thus less complexity.
– Manage all dependencies explicitly
– Use “hierarchical” decomposition and composition – this approach
gives us a more organized way to “grouping” of components and
connectors and the over-all configuration
Scalability and Heterogeneity (definition)
• Definition: Scalability is the capability of a software system to
be adapted to meet new requirements of size or scope.
– Ability to support larger and more complex systems without
compromising too much complexity and performance
– Note: performance speed is not part of scalability definition here
– We are dealing with scalability of scope, meaning adapting to
heterogeneity and portability (adaptability is defined later!)
• Def 1: Heterogeneity is the characteristics of the system
consisting of disparate constituents or functioning in disparate
computing environment.
• Def 2: Heterogeneity is the ability to i) include multiple
disparate constituents or ii) to function in disparate computing
environment
• Def 3: portability is a special case of Heterogeneity – ability to
execute on multiple platforms with minimal modification and
minimal degradation of system characteristics.
Scalability (design guidance)
• Component guidance:
– Give each component a clearly defined single purpose – this allows
“growth” and future changes a lot easier to handle; this same guideline
(component cohesion) appears repetitively.
– Give each component simple and understandable interface – allows
adding new component to interact with existing ones easier.
– Do not burden components with interaction responsibilities – keep
interaction responsibilities in the connectors so that the above first rule
is met.
– Avoid unnecessary heterogeneity - this complicates and decreases the
possibilities of adding new components that can interact with the
existing ones
– Distribute data source – this allows the scaling up of size and amount
of data where a single centralized data base may not support the
scaled up number of users
– Replicate data when necessary – this also allows the support of
growing number of distributed users
Note that some of these are starting to repeat from earlier property guidance !
Scalability (design guidance)
• Connectors guidance:
– Use explicit connectors - also needed for a lot of properties mentioned
earlier
– Give each connector a clearly defined responsibility
– Choose the simplest connector suited for the task
– Be aware of direct and indirect dependency differences - direct
dependencies between two components and the connector are simpler to
understand and design, but scaling up would mean duplicating the
connectors or possibly a more complex design; indirect dependencies such
as a data base may grow independently of the scaling up of functions ---(remember, however, common coupling is viewed as worse than data
coupling!)
– Do not place application functionality inside the connector
– Leverage “explicit” data connectors to support data scalability –
connectors that deal with buffering, caching, etc. of data are more likely to
allow growth of data or number of users.
Scalability (design guidance)
• Configuration guidance:
– Avoid system bottleneck – look for configuration that has a potential
connector bottleneck or a component bottleneck; scaling up other
parts of the system would make the bottleneck worse.
– Take advantage of parallel capabilities – this would require
independence in computation and independence of data requirements;
design configuration with the independence in mind
– Place data source close to the data consumers – provides performance
advantage for growth
– Make distribution transparent (location transparency) – makes growth a
lot easier, but there is a price to pay for other properties such as
efficiency !?
– Choose architecture style carefully - ensure that the architectural style
such as publish-subscribe is considered for scalability.
Adaptability (definition)
• Adaptability is a software system’s ability to satisfy
new requirements and “adjust” to new operating
conditions during its lifetime
– This definition is very similar to scalability (which was
mostly size and scope), but adaptability (any new
requirements and new operating environment) is more
general than scalability
Adaptability (design guidance)
• Component (guidance) --- similar to scalability & the tone is
to keep component complexity down, cohesion high, and
coupling low
–
–
–
–
–
Give each component a single clearly defined purpose
Minimize component interdependence
Avoid burdening component with interaction responsibilities
Separate processing from data
Separate data from meta-data
Adaptability (design guidance)
• Connector guidance – connectors are extremely important to
this characteristic of adaptability since connectors are really
“adaptors”
– Give each connector a clearly defined responsibility
– Make connectors flexible – note that this may conflict with other
properties
– Support connector composability – this may introduce complexity
and other constraints, but clearly gives “extensibility” to the design
– Be aware of difference in direct and indirect dependencies
Adaptability (design guidance)
• Configuration guidance:
– Leverage explicit connectors
– Make distribution transparent (location transparency) – same
comment as for scalability ----- it may conflict with efficiency
– Be aware of the different architecture styles
Dependability (definition)
• (Author) Dependability is a really a composite nonfunctional property, made up of several sub-properties:
–
–
–
–
–
–
–
reliability,
availability,
robustness,
fault-tolerant,
survivability,
safety and
security. (addressed separately in Chapter 13)
(I believe that each of these sub-properties, not just security,
should be considered separately.)
Dependability Sub-Property Definitions
• Reliability is the probability that the system will perform according to
requirements, under specific design limits, without failure for a specified
period of time.
• Availability is the probability that the system is operational at any particular
instance of time
• Robustness is the ability to respond adequately to unanticipated run time
conditions.
– What is considered “adequate” ?
– How is this different from Scalability? (anticipated vs unanticipated)
• Fault-tolerance is the ability to respond gracefully to run-time failure
– What is considered “gracefully”? (treat all failure severities the same?)
– Failures may occur : in system environment; in components; in connectors;
connector-component.
• Survivability is the ability to recognize, resist, recover from , and adapt to
mission-compromising threats. Note threats may be from i) attacks, ii)
failures, or iii) accidents
• Safety is the ability to avoid failures that will result in severe damages such
as loss of life, injury, loss of property, or destruction of property.
Note that many of these are abilities --- does that translate to functionalities?
Dependability (design guidance)
• Component guidance: (Note that we can seldom develop
100% reliable and fault-tolerant component.) But ---– Carefully control external component interdependencies among
components; making the component interfaces explicit and minimal
(loose coupling among components)
– Provide reflection capabilities (functionalities) in components:
include functionalities that will allow others to query the component
states: note that this may conflict with earlier attributes such as
efficiency
– Provide suitable exception handling mechanism
– Specify the component’s “key” state invariants in the component
design
Dependability (design guidance)
• Connector guidance
– Employ connectors that strictly control component dependencies
• Insulate components from each other
– Provide appropriate component interaction guarantees
• Ensure that the component data is transmitted
• Ensure that the component interactions are guaranteed for i) at least
once, ii) at most once, iii) exactly once
– Support dependability techniques via advanced connectors
• Some advanced connectors can allocate “replacement” component
when one fails
• Some may cache the data and still deliver partial inforamtion when the
data source component fails
Dependability (design guidance)
• Configuration guidance
– Avoid single point of failure
• Do not have one component/connector which many others dependent
on; this also cause potential bottleneck in performance. (minimize the
fan-ins to any one or a small set of components)
– Provide back-ups of critical functionality and/or data
• This obviously depends on other properties such as efficiency, complexity,
etc.
• This is clearly asking for more functionality
– Support non-intrusive system health monitoring
• Embed system monitoring functionalities in components or connectors
– Support Dynamic Adaptation
• This is not easy to do ---- lots of extra functionalities with uncertain
results