架构设计笔记-5-软件工程基础知识

知识要点

按软件过程活动，将软件工具分为软件开发工具、软件维护工具、软件管理和软件支持工具。

软件开发工具：需求分析工具、设计工具、编码与排错工具。

软件维护工具：版本控制工具、文档分析工具、开发信息库工具、逆向工程工具、再工程工具。

软件管理和软件支持工具：项目管理工具、配置管理工具、软件评价工具、软件开发工具的评价和选择。

软件开发环境（Software Development Environment，SDE）是指支持软件的工程化开发和维护而使用的一组软件，由软件工具集和环境集成机制构成。

软件开发环境应支持多种集成机制，例如：平台集成、数据集成、界面集成、控制集成和过程集成等。软件开发环境应支持小组工作方式，并为其提供配置管理，环境的服务可用于支持各种软件开发活动，包括分析、设计、编程、调试和文档等。

较完善的软件开发环境通常具有多种功能，例如：软件开发的一致性与完整性维护、配置管理及版本控制、数据的多种表示形式及在不同形式之间的自动转换、信息的自动检索与更新、项目控制和管理，以及对开发方法学的支持。软件开发环境具有集成性、开放性、可裁减性、数据格式一致性、风格统一的用户界面等特性，因而能大幅度提高软件生产率。

集成机制根据功能的不同，可划分为环境信息库、过程控制与消息服务器、环境用户界面三个部分。

（1）环境信息库。环境信息库是软件开发环境的核心，用以存储与系统开发有关的信息，并支持信息的交流与共享。环境信息库中主要存储两类信息：一类是开发过程中产生的有关被开发系统的信息，例如：分析文档、设计文档和测试报告等；另一类是环境提供的支持信息，例如，文档模板、系统配置、过程模型和可复用构件等。

（2）过程控制与消息服务器。过程控制与消息服务器是实现过程集成和控制集成的基础。过程集成是按照具体软件开发过程的要求进行工具的选择与组合，控制集成使各工具之间进行并行通信和协同工作。

（3）环境用户界面。环境用户界面包括环境总界面和由它实行统一控制的各环境部件及工具的界面。统一的、具有一致性的用户界面是软件开发环境的重要特征，是充分发挥环境的优越性、高效地使用工具并减轻用户的学习负担的保证。

软件开发模型大体上可以分为三种类型。第一种是以软件需求完全确定为前提的瀑布模型；第二种是在软件开发初始阶段只能提供基本需求时采用的迭代式或渐进式模型，例如喷泉模型、螺旋模型、统一开发过程和敏捷方法等；第三种是以形式化为基础的变换模型。

软件过程是制作软件产品的一组活动以及结果，这些活动主要由软件人员来完成。软件活动主要包括如下内容：

软件描述：定义软件功能以及使用的限制。
软件开发：软件的设计和实现，软件工程人员制作出能满足描述的软件。
软件有效性验证：软件必须经过严格的验证，以保证能够满足客户的需求。
软件进化：软件随着客户需求的变化不断地改进。

瀑布模型特点是因果关系紧密相连，前一个阶段工作的结果是后一个阶段工作的输入。或者说每一个阶段都建立在前一个阶段正确结果之上，前一个阶段的错漏会隐蔽地带到后一个阶段，这种错误有时甚至可能是灾难性的。因此每一个阶段工作完成后都要进行审查和确认，这是非常重要的。

螺旋模型是在快速原型的基础上扩展而成的一种生存周期模型，是一种演进式的软件过程模型。

两个特点：一是采用循环的方式逐步加深系统定义和实现的深度，同时降低风险；二是确定一系列里程碑，确保项目开发过程中的相关利益者都支持可行的和令人满意的系统解决方案。

这种模型将整个软件开发流程分成多个阶段，每个阶段都由 4 部分组成，它们是：

1. 目标设定（制定计划）。为该项目进行需求分析，定义和确定这一个阶段的专门目标，指定对过程和产品的约束，并且制定详细的管理计划。

2. 风险分析。对可选方案进行风险识别和详细分析，制定解决办法，采取有效的措施避免这些风险。

3. 开发和有效性验证（工程实施）。风险评估后，可以为系统选择开发模型，并且进行原型开发，即开发软件产品。

4. 评审（客户评估）。对项目进行评审，以确定是否需要进入螺旋线的下一次回路，如果决定继续，就要制定下一阶段计划。

螺旋模型的软件开发过程实际是上述 4 个部分的迭代过程，每迭代一次，螺旋线就增加一周，软件系统就生成一个新版本，这个新版本实际上是对目标系统的一个逼近。经过若干次的迭代后，系统应该尽快地收敛到用户允许或可以接受的目标范围内，否则也可能中途夭折。

快速应用开发（Rapid Application Development，RAD）是一种比传统生存周期法快得多的开发方法，它强调极短的开发周期。RAD 模型是瀑布模型的一个高速变种，通过使用基于构件的开发方法获得快速开发。如果需求理解得很好，且约束了项目范围，利用这种模型可以很快地开发出功能完善的信息系统。

但是 RAD 也具有以下局限性：

1. 并非所有应用都适合 RAD。RAD 对模块化要求比较高，如果有哪一项功能不能被模块化，那么 RAD 所需要的构建就会有问题；如果高性能是一个指标，且该指标必须通过调整接口使其适应系统构件才能获得，则 RAD 也有可能不能奏效。

2. 开发者和客户必须在很短的时间完成一系列的需求分析，任何一方配合不当，都会导致 RAD 项目失败。

3. RAD 只能用于管理信息系统的开发，不适合技术风险很高的情况。例如，当一个新系统要采用很多新技术，或当新系统与现有系统有较高的互操作性时，就不适合使用 RAD。

软件统一过程（Rational Unified Process, RUP）是一种基于面向对象技术的软件开发过程。其特点是“用例驱动，以架构为核心，迭代与增量”。

RUP软件开发生命周期是一个二维的软件开发模型，RUP 的 9 个核心工作流有：

业务建模：理解待开发系统所在的机构及其商业运作，确保所有参与人员对待开发系统所在的机构有共同的认识，评估待开发系统对所在机构的影响。
需求：定义系统功能及用户界面，使客户知道系统的功能，使开发人员理解系统的需求，为项目预算及计划提供基础。
分析与设计：把需求分析的结果转化为分析与设计模型。
实现：把设计模型转换为实现结果，对开发的代码做单元测试，将不同实现人员开发的模块集成为可执行系统。
测试：检查各子系统的交互与集成，验证所有需求是否均被正确实现，对发现的软件质量上的缺陷进行归档，对软件质量提出改进建议。
部署：打包、分发、安装软件，升级旧系统，培训用户及销售人员，并提供技术支持。
配置与变更管理：跟踪并维护系统开发过程中产生的所有制品的完整性和一致性。
项目管理：为软件开发项目提供计划、人员分配、执行、监控等方面的指导，为风险管理提供框架。
环境：为软件开发机构提供软件开发环境，即提供过程管理和工具的支持。

RUP把软件开发生命周期划分为多个循环（Cycle），每个循环生成产品的一个新版本，每个循环一次由4个连续的阶段（Phase）组成，每个阶段完成确定的任务。这4个阶段分别是：初始阶段、细化阶段、构造阶段（主要产生的文档包括设计模型）、移交阶段。

初始阶段：任务是为系统建立业务模型并确定项目的边界，定义最终的业务模型；
细化阶段：任务是分析问题领域，建立完善的架构，淘汰项目中最高风险的元素；
构建阶段：要开发所有剩余的构件和应用程序功能，把这些构件集成为产品；
移交阶段：重点是确保软件对最终用户是可用的。

每一个阶段都由一个或多个连续的迭代（iteration）组成。迭代并不是重复地做相同的事，而是针对不同用例的细化和实现。每一个迭代都是一个完整的开发过程，它需要项目经理根据当前迭代所处的阶段以及上次迭代的结果，适当地对核心工作流中的行为进行裁剪。

每一个阶段结束之前有一个里程碑（Milestone）评估该阶段的工作。

在 RUP 中采用 4+1 视图模型来描述软件系统的体系结构。4+1 视图包括逻辑视图、实现视图、进程视图、部署视图和用例视图。

分析人员和测试人员关心的是系统的行为，因此会侧重于用例视图；

最终用户关心的是系统的功能，因此会侧重于逻辑视图；

程序员关心的是系统的配置、装配等问题，因此会侧重于实现视图；

系统集成人员关心的是系统的性能、可伸缩性、吞吐率等问题，因此会侧重于进程视图；

系统工程师关心的是系统的发布、安装、拓扑结构等问题，因此会侧重于部署视图。

当采用面向对象的设计方法描述对象模型时，通常使用类图表达类的内部属性和行为以及类集合之间的交互关系；采用状态图定义对象的内部行为。

4+1 视图：逻辑视图、开发视图、物理视图（部署视图）、进程视图、场景。

敏捷软件过程强调：让客户满意和软件尽早增量发布；小而高度自主的项目团队；非正式的方法；最小化软件工程工作产品以及整体精简开发。

敏捷方法是一种适应性（非预测）、以人为本、迭代增量式的开发方法。结构化开发方法是面向过程的。

适应性解释：需求不稳定，无法预测；设计和构建是交错的，开发无法与设计分离；从指定计划的角度来看，分析、设计、构建和测试并不容易预测；可执行原型和部分实现的可运行系统是了解用户需求和反馈的有效媒介。

主要的敏捷方法：

极限编程（Extreme Programming， XP）：轻量级灵巧的软件开发方法。基础和价值观：交流、朴素、反馈、勇气。近螺旋式，将复杂开发过程分解为一个个简单的小周期。
水晶系列（Crystal）：与 XP 方法一样，都有以人为中心的理念，但在实践上有所不同。虽然水晶系列没有 XP 那样的产出效率，但会有更多的人能够接受并遵循它。其目的时发展一种提倡“机动性的”方法，包含具有共性的核心元素。
开放式源码：指的是开放源码界所用的一种运作方式，开放式源码项目的一个特别之处就是程序开发人员在地域上分布很广。这使得它和其他敏捷方法不同，因为一般的敏捷方法都强调项目组成员在同一地点工作。开放源码的一个突出特点就是查错排障的高度并行性：任何人发现了错误都可将改正源码的“补丁”文件发给维护者，然后由维护者将这些“补丁”或新增的代码并入源码库。
SCRUM ：强调这样一个事实，即明确定义的可重复的方法过程只限于在明确定义的可重复的环境中，为明确定义的可重复的人员用来解决明确定义的可重复的问题。
特征驱动开发方法（FDD）：由 Jeff De Luca 和大师 Peter Coad 提出，它致力于短时间的迭代阶段和可见可用的功能，在 FDD 中一个迭代周期一般是两周。在 FDD 中程序开发人员分成两类：即首席程序员和“类”程序员（Class Owner）。首席程序员是最富有经验的开发人员，他们是项目的协调者、设计者和指导者；“类”程序员则主要做源码编写。
自适应软件开发（ASD）方法由 Jim Highsmith 提出，其核心是 3 个非线性且不重叠的开发阶段，即猜测、合作与学习。

在初步的业务需求描述已经形成的前提下，基于 UML 的需求分析过程大致可分为以下步骤：

1. 利用用例及用例图表示需求。从业务需求描述出发获取执行者和场景；对场景进行汇总、分类、抽象，形成用例；确定执行者与用例、用例与用例图之间的关系，生成用例图。

2. 利用包图和类图表示目标软件系统的总体框架结构。根据领域知识、业务需求描述和既往经验设计目标软件系统的顶层架构；从业务需求描述中提取“关键概念”，形成领域概念模型；从概念模型和用例出发，研究系统中主要的类之间的关系，生成类图。

软件开发方法是指软件开发过程所遵循的办法和步骤，从不同的角度可以对软件开发方法进行不同的分类。

形式化方法是一种具有坚实数学基础的方法，从而允许对系统和开发过程做严格处理和论证，适用于那些系统安全级别要求极高的软件的开发。形式化方法的主要优越性在于它能够数学地表述和研究应用问题及软件实现。但是它要求开发人员具备良好的数学基础。用形式化语言书写的大型应用问题的软件规格说明往往过于细节化，并且难于为用户和软件设计人员所理解。由于这些缺陷，形式化方法在目前的软件开发实践中并未得到普遍应用。

净室软件工程（Cleanroom Software Engineering，CSE）是软件开发的一种形式化方法，可以开发较高质量的软件。它使用盒结构规约进行分析和建模，并且将正确性验证作为发现和排除错误的主要机制，使用统计测试来获取认证软件可靠性所需要的信息。CSE 强调在规约和设计上的严格性，还强调统计质量控制技术，包括基于客户对软件的预期使用测试。

分布性问题强调系统或系统中构件在一个分布的环境中相互通信的方式。分布性问题有两个元素：（1）实体间连接方式；（2）实体间通信的特性。解决分布性问题最普通的体系结构模式是代理（Proxy）模式。CORBA 是代理模式的一个范例。

产品配置是指一个产品在其生命周期各个阶段所产生的各种形式（机器可读或人工可读）和各种版本的文档、计算机程序、部件及数据的集合。

逆向工程：就是分析已有的程序，寻求比源代码更高级的抽象表现形式。一般认为，凡是在软件生命周期内将软件某种形式的描述转换成更为抽象形式的活动都可称为“逆向工程”。

重构（Restructuring）：指在同一抽象级别上转换系统描述形式；

设计恢复（Design Recovery）：指借助工具从已有程序中抽象出有关数据设计、总体结构设计和过程设计的信息（不一定是原设计）；

再工程（Re-engineering）：也称“修复和改造工程”，它是在逆向工程所获信息的基础上修改或重构已有的系统，产生系统的一个新版本。

结构化分析（SA）方法的基本思想是自顶向下，逐层分解。把一个大问题分解成若干个小问题，每个小问题再分解成若干个更小的问题。经过逐层分解，每个最低层的问题都是足够简单、容易解决的。

结构化方法分析模型的核心是数据字典，围绕这个核心有三个层次的模型，分别是数据模型、功能模型和行为模型（也称为“状态模型”）。在实际工作中一般使用 E-R 图表示数据模型，用 DFD （数据流图）表示功能模型，用状态转换图表示行为模型。这三个模型有密切的关系，它们的建立不具有严格的时序性，而是一个迭代的过程。

软件能力成熟度模型集成（Capability Maturity Model Integration for Software，CMMI）是在CMM的基础上发展而来。

CMMI 提供了一个软件能力成熟度的框架，它将软件过程改进的步骤组织成 5 个成熟度等级，共包括 18 个关键过程域，52 个过程目标，3168 种关键实践，它为软件过程不断改进奠定了一个循序渐进的基础。

Level 1 初始级：处于成熟度级别 1 级时，过程通常是随意且混乱的。这些组织的成功依赖于组织内人员的能力与英雄主义。成熟度 1 级的组织也常常能产出能用的产品与服务，但它们经常超出在计划中记录的预算与成本。
Level 2 已管理级：在该等级下，意味着组织要确保策划、文档化、执行、监督和控制项目级的过程，并且需要为过程建立明确的目标，并能实现成本、进度和质量目标等。为了达到过程能力成熟度模型的第二级，组织机构必须具有 6 个关键过程域。
Level 3 已定义级：在这一等级，企业能够根据自身的特殊情况定义适合自己企业和项目的标准流程，将这套管理体系与流程予以制度化，同时企业开始进行项目积累，企业资产的收集。
Level 4 量化管理级：在成熟度 4 级，组织建立了产品质量、服务质量以及过程性能的定量目标。成熟度级别 3 级与 4 级的关键区别在于过程性能的可预测。
Level 5 优化级：在优化级水平上，企业的项目管理达到了最高的境界。成熟度级别 5 级关注于通过增量式的与创新式的过程与技术改进，不断地改进过程性能。处于成熟度 5 级时，组织使用从多个项目收集来的数据对整体的组织级绩效进行关注。

需求工程主要被划分为5个阶段：

需求获取
需求分析
形成需求规格（需求文档化）
需求确认与验证
需求管理：主要活动包括：变更控制、版本控制、需求跟踪、需求状态跟踪。

需求的属性包括：创建需求的时间、需求的版本号、创建需求的作者、负责认可该软件需求的人员、需求状态、需求的原因和根据、需求涉及的子系统、需求涉及的产品版本号、使用的验证方法或者接受的测试标准、产品的优先级或者重要程度、需求的稳定性。

需求获取的方法：

用户访谈：用户访谈是最基本的一种需求获取手段，其形式包括结构化和非结构化两种。用户访谈是通过 1 对 1（或 1 对 2、1 对 3）的形式与用户面对面进行沟通，以获取用户需求。用户访谈具有良好的灵活性，有较宽广的应用范围。但是，也存在着许多困难。例如：用户经常较忙，难以安排时间；面谈时信息量大，记录较为困难；沟通需要很多技巧，同时需要系统分析师具有足够的领域知识等。另外，在访谈时，还可能会遇到一些对于企业来说比较机密和敏感的话题。
采样：指从种群中系统地选出有代表性的样本集的过程，通过认真研究所选出的样本集，可以从整体上揭示种群的有用信息。对于信息系统的开发而言，现有系统的文档（文件）就是采样种群。当开始对一个系统做需求分析时，查看现有系统的文档是对系统有初步了解的最好方法。但是，系统分析师应该查看哪些类型的文档，当文档的数据庞大，无法一一研究时，就需要使用采样技术选出有代表性的数据。采样技术不仅可以用于收集数据，还可以用于采集访谈用户或者采集观察用户。在对人员进行采样时，上面介绍的采样技术同样适用。通过采样技术，选择部分而不是选择种群的全部，不仅加快了数据收集的过程，而且提高了效率，从而降低了开发成本。另外，采样技术使用了数理统计原理，能减少数据收集的偏差。但是，由于采样技术基于统计学原理，样本规模的确定依赖于期望的可信度和已有的先验知识，很大程度上取决于系统分析师的主观因素，对系统分析师个人的经验和能力依赖性很强，要求系统分析师具有较高的水平和丰富的经验。
联合需求计划：为了提高需求获取的效率，越来越多的企业倾向于使用小组工作会议来代替大量独立的访谈。联合需求计划（Joint Requirement Planning，JRP）是一个通过高度组织的群体会议来分析企业内的问题并获取需求的过程，它是联合应用开发（Joint Application Development，JAD）的一部分。
问卷调查
现场观察
原型化方法
头脑风暴法

需求变更遵循以下流程：

1. 问题分析和变更描述。这是识别和分析需求问题或者一份明确的变更提议，以检查它的有效性，从而产生一个更明确的需求变更提议。

2. 变更分析和成本计算。使用可追溯性信息和系统需求的一般知识，对需求变更提议进行影响分析和评估。变更成本计算应该包括对需求文档的修改、系统修改的设计和实现的成本。一旦分析完成并且被确认，应该进行是否执行这一变更的决策。

3. 变更实现。这要求需求文档和系统设计以及实现都要同时修改。如果先对系统的程序做变更，然后再修改需求文档，这几乎不可避免地会出现需求文档和程序的不一致。

在对变更控制委员会的定义中，变更控制委员会对项目中任何基线工作产品的变更都可以做出决定。

软件需求包括三个不同的层次：业务需求、用户需求和功能需求。

业务需求：反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。
用户需求：描述了用户使用产品必须要完成的任务，这在用例文档或方案脚本说明中予以说明。
功能需求：定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。

以题干中字处理程序为例：用户能有效地纠正文档中的拼写错误是业务需求；找出文档中的拼写错误并通过一个提供的替换项列表来供选择替换拼错的词是用户需求；找到并高亮度提示错词的操作、显示提供替换词的对话框以及实现整个文档范围的替换则是功能需求。

需求跟踪包括编制每个需求与系统元素之间的联系文档，这些元素包括其它需求、体系结构、设计部件、源代码模块、测试、帮助文件和文档等。

软件需求开发的最终文档经过评审批准后，则定义了开发工作的需求基线（basline）。这个基线在客户和开发者之间构筑了计划产品功能需求和非功能需求的一个需求约定，是需求开发和需求管理之间的桥梁。

根据传统的软件生命周期方法学，可以把软件生命周期划分为软件定义、软件开发、软件运行、软件维护。

依赖倒置原则：指抽象不应该依赖于细节，细节应当依赖于抽象。换言之，要针对接口编程，而不是针对实现编程。在程序代码中传递参数时或在组合（或聚合）关系中，尽量引用层次高的抽象层类，即使用接口和抽象类进行变量类型声明、参数类型声明和方法返回类型声明，以及数据类型的转换等，而不要用具体类来做这些事情。为了确保该原则的应用，一个具体类应当只实现接口和抽象类中声明过的方法，而不要给出多余的方法，否则，将无法调用到在子类中增加的新方法。实现开闭原则的关键是抽象化，并且从抽象化导出具体化实现。如果说开闭原则是 OOD 的目标的话，那么依赖倒置原则就是 OOD 的主要机制。有了抽象层，可以使得系统具有很好的灵活性，在程序中尽量使用抽象层进行编程，而将具体类写在配置文件中，这样，如果系统行为发生变化，则只需要扩展抽象层，并修改配置文件，而无须修改原有系统的源代码，在不修改的情况下来扩展系统功能，满足开闭原则的要求。依赖倒置原则是 COM、CORBA、EJB、Spring 等技术和框架背后的基本原则之一。

程序流程图（Program Flow Diagram，PFD）：又称程序框图，方框表示处理步骤，菱形表示逻辑条件，箭头表示控制流向。优点：结构清晰，易于理解和修改。缺点：只能描述执行过程而不能描述有关的数据。流程图中只能包括 5 种基本控制结构：顺序型、选择型、WHILE 循环型（当型循环）、UNTIL 循环型（直到型循环）和多分支选择型。

IPO 图：由 IBM 公司发起并逐步完善的一种流程描述工具，其主体是处理过程说明，可以采用流程图、判定树、判定表、盒图、问题分析图或过程设计语言来进行描述。IPO 图中的输入、输出与功能模块、文件及系统外部项都需要通过数据字典来描述，同时需要为其中的某些元素添加注释。

NS流程图：也称盒图和方框图，特点是功能域明确；没有箭头，不能随意转移控制；容易表示嵌套关系和模板的层次关系，并具有强烈的结构化特征。但是当问题很复杂时，N-S 图可能很大。

问题分析图（Problem Analysis Diagram，PAD）：是继 PFD 和 N-S 图之后，又一种描述详细设计的工具，比PAD更直观，结构更清晰，可以取代PFD。PAD 也包含 5 种基本控制结构，并允许递归使用。

过程设计语言（Process Design Language，PDL）：也称为结构化语言或伪代码（pseudo code）。PDL用于描述模块中算法和加工逻辑的具体细节，以便在开发人员之间比较精确地进行交流。

对于具有多个互相联系的条件和可能产生多种结果的问题，用结构化语言描述则显得不够直观和紧凑，这时可以用以清楚、简明为特征的判定表（Decision Table）来描述。

判定表采用表格形式来表达逻辑判断问题，表格分成 4 个部分：左上部分为条件说明；左下部分为行动说明；右上部分为各种条件的组合说明，右下部分为各条件组合下相应的行动。

判定树（Decision Tree）也是用来表示逻辑判断问题的一种常用的图形工具，它用树来表达不同条件下的不同处理流程，比语言、表格的方式更为直观。判定树的左侧（称为树根）为加工名，中间是各种条件，所有的行动都列于最右侧。

1. 需求分析阶段：数据流图。
2. 概要设计阶段：模块结构图、层次图和 HIPO 图。
3. 详细设计阶段：程序流程图、伪代码、盒图。

UML 有两种类型的图：结构图和行为图。

结构图用来描述事物之间的关系，包括类图、对象图、组件图和部署图。

行为图用来描述参与者和用例之间的交互，或者描述参与者如何使用系统，包括用例图、顺序图、活动图、状态图和通信图。

状态图：描述了一个对象在其生命周期中可能的状态组合；
顺序图：描述对象按照时间顺序的消息流来建模用例；
数据流图：描述数据通过系统的流程以及系统实施的工作或处理过程的过程模型；
流程图：以图形化的方式展示应用程序从数据输入开始到获得输出为止的逻辑过程。

人机交互的黄金三原则：置于用户控制之下、减轻用户记忆负担、保持界面的一致性。

置于用户控制之下原则包含的内容：在定义人机交互方式时，不强迫用户采用不是必须的或者不情愿的方式来进行操作，允许交互的中断和撤销。当用户操作技能等级提高时，可以实现流水化的交互方式，允许用户定制交互方式，以便使用户界面与内部技术细节隔离，允许用户和出现在屏幕上的对象直接进行交互。

在面向对象分析中，利用用例与用例图表示需求，从用例模型中提炼形成领域模型，用例的实现可以用交互图表示。从领域模型和用例图形成类图，用包图和类图形成体系结构图。之后再进行后续的开发工作。

软件的逆向工程是一个设计恢复的过程，从现有的程序中抽取数据、体系结构和过程的设计信息。逆向过程和实现该过程的工具的抽象层次是指可从源代码中抽取出来的设计信息的精密程度。理想情况下，抽象程度应该尽可能高。逆向工程过程应该能够导出过程的设计模型（一种底层的抽象）；程序和数据结构信息（稍高层次的抽象）；对象模型、数据和控制流模型（相对高层的抽象）；UML 图、状态及部署图（高层抽象）。随着抽象层次增高，完备性就会降低。

软件设计包含4个既独立又相互联系的活动：