1． 软件工程的发展
计算机从刚开始被发明到现在，经过了广泛的发展和研究，也变得越来越好，其中，由于计算机技术带给人们越来越多的便利，使得人们更趋向于研发计算机应用软件跟技术，为人们提供更多的服务。但是，有一段时间之内，计算机软件的发展远远落后于整个计算机行业的发展态势。计算机软件在应用的过程中遇到了许多问题和危机，给整个计算机系统的发展带来了危害。因此，面对此类问题的出现，人们开始逐渐研发并构建软件工程，使得软件逐渐向对象软件进行开发[1]。
为了能使软件在发展的过程中更为具体和系统，软件行业的专家Booch、Jacobson和Rumbaugh早在1995年就开始在彼此的研究方案和概念中进行相互分析，并汲取对方理论中的可取之处，进行更为系统的研究，在此基础上，将软件的应用和分析进行了范围上的扩充，使模型变得更为广泛和抽象。为了方便人们进行理解，此后又提出了建立统一的语言UML，后来又出现了为了方便软件规范化的开发软件RUP。
计算机使用技术在日常生活的方方面面都得到了相应的使用，而且现在对计算机技术的需求也不断扩大， 各个学校也开始逐渐开设计算机应用管理技术，但是在信息管理者的方面来说，计算机在应用起来并不是十分顺畅。因为读者在进行计算机信息的读取时，需要采用相应的管理条件和硬件条件，读取不同的信息需要不同的管理要求。因此，就需要系统同时具备两种不同的交互功能，也要有发布系统的功能。另外，在设计方面需要给人们耳目一新的感觉，使人们能感到美的体验。当前采用的系统就是根据人力资源管理所需要的进行设计的，能够符合大部分管理者的要求，因此为了能够是全部的管理信息得到开发和应用，需要在功能上进行更大的扩展，使系统在应用起来能够更加具体、方便[2]。
2． 软件开发方法
2.1 软件生命周期法
软件生命周期指的是整个软件从开始进行使用到最终完全无法操作的整个过程。此周期主要包括以下几个阶段：软件计划、需求分析、系统设计、编码的实现、对系统的设计和检测以及维护运行等阶段[3]
在进行各个阶段的测试过程中，需要确定好我们最终的目标。其中，对软件进行功能的描述和使用，对软件进行限制，并对其进行相应的说明，使该项工作能够得到较为理想的结果。
在需求分析阶段[4]，主要是使用系统化的分析方法对软件的功能和结构进行描述，尽可能地捕捉用户，尤其是最终用户的期望和约束。这一般分为系统概要设计阶段和系统详细设计阶段两部分。前者是从系统整体结构出发，将系统的功能模块划分出来，并定义其主要的输入和输出，而具体的处理过程放在下一阶段进行。在详细设计阶段，要对上一阶段划分出来的各个模块进行具体的描述，这时需要定义一些数据结构或文件格式，甚至是函数的名称、参数等信息。其中对数据库的逻辑设计和物理设计也属于这一阶段。
在编码阶段[5]，主要的工作集中在对程序设计语言进行评估和选择，选择合适的开发工具和IDE，并在此基础之上进行代码开发，完成系统预定的各个功能模块。
在测试阶段[6]，主要的原则是证明软件中存在错误或隐患，而不是证明软件的正确性。排除错误是测试的主要目的，错误包括没有实现功能或功能没有按照业务要求进行、性能没有达到预定的期望、存在某些不能再现的情形等。测试一般有三个阶段：单元测试、组装测试和系统测试。单元测试又叫单体测试，是对系统实现的每个功能模块进行单独的测试。功能模块可以是一个函数，也可以是一个封装的类或组件，根据模块的代码进行强项调用进行测试。组装测试是根据功能模块的划分粒度不同而产生的，是将需要进行配合才能实现的功能拼装提来，组成更加完善的功能模块，对其进行输入输出的测试。系统测试时针对整个运行的系统进行的，要测试系统的功能、业务流程、安全性、负载性能等，是从用户使用的角度进行的测试。
一般情况下，比较保险的开发方式是将软件测试嵌入到软件的编码过程中，两者交叉进行 [7]。
在对系统进行维护和运行时，首先要把系统安装到实际的客户使用环境中去，按照客户的条件进行系统的试运行。这里主要根据用户的业务需求，对系统各个功能模块进行操作，观察系统是否按照业务的标准进行输入结果，并达到合理的运行效率。这种试运行是对系统安全性的测试，这个阶段输出的系统日志是非常重要的，它可以为系统发现错误后的修改提供重要的线索。这一阶段可以持续的时间很长，直到该软件系统不再使用。
传统的瀑布模型[8] 将软件开发分为以下几个阶段：制定计划、需求分析、软件设计、编码、测试、运行与维护。这是一个非常有价值的软件开发管理模型。每个阶段都是承上启下的，严格按照模型规定的开发顺序进行，可以避免很多返工的事情发生。每个阶段都应具有完善的质量保证体系，为下一阶段提供有利的支撑。在上一阶段没有完成相应的开发条件前，一般不允许进行下一阶段的开发。
2.2 原型法
在大型工程设计中经常使用样机，建造样机主要有两个目的[9]：第一是检验关键设计方案的正确性；第二是检验系统是否真正满足用户的需要。在计算机硬件系统开发中，每一种新产品的问世几乎都离不开样机的制造。对于软件系统，构造原型系统（相当于工程中的样机）的目的是使用户通过原型系统的实践而获得关于未来的系统将怎样为他们工作的更具体更直接的概念，从而可以更准确地提出和确定他们的要求。
采用构造原型系统策略的主要理由是[10]：由于人类对事物的认识是一个由浅入深、由模糊到清楚地过程，因此不能预先确定所有的需求；在用户和软件开发人员之间存在着交流的障碍；用户可以通过一个实在的模型获得感性认识，以确定需求；在开发过程中重复和反复是必要地和不可避免的；目前有快速建立原型系统的工具可以选用。
用户在使用了原型系统后就能够指出系统中的哪些特性是他们所喜欢的，哪些特性是他们所不能接受的，以及他们还需要哪些新的功能。在用户需求的基础上开发出来的经过实践检验的系统更可能真正地满足用户的需要[11]。
原型法开发模型如图2-2所示。
2.3 面向对象软件工程
在1981年后，随着面向对象的程序设计语言Smalltalk-80出现后，使得该技术得到很大的提升，而且随着技术的不断发展和成熟，此种方式产生了综合的工程学体系。而该工程学的主要发展方法就是面向对象进行软件开发[12]。
面向对象进行软件的开发是以一种全新的设计概念和系统程序进行设计和使用，该技术是根据对象、类、继承、封装和消息等最基本的概念及程序进行设计[13]。
该工程的主要思想是根据人们考虑事物的基本方法和惯用方式进行构造，软件系统能够将现实中所遇到的问题和实体之间进行联系，形成客观实体的真实对象。
在软件工程学的范畴内，对象、类、通信和继承共同构成面向对象[14].在计算机应用系统中，将应用软件实现面向对象的工程软件，其中包含对对象进行分析（OOA）、设计（OOD）、变成（OOI）、测试（OOT）和维护（OOSM）等。
3． 统一软件工程RUP
软件工程的三个要素[15]是工具、方法和过程。软件过程是指开发软件所需要完成的活动构成的框架。在每个活动期间，都要通过某些工具采用一些方法、技术构造工作产品（如计划、文档、模型、代码、测试用例和书册等）。
软件工程使用某些工具，采用某种方法，按照某种过程开发软件系统。如图3-1所示是工具、方法和过程在开发时的关系[16]。
工具层为软件过程和方法提供了自动或半自动的支持；方法层在技术上说明了需要如何去开发软件；软件过程提供一个活动框架，在这个框架下可以建立一个软件开发的综合计划[17]。
采用有效的软件过程是实现软件成功开发的前提。当前流行的软件过程有[18]：
（1）Rational Unified Process(RUP)
（2）OPEN Process
（3）Object-Oriented Software Process(OOSP)
（4）Extreme Programming(XP)
（5）Catalysis
（6）Dynamic System Development Method(DSDM)
其中，RUP（统一软件过程）既是一个软件过程，更是一个软件过程框架。它可以适合不同规模、各种类型的软件项目开发。在实际的应用过程中，可以根据自己的需要对这个标准进行裁剪。统一软件过程把UML建模语言有机地结合到一起，非常适合采用面向对象软件技术进行软件项目开发[19]。
统一软件过程有三个突出的特点：用例驱动、以架构为中心、采用迭代和增量模型。
（1）所有的软件开发都是用户需求驱动的。统一软件开发过程采用用例来描述用户需求，同时提供一套方法把用例转化为设计的类图，进一步变成最终的程序代码。在整个软件开发过程中，要求用例是可跟踪的，也就是说，无论是设计阶段还是实现阶段的产品，都可以找到相应的需求。用例还可以作为用户测试和验收最终软件产品的标准[20]。
（2）框架描述了系统的核心部分，它实现了用户的核心需求，包括了系统中最重要的静态和动态特征。架构刻画了系统的整体设计，它舍弃了细节部分，突出了系统的重要特征。统一软件过程提供了创建框架的相应方法和过程，可以帮助分析人员和设计人员很好地完成构架的设计[21]。
（3）统一软件过程采用迭代和增量的开发方式，把一个软件产品划分成多个较小的部分，每一次完成一个部分，每次要迭代部分是产品的一个增量部分。每个增量部分的生产过程是受控的[22]。
迭代过程的好处是：把一个复杂的系统分解成多个简单的系统；提高软件项目的可控性；降低软件开发的风险；有效地应对需求变更。
3.1 RUP简介和特点
传统的瀑布开发模型是一个一维的模型，开发过称被划分为多个连续的阶段[23]。
统一软件开发过程（Rational Unified Process，RUP）是一个程序开发方法，它以面向对象为主要手段，而且是基于网络的[24]。RUP可以指导所有层次和各个方面的程序开发，可以指定模板或模块。除了RUP之外，还有一些类似的方法，例如面向对象的软件过程，它是在软件开发中注重过程，定义开发的各个阶段、技术和实际成果，并结合其他开发组件，形成一个比较齐全的框架。
在RUP中，对软件开发模型中包括了软件生命周期和核心工作流，这些组成了一个二维的空间模型。如下图所示，它包括时间维，也就是横坐标，工作流用纵轴表示[25]。RUP开发模型如图3-2所示。
RUP有以下六个特点[26]：
（1）迭代式开发。在软件开发过程中，有个很难的过程，即在开发早期就收集到所有的用户需求。而在实际的开发过程中，用户的需求是不断发生变化的，并且有时变化的程度会很大。所谓的迭代式开发，就是在注重每次开发的当前需求，在用户的需求不断增加或变化时，开发也随之变化，并形成新的产品。这样做可以最大限度地降低项目风险，还可以使得项目开发处于一种阶段性成长模式。
（2）管理需求。确定系统的需求是一个连续的过程，开发人员在开发系统之前不可能完全详细地说明一个系统的真正需求。RUP描述了如何提取、组织系统的功能和约束条件并将其文档化，用例和脚本的使用已被证明是捕获功能性需求的有效方法。
（3）基于组件的体系结构。组件使重用成为可能，系统可以由组件组成。基于独立的、可替换的、模块化组件的体系结构有助于管理复杂性，提高重用率。RUP描述了如何设计一个有弹性的、能适应变化的、易于理解的、有助于重用的软件体系结构。
（4）可视化建模。可视化建模的目的是帮助人们更直观地理解系统，这可以使用RUP与UML结合来实现。通过这样的建模，可以将很复杂的系统变得简单易懂，并且也可以是基于组件或模块化地描述系统，方便对系统进行更深层次地分析。
（5）软件质量控制。在软件开发整个过程中，对质量的管理和控制是至关重要的，基于RUP的软件开发，可以很方便地做到这一点，基于模型的系统开发可以在关键点对系统的质量进行检测。
（6）控制软件变更。迭代式开发中如果没有严格的控制和协调，整个软件开发过程很快就陷入混乱之中，RUP描述了如何控制、跟踪、监控、修改以确保成功的迭代开 发。RUP通过软件开发过程中的制品，隔离来自其他工作空间的变更，以此为每个开发人员建立安全的工作空间。
3.2 RUP中的核心工作流
RUP中由核心工作流和核心支持工作流组成，其中核心工作流有六个，分别是商业建模、需求、分析和设计、实现、测试和部署。三个核心支持工作流是配置和变更管理、项目管理和环境。[27]
通过这九个工作流的配合，可以在软件生命周期中通过迭代的方式被复用，这类似与传统的瀑布模型的几个阶段，但是最根本的不同在于传统的模型对工作流的复用仅限于在一个开发循环中，而不是在某个工作流中。
（1）商业建模
它可以描述一个软件项目的开发构思，基于这个构思，可以对商业开发的初步设想加以实例化，用一种更加具体的方式表达出来，例如可以定义一些过程、角色或功能等。
（2）需求
需求描述了系统设想的功能，这里指的是抽象层次的功能，而不是具体的。通过需求工作流，可以使得系统最初设计者与开发者之间建立起共识，对系统的目标和约束进行定义并成果化，限定系统的范围。
（3）分析和设计
分析和设计是建立在对系统进行商业建模和需求建模基础之上的，对系统的各个细节进行具体的描述，并限定系统的环境、性能和优化策略。这里的设计并不是对源代码的设计，而是将系统的功能模块以包的形式给出，也有可能有子系统，整个系统的设计就是建立在这些功能包和子系统的支持下，描述系统的协作和实现用例。值得注意的是，可以通过分析和设计来描述系统的一些动作、状态和抽象的性能，使得系统的特点更加明显，便于对系统进行更深入的开发和优化。这里描述的系统结构式可以变化的，也方便对系统就行修改，加强系统的健壮性。
（4）实现
实现工作流可以是一种层次化系统或子系统描述，这种描述可以定义到代码的结构，也可以以组建的形式实现系统的功能模块及其实例。实现的目的不是运行系统，而是使得模块设计的结果更加可塑化，对组建可以进行测试和评价，系统可以在实现的工作中以动作描述的方式运行。
（5） 测试
测试工作流主要针对系统设计的协作而进行，具体来说是验证系统功能需求的实现，以及反馈结果是否满足需求的格式。在这一过程中，可以用迭代的方式对系统进行测试，这样使得更多的缺陷及早地暴露出来，这位系统开发降低了客观的成本。测试的方法有很多，最常用的是基于模型的测试，定性地判断系统的健壮性和可靠性。
（6）部署
当系统设计到测试阶段之后，可以将一个相对完整的系统进行发布和部署，这里面向的最终用户。部署工作流要实现的是根据最终用户的活动来调试系统的配置，保证系统按照用户的需求进行待运行，避免与最终客户的行为产生很大的反差。部署工作流还有一个重要的作用是帮助用户规范合理的工作方式，也就是使用系统的目的还在于完善工作质量。
（7）配置和变更管理
配置和变更管理的目的是让系统给最终用户带来更加可靠的性能，为此需要管理大量的系统运行环境数据和系统日志信息，这些信息可以帮助维护人员发现系统的问题，并在不断变化的系统实际用例中更加正确地指导用户使用系统。这其实是一种并行的管理方法，既不妨碍最终用户使用系统的正常功能，又能不断监视系统的运行状态。
（8）项目管理
项目管理工作流是针对项目开发人员和配合人员的，其主要目的是平衡系统参与人员的工作矛盾和时间安排。它强调从整体上统筹系统开发，为系统部署软件框架、人力框架和服务框架，并以一种高效的管理方式监控系统开发的各个阶段和模块。
（9）环境
环境工作流是一种辅助性的工作流，但往往又是最常用的工作流。它可以支持系统各个开发阶段和模块的工具、耗材、人力等，也可以调节项目的活动计划，在过程中不断对项目的推进产生必要的物质和精神上的支持。
3.3 RUP中的迭代模型
在RUP过程中，可以把每个阶段的任务分成多个部分，采用多次迭代完成每个阶段的任务。每一次完整的迭代包含9个工作流，迭代有可能只包含部分工作流。每一次迭代建立一个可执行的软件产品（版本），每次迭代产生的软件产品是最终产品的一个子集[28]。图3-3是RUP中某个阶段的迭代开发模型。
与传统的瀑布模型相比较，迭代开发的优点如下：
（1）由于把软件系统分成多个独立部分，采用增量开发，降低了开支的风险。
（2）由于是迭代开发，每次迭代产生出一个完整的软件产品，降低了产品无法按照既定进度进入市场的风险。
（3）由于采用迭代开发，多小组可以并行工作，加快了整个开发工作的进度。
3.4 RUP中的核心工作流
（1）需求工作流[29]
需求工作流开始前，首先要对业务建模，业务建模就是对业务组织、业务内容和业务流程进行建模。业务模型为需求工作打下基础。
需求捕获通过对业务内容进行描述、整理，确立业务实体及其关系；确定业务系统的功能要求；确定实现功能要求的实体间的交互关系。将用户需求精确化、完备化。大部分需求工作集中在初始和细化阶段，在细化阶段后期，需求捕获的工作量大幅下降。
①工作产品
执行需求捕获工作流时，软件开发人员开发的主要UML制品有：用例模型；软件体系构架描述，用包图（由用例构成的包）描述软件系统的宏观组织和结构；术语表；用户界面原型。
②软件开发人员
参与需求捕获阶段的软件开发人员有：系统分析人员；用例描述人员；用户界面设计人员；构架设计师。
③主要活动
需求捕获的工作流主要包括确定参与者和用例（概要描述）、区分用例的优先级、详细描述用例、构造用户界面原型以及构造用例模型5个活动。
A）确定参与者和用例。确定参与者和用例的目的是界定系统的范围，确定哪些参与者将与系统进行交互，以及他们将从系统中得到哪些服务（用例）；捕获和定义术语表中的公用术语，这些是对系统功能进行详细说明的基础，如图3-4所示。
图3-4 确定参与者用例
确定参与者和用例的过程通常包括4个步骤：确定参与者、确定用例、简要描述每个用例和概要描述用例模型。实际中，这些步骤通常是并发执行的。
B）区分用例的优先级。区分用例的优先级是为了决定用例模型中哪些用例需要在早期的迭代中进行开发（包括分析、设计、实现等），以及哪些用例可以在随后的迭代中进行开发。如图3-5所示。
图3-5 区分用例的优先级
C）详细描述用例。详细描述用例的主要目的是为了详细描述事件流。这个活动包括建立用例说明、确定用例说明中包括的内容和对用例说明进行描述的三个步骤，最终的结果以图或文字的用例的详细说明，如图3-6所示。
图3-6 详细描述用例
D）构造用户界面原型。在系统分析人员建立起用例模型，确定了谁是用户以及他们要用系统做什么后，接下来的工作就是要着手设计用户界面。这个活动由逻辑用户界面设计、实际用户界面设计和构造原型两部分组成，最终的结构是一个用户界面简图和用户界面原型，如图3-7所示。
图3-7 构造用户界面原型
E）构造用例模型。构造用例模型的主要目的是：整理用例间的关系，分离包含用例和扩展用例；补充用例说明。这个活动由确定共享的功能性说明、确定补充和可选功能说明，以及确定用例之间的其他关系三部分组成。在确定系统用例和参与者之后，系统分析人员可以重新整理用例之间的关系，使模型更易于理解和处理，如图3-8所示。
图3-8 构造用例模型
（2）分析工作流[30]
主要的分析任务从初始阶段的尾期开始，与需求一样，分析工作流主要集中在细化阶段，细化阶段的大部分活动是捕获需求，并进行需求分析，分析工作与需求捕获在很大程度上重叠。
①工作产品
在分析工作流期间，主要的UML制品有：分析模型；分析类，对业务模型中的类图或对象图中的类进行加工处理后的类；用例实现，实现用例的顺序图，即由哪些对象相互协作来完成用例的功能；分析包，分析阶段用包来描述未来的系统组成和结构；构架模型，通过包图来描述软件体系。
②软件开发人员
在分析工作流期间，参与的软件开发人员有架构设计师、用例工程师和构件工程师。
③主要活动
分析工作流主要包括架构分析、分析用例、分析类和分析包四个活动。
A）架构分析。架构分析的目的是通过分析包、分析类，并结合系统约束和特殊需求，以包的格式表示系统架构，以文本格式描述构架，如图3-9所示。
图3-9 架构分析
B）分析用例。分析用例的目的在于找到实现用例的对象，通过对象间的协作实现用例的功能；用例实现用协作图来描述，具体的输入和结构如图3-10所示。
图3-10 分析用例
C）分析类。分析类的目的在于依据分析类在用例实现中的角色来确定它的职责，确定分析类的属性及其关系。具体的输入和结果如图3-11所示。
图3-11 分析类
D）分析包。分析包的目的在于确保该分析包的合理性和相对独立性，确保该分析包包含完整的用例。一般说来，分析包的活动是：定义和维护包与其他包的依赖，确保包中包含恰当的类，然后限制对其他包的依赖。具体的输入和结果如图3-12所示。
图3-12 分析包
4． 统一建模语言UML
统一建模语言（Unified Modelling Language, UML）是用来对软件密集系统进行可视化建模的一种语言。是为面向对象开发系统的产品进行说明、可视化和文档编制的一种标准语言。
4.1 UML的定义
作为一种建模语言，UML是一个标准的图形化建模语言，由一系列图形符号组成，并具有特定的含义。它包括UML语义和UML表示方法两部分。
UML语义：描述了基于UML的精确元模型定义。为了使得描述UML各类组合的准确意义，定义了UML的元模型，即所有的用UML语言描述的模型都是基于这些元模型基础之上的，使得这类语言简单、一致和通用。
UML表示方法：定义了UML图形符号的表示方法，为系统建模提供了标准的使用规则，建立在UML元模型的基础之上，使用特定的表示方法代表特定的描述语义。
4.2 UML的主要特点
从整体来看，统一建模语言UML有三个主要的特点：
（1） UML是建在一些之前先进的软件设计方法基础之上的，包含了诸如Booch等方法的思想。
（2）面向对象的开发方法和非面向对象的开发方法都是软件开发过程中必不可少的方法，这些在UML中都有体现。
根据面向对象开发方法发展起来的UML表示方法，使用了大量的图形化的描述方式。作为一种软件设计语言，UML可以直观地进行系统描述甚至是行为描述。在使用的符号，都是经过精心筛选出那些在软件系统开发中最常用，也是最具有代表性的描述方式，也包括一些重新定义的符号，适用于特殊的系统描述。
（3）新的方法在不断发展的UML中层出不穷
在UML发展的过程中，由于新的开发思想和方法的出现，需要对UML定义的描述方法进行不断更新，在这个过程中，新加入了诸如模板、过程、并发、细化等概念和方法的提出，并给出了相应的描述符号的定义。UML是不断发展的语言，因此，UML可以随着软件工程的发展不断推陈出新。
UML虽然是非常实用并且是不断发展的语言，但是在目前定义的UML描述方法中，仍然有一些方法有待人们在实践中去验证。
4.3 UML的体系结构
UML是一种建立在公共机制上的程序设计语言，构造元素、规则和公共机制构成了UML体系。其中构造元素是描述事物和行为的基本元素，而规则是约束这些基本元素组合方式的约束，它们一起构成各种各样的UML图。
UML语言的组成结构，如图4-1所示。
（1）构造元素
构造元素包括基本元素、关系和图。这三种元素代表了软件系统或业务系统中的某个事物或事物间的关系。
（2）规则
构造元素具有命名、范围、可见性、完整性和执行等属性，规则是对软件系统或业务系统中某些事物的约束或规定。
（3）公共机制
公共机制包括详述、修饰、通用划分以及扩展机制，它是指只用于软件系统或业务系统中每个事物的方法或规则。
4.4 UML的建模机制
使用UML语言进行建模，需要几种图的配合才能构建比较完整的UML模型，这些图分别是：
（1）类图
类图（Class Diagram）是最常用的UML图，它可以显示出类、接口以及它们之间的静态结构和关系，通常用来描述系统的结构。类图中的关系包括依赖关系（Dependency）、泛化关系（Generalization）、关联关系（Association）和实现关系（Realization）。类图常用来描述业务或软件系统的组成、结构和关系。可通过为系统词汇建模型、模型化简单的协作和模型化一个逻辑数据库模式来使用类图。类图中的元素有类、接口、协作、关系、注释、约束和包。关系把类、协作、接口连接在一起构成一个图，注释的作用是对某些类和接口进行注释，约束的作用是对某些类的接口进行约束。
（2）对象图
对象图（Object Diagram）显示了一组对象和它们之间的关系。使用对象图可以说明数据结构、类图中的类或组件等实例的快照。对象图和类图一样，反映了系统的静态过程，但它是以实际的或原型化为基础来表达对象间的关系。对象图显示某时刻对象和对象之间的关系。一个对象图可看成一个类图的特殊实例，实例和类可在对象图中同时表示。
对象图是类图的一个实例，这个实例是在某一时刻才会出现的，在这一点上，对象图与类图十分相似。但是也有不同之处，对象图中的类是被实例化的，可以由多个对象同时出现，而类图中则没有对象，只是表示出对象的抽象层次。对象是类在某个时刻才会被实例化的，因此，对象图在系统中出现的时间也是有局限的。
（3）用例图
用例图是外部参与者所能观察到的系统功能的模型图。呈现了一些参与者和一些用例，以及它们之间的关系，主要用于对系统、子系统或类的功能行为进行建模。
用例图展示了用例之间以及用例与参与者之间是怎样相互联系的。对系统、子系统或类的行为进行了可视化，使用户能够理解如何使用这些元素，并使开发者能够实现这些元素。用例图主要用来描述用户的功能需求。UML侧重从最终用户的角度来理解软件系统的需求，强调谁在使用系统及系统可以完成哪些功能。用例分析技术是一种公认有效的用户需求获取、分析和描述技术。用例图描述了用例、参与者及其关系，可以包括注释、约束。
（4）交互图
在描述系统中，对象之间通过消息进行通信的图就是交互图，包括四种类型，分别是顺序图、通信图、定时图和交互概观图。
顺序图也成时序图，它描述了系统中对象间通过消息进行的交互，强调了消息在时间轴上的先后顺序。表明了由哪些对象通过消息相互协作来实现用例的功能，标识消息发生交互的先后顺序。顺序图中的元素包括对象、生命线、控制焦点和消息。消息表示了对象间的通信，生命线表示了对象的生存期，控制焦点表示对象正在执行一些活动。
通信图显示了一系列对象和这些对象之间的联系，以及对象间发送和接收的消息。对象通常是命名或匿名的类的实例，也可以代表其他事物的实例，如协作、组件和节点。使用通信图可以说明系统的动态情况，强调对象在交互行为中承担的角色。包括对象、消息和链。消息表示了对象之间的通信，对象通过链连接在一起。
定时图是一种特殊的顺序图，在UML2.0中，引入了一种新的交互图来解决着重表示定时约束的问题。如果要表示的交互具有很强的时间特性，例如实时控制系统中，最好用定时图建模。
（5）活动图
活动图是描述系统或业务的一系列活动构成的控制流，它描述了系统从一种活动转换到另一种活动的整个过程，说明了系统的活动控制流程，常用于对业务过程、工作流和用例实现进行建模。活动图的元素包括节点、终点、活动共节点、转换、分支与监护条件、分岔与汇合。其中，转换、分支、分岔与汇合把多个活动节点连接在一起。
5． 参考文献
[1] Farida K, Meslati D, Tamzalit D. An approach based on extending the RUP for dealing with anticipated changes in ontogenetic software systems[J]. International Journal of Computer Applications in Technology, 2015, 51(4).
[2] Estañol M, Queralt A, Sancho M R, et al. Specifying Artifact-Centric Business Process Models in UML[M] Business Modeling and Software Design - 4th International Symposium, BMSD 2014, Luxembourg, Luxembourg, June 24-26, 2014, Revised Selected Papers. 2015:62-81.
[3] 杜云梅,李师贤. RUP估算过程模型[J]. 计算机科学,2013,06:21-28.
[4] Evans A, Lano K, France R, et al. Meta-Modeling Semantics of UML[J]. Computer Science, 2014.
[5] 李传煌,王伟明,施银燕. 一种UML软件架构性能预测方法及其自动化研究[J]. 软件学报,2013,07:1512-1528.
[6] 柴玉梅,冯秋燕,王黎明. 基于UML模型和OCL约束的类间交互测试用例生成方法研究[J]. 电子学报,2013,06:1242-1248.
[7] Evans A, France R, Lano K, et al. Developing the UML as a Formal Modelling Notation[J]. Computer Science, 2014, 19(98):297--307.
[8] 余久久. 面向教学软件的RUP改进模型的设计研究[J]. 电化教育研究,2012,04:76-81+84.
[9] 王宇华,印桂生. 基于本体的需求模型到UML模型转换方法[J]. 哈尔滨工程大学学报,2012,06:735-740.
[10] 徐亮,张莉,樊志强. 一种基于UML的实时工作流建模方法研究[J]. 计算机研究与发展,2010,07:1184-1191.
[11] 韩德帅,杨启亮,邢建春. 一种软件自适应UML建模及其形式化验证方法[J]. 软件学报,2015,04:730-746.
[12] Evans A, France R, Lano K, et al. Meta-Modelling Semantics of UML[M] Behavioral Specifications of Businesses and Systems. Springer US, 2014:45-60.
[13] 何耀光,康汶,詹先信,温筱群. 基于UML的电子商务在线销售系统分析与设计[J]. 计算机与现代化,2011,02:171-174.
[14] Rumpe B. A Note on Semantics (with an Emphasis on UML)[J]. Eprint Arxiv, 2014(3):187-190.
[15] 殷永峰,郑本焘,陆民燕,倪红英. 基于UML实时扩展的嵌入式软件测试用例生成技术[J]. 系统工程与电子技术,2011,03:694-699.
[16] Broy M, Crane M L, Dingel J, et al. 2, nd, UML 2 Semantics Symposium: Formal Semantics for UML[C] International Conference on MODELS in Software Engineering. Springer-Verlag, 2014:318--323.
[17] 张琛,段振华,田聪. 基于事件确定有限自动机的UML2.0序列图描述与验证[J]. 软件学报,2011,11:2625-2638.
[18] 郭婧,吴军华. 面向方面的UML建模[J]. 计算机工程与设计,2011,12:4260-4264.
[19] 布宁,刘玉岭,连一峰,黄亮. 一种基于UML的网络安全体系建模分析方法[J]. 计算机研究与发展,2014,07:1578-1593.
[20] 文媛媛. 基于RUP过程和Web的四川职业技术学院固定资产管理系统设计[D].电子科技大学,2012.
[21] 邓容. RUP方法在新浪微博测试管理中的应用和实践[D].兰州大学,2012.
[22] 侯秀美. 基于UML的电子商务系统建模及应用研究[D].南昌大学,2012.
[23] Ahmad G, Soomro T R, Brohi M N. XSR: Novel Hybrid Software Development Model (Integrating XP, Scrum & RUP)[J]. 2014, 4:126-130.
[24] 张琛. 基于UML2.0模型的测试与验证方法[D].西安电子科技大学,2012.
[25] Akhunzada A, Gani A, Hussain S, et al. Towards experiencing the pair programming as a practice of the Rational Unified Process (RUP)[C] Sai Intelligent Systems Conference. IEEE, 2015.
[26] 佀腾飞. 基于RUP的轻量级软件过程实践[D].北京交通大学,2013.
[27] Cabot J, Clarisó R, Riera D. On the verification of UML/OCL class diagrams using constraint programming[J]. Journal of Systems & Software, 2014, 93:1-23.
[28] 李严. 使用UML和RUP构建面向对象的网络订票模型[D].吉林大学,2013.
[29] 贾婷婷. RUP方法在电子政务系统中的研究与应用[D].北京邮电大学,2013.
[30] 竺晓梅. 基于RUP的软件测试质量管理的研究与实现[D].复旦大学,2013.