《[互联网]4用例图.ppt》由会员分享，可在线阅读，更多相关《[互联网]4用例图.ppt（67页珍藏版）》请在三一文库上搜索。
1、用例图,用例图概述 参与者 用例 各种关系 用例文档 用例图建模技术 实例练习,用例图的优点与主要作用,软件开发的首要工作是了解需求 需求分析难于确定的最主要原因是：软件的开发者并不是最终软件的使用者 用例图的优点 可视化地表达系统需求，直观规范 用例图的主要作用： 在探讨问题时，便于系统用户、系统分析和设计人员、领域专家沟通交流、达成共识 使开发者快速准确的了解用户需求和相关概念,用例图的定义与组成,定义：由参与者、用例以及它们之间的关系构成的用于描述系统功能的动态视图 组成元素 参与者（Actor） 用例（Use Case） 关系（Relationship）,参与者,定义： 人、系统或类的
2、外部实体的抽象 存在于系统外部并直接与系统进行交互 表示方法： 使用一个人形图标来表示 参与者的名字写在人形图标下面。,参与者的种类,参与者不仅可以由人承担，还可以是其他系统、硬件设备，甚至是时钟。 人：当系统需要与某个人交互时（用户） 其它系统： 当系统需要与其它系统交互时 如：ATM系统中，银行后台系统就是参与者 硬件设备： 当系统需要与硬件设备交互时 如：门禁系统中，磁卡读写器就是参与者； 时间： 当系统需要定时触发时 如：定时闹钟系统中，时间就是参与者。,如何识别参与者？,1）系统完工之后，谁在使用系统完成日常的工作？ 2）系统是由谁来维护和管理的？ 3）谁对系统产生的结果感兴趣？ 4
3、）系统需要从谁那里获得数据？又为谁提供数据？ 5）系统需要与哪些其他系统交互（使用其他系统或被其他系统所使用）？ 6）系统控制的硬件设备有哪些？ 7）系统功能的执行是否受时间的影响？,注意事项,同一个人或事物可以扮演不同的角色 参与者不是指人或事物本身，而是指人或事物当时所扮演的角色。 不能将参与者的名字设置为参与者某个实例的名字,参与者之间的关系,参与者实质上也是类，因此它拥有与类相同的关系描述 参与者与参与者之间主要是泛化关系,用例的定义,定义： 是参与者可以感受到的系统服务或功能单元。 用文本的形式描述了参与者为了使用系统的某项功能而与系统之间发生的交互过程 表示方法： 使用椭圆图形来表
4、示 用例名称写在椭圆下方 用例名的两种表示方法,思考,用例的名称应使用动词开头 下列用例的名字是否合理？,注意事项,用例必须由某个参与者触发激活后才能执行 每个用例至少应该对应一个参与者 如果存在没有参与者的用例，就可以考虑将这个用例并入其他用例之中 用例表明的是一个类，而非某个具体实例 用例不是一个椭圆，而是一个完整的描述,用例与场景,定义：在系统中，按照某个顺序执行了一系列相关的动作后，即可实现某种功能，把完成了这一功能操作的集合称为场景。 用例与场景的关系 类是对一组对象共同属性和行为的抽象 用例是对一组场景共同行为的抽象 场景就是用例的实例，是用例的一次完整的、具体的执行过程 场景包括
5、成功场景和失败场景 在描述用例时应覆盖所有的场景，避免遗漏某些需求,场景举例,小刘取款场景,事件流：用例执行时动作的有序集合称为事件流,开发者获取需求的步骤,第一步：首先将用户的工作流程表示为场景，然后，将同类场景抽象为用例，以描述系统功能 第二步：客户和用户通过审查场景，并测试开发者提供的原型系统，以验证和确认需求规格说明 第三步，当系统需求定义成熟和稳定后，开发者和客户共同对需求规格说明进行确认。包括：系统的功能性需求、非功能需求、用例和场景在内的需求确认,如何识别用例？,任何用例和参与者都无法独立存在 识别用例通常从分析系统参与者开始： 1）参与者希望系统提供什么功能？ 2）参与者是否需
6、要获取或管理系统中某些信息？如果是的话，参与者又是如何完成这些操作的？ 3）参与者是否会将外部的某些事件通知给系统？ 4）系统中发生的事件是否需要通知参与者？ 5）是否存在影响系统的外部事件？,真实项目中如何发现用例？,请遵循如下思维习惯： 首先弄清楚有多少部门，多少岗位(参与者)？ 然后找到每一个岗位的业务代表，问他们类似的问题： 你平时都做什么？（参与者目标） 这件事是谁交办的？（交互） 做完了你需要通知或传达给谁吗？（交互） 做这件事情你都需要填写些什么表格吗？（用例）,用例的粒度,用例的粒度：用例所包含的系统服务或功能单元的多少 用例的粒度越大，其包含的功能就越多，最终得到的用例数就越
7、少； 用例的粒度越小，其包含的功能就越少，得到的用例数就越多；,用例的粒度,粒度的选择 适中合适： 粒度太大，用例数目过少，就会分析不充分 粒度太小，用例数目过多，就会使模型庞大繁杂，难于理解和使用 具体问题具体分析 简单问题：粒度小一些，将比较复杂的用例拆分成多个 复杂问题：粒度大一些，让一个用例包含较多的需求信息量，将复杂度适当引往用例内部,用例之间的关系包含,包含关系：用例可以简单地包含其他用例具有的行为，并把它所包含的用例行为作为自身行为的一部分。 箭头由基用例指向包含用例。,用例之间的关系包含,基用例和包含用例的事件流执行顺序,包含用例的事件流插入到基础用例的事件流中,包含关系的使用
8、,何时需要用到包含关系？ 多个用例用到同一段的行为，则可以把这段共同的行为单独抽象成为一个用例，然后让其他用例来包含这一用例 某一个用例的功能过多、事件流过于复杂时也可以把某一段事件流抽象成为一个被包含的用例，以达到简化描述的目的,包含关系的优点,可以避免在多个用例中重复描述同一段行为 提高了用例模型的可维护性：当需要对公共需求进行修改时，只需要修改一个用例而不必修改所有与其有关的用例 避免在多个用例中对同一段行为描述的不一致,用例之间的关系扩展,扩展关系：在一定条件下，把新的行为加入到已有的用例中，获得的新用例成为扩展用例，原有的用例称为基用例。 箭头方向是从扩展用例指向基用例。,用例之间的
9、关系扩展,扩展关系和包含关系的区别,1）在扩展关系中，扩展用例只有在满足一定条件下才会被执行；而在包含关系中，当基用例执行后，被包含用例是一定会被执行的 2）即使没有扩展用例，扩展关系中的基用例本身也是完整的；而对于包含关系，基用例在没有被包含用例的情况下就是不完整的存在。,用例之间的关系泛化,泛化关系：一个父用例可以被特化形成多个子用例，子用例继承了父用例所有的结构、行为和关系，子用例是父用例的一种特殊形式。 通过一个三角箭头从子用例指向父用例,用例之间的关系泛化,父用例和子用例之间的事件流,当发现系统中有两个或者多个用例在行为、结构和目的方面存在共性时，就可以使用泛化关系,泛化关系和包含关
10、系的区别,泛化关系 所有的子用例都有相似的目的和结构。它们是整体上的相似。 包含关系 基用例在目的上可以完全不同，但是它们都有一段相似的行为。它们的相似是部分的相似。,用例关系总结,包含关系：主要目的是为避免用力文本的重复编写 扩展关系：可以将可选路径中的场景抽象为扩展关系（通常都是不必要的） 泛化关系：两个或更多用例在行为、结构、目的等方面存在共性,系统边界,用来定义系统的界限 系统的用例都置于其中 参与者则置于边界之外 可以很清晰地标识出了系统的范围。,思考,某企业要求开发一个企业管理系统，并与原来的财务系统相连接，谁是actor？ 某企业要求开发一个企业管理系统，并且改造旧有的财务系统，
11、将它成为管理系统的一部分，谁是actor？ 某商品销售系统：顾客通过网络下单后，系统计算出总计金额、税金、运费，并将数目传递给一个外挂的会计系统（会计系统是另外购买的）。谁是actor？,用例图中的注释,持有银行信用卡的自动取款机用户,银行客户,取款,查询,转账,用例文档（规约）,用例图只能勾勒一个大致的系统功能轮廓，对于软件开发活动而言不够充分 一个完整的用例模型不仅包括用例图这个部分，更重要的是它的用例描述部分 用例文档： 采用足够清晰的、外部人员很容易理解的文字来描述用例所属的事件流，以说明一个用例的行为,用例文档的形式与标准,用例文档编写的形式 摘要：需求分析早期使用，主要描述主成功场
12、景 登录操作：客户向系统提交用户名+密码，系统进行认证后向用户显示登录成功信息。 非正式：需求分析早期使用，可以覆盖不同场景 正式：详细编写所有步骤及各种变化(参看附件),用例文档的形式与标准,用例文档的设计标准 立足于用户：考虑用户的目标与观点 易于理解：尽量多出现用户所在行业的专用名词，避免出现计算机专业术语 避免歧义：对于同一个用例让不同受众的理解一致 黑箱子：从系统外部描述系统功能，只关心系统具有哪些功能(what)，而不关心这些功能如何实现(how),用例文档模板,事件流,前置条件：用例启动时系统所处的状态,后置条件：用例执行完毕后系统所处的状态,基本事件流：基本事件流是对用例中常规
13、、预期路径的描述，体现了系统的核心价值。,扩展事件流：主要是对一些异常情况、选择分支进行描述。,事件流：用例执行时，由一序列活动组成的控制流。 分为基本事件流和扩展事件流两种。,事件流的描述规则,1）基本事件流是一个完整的事件流描述，可能采用多层次的步骤编号(如1、1.1等)来描述其顺序 2）在基本事件流中可能通过“子事件流名称/编号”来引用一个子事件流，通过“规则名称/编号”来应用一个规则或约束。 3）扩展事件流的步骤编号的命名通常采用“1a、1b”、“1.1a、1.1b”这样的形式，以使其与基本事件流中的步骤关联起来，同时在描述时首先会描述执行该扩展事件流的入口条件。,用例文档实例,思考,
14、练习,用例描述：注册,用例描述：登录,用例图建模技术,1）用例模型的运用方法 （1）增量开发的用例模型： 用例模型不是在需求捕获之后一次性生成的。 在实际应用中，用例模型也是增量开发出来的,用例图建模技术,1）用例模型的运用方法 （2）模型元素的无缝转换 不断迭代，反复执行以下任务： 寻找用例并详细说明它们 设计每个用例 设计并实现每个类 测试每个用例,用例图建模技术,2）建模要点 1）构建结构良好的用例： 为系统和部分系统中单个的、可标识和合理的原子行为命名； 将公共的行为抽取出来，放到一个被包含用例中，再将它include进来； 对于变化部分，将其抽取出来，放到一个扩展用例中，再通过ext
15、end连接； 清晰地描述事件流，使得读者能够轻而易举地理解,用例图建模技术,2）建模要点 2）构建结构良好的用例图： 摆放元素时，应该避免交叉线的出现； 对于语义上接近的行为和角色，最好使它们在物理上也更加接近； 根据系统实际情况控制粒度。,思考,参考答案,思考,请为某棋牌馆管理系统绘制用例图 客户通过该系统查看座位信息后能提前预定座位。如未有合适的座位，可以进入等候队列 总台服务员通过该系统能够安排客人的座位，办理结账。收款时可以用现金结账，如果使用银行卡结账，需要与外界的银联POS系统交互,用例图：棋牌管理系统,练习：绘制用例图,参考答案1,参考答案2,练习：绘制用例图,参考答案,选课：基
16、本事件流,基本事件流 1.Actor进入选课登陆页面 2.系统提示输入学号和密码 3. Actor输入学号和密码 4.系统验证信息是否正确 5. Actor进入选课主届面，点击选课按钮 6.系统显示所有课程信息 7. Actor选择课程 8.系统验证课程是否可选 9.系统显示课程选择成功，提示学生缴费,选课：扩展事件流,扩展事件流 4a.信息验证失败 4a1.系统提示验证失败，提示重新输入 8A.课程不可选 8A1.系统显示课程不可选及其原因,“企业进、存、销管理系统” 功能性需求包括以下内容： （1）采购员根据生产原料的使用情况判断采购用品，对需要订购产品信息统计订货的，并制作产品订单。最后
17、根据订单进行采购活动。 （2）仓库管理员负责产品的库存管理。包括产品入库管理、处理盘点信息、处理报损产品信息和一些信息的设置。这些设置信息，包括：供应商信息、产品信息。仓库管理员每天对产品进行一次盘点，当发现库存产品有损坏时，及时处理报损信息。当产品生产后，将产品进行入库。当产品销售后时，产品进行出库处理。 （3）统计人员负责统计分析管理，包括：查询产品信息、查询销售信息、查询供应商信息、查询缺货信息、查询报表信息，并制作报表。统计分析员使用系统的统计分析功能，了解产品信息、销售信息、供应商信息、库存信息。 （4）在销售员为客户提供售货服务时，接受客户购买产品，根据系统的定价计算出产品的总价，
18、客户付款，系统自动保存客户购买记录。 （5）系统管理员负责本系统的系统维护。系统管理员负责员工信息管理、供货商信息管理以及系统维护等。每种管理者都通过自己的用户名称和密码登录到各自的管理系统中。,1、需求分析,使用Rose创建用例图的步骤说明,（1）销售员：为客户客提供销售产品的服务。 （2）仓库管理员：负责库存产品的管理活动。 （3）采购员：负责企业生产原料的订购。 （4）会计：负责企业经营状况的统计。 （5）系统管理员：负责企业员工信息管理、供应商信息管理以及系统维护等。,2、识别参与者,使用Rose创建用例图的步骤说明,销售员能够通过该系统进行销售商品活动。首先登录系统，验证身份成功后，
19、获取商品信息，然后将销售信息更新，最后对客户进行商品销售。,销售员用例图,使用Rose创建用例图的步骤说明,3、构建用例模型,仓库管理员能够通过该系统进行如下活动： （1）处理盘点，每天需要对库存产品信息进行盘点 （3）产品入库。当产品生产后，将产品进行入库 （4）产品出库。当产品销售发货后，进行出库处理 （5）产品报损当发现库存产品有损坏时，及时处理报损信息 （6）管理设置。仓库管理员负责供应商信息、产品基本信息的管理设置,仓库管理员用例图,使用Rose创建用例图的步骤说明,3、构建用例模型,采购员能够通过该系统进行订货管理活动。采购员首先根据经营情况统计所缺的生产资料，根据需要制定出订单。
20、,采购员用例图,使用Rose创建用例图的步骤说明,3、构建用例模型,使用Rose创建用例图的步骤说明,会计用例图,会计负责产品的统计分析管理，它能够通过该系统进行如下活动： （1）查询基本信息。会计能够查询产品的基本信息，根据产品的基本信息，制定出相应的方案。 （2）查询销售信息。会计根据销售情况汇总后交销售部制定合理的销售方案。 （3）查询供应商信息。会计能够查询供应商信息。 （4）查询缺货信息。会计能够查询缺货信息。 （5）查询报损信息。会计能够查询报损信息。,3、构建用例模型,系统管理员能够通过该系统进行如下活动： （1）维护员工信息。系统管理员能够维护企业员工的信息，如添加员工、删除员工和修改员工信息等。 （2）维护供应商信息。系统管理员能够维护供应商的信息，如添加供应商、删除供应商和修改供应商信息等。 （3）系统设置。系统管理员能够根据一些需要进行必要的系统设置。,3、构建用例模型,系统管理员用例图,使用Rose创建用例图的步骤说明,零件购买系统（见附件）,潜在用户 根据需求检索出零件的详细信息和价格 注册成为正式用户 用户 提供身份信息以通过系统验证 选择零件创建订单 管理订单 结账 经理 开放注册会员的账户,零件购买系统（见附件）,