The Modifiability of a software system is related to how minimal is the cost/effort to develop and deploy changes to the software. This relates to well known concepts and principles of coupling, cohesion, maintainability, etc. and is the basis for many of the elements of object-oriented, component-based, and aspect-oriented design ("reuse" is a close cousin for all these as well).
Software Modifiability Tactics are presented in section 5.3 of Software Architecture in Practice. A taxonomy is given which relates architectural tactics to architectural patterns ("styles") and the design patterns which are largely concerned with achieving the attribute (in this case "modifiability") for various types of products and contexts. The article Understanding Architectural Patterns in Terms of Tactics and Models even has a nice matrix that maps architectural patterns or styles to the various kinds of modifiability tactics.
The taxonomy for software modifiability tactics is broken down as follows:
- Localize Changes (increase cohesion)
- Maintain Semantic Coherence
- Anticipate Expected [types of] Changes
- Generalize the Module
- Limit Possible Options
- Abstract Common Services
- Prevent Ripple Effects (reduce coupling)
- Hide Information
- Maintain Existing Interfaces
- Restrict Communication Paths
- Use an Intermediary
- Defer Binding-time (defer decision-making)
- Run-time Registration
- Configuration Files
- Polymorphism/Delegation
- Component Replacement
- Adhere to Defined Protocols
In September 2007, an SEI Technical Report on Software Modifiability Tactics was published that provides a comprehensive discussion of these modifiability tactics and the architecture/design patterns that can be used to implement them (and some of the tradeoffs involved).
Links and Resources on Software Modifiability Tactics:
- Modifiability Tactics, Chapter 5 section 3 of Software Architecture in Practice
- Understanding Architectural Patterns in Terms of Tactics and Models
- Modifiability Tactics, SEI @ CMU Technical Report CMU/SEI-2007-TR-002
- Design and Tactics, Lecture notes from an Aalborg University course on Database and Software Architecture
In a subsequent blog-entry I will muse about how Modifiability relates to Agility in both software architecture/design and in software process architecture/design.
2 comments:
I appreciate your previous blogs and this is also very helpful for the users about to the Architecture in Practice.
I think it is the best source of introducing yourself.
Thanks a lot for this post. i have been looking all over to find the meaning of modifiability. Also can you please tell me the difference between a product and a version. iam am a ug student.
Post a Comment