sa 006 modifiability

Vakgroep Informatietechnologie – IBCN

Software Architecture

Quality Attributes & Tactics (3)

Modifiability

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 2

Modifiability

Modifiability is about the cost of changes.

Operating Profit (EBIT) = Revenues - Expenses


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.


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

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


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.



Modifiability Generic Scenario (1/3)

Source The developer, system administrator or end user, can request or introduce a change to the system.

StimulusA directive to Add/delete/modify functionality; Modify quality attributesModify platform, technologyOperate in a new environment, new usersScale up and scale out

ArtifactCode, data, interfaces, components, resources, configurations, …



Environment



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

Modifiabililty Generic QAS

p. 10

SourceDeveloper

Sys admin

User

Environment- Design

- Build

- Deploy

- Runtime

Measure

# of artifacts

Effort

Time

Cost

Impact

New defects

Response- Change,

- Test

- Deploy

StimulusModify:

- Functions

- Qualities

- Platform

- Technology

- Scale/Scope

ArtifactCode, Data, Interfaces

Components,

Resources, Configs ..


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.

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.


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-Efficient

Scalability is added through a multitier architecture supporting a load-balanced farm of identical application instances, running on a variable number of servers.


Figure : Four-level SaaS maturity model

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.



Modifiability Tactics

Tactics

to Control

ModifiabilityChange

Request

Arrives

Changes made,

Tested and Deployed

on Time, within Budget

Reduce Module Size Increase Cohesion Reduce Coupling Defer Binding Time

Commit as late as possible


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.


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.


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



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



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


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.


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


Modifiability Tactics: summary

Change

Request

Arrives

Changes made,

Tested and Deployed

on Time,

within Budget

Modifiability

Reduce

SizeIncrease

Cohesion

Defer

Binding Time

Encapsulation

Wrap

Restrict communication paths

Use an intermediary

Split modules

Increase Semantic Coherence

Abstract Common Services

Reduce

Coupling

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


The MVC Pattern

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.


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.


Layers Pattern


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…


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.


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.


Example 1: Modifiability

p. 32 Vakgroep Informatietechnologie – Onderzoeksgroep IBCN

Artifact

Code

Environment

Design time

Response measure

Integration of visualization with system

is done within 4 hours

Response

Modification is made

without side effects

Stimulus

Create different

visualization for analysis

Project: BikePRINT

Source

Developer

Example 2: Interoperability

p. 33 Vakgroep Informatietechnologie – Onderzoeksgroep IBCN

Artifact

Code

Environment

Design time

Response measure

Only the communication

module is adjusted

Integration is possible within 3

hours

Response

Protocol is added without

affecting other

functionality

Stimulus

Add new communication protocol

Project: T.U.R.C.

Source

Developer

sa 006 modifiability

Technology

design change

modifiability generic

enemy of modifiability

modifiability definition

modifiabilitythe modifiability

modifiability aspects

example modifiability

new environment