软件工程主要知识点

试题类型:

一、选择题:10小题,20分。

二、判断题:10小题,20分。

三、简答题:6小题,30分。

四、应用题:2小题,30分。

需要重点掌握的内容:

一、“雨课堂”中第12章小测验;第345章小测验;第678章小测验。

二、重要概念:软件工程、软件过程、需求获取技术、需求分析、软件需求说明书、软件实现、软件测试、UML、用例图、顺序图、面向对象、类、对象、继承、封装、多态、软件维护类型、软件估算方法。

三、一些基本问题:

1、软件工程研究的主要内容。p7

软件工程研究的主要内容有以下四个方面:方法与技术、工具与环境、管理技术、标准与规范。

2、软件产品的生命周期6个阶段。p10

1)可行性研究

2)需求分析

3)软件设计

4)编码

5)软件测试

6)软件维护

3、常见软件开发生命周期模型。1.4

瀑布模型、快速原型模型、增量模型、螺旋模型、喷泉模型、统一过程、敏捷过程与极限编程

4、良好的编程实践主要体现在哪三个方面。

5、敏捷过程的核心价值观有哪些? 16

1)“个体和交互”胜过“过程和工具”

优秀的团队成员是软件开发项目获得成功的最重要因素,但不好的过程和工具也会使最优秀的团队成员无法发挥作用。

团队成员的合作、沟通以及交互能力要比单纯的软件编程能力更为重要。

正确的做法是:受限制利于构建软件开发团队(包括成员和交互方式等),然后再根据需要为团队配置项目环境(包括过程和工具)。

2)“可以使用的软件”胜过“面面俱到的文档”

软件开发的主要目标是向用户提供可以使用的软件而不是文档,但是,完全没有文档的软件也是一种灾难。开发人员应该把主要精力放在创建可使用的软件上面,仅当迫切需要并且具有重大意义时,才进行文档编制工作,而且所编织的内部文档应该尽量简明扼要和主题突出。

3)“客户合作”胜过“合同谈判”

客户通常不可能做到一次性地把他们的需求完整准确地表述在合同中。能够满足客户不断变化的需求的切实可行的途径是:开发团队与客户密切协作。因此,能指导开发团队与客户协同工作的合同才是最好的合同。

4)“响应变化”胜过“遵循计划”

软件开发过程总会有变化,这是客观存在的现实。一个软件过程必须反映现实,因此,软件过程应该有足够的能力及时响应变化。然而没有计划的项目也会因陷入混乱而失败,关键是计划必须有足够的灵活性和可塑性,在形势发生变化时能迅速调整,以适应业务、技术等方面的变化。

在理解上述4个价值观声明时应该注意,声明只不过是对不同因素在保证软件开发成功方面所起作用的大小做了比较,说一个因素更重要并不是说其他因素不重要,更不是说某个因素可以被其他因素替代。

6、如何进行结构化需求分析,其建模方法有哪些?31

数据流图(DFD)实体关系图(ER)控制流图(CFD)状态转换图(STD)

7、结构化分析方法的基本思想。2.3

“分解”和“抽象”

8、什么是抽象?当考虑问题的模块化解法时,你对抽象层次怎么理解?2.3 ??? 3.1.2(不确定,应该是第二个)

2.3 在逐层分解的过程中,起初并不考虑细节性的问题,而是先关注问题最本质的属性,随着分解自顶向下的进行,才会逐渐考虑到越来越具体的细节。这种用最本质的属性表示一个软件系统的方法就是“抽象”

3.1.2人类在认识复杂现象的过程中使用的最强有力的思维工具是抽象。人们在实践中认识到,在现实世界中一定事物、状态或过程之间总存在着某些相似的方面(共性)。把这些相似的方面集中和概括起来,暂时忽略它们之间的差异,这就是抽象。或者说抽象就是抽出事物的本质特性而暂时不考虑它们的细节。

由于人类思维能力的限制,如果每次面临的因素太多,是不可能做出精确思维的。处理复杂系统的唯一有效的方法是用层次的方式构造和分析它。一个复杂的动态系统首先可以用一些高级的抽象概念构造和理解,这些高级概念又可以用一些较低级的概念构造和理解,如此进行下去,直至最低层次的具体元素。

这种层次的思维和解题方式必须反映在定义动态系统的程序结构之中,每级的一个概念将以某种方式对应于程序的一组成分。

当我们考虑对任何问题的模块化解法时,可以提出许多抽象的层次。在抽象的最高层次使用问题环境的语言,以概括的方式叙述问题的解法;在较低抽象层次采用更过程化的方法,把面向问题的术语和面向实现的术语结合起来叙述问题的解法;最后,在最低的抽象层次用可以直接实现的方式叙述问题的解法。

9、为什么说“高内聚、低耦合”的设计有利于提高系统的独立性?3.1.4

高内聚:在软件设计时,应尽量提高模块的内聚程度,使模块内部的各个组成成分都相互关联,使其为了完成一个特定的功能而结合在一起。

低耦合:模块之间的耦合程度越低,相互影响就越小,发生异常后产生连锁反应的概率就越小,

在修改一个模块时,低耦合的系统可以把修改范围尽量控制在最小的范围内,

对一个模块进行维护时,其他模块的内部程序的正常运行不会受到较大的影响

10、人机界面设计的三条“黄金原则”。91

置用户于控制之下、减少用户的记忆负担、保持界面一致

11、为什么软件开发人员不能同时完成测试工作?5.1.1(9)

软件测试的原则包括使开发人员和测试人员分立,即软件的开发工作和测试工作不能由同一部分人来完成。

由于思维的局限性,开发人员很难发现自己的错误,如果由开发人员来完成对软件产品的测试,那么有很多缺陷有可能被忽视。

12、常用的软件测试模型。软件测试的目的是什么?132 129

常用的软件测试模型有V模型、W模型和H模型。

软件测试的目的是为了发现软件产品中存在的软件缺陷,进而保证软件产品的质量

 

13、软件测试应该划分为几个阶段?软件测试各个阶段应重点测试的内容是什么?153

从过程的观点考虑测试,在软件工程环境中的测试过程,实际上是顺序进行的4个步骤的序列。

最开始,着重测试每个单独的模块,以确保它作为一个单元来说功能是正确的,这种测试称为单元测试。单元测试大量使用白盒测试技术,检查模块控制结构中的特定路径,以确保做到完全覆盖并发现最大数量的错误。

接下来,必须把模块装配(即集成)在一起形成完整的软件包,在装配的同时进行测试,因此称为集成测试。集成测试同时解决程序验证和程序构造这两个问题。在集成过程中最常用的是黑盒测试用例设计技术。当然,为了保证覆盖主要的控制路径,也可能使用一定数量的白盒测试。

在软件集成完成之后,还需要进行一系列高级测试。必须测试在需求分析阶段确定下来的确认标准,确认测试是对软件满足所有功能的、行为的和性能需求的最终保证。在确认测试过程中仅使用黑盒测试技术。

系统测试。高级测试的最后一个步骤已经超出了软件工程的范畴,而成为计算机系统工程的一部分。软件一旦经过确认之后,就必须和其他系统元素(如硬件、人员、数据库)结合在一起。系统测试的任务是,验证所有系统元素都能正常配合,从而可以完成整个系统的功能,并能达到预期的性能。

14、面向对象分析的类图,类结构之间的关系?197

类图描述类及类与类之间的静态关系。类图是一种静态模型,它是创建其他UML图的基础。一个系统可以由多张类图来描述,一个类也可以出现在几张类图中。

类图不仅定义软件系统中的类,描述类与类之间的关系,它还表示类的内部结构(类的属性和操作)。类图描述的是一种静态关系,它是从静态角度表示系统的,因此,类图建立的是一种静态模型,它在系统的整个生命周期内都是有效的。类图是构建其他图的基础,没有类图就没有状态图等其他图,也就无法表示系统其他方面的特性。

15UML有哪几部分组成?UML图可以分为五个类别。205 206

UML由视图(view)、图(diagram)、模型元素(model element)、通用机制(general mechanism)等几个部分组成。

(1)视图:为了完整地描述一个系统,往往需要描述该系统的许多方面。用视图可以表示被建模系统的各个方面,也就是说,从不同目的出发可以为系统建立多个模型,这些模型都描述同一个系统,只是描述的角度不同,它们之间具有一致性。

(2)图:图是用来表达一个视图的内容的,通常,一个视图由多张图组成。UML共定义了9种不同的图,把它们有机地结合起来就可以描述系统的所有视图。

(3)模型元素:可以在图中使用的概念(如用例、类、对象、消息和关系),统称为模型元素。模型元素在图中用相应的视图元素(图形符号)表示。一个模型元素可以用在多个不同的图中,不管怎样使用,它总是具有相同的含义和相同的符号表示。

(4)通用机制:UML利用通用机制为图附加一些额外的信息,如可以在“笔记”中书写注释,或用“标签值”说明模型元素的性质等。此外,它还提供扩展机制(如构造型、标签值、约束),使UML能够适应一种特殊方法或满足某些特殊用户的需要。

UML的主要内容可以用下述5类图(共9种图形)来定义。

1.用例图

用例是对系统提供的功能(即系统的具体用法)的描述。用例图(use-case diagram)从用户的角度描述系统功能,并指出各个功能的操作者。用例图定义了系统的功能需求。

2.静态图

静态图(static diagram)描述系统的静态结构,属于这类图的有类图(class diagram)和对象图(object diagram)。类图不仅定义系统中的类,表示类与类之间的关系(如关联、依赖、泛化、细化等关系),也表示类的内部结构(类的属性和操作)。类图描述的是一种静态关系,在系统的整个生命期内都是有效的。

对象图是类图的实例,它使用几乎与类图完全相同的图示符号。两者之间的差别在于,对象图表示的是类的多个对象实例,而不是实际的类。由于对象有生命周期,因此对象图只能在系统的某个时间段内存在。一般说来,对象图没有类图重要,它主要用来帮助对类图的理解,也可用在协作图中,表示一组对象之间的动态协作关系。

3.行为图

行为图(behavior diagram)描述系统的动态行为和组成系统的对象间的交互关系,包括状态图(state diagram)和活动图(activity diagram)两种图形。状态图描述类的对象可能具有的所有状态,以及引起状态变化的事件,状态变化称做状态转换。通常,状态图是对类图的补充。实际使用时,并不需要为每个类都画状态图,仅需要为那些有多个状态,且其行为在不同状态有所不同的类画状态图。

活动图描述为满足用例要求而进行的动作以及动作间的关系。活动图是状态图的一个变种,它是另一种描述交互的方法。

4.交互图

交互图(interactive diagram)描述对象间的交互关系,包括顺序图(sequence diagram)和协作图(collaboration diagram)两种图形。顺序图显示若干个对象间的动态协作关系,它强调对象之间发送消息的先后次序,描述对象之间的交互过程。

协作图与顺序图类似,也描述对象间的动态协作关系。除了显示对象间发送的消息之外,协作图还显示对象及它们之间的关系(称为上下文相关)。由于顺序图和协作图都描述对象间的交互关系,所以建模者可以选择其中一种表示对象间的协作关系:如果需要强调时间和顺序,最好选用顺序图;如果需要强调上下文相关,最好选择协作图。

5.实现图

实现图(implementation diagram)提供关于系统实现方面的信息,构件图(component diagram)和部署图(deployment diagram)属于这类图。构件图描述代码构件的物理结构及各个构件之间的依赖关系。构件可能是源代码、二进制文件或可执行文件。使用构件图有助于分析和理解构件之间的相互影响。

部署图用来定义系统中软件和硬件的物理体系结构。通常,部署图中显示实际的计算机和设备(用节点表示),以及各个节点之间的连接关系,也可以显示连接的类型及构件之间的依赖关系。在节点内部显示可执行的构件和对象,以清晰地表示出哪个软件单元运行在哪个节点上。

16、简述面向对象设计的7条原则?261???? (不确定)

1模块化2抽象3信息隐藏4弱耦合5强内聚6可重用

17、常见的软件体系结构风格?7.7.2

1、提高可重用性2、提高可扩充性3、提高健壮性

18、掌握自动售货机的用例图分析。P206

19、掌握因果图、决策表进行用例设计的方法。P138

20、请画出ATM取款流程场景法分析图,设计每个场景的测试用例。P141

 

  • 1
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值