软件工程知识点汇总Word文档下载推荐.doc

软件工程知识点汇总Word文档下载推荐.doc

《软件工程知识点汇总Word文档下载推荐.doc》由会员分享，可在线阅读，更多相关《软件工程知识点汇总Word文档下载推荐.doc（11页珍藏版）》请在冰豆网上搜索。

2.2信息隐蔽原则：

采用封装技术，将程序模块的实现细节隐藏起来，使模块接口尽量简单。

2.3抽象化原则：

抽取事物最基本的特性和行为，忽略非本质细节，采用分层次抽象，自顶向下，逐层细化的办法控制软件开发过程的复杂性。

2.4模块独立原则：

是指每个模块只完成系统要求的独立子功能，并且与其他模块的联系最少且接口简单。

要求在一个物理模块内集中逻辑上相互关联的计算机资源，保证模块间由松散的偶合关系，模块内部有较强的内聚性，这有助于控制系统的复杂性。

（即：

高内聚低耦合）

2.5依赖倒转原则：

抽象不应该依赖于细节，细节应该依赖于抽象。

2.6开闭原则：

软件实体应该是可扩展的，但是不可以修改。

即对于扩展是开放的，对于更改是封闭的。

3软件开发模型：

瀑布模型；

快速原型；

喷泉模型；

各种模型的工作原理、阶段、每阶段任务、特点、示意图；

软件开发模型（也称为软件过程模型）：

是从软件项目需求定义开始直至软件经使用后废弃为止，跨越整个生命周期的系统开发、运行和维护所实施的全部过程、活动和任务的结构框架

3.1瀑布模型（又称线性模型）：

3.1.1工作原理：

规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。

前一阶段的工作成果是后一阶段工作开始的基础.所以,每个阶段都必须交出合格的文档,必须对前阶段的工作进行评审,前一阶段的工作完成后才可以开始后一阶段的工作

3.1.2阶段：

计划时期：

问题定义、可行性研究

开发时期：

需求分析、设计、编码、测试

运行时期：

运行和维护

3.1.3各阶段任务：

1.需求分析和定义

在软件项目进行过程中，需求分析是从软件定义到软件开发的关键步骤，是今后软件，开发的基本依据，同时也是用户对软件产品进行验收的基本依据。

需求分析和定义是以用户需求为基本依据，从功能、性能、数据、操作等多个方面，对软件系统给出完整、准确、具体的描述，用于确定软件规格。

2.软件设计

根据系统需求的定义，确定系统的结构，进行系统的概要设计和各部分的功能与结构的详细设计。

3.编码与单元测试

在这一阶段，根据软件设计文档完成了程序模块或程序单元的编码。

通过程序单元测试，验证其是否满足设计规范。

4.集成和系统测试

程序模块或程序单元被组装集成起来成为一个软件系统，然后进行系统测试。

测试完成后即交付用户使用。

5.运行和维护

通常这是软件生命周期中最长的一个阶段。

如果在运行期发现了软件的错误，就要修改软件，可能会重复上述某个或多个阶段的活动。

3.1.4特点：

①顺序性、依赖性：

下一阶段依赖上一阶段的完成。

②推迟实现：

阶段任务结束形成文档，并审核后方能进行设计任务，将程序的实现推迟进行。

③质量保证:

文档完整、文档评审，避免错误积累与放大效应。

3.1.5示意图：

3.2快速原型

3.2.1工作原理：

快速原型是利用原型辅助软件开发的一种新思想。

经过简单快速分析，快速实现一个原型，用户与开发者在试用原型过程中加强通信与反馈，通过反复评价和改进原型，减少误解，弥补漏洞，适应变化，最终提高软件质量。

废弃型：

也称快速建立需求规格原型法：

先构造一个功能简单而质量要求不高的模型系统，针对这个模型系统反复的进行分析修改，从而形成较好的设计思想，据此设计出更加完整、准确、一致可靠的最终系统，系统构造完成后，原来的模型就被废弃

追加型：

也称快速建立渐进原型法。

它采用循序渐进的开发方式，对系统模型作连续精化，即先构造一个功能简单而且质量要求不高的模型系统，最为最终系统的核心，将系统需要具备的性能逐步添加上去，通过不断地扩充修改，逐步追加新的要求，直至所有性能全部满足，此时原型模型也就是最终的产品。

3.2.2阶段及任务

原型快速分析：

是指在分析者和用户的紧密配合下，快速确定软件系统的基本要求，根据原型所要体现的特性（总体结构、处理功能、模拟性能、界面形式等），描述基本需求规格说明，以满足开发圆形的需要。

原型构造：

在快速原型分析的基础上，根据基本需求规格说明，忽略细节只考虑主要特性快速构造一个可运行的系统。

原型运行与评价：

是软件开发人员与用户频繁通信、发现问题、消除误解的用药阶段，目的是验证原型的正确程度，进而开发新的并修改原有的需求。

原型修改：

根据评价原型的活动结果进行修改。

若原型未满足需求说明的要求，说明 对需求说明存在不一致的理解或实现方案不够合理，则根据明确的要求迅速修改原型。

3.2.3特点

1．增强了软件开发人员和用户对系统需求的理解，便于将用户模糊的功能需求明确化

2．为用户提供了一种强有力的学习手段

3．易于确定系统的性能，是理解和确定软件需求规格说明的良好工具

4．按照快速建立渐进原型法建立的原型即为最终的产品

利用快速原型化技术可以为软件开发提供一种完整、灵活、近似动态的需求规格说明方法。

3.2.4示意图

3.3喷泉模型

3.3.1工作原理：

喷泉模型是一种以用户需求为动力，以对象为驱动的模型，主要用于描述面向对象的软件开发过程。

该模型认为软件开发过程自下而上周期的各阶段是相互重叠和多次反复的，各个开发阶段没有特定的次序要求，并且可以交互进行，可以在某个开发阶段中随时补充其他任何开发阶段中的遗漏。

3.3.2阶段

3.3.3每阶段任务

3.3.4特点：

喷泉模型体现了软件创建所固有的迭代和无间隙的特征。

迭代指系统中某个部分常常重复工作多次，无间隙指活动之间没有明显的间隙，如在分析和设计之间没有明显的界限。

3.3.5示意图

。

4软件生命周期：

阶段、各阶段功能、所涉及的内容（图、工具和文档）

4.1软件生命周期：

是指一个计算机软件从功能确定、设计到开发成功投入使用，并在使用中不断地修改、增补和完善，知道被新的需求所替代而停止该软件的使用全过程。

4.2四个工作阶段：

初始阶段：

建立业务模型，定义最终产品视图，并且确定项目的范围。

精化阶段：

设计并确定系统的体系结构，制定项目计划，确定资源需求。

构建阶段：

开发出所有构件和应用程序，把它们集成为客户需要的产品，并且详尽地测试所有功能。

移交阶段：

把开发出的产品提交给用户使用

4.3各阶段功能：

1问题定义可行性研究

可性研究的任务是以最小的代价在尽可能短的时间内确定问题是否值得解决、是否能够解决。

阶段性成果《项目可行性报告》

2需求分析阶段

需求分析的主要任务就是要通过软件开发人员与用户的交流和讨论，准确地获取用户对系统的具体要求。

阶段性成果《需求规格说明书》、数据字典、数据流图（DFD）

3概要设计阶段

划分出组成系统的物理元素，设计软件的结构，即确定模块及模块间的关系，根据需求分析阶段得到的逻辑模型来设计系统的物理模型

阶段性成果《概要设计说明书》

4详细设计阶段

设计每个模块的算法，确定每一模块使用的数据结构，确定模块接口的细节，为每一个模块设计一个测试用例，编写详细设计说明书

《软件详细设计》文档

5编码和单元测试

6系统测试

7软件维护阶段

4.4各阶段所涉及的内容（文档、工具、图）

5结构化方法:

生命周期中各阶段任务.获取用户需求、画数据流图、数据字典

6可行性分析、需求分析、设计（概要设计+详细设计）、测试、维护

7面向对象方法：

核心概念、模型

7.1面向对象中的基本概念：

对象：

代表了一个现实的或虚构的实体

类：

对具有相同数据和相同操作的一组相似对象的定义

继承：

子类自动的共享父类中定义的数据和方法的机制

多态性：

一个名字具有多种语义

封装：

将属性和操作包装成一个单元，使得对状态的访问和修改只能通过封装提供的接口进行

消息：

对象间在交互中所传送的通讯信息

关联：

对象之间所存在的联系

7.2模型

对象模型：

即寻找问题域中的对象，从对象中抽象出类的定义，识别对象的内部特征，定义属性，识别对象的外部关系，识别主题。

动态模型：

即建立交互图、状态图和活动图，进一步定义用例。

功能模型：

即用例分析，以用例对用户需求进行规范化描述；

为了更好地理解问题，人们常采用建立建立问题模型的方法。

模型就是为了理解事物而对事物作出的一种抽象，是对事物的一种无歧义的书面描述。

通常，模型由一组图示符号和组织这些符号的规则组成。

模型是一种思考工具，可以把知识规范地表示出来。

对于那些因过分复杂而不能直接理解的系统，特别需要建立模型，建模的目的主要是为了减少复杂性。

一旦建立起模型之后，就要经受用户和各个领域专家的严格审查。

模型常常会经过多次必要的修改。

用OO方法开发软件，通常需要建立3种形式的模型：

对象模型----描述系统数据结构；

动态模型----描述系统控制结构；

功能模型----描述系统功能；

这三种模型各自从不同的侧面反映软件系统的内容，相互影响、相互制约，有机地结合在一起，全面地表达对目标系统的需求。

对象模型表示静态的、结构化的系统的“数据”性质。

描述了系统的静态结构。

面向对象方法强调围绕对象而不是功能来构造系统。

对象模型为建立动态模型和功能模型，提供了实质性的框架。

1997年11月，国际对象管理组织OMG批准把UML1。

1作为基于面向对象技术的标准建模语言。

通常，使用UML的类图来建立对象模型。

在UML中术语“类”的实际含义是，“一个类及属于该类的对象”

-----------------------------------------------

状态模型表示瞬时的、行为化的系统的“控制”性质，它规定了对象模型中的对象的合法变化序列。

一旦建立起对象模型之后，就需要考察对象的动态行为。

所有对象都具有自己的生命周期。

状态，是对对象属性值的一种抽象。

各对象之间相互触发就形成了一系列的状态变化。

一个触发行为称作一个事件。

对象对事件的响应，取决于接受该触发的对象当时所处的状态，响应包括改变自己的状态或者又形成一个新的触发行为。

状态有持续性，它占用一段时间间隔。

状态与事件密不可分，一个事件隔开两个状态，一个状态隔开两个事件。

事件表示时刻，状态表示时间间隔。

UML中用状态图来描绘对象的状态、触发状态转换的事件及对象的行为。

每个类的动态行为用一张状态图来描绘，各个类的状态图通过共享事件合并起来，从而构成系统的动态模型。

动态模型是基于事件共享而互相关联的一组状态图的集合。

功能模型表示变化的系统的“功能”性质，它指明了系统应该“做什么”，因此更直接地反映了用户对目标系统的需求。

通常，功能模型由一组数据流图组成。

在OO方法中，数据流图远不如在结构化方法