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

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend