用例建模步骤
利用用例图描述用户需求
（4）用例的命名
每个用例应有唯一的名称 命名的方式：用例通常用动词 + 名词短语来命名---如：登录系统
请见文档中的说明 书写用例的模板格式
四、UML中的用例图
1、用例图 （1）什么是用例图
提供用例图的目的之 一是下面的描述
用例图是一种图形化的工具，它用简单的图形元素表示出 系统的参与者、用例以及它们之间的联系
（2）用例图中的参与者和用例之间的通信
参与者和用例之间的使用关系，在用例图中表示为一个 带箭头的直线
二、UML中的用例之间的关系
1、用例之间的关系
主要体现在纵向方面的层次化关系和横向方面的关联性和 包含
（1）用例的层次化（纵向方面）
按照抽象层次，用例可以划分为系统层（最高层）、子系 统层（可以再细分）和对象类层（最低层）。 系统层用例图：描述系统提供的全部主要的功能或服务。 子系统层用例图：描述某一子系统所应该提供的服务，它 的外部交互者可以是其他的子系统或高一层的参与者。 对象类层的用例图描述对象类提供的功能片或操作，它的 外部交互者可以是其他对象类或高一层活动者。
（3）用例图的组成元素
在一个用例图中，一般主要 包含有 系统边界 参与者 用例和用例关系 （泛化、使用和扩展等 三种形式）。
这在前面已经 加以说明过
2、用例图的主要作用 （1）面向用户
可以实现从用户角度来描述系统所应该具有的功能，同时 并能够指出各功能的操作者； 也能够显示出与系统进行交互的外部参与者及其使用方式。 （2）面向开发者 表示正在构造的新系统应该具有的功能 同时对已经构造完毕的系统，则反映了系统能够完成什么 样的功能
用例建模
10 1-10
ATM例子 寻找参与者 – ATM例子
1）如果我们所要定义的系统边界仅限于ATM机本身， 如果我们所要定义的系统边界仅限于ATM机本身， ATM机本身 那么后台服务器就是一个外部的系统， 那么后台服务器就是一个外部的系统，可以抽象为一个 参与者。 参与者。
2）如果我们所要定义的系统边界扩大至整个银行系统， 如果我们所要定义的系统边界扩大至整个银行系统， ATM机和后台服务器都是整个银行系统的一部分 机和后台服务器都是整个银行系统的一部分， ATM机和后台服务器都是整个银行系统的一部分，这时 候后台服务器就不再被抽象成为一个参与者。 候后台服务器就不再被抽象成为一个参与者。
17 1-17
使用角色和用例图组织你的用例
用例图是在一个图上显示了多个用例, 用例图是在一个图上显示了多个用例 它是一组用例的 全景图. 有时候角色我们称呼为用户,但是常常会指定一 全景图 有时候角色我们称呼为用户 但是常常会指定一 个具体的角色名称(比如 顾客).用户或者说角色位于系 比如:顾客 个具体的角色名称 比如 顾客 用户或者说角色位于系 统边界之外. 而系统在边界内. 统边界之外 而系统在边界内 角色也可以指非人类的外 部系统,但有时候许多人对这一点迷惑不解 但有时候许多人对这一点迷惑不解,我们已经发 部系统 但有时候许多人对这一点迷惑不解 我们已经发 现使用机器人这种图标可以消除这种迷惑误解. 现使用机器人这种图标可以消除这种迷惑误解 在用例和角色之间的连线表示这个角色是用例的执行者. 在用例和角色之间的连线表示这个角色是用例的执行者 这根连线也表示责任.比如 一个Customer(顾客 指向用 比如:一个 顾客)指向用 这根连线也表示责任 比如 一个 顾客 表示这个顾客负责执行check out(结帐 结帐) 例check out,表示这个顾客负责执行 表示这个顾客负责执行 结帐 可以有多个角色指向同一个用例.表示这个用例与多个 可以有多个角色指向同一个用例 表示这个用例与多个 角色关联.同样的 一个用户可以拥有多个角色.同一个用 同样的,一个用户可以拥有多个角色 角色关联 同样的 一个用户可以拥有多个角色 同一个用 户可以是一个职员,也可能是一个管理员 也可能是一个管理员. 户可以是一个职员 也可能是一个管理员
简述用例图的一般建模流程及步骤
简述用例图的一般建模流程及步骤下载温馨提示:该文档是我店铺精心编制而成，希望大家下载以后，能够帮助大家解决实际的问题。
文档下载后可定制随意修改，请根据实际需要进行相应的调整和使用，谢谢!并且，本店铺为大家提供各种各样类型的实用资料，如教育随笔、日记赏析、句子摘抄、古诗大全、经典美文、话题作文、工作总结、词语解析、文案摘录、其他资料等等，如想了解不同资料格式和写法，敬请关注!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!用例图是一种用于描述系统功能和用户与系统之间交互的图形化工具。
hbn正确使用顺序
hbn正确使用顺序正确使用HBN的顺序可以分为以下几个步骤：第一步：需求分析（200字）在进行HBN之前，首先需要明确项目的需求。
通过与相关利益相关者的沟通和需求获取工具的使用，收集并明确项目的功能和非功能需求。
这一步骤的重点是确保对项目的需求有一个清晰准确的了解，以便后续步骤的执行。
第二步：用例建模（400字）用例建模是HBN的核心步骤之一，通过用例建模可以对系统的行为进行具体描述，并且可以从用户的角度看待系统的功能。
一般来说，这一步骤包括以下几个方面：1.确定主要的用户角色和相关联的用例：确定系统将要涉及到的主要用户角色（如管理员、普通用户等），以及每个用户角色可以执行的用例。
2.编写用例描述：对每个用例编写详细的描述，包括用例的名称、前置条件、主要步骤和预期结果等。
3.确定用例之间的关系：确定用例之间的关系，比如哪些用例是可选的、哪些用例是必需的等。
第三步：领域建模（400字）领域建模是指对系统的业务对象进行分析和描述，以便于更好地理解和表达系统的领域知识。
这一步骤通常包括以下几个方面：1.识别业务对象：确定系统中的主要业务对象，如用户、产品、订单等。
2.分析业务对象之间的关系：分析业务对象之间的关系，如用户可以创建订单、产品可以被用户购买等。
3.绘制类图：根据业务对象和它们之间的关系，绘制类图来描述系统的领域知识。
第四步：交互建模（400字）交互建模是指对系统的用户界面和交互流程进行建模，以便于更好地理解和表达系统的用户操作过程。
这一步骤通常包括以下几个方面：1.绘制界面原型：通过绘制界面原型来描述系统的用户界面，包括页面布局、界面元素等。
2.分析用户操作流程：根据用例描述和界面原型，分析用户在系统中的操作流程。
3.编写交互图：根据用户操作流程，编写交互图来描述用户与系统的交互过程。
第五步：归纳分析（400字）归纳分析是指对之前建模结果进行归纳和分析，以便于更好地理解和表达系统的整体结构和行为。
业务建模及用例建模
业务建模及用例建模1. 业务建模业务建模是指通过对企业业务流程的描述和分析，来描绘企业的运营过程和业务逻辑关系。
它可以帮助企业理清业务流程，优化业务流程，并对业务进行管理和改进。
在软件开发过程中，业务建模也起到了重要的作用。
1.1 业务建模的目的和意义业务建模的目的是帮助企业更好地了解自己的业务流程，找出其中的问题和瓶颈，提出解决方案，并设计出更加高效的业务流程。
通过业务建模，企业可以减少资源浪费，提高业务效率，提升客户满意度。
1.2 业务建模的方法和工具在进行业务建模时，可以采用多种方法和工具，常用的有以下几种：•流程图：用于描述业务流程中的各个步骤和流程之间的关系。
可以直观地展示业务流程，帮助人们理清业务逻辑。
•EPC图：由由事件、功能和控制流组成的图形结构，用于描述业务流程中的各个步骤和流程之间的依赖关系。
•UML：包括用例图、活动图、类图等多种图表，用于描述软件系统的需求和设计。
1.3 业务建模的实施步骤进行业务建模时，可以按照以下步骤来进行：1.确定建模范围：明确需要建模的业务过程范围，确定建模的目标和侧重点。
2.收集业务信息：收集相关业务信息，包括业务流程、业务规则等。
3.描述业务流程：使用合适的建模工具，如流程图、EPC图等，描述业务流程中的各个步骤和流程之间的关系。
4.分析业务流程：对业务流程进行分析，找出问题和瓶颈，并提出改进建议。
5.优化业务流程：根据分析结果，对业务流程进行优化，设计更加高效的业务流程。
6.审核和验证：对优化后的业务流程进行审核和验证，确保其符合实际需求。
7.实施和改进：根据实际情况，将优化后的业务流程付诸实施，并不断进行改进和优化。
2. 用例建模用例建模是指通过对系统的功能需求进行描述和分析，确定系统与用户之间的交互行为和功能。
它可以帮助开发人员更好地理解用户需求，设计出更符合用户期望的系统。
2.1 用例建模的目的和意义用例建模的主要目的是用于系统需求分析和系统设计。
用例建模 用例规约
用例建模用例规约标题：点外卖系统用例建模与规范引言：随着互联网技术的快速发展，外卖行业迅猛壮大，点外卖已经成为人们日常生活中的一部分。
为了提高用户体验和系统效率，点外卖系统开发成为了一项重要的任务。
本文将通过用例建模与规约的方式，详细描述了点外卖系统的各个功能以及系统与用户之间的交互过程，旨在帮助开发团队和用户更好地理解和操作该系统。
一、用例建模1. 用户注册与登录- 用例名称：用户注册- 用例描述：用户需要提供个人信息进行注册，包括用户名、密码、手机号等，系统验证信息合法性后完成注册。
- 前置条件：用户打开点外卖系统，未登录状态。
- 后置条件：用户成功注册并登录系统，可进行下一步操作。
- 主要参与者：用户、系统。
- 触发事件：用户点击注册按钮。
- 用例步骤：1) 用户选择注册功能。
2) 用户填写个人信息并提交。
3) 系统验证信息合法性。
4) 系统生成唯一标识符并存储用户信息。
5) 系统自动登录用户。
2. 点餐与支付- 用例名称：用户点餐与支付- 用例描述：用户选择餐厅、浏览菜单、添加菜品到购物车，并进行支付操作。
- 前置条件：用户已注册并登录系统，进入特定餐厅界面。
- 后置条件：用户完成支付，生成订单，并进行配送。
- 主要参与者：用户、系统、餐厅。
- 触发事件：用户点击某个餐厅进入。
- 用例步骤：1) 用户选择特定餐厅。
2) 用户浏览菜单并添加菜品到购物车。
3) 用户选择支付方式并完成支付。
4) 系统生成订单，并通知餐厅。
5) 餐厅确认订单，并进行配送。
二、用例规约1. 用户注册规约- 前置条件：无。
- 后置条件：用户成功注册并登录系统。
- 基本流程：1) 用户打开点外卖系统，点击注册按钮。
2) 用户填写用户名、密码、手机号等个人信息并提交。
3) 系统验证信息合法性。
4) 如果验证通过，系统生成唯一标识符并存储用户信息，自动登录用户。
5) 如果验证失败，系统返回错误信息，用户重新填写信息。
- 异常流程：- 用户输入的用户名已被注册：系统返回错误信息，提示用户换一个用户名。
用例建模的步骤
用例建模的步骤嘿，咱今儿就来聊聊用例建模的那些事儿哈！你知道不，用例建模就像是搭积木，一块一块地拼出个精彩的模型来。
首先呢，咱得搞清楚需求，就像你要去旅行，得先知道自己想去哪儿，想看啥风景。
这一步可不能马虎，得瞪大了眼睛，竖起耳朵，把各种需求都搜罗过来。
然后呢，就是识别参与者啦！这就好比是找到一起搭积木的小伙伴，谁来跟咱一块儿玩这个游戏呀。
这些参与者可重要啦，他们会在这个模型里扮演各种角色呢。
接下来就是确定用例啦！这就像给每个小伙伴分配任务，你负责搭这个部分，他负责搭那个部分。
每个用例都代表着一个具体的功能或者活动。
再然后呀，就是描述用例啦！这可不能简单几笔带过，得详细地说说这个用例到底是咋回事儿，就像给小伙伴讲清楚他的任务该怎么做。
接着呢，要对用例进行排序。
这就像是给搭积木的步骤排个先后顺序，可不能乱了套。
再接下来，要检查用例模型。
这就好比搭完积木后，要看看有没有哪里不牢固，有没有缺块少角的。
最后，就是优化用例模型啦！把那些不合适的地方改一改，让这个模型更加完美。
你想想看，要是这每一步都没做好，那最后搭出来的模型能好看吗？能牢固吗？肯定不行呀！就好比盖房子，地基没打好，那房子能稳吗？咱再打个比方，用例建模就像做菜，需求就是食材，参与者就是厨师和食客，用例就是各种菜品，描述用例就是菜谱，排序就是做菜的先后步骤，检查就是尝尝味道对不对，优化就是调整口味让菜更好吃。
你说，这每一步是不是都很重要啊？所以啊，咱可得认真对待用例建模的每一个步骤，别马马虎虎的。
这可是关系到最后成果的好坏呢！咱可不能瞎糊弄，得用心去做，才能做出漂亮的用例模型来呀！你说是不是这个理儿呢？。
5-2 用户故事与用例建模
5-2 用户故事与用例建模
用户故事支持敏捷迭代计划
针对识别出的每一个故事，使用Story Point估算其工作量； – 故事点：一个达到共识的基本时间单位，例如1天； – 使用预定的值：1/2、1、2、3、5、8、13、20、40、80； 团队成员分别估计(而不是由项目经理一人决定)，差异较 大时面对面讨论，发现分歧，形成共识； 形成估算清单。
5-2 用户故事与用例建模
用户故事的描述
As a [user role] I want to [goal] so I can [reason] 作为一个<角色>, 我想要<活动>, 以便于<商业价值> Who (user role)
What (goal)
Why (reason) As a registered user I want to log in so I can access subscriberonly content. 作为一个“网站管理员”，我想要“统计每天有多少人访问了我的 网站”，以便于“赞助商了解我的网站会给他们带来什么收益”。
有时候需要在系统内部定时的执行一些操作，如检测系统资 源使用情况、定期生成统计报表等等； 但这些操作并不是由外部的人或系统触发的； 对于这种情况，可以抽象出一个系统时钟或定时器参与者， 利用该参与者来触发这一类定时操作； 从逻辑上，这一参与者应该被理解成是系统外部的，由它来 触发系统所提供的用例对话。 触发 系统时钟 周期性任务
用例模型容易构建、也容易阅读； 完全站在用户的角度上，从系统外部来描述功能； 帮助系统的最终用户参与到需求分析过程中来，其需求更容易 表达出来；Fra bibliotek软件工程
3 用例建模的基本过程
第7章_用例建模
参与者的特性： ①.参与者位于系统外部； ②.参与者与系统发生交互关系； ③.参与者与系统之间存在交互接口。
区分参与者和外部实体
• 只有在执行系统功能时与信息系统进行实时交 互的人员才能被当作参与者。
• 外部实体是指数据的来源和去向，提供数据的 人员不一定会执行系统功能
– 新生入学手工填写个人信息，然后由教务人员统一 将数据登记到学籍系统中，教务人员是参与者。
• 病人拿到挂号单后，到相应的科室进行 就诊。医生根据挂号的顺序号，依次给 病人看病开处方。
• 病人拿处方去收款处交费，并拿到发票。 • 病人拿已经收费的处方去药房拿药。
该系统潜在的参与者和用例有哪些？
用例图
用例图的作用：
用例图用来描述软件需求模型中的系统功能， 通过一组用例可以描述软件系统能够给用户提 供的功能。
⑤.从系统获取信息
有些参与者需要从系统获取必要的信息，例 如：
区分用例和用例完成的步骤
• 不能混淆用例和用例所包含的步骤。
– 比如“借出图书”功能要经过验证读者信息、检 查超出可借数量、保存借书记录、修改图书状态 等步骤
• 在系统中这些步骤通常不作为单独的功能提 供给参与者使用，它们只是一个用例所包含 的事件流，或者是用例的子功能。
– 如果学生直接通过Web方式提交个人信息，则认为 学生是参与者。
区分主要参与者和次要参与者
• 主要参与者（primary actor）是从系统中直 接获得可度量价值的用户。
• 次要参与者（secondary actor）的需求驱动 了用例所表示的行为或功能，在用例中起辅 助支持作用
• 用例分析的重点是要找到主要参与者。
3、用例与场景（Scenarios）
• 用例描述的是一组动作序列，在复杂的系统 中，用例细节可能存在多种不同的情节，称 为变体。
用例建模的基本过程
⽤例建模的基本过程
1.识别并描述参与者（actor）
通过以下问题识别Actor：
谁使⽤这个系统的功能？
谁从该系统获得信息？
谁向该系统提供信息？
该系统需要访问(读写)那些外部硬件设备？
谁来负责维护和管理这个系统以保证其正常运⾏？
该系统需要与其他系统进⾏交互吗？
2.识别⽤例（use case），并给出简要描述
寻找⽤例可以从以下问题⼊⼿(针对每⼀个参与者)：
参与者使⽤该系统执⾏什么任务？
参与者是否会在系统中创建、修改、删除、访问、存储数据？如果是的话，参与者⼜是如何来完成这些操作的？参与者是否会将外部的某些事件通知给该系统？
系统是否会将内部的某些事件通知该参与者？
3.识别参与者与⾓⾊之间的通讯关联
4.给出每⼀个⽤例的详细描述
5.细化⽤例模型。
软件工程之系统建模篇【设计用例模型】
软件⼯程之系统建模篇【设计⽤例模型】本⽂主要介绍⽤例模型的设计过程，⾸先从系统层设计⽤例模型，然后分别细化系统层识别的各⽤例，设计更为详细的⽤例模型。
⽤例模型是开发过程的起点，并驱动建模全过程。
以下以办公⾃动化（OA）中的办理发⽂⽤例模型为例，来讲解⽤例模型的设计过程。
⽤例模型包括办理公⽂⽤例图及⽤例描述。
办理发⽂⽤例模型 1、办理公⽂⽤例图 在设计办理发⽂⽤例模型之前，先要识别活动者和⽤例，活动者和⽤例识别以后，才能建⽴⽤例模型。
1.1 活动者识别 活动者是系统分析员与⽤户交流的起点，也是项⽬获得后续产品的关键。
活动者可以是使⽤系统功能的⼈，也可以是软件系统和硬件设备，凡是与系统进⾏信息交换的外部实物，都可以归为系统的活动者。
系统分析员与系统⽤户深⼊交流后，明确系统范围，系统功能和外部关联的事物。
识别活动者需要往复多次，可以通过向⽤户询问类识别活动者。
如：谁/什么对系统运⾏的结果感兴趣，会改变系统中的数据，从系统中获取信息，与系统交互。
通过对具备这些需求的⽤户进⼀步分析，即可识别系统活动者。
1.2 识别过程 与系统发⽣交互的外部实体有草拟⼈、审核⼈、复核⼈、签发⼈和分发⼈。
草拟⼈可识别为发⽂草拟⼈，审核⼈可设别为发⽂审核⼈、复核⼈可识别为发⽂复核⼈，签发⼈⼀般由相关领导担任，可识别为发⽂签发⼈，分发⼈可识别为分发⼈。
1.3 ⽤例识别 发⽂草拟⼈新拟发⽂编辑发⽂并保存在系统中 新拟发⽂⽤例 发⽂草拟⼈修改发⽂修改发⽂并保存所做操作 修改发⽂⽤例 发⽂审核⼈审核发⽂编辑审核意见并保存在系统中 审核发⽂⽤例 发⽂复核⼈复核发⽂编辑复核意见并保存在系统中 复核发⽂⽤例 发⽂签发⼈签发发⽂编辑签发意见并保存在系统中 签发发⽂⽤例 分发⼈ 分发发⽂对分发进⾏登记并保存在系统中 分发发⽂⽤例 发⽂草拟⼈送档案室 将发⽂转⼊档案室 送发⽂⾄档案室⽤例 1.4 ⽤例图 2、⽤例描述 2.1 新拟发⽂ ⽤例⽬标：当发⽂草拟⼈新拟⼀份发⽂时⽤例开始。
用例建模法
用例建模法用例建模法是一种常用的需求分析方法，通过描述系统与外部参与者之间的交互，帮助我们理解系统功能与行为。
在这种方法中，我们考虑系统能够提供给参与者的不同用例或场景，并描述了参与者与系统之间的交互。
以下是用例建模法的相关参考内容。
1. 用例建模的基本概念：用例：用例是一个有序的事件序列，用于描述参与者与系统之间的交互。
参与者：参与者是与系统进行交互的外部实体。
它可以是一个人、一个组织或另一个系统。
系统边界：系统边界是用于定义系统与外部参与者之间的界限。
主要成功场景：主要成功场景是该用例的典型执行路径，描述了系统如何响应参与者的请求并达到预期结果。
2. 用例建模的过程：(1) 识别参与者：确定系统的外部参与者，并理解他们对系统的期望。
(2) 确定用例：识别系统能够为参与者提供的用例或场景，并描述其目标和预期结果。
(3) 建立参与者与用例之间的关系：描述参与者与用例之间的交互方式和角色。
(4) 确定用例间的关系：通过识别用例间的相互作用和依赖关系来整理用例。
3. 用例建模的优点：(1) 用例建模通过描述用例和参与者之间的交互，帮助人们理解系统的需求和功能。
(2) 用例建模提供了一种可视化表示方法，使得分析和理解需求更容易。
(3) 用例建模强调用户的角色，有助于设计出更加用户友好的系统。
(4) 用例建模可以帮助团队成员进行有效的沟通和协作。
4. 用例建模的步骤：(1) 确定系统的边界：定义系统与外部参与者之间的边界。
(2) 识别参与者：确定与系统进行交互的外部参与者，并描述他们的期望和角色。
(3) 识别用例：确定系统需要提供的用例或场景，并描述它们的目标和预期结果。
(4) 建立参与者与用例之间的关系：描述参与者与用例之间的交互方式和角色。
(5) 确定用例间的关系：识别用例之间的相互作用和依赖关系。
以上是用例建模法的相关参考内容。
用例建模是一种常用的需求分析方法，通过描述系统与外部参与者之间的交互，帮助我们理解系统功能与行为。
用例建模
27
功能：
25
识别用例
• 首先弄清楚系统的问题域、业务流程， 整理出系统的功能需求，在此基础上结 合已经识别出来的角色识别、抽象出系 统用例，定义并描述它。 • 针对角色
–某个角色要求系统为其提供什么功能 ； 该 某个角色要求系统为其提供什么功能； 某个角色要求系统为其提供什么功能 角色需要做哪些工作？ 角色需要做哪些工作？ –角色需要阅读 、 创建 、 销毁 、 更新或存储 角色需要阅读、 角色需要阅读 创建、 销毁、 系统中的某些（ 信息码？ 系统中的某些（类）信息码？
4
例：自动饮料售货机
签选选 填亭
供送
用例图中包含系 统角色和用例等 三种模型元素， 以及它们之间的 关系。
供送供
取送取 收收赛
5
用例描述
• 用例内容，即该用例所代表功能的具体 实现过程，通常用普通的文字书写，在 UML语言中用例内容被看作用例元素的 文档性质 • 另一描述用例内容的工具是活动图
6
29
用例之间的关系： 用例之间的关系：Extend
• 一个用例中加入一些新的动作后则构成了另一 个用例，这两个用例之间的关系就是通用化关 系，又称扩展关系。 • 后者通过继承前者的一些行为得来，前者通常 称为通用化用例，后者常称为扩展用例。 • 扩展用例只有在基本用例中的某种条件满足时 才能执行，如果没有基本用例的运行，扩展用 例不能运行 • 基本用例执行时,扩展用例不一定执行
实验七 用例建模
实验六用例建模
[实验目的]
1、了解用例建模的方法；
2、掌握Rose的使用方法。
[实验内容]
按如下叙述建立用例模型：
某计算机厂商准备开发一个“网上计算机销售系统”以方便客户通过Internet 网络购买计算机。
客户可以通过Web页面登陆进入该系统，通过Web页面查看、选择、购买标准配置的计算机。
客户也可以选择计算机的配置或在线建立自己希望的配置。
可配置的构件（如内存）显示在一个可供选择的表中。
根据用户选择的每个配置，系统可以算出计算机的价格。
客户可选择在线购买计算机，也可以要求销售员在发出订单之前与自己联系，解释订单的细节，协商价格等。
客户在准备发出订单时，必须在线填写关于运送和发票地址以及付款细节（支票和信用卡）表格，一旦订单被输入，系统向客户发送一份确认邮件，并附上订单细节。
在等待计算机送到的时候，客户可以在线查询订单的状态。
后端订单的处理步骤是：验证客户的信用和付款方式、向仓库请求所购的计算机，打印发表并请求仓库将计算机运送给客户。
在客户订单输入到系统后，销售员发送邮件请求给仓库，附上所定的配置细节。
仓库从销售员那里获得发票，并给客户运送计算机。
[实验要求]
1、画出用例图；
2、说明建模过程。
[实验报告]
1. 报告要求用专门的实验报告纸书写，字迹清晰，格式规范；
2. 报告中写清姓名、学号、实验日期、实验题目、实验目的、实验要求；
3. 按要求完成实验；
4. 报告最后包含实验总结和体会。
第5讲 用例建模
2 识别参与者(Actor)
从需求中识别参与者
参与者：在系统之外，通过系统边界与系统进 行有意义交互的任何事物
要点：任何事物
任何事物举例：小人与圣小猪-1
如果我开发一个猪圈自动供食供水系统 ，猪的 前蹄触发一个开关系统就供食或供水。很显然 这里的参与者是小猪。通常，用例图中的参与 者用一个小人表示。
场景1：某企业要求开发一个企业信息管理 系统，并与原来已有的库存系统相连接
系统之外，重点明确新老系统间的接口
场景2：某企业要求开发一个企业信息管理 系统，并把原来已有的库存管理系统加以 改造，成为企业信息管理系统的一部分
系统之内，新系统存在一个“改造库存系统” 用例，工作量要比上述大很多
参与者的命名
涉众无法直接提供需求的现象
涉众无法陈述自己的需要
涉众说的是解决方案而不是需求
涉众难以构想新的工作方法
涉众的利益矛盾
涉众抵制变更
“最好也要有”—过度的要求
需求引发新的需求
获取需求的技巧——需求启发技术
技巧 描述 直接观察个人工作的情况，以发现现存的实践方 实地观察 式和问题，提供最直观的业务细节，但耗时 访谈 从个人处收集特定信息，直接沟通，信息真实性 特定群体 对一组人员进行调查，以便了解工作态度和共同 看法 调查 收集详细数据和统计意义上比较重要的数据，可 问卷调查 以获得匿名答复 用户指导 让最终用户告诉你，他们是如何实现业务流程的 原型制作 模拟一个无法直接测试的系统，便于沟通 记录用户完成任务的方式，便于了解用户习惯， 统计版本 及时改进
多，反之则包含的功能越少。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
三种模型的关系
4. 功能模型中的数据存储，以及数据的源点/终点， 通常是对象模型中的对象。 5. 功能模型中的数据流，往往是对象模型中的属性值， 也可能是整个对象。 6. 功能模型中的处理可能产生动态模型中的事件。 7. 对象模型描述了功能模型中的动作对象、数据存储 以及数据流的结构。
用例图：视图
在面向对象方法学中，对象模型是最基本的、最 重要的，它为其他两种模型奠定了基础，我们依靠对 象模型完成三种模型的集成。
1. 针对每个类建立的动态模型，描述了类实例的生命 周期或运行周期。 2. 状态转换驱使行为发生，这些行为在数据流图中被映 射成处理，它们同时与对象模型中的服务相对应。 3. 功能模型中的处理，对应于对象模型中类-&-对象所 提供的服务。
一般—特殊结构是一种分类结构，反映 了类间的一般与特殊的关系。一般类与特殊类 之间是一种“is a”的关系，如：汽车是一种交 通工具。同样，特殊类还可以分为更特殊的类， 这样可形成类的层次结构。
• 2. 组装结构 刻画整体—部分组织，表达了自然的整体和部分的结构 关系，从而把一些部分的聚合构造成整体。
计详细的动态模型来自阶详细的功能模型
段
面向对象技术是一个有全新概念 的开发模式,其特点是:
(1)方法是对软件开发过程所有阶段进 行综合考虑而得到的;
(2)从生存期的一个阶段到下一个阶段 所使用的方法与技术具有高度的连 续性;
(3)将OOA、OOD、OOP集成到生存
期的相应阶段.
面向对象分析 Object-Oriented Analysis
• 非正式分析法
用自然语言书写的需求陈述为依据确定的候选者 。
3. 定义类的结构和层次
类的结构主要有两种：一般—特殊 （generalization—specialization）结构和整 体—部分（whole—part）结构。
•1. 分类结构
获得类—成员组织，用于刻画对象之间的层次 关系，它通过搜集公共特性并把这种特性扩充至特 例之中来显示现实世界事件的通用性及专用性。
注意，执行者与用户是不同的两个概念， 一个用户可以扮演几个角色（执行者），一 个执行者可以是用户，也可以是其他系统 （应用程序或设备）。得到的用例必须进行 复审，以使需求完整。
2. 标识类和对象
类和对象来自问题领域。
可以先标识候选类，然后进行筛选
• 参照常见事物找出在当前问题域中的候选对 象。
（1）可感知的物理实体 （2）人或组织的角色 （3）应该记忆的事件 （4）两个或多个对象的相互作用 （5）需要说明的概念
整体—部分结构反映了类间的整体与部分关 系。值得注意的是，整体—部分关系是对对象 而言的，而不是对类的。整体—部分关系是一 种“has a ”的关系，如“汽车”有“发动机”。 同样，整体—部分结构也具有层次结构。
有的面向对象方法中，把互相协作以完 成一组紧密结合在一起的责任的类的集合定 义为主题(subject)或子系统（subsystem）。 主题和子系统都是一种抽象，从外界观察系 统时，主题或子系统可看作黑盒，它有自己 的一组责任和协作者，观察者不必关心其细 节。观察一个主题或子系统的内部时，观察 者可以把注意力集中在系统的某一个方面。 因此，主题或子系统实际上是系统更高抽象 层次上的一种描述。
面向对象分析的一般步骤如下： 1. 获取客户对系统的需求：包括标识场景（scenario）
和用例（use case也称用况），以及建造需求模型 2. 用基本的需求为指南，来选择类和对象（包括属性
和操作）。 3. 定义类的结构和层次。 4. 建立功能模型。 5. 建立对象模型。 6. 建立动态模型。 7. 利用用例/场景来复审分析模型。
功能模型：模型
类图：视图
对象模型：模型
顺序图：视图 状态图：视图 活动图：视图
动态模型：模型
分析模型的构成
分析模型：模型
用例建模——功能模型
用例建模是用于描述一个系统应该做什么的建模技 术，用例建模不仅用于新系统的需求获取，还可用于 已有系统的升级。用例模型用用例图来描述。
分析过程
1. 获取客户对系统的需求
需求获取必须让客户与开发者充分地交流，这里 介绍一种采用用例来收集客户需求的技术。分析员 首先标识使用该系统的不同的执行者（actor）， 这些执行者代表使用该系统的不同的角色。每个执 行者可以叙述他如何使用系统，或者说他需要系统 提供什么功能。执行者提出的每一个使用场景（或 功能）都是系统的一个用例的实例，一个用例描述 了系统的一种用法（或一个功能），所有执行者提 出的所有用例构成系统的完整的需求。
4. 建立功能模型
• 功能模型 说明发生什么，它只关心系统做什么，
而不考虑怎么做，描述系统的功能结构。
5. 建立对象模型
定义了做事情的实体，描述系统的数据结 构，包括对象之间的关系、对象的属性和操 作，用对象图表示。
对象模型描述了系统的静态结构，它指出 了类间的关系（relationship）。
类之间的关系有关联、依赖、泛化、实现 等。
6. 建立动态模型
• 明确规定了什么时候做（即在何种状态下 接受了什么事件的触发），描述系统的控 制结构，即：描述类的对象的状态和事件 的正确次序。
• 每个类的动态行为用一张状态图来描绘， 各个类的状态图通过共享事件合并起来， 从而构成系统的动态模型。
三种模型的关系
第10章 面向对象分析
• 面向对象软件开发技术
– 面向对象分析(OOA) – 面向对象设计(OOD) – 面向对象实现(OOP)
分析建模方法与分析模型
结构化分析(传统建模方法)方法
分析模型：数据流图(DFD) 数据字典(DD) 小说明 E-R图(ERD) 状态变迁图(STD)
面向对象分析方法
分析模型：用例模型（需求模型） 对象模型（概念模型）
功能模型（行为模型）
状态模型
分析模型
•对象模型: 描述静态结构, 定义做
事情的实体
•功能模型: 描述处理(数据变换),
指明系统应“做什么”
•动态模型: 描述交互过程, 规定什么
时候做
OMT模型系统分析和设计过程概观图
产生需求
分
问题描述
析
建立模型
阶 段
对象模型、动态模型、功能模型
结构及对象
设
设计
详细的对象模型