[color=red]软件工程知识点的概括：[/color]
●[color=red]软件[/color]：软件是能够完成预定功能和性能的可执行的计算机程序和使程序正常执行所需要的数据，加上描述程序的操作和使用的文档。
软件的特征：
(1)软件是一种逻辑实体，而不是具体的物理实体，因而它具有抽象性。
（2） 软件是通过人们的智力活动，把知识与技术转化成信息的一种产品
（3）软件成为产品后，其生产只是简单的拷贝，不同于硬件制造。
（4）维护过程比硬件复杂的多，甚至会引发新的错误。
[color=red]软件危机[/color]：指的是软件开发和维护过程中遇到的一系列严重问题。
出现软件危机的原因：
（1） 软件维护费用急剧上升，直接威胁计算机应用的扩大。
（2） 软件生产技术进步缓慢
软件工程：是指导计算机软件开发和维护的工程学科。
软件生存周期：一个软件从定义到开发、使用和维护，直到最终被弃用，要经历一个漫长的时期，通常把软件经历的这个漫长的时期称为生存周期。
[color=red]软件生存周期[/color]一般可分为以下阶段：
1.问题定义2.可行性研究。3需求分析4.总体（概要）设计。
5.详细设计。6.编码与单元测试。7.综合测试。8.软件维护
软件开发模型[color=red]（software process models）[/color]：软件开发模型是软件开发全过程、软件开发活动以及它们之间关系的结构框架。
瀑布模型(Waterfall model)即生存周期模型，由B.M.Boehm提出，是软件工程的基础模型。其核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作。采用结构化的分析与设计方法，将逻辑实现与物理实现分开。瀑布模型强调文档的作用，并要求每个阶段都要仔细验证。
快速原型模型（Prototyping model）:实现客户或未来的用户与系统的交互。
增量模型（Phased development）: increments and iterations（反复递增）
螺旋模型(Spiral model):将瀑布模型和快速原型模型结合起来，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统。
敏捷开发（Agile methods）：敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
可行性研究:压缩简化了的系统分析和设计的过程，也就是说在较高层次上以较抽象的方式进行设计的过程。不是解决问题，而是确定问题是否可解和是否值得解
系统流程图是概括地描绘物理系统的传统工具。它表达的是数据在系统各部件之间流动的情况，而不是对数据进行加工处理的控制过程。
结构化的分析方法使用数据流图DFD与数据字典DD来描述。其核心思想是分解化简问题，将物理与逻辑表示分开，对系统进行数据与逻辑的抽象。概括一下，结构化分析方法就是面向数据流自顶向下逐步求精进行需求分析的方法。
数据流图(DFD)：描绘信息流和数据从输入移动到输出的过程中所经受的变换。
数据字典(DD)作用：对软件中的每个数据规定一个定义条目，以保持数据在系统中的一致性。
27.ER diagram have three core constructs（P--158）ER 图表有三个核心构造
An entity: depicted as a rectangle, represents a collection of real-world objects that have common properties and behaviors描述为一个的矩形表示一个实际的对象的集合 具有公共属性和行为
A relationship: depicted as an edge between two entities, with diamond in the middle of the edge specifying（指定） the type of relationship描述为一个两个实体之间的边缘
An attribute: an annotation(注解) on an entity that describes data or properties associated with the entity描述数据或与该实体相关联的属性的实体上的注释
需求分析（requirements analysis）的[color=red]任务[/color]：
需求分析所要做的工作是深入描述软件的功能和性能，确定软件设计的限制和软件同其它系统元素的接口细节，定义软件的其它有效性需求。
一般说来，需求分析阶段的任务及工作：
1、确定对系统的综合要求
⑴ 功能要求（functional requirement）
⑵ 性能要求
⑶ 运行要求
⑷ 未来可能的扩充要求
(5) 可靠性和可用性需求
(6) 出错处理与安全需求
(7) 接口需求
(8) 约束因素（Design constraint）等
2、分析系统的数据要求
⑴建立概念模型:⑵形象描绘数据结构 ⑶数据结构规范化
3、导出逻辑模型
4、修正计划：重估成本、进度等
5、开发原型系统以检验方案的正确性及系统是否满足需求
需求分析（requirements analysis）的[color=red]原则[/color]：其基本原则可概括为:
（1）必须能够表达和理解问题的数据域和功能域；
（2）按自顶向下、逐层分解问题；
（3）要给出系统的逻辑视图和物理视图。
26. Requirements definition:
a complete listing of everything the customer wants to achieve完整列表的客户希望实现的一切
Describing the entities in the environment where the system will be installed
描述在将安装在系统环境中的实体
Requirements specification（需求规格）:
restates （重申）the requirements as a specification of how the proposed（提出） system shall behave
软件设计的任务：把分析阶段产生的软件需求说明转换为用适当方法表示的软件设计文档。不管采用何种软件设计方法，软件设计一般都包括数据设计、体系结构设计、接口设计和过程设计等内容。
[color=red]结构化设计方法[/color]：是一种面向数据流的设计方法，中心任务就是把用DFD图表示的系统分析模型转换为软件结构的设计模型，确定软件的体系结构与接口。
数据流的类型：
面向数据流的设计方法把信息流映射成软件结构，信息流的类型决定了映射的方法。信息流有下述两种类型：变换流和事务流。
结构化分析方法：
[color=red]模块[/color]：是一个拥有明确定义的输入、输出和特征的程序实体。模块的所有输入都是实现功能必不可少的，所有输出都有动作产生。
模块化：就是把程序划分成若干个模块，每个模块具有一个子功能，把这些模块集总起来组成一个整体，可以完成指定的功能，实现问题的要求。
模块化设计：把大型软件按照规定的原则划分成一个个较小的、相对独立但又相互关联的模块。分解和模块独立性，是实现模块化设计的重要指导思想。
[color=red]抽象[/color]：就是抽出事物的本质特性而暂时不考虑它们的细节。
[color=red]信息隐藏[/color]：模块中所包括的信息不允许其它不需要这些信息的模块调用。
[color=red]模块独立性[/color]：是软件系统中每个模块只涉及软件要求的具体子功能，而和软件系统中其他的模块接口是简单的。
[color=red]内聚[/color]（Cohesion）：标志一个模块内各个元素彼此结合的紧密程度。
[color=red]耦合[/color]（Coupling）：是对一个软件结构内各个模块之间互连程度的度量。
[color=red]深度[/color]：表示软件结构中控制的层数，它往往能粗略地标志一个系统的大小和复杂程度。
[color=red]宽度[/color]：是软件结构内同一个层次上的模块总数的最大值。
[color=red]扇出[/color]：是一个模块直接控制(调用)的模块数目，扇出过大意味着模块过于复杂，扇出过小(例如总是1)也不好。
[color=red]扇入[/color]：表明有多少个上级模块直接调用它，扇入越大则共享该模块的上级模块数目越多，这是有好处的，
35.We can measure coupling along a range of dependence
Characteristics of Good Design Coupling: Types of Coupling
Content(内容) coupling
Common (公共) coupling
Control (控制) coupling
Stamp (标记) coupling
Data (数据) coupling
软件设计的[color=red]基本原理[/color]：
(1)模块化 (2)抽象 (3)信息隐蔽 (4)模块独立性
软件设计的[color=red]基本经验[/color]：
模块独立性，低耦合，高内聚，公共模块。
[color=red]测试与调试[/color]：测试是为了发现程序中的错误而执行程序的过程。调试通过定位和纠正错误，消除软件故障，保证程序的可靠运行。
测试的种类：按照测试过程是否在实际应用环境中来分，有静态分析与动态测试。
测试方法（Testing Organization）：
[color=red]黑[/color]盒测试法，根据程序的功能来设计测试用例；
[color=red]白[/color]盒测试法，根据被测程序的内部结构设计测试用例。
通常的做法是，用黑盒法设计基本的测试方案，再用白盒法补充一些方案。
测试用例的设计是软件测试的中心内容。测试一个程序要使用多个测试用例，而每一个测试用例都应包括一组测试数据和一个相应的预期的测试结果。
黑盒测试法中的[color=red]3种常用技术[/color]：等价划分（等价分类）法、边界值分析法、错误推测（猜测）法。
白盒测试法：常用逻辑覆盖测试和路径测试法。
[color=red]测试的步骤[/color]：
[color=blue]1．单元测试（unit testing）
2．集成测试（Integration testing）
3．有效性测试
4．系统测试（System Testing）
5. 平行运行[/color]
软件可靠性（Software reliability）：是程序在给定的时间间隔内，按照规格说明书的规定成功地运行的概率。
软件维护：软件运行阶段对软件产品所进行的修改就是维护。
软件维护的种类：完善性维护；适应性维护；调试性维护;预防性维护。
软件可维护性（Software maintainability）：衡量软件维护容易程度的一种软件属性。定性的说，可维护性取决于软件的下列属性：可理解性、可修改性与可测试性。
软件配置：软件在生存周期内，它的各种形式、各种版本的文档与程序的总称。
软件[color=red]再工程[/color]：运用逆向工程、重构等技术，在充分理解原有软件的基础上，进行分解、综合，并重新构建软件，用以提高软件的可理解性、可维护性、可复用性或演化性。
1. UML图包含9类图：
①类图(class diagram) ②对象图(object diagram) ③用例图(use case diagram) ④顺序图(sequence diagram) ⑤协作图(collaboration diagram)
⑥状态图(statechart diagram) ⑦活动图(activity diagram)⑧组件图(component diagram)⑨部署图(deployment diagram)
2.使用UML对需求建模:我们可以使用用例(use case)作为着手进行需求建模的良好起点。用例按照系统的使用方式组织系统。以用例为起点进行需求建模，可以使我们的关注焦点集中于客户身上。
用例图是显示一组用例、参与者以及它们之间关系的图。
用例图包括以下三方面的内容。
1．参与者。2．用例。3．依赖、泛化和关联关系。
3.活动图:在UML中将这类描述活动流程的图形称为活动图（Activity Diagram）。
4.状态图:状态图（Statechart Diagram）对系统的动态方面进行建模
5.从UML设计角度，类的类型
通常类可以分为3种类型：实体类（entity）、边界类（boundary）和控制类（control）。
6．类与类之间的关系（分析）
关系（Relationship）是指事物之间的联系。 (1) 依赖（dependency） (2) 泛化（generalization） (3) 实现（realization） (4)关联
10. 请描述组件图和部署图的关系？
答：组件图用于描述系统中软件的构成，但没有描述系统中与硬件有关的构成情况。部署图则用于描述系统硬件的物理拓扑结构以及在此结构上运行的软件。
11．什么是正向过程和逆向工程：
正向过程是通过到实现语言的映射而把模型转换为代码的过程。
逆向工程是通过从特定实现语言的映射而把代码转换为模型的过程。
软件工程这门课程是做软件开发的人必学的课程，通过学这门课程，程序员就会注重软件开发的理论知识，以及做项目开发的思路。学了这门课程后你写程序就不会去盲目的去套用代码，而是理清此程序的架构以及思路。程序该从什么时候开始，什么时候结束。在中间需要添加什么样的功能，以完善该软件。其实学软件工程并不难，而且很容易。软件工程与日常生活联系起来的话，就是在一天中你该先做什么，后做什么。理解了先做什么，后做什么了以后写程序就不是那么难了，再复杂的程序也可以分成几大块。你理清程序的思路后就可以一步步的解决其中的难题，最终实现软件的功能。如果没学软件工程不知道理清程序的思路的话，做一个大的项目开发，那么多的代码，没有一个很好的结构，最终只会导致程序混乱，错误百出，知道代码再多也会素手无策的。
总而言之，作为一个程序员学习软件工程这门课程是至关必要的，如果没学习软件工程，你就不会做项目开发，也不可能开发出一个完善的软件出来。
●[color=red]软件[/color]：软件是能够完成预定功能和性能的可执行的计算机程序和使程序正常执行所需要的数据，加上描述程序的操作和使用的文档。
软件的特征：
(1)软件是一种逻辑实体，而不是具体的物理实体，因而它具有抽象性。
（2） 软件是通过人们的智力活动，把知识与技术转化成信息的一种产品
（3）软件成为产品后，其生产只是简单的拷贝，不同于硬件制造。
（4）维护过程比硬件复杂的多，甚至会引发新的错误。
[color=red]软件危机[/color]：指的是软件开发和维护过程中遇到的一系列严重问题。
出现软件危机的原因：
（1） 软件维护费用急剧上升，直接威胁计算机应用的扩大。
（2） 软件生产技术进步缓慢
软件工程：是指导计算机软件开发和维护的工程学科。
软件生存周期：一个软件从定义到开发、使用和维护，直到最终被弃用，要经历一个漫长的时期，通常把软件经历的这个漫长的时期称为生存周期。
[color=red]软件生存周期[/color]一般可分为以下阶段：
1.问题定义2.可行性研究。3需求分析4.总体（概要）设计。
5.详细设计。6.编码与单元测试。7.综合测试。8.软件维护
软件开发模型[color=red]（software process models）[/color]：软件开发模型是软件开发全过程、软件开发活动以及它们之间关系的结构框架。
瀑布模型(Waterfall model)即生存周期模型，由B.M.Boehm提出，是软件工程的基础模型。其核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作。采用结构化的分析与设计方法，将逻辑实现与物理实现分开。瀑布模型强调文档的作用，并要求每个阶段都要仔细验证。
快速原型模型（Prototyping model）:实现客户或未来的用户与系统的交互。
增量模型（Phased development）: increments and iterations（反复递增）
螺旋模型(Spiral model):将瀑布模型和快速原型模型结合起来，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统。
敏捷开发（Agile methods）：敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
可行性研究:压缩简化了的系统分析和设计的过程，也就是说在较高层次上以较抽象的方式进行设计的过程。不是解决问题，而是确定问题是否可解和是否值得解
系统流程图是概括地描绘物理系统的传统工具。它表达的是数据在系统各部件之间流动的情况，而不是对数据进行加工处理的控制过程。
结构化的分析方法使用数据流图DFD与数据字典DD来描述。其核心思想是分解化简问题，将物理与逻辑表示分开，对系统进行数据与逻辑的抽象。概括一下，结构化分析方法就是面向数据流自顶向下逐步求精进行需求分析的方法。
数据流图(DFD)：描绘信息流和数据从输入移动到输出的过程中所经受的变换。
数据字典(DD)作用：对软件中的每个数据规定一个定义条目，以保持数据在系统中的一致性。
27.ER diagram have three core constructs（P--158）ER 图表有三个核心构造
An entity: depicted as a rectangle, represents a collection of real-world objects that have common properties and behaviors描述为一个的矩形表示一个实际的对象的集合 具有公共属性和行为
A relationship: depicted as an edge between two entities, with diamond in the middle of the edge specifying（指定） the type of relationship描述为一个两个实体之间的边缘
An attribute: an annotation(注解) on an entity that describes data or properties associated with the entity描述数据或与该实体相关联的属性的实体上的注释
需求分析（requirements analysis）的[color=red]任务[/color]：
需求分析所要做的工作是深入描述软件的功能和性能，确定软件设计的限制和软件同其它系统元素的接口细节，定义软件的其它有效性需求。
一般说来，需求分析阶段的任务及工作：
1、确定对系统的综合要求
⑴ 功能要求（functional requirement）
⑵ 性能要求
⑶ 运行要求
⑷ 未来可能的扩充要求
(5) 可靠性和可用性需求
(6) 出错处理与安全需求
(7) 接口需求
(8) 约束因素（Design constraint）等
2、分析系统的数据要求
⑴建立概念模型:⑵形象描绘数据结构 ⑶数据结构规范化
3、导出逻辑模型
4、修正计划：重估成本、进度等
5、开发原型系统以检验方案的正确性及系统是否满足需求
需求分析（requirements analysis）的[color=red]原则[/color]：其基本原则可概括为:
（1）必须能够表达和理解问题的数据域和功能域；
（2）按自顶向下、逐层分解问题；
（3）要给出系统的逻辑视图和物理视图。
26. Requirements definition:
a complete listing of everything the customer wants to achieve完整列表的客户希望实现的一切
Describing the entities in the environment where the system will be installed
描述在将安装在系统环境中的实体
Requirements specification（需求规格）:
restates （重申）the requirements as a specification of how the proposed（提出） system shall behave
软件设计的任务：把分析阶段产生的软件需求说明转换为用适当方法表示的软件设计文档。不管采用何种软件设计方法，软件设计一般都包括数据设计、体系结构设计、接口设计和过程设计等内容。
[color=red]结构化设计方法[/color]：是一种面向数据流的设计方法，中心任务就是把用DFD图表示的系统分析模型转换为软件结构的设计模型，确定软件的体系结构与接口。
数据流的类型：
面向数据流的设计方法把信息流映射成软件结构，信息流的类型决定了映射的方法。信息流有下述两种类型：变换流和事务流。
结构化分析方法：
[color=red]模块[/color]：是一个拥有明确定义的输入、输出和特征的程序实体。模块的所有输入都是实现功能必不可少的，所有输出都有动作产生。
模块化：就是把程序划分成若干个模块，每个模块具有一个子功能，把这些模块集总起来组成一个整体，可以完成指定的功能，实现问题的要求。
模块化设计：把大型软件按照规定的原则划分成一个个较小的、相对独立但又相互关联的模块。分解和模块独立性，是实现模块化设计的重要指导思想。
[color=red]抽象[/color]：就是抽出事物的本质特性而暂时不考虑它们的细节。
[color=red]信息隐藏[/color]：模块中所包括的信息不允许其它不需要这些信息的模块调用。
[color=red]模块独立性[/color]：是软件系统中每个模块只涉及软件要求的具体子功能，而和软件系统中其他的模块接口是简单的。
[color=red]内聚[/color]（Cohesion）：标志一个模块内各个元素彼此结合的紧密程度。
[color=red]耦合[/color]（Coupling）：是对一个软件结构内各个模块之间互连程度的度量。
[color=red]深度[/color]：表示软件结构中控制的层数，它往往能粗略地标志一个系统的大小和复杂程度。
[color=red]宽度[/color]：是软件结构内同一个层次上的模块总数的最大值。
[color=red]扇出[/color]：是一个模块直接控制(调用)的模块数目，扇出过大意味着模块过于复杂，扇出过小(例如总是1)也不好。
[color=red]扇入[/color]：表明有多少个上级模块直接调用它，扇入越大则共享该模块的上级模块数目越多，这是有好处的，
35.We can measure coupling along a range of dependence
Characteristics of Good Design Coupling: Types of Coupling
Content(内容) coupling
Common (公共) coupling
Control (控制) coupling
Stamp (标记) coupling
Data (数据) coupling
软件设计的[color=red]基本原理[/color]：
(1)模块化 (2)抽象 (3)信息隐蔽 (4)模块独立性
软件设计的[color=red]基本经验[/color]：
模块独立性，低耦合，高内聚，公共模块。
[color=red]测试与调试[/color]：测试是为了发现程序中的错误而执行程序的过程。调试通过定位和纠正错误，消除软件故障，保证程序的可靠运行。
测试的种类：按照测试过程是否在实际应用环境中来分，有静态分析与动态测试。
测试方法（Testing Organization）：
[color=red]黑[/color]盒测试法，根据程序的功能来设计测试用例；
[color=red]白[/color]盒测试法，根据被测程序的内部结构设计测试用例。
通常的做法是，用黑盒法设计基本的测试方案，再用白盒法补充一些方案。
测试用例的设计是软件测试的中心内容。测试一个程序要使用多个测试用例，而每一个测试用例都应包括一组测试数据和一个相应的预期的测试结果。
黑盒测试法中的[color=red]3种常用技术[/color]：等价划分（等价分类）法、边界值分析法、错误推测（猜测）法。
白盒测试法：常用逻辑覆盖测试和路径测试法。
[color=red]测试的步骤[/color]：
[color=blue]1．单元测试（unit testing）
2．集成测试（Integration testing）
3．有效性测试
4．系统测试（System Testing）
5. 平行运行[/color]
软件可靠性（Software reliability）：是程序在给定的时间间隔内，按照规格说明书的规定成功地运行的概率。
软件维护：软件运行阶段对软件产品所进行的修改就是维护。
软件维护的种类：完善性维护；适应性维护；调试性维护;预防性维护。
软件可维护性（Software maintainability）：衡量软件维护容易程度的一种软件属性。定性的说，可维护性取决于软件的下列属性：可理解性、可修改性与可测试性。
软件配置：软件在生存周期内，它的各种形式、各种版本的文档与程序的总称。
软件[color=red]再工程[/color]：运用逆向工程、重构等技术，在充分理解原有软件的基础上，进行分解、综合，并重新构建软件，用以提高软件的可理解性、可维护性、可复用性或演化性。
1. UML图包含9类图：
①类图(class diagram) ②对象图(object diagram) ③用例图(use case diagram) ④顺序图(sequence diagram) ⑤协作图(collaboration diagram)
⑥状态图(statechart diagram) ⑦活动图(activity diagram)⑧组件图(component diagram)⑨部署图(deployment diagram)
2.使用UML对需求建模:我们可以使用用例(use case)作为着手进行需求建模的良好起点。用例按照系统的使用方式组织系统。以用例为起点进行需求建模，可以使我们的关注焦点集中于客户身上。
用例图是显示一组用例、参与者以及它们之间关系的图。
用例图包括以下三方面的内容。
1．参与者。2．用例。3．依赖、泛化和关联关系。
3.活动图:在UML中将这类描述活动流程的图形称为活动图（Activity Diagram）。
4.状态图:状态图（Statechart Diagram）对系统的动态方面进行建模
5.从UML设计角度，类的类型
通常类可以分为3种类型：实体类（entity）、边界类（boundary）和控制类（control）。
6．类与类之间的关系（分析）
关系（Relationship）是指事物之间的联系。 (1) 依赖（dependency） (2) 泛化（generalization） (3) 实现（realization） (4)关联
10. 请描述组件图和部署图的关系？
答：组件图用于描述系统中软件的构成，但没有描述系统中与硬件有关的构成情况。部署图则用于描述系统硬件的物理拓扑结构以及在此结构上运行的软件。
11．什么是正向过程和逆向工程：
正向过程是通过到实现语言的映射而把模型转换为代码的过程。
逆向工程是通过从特定实现语言的映射而把代码转换为模型的过程。
软件工程这门课程是做软件开发的人必学的课程，通过学这门课程，程序员就会注重软件开发的理论知识，以及做项目开发的思路。学了这门课程后你写程序就不会去盲目的去套用代码，而是理清此程序的架构以及思路。程序该从什么时候开始，什么时候结束。在中间需要添加什么样的功能，以完善该软件。其实学软件工程并不难，而且很容易。软件工程与日常生活联系起来的话，就是在一天中你该先做什么，后做什么。理解了先做什么，后做什么了以后写程序就不是那么难了，再复杂的程序也可以分成几大块。你理清程序的思路后就可以一步步的解决其中的难题，最终实现软件的功能。如果没学软件工程不知道理清程序的思路的话，做一个大的项目开发，那么多的代码，没有一个很好的结构，最终只会导致程序混乱，错误百出，知道代码再多也会素手无策的。
总而言之，作为一个程序员学习软件工程这门课程是至关必要的，如果没学习软件工程，你就不会做项目开发，也不可能开发出一个完善的软件出来。
扫一扫
6万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
