第6章 用例图解析.ppt

第6章 用例图 目录 目录 第6章 用例图 　 用例图是外部参与者所能观察到的系统功能的模型图，该图呈现了一些参与者和一些用例，以及它们之间的关系，主要用于对系统、子系统或类的功能行为进行建模。 6．１　需求技术 获取软件的需求是软件开发过程的重要难题，在当今的软件需求的实践中，RUP过程中的用例技术、XP中的用户故事（User Story）技术、FDD的Feature描述技术是获取需求的最佳技术，这三个技术的共同点是：站在用户的角度看待系统、定义系统 ；使用用户能够看懂的语言来描述系统，定义系统．三种需求技术的特点见表6-1所示。 6．２ RUP开发过程 RUP开发过程是“用例驱动”的开发过程，在RUP开发过程中，开发人员首先捕获客户的需求，并以用例的形式组织成用例模型；然后对需求模型进行分析、整理、验证，建立分析模型；最后以分析模型为基础，设计系统，来满足这些用例模型的要求。因此，软件的整个开发过程，就是建立模型的过程，从建立用例模型开始，其次是分析模型，接着是设计模型和实现模型，在建立了这些模型之后，还将根据用例模型设计出测试模型来对系统进行验证。 所有模型的建立过程不是线性转变的，而是是一个迭代、增量的开发过程。也就是在整个项目开发周期中，将会多次经过这五个模型的迭代、修改、删除、优化、精化的过程。 下面是对5个模型的定义： 1.用例模型：能够有效地帮助开发人员发现真正的功能需求，并用UML设计语言来描述需求，如，用例图。 6．２ RUP开发过程 2.分析模型：通过协作图来描述用例，检验、验证用例的一致性、正确性、完备性、可行性。分析的结果表示为类图、包图。 3.设计模型：在分析模型的基础上，把分析阶段的类分解为语言能实现的软件类，利用各种实现技术构造系统、子系统；并把设计类进行分组，打包、定义子系统和类的接口。这一阶段的产品有：（类图、对象图、包图、构件图） 4.部署模型：定义可计算节点系统的物理结构，并验证运行在这些节点上的构件想法是否实现了用例。（构件图、部署图） 5.测试模型：根据用例中所描述的功能来构建测试模型。 采用用例技术的优点有2点：一是，用例表达了用户对软件的目标要求，用例是系统向其用户提供的增值功能。二是，用例很直观，用户和客户根本无法了解复杂符号，而用例这种简单、自然的表述法可以使其易于阅读，并提出修改意见。 ６．３ 用例图的概念 1．用例图 用例图是描述用例、参与者及其关系的图。与所有UML的其它图一样，用例图可以包括注释、约束。图6-1是棋牌管理系统对应的用例图。 图中的元素包括：参与者、用例、一个方框和一些表示关系的连接线，所有的用例都位于方框之内，该方框称为“系统边界”。 方框内是棋牌管理系统的多个用例，方框外是外部参与者。 ６．３ 用例图的概念 2．用例图的作用 　 用例图展示了用例之间以及用例与参与者之间是怎样相互联系的。用例图对系统、子系统或类的行为进行了可视化，使用户能够理解如何使用这些元素，并使开发者能够实现这些元素。 用例图主要用来描述用户的功能需求。UML侧重从最终用户的角度来理解软件系统的需求，强调谁在使用系统、系统可以完成哪些功能。用例分析技术已经是一种公认有效的用户需求获取、分析和描述技术。 3．用例图的组成元素 用例图的组成元素包括用例、参与者、关系(用例间的关系，参与者之间的关系，参与者与用例之间的关系)。 6．4 用例图的表示 多个用例组成一个系统，参与者是系统外部的一个实体，它以某种方式与系统交互，请求系统执行用例，以获得参与者需要的价值。 在用例图中最为核心的两个元素是参与者（Actor）和用例（Use Case）。 6．４．１　参与者的表示 参与者是为了完成某个任务，而与系统进行交互的实体。参与者是用户相对系统而言所扮演的角色。 1．参与者的表示 参与者有两种表示方法，如图6-2所示． 6．4 用例图的表示 ２． 参与者分类 参与者不仅可以由人承担，还可以是其他系统、硬件设备，甚至是时钟。对参与者有两种分类方法：一种是按参与者本身的性质分，一种是按参与者的重要性来分。 按参与者性质分： 1）其它系统：当系统需要与其它系统交互时，如ATM柜员机系统中，银行后台系统就是一个参与者；2）硬件设备：如果系统需要与硬件设备交互时，如在开发IC卡门禁系统时，IC卡读写器就是一个参与者；3）时钟：当系统需要定时触发时，时钟就是参与者 6．4 用例图的表示 按参与者重要性分： 与某个用例交互的参与者可能有多个，按参与者对用例的重要性分为以下两类： 1）主要参与者：从系统获得可度量价值的用户，他的需求驱动了用例所表示的行为或功能。 2）次要参与者：在系统中提供服务，并且不能脱离主要参与者而存在。 6．4 用例图的表示 6．４．２ 用例的表示