软件系统开发指导课案.docx
- 文档编号:25869988
- 上传时间:2023-06-16
- 格式:DOCX
- 页数:31
- 大小:31.18KB
软件系统开发指导课案.docx
《软件系统开发指导课案.docx》由会员分享,可在线阅读,更多相关《软件系统开发指导课案.docx(31页珍藏版)》请在冰豆网上搜索。
软件系统开发指导课案
软件系统开发概述
系统开发的主要步骤包括:
系统需求分析、数据库设计和应用程序设计。
系统分为面向数据的数据库应用系统和面向处理的数据库应用系统。
否认哪一种,第一步都要作好数据库的设计。
两类系统都是通过应用程序向用户提供信息服务的。
但是,前者的应用面更宽,其数据对应用程序的依赖也因而更小。
反映在系统的开发步骤上,两类系统的具体作法也有较大不同。
现分述如下:
一、以数据为中心的系统
这类系统都是大型数据库系统。
这类系统的开发示意图如下
收集数据处理需求求
数据分类与编码
维护子系统的
设计与实现
应用子系统的
设计与实现
数据库设计
满意否
N
数据库实现
(采集与装入数据)
数据库运行与维护
1.数据库设计
数据量大是这类系统的主要特点。
如国家经济信息系统、全国财政税务信息系统、科技情报检索系统等,一般都在几百MB。
设计这类系统时还要充分考虑到数据的增长。
科技情报信息也好,国家经济信息也好,数据量都是逐年增长的。
在一般情况下,可以把数据分为当前数据和历史数据,分别存放在当前库和历史库中。
这样既可达到把一些有用数据作为历史资料长期保存的目的,又可使对当前数据的频繁处理更加高效和方便。
2.应用程序设计
在上图中,“数据库设计”的左右两侧列出了应用程序设计所包含的两项工作,即应用子系统设计和维护子系统设计。
需要强调指出,对于以数据为中心的系统,其应用子程序不仅数量大,而且伴随用户的增加而不断扩充。
由于这类系统的用户众多,每个用户对数据会有不同的需求,因此系统设置若干基本查询程序用于一般的对外信息服务外,应允许某些用户拥有专用的查询程序;对于领导机关和研究部门,还应允许它们建立满足各自需求的统计和分析程序,支持它们进行预测和决策。
由此可见,这类系统的应用子程序可以在数据库设计之后,甚至在已经运行后,再根据用户的需要逐步开发与扩充。
所以我们说,在这类系统中数据是独立于应用程序的。
除此之外,在设计这类系统的应用程序时不需注意以下特点:
(1)由于用户众多,系统应十分重视数据安全,防止有意或无意地造成数据的破坏或泄密。
为此,程序应具有鉴别用户身分(例如核对用户口令)和限制操作权限(例如只读不写)等功能,并在维护子程序中设置对数据进行后备(即复制备份)和转移(将数据从当前库转入历史库)等有关程序。
(2)考虑到大多数用户是不计算机的非专业用户,所有应用程序都应具有友好的用户界面,并尽可能利用图形、代码等技术,以方便用户的操作。
(3)维护数据的完整性。
由于这类系统往往是适用于多用户的网络或分布式系统,这一点尤须引起足够重视。
以数据为中心的应用系统通常是在大、中型计算机,或者由它们与微机共同组成的主从式系统上开发的。
二、以处理为中心的系统
在微机DBMS上开发的应用系统大都是小型的数据库系统。
它们是以处理为中心的应用系统,也是我们研究的重点。
这类系统的开发示意图如下:
需求分析
功能分析
数据分析
应用程序设计
数据库设计
系统试运行(联调)
满意否
NN
Y
系统运行与维护
由图可知,整个开发活动是从对系统的需求分析开始的。
需要指出,系统需求包括对数据的需求和对数据处理或应用的需求两方面的内容。
图中把前者称为数据分析,后者称为功能分析。
它们的分析结果将分别作为数据库设计和应用程序设计的依据。
实际上在一个“以处理为中心”的应用系统中,这两方面的需求往往我中有你,你中有我,不能截然分开。
具体地说,不仅在应用程序设计中仍须接受数据库当前结构的约束,在设计数据库的时候,也须充分考虑满足数据处理的需要。
需求分析结束后,就要分别开始数据库设计和应用误译设计了。
前者又可分为“概念设计-实现设计(或逻辑设计)-物理设计”等步骤;后者则通常包括“确定总体结构-模块设计-编码调试”等内容。
这两项工作完成后,系统应进入试运行,即把数据库文件连同有关的应用程序一起装入计算机,考察它们在各种应用中能否达到预定的功能和性能需求。
若不能满足,还需返回前面步骤,修改数据库或应用程序的设计。
为稳妥起见,在试运行阶段一般只装入少量数据。
等确认没有重大问题时再装入大批数据,以免造成较大返工。
试运行的结束,标志着系统开发的基本完成。
但是,只要系统存在一天,对系统的调整和修改就会继续一天。
还须继续做好系统的维护工作,包括纠错和系统改进等。
系统需求分析
需求分析是系统开发的第一步,目的是确定用户对目标系统的需求。
一般地说,目标系统都是由当前系统脱胎而来的。
它源于当前系统,但又往往高于当前系统。
大体上说系统的需求分析要经历下列步骤:
(1)调查研究当前系统的工作状况,即进行“详细的用户调查”
(2)通过对调查内容的“分析”与“抽象”,列出经过用户许可的目标系统需求
(3)对上述需求进行“数据分析”和“功能分析”,分别得出系统对数据和数据应用两方面的需求。
一个实例─汽车修理管理信息系统
(QCXL_MIS)
通过用户调查,初步得出以下结果:
1.当前系统工作状况
调查获悉,该厂在业务管理上共使用5种单据,4种账册和3种主要报表。
现分述如下:
(1)5种单据。
如下表
当前系统单据一览表
编号
名称
填写人
D1
修车登记表
送修人
D2
汽车修理单
修理派工员和修理工
D3
零件领用单
修理工
D4
零件入库单
仓库管理员
D5
修车发票
财务人员
各表的具体格式如下:
修车登记单
日期
汽车牌号型号
生产厂
修理项目
车主名电话
地址
其余略
(2)4种帐册如下表
当前系统账册一览表
编号
名称
建账根据
Z1
汽车登记册
D1
Z2
修理工名册
人事部门资料
Z3
汽车修理台账
D2、D5
Z4
库存零件台账
库房资料
汽车登记册
牌号
型号
生产厂
车主名
地址
电话
其余略
(3)3种主要报表
当前系统报表一览表
编号
名称
数据来源
B1
零件耗用月报表
Z3,Z4
B2
修理工资月报表
Z3,Z2
B3
零件订货计划
Z4
零件耗用月报表
零件名称
数量
价格
零件费
利润
其余略
2.对目标系统的应用要求
通过对当前系统的调查和与用户的共同讨论,对将要开发的目标系统提出了如下的总体要求:
(1)用数据文件代替现用的全部账册
(2)具有对各种数据文件装入和修改数据的功能
(3)能计算出修车费用和开发票。
其中修车费用按下列各式计算:
零件费=∑零件价格╳耗用数量
修理费=小时工资╳修理工时╳3
总计=零件费用+修理费
(4)能找出需要订货的零件,编制并打印零件订货计划
订货条件:
零件库存量<最低库存量
订货数量:
额定订货量
(5)按现有格式和内容和打印零件耗用月报表和修理工资月报表
(6)有多种查询和统计功能。
为了简化讨论,具体需求就从略了
在上述工作的基础上,就可以进行“数据分析”和“功能分析”了。
数据分析
这是数据库系统开发中十分重要的一项活动。
其首要任务是确定目标系统中使用的全部数据,为它们取名和定义。
在传统的软件工程方法中,数据常区分为数据文件、数据流(组合数据)和数据项(单个数据)三大类。
分析中要为每一数据编写一个数据条目,然后将所有条目合编为数据字典。
这样,在随后进行的系统设计中不论有多少人参加,大家都可以数据字典为统一的根据,不必担心因数据不一致而导致矛盾和混乱了。
在数据字典中,每一个数据占一个字典条目。
字典条目可以用简易表示法表示。
字典条目所用符号如下表:
符号
=
+
a{}b
[/…/]
()
*…*
含义
定义为
加
允许重复a-b次
在数项中任选一项
允许省略()中内容
注释的起止符号
字典条目举例
修车登记单=牌号+型号+生产厂+车主名+地址+电话
汽车登记册=牌号+型号+生产厂+车主名+地址+电话
车主名=3{汉字符}10
以汽车修理管理信息系统为例,说明数据分析步骤如下:
1.确定各个单项数据(不含数据文件和数据流)在目标系统中的名称。
为数据取名时注意:
(1)同一数据还要使用不同的名称
(2)在容易识别的前提下尽量简化名称,以方便输入操作。
在本例中,一律取汉字拼音的首字母作为数据名称。
例:
账册Z1(PH,XH,SCC,CZM,DZ,DH)
2.定义数据项的含意与取值
将上一步得到的全部数据项综合起来,加上含义与取值,便可得到整个目标系统的数据项条目,这些数据项将构成定义应用系统的字段变量和内存变量的根据。
数据项条目一览表
数据项名
含义
类型
宽度
数据项名
含义
类型
宽度
PH
汽车牌号
C
12
CB
成本
N
8.2
XH
汽车型号
C
6
JG
价格
N
8.2
GH
修理工工号
C
4
LJF
零件费
N
8.2
BH
修理单编号
C
4
ZJ
总计
N
8.2
LJH
零件号
C
6
SL
数量
N
2
XM
修理工姓名
C
8
KCL
库存量
N
3
CZM
车主名
C
8
ZDKC
最低库存
N
3
LJM
零件名
C
10
DHL
订货量
N
3
DZ
地址
C
16
LR
利润
N
8.2
DH
电话
C
13
YGZ
月工资
N
6.2
XLXM
修理项目
C
12
CSRQ
出生日期
D
8
SCC
生产厂
C
20
JCRQ
进厂日期
D
8
XLXS
修理小时
N
4.1
SXRG
送修日期
D
8
XSGZ
小时工资
N
5.2
WGRG
完工日期
D
8
XLF
修理费
N
8.2
3.定义目标系统的数据流
系统的输入数据和输出的打印数据,一般可转换为目标系统的输入和输出数据流。
就本例面议,D1-D5,B1-B3共可定义8种数据流。
如下表:
数据流条目一览表
数据流名
含义
组成
XCDJ
修车登记单
PH+XH+SCC+CZM+DH+DZ+XLXM+SXRQ
XLD
汽车修理单
BH+PH+GH+XLXM+XLXS+WGRQ+{LJH+SL}
LYD
零件领用单
BH+LJH+SL
RKD
零件入库单
LJH+LJM+CB+SL
XCFP
修车发票
CZM+DZ+PH+XLXM+WGRQ+XLF+LJF+ZJ
LHYB
零件耗用月报
LJH+LJM+SL
DHJB
零件订货季报
LJH+LJM+DHL+JG+ZJ
GZYB
修理工资月报
GH+XM+XLXS+XSGZ+YGZ
如果目标系统是基于普通文件的应用系统,在数据项和数据流全部定义后,就可以定义数据文件了。
但是在数据库应用系统中,定义数据库文件不属于分析阶段的任务。
这是因为在开发这类系统时,数据库的设计上升为一项独立的开发活动。
目标系统共需要多少个数据库文件?
每个文件怎样组成?
必须推迟到数据库设计阶段方能最后确定。
这也是开发数据库应用系统不同于开发传统文件应用系统的一个特点。
还需指出的是,由于数据库文件暂不能确定,已定义的数据项和数据流也可以在以后的设计阶段出现增删。
功能分析
功能分析的任务是弄清用户对目标系统数据处理功能所提出的需求。
用户对本例提出的功能需求可归纳为下列4个方面:
1.登记功能:
用于把各种手填单据中的数据及时登记到系统将要定义的数据库文件中。
由于库文件要等数据库设计好后才能确定,故此项功能也须随后再定。
2.开修车发票:
根据修理单记载的修理小时和零件用量记载的耗用零件,按规定的算式计算出修理费和零件费,然后打印出发票。
不难看出,发票包含的信息几乎取自所有数据文件,所以这是一项涉及面很广的功能。
3.打印报表:
包括2种月报表(零件耗用和工资津贴)和一种季报表(零件订货)。
4.查询统计:
满足对各种数据的查询、统计和分析等需求。
如前所述,为了简化所讨论的问题,这总分的功能从略了。
至此,除个别问题暂时不能确定外,已经基本上完成了对“汽车修理管理信息系统”的需求分析。
数据库设计
在数据库应用系统中,数据由DBMS进行独立的管理,对程序的依赖大为减小。
因此,数据库的设计也上升为一项独立的开发活动,成为在数据库应用系统的开发中最受关心的中心问题。
以下将介绍数据库设计所包含的工作内容、指导原则与设计过程。
一、数据库的分级结构与设计过程
1.SPARC分级结构
SPARC是美国国家标准协会(ANSI)下属的标准规划和要求委员会的缩写。
1975年,该委员会对数据库结构提出了一个标准模型。
这一模型将数据库划分为内模式、概念模式和外模式三级,被称为SPARC分级模型。
下图给出了这一模型的分级结构及各级之间的联系。
应用程序
外模式A
应用程序
应用程序
用户视图
外模式B
(用户级逻辑数
据库)
(外部/概念映射)
DBMS
概念模式
(概念/内部映射)
模
内
式
对于上图给出的三层模式,现分述如下:
(1)内模式(internalschema)即存储模式。
它是当数据库在外存储器上存储时,对它的物理结构的描述。
早期的数据库都建立在大、中型计算机上,其内模式通常由系统程序员设计,由他来确定所有数据库文件与索引文件的物理结构。
所以内模式有时也称为系统程序员视图(view),表明它是系统程序员观点下的数据库。
(2)概念模式(conceptualschema)它是对数据库整体逻辑结构的描述。
规模较大的数据库都设有数据库管理员(DataBaseAdministrator),简称DBA由他们来统一管理对数据库的定义、使用与维护,他们对数据库的全局结构必须有清楚的了解。
所以这一模式有时也称为DBA视图,表明它是DBA观点下的数据库。
(3)外模式(externalschema)数据共享是数据库的一大特点。
一个大型数据库通常拥有许多用户。
对某一特定的用户面议,他可能仅对其中的一部分数据感兴趣,不需要访问库中所有的数据,也不必了解数据库的全局结构。
以大型企业的管理信息系统为例,在它的数据库中,可能包括生产、供销、财务、人事等内容广泛的数据库文件。
外模式的作用就是用来定义满足不同用户(例生产、供销、财务、人事等处、科)需要的数据库。
一个数据库只能有一个概念模式,但却允许有多个外模式,每一个外模式都是概念模式的一个子集,包含了允许某一特定用户使用的那部分数据。
由于外模式是对应于用户的,是用户观点下的数据库,所以有时也称为用户视图。
小型数据库可以没有外模式。
此时所有的用户都直接使用概念模式,或者说取整个概念模式作为自己的外模式。
从上面描述可知,所谓三级模式,其实是对同一数据库所作的三种不同的描述。
内模式是计算机上实际存在的数据库,即常说的物理数据库。
概念模式是对内模式的逻辑抽象,外模式则是对概念模式中某个局部的抽象,它们分别对应于佤的和用户级的逻辑数据库。
如上图所示,从一种模式到另一种模式是通过级间“映射(mapping)”实现的。
这种映射功能由DBMS自动提供,不需要由用户进行干预。
2.数据库的设计过程
数据库的设计主要是针对上述三种模式的设计。
由于概念模式和外模式所描述的都是数据库的逻辑结构,所以传统的数据库设计将设计过程概括为两大步,即逻辑设计和物理设计。
当然,在逻辑设计前首先要进行系统分析,弄清用户对系统的需求。
但是,传统的数据库设计在完成需求分析后,随即就开始逻辑设计。
设计人员在满足系统需求的前提下,要同时考虑选择数据模型(层次、网状、关系)、确定存取方法与访问路径、提高存取效率等多方面的问题,难免顾此失彼。
为此,在“1978新奥尔良数据库设计小组工作报告”中,数十位专家一致建议在逻辑设计阶段前增加一个“概念设计”阶段,将设计全过程扩充为四步,如下:
第一阶段:
面向问题
第一步:
系统的需求分析----弄清系统对信息的需求
第二步:
概念设计----确定概念模式
第二阶段:
面向实现
第三步:
逻辑设计----确定概念模式与外模式(逻辑数据库)
第四步:
物理设计----确定内模式(物理数据库)
这样,第一阶段集中于弄清需要解决的问题,第二阶段才考虑怎样去实现,既降低了每一步工作的复杂性,而且使整个工作显得更有条理。
采用美籍华人陈平山创议的“实体-联系模型”(简称E-R模型),可将上图改造为:
需求说明书
系统需求分析
E-R模型
概念设计
逻辑数据库结构
实现设计
物理数据库结构
物理设计
以下对上图进行说明:
(1)需求分析目的是分析系统的需求。
这一步的主要任务是从数据库的所有用户那里收集对数据的需求和对数据处理的需求,并把这些需求写成用户各设计人员都能接受的需求说明书。
(2)概念设计目的是将需求说明书中关于数据的需求综合为一个统一的概念模型。
为此,可首先根据单个应用的需求,画出能反映每一应用需求的局部E-R模型。
然后把这些E-R图合并起来,消除冗余和可能存在的矛盾,得出系统的总体E-R模型。
(需要重申,概念模型是对用户需求的客观反映,并不涉及用什么软硬件来实现它们。
因此,这一步的注意力应该集中在怎样准确表达用户对信息的需求上,暂时不要去考虑怎样实现,以免分散精力。
)
(3)实现设计其目的是将前一步得出的E-R模型转换为某一特定的DBMS能够接受的逻辑模式。
在这一步中,首先要选择一种适当的数据模型(关系、网状、层次)。
由于一种特定的DBMS只支持一种数据模型,所以DBMS一经确定,数据模型也就确定了。
然后可以就按照相应的转换规则将E-R模型转换为所选的DBMS可以接受的数据库逻辑结构。
对于需要外模式的数据库,还应利用概念设计阶段得到的局部E-R模型,参照转换规则设计出供不同用户使用的局部逻辑结构。
通过转换规则形成的全局和局部的逻辑模式,还需要运用有关理论和方法对结构进行优化,然后再转入物理设计。
(4)物理设计目的在于确定数据库的存储结构。
其主要任务包括:
确定数据库文件和索引文件的记录格式和物理结构,选择存取方法,决定访问和外存储器的分配策略等。
由于这些工作都与硬件环境密切相关,所以物理设计包含了许多复杂和细致的工作。
幸运的是,这些工作大部分将由DBMS自动完成,仅有一小部分内容需要设计人员确定。
以FOXPRO为例,其物理设计主要包括确定数据库文件中表的字段类型与长度,决定在哪些字段上建立索引,建立什么样的索引等,实际上比概念设计和实现设计还要简单。
以下是数据库设计过程各阶段工作示意图:
应用1应用2应用n
用户模式求
用户模式求
用户模式求
…
用户需求
应用1
应用2
:
:
局部概念
局部概念
局部概念
逻
辑
数
据
库
E-R
模
型
库
物
理
用户需求
用户需求
应用n
数据库概念设计
需求分析结束后,就可以进行数据库概念设计了。
以下根据上述分析,建立汽车管理信息系统的概念模型。
作为预备知识,下面先对“实体-联系”方法作一简单介绍。
1.实体-联系方法
实体-联系方法(Entity-relationshipapproach)简称E-R方法,是用E-R图来描述现实世界中数据之间联系的有效方法。
自1976年P•P•S•Chen提出这一方法以来,E-R图在设计数据库中被广泛应用,现已成为概念设计阶段描述数据库概念模型的主要工具。
(1)E-R图的基本成分
E-R图中包含实体、联系与属性三种基本成份。
现分述如下:
●实体即现实世界中存在的“人”或“物”。
例如工厂、工人、产品、零件、订货单,都是实体的例子。
在数据库中实体常用来表示某类数据的集合,其范围可大可小,例如工人可表示一个车间的工人,也可表示一个工厂的工人。
●表示实体间存在的关系。
例如,厂长领导工厂,工厂雇用工人,工人生产产品,产品使用零件。
这里的“领导”、“雇用”、“生产”与“使用”都代表实体之间的联系。
联系又可分为一对一(1:
1)、一对多(1:
M)、多对多(M:
N)等类型。
厂长与工厂是一对一的联系,工厂与工人是一对多的联系,工人与产品是多对多的联系,产品与零件也属于多对多的联系。
●属性表示实体或联系的某种特征。
例如,零件可能有编号、名称、库存量、价格等属性;汽车可能有牌号、型号、车主姓名等属性。
值得注意的是联系也可以有属性。
如:
某种产品使用某种零件的“数量”,它既非产品的属性(如果该产品不止使用一种零件),也不能算零件的属性(因为同一种零件可能用在不同的产品上),只能是产品和零件均相关的“使用”属性。
当然,并不是所有联系都必须有属性。
(2)E-R图
在E-R图中,实体、联系与属性分别用矩形框、菱形框和椭圆框(或圆框)来表示。
如下图示例所示:
其中图1给出了实体之间的联系,图2给出了多个实体之间的联系,图3给出了实体和联系的属性。
现实世界中的任何数据集合都可以用E-R图来表示。
修理单
零件
使用
产品
厂长
生产
工人
产品
11MM
雇用
领导
修理
1MNN
修理工
工厂
汽车
工人
工厂
汽车
零件
车主姓名
牌照号
型号
价格
库存量
名称
工厂
使用
零件
产品
数量
在数据库设计中,E-R图常用来表示概念模型,有时亦称为E-R模型。
它直观易懂,也是设计人员和用户之间进行沟通的有效工具。
2.用E-R图描述概念模型
下面以汽车修理管理信息系统为例,说明用E-R方法来建立概念模型的具体步骤。
第一步:
确定E-R模型应含的实体。
如前面所指出的,每一实体可用来代表一类数据的集合。
所以在本例中,可以暂定修理厂原来使用的4种帐册为模型的第一批实体,并分别取名为“汽车”、“修理工”、“修理单”与“零件”。
第二步:
建立对应于系统单项应用的局部E-R模型。
这一步的目的是在实体之间建立所需的联系。
通常的作法是根据对系统的功能分析首先选出一至数项有代表性的单项应用,建立起相应的局部E-R模型。
然后在此基础上逐渐扩充,直到在所有实体之间均建立起应有的联系。
就本例来说,在需求中“开修车发票”是一项有代表性的应用。
计算修理费要用到修理工的“小时工资”和修理单的“修理小时”,计算零件费用时要用到修理单的“零件用量”和零件的“价格”,而发票中的“车主名”和“地址”都要用到汽车的信息。
一项应用涉及到所有4个实体中的数据。
下图给出了“开修车发票”这一单项应用的局部E-R模型。
为简明起见,其中每一实体只画出了在单项应用中用到的属性。
修理
汽车
修理工
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 系统 开发 指导