1 用例图建模步骤
第3章 用例图
为了保证系统正常运行，谁将对系统进行维护管理
（副参与者）？ 谁将完成系统数据的录入、导出及修改等工作（主 动参与者）？ 谁或什么系统对系统产生的结果感兴趣（被动参与 外部系统进行交互？ 在预定的时间，是否有事件自动触发？ 系统从何处获取信息？
（2）参与者不一定是人，也可以是一个外部系统， 该系统与本系统相互作用。代表的是一种角色。 （3）在系统的实际运作中，多个不同的用户可能 只对应于一个参与者；同时一个实际用户也可 能对应系统的多个参与者。
例如： 在“房地产开发经营管理系统”中，
所有的购房者作为一个集合，在“房屋销售子 系统”中作为购房合同的签约方出现，多个个 体在系统中担任一个参与者；同时，某个独立 的购房者在“物业管理子系统”中又作为房屋 的业主出现，同一个人在系统中担任了两类参 与者。
主参与者和副参与者
主参与者使用系统的主要功能，是使用系统较 频繁、业务量较大的用户。 副参与者处理系统的辅助功能，它与用例进行 交互的主要目的是为了给其他的参与者提供某些服 务。如管理数据库、通信、系统备份以及其他管理
等系统维护工作。
主动参与者和被动参与者
主动参与者是系统的启动者，负责启动一个或多
借阅图书用例的描述
用例名称 标识符 用例描述 参与者 状态 BorrowBook UC0001 图书管理员代理借阅者办理借阅手续 图书管理员 通过审查
前置条件
后置条件 假设 基本操作流程
图书管理员登录进入系统
如果这个用例成功，在系统中建立并存储借阅记录 图书管理员已经成功地登录到系统 1. 2. 3. 4. 5. 管理员输入借书证信息 系统验证借阅证的有效性 图书管理员输入图书信息 添加新的借阅记录 显示借书后的借阅信息
实验1-用例图的建模与绘制-讲解
实验一用例图的建模与绘制一、实验目的与要求● 掌握参与者、用例的识别方法； ● 掌握用例的描述方法；● 掌握用例与用例之间的各种关系； ●掌握用例图的绘制方法。
二、实验内容1.参考教材p72和p73的用例模型，包括图4-24，图4-25和图4-26，独立使用Rational Rose 绘制图书馆管理系统的用例图。
缴纳罚款<<extend>>处理预约编辑图书信息编辑用户信息点评：大部分同学都正确绘制出来了，少数同学忘记在依赖关系上添加相应的构造型，即include或extend添加方法：双击连线或右键菜单打开关系的specification（规格），设置其stereotype（版型）为include（包含）或extend（扩展）2. 下面的场景应该建模为用例的什么关系？请画出相应的用例图。
（1）在网络购物系统中，客户可以进行购物、确认支付等操作，这些操作都需要登录系统。
请对购物、确认支付进行建模。
包含关系两种场景适合建模为包含关系：（1）大用例分解为小用例，小用例为大用例的一部分。
注意，这里也不同于先后关系，一个用例不需要包含它所有的前置用例，先后关系通过用例的前置条件表达。
（2）多个用例的公共功能部分，提取出来作为提供用例，被其它用例包含。
存在问题1：关系的指向方向反了，或没分清哪个用例包含哪个用确认支付（2）在网络购物系统中，客户可选择如下付款方式：支付宝、信用卡、银联卡或货到付款。
请对付款及其变体进行建模。
泛化关系泛化关系：一个用例可以例举为多个子用例，比如，使用不同的实现手段，如还书、付款问题：（1）依然建模为包含关系，未能建模为泛化关系（2）用流程图的方法来画用例图。
支付宝信用卡银联卡货到付款（3）在网络购物系统中，客户可选择如下付款方式：金额在1000以下可使用支付宝快捷支付；金额在1000以上只能选择使用信用卡或银联卡进行支付；金额在500以下可选择货到付款。
如何绘制用例图
需求中如何画用例图UML用例图用例图主要用来图示化系统的主事件流程，它主要用来描述客户的需求，即用户希望系统具备的完成一定功能的动作，通俗地理解用例就是软件的功能模块，所以是设计系统分析阶段的起点，设计人员根据客户的需求来创建和解释用例图，用来描述软件应具备哪些功能模块以及这些模块之间的调用关系，用例图包含了用例和参与者，用例之间用关联来连接以求把系统的整个结构和功能反映给非技术人员（通常是软件的用户），对应的是软件的结构和功能分解。
用例是从系统外部可见的行为，是系统为某一个或几个参与者（Actor）提供的一段完整的服务。
从原则上来讲，用例之间都是独立、并列的，它们之间并不存在着包含从属关系。
但是为了体现一些用例之间的业务关系，提高可维护性和一致性，用例之间可以抽象出包含(include)、扩展(extend)和泛(generalization)几种关系。
共性：都是从现有的用例中抽取出公共的那部分信息，作为一个单独的用例，然后通后过不同的方法来重用这个公共的用例，以减少模型维护的工作量。
1、包含(include)包含关系：使用包含（Inclusion）用例来封装一组跨越多个用例的相似动作（行为片断），以便多个基（Base）用例复用。
基用例控制与包含用例的关系，以及被包含用例的事件流是否会插入到基用例的事件流中。
基用例可以依赖包含用例执行的结果，但是双方都不能访问对方的属性。
包含关系对典型的应用就是复用，也就是定义中说的情景。
但是有时当某用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例；相反，用例划分太细时，也可以抽象出一个基用例，来包含这些细颗粒的用例。
这种情况类似于在过程设计语言中，将程序的某一段算法封装成一个子过程，然后再从主程序中调用这一子过程。
例如：业务中，总是存在着维护某某信息的功能，如果将它作为一个用例，那新建、编辑以及修改都要在用例详述中描述，过于复杂；如果分成新建用例、编辑用例和删除用例，则划分太细。
数据建模--用例图
刹车系统 传动系统
是什么
骑行 载物
能做什么
捏合刹车
蹬踏前行
人们能用他来做什么
用例建模符号
提问，下列哪些是用例
以日常接触的银行业务为例：
支持跨行业务
错，这是一个业务规则限定业务范围
插入卡片
错，这是一个过程步骤，不是完整目标
3、实例：图书管理系统的用例图
借阅者 图书馆管理员 系统管理员
借阅者请求服务的用例图
图书馆管理员处理借书、还书的用例图
系统管理员进行系统维护的用例图
课后作业
复习用例图概念，及相应的建模步骤 创建“学生选课系统”用例图
谢谢观看
用例间常用的两类关系
包含关系
<<include>>
基础用例 维护数据
包含用例
管理员
<<include>>
<<include>> <<include>>
修改数据
删除数据
添加数据
用例间常用的两类关系
扩展关系
<<extend>>
基础用例
扩展用例
查询成绩
学生
<<extend>>
导出查询结果
<<extend>>
数据建模
————用例图
主要学习内容
1、用例图相关概念
用例图定义：
定义分析： • 要素？ • 主要作用？
参与者是为了完成一个事件而与系统交互的实体，是指系统以外的，
UML用例图的绘制与分析
UML用例图的绘制与分析UML（Unified Modeling Language）是一种用于软件开发的建模语言，它提供了一种标准的图形化表示方法，用于描述系统的结构和行为。
其中，用例图是UML中最常用的图之一，用于描述系统的功能需求和用户之间的交互关系。
本文将介绍UML用例图的绘制与分析。
一、概述UML用例图是一种高层次的视图，用于表示系统中的参与者（Actor）和用例（Use Case）之间的关系。
参与者可以是人、其他系统或外部设备，用例则表示系统提供的功能。
用例图可以帮助开发人员和用户理解系统的功能需求，并提供一个沟通的桥梁。
二、绘制用例图绘制用例图的第一步是确定参与者和用例。
参与者是与系统交互的实体，他们可以是用户、其他系统或外部设备。
用例是系统提供的功能，它描述了系统完成的任务或目标。
在绘制用例图时，可以使用椭圆形表示参与者，使用矩形表示用例。
接下来，需要确定参与者和用例之间的关系。
一种常见的关系是关联关系（Association），表示参与者与用例之间的关联。
关联关系可以用实线箭头表示，箭头指向用例。
另一种关系是包含关系（Include），表示一个用例包含了另一个用例。
包含关系可以用虚线箭头表示，箭头指向被包含的用例。
还有一种关系是扩展关系（Extend），表示一个用例可以在另一个用例的基础上进行扩展。
扩展关系可以用虚线箭头表示，箭头指向被扩展的用例。
最后，可以添加注释和约束条件来完善用例图。
注释可以用于解释用例的功能或描述参与者的特征。
约束条件可以用于限制用例的执行条件或前置条件。
三、分析用例图用例图不仅仅是一种图形化的表示方法，它还可以用于分析系统的功能需求和用户之间的交互关系。
通过分析用例图，可以发现系统中可能存在的问题或改进的空间。
首先，可以通过用例图来识别系统的功能需求。
每个用例代表了一个系统功能，通过分析用例图，可以清楚地了解系统需要完成哪些任务或目标。
如果用例图中缺少一些重要的用例，说明系统的功能需求可能不完整，需要进一步补充。
UML用例图的创建与应用详解
UML用例图的创建与应用详解UML（Unified Modeling Language）是一种用于软件系统建模的标准化语言。
在软件开发过程中，UML用例图是一种重要的工具，用于描述系统的功能需求和用户与系统之间的交互。
本文将详细介绍UML用例图的创建与应用。
一、UML用例图的概念和基本元素UML用例图是一种用于描述系统功能的图形化表示方法。
它主要由用例（Use Case）、参与者（Actor）和关系（Relationship）三个基本元素组成。
1. 用例（Use Case）：用例是对系统功能的描述，它表示系统与用户之间的交互。
每个用例代表一个特定的用户需求或系统功能。
用例通常以椭圆形状表示，并用文本标识。
2. 参与者（Actor）：参与者是与系统进行交互的外部实体，可以是人、其他系统或外部设备。
参与者以人的图标或简单的方框表示，并用文本标识。
3. 关系（Relationship）：用例和参与者之间的关系有三种：关联（Association）、包含（Include）和扩展（Extend）。
关联表示用例和参与者之间的关联关系，包含表示一个用例包含另一个用例，扩展表示一个用例可以根据条件扩展另一个用例。
二、UML用例图的创建步骤创建UML用例图可以分为以下几个步骤：1. 确定系统边界：首先确定系统的边界，即明确系统与外部实体的交互范围。
2. 确定参与者：根据系统边界确定参与者，包括系统的用户、其他系统或外部设备。
3. 确定用例：根据系统需求确定用例，描述系统的功能和用户需求。
4. 绘制用例图：根据确定的参与者和用例，使用UML工具绘制用例图，将参与者和用例按照关系连接起来。
5. 完善用例图：根据需要，可以添加用例之间的关系，如包含和扩展关系。
三、UML用例图的应用场景UML用例图在软件开发过程中有广泛的应用场景，以下是几个常见的应用场景：1. 需求分析：用例图可以帮助分析人员理解用户需求，明确系统的功能需求和用户与系统之间的交互。
visio2020绘制用例图带图例
visio2020绘制用例图
1.Microsoft Office2020中打开Microsoft Visio 2020，在“新建当选择”软件和数据
库“，如图：2.然后选择“UML模型图”，点击右下方的“创建”，进入主页面，如图：
3.在左下角模型资源治理器中，“顶层包”上右键新建”子系统“，如图：
4.给新建的“子系统”命名，如图：
5.然后在新建的子系统上右击，选择”用例图“如图：
新建用例图后打开。
左上角工具栏显现经常使用工具，拖拽即可绘制用例图：6.选中需要自概念的元素，右键可查看具体自概念元素样式，包括连线方式，文本，线条
样式，填充，如图：
7.设置参与者与用例之间的关系：
a)在左侧工具栏当选择“用”工具如图
b)在用例图中拖动图标链接目标用例与参与者：
选中线条右键-》格式-》线条，设置箭头起点为无
c)双击连线。
修改构造型为空，可隐藏连线上的label
8.设置用例之间的扩展关系：
a)选中工具栏上的扩展按钮：
b)拖动到有扩展关系的用例上
c)选中线条右键-》格式-》线条。
设置虚线和起始箭头：
用例图图例说明
UML表示
含义，视具体情况而定。
用例图关系说明
出发用例成为扩展用例。
基于UML的用例图模型创建
基于UML的用例图模型创建用例图是一种UML建模工具，用于描述一个系统的功能和行为。
用例图的主要作用是为系统的设计和分析提供可视化的结构模型，提高系统的可理解性和可维护性。
在本文中，我们将详细介绍如何创建一个基于UML的用例图模型。
创建用例图在创建用例图之前，您需要了解用例图的基本元素。
用例图由用例、系统边界、参与者和关联四个基本元素组成。
用例表示系统进行的主要活动和任务，系统边界表示系统的范围，参与者表示与系统交互的人或组织，关联表示用例和参与者之间的关系。
现在让我们开始创建用例图。
第一步：创建系统边界系统边界表示一个系统的范围，决定系统与外部世界之间的交互。
在UML中，系统边界表示用一个矩形来表示，其中系统边界内部的所有用例表示系统可以执行的任务或功能，外部的所有参与者则表示与系统交互的人或组织。
用例表示系统进行的主要活动和任务。
在UML中，用例用一个椭圆形来表示。
用例通常包括用例名和用例描述，用例名应该简明易懂，描述清晰明确。
第三步：创建参与者参与者表示与系统交互的人或组织。
在UML中，参与者用一个小人或者组织的图标来表示。
第四步：创建关联关联表示用例和参与者之间的关系。
关联分为三种类型：泛化、包含和扩展。
•泛化关系泛化关系表示一个用例是另一个用例的特殊情况。
在用例图中，泛化关系通过带有箭头的实线表示，箭头指向被泛化的用例。
例如，一个网上商店系统中的“购买商品”用例，可以泛化为“购买图书”、“购买电子产品”等细化用例。
第五步：完善用例图创建完用例图之后，您需要对它进行完善。
根据系统的需求，您可以对用例、参与者、关联进行修改和补充。
例如，可以为每个用例添加扩展场景和前置条件，为每个参与者添加角色和职责，为每个关联添加关联说明和触发条件。
总结UML用例图是一种非常有用的建模工具，可以帮助设计师和开发者更好地理解系统的需求和功能。
通过本文的介绍，您可以了解到如何创建一个基于UML的用例图模型，从而更好地发挥UML的建模功能。
基于UML的用例图模型创建
基于UML的用例图模型创建UML（Unified Modeling Language）是现在使用最广泛的软件模型语言，它是一种可以应用于大型软件开发中的标准建模语言。
UML能够帮助软件开发者直观地表达软件设计和规划，同时也能方便地进行软件开发的过程管理。
其中，UML中的用例图是描述软件使用者与软件系统的交互行为的一种图示工具，用于帮助开发人员理解软件系统以及需求管理。
下面将会根据UML的用例图模型创建来讲解用例图的建立方法。
一、确定参与者在开发用例图之前，第一步应该先确定系统将会有哪些参与者（Actor）。
参与者可以是用户、外部系统、硬件设备，等等。
通过这样的方式可以很明确地将系统与用户区分开来。
二、确定用例接下来，应该确定每个参与者与系统之间存在哪些行为以及可以进行哪些操作，也就是确定用例（Use Case）。
用例就是参与者与系统之间的一种交互方式，是为了实现某种特定的目标而进行的一系列操作。
三、建立用例图在确定完参与者和用例后，下一步就是建立用例图。
在用例图中，参与者用方框表示，用例则用椭圆形表示。
每个参与者都需要某些用例才能完成自己的任务，所以在用例图中，参与者与用例之间都要有连线连接。
此外，参与者与用例之间的连线可以用带箭头的实线或虚线，实线代表主要的交互过程，虚线则代表次要的交互过程。
每个用例的名称应该简明明了地表达该用例的功能。
四、添加包含和扩展用例在用例图中，某些用例之间会存在包含关系或扩展关系。
包含关系表示一个用例包含其他用例或操作，而扩展关系表示一个用例可以在执行过程中控制或者扩展其他用例。
在用例图中，这些关系都要用带箭头的连线来表示。
五、添加关联关系除了用例之间的关系，参与者之间还会存在关系，这些关系可以是拥有关系、通信关系、以及参与者之间的关系。
这些关系也要在用例图中体现出来。
六、定稿用例图在添加所有重要的用例、参与者、以及用例关系之后，就可以将用例图定稿。
此时，应该仔细检查每个用例的名称和说明是否清晰明了，参与者和用例之间的连线是否简明直观，以及参与者和用例的位置是否合理。
UML软件建模技术2.1用例图
第二章 需求建模
2.1 用例图
本节目标
1. 理解用例及用例图的概念
2. 如何创建用例图
3.掌握用例之间的关系
本节重难点
1.用例图的作用
2.用例图的创建方法
3.用例之间的关系
问题引入
作为一名HNS图书馆管理系统的项目开发人员，你需要
站在用户的角度分析该系统的需求，确定系统中的参与者和
1. 用例应描述系统该做什么，而不是如何做 2. 用例应采取参与者的视点 3. 用例应对参与者有价值 4. 用例描述的时间流应是一个完整场景 5. 所有的参与者、用例都应有相应的关联用例或 关联参与者 6. 计算用例的数量，控制用例的数目 用例图
概 念
用例之间的关系 用例之间抽象出包含(include)、扩展(extend) 和泛化(generalization)这几种关系。
概 念
用例（UseCase）
用例（UseCase）是对一组序列动作的描述，系统执行这些动 作将对用例的参与者产生可以观察的结果。在图形上，用例用实线 的椭圆表示。
用例
识别用例
1. 参与者希望系统提供什么功能 2. 系统是否存储和检索信息 3. 当系统改变状态时，是否通知参与者 4. 是否存在影响系统的外部事件，是哪个参与者 通知系统这些外部事件
主要用例，并画出用例视图。
认识用例图
我们可以使用用例(use case)作为需求建模的起点。 以用例为起点进行需求建模，可以使我们的焦点集中在客户身上 。 用例图是显示一组用例、参与者以及它们之间关系的图。 用例图从用户的角度而不是开发者的角度来描述对软件产品的需求， 分析产品所需的功能和动态行为。 用例图包括以下三方面的内容： 1. 参与者 2. 用例 3. 依赖、泛化和关联关系
用例图建模流程
用例图建模流程
用例图建模是一种描绘系统功能需求的有效方式，其基本流程如下：
1. 确定参与者：识别系统外部所有与系统交互的实体，如用户、硬件设备或其他系统，定义为参与者。
2. 描述用例：列举系统应提供的各项主要功能，每个功能视为一个用例，描述其目的、前置条件、基本流程和可能的扩展流程。
3. 建立关系：在用例图中绘制参与者和用例，使用关联线连接参与者和他们所使用的用例，表示参与者与用例之间的交互关系。
4. 标注扩展和包含关系：若某个用例的行为可以根据特定条件变化或包含其他用例的行为，标注扩展（extend）和包含（include）关系。
5. 完善细节：添加必要的注释说明，细化用例描述，完善用例图，确保其准确反映系统功能需求。
1绘制用例图
就可以完成的任务。 用例强调了能够增加可见的或可度量的业务价值
EBP级别上的用例
一个EBP级别上的用例通常被称为
一个用户目标级别上的用例，以强
调用例应该帮助系统的用户来实现
自己的目标
解决
找出用户的目标
你想做什么？
方案
你的目标是什么？ 和过
系统分析师UML用例实战》介绍如 何通过用例掌握UML。《系统分析 师UML用例实战》的案例基于 Wesley和Richard两个角色叙述，从 两人开始接到一个书店系统的项目， 到动手建立用例模型，并且应用用 例技术来估算工时，系统记述了 UML用例的应用方法。
第1章 绘制用例图
《系统分析师UML用例实战》
收银员或顾客
目标
处理销售 处理销售
……
……
……
确定用例——EBP级别的用例
一个好的用例为参与者产生一种可以估 量的价值结果
描述参与者想要系统完成的事情
用例
一组用例是一个系统的用户能够使 用系统完成的不同任务
可以通过考虑在系统实现后参与者 能够用它来做什么，简单地草拟出 这次迭代的一组初步的用例
影响软件项目的因素
不充分的用户输入 13%
其其它它 505%0%
不完整需求 12%
员工不足 6%
变更需求 12%
技术技能不足 7%
用例到底用在哪？
What
How
Do
用用 例例 图描
述
“用例”先睹为快——用例图
接待员 前台 领班
餐饮管理系统 记录预约
取消预约 <<include>>
<<include>> 调换餐桌
实验二1创建用例图并描述需求
实践创建用例图，并增加需求描述关于实践内容的说明 (2)实践内容的具体操作 (3)参考内容 (9)正常的需求工程阶段需要完成的工作有：领域了解、需求收集、分类、冲突解决、优先排序、需求检查、需求描述、需求验证。
并且这些活动是迭代执行的。
结合项目管理中的过程管理，每个活动都需要经过质量检验。
具体操作中大致按照如下步骤，迭代几轮可由具体情况决定[针对小组开发的项目]：下面的示例省略了前期的收集整理与评审过程，直接将最终得到的东西用UML建模。
注意自己实践的项目中不要省略这些步骤[需要过程记录]。
打开Rational Rose软件，新建一个空项目。
[点击Cancel 按钮]展开User-Case V iew中的Main用例图，根据提供的模型建立好系统的用例图。
保存Rose模型，在模型文件的文件夹下新建一个Requirements 文件夹。
在将用例的描述写入对应的Word文档中，具体使用什么格式的文档模版由开发组的配置管理员PCM负责给出。
针对此实验，具体格式由个人自定。
注意一般文档中都会注明当前文档的状态信息，如：文档种类、级别、当前状态、所有者、更改历史、质保跟踪信息等。
具体要求由各开发组的配置管理员给出。
在Rose模型中关联对应的Word文档。
最终各用例的文件描述关联的大致状况如下所示：在Requirements文件夹中新建下面几个Word文档，并将内容补充完整：所做系统的总体描述Problem S tatement[通常就是系统的愿景]补充的需求描述Supplementary Specifications [通常是系统总体的非功能需求] 术语表Glossary [记录系统中用到的术语，通常是领域相关的]将创建好的文档关联到Use Case V iew根目录下。
下面根据需要，建立重要用例的活动图。
右击某个用例，选择新建活动图，名称可以与用例同名或自动命名。
如下示例：将重要的活动建模到活动图中：[ 各用例中的活动图分别按说明分别实现]全部做完整个实例就结束了，后续的内容为参考的文档内容。
基于UML的用例图模型创建
基于UML的用例图模型创建UML用例图是一种用于描述系统需求和功能的建模语言，它主要用于软件开发中的需求分析和系统设计。
用例图描述了系统的功能、行为、角色和其它关键性质，有助于设计师和用户理解系统的基本构成部分。
在这篇文章中，我们将着重介绍如何创建一个简单的用例图模型。
一、定义系统范围在设计用例图之前，首先需要明确系统的范围，也就是系统的主要功能和外部参与者。
以下是一些常见的系统参与者和其功能：· 用户：使用系统的人员，需要执行一些任务并得到相应的结果。
· 管理员：管理系统并执行监测和控制任务。
· 系统：执行后台任务、存储数据和实现逻辑功能的软件。
二、绘制用例图1. 根据系统的范围，确定必要的参与者和用例。
在这个过程中，需要考虑系统的目标用户，以及他们需要使用的功能和任务。
在图中，参与者用椭圆形表示，用例则用方形表示。
参与者和用例之间的关系有三种：关联、包含和扩展。
关联：参与者与用例之间的基本关系。
可以用一条线表示，箭头指向用例方框。
包含：一个用例包含了另一个用例。
表示为一个方框在另一个方框中。
例如，登陆功能通常包括了用户名和密码两个步骤。
扩展：一个用例可以通过另一个用例添加或修改功能。
用一条箭头从一个用例指向展示的用例扩展时，用实心箭头指向可选的用例扩展。
3. 添加注释对于用例图，注释应该清楚地描述每个参与者和用例的目的和任务。
用例名应该简明扼要，注释则应该是一个更详细的描述。
三、优化用例图用例图应该是一个简明直观的系统概述，所以可以考虑以下方法来优化：1. 合并使用相似功能的用例。
在实际系统中，可能有一些用例是非常相似的，只是针对不同的用户和数据。
在这种情况下，可以考虑将这些用例合并在一起，减少冗余。
2. 添加通用的参与者。
在实际系统中，可能会有许多用户，但是他们大部分都拥有相同的功能。
这种情况下，可以考虑添加一个通用的参与者，来代替他们所有人的功能。
综上所述，利用UML的用例图模型可以清晰的展示系统的功能以及参与者之间的关系，有助于设计师和用户理解系统的基本构成部分。
uml语言各种图形的建立步骤(精)
UML语言各种图形的建立步骤1．用例图的建立步骤：1〉找出系统外部的活动者和外部系统，确定系统的边界和范围。
2〉确定每一个活动者所希望的系统行为。
3〉把这些系统行为命名为用例。
4〉把一些公共的系统行为分解为一批新的用例，供其它的用例引用。
把一些变更的行为分解为扩展用例。
5〉编制每一个用例的剧本。
6〉绘制用例图。
7〉区分主业务流和例外情况的事件流。
可以把表达例外的情况的事件流的用例图画成一个单独的子用例图。
8〉精化用例图，解决用例见得重复与冲入问题，简化用例中的对话序列，用力图可以有不同的层次，高层次系统的用例可以分解为若干个下属子系统中的子用例。
2．对象类图的建立步骤：1〉研究分析问题领域，确定系统的需求。
2〉发现对象和对象类，明确他们的含义和责任，确定属性和操作。
3〉发现类之间的静态联系。
着重分析找出对象类之间的一般和特殊关系，部分与整体关系，研究类的继承性和多态性，把类之间的静态联系用关联、泛化、聚合、组合、依赖等联系表达出来，虽然对象类图表达的是系统的静态结构特征，但是应当把对系统的静态分析与动态分析结合起来，更能准确地了解系统的静态结构特征。
4〉设计类与联系。
调整和精化已得到的对象类和类之间的联系，解决诸如命名冲突、功能重复等问题。
5〉绘制对象类图并编制相应的说明。
上述做法是直接从领域分析抽取对象和对象类开始的，这是常规的面向对象的系统分析与设计的做法。
Rational统一过程主张采用用例驱动的系统分析与设计方法。
从业务领域的分析中先抽取活动者和用例，建立业务模型。
业务模型包括业务用例模型、设计模型、实现模型和测试模型。
3．系统中的例外情况建模：1〉对于每一个对象类和接口，找出可能发生的例外情况和出现例外情况的条件。
2〉把每一个例外情况用一个信号类描述，类名前冠有构造型《exception》。
3〉建立例外情况的层次结构，把一般性的例外情况置于高层，把特殊性的例外情况置于低层。
4〉对于每一个操作确定可能发生的例外情况。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
用例图建模步骤
窗口说明
1.开始
用例图在用例视图目录下，使用右键菜单“new”——》“use case diagram”。
2.工具栏调整
一般情况下，所有UML模型的工具栏都是可以调整的，可以根据具体需要对工具栏上的按钮进行定制。
在工具栏上使用右键菜单，选择“Customize”如图2，选择需要增加或减少的图标，如图3所示。
3.增加参与者
参与者的增加有2种方式，
方式一：使用工具栏上的快捷菜单
如图4，图5所示
方式二：使用左边栏右键菜单“new”——》“Actor”新增参与者功能
如图6所示，需要注意的是：使用此方式增加的参与者将不会自动出现在右边的绘图区中，需要把这个参与者拖到绘图区方可。
关于删除：在右边的绘图区，删除参与者可以使用Del键删除，但删除之后被删除的参与者在左边的目录下仍然是存在的。
即在绘图区中不能彻底的删除参与者。
在左边的目录区，4.增加用例
用例增加的方式和方法与参与者增加的方式和方法是相同的。
5.建立参与者之间的关系
参与者之间的关系常见的是泛化关系。
步骤如下：
1）选择泛化关系，如图7所示。
2）如图8所示，画出两个参与者之间的泛化关系。
注意：起点是继承类，终点是被继承类。
即，画的时候是从儿子开始，到父亲结束。
6.建立用例之间的关系
用例之间的关系主要是3种，分别是包含（include），扩展（extend）和泛化（generalization）。
我们只要熟悉一种建立方式，其他2种都可以采用同样的步骤实现。
建立包含关系步骤如下：
1）如图9所示，选择用例关系的图标。
2）如图10所示，从“登陆系统”用例开始，到“密码验证”用例结束画出关联关系，注意箭头的方向。
3）双击这条线或者右键点击这条线然后选择“Open Specification”菜单项（图11所示），
在弹出的窗口（图12）的Stereotype中选择包含（include）关系
结果如图13，图14所示
7.啊啊。