17/08/2025

Software Architectures
Introduction to Modifiability

Today
• Definition of Modifiability
• Modifiability Quality Attribute Scenarios
• Analyzing Modifiability
• Modifiability Tactics

© Matthew Bass 2

1
 17/08/2025

Modifiability
• Very few systems are done after the initial release
• It’s common for changes to happen over time
• These changes occur for a variety of reasons:
• Bug fixes
• New capabilities are released
• The software is customized for a given context
• Technology has evolved and the system is changed to accommodate
the evolution
• …
© Matthew Bass 3

Bug Fixes
• After the initial system release bugs are almost always
discovered
• If you look at your iPhone/Android I suspect you’ll have outstanding
updates to apply
• How often do you get “Windows Updates” or do you need to update
“Flash”
• These are mostly patches to fix defects or bugs
• The system needs to be able to accommodate these patches

© Matthew Bass 4

2
 17/08/2025

New Capabilities
• We see this in many different ways
• Released systems often evolve to increase the capabilities
• Sometimes this comes in the form of an “enhancement request”
• Sometimes this could be the next version of the system or software
• Sometimes the software evolves on a continuous basis
• We may also need to be able to accommodate multiple
versions of the product
• As with the cell phone or infotainment example

© Matthew Bass 5

Customized System
• Many systems need customization for multiple
deployments/contexts
• These customizations might include:
• Varying feature sets
• Changing the systemic properties
• Changing the underlying platform (hardware/OS/data
base/ect)
• Change the implementation of some existing capability
© Matthew Bass 6

3
 17/08/2025

Evolving Technology
• Technology changes regularly
• Often for the same reason your systems evolve
• Sometimes these changes are small and benign
• Sometimes they can be disruptive
• Our systems often need to be able to accommodate these technological changes
• These changes can include:
• New version of the hardware
• OS
• Middleware
• Database
• Language
• …

© Matthew Bass 7

Related Concerns
• There are many concerns that are related to modifiability:
• Maintainability
• Extensibility
• Portability
• Variability
• …
• These are essentially the same concern, however
• They are all come down to the “cost of change”

© Matthew Bass 8

4
 17/08/2025

Is My System Modifiable?
• The question is not: “is my system modifiable”?
• The answer is always “yes” – with respect to some change
• The question is also not: “can I make some change to my system”?
• You can change anything on any system - given unlimited budget and unlimited
schedule …

• The question is can you make a specific change easily enough

© Matthew Bass 9

What Is Modifiability
• With modifiability the key question is not “if”, but “how
much?”
• Modifiability is about the “cost of change”
• The relevant aspects of modifiability include:
• What will change?
• When will the change take place?
• How much time/effort can the change require?

© Matthew Bass 10

5
 17/08/2025

What Will Change

• The business doesn’t require general modifiability
• Instead the business relies on specific things being able to change in the system
• This is true even if the business doesn’t know what kind of changes they will require
• The kind of things that can change include:
• Alternate implementation – we change the implementation of a given set of capability
• Change the platform (OS, hardware, database, ect)
• Add additional capability that doesn’t currently exist
• Change the external systems with our system interoperates
• The qualities the system exhibits
• Change the capacity of the system
• Each of these will be supported by different design decisions

© Matthew Bass 11

When?
• These changes could take place at different times in the
product life cycle
• These include:
• Design time changes
• Compile time changes
• Run time changes
• Again, each of these relies on different mechanisms in the
system

© Matthew Bass 12

6
 17/08/2025

Cost
• We think of cost as being only monetary
• This is the majority of the concern with software as well
• With software development cost is often equated to staff time
• We might also be worried about calendar time, however
• This is true if we have a hard date (e.g. the Xmas sales cycle) that we
need to achieve
• With modifiability we typically articulate cost as staff time,
calendar time, or both

© Matthew Bass 13

Today
• Definition of Modifiability
• Modifiability Quality Attribute Scenarios
• Analyzing Modifiability
• Modifiability Tactics

© Matthew Bass 14

7
 17/08/2025

General Quality Attribute Table

Portion of the Scenario Possible Values

Source End user, developer, system administrator, product manager, …

Stimulus A directive to add/remove/modify functionality, a quality attribute, capacity, or

technology
Artifact The system, code, data, interfaces, components, resources, configurations, …

Environment Runtime, compile time, build time, initiation time, design time

Response One or more of the following:

• Make modification
• Test modification
• Deploy modification
Response Measure Cost in terms of:
• Effort
• Calendar time
• Money
• Extent to which modification affects other functions or quality attributes
• New defects introduced

© Matthew Bass 15

Stimulus
• The stimulus describes the change to be made to the system
• The change can be any aspect of the system
• Functionality
• Quality attribute
• Technology
• Capacity
• These changes can be things like bug fixes or enhancements
• Other terms like “maintainability” or “flexibility” are essentially the
same as modifiability
© Matthew Bass 16

8
 17/08/2025

Artifact
• The artifact specifies what will have to accommodate the
change
• Remember we don’t want to embed design decisions in the
requirement
• If you’ve not already decomposed the system this will be “the system”
• The perspective of the artifact (static or dynamic) should align
with the environment
• In this case the environment defines when the change will be made

© Matthew Bass 17

Environment
• This specifies when the change will be made
• Changes can be made at:
• Design time
• Compile time
• Build time
• Initiation time
• Runtime

© Matthew Bass 18

9
 17/08/2025

Response
• Essentially this will describe what it means to accommodate
the change
• These could include:
• Make the change
• Test the change
• Deploy the change
• The response should align with what you need to be able to
do within the allotted cost/impact specified in the measure

© Matthew Bass 19

Response Measure
• The responses take time and cost money
• The time/cost is what differentiates a system that modifiable
enough from one that’s not
• Measures can include:
• Staff time
• Calendar time
• Direct cost
• Impact to existing system

© Matthew Bass 20

10
 17/08/2025

Today
• Definition of Modifiability
• Modifiability Quality Attribute Scenarios
• Analyzing Modifiability
• Modifiability Tactics

© Matthew Bass 21

Analyzing Modifiability
• The way we analyze a system is going to depend on the concern we are
analyzing
• With modifiability we can separate run time changes from static changes
• With run time changes we are typically worried about things like:
• Impact on existing capability
• Faults introduced
• Time until system becomes operational
• We’ll talk about these in a couple of minutes

© Matthew Bass 22

11
 17/08/2025

Static Modifications
• The more common modifiability concern is how much
time/effort is involved with a static change to the system
• In many ways analyzing effort required to make a change is
not any different from estimate construction effort
• The architectural aspect is to ensure it’s clear what is involved
in making the change
• If we’re going to change code this requires analyzing the coupling
• If we’re changing the support for a quality attribute things become a
bit more complicated
© Matthew Bass 23

Coupling
• Let’s assume we are going to modify existing code
• We need to look at 2 general kinds of dependencies
• Direct dependencies
• Indirect dependencies
• A dependency can be syntactic and/or semantic
• A syntactic dependency depends on the syntax of the interface
• These are dependencies that can be caught by a compiler
• A semantic dependency is a dependency based on meaning
• These can not typically be caught by a compiler
© Matthew Bass 24

12
 17/08/2025

Consider the Following

• What are the syntactic dependencies?
• What about the semantic dependencies?
Event Bus

A B C D

© Matthew Bass 25

Consider the Following

• What are the syntactic dependencies? Legend

• What about the semantic dependencies?

Code Module

A B C D
Uses

© Matthew Bass 26

13
 17/08/2025

Data Model Dependencies

• Dependencies on the data model aren’t always obvious from
a “uses” view
• Some changes result in a change to the data model
• Consider a situation where:
• A depends on B, and B depends on C, and they all rely on the data
type “Employee”
• If a change in A causes the definition of “Employee” to
change, B and C might have to change as well

© Matthew Bass 27

Determining Ripple Effect

• In order to determine impact of a change we want to look at
both syntactic and semantic dependencies
• Syntactic dependencies will result from a direct “uses”
relationship
• In order for there to be semantic dependencies there has to
be shared data
• This is not always obvious
• In event based systems this can change dynamically

© Matthew Bass 28

14
 17/08/2025

Estimating Effort
• Estimating effort is no different than estimating time to construct some
portion of the system
• We can use “top down” techniques such as
• Function point analysis
• We are in a position to consider “bottom up” techniques as well
• This is where we look at the actual work involved and estimate effort
• This may require considering the detailed design for some part of the
system
• Depending on how important our estimate is, this might be worthwhile

© Matthew Bass 29

Today
• Definition of Modifiability
• Modifiability Quality Attribute Scenarios
• Analyzing Modifiability
• Modifiability Tactics

© Matthew Bass 30

15
 17/08/2025

Modifiability Tactics
• In general there are 4 kinds of things we can do
to decrease the cost of change:
• Reduce module size
• Increase cohesion
• Reduce coupling
• Defer binding time

© Matthew Bass 31

Reduce Module Size

• Sometimes a module (cohesive unit of code) can be very large
• An indication that it has a great deal of capability
• If this is true changes in that module will typically take longer
• One way to reduce the amount of time required to make a given change
is to “split” the module
• This means a large module would be decomposed into smaller modules
• This reduces the internal coupling and increases the modifiability of the
module

© Matthew Bass 32

16
 17/08/2025

Increase Cohesion
• Several tactics involve moving responsibility from one module
to another
• This is done in order to reduce the side effects of making a change
• A side effect is an unintended consequence of making a
change
• If one module has responsibilities that serve multiple
purposes, you might want to relocate some of those
responsibilities
• This will increase the semantic coherence
© Matthew Bass 33

Semantic Coherence
• This means that the responsibilities of a given module are
focused on the same concern
• The idea is that most desired changes are related to a given
set of functional responsibilities
• If you co-locate those responsibilities they will be easier to change
• Can anyone think of a situation where “semantic coherence”
might not be the right partitioning from a modifiability
perspective?

© Matthew Bass 34

17
 17/08/2025

Reduce Coupling
• These tactics all reduce coupling between modules
• Encapsulation
• Use an intermediary
• Restrict dependencies
• Refactor
• Abstract common services

© Matthew Bass 35

Encapsulation
• Encapsulation hides data and/or services behind a fixed interface
• The idea is you focus on the variable aspect of the system
• Identify what will change
• Hide the variable aspects behind a fixed interface
• While the implementation will change, the interface won’t
• The dependency was moved from the implementation to the interface
• This means that anything that used to depend on the code (that will change) now
depends on the interface (that will not change)

© Matthew Bass 36

18
 17/08/2025

Use An Intermediary
• Using an intermediary breaks a dependency
• Examples of intermediaries are:
• Publish subscribe mechanism
• Message based interaction
• Directory service
• Shared data
• …
• The type of dependency that is reduced depends on the type
of intermediary
© Matthew Bass 37

Intermediaries and Dependencies

• What kind of dependency is broken for each of the
intermediaries listed on the previous slide?
• Publish subscribe mechanism
• Message based interaction
• Directory service
• Shared data

© Matthew Bass 38

19
 17/08/2025

Restrict Dependencies
• This tactic reduces the modules that a given module is
dependent on
• This can be accomplished by:
• Reducing visibility (making an interface “private”)
• Adding authorization (making an interface available to only
“authorized” modules)
• This tactic is realized in several patterns such as:
• Layered system
• Wrapper
© Matthew Bass 39

Example: Layers – 1
• The layered pattern is used to structure applications that can be decomposed into
groups of elements in each of which address a different level of abstraction.
• Elements
• elements are layers and are typically libraries or collections of related services
• specific and related functional responsibilities are assigned to each layer
• Relations
• relationships between layers is often implicit and is usually call-return oriented

© Matthew Bass 40

20
 17/08/2025

Example: Layers – 2
• Perspective and view
• code oriented; usually module view, although in practice mixed perspectives are
often and incorrectly utilized
• Topology
• layers are positions adjacent to one another
• relationships between layers are not usually explicitly depicted – this is OK, if the
pattern semantics are adhered to.

Layer A
Layer B
Layer C

© Matthew Bass 41

Example: Layers – 3
• Semantics
• Layers can only call on services of the next lower layer; that is, each layer provides
services to the layer above it and calls on services provided by the layer below it.
• Example properties promoted
• modifiability, portability, reusability
• Example properties inhibited
• performance, size of implementation; that is executable code built using this pattern
will be larger

© Matthew Bass 42

21
 17/08/2025

Why are the Semantics

Important?
Application
Let’s consider an example…
Translator
Lets assume that portability is an important business goal, OS
so I select a decoupling mechanism like layers…
HW

This structure has semantics, properties it promotes and inhibits. Knowing these enables
early analysis of the properties.
Assume that we chose this structure without any analysis and we find out that the system is
too slow,… what can we do?
We can bridge layers,… but what happens to portability?
These decisions are only good or bad depending upon the relative importance of portability
and performance – but without the proper expertise, early analysis is impossible!

© Matthew Bass 43

Refactor
• We often end up in a situation where multiple modules
are affected by the same change
• This occurs when responsibility is duplicated in
multiple modules
• Can easily occur when functionality drives decomposition
• Co-locating these responsibilities can reduce the effort
required to make the change

© Matthew Bass 44

22
 17/08/2025

Abstract Common Services

• Multiple similar interfaces can sometimes be combined
• Similar interfaces are not exactly the same, but similar
• It might be more cost effective to combine these similar
interfaces into a single interface
• This will result in less code to implement and maintain the capability
• Parameterization is a common way to introduce a more
general purpose interface
• These parameters might be simple values or complex statements

© Matthew Bass 45

Defer Binding Time

• Letting computers handle changes will almost always be less expensive
than having people make the change
• Designing artifacts with built-in flexibility is cheaper than hand-coding a change
• Deferring binding time can introduce mechanism that allow for computer
aided changes
• Binding time can be deferred to:
• Compile time
• Deployment time
• Initialization
• Runtime

© Matthew Bass 46

23
 17/08/2025

Compile Time Binding

• Compile time binding involves binding values at
compile time
• Tactics that support this are:
• Component replacement
• Compile-time parameterization
• Aspects

© Matthew Bass 47

Deployment/Initialization Time Binding

• Imagine specifying specific bindings in a configuration file
• Doesn’t require recompilation of the executable
• The configuration parameters can be specified in a config file
and provided when the system is deployed
• In order to make a change you’d need to update the file and re-deploy
• A resource or configuration file could also be provided at
initialization time (startup)
• This means you can reconfigure the system by changing the config
file and rebooting
© Matthew Bass 48

24
 17/08/2025

Runtime Binding
• There are many runtime binding mechanisms
• Runtime registration
• Dynamic lookup
• Interpret parameters
• Name servers
• Plug-ins
• Publish subscribe mechanisms
• Polymorphism
• Shared repositories
© Matthew Bass 49

General Modifiability Hints

• When thinking about modifiability you want to first identify
what and when
• You want to know what will change, and when it will change
• Depending on when you’ll make the change that will dictate
what aspect of the system you look at
• Static (code changes) imply you’ll need to look at three
primary concerns
• Syntactic dependencies, semantic dependencies, and data model
dependencies
© Matthew Bass 50

25
 17/08/2025

Summary
• When analyzing the “modifiability” of a system we are concerned with
the “cost of change”
• We need to know what will change, when will the change be made, and
how much effort can be involved in making the change
• The effort should align with the needs of the business as they relate to
this system
• You need to be sure to analyze all dependencies, direct and indirect in
order to get a sense for what level of effort is involved

© Matthew Bass 51

26