DGA - Department of computing science

Design Decision Rationale:
Experiences and Steps Ahead Towards
Systematic Use
Davide Falessi
Martin Becker
Giovanni Cantone
SHARK '06, June 11, 2006, Torino, Italy
Problem
Introduction DGA Motivators&Inhibitors Solution Conclusion


CBSE and PLA testify both the importance of
reuse and the achieved standardization.
Design Decision Rationale (DDR):
+ is promising,
- is not yet largely utilized,
- no standard methods exist.
DDR NEEDS FURTHER IMPROVEMENTS
2
Outline
Introduction DGA Motivators&Inhibitors Solution Conclusion

New DDR documentation framework the
Decision, Goal, and Alternatives (DGA).

Motivators and inhibitors of using DDR.

A solution: be systematic!


Reuse only pays off when enacted in a systematic,
pre-planned, and carefully focused way.
DDR usage scenarios, enlightening who, what,
when, and which items, allow a scenario-focused
efficient DDR documentation (DDRD) and the
persuasion of DDR maintainers and payees.
3
DGA
Context
Introduction DGA Motivators&Inhibitors Solution Conclusion


Ambient Intelligence (AmI) is a vision of
intelligent environments that react in a sensitive
and adaptive way to the presence of humans and
objects in order to provide various services to
people.
BelAmi (Bilateral German-Hungarian Research
Collaboration on Ambient Intelligence Systems)
project in the assisting living domain.
4
DGA
Context
Introduction DGA Motivators&Inhibitors Solution Conclusion

There are AmI characteristics that demand for
DDR usage, including:
 New combinations of required qualities, e.g.,
flexibility and efficiency, interoperability, and
safety.
 Several stakeholders with specific knowledge
and views.
 Architects and designers have to negotiate
their objectives that interfere with the issues
of others.
 Requirements do change substantially.
5
DGA
Rationale
Introduction DGA Motivators&Inhibitors Solution Conclusion



Our decision was to capture DDR by documenting
decisions that stakeholders were making in the AmI
context by using the CBAM method.
In fact, the SEI presented Cost Benefit Analysis
Method (CBAM) as a rational decision-making
process for software architectural decisions, which is
able to give stakeholders help in the elicitation of
costs and benefits.
We designed the Decision, Goals and Alternative
(DGA) technique that, as its name partially suggests
(“decision”, “alternative”), is related to CBAM.
6
DGA
Decision Drivers
Introduction DGA Motivators&Inhibitors Solution Conclusion
Functional Requirement
Non-Functional Requirement
Design Decision
Business Goal
Decision Relationship
Is it complete?
7
Our Experience
Decision Goal and Alternatives DDR Framework
Introduction DGA Motivators&Inhibitors Solution Conclusion

DGA stages:
1. Understand what to document.

Define project goals.
2. Enact the documentation.

For each design decision,

describe the level of importance that every
pre-defined goal (see point 1 above) has for
this decision;

for each decision-related alternative, describe
the level of fulfillment of every pre-defined
goals.
8
Functional Reqiuriment
TYPE
Buisness Cost / effort short
Goal
Cost / effort long
Non-Functional Reqiuriments
Memory
Energy
Comput. power
range comm.
bandwidth
COSTRAINTS Functional Reqiuriments
Non-Functional Reqiuriments
Introduction DGA Motivators&Inhibitors Solution Conclusion
Embedded
Mobile
Distributed
Context-aware
Self-aware
Natural int.
Adaptive
Heterogeneous
SUB-TYPE
Functionality
Suitability
Accuracy
Interoperability
Security
Compliance
Reliability
Maturity
Fault tolerance
Recoverability
Compliance
Usability
Understand.
Learnability
Operability
Attractiveness
Compliance
Efficiency
Time Behavior
Resource util.
Compliance
Maintainability
Analyzability
Changeability
Stability
Testability
Compliance
Portability
Adaptability
Instability
Co-existence
Replaceability
Compliance
Embedded
Mobile
Distributed
Context-aware
Self-aware
Natural int.
Adaptive
Heterogeneous
Memory
Energy
Comput. power
range comm.
bandwidth
DECISION ID
Example of Usage: Stage 1
COSTRAINTS
DGA
Functionality
Suitability
Accuracy
Interoperability
Security
Compliance
Reliability
Maturity
Fault tolerance
Recoverability
Compliance
Usability
Understand.
Learnability
Operability
Attractiveness
Compliance
Efficiency
Time Behavior
Resource util.
Compliance
Maintainability
Analyzability
Changeability
Stability
Testability
Compliance
Portability
Adaptability
Instability
Co-existence
Replaceability
Compliance
Buisness Cost / effort short
Goal
Cost / effort long
9
DGA
Example of Usage: Stage 2
Non-Functional Reqiuriments
Introduction DGA Motivators&Inhibitors Solution Conclusion
TYPE
SUB-TYPE
Functionality
Suitability
Accuracy
Interoperability
Security
Compliance
Reliability
Maturity
Fault tolerance
Recoverability
Compliance
Usability
Understand.
Learnability
Operability
Attractiveness
Compliance
Efficiency
Time Behavior
Resource util.
Compliance
Maintainability
Analyzability
DECISION ID
A 1 2 3
3
4
3
2
4
3
2
4
5
5
3
1
4
1
2
3
2.a Goal
importance
2.b Goal
fulfillment
10
DDR Motivators & Inhibitors
Introduction DGA Motivators&Inhibitors Solution Conclusion
Communication
Design quality
Reusability
Domain knowldg.
DDR
Additional effort
Unclear benefit
Inconsistencies
Personal int.
11
How to mitigate the impact of inhibitors and
emphasize on the impact of motivators?
Introduction DGA Motivators&Inhibitors Solution Conclusion

We propose a new approach aimed to enact a
systematic DDR use based on the concept of
DDR Use Case (DDRUC).

DDRUC enlightening who profits from what
information in which amount, allow a scenariofocused efficient DDRD and the persuasion of
DDR maintainers and payees.
12
Our Solution
DDR Use Case Description
Introduction DGA Motivators&Inhibitors Solution Conclusion
Scenario
ID
Actor
1
Designers
.
.
.
.
13 Stakeholders
Context
Environment
Driver
Activity
Advantages
Several designers,
Detection of
existence of relations
System
Time to
conflicts among
among decisions of heterogeneity
market, effort
decisions
different designers
.
.
.
.
.
.
.
.
Several designers
Large or
complex
system
Communication
avoidance
Effort
The set of DDRUC is supposed to be partial and illustrative,
however its description is complete. Do you agree?
13
Process for a Systematic DDR Use.
Scenarios Description
Utility
YES
Scenario
Selection
YES
Valuable?
NO
Scenario Description
Updating interesting Scenrios List
Context
Analysis
Metrics
Analysis
Required
Information
Analysis
No DDR Employment
Other scenario to analyze?
NO
Probability
Profit
Cost
Adoption of required
Information (only)
Persuasion of DDR
Maintainer
Persuasion of Payees
Feasibility
Analysis
Probability * Profit / Cost
Systematic DDR
Usage
14
Our Solution
Example of Scenario Focused DDRD
Introduction DGA Motivators&Inhibitors Solution Conclusion

Using a DDRD framework recently proposed in
literature and the abovementioned DDRUC, we
rationally deduced which information is required
by which DDRUC.
15
Example of scenario focused DDRD
the Chosen framework
Introduction DGA Motivators&Inhibitors Solution Conclusion
Information
Issue
Decision
Status
Group
Assumptions
Constraints
Positions
Argument
Implications
Related
decisions
Related
requirements
Related artifacts
Related
principles
Notes
Description
Architectural design issue being addressed.
Main characteristics of the made ADD.
E.g. pending, decided, or approved.
You can use a simple grouping—such as integration, presentation, data, and so on—to help organize the set of decisions.
Assumption in the environment in which ADD is made
(e.g. budget and middleware)
Additional constraints to the environment that the
selected ADD might pose.
Alternatives considered.
Reasons why you selected a position (e.g., time to
market and a specific functional requirement).
E.g. new requirements, or modify existing requirements,
additional constraints to the environment.
Decisions that impact or are impacted by the present
ADD.
An explicit trace of the ADD to the objectives or
requirements.
Artifacts impacted by the ADD.
A link between the ADD and enterprise principles
(business or others).
Further significant information not previously captured.
The framework,
aimed to capture
Architectural
Rationale,
recently proposed
by Tyree and
Akerman
16
Example of scenario focused DDRD
Results
Introduction DGA Motivators&Inhibitors Solution Conclusion
DDR Information
Issue
Decision
Status
Group
Assumptions
Constraints
Positions
Argument
Implications
Related decisions
Related requirements
Related artifacts
Related principles
Notes
1
X
X
X
2
X
X
4
X
X
X
X
X
X
X
3
X
DDRUC ID
5 6 7 8
X X X X
X X X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
9 10 11
X X X
X X X
X X X
12
X
X
X
13
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
By analyzing the
contents of the
traceability matrix,
we can derive that
the amount of effort
needed for using
DDR heavily
depends on the
specificities of the
DDRUC.
60% of T&A DDR information is not used !
(percentage of empty box)
17
Future Work
Introduction DGA Motivators&Inhibitors Solution Conclusion




Investigate the relationships between “Usefulness”
and the “Which”, “When”, and “How” of design
decision documentation, respectively.
Develop a decision-making support tool.
Figure out incompatibility issues and which design
rationale information is already available, so that we
do not need to document them again, when using a
certain software architecture design method.
Investigate the relationship between design rationale
information and the “type”, “granularity” and
“hierarchies” of a decision.
18
Conclusion
Introduction DGA Motivators&Inhibitors Solution Conclusion

We described:
 Decision, Goal, and Alternatives (DGA)
DDR framework.
 Motivators and inhibitors of using DDR.
 An approach for systematic DDR
employment based on the concept of
DDR Use Case (DDRUC).
19
Main contact
Davide Falessi, Ph.D. Student
University of Rome “Tor Vergata”, Dept. of Computer
Science, System and Industrial Engineering; Via
del Politecnico 1, 00133 Roma
Phone: +39 06 7259 7942
Email:
Url: http://www.webalice.it/d.falessi/
20