用例模型——绘制系统顺序框图(SSD)

UML用例建模解析刘伟UML（统一建模语言）是当前软件开发中使用最为广泛的建模技术之一，通过使用UML 可以构造软件系统的需求模型（用例模型）、静态模型、动态模型和架构模型。

UML通过图形和文字符号来描述一个系统，它是绘制软件蓝图的标准语言。

熟练掌握UML建模技术是一个优秀的软件从业人员所必备的基本技能之一，越来越多的软件企业在招聘中也需要应聘者具备一定的UML知识基础和实践经验。

作为UML的初学者，很多人也在尝试使用UML中的图形来描述一个软件系统，构造一个软件系统的蓝图。

然而，在使用UML的过程中，一部分人并没有深入理解这些图的作用，以及这些图在绘制过程中的一些技巧。

我将陆续通过几篇文章来帮助大家更快更好地学习UML，在软件项目中合理使用UML来提高软件开发效率并规范软件开发流程。

在本文中我将结合库存管理系统来深入浅出地讲述UML建模中的第一个模型——需求模型的构造，即用例建模，包括如何绘制规范的用例图、如何编写简洁而又清晰的用例文档、以及怎样通过用例图和用例文档来构造软件系统的需求模型。

在UML中，需求模型又称为用例模型，它主要用于描述系统的功能性需求，即软件可以实现的功能，如登录、注册、入库、出库、查看库存报表、增加员工信息等。

常规的用例建模一般包括两个组成部分：绘制用例图和编写用例文档。

1. 绘制用例图用例图是UML中比较简单的一种图形，它包含两个主要组成元素，分别是执行者(Actor)和用例(Use Case)。

执行者又称为参与者或角色，用例又称为用况或案例。

在用例图中，执行者用一个“小人”符号表示，用例用一个“椭圆”符号表示，因此用例图又有一个名字为“小人椭圆图”。

最简单的用例图如下：入库仓库管理员在该用例图中，“仓库管理员”表示执行者，“入库”表示一个用例，即系统的一个功能。

执行者是指直接和系统交互的一类事物，执行者主要有如下三类：(1) 直接使用系统的人，如使用一个库存管理系统的仓库管理员、仓储部经理等用户，仓库管理员可以通过系统进行入库和出库操作，仓储部经理可以通过系统查看各种报表，如库存报表、财务报表等；(2) 与该系统相关的其他系统，如在库存管理系统中如果涉及到付款操作，需要使用另一个软件——支付系统，此时支付系统就是库存管理的执行者之一；(3) 自动发生的事件，如时间、温度等自动事件，如果库存管理系统要求每晚零点执行一个数据汇总操作，此时时间就成为该操作的执行者。

需求中如何画用例图UML用例图用例图主要用来图示化系统的主事件流程，它主要用来描述客户的需求，即用户希望系统具备的完成一定功能的动作，通俗地理解用例就是软件的功能模块，所以是设计系统分析阶段的起点，设计人员根据客户的需求来创建和解释用例图，用来描述软件应具备哪些功能模块以及这些模块之间的调用关系，用例图包含了用例和参与者，用例之间用关联来连接以求把系统的整个结构和功能反映给非技术人员（通常是软件的用户），对应的是软件的结构和功能分解。

用例是从系统外部可见的行为，是系统为某一个或几个参与者（Actor）提供的一段完整的服务。

从原则上来讲，用例之间都是独立、并列的，它们之间并不存在着包含从属关系。

但是为了体现一些用例之间的业务关系，提高可维护性和一致性，用例之间可以抽象出包含(include)、扩展(extend)和泛(generalization)几种关系。

共性：都是从现有的用例中抽取出公共的那部分信息，作为一个单独的用例，然后通后过不同的方法来重用这个公共的用例，以减少模型维护的工作量。

1、包含(include)包含关系：使用包含（Inclusion）用例来封装一组跨越多个用例的相似动作（行为片断），以便多个基（Base）用例复用。

基用例控制与包含用例的关系，以及被包含用例的事件流是否会插入到基用例的事件流中。

基用例可以依赖包含用例执行的结果，但是双方都不能访问对方的属性。

包含关系对典型的应用就是复用，也就是定义中说的情景。

但是有时当某用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例；相反，用例划分太细时，也可以抽象出一个基用例，来包含这些细颗粒的用例。

这种情况类似于在过程设计语言中，将程序的某一段算法封装成一个子过程，然后再从主程序中调用这一子过程。

例如：业务中，总是存在着维护某某信息的功能，如果将它作为一个用例，那新建、编辑以及修改都要在用例详述中描述，过于复杂；如果分成新建用例、编辑用例和删除用例，则划分太细。

第一章1、什么是分析与设计？1、分析强调对问题和需求的调查研究2、设计强调的是满足需求的概念上的解决方案2、什么是面向对象分析与设计？1、在面向对象分析过程中，强调的是在问题领域内发现和描述对象（或概念）2、在面对对象设计过程中，强调的是定义软件对象以及它们如何协作以实现需求。

3、简单示例：1、定义用例（use case）需求分析可能包括人们如何使用应用的情节或场景，这些情节或场景可以被编写成用例。

2、定义领域模型（domain model）面向对象分析的结果可以表示为领域模型，在领域模型中展示重要的领域概念或对象。

需要注意的是，领域模型并不是对软件对象的描述，它使真实世界领域中的概念和想象可视化。

（也被称为概念领域模型—conceptual object model）3、定义交互图关注的是软件对象的定义—它们的职责和协作。

顺序图（sequence diagram）是描述协作的常见方法。

它展示对象之间的信息流，和由消息引起的方法调用。

4、定义设计类图除了在交互图中显示对象协作的动态视图外，还可以用设计类图（design class diagram）来有效的表示类定义的静态视图。

这样可以描述类的属性和方法。

与领域模型表示的是真实世界的类，设计类图表示的是软件类要注意的是，尽管设计类图不同于领域模型，但是其中的某些类名和内容还是相似的。

第二章1、什么是UML？统一建模语言（UML）是描述、构造和文档化系统制品的可视化语言。

UML表示法的基础是UML元模型，它描述建模元素的语义，UML元模型对模型驱动架构（Model Driven Architecture, MDA）CASE工具供应商具有影响。

开发者并不需要对其进行学习。

2、三种UML应用方式1、UML作为草图—非正式的、不完整的图，借助可视化语言的功能，用于探讨问题或解决方案空间的负责部分。

2、UML作为蓝图—相对详细的设计图。

用于：①逆向工程；②代码生成。

UML建模风格之顺序图和合作图、活动图一样，UML顺序图( Rumbaugh、Jacobson、和booch, 1999)是一种动态建模方法。

UML顺序图一般用于：1.确认和丰富一个使用情境的逻辑。

一个使用情境就是系统潜在的使用方式的描述，也就是它的名称所要描述的。

一个使用情境的逻辑可能是一个用例的一部分，或是一条备选线路；一个贯穿单个用例的完整流程，例如动作基本过程的逻辑描述，或是动作的基本过程的一部分再加上一个或多个的备用情境的逻辑描述。

或是包含在几个用例中的流程，例如一个学生注册入学之后，立即就要在三个班级注册。

2.研究你的设计，因为它们为你提供了一种方式，你可以使用这种方式来可视化的调用类定义的操作。

3.检测面向对象的设计中的瓶颈。

通过观察什么消息被发送给一个对象，以及通过概略的观察运行被调用的方法需要花费多长时间，你很快就能了解那里的设计需要变化，以达到在系统内部平衡负荷的目的。

实际上某些CASE工具甚至能够让你模拟软件这些特征。

4.使你能够感觉到你的应用程序的那个类将会变得复杂的，这是个信号，意味着你需要为那些类画状态图了。

指南∶通用准则尽力保持消息的顺序从左到右排列将分类器分层用和你的用例图一致的名称命名角色用和你的类图一致的名称命名类一个角色的名称可以和类的名称相同包含一个逻辑的叙述性描述在图的最左边放置初始的角色在图的最左边放置人和组织角色在图的最右边放置系统角色只在合适的时候才建模对象的Destruction分类器的原则当你在消息上引用对象时要命名他们当存在部分相同的类型时需要命名对象一致地应用文本版型少量地应用可视化的版型集中在关键的交互消息的原则把消息名放在箭头旁边直接创建对象为软件消息使用操作符号为涉及人和组织角色的消息使用叙述性文字推荐使用参数名称，而不是参数类型为参数占位符注明类型类的消息实现为静态操作为用例调用使用<<include>>版型返回值的原则当返回值非常明显时就不要对返回值建模只有当你需要在别处引用返回值时才对返回值建模在箭头旁边调整返回值返回值建模为方法调用的一部分为返回值占位符注明类型明确的为简单值标明实际值一、通用准则1.尽力保持消息的顺序是从左到右排列的一个顺序图的消息流开始于左上方，消息乙的位置比消息甲低，这意味着消息乙的顺序比消息乙要迟。

用例框圖(UseCase Diagram)簡介用例框圖顯示系統中的用例與角色及其相互關係。

用例是系統提供的高級功能塊，角色是與所建系統交互的物件。

下圖是個用例框圖的例子：用例(UseCase)用例是系統提供的功能塊。

換句話說，用例演示了人們如何使用系統。

下圖表示一個"登錄"的用例：用例之間一般有兩種關係：擴展關係，包含關係。

屬性∙General：常規屬性o a bstract：抽象。

是否是抽象類o c lassifier behavior：類元行為。

指定定義類行為的活動、交互、狀態機。

這些行為詳細定義了類的行為特徵。

o e xtends：繼承。

類的父類。

直接繼承的父類。

o f inal：是否可繼承。

final類不可被繼承。

o f ull name：全名。

包含路徑的全名，如java.util.zip。

o g uid：元素唯一ID。

o m etaclass：元類。

模型元素的元類。

o n ame：名字。

o p rovided interface：提供介面。

即實現的介面。

o r equired interface：需求介面。

即類使用到(Usage依賴)的介面。

o s tereotype：構造型。

可選擇，也可自行輸入。

o s ubject：主題。

選擇用例表達主題。

o v isiblity：可見性。

∙Custom：自定義o t agged value：標記值。

如"query=true"∙Description：描述o d escription：元素的描述資訊∙View：顯示屬性o3D look：是否顯示陰影o a uto resize：是否自動改變元素尺寸。

o b ackground：背景色o f ont：字體o f oreground：前景色o v iew as class：顯示類樣式。

模型導航區快顯功能表∙new：新建：以當前包為命名空間，創建以下元素：o E xtension Point：擴展點∙new diagram：新建框圖。

2.设计模式常⽤的UML图分析（⽤例图、类图与时序图）1-⽤例图概述1. 展现了⼀组⽤例、参与者以及他们之间的关系。

2. ⽤例图从⽤户⾓度描述系统的静态使⽤情况，⽤于建⽴需求模型。

⽤例特征保证⽤例能够正确捕捉功能性需求，判断⽤例是否准确的依据。

1. ⽤例是动宾短语2. ⽤例是相互独⽴的3. ⽤例是由⽤户参与者启动的4. ⽤例要有可观测的执⾏结果5. ⼀个⽤例是⼀个单元参与者 ActorUML中，参与者使⽤⼀个⼩⼈表⽰:1. 参与者为系统外部与系统直接交互的⼈或事务，于系统外部与系统发⽣交互作⽤2. 参与者是⾓⾊⽽不是具体的⼈3. 代表参与者在与系统打交道时所扮演的⾓⾊4. 系统实际运作中，⼀个实际⽤户可能对应系统的多个参与者。

不同⾓⾊也可以只对应⼀个参与者，从⽽代表同⼀参与者的不通实例⽤例 Use Case系统外部可见的⼀个系统功能单元。

系统的功能由系统单元所提供，并通过⼀系列系统单元与⼀个或多个参与者之间交换的消息所表达。

系统单元⽤椭圆表⽰，椭圆中的⽂字简述系统功能:关系 Relationship常见关系类型有关联、泛化、包含和扩展关联 Association表⽰参与者与⽤例之间的通信，任何⼀⽅都可发送或接受消息。

箭头指向：指向消息接收⽅：⼦系统 SubSystem⽤来展⽰系统的⼀部分功能(紧密联系)泛化 Inheritance继承关系，⼦⽤例和⽗⽤例相似，但表现出更特别的⾏为；⼦⽤例将继承⽗⽤例的所有结构、⾏为和关系。

⼦⽤例可以使⽤⽗⽤例的⼀段⾏为，也可以重载它。

⽗⽤例通常是抽象。

箭头指向：指向⽗⽤例2-类图描述系统中的类，以及各个类之间的关系的静态试图。

表⽰类、接⼝以及它们之间的协作关系，⽤于程序设计阶段。

注意:1. 抽象类或抽象⽅法⽤斜体表⽰2. 如果是接⼝，则在类名上⽅加 <<Interface>>3. 字段和⽅法返回值的数据类型⾮必需4. 静态类或静态⽅法加下划线类图实例:类图中的事务及解释如图，类图从上到下分为三部分,分别为类名、属性和操作1. 属性:如果有属性，则每⼀个属性都必须有⼀个名字，另外还可以有其它的描述信息，如可见性、数据类型、缺省值等2. 操作:如果有操作，则每⼀个操作也都有⼀个名字，其它可选的信息包括可见性、参数的名字、参数类型、参数缺省值和操作的返回值的类型等类图中的六种关系1.实现关系 implements (类实现接⼝)⽤空⼼三⾓虚线表⽰2.泛化关系 extends (表⽰⼀般与特殊的关系) is-a⽤空⼼三⾓实线表⽰3.组合关系 (整体与部分的关系) contains-a实⼼菱形实现表⽰eg.有头类、⾝体类与⼈类类三个类，则⼈类类中应包含头类及⾝体类这两个属性，则⼈类类与头类和⾝体的关系即为组合关系。

产品经理简称PM，是指在公司中针对某一项或是某一类的产品进行规划和管理的人员，主要负责产品的研发、制造、营销、渠道等工作。

产品经理是很难定义的一个角色，如果非要一句话定义，那么产品经理是为终端用户服务，负责产品整个生命周期的人。

产品经理需要考虑目标用户特征、竞争产品、产品是否符合公司的业务模式等等诸多因素。

近年来互联网产品经理火热，一起看下为大家精选的互联网产品经理学习文章。

上次介绍了活动图，这次UML 中，另一种流程分析利器——时序图。

以前每次要分析流程，我都会用活动图。

直到有一次，我面对一个业务流程，画活动图，画来画去，总觉得哪里不对，但又表达不出来，感觉如鲠在喉。

后来，我想起时序图，用时序图把流程梳理了一遍，豁然开朗。

原来，用不同的视图去描述同一个流程，能让我们看到自己未曾发现的问题。

就像看足球比赛，在多个不同位置的摄像镜头下，能看到球员更全面的表现。

此后，我用时序图甚至比活动图还多。

那么，它有啥特别之处，居然能替代活动图来分析流程？我们一起来看看。

01 解读时序图时序图，也叫序列图、顺序图，是UML 中常用的动态视图，用于描述多个对象参与实现业务目标时，彼此之间按时间顺序进行交互的过程。

时序图，用来表达对象或角色之间交互的信息传递和时间顺序，特别方便。

每次梳理流程，跟开发沟通，我都会借助它来描述。

绘制时序图，将一个个对象和其交互动作列出来，可以直观反映出，每个对象对其他对象、或其自身做的交互动作，让我们看到业务内部的运作、系统之间的互动，从而搞清楚业务规则、系统逻辑。

在《火球：UML 大战需求分析》一书中，作者总结特别好：“任何复杂的交互，都可以分解为自己与自己、自己与别人、别人与别人的多个简单交互”。

时序图正体现了这种逻辑，所以，它表达交互逻辑时，非常清晰简单。

客户用ATM 取款的时序图作为产品经理，如果我们能掌握这一利器，用来分析业务、定义需求，与开发沟通，定能大大提高效率。

时序图常见的应用场景，是在支付领域。

顺序图的建模步骤1．创建和删除顺序图1.1 创建顺序图新建一个顺序图的方式有两种：1.1.1 在逻辑视图中增加顺序图1）一般情况下，顺序图属于系统的逻辑模型，因此可以使用“Logical View”的右键菜单——〉“New”——〉“Sequence Diagram”，如下图所示：然后输入顺序图的名称，如下图所示：接着双击新增的顺序图名称，开始输入顺序图，如下图所示：1.1.2 在用例视图中增加顺序图顺序图主要是用于对用例的描述，在此种目的下新增顺序图的方式也是有两种：2.1）直接在“Use Case View”下的相应用例上通过右键菜单——〉“New”——〉“Sequence Diagram”菜单项新建一个顺序图，如下图所示：输入顺序图的名称，如下图所示：输入完顺序图的名称后，双击此顺序图的名称开始输入顺序图的内容。

2.2）在用例图中使用用例的属性窗口来新增顺序图。

如下图所示，在用例“浏览课件”的“Specification”属性窗口中的“Diagrams”项目下，通过右键菜单——〉“Insert Sequence Diagram”，输入顺序图的名称，如下图所示：双击此顺序图名称，进入顺序图的编辑界面。

1.2 删除顺序图不管是在逻辑视图（Logical View）还是在用例视图（Use Case View），删除顺序图的方式都是一样的。

都是选中需要删除的顺序图，右键菜单——〉“Delete”，即可直接删除，如下图所示。

注意，在Rational Rose2003环境下，所有的删除操作都是没有提示的。

1.3 修改顺序图的名称不管是在逻辑视图（Logical View）还是在用例视图（Use Case View），修改顺序图名称的方式都是一样的。

都是选中需要修改名称的顺序图，右键菜单——〉“Rename”，如下图所示：2．增加和删除对象2.1 增加对象在顺序图中，增加对象的方式主要有两种：2.1.1 使用原有的模型元素作为顺序图的对象使用拖放的方式把原有的模型元素作为顺序图的对象，如下图所示：注意：可以被拖放的模型元素有参与者（Actor）和类（Class）这两种模型元素。

用例图一般建模流程下载温馨提示:该文档是我店铺精心编制而成，希望大家下载以后，能够帮助大家解决实际的问题。

文档下载后可定制随意修改，请根据实际需要进行相应的调整和使用，谢谢!并且，本店铺为大家提供各种各样类型的实用资料，如教育随笔、日记赏析、句子摘抄、古诗大全、经典美文、话题作文、工作总结、词语解析、文案摘录、其他资料等等，如想了解不同资料格式和写法，敬请关注!Download tips: This document is carefully compiled by theeditor. I hope that after you download them,they can help yousolve practical problems. The document can be customized andmodified after downloading,please adjust and use it according toactual needs, thank you!In addition, our shop provides you with various types ofpractical materials,such as educational essays, diaryappreciation,sentence excerpts,ancient poems,classic articles,topic composition,work summary,word parsing,copy excerpts,other materials and so on,want to know different data formats andwriting methods,please pay attention!用例图是一种用于描述系统功能和用户与系统之间交互的图形化工具。

以下是用例图的一般建模流程：1. 确定系统边界和范围：明确系统的边界和范围，包括系统的主要功能和与外部系统的交互。

软件工程中的图软件工程导论中一般把软件的开发分为八个阶段：１.问题定义２.可行性研究３. 需求分析４. 总体设计（概要设计）５. 详细设计６. 编码和单元测试７. 综合测试８. 软件维护下面我们就说说各个阶段中与图的难解难分。

１. 问题定义问题定义阶段主要是根据用户的需求来定义用户需要解决的问题，用户要实现哪些功能。

２. 可行性研究可行性研究阶段就是看是否有一种使其在最小的代价，尽可能短的时间内，利益最大化的情况下解决问题的方案。

这个阶段的分析主要涉及以下几个图形工具。

2.1系统流程图系统流程图是描述系统物理模型的一种传统工具。

它是表达数据在系统各部件之间流动的情况，而不是对数据加工处理的控制过程，它是物理数据流图而不是程序流程图。

系统流程图形象的呈现了软件的功能，即使不懂软件的人也可以轻松的看懂，可以说它是软件设计师与用户之间沟通、交流的有效工具。

2.2数据流图数据流图是从数据传递和加工角度，以图形方式来表达系统的逻辑功能、数据在系统内部的逻辑流向和逻辑变换过程，是结构化系统分析方法的主要表达工具及用于表示软件模型的一种图示方法。

如果说系统流程图能让用户更好的明白系统的功能，那么数据流图则让用户更加明白系统的工作原理。

数据流图的基本符号：数据流图的使用例子：2.3数据字典数据字典就是数据的信息的集合，也可以说就是对上面提到的数据流图中的所有元素的定义的集合。

数据字典的主要作用就是在软件的分析与设计阶段方便我们查阅不甚了解的数据的描述信息。

３. 需求分析需求分析阶段主要确定系统必须做什么。

比如用户对系统的要求，确定目标系统所有的功能，确定系统运行的硬件和软件环境，系统性能要求，出错处理要求，接口需求，验证软件需求等等。

3.1 E-R图E-r 图的主要作用就是把用户的数据要求用可视化的图形呈现出来。

3.2状态转换图状态转换图说白了就是系统的行为建模，就是通过描述系统的状态以及引起状态变化的事件来表示系统的行为，将系统运行时详细的状态变化呈现给用户。