Download
1 / 13
150 likes | 294 Vues
This paper discusses the critical role of architectural decisions in software development and highlights the challenges faced in documenting these decisions, leading to "knowledge vaporization." It proposes the use of design patterns as a solution to enhance decision documentation and mitigate the risks associated with undocumented decisions. By establishing a relationship between patterns and decision-making, the paper elucidates how patterns can facilitate better documentation and communication among architects while acknowledging limitations and the need for further research.
E N D
On Using Patterns to Capture Architectural Decisions: Paper Overview/Summary James Martin CpE 691 February 4, 2010
Outline • Problem Overview • The pattern solution • Comparing patterns and decision • The pattern-decision relationship • Using patterns • Limitations and further research
Problem overview • Decisions made during software architecting have a substantial impact on the system • Design decisions aren’t documented by architects thoroughly enough by architects. • All aspects (i.e. alternatives, rationale, expected consequences, etc) are not usually captured • Leads to “knowledge vaporization”
Knowledge vaporization • Decisions are not recorded • Development and evolution cycles of software do not have appropriate access to decisions that were made during the architectural design • The decisions might reside in the heads of architects, but people eventually forget • “If something is not written down, it does not exist”
Documentation challenges • It takes a lot of effort • Decisions are made without thought • Can be disruptive to the flow of design • Architects don’t know how
The patterns solution • A.K.A. architectural style • Patterns help document decisions because they: • Include general structural and behavioral info • When a pattern is chosen, a decision is made so it can be documented • Architects already use patterns so they aren’t disruptive • Patterns are typically easy to follow • They are solutions to recurring problems
Pattern examples • Layers • Pipes and filters • Blackboard • Model-View-Controller (MVC) • Presentation-Abstraction-Control (PAC)
Decisions • Issue being decided • Decision that was made • Alternatives • Reasons for making the decision
The pattern-decision relationship • Two types of knowledge • Application-generic knowledge • Implicate knowledge gained through previous experiences (such as from patterns) • Used to make decisions • Application-specific knowledge • Involves decisions made during the architecting process, as well as the solutions • It is the decisions • Patterns comprise #1 • Decisions comprise #2
Using patterns • Architecting is decision-intensive • Making a lot of decisions means doing a lot of documentation • Using patterns helps alleviate the need for as much documentation since the documentation is implicit • When a pattern is selected the architectural decision is documented via the pattern’s usage
Limitations and further research • Application specific decisions must still be documented • Not all decisions can be captured via patterns • Organization decisions • Financial decisions • Using multiple patterns together without understanding them can lead to conflicts • Why a decision was made is not documented via patterns
