UML-用例图
UML用例和用例图
h
18
主要内容
基本概念：Use case、Actor、
Scenario Use case间的关系 Use Case 分析技术 案例讲解
h
19
关系
• 参与者与用例之间
– 关联关系
• 用例与用例之间
– 包含关系 (include) – 扩展关系 (extend) – 泛化关系 (generalization)
• 主事件流： • 1、系统显示ID和密码窗口； • 2、顾客键入ID和密码，然后按OK键； • 3、系统验证顾客ID和密码，并显示个人信息窗口； • 4、顾客键入姓名、街道地址、城市、邮政编码、电话号码，然
后按OK键； • 5、系统验证用户是否为老顾客； • 6、系统显示可以卖的商品列表； • 7、顾客在准备购买的商品图片上单击，并在图片旁边输入要购
• 用例结束后的系统状态
• 其他需要描述的内容
用例描述原则：尽可能写的“充分”，而不是追求写的形 式化、完整或漂亮。
h
32
h
33
书写用例文档
——路径交互步骤的描述
只书写“可观测”的 使用主动语句 句子必须以执行者或系统作为主语 每一句都要朝目标迈进 分支和循环 不要涉及界面细节
h
34
书写用例文档
买的数量。选购商品完毕后按Done按钮； • 8、系统通过库存系统验证要购买的商品是否有足够库存； • …….（后续描述省略）
问题：对用户界面的描述过于详细，对于需求文档来说， 详细的用户描述对获取需求并无帮助。
h
45
改进后的描述
• Use Case：Buy Something • 参与者：Customer • 主事件流： • 1、顾客使用ID和密码进入系统； • 2、系统验证顾客身份； • 3、顾客提供姓名、地址、电话号码； • 4、系统验证顾客是否为老顾客； • 5、顾客选择要购买的商品和数量； • 6、系统通过库存系统验证要购买的商品是否有足
电子商务系统分析与设计0301-UML-用例图绘制
第二题答案
显示是否有饮料 选择饮料
自动售货机 收钱
付款 找钱 提供饮料
顾客
10
12:56
第三题答案
11
12:56
12
12:56
12:56
3
1 用例图关系
用例图中涉及的关系有：关联、泛化、包含、扩展。
12:56
2 如何绘制用例图呢？
基本步骤
1.ONE
2.TWO
识别 参与者
确定 用例
4
3.THREE
构建用 例模型
12:56
实例
5
4.7 实例“学生信息管理系统”的需求
（1）系统管理员登录后可以对班级的基本信息进行增加、删除、 修改、查询等操作。学校领导登录后可以对班级基本信息进行查询 操作。
（2）教师登录后可以对学生的考试成绩进行录入、删除、修改、 查询等操作。学生登录后可以对考试成绩进行查询操作。
（3）学生登录后可以了解所有选修课程的具体信息，可以根据自 己的需要选择不同课程。系统管理员登录后可以增加、修改、查询、 删除选修课程。
（4）系统管理员可以对账号进行创建、设置、查看、删除等操作。
03有一台自动销售商品食品或者饮料等的机器任何人都可以通过按上面的按钮来购买商品每个商品旁边都有一个指示灯用来表示有没有该商品机器上有一个人民币入口和找零出口用来收钱和找钱如果你需要购买一瓶果汁请绘制出用例图
Байду номын сангаас习
2
UML有哪些特点？ UML有哪些功能？ UML包含哪些视图？ 用例图主要由哪些元素组成？ 用例图中涉及哪些关系？ 如果你根据一组需求绘制用例图，你会分为哪几步呢？
12:56
练习2
有一台自动销售商品（食品或 者饮料等）的机器，任何人都 可以通过按上面的按钮来购买 商品，每个商品旁边都有一个 指示灯，用来表示有没有该商 品，机器上有一个人民币入口 和找零出口，用来收钱和找钱， 如果你需要购买一瓶果汁，请 绘制出用例图。
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－表示两种类的实例间的关系.如果一个类的实例必须要用另一个类的实例才能完成工作时就要用关联.在图中，关联用两个类之间的连线表示.标准文档标准文档为了简单地表示出复杂的类图，可以把类组合成包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基础-用例图
30
订货系统用例图
<<extend>> 信用卡支付 <<include>> 下订单 <<extend>> <<include>> 计算订单价钱 <<extend>> 退货处理 选择仓库 <<extend>> 退货服务 发货 顾客 缺货 发货者 收款员 付款 <<extend>> 信用卡系统
管理者
货物管理
UseCase
Actor
预定
取车
还车 客户
34
泛化关系
泛化关系（Generalization Association）是表示一般 与特殊的关系。用于共享用例的共同功能行为。用例 可以继承父用例的含义和行为，也可以对父用例的行 为进行增加和修改。子用例可以出现在父用例出现的 任何位置。 泛化关系用泛化箭线（带空心三角箭头的实线）表 示，从子用例发出，指向父用例。如果需要可以在箭 线上标出联系的名称。
32
关系
用例除了与参与者有联系以外，用例之 间还存在着一定的关系。参与者之间还存有 关系。关系类型包括： 关联关系 包含关系 扩展关系 泛化关系
33
关联关系
关联关系用于描 述参与者与用例之间 的关系。在 UML 中用 实线表示。例如，客 户启动系统的取钱功 能，表示客户启动与 用例的关联。关系方 向显示是谁启动了通 信。建立通信之后， 信息是可以双向流动 的。
UML之用例图
UML之⽤例图⽤例图⽤例图是⽤来描述系统功能的技术，表⽰⼀个系统中⽤例与参与者及其关系的图，主要⽤于需求分析阶段。
⽤例图的基本组成元素：参与者、⽤例、元素之间的关系。
⽤例图使⽤范围：需求分析1.捕获需求。
描述功能需求、⾏为需求（系统要完成什么任务）2.分析需求。
明确类和对象，建⽴之间的关系⽤例图的基本概念1、⽤例图是表⽰⼀个系统中⽤例与参与者关系之间的图。
它描述了系统中相关的⽤户和系统对不同⽤户提供的功能和服务。
2、⽤例图相当于从⽤户的视⾓来描述和建模整个系统，分析系统的功能与⾏为。
3、⽤例图中的主要元素包括参与者、⽤例以及元素之间的关系。
此外，⽤例图还可以包括注解和约束，也可以使⽤包将图中的元素组合成模块。
如：参与者的概念1、参与者是与系统主体交互的外部实体的类元，描述了⼀个或⼀组与系统产⽣交互的外部⽤户或外部事物。
2、参与者位于系统边界之外，⽽不是系统的⼀部分。
3、参与者是从现实世界中抽象出来的⼀种形式，却不⼀定确切对应的现实中的某个特定对象。
符号：如何确定参与者？通过对参与者进⾏关注和分析，我们可以把重点放在如何与系统交互这⼀问题上，便于进⼀步确定系统的边界。
另外，参与者也决定了系统需求的完整性。
确定参与者可以从以下⼏个⾓度来考虑：1）为系统提供输⼊的⼈或事物2）接收系统输出的⼈或事物3）需要接⼊的第三⽅系统或设备4）时间是否会触发某些事件5）负责⽀持或维护系统中信息的⼈系统中的参与者⼀般可以分为四类：主要业务参与者：主要从⽤例的执⾏中获得好处的关联⼈员。
主要系统参与者：直接同系统交互以发起或触发业务或系统事件的关联⼈员。
外部服务参与者：响应来⾃⽤例的请求的关联⼈员。
外部接收参与者：从⽤例中接收某些价值或输出的⾮主要的关联⼈员。
参与者的泛化关系当系统中的⼏个参与者既扮演⾃⾝的⾓⾊，同时也有更⼀般化的⾓⾊时，可以通过建⽴泛化关系来进⾏描述。
与类相似，⽗参与者可以是抽象的，即不能创建⼀个⽗参与者的直接实例，这就要求属于抽象⽗参与者的外部对象⼀定能够属于其⼦参与者之⼀。
UML用例图描述
用例名称
系统管理员登录
标识符001用Fra bibliotek描述系统管理员通过设置的用户名和密码登录到学生管理系统
参与者
系统管理员
优先级
1
状态
等待审查
前置条件
学生管理系统正常运行
后置条件
如果管理员登录成功，则可以对学生基本信息进行管理，包括录入，删除，修改，查询学生基本信息，并且可修改自己的密码；如果管理员登录不成功，则不能对学生基本信息进行操作。
2.系统管理员无用户名先进行注册，再输入正确的用户名和密码顺利登录，并对学生基本信息进行操作
3.系统管理员忘记用户名和密码，通过手机动态密码进行验证，找回密码，再输入正确的用户名和密码顺利登录，并对学生基本信息进行操作
被泛化的用例
无
被包含的用例
查学生基本信息
被扩展的用例
无
用例“查学生基本信息”的描述
基本操作流程
1.系统管理员进入学生管理系统
2.系统管理员输入用户名和密码
3.系统管理员提交输入信息
4.系统对系统管理员输入的用户名和密码进行有效性检查
5.系统管理员对学生基本信息进行操作
可选操作流程
1.系统管理员输入正确的用户名和验证码，错误的密码无法顺利登录，重新输入正确的用户名和密码顺利登录，并对学生基本信息进行操作
用例名称
查学生基本信息
标识符
002
用例描述
系统管理员输入要查看的学生的基本信息，系统显示该学生的详细信息
参与者
系统管理员
优先级
2
状态
等待审查
前置条件
学生管理系统正常运行
后置条件
系统管理员输入学生的基本信息，可查看学生的详细信息
UML用例图的基本概念
UML的用途
需求分析
UML可以帮助开发人员更好地理 解客户需求，通过用例图等工具 将客户需求转化为可执行的用例。
系统设计
UML可以帮助开发人员在系统设 计阶段进行系统架构和组件的设 计，通过类图、时序图等工具进 行系统的分析和设计。
05
案例分析
案例一：简单登录系统用例图分析
总结词：简单明了
详细描述：简单登录系统通常包括用户名和密码输入、验证和登录成功或失败的反馈等基本功能。在 UML用例图中，可以清晰地表示出系统的主要功能和参与者的角色。
案例二：网上购物系统用例图分析
总结词：复杂多样
详细描述：网上购物系统涉及到多个参与者，如顾客、管理员和供应商等，以及多种复杂的业务功能，如商品展示、购物车 管理、订单处理和支付等。在UML用例图中，需要对各个功能进行详细的描述和分类，以便更好地理解系统的结构和功能。
用例图在系统设计中的应用
架构设计
用例图可以用于指导系统的架构设计，通过分析用例之间 的关系和交互，设计系统的组件和模块结构。
01
接口设计
用例图可以帮助设计系统组件之间的接 口，明确组件之间的输入输出关系和交 互协议。
02
03
系统流程设计
用例图可以用于描述系统的流程，通 过分析用例的执行顺序和交互逻辑， 设计系统的流程和顺序结构。
用例图在需求分析中的应用
1 2
沟通工具
用例图作为一种可视化图形表示，可以作为沟通 工具，帮助开发团队、客户和利益相关者理解系 统的需求和功能。
需求确认
通过绘制用例图，可以与利益相关者讨论和确认 系统的需求，确保对需求的理解和期望是一致的。
UML中共有5种静态图
UML中共有5种静态图：用例图，类图，对象图，组件图和配置图。
（1）用例图Use Case Diagram用例图展现了一组用例、参与者以及它们之间的关系可以用来描述系统的静态使用情况。
上图中小人形状的用户和ATM是参与者、椭圆形状的如插入卡、输入密码等是用例（2）类图Class Diagram类图展示了一组类、接口、子类以及他们之间的关系，在建模中最常用到的图就是类图；可以用类图说明系统的静态设计视图，包含主动类的类图。
上图中反应了5个类之间的关联关系，人民币账户和美元帐户从账户继承，账户和ATM相关联，两种账户和用户相关联（3）对象图Object Diagram对象图展示了一组对象和他们间的关系，可以用来说明类图中翻译的事物实例的数据结构和静态快照，表达了系统的静态设计视图和静态过程视图，除了显示和原型方面的因素外，它与类图的作用是相同的。
（4）组件图Component Diagram组件图，又名构件图，展现了一组组件之间的组织和依赖，用于对源代码、可执行的发布、物理数据库和可调整的系统建模。
上图中组件1和组件3依赖于组件2（5）配置图Deployment Diagram配置图展现了对运行时处理节点以及其中组件的配属，它描述系统硬件的物理拓扑结构，以及在此结构上执行的软件。
用配置图说明系统结构的静态配置视图，即说明分布、交互和安装的物理系统。
上图中，三个处理机与两个涉笔，相互之间是关联的关系UML中动态图有四种，分别是：时序图、协作图、状态图和活动图。
（1）时序图Sequence Diagram时序图展现了一组对象和由这组对象收发的信息，用于按时间顺序对控制流建模。
可以用时序图来说明系统的动态视图。
这里貌似有不同的说法Visual Paradigm里面叫时序图为Timing Diagram，而我参照的教材里边没有这种图，按理说是应该有的。
上图反应了用户与ATM交互的整个过程。
（2）协作图Collaboration Diagram协作图展现了一组对象之间的链接以及这组对象收发的消息，强调收发消息对象的组织结构，按组织结构对控制流建模。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
2012年 2012年4月
UML与设计模式 与设计模式
18/60 18/60
要点2 要点2：主动语句
欧文丛贝克汉姆处得到传球，守门员 欧文丛贝克汉姆处得到传球，守门员… 贝克汉姆传球给欧文，欧文射门，守门员扑救… 贝克汉姆传球给欧文，欧文射门，守门员扑救 图书管理员…… 图书管理员 系统…… 系统
UML与设计模式 与设计模式
17/60 17/60
要点1 只写“可观测” 要点1：只写“可观测”的
系统通过ADO建立数据库连接，传送SQL查询语 建立数据库连接，传送 系统通过 建立数据库连接 查询语 商品表”查询商品的详细信息… 句，从“商品表”查询商品的详细信息 系统按照查询条件搜索商品的详细信息
2012年 2012年4月
UML与设计模式 与设计模式
13/60 13/60
用例阐述组成
用例名称 用例概述 涉及的参与者 前置条件Preconditions 前置条件 后置条件Postcondition 后置条件 事件流Flow of events 事件流 分支流Subflows 备选流Alternate flow
2012年 2012年4月
UML与设计模式 与设计模式
11/60 11/60
“Borrow Book”用例中的场景 Book”用例中的场景
如，在“Borrow Book”这个用例中，包含着几 ”这个用例中， 个相关的scenario： 个相关的 ： Scenario-1：顺利地借到书 ： Scenario-2：该种书刊不存在 ： Scenario-3：物理书刊都已借出 ： Scenario-4：没有该借阅者信息 ：
2012年 2012年4月 UML与设计模式 与设计模式
3/60
1、用例图：参与者（Actors） 用例图：参与者（Actors）
参与者定义了一组与系统有信息交互关系的人、 参与者定义了一组与系统有信息交互关系的人、 它是用例的客户并与用例进行交互。 事、物。它是用例的客户并与用例进行交互。 一个参与者针对每一个与之通信的用例扮演一 种角色。 种角色。 角色可以是人或外部系统。 角色可以是人或外部系统。它定义了系统的边 界。
2012年 2012年4月 UML与设计模式 与设计模式
15/60 15/60
前置、后置条件(2) 前置、后置条件(2)
某些用例依赖于其他用例 一个用例在离开系统时， 一个用例在离开系统时，可能是另一个用例的 前置条件（例如： 登录” 管理系统” 前置条件（例如：“登录”和“管理系统”） 有助于识别漏掉的用例 如果一个用例的前置条件不能有执行其他用例 满足，可能意味着丢失了用例（例如： 满足，可能意味着丢失了用例（例如：“管理 订单”却没有“登录”用例） 订单”却没有“登录”用例）
状态图 活动图
部署图
2012年 2012年4月
UML与设计模式 与设计模式
2/60
UML图的作用 UML图的作用
UML 可以用于: 可以用于:
使用用例 使用用例（use cases）和参与者（actors） 用例（ cases）和参与者（actors） 描述系统的边界和它的主要功能。 描述系统的边界和它的主要功能。 使用交互图 顺序图、协作图） 交互图（ 使用交互图（顺序图、协作图）具体描述用 例的实现。 例的实现。 使用类图表示系统的静态结构。 类图表示系统的静态结构 使用类图表示系统的静态结构。 使用状态转换图模型化对象的行为。 状态转换图模型化对象的行为 使用状态转换图模型化对象的行为。 使用构件图和部署图 使用构件图和部署图展现系统的物理实现体 构件图和部署图展现系统的物理实现体 系结构。 系结构。 使用衍型（stereotypes）扩展建模能力。 使用衍型（stereotypes）扩展建模能力。
2012年 2012年4月
UML与设计模式 与设计模式
16/60 16/60
事件流描述要点
1.只书写“可观测”的 只书写“可观测” 只书写 2.使用主动语句 使用主动语句 3.句子必须以参与者或系统作为主语 句子必须以参与者或系统作为主语 4.不要涉及界面细节 不要涉及界面细节
2012年 2012年4月
识别用户
子用例可以出现在父用例 出现的任何位置
验证口令 扫描指纹
2012年 2012年4月
UML与设计模式 与设计模式
10/60 10/60
用例阐述文档
场景（ 场景（scenario）： 是参与者和被讨论系统之间 ）： 的一系列特定活动和交互。 的一系列特定活动和交互。每个用例是一组场景的 集合，而每个场景又是一个步骤序列。 集合，而每个场景又是一个步骤序列。 用例阐述文档针对每个用例， 用例阐述文档针对每个用例，描述各个场景
Maintain Curriculum 2012年 2012年4月
Request Course Roster UML与设计模式 与设计模式
Maintain Schedule
5/60
用例之间关系
《include》 》
包含
《extend》 》
扩展 泛化 使用
<<使用>> <<使用>> 使用
2012年 2012年4月
2012年 2012年4月 UML与设计模式 与设计模式
14/60 14/60
前置、后置条件(1) 前置、后置条件(1)
前置条件约束在用例开始前系统 的状态 把它们看做是看门人， 把它们看做是看门人，它阻 止参与者触发该用例直到满 足所有条件 说明在用例触发之前什么必 须为真 后置条件约束用例执行后系统的 状态 用例执行后什么必须为真 对于有多个事件流的用例， 对于有多个事件流的用例， 则应该有多个后置条件
2012年 2012年4月
UML与设计模式 与设计模式
9/60
泛化关系（generalization） 泛化关系（generalization）
和类一样， 和类一样，泛化是指一个用例继承了另一个用 在用例继承中， 例，在用例继承中，子用例可以从父用例继承 行为和含义，还可以增加自己的行为。 行为和含义，还可以增加自己的行为。
kitchen
COURTYARD
dressing room
Elena
User Interface for Status
living room
Current life OK points: 56.38
Get status Set qualities End game
Strength Endurance Endurance Intelligence Patience
2012年 2012年4月
UML与设计模式 与设计模式
12/60 12/60
谁来写用例文档
最完美：业务人员接受训练，写出优美的用例文 最完美：业务人员接受训练， 档 最现实：业务人员提供素材， 最现实：业务人员提供素材，开发人员写用例文 档 最糟糕：业务人员不管， 最糟糕：业务人员不管，完全由开发人员杜撰
2012年 2012年4月
UML与设计模式 与设计模式
19/60 19/60
要点3 要点3：以参与者或系统作主语
参与者…… 参与者 系统…… 系统 图书管理员输入书目和借阅者信息； 图书管理员输入书目和借阅者信息； 系统检索书目 系统检索借阅者 图书管理员将图书借给借阅者 系统记录借阅信息 …..
2012年 2012年4月 UML与设计模式 与设计模式
20/60 20/60
要点4 要点4：不涉及界面细节
会员从下拉框中选择类别 会员在相应文本框中输入查询条件 会员点击“确定” 会员点击“确定”按钮
2012年 2012年4月
UML与设计模式 与设计模式
21/60 21/60
Encounter Courtyard Image (including game characters)
扩展用例是在原用例的基础上增加新的步骤序 列形成的。 列形成的。 原用例被称为基用例 基用例（ case）。 ）。扩展 原用例被称为基用例（base use case）。扩展 只能发生在基用例的序列中的某个具体制定点 这个点叫做扩展点 扩展点（ points）。 上，这个点叫做扩展点（extension points）。
2012年 2012年4月
UML与设计模式 与设计模式
8/60
扩展关系 VS 包含关系
在扩展关系中， 在扩展关系中，基用例不必知道扩展用例 的任何细节，事实上基用例没有扩展也是 的任何细节，事实上基用例没有扩展也是 完整的，只有特定的条件发生了， 完整的，只有特定的条件发生了，扩展用 例的行为才被执行，而包含关系则不同。 例的行为才被执行，而包含关系则不同。
要调查参与者以确定他们的要求： 要调查参与者以确定他们的要求：
Registrar（注册管理员）－ Registrar（注册管理员）－ 维护所有课程信息 Professor（教授）－ Professor（教授）－ 要求选课名单 Student（学生）－ Student（学生）－ 维护选课表 Billing System（记账系统）－ 从注册中心接受 System（记账系统）－ 记账信息
player
Initialize Use Case for Encounter
actors Encounter Use case Initialize Travel to adjacent area Encounter foreign character designer Set rules Use case details Initialize 1. System displays player’s main character in the dressing room. 2. System displays a window for setting his character's qualities. 3. Player allocates the qualities of his main character. 4. Player chooses an exit from the dressing room. 5. System moves player’s main character into the area on the other side of the exit.