软件工程实践者的研究方法知识点.docx
《软件工程实践者的研究方法知识点.docx》由会员分享，可在线阅读，更多相关《软件工程实践者的研究方法知识点.docx（34页珍藏版）》请在冰点文库上搜索。
软件工程实践者的研究方法知识点
软件工程复习总结
第1章软件工程介绍
1．软件的定义软件是包括程序、数据及其相关文档的完整集合。
其中，程序是按照事先设计的功能和性能要求执行的指令序列；数据是使程序能正常操作信息的数据结构；文档是与程序开发、维护和使用有关的图文材料。
软件的定义：
1、指令的集合，通过执行这些指令可以满足预期的特征、功能和性能需求2、数据结构，它使得程序可以充分利用信息3描述程序操作和使用的文档
2．软件的特征
a）软件是设计开发的，而不是传统意义上的生产制造的
b）软件不会磨损
c）虽然整个工业向着基于构件的构造模式发展，然而大多数软件仍是根据实际的顾客需求定制的
3．软件与硬件的区别
a）软件是一种逻辑实体，而不是具体的物理实体
b）软件的生产与硬件不同，软件开发过程中没有明显的制造过程
c）软件在运行、使用期间没有磨损、老化问题
d）软件的开发、运行受到计算机系统的限制，不同程度地依赖于硬件和环境，导致了软件升级和移植地问题
e）软件复杂性越来越高
f）软件开发成本相当昂贵
g）大多数软件是新开发的，而不是通过已有的构件组装而来的
h）软件工程涉及诸多的社会因素
4．遗留软件与软件的演化
系统演化的原因:
a）系统需要修改其适应性，从而满足新的计算环境或者技术的需求
b）软件必须根据新的业务需求进行升级
c）软件必须扩展以具有与更多现代系统和数据库的协作能力
d）软件架构必须进行改建以适应多样化的网络环境
30年来软件发展的规律：
1、持续变化规律，2、复杂性增长规律，3、自我调控规律，4、组织稳定性守恒规律，5、保证通晓性规律，6、持续增长规律，质量衰减规律，7、反馈系统规律。
5．软件神话：
1、管理神话。
软件项目经理依赖信条，减轻提高软件进度和质量的压力。
如开发宝典、增加人员、软件外包。
2、用户神话。
开发小组没有和用户进行有效沟通，导致没有达到用户期望。
如没有详细了解就开始写程序，认为软件容易适应变更。
3、从业者神话：
软件开发者深信各种神话，旧的方式根深蒂固。
6.软件新的挑战：
遍在计算。
无线网络的快速发展也许将很快促成真正的分布式计算的实现
网络资源。
万维网已经快速发展为一个计算引擎和内容提供平台。
开源软件。
开源软件就是将系统应用程序源代码开放，
新经济。
第2章过程综述
1．软件工程定义：
（1）将系统的、规范的、可量化的方法应用于软件的开发、运行和维护，即将工程化方法用于软件开发
（2）在
（1）中所述的方法的研究
2．软件工程的层次：
工具方法过程质量关注点（根基）
软件工程的基础是过程（process）层。
软件过程是将各个技术层次结合在一起并实施合理地、及时地开发计算机软件。
过程定义一个框架，为有效交付软件过程技术，这个框架必须建立。
软件过程构成了软件项目管理控制的基础，并且建立了一个环境以便于技术方法的采用、工作产品的产生、里程碑的建立、质量的保证、正常变更的正确管理。
软件工程方法（method）为建造软件提供技术上的解决方法（"如何做"）方法覆盖面很广，包括沟通、需求分析、设计建模、编程、测试和支持。
软件工程方法依赖于一组基本原则，这些原则涵盖了软件工程所有技术领域，包括建模和其他描述性技术等。
软件工具（tool）为过程和方法提供自动化或半自动化的支持。
这些工具可以集成起来，使得一个工具产生的信息可被另外一个工具使用，这样就建立了软件开发的支撑系统，称为计算机辅助软件工程（computer-aidedsoftwareengineering）
3．通用过程框架Genericprocessframework的框架活动：
沟通策划建模构建和部署
communication（沟通）这个框架活动包含了与客户（和其他共利益者）之间的大量的交流和协作，还包括需求获取以及其他相关活动。
planning（策划）指为后续的软件工程工作制定计划。
它描述了需要执行的技术任务，可能的风险、资源需求、工作产品和工作进度计划。
modeling（建模）它包括创建模型和设计两方面。
创建模型有助于客户和开发人员更好的理解软件需求；设计可以实现需求。
Construction（构建）它包括编码（手写的或者自动生成的）和测试（测试是为了发现编码中的错误）deployment（部署）软件（全部或者完成的部分）交付到用户，用户对其进行评估并给出反馈意见。
4．CMMI的概念和等级（重点）：
CapabilityMaturityModelIntegration能力成熟度模型，SEI提出的一个全面的过程元模型，当软件组织开发达到不同的过程能力和成熟度水平时，该模型可用来预测其所开发的系统和软件工程能力。
第0级：
不完全级（Incomplete）。
过程域没有实施，或者已经实施但未达到CMMI1级成熟度所规定的所有目标。
第1级：
已执行级（Performed）CMMI中定义的所有过程域的特定目标都已经实现。
产生规定的工作产品所必需的工作任务都已经执行。
第2级：
已管理级（Managed）所有第1级规定的要求都已经达到。
另外，所有与过程域相关的工作都符合组织的规程；工作人员都有足够的资源完成工作；共利益者都积极参与到要求的过程域；所有的工作任务和工作产品都被"监督、控制和评审；并评估是否与过程描述相一致"。
第3极：
已定义级（Defined）所有第2级规定的要求都已经达到。
另外，根据组织剪裁准则，对其标准过程进行了裁剪，裁剪过的过程对组织的过程资产增添了新的内容，如工作产品、测量和其他过程改进信息等。
第4级：
已定量管理级（QuantitativelyManaged）所有第3级规定的要求都已经达到。
另外，通过采用测量和定量的估计等手段，对过程域进行控制和不断改进。
"已经建立起来对质量和过程性能的定量指标，并作为过程管理的标准"。
第5级：
优化级（Optimized）所有第4级规定的要求都已经达到。
另外，"采用定量（统计）的方法调整和优化过程域，以满足用户不断变更的需求，并持续地提高过程域的有效性。
"
5．PSP/TSP模型特点
PSP（个人软件过程）过程模型定义了5个框架活动：
策划、高层设计、高层设计评审、开发、后验。
策划：
它将需求活动分离出来，并根据需求计算项目的规模和所需资源，并且预测缺陷数目。
所有的度量都用工作表或模板记录。
最后，识别开发任务，并建立项目进度计划。
高层设计：
建立每个构件的外部规格说明，并完成构件设计。
如果有不确定的需求，则构建原型系统。
所有问题都被记录和跟踪。
高层设计评审：
使用形式化验证方法来发现设计中的错误。
对所有的重要任务和工作结果都进行度量。
开发：
细化和评审构件级设计。
完成编码，对代码进行评审，并进行编译和测试。
对所有的重要任务和工作结果都进行度量。
后验：
根据收集到的度量和测量结果，确定过程的有效性。
度量和测量结果为提高过程的有效性提供指导。
TSP的目标（团队软件过程）·建立自我管理团队来计划和跟踪其工作，确定目标，建立团队自己的过程和计划。
·只是管理人员如何指导和激励其团队，并保持团队的最佳表现。
·使CMM第5级的行为常规化，并依此约束员工，这样可加速软件过程改进。
·为高成熟度的软件组织提供改进指导。
·协助大学传授工业级团队技能。
第3章过程模型
1．过程模型的作用：
使软件开发更加有序
2．传统过程模型
瀑布模型又被称为经典生命周期，它提出了一个系统的、顺序的软件开发方法，从用户需求规格说明开始，通过策划、建模、构建和部署过程，最终提供一个完整的软件并提供持续的技术支持。
要求：
需求明确更改较小的情形
增量过程模型：
增量模型：
以迭代的方式运用瀑布模型。
随着时间推移，增量模型在每个阶段运用线性序列，每个线性序列生产出一个软件的可交付增量。
和原型不同，增量模型每个增量都提交一个可交付的产品。
瀑布模型的一个迭代版本，在每个阶段运行瀑布模型生产出一个软件可交付增量。
运用增量模型时，第一个增量往往时核心产品。
适用范围：
在开发过程中开发人员不足
RAD模型：
快速应用程序开发是一种侧重于短暂的开发周期的增量软甲过程模型。
RAD是瀑布模型的高速变体，通过基于构建的方法实现快速开发。
沟通来理解软件的特征，策划确保多个团队并行工作，建模包括三个阶段业务建模、数据建模和过程建模。
构建运用已有的构件技术并用代码自动生成技术，部署为以后的迭代建立基础。
不足：
1、大量的人员，2、开发者和客户如果没有为短实践内急速完成做好准备，通常为失败，3、需要合理的模块化，否则构建建立会有很多问题，4、不适合高性能，5、高风险不宜采用RAD。
演化过程模型：
原型模型（重点）原型模型的基本思想是：
软件开发人员在与用户进行需求分析时，以比较小的代价快速建立一个能够反映用户主要需求的原型系统，然后由客户或者用户进行评价。
开发人员根据反馈进一步对原型进行补充和完善，直到用户对开发的原型系统满意为止。
使用原型系统时，客户和开发者必须承认原型是为定义需求服务的。
然后丢弃原型，实际的软件系统是以质量第一为目标的。
适用范围：
a）客户提出了软件的一些基本功能，但是没有详细定义的输入、处理和输出需求。
b）开发人员对算法的效率、操作系统的兼容性和人机交互的形式等情况不确定。
――优点：
由用户或客户进行评价，能够用来定义需求缺点：
第一个系统通常是不可用的，必须被扔掉
螺旋模型一种风险驱动型过程模型，它有两个显著的特点。
一是采用循环的方式逐步加深系统定义和实现的深度，同时降低风险（要求在项目的所有阶段始终考虑技术风险）。
二是确定一系列里程碑，确保共利益者都支持可行的和令人满意的系统解决方案。
适用范围：
大型系统开发
协同开发模型。
有时候叫协同工程，可以表示为一系列框架活动、软件工程动作和任务以及相应的状态。
协同过程模型定义了一系列事件，这些事件将出发软件工程活动、动作或状态转换。
协同过程模型可用于所有类型的软件开发，能提供项目当前的状态图。
专用过程模型：
基于构建的开发：
能够做到软件复用，带来极大收益。
形式化方法模型：
的主要活动是生成计算机软件的数学规格说明。
使用形式化方法，歧义性问题、不完整问题、不一致问题都容易被发现和改正，不是依靠特定的评审，而是应用分析的方法。
面向方面的软件开发（AOSD）：
为定义、说明、设计和构建方面提供过程和方法，是对横切关注点局部表示的一种机制，超越了子程序和继承的方法。
统一过程：
UP以用例为驱动、以系统架构为中心的迭代与增量过程。
RUP包括起始、细化、构建、转换和生产5个部分。
五个UP阶段并不是顺序地进行，而是阶段性地并发进行。
UP模型（概念重点）：
一种用UML进行面向对象软件工程的框架。
敏捷的概念
4．了解模型的特点与使用范围
第6章系统工程（不作要求）
1．系统工程的概念
2．基于计算机系统的要素
3．系统工程的层次全局/领域/要素/详细视图
4．业务过程工程需要分析和设计的三种不同架构：
数据、应用、和技术基础设施
5．产品工程需求工程、构建工程、软件工程
需求导出为何困难：
范围问题理解问题易变问题
产品工程的目的是将用户期望的已定义的一组能力转化成真实产品。
为了达到这个目的，产品工程－类似系统工程必须给出架构和基础设施。
这个构架包括四个不同的系统构件：
软件硬件数据（数据库）以及人员
软件构造包括了编码和测试循环，循环过程包括为每个构件生成源码并对其进行测试和纠错。
软件部署发生在向客户展示每个软件增量的时候。
交付的关键原则是满足客户期望并且能为客户提供合适的软件信息支持。
6．系统建模方法：
HP方法（输入－处理－输出＋界面和维护自检）
7．SCD图
8．UML系统建模（部署图、活动图和用例图）
第7章需求工程（概念）
1．需求工程的任务：
启始、导出、求精、协商、规格说明、确认和需求管理－－InceptionElicitationElaborationNegotiationSpecificationValidationRequirementsManagement
2．质量功能部署（QFD）三类要求：
正常需求、期望需求、令人兴奋的需求。
3．用户场景的概念
用来识别对将要构建的系统的使用线索的描述――用例。
场景通常称为用例。
本质上，用例定义了最终用户如何在以特定的环境下与系统交互。
4．UML用例建模（用例图、活动图、状态图和类图）
系统规格说明的三个目标：
功能性能约束
用例模版p127
5.需求工程概念：
需求工程帮助软件工程师更好的理解他们将要解决的问题。
其中所包含的一系列任务有助于理解软件将如何影响业务、客户想要什么以及最终用户将如何与软件交互。
通过需求分析可以得到的产品有：
用户场景、功能和特征列表、分析模型或功能说明。
需求工程（RE）是一个软件工程动作，开始于沟通并持续到建模。
需求工程在设计和构造之间建立联系的桥梁
6.启动需求工程的过程
a.确认共利益者
b.识别多种观点
c.协同合作
d.首次提问
7.导出需求
a.协同需求收集
b.质量功能部署
c.用户场景
d.导出工作产品
第8章构建分析模型建模的目的对象技术建模原则分析包
1．分析建模的三个目标a.描述客户需要什么，b.为软件设计奠定基础，c.定义在软件完成后可以被确认的一组需求。
分析模型在系统描述和设计模型之间建立桥梁。
2．分析建模的方法（结构化分析和面向对象）1、一种考虑数据和处理的分析建模方法被称为结构分析。
2、第二种方法是面向对象的分析，这种方法关注于定义类和影响客户需求的类之间的协作方式。
3．分析模型的元素：
基于场景、面向信息流、基于类、基于行为
4．ERD（实体＋关系＋基数和形态）数据字典面向对象分析模型
5．基于场景建模（用例模版、活动图/泳道图）
6．状态图
7．基于类的建模：
实体、类、类图（CRC图），行为模型（时序图）
8．基于用例图的分析类的抽象方法
9．分析模型的概念及其组成
分析包：
分析建模的一个重要部分就是分类，也就是将分析模型的各种元素（如用例、分析类）分组打包－称作分析包，并为每个包取一个有代表性的名称。
10.创建分析模型遵循的原则：
a.模型应关注在问题域或业务域内可见的需求，抽象的级别应该相对高一些
b.分析模型的每个元素都应能增加对软件需求的整体理解，并提供对信息域。
功能和系统行为的深入理解
c.基于基础结构和其他非功能的模型应推延到设计阶段再考虑
d.最小化整个系统内的关联
e.确认分析模型为所有共利益者都带来价值
f.尽可能保持模型简洁
第八章构建分析模型
1、分析模型。
分析模型使用文字和图表的综合形式以相对容易理解的方式描绘需求的数据、功能和行为，更重要的是，可以更直接的评审它们的正确性、完整性和一致性。
2、基于场景的建模从用户的角度表现系统，面向流的建模在说明数据对象如何通过处理函数进行转换方面提供了指示，基于类的建模定义了对象、属性和关系，行为建模描述了系统状态、类和事件在这些类上的影响。
3、分析模型必须实现的三个主要目标：
a.描述客户需要什么，b.为软件设计奠定基础，c.定义在软件完成后可以被确认的一组需求。
分析模型在系统描述和设计模型之间建立桥梁。
4、分析建模的方法。
1、一种考虑数据和处理的分析建模方法被称为结构分析。
2、第二种方法是面向对象的分析，这种方法关注于定义类和影响客户需求的类之间的协作方式。
5、基于场景的建模使用UML分析建模，从开发用例、活动图和泳道图形式的场景开始。
6、创建数据流模型，数据流图有助于软件工程师开发信息域的模型，并同时开发功能域的模型。
7、CRC建模。
CRC提供了一个简单的方法，可以识别和组织与系统或产品需求相关的类。
CRC模型实际上师表示类的标准索引卡片的集合。
这些卡片被分为三部分，顶部写类名，下面左侧列出类的职责，右侧部分列出类的协作关系。
8、生成行为模型。
CRC索引卡和其他面向对象模型表现了分析模型中的静态元素，行为模型表示系统或产品的动态行为，有状态图、顺序图。
9、分析模型由4种建模元素构成：
基于场景的模型、流模型、基于类的模型和行为模型。
10、基于场景的模型从用户的角度描述软件需求。
用例是主要的建模元素，还可以适用活动图说明场景，泳道图显示了处理流如何分配给不同的用户。
流模型关注当数据对象通过处理函数转换时的流动。
基于类的建模使用基于场景和面向流的建模元素中提取的信息确定分析类。
前面三种分析模型元素提供了软件的静态视图，行为模型描述了动态行为。
行为模型使用基于场景、面向流和基于类的元素作为输入，从整体上表现分析系统和类的状态。
要做到这一点，要识别状态，定义导致类做出状态转移的事件，以及确认当转移完成时所发生的动作。
状态图和顺序图是用于行为建模的UML表达方式。
11.实体/关系图（ERD）图形化的表示对象/关系对。
ERD识别了一组基本元素：
数据对象、属性、关系以及各种类型的指示符，使用ERD的主要目的是表示数据对象及其关系
第9章设计工程
1．McGlaughlin指导评价良好设计的3个特征
2．设计的概念
抽象：
抽象是人类处理复杂问题的基本方法之一。
当我们在不同抽象级间移动时，我们力图创建过程抽象和数据抽象。
过程抽象是指具有明确和有限功能的指令序列。
数据抽象是描述对象的冠名数据集合
体系结构（概念）
软件体系结构意指"软件的整体结构和这种结构为系统提供概念上完整性的方式"。
从最简单的形式来看，体系结构是程序构建（模块）的结构或组织、这些构件交互的形式以及这些构件所用数据的结构。
模式：
设计模式描述了在某个特定场景与可能影响模式应用和使用方式的“影响力”中解决某个特定的设计问题的设计结构。
模块化：
软件体系结构和设计模式表现为模块化；软件被划分为独立命名的、可寻址的构件，有时被称为模块，把这些构件集到一起可以满足问题的需求
信息隐藏（重点）每个模块对其它所有模块都隐藏自己的设计决策。
就是说，模块
应该详细说明且精心设计以求在某个模块中包含的信息（算法和数据）不被不需要这些信息的其他模块访问。
隐蔽定义并加强了模块内的过程细节和模块所使用的任何局部数据结构的访问和约束。
功能独立：
功能独立的概念是模块化、抽象概念和信息隐蔽的直接结果
求精：
逐步求精是一种自顶向下的设计策略，求精实际上是一个细化的过程。
重构：
重构是一种重新组织的技术，可以简化构件的设计（或代码）而无需改变其功能或行为。
设计类：
组织良好的设计类的4个特征完整性和充分性原始性高内聚和低耦合性
4．模式和框架
5．完整设计的4个模型和作用：
数据、体系结构、接口和构件级设计
数据设计：
创建在高抽象级上（以客户/用户的数据观点）表示的数据模型或信息模型
体系结构设计：
揭示了规格分析模型的软件和硬件元素之间的关系和协作，体系结构设计定义了软件的主要结构元素之间的联系，为我们提供了软件的整体视图
接口设计：
软件接口设计元素告诉我们信息如何流入和流出系统以及被定义为体系结构一部分的构件之间是如何通信的，描述了一组可以用来描述一个特定类的外部可见的行为的操作以及提供对这些操作的访问包括三个重要元素：
用户界面（UI）；和其他系统、设备、网络或其他的信息生产者或使用者的外部接口；各种设计构件之间的内部接口。
构件级设计：
描述每一个软件组件的内部细节。
为所有本地数据对象定义数据结构，为所有在构件内发生的处理定义算法细节，并定义允许访问所有构件操作（行为）的接口。
6.从分析模型到设计模型的转化
第10章体系结构设计
1．体系结构设计定义和重要性
定义：
一个程序和计算系统软件体系结构是指系统的一个或者多个结构。
结构中包括软件的构件，构件的外部可见属性以及它们之间的相互关系。
体系结构并非可运行软件，确切的说，它是一种表达，是软件工程师能够
（1）分析设计在满足需求方面的有效性，
（2）在设计变更相对容易的阶段，考虑体系结构可能的选择方案，（3）降低与软件构造相关联的风险。
重要性：
软件体系机构的表示有助于对计算机系统开发感兴趣的各方（共利益者）开展交流；体系结构突出早期设计决策，影响随后的软件工程工作，同时对系统的最后成功有重要作用；体系结构"创建了一个相对小的，易于理解的模型，该模型描述了系统如何构成以及其构件如何一起工作"
2．数据设计目标数据字典－数据字典是用来定义数据流图中的各个成分的具体含义的。
它以一种准确的、无二义性的说明方式为系统的分析、设计及维护提供了有关元素的一致的定义和详细的描述。
数据设计是把分析模型定义的数据对象转化成软件构件级的数据结构，并且再必要时转化为应用程序级的数据库体系结构。
3．体系结构风格的组成要素一组构件、一组连接器、约束和语意模型
一种体系风格就是一种加在整个系统设计上面的变换。
它的目的就是为系统的所有的构建建立一个结构。
对已有体系结构进行再工程时，强制采用一种体系结构风格会导致软件结构的根本性改变，包括对构建功能的再分配。
每种风格描述一种系统类别，包括
（1）一组构建完成系统需要的某种功能，
（2）一组连接器，使构建间实现通信、合作和协调，（3）约束，定义构件成为一个系统，（4）语义模型，使设计者通过分析系统的构成成分的性质来理解系统的整体性质。
4．体系结构风格分类以数据为中心的体系结构数据流体系结构调用返回体系结构面向对象体系结构层次体系结构
5．模式（并发性、持久性、分布性）
体系结构模式（architecturepattern）软件的体系结构模式定义了处理系统某些行为特征的方法。
体系结构模式域：
并发性、持久性、分布性。
6．体系结构设计（体系结构环境ACD）
在体系结构设计层，软件架构师用体系结构环境图（architecturalcontextdiagram）对软件与外部实体交互方式进行建模。
7．体系结构的复杂性（共享依赖流依赖约束依赖）
a.共享依赖表示在使用相同资源的消费者间或为相同消费者生产的生产者之间的依赖关系
b.流依赖表示资源的生产者和消费者之间的依赖关系
c.约束依赖表示在一组活动间相关控制流上的约束
第11章构件级设计建模
1．构件的定义（面向对象和传统的观点）
构件是：
系统中某一定型化的、可配置的和可替换的部件，该部件封装了实现并暴露一系列接口。
从面向对象观点：
一个构件就是一个协作类的集合。
传统观点：
一个构件就是程序的一个功能要素，程序由处理逻辑及实现处理逻辑所需的内部数据结构以及能够保证构件被调用和实现数据传递的接口构成。
承担以下角色：
a.控制构件
b.问题域构件
c.基础设施构件
2．基于类的构件的基本设计原则
开关原则替换原则依赖倒置原则接口分离原则发布复用等价性原则共同封装原则
共同复用原则
开关原则TheOpen-ClosedPrinciple（OCP）：
模块应该对外延具有开放性，对修改具有封闭性
Liskov替换原则TheLiskovSubstitutionPrinciple（LSP）：
子类可以替换它们的基类
依赖倒置原则DependencyInversionPrinciple（DIP）：
依赖于抽象，而非具体的实现
接口分离原则TheInterfaceSegregationPrinciple（ISP）：
多个用户专用接口比一个通用接口要好
发布复用等价性原则TheReleaseReuseEquivalencyPrinciple（REP）：
复用的粒度就是发布的粒度
共同封装原则TheCommonClosurePrinciple（CCP）：
一同变更的类应该合在一起
共同复用原则TheCommonReusePrincip
升级会员 