Download - Chapter 8, Rationale Management
Con
quer
ing
Com
plex
and
Cha
ngin
g S
yste
ms
Ob
ject
-Ori
ente
d S
oftw
are
En
gin
eeri
ng Chapter 8,
Rationale Management
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 2
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 3
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 4
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 5
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 6
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 7
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 8
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 9
Centralized traffic control
CTC systems enable dispatchers to monitor and control trains remotely
CTC allows the planning of routes and re-planning in case of problems
T1291>
<T1515
Signals
Track circuits
Switches
Trains
S1
S2 S3
S4
SW1 SW2
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 10
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 11
input?:Issuedisplay?:Issue
Issues
Issues are concrete problem which usually do not have a unique, correct solution.
Issues are phrased as questions.
How should track sections be displayed?
How should the dispatcher input commands?
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 12
Proposals
Proposals are possible alternatives to issues. One proposal can be shared across multiple issues.
input?:Issue
addressed byaddressed byaddressed by
display?:Issue
text-based:Proposal point&click:Proposal
The interface for the dispatcher could be realized with a point &
click interface.
The display used by the dispatcher can be a text only
display with graphic characters to represent track segments.
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 13
input?:Issue
addressed byaddressed byaddressed by
display?:Issue
point&click:Proposal
Consequent issue
Consequent issues are issues raised by the introduction of a proposal.
terminal?:Issue
raises
Which terminal emulation should be used for the display?
text-based:Proposal
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 14
Criteria
A criteria represent a goodness measure. Criteria are often design goals or nonfunctional
requirements.
input?:Issue
availability$:Criterionusability$:Criterion
terminal?:Issue
addressed byaddressed byaddressed by
raises meets
fails
meets
fails
display?:Issue
point&click:Proposal
The time to input commands should be less than two seconds.
The CTC system should have at least a 99% availability.
text-based:Proposal
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 15
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 16
Arguments (2)
input?:Issue
availability$:Criterionusability$:Criterion
terminal?:Issue
addressed byaddressed byaddressed by
raises meets
fails
meets
fails
availability-first!:Argument
is supported by
is opposed by
display?:Issue
point&click:Proposal
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.
text-based:Proposal
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 17
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 18
Resolutions (2)
input?:Issue
availability$:Criterionusability$:Criterion
terminal?:Issue
addressed byaddressed byaddressed by
raises meets
fails
meets
fails
availability-first!:Argument
is supported by
is opposed by
text-based&keyboard:Resolution resolvesresolves
display?:Issue
point&click:Proposaltext-based:Proposal
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 19
Representing rationale: issue models
Proposal Criterion$
Issue?
meets +
fails -
is a consequence
responds
Argument!
supports +objects to -
supports +objects to -
Resolution.
resolves
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 20
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 21
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 22
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 23
Record and replay example: database discussion agenda
3. DiscussionI[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 24
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 25
Record and replay example: database discussion minutes
3. DiscussionI[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 26
Methodology by-product example:the Inquiry-Based Cycle
Question ?
Answer !
Reason .
ChallengeChange
Decide
Requirements
Discussion
Evolution
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 27
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 28
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 29
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 30
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 31
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