现代软件工程复习要点

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

第一章
软件是什么?
1、软件是指在执行时提供所需的功能和性能的指令(计算机程序)instructions。

2、软件是使程序能够充分处理信息的数据结构data structures。

3、软件是描述程序操作和使用的描述性信息descriptive imformation。

为什么说软件是双重角色dual roles?
1、软件是一种产品。

能提供计算潜在的生产、管理、获取、修改、显示或传递信息。

2、软件是交付产品的工具。

能够实现计算机的控制(如操作系统)、信息的传播(如网络
软件)和其他程序的创建和控制(如软件工具和环境)。

软件的失败曲线
软件不会损坏,所谓的软件“坏了”指
1、出现了Bug。

2、软件的环境变了。

3、软件不能满足新的需求了。

软件和硬件的区别:
1、软件是设计开发的,不是传统意义上的生产制造的。

2、软件不会“磨损”
3、虽然整个工业向着基于构件模式发展,然而大多数软件仍是根据顾客需求定制的。

为什么软件必须改变(上图的change)
1、软件必须适应新的计算机环境或者技术的需要。

2、必须增强软件来实现新的业务需求。

3、软件必须扩展,来实现与其他更现代的系统或数据库的互操作。

4、软件必须重新架构,使其在网络环境中可运行。

软件的种类:系统软件,应用软件,工程/科学软件,嵌入式软件,产品线软件,网络/手机应用程序),人工智能软件(机器人、神经网络、游戏)。

云计算为网络计算设备提供分布式数据存储和处理资源。

计算资源驻留在云之外,并且可以访问云中的各种资源。

产品线软件是一组软件密集型系统,具有共同的特点,满足特定市场的需求。

软件产品线共享一组资产,包括需求、体系结构、设计模式、可重用组件、测试用例和其他工作产品。

Webapp的特点
1、网络密集性。

大量用户可以一次访问webapp
2、不可预测的负载。

网络应用的用户数量可能会因每天的数量级而变化。

3、性能。

用户等待时间太长,可能会取消访问。

4、可用性。

5、数据驱动的。

6、内容敏感。

内容的质量和审美性是重要决定因素。

7、持续的进化。

8、即时性。

9、安全性。

10、美学。

第二章
CMMI capability maturity model integration能力成熟度模型集成
PSP personal software process 个人软件过程
TSP team software process 团队软件过程
IEEE 给出的定义软件工程的定义:
1、将系统化、规范的、可量化的方法应用于软件的开发、运行和维护,即将工程化方法应
用于软件。

2、在1中所述方法的研究。

软件工程是一种层次化的技术。

软件工程的根基在于质量关注点quality focus。

软件工程的基础是过程process。

过程:活动的集合,行动,和任务执行时要创建一些工作产品软件工程方法method为建造软件提供了技术上的解决方法(“如何做”)。

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

工具集成起来称为计算机辅助软件工程(computer-aided software engineering)
自上而下软件工程的层次是:工具、方法、过程、质量关注点。

通用过程框架(generic process framework):
1、沟通communication
2、策划planning
3、建模modeling 包括需求分析analysis of requirements和设计design
4、构建construction 包括编码code generation和测试testing
5、部署deployment
软件保护活动umbrella activities:
1、软件项目跟踪和控制
2、风险管理
3、软件质量保证
4、正式技术评审
5、测量
6、软件配置管理
7、可复用管理
8、工作产品的准备和生产
过程模式定义:
过程模式提供了一个模板——一种描述软件过程中重要特征的一致性方法。

通过过程模式,软件团队可以定义能最好满足项目需求的开发过程。

过程模式process model的模板:
1、模式名称。

模式名称应该清楚表达该模式在软件过程中的的功能。

2、目的。

简介描述模式目的。

3、类型。

定义模式类型。

4、启动条件。

模式应用的前提条件。

5、问题。

模式将要解决的问题。

6、解决方法。

描述模式的实现。

7、结束条件。

模式成功执行后的结果。

8、相关模式。

9、已知应用实例。

过程评估process evaluation模板:
1、启动initiating
2、诊断diagnosing
3、建立establishing
4、执行acting
5、学习learning
PSP个人软件过程模板:
1、策划
2、高层设计。

3、高层设计评审。

4、开发。

5、后验。

解决问题步骤:
1、理解问题。

2、计划解决方案。

3、执行。

4、测试结果正确性。

第三章
过程模型种类:
1、惯例过程模型。

2、瀑布模型。

3、增量过程模型。

4、演化过程模型。

5、专用过程模型。

惯例过程模型提供了一个过程框架,由对应于软件工程动作的明确的任务集组成。

瀑布模型。

又称经典生命周期。

沟通->策划->建模->构建->部署
出现问题:1、实际项目很少严格遵守这个顺序。

2、客户通常难以清楚地描述所有需求。

而瀑布模型要求客户明确需求。

3、客户必须有耐心,只有在项目接近尾声的时候,他们才能得到可执行程序。

增量过程模型
1、增量模型
增量模型以迭代的方式运用瀑布模型。

第一个增量往往是核心产品。

增量模型侧重于每个增量都提交一个可以操作的增量。

优点:1/可以规避技术风险。

2/可以保证部分功能按时交付给最终客户,不至于造成过分的延期。

2、RAD模型
RAD rapid application development 快速应用程序开发,是一种侧重于短暂的开发周期的增量软件过程模型。

通过基于构件的构建方法实现快速开发。

能使开发团队在非常短的时间内创造出“全功能系统”。

RAD模型建模部分包括三个主要阶段:业务建模、数据建模、过程建模。

不足之处:1/需要大量人力资源。

2/如果开发者和客户没有为短时间急速完成整个系统做好准备,RAD项目将会失败。

3/如果系统不能很好地模块化,RAD构件建立会有很多问题。

4/如果系统需求是高性能,并且需要通过调整构建接口的方式来提高性能,不能采用RAD模型。

5/技术风险很高的情况下,不宜采用RAD。

演化过程模型
演化模型是迭代的过程模型。

1、原型开发模型0otyping model
优点:客户对实际的系统有了直观的认识,开发者也迅速建立了一些东西。

缺点:1/客户看到了软件的工作版本,但不知道整个软件是粗糙的。

2/开发者为了使一个原型快速运行起来,往往在实现过程中采用折衷的手段。

2、螺旋模型spiral model
优点:1/采用循环的方式逐步加深系统定义和实现的深度,同时降低风险。

2/确定一系列里程碑,确保共利益者都支持可行和令人满意的系统解决方案。

螺旋模型是开发大型系统和软件的理想方法。

开发者可以在产品演进的任何阶段使用原型开发方法。

3、协同开发模型concurrent development model
专用过程模型
1、形式化方法模型
2、面向方面的软件开发
统一过程unified process UP
UP的起始,包括客户沟通和策划活动
UP的细化,包括用户沟通和通用过程模型的建模活动
UP的构建,与软件过程中构建活动一致
UP的转换
UP的生产,与通用过程的部署活动一致
五个UP阶段并不是顺序进行,而是阶段性并发进行。

第四章
Agile development 敏捷开发
敏捷的含义:1/有效地响应变化。

2/所有利益相关者之间的有效沟通。

3/将客户吸引到团队。

4/项目计划必须是灵活的。

5/快速、增量地交付软件。

敏捷过程必须具有自适应性。

应使用增量式开发策略,必须在很短的时间间隔内交付软件增量来适应不可预测的变化的步伐。

敏捷开发中的人的因素human factors
1、基本能力。

2、共同目标
3、精诚合作
4、决策能力
5、模糊问题解决能力
6、相互信任和尊重
7、自我组织。

包括三点:a、组织自身完成工作。

b、团队组织最能适应当前环境的过
程。

C、团队组织最好的进度安排以完成软件增量交付
极限编程extreme programming XP
XP的关键活动:
1、策划。

策划活动开始于建立一些列描述待开发软件必要特征与功能的“故事”。

2、设计。

XP设计严格遵循KIS keep it simple 保持简洁原则。

XP鼓励重构。

重构定义:是以不改变代码外部行为而改进内部结构的方式来修改软件系统的过程。

3、编码。

4、测试。

第七章
RE requirement engineering需求工程。

需求工程定义:
需求工程和其他软件工程活动类似,必须适应过程、项目、产品和工作人员的要求。

从软件过程的角度来看,需求工程是一个软件工程动作,开始与沟通并持续到建模。

需求工程过程通过执行七个不同的活动来完成:
1、起始。

Inception
2、导出。

Elicitation
3、精化。

Elaboration
4、协商。

Negotiation
5、规格说明。

Specification
6、确认。

Validation
7、管理。

Management
1、起始
A、建立基本的理解
B、识别利益相关者stakeholders
C、识别多种观点
D、协同合作
2、导出
A、会议讨论
B、QFD质量功能部署普通需求、期望需求、令人兴奋的需求
C、用例场景
用例图
3、精化
精化的最终结果是形成一个分析模型,该模型定义了问题的信息域、功能域和行为域。

数据流图data flow diagram
活动图activity diagram
分析模型的元素:
A、基于场景的元素
B、基于类的元素
C、行为元素
D、面向信息流的元素
4、协商
A、识别每个利益相关者,这些相关者参与协商
B、确定每个利益相关者的赢得条件
C、谈判
5、规格说明
规格说明是需求工程师完成的最终工作产品,它将作为软件工程师后续活动的基础。

6、确认
A、对需求工程的工作产品进行质量评估
B、检查不一致、遗漏、错误的规格说明
C、正式技术评审是最主要的需求确认机制
7、需求管理
帮助项目团队识别、控制和跟踪需求并更改需求。

软件配置管理SCM
第八章
分析模型必须实现三个目标:
1、描述客户需要什么
2、为软件设计奠定基础
3、定义在软件完成后可以被确认的一组需求
分析的经验原则:
1、模型应关注在问题域或业务域内可见的需求,抽象的级别应该相对高一些。

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

3、关于基础结构和其他非功能的模型应推延到设计阶段再考虑
4、最小化整个系统内的关联
5、确认分析模型为所有共利益者都带来价值
6、尽可能保持模型简洁
分析建模的方法:
1、结构化分析。

一种考虑数据和处理的分析建模方法,其中数据作为独立实体转换。

2、面向对象分析。

该方法关注于定义类和影响客户需求的类之间的协作方式。

★★★分析模型的元素
1、基于场景的元素
A、用例文本
B、用例图
C、活动图
D、泳道图
2、面向信息流的元素
A、数据流图
B、控制流图
C、处理说明
3、基于类的元素
A、类图
B、分析包
C、CRC模型
D、协作图
4、行为元素
A、状态图
B、顺序图
分析建模通常开始于数据建模
数据对象是几乎任何必须被软件理解的复合信息的表示。

ERD实体/关系图
面向对象的分析
1、在客户和软件工程师之间必须对基本的用户需求进行交流
2、必须确定类(也就是说,定义属性和方法)
3、定义类的层次结构
4、表现对象与对象的关系(对象连接)
5、必须为对象行为建模
6、上述1-5的工作步骤重复迭代直至模型完成
PSPEC 处理规格说明
CRC建模class-responsibility-collaborator类-职责-协作者
行为模型显示了软件如何响应外部事件或刺激。

要创建模型,分析师必须执行以下步骤:
1、评估所有的用例,以充分理解系统内交互的顺序
2、识别驱动交互序列的事件,并理解这些事件如何与特定对相关联
3、为每个用例创建一个序列
4、为系统构建状态图
5、检查行为模型以验证正确性和一致性。

需求模型描述中最基本的元素是用例。

为webapp需求建模
1、内容分析
2、相互作用分析
3、功能分析
4、配置分析
第九章
设计工程的目标是创作出坚固、适用和赏心悦目的模型或设计表示。

坚固性firmness:一个程序不应该有任何阻碍其功能的错误
适用性commodity:一个程序应该适合它的目的
赏心悦目delight:使用这个程序的体验应该是令人愉悦的
通用框架活动:
1、沟通
2、策划
3、建模需求分析和设计
4、构建编码和测试
5、部署
评价良好设计演化的三个特征:
1、设计必须实现所有包含在分析模型中的明确需求,而且必须满足客户期望的所有隐含需
求。

2、对于那些生成代码的人和那些进行测试以及随后维护软件的人而言,设计必须是可读的,
可理解的指南。

3、设计必须提供软件的全貌,从实现的角度说明数据域功能域和行为域。

FTP正式技术评审
质量属性
FURPS
F 功能性functionality
U易用性usability
R可靠性reliability
P性能performance
S可支持性supportability
设计模式模板design pattern template
模式名称
目的
类别
动机
适用性
结构
参与者
协作
结果
相关的模式
模块化
P184
为什么要信息隐蔽information hiding:
1、减少“副作用”的可能性
2、限制本地设计决策的全球影响
3、强调通过控制接口进行通信
4、不鼓励使用全局数据
5、导致封装——高质量设计的一个属性
6、导致更高质量软件的产生
功能独立
独立性可以使用两条定性的标准评估:内聚性cohesion和耦合性coupling。

内聚性显示了某个模块相关功能的强度;耦合性显示了模块间的相互依赖性。

内聚性是信息隐蔽的自然拓展。

一个内聚的模块执行一个独立的任务,与程序的其他部分只需要很少的交互。

耦合性表明软件结构中多个模块之间的相互连接。

在软件设计中,我们将尽力得到尽可能低的耦合。

一个组织良好的设计类的四个特征:
1、完整性与充分性sufficient
2、原始性primitiveness
3、高内聚性high cohesion
4、低耦合性low coupling
★★★设计模型中的元素
1、数据设计元素data elements
2、体系结构设计元素architectural elements
3、接口设计元素interface elements a、用户界面(UI)b、和其他系统、设备、网络或其他
的信息生产者或使用者的外部接口。

C、各种设计构建之间的内部接口。

4、构件级设计元素component elements
5、部署级设计元素deployment elements
第十章
什么是体系结构:
一个程序和计算系统软件体系结构是指系统的一个或多个结构。

结构中包括软件的构件,构件的外部可见属性以及它们之间的相互关系。

体系结构不是可运行软件。

它能使软件工程师能够:1、分析设计在满足规定需求方面的有效性。

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

3、降低与软件构件相关联的风险。

为什么体系结构这么重要:
1、软件体系结构的表示有助于对计算机系统开发感兴趣的各方(共利益者)开展交流。

2、体系结构突出了早期设计决策。

这些决策对随后的所有软件工程工作有深远影响,同时
对系统作为一个可运行实体的最后成功有重要作用。

3、体系结构“构建了一个相对小的,易于理解的模型,该模型描述了系统如何构成以及其
构件如何一起工作”。

什么是体系结构风格:
每种体系结构风格描述一种系统类别:1、一组构件a set of components完成系统需要的某种功能。

2、一组连接器a set of connectors,它们能使构件间实现“通信、合作和协调”。

3、约束constraints,定义构件如何继承为一个系统。

4、语义模型semantic models,它能使设计者通过分析系统的构成成分的性质来理解系统的整体性质。

体系结构风格简单分类:
1、以数据为中心的体系结构data-centered architectures
2、数据流体系结构data flow architectures
3、调用和返回体系结构call and return architectures
4、面向对象体系结构object-oriented architectures
5、层次体系结构layered architectures
体系结构模式三种特性:
1、并发性concurrency
2、持久性persistence
3、分布性distribution
体系结构设计
1、系统的环境表示
软件架构师用体系结构环境图ACD对软件和外部实体交互方式进行建模
2、定义原始模型
A、结点node
B、探测器detector
C、指示器indicator
D、控制器controller
3、将体系结构精化为构件
4、描述系统实例
ADL体系结构描述语言,为描述软件体系结构提供一套语义和语法。

映射数据流到软件体系结构
1、变换流
信息必须以“外部世界”信息的形式进出软件
2、事务流
事务流通过数据沿某输入路径的移动来呈现其特征,对输入路径将外部信息转换成一个事务。

3、变换映射★
变换映射是一组设计步骤,可以将具有变换流特征的DFD映射为某个特定的体系结构风格。

A、评审基本系统模型。

B、评审和精化软件的数据流图。

C、确定DFD是否含有变换流或事务流特征
D、通过确定输入和输出流的边界,分理处变换中心
E、完成“第一级分解”
F、完成“第二级分解”
G、使用提高软件质量的设计启发式方法,精化第一次迭代得到的体系结构。

P215
4、事务映射
★P222
第十一章
什么是构件:
构件是系统中某一定型化的、可配置的和可替换的部件,该部件封装了实现并暴露一系列接口。

构件有三个重要观点:
1、面向对象的观点object-oriented view
2、传统观点traditional view
传统构件也被称为模块它承担下列三个重要角色之一:a、控制构件。

B、问题域构件。

C、基础设施构件。

3、过程相关的观点process-related view
构件级设计的基本设计原则:
1、开关原则OCP
2、Liskov替换原则LSP
3、依赖倒置原则DIP
4、接口分离原则ISP
5、发布复用等价性原则REP
6、共同封装原则CCP
7、共同复用原则CRP
内聚性
耦合性
最简单的OCL语言语句由四个部分组成:
1、语境context定义了哪些情况语句是正确的。

2、特性property描述语境的一些特征。

3、操作operation用来操纵和限定一个特性。

4、关键字keyword用于说明条件表达式。

PDL程序设计语言
第十二章
界面设计的三条黄金规则:
1、置用户于控制之下
A、以不强迫用户进入不必要的或不希望的动作的方式来定义交互模式
B、提供灵活的交互
C、允许用户交互被中断和撤销
D、当技能级别增长时可以使交互流线化并允许定制交互
E、使用户与内部技术细节隔离开来
F、设计应允许用户与出现在屏幕上的对象直接交互
2、减少用户的记忆负担
A、减少对短期记忆的要求
B、建立有意义的缺省
C、定义直观的快捷方式
D、界面的视觉布局应该基于真实世界的象征
E、以不断进展的方式揭示信息
3、保持界面一致
A、允许用户将当前任务放入有意义的环境中
B、在应用系统家族内保持一致性
C、如果过去的交互模型已经建立起了用户期望,除非有迫不得已的理由,否则不要改
变他。

分析和设计用户界面要考虑四种模型:
1、工程师建立用户模型
2、软件工程师创建设计模型
3、最终用户在脑海里对界面产生的映像,称为用户的心理模型或系统感觉
4、系统的实现着创建现实模型。

要保持四个模型一致
用户界面分析和设计过程包括四个不同的框架活动:
1、用户、任务和环境分析及建模
2、界面设计
3、界面构造(实现)
4、界面确认
界面分析:
1、用户分析
A、用户访谈
B、零售输入
C、市场输入
D、支持输入
2、任务分析和建模
A、用例
B、任务细化
C、对象细化
D、工作流细化
E、层次表示
3、显示内容分析
4、工作环境分析
界面设计步骤:
1、使用界面分析中获得的信息,定义界面对象和行为
2、定义那些导致用户界面状态发生变化的事件(用户动作)。

对这个行为进行建模。

3、描述每一个界面状态,就像最终用户实际看的那样。

4、简要说明用户如何从界面提供的界面信息来解释系统状态。

第十三章
传统软件的测试策略
1、单元测试
2、集成测试
自顶向下集成
自底向上集成
回归测试
冒烟测试
调试策略
三种调试方法:
1、蛮力法
2、回溯法
3、原因排除法
第十五章
软件质量定义:
一种有效的过程,它能创造出一种有用的产品,为生产它的人和使用它的人提供可衡量的价值。

相关文档
最新文档