软件工程导论13章总结.docx

上传人:b****3 文档编号:4647407 上传时间:2022-12-07 格式:DOCX 页数:16 大小:65.11KB
下载 相关 举报
软件工程导论13章总结.docx_第1页
第1页 / 共16页
软件工程导论13章总结.docx_第2页
第2页 / 共16页
软件工程导论13章总结.docx_第3页
第3页 / 共16页
软件工程导论13章总结.docx_第4页
第4页 / 共16页
软件工程导论13章总结.docx_第5页
第5页 / 共16页
点击查看更多>>
下载资源
资源描述

软件工程导论13章总结.docx

《软件工程导论13章总结.docx》由会员分享,可在线阅读,更多相关《软件工程导论13章总结.docx(16页珍藏版)》请在冰豆网上搜索。

软件工程导论13章总结.docx

软件工程导论13章总结

开发软件的基本过程:

提出研制要求

 

生命周期方法:

生命周期法采用介于形式语言和自然语言之间的描述方式,通过一套分层的数据流程图,附以数据字典、小说明等工具来描述系统。

生命周期法的基本思想为保证系统开发的顺利进行,生命周期法强调遵循以下几个基本原则:

(一)面向用户的观点信息系统的目的是为管理人员提供管理和决策信息,能否满足用户的信息需求,是系统成败的重要标志。

实践证明,用户的参与,尤其是领导的介入,是系统成功的关键。

在整个研制过程中,系统研制人员应该始终与用户保持联系,从调查研究入手,充分理解用户的信息需求和业务活动,不断地让用户了解工作进展情况,校准工作方向。

(二)严格区分工作阶段生命周期法强调按时间顺序、工作内容,将系统开发划分为几个工作阶段,如系统规划阶段、系统分析阶段、系统设计阶段、系统实施阶段以及系统运行与维护阶段等等,各个阶段的任务是明确的,过程是循序渐进的。

对于复杂的系统,要强调和加强前期工作,强调分析设计的深入细致,以避免后期返工,造成投资耗费和负社会效益。

(三)自顶向下地完成系统的研制工作在系统分析阶段,从全局出发,对企业进行周密的调查分析,自上而下,从粗到精,由表及里,逐层、逐级进行业务过程分解,最后进行逆向综合和抽象,完成新系统模型的构造。

在系统设计阶段,用划分子系统的方法,把系统逐层分解到详细模块,完成设计方案。

在实施阶段,从实现系统的框架开始,自上而下实现系统功能。

程序设计过程中同样采用结构化设计的方法,自顶向下,逐步求精。

(四)充分考虑变化的情况

组织的经营环境在变化,用户的信息需求也在变化,他们对信息系统的要求会自然越来越高。

生命周期法充分考虑了这种变化,在系统设计中,把系统的可变更性放在了首位,运用模块结构方式来组织系统,使系统的灵活性和可变更性得以充分体现。

(五)工作成果文档化、标准化

系统开发是一项复杂的系统工程,参加人员多,经历时间长。

生命周期法用文档的标准化保证开发工作的连续性,在每个开发阶段,都要用文字、图表表达该阶段的成果,资料格式标准化、格式化。

这些文档资料在开发过程中是开发人员和用户交流思想的工具和媒介,在开发完成后,成为系统维护的依据。

因此,要求文档资料简洁明确,无二义性,既便于研制人员阅读,又便于用户理解。

生命周期法的特点

生命周期法很适合于开发大型的事务处理系统、大型的管理信息系统和可靠性要求很高的复杂应用系统。

也是软件的社会化大生产的有效方法。

生命周期法具有以下特点:

1、强调计划性,排除不确定性。

生命周期法通常假定系统的应用需求是预先描述清楚的,排除所有的不确定性因素。

2、强调分工,严格区分系统开发的各个阶段中的任务和要求,目的明确,任务清楚。

3.强调标准化和规范化,排除个性化和自由发挥。

规范、齐全的文档,严格的审定记录和有序的过程调度。

生命周期法的缺点

生命周期法是最成熟、应用最广泛的一种工程化方法,它也有不足和局限性。

(一)系统需求的不确定性:

1.在系统开发的起始阶段,用户对系统的目的和功能不了解,他们无法准确地描述自己对信息的需求。

2.系统分析人员和用户无法预测组织和系统的未来,按照目前状况描述的系统需求,可靠性可能很差。

3.用户和系统分析人员对信息需求的理解上会有偏差和错误,造成信息需求的描述不准确。

4、组织管理体制的变更,导致信息需求和工作过程发生变化。

(二)开发周期长一个规模较大的系统,其开发过程往往需要一至三年,这样一方面使用户在较长时间内不能得到一个可实际运行的物理系统,使用户有可望而不可及的焦虑;另一方面也难以适应环境变化,因为在开发过程中,信息需求可能已经发生了变化,系统尚未开发出来可能就已经过期了。

(三)文档化工作复杂:

生命周期法在开发的各个阶段中文档很多,工作烦琐,管理费用很高。

(三)缺乏灵活性:

开发中途修改方案的困难很大,涉及到的问题很复杂。

*数据流程图的画法

一般地说,画DFD应遵循“由外向内,自顶向下”原则进行。

由外向内是指:

先标定系统范围。

这个范围就是输入输出之间的部分,该部分的细节暂不考虑。

有时最外部难以表示出来全部数据流,但这不要紧,因为无法表示的内部数据流随着设计过程的深入,逐步会分解、画出并填补上去。

描述系统内部数据流,一般从输入端开始向输出端推进,每当经过使数据流的组成或数值发生变化的地方,就用一个“加工”将其连接起来,这个“加工”正是实现这一数据变化的。

注意,不要把相互无关的数据画成一个数据流,也不要把作为一个处理单位的数据画成两个数据流;如果牵涉到文件,则应表示出“文件”与“加工”的关系(读或写)。

画数据流程图时注意以下两点:

1、应该遵照业务处理过程(即前边的结果),将系统调查的资料和整理数据结合起来,在绘制的过程中不断地与相应的调查记录、数据记录对照,以便能及时发现诸如数据不匹配,流通渠道不畅,处理过程不合理之类的问题。

2、由于实际数据处理过程常常比较繁杂,故应该按照系统的观点,自顶向下地分层展开绘制,即先将比较繁杂的处理过程(不管有多大)当成一个整体处理块来看待(俗称“黑匣子”);然后绘出周围实体与这个整体块的数据联系过程;然后再进一步将这个块展开,如果内部还涉及到若干个比较复杂的数据处理部分的话,又将这些部分分别视为几个小“黑匣子”,同样,先不管其内部,只分析它们之间的数据联系。

这样反复下去,依此类推,直至最终搞清了所有问题为止,也有人将这个过程比喻为使黑匣子逐渐变“灰”,直到“半透明”和“完全透明”的分析过程。

3、数据流程图举例

我们在前边示例中,调查分析该企业财务科数据流程、业务流程及其组织结构图,然后根据其组织结构图(图3.9)从上至下展开,画出各自的数据流程图。

如图3.14,然后将3.14分解细化为图3.15。

在图3.15的基础上,画出第一层对应的数据流程图,如图3.16(a)—(d)。

图3.15的每个处理对应图3.16中的一个数据流程图。

顶层

2

1

3

3.4

3.3

1.4

3.2

35

1.4.2

1.4.3

1.4.5

1.4.4

图3.13结构化分析方法的示意图

 

图3.14会计核算顶层图

图3.15会计核算零层图

 

材料分配表

结构化分析示例

1.2按部

图3.16(a)材料核算

1.3材料

分配

材料消耗汇

门汇总

总表

产品明细目录

部门资料

4.一层图

(2)

考核标准

图3.16(b)工资核算

 

结构化分析示例4.一层图(3)

燃料汇总表

3.16(c)成本核算

结构化分析示例4.一层图(4)

 

3.16(d)综合分析

*画数据流程图的注意事项

1.数据守恒

数据守恒是指输入数据与输出数据匹配。

数据不守恒有两种情况。

一种是某个处理过程用以产生输出的数据,没有输入给这个处理过程,这肯定是遗漏了某些数据流。

另一种是某些输入在处理过程中没有被使用。

2.父子平衡逐步扩展数据流程图,是对上层图(父图)中某些处理框加以分解,下层图(子图)是上层图中某个处理框的“放大”。

父图中某一处理框的输入,输出数据流必须出现在相应的子图中,否则就会出现父图与子图的不平衡,父图与子图的关系,类似于全国地图与各省地图的关系。

在全国地图上标出的主要的铁路、河流,在各省地图上则标得更详细,除了有全国地图上与该省相关的铁路、河流之外,还有一些次要的铁路、公路、河流等,如在上图3.15零层图中的材料核算共有三个入口,表现在图3.16(a)只有三个入口,上下表示是一致的。

3.均匀分解

如果在一张数据流程图中,某些处理已是基本加工,而另一些却还要进一步分解三四层,这样的分解就不均匀。

不均匀的分解不易被理解,因为其中某些部分描述的是细节,而其他部分描述的是较高层的功能。

遇到这种情况,应重新考虑分解,努力避免特别不均匀的分解。

4.适当命名数据流程图中各种成分的命名与易解性有直接关系,所以应注意命名适当。

特别是处理框的命名应能准确地表达其功能,理想的命名由一个具体的动词加一个具体的名词组成,在下层尤其应该如此,例如“工资计算”、“材料分配”等。

画出数据流程图,要验证其正确性。

对一个大型系统不可能一开始就十全十美的,要经过逐步去粗取精,去伪存真的改进过程。

(四)汇总数据流程图通过对数据流程分析,揭示出现行系统具有四个主要处理:

成本核算、材料核算、工资核算和综合分析。

我们从上至下对数据流程图进行汇总,确定该系统的逻辑模型如图3.17。

在数据流程图中显示出系统当前使用的数据存储有:

部门资料、考核标准、产品明细表、工时比例标准、工资文件、其它计算标准、成本历史文件、财务标准文件。

这些数据存储文件的内涵应在数据字典中进行详细描述。

三、数据字典

DFD表达了数据与处理的关系,数据字典(datadictionary,,DD)则是对系统中的数据的详尽描述,它提供对数据库数据描述的集中管理,目的是对收集到的数据进行标准化、统一化,有统一的名称、格式和含义。

数据字典除保存数据名、类型、长度、精度等有关信息外,还包括数据流向的描述和加工的描述,显然数据字典可供设计者和用户双方参照使用,它为系统设计人员提供了一个有力的工具。

单独的DFD和单独DD都没有任何意义,只有两者结合在一起,加上必要的说明才能构成“系统说明书”。

DD产生于数据流图,是对数据流图中的数据流、数据项、文件和加工等描述的产物。

(一)概述

系统分析中所使用的数据字典,主要用来描述数据流程图中的数据流、数据存储、处理过程和外部实体。

数据字典把数据的最小组成单位看成是数据项(数

据元素),若干个数据项可以组成一个数据结构(组合数据项)。

数据结构是一个

递归概念,即数据结构的成分也可以是数据结构。

数据字典通过数据项和数据结构来描写数据流,数据的存储的属性,它们之间的关系如3.18所示

图3.18数据结构与数据项

数据项组成数据结构,数据结构组成数据流和数据存储。

建立数据字典的工作量很大,相当繁琐,但这是一项必不可少的工作。

数据字典在系统开发中具有十分重要的意义,不仅在系统分析阶段,而且在整个研制过程中以及今后系统运行中都要使用它。

数据字典可以用人工方式建立,事先印好表格,填好后接一定顺序排列,就是一本字典。

也可以结合手工的整理,存贮在计算机内,这样使用、维护都比较方便。

(二)数据字典的内容与示例

数据字典中所包括的项目有六类:

数据项、数据结构、数据流、处理逻辑(加工)、数据存储文件、外部实体。

不同类型的项目有不同的属性需要描述,现分

别说明如下:

1、数据项

数据项也称数据元素,是具有独立逻辑含义的最小数据单位,即逻辑上不可再分的数据单位,如学号、姓名等。

对每个数据项的定义包括以下内容:

1数据项的名称、编号、别名和简述;

2数据项的数值范围,如“工资”从200元到500元;

3数据项的长度,如“姓名”可以用四个汉字,即八个字节组成。

数据项定义

数据项编号:

A-004

数据项名称:

库存量

别名:

SL

简述:

某种配件的库存数量长度:

6个字节

取值范围:

0-999999

为了使用方便,可将多个数据项描述在同一表格内,表3.8数据项描述在同

表格内。

表3.8数据项定义

数据项编号

数据项名称

别名

长度

取值范围

简述

A-001

产口口编号

BH

6

0-999999

对不冋产品编号

A-002

产品名称

CPMZ

10

任何汉字、字母或数字

产品的名称

A-003

待产数

DCS

6

0-999999

需要生产数量

A-004

库存量

KCL

6

0-999999

某种配件库存数量

A-005

生产车间

SCCJ

10

任何汉字、字母或数字

指明某零件的生产

单位

2、数据结构

由若干个数据项构成的数据组合称为数据结构,它描述了某些数据项之间的关系。

一个数据结构可以由若干个数据项组成;也可以由若干个数据结构组成;还可以由若干个数据项和数据结构组成。

例如,“产品明细表”这个数据结构可表示为:

产品明细表二产品编号+产品名称+产品型号+产品规格+计量单位+单

在上述例子中,数据结构全部由数据项组成,称为简单的数据结构,在管理信息系统中,由于管理对象的复杂性,嵌套的数据结构是经常出现的。

例如,“销售合同”这个数据结构可表示为:

销售合同=合同编号+订货日期+用户+产品+订货数量+交货日期

在销售合同这个数据结构中,除了合同编号、订货日期、订货数量、交货日期这些数据项外,还包含了“产品”和“用户”两个数据结构。

因此,我们称销售合同是一个嵌套的数据结构。

在数据字典中,对数据结构的定义包括以下几项内容:

1数据结构的名称和编号;

2简述;

3数据结构的组成

如果是一个简单的数据结构,只要列出它所包含的数据项就可以了;如果是一个嵌套的数据结构,需列出它所包含的数据结构名称,因为这些数据结构同样在数据字典中有定义。

例表3.9数据结构定义。

表3.9数据结构定义

数据结构编号

数据结构名称

数据结构组成

简述

B-01

产品明细表

产口口编号+产口口名称+产口口型号+产

品规格+计量单位+单价

B-02

销售合同

合冋编号+订贝日期+用户+产品+

订货数量+交货日期

产品、用户还是数据结构

B-03

用户订货单

订货单标识+用户情况+配件情况

用户所填写用户情况

及订货要求等信息

3、数据流

数据流是表明系统中数据的逻辑流向,该数据可以是数据项或数据结构。

数据流的定义包括以下内容:

1数据流的名称及编号;

2简述;

3数据流的来源;

4数据流的去向;

5数据流的组成;

6数据流的流通量;

7高峰期流通量。

例:

表3.10数据流定义

表3.10数据流定义

编号

名称

简述

据源数来

据向数流

组成

流通

高峰流通量

C-01

半成品收发存日报

生产科为产品流向提供日报

各个生

产车间

半成品仓库

半成品收发存日报的数据结构

30份

/月

每日一份次日上午

8:

00

C-02

发货单

销售科为用户开具的发货单

销售科

用户

发货单数据结构

50份

/日

70份/日上午9:

00-11:

00

4、处理逻辑(加工)

处理逻辑的定义仅对流程图中最低层的处理逻辑加以说明,内容包括:

处理

逻辑名称及编号、输入数据、输出数据、处理频率、处理逻辑。

例:

图3.19是图3.16(b)汇总考核部分的最低层的一个数据流程图,我们对

它的处理过程描述如表3.11o

图3.19

表3.11处理过程描述

处理编号:

D-08

处理名称:

考核

输入数据:

①考勤表(No:

A—002)

②工时表(No:

A—006)

输出数据:

考核汇总表(No:

A—008)

处理逻辑:

1

(自然语言描述表)

、按职工名单填写出勤天数;

2、填写完成工时数量;

3、按照考核标准计算绩效分数:

分数二工时/标准*35%+出勤天数/出勤标准*65%

4、计算奖金系数:

系数二分数*标准*(1+加贴分数+扣除分数+事故分数)

5、汇总各个班组总分;

&汇总车间总分;

7、计算工资总额;

8、计算奖金总额。

5、数据存储文件

数据存储文件是数据流动的暂时或永久保存的地方。

在数据字典中,数据存

储的内容通常由数据存储的编号、名称、简述、组成、关键字和相关的处理等组成。

例:

对示例中的部分文件进行数据存储定义。

表3.12数据存储定义表

编号1

名称

简述

组成

关键字

相关处理

E-03

成本分析

根据产品生产的各项费用与历史费用比较,

进行成本分析

产品编号+产品名称+材料费用+设备费用+工具费用+运输费用+历史费用

产品编号

确定生产情况

E-08

工资文件

存放职工工资情况

职工编号+姓名+职称+基本工资+计件工资+扣除+实发工资

职工编号

确定职工工资总额及发放工资

E-13

产品明细文件

产品目录

编号+名称+规格

+

数量+批号+价格

编号

确定企业的营销策略

6外部实体

在数据字典中,外部实体的定义包括:

外部实体的名称、编号、简述以及相关数据流的输入和输出。

例:

表3.13外部实体的定义

表3.13外部实体的定义

编号

实体名称

简述

输入的数据流

输出的数据流

F-03

客户

购买本公司货物的用户

订货单、发货单

订货单

F-08

职工

本公司在职职工

职工登记表

职工卡

F-10

产品

本公司生产的产品

产品一览表

产品生产情况表

数据字典是系统分析阶段的重要文档,它清楚地定义和详细地解释了数据流程图上未能详细表达的内容。

随着数据流程图自顶向下逐层扩展,数据字典也逐步充实与完善。

数据字典在建立过程中不仅反映了数据流程图中诸元素的关联关系,同时还必须保证数据之间的一致性和完整性,即名称的统一性,编号的唯一性,数据来源与去向的相应关系。

通过数据字典,能对数据流程图中各要素的关系作合理性与统一性的检查;能有效地对资源进行控制和集中。

数据字典是在需求分析阶段建立,并在系统设计过程中不断修改、充实和完善。

四、加工说明

我们知道,数据流程图是分层的,上层的数据流程图表达了系统的主要逻辑功能,随着自顶向下逐层展开,表达的功能越来越具体,直到最底层的数据流程图,系统的全部逻辑功能被详细地表达出来。

因此,系统的最小功能单元就是最底层数据流程图中每个处理加工,称为基本处理(功能单元),对每个基本处理(处理逻辑)已在数据字典中作了定义,在定义中除了指出其特征外,还描述了每个加工所具有的处理功能,但是这种描述毕竟是比较粗糙的,不能充分作为系统设计员和程序员工作的依据,因而有必要采用一定的工具进行更为详细的描述。

对基本处理的描述称为“小说明“或”基本说明”,它是从另一个侧面刻划了系统的局部和细节,说明加工的触发条件,出错处理、优先级等问题,对数据流程图作了必要的补充。

数据流程图,数据字典和加工说明三者构成了系统的逻辑模型。

理想的基本说明应该容易被开发者和用户理解,又要严格、精确,目前人们正在研究具有这种特点的形式语言,但还没有理想的结果,结构化方法在精确性和可理解性中间考虑了折中的方案,用结构化语言,判定表和判定树三种半形式化的方式编写基本说明。

下面分别介绍这三种工具。

(一)结构化语言

与程序设计语言的结构化相似,结构化语言也只允许三种基本逻辑结构:

顺序结构、选择结构和循环结构。

结构化语言与程序设计语言的差别在于结构化语言没有严格的语法规定,与自然语言的最大不同是它只使用极有限的词汇和语句,简洁而明确地表达功能单元的逻辑功能。

结构化语言使用的语句只允许有以下三类:

1、祈使语句祈使语句指出要做什么事情,包括一个动词和一个宾语。

动词指出要执行的功能,宾语表示动作的对象,作宾语的名词在数据字典中已经进行了定义。

例如:

“计算金额”、“获得库存量”、“计算实发工资”等,祈使语句应尽量简短、明了。

2、判断语句判断语句类似于结构程序设计中的条件语句,其一般形式是:

如果条件1

则动作A

否则(条件不成立)

动作B

判断语句中的“如果”、“否则”要成对出现;动作A和动作B可以是一组祈使语句,也可以是判断语句或循环语句,从而形成各种嵌套结构,也允许出现多重嵌套;在多重嵌套的情况下,相应层次的保留字上下对齐,层次清楚,便于阅读。

例如:

本节示例中所述的公司给一次购货在100万元以上的客户以不同折扣率。

如果这样的客户最近3个月无欠款,则折扣率为15%。

;虽然有欠款但与公司已经有10年以上的贸易关系,则折扣率为10%,否则折扣率为5%。

,公司的折扣政策用判断语句表达如下:

如果购货额在100万元以上

与公司交易10年以上折扣率为10%0折扣率为5%

否则

3、循环语句

循环语句是指在某种条件下连续执行相同的动作,直到这个条件不成立为止。

例如:

计算每户的房租、水电费,不仅要计算每一户应交的费用,而且还要计算所有住户所交房费的总和,其循环语句如下:

对每一户计算房租、水电费将房租、水电费加到总计中

在上述循环语句中,“计算房租水电费”已定义

(二)判定树

当某个动作的执行不是只依赖于一个条件,而是和若干条件相关,如果仍用结构化语言表达,可能要使用多层次判断语句,就会比较复杂,不能一目了然。

在这种情况下用判断树更为合适,判断树是用来表示逻辑判断问题的一种工具。

它用“树”来表达不同条件下的不同处理,比用语言的方式更为直观。

判断树的左边为树根,从左向右依次排列各种条件,左边的条件比右边的优先考虑,根据每个条件的取值不同,树可以产生很多分支,各分支的最左端(即树梢)即为不同的条件取值状态下采取的行动(也称策略)。

前面提到关于折扣率的规定就涉及三个条件:

购货款、最近3个月有无欠款、贸易时间是否超过

10年。

这个规定用判定树可表示如下:

由上可知,判断树的优点是直观和明确,可以清楚地看出各种条件下的不同取值状态下应当采取的行动,还可以看出根据条件的优先级别逐步判断、决策的过程。

(三)判断表

判断表是另外一种表达逻辑判断的工具。

与结构化语言和判定树方法相比,

判断表的优点是能够把所有的条件组合充分的表达出来。

其缺点是判断表的建立

过程较为繁杂,且表达方式不如前两者简便。

例如:

对前边提到的折扣政策的例子,可用判断表3.14表达如下:

判断表分成四大部分,左上角为条件说明,左下角为行动说明,右上角为各种条件全部组合,右下角为各种条件组合下采取的行动。

判断表要反映出所有的条件组合,若有Q1、Q2……共N个条件,每个条件分别可取W1、W2……Wn个值,则全部条件组合有W1xW2X……xWn个。

本例中由于各条件均取两个值,所以共有2X2X2=8个条件组合,每个条件组

合及相应行动见表3.14。

丫一表示成立N—表示条件不成立V—表示采取此行动。

表3.14折扣政策条件判断表

各种条件组合条件与行动

1

2

3

4

5

6

7

8

Q1:

交易额〉=100万元

N

N

N

N

Q2:

最近3月无拖欠款

N

N

N

N

Q3:

与本公司交易〉=10年

N

N

N

N

A1:

折扣率15%

V

V

A2:

折扣率10%

V

A3:

折扣率5%

V

A4:

无折扣

V

V

V

V

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 初中教育 > 语文

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1