UML的种图例的定义用途、画法总结
3、UML的9种图分类及运用
3、UML的9种图分类及运用UML中的图可以分成两大类·结构图·行为图UML结构图UML结构图表示系统的静态方面，描述系统的主要结构因此而稳定的那部分，静态结构图主要包括·类图·对象图·组件图·部署图UML类图·类图描述系统中的类，以及各个类之间的关系，类图能够让我们在编码前对系统有个全面的认识。
·类图是一种静态模型，类图代表面向对象系统，类图其他图定义的基础。
·哪里需要用类图是一个静态图，描述一个系统的静态视图，用于前期部署UML对象图·对象图与类图类似，它是类图的实例化，显示类的多个实例化，不是实际的类，描述对象间的关系，用来建立系统原型。
·对象图显示某一时刻对象和对象间的关系·类图代表整个系统模型的抽象，对象图代表系统中某一时刻某一部分的抽象·哪里需要用运行的系统某一时刻的快照•UML组件图•·组件图用来描述系统的物理结构及相互间的关系，模型化和文档化了一个系统的架构·构件可以是一个文件，产品，可执行脚本，库等·组件图= 构件（Component）+接口（Interface）+关系（Relationship）+端口（Port）+连接器（Connector）·哪里需要用架构师在建立项目初期就要建立的图UML部署图·部署图用来建模系统的物理部署，如计算机和设备，及它们之间的关联关系·部署图的使用者为开发人员，系统集成人员和测试人员·部署图由节点以及节点之间的关系组成·哪里需要用主要用于系统工程师UML行为图行为图属于系统的动态部分，另一部分是系统的结构图。
行为图捕捉系统的静态方面。
UML中的行为图主要包括：·用例图·时序图·协作图·状态图·活动图UML用例图·用例图描述角色以及角色与用例之间的连接关系。
浅谈UML中常用的几种图
浅谈UML中常用的几种图1 UML简介2 UML常见图分类3 用况图（用例）4 类图简单类图使用举例5 其他辅助用图●时序图(顺序图)●协作图（Collaboration Diagram/communication Diagram）/通信图●状态图●活动图(Activity Diagram)6 组件图(ComponentDiagram)、配置图(Deployment Diagram)1 UML简介统一建模语言（Unified Modeling Language，UML）又称标准建模语言，是始于1997年的一个OMG标准，它是一个支持模型化和软件系统开发的图形化语言，为软件开发的所有阶段提供模型化和可视化支持，包括由需求分析到规格，到构造和配置。
‘UML感兴趣的可以阅读UML 1规范，包含了UML 的所有知识内容。
注：OMG, Object Management Group 对象管理组织2 UML常见图分类UML从考虑系统的不同角度出发，定义了用况图、类图、对象图、包图、状态图、活动图、序列图、通信图、构件图、部署图等10种图。
分类：面向对象动态建模，用于建立行为的实体间行为交互的四种图：状态图(Stage Diagram)，序列图(Sequence Diagram)，协作图(Communication Diagram)，活动图(Activity Diagram) 。
“序列图”与“协作图”表述的是相似的消息，“活动图”是“状态图”的一种。
•静态结构图Static Structure Diagram•类图Class Diagram•对象图Object Diagram•用况图Use Case Diagram•交互图Interaction Diagram•顺序图Sequence Diagram•协作图Collaboration Diagram•状态图State chart Diagrams•活动图Activity Diagrams•实现图Implementation Diagrams•构件图Component Diagram•部署图Deployment Diagram3 用况图（用例）用例图，展现了一组用例、参与者（actor）以及它们之间的关系。
UML各种图例齐全—用例图、类图、状态图、包图、协作图、顺序图详细说明画法和功能
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.UML类的符号是一个被划分成三块的方框：类名，属性，和操作.抽象类的名字，像Payment是斜体的.类之间的关系是连接线.类图有三种关系.关联association－表示两种类的实例间的关系.如果一个类的实例必须要用另一个类的实例才能完成工作时就要用关联.在图中，关联用两个类之间的连线表示.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用例图的基本概念
UML的用途
需求分析
UML可以帮助开发人员更好地理 解客户需求，通过用例图等工具 将客户需求转化为可执行的用例。
系统设计
UML可以帮助开发人员在系统设 计阶段进行系统架构和组件的设 计，通过类图、时序图等工具进 行系统的分析和设计。
05
案例分析
案例一：简单登录系统用例图分析
总结词：简单明了
详细描述：简单登录系统通常包括用户名和密码输入、验证和登录成功或失败的反馈等基本功能。在 UML用例图中，可以清晰地表示出系统的主要功能和参与者的角色。
案例二：网上购物系统用例图分析
总结词：复杂多样
详细描述：网上购物系统涉及到多个参与者，如顾客、管理员和供应商等，以及多种复杂的业务功能，如商品展示、购物车 管理、订单处理和支付等。在UML用例图中，需要对各个功能进行详细的描述和分类，以便更好地理解系统的结构和功能。
用例图在系统设计中的应用
架构设计
用例图可以用于指导系统的架构设计，通过分析用例之间 的关系和交互，设计系统的组件和模块结构。
01
接口设计
用例图可以帮助设计系统组件之间的接 口，明确组件之间的输入输出关系和交 互协议。
02
03
系统流程设计
用例图可以用于描述系统的流程，通 过分析用例的执行顺序和交互逻辑， 设计系统的流程和顺序结构。
用例图在需求分析中的应用
1 2
沟通工具
用例图作为一种可视化图形表示，可以作为沟通 工具，帮助开发团队、客户和利益相关者理解系 统的需求和功能。
需求确认
通过绘制用例图，可以与利益相关者讨论和确认 系统的需求，确保对需求的理解和期望是一致的。
UML中三种常用的图
1.用例图：用例图是从用户的观点描述系统的功能，它由一组用例、参与者以及他们之间的关系组成他将系统的一个功能描述成一系列事件，这些事件最终对参与者产生有价值的可观测结果参与者（Actor）：代表与系统交互的外部实体用例（Use-Case）：表示系统能提供的功能，如：登录，查询等关联关系：当参与者与用列进行交互时，用例与参与者之间有关联关系，用一条直线表示这种关系参与者之间可能存在泛化关系，类似的参与者可以用泛化关系组成一般与特殊的层析结构如：经理初次之外，用例之间还存在一定的关系，具体包括包含（include）、扩展（extend）、泛化（Generalization）等3种关系（1）包含关系一个复杂系统中，不同用例之间可能存在一些相同的行为，这时可将这些相同的行为提取出来单独组成一个用例。
当其他用例使用该用例时，用例之间便形成了包含关系包含关系用带关键字<<include>>的虚线来表示，虚线指向被包含的用例注册新用户（2）扩展关系在用例的执行过程中，可能会出现异常行为，也可能在不同的流程分支中选择执行，这时可将异常行为或可选分支抽象成一个单独的扩展用例，它与主用例之间形成扩展关系扩展关系用带关键字<<extend>>的虚线表示，箭头指向被扩展的用例注册（3）泛化关系与参与者之间的泛化关系一样，用例之间的泛化关系是描述用例之间一般与特殊关系的，不同的子用例代表了父用例的不同实现方法。
密码找回2.类图类图描述系统的静态结构，表示系统中的类、类与类之间的关系以及类的属性和操作类用一个矩形方框表示，方框被分成3部分，最上面显示类名，中间部分显示类的属性，最下面显示类的操作类之间的关系包括关联、聚合、泛化、依赖等类型关联（Association）是一种结构定义，表达模型元素间的一种语义联系，它是对具有共同的结构特性、行为特性、关系和语义链的描述，使用一条连接在两个类之间的实线表示，关系的每一端用数字表示关系的重数。
UML的9种图例的定义、用途、画法总结
1UML 的9种图例的总结一、 用例图1、 定义用例定义：用例是对包括变量在内的一组动作序列的描述，系统执行这些动作，并产生传递特定参与者的价值的可观察结果。
（这是UML 对用例的正式定义，可以这样去理解，用例是参与者想要系统做的事情，用例在画图中用椭圆来表示，椭圆下面附上用例名称）。
用例图定义：由参与者（Actor ）、用例（Use Case ）以及它们之间的关系构成的用于描述系统功能的动态视图称为用例图。
2、 用途用例图（User Case ）是被称为参与者的外部用户所能观察到的系统功能的模型图，呈现了一些参与者和一些用例，以及它们之间的关系，主要用于对系统、子系统或类的功能行为进行建模。
用例图主要的作用有三个：（1）获取需求；（2）指导测试；（3）还可在整个过程中的其它工作流起到指导作用。
3、 组成元素以及元素之间的关系说明用例图由参与者（Actor ）、用例（Use Case ）、系统边界（用矩形表示—注明系统名称）、箭头组成，用画图的方法来完成。
参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。
因此参与者可以是人，可以是事物，也可以是时间或其他系统等等。
还有一点要注意的是，参与者不是指人或事物本身，而是表示人或事物当时所扮演的角色。
系统边界是用来表示正在建模系统的边界。
边界内表示系统的组成部分，边界外表示系统外部。
系统边界在画图中用方框来表示，同时附上系统的名称，参与者画在边界的外面，用例画在边界里面。
因为系统边界的作用有时候不是很明显，所以我个人理解，在画图时可省略。
箭头用来表示参与者和系统通过相互发送信号或消息进行交互的关联关系。
箭头尾部用来表示启动交互的一方，箭头头部用来表示被启动的一方，其中用例总是要由参与者来启动。
元素之间的关系：用例图中包含的元素除了系统边界、角色和用例，另外就是关系。
关系包括用例之间的关系，角色之间的关系，用例和角色之间的关系。
角色之间的关系：角色之间的关系。
UML：图的分类及作用（共5类图,有9种图形）
UML：图的分类及作⽤（共5类图,有9种图形）第⼀类：⽤例图：从⽤户⾓度描述系统功能,并指出各功能的操作者。
第⼆类：静态图：包括类图、对象图和包图。
1、类图：表⽰类之间的联系如关联、依赖、聚合等，包括类的内部结构（类的属性和操作）。
在系统的整个⽣命周期都是有效的 2、对象图：表⽰类图的⼀个实例，对象图只能在系统某⼀时间段存在。
3、包图：表⽰包与包之间的关系。
包图⽤于描述系统的分层结构。
第三类：⾏为图：状态图、活动图。
描述系统的动态模型和组成对象间的交互关系。
1、状态图：是对类图的补充，描述类的对象所有可能的状态以及事件发⽣时状态的转移条件。
在实⽤上并不需要为所有的类画状态图,仅为那些有多个状态其⾏为受外界环境的影响并且发⽣改变的类画状态图。
2、描述满⾜⽤例要求所要进⾏的活动以及活动间的约束关系,有利于识别并⾏活动。
第四类：交互图：包括顺序图 ,协作图（即合作图） 1、顺序图:强调的是时间和顺序的关系 2、协作图:强调的是上下级关系第五类：实现图：构件图，描述代码部件的物理结构及各部件之间的依赖关系。
从应⽤的⾓度看,当采⽤⾯向对象技术设计系统时,⾸先是描述需求;其次根据需求建⽴系统的静态模型,以构造系统的结构;第三步是描述系统的⾏为。
其中在第⼀步与第⼆步中所建⽴的模型都是静态的,包括⽤例图、类图(包含包)、对象图、组件图和配置图等五个图形,是标准建模语⾔UML的静态建模机制。
其中第三步中所建⽴的模型或者可以执⾏,或者表⽰执⾏时的时序状态或交互关系。
它包括状态图、活动图、顺序图和合作图等四个图形,是标准建模语⾔UML的动态建模机制。
因此,标准建模语⾔UML的主要内容也可以归纳为静态建模机制和动态建模机制两⼤类。
总结：1、静态图：包括⽤例图、类图(包含包)、对象图、组件图和配置图等五个图形，⾸先是描述需求;其次根据需求建⽴系统的静态模型,以构造系统的结构; 2、动态图：包括状态图、活动图、顺序图和合作图等四个图形，是描述系统的⾏为；。
UML中各种图的画法(全)
UML中各种图的画法(全)UML中各种图的画法(全)一、UML中基本的图范畴：在 UML 2 中有二种基本的图范畴：结构图和行为图。
每个 UML 图都属于这二个图范畴。
结构图的目的是显示建模系统的静态结构。
它们包括类，组件和（或）对象图。
另一方面，行为图显示系统中的对象的动态行为，包括如对象的方法，协作和活动之类的内容。
行为图的实例是活动图，用例图和序列图。
二、UML中的类图：1.类图的表示：类的 UML 表示是一个长方形，垂直地分为三个区，如图 1 所示。
顶部区域显示类的名字。
中间的区域列出类的属性。
底部的区域列出类的操作。
在一个类图上画一个类元素时，你必须要有顶端的区域，下面的二个区域是可选择的（当图描述仅仅用于显示分类器间关系的高层细节时，下面的两个区域是不必要的）。
描述：顶部区域显示类的名字。
中间的区域列出类的属性。
底部的区域列出类的操作。
当在一个类图上画一个类元素时，你必须要有顶端的区域，下面的二个区域是可选择的（当图描述仅仅用于显示分类器间关系的高层细节时，下面的两个区域是不必要的）。
·类名：如果是抽象类，则采用斜体·类属性列表：name : attribute type 如 flightNumber : Integer，这是最常见的表达形式n ame : attribute type = default value 如balance : Dollars = 0，这是带有默认值的表达形式·类方法列表：name(parameter list) : type of value returned注意：在业务类图中，属性类型通常与单位相符，这对于图的可能读者是有意义的（例如，分钟，美元，等等）。
然而，用于生成代码的类图，要求类的属性类型必须限制在由程序语言提供的类型之中，或包含于在系统中实现的、模型的类型之中。
2.继承的表示：为了在一个类图上建模继承，从子类（要继承行为的类）拉出一条闭合的，单键头（或三角形）的实线指向超类。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
UML的9种图例的总结一、用例图1、定义用例定义：用例是对包括变量在内的一组动作序列的描述，系统执行这些动作，并产生传递特定参与者的价值的可观察结果。
（这是UML对用例的正式定义，可以这样去理解，用例是参与者想要系统做的事情，用例在画图中用椭圆来表示，椭圆下面附上用例名称）。
用例图定义：由参与者（Actor）、用例（Use Case）以及它们之间的关系构成的用于描述系统功能的动态视图称为用例图。
2、用途用例图（User Case）是被称为参与者的外部用户所能观察到的系统功能的模型图，呈现了一些参与者和一些用例，以及它们之间的关系，主要用于对系统、子系统或类的功能行为进行建模。
用例图主要的作用有三个：（1）获取需求；（2）指导测试；（3）还可在整个过程中的其它工作流起到指导作用。
3、组成元素以及元素之间的关系说明用例图由参与者（Actor）、用例（Use Case）、系统边界（用矩形表示—注明系统名称）、箭头组成，用画图的方法来完成。
参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。
因此参与者可以是人，可以是事物，也可以是时间或其他系统等等。
还有一点要注意的是，参与者不是指人或事物本身，而是表示人或事物当时所扮演的角色。
系统边界是用来表示正在建模系统的边界。
边界内表示系统的组成部分，边界外表示系统外部。
系统边界在画图中用方框来表示，同时附上系统的名称，参与者画在边界的外面，用例画在边界里面。
因为系统边界的作用有时候不是很明显，所以我个人理解，在画图时可省略。
箭头用来表示参与者和系统通过相互发送信号或消息进行交互的关联关系。
箭头尾部用来表示启动交互的一方，箭头头部用来表示被启动的一方，其中用例总是要由参与者来启动。
元素之间的关系：用例图中包含的元素除了系统边界、角色和用例，另外就是关系。
关系包括用例之间的关系，角色之间的关系，用例和角色之间的关系。
角色之间的关系：角色之间的关系。
由于角色实质上也是类，所以它拥有与类相同的关系描述，即角色之间存在泛化关系（泛化关系可以先简单理解为继承），泛化关系的含义是把某些角色的共同行为提取出来表示为通用的行为。
用例之间的关系：●包含关系：基本用例的行为包含了另一个用例的行为。
基本用例描述在多个用例中都有的公共行为。
包含关系本质上是比较特殊的依赖关系。
它比一般的依赖关系多了一些语义。
在包含关系中箭头的方向是从基本用例到包含用例。
在UML1.1中用例之间是使用和扩展这两种关系，这两种关系都是泛化关系的版型。
在UML1.3以后的版本中用例之间是包含和扩展这两种关系。
●泛化关系：它的意思和面向对象程序设计中的继承的概念是类似的。
不同的是继承使用在实施阶段，泛化使用在分析、设计阶段。
在泛化关系中子用例继承了父用例的行为和含义，子用例也可以增加新的行为和含义或者覆盖父用例中的行为和含义。
●扩展关系扩展关系的基本含义和泛化关系类似，但在扩展关系中，对于扩展用例有更多的规则限制，基本用例必须声明扩展点，而扩展用例只能在扩展点上增加新的行为和含义。
与包含关系一样，扩展关系也是依赖关系的版型。
在扩展关系中，箭头的方向是从扩展用例到基本用例，这与包含关系是不同的。
用例的泛化、包含、扩展关系的比较。
一般来说可以使用“is a”和“has a”来判断使用那种关系。
泛化和扩展关系表示用例之间是“is a”关系，包含关系表示用例之间是“has a”关系。
扩展与泛化相比多了扩展点，扩展用例只能在基本用例的扩展点上进行扩展。
在扩展关系中基本用例是独立存在。
在包含关系中执行基本用例的时候一定会执行包含用例。
（1）如果需要重复处理两个或多个用例时可以考虑使用包含关系，实现一个基本用例对另一个的引用。
（2）当处理正常行为的变形是偶尔描述时可以考虑只用泛化关系。
（3）当描述正常行为的变形希望采用更多的控制方式时，可以在基本用例中设置扩展点，使用扩展关系。
扩展关系比较难理解，如果把扩展关系看作是带有更多规则限制的泛化关系，可以帮助理解。
通常先获得基本用例，针对这个用例中的每一个行为提问：该步骤会出什么差错？该步骤有不同的情况吗？该步骤的工作怎样以不同的方式进行等，把所有的变化情况都标识为扩展。
通常基本用例很容易构造，而扩展用例需要反复分析、验证。
当我们发现已经存在的两个用例间具有某种相似性时，可以把相似的部分从两个用例中抽象出来单独作为一个用例，该用例被这两个用例同时使用，这个抽象出的用例和另外两个用例形成包含关系。
用例之间的关系举例：包含：业务中，总是存在着维护某某信息的功能，如果将它作为一个用例，那新建、编辑以及修改都要在用例详述中描述，过于复杂；如果分成新建用例、编辑用例和删除用例，则划分太细。
这时包含关系可以用来理清关系。
扩展：系统中允许用户对查询的结果进行导出、打印。
对于查询而言，能不能导出、打印查询都是一样的，导出、打印是不可见的。
导入、打印和查询相对独立，而且为查询添加了新行为。
泛化：子用例将继承父用例的所有结构、行为和关系。
子用例可以使用父用例的一段行为，也可以重载它。
父用例通常是抽象的。
4、画法例子二、类图1、定义类图Class diagram通过显示出系统的类以及这些类之间的关系来表示系统。
类图是静态的－它们显示出什么可以产生影响但不会告诉你什么时候产生影响。
在系统分析阶段将类分成三种类型：实体类、边界类、控制类边界类用于描述外部参与者与系统之间的交互。
识别边界类可以帮助开发人员识别出用户对界面的需求。
实体类主要是作为数据管理和业务逻辑处理层面上存在的类别；它们主要在分析阶段区分。
实体类的主要职责是存储和管理系统内部的信息，它也可以有行为，甚至很复杂的行为，但这些行为必须与它所代表的实体对象密切相关。
控制类用于描述一个用例所具有的事件流控制行为，控制一个用例中的事件顺序。
2、用途类图的目的是显示建模系统的类型，描述组成系统的对象内容与对象之间的关系。
3、组成元素以及元素之间的关系说明类名类的 UML 表示是一个长方形，垂直地分为三个区，如图 1 所示。
顶部区域显示类的名字。
中间的区域列出类的属性。
底部的区域列出类的操作。
当在一个类图上画一个类元素时，你必须要有顶端的区域，下面的二个区域是可选择的（当图描述仅仅用于显示分类器间关系的高层细节时，下面的两个区域是不必要的）。
图 1 显示一个航线班机如何作为 UML 类建模。
正如我们所能见到的，名字是Flight，我们可以在中间区域看到Flight类的3个属性：flightNumber，departureTime 和 flightDuration。
在底部区域中我们可以看到Flight类有两个操作：delayFlight 和 getArrivalTime。
图 1: Flight类的类图类属性列表类的属性节（中部区域）在分隔线上列出每一个类的属性。
属性节是可选择的，要是一用它，就包含类的列表显示的每个属性。
如下格式：name : attribute typeflightNumber : Integer继续我们的Flight类的例子，我们可以使用属性类型信息来描述类的属性，如表 1 所示。
表 1：具有关联类型的Flight类的属性名字属性名称属性类型flightNumber IntegerdepartureTime DateflightDuration Minutes在业务类图中，属性类型通常与单位相符，这对于图的可能读者是有意义的（例如，分钟，美元，等等）。
然而，用于生成代码的类图，要求类的属性类型必须限制在由程序语言提供的类型之中，或包含于在系统中实现的、模型的类型之中。
在类图上显示具有默认值的特定属性，有时是有用的（例如，在银行账户应用程序中，一个新的银行账户会以零为初始值）。
UML 规范允许在属性列表节中，通过使用如下的记号作为默认值的标识：name : attribute type = default value举例来说：balance : Dollars = 0显示属性默认值是可选择的；图 2 显示一个银行账户类具有一个名为balance的类型，它的默认值为0。
图 2：显示默认为0美元的balance属性值的银行账户类图。
类操作列表类操作记录在类图长方形的第三个（最低的）区域中，它也是可选择的。
和属性一样，类的操作以列表格式显示，每个操作在它自己线上。
操作使用下列记号表现：name(parameter list) : type of value returned图3显示，delayFlight 操作有一个Minutes类型的输入参数 -- numberOfMinutes。
然而，delayFlight 操作没有返回值。
1当一个操作有参数时，参数被放在操作的括号内；每个参数都使用这样的格式：“参数名：参数类型”。
图 3：Flight类操作参数，包括可选择的“in”标识。
当文档化操作参数时，你可能使用一个可选择的指示器，以显示参数到操作的输入参数、或输出参数。
这个可选择的指示器以“in”或“out”出现，如图3中的操作区域所示。
一般来说，除非将使用一种早期的程序编程语言，如Fortran ，这些指示器可能会有所帮助，否则它们是不必要的。
然而，在 C++和Java中，所有的参数是“in”参数，而且按照UML规范，既然“in”是参数的默认类型，大多数人将会遗漏输入/输出指示器。
继承在面向对象的设计中一个非常重要的概念，继承，指的是一个类（子类）继承另外的一个类（超类）的同一功能，并增加它自己的新功能（一个非技术性的比喻，想象我继承了我母亲的一般的音乐能力，但是在我的家里，我是唯一一个玩电吉他的人）的能力。
为了在一个类图上建模继承，从子类（要继承行为的类）拉出一条闭合的，单键头（或三角形）的实线指向超类。
考虑银行账户的类型：图 4 显示 CheckingAccount 和 SavingsAccount 类如何从 BankAccount 类继承而来。