体系结构结构模型

仓库管理系统的软件体系结构模型
XXX
（XX大学 XXX学院，XX XXX）
摘要：本文使用统一建模语言UML对仓库管理软件的软件体系架构进行建模。

使仓库管理软件架构在开发初期能够很好地被开发人员和客户理解。

本文采用“4+1”视图模型对系统进行建模。

关键词：仓库管理 UML 软件体系架构
1.软件系统体系结构模型
本章采用“4+1”视图模型对软件系统进行建模。

该视图模型从5个不同的视角，包括逻辑视图、进程视图、物理视图、开发视图、和场景视图来描述软件体系机构。

每个视图只关心系统的一个侧面，5个视图结合在一起才能反映系统的软件体系结构的全部内容。

“4+1”视图模型如图1所示，其中图中的实施视图就是开发视图。

图1 “4+1”视图模型1.1逻辑视图
逻辑视图（Logical view），主要是整个系统的抽象结构表述，关注系统提供最终用户的功能需求，不涉及具体的编译，即输出和部署。

在逻辑视图中，系统分解成一系列的功能抽象。

这些分解不但可以用来进行功能分析，而且可用作标识在整个系统的各个不同部分的通用机制和设计元素。

通常在UML中用类图来描述逻辑视图。

类图(Class diagram)显示了模型的静态结构，特别是模型中存在的类、类的内部结构以及它们与其他类的关系等，从系统构成角度来描述正在开发的系统。

类图不显示暂时性信息。

如图2所示为系统逻辑视图。

在逻辑视图中，采购入库员、出库员、商场管理员、仓库管理员类是通过系统用户类泛化来的，系统用户有的一般操作和属性他们也都拥有。

其中按照系统的权限范围来说，采购入库员、出库员、仓库管理员依赖于商场管理员，因为只有商场管理
图2 逻辑视图
员有注册用户的功能。

除了他们共有的属性和操作，采购入库员、出库员、商场管理员、仓库管理员还有各自的特殊操作。

采购入库员类自己还包含了商品入库、创建商品信息、维护商品信息、信息查询这些操作。

出库员类包含的操作有商品出库、信息查询。

仓库管理员类包含的操作有仓库盘点、货位管理。

商场管理员类包含的操作有注册用户、注销用户、查询出库信息、查询入库信息、创建供应商信息、维护供应商信息、创建客户信息、维护客户信息、查询盘点信息、创建商品信息、维护商品信息等操作。

系统的功能类模块包括入库模块、出库模块、信息查询模块、仓库盘点模块、信息管理模块，每个模块都有其各自的功能。

入库模块包含创建商品入库单、提交入库单的功能；出库模块包含创建出库单、提交出库单功能；信息查询模块包含显示入库明细、显示出库明细、显示盘点明细、显示货位明细功能；仓库盘点模块包含仓库盘点、货位管理功能；信息管理模块包含系统用户信息管理、客户信息管理、供应商信息管理和商品信息管理等功能。

各个功能模块和数据库有依赖关系。

功能模块完成功能后会把各种信息传到数据库中存储，形成相应的表。

每个功能模块都有一个可以与打印机连接的接口，方便各种凭证的打印和出具。

1.2开发视图
开发视图又称为模块视图，主要侧重于软件模块的组织和管理。

软件可通过程序库或子系统进行组织，这样，对于一个软件系统，就可以由不同的人并行开发，缩短开发周期。

开发视图要考虑到软
件内部的需求，如软件开发的容易性、软件的重用和软件的通用性，要充分考虑由于开发工具的不同而带来的局限性。

开发视图通过系统输入输出关系
图3 开发视图的模型图和子系统图来描述。

在开发视图中，最好采用4~6层子系统，而且每个子系统仅仅能与同层的或更底层的子系统通信，这样可以使每个层次的接口既完备又精炼，避免了各个模块很复杂的依赖关系。

开发视图所用的风格通常是层次结构风格，如图3所示即本文系统的开发视图。

开发视图中，分为表示层、业务逻辑层、数据库访问层。

表示层负责界面及用户交互，是应用的用户接口部分，它担负着用户与应用间的对话功能。

业务逻辑层主要集中在业务规则的制定、业务流程的实现等与业务需求有关的系统设计，业务逻辑层在体系架构中的位置很关键，它处于数据访问层与表示层中间，起到了数据交换中承上启下的作用。

数据访问层又称为DAL层，有时候也称为是持久层，其功能主要是负责数据库的访问，简单的说法就是实现对数据表的Select（查询），Insert（插入），Update（更新），Delete（删除）等操作。

数据库访问层是唯一知道如何操作存储介质的入口，可以这么来说，基于数据访问层之上，我们调用数据库访问层提供的方法，我们就能完成数据的存储与读取，所以我们可以知道，数据访问层应该是与数据库直接是独立的。

本文中把数据访问层架构成3个构件，分别为操作控制构件、配置管理构件、数据访问构件。

三个层次中，系统主要功能和业务逻辑都在业务逻辑层进行处理。

这里所说的三层体系，不是指物理上的三层，不是简单地放置三台机器就是三层体系结构，也不仅仅有B/S应用才是三层体系结构，三层是指逻辑上的三层，即把这三个层放置到一台机器上。

图4中各层之间、之内的箭头表示调用关系。

业务逻辑层或界面层可以向数据访问层的操作控制构件传入要执行的命令参数；数据控制层接到请求后，负责缓存，并将传入的参数继续下传，完成向下的功能调用，它是上层应用与下层具体数据库操作管理服务通信的逻辑中介；数据操作层根据传入参数信息，结合配置信息来创建具体的数据操作对象返回给上层调用者，并提供具体功能调用服务，也就完成数据库的访问，它负责和底层数据库系统的透明交互，完成SQL语句的执行。

各层和构件都是相互独立的，层与层及构件之间通过接口或者配置管理来通信，数据操作具有很高的重用性。

1.3进程视图
进程视图（Process view）处理视图关注系统动态运行时，主要是进程以及相关的并发、同步、通信等问题，侧重于系统的运行特性。

处理视图和开发视图的关系：开发视图一般偏重程序包在编译时期的静态依赖关系，而这些程序运行起来之后会表现为对象、线程、进程，处理视图比较关注的正是这些运行时单元的交互问题。

进程视图也定义了逻辑视图中的各个类的操作是在哪一个线程中被执行的。

如图4所示为本系统的进程视图。

图4进程视图
系统只有一个进程视图，它以图形方式说明了系统中进程的详细组织结构，其中包括类和子系统到进程和线程的映射。

进程视图在每次迭代过程中都会加以改进。

进程视图显示系统中所有活动进程的树。

其中显示了进程 ID 和模块名称。

1.4物理视图
物理视图（physical view）主要考虑如何把软件映射到硬件上，通常要考虑系统性能、规模、可靠性等。

物理视图对应用自身的实现结构建模，例如系统的构件组织和建立在运行节点上的配置。

这类视图提供了将系统中的类映射成物理构件和节点的机制。

如图5所示为系统的物理视图。

本系统的物理部署架构:客户端PC机主要部署软件系统应用的定义、发布、展示的人机交互部分；服务器主要实现业务逻辑；
数据库服务器完成存储过程及实现数据存储的任务；图中的虚线箭头代表的是依赖关系。

图5 物理视图
1.5场景视图
图6 场景视图
场景（scenarios）可以看做是那些重要系统活动的抽象，它使逻辑视图、开发视图、进程视图、物理视图有机的联系起来，有机的联系起来，从某种意义上说场景是最重要的需求抽象。

在开发体系结构时，它可以帮助设计者找到体系结构的构件和它们之间的作用关系。

同时，也可以用场景来分析一个特定的视图或描述不同视图构件间是如何相互作用的。

本文用用例图来描述仓库管理系统的场景，如图6所示。

如图所示场景中，角色有商场管理员、仓库管理员、采购入库员、出库员，每个角色都有对应的用例和对应的业务。

下面是一些业务的说明：
入库单:即采购入库单，日常业务功能，使用频繁。

主要是对每一批商品入库业务进行记录，自动生成对应的入库凭证。

出库单：日常业务功能，使用频繁。

主要是对每一笔出库业务进行记录，并且生成相应的出库凭证。

仓库盘点：仓库管理中的重要业务，主要根据出库和入库记录对每一种库存商品的数量进行盘点，并对仓库中资金的流动进行统计，计算出每一种商品入库和出库的总值。

库存查询：统计查询功能中的一个模块，提供对库存商品按照多种字段进行查询。

入库查询：统计查询功能中的一个模块，提供对入库记录按照多种字段进行查询。

出库查询：统计查询功能中的一个模块，提供对出库记录按照多种字段进行查询。

客户管理：基本信息维护中的模块，主要用于对客户信息进行查询和维护。

供应商管理：基本信息维护中的模块，主要用于对供应商信息进行查询和维护。

2.总结
有以上的结构建模分析可知，逻辑视图和开发视图描述系统的静态结构，而进程视图和物理视图描述系统的动态结构。

对于不同的软件系统来说，侧重的角度也有所不同。

另外，本文另对数据访问层进行进行了细化，提取了数据访问层中的构件。