软件工程整理.docx

上传人:b****5 文档编号:24689030 上传时间:2023-05-31 格式:DOCX 页数:13 大小:34.25KB
下载 相关 举报
软件工程整理.docx_第1页
第1页 / 共13页
软件工程整理.docx_第2页
第2页 / 共13页
软件工程整理.docx_第3页
第3页 / 共13页
软件工程整理.docx_第4页
第4页 / 共13页
软件工程整理.docx_第5页
第5页 / 共13页
点击查看更多>>
下载资源
资源描述

软件工程整理.docx

《软件工程整理.docx》由会员分享,可在线阅读,更多相关《软件工程整理.docx(13页珍藏版)》请在冰豆网上搜索。

软件工程整理.docx

软件工程整理

1.遗留软件:

年代较久,甚至过于久远的软件。

特点:

(1)生命周期长以及业务关键性

(2)质量差

遗留系统发生演化的原因:

(1)软件需要进行适应性调整,从而可以满足新的计算环境或者技术的需求。

(2)软件必须升级以实现新的商业需求。

(3)软件必须扩展以使之具有与更多新的系统和数据库的互操作能力。

(4)软件架构必须进行改建以使之能适应不断演化的计算环境。

2.软件工程设计

软件设计在软件工程中属于核心技术,并且它的应用与所使用的软件工程模型无关。

必需的四种设计模型:

(1)数据设计或类设计将类模型转化为设计类的实现以及软件实现所要求的数据结构。

(2)体系结构设计定义了软件的主要结构化元素之间的关系,可满足系统需求的体系结构风格和模式以及影响体系结构实现方式的约束。

(3)接口设计描述了软件和协作系统之间,软件和使用人员之间是如何通信的。

(4)构建级设计将软件体系结构的结构化元素变换为对软件构件的过程性描述。

3.需求获取的起始阶段要解决的问题:

1)应能适当地调整收集范围。

在收集需求信息的开始,开发人员并不知道用户需求信息量的大小,可以根据系统的范围适当扩大收集范围。

但也不能过于扩大收集范围,因为在扩大的范围内收集的需求信息有些可能不是真正的需求,这将导致开发人员要花费大量的精力和时间来理解和分析这些需求信息。

显然,收集的范围也不能太小,否则有些重要需求会被遗漏或排除在外。

2)尽量把用户所持的假设解释清楚,特别是发生冲突的部分。

这就需要根据用户所讲的话或提供的文字去理解,以明确用户没有表达清楚的、但又想加入的需求信息。

3)尽量理解用户用于表达他们需求的思维过程,特别是尽量熟悉和掌握用户具有的一些专业知识和术语。

4)在收集需求信息时,应尽量避免受不熟悉细节的影响,如一些表格的具体设计等,这些可作为需求先记录下来,然后再由设计工作去完成。

4.体系结构模型的三个来源:

构件、连接件和配置

5.面向对象多态机制的三个必要条件:

1)要有继承

2)要有重写

3)父类的应用指向子类的对象(向上转型)

6.单元测试,回归测试,冒烟测试,白盒测试:

单元测试侧重于软件设计的最小单元(软件构件或模块)的验证工作。

在单元测试期间,选择测试的执行路径是最基本的任务。

测试用例的设计目的旨在发现因错误计算、不正确的比较或不适当的控制流而引起的错误。

回归测试重新执行已测试过的某些子集,以确保变更没有传播不期望的副作用。

无论什么时候修正软件,软件配置的某些方面(程序、文档或支持数据)也发生变更。

回归测试的好处:

有助于保证变更(由于测试或其他原因)不引入无意识行为或额外的错误。

回归测试方法:

可以手工进行,重新执行所有测试用例的子集,或者利用捕捉/回放工具自动进行。

冒烟测试可以理解为该种测试耗时短,仅用一袋烟功夫足够了。

类比新电路板基本功能检查。

测试对象是每一个新编译的需要正式测试的软件版本,目的是确认软件基本功能正常,可以进行后续的正式测试工作。

白盒测试也被称为玻璃盒测试或结构化测试,一种测试用例设计方法,利用作为构件级设计的一部分所描述的控制结构来生成测试用例。

测试方法:

1)基本路径测试

2)控制结构测试

7.软件过程的框架

过程框架为实现完整的软件工程建立了基础,一个通用的软件工程过程框架包含。

沟通:

与客户和其它共利益者沟通和协作。

策划:

为后续的软件工程工作制定计划。

建模:

包括创建模型和设计。

构建:

编码和测试。

部署:

交付用户、测评及反馈。

8、耦合

耦合是类之间彼此联系程度的一种定性度量,随着类之间的相互依赖越来越多,类之间的耦合程度也会增加,在构件级设计中一个重要目标就是保持低耦合。

9、重构

重构是使用这样一种方式改变软件系统的过程:

不改变代码[设计]的外部行为而是改进其内部结构。

10、软件工程是什么

1.将系统化,规范化,可量化的方法应用于软件的开发,运行和维护,即将工程化方法应用于软件。

2.对系统化,规范化,可量化的方法进行研究。

11、内聚

传统观点:

模块的专一性

面向对象系统构件设计观点:

内聚性意味着构件或者类只封装那些相互关联密切,以及与构件或类自身有密切关系的属性和操作。

内聚分类

功能的通过操作来表现

分层的由包、构件和类来表现

通信的访问相同数据的操作定义在一个类中

12、设计模式

设计模式描述了在某个特定场景中解决某个特定问题的设计结构。

13、回归测试、阿尔法测试、贝塔测试

回归测试

回归测试是指修改了旧代码后,重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。

回归测试作为软件生命周期的一个组成部分,在整个软件测试过程中占有很大的工作量比重。

阿尔法测试

由有代表性的用户在开发者场所进行,软件在自然设置下使用,开发者站在用户后面观看,并记录错误和使用问题,阿尔法测试在受控环境下进行。

贝塔测试

在一个或多个最终用户场所进行,开发者通常不在场,在不为开发者控制的环境下现场应用软件,最终用户记录测试过程中遇见的所有问题(现实存在或想象),并定期报告给开发者。

14.开闭原则p180

开闭原则(OCP)。

“模块[构件]应该对外延具有开放性,对修改具有封闭性”。

15.分析模型p88p96

分析模型的作用是为基于计算机的系统提供必要的信息、功能和行为域的说明

分析模型的元素:

基于场景的元素、基于类的元素、行为元素。

分析模型必须建立的三个目标:

(1)描述客户需要什么;

(2)为软件设计奠定基础;

(3)定义的一组需求在软件完成后可以被确认

创建分析模型应该遵循的经验原则:

1.模型应关注在问题域或业务域内可见的需求,抽象的级别应该相对高一些。

2.需求模型的每个元素都应能增加对软件需求的整体理解,并提出对信息域、功能和系统行为的深入理解。

3.关于基础结构和其他非功能的模型应推延到设计阶段再考虑。

4.最小化整个系统内的关联。

5.确认需求模型为所有利益相关者都带来价值。

6.尽可能保持模型简洁。

16、crc卡片分析类的建模活动p113

CRC模型实际上是表示类的标准索引卡的集合。

类的类型:

实体类也称作模型或业务类,是从问题说明中直接提取出来的(例如FloorPlan和Senor)。

边界类用于创建用户可见的和在使用软件时交互的接口(如交互屏幕或打印的报表)。

控制类自始至终管理“工作单元”

17螺旋模型、增量模型、瀑布模型、协同模型p31p32p35

瀑布模型:

又称经典生命周期,它提出一个系统的顺序的软件开发方法,从用户需求规格说明开始,通过策划、建模、构建和部署的过程,最终提供完整的软件支持。

瀑布模型的一个变体称为V模型

优点:

是软件工程最早的范例。

消除非结构化软件。

   降低软件的复杂度,促进软件开发工程化

出现的问题:

实际的项目大部分情况难以按照该模型给出的顺序进行。

      经常情况下客户难以表达真正的需求。

      客户要等到开发周期的晚期才能看到程序运行的测试版本。

      可能会产生“堵塞状况”

总结:

对当前软件工作往往并不合适。

   当需求确定,工作能够线性方式完成时,可以采用

增量模型:

增量模型以迭代方式运用瀑布模型;

     在每个阶段运用的序列都是线性的;

     每个线性序列生产出一个软件的可交付增量;

     运用增量模型的时候,第一个增量往往是核心产品

应用情况:

(1)在期限之前没有足够的开发人员;

(2)需要规避技术风险的项目;

螺旋模型:

一种演进式的软件过程模型

     结合了原型的迭代性质和瀑布模型的系统性和可控性特点

     具有迅速开发,逐步完善软件版本的潜力

显著特点:

1.采用循环的方式逐步加深系统定义和实现的深度,同时降低风险;

     2.确定一系列里程碑作为支撑点,确保共利益者都支持可行的和令人满意的系统解决方案; 

优点:

 

1.这种模型适合于大型系统的开发,应该说它对于具有高度高风险的大型复杂软件系统的开发是最为实际有效的方法。

    2.沿螺线自内向外每旋转一圈便开发出更为完善的一个新的软件版本。

    3.永远保持可操作性,直至软件产品周期结束。

   4.过程经常处于休止状态,但每当有变更时,过程总能在合适的入口启动(如产品升级)。

协同模型:

 

   特点:

1.提供精确的项目当前状态图;

     2.不是把软件工程活动、动作和任务局限在一个时间序列,而是定义活动状态网络;

     3.过程网络中某点产生的事件可以触发状态的转换

18、软件工程的层次化技术和软件工程的5个框架活动p11

5个过程框架活动:

沟通:

与客户和其它共利益者沟通和协作。

         策划:

为后续的软件工程工作制定计划。

         建模:

包括创建模型和设计。

         构建:

编码和测试。

         部署:

交付用户、测评及反馈。

层次化技术:

      

   其根基在于质量关注点

   基础是过程层,定义一个框架。

   方法层为建造软件提供技术上的解决方法。

   工具层为过程和方法提供自动化或半自动化的支持。

19、敏捷软件开发和敏捷宣言p45

敏捷宣言:

个人和这些人之间的交流胜过了开发过程和工具

     可运行的软件胜过了宽泛的文档

     客户合作胜过了合同谈判

     对变更的良好响应胜过了按部就班地遵循计划

什么是敏捷:

有效的(快速并适应)响应变更

      所有利益相关者中的有效沟通

      吸引客户到团队

      组织团队使其控制工作执行

      快速、增量交付的软件

 敏捷要求:

     每个人是敏捷的

     团队是敏捷的 

使用最广泛的敏捷过程:

极限编程(XP)

极限编程(XP)的四个过程:

策划、设计、编码、测试。

20体系结构并非可运行的软件。

他是一种表达使你能够:

(1)在满足既定的需求方面下,分析设计有效性;

(2)在设计变更相对容易的阶段,考虑体系结构可能的选择方案;

(3)降低与软件构造相关的风险

21.描述软件体系结构风格的基本要素

每种风格描述一种系统类别,包括:

(1)完成系统需要的某种功能的一组构件(例如,数据库、计算模块);

(2)能使构件间实现“通信、合作和协调”的一组连接件;

(3)定义构件如何集成为系统的约束;

(4)语义模型,能使设计者通过分析系统组成成分的已知属性来理解系统的整体性质。

体系结构风格的简单分类:

(1)以数据为中心的体系结构

(2)数据流体系结构

(3)调用和返回体系结构

(4)面向对象体系结构

(5)层次体系结构

22软件测试的主要步骤及主要任务

主要步骤:

(1)测试计划

(2)测试用例设计

(3)测试执行

(4)测试结果数据的收集与评估

主要任务:

通过科学的、可靠的、有效的测试方法及技术找出软件中存在的缺陷,

23普适性活动:

(1)软件项目跟踪和控制

(2)风险管理

(3)软件质量保证

(4)技术评审

(5)测量

(6)软件配置管理

(7)可复用管理

(8)工作产品的准备和生产

24需求分析的主要内容:

(1)产生软件工作特征的规格说明

(2)指明软件和其他系统元素的接口

(3)规定软件必须满足的约束

25需求规格说明书的内容(p75信息栏)

规格说明—是下面的一个(或者多个):

一份写好的文档

一套模型

一个形式化的数学模型

一组使用场景(使用案例)

一个原型

26用户界面设计的原则P198

1.把控制权交给用户

2.减轻用户的记忆负担

3.保持界面一致

27软件配置管理的主要活动P312

1.对象标识

2.变更控制

3.版本控制

4.影响管理

5.配置审核

6.报告

28开源软件和非开源软件及其质量优势和劣势是什么

开源软件:

可以被公众使用的软件,并且此软件的使用,修改和分发也不受许可证的限制。

非开源软件:

则是不能随意进行更改的,一般是属于保密的,只有公司的开发者才能进行更改。

开源软件的优势

1、成本低

2、无须繁琐的认证许可

3、使用自由

开源软件的劣势

1、技术支持差

2、使用文档弱

2、安全性低

3、维护费用高

非开源软件的优势

1.单一供应商

2.企业级产品

3.专业接口

4.安全性高

非开源软件的劣势

1.产品臃肿

2.需要额外的费用

3.供应商锁定

4.用其他软件替换要付出很多代价

 

29开源软件对传统行业的影响

开源给传统行业带来挑战和发展

挑战:

开源软件推动一些企业快速发展,对传统行业产生巨大竞争。

机遇:

传统企业可以利用开源软件树立品牌形象,扩大影响范围,开源还可以作为公司的战略武器。

最好的例子就是谷歌的Android。

30

控制耦合:

当操作A调用操作B,并且向B传递了一个控制标记。

标记耦合:

类B被声明为类A某一操作中的一个参数类型。

数据耦合:

操作需要传递较长的数据参数时。

导入耦合:

如果两个模块之间没有直接关系,它们之间的联系完全是通过主模块的控制和调用来实现的,这就是非直接耦合。

这种耦合的模块独立性最强。

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 医药卫生 > 药学

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1