MIS系统开发的原型法.ppt

第11章 MIS系统开发的原型 法 11.1 原型法概述 1.1.1 导致原型法产生的结构化生命周期法的 不足之处 1.前提不符合实际：结构化生命周期法要求用户在未见 到实际运行的系统之前就能够靠规格说明书来清楚的一 劳永逸的表达对要开发的系统的需求，这往往不；人的 认识规律。 2. 开发周期长且难使用环境变化：结构化生命周期法 使用工具效率低，要形成许多冗长的文档，导致开发周 期长且难使用环境变化。 3. 很难调动用户参与系统开发的积极性：”务虚“阶 段长，用户长期看不到实际运行的系统，阻碍了用户参 与。 4. 各阶段之间不允许有反复：各阶段使用完全不同的 模型，阶段之间反复困难，只适于瀑布式前进。 11.1.2 原型法的一般工作过程 1.原型法的概念：在对用户需求作简要分析后，就快速 地建立系统的原型，使用户能通过实际试用原型系统来 认识优势与不足，多次反复地参与原型改进，直到得到 满意的系统。 2.原型法的一般工作过程（如下页所示） 用户提出要求 识别归纳问题 开发系统原型 分析评价 不可行处理 不满意处理 修改 试运行 图11.1 原型法的工作过程 3. 原型法的软件支持环境 n一个方便灵活的关系数据库系统（RDBS）提供设计 上和存取上的方便，允许直接进行数据的模型化和简 化程序开发。 n一个与RDBS相对应的方便灵活的数据字典，它具有 存储所有实体的功能，用于存储所有系统实体的定义 和控制信息。 n一套与RDBS相对应的快速查询系统，能支持任意非 过程化的（即交互定义方式）组合条件查询，且能将 查询结果保留，并和字典溶为一体。 n一套高级的软件工具（如4GL或信息系统开发生成环 境等等）用以支持结构化或面向对象程序，并且允许 采用交互的方式迅速地进行书写和维护，产生任意程 序语言的模块。 n一个非过程化的报告或屏幕生成器，允许设计人员 详细定义报告或屏幕输出样本。 n原型人员工作台：提供原型开发人员使用，具有交 互功能，使用方便，并能产生反馈信息的工作站。 基于上述这些软件支持工具，“原型”可以快速生成 ，可以快速地测试，即可以测试新的构思、新的设想的 好坏优劣。对于想法、概念、观点和要求的正确性，都 可以在原型实验室中加以验证。这就是原型技术目前越 来越广泛存在于各种形式的开发活动中的主要原因。 11.1.3 原型法的特点与适用范围 1原型法的特点 n原型法更多地遵循了人们认识事物的规律，因而更容 易为人们所普遍接受。 v人们认识任何事物都不可能一 次就完全了解并把工作做得尽善尽美。 v认识和学习的过程都是循序渐 进的。 v人们对于事物的描述往往都是 受环境的启发而不断完善的。 v人们批评指责一个已有的事物 ，要比空洞地描述自己的设想容易得多 ，改进一些事物要比创造一些事物容易 得多 n原型法将模拟的手段引入系统分析的初期阶段，沟 通了人们的思想，缩短了用户和系统分析人员之间的 距离，解决了结构化方法中最难于解决的一环。 v所有问题的讨论都是 围绕某一个确定原型而进行的，彼 此之间不存在误解和答非所问的可 能性，为准确认识问题创造了条件 。 v有了原型后才能启发 人们对原来想不起来或不易准确描 述的问题有一个比较确切的描述。 v能够及早地暴露出系 统实现后存在的一些问题，促使人 们在系统实现之前就加以解决。 n充分利用了最新的软件工具，摆脱了老一套工作方 法，使系统开发的时间、费用大大减少，效率等方面 都大大地提高。 n原型法可以提供很好的项目说明和示范，简化了项 目管理。 n原型法可以接受需求的不确定性和风险。 2原型法的适用范围 作为一种具体的开发方法，它有一定的适用范围和 局限性。主要表现在： n对于一个大型的系统，如果我们不经过系统分析来进 行整体性划分，想要直接用屏幕来一个一个地模拟是 很困难的。 n对于大量运算的、逻辑性较强的问题，原型法很难构 造出模型来供人评价。 n对于基础管理不善、信息处理过程混乱的问题，使用 有一定的困难。 n对于一个批处理系统，其大部分是内容处理过程，这 时用原型方法有一定的困难。 原型方法是在信息系统研制过程中的一种简单的 模拟方法，与人们不经分析直接编程时代以及结构化系 统开发时代相比，它是人类认识信息系统开发规律道路 上的“否定之否定”。它站在前者的基础之上，借助于新 一代的软件工具，螺旋式地上升到了一个新的更高的起 点；它“扬弃”了结构化系统开发方法的某些繁琐细节， 继承了其合理的内核，是对结构化开发方法的发展和补 充。这种相互补充、相互促进的系统开发方式将会是今 后若干年信息系统或软件工程中所使用的主要方法。 11.2 增长原型法 11.2.1 抛弃原型法 建立这种原型系统的目的，是评价目标系统的某个 （或某些）特性，以便更准确地确定需求，或者更严格 地验证设计方案。使用完之后就把这种原型系统抛弃掉 ，然后再重新建立正式的目标系统。这种途径本质上仍 属于传统的瀑布模型（Waterfall Model），建立原型 只不过是一种辅助性的步骤。 11.2.2 演化原型法 经过初步调研和分析获知用户的基本需求之后，就 利用适当的软件工具（如4GL）快速地实现一个原型系 统，作为沟通各方的基础和用户实践的场所，开发人员 根据用户试用后的意见，对原型进行修改和扩充，然后 再次交给用户试用，并根据试用后提出的意见，再次对 原型进行修改和扩充，这样，经过多次迭代直到用户满 意为止。 11.2.3 增长原型法 把系统划分为若干个子系统。选择其中一个作为首 期工程，用演化原型法开发这个子系统；再选择另一个 与之相关的子系统作为二期工程，在首期过程开发的子 系统的基础上，用演化原型法增加二期工程的子系统需 要的信息与功能，并把它们集成为一个整体；这样一期 期地推进，直到完成整个系统的开发。 可见，增长原型法先要把系统开发划分为若干期工 程，每期工程从首轮开始，有要有若干轮的演进。每期 内采用的是螺旋模型，一期期向前推进则形成渐增模型 。 螺旋模型的原型开发方法如图11.2所示。 图11.2 螺旋模型的原型开发过程 按照螺旋模型，整个系统（软件）开发项目始于 螺旋中心，然后绕着中心做360的旋转，每旋转一周 便得到一个原型版本，对整个系统而言则是开发过程中 的一个步骤。这种不断的旋转可以大量节省开发和维护 的时间和费用，因为下一个版本总是在上一个版本的基 础上加上改进和维护的结果。这种通过不断地螺旋式旋 转、反馈、修改与完善来完成最终版本的途径，正是 4GL与螺旋式应用开发系统的目标。 使用渐增模型开发系统的过程如下： 完成一部分分析工作； 完成一部分设计工作； 完成一部分程序设计工作； 建造系统原型并评价； 对另一部分重复上述过程。 11.3 快速原型法的开发工具 建立原型的计算机辅助软件工程（CASE）工具除了 RDBS外主要有： 屏幕绘图程序（屏幕生成器） 报告生成程序（报表生成器） 菜单建立程序（菜单生成器） 第四代程序生成语言（4GL） 可执行的规格说明语言 n4GL可以用来开发更为完整的系统模型，在这种情况 下，原型包括了系统的主要功能，但不检查例外情 况或无效的输入数据，也不考虑执行的性能，其目 的是通过使用相对完整的原型，让用户具有使用该 系统的经验。 n可执行的规格说明语言是最复杂的原型建立工具， 它把系统开发变成一个迭代过程，在这个过程中， 系统得到描述，执行该规格说明能够判断系统是否 完整与正确。然后，根据使用这个原型的经验对规 格说明重新定义后再重新执行。迭代过程就这样继 续下去，直到系统满足了所有的用户需求。 n现在的应用中，尤其是在C/S模式MIS的开发与研制 中，一般是先快速地建立一个图形用户接口（GUI） ，作为系统的初始原型，通过用户的不断反馈、反 复与累增、逐步地建立起符合用户需求的新MIS。 11.3.1 可视化 科学计算可视化（Visualization in Scientific Computing）是运用计算机图形学和图象处理技术，将 科学计算过程中产生的数据及计算结果转换为图形或图 象在屏幕上显示出来。它不仅包括科学计算数据可视化 ，而且包括工程计算数据的可视化；同时也包括测量数 据的可视化. 程序设计可视化（Visual Programming）是指用图 表、随手画的素描、图标或图象等可视表达式来编制程 序。运用这类可视表达式时所用的技术手段有以下三项 ： n“点击”：例如，Windows中点File菜单，File的下 拉菜单项。 n“剪贴” （Cut and Paste）或“抄贴” （Copy and Paste）： “剪贴”，例如，Windows中剪一个 图标，再把这个图标粘贴于另一处； “抄贴”，就 是抄录板（Clipboard）的操作。 n“拖放” （Drag and Drop）：例如，Windows中把 一幅图从屏幕的一边拖到另一边。 一个程序设计语言的语法若用到这种可视表达方式 ，这个语言就叫可视程序设计语言（Visual Programming Language，VPL）。一个可视程序设计环 境（Visual Programming Environment，VPE）提供可 视的方法来使用一种语言，不管这个语言是可视的，还 是文字的。 不少可视技术已被吸收到一些支持文字程序语言 的VPE之中，而且跟着也用于 nGUI程序设计； n图象描述关系和数据结构行为； n可视地把文字编程而得到的各部分，组建成新的程 序。 Microsoft的Windows就是GUI程序设计的最有名和最有 用的例子。 11.3.2 速成化 速成应用开发（Rapid Application Development， RAD），简称为速成化，是从联合应用程序设计（Joint Application Design，JAD）演变而来的： n做到JAD原来要求的把用户需求快速明确提出来 nCASE工具 n原型技术 n一支能突击完成任务的队伍 n有一套能快速实现用户要求的形式化软件研制方法 ，包括可视程序设计方法和技术。 RAD的实际做法是：在初步掌握用户要求后，立即实现 （建库与编程，目前的做法是可视建库与编程）。在此 过程中，反复分析与设计是通过与用户共同参与来完成 的。 目前推行的RAD实际上有两方面内容： n联合应用程序设计（JAD）， n速成迭代原型法（Rapid Iterative Prototyping， RIP）。 这两方面结合使用，表示RAD是面向用户的。JAD讨 论和RIP结合使用的目的，是使用户在整个研制周期中 成为积极的参与者，从而保证系统符合所有要求。JAD 的反复讨论缩短需求分析与设计的进行过程，而RIP会 加速编程过程。这同时表示具有JAD和RIP两方面的RAD 实际上包含分析、设计与实现（编程）三阶段，不过在 RAD下整个的开发周期缩短了。 RAD往往是可视的，它最拿手的一招是一套可视程 序设计工具，能快速建成合格的图象用户接口（GUI） 。从RAD发展到现有阶段来看，需要弄清它做得好或甚 至很好的是哪些，哪些做得不好或者不能做。 11.3.3 组件化(Components ) 组件软件基本思路是，系统的开发可以用现成的预 制软件组件来组装。象硬件系统可用集成电路等元器件 来“即插即用”（Plug and Play）组装一样，最后软 件系统也能象硬件一样，用所需的一套软件组件“即插 即用”组合起来。 复合文书是其特例，即以一个空文书为容器，把不 同来源的组件组装在其中。 组件软件可以做到少编程序，而且能快速地把待制 的应用搞出来。组件软件的好处可概括为：可重用、能 交互操作、易于使用、有灵活性、可加工改造以及有规 模的伸缩性。 现行的组件可分为五种类型： nGUI组件（GUI Components）：它扩充研制工具，建 立GUI的能力。 n逻辑组件（Logic Components）：它提供非可视的 计算能力、图象编辑等。 n垂直组件（Vertical Components）：它对某一具体 产业提供数据和逻辑，类似于小型应用。 n容器组件（Container Components）：它提供一骨 架，把各类定制的控件装填进去。 n中间组件（Middleware Components）：它便于与网 络、交易监督程序或DB的交互操作。 组件可在下列三种环境中使用: n某一具体应用研制环境 n一种应用的平台 n一种对象标准 目前的使用情况是应用开发环境占领先地位，大 多数组件是属于Visual Basic/ActiveX之列。 组件软件（Compound Software）与复合文书（ Compound Documents）：所谓文书中心，即编程以文 书为中心，而不象以应用（例如，库存管理）为中心 的程序设计。以文书为中心时，用户不是启动一个应 用，然后打开文件，而是直接打开文书。实际上一个 组件是一个预制的小型应用程序，组件软件与复合文 书把不同的预制的小型应用程序集成在一起。因此说 它是文书中心的，不是应用中心的。 组件软件与复合文书同时也是可视的，往往也是 速成的。就目前组件工艺而言，组件的来源有三： n装配组件的研制工具都能提供组件框架。 n专门制造组件框架的软件厂商。 n用户自制组件。 11.4 原型法系统开发实例 本节以数据库（DB）设计为中心，使用Visual FoxPro（VFP）6.0，对某商业企业以其仓库的进、销、 存信息系统为第一期工程，讨论用原型法开发首轮原型 的具体过程。 这里把系统分析与设计做得比较规范，叙述也是 直线推进，是为使学生把握全貌。原型法的各轮开发都 是只要做概略分析与设计就动手实现，并且是不断反复 而非直线推进的。 11.4.1 系统首轮概要分析 概述：仓库进、销、存（进货、销售、存储）管理是商 业企业经营管理中的核心环节，也是一个企业能否取得 效益的关键。建立仓库进、销、存信息系统的目的是使 企业能做到合理进货、及时销售、库存量最小、周转灵 活、没有积压，使企业取得最好的经济效益。 一. 需求初步分析 1. 组织结构概况 通过调查研究，得出该商业企业的组织机构图如图 11.3所示，图中只简单地给出与仓库进、销、存业务相 关部分的结构层次图。供应部负责进货业务；销售部负 责销售业务；仓储部下有三个仓库，负责存储各类商品 。 人 事 部 财 会 部 销 售 部 供 应 部 仓 储 部 仓 库 1 仓 库 2 仓 库 3 总经理办公室 图11.3 某商业企业仓库的进、销、存组织机构图 2. 业务流程概况 业务流程分析简述如下： J. 进货管理 接受供应部门交来的进货单，审查，有错退回，无错则 与已到货物核对，单物不符则退回，相符则把货物入库 ，在库存台帐各相关帐页中登入进货栏并修改库存栏。 P. 盘存管理 接受仓储部门交来的盘存通知，审查，有错退回， 无错则依库存台帐盘点货物，填写盘存明细表，按处理 意见，登记库存台帐相应货物页，对使现存量少于最小 存量者，登记进货要求单，交供应部门。 T. 提货管理 接受销售部门交来的订货单，审查，有错退回，无 错则与库存台帐核对，缺货项填缺货单交销售部门，并 登记进货要求单交供应部门；有货项则填入提货单，交 经办人提货，并登记库存台帐相应货物页的提货栏，修 改其库存栏；当现存量少于最小存量时，登记进货要求 单交供应部门。 从系统业务流程分析可得到系统的业务流程图如图 11.4所示。（见Word文档） 3. 信息需求调查与分析 从业务流程图中找出相关单证、票据、帐簿、报表 、文档等原始资料，从中抽出反映信息需求的相关事项 。下面以本系统中最有代表性的库存台帐为例（图11.5 ）。 为节省篇幅，其它单证帐表，如进货单、提货单、 盘存明细表、仓库月报表等就不一一列举。 从原始资料中抽出各栏目名称等系统要保存使用的相关 事项，去掉组合项、导出项、泛指项得到基本项（不能 在系统内生成、来自外部的项），就是要组织数据库基 表中的信息。列举如下： 货号，货名，型号，规格，计量单位；部门号，部门名 ，部门类型，位置，电话； 员工号，姓名，性别，生日，职务，住址，电话；客户 号，客户名，地址，信誉度，联系人，邮编，电话； 供应商号，户名，信誉度，联系人，邮编，电话；货物 所存库号，库存价，期初存量，现存量，最低存量，最 高存量，采购批量； 员工所属部门号，聘用日期；部门主管工号，任职日期 ； 提货单号，日期，时间，经手员工号，提货客户号，所 提货号，售价，提货数量； 进货单号，日期，时间，经手员工号，进供供应商号， 所进货号，进价，供应数量； 盘存单号，日期，盘存库号，清点员，对帐员，审查员 ，所盘货号，实存量，处理意见。 库存台帐 封面 库号 库名 位置 电话号 主管姓名 管理人员登记表 工 号 姓 名 性 别生 日 职 务 地 址 电 话 任职日期 记帐期间： 年 月 日至 年 月 日 帐页 摘要常为：“XXX客户用XXX号提单提货”等 图11.5 库存台帐格式示意图 货号货名型号 规格 计量单位 库存类 型 最低存 量 最高存 量 采购批量 日期 摘要进 货提 货库 存 进 价 数量金额 售价 数量金额 存 价 数量金额 4. 处理功能现状调查分析 在以数据库为中心的原型法中，按业务流程图划分 功能，通常只要展开一两层就可以了。本例划分为进货 、提货、盘存3个子系统，功能层次图如图11.6。 仓库进销存MIS 提货进货盘存 图11.6 进销存信息系统现状功能层次简图 二、 数据库初始概念设计 由系统的基本数据项，按照由基本项构思E-R图的 四条原则，并根据系统的基本功能要求，导出三个初始 局部E-R子图，并改进，然后综合成系统全局E-R草图， 再经过优化，消除重复的实体与重复的联系；引进所需 的联系体，把多元联系转换为多个二元联系，最终得到 系统的全局E-R图。 1. 初始局部E-R图的构思 规定一个库管员只在一个仓库工作，一个仓库可以 有多个库管员；一种货物只能存放在一个仓库，一个仓 库可以存放多种货物；每次盘存只有一个清点员、一个 记帐员、一个审核员。由基本数据项，得到提货、进货 、盘存三个子E-R图如下图11.7（实体的属性未列出） ： 提货 货 物 客 户 销售员库管员 M NK L *客户号 *货号 员 工 父子类 父子类 *工号 日期 时间 售价 数量 提货子ERD 进货 货 物 供应商 采购员库管员 M NK L *商号 *货号 员 工 父子类 父子类 *工号 日期 时间 进价 数量 进货子ERD 盘存 货 物 仓 库 清点员审查员 M NK L *库号 *货号 员 工 父子类 父子类 *工号 日期 实存 盈亏量 处理意见 盘存子ERD 对帐员 父子类 J 库管员 父子类 管理 M 1 存放 1 M 现存量 现存价 2. 初始局部E-R图的改进 从图11.7按从ERD导出一般关系的四条原则，多对 多提货联系得到提货关系框架（图11.8）。 提货关系 日期 时间 客户号销售员工号 库管员工号 货号售价数量 外键外键外键外键 复合主键 从提货关系中可以发现两个问题，一是复合主码 太复杂，不便于查询；二是非码属性售价、数量函数 依赖于(日期,时间,客户号,货号)，对主码是部分函数 依赖，因此，提货关系模式不是3NF。当客户一次提取 多种货物时，日期、时间、客户号、销售员工号、库 管员工号必定多次重复。 究其原因是：当考虑多次提货时，客户、经手员工 、货物之间是多对多联系；但是当考虑客户的一次提货 （提取多种货物时）与经手员工、客户之间是对一的联 系，而与货物依然是对多联系。 解决的方法是在提货E-R子图中引进联系虚体（简 称联系体）提货单。它描述的是提货联系，本质上不是 实体，只是为了化简提货这个复杂的多元联系而引进的 一个中间替身。借用了业务人员熟习的名字提货单 ，但与日常业务中的提货单在组成结构与内容上都相差 甚远。从而把提货转化为员工与提货单之间的经手联系 （一对多）、客户与提货单之间的购买联系（一对多） 、提货单与货物之间的所提联系（多对多）等三个二元 联系。 引进联系体后的提货E-R子图如图11.9。 出售 货 物 客 户 销售员 库管员 M N K L *客户号 *货号 员 工 父子类父子类 *工号 日期 时间 *提货单号 数量 提货子ERD 提货单 经手 购 买 所提 1 1 1 M 售价 摘要 引进类型体后，提货联系在引进联系体提货单后，导出提 货单关系、所提货关系如下： 提单号 日期 时间摘要 销售员工号经手员工号 购物客户号 外鍵 外鍵 主鍵 提货单关系 (经手联系) (购买联系)(出售联系) *时间是为把同日同客户同经手人的提货区分开，引进提单号后就可省去 提货单号 所提货号 售价 数量 外鍵外鍵 主鍵 所提货关系 对进货联系作同样的处理，可以得到完全类似的改 进后的进货ERD。盘存联系也可以作类似的考虑，不 过得到的改进后的盘存ERD要复杂一些，请同学们参 考教材上的图11.11，按这里所作的修改，画出改进后 的盘存ERD。 3. 综合成全局E-R图 把各子业务的ERD，以共有实体为铰链，集成起来 ，就得到全局ERD初稿；再消除冗余的联系、实体与属 性，归并相关实体成父类实体，就可以对其改进。员工 实体与人事管理共享，在人事管理中员工与部门联系， 而仓库是仓储部属下的子部门，所以在全局E-R图中应 引入部门实体。供应商与作为购买商的客户是属性相同 的实体，可以看成是客户实体的两个子类。请参考教材 图11.12的全局E-R图，按这里所作的修改，画出其全局 ERD基本结构。 对全局ERD中的多对多的多元联系引进联系体， 参考改进后的各子ERD，可以得到改进后的全局ERD 。对本案例，请同学们对照教材上的图11.13，按这里 所作的修改，画出改进后的全局ERD基本结构。 三、 数据存储组织的初步考虑 依据四条原则从全局ERD导出一般关系框架，作为 数据存储组织的初步考虑，可以检验ERD的构思是否规 范，可为以数据库为中心进行业务流程再造提供依据。 本例从引进联系体的ER图（图11.13）导出系统的10个 一般关系模型（二维表）如图11.14。这些关系模式都 是3NF或BCNF，可见该ERD的规范化程度是满足基本结构 要求的。请同学们按这里所作的修改，对这些关系框架 作补充改进。 四、 以数据库为中心的进销存业务流程再造 假设用原型法开发仓库进销存业务系统为起点系 统，其它相关业务都还是手工作业，它们与本系统的信 息交换还是用纸介质。为相关业务计算机化并联网后系 统集成需要，本系统所有接收送出的票据帐表都存入临 时文件；当然，系统渐进集成时要从更大范围考虑数据 库重构和业务流程再造。 作为以数据库设计为中心的原型法起点的业务系统 开发中的业务流程再造，很难完全着眼于企业经营链的 全局，只能尽可能考虑全局，重点放在本系统业务的降 低成本和提高收益上。本案例主要考虑三个方面：一是 以数据库为中心，尽可能用计算机处理业务，集成业务 流程，减少业务环节，提高效率与质量；二是及时向相 关部门公布进销存明细和统计分析结果，以便及时进货 ，适时销售，合理库存，提高效益；三是建立并及时改 进市场模型和库存模型，提高其运行频率，有效控制进 货和库存，提高资金运用效率，创造经济效益。 为了尽快研制出实用原型，首轮主要考虑第一方面 ，适当兼顾第二方面。人工流程有些环节是隐含模糊的 ，计算机处理流程则不能这样。下面是再造的进货管理 、提货管理、盘存管理、统计分析等业务流程。 J. 进货管理 接受供应部门提供的进货单，人工审查，有错退回。无 错则加上实到货量栏，输入进货临时文件，按进单户名 查客户关系，找到则把客户号填入进货临时文件，否则 人机结合在临时文件中确定客户号，把新客户信息登录 到客户关系。从进货临时文件打印出相应的进货单，核 对所到货，货单不符合记录实到货量，打印有错进货表 ，交供应部门；相符的则入库并登记到进货单关系及所 进货关系，若是新货则登记货物信息到货物关系，否则 只修改货物关系中的现存量和库存价。 P. 盘存管理 仓储部门按计划编制盘存通知，人工审查，有错修 改，无错则输入盘存临时文件。从货物关系按盘存通知 中库号查找相应的货物记录，加上清点工号、对帐工号 、审查工号、实存量、盘盈量、处理意见等空白字段， 组成盘存明细记录到盘存临时文件中，打印出盘存单及 其盘存明细表，据此盘点库存，记录上述空白字段的值 ，输入到盘存临时文件中并打印盘存结果。依据盘存临 时文件登记盘存单关系及所盘货物关系；按实存量和处 理意见修改货物关系中的现存量。若修改后的现存量低 于最小存量，则调用“进货要求生成”，生成进货要求 记录，存入进货要求临时文件，定期打印进货要求单交 供应部门。 T. 提货管理 接受销售部门订货单，人工审查，有错退回，无错 则输入订货临时文件。按订单户名查客户关系，找到则 把客户号填入进货临时文件，否则人机结合在临时文件 中确定客户号，把新客户信息登录到客户关系。与货物 关系核对，若是新货，则把现存量为0的新货记录登记 到货物关系；把（订货数量货物关系中的现存量）登 记到订货临时文件中的缺货量字段中。缺货量0的为缺 货项，登记到缺货临时文件，打印出缺货单交销售部门 ，并调用进货要求生成，登记进货要求记录到进货要求 临时文件。有货的订货项目则登记到提货单关系及所提 货物关系，打印出提货单，交仓管员发货，并登记经手 工号，输入提货单关系。按（现存量=现存量提货数 量）修改货物关系的现存量，若改后现存量低于最小存 量则调用进货要求生成，生成进货要求记录，存入进货 要求临时文件。定期打印进货要求单交供应部门。 F. 统计分析 可以通过统计分析编制多种图表，支持相关决策。 这里仅考虑进销存明细帐、月报表，盘存明细表，进货 统计表，提货统计表，库存金额降序排列的前20%种(即 A类)货物的库存金额与提货金额对比直方图等。 在课件Word文档中给出给出新的业务流程图，请同 学们注意对输入的校验等方面与人工流程的重要差别。 五、系统首轮实现的功能分析 系统首期除了要实现进货管理、盘存管理、提货管 理、统计分析等基本业务，还要实现系统初始化、查询 等常规功能。对系统本身的管理维护功能是常规的，原 型法首期往往也不急于实现，这里不讨论。本例系统首 期功能层次图如图11.16。 进销存业务信息 系统 系统初始化 进货管理 盘存管理 提货管理查询统计分析 进 货 清 空 提 货 清 空 盘 存 清 空 期 初 存 量 设 置 期 末 转 存 常 用 定 式 查 询 查 询 生 成 器 制 进 销 存 明 细 表 制 盘 存 明 细 表 制 进 货 月 报 表 制 提 货 月 报 表 制 畅 销 货 图 表 空 库 录 入 *进货、盘存、提货等管理有输入到临时文件、打印单据、修改 数据库表等等功能，具体见上述业务描述。 *盘存管理、提货管理调用“进货要求生成”功能。 图11.16 本例系统首期功能层次图 11.4.2 系统首轮概略设计 一、 概略的总体设计 1. 一般关系模型设计：根据系统分析中构思的以数据 库为中心的新业务流程图和新功能层次图，回头修改 ERD，然后再依据从ERD导出一般关系模型的四条原则得 到一组关系框架。如ERD无需修改，则只要审视系统分 析中对数据存储的初步设想，补充完善。本例上述的10 个关系框架是已补充完善的，这里不再重画。 2. 首轮要实现的系统总体结构设计：依据业务流程和 功能层次图确定要实现的模块及其间的层次调用与信息 交换以及其对数据存储的读写和对系统外的输入输出， 画出模块结构图（MSD）。原型法要快速建立原型并允 许反复修改，本例从业务流程和功能层次图就能基本明 确总体机构，可以省去总体结构设计，不画MSD。 3. 首轮要实现的系统平台设计：本系统如采用C/S结 构平台，以SQL Server等实现服务器的数据管理，用VC 等可视化语言与相关的软件开发工具作前台处理，可能 是好的，同时也为以后集成到Intranet平台作好了准备 。但在初始阶段，企业的技术、设备、资金都不一定能 适应，初始原型又要尽快见效，常常不得不退而求其次 。本例要面向经济类、管理类几乎所有专业的学生，考 虑其已有的信息技术基础，所以采用支持VFP的局域网 平台，把VFP数据库放在仓储部门的相当于服务器的P3 微机系统里，各仓库的微机通过局域网作为VFP的用户 共享数据库。 二、 概略的具体设计 1. 代码系统设计 代码是系统给系统所涉及的事物个体的可识别的编码标 识，在企业内外应尽可能具有通用性，所以一般要在 MIS总体规划中基本完成代码系统的设计。这里仅为本 例讨论的需要给出两种代码的编码规则。 n工号：采用身份证号，18位字符，为分组码； n货号：12位，为分组码 v大类1位字符，如1. 日用百货，2.五金电器，3.纺织服 装，等；中类1位字符，如21.小 五金，27.小家电，28.大家电，等 ； v小类3位字符，如 28001.电冰箱，28002.电视机， 28003.抽油烟机，等；品牌或生产 商4位字符，用拼音缩写，如 28004haie.海尔空调器，等；品种 编号3位字符，按首次进货顺排 。 从理论上讲，采用增长原型法，编码表要在总体战略规 划时编制并输入数据库，但实际上往往是从首轮实现开 始建立，然后伴随系统的演进增长而改进扩充。 2Foxpro 数据结构具体设计 （1）数据库表结构 在一般关系框架下面增加类型、长度、小数位、索 引等行，按VFP要求标注。必要时还要补充由系统导出 并填入的必要的导出项字段。从而，形成可在VFP的数 据库设计器、表设计器中可视操作即可生成数据库基表 的表框架。用不止是一个字段的复合索引表达式建立的 索引，若表格中不便填写，可在表格下注明。下面仅以 货物关系所对应的表结构为例。实际的开发中，还应有 显示名、显示格式和实现字段级完整性控制的输入掩码 、字段验证等行，在框架表下面还要有记录有效性检查 规则、插入触发器、修改触发器、删除触发器等条件表 达用于记录级完整性控制；本例不作具体讨论，可参考 有关VFP的资料或者我们即将推出的与本教材配套的IS 案例讲义或教材。下面仅列出货物表和所提货物表作为 示例(课件Word文档，图11.17)。 （2）数据库表间关联设计 表间关联是不同而又相关的两个表父表和子表 之间建立的记录指针联动，使父表记录指针移动时，子 表记录指针按一定的条件随之移动。数据库表间可建立 从父表主索引到子表相关索引的一对多的永久关联，只 要不作删除或更新就会保留在数据库描述文件（.DBC） 中，在查询、报表、表单（FORM）等中自动发挥作用。 VFP表（数据库表、自由表）间还可建立父表字段到子 表索引的多对一或一对多的临时关联，但必须在应用的 数据环境（数据工作期）中建立，也只有在该数据工作 期窗口打开时才起作用。本例数据库表间要建立的永久 关联如图11.18所示。依此可回头检视数据库表框架中 的索引还有没有需要补充的。 提货单 所提货物 货物 部门 员工 客户 所进货物 所盘货物 进货单 盘存 单 仓库 *箭头表示从父表主键指向子表的相关索引（常为外键）的 永久 关联 图11.18 仓库进销存业务信息系统数据库 表间的永久关联图 主管 所属 *仓库号=子部门号 （3）数据库表间的参照完整性（RI）设计 数据库表间的永久关联是数据库表间建立参照完整 性（RI）的基础。RI是指关联的父子表的相关记录应该 是相容的，所以，在修改（记录插入、删除、更新）时 要对关联字段的值作一定的限制规则，包括忽略（父子 表记录修改时不必顾及相容性）、限制（若删除父表记 录或更新父表的关联字段时，子表中有相关记录；或者 插入子表记录时，父表关联字段无相关的值，则禁止修 改）、级联（删除父表记录时，子表相关记录将被同时 删除，更新父表记录关联字段值子表相应字段值同时被 更新）等三级。 本例中把数据库表间的永久关联的参照完整性都设 置成对插入与删除为限制，对更新为级联。 （4）用户视图（SQLVIEW）结构设计 用户视图是用户在运行应用程序时所看到的应用程 序中用到的数据库的那些部分。视图结构设计中，要列 出组成视图的字段及其所来自的VFP表，并给出选择条 件，字段（含选择条件中用到的）来自一个以上的表时 要给出连接条件，视图中有导出项时要给出导出规则。 视图结构设计常伴随着处理模块具体设计来进行， 我们也把它们放到那里介绍。与视图相关的数据安全性 设计是很重要的，例如，本例中仓管员应在只能看到本 库货物和相关信息的视图上进行授权的操作，但本例的 首期工程中不必实现，所以这里就不具体讨论了。 （5）各子系统中的临时文件作为VFP自由表的设计 为了作VFP自由表组织方便，把订货临时文件分成 订单临.DBF、所订货临.DBF两个自由表，把进货临时文 件分成进单临.DBF、所进货临.DBF两个自由表，把盘存 临时文件分成盘单临.DBF、所盘货临.DBF两个自由表。 还有作为输出的缺货临.DBF和进货要求临.DBF。订货临 时文件的两表如图11.19。进货临时文件与以上两表类 似。盘存临时文件的两表如图11.20。(见课件Word文档 ） 3. 首轮实现的模块的具体设计 先设计模块的程序流程图，再伴随着设计视图（ SQLVIEW）。 （1）系统主控模块设计 在VFP中系统主控模块可以是一个表单（FORM）文件（ .SCX）、一个菜单MENU文件(.MPR)，也可以是一个程序 （PROGRAM）文件(.PRG)。其作用是：对系统运行环境 初始化，显示系统形象画面并实现用户进入系统的管理 ，启动系统的逐级调用（通常是通过一个菜单系统）， 控制等待事件的循环和退出系统时恢复环境的原状。具 体请参考VFP教材。这里给出本例的主控模块框图及其 主控菜单(图11.21)。见课件Word文档 （2）下层模块的具体设计 系统初始化模块对应于主控菜单中的一个下拉单， 其菜单项所调用的子模块都是常规的VFP表的输入、复 制、删除、替换等操作，这里就不用讨论它们的具体设 计了。 进货、提货、盘存等管理的模块，可按照上述的业 务流程来作具体设计，下面以提货管理为例来讨论。提 货管理的程序框图如图11.22（见课件Word文档）。为 了说明PAD图的优点，我们同时给出了与粗框图相应的 PAD图。未画出的细框图及进货管理、盘存管理的程序 框图留作练习。 查询模块的下拉挂帘中的常用定式查询是指系统多 次要做的格式固定的查询，可事先用VFP查询生成向导 、设计器等生成查询程序供调用；用户查询生成是系统 运行中临时要做的查询，首轮实现中可直接调用VFP查 询生成软件来实现。退出模块在显示告别画面后，实现 系统环境复原，最后退出系统。 统计分析图表模块所调用的子模块中，进销存明细 表可以设计成在要用时一次从相关关系生成，也可以模 拟人工，设置一个临时表，有货号、日期、摘要、进价 、进货数量、进货金额、售价、提货数量、提货金额、 库存价、库存数量、库存金额等字段，在每次完成相关 业务时就登记该表，要输出时，直接用货物关系与该表 生成进销存明细表。这个表还可借用于其它统计分析中 。前4个是常规报表，可用VFP报表生成软件设计好，以 供调用。 畅销货分析图表是指按日提货金额、月合计提货金 额、从年初到当日累计提货金额降序排列，合计约占总 量80%的前20%种货物的累计数量、金额的横向、纵向的 对比图表，它们对企业经营决策有重要参考价值。VFP 中能通过可视程序设计方便地得到相应的程序模块。这 里主要以月合计提货金额按货种横向比较图表为例，来 介绍SQL视图，其结构表示如下。 n视图名称：货物月合计提货金额 n组成字段：货号、货名、型号、规格、月合计提货金额 n字段来源：货物表、提货单表、所提货物表 n连接条件：货物.货号=所提货物.货号 与 提货单.提单号=所 提货物.提单号 n选择条件：提货单.日期在所规定月份 n导出项导出规则：按货号分组求和 4. 系统首轮实现用开发平台与运行平台的具体设计 原型法的开发与运行没有明确的界限，本例首轮开 发及其初期运行都在能支持VFP6.0的微机单机平台上完 成，以后的改进才移植到微机局域网上，故无需提出具 体要求。 11.4.3 系统首轮实现 以数据库为中心的原型法实现是从数据库建立入手 的。处理模块采用自底向上编制测试，自顶向下联调的 上下结合的策略，与用户一起，边生成，边测试，边改 进。下面简述本例首轮实现的基本过程。为便于以后向 SQL SERVER或其它关系数据库平台转换，对数据的操纵 应尽量用SQL语句来实现。 一、系统实现计划与测试方案的编制 结构化生命周期法中，在系统设计说明书中有系 统实现的初步计划和测试的初步方案，进入系统实现阶 段要据此编制具体的系统实现计划与测试方案。原型法 则没有必要如此繁琐，但也要有安排实现步骤的初步计 划和相应的以测试数据为主体的测试方案。测试方案明 确在系统实现的每一小阶段要作测试的目标、内容与使 用的测试数据，结构化方法中关于系统测试的原则、方 法与测试数据的设计已作详细讨论。本例中的测试数据 主要是初始化空库录入中要录入的测试数据和基本业务 模块测试中的订货、进货数据。 二、建立VFP表结构 在结构化方法中，IT类专业人员更多地用DDL，如 SQL中的建库、建表语句来编写源模式，建立数据库结 构。在原型法中，主要通过可视化的设计器或生成器来 快速建立。进入VFP的表设计器，按具体设计中的框架 ，生成作为VFP自由表的各临时文件(.DBF)。进入VFP数 据库设计器，建立仓库进销存数据库(.DBC)，然后按具 体设计中的框架，生成各数据库表(.DBF)，注意其字段 级和记录级完整性的定义；建立各表的索引，注意索引 类型；建立表间永久关联，定义表间参照完整性(RI)。 三、初始化模块生成、测试数据录入、数据库测试 按具体设计，编写表单等可视对象的具体结构和程 序的具体代码，特别注意如何确保数据输入的正确；用 表单设计器等工具，建立初始化各模块。运行空库录入 模块，试图把事先设计好的包含各种可能错误数据的测 试数据录入各数据库表中，以检测数据库完整性控制功 能并改进之；在保证所设计的完整性不被破坏的数据录 入后，用VFP的常用浏览、查询、排序、修改等工具或 命令，按事先设计的测试方案进行测试并修改。用库中 现有的测试数据测试期末转存与进货、提货、盘存数据 清空及期初存量设置等模块并修改。 四、其它下层模块的生成与测试 按具体设计，编写表单结构和程序代码，同样要特 别注意如何确保数据输入的正确；用表单设计器等工具 或建立程序文件工具，建立进货管理、提货管理、盘存 管理等模块，按设计的测试方案和数据，测试这些模块 并修改之；具体编制各定式查询格式，用查询设计器生 成各定式查询模块，测试并修改；非定式查询直接用查 询命令来完成，可按测试方案直接试验；统计分析图表 要按具体设计编制图表格式，确定数据环境，先用视图 设计器建立视图，再用报表设计器生成报表模块，统计 图则要用查询设计器的查询结果生成图形的功能来实现 ，然后测试改进之。 五、上层模块的实现与系统联调 按具体设计，编写各表单、菜单等结构和程序代 码。用表单设计器生成各人机接口表单；用菜单设计器 生成作为主控菜单的下拉菜单和必要的快捷弹出菜单， 注意用菜单项命令调用下层模块，测试运行主控菜单并 改进；用程序编辑器输入并编辑主控模块为主程序；运 行主程序进行系统联调。也可把主程序编写成一个主表 单。 六、项目的建立与管理 本系统的所有程序模块和VFP表应放到同一子目录 下，设置默认路径指向该目录，打开项目管理器，建立 项目CKJXC(.PJX), 首先把主程序作为第一个文件添加 到项目中，主程序就自动成为项目的主文件；添加已建 立的仓库进销存数据库(.DBC)，项目管理器自动把其数 据字典和所有数据库表(.DBF)与视图添加到项目中；添 加已建立的自由表(.DBF)、数据工作期即环境(.VUE)等 文件。在项目管理器下进行联编，就会自动把主文件逐 级调用或触发的所有表单、菜单及程序代码文件等自动 添加到项目中，并可根据选择生成在VFP环境下运行的 应用程序文件(.APP)或在WINDOWS环境下运行的可执行 文件(.EXE)。 在原型法的首轮实现中，往往不必建立项目，而是 在联调通过后直接清空测试数据，执行主程序，进行系 统初始化，进入试运行与改进阶段。 11.4.4 首轮实现系统试运行评价与改进 用原型法开发信息系统，首轮实现并不是系统开发 的结束，一般也不是首期工程开发的结束。因为这时得 到的只是一个快速生成的一个初始系统，必须在试运行 中与用户一起分析发现问题，反复进行系统再分析、再 设计、再实现，不断改进完善，到完全满足用户需求。 按照增长原型法，首期开发基本完成后，还要再开发相 关的系统，并逐渐归并集成，直到系统总体战略规划的 实现。例如，本例就可以添加多用户并发控制和安全性 控制，还要结合营销业务信息系统和供应业务信息系统 的系统分析，考虑建立库存管理模块以及时改进市场模 型和库存模型，提高其运行频率，并按季节划分货物的 ABC类，有效控制进货和库存，提高资金运用效率，创 造经济效益，从而改进完善本系统。 本例简要讨论了用以数据库设计为中心的原型法开 发商业企业仓库进销存业务信息系统的全过程。可以看 到，它也要有分析、设计、实现、运行四个环节。但是 ，它不像结构化生命周期法那样义无返顾地勇往直前， 每一个阶段都要那么仔细、那么完备地得到不必更改的 成果，那样希望一榜定终生，最后实现完备的整个较大 规模的信息系统，而是从较大规模的信息系统的一个有 关全局的业务信息系统开始，通过必不可少的简要分析 与设计，借助有效的快速开发工具，尽快实现一个可用 的业务信息系统原型，整个分析、设计、实现的过程， 一直到系统运行，都是允许并要求反复修改并不断改进 完善的。同时还要不断扩充，归并集成，增长成一个较 为完备的信息系统。 习题9 第11章完 按本科教学大纲要求，全部教学内容就学习完了。 面向对象方法篇主要是面向管理科学与工程学科的硕士 研究生教学的。我们在第5章已经较多地补充了关于面 向对象开发方法的基本知识，通过全面系统地学习MIS 的基础理论和结合案例系统详细的学习结构化生命周期 法，加上通过即将开始的专业综合设计，同学们应该完 全具备了自学面向对象开发方法的基础知识与理解能力 。建议同学们在学习选修课面向对象程序设计时，自学 面向对象方法篇，针对将要面对职业生涯，培养用面向 对象方法开发MIS的基本能力，这将使你们终生受益。 谢谢大家！ 3E6H9LcOfRjUmYp!s&w)z0C4F7JaMdPhSkVnZq$u*x-A2D5G8KbNfQiTlXo#r%v(y0B3E6I9LcOgRjVmYp!t&w)z1C4F7JaMePhSkWnZq$u*x+A2D5H8KbNfQiUlXo#s%v(y0B3F6I9LdOgRjVmYq!t&w-z1C4G7JbMePhTkWnZr$u(x+A2E5H8KcNfRiUlXp#s%v)y0B3F6I