用例模型20.docx

用例模型20.docx

《用例模型20.docx》由会员分享，可在线阅读，更多相关《用例模型20.docx（60页珍藏版）》请在冰豆网上搜索。

用例模型20

第6章用例模型

学习目标

1、了解UML中的基本图形元素

2、掌握用例图的概念及基本元素

3、学会建立用例模型

4、掌握用例描述

5、学会使用StarUml绘制用例图

什么是模型？

模型是一组具有完整语义的信息，它是对现实世界的简化，也是对认知主体的抽象，建模过程就是认识世界、捕捉认知对象本质的过程。

拓展思维：

在周围环境中，哪些地方都用到了模型的思想？

面向对象（ObjectOriented,OO）是当前计算机界关心的重点。

面向对象建模是软件工程师对系统相关的问题域的建模和求解域的建模。

注释：

什么是问题域？

什么是求解域？

问题域是软件工程师需要理解系统运行的环境，需要了解与系统相关的问题。

例如：

对于一个火车交通控制系统来说，软件工程师需要知道火车信号化的程序；对于一个股票交易系统，软件工程师需要知道交易规则，但软件工程师不需要成为一个完全通过认证的火车调度员或股票经纪人。

他们仅仅需要的是了解与该系统相关的问题概念，换句话说，他们需要构造一个问题域的模型。

求解域是软件工程师需要构建一个求解域，以帮助理解构建的系统、评估不同的解决方案并进行权衡。

同时因为大多数系统是非常复杂的，任何个人都没有足够的精力能完全理解，而且这样的系统构建起来也是非常昂贵的。

为了克服这些挑战，软件工程师就需要构建问题域。

问题域首先被建模为一组对象和关系，然后，系统用这个模型来表达它操纵现实世界的概念。

例如一个火车交通控制系统包括火车对象，表示它监视的火车。

一个股票交易系统包括交易对象，用来表示股票的买进和卖出。

然后，求解域的概念也被建模为对象。

UML，称为统一建模语言（UnifiedModelingLanguage），是目前面向对象对现实世界建模的统一标准之一，它提供了一种可视化的建模语言，采用一组具有明确语义的图形符号，建立清晰的模型便于用户和软件开发者之间的交流。

它用模型来描述软件系统的静态特征和动态特征。

针对UnifiedModelingLanguage，可作如下理解：

Unified：

组合了当前最好的面向对象软件建模方法，包括GradyBooch的TheBoochMethod，JamesRumbaugh的OMT，IvarJacobson的OOSE等；

Modeling：

用于表达现实的简化视图，以便于面向对象软件系统的设计与实现。

Language：

UML主要是遵循精确语法的图形语言。

UML的目标是用面向对象的方式描述任何类型的系统，最直接的是用UML为软件系统创建模型。

用例模型是UML中从用户的观点对软件系统行为的一个建模，定义了系统做什么，即以系统功能为目标，从系统使用者的角度来描述系统操作的过程。

6.1UML简介

UML是一种建模语言，是用来为面向对象开发系统的产品进行说明可视化和编制文档的方法。

它是由信息系统（IS，InformationSystem）和面向对象领域的三位著名的方法学家GradyBooch，JamesRumbaugh和IvarJacobson（称为“三个好朋友”，theThreeAmigos）提出的。

这种建模语言得到了UML伙伴联盟的应用于反馈，并得到了工业界的广泛支持，由OMG组织（ObjectMangementGroup）采纳作为业界标准。

UML是一种定义良好、易于表达、功能强大的用于对软件密集型系统建模的图形语言。

它支持从需求分析开始的面向对象软件开发的全过程。

UML作为一种建模语言，它使软件开发人员专注于建立系统的模型和结构，而不是选用具体的程序设计语言和算法来实现。

当模型建立之后，模型可以被UML工具转化成指定的程序设计语言代码和数据库结构。

拓展阅读：

1997年，作为Booch、OOSE和OMT方法的主要作者，GradyBooch、IvarJacobson和JamesRumbaugh一起工作，创立了UML（统一建模语言）0.9版本。

Grady（IBMfellow）因其在软件架构、软件工程和软件建模方面的杰出贡献而在国际上享有盛名。

自Rational于1981年创建以来，他就一直担任IBMRational的首席科学家。

Grady于2003年3月荣获IBM名士（IBMfellow）的称号。

IvarJacobson博士是Objectory方法的发明者，也是瑞典ObjectoryAB公司的创始人。

Jacobson博士是两本影响深远的畅销书的主要作者：

《面向对象的软件工程―一种用例驱动方法》（1992年计算机语言生产力奖获得者）和《对象的优势―采用对象技术的业务过程再工程》。

Rumbaugh博士是享誉全球的软件开发方法学家。

Jim一直是引导UML未来开发的领袖，他提出了许多有关UML的概念。

他与Rational的其他软件领袖一起工作在各个领域，比如Rational统一过程和实时开发方法学。

自从2003年IBM收购了Rational之后，Jim就一直致力于推动IBM建模工具的开发。

Rumbaugh

GradyBooch

IvarJacobson

6.1.1UML语言特点

标准建模语言UML的出现，是面向对象软件工程二十世纪九十年代中期所取得的最重要的成果。

其主要特点可以归结为以下三点：

（1）统一标准

UML不仅统一了Booch、OMT和OOSE等方法中的基本概念，还吸取了面向对象技术领域中其他流派的长处，其中也包括非OO方法的影响。

UML使用的符号表示考虑了各种方法的图形表示，删掉了大量易引起混乱的、多余的和极少使用的符号，也添加了一些新符号，提供了标准的面向对象的模型元素的定义和表示法，并已经成为OMG的标准。

（2）面向对象

UML支持面向对象的主要概念，包括类、对象、消息等，它提供了一批基本的表示模型元素的图形和方法，能简洁明了地表达面向对象的各种概念和模型元素。

（3）表达能力强大、可视化

UML是一种图形化语言，用UML的模型图形能清晰地表示系统的逻辑模型或实现模型。

它不只是一堆图形符号，在每一个图形表示符号后面，都有良好定义的语义；UML还提供了语言的扩展机制，用户可以根据需要增加定义自己的构造型、标记值和约束等，它的强大表达能力使它可以用于各种复杂类型的软件系统的建模。

但是UML并不是万能的，正如M.Fowler指出的，UML是一种建模语言而不是一种方法。

它不包含任何过程指导。

就是说，它并不讲述如何运用面向对象的概念与原则去进行建模，而只是定义了用于建模的各种元素，以及由这些元素所构成的各种图的构成规则。

在文学领域，一本词典加一本语法手册，并不能构成一种文学理论或创作方法，也不能使学习者学会如何进行文学创作。

同样，在软件领域，仅有一种建模语言不能算作是一种建模方法，也不能为工程技术人员提供一套可遵循的开发准则。

6.1.2UML中的基本图形元素

在UML中定义了两类模型元素。

一类模型元素称为是事物，包括结构事物、动作事物、分组事物和注释事物，主要用于表示模型中的某个概念，如类、对象、构件、用例、结点、接口、包和注释等；另一类称为是关系，用于表示模型元素之间相互连接的关系，其中主要有关联、泛化、依赖和聚集等。

这两类模型元素均可用图形符号来表示。

（1）结构事物

结构事物共有7种：

类、接口、协作、用例、活动类、组件和节点。

●类：

是对具有相同属性、方法、关系和语义的对象的抽象，一个类可以实现一个或多个接口。

在UML中类用包括类名、属性和方法的矩形表示。

●接口：

是为类或组件提供特定服务的一组操作的集合。

接口描述了类或组件的对外可见的动作。

在UML中接口用圆表示，在图形旁边还要标注接口的名字。

●协作：

定义了交互操作。

在UML中，用虚线构成的椭圆表示，椭圆中要标注协作的名字。

●用例：

描述系统对一个特定角色执行的一系列动作。

在UML中，用例用标注了用例名称的实线椭圆表示，如下图所示。

●活动类：

是类对象有一个或多个进程或线程的类，在UML中，活动类和类的表示法相同，只是边框用粗线条，如下图所示。

●组件：

是实现了一个接口集合的物理上可替换的系统部分。

●节点：

是在运行时存在的一个物理元素。

它代表一个可计算的资源，通常占用一些内存和具有处理能力。

一个组件集合一般来说位于一个节点。

（2）动作事物

动作事物是UML模型中的动态部分,代表时间和空间上的动作。

交互和状态机是UML中最基本的两个动态事物元素。

●交互：

是一组对象在特定上下文中，为达到某种特定的目的而进行的一系列消息交换组成的动作。

在UML中用带箭头的直线来表示。

●状态机：

由一系列对象的状态组成。

（3）分组事物

分组事物是UML模型中组织的部分，分组事物只有一种，称为包。

包是一种有组织地将一系列元素分组的机制。

。

（4）注释事物。

注释事物是UML模型的解释部分。

以下是几种连接关系的含义：

（1）关联：

连接模型元素及链接实例；例如教师和学生之间的关系。

（2）泛化：

表示一般与特殊的关系，即“一般”元素是“特殊”元素的泛化，“特殊”元素是“一般”元素的特化；例如：

（3）依赖：

表示一个元素以某种方式依赖于另一个元素；假设有两个元素X，Y，如果修改元素X的定义可能会引起对另一个元素Y的定义的修改，则称元素Y依赖于元素X。

（4）聚集：

表示整体与部分的关系，即“部分”元素是“整体”元素的一部分。

回答问题：

（1）在上面的图中，“车”，“教师”，“显示器”等事物属于UML中的哪一个概念？

（2）“人”，“男人”，“女人”之间是UML中的什么关系？

（3）观察周围的事物，举出“聚合”，“泛化”关系的实例。

6.1.3UML组织结构

UML是用来描述模型的，它用模型来描述系统的结构（静态特征）和行为（动态特征）。

它从不同的视角为系统建模，形成不同的视图（View），每个视图代表完整系统描述中的一个抽象，显示这个系统中的一个特定的方面；每个试图有一组图构成，图中包含了强调系统中某一方面的信息。

UML包括两类图和五种视图。

（1）图

图是系统架构在某个侧面的表示，UML提供了两大类——静态图和动态图，共计9种不同的图。

静态图（StaticDiagram）包括用例图、类图、对象图、件图、部署图。

其中用例图描述系统的功能；类图描述系统的静态结构；对象图描述系统在某个时刻的静态结构；构件图描述实现系统的元素的组织；部署图描述系统环境元素的配置。

动态图（DynamicDiagram）包括状态图、时序图、协作图和活动图。

其中状态图描述系统元素的状态条件和响应；时序图按时间顺序描述系统元素间的交互；协作图按照时间和空间的顺序描述系统元素间的交互和关系；活动图描述系统元素的活动。

其中活动图是由JameOdell提出，状态图由DavidHarel提出。

（2）视图

用例视图表达从用户角度看到的系统应有的外部功能，有时也叫用户模型视图；用用例图来描述。

设计视图描述系统设计特征，包括结构模型视图和行为模型视图，前者描述系统的静态结构（类图、对象图），后者描述系统的动态行为（交互图、状态图、活动图）。

部署视图配置视图描述系统的物理配置特征。

用配置图表示。

实现视图表示系统的实现特征，常用构件图表示。

进程视图表示系统内部的控制机制。

常用类图描述过程结构，用交互图描述过程行为。

思考：

不会编程可以学习UML吗？

注解：

可以，为什么不可以呢？

只要你清楚下面这一点，对于不懂编程的你，只要你不试图很快地直接用UML写出可执行的软件程序，你就可以立即去学习UML。

据说某些高手可以通过RationalRose这样的工具用UML建模，然后直接生成项目50%以上的程序代码。

我相信这是真的，但对于不懂编程的你，暂时是再努力也做不到这样的。

UML是一种建模语言，除了上面这个作用外，其他用处还多得很，只要你不是为了这个而学习UML，你就可以放心大胆地去学，学习UML对编程知识没有什么依赖，相反，某些根深蒂固的编程想法，有时候倒是会误导很多人做出晦涩难懂的模型。

如果你的目标是成为系统分析员，设计师或方案工程师、业务咨询师、流程师、管理大师等，你渴望把你在某个业务领域的经验和知识借助模型表达出来，那么，你就是非常适合学习UML的人选，如果你的目标就是成为程序员或成为优秀的软件分析师、设计师，那么，你免不了迟早要精通至少一门编程语言，而且要参与三个以上的有一定份量的软件项目的开发工作。

即使这样，学习编程语言和学习UML也并不需要有先后之分。

你仍然可以立即开始学习UML，而且，学会了UML建模，对你往后学习具体的编程语言一定会是有帮助的。

6.2需求分析与用例模型

电影《其实你不懂他的心》（He'sJustNotThatIntoYou）

在日常生活中，你可能会说“我要吃蛋炒饭！

”，会想“我需要什么样的女朋友？

”等等诸如此类的问题，它们都体现人们对周围环境或者对自己的需求，电影《其实你不懂他的心》也是以此为题材编写的一部经典影片，受到了很多人们的喜欢。

总之，需求是人们对某项事物在特定时间内的一个想法或者一个要求。

但这种需求往往是多方面的、不确定的，即需求具有多变性。

1915年，Rubin展示了与下图相似的一幅图画，说明了多稳定图像的概念。

你看见了什么？

两张对看的人脸？

如果你更多关注白色区域，实际上你会看到一个花瓶。

一旦你能分别插接到这两个图像，就比较在花瓶和人脸之间前后切换了。

如果上图有一个系统需求说明，那么你会构建哪一个模型呢？

由于自然语言固有的不准确性以及需求说明者自作的假设，这个系统需求说明就与多稳定图像一样，含有二义性；即不确定。

软件系统的需求是指用户对软件的功能和性能的要求，就是用户希望软件能做什么事情，完成什么样的功能，达到什么性能。

同样，软件系统的需求也是不确定的，需要软件分析师和用户沟通，去分析和引导客户将心里模糊的需求以精确的方式描述并展示出来。

这个过程就是需求分析。

需求分析就是提供一种与客户在系统功能方面进行沟通并达成共识的方式，使开发者能够更准确的理解系统的需求；是把客户的功能描述转化为软件人员所能理解的功能描述，并在客户描述的基础上去除不合理的地方，补充系统缺失的地方，最后为系统的概要设计，详细设计提供准确，有效的数据基础。

需求分析在软件开发过程中是非常重要的，如果需求获取不正确或在需求开发过程中很多功能没有挖掘出来，那么在后期选择弥补时，将会造成项目延期以及成本大幅度增加的严重后果。

例1：

软件开发者没有正确理解客户的要求。

例2：

需求没有满足完备性和一致性，就开始了设计。

需求分析是为软件的最终用户所看到的系统建立一个模型，是对需求抽象的描述。

用例模型是采用面向对象的思想，是需求分析模型的表现形式之一，主要用于表现系统的功能性需求；是以一种更直观的图性方式来表现用户对软件系统的要求。

即客户通过用例模型来验证系统在完成之后是否能够满足自己的期望，开发者通过用例模型来保证自己正在开发的系统是客户所期望的，以保证用户和软件开发者对问题理解的完备的一致。

6.3用例模型

用例模型使用用例描述了系统的功能需求，模型化表示了系统的功能和系统的环境。

用例模型为客户和开发者提供了一种契约。

当客户同意了用例模型，客户希望得到的系统功能也就确定了。

在软件开发过程中，用例模型可以作为一种方式用来与系统的客户进行交流。

用例模型的作用有（摘于IBM教材《使用UML进行面向对象分析与设计》）：

（1）在系统开发的早期就可以明确最后提交的产品功能和特性；

（2）确保双方都对需求有了准确的理解标识（系统的用户群和系统的功能）；

（3）确定对系统与用户群之间接口的需求验证（是否客户所有的需求都被捕获）；

（4）确保开发团队已完全理解了客户的需求。

用例模型是使用用例的方法来描述系统功能需求的过程。

它主要包括两部分内容：

用例图和用例描述。

6.3.1用例图

用例图（Usecasediagram）从用户角度描述系统功能,并指出各功能的操作者。

在用例图中的核心概念有角色和用例。

拓展阅读：

用例图的多种认识

●用例图用于描述系统应该具有的功能集，它是从系统的外部用户角度出发对系统的抽象表示。

●用例图所描述的系统功能依靠于外部用户或另一个系统触发激活，为用户或另一个系统提供服务，实现用户或另一个系统与系统的交互，系统实现的最终目标是提供用例视图中描述的功能

●用例图是UML其他视图的核心和基础，其他图的构造和发展依赖于用例图中所描述的内容。

因为系统的最终目标是提供用例图中描述的功能，同时附带一些非功能性的性质，因此用例图影响着所有其他的图

●用例图还可用于测试系统是否满足用户的需求和验证系统的有效性；

用例图主要为用户设计人员、开发人员和测试人员而设置，用例图静态地描述系统功能为了动态地观察系统功能偶尔也用活动图activitydiagram描述。

（1）角色（Actor），又称为参与者，是指系统的用户在与系统按照用例的描述进行交互时所扮演的一系列相关的角色。

典型地，一个角色可以是一个人，一部硬件或者与系统进行交互的其它系统。

角色是一个群体概念，代表的是一类能使用某个功能的人或事，角色不是指某个个体。

比如在自动售货系统中系统有售货、供货、提取销售款等功能，启动售货功能的是人，那么人就是角色，如果再把人具体化，则该人可以是张三（张三买矿泉水），也可以是李四（李四买可乐），但是张三和李四这些具体的个体对象不能称作角色。

事实上，一个具体的人（比如张三）在系统中可以具有多种不同的角色。

比如上述的自动售货系统中，张三既可以为售货机添加新物品（执行供货），也可以将售货机中的钱取走（执行提取销售款）。

通常系统会对角色的行为有所约束，使其不能随便执行某些功能。

比如可以约束供货的人不能同时又是提取销售款的人，以免有舞弊行为。

角色都有名字，它的名字反映了该角色的身份和行为（比如，顾客），注意不能将角色的名字表示成角色的某个实例（比如，张三），也不能表示成角色所需完成的功能（比如，售货）。

例1：

“我的一个朋友结婚了”，在这个事实描述里，你会想到哪些人或事呢？

答案是：

月老，新娘，新郎，亲朋好友，玫瑰花。

这些就是这个事实中的人或事，也可以称为是这个事实描述里面存在的角色。

例2：

“Jack要给家里举办一个舞会，他会邀请哪些人呢？

Jack想了一会，给他的妻子说，“我准备邀请的人有：

亲密的同事，要好的朋友，帮忙的邻居”。

那么在这次舞会里，又会有哪些人呢？

这些人对于舞会的贡献是什么呢？

在这个场景中，会有哪些角色呢？

分析：

参加舞会的人有：

参加舞会的人

对舞会的贡献

Jack

舞会筹备者、舞会参加者

Jack的妻子

舞会筹备者、舞会参加者

同事

舞会参加者

朋友

舞会参加者

邻居

舞会参加者

角色应该从与此事件交互过程中所表现的作用或者贡献来确定。

在这个场景中，存在的角色有:

而对于Jack、某同事或者某邻居等都只能称为是角色的一个个体，是角色的实例化。

（2）用例（UseCase）是系统对角色的交互进行响应，并产生一个可见的结果时所进行的一系列动作。

用例描述了系统的功能，并且不涉及到系统的实现。

用例的图型表示为：

这里要特别强调的是，用例是经过一系列的动作所产生的结果。

拓展阅读：

用例（usecase）这个概念是IvarJacobson于20世纪60-70年代在爱立信公司开发AKE、AXE系列系统时发明的，并在其博士论文“Conceptsformodelinglargerealtimesystems”（1985年）和1992年出版的论著“Object-orientedsoftwareengineering:

ausecasedrivenapproach”中做了详细论述。

自从Jacobson提出用例概念后，面向对象领域已经广泛采纳了这一概念，并认为它是第二代面向对象技术的标志。

针对用例还有如下解释：

用例定义1：

用例是对一个参与者（Actor）使用系统的某一项功能时所进行的交互过程的一个文字描述序列。

用例定义2：

用例是系统、子系统或类和外部的参与者（Actor）交互的动作序列的说明，包括可选的动作序列和会出现异常的动作序列。

用例从使用系统的角度描述系统的信息，即站在系统外部查看系统功能，而不是考虑系统内部对该功能的实现。

用例可以清楚描述了用户提出的可见需求，每个用例对应一个具体的用户目标，使用用例可以促进与用户沟通，理解正确的需求，同时可以划分系统与外部对象的界限。

用例是代表系统中各项目相关人员之间就系统的行为达成的契约。

用例分析的结果可以为预测系统的开发时间和预算提供依据，保证项目的顺利进行，因此用例可以驱动软件开发过程。

我们可以把所有的用户需求都用用例来表示，因此用例可以表达用户对产品功能的期望，表达客户的需求，不仅如此，而且开发人员可以借助用例来与用户沟通，发现用户的潜在性需求。

例3：

在一节不和谐的课堂里，老师叹气道：

“要是坐在后排聊天的同学能像中间打牌的同学那么安静，就不会影响到前排睡觉的同学。

”在这个描述中，同学们在课堂上都做了什么呢？

答案：

聊天、打牌、睡觉。

分析：

睡觉，用到的一些列动作有趴在课桌上、打鼾、磨牙等等；产生的结果时睡觉后不瞌睡了。

打牌，用到的一些列动作有找打牌者、找扑克牌、起牌、出牌等等；产生的结果时打牌者心灵上得到了娱乐。

那么这些动宾词语就是用例，它表示了“同学”这个角色所做的事情。

例4：

如果你去使用ATM机（自动取款机），那么你通过ATM都可以做什么呢？

答案是：

查询、存款、取款、转账、打印等。

这些都可以称为是用例，如下表示：

用例描述用户提出的一些可见需求，对应一个具体的用户目标。

在例4中，不论是存款还是转账我们都需要进行“数据处理”，但是“数据处理”不属于一个用例，因为它没有直接反应用户的需求。

（3）绘制用例图

用例图是用例的集合，通常由系统、用例、角色和关联组成。

系统用一个矩形框表示，上面标注系统名称，内部可包含一个或多个用例。

角色和用例之间的关联利用直线表示，组成符号如下：

但是在一般情况下，在用例图中仅仅表示参与者和用例之间的关系，而忽略掉系统的描述。

例如，通过例4，由每个取款者抽象出系统角色“客户”，利用关联将角色和用例连接起来，就构成了用例图。

下面给出例3和例4的用例图。

思考：

1、咖啡机有煮咖啡的功能，我们如何表示这种关系？

这个描述中存在哪些角色？

哪些用例？

2、小王利用咖啡机煮咖啡，这种关系又如何表示？

这个描述中又存在哪些角色？

哪些用例？

注：

要说明用例是某角色所拥有功能的直接表现形式。

例5：

某保险商务系统，客户可以签订保险单，保险销售员可以鉴定保险单，还可以进行销售统计和客户统计。

这段描述的用例图表示为：

例6：

用户登录购物网站，浏览商品，选择商品下订单并支付，请识别该过程中的参与者和用例，并画出用例图。

分析参与者：

用户

分析用例：

登录，浏览商品，下订单，支付

画用例图：

拓展练习1：

教务管理系统中，学生转学这个过程中牵涉到了学生记录的增加、修改和删除，请确定学生转学这个过程的用例。

拓展练习2：

某学校网上选课系统。

其中管理员通过系统管理界面进入系统，建立本学期要开设的各种课程，将课程信息保存到数据库中，并可以对课程进行改动和删除。

学生通过客户机浏览器进入系统，选择课程：

可以查询课程，选择课程，支付课程费用。

请分析此系统中存在的角色和用例，并画出用例图。

6.3.2用例描述

用例描述（也称为用例规约）主要是描述