ftameworkfor capturing and using architecture design knowledge to support architecture-based software development'. A web-based knowledge management.
PAKME: A Tool for Capturing and Using Architecture Design Knowledge
IMuhammad Ali Babar, 2Xiaowen Wang,
Ian Gorton 1Empirical Software Engineering National ICTAustralia Ltd. & CSE, UNSW, 2MRO Software I tX7;LL 7 I...
-12 -
?,ozrtowL, --I
4 -t __++n?Xn;+
--,!*
-
---
- ----
Abstract Management of architecture knowledge is vital for improving an organization's architectural capabilities. Despite the recognition of the importance of capturing and reusing architecture knowledge, there is no suitable support mechanism. We have developed a conceptual ftamework for capturing and using architecture design knowledge to support architecture-based software development'. A web-based knowledge management Process-based Architecture tool, Knowledge Management Environment (PAKME), has been developed to support that framework. This paper describes the main architectural components and features of the PAKME. We also discuss different usages of the tool for capturing and using architecture design knowledge to support architecting process. The paper concludes with open issues that we plan to address in order to extend the tool and successfully transfer the support mechanism to industry.
Keywords: Software architecting, knowledge management, software reuse, process improvement
1. Introduction Software Architecture (SA) design and evaluation involves complex knowledge intensive tasks [1, 2]. The knowledge required to make suitable architectural choices is broad, complex, and evolving, and can be beyond the capabilities of any single architect. The software architecture research community has developed several approaches (such as Architecture Tradeoff Analysis Method (ATAM) [3], 4+1 views [4], Rationale Unified Process (RUP) [5] and architecture-based development [6]) to support a disciplined architecture process. Although, these approaches help manage complexity by using systematic approaches, they provide little guidance or support to capture, maintain, and reuse knowledge about the architectural artifacts used in design decisions and explanations of the use of certain types of design constructs (such as patterns, styles, tactics and so on). Such information represents architecture knowledge, which can be valuable throughout the software development lifecycle [7, 8]. However, the lack of a systematic approach to capture 1 Framework has been reported in [14].
< _
2
__
-,-,
and use architecture knowledge may preclude organizations from growing their architecture capability. Moreover, knowledge concerning the domain analysis, architectural patterns used, design alternatives evaluated and design decisions made is implicitly embedded in the architecture and/or becomes tacit knowledge of the architect [2, 7, 9]. At National ICT Australia, one of the main goals of our research is to develop effective knowledge management (KM) structures to facilitate the management of implicit architecture knowledge generated during the architecture process or informally described in sources such as [10-13]. We have developed a framework for capturing and using architecture knowledge [14]. The framework identifies various approaches to capture implicit and explicit design and process knowledge,, along with an approach to distill and document architecture knowledge from patterns [15]. The novelty of the approach resides in its ability to incorporate all the components into an integrated approach, which has been implemented in a web-based architecture knowledge management repository. This paper presents the Process-centric Architecture Knowledge Management Environment, PAKME, which provides a support mechanism to capture and use architecture knowledge. The implementation of PAKME is an effort intended to provide a practical solution to knowledge management issues that characterize the architecture process and are discussed in the following section.
2. KM Problems in Architecture Processes The software architecture process involves knowledge-intensive activities such as architecture design, evaluation, and documentation. These activities consume or generate a significant amount of knowledge. Architects require topic knowledge (learned from text books and courses) and episodic knowledge (experience with the knowledge) [1]. One of the main problems in the architecture is the lack of access to knowledge underpinning the design process and decisions [7, 16]. This type of knowledge involves things like the impact of certain middleware choices on communication mechanisms between different tiers, why an API is used instead of a wrapper, and who to contact to discuss the performance issues.
Much of this knowledge is episodic and usually not documented [2]. The absence of a disciplined approach to capture and maintain architecture knowledge has many downstream consequences. These include: * the evolution of the system becomes complex and cumbersome, resulting in violation of the fundamental design decisions * inability to identify design errors * inadequate clarification of arguments and information sharing about the design artifacts and process, All these cause loss of substantial knowledge generated during the architecture process, thus depriving organizations of a valuable resource. Further, loss of key personnel may mean loss of knowledge [2, 17, 18]. The SA research community has developed several methods (such as ATAM [3], PASA [19]) to support a disciplined approach to architectural practices. Some of these methods emphasize the need for knowledge management. However, there is no approach that explicitly states what type of knowledge needs to be managed and how, when, where, or by whom to support architecture activities. Also, none of the current approaches provides any conceptual framework to design, develop and maintain an appropriate repository of architecture knowledge. Hence we posit that the lack of suitable techniques, tools, and guidance is why knowledge about design decisions is not captured and managed [15]. To address these issues, we have developed a framework for capturing and using architecture design knowledge. Elioit ...............t Requirents _I
_*Archito2ural
Desgn Arlhiteture
architecture design knowledge: generic architecture knowledge (such as general scenarios, patterns, quality attributes, design options and others), and project specific architecture knowledge (such as concrete scenarios, contextualized patterns, quality factors, architectural decisions and others). The generic knowledge is accumulated by capturing architecture knowledge using the techniques included in our framework for capturing and using architecture design knowledge [14]. This framework provides a conceptual guidance to design, develop and populate a knowledge repository to improve architecture processes. Figure 1 presents the conceptual framework for providing a knowledge repository support to different activities of architecture-based software development.
3. Knowledge Management Tool Support The Process-based Architecture Knowledge Management Environment (PAKME) is a prototype of a web-based system to provide knowledge management support for improving architecture activities. The PAKME has been built on top of an open source groupware platform, Hipergate [26], which provides various collaborative features such as contact management, project management, synchronous and asynchronous communication tools and other collaborative services, which we plan to use to support distributed architecture evaluation process [27]. We have modified the data model of the Hipergate to accommodate the artifacts (such as patterns, scenarios, tactics and others) that make up architecture knowledge [15]. We have also made modifications to the presentation and business logic tiers in order to add the features required to capture, retrieve and manage architecture design knowledge.
rnt
m
Achitecture
Analzm
ArdichIeufr
Relze
Arch'teture
Archiecture Knowedge RepasitorY GCnen'c Kn wledge
Kect-sped kr_wle
Ma inain
Archieture
Figure 1: A knowledge repository support for architecture-based software development. This framework incorporates concepts from KM [20, 21], experience factories [22, 23], and pattern-mining [24, 25] paradigms to provide an integrated support environment. The framework requires a knowledge repository, which is logically divided into two types of
DataStoe
Figure 2: Component view of PAKME' architecture
Currently PAKME consists of four components, which are shown in Figure 2. * User Interface - The only way to interact with the system is through a user interface that is integrated
*
*
*
*
into Hipergate's interface, which has been implemented using a combination of Java Server Pages (JSP) and HTML technologies. Knowledge management - This component provides common services to store, retrieve, and update artifacts that make up architecture knowledge such as patterns, scenarios, quality attributes and others. As we mentioned, the knowledge base is logically divided into generic knowledge, and project specific knowledge. This component also provides services to instantiate generic architectural artifacts into project-specific artifacts. For example, creating concrete scenarios to characterize quality attributes for a project based on general scenarios stored in the knowledge-based part of the repository. This component uses the services of a data management component to store, maintain, and retrieve architectural artifacts. Search - This component helps users search through the knowledge repository for desired artefacts. There are three types of search functions: keyword-based search, advanced search, and navigation-based search. Keyword-based search facility explores the repository for a desired artefact utilizing the key words that are attached as metadata to each artefact. Advanced search is based on a combination of logical operators (i.e. And, Or and Not), while navigation-based search means searching the artefacts based on the results of the two main searches functions. Navigational search is provided by presenting the retrieved artefacts as hyperlinks, which can be clicked to retrieve detailed information about them and other related artefacts. Reporting - This component provides the services for representing architectural knowledge to explicate the relationships that exist between different architectural artefacts or to show their positive or negative effects on each other. For example, a tactic-benefit matrix shows which scenarios can be achieved by using which patterns through the tactics applied by those patterns. The reporting component also supports architecture evaluation by helping stakeholders generate utility trees to specify quality attributes and presenting the findings of architecture analysis as a result tree, which categories the findings into risk themes. Data Management - This component provides all the services to store, maintain, and retrieve data from a persistent data source, which is implemented with PostgreSQL 8.0. The data management logic uses Postgres's scripting language.
4. Capturing and Using Architecture knowledge with PAKME This section describes how PAKME provides a support mechanism for capturing and using architecture design knowledge.
Currently, functionalities:
PAKME
implements
four
main
Knowledge acquisition. This component provides various forms and editing tools to enter new generic or project specific knowledge into the repository. * Knowledge maintenance. The maintenance component provides various features to modify, delete and instantiate different architectural artifacts. It also implements repository administration functions. * Knowledge retrieval. The retrieval component supports both basic and advanced searches to find and retrieve the desired pieces of architecture knowledge. * Knowledge presentation. This component supports generating different views of the architecture knowledge residing in the AKR. The main objectives of PAKME are to provide support mechanisms for knowledge capture, manage, and retrieval to improve the quality of architecture activities. It also acts as a knowledge source for those who need rapid access to experience-based design decisions to assist in making new decisions or discovering the rationale for past decisions. *
el pergate
Figure 3: Screenshot of entry page showing main features of PAKME
4.1 Supporting Knowledge Capture There are two main strategies to capture implicit architecture design knowledge from human sources (e.g. architects, domain experts and project teams): 1) appoint a knowledge engineer to capture implicit knowledge from individuals or teams [2, 28]
2) provide appropriate tool support so that knowledge can be encoded into the system as part of the knowledge creation process. The latter is called contextualized knowledge acquisition [29]. PAKME provides appropriate tool support to capture implicit knowledge to populate a knowledge repository by using either of these knowledge acquisition strategies. We have been using PAKME by embedding it into knowledge creation processes. That means architects/designers can use PAKME to store or search architecture knowledge (generic or projectspecific) during architecture design. Figure 3 shows the main paths that can be taken to use the knowledge repository. Generic knowledge can also be captured from secondary sources (such as design patterns and technical reports). We have populated PAKME's generic knowledge repository by capturing architecturally significant artifacts from architects of systems reported in [30] and several J2EE [31] patterns, architecture patterns [12], and the Battle Control System (BCS) case study described in [10]. The architecture knowledge elicited from human or secondary sources must also be structured and documented in a format that makes it a readily reusable architectural artifact and represent the captured architectural knowledge at level of abstraction that is more suitable to architectural level. We have designed a set of templates (see [24]) to document different units of architecturally significant information (i.e. general scenarios, quality attributes, tactics, usage examples and so on) as reusable artifact of architecture knowledge. PAKME implements these templates to helps users structure the captured knowledge before storing it into the repository. PAKME also provides various editing and updating features to facilitate knowledge maintenance.
Figure 4: An interface to store new pattern
Figure 4 shows an interface to store a new pattern in the AKR. While entering a new artifact, an end user can view the existing artifacts in the background as shown in Figure 4. For example, if a user's search fails to retrieve a specific artifact, the user may decide to create the one they need in the repository. Figure 5 shows the interface to modify an artifact stored in the repository using PAKME's knowledge maintenance features.
Figure 5: An interface to modify a stored pattern
4.2 Supporting Knowledge Use/Reuse We provide an illustrated example to demonstrate how PAKME facilitates architecture knowledge use/reuse. For example, an architect needs to design a suitable architecture for a new application that should satisfy certain non-functional requirements. The architect is likely to make architectural decisions using a common process - understanding the problem, identifying potential alternatives, and assessing their viability. There are a few ways PAKME can support this process. The architect can search the repository for architectural artifacts that can be reused. For example, the architect can use a particular quality requirement (e.g. performance) as a keyword to retrieve general scenarios that characterize performance. The architect decides to instantiate those general scenarios into concrete performance scenarios. These general scenarios can also help the architect to identify the patterns that can be used to satisfying the performance requirements. Moreover, those general scenarios can also lead the architect to identify a reasoning model that should be used to analyze architectural decisions. In this process, the architect can use PAKME's different search features: basic, advanced, and navigational based search. Figure 6
shows one of the outputs of such a search. The architect may decide to find out if similar problems have been solved in other project. He/she can browse through the existing projects for similar problems. One way of doing this is to find a similar project by looking at projects' description or performing a keyword-based or advanced search using quality attributes, scenarios, application type and similar meta-data.
Additionally, project-specific knowledge can also help designers, developers and maintainers to better understand the architectural decisions, their constraints and reasoning behind it. Availability of the reasoning behind the design decisions helps architects to explain architectural choices and how they satisfy business goals [9]. Such knowledge is also valuable during implementation and maintenance stages. PAKME's reporting component also supports knowledge use/reuse by generating different views of the architecture knowledge residing in the repository. The reporting component also supports several activities of architecture evaluation methods like ATAM [12] by helping visualize concrete scenarios in terms of utility tree (Figure 7) and categorizing the findings of architecture evaluation into different risk themes and representing them as a result tree (Figure 8).
iPeri
Figure 6: Various screens showing the results of search and navigation based retrieval.
Having found a similar project, the architect can retrieve the architecture design decisions taken, design options considered, rationale for choosing a particular design option, tradeoffs made, and findings of architecture evaluation. Such information can help the architect to decide whether the architecture decision can be reused or not and how much tailoring is required. Moreover, the utility and result trees (see Figures 7 & 8) provide an intuitive way of comprehending the implications of reusing an existing architecture decision.
WIodifiabiity EIChanie web [li < 2 wksl
E Newi nessage Idata tylwe < 1 wl E New me ssage folnat < moitll
IAvAibihty El Siuive single networkfailure E Hadwa e failure j< 5 rniniesI
Rcslt TIic E Ilsk Tl i
jisk
icil
p
-> Issul:e T1
Figure 8: A result tree of evaluation of the BCS system. PAKME supports architecture evaluation activity in many other ways as well. For example, an evaluator can use the general scenarios to stimulate stakeholders' thinking for gathering concrete scenarios or evaluating the suitability of certain patterns in the proposed architecture by matching the required concrete scenarios with the general scenarios extracted from that pattern. Moreover, modifications to major artifacts (such as architecture decisions) and revision reasons are logged for later review. Architecture decisions are also time stamped and annotated with the decision maker's details, which can be used to seek further explanation for a particular architecture decision.
5. Summary and Future work [Iediiuil,[Higl
[ThgJiJ [1OvDefJ
Figure 7: A utility tree of concrete scenario s.
Our research is aimed at improving the effectiveness of architecture-based software engineering by providing knowledge management support mechanism. We proposed a framework for capturing and using architecture knowledge. We have developed a tool, PAKME, to support that framework. This paper
discusses various architectural aspects and features provided by PAKME. We also describe different uses of the tool to improve the knowledge capture and use/reuse during architecting process. Future work includes enhancement of the tool with case-based approaches [29] and incremental refinement of search queries based on the results of the basic search. Furthermore, we plan to implement more functions, such as add architecture decision table and viewer architecture in reporting functionality. Additionally, we also plan to separate business logic and presentation logic by using EJB objects in order to over come the limitations inherited from the Hipergate. We are particularly keen to test the pattern-mining process and tool in industrial settings, so that their applicability and scalability can be thoroughly assessed. The preliminary results of our assessment of the patternmining process and the usefulness of the extracted knowledge are very encouraging [24]. These give us confidence in the utility of our approach. Acknowledgement - Several undergraduate students helped us build the tool. National ICTAustralia is funded through the Australian Government's Backing Australia's Ability initiative, in part through the Australian Research Council.
6. References [1] P.N. Robillard, The role of knolwedge in software development. Communications of the ACM, 1991. 42(1): pp. 87-92. [2] L.G. Terveen, et al., Living Design Memory: Framework, Implementation, Lessons Learned. Human-Computer Interaction, 1995. 10(1): pp. 1-37. [3] P. Clements, et al., Evaluating Software Architectures: Methods and Case Studies. 2002: Addison-Wesley. [4] P.B. Kruchten, The 4+1 View Model of architecture. Software, IEEE, 1995. 12(6): pp. 42-50. [5] P. Kruchten, The Rational Unified Process: An Introduction. 2nd ed. 2000: Addison-Wesley. [6] L. Bass and R. Kazman, Architecture-Based Development, Tech Report CMUISEI-99-TR-007, SEI, Carnegie Mellon University, Pittsburgh, 1999 [7] J. Bosch. Software Architecture: The Next Step. European Workshop on Software Architecture, 2004. [8] A.H. Dutoit and B. Paech, Rationale Management in Software Engineering, in Handbook of Software Engineering and Knowledge Engineering, S. Change, Editor. 2001, World Scientific Publishing, Singapore. [9] J. Tyree and A. Akerman, Architecture Decisions: Demystifying Architecture. IEEE Software, 2005. 22(2): pp. 19-27. [10] L. Bass, et al., Software Architecture in Practice. 2 ed. 2003: Addison-Wesley. [11] E. Gamma, et al., Design Patterns-Elements of Reusable Object-Oriented Software. 1995, Reading, MA: AddisonWesley. [12] F. Buschmann, et al., Pattern-Oriented Software Architecture: A System of Patterns. 1996: John Wiley & Sons.
[13] F. Bachmann, et al., Deriving Architectural Tactics: A Step toward Methodical Architectural Design, Tech Report CMUISEI-2003-TR-004, SEI, Carnegie Mellon University, USA, 2003 [14] M. Ali-Babar, et al. Capturing and Using Software Architecture Knowledge for Architecture-Based Software Development. Accepted in the 5th International Conference on Quality Software, 2005. [15] M. Ali-Babar, et al., A Framework for Supporting Architecture Knowledge and Rationale Management, in Rationale Management in Software Engineering, A.H. Dutoit, et al., Editors. 2006, to be published by Springer. [16] M. Ali-Babar, et al., A Framework for Supporting Architecture Knowledge and Rationale Management, in Rationale Management in Software Engineering, A.H. Dutoit, et al., Editors. 2005, Submitted for review. [17] T.R. Gruber and D.M. Russell, Design Knowledge and Design Rationale: A Framework for Representing, Capture, and Use, Tech Report KSL 90-45, Knowledge Systems Laboratory, Standford University, California, USA, 1991 [18] A.P.J. Jarczyk, et al. Design Rationale for Software Engineering: A Survey. Proc. 25th Hawaii Int'l. Conf on System Sciences, 1992. [19] L.G. Williams and C.U. Smith. PASA: An Architectural Approach to Fixing Software Performance Problems. Proc. of Int'l. Conference of the Computer Measurement Group, 2002. [20] G.J.B. Probst. Practical Knowledge Management: A Model That Works. Last accessed on 14th March, 2005, Available from:
[21] I. Rus and M. Lindvall, Knowledge Management in Software Engineering. IEEE Software, 2002. 19(3): pp. 26-38. [22] V.R. Basili and G. Caldiera, Improving Software Quality Reusing Knowledge and Experience. Sloan Management Review, 1995. 37(1): pp. 55-64. [23] V.R. Basili, et al., The Experience Factory, in Encyclopedia of Software Engineering, J.J. Marciniak, Editor. 2001, John Wiley & Sons. [24] M. Ali-Babar, et al. Mining Patterns for Improving Architecting Activities - A Research Program and Preliminary Assessment. 9th Int'l. conf on Empirical Assessment in Software Engineering, 2005. [25] L. Zhu, et al. Mining Patterns to Support Software Architecture Evaluation. 4th Working IEEEIIFIP Conference on Software Architecture, 2004. [26] Hipergate - Open Source CRM and Groupware. Last accessed on 16th April, 2005, Available from:
[27] M. Ali-Babar, et al. An Exploratory Study of Groupware Support for Distributed Software Architecture Evaluation Process. Proc. of the 11th Asia Pacific Software Eng. Conf , 2004. [28] B. Skuce, Knowledge management in software design: a tool and a trial. Software Engineering Journal, Sept. 995: pp. 183-193. [29] S. Henninger, Tool Support for Experience-Based Software Development Methologies. Advances in Computers, 2003. 59: pp. 29-82. [30] T. Al-Naeem, et al. A Quality-Driven Systematic Approach for Architecting Distributed Software Applications. Proc. of the 27th Int'l. Conf on Software Eng., 2005. [31] D. Alur, et al., Core J2EE Patterns: Best Practices and Design Strategies. 2nd ed. 2003: Sun Microsystem Press.
