Design Decision Rationale: Experiences and Steps Ahead Towards Systematic Use

Design Decision Rationale: Experiences and Steps Ahead

Towards Systematic Use

Davide Falessi Martin Becker Giovanni Cantone

SHARK '06, June 11, 2006, Torino, Italy

2

Problem

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

Introduction DGA Motivators&Inhibitors Solution

Conclusion

3

Outline 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.


Conclusion

4

DGAContext

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.

Introduction DG

A Motivators&Inhibitors Solution

Conclusion

5

DGAContext

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.

Introduction DG


Conclusion

6

DGARationale

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.

Introduction DG


Conclusion

7

DGADecision Drivers

Design Decision

Non-Functional Requirement

Functional Requirement

Decision RelationshipBusiness Goal

Is it complete?

Introduction DG


Conclusion

8

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.

Our ExperienceDecision Goal and Alternatives DDR Framework

Introduction DG


Conclusion

9

DGAExample of Usage: Stage 1

FunctionalitySuitabilityAccuracyInteroperabilitySecurityComplianceReliabilityMaturityFault toleranceRecoverabilityComplianceUsabilityUnderstand.LearnabilityOperabilityAttractivenessComplianceEfficiencyTime BehaviorResource util.ComplianceMaintainabilityAnalyzabilityChangeabilityStabilityTestabilityCompliancePortabilityAdaptabilityInstabilityCo-existenceReplaceabilityCompliance

Non

-Fun

ctio

nal R

eqiu

rimen

tsEmbeddedMobileDistributedContext-awareSelf-awareNatural int.AdaptiveHeterogeneousFu

nctio

nal R

eqiu

rimen

tsMemoryEnergyComput. powerrange comm.bandwidthC

OST

RA

INTS

Cost / effort shortCost / effort long

Buisness Goal

FunctionalitySuitabilityAccuracyInteroperabilitySecurityComplianceReliabilityMaturityFault toleranceRecoverabilityComplianceUsabilityUnderstand.LearnabilityOperabilityAttractivenessComplianceEfficiencyTime BehaviorResource util.ComplianceMaintainabilityAnalyzabilityChangeabilityStabilityTestabilityCompliancePortabilityAdaptabilityInstabilityCo-existenceReplaceabilityComplianceEmbeddedMobileDistributedContext-awareSelf-awareNatural int.AdaptiveHeterogeneousMemoryEnergyComput. powerrange comm.bandwidthCost / effort shortCost / effort long

CO

STR

AIN

TS

Buisness Goal

TYPE SUB-TYPE DECISION ID

Non

-Fun

ctio

nal R

eqiu

rimen

tsFu

nctio

nal R

eqiu

rimen

ts

Introduction DG


Conclusion

10

A 1 2 3FunctionalitySuitabilityAccuracy 3InteroperabilitySecurityComplianceReliabilityMaturity 4Fault toleranceRecoverabilityComplianceUsabilityUnderstand.Learnability 5OperabilityAttractivenessComplianceEfficiencyTime BehaviorResource util. 4ComplianceMaintainabilityAnalyzabilityChangeabilityStability 2TestabilityCompliancePortabilityAdaptabilityInstabilityCo-existence 1ReplaceabilityComplianceEmbeddedMobileDistributed 4Context-awareSelf-awareNatural int.AdaptiveHeterogeneousMemory 4Energy 4Comput. powerrange comm.bandwidthCost / effort short 5Cost / effort long 4

Buisness Goal

TYPE SUB-TYPE DECISION IDN

on-F

unct

iona

l Req

iurim

ents

Func

tiona

l Req

iurim

ents

CO

STR

AIN

TSFunctionalitySuitabilityAccuracyInteroperabilitySecurityComplianceReliabilityMaturityFault toleranceRecoverabilityComplianceUsabilityUnderstand.LearnabilityOperabilityAttractivenessComplianceEfficiencyTime BehaviorResource util.ComplianceMaintainabilityAnalyzabilityChangeabilityStabilityTestabilityCompliancePortabilityAdaptabilityInstabilityCo-existenceReplaceabilityComplianceEmbeddedMobileDistributedContext-awareSelf-awareNatural int.AdaptiveHeterogeneousMemoryEnergyComput. powerrange comm.bandwidthCost / effort shortCost / effort long

DECISION IDN

on-F

unct

iona

l Req

iurim

ents

Func

tiona

l Req

iurim

ents

CO

STR

AIN

TS

Buisness Goal

TYPE SUB-TYPEA 1 2 3

FunctionalitySuitabilityAccuracy 3 4 3 2InteroperabilitySecurityComplianceReliabilityMaturity 4 3 2 4Fault toleranceRecoverabilityComplianceUsabilityUnderstand.Learnability 5 5 3 1OperabilityAttractivenessComplianceEfficiencyTime BehaviorResource util. 4 1 2 3ComplianceMaintainabilityAnalyzabilityChangeabilityStability 2 4 2 2TestabilityCompliancePortabilityAdaptabilityInstabilityCo-existence 1 4 2 1ReplaceabilityComplianceEmbeddedMobileDistributed 4 4 2 1Context-awareSelf-awareNatural int.AdaptiveHeterogeneousMemory 4 2 1 3Energy 4 1 2 3Comput. powerrange comm.bandwidthCost / effort short 5 2 3 3Cost / effort long 4 3 4 1

Buisness Goal


on-F

unct

iona

l Req

iurim

ents

Func

tiona

l Req

iurim

ents

CO

STR

AIN

TS2.a Goal importance

2.b Goal fulfillment

A 1 2 3FunctionalitySuitabilityAccuracyInteroperabilitySecurityComplianceReliabilityMaturityFault toleranceRecoverabilityComplianceUsabilityUnderstand.LearnabilityOperabilityAttractivenessComplianceEfficiencyTime BehaviorResource util.ComplianceMaintainabilityAnalyzabilityChangeabilityStabilityTestabilityCompliancePortabilityAdaptabilityInstabilityCo-existenceReplaceabilityComplianceEmbeddedMobileDistributedContext-awareSelf-awareNatural int.AdaptiveHeterogeneousMemoryEnergyComput. powerrange comm.bandwidthCost / effort shortCost / effort long

Buisness Goal


on-F

unct

iona

l Req

iurim

ents

Func

tiona

l Req

iurim

ents

CO

STR

AIN

TS

Introduction DG


Conclusion

DGAExample of Usage: Stage 2

11

DDR Motivators & Inhibitors

DDR

Communication

Design quality Reusability Domain knowldg.

Additional effort

Unclear benefit

Inconsistencies

Personal int.

Introduction DGA Motivators&

Inhibitors Solution Conclusion

12

How to mitigate the impact of inhibitors and emphasize on the impact of motivators?

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 scenario-focused efficient DDRD and the persuasion of DDR maintainers and payees.


Conclusion

13The set of DDRUC is supposed to be partial and

illustrative, however its description is complete. Do you agree?

Environment Driver

1 Designers

Several designers, existence of relations among decisions of different designers

System heterogeneity

Detection of conflicts among

decisions

Time to market, effort

. . . . . .

. . . . . .13 Stakeholders Several designers

Large or complex system

Communication avoidance Effort

Advantages

ScenarioContext

ID Actor Activity

Our SolutionDDR Use Case Description


Conclusion

14

Process for a Systematic DDR Use.

ContextAnalysis

MetricsAnalysis

Required Information

Analysis

Probability Profit Cost

FeasibilityAnalysis

Probability * Profit / Cost

Scenario Description

Utility

Persuasion of DDR Maintainer

Systematic DDR Usage

Valuable?YES

No DDR Employment

NO

Adoption of required Information (only)

Scenarios Description

Scenario Selection

Updating interesting Scenrios List

Other scenario to analyze?

YES

NO

Persuasion of Payees

15

Our SolutionExample of Scenario Focused

DDRD

Using a DDRD framework recently proposed in literature and the abovementioned DDRUC, we rationally deduced which information is required by which DDRUC.


Conclusion

16

Example of scenario focused DDRDthe Chosen framework

Information DescriptionIssue Architectural design issue being addressed.Decision Main characteristics of the made ADD.Status E.g. pending, decided, or approved.

Group You can use a simple grouping—such as integration, presentation, data, and so on—to help organize the set of decisions.

Assumptions Assumption in the environment in which ADD is made (e.g. budget and middleware)

Constraints Additional constraints to the environment that the selected ADD might pose.

Positions Alternatives considered.

Argument Reasons why you selected a position (e.g., time to market and a specific functional requirement).

Implications E.g. new requirements, or modify existing requirements, additional constraints to the environment.

Related decisions

Decisions that impact or are impacted by the present ADD.

Related requirements

An explicit trace of the ADD to the objectives or requirements.

Related artifacts Artifacts impacted by the ADD.Related principles

A link between the ADD and enterprise principles (business or others).

Notes Further significant information not previously captured.

The framework, aimed to capture Architectural Rationale, recently proposed by Tyree and Akerman


Conclusion

17

1 2 3 4 5 6 7 8 9 10 11 12 13Issue X X X X X X X X X X X X XDecision X X X X X X X X X XStatus X X X X X X X X XGroup Assumptions X X Constraints X X Positions X X X X X Argument X X X X X XImplications X X X X XRelated decisions X X X X X X XRelated requirements X X X X X X X Related artifacts X X X X X XRelated principles X X X X Notes

DDR Information DDRUC ID

60% of T&A DDR information is not used !

(percentage of empty box)

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.

Example of scenario focused DDRDResults


Conclusion

18

Future Work 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.


Conclusion

19

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).


Conclusion

20

Main contact

Davide Falessi, Ph.D. StudentUniversity of Rome “Tor Vergata”, Dept. of

Computer Science, System and Industrial Engineering; Via del Politecnico 1, 00133 Roma

Phone: +39 06 7259 7942Email: Url: http://www.webalice.it/d.falessi/

Documents

Design Decision Rationale: Experiences and Steps Ahead Towards Systematic Use