复习重点(修复的).doc

复习重点 组成派和决策派两种流派的软件架构概念的相同和区别； 将软件架构概念分为两大流派：组成派和决策派。 软件系统的架构将系统描述为计算组件及组件之间的交互。（“组成派”软件架构概念的典型代表） “组件”可以指子系统、框架（Framework）、模块、类等不同粒度的软件单元，它们可以担负不同的计算职责。 软件架构是在一些重要方面所作出的决策的集合。 组成派的观点更关注软件，倾向于“组件+交互”的思想 CRC卡： P10：案例 PM Tool是一个项目管理系统，提供项目计划、任务管理和资源管理等功能。 分离关注点的三种方法； 通过职责划分来分离关注点 它们所承担的职责都应该具有高内聚性 利用软件系统各部分的通用性的不同进行关注点分离 通过不同粒度级别分离关注点 框架和架构的联系和区别； 分层架构与mvc架构结合使用 联系： 框架技术和架构技术的出现，都是为了解决软件系统日益复杂所带来的困难而采取的“分而治之”思维的结果—先大局后局部，就出现了架构；先通用后专用，就出现了框架。架构是问题的抽象解决方案，它关注大局而忽略细节；而框架是通用半成品，还必须根据具体需求进一步定制开发才能变成应用系统。 能够简述软件架构的作用； 对新产品开发的作用： 上承业务目标，下接技术决策，控制复杂性，组织开发，利于迭代开发和增量交付，提高质量。 对软件产品线开发的作用： 固化核心知识，提供可重用资产，缩短推出产品的周期，降低开发和维护总成本，提高产品质量，支持批量定制。 对软件升级的作用： 进行软件架构重构，从而适应新需求及开发和维护的需要。 理解视图的概念以及多种视图多种角度进行架构设计的意义； 视图的概念： 一个架构视图是对于从某一视角或某一点上看到的系统所作的简化描述，描述中涵盖了系统的某一特定方面，而省略了与此方面无关的实体。 用户所需的功能和系统本身的结构一定是相互影响的，这正是软件架构师要特别关注的 实践指南：逻辑架构与物理架构： 逻辑架构：规定软件系统由那些逻辑元素组成及这些逻辑元素之间的关系。（逻辑元素划分准则：对关键机制相关的架构设计部分明确到类，而一般功能则到模块甚至子系统的接口定义即可） 逻辑架构的核心任务： 识别功能块 规划功能块的接口 明确功能块之间的使用关系和使用机制 物理架构：规定了组成软件系统的物理元素，这些物理元素之间的关系，以及它们部署到硬件上的策略。反映了软件系统动态运行时的组织情况。 从逻辑架构和物理架构到设计实现： 图P58 P59：设备调试系统案例： 软件架构设计的5视图： 逻辑架构： 关注功能，不仅包括用户可见的功能，还包括为实现用户功能而必须提供的“辅助功能模块”；它们可能是逻辑层、功能模块和类等； 关注“目标程序及其依赖的运行库和系统软件”最终如何安装或部署到物理机器，以及如何部署机器和网络来配合软件系统的可靠性、可伸缩性等要求。 关注程序包，不仅包括要编写的源程序，还包括可以直接使用的第三方SDK 运行架构： 关注进程、线程、对象等运行时概念，以及相关的并发、同步、通信等问题。 数据架构： 关注持久化数据的存储方案，不仅包括实体及实体关系的数据存储格式，还可能包括数据传递、数据复制和数据同步等策略。 概念性架构与实际架构的区别点和共同点； 区别点： 接口。在实际架构中，接口占据非常核心的地位；而概念性架构中没有接口的概念 子系统。实际架构重视通过子系统和模块来分割整个系统，并且子系统往往有明确的接口；而概念性架构中只有抽象的组件，这些组件没有接口只有职责，一般是处理组件、数据组件或连接组件中的一种。 交互机制。实际架构中的交互机制是“实在”的，如基于接口编程、消息机制或远程方法调用等等；而概念性架构中的交互机制是“概念化”的概念性架构和实际架构都满足软件架构的概念——“架构=组件+交互”，还是“架构=重要决策集”。 补充资料： 两个误区： 误区一：架构设计的驱动力 说法一：架构设计是功能需求驱动的。 错误。架构设计的驱动力 = 功能 + 质量 + 说法二：架构设计是用例驱动的。 错误。用例技术是功能需求实际上的标准，用例技术涉及，但无法全面涵盖非功能需求。 两种说法的实质是一样的。 同样，概念架构的驱动力也不仅仅是功能需求。 误区二：误把“阶段”当成“视图” 说法一：概念视图，有时也称为“逻辑视图”，这种视图显示了系统的主要部分及它们之间的相互关系。 说法二：“4”把“概念架构阶段”当成了“概念架构视图” 案例：分层模式 软件架构设计四条策略的策略内容、针对问题和关键点； 四条策略： 策略： 全面认识需求 关键需求决定架构： 多视图探寻架构 4、尽早验证架构 补充： 何谓好的软件架构设计： 所谓成功的架构设计,,并且在所花费的时间、技术决策