软件工程复习要点Word文档格式.docx
- 文档编号:22270710
- 上传时间:2023-02-03
- 格式:DOCX
- 页数:33
- 大小:33.23KB
软件工程复习要点Word文档格式.docx
《软件工程复习要点Word文档格式.docx》由会员分享,可在线阅读,更多相关《软件工程复习要点Word文档格式.docx(33页珍藏版)》请在冰豆网上搜索。
并行过程流:
建模连边
(以上内容详见图)
惯用模型
增量模型(图见P32)
适用情形:
初始的软件需求明确,但是整个开发过程却不宜单纯运用线性模型。
同时,可能迫切需要为用户迅速提供一套功能有限的软件产品,然后在后续版本中再进行细化和扩展功能。
特点:
综合了线性过程流和并行过程流的特征。
每个增量都提交一个可以运行的产品。
原型开发模型(图见P33)
适用情形
客户提出了一些基本功能,但没有详细定义功能和特性需求
开发人员可能对算法的效率、操作系统的兼容性和人机交互的形式等情况并不确定
特点
很少是好用的,可能太慢太大,难以使用。
一般作为被丢弃的系统。
UML-统一建模语言
统一过程(UP)(图见P41)
沟通+策划->
起始
策划+建模->
细化
构建->
构建
构建+部署->
转换
发布,软件增量->
生产
敏捷软件开发的宣言
“我们正在通过亲身实践以及帮助他人实践的方式来揭示更好的软件开发之路,通过这项工作,我们认识到:
个人和他们之间的交流胜过了开发过程和工具
可运行的软件胜过了宽泛的文档
客户合作胜过了合同谈判
对变更的良好响应胜过了按部就班地遵循计划
也就是说,虽然上述右边的各项很有价值,但我们认为左边的各项具有更大的价值。
”
敏捷过程
是由客户对他们需求的描述(场景)所驱动的
意识到计划是短期的
着重强调构建活动的软件迭代开发
交付多个软件增量
适应变更的出现
收集需求
目的是
标识问题
提出解决方案的元素
协商不同方法
确定一套解决需求问题的初步方案
质量功能部署(QFD)
功能部署决定系统所需的每一个功能的“价值”(由客户感知)
信息部署确定数据对象和事件
任务部署检查系统行为
价值分析决定需求的相对优先权
分析模型的元素
基于场景的元素
功能说明——处理软件功能的描述
用例——描述“参与者”和系统之间的交互作用
基于类的元素
由场景暗示
行为元素
状态图
面向数据流元素
数据流图
桥接
系统元素-分析模型-设计模型
域分析(一种普适性活动)
软件域分析是识别、分析和详细说明某个特定应用领域的公共需求,特别是那些在该应用领域内被多个项目重复使用的……
[面向对象的域分析是]在某个特定应用领域内,根据通用的对象、类、部件和框架,识别、分析和详细说明公共的、可复用的能力
分析模式
模式名称:
捕获模式本质的描述符。
目的:
描述该模式实现了或代表什么。
动机:
说明怎样用模式解决问题的一个场景。
影响环境:
对外部问题(影响)的描述,即能够影响如何使用模式,当应用该模式时,影响即将被解决的外部问题。
解决方案:
对如何应用模式来解决强调结构和行为问题的描述。
效果:
解决了发生在应用模式时和应用过程中存在权衡的问题。
设计:
通过使用已知的设计模式讨论如何实现该分析模式。
已知应用:
在实际系统中使用的例子。
相关模式:
与命名模式有关的一个或更多分析模式,因为
(1)通常与命名的模式共同使用;
(2)结构上与命名模式相似;
(3)是命名模式的一个变体。
需求监视
在增量开发时特别需要:
分布式调试-发现错误及确定其原因。
运行时验证-确定软件是否与其规格说明相匹配。
运行时确认-评估演化的软件是否满足用户目标。
业务活动监视-评价系统是否满足业务目标。
演化和代码设计-在系统演化时給利益相关者提供信息。
需求建模
基于场景的模型
从用户角度来看的系统。
(用例图)
数据模型
表示数据在系统内是如何转换的。
面向类的模型
定义对象、属性和关系。
(类图)
面向流的模型
(数据流图)
行为模型
表示事件对系统状态的影响(状态图)
事件流是通过文字描述一个用例的方法,说明用例的逻辑流程。
软件域分析是识别、分析和详细说明某个特定应用领域的公共需求,特别是那些在该应用领域内被多个项目重复使用的……[面向对象的域分析是]在某个特定应用领域内,根据通用的对象、类、部件和框架,识别、分析和详细说明公共的、可复用的能力
需求建模策略
需求建模的一种视角,被称作结构化分析,它考虑数据和把数据转换为独立实体的过程。
数据对象的建模方式是,定义对象的属性和关系。
操纵数据对象的过程的建模方式是,表明当数据对象流过系统时它们如何转换数据。
分析建模的第二种方法,被称作面向对象分析,该方法关注于
定义类
类彼此之间协作以影响客户需求的方式
基于类建模表示:
系统操纵的对象
操作(也称作方法或服务),应用于对象以影响操纵。
对象之间(某种层级)的关系
·
协作,在所定义的类之间发生
基于类的模型元素包括类和对象、属性、操作、CRC模型、协作图和包。
分析类
分析类代表“系统中具备职责和行为的事物”的初期概念模型。
这些概念模型最终将演进为设计模型中的类和子系统。
分析类表现为如下方式之一:
外部实体(例如其他系统、设备、人员),产生或使用基于计算机系统的信息
事物(例如报告、显示、字母、信号),问题信息域的一部分
偶发事件或事件(例如所有权转移或完成机器人的一组移动动作),在系统操作环境内发生
角色(例如经理、工程师、销售人员),由和系统交互的人员扮演
组织单元(例如部门、组、团队),和某个应用系统相关
场地(例如制造车间或码头),建立问题的环境和系统的整体功能
结构(例如传感器、四轮交通工具、计算机),定义了对象的类或与对象相关的类
例子见p109
潜在类
保留信息。
只有记录潜在类的信息才能保证系统正常工作,在这种分析过程中的潜在类是有用的。
所需服务。
潜在类必须具有一组可确认的操作,这组操作能用某种方式改变类的属性值。
多个属性。
在需求分析过程中,焦点应在于“主”信息;
事实上,只有一个属性的类可能在设计中有用,但是在分析活动阶段,最好把它作为另一个类的某个属性。
公共属性。
可以为潜在类定义一组属性,这些属性适用于类的所有实例。
公共操作。
可以为潜在类定义一组操作,这些操作适用于类的所有实例。
必要需求。
在问题空间中出现的外部实体,和任何系统解决方案运行时所必需的生产或消费信息,几乎都被定义为需求模型中的类。
(p110)
类的类型
实体类,也称作模型或业务类,是从问题说明中直接提取出来的(例如FloorPlan和Senor)。
边界类用于创建用户可见的和在使用软件时交互的接口(如交互屏幕或打印的报表)。
控制类自始至终管理“工作单元”[UML03]。
也就是说,设计控制类可以管理:
实体类的创建或更新;
当边界类从实体对象获取信息后的实例化;
对象集合间的复杂通信;
对象间或用户和应用系统间交换数据的确认。
类之间三种不同的通用关系[WIR90]:
is-part-of(是……一部分)关系--复合聚合类
has-knowledge-of(有……知识)的关系
depends-upon(依赖……)关系
评审CRC模型
所有参加(CRC模型)评审的人员拿到一部分CRC模型索引卡。
拆分协作卡片(也就是说每个评审员不得有两张存在协作关系的卡片)。
分类管理所有的用例场景(以及相关的用例图)。
评审组长细致地阅读用例。
当评审组长看到一个已命名的对象时,给拥有相应类索引卡的人员一个令牌。
当令牌传递时,索引卡的拥有者需要描述卡上记录的职责。
评审组确定(一个或多个)职责是否满足用例需求。
如果记录在索引卡上的职责和协作不能满足用例,就需要修改卡片。
修改可能包括定义新类(和相关的CRC索引卡),或者在已有的卡上说明新的或修改的职责、协作。
类状态具有被动和主动两种特征[CHA93]。
被动状态只是某个对象所有属性的当前状态。
一个对象的主动状态指的是对象进行持续变换或处理时的当前状态。
系统的状态
状态——在给定的时间内,观察到的一组系统行为特征的情况
状态转换——从一个状态到另一个状态的运动
事件——能导致系统表现出一些可预测的行为方式的发生
活动——以作出转变结果形式出现的过程
行为建模
1.列出不同的系统状态(系统如何表现?
)
2.表明系统如何从一个状态转变为另一个状态(系统怎样改变状态?
指出事件
指出活动
3.画状态图或顺序图
WebApp的需求模型
内容分析。
给出由Web应用系统提供的全部系列内容。
内容包括文本、图标和图像、视频和音频数据。
数据建模用来确定和描述每一个数据对象。
交互分析。
详细描述了用户与Web应用系统采用了哪种交互方式。
开发用例提供这种交互方式的详细描述。
功能分析。
作为交互分析一部分创建的使用场景(用例)定义了将用于Web应用系统内容并描述其他处理功能的操作。
所有的操作和功能都被详细的描述。
配置分析。
详细描述Web应用系统驻留的环境和基础设施。
交互模型
由四个元素组成
用例
顺序图
用户界面原型
软件设计宣言--良好的软件设计应该展示:
坚固:
程序应该不含任何妨碍其功能的缺陷。
适用:
程序应该符合开发的目标。
愉悦:
使用程序的体验应是愉快的。
设计原则
设计过程中不要有“井蛙之见”。
设计应起源于分析模型。
设计不要白费力气做重复工作。
在软件和真实世界的问题之间,设计应能“最小化知识距离”[DAV95]。
设计应表现出一致性和集成性。
设计结构应适应变化。
即使遇到数据、事件或操作条件异常时,设计结构应能温和处理。
设计不是编码,编码不是设计。
创建设计时就应对其质量进行评估,而不是创建之后。
评审设计以最小化概念上的(语义的)错误。
设计的基本概念
抽象——数据、过程、控制
体系结构——软件的整个结构
模式——已证实的解决方案的“精髓”
关注点分离——任何复杂问题如果被分解为若干块,该复杂问题更容易地被处理。
模块化——数据和功能的划分
信息隐蔽——控制接口
功能独立——专一的功能和低耦合
求精——所有抽象精化的细节
方面——一种理解全部需求如何影响设计的机制
重构——一种简化设计的重新组织的技术
面向对象设计概念——附录II
设计类——提供设计细节,使分析类得以实现
设计模式模版
模式名——以简短但富于表现力的名字描述模式的本质
目的——描述模式及其做什么
也称为——列出任何模式的别名
动机——提供问题的实例
适用性——指出模式适用的具体设计解决方案
结构——描述要求实现模式的类
参与者——描述要求实现模式的类的职责
协作——描述参与者如何协作,以完成他们的职责
结构——描述了影响模式的“设计力量”和在实现模式时,必须考虑的潜在权衡
相关模式——相关设计模式的交叉索引
模块功能独立
通过开发具有“专一”功能和“避免”与其他模块过多的交互的模块,可以实现功能独立。
独立性有两条定性标准进行评估:
内聚性显示了某个模块相关功能的强度。
一个内聚的模块执行一个独立的任务,与程序的其他部分构件只需要很少的交互。
简单地说,一个内聚的模块应该(理想情况下)只完成一件事情。
耦合性显示了模块间的相互依赖性。
耦合性依赖于模块之间的接口复杂性、引用或进入模块所在的点以及什么数据通过接口进行传递。
方面
考虑两个需求,A和B。
“如果已经选择了一种软件分解[精化],在这种分解中,如果不考虑需求A的话,需求B就不能得到满足”[Ros04],那么需求A横切需求B。
方面是一个横切关注点的表示。
重构
Fowler[FOW99]用下面的方式定义重构:
“重构是使用这样一种方式改变软件系统的过程:
不改变代码[设计]的外部行为而是改进其内部结构。
当重构软件时,检查现有设计:
冗余性
没有使用的设计元素
低效的或不必要的算法
拙劣的或不恰当的数据结构
其他设计不足,修改这些不足以获取更好的设计。
OO设计概念
设计类
实体类
边界类
控制类
继承——超类的所有特点立即被所有子类继承。
消息——刺激接收对象产生某种行为
多态——一种可以显著减少扩展已存在的设计的特性
在设计时,分析类被精化变为实体类
边界类是在设计中创建接口被开发的(例如:
交互式屏幕或打印报表),用户看到并与使用的软件交互。
边界类的设计,其职责管理将实体对象呈现给用户的方式。
控制类被设计用来管理
实体对象的创建和更新;
边界对象的实例化,因为它们获得来自实体对象的信息;
对象集之间的复杂通信;
验证对象之间或用户与应用程序之间的数据通信。
设计类的特征
完整性-包含所有必须的属性,只包含那些“对实现该类的目的是足够”的方法
原始性–每个类方法关注于提供一个服务
高内聚性–小的、集中的、专一的类集合
低耦合性–类之间的协作保持在最小范围内
书P146设计模型的维度图
体系结构为什么重要?
软件体系结构的表示有助于对基于计算机的系统开发感兴趣的各方(利益相关者)开展交流。
体系结构突出了早期的设计决策,这些决策对随后所有的软件工程工作有深远影响,同时对系统作为一个可运行实体的最后成功有重要作用。
体系结构“构建了一个相对小的、容易理解的模型,该模型描述了系统如何构成以及其构件如何一起工作”[BAS03]。
体系结构风格
每种风格描述一种系统类别,包括:
(1)完成系统所需要的某种功能的一组构件(例如数据库、计算模块);
(2)能使构件间实现“通信、协调和合作”的一组连接件;
(3)定义构件如何集成为系统的约束;
(4)语义模型,能使设计者通过分析系统组成成分的已知属性来理解系统的整体性质。
·
以数据为中心的体系结构
数据流体系结构
调用和返回体系结构
面向对象体系结构
层次体系结构
体系结构模式
并发性——应用程序必须以模拟并行的方式来处理多任务
操作系统进程管理模式
任务调度器模式
持久性——如果数据在创建它的进程运行结束之后仍然要存在,则数据是持久的。
两种常见模式是:
数据库管理系统模式,它把DBMS的存储和检索功能应用到应用系统的体系结构之中
应用级持久性模式,它把持久性特征构建到应用系统体系结构之中
分布性——在分布式环境中,系统或系统内的构件之间相互通信的方式
代理的作用是在客户端构件和服务器端构件之间担当“中间人”。
定体系结构的原型集
原型(类似于类)是表示系统行为元素的一种抽象
体系结构的考虑要素
经济性–最好的软件应该是整洁的并依赖抽象化以减少无用的细节。
易见性–对于那些随后将验证这些模型的软件工程师而言,体系结构的决策及其依据应该是显而易见的。
隔离性–在设计中不产生隐藏依赖的关注点分离。
对称性–体系结构的对称性意味着它的属性是均衡一致的。
应急性–紧急的、自组织的行为和控制。
体系结构的复杂性
通过考虑体系结构中构件间的依赖关系,对提议的体系结构的整个复杂性进行评估[Zhao98]
共享依赖表示使用相同资源的消费者之间或为相同消费者生产的生产者之间的依赖关系。
流依赖表示资源的生产者和消费者之间的依赖关系。
约束依赖表示在一组活动间相互控制流上的约束。
体系结构描述语言(ADL)
构件的定义
OMG统一建模语言规范[OMG01]是这样定义构件的:
“系统中模块化的、可部署的和可替换的部件,该部件封装了实现并对外提供一组接口。
OO观点:
构件包含一组协作的类
传统观点:
一个构件包含处理逻辑,实现处理逻辑所需的内部数据结构以及能保证构件被调用和实现数据传递的接口。
构件基本设计原则
开闭原则(OCP)。
“模块[构件]应该对外延具有开放性,对修改具有封闭性”。
Liskov替换原则(LSP)。
“子类可以替换它们的基类”。
依赖倒置原则(DIP)。
“依赖于抽象,而非具体实现”。
接口分离原则(ISP)。
“多个客户专用接口比一个通用接口要好”。
发布复用等价性原则(REP)。
“复用的粒度就是发布的粒度”。
共同封装原则(CCP)。
“一同变更的类应该合在一起”。
共同复用原则(CRP).。
“不能一起复用的类不能被分到一组”。
内聚性
内聚性描述为模块的专一性
OO观点:
:
内聚性意味着构件或者类只封装彼此之间/与构件或类自身之间紧密相关的属性和操作。
内聚性的级别
功能内聚:
当一个模块完成一组且只有一组操作并返回结果时
分层内聚:
由包、构件和类来体现。
高层能够访问低层的服务,反之不可。
通信内聚:
访问相同数据的所有操作被定义在一个类中。
顺序内聚:
模块内元素必须以特定次序执行,前者输出为后者输入;
过程内聚:
模块内元素必须以特定次序执行
时间内聚:
模块内各元素在同一时间段内执行;
如:
变量初始化等,在同一时间内执行
实用程序内聚:
部件常常是一些相关的、可重用的实用程序。
耦合性
传统观点
构件之间彼此联系、构件和外部世界联系程度的一种度量
OO观点:
类之间彼此联系程度的一种定性度量
耦合分类
内容耦合,一个构件暗中修改其他构件的内部数据
共用耦合,当大量的构件都要使用同一个全局变量时
控制耦合,当操作A调用操作B,并且向B传递控制标记时
标记耦合,当类B被声明为类A某一操作中的一个参数类型时
数据耦合,当操作需要传递长串的数据参数时
例程调用耦合,当一个操作调用另外一个操作时
类型使用耦合,当构件A使用了在构件B中定义的一个数据类型时
包含或者导入耦合,当构件A引入或者包含一个构件B的包或者内容时
外部耦合,当一个构件和基础设施构件进行通信和协作时
领域分类
枚举类型——通过定义类中的分层结构及定义软件构件子类等级来描述构件。
逐面分类法——分析领域范围,并确定一组基本特征的描述。
属性-值分类——为所有在领域范围内的构件定义一组属性。
用户界面设计的黄金规则
把控制权交给用户
减少用户的记忆负担
保持界面一致
以不强迫用户进入不必要的或不希望的动作的方式来定义交互模式。
提供灵活的交互。
允许用户交互被中断和撤销。
当技能水平高时可以使交互流线化并允许定制交互。
使用户与内部技术细节隔离开来。
设计应允许用户与出现在屏幕上的对象直接交互。
减轻用户的记忆负担
减少对短期记忆的要求。
建立有意义的默认设置。
定义直观的快捷方式。
界面的视觉布局应该基于真实世界的象征。
以一种渐进的方式揭示信息。
允许用户将当前任务放入有意义的环境中。
在完整的产品线内保持一致性。
如果过去的交互模型已经建立起了用户期望,除非有不得已的理由,否则不要改变它。
用户界面设计模型
用户模型——系统所有最终用户的轮廓
设计模型——用户模型的设计实现
心理模型(系统感觉)——用户脑海里对界面产生的映像
实现模型——“视感”界面,结合了用来描述界面语法和语义的支撑信息
用户界面设计过程
界面分析和建模->
界面设计->
界面构造->
界面确认
呈螺旋型,即完成至尾部后迭代至开始
验证与确认
验证是指确保软件正确地实现某一特定功能的一系列活动。
确认指的是确保开发的软件可追溯到客户需求的另外一系列活动。
Boehm[Boe81]用另一种方式说明了这两者的区别:
验证:
我们在正确地构造产品吗?
确认:
我们在构造正确的产品吗?
代码生成-单元测试
设计模型-集成测试
需求分析模型-确认测试
系统工程-系统测试
单元测试
对单个模块的测试,在面向对象测试中,其重点在于封装的类,类中包含的测试是最小的可测试单元
集成测试策略
集成测试是构件软件体系结构的系统化技术,勇士也是进行一些已在发现与接口相关的错误的测试。
选择:
“一步到位”方法,非增量式的
增量构件策略
测试方法
自顶向下集成测试:
通过自顶向下逐渐将桩模块替换为实际模块完成测试
自底向上增量式测试:
通过先测试底层模块,然后将已测试过的部分划分为簇,逐步向上层测试,过程中不需要桩模块
三明治测试:
混合增量式测试,结合自顶向下和自底向上进程集成和测试,其测试中同时可能存在桩模块和簇
回归测试:
在修改软件后执行以测试过的某些子集,以确保变更中没有传播不期望的副作用,避免因修正旧错误导致的新错误
冒烟测试:
每日都构建一个构造,包含所有至此的所有进度,并对其进行测试以发现导致此构造工作异常的错误,这个测试方法可以是以上任意的。
此举有利于在早期发现错误以避免可能导致项目延迟的“业务堵塞”错误。
通用测试标准
接口的完整性–在把每个模块或簇添加到软件中时,测试内部和外部模块的接口。
功能的有效性–通过测试来发现软件中的功能缺陷。
信息内容–通过测试来发现局部的或全局的数据结构中的错误。
性能-验证规定的性能边界是否测试过。
OO测试策略
类测试相当于单元测试
测试类中的操作
检查类的状态行为
集成测试应用三种不同的策略
基于线程的测试——对响应系统的一个输入或事件所需的一组类进行集成
基于使用的测试——对响应系统的一个用例所需的一组类进行集成
簇测试——对演示一个协作所需的一组类进行集成
高阶测试
恢复测试
通过各种方式强制地使软件发生故障,并验证其能适当恢复。
安全测试
验证建立在系统内的保护机制是否能够实际保护系统不受非法入侵。
压力测试
以非正常的数量、频率或容量的方式执行系统。
测试是想要破坏程序。
举例:
—如果正常的中断频率为每秒5次,强度测试设计为每秒50次中断。
—把输入数据的量提高一个数量级来测试输入
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件工程 复习 要点