需求分析与建模课件.ppt

《需求分析与建模课件.ppt》由会员分享，可在线阅读，更多相关《需求分析与建模课件.ppt（79页珍藏版）》请在三一办公上搜索。

1、.,1,1,第5章 需求分析与建模,需求分析必要性结构化分析面向对象分析需求用例分析,.,2,2,5.1 需求分析与软件分析,神父之牛的故事有个神父在教堂为一个人忏悔。那人说：“神父，我偷了别人一头牛，我该怎么办？我把牛给你好不好？”神父回答：“我不要。你应该把那头牛送还给失主才对。”那人说：“但是他说他不要。”神父说：“那你就自己收下吧。”结果，当天晚上神父回到家后，发觉他的牛不见了。,需求分析的必要性：,.,3,3,5.1 需求分析与软件分析,95 折=95%9 折=9%?(9 折=90%),需求分析的必要性：,.,4,需求分析与建模,需求分析与软件分析结构化分析面向对象的分析需求用例求分

2、析,.,5,5.2 结构化分析,结构化分析（SA）方法是一种面向过程的需求分析方法，主要对数据(流)进行分析，基本思想是将系统抽取出“数据”和“控制”两部分，再分别进行抽象和处理。数据流图（DFD）、数据字典（DD）和流程图是结构化分析最常用的工具。数据流图用来描述数据流从输入到输出的变换流程。数据字典是关于数据的信息的集合，也就是对数据流图中包含的所有元素的定义的集合。,.,6,5.2 结构化分析,.,7,5.2 结构化分析,结构化分析（SA）方法的特点简单高效适合需求分析非常清楚的系统,.,8,需求分析与建模,需求分析与软件分析结构化分析面向对象的分析需求用例分析,.,9,1面向对象(Ob

3、ject Oriented,OO)的基本思想模拟人类认识和解决问题的方式遇到问题认识个体对问题空间（问题域）进行划分归类找出每个类中的基本特征抽象找出实现的解法（求解域）见“第5章补充-面向对象的思想、方法和应用”,5.3 面向对象的分析-基本思想,.,10,5.3 面向对象的分析-基本思想,面向对象的开发方法可描述为：（1）客观事物都是由对象（object）组成的 对象是在客观事物基础上抽象的结果，任何复杂的事物都可以通过对象的某种组合构成。,（2）对象由属性和方法组成 属性（attribute）反映对象的信息特征。如：特点、值、状态等。方法（method）则用 来定义改变对象属性状态的各种

4、操作方式。,(3)对象之间的联系通过传递消息来实现传递消息（message）的方式是通过消息模式（message pattern）和方法所定义的操作过程来完成的。,(4)对象可按其属性进行归类 类（class）有一定的结构，类可以有超类（super class）这种对象或类之间的层次结构是靠继承关系维系的。,（5）对象是被封装的实体，类可以有子类(subclass)所谓封装（encapsulation），即指严格的模块化。这种封装的对象满足软件工程的要求，而且可以直接被面向对象的程序设计语言所接受。,.,11,2结构化方法与OO方法的比较结构化方法依赖基本的数据结构，直接附加语义协议，处理信息

5、,5.3 面向对象的分析-比较,.,12,2结构化方法与OO方法的比较OO方法利用数据结构的多重性，层层变换，最后在最上层附加语义协议,5.3 面向对象的分析-比较,.,13,2OO方法与结构化方法的比较结构化方法：基于变换(输入输出)，数据与指令分开OO方法：基于分解，数据与指令放在一起结构化方法从一开始就将系统拆分成“数据”和“控制”两部分，再分别进行抽象和处理OO方法将任务分解为若干较小的子任务，最后才进行“数据”和“控制”的拆分把功能与信息混合的的系统“拆解”为数据和控制，是系统分析与设计过程中最大的风险OO方法将此风险推后，在一系列小系统上“拆解”，更为安全可靠,5.3 面向对象的分

6、析-比较,.,14,如果你的分析习惯是在调研需求时先弄清楚有多少业务流程，再画出业 务流程图，然后顺藤摸瓜，找出业务流程中每一步骤的参与部门或岗位，弄清楚在这一步参与者所做的事情和填写表单的结果，并关心用户是如何把这份表单传给到 下一个环节的。那么很不幸，你还在做面向过程的事情。如果你的分析习惯是在调研需求时最先弄清楚有多少部门，多少岗位，然后找到每一个岗位的业务代表，问他们类似的问题：你平时都做什么？这件事是谁交办的？做完了你需要通知或传达给谁吗？做这件事情你都需要填写些什么表格吗？.那么恭喜你，你已经OO啦！,5.3 面向对象的分析-比较,闲话：今天你OO了吗？,.,15,3、面向对象技术

7、的基本概念:对象和实例(object&instance)类(class)封装(encapsulation)继承(inheritance)多态(polymorphism)消息(message),5.3 面向对象的分析-基本概念,.,16,对象模型基本元素的标识1）类、属性、方法 类是具有相同属性和操作的对象集合的总称。它是面向对象的一个基本概念，类封装了客观世界中对象实体的特征与行为，即属性与方法。其表示法是一个矩形，由带有类名、属性和方法（操作）的分格框组成。如下图所示。,5.3 面向对象的分析-基本概念,.,17,属性 属性是指类的特性，它描述类所具有的一系列特性值。一个类可以有多个属性，也

8、可以没有属性。在类图中属性只要写上名字就可以了。如右上图.也可以在属性名后跟上类型甚至缺省取值，如右下图：,5.3 面向对象的分析-基本概念,.,18,方法 方法是指类所能提供的服务或可执行的操作。它表现类的动态特征。,5.3 面向对象的分析-基本概念,.,19,2）继承 继承，也称泛化，它是面向对象描述类之间相似性的一个重要机制。面向对象利用继承来表达这种相似性，这使得可以利用继承来管理类，同时也使得在定义一个相似类时能简化类的定义工作。,5.3 面向对象的分析-基本概念,.,20,继承（泛化）关系,5.3 面向对象的分析-基本概念,.,21,3）超类、父类、子类 一个类可以继承其他类的属性

9、和方法。继承了其它类属性和方法的类称为子类，被继承的类称为父类或超类。它们的关系如下图所示。子类复用父类属性和方法的过程，称为继承或泛化。没有父类的类被称为基类或根类；没有子类的类被称为叶类。如果一个类恰好只有一个父类，这样的继承关系叫单继承。如果一个类有多个父类，这样的继承就是多继承。,5.3 面向对象的分析-基本概念,.,22,4）抽象类 抽象类（Abstract Class）是一种不能直接产生实例的类，它的作用仅仅是为了其他的非抽象类继承和重用。,5.3 面向对象的分析-基本概念,.,23,类“Window”包含有两个方法的名称“toFront()”和“toBack()”，但是没有方法实

10、现。类“Window”本身不能有实例，但它有两个特化的子类“Windows Window”和“Mac Window”，它们包含了方法“toFront（）”和“toBack（）”在不同平台上的实现。在本例中，类“Window”的作用是作为文本编辑器类“Text Editor”的一个接口。,5.3 面向对象的分析-基本概念,此图表示了抽象类的应用。其中文本编辑器独立于平台，为此定义了一个独立于平台的窗口对象类“Window”，它是一个抽象类，在类名“Window”下标有约束abstract。,.,24,5）多态多态是指子类对象可以像父类对象那样使用，同样的消息既可以发送给父类对象也可以发送给子类对

11、象。即在类等级的不同层次中可以共享（公用）一个行为（方法）的名字，不同层次中的每个类各自按自己的需要来实现这个行为。当对象接收到发送给它的消息时，根据该对象所属于的类动态选用在该类中定义的实现算法。,5.3 面向对象的分析-基本概念,.,25,5）多态 在不同类中具有相同名称的方法（操作）。,5.3 面向对象的分析-基本概念,.,26,6）重载(Overloading)有两种重载：函数重载指同一个函数名可以对应着多个函数的实现，每种实现对应着一个函数体，这些函数的名字相同，但是函数的参数的类型不同。运算符重载是指同一个操作符可以施加于不同的操作数。重载进一步提高了面向对象系统的灵活性和可读性。

12、,5.3 面向对象的分析-基本概念,.,27,7）依赖(dependency)依赖是指一个类中的元素使用了另一个类。依赖关系描述类之间的使用关系。,5.3 面向对象的分析-基本概念,.,28,8）关联 关联（Association）是指对象类之间具有的语义联系。其基本表示如下。,应用于关联的4种修饰：关联名角色名多重性限定符与约束符,5.3 面向对象的分析-基本概念,.,29,9）聚合与组合 聚合（Aggregation）是一种描述类之间的整体与部分的组成关系。,5.3 面向对象的分析-基本概念,.,30,组合（Composition）是一种特殊的聚合，它的每个部分体都是必须的。如下图所示。,

13、5.3 面向对象的分析-基本概念,.,31,10）类图类图表达了一组类和它们之间的联系。,类图示意,5.3 面向对象的分析-基本概念,.,32,11）对象 对象是类的具体实例，即类在某时刻的一个快照。,5.3 面向对象的分析-基本概念,.,33,类图示意,11）对象图 对象图是类图的一个实例，它表示在某一时刻系统对象的状态、对象之间的联系状态。,5.3 面向对象的分析-基本概念,.,34,对象图示意,5.3 面向对象的分析-基本概念,.,35,12）消息 消息是从一个对象（发送者）向另一个或几个其他对象（接收者）发送的信号，或由一个对象（发送者或调用者）调用另一个对象（接收者）的操作。,5.3

14、 面向对象的分析-基本概念,.,36,13）接口(Interface)接口 是一组外部可访问的操作方法，它用于一个类为其他类提供服务。接口可以看作为一种特殊的抽象类，它不含属性，只有方法。接口代表系统中的接缝，接口两端的对象或组件可以独立变更，只要它们遵守和实现接口的规定，通过接口相联系即可。,5.3 面向对象的分析-基本概念,.,37,建立功能模型建立对象模型建立动态模型,5.3 面向对象的分析-分析方法,确定类与对象 确定结构与关联定义属性定义服务,准备典型的交互行为的脚本提取事件，确定事件的动作及目标对象排列事件顺序，确定状态及状态间关系,用例图描述,.,38,38,需求分析与建模,需求

15、分析与软件分析结构化分析面向对象的分析需求用例分析,.,39,39,5.4 需求用例分析,需求用例分析（基于用例的需求分析）用例的概念用例的粒度用例业务建模之涉众业务建模一般步骤和方法 用户、业务用例和业务场景 用例实现、用例场景和领域模型 用例规约的编写-业务规则和实体描述 编写UML需求规格说明书,.,40,5.4 用例分析-用例的概念,用例的定义用例就是与使用者(actor)交互的，并且给使用者提供可观测的有意义的结果的一系列活动的集合。用例的特征1系列活动是相对独立的。这意味着它不需要与其它用例交互而独自完成参与者的目的。也就是说从“功能”上说是完备的。（有人可能会想到，用例之间不是也

16、有关联关系吗？比如扩展/实现/包含。解释：用例间关系是分析过程的产物，而且这种关系一般的产生在概念层用例阶段和系统层用例阶段。对于业务用例，独立性特征是很明显的。）,比如在ATM取钱的场景中：取钱，读卡，验证账号，打印回执单等都是可能的用例,.,41,5.4 用例分析-用例的概念,用例的特征2执行结果对参与者来说是可观测的和有意义的。（例如，系统会监控参与者在系统里的操作，并在参与者删除数据之前备份。虽然它是系统的一个必需组成部分，但它在需求阶段却不应该 作为用例出现。因为这是一个后台进程，对参与者来说是不可观测的，它应该在系统用例分析阶段定义。）（又比如说，登录系统是一个有效的用例，但输入密

17、码却不是。这是因为登录系统对参与者是有意义的，这样他可以获得身份认证和授权，但输入密码却是没有意义的，输入完了呢？有什么结果吗？）,.,42,5.4 用例分析-用例的概念,用例的特征3用例必须由一个参与者发起。不存在没有参与者的用例，用例不应该自动启动，也不应该主动启动另一个用例。用例总是由一个参与者发起，并且满足特征2。例如从ATM 取钱是一个有效的用例，ATM吐钞却不是。(因为ATM是不会无缘无故吐钞的)。,.,43,5.4 用例分析-用例的概念,用例的特征4必然是以动宾短语形式出现的。即，必须有一个动作和动作的受体。例如，喝水是一个有效的用例，而“喝”和“水”却不是。（虽然生活常识告诉我

18、们，在没有水的情况下 人是不会做出喝这个动作的，水也必然是喝进去的，而不是滑进去的，但是笔者所见的很多用例中类似“计算”，“统计”，“报表”，“输出”，“录入”之类的 并不在少数。）,.,44,5.4 用例分析-用例的概念,用例的特征5需求分析阶段用例以参与者为中心（区别于以计算机 系统为中心），从参与者的角度来描述他要做的日常工作（区别于以业务流程描述的方式），并分析这些日常工作之间是如何交互的（区别于数据流的描述方式）。换句话说，用例分析的首要目标不是要弄清楚某项业务是如何一步一步完成的，而是要弄清楚有多少参与者？每个参与者都做什么？业务流程分析则是后续的工作 了。,.,45,5.4 用例

19、分析-用例的概念,用例就是功能的划分和描述，认为一个用例就是一个功能点错！,.,46,46,5.4 用例分析-用例的粒度,比如学生管理系统中：成绩管理、成绩录入、成绩修改、成绩删除、成绩保存等都是可能的用例成绩管理包含了后续的其它用例，成绩管理粒度更大一些，其它用例的粒度则要小一些是一个大的用例合适，还是分解成多个小用例合适呢？,.,47,47,5.4 用例分析-用例的粒度,经验：根据阶段不同，使用不同的粒度。在业务建模阶段，用例的粒度以每个用例能够说明一件完整的事情为宜。即一个用例可以描述一项完整的业务流程。这将有助于明确需求范围。例如取钱，报装电话，借书等表达完整业务的用例，而不要细到验证

20、密码，填写申请单，查找书目等业务中的一个步骤。在用例分析阶段，用例的的粒度以每个用例能描述一个完整的事件流为宜。可理解为一个用例描述一项完整业务中的一个步骤。需要注意的是，这个阶段需要采用OO方法，归纳，抽象业务用例中的概念模型。例如，宽带业务需求中有申请报装，申请迁移地址用例，在用例分析时，可归纳和分解为提供申请资料、受理业务、现场安装等多个业务流程中都会使用的概念用例。在系统建模阶段，用例视角是针对计算机的，因此用例的粒度以一个用例能够描述操作者与计算机的一次完整交互为宜。例如，填写申请单、审核申请单、分配资源、派发任务单等。可理解为一个操作界面，或一个页面流。在RUP中，项目计划要依据系

21、统模型编写，因此另一个可参考的粒度是一个用例的开发工作量在一周左右为宜。,报装电话,申请资料,受理业务,现场安装,填写申请单,审核申请单,分配资源,派发任务单,.,48,48,5.4 用例分析-用例的粒度,实际上，用例粒度的划分依据（尤其是业务用例）：用例的粒度是以该用例是否完成了参与者的某个目的为依据。例如：某人去图书馆，查询了书目，出示了借书证，图书管理员查询了该人以前借阅记录以确保没有未归还的书，最后借到了书。从这段话中能得出多少用例呢？只有一个：借书。(其它都只是完成这个目的过程)，(这里讨论的是业务用例)。（用例分析是以参与者为中心的，用例的粒度以能完成参与者目的为依据）,.,49,

22、49,5.4 用例分析-用例的粒度,上述粒度选择方法只是通常情况下的做法，并不是一个统一的标准现实中，大型系统和小型系统的用例粒度选择会有较大差异。这种差异是为了适应不同的需求范围。（大型项目应选择大粒度，有助于把握需求范围，不容易遗漏。小项目应选择小粒度，避免需求模糊而易忽略细节）一般来说，一个系统的业务用例定义在多于10个，少于50个之间同一个需求阶段，所有用例的粒度应该是同一个量级的,.,50,50,5.4 用例分析-用例的粒度,实例分析：业务建模阶段，用例的粒度以每个用例能够说明一件完整的事情为宜。即一个用例可以描述一项完整的业务流程在系统建模阶段，用例视角是针对计算机的，因此用例的粒

23、度以一个用例能够描述操作者与计算机的一次完整交互为宜一个普通的财务系统的用户管理，有增删改查这里，把“用户管理”作为一个用例，还是把增删改查分别作为用例呢？（他们每一个都是一个完整的业务流程和一次完整交互，而且也都是一个actor发起的动作）,.,51,51,5.4 用例分析-用例的粒度,实例分析：业务用例应以“管理用户”或“维护用户”作为粒度，而增、删、改、查则作为系统用例理由：增删改查不能做为一个完整的业务来理解。（作为一个管理业务，数据只有先增，才会有改、删。增删改查结合起来才能完成actor的管理目的，只删或只增都不是业务的全部）。是否是一项完整业务，要看actor的目标，而不是事情是

24、否完整。（此例中，actor的目标是为了增加一个用户？是为了删除一个用户？都不是，而是为了管理用户，这个目标包括了用户这个实体的整个生命周期）,.,52,52,5.4 用例分析-用例的粒度,实例分析：再讨论，如果业务要求还有别的要求:权限升级，关系变更，.那么，如果将每个都作为一个业务用例，很容易造成一个结果:这些原本与用户实体紧密关联、共同组成用户实体生命周期的业务，被割裂成多个独立的业务，因为定义了多个用例（请参看用例特征第一条）。在RUP中，用例驱动的含义是:一个用例就是一个分析单元、设计单元、开发单元、测试单元甚至部署单元。把紧密关联的业务分成多个独立部分去实施是高成本的，高风险的。,

25、.,53,53,5.4 用例分析-用例的粒度,实例分析：为什么在系统用例分析阶段要把“增删改查”分出来呢？原因：系统用例的目的是为了将actor的业务用计算机模拟出来一般地，增、删、改、查对一个actor来说是不会同时发生的，(每次actor只会完成其中的一个行为）分开来的好处：1)有利于详细分析模拟行为的细节而不至于混淆;2)对WEB应用来说，数据的增删改查等，很容易形成“模板”。(增加用户用这个模板，增加其它基础数据可能也用同一个模板，无非是操作的数据（实体）不同而已。因此，在很多情况下，这些模板是可以复用的。),.,54,54,5.4 用例分析-用例的粒度,对这个例子来说，在系统用例阶段

26、，我们可以用“管理用户”include“增加用户”来表示这个实现关系，同时，让“增加用户”，“增加XX数据”等等用例来继承自一个抽象出来的“增加数据”用例，这样，可复用的模板体现在“增加数据”用例上，而具体业务，则体现在“增加XX数据”上。实际上，这也是一种OO思想的体现。,.,55,55,5.4 用例分析-用例业务建模之涉众,业务建模阶段的任务：发现和定义涉众 画定业务边界 获取用例 绘制用例场景图 绘制业务实体模型（领域模型）编制词汇表。,.,56,56,5.4 用例分析-用例业务建模之涉众,实例-网上图书借阅系统，初步接触，业务负责人描述：我们原本是一个传统的图书馆，传统的借书方式要求读

27、者亲自来到图书馆，这显得非常不方便。想借助网络，让读者通过网络借/还书，这样可以可以方便的检索目录，让读者可以足不出户借到需要的书。,.,57,57,5.4 用例分析-用例业务建模之涉众,我们已经基本上了解了系统目标。可能有些系统分析员已经准备开始着手询问借书的流程，借阅人的资格认证问题了，甚至有的人已经凭借多年的开发经验在脑海中绘制出了一幅网页，考虑如何实现这个系统了。请您千万不要着急往下走！因为我们得到的仅仅是一个由非计算机专业人员规划出的很粗略的构想，其可行性如何都尚未得到证实，在这样的基础下就开始细化，将来出现反复甚至失败的危险是很大的。,.,58,58,5.4 用例分析-用例业务建模

28、之涉众,了解系统目标后，系统分析员首先要做不是去了解业务的细节，而是发现与这个目标相关的人和物。英文称为Stakeholder或Business Actor，有称干系人、涉众。涉众不等于用户，涉众是与要建设的业务系统相关的一切人和事。,.,59,59,5.4 用例分析-用例业务建模之涉众,业主系统建设的出资方，投资者，它不一定是业务方。（比如可以假设这个图书馆的网络化建设是由一家国际风险投资机构投资的，它本身并不管理图书馆，它只是从资本上拥有这个系统并从借书收入中获得回报。）业主的钱是这个项目存在的原因。若系统不符合业主的期望，撤回投资，那么再好的愿望也是空的 业主关心的是建设成本，建设周期以

29、及建成后的效益。（建设成本、建设周期将直接影响到你可以采用的技术，可以选用的软件架构，可以承受的系统范围。）,.,60,60,5.4 用例分析-用例业务建模之涉众,业务提出者业务规则的制定者（业务方的高层人物，如CEO，高级经理等）。他们制定业务规则，圈定业务范围，规划业务目标。系统建设是业务提出者经营和管理意志的体现。业务提出者的期望一般比较原则化和粗略化，但却不能违反和误解。业务提出者最关心系统建设能够带来的社会影响，效率改进和成本节约。在系统建设过程的沟通中，他们的意志一般是极少妥协的。,.,61,61,5.4 用例分析-用例业务建模之涉众,业务管理者实际管理和监督业务执行的人员（中层干

30、部），将业务提出者的意志付诸实施，并监督底层员工工作的作用。是系统的主要用户之一他们关心系统将如何实现他们的管理职能，如何能方便的得知业务执行的结果，他们如何将指令下达，以及如何得到反馈业务管理者的期望相对比较细节，是需求调研过程中最重要的信息来源。是系统分析员最需要下功夫的系统分析员必须要把业务管理者的思路、想法弄清楚，业务建模的结果也必须与业务管理者达成一致在系统建设过程中，业务管理者的期望可以有所妥协，一个经验丰富的系统分析员可以给他们灌输合理的管理方式，提供可替代的管理方法（以规避导致高技术风险或高成本风险的不合理要求）,.,62,62,5.4 用例分析-用例业务建模之涉众,业务执行者

31、底层的操作人员，是与将来的计算机直接交互最多的人员他们最关心系统会给他们带来什么样的方便，会怎样的改变他们的工作模式他们的需求最细节，系统的可用性，友好性，运行效率与他们关系最多。系统界面风格，操作方式，数据展现方式，录入方式，业务细节都需要从他们这里了解他们将成为系统是否成功的试金石。Look and Feel，表单细节等是系统分析员与他们调研时需要多下功夫的地方这类人员的期望灵活性最大，也最容易说服和妥协同时，他们的期望又往往是不统一的，各种古怪的要求都有系统分析员需从各种期望中找出普遍意义，解决多数人的问题,.,63,63,5.4 用例分析-用例业务建模之涉众,第三方与这项业务而关联的非

32、业务方的其他人或事（比如，借阅人借书时需要交费，若交费是通过网上银行支付的，则网上银行就成为了网上借书系统的一个涉众）第三方的期望对系统来说不起决定性意义，但会起到限制作用（最终在系统中，这种期望将体现为标准、协议和接口）另一种第三方是项目监理，系统分析员也必须弄清楚监理的期望,.,64,64,5.4 用例分析-用例业务建模之涉众,相关的法律法规国家和地方法律法规（例如，借阅系统要建立借阅人档案，就必须保障借阅人的隐私权；要与网上银行交易，必须遵守信息安全法等。）必须得遵守一些行业规范和标准（例如，网上借阅需要遵守HTML规范，借阅者才能正常浏览网页）,.,65,65,5.4 用例分析-用例业

33、务建模之涉众,用户预期的系统使用者。用户可能包括上述的任何一种涉众用户涉众模型建立的意义是：每个用户将来都可能是系统中的某个角色，是实实在在参与系统的，需要编程实现相应的系统功能上述的其它涉众，则有可能只是在需求阶段有用，最终并不与系统发生交互在建模过程中，概念模型的建立和系统模型的建立都只从用户开始分析，而不再理会其它的涉众。（其它涉众体现在文档中即可）,.,66,66,5.4 用例分析-用例业务建模之涉众,业主业务提出者业务管理者业务管理者第三方相关的法律法规用户,.,67,67,5.4 用例分析-业务建模一般步骤和方法,本方法并非唯一正确，仅供参考Step1 从涉众中找出参与者，定义这些

34、参与者之间的关系Step2 找出每个参与者要做的事，即业务用例 1）注意用例的粒度 2）建议为每个business actor绘制一个业务用例图，这能很好的体现以人为中心的分析模式，并且不容易漏掉business actor需要做的事。至于以参与者为中心的视图容易漏掉某个业务用例的担心，可以在第3、4步中得到消除Step3 利用业务场景图帮助分析业务流程 1）本阶段最好使用活动图Activity diagram 2）绘制时要采用Step1定义的参与者名作为泳道名，用Step2定义的业务用例名作为活动名。（若无法完备地描绘业务流程，那么一定是前面的定义有问题）（若不是所有actor 和use c

35、ase 都被用到，则应该检查业务流程有无遗漏，或是否有无用的actor 和 use case）,.,68,68,5.4 用例分析-业务建模一般步骤和方法,Step4 绘制用例场景图（用活动图）。1)与业务场景图不同，用例场景图只针对某用例绘制其执行过程 2)使用Step1定义的参与者作为泳道名。(能助你发现在定义业务用例图时的错误)3)步骤简单的业务用例是不必绘制场景图，只需要写用例规约Step5 从Step3或Step4中绘制的活动图中找到每一步活动将使用到的事物或产生的结果。（这是找到物的过程。）找到后，应当建立这些物之间的关系（业务实体模型）。Step6 上述过程中，随时补充词汇表Glo

36、ssary。将此过程中的所有业务词汇、专业词汇等一切在建模过程中使用到的需要解释的名词。（为模型建立人与读者就模型达成一致理解提供保证）。,.,69,69,5.4 用例分析-业务建模一般步骤和方法,Step7 根据涉众(利益相关者)的期望审视模型，确定业务范围（决定哪些业务用例在系统范围内）去除的业务用例有两种情况：1、该业务用例是被调用一方，应改为 boundary 类型，意味着将来它是一个外部接口。2、该业务用例主动调用系统内业务用例，应改为business actor类型。（由业务用例转换而成的business actor不是人，而通常是一个外部系统进程，因此应该在被调用的系统内业务用例

37、与它之间增加一个boundary元素，意味着我们的系统将为这样一个外部进程提供一个接口）说明：上述的7个步骤并非一次性完成的，在每一个步骤中都可能导致对以前步骤的调整。即使建模已经完成，当遇到变化或发现新问题时，上述步骤应当从头到再执行一次。这也是RUP倡导的迭代开发模式。,.,70,70,5.4 用例分析-用户、业务用例和业务场景,回头看看需吧，图书馆主任是这么说的：我们原本是传统的图书馆，要求读者亲自来到图书馆，这显得非常不方便，而且随着藏书的增加和读者群的增长，尤其而且大量的读者到图书馆，使得图书馆的场地不足，工作人员也不够了。想借助网络，让读者通过网络借/还书，这样可以省掉大量的场地维

38、护和工作人员成本支出，同时计算机可以方便的检索目录，让读者可以足不出户借到需要的书。为了把书送到借阅人手里，我们已经联系了A特快专递公司和B物流公司，由他们往返借阅人和图书馆之间把图书送出和收回。读者在网上出示和验证借书卡，找到需要的书，提交申请，图书管理员确认后，就会通知物流公司来取书，当读者拿到书之后，物流公司需要把读者的签单拿回来以证明读者已经拿到了书。当然这个过程读者是需要付费的。还书也是基本同样的过程。,.,71,71,5.4 用例分析-用户、业务用例和业务场景,1、找出参与者（业务用户，并非将来系统中的“角色”）,.,72,72,5.4 用例分析-用户、业务用例和业务场景,2、找出

39、每个参与者要做的事，即业务用例。业务用例来自于系统分析员对上一步中所有参与者的访谈、总结和归纳。建议从每个参与者的角度以及从每项业务的角度来绘制业务用例图,这个视图的意义：调研对象一眼就能看出来，这个模型是否已经涵盖了他所有需要做的事。,.,73,73,5.4 用例分析-用户、业务用例和业务场景,业务视角：从业务的视角查看每项业务是由哪些用例和哪些角色参与完成的。,意义：需求研讨会上，业务专家可以一眼看出这个模型是否已经能够完整的表达业务,.,74,74,5.4 用例分析-用户、业务用例和业务场景,3、针对每项业务视图绘制业务场景图，用活动图详细描述这些参与者、用例是如何交互来完成这项业务的。

40、,借阅图书业务过程,.,75,75,5.4 用例分析-用户、业务用例和业务场景,注：业务场景图可能不止一个。（同样一项业务，会有很多种不同的业务实现方式，例如借阅图书业务，就有可能第一次借书，又还书又借书，VIP客户借书，借书时借证已经到期.等等许多种场景）对于上述场景，每一个都不能漏掉或省略（至少必须在文档中体现出来），除非已经很明确这个业务场景不包括在系统范围之内这些业务场景图的意义：它已经绘制出了一份系统蓝图（将来的系统建设很大程度将依据此场景图进行）,.,76,76,5.4 用例分析-用户、业务用例和业务场景,经过上面的三个步骤，已经形成了基本的需求框架，并圈定了业务范围得到这三个成果后，暂停调研，通过评审会，研讨会等形式充分论证这些成果的正确性和完备性。求得业务专家、用户代表、开发方、项目经理等各方的一致认可，将其作为第一份基线一般不要在这个基线形成之前深入细化需求，因为需求过程，或说用例过程是一个自顶向向下的过程，（如果上一步没有形成基线就进行下一步，）,.,77,5.5 小节,方法包括结构化分析面向对象的分析方法基于用例的RUP需求分析方法,.,78,78,作业：,对自选项目进行需求分析，给出相应的用例模型,谢谢观看！,