19.9.11统一建模语言UMI.和统一开发过程RUP

    现代软件开发面临着要尽快将产品推向市场和开发高质量、低成本产品的矛盾。要成功地解决软件开发中的矛盾，必须将软件开发作为一种团队活动。为了有效组织开发和进行交流，团队中不同参与者统一使用公共的过程、公共的表达语言，以及支持该语言和过程的工具。Rational统一过程(RUP)就是这样一种公共过程，而且已经在多个软件开发组织的实践中被证实可以有效解决上述矛盾。统一建模语言(UML)则可以作为开发团队的公共语言。UML不是完整的开发方法，UML规范也没有定义标准的过程，而RUP则是有效使用UML的指南。这里着重介绍UML和RUP的基本概念，并描述如

何在RUP的指导下用UML建模。

    1. UML

    UML是一种可视化的建模语言，结合了Booch, Objectory和OMT方法，同时吸收了其他大量方法学的思想，提供了一种表示的标准。1997年OMG采纳UML作为软件建模语言的标准，可以应用于不同的软件开发过程。

    下面介绍UML涉及的一些基本概念。

    1)视图(Views )

    UML用模型来描述系统的静态结构和动态行为。为了捕捉要构建的软件系统的所有决策信息，需要从团队中不同参与者的角度出发，为系统的体系结构建模，形成不同的系统视图。要描述一个软件系统，下面的五种视图尤为重要。

    (1)用例视图(Use case view )

    用例视图定义系统的外部行为，是最终用户、分析人员和测试人员所关注的。用例视图定义了系统的需求，是描述系统设计和构建的其他视图的基础，即用例驱动。用例视图也称为用户模型视图。

    (2)逻辑视图(Logic view )

    逻辑视图描述逻辑结构，该逻辑结构支持用例视图描述的功能，它描述了问题空间中的概念以及实现系统功能的机制，如类、包、子系统等，因而是编程人员最关心的。

逻辑视图又称做结构模型视图或静态视图。

    (3)实现视图(Implementation view)

    实现描述用于组建系统的物理组件，如可执行文件、代码库和数据库等系统程序员所看到的软件产物，是和配置管理以及系统集成相关的信息。实现视图又称为组件视图( Component view ) 。

    (4)过程视图(Process view )

    过程视图描述将系统分解为过程和任务，以及这些并发元素之间的通信与同步。过程视图对于系统集成人员特别重要，因为他们需要考虑系统的性能和吞吐量等。过程视图也称为并发视图、动态视图或者协作视图等。

    (5)部署视图(Deployment view )

    描述系统的物理网络布局，是系统工程师和网络工程师所感兴趣的。又称做物理

视图。

    2)图(Diagrams )

每个视图都由一个或者多个图组成，一个图是系统体系结构在某个侧面的表示，所有的图在一起组成系统的完整视图。UML提供了九种不同的图，分为静态图和动态图两大类。静态图包括用例图、类图、对象图、组件图和配置图，动态图包括序列图、状态图、协作图和活动图。

    (1)用例图(Use case diagram)

    用例图描述系统的功能，由系统、用例和角色(Actor)三种元素组成。图中显示若干角色以及这些角色和系统提供的用例之间的连接关系。用例是系统对外提供的功能的描述，是角色和系统在一次交互过程中执行的相关事务的序列。角色是与系统、子系统或类交互的外部人员、进程或事物。

    用例之间存在扩展、使用和组合三种关系。角色之间可以用通用化关系将某些角色的共同行为抽象为通用行为。在UML中，用例图是用例视图的重要组成部分。

    (2)类图(Class diagram)

    类图用来表示系统中的类以及类与类之间的关系，描述系统的静态结构，用于逻辑视图中。类是对象的抽象描述。所谓对象就是可以控制和操作的实体，类是具有共同的结构、行为、关系、语义的一组对象的抽象。类的行为和结构特征分别通过操作和属性表示。

    类与类之间有多种关系，如关联、依赖、通用化、聚合等。关系提供了对象之间的通信方式。关联关系用于描述类与类之间的连接，通常是双向的·通用化又称继承，是通用元素和具体元素之间的一种分类关系，具体元素完全拥有通用元素的信息，并且还可以附加其他信息。聚合关系具有较强的耦合性，描述整体与部分的关系。依赖关系描述两个模型元素之间语义上的连接关系，其中一个元素是独立的，另一个元素依赖于独立的模型元素，独立元素的变化将影响到依赖元素。

    (3)对象图(Object diagram)

    对象图是类图的示例，类图表示类和类与类之间的关系，对象图则表示在某一时刻这些类的具体实例以及这些实例之间的具体连接关系，可以帮助人们理解比较复杂的类图。对象图也可以用于显示类图中的对象在某一点的连接关系。对象图常用于用例视图和逻辑视图中。

    (4)状态图(State diagram )

    状态图主要用来描述对象、子系统、系统的生命周期。通过状态图可以了解一个对象可能具有的所有状态、导致对象状态改变的事件，以及状态转移引发的动作。状态是对象操作的前一次活动的结果，通常由对象的属性值来决定。事件指的是发生的且引起某些动作执行的事情。状态的变化称做转移，与转移相连的动作指明状态转移时应该做的事情。状态图是对类描述的事物的补充说明，用在逻辑视图中描述类的行为。

    (5)序列图(Sequence diagram)

    面向对象系统中对象之间的交互表现为消息的发送和接收。序列图反映若干个对象之间的动态协作关系，即随着时间的流逝，消息是如何在对象之间发送和接收的。序列图表现为二维的形式，其中的纵坐标轴显示时间，横坐标轴显示对象。序列图中重点反映对象之间发送消息的先后次序，常用在逻辑视图中。

    (6)协作图(Collaboration diagram)

    协作图主要描述协作对象之间的交互和链接。协作图和序列图同样反映对象间的动态协作，也可以表达消息序列，但重点描述交换消息的对象之间的关系，强调的是空间关系而非时间顺序。

    (7)活动图(Activity diagram )

    活动图显示动作及其结果，着重描述操作实现中所完成的工作以及用例实例或对象中的活动。活动图中反映了一个连续的活动流，常用于描述一个操作执行过程中所完成的工作。活动图也有其他的用途，如显示如何执行一组相关的动作，以及这些动作如何影响它们周围的对象，说明一次商务活动中的工人、工作流、组织和对象是如何工作的等。

    (8)组件图(Component diagram)

    组件图用来反映代码的物理结构。组件可以是源代码、二进制文件或可执行文件，包含逻辑类的实现信息。实现视图由组件图构成。

    (9)配置图(Deployment diagram )

    配置图用来显示系统中软件和硬件的物理架构。图中通常显示实际的计算机和设备

及它们之间的关系。配置图用来构成配置视图，描述系统的实际物理结构。

    3)模型元素

    可以在图中使用的概念统称为模型元素。模型元素用语义、元素的正式定义或确定的语句的准确含义来定义。模型元素在图中用相应的符号表示，即视图元素。一个模型元素可以用在多个不同的图中，但总是具有相同的含义和符号表示，并且出现的方式应符合一定的规则。

    除了类、对象、消息等概念外，模型元素之间的连接关系如关联、依赖、通用化也

是模型元素。另外，模型元素也包括消息、动作和版型等。

    4)通用机制

    通用机制用于为图附加一些无法用基本的模型元素表示的信息，如注释(note )、修饰(adornment)和规格说明(specification)等。

    在图的模型元素上添加修饰为模型元素附加一定的语义，这样，建模人员就可以方便地区别类型与实例。

    无论建模语言怎样扩展，它都不可能适用于描述任何事物。UML提供的注释能力能够在模型中添加一些模型元素无法表示的额外信息，对某个元素作出解释或说明。

模型元素具有的一些性质是以数值方式体现的。一个性质用一个名称和一个值表示，又称做加标签值(tagged value )。 UML中预定义了许多性质，一般作为模型元素实例的附加规格说明。这种规范说明方式是非正式的，不直接显示在图中。

    5)扩展机制

    为了使建模人员根据需要对基本建模语言进行一定的扩展，UML提供了版型、加标签值和约束等扩展机制。

    版型机制是指在已有的模型元素基础上建立一种新的模型元素。版型比现有元素多一些特别的语义，其使用场所和产生版型的原始元素相同。版型的存在避免了UML语言过于复杂化，同时也使UML能够适应各种需求。

    加标签值也称为性质。除了UML语言中预定义的性质外，用户还可以为元素定义一些附加信息，即定义性质。

    约束是对元素的限制。通过约束限定元素的用法或元素的语义。

    通过扩展机制可以扩展UML以适用于某种具体的方法、过程或组织。

    6) UML建模

    用UML语言建造系统模型时，并不是只建立一个模型。在系统开发的每个阶段都要建造不同的模型，建造这些模型的目的也不同。需求分析阶段建造的模型用来捕获系统的需求，描绘与真实世界相应的基本类和协作关系。设计阶段的模型是分析模型的扩充，为实现阶段作指导性的、技术上的解决方案。实现阶段的模型是真正的源代码，编译后就变成了程序。最后的配置模型则是在物理架构上解释系统是如何展开的。

    UML尽可能地结合了世界范围内面向对象项目的成功经验，因而它的价值在于它体现了世界上面向对象方法实践的最好经验，并以建模的形式将它们打包，以适应开发大型复杂系统的要求。但需要说明的是，UML作为一种建模语言，目的是为不同领域的人们提供统一的交流标准，其本身并不能保证系统的质量。使用UML建模，必须依照某种方法或过程进行。

    在众多的软件设计和实现的经验中，最突出的有两条，一是注重系统体系结构的开发，一是注重过程的迭代和递增性。尽管UML本身没有定义任何过程，但UML对任何使用它的方法或过程提出的要求是:支持用例驱动，以体系结构为中心以及递增和迭代地开发。

    2. Rational统一过程—RUP

    UML语言适用于各种软件开发方法、软件生命周期的各个阶段、各种应用领域和各种开发工具。UML规范实质上仅仅阐明了建模的基本元素、表示法、相关语义和扩展机制，好比只提供了构筑大厦的砖头和水泥，因此在UML的应用过程中选用正确的开发方法论(methodology)是成功建模的关键。

只有在对基本概念正确理解的基础上采用了正确的方法和步骤才能建立正确的UML模型。这里我们把采用UML的面向对象开发方法，通常包括GOAD方法论和开发过程模型等，统称为“UML方法，，。例如，RUP (Rational Unified Process. Rational统一过程)就是一种基于UML方法的开发过程向导和框架。

    简单地说，软件工程过程描述做什么、怎么做、什么时候做以及为什么要做，描述了一组以某种顺序完成的活动。过程的结果是一组有关系统的文档，例如模型和其他一些描述，以及对最初问题的解决方案。过程描述的一个重要部分是定义如何使用人力及其工具和信息等资源的一些规则来完成某个确定的目标，为用户的问题提供解决方案。

    目前比较流行的有几种主要的过程，包括Rational统一过程、OPEN过程和面向对象软件过程(OOSP )。其中RUP是由Booch等方法学家以Rational的Objectory为核心提出的，因此在这个过程中使用UML是很自然的。

RUP是Ratinal公司开发的过程产品，是软件工程化的过程。RUP提供了在开发机构中分派任务和责任的纪律化方法。它的目标是在可预见的日程和预算的前提下，确保满足最终用户需求的高质量产品。也是在国内应用比较普遍的过程产品。