软件工程：抽象与建模

1.1准备

特性描述：工程是将科学的洞察力和人类的需要转化为技术产品的数学、职业、规范、工艺和艺术。

软件工程的科学是计算机与计算的科学。

特性描述：计算机科学是什么样的“事物”可以(或能够)存在于计算机“之中”,也就是说，数据(即值及其类型)和进程，及其函数、事件和通信的研究和知识。

特性描述：计算科学是如何构造这些“事物”的研究和知识。

工程师跨越科学和技术的桥梁，从科学结果中创造技术，分析技术以确定其是否具有科学价值。

学习这几卷的学生不必熟悉下列计算机科学主题的学科：自动机、形式语言和可计算性,程序设计语言语义,类型理论,复杂性理论,密码学及其他内容。

希望学习这几卷的学生应熟悉下列计算科学主题：函数式程序设计,逻辑程序设计,命令式程序设计,并行式程序设计,以及算法和数据结构

关键词 艺术、规范、工艺、科学、逻辑和实践这些关键词暗示出了我们对程序设计的基本方法。但是软件工程却超出了上述计算机和计算科学主题所暗示的内容。软件工程超出了算法和数据结构和程序设计语言技巧。这些计算机和计算科学技巧可以而且必须首先被个人、专业的和学术上受到教育和训练的程序设计人员适度地掌握。软件工程等同于令由两个或者更多的程序设计人员组成的小组卓有成效地一起工作。并且软件工程是关于生产能够被进一步使用在由其他开发者所进行的更大型计算系统开发中的软件。

为了达到后面的这些期望，软件工程必须增加计算机和计算科学的知识，如项目和产品管理的学科。通过项目管理我们通俗地指：项目领导者如何规划(调度和分配)开发资源，如何监测和控制“进程”,等等。通过产品管理我们通俗地指：软件公司如何确定一个产品或其自身产品的策略，也就是说，从事哪些项目，营销哪些产品，如何定价、服务和扩展等等。

我们细化许多项目管理事项：(1)开发过程的选择和规划，(2)资源的调度和分配，(3)工作进程的监测与控制，(4)质量检测与控制：确保和评估，(5)版本控制和配置管理，(6)遗留系统，(7)成本估算，(8)法律问题，等等。

(1)过程(选择和)建模是一个项目管理问题。工程师如何推进，先做什么后做什么等等?不只有一个做事情及在阶段、时期及步骤中推进的正确方法，实际上有许多合适的过程模型。首先，开发过程由问题框架确定，其次，由问题的新颖性确定；第三，由程序设计人员和管理的经验确定，等等。

(2)资源规划、调度和分配是另一个项目管理事项。在规划中，我们决定要做哪些事情。在调度中，我们决定什么时候做这些事情。而在分配中，我们决定使用哪些资源(资金、人力、机器等等)。

(3)工作进程监测和控制扩展了项目管理所关心问题的列表。一旦项目在规划后完全启动，需要经常性地持续地检查进展。如果进展与计划一致，则继续。但是如果计划没有被遵循，则通过可能的对计划的变更、开发资源的重新调度和/或重新分配以进行控制。

(4)质量确保和评估的监测与控制进一步扩展我们的项目管理所关心内容的列表。软件产品所使用的应用领域知识的网络，期望软件产品所实现的成百上千的绝大多数彼此无关需求的纷繁芜杂，以及软件设计技巧和工具(语言等等)的“巴比伦塔”,所有这些都使得对产品质量所指内容进行仔细地系统描述和对开发过程进行仔细地检查成为必要，其目的是为了确定质量目标是否能够达到或处于危险。

(5)版本控制和配置管理：在软件开发中，程序设计人员通常构造代码的几个版本或“生代”。必须监测和控制这些生代和版本。这被称作版本控制。这可能是一个相当大的任务，通常说来，就算不到上千，也有数以百计的这样的可选或者补充版本。一些这样的版本可能进入产品的发布当中，其他的一些版本的子集则进入到相关产品的其他发布当中。将这些版本组合到软件产品中被称作配置管理。

(6)遗留系统：在软件客户(用户、需方、买方)操作通常是由“年代久远”的部分组合而成的计算系统的任何时候，必须对其进行维护：调整以适应新的硬件和软件，完善以提供相关的性能，(通过消除隐错)来修正。所有这三种维护方式都逐渐变得有问题起来，因为原始的软件所使用的程序设计语言不再有足够的、更别提“最新的”编译器和相关的支持工具，或者其文档的风格基本上对新生代的程序设计人员来说是陌生的，或者根本没有文档。这种软件和这些种类的问题构成了遗留软件的概念。

(7)成本估算：两个成本估算的问题可能是相关的：估算开发新(或者维护旧)软件的成本，以及为软件估算有竞争力和盈利的价格。成本估算的问题与下列问题相互交织：软件开发过程模型、项目和产品管理、质量确保、版本控制和配置管理、遗留系统，等等。

(8)与软件相关的法律问题：有许多法律问题与软件相关。有软件专利，其确立知识和财产权利。有软件课程认定，也就是说，大学或学院软件工程课程的通过。有软件公司认定：一般来讲，(通常且典型地由或通过某ISO相关代理)批准为可信的软件开发者。有软件工程师认证：(通常由某个国家工程协会)批准某人为专家。最后有软件产品认证：(通常由某个国际代理或者其他)批准特定的软件产品达到质量的特定标准。

软件工程根深蒂固于程序设计之中：(1)在软件设计之中，(2)之前在构造软件需求之巾，(3)之前在理解应用领域之中。

这几卷花费大多数章节在软件工程的开发方面：关于开发适当的对应用领域理解的原则和技术，关于开发适当的软件需求的原理和技术，关于开发适当的软件设计的原理和技术。这几卷基于非形式和形式语言的工具为描述领域、规定需求和规约(设计)软件展开这些原理及技术。

 

 

软件工程三部曲

这是一个新的贡献：论述了领域工程、需求工程和软件设计的三部曲(Triptych)。该方式强调领域工程，“从理念和逻辑上来说”,先于需求工程，而需求工程从理念和逻辑上来说先于软件设计。这个最新的贡献就是赋予领域工程以核心角色。

1.2.1软件和系统开发

尽管主要是关于软件工程的内容，我们在非常大的程度上却不能避免涉及到更加宽泛的计算系统工程。

特性描述：通过计算系统，我们指共同实现某需求的硬件和软件的组合。

典型地一个计算系统分布在本地和全球，因此典型地需要大量的数据通信硬件和软件。在下文中，当我们说“软件”或“系统”的时候，通常我们可以用更加宽泛的术语“计算系统”来替代。

1.2.2三部曲引出

我们将三部曲的三个组成部分的作用说明如下：在我们能够(3)设计软件之前，我们必须理解(2)对该软件的需求。在我们能够规定(2)需求之前，我们必须理解应用(1)领域。我们反复讨论的是我们如何解释上文提到的“理念和逻辑上”的优先顺序。但首先我们将看一下三部曲的三个组成部分，或者即如我们所称作的软件开发的三个阶段。

1.2.3领域工程

特性描述：通过领域工程，我们指领域描述的工程。

特性描述：通过领域，我们指(i)人类活动的范围，(ii)和/或半机械化或全机械化的行为，(ii)可以被描述的自然范围，潜在地能够得以部分或完全计算的部分或全部。

例1.1三个领域与上述列举(i-iii)相关的(各个)领域的例子：(i)账簿登记；(ii)用船从某起点港口经由其他港口向目的港口的货物发送；(iii)行星运动，即天体力学[450]。

当我们可以使用客观的方式来描述一个领域的时候，我们理解了该领域。

特性描述：通过领域描述，我们指对下列领域刻面的属性的用陈述式表达的描述：内在(基本部分、不变部分、核心部分)、企业(商业、机构)过程、技术支持、管理和组织、规则和规定、人的行为和可能的领域的其他方面。

领域描述解释事实上的领域。不能有任何对所要软件的需求引用----需求在后面才出现!另外，不能有任何对所要软件的引用--软件同样是在后面才出现!因此，领域描述与信息技术(IT)或软件没有任何关系--除了已经在领域中安装或部署的以外，并且只有那些对已存在的IT或软件的引用才被认为是相关的。

例1.2 物流领域我们并没有描述该示例领域，只是用几乎是描述性的语言说明一下：物流领域包括

(a)货物的发送者和接收者；

(b)物流公司，它们安排发送者和接收者发送或接收货物；

(c)运输中心(如港口、火车站、卡车站、机场空中货物中心),这里货物可以向运输机加载或卸载；

(d)货运公司拥有的和/或运营的运输机(比如船、货物火车、卡车和飞机);

(e)货运公司(如定期货轮、铁路运营商、载重汽车公司、航空公司);

(f)货运线路网络(船运航线、铁路线、高速公路和空中走廊)。

可以提示一些其他的描述：运输路径是两个运输中心之间的连接。运输线路是一序列的一个或者多个连接路径。一些运输中心具有两个或更多种类，如港口和火车站、空中货运中心和卡车站等等。运输机根据固定的时间表沿它们的路线行进。运输机的费用表规定了两个运输中心之间运输货物每立方米的成本。

再重复一遍，领域描述描述事实上的领域。卷3第5章讨论了描述任意论域的原则、技术和工具，无论是领域、需求或软件。卷3的第IV部分讨论了适当的领域描述的原则、技术和T.具。领域知识需要从那些工作在领域中并为其所影响的人获取，也即引出。

1.2.4需求工程

特性描述：通过需求工程，我们指需求规定的工程。

需求是获取所需软件(即将交付的软件)的客户和该软件的交付人或者开发者之间的合同关系的自然结果。通过需求，我们指一组一个或多个对将被开发软件所期望的性质采用推定式表达的语句。需求必须从那些被该最终所获取的软件所影响的人得到。

例1.3 一些物流需求（本例接着例1.2）。

我们并没有例证一个真正的需求规定，只是提示一下其可能涉及的内容。物流系统需要软件系统对(至少)下列若干种类行为的支持：

　　首先我们例证一些领域需求。这是一些仅与领域相关的需求，其专业术语为领域术语。举例如下：

　　　　处理来自于可能的发送人对物流公司有关可能的运输路线、日程和成本咨询的软件支持；

　　　　处理来自于实际的发送人对物流公司请求货物的发送，以及货单的发行和将要发送货物的处理的软件支持；

　　　　对物流公司跟踪货物(在运输中心或是在预定运输机的运输公司)行踪的软件支持；

　　　　对进出运输中心的运输机管理、运输机卸载和装载、对来自于物流公司的货物的接收，和到物流公司的货物的发送等的软件支持。

　　接着我们例证一些机器需求。这些是主要与将要构建的机器相关的需求，它们是：所需计算系统的软件+硬件，换句话来说，其专业术语另外一般还包括信息技术术语。举例如下：

　　　　该计算系统出现故障的时间间隔平均为两年；当该系统崩溃时，其最长时间为两个小时，等等。

　　最后，我们例证一些接口需求。这些是与领域和将要构建的机器同时相关的需求，是与机器和领域之间、领域中的人类用户及(其他)自然现象和领域中人造设备之间接口相关的需求。接口需求与领域和机器共享的现象有关。举例如下：

　　　　发送者和接收者应当能够从自己家里的电脑上通过标准的互联网浏览器确定他们自己货物的运输状态；计算系统应当为物流公司显示可放大缩小的路线网络，等等。

例1.4 将接着本例。

注意例1.3 是如何引入三种需求概念的：领域需求、接口需求和机器需求。

这种分解代表所考虑事物的语用分离。

　　领域需求，再重复一遍，是仅与领域现象相关的需求，即它们是其专业术语为领域术语的需求。

　　接口需求，再重复一遍，是与领域和将要构建的机器同时相关的需求，是与机器和人之间、领域中的人类用户及(其他)自然现象和领域中人造设备之间接口相关的需求。也就是说，与环境和机器共享的现象相关的需求。

　　机器需求，再重复一遍，是主要与将要构建的机器相关的需求，也就是说，所需计算系统的软件+硬件。换句话说，机器需求的专业术语另外一般还包括信息技术术语。

注意在粗略描述一些需求的时候，我们是如何依赖于前面已经描述过的术语。尽管我们并没有精确地描述那些术语。但是我们提示了对所有这些领域特定的术语的解释如何成为了领域描述的目的。类似地我们依赖于在其他的地方精确规约的机器(硬件+软件技术，即IT)术语!

同时请注意我们是如何“偷偷地的加入”领域、接口和机器需求这些关键概念到例子中去的!卷3第五部分(第17-24章)讨论了关于适当的需求规定的原则、技术和工具。

一种流行的需求观点做了下列区分：用户需求、系统需求、非功能性需求。我们如何来看待它们? 用户需求形成了一个完整的需求集合：领域、接口和机器需求。

　　系统需求也是如此。

　　非功能性需求是我们所称之为的一些接口需求和大部分(如果不是全部)的机器需求。这是如何实现的呢?

　　用户需求不必完全，正如我们所称之为的那样，它们可以是粗略描述，尽管典型情况下它们都是结构非常清晰而且交叉索引非常仔细的，它们构成了系统需求开发的输入。

　　系统需求必须是一致和相对完全的：它们“改进”用户需求，且构成了软件设计的输入。

1.2.5软件设计

软件：代码和文档

特性描述：通过软件，我们不仅仅指计算机能够运行所基于的代码，同样也指对该代码的适当使用所必须的所有文档编制。这包括：

　　企业过程再工程手册，对于需要获取计算系统，并使用其来进行最优运作的企业(机构)来说它们是必要的；

　　安装手册，当最初安装该计算系统时它们是必要的；

　　用户培训和日常使用手册，在对将来的系统用户的培训和被安装系统的日常使用中需要它们；

　　维护手册，在被安装系统的日常设备管理((适应性)升级或降级、性能(完善性)提高、错误改正)中需要它们；

　　处理手册，当拆除系统的时候需要它们。

理想状态下软件同样也包括软件确认和验证历史的精确记录：参与者反应、验证和测试，包括测试套件及其预期结果和使用其进行实际测试的实际记录。通过测试套件，我们指作为测试输入的数据集。

 

软件设计，I

特性描述：通过软件设计，我们指(所需)软件的实现，不仅仅是编码，还有其阶段和逐步开发和文档编制。

开发时期、阶段和步骤

特性描述：通过软件开发，我们指领域描述、需求规定和软件设计的组合开发。

软件、领域描述和需求规定通常都是非常复杂的。因此这些都需要根据所考虑事物的分离原则(即分治法)来开发。因此我们将领域描述、需求描述和软件设计的开发时期分为阶段和步骤。

软件设计，Ⅱ

传统上我们认为在软件设计阶段，首先建立软件体系结构，它实现了领域需求、接口需求和机器需求的一个“高层设计”。

在第二个阶段，我们建立程序构件，它为软件设计了总体和详细的模块结构。

最后阶段或者说实现阶段，它通常由许多步骤构成，包括平台重用设计，其中检查了可用的软件构件在实现中可能的重用；模块化，或者对象化，其中出现了从程序组织到模块的细粒度分解；

最后是编码本身，其中最终的代码行得以规约。也即，用某种程序设计语言和对运行时系统程序和(其他平台)构件的调用所表达的对机器的指令。

在例1.4中，我们给出了非形式表达的软件体系结构设计。

 

例1.4 物流系统软件设计 （本例接着例1.2和例1.3）

我们没有举例说明一个适当的软件设计规约。我们只是提示它可能涉及到的内容。

物流计算和通信系统实现如下：每个发送者或接收者，每个物流公司，每个运输公司，每个运输中心和(一个运输公司的)每个运输机都实现为一个独立的、并发运行的带有其自身状态的进程。所有的进程都不会共享全局状态构件，而是基于同步和通信消息运行。货物没有实现为对象，即独立进程。共享数据实现为独立的进程，其状态表示共享数据(即数据库)。

 

1.2.6讨论

一般问题

本节结束了软件开发三部曲核心概念的说明。总之，我们强调在三个软件开发时期之间的两组关系。三种(和三阶段的)工程开发可以总结如下：领域工程中，我们描述事实上的领域；在需求工程中，为了支持我们所想拥有的在领域中的行为，我们为其规定对软件(即计算系统)的需求；在软件设计早期阶段，我们规约软件为我们对其所确定的内容。

这三种文档的关系源于各自的开发阶段。

领域描述是陈述式的，正如我们所严肃地认为领域描述本质上的确如此。我们必须确保描述了领域所有可能的行为，包括我们通常期望的正常运行的行动者，同样也包括错误的、有故障的、不那么勤勉的、草率的甚至完全是犯罪的行为。

需求规定是假定的，正如我们命令软件所表现的那样。

自然地需求规定将关于正常运行的行为并且试图确保所有行为者的正确行为，无论是人或是机器。

软件规约是命令式的，也就是说，是强制性的。

当领域描述被形式化时，“可能”的阻碍就没有了。当需求规定被形式化时，“必须”的阻碍也就类似地没有了。形式领域描述、需求规定和软件(设计)规约的共同之处在于一定的“权威性氛围”,而领域描述是绝不会有这样的“氛围”的。领域描述只是一个抽象，或者某一现实的模型，但它不是该现实，而需求规定却用于表示将要实现的软件的精确模型。

软件工程的三部曲方法是这几卷的核心。我们将尽力说明清楚领域描述、软件规定和软件规约开发的原则、技术和工具。

　　在领域描述中，我们发现如领域属性、参与者及其观点和领域方面的这些概念。

　　在需求规定中，我们发现如领域需求、接口需求和机器需求的这些概念。

　　与上述这些无关，我们发现如领域投影、例示、扩展和初始化的需求技术。

　　在软件设计中，我们发现如软件体系结构、程序组织和结构、模块化概念。

1.3文档

本节包括许多例子以及阐明许多文档编制的原则、技术与工具。文档编制在软件工程中非常普遍而且重要。

在前一节中我们看到软件开发需要三个主要的时期，在时期中可能的若干阶段和阶段中可能的若干步骤。对这些步骤的执行产生了文档。这些文档是关于领域描述、需求规定和软件规约的。

除了纸质或电子文档，步骤、阶段和时期没有产生任何其他的东西。所以问题就是：什么种类的文档?

在本节我们将简要的概述三种源于步骤、阶段和时期工程的文档。很重要的一点是读者要将论域记住，领域、需求、软件、前两者(领域和需求)、后两者(需求和软件)或者三者(完整的开发)。也就是说，各种各样的文档，甚至内容最为翔实的那些，全都有一个特定的论域在头脑中。这必须在开始的时候清晰地陈述出来，以免开发合同的一方在刚刚开始就混乱不清了!

1.3.1文档种类

出现于开发过程的文档基本上有三类，因此它们也应当是开发者的目标。这些文档是：

　　(1)信息文档，或者文档部分如合作者和当前的情况、需要和想法、产品概念和措施、范围和区间描述、假设和依存关系、隐式/派生目标、纲要、简要设计、合同、日志；

　　(2)描述文档，或者文档部分如粗略描述(“头脑风暴”的记录)、术语、叙述、形式模型；

　　(3)分析文档，或者文档部分如描述性质验证、开发变迁(也即开发步骤)正确性验证、形式和非形式描述确认。

我们将简要地回顾这些种类的文档，既考虑其语用：为什么它们是必要的；也考虑其众多的数量：为什么有这么多看上去不同种类的文档。

1.3.2时期、阶段和步骤文档

一个开发时期产生了一个信息、描述和分析文档的全面的、定义性集合。一个开发阶段产生了类似的一个信息、描述和分析文档的全面的集合，或者产生了一个相对完全的领域、接口或者机器需求的规定。

子时期和阶段之间的界限，以及它们的全面性之间的界限并不是明显的。阶段和步骤的概念仅仅是出于语用上的目的。你可以继续定义子步骤等等，但是我们避免这样做。让实际的项目来确定更细粒度的需求吧!

如果需要区分时期和阶段，那么阶段文档的完整集合代表在时期中多于一个开发“阶段”。

开发步骤仅产生了一个全面的文档集合中的一部分，比如：(只是)作为子步骤的一个信息、描述或者分析文档或文档部分的完整集合、这些文档中的一个或文档部分。随着我们在这几卷中逐步深入还会有更多。

1.3.3信息文档

特性描述：信息文档，通过其我们指提供信息的文档或文档部分，它不必描述一个可指的显然的现象或概念。

如其名所示，信息文档给出具有多种形式的信息：信息文档包括那些察觉的或已经清晰表达的需要、产品概念和措施、范围和区间描述、假设和依存关系、隐式/派生目标、纲要、合同、设计概要，等等。

当前情况文档编制

对软件开发，或需求规定，或领域描述的需要通常来自于当前的情况。当前需要可能是领域没有得到良好的理解，或者是需要软件。因此专业的软件开发项目会生成一个信息文档--两三页--它给出产生需要的当前情况的信息。

需要文档编制

需要涉及到察觉的或者实际的对所要产品的需要，无论是领域描述、需求规定、软件设计(即规约),还是像最经常的情况那样，只是软件本身。需要可以通过多种方式来表达：我们必须理解领域；我们必须建立需求；自动化人类那些无趣、令人厌烦的过程；加速缓慢过程的软件；等等。如果可能的话，需要一定要被量化。

产品概念和措施

产品概念和措施涉及到“头脑风暴”或想法(“梦想”)。也就是说，论域“包含”的事物或将要包含的事物，建议者对该“软件”的目标是什么,在更大的社会经济环境中，该产品服务(或实现)的作用是什么。也就是说，开发者和/或客户的策略目标是什么,它如何补充以前的产品，和/或它为下一代的产品如何开辟道路，或成为下一代的产品。

设计概要

设计概要涉及那些描述将要进行什么样的项目的文档：

　　为了什么样的论域，特定地(目标是特定客户),或者一般性地(目标是一类非常大的这样的客户),或者两者之间。

　　该项目是一个普通的开发，或者是一个研究，或者是包括研究和开发的某高级项目。

　　最后它同样包括那些一般性的交付中所期望的事物，时间期限、成本、涉及的研究机构等等。

通常范围和区间描述是设计概要的一部分，或者就与设计概要相邻。下面我们对其进行探讨。

范围和区间描述

范围和区间描述涉及项目中所处理的论域中更加特定的主题，也就是说，目标和模式范围，比如：铁路或保健、金融服务；新的开发(包括研究与开发)或维护，或其他。目标和模式区间，比如车辆监测和控制、电子版患者期刊、股票交易；库存现有货物广告、某类的一个产品，或其他产品。

纲要

纲要涉及所需软件的一个简要(即短小的综述)刻画，无论是领域描述、需求规定，还是软件设计。纲要就像是一个电影预告片。它用几句话讲述整个事情(领域、需求或软件)所相关的事物。纲要不是一个描述(规定、规约),“但几乎”是。它提及论域中所有最为重要的现象，它们的实体、类型、值、动作、事件和行为。它提及它们的语义和语法，但是并不完全。并且一个纲要将这些现象构件与它们的语用“联系”,即它们所起的作用，等等。纲要通常构成了合同的一个重要的介绍部分。

合同

合同描述了合同方、主题事项和考虑事项。

合同涉及指定立约人(合同方：客户和开发者)的法律文档；并且其规定什么将会被开发：如果是软件，则通常合同会涉及已经存在的需求规定；如果是需求，则合同通常会涉及已经存在的领域描述；或者如果是领域描述，则范围和区间描述将是非常重要的文档部分。另外    (考虑事项)合同规定开发成本(预计):如果开发软件，则该预计将是有约束力的。如果开发需求，则成本可以基于固定的每小时费用和一些通常可协商的粗略时间预计。由于在合同方之间有许多不可预计的交互会发生，是不可能给出精确的数字的。或者如果开发领域描述——在这种情况下，该项目基本上是个联合研究工作——则成本通常是可以协商的，比如以月为单位来付费。合同(更进一步的考虑事项)将会涉及法律事宜。许多其他的考虑事项可以是合同文档的一部分。

讨论

我们已经概述了必要的信息文档。我们强调开发者(和/或客户)在极端情况下的每个时期、阶段中，在一些情况中的开发步骤及其变迁中不得不“重复”这些文档。也就是说，信息文档可能对于每个和所有的三部曲时期来说都是需要的：领域、需求和软件设计。

我们选择了文档(和文档编制)这个措辞用以表明你可以将上述每个列出的信息文档类型看作对个体的、独立的“装订”文档实例的指定。对于下一类的文档，描述文档，我们选择的措辞允许其各种各样的类型来指代能够“混合”(编制在一起)成为更大文档的文档部分。

 

1.3.4描述文档

特性描述：描述文档，通过其我们指描述显然的现象或概念的文档或文档部分。

 

这里在非常特定和狭窄的意义上使用术语描述(describe、description)和描述的(descriptive)。描述指代(即某文本用文字表达)物理上存在的某自然部分(它以通常受到物理定律约束的物理行为为中心),或者世界的某人造部分(它以人类行为为中心，包括人类行为与人工制品的交互),或者这两类世界的组合。

因此正如我们所使用的术语描述，它趋向于关注最终可能“存在于计算机中”的事物。也很有可能我们有关一个领域的描述是不可计算的，是不可能由计算机模仿的。然而需求规定“缩减”其潜在的领域描述，并且确保其所需要的也是可计算的。所以看法，感情，超自然的、政治的或其他类似的主观文本在这里不被看作是描述。

从上面可以看到，并且它也会在后面反复出现，即：精确地界定什么时候是一个描述(规定、规约),而且什么能够被描述，也就是说，什么能够存在并不是一个简单直接的事情。

(因此)我们考虑三种描述：领域描述、需求规定、软件设计。我们指出我们同义地使用三个不同的术语：描述、规定和设计(规约)。

　　领域描述是关于已经存在的事物，即“实际的世界”。Michael Jackson将领域描述称为陈述式的。

　　需求规定是关于我们对软件的期望，即“我们所想要的世界”。 Michael Jackso将需求规定称为假定的。

　　软件(设计)规约则概括了软件设计结构，也就是说，特定类型、值、函数、事件和行为的规约。Michael Jackson将软件设计称为命令式的。

 

描述文档种类和类型

我们了解基本上有两个种类的描述文档：非形式的和形式的。我们了解基本上有四种类型的描述文档：粗略描述(记录“头脑风暴”结果的文档)、术语、叙述、形式模型。你可以将后两个类型(描述和形式模型)看作一个类型，“适当描述文档”的类型，非形式和形式的。我们将使用上述的分类法。

 

粗略描述

特性描述：粗略描述文档，通过其我们指一个描述文档，它是一个草稿，其描述是不完全的并且/或者不是良好组织的。

通过探索的、实验性的方式，粗略描述起到了理解论域中核心概念的作用，由此也起到理解衍生概念的作用。在开发粗略描述的过程中，粗略描述作为确认核心概念及它们的关系的方法。该确认过程具有极端的重要性。它具有分析的特性。

 

术语

特性描述：术语文档，通过其我们指描述文档，它使用系统的但不必完全或详尽的方式列出并简要解释许多术语。

 粗略描述步骤和概念形成分析步骤一起起到了确认和统一重要概念(即无论是领域、需求或者软件中的现象的抽象)的作用。该确认包含有命名这些概念的这一点。一个所有这些概念的名字和它们的特性描述(描述、解释、定义)的列表被称为术语。我们也将该列表称为术语表，或者词典，或者甚至是本体论。

 我们认为在软件开发的每一个时期中进行下列四个术语学相关的动作是非常重要和必要的：

　　(1)建立(面向时期的)术语；

　　(2)使用且遵守该术语；

　　(3)更新，也即维护该术语，且令所有使用该被引用术语的文档反映这些变化；

　　(4)使得该术语可供使用。

叙述

特性描述：叙述文档，通过其我们指描述文档，它使用自然语言，但也很可能是(应用领域特定的)专业语言来系统地和适度全面地解释指定论域的实体、函数和行为(包括事件)。

叙述就是“讲述一个故事”。这里将要讲述的故事(叙述)是选定论域的故事，无论其是一个论域，或者论域的一部分，还是需求，或者软件设计。该叙述必须使得听众(即读者),当然还有叙述者能够形式化该故事：也就是说，我们将以下看作对叙述的一个约束：可以给它们赋予数学(也即计算科学)的模型或者可以在数学上进行特性描述。所描述的事物是可计算的不是对领域描述的约束(可以通过计算机来模拟的(机械化的))。领域需求规定和软件设计规约构成计算模型实际上是对这两者的约束。

可以通过以下论述来说明对形式化这一坚持是合理的：领域需求必然包含可计算的事物。毕竟，它们是关于计算系统的。软件设计当然必须也包含有可计算的事物。

但是为什么我们坚持领域描述应当是可形式化的呢?

　　首先我们必须接受领域需求，如例1.3所提及的，来自于领域描述，并且我们希望该“来自于”操作能够得到非常好的形式上的理解。

　　其次，我们必须接受，最初的任务以及最近的这两千五百年来对其成功的探索，就是去形式化现实世界的现象，先是物理现象，现在则是人造现象。因此为何我们不对领域也尝试一下呢直到我们实际上拥有了形式模型的时候，我们才能说理解了领域本质的部分。

　　第三，必须理解我们只是试图形式化领域的语义和句法的方面，而不是其语用意义。

　　最后，我们必须接受，今天2005年11月2日，我们并不十分了解如何形式化领域和需求的方方面面!这最后一句提示尤其适用于领域描述、接口和机器需求规定。

这样任务就明确了：主要描述可以或者应当被形式化的事物。非形式叙述的方式源自于以下信条：首先给出实体类别的文本(即类型：抽象类型(分类)和具体类型)。然后在如果需要和在需要的时候，假定任何固定的事物(即常数)、例示(即值)。接着假定应用到实体上的所有函数(即观测器、生成器、谓词、辅助函数),并刻画这些函数：从声明其应用到的   (输入)实体的类型和作为结果所产生的(输出)实体的类型开始；接着刻画输入和输出之间的函数关系。类似的确认行为(即过程);及它们的交互(即其共享事件、如同步和通信)。

 

形式模型

特性描述：形式文档，通过其我们指使用形式语言表达(某论域)的模型的文档。

 

形式模型是使用某数学记法或某形式语言表达的模型。数学表达式允许传统但精确的推理，就如那些数学教材中通常所做的那样。形式语言是具有精确的句法，精确的语义和数学逻辑证明系统(即一个能够进行形式推理的证明规则集合)的语言，就如那些数理逻辑的教材中所做的那样，但在这里稍有变化。非形式叙述和形式模型可以在文字上交织在一起，就如我们经常在数学和物理教材中所看到的那样。非形式叙述和其形式模型之间的关系必然是非形式的。也就是说，该关系的正确性永远无法得到证明，它必须得到确认。

第1、2卷包括许多为构建适当的形式模型而给出例子、原则和技术的章节。特定领域、需求和软件设计形式化的原则和技术则在第3卷的第IV～VI部分予以讨论。

 

讨论

非形式粗略描述，更加结构化一些，但仍旧是非形式叙述，而形式模型可以在独立的文档中予以说明，或者与分析文档组合和交织在一起。通常来说，粗略描述文档的编制方式不适于发布，除了给直接参与的客户和开发人员以外，并且通常也只是给开发人员。我们说非形式叙述、术语和形式模型可以构成可交付文档。并且我们通常认为粗略描述是开发企业所有文档。

 

 

1.3.5分析文档

特性描述：分析文档，通过其我们指其对象为描述文档的文档。分析文档的文本分析一个描述文档。

如该术语所示，分析文档是其内容为其他文档(这里是描述文档)的分析的文档。我们考虑四种分析文档：那些表示以下内容的文档

　　(1)(在头脑风暴中)来自于粗略描述的概念的形成，

　　(2)形式和非形式描述文档的确认，

　　(3)描述性质验证，

　　(4)开发变迁(即开发步骤)正确性验证。

可能有其他的分析文档。例如：

　　其内容是分析所需计算系统行为方面的文档，比如基于排队理论研究所预期的接口反应时间；

　　基于复杂度理论研究所预期的机器计算时间；

　　基于引用模式的统计研究的字典或数据库散列算法的细节等等。

　　也可能包括有内容为分析实际问题的文档，比如项目和生产规划、监测和控制计算系统的基于统计研究的生产线流程(拥塞);

　　金融服务或电子交易计算系统的基于类似研究的公司现金流等等。

可以设想其他种类的分析文档。在这几卷中，我们将只考虑那些提及的文档。

 

粗略描述分析和概念形成

在描述一个领域、规定某需求或规约某软件设计中，最为重要的任务就是识别论域发展所围绕的核心概念。

　　一方面，领域中的这些现象是所想要的在软件或软件程序结构(数据结构、程序等等)中的工具。

　　另一方面在现实世界中的这些现象，这些(将在所需软件中显现出来的)工具或程序代码结构将(对于该领域来说)被概念化，或者当它们作为需求获取出来或存在于软件代码中时，实际上它们就是概念(抽象观念)。

　　因此我们了解了从通常可触知现象的具体的、显然的、现实的世界到概念的抽象、可理性感知但通常无形的世界的变迁。从可感知的事物，通过可想象的事物，到达“做进”软件中的事物，我们需要记录的正是这一变迁。

对于领域，我们这样做是通过：

　　首先进行头脑风暴，也就是说，通过粗略地描述领域描述，并且由此通过分析来识别领域概念。

　　然后，对于需求，通过构想来这样做。其中通过粗略地描述需求“规定”,并且由此通过分析来识别需求概念。

　　最后对于软件我们通过“角色分配”,也就是说，通过粗略的描述软件“设计”,并且由此通过分析来识别适当的软件结构。

以形成概念为目标的分析是一门艺术。恐怕最难学习的事情就是正确地对其进行处理，或者至少通过某种方式来处理，其中会出现令人高兴、优雅和实用的概念。但是阅读许多分析示例可能会有所帮助。

 

描述、规定和规约的确认

特性描述：确认文档，通过其我们指分析文档，它对于被描述论域的参与者来说验证了描述文档(8c.)的文本。

领域描述必须被确认，它们非常可能是由主要为开发人员组成的小组，在由客户人员组成的一个类似的小组的帮助下写成的。但是更大、更具代表性的客户人员组需要回顾领域描述以对其取得一致同意。需求规定亦是如此。

领域描述和需求规定确认必然是客户人员和开发人员之间交互的过程，亦必然是基于非形式叙述和术语描述的过程。这种确认是非常关键的：它必然是非形式的人为过程，其作用是获得正确的产品。

 

规约属性的验证

特性描述：验证文档，通过其我们指分析文档，它证明、模型检查或测试关于描述、规定或规约性质的陈述。

一个领域描述表示一个理论。描述只是领域的一个模型，而不是真正的领域。通过使用精确的自然语言表达，尤其是使用某形式语言表达，领域描述所指示的模型具有一些属性。所有这些属性的总和是该领域的一个理论。需求规定和软件设计规约亦是如此。

当给定了一个一致且相对完全的描述(或规定、或规约),我们可以非形式的思考这些属性。当我们也拥有一个形式描述(形式规定、形式[设计]规约)时，我们也可以形式地记录下来该推理。形式模型的优点是这些定理可以得到证明。对这些定理的证明提供了对描述更高层次的信任。

 

例1.5一个领域理论假定我们已经描述了一个铁路系统，它的线路和车站网络，它的列车时刻表，以及依据时刻表的实际列车运行。

让我们另外假定列车时刻表且运输以24小时为模：每日重复且总是准时的。现在只是由列车时刻表(和列车运行)非常间接地产生的一个性质可以是下面的Kirchhoff定律的一个变体：在相同的24小时中，对于网络中的任一车站，该车站列车到达的数量减去在该车站停止旅程的列车的数量，加上在该车站启程列车的数量，等于离开该车站列车的数量。

领域的信息科学模型可以成为理论，就像物理现象的模型一样，如牛顿力学、热力学等等。第3卷的第15章给出了领域理论的例子、原则和技术，它们对于建立如上所示的领域理论来说非常有用。

 

开发时期、阶段或步骤变迁的正确性

当我们从描述领域的时期变迁到对支持该领域行为软件的需求进行规定的时期时，我们正确性关联这一从后者到前者的变迁。当我们从对软件进行需求的规定变迁到对所需软件进行规约的时期时，我们正确性关联这一从后者到前者的变迁。当这些正确性关系被适当地陈述时  (如果我们要信任开发，它们也必须被适当陈述),能够对其进行非形式地思考。并且，如果描述、规定和(设计)规约得以形式地表达，这些关系亦是如此，则该推理可以得到形式地支持：可以对正确性进行形式证明。

 

时期能够分解为开发阶段，阶段之间的变迁可以得到正确性关联和讨论。类似地阶段能够分解为步骤，步骤之间的变迁可以得到正确性关联和讨论。

注意我们有时使用“能够”,有时使用“可以”。像数学家那样，我们总是能够尝试非形式地推理。但是如今并不是总是能够形式地证明属性和变迁的正确性。其原因可能如下：我们可能构建了一些笨拙的模型，使得难以证明。或者计算科学和规约语言设计者可能尚米研究和开发出适当的规约语言结构和证明系统。或者我们，这些开发者，还不太善于陈述和证明辅助引理和定理。或者我们在试图证明一个并非是定理的事物，一个为假的事物。

 

讨论

我们综述了在软件开发中可能出现的分析文档。至少有四种分析文档部分：概念形成、描述(规定和设计规约)确认、性质验证和正确性验证。一些分析文档是受灵感启发的，比如概念形成似乎就是如此。其他的分析文档是受人类交互指导的，比如确认就是如此。还有一些其他的文档是可以形式化的，比如性质和正确性验证就可以。