感谢老师课程！
课程链接：《软件工程》3小时期末速成课！期末速成丨考前突击丨期末不挂科丨考点总结
主讲人：杨老师（B 站 UP：数学建模老哥）

为什么需要软件工程？

尽管软件的发展非常迅速，但软件的开发尚没有摆脱手工制作的过程，开发人员对软件开发的认识存在一些偏差，严重影响了软件的发展。于是，许多计算机和软件科学家进行了一些尝试，把其他工程领域中行之有效的方法运用到软件开发中来，形成了软件工程。

系统模块功能确定以后，下一步就要对模块的功能和性能、数据结构、用户界面等进行必要的设计；然后进入程序编码、软件测试等阶段，而后方可交付用户使用；在用户使用的过程中，还要对程序进行不断的完善与修改，以满足用户的实际需要。

软件和软件危机

软件的定义

软件是计算机系统中与硬件相互依存的另一部分，它是包括程序、数据及其相关文档组成的完整集合。
可以写作为：软件=程序+数据+文档。
程序：程序是按事先设计好的功能和性能要求执行的指令序列。
数据：数据是指程序能正常处理信息的数据和数据结构。
文档：文档是与程序运行和维护有关的图文资料。

软件的特点

（1） 软件具有抽象特征。
（2） 软件具有无明显制造过程特征。
（3） 软件无备件的特征。
（4） 手工制作特征。
（5） 成本昂贵特征。

软件的分类（了解）

按软件功能进行划分
（1）系统软件
（2）支撑软件
（3）应用软件

按软件规模进行划分

软件危机

20世纪60年代中期以后，一些开发大型软件系统的要求提了出来。然而软件技术的进步一直未能满足形势发展的需要，在大型软件的开发过程中出现了复杂程度高、研制周期长、正确性难以保证的三大难题。遇到的问题找不到解决办法，致使问题堆积起来，形成了人们难以控制的局面，出现了所谓的“软件危机”。

软件危机的定义及其表现形式：
软件危机是指在软件开发和维护中所产生的一系列严重的问题。一是如何开发软件，满足用户对软件的需求，二是如何维护数量众多的已有软件。其主要表现如下：
（1）用户需求不明确、变更过多
（2）软件成本日益增长
（3）开发进度难以控制
（4）软件质量差
（5）软件维护困难

软件危机产生的原因
（1）软件开发无计划性
（2）软件需求不充分
（3）软件开发过程无规范
（4）软件产品无评测手段

解决软件危机的途径
（1）应该加强软件开发过程的管理。
（2）推广使用开发软件的成功技术与方法
（3）开发和使用好的软件工具

软件工程的概念

为了解决软件危机，人们在软件开发中也不断改进和发展，在50多年中计算机软件开
发经历了三个发展阶段：
程序设计阶段：约为50至60年代
程序系统阶段：约为60至70年代
软件工程阶段：约为70年代以后

软件工程的方法、工具、过程构成了软件工程的三要素。

软件工程的目标可概括为：在给定成本、进度的前提下，开发具有可修改性、有效性、可靠性、可理解
性、可维护性、可重用性、可适应性、可移植性、可追踪性和可互操作性并满足用户要求的软件产品。

软件生存周期及软件开发模型

软件也有一个孕育、诞生、成长、成熟、衰亡的生存过程。我们称其为计算机软件的生存周期。软件生存周期可划分为若干个阶段。各阶段都包括计划、开发、运行与维护三个时期，而每个时期又划分为若干个阶段。

a．计划时期
计划时期的主要任务是调查和分析。计划时期有问题定义和可行性研究两个阶段。
b．开发时期
开发时期要完成设计和实现两大任务。设计任务包括需求分析和软件设计两个阶段；实现任务包括编码和测试。
（1）需求分析
该阶段主要解决的问题是“目标系统必须做什么”，也就是要深入描述软件的功能和性能；确定软件设计的限制和软件与其他系统元素的接口；定义软件的其他有效性需求，并用“需求规格说明书”的形式准确地表达出来，提交管理机构评审。
（2）软件设计
是软件工程的技术核心，主要任务是把已确定了的各项需求转换成一个相应的体系结构，通常细分成总体设计和详细设计两个阶段。
（3）编码
该阶段的主要任务就是按照选定的语言把软件设计转换成计算机可以接受的程序代码， 即写成 “源程序清
单”。
（4）测试
测试是保证软件质量的重要手段，其主要方式是在设计测试用例的基础上检验软件的各个组成部分。
c．运行时期
已交付的软件投入正式使用，便进入运行时期。这是软件生存期的最后一个时期，可能要持续若干年甚至
几十年。在运行过程中，可能由于多方面的原因，需要对它进行修改。因此，软件人员在这一时期的主要工作，就是做好软件维护。

软件生存周期模型

软件生存周期模型是从软件项目需求定义直至软件经使用后废弃为止，跨越整个生存周期的系统开发、运作和维护所实施的全部过程、活动和任务的结构框架。有多种软件生存期模型。例如：瀑布模型、演化模型、螺旋模型、智能模型等。它们各有特色，但一般都包含“定义（或计划）”、“开发”和“维护”3类活动。定义活动主要弄清软件“做什么”；开发活动集中解决让软件“怎么做”；维护活动则聚集于软件的“修改”，即“What-How-Change”。

瀑布模型（Waterfall model）

演化模型（evolutional model）

先做试验开发，其目标只是在于探索可行性，弄清软件需求；然后在此基础上获得较为满意的软件产品。
通常把第一次得到的试验性产品称为“原型”。显然，演化模型在克服瀑布模型缺点、减少由于软件需求不明确而给开发工作带来风险方面，确有显著的效果。

螺旋模型（spiral model）

可行性研究

问题的定义

问题定义（Problem Definition）是软件定义的第一个阶段，该阶段主要明确“该软件开发项目要解决什么问题”。 系统分析过程的第一步要明确用户的需求。为此，系统分析员在对用户的需求进行分析时，必须明确以下问题：
软件系统要完成的总体目标是什么？
要开发的软件的功能和性能是什么？
软件系统在可靠性和质量上有何具体要求？
开发该软件系统是否具备可行的技术？
当前市场和竞争对手的情况怎样？
开发该软件系统是否有成本和进度约束？
该软件系统将来可能进行哪些扩充？

可行性研究的任务

可行性研究的主要目的是用极少的代价在最短的时间内决定被开发的软件是否能开发成功。
（1）经济可行性：通过对被开发软件系统的成本效益的分析，估算系统的开发成本，估计系统可能取得的效益，确定待开发系统是否值得投资开发。
（2）技术可行性：从问题定义规格说明书提出的系统功能、性能以及实际系统的各种约束来分析，确定当前的技术及条件是否能实现整个系统。
（3）法律可行性：分析在系统开发的全部过程中可能出现和涉及的法律问题，如合同、责任、知识产权、专利等问题。
（4）运行可行性：判断新系统的运行方式是否可行。

可行性研究的步骤及工具

a．可行性研究的步骤
（1）确定系统的规模和目标
（2）分析现有系统，设计新系统的高层系统模型
（3）评审系统模型
（4）设计和评价新系统的实现方案
（5）制定行动方案
（6）拟定开发计划
（7）编制可行性报告

b．可行性研究的工具
在进行可行性研究时，使用的主要工具为系统流程图。系统流程图的基本作用是：以黑盒方式描述系统各部件（如人工处理、程序、数据库、图表等），它只描述了信息在系统各部件中的流动情况，不对信息在系统中的加工细节进行描述，所以它不同于程序流程图。

制订项目计划

制订项目开发计划的目的是用文件的形式，把开发过程中各项工作的负责人员、开发进度、所需经费预算、所需软、硬件资源等问题做出的安排记载下来，以便根据本计划开展和跟踪本项目的开发工作。

需求分析

需求分析的目标和任务

软件需求分析的目标是深入描述软件的功能和性能，确定软件设计的约束和软件同其他系统元素的接口细节，定义软件的其他有效性需求。需求分析的基本任务是软件人员和用户一起完全弄清用户对系统的确切要求，通俗地说就是要解决“系统做什么”的问题，但不包括“怎么做”的问题。

需求分析阶段的具体任务：
a．确定目标系统的具体要求
（1）确定系统的运行环境要求
（2）系统的性能要求
（3）系统功能
b．分析系统的数据要求
c．建立目标系统的逻辑模型
d．修正系统开发计划
e．建立原型系统
f．编写软件需求规格说明书及评审

软件需求的获取

(1)访谈和会议
(2) 市场调查
(3) 访问用户和用户领域的专家
(4) 考察现场，跟踪现场业务流程
(5)开发人员和用户共同组成联合小组

需求分析的过程

（1）问题识别
首先系统分析员要研究可行性分析报告和软件项目实施计划。主要是从系统的角度来理解软件，并评审用于产生计划估算的软件范围是否恰当，确定对目标系统的综合要求，即软件的需求。并提出这些需求实现条件，以及需求应达到的标准。也就是解决要求被开发的软件用来做什么，做到什么程度。

这些需求包括：
功能需求、性能需求、环境要求、可靠性需求、安全保密要求、用户界面需求、资源使用需求、软件成本消耗与开发进度需求、预计系统可达到的目标。

（2）分析与综合
在对现行问题和期望的信息（输入和输出）进行分析的基础上，分析员综合出一个或几个解决方案，然后检查这些方案是否符合软件计划中规定的范围等，再进行修改。总之，对问题进行分析和综合的过程将一直持续到分析人员与用户双方都感到有把握正确地制定该软件的需求规格说明为止。

（3）编制需求规格说明

（4）需求分析评审
作为需求分析阶段工作的复查手段，在需求分析的最后一步，应该对功能的正确性、完整性和清晰性，以及其他需求给予评价。如果在评审过程中发现说明书存在错误或缺陷，应及时进行更改或弥补，并再次评审。

快速原型方法

在软件工程中，原型是软件的一个早期可运行的版本，它能反映最终系统的一部分重要特性。如果在获得一组基本需求说明后，通过快速分析构造出一个小型的软件系统，满足用户的基本要求。使得用户可在试用原型系统的过程中得到亲身感受和受到启发，做出反应和评价。然后开发者根据用户的意见对原型加以改进。随着不断试验、纠错、使用、评价和修改，获得新的原型版本，如此周而复始，逐步减少分析和交流中的误解，弥补不足之处，进一步确定各种需求细节，适应需求的变更，从而提高最终产品的质量。

原型的分类
（1）废弃型
先构造一个功能简单而且质量要求不高的原型系统，针对这个原型系统反复进行分析修改，形成比较好的设计思想，据此设计出更加完整、准确、一致、可靠的最终系统。系统构造完成后，原来的原型系统就被废弃不用。
（2）追加型或演化型
先构造一个功能简单而且质量要求不高的模型系统，作为最终系统的核心，然后通过不断地扩充修改，逐步追加新要求，最后发展成为最终系统。

结构化分析方法

SA（Structured Analysis，结构化分析方法）是20世纪70年代中期由E．Yourdon等人倡导的一种面向数
据流的分析方法。

a．数据建模
一般地，数据模型包括3种互相关联的信息，即数据对象、属性和关系。
（1）数据对象（2）属性（3）关系 ：各个数据对象的实例之间的关联。实例的关联类型有3种：一对一（1：1）一对多（1：m）多对多（n：m）（4）实体—关系图 ：数据对象及其关系可用ERD表示。
b．功能建模和数据流
功能建模的思想就是用抽象模型的概念，按照软件内部数据传递、变换的关系，自顶向下逐层分解，直到找到满足功能要求的所有可实现的软件为止。
c．行为建模
行为建模给出需求分析方法的所有操作原则，但只有结构化分析方法的扩充版本才提供这种建模的符号。行为建模常用状态—迁移图作为分析工具。

数据流图与数据字典

数据流图（Data Flow Diagram，简称DFD）是用来描绘软件系统逻辑模型的图形工具，用于描绘信息在系统中流动和处理情况。设计DFD只需考虑软件系统必须完成的基本逻辑功能，完全不需考虑如何具体地实现这些功能，即只考虑软件“做什么”，而不必考虑“怎么做”。

在数据流图中常用的有4种基本符号：

在对数据流图进行分层时，容易出现以下几种错误，应特别注意：父图与子图不平衡、分解的速度太快、不遵守加工编号规则

数据字典（Data Dictionary，DD）是结构化分析方法的另一种有力工具，在数据字典中建立的一组严密一致的定义有助于消除分析员和用户之间的沟通障碍，因此将消除许多可能的误解。对数据的这一系列严密一致的定义也有助于改进在不同的开发人员或不同的开发小组之间的通信。同时，数据字典也是软件维护时使用的一种重要资料。如果要求所有开发人员都根据公共的数据字典描述数据和设计模块，则能避免许多麻烦的接口问题，提高开发的效率和质量。

数据字典的内容①数据流词条描述②数据项词条描述③数据文件词条描述④加工逻辑词条描述⑤源点及汇(终)点词条描述

需求分析评审

需求规格说明书中阐明的需求是经过认真研究和分析后定下来的，是软件开发人员和用户对问题的共同理解，可被当作是双方达成的协议书。由于其中规定的需求都是系统准备加以实现的，因此它应该作为软件设计和实现的基础和依据。在项目开发的最后阶段，其中规定的各项需求又将是产品验收的依据。当软件产品投入运行以后，如需进行适应性或扩充性维护，仍然需要软件规格说明书。由此可见，软件规格说明书在整个软件生存周期中都具有十分重要的作用。

（1）正确性（2）无歧义性（3）完全性（4）可验证性（5）一致性（6）可理解性（7）可修改性（8）可追踪性

需求分析实例

软件设计的任务

需求分析阶段的结果是需求规格说明书，它明确地描述了用户对系统的需求，解决了软件“做什么”的问题。在明确了要做的“问题”之后，现在应该着手寻求问题的“解答”，即解决软件“怎么做”的问题。软件设计是一个把软件需求转换成软件表示的过程，软件设计分为两个阶段：
概要设计，将软件需求转换为软件结构和数据结构，并编写概要设计说明书；
详细设计，通过对软件结构的细化，得到软件的详细的算法和数据结构，产生描述软件的详细设计文档。
概要设计的基本任务有：
①制定规范 ②软件系统结构的总体设计 ③处理方式设计 ④数据结构设计 ⑤可靠性设计 ⑥编写概要设计阶段的文档 ⑦概要设计评审

软件设计的基本概念

逐步求精、程序结构、数据结构、局部化

a．模块化
模块是数据说明、语句等程序对象的集合，单独命名而且可通过名字来访问，如过程、函数、子程序、宏等都可以作为模块。模块具有3个基本属性：
（1）功能：模块实现的功能（含子模块的功能）。
（2）逻辑：描述模块内部怎么做。
（3）状态：模块使用时的环境和条件。
模块具有内部和外部两个特性：
（1）外部特性：模块的名字、参数表等。
（2）内部特性：完成模块功能的程序代码和模块内部数据。

b．模块的独立性
是指软件系统中每个模块只涉及软件要求的具体的子功能，而和软件系统中其他的模块的接口是简单的。例如，若一个模块只具有单一的功能且与其他模块没有太多的联系，那么，则称此模块具有模块独立性。它的重要性在于：
● 模块独立性好的软件比较容易开发，便于多人合作开发同一个软件。
● 独立的模块比较容易测试和维护。
● 一般采用两个准则度量模块独立性，即模块与模块间的耦合性和模块内部的内聚性。

c．耦合性
耦合是程序结构内不同模块之间相互关联程度的度量。它是由模块间接口的复杂程度、调用模块的方式及通过接口传递的信息类型决定的。模块之间的连接越紧密，联系越多，耦合性就越高，而其模块独立性就越弱。
（1）非直接耦合
如果两个模块之间没有直接关系，它们之间的联系完全是通过主模块的控制和调用实现的，这就是非直接耦合，其模块独立性最强。
（2）数据耦合
如果一个模块访问另一个模块时，彼此之间是通过数据参数（不是控制参数、公共数据结构或外部变量）来交换输入、输出信息的，则称这种耦合为数据耦合。由于限制了只通过参数表传送数据，所以按数据耦合开发的程序接口简单，安全可靠。数据耦合是松散的耦合，模块之间的独立性比较强。在软件设计中就多使用这类耦合。
（3）特征耦合
如果一组模块通过参数表传递记录信息，就是特征耦合。事实上，这组模块共享了某一数据结构的子结构，而不是简单变量。这就要求这些模块都必须清楚该记录的结构，并按结构要求对记录进行操作。
（4）控制耦合
如果一个模块通过传送开关、标志、名字等控制信息，明显地控制选择被调用模块的功能，则称这种耦合为控制耦合。这种耦合的实质是在单一接口上选择多功能模块中的某项功能。因此，对被控制模块的任何修改，都会影响控制模块。另外，控制耦合也意味着控制模块必须知道被控制模块内部的一些逻辑关系，这些会降低模块的独立性。
（5）外部耦合
一组模块都访问同一全局简单变量而不是同一全局数据结构，而且不是通过参数表传递该全局变量的信息，则称之为外部耦合。外部耦合引起的问题类似于公共耦合，区别在于在外部耦合中不存在依赖于一个数据结构内部各项的程序逻辑。
（6）公共耦合
若一组模块都访问同一个公共数据环境，则它们之间的耦合就称为公共耦合。公共的数据环境可以是全局数据结构、共享的通信区、内存的公共覆盖区等。
（7）内容耦合
如果一个模块直接访问另一个模块的内部数据；或者一个模块不通过正常入口转到另一模块内部；或者两个模块有一部分程序代码重迭；或者一个模块有多个入口，则两个模块之间就发生了内容耦合。在内容耦合的情况下，被访问模块的任何变更，或者用不同的编译器对它再编译，都会造成程序出错。这种耦合是模块独立性最弱的耦合。

d．内聚性
内聚性标志一个模块内部各元素彼此结合的紧密程度。
（1）偶然内聚
当几个模块内凑巧有一些程序段代码相同，又没有明确表现出独立的功能，把这些代码独立出来建立的模块称为偶然内聚。
（2）逻辑内聚
如果一个模块把几种相关的功能组合在一起，每次被调用时，由传送给模块的控制参数来确定该模块应执行哪一种功能， 称为逻辑内聚。逻辑内聚导致模块间的控制耦合。
（3）时间内聚
时间内聚模块大多为多功能模块，要求模块的各个功能必须在同一时间段内执行。如初始化模块或结束模块等。在一般情形下，各部分可按任意的顺序执行，所以它的内部逻辑更简单。
（4）过程内聚
如果模块内的处理是相关的，而且必须以特定顺序执行，则称为过程内聚。在使用流程图作为工具设计程序时，常常通过流程图来确定模块划分。把流程图中的某一部分划出组成模块，就得到过程内聚模块。
（5）通信内聚
如果一个模块内各功能部分都使用了相同的输入数据，或产生了相同的输出数据，则称之为通信内聚模块。通常，通信内聚模块是通过数据流图来定义的。
（6）信息内聚
模块完成多个功能，各个功能都在同一数据结构上操作，每一项功能有一个惟一的入口点。信息内聚模块可以看成是多个功能内聚模块的组合，并且实现信息的隐蔽。即把某个数据结构、资源或设备隐蔽在一个
模块内，不为别的模块所知晓。这种封装增加了模块的独立性。
（7）功能内聚
一个模块的各个成分都是完成某个具体任务必不可少的，这些成分协同工作，紧密联系，不可分割，则称为功能内聚。功能内聚的内聚度最高。满足功能内聚的模块执行一个功能，这是判断模块是否是功能内聚
的一个方法。

e．抽象
抽象（Abstraction）就是提取出事物的本质特征而暂时不考虑它们的细节。在软件设计中，涉及到众多的物理元素。如果一开始就考虑细节问题，就不可能做到精确思维。所以抽象化对于软件设计十分重要。在软件设计中，可以有不同的抽象层次。在最高的抽象层次上，用问题所处环境的语言概括描述问题的解答。在最低层次，用直接实现的方式来描述问题的解答。而在中间层次，则采用过程化的方法。
（1）过程抽象在软件生存期中，从问题定义到程序的实现（源代码），每进展一步都可以看作是对软件解决方法的抽象化过程的一次细化。如在软件计划阶段，可以将整个软件系统当作一个简化的整体元素来看待；在需求分析阶段，用问题所处环境的术语来描述软件的解决方法；而在软件设计阶段，随着从概要设计到详细设计的进行，抽象的层次逐渐降低；当产生源代码时达到最低的抽象层次。
（2）数据抽象数据抽象允许设计人员在不同的抽象层次上描述数据对象的细节。数据抽象把一个数据对象的定义抽象为一个数据类型名，用此类型名可定义多个具有相同性质的数据对象。在抽象数据类型的定义中还可以加入一组操作的定义，用以确定在此数据对象上可以进行的操作。
（3）控制抽象与过程抽象和数据抽象一样，控制抽象可以包含一个程序控制机制而无须规定其内部细节。关于控制抽象的一个例子就是在操作系统中用以协调某些活动的同步信号。

信息隐蔽

这一指导思想的目的是为了提高模块的独立性，当修改或维护模块时减小把一个模块的错误扩散到其他模块中去的机会。在这一思想的指导下，在软件开发中先后出现了“数据封装”（DataEncapsulation，指在一个模块中包含一个数据结构和在此数据结构上执行的操作），“抽象数据类型” （AbstractDatatype，指一种数据类型，其中可包含在该类型的实例上执行的操作）等设计方法。

软件的设计原则

软件的设计原则应遵循以下几个方面：
（1）功能分解。功能分解是非常朴素、普通的思想，是人们处理复杂问题常用的方法。然而，也是非常容易遗忘的思想。很多设计人员总是雄心勃勃，试图设计出非常复杂的算法，非常完美的结构，不是将问题简化，而是将问题复杂化。而实践证明，这些出发点就是有偏差的。软件领域以外的很多实践和经验，都证明了分工、分解是处理复杂系统的基本前提。
（2）设计对于分析模型应该是可跟踪的（软件的模块可能被映射到多个需求上）。
（3）设计结构应该尽可能地模拟实际问题。
（4）设计应该表现出一致性。
（5）不要把设计当成编写代码。
（6）在创建设计时就应该能够评估质量。
（7）在设计阶段就要注重软件的重用。
（8）评审设计以减少语义性的错误。

结构化设计方法

结构化设计方法（StructuredDesign， SD ） 是2 0 世纪7 0 年代中期由Stevens.Myers与Constantine等人率先倡导的，它是一种面向数据流的设计方法，是基于模块化、自顶向下逐层细化、结构化程序设计等程序设计技术基础上发展起来的。使用该方法时应注意以下几点：

详细设计

N-S图也称盒图（Box-Diagram），是由Nassi和Shneiderman提出的一种符合结构化程序设计原则的图形描述工具。结构化程序设计要求只使用3种基本控制结构，即顺序结构、分支结构（包括简单选择型和多分支选择型）和循环结构（包括先判定型和后判定型）。

N-S图有以下几个特点：

• 图中每个矩形框都是明确定义了的功能域。
• 图中的控制转移不能任意规定，必须遵守结构化程序设计要求。
• 从图中可以很容易地确定局部数据和全局数据的作用域。
• 图中很容易表现嵌套关系及模块的层次结构。

PAD（Problem Analysis Diagram，问题分析图），是日本日立公司提出的用结构化程序设计思想表现程序逻辑结构的图形工具。现在已被ISO认可。PAD也设置了5种基本控制结构的图式，并允许递归使用。

判定表与判定树
当算法中包含多重嵌套的条件选择时，用程序流程图、N-S图或PAD都不易清楚地描述。这时可以用判定表或判定树来描述这些复杂的条件。判定表与判定树除了在详细设计阶段使用外，在需求分析阶段也经常使用。
判定表一般由4部分组成：左上半部分列出所有条件、左下半部分列出所有动作、右上半部分列出各种条件组合，右下半部分列出和每组条件取值组合对应的动作。

判定表的优点是能够简洁、无二义性地描述所有的处理规则。缺点是它所表示的是静态逻辑，是在某种条件组合情况下可能的结果，它不能表达加工的顺序，也不能表达循环结构。因此，判定表不能成为一种通用的设计工具，一般作为辅助工具配合其他工具一起使用。

　某“订货单处理程序”的处理逻辑描述如下：
“如果订货金额不足500元且未过期，则向客户发出批准单和提货单，已过期的，什么也不发；如果订货金额超过500元但不足1000元，则发出批准单和提货单，对已过期的，还要发过期通知单；如果订货金额超过1000元，不论是否过期，都要发出批准单和提货单。”试用判定表表示出该逻辑。

判定树（Decision Tree）
判定树实质上是判定表的一种变形，本质上是一样的。判定树的优点是形式简单、比较直观、易于掌握和使用。缺点是不如判定表简洁。

面向对象的开发过程

应用生存期
瀑布模型是传统的生存期模型。这个生存期对整个的开发过程进行了模型化，可称它为应用的生存期。在面向对象的开发过程中，面向对象的开发过程主要步骤：应用与维护、分析阶段、高层设计、类的开发、实例的建立、组装测试

类生存期
在面向对象技术中，类是作为一个单元存在的。不断有新的类在系统开发的各个阶段被标识，但在各个阶段的类所起的作用是不同的。类的开发有如下几个步骤：类的规格说明、设计、实现、测试、求精和维护

对象模型技术

对象模型的作用是描述系统的静态结构，包括构成系统的类和对象，它们的属性和操作，以及它们之间的联系。

系统的涉及时序和改变的状况，可用动态模型来描述。动态模型着重于系统的控制逻辑。它包括两个图：状态图、事件追踪图。建立动态模型的步骤为：准备对话式的节目（事件记录）、确认对象的事件、准备每个程序的事件追踪图、确保对象间事件的一致性

功能模型着重于系统内部数据的传送和处理。功能模型由多个数据流图组成，它们指明从外部输入，通过操作和内部存储，直到外部输出的整个的数据流情况。