1. Conquering Complex and Changing Systems Object-Oriented Software Engineering Rationale Management Bernd Brügge Allen Dutoit Technische Universität München Applied Software Engineering July 5, 2005

2. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 2 Announcements No exercises tomorrow (July 6, 2005) Next week (July 12, 2005) Guest lecture by Frank Mang, Accenture Topic: Writing Project Proposals Two weeks from today (July 19, 2005) Written exam (for students who need it) Open book (OOSE, slides, notes, dictionary, etc.) No electronic devices (laptops, PDAs, etc.)

3. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 3 Overview: rationale What is rationale? Why is it critical in software engineering? Centralized traffic control example Rationale in project management Meeting management Consensus building Consistency with goals Summary

4. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 4 What is rationale? Rationale has nothing to do with… Rational, Inc. (now IBM Rational) Rose, ClearQuest, ClearCase Rational thinking Governed by evidence and logic As opposed to emotion or prejudice Rationale is the reasoning or principle that underlies a particular course of action Rationale is the answer to the question why

5. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 5 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

6. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 6 Why is rationale important in software engineering? Many software systems are like aircraft: They result from a large number of decisions taken over an extended period of time. Evolving assumptions Legacy decisions Conflicting criteria Loss of rationale leads to -> High maintenance cost -> Reconstruction of information

7. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 7 Uses of rationale 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

8. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 8 Representing rationale: issue models Argumentation is the most promising approach so far: More information than documents Captures trade-offs and discarded alternatives that design documents do not. More structure than communication records Communication records contain everything. Issue models represent arguments in a semi-structured form: Nodes represent argument steps Links represent their relationships

9. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 9 Decision: Smart Card + PIN ATM Example Question: Alternative Authentication Mechanisms? References: Service: Authenticate Option 1: Account number Option 2: Finger print reader Option 3: Smart Card + PIN Criteria 1: ATM Unit Cost Criteria 2: Privacy + + +– +–

10. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 10 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

11. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 11 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 Although not life critical, downtime is expensive Low tolerance for bugs Transition to mature technology

12. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 12 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?

13. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 13 display?:Issue addressed by input?:Issue text-based:Optionpoint&click:Option Options Options are possible alternatives to issues. One option 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.

14. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 14 display?:Issue selection?:Issue addressed by raises input?:Issue text-based:Optionpoint&click:Option Consequent issue Consequent issues are issues raised by the introduction of a proposal. How should trains be selected?

15. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 15 display?:Issue availability$:Criterionusability$:Criterion selection?:Issue addressed by raisesmeets fails meets fails input?:Issue text-based:Optionpoint&click:Option Criteria A criteria represent a goodness measure. Criteria are often design goals or nonfunctional requirements. The time to input commands should be less than two seconds. The CTC system should have at least a 99% availability.

16. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 16 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.

17. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 17 Arguments (2) display?:Issue availability$:Criterionusability$:Criterion selection?:Issue addressed by raisesmeets fails meets fails availability-first!:Argument is supported by is opposed by input?:Issue text-based:Optionpoint&click:Option 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.

18. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 18 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.

19. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 19 Resolutions (2) display?:Issue availability$:Criterionusability$:Criterion selection?: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:Optionpoint&click:Option

20. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 20 Questions, Options, Criteria Designed for capturing rationale after the fact (e.g., quality assessment). QOC emphasizes criteria Option !Criterion $ Question ? positive assessment + negative assessment - consequent question response Argument. supports + objects-to - supports + objects-to -

21. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 21 Other issue models: Decision Representation Language

22. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 22 Overview: rationale What is rationale? Why is it critical in software engineering? Centralized traffic control example Rationale in project management Meeting management Consensus building Consistency with goals Summary

23. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 23 Meeting Management: Goals Keep meetings short Define scope of meeting before hand Focus only on issues within scope Invite the right participants Do not invite participants who cannot contribute Do invite participants whose agreement is needed Record to agreements for closed items Ensure that all remember the same outcome Record context for open items Shorten follow up discussions on the same theme

24. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 24 Meeting Management: Concepts Agenda assigned to Decision selected by Issue scoped by Participant invites Option addressed by assessed by Action Item realized by Argument supports opposes Criterion makes explicit Minutes records

25. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 25 Meeting Documents Agenda Defines the scope of the meeting in terms of open issues (from the Issue Database) Invites participants whose agreement is needed to resolve the issues A time budget is allocated to each issue before the meeting Minutes For each issue o Records decisions and their realization, OR o Records the current progress of the discussion in terms of options, criteria, and arguments

26. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 26 Meeting Roles Facilitator Responsible for keeping the meeting within scope Interupts or redirects participants who get side tracked Ensures that decisions represent consensus Time keeper Informs the facilitator when an specific issue takes more time than budgeted Minute taker Records decisions, action items, options, … Distributes the meeting minutes to all other participants shortly after the meeting

27. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 27 ParticipantMinute TakerFacilitator Meeting Activities Post Agenda Review Agenda Revise Agenda Initiate Meeting Facilitate Meeting Discuss & Resolve Issues Record Meeting Close Meeting Realize Action Items Post Minutes

28. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 28 Example Issue Database

29. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 29 Example Agenda AGENDA: Integration of access control and notification 1. Purpose The first revisions of the hardware/software mapping and the persistent storage design have been completed. The access control model needs to be defined and its integration with the current subsystems, such as NotificationService and TrackingSubsystem, needs to be defined. 2. Desired outcome Resolve issues about the integration of access control with notification. 3. Information sharing [Allocated time: 15 minutes] AI[1]: Dave: Investigate the access control model provided by the middleware. 4. Discussion [Allocated time: 35 minutes] I[1]: Can a dispatcher see other dispatchers TrackSections ? I[2]: Can a dispatcher modify another dispatchers TrackSections ? I[3]: How should access control be integrated with TrackSections and NotificationService ? 5. Wrap up [Allocated time: 5 minutes] Review and assign new action items. Meeting critique.

30. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 30 Example Unstructured Minutes Integration of access control and notification 4. Discussion... I[3]: How should access control be integrated with TrackSections and NotificationService ? Dave: The TrackSection maintains an access list. The notification service asks the TrackSection about who has access. Alice: We should probably reverse the dependency between TrackSection and NotificationService. Instead, the UIClient requests subscriptions from the TrackSection, which checks for access and then calls the NotificationService. This way, all protected methods are in one place. Dave: This way the TrackSection can also more easily unsubscribe dispatchers when their access is revoked. Ed: Hey, no need for access control in NotificationService : Dispatchers can see all TrackSections. As long as the NotificationService is not used for changing the TrackSection state, there is no need to restrict subscriptions. Alice: But thinking about the access control on notification would be more general. Ed: But more complex. Lets just separate access control and notification at this point and revisit the issue if the requirements change. Alice:Ok. Ill take care of revising the TrackingSubsystem API....

31. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 31 Example Structured Minutes STRUCTURED MINUTES: Integration of access control and notification 4. Discussion... I[3]: How should access control be integrated with TrackSections and NotificationService ? P[3.1]:TrackSections maintain an access list of who can examine or modify the state of the TrackSection. To subscribe to events, a subsystem sends a request to the NotificationService, which in turns sends a request to the corresponding TrackSection to check access. P[3.2]:TrackSections host all protected operations. The UIClient requests subscription to TrackSection events by sending a request to the TrackSection, which checks access and sends a request to the NotificationService. A[3.1] for P[3.2]: Access control and protected operations are centralized into a single class. P[3.3]: There is no need to restrict the access to the event subscription. The UIClient requests subscriptions directly from the NotificationService. The NotificationService need not check access. A[3.2] for P[3.3] Dispatchers can see the state of any TrackSections (see R[1] ). A[3.3] for P[3.3] : Simplicity. R[3]: P[3.3]. See action item AI[2]....

32. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 32 Consensus building Problem Any realistic project suffers the tension of conflicting goals Stakeholders come from different background Stakeholders have different criteria Example Requirements engineering Client: business process (cost and schedule) User: functionality Developer: architecture Manager: development process (cost and schedule)

33. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 33 Consensus building: WinWin Incremental, risk-driven spiral process Identification of stakeholders Identification of win conditions Conflict resolution Groupware tool Stakeholders post win conditions Facilitator detects conflict Stakeholders discuss alternatives Stakeholders make agreements

34. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 34 Consensus building: Model

35. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 35 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

36. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 36 Consensus building: EasyWinWin tool

37. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 37 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.

38. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 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

39. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 39 Consistency with goals: Model x

40. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 40 Consistency with goals: Process Elicit high-level goals Refine into detailed goals Identify goal dependencies Identify operational goals Evaluate alternatives

41. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 41 Summary Rationale can be used in project management To manage meetings To build consensus (WinWin) To ensure quality (NFR Framework) Other uses include Architectural design Risk management Change management Process improvement … Open issues Cost User acceptance