Software Architecture
Prof.Dr.ir. F. Gielen
Quality Attributes & Tactics (4)
Modifiability
Vakgroep Informatietechnologie – IBCN
Modifiability
Modifiability is about the cost of changes.
What



Functions, Platform, Environment.
Data, data representation
System Qualities (performance, throughput,…)
When



is the change required ?
Development time, build time, ..runtime
Who

can change ?
will implement the change ?
Software engineers ?
Users ?
Administrators ?
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 2
Modifiability Scenario
“A
developer wants to change the UI
code at design time; the modification is
made without side effects in 3 hours.”
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 3
Modifiability Tactics
Change
Request
Tactics
to Control
Modifiability
Arrives
Changes made,
Tested and Deployed
on Time, within Budget
Localize Modifications

Assign responsibilities to modules such that changes are
limited in scope.
Prevent Ripple Effect

A ripple effect from a modification is the necessity of making
changes to modules not directly affected by it
Defer Binding Time

Commit as late as possible
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 4
Localize Modifications (1/2)

General rule :


Goal:


The fewer components to change  less cost to change
Assign functionality to modules so that anticipated
changes will be limited in scope
Maintain semantic coherence:

Responsibilities work together without excessive reliance
on other modules


Abstract common services : e.g. timer services,
security, encryption, …etc.
Anticipate expected changes:


Considering the set of envisioned changes, provides a
guide to the assignment of responsibilities
Do fundamentally different changes affect the same
module ?
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 5
Localize Modifications (2/2)

Generalize the module



Making the module more general allows it to function for
broader range of inputs
Think of the input as a language for the module
Limit possible options


Modifications may have long reaching effects (especially
within product lines)
Reducing choices can reduce the impact

E.g., changing the OS has substantial ramifications
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 6
Ripple Effects : Module dependencies
Syntax :

Data: For B to compile/execute correctly the type of the
data produced by A and used by B must be consistent with
B’s assumptions

Service: For B to compile/execute correctly the signature
of services provided by A and invoked by B must be
consistent with B’s assumptions
Semantics :

Data: For B to execute correctly the meaning of the data
produced by A and consumed by B must be consistent
with B’s assumptions

Service: For B to execute correctly the semantics of
services provided by A and used by B must be consistent
with B’s assumptions
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 7
Prevent Ripple Effects (2/3)
Sequence:

Data: For B to execute correctly it must receive data produced
by A in a fixed sequence. E.g., protocol headers before body

Control: For B to execute correctly A must have executed
within certain (time) constraints
Identity of an interface of A:

A may have multiple interfaces each of which has a definition
that must remain consistent with B’s assumptions
Location of A at runtime:

If A is allowed to migrate B must know where it is.
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 8
Prevent Ripple Effects (3/3)
Quality

of service/ data provided by A
Data accuracy
Existence

of A:
Routeplanner – existence of GPS module ?

Startup scenario !
Resource behavior of A

e.g., A uses the same memory as B
Modifiability Tactics cannot avoid ripple effect but
limit the effect of changes.
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 9
Modifiability Tactics

Hide information



The oldest of our tactics
Uses anticipated changes as basis for decomposition
Maintain existing interfaces

Patterns for implementing this tactic




Adding interfaces
Adding an adapter
Providing a stub (just in case …)
Restrict communication paths
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 10
Use intermediaries (1/2)

Examples of Intermediaries

Data(syntax):



data repositories (DB and blackboards) act as
intermediary between producer and consumer of data
Publish/subscribe services
Service (syntax)

Patterns: façade, bridge, mediator, proxy,
factory all provide intermediaries to convert from one
syntax of a service to another
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 11
Use intermediaries (2/2)

More intermediaries ...

Identity of interface of A:


Location of A (runtime)


register with name-server
Resource behavior of A or resource controlled by A


A broker can be used to find the interface to perform a
service,
Resource manager is intermediary
Existence of A:

the factory pattern can construct instances if needed
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 12
Defer Binding Time
Modifiability


Time to deploy
Allowing non-developers to make changes
What


scenarios include:
is binding time?
Static vs dynamic: e.g. name binding in C++ & Java
build time, installation, configuration or runtime.
Deferring
Binding Time supports both of
these scenarios
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 13
Defer Binding Time Tactics





Runtime registration supports plug-and-play at
expense of registration overhead
Configuration files allow set-up parameters to
be initialized
Polymorphism – late binding of method calls
Component replacement allows load time
binding
Protocol adherence allows runtime binding of
independent processes
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 14
Modifiability Tactics: summary
Modifiability
Change
Request
Arrives
Localize
Changes Prevent Ripple
Effect
•Semantic
Coherence
•Anticipate
changes
•Generalize
Modules
•Limit
Options
•Abstract
Common
Services
•Hide
Information
•Maintain
existing
interfaces
•Restrict
communication
paths
Defer
Binding Time
•Runtime
Registration
•Polymorphism
Changes made,
Tested and Deployed
on Time,
•Component
Replacement
within Budget
•Configuration
files
• Adherence to
protocols
•Use an
intermediary
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 15