软件工程要点串讲

《软件工程要点串讲》由会员分享，可在线阅读，更多相关《软件工程要点串讲（11页珍藏版）》请在金锄头文库上搜索。

1、第一讲第一讲 概概 述述 1.1 软件工程的研究内容 （1）软件工程要考虑专业软件开发所需要的理论、方法和工具-工程技术问题 （2）软件工程要考虑如何有效的在软件开发中利用有限的成本资源-工程管理的问 题 1.2 什么是软件? （1）软件包括：-软件的内涵 能够提供客户所需功能与性能的计算机程序；计算机程序； 使程序能够适当的操作信息的数据结构；数据结构； 用以描述程序开发过程及使用的文档文档。 （2）软件产品可以为一个特定的用户设计开发，也可以为某一类通用的市场设计开发。（3）软件产品可以分成：通用软件（Generic Software） 、 定制软件（Bespoke Software） （

2、4）一个新的软件并不一定是全新开发，可以由现有软件或可复用软件成分配置形成。1.3 什么是软件工程 ？ （1）软件工程是涉及软件生产各个方面的一门工程学科 （2）软件工程涉及软件生命周期的各个方面，从软件需求的确定到软件退役。 （3）软件工程：将系统化的、规范的、可度量的方法应用于软件的开发、运行和维 护的过程，即将工程化应用于软件；研究中的方法. 1.4 什么是成功的软件项目：按时交付、不超预算、满足用户要求。 1.5 （1）所有的软件过程软件过程中都包括四个基本活动:描述、开发、有效性验证、进化。 （2）软件生命周期软件生命周期是软件过程的另一种形象描述，包括：需求定义、分析与描述、 软件

3、设计、实现、测试、维护与退役等活动。 1.6 什么是优良软件的属性优良软件的属性？可维护性、可依赖性、有效性和可用性（可接受性） 。第二讲第二讲 软件过程软件过程2.1 瀑布模型（顺序模型）瀑布模型（顺序模型）瀑布模型的缺点和适用情况 （1）这种模型生硬的把一个软件过程划分成几个界限清晰的阶段，而且这些阶段前后有严 格的顺序，这导致它很难对用户的需求变更做出及时的调整； （2）因此，瀑布模型只适合需求非常清楚和需求变更被严格限制的情况下。 2.2 进化式开发模型进化式开发模型 基本思想：通过开发系统原型和用户反复交互，以明确需求，使系统在不断调整与修改中 得以进化成熟。又叫做原型式开发方法。

4、两种基本类型：探索式开发、抛弃式原型法问题：问题：缺乏过程可见性、系统结构通常会很差、需要一些特别的技术（如原型快速开发技 术） 、通常与主流技术不兼容. 适用情况：适用情况：适合中小规模的交互系统、可用于大型系统的局部开发（如系统界面） ，可以和 瀑布模型混合使用、生命周期较短的系统。 2.3 增量式开发增量式开发 增量式开发的特点特点 （1）在这种开发方式中，系统不是作为一个整体交付，而是被分解成若干个增量，每个增 量交付系统的部分功能。 （2）用户的需求按优先级排队，优先级最高的需求被放入最早交付的增量中。这样，优先 级最高的系统功能就得到最多的测试，系统的可靠性较高。 2.4 基于构件

5、的软件工程基于构件的软件工程 （1）软件复用是指在两次或多次不同的软件开发过程中重复使用相同或相似软件元素（通 常称为可复用构件、组件或软部件）的过程。 （2）软构件是标准的、可以互换的、经过装配可随时使用的软件模块。 软件复用的意义：（1）软件复用的出发点是使软件系统的开发不再“一切从零开始” ，能够充分利用已有的 知识和经验。 （2）软件复用能够在软件开发中避免重复劳动，充分利用已有的开发成果， ，提高开发效 率，降低开发成本。 （3）软件复用还可以避免全新开发可能引入的错误，从而提高软件的开发质量。第三讲第三讲 需求工程需求工程 3.1 需求工程过程需求工程过程 需求工程过程并不具有唯一

6、的模型，在所有的过程中都会涉及一些共同的活动，它们是： 可行性研究、需求导出与分析、需求描述、需求有效性验证、需求管理。 3.2 可行性研究：可行性研究： （1）可行性研究要决定被提议的系统是否值得去做。 （2）进行可行性研究包括信息评估、信息汇总和书写报告三部分工作。 3.3 需求的两个不同层次的描述需求的两个不同层次的描述 用户需求：从客户的角度，采用自然语言配合以图表对目标系统应提供的服务以及系统操 作要受到的约束进行的声明。 系统需求：系统需求是一种结构化文档，要运用一些专业的模型详细的描述系统的功能及 其约束。系统需求文档有时也称为功能描述，应该是精确的，它可以成为双方之间合同的 重

7、要内容，同时作为开发工作的依据。 3.4 功能需求与非功能需求功能需求与非功能需求 功能需求：对系统应提供的功能，系统在特定的输入下做出的反应及特定条件下的行为的 描述。某些情况下还要包括系统不应做什么。 非功能需求：对系统提供服务或功能时收到的约束进行描述。如时间约束、开发过程约束 和标准等。 领域需求：这种需求来自于系统的应用领域，反映领域特征。可能是功能需求也可能是非 功能需求。 功能性需求与非功能性需求相比较，非功能需求往往更为关键，因为非功能需求表示的是 系统的整体特征，而功能性需求描述的则是局部功能。 3.7 需求导出与分析需求导出与分析 （1）这个阶段在可行性研究之后进行，通常与

8、需求描述交叉进行。 （2）需求导出的过程活动包括：需求发现、需求的分类与组织、优先排序和冲突解决、需 求文档化。 （3）需求的发现与识别是整个过程中最为关键的活动，负责收集目标系统级现存系统的相 关信息并从这些信息中提炼出用户需求和系统需求。 （4）信息的来源包括已有的文件，系统的信息持有者（stakeholders）以及相近系统的规约 描述。 （5）需求要从多个视点进行分析 （6）视点用来表述不同角度的需求来源（信息持有者、其它相关系统及领域） 。每一个视 点代表系统需求的一个子集。3.8 结构化分析（结构化分析（SA）建模）建模（1）结构化分析方法是一种面向数据流的系统建模技术，它从数据加

9、工的角度对系统进行 规格描述； （2）SA 帮助分析者理解系统的功能，并采用模型与用户进行交流； （3）不同的模型从不同的角度对系统进行描述。 （4）结构化分析模型的核心是数据词典数据词典，它描述了所有的在目标系统中使用的和生成的数 据对象。 （5）围绕着这个核心的有三种图：实体实体关系图关系图(ERD)描述数据对象及数据对象之间的关 系；数据流图数据流图(DFD)描述数据在系统中如何被传送或变换，以及描述如何对数据流进行变 换的功能（子功能） ；状态状态迁移图迁移图(STD)描述系统对外部事件如何响应，如何动作。 （6）因此，ERD 用于数据建模，DFD 用于功能建模，STD 用于行为建模。

10、 3.9 UML 与面向对象分析方法与面向对象分析方法 3.9.1 理解 UML UML 是一种标准的图形化建模语言，它为不同领域的人们提供一种统一的交流标准，这种 标准使得系统构造者能够用标准的、易于理解的方式建立能表达出他们想象力的系统蓝图， 并使客户、分析员、设计人员、程序员和系统其它涉及者能够相互理解和达成一致，从而 能够有效地共享和交流设计结果。3.10 需求有效性验证需求有效性验证 （1）需求有效性验证的目的是检验需求描述是否正确地反映了客户的意愿。 （2）好的需求对软件系统的开发效率及软件质量起着至关重要的作用。一个错误发现的越 晚，修改它所付出的代价就越大。3.11 需求检查几

11、个方面：有效性、一致性、完备性、现实性、可检查性。 需求有效性检验技术：需求评审、建立原型、测试用例生成。 第四讲第四讲 设计工程设计工程4.1 软件工程中的设计软件工程中的设计 （1）设计是一个把问题转换成解决方案的创造性过程； （2）设计解决的是“如何实现系统”的问题； （3）从工程管理的角度，软件设计可以分成概要设计（总体设计、系统设计）与细节设计 （详细设计） 4.2.1 模块化模块化 （1）模块化的思想，即把软件划分为可独立命名和编址的构件，每个构件称为一个模块， 每个模块完成一个子功能，当把所有模块组装到一起成为一个整体时，便可以完成指定的 功能。 （2）模块组成系统或子系统。 （

12、3） “一个复杂问题分割成若干个容易解决、容易管理的小问题后更易于求解” ，模块化正 是以此为依据把系统划分成若干个模块，各个击破。 4.2.2 信息隐藏与独立性信息隐藏与独立性 （1）信息隐藏原理告诉我们，模块应该设计得使其所含信息（过程和数据）对于那些不需 要这些信息的模块来说不可访问；每个模块只完成一个相对独立的特定功能；模块之间仅 交换那些为完成系统功能必须交换的信息，即模块应该功能独立的。 （2）采用信息隐藏原理指导模块设计有很多好处：1）它支持模块的并行开发；2）减少测试和后期维护的工作量。因为测试和维护阶段不可避免地要修改设计和代码，模块对大多数数据和过程处理细节的隐藏可以减少错

13、误向外传播。3）整个系统扩充功能只需“插入”新模块，原有的多数模块无须改动。 4.2.3 模块独立性（模块独立性（Independency） （1）模块独立性的概念是模块化、抽象和信息隐藏概念的直接产物，模块独立性是通过开 发具有单一功能和与其他模块没有过多交互作用的模块来达到的。 （2）独立性好的模块对其它的模块依赖性小，修改时对其它模块的影响小，易于修改和扩 充，因此有良好的可维护性。 （3）模块独立性可用两个定性准则来度量：耦合性（coupling）和内聚性（cohesion） 。（4）耦合是模块之间相对独立性的量度，而内聚则是模块功能相对强度的量度。 （5）模块的内聚性越强，耦合性越弱

14、，独立性越强。 4.3 体系结构设计体系结构设计 （1）体系结构（architecture,又称架构）设计的任务是要识别出组成系统的子系统并建立子 系统的控制和通信框架。 （2）体系结构设计是联系需求描述与其他设计活动的桥梁。 系统的组成系统的组成 （1）系统的组成反映的是系统组织所采用的基本策略。 三种应用广泛的组成类型：数据中心体系结构（容器模型） 、客户/服务器体系结构、抽象 机或分层体系结构。 4.3.1 数据中心体系结构（容器）数据中心体系结构（容器） 数据中心体系结构（容器模型）的基本特点： （1）所有共享数据放到一个中心数据库（容器）中，所有子系统都能从中存取数据； （2）当系统

15、中存在大量的数据共享时，数据中心（容器）模型是最为常用的体系结构风格。4.3.2 客户客户/服务器体系结构服务器体系结构 （1）客户/服务器模型是一个分布式系统模型，数据和加工过程在多个处理器之间分配； （2）这种模型的主要组成： 一组为其它子系统提供服务的单机服务器服务器； 一组向服务器请求服务的客户机客户机； 连接客户机与服务器的网络网络。 4.3.3 分层（抽象机）体系结构分层（抽象机）体系结构 （1）这种模型把系统组织成一系列的层次（抽象机） ，每一层提供一组服务； （2）这种模型支持增量式的开发，不同层次的服务可以单独交付； （3）层与层之间以接口相联系，一个接口发生改变，只有毗邻的

16、层会受到影响； 4.4 控制模型控制模型 （1）控制模型考虑子系统之间的控制流，这是分解模型不考虑的问题。 （2）对控制流建模有两种一般性的方法： 1）集中式控制：一个子系统专门负责控制，控制其他子系统的启动与停止。 2）基于事件的控制：不将控制信息集中在一个子系统内，每个子系统都能够接受来自系统 外部的事件并作出响应。 4.6 用户界面设计过程用户界面设计过程4.7 界面设计的一般原则界面设计的一般原则：用户熟悉、一致性、意外最小化、可恢复性、用户差异性 4.8 错误消息：错误消息： （1）错误消息的设计对界面设计的成败是非常关键的。 设计很差的错误消息会导致用户 对整个系统反感。 （2）错误消息应该是礼貌的、简明的、一致的和建设性的。 4.9 帮助系统设计：帮助系统设计：软件帮助系统不能是用户手册的简单复制，应该有一个合理的组织与 结构，应该为用户提供不同的入口。 第五讲第五讲 软件实现与验证软件实现与验证 5.1 程序设计与调试程序设计与调试 （1）程序设计的任务是