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、系统通过库存系统验证要购买的商品是否有足
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用例图、流程图)
产品需求文档的写作(五) –用例文档(UML用例图、流程图)在产品和技术领域里都有UML的技能知识，而对于产品人员的UML则更多的是指用例图，也就是我所称呼的用户流程图。
在讲PRD文档写作的第二篇文章里，我提到了用户流程图的制作，实际上用户流程图是我在产品规则的初期对用例图的一种结构化的表达方式，由于以结构化的方式描述用例太抽象，缺少逻辑性表达，并且那篇文章更偏向于功能性用户流程，还不是实际意义上的用例，因此今天我补文一篇，细讲一下UML用例图和用例文档。
用例文档是由多个用例组成的一份文档，主要用于技术开发与测试使用，他是PRD中的重要辅助文档，用于讲解某个环节的功能逻辑，例如用户注册、活动报名等等功能都是需要用例辅助说明的。
用例文档的写作时间在原型设计之后，通常和PRD文档同步撰写。
用例文档中有两个关联文件，分别是用例图和流程图。
用例图是UML的一种类图表现方式，是从用户角度描述产品功能，并指出该用户在产品各功能中的操作权限。
流程图是通过线框图形的方式描述产品功能的处理过程，主要是描述功能的执行顺序、分支和循环的逻辑。
写用户文档的常用软件是Word，其中用例图和流程图的制作软件常用的是Visio，当然也有用Axure RP软件制作的，例如下面的第三步流程图就是用Axure RP制作的。
一份完整的用例文档分别是由以下三点内容组成，其中第3点的“用例”是描述功能逻辑的部分，根据功能的多少决定有多少个用例。
用例文档的大概组成部分如下：1、修改记录：每次修改的备注记录，同PRD文档。
2、角色介绍：描述参与系统中的各个角色3、用例：同下方步骤的第4步，其中第3步中的流程图是直接插入到第4步的流程图表格项中的。
用例文档的模板格式如同以上三点内容，通过Word文档绘制表格，在表格中撰写用例描述，表格的格式和样式参考以下示例图。
1、撰写用例文档的第一步是注明使用产品的各个角色(参与者)和角色说明(角色介绍)。
学生管理系统用例图、类图、对象图的绘制(UML)
参与者1--系统管理员：参与Biblioteka 2--教师：参与者3—学生：
类图与对象图的绘制
有一个学生管理系统，其中有参与者三人，分别为系统管理员、教师和学生，需求如下：
（1）系统管理员登录系统后，通过身份验证，能够对学生的基本信息进行管理，包括录入学生基本信息、修改学生基本信息、查询学生基本信息、删除学生基本信息，并且可以找回自己的密码。
（2）教师在日常管理中可以登录系统，如果忘记了自己的密码，则可以找回。可以通过系统查询、修改和删除学生的考试成绩。当考试结束后，教师有权将学生成绩录入系统。
UML图书管理系统类图 文档
图书借阅系统用例分析1。
用户采用用例图描述的图书借阅系统主要包括三类用户:读者、图书管理员、系统管理员。
其中，读者是多个，图书管理员是几个，系统管理员是一个。
1.1读者描述：读者可以借阅、预约、续借、归还图书，可以对书籍和个人信息进行查询，可以取消预约，可以提出办理图书借阅证的申请。
示例:持有图书借阅证的任何人。
1.2图书管理员描述：图书管理员对图书信息维护，包括图书订购、新书入库、破损修补、旧书下架，另外还对读者信息进行管理，进行借阅登记等.示例：图书管理员1。
3系统管理员描述：系统管理员对系统进行维护，包括读者信息的创建、修改、删除,日志维护，权限维护,后台数据维护，还有系统信息的维护。
示例：系统管理员2.用例通过识别的参与者，对需求进一步分析，将业务需求进行分解，获得每个参与者的使用用例：2.1读者（1)读者办卡:提供为读者办理借书证的功能（2）书籍查询：为读者提供书籍查询功能(3）书籍借阅:提供借阅书籍的功能（4)书籍续借：提供续借书籍的功能（5）书籍预约：提供对某一书籍的预约功能（6）取消预约：提供对预约进行取消的功能（7）书籍归还:提供归还书籍的功能（8）读者信息查询：为读者提供个人信息查询的功能（9）缺书登记：当读者需要的书籍查询书库没有记录时，读者可将此书进行缺书登记2.2图书管理员（1）图书信息维护图书订购：参考各类图书的库存数和借阅率及缺书登记,对书籍进行统一采购新书入库：将新书到货进行编号入库书籍破损修补：当书籍有损坏时进行修补旧书下架：将遗失或淘汰的书籍从书库中清除（2)读者信息管理(3）借阅书籍登记2。
3系统管理员（1）系统维护：维护图书借阅系统的系统结构(2）日志维护：维护系统中各种日志，如借阅记录、书籍记录等(3）权限维护：确定系统各参与者的权限，维护相关权限（4)增删用户：增加或者删除用户及相关信息（5）后台数据维护:维护系统后台数据库中的各种数据3。
用例图3。
1用例说明4 类图在用例分析基础之上，根据需求可建立起系统的静态数据模型，即建立系统类图。
UML实践----用例图、顺序图、状态图、类图、包图、协作图
UML实践----用例图、顺序图、状态图、类图、包图、协作图2009-01-20 作者：Randy Miller 来源：网络面向对象的问题的处理的关键是建模问题。
建模可以把在复杂世界的许多重要的细节给抽象出。
许多建模工具封装了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描述了作为一个外部的观察者的视角对系统的印象。
UML用例图的主要元素解析与使用方法
UML用例图的主要元素解析与使用方法UML（Unified Modeling Language）是一种用于软件系统建模的标准化语言，用例图是UML的一种图表类型，用于描述系统的功能需求和用户与系统之间的交互。
在软件开发过程中，用例图是非常重要的工具，它能够帮助开发团队更好地理解系统需求，设计出更合理的系统架构。
本文将对UML用例图的主要元素进行解析，并介绍其使用方法。
一、参与者（Actors）参与者是指与系统进行交互的实体，可以是人、其他系统或外部设备。
在用例图中，参与者用一个小人的图标表示。
参与者与系统之间通过用例进行交互。
一个参与者可以在多个用例中出现，也可以在一个用例中有多个参与者。
二、用例（Use Cases）用例是对系统功能的描述，它表示系统为参与者提供的一项功能或服务。
用例图中，用例用一个椭圆形图标表示。
每个用例都有一个名称，通常使用动词短语来描述功能。
用例之间可以有关系，如包含关系（include）、扩展关系（extend）等。
三、关系（Relationships）在用例图中，参与者与用例之间可以有不同类型的关系，如关联关系（association）、包含关系（include）、扩展关系（extend）等。
关联关系表示参与者与用例之间的关联，包含关系表示一个用例包含另一个用例，扩展关系表示一个用例可以扩展另一个用例。
四、系统边界（System Boundary）系统边界是用于表示系统的边界，用一个矩形框表示。
在用例图中，系统边界将参与者和用例包围在内，表示系统的范围和边界。
五、泛化（Generalization）泛化是一种继承关系，用于表示两个用例之间的继承关系。
在用例图中，泛化关系用一个带有箭头的实线表示，箭头指向父用例。
六、扩展点（Extension Points）扩展点用于表示一个用例可以被扩展的地方。
在用例图中，扩展点用一个小圆圈表示，并与扩展用例之间用虚线连接。
使用UML用例图进行系统建模时，需要按照以下步骤进行：1. 确定参与者：首先，需要确定系统中的参与者，包括用户、其他系统或外部设备。
UML中的用例与类图之间的关联关系
UML中的用例与类图之间的关联关系UML（Unified Modeling Language）是一种用于软件系统建模的标准化语言，它提供了一套丰富的图形符号和规范，用于描述和设计软件系统的结构和行为。
在UML中，用例图和类图是两个重要的建模工具，它们分别用于描述系统的功能需求和结构设计。
本文将探讨用例图和类图之间的关联关系，以及它们在软件开发过程中的应用。
一、用例图的作用和特点用例图是一种用于描述系统功能需求的图形表示方法。
它通过用例（Use Case）和参与者（Actor）之间的关系来描述系统的功能和行为。
用例图可以帮助开发团队和用户明确系统的功能需求，从而指导软件系统的开发和测试工作。
用例图的特点在于它强调系统与外部参与者之间的交互关系。
一个用例表示系统的一个功能需求，而参与者则表示与系统进行交互的外部实体，如用户、系统管理员等。
用例图通过箭头来表示参与者和用例之间的关系，例如，一个参与者可以执行多个用例，一个用例也可以被多个参与者执行。
二、类图的作用和特点类图是一种用于描述系统结构设计的图形表示方法。
它通过类（Class）、关联（Association）、继承（Inheritance）等元素来描述系统中的对象和它们之间的关系。
类图可以帮助开发团队明确系统的结构和组织，从而指导软件系统的设计和实现工作。
类图的特点在于它强调系统中对象之间的关联关系。
一个类表示系统中的一个对象，而关联则表示对象之间的关系。
类图通过线条和箭头来表示类和关联之间的关系，例如，一个类可以关联到另一个类，表示它们之间存在某种关联。
类图还可以使用继承关系来描述类之间的层次结构，例如，一个类可以继承自另一个类，表示它们之间存在父子关系。
三、用例图和类图的关联关系用例图和类图之间存在着紧密的关联关系。
用例图描述了系统的功能需求，而类图描述了系统的结构设计。
用例图中的用例可以通过类图中的类来实现，从而满足系统的功能需求。
具体来说，用例图中的用例可以通过类图中的类的操作来实现。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
中软培训
用例要点： ? 价值结果→有意义的目标 ? 系统执行→价值结果由系统生成 ? 执行者可见→业务语言，用户观点 ? 一组用例实例→用例的粒度
识别用例
有意义பைடு நூலகம்目标：
中软培训
识别用例
用户观点而非系统观点：
中软培训
用户观点
系统观点
识别用例
用例命名：执行者视角
动词（+宾语） 状语 定语
中软培训
识别用例
问
题
UML三个主要作用（1） 中软培训
? 理由一：UML是客户、系统分析员和程序员之间的“桥梁”
使用可视化建模来获取并表现商业逻辑和对象
? 用例图 ? 活动图 ? 状态图
使用可视化建模来分析和设计计算机应用程序
? 时序图 ? 对象图 ? 部署图 ? ……
UML三个主要作用（2）
? 理由二：UML从客户的角度将复杂的系统整理清楚
书写用例文档
——用例的内容
中软培训
书写用例文档
——涉众利益
利益的冲突
中软培训
银行的 用户的 法律的
谁的？
书写用例文档
中软培训
——路径交互步骤的描述
?只写“可观测的” ?使用主动语句 ?句子必须以执行者或系统作为主语 ?每一句都要朝目标迈进 ?分支和循环 ?不要涉及界面细节
书写用例文档
——字段列表
实现模块和代码间的关系 系统物理拓扑架构
模型可由9个图来展现
墨绿色表示动态图 粉红色表示静态图 （可把用例图单列出来）
Use Case DUiDasgiae时rgaCrm序aams图e
功能
UDsUiaesgeCraaCmsaese Dia用gr例am图
DiSatgSarttaaemte Diag类ra图m
可互换
行
为 可互换
主要步骤
中软培训
识别执行者
中软培训
——执行者（Actor ）
在系统之外，透过系统边界与系统进行有 意义交互的任何事物。
识别执行者
中软培训
执行者要点： ? 系统外——必须和它交互 ? 系统边界 ——直接与系统交互 ? 有意义的交互 ——属于目标系统的责任 ? 任何事物 ——人、外系统、外部因素、时间
识别用例
中软培训
用例的粒度（6）：灵活处理CURD
也可以把包含复杂交互的路径独立出去形成用例
识别用例
中软培训
执行者使用这个系统达到什么目标？ 语法测试：【执行者】使用系统来【用例】
识别用例
讨论（1）：登录怎么处理？
中软培训
识别用例
讨论（2）：几个登录？
中软培训
或
用例文档：更进一步的精度 中软培训
用例的粒度（3）：四轮马车
中软培训
警惕CURD泛滥！
任何业务归根到底都可以看作 CURD，但光CURD能为Actor 提供价值吗？
CRUD 是Create （创建）、 Read（读取）、 Update （更新）和 Delete （删除）缩写
识别用例
用例的粒度（3）：四轮马车误区
中软培训
多个用例会操作同一项数据
用表达式
书写用例文档
——可用性
× ?系统应易于使用
中软培训
?第一次使用时30分钟内能学会添加员工（任务时间）
√ ?5次击键能完成客人入住服务，不需要使用鼠标（操作次 数） ?80%的用户认为系统易学，并且使用效率高（用户调查）
?+ → 数据序列
? []→
可选项
?{}* → 多个
?{ | | | } → 可能取值
?A=B → 把B的结构赋给A
中软培训
可以用自然语言，也可以用表达式
书写用例文档
——字段列表
中软培训
?注册信息=公司名+联系人+电话+{联系地址}* ?联系地址=州+城市+街道+邮编 ?保存信息=注册信息+注册时间 ?客房状态={空闲|已预定|占用|维修中}
D部iagr署am 图
物理架构
UML9种图
中软培训
? 用例图：业务建模、需求、测试 ? 类图：业务建模、分析、设计 ? 对象图：业务建模、分析、设计 ? 组件图：设计 ? 部署图：设计
敏捷建模原则：需要时再添加
结 构
? 顺序图：业务建模、分析、设计 ? 协作图：业务建模、分析、设计 ? 状态图：需求、分析、设计 ? 活动图：业务建模、设计
识别执行者
中软培训
思路： ? 谁使用了系统的主要功能？ ? 谁改变了系统的主要数据？ ? 谁从系统获取信息？ ? 谁需要系统的支持以完成日常工作任务？ ? 谁负责维护、管理并保持系统正常运行？ ? 系统需要应付（处理）哪些硬件设备？ ? 系统需要和哪些外部系统交互？ ? 谁（或什么）对系统运行产生的结果感兴趣？ ? 有没有自动发生的事件？
中软培训
UML实用技术
V1.0
软件开发过程详解
中软培训
? 目前的现实是什么？——业务建模
找
? 在这个现实下，开发系统是为了达到什么目标？ ——愿景
到
问
? 为了达到目标，系统应对外提供什么样的功能和性能？ ——需求
题
解
? 为了提供这些功能，系统内部应该有什么样的核心业务机制？ ——分析
决
? 为了满足性能，系统的核心机制如何在选定的架构上实现？ ——设计
用例图可以作用例文档的总图 进一步的精度：有层次的文档 文档中每一句话都有其价值
? 用例编号：用例名 ? 执行者 ? 前置条件 ? 后置条件 ? 涉众利益 ? 基本路径
? 1……XXXX ? 2……XXXX ? 3……XXXX
? 扩展
? 2a.……XXXX
? 2a1.……XXXX
? 字段列表 ? 业务规则 ? 非功能需求 ? 设计约束 ? 待解决问题
识别执行者
中软培训
责任类似或重叠——抽象出执行者
识别用例
中软培训
用例的基本定义：
步骤
用例实例是 在系统中执行 的一系列动作 ，这些
动作将生成特定 执行者可见 的价值结果。一个
用例定义一组用例实例 。
目标
路径 ——Ivar Jacobson （RUP）
通俗地讲：执行者通过系统达到某个目标
识别用例
中软培训
静态结构
State DiDagiSa对rtgaarm象taem图
动
态 行 为
SDciSDaecgina协eraganrrmai作aormio图
模型
DiSatgSarttaaemte Dia组gr件am图
SDcSiDaecgina状eraganrrmai态aormio图
活动图
Component DCioamgrpaomnent
中软培训
UML三个主要作用（3） 中软培训
? 理由三：UML能使越来越复杂的软件 系统架构更加合理和健壮
功能需求
成本
兼容性
容量
错误处理
稳定性
software
容错性
性能
全面
技术交互
可移植
系统模型可由“4+1”视图展现 中软培训
逻辑视图
实现视图
分析设计结构
系统功能
用例视图
进程视图
部署视图
系统并发工作情况