Software architecture & modifiability: it is about the cost

1. Software Architecture
Quality Attributes & Tactics (3)
Modifiability
Vakgroep Informatietechnologie – IBCN

2. Modifiability
Modifiability is about the cost of changes.
Operating Profit (EBIT) = Revenues - Expenses
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 2

3. Modifiability Definition
The modifiability of a software system is the
ease with which it can be modified to changes
in the environment, requirements or functional
specification.
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 3

4. Modifiability Aspects
 What can change ?
 Functions, Platform, Environment.
 Qualities (performance, reliability,…)
 Capacity (number of users,..)
 When is the change required ?
 Development time, build time, configuration, runtime
 Who will implement the change ?
 Software engineers ,users , administrators ?
 What is the cost of change?
 Cost of introducing the mechanism in the architecture
 Cost of making the modification using that mechanism
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 4

5. Business Concerns (1/2)
 Extensibility
 Adding and enhancing functionality
 Effort for the next release
 Simplification
 Complex components are difficult to change
 Simplifying functionality for maintainability
 Restructuring
 Modularizing
 Creating reusable components
 Smaller components are easier to modify
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 5

6. Business Concerns (2/2)
 Time to deploy
 Time for introducing a new feature
 Competitiveness
 Functional scalability
 Ability to scale up or down in terms of users,
transactions …
 Functional flexibility
 Make existing functionality available to new users,
new locations & unforeseen situations.
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 6

7. Modifiability Generic Scenario (1/3)
 Source
The developer, system administrator or end user, can
request or introduce a change to the system.
 Stimulus
A directive to
Add/delete/modify functionality;
Modify quality attributes
Modify platform, technology
Operate in a new environment, new users
Scale up and scale out
 Artifact
Code, data, interfaces, components, resources,
configurations, …
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 7

8. Modifiability Generic Scenario (2/3)
 Environment

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 8

9. Modifiability Generic Scenario (3/3)
 Response
Make, test and deploy the modification
 Response measures
 Number of affected artifacts.
 Size of the change.
 Effort & time
 Cost (direct or opportunity cost)
 Number of other functions or quality attributes affected
by the change
 New defects introduces
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 9

10. Modifiabililty Generic QAS
Artifact
Code, Data, Interfaces
Components,
Resources, Configs ..
Source Stimulus Environment Response Measure
Developer Modify: - Design - Change, # of artifacts
Sys - Functions - Build - Test Effort
admin - Deploy - Deploy Time
- Qualities
User - Runtime
- Platform Cost
- Technology Impact
- Scale/Scope New defects
p. 10

11. Example Modifiability Scenario
A developer wants to change the UI code
(e.g. change an input field to a pick list)
at design time; the modification is made without
side effects in 3 hours.
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 11

12. Example 2: Saas Applications
A SaaS application is scalable, multi-tenant, and
configurable.
Scalable application is able to handle and to support the
required quality of service as the system load increases.
In a multi-tenancy environment, multiple customers share the
same application, running on the same operating system, on the
same hardware, with the same data storage mechanism. The
distinction between the customers is achieved during application
design, so that customers do not share or see each other's data.
Configurable applications allow a certain level of customization
via metadata services, which are responsible for managing
application configuration for individual tenants.
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 12

13. Saas Maturity Model
 Lvl I: Ad Hoc/Custom
 Each customer has its own customized version
 Lvl II: Configurable
 Flexibility through configurable metadata: many
customers can use separate instances of the
same application code.
 Lvl III: Configurable, Multi-Tenant-Efficient
 Hosting a single instance, which serves all
customers. Requires appropriate authorization
and security policies.
 Lvl IV: Scalable, Configurable, Multi-Tenant-
Figure : Four-level SaaS maturity model
Efficient
Scalability is added through a multitier architecture
supporting a load-balanced farm of identical
application instances, running on a variable
number of servers.
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 13

14. Understanding Modifiability
The modifiability of a system is determined by:
 Coupling: Modules in systems have different responsibilities. If
the responsibilities of modules overlap, a single change request
may impact multiple modules. The probability that a modification to
one module will propagate to another is called coupling. Coupling is
an “inter module” characteristic and is the enemy of modifiability:
low coupling is good.
 Cohesion: Cohesion measures how much the responsibilities of a
module are related. The cohesion of a module is the probability that
a change request to one responsibility will impact another one.
Cohesion is an intramodule characteristic and high cohesion is
good.
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 14

15. Modifiability Tactics
Tactics
to Control Changes made,
Change
Request Modifiability Tested and Deployed
Arrives on Time, within Budget
 Reduce Module Size
 Increase Cohesion
 Reduce Coupling
 Defer Binding Time
 Commit as late as possible
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 15

16. Increase Cohesion (1/2)
 Maintain Semantic Coherence
 The responsibilities in a module should serve the
same purpose.
 Example: Responsibilities that deal with hardware
should be allocated to the hardware module and not to
the application level. A hardware responsibility typically
does not have any semantic coherence with the
application responsibilities.
 Abstract Common Services
 In case of similar services they should be
implemented only once in a slightly more general
form.
 Refactoring is an example of this tactic. Refactoring
rule involves examining existing responsibilities and
factoring out the similar elements.
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 16

17. Increase Cohesion (2/2)
 How to test for semantic cohesion?
 Anticipate the set of envisioned changes:
 Does one specific change impacts a lot of
modules ?
 Do fundamentally different changes affect
the same module ?
 If some responsibilities are not affected by a
change they should be moved to another module.
 If a change impacts multiple modules,
responsibilities need to be moved or allocated to
new modules.
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 17

18. Reduce Coupling (1/3)
 Hide information - Encapsulation
 Encapsulation introduces an explicit interface to a
module.
 Encapsulation acts by enforcing information hiding
behind an interface.
 Maintain existing interfaces – Wrappers
 A wrapper is a form of encapsulation. It is an interface for
a module that transforms the data or control information
for the module.
 The wrapper transformations reduce the total cost of a
change by reducing the costs associated with
propagation
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 18

19. Reduce Coupling (2/3)
 Reduce Communication Paths
 Use Intermediaries - Break dependencies.
 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. 19

20. Reduce Coupling (3/3)
 More intermediaries ...
 Identity of interface of A:
 A Broker can be used to find the interface to
perform a service,
 Location of A (runtime)
 register with name-server
 Resource behavior of A or resource controlled by A
 Resource manager is intermediary
 Existence of A:
 The Factory pattern can construct instances if
needed
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 20

21. Defer Binding Time (1/2)
 Implementation/Design time:
 Aspect-Oriented Programming.
 Polymorphism.
 Parameterize Modules.
 Build time
 Component Replacement.(build scripts, makefiles)
 Deployment & Initialization time
 Configuration-Time Binding.
 Resource Files.
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 21

22. Defer Binding Time (2/2)
 Runtime
 Use Runtime Registration.
 Dynamic Lookup (for services)
 Interpret Parameters.
 Start-Up Time Binding.
 Runtime Binding.
 Name Servers.
 Plug-Ins.
 Publisher-Subscriber
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 22

23. Modifiability Tactics: summary
Modifiability
Reduce Defer
Size Binding Time
Split Increase Reduce Changes made,
Change modules Cohesion Coupling
Request Tested and Deployed
Increase Encapsulation
Arrives Semantic Wrap
on Time,
Coherence
Restrict within Budget
Abstract communication
paths
Common
Services Use an
intermediary
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 23

24. Architectural Patterns & Tactics
 The Model-View-Controller architectural
pattern (MVC) divides an interactive application
into three components.
 The Model contains the core functionality, data and
state.
 Views is the user interface component. It produces a
representation of the model and can handle input.
 Controllers manage the interaction between the
model and the view ensures consistency between.
 Used in :
 Java Swing, Adobe Flex, Nokia Qt, ASP.net
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 24

25. The MVC Pattern

26. MVC Tactics analyzed:
The Model-View-Controller pattern implements the
following tactics:
Maintain Semantic Coherence. According to the definition, the
model component contains the functional core of the application,
requiring all the necessary responsibilities for those concepts to be
located within the model.
Encapsulation. The model component encapsulates the
functional core data and functionality.
Use an Intermediary. The controller acts as an intermediary
between the view and the model.
Use Runtime Binding. Views can be opened and closed
dynamically, and different views can be bound to the data at
different times during execution.
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 26

27. The Layers Pattern
 The Layers architectural pattern helps to
structure applications that can be
decomposed into groups of subtasks in which
each group of subtasks is at a particular level
of abstraction
 The pattern consists of a number of layers.
Layers are partially ordered with respect to
the uses relationship. A layer may only use
lower level layers in the partial order.
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 27

28. Layers Pattern
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 28

29. Layers are used when :
 Late source code changes should not ripple
through the system…
 Interfaces should be stable, and may even be
prescribed by a standards body.
 Parts of the system should be exchangeable…
 It may be necessary to build other systems at a
later date with the same low-level issues…reuse.
 Similar responsibilities should be grouped…
 The system will be built by a team of
programmers, and work has to be subdivided
along clear boundaries…
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 29

30. Layers Tactics Analyzed (1/2)
 The Layers pattern can be understood in terms of the
following tactics:
 Maintain Semantic Coherence. The goal of ensuring that a
layer’s responsibilities all work together without excessive
reliance on other layers is achieved by choosing
responsibilities that have some sort of semantic coherence.
 Raise the Abstraction Level. Layers represent an abstract
ladder of services. Modules in lower layers may have an
abstract (or more general) representation in the upper
layers.
 Example, there may be concrete device drivers in the lower layer
and a more general notion of a virtual device driver in an upper
layer.
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 30

31. Layers Tactics Analyzed (2/2)
 Abstract Common Services. Typically the responsibilities
of a layer are grouped together into services. Abstract
Common Services would place a single copy of the service
in a distinct module and have it accessed by the
consumers of the replicated service. In the Layers pattern,
the common services are abstracted and located in a layer
below the consumers of the services.
 Use Encapsulation. There are two design considerations
of the Layers pattern with respect to interfaces:
1. Each layer may have its own interface and
2. Particular layers may act as an interface (e.g., API, façade) for
another layer.
The first consideration is an instance of the Use Encapsulation
tactic; the second is an instance of the Use an Intermediary
tactic.
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 31

32. Example 1: Modifiability
Project: BikePRINT
Artifact
Code
Source Stimulus Environment Response Response
Developer Create Design time Modification measure
different is made Integration of
visualization without side visualization
for analysis effects with system
is done within
4 hours
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 32

33. Example 2: Interoperability
Project: T.U.R.C.
Artifact
Code
Response
Source Stimulus Environment Response measure
Developer Add new Design time Protocol is Only the
communicati added communication
on protocol without module is
affecting adjusted
other Integration is
functionality possible within 3
hours
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 33