The workshop participants split into several pairs or groups for the discussion. These are the notes on the presentation of the discussion results.

Group 1

• How to model context for automated qualitative reasoning?
• What are the existing/possible different types of contexts in which architecture will be realized? What are the assumptions on the context
  
  • E.g. static context, static user profile; static context, dynamic user profile
  • (Probably there is no one-size-fits-all reasoning approach
• What are the key assumptions for tactics/patterns on the context
• Is domain-specific context modeling helpful for supporting (automated/semi-automated/manual) qualitative reasoning?
  
  • Currently higher abstraction level
    
    • Usage profile
    • Execution context
• How to cope at design time with/model/anticipate on dynamically changing contexts?
• How to cope at run-time with/model/anticipate on dynamically changing contexts?
• What are the required architecture models/viewpoints for reasoning about quality?
  
  • Perspectives
  • Explicit Viewpoints
• How to do an objective multi-criteria optimization of architecture design? (beyond ATAM, etc)
• What are the required qualitative metrics?
• How to provide reusable models that capture relation between/among patterns and quality factors?
  
  • Many-to-many relation between pattern/tactic <-> quality
  • The above relation is context dependent!

Group 2

• How can academic knowledge be applied in practice in large scale?
• What are required qualitative metrics? (high cohesion, low coupling, how to provide more guidelines to translate these principles into sth more tangible)
• What is the minimal set of models / knowledge needed to reason about architecture.

Group 3

• Backtracking of decisions
  • How to integrate decision making into the design process? What is the description of the structure of the design space? Why did I made this decision?
  • Data about running system. Can I find evidence that decision was right? How to falsify the architecture decisions? Architecture as a theory :)

Group 4

• How can models support better decision making and not just capture the outcome?
  • Models typically capture the result , but how to make sure that process is supported.
• How do we trace the decision making across the opportunity space, problem space, decision space (Requirements or design?)
  • Opportunities, wishful thinking,
  • requirements may not be feasible.
  • Business modelling
  • Requirements prioritization, what to commit to
• How do we transfer knowledge back from experts / experience so that we can reuse in the future?

Group 5

• How to reduce ambiguity among stakeholders or team of architects?
• How to provide usable models?
• How to bridge SWA models to naturalistic decision making?
• When can I decide qualitative and when do I have to cross the border to quantitative evaluation?
  • On which factors does this depend?

Group 6

• Different aspects of decision making, how do they interrelate?
  • Dependencies among these
  • How could we visualize and understand the dependencies?
  • Requirements, context, ?
  • What can my program do? How much time do I have?
  • What are different solutions?
• What is reasoning in software design?
  • Inductive, deductive?
  • No rules of thumb
  • Problem is not clear to start with
  • What kind of reasoning is needed?
• How do we retrieve the knowledge and make it explicit?
  • Can be distributed. Probably cannot all be made explicit.
  • How do you distribute it to the right people in the right place and right time?
  • Do we have to spend extra time to gather knowledge? Better: How can we uncover knowledge without extra effort? Capture knowledge seamlessly.
  • What is actually the scale - system or local
  • Trade offs between quality that we need to consider
  • Architect qaliti: the same solution for the same problem throughout the sistem.
  • What do we want to achieve with Qual Arch Reasoning?
    • Ambition - use cases for the reasoning
  • Coming up with options or evaluating options
  • How to combine qualitative and quantitative
  • Can there be a hierarchy of reasoning? Per quality? Per domain?

Other questions during theme discussion

• Why do we have to document all the reasoning? Other engineering disciplines do not do that
  • Lifecycle: cars are built from scratch (the metal), but software evolves.
  • Standards to follow in building construction.

In the following discussion, we identified the following themes:

• Context
• Modelling
• Knowledge management
  • Reuse
• Metrics
• Process of reasoning
• Use cases and practicality of qualitative reasoning

Solution direction

• Example of an actual system together with the reasoning that was done (anything, but industry example would be good)
  • Patricia has an example from student projects, traces exploration of design space, from requirements to realization
  • CoCoME example (common component modelling example): also for evaluating maintainability and evolution scenarios
    • We would have to add the reasoning?

The participants again split into pairs or small groups and discussed. Here are the solutions!

Group 6

• Context: Capture the context: Project-specific and generic. Want to abstract generic knowledge from specific projects
• Context - problem - solution
  • Organize the knowledge in this way
  • Basis for semantic analysis based on ontologies
• Solution for relating knowledge and establishing associations
• Capture all spoken communication

Group 5

• Work on ontologies to reduce ambiguity and awareness of context and to clarify quality goals
• Modelling: Let model emerge from practice instead of trying to put rational models on practice
• Process and use cases: Design space graph: Add properties:
  • is a decision final? Maybe later backtrack.
  • How sure am I? Confidence
• Start with a base idea on qualitative insights. Then, whenever I am unsure and have a high priority go back and do it quantitatively.

Group 4

• Studies about process of reasoning? How do experiences architects do it?
• Industry and academia to share processes?

Group 3

• Support architect during decision making, capture rationale behind decision. Backtracking or anticipate upfront
• Knowledge management: search for knowledge on the internet, crowd-sourcing. Support architect duing modelling by showing what others have done and what are the options

Group 2

• More groundbreaking ideas! Not just incremental. Can we define certain types of theories and standards? So that that we do not have to document rational but refer to standard.
• Close gap between modelling and programming, link the two. Moving the programming level up?

Group 1 (first listing their identified questions again, then ideas for their solution

• How to model context for automated qualitative reasoning?
  
  • Analyze existing context models, identify commonality and variability, identify limitatons
  • Define a metamodel (e.g. EMF) that captures the elements of context
  • Refine the metamodel to selected case studies to validate and enhance metamodel
  • Define the concrete syntax (notation) for modeling context.
• What are the existing/possible different types of contexts in which architecture will be realized? What are the assumptions on the context?
  
  • Two key issues: (1) execution platform (2) usage profile. Both can be static or dynamic. As such we have four different context models
    
    • static execution platform, static user profile
      
      • Classical information systems
    • static execution platform, dynamic user profile;
      
      • Information systems with dynamically changing load
    • dynamic execution platform, static user profile;
      
      • Mobile systems
    • dynamic execution platform, dynamic user profile; 
      
      • Mobile, cloud-based systems
• What are the key assumptions for tactics/patterns on the context
  
  • Depends on quality factor and context assumptions
  • Consider each quality separately
• Is domain-specific context modeling helpful for supporting (automated/semi-automated/manual) qualitative reasoning?
  
  • Domain specific model provides knowledge, and as such can provide additional knowledge
  • Validate with case studies
• How to cope at design time with/model/anticipate on dynamically changing contexts?
  
  • Need design models that can capture context and dynamic change
• How to cope at run-time with/model/anticipate on dynamically changing contexts?
  
  • Self-adaptive architectures
• What are the required architecture models/viewpoints for reasoning about quality?
  
  • Perspectives
  • Explicit Viewpoints
  • Other? Combined?
• How to do an objective multi-criteria optimization of architecture design? (beyond ATAM, etc)
  
  • Semantically enriched models? More objective reasoning?
• What are the required qualitative metrics?
  • no answer as time ran out
• How to provide reusable models that capture relation between/among patterns and quality factors?
  
  • Many-to-many relation between pattern/tactic <-> quality
  • The above relation is context dependent!
  • no answer as time ran out

The workshop organizers will write a summary.