Working Group Summaries

WICSA Wrap-Up

Leadership

Senior technical leadership

Impression

Technical

Technical tools forsoftware systemstructure

“We need more – it’s not good enough yet”

“This is what architects really do –help us here too”

General observations

WICSA WCRE interaction workedWe’re stretching the bounds of “software architecture” Architects are senior technical leaders Architecture of the software part is hard to

separate from architecture of the system

Participation from practicing architects has led to outstanding discussions As a researcher, I really, really appreciate

this Please tell the organizers how to extend this

Working Groups

Education Hans van Vliet and

Mary Shaw

Quality Len Bass

Architecting Christine Hofmeister

Evaluation & Analysis David Garlan

ADLs in Practice Eóin Woods

Documentation in Practice Paul Clements

Components and Services Ivica Crnkovic

Architectural Design Decisions Jeff Tyree

WG Education

Focus: curriculum guidelines for a variety of students

Generated version 0 of a traceability matrix

Numbers: based on Bloom’s taxonomy

Level

Topic

CSundergr

new programmer

new architec

t

people skills

0 3 3-5

business

0 1 3

arch techn

1 2 4

reqs eng

1 1 5

programming

2 4 2

basic SE

1 3 5

some domain

1 1 5

WG Quality

Similarities/differences among quality attributes 3 essential elements: stakeholder, system, concern QAs are all interrelated and there does not yet exist

an orthogonal basis for defining QAs. Each QA has a cost and a value in achieving.

QAs change form as you change abstraction level power (system level) idle mode (software side)

Study measuring stability of architecture and relating it to causes and impacts would be useful. Stability could be caused by: System death Getting architecture correct Fragility and fear of change

WG Architecting

Agile methods: pose neither new problems nor new solutions for architecting. Documentation: Reverse engineering architecture from code will never

suffice. Things such as rationale are simply not present in code.

Can’t rely on the architect’s memory, and video tapes, digital snapshots, etc. are not descriptive enough.

There is no substitute for architecture documentation.

Architect’s role: The architect must code; must be the “first among equals” in order to achieve good team morale.Patterns/styles help, need better tool support

WG Evaluation and Analysis

Objectives: Understand how to improve our ability to model and evaluate architectures.Representative issues: How much architecture is enough? How many

architects and architectural roles are needed in an organization?

How do you identify the 5 top architectural issues for a system?

How do we extract architecture patterns from code?

How do we model architectures for mobile/pervasive systems?

What properties do you evaluate? Why?

WG ADLs in Practice

Why aren’t ADLs used in practice? Restrictive

assumptions Single view(point)-

oriented Lack of tool support Lack of domain

focus Lack of “rollout

plan” and tech transfer

What to change? Linkage to technology Specialise with domain-

specifics User studies

what do architects really do/need?

Simple tool support Visio, MagicDraw, Visual

Studio, eclipse Graphical presentation

support Improve tech transfer by

aligning with trends

WG Documentation in Practice

Enforcement/traceability: Structuring/supporting architecture documentation for consistency of architecture & implementation?Tooling: What would a superb architecture documentation tool look like and what services would it provide?

Multi-view consistency checking & “round-trip engineering” to code

Inhibitors: why isn't documentation universally produced? What are the inhibiting factors?

Need to focus on “just in time” architecture documentation What do I produce now, and for whom, to deliver best value?

Documentation uses: Can it ever take the place of a person? Does the role of documentation include protecting the project

from architects who walk in front of busses?UML and architecture: How could UML be a true ADL?

Views as first-class concepts. A long list of other things. Should we worry about other

languages on their own merits and translate those to UML?

WG Components and services

Paper presentations Demonstration of (automatic) creation of connectors for

different reasons (coordination protocols, providing different services, etc.)

Which unwanted properties these connectors bring (performance, resource usage, timing behavior)??

How to predict the system behavior when including such connectors?

General discussion What characterizes differences between component-

based and service-oriented approach? SOA: objects, or not?

How do we extend the principles (functional and non-functional aspects) of components to embedded systems?

How do we get a software architecture that guarantees certain properties of a dynamic behavior?

WG Architecture Design Decisions

High quality presentations & discussions on tools & processes for capturing architectural knowledge, prototyping processes case studies: SMS to Air Traffic Control

Key takeaways include need for: common metamodel and language for expressing

architecture design decisions (tools, reuse support) better understanding of casual relationships among decision

decisions & decisions’ interaction with environment. taxonomy of architecture decision decisions, using it as an

aide for classification, ordering and socialization. Additional techniques and practices related to socialization,

mentoring and communicationExamples of “good architectures” are needed where architecture decisions are explicitly highlighted. Supports Booch’s notion of a “reading club”

Technical blueprint vs leadership

Dissonance: SW Arch as technical system blueprint vs senior technical leadership Is the technical focus just out of touch,

or Is the definition of SW Arch being

diluted, or Is SW Arch in practice embedded in

other responsibilities?

How can we resolve this dissonance?

Leadership

Senior technical leadership

Technical

Technical tools forsoftware systemstructure

“We need more – it’s not good enough yet”

“This is what architects really do –help us here too”

We’re looking at the “bear” and running faster than the other guy

This is absolutely important and researchers willhelp as much as possible, but we need to bring in other researchers with skills in the larger arena

Are we closing a “Golden Age”?

Paul Clements invoked a golden age of aviation

“Golden Age of the Celestial Atlas” rare book exhibit Dictionary.com: “any period (sometimes imaginary) of great peace and prosperity and happiness

http://www.lindahall.org/events_exhib/exhibit/ex_atlas.shtml

Where Next?

Move beyond the “Golden Age” It represents passage to maturity, not the end

of research opportunities This groundwork shows where to make

progress Each workshop topic

Golden Ages are followed by development of richer, more broadly useful results Biplane 747, Airbus, spacecraft Illuminated maps Hubble photographs We need both for Mars Rovers

So, what are the SA opportunities?

So, what are the SA opportunities?

Education Hans van Vliet and

Mary Shaw

Quality Len Bass

Architecting Christine Hofmeister

Evaluation & Analysis David Garlan

ADLs in Practice Eóin Woods

Documentation in Practice Paul Clements

Components and Services Ivica Crnkovic

Architectural Design Decisions Jeff Tyree