大象：THINKING IN UML 第1章 为什么需要UML.ppt

UML提供的元素 第一参与者，UML采用称之为参与者(actor)的元模型作为信息来源提供者，参与者代表现实世界的“人”。参与者是模型信息来源的提供者，也是第一驱动者。 另外，在这个顾客就是上帝的时代，以参与者也就是“人”为中心还顺应了“以人为本”这一时代的要求，更容易获得客户满意度。 用例和规则 第二，UML采用称之为用例(use case)的一种元模型来表示驱动者的业务目标，也就是参与者想要做什么并且获得什么。这个业务目标就是现实世界中的“事”。而这件事是怎么做的，依据什么规则，则通过称之为业务场景(business scenario)和用例场景(use case scenario)的UML视图来描绘。这些场景便是现实世界的“规则”。 “物” 最后，UML通过称之为业务对象模型(business object model)的视图说明在达成这些业务目标的过程中涉及到的事物，用逻辑概念来表示它们，并定义它们之间的关系。业务对象模型则代表了现实世界中的“物”。 从现实世界到业务模型 概念模型 得到业务模型仅仅是一个开始，要想将业务模型转化到计算机能理解的模型，还有一段路要走。其中最重要的一步便是概念模型。 分析模型 虽然上一节中现实世界被业务模型映射并且记录下来，但这只是原始需求信息，距离可执行的代码还很遥远，必须把这些内容再换成一种可以指导开发的表达方式。UML通过称之为概念化的过程(Conceptual)来建立适合计算机理解和实现的模型，这个模型称为分析模型(Analysis Model)。 分析模型 分析模型介于原始需求和计算机实现之间，是一种过渡模型。分析模型向上映射了原始需求，可执行代码可以通过分析模型追溯到原始需求；同时，分析模型向下为计算机实现规定了一种高层次的抽象，这种抽象是一种指导，也是一种约束，计算机实现过程非常容易遵循这种指导和约束来完成可执行代码的设计工作。 分析模型的元模型 事实上分析模型在整个分析设计过程中承担了很大的职责，起到了非常重要的作用。绘制分析模型最主要的元模型有： 边界类(boundary)。边界是面向对象分析的一个非常重要的观点。从狭义上说，边界就是大家熟悉的界面，所有对计算机的操作都要通过界面进行。 实体类 实体类(entity)。原始需求中领域模型中的业务实体映射了现实世界中参与者完成业务目标时所涉及的事物，UML采用实体类来重新表达业务实体。实体类可以采用计算机观点在不丢失业务实体信息的条件下重新归纳和组织信息，建立逻辑关联，添加那些实际业务中不会使用到，但是执行计算机逻辑时需要的控制信息等。这些实体类可以看作是业务实体的实例化结果。 控制类 控制类(contr01) 。边界和实体都是静态的，本身并不会动作。UML采用控制类来表述原始需求中的动态信息，即业务或用例场景中的步骤和活动。从UML的观点看来，边界类和实体类之间，边界类和边界类之间，实体类和实体类之间不能够直接相互访问，它们需要通过控制类来代理访问要求。这样就把动作和物体分开了。 边界类实际上代表了原始需求中的“事”；实体类则由业务模型中的领域模型转化而来，它代表了现实世界中的“物”：控制类则体现了现实世界中的“规则”，也就是定语；再加上由参与者转化而来的系统的“用户”，这样一来，“人”也有了。 业务模型到概念模型 概念模型到设计模型 在设计模型中，概念模型中的边界类可以被转化为操作界面或者系统接口；控制类可以被转化为计算程序或控制程序，例如工作流、算法体等；实体类可以转化为数据库表、XML文档或者其他带有持久化特征的类。 概念模型到设计模型 面向对象分析设计完整过程 从现实世界到业务模型 从业务模型到概念模型 从概念模型到设计模型 统一过程RUP RUP(Rational Unified Process)译为统一过程。统一过程并非是因为UML才诞生的，也不是最近才出来的软件方法，而是有着很长时间的发展，有着很深的根源。统一过程归纳和整理了很多在实践中总结出来的软件工程的最佳实践，是一个采用了面向对象思想，使用UML作为软设计语言，并且结合了项目管理、质量保证等许多软件工程知识综合而成的一个非常完整和软件方法。统一过程经过了三十多年发展，和统一过程本身所推崇的迭代方法一样，统一过产品本身也经过了很多次的迭代和演进，才最终推出了现在这个版本。 统一过程RUP 统一过程归纳和集成了软件开发活动中的最佳实践，它定义了软件开发过程中最重要的工作(四个阶段和九个核心工作流)，定义了参与软件开发过程的各种角色和他们的职责，定义了软件生产过程中产生的工件(见注)，并提供了模板。最后，采用演进式软件生命周期将工作、角色和工件串在一起，形成了统一过程。 统一过程RUP 统一过程将软件生产分为了四个阶段和九个核心工作流，每个工作流在不