[经济学]第5章 建模实训.pptVIP

第5章 基于UML的企业供应物流信息系统建模实训 概述 物流信息系统的建设历经阶段： 需求定义 系统分析 系统设计 系统实现 系统测试 系统交付 系统维护。 需求定义 描述用户对系统的需求（业务和系统） 基本过程 用例建模 用例模型主要用来描述系统和系统外部环境的关系，并直接影响着其他模型； 用例模型只关心系统所应实现的功能，不关心内部的细节； 用例是一组系统使用场景的集合，每个场景又是由一些事件序列构成，发起这个事件的用户就是系统使用者； 用例图是系统的高层描述，图中的角色和用例，在实现阶段则变成了对象和接口这样的底层描述。 建模过程（步骤） 确定将要设计的系统和它的边界 ； 确定系统外的活动者（参与者）； 从活动者（用户）和系统对话的角度继续寻找如下特征： 活动者怎样使用系统 系统向活动者提供什么样的功能 把离用户最近（接口）的用例作为顶级用例 对复杂的用例做进一步分解， 并确定低级用例以及用例间的关系。 寻找每一个用例发生的前提条件和发生后对系统产生的结果。 寻找每一个用例在正常和非正常条件下的执行过程 用 UML 建模工具画出用例模型图 编写用例模型图的补充说明文档 系统用例模型 确定系统目标：干什么，不干什么； 确定角色：谁要与系统对话； 确定未来系统与其他企业、系统、构件或用户接口 。 建模操作 业务用例模型 业务用例建模是对系统用例建模的一种细化； 业务用例建模主要要识别低级用例和顶级用例之间的关系； 方法：将每一个用例分解成更小的过程， 直到完成所有内部机制的描述。（活动图） 用例描述 用例编号 用例名称 参与者 : 触发用例的角色、 系统、时间 前置条件：用例执行前必须满足的条件， 如果不满足条件， 用例不被执行 后置条件：在用例结束时，系统必须所处的状态 基本事件流 ：主路径 可选事件流 ：不是经常发生的路径 异常事件流 ：发生错误时的路径 活动图建模 用例图中各用例的工作控制流描述除了可以用文本外，对于复杂的工作控制流用活动图描述更直观； 活动图可以描述系统有哪些动作（活动）、做了什么（对象状态改变）、何时发生（动作序列）、何处发生（泳道）。 活动图是用例的细化； 通过活动图建模可以补充、完善用例图。 建模过程 按主路径建模； 添加从路径； 添加泳道； 建模操作 类图建模 类是现实世界的对象（事物）经过分类、归并、抽象后得到的概念； 类中对象共有的特征和操作就是类的属性和操作（具体对象还可以有自己特有的）； 3种不同的类： 实体类：系统中需要持久保存的对象，要映射到数据库中 与系统有关的外部实体：角色，系统、I/O设备等 系统要管理的实体：如货物、车辆、仓库等 概念性实体：如单据、报告、报表等 类 边界类：系统与外界的交界处，各种I/O类 用例图中的每对角色--用例之间必需一边界类 活动者通过边界类操作系统 控制类：控制其它类工作的类。 边界控制类 用例控制类 类图建模步骤 识别实体类； 根据常识、问题域、系统责任确定该类有那些属性； 补充该类动态属性，如状态、对象间联系（如聚合、关联） 等属性 ； 从需求中的动词、 功能或系统责任中寻找类的操作； 从状态转换， 流程跟踪、系统管理等方面补充类的操作； 对所寻找的操作在类间进行合理分配（职责分配），形成每个类候选操作。； 补充每个类的的分析文档， 为类的进一步设计打下基础。 实体类识别方法 名词识别法： 从系统（用例模型、活动图模型等）描述中找出名词、名词短语或名词性代词，因为它们往往对应着对象（类）； 一般单数名词可以识别为对象，而复数名词则可以识别为类； 不是每个名词都对应着一个对象，可能有的名词只是其他对象的一个属性； 考察是否有与该对象（类）相关的身份和行为，即是否可以加动词。 入库管理中的类 名词识别 外部实体名词：库管员、采购员、验收员、来料单位、采购管理子系统 概念性实体：各种单据 管理对象实体：货物、货位、仓库 类 采购员、库管员、验收员、货物、仓库、货位、验收单、入库单 定义类的属性 属性名 别名 可见性 数据类型 默认值 备注 货物编号 public S no default 货物名称 public S no default 型号规格 public S no default 计量单位 public S no default 尺寸 public S no default 重量 public N no default 类名：货物类 定义类的操作 类名：入库单类 操作名 别名 可见性 参数 返回值 备注 新建 private 入库单编号 boolean 修改 private 入库单编号 boolean 暂存 private 入库单编号 boolean 提交 private