Lecture for Chapter 12, Rationale Management
Download
Report
Transcript Lecture for Chapter 12, Rationale Management
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 circ uits
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 C ategory
Win C ondition
involves
Issue
addresses
Option
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
_
Authentication
C onfidentiality
Integrity
OR
Account+PIN
Finger Print Reader
Sm artC ard+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
Decision Proble
Alternative
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