您的当前位置:首页正文

软件工程笔记

2020-02-21 来源:好走旅游网
第一章 软件工程概述

1. 软件危机 (software crisis):是指在计算机软件的开发和维护过程中所遇到的一系列

严重问题。即“两低一高” 问题:质量低、效率低、成本高。

软件危机也成为“软件萧条(depression)”或“软件困扰(afflication)” 2. 软件危机主要表现

1)开发成本和进度估计不准

2)用户对“已完成的”软件系统不满意 3)软件质量往往靠不住 4)软件常常是不可维护的

5)软件通常没有适当的文档资料 6)软件成本逐年上升

7)软件开发生产率滞后于硬件和计算机应用普及的趋势 3. 产生软件危机的原因

1)与软件本身的特点有关

a. 软件不同于硬件,是逻辑部件而不是物理部件 缺乏可见性 难于测试

管理和控制开发过程困难

不会因使用时间过长而被“用坏” 难以维护

b.软件不同于一般程序,规模庞大,而且程序复杂性随着程序规模的增加而呈指数上

2)和软件开发与维护的方法不正确有关

a.对软件开发和维护有关的错误认识和作法 忽视软件需求分析的重要性 认为软件开发就是写程序 轻视软件维护

b. 对软件开发过程与方法的认识与应用

软件开发要经历一个漫长的时期(编程占10-20%) 程序仅是完成软件配置的一个组成部分 软件开发方法要有利于软件维护 4. 软件的特点

(1)软件是无形的(intangible) (2)软件副本的大批量生产轻而易举 (3)软件业是劳动密集型的

(4)一个没有经过充分训练的软件开发人员很容易编写出难以理解和修改的软件

(5)软件本身很容易修改。但由于它的复杂性,又很难正确地修改 。

(6)软件不像其他的工业产品那样会因使用而磨损,随着反复修改,它的设计会逐渐退化

5. 消除软件危机的途径

1)对计算机软件的正确认识

2)认识到软件开发不是个体劳动的神秘技巧,而是一种组织良好、管理严密、各类人员

协同配合、共同完成的工程项目 3)推广使用成功的软件开发技术和方法

4)开发和使用更好的软件开发工具 总之, 为了消除软件危机,既要有技术措施(方法和工具),又要有必要的组织管理措施。 6. 对“工程”的理解:大事情,施工的过程,工程学科。

施工的过程:分析设计 实现 维护 7. 软件的概念

经典定义:软件 = 程序 + 文档 + 数据

软件是计算机程序及其有关的数据和文档的完整集合。

计算机程序是能够完成功能的可执行的指令序列

数据是程序能适当处理的信息,具有适当的数据结构 软件文档是开发、使用和维护程序所需要的图文资料

8. 软件工程的概念

概括地说,软件工程是指导计算机软件开发和维护的工程学科。

采用工程的概念、原理、技术和方法来开发与维护软件,把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来,以经济地开发出高质量的软件并有效地维护它,这就是软件工程。

目标:项目成功(BFC,Better、Faster、Cheaper) 9. 软件工程的本质特征

(1)软件工程关注于大型程序的构造 (2)软件工程的中心课题是控制复杂性 (3)软件经常变化

(4)开发软件的效率非常重要 (5)和谐地合作是开发软件的关键 (6)软件必须有效地支持它的用户 (7)在软件工程领域中通常由具有一种文化背景的人替具有另一种文化背景的人创造

产品

10. 软件工程的基本原理

(1)用分阶段的生命周期计划进行严格管理

(2)坚持进行阶段评审 (3)实行严格的产品控制 (4)采用现代程序设计技术 (5)结果应能清楚地审查

(6)开发小组的人员应该少而精

(7)承认不断改进软件工程实践的必要性 11. 软件工程方法学

通常把在软件生命周期全过程中使用的一整套技术的集合称为方法学(methodology),也称为范型(paradigm)。

1) 传统方法学(结构化方法学):SA,SD,SP,ST 2) 面向对象方法学:OOA,OOD,OOP,OOT S:结构化,structured

OO:面向对象,Object Oriented A:分析,Analysis D:设计,Design

P:编程,Programming T:测试,Test

12. 软件工程方法学三要素,这就是方法、工具和过程。其中:

1)方法是完成软件开发任务的技术方法,回答“如何做”的问题; 2)工具是为方法的运用提供自动的或半自动的软件支撑环境;

3)过程规定了完成各项任务的工作阶段、工作内容、产品、验收的步骤和完成准则。

第二章 软件过程

1. 过程(process):ISO9000把过程定义为,把输入转化为输出的一组彼此相关的资源和

活动。

2. 软件过程(Software Process): 是为了获得高质量软件所需要完成的一系列任务的框架

(Framework),它规定了完成各项任务的工作步骤。 3. 软件生命周期

软件生命周期由软件定义、软件开发、和运行维护三个时期组成,每个时期又可进一步划分成若干个阶段。(三个时期八个阶段) 三个时期八个阶段:

三个时期:软件定义、软件开发、运行维护 八个阶段:(1)问题定义 (2).可行性研究 (3).需求分析 (4).概要设计 (5).详细设计 (6).编码和单元测试 (7).综合测试 (8).软件维护 4. 软件开发模型(在课本的14—33页,了解一下)

1) 瀑布模型 (Waterfall) 2) 快速原型模型Prototype

3) 增量模型(Incremental Models) 4) 喷泉模型 5) 螺旋模型

6) 统一过程(rational unified process,RUP) 7) 敏捷过程

8) 极限编程(extreme programming,XP)

9) 能力成熟模型(capability maturity model,CMM)

第三章 结构化的分析(SA)

1. 需求分析:发现、求精、建模、规格说明、复审的过程。 发现:获取需求,完备、正确、有效 求精:细节

建模:形式化描述

规格说明:详述 复审:批准 2. 需求分析的准则

1) 必须理解和表示问题的信息域,根据这条准则应该建立数据模型。 2)必须定义软件应完成的功能,这条准则要求建立功能模型。

3)必须表示作为外部事件结果的软件行为,这条准则要求建立行为模型。 4)必须对描述信息、功能和行为的模型进行分解,用层次的方式展示细节。

3. 需求获取的方法 1) 访谈

正式的:事先准备好的

非正式的访谈:开放的,头脑风暴,情景分析 2) 面向数据流自顶向下求精 3) 简易的应用规格说明技术 4) 快速建立软件原型 4. 分析建模

结构化分析实质上是一种创建模型的活动。

通过需求分析而建立的模型必须达到下述的三个基本目标:

描述用户的需求。

为软件设计工作奠定基础。

定义一组需求,一旦开发出软件产品之后,就可以用这组需求为标准来验收该产品。

5. 模型(Model):是为了理解事物而对事物作出的一种抽象,是对事物的书面上的无歧义

文字或图形的描述.

5.1. 模型是对问题的简化。 5.2. 要从多个角度认识事物。

6. 分析模型: 数据模型(实体联系图)、功能模型(数据流图)、行为模型(状态转换图)。

7. 需求分析成果:软件需求规格说明

8. 实体-联系图(ER图,entity-relationship diagram)(P41,要求会画)

(1)数据模型的主要成分:数据对象,数据对象的属性,数据对象彼此间相互连接的关系

数据对象:对软件必须理解的复合信息的抽象。

属性:定义了数据对象的性质。

联系:数据对象彼此之间相互连接的方式称为联系,也称为关系。

类型:一对一联系、一对多联系、多对多联系。联系也可以有属性。

(2)实体-联系图的符号表示: 实体

属性

联系

9. 数据流图(DFD,Data Flow Diagram):描绘信息流和数据从输入移动到输出的过程中

所经受的变换

(书本P43—47,要会画)

10. 数据字典(DD:,Data Dictionary):是关于数据的信息的集合,是对数据流图中包含

的所有元素的定义的集合 (书本P49—51,要会画)

11. 状态转换图(SD,State Diagram):通过描绘系统的状态及引起系统状态转换的事件,

来表示系统的行为。用于建立行为模型。

状态:是任何可以被观察到的系统行为模式。状态规定了系统对事件的响应方式

事件:是在某个特定时刻发生的事情,是引起系统做动作或(和)转换状态的控制信

息。

(书本P47—49)

第四章 结构化设计

性能 DFD 环境 功能 将来 分析 设计 过程 ERD DD 数据 STD 接口 ( 五大需求) 架构 数据 (四大设计) 内存 DS 数据 DB 外存

file 架构 C/S,B/S 四大设计 构件之间的接口 接口

人—机 接口 Process 过程

Procedure(步骤) 三型两化

行为模型 三型 功能模型 数据模型 系统化 两化 层次化

如何设计:必须依据原理、原则、规则、准则

模块:是由边界元素限定的相邻的程序元素的序列,而且有一个整体标识符来代表它。 模块化:就是把程序划分成可独立命名且独立访问的模块,每个模块完成一个子功能,把这

些模块集成起来构成一个整体,可以完成指定的功能满足用户的需求。

(1) 一组相邻元素 (2) 一个边界

(3) 一个名字(标识符ID)

Why模块化

1) 降低复杂度

2) 有利于团队分工协作 How to 模块化

Meyer模块化5标准

1) 模块可分解性(降低复杂性) 2) 模块可组装性(可重用,reuse) 3) 模块可理解性(易于维护) 4) 模块连续性(副作用小) 5) 模块保护性(屏蔽异常) 抽象(abstract):抽出事物的本质特征,而暂时不考虑它们的细节 找共性,略特性

抓主要,略次要 有效降低模块数量

逐步求精:为了集中精力解决主要问题而尽量推迟对问题细节的考虑。 大 小 粗 细

Miller法则:一个人在任何时候都只能把精力集中在7±2个知识块上。

7±2

全局变量

信息隐藏

局部变量

块内:高内聚,一个模块只做一件事 模块独立

参数少 块间:低耦合,KIS(keep it simple) 类型简单 结构化设计原理:

1) 模块化 2) 抽象 3) 信息隐藏 4) 逐步求精

启发原则:

1) 改进软件结构提高模块独立性

2) 模块规模应该适中(LOC<30)LOC:lines of code note>code 3) 深度、宽度、扇出和扇入都应当适中 (7±2原则) 4) 模块的作用域应该在控制域之内

5) 力争降低模块接口的复杂度(接口KIS) 6) 设计单出口单入口的模块 7) 模块的功能应该可以预测

设计结果描述工具:建模工具 软件工具 工具 建模工具 开发工具

IPO图(Input Process Output):描述模块(总体)

架构表示:C/S,B/S ,层次

层次图 + IPO图 = HIPO图 结构图:(P76)

Yourdon提出的结构图是进行软件结构设计的另一个有力工具

面向设计流的设计方法 三种设计方法 面向数据结构的设计方法 面向对象的设计方法 设计优化:

无 有 好 优 精

人—机界面设计问题

MI CUI GUI AUI MMI

1. 系统响应时间(长度、易变性)

集成式(内含,开始就设计在软件中) 2. 用户帮助措施 嵌入式/附加式(联机文档)

1) 完备性

2) 选择性(menu, F1 , help) 3) 如何显示帮助信息

4) 返回/退出(ESC escape , 按钮) 平面

5) 怎样组织帮助信息 层次结构(导航) Web页(超链接) 3. 出错信息处理 1) 可理解性 2) 建设性 3) 警示性 4) 视听性 5) 友好性 4. 命令交互

UI设计的重要性:

1) 用户评价产品的依据 2) 占总设计量的50%以上

3) 涉及到美学、人—机工程学、心理学 4) UI工程师成为一种岗位 UI设计原则:

以人为本、人性化、美、方便 和谐 美 一致 对称

人—机界面设计过程:

用户界面设计是一个迭代的过程 建模(UML的状态图)

建立原型(powerpoint,dreamvever) 试用

评估

界面设计指南(看看微软的界面设计)

1) 一般交互 2) 信息显示 3) 数据输入

结构化方法学

SA SD SP ST

1965

GOTO语句 1968 (书本P89) 1972

如果一个程序的代码块仅仅通过顺序、选择和循环这三种控制结构进行连接,并且每

一个代码块只有一个入口和一个出口,则称这个程序是结构化的。

1) 顺序

2) 选择(单路、双路、多路、多重)

3) 循环(for 、 当型循环、直到型循环、枚举)

过程设计工具

程序流程图

N-S盒图 图

PAD图 UML活动图 判定树

判定表 表 伪码语言 语言

(要会画这些图,会根据伪码语言转化为上述各种图,还要掌握几种图之间的转换)

数据的三类逻辑结构

1) 顺序 2) 选择 3) 重复

第五章 结构化实现

测试

定义:为了发现错误而执行程序的过程 错误 编写时产生的

故障 运行时发生的

测试具有破坏性,而其它的环节都是建设性的。但是其破坏时为了更好的建设,保证质

量的有效途径

测试的目标()

1) 定义:测试是为了发现程序中的错误而执行程序的过程

2) 好的测试:好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案 3) 成功的测试:成功的测试是发现了至今为止尚未发现的错误的测试

目的 测试方案 一组输入

一组输出(预期的结果) 测试的准则

1) 追溯到需求:所有的测试都应该能追溯到用户的需求

2) 及早计划:应该在测试之前的相当长时间,就指定出测试计划

3) 2、8定律:把Pareto原理应用于软件测试。Pareto原理告诉我们,测试发现的

错误中的80%很可能是由程序中20%的模块造成的

4) 从小到大:测试应该从“小模块”开始,并逐步进行“大模块”测试 5) 不可穷尽:穷举测试是不可能的

6) 第三方(丙方)测试:为了达到最佳的测试效果,应该由独立的第三方来从事测

试工作

所谓最佳效果,就是指最大可能性发现错误的测试,这也是测试的基本目标

黑盒测试:接口处、功能测试 测试方法

白盒测试:结构测试

流图P110(要会根据程序流程图转化) 体现了程序判断的节点

白盒测试技术:

1) 逻辑覆盖 2) 路径覆盖

程序的复杂度度量(P115,要会根据流图,计算出程序的复杂度) 流图中的区域数 = 环形复杂度

3种方法 流图中的环形复杂度 = 流图中的边数 – 图中节点数 + 2 流图中的环形复杂度 = 图中判定节点的数目 + 1

复杂:指人的体力和脑力受到挑战 独立路径(P115)

定义:是指至少引入程序的一个新处理语句集合或一个新条件的路径 自顶向下 找法 从左向右 逐步增加

黑盒测试技术(P120) 等价类划分 边界值分析 错误预测

测试步骤(从小到大)

单元 子系统 系统 验收 平行运行

集成测试 一边运行新系统,一边运行旧系统

集成测试的策略 深度优先 自顶向下 宽度优先 自底向上

软件的可靠性

可靠性:时间段,在规定的时间段内,成功运行程序的概率 可用性:时间点,在一个时间点上,成功运行程序的概率 MTTF:Mean Time To Failure,平均无故障时间 MTTR:Mean Time To Repair,平均维修时间

测试

发现bug 质量 排除bug

可靠性

第六章 面向对象方法学导论

面向

观点、世界观、软件观

System

1) 若干部件的集合

2) 部件具有独立的功能和边界

3) 部件之间具有相互联系,这些联系构成结构 4) 部件间相互作用,构成运动

对象(P151)

在研究或解决问题的过程中关注的人、事物、概念

OO(Object Oriented,面向对象)起源 学习、掌握、运用

面向对象方法学的四个要点:

面向对象 = 对象 + 类 + 继承 + 通信

1) 认为客观世界是由各种对象组成的,任何事物都是对象,复杂的对象可以由比

较简单的对象以某种方式组合而成

2) 把所有对象都划分成各种对象类,每个对象类都定义了一组数据和一组方法。 3) 按照子类与父类的关系,把若干个对象类组成一个层次结构的系统 4) 对象彼此之间仅能通过传递消息互相通信

面向对象方法学的优点

1) 与人类习惯的思维方法一致 2) 稳定性好 3) 可重用性好

4) 较易开发大型软件产品 5) 可维护性好

面向对象的一些概念

1. 对象:是封装了数据结构以及可以施加在这些数据结构上的操作的封装体,这个封装

体有可以唯一标识它的名字,而且向外界提供一组服务。 2. 类:就是对具有相同数据和相同操作的一组相似对象的定义 3. 实例:就是有某个特定的类所描述的一个具体的对象

4. 消息:就是要求某个对象执行在定义它的那个类中所定义的某个操作的规格说明书 5. 方法:就是对象所能执行的操作,也就是类中所定义的服务

6. 属性:类中说定义的数据,它是对客观世界实体所具有的性质的抽象 7. 封装:就是把某个事物包起来,使外界不知道该事物的具体内容 8. 继承:是指能够直接获取已有的性质和特征,而不必重复定义他们

9. 多态性:是指子类对象可以像父类对象那样使用,同样的消息既可以发送给父类也可

以发送给子类对象。 10. 重载:函数重载是指在同一作用域内的若干个参数特征不同的函数可以使用相同的函

数名字

面向对象的三种关系:

继承 组成 关联 父类 (这个箭头是空心的) 子类 子类

对象的特点:

(1) 以数据为中心 (2) 实现了封装

(3) 本质上具有并行性 (4) 模块独立性好

面向对象建模:

功能模型 三种模型的建模工具: 对象模型:类图

功能模型:用例图(用况图) 类 动态模型:状态图,时序图 对象模型

动态模型

(面向对象模型)

面向对象的建模步骤:

系统观点 啥们

UML的9种图

对象模型:最基本、最核心、最重要

状态图:

描述了单一对象,在其生命周期内的变化规律 事件event 瞬间的 状态 时间段

时序图:

多个对象的交互。时序图的每个对象有各自对应一个状态图

第7&8章

九个图 九个图 分析 设计

For 人 for计算机

3型5层 (课本的p166) 对象模型 3型 功能模型 动态模型

自顶向下 5层 逐步求精 啥们之序

面向对象(OOA)的任务与过程

分析:搞清楚、弄明白软件的需求,并根据需求建模

研究需求

识别对象

建立模型

面向对象分析的策略:

三型五层:自顶向下、逐步求精

五层:主题层、类与对象层、结构层、属性层、服务层

需求陈述P167

用户提供、表现多样 内容:范围、需求、假设 问题:歧义、矛盾

对策:甲乙共商 ,原型化需求

架构成中心用况驱动 增量与迭代 例子 ATM (课本P167)

建立对象模型

类:名词

a kind of 关系: part of

….. with ……

词法分析 属性:量词(重量、身高、年龄)、形容词 方法:动词

候选 筛选 确定 优化

UC矩阵 user customer

建立动态模型

顺序图 状态图 (多对象) (单一对象) 需求陈述

编写脚本

画顺序图

案例研究:电梯系统(课本的P186——P190)

OOA OOD OOP (3型4图) (3型4图)

for 需求 for 机器/实现

3型4图:

对象模型 类图 功能模型 用例图

动态模型 顺序图、状态图

OOD(面向对象设计)准则:P192

1. 模块化 2. 抽象 3. 信息隐藏 4. 弱耦合 5. 强内聚

6. 可重用

启发规则:

1. 设计结果应该清晰易懂

2. 一般/特殊结构的深度应适当 3. 设计简单的类 4. 使用简单的协议 5. 使用简单的服务 6. 把设计变动减至最小

第9章(老师没讲)

第10章UML(P232)(自己看,一定要会画9种图)

第11章 计划

管理:

就是通过计划、组织和控制等一系列的活动,合理的配置和使用各种资源,以达到既定目标的过程。

软件项目管理:就是通过计划、组织、控制等一系列的活动,合理的配置和使用各种资源,

以便在预定成本和期限内开发符合客户需要的软件的过程

(类)工程:大的、复杂的、由众多人一起完成的 (对象)项目:一个具体的工程是项目

人 财 估量 工作量 物 (代码行) 时

软件配置:程序、文件、数据

对软件的配置进行管理的原因:需求的变更是不可避免的

风险(risk):导致失败的因素 识别

评估

避免

估算代码行:

估 概 预 决

代码行 LOC KLOC 估算量

功能点 FP(function points)

FP技术:(具体的计算方法P253)

程序量 工作量 进度 (KLOC FP) (人月) (人员)

人月神话 Brooks

1. 劳动密集型 2. 智力VS体力

工作量(课本的P254) E=f (KLOC) E=f (FP)

静态单变量模型 三种方法 动态多变量模型 构造性成本模型

进度计划:

分解,分而治之; 大事化小,小事化了

P254---P264要精读

指导软件项目进度安排的基本原则:

1. 划分

2. 相互依赖性 3. 时间分配 4. 工作量确认 5. 定义责任 6. 定义结果

7. 定义里程碑

工程网络图(P260——P262):

要掌握的内容:最早时刻、最迟时刻、最短路径、关键路径、关键事件

第13章 控制

软件风险的特点:

1. 不确定性 2. 损失

软件风险的分类:

1. 按风险的影响范围分类:

(1) 项目风险 (2) 技术风险 (3) 商业风险

2. 按风险的可预测性分类:

(1) 已知风险 (2) 可预测风险 (3) 不可预测风险

风险因素:性能风险、成本风险、支持风险、进度风险 (P280 表)

质量:满足用户需求的程度

软件质量:软件与明确规定地和隐含地定义的需求相一致的程度

质量保证很重要:

1. 召回 2. 市场占有 3. 生命力

质量保证: Test 文档 管理

审查、复查

规则、原则、准则

质量因素:

哪些方面 如何度量

3方面13因素(3方13条)(P283,图)

软件质量因素的定义(P284 表) 可 XX性:XX 的难易程度。

软件质量保证措施:P(284)

1) 技术复审 2) 走查 3) 审查 4) 测试

软件配置管理 变更

版本(version)

这些管理基于软件的本质特征:演化性、构造性

软件配置发生变化的原因:

1) 新的商业或市场调件导致产品需求或业务规则变化

2) 新的客户需求,要求改变信息系统产生的数据、产品提供的功能或系统提供服务 3) 企业改组或业务缩减,引起项目优先或软件工程队伍结构的变化 4) 预算或进度限制,导致对目标系统重定义

5) 发现了在软件开发过程前期阶段所犯的错误,必须及时改正

基线(base line)P187

软件配置管理过程

1) 标识软件配置中的对象 2) 版本控制 3) 变化控制 4) 配置审计 5) 状态报告

因篇幅问题不能全部显示,请点此查看更多更全内容