华南理工大学软件工程复习提纲Word文件下载.docx
- 文档编号:417574
- 上传时间:2023-04-28
- 格式:DOCX
- 页数:23
- 大小:331.67KB
华南理工大学软件工程复习提纲Word文件下载.docx
《华南理工大学软件工程复习提纲Word文件下载.docx》由会员分享,可在线阅读,更多相关《华南理工大学软件工程复习提纲Word文件下载.docx(23页珍藏版)》请在冰点文库上搜索。
根据SRS建立目标软件系统总体结构、设计全局数据库和数据结构,规定设计约束,制定集成测试计划
⑤详细设计:
细化概要设计生成的各个模块,详细描述模块的内部细节(算法、数据结构等),形成可编程的程序模块,制定单元测试计划
⑥程序编码:
根据详细设计规格说明书编写源程序
⑦集成测试:
根据概要设计规格说明书,将经过单元测试的模块逐步进行集成和测试
⑧确认测试:
根据软件需求规格说明书,测试软件系统是否满足用户的需求
⑨运行维护:
对使用后的软件进行维护,包括修正错误,增加功能,搬迁新环境等性能维护。
2.需求分析的定义。
在软件工程中,需求分析指的是在建立一个新的或改变一个现存的电脑系统时描写新系统的目的、范围、定义和功能时所要做的所有的工作。
即确定要计算机“做什么”,要达到什么样的效果。
3.典型的软件开发过程模型的特点(优缺点)及要求,特别是原型法、瀑布模型、螺旋模型、增量和迭代等。
一、瀑布模型
需求分析→系统分析→程序设计→编码→单元测试和集成测试→系统测试→验收测试→运行和维护
(1)要求:
①一个开发阶段必须在另一个开发阶段开始之前完成。
②当客户引发的所有需求都已经过完整性和一致性分析,并形成需求文档之后,开发团队才能够开始进行系统设计活动。
③每一个过程活动都有与其相关联的里程碑和可交付产品。
(2)特点:
优点:
采用规范的结构化方法;
严格规定每个阶段提交的文档;
要求每个阶段交出的产品必须经过验证
缺点:
对如何处理开发中产品和活动的变化没有提供相关指导;
将软件开发视为制造而不是创造;
创造一个产品没有迭代的活动;
需要等待很长的时间
二、原型法
原型法是指在获取一组基本的需求定义后,利用高级软件工具可视化的开发环境,快速地建立一个目标系统的最初版本,并把它交给用户试用、补充和修改,再进行新的版本开发。
反复进行这个过程,直到得出系统的“精确解”,即用户满意为止。
(1)要求(过程)
确定用户的基本需求;
构造初始原形;
运行、评价、修改原形;
形成最终的管理信息系统
(2)特点
符合人们认识事物的规律,系统开发循序渐进,反复修改,减少开发中的风险和不确定性;
开发周期短,成本相对少。
忽略软件的总体质量和长期的可维护性;
开发过程要经过多次反复修改评价,不便于管理;
开发人员易将原型取代系统分析;
缺乏规范化的文档资料
适用范围:
处理过程明确、简单系统;
涉及面窄的小型系统
三、阶段化开发:
增量和迭代
增量开发:
需求文档中指定的系统按功能划分为子系统。
定义发布时首先定义一个小的功能子系统,然后在每一个新的发布中增加新功能。
迭代开发:
一开始就提交一个完整的系统,然后在每一个新的发布中改变每个子系统的功能。
特点:
缩短循环周期,客户可以提前获得一部分系统功能
四、螺旋模型
螺旋模型的每个迭代都围绕4个主要活动:
计划;
确定目标、可选方案及约束;
评估可选方案及风险;
开发与测试
有利于软件重用,重视软件质量;
减少过多测试
风险驱动,需要丰富的风险评估经验;
主要适用于内部开发的大规模软件项目;
随着迭代次数增加,工作量加大,开发成本增加
4.原型法的特点以及分类:
探索型(递增型)原型、实验型(抛弃型)原型和演化型原型。
5.敏捷开发方法和极限编程的特点。
(1)敏捷方法
强调灵活性在快速、有效开发在软件中的作用
相对于过程和工具,更强调个人和交互的价值
更喜欢在生产运行的软件上投入时间,而不是在文档的编写上
注重客户的合作,而不是合同谈判
专注于对变化的反应,而不是创建一个计划而后遵循这个计划
(2)极限编程
具有强沟通、简化设计和迅速反馈等特点,一般只适合于规模小、进度紧、需求不稳定、开发小项目的小团队。
极限编程的核心有4个要点:
交流、简单、反馈和勇气。
第三章计划和项目管理
1.了解项目计划和管理的主要内容和常用方法
(1)项目计划要列出软件开发要做的主要工作和任务清单,要回答“软件工程项目做什么”。
强调可调性创造性分析性响应性,用于协调项目编制、指导项目执行。
(2)项目管理,就是项目的管理者,在有限的资源约束下,运用系统的观点、方法和理论,对项目涉及的全部工作进行有效地管理。
即从项目的投资决策开始到项目结束的全过程进行计划、组织、指挥、协调、控制和评价,以实现项目的目标。
阶段化管理、量化管理和优化管理三个方面。
2.软件可行性研究的内容。
第四章获取需求
1.了解需求的重要性及需求分析阶段的目标及主要产物。
(1)重要性
①需求在软件开发起到了决策的作用,提供了开发的方向,指明了开发策略
②缺少需求或需求错误会导致项目开发失败
(2)目标及产物
①了解客户要求②分析系统的数据要求③需求规格说明书
2.需求工程包括哪些方面?
需求工程包括需求开发和管理,而需求开发又包括:
需求获取,需求分析,需求规格说明和需求验证。
3.需求的类型:
功能需求、非功能需求或质量需求、设计约束、过程约束。
4.两种需求文档:
需求定义文档和需求规格说明书。
5.需求规格说明书的主要内容。
略
6.常用的需求建模表示方法:
ER图、事件跟踪、状态机、Petri网、数据流图、用例图和原型法。
第五章UML部分
1.UML的作用:
是为软件系统的制品进行描述(specifying)、可视化(visualizing)、构造(constructing)、文档化(documenting)的一种语言。
2.UML中的4+1视图:
用例视图,设计视图,进程视图,实现视图,分布视图。
①用例视图:
用来支持软件系统的需求分析,它定义系统的边界,关注的是系统的外部功能的描述。
②逻辑视图(设计+进程):
定义系统的实现逻辑,描述实现用例图描述的功能以及设计软件系统的设计概念。
③实现视图:
描述组成一个软件系统的各个物理部件以各种方式组合起来,构成一个可实际运行的系统。
④分布视图:
描述软件产品在计算机硬件系统和网络上的安装、分发、分布。
3.UML中的三种扩展机制:
构造型Stereotype;
标记值taggedvalue;
约束constraint.
构造型(stereotype):
对UML词汇(建模元素)的扩充,用来描述和已有的UML建模元素类似,但又对特定的问题领域有特殊意义的建模元素。
(类)
标记值(taggedvalue):
对UML建模元素的构成(property)的扩充,用于为此建模元素增加新的规格说明。
(类的属性)
约束(constraint):
约束用来扩充UML建模元素的语义,以便增加新的规则或修改已有的规则(关系)
4.UML中所包含的9种图形及各自的作用。
①类图:
包含类、接口、协同及其关系,用来描述逻辑视图的静态属性。
②对象图:
包含对象及其关系,用来表示类图的类的对象在系统运行过程中某一时刻的状态。
③组件图:
描述系统的物理实现,包括构成软件系统的各部件的组织和关系。
类图里的类在实现时最终会映射到组件图的某个组件。
一个组件可以实现多个类。
④分布图:
描述系统的组件在运行时在运行节点上分布,一个节点可包含一个或多个组件。
⑤用例图:
描述系统的边界和其上的动态行为,包括用例、系统作用者及其之间的关系。
⑥⑦序列图和协作图:
用来描述一组对象之间的动态交互。
⑧⑨状态图和状态机:
用来描述对象的动态特性。
前者强调对象对外部事件的相应及相应的状态变迁,后者描述对象之间控制流的转换和同步机制。
5.用例图的作用。
①用例图用来描述软件需求模型中的系统功能,通过一组用例可以描述软件系统能够给用户提供的功能。
②用例图可以作为整个系统开发过程中的开发依据,指导和驱动其他模型。
6.用例图的主要构成部分。
①参与者②用例③系统边界④关系(箭头)
7.类图的主要作用
类图是描述类、接口以及它们之间关系的图,它显示了系统中各个类的静态结构,是一种静态结构。
8.了解类之间的各种关系:
关联、依赖、继承或泛化、组合&
聚合
①关联:
用来表示两个(或多个)类的对象之间的结构关系,在代码中表现为一个类以属性的形式包含对类的一个或多个对象的引用。
②依赖:
表示一个类以某种形式依赖于其他类。
依赖关系中,其中一个类的改编可能会影响另一个类。
在程序代码中,依赖关系意味着一个类的对象出现在另一个类的操作当中。
常见的有两种情况:
一个类将另一个类的对象作为自己某个操作的参数(形参),或者是操作的局部变量。
③泛化(继承):
定义类和包之间的一般元素和特殊元素之间的分类关系。
④聚合:
表示类之间整体与部分的关系。
聚合意味着一个类拥有但共享另一个类的对象。
⑤组合:
特殊形式的聚合。
一个部分类最多只属于一个整体类,整体类不存在时,部分类将同时销毁。
9.了解类图的基本建模步骤
10.接口和抽象类的定义及各自的特点。
(1)抽象类
抽象类是指那些不具有任何对象的类,其作用是为其他的类描述它们的公共属性和行为。
通常,抽象类具有一组抽象操作。
一个拥有至少一个抽象操作的类必定是一个抽象类。
(2)接口
接口是一组没有实现的操作的集合。
接口只提供操作的声明,不提供任何相应的功能代码。
具体的功能代码由使用该接口的类实现,这叫作实现关系。
①接口只包含操作而不包含属性,并且操作都是公有的(public),不允许使用可见性限定符。
②接口不能自己实现其操作,而是由相应的类来实现。
③接口没有构造函数和析构函数,不能直接被实例化
④一个类可以实现多个接口。
(3)对比
①接口是一个不带实现的类,它只规定类的外部特性,包括公共属性、操作及其语义,因此只有操作声明而没有方法体和物理存储区。
②抽象类和接口很相似,也只定义接口而推迟定义其实现部分,然而抽象类允许增加一些方法的实现。
③语义层面上:
抽象类是一种类是对一组具有相同属性和方法的逻辑上有关系的事物的一种抽象。
而接口则是对一组具有相同属性和方法的逻辑上不相关的事物的一种抽象。
④抽象类中可以有自己的数据成员,也可以有非abstract的成员方法。
而接口中的方法只能有静态的不能被修改的数据成员
⑤抽象类表示的是一种继承关系,一个类只能使用一次继承关系。
但是,一个类却可以实现多个interface。
⑥抽象类中的方法可以有默认行为。
但接口中的方法却不能拥有默认行为。
11.交互图的分类:
顺序图和协作图,各自的优缺点。
UML2.0中协作图改成通信图。
交互图描述一个交互,其中包括了一系列的对象及其关系以及通过这些关系在对象之间传送的消息。
(1)顺序图
强调的是消息发送的时间的先后顺序。
组成部分:
①对象:
序列图中所包含的每个对象用一个对象框(短式)表示,对象名需带下划线。
②生存线:
对象框下画的一条垂直虚线,称为该对象的生存线,表示对象的生存时间。
③激活期:
对象生存线上的一个细长方形框,表示该对象的激活时间段,即活动期间。
④消息:
对象之间消息的发送和接收用两个对象生存线(激活期)之间的消息箭头线。
(2)协作图
强调的是发送和接收消息的对象之间的组织结构。
一个协作图显示了一系列的对象和在这些对象之间的联系以及对象间发送和接收的消息。
构成:
对象;
连接;
在此连接上传递的消息
相同点:
①它们都表现出了对象之间的交互信息。
②两个图对象的绘制方式相同
不同点:
①顺序图反映了对象之间交互的时间关系,而通信图反映了对象之间交互的空间关系。
②顺序图用于展示特定的业务场景,而通信图用来展示详细的业务过程。
③顺序图的对象在图形的顶部一字排开,而通信图对象的摆放位置在二维空间只要选择合适的位置即可。
④通信图不能表现组合片段。
12.状态图和活动图各自的作用。
(注意活动图中泳道的作用)
(1)状态图
状态图描述了一个对象或交互过程在它的生命周期中对一系列外界激励的所呈现出的不同状态以及它相应的响应和活动。
状态图描述交互对对象内部的影响,交互图中的消息在这里变成外部事件对对象发出的命令,对象对这些命令的响应导致对象的状态发生变化。
因此,从这个意义上说,状态图是顺序图的进一步细化,并且是对核心对象(选择核心对象的依据是看是否在多个交互图中有多个消息指向该对象)的细化。
(2)活动图
在UML里,用来为非反应型对象建模的状态机被称为活动图。
活动图是一种特殊形式的状态机,用于对计算流程和工作流程建模。
活动图着重表现活动的控制流,描述在对象之间传递的操作
泳道:
活动图可以用来表达软件对象的比较复杂的动态行为。
这些动态行为
●可能是模拟现实世界的某个机构的各业务部门的运作情况;
●也可能是一个复杂的算法,
●这算法可能需要由软件系统中的多个协同共同实现。
(协同指的是多个类的对象共同工作,以提供单个类的的对象单独工作不能提供的动态行为)
在UML里,对在语义上互相关联的活动状态的子集的划分,是使用泳道(swimlane)实现的。
①泳道是活动图里对其中的活动按照其职责上的关联进行的划分。
泳道在活动图内是一系列的垂直的隔断。
②在活动图里,泳道区分了其中的活动的不同职责。
③在有泳道的活动图中,每一活动都属于且只属于一个泳道。
泳道之间可以有变迁的传递。
泳道从语义上可以理解为是一个模型包。
泳道可以有名字,以区分不同状态集合的职责。
④泳道可以用在为复杂的算法进行建模的活动图上。
这时,一个泳道对应于一个协同,其中的活动可以由一个或多各互相连接的类的对象实现。
⑤带有泳道的活动图也可以在软件开发的需求分析阶段用来为业务部门的业务流程的建模上,这时,泳道可以代表业务流程中的一个业务部门。
13.组件图的作用以及组件与接口间的关系。
组件是一个相对独立的物理块,是系统的一个物理和可替代的组成部分,一般作为一个独立的文件存在。
组件具有确定的借口,相互之间可以调用,组件之间存在依赖关系。
组件图的主要目的是显示系统组件间的结构关系。
组件与接口:
①组件的一个重要特性就是实现了逻辑视图中为软件系统规定的设计词汇的语义,语义除了静态结构之外,即是其规定的动态行为。
从组件外部来看,一个组件区分于另一个组件的的本质特征就是其动态行为。
如果需要强调组件的动态行为,即组件为外部世界提供的服务,就可以使用接口。
②通过将软件系统的划分为不同的可执行组件,可以实现软件系统的组件化。
软件系统在物理上由不同组件构成,有些组件向外部提供由接口规定的服务,有些组件使用这些服务。
③组件化的好处:
组件是可替换的;
边界清晰;
便于维护、升级;
组件化的软件系统可以是分布式的,不要求使所有组件都运行于一个结点
④一个组件实现了一个接口,被一个组件实现的接口是该组件的实现接口。
一个组件使用了另一个组件通过接口提供的服务,被一个组件调用的接口是该组件的输入接口
14.部署图的作用以及节点的分类
(1)部署图(配置图)是用来显示系统中软件和硬件的物理架构。
从部署图中,您可以了解到软件和硬件组件之间的物理关系以及处理节点的组件分布情况。
使用部署图可以显示运行时系统的结构,同时还传达构成应用程序的硬件和软件元素的配置和部署方式。
部署图描述了一个运行时的硬件结点,以及在这些结点上运行的软件组件的静态视图。
部署图显示了系统的硬件,安装在硬件上的软件,以及用于连接异构的机器之间的中间件。
(2)节点
节点是运行时代表计算资源的物理元素。
节点通常有内存及处理能力,它可以是物理设备及运行在该设备上的软件系统。
节点分为处理机和设备
处理机:
能执行软件、具备计算能力的节点,如主机、服务器、客户机等
设备:
没有计算能力的节点,如打印机、传感器、终端等
15.主要的面相对象设计原则及各自的原理:
OCP,LSP,DIP,ISP,CARP,LoD
设计原则名称
简介
里氏替换原则LSP
任意父类可以出现的地方,子类也可以出现
开闭原则OCP
对扩展开发,对修改关闭
单一职责原则SRP
类的职责单一
依赖倒转原则DIP
针对抽象(或接口)编程,而不针对具体编程
接口隔离原则ISP
使用多个专门接口要优于使用单一的接口
组合聚合原则CRP
优先使用组合或聚合关系,不要过于使用继承关系
迪米特原则LoD
一个软件实体对其他实体的引用越少越好
①LSP李氏替换原则:
如果在任何情况下,子类(或子类型)或实现类与基类都是可以互换的,那么继承的使用就是合适的。
为了达到这一目标,子类不能添加任何父类没有的附加约束。
②OCP开闭原则:
软件实体(类、模块、函数等)应该是可扩展的,但是不可修改的。
③SRP单一职责原则:
规定一个类应该只有一个发生变化的原因。
如果一个类承担的职责过多,就等于把这些职责耦合在一起了。
一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。
这种耦合会导致脆弱的设计,当发生变化时,设计会遭受到意想不到的破坏。
而如果想要避免这种现象的发生,就要尽可能的遵守单一职责原则。
此原则的核心就是解耦和增强内聚性。
④ISP接口隔离原则:
客户端不应该依赖它不需要的接口;
一个类对另一个类的依赖应该建立在最小的接口上。
为了避免“肥接口(fatinterface)”,应当以一个类实现多个接口,而各客户仅仅获知必须的接口
⑤DIP依赖倒转原则:
程序要依赖于抽象接口,不要依赖于具体实现。
简单的说就是要求对抽象进行编程,不要对实现进行编程,这样就降低了客户与实现模块间的耦合。
⑥CRP组合复用原则:
继承复用:
实现简单,易于扩展。
破坏系统的封闭性,从基类继承而来的实现是静态的,不能在运行时动态改变,缺乏灵活性(即“白盒”复用)。
组合/聚合复用:
耦合度较低,可以灵活地选择成员对象的操作;
可以在运行时动态改变。
(即“黑盒”复用)
⑦迪米特原则:
指一个软件实体应该尽量少与其他实体发生相互作用。
16.设计模式的内容和分类。
(1)设计模是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。
一个模式有四个基本要素:
模式名称、问题、解决方案、效果
(2)分类
①创建型模式:
抽象的实例化过程,隐藏了对象创建的具体细节,使程序代码不依赖具体的对象。
例:
单例模式、抽象工厂模式、建造者模式、工厂模式、原型模式。
②结构型模式:
描述类和对象之间通过组织形成新的结构,以实现新的功能。
适配器模式、桥接模式、装饰模式、组合模式、外观模式、享元模式、代理模式。
③行为型模式:
描述算法以及对象之间的任务(职责)分配及它们之间的通讯模式。
模版方法模式、命令模式、迭代器模式、观察者模式、中介者模式、备忘录模式、解释器模式、状态模式、策略模式、职责链模式、访问者模式。
17.设计模式与面向对象设计原则之间的关系,特别是OCP原则
设计模式就是实现了面向对象原则,从而达到了代码复用、增加可维护性的目的。
18.了解常见设计模式的设计思想及其原理,了解如何从OCP的角度进行分析
第六章设计系统
1.概念设计和技术设计的内容
①概念设计:
是由分析用户需求到生成概念产品的一系列有序的、可组织的、有目标的设计活动,它表现为一个由粗到精、由模糊到清晰、由抽象到具体的不断进化的过程。
②技术设计:
对主要硬件部分及其功能的描述,确定设计软件构件的层次和功能、数据结构和数据流
2.好的设计的衡量:
内聚和耦合
①内聚是一个模块内部各成分之间相关联程度的度量。
(高内聚)
②耦合是指对象之间的依赖性(低耦合),耦合性是程序结构中各个模块之间相互关联的度量。
它取决于各个模块之间的接口的复杂程度、调用模块的方式以及哪些信息通过接口。
3.常用的内聚和耦合度类型
(1)内聚类型
低→高:
功能内聚、信息内聚、通信内聚、过程内聚、时间内聚、逻辑内聚、偶然内聚
(2)耦合类型
高→低:
内容耦合、公共耦合、外部耦合、控制耦合、标记耦合、数据耦合、非直接耦合
第七章测试
1.测试的目标和衡量标准
目标:
发现错误,只有当发现了错误时,测试才被认为是成功的。
衡量标准:
需求的覆盖率;
缺陷数量;
缺陷重现率;
效率;
重用价值。
2.测试的分类(或组织)。
各种类型的测试的主要任务及所依赖的文档。
①模块、构件、单元测试:
对软件中的最小可测试单元进行检查和验证,目的是检验软件基本组成单位的正确性。
②集成测试:
在单元测试的基础上,将所有模块按照设计要求组装成为子系统,进行集成测试。
目的是检查软件单位之间的接口是否正确。
③功能测试:
对产品的各功能进行验证,根据功能测试用例,逐项测试,根据需求文档检查产品功能完整性。
④性能测试:
检查系统的响应速度,结果精确性和数据的可访问性
⑤验收测试:
指确认系统是否符合设计规格或契约之需求内容的测试
⑥安装测试:
确保该软件在正常情况和异常情况的不同条件下,安装后的正常运行。
3.黑盒测试和白盒测试的思想,了解白盒测试中的基本路径测试等方法。
(1)黑盒测试也称功能测试,它是通过测试来检测每个功能是否都能正常使用。
在测试中,把程序看作一个不能打开的黑盒子,在完全不考虑程序内部结构和内部特性的情况下,在程序接口进行测试,它只检查程序功能是否按照需求规格说明书的规定正常使用,程序是否能适当地接收输入数据而产生正确的输出信息。
黑盒测试着眼于程序外部结构,不考虑内部逻辑结构,主要针对软件界面和软件功能进行测试。
(2)白盒测试又称结构测试,是全面了解程序内部逻辑结构、对所有逻辑路径进行的测试。
"
白盒"
法是穷举路径测试。
在使用这一方案时,测试者必须检查程序的内部结构,从检查程序的逻辑着手,得出测试数据。
(3)基本路径测试
基本路径测试法是在
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 华南理工大学 软件工程 复习 提纲