软件工程概论sw04-capter5.1,5.2_设计.ppt

5.1.1 什么是“设计”？ 设计的目标：质量 瑞典的瓦萨战舰 时间：1620年代 背景：瑞典 vs. 波兰交战 用户：瑞典国王 需求：建造一艘巨型战舰，长70m， 载员300人，两层甲板、 64门重炮，以尽快结束战争。 此前从未有人设计过如此复杂的 战舰，荷兰设计师Henrik Hybertsson 穷尽毕生精力，设计完成，并建造下水。 大结局：1628年8月10日，Vasa战舰下 水，在鸣放了几响礼炮之后， 很快沉入水中。 瓦萨战舰的教训 合理切合实际的系统结构是保证系统成功运行的首要 因素。虽然Vasa战舰制造工艺精良，但船体比例严重 失调，体系结构存在致命缺陷； 设计师在无前人设计经验的基础上，既要执行国王的 “功能性”需求，又要考虑“性能”要求(如安全性、可 靠性、造价等)。面对诸多相互冲突的约束条件，做 出了错误的权衡，对一些不可能实现的要求作了妥协。 从建筑设计看软件设计 “设计良好的建筑应该展示出坚固、适用和令人赏心悦目的特点。” 对好的软件设计来说也是如此 坚固：软件应该不含任何 妨碍其功能的缺陷； 适用：软件要符合开发的 目标，满足用户需求； 赏心悦目：使用软件的体验应该是愉快的。 设计=天才+创造力 每个工程师都希望做设计工作，因为这里有 “创造性”——客户需求、业务要求和技术限 制都在某个产品或系统中得到集中的体现。 “设计”是最充分展现工程师个人水平的工作。 “设计”的本质 为问题域的外部可见行为的规约增添实际的计算机 系统实现所需的细节，包括关于人机交互、任务管 理和数据管理的细节。 — Coad/Yourdon 结构化的设计 设计=不断的作出决策 解决“How to do”，就需要不断的做出各种“设计决 策” ，在各类需求之间进行“折中”，使得最终设计 性能达到最优。 良好的设计的三个特征 设计必须是实现所有包含在分析模型中的明确需求、 以及客户期望的所有隐含需求； 5.1.2 将分析模型转换为设计模型 从工程管理的角度看， 软件设计包括： 概要设计： 详细设计： 5.2.2 为什么要提出“软件体系结构”  5.2 软件体系结构简介 “体系结构”一词起源于建筑学 如何使用基本的建筑模块构造一座完整的建筑？ 包含两个因素： 基本的建筑模块：砖、瓦、灰、沙、石、预制梁、柱、屋面板… 建筑模块之间的粘接关系：如何把这些 “砖、瓦、灰、沙、石、预制梁、柱、 屋面板”有机的组合起来形成整体建筑？ 1) 计算机硬件系统的“体系结构” 如何将设备组装起来形成完整的计算机硬件系统？ “体系结构”的共性 共性： 一组基本的构成要素——构件 这些要素之间的连接关系——连接件 这些要素连接之后形成的拓扑结构——物理分布 作用于这些要素或连接关系上的限制条件——约束 质量——性能 软件的架构与模式之经典架构 Layers（层次）架构模式 Fa?ade（门面）架构模式 Mediator（调停者）架构模式 Layers架构模式 横向划分将系统按照商业目的划分。比如一个书店的管理系统可以划分成为进货、销售、库存管理、员工管理等等。 纵向划分则不同，它按照抽象层次的高低，将系统划分成层，或叫Layer。比如一个公司的内网管理系统通常可以划分成为下面的几个Layer:　　 Layers架构模式 Layers架构模式的好处是： 第一、任何一层的变化都可以很好地局限于这一层，而不会影响到其他各层。 第二、更容易容纳新的技术和变化。Layers架构模式容许任何一层变更所使用的技术 Facade架构模式 Facade架构模式 Mediator架构模式 Mediator架构模式 Mediator架构模式 在Mediator模式中，所有的成员对象都可以协调工作，但是又不直接相互管理。 这些对象都与一个处于中心地位的调停者对象发生紧密的关系，由这个调 停者对象进行协调工作。 这个协调者对象叫做调停者（Mediator），而调停者所协调的成员对象称做同事（Colleague）对象。 Mediator架构模式 在Colleague 对象内部发生的事件会影响到所有的同事，但是这种影响不是以直接管理的方式直接传到其它的对象上的。 记住在小组的成员增加时，这样的相互作用关系是以比指数更快的方式增加的。 相反，这种影响仅仅直接影响到调停者对象，而调停者对象反过来会协调其它的同事，形成整个系统的行为。 如果小组的成员增加时，调停者对象可能会面临修改，而其它的同事则可以装做不知道这个新的成员一样，不