软件生命周期

一个软件产品或软件系统经历孕育、诞生、成长、成熟、衰亡等阶段，一般称为软件生存周期（软件生命周期）。

根据软件所处的状态和特征，划分软件生存周期。

需求定义、软件设计、软件实现、软件维护

使用角度

1. 提出需求

   用户根据需求，提出要解决的问题和需要的软件。

2. 获取软件

   这个过程主要是对获取软件的最佳途径做出决策并选择最佳的供应商。

   • 购买软件
   • 定制或开发软件
   • 租赁软件或租赁服务

3. 使用软件

   一旦获得软件之后，用户将操作软件使之为其服务。

开发角度

软件生存周期的一些活动构成了软件开发生命周期，即从决定开发软件产品到交付软件产品。

1. 定义软件：理解问题、可行性研究、需求分析
2. 开发软件：软件设计、软件实现、软件测试
3. 维护软件：软件交付、软件维护、软件退役

软件开发过程

瀑布式开发过程

适用于需求比较明确、小系统开发项目。

六个基本活动

制定计划、需求分析、软件设计、程序编写、软件测试、运行维护

特点

1，自上而下，相互衔接，固定次序

2，当前活动接收上一项活动的工作结果，将之作为下一项活动的输入，否则返回修改。

3，强调文档作用，每个阶段都需要仔细验证。

核心思想

按工序将问题化简，将功能的实现和设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现和物理实现分开。

缺点

1，阶段划分僵硬，产生大量文档，增加工作量。

2，开发是线性的，到整个过程的末期才能看到可运行软件，不利于快速相应变化的需求。

3，早期的错误要等到开发后期的测试阶段才能发现，增加了开发的风险。

4，瀑布模型的突出缺点是不适应用户需求的变化。

strong>增量开发模型

定义

指的是待开发的软件不是一次就能完成的，而是把软件分成一系列增量，完成一部分就交付一部分。

特点

1，引进了增量包的概念，无需等到所有需求明确，只需要某个需求明确了，就可进行开发。

增量的类型及其开发不止一种，可行的方式是首先实现那些明确的、核心的需求，也可以对需求按优先级排序，或者按照用户的要求实现增量。

2，本质是迭代开发的，反复执行**【分析——设计——编码——测试】**的过程。

3，最好是再架构设计完成之后再进行增量，保证系统的健壮性和可扩展性。

4，把瀑布模型的顺序特征与快速原型法的迭代特征相结合。

优点

1，短时间内向用户提交一个可运行软件，提供用户急需的部分功能。

2，每次只提交部分功能，用户有充分的时间学习、适应新的产品。

3，使软件适应需求的变化。

4，有利于系统维护。

能在较短的时间内向用户提交可完成部分工作的产品。

将待开发的软件系统模块化，可以分批次地提交软件产品，使用户可以及时了解软件项目的进展。

以组件为单位进行开发降低了软件开发的风险。一个开发周期内的错误不会影响到整个软件系统。

开发顺序灵活。开发人员可以对组件的实现顺序进行优先级排序，先完成需求稳定的核心组件。当组件的优先级发生变化时，还能及时地对实现顺序进行调整。

缺点

1，每次增加的部件可能会破坏已构造好的系统（避免则需要软件具备开放式的体系结构，否则系统将失去文档的结构）

2，容易退化为边做边改模型，使软件过程的控制失去整体性。

3，难以定义软件开发中的“增量”，界定它的工作量、需求范围、功能或特性。

由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构。

在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而是软件过程的控制失去整体性。

如果增量包之间存在相交的情况且未很好处理，则必须做全盘系统分析，这种模型将功能细化后分别开发的方法较适应于需求经常改变的软件开发过程。

作用

1， 开发初期的需求定义只是用来确定软件的基本结构，使得开发初期用户只需要对软件需求进行大概的描述；而对于需求的细节性描述，则可以延迟到增量构件开发时进行，以增量构件为单位逐个地进行需求补充。这种方式能够有效适应用户需求的变更。

2， 软件系统可以按照增量构件的功能安排开发的优先顺序，并逐个实现和交付使用。不仅有利于用户尽早用上系统，能够更好地适应新的软件环境，而且在以增量方式使用系统的过程中，还能获得对软件系统后续构件的需求经验。

3， 软件系统是逐渐扩展的，因此开发者可以通过对诸多构件的开发，逐步积累开发经验。实际上，增量式开发还有利于技术复用，前面构件中设计的算法、采用的技术策略、编写的源码等，都可以应用到后面将要创建的增量构件中去。

4， 增量式开发有利于从总体上降低软件项目的技术风险。个别的构件或许不能使用，但一般不会影响到整个系统的正常工作。

5， 实际上，在采用增量模型时，具有最高优先权的核心增量构件将会被最先交付，而随着后续构件不断被集成进系统，这个核心构件将会受到最多次数的测试。这意味着软件系统最重要的心脏部分将具有最高的可靠性，这将使得整个软件系统更具健壮性。

敏捷开发

适用于需求不明确的项目、创新性的项目或者需要抢占市场的项目。 期限紧迫。

定义

面对快速变化需求的一种软件开发能力。以用户的需求进化为核心，采用迭代、循序渐进的方式开发 。

在敏捷开发中，增量开发的迭代周期一般为1~6周。

基本技术

敏捷开发使用的UML符 主要是类图和时序图。

敏捷开发遵循软件开发的基本原则，同时也总结出了11条面向对象设计的原则，例如单一职责原则，里氏代换原则。

敏捷开发加强和推广了一些经典的实践，例如【意图导向编程】，指的是假设当前这个对象中已经有了一个理想的方法，它可以准确无误的完成想做的事情，而不是直接盯着每一点要求来编写代码。

敏捷开发也创造了一些新的技术或实践，例如：测试驱动开发、结对编程、代码重构、持续集成。

（测试驱动开发TDD：在一个微循环中，首先确认并且自动化进行一个失败的测试，然后编写足够的代码通过测试，在下一轮前重构代码。）

四个核心价值观

（1）个体和互动胜过流程和工具。

（2）工作的软件胜过详尽的文档。

（3）客户合作胜过合同谈判。

（4）响应变化胜过遵循计划。

十二条原则

（1）最优先要做的是通过尽早地、持续地交付有价值的软件满足客户需要。

（2）即使在开发后期也欢迎需求的变化，敏捷过程利用变化为客户创造竞争优势。

（3）经常交付可以工作的软件，从几星期到几个月，时间越短越好。

（4）业务人员和开发人员应该在整个项目过程中始终朝夕在一起工作。

（5）要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。

（6）在开发小组中最有效率、也最有效果的信息传达方式是面对面的交谈。

（7）工作的软件是进度的主要度量标准。

（8）责任人、开发者和用户应该维持长期、恒等的开发节奏。

（9）对卓越技术与良好设计的不断追求将有助于提高敏捷性。

（10）简单——尽可能减少工作量的艺术——至关重要。

（11）最好的架构、需求和设计都源于自组织的团队。

（12）每隔一定时间，团队都要总结、反省工作效率，然后相应地调整自己的行为。

认识面向对象

类图表示法

下图表示一个Employee类，它包含name,age和address这3个属性，以及work()方法。

类和类之间的六种关系

关联、聚合、组合、依赖、继承、实现

其中，聚合和组合 属于关联关系。

几种关系所表现的强弱程度依次为：组合 > 聚合 > 关联 > 依赖。

关联

是对象之间的一种引用关系。

单向关联

在UML类图中单向关联用一个带箭头的实线表示。上图表示每个顾客都有一个地址，这通过让Customer类持有一个类型为Address的成员变量类实现。


双向关联

双方各自持有对方类型的成员变量。

在UML类图中，双向关联用一个不带箭头的直线表示。上图中在Customer类中维护一个List<Product>，表示一个顾客可以购买多个商品；在Product类中维护一个Customer类型的成员变量表示这个产品被哪个顾客所购买。

聚合

聚合关系是关联关系的一种，是强关联关系，是整体和部分之间的关系。

聚合关系也是通过成员对象来实现的，其中成员对象是整体对象的一部分，但是成员对象可以脱离整体对象而独立存在。例如，学校与老师的关系，学校包含老师，但如果学校停办了，老师依然存在。

在 UML 类图中，聚合关系可以用带空心菱形的实线来表示，菱形指向整体。下图所示是大学和教师的关系图。

依赖

依赖关系是一种使用关系，它是对象之间耦合度最弱的一种关联方式，是临时性的关联。在代码中，某个类的方法通过局部变量、方法的参数或者对静态方法的调用来访问另一个类（被依赖类）中的某些方法来完成一些职责。

在 UML 类图中，依赖关系使用带箭头的虚线来表示，箭头从使用类指向被依赖的类。下图所示是司机和汽车的关系图，司机驾驶汽车（Driver通过drive方法的参数访问Car类）：

实现

实现关系是接口与实现类之间的关系。在这种关系中，类实现了接口，类中的操作实现了接口中所声明的所有的抽象操作。

在 UML 类图中，实现关系使用带空心三角箭头的虚线来表示，箭头从实现类指向接口。例如，汽车和船实现了交通工具，其类图如图 9 所示。

依赖倒转原则

高层模块不应该依赖低层模块，两者都应该依赖其抽象；**具体不应该依赖于细节，细节应该依赖于抽象。**该原则与传统的结构化分析和设计方法对立。

【例】组装电脑

现要组装一台电脑，需要配件cpu，硬盘，内存条。只有这些配置都有了，计算机才能正常的运行。选择cpu有很多选择，如Intel，AMD等，硬盘可以选择希捷，西数等，内存条可以选择金士顿，海盗船等。

测试类用来组装电脑。

上面代码可以看到已经组装了一台电脑，但是似乎组装的电脑的cpu只能是Intel的，内存条只能是金士顿的，硬盘只能是希捷的，这对用户肯定是不友好的，用户有了机箱肯定是想按照自己的喜好，选择自己喜欢的配件。

根据依赖倒转原则进行改进：

代码我们只需要修改Computer类，让Computer类依赖抽象（各个配件的接口），而不是依赖于各个组件具体的实现类。

类图如下：

长方形类（Rectangle）：