信息系统课件-系统分析.pptVIP

（2）建立业务模型 业务模型除包括类图、对象图以外，还要画出用例图、活动图、顺序图和状态图。 用例图从使用者角度描述系统。侧重从功能的角度描述业务过程的信息，表达业务过程各个功能的组成部分，确定参与者，以及参与者使用的业务用例。 例：电话订货系统的用例图 电话订货 查询订单 开列订单 验证客户 安排付款 审核使用 extend include include include extend extend 客户 服务人员 例：用例图、类图、顺序图、状态图之间的关系 开列订单 验证客户 extend 用例图 服务人员 服务人员 订单 客户 商品条目 类图 顺序图 订单：…….. 客户：…….. 创建订单 验证客户 订单调出 订单分发 订单存档 订单入座 订单填写 订单类的状态图 例：活动图—描述单个业务用例的细节过程 创建订单 确认订单 提供优惠 填写订单 团体付费 信用卡付费 填写订单 个别订户 分支 同步条 团购订户 同步条 合并 （3）需求说明的补充 对于非功能需求，采用传统手段进行说明。内容有： 可用性：用户可以使用系统的时间百分比。 可靠性：系统正确运行的可靠程度。 性能：系统功能之外增加的条件。如，容量、响应时间、带宽等。 可支持性：为保持可维护性、可扩展性必须达到的要求。 设计约束：对系统设计的限制。 接口需求：系统与外部的接口，如：软件接口、硬件接口、通信接口等。 其他需求：在线帮助、产品许可等。 参与者（Actor)是UML的专门术语。特指系统外部介入系统的实体。可以是人员、设备、其他系统等。 参与者的输入，或请求系统输出是触发系统用例执行的根源。 区分实体、参与者、角色。同一实体在不同用例面前可能扮演不同角色。 业务用例中的角色经系统分析员提炼成为参与者。 3、功能分析 （1）识别参与者 功能分析的工作：识别参与者、定义系统边界、识别系统用例、识别用例间的关系、建立用例模型，划分用例优先等级等。 提炼角色为参与者的步骤： 考虑所有可能与系统运行有关的人员、设备和其他系统； 确定系统在输入、输出方面的参与者； 确定系统操作和维护方面的参与者； 将参与者——用户——角色联系起来； 进行合理组织和合并，减少功能重叠，形成参与者和角色类别； 对参与者命名 电话订货 查询订单 开列订单 验证客户 安排付款 审核使用 extend include include include extend extend 客户 服务人员 （2）定义系统边界 大边框界定了系统边界 （3）识别系统用例 识别系统用例的两种方式：基于参与者的方式；基于事件的方式。 整理用例集 识别外部事件 发现服务对象 识别执行过程 创建订单 分析事件功能 识别参与者 通过系统必须 响应的外部事 件，找出系统 的边界和内外 联系 通过系统功能分 析，找出系统事 件与参与者的关 系，进而建立用 例 通过识别参与 者，确认最终 使用者和服务 对象 通过分析每个 参与者所发起 参加的执行过 程，确定转化 为用例的可能性 通过对参与者、 事件、过程、功 能及相互关系的 分析，建立用例 和用例集合 识别用例完成后，还要考虑以下问题： 每个参与者的特定任务是否完成？ 是否每个参与者都要从系统中创建、存储、改变、移动或读取信息？ 是否有特定任务或数据尚找不到参与者？ 是否需要将系统维护、支持的用例画上去？ 是否有其他重要的功能需求没有列上去？ （4）识别用例间的关系 用例之间也有关系之间所具有的关系，即：关联、聚集、泛化等。 用例之间还有两种特殊的关系：包含、扩展。 包含关系： 表示所触发用例的完成需要调用其他子用例。 扩展关系： 表示可以选择的行为集合、特定条件下才发生的行为集合、或者不同流程等。 系统分析 一、系统分析概述 三、事物、对象及其关系属性 二、事件和事件的描述 四、需求建模 五、需求建模实例 一、系统分析概述 1、系统分析的用户视图 分析的目的：分析现实世界的 事物如何转化到计算机世界，使信息系统能最终达到原来现实世界的目的。 分析的结果：产生对现实世界一组准确、完整、一致并且可以检验的系统模型。 系统 拥有 者 系统 用户 系统 设计 者 系统 实施 者 关注数据 关注处理 关注接口 关注通信 系统开发 商务知识 数据需求 数据库范式 数据库程序 系 统 分 析 员 关注者 系 统 分析 与 设计 方 法 学 处 理 过 程 数据库 管理系统 销售与 咨询商 商务功能 处理需求 应用范式与说明 商务地点 接口需求 通信环境 通信需求 系统分析阶段数据、功能和交互行为板块的用户视图 2、模型驱动的分析方法 模型驱动的方法强调对现有系统和目标系统采用图示的系统模