一、 认识软件架构
- 本书的主旨： 阐明企业目标、产品需求、设计师的经验、构架和最终系统之间的关系——它们构成带有回路的、可由开发组织实施管理的周期
- 架构商业周期(ABC)： 软件架构是技术、商业和社会等诸多因素作用的结果，而软件架构的存在反过来又会影响技术、商业和社会环境，从而影响到未来的架构（从环境到架构又返回到环境）
- 架构也是若干商业和技术决策的结果
1. 软件架构的概念
1. 定义：
是系统的一个或多个结构，他们由软件元素、这些元素的外部可见属性以及组件之间的关系组成，组件的外部可见性属性是指其他元素对该元素所做的假设
从下面六个方面来理解：
- 软件架构定义了软件元素
- 系统可能由多个结构组成
- 每个软件系统都有自己的架构
- 架构应建立在一定的设计原则之上
- 只要某个组件的行为可以从其它组件的角度观察到或区别开，这样的行为就是软件架构的内容
- 软件架构是抽象的，集中研究“黑盒”组件的行为和交互，是设计第一步
2. 其它观点
- 软件架构是高层次的设计
- 软件架构是软件系统的总体结构
- 构架是组件和连接器
- 软件架构是一个程序或系统的组件结构、组件之间的相互联系及管理其设计和演变的原则和方针的结构
- 软件架构是具有一定形式的结构化元素，包括处理元素、数据元素和连接元素。处理元素负责对数据进行加工，数据元素是被加工的信息，连接元素把架构的不同部分组合连接起来(Perry和Wo1f提出)
- 软件体系结构是软件设计过程中的一个层次，这一层次超越计算过程中的算法设计和数据结构设计(Mary Shaw和David Garlan)
-
软件体系结构有四个角度(Kruchten)：
- 概念角度描述系统的主要构件及它们之间的关系
- 模块角度包含功能分解与层次结构
- 运行角度描述了一个系统的动态结构
- 代码角度描述了各种代码和库函数在开发环境中的组织
1. 静态的角度：
- 模块结构 —— 体现了任务的划分，每个模块有其接口描述、代码和测试计划等，各模块通过父子关系联系起来，在开发和维护阶段用于分配任务和资源
- 分析类结构 ——子系统图、包图
- 类结构 —— 对象之间的继承或实例关系
2. 动态的角度：
- 进程结构 —— 运行系统的动态特征，包括进程间的同步关系、缺少不能运行、存在不能运行、先后等关系，与模块结构、概念结构成垂直正交关系
- 数据流 —— 模块之间可能发送数据的关系，最适合用于系统需求的追踪
- 控制流 —— 程序、模块或系统状态之间的“之后激活”的关系，适合于对系统功能行为和时序关系的验证
- 使用结构 —— 描述过程或模块之间的联系，这种联系是“假设正确存在”的关系，用于设计可轻松扩展的系统。如果过程A的运行必须以过程B的正确运行为前提，则说过程A使用过程B
- 调用结构 ——（子）过程之间调用和被调用的关系，可用来跟踪系统的执行过程
- 层次结构 —— 是一种特殊的使用结构，层就是相关功能的一致集合，在严格的分层结构中，第n层仅能使用第n-1层提供的服务
3. 部署的角度：
- 物理结构 —— 软件与硬件之间的映射关系，在分布式或并行系统中有重要意义
各种结构间的相互关系
- 各个结构都是从不同角度考察系统，但它们并不完全独立，它们之间的联系是多对多的
- 每个项目在开发时一般是注重一个结构，按照这一主要结构来考虑和运用其它结构
- 经验表明，系统规模越大，结构之间的差异越明显
3. 软件架构的影响
1. 架构受系统涉众的影响
涉众就是对系统构建感兴趣的人或组织
如：客户、最终用户、开发人员、项目经理、维护人员、对系统进行市场营销活动的人
4. 软件架构对影响的反作用
软件架构的商业周期：（下图）
-
性能： 指系统的响应能力——即对外部刺激（事件）做出反应时所需要的时间或在某段时间内所处理的事件个数
- 服务请求的到达速率
- 处理时间
- 队列大小
- 延迟时间长短
-
易用性：
- 可学习性
- 可记忆性
- 错误避免
- 错误处理
- 满意度
-
可测试性： 指通过测试（通常是基于运行的测试）揭示软件缺陷的容易程度
可测试性：指假设软件中至少有一个错误，软件在”下次“测试运行时不能正常工作的可能性
- 刺激源：可以是风险承担者、计算机系统等
- 刺激：可以看作是一个事件
- **环境：**系统当前的状态
- **制品：**系统中对事件作出反应的部分，可以是整个系统或系统的某一部分
- **反应：**事件到达后系统的相关行为
- **反应度量：**对反应结果提供某种形式的衡量
生成质量属性场景的目的和意义：
- 帮助构架师生成有意义的质量属性需求
- 使质量属性需求的描述规范化
- 某一场景是一类场景的代表，系统将以完全相同的方式对这些场景做出反应
质量场景创建的参与人员：
- 负责软件执行的人员—— 最终用户
- 负责管理系统的人员—— 系统管理员
- 负责更改系统运行时功能的人员—— 维护人员
- 负责系统规划的单位 —— 客户
- 负责项目实施的单位 —— 开发组织
5. 限制条件
4. 调用–返回样式
- 大型软件系统的主流构架样式
- 目标是实现系统的可更改性和可扩展性
- 主程序-子程序构架
- 远过程调用构架
- 面向对象构架
- 分层构架
5. 独立组件样式
通过解除各运算部分之间的耦合实现可更改性
- 事件系统样式
- 通讯进程样式
6. C/S样式
-
二层C/S结构：
局限：
- 二层C/S结构是单一服务器且以局域网为中心的，所以难以扩展至大型企业广域网或Internet
- 软、硬件的组合及集成能力有限
- 服务器的负荷太重，难以管理大量的客户机，系统的性能容易变坏
- 数据安全性不好
-
三层C/S结构：
- 表示层： 用户接口部分
- 业务层： 应用的本体
- 数据层： 数据库管理系统，负责管理对数据库数据的读写
优点：
- 允许合理地划分三层结构的功能，使之在逻辑上保持相对独立性，从而使整个系统的逻辑结构更为清晰，能提高系统的可维护性和可扩展性
- 允许更灵活有效地选用相应的软硬件平台，使之在处理能力和处理特性上分别适应于结构清晰的三层；并且这些平台和各个组成部分可以具有良好的可升级性和开放性
- 三层C/S结构中，各层可以并行开发，可以选择各自最适合的开发语言，维护也会更容易些
- 允许充分利用业务层有效地隔离开表示层与数据层，未授权的用户难以绕过业务层而利用数据库工具或黑客手段去非法地访问数据层，这就为严格的安全管理奠定了坚实的基础；整个系统的管理层次也更加合理和可控制
7. C2样式
基于构件和消息的体系结构模式，用于构建灵活的、可伸缩的软件系统
由层和线索的构件构成
- 层： 是由一组具有相同抽象级别的构件构成
- 线索： 是子系统的特例，它是由完成不同层次功能的构件组成（通过相互调用来关联），每一条线索完成整个系统中相对独立的一部分功能
主要特征：
- 正交软件体系结构由完成不同功能的n（n > 1）个线索（子系统）组成
- 系统具有m（m > 1）个不同抽象级别的层
- 线索之间是相互独立的（正交的）
- 系统有一个公共驱动层（一般为最高层）和公共数据结构（一般为最低层）
优点：
- 结构清晰，易于理解
- 易修改，可维护性强
- 可移植性强，重用粒度大
9. 构架的异质性
- 局部异质
- 层次异质
- 并行异质
3. 构架模式、参考模型与参考构架
- 构架模式 —— 是对元素和关系类型以及一组对其使用方式的限制的描述
- 参考模型 —— 是一种考虑数据流的功能划分，是对已知问题的标准分解，分解所得的各个部分相互协作，构成问题的解决方案
- 参考构架 —— 是映射到软件组件及组件之间数据流上的参考模型 ，即将功能划分与系统分解对应起来，这种对应不一定是一一映射
2. 可用性的战术
1. 局部化修改
是在设计期间为模块分配责任，以把预期的变更限制在一定的范围内，以降低修改成本
- 维持语义的一致性
- 预期期望的变更
- 泛化模块
- 限制可能的选择
2. 防止连锁反应
修改没有直接影响到的模块也需要改变，这是由于模块间存在依赖关系
依赖关系有：
- 语法
- 语义
- 顺序
防止连锁反应的战术有：
- 信息隐藏
- 维持现有的接口
- 添加接口
- 添加适配器
- 提供一个占位程序A
3. 推迟绑定时间
可以允许非开发人员进行修改，也可以延迟部署时间
- 运行时注册 —— 支持即插即用
- 配置文件 —— 启动时设置参数
- 多态 —— 允许方法调用的后期绑定
- 组件更换 —— 允许载入时间绑定
- 遵守已定义的协议 —— 允许独立进程的运行时绑定
4. 性能的战术
1. 抵抗攻击
- 对用户进行身份验证
- 对用户进行授权
- 维护数据的机密性
- 维护完整性
- 限制暴露的信息
- 限制访问
- 在外部用户和提供服务的系统之间设置认证服务器
- 把要保护的系统置于通讯防火墙之后
- 在某个可信内核的基础上构建系统，由该内核提供安全
2. 检测攻击
- 误用情况的检测是把通信模式与已知攻击的历史模式进行比较
- 异常情况的检测是把通信模式与其本身的历史基线（情况）进行比较
3. 从攻击中恢复
- 恢复状态
- 识别攻击者
6. 易用性战术
1. 运行时战术
- 维持任务的一个模型
- 维持用户的一个模型
- 维持系统的一个模型
2. 设计时战术
将用户接口与应用的其余部分分离开来
- 模型-视图-控制器
- 表示-抽象-控制
- Seeheim
- Arch/Slinky
7. 软件架构样式与战术的关系
- 软件架构样式从战略层面解决质量问题
- 战术是从具体部署上给出解决质量问题的局部策略
8. 战术举例
采用战术 敏感点 有风险决策 超出限制访问量的请求放在等待队列中 提高了系统的稳定性和可用性，减少了崩溃的可能 会降低对打并发数目，使得用户的等待时间过长，可能造成用户不满 缓存 提高系统的访问速度和性能 单服务器提供的缓存数目有限，并发用户数多的情况下，系统处理缓慢 每个IP每次只允许发出一个请求 合理的要求，避免了非法用户的恶意攻击 可能降低了易用性，但系统的安全性提高了 数据库连接池 数据库连接池允许应用程序重复使用一个现有的数据库连接，而不是重新建立一个，提高应用系统的性能 容错性 能够对用户出现的误操作进行检测和处理，并给出相应的处理信息，提高系统的可用性 系统备份与恢复 增强系统的容错能力 操作系统和数据库软件发生崩溃时，恢复时间较长 五、设计构架
1. 构架的设计
1. 基于构架的开发步骤：
- 为软件系统构建一个商业案例
- 弄清系统需求
- 构建或选用构架
- 正确表述此构架，并与有关各方进行交流
- 对此构架进行分析和评价
- 实现基于构架的系统并保证与构架相一致
- 系统维护时，构架文档应同步维护
2. 何时开始设计：
对需求有初步了解就可以开始设计
3. 构架驱动因素的组成：
比较重要的功能、质量属性、商业属性
4. 如何确定构架驱动因素：
业务目标优先级较高的要求
2. 良好架构的评判原则
1. 设计构架过程的建议：
- 构架的设计应该由一位设计师来完成，或在某位设计师领导下的小组来完成
- 设计师应全面掌握对系统的技术需求，以及对各项定性指标优先级的清单
- 构架的文档完备，至少有一个静态视图和动态视图，并采用所有人员认可的文档形式
- 构架设计方案应让各风险承担者积极参与评估
- 通过对构架分析，得出明确的定性与定量指标
- 构架设计应有助于增量式实现
- 允许构架带来一定的资源争用，并给出可行的解决方案
2. 构架结构的建议：
- 构架由定义良好的模块组成
- 模块的划分应体现出信息隐藏和相互独立的原则
- 采用特定于每个属性的众所周知的构架战术来实现质量属性
- 构架不依赖于某个特定版本的商用产品或工具
- 产生数据的模块和使用数据的模块分离
- 对并发系统，构架应采用定义良好的进程或任务
- 任务或进程编写要考虑到与特定处理器的关系，并容易改变关系
- 构架应采用少量的、简单的设计模式
3. 属性驱动的设计(ADD)
属性驱动的设计(Attribute Driven Design, ADD)把一组质量属性场景作为输入，利用对质量属性实现与构架设计之间的关系的了解，对构架进行设计
ADD构架设计的步骤如下：
- 样本输入
- 选择要分解的模块
- 根据下列步骤对模块进行求精：
- 从具体的质量场景和功能需求集合中选择构架驱动因素
- 选择满足构架驱动因素的构架模式
- 实例化模块并根据用例分配功能，使用多个视图进行表示
- 定义子模块的接口
- 验证用例和质量场景并对其进行求精，使它们成为子模块的限制
- 对需要进一步分解的每个模块重复上述步骤
4. 创建骨架系统
创建骨架系统的思想是提供一种基本能力，以一种对项目有力的顺序实现系统的功能
1. 原因：
- 提高开发效率，鼓舞士气
- 能更早发现复杂的依赖关系
- 使开发人员更多关注在设想中最难以实现的部分
- 能够缩短系统集成时间，降低其成本，并使集成成本更明确
- 便于评审和测试
2. 步骤：
- 实现处理构架组件的执行和交互的软件部分
- 实现规则引擎（带有规则的原型集）以控制在基于规则的系统中规则的激发
- 逐步进行测试
5. 团队结构的形成
- 开发小组的结构反映了构架的模块结构
- 开发小组要做到松耦合，高内聚
- 开发组织对构架也会有影响
6. 架构师的职责
- 了解所在组织的业务目标，使架构更好地支持业务目标
- 规划产品的开发与演进
- 规划和建设架构级的重用，如产品线等
- 领导并负责架构设计，定义系统的高层结构和接口
- 为项目管理提供支持，如技术可行性、任务划分、人员招聘
- 领导和协调项目组的主要技术活动，对主要技术产品负责实际参与架构原型的开发实现
- 讲解架构、指导详细设计和开发、协调冲突以实现既定的构架目标
- 规划和协助软件架构的评审
- 评估新技术并提出采用建议
六、构架评审的一般方法
1. 成本与收益
1. 成本
- 人员时间成本
- 构架评审部门的组织开销构
- 架评审部门要求高级设计人员参与的代价
2. 收益(优点)
- 及早发现现有构架中存在的问题
- 构架的改进
- 财务收益
- 强制为评审做准备
- 捕获构架设计的基本思想
- 验证需求的有效性
2. 评审的一般技巧
1. 定性分析
是指凭分析者的直觉、经验，凭分析对象过去和现在的延续状况及最新的信息资料，对分析对象的性质、特点、发展变化规律作出判断的一种方法
定性技巧——提问技巧
- 场景—描述风险承担者和系统之间的具体交互
- 评审清单—对同一领域的若干系统进行评估后提出的一组详细的问题
- 问卷—适用于所有构架的若干问题的清单
2. 定量分析
是依据实际统计数据，建立数学模型，并用数学模型计算出分析对象的各项指标及其数值的一种方法
定量技巧
- 指标—对构架可观察到的参数的量化解释
- 模拟、原型与实验
3. 评审实践
1. 评审前提
- 评审环境—预先规划
- 项目代表—风险承担者，子系统或组件负责人
-
评审小组
- 评审小组的人员公证、客观、受尊重
- 成员必须专门从事评审工作
- 有对构架相关问题熟悉的人，其领导具有设计、评价经验
- 至少有一位该系统所属领域的专家
- 有专人负责文档、后勤，办公地点离评审对象近，有学徒
-
组织的期望—用合同明确
- 构架评审结束时应向谁报告什么内容
- 评审的标准是什么
- 向评审小组提供那些资源及人力
- 对评审小组和项目组以后的工作有什么期望
- 预计评审持续的最长时间
-
评审的准备—制定评审日程
- 系统需求文档
- 架构文档，包括架构描述及介绍构架决策思想的材料
- 将系统的质量属性和功能要求按重要程度排序出前面3-5个
2. 评审实施
- 按问题的重要性进行分类
- 强调那些与构架相符或相悖的重要问题
- 必须记载评审中所提的每个问题
3. 评审结果
- 对评审中的各个问题都要做出正式的阐述，同时也要对赖以确定这些问题的数据做出相应的说明
4. 总结
构架评审的主要指导原则如下：
- 把由独立部门实施的正规的构架评审作为项目开发周期规划的一部分
- 选择评审的最佳时间，尽早预审一次
- 选择恰当的评审技巧
- 签署评审合同
- 限制所要评审的质量属性的个数
- 要保证评审小组中有构架方面的专家、领域专家、资料员及后勤员
- 一定要有系统设计师
- 收集各种场景数据，并在此基础上形成评审清单
5. 评审（分析）软件架构的原因
- 架构师风险承担者交流的平台、是早期设计决策的体现、是可传递的系统抽象（架构级重用）
- 系统的质量属性不可能在
来源：yin__ren
声明：本站部分文章及图片转载于互联网，内容版权归原作者所有，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！