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


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


Overview

Rationale: What is it? Why should you care?

Rationale methods Representing rationale Authoring rationale Accessing rationale

State of practice & research Summary


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.


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


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


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


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


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


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?


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.


input?:Issue


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


Criteria

A criteria represent a goodness measure. Criteria are often design goals or nonfunctional

requirements.

input?:Issue

availability$:Criterionusability$:Criterion

terminal?:Issue


raises meets

fails

meets

fails

display?:Issue


The time to input commands should be less than two seconds.

The CTC system should have at least a 99% availability.

text-based:Proposal


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.


Arguments (2)

input?:Issue


terminal?:Issue


raises meets

fails

meets

fails

availability-first!:Argument

is supported by

is opposed by

display?:Issue


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


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.


Resolutions (2)

input?:Issue


terminal?:Issue


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


Representing rationale: issue models

Proposal Criterion$

Issue?

meets +

fails -

is a consequence

responds

Argument!

supports +objects to -

supports +objects to -

Resolution.

resolves


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


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


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.


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?


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.


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


Methodology by-product example:the Inquiry-Based Cycle

Question ?

Answer !

Reason .

ChallengeChange

Decide

Requirements

Discussion

Evolution


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


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


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


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


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

Chapter 8, Rationale Management

Documents

Transcript of Chapter 8, Rationale Management