8 面向对象分析-usecase图

1、北京大学软件与微电子学院 面向对象技术高级课程 第二部分:面向对象分析,第三章 用况（USE CASE）图,目录,1.用况图的历史 2.系统边界 3.参与者 4.用况 5.用况图 6.例题 7.UML2.0中的用况图 8.UML用况的相关概念,引子,粒子轰击金箔实验（散射实验）,1.用况图的历史,1987年,I.Jacobson首先提出 得到了许多方法学的采纳 90年代末被UML采纳并标准化,Ivar Jacobson,Ivar Jacobson博士1939年9月生于瑞典的一个小镇Ystad。 1962年从位于海港城市歌德堡的Chalmers工学院获电子工程硕士学位。1985年从斯德歌尔摩皇家

2、工学院获得博士学位。他的博士论文是关于大型实时系统的语言构造方面的研究。19831984年他是麻省理工学院MIT的Functional Programming and Dataflow Architecture Group的访问学者。 IvarJacobson博士被公认是深刻影响并改变着整个软件工业开发模式的世界级大师，是软件方法论的一面旗帜。他是面向方面的软件开发(AOSD)、组件(Component)和组件架构(Component Architecture)，用例，SDL (Specification Description Language), 现代业务工程，Rational统一过程(R

3、UP), UML建模语言(与Grady Booch和James Rumbaugh共同创建)等业界主流方法和技术的创始人。 Ivar Jacobson博士曾任瑞典爱立信公司的首席软件体系架构师，负责迄今为止商业上最为成功的AXE交换机的研发。Ivar Jacobson博士在大规模架构重用方面做了大量的工作, 他在使用对象方法设计大型实时系统方面已经有超过25年的经验 在过去四十年以来，Ivar Jacobson始终以其似火的创造热情和惊人的天赋，对整个软件产业保持了非凡的影响，是屈指可数的几位世界级软件大师之一。 Jacobson先生早年在爱立信担任首席架构师期间，发明了顺序图和协作图，稍后，他

4、作出了对整个软件工业影响重大的发明用例。在面向对象如火如荼的八十年代， Jacobson先生创立了Objective System，创造了OOSE软件工程方法，成为在世界上推行面向对象分析设计方法的领军人物。 1995年，Jacobson先生加盟了 Rational，在此后的三年中，他与Grady Booch和James Rumbaugh三人一起创造了意义深远的UML，因此，他们三人被成合称为“UML三友”。 2003年，Jacobson先生成立了Ivar Jacobson International， 2005年进入中国，成立了雅各布森软件（北京）有限公司。Ivar Jacobson Int

5、ernational致力于软件开发新方法的研究，并在2005年提出Essential UP，继续着他的软件传奇。 Jacobson先生著作等身，其中像面向对象软件工程和UML语言用户指南等著作，已经成为殿堂级的软件经典著作。,According to Ivar Jacabson:,It was 1986; Id worked at Ericsson for more than twenty years and was trying to figure out a better way to model telephone calls It would have been very diffic

6、ult to model each type of call there were too many, and there was a lot of overlap between them. So first we listed and named them. We called them “traffic cases.”,According to Ivar Jacabson:,Our approach was to model the different “functions” or “features” needed to carry out all the calls all the

7、traffic cases. Functions had no interfaces. They had beginnings and endings, but they were not well defined. A function could interact with the outside world. The general feeling was that we didnt really know what functions were, but we could give examples of them, and some people could specify them

8、. I developed a separate model for describing a system from an outside perspective and called it a use-case model . This provided a black-box view of the system the systems internal structure would be of no interest in this model.,2.系统边界,黑盒:系统对外部的客观世界发挥什么作用,提供什么业务功能来展现系统. 白盒:系统如何提供业务功能的.,问题的提出：在系统尚未

9、存在时，如何描绘用户需要一个什么样的系统？如何规范地定义用户需求？ 考虑问题的思路：把系统看作一个黑箱，看它对外部的客观世界发挥什么作用，描述它外部可见的行为。,系统边界与参与者,系统边界：一个系统所包含的所有系统成分与系统以外各种事物的分界线。 系统：是由“用户”使用的软件，以及所有与其相关的硬件。指被开发的计算机软硬件系统，不是指现实世界的系统。 系统成分：在OOA和OOD中定义，在编程时加以实现的系统元素对象系统边界与参与者 参与者：在系统边界以外，与系统进行交互的事物人员、设备、外系统,注意问题,系统是指被开发的计算机软硬系统自身. 问题域中的某些事物将作为参与者处理。 原来已经存在的

10、系统，看作是一个外系统。 子系统彼此之间都可以互为外系统。,现实世界中的事物与系统的关系包括如下几种情况：,某些事物位于系统边界内，作为系统成分. 某些事物位于系统边界外，作为参与者. 某些事物可能既作为参与者,又作为系统成分. 某些事物既不做为参与者,又不作为系统成分. 认识清楚上述事物之间的关系，也就划分出了系统边界。,3.参与者,简言之，参与者是在系统之外的与系统进行交互的任何事物。 定义：参与者模型系统之外的实体,当外部实体与系统交互时,它就扮演某一特定参与者的角色.,收款员,收款,检查,优惠,参与者可以发出对系统服务的请求 按系统的要求提供服务 通过参与者和系统之间服务请求的复杂对话

11、与系统交互 所有参与者的请求/响应的完全集构成了可以觉察到的系统的问题域边界。 一个参与者的一个实例代表以一种特定的方式与系统进行的单独的交互。 尽管在模型中使用参与者，但参与者实际上并不是系统的一部分。它们存在于系统之外。,参与者之间的泛化关系,一些参与者可能具有共同的对系统调用的请求。 一种做法是显式地将这样同的每一个请求与每一个参与者相关联。（不推荐） 如果一组参与者具有共同的性质，可以把这些性质抽取出来放在另一个参与者中，它们再从中继承，把这种关系称为参与者之间的泛化关系。 定义：从参与者A到参与者B之间的泛化关系是指，A的实例能与和B实例进行通讯的用况实例进行通信。,参与者之间的泛化

12、关系,识别参与者,1首先将精力集中于启动系统行为的参与者。 2从用户、外部系统和设备三个方面发现参与者 3通过识别一般的或较特殊的角色来组织参与者。,用户、外部系统与设备,用户 从直接使用系统的人员中发现参与者。 这里强调的是直接使用，而不是间接的。 特定的人，在系统中可扮演不同的角色。 是用户角色的类别 外部系统 所有与系统交互的外部应用系统都是参与者。 外部应用系统可以是其他子系统、上级系统或任何与它进行协作的系统。,用户、外部系统与设备（续）,设备 识别所有与系统交互的设备。 与系统相连的设备 向系统提供外界信息或系统的控制下运行。 通常，不包括监视器、键盘、鼠标和其它的标准的用户接口类

13、型设备。 考虑外部传感器（输入信息）和受控马达（输出信息）。,系统,设备,外部世界,系统,设备,外部世界,人员,外部事件,当我们构造实时和异步交互的系统时，将外部事件识别为潜在的参与者就变得更加重要了。 例如，由时间的流逝而激发系统的活动是常见的情况。可以把时间事件作为一个参与者，也可以把时间事件作为系统的一部分。,4.用况,定义：用况是对参与者使用系统的一项功能时所进行的交互过程的描述。 A use case is a special sequence of transactions, performed by a user and a system in a dialogue. Jacob

14、son 1987 Use case是通过某部分功能来使用系统的一种具体的方式因此，usecase是相关事务的一个具体序列，参与者和系统以对话的方式执行这些事务从用户的观点看，每个usecase都是系统中一个完整序列的事件。Jacobson 1992 UML2.4,使用用况的原因,用况是对用户需求（主要是功能需求）的规范化的描述。 为领域专家、最终用户和开发者提供一种相互交流的手段。 为开发者提供一种认识和理解系统的方法为开发者提供一种认识和理解系统的方法。 用况是开发期间随着演化而测试每个元素的基础。 用况的中文译法 用况的实例场景,用况与参与者之间的关系,定义：关联是参与者在用况中的参与（也

15、就是参与者实例与用况实例之间的相互通信）。 若没有进行特殊的说明，任何一方都可发送和接收消息。 这是参与者和用况之间的唯一关系。交互是双向的，参与者能够产生对系统的请求，或系统要求参与者采取某些动作。 把参与者和用况之间的关联表示成参与者和用况之间的一条实线。,例1:语音邮件系统,在语音邮件系统中,当有人拨打一个号码时,如果没有人接听此电话,此人便可留下信息.以后,该信息能够被另一个人检索到并进行保留或删除.,划分系统边界 识别参与者 识别用况 画用况图 用况详细描述,语音邮件系统,检测摘机,呼叫系统,接听来电,检索信息,保留信息,删除信息,参与者 系统 拨打电话 转检测摘机,参与者 系统 检

16、测摘机 若三次内接听 不作为 若三次无人接听 转接听来电,参与者 系统 欢迎语音 请说姓名 回答姓名 请留言 留言 再见语音挂机,参与者 系统 请求检索 显示检索界面 输入检索条件 查询并返回结果,用况与参与者之间的关系（续）,浏览图片,浏览者,一个用况可能同多个参与者交互 参与者之间通过系统实时交互 参与者之间与系统处于同一控制流,发邮件,发送者,?,例2:选课系统,在选课系统中,学生登录后可以查询所有的课程,并选择所要修的课程,也可以放弃已经选择的课程,教务员登录后可以加入新的课程,删除一门课程,并可以与指导者一起审查学生所选的课程,如果不合适,则取消其所选的课程.,选课,放弃选课,加入新

17、课,删除课程,审查选课,查询课程,登陆系统,参与者 系统 请求登陆 显示登陆界面 输入用户名密码 验证 若验证成功,显示用户界面 否则提示错误,参与者 系统 请求查询 显示查询界面 输入查询条件 查询并返回结果 浏览,参与者 系统 选择课程 记录并显示其选择的所有课程,参与者 系统 请求放弃 列出该生的所有课程 选择要放弃课程 记录并显示其现有课程,参与者 系统 请求加入新课 显示加入新课界面 输入课程名教师等 记录并显示,参与者 系统 请求删除课程 列出所有的课程 选择要删除的课程 记录并显示现有的课程,管理者 系统 指导者 将每个学生的选课 发送 审查,若不 通知系统发给其各自 合适,则取

18、 消 的指导者 保存,用况之间的关系扩展关系,定义：从用况A到用况B的扩展关系是指，用况B的实例是可以被用况A指定的行为扩充（服从于在扩展中指定的特定条件）。行为被插入到由B中的扩展点定义的位置。 通过敞开的虚线箭头表示用况之间的扩展关系，该箭头从提供扩展的用况指向基用况。这个箭头用关键字标记。可以在这个关键字附近表示这个关系的条件。 扩展点是用况中的一个位置，在该位置上，可以插入另外一些用况的动作序列。 在一个用况中，每一个扩展点的名字是唯一。 可以把扩展点列在用况中的一个题头为“扩展点”的分栏中。以一种适当的方式给出扩展点的位置描述，通常采用普通的文本。,用况B . e .,用况A . .

19、 .,定义：从用况A到用况B的包含关系表明，用况A的一个实例也包含了用况B所指定的行为。在用况A中定义的位置包含该行为。 通过一个敞开的虚线箭头表示用况之间的包含关系，该箭头从基用况指向被包含的用况。这个箭头用关键字标记。 包含关系使得我们在一个用况中局部化多个用况中共同的活动序列。这样，可以避免多次描述同一事件流；当这个共同的序列发生变化时，这样就显现出优势，即只需要在一个地方进行改动。,A,B,用况之间的关系包含关系,用况A Include B .,用况B . . .,包含关系与扩展关系的区别-观点1,相同点 都是不完整的 都离不开基本用况 都可实现为子程序 不同点 方向不同 1对多选包含

20、关系（1个子用况，多个主用况） 多对1选扩展（多个子用况，1个主用况） 包含处理一般的情况 扩展处理特殊的情况,包含关系与扩展关系的区别-观点2,Maksimchuk instead, the extension use case specifies where in the base use case the use case instance shall make the interruption.,包含关系与扩展关系的区别-观点4,UML Distilled, Martin Fowler 当在两个或多个独立usecase中重复自己并希望避免重复时，使用包含。 当表述关于正常行为的一个变化

21、情形并希望临时表述时，使用泛化。 当表述正常行为的一个变化情形并希望使用更为受控的形式在基本usecase中说明扩展点时，使用扩展。,包含关系与扩展关系的区别-观点5,面向对象的系统分析，邵维忠 杨芙清 语义差别甚微 实践中很容易相混 为什么没有包含点 方向不同,泛化关系 子用况继承父用况的行为和含义. 子用况还可以增加或覆盖父用况的行为. 子用况可以出现在父用况出现的任何位置. 用一个指向父用况的带有封闭的空心箭头的实线来表示用况之间的泛化关系。,A,B,用况之间的关系,用况A a b c,用况B a b x c,参与者泛化与用况泛化的混合使用 （Writing Effective Use

22、Case，Alistair Cockburn ）,普通销售人员终止除大交易外的所有交易；高级交易人员终止所有交易。,用况分类,高层用况和低层用况 高层用况描述对有价值的功能所提供的要素做了总的、简要的描述，并不考虑这些有价值的功能是怎样获得的。 低层用况描述提供了表示活动、任务或变化的确切顺序的业务细节。 本质用况和具体用况 本质用况是独立于实现的（硬件的和软件的）业务解； 具体用况是依赖设计的。 主要用况和次要用况 主要用况捕获系统的主要业务功能。 次要用况处理不常见的和例外的情况。可选用况表示可以处理也可以不处理的用况。,用况是对场景的概括 （Writing Effective Use C

23、ase，Alistair Cockburn ）,ATM交易,查询,取款,转帐,线路故障,无钱,无效卡,成功场景,失败场景,捕获用况的策略,1首先写下两个或三个最常见的简单场景（用况）。 2当有两个或三个场景看上去很相似的时候，就试着产生更“抽象”的场景（用况）。 3应谨慎选择用于不常见事件的附加的用况，并保持在可管理的数量上。 4以增量的方式进行分析。 首先开发主要的、高层的用况模型。 然后使用该模型开发主要的、本质的用况模型。 进一步地，使用所得到的模型指导开发次要的、本质的用况。 最后，使用该模型开发次要的、具体的用况。,用况文档模板,用况名 描述：对该用况的一句或两句的描述。 参与者：识

24、别参与用况的参与者。 包含：识别该用况所包含的用况。 扩展：识别该用况可以扩展的用况。 泛化：若该用况是子用况，则要说明它的父用况。 前置条件：启动此用况所必须具备的条件。 细节：识别该用况的细节。 后置条件：识别在该用况结束时确保成立的条件。 例外：识别在该用况的执行的过程中可能引起的例外。 限制：识别在应用中可能出现的任何限制。 注释：提供可能对该用况是重要的任何附加信息。,举例,例3: 网上职位发布系统,网上职位发布系统中,职位发布员编辑准备发布的职位名称,职位要求,招聘人数等信息, 预览一下其发布职位的版式,在通过权限检查后,方可在网上发布. 除了一般类型的职位发布外,还有一种特效职位

25、发布,允许职位发布员发布自定制的图片页面等.,发布职位,职位发布员,检查权限,提交,预览,特效发布职位,发布职位 参与者 系统 请求发布职位 显示发布职位界面 填写职位名称/职位要求/招聘人数 接受 Include 预览 若不满意,继续编辑 显示发布职位界面(有已输入的信息) 若满意,提交 Include 检查权限 Include 提交 预览 请求预览待发布的职位 根据其内容产生预览界面并显示 观察后返回 返回 检查权限 检查该发布员的职位发布余额是否,用况分组,当许多用况具有同样的功能或者以同样的方式相互联系，就将他们归在一起。UML 的包表示了用况的聚类。,分组的依据,同样的参与者 共同的

26、实体 书: 读者 管理员 特定的工作流,审查,参与者 确定系统环境中的所有角色，并都归入了相应的参与者。 每个参与者都至少和一个用况关联； 若一个参与者是另一个参与者的一部分，把它们合并； 若两个参与者相对于系统而言，扮演了类似的角色，应该在它们之间使用泛化关系； 用况 每个用况都至少和一个参与者关联； 若两个用况有相同或相似的序列，可能需要合并它们，或抽取出一个新用况，在它们之间使用包含、扩展或泛化关系。 若用况过于复杂，为了易于理解，考虑进行分解；若一个用况中有完全不同的事件流，最好把它分解成不同的用况,例4: ATM机,持卡用户在银行ATM机上进行查询取款转帐等业务.若ATM发现用户连输

27、三次密码不对, 该卡已挂失或忘记取卡,则吞卡.检测到无效卡则退卡.每到午夜12点,统计该日的取款总额并发送至总部系统,机内无现金时及时通知总部系统.,ATM交易,扩展点: 可能的交易 是否忘记取卡,查询余额,转帐,用户识别,扩展点: 是否为盗卡 是否为无效卡,取款,扩展点: 是否无现金,午夜12点,统计总额,吞卡,退卡,通知无钱, 可能的交易 要求查询, 可能的交易 要求转帐, 可能的交易 要求取款, 是否忘记取卡 是, 是否为盗卡 是, 是否为无效卡 是, 是否无现金 是, ,ATM交易 参与者 系统 显示广告 插卡 include(识别用户) 可能的交易 打印凭条 退卡 是否忘记取卡 识别

28、用户 用户 系统 总部系统 得到顾客ID 是否为无效卡 输入 请顾客输入的密码 请求验证 验证用户密码 如果密码正确，返回 如果错误，请重输 是否为窃卡 （连输三次错误密码） 查询余额 用户 系统 总部系统 提请查询 请求总部系统 查询 显示余额 返回余额,例5:,很多软件系统在一开始都需要登录，若用户登录成功，则可进入系统。如下以一个研究生学籍管理系统为例，描述四种登录方法。为了简化起见，假设此处仅描述登录、选课和查看学分这3项功能。,方案一,登录 参与者 系统 研究生启动系统； 系统提示研究生输入研究生证号和密码； 研究生输入研究生证号和密码； 系统进行验证，给出验证信息； 若通过，若该生

29、选择选课 include(选课)； 若通过，若该生选择查看学分 include(查看学分)；,登录,查看学分,选课,点评: 该方法的缺点是，必须要了解系统的所有其它模块，才能描述清楚“登录”用况。向系统增加新用况时，也要修改登录用况。此外，从维护的角度看，有时会忘记对“登录”用况进行修改。,方案二,登录,查看学分,选课,选课 参与者 系统 研究生启动系统 include(登录)； 若通过，系统执行用况“选课”的其余部分；,点评: 这个方法中的“登录”用况仅描述有关登录的信息，研究生执行系统的每项功能都要先登录。其缺点为，对研究生要进行多次验证。,方案三,查看学分,选课, 选课 选择选课,扩展点

30、: 选课 查看学分,登录,登录 参与者 系统 研究生启动系统； 系统提示研究生输入研究生证号和密码； 研究生输入研究生证号和密码； 系统进行验证，给出验证信息； 若通过，选课 查看学分,点评: 该方法与方法一相比，对“登录”用况的描述要清楚一些。在增加新用况时，仅在登录用况中添加扩展点即可。, 查看学分 选择查看学分,方案四,查看学分,选课, 可能的操作 请求选课,扩展点: 可能的操作,登录,登录 参与者 系统 研究生启动系统； 系统提示研究生输入研究生证号和密码； 研究生输入研究生证号和密码； 系统进行验证，给出验证信息； 若通过，可能的操作,点评: 该方法与方法一相比，对“登录”用况的描述

31、要清楚一些。在增加新用况时，仅在用况图中添加扩展用况即可。, 可能的操作 请求查看学分,方案五,登录,查看学分,选课,登录 参与者 系统 研究生启动系统； 系统提示研究生输入研究生证号和密码； 研究生输入研究生证号和密码； 系统进行验证，给出验证信息； 选课 参与者 系统 若研究生通过了登录且选择了选课， 系统开始执行用况“选课”；,点评: 若使用该方法，必须要在“选课”用况和“查看学分”用况中指定前置条件：只有在登录成功后才能执行自己。,课堂练习,某供电局准备开发线路监控软件系统，用于各条供电线路的情况。该系统由专职的管理员来操作。每条供电线路安装一个线路检测仪，每30秒采集1次该线路的信息

32、（包括电压、电流）。每隔1小时，线路检测仪通过专线向线路监控软件系统传送该小时的数据，系统接受后，保存在系统中。 管理员登陆系统后，可进行如下几项工作： 线路基本信息录入：录入每条线路的基本信息，包括线路号、位置等等。 搜集采样信息：当系统与某线路的检测仪通讯时，系统提示管理员正在与该线路的检测仪通讯，并将检测仪所收集的该线路该时段的采样信息保存在系统中。 采样信息整理：可以根据这些数据生成该线路该日的数据报表与曲线，并能打印出来。,管理员,登录,线路基本信息录入,搜集采样信息,整理采样信息,线路检测仪,用况建模的注意事项,应确保不仅领域专家而且程序员都能够理解每一种用况所描述的系统使用的重要

33、意义。 定义用况文本时，应准确和一致地使用名词和动词 区分出在用况之间参与者之间的关系 大量的用况应该组织为包,运用建模工具,建模工具 JBOO Rational rose Telelogic Tau 绘图工具 Visio powerpoint 编程工具 JBuilder Delphi .,UML2.0中的用况图,扩展关系的表示法有变化,吞卡, 是否为盗卡 是,扩展点: 是否为盗卡,用户识别,吞卡,扩展点: 是否为盗卡,用户识别,条件:为盗卡 扩展点:是否为盗卡,UML1.X,UML2.0,UML2.0中的用况图,用况的表示法,用况图,用况图的研究,用况驱动的软件开发 积极意义 有助于分析模型

34、、设计模型的建立 有助于改进分析、设计以及实现与测试 问题 对用况依赖过高 导致功能分解的老路,用况与MDA 尽管UML致力于定义越来越精确的用况定义，但UML并没有对用况的演化做出多大的贡献 MDA的提出，要求实现模型之间的转化. 按照UML现有的用况图的语义，远远不能达到支持从用况图到其他模型自动转化的程度。,与微软过程与XP中的类似物的比较,Usecase图与微软过程中的对应物 Persona vs. actor Persona是actor的实例 Persona更为具体、真实、鲜活、好记 便于抓住特定的用户 Scenarios vs. usecase Scenarios 是 usecas

35、e的实例 Scenarios 先于 usecase Scenarios是业务，但不是与系统的交互（ storyboard ） 其中有界面模拟,Colby的使用场景 大多敷早上， Colby都准时起床去学校。去学校前，她通常很少有时间去检查她的AOL电子邮件账户。在学校里她仅可以在做科学课作业和进行社会学研究时才使用计算机图书馆虽然有许多计算机，但要使用的人太多了。 除使用学校的计算机外，在回家的路上， Colby会去县图书馆的一个部门使用计算机。她先登录到她的Hotmail账号查看一些她感兴趣的邮件(有时她喜欢使用这个账号而不是她的AOL电子邮件账号。因为她妈妈不知道这个账号，而且这个账号可以

36、在任何地方使用在学校、图书馆和家里。 然后她通过雅虎分类为她的英文论丈查找一些有关奥斯卡怀尔德的信息。在下线前，她还查看了一个BackstreetBovs”网站看看她喜爱的一个乐队有没有新东西。不管在哪儿登录，Colby主要用雅虎采搜索网站、但是她希望有一些东西“更酷”且让她无论在何处都能找到她的密友列表和聊天室。,与微软过程与XP中的类似物的比较,Usecase图与XP 使用者故事（user stories） User Story(用户故事)：描述对软件（或系统）用户或客户有价值的功能,只是需求描述，而不是详细的需求规范。 “As a DBA, I want to be able to co

37、mpress a table so that I can reduce my storage consumption“ Usecase有全局观，有图，可直接用与测试，细致 User story 一句话，简单，无图，概略 Scenarios vs. user stories user stories= Scenarios的目标 user stories 用户在身边做详细解释,RUP中的业务模型与业务用例(选讲),RUP中的业务模型与业务用例： business actor,A business actor (introduced in Rational Unified Process (RUP)

38、 to support business modeling) represents a role played by some person or system external to the modeled business and interacting with the business. Note, business actor is not defined in UML standard.,RUP中的业务模型与业务用例： Business Use Case,Though support for business modeling is declared as a goal of UM

39、L, UML specification provides no notion for business use cases. Business use cases were introduced in Rational Unified Process (RUP) to support Business Modeling to represent business function, process, or activity performed in the modeled business. Business use case should produce a result of obser

40、vable value to a business actor. A business use case defines what happens in the business when the use case is requested by business actor, it describes complete workflow or business process that produces results required or in need of business actor. Business use case is represented in RUP with use

41、 case oval and a line crossing it as shown below.,RUP中的业务模型与业务用例,Business Object Model,a business use-case model tells what a business process will do a business object model tells how it will be done. It serves as an abstraction of how business workers and business entities need to be related and t

42、o collaborate in order to perform the business. It indicates how workers relate both to each other and to things within the business.,区分业务工人(Business Worker),业务参与者在业务外面 业务工人在业务里面 A business worker is a class that represents an abstraction of a human that acts within the system. A business worker int

43、eracts with other business workers and manipulates business entities while participating in business use-case realizations.,区分业务实体(Business Entity),A business entity is a class that is passive; that is, it does not initiate interactions on its own. A business entity object may participate in many di

44、fferent business use-case realizations and usually outlives any single interaction. In business modeling, business entities represent objects that business workers access, inspect, manipulate, produce, and so on. Business entity objects provide the basis for sharing among business workers participating in different business,RUP中的业务模型,RUP中的业务模型,RUP中的业务模型,业务建模的目的是找出理由，有了这个新系统，对现在的流程确实有帮助： 新系统的引进是否改进系统间信息的流转？ 新系统的改进是否封装了本来在人脑中的业务逻辑