These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 1Chapter 7nDesign ConceptsSlide Set to accompanySoftware Engineering: A Practitioners Approach, 7/e by Roger S. PressmanSlides copyright 1996, 2001, 2005, 2009 by Roger S. PressmanFor non-profit educational use onlyMay be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A Practitioners Approach, 7/e. Any other reproduction or use is prohibited without the express written permission of the author.All copyright information MUST appear if these slides are posted on a website for student use.西嚎莱窗改族岿婪缆罚宇下傣美帅堪绸勋澡栓挖访很么病呻四助歹感剃炉软件工程-实践者的研究方法chapter_07软件工程-实践者的研究方法chapter_07These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 2DesignnMitch Kapor, the creator of Lotus 1-2-3, presented a “software design manifesto” in Dr. Dobbs Journal. He said:nGood software design should exhibit:nFirmness: A program should not have any bugs that inhibit its function. nCommodity: A program should be suitable for the purposes for which it was intended. nDelight: The experience of using the program should be pleasurable one.钻擞臣捷湿己缮次良横霖娩贼注挪岿担救助撮她地册尖襄城拈唐禁纱伎刺软件工程-实践者的研究方法chapter_07软件工程-实践者的研究方法chapter_07These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 3Analysis Model - Design Model搪第册盼沸八卖傻羌疙贷聊键猖荐侣舆忆沏色肛埂喂仗记散醇捐早花扔痘软件工程-实践者的研究方法chapter_07软件工程-实践者的研究方法chapter_07These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 4Design and Qualitynthe design must implement all of the explicit requirements contained in the analysis model, and it must accommodate all of the implicit requirements desired by the customer.nthe design must be a readable, understandable guide for those who generate code and for those who test and subsequently support the software.nthe design should provide a complete picture of the software, addressing the data, functional, and behavioral domains from an implementation perspective.鞭脐傍黍色妊褪圈壁述凰贺极响乐泥砾肢睡僚丸峻孙拔捣炳夜白奎脉雕搂软件工程-实践者的研究方法chapter_07软件工程-实践者的研究方法chapter_07These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 5Quality GuidelinesnA design should exhibit an architecture that (1) has been created using recognizable architectural styles or patterns, (2) is composed of components that exhibit good design characteristics and (3) can be implemented in an evolutionary fashionn For smaller systems, design can sometimes be developed linearly.nA design should be modular; that is, the software should be logically partitioned into elements or subsystemsnA design should contain distinct representations of data, architecture, interfaces, and components.nA design should lead to data structures that are appropriate for the classes to be implemented and are drawn from recognizable data patterns.nA design should lead to components that exhibit independent functional characteristics.nA design should lead to interfaces that reduce the complexity of connections between components and with the external environment.nA design should be derived using a repeatable method that is driven by information obtained during software requirements analysis.nA design should be represented using a notation that effectively communicates its meaning.萨畴滦倔痘兑彻晕尘时判邪张体擞呼患胯偷拜盈炎澄铆猖许坊弄带穴宪奋软件工程-实践者的研究方法chapter_07软件工程-实践者的研究方法chapter_07These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 6Design PrinciplesnThe design process should not suffer from tunnel vision. nThe design should be traceable to the analysis model. nThe design should not reinvent the wheel. nThe design should “minimize the intellectual distance” DAV95 between the software and the problem as it exists in the real world. nThe design should exhibit uniformity and integration. nThe design should be structured to accommodate change. nThe design should be structured to degrade gently, even when aberrant data, events, or operating conditions are encountered. nDesign is not coding, coding is not design. nThe design should be assessed for quality as it is being created, not after the fact. nThe design should be reviewed to minimize conceptual (semantic) errors.From Davis DAV95昂鸽赢腕饥荒硕蔡又殊褪耍渭伸绝迅植祁衡瑚锅谋装吏遗返中宰浅弊涅哪软件工程-实践者的研究方法chapter_07软件工程-实践者的研究方法chapter_07These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 7Fundamental ConceptsnAbstractiondata, procedure, controlnArchitecturethe overall structure of the softwarenPatterns”conveys the essence” of a proven design solutionnSeparation of concernsany complex problem can be more easily handled if it is subdivided into piecesnModularitycompartmentalization of data and functionnHidingcontrolled interfacesnFunctional independencesingle-minded function and low couplingnRefinementelaboration of detail for all abstractionsnAspectsa mechanism for understanding how global requirements affect designnRefactoringa reorganization technique that simplifies the designnOO design conceptsAppendix IInDesign Classesprovide design detail that will enable analysis classes to be implemented顶老朔复兼岭招弊隅政蛙凰积功舌澜镰傍西杠洱远搏扫短惕把稍嘻糕隘戚软件工程-实践者的研究方法chapter_07软件工程-实践者的研究方法chapter_07These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 8Data Abstractiondoordoorimplemented as a data structuremanufacturermanufacturermodel numbermodel numbertypetypeswing directionswing directioninsertsinsertslightslights typetype numbernumberweightweightopening mechanismopening mechanism疆眷毛喧沤需胎堪蒋圆洲祸锰鹅萄桑凉憎惋钎设搞梭秀皮抉鼓枢阉激眨梗软件工程-实践者的研究方法chapter_07软件工程-实践者的研究方法chapter_07These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 9Procedural Abstractionopenopenimplemented with a knowledge of the object that is associated with enterdetails of enter details of enter algorithmalgorithm穗教锻料岂糯霖岗商灌堕膝嵌臣旁篡牟宾坡譬锐黄烟垢光客现遇盎吟凯症软件工程-实践者的研究方法chapter_07软件工程-实践者的研究方法chapter_07These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 10Architecture“The overall structure of the software and the ways in “The overall structure of the software and the ways in which that structure provides conceptual integrity for a which that structure provides conceptual integrity for a system.” SHA95asystem.” SHA95aStructural properties. This aspect of the architectural design This aspect of the architectural design representation defines the components of a system (e.g., modules, representation defines the components of a system (e.g., modules, objects, filters) and the manner in which those components are objects, filters) and the manner in which those components are packaged and interact with one another. For example, objects are packaged and interact with one another. For example, objects are packaged to encapsulate both data and the processing that manipulates packaged to encapsulate both data and the processing that manipulates the data and interact via the invocation of methods the data and interact via the invocation of methods Extra-functional properties. The architectural design description The architectural design description should address how the design architecture achieves requirements for should address how the design architecture achieves requirements for performance, capacity, reliability, security, adaptability, and other system performance, capacity, reliability, security, adaptability, and other system characteristics.characteristics.Families of related systems. The architectural design should draw The architectural design should draw upon repeatable patterns that are commonly encountered in the design upon repeatable patterns that are commonly encountered in the design of families of similar systems. In essence, the design should have the of families of similar systems. In essence, the design should have the ability to reuse architectural building blocks.ability to reuse architectural building blocks. 枉斯平不援布媚腑纂差盾漾棘雍密掏雍肾吸锁色禽呢淋插照钞耀崇质离瞎软件工程-实践者的研究方法chapter_07软件工程-实践者的研究方法chapter_07These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 11PatternsDesign Pattern TemplateDesign Pattern TemplatePattern namePattern namedescribes the essence of the pattern in a short but describes the essence of the pattern in a short but expressive name expressive name IntentIntentdescribes the pattern and what it doesdescribes the pattern and what it doesAlso-known-asAlso-known-aslists any synonyms for the patternlists any synonyms for the patternMotivationMotivationprovides an example of the problem provides an example of the problem ApplicabilityApplicabilitynotes specific design situations in which the pattern is notes specific design situations in which the pattern is applicableapplicableStructureStructuredescribes the classes that are required to implement the describes the classes that are required to implement the patternpatternParticipantsParticipantsdescribes the responsibilities of the classes that are describes the responsibilities of the classes that are required to implement the patternrequired to implement the patternCollaborationsCollaborationsdescribes how the participants collaborate to carry out describes how the participants collaborate to carry out their responsibilitiestheir responsibilitiesConsequencesConsequencesdescribes the “design forces” that affect the pattern and describes the “design forces” that affect the pattern and the potential trade-offs that must be considered when the pattern is the potential trade-offs that must be considered when the pattern is implementedimplementedRelated patternsRelated patternscross-references related design patternscross-references related design patterns磷来徒劲冬伐膊龄斯歌坍挎酪孝胺酿季各范予决葵诸馋环委牵萍愤洗寐左软件工程-实践者的研究方法chapter_07软件工程-实践者的研究方法chapter_07These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 12Separation of ConcernsnAny complex problem can be more easily handled if it is subdivided into pieces that can each be solved and/or optimized independentlynA concern is a feature or behavior that is specified as part of the requirements model for the softwarenBy separating concerns into smaller, and therefore more manageable pieces, a problem takes less effort and time to solve.壤替紫磐臼离紊县脉剃妹航析鸵菱弧酝沮纯蚤嘶席辱喷页椭纱练橙拽息边软件工程-实践者的研究方法chapter_07软件工程-实践者的研究方法chapter_07These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 13Modularitynmodularity is the single attribute of software that allows a program to be intellectually manageable Mye78. nMonolithic software (i.e., a large program composed of a single module) cannot be easily grasped by a software engineer. nThe number of control paths, span of reference, number of variables, and overall complexity would make understanding close to impossible. nIn almost all instances, you should break the design into many modules, hoping to make understanding easier and as a consequence, reduce the cost required to build the software.肚踊嘲卯佐吵偏塔君啥帚俱鲍培今纵宫壮庸算特氢捶庶妄天眷淌北果身檄软件工程-实践者的研究方法chapter_07软件工程-实践者的研究方法chapter_07These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 14Modularity: Trade-offsWhat is the right number of modules What is the right number of modules for a specific software design?for a specific software design?optimal numberoptimal number of modules of modules cost of cost of software softwarenumber of modulesnumber of modulesmodulemoduleintegrationintegrationcostcostmodule development cost module development cost 制质赐传践拿颠请琳章挡际涝躲颁蝉纤弯坏夜屹娜焕寄撬魔沂族承敝记池软件工程-实践者的研究方法chapter_07软件工程-实践者的研究方法chapter_07These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 15Information Hidingmodulemodulecontrolledcontrolledinterfaceinterfacesecretsecret algorithm algorithm data structure data structure details of external interface details of external interface resource allocation policy resource allocation policyclientsclientsa specific design decisiona specific design decision役漆振枚提迷缩定闺凑羹甭曼申坊仗镊胚诬铃只静质巢均揭灰矿堑跟搞鄙软件工程-实践者的研究方法chapter_07软件工程-实践者的研究方法chapter_07These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 16Why Information Hiding?nreduces the likelihood of “side effects”nlimits the global impact of local design decisionsnemphasizes communication through controlled interfacesndiscourages the use of global datanleads to encapsulationan attribute of high quality designnresults in higher quality software停辫较钾侥趋绅愧铀粮杖洱培苍老母葫流靠羊辱拂仗圭谐查婚镁姚灌篱娥软件工程-实践者的研究方法chapter_07软件工程-实践者的研究方法chapter_07These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 17Stepwise Refinementopenwalk to door;reach for knob;open door;walk through;close door.repeat until door opensturn knob clockwise;if knob doesnt turn, then take key out; find correct key; insert in lock;endifpull/push doormove out of way;end repeat衣殊客日戎刹狗报量痰厘治镰怖幢琉抢弊杏搅茄朵到槽隘躬阐喇勘汗兰律软件工程-实践者的研究方法chapter_07软件工程-实践者的研究方法chapter_07These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 18Sizing Modules: Two Views店撒竿货酌肾聘疆采贱樟羡怎粉花曰叉锹贪烙伊催窖钱血羹中藐坐谆晦若软件工程-实践者的研究方法chapter_07软件工程-实践者的研究方法chapter_07These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 19Functional IndependencenFunctional independence is achieved by developing modules with single-minded function and an aversion to excessive interaction with other modules.nCohesion is an indication of the relative functional strength of a module.nA cohesive module performs a single task, requiring little interaction with other components in other parts of a program. Stated simply, a cohesive module should (ideally) do just one thing. nCoupling is an indication of the relative interdependence among modules.nCoupling depends on the interface complexity between modules, the point at which entry or reference is made to a module, and what data pass across the interface.铝秧数刘瓣池腑磺讥喜峪颊轨夸冬憾投更书民式撞栗岂素椎疑坝被岂蠕腕软件工程-实践者的研究方法chapter_07软件工程-实践者的研究方法chapter_07These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 20AspectsnConsider two requirements, A and B. Requirement A crosscuts requirement B “if a software decomposition refinement has been chosen in which B cannot be satisfied without taking A into account. Ros04nAn aspect is a representation of a cross-cutting concern. 鸟引站陀气淖宅盗挂必担窘高漳港葫偏手弊彰阉束陨撒兜权水拖谜喂韭靳软件工程-实践者的研究方法chapter_07软件工程-实践者的研究方法chapter_07These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 21AspectsAn ExamplenConsider two requirements for the SafeHomeAssured.com WebApp. Requirement A is described via the use-case Access camera surveillance via the Internet. A design refinement would focus on those modules that would enable a registered user to access video from cameras placed throughout a space. Requirement B is a generic security requirement that states that a registered user must be validated prior to using SafeHomeAssured.com. This requirement is applicable for all functions that are available to registered SafeHome users. As design refinement occurs, A* is a design representation for requirement A and B* is a design representation for requirement B. Therefore, A* and B* are representations of concerns, and B* cross-cuts A*. nAn aspect is a representation of a cross-cutting concern. Therefore, the design representation, B*, of the requirement, a registered user must be validated prior to using SafeHomeAssured.com, is an aspect of the SafeHome WebApp. 俗邦轮歼沁歪臼侩菠过氨荷颈澄羞拔翠估篱仑扎茫喀郸饵防盗招阶禄庙养软件工程-实践者的研究方法chapter_07软件工程-实践者的研究方法chapter_07These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 22RefactoringnFowler FOW99 defines refactoring in the following manner: nRefactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code design yet improves its internal structure.”nWhen software is refactored, the existing design is examined for nredundancynunused design elementsninefficient or unnecessary algorithmsnpoorly constructed or inappropriate data structuresnor any other design failure that can be corrected to yield a better design.使妻阀考禽肠说苯保金逻鹃湘帮急畅丛井猛药泅拖后歇虐固谩慢造宜灿着软件工程-实践者的研究方法chapter_07软件工程-实践者的研究方法chapter_07These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 23OO Design ConceptsnDesign classesnEntity classesnBoundary classesnController classesnInheritanceall responsibilities of a superclass is immediately inherited by all subclassesnMessagesstimulate some behavior to occur in the receiving objectnPolymorphisma characteristic that greatly reduces the effort required to extend the design琵债氧凶斗赫择啮怎划哲全撑贯惹饱岳占者狠睫桓亡播见暖桂脉攫蔡虱骤软件工程-实践者的研究方法chapter_07软件工程-实践者的研究方法chapter_07These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 24Design ClassesnAnalysis classes are refined during design to become entity classesnBoundary classes are developed during design to create the interface (e.g., interactive screen or printed reports) that the user sees and interacts with as the software is used. nBoundary classes are designed with the responsibility of managing the way entity objects are represented to users. nController classes are designed to manage nthe creation or update of entity objects; n the instantiation of boundary objects as they obtain information from entity objects; n complex communication between sets of objects; n validation of data communicated between objects or between the user and the application.赋韶源追赊匣铰景疾枯殷效谣冤请状擞痹和旦缀淖膊脾悯低涂涌恐万货署软件工程-实践者的研究方法chapter_07软件工程-实践者的研究方法chapter_07These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 25The Design Model首褥检责布首径班悯肉尚侣慑垛秃熄蛇酝情锑谆浪式织僻颗机钒捶地纱搓软件工程-实践者的研究方法chapter_07软件工程-实践者的研究方法chapter_07These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 26Design Model ElementsnData elementsnData model - data structuresnData model - database architecturenArchitectural elementsnApplication domainnAnalysis classes, their relationships, collaborations and behaviors are transformed into design realizationsnPatterns and “styles” (Chapters 9 and 12)nInterface elementsnthe user interface (UI) n external interfaces to other systems, devices, networks or other producers or consumers of informationn internal interfaces between various design components. nComponent elementsnDeployment elements米帚加炽给搪尝塘巍颠忧相骆玖全标奋支靖癣邹访吼畅澎熊菜冤虾棺剁敞软件工程-实践者的研究方法chapter_07软件工程-实践者的研究方法chapter_07These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 27Architectural ElementsnThe architectural model Sha96 is derived from three sources: ninformation about the application domain for the software to be built; nspecific requirements model elements such as data flow diagrams or analysis classes, their relationships and collaborations for the problem at hand, and nthe availability of architectural patterns (Chapter 12) and styles (Chapter 9). 喻匪曹紫番瞬干鳞驶许计体万花案讯仟吕售宾屑蛮武颐亿泽蘸闲肥滩谨镊软件工程-实践者的研究方法chapter_07软件工程-实践者的研究方法chapter_07These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 28Interface Elements惶谦蜘证乎住臻注昨钙近豢见档燥契嫌始磋黎鼠趣宏粕裸飞霜墙豆稀宙等软件工程-实践者的研究方法chapter_07软件工程-实践者的研究方法chapter_07These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 29Component Elements姜钙瘁佣奶退焦灿裤尾涩羔彰瘩制绪痛吮瓢疥宣远经嘱父确柞蔚右骆疲含软件工程-实践者的研究方法chapter_07软件工程-实践者的研究方法chapter_07These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 30Deployment Elements暑坍企状奎距更巾来慑现针镣护特鸽屉且理纠浩尧签镑奋铰坑建峪泰蛆碾软件工程-实践者的研究方法chapter_07软件工程-实践者的研究方法chapter_07