<一>面向对象分析之面向对象和面向过程

面向对象
        ---->注重的是拆分，组装。
        ---->封装，继承，多态，复用（只是现象）
        ---->面向对象变成的目标从来就不是复用。相反，对我来说，对象提供了一种处理复杂性问题的方式。这个问题可以追溯到亚里士多德，你把这个世界视为过程还是对象？在面向对象兴起运动之前。编程以过程为中心。例如结构化的设计方法。然而系统已经到达了超越其处理能力的复杂极点。有了对象。我们能够通过提升抽象级别来构建更大的，更复杂的系统。我们认为，这才是面向对象编程运动真正的目的。
        ----->面向对象。是将大行为拆分成很多独立的小对象。小对象具有只关注自己的小行为。然后对象进行组合，完成整个大行为。
        ---->从宏观角度上讲，对象是“短视”的。它不知道它身处的整个世界是怎么回事。也不知道它的行为如何贡献给这个世界。它只知道与它有着联系的身边的一群小伙伴（这称之为依赖）。并与小伙伴保留着信息交流的关系（这称之为耦合）
        ---->高内聚，低耦合。是现实深度封装，减少依赖。
      
面向过程
        ---->注重的是因果关系。
        ---->面向过程是将行为看成一个紧密联系的整体。对于复杂多变的行为，是个短板。

面向过程和面向对象的区别
        --->面向过程：调研需求时，最先弄清楚有多少个业务流程，先画出业务流程图，然后顺藤摸瓜，找出业务流程中每一步骤参与的部门或岗位。弄清楚这一步参与者所作的事情和填写表单的结果。并关心用户是如何把表单送到下一环节中的。那很不幸，你还在做面向过程的事情。
        --->面向对象：如果你习惯在调研需求时，最先弄清楚有多少个部门，多少个岗位。然后找到每个岗位的业务代表。问他们类似的问题：你平时都做什么？这事是谁交代办的？做完后你要通知或传递给谁吗？做这些事情你需要填写些什么表格？那么恭喜你，你已经面向对象了。

面向对象分析问题的三大步骤
一：从现实世界到业务模型：
                --->建立模型，就是一种抽象的过程。站在很高的抽象层次。以高度归纳的视角看这个世界运作，就会发现现实世界无论多复杂，无论那个行业，无论什么业务，其本质无非是由人，事，物和规则组成的。人是一切的中心。人要做事，做事就会使用一些物并产生另一种物，同时做事需要遵循一定的规则。
                --->人驱动系统，事体现过程，物记录结果，规则是控制。
                --->建立模型的关键是弄明白有什么人，什么人做什么事情，什么事情产生什么物，中间有什么规则，再把人，事，物之间的关系定义出来。一个模型也就基本成型了。

UML提供了什么元素来为现实世界建立模型呢。
        【1】参与者：（1）UML利用参与者（actor）的元模型作为信息来源的提供者。可代表现实世界的“人”。参与者是模型信息来源的提供者，也是第一驱动者。(2)建立模型的意义完全被参与者定义。所以建立的模型也是为参与者服务的。参与者是整个建
立模型过程中的中心。
        【2】用例：（1）UML采用用例（use case）的一种元模型表示驱动者的业务目标。也就是参与者想要做什么并获得什么。这个业务目标是现实世界中的“事”。（2）这个事情怎么做，依据什么规则，则通过被叫做“业务场景（business scenario）”和“用例场景（use case scenario）”的UML视图来描绘。这些场景则是现实世界中的“规则”

二：从业务模型到概念模型
        ---->分析模型：虽然上一阶段，用业务模型将现实世界映射并记录下来，但这只是原始需求信息，距离可执行的代码还很遥远，必须把这种模型换成一种可知道开发的表达式。UML称之为概念化的过程来建立适合计算机理解和实现的模型。这个模型被称之为：分析模型。
        ---->分析模型介于原始需求和计算机实现之间，是一种过度模型。分析模型，向上映射了原始需求，计算机的可执行代码可以通过分析模型追溯到原始需求。同时，分析模型向下为计算机实现规定了一种高层次的抽象。这种抽象是一种知道，也是一种约束。计算机实现过程中，非常容易遵循这种指导和约束来完成可执行代码的设计工作。
        ---->事实上分析模型在整个设计过程中承担很大的指责，起到非常重要的作用，绘制分析模型的最主要的元模型有：
        【1】边界类（boundary）
                        -->边界是面向对象分析的一个非常重要的观点。狭义上说，边界就是大家熟悉的页面。从广义上说，任何一件事物都分为里面和外面。外面的事物与里面的事物之间的任何交互都需要有一个边界。比如参与者与系统交互，系统与系统交互。模块与模块之间的交互。只要是两个不同职责的簇之间的交互都需要有一个边界。
                        -->换句话说，边界决定了外面能对里面做什么“事”
        【2】实体类（entity）
                        -->参与者完成业务目标时都要涉及事物。UML采用实体类来重新表达业务实体。
                        -->实体类可以采用计算机观点在不丢失业务实体信息的条件下重新归纳和组织信息。
        【3】控制类（control）
                        -->边界和实体都是静态的。本身并不会动作。UML采用控制类来表达原始需求中的动态信息。就是业务或用例场景中的步骤和活动。
                        -->控制类代表规则，业务流程。

三：从概念模型到设计模型。
                --->设计模型：上一节中建立的概念模型距离可执行代码已经非常接近了。概念模型使我们获得了软件的蓝图。获得了建设软件所需要的所有组成内容以及建设软件所需要的所有必要细节。这类似于我们已经在图纸上绘制出了一辆汽车所有的零部件，并绘制出如何组装这些零部件的步骤，接下来的工作就是建造或购买所需的零部件。并索道生产线上生产汽车。
                --->在设计模型中。概念模型的边界类可以被转化为操作界面或者系统接口。控制类可转化为计算机程序或控制程序，例如工作流，算法体等。实体类可以转化为数据库表，XML文档或者带有其他持久化特征的类。

面向对象分析的完整过程图