Conquering Complex and Changing Systems
Object-Oriented Software Engineering
Chapter 8,
Rationale
Management
An aircraft example
A320
 First fly-by-wire passenger aircraft
 150 seats, short to medium haul
A319 & A321
 Derivatives of A320
 Same handling as A320
Rationale:
 Reduce pilot training & maintenance costs
 Increase flexibility for airline
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
2
An aircraft example (2)
A330 & A340
 Long haul and ultra long haul
 2x seats, 3x range
 Similar handling than A320 family
Rationale
 With minimum cross training, A320 pilots can be certified to
fly A330 and A340 airplanes
Consequence
 Any change in these five airplanes must maintain this similarity
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
3
Overview

Rationale:
 What is it?
 Why should you care?

Rationale methods
 Representing rationale
 Authoring rationale
 Accessing rationale


State of practice & research
Summary
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
4
What is rationale?
Rationale is the reasoning that lead to the system.
Rationale includes:
 Issues that were addressed,
 Alternatives that were considered,
 Decisions that were made to resolve the issues,
 Criteria that were used to guide decisions, and
 Debate developers went through to reach a decision.
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
5
Why rationale?
Software systems are similar to passenger airplanes:
They 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 Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
6
Rationale helps deal with change

Improve maintenance support
 Provide maintainers with design context

Improve learning
 New staff can learn the design by replaying the decisions that
produced it

Improve analysis and design
 Avoid duplicate evaluation of poor alternatives
 Make consistent and explicit trade-off
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
7
Levels of rationale
No rationale captured
 Rationale is only present in memos, online communication,
developers’ memory
Rationale reconstruction
 Rationale is documented in a document justifying the final design
Rationale capture
 Rationale is documented during design as it is developed
Rationale integration
 Rationale drives the design
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
8
Centralized traffic control
Trains
S2
T1291>
Signals
S3
Switches
SW1
SW2
S1


Track circuits
<T1515
S4
CTC systems enable dispatchers to monitor and control trains
remotely
CTC allows the planning of routes and re-planning in case of
problems
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
9
Centralized traffic control (2)
CTC systems are ideal examples of rationale capture:

Long lived systems (some systems include relays installed last
century)
 Extended maintenance life cycle

Downtime is expensive (although not safety critical)
 Low tolerance for bugs
 Transition to mature technology

Initial developers are not available
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
10
Issues


Issues are concrete problem which usually do not have a
unique, correct solution.
Issues are phrased as questions.
display?:Issue
How should track sections
be displayed?
Bernd Bruegge & Allen Dutoit
input?:Issue
How should the dispatcher
input commands?
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
11
Proposals


Proposals are possible alternatives to issues.
One proposal can be shared across multiple issues.
display?: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 Dutoit
input?:Issue
addressed by
point&click:Proposal
The interface for the dispatcher
could be realized with a point &
click interface.
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
12
Consequent issue

Consequent issues are issues raised by the introduction of a
proposal.
display?:Issue
addressed by
text-based:Proposal
input?:Issue
addressed by
addressed by
point&click:Proposal
raises
terminal?:Issue
Which terminal emulation should
be used for the display?
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
13
Criteria


A criteria represent a goodness measure.
Criteria are often design goals or nonfunctional
requirements.
display?:Issue
addressed by
addressed by
text-based:Proposal
raises
input?:Issue
meets
addressed by
point&click:Proposal
meets
terminal?:Issue
fails
fails
usability$:Criterion
The time to input commands should
be less than two seconds.
Bernd Bruegge & Allen Dutoit
availability$:Criterion
The CTC system should have
at least a 99% availability.
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
14
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 Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
15
Arguments (2)
display?:Issue
addressed by
addressed by
text-based:Proposal
raises
input?: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 Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
16
Resolutions




Resolutions represent decisions.
A resolution summarizes the selected alternative and the
supporting argument.
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 Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
17
Resolutions (2)
resolves
text-based&keyboard
:Resolution
display?:Issue
text-based:Proposal
raises
input?: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 Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
18
Representing rationale: issue models
resolves
Resolution.
Issue?
is a consequence
responds
Proposal
meets +
Criterion$
fails supports +
objects to -
supports +
objects to Argument!
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
19
Representing rationale (cont’d)
Many issue models have been proposed:
 IBIS, QOC, DRL, WinWin
 Similar in their essence
 Differ in the amount of detail that can be captured
Challenges
 Require tool support for capture and access
 Require integration with CASE and project management tools
 Require integration with methodology
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
20
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 Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
21
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 Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
22
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 Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
23
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 Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
24
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 Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
25
Methodology by-product example:
the Inquiry-Based Cycle
Requirements
Challenge
Change
Question ?
D
Answer !
Evolution
Decide
Reason .
Discussion
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
26
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 Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
27
State of the practice
Standalone issue based tools
 QuestMap
Problem management tools
 Work flow application tracking problems and resolutions
 Integrated with configuration management
 Some tools (e.g., ClearQuest) allow schema to be customized
RequisitePro
 Requirements management
 Integrated with configuration management
 Explicitly captures rationale behind change
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
28
State of research



Many solutions for representation exist and can be tailored to a
specific problem
Progress in natural language search and in hypertext
technology make access a less critical issue.
Current challenges
 Integration with methodology
 Integration with tools
 Overhead
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
29
Open issues

Formalizing knowledge is costly.
 Maintaining a consistent design model is expensive.
 Capturing and maintaining its rationale is worse.

The benefits of rationale are not perceived by current
developers.
 If the person who does the work is not the one who benefits from it,
the work will have lower priority.
 40-90% of off-the-shelf software projects are terminated before the
product ships.

Capturing rationale is usually disruptive.

Current approaches do not scale to real problems
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
30
Summary

Capturing rationale is critical
 Argumentation of alternatives
 Explicit design criteria
 Information relevant for future change

Issue models provide a good representation
 Offer a structured solution to capture rationale
 Make it easier to browse rationale information

Rationale needs to be integrated through out the process
 Provide a short term incentive
 Decrease setup cost
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
31