Chapter 7: Modiﬁability Rob Pe5t SWE 443 Spring 2015 © Len Bass, Paul Clements, Rick Kazman, distributed under CreaLve Commons AOribuLon License Chapter Outline • 
• 
• 
• 
• 
What is Modiﬁability? Modiﬁability General Scenario TacLcs for Modiﬁability A Design Checklist for Modiﬁability Summary © Len Bass, Paul Clements, Rick Kazman, distributed under CreaLve Commons AOribuLon License What is Modiﬁability? •  Modiﬁability is about change and our interest in it is in the cost and risk of making changes. •  To plan for modiﬁability, an architect has to consider three quesLons: –  What can change? –  What is the likelihood of the change? –  When is the change made and who makes it? © Len Bass, Paul Clements, Rick Kazman, distributed under CreaLve Commons AOribuLon License Modiﬁability General Scenario Por$on of Scenario
Source
SLmulus
Possible Values
End user, developer, system administrator
A direcLve to add/delete/modify funcLonality, or change a quality aOribute, capacity, or technology
ArLfacts
Code, data, interfaces, components, resources, conﬁguraLons, … Environment
RunLme, compile Lme, build Lme, iniLaLon Lme, design Lme
Response
One or more of the following: • make modiﬁcaLon • test modiﬁcaLon • deploy modiﬁcaLon
Response Cost in terms of: Measure • number, size, complexity of aﬀected arLfacts • eﬀort • calendar Lme • money (direct outlay or opportunity cost) • extent to which this modiﬁcaLon aﬀects other funcLons or quality aOributes new dCefects © Len B• ass, Paul lements, iRntroduced
ick Kazman, distributed under CreaLve Commons AOribuLon License Sample Concrete Modiﬁability Scenario •  The developer wishes to change the user interface by modifying the code at design Lme. The modiﬁcaLons are made with no side eﬀects within three hours. © Len Bass, Paul Clements, Rick Kazman, distributed under CreaLve Commons AOribuLon License Goal of Modiﬁability TacLcs •  TacLcs to control modiﬁability have as their goal controlling the complexity of making changes, as well as the Lme and cost to make changes. © Len Bass, Paul Clements, Rick Kazman, distributed under CreaLve Commons AOribuLon License Goal of Modiﬁability TacLcs © Len Bass, Paul Clements, Rick Kazman, distributed under CreaLve Commons AOribuLon License Modiﬁability TacLcs Modifiability Tactics
Reduce Size
of a Module
Change
Requests
Split Module
Increase
Cohesion
Increase
Semantic
Coherence
Reduce
Coupling
Encapsulate
Defer
Binding
Changes Made
and Deployed
Use an
Intermediary
Restrict
Dependencies
Refactor
Abstract Common
Services
© Len Bass, Paul Clements, Rick Kazman, distributed under CreaLve Commons AOribuLon License Reduce Size of a Module •  Split Module: If the module being modiﬁed includes a great deal of capability, the modiﬁcaLon costs will likely be high. Reﬁning the module into several smaller modules should reduce the average cost of future changes. © Len Bass, Paul Clements, Rick Kazman, distributed under CreaLve Commons AOribuLon License Increase Cohesion •  Increase SemanLc Coherence: If the responsibiliLes A and B in a module do not serve the same purpose, they should be placed in diﬀerent modules. This may involve creaLng a new module or it may involve moving a responsibility to an exisLng module. © Len Bass, Paul Clements, Rick Kazman, distributed under CreaLve Commons AOribuLon License Reduce Coupling •  Encapsulate: EncapsulaLon introduces an explicit interface to a module. This interface includes an API and its associated responsibiliLes, such as “perform a syntacLc transformaLon on an input parameter to an internal representaLon.” •  Use an Intermediary: Given a dependency between responsibility A and responsibility B (for example, carrying out A ﬁrst requires carrying out B), the dependency can be broken by using an intermediary. © Len Bass, Paul Clements, Rick Kazman, distributed under CreaLve Commons AOribuLon License Reduce Coupling •  Restrict Dependencies: restricts the modules which a given module interacts with or depends on. •  Refactor: undertaken when two modules are aﬀected by the same change because they are (at least parLal) duplicates of each other. •  Abstract Common Services: where two modules provide not-‐quite-‐the-‐same but similar services, it may be cost-‐eﬀecLve to implement the services just once in a more general (abstract) form. © Len Bass, Paul Clements, Rick Kazman, distributed under CreaLve Commons AOribuLon License Defer Binding •  In general, the later in the life cycle we can bind values, the beOer. •  If we design arLfacts with built-‐in ﬂexibility, then exercising that ﬂexibility is usually cheaper than hand-‐coding a speciﬁc change. •  However, pu5ng the mechanisms in place to facilitate that late binding tends to be more expensive. © Len Bass, Paul Clements, Rick Kazman, distributed under CreaLve Commons AOribuLon License Design Checklist for Modiﬁability Alloca$on of Determine which changes or categories of changes are Responsibili$es
likely to occur through considera$on of changes in technical, legal, social, business, and customer forces. For each poten$al change or category of changes • Determine the responsibili$es that would need to be added, modiﬁed, or deleted to make the change. • Determine what other responsibili$es are impacted by the change. • Determine an alloca$on of responsibili$es to modules that places, as much as possible, responsibili$es that will be changed (or impacted by the change) together in the same module, and places responsibili$es that will be changed at diﬀerent $mes in separate modules.
© Len Bass, Paul Clements, Rick Kazman, distributed under CreaLve Commons AOribuLon License Design Checklist for Modiﬁability Coordina$on Determine which func$onality or quality aHribute can Model
change at run$me and how this aﬀects coordina$on; for example, will the informa$on being communicated change at run-‐$me, or will the communica$on protocol change at run-‐$me? If so, ensure that such changes aﬀect a small number set of modules. Determine which devices, protocols, and communica$on paths used for coordina$on are likely to change. For those devices, protocols, and communica$on paths, ensure that the impact of changes will be limited to a small set of modules. For those elements for which modiﬁability is a concern, use a coordina$on model that reduces coupling such as publish/subscribe, defers bindings such as enterprise service bus, or restricts dependencies such as broadcast.
© Len Bass, Paul Clements, Rick Kazman, distributed under CreaLve Commons AOribuLon License Design Checklist for Modiﬁability Data Determine which changes (or categories of changes) to the data abstrac$ons, Model
their opera$ons, or their proper$es are likely to occur. Also determine which changes or categories of changes to these data abstrac$ons will involve their crea$on, ini$aliza$on, persistence, manipula$on, transla$on, or destruc$on. For each change or category of change, determine if the changes will be made by an end user, system administrator, or developer. For those changes made by an end user or administrator, ensure that the necessary aHributes are visible to that user and that the user has the correct privileges to modify the data, its opera$ons, or its proper$es. For each poten$al change or category of change • determine which data abstrac$ons need to be added, modiﬁed, or deleted • determine whether there would be any changes to the crea$on, ini$aliza$on, persistence, manipula$on, transla$on, or destruc$on of these data abstrac$ons • determine which other data abstrac$ons are impacted by the change. For these addi$onal abstrac$ons, determine whether the impact would be on their opera$ons, proper$es, crea$on, ini$aliza$on, persistence, manipula$on, transla$on, or destruc$on. • ensure an alloca$on of data abstrac$ons that minimizes the number and severity of modiﬁca$ons to the abstrac$ons by the poten$al changes Design your data model so that items allocated to each element of the data model are likely to change together.
© Len Bass, Paul Clements, Rick Kazman, distributed under CreaLve Commons AOribuLon License Design Checklist for Modiﬁability Mapping Among Architectural Elements
Determine if it is desirable to change the way in which func$onality is mapped to computa$onal elements (e.g. processes, threads, processors) at run$me, compile $me, design $me, or build $me. Determine the extent of modiﬁca$ons necessary to accommodate the addi$on, dele$on, or modiﬁca$on of a func$on or a quality aHribute. This might involve a determina$on of, for example: • execu$on dependencies • assignment of data to databases • assignment of run$me elements to processes, threads, or processors Ensure that such changes are performed with mechanisms that u$lize deferred binding of mapping decisions.
© Len Bass, Paul Clements, Rick Kazman, distributed under CreaLve Commons AOribuLon License Design Checklist for Modiﬁability Resource Determine how the addi$on, dele$on, or modiﬁca$on of Management
a responsibility or quality aHribute will aﬀect resource usage. This involves, for example, • determining what changes might introduce new resources or remove old ones or aﬀect exis$ng resource usage. • determining what resource limits will change and how Ensure that the resources aTer the modiﬁca$on are suﬃcient to meet the system requirements. Encapsulate all resource managers and ensure that the policies implemented by those resource managers u$lize are themselves encapsulated and bindings are deferred to the extent possible.
© Len Bass, Paul Clements, Rick Kazman, distributed under CreaLve Commons AOribuLon License Design Checklist for Modiﬁability Binding For each change or category of change Time
• Determine the latest $me at which the change will need to be made. • Choose a defer-‐binding mechanism (see Sec$on 7.2.4) that delivers the appropriate capability at the $me chosen. • Determine the cost of introducing the mechanism and the cost of making changes using the chosen mechanism • Do not introduce so many binding choices that change is impeded because the dependencies among the choices are complex and unknown. © Len Bass, Paul Clements, Rick Kazman, distributed under CreaLve Commons AOribuLon License Design Checklist for Modiﬁability Choice of Determine what modiﬁca$ons are made easier or harder Technology
by your technology choices. • Will your technology choices help to make, test, and deploy modiﬁca$ons? • How easy is it to modify your choice of technologies itself (in case some of these technologies change or become obsolete)? Choose your technologies to support the most likely modiﬁca$ons. For example, an Enterprise Service Bus makes it easier to change how elements are connected but may introduce vendor lock in.
© Len Bass, Paul Clements, Rick Kazman, distributed under CreaLve Commons AOribuLon License Summary •  Modiﬁability deals with change and the cost in Lme or money of making a change, including the extent to which this modiﬁcaLon aﬀects other funcLons or quality aOributes. •  TacLcs to reduce the cost of making a change include making modules smaller, increasing cohesion, and reducing coupling. Deferring binding will also reduce the cost of making a change. © Len Bass, Paul Clements, Rick Kazman, distributed under CreaLve Commons AOribuLon License