新软件工程复习总结.docx
《新软件工程复习总结.docx》由会员分享，可在线阅读，更多相关《新软件工程复习总结.docx（19页珍藏版）》请在冰豆网上搜索。
新软件工程复习总结
1）需求分析 85
需求分析阶段的基本过程包括四个方面：
对问题的识别，分析与综合，制定规格说明以及评审。
（1）问题识别，系统分析人员要研究计划阶段产生的可行性分析报告和软件项目实施计划。
然后进行功能需求、性能需求、环境需求、可靠性需求安全保密需求、用户界面需求、资源使用需求等方面的工作。
（2）分析与综合，分析员需从数据流和数据结构出发，逐步细化所有的软件功能，找出系统各元素之间的联系、接口特性和设计上的限制，分析他们是否满足功能需求，是否合理。
（3）制定规格说明，编写需求分析的文档。
（4）需求分析评审。
为保证软件需求定义的质量，评审应以专门指定的人员负责，并按规程严格执行。
需求分析对系统的综合要求：
功能需求；性能需求；可靠性和可用性需求；出错处理需求；接口需求；约束；逆向需求；将来可能提出的要求；
获取需求的方法
1、访谈
同潜在需要的用户进行讨论
使用情景分析技术
通过大面积的市场调查和用户问卷调查
2、面向数据流自顶向下求精
采用自顶向下求精方法，分析员借助数据流图、数据字典和IPO图向用户解释输入数据是怎样一步一步地转变成输出数据的。
3、简易的应用规格说明技术
4、快速建立软件原型
2）用例图，要明白包含和扩展（书上没找到）
用例图概要
用例图是被称为参与者的外部用户所能观察到的系统功能的模型图。
用例图列出系统中的用例和系统外的参与者，并显示哪个参与者参与了哪个用例的执行（或称为发起了哪个用例）。
用例图多用于静态建模阶段（主要是业务建模和需求建模）。
实例用例之间扩展和包含关系
用例的上下文是：
短途旅行但汽车的油不足以应付全部路程。
那么为汽车加油的动作在旅行的每个场景（事件流）中都会出现，不加油就不会完成旅行。
吃饭则可以由司机决定是否进行，不吃饭不会影响旅行的完成。
右图中的参与者有？
（a）1（b）2
（c）3（d）4
右图中的用例有？
（a）1（b）2
（c）3（d）4
2和3之间是什么关系？
5和6呢？
（a）扩展，包含（b）包含，扩展
5缺少了3仍然是个完整的用例？
（a）是的（b）不是
4能够参与2吗？
1能够参与5吗？
（a）可以，不可以（b）不可以，可以
习题答案：
1、（a）（d）2、（b）（c）3、（b）4、（b）5、（b）
3）常用软件过程模型 23页
软件过程（简单了解）
软件过程是为了获得高质量软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。
过程定义了：
（1）运用方法的顺序；
（2）应该交付的文档资料；（3为保证软件质量和协调变化所需要采取的管理措施；（4）标志软件开发各个阶段任务完成的里程碑。
包括5个框架活动：
沟通，策划，建模，构建，部署。
瀑布模型
有时候，可以清楚地了解问题的需求，当从沟通到部署采用线性工作流方式的时候，这种情况通常发生在对一个已经存在的系统进行明确定义的适应性调整或是增强的时候；也可能发生在很少数新的开发工作上，但是需求必须是准确定义和相对稳定的。
瀑布模型有许多优点：
可强迫开发人员采用规范的方法（例如，结构化技术）.
将使软件维护变得比较容易.
显著降低软件预算
缺点：
1、实际的项目很少遵守瀑布模型提出的顺序。
虽然线性模型可以加入迭代，但是它是用间接的方式实现的，结果是，随着项目的推进，变更可能造成混乱。
2、客户通常难以清楚地描述所有的需求。
瀑布模型需要客户明确的需求，因此很难适应在许多项目开始阶段必然存在的不确定性。
3、客户必须要有耐心，因为只有在项目接近尾声的时候，他们才能得到可执行的程序。
对于系统中存在的重大缺陷，如果在可执行程序评审之前没有被发现，将可能造成惨重损失。
增量过程模型
初始的软件需求有明确的定义，但是整个开发过程却不宜单纯运用线性模型。
同时，可能迫切需要为用户迅速提供一套功能有限的软件产品，然后再后续版本中再进行细化和扩展功能。
这个时候，需要增量过程模型。
使用增量模型开发软件时，把软件产品作为一系列的增量构件来设计、编码、集成和测试。
每个构件由多个相互作用的模块构成，并且能够完成特定的功能。
特点
增量模型的特点是引进了增量包的概念，无须等到所有需求都出来，只要某个需求的增量包出来即可进行开发。
虽然某个增量包可能还需要进一步适应客户的需求并且更改，但只要这个增量包足够小，其影响对整个项目来说是可以承受的。
优点
1）由于能够在较短的时间内向用户提交一些有用的工作产品，因此能够解决用户的一些急用功能。
2）由于每次只提交用户部分功能，用户有较充分的时间学习和适应新的产品。
3）对系统的可维护性是一个极大的提高，因为整个系统是由一个个构件集成在一起的，当需求变更时只变更部分部件，而不必影响整个系统。
缺点
1）由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构。
2）在开发过程中，需求的变化是不可避免的。
增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而使软件过程的控制失去整体性。
3）如果增量包之间存在相交的情况且未很好处理，则必须做全盘系统分析，这种模型将功能细化后分别开发的方法较适应于需求经常改变的软件开发过程。
演化过程模型
演化过程模型是迭代的过程模型，使得软件开发人员能够逐步开发出更完整的软件版本。
1、原型开发。
原型模型的特点：
（1）开发人员和用户在“原型”上达成一致。
这样一来，可以减少设计中的错误和开发中的风险，也减少了对用户培训的时间，而提高了系统的实用、正确性以及用户的满意程度。
（2）缩短了开发周期，加快了工程进度。
（3）降低成本。
原型模型的缺点：
当告诉用户，还必须重新生产该产品时，用户是很难接受的。
这往往给工程继续开展带来不利因素。
开发者为了使一个原型快速运行起来，往往在实现过程中采用这种手段。
不宜利用原型系统作为最终产品。
采用原型模型开发系统，用户和开发者必须达成一致：
原型被建造仅仅是用户用来定义需求，之后便部分或全部抛弃，最终的软件是要充分考虑了质量和可维护性等方面之后才被开发。
2、螺旋模型
它将瀑布模型的系统性和可控性和快速原型模型的迭代性结合起来，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统。
优点：
（1）采用循环的方式逐步加深系统定义和实现的深度，同时降低风险。
（2）确定一系列里程碑，确保利益相关者都支持可行的和令人满意的系统解决方案。
缺点
很难让用户确信这种演化方法的结果是可以控制的。
建设周期长，而软件技术发展比较快，所以经常出现软件开发完毕后，和当前的技术水平有了较大的差距，无法满足当前用户需求。
螺旋模型的项目适用：
对于新近开发，需求不明确的情况下，适合用螺旋模型进行开发，便于风险控制和需求变更！
4）一个简单的数据流图 这个看我上传的uml
4.某运动会管理系统的功能为：
（1）接受来自运动员的报名单，记录报名信息，打印运动员号码单发送给运动员、打印参赛人员报表发送给裁判。
（2）接受来自裁判的比赛项目及成绩，产生比赛结果报表发送给发布台。
用分层数据流图表示上述系统的功能。
（画出顶层、0层和1层数据流图）
某部门期刊阅览管理系统的部分功能如下：
（1）期刊信息维护：
管理员定期输入新进期刊的信息，系统为期刊统一编号、登记入库、打印输出新进期刊目录清单。
（2）期刊借阅管理：
根据读者提供的阅览证信息和期刊借阅请求，查询期刊信息、进行借阅登记，打印期刊借阅清单给读者。
请画出描述上述系统功能的分层数据流图。
（画出顶层、0层和1层数据流图）
4）软件测试的主要步骤，就是集成测试，客户验收测试这些制度 263，269（B塔，测试就是客户验收测试）
软件测试的必要性：
软件的复杂性成员之间的沟通和配合技术评审的不完整性编码引入新的错误
软件测试的目的与软件工程其他阶段的目的都相反，软件工程的其他阶段都是“建设性”的。
在测试阶段测试人员努力设计一系列测试方案，目的却是为了“破坏”已经建造好的软件系统
测试阶段的根本目的是尽可能多地发现并排除软件中潜藏的错误，最终把一个高质量的软件系统交给用户使用
软件测试准则
（1）所有测试都应该能追溯到用户需求
（2）应该在测试开始之前就制定出测试计划；完成了需求模型就可以着手制定测试计划；在建立了设计模型后就可以立即开始设计详细的测试方案
（3）测试发现的错误中的80％很可能是由程序中20％的模块造成的。
问题是怎样找出这些可疑的模块并彻底地测试它们
（4）应该从“小规模”测试开始，并逐步进行“大规模”测试
（5）穷举测试是不可能的
（6）为了达到最佳的测试效果，应该由独立的第三方从事测试工作
测试步骤
1．模块测试2．子系统测试3．系统测试4．验收测试5．平行运行
单元测试：
主要使用白盒测试技术
测试重点1模块接口2局部数据结构3重要的执行通路4出错处理通路5边界条件
集成测试：
集成测试是构造软件体系结构的系统化技术，同时也是进行一些已在发现与接口相关的错误的测试。
选择：
•“大爆炸”方法，非增量的式的
•增量构建策略
两种方法的比较
非渐增式测试
•一下子把所有模块放在一起，并把庞大的程序作为一个整体来测试，测试者面对的情况十分复杂
•改正错误是极端困难的
•想要诊断定位一个错误是非常困难的
•错误会连续不断，没有尽头
渐增式测试
•与“一步到位”的非渐增式测试相反，它把程序划分成小段来构造和测试
•易定位和改正错误
•对接口可以进行更彻底的测试
•可以使用系统化的测试方法
渐增测试的三种集成策略
自顶向下集成
自顶向下增量式测试表示逐步集成和逐步测试是按照结构图自上而下进行的，即模块集成的顺序是首先集成主控模块（主程序），然后依照控制层次结构向下进行集成。
从属于主控模块的按深度优先方式（纵向）或者广度优先方式（横向）集成到结构中去。
深度优先方式的集成：
——首先集成在结构中的一个主控路径下的所有模块，主控路径的选择是任意的。
广度优先方式的集成：
——首先沿着水平方向，把每一层中所有直接隶属于上一层的模块集成起来，直到底层。
自底向上集成
第1步：
把低层模块组合成族，每族实现一个子功能
第2步：
用驱动程序（Driver）协调测试数据的I\O，测试子功能族。
第3步：
去掉Driver，自下而上把子功能族合成更大的子功能族。
自底向上增量式测试表示逐步集成和逐步测试的工作是按结构图自下而上进行的，即从程序模块结构的最底层模块开始集成和测试。
由于是从最底层开始集成，对于一个给定层次的模块，它的子模块（包括子模块的所有下属模块）已经集成并测试完成，所以不再需要使用桩模块进行辅助测试。
在模块的测试过程中需要从子模块得到的信息可以直接运行子模块得到。
三明治测试
混合增量式测试是把自顶向下测试和自底向上测试这两种方式结合起来进行集成和测试。
这样可以兼具两者的优点，而摒弃其缺点。
回归测试
1、回归测试重新执行已测试过的某些子集，以确保变更没有传播不期望的副作用。
2、无论什么时候修正软件，软件配置的某些方面（程序、文档或支持数据）也发生变更。
3、回归测试有助于保证变更（由于测试或其他原因）不引入无意识行为或额外的错误。
4、回归测试可以手工进行，方法是重新执行所有测试用例的子集，或者利用捕捉/回放工具自动进行。
冒烟测试
为生产软件创建“每日构建”的一种常见方法
冒烟测试步骤：
将已经转换为代码的软件构件集成到“构建”中去。
一个构建包括所有的数据文件、库、可复用的模块以及实现一个或多个产品功能所需的工程化构件。
设计一系列测试以暴露影响构建正确地完成其功能的错误。
其目的是为了发现极有可能造成项目延迟的“业务阻塞”错误。
每天将该构建与其他构建及整个软件产品（以其当前的形式）集成起来进行冒烟测试。
这种集成方法可以是自顶向下，也可以自底向上。
确认测试
也称为验收测试，它的目标是验证软件的有效性。
通常使用黑盒测试法
基本路径测试
基本路径测试是TomMcCabe提出的一种白盒测试技术。
用该程序的环形复杂度定义执行路径的基本集合，导出的测试用例可以保证程序中的每条语句至少执行一次，而且每个条件在执行时都将分别取真、假两种值。
步骤：
第一步，根据过程设计结果画出相应的流图。
第二步，计算流图的环形复杂度。
第三步，确定线性独立路径的基本集合。
第四步，设计可强制执行基本集合中每条路径的测试用例。
5）根据JAVA代码画一个顺序图，这个代码页很容易，不用太复杂
用来描述为了完成确定事务，对象之间按照时间消息交互的顺序关系
概要
顺序图用来表示用例中的行为顺序。
当执行一个用例行为时，顺序图中的每条消息对应了一个类操作或状态机中引起转换的事件。
顺序图展示对象之间的交互，这些交互是指在场景或用例的事件流中发生的。
顺序图属于动态建模。
顺序图的重点在消息序列上，也就是说，描述消息是如何在对象间发送和接收的。
表示了对象之间传送消息的时间顺序。
浏览顺序图的方法是：
从上到下查看对象间交换的消息。
1指出左图中的参与者？
A①B②C③D④
2哪些是对象？
A①B②③④C④D⑤⑥⑦⑧⑨⑩
3Server类调用了CreditService类中的什么操作？
A⑦B⑧C⑦⑧D⑧⑨
1.A2.B3.B
6）状态图的基本概念，不要求画，根据图回答问题，所以基本概念要知道。
状态图概要
状态图
说明对象在它的生命期中响应事件所经历的状态序列，以及它们对那些事件
的响应。
状态图用于
揭示Actor、类、子系统和组件的复杂特性。
为实时系统建模。
状态图的组成
状态
对象的状态是指在这个对象的生命期中的一个条件或状况，在此期间对象将
满足某些条件、执行某些活动，或等待某些事件。
转移
转移是由一种状态到另一种状态的迁移。
这种转移由被建模实体内部或外部
事件触发。
对一个类来说，转移通常是调用了一个可以引起状态发生重要变化的操作的
结果。
7）黑盒测试，白盒测试 281
黑盒测试法（测试过程后期使用的方法）
把程序看作一个黑盒子，完全不考虑程序的内部结构和处理过程
黑盒测试是在程序接口进行的测试
•检查程序功能是否能按照规格说明书的规定正常使用
•程序是否能适当地接收输入数据产生正确的输出信息
•程序运行过程中能否保持外部信息的完整性
黑盒测试又称为功能测试
白盒测试法（重点）
●把程序看成装在一个透明的白盒子，测试者完全知道程序的结构和处理算法
●这种方法按照程序内部的逻辑测试程序，检测程序中主要执行通路是否都能按预定要求正确工作
●白盒测试又称为结构测试
8）课本上的一个面向对象原则的理解。
173-176的那些原则
4种适用于构件级设计的基本设计原则：
1、开闭原则OCP
（1）对于扩展是开放的（Openforextension）。
这意味着模块的行为是可以扩展的。
当应用的需求改变时，我们可以对模块进行扩展，使其具有满足那些改变的新行为。
也就是说，我们可以改变模块的功能。
（2）对于修改是关闭的（Closedformodification）。
对模块行为进行扩展时，不必改动模块的源代码或者二进制代码。
模块的二进制可执行版本，无论是可链接的库、DLL或者.EXE文件，都无需改动。
实现开闭原则的关键就在于“抽象”
2、Liskov替换原则LSP
子类型必须能够替换它们的基类型
3、依赖倒置原则DIP
依赖于抽象，而非具体实现
4、接口分离原则ISP
多个客户专用接口比一个通用接口要好。
在设计过程中如何正确组织这些构件？
给出另一些打包原则：
1、发布复用等价性原则REP
“复用的粒度就是发布的粒度”当设计类或构件用以复用时，在可复用实体的开发者和使用者之间就建立了一种隐含的约定关系。
开发者承诺建立一个发布控制系统，用来支持和维护实体的各种老版本，同时用户组件将其升级到最新版本，明智的方法是将可复用的类分组打包成能够管理和控制的包，并作为一个更新的版本而不是对每个类分别进行升级。
2、共同封装原则CCP
“一同变更的类应该合在一起”类应该根据其内聚性进行打包。
也就是说，当类被打包成设计的一部分时，他们应该处理相同的功能或者行为域。
当某个域的一些特征必须变更时，只有相应包中的类才有可能需要修改。
这样可以进行更加有效的变更控制和发布管理。
3、共同复用原则CRP
“不能一起服用的类不能被分到一组”当包中的一个或者多个类变更时，包的发布版本号也会发生变更。
所有那些依赖于已经发生变更的包的类或者包，都必须升级到最新的版本，并且都需要进行测试以保证新发布的版本能够无故障运转。
如果类没有根据内聚性进行分组，那么这个包中与其他类无关联的类有可能会发生变更，而这往往会导致进行没有必要的集成和测试。
因此，只有那些一起被复用的类才应该包含在一个包中。
升级会员 