Object-Oriented Software Engineering An aircraft example Chapter 12, A320 ♦ First fly-by-wire passenger aircraft Rationale Management ♦ 150 seats, short to medium haul Using UML, Patterns, and Java 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 An aircraft example (2) Overview: rationale A330 & A340 ♦ What is rationale? ♦ Long haul and ultra long haul ♦ Why is it critical in software engineering? ♦ 2x seats, 3x range ♦ Centralized traffic control example ♦ Similar handling as A320 family ♦ Rationale in project management ! Consensus building ! Consistency with goals Design rationale ! Rapid knowledge construction ♦ With minimum cross training, A320 pilots can be certified to ♦ Summary 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 Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 4 What is rationale? Why is rationale important in software engineering? Rationale is the reasoning that lead to the system. Many software systems are like aircraft: Rationale includes: They result from a large number of decisions taken over an extended period of time. ♦ the issues that were addressed, ♦ the alternatives that were considered, ♦ Evolving assumptions ♦ the decisions that were made to resolve the issues, ♦ Legacy decisions ♦ the criteria that were used to guide decisions, and ♦ Conflicting criteria ♦ the debate developers went through to reach a decision. -> high maintenance cost -> loss & rediscovery of information Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 5 Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 6
Uses of rationale in software engineering Representing rationale: issue models ♦ Improve design support Argumentation is the most promising approach so far: ! Avoid duplicate evaluation of poor alternatives ♦ More information than document: captures trade-offs and ! Make consistent and explicit trade-offs discarded alternatives that design documents do not. ♦ Less messy than communication records: communication ♦ Improve documentation support records contain everything. ! Makes it easier for non developers (e.g., managers, lawyers, technical writers) to review the design Issue models represent arguments in a semi-structure form: ♦ Improve maintenance support ♦ Nodes represent argument steps ! Provide maintainers with design context ♦ Links represent their relationships ♦ 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 Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 8 ATM Example Centralized traffic control Trains Question: Alternative Authentication Mechanisms? References: Service: Authenticate S2 T1291> S3 Track circuits Decision: Smart Card + PIN Signals Switches Criteria 1: Criteria 2: SW1 SW2 <T1515 ATM Unit Cost Privacy S1 S4 Option 1: Account number + – Option 2: Finger print reader – + ♦ CTC systems enable dispatchers to monitor and control trains remotely Option 3: Smart Card + PIN + + ♦ 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 9 Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 10 Centralized traffic control (2) Issues CTC systems are ideal examples of rationale capture: ♦ Issues are concrete problem which usually do not have a unique, correct solution. ♦ Long lived systems (some systems include relays installed last ♦ Issues are phrased as questions. century) ! Extended maintenance life cycle input? : Issue disp lay?: Issue ♦ Although not life critical, downtime is expensive ! Low tolerance for bugs How shou ld t he d i spa tche r i npu t How shou ld t rack sec t i ons be com mands? d isp layed? ! Transition to mature technology Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 11 Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 12
Proposals Consequent issue ♦ Proposals are possible alternatives to issues. ♦ Consequent issues are issues raised by the introduction of a proposal. ♦ One proposal can be shared across multiple issues. i npu t? : I ssue d isp lay? : I ssue i npu t? : I ssue d isp lay? : I ssue add ressed by add ressed by add ressed by addressed by addressed by addressed by t ex t -based :P roposa l po in t&c l i ck :P roposa l tex t -based:Proposa l poin t&c l ick :Proposa l ra ises te rmina l? : Issue The d i sp lay used by t he d i s pa tche r can be a t ex t on l y d i sp lay w i t h g raph i c cha rac te rs t o rep resen t t r ack segmen ts . Which te rm ina l emu la t i on s hou ld be used The i n te r face fo r t he d i spa tc her cou ld be f o r t he d i sp lay? rea l i zed w i th a po in t & c l i c k i n t e r face . Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 13 Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 14 Criteria Arguments ♦ A criteria represent a goodness measure. ♦ Arguments represent the debate developers went through to ♦ Criteria are often design goals or nonfunctional arrive to resolve the issue. requirements. ♦ Arguments can support or oppose any other part of the i npu t? : I ssue d isp lay? : I ssue rationale. add ressed by add ressed by add ressed by ♦ Arguments constitute the most part of rationale. t ex t -based :P roposa l po in t&c l i ck :P roposa l ra i ses meets meets t e rm ina l? : I ssue fa i l s fa i l s usab i l i t y$ :Cr i te r ion ava i lab i l i t y$ :Cr i te r ion The CTC sys tem shou ld have a t l eas t The t ime to i npu t 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 Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 16 Arguments (2) Resolutions i npu t? : I ssue d isp lay? : I ssue ♦ Resolutions represent decisions. add ressed by add ressed by add ressed by ♦ A resolution summarizes the chosen alternative and the t ex t -based :P roposa l po in t&c l i ck :P roposa l argument supporting it. ra i ses meets meets ♦ A resolved issue is said to be closed. ♦ A resolved issue can be re-opened if necessary, in which case t e rm ina l? : I ssue the resolution is demoted. 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 rs t ! :Argument Po in t&c l i ck i n te r faces a re more comp lex to imp lemen t t han tex t -based i n te r faces . Hence , t hey are a l so more d i f f i cu l t t o t est . The po in t&c l i ck i n te r f ace r i s ksi n t roduc ing fa ta l e r ro rs i n t he sys tem tha t wou ld o f f se t any usab i l i t y bene f i t t he i n te r f a ce wou ld p rov ide . Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 17 Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 18
Recommend
More recommend