温昱 软件开发大会演章节稿.pptVIP

业内对架构的讨论仍沿用了传统思想：如果知道了系统需求，就可以为此系统构建架构。这种观点是缺乏远见的…… ——Len Bass 定 位 原理：功能 and 职责协作链 第一技：通过协作，识别职责 第二技：缩小范围，事半功倍 如何确定关键功能需求 核心功能 标志：业务层的接口要反映这些功能 必须实现的功能 往往来自甲方的要求。 覆盖了系统架构的一些方面，而其他功能没有 例如…… 实现风险高的功能 例如…… 案 例 有意义吗 概念性架构设计过程 概念性架构设计过程 概念性架构设计过程 概念性架构设计过程 有奖问答 架构设计的“决定因素” 用例驱动的（功能需求驱动的） 非功能需求驱动的 包括功能、非功能的综合因素驱动的 根本不存在所谓“决定因素”，应靠经验 原理：质量属性对架构的影响 功能需求：连接两岸的公路交通 桥墩支撑的公路桥 约束条件：不能影响万吨轮从桥下通过 规定桥墩的高度和桥墩间距 使用期质量：在湍急的江流中保持稳固 把桥墩建在岩石层之上 建造期质量：施工方便性 继续确认和调整架构 第三技：功能质量，综合考虑 Cache机制 著名定义中的两个错误 架构风格到接口一级了么？ 非功能需求的设计要另起炉灶么？ 软件架构包含了关于以下问题的重要决策： 软件系统的组织； 选择组成系统的结构元素和它们之间的接口，以及当这些元素相互协作时所体现的行为； 如何组合这些元素，使它们逐渐合成为更大的子系统； 用于指导系统组织的架构风格：这些元素以及它们的接口、协作和组合。 软件架构不仅注重软件本身的结构和行为，还注重其他特性：使用、功能性、性能、弹性、重用、可理解性、经济和技术的限制及权衡、以及美学等。 第四技：分门别类，深入理解 运行期质量 + 开发期质量 找到合适你的质量分类 FURPS McCall ISO 运行期质量 + 开发期质量 …… 有奖问答 包括可扩展性、可管理性等在内的质量要求，以下正确的是 可扩展性越强越好，所有可以想到的情况统统支持，不计成本 有经验的架构师懂得借助场景技术，理性决定支持哪些扩展、如何支持扩展 设计模式影响性能 “可管理性”往往转化成一组“功能需求”，如用户管理功能、备份功能、参数配置功能、运行监视功能等 约束的常见类型 技术性约束：采用何种OS、采用何种技术、需要和哪些遗留系统互操作…… 标准性约束：不同行业、大型企业集团的相关行业标准、企业标准…… 法规性约束：相关法律、法规、政府规章、行政规定…… 架构师实际面临更多约束 第五技：约束分析，必不可少 第六技：正交表法，掌控全局 对比：经典的需求分类方式 ?正交表方法，推荐给大家！ 案例：连锁超市系统 案例：连锁超市系统 案例：连锁超市系统 案例：连锁超市系统 实际当中约束的影响 实际当中约束的影响 有奖问答 关于功能、质量、约束这三类需求，以下正确的是 需求变更主要来自功能需求 一般而言，质量需求最稳定 约束只需遵守即可 约束仅存在于技术方面 约束仅来自客户方 系统方法总结 谢 谢！ QA 如 何 下 载 本 PPT 大会网站 松耦合空间 当然也不是用例驱动 当然也不是用例驱动 高性能 易理解性（Understandability） 可扩展性（Extensibility） 可重用性（Reusability） 可测试性（Testability） 可维护性（Maintainability） 可移植性（Portability） 性能（Performance） 安全性（Security） 易用性（Usability） 持续可用性（Availability） 可伸缩性（Scalability） 互操作性（Interoperability） 可靠性（Reliability） 鲁棒性（Robustness） 开发期质量属性 运行期质量属性 演 进 开发期质量属性 运行期质量属性 可扩展性（Extensibility） 可维护性（Maintainability） 可移植性（Portability） 可伸缩性（Scalability） 易理解性（Understandability） 可测试性（Testability） 可重用性（Reusability） 性能（Performance） 安全性（Security） 易用性（Usability） 持续可用性（Availability） 互操作性（Interoperability） 可靠性（Reliability） 鲁棒性（Robustness） 议 程 功能与架构 质量与架构 约束与架构 总结 乙方约束 开发期质量 行为需求 用户级约束 运行期质量 用