UML培训教程7-用例图实例
- 格式:ppt
- 大小:938.50 KB
- 文档页数:21
UML用例图用例描述详解描述用例规约应该避免这样一种误解――认为由参与者和用例构成的用例图就是用例模型,用例图只是在总体上大致描述了系统所能提供的各种服务,让我们对于系统的功能有一个总体的认识。
除此之外,我们还需要描述每一个有例的详细信息,这些信息包含在用例规约中,用例模型是由用例图和每一个用例的详细描述――用例规约所组成的。
RUP中提供了用例规约的模板,每一个用例的用例规约都应该包含以下内容:•简要说明(Brief Description)简要介绍该用例的作用和目的。
•事件流(Flow of Event)包括基本流和备选流,事件流应该表示出所有的场景。
•用例场景(Use-Case Scenario)包括成功场景和失败场景,场景主要是由基本流和备选流组合而成的。
•特殊需求(Special Requirement)描述与该用例相关的非功能性需求(包括性能、可靠性、可用性和可扩展性等)和设计约束(所使用的操作系统、开发工具等)。
•前置条件(Pre-Condition)执行用例之前系统必须所处的状态。
•后置条件(Post-Condition)用例执行完毕后系统可能处于的一组状态。
用例规约基本上是用文本方式来表述的,为了更加清晰地描述事件流,也可以选择使用状态图、活动图或序列图来辅助说明。
只要有助于表达的简洁明了,就可以在用例中任意粘贴用户界面和流程的图形化显示方式,或是其他图形。
如活动图有助于描述复杂的决策流程,状态转移图有助于描述与状态相关的系统行为,序列图适合于描述基于时间顺序的消息传递。
基本流基本流描述的是该用例最正常的一种场景,在基本流中系统执行一系列活动步骤来响应参与者提出的服务请求。
我们建议用以下格式来描述基本流:1) 每一个步骤都需要用数字编号以清楚地标明步骤的先后顺序。
2) 用一句简短的标题来概括每一步骤的主要内容,这样阅读者可以通过浏览标题来快速地了解用例的主要步骤。
在用例建模的早期,我们也只需要描述到事件流步骤标题这一层,以免过早地陷入到用例描述的细节中去。
UML各种图例——用例图、类图、状态图、包图、协作图、顺序图面向对象的问题的处理的关键是建模问题.建模可以把在复杂世界的许多重要的细节给抽象出.许多建模工具封装了UML(也就是Unified Modeling Language™),这篇课程的目的是展示出UML的精彩之处.UML中有九种建模的图标,即:∙用例图∙类图∙对象图∙顺序图∙协作图∙状态图∙活动图∙组件图∙配置图本课程中的某些部分包含了这些图的细节信息的页面链接.而且每个部分都有一个小问题,测试一下你对这个部分的理解.为什么UML很重要?为了回答这个问题,我们看看建筑行业.设计师设计出房子.施工人员使用这个设计来建造房子.建筑越复杂,设计师和施工人员之间的交流就越重要.蓝图就成为了这个行业中的设计师和施工人员的必修课.写软件就好像建造建筑物一样.系统越复杂,参与编写与配置软件的人员之间的交流也就越重要.在过去十年里UML就成为分析师,设计师和程序员之间的“建筑蓝图”.现在它已经成为了软件行业的一部分了.UML提供了分析师,设计师和程序员之间在软件设计时的通用语言.UML被应用到面向对象的问题的解决上.想要学习UML必须熟悉面向对象解决问题的根本原则――都是从模型的建造开始的.一个模型model就是根本问题的抽象.域domain就是问题所处的真实世界.模型是由对象objects组成的,它们之间通过相互发送消息messages来相互作用的.记住把一个对象想象成“活着的”.对象有他们知道的事(属性attributes)和他们可以做的事(行为或操作behaviors or operations).对象的属性的值决定了它的状态state.类Classes是对象的“蓝图”.一个类在一个单独的实体中封装了属性(数据)和行为(方法或函数).对象是类的实例instances.用例图用例图Use case diagrams描述了作为一个外部的观察者的视角对系统的印象.强调这个系统是什么而不是这个系统怎么工作.用例图与情节紧紧相关的.情节scenario是指当某个人与系统进行互动时发生的情况.下面是一个医院门诊部的情节.“一个病人打电话给门诊部预约一年一次的身体检查.接待员找出在预约记录本上找出最近的没有预约过的时间,并记上那个时间的预约记录.”用例Use case是为了完成一个工作或者达到一个目的的一系列情节的总和.角色actor是发动与这个工作有关的事件的人或者事情.角色简单的扮演着人或者对象的作用.下面的图是一个门诊部Make Appointment用例.角色是病人.角色与用例的联系是通讯联系communication association(或简称通讯communication)角色是人状的图标,用例是一个椭圆,通讯是连接角色和用例的线.一个用例图是角色,用例,和它们之间的联系的集合.我们已经把Make Appointment作为一个含有四个角色和四个用例的图的一部分.注意一个单独的用例可以有多个角色.用例图在三个领域很有作用.∙决定特征(需求).当系统已经分析好并且设计成型时,新的用例产生新的需求∙客户通讯.使用用例图很容易表示开发者与客户之间的联系.∙产生测试用例.一个用例的情节可能产生这些情节的一批测试用例.类图类图Class diagram通过显示出系统的类以及这些类之间的关系来表示系统.类图是静态的-它们显示出什么可以产生影响但不会告诉你什么时候产生影响.下面是一个顾客从零售商处预定商品的模型的类图.中心的类是Order.连接它的是购买货物的Customer和Payment.Payment有三种形式:Cash,Check,或者Credit.订单包括OrderDetails(line item),每个这种类都连着Item.每个类图包括类,关联和多样性表示.方向性和角色是为了使图示得更清楚时可选的项目.包和对象图为了简单地表示出复杂的类图,可以把类组合成包packages.一个包是UML上有逻辑关系的元件的集合.下面这个图是是一个把类组合成包的一个商业模型. dependencies关系.如果另一个的包B改变可能会导致一个包A改变,则包A依赖包B.包是用一个在上方带有小标签的矩形表示的.包名写在标签上或者在矩形里面.点化线箭头表示依赖对象图Object diagrams用来表示类的实例.他们在解释复杂关系的细小问题时(特别是递归关系时)很有用.这个类图示一个大学的Department可以包括其他很多的Departments.这个对象图示上面类图的实例.用了很多具体的例子.UML中实例名带有下划线.只要意思清楚,类或实例名可以在对象图中被省略.每个类图的矩形对应了一个单独的实例.实例名称中所强调的UML图表.类或实例的名称可能是省略对象图表只要图的意义仍然是明确的.顺序图类图和对象图是静态模型的视图.交互图是动态的.他们描述了对象间的交互作用.顺序图将交互关系表示为一个二维图.纵向是时间轴,时间沿竖线向下延伸.横向轴代表了在协作中各独立对象的类元角色.类元角色用生命线表示.当对象存在时,角色用一条虚线表示,当对象的过程处于激活状态时,生命线是一个双道线.消息用从一个对象的生命线到另一个对象生命线的箭头表示.箭头以时间顺序在图中从上到下排列.协作图协作图也是互动的图表.他们像序列图一样也传递相同的信息,但他们不关心什么时候消息被传递,只关心对象的角色.在序列图中,对象的角色放在上面而消息则是连接线.对象角色矩形上标有类或对象名(或者都有).类名前面有个冒号(:).协作图的每个消息都有一个序列号.顶层消息的数字是1.同一个等级的消息(也就是同一个调用中的消息)有同样的数字前缀,再根据他们出现的顺序增加一个后缀1,2等等.状态图对象拥有行为和状态.对象的状态是由对象当前的行动和条件决定的.状态图statechart diagram显示出了对象可能的状态以及由状态改变而导致的转移.我们的模型例图建立了一个银行的在线登录系统.登录过程包括输入合法的密码和个人账号,再提交给系统验证信息.登录系统可以被划分为四种不重叠的状态:Getting SSN, Getting PIN, Validating, 以及Rejecting.每个状态都有一套完整的转移transitions来决定状态的顺序.状态是用圆角矩形来表示的.转移则是使用带箭头的连线表示.触发转移的事件或者条件写在箭头的旁边.我们的图上有两个自转移.一个是在Getting SSN,另一个则在上Getting PIN.初始状态(黑色圆圈)是开始动作的虚拟开始.结束状态也是动作的虚拟结束.事件或条件触发动作时用(/动作)表示.当进入Validating状态时,对象并不等外部事件触发转移.取而代之,它产生一个动作.动作的结果决定了下一步的状态.活动图活动图activity diagram是一个很特别的流程图.活动图和状态图之间是有关系的.状态图把焦点集中在过程中的对象身上,而活动图则集中在一个单独过程动作流程.活动图告诉了我们活动之间的依赖关系.对我们的例子来说,我们使用如下的过程.“通过ATM来取钱.”这个活动有三个类Customer, ATM和Bank.整个过程从黑色圆圈开始到黑白的同心圆结束.活动用圆角矩形表示.。
UML中的用例(Use Case)概念分析及实例文/登峰2005-02-25在UML中use case似乎最簡單的,用例建模的最主要功能就是用来表达系统的功能性需求或行为,依我的理解用例建模可分为用例图和用例描述。
用例图由参与者(Actor)、用例(Use Case)、系统边界、箭头组成,用画图的方法来完成。
用例描述用来详细描述用例图中每个用例,用文本文档来完成,以及由箭头所组成的各种关系,包括泛化,包含,扩展等。
本文准备向大家介绍以下内容,所有图示均用PowerDesigner所画.◆用况◆参与者◆泛化◆<<use>>◆<<include>>◆<<extend>>◆用例描述1.用况(use case)图1用况图是对一组动作序列(其中包括它的变体)的描述,系统执行该动作为执行此动作的参与者产生一个可观察的结果值。
比如你使用计算器,这里可以把计算器看作为用况,参与者是登峰,登峰按了3+3(用况执行的序列),计算机器返回一个结果6。
2.参与者(Actor)参与者不是特指人,是指系统以外的,在使用系统或与系统交互中所扮演的角色。
因此参与者可以是人,可以是事物,也可以是时间或其他系统等等。
还有一点要注意的是,参与者不是指人或事物本身,而是表示人或事物当时所扮演的角色。
比如小明是图书馆的管理员,他参与图书馆管理系统的交互,这时他既可以作为管理员这个角色参与管理,也可以作为借书者向图书馆借书,在这里小明扮演了两个角色,是两个不同的参与者。
参与者在画图中用简笔人物画来表示,人物下面附上参与者的名称。
3.泛化泛化和类中的泛化概念是一样的,子用况继承父用况的行为和含义,还可以增加或覆盖父用况的行为;子用况可以出现在任何父用况出现的位置(父和子均有具体的实例)。
下面给出两种图示来说明泛化的概念和含义图2含义继承图3行为继承4.<<user>><<use>>: 其关系非常象一个函数调用或一个子过程以这种方式使用的用例称为抽象用例因为它不能单独存在而必须被其它用例使用,请看下图图4使用<<use>>示例5.<<include>>怎么解释这个定义呢?还是说明一下它的功能吧,<<include>>可以把几个用例的公共步骤分离出来成为一个单独的被包含用例。
UML用例图的用例间关系处理技巧与案例分享在软件开发过程中,UML(统一建模语言)用例图是一种常用的工具,用于描述系统的功能需求和用户行为。
用例图可以帮助开发团队更好地理解系统的功能,并且在需求分析和设计阶段提供指导。
然而,用例图中的用例之间的关系处理是一个关键问题,本文将介绍一些处理这些关系的技巧,并分享一些实际案例。
1. 泛化关系(Generalization)泛化关系是用例图中的一种重要关系,用于表示两个用例之间的继承关系。
通过泛化关系,可以将通用的用例抽象为父用例,然后通过继承关系衍生出具体的子用例。
这样可以减少冗余的用例描述,提高模型的可读性和可维护性。
例如,在一个电商系统中,可以定义一个父用例“用户管理”,然后通过泛化关系创建两个子用例“注册用户”和“登录用户”。
这样,父用例中的共同行为可以在子用例中继承并具体化。
2. 包含关系(Include)包含关系用于表示一个用例包含了另一个用例的行为。
通过包含关系,可以将一个用例的行为模块化,并在其他用例中重复使用。
这样可以提高模型的可重用性和可维护性。
例如,在一个银行系统中,可以定义一个用例“转账”,然后通过包含关系将“验证账户”和“更新账户余额”两个用例包含在“转账”用例中。
这样,其他用例中需要进行账户验证和更新余额的地方可以直接调用“转账”用例中的这两个子用例。
3. 扩展关系(Extend)扩展关系用于表示一个用例可以在另一个用例的基础上进行扩展。
通过扩展关系,可以在不修改原有用例的情况下,为系统添加新的功能。
例如,在一个学生管理系统中,可以定义一个用例“学生信息管理”,然后通过扩展关系将“添加学生信息”和“修改学生信息”两个用例扩展到“学生信息管理”用例中。
这样,当系统需要添加新的功能,比如“删除学生信息”,可以通过扩展关系在“学生信息管理”用例中添加该功能。
4. 关联关系(Association)关联关系用于表示两个用例之间的关联。
UML的使用教程与实例分享UML(统一建模语言)是一种用于软件开发过程中进行建模的标准化语言。
它提供了一种图形化的方式来描述软件系统的结构、行为和交互。
在软件开发过程中,使用UML可以帮助开发团队更好地理解和沟通需求,设计和实现高质量的软件系统。
本文将介绍UML的基本概念和常用图表,并通过实例分享来帮助读者更好地理解和应用UML。
1. UML的基本概念UML由一系列图表组成,每种图表都用于描述软件系统的不同方面。
常用的UML图表包括用例图、类图、时序图、活动图等。
用例图用于描述系统的功能需求,类图用于描述系统的静态结构,时序图用于描述系统的动态行为,活动图用于描述系统的业务流程。
了解这些基本概念是使用UML的前提。
2. 用例图用例图是UML中最常用的图表之一,用于描述系统的功能需求。
用例图由参与者(Actor)和用例(Use Case)组成。
参与者是系统的外部角色,可以是人、其他系统或设备等。
用例是系统的功能需求,描述了系统与参与者之间的交互。
通过用例图,可以清晰地了解系统的功能和参与者之间的关系。
3. 类图类图是UML中描述系统静态结构的图表。
类图由类、属性和方法组成。
类是对具有相同属性和行为的对象的抽象,属性是类的特征,方法是类的行为。
通过类图,可以清晰地了解系统中的各个类及其之间的关系。
类图还可以用于生成代码和数据库设计。
4. 时序图时序图是UML中描述系统动态行为的图表。
时序图描述了系统中对象之间的交互和消息传递顺序。
时序图由对象、生命线、消息和控制流程组成。
对象是系统中的实体,生命线表示对象的生命周期,消息表示对象之间的交互,控制流程表示对象之间的控制流程。
通过时序图,可以清晰地了解系统中对象之间的交互过程。
5. 活动图活动图是UML中描述系统业务流程的图表。
活动图由活动、决策、并行和合并等元素组成。
活动表示系统中的业务流程,决策表示系统中的判断条件,并行表示系统中的并发流程,合并表示系统中的流程合并。
初学UML之-------用例图分类:UML Modeling2007-10-16 04:37 58803人阅读评论(48) 收藏举报一.UML简介UML(统一建模语言,Unified Modeling Language)是一种定义良好、易于表达、功能强大且普遍适用的可视化建模语言。
它融入了软件工程领域的新思想、新方法和新技术。
它的作用域不限于支持面向对象的分析与设计,还支持从需求分析开始的软件开发的全过程。
在系统分析阶段,我们一般用UML来画很多图,主要包括用例图、状态图、类图、活动图、序列图、协作图、构建图、配置图等等,要画哪些图要根据具体情况而定。
其实简单的理解,也是个人的理解,UML的作用就是用很多图从静态和动态方面来全面描述我们将要开发的系统。
二.用例建模简介用例建模是UML建模的一部分,它也是UML里最基础的部分。
用例建模的最主要功能就是用来表达系统的功能性需求或行为。
依我的理解用例建模可分为用例图和用例描述。
用例图由参与者(Actor)、用例(Use Case)、系统边界、箭头组成,用画图的方法来完成。
用例描述用来详细描述用例图中每个用例,用文本文档来完成。
1.用例图参与者不是特指人,是指系统以外的,在使用系统或与系统交互中所扮演的角色。
因此参与者可以是人,可以是事物,也可以是时间或其他系统等等。
还有一点要注意的是,参与者不是指人或事物本身,而是表示人或事物当时所扮演的角色。
比如小明是图书馆的管理员,他参与图书馆管理系统的交互,这时他既可以作为管理员这个角色参与管理,也可以作为借书者向图书馆借书,在这里小明扮演了两个角色,是两个不同的参与者。
参与者在画图中用简笔人物画来表示,人物下面附上参与者的名称。
用例是对包括变量在内的一组动作序列的描述,系统执行这些动作,并产生传递特定参与者的价值的可观察结果。
这是UML对用例的正式定义,对我们初学者可能有点难懂。
我们可以这样去理解,用例是参与者想要系统做的事情。
1.1跟我学统一建模语言UML——UML用例图及在项目中的应用示例1.1.1UML用例图及在项目中的应用示例1、什么是用例图(1)用例图在面向对象需求分析方法中,通常使用用例(Use Case)来获取软件系统的需求。
Use Case通过描述“系统”和“活动者”之间的交互状况来描述软件系统的行为。
通过分解系统目标,Use Case描述活动者为了实现这些目标而执行的所有步骤。
(2)为什么要采用用例图来描述需求用例图是一种图形化的工具,它用简单的图形元素表示出系统的参与者、用例以及它们之间的联系。
通过用例图能够较好地避免了表达的歧义性,便于用户和系统开发人员理解系统的需求,取得共识。
(3)用例图中的参与者和用例之间的通信参与者和用例之间的使用关系,在用例图中表示为一个带箭头的直线。
如下为某项目中的用例图示例:(4)用例图的主要作用1)利用用例图可以实现从用户角度来描述系统所应该具有的功能,同时并能够指出各功能的操作者;也能够显示出与软件系统进行交互的外部参与者及其使用方式。
2)通过用例图可以表示正在构造的新系统应该具有什么的功能,同时对已经构造完毕的系统,则反映了系统能够完成什么样的功能注意:1)用例内容描述包含了定义系统实际需求和功能的重要信息。
2)除了可以用用例以外,用户还可以选择另一种方式:绘制活动图3)然而,记住以下这一点是很重要的:用例应该便于与最终用户沟通,如果采用比较正式的结构,如活动图,可能会使人们不习惯对用例的内容进行解释,从而造成沟通上的不便。
(5)用例图的组成元素在一个UML的用例图中,一般主要包含有系统边界(有的UML工具软件部创建出系统边界线)、参与者、用例和用例关系(通信、使用和扩展等三种形式)。
2、应用Use Case方法最主要的优点(1)在于它是用户导向的用户可以根据自己所对应的Use Case来不断细化软件系统项目的需求。
此外,使用Use Case还可以方便地得到软件系统功能的测试用例。