软工考试材料.docx

1、软工考试材料软件的定义（P1）软件是能够完成预定功能和性能的可执行的计算机程序软件是逻辑的而不是物理的，是抽象产品（P2） -？面向对象软件工程（P9）它以面向对象程序设计为基础，其他开发过程课包含以下阶段：OO分析与对象抽象 对象详细设计 面向对象的编码与测试软件生存周期（P19）定义：一个软件从开始立项起，到废弃不用止，统称为软件的生存周期（软件生存周期包 含是三个阶段：软件定义、软件开发和软件运行维护）主要活动：1、需求分析；2、软件分析；3、软件设计；4、编码；5、软件测试；6、运行维护。传统软件过程-模型（P21）一、瀑布模型各项活动按自上而下，相互衔接的固定次序，如同瀑布逐级下落。

2、各项活动均处于一个质量环（输入-处理-输出-评审）中。二、快速原型模型快速原型模型（Rapid Prototype Model）的主要做法是：首先建立一个能够反映用户主要需求的原型，让用户实际看一看未来系统的概貌，以便判断哪些功能是符合需要的，哪些方面还需要改进。快速原型系统的优越性主要体现在：软件开发人员向用户提供一个“样品”，用户向开发人员迅速作出“反馈”如何产生快速原型系统？1、原型系统仅包括未来系统的主要功能，以及系统的重要接口。2、为了尽快向用户提供原型，开发原型系统时应尽量使用能缩短开发周期的语言和工具。3、把原型系统作为基础，通过补充与修改获得最终的实际系统。快速原型模型带来的问

3、题：需要足够的人力资源、用户和设计成为关键、适用于MIS形式的系统。三、增量模型 先完成一个系统自己的啊，再按不同的开发步骤增加功能（系统子集），如此递增下去直至满足全部系统需求。（系统的总体设计要在初始子集设计阶段就应作出设想）把软件产品分解成一系列的增量构建，在增量模型开发迭代中逐步加入。每个构件由多个相互作用模块构成，并且能够完成特定的功能。增量开发方法的新演进版本叫做“极限程序设计”四、螺旋模型 集合瀑布模型与快速原型模型的基础上增加了风险分析。螺旋模型沿着螺线旋转，在四个象限上分别表达四个方面的活动，即：制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件；风险分析：分析所选

4、方案，考虑如何识别和消除风险；实施工程：实施软件开发；客户评估：评价开发，提出修正建议。要点：相似于增量模型，是顺序过程与原型过程的统一，强调版本和版本升级。 与增量模型的区别：活动划分不同；更强调“计划”、“风险分析”和“用户评估”；版本有更明确的目标 版本的明确目标：概念项目增量项目维护项目。 螺旋模型将瀑布模型与快速原形模型结合起来，并且加入两种模型均忽略了的风险分析。 螺旋模型沿着螺线旋转，自内向外每旋转一圈便开发出更完善的一个新版本。 可行性研究的内容、时间、权限（P35） -？1、经济可行性；2、技术可行性；3、运行可行性；4、法律可行性5、时间可行性SA模型的组成（P45）数据字

5、典（DD）：目的是对数据流程图中的各个元素做出详细的说明。它是系统所涉及的各种数据对象的总和。从DD出发可构建3种图：1、实体联系图（E-R）：用于描述数据对象间的关系，他代表软件的数据模型，在实体-关系图中出现的每个数据对象的属性均可用数据对象说明来描述；2、数据流图（DFD图）：作用是指明系统中数据是如何流动和变换的，以及描述是数据流进行变换的功能，在DFD图中出现的每个功能的描述则写在（PSPEC）中，它们一起构成功能模型；3、状态变换图（STD状态-变迁图）：用于指明系统在外部时间的作用下将会如何动作，表明了系统的各种状态以及各种状态间的变迁，从而构成为行为模型的基础，关于软件控制方面

6、的附加信息则包含在控制说明（CSPEC）。数据字典书写方法：定义：DD是对所有与系统相关的数据元素的一个有组织的列表,以及精确的、严格的定义，使得用户和系统分析员对于输入、输出、存储成分和中间计算有共同的理解 作用：DFD中的数据流、数据存储表示某个有组织的数据集合，它们要由SA的其他描述工具-需求字典(数据字典)来描述，包括： 词条描述、 数据结构描述、 加工逻辑说明数据字典的内容：数据流、数据流分量、数据存储、处理定义数据的方法：由数据元素组成数据的方式的三种基本类型顺序 +： 以确定次序连接两个或多个分量 a+b+c 选择 |， ： 从两个或多个可能的元素中选取一个 a | b | c

7、重复 ： 把指定的分量重复零次或多次 a 可选：一个分量是可有可无的（重复零次或一次）, （a）例子：身份证号 = 区域码 + 出生日期码 + 顺序码 + 校验码 （注：不加大括号）区域码 = 6数字字符6 数字字符=“0”、“1”、“2”、“9”出生日期码 = 年 + 月 + 日 年 = 4数字字符4 月 = “01”、“02”、“03”.“12” 日 = “01”、“02”、“03”.“31”顺序码 = 3数字字符3 = “000”.999”校验码 = 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | X 航班信息文件航空公司名称航班号起点终点日期 起飞时间降

8、落时间航空公司名称2字母4航班号3十进制数字3字母“A”“Z”十进制数字“0”“9”起点终点1汉字10起飞时间降落时间时分时“00”“23”分“00”“59”日期年月日年2000200120022004 月“01”“12”日“01”“31”状态图画法： 状态图是一个状态和事件的网络，侧重于描述每一类对象的动态行为。在状态图中，状态是对某一时刻中属性特征的概括。而状态迁移表示这一类对象在何时对系统内外发生的哪些事件做出何种响应操作是一个伴随状态迁移的瞬时发生的行为，与触发事件一起表示在有关的状态迁移之上。活动则是发生在某个状态中的行为，往往需要一定的时间来完成，因此与状态名一起出现在有关的状态之

9、中。SD模型的组成（P50 P54 五） 数据设计：将分析信息模型转换成数据结构，来自于 实体关系图和数据字典体系结构设计：定义软件的主要结构元素、设计模式及应用约束（子系统的交互）接口设计：描述软件内部、软件和协作系统之间的通信，数据流或控制流的特定行为构件设计：结构元素变换为软件过程的描述，来自于处理说明以及状态变换图数据流图转化为DC图详细设计(过程设计、模块设计) （P68 五）常用的表达工具1、程序流程图 也称为程序框图，程序流程图使用五种基本控制结构是:2、盒图(N-S图)：用方框图代替传统的流程图，五种基本控制结构由五种图形构件表示。3、问题分析图(PAD)4、伪代码和PDL语言

10、 PDL是一种用于描述功能模块的算法设计和加工细节的语言。称为设计程序用语言。它是一种伪码。 伪码的语法规则分为“外语法”和“内语法”。 PDL具有严格的关键字外语法，用于定义控制结构和数据结构，同时它的表示实际操作和条件的内语法可使用自然语言的词汇。5、判定表 判定表用于表示程序的静态逻辑 在判定表中的条件部分给出所有的两分支判断的列表，动作部分给出相应的处理 要求将程序流程图中的多分支判断都改成两分支判断UML九种图（P82 六）图是系统架构在某个侧面的表示，UML提供了两大类静态图和动态图，共计9种不同的图。静态图（Static Diagram）包括用例图、类图、对象图、构建图、部署图。

11、其中用例图描述系统的功能；类图描述系统的静态结构；对象图描述系统在某个时刻的静态结构；构件图描述实现系统的元素的组织；部署图描述系统环境元素的配置。动态图（Dynamic Diagram）包括状态图、时序图、协作图和活动图。其中状态图描述系统元素的状态条件和响应；时序图按时间顺序描述系统元素间的交互；协作图按照时间和空间的顺序描述系统元素间的交互和关系；活动图描述系统元素的活动。用例图的符号和画法（P85 六） -？优化用例图借角色与角色、用例与用例之间的关系（）-？类与类之间的关系（P87）关联关系：关联表示两个类之间存在的某种语义上的联系，即与改关联连接的类在对象之间的语义连接（称为链接）

12、。聚集关系：聚集是一种特殊形式的关联。一般表示类之间具有整体与部分的关系，还有一种特殊聚集称为组合关系。在UML中，聚集表示为空心菱形，组合表示为实心菱形。泛化：泛化也成为继承。依赖：假设有两个元素X、Y，如果修改X的定义可能会引起对Y的定义的修改，则称元素Y依赖于元素X。约束与派生：约束包含或关联、有序关联等，继承也分为多重、不相干、完全和不完全等约束，派生则用于描述某种事物的产生规则。状态图（即状态变迁图）（P93 PPT） -？需求分析的任务（P108 三）准确地定义未来系统的目标，确定为了满足用户的需求系统必须做什么。用 规范的形式准确地表达用户的需求。让用户和开发者共同明确将要开发的

13、是一个什么样的系统（做什么：What）。具体而言,两个任务：建立分析模型；编写需求说明。需求分析的任务就是借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系统的 “做什么” 的问题。需求分析的步骤：需求获取、需求提炼：分析建模、需求描述：编写、需求验证面向对象分析模型（P139） 使用实例，处于OOA模型核心的是“使用实例”（Use Case ），简称“用例”。获得软件的需求后，软件分析员既可据此创建一组“场景”（Scenario），每个场景包含一个使用实例。从这些用例出发，进一步抽取和定义OOA模型的3种模型，即 类-对象模型，描述系统所涉及的全部类-对象，每个类-对象都通过属性、操

14、作和写作者来进行进一步描述； 对象-关系模型，描述对象之间的静态关系，同时定义了系统中所有重要的消息路径，它也可以具体化到对象的属性、操作和协作者； 对象-行为模型，描述了系统的动态行为，即对湘杂特定的状态下如何反映外界的事件。图模型 -？识别和确定分析类（P141）分析类的类型来源：用例规约角度：系统与角色的边界；系统使用的信息；系统的控制逻辑。 在面向对象的分析中，类代表了一组对象所共同拥有的属性和行为。在分析识别类中，根据分析角度的不同，将分析类划分为边界类、实体类和控制类。边界类：表示参与者与系统之间的交互；实体类：表示系统存储和管理的永久信息；控制类：表示系统在运行过程中的业务控制逻

15、辑。这种划分的基本思想是将对象在系统中所承担的行为按照其作用和变化影响程度进行分类，将变化对系统结构的影响限制在一个相对明确的范围内。 查找分析类 查找分析类通常以每一个用例作为一个研究对象； 为每个用例设置一个控制类。时序图的画法（P144）以时间顺序显示对象交互的图，它显示了参与交互的对象和所交换消息的顺序。由于对象生存期的引入，时序图具有时间顺序的概念，从而可以清晰地表示对象在其生存期的某一时刻的动态行为。 形成时序图时，首先把参加交互的对象放在图的上方，沿X轴方向排列，通常把发起交互的对象放在左边，较下级对象依次放在右边，把这些对象发送和接收的消息沿Y轴方向按时间顺序从上到下放置，这样

16、就提供了控制流随时间推移的清晰的可视化轨迹。 模块独立性（P168）模块独立性概括了吧软件划分为模块时要遵守的准则，也是判断模块构造是否合理的标准，坚持模块的独立性，一般认为是获得良好设计的关键。 独立性可以从两个方向来度量，即模块本身的内聚和模块之间的耦合。前者指模块内部各个成分之间的联系，所以也称为模块内联系或模块强度；后者指一个模块与其他模块间的联系，所以又称为块间联系。模块的独立性愈高，则块内联系越强，块间联系越弱。以下是七种内聚和耦合：1、内聚：内聚是从功能的角度对模块内部聚合能力的量度，按照由弱变强的顺序：偶然内聚逻辑性内聚实践性内聚过程性内聚通信性内聚顺序性内聚功能性内聚低内聚模

17、块偶然性内聚：块内个组成成分在功能上是互不相关的，这类模块内部成分的组合纯属偶然。逻辑性模块：通常由若干个逻辑功能相似的成分组成。时间性模块：这类模块所包含的成分，是由相同的执行时间而联系在一起的。中内聚模块过程性模块：当模块中包含的一组任务必须按照某一特定的次序执行，就称为过程性模块通信行模块：模块内部的各个成分都使用同一种输入数据，或者产生同一个输出数据，靠公用数据联系在一起，故称为通信性内聚。高内聚模块顺序性模块：模块中各组成部分是顺序执行的，上一个处理框的输出就是下一个处理框的输入功能性模块：所有的成分结合在一起，用于完成一个单一的功能。（内联系最强）2、耦合耦合是对软件内部块间联系的

18、度量模块1和2为同级模块，相互之间没有信息传递，属于非直接耦合。模块3 、4都是1的下属模块，可通过参数表与他们交换数据，如果交换的是简单变量，便构成数据耦合；如果交换的是数据结构，便构成特征耦合。控制耦合是中等强度的耦合。此时在模块之间传递的信息不是一般的数据，而是用作控制信号的开关值或标质量。控制，模块必须知道被控制模块的内部逻辑，从而增强了模块之间的相互依赖。若允许一组模块访问同一个全局变量，可称它们为外部耦合；若允许一组模块访问同一个全局性的数据结构，称之为共公耦合。 如果一个模块可以直接调用另一个模块中的数据，或者允许一个模块直接转移到另一个模块中去，就称它们之间的耦合为内容耦合。面

19、向对象设计模型（P172 六）设计模型定义成了一个金字塔层次结构。自低而上分别为：子系统层：包含每个子系统的表示类和对象层：包含类层次和每个对象的设计表示消息层：包含使得每个对象能够和其协作者通信的细节，建立 系统的外部和内部接口责任层：包含针对每个对象的所有属性和操作的数据结构和算法的设计系统架构设计（P174）软件系统架构是指系统主要组成元素的组织或结构，以及其他全国行决策，组成元素之间通过接口进行交互。系统架构包含关于软件系统组织的许多决定，该层次的设计工作包含以下6个方面的活动：1、系统高层结构设计。一个软件的设计模型通常是分层组织的，系统架构师需要根绝软件需求模型和分析模型，套用软件

20、架构模型来设计软件系统的高层组织结构。2、确定设计元素。主要包括识别和确定设计类和子系统，将设计类组织到相应的包含中，为了子系统设计接口，确定复用机会等。3、确定任务管理策略。对于规模较大的复杂软件系统，考虑解决由于多用户、并发执行任务等可能引起的冲突或者运行性能等问题的策略。4、实现分布式机制。当一个软件的不同组成构建位于不同服务器上时，选择支持远程通信的构建，给出如何实现这些构建之间通信的统一方案。5、设计数据存储方案。根据实际数据库管理系统的类型，选择数据库访问的支持构件，设计类/对象数据的存储、读取、删除或修改等操作的方法。6、人机界面设计。考虑人机界面的统一要求和规范，确定实现的技术基础和工具等。 系统架构设计是针对整个系统的，其设计结果将影响整个系统，软件设计人员在设计系统中的每个设计元素以及他们之间的交互时都必须遵循系统架构设计文档。