信息系统分析与设计教学课件作者王兴鹏章节07-面向对象分析设计.pptVIP

第7章 面向对象分析与设计 主讲：王兴鹏 xingpengwang@163.com UML建模 一种系统开发方法应由建模语言和开发过程组成。 建模语言是设计的表示符号,而过程则是描述如何进行开发所需的步骤。 UML的开发过程包括需求获取、系统分析、系统设计、实现和测试5个步骤。 第一节需求获取 需求获取 系统开发的第一步工作就是进行需求收集。 需求收集从调查开始。 调查是为了发现了系统中的参与者和高层用例。 一、建立用例图 1.确定系统边界 在确定参与者和用例的过程中也就确定的了系统的边界，用例是系统之中的，参与者是系统外部的。 确定一个新需求是否属于开发的系统之中，可参考以下问题： (1)这些需求对于系统是否是必须的? (2)这些需求是系统在逻辑上会完成的吗？ (3)这些需求是参与者要求系统去做的吗? 一、建立用例图 2.识别参与者 （1）识别参与者的一般方法 一般地，可以通过以下问题去寻找用例图中的参与者： 谁是系统的主要使用者？ 谁从系统获取信息？ 谁向系统输入信息？ 谁从系统中删除信息？ 谁需要系统支持他们的日常工作？ 谁来维护、管理系统使其能正常工作？ 系统需要控制哪些硬件？ 系统需要与其他哪些系统交互？ 对系统产生的结果感兴趣的是哪些人或哪些事物？ 除把直接使用系统的人员确认为参与者外。凡是与系统进行信息交换（包括数据信息和控制信息交换）的外部事物均可被确认为参与者。外部事物指的是：人员、设备、外部系统、事件。 一、建立用例图 2.识别参与者 （2）系统边界与参与者 参与者与系统边界的划定有关 一、建立用例图 2.识别参与者 （3）特殊的参与者——系统时钟 一、建立用例图 3.识别用例 识别用例常用下面两种方法。 （1）根据与参与者有关的服务请求或事件 l）识别出与系统有关的参与者。 2）对每个参与者，识别出他们发起或参加的过程。 3）对每个参与者，识别出向他们传递信息的过程。 可列一个表，首先列出参与者，然后列出与它们有关的服务请求或事件。 为编制用例准备一个表 参与者→职责→用例 3.识别用例 （2）根据参与者的职责 参与者的职责是它应完成的任务，也是它对系统功能的需求。因此，我们通过列出参与者的职责，也能帮助我们识别系统的用例。 通常，在确定用例前应考虑以下问题： 参与者需要使用系统吗? 对于各个参与者，其哪些职责会涉及系统? 系统与参与者之间有哪些交互? 系统需要何种输入输出?输入从何处来?输出到何处去? 用例将支持和维护的系统功能是什么? 必须提醒参与者的事件有哪些? 参与者必须提醒的事件有哪些?怎样把这些事件表示成用例中的功能? 参与者→职责→用例 从发货者（Shipper）识别 发货者要求系统提供什么功能？ 仓库存储物品的管理； 发货处理。 发货者需要做什么？ 从所有的定单中按顺序挑选出优先级较高的定单来发货； 在发货单上签上发货的品名、数量。 发货者需要阅读、创建、销毁、更新或存储系统的某些信息吗？ 是，发货者需要阅读、更新仓库存储物品信息和顾客信息。 系统中的事件一定要告知发货者吗？ 仓库有关物品短缺（发货者报告） 一、建立用例图 4.确定关系 确定用例的最后一个步骤就是描述关系。 关系包括： 参与者与用例之间的关系 用例之间的关系 参与者之间的关系。 关系类型包括： 关联关系、包含关系、扩展关系和泛化关系。 用例图的关系识别 包含关系：系统分析员应该检查模型中的每个用例，提炼出公共的部分，创建单独的用例，并用包含关系与基本用例连接。这样会降低原来的用例复杂性，增加用例的复用性。 扩展关系：系统分析员检查每个用例，如果发现一个用例比较大，并且其中既包含了一般处理又包含了特殊处理，那么就应该将特殊处理的部分提取出来，创建单独的用例，并且用扩展关系连接这个用例与相关的用例。这样会降低原来的用例复杂性，处理更简单。 用例泛化：同一种业务目标的不同实现方式，可使用用例泛化关系，便于对需求的理解 参与者泛化：有时参与者之间存在一些共性，为了便于描述参与者之间的区别，使用参与者泛化关系来描述参与者之间的关系。 用例关系 一、建立用例图 5.用例描述 详细具体的描述一个用例还要使用用例描述。用例描述是指采用自然语言描述一个用例的功能。在用例描述中，通过用例的事件流可以详细地描述系统的一个功能是如何执行的。 用例描述是一个结构化的用例说明文本。描述一个用例，可参照9.3.1介绍的标准模板。 描述一个用例，应说明以下细节： 用例名 前置条件（Pre－Conditions） 后置条件（Post-Conditions） 扩充点（Extension Points） 事件流 基流（Basic Flow） 分支流（Subflows）（可选） 替代流（Alternative Flows） 一、建立用例图