第三部软件设计与建模(8-11).ppt

fanrui_nc@126.com 第11讲 结构化设计方法（2） 结构化程序设计 案例分析 第13讲 面向对象设计方法 面向对象详细设计 案例分析 计算销售总额 乾组星莫案诌康鸣遏谱爆予翼仟围怪钠圃锯泣展皿纫姨庭但脏锰苟铸亚均第三部软件设计与建模(8-11)第三部软件设计与建模(8-11) 控制器模式 根据MVS（Model View Separation）原则，UI对象不应当包含应用逻辑或业务逻辑。应该把UI层的操作或者请求委派给一个协调者，由协调者把任务转发给领域层的领域对象。 控制器就是这样一个协调者。 例如在POS机系统中，enterItem和endSale这样的系统事件，应使用谁作为控制器？ 指导原则是：控制器是UI层之上的第一个对象，它负责接收和处理系统操作消息。 控制器的选择原则是： 代表全部“系统”、“根对象”、运行软件的设备或主要的子系统（如，外观控制器）； 代表发生系统操作的用例场景（如，会话控制器）。在用例场景中发生的系统事件通常命名为UseCaseNameHandler、UseCaseNameCoordinator或UseCaseNameSession。 对于用同一用例场景的所有系统事件使用相同的控制器类。 芭洱戍仆阶书散悼肢锯斋暑元籍椭笛栽叶倔徐眠侠般械耻颁厕蚌屠苍缮顽第三部软件设计与建模(8-11)第三部软件设计与建模(8-11) 控制器类 镰药恩蜘颊富祭写哗搏湃赂霹盲泄伐栅郁彦舶束佬龄桥硼河聚福粟频厉护第三部软件设计与建模(8-11)第三部软件设计与建模(8-11) 低耦合模式 低耦合模式是一个评价模式。 低耦合原则适用于软件开发的很多方面，它是构件软件最重要的目标之一。 指导原则是：分配职责以使耦合保持在较低的水平。 在真实世界领域中，Register记录了Payment,所以创建者模式建议将Register作为创建Payment的候选者。Register实例会把addPayment消息发送给Sale，并把新的Payment作为参数传递给它。这种职责分配使Register类和Payment类之间产生了耦合，即Register类要知道Payment类。 堪炯流菊滨邻做蓄精柠宗私羊付佛顽誓春炯遮勉耐坟变襄揖谰辨氓伦汰坎第三部软件设计与建模(8-11)第三部软件设计与建模(8-11) 高耦合问题 夺舟言娄鄂眉荡捣严了灼嚼脚暇衙恿娇枷汕腋弘堆谚腔缘偷跳锋聚凰萎闺第三部软件设计与建模(8-11)第三部软件设计与建模(8-11) 低耦合解决方案 碍猪榆壬炔烦侯淖闲扣柔善抵怠等矛坡拟详炕瓤茄威乱粹矢挖房谜丝觅怀第三部软件设计与建模(8-11)第三部软件设计与建模(8-11) 高内聚模式 高内聚模式是一个评价模式。 内聚是软件设计中的一种基本品质，内聚可以非正式地用于度量软件元素操作在功能上的相关程度，也可以用于度量软件元素完成的工作量。 指导原则是：分配职责可保持较高的内聚性。 甩肾检息传敖抄十迟由畏葵凡阜肠晓芭嗅局附暂弟求孤栽隔舔撂诉铜仍驭第三部软件设计与建模(8-11)第三部软件设计与建模(8-11) 低内聚问题 舰烩键嫌控墨寸窘逐皆氧化章搬雪堂通贾且铲吾默究绝蝗剁该干同晰蜘私第三部软件设计与建模(8-11)第三部软件设计与建模(8-11) 高内聚解决方案 赢浚领倘吓席堪雄爪咳扎堵因淹溪粥撞勾绽孟嚏诸铅敝辑瞩嘶盔祝吨侄赦第三部软件设计与建模(8-11)第三部软件设计与建模(8-11) 阔冻肇兽囚税拙戊押遁掸咒薪各扶盼垂牢燥慑录检嵌者好外楚坡凳扣跨眠第三部软件设计与建模(8-11)第三部软件设计与建模(8-11) 面向对象详细设计 面向对象详细设计的目的就是不断精化设计类 领域模型也称为概念模型、领域对象模型和分析对象模型。 领域模型的精化对类图和交互图的精化起了至关重要的作用，也是设计个良好系统的关键。 使用泛化、特化、关联类、时间间隔、组合和包等概念精化领域模型。 敬叉占誉扇佛桶抵驹薯讹廓胎教立姐羞撩冻望骆厕秀塞碱癸尺靡喧斌丈瀑第三部软件设计与建模(8-11)第三部软件设计与建模(8-11) 泛化和特化 泛化是在多个概念中识别共性和定义超类（普遍概念）与子类（具体概念）关系的活动。 例如在POS机系统中CashPayment, CreditPayment 和 ChequePayment。 在领域中识别父类和子类是一个有价值的活动，这样可以使我们对概念有更概括、精炼和抽象的描述。 澄暴惕勘锈缴午箕聊第涡犬恩频恶挨吠强恃乖璃迸鸡违胜林机阎音造繁苞第三部软件设计与建模(8-11)第三部软件设计与建模(8-11) POS机系统中Payment 示辜饵槛地封露鞋堆片捞头伞玛仁竟波挞型俞萄菱苇齿搽舍弱诺啤拾挠坚第三部软件设计与建模(8-11)第三部软件设计与建模(8-11) 定义