用例分析_业务建模一般步骤和方法
业务流程建模方法
业务流程建模方法
业务流程建模是指将一个复杂的业务过程进行分解并描述成一系列的活动、决策和分支，并以图形化的方式展示出来，以便更好地理解和分析业务流程，从而提高业务流程的效率和质量。
常见的业务流程建模方法有：
1. 流程图：采用流程图的形式将业务过程中的活动、决策和分支进行可视化展示，以便更好地理解和分析。
2. 事件流图：将业务过程中的事件和活动以及它们之间的关系进行可视化展示，以便更好地理解和分析业务流程的整体演变过程。
3. 数据流图：将业务过程中的数据流动和处理过程进行可视化展示，以便更好地理解和分析业务流程的数据流转和处理方式。
4. 时序图：通过时序图展示业务过程中的活动和事件之间的顺序关系，以便更好地理解和分析业务流程的执行顺序和流转路径。
5. UML建模：利用UML（统一建模语言）进行业务流程建模，包括使用用例图、活动图、时序图等来描述业务过程的各个方面。
以上方法可以根据具体的业务场景和需求来选择，用于对业务流程进行建模和分析，以便更好地优化和改进业务流程。
用例建模
10 1-10
ATM例子 寻找参与者 – ATM例子
1）如果我们所要定义的系统边界仅限于ATM机本身， 如果我们所要定义的系统边界仅限于ATM机本身， ATM机本身 那么后台服务器就是一个外部的系统， 那么后台服务器就是一个外部的系统，可以抽象为一个 参与者。 参与者。
2）如果我们所要定义的系统边界扩大至整个银行系统， 如果我们所要定义的系统边界扩大至整个银行系统， ATM机和后台服务器都是整个银行系统的一部分 机和后台服务器都是整个银行系统的一部分， ATM机和后台服务器都是整个银行系统的一部分，这时 候后台服务器就不再被抽象成为一个参与者。 候后台服务器就不再被抽象成为一个参与者。
17 1-17
使用角色和用例图组织你的用例
用例图是在一个图上显示了多个用例, 用例图是在一个图上显示了多个用例 它是一组用例的 全景图. 有时候角色我们称呼为用户,但是常常会指定一 全景图 有时候角色我们称呼为用户 但是常常会指定一 个具体的角色名称(比如 顾客).用户或者说角色位于系 比如:顾客 个具体的角色名称 比如 顾客 用户或者说角色位于系 统边界之外. 而系统在边界内. 统边界之外 而系统在边界内 角色也可以指非人类的外 部系统,但有时候许多人对这一点迷惑不解 但有时候许多人对这一点迷惑不解,我们已经发 部系统 但有时候许多人对这一点迷惑不解 我们已经发 现使用机器人这种图标可以消除这种迷惑误解. 现使用机器人这种图标可以消除这种迷惑误解 在用例和角色之间的连线表示这个角色是用例的执行者. 在用例和角色之间的连线表示这个角色是用例的执行者 这根连线也表示责任.比如 一个Customer(顾客 指向用 比如:一个 顾客)指向用 这根连线也表示责任 比如 一个 顾客 表示这个顾客负责执行check out(结帐 结帐) 例check out,表示这个顾客负责执行 表示这个顾客负责执行 结帐 可以有多个角色指向同一个用例.表示这个用例与多个 可以有多个角色指向同一个用例 表示这个用例与多个 角色关联.同样的 一个用户可以拥有多个角色.同一个用 同样的,一个用户可以拥有多个角色 角色关联 同样的 一个用户可以拥有多个角色 同一个用 户可以是一个职员,也可能是一个管理员 也可能是一个管理员. 户可以是一个职员 也可能是一个管理员
面向业务领域建模举例
需求收集
– 图书馆能够容易地建立、修改和删除标题、借书者、 借阅信息和预定信息。 – 系统能够运行在所有流行的技术环境中，包括Unix, Windows 和OS/2，并应有一个现代的图形用户界面。 – 系统容易扩展新功能。
• 这里我们暂时不必考虑预定的图书到达后通知预 定人的功能，也不必检查借书过期的情况。
类图
顺序图
数据库设计
• 根据类图和用例图，为该系统建立六张数 据库表：users、loginSession、Courses、 Content、BBS、Test，分别用来存放用户信 息、登录信息、精品课程主要信息、课程 内容信息、考试题库和留言板信息等。
关系数据库
网上商品交易系统的研究
• 本系统主要使用对象是
用例文档
2、如果借书者有预订： • 借书者被识别 • 书名被识别； • 与书名对应的一本可用书被识 别； • 系统借出对应的书； • 新的借出记录被登记； • 删除预订。
确定构建内容--面向对象分析
需求工程关注理解用户和他们的使用，而分析关注于理解要构建的内 容。 分析是一个迭代的过程！
软件工程教研室 熊伟 x_w_ei@
精品课程远程教育网站模型设计
• 从用户方面来看，精品课程网站用户必须 有学生、课程教师，以及管理员三类；
• 从功能方面来看，精品课程网站应有用户 管理（教师管理、学生管理）、课程生成、 课程管理（栏目管理、内容管理、考试管 理）网站浏览，以及网站留言等功能。
需求收集
• 在图书管理系统需求规范文档中可能指出如下内 容：
– 这是一个图书馆支持系统； – 图书馆将图书和杂志借给借书者。借书者已经预先注册， 图书和杂志也预先登记； – 图书馆负责新书的采购。每一本图书都购进多本书。当 旧书超期或破旧不堪时，从图书馆中处理掉。 – 图书管理员是图书馆的员工。他们的工作就是和读者打 交道并在软件系统的支持下工作。 – 借阅人可以预定当前没有的图书和杂志。这样，当他所 预定的图书和杂志归还回来或购进时，就通知预定人。 当预定了某书的借书者借阅了该书后，预定就取消。或 者通过显式的取消过程强行预定。
用例建模指南
I. 指南：用例II.主题解释如何查找用例用例如何演进 是否详细说明了所有的用例？用例的范围用例如何实现一个用例具有许多可能的实例用例实例的并行名称简要说明事件流 - 内容事件流 - 结构事件流 - 风格事件流 - 示例特殊需求前置条件和后置条件扩展点 用例图III. 解释以上定义中有几个关键词：用例实例。
以上定义所说的序列实际上是贯穿整个系统的某个特定事件流，即一个实例。
可能会有许多事件流，而许多事件流可能非常相似。
为了使用例模型便于理解性，应该将相似的事件流组合到一个用例中。
确定和说明某个用例实际上就是确定和说明一组相关的事件流。
系统执行。
这意味着系统提供用例。
主角和系统的某个用例实例进行通信。
可观测的结果值。
您可以给一个成功执行的用例赋予一个值。
用例应该确保主角可以执行某个具有可确定值的任务。
确定用例的正确级别或粒度是非常重要的事情。
正确级别是指所实现的用例不是太小。
在某些特定的环境中，可以将一个用例当作组织内的一个计划单元，该单元包括了担任系统的主角角色的个人。
动作。
一个动作就是一个计算或算法过程。
当主角向系统提供信号或当系统得到时间事件时，动作即被调用。
动作可能包含向调用的主角或其他主角进行的信号传输。
动作是不可分的，它要么完全执行，要么根本不执行。
特定主角。
主角是查找正确用例的关键，这尤其是因为主角可帮助您避开太大的用例。
例如，考虑一个可视化建模工具。
该应用程序有两个真正的主角：开发人员，他负责以该工具作为支持来进行系统开发；系统管理员，他负责管理该工具。
这两个主角对系统都有各自的要求，因而需要自己的用例集。
系统的功能由不同的用例来定义，每个用例都代表了一个特定的事件流。
用例说明将定义执行用例时在系统中发生的事件。
例如，在自动柜员机中，客户可以从帐户中提取现金、将现金转入帐户或核对帐户余额。
这些功能对应于可以用用例来代表的事件流。
每个用例本身就有一个要执行的任务。
所收集到的用例组成了所有可能的系统使用方法。
用例建模步骤
三种模型的关系
4. 功能模型中的数据存储，以及数据的源点/终点， 通常是对象模型中的对象。 5. 功能模型中的数据流，往往是对象模型中的属性值， 也可能是整个对象。 6. 功能模型中的处理可能产生动态模型中的事件。 7. 对象模型描述了功能模型中的动作对象、数据存储 以及数据流的结构。
用例图：视图
在面向对象方法学中，对象模型是最基本的、最 重要的，它为其他两种模型奠定了基础，我们依靠对 象模型完成三种模型的集成。
1. 针对每个类建立的动态模型，描述了类实例的生命 周期或运行周期。 2. 状态转换驱使行为发生，这些行为在数据流图中被映 射成处理，它们同时与对象模型中的服务相对应。 3. 功能模型中的处理，对应于对象模型中类-&-对象所 提供的服务。
一般—特殊结构是一种分类结构，反映 了类间的一般与特殊的关系。一般类与特殊类 之间是一种“is a”的关系，如：汽车是一种交 通工具。同样，特殊类还可以分为更特殊的类， 这样可形成类的层次结构。
• 2. 组装结构 刻画整体—部分组织，表达了自然的整体和部分的结构 关系，从而把一些部分的聚合构造成整体。
计详细的动态模型来自阶详细的功能模型
段
面向对象技术是一个有全新概念 的开发模式,其特点是:
(1)方法是对软件开发过程所有阶段进 行综合考虑而得到的;
(2)从生存期的一个阶段到下一个阶段 所使用的方法与技术具有高度的连 续性;
(3)将OOA、OOD、OOP集成到生存
期的相应阶段.
面向对象分析 Object-Oriented Analysis
• 非正式分析法
用自然语言书写的需求陈述为依据确定的候选者 。
3. 定义类的结构和层次
类的结构主要有两种：一般—特殊 （generalization—specialization）结构和整 体—部分（whole—part）结构。
业务建模
通过用例分析技术，建立企业的业务模型，进行适当的切割，选取稳定的软件架构，分析出企业的业务实体（Business Entity 企业中微小不可分的事物，抽象或具体的，如帐户，契约等，又被称为Business Object），以此为基础，组装出组件（Component），落实到相应的三层结构，建立针对特定功能区域的应用系统。
以这样的流程做出来的企业应用系统，不论规模是部门级的，还是企业相关图书级的，都有扩展的余地。
以组件为基础的软件三层构架，也能够较好的配合企业的业务变化而变化（相应变化的代价较小）。
而整个流程的第一步，就是业务建模了解目标组织（将要在其中部署系统的组织）的结构及机制。
了解目标组织中当前存在的问题并确定改进的可能性。
确保客户、最终用户和开发人员就目标组织达成共识。
业务建模导出支持目标组织所需的系统需求。
为实现这些目标，业务建模工作流程说明了如何拟定新目标组织的前景，并基于该前景来确定该组织在业务用例模型和业务对象模型中的流程、角色以及职责。
作为对这些模型的补充，还开发了以下工件：补充业务规约词汇表与其他工作流程的关系业务建模工作流程与其他工作流程的关系如下：业务模型是需求工作流程的一种重要输入，用来了解对系统的需求。
业务实体是分析设计工作流程的一种输入，用来确定设计模型中的实体类。
环境工作流程开发并维护支持工件，例如“业务建模指南”。
简介：业务建模是OOAD的重要组成部分，简单的说，业务建模就对业务领域问题进行结构化的描述。
这个描述将会直接指导最终生成的软件，业务模型是否具有扩展性，业务模型是否能够正确的反映需求，都将影响最终软件的质量。
1. 业务建模1.1 为什么要业务建模？我们把业务建模这个概念放在了最后的部分，因为面向对象是业务建模的基础。
面向对象是一种用计算机语言模拟现实生活的技术。
而传统的语言是基于时序的，是计算机观点的语言，和人们熟悉的社会观点是不同的。
在软件发展初期时，这并不是什么很大的问题，但是当软件规模越来越大，变化的速度越来越快的时候。
用例建模指南
用例建模指南用例(Use Case)是一种描述系统需求的方法，使用用例的方法来描述系统需求的过程就是用例建模。
用例方法最早是由Iva Jackboson博士提出的，后来被综合到UML规范之中，成为一种标准化的需求表述体系。
1. 什么是用例？传统的需求表述："软件需求规约"(Software Requirement Specification)。
传统的软件需求规约基本上采用的是功能分解的方式来描述系统功能，在这种表述方式中，系统功能被分解到各个系统功能模块中，我们通过描述细分的系统模块的功能来达到描述整个系统功能的目的。
缺点：采用这种方法来描述系统需求，非常容易混淆需求和设计的界限，这样的表述实际上已经包含了部分的设计在内。
由此常常导致这样的迷惑：系统需求应该详细到何种程度？一个极端就是需求可以详细到概要设计，因为这样的需求表述既包含了外部需求也包含了内部设计。
在有些公司的开发流程中，这种需求被称为"内部需求"，而对应于用户的原始要求则被称之为"外部需求"。
功能分解方法的另一个缺点是这种方法分割了各项系统功能的应用环境，从各项功能项入手，你很难了解到这些功能项是如何相互关联来实现一个完成的系统服务的。
所以在传统的SRS文档中，我们往往需要另外一些章节来描述系统的整体结构及各部分之间的相互关联，这些内容使得SRS需求更象是一个设计文档。
1.1 参与者和用例从用户的角度来看，他们并不想了解系统的内部结构和设计，他们所关心的是系统所能提供的服务，也就是被开发出来的系统将是如何被使用的，这就用例方法的基本思想。
用例模型主要由以下模型元素构成：∙参与者(Actor)参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统，他们代表的是系统的使用者或使用环境。
∙用例(Use Case)用例用于表示系统所提供的服务，它定义了系统是如何被参与者所使用的，它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话。
OO系统分析员之路--用例分析系列(3)--业务建模之涉众
在了解了系统目标以后，系统分析员最先要做的事情不是去了解业务的细节，而是去发现与这个目标相关的人和物。
英文把这种人和物称为Stakeholder，在Rose中，这类模型的类型被定义为Business Actor 。
有的资料翻译为干系人，笔者则更喜欢涉众这种翻译方法。
这就谈到了业务建模的第一步：发现和定义涉众。
从这一篇开始，笔者将借助一个虚拟的实例来阐述获取用例的方法，以及如何判断用例获取是否完备，粒度选择是否合适。
事实上，在做这些工作时，我们正在进行需求分析的第一个阶段，即业务建模阶段。
借助这个例子，笔者同样会阐述业务建模到底应该做什么，做到什么地步才能说明业务需求已经完整，可以称为一份完整的需求规格说明书了。
一般来说，只有当以下工作都完成，才能说业务模型建立完成，它们是：∙发现和定义涉众∙画定业务边界∙获取用例∙绘制用例场景图∙绘制业务实体模型（领域模型）∙编制词汇表下面笔者开始就一个事例来说明如何完成这些工作，这只是一个虚拟的事例，它的合理性和真实性请读者不必追究。
现在我们接到一个项目，是一个网上图书借阅系统，初步跟客户接触，网上图书馆的业务负责人这样告诉我：我们原本是一个传统的图书馆，传统的借书方式要求读者亲自来到图书馆，这显得非常不方便，而且随着藏书的增加和读者群的增长，尤其而且大量的读者到图书馆，使得图书馆的场地不足，工作人员也不够了。
所以想到借助网络，让读者通过网络借/还书，这样可以省掉大量的场地维护和工作人员成本支出，同时计算机可以方便的检索目录，让读者可以足不出户借到需要的书。
为了把书送到借阅人手里，我们已经联系了A特快专递公司和B城市物流公司，初步达成协议，由他们往返借阅人和图书馆之间把图书送出和收回。
读者在网上出示和验证借书卡，找到他们需要的书，提交申请，图书管理员确认后，就会通知物流公司来取书，当读者拿到书之后，物流公司需要把读者的签单拿回来以证明读者已经拿到了书。
当然这个过程中，读者是需要付费的。