《软件工程（第4版?修订版）》—第1章1.5节 系统的方法

我们开发的项目并不存在于真空中。通常，我们装配在一起的硬件和软件，必须与用户、其他软件任务、其他部分的硬件、现有数据库（即仔细定义的数据集合和数据关系）甚至其他的计算机系统进行交互。

本节书摘来自异步社区《软件工程（第4版?修订版）》一书中的第1章1.5节 系统的方法，作者【美】Shari Lawrence Pfleeger , 【加】Joanne M.Atlee，更多章节内容可以访问云栖社区“异步社区”公众号查看。

1.5 系统的方法
软件工程（第4版•修订版）
我们开发的项目并不存在于真空中。通常，我们装配在一起的硬件和软件，必须与用户、其他软件任务、其他部分的硬件、现有数据库（即仔细定义的数据集合和数据关系）甚至其他的计算机系统进行交互。因此，为任何项目提供一个背景是非常重要的，该背景就是项目的边界（boundary）：项目中包含什么，不包含什么。例如，假设主管让你编写一段程序为办公室的人员打印工资单。你必须知道你的程序是否只是简单地从另一个系统中读入工作时间并且打印结果，还是必须同时计算工资信息。类似地，你必须知道程序是否需要计算税率、养老金以及津贴，或者是否要随每份工资单提供这些项目的报告单。实际上，你真正要问的问题是：项目从哪里开始，到哪里结束？同样的问题可以应用于任何系统。一个系统是对象和活动的集合，再加上对象和活动之间关系的描述。就每个活动而言，典型的系统定义包括需要的输入列表、采取的动作以及产生的输出。因此，要开始一个项目，必须知道系统包含哪些对象或活动。

1.5.1 系统的要素
我们通过命名系统的组成部分并标识这些组成部分是如何与另一个系统相互联系的，来描述这个系统。这种标识是分析摆在我们面前的问题的第一步。

1．活动和对象
首先，我们对活动和对象加以区分。活动（activity）是发生在系统中的某些事情，通常描述为由某个触发器引发的事件，活动通过改变某一特性将一个事物转变成另一个事物。这种转变可能意味着数据元素从一个位置移到另一个位置，从某个值转变为另一个值，或者与其他的数据相结合为另一个活动提供输入。例如，一个数据项可以从一个文件移到另外一个文件。这种情况下，改变的特性是位置。或者，数据项的值可能增加。最后，数据项的地址可以与若干其他数据项的地址一起包含在参数列表中，以便可以调用另外的例程一次性处理所有数据。

活动中涉及的要素称为对象（object）或实体（entity）。通常，这些对象以某种方式相互联系。例如，对象能够排列在表格或矩阵中。对象常常组成记录，其中，每一条记录按规定的格式排列。例如，一个雇员的历史记录中可能包含如下对象（也称字段）：

名 邮政编码

教名 每小时的工资

姓 每小时的津贴

街道地址 累计休假

城市 累计病假

州

记录中不仅定义了每个字段，而且定义了每个字段的大小以及字段之间的关系。因此，记录描述规定了每一个字段的数据类型、记录中的开始位置和字段的长度。依次地，因为每个雇员都有一条记录，所有的记录组合在一起就构成了文件，并且要指明文件特性（如最大的记录数等）。

有时，对象定义得稍有不同。不是将每一项考虑为一个大记录中的字段，而是将对象看作是独立存在的。对象的描述包括每个对象的特性列表，以及所有使用对象或影响对象的动作的列表。例如，考虑“多边形”对象。一个对象描述可以是，这个对象具有诸如边数以及每条边的长度等特性。动作可能包括计算面积和周长。甚至可能还可以有一个属性称为“多边形类型”。这样，可以标识每个“多边形”的实例，例如是“菱形”还是“长方形”等。类型本身也可能有对象描述。例如“长方形”可以由“正方形”和“非正方形”组成。当我们在第4章研究需求分析的时候，将会探讨这些概念，并在第6章讨论面向对象开发的时候进行深入探讨。

2．关系和系统边界
一旦定义了实体和活动，就要把实体和它们的活动进行匹配。实体和活动之间的关系应该要清晰、仔细地予以定义。实体的定义包括实体起源于何处的描述。有些项驻留于已经存在的文件中，有些项在活动的过程中被创建。实体的目的地也是非常重要的。有些项仅仅被一个活动所使用，而有些项会被指定为其他系统的输入。也就是说，系统的某些项会被当前系统范围之外的活动所使用。因此，可以认为我们正在考虑的系统是有边界的。有些项跨越边界进入我们的系统，而另一些是我们系统的产品并为其他系统所使用。

使用这些概念，我们能够把系统（system）定义成一组事物的集合：一组实体、一组活动、实体和活动之间关系的描述以及系统边界的定义。系统的这个定义不仅适用于计算机系统，而且适用于其他任何事物（其中，对象以某种方式与其他对象交互）。

3．系统举例
要了解系统定义是如何进行的，考虑一个呼吸系统的例子：身体吸进氧气排出二氧化碳和水。我们可以很容易地定义它的边界：如果指出身体的一个具体器官，就能说出它是不是呼吸系统的一部分。氧气和二氧化碳分子都是实体或对象，它们按照可以明确定义的方式进出呼吸系统。我们也可以根据实体间的交互来描述系统中的活动。如果必要的话，可以通过什么进入以及什么离开来描述这个系统，也可以用一个表格来描述其中涉及的所有实体和活动。图1-8说明了一个呼吸系统。请注意每个活动都涉及实体，并且可以通过描述哪些实体是输入，它们如何被处理，以及输出的结果来进行定义。

我们还必须清晰地描述计算机系统，与预期的用户一起定义系统的边界：我们的工作从什么地方开始以及在什么地方结束？另外，我们必须知道什么处于系统的边界上，从而可以确定输入的开始和输出的目的地。例如，在打印工资单的系统中，支付信息可能来自公司的计算机，系统输出可能是发送到邮箱的工资单的集合，送到适当的接收者手中。在图1-9所示的系统中，我们可以了解边界并且理解实体、活动和它们之间的关系。

图1-9 工资单产品的系统定义

1.5.2 相互联系的系统
边界的概念之所以重要，是因为几乎不存在与其他系统无关的系统。例如，呼吸系统必须与消化系统、循环系统、神经系统以及其他系统交互。呼吸系统没有神经系统就不能发挥作用，循环系统没有呼吸系统也不能正常工作。这种相互依赖可能是非常复杂的（实际上，由于我们不能认清生态系统的复杂性，已经引起并加剧了许多环境问题）。但是，一旦描述了系统的边界，就很容易了解什么在系统内部、什么不在以及什么超出了边界。

此外，一个系统存在于另外一个系统的内部也是可能的。描述一个计算机系统的时候，通常是集中于实际系统的一小部分。这种集中使得我们能够定义和构建一个比包裹它的系统简单得多的系统。如果仔细记录那些影响系统的系统之间的交互，即使集中于更大系统中的较小部分，也不会有任何损失。

我们来讨论一个例子，看一看是如何做到这一点的。假定要开发一个水系监控系统，该系统在整条河流经过的很多地点采集数据。在数据采集点完成若干计算，其结果被传送到中心站点进行汇总报告。这样一个系统的实现方式可能是：有一个中心站点的计算机，它与数十个在远程站点的小型计算机进行通信。其中，必须考虑很多系统活动，包括收集水质数据的方式、在远程站点进行的计算、与中心站点的信息通信、通信数据在数据库或共享数据文件中的存储以及根据数据创建报告。可以把这个系统看成是一些系统的集合，其中每个系统都有特定的目的。尤其是，我们可以只考虑较大的系统的通信方面，并且开发一个通信系统将数据从远程站点传送到中心站点。如果我们仔细地定义通信系统和大系统之间的边界，通信系统的设计和开发就可以独立于大系统来完成。

整个水系监控系统的复杂性要比通信系统大得多，因此，通过对分开的、较小的部分进行处理可以简化我们的工作。如果边界定义详细、正确，那么根据较小的部分构建较大的系统是相对容易的。通过以分层的方式来考虑较大的系统，可以按图1-10所示那样描述系统的构造过程（以水系监控系统为例）。一个层次本身就是一个系统，但是，每一层及其包含的那些层次也构成一个系统，图1-10中的圆圈表示它所代表的系统的边界，所有圆圈的集合构成了水系监控系统。

一个系统可能包含另外一个系统，这一点很重要，因为它反映了这样一个事实：一个系统中的对象或活动是外层所代表的每一个系统的一部分。因为每一层都会引入更多的复杂性，所以随着每一层系统的加入，要理解任何一个对象或活动就会更加困难。因此，首先集中于最小的系统是最简单的方法，这样便于更好地理解随后的系统。

我们使用这种思想来构建一个替换旧版本的新系统（无论是手工方式还是自动方式）。我们希望尽可能多地理解新、旧系统是如何运行的。通常情况下，两个系统之间的差别越大，设计和开发就越困难。之所以出现这样的困难，不仅是因为人们倾向于拒绝改变，而且这种差别使得系统难以学习。在构造或合成大系统的时候，把新系统的构造作为一系列递增的中间系统是极其有用的。不是从A系统直接构建B系统，而是从A到A，再到A，然后到B。例如，假定A是一个包含3个主要功能的手工系统，B是A的自动化版本。我们可以将A系统定义为一个新的系统，它只有功能1是自动化的，而功能2和功能3仍是手工的。然后，A有自动化的功能1和功能2，但其功能3仍是手工的。最后，B具有3个自动化的功能。通过将A到B的“距离”分成三段，我们就得到了一系列小的问题，这比整个问题要更容易处理。

在我们的例子中，两个系统非常相似。它们的功能是相同的，但是实现的方式不同。但是，目标系统常常与现有系统存在着巨大差别。尤其是，通常希望目标系统不受现有硬件和软件所强加的约束的限制。增量开发（incremental development）方法可以包含一系列阶段，其中每一个阶段都使前面的系统不受当前系统约束的限制。例如，阶段1可能增加一个新硬件，阶段2可能替换执行一组特定功能的软件。系统逐渐地从旧的软件和硬件中脱离开，直到它体现出新系统的设计。

因此，系统开发可以首先在实际系统中实现一组变化，然后增加一系列变化以生成完整的设计方案，而不是从当前一步一下跳到将来。使用这种方法，我们必须同时从两个不同的方面看待系统：静态地和动态地。静态视图告诉我们系统如今如何运行，而动态视图展示系统如何演变成最终的系统。缺少任何一方面都是不完整的。

本文仅用于学习和交流目的，不代表异步社区观点。非商业转载请注明作译者、出处，并保留本文的原始链接。

从软件工程角度看测试 近几年的软件测试岗位，开始逐渐变为了QA，即质量保障。看似只是一个名词的变化，其实背后对应的是企业对软件测试这个岗位有了更多的要求和期望。当然也有同学会自嘲自己是点工、PageClienter等，面试造火箭入职拧螺丝的背后也存在很多无奈。
『软件工程12』软件工程实践方法——软件测试 在一项系统软件完成之后，且在上线之前，需要经过不断的软件测试，找出 bug 和错误，不断修补，才能正式上线。在下面的这篇文章中，将讲解软件测试的一些基础知识以及测试用例的设计和软件测试的步骤。 接下来开始进行讲解。
关于软件工程的几点思考 来阿里已经很长一段时间了，从刚开始来我就想写点关于软件工程，服务化和开发效率的个人理解，却一直没有想好怎么写，一直在心里筹划思考该如何准确地表达我所想的内容，也能够给别人带来一些有价值的信息，但是拖了很久了，想想还是写出来罢，没有必要追求那么完美，欢迎拍砖。（顺便说下，有观点认为拖延症患者都有或多或少的完美主义倾向，处女座的同学验证下哈。） ## 1 什么是软件工程？ 服务化其实是一个软
《软件工程方法与实践》—— 1.2 什么是软件 既然软件工程的主角是软件开发，那么在现代社会中，软件担任的究竟是一种什么样的角色呢？我们使用的大部分软件同时担任着两个角色，既是软件产品，又是软件工具。软件产品是指为最终用户使用并带来益处的具有商业价值的软件系统。
《软件工程（第4版?修订版）》—第1章1.4节软件工程涉及的人员 软件开发的一个关键部分是客户与开发人员之间的交流，如果交流失败，那么系统也将失败。必须在构建有助于解决问题的系统之前，理解客户想要什么以及他们需要什么。要做到这一点，我们把讨论的重点转向软件开发所涉及的人员。
《软件工程方法与实践》—— 第一部分 软件工程基础 本部分将介绍软件工程的基本概念、软件过程及其模型和敏捷软件开发方法，包括软件工程概述、软件过程、软件过程模型和敏捷软件开发方法四章内容
《软件工程方法与实践》—— 1.6 小结 软件是计算机系统中与硬件相对应的另一部分，是一系列程序、数据及其相关文档的集合。软件具有复杂性、一致性、退化性、易变性、移植性和高成本等特征。软件工程是由于软件危机的出现而被提出的，其主旨是以工程化的思想进行软件的开发与维护，目的是高效率地生产出高质量的软件。
《软件工程方法与实践》—— 2.4 软件生存周期 一般地，软件生存周期可划分为定义、开发和运行3个时期，每个时期又细分为若干个阶段。把整个软件生存周期划分为若干阶段，使得每个阶段有明确的任务，使规模大、结构复杂和管理复杂的软件开发变得容易控制和管理。 通常，软件生存周期包括问题的定义与可行性分析、项目计划、需求分析、软件设计、编码与测试、运行与维护等阶段，每个阶段又包含一系列的活动，可以将这些活动以适当的方式分配到不同的阶段去完成。
异步社区 异步社区(www.epubit.com)是人民邮电出版社旗下IT专业图书旗舰社区，也是国内领先的IT专业图书社区，致力于优质学习内容的出版和分享，实现了纸书电子书的同步上架，于2015年8月上线运营。公众号【异步图书】，每日赠送异步新书。