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
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
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
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
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
Hinweis der Redaktion
Platform: OS, DBMS, Middleware change Environment: Keyboard control to touch screen, sensor input Data representation: binary to ASCII , proprietary to standard (XML), ….
Model - The model represents enterprise data and the business rules that govern access to and updates of this data. Often the model serves as a software approximation to a real-world process, so simple real-world modeling techniques apply when defining the model. View -The view renders the contents of a model. It accesses enterprise data through the model and specifies how that data should be presented. It is the view's responsibility to maintain consistency in its presentation when the model changes. This can be achieved by using a push model, where the view registers itself with the model for change notifications, or a pull model, where the view is responsible for calling the model when it needs to retrieve the most current data. Controller - The controller translates interactions with the view into actions to be performed by the model. In a stand-alone GUI client, user interactions could be button clicks or menu selections, whereas in a Web application, they appear as GET and POST HTTP requests. The actions performed by the model include activating business processes or changing the state of the model. Based on the user interactions and the outcome of the model actions, the controller responds by selecting an appropriate view.