rationale management chapter 12 an aircraft example
play

Rationale Management Chapter 12, An aircraft example A320 First - PDF document

Object-Oriented Software Engineering Using UML, Patterns, and Java Rationale Management Chapter 12, An aircraft example A320 First fly-by-wire passenger aircraft 150 seats, short to medium haul A319 & A321 Derivatives of A320


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

  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 Design rationale ♦ Reduce pilot training & maintenance costs ♦ Increase flexibility for airline Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 2

  3. An aircraft example (2) A330 & A340 ♦ Long haul and ultra long haul ♦ 2x seats, 3x range ♦ Similar handling as A320 family Design 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 H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 3

  4. Overview: rationale ♦ What is rationale? ♦ Why is it critical in software engineering? ♦ Centralized traffic control example ♦ Rationale in project management ! Consensus building ! Consistency with goals ! Rapid knowledge construction ♦ Summary Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 4

  5. What is rationale? Rationale is the reasoning that lead 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 5

  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 -> high maintenance cost -> loss & rediscovery of information Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 6

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

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

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

  10. Centralized traffic control Trains S2 T1291> S3 Track circuits 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 10

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

  12. Issues ♦ Issues are concrete problem which usually do not have a unique, correct solution. ♦ Issues are phrased as questions. i npu t? : I ssue d isp lay?: Issue How shou ld t he d i spa tche r i npu t How shou ld t r ack sec t i o ns be com mands? d i sp layed? Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 12

  13. Proposals ♦ Proposals are possible alternatives to issues. ♦ One proposal can be shared across multiple issues. i npu t? : I s sue d i sp lay?: I s sue addressed by addressed by addressed by t ex t -based:Proposa l po in t&cl i ck :Proposa l The d i spl a y used by t he d i spa tche r can be a t ex t on l y d i sp lay wi th g raph i c char ac te r s t o r ep resen t t r ack segmen t s . The i n ter f ace f o r t he d i spa tche r c ou ld be r ea l i zed wi th a po in t & c l i ck i n te r f ace . Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 13

  14. Consequent issue ♦ Consequent issues are issues raised by the introduction of a proposal. i npu t? : I s sue d i sp lay?: I s sue add ressed by add ressed by add ressed by t ex t - based :P roposa l po in t&c l i ck :P roposa l ra ises t e rminal ? : I ssue Which t e rm ina l emu la t i o n shou ld be used f o r t he di sp l ay? Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 14

  15. Criteria ♦ A criteria represent a goodness measure. ♦ Criteria are often design goals or nonfunctional requirements. i npu t? : I s sue d i sp lay?: I s sue add ressed by add ressed by add ressed by t ex t - based :P roposa l po in t&c l i ck :P roposa l r a i ses meets meets t e rm ina l ? : I ssue f a i l s f a i l s usab i l i t y$ :Cr i ter ion ava i lab i l i t y$ :Cr i t e r ion The CTC sys tem shou l d have at l eas t The t ime to i nput commands shou ld be l ess a 99% ava i l ab i l i t y . t han two seconds . Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 15

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

  17. Arguments (2) i npu t? : I s sue d i sp lay?: I s sue add ressed by add ressed by add ressed by t ex t - based :P roposa l po in t&c l i ck :P roposa l r a i ses meets meets t e rm ina l ? : I ssue i s opposed by f a i l s f a i l s usab i l i t y $ :C r i t e r i on ava i l ab i l i t y$ :C r i t e r i on i s suppor ted by ava i lab i l i t y - f i r s t ! :Argument Po in t&c l i c k i n te r f aces a re mo re c omp lex t o imp lement t h an tex t - based i n t e r f aces. Hence , t hey a re a l so more d i f f i cu l t t o t es t . The po in t&c l i c k i n te r f ace r i s k si n t r oduc ing f a tal e r ro r s i n the sys tem t ha t wou l d o f f se t any usab i l i t y bene f i t t he i n t e r f ace wou ld p rov ide . Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 17

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

  19. Resolutions (2) t ex t -based&keyboard :Reso lut ion reso lves reso lves i npu t? : I s sue d i sp lay?: I s sue add ressed by add ressed by add ressed by t ex t - based :P roposa l po in t&c l i ck :P roposa l r a i ses meets meets t e rm ina l ? : I ssue i s opposed by f a i l s f a i l s usab i l i t y $ :C r i t e r i on ava i l ab i l i t y$ :C r i t e r i on i s suppor t ed by ava i l ab i l i t y - f i r s t ! : Argumen t Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 19

Recommend


More recommend