WICSA 2009 WS6 -- Architecture Design

From WICSA Conference Wiki

Jump to: navigation, search

Session Chairs: David Garlan and Bob Schwanke

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

Contents

Participants

Please sign your name here if you are thinking of attending this Working Session. (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.
  • --Bob Schwanke, Siemens Corporate Research. Design conformance can and should be spot-tested, early and often.
  • --Shaun Laurens, E.ON Energy Trading SE.
  • --David.Garlan 19:46, 4 September 2009 (EDT) Carnegie Mellon University. I will be leading this working session with Bob Schwanke. The four papers in this session promise to provide an interesting collection of perspectives to seed the discussion. I would be interested in hearing from potential participants what kinds of topics they would like to see discussed in this session. Here are some that I would find interesting:
    • What is the current state of the practice in architecture design methods, notations, and tools?
    • What are the current gaps in technology and process, which if bridged could enable a substantial improvement in the state of the practice?
    • What are the scientific, technical, and engineering challenges that must be addressed to bridge those gaps?
    • What is the impact of specific domains on architectural design? Does it even make sense to try to find general-purpose solutions?
    • How does the ubiquitous nature of frameworks, middleware, and legacy systems change the equation for architecture design?
  • Prabhakar TV, IIT Kampur, teach in university, process of architecture design (doesn’t exist)
  • Thorsten Keuler, Fraunhofer Instititute, design use cases that show real benefit to customer
  • Samuil Angelou – Eindhoven – software reference architectures -- What do you want to design in a reference architecture, and how do you do this?
  • Rafael Pino – Columbia; Gap between requirements, specification and design
  • Richard Mordinyi, Vienna University of Technology, grad student, coordination of complex systems, changing business requirements affect design in client applications
  • Alejandro Salamanca, Columbia, existing design methods still effective
  • Shaun Laurens, energy utility, architect, handling change that surrounds the architecture.
  • Henry Muccini, Univerisity of L’Aquila, Italy, Software architecture-based testing, model checking, fault tolerance, interoperability among architecture related tools.
  • Jennifer Perez, TU Madrid, architecture design and software product lines, testing architectures.
  • Raghu Sangwan, Penn State, SCR, Characterize structural complexity and compare it across systems developed with different methodologies. (Incidental and accidental complexity).
  • David Ameller, TU Catalonya, grad student, model driven development with non-functional requirements.
  • Matt Staples, NICTA and UNSW, Australia, business adaptation, component architectures for embedded systems

Papers

  • "Generate and Test as a Software Architecture Design Approach", by Len Bass
    In the last several years, the concept of a design decision has become important in the software architecture design community. A design decision begins with an issue and then focuses on the alternative solutions and the rationale for these solutions. The question of where the issues come from is not usually addressed within this approach.
    In this paper, we present a "generate and test" approach to design. If the design process is viewed as a generate and test process, then the set of questions that must be answered include where does the initial hypothesis come from, what are our test cases for any hypothesis, and how is the next hypothesis generated. slides
  • "Introducing Aspect-Oriented Space Containers for Efficient Publish/Subscribe Scenarios in Intelligent Transportation Systems", by Eva Kühn, Richard Mordinyi, Laszlo Keszthelyi, Christian Schreiber, Sandford Bessler and Slobodanka Tomic
    The publish/subscribe paradigm is a common concept for delivering events from information producers to consumers in a decoupled manner. Some approaches allow durable subscriptions or the transportation of events even to mobile subscribers in a dynamic network infrastructure. However, in the safety-critical telematics durable delivery of events is not sufficient enough. Short network connectivity time and small bandwidth limit the number and size of events to be transmitted hence relevant information needed for safety-critical decision making may not be timely delivered.
    In this paper we propose the integration of publish/subscribe systems and Aspect-oriented Space Containers (ASC) distributed via Distributed Hash Tables (DHT) in the network. The approach allows storage, manipulation, pre-processing, and prioritization of messages sent to mobile peers during bursts of connectivity.
    The benefits of the proposed approach are (a) less complex application logic due to the processing capabilities of Space Containers, and (b) increased efficiency due to delivery of essential messages only aggregated and processed while mobile peers are not connected. We describe the architecture of the proposed approach and explain its benefits by means of an industry use case.


  • "Layered Architecture Revisited — Comparison of Research and Practice", by Juha Savolainen and Varvana Myllärniemi
    Organizing a software architecture into layers has been one of the earliest architectural styles ever used. Even today layered structure is a very common architectural style used in various industrial systems. However, we have observed that the usage of layered architectural style varies greatly in different contexts. This paper aims to compare the notion of software architecture layers in research literature as well as in industrial practice. Firstly, we performed a systematic literature review of research articles on layered software architectures; we also reviewed selected books of software architecture. Secondly, to understand the practice, we investigated a number different recent architecture documents to cover the current usage of layered architectures. Our results indicate that there is very little actual research done on layered architectures. The current usage of layered structures seems to be more complex than reported before. This gap between the research and practice needs to be bridged by researchers.
  • "Interaction-Sensitive Synthesis of Architectural Tactics in Connector Designs", by Thorsten Keuler and Christian Webel
    During architectural design, the architect has to come up with architectural structures and tactics that aim at the fulfillment of quality attribute requirements. Architectural structures are built from component and connector types that define how components are supposed to interact. Since connector types typically impact big portions of a system, tactics usually crosscut connector designs and demand for modularized treatment during architecutre design. The synthesis of tactics within connector designs, however, turns out to be a major challenge. This is due to the fact that they are likely to affect each other in the final system where they need to be mutually integrated. This mutual affection is called tactic interaction. In this paper, we describe an approach towards detecting such tactic interactions during connector design. Our approach is integrated in a commercial architecture design tool supporting interaction-sensitive synthesis of architectural tactics during connector design activities.

Contributions

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

Working Session Details

Welcome to the working session on Architecture Design.

Goal

The guiding principle for this working session is quite straightforward:


Strategy

To achieve this goal we ...

Discussion

Sorry that these notes are very raw. Please improve.--Bob Schwanke 03:49, 17 September 2009 (EDT)

Design goes from General to specific

  • Design in general
  • Architectural design – Bass, connectors design
  • Arch for families of systems – Pub-Sub, Layers
  • Arch for products in particular domain – Aspect oriented space containers

Len Bass

  • Describing what people already do in a slightly different way.

Thorsten Keuler

  • How sensitive is approach to the type of connector you start with?
  • Why restricted to connectors?
    • Even though the idea is clearly geared towards the alteration of connectors, it inevitably has an effect on the structure of components that are involved when applying or modifying architectural tactics. However, since one goal of the research is to enable early estimates of run-time properties, the efficient generation of alternative connector designs that can be probed (tested) for the fulfillment of quality attributes, the connectors are the bottleneck in that generation process.
  • Have you used existing ADL’s from the literature, or just the concepts (e.g. from AOADL)
    • The point of describing the result in terms of an (AO)ADL is not the main target here, it is more the process of design that is addressed. What we want to be answered is the question: How to guide the architect in an efficient and effective way to reach the goal of having reasonable design decision to document (by means of an ADL).

Tomi Männistö – Layers, Revisited
(feel free to contribute and correct)

  • Questions, initially from the presentation
    1. How solid is the foundation on top which research and practice on architectural layers is built
      • The literature review on layers did not return too many papers
      • A limited case study found an example exceeding the state-of-the-art
    2. Definition of layer
      • Just an hierarchical organisation or should it bear some architectural design decisions?
      • When an architectural style has been defined and published at some point in time will it stay like that forever?
      • Should it evolve, or should we come up with a new name?
      • Should there be a taxonomy of all sort of layers
    3. As single systems do have multiple layerings
      • Should researchers investigate and revise the layer style?
      • Should practitioners define more complex structural representations as they see fit (and call them something else)
  • Some discussion points raised
    • Why layers - selected as they are pretty widely used in practice and yet what is meant by a layer seems to vary remarkably. But the same questions asked here for the layers are certainly relevant to other styles as well.
    • Is tier a different animal or should tiers be included in the review - were not in this study.
      (tier in Deutsch means animal in Englisch, but no pun was intended)
    • The role and need for layers as a separate concept in addition to modularity in general (this is probably not accurate and is anyway missing some references mentioned).
    • The reasons for extending the layering with additional concepts and constructs; why not simply abstract them away, as you are abstracting anyway. In the practical examples the reasons for what kind of things are in the diagram boiled down to what the architects wanted to communicate with the architecture description.

Publish Subscribe with Aspect-Oriented Space Containers

Hearing incremental improvements to architecture design methods.

  • Does system-of-systems problem change the way we think about architecture?
  • If we could measure our quality attributes, could we do better architecture?
    • Important Quality Attribute: Continuous integration and build, with confidence that the system is still working.

Some responses to David's pre-workshop questions:

  • What is the current state of the practice in architecture design methods, notations, and tools?
    • I (Bob) think that the biggest problem in architecture design is still requirements. Our requirements, including legacy software, define the starting point for design.
    • Design is definitely a search process. "Generate and Test" is one kind of search, but it some sense it uses "means-ends analysis" to assess the gap between the partial solution and the desired endpoint, then add something to the design that brings it closer to the endpoint. Is that hill-climbing? But evaluation (testing) of the partial solution is necessary to determine unintended interactions between design decisions.
  • What are the current gaps in technology and process, which if bridged could enable a substantial improvement in the state of the practice?
    • Assessing conformance of the implementation to the architecture models
    • Quantifying architecturally-significant quality attributes
  • What are the scientific, technical, and engineering challenges that must be addressed to bridge those gaps?
    • Partial automation of conformance checking
    • Instrumentation of quality attribute measurement
  • What is the impact of specific domains on architectural design? Does it even make sense to try to find general-purpose solutions?
    • Not addressed yet
  • How does the ubiquitous nature of frameworks, middleware, and legacy systems change the equation for architecture design?
    • Architect, in many cases, cannot even consider building something he needs, and isn't even a big enough customer to influence the future development (or stability) of the subsystems he buys. Instead, he has to plan for the expected variation in COTS components.
Retrieved from "http://wwwp.dnsalias.org/wiki/WICSA_2009_WS6_--_Architecture_Design"
Personal tools