1. Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 12: Rationale Management

2. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 2 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

3. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 3 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.

4. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 4 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

5. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 5 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

6. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 6 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

7. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 7 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

8. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 8 display?:Issueinput?:Issue Issues  Issues are concrete problem which usually do not have a unique, correct solution.  Issues are phrased as questions. How should the dispatcher input commands? How should track sections be displayed?

9. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 9 display?:Issue addressed by input?:Issue text-based:Proposalpoint&click:Proposal Proposals  Proposals are possible alternatives to issues.  One proposal can be shared across multiple issues. 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.

10. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 10 display?:Issue terminal?:Issue addressed by raises input?:Issue text-based:Proposalpoint&click:Proposal Consequent issue  Consequent issues are issues raised by the introduction of a proposal. Which terminal emulation should be used for the display?

11. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 11 display?:Issue availability$:Criterionusability$:Criterion terminal?:Issue addressed by raisesmeets fails meets fails input?:Issue text-based:Proposalpoint&click:Proposal Criteria  A criteria represent a goodness measure.  Criteria are often design goals or nonfunctional requirements. The CTC system should have at least a 99% availability. The time to input commands should be less than two seconds.

12. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 12 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.

13. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 13 Arguments (2) display?:Issue availability$:Criterionusability$:Criterion terminal?:Issue addressed by raisesmeets fails meets fails availability-first!:Argument is supported by is opposed by input?:Issue text-based:Proposalpoint&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.

14. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 14 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.

15. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 15 Resolutions (2) display?:Issue availability$:Criterionusability$:Criterion terminal?:Issue addressed by raisesmeets fails meets fails availability-first!:Argument is supported by is opposed by text-based&keyboard :Resolution resolves input?:Issue text-based:Proposalpoint&click:Proposal

16. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 16 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

17. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 17 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.

18. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 18 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

19. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 19 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.

20. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 20 Centralized traffic control  CTC systems enable dispatchers to monitor and control trains remotely  CTC allows the planning of routes and replanning in case of problems

21. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 21 Centralized traffic control (2) CTC systems are ideal examples of rationale capture:  Long lived systems (some systems include 19 th century relays)  Extended maintenance life cycle  Although not life critical, downtime is expensive  Low tolerance for bugs  Transition to mature technology needs careful planning

22. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 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?

23. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 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.

24. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 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].

25. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 25 Methodology by-product example: the Inquiry-Based Cycle Question ? Answer ! Reason.  Challenge Change Decide Requirements Discussion Evolution

26. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 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

27. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 27 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

28. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 28 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)

29. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 29 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

30. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 30 Consensus building: Negotiation Model

31. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 31 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

32. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 32 Model Structure  Domain Taxonomy  Requirements structure  Stakeholders  Create WinConditions  WinWin Artifacts  Documents decision process  Can relate to analysis documentation  COCOMO  Risk Analysis  Agreements lead to requirements WinWin artifact WinWin Taxonomy WinConditionIssueOptionAgreement Taxonomy Element relates to  Priority has  Stakeholder creates  has  resolved by  leads to   provides solution for Statement  becomes  creates Analysis Artifacts documented by  Feature expressed as  Use Case related to 

33. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 33 Consensus building: Process 2. Identify stakeholders’ win conditions 3. Reconcile win conditions. Establish alternatives. 4. Evaluate & resolve risks. 5. Define solution 6. Validate 7. Review & commit 1. Identify stakeholders

34. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 34 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.

35. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 35 Consensus building: WinWin tool

36. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 36

37. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 37 Consensus building: Experiences Context  Initial case studies used project courses with real customers  Used in industry Results  Risk management focus  Trust building between developers and clients  Discipline  Inadequate tool support

38. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 38 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.

39. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 39 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

40. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 40 Consistency with goals: Model   

41. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 41 Consistency with goals: Process Elicit high-level goals Refine into detailed goals Identify goal dependencies Identify operational goals Evaluate alternatives

42. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 42 Consistency with goals: Experiences  Case studies on existing systems lead to clearer trade-offs  Research into integrating NFR framework and design patterns  Match NFRs to design pattern “Forces”  Link NFRs, design patterns, and functional requirements  Tool support inexistent

43. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 43 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.

44. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 44 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.

45. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 45 Rapid knowledge construction: Knowledge Map

46. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 46 Nodes in the Knowledge Map  Questions  Ideas / answers  Arguments – pros and cons  Decisions  Notes  References

47. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 47 Rapid knowledge construction: Generating Document Templates

48. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 48

49. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 49 Rapid knowledge Construction: Experiences Context  Several industrial case studies, including Y2K contingency planning at Bell Atlantic Results  Increased meeting efficiency (templates are reused)  Knowledge reused for other tasks

50. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 50 Questions, Options, Criteria  Designed for capturing rationale after the fact, for long term use (e.g., quality assessment).  QOC emphasizes systematic evaluation of options against criteria Option !Criterion $ Question ? positive assessment + negative assessment - consequent question response Argument. supports + objects-to - supports + objects-to -

51. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 51 Other issue models: Decision Representation Language

52. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 52 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