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