1. technology and computing
2. programming languages
3. java

Using UML, Patterns, and Java
Object-Oriented Software Engineering
Chapter 12: Rationale Management
Overview: rationale management





What is rationale?
Why is it critical in software engineering?
Representing rationale
Authoring rationale
State-of-the-practice
 Consensus building (WinWin)
 Consistency with goals (NFR Framework)
 Rapid knowledge construction (Compendium)

Summary
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
2
What is rationale?
Rationale is the reasoning that led to the system.
Rationale includes:
 the issues that were addressed,
 the alternatives that were considered,
 the decisions that were made to resolve the issues,
 the criteria that were used to guide decisions, and
 the debate developers went through to reach a decision.
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
3
Why is rationale important in software engineering?
Many software systems result from a large number of decisions
taken over an extended period of time.



Evolving assumptions
Legacy decisions
Conflicting criteria
-> high maintenance cost
-> loss & rediscovery of information
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
4
Uses of rationale in software engineering

Improve design support
 Avoid duplicate evaluation of poor alternatives
 Make consistent and explicit trade-offs

Improve documentation support
 Makes it easier for non developers (e.g., managers, lawyers,
technical writers) to review the design

Improve maintenance support
 Provide maintainers with design context

Improve learning
 New staff can learn the design by replaying the decisions that
produced it
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
5
Overview: rationale management





What is rationale?
Why is it critical in software engineering?
Representing rationale
Authoring rationale
State-of-the-practice
 Consensus building (WinWin)
 Consistency with goals (NFR Framework)
 Rapid knowledge construction (Compendium)

Summary
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
6
Representing rationale: issue models
Argumentation is the most promising approach so far:
 More information than document: captures trade-offs and
discarded alternatives that design documents do not.
 Less messy than communication records: communication
records contain everything.
Issue models represent arguments in a semi-structure form:
 Nodes represent argument steps
 Links represent their relationships
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
7
Issues


Issues are concrete problem which usually do not have a
unique, correct solution.
Issues are phrased as questions.
input?:Issue
How should the dispatcher
input commands?
Bernd Bruegge & Allen H. Dutoit
display?:Issue
How should track sections
be displayed?
Object-Oriented Software Engineering: Using UML, Patterns, and Java
8
Proposals


Proposals are possible alternatives to issues.
One proposal can be shared across multiple issues.
input?:Issue
addressed by
addressed by
text-based:Proposal
The display used by the
dispatcher can be a text only
display with graphic characters
to represent track segments.
Bernd Bruegge & Allen H. Dutoit
display?:Issue
addressed by
point&click:Proposal
The interface for the dispatcher
could be realized with a point &
click interface.
Object-Oriented Software Engineering: Using UML, Patterns, and Java
9
Consequent issue

Consequent issues are issues raised by the introduction of a
proposal.
input?:Issue
display?:Issue
addressed by
addressed by
text-based:Proposal
addressed by
point&click:Proposal
raises
terminal?:Issue
Which terminal emulation should
be used for the display?
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
10
Criteria


A criteria represent a goodness measure.
Criteria are often design goals or nonfunctional
requirements.
input?:Issue
addressed by
addressed by
text-based:Proposal
raises
display?:Issue
meets
addressed by
point&click:Proposal
meets
terminal?:Issue
fails
fails
usability$:Criterion
The CTC system should have at
least a 99% availability.
Bernd Bruegge & Allen H. Dutoit
availability$:Criterion
The time to input commands should
be less than two seconds.
Object-Oriented Software Engineering: Using UML, Patterns, and Java
11
Arguments



Arguments represent the debate developers went through to
arrive to resolve the issue.
Arguments can support or oppose any other part of the
rationale.
Arguments constitute the most part of rationale.
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
12
Arguments (2)
input?:Issue
addressed by
addressed by
text-based:Proposal
raises
display?:Issue
meets
addressed by
point&click:Proposal
meets
terminal?:Issue
fails
fails
usability$:Criterion
is opposed by
availability$:Criterion
is supported by
availability-first!:Argument
Point&click interfaces are more complex to implement than text-based
interfaces. Hence, they are also more difficult to test. The
point&click interface risks introducing fatal errors in the system
that would offset any usability benefit the interface would provide.
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
13
Resolutions




Resolutions represent decisions.
A resolution summarizes the chosen alternative and the
argument supporting it.
A resolved issue is said to be closed.
A resolved issue can be re-opened if necessary, in which case
the resolution is demoted.
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
14
Resolutions (2)
resolves
text-based&keyboard
:Resolution
input?:Issue
text-based:Proposal
raises
display?:Issue
addressed by
addressed by
meets
resolves
addressed by
point&click:Proposal
meets
terminal?:Issue
fails
fails
usability$:Criterion
is opposed by
availability$:Criterion
is supported by
availability-first!:Argument
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
15
Overview: rationale management





What is rationale?
Why is it critical in software engineering?
Representing rationale
Authoring rationale
State-of-the-practice
 Consensus building (WinWin)
 Consistency with goals (NFR Framework)
 Rapid knowledge construction (Compendium)

Summary
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
16
Authoring Rationale

When to capture rationale
 In meetings


Real-time communications, clarifications, negotiations and resolutions
Meeting minutes can be recorded in structured format, based on issue model
 Asynchronously


Contextual information can be added in between meetings
Project participants absent during meetings can read the minutes and post
additional issues or options, which can be resolved offline
 When discussing change



Change is inevitable – requirements change, assumptions change
It is important to record the rationale not only for the original decision, but
subsequent changes
Rationale for change must be related back to past rationale
 After the fact


Many project discussions are carried out informally
The rationale behind the decisions resulting from these discussions should also
be reconstructed and recorded.
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
17
Authoring rationale
Approaches
 Reconstruction
 Record-and-replay
 Byproduct of development methodology
 Incremental and semi automated structuring
Challenges
 Lot of information to capture
 Disruptive for developers
 Formalizing knowledge is expensive
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
18
Record and replay example: meeting management

Facilitator posts an agenda
 Discussion items are issues

Participants respond to the agenda
 Proposed amendments are proposals or additional issues

Facilitator updates the agenda and facilitates the meeting
 The scope of each discussion is a single issue tree

Minute taker records the meeting
 The minute taker records discussions in terms of issues, proposals,
arguments, and criteria.
 The minute taker records decisions as resolutions and action items.
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
19
Centralized traffic control
Trains
S2
T1291>
S3
Track circuits
Signals
Switches
SW1
SW2 <T1515
S1


S4
CTC systems enable dispatchers to monitor and control trains
remotely
CTC allows the planning of routes and replanning in case of
problems
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
20
Centralized traffic control (2)
CTC systems are ideal examples of rationale capture:

Long lived systems (some systems include 19th century relays)
 Extended maintenance life cycle

Although not life critical, downtime is expensive
 Low tolerance for bugs
 Transition to mature technology needs careful planning
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
21
Record and replay example: database discussion
agenda
3. Discussion
I[1] Which policy for retrieving tracks from the database?
I[2] Which encoding for representing tracks in
transactions?
I[3] Which query language for specifying tracks in the
database request?
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
22
Record and replay example: database discussion
I[1] Which policy for retrieving tracks from the database?
Jim: How about we just retrieve the track specified by the
query? It is straightforward to implement and we can
always revisit it if it is too slow.
Ann: Prefetching neighboring tracks would not be much
difficult and way faster.
Sam: During route planning, we usually need the neighbor
tracks anyway. Queries for route planning are the most
common queries.
Jim: Ok, let’s go for the prefetch solution. We can revert
to the simpler solution if it gets too complicated.
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
23
Record and replay example: database discussion
minutes
3. Discussion
I[1] Which policy for retrieving tracks from the database?
P[1.1] Single tracks!
A- Lower throughput.
A+ Simpler.
P[1.2] Tracks + neighbors!
A+ Overall better performance: during route
planning, we need the neighbors anyway.
{ref: 1/31 routing meeting}
R[1] Implement P[1.2]. However, the prefetch should be
implemented in the database layer, allowing use to
encapsulate this decision. If all else fails, we will
fall back on P[1.1].
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
24
Methodology by-product example:
the Inquiry-Based Cycle
Requirements
Challenge
Change
Question ?
D
Answer !
Evolution
Decide
Reason .
Discussion
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
25
Accessing rationale
Browse & search
 Full text search allows to identify interesting nodes
 Issue model links allow the browsing of related issues quickly
Passive & active design critique
 Rationale can be used by knowledge based critiques to evaluate
a design
Challenges
 Evolving terminology
 Navigation through a large flat space
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
26
Overview: rationale management





What is rationale?
Why is it critical in software engineering?
Representing rationale
Authoring rationale
State-of-the-practice
 Consensus building (WinWin)
 Consistency with goals (NFR Framework)
 Rapid knowledge construction (Compendium)

Summary
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
27
Consensus building
Problem
 Any realistic project suffers the tension of conflicting goals
 Stakeholders come from different background
 Stakeholders have different criteria
Example
 Stakeholders in requirements engineering




Client:
business process (cost and schedule)
User:
functionality
Developer: architecture
Manager: development process (cost and schedule)
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
28
Consensus building: WinWin

Philosophy – making winners of key stakeholders is a
necessary and sufficient condition for project success

Incremental, risk-driven process
 Identification of stakeholders
 Identification of win conditions
 Conflict resolution

Asynchronous groupware tool




Stakeholders post win conditions
Facilitator detects conflict
Stakeholders discuss alternatives
Stakeholders make agreements
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
29
Consensus building: Negotiation Model
Taxonomy Category
Win Condition
involves
Issue
addresses
Opt ion
covers
Bernd Bruegge & Allen H. Dutoit
adopts
Agreement
Object-Oriented Software Engineering: Using UML, Patterns, and Java
30
Artifacts of Negotiation Model





Win conditions – capture stakeholder goals and concerns with
respect to a new system
Issues – record conflicts among win conditions
Options – alternative solutions to address issues
Agreements – used to adopt an option, or if there were no
conflicts, the win conditions are adopted.
Taxonomy – links artifacts, acts as checklist for sufficient
coverage
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
31
Consensus building: Process
2. Identify stakeholders’
win conditions
1. Identify stakeholders
3. Reconcile win conditions.
Establish alternatives.
7. Review & commit
6. Validate
4. Evaluate & resolve risks.
5. Define solution
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
33
WinWin Tool




Groupware tool for stakeholders to negotiate mutually
satisfactory system specifications.
Supports WinWin negotiation model
Synchronous and asynchronous negotiations
Additional tools support tradeoff analysis and risk
identification and resolution
 A4 (Architecture Attribute Analysis Aid) – Architecture-based
analysis of cost, schedule, performance and reliability.
 Rapide – Architecture tool for modeling and simulating systems and
identifying problems (deadlocks, bottlenecks, etc.) in the
architecture.
 COCOMO (Constructive Cost Model) II – Cost/schedule estimation
tool.
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
34
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
36
Consistency with goals
Problem
 Once multiple criteria have been acknowledged
 Find solutions that satisfy all of them
 Document the trade-offs that were made
Example
 Authentication should be secure, flexible for the user, and low
cost.
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
38
Consistency with goals: NFR Framework

NFR goal refinement





NFRs are represented as goals in a graph
Leaf nodes of the graph are operational requirements
Relationships represent “help” “hurt” relationships
One graph can represent many alternatives
NFR evaluation
 Make and break values are propagated through the graph
automatically
 Developer can evaluate different alternatives and compare them
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
39
Consistency with goals: Model
X


Flexibility
Low cost
_
+
+
Security
AND
_
Authent ication
Confidentiality
Integrity
OR

Account+PIN
Finger Print Reader
SmartCard+PIN
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
40
Consistency with goals: Process
Elicit
high-level goals
Evaluate
alternatives
Refine into
detailed goals
Identify
operational goals
Bernd Bruegge & Allen H. Dutoit
Identify goal
dependencies
Object-Oriented Software Engineering: Using UML, Patterns, and Java
41
Rapid knowledge construction
Problem
 When a company is large enough, it doesn’t know what it does.
 Knowledge rarely crosses organizational boundaries
 Knowledge rarely crosses physical boundaries
Example
 Identify resources at risk for Y2K and prioritize responses.
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
43
Rapid knowledge construction: Compendium

Meeting facilitation
 Stakeholders from different business units
 External facilitator

Real-time construction of knowledge maps
 The focus of the meeting is a concept map under construction
 Map includes the issue model nodes and custom nodes
(e.g., process, resource, etc.)

Knowledge structuring for long term use
 Concept map exported as document outline, process model, memos,
etc.
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
44
Rapid knowledge construction: Knowledge Map
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
45
Nodes in the Knowledge Map






Questions
Ideas / answers
Arguments – pros and cons
Decisions
Notes
References
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
46
Rapid knowledge construction:
Generating Document Templates
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
47
Questions, Options, Criteria




Designed for capturing rationale after the fact, for long term
use (e.g., quality assessment).
QOC emphasizes systematic
Question ?
evaluation of options
against criteria
consequent question
response
positive
assessment +
Option !
Criterion $
negative
assessment supports +
objects-to -
supports +
objects-to -
Argument .
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
50
Other issue models:
Decision Representation Language
is a good alternative for
Alternative
Decision Problem
achieves
Goal
AchievesLink
Claim
denies
denies
supports
is a result of
Procedure
Bernd Bruegge & Allen H. Dutoit
Claim
answers
is an answering
procedure for
Object-Oriented Software Engineering: Using UML, Patterns, and Java
supports
presupposes
raises
Question
51
Summary

Rationale can be used in project management
 To build consensus (WinWin)
 To ensure quality (NFR Framework)
 To elicit knowledge (Compendium)

Other applications include
 Risk management
 Change management
 Process improvement

Open issues
 Tool support
 User acceptance
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
52