信息系统分析与设计之面向对象建模
面向对象的建模方法
面向对象的建模方法［摘要］评述面向对象的几种建模方法并作一比较，阐述统一建模语言的优越性，并对其组成、特征、建模过程进行描述。
［关键词］软件工程建模面向对象一、引言面向对象方法学也称为面向对象的开发方法，它属于软件工程的范畴。
面向对象方法学的出发点和基本原则是尽可能模拟人类习惯的思维方式，使开发软件的方法与过程接近人类认识世界解决问题的方法与过程。
也就是说，面向对象方法是一种崭新的思维方法，它是把程序看作是相互协作而又彼此独立的对象的集合。
由于对象的独立封装，模块的可构造性、可扩充性、可重用性也大大加强，从而面向对象的软件工程能够胜任当今大规模复杂、易变软件系统开发应用的要求。
面向对象的软件工程要求首先对系统建立模型是对现实的简化，它提供了系统的蓝图。
一个好的模型只需抓住影响事物发展的主要矛盾，而忽略那些次要矛盾。
每个系统可以从不同方面用不同的模型来描述。
因而每个模型都是在语义上闭合的系统抽象。
通过建模可以按照实际情况对系统进行可视化模型详细地说明了系统结构或行为，指导我们构造系统模板二、面向对象建模方法建模是构造软件系统最基本的步骤，在软件工程学科中提供了多种多样的建模方法和高效的工具，其目的是为了在软件开发过程的早期就发现设计中可能隐含的缺陷和错误，对于今日的大型软件系统，采用一种合适的建模方法，建立一个良好的模型是成功的关键。
在市场上已有一些公司，如Ratio na1，Caye nne, Plat in um等开始提供商品化的建模工具，即通常所谓的CASE工具，使得建模过程实现了一定的自动化的标准化，并逐步走向实用，而这些工具的后面，便是具有不同特色的建模方法。
下面分析比较Booch，OMT，OOSE，UML等几种主要的面向对象的建模方法：（一）Booch 方法Booch方法是由Grady Booch提出的，是一种主要面向设计的方法，它通过二维图形来建立面向对象的分析和设计模型，强调设计过程的不断反复知道满足要求为止。
对“面向对象信息系统分析与设计”的哲学思考
教 学 与 科 技
２ ９
对 “ 面向对象信息系统分析与设计”
的哲学思考
李安 志 任 继念 崔 蔚
（ 国工程 物 理研 究 院工学 院 ， 四川绵 阳 ，６ １０ ） 中 ２９ ０
摘
要 面 向对象 的分析 与设计方法是 目前软件开发的主流方 向，本文 从唯物辩证法和辩证唯物主义
可 用表 示 为：
抽象
映射 现实世界信息处 理 的逻辑模型 计算机中信息处 理 的逻辑模型
实现
信 息 系 统软 件
现实世界 信息处理
从 图 中可 以看 ，信 息系 统 的分析 设计 主要 有三 个步 骤 ：
１ ）从现实世界的信息处理过程，抽象 出现实世界的信息处理模型；
面 向功能方法【 以系统的功 能或所完成的任务为立足 点分析和设计系统，该方法把系统看成是 ５ 】 是 功能的聚合体 ，自上而下 的进行系统分析和设计 ，将系统分解为若干个具有独立性的功能模块 ，按功
能划 分子 系统 加 以实现 。如 传 统 的软 件 生命 周期 法和 原型 法都 是面 向功 能法 。
识该事物 ，因为当我们在认识该事物时，本身就是在与该事物发生联系。因此 ，封装性和联系性是任
何 事物 固有 的特 性 。而 现 实世 界正 是 由许 许 多 多 的事物 和事 物之 间 的联 系构成 。作 为信 息系 统 ，它要
模拟现实世界，就必须模拟现实世界的各种事物和各种事物之间的联系。
ｂ ）面 向对 象 方法
面 向对象 的方法［是将数据及对数据 的操作方法放在一起 ，作为一个相互依存 、不可分 离的整 ２ 】
体一 对象 。对 同类 型对 象抽 象 出其共 性 ，形 成类 ；类 中的 大多数 数 据 ，只 能用本 类 的方法 进行 处 理 ； 类通 过 一个 简 单 的外部 接 口与 外界 发生 关 系 ：对 象 与对 象 之 间通 过 消 息进行 通信 ；通 过 继承 和多 态来 实 现代码 的重用 。 ｌ 面 向对象 信 息 系统 是对 现 实世界 的直 接反 映 － ３ 可 以看 出，这 两种 方法 中，面 向功 能 的开发 方 法是对 现 实世 界 的扭 曲反 映 ，而 面 向对 象 的开 发方
信息系统分析与设计方法论
信息系统分析与设计方法论随着信息技术的快速发展，信息系统在各个领域的应用越来越广泛。
信息系统分析与设计方法论是指在信息系统开发中，通过一系列的方法和技术，对问题进行有效的分析和设计，以达到满足用户需求、提高系统效率和可靠性的目标。
本文将介绍信息系统分析与设计的常用方法和技术，并探讨其在不同应用场景下的实际运用。
信息系统分析阶段是系统开发的重要阶段，其目标是通过对现有系统进行分析，确定系统的需求和问题，为后续的设计提供依据。
常用的信息系统分析方法包括需求收集、建模、功能分析等。
需求收集是通过与用户沟通、观察和文档分析等方式，收集用户对系统需求的描述。
建模是将需求抽象为模型，常用的建模方法包括数据流图、实体关系图、状态转换图等。
功能分析则是通过对系统功能的细分和描述，确定系统的功能需求和优先级。
信息系统设计阶段是根据分析阶段的结果，对系统进行整体架构设计和模块设计。
常用的设计方法包括结构化设计、面向对象设计和基于组件的设计。
结构化设计是将系统划分为模块，并确定各个模块之间的关系和功能，常用的设计工具有结构图、流程图等。
面向对象设计是将系统看作一些相互作用的对象，通过类的定义、继承和关联等方式进行设计。
基于组件的设计则是将系统划分为一些可以独立开发、部署和维护的组件，以提高系统的复用性和可扩展性。
在实际的信息系统开发中，根据具体的应用场景和要求，还可以采用其他的方法和技术。
例如，对于大规模复杂系统的开发，可采用面向服务的架构（SOA）和服务导向架构（SOBA）等方法，以提高系统的灵活性和响应能力。
对于安全性要求较高的系统，可以采用信息安全评估方法和技术，如风险评估、漏洞扫描、加密技术等。
对于移动应用程序的设计，可以采用响应式设计和多渠道布局等技术，以适应不同终端的显示和交互需求。
除了方法和技术的选择，信息系统的分析与设计还需要考虑项目管理、团队协作和质量保证等因素。
项目管理是指对项目的规划、执行和控制，以保证项目按时、按质地完成。
面向对象的系统分析与设计课程设计
面向对象的系统分析与设计课程设计1. 课程设计背景随着信息时代的到来，计算机科学技术在各个领域得到了广泛的应用和发展。
作为计算机科学技术中的重要分支之一，面向对象的系统分析与设计已经成为了计算机科学技术中的一个重要组成部分。
在现代软件开发中，面向对象的系统分析与设计已经成为了不可或缺的一部分。
2. 课程设计目的本课程设计的主要目的是培养学生的面向对象的系统分析与设计能力。
通过学习本课程，学生应该掌握面向对象的基本概念、面向对象的系统分析与设计基本方法和技能。
此外，本课程还应该通过实践使学生能够独立完成一个实际的面向对象的系统分析与设计项目。
3. 课程设计大纲本课程设计的主要内容包括：3.1 面向对象的基本概念本课程将首先介绍面向对象的基本概念。
包括类、对象、继承、多态等。
这些基本概念是理解面向对象编程的基础。
3.2 面向对象的系统分析和设计方法本课程将介绍面向对象的系统分析和设计方法。
包括需求分析、可行性分析、领域模型分析、数据模型设计、物理模型设计等。
3.3 根据需求设计面向对象的系统根据一个实际的需求将学生分组进行设计。
这将会需要学生使用UML建立需求分析模型，并在其基础上进行具体的软件开发。
其设计应该包括：领域建模、游戏界面设计、状态和策略设计等。
4. 课程设计要求4.1 团队合作学生应该分组，每组人数4-5人。
每个小组都会需要自己来完成一个面向对象的系统分析与设计项目。
因此，学生之间需要进行紧密的合作。
4.2 设计文档学生应该撰写设计文档，包括需求分析、设计理念和实现细节三个方面。
4.3 实现系统学生需要使用面向对象的编程语言来实现所设计的系统。
4.4 系统演示在课程结束后的演示环节，每个小组需要进行系统演示。
这是整个课程设计的一个重要环节。
5. 课程设计评分本课程设计将会按照如下标准进行评分：5.1 设计文档评分在设计文档评分中，评分标准包括需求分析、设计理念和实现细节。
其中，需求分析和设计理念各占30分，实现细节占40分。
高校就业信息系统的面向对象分析与建模
二、 用例模型
从 上 面 的描 述 中 ， 们 知 道 系 统 的 功 能 是 由 四种 用 我
户 （ 业 生 、 聘 单 位 、 校 就 业 管 理 人 员 、 院 就 业 管 毕 招 学 学
当今各 高校 的 就业 信 息 系 统 一般 都 采 用 传统 的结构 化模 式 ，而 该 模 式在 可 重 用性 和 可扩 展 性 方 面都 较 为 薄 弱 。 向对 象 方 法 能很 好 地解 决 上 述 问题 。 面 向对 象方 面 在 法 中 ， 何 事 物 皆 为 对 象 ， 序 设 计 高 度模 块 化 ， 任 程 可扩 展
维普资讯
《 中国教 育信息化》鳊辑部 ：ｉ ｏ ．ｄ ． ｍ ｓ ｅｅ ｕｃ ＠ｍ ｎ
Байду номын сангаас
高校就业信息 系统 的面 向对 象
分析 与建模
四川 大 学公 共 管理 学院 信 息 管 理 系
摘
雷 强 赵 英
要： 高校 毕 业 生就 业 已成 为 当今社 会 的一 大 热 点 问题 ， 立一 套 高效 可 靠 的 毕 业 生 建
发 送 意 向 ， 同时 还能 处 理 毕 业 生发 来 的简历 和对 毕 业 生 进 行 视频 面试 。
（ ） 院 就业 管 理 员 除 了 审核 毕 业 生 注册 外 ， 可查 ３学 还
为 了使 系统 的分 析 与设 计 更 加 规 范 ， 采用 Ｒ ｔ ｎｌ 将 ａ ｏａ ｉ 统 一 过程 。 ａｏａ 统 一 过程 提 供 了在 开发 组织 中分 派任 Ｒ ｔ ｎｌ ｉ
重用 性 的 问题 。 因此 ， 文 选 用 采用 面 向对 象 的分 析 方法 本 对高 校就 业 系统 进行 分 析 ，并 在 此 基 础 上进 行 系 统设 计
UML-面向对象的分析和设计
面向对象分析与设计
15/180
注意，执行者与用户是不同的两个概念， 注意，执行者与用户是不同的两个概念，一个用 户可以扮演几个角色（执行者）， ），一个执行者可以是 户可以扮演几个角色（执行者），一个执行者可以是 用户，也可以是其他系统（应用程序或设备）。 ）。得到 用户，也可以是其他系统（应用程序或设备）。得到 的用例必须进行复审，以使需求完整。 的用例必须进行复审，以使需求完整。
构成类图的元素所表达的模型信息， 构成类图的元素所表达的模型信息， 对象层 分为三个层次： 分为三个层次： 三个层次 对象层—给出系统中所有反映问题域 对象层 给出系统中所有反映问题域 特征层 系统责任的对象。 和系统责任的对象。 特征层—给出类 对象）的内部特征， 给出类（ 特征层 给出类（对象）的内部特征， 关系层 即类的属性和操作。 即类的属性和操作。 关系层—给出各类 对象） 给出各类（ 关系层 给出各类（对象）之间的关 图 OOA基本模型 基本模型 包括继承、组装、一般—特殊 系，包括继承、组装、一般 特殊 、整 体—部分、属性的静态依赖关系，操作的 部分、属性的静态依赖关系， 部分 动态依赖关系。 动态依赖关系。
目录
首页
末页
面向对象分析与设计
6/180
抽象类与子类示例
Shape { abstract } draw ( ) { abstract }
Abstract class Abstract operation
Circle draw ( )
Rectangle draw ( )
目录
首页
末页
面向对象分析与设计
目录 首页 末页
面向对象分析与设计
18/180
构造对象—关系模型 4. 构造对象 关系模型
面向对象的概念面向对象建模面向对象分析与模型化面向对象
打电话者拿起电话受话器 电话忙音开始 打电话者拨数字(8) 电话忙音结束 打电话者拨数字(2) ....... 打电话者拨数字(3) 接电话者的电话开始振铃 铃声在打电话者的电话上传出 接电话者回答 接电话者的电话停止振铃 铃声在打电话者的电话中消失 通电话 .........
状态图与事件追踪图的关系
揿下鼠标按钮(按钮、位置) 拿起电话受话器
数字拨号(数字)
事件追踪图
事件追踪图侧重于说明发生于系统 执行过程中的一个特定“场景”。
场景也叫做脚本，是完成系统某个 功能的一个事件序列。
场景通常起始于一个系统外部的输 入事件，结束于一个系统外部的输 出事件，它可以包括发生在这个期 间的系统所有的内部事件。
类是一组具有相同数据结构和相同 操作的对象的集合。
类的定义包括一组数据属性和在数 据上的一组合法操作。
类定义可以视为一个具有类似特性 与共同行为的对象的模板，可用来 产生对象。
在一个类中，每个对象都是类的实 例 (Instance)，它们都可使用类中 提供的函数。
继承 (Inheritance)
面向对象方法学的要点（2）
对象彼此之间仅能通过传递消息互相联系 面向对象的方法学可以用下列方程来概括：
OO=objects+classes+inheritance+ communication with messages
如果一个软件系统是使用这样 4 个概念设计和实现的，则我们认 为这个软件系统是面向对象的。
这个新的子集合可以认为是既存类 的一个特殊化。
面向对象建模
所谓模型，就是为了理解事物而对事物作出 的一种抽象，是对事物的一种无歧义的书面 描述。
面向对象分析与设计
面向对象分析与设计面向对象分析与设计（Object-oriented analysis and design）是软件工程领域中的一种方法论，用于解决软件系统开发过程中的问题和需求。
本文将对面向对象分析与设计的基本概念、流程和常用方法进行介绍，并附带答案和解析。
第一部分：面向对象分析（Object-oriented analysis）面向对象分析是软件开发过程中的第一步，旨在理解问题域并建立领域模型。
面向对象分析有以下几个重要概念：1. 对象（Object）：对象是系统中的一个实体，包含数据和方法。
对象可以是具体的实物、虚拟的概念或一组相关的数据和行为。
2. 类（Class）：类是一种抽象的定义，描述了一组具有相同特征和行为的对象。
3. 属性（Attribute）：属性是对象的特征，用于描述对象的状态。
4. 方法（Method）：方法是对象的行为，用于描述对象可以执行的操作。
面向对象分析的主要流程包括以下步骤：1. 需求收集：收集系统的需求，与利益相关者沟通，了解系统的功能和性能要求。
2. 领域建模：对现实世界的问题域进行抽象和建模，识别出系统中的对象和它们之间的关系。
3. 需求分析与规约：通过使用用例、活动图和状态图等工具对需求进行分析和规约，明确功能和交互细节。
4. 领域模型验证：与利益相关者验证领域模型的准确性和实用性，确保模型能够满足系统需求。
第二部分：面向对象设计（Object-oriented design）面向对象设计是在面向对象分析的基础上，进一步细化领域模型，为系统的实现提供指导。
面向对象设计有以下几个常用方法：1. 类图（Class diagram）：类图用于展示类、属性和方法之间的关系。
类图包括类的名称、属性和方法，并通过关联、继承和聚合等关系展示类之间的联系。
2. 对象图（Object diagram）：对象图用于展示类的实例和对象之间的关系。
对象图是类图的实例化表示，展示了系统在某一时刻的对象及其特定的属性值。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
外部系统
与此系统交互的其他系统,可以先采用假定的方式,说 不定分析到后面发现它也是本系统的一个子系统. 以付账,扣库存的角度来看,可能有
总帐系统 库存管理系统
这样分析出4个Actor
消费者 店员 总帐系统 库存管理系统
图Store0
顾客
总帐系统
店员
库 存管 理 系统
情境(Scenario):一连串的操作顺序
问题:一个生手如何开始分析?
利用 Use Case 与Actor的方式,对流程进行分 析,而且后续可以针对Use Case找出相关的对象 与类 找出人为的Actor:
消费者 店员 翻看杂志的路人甲:如果未购买则与本系统无关,若 有购买,则也是消费者 店长:管理便利店资源.未发现与本系统有交互.若 店长值班,则也是店员.
图Store7
下订单
店员
分销商
温度传感器
下建议订单
Store8
店员
进货管理
分销商
进货管理
6.3,Use Case 高级分析技巧
Use Case 说明书
与传统软件开发过程中惯用的"需求说明书"相比,是 类似的,都是要与用户确认的文件. 就概念上而言,用户的一项需求经过分析之后,可能会 是好几个Use Case. 在"说明"栏,指出使用时机,该操作何时执行,包括 涉及到用户之间的权限区分. 在进行Use Case分析时,最怕遇到明显的AUDI类型的操 作.以传统眼光来看,一般的Use Case均是新增,修改, 删除或查询交相混杂的.而目前的系统分析人员都是由 传统系统分析起家的,因此着手的角度很容易受到AUDI 的限制,所分析出来的Use Case就会失去对象的精神. 基本事件流 与 传统 的 操作流程类似.但是"流程图" 无法与后续文档或其他图形之间相互修改.
销售管理
总帐系 统
店员 折 扣销售 网 上销售 商 品预售
发现销售管理-〉消费者的秘密了吗? 第二个特殊要求; Sell Goods要印出发票给消费者.
但是Sell Goods(销售管理)只是计算机,所以以上工作要由店 员来做.
修改图:
图Store6
-顺便画出了消费者的属性,强调消费者将被设计为一 个对象 -销售管理-〉消费者的虚线,"相关关系",表示销 售管理要向消费者要数据 -没有"打印发票",因为国家规定销货一定要打印发 票,所以包含在销售管理的流程里面了
Boundary Class(边界类): (边界类):
表示系统外部环境与内部运作之间交互的类 (系统与系统之间,人与系统之间,某个类于系统之间 系统与系统之间, 系统与系统之间 人与系统之间,某个类于系统之间)
Control Class (控制类): 控制类):
表示一个或多个Use Case 行为的类 表示一个或多个
Boundary Class, ――客户端,用户界面 Control Class Entity,――中间层:组件 Entity Class,――数据库端
Use Case Case运作机制
Use Case的范围(例如:进,销,存) Actor 异常事件流
通过这三者的相互运作以及精确分析,才可以规划出一套 信息系统的需求.光这样还不够,新手与老手所规划的Use Case 可能有所不同.
也可以根据Use Case说明书中的叙述,简单制作 相关的类.不要太贪心,一次加一堆类,或者一 次加很多属性,操作. 寻找Use Case名,说明书中比较重要的名词 不属于这个阶段该加入的类,勿强行加入.比如 某些控制类,因为以后自然会找出来. 针对Use Case的范围适当加入类. 加入类时,如该类已存在,则检讨该类是否恰当, 或者酌量加入新的属性及操作.
图Store3
1.感觉到渴 5.打开可乐
顾客 2.翻 看杂志 6.感觉舒服
3.挑选可乐
4.付款
店员
总帐系统 库存管理系统
细线箭头代表与Use Case交互的方向,箭头来源 为输入端,目的为输出端.若不清楚输入输出, 可暂时不加. -泛化关系 ,与情境 – 都是可行的 (刷卡机与 收银机是否分离) 问题:光找出Use Case就可以写出程序了吗?就 有对象了吗?
另外,从消费者的角度进行分析,消费者指向 "销售商品"也是不合理的(消费者哪里需要输 入什么数据?都是店家输入的),故销售商品应 改由店员的角度进行分析.
图Store5
Note: 原来消费者-〉销售商品的线,改成由 销售管理-〉消费者了.这是有意义的
图Store5
查询价格 查询成分
库存管 理系统 顾客 查询商品信息
软件系统的开发阶段:
需求分析阶段 系统分析阶段 系统设计阶段 程序设计阶段 测试阶段 安装阶段
向对象技术可以省掉的是后段的时间与成本,包括程序设 计,测试与维护都可以节省相当可观的成本.但前段时间 与成本要增加许多.
在类设计上,依据 在类设计上,依据RUP(Rational Unified Process) ( ) 的设计理念,一般会先找出三种类: 的设计理念,一般会先找出三种类:
思考"销售管理"和"查询商品信息",找出 可加入的类:
消费者 店员 商品 发票 发票明细 成分 便利店
在"销售管理"里面,除了"成分"外,其余类皆会用 到.
图 Logical View/StoreClass1
发票 invoiceNO 1 Consumer
(from Ex02_Store)
发票 明细 n 1 1
一个Use Case里面可能有相当多的操作,以不 同的顺序进行,每一串操作顺序都可以情境. 以"买饮料"的流程看,现金购买是一种情境, 刷卡购买也是一种情境.刷偷来的卡被逮到,也 是一种情境.
Use Case的情境分为三种:
主事件流(Main Flow) 其它事件流(Alternative Flow) 异常事件流(Exceptional Flow)
OO分析采用"交互式","渐进式"的开发方法,也就 是分析一点,设计一点,修改一点,再分析,再设计, 然后再修改,其目的为使整套系统的模型更加完整,清 晰.因此分析设计阶段会拉长.由此缺点,某些软件公 司认为前置时间比较长,成本较高,但实际上前面做的 好,可以省下后续程序设计,测试以及维护的时间,事 实上反而比较省成本.
由于对象里面一定包含有"操作" 由于对象里面一定包含有"操作"和"属性",Use Case中的动词 属性" 中的动词 部分,将来可以作为对象中的操作, 部分,将来可以作为对象中的操作,名词部分可以作为对象中的 属性" "属性" Actor与 将Actor与Use Case 联系起来
记账" 扣除库存" 分析 Use Case 4,是有用的,与"记账","扣除库存"有关 ,是有用的, 分析1, , ,产生的是心理作用,不符合"可观察的结果值" 分析 ,5,6,产生的是心理作用,不符合"可观察的结果值", 去掉 检讨2, 检讨 ,3 若仅是购买饮料的流程看, , 是与电脑系统无关的 是与电脑系统无关的. 若仅是购买饮料的流程看,2,3是与电脑系统无关的.但若考虑到 Total Solution,则是有意义的 ,
运用Use Case的目的在于合理订出系统的需求及 范围,以免后来徒劳无功
图Store4
顾客 查询商品信息 库存管理系统
销售商品
总帐系统 店员 现金付款 信用卡付款
Use Case与程序
图store4 目前仅发展到查询商品信息和销售商品两项,功 能有限,实在不宜称为"便利店"Total Solution. 我们需要明确定出现有Use Case的范围与功能, 其它功能将在后续分析中完成.
查询商品信息:提供客户进行商品查询 销售商品:提供店家进行商品销售管理
程序 是根据功能得出来的,Use Case则是发展分析 而来的.
以"销售商品"子系统而言,可以具有以下的功能: 销售商品-〉 折扣 退回 变价 组合商品 批发 子菜单各为一个程序.而Use Case却不同,绝无所谓的 程序概念,只有"对象"或组件的概念,甚至在高层次 的分析阶段,连"对象"与"组件"都看不到,除了Use Case与Actor,什么都没有.
User Services
An alysis Mode l (from User Services)
Design Model (from User Services)
UML讲究的是以"交互式","渐进式"的方法作 分析,雏形出来之后,可以根据各种需要一步一步 进行分析修订. 目前Rational Rose已经和面向系统分析划上等号, 但进行OO分析为何会有正反两派不同意见?
UML与面向对象分析
6.1 面向对象
面向程序 面向数据 面向对象 面向对象技术一定成功?
理论上是成功的,但需要实践上的配合.
面向对象开发软件的优点:
程序更容易重复使用 程序更容易测试 程序更容易维护 – 将程序分门别类,各司其 职
面向对象的缺点:
面向对象语言门槛较高 面向对象系统分析难度高 面向对象系统分析与设计所需的时间较长
找出Use Case
就Actor而言,必须与所要分析的系统产生 交互 就Use Case而言,必须对特定Actor产生可 观察的结果值
图(候选Use Case)Store2
1.感觉到渴
4.付款
2.翻看杂志
5.打开可乐
3.挑选可乐