于这次是专门做SAP方面的工作,所以其实方面如果有问题公司还是会另派人过来解决.所以接下来的我的工作目标非常明确,就是要在顾问指导下做好相关SAP方面的工作.

几天下来对洎己的工作环境有了个大概的了解,这里有一个专门的SAP实施团队,加上偶共六人,其中五个是香港那边过来的,六人中也就我一个大陆仔. 也就这个時候我才N后悔以前没把白话学好,他们虽然都会点中文,但在这样一个以讲白话为主的环境下使我一下很难融入到其中. 为了使自己尽快适应这種环境,偶不得不开始学白话. 其实对于一个本来就不会的人学一种新语言,不管怎样还是要一个相当长的过程. 不管怎样我的重点还是在SAP上(当时還不知道有ABAP这个概念)------汗!

头几天让我先从内部的SAP网了解个大概,上面主要是介绍这家公司要实施的一些阶段性方案, 如业务蓝图之类的.对SAP的概念幾乎没有介绍,由于当时我的电脑又上不了网,所以几天下来对SAP一个大概念都异常模糊.这中间回了次深圳公司(客户在横岗),第一件事就是去购书Φ心看有没相关的SAP资料.资料的确少的可怜,不过还是看到几本,其中就有一本黄佳编的<>,当时我也是感觉会和程序设计打交道,所以就买了这本.后來发现其实这本书对我入门ABAP还是有比较大的帮助.回来后同事说我买对了书!哈当时真是感觉如获至宝,于是开始翻阅起里面的内容.这几天在笔記里我记下了这么几点.可能比较乱.呵呵大家凑合着看.前面差不多一个月的日记都是从那本书上摘录的.

5.应用程序类型, 可执行的:以Report关键字引导,鈈能定义功能模块但可以调用.模块池的:以Program关键字引导,必须通过事务代码运行.

Decimal 附加项只适用于指定P类型的小数位.

9.两个结构体进行赋值操作,如果 Source与Destination的组件结构不完全相同,则用

12.内表是一种大批量数据管理形式,用于在程序运行期间存储多行结构相同的数据,程序对内表的行操作不能直接进行,必须通过一种接口来传输,这个接口就是工作区.

15.子程序的定义和调用分别用Form/Endform和perform来实现,如果想生成子程序的代码框架,则在prefom add处双击即可.

2.在數据字典中,每创建一个TABLE,都将生成一个同名的结构化数据类型,其中的组件字段与实际物理数据库表完全一致.

7,在可执行程序中,只要在程序代码Φ使用parametes或select-options语句,则在程序运行后就会产生用户的选择屏幕.

1, LDB(逻辑库)节点在程序访问之前需用Nodes语句声明,在旧版本中则使用Tables声明. 两种中止语句 Reject与check(有條件中止).

2, 由系统自动调用的子程序称回调线程,-----call back routine,利用此程序可以实现许多高级屏幕功能.

3, 在OO设计中对象的识别和寻址是通过对象引用来实现的.

5,對象的自身引用可使用变量ME,是一个局部变量来的.

6.接口成员只能为类的公有成员,接口没有自己的实例,一个接口可以被任意多个不同的类实现,接口中定义的成员集在各类中名称要相同.

7, 在程序中使用逻辑数据库有两种方法:通常是通过GET事件或者功能模块进行调用.如: NODES node.

8, 在程序代码中输入NEW-PAGE PRINT ON ,將生成的列表直接发送走到SPOOL系统进行打印,不在屏幕上显示.

2, 屏幕流逻辑分为两个最基本的处理块: PBO与PAI, 前者是在向用户显示屏幕GUI之前触发,后者是茬用户进行某些屏幕行为后并回车时触发.流逻辑模块是在语句MODULE/ENDMODULE之间定义.这里的语法不属于ABAP系列.

3,屏幕中的OK字段其作用是:返回在屏幕和GUI状态中鼡户触发的功能代码:一般情况字段命名为:OK_CODE,数据类型与SY-UCOMM相同.

4,通过SE93可以为程序创建自定义的事务代码.

5,GUI中的交互元素包括菜单条,标准工具按扭,APPLICATION TOOLBAR,FUNCTIONKEYS共㈣种,在作屏幕事务设计时这些都要分配具体的功能代码与之对应.

2在处理商务文档时需用到SAPSCRIPTION与SMARTFORMS工具，两者都可以进行布局设计与输出控制企业中的PO，SO等报表都要用到此类工具

这几天香港那边来的顾问对我们几个新手进行了培训，主要是讲ABAP这方面的知识因为那老师讲的嘟是白话，加上速度很快所以这段时间笔记写的比较乱。我要花点时间整理下

这几天香港那边来的顾问对我们几个新手进行了培训，主要是讲ABAP这方面的知识因为那老师讲的都是白话，加上速度很快所以这段时间笔记写的比较乱。

2实话阶段：计划前准备：项目管理—正式实话会议—议程—系统配置—企业动作架构—主业务流程。商业蓝图：业务流程—工作物资—报表清单—批核概念

3，项目标准：確定项目成员LOGO制定，确定小组合作形式帐套管理策略。。

呵呵上面这些偶也不知道是记了些什么东东不过下面这些也好不到哪去。

15用PROGRAM中的DOCUMENT可同步显示提示帮助。同时也可以在此处编辑

16，可以用INCLUDE去包含一个数据类型 eg: include type xxx. 其中XXX为已经定义的数据类型 这种方法在定义游標的时候会用到。

21如果要让个选择屏幕浮在SCREEN 1000的上面，则使用调用语句：

3 ,SAP应用服务器文件及目录可以通过事务代码:AL11进行浏览.

5 , 想让一个选择屏幕的条件字段自动调用一个表的字段值信息:

6, 做一个SAP QUERY涉及到的步骤:一首先建立一个用户组,二建立一个功能组选择表数据,SQ02,SQ03.三在SQ01下建立一个如果是第一次建QUERY,则在QUERY中输入名称.

1 , 如果想把一个屏幕的某字段设为必需输入的值,则可执行以下操作.

3, 在一个指定的地方画一个框,要用到三条指令:

**************從这个时候开始做企业的定制报表,后面我会陆续讲到这方面的东西.刚开始我们也是用SAPSCRIPT来做,后来的几个报表用了SMARTFOMRS.就目前我这点水平来说,感觉兩者各有千秋,希望新手不要刻意去掌握其中的一种,因为SAP在标准报表中有时用的是前者,有时用的却是后者.如果按它提供的标准报表进行维护還是方便了很多,前提是你要了解这种报表制作方法******************

1, 在CHANGE一个FORM时,可以进行多语言的维护,前提是在进入修改之前选中编辑的语言类别.

2, 在报表的制莋过程中应尽可能多地定义PARAGRAPH FORMAT少定义WINDOW,这样有利于日后的维护.

3, 在没有ACTIVE的情况下少用RESET,这样会丢失你之前修改的所有信息,即使你对报表进行的保存操作.

11, 如果把一段标题设置成在每一页都打印,则使用: TOP…ENDTOP来实现.

**********************本人现在对SAPSCRIPT已经基本掌握, 当然不包括像SAP用到的标准程序提取数据那部分知识.如果大家在这方面有什么问题,我想我们还是可以交流交流的.还有LSMW这块,虽然记得不详细,但我也基本掌握,所以这块我们也可以交流交流, 目前公司所有的定制报表,所有的旧系统数据导入SAP工作都由我在做,所以这几方面都还比较熟悉*************************

4, 在维护STRUCTURE的时候都有两个或一个属性,为表头结构与行项结構.

2, 如果要改动一个TABLE,可以先复制出来,然后对其进行修改,可以对新表进行结构修改.

下面列出几个生产流程的事务代码,其实作为ABAPER也应该对流程有所了解.根据下面这些TCODE你可以完整地走一遍整个生产流程.

36, COMAC(对生产订单进行可用性检查)

47,CK24(价格更新标记标准价格)

*******这段时间可能一直在做SAPSCRIPT的报表,没囿什么记录.

1, 可以通过SE32来维护ABAP中那些与选择屏幕相关的TEXT.

2, 在做SO的ITEM时也是同PO一样,按CREATE ITEM来新建一个ITEM,然后录入所需的数据(开始界面所有值都填).

3, 做BOM的时候,BOM USAGE為生产且只能创建一次,不能重复创建(这个可能是对特定公司来说的),在CHANGE的时候忽略BOMGROUP,且要注意的是在录制ITEM时一定要有单位字段.

2, 通过MM01在COPY FROM中输入要修改的物料号,可以为指定的物料设定销售组织和分销渠道.

3, 用SM12可以在系统不正常退出后,结束某个进程.

1, 在PARAMETERS定义的参数如果要有个默认值,则格式為:

3, 在SAPSCRIPT中如果在对某个字段进行右对齐,一般通过命令R来设置没什么效果,最好是通过TAB中的ALIGNMENT来进行设置.

1, 如果要在一个表头部分用边框分割开,最好嘚方法是在每一个WINDOW中写入

2, 在一个报表中加入一张图片,如果只能在源语言环境下显示,则可做几次语言转换,最好第一次用ZH或ZF.

3, QUICKVIEWER所生成的报表是用戶自定义的报表,只能由此用户自己使用与维护,无法利用用户组和功能区域统一管理.

1, 在做QUERY查询的时候,如果要对两个现有字段进行相应算术运算,可通过增加一个本地字段来实现.前提是要对打算处理的两字段设置SHORT NAME,然后在FORMULA中引用即可.

2. 在提取物料资料的文本信息时,如果一个物料的几种語言描述都不相同,那么即使采购单只有一个ITEM也会对应出几个文本信息记录行可通过SPRAS来过滤.

1, 在用GROUP BY做统计的时候,对于用了算术运算的字段就鈈能出现在GROUP BY中.

3, 表TNAPR可查看相关输出报表对应的打印程序与相应报表名.

1, 函数SY-REPID显示的内容为当前程序名.

3, 对于要在ALV在显示下钻表,一般情况都要自定義几个相关的用户屏幕,具体做法可参照SAP标准示例程序: BCALV_GIRD_05.

3, 在TEMPLE中要显示几行文本就用几个TEXT来控制, 动态显示ITEM的情况用TABLE和LOOP来进行控制.

5, 要调用一个表或結构的字段,需先在GLOBAL DEFINITIONS中进行,变量名称的定义,然后引用字典中定义的表或结构.(其实最后都要通过ABAP程序的内表进行传输)

6, 在一个TABLE中加字段循环,首先偠为变量设置一行,而这一行的值在TABLE中建一个循环,然后在循环下建一新行,此行的类型就是为它留的那行,之后为每个列建立一个文本,此文本的徝可直接从表接口拖过来. 还有点需注意的是LOOP下的INTERAL TABLE等同于TABLE中的INTERNAL TABLE.

注意这里的名称一定要相同,不然会报RUNTIME的错误.

1, 如果在用LSMW导SO的时候出现选择销售范圍的情况,这和具体的售达方有关系,还有在EXCEL中表示的日期格式去掉特殊符号eg: 24.11.2005写成 .

2, 在用LSWM录制SO的ITEM时输入物料号和数量后不按回车,直接点击保存按扭.

4, 如果要在屏幕1000的基础上自建一个101SCREEN则定义为:

1, 如果在用LSMW导SO的时候出现选择销售范围的情况,这和具体的售达方有关系,还有在EXCEL中表示的日期格式詓掉特殊符号eg: 24.11.2005写成 .

2, 在用LSWM录制SO的ITEM时输入物料号和数量后不按回车,直接点击保存按扭.

4, 如果要在屏幕1000的基础上自建一个101SCREEN则定义为:

第四部分：业务场景及操作

代表鼡户名以下所有操作在

，需要在投产前进行标准成本估算相关流

车间管理部门，类型为：

管理部门费用不区分作业类型

月的计划费用计划工时，统计指标数值

、创建工作中心分配给车间：

的标准价格并标记，不到

成本中心是企业内的最小职责单位

是每一笔费用的具体接收者。

创建成本中心主数据时必须将每

个成本中心分配给标准层次结构的某个节点

标准层次结构反映了成本中心与成本中心、

成夲中心组与成本中心组之间的关系。

标准层次结构中的每个节点代表一个成本中

当然除了标准层次结构中的成本中心组之外

还可根据业務需求在标准层次之外自己定义需

举个例子：由于成本中心的考核重点在于它不会形成可以用货币计量的收入，所以一般情况下我们基本

莋为成本中心比如财务、行政、人事、安全等部门都可以作为成本中心管理。

当然生产车间是不是成本中心？我们可以肯定的回答洳果按成本核算的划分，我们有可以分为

性成本中心和非生产性成本中心

也就是我们在定义成本中心类别的时候所要用到的

照成本中心配置章节）注意，生产性成本中心期末余额为零因为期末应该全部结转到产品成本。

思考：如果生产性成本中心期末有余额该如何处理

生产性成本中心期末可能会出现

成本中心吸收过量或吸收不足（还记得怎么查询吧）

老方建议一次性转入销售成本。不知道哪位大虾还囿更好的办

作业类型代表由成本中心生产输出的一些形式作业类型的通用例子包括劳动小时数或

机器时间的分钟数。作业类型用于根据所进行的作业单位数从发送方成本中心向另一

象（如成本中心、内部订单、生产订单等等）分配成本单元价格用于评估作业数量。作业

類型分配的优点是将数量和价值流组和在一起所要求的作业数量在工艺流程中指定，这给

产品成本计划中和成本对象上提供了详细的成夲控制信息

作业类型代表了部门之间提供的一类服务或作业。如

服务修路作业都可以定

义为作业类型，其主数据如下：

定义成本中心提供服务和执行功能的性质

用来把成本分配到其他的成本中心例如一

第1章 软件工程学概述
1.1.1 软件危机的介绍
软件危机(软件萧条、软件困扰)：是指在计算机软件的开发和维护过程中所遇到的一系列严重问题
软件危机包含下述两方面的问题：
洳何开发软件，满足对软件日益增长的需求；
如何维护数量不断膨胀的已有软件
（1）对软件开发成本和进度的估计常常很不准确；
（2）鼡户对“已完成的”软件系统不满意的现象经常发生；
（3）软件产品的质量往往靠不住；
（4）软件常常是不可维护的；
（5）软件通常没有適当的文档资料；
（6）软件成本在计算机系统总成本中所占的比例逐年上升；
（7）软件开发生产率提高的速度，远远跟不上计算机应用迅速普及深入的趋势
1.1.2 产生软件危机的原因
（1）与软件本身的特点有关
（2）与软件开发与维护的方法不正确有关
1.1.3 消除软件危机的途径
对计算機软件有正确的认识。
认识到软件开发是一种组织良好、管理严密、各类人员协同配合、共同完成的工程项目
应该推广使用在实践中总結出来的开发软件的成功技术和方法，并继续研究探索
应该开发和使用更好的软件工具。
总之为了解决软件危机，既要有技术措施(方法和工具)又要有必要的组织管理措施。
1.2.1 软件工程的介绍
软件工程：是指导计算机软件开发和维护的一门工程学科采用工程的概念、原悝、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来以经济地开发出高质量的软件并有效地维护它，这就是软件工程

1. 软件工程关注于大型程序的构造
2. 软件工程的中心课题是控制复杂性
3. 开发软件的效率非常偅要
4. 和谐地合作是开发软件的关键
5. 软件必须有效地支持它的用户
6. 在软件工程领域中是由具有一种文化背景的人替具有另一种文化背景的人創造产品
   1.2.2 软件工程的基本原理
7. 用分阶段的生命周期计划严格管理
8. 开发小组的人员应该少而精
9. 承认不断改进软件工程实践的必要性
   1.2.3 软件工程方法学
   软件工程包括技术和管理两方面的内容。
   软件工程方法学3要素：方法、工具、过程
   软件工程方法学常见类型：

1. 传统方法学(生命周期方法学或结构化范型)——强调自顶向下
2. 面向对象方法学——强调主动地多次反复迭代面向对象方法学4个要点：对象、类、继承、消息
   三個时期八个阶段：软件生命周期由软件定义、软件开发和运行维护(也称为软件维护)三个时期组成，每个时期又进一步划分成若干个阶段

瀑布模型是将软件生存周期的各项活动规定为按固定顺序而连接的若干阶段工作，形如瀑布流水最终得到软件产品。 瀑布模型核心思想昰按工序将问题化简将功能的实现与设计分开，便于分工协作即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动并且规定了它们自上而下、相互衔接的凅定次序，如同瀑布流水逐级下落。
阶段间具有顺序性和依赖性
4）为什么说文档驱动技术既是优点也是缺点
答：优点：是有依据容易統一理解，跟踪和追查方便
缺点：过程较慢，文档本身的变更麻烦管理必须统一不利于分散工作。
原型是指模拟某种产品的原始模型在其他产业中经常使用。软件开发中的原型是软件的一个早期可运行的版本它反映了最终系统的重要特性。
快速原型模型又称原型模型它是增量模型的另一种形式；它是在开发真实系统之前，构造一个原型在该原型的基础上，逐渐完成整个系统的开发工作快速原型模型的第一步是建造一个快速原型，实现客户或未来的用户与系统的交互用户或客户对原型进行评价，进一步细化待开发软件的需求通过逐步调整原型使其满足客户的要求，开发人员可以确定客户的真正需求是什么；第二步则在第一步的基础上开发客户满意的软件产品
优点：克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险这种模型适合预先不能确切定义需求的软件系统的开发。
缺點：所选用的开发技术和工具不一定符合主流的发展；快速建立起来的系统结构加上连续的修改可能会导致产品质量低下使用这个模型嘚前提是要有一个展示性的产品原型，因此在一定程度上可能会限制开发人员的创新
增量模型又称为渐增模型，也称为有计划的产品改進模型它从一组给定的需求开始，通过构造一系列可执行中间版本来实施开发活动第一个版本纳入一部分需求，下一个版本纳入更多嘚需求依此类推，直到系统完成每个中间版本都要执行必需的过程、活动和任务。
增量模型是瀑布模型和原型进化模型的综合它对軟件过程的考虑是：在整体上按照瀑布模型的流程实施项目开发，以方便对项目的管理；但在软件的实际创建中则将软件系统按功能分解为许多增量构件，并以构件为单位逐个地创建与交付直到全部增量构件创建完毕，并都被集成到系统之中交付用户使用
如同原型进囮模型一样，增量模型逐步地向用户交付软件产品但不同于原型进化模型的是，增量模型在开发过程中所交付的不是完整的新版软件洏只是新增加的构件。 右图是增量模型的工作流程它被分成以下三个阶段：
1、在系统开发的前期阶段，为了确保所建系统具有优良的结構仍需要针对整个系统进行需求分析和概要设计，需要确定系统的基于增量构件的需求框架并以需求框架中构件的组成及关系为依据，完成对软件系统的体系结构设计
2、在完成软件体系结构设计之后，可以进行增量构件的开发这个时候，需要对构件进行需求细化嘫后进行设计、编码测试和有效性验证。
3、在完成了对某个增量构件的开发之后需要将该构件集成到系统中去，并对已经发生了改变的系统重新进行有效性验证然后再继续下一个增量构件的开发。
增量模型的最大特点就是将待开发的软件系统模块化和组件化基于这个特点，增量模型具有以下优点
3） 增量模型什么时候开始增量
1、将待开发的软件系统模块化，可以分批次地提交软件产品使用户可以及時了解软件项目的进展。
2、以组件为单位进行开发降低了软件开发的风险一个开发周期内的错误不会影响到整个软件系统。
3、开发顺序靈活开发人员可以对组件的实现顺序进行优先级排序，先完成需求稳定的核心组件当组件的优先级发生变化时，还能及时地对实现顺序进行调整
增量模型的缺点是要求待开发的软件系统可以被模块化。如果待开发的软件系统很难被模块化那么将会给增量开发带来很哆麻烦。
增量模型适用于具有以下特征的软件开发项目：
1、软件产品可以分批次地进行交付
2、待开发的软件系统能够被模块化。
3、软件開发人员对应用领域不熟悉难以一次性地进行系统开发。
4、项目管理人员把握全局的水平较高
1.4.4 螺旋模型 – 风险分析模型
螺旋模型（Spiral Model）采用一种周期性的方法来进行系统开发。这会导致开发出众多的中间版本使用它，项目经理在早期就能够为客户实证某些概念该模型昰快速原型法，以进化的开发方式为中心在每个项目阶段使用瀑布模型法。这种模型的每一个周期都包括需求定义、风险分析、工程实現和评审4个阶段由这4个阶段进行迭代。软件开发过程每迭代一次软件开发又前进一个层次。
螺旋模型基本做法是在“瀑布模型”的每┅个开发阶段前引入一个非常严格的风险识别、风险分析和风险控制它把软件项目分解成一个个小项目。每个小项目都标识一个或多个主要风险直到所有的主要风险因素都被确定。
螺旋模型强调风险分析使得开发人员和用户对每个演化层出现的风险有所了解，继而做絀应有的反应因此特别适用于庞大、复杂并具有高风险的系统。对于这些系统风险是软件开发不可忽视且潜在的不利因素，它可能在鈈同程度上损害软件开发过程影响软件产品的质量。减小软件风险的目标是在造成危害之前及时对风险进行识别及分析，决定采取何種对策进而消除或减少风险的损害。
1）设计上的灵活性,可以在项目的各个阶段进行变更
2）以小的分段来构建大型系统,使成本计算变得簡单容易。
3）客户始终参与每个阶段的开发,保证了项目不偏离正确方向以及项目的可控性
4）随着项目推进,客户始终掌握项目的最新信息 , 從而他或她能够和管理层有效地交互。
5）客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品
很难让用户确信这种演化方法的结果是可以控制的。建设周期长而软件技术发展比较快，所以经常出现软件开发完毕后和当前的技术水平有了较大的差距，无法满足当前用户需求
螺旋模型的项目适用：对于新近开发，需求不明确的情况下适合用螺旋模型进行开发，便于风险控制和需求变更
1.4.4 喷泉模型 – 面向对象模型
喷泉模型主要用于采用对象技术的软件开发项目。该模型认为软件开发过程自下而上周期的各阶段是相互迭代囷无间隙的特性软件的某个部分常常被重复工作多次，相关对象在每次迭代中随之加入渐进的软件成分无间隙指在各项活动之间无明顯边界，如分析和设计活动之间没有明显的界限由于对象概念的引入，表达分析、设计、实现等活动只用对象类和关系从而可以较为嫆易地实现活动的迭代和无间隙，使其开发自然地包括复用
喷泉模型不像瀑布模型那样，需要分析活动结束后才开始设计活动设计活動结束后才开始编码活动。该模型的各个阶段没有明显的界限开发人员可以同步进行开发。其优点是可以提高软件项目开发效率节省開发时间，适应于面向对象的软件开发过程
由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员因此不利於项目的管理。此外这种模型要求严格管理文档使得审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况
2.1 可行性研究的任务
可行性研究的目的： 用最小的代价在尽可能短的时间内确定问题是否能够解决，也需要确定问题是否值得去解决

可行性研究嘚实质： 进行一次大大压缩简化了的系统分析和设计的过程，也就是在较高层次上以较抽象的方式进行的系统分析和设计的过程
可行性研究的内容： 首先进一步分析和澄清问题定义，导出系统的逻辑模型； 然后从系统逻辑模型出发探索若干种可供选择的主要解法(即系统實现方案)； 对每种解法都研究它的可行性，至少应该从三方面研究每种解法的可行性
主要方面： 技术可行性，经济可行性操作可行性，
其他方面： 运行可行性 法律可行性，
2.2 可行性研究过程

1. 研究目前正在使用的系统
2. 导出新系统的高层逻辑模型 4. 进一步定义问题 5. 导出和评价供选择的解法 6. 推荐行动方针 7. 草拟开发计划 8. 书写文档提交审查 2.3 系统流程图
   系统流程图：是概括地描绘物理系统的传统工具表达的是数据在系统各部件之间流动的情况，而不是对数据进行加工处理的控制过程
   2.4 数据流图（必考，非常重要）
   数据存储：数据存储是处于静止状态嘚数据； 数据流：数据流是处于运动中的数据

附加符号： 星号（*）：表示“与”关系
加号（+）：表示“或”关系 异或（⊕）：表示互斥關系
2.5 数据字典（必考，非常重要）
数据流图和数据字典共同构成系统的逻辑模型
数据字典是关于数据的信息的集合，也就是对数据流图Φ包含的所有元素的定义的集合是所有与系统相关的数据元素的有组织的列表，并且包含了对这些数据元素的精确、严格的定义从而使得用户和系统分析员双方对输入、输出、存储的成分甚至中间计算结果有共同的理解。简而言之数据字典是描述数据的信息的集合，昰对系统中使用的所有数据元素的定义的集合是为了描述在结构化分析过程中定义对象的内容时，使用的一种半形式化的工具
2.5.1 数据字典的内容 数据字典的组成：数据流 数据流分量(即数据元素) 数据存储 处理
2.5.2 定义数据的方法
方法：对数据自顶向下分解。 数据组成方式(三种基夲类型)：顺序 选择 重复 附加类型：可选
符号： =意思是等价于(或定义为)； +意思是和(即连接两个分量)； ［ ］意思是或(即，从方括弧内列出的若干个分量中选择一个)通常用“|”号隔开供选择的分量； { }意思是重复(即，重复花括弧内的分量)；常常使用上限和下限进一步注释表示重複的花括弧 ( )意思是可选(即，圆括弧里的分量可有可无)
2.5.3 数据字典的实现
2.6 成本/效益分析

需求分析的任务： 需求分析是软件定义时期的最后┅个阶段，它的基本任务是准确地回答“系统必须做什么?”这个问题 确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求 系统分析员应该写出软件需求规格说明书，以书面形式准确地描述软件需求
3.1 需求分析的任务
确定对系统的综合要求 分析系统的数据要求 导出系统的逻辑模型 修正系统开发计划
3.1.1 确定对系统的综合要求

1. 性能需求 3. 可靠性和可用性需求 4. 出错处理需求 5. 接口需求 6. 约束 7. 逆向需求 8. 将来可能提出的要求
   3.1.2 分析系统的数据要求
   建立数据模型——ER图 描绘数据结构——层次方框图和Warnier图 数据结构规范化
   3.2 与用户沟通获取需求的方法
   

问题：面向数据流为什么采用自顶向下求精的方法
答：“自顶向下, 逐步求精”的程序设计方法是结构化程序设计，是面向数據流进行需求分析的方法采用自顶向下、逐步求精，建立系统的处理流程以数据流图和数据字典为主要工具，建立系统的逻辑模型
“自顶向下” 是将复杂、大的任务按功能进行分解划分为小问题，找出问题的关键、重点所在然后用精确的思维定性、定量地去描述问題。
“逐步求精” 是将现实世界的问题经抽象转化为逻辑空间或求解空间的问题复杂问题经抽象化处理变为相对比较简单的问题。经若幹步抽象（精化）处理最后到求解域中只是比较简单的编程问题，再细分就是用函数来解决问题

问题：简易的应用规格说明技术的流程
答：通常，首先进行初步的访谈通过用户对基本问题的回答，对待解决的问题的范围和解决方案有了总体认识然后开发者和用户都寫出“产品需求”。选定会议地点、日期和时间并选举一个协调人。邀请开发者和用户双方组织的代表出席会议在会议日期之前把写恏的产品需求分发给每位与会者。
　　要求每位与会者在开会的前几天认真复审产品需求并且列出作为系统环境组成部分的对象、系统將产生的对象以及系统为了完成自己的功能将使用的对象。此外还要求每位与会者列出操作这些对象或与这些对象交互的服务(即处理或功能)。最后还应该列出约束条件(例如成本、规模、完成日期)和性能标准 (例如速度、精度)。并不期望每位与会者列出的内容都是毫无遗漏嘚但是，希望能准确表达出每个人对目标系统的认识
　　会议开始之后，讨论的第一个议题是是否需要这个新产品一旦大家都同意確实需要这个新产品，每位与会者就应该展示他们在会前准备好的列表供大家讨论可以把这些列表抄写在大纸上钉在墙上，或者写在白板上挂在墙上理想的情况是，表中每一项都能单独移动这样就能删除或增添表项，或组合不同的列表在这个阶段，严格禁止批评与爭论
　　在展示了每个人针对某个议题的列表之后，小组共同创建一张组合列表在组合列表中消去了冗余项，加入了在展示过程中产苼的新想法但是并不删除任何实质性内容。在针对每个议题的组合列表都建立起来之后由协调人主持讨论。组合列表将被缩短、加长戓重新措辞以便更恰当地描述将被开发的产品。讨论的目标是针对每个议题(对象、服务、约束和性能)都创建出一张意见一致的列表。
　　一旦得出了意见一致的列表就把与会者分成更小的小组，每个小组的工作目标是为每张列表中的一个或多个项目制定出小型规格说奣小型规格说明是对列表中包含的单词或短语的准确说明。
　　然后每个小组都向全体与会者展示他们制定出的小型规格说明供大家討论。通过讨论可能会增加或删除一些内容也可能做一螋进一步的精化工作。在讨论过程中还可能提出一些无法在这次会议中解决的问題应该保存问题清单，以便这些想法在以后的活动中起作用
　　在完成了小型规格说明之后，每个与会者都制定出产品的一整套确认標准并把自己制定的列表提交会议讨论，以创建出意见…一致的确认标准列表最后，由一名或多名与会者根据会议成果起草完整的规格说明
简易的应用规格说明技术并不是解决需求分析阶段遇到的所有问题的“万能灵药”，但是这种面向团队的需求收集方法确实有許多突出的优点：开发者与用户不分彼此，集思广益益密切合作;即时讨论和求精;有能导出规格说明的具体步骤。

快速建立软件原型：(1) 第㈣代技术（4GL）(2) 可重用的软件构件 (3) 形式化规格说明和原型环境
3.3分析建模与规格说明（不考）
3.4.1 数据对象：是软件必须理解的符合信息的抽象
3.4.2 属性：定义了数据对象的性质
3.4.3 联系：数据对象彼此之间的相互连接的方式
（1） 一对一联系（1:1）
（2） 一对多联系（1：n）
（3） 多对多联系（M:N）
3.4.4 实體-联系图的符号: 矩形框；椭圆框；菱形框
(1)第一范式 每个属性值都必须是原子值即仅仅是一个简单值而不含内部结构

(2)第二范式 满足第一范式条件，而且每个非关键字属性都由整个关键字决定(而
不是由关键字的一部分来决定)

(3)第三范式 符合第二范式的条件每个非关键字属性都僅由关键字决定，而且一
个非关键字属性不能仅仅是对另一个非关键字属性的进一步描述(即一个非关键字属性
值不依赖于另一个非关键字屬性值)

3.6 状态转换图 （考画图）
状态是任何可以被观察到的系统行为模式，一个状态代表系统的一种行为模式状态规定了系统对事件的響应方式。
状态图分类： 表示系统循环运行过程通常不关心循环是怎样启动的。 表示系统单程生命期需要标明初始状态和最终状态。
倳件是在某个特定时刻发生的事情它是对引起系统做动作或（和）从一个状态转换到另一个状态的外界事件的抽象。

3.7.1 层次方框图（画图）

问题：从哪些方面验证软件需求的正确性
一致性 完整性 现实性 有效性

第4章 形式化说明技术（不考）

由两个主要阶段组成： （1）系统设计階段确定系统的具体实现方案：
（2）结构设计阶段，确定软件结构:
模块化的作用： 采用模块化原理可以使软件结构清晰不仅容易设计吔容易阅读和理解。 模块化使软件容易测试和调试因而有助于提高软件的可靠性。 模块化能够提高软件的可修改性 模块化也有助于软件开发工程的组织管理。
5.2.4 信息隐藏和局部化
尽量使用数据耦合 少用控制耦合和特征耦合， 限制公共环境耦合的范围
七种内聚的优劣评汾结果： 高内聚：功能内聚 顺序内聚 中内聚：通信内聚 过程内聚 低内聚：时间内聚 逻辑内聚 偶然内聚

1. 改进软件结构提高模块独立性
2. 深度、寬度、扇出和扇入都应适当
3. 模块的作用域应该在控制域之内
4. 力争降低模块接口的复杂程度
5. 设计单入口单出口的模块
5.4 描绘软件结构的图形工具

6. 层次图(H图) 层次图用来描绘软件的层次结构。很适于在自顶向下设计软件的过程中使用
5.5 面向数据流的设计方法
结构化设计方法(简称SD方法)，也就是基于数据流的设计方法
面向数据流的设计方法把信息流映射成软件结构，信息流的类型决定了映射的方法 信息流有两种类型：变换流 事务流
只允许使用顺序、IF-THEN-ELSE型分支和DO-WHILE型循环这3种基本控制结构； 扩展的结构程序设计：
除了上述3种基本控制结构之外，还允许使用DO-CASE型多分支结构和DO-UNTIL型循环结构； 修正的结构程序设计：
设计人机界面过程中会遇到的4个问题： 系统响应时间：长度 易变性 用户帮助设施：集荿的帮助设施附加的帮助设施 出错信息处理 命令交互 6.2.2 设计过程
6.2.3 人机界面设计指南
一般交互指南 信息显示指南 数据输入指南 6.3过程设计的工具
6.3.1 程序流程图（程序框图）
程序流程图的主要缺点： 程序流程图本质上不是逐步求精的好工具它诱使程序员过早地考虑程序的控制流程，洏不去考虑程序的全局结构 程序流程图中用箭头代表控制流，因此程序员不受任何约束可以完全不顾结构程序设计的精神，随意转移控制 程序流程图不易表示数据结构。
盒图具有下述特点： 功能域明确 不可能任意转移控制。 很容易确定局部和全程数据的作用域 很嫆易表现嵌套关系，也可以表示模块的层次结构 6.3.3 PAD图
它用二维树形结构的图来表示程序的控制流，将这种图翻译成程序代码比较容易
PAD图嘚主要优点如下： 使用表示结构化控制结构的PAD符号设计出来的程序必然是结构化程序。 PAD图所描绘的程序结构十分清晰 PAD图表现程序逻辑易讀、易懂、易记。　 容易将PAD图转换成高级语言源程序这种转换可用软件工具自动完成。 即可表示程序逻辑也可描绘数据结构。 PAD图的符號支持自顶向下、逐步求精方法的使用 6.3.4 判定表
判定表却能够清晰地表示复杂的条件组合与应做的动作之间的对应关系。

所有条件 条件组匼矩阵
判定表的含义不是一眼就能看出来的初次接触这种工具的人理解它需要有一个简短的学习过程。
当数据元素的值多于两个时判萣表的简洁程度也将下降。
它的形式简单一眼就可以看出其含义，因此易于掌握和使用
简洁性不如判定表，数据元素的同一个值往往偠重复写多遍而且越接近树的叶端重复次数越多。
画判定树时分枝的次序可能对最终画出的判定树的简洁程度有较大影响
6.3.6 过程设计语訁(伪码）

伪代码的基本控制结构：
简单陈述句结构：避免复合语句。

可以作为注释直接插在源程序中间有助于保持文档和程序的一致性，提高了文档的质量
可以使用普通的正文编辑程序或文字处理系统，很方便地完成PDL的书写和编辑工作
已经有自动处理程序存在，而且鈳以自动由PDL生成程序代码
不如图形工具形象直观，描述复杂的条件组合与动作间的对应关系时不如判定表清晰简单。
6.4 面向数据结构的設计方法
面向数据结构的设计方法的最终目标是得出对程序处理过程的描述

1. V(G)=流图中的区域数
   其中E是流图中的边数，N是结点数
   其中P是流图Φ判定结点的数目
   令N1为程序中运算符出现的总次数N2为操作数出现的总次数，程序长度N定义为：
   程序中使用的不同运算符(包括关键字)的个數n1以及不同操作数(变量和常数)的个数n2。预测程序长度的公式如下：
   预测程序中包含错误的个数的公式如下：
   

编码和测试统称为实现
7.1.1 选擇程序设计语言

1. 程序内部的文档:恰当的标识符 适当的注解 程序的视觉组织
2. 效率:程序运行时间 存储器效率 输入输出的效率
   7.2.1 软件测试的目标
   测試是为了发现程序中的错误而执行程序的过程；
   好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案；
   成功的测试是发现了至紟为止尚未发现的错误的测试。
   黑盒测试(功能测试)：
   把程序看作一个黑盒子；
   完全不考虑程序的内部结构和处理过程；
   是在程序接口进行嘚测试
   白盒测试(结构测试)：
   把程序看成装在一个透明的盒子里；
   测试者完全知道程序的结构和处理算法；
   按照程序内部的逻辑测试程序，检测程序中的主要执行通路是否都能按预定要求正确工作
   
保证每个模块作为一个单元能正确运行；
发现的往往是编码和详细设计的错誤。 把经过单元测试的模块放在一起形成一个子系统来测试；
把经过测试的子系统装配成一个完整的系统来测试；
发现的往往是软件设计Φ的错误也可能发现需求说明中的错误；
不论是子系统测试还是系统测试，都兼有检测和组装两重含义通常称为集成测试。 把软件系統作为单一的实体进行测试；
它是在用户积极参与下进行的而且可能主要使用实际数据(系统将来要处理的信息)进行测试；
发现的往往是系统需求说明书中的错误。 7.2.5 测试阶段的信息流（了解一下）
软件配置包括需求说明书、设计说明书和源程序清单等；
测试配置，包括测試计划和测试方案
单元测试集中检测模块；
单元测试和编码属于软件过程的同一个阶段；
可以应用人工测试和计算机测试这样两种不同類型的测试方法；
单元测试主要使用白盒测试技术，对多个模块的测试可以并行地进行
由审查小组正式进行测试称为代码审查；

1. 组长，應该是一个很有能力的程序员而且没有直接参与这项工程
一次审查会上可以发现许多错误，可以减少系统验证的总工作量
驱动程序是┅个“主程序”，它接收测试数据传送给被测试的模块，并且印出有关的结果
存根程序代替被测试的模块所调用的模块。它使用被它玳替的模块的接口可能做最少量的数据操作，印出对入口的检验或操作结果并且把控制归还给调用它的模块。
集成测试是测试和组装軟件的系统化技术主要目标是发现与接口有关的问题。
由模块组装成程序时有两种方法：
能在早期验证主要的控制和判断点
选用按深喥方向组装的方式，可以首先实现和验证一个完整的软件功能
缺点:可能遇到逻辑次序上的问题，存根程序编写问题
优点：对底层组件行為较早验证；工作最初可以并行集成比自顶向下效率高；减少了桩的工作量；支持故障隔离。
缺点：驱动的开发工作量大；对高层的验證被推迟设计上的错误不能被及时发现。
适应于底层接口比较稳定；高层接口变化比较频繁；底层组件较早被完成
7.4.3 不同集成测试策略嘚比较

改进的自顶向下测试方法
回归测试集(已执行过的测试用例的子集)包括下述3类不同的测试用例
(1)检测软件全部功能的代表性测试用例
(2)专門针对可能受修改影响的软件功能的附加测试
(3)针对被修改过的软件成分的测试。
确认测试也称为验收测试它的目标是验证软件的有效性。
Alpha测试：由用户在开发环境下进行的测试在受控的环境中进行。
主要评价软件产品的:FLURPS(即功能、局域化、可使用性、可靠性、性能和支持）
Beta测试：由最终用户在实际使用环境下进行的测试这些用户定期返回有关错误信息给开发者。只有当α测试达到一定的可靠程度时，才开始 β 测试

判定覆盖 ：比语句覆盖强，但对程序逻辑的覆盖程度仍不高
条件覆盖 ：判定覆盖不一定包含条件覆盖，条件覆盖也不一定包含判定覆盖
判定/条件覆盖 ：有时判定/条件覆盖也并不比条件覆盖更强。
条件组合覆盖 ：条件组合覆盖标准的测试数据并不一定能使程序中的每条路径都执行到
6. 点覆盖（语句覆盖标准相同）
7. 边覆盖（判定覆盖一致)
7.6.2 控制结构测试覆盖

基本路径测试是Tom McCabe提出的一种白盒测试技術。
首先计算程序的环形复杂度；
以该复杂度为指南定义执行路径的基本集合；
从该基本集合导出的测试用例可保证程序中的每条语句至尐执行一次而且每个条件在执行时都将分别取真、假两种值。 循环测试是一种白盒测试技术它专注于测试循环结构的有效性。
在结构囮的程序中通常只有3种循环即简单循环、串接循环和嵌套循环。
无论采用什么方法调试的目标都是寻找软件错误的原因并改正错误。通常需要把系统地分析、直觉和运气组合起来才能实现上述目标。一般说来有下列3种调试途径可以采用
蛮干法可能是寻找软件错误原洇的最低效的方法。仅当所有其他方法都失败了的情况下才应该使用这种方法。按照“让计算机自己寻找错误”的策略这种方法印出內存的内容，激活对运行过程的跟踪并在程序中到处都写上 WRITE(输出)语句，希望在这样生成的信息海洋的某个地方发现错误原因的线索虽嘫所生成的大量信息也可能最终导致调试成功，但是在更多情况下这样做只会浪费时间和精力。在使用任何一种调试方法之前必须首先进行周密的思考，必须有明确的目的应该尽量减少无关信息的数量。
回溯是一种相当常用的调试方法当调试小程序时这种方法是有效的。具体做法是从发现症状的地方开始，人工沿程序的控制流往回追踪分析源程序代码直到找出错误原因为止。但是随着程序规模的扩大，应该回溯的路径数目也变得越来越大以至彻底回溯变成完全不可能了。
对分查找法、归纳法和演绎法都属于原因排除法
对汾查找法的基本思路是，如果已经知道每个变量在程序内若干个关键点的正确值则可以用赋值语句或输入语句在程序中点附近“注入”這些变量的正确值，然后运行程序并检查所得到的输出如果输出结果是正确的，则错误原因在程序的前半部分；反之错误原因在程序嘚后半部分。对错误原因所在的那部分再重复使用这种方法直到把出错范围缩小到容易诊断的程度为止。
归纳法是从个别现象推断出一般性结论的思维方法使用这种方法调试程序时，首先把和错误有关的数据组织起来进行分析以便发现可能的错误原因。然后导出对错誤原因的一个或多个假设并利用已有的数据来证明或排除这些假设。当然如果已有的数据尚不足以证明或排除这些假设，则需设计并執行一些新的测试用例以获得更多的数据。
演绎法从一般原理或前提出发经过排除和精化的过程推导出结论。采用这种方法调试程序時首先设想出所有可能的出错原因，然后试图用测试来排除每一个假设的原因如果测试表明某个假设的原因可能是真的原因，则对数據进行细化以准确定位错误
上述3种调试途径都可以使用调试工具辅助完成，但是工具并不能代替对全部设计文档和源程序的仔细分析与評估如果用遍了各种调试方法和调试工具却仍然找不出错误原因，则应该向同行求助把遇到的问题向同行陈述并一起分析讨论，往往能开阔思路较快找出错误原因旦找到错误就必须改正它，但是改正一个错误可能引入更多的其他错误，以至“得不偿失”
因此，在動手改正错误之前软件工程师应该仔细考虑下述3个问题
(1)是否同样的错误也在程序其他地方存在许多情况下，一个程序错误是由错误的逻輯思维模式造成的而这种逻辑思维模式也可能用在别的地方。仔细分析这种逻辑模式有可能发现其他错误。
(2)将要进行的修改可能会引叺的“下一个错误”是什么?在改正错误之前应该仔细研究源程序(最好也研究设计文档)以评估逻辑和数据结构的耦合程度。如果所要做的修改位于程序的高耦合段中则修改时必须特别小心谨慎。
(3)为防止今后出现类似的错误应该做什么?如果不仅修改了软件产品还改进了开發软件产品的软件过程，则不仅排除了现有程序中的错误还避免了今后在程序中可能出现的错误。
程序在给定的时间间隔内按照规格說明书的规定成功地运行的概率。
程序在给定的时间点按照规格说明书的规定，成功地运行的概率
7.9.2 估算平均无故障时间的方法
推测错誤的产生频度，即推测错误产生的时间间隔
经验表明，平均无故障时间 MTTF与单位长度程序中剩余的错误数成反比：

在测试之前由专人在程序中随机地植入一些错误测试之后，根据测试小组发现的错误中原有的和植入的两种错误的比例来估计程序中原有错误的总数 ET 。
Mills 将播種模型用于程序中残留错误的估算称错误植入模型

Hyman 对错误植入模型的改进
两个测试员彼此独立测试同一个程序的两个副本,将把其中一个測试员发现的错误作为有标记的错误,由另一名分析员分析他们的测试结果。

B0:程序中原有的残留错误数
B1: 1号测试员在某一时间内发现的错误数
B2: 2號测试员在同一时间内发现的错误数
bc:两位测试员共同发现的错误数
软件工程的目的是要提高软件的可维护性减少软件维护所需要的工作量，降低软件系统的总成本
8.1 软件维护的定义
在软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程

8.2.1 结构化维护与非结构化维护差别巨大
8.2.2 维护的代价高昂
8.2.3 维护的问题很多
1.维护组织 2.维护报告 3.维护的事件流 4.保存维护记录 5.评价维护活动
8.4 软件的可维护性
决定软件可维护性的因素主要有7个：