电子商务系统分析与设计技术4-ok.pptVIP

主要内容 用例与用例构建方法 需求分析实例-餐馆系统的用例构建 需求分析工具使用介绍 引子--系统建模的着手点 一 是从面向对象分析设计开始,依次建立用例图,时序图及类图,由类图转化成概念数据模型及物理数据模型 二 是从结构化分析开始,依次产生流程分析模型,概念数据模型及物理数据模型 三 结合两种方法 用例 分析的第一步是确定系统能够做什么？谁来使用这个系统？这些分别叫角色（actors）和用例（use cases）。 从本质上讲，一个用例是用户与计算机之间为达到某个目的的一次典型交互作用： 用例描述了用户提出的一些可见的需求； 用例可大可小； 用例对应一个具体的用户目标； 用例图用例图描述系统外部的执行者与系统的用例之间的某种联系。 所谓用例是指对系统提供的功能（或称系统的用途）的一种描述； 执行者是那些可能使用这些用例的人或外部系统； 用例和执行者之间的联系描述了“谁使用哪个用例”。 用例图 用例图着重于从系统外部执行者的角度来描述系统需要提供哪些功能，并且指明了这些功能的执行者是谁； 用例图在UML方法中占有十分重要的地位，人们甚至称UML是一种用例驱动的开发方法。 用例图-图符 用例图中的图符：用例参与者系统：用于界定系统功能范围，描述该系统功能的用例都置于其中，而描述外部实体的执行者都置于其外。关联：连接执行者和用例，表示执行者所代表的系统外部实体与该用例所描述的系统需求有关。 1、用例 用例就是一个用来描述参与者如何使用系统来实现其目标的一组场景的集合。 通常可以把它暂时理解为功能中的模块（虽然这并不严密，但更加实用）。用例强调的是一组场景，在这组场景不多但相互之间存在功能上的共性，就像一个大功能模块下的多个子模块。 这组场景中的每一个，又分别形成一个个子用例。子用例再细分，又可以再形成各自的子用例。 用例分析就是这样由粗到细的逐步细分，从而形成一系统的用例图。用例图分析到多细，应当由业务需求的情况决定。分得过粗，就不足以说清楚业务的相关细节，或者使一张用例图信息过多，影响人们的理解；分得过细，不仅会增加工作量，还会丢失许多用例间的相互关系，得不偿失。 用例图-图符 用例图中的图符：使用：由用例A连向用例B，表示用例A中使用了用例B中的行为或功能。扩展：由用例A连向用例B，表示用例B描述了一项基本需求，而用例A则描述了该基本需求的特殊情况。注释体：对UML实体进行文字描述注释连接：将注释体与要描述的实体连接，说明该注释体是针对该实体所进行的描述。 用例图-试读 包含与扩展关系小结 包含关系表示一种从属关系，即子用例是主用例中相对独立的、必须调用的一部分功能。 在用例分析中，我们应当将多个用例都共有的、相对独立的功能提取出来形成一个子用例，为日后代码复用提供有力保障。 扩展关系表示一个功能是对另一个功能的扩展，即被扩展功能不一定调用扩展功能，但扩展功能是对被扩展功能的加强与延伸。 2、参与者 用例模型中的参与者，除了表示操作系统的人，还表示处于系统边界之外，与系统边界内的用例有关联的其它系统。 因此，只有定义好一个系统的边界，才能定义哪些是这个系统内的用例，哪些是这个系统内外的参与者。用例模型对本系统与其它系统相互关联的分析，为我们日后开发过程中，为其它系统提供接口，或与其它系统进行接口，提供了依据 参与者之间的关系 用例图 用例模型的获取： 获取执行者 获取用例 用例图 获取执行者： 谁使用系统的主要功能（主要使用者）？ 谁需要系统支持他们的日常工作？ 谁来维护、管理系统使其能正常工作（辅助使用者）？ 系统需要控制哪些硬件？ 系统需要与其他哪些系统交互？ 对系统产生的结果感兴趣的是哪些人？ 用例图 获取用例： 执行者要求系统提供哪些功能？ 执行者需要读、产生、删除、修改或存储系统中的信息有哪些类型？ 必须提醒执行者的系统事件有哪些？ 执行者必须提醒系统事件有哪些？怎样把这些事件表示成用例中的功能？ 主要内容 用例与用例构建方法 需求分析实例 需求分析工具使用介绍 关于图书馆系统的需求 1.?这是一个图书馆支持系统； 2.?图书馆将图书和杂志借给借书者。借书者已经预先注册，图书和杂志也预先注册； 3.?图书馆负责新书的购买。每一本图书都购进多本书。当旧书超期或破旧不堪时，从图书馆中去掉。 4.?图书管理员是图书馆的员工。他们的工作就是和读者打交道并在软件系统的支持下工作。 关于图书馆系统的需求 5.?借阅人可以预定当前没有的图书和杂志。这样，当他所预定的图书和杂志归还回来或购进时，就通知预定人。当预定了某书的借书者借阅了该书后，预定就取消。或者通过显式的取消过程强行取消预定。 6.图书馆能够容易地建立、修改和删除标题、借书者、借阅信息和预定信息。 7.?系统能够运行在所有流行的技术