1、.1 1l需求分析需求分析必要性必要性l结构化分析结构化分析l面向对象分析面向对象分析l需求用例分析需求用例分析.2 2 神父之牛的故事神父之牛的故事l有个神父在教堂为一个人忏悔。l那人说：“神父，我偷了别人一头牛，我该怎么办？我把牛给你好不好？”l神父回答：“我不要。你应该把那头牛送还给失主才对。”l那人说：“但是他说他不要。”l神父说：“那你就自己收下吧。”l结果，当天晚上神父回到家后，发觉他的牛不见了。需求分析的必要性：需求分析的必要性：.3 3l 95 折 = 95%l 9 折 = 9% ? (9 折 = 90% )需求分析的必要性：需求分析的必要性：.4l需求分析与软件分析需求分析与
2、软件分析l结构化分析结构化分析l面向对象的分析面向对象的分析l需求用例求分析需求用例求分析.5l结构化分析（SA）方法是一种面向过程的需求分析方法，主要对数据 (流) 进行分析，基本思想是将系统抽取出“数据”和“控制”两部分，再分别进行抽象和处理。 l数据流图（DFD）、数据字典（DD）和流程图是结构化分析最常用的工具。l数据流图用来描述数据流从输入到输出的变换流程。l数据字典是关于数据的信息的集合，也就是对数据流图中包含的所有元素的定义的集合。.6.7l结构化分析（SA）方法的特点简单高效适合需求分析非常清楚的系统.8l需求分析与软件分析l结构化分析l面向对象的分析l需求用例需求用例分析.9
3、1面向对象面向对象(Object Oriented,OO )Object Oriented,OO )的基本思想的基本思想l模拟人类认识和解决问题的方式模拟人类认识和解决问题的方式遇到问题遇到问题认识个体认识个体对问题空间（问题域）进行划分对问题空间（问题域）进行划分归类归类找出每个类中的基本特征找出每个类中的基本特征抽象抽象找出实现的解法（求解域）找出实现的解法（求解域）见见“第第5章补充章补充-面向对象的思想、方法和应用面向对象的思想、方法和应用”基本思想基本思想.10面向对象的开发方法可描述为：面向对象的开发方法可描述为： （1）客观事物都是由对象（）客观事物都是由对象（object）组成
4、的）组成的 对象是在客观事物基础上抽象的结果，任何复杂对象是在客观事物基础上抽象的结果，任何复杂的事物都可以通过对象的某种组合构成。的事物都可以通过对象的某种组合构成。 （2）对象由属性和方法组成）对象由属性和方法组成 属性（属性（attribute）反映对象的信息特征。如：）反映对象的信息特征。如：特点、值、状态等。特点、值、状态等。 方法（方法（method）则用）则用 来定义改来定义改变对象属性状态的各种操作方式。变对象属性状态的各种操作方式。(3) 对象之间的联系通过传递消息来实现对象之间的联系通过传递消息来实现传递消息（传递消息（message）的方式是通过消息模式）的方式是通过消息
5、模式（message pattern）和方法所定义的操作过程来完成）和方法所定义的操作过程来完成的。的。(4) 对象可按其属性进行归类对象可按其属性进行归类 类（类（class）有一定的结构，类可以有超类（）有一定的结构，类可以有超类（super class）这种对象或类之间的层次结构是靠继承关系维）这种对象或类之间的层次结构是靠继承关系维系的系的。 （5）对象是被封装的实体，类可以有子类）对象是被封装的实体，类可以有子类(subclass) 所谓封装（所谓封装（encapsulation），即指严格的模块化。），即指严格的模块化。这种封装的对象满足软件工程的要求，而且可以直接被这种封装的对象
6、满足软件工程的要求，而且可以直接被面向对象的程序设计语言所接受。面向对象的程序设计语言所接受。.112结构化方法与结构化方法与OOOO方法的比较方法的比较l结构化方法依赖基本的数据结构，直接附加语义结构化方法依赖基本的数据结构，直接附加语义协议，处理信息协议，处理信息.122结构化方法与结构化方法与OOOO方法的比较方法的比较lOOOO方法利用数据结构的多重性，层层变换，最后方法利用数据结构的多重性，层层变换，最后在最上层附加语义协议在最上层附加语义协议.132OOOO方法与结构化方法的比较方法与结构化方法的比较l结构化方法：基于变换结构化方法：基于变换( (输入输入输出输出) )，数据与指令
7、分开，数据与指令分开lOOOO方法：基于分解，数据与指令放在一起方法：基于分解，数据与指令放在一起l结构化方法从一开始就将系统结构化方法从一开始就将系统拆分成拆分成“数据数据”和和“控制控制”两部分，再分别进行抽象和处理两部分，再分别进行抽象和处理lOOOO方法将任务分解为若干较小的子任务，最后才进行方法将任务分解为若干较小的子任务，最后才进行“数数据据”和和“控制控制”的拆分的拆分l把功能与信息混合的的系统把功能与信息混合的的系统“拆解拆解”为数据和控制，是系为数据和控制，是系统分析与设计过程中最大的风险统分析与设计过程中最大的风险lOOOO方法将此风险推后，在一系列小系统上方法将此风险推后
8、，在一系列小系统上“拆解拆解”，更为，更为安全可靠安全可靠.14l如果你的分析习惯是在调研需求时先弄清楚有多少业务流程，再画出业 务流程图，然后顺藤摸瓜，找出业务流程中每一步骤的参与部门或岗位，弄清楚在这一步参与者所做的事情和填写表单的结果，并关心用户是如何把这份表单传给到 下一个环节的。那么很不幸，你还在做面向过程的事情。l如果你的分析习惯是在调研需求时最先弄清楚有多少部门，多少岗位，然后找到每一个岗位的业务代表，问他们类似的问题：你平时都做什么？这件事是谁交办的？做完了你需要通知或传达给谁吗？做这件事情你都需要填写些什么表格吗？.那么恭喜你，你已经OO啦！闲话：今天你OO了吗？.153、面
9、向对象技术的基本概念、面向对象技术的基本概念:对象和实例对象和实例(object&instance)类类(class)封装封装(encapsulation)继承继承(inheritance)多态多态(polymorphism)消息消息(message)基本概念基本概念.16l对象模型基本元素的标识对象模型基本元素的标识1）类、属性、方法）类、属性、方法 类类是具有相同属性和操作的对象集合的总称。它是面向是具有相同属性和操作的对象集合的总称。它是面向对象的一个基本概念，类封装了客观世界中对象实体的特征对象的一个基本概念，类封装了客观世界中对象实体的特征与行为，即与行为，即属性属性与与方法方法。其
10、表示法是一个矩形，由带有类名、。其表示法是一个矩形，由带有类名、属性和方法（操作）的分格框组成。如下图所示。属性和方法（操作）的分格框组成。如下图所示。基本概念基本概念.17l属性属性 属性属性是指类的特性，它是指类的特性，它描述类所具有的一系列特性描述类所具有的一系列特性值。一个类可以有多个属性，值。一个类可以有多个属性，也可以没有属性。在类图中也可以没有属性。在类图中属性只要写上名字就可以了。属性只要写上名字就可以了。如右上图如右上图. 也可以在属性名后跟上也可以在属性名后跟上类型甚至缺省取值，如右下类型甚至缺省取值，如右下图：图：基本概念基本概念.18l方法方法 方法方法是指类所能提供的
11、服务或可执行是指类所能提供的服务或可执行的操作。它表现类的动态特征。的操作。它表现类的动态特征。基本概念基本概念.192）继承）继承 继承继承，也称，也称泛化泛化，它是面，它是面向对象描述类之间相似性的一向对象描述类之间相似性的一个重要机制。面向对象利用继个重要机制。面向对象利用继承来表达这种相似性，这使得承来表达这种相似性，这使得可以利用继承来管理类，同时可以利用继承来管理类，同时也使得在定义一个相似类时能也使得在定义一个相似类时能简化类的定义工作。简化类的定义工作。基本概念基本概念.20继承（泛化）关系基本概念基本概念.213）超类、父类、子类）超类、父类、子类 一个类可以继承其他类的属性
12、和方法。继承了其它类属性一个类可以继承其他类的属性和方法。继承了其它类属性和方法的类称为和方法的类称为子类子类，被继承的类称为，被继承的类称为父类父类或或超类超类。它们的关。它们的关系如下图所示。子类复用父类属性和方法的过程，称为系如下图所示。子类复用父类属性和方法的过程，称为继承继承或或泛化泛化。 没有父类的类被称为没有父类的类被称为基类基类或或根类根类；没有子类的类被称为；没有子类的类被称为叶叶类类。 如果一个类恰好只有一个父类，这样的继承关系叫如果一个类恰好只有一个父类，这样的继承关系叫单继承单继承。如果一个类有多个父类，这样的继承就是如果一个类有多个父类，这样的继承就是多继承多继承。基
13、本概念基本概念.224）抽象类）抽象类 抽象类抽象类（Abstract Class）是一种不能直接）是一种不能直接产生实例的类，它的作产生实例的类，它的作用仅仅是为了其他的非用仅仅是为了其他的非抽象类继承和重用。抽象类继承和重用。基本概念基本概念.23 类类“Window”包含有两个方法的名称包含有两个方法的名称“toFront()”和和“toBack()”，但是没，但是没有方法实现。类有方法实现。类“Window”本身不能有实例，但它有两个特化的子类本身不能有实例，但它有两个特化的子类“Windows Window”和和“Mac Window”，它们包含了方法，它们包含了方法“ toFron
14、t（）（）”和和“toBack（）（）”在不同平台上的实现。在本例中，在不同平台上的实现。在本例中，类类“ Window”的作用是作为文本编辑器类的作用是作为文本编辑器类“ Text Editor”的一个接口的一个接口。基本概念基本概念 此图表示了抽象类的应用。其中此图表示了抽象类的应用。其中文本编辑器独立于平台，为此定文本编辑器独立于平台，为此定义了一个独立于平台的窗口对象义了一个独立于平台的窗口对象类类“Window”，它是一个抽象类，它是一个抽象类，在类名在类名“Window”下标有约束下标有约束abstract。.245）多态）多态l多态多态是指子类对象可以像父类对象那样使用，同是指子
15、类对象可以像父类对象那样使用，同样的消息既可以发送给父类对象也可以发送给子样的消息既可以发送给父类对象也可以发送给子类对象。类对象。l 即在类等级的不同层次中可以共享（公用）一个即在类等级的不同层次中可以共享（公用）一个行为（方法）的名字，不同层次中的每个类各自行为（方法）的名字，不同层次中的每个类各自按自己的需要来实现这个行为。当对象接收到发按自己的需要来实现这个行为。当对象接收到发送给它的消息时，根据该对象所属于的类动态选送给它的消息时，根据该对象所属于的类动态选用在该类中定义的实现算法。用在该类中定义的实现算法。 基本概念基本概念.255）多态）多态 在不同类中具有相同名称的方法（操作）
16、。在不同类中具有相同名称的方法（操作）。基本概念基本概念.26l6）重载）重载(Overloading) l 有两种重载：有两种重载：函数重载函数重载指同一个函数名可以对应指同一个函数名可以对应着多个函数的实现，每种实现对应着一个函数体，这着多个函数的实现，每种实现对应着一个函数体，这些函数的名字相同，但是函数的参数的类型不同。些函数的名字相同，但是函数的参数的类型不同。运运算符重载算符重载是指同一个操作符可以施加于不同的操作是指同一个操作符可以施加于不同的操作数。数。l 重载进一步提高了面向对象系统的灵活性和可重载进一步提高了面向对象系统的灵活性和可读性。读性。基本概念基本概念.277）依赖
17、）依赖(dependency) 依赖依赖是指是指一个类中的元素使用了另一个类一个类中的元素使用了另一个类。依赖关系描述类之间的依赖关系描述类之间的使用关系使用关系。基本概念基本概念.288）关联）关联 关联（关联（Association）是指对象类之间具有的是指对象类之间具有的语义联系。其基本表示如下。语义联系。其基本表示如下。应用于关联的应用于关联的4种修饰：种修饰：关联名关联名角色名角色名多重性多重性限定符与约束符限定符与约束符基本概念基本概念.299）聚合与组合）聚合与组合 聚合（聚合（Aggregation）是一种描述类之间的整体是一种描述类之间的整体与部分的组成关系。与部分的组成关系
18、。基本概念基本概念.30 组合（组合（Composition）是一种特殊的聚合，是一种特殊的聚合，它的每个部分体都是必须的。如下图所示。它的每个部分体都是必须的。如下图所示。基本概念基本概念.3110）类图）类图类图表达了一组类和它们之间的联系。类图表达了一组类和它们之间的联系。类图示意类图示意基本概念基本概念.3211）对象）对象 对象对象是类的具体实例，即类在某时刻的一个快是类的具体实例，即类在某时刻的一个快照。照。基本概念基本概念.33类图示意类图示意11）对象图）对象图 对象图对象图是类图是类图的一个实例，它表的一个实例，它表示在某一时刻系统对示在某一时刻系统对象的状态、对象之象的状态
19、、对象之间的联系状态。间的联系状态。基本概念基本概念.34对象图示意基本概念基本概念.3512）消息）消息 消息消息是从一个对象（发送者）向另一个或几个其是从一个对象（发送者）向另一个或几个其他对象（接收者）发送的信号，或由一个对象（发送他对象（接收者）发送的信号，或由一个对象（发送者或调用者）调用另一个对象（接收者）的操作。者或调用者）调用另一个对象（接收者）的操作。基本概念基本概念.3613）接口）接口(Interface) 接口接口 是是一组外部可访问的操作方法一组外部可访问的操作方法，它用于一，它用于一个类为其他类提供服务。接口可以看作为一种特殊的个类为其他类提供服务。接口可以看作为一
20、种特殊的抽象类，抽象类，它不含属性，只有方法它不含属性，只有方法。接口代表系统中的。接口代表系统中的接缝，接口两端的对象或组件可以独立变更，只要它接缝，接口两端的对象或组件可以独立变更，只要它们遵守和实现接口的规定，通过接口相联系即可。们遵守和实现接口的规定，通过接口相联系即可。基本概念基本概念.37l建立功能模型l建立对象模型l建立动态模型分析方法分析方法确定类与对象 确定结构与关联定义属性定义服务准备典型的交互行为的脚本提取事件，确定事件的动作及目标对象排列事件顺序，确定状态及状态间关系用例图描述.3838l需求分析与软件分析l结构化分析l面向对象的分析l需求用例分析需求用例分析.3939
21、l需求用例分析需求用例分析（基于用例的需求分析） 用户、业务用例和业务场景 用例实现、用例场景和领域模型 用例规约的编写-业务规则和实体描述 编写UML需求规格说明书 .40用例就是与使用者(actor)交互的，并且给使用者提供可观测的有意义的结果的一系列活动的集合。系列活动是相对独立的系列活动是相对独立的。这意味着它不需要与其它用例交互而独自完成参与者的目的。也就是说从“功能”上说是完备的。（有人可能会想到，用例之间不是也有关联关系吗？比如扩展/实现/包含。解释：用例间关系是分析过程的产物，而且这种关系一般的产生在概念层用例阶段和系统层用例阶段。对于业务用例，独立性特征是很明显的。）比如在A
22、TM取钱的场景中：取钱，读卡，验证账号，打印回执单等都是可能的用例.41执行结果对参与者来说是可观测的和有意义的执行结果对参与者来说是可观测的和有意义的。（例如，系统会监控参与者在系统里的操作，并在参与者删除数据之前备份。虽然它是系统的一个必需组成部分，但它在需求阶段却不应该 作为用例出现。因为这是一个后台进程，对参与者来说是不可观测的，它应该在系统用例分析阶段定义。）（又比如说，登录系统是一个有效的用例，但输入密码却不是。这是因为登录系统对参与者是有意义的，这样他可以获得身份认证和授权，但输入密码却是没有意义的，输入完了呢？有什么结果吗？ ）.42用例必须由一个参与者发起用例必须由一个参与者
23、发起。不存在没有参与者的用例，用例不应该自动启动，也不应该主动启动另一个用例。用例总是由一个参与者发起，并且满足特征2。例如从ATM 取钱是一个有效的用例，ATM吐钞却不是。(因为ATM是不会无缘无故吐钞的)。.43必然是以动宾短语形式出现的必然是以动宾短语形式出现的。即，必须有一个动作和动作的受体。例如，喝水是一个有效的用例，而“喝”和“水”却不是。（虽然生活常识告诉我们，在没有水的情况下 人是不会做出喝这个动作的，水也必然是喝进去的，而不是滑进去的，但是笔者所见的很多用例中类似“计算”，“统计”，“报表”，“输出”，“录入”之类的 并不在少数。）.44需求分析阶段用例以参与者为中心需求分析
24、阶段用例以参与者为中心（区别于以计算机 系统为中心），从参与者的角度来描述他要做的日常工作（区别于以业务流程描述的方式），并分析这些日常工作之间是如何交互的（区别于数据流的描述方式）。 换句话说，用例分析的首要目标不是要弄清楚某项业务是如何一步一步完成的，而是要弄清楚有多少参与者？每个参与者都做什么？业务流程分析则是后续的工作 了。.45用例就是功能的划分和描述，认为一个用例就是一个功能点错！.4646l比如学生管理系统中：成绩管理、成绩录入、成绩修改、成绩删除、成绩保存等都是可能的用例l成绩管理包含了后续的其它用例，成绩管理粒度更大一些，其它用例的粒度则要小一些l是一个大的用例合适，还是分解
25、成多个小用例合适呢？.4747l经验：根据阶段不同，使用不同的粒度。l在业务建模阶段，用例的粒度以每个用例能够说明一件完整的事情为宜。即一个用例可以描述一项完整的业务流程。这将有助于明确需求范围。例如取钱，报装电话，借书等表达完整业务的用例，而不要细到验证密码，填写申请单，查找书目等业务中的一个步骤。l在用例分析阶段，用例的的粒度以每个用例能描述一个完整的事件流为宜。可理解为一个用例描述一项完整业务中的一个步骤。需要注意的是，这个阶段需要采用OO方法，归纳，抽象业务用例中的概念模型。 例如，宽带业务需求中有申请报装，申请迁移地址用例，在用例分析时，可归纳和分解为提供申请资料、受理业务、现场安装
26、等多个业务流程中都会使用的概念用例。l在系统建模阶段，用例视角是针对计算机的，因此用例的粒度以一个用例能够描述操作者与计算机的一次完整交互为宜。例如，填写申请单、审核申请单、分配资源、派发任务单等。可理解为一个操作界面，或一个页面流。l在RUP中，项目计划要依据系统模型编写，因此另一个可参考的粒度是一个用例的开发工作量在一周左右为宜。报装电话申请资料受理业务现场安装填写申请单审核申请单分配资源派发任务单.4848l实际上，用例粒度的划分依据（尤其是业务用例）：用例的粒度是以该用例是否完成了参与者的某个目的粒度是以该用例是否完成了参与者的某个目的为依据。l例如：某人去图书馆，查询了书目，出示了借
27、书证，图书管理员查询了该人以前借阅记录以确保没有未归还的书，最后借到了书。l从这段话中能得出多少用例呢？l只有一个：借书。(其它都只是完成这个目的过程)，(这里讨论的是业务用例)。（用例分析是以参与者为中心的，用例的粒度以能完成参与者目的为依据）.4949l上述粒度选择方法只是通常情况下的做法，并不是一个统一的标准l现实中，大型系统和小型系统的用例粒度选择会有较大差异。这种差异是为了适应不同的需求范围。（大型项目应选择大粒度，有助于把握需求范围，不容易遗漏。小项目应选择小粒度，避免需求模糊而易忽略细节）l一般来说，一个系统的业务用例定义在多于10个，少于50个之间l同一个需求阶段，所有用例的粒
28、度应该是同一个量级的 .5050实例分析实例分析业务建模阶段，用例的粒度以每个用例能够说明一件完整的事情业务建模阶段，用例的粒度以每个用例能够说明一件完整的事情为宜。即一个用例可以描述一项完整的业务流程为宜。即一个用例可以描述一项完整的业务流程在系统建模阶段，用例视角是针对计算机的，因此用例的粒度以在系统建模阶段，用例视角是针对计算机的，因此用例的粒度以一个用例能够描述操作者与计算机的一次完整交互为宜一个用例能够描述操作者与计算机的一次完整交互为宜l一个普通的财务系统的用户管理，有增删改查l这里，把“用户管理”作为一个用例，还是把增删改查分别作为用例呢？（他们每一个都是一个完整的业务流程和一次
29、完整交互，而且也都是一个actor发起的动作）.5151实例分析实例分析l业务用例应以业务用例应以“管理用户管理用户”或或“维护用户维护用户”作为粒度，而作为粒度，而增、删、改、查则作为系统用例增、删、改、查则作为系统用例l理由： 增删改查不能做为一个完整的业务来理解。（作为一个管理业务，数据只有先增，才会有改、删。增删改查结合起来才能完成actor的管理目的，只删或只增都不是业务的全部）。 是否是一项完整业务，要看actor的目标，而不是事情是否完整。（此例中，actor的目标是为了增加一个用户？是为了删除一个用户？都不是，而是为了管理用户，这个目标包括了用户这个实体的整个生命周期）.525
30、2实例分析实例分析l再讨论，如果业务要求还有别的要求:权限升级，关系变更，. l那么，如果将每个都作为一个业务用例，很容易造成一个结果: 这些原本与用户实体紧密关联、共同组成用户实体生命周期的业务，被割裂成多个独立的业务，因为定义了多个用例（请参看用例特征第一条）。l在RUP中，用例驱动的含义是:一个用例就是一个分析单元、设计单元、开发单元、测试单元甚至部署单元。l把紧密关联的业务分成多个独立部分去实施是高成本的，高风险的。.5353实例分析实例分析l为什么在系统用例分析阶段要把“增删改查”分出来呢？l原因：系统用例的目的是为了将actor的业务用计算机模拟出来一般地，增、删、改、查对一个ac
31、tor来说是不会同时发生的，(每次actor只会完成其中的一个行为）分开来的好处： 1) 有利于详细分析模拟行为的细节而不至于混淆; 2) 对WEB应用来说，数据的增删改查等，很容易形成 “模板”。 (增加用户用这个模板，增加其它基础数据可能也用同一个模板，无非是操作的数据（实体）不同而已。因此，在很多情况下，这些模板是可以复用的。).5454l对这个例子来说，在系统用例阶段，我们可以用“管理用户” include “增加用户”来表示这个实现关系，同时，让“增加用户”，“增加XX数据”等等用例来继承自一个抽象出来的“增加数据”用例，这样，可复用的模板体现在 “增加数据”用例上，而具体业务，则体
32、现在“增加XX数据”上。实际上，这也是一种OO思想的体现。 .5555l业务建模阶段的任务： 发现和定义涉众 画定业务边界 获取用例 绘制用例场景图 绘制业务实体模型（领域模型） 编制词汇表。 .5656l实例-网上图书借阅系统，初步接触，业务负责人描述： 我们原本是一个传统的图书馆，传统的借书方式要求读者亲自来到图书馆，这显得非常不方便。 想借助网络，让读者通过网络借/还书，这样可以可以方便的检索目录，让读者可以足不出户借到需要的书。 .5757l我们已经基本上了解了系统目标。可能有些系统分析员已经准备开始着手询问借书的流程，借阅人的资格认证问题了，甚至有的人已经凭借多年的开发经验在脑海中绘
33、制出了一幅网页，考虑如何实现这个系统了。l请您千万不要着急往下走！因为我们得到的仅仅是一个由非计算机专业人员规划出的很粗略的构想，其可行性如何都尚未得到证实，在这样的基础下就开始细化，将来出现反复甚至失败的危险是很大的。 .5858l了解系统目标后，系统分析员首先要做不是去了解业务的细节，而是发现与这个目标相关的人和物。英文称为Stakeholder或Business Actor ，有称干系人、涉众。l涉众不等于用户，涉众是与要建设的业务系统相关的一切人和事。 .5959l业主业主系统建设的出资方，投资者，它不一定是业务方。（比如可以假设这个图书馆的网络化建设是由一家国际风险投资机构投资的，它
34、本身并不管理图书馆，它只是从资本上拥有这个系统并从借书收入中获得回报。） 业主的钱是这个项目存在的原因。若系统不符合业主的期望，撤回投资，那么再好的愿望也是空的 业主关心的是建设成本，建设周期以及建成后的效益。（建设成本、建设周期将直接影响到你可以采用的技术，可以选用的软件架构，可以承受的系统范围。）.6060l业务提出者业务提出者业务规则的制定者（业务方的高层人物，如CEO，高级经理等）。他们制定业务规则，圈定业务范围，规划业务目标。系统建设是业务提出者经营和管理意志的体现。业务提出者的期望一般比较原则化和粗略化，但却不能违反和误解。业务提出者最关心系统建设能够带来的社会影响，效率改进和成本
35、节约。在系统建设过程的沟通中，他们的意志一般是极少妥协的。.6161l业务管理者业务管理者实际管理和监督业务执行的人员（中层干部），将业务提出者的意志付诸实施，并监督底层员工工作的作用。是系统的主要用户之一他们关心系统将如何实现他们的管理职能，如何能方便的得知业务执行的结果，他们如何将指令下达，以及如何得到反馈业务管理者的期望相对比较细节，是需求调研过程中最重要的信息来源。是系统分析员最需要下功夫的系统分析员必须要把业务管理者的思路、想法弄清楚，业务建模的结果也必须与业务管理者达成一致在系统建设过程中，业务管理者的期望可以有所妥协，一个经验丰富的系统分析员可以给他们灌输合理的管理方式，提供可替
36、代的管理方法（以规避导致高技术风险或高成本风险的不合理要求） .6262l业务执行者业务执行者底层的操作人员，是与将来的计算机直接交互最多的人员他们最关心系统会给他们带来什么样的方便，会怎样的改变他们的工作模式他们的需求最细节，系统的可用性，友好性，运行效率与他们关系最多。系统界面风格，操作方式，数据展现方式，录入方式，业务细节都需要从他们这里了解他们将成为系统是否成功的试金石。Look and Feel ，表单细节等是系统分析员与他们调研时需要多下功夫的地方这类人员的期望灵活性最大，也最容易说服和妥协同时，他们的期望又往往是不统一的，各种古怪的要求都有系统分析员需从各种期望中找出普遍意义，解
37、决多数人的问题.6363l第三方第三方与这项业务而关联的非业务方的其他人或事 （比如，借阅人借书时需要交费，若交费是通过网上银行支付的，则网上银行就成为了网上借书系统的一个涉众） 第三方的期望对系统来说不起决定性意义，但会起到限制作用 （最终在系统中，这种期望将体现为标准、协议和接口） 另一种第三方是项目监理，系统分析员也必须弄清楚监理的期望 .6464l相关的法律法规相关的法律法规国家和地方法律法规（例如，借阅系统要建立借阅人档案，就必须保障借阅人的隐私权； 要与网上银行交易，必须遵守信息安全法等。） 必须得遵守一些行业规范和标准 （例如，网上借阅需要遵守HTML规范，借阅者才能正常浏览网页
38、） .6565l用户用户预期的系统使用者。用户可能包括上述的任何一种涉众用户涉众模型建立的意义是：每个用户将来都可能是系统中的某个角色，是实实在在参与系统的，需要编程实现相应的系统功能上述的其它涉众，则有可能只是在需求阶段有用，最终并不与系统发生交互在建模过程中，概念模型的建立和系统模型的建立都只从用户开始分析，而不再理会其它的涉众。（其它涉众体现在文档中即可）.6666l业主业主l业务提出者业务提出者l业务管理者业务管理者l业务管理者业务管理者l第三方第三方l相关的法律法规相关的法律法规l用户用户.6767l本方法并非唯一正确，仅供参考本方法并非唯一正确，仅供参考Step1 从涉众中找出参与
39、者找出参与者，定义定义这些参与者之间的关系之间的关系Step2 找出每个参与者要做的事找出每个参与者要做的事，即业务用例 1）注意用例的粒度 2）建议为每个business actor绘制一个业务用例图，这能很好的体现以人为中心的分析模式，并且不容易漏掉business actor需要做的事。至于以参与者为中心的视图容易漏掉某个业务用例的担心，可以在第3、4步中得到消除Step3 利用业务场景图帮助分析业务流程利用业务场景图帮助分析业务流程 1）本阶段最好使用活动图Activity diagram 2）绘制时要采用Step1定义的参与者名作为泳道名，用Step2定义的业务用例名作为活动名。（若
40、无法完备地描绘业务流程，那么一定是前面的定义有问题）（若不是所有actor 和use case 都被用到，则应该检查业务流程有无遗漏，或是否有无用的actor 和 use case ）.6868Step4 绘制用例场景图绘制用例场景图（用活动图）。 1) 与业务场景图不同，用例场景图只针对某用例绘制其执行过程 2) 使用Step1定义的参与者作为泳道名。(能助你发现在定义业务用例图时的错误) 3) 步骤简单的业务用例是不必绘制场景图，只需要写用例规约Step5 从Step3或Step4中绘制的活动图中找到每一步活动将使用到的找到每一步活动将使用到的事物或产生的结果事物或产生的结果。（这是找到物
41、的过程。）找到后，应当建立这些物之间的关系（业务实体模型）。Step6 上述过程中，随时补充词汇表随时补充词汇表Glossary。将此过程中的所有业务词汇、专业词汇等一切在建模过程中使用到的需要解释的名词。（为模型建立人与读者就模型达成一致理解提供保证）。.6969Step7 根据涉众根据涉众(利益相关者)的期望期望审视模型，确定业务范围确定业务范围（决定哪些业务用例在系统范围内） 去除的业务用例有两种情况： 1、该业务用例是被调用一方，应改为 boundary 类型，意味着将来它是一个外部接口。 2、该业务用例主动调用系统内业务用例，应改为business actor类型。（由业务用例转换而
42、成的business actor不是人，而通常是一个外部系统进程，因此应该在被调用的系统内业务用例与它之间增加一个boundary元素，意味着我们的系统将为这样一个外部进程提供一个接口）说明：上述的上述的7个步骤并非一次性完成的个步骤并非一次性完成的，在每一个步骤中都可能导致对以前步骤的调整。即使建模已经完成，当遇到变化或发现新问题时，上述步骤应当从头到再执行一次。这也是RUP倡导的迭代开发模式。.7070回头看看需吧，图书馆主任是这么说的：回头看看需吧，图书馆主任是这么说的： 我们原本是传统的图书馆，要求读者亲自来到图书馆，这显得我们原本是传统的图书馆，要求读者亲自来到图书馆，这显得非常不方
43、便，而且随着藏书的增加和读者群的增长，尤其而且大量非常不方便，而且随着藏书的增加和读者群的增长，尤其而且大量的读者到图书馆，的读者到图书馆， 使得图书馆的场地不足，工作人员也不够了。使得图书馆的场地不足，工作人员也不够了。 想借助网络，让读者通过网络借想借助网络，让读者通过网络借/还书，这样可以省掉大量的场还书，这样可以省掉大量的场地维护和工作人员成本支出，同时计算机可以方便的检索目录，让地维护和工作人员成本支出，同时计算机可以方便的检索目录，让读者可以足不出户借到需要的书。读者可以足不出户借到需要的书。 为了把书送到借阅人手里，我们已经联系了为了把书送到借阅人手里，我们已经联系了A特快专递公
44、司和特快专递公司和B物流公司，由他们往返借阅人和图书馆之间把图书送出和收回。物流公司，由他们往返借阅人和图书馆之间把图书送出和收回。 读者在网上出示和验证借书卡，找到需要的书，提交申请，图读者在网上出示和验证借书卡，找到需要的书，提交申请，图书管理员确认后，就会通知物流公司来取书，当读者拿到书之后，书管理员确认后，就会通知物流公司来取书，当读者拿到书之后，物流公司需要把读者的签单拿回来以证明读者已经拿到了书。当然物流公司需要把读者的签单拿回来以证明读者已经拿到了书。当然这个过程读者是需要付费的。这个过程读者是需要付费的。 还书也是基本同样的过程。还书也是基本同样的过程。.7171l1、找出参与
45、者、找出参与者（业务用户，并非将来系统中的（业务用户，并非将来系统中的“角色角色”）.7272l2、找出每个参与者要做的事，即业务用例。、找出每个参与者要做的事，即业务用例。业务用例来自于系统业务用例来自于系统分析员对上一步中所有参与者的访谈、总结和归纳。建议从每个分析员对上一步中所有参与者的访谈、总结和归纳。建议从每个参与者的角度以及从每项业务的角度来绘制业务用例图参与者的角度以及从每项业务的角度来绘制业务用例图 这个视图的意义：调研对象一眼就能看出来，这个模型是否已经涵盖了他所有需要做的事。.7373l业务视角：业务视角：从业务的视角查看每项业务是由哪些用例和哪些角色参与完成的。意义：需求
46、研讨会上，业务专家可以一眼看出这个模型是否已经能够完整的表达业务.7474l3、针对每项业务视图绘制业务场景图针对每项业务视图绘制业务场景图，用活动图详细描，用活动图详细描述这些参与者、用例是如何交互来完成这项业务的。述这些参与者、用例是如何交互来完成这项业务的。 借阅图书业务过程.7575l注：注：l业务场景图可能不止一个业务场景图可能不止一个。（同样一项业务，会有很多。（同样一项业务，会有很多种不同的业务实现方式，例如借阅图书业务，就有可能种不同的业务实现方式，例如借阅图书业务，就有可能第一次借书，又还书又借书，第一次借书，又还书又借书，VIP客户借书，借书时借客户借书，借书时借证已经到期
47、证已经到期.等等许多种场景）等等许多种场景）l对于上述场景，对于上述场景，每一个都不能漏掉或省略每一个都不能漏掉或省略（至少必须在（至少必须在文档中体现出来），除非已经很明确这个业务场景不包文档中体现出来），除非已经很明确这个业务场景不包括在系统范围之内括在系统范围之内l这些业务场景图的意义：它已经绘制出了一份系统蓝这些业务场景图的意义：它已经绘制出了一份系统蓝图（将来的系统建设很大程度将依据此场景图进行）图（将来的系统建设很大程度将依据此场景图进行）.7676l经过上面的三个步骤，已经形成了经过上面的三个步骤，已经形成了基本的需求框架基本的需求框架，并，并圈定了圈定了业务范围业务范围l得到这
48、三个成果后，暂停调研，通过得到这三个成果后，暂停调研，通过评审会评审会，研讨会等，研讨会等形式充分论证这些成果的正确性和完备性。求得业务专形式充分论证这些成果的正确性和完备性。求得业务专家、用户代表、开发方、项目经理等各方的一致认可，家、用户代表、开发方、项目经理等各方的一致认可，将其作为将其作为第一份基线第一份基线l一般一般不要在这个基线形成之前深入细化需求不要在这个基线形成之前深入细化需求，因为需求，因为需求过程，或说用例过程是一个自顶向向下的过程，（如果过程，或说用例过程是一个自顶向向下的过程，（如果上一步没有形成基线就进行下一步上一步没有形成基线就进行下一步 ，）.77l方法包括结构化分析l面向对象的分析方法l基于用例的基于用例的RUP需求分析方法需求分析方法.7878l对自选项目进行需求分析，给出相应的用例模型谢谢观看！
