搜索
第3章用例图目录3.1需求技术3.2RUP开发过程3.3用例图的概念3.4用例图的表示3.5参与者之间的关系目录3.6用例之间的关系3.7参与者与用例之间的关系3.8阅读用例图3.9用例图应用3.10建模要点第3章用例图•用例图是外部参与者所能观察到的系统功能的模型图，该图呈现了一些参与者和一些用例，以及它们之间的关系，主要用于对系统、子系统或类的功能行为进行建模。3.1需求技术•获取软件的需求是软件开发过程的重要难题，在当今的软件需求的实践中，RUP过程中的用例技术、XP中的用户故事（UserStory）技术、FDD的Feature描述技术是获取需求的最佳技术，这三个技术的共同点是：站在用户的角度看待系统、定义系统；使用用户能够看懂的语言来描述系统，定义系统．三种需求技术的特点见表3-1所示。需求技术种类描述用例(Usecase)描绘一个系统外在可见的需求情况，是代表系统中各个项目相关人员(风险承担人，Stakeholder)之间就系统的行为所达成的契约用户故事(userstory)由客户参与编写，说明他们需要系统为他们做什么，一般用客户的术语编写，其长度约为三句话左右需求特性(Feature)就是一个小的，具有客户价值的功能，通常表示为actionresultobject表3-13种获取需求的技术3.2RUP开发过程•RUP开发过程是“用例驱动”的开发过程，在RUP开发过程中，开发人员首先捕获客户的需求，并以用例的形式组织成用例模型；然后对需求模型进行分析、整理、验证，建立分析模型；最后以分析模型为基础，设计系统，来满足这些用例模型的要求。因此，软件的整个开发过程，就是建立模型的过程，从建立用例模型开始，其次是分析模型，接着是设计模型和实现模型，在建立了这些模型之后，还将根据用例模型设计出测试模型来对系统进行验证。•所有模型的建立过程不是线性转变的，而是是一个迭代、增量的开发过程。也就是在整个项目开发周期中，将会多次经过这五个模型的迭代、修改、删除、优化、精化的过程。•下面是对5个模型的定义：•1.用例模型：能够有效地帮助开发人员发现真正的功能需求，并用UML设计语言来描述需求，如，用例图。3.2RUP开发过程•2.分析模型：通过协作图来描述用例，检验、验证用例的一致性、正确性、完备性、可行性。分析的结果表示为类图、包图。•3.设计模型：在分析模型的基础上，把分析阶段的类分解为语言能实现的软件类，利用各种实现技术构造系统、子系统；并把设计类进行分组，打包、定义子系统和类的接口。这一阶段的产品有：（类图、对象图、包图、构件图）•4.部署模型：定义可计算节点系统的物理结构，并验证运行在这些节点上的构件想法是否实现了用例。（构件图、部署图）•5.测试模型：根据用例中所描述的功能来构建测试模型。•采用用例技术的优点有2点：一是，用例表达了用户对软件的目标要求，用例是系统向其用户提供的增值功能。二是，用例很直观，用户和客户根本无法了解复杂符号，而用例这种简单、自然的表述法可以使其易于阅读，并提出修改意见。3.3用例图的概念•1.用例图•用例图是描述用例、参与者及其关系的图。与所有UML的其它图一样，用例图可以包括注释、约束。图3-1是棋牌管理系统对应的用例图。•图中的元素包括：参与者、用例、一个方框和一些表示关系的连接线，所有的用例都位于方框之内，该方框称为“系统边界”。方框内是棋牌管理系统的多个用例，方框外是外部参与者。图3-1棋牌管理系统的用例图3.3用例图的概念•2.用例图的作用•用例图展示了用例之间以及用例与参与者之间是怎样相互联系的。用例图对系统、子系统或类的行为进行了可视化，使用户能够理解如何使用这些元素，并使开发者能够实现这些元素。•用例图主要用来描述用户的功能需求。UML侧重从最终用户的角度来理解软件系统的需求，强调谁在使用系统、系统可以完成哪些功能。用例分析技术已经是一种公认有效的用户需求获取、分析和描述技术。•3.用例图的组成元素•用例图的组成元素包括用例、参与者、关系(用例间的关系，参与者之间的关系，参与者与用例之间的关系)。3.4用例图的表示•多个用例组成一个系统，参与者是系统外部的一个实体，它以某种方式与系统交互，请求系统执行用例，以获得参与者需要的价值。•在用例图中最为核心的两个元素是参与者（Actor）和用例（UseCase）。•3.4.1参与者的表示•参与者是为了完成某个任务，而与系统进行交互的实体。参与者是用户相对系统而言所扮演的角色。•1.参与者的表示•参与者有两种表示方法，如图3-2所示。图3-2参与者的两种表示法3.4.1参与者的表示•2.参与者分类•参与者不仅可以由人承担，还可以是其他系统、硬件设备，甚至是时钟。对参与者有两种分类方法：一种是按参与者本身的性质分，一种是按参与者的重要性来分。•（1）按参与者性质分•1）其它系统：当系统需要与其它系统交互时，如ATM柜员机系统中，银行后台系统就是一个参与者；2）硬件设备：如果系统需要与硬件设备交互时，如在开发IC卡门禁系统时，IC卡读写器就是一个参与者；3）时钟：当系统需要定时触发时，时钟就是参与者3.4.1参与者的表示•（2）按参与者重要性分：•与某个用例交互的参与者可能有多个，按参与者对用例的重要性分为以下两类：•1）主要参与者：从系统获得可度量价值的用户，他的需求驱动了用例所表示的行为或功能。•2）次要参与者：在系统中提供服务，并且不能脱离主要参与者而存在。3.4.2用例的表示•用例是对一组场景共同特征的抽象，即，用例是对一组场景共同行为的抽象，场景就是用例的一次完整的、具体的执行过程。用例与场景的关系，如同类与对象的关系，用例应该给参与者带来可见的价值。•１.场景•在系统中，按照某个顺序执行的一系列相关的动作后，实现了某种功能，把完成了这一功能的操作的集合称为场景。“场景”就是用户使用系统的一个实际的、特定的场面。•下面列举一个场景例子。•开发者与用户、客户进行交流，构建场景和用例规格描述。一个场景就是描述用户与系统之间的一系列交互活动，描述了系统一次具体执行的行为路径，即，一次完整的事件流。如，小刘通过银行柜圆机(ATM系统)取款3000元的场景，如图3-3所示。3.4.2用例的表示场景名称取款3000元参与者客户小刘事件流（1）小刘将银行卡插入柜员机。（2）柜员机要求客户输入卡密码。（3）小刘输入卡密码，并确认密码。（4）柜员机屏幕提示，请客户选择服务类型。（5）小刘选择取款服务。（3）柜员机提示：请客户输入取款数目。（7）客户输入3000，并确认。（8）柜员机出钱口输出30张一佰元的人民币。（9）小刘取回30张100元面额的人民币。（10）柜员机提示服务类型：确认、或继续，或退卡。（11）小刘选择服务类型退卡，结束服务。图3-3小刘取款场景3.4.2用例的表示•开发者获取需求的步骤是：第一步，开发者首先将用户的工作流程表示为场景，然后，将同一类场景抽象为用例，以描述系统的功能；第二步，客户和用户通过审查场景，并测试开发者提供的原型系统，以验证和确认需求规格说明书。第三步，当系统需求定义成熟和稳定后，开发者和客户共同对需求规格说明进行确认，包括，系统的功能性需求、非功能需求、用例和场景在内的需求确认。•事件流：用例执行时动作的有序集合称为事件流。3.4.2用例的表示•2．用例的表示•每个用例都有一个名字，即，用例的名称，用例的名称有两种表示方法：•简单名：没有标识用例所属的包。•路径名：在用例名前标识了用例所属的包。图3-４用例的名称表示3.5.1识别参与者•需求获取的第一步是，标识参与者。这一服务定义了系统的边界，并从开发者要考虑的系统中，找出所有的观察点。开发者通过回答下面问题来寻找参与者：•系统支持哪些用户组完成他们的工作？•哪一个用户组执行系统的主要功能？•次要功能由哪一个用户组完成，比如维护或管理？•与该系统进行交互的外部硬件和软件系统是哪些？•在确定具体参与者时，可以通过以下一些常见的问题来帮助分析：谁使用这个系统、谁安装这个系统、谁启动这个系统、谁维护这个系统、谁关闭这个系统、哪些其他的系统使用这个系统、谁从这个系统获取信息、谁为这个系统提供信息。是否有事情自动在预计的时间发生（说明有定时器）、系统是否需要与外部实体交互以帮助自己完成任务。•一旦参与者被标识出来后，需求获取的下一步活动是，决定每一个参与者将访问的功能。3.5.2参与者之间的泛化关系•参与者之间的关系一般表现为特殊/一般化关系，即，泛化关系。泛化关系的表示如图3-5所示。图3-5参与者是泛化关系3.5.2参与者之间的泛化关系•对于参与者而言，泛化关系的引用可以有效地降低模型的复杂度。例如：在图3－1所示的用例图中，我们希望引入一个“迎宾员”的角色，并且为了缓解总台服务员的压力，希望让迎宾员也能完成“安排座位”的职责，那么就可以通过泛化来更有效地组织这个用例图。•图3－3表述了：总台服务员是一种“特殊”地迎宾员，它不仅可以安排座位，还能够办理结帐。图3-3参与者泛化3.3用例之间的关系•3.3.1识别用例•在需求分析时，当标识出了参与者以后，下一步就是识别用例，寻找用例最好的方法是，从参与者的角度看，参与者是如何使用系统的，通过回答以下问题，可以识别用例：•每个参与者希望系统提供什么功能？•系统是否存储和检索信息？如果是，由哪个参与者触发？•系统改变状态时，是否通知参与者？•哪些外部事件触发系统？•哪个参与者发出事件？•通过回答以上问题，得到一个候选用例列表。3.3.2标识用例间的关系•下面以一个“棋牌馆管理系统”的局部用例模型为例，说明用例之间的三种关系：包含关系、扩展关系、泛化关系•该系统的主要功能是：以Internet的形式向客户提供座位预订服务，如果暂时无法获取座位信息时，允许客户进入“等候队列“，当有人退订之后将及时通知客户。另外，该系统还将为总台服务员提供座位安排以及结帐的功能，要求能够支持现金和银行卡两种结帐方式。•在图3-１中可以看到4种元素：参与者、用例、一个方框和一些表示关系的连接线。前面已经介绍了参与者和用例的表示法，不难知道该图中有客户、总台服务员和银联POS系统3个参与者，还包括预订座位、安排座位、办理结帐等8个用例。3.3.2标识用例间的关系•1.系统边界•从图3-1中可以看到有一个方框，所有的用例都在这个方框内，而且它还有个名字：棋牌馆管理系统。在UML表示法中，这个方框称为”系统边界”，也叫做“系统范围”，他用来定义系统的界限，系统的用例都置于其中，参与者则置于边界之外。通过这个系统边界可以很清晰地标识出了系统的范围。•例如，图3-1中也明确地指出了该系统在处理银行卡结帐时将通过系统外的“银联POS系统”来完成，该系统是位于“棋牌馆管理系统”外的。因此，“银联POS系统”也是参与者。3.3.2标识用例间的关系•２．包含关系•在UML中，包含关系用构造型《include》表示，它是指基用例（baseusecase）在它内部的某一个位置上显式地合并了另一个用例的行为。•(1)包含用例的表示•包含是指一个用例被另一个用例使用，被使用的用例就是包含用例，使用包含用例的是基用例。•图3-7说明：查询、提款、转帐三个是基用例，它们都包含打印回执用例．基用例执行时必须执行包含用例，否则，基用例是不完整的，包含用例不是孤立存在的，它仅作为基用例的一部分出现．图中，包含关系的箭头是从基用例指向包含用例．•只有当某个事件流片断在多个用例中出现时，才将这个事件流片段抽取出来，放在一个单独的用例中，把这个用例用作包含用例。3.3.2标识用例间的关系•图3-7包含用例3.3.2标识用例间的关系•(2)基用例与包含用例事件流•例如在图3-1中，用例预定座位就包含了用例检查座位信息。可以设想，当客户预定座位时，必须知道座位的信息（是否有座位、有哪些空座位等），因此这两个用例的事件流执行顺序如图3-8所示。图3-8两个用例的事件流执行顺序3.3.2标识用例间的关系•3.扩展关系•(1)扩展用例的表示•在UML中，扩展关系用构造