CS427: Software Engineering IAdministrative infoTopics on designArchitectureArchitecture is used to:Object-oriented designResponsibility-driven designSlide 8Slide 9OODWhat order?Data-centered architectureSlide 13Transaction-orientedTransactionsWork-pieceSlide 17Realtime-controlTrade-offsQuality AttributesATAMSlide 22What is an architect?Your projectsNext: Quality Assurance1CS427:Software Engineering IDarko Marinov(slides from Ralph Johnson)CS427 19-2Administrative infoNew Wiki serverhttp://pixie.cs.uiuc.edu:8080/SEcoursePlease report broken links (such as for HW3)HW3 is due on Tuesday, Nov. 7State machines and ADTsProject groups should start meeting TAsGet feedback on projects from TAsOffice hours: Mon 3-4, Tue 10-11, Thu 2-3CS427 19-3Topics on designPreviouslyComponent-level designModularity and abstractionRefinementXP example (for analysis and design)TodayOO design (and some RUP reminders) Time permitting: revisit Viking exampleCS427 19-4ArchitectureEarly design decisionsHigh-levelPervasiveExpensive to changeArchitectural stylesCS427 19-5Architecture is used to:Decide what design problems to work on firstDivide the system into modulesDivide the developers into teamsSubcontract work to other groupsDecide what technology to useCS427 19-6Object-oriented designHow to view objects/classes in your software systemBook describes three methodsBoochEvolved into UML/RUPSchlaer-MellerObject information, object state, processing/actionsResponsibility-driven designObjects and their collaborationsCS427 19-7Responsibility-driven designObject model is made up of cardsEach card represents a classClass listsName, superclassResponsibilitiesCollaboratorsCS427 19-8Responsibility-driven designStart with a “scenario” – a use caseAdd to classes/responsibilities/ collaborations to implement scenarioOnly change classes because of scenarioComplaint? Invent a scenario!CS427 19-9Responsibility-driven designLike RUP and XPUse case drivenIncrementalLike XPLousy documentationBest seen liveCS427 19-10OODWhat is OOD good for?Business systemsGUIsEditorWhat is it bad for?Real-time controlCompilers?CS427 19-11What order?Use cases first?Processes first? Data model first?GUI first?Depends on architectural styleCS427 19-12Data-centered architectureDatabase design is keyNot hard to add data, can be hard to changeBehavior less important, easy to changeRUP can be overkillXP can be a problem because refactoring a RDBMS schema can be hardCS427 19-13Data-centered architectureDB2Enter ImmunizationEdit immunization types and rulesSend Reminder LettersCreate PatientEdit PatientCS427 19-14Transaction-orientedTransactions are stored in a databaseTimecards and paychecks (payroll)Purchases and sales (retail)Telephone calls (telephone billing)System keeps track of totalsTotals are function of transactionsRules for computing totals tend to be complex and frequently changeCS427 19-15TransactionsSales JournalCash registers Sales proc.InventoryTextbookTradebookCredit CardsReceivingCS427 19-16Work-pieceUser is manipulating complex dataData only changes when user changes itModel of what user is thinking, not of the worldUser interface is often importantEfficiency usually is not importantIdeal for object-oriented programmingCS427 19-17Work-pieceBinaryExpressionSpreadsheet InterfaceCell*SpreadsheetRuleCellReference2*dependentCS427 19-18Realtime-controlSystem must respond in a short time to events in the real worldMust be efficient enoughData usually trivial, GUI usually simpleUsually contains feedback loopsCS427 19-19Trade-offsHow do you pick an architectural style?Depends on what you knowDepends on architectural qualities that are importantWhat is important?Flexibility and ease of changeEfficiencyReliabilityCS427 19-20Quality AttributesDesired properties of entire system, not particular featuresNon-functional requirementsUsability, maintainability, flexibility, understandability, reliability, efficiency, ...CS427 19-21ATAMArchitectural Trade-off Analysis MethodCollect scenarios (architectural use cases)Collect requirements, constraints, and environment descriptionsDescribe candidate architectural stylesEvaluate quality attributesIdentify sensitivity of quality attributesCritique candidate architecturesCS427 19-22Trade-offsHow it is really doneExperts pick a way that seems best and start to use itIf problems arise, they reconsiderA paper on general decision-making http://www.fastcompany.com/online/38/klein.htmlCS427 19-23What is an architect?Responsible for choosing architectureResponsible for communicating with clientResponsible for making trade-offs about featuresChief builder - “Architect also implements”Leader of developersCS427 19-24Your projectsMore than one person can play the architect roleMore than one person MUST implement parts of the codeBut not everyone has to implement codeDocument your processTAs will provide more detailed grading criteriaCS427 19-25Next: Quality AssuranceHamlet and Maybee, Chapter 19 on Testing (not 17 or