sa 006 modifiability
DESCRIPTION
Software architecture & modifiability: it is about the costTRANSCRIPT
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
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 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. 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
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
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
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 7
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, …
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 8
Modifiability Generic Scenario (2/3)
Environment
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 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
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 ..
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 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.
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
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.
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 13
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.
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 14
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 15
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
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 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. 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. 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. 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. 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. 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. 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. 23
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
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 24
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.
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 26
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
Layers Pattern
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 28
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
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
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
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