第3系统需求建模SPA31.ppt

3.1系统需求建模 －－事件和事务 小组二次作业 设计一二级DFD图 设计一二级用例图 设计类图 设计主要用例的时序图 每人撰写一个用例的用例文档 小组经理工作要求 组长：组织小组讨论会 开发经理：负责项目各作业的技术方向 计划经理：与其他成员讨论开发计划并跟踪。 质量经理：确定每个项目的质量标准并检查。 技术经理：提供项目开发平台技术支持好开发技术技术支持。 学习目标 学习本节后具有如下能力： （1）解释为何要建立信息系统模型 （2）描述三类模型 （3）阐述如何利用系统事件来定义系统需求 （4）确定和分析系统对之做出响应的事件 （5）解释如何用系统中的事务概念来定义需求 （6）比较数据实体和对象之间的差异 （7）确定和分析系统中需要的数据对象 （8）阅读、解释并创建E-R图 （9）阅读、解释并创建类图 本节要点 事件和模型 事件和系统需求 事务和系统需求 E-R图 类图 目标 本章主要工作是在前面收集信息资料的基础上，通过建立各种模型来将功能需求整理成文档的一些技术。 这些模型是在分析活动过程中建立的，也就是通常称之为“定义系统需求” 模型于建模 模型－是分析和设计工作后产生的文档 作用 （1）建模过程可以进行系统分析 （2）系统需要不同形式和抽象层次的模型描述系统的各个方面。 （3）提供了一个容易理解的信息形式 （4）是一个交流过程，也有利于交流 逻辑模型和物理模型 模型是对对象系统的形式化的特征 抽象，概括性或近似地表示 构造模型的过程是一个抽象、分 析的过程。 模型的作用 在建模过程中了解系统 通过抽象降低复杂性 有助于回忆所有的细节 有助于开发小组间的交流 有助于与用户的交流 为系统的维护提供文档 模型的类型 数学模型：描述系统技术方面的一系列公式 描述模型：描述系统某些方面的叙述性的备忘录、报表或列表 图形模型：图表或系统某些方面示意性表示 如分析阶段创建的模型有：事件列表、数据流图、E-R图，数据流定义、数据元素定义、过程描述、用例图、类图、位置图、顺序图、协作图、状态图 设计阶段的模型有：窗口界面，报表设计，系统流程图，结构图，数据库设计，网络拓扑，分布图等 事件和系统需求 事件 可以描述、值得记录的在某一特定时间和地点发生的事情。 事件类型 外部事件：系统外部发生的，通常由外部实体或动作参与者触发。 临时事件：到达某一时刻所发生的事件。 状态事件：当系统内部发生了需要处理的情况时所引发的事件。 定义事件 事件/条件和响应 事件序列：跟踪事件处理的生命周期 技术依赖事件和系统控制 用事件列表表示每个事件 事件 触发器 来源 活动/用例 响应 目的 事件和系统需求 系统需要存储的事务信息 工作过程中的产品、订单、客户等 传统开发中，事务构成系统存储信息 对象开发中，事务是系统中交互的对象 事物类型 实物：飞机、书、文档、工作表 角色：雇员、顾客、系统管理员、用户 组织部门：工作组、部门、系、班级 设备：打印机、电脑、窗口、鼠标 突发事件或事件交互：登陆、退出、合同、订单、支付、购买 地点/位置：仓库、工厂，部门办公室、零售店 事物列表过程 使用事件列表，确定所有名词 使用已有系统，从当前过程及当前报表中寻找其他信息 将列表精简并记录假设或要检查的问题 （1）是系统要了解的事物吗？ （2）在你所工作的系统范围内吗？ （3）系统需要记住多于这些项目中的一个吗？ （4）与你已经定义的其他事物是同义词吗？ （5）真的是从你已经定义的其他信息中产生系统输出吗？ （6）这一输入真的可以导致记录一些你已经定义的其他信息吗？ （7）可能是你已经定义的其他事物的一些属性吗？ （8）当假设变化时你可能需要的事物吗？ 事物之间的关系 1:1 1:N N:M 二元关系 一元（回归）关系 三元关系 N元关系 事物属性 属性：有关事物某方面特征 关键字（标识符）：能唯一标识事务的属性 复合属性：包含许多相关属性的属性 数据实体与对象 数据实体：需要存储其信息的事物 对象：某个特定事物，有属性，方法和消息构成。 3.2需求的传统描述方法 结构化描述 （1）DFD 结合了事件触发处理和在ERD中定义的数据实体相结合（事件表和ERD） 重点：抽象水平（把系统分解成一个逐渐细化的分层集合的建模技术） 数据流图 (DFD，Data Flow Diagram) 描述逻辑模型的图形工具， 表示数据在系统内的变化。 DFD可以用来表示一个系统或软件在任何层次上的抽象。 较大型软件系统DFD分成多层(子图、父图概念),可以表示数据流和功能的进一步的细节。 数据流程图的表示 画数据流图 规则：由外向里画 画系统的输出、输入 化系统的内部 画加工的内部 词典条目的各种类型 四个类型条目 数据