第章UML地图.pptVIP

第四章 UML的图 UML建模分为静态建模和动态建模。 用例图、类图、对象图、包图属于静态建模。 时序图、协作图、活动图、状态图属于动态建模。 一、用例图（Use Case Diagrams） 用例图显示一组用例，参与者以及它们之间的关系。用于需求分析阶段，即确定“谁使用系统以及做什么”。 画好用例图是由软件需求到最终实现的第一步。 用例图包括以下3方面内容。 （1）用例（Use Case） （2）参与者（Actor） （3）关系（依赖、泛化以及关联） 用例图的主要元素是用例和参与者：所谓用例是指对系统提供的功能(或系统的用途)的描述；参与者是指可能使用用例的人或外部系统。两者的关系是“谁使用了哪个用例”. 用例图着重于从系统外部参与者的角度来描述系统需要提供哪些功能，并且指明这些功能的参与者是谁。 1、参与者（Actor） 参与者（Actor）是系统外部的一个实体（可以是任何的事物或人），它以某种方式参与了用例的执行过程。 参与者通过向系统输入或请求系统输入某些事件来触发系统的执行。参与者是系统之外，透过系统边界与系统进行有意义交互的任何事物（人或事物）。 在处理参与者时，应考虑其参与系统的身份，而不是人名或工作名。 在UML中，参与者用人形图符表示。 但参与者未必是人，可以是一个外部系统。 参与者—识别思路 谁使用该系统 谁改变系统的数据 谁从系统获取信息 谁需要系统的支持以完成日常工作任务 谁负责维护、管理并保持系统正常运行 系统需要应付那些硬件设备 系统需要和那些外部系统交互 谁对系统运行产生的结果感兴趣 案例：库存管理系统 某汽车制造厂需要一套库存管理系统，该系统实现的业务：生产工人根据生产计划领取物料，库存操作员根据生产系统的派单准备，交付给领料工人，余料即时归还库房。库房管理人员定期盘点库存，通知供应商供货，对长期积存的货物，申请退货。 识别思路： 谁使用该系统 谁改变系统的数据 谁从系统获取信息 谁需要系统的支持以完成日常工作任务 谁负责维护、管理并保持系统正常运行 系统需要应付那些硬件设备 系统需要和那些外部系统交互 谁对系统运行产生的结果感兴趣 库存管理系统的参与者 识别用例 识别用例最好的办法就是从分析系统的参与者开始，先列出所有的参与者，在根据每个参与者列出与它有关的用例（P44）。在识别用例的过程中，通过以下的几个问题可以帮助识别用例： （1）参与者希望系统提供什么功能？ （2）系统是否存储和检索信息？如果是，这个行为由哪个参与者触发? （3）当系统改变状态时，通知参与者吗？ （4）存在影响系统的外部事件吗？ （5）是哪个参与者通知系统这些事件？ 用例分析 用例分析是处于系统的需求分析阶段，这个阶段应该尽量的避免去考虑系统实现的细节问题。也就是说，用例描述的是一个系统做什么，而不是怎么做。 案例2：零件销售系统 3、关系 参与者与用例之间 关联关系 用例与用例之间 包含关系 (include) 扩展关系 (extend) 泛化关系 (generalization) 参与者与参与者之间 泛化关系 (generalization) 关系—参与者与用例之间 关联关系 描述参与者与使用用例之间的关系。在UML中，关系用实线表示，实线可以有箭头，也可以没有箭头。 例：参与者与用例通过关联相连。 1）包含关系(include) 包含关系中一个用例总是使用另一个用例的功能 -* 如果两个以上用例有大量一致的功能，则可以将这个功能分解到另一个用例中。 * 一个用例的功能太多时，可以用包含关系建模两个小用例。 包含关系中基用例本身是不完整的。 例1： 本例中，用例“Check Credit” 检查输入的信用卡号是否有效，信用卡是否有足够的资金。 例2：（见课程设计书P34） 2）扩展关系(extend) 扩展关系允许一个用例（可选）扩展另一个用例的功能。 当某个新用例在原来的用例基础上增加了新的步骤序列，则原用例被称作基用例，这种关系被称为扩展关系。 基用例可以单独存在，但在一定的条件下，他的行为可以被另一个用例的行为延伸。扩展只能发生在基用例的序列中某个特定的点上，这个点叫扩展点。 扩展关系中基用例本身是完整的。 例（见课程设计书P34） 包含关系与扩展关系的区别 用例间的关系——泛化关系 3）泛化关系（也称类属或概括关系） 泛化关系其实是子类与父类的关系。象类之间的泛化关系一样，用例和参与者也可以继承另一个用例和参与者。 例（见课程设计书P33） 关系—参与者与参与者之间 用例的描述——事件流（见课程设计书P30） 建立实际的系统，还需要更多的细节，这些细节写在事件流文档中。 事件流是通过文字描述一个用例的行为，说明用例的逻