UML重点经验总结资源-CSDN文库

UML

设计模式

需积分: 9 28 浏览量 2007-12-28 17:05:11 上传评论收藏 179KB DOC 举报

资源推荐

资源详情

资源评论

　二. 标准建模语言 UML 的内容

　标准建模语言 UML 的重要内容可以由下列五类图（共 9 种图形）来定义：



第一类是用例图，从用户角度描述系统功能，并指出各功能的操作者。　

第二类是静态图(Static diagram)，包括类图、对象图和包图。

类图描述系统中类的静态结构。不仅定义系统中的类，表示类之间的联系如关

联、依赖、聚合等，也包括类的内部结构（类的属性和操作）。类图描述的是

一种静态关系，在系统的整个生命周期都是有效的。

对象图是类图的实例，几乎使用与类图完全相同的标识。他们的不同点在于对

象图显示类的多个对象实例，而不是实际的类。一个对象图是类图的一个实例。

由于对象存在生命周期，因此对象图只能在系统某一时间段存在。

包图由包或类组成，表示包与包之间的关系。包图用于描述系统的分层结构。

第三类是行为图（Behavior diagram），描述系统的动态模型和组成对象间

的交互关系。

状态图描述类的对象所有可能的状态以及事件发生时状态的转移条件。通常，

状态图是对类图的补充。在实用上并不需要为所有的类画状态图，仅为那些有

多个状态其行为受外界环境的影响并且发生改变的类画状态图。

活动图描述满足用例要求所要进行的活动以及活动间的约束关系，有利于识别

并行活动。

第四类是交互图（Interactive diagram），描述对象间的交互关系。

顺序图显示对象之间的动态合作关系，它强调对象之间消息发送的顺序，同时

显示对象之间的交互

合作图描述对象间的协作关系，合作图跟顺序图相似，显示对象间的动态合作

关系。除显示信息交换外，合作图还显示对象以及它们之间的关系。如果强调

时间和顺序，则使用顺序图；如果强调上下级关系，则选择合作图。这两种图

合称为交互图。

第五类是实现图( Implementation diagram )。

构件图描述代码部件的物理结构及各部件之间的依赖关系。一个部件可能是一

个资源代码部件、一个二进制部件或一个可执行部件。它包含逻辑类或实现类

的有关信息。部件图有助于分析和理解部件之间的相互影响程度。

配置图定义系统中软硬件的物理体系结构。它可以显示实际的计算机和设备

（用节点表示）以及它们之间的连接关系，也可显示连接的类型及部件之间的

依赖性。在节点内部，放置可执行部件和对象以显示节点跟可执行软件单元的

对应关系。

从应用的角度看，当采用面向对象技术设计系统时，首先是描述需求；其次

根据需求建立系统的静态模型，以构造系统的结构；第三步是描述系统的行为。

其中在第一步与第二步中所建立的模型都是静态的，包括用例图、类图（包含

包）、对象图、组件图和配置图等五个图形，是标准建模语言 UML 的静态建模

机制。其中第三步中所建立的模型或者可以执行，或者表示执行时的时序状态

或交互关系。它包括状态图、活动图、顺序图和合作图等四个图形，是标准建

模语言 UML 的动态建模机制。因此，标准建模语言 UML 的主要内容也可以归

纳为静态建模机制和动态建模机制两大类。

四. 标准建模语言 UML 的应用领域

 UML 适用于系统开发过程中从需求规格描述到系统完成后测试的不同阶段。

在需求分析阶段，可以用用例来捕获用户需求。通过用例建模，描述对系统感

兴趣的外部角色及其对系统（用例）的功能要求。分析阶段主要关心问题域中

的主要概念（如抽象、类和对象等）和机制，需要识别这些类以及它们相互间

的关系，并用 UML 类图来描述。为实现用例，类之间需要协作，这可以用

UML 动态模型来描述。在分析阶段，只对问题域的对象（现实世界的概念）建

模，而不考虑定义软件系统中技术细节的类（如处理用户接口、数据库、通讯

和并行性等问题的类）。这些技术细节将在设计阶段引入，因此设计阶段为构

造阶段提供更详细的规格说明。

编程（构造）是一个独立的阶段，其任务是用面向对象编程语言将来自设计

阶段的类转换成实际的代码。在用 UML 建立分析和设计模型时，应尽量避免考

虑把模型转换成某种特定的编程语言。因为在早期阶段，模型仅仅是理解和分

析系统结构的工具，过早考虑编码问题十分不利于建立简单正确的模型。

 UML 模型还可作为测试阶段的依据。系统通常需要经过单元测试、集成测

试、系统测试和验收测试。不同的测试小组使用不同的 UML 图作为测试依据：

单元测试使用类图和类规格说明；集成测试使用部件图和合作图；系统测试使

用用例图来验证系统的行为；验收测试由用户进行，以验证系统测试的结果是

否满足在分析阶段确定的需求。

五、标准建模语言 UML 的静态建模机制

(1) 用例模型描述的是外部执行者(Actor)所理解的系统功能。用例模型用于需

求分析阶段,它的建立是系统开发者和用户反复讨论的结果,表明了开发者和用

户对需求规格达成的共识。首先,它描述了待开发系统的功能需求;其次,它将系

统看作黑盒,从外部执行者的角度来理解系统;第三,它驱动了需求分析之后各阶

段的开发工作,不仅在开发过程中保证了系统所有功能的实现,而且被用于验证

和检测所开发的系统,从而影响到开发工作的各个阶段和UML 的各个模型。在

UML 中,一个用例模型由若干个用例图描述,用例图主要元素是用例和执行者。

(2) 用例(use case) 从本质上讲,一个用例是用户与计算机之间的一次典型交互

作用。以字处理软件为例,"将某些正文置为黑体"和"创建一个索引"便是两个典

型的用例。在 UML 中,用例被定义成系统执行的一系列动作,动作执行的结果能

被指定执行者察觉到。在 UML 中,用例表示为一个椭圆。

·用例捕获某些用户可见的需求,实现一个具体的用户目标。

·用例由执行者激活,并提供确切的值给执行者。

·用例可大可小,但它必须是对一个具体的用户目标实现的完整描述。

(3) 执行者(Actor)是指用户在系统中所扮演的角色。其图形化的表示是一个小

人。一个用户也可以扮演多种角色(执行者)。例如,一个高级营销人员既可以是

贸易经理,也可以是普通的营销人员;一个营销人员也可以是售货员。在处理执

行者时,应考虑其作用,而不是人或工作名称,这一点是很重要的。不带箭头的线

段将执行者与用例连接到一起,表示两者之间交换信息,称之为通信联系。执行

者触发用例,并与用例进行信息交换。单个执行者可与多个用例联系;反过来,一

个用例可与多个执行者联系。对同一个用例而言,不同执行者有着不同的作用:

他们可以从用例中取值,也可以参与到用例中。尽管执行者在用例图中是用类似

人的图形来表示的,但执行者未必是人。例如,执行者也可以是一个外界系统,该

外界系统可能需要从当前系统中获取信息,与当前系统有进行交互。

通过实践,我们发现执行者对提供用例是非常有用的。面对一个大系统,要列出

用例清单常常是十分困难。这时可先列出执行者清单,再对每个执行者列出它的

用例,问题就会变得容易很多。

(4) 使用和扩展(Use and Extend)是两种不同形式的继承关系。当一个用例与

另一个用例相似,但所做的动作多一些,就可以用到扩展关系。

例如图1 中,基本的用例是"进行交易"。交易中可能一切都进行得很顺利,但也

可能存在扰乱顺利进行交易的因素。将非常规的动作放置于"超出某些边界值

的情况" 用例中,这便是扩展关系的实质。当有一大块相似的动作存在于几个用

例,又不想重复描述该动作时,就可以用到使用关系。

(5) 用例模型的获取几乎在任何情况下都会使用用例。用例用来获取需求,规划

和控制项目。用例的获取是需求分析阶段的主要任务之一,而且是首先要做的工

作。大部分用例将在项目的需求分析阶段产生,并且随着工作的深入会发现更多

的用例,这些都应及时增添到已有的用例集中。

用例集中的每个用例都是一个潜在的需求。

a. 获取执行者获取用例首先要找出系统的执行者。可以通过用户回答一些问题

的答案来识别执行者。

以下问题可供参考:

·谁使用系统的主要功能(主要使用者)。

·谁需要系统支持他们的日常工作。

·谁来维护、管理使系统正常工作(辅助使用者)。

·系统需要操纵哪些硬件。

·系统需要与哪些其它系统交互,包含其它计算机系统和其它应用程序。

·对系统产生的结果感兴趣的人或事物。

b. 获取用例一旦获取了执行者,就可以对每个执行者提出问题以获取用例。以

下问题可供参考:

·执行者要求系统提供哪些功能(执行者需要做什么)?

·执行者需要读、产生、删除、修改或存储的信息有哪些类型。

·必须提醒执行者的系统事件有哪些?或者执行者必须提醒系统的事件有哪些?怎

样把这些事件表示成用例中的功能?

·为了完整地描述用例,还需要知道执行者的某些典型功能能否被系统自动实现?

还有一些不针对具体执行者问题(即针对整个系统的问题):

·系统需要何种输入输出?输入从何处来?输出到何处?

·当前运行系统(也许是一些手工操作而不是计算机系统)的主要问题?

需要注意,最后两个问题并不是指没有执行者也可以有用例,只是获取用例时尚

不知道执行者是什么。一个用例必须至少与一个执行者关联。还需要注意:不同

的设计者对用例的利用程度也不同。

剩余11页未读，继续阅读

评论收藏

内容反馈

零度畅想

粉丝: 17
资源: 20

UML 重点经验总结

最新资源

UML 重点经验总结

2017天津理工大学软件工程重点整合-UML部分(精品PPT课件).ppt

UML自己学习总结

UML期末复习总结.docx

UML考试题库总结

UML学习总结报告

UML考点总结

uml期末重点

UML建模系列文章总结

UML各种图画法总结

uml设计总结

UML类图符号总结

UML复习大纲总结整套版

UML+OOPC总结笔记1

uml 资料学习总结

UML及其建模课程设计

个人总结UML类图介绍

UML九种视图总结

uml实验报告总结.pdf

uml实验报告总结.doc

uml实例uml实例uml实例uml实例uml实例

Qt 5实现串口调试助手 （源工程文件、0积分下载）

【SystemVerilog】路科验证V2学习笔记（全600页）.pdf

AutoSAR标准协议4.2.2

光伏-储能并网系统仿真.rar

NPPJSONViewer.zip

GD32替换STM32注意事项.pdf

XCP协议的规范文档

VS2015安装证书，JavaScript_ProjectSystem.msi，JavaScript_LanguageService.msi

CANoe通过CAPL脚本实现自动测试

最新资源

Qt 5实现串口调试助手（源工程文件、0积分下载）