软件过程续

1软件工程过程
  任何工业化生产都离不开过程
 大规模，有组织，有序的
 软件工程过程
 合理使用软件生产制造技术，定义谁（Who) 什么时候(When) 做什么（What），以及如何（How)达到确定目标
 将用户需求转化为软件系统的所有活动的集合
  开发一个新的产品
  增强已开发产品的功能（修复bug,或者添加功能）　　
 新建和改变的需求->软件工程过程->新建和改变的需求         
有效的过程
 1保证产品的质量，迅速减少项目的风险（需求，技术，政治风险等）
 2保证项目的可预测性（进度，成本，功能等）
 3能够捕获和提供最佳实践方法（Best Practice)
 4促进领域内（软件开发）的共识和相互理解
   成功的软件开发=开发技术(面向对象的分析技术+结构化设计方法+基于构件的开发方法） +开发过程（RUP ,CMM,XP，瀑布模型，螺旋模型）+CASE TOOL (Rationl ROSE Rup builder)
开发方法(基于团队的开发）=UML（统一建模语言）+RUP (统一过程）
 建模语言
  表述设计方法的表示法
  主要是图形化的
 开发过程
  对开发中 所采取步骤的指导
  将建模语言置于特定的语境（开发环境）之中

 RUP  囊括的最佳实践方法,是可定制的通用过程框架
   迭代开发，管理需求，使用基于构件的架构 ，可视化的建模，质量验证，控制变更
          核心技术 用例需求(Use Case)驱动的，以构架(Architecture)为中心的，迭代(Iterative)和增量的(Incremental)开发方式
 什么是用例（Use Case)
  软件系统的特征：服务于特定用户
  用例描述用户（User)需求
   用户:与所开发系统交互的人或其他系统
   所有用例构成系统的全部功能和边界
  UML 规范说明中的定义
     用例：在不展现系统或子系统内部结构的情况下,对系统或子系统的某个连贯的功能单元的定义
  Use Case  基本模型元素符号
                   Actor(参与者)表示与系统交互的任何事物
       Use Case (用例) 定义了系统的一系列动作，并向参与者提供有价值的结果
  RUP 是用例驱动的
 需求分析阶段用户需求用Use Case 来表达
 设计初期很多类根据  Use Case 来发现
 构造阶段开发的管理和任务分配按造Use Case 来组织
 测试阶段的实例根据Use Case 来生成
       用例是有序迭代开发的基础
 为编写最终用户手册提供索引(Index)
 抽取可单独出售的系统单元(Business Comonent
 以架构为中心的RUP
 软件架购  系统的重要元素，子系统，类，构件，节点，以及他们之间的通过接口实现的协作
 软件系统的组织（结构与行为)
 架构风格(数据流风格,调用/返回风格等)
      .功能，性能，适应性，重要性，技术约束，美学考虑
      架构描述=架构模型（是概念和知识）+架构视图(表达模型的方式)
  统一过程以架构为中心
 架构为用户和开发人员提供系统的整体视图
 架构是系统实现的基础
 为项目管理提供基本指导
 架构描述是软件系统的主要制品
 以架构为中心的优点
 创建可重用的框架，是构架级的重用成为可能
 从构架可以方便地得到其他制品
 形成产品结构系列(企业版,家用版)
      开发队伍结构
 简化基于构件的开发
  迭代和增量的RUP
 统一过程是迭代和增量的过程
 迭代
   '迭代是统一过程中最小的开发时间单位，包含了软件开发的所有工作流，可看作袖珍瀑布模型
 增量 是每次迭代所产生的，可增加系统功能的构造块
迭代是开发方式,增量是开发结果
 迭代工作流: 一次迭代 :需求->分析->设计->实现->测试
 迭代是什么
  是明确活动的集合
 是有序的，受控的开发方式
 是能够产生内部版本的袖珍项目 
 是项目开发过程中具体执行的工作流
 迭代不是什么
 不是任意的探路
 不是重复设计同样的东西
 不是只影响开发人员
 不是项目失败的理由
 可以降低风险
 尽早处理风险和重要风险，同时将项目开发的总风险分散到每次的迭代中
 小步前进
  允许系统灵活改变，更易于处理不断变化的需求
 受控增长
 避免回头开发，允许连续的系统集成
 增强信心
使用户和开发人员都可以看到系统中不断增加的可运行功能，对项目进度充满信心
 用例驱动，架构中心和迭代与增量
 用例驱动系统架构的设计
 系统 架构影响用例的实现
 用例体现了系统的功能(function)
 构架反映了系统的表现形式（Form)
 用例设定了目标，构架建立了模式，开发人员根据目标和模式规划产品迭代开发的顺序
Agile 方法的产生
           针对以上问题，产生了一系列轻载(lightweight)方法 如XP  SCRUM 等
 light weight->agile
 Agile 方法含义: 是保证软件开发成功产出的前提下，尽量减少开发过程的活动和制品的方法，笼统的将就是，“刚刚好"(Just Enough ),即开发中的活动及制品既不要太多
也不要太到。
 核心理念
   基于适应而非预测
 以人为导向而非过程导向
  自适应系统是一个强反馈系统
 在软件开发中，需求的获取和分析，软件设计，编码，等实质均为前馈环节，真正的反馈环节应该是用户对可运行软件的使用，使用中的判断及判断后与开发人员的信息交流
 反馈和前馈这一回路的响应速度应大于被跟踪（或被适应）的系统的变化速度，这就要求软件开发有快速的产出能力
        特点:通过快速，短迭代式的开发，不断产出，和演化可运行的软件，根据用户的反馈信息作适应性调整，然后进入下一轮快速短迭代式开发
 软件开发中
 人是过程的主体，而人的工作承受力是有限的，
软件开发中的大部分是需要创造力的设计工作，软件人员是创造性的工作者
 软件人员有主观上作好工作的意愿
 软件开发的目的是为人提供方便，应首先着眼于有用的可执行软件，也就是首先考虑商务目标，而不是为过程而过程
 强调开发中的中间过程和制品（文挡）
 追根揭底其目的是为了交流
项目失败的原因追溯到某个信息没有及时准确地传递到应该接收它的人
人特别擅长面对面的交流，面对面的交流成本远远低于文档交流的成本
努力营照诚信，开放的组织氛围，根据项目中信息流通的具体情况，按照高内聚，松耦合的原则，将项目划分为若干个小组
通过小组内各种渠道的沟通，来减少中间制品的工作负担，提高应变能一
 任何软件开发方法都有一个相应的价值系统，方法通过价值系统对过程予以指导，方法只有在其应用周境与价值系统相吻合时才能发挥真正效力
 Agile 联盟提出了'四个价值',"十二个指导原则"
   较之于过程和工具，更注重人极其相互作用的价值
 较之于无所不及的各类文档，更注重可运行的软件的价值
 较之于合同谈判，更注重与客户合作的价值
  较之于按计划行事，更注重适应需求的变化
指导原则
  在快速不断地交付用户可运行的软件的过程，将是拥护满意放到第一位
 以积极的态度对待需求的变化，（不管该变化出现在开发早期还是后期
  以几周到几个月为周期，尽快，不断地交付可运行的软件供用户使用
 在项目的过程中，业务人员和开发人员最好能一起工作
 以积极向上的员工为中心建立项目组，给予他们所需要的环境和支持，对他们的工作予以充分的信任
 在项目组中，最有用，最有效的信息沟通手段是面对面的交流
 测量项目进展的首要依据是可运行的软件
 Aglile 过程高度重视可持续开发
 项目发起者，开发者，和用户能始终保持步调一致
 应时刻关注技术上的精益求精和设计的合理，这样能提高软件的快速应变力
 简单化(应尽可能减少不必要工作的艺术
 最好的框架结构，需求和设计产生于自组织的项目组
项目组要定期对其运作情况进行反思，提出改进意见，并进行相应的微调
  适合Agile 方法的情况
  需求不确定，易挥发（Volatile ，只今天的要求明天就不需要了)
 有责任感和积极向上的开发人员
 用户容易沟通并能参与
  Agile 与 CMM
 CMM视角
 CMM注重管理,(组织过程的有效性和过程的系统化改进),Agile 更注重效率和技术
 CMM提供了一个高度抽象的框架，有广泛的适用范围，Agile 适用于小组织和需求不定，有用户紧密的参与情况(在高可靠性要求和大型项目组，或虚拟项目中不宜采用)
   CMM 与Aglie  有一些共同特点，但Agile 部分满足CMM2~3 中 部分KPA(关键过程域的要求
   Agile 方法提出了某些周境(context)下非常有效的实践，与CMM方法有一定的互补性，CMM着重于应该"做什么，Agile 侧重于"何做"
 XP  视角
XP方法从某种意义上来说是 CMM2 到5级的一个垂直切片(满足了CMM2到5级的部分KPA目标要求)
 若将之应用于整个组织还需要更多的度量工作，但他同时指出，XP方法中更多的度量不是不可以做，而是根据投入回报分析决定是否有必要
 CMM注重质量,Agile 注重生产率
  CMM强调过程的可观测性,Aglie 强调可观测的结果(可运行的软件)
 CMM 注重管理和过程,Agile 注重技术和效率
 CMM注重组织,Agile 注重个人
 CMM无所不包,（Universal,) Agile 有明确的使用范围
 他们都包含了一些软件工程好的实践
什么是XP
 XP是勇气，交流和反馈和简单
 XP是软件开发过程中的纪律，他规定你，必须在编程前些测试，必须两个人一起编程,必须遵守编程规范
  XP 是把最好的实践经验提取出来，形成了一个崭新的开发方法
   简单为在管用能完成事情的前提下，做简单的事;交流及整个开发过程应该都需要即使交流，这里交流侧重口头交流和简单明了说明问题的文档交流,屏弃烦琐杂乱的文档和计划等，反馈几整个项目计划任何时候都需要客户和内部人员的反馈，一保证整个项目软件处于设计和编程与修复bug的状态,勇气即要求你必须是有足够信心对自己的代码和别人的代码进行重构
  十二条惯例和规则
On-Site Customer  (现场客户)   计划项目(Planning Game) 频繁小规模发布软件 small Release 简单设计 Simple Design 测试驱动开发(Test Driven Delelopment)
持续集成(continuous Integration) 集体拥有代码(Collective Code Owership 编程规范 (Coding Standards)  重构 (Refacytoring ) System Metaphor （系统隐预）
Pair programming 结对编程 平稳的工作效率(sustainable pace)
测试驱动开发(Test-Driven Develop ,TDD)
  先写功能测试->先写单元测试 ->编程-》运行单元测试->运行功能测试
     编程->重构->集成
 MSF 主旨和观点
 MSF 对环境，采用的技术，项目的大小有较大的适应性,这是MSF  的第一个主旨
 MSF对软件开发的独到见解
  用户的需求是变动的
 需求是未来的，而不是当前的
 资源永软是匮乏的
 风险普遍存在
 开发小组是平等协作的平等关系
 认识是渐进的，过程是迭代的
 技术模型也可以影响业务模型
 MSF 是一系列的指导方针
 目的在于更快的速度，更少的人力，更小的风险，更高的质量，成功交付信息技术解决方案
 小组模型
   MSF 提供了一个有机的建组模型
 由不同的业务职能人员形成开发组，人员以角色承担组内成员应负的责任
 角色之间是协商和合作关系，小组的扩大与缩减也都以角色承担工作量为准
 过程模型
 MSF 提供一个既分阶段又反复迭代的软件开发模型
 吸收了瀑布模型的经验和螺旋模型的优点
     管理准则:项目管理准则，风险管理和就绪管理
  项目管理
    不设项目经理
   项目管理活动尽量以当事人的意见为主
   强调项目管理与风险管理紧密结合
   MSF 项目管理非常重视实践
 基本原则 :
  职责明确，责任共享，在一个共享的远景下工作小组成员有责有权重点是交付业务价值，灵活敏捷，主动应变，促进坦率沟通，在质量上投资，在各种经验中学习
    g关键概念
 MSF 形成自己的模型和准则时，为了体现MSF 的基本原则形成一些关键的概念，及支持MSF 思想的理念
      MSF为每一种模型，每一种准则给出了关键概念
 小组模型关键概念:角色平等,以客户为中心,都要有产品理念，零缺陷意识，乐于学习，有激情的小组最有效
 `经实践检验正确的经验
 除了基本原则和关键概念之外,WSF 还为每种模型，每种准则提供了采用模型，实施管理时的实际经验，这些经验是经过实际验证切实可行的
 小组模型经验：组成多学科小组，同一地点办公，所有成员均参与设计
  CMM
 能力成熟度模型(Capability Maturity Model)
    用于软件开发组织内部软件过程改进
   CMM  (初始级，可重复级,以定义级，以管理级，优化级,
     PSP  个体软件过程PSP (Personal Software Process) 为基于个体和小型群组软件过程的优化提供了具体而有效的途径，
如何指定计划，如何控制质量，如何与其他人相互协作等等
 PSP 采用的方法
 PSP 保张软件产品质量的一个重要途径是提高设计质量
在软件设计阶段，PSP 的着眼点在于软件缺陷的预防
 其具体方法是强化设计结束准则，而不是设计方法的选择
 PSP 的效用
  绝大多数软件缺陷是由于对问题的错误理解或简单的失误所造成的，只有很少一部分是由于技术问题而产生的
如果在设计阶段注入一个差错，则这个差错在编码阶段所引发 3~5个新的缺陷，要修复这些缺陷所花费的费用要比修复这个设计缺陷所化的费用多10倍
 TSP  群组软件过程TSP （Team Soft Ware Process)
 指导项目组中的成员如何有效地规划和管理所面临的项目开发任务
 告诉管理人员如何指导软件开发队伍始终以最佳状态来完成工作
 TSP实施集体管理与自己管理自己相结合的原则，最终目的在于指导一切人员如何在最少的时间内，以预定的费用生产出高质量的软件产品
 TSP 采用的方法
  对群组的软件开发过程的定义，度量和改进
 实施TSP 的先决条件有3条
  需要有高层主管和各级经理的支持，以取得必要的资源
 项目组开发人员需要经过PSP 的培训并按TSP工作的愿望和热情
 整个软件企业在总体上处于CMM二级以上     
       TSP所采用的方法
 在实施TSP的过程中
 要有明确的目标
 开发人员在每一阶段开始，要做好工作计划
 如何发现未能按期按质完成计划，应分析原因，一判定问题是由于内容不合适或工作计划不实际所引起，还是由于资源不足或主观努力不够所引起
 TSP 所采用的方法
 在实施TSP的过程中
 开发小组应随时追踪项目进展状态并进行定期汇报
 开发小组应经常评审自己是否按照 PSP 的原理工作
 开发人员按自己管理自己的原则管理软件过程，如果发现过程不合适，应及时改进，以保证用高质量的过程来生产高质量的软件
 项目开发小组则按照集体管理的原则进行管理，全体成员都要参加和关心小组的规划，进展的追踪和决策的制定等项工作 。
经验借鉴
  软件工程管理方面的投资一般占软件开发费用的10%左右
 软件工程的重大修改必须由高层管理部门启动
 软件过程的改善还有待于全体人员的积极参与，否则不仅他本人将失去从软件过程改善中获得提高的机会
 ，甚至成为过程改善的阻力
 软件过程成熟度的升级本身就是一个过程，有一个生命周期，因此，过程改善工作需要循序渐进
 要将CMM/PSP /TSP 引入软件企业，最有效的途径是要对单位主管和主要开发人员进行系统的分配
 中小企业可以以CMM为框架,先从PSP 做起，然后在此基础上逐渐过滤到 TSP ，以保证CMM/PSP/TSP 在企业中根深缔固
软件架构风险管理与控制
 风险管理过程
 表识->分析和优先级化->计划和调度->跟踪和报告->控制->学习
风险标识
 1小组经验
 2项目相关的风险
   . 一般的                                     风险
  . 业务的         标识
  .技术的
  .环境的
 3组织风险政策和规程
  项目规格说明历史，状态或上下文
 4其他
 5风险知识库

 
目标：为小组创建一个他们面临的风险列表
输入：一般和项目风险相关的可用的知识，包括业务，技术和组织和环境域
风险标识活动
 MSF 风险管理准则强调风险标识在一个项目中要周期性实施
 风险标识可以是进度驱动的，可以里程碑驱动的，或事件驱动的
 结构化方法
 风险分类
 风险陈述
  人员:客户，最终用户 ，过程：使命和目标，决策，技术：保障性，开发与测试环境；环境的：法律，规章
   根源-风险陈述 《条件->结果》->全部损失或机会成本
 开发和测试角色在这个项目中已经被合并->交付时会有更多的缺陷
 输出:对小组面临的风险的明确的，无二义的，达成共识的陈述，用风险列表的方式记录
 MSF 风险管理建议小组必须创建表格记录的风险陈述记录
风险优先级化确保小组首先处理最重要的项目风险
 分析确定风险的优先级
目标：首要目标是确定风险列表中各项的优先级，确定那些是需要分配资源做计划的风险
 输入：切题的信息可来自组织风险政策和指南，行业风险数据库，模拟，分析模型，业务单位经理，领域专家等
 风险分析活动
 风险分析最易使用的一个方法是，使用两个被广泛接受的风险成分达成共识的估计，这两个量可以被相乘来计算一个简单度量,即风险爆发(risk exposure)
 风险概率
 概率的三种表示法 

  
概率的七值表示法
  
风险影响
金钱损失记分表
 
风险影响记分表
 
风险爆发=风险概率* 风险影响

量化方法补充
 风险有加权的优先级矩阵
 
输出
风险主列表
 附加的分析方法
 风险陈述表
 最高风险列表
 是风险无效
风险主列表
 
风险主列表条目
 
风险陈述表格中的内容
      
风险计划和调度
优先级的风险列表（最高风险)    更新的风险列表
项目的计划的进度表            风险计划和调度 风险行动表

风险的知识库计划信息                            更新的项目计划和进度表
风险计划和调度
 目标：
 为风险分析所表识的最高风险的控制开发详细的计划，并把他们集成到表准的项目管理过程中以确保他们完成
 输入：包括风险主列表，最高风险列表，来自风险管理知识库中的信息，以及项目计划和进度表
 计划活动
 研究，接受，避免，转移，缓解，应急计划
 调度活动
 小组应该认识到发风险控制活动是项目有机成分，而不是自愿实施的额外活动
 输出
 风险行动项，风险行动表，更新项目进度表和醒目计划
 风险跟踪报告
 项目计划（项目状态报告）   风险状态报告
  风险行动表格       风险追踪报告
 风险度量     触发事件通知
目标
 监视风险行动计划的状态
 监视与应急计划触发器相关的项目度量
 提示应急计划已经触发，启动应急计划
 输入：
 风险行动表
 相关项目的状态报告
 跟踪活动
 为每个风险创建特地功能风险状态报告
 风险状态报告
 运行在两个层次上，一个层次是小组本身，一个层次是向外部干系人报告
 输出：风险状态报告的目的是通告风险状态的变化，报告缓解计划的进展
风险控制
风险状态报告      项目状态报告

   风险控制   应急计划结果报告
触发事件通知               项目变更控制要求
风险控制
 目标：成功执行为最高风险开发的应急计划
 输入：风险行动表
 控制活动：风险控制活动应利用标准的项目管理过程使启动，监视和评估能沿着计划好的行动路线进展
 输出：是标准的项目状态报告，记录了应急计划逐步完成的进展情况
从风险中学习
 风险主列表      风险政策和指南变更的建议
风险行动表格
风险状态报告                      从风险中学习         新风险修改后的风险分类，应急计划缓解计划
项目计划和进度       风险知识库
小组经验
风险政策和指南
捕获风险学习  
 风险分类记录学习的两个关键方面：新风险；成功的缓解策略
 管理从风险中学习
 在特定的风险分类领域必须有专人负责
 风险分类应平衡两个方面的需求：风险覆盖的全面性和复杂性及可用性
 需要建立一个风险知识来维护风险分类，定义，诊断，平分系统，以及捕获使用他们的小组经验反馈
 需要很好的管理风险审核过程，确保捕获所有的学习经验，
上下文相关的风险分类
 对于特殊的，一再重复的项目上下文，要通过开发风险分类来求精风险标识
 风险知识库
 在管理风险知识中提高成熟度
 最低层，没有知识库，在实施风险管理时从零开始
 第二级，将采用非形式的知识库
 第一级为风险表识提供了一个更加结构化的方法
如何描述和评估软件架构质量
 软件的质量建模
 评估软件架构质量的价值
 怎样改变软件架构的质量
 如何评价软件的架构
 评估软件架构师的能力
 1软件的质量建模
 技术架构
 管理架构
 支撑架构
 业务架构
 软件架构质量模型隐喻 1
 软件架构的重要性是不然而喻的，但是当所有人都意识到他的重要性的时候，却很少有人能够清晰的描述出如何能够提高软件质量
 软件质量况架的目的就在于提出一个评价的原型，帮助我们分析一种方法和技术是否能够提高软件质量
 什么才是一个高质量的软件
 满足用户的需求。这是最重要的一点，一个软件如果不能够满足用户的需要，设计的在好，采用的技术在先进，也没有如何的意义，所以这点非常的朴实，但却是软件质量的第一个评判标准
 合理进度，成本，功能关系，软件开发中的所有的管理都是围绕着这几个要素在做文章的，如何在特定的时间内，以特定的成本，开发出特定功能 的软件，三者之间存在一种微妙的平衡，在Planning
 一个高质量的软件的开发过程中，项目成员一定能够客观的对待这三个因素，并通过有效的计划，管理，控制，使得三者之间达成一种平衡
 保证产出的最大化
 具备扩展性和灵活性，能够适应一定程度的需求变化，当今的社会已经变成一种变化速度极快的设计了。变化就会对软件产生冲击，所以一个质量优秀的软件，应该能够在一定程度上适应这种变化，并保持软件的稳定
 能够有效的处理例外的情况，写过软件的人都知道，实现主题功能的工作量其实不大，真正的工作量都在处理各种例外，所以，一个软件如果能够足够的建壮，足够的鲁棒，能够承受各种非法情况的冲击，这个软件就是高质量的
 保持成本和性能的平衡。性能往往来源于客户的非功能需求，是软件质量的一个重要评价因素，但是性能问题在任何地方都存在，所以需要客观的看待她，例如一段性能不错的代码可能可读性很差，这就需要进行平衡，如果这段代码的性能是整个软件的关键，那么取高性能而舍弃可读性，反之则取可读性而舍弃高性能，一个优秀的软件能够保持成本和性能之间的平衡
 能够可持续的发展，很少有软件组织只开发一个软件的，所以，一个优秀的软件在开发完成后，可以形成知识沉淀，为软件组织的长期发展贡献力量，这是一个优秀软件应该要能够作到的
 软件的质量框架的 组成
 第一部分是前提，说明了软件框架的适用范围，以及适合的环境，和方法学一样，没有泛之四海皆准的方法学，所以软件质量框架也需要一个上下文环境
 第二部分是价值观，价值观说明了软件质量框架中强调的价值，在软件的框架的结构和实践中，都将充分的表现出一开始我们定义的价值
 第三部分是结构，结构定义了软件质量框架的组成部分
 以及软件质量框架和开发过程的关系，第四部分是文章着墨最多的部分，及优秀实践
 优秀实践通过具体，实际的分析，举例，深入阐述了软件质量框架的价值观和结构
软件架构的前提
 平台前提：由于软件质量框架的实践将会涉及具体的技术和代码，所以我们首先为软件质量框架定义了平台，软件质量框架将会运行在 J2EE 平台上，使用对象分析技术
   组织前提：执行软件质量框架需要投入，需要付出，软件质量框架最难的地方不是学习，而是执行，在一个组织中，需要评估应用软件质量框架需要多少多少投入，对目前的开发过程有多大的助益，一般来说，组织的规模越大，其开发过程和产品越复杂，就越适合采用软件质量框架
方法学前提：在敏捷方法学中，对规则和秩序有两中不同的观点，一种是强调规则和秩序，以XP为代表，他对代码都有要求，另一种则不那么强调，以自适应的软件开发为代表，他不要求程序员的具体行为，软件质量框架采用第一种观点，要求组织中存在严谨的规则和秩序
 软件质量框架的价值观
 明确具体：对软件的管理必须是明确具体的，软件开发是工程，也是艺术，需要紧密的协作和沟通，任何一个含糊的指令都可能导致软件开发中出现错误，所以，在软件开发中，任何一个指令都应该是明确具体的，为什么说是相对呢？是和成本相对，指令越明确，成本就越高，例如，你可以把需求文档写的非常的具体，但是你需要付出制作和维护的代价，所以我们的明确性是一个考虑成本前提下的特性
 明确具体要从综合上考量，怎么理解呢？ 例如 XP中的用户故事是非常不精确的，按道理说它是不明确，也是不具体的，但是在整个开发周期中，将会有跌代，测试，现场用户等多种手段使用户故事明确具体起来，所以从整体上看，它并不违反我们的价值观，产品质量是一个系统工程，决不仅仅是在QA部门工作，这个道理适用于制造业，也适用于软件业
 容错：软件开发是人的工作，人是无法避免错误的，所以软件质量框架中容易犯错。因为不犯错误是天方夜潭，你就算做了这方面的强制规定也无法避免他的出现，反而会引发其他的问题，例如隐瞒错误，或为了隐瞒错误而导致的额外成本。所以正确的态度是允许发生错误，并建立一套监测，管理，反馈，修改错误的体制
 规范：在前提中，我们已经提到了，规范是软件质量框架的基本态度，所以，软件质量框架中强调规范，并使用规范来推动框架的运作
测试：软件的质量框架非常强调测试，测试是保证质量的必由之路，测试要尽可能快的反馈，这是软件质量框架对测试的基本态度，测试是综合的，软件开发过程中的所有工件，都需要伴随着相应的测试工件，这是基于一个简单的观念，如果你不能够成为你的工作制定一个完成的标准，你又该如何开展你的工作呢？
 软件质量框架的结构
 处于结构核心的是技术架构和管理架构，软件质量框架既不是方法学，也不是一个软件，更象两者的结合体，技术架构和管理架构的融合体现了这一特性，软件质量框架并不关心单个开发人员的效率，他关注的是开发团队整体的效率
 因此，管理架构在框架中的意义在于他定义了一套软件管理的方法，能够对开发人员极其他们的工作进行管理，从这一点来看，他的作用和软件工程方法学一样的，但是在现实中我们很难发现软件组织在迈向软件过程的涂中往往因为现实的困难而止步不前，其中一个主要的原因是在引入的方法学的过程中生产效率降低了，而引起组织成员对变革的怀疑和不满
 软件质量框架还提供了一个技术框架，其中的是目的明确的定义如何应用组织中涉及的软件技术，以及管理软件技术的方法，技术架构是具体的代码，相比起方法学来说，他更加的具体，更容易为开发人员是进行技术积累，另一方面也是为管理架构服务
 技术架构和管理架构的下一层是支撑框架支撑框架包括代码，组件，文档，目的是为技术架构和管理架构提供底层的支持
 处于结构最顶层的是业务架构，这个部分对于任何一个软件组织来说都是不同的因为不同的软件组织的业务不同。业务架构的目的是对业务进行建模和抽象，提取出可重用的部分，以提高软件组织的生产率
 软件架构的优秀实践
 一个开发团队要提高效率，就需要思考目前的管理活动中有那些要素是可以改进的；如何把一些事务性的操作变得自动化，从而节约人力，如何找到更好的方法，让开发过程更为合理，更注重软件的质量；如何在团队中传播优秀的思想，让团队成员不断的学习和进取，自发的改进过程，这些美好的愿望几乎是所有方法论和各种认证的共同心声，但是要完全做到可就太难了
 优秀的实践是来源与软件开发界的一些新思路和新理念论，他们能够为以上愿望的达成起到正面的作用。在组织中引入用这些实践决不是一个容易的过程，但他们确实非常的有效，不论是在成本控制上，还是在质量的改进上
   日创建：一个组织应当拥有一个有效的工作流程，这个工作流程能够指导软件开发的进行，这个流程应该是具体的，可操作的，随意的计划和从来不遵循的进度决不是一个有效的工作流程，日创建实践提出了一种对开发过程进行精细管理的方法，他是量化软件的基础，有了日创建，你会发现计划的制定和进度的监控是非常容易的一件事情
 测试驱动开发：软件质量的根源来源于测试，测试作好了，软件的质量就好，这是毫无疑问的，问题的关键在于怎么做测试，才能保证测试的投入能够带来软件质量的有效提升。测试驱动开发正是为了解决这个问题而出现的，他不是一个完整的方法论，可以和任何一种开发流程进行融合，测试驱动开发不但能够改善测试效果，还能够改进软件的设计
 建立核心框架：框架是一种具有高质量重用性的软件，这个特性决定了他非常适合成为软件组织积累知识的一种有效手段，传统的知识积累的方法是文档，但是文挡容易产生歧异，开发人员往往也不愿意去阅读和理解文挡，框架提供的是一种综合的手段，包括文挡，模型和代码，更容易理解，更重要的是，开发人员必须在日常的工作中使用框架，这使得他们对框架中的知识非常的熟悉，并根据工作的需要来改进框架
 面向组件编程：有效的组织再于有效的分工，体力活动容易进行分工，脑力劳动则比较难，而软件开发似乎更难了，所以，长久以来我们都习惯采用以功能块开发为单位的粗粒度划分方式，并以服务作为组件之间相互依赖的契约，不但定义了组件和组件之间的关系，也规定了组件开发者，组件使用者，组件测试者的权利和义务。从而能够进行软件开发工作的分配，管理， QA 等工作
 从软件结构的角度来看，日创建和测试驱动开发似乎偏向于管理架构，而建立核心框架和面向组件编程侧重于技术框架，事实上，他们既包含技术架构，也包含管理架构，彼此之间也有相关关联
例如，面向组件编程在合理划分组件之后，就需要一个有效的核心框架来集成组件，通过每个组件都需要采用测试驱动开发方法来保证质量，同时，日创建将会以组件为单位进行每日的创建，从而为进度估算提供有效数据
 未来的一种可能性是UML2.0和MDA技术的普及，以上的几个实践从以代码为核心转变为以设计为核心，而另一种可能性是随着以AspectJ为代表的AOP 技术的普及和J2se1.5 中引入了的元数据机制，面向组件编程把Aspect 作为组件的一种，而测试驱动开发也会加入测试 Aspect 的相关内容，在日创建中也会增加相应的处理AOP的步骤
软件架构评估
 高质量架构设计的障碍
 1对软件开发过程中架构设计的重要性没有认识
 2对软件架构师的角色缺乏理解
 3宽泛地认为设计是技术形式的活动，而不是技术活动
 4对设计的过程缺乏理解
 5在开发组织中缺乏设计经验
 缺少软件架构设计的方法学和相应工具
 不知道如何评估设计
 在“利益相关者”之间缺乏有效的沟通
 架构权衡分析评估方法
 1评估参与者
 1）评估组独立于项目组，3-5人，中立，每个人都有能力进行架构设计
 2项目决策者项目负责人，架构师，客户代表等构成
 3架构利益相关者相关者开发人员，测试人员，维护人员，用户等构成12~15人
 
Cost  Benefit  Analysis Method(CBAM)
1)消耗和效益的上下文

 Business Goals  ->Architechture Strategies->Persormance ,security,modiliablity ,Usablity  ->Benefit
    |
   ^ 
   Cost
步骤
 

评估软件架构师的能力
 角色和分工
 参与应用建模的人员主要分成两类角色，系统架构师和设计师
 系统架构师职责
 系统架构师负责领导和协调整个项目中的 技术活动
 在个人综合素养方面，系统架构师应该具有领导才能，能够在压力下作出关键性的决定性的决策并善始善终
 能够赢得项目经理，客户，用户群体以及管理团队的认同和尊敬，尤其要善于和项目经理紧密协作
 在各个方面都能展现出目标的实干作风，在专业技能方面，与其他角色相比，系统架构师通常具有全方位的技能，其见解重在广度，而不是深度
 系统架构师不仅要具备设计师的各项技能，而且应该具有问题领域和软件工程领域的实践经验，从而有能力在无法获得完整信息的情况下迅速领会问题并根据经验作出谨慎的判断
 如果项目较大，系统架构师将是一个团队，上述的关键素质要求可由团队成员来分担，但其中要有一名系统架构师具有足够的权威
设计师职责
 设计师的工作对象通常是系统的局部或者细节
 设计师应该掌握的技能包括
 理解以 Use Case  建模的技术捕获和描述的软件需求
 在系统架构师的统一协调下，应用 UML进行局部的面向对象的分析和设计
 了解主流的实施技术（程序设计语言和 开发环境）
设计模式与软件架构设计
 面向对象软件架构设计思想
 使用UML进行软件架构设计
 设计模式的本质论
 设计模式与架构模式
  面向对象的本质论-面向对象范式
 功能分解模式分析
 功能分解模式如何适应需求的变化
 面向对象范式
    功能分解：
 分析者将问题分成多个功能步骤，这些步骤组合起来就是可以解决实际的问题
 把问题分解成小块来解决，比以次处理整个问题要简单
 功能分解带来的问题
 他不能帮助我们为未来可能发生的变化作出准备
 他不能帮助我们的代码优雅的演变
 变化的发生还为错误和意外结果的发生创造了机会-许多错误都来自代码的变化
 模块化方式处理变化  
 模块化可以帮助你写出更容易理解的代码，更容易理解的代码也更容易维护；
 模块话并不能帮助你写出能应付所有可能出现的变化代码
 内聚和耦合
 内聚度：是指程序中的操作之间联系紧密的程度，描述了一个子程序的内部成分之间相互联系的强度
 耦合度：是指两个只程序之间联系强度，描述了一个子程序与其他子程序之间的联系强度
 耦合度与内聚度成反比
 目标：将建具有内部完整性（强内聚）的子程序，以及小的，直接的，，可见的，灵活的与其他子程序之间的联系（松耦合）
 责任迁移模式处理需求变化
           软件开发过程的视角
 概念（conceptual)
 展示了问题领域中的概念
 一个概念模型可以在对实现软件有很少或毫无注意的情况下勾勒出来
 规格 （Specification )
  我们只看软件的接口，而不看软件的实现
  实现 （Implementtation)
   置身于代码当中，使常规视角
 目标：
 一个层次（概念层次）上通信而在另一个层次（实现层次）上执行，
请求者不知道发生了什么，只知道概念上发生了什么

 面向对象范式
 面向对象范的核心是“对象”的概念
 所有的东西都聚焦于对象
 围绕对象-而非函数-组织代码
 对象从不同视角观察
 概念层
 一个对象是一系列责任
 规格层：一个对象是一系列可以被其他对象或该对象自己调用的方法
 实现层：一个对象是一些代码和数据
 面向对象本质论-设计原则
 面向对象的设计目标
 可维护性，可复用性
 可维护性：
 现在存在的问题：
   过于僵硬，过于脆弱，复用率低，粘度过高
 可维护性
 设计的目标
 可扩展性（Extensionlity)
     新的功能可以很容易假如到系统中
 灵活性（Flexiblity)
 允许代码修改平稳的发生，而不会涉及到许多其他的模块
 可插入性
 可以很容易地将一个类抽出去，同时将一个可以很容易地将一个类抽出去，同时将一个同样的接口的类加入进来
 可复用性
 重要性
  较高的生产效率
  较高的软件质量
  恰当使用复用可以改善系统的可维护性
 传统的复用
  代码的剪贴使用
  算法的复用
  数据结构的复用
 设计原则
  “开闭”原则（OCP)
   Open-Closed Principle
  定义Software entities should be open for extension but closed for modifycation
  一个软件实体对扩展开放，对修改关闭
  ”抽象化“是OCP的关键
  对可变性的封装原则　
   Priciple of Encapsulation of Variation (EVP)
   找一个可变的因素把他封装起来
   一种可变性不应当散落到代码的很多角落里，而应当被封装到一个对象里
   一种可变性不应当与另一种可变性混合在一起
  里氏代换原则（LSP)
   Liskov  Substitution Principle
   如果对某一对象类型T1的对象O1,都有类型为T2的对象o2,使得以T1定义的所有程序P在所有的对象O1 都代换成o2时，程序P的行为没有变化，那么类型T2是类型T1的子类型
  依赖倒转原则(DIP)
   Dependency Inversion Principle(DIP)
   要依赖于抽象，不要依赖于具体
   抽象层次包含的是应用系统的商务逻辑和宏观的，对整个系统来说重要的战略性的决定，是必然性的体现
   具体层次则含有一些次要的，与实现相关的算法和逻辑以及战术性的体现，带有相当的偶然性
  表述　　
   Abstractions  should not  depend upon details,details should  depend upon  abstractions ,(抽象不应当依赖细节，细节应当依赖抽象）
  Program to  an interface ,not a implementation (要针对接口编程，而不要针对实现编程
  接口隔离原则(ISP)
  Interface  Segregation Principle (ISP)
  从一个客户角度来将，一个类对另一个类的以来性应当建立在最小的接口上
  原则，角色分割
   定制服务
   
  组合／聚合复用原则（CARP)
   Compsition/Aggregation Reuse Principle (CARP)
   定义 
    在一个新的对象里面使用一些已有的对象，使之成为新对象的一部分，新的对象通过向这些对象的委派达到复用已有功能的目的
    尽量使用合成/聚合,而不是继承
　　　　　　　　　　　　　　　　类图中的关系
   一般化的关系(Ceneralization )
   表示类与类之间的继承关系，接口与接口之间的继承关系
   类对接口的实现关系
   关联关系（Association)
    表示类与类之间的联接，他是一个类知道另一个类的属性和方法
    关联可以是单向的，也可以是双向的
   聚合(Aggregation)关系
    是关联的一种，是强的关联关系，是整体与个体的关系
    合成关系
    是关联关系的一种，是比聚合关系强的关联，他要求普通的聚合关系中代表整体的对象负责代表个体的对象的生命周期，合成关系不能共享
   依赖关系(Dependency)
    是类与类之间的连接，依赖总是单向的，依赖表示一个类依赖于另一个类的定义
   通常被依赖的对象以方法的参数或返回表示
  
  迪米特法则(LoD)
 　　　　　　　　Law of Demeter(LoD)又称最少知识原则
   Least Knowledge Principle (LKP)
   表述
    only talk to your immediate friends "只与你的直接朋友通信"
    Don't talk to strangers "不要与陌生人讲话"
    每个软件单位对其他的单位都只有最少的知识，而且局限于那些与本单位密切相关的软件单位
     狭义的迪米特法则
     如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用，如果其中一个类需要调用另一个类的某一方法的话，可以通过第三方转发这个调用
  朋友的确定
   当前对象本身（this)
   以参量形式传入到当前对象方法的中的对象
   当前对象的实例变量直接引用的对象，
   当前对象的实例变量如果是一个聚集，那么聚集中的元素都是“朋友”
   当前对象所创建的对象
   与依赖倒转原则的互补原则
  广义的迪米特法则
   封装（信息隐藏）
   模块将它所有的实现细节隐藏起来，彻底地将提供给外界的API 和自己的实现分割开来
   模块与模块间仅通过彼此的API 相互通信，而不会理会模块内部的工件细节
   控制信息过载
   在类的划分上，应当创建弱耦合的类，类之间的偶合越弱，就越利于复用
  在类的结构设计上，每一个类都应当尽量降低成员的访问权限(Accessibility)
  在类的设计上，只要有可能，一个类应当设计成不变类
 在对其他类的引用上，一个对象对其实例的引用应当降到最低
  ICONIX 流程　
  　最小建立模型技术
 对于大多数问题而言，只需要使用20%  的UML ,可以完成８０％  的建立模型的工作
 　实际中，好象总是没有足够的时间来完成建立模型分析设计工作，总是过早进入到编码阶段
 足以很好地完成软件项目工作所需要的，最小的UML和建立模型的技术子集
 如何从用例到代码
  工作起点：
   假设：
    一些原型化的工作已经完成
    确定了用户界面 
    已经开始确定系统的一些场景和用例
   面向对象的系统中
   代码的结构好似由类来定义的
   编写代码前，必须知道所需的软件类是什么样的
   类图规定了代码的结构
   获得一组非常详细的，设计级别的（Design-level)类图
   设计级是一种详细程度，这种级别的类图可以用做系统实际代码的模版，准确地指出如何组织代码
   面向对象的软件开发中，最困难的工作之一分配行为，这需要就每个要建立的软件函数作出决策
   对于每个函数必须决定将其放在那个类中
  时序图将操作分配给类
   时序图帮助你作出行为分配决策的理想工具
   需要根据用例获得的时序图
 如何跨越模糊用例与详细程度类似代码的时序图之间的鸿沟
  使用健壮图他填补模糊，朦胧的用例与非常详细，精确的时序图之间的鸿沟
  时序图的最上面是，特定场景涉及的一组对象　
 设计模式的本质论
  模式是从解决具体问题抽象出俩的，这种具体问题在特定的上下文中重复出现，也就是说，每个具体形式都对一种重复的问题采用重复的解决方案
  然而，模式不仅仅是解决方案，正式因为很多人认为设计模式仅仅是解决方案，所以导致设计模式的滥用和设计过度
  模式不是解决方案　
  模式是在某种语镜中权衡各方面利弊的一种方案的选择，这种选择是这些利弊平衡的结果，获得好处的同时需要付出代价，并且结果中有利的方面，也有不利的一面
 　　在语境中，问题出现在一种特定的上下文中，并且包含各种相互竞争的关切（Forces),目标解决方案包括对这些关切的平衡，这种关切在模式中称为作用力，这些作用力相互牵制，因此，模式不能简单看作是“特定场景的解决方案",下面的定义更符合模式的内在含义
  模式是被命名的有组织的信息，他捕获了在一定语境（场景）中包含相关作用力的问题的解决方案的本质结构和内在含义，这种解决方案被证明是成功的
  模式包含3个部分：相关的上下文，与上下文相关的作用系统和解决问题的方案　　　
 理解设计模式的结果而后代价
  在GOf 的设计模式中充分讨论了模式的使用结果，既有好的一面，又有不好的一面，即使用模式是有代价的　
  １对象过多
   设计模式的精髓之一是将可变的部分封装为对象，带来的饿好处是系统更加灵活，容易维护，但也增加了大量的对象，如果不恰当的使用设计模式，会使系统难于调试，下面模式比较有代表性
 命令模式：将行为封装成对象，这样原来一个对象中的若干方法变成了若干命令对象，原来由一个对象完成的工作现在可能由十几个对象完成
 状态模式将不同的状态封装成对象，原来可能是通过判断语句完成的工作分散到各个对象中完成，由于状态是动态决定的，因此设计测试用例时有难度
 　更复杂的装配关系
  很多设计模式依赖对象之间的关系，因此在初始化需要执行相应的装配工作，需要装配对象的模式
   生成器的模式"需要装配生成器和导航器
   桥结模式：需要将代表逻辑的对象和代表实现的对象进行装配
   观察者模式：需要将不同的观察者对象关联在一起
   职责链模式：需要组装整条职责链
 测试难度加大
  这是由前面两个结果导致的饿，由于对象的增多和对象间关系的复杂，因此测试用例的设计难度加大，特别是很多逻辑上的错误可能由装配关系不当造成，并且在编译时很难发现
 解决测试难度大的方法是将测试用例文挡化，即绘制测试用例的对象图，这个话题可参考相关的书籍
 程序结构复杂
  设计模式关注的是如何是软件更具有可维护性，因此从结构上已经与原始的需求完全不同，加上很多功能是通过对象动态组合实现的，程序的动态结构变得与静态结构同样重要
 从单纯　的静态结构已经很难理解实现的方式和最终的意图了，着也是经常是使用设计模式的代价致意　
  设计模式不能做什么
  设计模式不是法则
  不能提高开发速度或者形象开发速度
  不是万能的
  设计模式不是法则
  模式理论的精髓之一就是模式的使用一有前提和代价的模式是在某种前提下，综合各方面因素后考虑得出的结果，即在使用模式时总要是付出代价的，当然这种代价必须是可接受的，如果某个模式在所有场合中的使用都是必然的，那么他就不能叫做模式了，而是一种必须遵守的法则，例如”面向接口，而非实现编程",是法则而非模式。
  不能提高开发速度或者形象开发速度
  如果以一个开发周期作为考核标准，恐怕没有人会使用设计模式，设计模式并不能提高目前的开发速度，至少其关注的目标并不是开发速度，很多情况下甚至会降低开发速度，即使是正确选择了设计模式
  这是因为设计模式可能回引入更多的对象和更复杂的对象装配关系，从而似的程序更多的动态状态，从局部看来边的结构复杂，难以理解并且测试困难，如果仅仅关注形象速度，或则能够百分之百地确定需求没有变化，那么设计模式并不是很好的选择
  不是万能的
 设计模式的使用是自然而燃的事，很多情况下不使用设计模式是因为不需要，问题很没有复杂到非用不可的程度，我们是为了设计而使用设计模式，而不是为了使用设计模式而设计
 当你的项目发现有如下的问题之一时，就需要考虑重构代码，可能会有某种模式适合
 代码无法进行单元测试
 需求的变动总是导致代码的变动
 有重复代码存在
 继承层次太多了
 隐藏的依赖过多
  设计模式与架构模式
  软件顶层架构的设计
  方法
  结合实际需求，选取架构模式，在进行局部调整
  主要架构模式：
   流程处理模式
   客户／服务器模式
   模型－视图－控制器的模式
   分层模式
  流程处理模式
   流程处理系统以算法和数据结构为中心，其系统功能由一系列的处理步骤构成，相临的处理步骤用　数据流管道连接
   流程处理模式适用于批处理方式的软件系统，不适合交互是交互式系统
 流程处理模式
流程处理模式有三个处理步骤
 步骤都使用公共的系统服务，（例如数据库访问服务，命令处理和　命令处理的进度，结果都通过用户界面
                           界面
  前处理器　问题求解器　　后处理器
    系统服务

客户／服务器模式
客户端负责用户输入和处理结果的呈现，服务端负责后台业务处理
　　　　　　　　　　客户端　　　　　　　客户端
 　　　　　　　　　　服务器　
　　模型-视图－控制器（MVC)  模式
    模型-视图－控制器模式
 软件系统由模型，视图，控制器三部分组成
 模型负责维护并保存具有持久性的业务数据，实现业务处理功能，并将业务数据的变化情况及时通知视图
 视图负责呈现模型包含的业务数据，响应模型变化通知，更新呈现形式，向控制器传递用户的界面动作
 控制器负责用户的界面动作影射为模型中的业务处理功能并实际调用之，然后根据模型返回的业务处理结果选择新的视图
分层模式
 将整个软件系统分为若干层次，最顶层直接面向用户提供软件系统的操作界面，其余各层为紧邻其上的层次提供服务
 分层模式可以有效降低软件系统的耦合度，应用普遍
 　　层次划分原则
 　　易变化的部分，如用户界面，与业务逻辑紧密相连的部件，放到高层
 稳定的部分，如公共的技术服务，放到低层
 每层都尽量访问紧邻的下层，避免越级访问，尤其要避免逆向访问，上层模块为下层模块提供服务
 将目标软件系统的外部接口放到较低层次，系统其余部分对外部系统的访问或操作通过这些外部接口提供服务来完成
 软件架构
 在全面了解软件架构的前提下，对于具体的应用需求而言，影响顶层架构选取的主要因素在于分析人员的经验以及他们对每种架构样式与软件项目之间匹配程度的判断
 大型软件系统的顶层架构往往需要使用多种架构样式，如，整个目标软件系统　采用分层结构，在系统的不同层次内在分别使用适宜的其他类型的架构模式
 确立软件架构考虑的因素
 架构中包的数量
 包中软件元素过多，应对包进一步细分；如果过少，则说明架构过早陷入细节
 架构中包的耦合度
  包的依赖关系，连接关系应尽量简单，松散简单，，如分层结构中，通常要求某一层的软件元素只与同层次及下一层的元素存在依赖关系
 软件元素的稳定性
 抽取不稳定的元素的相对稳定部分，将不稳定的软件元素聚集在少数几个包中，以提高软件系统的可维护性
确立软件架构
 软件元素的分类
  将软件的可选功能和必须实现功能的软件元素分别放到不同包或子包中
 作为软件系统运行环境的物理网络拓扑
 根据软件元素在分布环境中的布局，划分顶层架构的包，是包的消息传递与物理节点的通信相协调，顶层架构定义的通信关系支持后续的分析和设计活动
 确定软件架构
 软件元素的安全，保密级别
 根据安全访问的权限划分顶层架构中的包或者子包
 开发团队的技术专长
 　根据开发人员在问题和技术领域的专长划分顶层架构，使得每个包的开发都能充分发挥开发和团队的技术专长
 调整软件架构，支持并行开发　
 AOP 开发实践
  AOP 概述
  使用AOP实现松散耦合
  使用AOP 组合两个业务逻辑
  对象代理和过滤器
  结论
 什么是AOP
 AOP 是Aspect Oriented  Programming 的缩写
 中文翻译为面向方面的编程，其核心内容就是所谓的“横切关注点"
  OO都是纵向的结构
  使用面向对象方法构建软件系统，我们可以利用 OO的特性，很好的解决纵向的问题，因为OO的核心概念，如继承等，都是纵向结构的
 AOP目标
 但是在软件系统中，往往有很多模块，或者很多类共享某个行为，或者说，某个行为存在于软件的各个部分中，这个行为可以看作是”横向“存在软件之中，他所关注的是软件的各个部分的一些共有的行为，而且，在很多情况下，这种行为不属于业务处理逻辑的一部分
 例如，操作日志的记录，这种操作并不是业务逻辑调用的必须部分，但是，我们却往往不得在代码中显示调用，并承担由此带来的后果，（例如，当日志记录的接口发生变化时，不得不对调用代码进行修改
 这种问题使用传统的OO方法是很难解决的，AOP的目标，便是要将这些”横切关注点 “与业务逻辑代码相分离，从而得到更好的软件结构以及性能，稳定性等方面的好处
   关注点切割图
      纵向关注点
  软件模块  软件模块 软件模块 软件模块
    操作日志
                 安全检测    横切关注点
   业
   务
   数
   据
     事务处理
AOP 的自动耦合
 AOP  给我们的软件设计带来了一个新的视角和架构方法，使用 AOP ,我们可以专注于业务逻辑代码的编写，而将诸如日志记录，安全检测等系统功能交由AOP 框架
 在运行时刻自动耦合进来
   使用AOP 技术的情景
   Authentication   权限
  Caching          缓存
  Context  passing 内容传递
  Error Handling  错误处理
  Lazy  loading  ；懒加载
   Debugging  调试
  Logging ,tracing ,profing and monitoring (记录追踪，优化，较准）
  Performance optimization  性能优化
  Persistence 持久化
  Resource pooling  资源池
  Synchronization  同步
  Transactions 事务
 AOP 概述
  使用AOP 实现松散耦合
 使用AOP  组合两个业务逻辑
 对象代理和过滤器
 结论
  Websharp Aspect
  我们选用这个开放源代码的Web Sharp Aspect 框架。这个框架是基于Microsoft .net 平台的，并且是使用C#语言开发的，所以，下面的示例代码使用了C#相关的语法
 关于这个框架的说明以及源代码，可以从以下地址下载www.websharp.org
 对于应用软件来说，权限控制是一个常见的例子，为了得到好的程序结构，通常使用OO的方法，将权限校验过程封装在一个类中，这个类包含了一个校验权限的代码
 
  Public class  Security
  {
  public bool CheckRight(User CurrentUser,Model  accesModel, OperationType  operation)
  {
  ...//校验权限
  }
  }
 然后，在业务逻辑过程中进行如下调用
  public  class BusinessClass
  {
   public  void BusinessMethod()
   {
   Security s =new Security();
   if (! s.CheckRight(......))
   {
    return;
   }
   ...//执行业务处理逻辑
   }
  }

OO设计的问题
 这种方法在OO 设计中，是常见的做法，但是这种做法会带来以下问题
 不清晰的业务处理逻辑，在某种意义上来说，权限校验过程并不是业务逻辑执行的一部分，这个工作是属于系统的，但是，在这种情况下，我们不得不把系统的权限校验过程和业务逻辑执行过程搀杂在一起，造成代码的混乱
  代码浪费，使用这种方法，我们必须所有的业务逻辑代码中用Security 类，似的同样校验的代码充斥整个软件中，显然不是很好的现象
 紧耦合：使用这种方法，我们必须在业务逻辑只能显示引用Security 类，这就造成了业务逻辑代码同Security 类的紧密偶合，这意味着，当Security  发生变化时，例如 ，当系统进化时，需要对CheckRight 的方法进行改动，可能回影响到所有引用的嗲吗，下面的所有问题都是由此而来
 不易扩展：在这里，我们只是在业务逻辑填加了权限校验，那一天，当我们需要填加额外的功能，例如日志记录功能的时候，我们不得不把同样在所有的业务逻辑代码中填加这个功能
 不灵活，有的时候，由于某些特定的需要，我们需要暂时禁止，或者填加某项功能，采用传统的如上述的做法，我们不得不采用修改代码的方式来实现
 为了解决这些问题，我们通常会采用诸如设计模式等方式，对上面的方案进行改进，这往往需要很好的技巧
 利用AOP,我们可以很方便的解决上述问题
 我们以Websharp Aspect 为例，看看如何来对上面的代码进行改动，以获得一个更好的系统结构
 首先，Security 并不需要做任何修改
 然后，我们对BusinessClass做一个小小的改动
 为BusinessClass添加一个名为AspectManaged的属性，并使得BusinessClass继承AspectObject ,然后，删除代码中对Security  的调用，这样，我们的代码就变成了如下的样子
  [AspectManaged(true)]
 public  class  BusinessClass:AspectObject
 {
   public void  BusinessMethod()
  {
   ......//执行业务逻辑
   }
 }
然后，我们为系统增加一个SecurityAspect
 public  class  SecurityAspect:IAspect
 {
 public void  Execute (object[] paramList)
 {
 if (!Security.CheckRight(.......))
 {
 throw  new  SecurityException("你没有权限!");
 }
 }
最后，我们在系统配置文件中添加必要的信息
  <Websharp.Aspects>
   <Aspect type="MyAPP.SecurityAspect,MyAPP="deploy-model="signleton"
   pointcut-type="Method" action-position="before" match="*,"/>
  </Websharp.Aspects>
 我们完成了代码重构，当BusinessClass被调用的时候
 AOP框架会自动BusinessClass的BusinessMethod 方法，并调用相应的权限校验方式
 采用这种方式，我们在 BusinessClass 中没有显示引用Security类及其方法，并且，在所有业务逻辑代码中，都没有必要引用Security 类
 这样，借助AOP 机制，我们就实现了BusinessClass和Security 类的松散耦合，上面列出的所有问题都应刃而解，同时，这也是一种易于扩展的机制，例如，当我们需要添加相应的Aspect 类，然后在配置文件中进行配置即可，而无须对业务逻辑代码进行任何改动
 
     使用AOP 组合两个业务逻辑
 使用AOP  我们不仅可以用来分离系统功能和业务逻辑就向上面我们做的那样，也可以用来耦合不同的业务逻辑，得到更加灵活的软件结构，下面，我们通过一个具体的方案，来看看怎么通过AOP,组合两个业务逻辑过程
 我们假设有如下一个场景
 我们设计了一个ERP系统，其中，库存管理系统需要同财务系统相交互，例如，当某个库存商品报废的时候需要有相应的财务处理过程，因此，我们通常需要在库存商报废的业务逻辑中引用相关的财务处理逻辑，着必然会造成两个部分的耦合，当然，为了使两个部分尽量耦合程度降低，我们通常会使用Facade 等设计模式来进行解耦
 由于某些原因，我们需要将库存管理系统单独出售，这就需要我们从库存商品报废的业务逻辑中将引用的相关财务处理逻辑去除，这意味着我们需要修改原有的代码
为了解决这个问题，即可以随时将财务处理逻辑添加或者从库存商品报废的业务逻辑中删除，我们可以采用一些方法，例如，设置一些开关参数，在库存商品报废的业务逻辑中，根据这些开关参数的值，来判断是否需要执行财务处理逻辑
 问题是，着仍旧不是一个理想的解决方案，采用这种方式，你必须事先知道所有需要设置的开关参数，并且，在业务逻辑代码中添加相应的判断
 当为系统增加一个类似的需要灵活处理的部分时，开发人员不得不添加相关的参数，并且修改相应的代码（添加相应的判断代码）
 修改代码总是不好的事情，因为按照软件工程的要求，当有新的需求是，尽量不要修改原来的饿代码，而是增加相应的代码，但是，在这种情况下，你做不到
 使用 AOP我们可以通过一种更加自然的方式来实现这个目标，基本方法是
 首先，编写相关的库存商品报销业务逻辑，不需要添加任何其他的内容，并且，把这个逻辑的代码设置为可AOP的
 其次，编写财务处理逻辑
 添加一个把库存商品报废业务逻辑和财务处理逻辑组合起来的Aspect 这个Aspect 可以拦截库存商品报废业务逻辑的执行，动态的加入财务处理逻辑的过程，并且，在配置文件进行配置。
这样，我们通过一个Aspect 组合了着两个业务逻辑，并且我们随时可以通过修改配置文件的方式把财务处理从库存商品报废业务逻辑中去除，而不用修改任何代码
 采用AOP的好处是，我们可以独立的编写各个业务逻辑，似的系统各个部分之间的耦合度降到最低，然后，可以在系统中根据需要随时组合两个逻辑，而不用修改原来的代码
 对象代理和过滤器
 应该认识到，完全AOP实现的,需要开发语言的支持，因为对于AOP 的研究，还正在进行之中，目前的开发语言，都还没有完全支持AOP 的，但是我们可以利用现有的一些语言功能，来实现AOP的部分功能
 上面所举的例子，在实现上，是利用了对象代理(Proxy)机制，所谓Proxy,就是”为其他对象提供一种代理以控制对这个对象的访问"
   在WebsharpAspect 中当，一个对象被标记为Aspectmanaged后，这个类的实例的创建过程，以及方法的 调用会被WebSharpAspect 控制，因此，当你调用如下语句，
  BusinessClass  bc=new BusinessClass();
 你得到的实际不是BusinessClass类的实例，而是他的一个代理，
 因此当调用这个实例的方法的时候，所有的调用都会被代理所捕获，代理会在实际的方法调用之前，透明的执行一些预定义的操作，然后在执行实际的方法，最后，在实际的方法调用之后，在执行一些预定义的操作，这样，就实现了AOP功能
  注意，AOP并不仅仅等同于方法拦截，当然，着也是最常用和非常有效的AOP功能
   在某些开发中，我们可能使用过滤器来完成某些AOP功能，例如，当用户访问某些资源时，我们可以对访问信息进行一些过滤处理。一个常见的场景是，在JSP的开发中，为了实现对中文的正确处理，以获得正确的文字编码，在每个Request 中进行手工进行转码肯定不是一个好的解决方案
 一个比较好的例子是，是为应用程序编写一个Filter,自动进行转码处理，例如，我们可以为TOMCAT写如下一个过滤器来实现转码
 public class  SetCharacterEncodingFilter implements Filter
{

 public void doFilter(ServletRequest request,ServletResponse  response,FilterChain chain)
 {
  request.setCharacterEncoding("gb2312");
  chain.doFilter(request,response);
 }
}
  这样我们就不必在具体业务处理中进行手工的转码
 ，实现业务逻辑同转码这样的系统功能的分离
 目前，常见的 Web服务器都提供类似的机制，例如，在IIS中，也可以使用过滤器功能，传统的开发方式是根据使用VC 开发一个ISAPI Filter ,在.net 发布后，可以使用HttpHandler和HttpModule 实现相同的功能，但是，开发难度要低得多
 使用过滤器的另外的一个场景，例如，在客户请求某个Web 方面的时候，可以使用过滤器拦截这个请求，然后，判断这个用户是否具备对请求资源的访问权限 ，如果是那么，过滤器可以把这个请求放过去，什么都不做，否则，过滤器可以重定向到某个页面，告诉用户不能访问的原因，或者，直接抛出异常，又由前面的处理者处理，通过这种方式，我们可以同样的分离诸如身份验证这样的系统功能和业务逻辑，实现更好的系统结构
 通过象Web服务器这样的应用程序环境提供的功能，我们还可以实现起他一些AOP的功能，构建更好的系统况架
 结论
   AOP给了我们一个新的视角来看待软件的架构，有的时候，即使不使用AOP技术, 只使用AOP 的某些观念和现有的技术来搭建系统架构，对我们也是非常有益的
}