Chapter 7 - Modifiability Flashcards
definition of modifiability
pertains to the cost and risks of making changes
3 issues with regards to modifiability
- what can change?
- what is the likelihood of change?
- when is the change made and who makes it?
In general scenario, 3 possible values for “Source”
end user
developer
system administrator
In general scenario, 2 possible values for “Stimulus”
directive to:
- add/delete/modify functionality
- change quality attribute, capacity, or technology
In general scenario, 6 possible values for “Artifact”
code data interfaces components resources configurations
In general scenario, 3 possible values for “Response”
- make modification
- test modification
- deploy modification
In general scenario, 5 possible values for “Environment”
- runtime
- compile time
- build time
- initiation time
- design time
In general scenario, 6 possible values for “Response Measure”
- number, size, complexity of artifacts affected
- effort
- calendar time
- money
- extent to which modifications affect functions or quality attributes
- new defects introduced
2 Primary goal of modifiability tactics
- control the complexity of making changes
- control the time and costs to make changes
4 categories of modifiability tactics
- reduce the size of a module
- increase cohesion
- reduce coupling
- defer binding
1 tactics for reducing the size of a module
split module
what does it mean to split a module?
refining modules with a great deal of capability into several smaller modules to reduce the average cost of future changes
1 tactic increasing cohesion
increase semantic coherence
what does it mean to increase semantic coherence
and two program units A and B whose responsibilities do not serve the same purpose should be placed in separate modules
5 tactics for reducing coupling
- encapsulate
- use an intermediary
- restrict dependencies
- refactor
- abstract common services
what does it mean to encapsulate
to introduce an explicit interface to a module including an API and associated responsibilities
what does it mean to use an intermediary
using some intermediate responsibility to break a dependency between to responsibilities A and B
what does it mean to restrict dependencies
restrict modules which a given module interacts with or depends on
what does it mean to refactor
undertaken when tow modules are affected by the same change because they are at least partial duplicates
what does it mean to abstract common services
implement a single service used slightly differently by two different modules one time in a more general and abstract form
what does it mean to defer binding
the later in the life cycle in which things are bound typically leads to greater flexibility (in terms of modifiability)
the importance of allocation of responsibilities with regards to modifiability
determine which changes or categories of changes are likely to occur through consideration of changes in technical, legal, social, business and customer forces
3 important tasks pertaining to allocation of responsibilities with regard to modifiability for each potential change or category of changes
- determine the responsibilities that need to be added to make the change
- determine what other responsibilities are impacted by the change
- allocate responsibilities in such a way so that groups of responsibilities affected by a change are in the same module (maximize local changes!)
3 issues with the coordination model in regards to modifiability
- determine which functionality or quality attribute can change at runtime and how this affects coordination
- determine which devices, protocols, and communication paths used for coordination are likely to change
- use a coordination model to reduce coupling for elements that are likely to change
3 issues with the data model in regards to modifiability
- determine which changes to the data abstractions, their operations, or their properties are likely to occur
- for each category of change, determine who will make the changes and ensure that they have the correct privileges
- design the data model so that allocated items change together
In regards to the data model, 4 things to consider for each potential change or category of change
- determine which data abstractions need to be added, changed, or deleted
- determine whether there would be any changes to creation, initialization, manipulation, translation, or destructions of these data abstractions
- determine which other data abstractions are impacted by the change
- ensure the allocation of data abstractions minimizes the number and severity of modifications
3 issues with the mapping among architectural elements in regards to modifiability
- determine if changing the way which functionality is mapped is desirable
- determine the extent of modifications necessary to accommodate changes to functionality or quality attributes
- ensure that changes are performed with mechanisms that utilize deferred binding of mapping decisions
3 issues with resource management in regards to modifiability
- determine how changing a responsibility or quality attribute will affect resource usage
- ensure that resources after the modification are sufficient to meet system requirements
- encapsulate all resource managers and the policies they implement and bindings are deferred as much as possible
4 things to consider for each type of change with regards to binding time
- determine the latest time a given change will need to be made
- chose a defer-binding mechanism
- determine the cost of introducing and making changes using the chosen mechanism
- do not introduce so many binding choices so as to impede change
2 issues with the choice of technology in regards to modifiability
- determine which modifications are made easier or harder by the choice of technology
- chose technologies that will support the most likely modifications
