第二章需求分析课件.ppt

1、 需求分析的目的与意义 需求分析的步骤需求分析的目的与意义需求分析需求分析是一个非常重要的过程，它完成的好坏直接影响后续软件开发的质量。一般情况下，用户并不熟悉计算机的相关知识，而软件开发人员对相关的业务领域也不甚了解，用户与开发人员之间对同一问题理解的差异和习惯用语的不同往往会为需求分析带来很大的困难。因此，开发人员和用户之间充分和有效的沟通在需求分析的过程中至关重要。需求分析的目的与意义有效的需求分析需求分析通常都具有一定的难度，一方面是因为交流存在障碍，另一方面是因为用户通常对需求的陈述不完备、不准确和不全面，并且还可能不断地变化。开发人员不仅需要在用户的帮助下抽象现有的需求，还开发人员

2、不仅需要在用户的帮助下抽象现有的需求，还需要挖掘隐藏的需求。需要挖掘隐藏的需求。此外，把各项需求抽象为目标系统的高层逻辑模型对日后的开发工作也至关重要。合理的高层逻辑模型是系统设计的前提。需求分析的目的与意义在进行需求分析需求分析的过程中，首先要明确需求分析应该是一个迭代的过程。由于市场环境的易变性以及用户本身对于需求描述的模糊性，需求往往很难做到一步到位。需求分析需求分析不仅仅是属于软件开发生命周期早期的一项工作，而且还应该贯穿于整个生命周期中，它应该随着项目的深入而不断地变化。需求分析的步骤需求分析的步骤 需求包括系统要做什么，相对于原系统目标系统需要进行哪些修改，目标用户有哪些，以及不同

3、用户需要通过系统完成何种操作等。需求包括用户对于系统执行速度、响应时间、吞吐量和并发度等指标的要求。需求包括目标系统对于网络设置、硬件设备、温度和湿度等周围环境的要求，以及对操作系统、数据库和浏览器等软件配置的要求。需求涉及数据的输入/输出格式的限制及方式、数据的存储介质和显示器的分辨率要求等问题。需求分析的步骤1.获取需求，识别问题获取需求，识别问题开发人员从功能、性能、界面和运行环境等多个方面识别目标系统要解决哪些问题，要满足哪些限制条件，这个过程就是对需求的获取。开发人员通过调查研究，要理解当前系统的工作模型和此外，在需求的获取时，还要明确用户对系统的安全性、可移安全性、可移植性和容错能

4、力植性和容错能力等其他要求。需求分析的步骤需求获取方法 问卷调查 访谈实地操作建立原型研究资料编号提出问题1您在您在哪个部门工作？哪个部门工作？2出版业务流程是什么？出版业务流程是什么？3您您每日都处理那些文件、数据、报表？每日都处理那些文件、数据、报表？4工作中手工处理特别麻烦的事情是什么？工作中手工处理特别麻烦的事情是什么？5工作中手工处理什么问题解决不了？影响效率的问题工作中手工处理什么问题解决不了？影响效率的问题有哪些？有哪些？6您认为提高工作效率，节省工作时间，减轻工作强度您认为提高工作效率，节省工作时间，减轻工作强度可采取哪些办法？可采取哪些办法？某出版社系统调查表某出版社系统调查

5、表编号提出问题7您的部门需要成本核算和统计的内容有哪些？您的部门需要成本核算和统计的内容有哪些？8您的部门采用计算机管理工作情况如何？您的部门采用计算机管理工作情况如何？9如何改进业务流程使之更合理？如何改进业务流程使之更合理？10哪些问题是目前传统手工方法根本无法解决的？哪些问题是目前传统手工方法根本无法解决的？11出版社计算机管理信息系统需要解决什么问题？某出版社系统调查表某出版社系统调查表需求获取面临的问题需求获取面临的问题需求分析的步骤2.分析需求，建立目标系统的逻辑模型分析需求，建立目标系统的逻辑模型常用的模型图有数据流图、数据流图、E-R图、用例图和状态转换图图、用例图和状态转换图

6、等，不同的模型从不同的角度或不同的侧重点描述目标系统。绘制模型图的过程，既是开发人员进行逻辑思考的过程，也是开发人员更进一步认识目标系统的过程。需求分析的步骤3.将需求文档化将需求文档化获得需求后要将其描述出来，即将需求文档化。对于大型的软件系统，需求阶段一般会输出三个文档：用户需求报告 系统需求规格说明书 软件需求规格说明书需求分析的步骤对于简单的软件系统而言，需求阶段只需要输出软件需求文档就可以了。软件需求规格说明书主要描述软件的需求，从开发人员的角度对目标系统的业务模型、功能模型和数据模型等内容进行描述。作为后续的软件设计和测试的重要依据，需求阶段的输出文档应该具有清晰性、无二义性和准确

7、性，并且能够全面和确切地描述用户需求。1 引言引言 1.1 编写目的编写目的 说明编写这份软件需求说明书的目的，指出预期的读者。说明编写这份软件需求说明书的目的，指出预期的读者。1.2 背景背景 说明：说明：a 待开发的软件系统的名称；待开发的软件系统的名称；b 本项目的任务提出者、开发者、用户；本项目的任务提出者、开发者、用户；c该软件系统同其他系统或其他机构的关系。该软件系统同其他系统或其他机构的关系。1.3 定义定义 列出本文件中用到的专门术语的定义。列出本文件中用到的专门术语的定义。1.4 参考资料参考资料 需求说明书的编写提示需求说明书的编写提示2 任务概述任务概述 2.1 目标目标

8、 叙述该项软件开发的意图、应用目标、作用范围以及叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。如果所其他应向读者说明的有关该软件开发的背景材料。如果所定义的产品是一个更大的系统的一个组成部分，可使用一定义的产品是一个更大的系统的一个组成部分，可使用一张方框图来说明该系统的组成和本产品同其他各部分的联张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。系和接口。|2.2 用户的特点用户的特点 列出本软件的最终用户的特点，充分说明操作人员、列出本软件的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长，以及本软件的预期使用维护人员的教

9、育水平和技术专长，以及本软件的预期使用频度。这些是软件设计工作的重要约束频度。这些是软件设计工作的重要约束。2.3 假定和约束假定和约束 需求说明书的编写提示需求说明书的编写提示3 需求规定需求规定 3.1 对功能的规定对功能的规定 用列表的方式（例如用列表的方式（例如IPO表），逐项叙述对软件所表），逐项叙述对软件所提出的功能要求。提出的功能要求。3.2 对性能的规定对性能的规定 3.2.1 精度精度 说明对该软件的输入、输出数据精度的要求，可能包括说明对该软件的输入、输出数据精度的要求，可能包括传输过程中的精度。传输过程中的精度。3.2.2 时间特性要求时间特性要求 说明对于该软件的时间特

10、性要求，如对：说明对于该软件的时间特性要求，如对：a 响应时间；响应时间；需求说明书的编写提示需求说明书的编写提示b 更新处理时间；更新处理时间；c 数据的转换和传送时间；数据的转换和传送时间；3.2.3 灵活性灵活性 说明对该软件的灵活性的要求，即当需求发生某些变化时，该软件对说明对该软件的灵活性的要求，即当需求发生某些变化时，该软件对这些变化的适应能力，如：这些变化的适应能力，如：a 操作方式上的变化；操作方式上的变化；b 运行环境的变化；运行环境的变化；c 同其他软件的接口的变化；同其他软件的接口的变化；d 精度的变化；精度的变化；对于为了提供这些灵活性而进行的专门设计的部分应该加以标明

11、。对于为了提供这些灵活性而进行的专门设计的部分应该加以标明。3.3 输人输出要求输人输出要求 解释各输入输出数据类型，并逐项说明其媒体、格式、数值范围、精解释各输入输出数据类型，并逐项说明其媒体、格式、数值范围、精度等。度等。需求说明书的编写提示需求说明书的编写提示3.4 数据管理能力要求数据管理能力要求 说明需要管理的文件和记录的个数、表和文件的大小说明需要管理的文件和记录的个数、表和文件的大小规模，要按可预见的增长对数据及其分量的存储要求作规模，要按可预见的增长对数据及其分量的存储要求作出估算。出估算。3.5 故障处理要求故障处理要求 列出可能的软件、硬件故障以及对各项性能而言所产列出可能

12、的软件、硬件故障以及对各项性能而言所产生的后果和对故障处理的要求。生的后果和对故障处理的要求。3.6 其他专门要求其他专门要求 如用户单位对安全保密的要求，对使用方便的要求，如用户单位对安全保密的要求，对使用方便的要求，对可维护性、可补充性、易读性、可靠性、运行环境可对可维护性、可补充性、易读性、可靠性、运行环境可转换性的特殊要求等。转换性的特殊要求等。需求说明书的编写提示需求说明书的编写提示4 运行环境规定运行环境规定 4.1 设备设备 列出运行该软件所需要的硬设备。说明其中的新型设备及其列出运行该软件所需要的硬设备。说明其中的新型设备及其专门功能，包括：专门功能，包括：a处理器型号及内存容

13、量；处理器型号及内存容量；b外存容量、输入及输出设备的型号和数量，联机或脱机；外存容量、输入及输出设备的型号和数量，联机或脱机；d数据通信设备的型号和数量；数据通信设备的型号和数量；e其他专用硬件其他专用硬件 4.2 支持软件支持软件 包括要用到的操作系统、编译（或汇编）程序、测试支持软包括要用到的操作系统、编译（或汇编）程序、测试支持软件等。件等。需求说明书的编写提示需求说明书的编写提示4.3 接口接口 说明该软件同其他软件之间的接口、数据通信协议等。说明该软件同其他软件之间的接口、数据通信协议等。4.4 控制控制 说明控制该软件的运行的方法和控制信号，并说明这些控说明控制该软件的运行的方法

14、和控制信号，并说明这些控制信号的来源。制信号的来源。需求说明书的编写提示需求说明书的编写提示需求分析的步骤4.需求验证需求验证需求验证是对需求分析的成果进行评估和验证的过程。为了确保需求分析的现实性、一致性、完整现实性、一致性、完整性和有效性性和有效性，提高软件开发的效率，为后续的软件开发做好准备，需求验证的工作非常必要。在需求验证的过程中，可以对需求阶段的输出文档进行多种检查，比如，一致性检查、完整性检查和有效性检查等。同时，需求评审也是在这个阶段进行的。面向对象需求分析方法面向对象面向对象的需求分析需求分析基于面向对象的思想，以用以用例模型为基础例模型为基础。开发人员在获取需求的基础上，建

15、立目标系统的用例模型。所谓用例用例是指系统中的一个功能单元，可以描述为操作者与系统之间的一次交互。用例常被用来收集用户的需求。面向对象需求分析方法首先要找到系统的使用者使用者，即用例的操作者。操作者是在系统之外，透过系统边界与系统进行有意义交互的任何事物。“在系统之外在系统之外”是指操作者本身并不是系统的组成部分，而是与系统进行交互的外界事物。这种交互应该是“有意义”的交互，即操作者向系统发出请求后，系统要给出相应的回应。而且，操作者并不限于人，也可以是时间、温度操作者并不限于人，也可以是时间、温度和其他系统等和其他系统等。面向对象需求分析方法比如，目标系统需要每隔一段时间就进行一次系统更新，

16、那么时间时间就是操作者。可以把操作者执行的每一个系统功能都看作一个用例可以把操作者执行的每一个系统功能都看作一个用例。可以说，用例描述了系统的功能，涉及系统为了实现一个功能目标而关联的操作者、对象和行为。识别用例时，要注意用例是由系统执行的用例是由系统执行的，并且用例的结果是操作者可以观测到的。用例是站在用户的角度对系统用例是站在用户的角度对系统进行的描述进行的描述，所以描述用例要尽量使用业务语言而不是技术语言。面向对象需求分析方法下图所示为某图书馆信息管理系统的用例图。面向对象需求分析方法确定了系统的所有用例之后，就可以开始识别目标系统中的对象对象和类类了。把具有相似属性和操作的对象定义为一

17、个类类。属性定义对象对象的静态特征，一个对象对象往往包含很多属性。面向对象需求分析方法比如，读者的属性可能有姓名、年龄、年级、性别、学号、身份证号、籍贯、民族和血型等。目标系统不可能关注对象的所有属性，而只是考虑与业务相关的属性。比如，在“图书馆信息管理”系统中，可能就不会考虑读者的民族和血型等属性。操作定义了对象的行为，并以某种方式修改对象的属性值。面向对象需求分析方法目标系统类可以划分为边界类边界类、控制类控制类和实体类实体类 代表了系统及其操作者的边界，描述操作者与系统之间的交互。它更加关注系统的职责，而不是实现职责的具体细节。通常，界面控制类、系统和设备接口类都属于边界类。代表了系统的

18、逻辑控制，描述一个用例所具有的事件流的控制行为，实现对用例行为的封装。通常，可以为每个用例定义一个控制类。描述了系统中必须存储的信息及相关的行为，通常对应于现实世界中的事物。面向对象需求分析方法确定系统的类和对象后，分析类之间的关系对象或类之间的关系“非结构化”的和短暂的关系，表明某个对象会影响另外一个对象的行为或服务“结构化”的关系，描述对象之间的连接。特殊的关联关系，它们强调整体和部分之间的从属性，组合是聚合的一种形式，组合关系对应的整体和部分具有很强的归属关系和一致的生存期。比如，计算机计算机和显示器显示器就属于聚合聚合关系。与类间的继承类似。针对类与接口的关系。面向对象需求分析方法明确

19、了对象、类和类之间的层次关系之后，需要进一步识别出对象之间的动态交互行为，即系统响应外部事件或操作的工作过程。一般采用顺序图将用例和分析的对象联系在一起，描述用例的行为是如何在对象之间分布的。面向对象需求分析方法最后，需要将需求分析的结果用多种模型图表示出来，并对其进行评审。由于分析的过程是一个循序渐进的过程，合理的分析模型需要多次迭代才能得到。面向对象需求分析的示意图如图所示。类图和对象图 用例图 顺序图 状态图 活动图 通信图 交互概况图 时序图 组件图 部署图 包图UML简介UML（Unified Modeling Language），即统一建模统一建模语言语言，是一种标准的图形化建模语

20、言。它主要用于软件的分析与设计，用定义完善的符号来图形化地展现一个软件系统。UML的使用可以贯穿于软件开发周期的每一个阶段，适用于数据建模、业务建模、对象建模和组件建模。作为一种建模语言，UML并不涉及编程的问题，即与语言平台无关，这就使开发人员可以专注于建立软件系统的模型和结构。UML简介UML 2.0支持13种图，有6种结构图和7种行为图。结构图结构图（静态模型图静态模型图）类图类图组织结构图组织结构图组件图组件图部署图部署图对象图对象图包图包图行为图行为图（动态模型图动态模型图）活动图活动图交互图交互图顺序图顺序图通信图通信图交互概况图交互概况图时序图时序图用例图用例图状态机图状态机图类

21、图类图类图使用类和对象描述系统的结构，展示了系统中类的静态结构，即类与类之间的相互关系。类之间有多种联系方式，如关联关联（相互连接）、依赖依赖（一个类依赖于或使用另一个类）、泛化泛化（一个类是另一个类的特殊情况）。一个系统有多幅类图，一个类也可以出现在几幅类图中。类图类与类之间的关系有关联关联、依赖依赖、泛化泛化和实现实现等。1）关联（Association）表达模型元素间的一种语义关系，对具有共同的结构特性、行为特性、关系和语义的链的描述。UML中使用一条直线表示关联关系，直线两端上的数字表示重数。比如一个学生可以同时借阅多本书，但一本书只能同时被一个学生借阅，关系是一对多；而一个图书管理员

22、可以管理多本图书，一本图书也可以被多个管理员管理，关系是多对多。类图受限关联受限关联用于一对多或多对多的关联。如果关联时需要从多重数的端中指定一个对象来限定，可以通过使用限定符来指定特定对象。比如，一个学生可以借多本书，但这多本书可以根据书的书号不同而区分，这样就可以通过限定符“书号”来限定这些图书中的某一本图书。如下图所示。类图聚集和组合聚集和组合表示整体-部分的关联，有时也称之为“复合”关系。聚集的部分对象可以是任意整体对象的一部分。比如，“目录”与该目录下的“文件”，班级与该班级的学生等。组合则是一种更强的关联关系，代表整体的组合对象拥有其子对象，具有很强的“物主”身份，具有管理其部分对

23、象的特有责任，比如“窗口”与窗口中的“菜单”。类图聚集关联使用空心菱形表示，菱形位于代表整体的对象一端；组合关联与聚集关联表示方式相似，但使用实心菱形。聚集和组合的关联关系见下图。聚集关联聚集关联组合关联组合关联类图重数重数是关联关系中的一个重要概念，表示关联链的条数。比如下图中，链的两端的数字“1”和符号“*”表示的就是重数。重数可以一个任意的自然数集合，但实际使用中，大于1的重数常常用“*”号代替。所以实际使用的重数多为0、1和符号“*”。一对一关联的两端重数都是1；一对多关联的一端重数是1，另一端是“*”；多对多关联的两端重数都是0n，常表示为“*”。类图2）依赖依赖指出两个或多个模型元

24、素之间的语义上的关系，被依赖元素的改变会导致依赖元素的改变。依赖关系常用带箭头的虚线表示，箭头指向依赖对象。对对 象象类图在UML2.0中的依赖关系参见下表。类图3）泛化泛化关系描述类的一般-特殊关系，是更一般描述与更特殊描述之间的一种分类学关系，特殊描述常常是建立在一般描述基础上的。比如会员是VIP会员的一般描述，VIP会员就是会员的泛化，会员是一般类，VIP会员是特殊类；学生是本科生的一般描述，本科生就是学生的泛化，学生是一般类，本科生是特殊类。特殊类是一般类的子类，而特殊类还可以是另一个特殊类的子类。比如，本科一年学生就是本科生的更特殊化描述，是后者的泛化。泛化的这种特点构成泛化的分层结

25、构。类图比如，三角形、四边形、六边形都属于多边形，而四边形中又包含矩形，它们的关系如下图所示。类图4）实现实现关系将一个模型连接到另一个模型，通常情况下，后者是行为的规约（如接口），前者要求必须至少支持后者的所有操作。如果前者是类，后者是接口，则该类是后者的实现。类图实现与泛化很相似，区别是泛化是针对同层级元素之间的连接，而实现是针对不同语义层上的元素的连接。如子类与父类关系是泛化，类与接口关系是实现。比如，定义“图形”接口，类“圆”则是该接口的实现，如下图所示。用例图用例图用例图是从用户的角度描述系统的功能，由用例（User Case）、操作者（Actor）以及它们的关系连线组成。用例用例是

26、从用户角度描述系统的行为，它将系统的一个功能描述成一系列的事件，这些事件最终对操作者产生有价值的观测结果。操作者是与系统交互的外部实体，可能是使用者，也可能是与系统交互的外部系统、基础设备等。用例图在UML中，操作者使用人形符号表示，并且具有唯一的名称；用例使用椭圆表示，也具有唯一的名称。操作者和用例之间使用带箭头的实线连接，由操作者指向用例。用例2用例1操作者用例3用例图正确识别系统的操作者尤为重要，以图书管理系统中学生借书事务为例，学生将书带到总借还台，由图书管理员录入图书信息，完成学生的借书事务。这个使用场景中，图书管理员是操作者，而学生不是，因为借书事务本身是由图书管理员来完成，而不是

27、学生本身。但如果学生可以自助借书，或者可以在网上借书，那么学生也将是操作者，因为这两种场景中学生直接与图书管理系统进行了交互。用例图在分析系统的操作者时，除了考虑操作者是否与系统交互之外，还要考虑操作者是否在系统的边界之外，只有在系统边界之外的操作者才能称为操作者，否则只能是系统的一部分。初学者常常把系统中的数据库识别为系统的操作者，对于多数系统来说，数据库是用来存储系统数据的，是系统的一部分，不应该被识别为操作者。用例图可能的例外是，一些遗留系统的数据库存储着新系统需要导入或者处理的历史数据，或者系统产生的数据导出到外部数据库中以供其它系统使用，这时的数据库应该视为系统的参与者。在分析用例名

28、称是否合适之时，一个简单有效的方法是将操作者和其用例连在一起读，看是否构成一个完整场景或句子。比如“游客浏览图书”，“游客登录注册”，都是一个完整的场景。而“游客图书”就不是一个完整场景或句子。用例图操作者之间可以存在泛化关系，类似的参与者可以组成一个层级结构。在网上书店的例子中，会员是游客的泛化，游客有浏览图书的用例，而会员不仅包含游客的全部用例，还具有自己特有的购买图书用例，参见下图。浏览图书会员购书游客登录注册按类别浏览图书按年份浏览图书查询图书用例图用例之间的关系有“包含”（include）“扩展”（extend）“泛化”（generalization）用例间连线“包含”关系使用带箭头

29、的虚线表示，虚线上标有“”，方向由包含用例指向被包含用例扩展关系也使用带箭头的虚线表示，虚线上标有“”，方向由扩展用例指向被扩展用例“泛化”关系使用带三角形箭头的实线表示，方向由子用例指向父用例用例图 如果系统用例较多，不同的用例之间存在共同行为，可以将这些共同行为提取出来，单独组成一个用例。当其他用例使用这个用例之时，它们就构成了包含关系。在用例的执行过程中，可能出现一些异常行为，也可能会在不同的分支行为中选择执行，这时可将异常行为与可选分支抽象成一个单独的扩展用例，这样扩展用例与主用例之间就构成了扩展关系。一个用例常常有多个扩展用例。用例之间的泛化关系描述用例的一般与特殊关系，不同的子用例

30、代表了父用例的不同实现。本章实践部分详细介绍使用Rose绘制网上书店系统的用例模型。顺序图顺序图顺序图描述了一组对象的交互方式，它表示完成某项行为的对象和这些对象之间传递消息的时间顺序。顺序图顺序图由对象（参与者的实例也是对象）、生命线、控制焦点、消息等组成。生命线是一条垂直的虚线，表示对象的存在时间；控制焦点是一个细长的矩形，表示对象执行一个操作所经历的时间段；消息是作用于控制焦点上的一条水平带箭头的实现，表示消息的传递。顺序图一般使用顺序图描述用例的事件流，标识参与这个用例的对象，并以服务的形式将用例的行为分配到对象上。通过对用例进行顺序图建模，可以细化用例的流程，以便发现更多的对象和服务

31、。顺序图可以结合以下步骤进行绘制 列出动该用例的操作者 列出启动用例时操作者使用的边界对象 列出管理该用例的控制对象 根据用例描述的所有流程，按时间顺序列出分析对象之间进行消息传递的序列顺序图绘制顺序图需要注意以下问题：如果用例的事件流包含基本流和若干备选流，则应当对基本流和备选流分别绘制顺序图如果备选流比较简单，可以合并到基本流中如果事件流比较复杂，可以在时间方向上将其分成多个顺序图实体对象一般不会访问边界对象和控制对象顺序图以图书管理系统的“登记借书”用例为例，基本流的顺序图如下图所示。状态图状态图状态图由状态机扩展而来，用来描述对象对外部对象响应的历史状态序列，即描述对象所有可能的状态，

32、以及哪些事件将导致状态的改变。包括对象在各个不同状态间的跳转以及这些跳转的外部触发事件，即从状态到状态的控制流。状态图侧重于描述某个对象的动态行为，是对象的生命周期模型。状态图状态图的组成元素包括状态、事件、转换、活动和动作。在UML中，状态用圆角矩形表示，一个转换由连接两个状态的箭头表示。状态图可以进行嵌套。（1）状态是指在对象生命周期中的一个条件或状况，对象在此期间将满足某些条件、执行某些活动或者进行某些等待。状态有状态名、进入/退出动作、内部转移、约束和延迟事件等组成。（2）事件是对触发状态转换的事情的描述。状态图（3）转换是指两个状态之间的转换，描述对象在第一个状态中执行一定动作，并在

33、满足特定条件或发生特定事件后进入第二个状态。（4）活动是状态机中进行的非原子执行单元。（5）动作由引起（状态或事件）模型状态或值改变的一系列可执行原子计算组成。在状态图中，只能有一个初态，可以有多个终态。初态使用实心黑圆表示，终态使用包含实心黑圆的圈表示。而且，状态图还可以有分支、分叉、汇合、历史状态等。状态图下图显示了网上书店订单类的示意状态图。由初态开始，首先进入“审核付款”，如未支付，则转到“拒绝”状态并到终态；如果已经支付，则转到“审核完成”状态。接着进入“订单审核”状态，如果有货则“发货”，没货则进入“等待发货”。发货完成，进入买家“已收货”状态，最终进入终态。活动图活动图活动图中的

34、活动是展示整个计算步骤的控制流（及其操作数）的结点和流的图。执行的步骤可以是并发的或顺序的。活动图活动图可以看做特殊的状态图状态图，用于对计算流程和工作建模（后者是对对象的状态建模）。活动图活动图的状态表示计算过程中的所处的各种状态。活动图活动图的开始结点和结束结点与状态图状态图相同，活动图中的状态称为动作状态，也使用圆角矩形表示。动作状态之间使用箭头连接，表示动作迁移，箭头上可以附加警戒条件、发送子句和动作表达式。活动图活动图是状态图状态图的变形，根据对象状态的变化捕获动作（所完成的工作和活动）和它们的结果，表示了各动作及其间的关系。活动图与状态图状态图不同的是，活动图活动图之间的动作迁移并

35、不是靠触发状态图之间状态迁移的事件完成的，而是当动作状态包含的活动完成时就进入下一个状态。在活动图活动图中，事件只能附加在开始结点到第一个动作状态之间的迁移上。在活动图活动图中，判定符号用菱形表示，可以包含两个或更多附加有警戒条件的输出迁移，迁移根据警戒条件是否为真选择迁移结点。活动图活动图活动图可以根据活动发生位置的不同划分为若干个矩形区，每个矩形区称为一个泳道，泳道有泳道名。把活动划分到不同的泳道中，能更清楚地表明动作在哪里执行（在哪个对象中等）。一个动作迁移可以分解成两个或更多导致并行动作的迁移，多个来自并行动作的迁移也可以合并为一个迁移。需要注意的是，并行迁移上的动作必须全部完成才能进

36、行合并。活动图活动图中也可以包含对象，对象使用矩形表示，可作为活动的输入或输出（用虚线箭头连接），表示对象受特定动作的影响，如下图所示。活动图此外，活动图还可以描述系统的活动场景。以用户在网上书店提交订单为例，系统接收用户的订单，确认是否付款；若未付款，则取消订单；若已付款，则检查订单内容；如果有货，就发货并更新库存；若无货则等待采购。活动图这一活动场景的活动图如下图所示。通信图通信图通信图又称协作图（或合作图），用于显示系统的动作协作，类似顺序图中的交互片段，但通信图通信图也显示对象之间的关系（上下文）。实际建模中，顺序图顺序图和通信图通信图的选择需要根据工作的目标而定。如果重在时间或顺序，

37、那么选择顺序图顺序图；如果重在上下文，那么选择通信图通信图。顺序图顺序图和通信图通信图都显示对象之间的交互。通信图通信图显示多个对象及它们之间的关系，对象间的箭头显示消息的流向。消息上也可以附带标签，表示消息的其它信息，如发送顺序、显示条件、迭代和返回值等。开发人员熟识消息标签的语法之后，就可以读懂对象之间的通信，并跟踪标准执行流程和消息交换顺序。但是，如果不知道消息的发送顺序，那么就不能使用通信图来表示对象关系。通信图网上书店游客成功登录过程的通信图如下图所示。交互概况图交交互概况图互概况图为建模人员提供从高级抽象层次来检查系统主要交互流的方式。当建模人员设法保证所做的设计已经捕获了用例中定

38、义的所有主流程元素时，就可以证明UML的这个特征非常有用。交互概况图交互概况图基本上就是一个活动图，只是主节点由交互片段（即顺序图的某些部分）代替，并以特定的顺序放置。也为建模人员提供了另一种显示交互期间的流控制的方法，其要点就是显示在系统某个位置处的交互具有的各种选择。时序图时序图时序图主要用于实时系统，显示对象的交互，以及这些对象沿着时间轴所发生的状态变化。时序图时序图提供了一种用来显示主动对象，以及在它们与其他主动对象、系统资源的交互过程中的状态变化的方法。时序图时序图的X轴为时间轴，Y轴为主动对象及其状态。时序图每个主动对象在X轴方向上具有方波（矩形波）一样的时间序列，根据时间轴向的时

39、序宽度，即可知道主动对象在某一状态的持续时间。由于多个对象在Y轴方向对齐排列，所以很容易判断同一时刻，哪些主动对象处于什么状态，这为挑选竞争条件、优先级倒置、死锁，以及其它通信问题提供了一个非常有用的工具。组件图组件图组件图根据系统的代码组件显示系统代码的物理结构。其中的组件可以是源代码组件、二进制组件或者可执行组件。组件包含了其实现的一个或多个逻辑类信息，因此也就创建了从逻辑视图到组件视图的映射。根据组件视图中组件之间的关系，可以轻易地看出当某一个组件发生变化时，哪些组件会受到影响。组件图如下图所示的组件图，“Student”组件依赖于“Common”组件，“Librarian”组件也依赖于

40、“Common”组件，这样，如果“Common”组件发生变化，就会同时影响到“Student”组件和“Librarian”组件。依赖关系本身还具有传递性，如“Common”组件依赖于“DataBase”组件，所以“Student”和“Librarian”组件也依赖于“DataBase”组件。部署图部署图部署图用于显示系统中硬件和软件的物理结构，可以显示实际中的计算机和设备（节点），以及它们之间的互连关系。在部署图部署图中的节点内，已经分配了可以执行的组件和对象，以显示这些软件单元具体在哪个节点上运行。部署图部署图也显示了各组件之间的依赖关系。部署图部署图部署图是对系统实际物理结构的描述，不同于

41、用例图等从功能角度的描述。对一个明确定义的模型，可以实现完整的导航：从物理部署节点到组件，再到实现类，然后是该类对象参与的交互，最后到达具体的用例。系统的各种视图合在一起，从不同的角度和细分层面完整地描述整个系统。部署图图书管理系统的物理机构部署图如下图所示，整体上划分为数据库、应用系统和客户端3个节点。数据库节点中包含“DataBase”的相关组件，应用系统中包含“Common”、“Student”和“Librarian”等组件，客户端中包含各种客户端组件。包图包包是一种对元素进行分组的机制。如果系统非常复杂，常常包含大量的模型，为了利于理解以及将模型独立出来用于复用，对这些元素进行分组组织，从而作为一个个集合进行整体命名和处理。包包的符号如右图所示。包图包包中的元素需要与其它包或类中的元素进行交互，交互过程的可访问性包括：包中元素可以被其它包的元素访问。包中元素只能被同属于一个包的内含元素访问。包中的元素只能被此包或其继承包内的元素访问。包图包包的一些特征如下：包是包含和管理模型内容的一般组织单元，任何模型元素都可以包含其中 一个模型元素只能存在于一个包中，包被撤销时，其中的元素也被撤销 包可以包含其他包，构成嵌套层次结构。包只是一个概念化的元素，不会被实例化，在软件运行中不会有包存在其中。