UML建模-基于UML的系统分析与设计.ppt

基于UML的系统分析与设计 UML建模 一种系统开发方法应由建模语言和开发过程组成。 建模语言是设计的表示符号,而过程则是描述如何进行开发所需的步骤。 UML的开发过程包括需求获取、系统分析、系统设计、实现和测试5个步骤。 第一阶段 需求获取 需求获取 1.需求获取 系统开发的第一步工作就是进行需求收集。 需求收集从调查开始。 调查是为了发现了系统中的参与者和高层用例。 2.建立用例图 为了能够准确的描述用户的需求，就要使用用例。 首先需识别用例，然后才能建立用例。 ⑴确定系统边界 在确定参与者和用例的过程中也就确定的了系统的边界， 用例是系统之中的， 参与者是系统外部的。 （1）识别参与者 一般地，可以通过以下问题去寻找用例图中的参与者： 谁是系统的主要使用者？ 谁从系统获取信息？ 谁向系统输入信息？ 谁从系统中删除信息？ 谁需要系统支持他们的日常工作？ 谁来维护、管理系统使其能正常工作？ 系统需要控制哪些硬件？ 系统需要与其他哪些系统交互？ 对系统产生的结果感兴趣的是哪些人或哪些事物？ （1）识别参与者 除把直接使用系统的人员确认为参与者外。 凡是与系统进行信息交换（包括数据信息和控制信息交换）的外部事物均可被确认为参与者。 外部事物指的是：人员、设备、外部系统、事件。 ⑵识别用例 基于参与者识别用例 l）识别出与系统有关的参与者。 2）对每个参与者，识别出他们发起或参加的过程。 3）对每个参与者，识别出向他们传递信息的过程。 可列一个表 为编制用例准备一个表 参与者→职责→用例 参与者名： customer（客户） 参与者职责： 定货、退还定货、查询定单。 参与者检查问题： 使用系统主要功能； 对系统运行结果感兴趣。 参与者→职责→用例 从发货者（Shipper）识别 发货者要求系统提供什么功能？ 仓库存储物品的管理； 发货处理。 发货者需要做什么？ 从所有的定单中按顺序挑选出优先级较高的定单来发货； 在发货单上签上发货的品名、数量。 ? 发货者需要阅读、创建、销毁、更新或存储系统的某些信息吗？ 是，发货者需要阅读、更新仓库存储物品信息和顾客信息。 ? 系统中的事件一定要告知发货者吗？ 仓库有关物品短缺（发货者报告） 识别用例 通常，在确定用例前应考虑以下问题： 参与者需要使用系统吗？ 对于各个参与者，哪些任务会涉及到系统？ 系统与参与者之间有哪些交互？ 系统需要何种输入输出？输入从何处来？输出到何处去？ 识别用例 用例将支持和维护的系统功能是什么？ 必须提醒参与者的系统事件有哪些？ 参与者必须提醒系统事件有哪些？怎样把这些事件表示成用例中的功能？ 用例的粒度 不要把用例划分的过大，也不要把用例划分得过于琐碎细小。 通常,用例的行为都是用事件流描述，并且会产生显著的目标。这是用例粒度的底线。 即每个用例都应当是一个完成有意义的业务目标的事件流集合。 用例过细 一般认为合适的把握 ⑷确定关系 确定用例的最后一个步骤就是描述关系。 关系包括： 参与者与用例之间的关系 用例之间的关系 参与者之间的关系。 关系类型包括： 关联关系、包含关系、扩展关系和泛化关系。 库存管理用例图 发现包含关系 系统分析员应该检查模型中的每个用例，提炼出公共的部分，创建单独的用例，并用包含关系与基本用例连接。 这样会降低原来的用例复杂性，增加用例的复用性。 发现扩展关系 系统分析员检查每个用例，如果发现一个用例比较大，并且其中既包含了一般处理又包含了特殊处理，那么就应该将特殊处理的部分提取出来，创建单独的用例，并且用扩展关系连接这个用例与相关的用例。 这样会降低原来的用例复杂性，处理更简单。 参与者泛化关系 有时参与者之间存在一些共性，为了便于描述参与者之间的区别，使用参与者泛化关系来描述参与者之间的关系。 用来判断应使用哪种关系的规则： 当处理一般与特殊的关系时，采用泛化关系。 当避免两个或多个例出现重复描述时，采用包含关系 当描述用例的某种异常动作。采用扩展关系 用例的优化 用例是否有重复的功能出现（合并） 是否有功能上的包含（合并） 优化原则： 独立 集中 用例的优化 合并 同类或相似的用例合并 例：电子邮件撰写、邮件查看、合同录入、合同修改、合同删除、合同查看 功能性合并 文档录入（电子邮件撰写、合同录入） 文档查看（邮件查看、合同查看） 业务性合并 邮件管理、合同管理 用例的优化 拆分 对较大的或复杂的用例 用例描述，描述到了第四级，仍无法描述清楚，需用例拆分 主流→子流→分支流→子分支流 用例的优化 拆分例子 管理用户包括处理：添加用户、修改用户信息、删除用户、查找用户、修改用户口令、变更用户级别 拆分为：维护用户信息、管理用户权限两个用例（按业务相关性） 3.定义用例的优先级 定义用例的优先级是为了区分