第五章[0]软件设计.pptVIP

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) 计算机硬件系统的“体系结构” 如何将设备组装起来形成完整的计算机硬件系统？ “体系结构”的共性 共性： 一组基本的构成要素——构件 这些要素之间的连接关系——连接件 这些要素连接之后形成的拓扑结构——物理分布 作用于这些要素或连接关系上的限制条件——约束 质量——性能 2) “软件体系结构”(Software Architecture) 提供了对软件系统的结构、行为和属性的抽象。 反映系统开发中具有重要影响的设计决策,便于 各种人员的交流，据此开发的系统能完成系统既 定的功能和性能需求。 (1) 构件(Component) 构件是具有某种功能的可复用的软件结构单元， 表示了系统中主要的计算元素和数据存储。 (2) 接口(Interface) 构件作为一个封装的实体，只能通过其接口与外 部环境交互； 芯片的管脚 内部结构则被隐藏起来(Black-box)； 一个构件至少有一个接口， 一个构件可以提供多重接口： 接不同的管脚，实现不同的功能。 构件接口与构件实现严格分开. (3) 服务(Service) 构件被看作一个“黑盒”(Black Box)，其内部具体的实现机制被封装和隐藏起来。 构件的功能以服务(Service)的形式体现出来，并通过接口向外发布，进而产生与其它构件之间的关联。 (4) 连接件(Connector) 连接件(Connector)：表示构件之间的交互并实现构 件之间的连接，如： 管道(pipe) 过程调用(procedure call) 事件广播(event broadcast) 客户机-服务器(client-server) 数据库连接(SQL) 连接件也可看作一类特殊的构件，区别在于： 一般构件是软件功能设计和实现的承载体； 连接件是负责完成构件之间信息交换和行为联系 的专用构件。 (5) 连接的协议(Protocol) 协议(Protocol)是连接的规约(Specifica