WicsaWikiWANParty:WS3

From WICSA Conference Wiki

Jump to: navigation, search

Evolving Architectures II

Image:DSC 0071.jpg

WICSA WS3 chair Paola Inverardi and participants Cristóvão Oliveira and Jan Bosch

CONTEXT and MOTIVATION

CommUnity:

  • A language for parallel program design
  • Style of Unity
  • Based on action sharing
  • Supports the complete separation of "coordination" from "computation" concerns
  • Our aim is an attempt to making a clear separation of "distribution" and "mobility" from the two dimensions above
  • Provides a paradigmatic architectural description language in which connectors are first-class entities

CommUnity Workbench:

  • A graphical integrated development environment
  • CommUnity designs can be written, run, and debugged

Further information can be found in the CommUnity and participant websites.

Session Summary by User:David Wile and Paola Inverardi

Discussion

  • Two presentations
    • Francois Vermaut: (Namur) on quality attribute-based refinement
    • Cristovao Oliveira (Lisbon) on mobility
  • Axes for comparison
  • Discussion

Axes of Comparison for Evolution

  • Orthogonal views help to clarify what is evolving
  • Help to classify different ADLs and frameworks
  • Each will describe a surface in 4-space
    • E.g. Acme
    • Style-based evolution, strongly constrained while allowing full modification (creates)
    • Run-time dynamism topologically constrained (only) while allowing full modification

Axis 0: Types of Change

  • Instantiate / Replicate
  • Refine
  • Substitute
  • Modify
  • Create

I don't think we should consider "refine" as separate, easier type of change than "Modify". In my sense, refinement almost always imply a modification. For example, the refinement of a component in order to add some value to it, will make its interface change (to reflect this value adding), and may thus also change the connectors attached to this interface... The case study in my article (Attribute-based refinement of Software Architecture) shows such a case. --Francois Vermaut

Axis 1: Evolution Grain-size

  • Style or Product Line Design Time
  • Architecture Design Time
  • Architecture Implementation Time
  • Architecture Instantiation / Assembly Time
  • Run-time

All of these variants of changes, or architecture evolution are challenges for reseach and practice. The perhaps major challenge is that changes in an architecture (in the sense "components and connectors") occur at all the above mentioned levels for each and every software system. The long-term objective for software architecture research must be to provide methods, notations etc. that not only address one of these types of change but all. --Rikard Land


Axis 2: Constraint Level

  • Core (Syntactic)
  • Constrained (Type Checked)
  • Compiled (Locally analyzed)
  • Closed (Globally analyzed)

Axis 3: Machine Accessibility

  • Reflective
  • Indexed
  • Raw

Discussion Summary

  • YAWN :-( Axes determined not to be of any interest to the group
  • JAN :-) Problems were more fundamental.
  • Essentially 3 threads:
    • Definitional problems
    • Industrial desiderata not met by architecture descriptions
    • Expanded notion of architecture needed

Definitional problems

  • Jeff Magee: the architecture shouldn’t evolve. The architecture is what you can count on not needing to evolve.
  • Paola: Early on you fix the knowledge you can assume and build on this.
  • My paraphrase: the largest invariant of the system.

Industrial Needs

  • Jeff: (from Working Session I): Internet protocol is an architecture that hasn’t evolved a bit.
  • Andre Postma (Philips): centralized database hard to change

Nokkia? (name?): moved from tightly-coupled to loosely-coupled

  • My observation: this is like the move to XML from OO – give up constraints for flexibility

Expanded Concerns

  • Jan: quality concerns should be part of the architecture spec, including the design decisions (evolution records their introduction and removal).
  • David Garlan: expand architecture specifications to include user context and environment
  • My paraphrase: Situated-User Model
  • Paola: architecture includes vertical slice into the implementation infrastructure

Some Thoughts

  • Taking “largest invariant” to heart
  • Architecture is not the invariant, but the supporting fabric that you think will achieve it
  • Might need to include aspects like qualities to be preserved and situational awareness
    • How is this done in building architecture?
    • Perhaps the design makes the qualities “apparent,” e.g. light and airy, solid foundation, open, etc.
    • Use styles that exhibit the desired properties – situated GUIs, security envelopes, etc.
  • FUN STUFF!
Retrieved from "http://wwwp.dnsalias.org/wiki/WicsaWikiWANParty:WS3"
Personal tools