Workshop SHARK 2011 – Author Index |
Contents -
Abstracts -
Authors
|
Boucké, Nelis |
![]() Jo Van Eyck, Nelis Boucké, Alexander Helleboogh, and Tom Holvoet (Katholieke Universiteit Leuven, Belgium) ![]() |
|
Brown, Nanette |
![]() 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. ![]() |
|
Burge, Janet E. |
![]() 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. ![]() |
|
Cleland-Huang, Jane |
![]() 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. ![]() |
|
Connor, Holly L. |
![]() 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. ![]() |
|
De Boer, Taco |
![]() 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. ![]() |
|
Gannod, Gerald C. |
![]() 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. ![]() |
|
Helleboogh, Alexander |
![]() Jo Van Eyck, Nelis Boucké, Alexander Helleboogh, and Tom Holvoet (Katholieke Universiteit Leuven, Belgium) ![]() |
|
Holvoet, Tom |
![]() Jo Van Eyck, Nelis Boucké, Alexander Helleboogh, and Tom Holvoet (Katholieke Universiteit Leuven, Belgium) ![]() |
|
Michalik, Bartosz |
![]() 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. ![]() |
|
Mirakhorli, Mehdi |
![]() 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. ![]() |
|
Nord, Robert L. |
![]() 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. ![]() |
|
Nowak, Marcin |
![]() 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. ![]() |
|
Ozkaya, Ipek |
![]() 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. ![]() |
|
Pautasso, Cesare |
![]() 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. ![]() |
|
Tang, Antony |
![]() 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. ![]() ![]() 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. ![]() |
|
Van Eyck, Jo |
![]() Jo Van Eyck, Nelis Boucké, Alexander Helleboogh, and Tom Holvoet (Katholieke Universiteit Leuven, Belgium) ![]() |
|
Vliet, Hans van |
![]() 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. ![]() |
|
Weyns, Danny |
![]() 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. ![]() |
20 authors
proc time: 0.03