Session:Design Decisions in Architecting--Discussions

From WICSA Conference Wiki

Please use this page to capture ideas, thoughts, reactions, opinions and so on about the content of this session.

Moderator: Henk Obbink

Key ideas

(key ideas, how papers relate to each other and support the session theme)

• key idea 1

Discussion questions

Re: ACCA

• Does it matter if the concerns are orthogonal?
• Is there benefit in trying to decompose concerns and/or decicions so that you get to a 1:1 relationship between decisions and concerns? (Is this even possible?)
• How do you handle the case of sequential decisions leading to a concern?

ACCA: An Architecture-centric Concern Analysis Method

In the presentation a definition of "concerns" is given, focussing on issues who form a problem in the architecture. This definition is 'strange' considering the already existing definitions for concerns in the field of AOSD. An intuitive definition is "a concern is an important issue for a stakeholder of the system".

• Is 'concerns' in this context the most suited term? Why not just use 'problems'?

• How does this definition of concerns relate to the work done in AOSD? As described in the presentation, the concerns at least seem to be crosscutting. But they seem to be closer to requirements (problem domain) than to things that have to be modularized (solution domain).

A couple of comments

• Does this approach require a post-mortem of an executable architecture? Or, can this approach be done on an architecture design?

• Most of the 61 issues were categorized to Reliability/Availability, Security and Usability. Isn't this this case of almost all architecture work?

re: "Software Architecture as a Set of Architectural Design Decisions"

• You assert that the architecture is the sum of the design decisions. If a set of design decisions leads to an architecture structured as a particular set of components and connectors (for example), and a different set of design decisions leads to an architecture with the exact same structure of the same components and connectors, then are these the same architecture or different architectues? What does this mean in practice?

Answer: I believe these two architectures to be different from eachother. The mere fact that, for example, the set of components and connectors are the same is not enough to make them the same. The primary reason for this is that the reasoning behind the two architectures are different and this can lead to different refinements and changes in the future of the architecture. In this particular case, I would call the architectures similair, as opposed to being the same. (Anton Jansen)

(pre-session, session, post-session, post-mortem)