实用软件架构技术郭树行博士2009-11-5.ppt

?正交表方法，推荐给大家！ 业务目标 快好省 组织级约束 用户需求 运行期质量 用户级约束 行为需求 开发期质量 乙方约束 用户 开发 组织 广义功能 质量 约束 案例：连锁超市系统 提高收银效率 投资少，工期短 (投资多,使用期长) 要求在Linux上运行 与原有物流系统整合 用户电脑水平偏低 开发人员分散在不同地点 用户 开发 组织 广义功能 质量 约束 案例：连锁超市系统 提高收银效率 （业务需求） 单笔取消功能 （用户需求） 鲁棒性 (Robustness) 用户电脑 水平偏低 POS终端按键触发状态转换然后扫描或输入商品ID （行为需求） 案例：连锁超市系统 工期短 投资少 松耦合 团队熟悉A技术 不可选昂贵的中间件 开发人员分散在不同地点 选择A技术 否定B技术 案例：连锁超市系统 投资较多 预期使用期长 原有物流系统整合 互操作性 基于MOM的整合策略 实际当中约束的影响 实际当中约束的影响 有奖问答 关于功能、质量、约束这三类需求，以下正确的是 需求变更主要来自功能需求 一般而言，质量需求最稳定 约束只需遵守即可 约束仅存在于技术方面 约束仅来自客户方 议 程 功能与架构 质量与架构 约束与架构 总结 系统方法总结 谢 谢！ QA 当然也不是用例驱动 当然也不是用例驱动 实用软件架构技术 郭树行 博士 2009-11-5 业内对架构的讨论仍沿用了传统思想：如果知道了系统需求，就可以为此系统构建架构。这种观点是缺乏远见的…… ——Len Bass 定 位 议 程 功能与架构 质量与架构 约束与架构 总结 原理：功能 and 职责协作链 查看任务 分配任务 修改任务 第一技：通过协作，识别职责 第二技：缩小范围，事半功倍 如何确定关键功能需求 核心功能 标志：业务层的接口要反映这些功能 必须实现的功能 往往来自甲方的要求。 覆盖了系统架构的一些方面，而其他功能没有 例如…… 实现风险高的功能 例如…… 案 例 有意义吗 展现层 业务层 数据层 概念性架构设计过程 概念性架构设计过程 概念性架构设计过程 概念性架构设计过程 有奖问答 架构设计的“决定因素” 用例驱动的（功能需求驱动的） 非功能需求驱动的 包括功能、非功能的综合因素驱动的 根本不存在所谓“决定因素”，应靠经验 议 程 功能与架构 质量与架构 约束与架构 总结 原理：质量属性对架构的影响 功能需求：连接两岸的公路交通 桥墩支撑的公路桥 约束条件：不能影响万吨轮从桥下通过 规定桥墩的高度和桥墩间距 使用期质量：在湍急的江流中保持稳固 把桥墩建在岩石层之上 建造期质量：施工方便性 继续确认和调整架构 第三技：功能质量，综合考虑 高性能 Cache机制 著名定义中的两个错误 架构风格到接口一级了么？ 非功能需求的设计要另起炉灶么？ 软件架构包含了关于以下问题的重要决策： 软件系统的组织； 选择组成系统的结构元素和它们之间的接口，以及当这些元素相互协作时所体现的行为； 如何组合这些元素，使它们逐渐合成为更大的子系统； 用于指导系统组织的架构风格：这些元素以及它们的接口、协作和组合。 软件架构不仅注重软件本身的结构和行为，还注重其他特性：使用、功能性、性能、弹性、重用、可理解性、经济和技术的限制及权衡、以及美学等。 第四技：分门别类，深入理解 运行期质量属性 开发期质量属性 性能（Performance） 安全性（Security） 易用性（Usability） 持续可用性（Availability） 可伸缩性（Scalability） 互操作性（Interoperability） 可靠性（Reliability） 鲁棒性（Robustness） 易理解性（Understandability） 可扩展性（Extensibility） 可重用性（Reusability） 可测试性（Testability） 可维护性（Maintainability） 可移植性（Portability） 运行期质量 + 开发期质量 运行期质量属性 开发期质量属性 性能（Performance） 安全性（Security） 易用性（Usability） 持续可用性（Availability） 互操作性（Interoperability） 可靠性（Reliability） 鲁棒性（Robustness） 易理解性（Understandability） 可测试性（Testability） 可重用性（Reusability） 演 进 可伸缩性（Scalability） 可扩展性（Extensib