概述
这一模块选择题的分值比较多,案例题和论文也有能用上的地方。主要知识点会特殊标注或说明。
软件开发生命周期
软件工程三要素:方法、工具、过程。不会直接考,但可帮助记忆理解。
-
传统软件生命周期方法学分为:(选择题)
- 软件定义
- 软件开发
- 软件运行与维护
-
软件定义分为:(了解)
- 问题定义:目标系统是什么,系统的定义与范围。
- 可行性研究:技术、经济、操作、社会方面的可行性。
- 需求分析:功能(基础)、性能(安全可靠可维护精度容错响应速度适应性)、环境约束(软件硬件)。
-
软件开发分为:(选择题)
- 概要(总体设计):系统总体结构、子系统划分、模块间关系
- 详细设计:模块逐步细化,数据的结构,分布,组织,接口,界面等。
- 编码:可运行程序
- 测试:单元、集成、确认、系统测试。
-
软件运行和维护:(了解)
- 交付使用
- 对产品和需求的修改做出响应
软件开发方法
软件开发方法分类
开发风范
- 自顶向下:将一个大问题分化为多个可以解决的小问题。
- 自底向上:从具体的器件、逻辑部件或者相似系统开始,需要开发者富有经验技巧
性质
- 形式化:基于严密的,数学上的形式机制的计算机系统研究方法。
- 非形式化:各种开发模型
非形式化开发
结构化开发方法
将一堆零件按规则逻辑组织起来,变成一辆汽车,汽车就是结构化的结果。其中的规则逻辑,就是结构化思维。
- 开发目标清晰化
- 与用户保持沟通,用户了解工作进展,校准工作方向。
- 开发工作阶段化
- 每个阶段完成后评审,便于项目管理与控制
- 开发文档规范化
- 每个阶段生成文档,保证系统维护工作的便利
- 设计方法结构化
- 自顶向下分解,分析设计,实现模块
缺点:开发周期长,难以适应需求变化,很少考虑数据结构
- 自顶向下分解,分析设计,实现模块
面向对象方法
对象就是站在某个角度,某个个体具有属性和操作,那么这个个体就是对象。
比如:在汽车驾驶员的角度看车这个个体关心的一些状态和操作。在驾驶时,关注的状态大概有车速、转速、剩余的油、胎压等等,这些属性状态都可以用数字来表示。除了这些属性之外,还有具体的操作,刹车、油门、转向灯开关等等。这些是具体的动作,汽车会会有有相应的行为。状态就是属性,这些行为就是方法。两个加起来就是一个对象。不同的车,属性都是类似的,把这些类似的属性和方法提取出来,就变成了类。
面向对象方法的类别
类别 | 说明 |
---|---|
Coad/Youedon方法 | 特别强调OOA和OOD采用完全一致的概念和表示法,使分析和设计之间不需要表示法的转换 |
Booch方法 | 分为动态模型和静态模型,静态模型分为逻辑模型和物理模型,描述系统构成和结构。动态模型包括状态图和顺序图,表示交互过程 |
OMT方法 | 建模思想,采用对象模型(对象图)、动态模型(状态图)、和功能模型(DFD)建立一个实际的应用模型 |
OOSE | 使用用例,取代DFD需求分析和建立功能模型 |
构件化开发方法
构件/组件是同一个概念,通过连接件连接在一起共同构成一个系统整体
构件与对象的关系
- 构件
- 独立部署单元
- 作为第三方的组装单元
- 没有外部可见的状态
- 对象
- 一个实例单元具有唯一标志
- 可能具有状态,状态外部可见
- 封装了自己的行为和状态
构件并非一定包含类,一个类元素只能属于一个构件。这样设计的好处是,构件与构件之间不会互相影响。
- 类/对象之间的通过消息来交互,当多个类组合完成完整的功能时,可以成为一个构件
- 构件与构件之间通过接口来进行交互
构件的获取
- 从现有构件中获得符合要求的构件,直接使用或做适应性修改,得到可复用的构件。
- 通过遗留工程,将具有潜在复用价值的构件提取出来,得到可复用的构件。
- 从市场上购买线程的商业构件。
- 开发新的符合要求的构件。
构件的分类
- 关键字分类法:将应用领域的概念从抽象到具体的顺序逐次分解为树形或有向无回路图的结构,每个概念用一个描述性的关键字表示。
- 刻面分类法:定义若干刻画构件特征的“刻面”,包含若干概念,这些概念描述构件在概念上的特征。
- 超文本方法:检索者可以任意跳转。
构件复用方法
- 检索与提取构件
- 理解与评价构件
- 修改构件
- 构件组装
检索分为
- 基于关键字的检索
- 刻面检索法
- 超文本检索法
面向服务的方法
将构件进一步扩展为服务,过载服务总线上为客户提供服务。
例如:电子商城中,订单管理系统,用户管理系统,物流系统等等变成服务,通过网页服务统一为用户提供服务。
抽象级别
- 操作:最底层,如读、写等操作
- 服务:代表操作的逻辑分组,如将读写,开关作为文件IO服务
- 业务流程:最高层,为了实现特定的业务目标而执行的长期运行的动作或者活动。
原型方法
也称为快速原型法,根据初步需求快速建立系统模型,与用户交流,主要用来确定需求。
按照实现功能划分
- 水平原型:界面,用来细化需求,但无实际的功能。
- 垂直原型:结构化原型,用于复杂算法的实现,实现了部分功能
按照最终结果划分
- 抛弃式:探索,解决需求不确定性,二义性等
- 演化式:逐步演化为目标系统,用于易于升级和优化的场合
敏捷开发
以人为核心、迭代、循序渐进。两个特征
- 适应性而非预设性:重型方法试图对一个软件开发项目在很长的时间跨度内做出详细的计划,然后依计划开发。这类方法在计划制定完成后拒绝变化。而敏捷开发欢迎变化。
- 敏捷型方法是面向人的而非面向过程的:它们试图使软件开发工作能够利用人的特点,充分发挥人的创造性,强调开发应该是一项愉快的活动。
核心思想
- 敏捷方法是适应性,而非可预测性
- 敏捷方法是以人为本,而非以过程为本
- 迭代增量式的开发过程
主要内容:四个核心价值观,12条过程实践规则
沟通 | 简单 | 反馈 | 勇气 |
---|---|---|---|
设计者、开发者和客户三者之间的有效交流是开发成功的关键 | 是设计和编码的指导原则,强调只满足当前功能需求,尽量使代码简单化 | 强调设计者、开发者和客户之间及时和详尽的意见反馈是开发成功的保证 | 要求设计者和开发者在必需做出取舍或重构时,勇于抉择,勇于实践 |
实践类型 | 内容 |
---|---|
计划游戏 | 快速制定计划、随着细节的不断变化而完善 |
小型发布 | 系统的设计要尽可能早的交付 |
隐喻 | 找到合适的比喻传达信息 |
简单设计 | 只处理当前的需求,使设计保持简单 |
测试先行 | 先写测试代码,然后再编写程序 |
重构 | 重新审视需求和设计,重新明确的描述它们以符合新的和现有的需求 |
结对编程 | 两个程序员在一个计算机上共同工作。一个输入代码,而另一个审查 |
集体代码所有制 | 开发人员轮换完成系统不同领域中不同模块的不同任务。每个人都对程序负责 |
持续集成 | 可以按日甚至按小时为客户提供可运行的版本 |
每周工作四十个小时 | 保证工作质量 |
现场客户 | 系统用户代表全程配合XP团队 |
编码标准 | 规范代码的编写 |
敏捷方法分类
- XP极限编程:高效,低风险,测试先行
- Cockburn水晶方法:**不同项目,不同策略。**水晶有很多个切面,每个切面都不同。
- SCRUM并列争球法:迭代。30天一周期。优先级
- FDD功用驱动方法:开发人员分类。指挥者、类程序员
- 开放式源码:虚拟团队,成员遍布各地
- ASD自适应方法:预测-协作-学习
SRUM并列争求法
- 产品待办列表
- 迭代待办列表
- 四周为一个周期
- 每日站立会议
- 迭代燃尽图
- 迭代复盘会议
开发模型
软件生存周期模型,又称软件开发模型,或软件过程模型。
软件过程模型的软件活动主要有:
- 软件描述
- 软件开发
- 软件有效性验证
- 软件进化
瀑布模型
缺点:现实软件需求很难确定,需要很长时间才能得到软件初始版本
- 上一次的开发成果作为本活动的输入
- 本次活动的输出成果输出给下次活动
- 对本次活动成果评审。成功继续下一项开发活动,否则返回上一项甚至更前
原型模型
原型模型使用应注意:
- 用户对系统模糊不清,无法准确回答目标系统的需求
- 要有一定的开发环境和工具支持
- 经过对原型的若干次修改,应收敛到目标范围内,否则可能失败
- 对大型软件来说,原型可能非常复杂且难以快速完成,如果没有现成的,就不考虑使用原型法。
螺旋模型
- 瀑布模型与原型模型的结合
- 适用于庞大、复杂并具有高风险的系统
喷泉模型
基于可重用的构件模型
RAD 快速应用开发
- 强调极短的开发周期
- 是瀑布模型的一个高速变种
- 通过使用基于构件的开发方法进行快速开发
基本思想
- 让用户更主动的参与到系统分析、设计和构造活动中来。
- 将项目开发组织成一系列重点突出的研讨会,研讨会要让项目投资方、用户、系统分析师、设计人员和开发人员一起参与
- 通过一种迭代的构造方法,加速需求分析和设计阶段
- 让用户提前看到一个可工作的系统
RUP 统一过程模型
- 将项目管理、业务建模、分析与设计等统一起来,贯穿整个开发过程。
- 四个顺序阶段:初始阶段、细化阶段、构建阶段、移交阶段
- 每个阶段安排评审,若满意进入下一阶段
- 采用迭代和增量的方式,好处如下:
- 在软件开发的早期就可以对关键的、影响大的风险进行处理
- 可以提出一个软件体系结构来指导开发
- 可以更好的处理不可避免的需求变更
- 可以较早的得到一个可以运行的系统,鼓舞开发团队的士气,增强项目成功的信心。
- 为开发人员提供一个能更有效工作的开发过程。
净室软件工程
有印象即可
-
净室软件工程(Cleanroom Sotfware Engineering)是一种形式化开发方法。
-
使用盒结构规约进行分析与建模
-
正确性验证排除错误
-
统计测试
-
质量控制
软件重用与逆向工程
选择题
软件重用
- 软件重用是指在两次或多次不同的软件开发过程中重复使用相同或相似软件元素的过程。
- 软件元素包括
- 需求分析文档
- 设计过程
- 设计文档
- 程序代码
- 测试用例
- 领域知识
- 可区分为
- 横向重用:指重用不同应用领域中的软件元素,例如数据结构、分类算法和人机界面构件等。
- 纵向重用:指在一类具有较多公共性的应用领域之间进行软件重用
逆向工程
选择题较多,案例题可能会出现
相关概念有:重构,设计恢复,再工程,正向工程。
- 重构(restructuring)。重构是指在同一抽象级别上转换系统的描述形式。
- 设计恢复(design recovery):设计恢复是指借助工具从已有程序中抽象出有关数据设计、总体结构设计和过程设计等方面的信息。
- 再工程(re-engineering):再工程是指在逆向工程所获得信息的基础上,修改或重构已有的系统,产生系统的一个新版本。
- 正向工程(Forward engineering):不仅从现有系统中恢复设计信息,而且使用该信息去改变或重构现有系统,以改善其整体质量。
逆向工程可以分为如下四个抽象层次
选择题、案例题常见
实现级别 | 抽象的语法树、符号表、过程的设计表 |
---|---|
结构级别 | 反映程序分量之间相互依赖关系的信息,如调用图、结构图、程序和数据结构 |
功能级别 | 反映程序段功能与程序段之间关系的信息,如数据和控制流模型 |
领域级别 | 反映程序分量或程序实体与应用领域概念之间对应关系的信息,如E-R模型 |
逆向工程的完备性可以用在某一个抽象层次上提供信息的详细程度来描述。抽象层次越高完备性越低,通过逆向工程恢复的难度越大。