WICSA 2009 WS5 -- Architecture Knowledge 2 -- Decisions and Rationale

From WICSA Conference Wiki

Jump to: navigation, search

Session Chairs: Paris Avgeriou and Eltjo Poort

Wednesday, 16th September, 13:30 - 15:30

Contents

Participants (Tentative)

Please sign your name here if you are thinking of attending this BoF. (Click the signature button in the editor). Tell us something about your background. Add a few sentences about the working session topic such as your position, questions you would like to see discussed, etc.
  • Peng Liang, University of Groningen. What's the core of architectural design decision, what's the relationship between decision and rationale.
  • Ulrik Eklund, Chalmers Univ. of Tech./Volvo Car Corporation. How to to identify implicit decisions and what about "inherited" decisions?
  • Patrick Könemann, Technical University of Denmark. Design decision support in model-driven software development.
  • Rafael Capilla, Universidad Rey Juan Carlos (Madrid). Strategies to embed design rationale in software modeling tools.
  • Paris Avgeriou, University of Groningen (the Netherlands). Transferring research results into the industry - especially establishing a repository for sharing architecture knowledge.
  • Olaf Zimmermann, IBM Research - Zurich. Initiator and principal investigator of the SOAD project, an indistrial resear4ch and knowledge engineering project.

Papers

  • "Architectural Design Decision: Existing Models and Tools", by Mojtaba Shahin, Peng Liang and Mohammad Reza Khayyambashi
    In the field of software architecture, there has been a paradigm shift from describing the outcome of architecting process mostly described by component and connector (know-what) to documenting architectural design decisions and their rationale (know-how) which leads to the production of an architecture. This paradigm shift results in emergence of various models and related tools for capturing, managing and sharing architectural design decisions and their rationale explicitly. This paper analyzes existing architectural design decisions models and provides a criteria-based comparison on tools that support these models. The major contribution of this paper is twofold: to show that all of these models have a consensus on capturing the essence of an architectural design decision; and to clarify the major difference among the tools and show what desired features are missing in these tools.
  • "Integrating Decision Management with UML Modeling Concepts and Tools", by Patrick Könemann
    Numerous design decisions including architectural decisions are made while developing a software system, which influence the architecture of the system as well as subsequent decisions. Several tools already exist for managing design decisions, i.e. capturing, documenting, and maintaining them, but also for guiding the user by proposing subsequent decisions. In model-based software development, many decisions directly affect the structural and behavioral models used to describe and develop a software system and its architecture. However, the decisions are typically not connected to these models. In this paper, we propose an integration of a decision management and a UML-based modeling tool, based on use cases we distill from an example: the UML modeling tool shall show all decisions related to a model and allow extending or updating them; the decision management tool shall trigger the modeling tool to enforce design decisions (modify the models). We define tool-independent concepts and architecture building blocks supporting these requirements and present first ideas how this can be implemented in the IBM Rational Software Modeler and Architectural Decision Knowledge Wiki. This seamless integration of formerly disconnected tools could improve tool usability as well as decision maker productivity.
  • "Embedded Design Rationale in Software Architecture", by Rafael Capilla
    The increasing interest to consider design decisions and its rationale as an inherent part of the software architecture development process has led to a number of research works that promote the capturing and use of the architecturally significant decisions. Hence, the stakeholders can keep track of the reasons of changes. This paper explores a variety of initiatives from previous works and advocates for an "embedded use of design rationale" in software architecting activities with tool support.

(paper moved from WS4) *"The Anatomy and Physiology of the Grid Revisited", by Chris A. Mattmann, Joshua Garcia, Ivo Krka, Daniel Popescu, and Nenad Medvidovic

  • In this paper, we revisit the widely cited domain-specific software architecture (DSSA) for the domain of grid computing We have comprehensively studied 18 grid systems over the past five years, observing that, while individual grid systems are widely used and deemed successful, the grid DSSA is underspecified and makes it difficult to pinpoint what makes a software system a grid. Inspired by this conclusion, we describe our work-in-progress towards answering this important question.

Contributions

If you have relevant materials or references, please add here:

A text book about Software Architecture Knowledge Management is now available. Some of the editors and chapter authors attended the working session.

The SOA Decision Modeling (SOAD) Project has produced decision modeling concepts, a model instance for SOA design (about 500 recurring issues and alternatives), as well as related tooling. This is the project homepage. The latest and most complete paper describing the project is a contribution to the JSS special issue on architectural decisions. SOAD was also featured in a WICSA/ECSA 2009 tutorial on Monday morning. See main conference page WICSA_ECSA_2009.

Direct link to last year's working session: WICSA2008 WS2 Knowledge

The following paper was originally accepted for this working session, but the authors were unable to attend:

  • "A Model to Represent Architectural Design Rationale", by María Celeste Carignano, Silvio Gonnet and Horacio Leone
    When developing a software system, its architecture must be considered so that it can be understood, updated, and improved. In general, considering the architectural artefacts is not enough. The reasons, assumptions and justifications bore in mind by the architects during the architecture design stage must be also known. Nevertheless, not all aspects analysed during the design process can be identified, especially all those alternatives that were evaluated and rejected. In the present contribution, a model to represent the rationale generated by architects during the architectural design is proposed so that it can last over time and it can be retrieved, analysed and reused whenever necessary. The model includes concepts representing architectural artefacts, reasons, assumptions, and decisions and reasoning elements status.

Working Session Details

Welcome to the working session on Architectural Decisions and Rationale.

Goal

Exploring obstacles to capturing AD&R. What is preventing real-life architects from doing this, and how can we help overcoming these obstacles?

Related questions:

  1. Paris: would like to discuss what happens after the knowledge is captured: how to spread it in practice? Through a repository?
  1. Rafa: we need to highlight the lacks of current commercial and research tools supporting ADD and define better the steps of the reasoning process in architecting, and what is needed to develop a second generation of tools, that include design rationale in architecture, more suitable to software modelers.

Working Session Agenda

  1. Introduction (10min)
  2. 4 10-minute paper presentations (40min)
  3. Brainstorm on obstacles in AD&R capture and use (20min)
  4. Gathering ideas on helping overcome obstacles identified in previous step (40min)
  5. Wrap-up (10min)

Results

Identified obstacles preventing AD&R capture and use in real-life situations:

  1. The Architect
    1. Decisions made by subconsciousness
    2. Blocking creativity
    3. Unaware of making decisions
    4. Unwillingness to share/reveal expertise
  2. Intrusiveness
  3. Tacit rationale
  4. Diversity of decision types/classes
  5. No perceived value
    1. Benefit in future only


Ideas for overcoming these obstacles raised during working session:

  1. Make assumptions about decision-making explicit
  2. Processes/methods/tools that support:
    1. Decision Capture after design
      1. Analysis
      2. Parking space highlight issue
      3. Making tacit rationale explicit
    2. decision making based on incomplete information
    3. multi-genre decisions
      1. Mind-map like modelling?
    4. decision evolution
    5. Group decision making
  3. Education
    1. Reflection
    2. Reasoning
    3. Show good/bad rationale
  4. Architecture Process
  5. Gather historical information
    1. What went wrong / right
    2. Including maintenance phase
  6. Document decision models for Reference Architectures
  7. Have EA make principles about capturing AD&R
Retrieved from "http://wwwp.dnsalias.org/wiki/WICSA_2009_WS5_--_Architecture_Knowledge_2_--_Decisions_and_Rationale"
Personal tools