第四章 系统设计
4.1 系统设计概述
系统设计是在系统分析的基础上由抽象到具体的过程，同时，还应考虑到系统所实现的内外环境和主客观条件，本着实事求是的态度进行这一阶段的工作。
系统设计阶段的主要目的是将系统分析阶段所提出的反映用户信息需求的系统逻辑方案转换成可以实施的基于计算机与通信系统的物理方案。
这一阶段的主要任务就是从管理信息系统的总体目标出发，根据系统分析阶段对系统的逻辑功能的要求，并考虑到经济、技术和运行环境等方面的条件，确定系统的总体结构和系统各组成部分的技术方案，合理选择计算机和通信的软、硬件设备，提出系统的实施计划，确保系统总体目标的实现。
系统设计工作的特点:
1、系统设计阶段，大量工作是技术性的。
2、允许用户对已提出的信息需求做非原则性的修改或补充。
3、用户在操作使用和运行环境等方面的具体要求也要在系统设计阶段加以明确并在系统的技术方案中得反映，因此系统设计人员还要同管理环境打交道。
4、系统设计工作的环境是管理环境和技术环境的结合，是系统设计工作的重要特点。
系统设计分为两部分：系统总体结构设计和系统详细设计。
4.2 系统总体结构设计
系统的总体结构设计是指整个系统由哪些部分组成，以及各部分在物理上、逻辑上的相互关系，包括硬件部分和软件部分。为了实现系统的总体功能，提高系统的各项指标，总体结构设计的主要任务是将整个系统合理的划分为各个功能模块，正确地处理模块之间与模块内部的联系以及它们之间的调用关系和数据联系，定义整个模块的内部结构。
4.2.1 系统总体功能结构
根据系统分析的结果数据流程图所描述的系统的逻辑模型，把数据流程图上各个处理模块进一步分解，确定系统的层次结构关系，把逻辑模型变为物理模型。
在管理信息系统的设计过程中，系统划分的一般原则如下：
1、子系统要具有独立性。即应把相对独立的事务处理过程作为一个子系统。这样的子系统具有较高的内聚性，与其它的藕合较弱，便于软件开发、使用及日后系统维护。
2、子系统的划分结果应使数据冗余度较小。应避免部分数据在多个子系统中出现，尤其是修改，以保证系统的安全性、可靠性和数据的一致性。
3、子系统的划分应能满足目前和日后管理上的需要，功能应齐全，操作要方便且为今后发展留有接口。
4、子系统的划分应以该单位的管理职能为依据。应尽量避免过分依赖于组织机构，以防止机构变更后为系统带来不必要的麻烦。
从公司的组织结构上出发，把整个管理信息系统划分成多个子系统。每个子系统的功能相对独立，但是子系统之间有必要的数据联系。
对电子购物商城系统的数据流图采用变换中心法和事务中心法进行分析，对其逐步进行功能分解，直到分解成为含义明确、功能单一的单元功能模块，从而得到系统的功能模块结构图，即系统的功能图。如图4-1，反映了电子购物商城的系统功能模块的划分。
图4-1 电子购物商城系统功能模块结构图
1、前台模块详细功能描述
其中，用户信息管理以及订单是禁止匿名用户访问的内容。
(1)商品信息模块：
热门商品浏览（首页显示点击率最高的商品列表）、新到商品浏览（首页显示最新添加的商品列表）、商品分类浏览、按商品名称搜索、商品详细信息。
(2)购物车模块：
添加商品到购物车、购物车信息修改、结账。
(3)用户信息管理模块：
注册新用户、登录、用户修改密码、用户个人资料管理。
(4)订单模块：
查询个人订单列表、查询某笔订单的详细信息。
2、后台模块详细功能描述
(1)管理员信息管理：
登录；添加新管理员、删除管理员：修改密码；管理员日志（记录管理员的每个操作，由超级管理员进行查询）。
(2)商品信息管理：
添加、删除商品类别；添加、修改、删除商品信息。
(3)用户信息管理：
查询用户信息、修改账户金额。
(4)销售管理：
查询某月的销售情况（包括每种商品的售出数量、相关订单数、销售收入）。
4.2.2 系统总体物理结构
电子购物商城各个部门在不同的地点办公，网络拓扑结构以交换机为基础，各部门通过主交换机连接到公司主服务器，电子购物商城有五个不同办公地点的办公处组成。根据这个特点，系统利用微机局域网作为系统的基本物理结构。为了提高系统的可靠性和可扩展性，网络采用以网络集线器为基础，以双绞线为传输介质的星型结构。在每个业务发生点以及每个管理员分别配制微型计算机作为系统结点工作站，系统功能的实现，子系统间的数据共享与交互通过网络服务器完成。电子购物商城的系统网络拓扑图如图4-2所示。
图4-2 电子购物商城系统网络拓扑图
系统具体物理配置如下：
利用公司已经架设好的企业局域网，主服务器采用：服务器、交换机、网络集线器，传输介质采用10M屏蔽双绞线为介质的星型网络拓扑结构，服务器作为系统功能实现和数据共享中心，应具有较好的性能和可靠性。在此基础上再配上一台提供web服务的服务器和一台SQL SERVER 2000数据库服务器即可实现对本系统的全部物理支持。
系统具体硬件配置如下：
1、WWW服务器：INTER P4 2.4 512M DDR ROM 80GB 硬盘。
2、数据库服务器：INTER P4 2.4 512M DDR ROM 80GB 硬盘。
3、客户机：目前流行的PC兼容机。
4、网络连接设备：路由器、交换机、打印机、扫描仪等。
系统具体软件配置如下：
1、操作系统：Microsoft公司Windown2000Server,网络协议采用TCP/IP协议，
客户机 WINDOWS 2000/XP。
2、WWW服务器：IIS 5.0
3、数据库软件：SQL SERVER 2000。
4.2.3 系统体系结构
目前，Web项目较为流行的开发模式是三层逻辑体系结构，eshop的开发按照Windows DNA (Windows Distributed Internet Application，分布式互联网应用结构)，采用基于XML的三层B/S体系结构。Windows DNA提供了一种开发三层结构Web应用程序的通用方法是一个电子商务开发的良好环境。
三层逻辑体系结构是指数据访问层(DAL)、业务逻辑层(BLL)、用户表示层。DAL涉及到数据库本身、存储过程以及提供数据库接口的组件；BLL指的是封装了应用程序商务逻辑的组件；而表示层指的是Web应用程序页，如图4-3所示。
4.3 系统详细设计
4.3.1 代码设计
代码，是用来表示的客观事物的实体类型，以及属性的一个或一组易于计算机识别和处理的特定符号或记号，它可以是字符、数字、某些特殊符号或它们的组合，它可以起到表示、统计、检索和随想状态的描述的作用。
代码是代表系统中客观存在的事物名称、属性或状态的符号。由于现代管理活动中产生的数据量大，所需要的信息种类也很多，为了满足各种管理职能和各个管理层次对信息的需求，必须经过分类整理后才能更有效的利用。代码设计就是信息分类的具体表现，将系统中具有某些共同属性或特征的信息归并到一起。用一些便于计算机或人来识别和处理的符号来表示各种信息。
代码设计实际是一个科学管理的问题。设计出一个好的代码方案，对于系统的开发工作极为有利，它使许多处理工作变得十分方便，通过对数据库以及彼此之间的联系进行分析，对所有数据库文件中的主码和外码的构成进行分析。数据元素的代码设计主要应用符合码和助忆码的设计方法。
为了编程时方便记忆，本系统均采用英文缩写，作为该项的代码。例如：“ProductInfo”表示商品信息表，“ProductID”表示商品编号，“ProductName”表示商品名称。
4.3.2 数据库设计
几乎所有的WEB项目都是基于数据库的，这使得数据的设计在整个项目中的地位举足轻重。相关研究表明，在数据应用系统的开发中，项目成功50%靠数据库的设计。良好的数据设计往往能够减少开发的负担。
数据库设计是指对于一个给定的应用环境，通过合理的逻辑设计和有效的物理设计来构造较优的数据库模式，建立数据库极其应用系统，满足用户的各种信息需求。
从数据应用系统和开发的全过程来考虑，数据库的设计可分为六个阶段：需求分析、概念结构设计、逻辑结构设计、物理结构设计、数据库实施、数据库的运行与维护，按照这样的设计过程，数据库结构设计的不同阶段可形成数据库的各级模式。数据库设计的核心问题是如何从系统的观点出发建立一个数据库模式。一个良好的数据库应该充分反映物流发展变化的状况，充分满足组织的各级管理要求，同时还应该使后继系统开发工作方便、快捷，系统开发小，易于管理和维护。在物理设计阶段根据DBMS的特点和处理要求，进行物理储存安排。。
1、数据库需求分析
eshop是一个典型的电子商务系统，针对它将要实现的业务功能，数据库中应该具有以下的模块：
(1)用户信息:其中应该包括用户编号、用户名、密码、账户金额、姓名、地址等内容。
(2)商品信息:包括商品编号、商品名称、商品价格、描述以及所属类别等。
(3)购物车:用来存储用户购物的信息，如商品编号、数量等。
(4)订单:一笔完整的订单记录应该包括它所相关商品集合以及各个商品的数量等信息。
(5)管理员信息:与用户信息类似，包括管理员编号、登录名、密码、角色类别等。
(6)管理员日志:包括日志编号、发生事件以及时间。
2、数据库概念结构设计
在数据库技术中，我们用模型的概念描述数据库的结构与语义，对现实世界进行抽象。表示实体类型及实体间联系的模型称为“数据模型”，其中之一就是实体联系模型(ER模型)。ER模型是独立于计算机系统的模型，完全不涉及信息在系统中的表示，只是用来描述某个特定组织关心的信息结构，这类模型称为“概念数据模型”。
在电子购物商城系统中，存在用户、商品、购物车、订单、管理员等几个对象实体，以上述实体为例，一个用户对应多个商品，同时一个商品属于多个用户；一个用户对应多个购物车，同时一个购物车只属于一个用户；一个用户对应多个订单，一个订单只能属于一个用户；一个商品对应多个购物车，一个购物车对应多个商品；一个商品对应多个订单，一个订单对应多个商品；一个订单对应多个购物车，一个购物车只能属于一个订单；一个管理员对应多个用户、商品、购物车、订单，一个用户、商品、购物车、订单只能属于一个管理员。
由此可知用户和购物车之间、用户和订单之间、订单和购物车之间、管理员和用户、商品、购物车、订单之间都是一对多的关系；商品和购物车之间、用户和商品之间是多对多的关系。
根据上述分析可对应的实体-关系图如下：如图4-5所示用户和商品、订单之间的局部ER图,图4-6所示商品、订单和购物车之间的局部ER图，图4-7所示各实体之间总体ER图。
实体类型 实体间联系 属性
图4-4 ER图的元素说明
M 1
N N
图4-5 用户和商品、订单之间的局部ER图
M 1
N N
图4-6 商品、订单和购物车之间的局部ER图
M N 1
N 1 N
N 1 1 N
M 1 1
N N N
图4-7 各实体之间总体ER图
3、数据库逻辑结构设计
通过E－R图分析，下面设计具体的逻辑结构。
所涉及到的主要实体集及其属性如下：
用户（UserID、UserName、UserPwd、UserRealName、Sex、Address 、Email、Zipcode）
商品（ProductID、ProductName、ProductPrice、Intro、CategoryID、ClickCount）
购物车（RecordID、CartID、ProductID、CreatedDate、Quantity）
订单（OrderID、UserID、OrderDate、ProductID、Quantity、UnitCost）
管理员（AdminID、LoginName、LoginPwd、RoleID、RoleName）
4、数据库物理结构设计
本系统共涉及到9个表，分别是：用户信息表UserInfo、商品信息表ProductInfo、商品类别字典表Category、购物车表ShoppingCart、订单表Orders、订单信息表OrderItems、管理员信息表Admin、管理员角色字典表AdminRole和管理员日志表AdminAction。
主要设计思想：
(1)尽管在需求分析中，商品类别仅仅是商品的一个属性，但数据库设计中一般将其分离出去创建单独的表。事实上，这是一种面向对象的思想，这种做法有利于系统的扩展，例如商城的管理者将要拓宽业务、推出某种新类型的商品早，这样的设计将令其变得异常容易。同样的思想也体现在Admin表和AdiminRole表的设计中。
(2)由于订单可能包括多种商品，而且数量不一，所以用两个表来共同体现订单这个实体。在Orders表中存放订单的基本信息：订单号、所属用户的编号以及下订单的时间。而在OrderItems表中则存放订单的具体信息，每条记录体现某个订单所包含的某种商品的购买信息。
在本系统中数据库具体表结构的设计：
(1)用户基本信息表 UserInfo
用户信息表用来记录用户的一些基本信息，其结构如表4.1所示。
表4.1 UserInfo的结构
| 编号 | 字段名称 | 数据类型 | 说明 |
| 1 | UserID | Int | 用户ID（主键） |
| 2 | UserName | Nvarchar(50) | 用户登录名 |
| 3 | UserPwd | Nvarchar(50) | 用户密码 |
| 4 | Question | Nvarchar(50) | 密码提示问题 |
| 5 | Answer | Nvarchar(50) | 密码提示问题答案 |
| 6 | Acount | Decimal | 账户金额 |
| 7 | UserRealName | Nvarchar(50) | 用户真实姓名 |
| 8 | Sex | Nvarchar(50) | 性别 |
| 9 | Address | Nvarchar(50) | 地址 |
| 10 | | Nvarchar(50) | 电子邮件 |
| 11 | Zipcode | Nvarchar(50) | 邮编 |
(2)商品信息表 ProductInfo
商品信息表表示商品的基本信息，如表4.2所示。
表4.2 ProductInfo的结构
| 编号 | 字段名称 | 数据类型 | 说明 |
| 1 | ProductID | Int | 商品编号（主键） |
| 2 | ProductName | Nvarchar(50) | 商品名称 |
| 3 | ProductPrice | Decimal | 价格 |
| 4 | Intro | Nvarchar(50) | 商品介绍 |
| 5 | CategoryID | Int | 所属分类编号 |
| 6 | ClickCount | Int | 点击数 |
(3)商品分类表 Category
商品分类表用来表示商品类别信息。其结构如表4.3所示。
表4.3 Category的结构
| 编号 | 字段名称 | 数据类型 | 说明 |
| 1 | CategoryID | Int | 商品分类ID（主键） |
| 2 | CategoryName | Nvarchar(50) | 分类名称 |
(4)购物车表 ShoppingCart
购物车表用来存储用户购物的信息。其结构如表4.4所示。
表4.4 ShopingCart的结构
| 编号 | 字段名称 | 数据类型 | 说明 |
| 1 | RecordID | Int | 记录ID（主键） |
| 2 | CartID | Nvarchar(50) | 购物车ID |
| 3 | ProductID | Int | 所购商品编号 |
| 4 | CreatedDate | DateTime | 购物时间 |
| 5 | Quantity | Int | 购买数量 |
(5)订单表 Orders
订单表保存每笔订单的基本信息。结构如表4.5所示。
表4.5 Orders的结构
| 编号 | 字段名称 | 数据类型 | 说明 |
| 1 | OrderID | Int | 订单号（主键） |
| 2 | UserID | Int | 所属用户ID |
| 3 | OrderDate | DateTime | 成交时间 |
(6)订单详细信息表 OrderItems
订单详细信息表体现订单的细则，结构如表4.6所示。
表4.6 OrderItems的结构
| 编号 | 字段名称 | 数据类型 | 说明 |
| 1 | OrderId | Int | 所属订单号（主键） |
| 2 | ProductID | Int | 商品ID（主键） |
| 3 | Quantity | Int | 该商品的购买数量 |
| 4 | UnitCost | Decimal | 该商品的单价 |
(7)管理员信息表 Admin
与用户信息表类似，管理员信息表用来保存管理员的基本信息，如表4.7所示。
表4.7 Admin的结构
| 编号 | 字段名称 | 数据类型 | 说明 |
| 1 | AdminID | Int | 管理员ID |
| 2 | LoginName | Nvarchar(50) | 管理员登录名 |
| 3 | LoginPwd | Nvarchar(50) | 管理员密码 |
| 4 | RoleID | Int | 管理员角色ID |
(8)管理员角色表 AdminRole
管理员角色表用来表示不同的管理员角色类别，如表4.8所示。
表4.8 AdminRole的结构
| 编号 | 字段名称 | 数据类型 | 说明 |
| 1 | RoleID | Int | 角色ID（主键） |
| 2 | RoleName | Nvarcha(50) | 角色名称 |
(9)管理员日志表 AdminAction
管理员日志表表示管理员操作的每一条记录，如表4.9所示。
表4.9 AdminAction的结构
| 编号 | 字段名称 | 数据类型 | 说明 |
| 1 | ActionID | Int | 日志ID（主键） |
| 2 | Action | Nvarchar(50) | 角色名称 |
| 3 | ActionDate | DateTime | 日志时间 |
| 4 | AdminID | Int | 所属管理员编号 |
5、数据库设计图
设计的各数据表之间的关系如图4-8所示。
| UserInfo | |
| PK | UserId |
| UserName UserPwd Question Answer Acount UserRealName Sex Address Zipcode | |
| AdminRole | |
| PK | RoleId |
| RoleName | |
| Category | |
| PK | CategoryId |
| CategoryName | |
| ProductInfo | |
| PK | ProductId |
| FK1 | ProductName ProductPrice Intro CategoryID ClickCount |
| Admin | |
| PK | AdminID |
| FK1 | LoginName LoginPwd
RoleId |
| Order | |
| PK | OrderId |
| FK1 | UserID OrderDate |
| AdminAction | |
| PK | ActionId |
| FK1 | Action ActionDate AdminID |
| ShoppingCart | |
| PK | RecordId |
| FK1 | CartId ProductID Quantity CreateDate |
| OrderItems | |
| PK,FK1 PK,FK2 | OrderId ProductID |
| Quantity UnitCost | |
图4-8 数据库设计图
数据库设计图说明如下：
PK(Primary Key)为主键，FK(Foreign Key)为外键，箭头代表两个表之间的关系，即某个表的PK与另一个表的FK之间的对应关系。
4.3.3 用户界面设计
目前，界面设计已成为评价软件质量的一条重要指标，一个计算机系统的成功与否，很大程度上取决于用户使用人机界面、人机对话的体验或感受。所谓用户界面是指软件系统与用户交互的接口，也是控制和选择信息输入输出的主要途径，通常包括输入、输出、人机对话的界面与方式等。用户界面设计应坚持友好、简便、实用、易于操作的原则，尽量避免过于烦琐和花哨。
1、输入设计
输入数据的正确性对于整个系统质量的好坏具有决定性的意义，输入设计不当有可能使数据发生错误，这时，所使用的计算和处理十分正确，也不能得到可靠的输出信息。因此，输入设计必须考虑周全，尽量使出错率降到最低。
2、输出设计
系统设计的过程正好和实际实施过程相反，并不是从输入设计到输出设计，而是从输出设计到输入设计，这是因为输出表格直接与使用者相联系，设计的出发点应当是保证输出表格方便的为使用者服务，正确及时的反映和组成用户生产和服务部门的有用信息。
3、人－机对话设计
人－机对话主要是指在计算机程序运行中，使用者与计算机系统之间通过终端屏幕或其他装置进行一系列交替的询问与回答。对话设计的任务是与用户共同的确定对话方式、内容与具体格式。
信息的输入主要采用手工操作方式，以键盘、鼠标作为输入设备，输出设备采用显示终端、打印机、以及纸张、磁盘作为输出介质。
本系统采用了基于B/S结构的菜单选择、填写表格和简单提示等友好的人机交互方式，如图4-9 所示。
图4-9 系统基本用户界面
屏幕最上方是电子购物商城系统主功能模块链接区，显示系统登录等主链接，用户通过鼠标选择访问登录页面。屏幕左边的子功能信息链接区，是各子功能模块信息具体
体现，用户可通过鼠标选择所需信息。当用户选择了所要进行的工作后，系统进入了相应的业务处理功能模块，整个业务处理活动在显示区域进行，显示相应的查询结果信息。当用户业务处理完毕后系统返回到之前的菜单显示状态；当用户不使用时，可选择退出整个系统。
4、处理过程设计
处理过程设计要根据模块划分以及结构化程序设计的基本原则，对每个程序模块中的详细处理过程进行设计，设计的工具有程序流程图、合图（N-S图）、过程设计语言、判定树和判定表等，本系统中采用的是程序流程图，如电子购物商城前台系统程序流程图，如图4-10所示。
图4-10 电子购物商城前台系统程序流程图
1510
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
