软件工程复习总结

学科内容：

可行性研究：经济可行性、技术可行性、社会可行性。

软件工程的三要素：工具、过程、方法。

软件过程部分：

软件的生命周期：

?指软件孕育、诞生、成长、成熟、衰亡的过程

软件生命周期包括：定义、开发、维护。

定义包括：问题定义、可行性研究、需求分析。

开发包括：设计、编码、测试。

维护包括：运行维护。

?

?什么是软件过程模型？

?又称：软件开发模型/软件生命周期模型

?指软件生命周期内过程、活动和任务的结构框架

?

?过程模型是一个模型（需要进行具体定义和剪裁方可使用）

?过程模型是对不同过程的一种组织方式。

瀑布模型的优缺点：

优点

?可强迫开发人员采用规范的方法

?严格地规定了每个阶段必须提交的文档

?要求每个阶段的所有产品都必须经过质量保证小组的仔细验证

缺点

?无法解决软件需求不明确或不准确的问题；可能导致最终开发的产品不能真正满足用户需要

?瀑布模型比较适合开发需求明确的软件（极少的情况）

?不适应需求经常变化的软件开发

?开发早期存在的问题往往要到交付使用时才发现，维护代价大

瀑布模型的特点：

阶段间具有顺序性和依赖性、推迟实现的观点（目的是什么？）、质量保证的观点（怎样实现的？）、只适用于极小型的项目！（为什么？）

瀑布模型的精髓和内涵：

精髓：针对每一步骤的要求严格的验证

内涵：保证质量

*********什么是瀑布式思维，怎样避免？

增量模型说明：

把软件产品作为一系列的增量构件来设计、编码、集成和测试。每个构件由多个相互作用的模块构成，并且能够完成特定的功能

使用增量模型时，第一个阶段的增量构件往往实现软件的基本需求，提供最核心的功能；后面的增量构架逐渐添加系统的功能

增量和迭代开发的理解和实际应用：

增量模型的精髓和内涵：

精髓

?从最主要的需求开始进行增量开发，不断获得用户的使用反馈，上一次增量作为下一次增量的基础，从而使需求逐渐完善

内涵

?通过多次增量，不断获得用户的反馈，并使需求逐步精化

迭代的概念，增量？？？？？？？？？

*****************瀑布式有什么缺点；迭代、增量有什么优缺点，怎么实现

需求（requirements）就是确定系统该做些什么以及该符合什么条件。

软件需求包括：功能需求、性能需求、用户或人的因素、环境需求、界面需求、文档需求、数据需求、资源使用需求、安全保密要求、可靠性需求、软件成本消耗与开发进度需求、其他非功能性要求

需求分析的目标：明确性、完整性、一致性、可测试性

需求一致性的含义：一致性

?业务需求与用户需求的一致性

?用户需求与功能需求的一致性

RUP以及敏捷过程都采用迭代和进化式的需求分析

需求工程的任务：

1需求获取2需求分析、协商与建模3需求规约与验证4需求管理

如何进行增量和迭代式的开发？？？？？(即增量和迭代的实际应用)

常用的需求分析（启发）技术：常用的分析和建模方法有面向数据流方法、面向数据结构方法和面向对象的方法。

?实地观察

?访谈

?开会

?问卷调查

?原型制作

?研究文档

?研究竞争对手

几种常用的过程模型及其特点：（了解一下）

快速原型模型：

什么是“原型”

?原型是快速实现和运行的早期版本，反映最终系统部分重要特性

?常见的原型实例：人机界面；系统主要功能

?优点：通常能反映用户真实需求、软件产品的开发基本上是线性顺序进行的

快速原型模型的精髓和内涵：

精髓：通过在早期建立原型系统，获得用户的反馈，并由反馈进一步精化用户需求

内涵：通过用户反馈精化需求

螺旋模型：

缺点：一个周期的执行时间太长、要有方法和自动化工具支持，否则无法实施、进行风险分析的费用可能较大

螺旋模型的精髓和内涵：精髓：风险驱动内涵：规避风险

可行性研究的目的（作用？）：

1用最小的代价在尽可能短的时间内确定问题是否能够解决。2不是解决问题，而是确定问题是否值得去解决。 3说明该软件开发项目的实现在技术上、经济上和社会条件上的可行性；评述为合理地达到开发目标可能选择的各种方案。

可行性研究的内容：技术可行性、经济可行性、法律可行性、操作可行性

可行性研究的步骤：1项目目标和规模2研究目前的系统3形成高层逻辑模型4问题的重新定义。

敏捷和统一过程知识点：

?1,RUP的阶段划分

?1初始阶段2细化阶段（精化阶段）3构造阶段（构建阶段）4交付阶段（产品化阶段）

?

?2,RUP中迭代的理解 (RUP迭代阶段图)：

?RUP：Rational Unified Process 四个阶段：

?1初始阶段2细化阶段（精化阶段）3构造阶段（构建阶段）4交付阶段（产品化阶段）

?工作流程（九个）：业务建模、需求、分析设计、实施、测试、部署、配置和变更管理、项目管理、环境。

?RUP的六个最佳商业实践：

? 1 迭代式开发（develop software iteratively）

?给定的时间内，开发一个大型的复杂的软件系统，定义问题并构建解决方案是不可能一蹴而就的。

?允许每次迭代中的需求变化；

?每个迭代完成一个版本的程序。

? 2 管理需求（manage requirements）

?需求是变化的；

?RUP实现对需求的动态管理。

? 3 使用基于构件的体系结构（use component-based architectures）

?构件就是已存在的模块或子系统（重用）；

?降低复杂度，提高效率，提高软件质量。

? 4 可视化软件建模（visually model software）

?建模就是建立模型，模型是对客观事物的抽象；

?可视化模型更容易理解；

?可采用UML建立可视化的模型。

? 5 验证软件质量（verify model quality）

?软件质量决定软件的成败；

?RUP对软件质量的评估贯穿于整个开发过程的始终。

? 6 控制软件变更（control changes to software）

?管理软件变更；

?软件修改可控、可跟踪。

?

但现实总是残酷的，需求总是会变化。变化的原因有以下几种：1）业务发生了变化；

2）客户对业务的理解发生了变化；

3）需求分析人员对需求的理解出现了偏差，需要修正。

?3,敏捷思想如何对待需求变化的（拥抱变化）：

1现场客户：很多开发团队并不喜欢客户对他们指手画脚，甚至认为他们不停提出的需求变化让他们疲于应对。但现场客户给团队开发带来的益处还是要远远超过他带来的坏处。无论团队中聚集了多么权威的领域专家，但真正了解客户需求的还是客户自己。（即客户就是开发团队的一员，客户加入到开发团队）

2定期迭代：不仅要定期迭代，而且要尽可能地让迭代周期短，并及时交付可以工作的小版本发布。XP的迭代周期通常为一周，而发布一个小版本大约是一个月。

敏捷方法绝对不可闭门造车，因为需求总是可能存在二义性，且需求总是处于不断的变化中。若能定期交付一个可以工作的小版本，一方面可以给与开发团队和客户以信心，另一方面也有助于我们及时获得客户的反馈。

3持续改进：开发过程总是会出现错误，无论是开发方法、技能，还是团队管理与团队合作。持续地改进我们的开发方法、管理方法与开发过程，才能够及时而有效地解决错误，避免重蹈覆辙。一个能够持续改进的团队是一个成长的团队，同时必然会是一个拥抱变化的团队。

?4,敏捷宣言的理解：

1个体和交互胜过过程和工具2可以工作的软件胜过面面俱到的文档3客户合作胜过合同谈判4响应变化胜过遵循计划

迭代思想的具体体现：具体应用实例（一定要掌握）

软件方法部分

业务建模知识点

业务建模对于软件开发的作用：描述现实，帮助发现软件需求。

建模的目的：（帮助大家进行沟通和理解）

业务建模和系统建模的区别：针对的对象不同：前者针对业务现状，后者针对系统

1,业务建模的目的？

业务建模的目的(from RUP)

?理解将要实施的系统的组织结构和动态特性

?理解当前在目标组织中的问题，并明确改进的潜力

?确保客户、最终用户和开发人员对目标组织有统一的理解

?获取用于支持目标组织的系统需求

2,什么情况需要进行业务建模。

不熟悉业务机构（当团队成员对业务现状不了解时）

机构最近进行了一些业务过程重组

机构准备进行业务过程重组

建立机构主要部分使用的软件

机构中大型复杂工作流的文档不足

3,业务建模的手段：领域模型、业务对象图、业务用例图、活动图

第一种方式：领域建模（本质就是类图）领域建模是业务对象图的一个特例。反映的是现实世界的一个概念，而非软件系统的概念

第二种方式：后面两个（比较麻烦）

4,领域模型的理解：

领域模型基本元素就是概念类，反映出现实世界的一种概念，是类图的一种简化的表示方式?基本概念：

领域模型（domain model）是对领域内的概念类或现实世界中对象的可视化表示。

领域模型也称为概念模型、领域对象模型和分析对象模型。

在UP中领域模型指的是对现实世界概念类的表示，而非软件对象的表示。

什么是概念类？？？？？

?通俗的讲，概念类是思想、事物或对象。

?正式的讲，概念类可以从其符号、内涵和外延来考虑。

–符号：表示概念类的词语或图形

–内涵：概念类的定义

–外延：概念类所适用的一组示例

5,可视化建模的主要作用（沟通和理解）

Why Model?

1Modeling achieves four aims:

?Helps you to visualize（可视化）a system as you want it to be.

?Permits you to specify （描述）the structure or behavior of a system.

?Gives you a template that guides you in constructing（构造）a system.

?Documents （文档）the decisions you have made.

2、You build models of complex systems because you cannot comprehend such a system in its entirety

3、You build models to better understand the system you are developing

用例（系统）建模知识点

1,用例、参与者、用例图概念的理解

几个概念的含义

参与者：在系统之外，透过系统边界与系统进行有意义交互的任何事物

参与者要点：

系统外

?参与者代表在系统边界之外的真实事物，并不是系统的成分

系统边界

?参与者透过系统边界直接与系统交互，参与者的确定代表系统边界的确定 有意义的交互

?系统需要关注其交互过程，即系统职责

任何事物

?人、外系统、外部因素、时间

用例：用例实例是系统执行的一系列动作，这些动作将生成特定参与者可观测的结果值

一个用例定义一组用例实例（场景）

2,针对实际问题进行用例建模，手绘用例图

先识别参与者，再识别参与者对应的用例就画出来了

反映的是外部参与者与内部系统的一个交互

画业务建模、系统建模图（组成部分、细节）

以某种图（用例图、活动图、顺序图、用例规约）描述用例。

必考内容，看以什么形式考（用例图+描述应该为一体）。

3,理解用例建模中用例规约的最重要和最本质的工作

用例建模中最重要的东西不是画用例，而是写用例规约

用例规约具体描述用例，是最核心的东西，才可以进行下一步的设计，因为真正参考的还是用例规约

用例规约：更进一步的精度

?用例文档的核心，而用例图作为用例文档的总图

?进一步的精度：有层次的文档

?文档中每一句话都有其价值

用例图是骨架，而用例规约则是其内在的肉

用例分析知识点

1,分析类和设计类的区别

用例分析的产物（参与类类图和用例实现（即顺序图））

简单的三层架构BCE

什么是分析类？

分析类代表了“系统中必须具备职责和行为的事物”的早期概念模型

分析类处理主要的功能需求，模型化问题域对象

根据备选构架定义三类分析类

边界类：系统及其执行者的边界

控制类：系统的控制逻辑

实体类：系统实用的信息

边界类直接可以通过用例得出，不需要任何思考，起个名字直接画出来就行了，控制类也不用想

但是实体类需要通过用例分析出来有哪些实体。

边界类表示系统与执行者之间的边界

?代表系统与环境的交互

?是接口和外部事物的中间体

?构造型<>

三类边界类

?用户界面类

?系统接口类

?设备接口类

每对执行者/用例定义一个边界类

控制类表示系统的控制逻辑

?系统行为的协调器

?构造型<>

查找控制类

?在系统开发早期，为一个用例定义一个控制类，负责该用例的控制逻辑

实体代表了待开发系统的核心概念

实体类提供了另一个理解系统的观点

?显示了系统的逻辑数据结构

?传统的面向对象方法就是从这个角度进行分析和设计

使用构造型<>

可以从以下中找到实体类

?词汇表(需求)、业务领域模型(业务建模)、用例事件流(需求)、关键抽象概念(构架分析) 什么是设计类？？？？？？

2,用例分析的流程的理解

用例分析流程（步骤）：

1.完善用例规约

2.实现每一个用例

? 2.1从用例行为中查找类

? 2.2将用例行为分配给类

? 2.3构造该用例的参与类类图

3.对每一个得到的分析类

? 3.1说明职责

? 3.2说明属性和关联

? 3.3限定分析机制

3,*********系统用例的实现：手绘顺序图***********

软件分析设计考察点

1,类图、类之间的关系，类图的画法（必考）

继承、实现、依赖等等，关系的表示，公有、私有、保

护成员的表示

类间关系：

依赖关系

use-a:自行车和打气筒、充电电池和充电器

关联关系

has-a:主人和自行车（固定的对应关系）

聚合关系

组合关系

泛化关系：is-a：继承，基类派生类

实现关系接口，接口类

2,数据库建模（ER图、表结构图）

步骤：需求分析

概念结构设计（最重要的）

逻辑结构设计（最重要的）

物理结构设计（不作为重点，开发中经常涉及不到的内容）

具体的部署和实施

概念结构设计-----ER图

ER图中的E和BCE中的E的相同点和区别：

相同点：通常两者是一致的

区别：ER图中的E是需要持久化到数据库中的实体，而BCE中的E通常指所有的实体：包括需要持久化和不需要持久化的实体

形成独立于及其特点，独立于各个DBMS产品的概念模式（E-R图）

ER（Entity Relation）图也成ER模型

逻辑结构设计-----表结构（图之间的关系，多为外间关系）

逻辑设计阶段：首先将E-R图转换成具体的数据库产品支持的数据模型，如关系模型，形成数据库逻辑模式；然后根据用户处理的要求、安全性的考虑，在基本表的基础上在简历表要的视图，形成数据的外模式。

（表和字段设计技巧------逻辑设计）

数据库建模以及表的联合查询是重点，外连接不考，内连接考。

三个表的From变成inner join的形式（两者是相同的）

3,数据库SQL的使用（内连接、联合查询）

create table std (id integer,name varchar(20));

create table course (id integer,name varchar(40));

create table std_course (std_id integer,course_id integer);

insert into course values(1,'数据库原理');

insert into course values(2,'数据结构');

insert into course values(3,'软件工程');

insert into course values(4,'C++编程');

select * from course;

insert into std values(1,'小王');

insert into std values(2,'小李');

insert into std values(3,'小张');

insert into std values(4,'小赵');

select * from std;

insert into std_course values(1,1);

insert into std_course values(1,2);

insert into std_course values(1,3);

insert into std_course values(1,4);

insert into std_course values(2,1);

insert into std_course values(2,2);

insert into std_course values(2,3);

insert into std_course values(3,1);

insert into std_course values(3,2);

insert into std_course values(4,4);

课程任务：

1,完成mysql的安装(也可使用其它数据库)

2,按照上面的sql语句完成实验环境的建立。

3,请使用一条SQL查询选修各门课程的课程名称和对应的学生人数(分别使用联合查询方式和inner join方式实现)

select https://www.360docs.net/doc/ad3017910.html, as '课程名称',

count(sc.std_id) as '选修人数'

from course c,std_course sc

where c.id=sc.course_id

group by sc.course_id;

select https://www.360docs.net/doc/ad3017910.html, as '课程名称',

count(sc.std_id) as '选修人数'

from course c

join std_course sc on c.id=sc.course_id

group by sc.course_id;

select https://www.360docs.net/doc/ad3017910.html, as '课程名称',

https://www.360docs.net/doc/ad3017910.html,t as '选修人数'

from course c

join

(

select count(*) as cnt,course_id

from std_course

group by course_id

) a on a.course_id=c.id;

4,深入练习，请完成下面查询：

请使用一条SQL实现学生列表的查询，要求显示如下三列：学生名称、所选修课程名称、所选修课程的选修人数

select

https://www.360docs.net/doc/ad3017910.html, as '学生姓名',

https://www.360docs.net/doc/ad3017910.html, as '课程名称',

https://www.360docs.net/doc/ad3017910.html,t as '选修人数'

from std s

join std_course sc on s.id=sc.std_id

join course c on c.id=sc.course_id

left join (

select count(*) as cnt,course_id

from std_course

group by course_id ) a

on a.course_id = sc.course_id;

select

https://www.360docs.net/doc/ad3017910.html, as '学生姓名',

https://www.360docs.net/doc/ad3017910.html, as '课程名称',

https://www.360docs.net/doc/ad3017910.html,t as '选修人数'

from std s,std_course sc,course c,

(

select count(*) as cnt,course_id

from std_course

group by course_id ) a

where s.id=sc.std_id

and c.id=sc.course_id

and a.course_id = sc.course_id;

5,left join之探索

新增一门新的课程：

insert into course values(5,'Oracle DBA');

该课程现在没有任何学生选修，好看下面的两个语句的执行结果区别：

select distinct https://www.360docs.net/doc/ad3017910.html, as '课程名称',sc.course_id

from course c

join std_course sc on c.id=sc.course_id;

select distinct https://www.360docs.net/doc/ad3017910.html, as '课程名称',sc.course_id

from course c

left join std_course sc on c.id=sc.course_id; --这一行是否存在不影响查询结果的条数

内连接时，是仅取出满足where条件以及关连关系的记录。

外连接时，是先取出满足where条件的course表中的记录，然后再针对每一条结果去匹配std_course表中的记录。

4,数据库建模的流程

数据库设计的步骤：

1.需求分析

2.概念结构设计

3.逻辑结构设计

4.物理结构设计

5.数据库实施

6.数据库

运行和维护。

基于职责的类架构和分层架构强调基于职责

职责需要知道：

5,基于职责的分层架构设计

?分层的思路是将系统按功能职责进行划分，将同一类职责的功能抽象为一层。

?信息系统中常用的三层结构：

–1, 表示层－－用户界面

–2, 业务逻辑层－－业务处理流程

–3, 数据层－－持久化存储

模型视图控制器构架MVC

模型，即相关的数据，它是对象的内在属性

视图是模型的外在表现形式，一个模型可以对应一个或者多个视图，视图还具有与外界交互的功能

控制器是模型与视图的联系纽带，控制器提取通过视图传输进来的外部信息转化成相应事件，然后由对应的控制器对模型进行更新；相应的，模型的更新与修改将通过控制器通知视图，保持视图与模型的一致性

MVC构架示意图B-C-E

以构造型<>表示系统不同层次

以B-C-E三层结构划分系统的三类功能

?边界层(Boundary)负责系统与执行者之间的交互

?控制层(Control)处理系统的控制逻辑

?实体层(Entity)管理系统使用的信息

层之间建立依赖关系

类设计模式中的职责：需要知道集中职责模式以及分别解决什么问题

6,基于职责的类设计模式

定义：设计类图

我们已经讨论过，同一种UML图可以用于多种情况。在业务建模及用例分析中类图可以用于将领域概念可视化。

在设计建模中的类图被称为设计类图（Design Class Diagram，DCD）

面向对象设计的5个职责模式

创建者（Creator）

信息专家（Information Expert）

低耦合（Low Coupling）

控制器（Controller）

高内聚（High Cohesion）

7,常见的分层架构，UML中如何表示

典型的三层还有多层

三层架构在UML中通过包图来表示

?分层的思路是将系统按功能职责进行划分，将同一类职责的功能抽象为一层。

?信息系统中常用的三层结构：

–1, 表示层－－用户界面

–2, 业务逻辑层－－业务处理流程

–3, 数据层－－持久化存储

UML中用包图表示分层架构

8,层次图、结构图、流程图、数据流图的基本概念（了解就行）

层次图：1.描述软件的层次结构2.层次图中，一个方框代表一个模块，方框间的连线表示调用关系。结构图：1.一个方框表示，一个模块，框内著名模块的名字或主要功能2.一个模块指向另一个模块的

箭头或直线表示前一模块对后一模块的调用3.调用直线边的带注释的小箭头，表示调用是从一个模块传给另一个模块的数据，也指出了传送方向，箭头尾部是空心圆表示传递数据，箭头尾部是实心圆表示传递控制信息。

流程图：1.程序流程图独立于任何一种程序设计语言，比较直观、清晰、易于学习掌握2.为使用流程图描述结构化程序，必须限制流程图只能使用五种基本控制结构。：顺序型、选择型、先判断型循环、后判断型循环、多种情况选择。

数据流图？？？？？？？

9,内聚、耦合的关系，常用的设计方法

高内聚和低耦合还是基于职责的设计思想

高内聚并不是类功能越多越好，而是类功能越单一越好高内聚和低耦合是统一的过程

针对内聚和耦合的设计方法比如：面向接口编程、分层的思想

耦合性：偶和形式对软件系统结构中，各模块间相互联系紧密成的一种度量。

内聚性：只一个模块内部各个元素彼此结合的紧密程度的度量，若一个模块内元素（语句之间、程序之间）联系的越紧密，则它的内聚性就越高。

模块间偶和强度

低耦合：无直接耦合、数据耦合、特征耦合。

中耦合：控制耦合。

较强耦合：公共环境耦合。

强耦合：内容耦合。

模块独立性由强到弱。

高内聚：功能内聚、顺序内聚。

中内聚：通信内聚、过程内聚。

低内聚：时间内聚、逻辑内聚、偶然内聚。

模块独立性由强到弱。

软件管理部分

风险管理方式：风险列表

1,风险管理意识：十大风险清单

管理的范围：四个P！

?People

?Product

?Process

?Project

总之：试卷反映了基本知识点和工程思想的理解