软件工程专业课程设计--仓库管理系统

软件工程专业课程设计--仓库管理系统内容摘要：

入库信息；查询产品信息 管理权限 普通权限 13 第二章 概要设计 一、软件体系结构模型 大型软件系统总是被 分解成一系列子系统，由子系统提供一些相关的服务。 软件体系结构设计过程就是识别出这些子系统，并建立子系统控制和通信的框架，最后给出软件体系结构的一个描述。 ⒈系统构成模型 系统构成模型有容器模型、客户 服务器模型和抽象机模型三种。 ⑴容器模型 构成一个系统的子系统一定要浇灌换信息，以便能有效地在一起工作。 子系统交换信息、 协调工作有两种基本方法： 全部共享书防在一个中央数据库中，所有子系统都能从中存取数据； 每个子系统用各自的数据库与其他子系统进行数据交互，通过消息传递来实现。 一般情况下，大多数使用大量数据的 系统都是围绕共享数据库（或称为容器）组织的，所以，基于一个共享数据库的系统的系统模型称为容器模型。 这个模型适合于数据由一个子系统产生，而其他子系统共享使用的系统结构。 这种类型的系统有命令控制系统、管理信息系统、 CAD 系统和 CASE 工具集成系统等。 共享容器模型的优点是能够高效地共享大量的数据，生产数据的子系统不需要关心数据如何被其他子系统使用，可以集中进行备份、保密、访问控制和错误恢复等活动。 其缺点是子系统一定要与容器数据一致，系统变更或进化比较困难，难以集成，以及很难将容器分布到多台机器上。 ⑵客户 服务 器模型 客户 服务器模型的主要组成部分是： 一组给其他子系统提供服务的单机服务器； 一组向服务器请求服务的客户机； 一个连接客户和服务器的网络 (可选 )。 客户机必须知道可用的服务器的名字和它们所提供的服务，并通过远程调用获取服务器提供的服务。 反之，服务器没有必要知道客户机的身份，以及到底有 14 多少客户机在运行。 客户 服务器模型能够实现基于容器模型的系统，容器就充当了系统的服务器。 子系统需要访问容器，因而扮演了客户机的角色。 当然，当运行大量数据交换时，这种系统就会产生性能问题。 客户 服务器模型的最大优点是：这是 一个分布式结构，通过网络可以很容易地添加新的客户机和服务器，而不会 影响 系统的其他部分。 ⑶抽象机模型 抽象机模型也称为分层模型，是建立子系统的接口模型，它把子系统组织成一系列的层次，每一层提供一组服务，每一层定义为一个抽象机。 每个抽象机都是由其下层的抽象机的代码构成的。 每一层提供给上一层服务，同时调用下一层的服务。 每一层的实现只影响相邻层，不会影响到系统的其他各层。 分层的方法支持系统的增量式开发，若一层开发完成，该层提供的服务就可以被用户使用了。 分层的缺点是：用这种方法构建系统比较困难。 几乎所有抽象机都 需要的基本服务（如文件管理）需要由内层提供，因此，用户的服务可能需要访问较深层的抽象机。 这一点有悖于一个外层只需要访问临近下层抽象机的分层原则。 性能也可能是一个问题，因为需要多层的指令解释过程。 如果层次太多，层次管理就将成为系统的一个重要负担。 根据三种系统构成模型的介绍，很明显地可以知道本仓库管理系统是基于 容器 模型设计的。 仓库管理系统只使用到一个总数据库，而其中提供的所有服务都直接访问该数据库 ，因此本仓库管理系统具备容器模型的各种特性。 ⒉系统控制模式 软件体系结构除了要明确系统构成模型之外，还要给出子系 统的控制模式，使子系统能够根据控制模式工作。 在体系结构层次上的控制模式主要反映子系统之间的控制流。 系统控制模式有两种一般性的建模方法，即集中式控制和事件驱动控制。 ⑴集中式控制 在集中式控制模型中，一个子系统被定义为系统控制器来负责管理其他系统的执行。 集中式控制模型又可分为调用 返回模型和管理者模型两类。 15 ①调用 返回模型。 这是一个自上而下的子过程模型。 控制始于系统（程序）的顶层，在子系统（程序）调用过程中，控制逐步传递到更低的层次中。 该模型适用于顺序执行的系统。 ②管理者模型。 这是一种适用于并发系统 的模型。 一个系统组件被指定为系统管理者， 控制其他系统过程的启动、终止和协调。 一个过程就是一个能和其他过程并发执行的子系统或模块。 ⑵事件驱动控制 在集中式控制模型中，控制决断通常决定于一些系统状态变量值。 相反，事件驱动的控制模型是通过外部产生的事件驱动系统的。 有多种不同的基于事件驱动的系统，如电子表格、基于规则的产生式系统等。 下面是两种事件驱动的控制模型。 ①广播模型。 发生的事件广播到所有子系统，任何能处理该事件的子系统都会响应。 该模型适用于基于网络的分布式系统。 ②中断驱动模型。 由中断处理器对来自外部 的中断进行检测，然后在其他组件中处理这些中断。 该模型适用于对定时有严格要求的实时系统。 广播模型中的子系统注册其感兴趣的特别事件，当这些事件发生的时候，控制被转换到处理这些 事件 的子系统。 所有的事件都可以被发送到所有的子系统，但这样做增加了子系统的开销。 一般地，事件和消息处理器要维护子系统的注册和这些子系统所感兴趣的事件。 广播模型的优点是进化比较简单，处理特别类型事件的新的子系统可以通过在事件处理器中注册这些事件来达到集成；其缺点是子系统相互竞争地处理事件，这可能会引起冲突。 中断驱动模型只用在硬件实时系统 中，要求对一些事件能作出及时响应，这可以与集中式控制模型结合起来使用。 中央管理者处理系统的一般性运转，而中断控制用于对紧急事件作出反应。 16 而本仓库管理系统显然属于前者，所有的子系统都是由 一个总的系统控制的，触发子系统的调用主要取决于系统状态量的改变。 并且可以看出，仓库管理系统是属于管理者模型的。 二、用面向数据流的方法设计系统软件结构 ⒈仓库管理软件结构 在需求分析中，已经使用结构化方法分析了“仓库管理系统”。 因此，可以从图 16 所示的仓库管理系统 流 图出发来设计仓库管理系统的结构。 17 图 15 仓库管理系统数据流图 下一个设计步骤是完成“第一级分解”。 所谓“第一级分解”就是确定系统的总体控制结构。 通常，变换分析得出的系统高层结构是一个“三叉”控制结构。 针对“仓库管理”得出的高层控制结构如图 16所示。 用户数据 D1 仓库数据 产品入库 维护模块 D1 仓库数据 用户 客户管理 用户管理 退出系统 D2 客户资料 D3 用户资料 产品出库 产品查询 用 户 数 据 帮助模块 18 图 16 仓库管理的“第一级分解” 再下一个设计步骤是完成“第二级分解”。 所谓“第二级分解”，就是把数据流图中的每个处理映射成软件结构中的一个适当的模块。 变换分析的映射规则是从变换中心的边界开始沿着输入通 路向外移动，把输入通路中每个处理映射成软件结构中“输入信息处理控制模块”控制下的一个低层模块；然后沿着输出通路向外移动，把输出通路中每个处理映射成直接或间接接受“输出信息处理控制模块”控制的一个低层模块；最后把变换中心内的每个处理映射成接受“变换中心控制模块”控制的一个低层模块。 对于“仓库管理”来说，“第二级分解”的结果如图 17 所示。 图 17 仓库管理的“第二级分解” 最后洋设计步骤是对仓库管理的初步结果优化。 结合仓库管理的“第二级分解”图可以将其 优化成如下的软件结构图。 仓库管理 接收数据 处理 数据 输出 数据 仓库管理 接收数据 处理数据 输出数据 帮助信息 验证用户 权限 收集数据 审核数据 修改更新 统计数据 汇总数据 分析数据 19 图 18 优化后的仓库管理软件结构 ⒉ 系统帐户管理软件结构 根据数据流图，能够得到系统帐户管理软件结构如下图所示。 图 19 系统帐户管理软件结构 综合上面的分析，可进一步得到包含系统帐户管理、仓库管理和系统数据管理三大子功能的软件结构如图 20所示。 仓库管理 接收数据 处理数据 打印报表 验证用户 权限 收集数据 审核数据 修改更新 统计数据 汇总数据 分析数据 系统帐户管理 修改更新授权 验证用户 查询用户 20 图 20 仓库管理系统细化的软件结构 结合上述的分析描述，得到仓 库管理系统的完整软件结构图，如图 21 所示。 仓库管理 接收数据 处理数据 帮助信息 验证用户 权限 收集数据 审核数据 修改更新 统计数据 汇总数据 分析数据 系统帐户管理 修改更新授权 查询用户 21 图 21 仓库管理系统的完整软件结构 三、数据库逻辑结构设计 数据库逻辑结构设计的任务是根据 ER模型和需求分析所产生的文档，并综合考虑所选择的具体 DBMS 的特点，设计出整个数据库的逻辑结构。 一般来说，选择哪一种 DBMS 存放数据，是由系统分析员和用户（一般是企业的高级管理人员）决定的。 需要考虑的因素包括 DBMS 产品的性能和价格，以及所设计的应用系统的功能复杂程度。 如果选择的是关系型 DBMS 产品，那么逻辑结构的设计就是指设计数据库中所包含的各个关系模式的结构，包括关系模式的名称、每 一 关系模式中各属性的名称、数据类型和取值范围等。