任胜兵老师软件工程课件知识点整理Word文档格式.docx
《任胜兵老师软件工程课件知识点整理Word文档格式.docx》由会员分享，可在线阅读，更多相关《任胜兵老师软件工程课件知识点整理Word文档格式.docx（23页珍藏版）》请在冰豆网上搜索。
社会实践需要、追踪科学前沿和热点
嵌入式系统研究的问题：
嵌入式系统的可靠性（稳定运行的时间）
嵌入式系统的性能（运行速度、功耗）
嵌入式系统的可演化性（结构）
嵌入式系统的正确性（行为）
嵌入式系统地正确性：
系统建模与验证
如何找到研究问题
首先，从项目实践中获取候选问题列表：
实践中经常遇到的问题是什么？
实践中难以解决的问题是什么？
实践中最重要的要解决的问题是什么？
其次，通过交流确定候选题目：
与导师交流，如果研究领域导师熟悉，很快就可以确定
广泛阅读最新的文献，通过阅读文献，尤其是会议论文，能够确定目前这一领域的热点研究问题是什么
与同学交流，包括高年级同学、其他专业同学、其他学校同学
依据自己的兴趣爱好
如何确定研究内容
首先，从收集的文献中确定一篇合适的文献作为起点，仔细阅读，回答：
文章研究的问题是什么？
其背景是什么？
其意义是什么？
文章解决问题的理论依据是什么？
文章解决问题的方法是什么？
包括论证过程、实验数据、实验工具
文章解决问题得到的有用结论是什么？
应用价值和科学价值何在？
其次，针对详细阅读的论文，仔细思考以下问题：
文章中有哪些方面的内容值得进一步研究？
文章还有哪些问题没有涉及到？
文章的研究方法可以进一步改进吗？
文章的实验数据存在问题吗？
文章的实验工具可以改善吗？
文章的结论，尤其是展望值得进一步研究吗？
文章的研究在实际应用中还存在哪些问题？
文章的结论可靠吗？
与实际相符吗？
再次，确认前面提到的各种问题：
查找相关文献
学习与论文有关的基本理论
动手验证论文的实验
进一步思考前面的问题，通过批判性思维反驳，记录反驳的依据
与同学进行交流讨论
与导师交流讨论
RAD模型的不足
技术风险很高的情况不适合采用；
（如新软件要求与已存在的程序有高可互操性时，或系统难以被适当地划分为若干功能等情况）
需要足够的人力以创建足够的RAD小组；
开发者和用户需要在很短的时间内完成系统开发。
渐增模型
前述生存期模型，均是一次性地将整个系统交给用户：
瀑布模型是假设当线性阶段完成之后就能交付一个完善的系统。
原型模型主要用来帮助开发者获取用户需求，待需求稳定后再开发最终系统提供给用户。
RAD模型则先将系统主要功能分给若干RAD小组开发，然后集成起来形成最终系统提交给用户。
业务和产品需求的变化，市场竞争和商业压力等等
以逐步增加软件产品的方式构造软件---渐增模型
渐增模型的特点
♦可以根据需要补充人员；
♦能够有计划地管理技术风险；
♦能够减少全新软件产品对用户带来的影响；
♦不需要大的资金支出；
♦用户能及早使用及早发现问题；
♦投资回报随功能渐增而渐增。
渐增模型的不足:
如果产品整体结构设计不当，则难以为其增加新的增量；
（对设计水平要求较高）
由于采用增量开发，故难于进行彻底的测试。
螺旋模型
螺旋模型的特点:
既保持了传统生命周期模型中系统的阶段性方法，又将迭代演化的思想吸收到模型中；
螺旋模型是风险驱动的。
（风险分析使得用户和开发者能够更好地理解和对待每一个阶段的风险）
螺旋模型适合于大型软件的开发
螺旋模型的不足:
要求软件开发人员善长风险分析；
风险分析会导致项目终止而终止合同，出现违约诉讼；
对于小项目，风险分析的成本可能与整个项目的成本相当。
敏捷原则
♦最优先要做的是通过尽早地、持续地交付有价值的软件来使客户满意。
♦即使在开发后期，也欢迎需求改变。
敏捷过程利用变化来为客户创造竞争优势。
♦经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。
♦在整个项目开发期间，业务人员和开发人员必须天天在一起工作。
♦围绕有积极性的个人构建项目团队。
为他们提供所需的环境和支持，并信任他们能够完成工作。
♦在团队内部，最有效果并富有效率的信息传递方法是面对面的交流。
♦可运行的软件是首要的进度度量标准。
♦敏捷过程提倡可持续的开发速度。
责任人、开发者和用户应该能够保持一个长期的、稳定的开发速度。
♦持续关注优秀的技能和好的设计，增强敏捷能力。
♦简单（是不必做的工作最大化的艺术）是必要的。
♦最好的架构、需求和设计出自于自组织的团队。
♦每隔一段时间，团队应反省如何才能有效地工作，并相应地调整自身的行为。
极限编程（ExtremeProgramming，简称XP）是由KentBeck、WardCunningham、RonJeffries等人通过整理优秀团队的共同之处而提出的敏捷过程。
所谓极限，KentBeck认为是：
尽力而为，然后处理其结果。
极限编程专注于编程技术、清晰沟通和团队协作，只需做能够为客户创造价值的事情，是一组确保项目开发成功的规则，适用于任何规模的团队，适合模糊或快速变化的需求。
站立式会议大多在9点钟开始，团队集中讨论当前的工作，对具体问题寻求解决建议。
站立会议一般持续很短的时间，应该回答：
自昨天开始已经做了什么？
从现在开始你将做什么？
阻碍迭代目标的有什么？
有没有未完成的事情？
在需求或技术等方面是否有与其他人员有关的决定等。
站立式会议的目的是相互交流学习，了解项目的进度。
极限编程过程强调小规模、频繁地发布代码和测试。
一方面，小型发布有利于尽早为客户提供业务价值，使客户增加信心。
另一方面，客户可以通过使用小型发布的软件系统，能够获取更多的其他需求，发现系统存在的缺陷，通过反馈将更有力地指导项目成功，包括改善进度估算、完善故事、改变故事实现的优先级等。
在发布阶段，如果需要文档，则应该在当前版本趋于稳定时撰写文档，主要包括：
系统文档，为理解系统提供一个总览信息，如系统技术架构、高层次系统需求、关键设计决策总结、重要的设计模型等等；
系统操作文档，描述系统涉及的依赖关系、与其他系统交互的特性、预期系统负载等；
系统支持文档，描述解决问题时的参考信息、疑难问题的上报流程、维护团队的联系列表等；
用户文档，如参考手册、用户指南、支持指南及培训资料等。
极限编程实践:
Scrum过程
在敏捷软件开发中，Scrum是一种迭代增量式软件开发过程，就像橄榄球赛的争球过程：
快速、自组织和有适应性。
Scrum团队角色:
产品负责人（ProductOwner）：
定义和维护“产品待办事项表（ProductBacklog）”，负责最大化产品以及Scrum团队的工作价值，代表利益相关者的利益。
Scrum主管（ScrumMaster）:
确保Scrum团队遵循Scrum理论、实践和规则，通过指导和引导，使Scrum团队更加高效地创建高质量的产品。
开发团队（DevelopmentTeam）：
负责在每个冲刺（Sprint）结束，交付潜在可发布的“已完成”产品增量。
只有开发团队的成员才能交付产品增量。
开发团队:
团队的大小足够小，以保证灵活性，同时应能完成有意义的任务，一般是7±
2人。
开发团队有以下几个特点：
员是自组织的，没有人（即使是Scrum主管都不可以）告诉开发团队如何把产品待办事项表变成潜在可发布的功能。
开发团队是跨功能的，团队作为一个整体拥有创造产品增量所需要的全部技能。
Scrum不认可开发团队成员的头衔，无论承担哪种工作他们都是开发者。
此规则无一例外。
开发团队中的每个成员可以有特长和专注领域，但是责任归属于整个开发团队。
开发团队不包含如测试或业务分析等负责特定领域的子团队。
Scrum制品:
Scrum软件开发过程产生的制品除可工作的软件外，主要有四种：
产品待办事项表、冲刺待办事项表、冲刺燃尽图和发布燃尽图。
产品待办事项表模版
冲刺待办事项表模版
冲刺燃尽图（SprintBurndown）
Scrum会议由Scrum主管主持。
冲刺计划会
每日站立会
冲刺评审会议
冲刺反思会
与极限编程敏捷软件开发过程相比，Scrum过程强调管理，而极限编程强调实践，两者具有很好的互补性。
冲刺计划会
♦冲刺计划会是为冲刺做准备的会议，主要确定冲刺要做什么和怎么做，时间大概是几个小时。
♦在这个会议中，开发团队和产品负责人通过共同讨论，理解产品负责人需要什么和为什么需要，从而由开发团队自己确定本次冲刺应该完成的产品待办事项表中的条目。
♦然后，开发团队针对要在本次冲刺中实现的条目进行计划、分析和设计，并将每个条目分解成细粒度的任务，形成冲刺待办事项表和冲刺目标。
每日站立会议
要求每个成员都参加，时间不超过15分钟。
会上，所有成员必须回答三个问题：
上次站立会议后做了哪些工作？
遇到了哪些问题？
下次站立会议之前计划做什么？
Scrum主管负责帮助团队解决遇到的问题。
在会后，会有一个或多个并行的会议跟进。
跟进会议不要求所有人都参加，主要针对站立会议收集的信息与相关成员作进一步的沟通，此时Scrum主管一般不参加。
冲刺评审会议
对功能性的产品增量进行审视和调整，时间不超过4小时（小时数等于本次冲刺周期的周数）。
在冲刺评审会中，真实用户和产品负责人检验和使用运行起来的软件。
通过开发团队、产品负责人和其他涉众之间的交流，审视产品的进展，并针对问题进行调整。
冲刺反思会
在冲刺评审会之后，针对流程和环境的审视和调整。
每位成员要求对本次冲刺的情况进行回顾，不仅对工作中存在的问题进行反思，而且也要讨论好的工作方式。
每位成员要对其他成员的反思进行评价，表达各自的期望。
有人统计，在行业实际使用的所有敏捷软件开发过程中，极限编程过程占8%，Scrum过程占49%，极限编程和Scrum结合过程占22%，其他敏捷软件开发过程占21%。
精益软件开发
特征驱动软件开发
基于Petri网的软件过程建模:
C.A.Petri博士在1962年首次提出了Petri网的概念。
Petri网是一种用于系统描述和分析的数学工具。
Petri网通过对实际软件开发过程中的开发活动,对产品、资源等进行抽象,从而完成对软件过程的描述,并进一步支持软件过程的标准化和自动化。
二元组N=（S,T,F）称为有向网的充分必要条件是：
1.S∩T=φ,（二元性）
2.S∪T≠φ,（非空）
3.F⊆SxT∪TxS,（x为笛卡尔积）
4.dom（F）∪cod（F）=S∪T,（不存在孤立元素）
其中：
dom（F）={x|∃y:
（x,y）∈F},
cod（F）={y|∃x:
（x,y）∈F}
分别称为F的定义域（domain）和值域（codomain）
S称为N的库所集，通常用圆圈或椭圆表示库所，描述系统状态
T称为N的变迁集，通常用方框或粗杠表示变迁，描述系统事件
F称为N的流关系，通常用箭头表示，描述系统状态和事件之间的关系
通常在Petri网的图形表示中,用圆圈（O）表示库所,矩形（口）表示变迁,黑点（·
）表示托肯（token）。
Petri网例子
一年四季的变化
状态：
春、夏、秋、冬
事件：
立春、立夏、立秋、立冬
Petri网系统
Petri网只提供了系统的结构框架，就像演戏的舞台
活动在框架上的是系统中流动的资源
假定有向网N=（S,T,F），记IN0={0,1,2,…},IN={1,2,…},并以ω表示无穷：
ω=ω+1=ω+ω
K:
S->
IN∪{ω}称为N的容量函数
对给定的容量函数K，M:
IN0称为N的一个标记（Marking）的条件是：
∀s∈S：
M（s）≤K（s）
W:
F->
IN称为N上的权函数，对（x,y）∈F,W（x,y）=W（（x,y））称为（x,y）上的权
六元组∑=（S,T,F,K,W,M0）构成网系统的条件是：
1）N=（S,T,F）构成有向网，称为∑的基网
2）K,W和M0依次为N的容量函数、权函数和初始标识
Petri网系统变迁发生的条件
假定N是Petri网系统的基网
.x={y|（y，x）∈F}称为x的前集或输入集
x.={z|（x，z）∈F}称为x的后集或输出集
t是N中的变迁，.t.=.t∪t.称为t的外延
t在M有发生权的条件是：
∀s∈.t：
M（s）≥W（s,t）∧
∀s∈t.：
M（s）+W（s,t）≤K（s）
t在M有发生权记作M[t>
也说M授权t发生或t在M授权发生
若M[t>
，则t在M可以发生，将标识M改变为M’,对任何s∈S，M’（s）为：
M（s）-W（s,t）,若s∈.t-t.
M（s）+W（s,t）,若s∈t.-.t
M（s）-W（s,t）+W（t,s）,若s∈t.-.t
M（s）,若s∉.t.
♦简单有色Petri网的例子哲学家就餐
P={Think,Eat,Unusedchopsticks}
T={TakeChopsticks,PutDownChopsticks}
A={（Think,TakeChopsticks）,（TakeChopsticks,Eat）,（Eat,PutDownChopsticks）,（PutDownChopsticks,Think）,（Unusedchopsticks,TakeChopsticks）,（PutDownChopsticks,Unusedchopsticks）}
∑={PH,CS}
V={p:
PH}
C（p）={PHifp∈{Think,Eat},CSotherwise}
G（t）=trueforallt∈T
E（a）={1'
pifa∈{（Think,TakeChopsticks）,（TakeChopsticks,Eat）,（Eat,PutDownChopsticks）,（PutDownChopsticks,Think）,
chopsticks（p）otherwise}
I（p）={PH.all（）ifp∈{Think},
CS.all（）ifp∈{Unusedchopsticks},
Omsotherwise}
对一个有色Petri网CPN,定义：
1）一个标识（Marking）是一个函数M,将每一个库所p映射为标记M（p）∈C（p）ms的多重集合
2）初始标识M0定义为M0（p）=I（p）<
>
对所有p∈P.<
表示空绑定
3）变迁t的变量var（t）⊆V，由t的守卫条件中出现的自由变量和与t相连的弧的弧表达式中出现的自由变量组成
4）变迁t的一个绑定是一个函数b，将每个变量v∈var（t）映射到一个值b（v）∈type（v）.变迁t的所有绑定集记为B（t）
5）一个绑定元素是一个二元组（t,b）,满足t∈T,b∈B（t）.CPN模型中所有绑定元素构成的集合记为BE
6）步Y∈BEms是一个绑定元素的非空、有限多重集合
例如（Take_Chopsticks,<
p=ph
（1）>
）便是一个有色Petri网变迁Take_Chopsticks的步
软件组织为何要引入CMMI？
企业面临更多的挑战与市场竞争
新的发展方向和机会
软件外包服务，业务合作
“认证”要求–市场宣传、投标资质、顾客的压力……
ISO9001，CMMI，信息安全，知识产权保护
顾客满意度，要求按时交付产品；
以较低的成本、开发出更多功能、更好质量的产品
企业能力提升的要求
业务和规模和扩展（开发团队人员增加）
更复杂的产品
人员流失（组织的知识资产没有保留和积累）
项目的可预见性不足
很多不成熟的软件组织面临的问题
项目有可能获得良好的性能和结果，但是
需求经常得不到一致的理解，并且往往是不受控制地进入项目
进度和预算经常得不到保障
项目的进展无法度量
产品的内容没有跟踪和控制，版本混乱
工程活动没有标准，实施得不一致
开发团队没有经过培训，相互间不协调
缺陷增生
项目的成功依赖于技术骨干
♦CMMI–能力成熟度模型集成
CapabilityMaturityModelIntegration
♦软件过程改进方面得到国际认可的标准
♦目的：
为软件组织改进和提高过程能力提供指南
♦内容：
涵盖系统工程和软件工程管理的最佳实践
-涉及产品的开发和维护活动、覆盖产品从概念提出到交付和维护的整个生存周期。
♦评估组织当前开发管理状况的标尺
阶段型按成熟度等级划分过程域
指导思想：
自顶向下、逐步求精、单入口、单出口；
基本原则：
抽象和功能分解；
方法论：
系统是由一些功能的相互联系、相互作用而形成；
结构化方法系列：
结构化分析方法、结构化设计方法和结构化程序设计方法。
（具体）技术方法：
面向数据流图的方法、IDEF0方法、Jackson方法、LCP（LogicalConstructionPrograms）方法等。
结构化方法的特点
强调阶段划分；
简单实用；
技术成熟；
应用广泛。
特别适合于需求能够预先指定的系统的开发
结构化方法的不足
不太适应规模大及特别复杂的项目；
难于解决软件重用（复用）问题；
难于适应需求变化或模糊的问题；
软件维护依然比较复杂。
DataFlowModeling
数据流建模方法是一种结构化分析方法；
自顶向下、逐层分解地定义系统需求；
特点是利用数据流图来对用户需求进行分析；
可用于分析任何应用系统的需求（why?
）。
数据流（用箭头表示）；
加工（加工一般用一个圆圈或圆角方框来表示）；
数据存储（一般用开口的矩形框或双划线来表示）；
数据的源点和终点（一般用正方形或立方体来表示）；
扩展符号主要有：
*、+和⊕。
分层数据流图
只用一张数据流图来描述，不仅难于一次画齐，而且也难于理解。
分层数据流图可以避免一次引入过多的细节，有利于控制问题的复杂度，从而便于对大型系统描述的实现。
不同的用户可以只选择分层数据流图中与本身有关或感兴趣的部分，不必阅读全图，从而便于用户的使用和理解。
除顶层图只有一张不用编号外，每一张分层图均编号，编号规则为：
①分层图的编号等于相应被分解处理的编号；
②处理的编号=图的编号+“.”+顺序号；
③顶层图中处理编号为0，可省略。
例子
假设商场每周需要一张订货报表，表中对于每一需要订货的商品，要求列出下列数据：
商品编号、商品名称、库存数量、订货数量、商品单价、供应商。
商品入库或出库称为库存更新事务。
系统通过仓库中的显示终端由仓库管理员把事务报告录入到订货系统中。
当某种商品的库存数量比设定的库存量临界值小时，表示需要订货。
采购员根据每周的订货报告进行订货。
1）抽象与求精
抽象是一种常用的思考和解决问题的方式，即抽取事物的本质的共同特性而暂时避开不必要的低层细节。
方式：
过程抽象、数据抽象和控制抽象。
抽象过程是指具有特定功能的一个命名的指令序列。
（如：
二维图形创建）
抽象数据则是描述数据对象的一个命名的数据集合。
“图画”数据对象）
抽象控制包含了一种程序控制机制而无须刻画其内部细节。
操作系统中的“同步信号量”）
求精是由N.Wirth最初提出的一种自顶向下设计策略，其主要思想是：
将某个宏观功能不断分解，逐步确定过程细节，直至用程序设计语言描述的算法实现为止。
抽象使得设计人员能够避开过早地陷入细节之中刻画过程和数据。
求精能够帮助设计人员随着设计过程的深入而不断呈现更低层次的信息。
如何确保模块数落在“最小代价区”？
依据什么标准划分模块？
由Parnas倡导的“信息隐藏”是指模块中所包含的信息（包括数据和过程）对不需要这些信息的其它模块是不可访问的。
抽象有助于定义组成软件的过程（或信息）实体；
隐藏定义并加强了对模块内部访问的约束，有助于分离模块的实现者和使用者。
模块独立性是模块化、抽象和信息隐藏的直接产物，其基本含义是每一个模块只完成功能需求中的一个特定的子功能，而且从程序结构的其它部分来看这一模块只具有一个简单的接口。
模块的功能独立性可以使得模块既容易开发又容易维护。
模块独立性有两个定性的度量标准：
内聚度和耦合度。
内聚度（Cohesion）是指模块内部各成分联系紧密的程度。
通常，内聚度越高，模块的独立性就越强。
G.Myers定义了七种类型的内聚，大致按照内聚程度从高到低的顺序是：
功能内聚、信息内聚、通信内聚、过程内聚、时间内聚、逻辑内聚和偶然内聚。
设计模块时，应该尽可能避免使用偶然内聚等低级内聚的模块，争取高级内聚的模块，以提高模块的独立性。
耦合（Coupling）是模块之间相互关联紧密的程度。
一般地，模块的耦合度越低，模块的独立性越强。
模块之间的耦合程度从低到高也可分为七种：
非直接耦合、数据耦合、标记耦合、控制耦合、外部耦合、公共耦合、内容耦合。
在设计模块时，应该尽量使用数据耦合，必要时使用标记耦合，少用控制耦合，限制使用公共耦合，最好不要使用内容耦合。
♦模块的扇出是指模块直接调用多少其它模块。
♦模块的扇入是指共有多个模块直接调用本模块。
♦模块的扇出过大，表明该模块过分复杂，需要协调和控制过多的下层模块。
♦模块的扇入过大，而它又不是公用模块，一般来说明该模块可能具有多个功能。
♦经验表明，良好的软件结构图，上层模快（主要是控制模块）往往具有较高的扇出，底层的模块（主要是功能型模块）具有较高的扇入，呈两头小、中间大的清真寺状。
模块的作用域是指模块中判定的作用范围，它是指所有受这个判定影响的模块。
模块的控制域是指模块本身及其直接或间接调用的模块。
如果模块的作用域不在控制域之内，则会增加模块间数据的传递量，使模块之间出现控制耦合。
升级会员 