【软件工程】软件工程入门

🌈 个人主页：十二月的猫-CSDN博客
🔥 系列专栏： 🏀软件开发必练内功_十二月的猫的博客-CSDN博客

💪🏻 十二月的寒冬阻挡不了春天的脚步，十二点的黑夜遮蔽不住黎明的曙光

1. 前言

2. 软件工程概念

2.1 定义

2.2 软件工程与软件工程学

3. Why 软件工程

3.1 什么是软件工程

3.1.1 问题分析

3.1.2 问题解决

3.2 软件工程存在的问题

3.2.1 区分fault、error、failure

3.3 高质量软件

3.4 软件工程的参与者

3.5 总结

4. 开发方法

4.1 系统化开发方法

4.2 工程化开发方法

5. 软件开发的Wasserman规范（基本概念）

5.1 抽象

5.2 分析和设计方法以及表示法

5.3 用户界面原型化

5.4 软件体系结构

5.5 软件过程

5.6 复用

5.7 测度

5.8 工具和集成环境

1. 前言

软件工程包括什么

项目管理层面的内容
技术研发层面的内容
软件工程学范畴内的知识点

软件工程要求什么：

了解软件工程（用工程方法、工程思想完成软件开发）的实际操作流程
了解工程问题如何解决

软件工程学作用：

采用高质量的环境及工具，使软件能够按照某种能够反映软件开发规律的规范/模式来开发。

一句话解释软件工程学的目标：

研究规范/模式。这个规范/模式能够体现软件开发过程的自然规律，并通过遵循开发过程的自然规律达到 提升软件质量/开发效率 的效果。

2. 软件工程概念

2.1 定义

将系统化的、规范化、可量化的方法应用于软件的开发、运行和维护，即将工程化方法应用于软件开发。

软件工程 = 软件开发技术+软件工程学+软件项目管理

2.2 软件工程与软件工程学

想要用工程化的方法开发一个软件

完整流程如下：

1、学会软件开发相关的技术（数据库、编程语言、算法等）；

2、学会软件工程学，利用软件工程学的思想加上软件开发相关技术完成软件开发

3、软件生命周期整个过程都需要软件项目管理从软件筹划到软件落地再到软件维护全部过程都需要项目管理能力

软件工程学是软件工程的一部分，软件工程是一个更宏观的概念
软件工程学是狭义上的软件工程
软件工程学研究的是软件开发的规范/模式

3. Why 软件工程

3.1 什么是软件工程

从词汇本意出发

软件工程= 软件+工程

定义一：用系统化、工程化方法解决软件开发问题

从问题论角度出发

软件工程本质是解决问题：软件开发中遇到的问题

定义二：软件工程 = 问题分析+问题解决

（针对技术问题，项目进展）

从定义二出发，软件工程关键就在于 问题分析、问题解决

3.1.1 问题分析

对于一个复杂的问题，我们的分析都可以采用如下流程：

分解为子问题->解决子问题->合并子问题

3.1.2 问题解决

软件工程中的问题解决，就是运用各种技术，来有针对、具体的解决所遇到的问题。

针对具体问题，提出具体解决方法。例如：

提高并发能力：分布式开发

提高代码复用率：面向对象开发

3.2 软件工程存在的问题

3.2.1 区分fault、error、failure

fault：缺陷。程序在功能的实现上存在缺陷，但是这个缺陷如果不造成程序运行的error，或者不造成程序结果的failure，就不会被发现。如果造成程序运行的error/failure，那就可以根据error/failure定位到fault的位置。

error：错误。错误程序代码（运行错误）/错误理解需求。

failure：失败。程序能够运行，但是运行结果有问题。

一个error（错误理解需求）能造成很多fault；fault又将造成failure

fault是永远存在的；failure、error不一定存在（只要永远没运行到fault所在代码，就永远不会有error/failure）

3.3 高质量软件

软件质量包括：

最终产品质量
过程的质量（软件开发及维护的质量）
商业质量

目标：商业价值和技术价值统一起来（两者不一定相伴随）

过程：提高过程的商业价值（软件开发过程中工作量就是投资，就是花费的商业价值）

3.4 软件工程的参与者

客户、开发者、使用者

3.5 总结

软件工程 = 软件工程技术+软件工程学+软件项目管理

软件工程是一个系统工程，包括软件项目开发、项目管理两个方面

项目开发包括：问题分析、问题解决（需要软件开发技术和软件工程学）

项目管理包括：过程管理、人员管理等

项目开发中的问题分析和问题解决都依靠软件工程学、软件开发技术的知识。所以这里就引入了两个软件工程概念——1、软件工程包括三方面内容；2、软件工程包括两个过程

4. 开发方法

在前一个栏目 3. Why 软件工程中，我们研究了软件工程的两种定义（一个是内容定义、一个是过程定义）。从内容定义中，我们意识到软件工程中的核心在于软件工程学以及软件项目管理；在过程定义中，软件项目开发过程中也是持续需要软件工程学的知识作为补充。

因此软件工程学是核心！！！

软件工程学，前面我们接触了：1、问题分析法/问题解决法；2、软件工程质量的判断；3、软件工程的问题。

其中问题分析和解决是软件工程开发的前言；软件工程问题是前序；软件工程质量判断是后言。

最核心的部分是：如何根据实际问题分析后的结果，构建软件，通过软件工程质量判断

4.1 系统化开发方法

软件是一个系统，因此构建软件，最宏观的角度就是从整个系统角度来看软件。

构建软件第一步：确定软件（系统）边界

系统的要素：

想要确定系统边界，先要了解系统由哪些部分组成：

活动
对象（实体）
关系
系统边界

活动：发生在系统中的事件，由一个事务转变为另一个事务

对象：活动中的所有东西

关系：对象与活动之间的所有相互关系

系统边界：活动/对象/关系的一个整体工作范围

一个例子：

（上图只有活动和边界，将活动细分才会有关系和对象）

活动有：Date validation、calculation、printing

实体有：打印机、计算员、数据测试员等

关系有：活动之间关系、实体活动之间关系

边界是：所有活动、关系、实体的范围

4.2 工程化开发方法

将软件开发看作一个工程项目，让软件开发也遵从工程项目开发的一个具体流程。

工程化：系统化、规范化、模块化

具体流程：

需求分析
系统设计
程序设计
程序实现
单元测试
集成测试
系统测试
系统提交
维护

让软件开发严格遵守上面的具体开发流程，从而提高软件质量

5. 软件开发的Wasserman规范（基本概念）

自从20世纪70年代以来，软件开发一直发生着巨大的变化（Wasserman 1995）。例如，早期的应用软件是运行在单处理器上的，通常是大型机。输入是线性的，往往是一副卡片或一个输入磁带，而输出是字母数字。系统用两种基本方式来设计：转换（transformation），它将输入转换为输出；事务（transaction），由输入决定哪个功能将被执行。如今，基于软件的系统已经大不相同，并且更为复杂。它们通常运行在多个系统上，有时配置在具有分布式功能的客户/服务器体系结构中。软件不仅执行用户需要的主要功能，而且还要执行网络控制、安全性、用户界面表示和处理，以及数据或对象管理。

传统的“瀑布”开发方法假定开发活动是线性前进的，即只有在一个活动完成以后才会进行下一个活动（将在第2章中学习）。这种方法不再灵活也不再适合于当今的系统了。

因此，我们需要新的方法，这些新的方法需要满足一些规范，这就是Wasserman规范

Wasserman指出，7个技术变化中的任何一个都对软件开发过程有着重大的影响（Wasserman 1996）。它们合在一起，改变了我们的工作方式。在DeMarco的介绍中，描述了这种根本的转变：我们首先解决了容易的问题——这意味着尚未解决的一组问题比以前更加困难了。Wasserman通过提出软件工程中存在的8个基本概念来应对这一挑战。这些概念构成了有效的软件工程规范的基础。在这里给出它们的简要介绍，在后面的章节中，将回过头来探讨它们在什么地方适用于我们所做的事情，以及如何应用于我们所做的事情。

5.1 抽象

有时，在一个问题的“自然状态”（即如同客户和用户表达的那样）考虑这个问题是一件令人畏惧的事情。在问题的“自然状态”下，我们不可能发现以有效的或者甚至只是可行的方法处理问题的显而易见的方式。抽象（abstraction）是在某种概括层次上对问题的描述，使得我们能够集中于问题的关键方面而不会陷入细节。这个概念与转换（transformation）不同，转换是把问题转移到另外一个我们理解得更好的环境中。转换通常用于将一个问题从现实世界转移到数学世界中，这样我们能够利用数字的知识来解决问题。

通常，我们使用抽象标识对象的类，以便能够把多个项组合在一起。这样，我们处理的事情可以更少，而且可以集中考虑每个类中各个项之间的共性。我们可以讨论一个类中各个项的性质或属性，检查属性以及类之间的关系。例如，假定我们要为一条大的、复杂河流构建一个环境监测系统。监控设备可能包括监测空气质量、水质、温度、流速以及其他环境特性的传感器。但是，为了达到目的，我们可能决定定义一个称为“传感器”的类。类中的每个项具有固定的属性，不论它监测哪个特性：高度、重量、电力需求、维护进度等。我们在了解问题环境的过程中，或在设计解决方案的过程中，处理的是类，而不是它的元素。因此，类的使用有助于简化问题陈述并使我们集中于问题的本质要素或特性。

抽象也可以按层次的方式进行组织。例如，传感器是一种类型的电子设备，而我们可能有两种类型的传感器：水传感器和空气传感器。

因此，可以构成图1-13所示的简单层次结构。通过隐藏其中一些细节，我们可以集中精力考虑必须处理的对象的本质特性，并且得到简单、优雅的解决方案。我们将在第5章、第6章和第7章中更详细地讨论抽象和信息隐藏。

5.2 分析和设计方法以及表示法

当设计一个作为课程作业的程序时，通常需要自己完成工作。产生的文档是一个正式描述，它告诉你自己为什么选择这个特定的方法、变量名的含义是什么以及实现的算法。但是，当与团队一起工作的时候，必须与开发过程中的其他参与者进行交流。大多数工程师，无论他们是做什么样的工程，都会使用标准的表示法来帮助他们进行交流以及文档化相关决策。例如，建筑师画了一张图或蓝图，任何其他的工程师都能够理解他画的图。更为重要的是，公共的表示法使得建筑承包商能够理解建筑师的意图和想法。正如将在第4章、第5章、第6章和第7章中看到的，软件工程中没有类似的标准，由此产生的误解是当今软件工程中的一个关键问题。

分析和设计方法不止是提供了交流媒介，还使我们能够建立模型并检查模型的完整性和一致性。再者，我们可以更容易地从以前的项目中复用需求和设计组件，从而相对容易地提高生产率和质量。

但是，在我们能够决定一组标准的方法和工具之前，仍然有许多悬而未决的问题需要解决。正如我们将在后面的章节中看到的那样，不同的工具和技术处理的是问题的不同方面，我们需要标识建模原语，以便用一种技术就能获取问题的所有重要的方面。或者我们需要开发一种供所有方法使用的表示技术，当然可能需要某种形式的剪裁。

5.3 用户界面原型化

原型化（prototyping）意味着构建一个系统的小版本，通常只有有限的功能，它可用于：

帮助用户或客户标识系统的关键需求；
证明设计或方法的可行性。
通常，原型化过程是迭代的：首先构建原型，然后对原型进行评估（利用用户和客户的反馈），考虑如何改进产品或设计，之后再构建另外一个原型。当我们和客户认为手头问题的解决方案令人满意时，迭代过程就终止了。

原型化通常用来设计一个良好的用户界面（user interface），即系统与用户交互的部分。但是，在其他场合也可以使用原型，甚至是在嵌入式系统（embedded system）（即其中的软件功能不是明确地对用户可见的系统）中。原型能够向用户展示系统将会有什么样的功能，而不管它们是用硬件还是用软件实现的。因为从某种意义上讲，用户界面是应用领域和软件开发团队之间的桥梁，所以，原型化可以把使用其他需求分析方法不能明确的问题和假设表面化。我们将在第4章和第5章讨论用户界面原型化的作用。

5.4 软件体系结构

系统的整个体系结构不仅对实现和测试的方便性很重要，而且对维护和修改系统的速度和有效性也很重要。体系结构的质量可能成就一个系统，也可能损害一个系统。事实上，Shaw和Garlan将体系结构独自作为规范，它影响整个开发过程（Shaw and Garlan 1996）。一个系统的体系结构应该体现我们将在第5章和第7章学习的良好设计的原则。

系统的体系结构根据一组体系结构单元以及单元之间的相互关系来描述系统。单元越独立，体系结构越模块化，就越容易分别设计和开发不同的部分。Wasserman指出，至少有5种方法可以将系统划分为单元（Wasserman 1996）。

(1) 模块化分解：基于指派到模块的功能。

(2) 面向数据的分解：基于外部数据结构。

(3) 面向事件的分解：基于系统必须处理的事件。

(4) 由外到内的设计：基于系统的用户输入。

(5) 面向对象的设计：基于标识的对象的类以及它们之间的相互关系。

这些方法并不是相互排斥的。例如，可以用面向事件的分解设计用户界面，同时，使用面向对象或面向数据的方法来设计数据库。我们将在后面的章节中进一步详细分析这些技术。这些方法之所以重要，是因为它们体现了我们的设计经验，并通过复用已经做过的和所学到的，充分利用过去的项目。

5.5 软件过程

自从20世纪80年代后期以来，很多软件工程师已经在密切留意开发软件的过程以及由此产生的产品。活动中的组织和规范对软件的质量和软件开发的速度的积极作用已经得到承认。然而，Wasserman指出：

不同应用类型和组织文化之间的巨大差异使得不可能对过程本身进行预先规定。因此，软件过程不可能以抽象和模块化的方式作为软件工程的基础。（Wasserman 1996）

相反，他提出，不同的软件类型需要不同的过程。尤其是，Wasserman指出企业范围的应用程序需要大量的控制，而单个的或部门级的应用程序可以利用快速应用程序开发，如图1-14所示。

利用目前的工具，很多中小规模的系统可以由一两个开发人员来完成，其中每个开发人员必须担任多个角色。这样的工具可能包含文本编辑器、编程环境、测试支持工具，还可能包含一个获取关于产品和过程的关键数据元素的小型数据库。因为项目的风险相对较低，所以需要很少的管理支持或评审。

但是，大型、复杂的系统需要更多的结构、检查和平衡。这些系统通常涉及很多客户和用户，并且开发会持续很长时间。再者，因为某些关键子系统可能由他人提供或用硬件实现，开发人员并不总是能够控制整个过程。这种类型的高风险系统需要分析和设计工具、项目管理、配置管理、更复杂的测试工具以及对系统更严格的评审和因果分析。第2章将详细讨论若干可选的过程，以了解不同的过程是如何处理不同的目标的。然后，在第12章和第13章中，我们评估一些过程的有效性，并探讨对它们进行改进的方法。

5.6 复用

在软件开发和维护中，通常通过复用以前开发项目中的项来利用应用程序之间的共性。例如，在不同的开发项目中，我们使用同样的操作系统和数据库管理系统，而不是每次都构建一个新的。类似地，当我们构建一个与以前做过的项目类似但有所不同的系统时，可以复用需求集、部分设计以及测试脚本或数据。Barnes和Bollinger指出，复用并不是一个新的思想，他们还给出了很多有趣的例子，说明复用的不仅仅是代码（Barnes and Bollinger 1991）。

Prieto-Diaz介绍了这样一种理念：可复用构件是一种商业资产（Prieto-Diaz 1991）。公司和组织机构对那些可复用的项进行投资，而当这些项再次用于后面的项目中的时候，就可以获得巨大的收益。但是，制定一个长期、有效的可复用计划可能很困难，因为存在如下这些障碍。

有时候，构建一个小的构件比在可复用构件库中搜索这样一个构件要更快。
要使一个构件足够通用、可以在将来被其他开发人员很容易地复用，则可能需要花费格外多的时间。
由于难以对做过的质量保证和测试的程度进行文档化，可能会导致一个潜在的复用人员认为构件的质量是令人满意的。
如果某个复用的构件失效或需要进行更新，不清楚谁应该对此负责。
理解和复用一个由他人编写的构件，其代价可能是高昂的，也可能很耗时。
在通用性和专业性之间通常存在冲突。
我们将在第12章中更详细地讨论复用，并研究几个成功复用的例子。

5.7 测度

改进是软件工程研究的驱动力：通过改进过程、资源和方法，我们可以生产和维护更好的产品。但是，我们有时只能概况地表示改进目标，原因是没有量化地描述我们做了什么以及我们的目标是什么。正因为如此，软件测度已经成为好的软件工程实践的一个关键方面。通过量化我们做了什么以及我们的目标是什么，就可以用通用数学语言来描述我们的行动和结果，从而能够评估我们的进展。另外，量化的方法允许我们比较不同项目的进展。例如，当John Young担任惠普公司的CEO时，他设置了“10X”的目标，即无论对于何种应用的类型和领域，对于惠普的每一个项目，在质量和生产率方面都要有10倍的提高（Grady and Caswell 1987）。

在较低的抽象层次上，测度有助于使我们的过程和产品的特定特性更加可见。将我们对现实的、经验世界的理解转换为形式化的、数学世界中的要素和相互关系，通常是有益的，这样，我们可以操纵它们，从而得到进一步的理解。正如图1-15所示的那样，可以使用数学和统计的方法来解决问题、寻找趋势或刻画一种情形（例如使用平均值和标准差）。而这个新的信息可以接着被映射回现实世界，作为我们试图解决的现实问题的解决方案的一部分。在本书中，我们将看到测度如何应用于支持分析和决策的例子。