需求分析与建模课件.ppt

《需求分析与建模课件.ppt》由会员分享，可在线阅读，更多相关《需求分析与建模课件.ppt（79页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。

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

2、必要性：需求分析的必要性：3.需求分析与建模需求分析与建模l需求分析与需求分析与软件分析件分析l结构化分析构化分析l面向面向对象的分析象的分析l需求用例求分析需求用例求分析4.5.2 结构化分析构化分析l结构化分析（SA）方法是一种面向过程的需求分析方法，主要对数据(流)进行分析，基本思想是将系统抽取出“数据”和“控制”两部分，再分别进行抽象和处理。l数据流图（DFD）、数据字典（DD）和流程图是结构化分析最常用的工具。l数据流图用来描述数据流从输入到输出的变换流程。l数据字典是关于数据的信息的集合，也就是对数据流图中包含的所有元素的定义的集合。5.5.2 结构化分析构化分析6.5.2 结构化

3、分析构化分析l结构化分析（SA）方法的特点简单高效适合需求分析非常清楚的系统7.需求分析与建模需求分析与建模l需求分析与软件分析l结构化分析l面向对象的分析l需求用例需求用例分析8.1面向面向对象象(Object Oriented,OO)Object Oriented,OO)的基本思想的基本思想l模模拟人人类认识和解决和解决问题的方式的方式遇到遇到问题认识个体个体对问题空空间（问题域）域）进行划分行划分归类找出每个找出每个类中的基本特征中的基本特征抽象抽象找出找出实现的解法（求解域）的解法（求解域）见“第第5章章补充充-面向面向对象的思想、方法和象的思想、方法和应用用”5.3 面向面向对象的分

4、析象的分析 -基本思想基本思想9.5.3 面向面向对象的分析象的分析 -基本思想基本思想面向面向对象的开象的开发方法可描述方法可描述为：（1）客）客观事物都是由事物都是由对象（象（object）组成的成的 对象是在客象是在客观事物基事物基础上抽象的上抽象的结果，任何复果，任何复杂的事物都可以通的事物都可以通过对象的某种象的某种组合构成。合构成。（2）对象由属性和方法象由属性和方法组成成 属性（属性（attribute）反映）反映对象的信息特征。如：象的信息特征。如：特点、特点、值、状、状态等。等。方法（方法（method）则用用 来定来定义改改变对象属性状象属性状态的各种操作方式。的各种操作方

5、式。(3)对象之象之间的的联系通系通过传递消息来消息来实现传递消息（消息（message）的方式是通）的方式是通过消息模式消息模式（message pattern）和方法所定）和方法所定义的操作的操作过程来完成程来完成的。的。(4)对象可按其属性象可按其属性进行行归类 类（class）有一定的）有一定的结构，构，类可以有超可以有超类（super class）这种种对象或象或类之之间的的层次次结构是靠构是靠继承关系承关系维系的系的。（5）对象是被封装的象是被封装的实体，体，类可以有子可以有子类(subclass)所所谓封装（封装（encapsulation），即指），即指严格的模格的模块化。化。

6、这种封装的种封装的对象象满足足软件工程的要求，而且可以直接被面件工程的要求，而且可以直接被面向向对象的程序象的程序设计语言所接受。言所接受。10.2结构化方法与构化方法与OOOO方法的比方法的比较l结构化方法依构化方法依赖基本的数据基本的数据结构，直接附加构，直接附加语义协议，处理信息理信息5.3 面向面向对象的分析象的分析 -比比比比较较11.2结构化方法与构化方法与OOOO方法的比方法的比较lOOOO方法利用数据方法利用数据结构的多重性，构的多重性，层层变换，最后，最后在最上在最上层附加附加语义协议5.3 面向面向对象的分析象的分析 -比比比比较较12.2OOOO方法与方法与结构化方法的比

7、构化方法的比较l结构化方法：基于构化方法：基于变换(输入入输出出)，数据与指令分开，数据与指令分开lOOOO方法：基于分解，数据与指令放在一起方法：基于分解，数据与指令放在一起l结构化方法从一开始就将系构化方法从一开始就将系统拆分成拆分成“数据数据”和和“控制控制”两部分，再分两部分，再分别进行抽象和行抽象和处理理lOOOO方法将任方法将任务分解分解为若干若干较小的子任小的子任务，最后才，最后才进行行“数数据据”和和“控制控制”的拆分的拆分l把功能与信息混合的的系把功能与信息混合的的系统“拆解拆解”为数据和控制，是系数据和控制，是系统分析与分析与设计过程中最大的程中最大的风险lOOOO方法将此

8、方法将此风险推后，在一系列小系推后，在一系列小系统上上“拆解拆解”，更，更为安全可靠安全可靠5.3 面向面向对象的分析象的分析 -比比比比较较13.l如果你的分析习惯是在调研需求时先弄清楚有多少业务流程，再画出业 务流程图，然后顺藤摸瓜，找出业务流程中每一步骤的参与部门或岗位，弄清楚在这一步参与者所做的事情和填写表单的结果，并关心用户是如何把这份表单传给到 下一个环节的。那么很不幸，你还在做面向过程的事情。l如果你的分析习惯是在调研需求时最先弄清楚有多少部门，多少岗位，然后找到每一个岗位的业务代表，问他们类似的问题：你平时都做什么？这件事是谁交办的？做完了你需要通知或传达给谁吗？做这件事情你都

9、需要填写些什么表格吗？.那么恭喜你，你已经OO啦！5.3 面向面向对象的分析象的分析 -比比比比较较闲话：今天你OO了吗？14.3、面向、面向对象技象技术的基本概念的基本概念:对象和象和实例例(object&instance)类(class)封装封装(encapsulation)继承承(inheritance)多多态(polymorphism)消息消息(message)5.3 面向对象的分析-基本概念基本概念15.l对象模型基本元素的象模型基本元素的标识1）类、属性、方法、属性、方法 类是具有相同属性和操作的是具有相同属性和操作的对象集合的象集合的总称。它是面向称。它是面向对象的一个基本概念，

10、象的一个基本概念，类封装了客封装了客观世界中世界中对象象实体的特征体的特征与行与行为，即，即属性属性与与方法方法。其表示法是一个矩形，由。其表示法是一个矩形，由带有有类名、名、属性和方法（操作）的分格框属性和方法（操作）的分格框组成。如下成。如下图所示。所示。5.3 面向对象的分析-基本概念基本概念16.l属性属性 属性属性是指是指类的特性，它的特性，它描述描述类所具有的一系列特性所具有的一系列特性值。一个。一个类可以有多个属性，可以有多个属性，也可以没有属性。在也可以没有属性。在类图中中属性只要写上名字就可以了。属性只要写上名字就可以了。如右上如右上图.也也可可以以在在属属性性名名后后跟跟上

11、上类型型甚甚至至缺缺省省取取值，如如右右下下图：5.3 面向对象的分析-基本概念基本概念17.l方法方法 方法方法是指是指类所能提供的服所能提供的服务或可或可执行行的操作。它表的操作。它表现类的的动态特征。特征。5.3 面向对象的分析-基本概念基本概念18.2）继承承 继承承，也称，也称泛化泛化，它是面，它是面向向对象描述象描述类之之间相似性的一相似性的一个重要机制。面向个重要机制。面向对象利用象利用继承来表达承来表达这种相似性，种相似性，这使得使得可以利用可以利用继承来管理承来管理类，同，同时也使得在定也使得在定义一个相似一个相似类时能能简化化类的定的定义工作。工作。5.3 面向对象的分析-

12、基本概念基本概念19.继承（泛化）关系5.3 面向对象的分析-基本概念基本概念20.3）超）超类、父、父类、子、子类 一个一个类可以可以继承其他承其他类的属性和方法。的属性和方法。继承了其它承了其它类属性属性和方法的和方法的类称称为子子类，被，被继承的承的类称称为父父类或或超超类。它。它们的关的关系如下系如下图所示。子所示。子类复用父复用父类属性和方法的属性和方法的过程，称程，称为继承承或或泛化泛化。没有父没有父类的的类被称被称为基基类或或根根类；没有子；没有子类的的类被称被称为叶叶类。如果一个如果一个类恰好只有一个父恰好只有一个父类，这样的的继承关系叫承关系叫单继承承。如果一个如果一个类有多

13、个父有多个父类，这样的的继承就是承就是多多继承承。5.3 面向对象的分析-基本概念基本概念21.4）抽象）抽象类 抽象抽象类（Abstract Class）是一种不能直接）是一种不能直接产生生实例的例的类，它的作，它的作用用仅仅是是为了其他的非了其他的非抽象抽象类继承和重用。承和重用。5.3 面向对象的分析-基本概念基本概念22.类“Window”包含有两个方法的名称包含有两个方法的名称“toFront()”和和“toBack()”，但，但是没有方法是没有方法实现。类“Window”本身不能有本身不能有实例，但它有两个特化的子例，但它有两个特化的子类“Windows Window”和和“Mac

14、 Window”，它，它们包含了方法包含了方法“toFront（）（）”和和“toBack（）（）”在不同平台上的在不同平台上的实现。在本例中，。在本例中，类“Window”的作用是作的作用是作为文本文本编辑器器类“Text Editor”的一个接口的一个接口。5.3 面向对象的分析-基本概念基本概念 此此图表示了抽象表示了抽象类的的应用。其中用。其中文本文本编辑器独立于平台，器独立于平台，为此定此定义了一个独立于平台的窗口了一个独立于平台的窗口对象象类“Window”，它是一个抽象，它是一个抽象类，在在类名名“Window”下下标有有约束束abstract。23.5）多）多态l多多态是指子是

15、指子类对象可以像父象可以像父类对象那象那样使用，同使用，同样的消息既可以的消息既可以发送送给父父类对象也可以象也可以发送送给子子类对象。象。l 即在即在类等等级的不同的不同层次中可以共享（公用）一个次中可以共享（公用）一个行行为（方法）的名字，不同（方法）的名字，不同层次中的每个次中的每个类各自各自按自己的需要来按自己的需要来实现这个行个行为。当。当对象接收到象接收到发送送给它的消息它的消息时，根据，根据该对象所属于的象所属于的类动态选用在用在该类中定中定义的的实现算法。算法。5.3 面向对象的分析-基本概念基本概念24.5）多）多态 在不同在不同类中具有相同名称的方法（操作）。中具有相同名称

16、的方法（操作）。5.3 面向对象的分析-基本概念基本概念25.l6）重）重载(Overloading)l 有两种重有两种重载：函数重函数重载指同一个函数名可以指同一个函数名可以对应着多个函数的着多个函数的实现，每种，每种实现对应着一个函数体，着一个函数体，这些函数的名字相同，但是函数的参数的些函数的名字相同，但是函数的参数的类型不同。型不同。运运算符重算符重载是指同一个操作符可以施加于不同的操作数。是指同一个操作符可以施加于不同的操作数。l 重重载进一步提高了面向一步提高了面向对象系象系统的灵活性和可的灵活性和可读性。性。5.3 面向对象的分析-基本概念基本概念26.7）依）依赖(depend

17、ency)依依赖是指是指一个一个类中的元素使用了另一个中的元素使用了另一个类。依依赖关系描述关系描述类之之间的的使用关系使用关系。5.3 面向对象的分析-基本概念基本概念27.8）关）关联 关关联（Association）是指是指对象象类之之间具有的具有的语义联系。其基本表示如下。系。其基本表示如下。应用于关用于关联的的4种修种修饰：关关联名名角色名角色名多重性多重性限定符与限定符与约束符束符5.3 面向对象的分析-基本概念基本概念28.9）聚合与）聚合与组合合 聚合（聚合（Aggregation）是一种描述是一种描述类之之间的整体与的整体与部分的部分的组成关系。成关系。5.3 面向对象的分析

18、-基本概念基本概念29.组合（合（Composition）是一种特殊的聚合，是一种特殊的聚合，它的每个部分体都是必它的每个部分体都是必须的。如下的。如下图所示。所示。5.3 面向对象的分析-基本概念基本概念30.10）类图类图表达了一表达了一组类和它和它们之之间的的联系。系。类图示意示意5.3 面向对象的分析-基本概念基本概念31.11）对象象 对象象是是类的具体的具体实例，即例，即类在某在某时刻的一个快刻的一个快照。照。5.3 面向对象的分析-基本概念基本概念32.类图示意示意11）对象象图 对象象图是是类图的一个的一个实例，它表例，它表示在某一示在某一时刻系刻系统对象的状象的状态、对象之象

19、之间的的联系状系状态。5.3 面向对象的分析-基本概念基本概念33.对象图示意5.3 面向对象的分析-基本概念基本概念34.12）消息）消息 消息消息是从一个是从一个对象（象（发送者）向另一个或几个其送者）向另一个或几个其他他对象（接收者）象（接收者）发送的信号，或由一个送的信号，或由一个对象（象（发送送者或者或调用者）用者）调用另一个用另一个对象（接收者）的操作。象（接收者）的操作。5.3 面向对象的分析-基本概念基本概念35.13）接口）接口(Interface)接口接口 是是一一组外部可外部可访问的操作方法的操作方法，它用于一个，它用于一个类为其他其他类提供服提供服务。接口可以看作。接口

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

21、软件分析l结构化分析l面向对象的分析l需求用例分析需求用例分析38.395.4 需求用例分析l需求用例分析需求用例分析（基于用例的需求分析）用例的概念用例的概念用例的粒度用例的粒度用例用例业务业务建模之涉众建模之涉众业务业务建模一般步建模一般步骤骤和方法和方法 用户、业务用例和业务场景 用例实现、用例场景和领域模型 用例规约的编写-业务规则和实体描述 编写UML需求规格说明书 39.5.4 用例分析-用例的概念用例的概念用例的概念用例的概念l l用例的定用例的定用例的定用例的定义义用例就是与使用者(actor)交互的，并且给使用者提供可观测的有意义的结果的一系列活动的集合。l l用例的特征用例

22、的特征用例的特征用例的特征1 1系列活系列活动是相是相对独立的独立的。这意味着它不需要与其它用例交互而独自完成参与者的目的。也就是说从“功能”上说是完备的。（有人可能会想到，用例之间不是也有关联关系吗？比如扩展/实现/包含。解释：用例间关系是分析过程的产物，而且这种关系一般的产生在概念层用例阶段和系统层用例阶段。对于业务用例，独立性特征是很明显的。）比如在ATM取钱的场景中：取钱，读卡，验证账号，打印回执单等都是可能的用例40.5.4 用例分析-用例的概念用例的概念用例的概念用例的概念l l用例的特征用例的特征用例的特征用例的特征2 2执行行结果果对参与者来参与者来说是可是可观测的和有意的和有

23、意义的的。（例如，系统会监控参与者在系统里的操作，并在参与者删除数据之前备份。虽然它是系统的一个必需组成部分，但它在需求阶段却不应该 作为用例出现。因为这是一个后台进程，对参与者来说是不可观测的，它应该在系统用例分析阶段定义。）（又比如说，登录系统是一个有效的用例，但输入密码却不是。这是因为登录系统对参与者是有意义的，这样他可以获得身份认证和授权，但输入密码却是没有意义的，输入完了呢？有什么结果吗？）41.5.4 用例分析-用例的概念用例的概念用例的概念用例的概念l l用例的特征用例的特征用例的特征用例的特征3 3用例必用例必须由一个参与者由一个参与者发起起。不存在没有参与者的用例，用例不应该

24、自动启动，也不应该主动启动另一个用例。用例总是由一个参与者发起，并且满足特征2。例如从ATM 取钱是一个有效的用例，ATM吐钞却不是。(因为ATM是不会无缘无故吐钞的)。42.5.4 用例分析-用例的概念用例的概念用例的概念用例的概念l l用例的特征用例的特征用例的特征用例的特征4 4必然是以必然是以动宾短短语形式出形式出现的的。即，必须有一个动作和动作的受体。例如，喝水是一个有效的用例，而“喝”和“水”却不是。（虽然生活常识告诉我们，在没有水的情况下 人是不会做出喝这个动作的，水也必然是喝进去的，而不是滑进去的，但是笔者所见的很多用例中类似“计算”，“统计”，“报表”，“输出”，“录入”之类

25、的 并不在少数。）43.5.4 用例分析-用例的概念用例的概念用例的概念用例的概念l l用例的特征用例的特征用例的特征用例的特征5 5需求分析需求分析阶段用例以参与者段用例以参与者为中心中心（区别于以计算机 系统为中心），从参与者的角度来描述他要做的日常工作（区别于以业务流程描述的方式），并分析这些日常工作之间是如何交互的（区别于数据流的描述方式）。换句话说，用例分析的首要目标不是要弄清楚某项业务是如何一步一步完成的，而是要弄清楚有多少参与者？每个参与者都做什么？业务流程分析则是后续的工作 了。44.5.4 用例分析-用例的概念用例的概念用例的概念用例的概念用例就是功能的划分和描述，认为一个用

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

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

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

29、的，用例的粒度以能完成参与者目的为依据）48.495.4 用例分析-用例的粒度用例的粒度用例的粒度用例的粒度l上述粒度选择方法只是通常情况下的做法，并不是一个统一的标准l现实中，大型系统和小型系统的用例粒度选择会有较大差异。这种差异是为了适应不同的需求范围。（大型项目应选择大粒度，有助于把握需求范围，不容易遗漏。小项目应选择小粒度，避免需求模糊而易忽略细节）l一般来说，一个系统的业务用例定义在多于10个，少于50个之间l同一个需求阶段，所有用例的粒度应该是同一个量级的 49.505.4 用例分析-用例的粒度用例的粒度用例的粒度用例的粒度实例分析例分析：业务建模建模阶段，用例的粒度以每个用例能段

30、，用例的粒度以每个用例能够说明一件完整的事情明一件完整的事情为宜。即一个用例可以描述一宜。即一个用例可以描述一项完整的完整的业务流程流程在系在系统建模建模阶段，用例段，用例视角是角是针对计算机的，因此用例的粒度以算机的，因此用例的粒度以一个用例能一个用例能够描述操作者与描述操作者与计算机的一次完整交互算机的一次完整交互为宜宜l一个普通的财务系统的用户管理，有增删改查l这里，把“用户管理”作为一个用例，还是把增删改查分别作为用例呢？（他们每一个都是一个完整的业务流程和一次完整交互，而且也都是一个actor发起的动作）50.515.4 用例分析-用例的粒度用例的粒度用例的粒度用例的粒度实例分析例分

31、析：l业务用例用例应以以“管理用管理用户”或或“维护用用户”作作为粒度，而粒度，而增、增、删、改、改、查则作作为系系统用例用例l理由：增删改查不能做为一个完整的业务来理解。（作为一个管理业务，数据只有先增，才会有改、删。增删改查结合起来才能完成actor的管理目的，只删或只增都不是业务的全部）。是否是一项完整业务，要看actor的目标，而不是事情是否完整。（此例中，actor的目标是为了增加一个用户？是为了删除一个用户？都不是，而是为了管理用户，这个目标包括了用户这个实体的整个生命周期）51.525.4 用例分析-用例的粒度用例的粒度用例的粒度用例的粒度实例分析例分析：l再讨论，如果业务要求还

32、有别的要求:权限升级，关系变更，.l那么，如果将每个都作为一个业务用例，很容易造成一个结果:这些原本与用户实体紧密关联、共同组成用户实体生命周期的业务，被割裂成多个独立的业务，因为定义了多个用例（请参看用例特征第一条）。l在RUP中，用例驱动的含义是:一个用例就是一个分析单元、设计单元、开发单元、测试单元甚至部署单元。l把紧密关联的业务分成多个独立部分去实施是高成本的，高风险的。52.535.4 用例分析-用例的粒度用例的粒度用例的粒度用例的粒度实例分析例分析：l为什么在系统用例分析阶段要把“增删改查”分出来呢？l原因：系统用例的目的是为了将actor的业务用计算机模拟出来一般地，增、删、改、

33、查对一个actor来说是不会同时发生的，(每次actor只会完成其中的一个行为）分开来的好处：1)有利于详细分析模拟行为的细节而不至于混淆;2)对WEB应用来说，数据的增删改查等，很容易形成“模板”。(增加用户用这个模板，增加其它基础数据可能也用同一个模板，无非是操作的数据（实体）不同而已。因此，在很多情况下，这些模板是可以复用的。)53.545.4 用例分析-用例的粒度用例的粒度用例的粒度用例的粒度l对这个例子来说，在系统用例阶段，我们可以用“管理用户”include“增加用户”来表示这个实现关系，同时，让“增加用户”，“增加XX数据”等等用例来继承自一个抽象出来的“增加数据”用例，这样，可

34、复用的模板体现在“增加数据”用例上，而具体业务，则体现在“增加XX数据”上。实际上，这也是一种OO思想的体现。54.555.4 用例分析用例分析-用例用例用例用例业务业务建模之涉众建模之涉众建模之涉众建模之涉众l业务建模阶段的任务：发现和定义涉众 画定业务边界 获取用例 绘制用例场景图 绘制业务实体模型（领域模型）编制词汇表。55.565.4 用例分析用例分析-用例用例用例用例业务业务建模之涉众建模之涉众建模之涉众建模之涉众l实例-网上图书借阅系统，初步接触，业务负责人描述：我们原本是一个传统的图书馆，传统的借书方式要求读者亲自来到图书馆，这显得非常不方便。想借助网络，让读者通过网络借/还书，

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

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

37、期望，撤回投资，那么再好的愿望也是空的 业主关心的是建设成本，建设周期以及建成后的效益。（建设成本、建设周期将直接影响到你可以采用的技术，可以选用的软件架构，可以承受的系统范围。）59.605.4 用例分析用例分析-用例用例用例用例业务业务建模之涉众建模之涉众建模之涉众建模之涉众l业务提出者提出者业务规则的制定者（业务方的高层人物，如CEO，高级经理等）。他们制定业务规则，圈定业务范围，规划业务目标。系统建设是业务提出者经营和管理意志的体现。业务提出者的期望一般比较原则化和粗略化，但却不能违反和误解。业务提出者最关心系统建设能够带来的社会影响，效率改进和成本节约。在系统建设过程的沟通中，他们的

38、意志一般是极少妥协的。60.615.4 用例分析用例分析-用例用例用例用例业务业务建模之涉众建模之涉众建模之涉众建模之涉众l业务管理者管理者实际管理和监督业务执行的人员（中层干部），将业务提出者的意志付诸实施，并监督底层员工工作的作用。是系统的主要用户之一他们关心系统将如何实现他们的管理职能，如何能方便的得知业务执行的结果，他们如何将指令下达，以及如何得到反馈业务管理者的期望相对比较细节，是需求调研过程中最重要的信息来源。是系统分析员最需要下功夫的系统分析员必须要把业务管理者的思路、想法弄清楚，业务建模的结果也必须与业务管理者达成一致在系统建设过程中，业务管理者的期望可以有所妥协，一个经验丰富

39、的系统分析员可以给他们灌输合理的管理方式，提供可替代的管理方法（以规避导致高技术风险或高成本风险的不合理要求）61.625.4 用例分析用例分析-用例用例用例用例业务业务建模之涉众建模之涉众建模之涉众建模之涉众l业务执行者行者底层的操作人员，是与将来的计算机直接交互最多的人员他们最关心系统会给他们带来什么样的方便，会怎样的改变他们的工作模式他们的需求最细节，系统的可用性，友好性，运行效率与他们关系最多。系统界面风格，操作方式，数据展现方式，录入方式，业务细节都需要从他们这里了解他们将成为系统是否成功的试金石。Look and Feel，表单细节等是系统分析员与他们调研时需要多下功夫的地方这类人

40、员的期望灵活性最大，也最容易说服和妥协同时，他们的期望又往往是不统一的，各种古怪的要求都有系统分析员需从各种期望中找出普遍意义，解决多数人的问题62.635.4 用例分析用例分析-用例用例用例用例业务业务建模之涉众建模之涉众建模之涉众建模之涉众l第三方第三方与这项业务而关联的非业务方的其他人或事（比如，借阅人借书时需要交费，若交费是通过网上银行支付的，则网上银行就成为了网上借书系统的一个涉众）第三方的期望对系统来说不起决定性意义，但会起到限制作用（最终在系统中，这种期望将体现为标准、协议和接口）另一种第三方是项目监理，系统分析员也必须弄清楚监理的期望 63.645.4 用例分析用例分析-用例用

41、例用例用例业务业务建模之涉众建模之涉众建模之涉众建模之涉众l相关的法律法相关的法律法规国家和地方法律法规（例如，借阅系统要建立借阅人档案，就必须保障借阅人的隐私权；要与网上银行交易，必须遵守信息安全法等。）必须得遵守一些行业规范和标准 （例如，网上借阅需要遵守HTML规范，借阅者才能正常浏览网页）64.655.4 用例分析用例分析-用例用例用例用例业务业务建模之涉众建模之涉众建模之涉众建模之涉众l用用户预期的系统使用者。用户可能包括上述的任何一种涉众用户涉众模型建立的意义是：每个用户将来都可能是系统中的某个角色，是实实在在参与系统的，需要编程实现相应的系统功能上述的其它涉众，则有可能只是在需求

42、阶段有用，最终并不与系统发生交互在建模过程中，概念模型的建立和系统模型的建立都只从用户开始分析，而不再理会其它的涉众。（其它涉众体现在文档中即可）65.665.4 用例分析用例分析-用例用例用例用例业务业务建模之涉众建模之涉众建模之涉众建模之涉众l业主主l业务提出者提出者l业务管理者管理者l业务管理者管理者l第三方第三方l相关的法律法相关的法律法规l用用户66.675.4 用例分析用例分析-业务业务建模一般步建模一般步建模一般步建模一般步骤骤和方法和方法和方法和方法l本方法并非唯一正确，本方法并非唯一正确，仅供参考供参考Step1 从涉众中找出参与者找出参与者，定定义这些参与者之之间的关系的关

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

44、有actor 和use case 都被用到，则应该检查业务流程有无遗漏，或是否有无用的actor 和 use case）67.685.4 用例分析用例分析-业务业务建模一般步建模一般步建模一般步建模一般步骤骤和方法和方法和方法和方法Step4 绘制用例制用例场景景图（用活动图）。1)与业务场景图不同，用例场景图只针对某用例绘制其执行过程 2)使用Step1定义的参与者作为泳道名。(能助你发现在定义业务用例图时的错误)3)步骤简单的业务用例是不必绘制场景图，只需要写用例规约Step5 从Step3或Step4中绘制的活动图中找到每一步活找到每一步活动将使用到的将使用到的事物或事物或产生的生的结果

45、果。（这是找到物的过程。）找到后，应当建立这些物之间的关系（业务实体模型）。Step6 上述过程中，随随时补充充词汇表表Glossary。将此过程中的所有业务词汇、专业词汇等一切在建模过程中使用到的需要解释的名词。（为模型建立人与读者就模型达成一致理解提供保证）。68.695.4 用例分析用例分析-业务业务建模一般步建模一般步建模一般步建模一般步骤骤和方法和方法和方法和方法Step7 根据涉众根据涉众(利益相关者)的期望期望审视模型，确定确定业务范范围（决定哪些业务用例在系统范围内）去除的业务用例有两种情况：1、该业务用例是被调用一方，应改为 boundary 类型，意味着将来它是一个外部接口

46、。2、该业务用例主动调用系统内业务用例，应改为business actor类型。（由业务用例转换而成的business actor不是人，而通常是一个外部系统进程，因此应该在被调用的系统内业务用例与它之间增加一个boundary元素，意味着我们的系统将为这样一个外部进程提供一个接口）说明：上述的上述的7个步个步骤并非一次性完成的并非一次性完成的，在每一个步骤中都可能导致对以前步骤的调整。即使建模已经完成，当遇到变化或发现新问题时，上述步骤应当从头到再执行一次。这也是RUP倡导的迭代开发模式。69.705.4 用例分析用例分析-用用用用户户、业务业务用例和用例和用例和用例和业务场业务场景景景景回

47、回头看看需吧，看看需吧，图书馆主任是主任是这么么说的：的：我我们原本是原本是传统的的图书馆，要求，要求读者者亲自来到自来到图书馆，这显得得非常不方便，而且随着藏非常不方便，而且随着藏书的增加和的增加和读者群的增者群的增长，尤其而且大量，尤其而且大量的的读者到者到图书馆，使得使得图书馆的的场地不足，工作人地不足，工作人员也不也不够了。了。想借助网想借助网络，让读者通者通过网网络借借/还书，这样可以省掉大量的可以省掉大量的场地地维护和工作人和工作人员成本支出，同成本支出，同时计算机可以方便的算机可以方便的检索目索目录，让读者可以足不出者可以足不出户借到需要的借到需要的书。为了把了把书送到借送到借阅

48、人手里，我人手里，我们已已经联系了系了A特快特快专递公司和公司和B物流公司，由他物流公司，由他们往返借往返借阅人和人和图书馆之之间把把图书送出和收回。送出和收回。读者在网上出示和者在网上出示和验证借借书卡，找到需要的卡，找到需要的书，提交申，提交申请，图书管理管理员确确认后，就会通知物流公司来取后，就会通知物流公司来取书，当，当读者拿到者拿到书之后，之后，物流公司需要把物流公司需要把读者的者的签单拿回来以拿回来以证明明读者已者已经拿到了拿到了书。当然。当然这个个过程程读者是需要付者是需要付费的。的。还书也是基本同也是基本同样的的过程。程。70.715.4 用例分析用例分析-用用用用户户、业务业

49、务用例和用例和用例和用例和业务场业务场景景景景l1、找出参与者、找出参与者（业务用用户，并非将来系，并非将来系统中的中的“角色角色”）71.725.4 用例分析用例分析-用用用用户户、业务业务用例和用例和用例和用例和业务场业务场景景景景l2、找出每个参与者要做的事，即、找出每个参与者要做的事，即业务用例。用例。业务用例来自于系用例来自于系统分析分析员对上一步中所有参与者的上一步中所有参与者的访谈、总结和和归纳。建。建议从每个从每个参与者的角度以及从每参与者的角度以及从每项业务的角度来的角度来绘制制业务用例用例图 这个视图的意义：调研对象一眼就能看出来，这个模型是否已经涵盖了他所有需要做的事。7

50、2.735.4 用例分析用例分析-用用用用户户、业务业务用例和用例和用例和用例和业务场业务场景景景景l业务视角：角：从业务的视角查看每项业务是由哪些用例和哪些角色参与完成的。意义：需求研讨会上，业务专家可以一眼看出这个模型是否已经能够完整的表达业务73.745.4 用例分析用例分析-用用用用户户、业务业务用例和用例和用例和用例和业务场业务场景景景景l3、针对每每项业务视图绘制制业务场景景图，用活，用活动图详细描描述述这些参与者、用例是如何交互来完成些参与者、用例是如何交互来完成这项业务的。的。借阅图书业务过程74.755.4 用例分析用例分析-用用用用户户、业务业务用例和用例和用例和用例和业务