软件工程复习 WHUT

软件过程模型：

瀑布模型：界限分明的独立阶段，计划驱动的软件过程、规范软件开发活动

（例如：可分为分析、开发、维护三个阶段） 也称生命周期模型、线性模型，采用结构化分析、设计、编程技术

不足的地方：知道后期才可得出可用的系统，用户最初说不清楚需求

原型化模型：部分开发的产品，对于系统增强，适用于需求明确 选择可行的策略

快速原型法：适用于需求不明或易变的系统（用户驱动）

建立原型的目的是分析用户需求，评估关键技术，战士新概念和方法

如何建造原型呢？ 分清主次 快速开发

从原型走向产品：抛弃式原型、演化式原型、垂直原型、水平原型。

迭代式开发：描述、开发、验证交织在一起，建立一系列版本，逐步交付

制定计划、风险分析、实施工程、客户评估

可转换模型：利用自动化手段，将需求规格说明转化为可交付使用的系统

阶段化开发中有增量模型和迭代模型

增量模型：每一次发布都出新功能，直到功能构造完全

迭代模型：一开始提交整个系统，后续打补丁

敏捷式开发方法：

快速高质量的开发软件产品新型方法，强调更紧密的团队协作

软件过程的总结：

1、 开发软件需要的规范流程是什么？

问题定义-需求开发-软件设计-软件构造-软件测试

2、 规范流程的结构框架有哪些？

瀑布模型、袁兴华模型、迭代式开发、可转换模型

3、 当前流行的开发流程框架？

敏捷式开发模型

不是可行性分析的内容：质量可行性

每个阶段增加风险分析的快速原型是：螺旋模型

增量、迭代模型有区别，增量模型其实是一种非整体开发模型

快速原型开发模型适用于需求不清楚的情况

考虑开发语言不属于需求开发活动

抛弃式原型适合需求不确定不完整的项目

维护是周期花费最多的阶段

需求工程

什么是软件需求？为什么说需求很重要？

软件需求分几类（功能、性能、技术限制、其他限制）：

能做什么？做的有多好，可靠性？指定平台、数据库、开发工具、经济、时间、法律

需求的三个层次是什么？

业务需求、用户需求、功能需求

需求工程=需求开发+需求管理两者的区别？

各阶段的任务是什么？

需求分析员必备知识和技能

项目实践经验、软件工程、需求分析、产品市场、业务领域知识

技能：倾听、提问、协调、剑魔、写作、创造、组织、观察、交流

非功能性需求及其描述

隐藏需求

可行性分析是确定能否有可行的方案，比较粗略，细节被忽略

需求获取：需要人为主动捕捉，有多种方式结合内外部渠道获取用户需求

技巧：问卷调查、文档考古、面谈、用户调查、场景分析、大数据分析、原型法

需求记录：文字、UML（用例图、状态图、顺序图）、数据流图、层次方框图、IPO图

需求分析：用户需求转化为产品需求，并确定产品需求的基本属性、商业价值（最关键，老板要赚钱）、实现难度、性价比。商业价值还要衡量其重要性和紧急性

性价比=商业价值÷实现难度（简化为开发量）

需求处理：需求加减法，少数用户需求减掉，小步快跑、快速迭代

需求文档撰写：

需求规格说明书：要完整详细地描述系统各项特性

对于开发者 详细 不能有歧义

对于用户 好理解不能技术化

法律上 有验收标准

需求确认 对说明书做出承诺，有商业合同的效果

需求管理：需求实现 需求跟踪 需求变更控制（按规范处理需求变更）

需求变更控制：基本流程 变更申请-评估/审批-更改-重新确认

需求工程分为需求开发狗偶成和需求管理过程

需求获取、需求分析、需求处理、需求确认

业务需求表示组织或客户高层次目标

用户需求是用户要求必须完成的任务

功能需求是产品必须实现的软件功能

从业务需求（量化描述需求、有数据）+用户需求->功能需求

对象模型

面向对象程序设计

OO（面向对象）是以对象为中心的思维方式

对象=算法加数据结构

程序=对象1+对象2+对象3……

对象就是一个独立存在的客观事物  由属性和操作构成 属性：静态特征 操作：动态特征

OO编程方法特性：

有点 ：易维护、质量高、效率高、易扩展

缺点 ： 运行效率会下降10%左右

面向对象基本特征：抽象、封装和数据隐藏、集成、多态

不关心内部如何实现，只关心如何使用功能

OO技术利益

复用性：代码重用、类库、框架重用

减少编制新的系统代码、通过集成关联封装手段实现新的功能

较小的需求变化不会对系统结构有大的改变

习题：OO技术基本特征包括封装、多态性、和继承性

OO系统具有高内聚低耦合特征

面向对象的设计将事物的数据和对数据的操作封装为一体

UML标准的形成标志着OO分析与编程的软件开发方法成为主流

可视化建模与UML

UML是建模内容的表达，他是一种语言

UNL是统一建模语言 Unified Modeling Language

UML特点：

同意了面向对象方法的表示、与开发过程无关、允许扩展、不涉及语法、可用OOP语言框架

对整个系统来说

功能-用例图 静态结构-类图&对象图

动态行为-状态图&顺序图&协作图&活动图

物理架构-构件图&部署图

用例图：定义系统功能需求，从外部看系统功能，不描述具体实现

类图：描述系统的静态结构 表示类以及类之间的关系

状态图（行为图）：强调对象行为的时间顺序 是对类的补充 表示状态转移

活动图（行为图）：从一个活动到另一个活动的流程 强调控制流程

顺序图&协作图 一组对象之间的写作关系，。顺序图反应时间熟悉怒，协作图反应收发消息的对象的结构组织
顺序图和协作图同构，可以相互转换

构件图：

构件图描述程序代码的组织结构 构建以及他们之间的依赖关系 表示系统的静态实现试图

部署图：反映系统中软件和硬件的物理架构，标识系统运行时的处理节点以及节点中构建的配置

用例图的作用：描述开发系统的功能需求和系统使用场景，知道软件测试人员进行测试，验证与确认系统的需求

用例图的组成：系统（系统边界）参与者（执行者，活动者，Actor）、用例（Use Case）、关系（Relationship）、用例描述

四种关系：

关联描述参与者和用例之间的关系 箭头指向谁就调用谁

包含：1个用例之间的关系基本用例行为包含了另一个用例

执行基用例时 必须执行被包含用例 被包含用例也可以单独执行

扩展：一个用例可定义为基础用例的增量扩展 成为扩展关系

扩展关系是把新行为插入到已经拥有的用例中的方法 一般基础用例不会涉及扩展用例，特定条件下才会被执行

泛化：一个用例和几种情形的用例间构成泛化关系

往往父用例为抽象用例

用例图E.G.

对用例描述有两种方法：1、用例图 2、用例描述

用例图并不描述软件的特性，不反应功能的不同抽象层次

用例关系包括泛化、包含、扩展

参与者类型不包括交互对象

活动图、用例图、顺序图描述系统动态行为

类图的抽象层次：

概念类 仅包含类名，不考虑细节

分析类 分析不针对具体语言 包含一些类的细节特性

设计类 针对具体的语言 考虑实现细节

类图中的关系：

泛化关系：是从特殊元素到一半元素的分类关系

E.G.：

关联关系一般使用连接两个类的关联先表示，。

关联有多种形式，可以自我关联

关联关系中包括聚合关系和组合关系

部分与整体             组合关系是更强形式的关联

组合和聚合的适用情况：组合和部分 容器和内容 集合和成员

实现关系：类和被类实现的接口 协作、被协作实现的用例都是实现关系

依赖关系：一个雷的实现需要另外一个类的协助 劲量不要使用双向的互相依赖

如何设计模型与用例模型？

用例模型只是外观的表现  宏观的功能，而类图主要画内部结构
交互图主要是画内部的行为

1、 边界类，完成系统与参与者之间的交互

通过用例图得到边界类至少与一个参与者有关，参与者类型不同 设计也不同

边界类包括屏幕串口、通信接口、…..

2、 识别边界类：根绝用例图
每个参与者与一个用例交互 必定找到一个边界类

3、 实体类：是一个软件对象，将实体类反应的信息在系统中处理并存储

边界类仅负责数据的交互 不承担数据逻辑处理

举个栗子

4、 控制类：协调、排序、事务处理、对其他对象的控制，控制类不封装与参与者交互有关的额内容，也不封装与系统处理的长效持久的信息有关的问题E.g.

不同类的职责分配：边界类-控制类-实体类

如果部分和整体具有统一的生命周期 则两者之间的关系成为组合关系

类间关系：泛化=实现>组合>聚合>关联>依赖

泛化（继承）

子类继承父类，父类泛化子类

实现（接口类，为了多态）

类与接口的关系，代表类实现了接口的所有属性和方法

组合

对象可以控制成员对象的生命周期 （成员对象不可脱离整体对象存在）

聚合

成员对象是整体对象的一部分 但成员变量也可脱离整体独立存在

关联

将一个类的对象作为另一个类的成员变量

依赖

某个类的方法使用另一个类的对象作为惨数

部分与整体统一生命周期----组合关系

计算机由CPU、内存、硬盘等构成 计算机类和鼠标类为—聚合关系

什么是顺序图？

顺序图展示几个对象之间的动态关系，系统之行的某一特定时间所发生的事

纵向为时间轴，横向为独立对象的类元角色 各个角色活动由生命线表示

顺序图元素：对象、类、参与者

创建、删除对象 ：发送消息来创建另一个对象 若要删除 就可以在对象生命线底部打叉

顺序图作用：

业务人员对交流当前业务如何进行有用，可作为需求文件使用

对于需求分析人员，顺序图可通过提供一个深层次的表达吧用例带入下一层次

对于技术人员，记录未来系统的行为如何表现有用，挖掘系统对象间的交互。

创建顺序图以用例为单元 一个用例就是一张图 要表示出每个用例需要的功能 调用对象的操作参与执行的步骤需要详细写出

若需要考察单个用例内部多个对象的行为 可以使用顺序图

如果需要考察单个对象的行为就需要使用状态图

如果考察跨用例或者跨线程行为就需要考虑使用活动图