全程一体化建模过程与要领.ppt

第10章 全程一体化建模过程与要领,（时间：3次课，6学时）,教学提示：前面用六章篇幅围绕全程一体化建模工具PlayCASE的操作方法进行了讲述，从本章开始，将结合案例讲解PlayCASE在软件项目开发过程中的实际应用。在通过案例介绍之前，首先讲解如何运用该工具和软件工程的理论进行建模的过程和方法，介绍与建模有关的概念、建模技术和要领。 教学目标：掌握业务建模过程、主要环节、主要指标，掌握整个建模过程中需要用到的几个主要的基本建模图形，以及它们之间的集成关系，了解PlayCASE的应用要领。,第10章 全程一体化建模过程与要领,第10章 全程一体化建模过程与要领,10.1 业务建模过程 10.2 业务建模图形 10.3 业务调查 10.4 需求定义 10.5 总体设计 10.6 详细设计 10.7 生成程序 10.8 PlayCASE的应用要领 10.9 习题,10.1 业务建模过程,10.1.1 业务流程设计 10.1.2 业务建模 10.1.3 业务模型集成关系 10.1.4 基本建模方法 10.1.5 建模的主要指标 10.1.6 建模的主要文档,10.1.1 业务流程设计,1. 业务建模与流程设计的关系 首先，通过业务建模可以提供一个一致的业务表现形式，提供一种交流的手段，使得工作人员能更好地描述业务与表达需求，使软件开发人员更容易理解客户单位的日常办公业务，为更好地描述已有流程和明确需求奠定基础。其次，业务建模技术帮助工作人员和软件开发人员建立详细的业务模型，实现业务过程分析和设计的可视化，为规范与改进业务流程提供基础素材，可降低信息化项目的实施成本，提高信息化项目的效益。,10.1.1 业务流程设计,2. 业务流程设计过程的层次框架 图10.1表示了业务流程设计过程的层次框架，它由业务模式持续改进、建模主要环节、建模过程以层次化的方式构成。 图10.1 业务流程设计过程的层次框架,10.1.1 业务流程设计,3.业务流程设计的目的及原则 建模目的 在描述现有业务流程的基础上，对流程进行规范与改进 将未来的流程表达清楚，为开发人员提供清晰、可识别的业务流程，为相应的软件系统开发打下坚实的基础,10.1.1 业务流程设计,建模原则 业务流程设计强调工作人员的全程参与 围绕结果而不是职能进行设计 业务流程改进是一项持续进行的工作,10.1.1 业务流程设计 10.2给出了业务流程设计与业务持续改进的关系。 图10.2 业务模式持续改进示意图,10.1.1 业务流程设计,4.业务模式持续改进的方法 确定信息化的范围； 建立信息化的目标； 确定和提供实现信息化目标必须的资源； 描述现有业务流程； 分析现有业务流程； 规范与改进业务流程； 业务流程信息化； 进行业务持续改进。,10.1.2 业务建模,1. 参加业务建模的人员 无论是在对现有的业务进行建模，还是对未来的业务进行建模，涉及到的主要人员可 分为业务领域专家、业务分析员和软件开发人员3种。其中，业务领域专家是具备一定业务管理知识与管理实践经验的人员，业务分析员是进行业务建模工作、整理业务对信息化的需求、形成建模文档的人员，软件开发人员是接受建模文档并进行软件设计、编程等软件开发工作的人员。,10.1.2 业务建模,2.业务建模的主要环节 确定建模范围和业务框架； 通过调查收集业务素材进行分析； 利用基本建模过程建立业务模型； 根据主要建模指标对模型进行评审； 完善和完成整个业务模型（包括需求定义），形成文档。,10.1.2 业务建模 图10.4、图10.5分别给出了无角色和有角色的业务建模主要环节的示意图。,图10.4 无角色的业务建模主要环节示意图,10.1.2 业务建模,图10.5 有角色的业务建模主要环节示意图,10.1.2 业务建模,在确定建模范围时，一定要有主要负责人参与到项目组,在所确定的建模范围中，决定组织的哪一部分将变成哪些业务的发起者，每种业务将形成若干业务流程，这些业务构成业务种类框架。,在这个范围中，业务建模的对象是：,(1)确定建模范围和业务种类框架,10.1.2 业务建模,(2) 通过调查收集业务素材进行分析 收集业务素材的主要步骤是： 业务分析员制订比较详细的调研表格； 发放给业务领域专家； 业务领域专家填写调研表格，并将自己所做的业务描述清晰； 业务分析员收集调研表格，进行下一步建模工作。,10.1.2 业务建模,(3) 利用基本建模过程建立业务模型 通过运用“基本建模过程”，根据收集的调研表格和根据与业务领域专家的交流，得到业务模型： L 业务组织、职责结构描述 L 业务流程建模 L 业务信息内容和处理权限描述,10.1.2 业务建模,(4) 根据主要建模指标对模型进行评审 评审工作的依据：建模的主要指标 由业务领域专家对模型进行评审 确定业务过程是否正确 结合实际，改变现有业务流程,10.1.2 业务建模,(5) 完善和完成整个业务模型，形成建模文档 根据建模的原则和基本建模过程，不断地根据业务要求建立业务模型，同时通过不断地评审对模型进行确认，以逐步求精的方式构造最终的业务模型。 建模结束时，应该得到包括主要建模图形、相关业务解释的主要文档。,10.1.3 业务模型集成关系 1.业务模型的构成,由基本建模图形和 派生建模图形组成,功能调用树,事件接口图,数据流图,数据接口图,信息内容/关系图,职责执行流程图,业务协作流程图,组成结构树,推,导,基,本,图,形,派,生,图,形,10.1.3 业务模型集成关系 2. 基本建模图形之间的集成关系,交接工作,相关业务信息,工作交接事件,相关业务信息,组织,部门1,部门2,部门3,岗位A,岗位B,岗位C,职责1,职责2,职责3,活动步骤1,活动步骤2,活动步骤3,岗 位 A,活动步骤A1,活动步骤A2,活动步骤A3,岗 位 B,岗 位 C,活动步骤B3,活动步骤B1,活动步骤B2,活动步骤C1,组成结构树 职责执行流程图,业务协作流程图 业务信息关系图,工作交接事件,相关业务信息,业务信息a,栏目 a1,栏目 a2,业务信息b,栏目 b1,栏目 b2,开始,活动步骤1,活动步骤2,活动步骤3,结束,10.1.4 基本建模方法,1. 以职能分工分析为出发点的建模方法 以职能分工分析为出发点的建模方法是根据业务建模的实际需要，从一个单位的组织分工描述开始，完成对这个单位业务描述。它主要有两种流程分支：第一个分支是描述组织分工、描述业务信息、描述业务流程，第二个分支是描述组织分工、描述业务流程、描述业务信息(见图10.9)。 图10.9 以职能分工分析为出发点的建模过程,10.1.4 基本建模方法,2. 以业务流程分析为出发点的建模方法 以业务流程分析为出发点的建模方法是根据业务建模的实际需要，从业务流程的描述开始，完成业务建模工作。它主要有两种流程分支：第一个分支是描述业务流程、描述业务信息、描述组织分工，第二个分支是描述业务流程、描述组织分工、描述业务信息，如图10.10所示。 图10.10 以业务流程分析为出发点的建模过程,10.1.5 建模的主要指标,1. 描述组织结构和组成的主要指标 组织结构和组成的主要指标如下： 将需要规范化管理的部门及与之有业务联系的部门列举出来； 将上述需要规范化管理的部门中的岗位列举出来； 将上述需要规范化管理的岗位中的职责列举出来； 将上述需要规范化管理的职责中的活动步骤列举出来； 将上述活动步骤分解成子活动步骤，到对业务信息栏目逐条处理的程度； 将上述处理业务信息栏目的活动步骤所体现的处理方法继续分解成子活动步骤，直到新员工上岗培训所能理解的程度。,10.1.5 建模的主要指标,2. 描述业务流程的主要指标 业务流程的主要指标如下： 列举出所有业务流程的名称； 以担负职责的角色、岗位、部门为活动主体，以按业务发展的顺序描述角色间的业务往来事件； 以业务流程中发生的事件为主线，按业务流程顺序描述业务往来事件及其携带的业务信息； 充分体现分工组成结构中的职责或活动步骤； 将活动步骤所体现的处理方法继续分解成子活动步骤，直到基本不能细分为止； 描述各级活动步骤之间的逻辑流程关系。,10.1.5 建模的主要指标,3. 描述业务信息的主要指标 业务信息的主要指标如下： 业务信息按单位和角色分别进行描述； 描述业务信息的所有栏目； 按业务信息在栏目级别上整理其操作权限读取、修改、删除等； 按业务分类整理所有业务信息的共享情况； 描述信息之间的联系。,10.1.6 建模的主要文档,1. 描述组织分工的建模文档 该建模文档应该包括以下两方面的内容： 反映一个组织中上下级关系的组织结构图以及相关描述； 反映一个组织中层次化职能分工分解的组成结构树以及相关描述。 2. 描述业务流程的建模文档 该建模文档应该包括以下两方面的内容： 反映宏观业务联系的业务协作流程图以及相关描述； 反映微观业务操作的事件流图以及相关描述。,10.1.6 建模的主要文档,3. 描述业务信息的建模文档 该建模文档应该包括以下两方面的内容： 反映业务信息内容及其联系的业务信息关系图以及相关描述； 反映业务信息基本流向的数据流图以及相关描述； 反映活动主体之间信息交互的数据接口图以及相关描述； 反映活动主体操作信息的业务信息操作权限图以及相关描述。 4. 描述信息化需求定义的建模文档 基于组成结构树的信息化功能定义、过程定义，以及相关描述。,10.2 业务建模图形,10.2.1 描述组织分工的建模图形 10.2.2 描述业务信息的建模图形 10.2.3 描述业务流程的建模图形,10.2.1 描述组织分工的建模图形,组成结构树是描述业务分工的建模图形是一个组织的分工及层次关系的一种体现，其特点是： 它描述的组成关系，不是组织结构图描述的上下级关系； 它精细地描述了业务工作，体现了分工责任化。,10.2.1 描述组织分工的建模图形,以下是在描述组成结构树时应注意的问题及其原则： 1. 机构中的部门组成 2. 部门中的岗位组成 3. 岗位中的职责组成 4. 岗位职责中的活动步骤组成 5. 组成结构树的拆分 6. 活动单元的编码规则 7. 分工组成的分解原则 8. 分工组成的描述范围 9. 活动单元类型划分的相对性,10.2.2 描述业务信息的建模图形,1. 业务信息关系图 业务信息关系图主要涉及到对信息关系的描述。在PlayCASE中，分别用计算组装链、分类链和连接链等实现对信息关系的描述。 业务信息主要由信息的名称、信息栏目组成。 2. 业务信息与组织单元作用关系建模图形 业务信息与组织单元作用关系可以用数据接口图、数据流图来表示，这些建模图形可以由组成结构树、事件流图、业务协作流程图、信息/表单关系图导出。,10.2.3 描述业务流程的建模图形,1. 业务协作流程图 业务协作流程较事件流图(功能执行流程)更侧重于宏观描述，体现业务人员之间的工作交互关系。 (1) 业务种类与业务协作流程的分类 业务管理是结合“责、权、利”来进行的，每种业务按部门或岗位具体展开，形成了业务流程(业务协作流程)，所以划分业务协作流程种类与划分业务种类几乎是同义语。ISO 9000的质量活动要素的概念为业务类别划分提供了很好的框架。,10.2.3 描述业务流程的建模图形,(2) 业务协作流程图的内容 业务协作流程图用于描述部门或岗位之间的工作协作流程，其绘制要点是： 明确参与协作的活动主体，活动主体最好是岗位，如果是部门，那么它们之间的业务协作还有很大的不确定性； 体现PDCA质量环，保证过程内容的完整性，其中P代表计划(Plan)，D代表执行(Do)，C代表检查(Check)，A代表处置(Action)； 明确开始事件、结束事件； 确保事件链一环紧扣一环，流程不中断； 明确伴随事件的业务信息。,10.2.3 描述业务流程的建模图形,2. 事件流图(功能执行流程图) 在采用不同的建模过程时，尽管使用的是同一种建模图形，但使用顺序和描述方法不尽相同，而得到的业务模型应当是一样的。如以职能分工分析为出发点的建模过程首先描述组成结构树，随着建模的不断进展，这样在业务流程描述以及在业务信息描述时，对组织情况的描述要求就可以减少。利用主要的建模图形基本可以表示出业务模型，如果需要对主要建模图形进行进一步补充，则需要利用辅助建模图形进行描述。例如数据接口图等。,10.3 业务调查,1填写业务调查表 这是了解用户业务的第一步。该表是描述组织机构的组成结构树及描述业务流程的事件流程图的依据。 岗位设置、责任(往往“挂”在墙上) 业务报表/信息(往往“摆”在桌子上) 所需软件(可在需求定义阶段与用户共同确定),10.3 业务调查,2描述组织结构 用户的业务组织结构是我们认识了解其业务的最佳向导，PlayCASE用组成结构树来表示它。 划分组织结构的一般原则： 第0层：企业自身 第1层：企业的业务部门类别（如生产经营部门等） 第2层：具体的业务处室（如销售处等） 第3层：业务处室所设的业务岗位（如财务处的记帐员、成本会计等） 第4层：每个岗位的工作职责（如成本会计要核算生产成本、核算销售成本等）。,10.3 业务调查,3准确捕捉业务流程，全面搜集业务信息（数据） PlayCASE用事件流程图描述业务流程，其方式是沿组成结构树自上而下，从整体到部分。 对用户业务流程的调查应该从划分业务流程种类开始。划分依据：一个业务流程由一组联系紧密的业务活动组成。 通过经验丰富的用户提供的业务的各种细节，无一遗漏地捕捉到用户进行业务活动时产生的各种业务数据，这些数据往往体现为报表、票据等，它们可以用于生成数据流程图(DFD)。,10.3 业务调查,4归纳业务部门间的活动 PlayCASE根据事件流程图，用事件接口图自动归纳业务部门间的业务活动。 事件接口图和事件流程图一一对应，它按层次来表达业务部门（人）之间的业务分工，集中反映了各个部门（人）的业务活动。 从宏观上把握和认识企业的业务划分与工作职责。,10.3 业务调查,5归纳业务部门间交换的业务信息 PlayCASE根据事件流程图中事件所携带的数据，用数据接口图自动归纳业务部门（人）之间的信息交互。 数据接口图和事件流程图一一对应，按层次来表达企业内部的信息界面，说明信息的由来和去处。 从整体上把握和认识企业进行业务活动时所交互的信息。,10.3 业务调查,6描述业务数据的具体内容 在事件流程图中捕捉到的业务数据，PlayCASE用“信息/表单” 来描述，可从两方面深入认识： 业务数据的具体内容（现阶段考虑） 业务数据间的联系(总体设计阶段考虑) 如果业务数据种类较多，为了保证调研的效率，在业务调查阶段可以采取折衷方式： 不描述业务数据的具体内容 只描述关键部分 保留原始材料（数据） 忽略部分应当在总体设计时补充。,10.4 需求定义,1.确定哪些业务需要计算机软件 在业务调查的基础上，用组成结构树定义软件的基本结构：每个节点由业务部门和支持它的计算机软件组成。 组成结构树应当分解到：凡是需要计算机软件的部门，分解到每个业务岗位的工作职责。 一般来讲，业务调查很难一次彻底完成，往往贯穿整个开发过程。,10.4 需求定义,2.描述软件系统的运行模式 PlayCASE用事件流程图描述未来软件的总体行为，它是真实业务的仿真。这种直接支持日常业务活动的软件最容易被用户接受。,10.5 总体设计,1.描绘软件的全部结构 明确结构树中哪些节点是子系统，哪些节点是功能（模块），其判断可以综合两方面因素： 支持业务部门或业务岗位的软件，可以视为子系统，替代业务岗位某项职责的软件可以视为功能（模块） ； 单个运行的软件（可执行文件）可以视为子系统，反之为功能（模块）。 在此基础上，根据用户实际业务的需要，对现有结构树的末级节点进行适当的功能分解。,10.5 总体设计,原则 功能分解要尽可能根据用户的业务活动规则进行，按照国家制度规定进行。 功能分解程度最好对应到“原子”级业务活动。 从某种意义上来说，这种分解是需求分析的深化。,10.5 总体设计,2.描述软件的总体运行过程 在需求定义的基础上，根据组成结构树所做的功能分解，把事件流程图进一步向下逐层展开，来描述软件的总体运行过程。,10.5 总体设计,3.划分软件的功能界面 PlayCASE根据上述事件流程图，用事件接口图自动归纳子系统（或模块）间的功能交互。 事件接口图和事件流程图一一对应，按层次来表达软件内部的功能界面，说明哪些功能由哪些子系统（模块）来完成。 从宏观上把握和认识系统每部分所具备的各种功能。,10.5 总体设计,4.划分软件的数据界面 PlayCASE根据事件流程图中事件所携带的数据，用数据接口图自动归纳子系统（模块）间的信息交互。 数据接口图和事件流程图一一对应，按层次来表达软件内部的数据界面，说明信息的来源和去处。 从整体上把握和认识系统运行时所交互的信息。,10.5 总体设计,5.描述信息流动情况 数据流图用于描述信息流动的情况 在纵向表示了函数分解关系 在横向上表示了数据依赖关系 和事件流程图一一对应 在系统开发的任何阶段都可以得到数据流图,10.5 总体设计,6.归纳上下级模块的数据传递 PlayCASE提供的功能调用树与软件工程教科书所讲的结构图是一致的。 组成结构树的所有节点视做软件的模块 父级模块调用子级模块完成有关功能 集中反映父级模块传递给子级模块的数据和子级模块返回的数据,10.5 总体设计,7.进行数据库的概念设计 补充业务调查时业务数据（信息/表单）的具体内容被忽略的部分。 指定数据属性值的基本类别（如数字型、字符型、时间型等） 属性值的具体类型（如数字型中的整数、浮点数等），可以在详细设计中确定，因为在总体设计时，并不需要考虑实现系统所使用的编程工具和DBMS。,10.5 总体设计,8.描述数据（信息/表单）间的相互关系 信息/表单关系图包括了实体关系图的全部内容 三种数据关系：组装关系、分类关系、关联关系 由业务数据本身的性质或者根据业务活动找到这些关系 全面建立所有数据的关系，尽可能消除孤立数据,1设计用户界面及其运行序列 2进行数据库的逻辑设计 3进行数据库的物理设计 4设计模块 5. 生成程序,10.6 详细设计,10.6 详细设计,1.设计用户界面及其运行序列 设计每个子系统的所有用户界面。 典型的用户界面有如菜单、对话框、Form（窗体）等。 给出这些界面的运行序列，形成用户界面原型系统，预演未来软件系统的运行模式。,10.6 详细设计,2.进行数据库的逻辑设计 定义信息/表单的键字（包括主键、外键和候选键），保持数据一致性； 确定实现信息/表单具体的DBMS或编程语言； 定义信息/表单属性值的具体类型； 建立交叉表，消除多对多的连接关系； 信息/表单应当符合第3范式，至少要达到第2范式，消除更新异常情况。,10.6 详细设计,3.进行数据库的物理设计 定义信息/表单的索引，优化数据检索； 垂直分割信息/表单，优化数据存取； 定义视图、查询，为编程提供方便; 定义信息/表单的方法。,10.6 详细设计,4.设计模块 用伪码（一种规范的结构化模块设计语言）（事件流程图中的【 Pcode】） PAD（问题分析图）设计每个模块的运行过程。（岗位说明书中的【工作职责】 ）,10.6 详细设计,物理数据库的设计 理解应用类型 使用定量评估 理解存储分层结构 理解DBMS中的瓶颈 选择平台 物理设计原则与常规硬件设计建议,10.6 详细设计,理解应用类型 操作类型 只读: SELECT操作； DML：Insert，Update，Delete操作。 应用类型 OLTP、DSS、批作业处理、OLAP、VCDB,10.6 详细设计,应用类型 （1）OLTP（联机事务处理）是一个包含繁重DML的应用。 （2）DSS（决策支持系统）通常是一个大型的、包含历史性内容的只读数据库，通常用于简单的固定查询。 （3）批作业处理批作业处理系统是作用于数据库的非交互性的自动应用。通常含有繁忙的DML语句并有较低的并发性。 （4）OLAP（联机分析处理）可提供分析服务。包含大量计算。有时是OLTP和DSS模型的交叉。 （5）VCDB（可变基数数据库）通常被用作一个处理系统的数据库后端。在数据处理期间，数据库中的表显著地增长或收缩。,10.6 详细设计,使用定量评估 事务分析 * 并发用户数目 * 响应时间 * 经过的时间 * 事务数目 * 并发程序的数目 * 读或写的字节数 筛分分析 表有多大,10.6 详细设计 理解存储分层结构,10.6 详细设计,RAID RAID（冗余廉价磁盘阵列）是一组能并行工作的磁盘。能够减少I/O时间，通过数据条技术来实现并行工作。 1RAID 0没有校验的基本数据条。 特点：速度快，但无校验。适用于tempdb。 2RAID 1是传统的，硬件级的磁盘镜像。两部分磁盘是同时写的。 特点：可靠性最高。写较慢、读快、贵、没有数据条状化的内部机制。 3RAID 5带有校验的数据条。它将校验信息与数据一起保存在所有磁盘上。校验信息和数据一样受到保护。 特点：可靠性较高、写慢。 4使用RAID设备的考虑： 造价、性能、可靠性； 数据和日志使用不同的RAID设备。,10.6 详细设计,理解DBMS中的瓶颈 1网络； 2对DSS、VLDS来说，硬盘的I/O尤为突出； 3OLTP和OLAP内存和CPU 较突出。,10.6 详细设计,选择平台 1Intel公司的微机系列和Sun公司的Solaris系统； 2Windows NT Unix：支持多CPU 3Oracle 9i SQL SERVER 2000 Sybase,10.6 详细设计,物理设计原则与常规硬件设计建议 1设计原则 2硬件设计： 主要目标是消除或减少竞争。,10.6 详细设计,1设计原则 分而治之：分区、分段和并行。 预分配和预编译：静态分配和固定分配。即提前分配你的资源。 前摄：预测主要的问题。 批量、块和批处理：使用大量传送。即持有着相同的起源和终点的I/O操作组合在一起。 合理地分割应用：客户/服务器的分工要合理。,10.6 详细设计,2硬件设计 把表和索引分开； 把大的表和索引段放到它们自己的盘上； 把经