Issue No.02 - March/April (2009 vol.26)
Published by the IEEE Computer Society
Uwe Zdun , Vienna University of Technology
DOI Bookmark: http://doi.ieeecomputersociety.org/10.1109/MS.2009.37
Capturing software design knowledge is important because it tends to evaporate as software systems evolve. This has severe consequences for many software projects. To counteract this phenomenon, effective, systematic documentation of design knowledge is important. However, many proposed approaches for capturing design knowledge are still experimental or in an early-adoption stage. In this article, we discuss existing and new approaches to deal with parts of the knowledge evaporation problem.
Capturing software design knowledge is important because it tends to evaporate as software systems evolve. This has severe consequences for many software projects. Knowledge evaporation is a problem for all kinds of design knowledge, including software architectural knowledge, object-oriented design knowledge, knowledge about implementation details, and knowledge about the software process. We can ascribe many of the reasons for this to two "laws" of software evolution: increasing complexity and continuing change. The sidebar "Design Knowledge Evaporation and
the Laws of Software Evolution" summarizes these laws and explains their relationship to design knowledge evaporation.
To counteract this phenomenon, effective, systematic documentation of design knowledge is important. However, many proposed approaches for capturing design knowledge are still experimental or in an early-adoption stage. In practice, many developers, designers, and architects consider the capture of design knowledge a resource-intensive process without tangible, short-term gains. They often address it inadequately or even skip it entirely. On the other hand, some do use a set of accepted approaches to deal with parts of the knowledge evaporation problem. For more information, see the sidebar " Current and New Approaches for Capturing Design Knowledge."
For this minitheme, the three articles we selected from our regular queue address increasing complexity and continuing change by providing explicit means for capturing design knowledge.
"Modularization of a Large-Scale Business Application: A Case Study," by Santonu Sarkar, Shubha Ramachandran, G. Sathish Kumar, Madhu K. Iyengar, K. Rangarajan, and Saravanan Sivagnanam, reports on using a subset of the common approaches for capturing design knowledge. The project deals with reengineering for better modularity. The article's starting point is the situation that large software systems deteriorate into unmanageably complex monoliths because continuing changes aren't applied systematically. Among the approaches used for capturing design knowledge are guidelines on how to structure modules and module interactions, explicit modeling of the system's modularization, tools to gather the design knowledge and aid modularization, involvement of stakeholders other than developers, and metrics to measure the quality of the modularization.
In "The Decision View's Role in Software Architecture Practice," Philippe Kruchten, Rafael Capilla, and Juan Carlos Dueñas propose augmenting architectural view models using a decision view that extends the traditional views with information on the design rationale. They argue that a decision view can help record and document the key decisions with an acceptable overhead. The approach is based on the well-known 4+1 view model but can easily be extended to other such models. The article proposes a lightweight approach that architects can apply as an extension to existing view models. In addition, the authors describe the historical evolution of software architecture representation.
Finally, "Software Architecture Design Reasoning: A Case for Improved Methodology Support," by Antony Tang, Jun Han, and Rajesh Vasa, proposes a novel approach to modeling design decisions and supporting reasoning about software architecture designs. Explicitly modeling design decisions makes architectural designs justifiable through the design rationale, and support for design reasoning enables the analysis of causal relationships among the design context, the design justification, and the design result. The authors suggest that this eases understanding, analysis, and communication of the architecture and hence reduces the complexity with which architects must deal. In addition, it supports changing the design: we can analyze the impact of changes when a system evolves while still accessing the original design rationale. This article targets readers who are interested in more experimental ways to capture and use design knowledge.
Depending on the situation, all three approaches described in these articles might help address the problems that many projects face: increasing complexity and continuing change.
Uwe Zdun is an assistant professor in the Distributed Systems Group at the Vienna University of Technology. His research interests include software patterns, software architecture, language engineering, service-oriented architecture, distributed systems, and object orientation. He authored or coauthored Frag, Extended Object Tcl (XOTcl), Leela, ActiWeb, and many other open source software systems. He's coauthor of Remoting Patterns: Foundations of Enterprise, Internet, and Realtime Distributed Object Middleware (John Wiley & Sons) and Software-Architektur: Grundlagen, Konzepte, Praxis (Software Architecture: Basics, Concepts, Practice; Elsevier/Spektrum). He's also the European editor of the Transactions on Pattern Languages of Programming. Contact him at firstname.lastname@example.org.