基于模型的软件开发

本书揭示基于模型的软件开发方法的核心原则，展示如何分离每一个项目的关注点，使得参与者能够为每个域特有的需要和特征进行优化。本书共分三部分，共有18章。第一部分（第1～6章）重点介绍面向对象方法诞生的历史背景，阐述面向对象的方法旨在解决的问题。第二部分（第7～13章）讨论面向对象开发的基本原则如何应用于MDB方法学中，如何定义稳定的应用结构或框架。第三部分（第14～18章）讲述如何利用动态模型描述动态计算需要。

H.S.Lahman，1957年在插件板上写了他的第一个软件程序。在接下来的十年，他作为勘探地球物理学家在很多重要的沼泽、沙漠和苔原的丛林中使用尖端技术，这些磨练了他的意志。然后。他回到学校学习经济学、运筹学和计算学。在接下来的30年中，他为MIS系统、科学和R—T／E环境开发软件。1982年。他成为一名面向对象开发的倡导者。20世纪90年代，他成为一名软件质量和开发过程改进的倡导者。

廖彬山，先后就读于南京大学数学系和北京航空航天大学计算机科学与技术系。现在是美国
CMU/SEI认证CMMI主任评估师（CMU/SEI-certified Scampi Lead Appraiser），北京国信
普道科技有限公司CMMI首席顾问，北京航空航天大学软件学院客座教授。目前主要从事CMMI的培训、咨询和评估工作及软件工程理论与方法的研究工作。迄今为止，已经成功地为几十家不同类型、不同规模、不同应用领域的企业进行了基于CMM和CMMI的咨询与评估工作，积累了丰富的实践经验，有效地解决了企业实际存在的问题。已经成功地为国内近百家企业提供了软件估算、软件度量与量化管理、功能点、统计过程控制、高成熟度组织的过程改进、个体软件过程（PSP）、团队软件过程（TSP）、需求工程、缺陷管理、软件测试、同行评审、持续风险管理、统一软件开发过程等专题培训，有效地提高了国内企业的项目管理和工程开发能力。

王慧毕业于北京航空航天大学计算机学院，工学博士，研究方向为软件工程和过程工程。她曾从事大型软件过程建模与模拟系统的需求开发、软件设计与实现、系统测试等工作。目前是一名咨询师，成功地为多家不同类型、不同规模、不同应用领域的企事业单位进行了敏捷开发方法、软件项目管理、CMMI、TSP和PSP等咨询工作，有效地解决了企业实际存在的问题。

马苏宏毕业于北京航空航天大学计算机学院，工学硕士，研究方向为过程工程的建模、模拟与正向工程。曾就职于IBM公司，担任软件工程师，有丰富的软件设计与开发经验。目前是一名业余的翻译爱好者。

译者序
前言
引言
第一部分面向对象开发的根本
第1章历史的视角2
1.1历史2
1.2结构化开发3
1.3宝贵教训8
1.3.1全局数据9
1.3.2巨程序单元9
1.3.3软件结构10
1.3.4缺乏内聚性10
1.3.5耦合10
1.4技术革新12
1.4.1图灵机13
1.4.2语言和方法学13
1.4.3集合和图16
1.4.4范式16
1.4.5数据流18
1.4.6状态机20
第2章对象技术22
2.1基本理念22
2.1.1可维护性22
2.1.2问题域抽象23
2.1.3OOA、OOD和OOP24
2.1.4主题25
2.1.5关注点分离26
2.1.6抽象层次26
2.1.7问题域抽象28
2.1.8封装29
2.1.9内聚性29
2.1.10逻辑不可分性30
2.1.11通信模型31
2.2广度优先处理（又称对等协作）32
2.2.1细化与转化33
2.2.2消息范式35
2.2.3对象特征36
第3章泛化、继承、泛型和多态39
3.1泛化39
3.2继承42
3.3多态42
3.4泛型45
第4章MBD路线图46
4.1问题域和计算域46
4.1.1问题域48
4.1.2计算域49
4.1.3转换50
4.2可维护性50
4.2.1领域分析50
4.2.2不变量建模51
4.2.3应用分区52
4.2.4静态视图52
4.2.5动态视图52
第5章不变量建模55
5.1什么是不变量建模55
5.1.1不变量56
5.1.2数据57
5.2好处58
5.3例子60
5.3.1银行ATM软件60
5.3.2硬件接口64
5.3.3折旧67
5.3.4远程POS输入示例72
第6章应用分区76
6.1为什么我们要关注76
6.2应用分区的基本概念77
6.2.1主题79
6.2.2客户端/服务关系82
6.2.3抽象层次84
6.2.4接口85
6.3识别子系统86
6.3.1将相同的实体抽象为其他子系统时，当前子系统是否存在不同的视角86
6.3.2是否存在客户端/服务的关系86
6.3.3服务是否比客户端更加详细87
6.3.4是否与其他子系统知识共享87
6.3.5是否与其他子系统行为共享87
6.3.6主题是否内聚87
6.3.7边界定义是否清晰88
6.3.8能否重用88
6.3.9是否被分布式网络环境绑定88
6.3.10是否针对不同的问题域88
6.4桥89
6.4.1消息范式，又是消息范式89
6.4.2桥模型91
6.5描述子系统92
6.5.1子系统描述93
6.5.2关系描述94
6.5.3需求分配94
6.6一个例子：宠物保健中心94
6.7过程106
第二部分静态模型
第7章第二部分路线图112
7.1什么是静态模型113
7.2知识和行为114
7.3实用的注释115
第8章类117
8.1抽象表示117
8.1.1为真实的东西建模118
8.1.2局限于子系统或组件中119
8.1.3逻辑不可分性119
8.1.4委托120
8.2类表示法121
8.3识别类及其职责122
8.3.1对象“突击”123
8.3.2用例变异124
8.4例子125
8.4.1传奇的银行ATM控制器125
8.4.2宠物保健中心：处置131
8.5使用序列图和协作图134
第9章类的职责137
9.1属性：一个类对象应该知道什么137
9.1.1定义和表示法137
9.1.2与数据存储不同138
9.1.3状态139
9.1.4抽象数据类型140
9.2操作和方法：对象必须做什么142
9.2.1定义和表示法142
9.2.2识别行为144
9.2.3拟人化148
9.3过程149
9.4例子150
9.4.1ATM150
9.4.2宠物保健中心：处置158
第10章关联165
10.1定义与基础165
10.2表示法170
10.3逻辑连接的性质172
10.3.1导航到知识与导航到行为173
10.3.2关联角色174
10.3.3关联路径175
10.4条件性178
10.5多重性182
10.5.1使用“一个”模型替换问题域的“一个或更多个”模型183
10.5.2为问题域关联提供二次关联184
10.5.3选择和参与185
10.6约束187
10.7关联类189
10.8识别关联192
10.9例子195
10.9.1ATM控制器195
10.9.2宠物保健中心：处置198
第11章引用完整性和知识完整性200
11.1知识完整性200
11.1.1及时性201
11.1.2一致性201
11.1.3快照和实时访问202
11.1.4依赖属性202
11.1.5属性标准化204
11.2引用完整性207
11.2.1标识与引用属性207
11.2.2关联循环209
11.2.3关系和面向对象范式：完全不同211
第12章泛化归来213
12.1子类化213
12.1.1表示法和规则215
12.1.2泛化和特定化216
12.1.3分类219
12.1.4包含多态223
12.1.5为什么是{相交，完整}的子集225
12.2多方向子类、多重继承与组合227
12.3泛化的备选235
12.3.1委托236
12.3.2参数多态238
12.3.3基本抽象238
第13章识别知识239
13.1面向对象知识的性质是什么239
13.2抽象聚合241
13.3挑选适合的抽象245
13.3.1抽象人们做什么246
13.3.2潜在实体知道哪些247
13.3.3对象抽象应当知道哪些实体知识的子集248
13.3.4主题是什么248
13.3.5抽象层次是什么251
13.4抽象是否需要结合实体知识252
第三部分动态模型
第14章第三部分路线图258
14.1第三部分路线图258
14.1.1一切都关乎行为259
14.1.2对象生命周期261
14.1.3异步解决方案262
14.1.4同步服务266
14.2动作语言269
14.3Mealy机、Moore机和Harel机270
14.4学习曲线272
第15章有限状态机273
15.1基本的有限状态自动机273
15.1.1表示法277
15.1.2契约设计的作用280
15.2寻找状态机283
15.2.1知识和行为283
15.2.2管理序列286
15.3一些例子295
15.3.1车库门遥控器295
15.3.2自动家庭厨房297
15.3.3空中交通管制系统297
15.3.4岩石298
第16章状态、转换、事件和动作300
16.1状态300
16.2转换305
16.3事件306
16.4动作309
16.5执行模型311
16.6命名约定313
第17章开发状态模型316
17.1设计状态机316
17.2例子325
17.2.1ATM控制器：字符显示326
17.2.2ATM控制器：调度器331
17.2.3ATM控制器：存款340
第18章抽象动作语言344
18.1AAL和ADFD345
18.2AAL语法346
18.3例子348
18.3.1车库门遥控器348
18.3.2ATM：字符显示351
术语表354

前    言软件开发是一项极其复杂的智力活动，它是一门朝气蓬勃并且仍在迅速发展的学科。软件开发还不够完善，因此迄今人们仍然在试图找出开发软件的好方法。 尽管如此，多年来软件开发方法仍然获得了大幅提升。许多设计方法学不断发展以促进软件设计的各个方面。其中之一是结构化设计方法，该方法提供了一种非常直观的方式，用以很好地匹配图灵和冯·诺依曼的硬件计算模型。 问题尽管结构化设计明显优于它之前的特定方法，但它存在着一个致命的弱点：当用户需求随着时间的推移改变时，软件往往很难随之修改，大型的应用尤其如此。与此同时，应用的规模和复杂性迅速膨胀。另外，新的语言、技术、操作系统、数据存储范式、用户界面范式、硬件等以惊人的速度出现在计算领域中。然而，商业条件一直在要求软件产品更快、成本更低地投入市场。 希望因此，一些新的设计方法出现了，这些方法从实践中吸取了来之不易的经验和教训。同时，计算领域提出了一些革命性的新观点。其中之一就是面向对象的范式，其主要目标为：在软件产品的生命周期中，随着需求出现不可避免的变更，保证大型应用的可维护性。 本书介绍一种特定软件设计方法的实践，该方法称为基于模型的开发方法，其主要基础是Shlaer-Mellor方法。通常情况下应用OO范式，特定情况下应用MBD方法能够使大型应用获得更强的健壮性和可维护性。 本书主要内容尽管本书使用UML（Unified Modeling Language，统一建模语言）作为表示法，但其应用是很浅显的。有很多非常优秀的书籍描述了如何使用UML进行软件设计，因此本书没有过多地描述UML的语法。同样，本书遵循了MBD的设计方法，但是该设计方法主要为下列真正目的提供背景支持： 本书的主要目标在于描述，为什么在一般情况下使用OO方法和在特殊情况下使用MBD方法是在宣传一种做事情的特殊方法。 不存在一种唯一正确的方法可以设计和开发所有软件。设计更多地依赖于特定的开发环境，包括从业务目标到工具再到团队文化等所有内容。最终，企业将决定在它的环境中哪一组工具是最高效的。为了做到这一点，决策者应当了解为什么MBD的方法工具集得以应用在许多常见的环境中。更重要的是，相关人员需要充分理解基本原理，从而能够根据特定的环境加以调整进而应用。 实现面向对象的设计需要一种独特的思维，该思维在硬件计算模型中很不直观。本书真正关心的是设计软件时如何思考，特定的表示法和方法学不是本书的侧重点。因此，本书以大量的篇幅探索好的软件设计的思考过程，甚至故意提供了一些不好的初步设计，用以证明该方法的自我纠正能力。 为了获得这样的理解，有必要描述软件开发的传统方法（面向对象方法之前）在某些方面如何失败，以及面向对象范式如何改正这些缺点。尽管结构化方法为1970年之前软件开发的混乱带来了切实的秩序，但它不是万能的。到20世纪80年代，软件明确显示，严重的可维护性问题仍然存在，这些问题正是面向对象范式要解决的。 同样，如果不讨论一种方法学的某些基础理论，那么就没有办法描述该方法学是否能够很好地工作。然而，这是一本软件开发人员写给软件开发人员的书，因此本书有意识地使用了不具有数学严谨性的实践术语来描述理论问题。 因为本书的主要内容是抽象OOA（Object Oriented Analysis，面向对象分析）模型的建立，因此书中没有很多OOPL（Object Oriented Programming Language，面向对象编程语言）代码。从方法学的名称顾名思义，其重点在于抽象建模而不是编写传统的源语言代码。实际上，当一个具有“转化质量”的OOA模型开发完成后，模型就是代码。换句话说，OOA建模使用的表示法是一种扩展的UML符号，其中增加了符合MDA的抽象动作语言（Abstract Action Language，AAL）的内容。表示法是4GL（Fourth Generation Language，第四代语言）而不是3GL（Third Generation Language，第三代语言），但是模型像任何一个3GL程序一样可执行。模型是独立实现的，它是一个针对功能需求解决方案的完整、准确而清晰的规格说明。 我们需要指出的最后一点是，作者的实践开发经验是以几十年而不是几年来衡量的。尽管本书的重点在于解释为什么这样做事情，但它绝对不是一本理论书。本书的基础是在现实世界中行之有效的方法。 路线图本书的主题限定于OOA层的应用开发，主要分为三部分。第一部分回顾了历史并介绍了基本的面向对象的原则。引言部分包括对结构化开发问题的讨论，这些问题正是OO范式想要解决的。第二部分关乎为问题的解决方案构造一个静态的结构。这一部分描述了OO范式与其他方法的最大不同，主要表现了OO范式在问题域抽象方面的独特视角。第三部分描述了解决方案的动态方面，尤其是积极地使用有限状态机进行行为描述。 读者对象本书的主要受众人群为具有较少OO经验的人。本书假定读者具有一些粗略的UML知识。本书还假定读者具有一些软件开发经验，接触过类似C语言的课程项目等。这里假设的经验层次包括：基本具备有关计算机和编程的一些知识，基本熟悉一些常见的缩略语，例如KISS等。 第二类读者是从传统的程序开发环境向OO范式转变的大量人群。他们中的许多开发者直接跃进到使用面向对象的编程语言写程序，因为他们已经具有了丰富的编程经验（即，相信如果一个人已经了解了一种编程语言，就能了解全部的编程语言）。可悲的是，这样的开发者往往会开发出大量不好的OO代码，因为没有人告诉他们为什么面向对象的分析和设计与结构化的分析和设计之间存在着巨大的差异。如果你是其中之一，那么你需要忘掉之前所学过的所有关于设计软件的内容，从零开始。 转化的作用MBD的一个主要特点是，它是基于转化（translation）的一系列方法之一。也就是说，MBD是一种这样的方法，在该方法中，一个解决方案使用某种表示法（例如UML）抽象为模型，然后使用一个完整的代码发生器将模型自动转化为一种实现。转化具有一些明显的优势，因为它代表了计算领域的一种自动化的逻辑扩展，能够提高生产力、实现规模经济并增加可靠性。缺点在于这并不容易做到。模型编译器面临的优化问题比3GL编译器面临的优化问题更加复杂。无论如何，当前已经存在一些商业代码生成器能够为基于转化的方法提供100％的代码生成。 尽管大部分转化方法出现于对象管理组织（Object Management Group，OMG）成立之前，由OMG所规范的模型驱动架构（Model-Driven Architecture，MDA）还是极大地推动了这些方法。MDA为即插即用工具提供急需的标准，为生成完整的代码提供概念框架。从一个抽象的、独立于实现的模型获得第三代语言代码或者程序集是一项重要的工作，特别是对当前复杂的IDE（Integrated Development Environment，集成开发环境）来说。这项工作大大受益于MDA的概念及其形式化。 然而，MBD并不依赖于转化。MBD中产生的模型与传统开发中OOA产生的模型本质是相同的，可以通过手工的方式生产OOD模型和3GL代码。MBD模型的构建只是比典型的OOA模型更加严格，因为代码生成器是没有想象力的，它们处理命令中的内容，而不是暗示的内容。开发者必须手工实现转化。 致谢非常感谢Steve Mellor和Sally Shlaer的工作，他们的方法是MBD的基础。他们是软件开发转化方法的开创者，并为OOA模型提供了急需的设计严谨性。除此之外，Steve Mellor是我见过的最好的OO建模者，他提供的例子让人受益匪浅。 同样感谢Rebecca Wirfs-Brock对手稿一丝不苟和悉心的审校。 Pathfinder Solutions为本书的方法提供了优秀的试验场，Greg Eakman、Carolyn Duby和Peter Fontana提供了特别的支持。 还要感谢Addison-Wesley出版社的Chris Guzikowski和Raina Chrobak的耐心与信心。谢谢Elizabeth Ryan、Diane Freed和Chris Zahn的编辑工作。 尽管这本书于我退休之后开始撰写，我还是要感谢Teradyne/ATB公司，他们提供了世界一流的软件开发工厂，其中充满了明星开发人员，他们为本书中的许多想法提供了原型。 最后，我要感谢30多年以来因特网上的大量用户为本书中概念的解释提供的共鸣版。读者读到的清晰描述大部分精炼自公共论坛上的描述。 引    言历史是一场噩梦，我试图从中清醒。 ——乔伊斯40年前，百万行的程序被认为是巨型程序，仅供美国国防部（Department of Defense，DoD）内部巨大的主机系统使用。按常规估计，开发这样的程序需要1000名工程师工作10年。今天，大多数PC上的应用都超过百万行，并且有许多在千万行范围之内。而且，人们期望它们能在几年甚至更短的时间之内开发完成。因此，在程序规模不断增长的同时，客户期望开发费用能越来越少。 在高科技日新月异的当今社会，软件快速老化已经成为常态。在公司的经济发展模式中，增长的要求比以往任何时代都更受重视。诸多因素促使公司在短时间内创造出更多、更好、更与众不同的产品。由于这些新产品的研发制造都需要依赖日渐庞大的各式软件，因此软件开发人员完成工作、缩短上市时间的压力不断增大。 软件开发人员同时奋战在软件开发的另外一条战线上。40年以前，对于发布的代码，全美的平均缺陷率为150个/KLOC。但是该数据没有人关注，因为大好形势之时，没有人去研究如何写“好的”软件。GOTO语句和全局数据占主流地位，设计在黑板上或者鸡尾酒餐巾上完成，DEL键永远是程序员们的最爱。软件开发如同一些电气专业一样晦涩难懂，因此，坦率地说，那时没有人在意这些。 但是，这样一个乌托邦式的情况不可能永久持续。在20世纪70、80年代发生了两次变革。第一，一场由日本方面开始的质量革新出现，亚洲其他国家纷纷效仿，随后缓慢波及到西方工业国家。此次变革使得用户进入了一个新时代，他们不用再把每周六分之一的时间花在修理车子或者电视上，这才是用户真正喜欢的。第二，在此次质量革新之后，软件的影响逐渐渗透到生活的方方面面，突然间软件就成为经常出错的典型。现在用户逐渐意识到了还有更好的质量革新方式，于是对于这些经常出错的软件，他们不再喜欢了。 因此，要求软件开发人员在更短的时间之内开发规模更大的程序，同时还要求将缺陷率控制在5西格玛的范围之内。更大的挑战是，20世纪80年代市场流行的口号是“质量是免费的”。虽然每一位软件开发人员都知道这是一派胡言，因为软件质量与开发时间是此消彼长的一种平衡。但是，市场压力的影响远远大于软件开发人员的影响，没有人听到软件开发人员的呐喊。因此20世纪80年代对于“软件危机”一词更新更深层的含义是以软件开发人员的健康为代价的。 第二个重大事件是关于计算的技术大爆炸。以前技术进步的主要特征是新的语言或者操作系统的出现。但是PC软件数量的不断增长，程序互操作性的需求和万维网的出现，促使计算技术创新不断。从以架构策略为基础的计划工作到测试过程，现在的软件开发人员在方方面面都有多种选择。更夸张的是，当开发人员还在熟悉旧技术的时候，新的技术已经出现了，速度之快令人咂舌。 最终，软件开发人员面临着不断产生的需求变更。计算域不是唯一面对创新和变革的领域。美国联邦会计标准局（Federal Accounting Standards Bureau，FASB）的核心管理信息系统IRS以及各式各样的其他美国政府机关不定期在颁布变更指令。产品的激烈竞争迫使市场支持者不断推陈出新，以保持与竞争对手步伐一致。同样，在学术界，标准、技能和工程学科的技术方面也日新月异，逐渐摆脱混乱形成统一。“需求万年不变”和项目瀑布模型的日子一去不复返了。 总之，现代的软件开发人员都面临着一个古老的问题，即：如何把5磅的东西尽快放到一个容量仅3磅的袋子里，并保证没有任何遗漏。今天，和半个世纪前相比，我们有着更好的工具、方法、过程和技术，但问题也是成比例增长的。基本汇编语言（Basic Assembly Language，BAL）要解决的软件危机问题仍然如影随形，这也是本书的第一条忠告。 软件开发是一个不可能完成的任务，开发人员唯一要做的就是不断应对并保持微笑。 1.?研究现状1995年的某次会议上，主讲人要求当时的与会人员中使用微软Windows操作系统的人员举手示意，数百人举起了手。然后，他要求过去一周内系统崩溃过的人再次举手，大半以上的人仍然举手。接下来，他让那些认为微软在将来会被市场淘汰的人继续举手，结果所剩寥寥无几。该主讲人用此次实例来说明和验证自己的说法，那就是，软件质量不是一个事关公司生存的必要条件。 这一结论在今天很难保证是对的，尤其是在微软与Linux的市场大战中可见一斑。决定一个软件公司在市场中生存的关键因素，其实是他们是否能够提供用户想要的东西。从广义上讲，这一点可大致从产品的可靠性、功能性、易用性和可用性（即市场时效性）四个方面评估，当然开发人员花费在这四个方面的成本是不同的，如图I-1所示。用户总是希望各方面都得到满足，但是毕竟预算有限，因此供应商决定综合的总成本，然后由市场来检验用户的满意度。 图I-1  权衡冲突的开发优先级如何满足这四个方面基本上是一项市场决策。在一个既定市场给定价格下，市场支持者总是期望通过一个最佳营销战略来赚取他们的第一桶金。而成本最小化的关键在于软件开发人员。这种开发成本的降低会直接影响产品市场竞争优势的确立。这种优势的价值将取决于特定的市场地位。因此，衡量软件开发现状的问题是：运用什么样的工具才能有效降低成本且满足这四个方面的要求。 我们有各种各样的软件工具来帮助我们，如版本控制系统。我们也有大量的过程，从XP到正式方法。我们还有很多种软件设计方式方法。我们有像RUP和CMM这样的过程框架，还有汇编语言、集成开发环境（IDE）、度量系统、估计模型和其他各种各样的工具。 我们有各种珍贵的数据，可以整理出可用的方法、技术和实践经验，形成最佳的组合。 一帮黑客宅在他们的卧室里，经过数月消耗掉无数可乐和披萨后黑掉某一应用的日子一去不复返了。如果工作面试时，你告诉招聘经理去年你总共写了100KLOC，那你可以跟这份工作“拜拜”了。因为招聘经理都明白效率如此低下的原因是编写的代码最后都不可靠，并且是一堆无法维护的烂摊子。有效降低满足这四个方面的成本，需要的是有组织、有系统地进行软件开发。 目前业界有太多口惠而不实的软件工程。作为一门工程学科我们可能还需要走很长的路。软件开发是一门艺术，尽管非常晦涩难懂。其精髓在于这是一个在给定环境下运用各种不同方法和工具的大杂烩，即一个协调统一的开发系统。除了提供这种集成系统的规则外，我们的“软件工程”只不过是“这里有一个框架和一些可选择的组合。寻找正确的候选者并在特定开发环境中把它们恰当地组合在一起，则是留给学生的练习。” 2.?什么在起作用然而现实情况是，软件开发的艺术在过去的半个世纪里有了长足的发展。同样数目的开发人员能够在更短的时间内更高质量地完成更大规模的项目，因此我们更应该去做一些更有帮助的事情。其中棘手的问题是，如何弄清哪些事情是正确的。 早在1970年之前，人们就有基于几十年实践经验总结的宝贵教训。例如，曾几何时FORTRAN的GOTO语句和COBOL的ALTER语句被视为处理复杂编程问题的强大工具，然而10年后，编程经理不再使用这些语句，因为使用这些功能的程序在需求变更时很难维护。 所有这些来之不易的教训形成了开发者经验的概念。当一个程序员犯过足够多的错误并在错误中吸取了各种教训后，他就会逐渐成长为软件开发的行家。遗憾的是，软件开发人员总是会重新经历这些错误，因为没有一个关于这些软件开发经验教训的系统总结或者统一标准。 20世纪60年代末，第三代编程语言中出现了各种各样的编程方法，软件设计方法开始兴起。早期，大家只是把一些经常犯的错误和实践经验公布于众。不过，很快软件专家们开始将这些实践经验总结成系统的设计方法学。这些方法学在细节上各有不同但是很多特征是有共同点的，所以它们都属于结构化开发（Structured Development，SD）。因为它们是相当抽象的视图——有关软件设计的一张大图，而且读者会发现它能够很方便地使用专门的表示法。很多倡导者也很学术化，表示法往往倾向于图形化，这使集合论和图论中的理论约束也得以应用。 结构化开发是20世纪中期最简单也是最重要的软件开发成果。毫不夸张地说，它让软件开发摆脱了杂乱无章的状态。除此之外，它是数据处理的增长动力，数据处理在20世纪80年代演变为重要的信息技术。在企业界，很多入门级的COBOL程序员艰难地做出了大量的报表，从而为日常的企业运行提供了前所未有的可视性。更好的是，这些报告通常相当准确。 当然，结构化开发在软件开发的漫漫长路上仅是第一步。正如所预期的，它是新的，但不是万能的，从20世纪70年代起它的一些缺陷就开始显现了。只有理解这些缺陷是什么，才能理解20世纪80年代面向对象开发的发展原因和发展方式。