《Thinking in UML》 笔记——1、为什么需要UML
为什么需要UML
面向过程还是面向对象
略...
什么是UML
编程需要的对象不但不能够从设计中自然而然地推导出来，而且强调连续性和过程化的结构化设计与事件驱动的离散对象结构之间有着难以调和的矛盾。由于设计无法自然推导出对象结构，使得对象结构到底代表了什么样的含义变得模糊不清。同时，设计如何指导编程，也成为了困扰在人们心中的一大疑问。
为了解决这些困难，一批而向对象的设计方法(OOD方法)开始出现，例如Booch86、GOOD(通用面向对象开发)、HOOD(层次化面向对象设计)、OOSE(面向对象结构设计)等。虽然解决了从设计到开发的困难，随着应用程序的进一步复杂，需求分析成为比设计更为重要的问题。这是因为人们虽然可以写出漂亮的代码，却常常被客户指责不符合需要而推翻重来。事实上如果不符合客户需求，再好的设计也等于零。于是OOA(面向对象分析)方法开始走上了舞台，其中最为重要的方法便是UML的前身，即由Booch创造的Booch方法，由Jacobson创造的OOSE、Martin/OdeII 方法和Rumbaugh创造的OMT、Shlaer/Mellor方法。这些方法虽然各不相同，但它们的共同的理念却是非常相似的。于是三位面向对象大师决定将他们各自的方法统一起来，在1995年10月推出了第一个版本，称为“统一方法”(Unified Method 0.8)。随后，又以“统一建模语言”(Unified Modeling Language) UML 1.0
的正式名称提交到OMG(对象管理组织)，在1997年1月正式成为一种标准建模语言。之所以改名，是因为UML本身并没有包含软件方法，而仅是一种语言。
统一语言
即要让人和机器都能读懂。
可视化
在这里可视化的含义并不是指UML的图形是可以用眼睛看到的，可视化的含义是指，UML通过它的元模型和表示法，把那些通过文字或其他表达方法很难表达清楚的，隐晦的潜台词用简单直观的图形表达和暴露出来，准确而直观地描述复杂的含义。把“隐晦”的变成“可视”的，也就是把文字变成图形，这才是UML可视化的真正含义。
从现实世界到业务模型
我们所处的这个现实世界充满了丰富多彩但杂乱无章的信息，要建立一个模型并不容易。建立模型的过程是一个抽象的过程，所以要建立模型，首先要知道如何抽象现实世界。如果我们站在很高的抽象层次，以高度归纳的视角来看这个世界的运作，就会发现现实世界无论多复杂，无论是哪个行业，无论做什么业务，其本质无非是由人、事、物和规则组成的。
人是一切的中心，人要做事，做事就会使用一些物并产生另一些物，同时做事需要遵循一定的规则。人驱动系统，事体现过程，物记录结果，规则是控制。建立模型的关键就是弄明白有什么人，什么人做什么事，什么事产生什么物，中间有什么规则，再把人、事、物之间的关系定义出来，一个模型也就基本成型了。
第一，UML采用被称之为参与者(actor)的元模型作为信息来源提供者，参与者代表了现实世界的“人”。参与者是模型信息来源的提供者，也是第一驱动者。换句话说，要建立的模型的意义完全被参与者决定，所建立的模型也是完全为参与者服务的，参与者是整个建模过程的中心。UML之所以这样考虑，是因为最终计算机的设计结果如果不符合客户需求，再好的设计也等于零。与其在建立计算机系统后因为不符合系统驱动者的意愿而推倒重来，还不如在一开始就从参与者的角度为将来的计算机系统规定好它必须实现的那些功能和必须遵守的参与者的意志，由驱动者来检验和决定将来的计算机系统要如何运作。
另外，在这个顾客就是上帝的时代，以参与者也就是“人”为中心还顺应了“以人为本”这一时代的要求，更容易获得客户满意度。
第二，UML采用被称之为用例(use case)的一种元模型来表示驱动者的业务目标，也就是参与者想要做什么并且获得什么。这个业务目标就是现实世界中的“事”。而这件事是怎么做的，依据什么规则，则通过被称之为业务场景(business scenario)和用例场景(use case scenario)的UML视图来描绘的，这些场景便是现实世界中的“规则“。最后，UML通过被称之为业务对象模型(business object model)的视图来说明在达成这些业务目标的过程中涉及到的事物，用逻辑概念来表示它们，并定义它们之间的关系。业务对象模型则代表了现实世界中的“物”。
UML通过上面的元模型和视图捕获现实世界的人、事、物和规则，于是现实信息转化成了业务模型，这也是面向对象方法中的第一步。业务模型真实映射了参与者在现实世界的行为，下图展示了这种映射关系。
从业务模型到概念模型
UML通过被称之为概念化的过程(Conceptual)来建立适合计算机理解和实现的模型，这个模型称为分析模型(Analysis Model)。分析模型介于原始需求和计算机实现之间，是一种过渡模型。分析模型向上映射了原始需求，计算机的可执行代码可以通过分析模型追溯到原始需求;同时，分析模型向下为计算机实现规定了一种高层次的抽象，这种抽象是一种指导，也是一种约束，计算机实现过程非常容易遵循这种指导和约束来完成可执行代码的设计工作。
事实上分析模型在整个分析设计过程中承担了很大的职责，起到了非常重要的作用。绘制分析模型最主要的元模型有：
边界类(boundary)：边界是面向对象分析的一个非常重要的观点。狭义上说，边界就是大家熟悉的界面，所有对计算机的操作都要通过界面进行。从广义上说，任何一件事物都分为里面和外面，外面的事物与里面的事物之间的任何交互都需要有一个边界。比如参与者与系统的交互，系统与系统之间的交互，模块与模块之间的交互等。只要是两个不同职责的簇之间的交互都需要有一个边界，换句话说，边界决定了外面能对里面做什么“事”。
实体类(entity)：原始需求中领域模型中的业务实体映射了现实世界中参与者完成业务目标时所涉及的事物，UML采用实体类来重新表达业务实体。实体类可以采用计算机观点在不丢失业务实体信息的条件下重新归纳和组织信息，建立逻辑关联，添加那些实际业务中不会使用到，但是执行计算机逻辑时需要的控制信息等。这些实体类可以看作是业务实体的实例化结果。
控制类(control)：边界和实体都是静态的，本身并不会动作。UML采用控制类来表述原始需求中的动态信息，即业务或用例场景中的步骤和活动。从UML的观点看来，边界类和实体类之间，边界类和边界类之间，实体类和实体类之间不能够直接相互访问，它们需要通过控制类来代理访问要求。这样就把动作和物体分开了。考虑一下，实际上在现实世界中，动作和物体也是分开描述的。
举例：读者或许在小时候都玩过一个游戏，每个同学发四张小纸条，在第一张纸条上写上xxx的名字，在第二张纸条上写上在什么地方，在第三张纸条上写上一个动作，在第四张纸条上写一个物体，然后将这些字条分开放在四个箱子里，再随意地从这四个箱子里各取一张纸条，就能组成很多非常搞笑的句子，例如张xx在公园里跳圆规之类的奇怪语句，一个班的同学常常笑得前仰后合。
游戏虽然是游戏，但说明了一个道理，只要有人、事、物和规则(定语)，就能构成一个有意义的结果，无非是是否合理而已。分析类也是应用这个道理来把业务模型概念化的。由于所有的操作都通过边界类来进行，能做什么不能做什么由边界决定，所以边界类实际上代表了原始需求中的“事”;实体类则由业务模型中的领域模型转化而来，它代表了现实世界中的“物。控制类则体现了现实世界中的“规则”，也就是定语。再加上由参与者转化而来的系统的“用户”，这样一来，“人”也有了。有了人、事、物、规则，我们就可以像那个游戏一样把它们组合成各种各样的语句，只不过不是为了搞笑，所以不能随意组合，而是要依据业务模型中已经描绘出来的用例场景来组合这些元素，让它们表达特定的业务含义。
从概念模型到设计模型
概念模型距离可执行代码己经非常接近了。概念模型使我们获得了软件的蓝图，获得了建设软件所需要的所有组成内容以及建设软件所需要的所有必要细节。这就类似于我们己经在图纸上绘制出了一辆汽车所有的零部件，并且绘制出如何组装这些零部件的步骤，接下来的工作就是建造或者购买所需的零部件，并送到生产线去生产汽车。
设计模型的工作就是建造零部件，组装汽车的过程。在大多数情况下，实现类可以简单地从分析类映射而来。在设计模型中，概念模型中的边界类可以被转化为操作界面或者系统接口。控制类可以被转化为计算程序或控制程序，例如工作流、算法体等;实体类可以转化为数据库表、XML文档或者其他带有持久化特征的类。这个转化过程也是有章可循的，一般来说，可以遵循的规则有：
· 软件架构和框架：软件架构和框架规定了实现类必须实现的接口、必须继承的超类、必须遵守的编程规则等。例如当采用J2EE架构时，Home和Remote接口就是必需的。
· 编程语言：各类编程语言有不同的特点，例如在实现一个界面或者一个可持久化类时，采用C++还是Java作为开发语言会有不同的设计要求。
· 规范或中间件：如果决定采用某个规范或采用某个中间件时，实现类还要遵循规范或中间件规定的那些必需特性。
实际上，由于软件项目可以选择不同的软件架构和框架，可以选择不同的编程语言，也可以选择不同的软件规范，还可以购买不同的中间件，因此同样的概念模型会因为选择不同而得到不同的设计模型。下图展示了从概念模型到设计模型的转化过程：
统一过程(RUP)
RUP 是什么
严格说起来UML并不是一个方法，而只是一种语言。UML定义了基本元素，定义了语法，但是如果要做一个软件项目，还需要有方法的指导。正如写文章有文法，有五言律，有七言律一样，UML也需要有方法的指导来完成一个软件项目。RUP无疑是目前与UML集成和应用最好、最完整的软件方法。
RUP (Rational Unified Process)译为统一过程。统一过程并非是因为UML才诞生的，也不是最近才出来的软件方法，而是有着很长时间的发展，有着很深的根源。统一过程归纳和整理了很多在实践中总结出来的软件工程的最佳实践，是一个采用了面向对象思想，使用UML作为软件分析设计语言，并且结合了项目管理、质量保证等许多软件工程知识综合而成的一个非常完整和庞大的软件方法。统一过程经过了三十多年发展，和统一过程本身所推崇的迭代方法一样，统一过程这个产品本身也经过了很多次的迭代和演进，才最终推出了现在这个版本。
RUP 与 UML
统一过程和UML是不同的两个领域。UML是一种语言，用来描述软件生产过程中要产生的文档，统一过程则是指导如何产生这些文档以及这些文档要讲述什么的方法。虽然现在统一过程是指导UML的方法中最著名、应用最广、可能也是最成功的一个，但这两者却不是完全不可以分开的。
RUP 与软件工程
统一过程方法是一个庞大和复杂的知识体系，它几乎囊括了软件开发这一生产过程所需要知识的方方面面。但同时，也正由于统一过程的复杂和庞大，使得它学习起来很困难;要在实际项目中实施统一过程也非常困难，统一过程也是迄今为止最重量级的软件方法。统一过程是一种追求稳定的软件方法，它追求开发稳定架构，控制变更，立足于长期战略，适用于指导大中型软件产品的开发。由于统一过程是一种重量级的方法，因此实施统一过程是高成本的，是一个组织战略的选择，而不仅仅是某一个项目的战术选择。
另一方面是出于提高软件技术水平和质量的需要。我们知道要生产一个好的软件产品，必须保证需求、分析、设计、质量等工作。统一过程由于集成了面向对象方法、UML语言、核心工作流、工件模板和过程指导等许多知识，使得软件生产工作能够利用这些成熟的指导来提高组织内整体软件认识水平和开发人员的软件素质，借此来提高软件产品的技术水平和质量。
再一方面，统一过程适于开发稳定的架构，它通过不断的演进来逐步推进软件产品，这一特点使得它特别适合于长期战略的软件产品。例如那些长期立足于做某一个行业，希望做精做深，做行业整体解决方案的组织。
但是统一过程由于太过于庞大和复杂，相对于轻量级的敏捷方法，例如著名的XP(极限编程)方法来说，显得死板和难以实施。统一过程不但不能快速适应需求的变化，而且变更一个需求要经历复杂的过程和很多额外的工作。对于较小的组织和项目来说，使用统一过程的确有些费力不讨好，也因此招来了许多置疑。
笔者觉得这种置疑是大可不必的，轻量级的敏捷方法和重量级的统一过程都是非常优秀的软件方法，只是它们各有各的适用范围。轻量级的XP方法追求在变化中用最快速的办法适应变更，用小的管理成本保障软件质量.对于中小型公司和中小型软件来说，XP的确是非常有效的软件方法，它能大大降低管理、开发成本和技术风险。不过对于大型公司和大型项目来说，XP就不适用了，这时RUP却非常适合。因为对大型项目来说，一个项目有可能经历几年甚至几十年的时间，涉及几千甚至几万人，如果没有一个稳定的架构，在朝令夕改的方式下项目是不可能顺利实施下去的。
RUP 与最佳实践
统一过程集成了很多过程类的最佳实践，这些最佳实践中包括用例驱动、架构导向、构件化等。另外，统一过程不仅仅集成了软件过程的技术方面的内容，还集成了大量的管理方面的内容，涉及到了软件工程的方方面面。可以说是目前为止最全面、最广泛、最综合的软件休系。因此笔者建议读者认真学习统一过程。学习统一过程的目的不一定要在项目中去实施，因为上一节讲到实施统一过程并不容易，而是因为学习统一过程将了解到软件的本质，对提升软件“智商”是非常有好处的。
