电子商务信息系统分析与设计徐天宇第09章节面向对象的系统分析1章节.ppt

第9章 面向对象的系统分析 面向对象的系统分析 一种系统开发方法应由建模语言和开发过程组成。 建模语言是设计的表示符号,而过程则是描述如何进行开发所需的步骤。 本书采用的UML的开发过程：需求获取、系统分析、系统设计、实现和测试5个步骤。 迭代 UML软件开发过程就是一个多次反复修改、逐步完善的迭代过程。 在实际工作中，建模的步骤并不一定严格按照前面讲述的次序进行。 9.1需求获取 9.1.1需求获取 系统开发的第一步工作就是进行需求收集。 需求收集从调查开始。调查的对象、方法、内容、步骤可参照第四章中介绍的内容。 调查的目的是为了发现了用户的需求。 2.建立用例图 为了能够准确的描述用户的需求，就要使用用例。 从需求角度来说，一个用例就是使用者对系统的一个需求。 用例捕捉的是功能性需求。所有用例结合起来就构成了“用例模型”，该模型描述系统的全部功能。这个模型取代了系统传统的功能规范说明。 首先需识别用例，然后才能建立用例。 1.确定系统边界 在确定使用者和用例的过程中也就确定的了系统的边界， 用例是系统之中的， 使用者是系统外部的。 例：系统边界 确定系统边界的参考问题 这些需求对于系统是否是必须的？ 这些需求是系统在逻辑上会完成的吗？ 这些需求是使用者要求系统去做的吗？ 2.识别使用者 ⑴识别使用者的一般方法的参考问题 谁是系统的主要使用者？ 谁从系统获取信息？ 谁向系统输入信息？ 谁从系统中删除信息？ 谁需要系统支持它们的日常工作？ 谁来维护、管理系统使其能正常工作？ 系统需要控制哪些硬件？ 系统需要与其它哪些系统交互？（这里的其它系统包含其它计算机系统和其它应用程序。） 对系统产生的结果感兴趣的是哪些人或哪些事物？ ⑵系统边界与使用者 系统边界与使用者 ⑶事件与使用者 事件是在特定的时间发生的事情，并且启动或触发了系统的预置响应。 事件分为外部、内部和定时三类。 事件驱动系统的基本运作模式是 系统空闲等待； 事件发生，系统响应； 响应完成，系统继续等待。 ⑷特殊的使用者――系统时钟 ⑵识别用例 面对一个大系统，要列出用例清单常常是很困难的。 在这种情况下，往往首先需要找出各种可能的使用者，开列出他们的名单，然后通过对这些使用者的调查，为他们描绘出各自要求的用例。 3.识别用例 ⑴根据与使用者有关的服务请求或事件 常用来识别用例的方法是基于使用者的方法。 ①识别出与系统有关的使用者。 ②对每个使用者，识别出它们发起的服务请求或事件。 ③对每个使用者，识别出向它们传递信息的服务或事件。 使用者发起的服务请求或事件 向使用者发起的服务请求或事件 ⑵根据使用者的职责 使用者的职责是他应完成的任务，也是他对系统功能的需求。 因此，我们通过列出使用者的职责，也能帮助我们识别系统的用例。 对象责任 使用者→职责→用例 使用者名：customer（客户）。 使用者职责：定货、退还定货、查询定单 使用者→职责→用例 2．从发货者（Shipper）识别 ? 发货者要求系统提供什么功能？发货者需要做什么？ 答：发货者要求系统提供： 仓库存储物品的管理； 发货处理。 发货者需要做； 从所有的定单中按顺序挑选出优先级较高的定单来发货； 在发货单上签上发货的品名、数量。 ? 发货者需要阅读、创建、销毁、更新或存储系统的某些信息吗？ 答：是，发货者需要阅读、更新仓库存储物品信息和顾客信息。 ? 系统中的事件一定要告知发货者吗？ 答：是，这些事件包括： 仓库有关物品短缺（发货者报告） 根据使用者的职责识别用例 使用者需要使用系统吗？ 对于各个使用者，哪些职责会涉及到系统？ 系统与使用者之间有哪些交互？ 系统需要何种输入输出？输入从何处来？输出到何处去？ 用例将支持和维护的系统功能是什么？ 必须提醒使用者的事件有哪些？ 使用者必须提醒的事件有哪些？怎样把这些事件表示成用例中的功能？ 4.用例的粒度 不要把用例划分的过大，如只用一个用例就把一个系统或子系统的功能行为全部包括在内， 但也不要把用例划分得过于琐碎细小。 通常,用例的行为都是用事件流描述。这是用例粒度的底线。 即每个用例都应当是一个完成有意义的业务任务的事件流集合。 4.用例的粒度 用例粒度的合适的把握是： 一个用例应当是一个完成有意义的业务任务的事件流集合。 一个用例以能够描述使用者与计算机的一次完整交互为宜。 一个用例只描述没有大的分支的事件流的单个线索。 用例过细 一般认为合适的把握 5.确定关系 关系包括使用者与用例之间的关系、用例之间的关系、使用者之间的关系。 具体表现为:关联关系、包含关系、扩展关系和泛化关系。 表— 角色、用例间的关系类型 确定关系时，需确定 这种关系是谁发出来的 注意箭头