只供参考，喜欢请支持正版图书
1.1 面向过程还是面向对象
我对面向对象编程的目标从来就不是复用。相反，对我来说，对象提供了一种处理复杂性问题的方式。这个问题可以追溯到亚里士多德：您把这个世界视为过程还是对象？在面向对象兴起运动之前，编程以过程为中心，例如结构化设计方法。然而，系统已经到达了超越其处理能力的复杂性极点。有了对象，我们能够通过提升抽象级别来构建更大的、更复杂的系统——我认为，这才是面向对象编程运动的真正胜利
1.1.1 面向过程方法
如图1.1所示，计算机通过数据来记录这个过程的变迁。过程中每一步都会产生、修改或读取一部分数据。每一个环节完成后，数据将顺着过程链传递到下一部分。当我们需要的最终结果在数据中被反映出来，即达到预期状态的时候，我们认为这个过程结束了。从图1.1中也可以看出，销售定单数据是这个过程的核心。为了能很好地分析这样的过程，DFD图被广泛应用。DFD图表达了“（从上一步）输入数据→（在这一步）功能计算→（向下一步）输出数据”这样一个基础单元。例如图中的“销售定单”单元，它读取客户请求，创建了销售定单数据；而“财务处理”单元则读取定购的商品信息，写入财务数据……直到“物流”单元将货物送到消费者手中并将数据写入销售定单后，这个过程才宣告结束
由于数据是如此重要，因此数据的正确性和完备性对系统成功与否至关重要。为了更好地管理数据，不至于让系统运行紊乱，人们通过定义主键、外键等手段将数据之间的关系描绘出来，结构化地组织它们，利用关系理论，即数据库的三大范式来保证它们的完备性和一致性。在面向过程成为主要的软件方法之后，关系型数据库得到了极大的发展，针对数据的分析方法ER模型也深入人心，被极为广泛地使用。
1.1.2 面向过程的困难
其实并非面向过程的方法不正确，只是因为构成一个系统的因素太多，要把所有可能的因素都考虑到，把所有因素的因果关系都分析清楚，再把这个过程模拟出来实在是太困难了。我们的精力有限，计算能力有限，只能放弃对整个过程的了解，重新寻找一个方法，能够将复杂的系统转化成一个个我们可以控制的小单元。这个方法的转换正如：如果一次成型一辆汽车太过困难，我们可以将汽车分解为很多零件，分步制造，再依据预先设计好的接口把它们安装起来，形成最终的产品。
这种把复杂工程转化成标准零部件的做法，在工业界早已非常普遍，这正是一种面向对象的方法。与过程方法不同的是，汽车不再被看作一个一次成型的整体，而是被分解成了许多标准的功能部件来分步设计制造。我们在市面上看到的每一款汽车，都是基于某个商业策略，由不同的标准零部件组合而成。当市场变化、商业策略变化时，可以通过变更标准零部件来迅速生产一款新车型。
面向过程面对如今这个复杂的世界显得无能为力，面向对象又如何呢？从下一节开始我们将进入精彩纷呈的面向对象世界，来探询面向对象方法是如何面对这个复杂世界的。
1.1.3 面向对象方法
面向对象（Object Oriented，简称OO）方法将世界看作一个个相互独立的对象，相互之间并无因果关系，它们平时是“鸡犬之声相闻，老死不相往来”的。只有在某个外部力量的驱动下，对象之间才会依据某种规律相互传递信息。这些交互构成了这个生动世界的一个“过程”。在没有外力的情况下，对象则保持着“静止”的状态。
图1.3展示了这样一个结果，当离散对象们被按规则组合起来以后，就能表达预期的功能。其实世界就是这样组成的。平时看上去每个对象都互无关系，然而当它们按图示规则组织起来之后，踩下刹车，汽车便乖乖停住了。
从图1.3中还可以发现，某些零件不是特殊的只能用于制动鼓的。如螺丝和螺帽，它们还可以用于别的地方。这是面向对象的一个重要特性：复用。
从图1.3还可以读出的另一个重要的信息是，由于对象是独立于最终产品的，只要符合规则要求，这些标准零件就可以替换！我们可以采用钢制的，也可以采用合金制的；可以采用A工厂生产的，也可以采用B工厂生产的。这使得我们可以在不改变既定目标的情况下替换零件，给我们带来了极大的灵活性和扩展能力.
1.1.4 面向对象的困难
如果您正被上面的这些问题困扰着，请您不要怀疑是否面向对象错了。我们把世界看作是由许多对象组成的这并没有错，只是现实世界和对象世界之间存在着一道鸿沟，这道鸿沟的名字就叫做抽象。抽象是面向对象的精髓所在，同时也是面向对象的困难所在。实际上，要想跨越这道鸿沟，我们需要：
■ 一种把现实世界映射到对象世界的方法。
■ 一种从对象世界描述现实世界的方法。
■ 一种验证对象世界行为是否正确反映了现实世界的方法。
幸运的是，UML，准确地说是UML背后所代表的面向对象分析设计方法，正好架起了跨越这道鸿沟的桥梁。在下一节里，让我们带着疑问，来看看UML是如何解决这些问题的。
1.2 UML带来了什么
1.2.1 什么是UML
为了解决这些困难，一批面向对象的设计方法（OOD方法）开始出现，例如Booch86、GOOD（通用面向对象开发）、HOOD（层次化面向对象设计）、OOSE（面向对象结构设计）等。这些方法可以说是如今面向对象方法的奠基者和开拓者，它们的应用为面向对象理论的发展提供了非常重要的实践和经验。同时这些方法也是相当成功的，在不同的范围内拥有着各自的用户群。
然而，虽然解决了从设计到开发的困难，随着应用程序的进一步复杂，需求分析成为比设计更为重要的问题。这是因为人们虽然可以写出漂亮的代码，却常常被客户指责不符合需要而推翻重来。事实上如果不符合客户需求，再好的设计也等于零。于是OOA（面向对象分析）方法开始走上了舞台，其中最为重要的方法便是UML的前身，即：由Booch创造的Booch方法，由Jacobson创造的OOSE、Martin/Odell方法，Rumbaugh创造的OMT、
Shlaer/Mellor方法。这些方法虽然各不相同，但它们的共同的理念却是非常相似的。于是三位面向对象大师决定将他们各自的方法统一起来，在1995年10月推出了第一个版本，称为“统一方法”（Unified Method 0.8）。随后，又以“统一建模语言”（Unified ModelingLanguage）UML 1.0的正式名称提交到OMG（对象管理组织），在1997年1月正式成为一种标准建模语言。之所以改名，是因为UML本身并没有包含软件方法，而仅是一种语言，我们将在1.3节统一过程简介中解释语言和方法的关系。
1.2.2 统一语言
统一语言的另一个意义是要让人和机器都能读懂。好，统一的任务完成了，接下来的任务就是可读性。如果语言可读性很差，人们在理解起来同样会有困难。一门好的语言要能够让人们快速理解并留下深刻印象。
我们知道，相对文字和图形，人脑对图形的接受能力显然更强。因此，UML采用了“可视化”的图形方式来定义语言。
1.2.3 可视化
一幅图画可以表达的含义远远胜过文字描述，上面的那段话让我们试着换一种形式来表达，如图1.5所示。
1.2.4 从现实世界到业务模型
我们所处的这个现实世界充满了丰富多彩但杂乱无章的信息，要建立一个模型并不容易。建立模型的过程是一个抽象的过程，所以要建立模型，首先要知道如何抽象现实世界。如果我们站在很高的抽象层次，以高度归纳的视角来看这个世界的运作，就会发现现实世界无论多复杂，无论是哪个行业，无论做什么业务，其本质无非是由人、事、物和规则组成的。人是一切的中心，人要做事，做事就会使用一些物并产生另一些物，同时做事需要遵循一定的规则。人驱动系统，事体现过程，物记录结果，规则是控制。建立模型的关键就是弄明白有什么人，什么人做什么事，什么事产生什么物，中间有什么规则，再把人、事、物之间的关系定义出来，一个模型也就基本成型了。
那么UML是不是提供了这样的元素来为现实世界建立模型呢？是的。
第一，UML采用称之为参与者（actor）的元模型作为信息来源提供者，参与者代表了现实世界的“人”。参与者是模型信息来源的提供者，也是第一驱动者。另外，在这个顾客就是上帝的时代，以参与者也就是“人”为中心还顺应了“以人为本”这一时代的要求，更容易获得客户满意度。
第二，UML采用称之为用例（use case）的一种元模型来表示驱动者的业务目标，也就是参与者想要做什么并且获得什么。这个业务目标就是现实世界中的“事”。而这件事是怎么做的，依据什么规则，则通过称之为业务场景（business scenario）和用例场景（use case scenario）的UML视图来描绘的，这些场景便是现实世界中的“规则”。
UML通过上面的元模型和视图捕获现实世界的人、事、物和规则，于是现实信息转化成了业务模型，这也是面向对象方法中的第一步。业务模型真实映射了参与者在现实世界的行为，图1.6展示了这种映射关系。
1.2.5 从业务模型到概念模型
虽然上一节中现实世界被业务模型映射并且记录下来，但这只是原始需求信息，距离可执行的代码还很遥远，必须把这些内容再换成一种可以指导开发的表达方式。UML通过称之为概念化的过程（Conceptual）来建立适合计算机理解和实现的模型，这个模型称为分析模型（Analysis Model）。分析模型介于原始需求和计算机实现之间，是一种过渡模型。分析模型向上映射了原始需求，计算机的可执行代码可以通过分析模型追溯到原始需求；同时，分析模型向下为计算机实现规定了一种高层次的抽象，这种抽象是一种指导，也是一种约束，计算机实现过程非常容易遵循这种指导和约束来完成可执行代码的设计工作。
事实上分析模型在整个分析设计过程中承担了很大的职责，起到了非常重要的作用。绘制分析模型最主要的元模型有：
边界类（boundary） 。边界是面向对象分析的一个非常重要的观点。从狭义上说，边界就是大家熟悉的界面，所有对计算机的操作都要通过界面进行。从广义上说，任何一件事物都分为里面和外面，外面的事物与里面的事物之间的任何交互都需要有一个边界。比如参与者与系统的交互，系统与系统之间的交互，模块与模块之间的交互等。只要是两个不同职责的簇之间的交互都需要有一个边界，换句话说，边界决定了外面能对里面做什么“事”。在后续的章节中，读者会感受到边界的重要性，边界能够决定整个分析设计的结果。
实体类（entity） 。原始需求中领域模型中的业务实体映射了现实世界中参与者完成业务目标时所涉及的事物，UML采用实体类来重新表达业务实体。实体类可以采用计算机观点在不丢失业务实体信息的条件下重新归纳和组织信息，建立逻辑关联，添加那些实际业务中不会使用到，但是执行计算机逻辑时需要的控制信息等。这些实体类可以看作是业务实体的实例化结果。
控制类（control） 。边界和实体都是静态的，本身并不会动作。UML采用控制类来表述原始需求中的动态信息，即业务或用例场景中的步骤和活动。从UML的观点看来，边界类和实体类之间，边界类和边界类之间，实体类和实体类之间不能够直接相互访问，它们需要通过控制类来代理访问要求。这样就把动作和物体分开了。考虑下，实际上在现实世界中，动作和物体也是分开描述的。
1.2.6 从概念模型到设计模型
1.2.7 面向对象的困难解决了吗
1.2.7.1 从现实世界到业务模型
1.2.7.2 从业务模型到概念模型
1.2.7.3 从概念模型到设计模型
1.3 统一过程简介
1.3.1 RUP是什么
严格说起来UML并不是一个方法，而只是一种语言。UML定义了基本元素，定义了语法，但是如果要做一个软件项目，还需要有方法的指导。正如写文章有文法，有五言律，有七言律一样，UML也需要有方法的指导来完成一个软件项目。RUP无疑是目前与UML集成和应用最好、最完整的软件方法。
RUP（Rational Unified Process）译为统一过程。统一过程并非是因为UML才诞生的，也不是最近才出来的软件方法，而是有着很长时间的发展，有着很深的根源。统一过程归纳和整理了很多在实践中总结出来的软件工程的最佳实践，是一个采用了面向对象思想，使用UML作为软件分析设计语言，并且结合了项目管理、质量保证等许多软件工程知识综合而成的一个非常完整和庞大的软件方法。统一过程经过了三十多年发展，和统一过程本身所推崇的迭代方法一样，统一过程这个产品本身也经过了很多次的迭代和演进，才最终推出了现在这个版本。图1.10展示了统一过程的演进过程。
工件：工件也称为成果物或者制品（Artifact），这与可交付物（Deliverable）是有一些差别的。当某一个或某一些工作是最终产品的一部分需要交付出去时，才被称为可交付物。而在软件生产过程中任何留下记录的事物，都可称为工件。
1.3.4 RUP与最佳实践
只供参考，喜欢请支持正版图书