DONET架构设计六技.ppt

第三技：功能质量，综合考虑 高性能 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） 可扩展性（Extensibility） 可维护性（Maintainability） 可移植性（Portability） 找到合适你的质量分类 FURPS McCall ISO 运行期质量 + 开发期质量 …… 有奖问答 包括可扩展性、可管理性等在内的质量要求，以下正确的是 可扩展性越强越好，所有可以想到的情况统统支持，不计成本 有经验的架构师懂得借助场景技术，理性决定支持哪些扩展、如何支持扩展 设计模式影响性能 “可管理性”往往转化成一组“功能需求”，如用户管理功能、备份功能、参数配置功能、运行监视功能等 议 程 功能与架构 质量与架构 约束与架构 总结 约束的常见类型 技术性约束：采用何种OS、采用何种技术、需要和哪些遗留系统互操作…… 标准性约束：不同行业、大型企业集团的相关行业标准、企业标准…… 法规性约束：相关法律、法规、政府规章、行政规定…… 架构师实际面临更多约束 第五技：约束分析，必不可少 第六技：正交表法，掌控全局 对比：经典的需求分类方式 ?正交表方法，推荐给大家！ 业务目标 快好省 组织级约束 用户需求 运行期质量 用户级约束 行为需求 开发期质量 乙方约束 用户 开发 组织 广义功能 质量 约束 案例：连锁超市系统 提高收银效率 投资少，工期短 (投资多,使用期长) 要求在Linux上运行 与原有物流系统整合 用户电脑水平偏低 开发人员分散在不同地点 用户 开发 组织 广义功能 质量 约束 案例：连锁超市系统 提高收银效率 （业务需求） 单笔取消功能 （用户需求） 鲁棒性 (Robustness) 用户电脑 水平偏低 POS终端按键触发状态转换然后扫描或输入商品ID （行为需求） 案例：连锁超市系统 工期短 投资少 松耦合 团队熟悉A技术 不可选昂贵的中间件 开发人员分散在不同地点 选择A技术 否定B技术 案例：连锁超市系统 投资较多 预期使用期长 原有物流系统整合 互操作性 基于MOM的整合策略 实际当中约束的影响 实际当中约束的影响 有奖问答 关于功能、质量、约束这三类需求，以下正确的是 需求变更主要来自功能需求 一般而言，质量需求最稳定 约束只需遵守即可 约束仅存在于技术方面 约束仅来自客户方 议 程 功能与架构 质量与架构 约束与架构 总结 系统方法总结 谢 谢！ QA 如 何 下 载 本 PPT 大会网站 松耦合空间 资深咨询顾问 软件架构专家 架构设计高级培训讲师 《软件架构设计》作者 Email: shanghaiwenyu@163.com MSN: shanghaiwenyu@ 当然也不是用例驱动 当然也不是用例驱动 架构设计六技 从需求向架构过渡的系统方法 温 昱