Powered by
Workshop on SHAring and Reusing architectural Knowledge (SHARK 2011),
May 24, 2011,
Waikiki, Honolulu, HI, USA
Workshop on SHAring and Reusing architectural Knowledge (SHARK 2011)
Preface
Foreword
The SHARK workshop focuses on current and emerging methods, languages, notations, technologies and tools to create, extract, represent, share, use and re-use architectural knowledge. Architectural Knowledge (AK) is the integrated representation of the software architecture of a software-intensive system (or a family of systems), including the architectural design decisions, and the external context/environment. It is increasingly recognized as the means for architecture governance; it facilitates and supports collaboration and the transfer of expertise.
Architectural knowledge has been established within the software architecture community as a self-contained research area, and brought along some promising research directions. In this workshop we discuss the issues that lead to the application of architectural knowledge in research and industrial practice; ongoing research and new ideas to advance the field. In its five previous editions we examined: the state of the art and practice (2006), future challenges and trends (2007), architectural knowledge as perceived by different research communities, including requirements engineering, service-oriented computing and international standardization (2008), the application, experimentation, specialization and use of architectural knowledge theory and approaches (2009), and the Body of Knowledge of the Software Architecture community (2010).
In this sixth SHARK edition we plan to investigate the approaches for AK personalization, where knowledge is not codified through templates or annotations, but it is exchanged through the discussion between the different stakeholders. Therefore, the emphasis does not lie on resource-intensive documentation but on lightweight, just-in-time conversations facilitated by “knowledge yellow pages” (who knows what). The AK community has not explored AK personalization in depth, even though it has acknowledged its value as a viable approach. As SHARK is a discussion-intensive workshop, we will form small working groups that will discuss in detail the various aspects of AK personalization. The actual topics for discussion will be generated during the workshop with the following topics as a starting point: methods and tools for AK personalization, hybrid approaches (making the best of both personalization and codification), potential industrial practices or even full industrial case studies of AK personalization, and applying knowledge management theory of knowledge personalization.
Keynote
Software Designers, Are You Biased?
Antony Tang
(VU University Amsterdam, Netherlands)
Methods of representing and capturing design rationale have been studied in past years. Many meta-models, methods and techniques have been proposed. Are these software engineering methods sufficient to help designers make logical and appropriate design decisions? Studies have shown that people make biased decisions, software designers may also be subjected to such cognitive biases. In this paper, I give an overview of how cognitive biases and reasoning failures may lead to unsound design decisions. I conjecture that in order to improve the overall quality of software design, we as a community need to improve our understanding and teaching of software design reasoning.
@InProceedings{SHARK11p1,
author = {Antony Tang},
title = {Software Designers, Are You Biased?},
booktitle = {Proc.\ SHARK},
publisher = {ACM},
pages = {1--8},
doi = {},
year = {2011},
}
Full Papers
Architecting with Just Enough Information
Robert L. Nord, Nanette Brown, and
Ipek Ozkaya
(SEI/CMU, USA)
We learned an important lesson recently about breaking down barriers among architects, developers, and other stakeholders when we were engaged on a project and were challenged to deliver the architecture in smaller increments and shorter iterations. We learned how information was used and exchanged among key players participating in the software development process and are seeking to formalize our understanding through principles of workflow from lean software development and how architecture knowledge management can influence defining an appropriate architecture batch size for effective incremental development.
@InProceedings{SHARK11p9,
author = {Robert L. Nord and Nanette Brown and Ipek Ozkaya},
title = {Architecting with Just Enough Information},
booktitle = {Proc.\ SHARK},
publisher = {ACM},
pages = {9--12},
doi = {},
year = {2011},
}
Building Roadmaps: A Knowledge Sharing Perspective
Antony Tang, Taco de Boer, and Hans van Vliet
(VU University Amsterdam, Netherlands; Océ Technologies, Netherlands)
Roadmapping is a process that involves many stakeholders and architects. In an industry case, we have found that a major challenge is to exchange timely knowledge between these people. We report a number of knowledge sharing scenarios in the roadmapping process. In order to address these issues, we propose a codification mechanism that makes use of a semantic wiki to facilitate knowledge sharing.
@InProceedings{SHARK11p13,
author = {Antony Tang and Taco de Boer and Hans van Vliet},
title = {Building Roadmaps: A Knowledge Sharing Perspective},
booktitle = {Proc.\ SHARK},
publisher = {ACM},
pages = {13--20},
doi = {},
year = {2011},
}
Goals, Questions and Metrics for Architectural Decision Models
Marcin Nowak and Cesare Pautasso
(University of Lugano, Switzerland)
Architectural decisions are the key element behind the design process leading to a software architecture. Making software architects aware of the implications of their decisions is only the beginning of what can be achieved by capturing the rationale and the constraints influencing the decision making process in a reusable body of architectural knowledge. In this paper we propose a metric-based approach to the analysis of architectural decision models. Using a hierarchically-structured approach we identify a number of useful goals and stakeholders involved in the architectural design process. Next, we sketch a set of metrics to provide data for the evaluation of the aforementioned goals. Our aim is to stimulate a discussion on how to find indicators relevant for software architects by measuring the intrinsic properties of architectural knowledge.
@InProceedings{SHARK11p21,
author = {Marcin Nowak and Cesare Pautasso},
title = {Goals, Questions and Metrics for Architectural Decision Models},
booktitle = {Proc.\ SHARK},
publisher = {ACM},
pages = {21--28},
doi = {},
year = {2011},
}
Using Rationale to Drive Product Line Architecture Configuration
Janet E. Burge, Gerald C. Gannod, and Holly L. Connor
(Miami University, USA)
The process of designing and building a software system requires making many decisions. These decisions, the al-
ternatives considered, and the reasons behind the choices comprise the rationale for the completed system. The driv-
ing force behind many, if not most, of these decisions is the need to meet the stakeholder requirements for the system
being developed. Software product line approaches allow developers to design and develop families of products that
share a common platform of behaviors and infrastructure. These approaches are based on assembling a configuration
of a set of common features (commonalities) along with a set of product specifific features (variabilities) to form a new
product with a low amount of effort. In this context, these variabilities represent a wide variety of potential design al-
ternatives. The goal of our research is to bring the end-user into the process of configuring a software product through
the use of system level rationale that maps product line features to system requirements. Specifically, in our approach
we specify rationale at the level of a feature diagram. Accordingly, we are taking advantage of the natural correlation
between alternative features in a feature diagram and the alternative structure used in design rationale. This allows
the end-user to indicate which requirements apply to their product and to have that selection generate a set of product
features that satisfy those requirements.
@InProceedings{SHARK11p29,
author = {Janet E. Burge and Gerald C. Gannod and Holly L. Connor},
title = {Using Rationale to Drive Product Line Architecture Configuration},
booktitle = {Proc.\ SHARK},
publisher = {ACM},
pages = {29--36},
doi = {},
year = {2011},
}
Codifying Architecture Knowledge to Support Online Evolution of Software Product Lines
Danny Weyns and Bartosz Michalik
(Katholieke Universiteit Leuven, Belgium)
A company's architecture knowledge is often personalized across specific people that share experience and knowledge in the field. However, this knowledge may be important for other stakeholders. Omitting the codification of the architecture knowledge may result in ad-hoc practices, which is particularly relevant for software evolution. In a collaboration with Egemin, an industrial manufacturer of logistic systems, we faced the problem with a lack of codified architecture knowledge in the context of the evolution of a software product line (SPL). In particular, maintainers lack the architecture knowledge that is needed to perform the evolution tasks of deployed products correctly and efficiently. Ad-hoc updates increase costs and harm the company's reputation.
To address this problem, we developed an automated approach for evolving deployed systems of a SPL. Central in this approach are (1) a meta-model that codifies the architecture knowledge required to support evolution of a SPL, and (2) and algorithm that uses the architecture knowledge harvested from a deployed system based on the meta-model to generate the list of tasks maintainers have to perform to evolve the system. Evaluation of the approach demonstrates a significant improvement of the quality of system updates with respect to the correct execution of updates and the availability of services during the updates.
@InProceedings{SHARK11p37,
author = {Danny Weyns and Bartosz Michalik},
title = {Codifying Architecture Knowledge to Support Online Evolution of Software Product Lines},
booktitle = {Proc.\ SHARK},
publisher = {ACM},
pages = {37--44},
doi = {},
year = {2011},
}
Transforming Trace Information in Architectural Documents into Re-usable and Effective Traceability Links
Mehdi Mirakhorli and Jane Cleland-Huang
(DePaul University, USA)
Architectural analysis processes, such as the Architecture
Trade-off and Analysis Method (ATAM), utilize a scenario
based approach to evaluate the extent to which an architectural
solution meets a potentially competing set of quality
goals. The resulting architectural documents contain a rich
set of trace relationships between quality goals, decisions,
and architectural elements. Unfortunately this information
is not readily accessible for supporting tasks other than initial
architectural assessments. In this paper we describe a
technique and supporting tools for extracting and generating
traceability links from the architectural documents. A
specialized Traceability Information Model is used to guide
the user through the task of establishing traceability links
from design decisions to the architectural elements in which
the decision is realized. The retrieved and generated traceability
links can then be used to support a far broader set
of activities including visualization of design rationale and
architectural preservation. We evaluate our approach using
a case study of the NASA Crew Exploration Vehicle.
@InProceedings{SHARK11p45,
author = {Mehdi Mirakhorli and Jane Cleland-Huang},
title = {Transforming Trace Information in Architectural Documents into Re-usable and Effective Traceability Links},
booktitle = {Proc.\ SHARK},
publisher = {ACM},
pages = {45--52},
doi = {},
year = {2011},
}
Poster
Using Code Analysis Tools for Architectural Conformance Checking
Jo Van Eyck, Nelis Boucké, Alexander Helleboogh, and Tom Holvoet
(Katholieke Universiteit Leuven, Belgium)
@InProceedings{SHARK11p53,
author = {Jo Van Eyck and Nelis Boucké and Alexander Helleboogh and Tom Holvoet},
title = {Using Code Analysis Tools for Architectural Conformance Checking},
booktitle = {Proc.\ SHARK},
publisher = {ACM},
pages = {53--52},
doi = {},
year = {2011},
}
proc time: 0.02