毕业设计文献翻译：无缝的面向对象软件架构

文献翻译二级学院计算机科学与工程学院班级学生姓名学号译文要求1、译文内容必须与课题（或专业）内容相关，并需注明详细出处。2、外文翻译译文不少于2000字；外文参考资料阅读量至少3篇（相当于10万外文字符以上）。3、译文原文（或复印件）应附在译文后备查。译文评阅导师评语（应根据学校“译文要求”，对学生外文翻译的准确性、翻译数量以及译文的文字表述情况等作具体的评价）指导教师：年月日无缝的面向对象软件架构摘要：在这篇论文中主要分析无缝的面向对象软件架构。阐述软件在分析、设计以及开发过程中面向对象设计思想如何使概念到实现的平稳过渡，避免软件系统与需求目标的偏离。关键词：面向对象可重用性无缝性1面向对象软件发展1.1介绍什么是面向对象范例的潜能？我们通过合理地使用这种在发明25年后终于征服软件产业的技术能够多大限度的改进软件开发过程？弗雷德·布鲁克斯，在他的著名文章“没有银弹：软件工程的本质性与附属性工作”[布鲁克斯1987]中，把创造软件的困难划分为本质性与附属性。一款软件的本质是一系列互相关联的概念的构件：数据集合，数据项之间的关系，算法和函数调用。软件的的总体结构——其逻辑结构的一部分独立于任何特别的机器表征，但是还不足够详细的足以明确转换为可执行代码。它的附属性则相反，所有复杂的细节需要用于表示在给定的计算环境的附属性。布鲁克斯认为，相对于表示软件和测试它的保真度的模型（附属部分），创造软件的最重要的部分是说明书，设计和本质概念构想的测试。如果这是真的，他推断，构造软件将会一直困难。不管语言和工具如何的给力，都会使我们远离我们想要表达的真正的问题。乍一看，布鲁克斯的结论似乎认为面向对象的抽象具有提高软件生产效率的潜力这一显著因素是无效的。而事实上，如果面向对象技术主要讲授和用于从头开始构建新的系统，像那些现代工业常见的案例一样，也许只有边际生产率的提高可以期待。但是，在另一方面，它强调的是从单个系统转移到可分割的软件组件的生产和使用，使深刻的变化成为可能。可重用方法的好处两个值得乐观的理由。首先，通过排除工业软件工程大多数意外的困难可以使软件费用降低一个数量级——或许不是一个单独的系统版本，但肯定覆盖整个产品生命周期。方法和实现语言是不够的，但是，要达到降低费用的目标，无论多么强大的概念和高度自动化。我们还需要访问那些在现代工业软件项目中被一遍又一遍改造的底层封装基础概念的大量可重用构件基础。其次，可重用抽象并不仅限于隐藏意外的困难，也可以用来攻击软件设计的本质。涉及解决问题的复杂性不仅取决于问题本身，同样受到推理问题的原始有效观念影响。所以如果我们能够提高表达能力和原始事物的可理解性在不同的问题领域，那么类似抽象设计的复杂性就可以减小。作为附带影响，投资于重用还可以带来另外一个重要的好处。软件构件在多重环境下被用到或重用多次意味着软件质量有连续提高的机会，这在经济上比只在一个项目中使用可行性更高。这可以使新的抽象逐步发展直到它们成为概念上强大到足以使它们成为系统的一部分开发人员的标准词汇。这也许，反过来促进新的有用的，但是由于初步努力尚未达到要求的更高水平的抽象被发现。起初的困难目前已投资超过过去二十年来的显著努力用于建立和使用工业系统开发的软件组件库。尽管某些应用领域已经看到了一些成功，在一般案例中实现高度重用程度被在练习中被证明困难比预期中的更难。大多数的失败被归咎于组织的缺点，例如缺少明确责任的角色（重用管理者），没有一致的管理策略，缺少自动化工具的支持，以及与短期项目预算冲突等。其它的问题是自然的商业，例如如何保护可重用设计足以使与投资人的投资是匹配的。这些问题之所以存在，是因为我没转换技术，必须要先解决问题。但这一切的关键是面向对象的抽象——唯一的足以够用于构建所需的通用组件的技术。由于重用主要依赖于传统的技术，也就不必为它的失败而感到奇怪了。就像我们缺少基本的方法生产正确的部件，正式组织和自动浏览工具难以提供帮助。另一方面，面向对象并没有自动解决所有问题，许多面向对象的项目同样报告难以实现重用目标的困难。然而，这并不能作为大规模重用在实践中无法实现的迹象，或者说面向对象无效。相反，有很多原因可以解释这些初步的困难只是没有预料到而已。首先，大多数或者说全部的工业化的面向对象的项目仍然在使用混合的语言或者混合的方法。致使部分自相矛盾的概念产生混乱并延迟充分利用新方法必需的心理转变。混合语言落后的兼容性需求同样使完全支持面向对象的核心概念变得不可能，进而使建设高质量的组件库变得困难。其次，即使技术手段是一个先决条件且必须是第一位的，组织方面也同样重要。许多项目失败是因为准备不充分的培训，缺少管理支撑或者重用协调。这些同样是必须解决的问题，尤其是对于大型机构。最后，商用类库的大小和质量是一个重要变量，甚至最好的面向对象的环境也只是一个目标的一小部分影响因素。因为良好的抽象需要依赖多种已经被尝试过的方法逐步开发，在我们可以期待一些东西可以接近最常见的改造软件组件的完整封装之前，它自然会耗费一些时间。 知识的重用之路如果我们把当前的面向对象语言趋势与1970年代到1980年代初向高级语言过渡比较，这种情形尽管有很多相似之处，也是相当不同的。像Pascal和C这类控制结构体现抽象的组装的语言，程序员总是通过智力解决（经常发生在一些伪陵符号注释），因此,大回报是立竿见影。当由构造序列组成的机器指令的冗长的且易出错的翻译不再需要时，工作可以继续像以前一样，只是更快。在一些重要的领域，当从今天被认为是传统语言的（如Pascal或C）转向一个更好的面向对象环境同样如此。使用现成的组件的能力代表了几乎所有的基本数据结构和基本算法（列表，哈希表，队列，栈），而不需要知道任何关于它们的实现，是一个直接并联。另一个领域是图形接口。但是面向对象的抽象以为着更多，因为它几乎可以在任何一个领域被用来创建新概念。这意味着它最大的潜能（从长远来看）不在于代表我们已经熟悉的概念，而是作为发明新的概念的媒介。这是面向对象作为一个技术投资而非短期收益的一个主要原因（尽管并不排除后者）。真正的大回报将取决于重用在特定领域的水平。它有可能捕获在整个应用程序类型即所谓的框架,而且从一个环境到另一个环境只需修改小部分即可。成功的框架在开始的时候很难构思。相当于它们逐渐适应进化的一群解决一个特定问题也能解决其它问题的组件，类似的在实践中出现的问题。因此产生的结构的有效性证明被经验证明，保证低成本/收益比率。所以如果事情进展缓慢我们不能绝望——毕竟，我们是伸手摘星。未来的潜力是巨大的，尽管广泛的培训和组织支持是必要的且不是免费的，在我们的投资开始获得汇报之前我们不需要走很远的重用之路。在本书中，我们将介绍来自确实至关重要的广泛的软件重用为基础的面向对象的分析和设计，而且只要我们利用面向对象概念的方式在实践中实现是符合这以目标的。这一观点强调我们认为没有充分解决的面向对象技术的某些方面。那么，什么是有能力使软件重用变成标准的做法并且最终给出软件工程面向对象术语的面向对象本质的意义？除了类的概念提供的极致的灵活性——让我们可以通过继承建立可组合且可量身定做的开放组件——已经在序言中提到的面向对象的三个重要方面，无缝性、可逆性和和软件外包，比迄今为止已有的关于分析和设计文献更值得关注。我们来依次看一下。 1.2无缝性面向对象方法是迄今为止已知的唯一具有潜力的方法，可以使分析、设计，以及通用的软件系统的设计和实现转变为真正的无缝过程。从用户需求到分析与设计，到运行系统平稳过渡，软件工程的目标需要20多年，但是传统的方法在实践中已经失败（虽然经常声称已经解决）。这不是令人惊讶的，因为概念和符号设计师的方法被迫从Scylla和Charybdis选择。要么你提供一个传统编程语言的翻译，那些改变符号就能成为另外一种的语言（通常引起的复杂性比它解决的问题更多），或者你发明一个完全不同的高级符号并保持规范和代码之间的差异。同样的抽象机制（类）可以用于所有的发展阶段使面向对象如此的吸引人。基本概念需要等外部概念模型对象代表医院,飞机,和广泛的区域网络并不是本质上有什么不同，所需对象代表四精度浮点数,街道地址或进程调度程序。抽象封装的类的语义解释会有所不同，但是一般的问题仍然是相同的：指定类的一致性，与其他类的关系，通过适用操作的行为。通过生产、维修工作系统嫩巩固保持相同的模式从最初的可行性研究带来巨大的优势。当基本概念对于每个人都相同时，与每一个不同角色的项目成员沟通是一个很大的提高。教育促进人造说明符与实现者之间的障碍消失，为系统生命周期的整体视图创造空间。无缝性也促进了需求跟踪。由于类从分析阶段被引入直到最终的系统还会呈现，通过设计和实现跟踪需求扩展变得很容易。 1.3可逆性真正的无缝性不仅仅意味着容易从规范的转变实现。太多的面向对象方法依赖于不言而喻的只用于早期开发阶段分析和设计符号的设想，然后翻译成面向对象编程的程序或不。但在某些时候（其实很快）初始系统将被修改以满足新的要求。理想地，这意味着首先改变最高的描述，然后向下相继地传递变化直到代码实现。然而，这不是在实践中大多数系统的工作方式。因为高级规范只能代表系统的一个粗略的草图,在规格可以执行之前必须忽略很多细节和问题在这一点上。这意味着一个全新的根据实现语言概念的抽象世界将被创造，主要的兴趣和创造性工作将逐步转移到现在的环境。连续的改进和修正将会被直接应用与程序代码，因为只有我们有足够的表达能力能够解决不可能解决的隐晦的、详细的决定性规范。而且有些细节总是被证明对系统结构具有重大影响。（如果程序代码可以从规范代码自动生成，后者将简单的成为我们新的编程语言而且我们一点也不需要讨论的低水平。）然而，如果抽象系统描述是为了在第一次翻译成程序代码时的价值，修改代码则必须定期的反射回给规格。在这里，所有的传统方法被摧毁。如果概念原语被规格和实现语言所分别使用，不能被直接映射到彼此（总是用非面向对象处理的情况），这将导致规范和实现之间的分歧。随着系统的发展保持两个世界始终一致将会变得非常昂贵，因为这意味着或多或少的在不兼容的概念结构之间重复简单的翻译。事实上，即使你努力使所有的规范保持最新，也没有办法知道它们真的是最新的（由于概念上的不匹配），所以通常人们不会信任它们。毕竟，只有可执行的规范，即程序代码，通过实行系统操作与硬件交流。它是决定飞机是否安全起飞或降落的完整程序代码，而不是吸引分析师或设计师的蓝图。一个正确的系统可以没有故障的运行，即使它的规范是错的，而不是相反。因此，当我们在实践中要选择支持的描述，选择很简单。规范的价值直接关系到它们可以直接通过规范翻译成程序代码或被程序代码直接翻译为规范。那些声称只有非常高层次的需求和分析模型要紧，没有给出任何如何映射到可执行代码或从可执行代码反射的做法的提示，看起来似乎并不了解现在的软件意味着管理数十亿美元的投资。面向对象概念的高级建模技术被奋力征服程序设计的复杂性的人们发现似乎并不是一个巧合。不像其他的方法，面向对象本质上是可你的。由于分析和设计类可以作为最终系统的一部分，任何影响这些类的结构和接口的实现更改变得立即可见，但是前提是我们避免包括其他领域的元素，如我们的方法的标准部分：如实体关系图、状态转换图、或者数据流程图。混合范式打破了可逆性，并且引入了新的复杂性，这在大多数情况下将大于预期效益。这并不意味着这些技术能用于面向对象系统。一些应用程序可能会受益于特殊场合的实体-关系图，并且通过状态转换图建造某些抽象将会极其的强大，但是它们基于一般方法则会丢失重点。相反，我们应该利用面向对象的特殊品质：它的简单易行，连贯性，以及极其普遍性。它在没有强制改变任何特殊的查看方式的情况下提供了对各级抽象的支持。这使这种途径在开发方法中变得独特，且它的基本概念被证明足够的支持我们需要的大多数软件的规范和实现，几乎可以忽略软件的应用领域。 1.4软件外包软件重用需要额外的高质量，因为其潜能提高生产效率也比以前造成伤害的风险更大。从头编写大多数用传统风格编写的软件至少在限制错误在特定系统发展的影响的具有优势。然而，如果一个不适当的软件构件应用于成千上万的应用程序，积累损伤实际上是非常高的。在一定程度上这会让重用软件片段受到广泛测试沉重反击，但是测试只能揭示一小部分潜在的错误，只要使用模式在变化，以前隐藏的问题可能会被发现。面向对象方法的整个想法是通过在抽象层不断地建立更强大的组件设计软件从而反映出在各种应用领域的高级概念，每个都建立在之前的基础上。我们知道没有更好的方式来掌握错综复杂的事物，但这同样意味着产生的结构变得完全依赖于组成部分的正确机能。如果一些核心抽象失败了，整个建筑就有可能分崩离析。因此想办法保证软件的正确性也更加重要。幸运地，近年来提出来了一个非常有前途的方法，将元素从抽象数据类型和正式规范的研究领引入到软件工程的标准用法。这是软件外包的理论【Meyer1992c】。这个想法是用声明定义每个类的语义。先决条件和每个操作的结果行为是通过预处理和后置条件规定，且全部类一致通过类的不变式。然后，这些语义规范在没个类之间形成一个合约基础，供给方和所有的类使用它的业务操作和客户端。一个软件被视为一个客户和供应商合作的网络，而软件的请求和服务通过分散的合同精确定义。根据合同，一致的错误处理机制是可能的。如果声明在运行时被监控，违反合同则会导致异常。分散的处理程序可以被定义和实现为一般的异常管理工具处理错误恢复。软件外包代表程序生产中具有重大意义的一步，应该被包括在任何面向对象的分析和设计方法中，旨在建立可靠的、高质量的专业化产品。2BON方法2.1介绍本书描述的方法叫做BON，代表“业务对象表示法（BusinessObjectNotation”。它提供了一组面向对象软件建模的概念，两个版本的支持表示法——一个图形一个文本——一套可以用于生产模型的规则和指引。BON专注于分析和设计的基本要素，该方法是集成和适应可以应用与不同的组织的各种开发框架和标准。BON支持核心没有特殊应用程序类型的整体软件开发，特别是对质量和可靠性要求很高的产品。概念和符号的设计提倡在前一章中提出的可重用性方法：无缝性，可逆性，软件外包。与发现在许多面向对象的阵营中大规模重用的可达性有些消极态度相反，我们认为这确实是该技术的首要目标。BON不引入任何根本性的新概念；面向对象的基本思想结合软件规范元素作为原语是足够的。它是一个可以造成质的区别的通过一个扩展标记的详细定义和概念表达排列。（到一定程度时，BON由被不包含它的表示方法定义，因为无缝和简单是指导明星。）读者当然会怀疑在很多表示法已经出版的情况下而不引入新的表示法是否会导致目标不能实现。我们不能只是适应一个更广泛使用的现有的表示法来实现我们的目标吗？遗憾的是不能。尽管在许多已经被提出的方法中使用的概念似乎是或多或少相同（类，操作，关系），依然有表面下的细微差异以防它们一对一映射。由于表示法只是一种用综合的可读的形式表达基本概念的方式，重用在这种情形下不能工作。面向对象的分析和设计领域还很年轻、不成熟，许多竞争的方法和相应的表示法自然地会在它该出现的时间不断涌现。也许这会对一些潜在的用户制造混乱，但这真的是他们的最佳收益。规范化太早是极其有害的，因为它缩小了建模的角度，挡住了真正理解的方式。（我们很高兴地看到，这一观点被众多在该领域知名的专家共享，通过最近的一封公开信“过早的标准化方法是有害的”[Mellor1993]） 2.2什么是BON没有的许多现有的分析和设计的方法，也许大多数，不是使用一些实体-关系方法(实体关系建模[Chen1976])或有限状态机（FSM建模）的变种的数据建模，就是全部，作为高级系统描述的一个重要部分。我们的想法是把这些技术的优点与面向对象概念结合起来，从而从连个方面受益。然而，这种方法严重阻碍了在前面章节提到的无缝和可逆性主张。我们认为，这个缺点远远超过因此带来的好处。使用FSM建模，由于在状态转换图和最终实现之间没有简单的映射，阻抗不匹配是显而易见的。（除非我们把没个对象都建模为一个状态机，从而放弃所有类概念的抽象力量）。使用ER建模，情况则比较复杂一点。 为什么不用ER建模？分析ER建模的支持者声称二元关系比类的相互引用更加通用，因为在前面提到的后一种明确的设计选择仍然保持开放。这当然是真实的，因为可以通过多种方式表示两个类之间的特定关系。然而，通过限制所有的类依赖于二元关系使选择保持开放通常并不是最好的一种方案。事实上，为了得到一个好的系统模型我们反而不能保持一切开放，因为这将严重地影响我们理解问题。所以问题不是是否应该做出设计决策，而是选择哪一个。ER建模当然也不例外。相反，就像许多武断的或有疑问的决定必须被做出以达成ER建模，正如一个纯粹的面向对象模型。在后一种情况下，我们必须选择概念模型作为类和哪些应该成为这些类的操作。用ER建模，我们必须选择描绘实体的概念，以及哪些会成为实体的属性，哪些会成为它们之间的关系。这对改变来说并不意味着比选择更容易或者影响更小。例如，一个ER模型中的属性被视为实体中的“性质”，并由一个值表示。但一个属性是什么？考虑实体员工和一个服务部门最受欢迎的人的概念。显然，最受欢迎的是一种人的性质，但是从系统的观点来看把这当做一个员工的属性建模可能是相当错误的。员工抽象可能不知道它的条件，知识表示自身的唯一方式可能相反是其它实体属性的组合，也许是统计数字和客户投票。所以我们在这里有一个问题：任何一个属性都被认为是和储存在实体中的数值是直接对应的，在这种情况下太低级，或者这只是一个不明确的“性质”，这又太高级，因为它没有告诉我们关于系统足够多的信息。面向对象的中间道路是一个类操作返回一个值，而值可能是任何类型的。这避免了过早的确定不同的值的存储方式，并且告知了足够多的系统行为允许无缝过渡到实现。另外一个麻烦的地方是为实体的属性和关系选择什么级别的“标准化”。实体A与B之间的二元关系通常不会对A与B之间的联系作任何说明（除了通过语义标签，例如“适用于”和它的相对角色“使用”）。按此推理，传递规律也必须适用：如果B通过关系“有下级单位”反过来与C关联，那么A也能通过“适用于上级单位”与C关联，C通过“是上级单位的下级单位”与A关联（图2.1）。由于ER模型通常是连接图，可以查找每一个实体与其它实体之间的二元关系递归地调用规律产生图。因此，只有被认为是最重要的关系被包含在图中，其余的则被隐藏。有些作者建议分离独立的属性和关系的正交基，并且标记所有其它显示的正交基。然而，哪些作为正交基被选择远不够明显，也不清楚“衍生”意味着什么。例如，考虑图2.2所示的实体，我们可以选择母亲-儿子和母亲-女儿两个关系作为正交基。儿子-女儿之间的关系兄弟-姐妹就变成了衍生，因为对于任何一对儿子和女儿我们可以推断出他们是否是兄弟姐妹。但是我们可以选择其他两个作为正交基（假设兄弟-姐妹意味着所有的兄弟姐妹，共有双方的父母）。此外，可导出的属性通常是全局的。从儿子的视角，母亲和姐姐的角色可能同样重要，且事实上一个属性从另一个属性中导出并不应该总是被强调。相反，可能晚些时候一个系统中母亲的角色也能被继母实体所实现，那么，可导出性将不再持有。出于同样的原因，衍生属性和基础属性的区别并不总是明显。确定可导出性必须经常做出关于底层信息内容的比预期要早的假设。这些问题会在纯粹的面向对象方法前消失，因为我们专注于系统行为而不是什么信息需要被存储。因为这种行为是实现系统功能的需要，更多的重在应对未来变化的结果。底线是如果我们在分析和设计级别加入ER建模我们将放弃面向对象方法固有的无缝性，但是我们却得不到多少回报。在实践中，真正的系统通常有几百个潜在的实体和它们之间的关系。因此产生的完整的ER图变得巨大，其本质上是一个平面结构。为实现一些目的，大型图通常被分解较小的重叠的部分，其中每个部分包含一些实体集与一个相互关系的子集。这可能使任意的关联遗漏。这种技术类似于过去的分割项目流程图，只是留下很多引用其他图的箭头，边界关系只是简单的限制。然而，这并不改变固有的平面结构，也不是对理解大型系统如此重要的“缩放”功能，我们坚持“平移”的形式。强调作为一个建模概念的关联与对象行为分离有利于整体系统观察。它打破封装和集中在短期细节上比局部概念更多，这可能有潜力时之存活更长时间。ER建模作为分析和设计方法的部分不会帮助我们找到可能在其它情况下使用的代表有趣概念的类，除了解决当前的一部分问题。面向对象开发的无缝性和可逆性因此不能完全利用，因而不利用重用。而且，我们不需要这种类型的独立的联合，因为面向对象原语可以直接用来建模任何我们想要的概念。由于这些原因，BON被设计为遵循不同的轨道。与其试图包含传统数据建模概念或或所谓的结构化技术带着所有附带的缺点，更富有成果的是寻求：面向对象的灵活性和透明度、强类型的表现能力，以及类之间的正式契约的结合。1Object-orientedsoftwaredevelopment1.1INTRODUCTIONWhatisthepotentialoftheobject-orientedparadigm?Howmuchimprovementofthesoftwaredevelopmentprocesscanwereasonablyexpectfromusingthistechnology,which25yearsafteritsinitialinventionfinallyseemstobeconqueringthesoftwareindustry?FredBrooks,inhiswell-knownarticle“NoSilverBullet:EssenceandAccidentsinSoftwareEngineering”[Brooks1987],dividesthedifficultiesofbuildingsoftwareintoessenceandaccidents.Theessenceofapieceofsoftwareisaconstructofinterlockingconcepts:datasets,relationshipsamongdataitems,algorithms,andfunctioninvocations.Thisconstructisthegeneralarchitectureofthesoftware—thatpartofitslogicalstructurewhichisindependentofanyparticularmachinerepresentation,butstilldetailedenoughtoallowunambiguoustranslationtoexecutablecode.Theaccidents,bycontrast,areeverythingelse—allthegorydetailsandcontortionsnecessaryforrepresentingtheessenceinagivencomputingenvironment.Brooksbelievesthehardpartofbuildingsoftwareisthespecification,design,andtestingoftheessentialconceptualconstructs,asopposedtorepresentingthemandtestingthefidelityoftherepresentations(theaccidentalpart).Ifthisistrue,heconcludes,buildingsoftwarewillalwaysbehard.Languagesandtoolsnomatterhowpowerful,canonlytakeusthatfarwhentherealproblemistodecidewhatexactlywewanttoexpress.Atfirstsight,Brook’sconclusionmayseemtoinvalidateallclaimsthatobject-orientedabstractionhasthepotentialtoincreasesoftwareproductivitybyasignificantfactor.Infact,ifobject-orientedtechniquesaremainlytaughtandusedtobuildnewsystemsfromscratch,asoftenseemstobethecaseinindustrytoday,onlymarginalproductivityimprovementscanprobablybeexpected.Ifontheotherhand,theemphasisisshiftedfromindividualsystemstotheproductionanduseoftailorablesoftwarecomponents,aprofoundchangebecomespossible.BenefitsofareusabilityapproachTherearetworeasonsforoptimism.First,thecostofsoftwarecanstillbereducedbyanorderofmagnitudebyremovingmostoftheaccidentaldifficultiesfromindustrialsoftwareengineering—maybenotforasinglesystemversion,butsurelyoveraproduct’slifecycle.Methodsandimplementationlanguagesarenotenough,however,toachievethiscostreduction,nomatterhowconceptuallypowerfulandhighlyautomated.Wealsoneedaccesstoalargebaseofreusablecomponentswhichencapsulatethebasicconceptsthatarebeingreinventedoverandoverintoday’sindustrialsoftwareprojects.Second,reusableabstractionsarenotlimitedtohidingaccidentaldifficulties,butcanalsobeusedtoattacktheessenceofsoftwaredesign.Thecomplexityinvolvedinsolvingaproblemdependsnotonlyontheproblem,butjustasmuchontheprimitiveconceptsavailableforreasoningabouttheproblem.Soifwecanincreasetheexpressivepowerandunderstandabilityoftheseprimitivesinvariousproblemareas,thecomplexityofcorrespondingabstractdesignscanalsobereduced.Asasideeffect,investinginreusebringsanothercrucialadvantage.Softwarecomponentsthatareusedandreusedmanytimesinmanydifferentcontextsstandthechanceofacquiringmuchhigherqualitythroughsuccessiveimprovementthanisevereconomicallyfeasibleforcomponentsthatarejustusedwithinasingleproject.Thisenablesnewabstractionstograduallyevolveuntiltheybecomeconceptuallystrongenoughtobecomepartofthesystemdeveloper’sstandardvocabulary.Thismay,inturn,leadtothediscoveryofnewusefulabstractionsatyethigherlevelsthatwouldotherwisenothavebeenfoundowingtotheinitialeffortrequired.InitialdifficultiesTherehasbeensignificanteffortinvestedoverthepasttwodecadestobuildanduserepositoriesofsoftwarecomponentsforindustrialsystemsdevelopment.Althoughcertainapplicationareashaveseensomesuccesses,achievingahighdegreeofreuseinthegeneralcasehasturnedouttobemuchmoredifficultinpracticethanfirstexpected.Muchofthefailurehasbeenattributedtoorganizationalshortcomings,suchaslackofclearresponsibilityroles(reusemanagers),noconsistentmanagementpolicy,lackofautomatedtoolssupport,andconflictswithshort-termprojectbudgets.Otherproblemsarecommercialinnature,suchashowtoprotectreusabledesignsenoughtomaketheeffortinvestedworthwhilefortheoriginators.Theseproblemsdonotgoawayjustbecauseweswitchtechnology,andmuststillbesolved.Butthekeytoitallisobject-orientedabstraction—theonlytechniqueflexibleenoughforbuildingthegeneralcomponentsneeded.Sincereuseeffortshavemainlyreliedontraditionaltechniques,itisnosurprisethattheyhavelargelyfailed.Aslongaswelackthebasicmeanstoproducetherightcomponents,formalorganizationandautomatedbrowsingtoolscandolittletohelp.Ontheotherhand,object-orientationdoesnotautomaticallysolveallproblems,andmanyobject-orientedprojectshavealsoreporteddifficultiesattainingtheirreusegoals.This,however,mustnotbetakenasasignthatlarge-scalereuseisunattainableinpractice,orthattheobject-orientedapproachdoesnotwork.Onthecontrary,thereareanumberofreasonswhytheseinitialdifficultiesareonlytobeexpected.First,mostindustrialobject-orientedprojectsarestillusinghybridlanguagesorhybridmethods,orboth.Theresultingmixofpartlycontradictoryconceptscreatesconfusionanddelaysthementalshiftnecessarytotakefulladvantageofthenewapproach.Therequirementofbackwardcompatibilityforhybridlanguagesalsomakesitimpossibletosupportcleanlyallofthecentralobject-orientedconcepts,whichinturnmakestheconstructionofhigh-qualitycomponentlibrariesdifficult.Second,evenifthetechnicalmeansareaprerequisiteandmustcomefirst,theorganizationalaspectsarealsocrucial.Manyprojectshavefailedbecauseofinadequatetraining,lackofmanagementsupportorreusecoordination.Theseareproblemsthatmustbeaddressedinparallel,particularlyforlargeorganizations.Third,thesizeandqualityofcommerciallyavailableclasslibrariesishighlyvariable,andeventhebestobject-orientedenvironmentsonlycoverasmallpartofwhatonewouldwishfor.Sincegoodabstractionsneedtobedevelopedincrementallywithmanyalternativeapproachestried,itwillnaturallytakesometimebeforewecanexpectanythingclosetoacompleteencapsulationofthemostcommonlyreinventedsoftwarecomponents.TheroadtoreuseofknowledgeIfwecomparethecurrenttrendtowardsobject-orientedlanguageswiththetransitiontohigh-levellanguagesinthe1970sandearly1980s,thesituation,althoughithasmanysimilarities,isalsoquitedifferent.ThecontrolstructuresoflanguageslikePascalandCembodyabstractionsthattheassemblyprogrammerswerealreadyusingmentally(oftenoccurringascommentsinsomepseudo-Algolnotation),sothebigpayoffswereimmediate.Whenthetediousanderror-pronetranslationsoftheseconstructsintosequencesofmachineinstructionswerenolongerneeded,workcouldproceedasbefore,onlymuchfaster.Insomeimportantareas,thesameistruewhenmovingfromwhatcanbeconsideredatraditionallanguagetoday(suchasPascalorCabove)toagoodobject-orientedenvironment.Theabilitytouseoff-the-shelfcomponentsrepresentingthebasicdatastructuressofundamentalforalmostanycomputingalgorithm(lists,hashtables,queues,stacks),withouttheneedtoknowanythingabouttheirimplementation,isadirectparallel.Anothersuchareaisgraphicalinterfaces.Butobject-orientedabstractionmeansmuchmore,sinceitcanalsobeusedtocreatenewconceptsinalmosteveryconceivablearea.Thismeansitsgreatestpotential(inthelongrun)liesnotinrepresentingtheconceptswithwhichwearealreadyfamiliar,butratherinservingasavehicleforinventingnewones.Thisisthemainreasonwhyobject-orientedtechnologyisatechnologyofinvestmentmorethanofshort-termprofit(evenifthelatterisbynomeansprecluded).Thereallybigpayoffswillcomefromreuseatmoredomain-specificlevels.Itispossibletocapturewholeapplicationtypesinso-calledframeworks,andonlytailorthesmallportionsthatneedtobedifferentfromonesituationtoanother.Successfulframeworksarehardlyeverconceivedassuchfromthebeginning.Rathertheyevolvebygradualadaptationofagroupofcomponentssolvingaparticularproblemintoalsosolvingother,similarproblemsthatoccurinpractice.Theusefulnessoftheresultingstructuresisthusempiricallyproven,whichguaranteeslowcost/benefitratios.Sowemustnotdespairifthingsappeartogoslowly—afterall,wearereachingforthestars.Thefuturepotentialisenormous,andeventhoughextensivetrainingandorganizationalsupportisnecessaryandnotfree,weneednotgoveryfardowntheroadtoreusebeforeourinvestmentstartstoshowreturns.Andfromthere,thingswillonlygetbetter.Inthisbook,wewillpresentaviewofobject-orientedanalysisanddesignderivedfromthebasicpremisethatextensivesoftwarereuseisindeedessential,andthatitcanbeattainedinpracticeprovidedwetakeadvantageoftheobject-orientedconceptsinawaythatiscompatiblewiththisgoal.Thisviewemphasizescertainaspectsofobject-orientedtechnologywhichwethinkhavenotbeensufficientlyaddressed.Whatexactly,then,aretheobject-orientedqualitiesthathavethecapacitytoturnsoftwarereuseintostandardpracticeandfinallygivethetermsoftwareengineeringitsintendedmeaning?Inadditiontotheextremeflexibilityprovidedbytheclassconcept—allowingustobuildopencomponentsthatcanbecombinedandtailoredthroughinheritance—threecrucialaspectsofobject-orientationalreadymentionedinthepreface,seamlessness,reversibility,andsoftwarecontracting,deservemuchmoreattentionthantheyhavehadsofarintheliteratureonanalysisanddesign.Wewilltakealookattheminorder.1.2SEAMLESSNESSTheobject-orientedapproachistheonlymethodknowntodatethathasthepotentialtoturnanalysis,design,andimplementationofgeneralsoftwaresystemsintoatrulyseamlessprocess.Asmoothtransitionfromuserrequirementsoveranalysisanddesignintorunningsystemshasbeenthegoalofsoftwareengineeringforover20years,buttraditionalmethods(althoughoftenclaimingtohavethesolution)havegenerallyfailedinpractice.Thisisnotsurprising,sincethedesignersofconceptsandnotationsforsuchmethodsareforcedtochoosebetweenScyllaandCharybdis.Eitheryouprovideaneasytranslationtosometraditionalprogramminglanguage,whichforcesthenotationtobecomejustanotherprocedurallanguage(oftenintroducingmorecomplexitythanitsolves),oryouinventacompletelydifferenthigh-levelnotationandkeepthebarrierbetweenspecificationandcode.Whatmakesobject-orientationsoattractiveisthatthesameabstractionmechanism(theclass)canbeusedinalldevelopmentphases.Thebasicconceptsneededtomodelobjectsrepresentingsuchexternalnotionsashospitals,airplanes,andwideareanetworksarenotessentiallydifferentfromwhatisneededforobjectsrepresentingquadrupleprecisionfloatingpointnumbers,streetaddresses,orprocessdispatchers.Thesemanticinterpretationoftheabstractionsencapsulatedbytheclassesmayvary,butthegeneralproblemremainsthesame:tospecifyclassconsistency,relationswithotherclasses,andbehaviorthroughapplicableoperations.Beingabletokeepthesameparadigmfrominitialfeasibilitystudyallthewaythroughproductionandmaintenanceofaworkingsystembringsenormousadvantages.Communicationbetweenprojectmemberswithdifferentrolesisgreatlyimprovedwhenthebasicconceptsarethesameforeverybody.Educationisfacilitatedandtheartificialbarriersbetweenspecifiersandimplementorsvanish,makingroomforaholisticviewofthesystemlifecycle.Seamlessnessalsofacilitatesrequirementstraceability.Sincetheclassesintroducedintheanalysisphasewillstillbepresentinthefinalsystem,tracingthepropagationofinitialrequirementsthroughdesignandimplementationbecomesmucheasier.1.3REVERSIBILITYTrueseamlessnessmeansmorethanjusteasytransitionfromspecificationtoimplementation.Fartoomanyobject-orientedmethodsrelyontheunspokenassumptionthattheanalysisanddesignnotationwillonlybeusedintheearlydevelopmentphases,andthentranslatedonceintoprogramcode—objectorientedornot.Butatsomepoint(infact,verysoon)theinitialsystemwillbemodifiedtomeetnewrequirements.Ideally,thiswouldmeanchangingfirstthetopmostdescriptions,andthensuccessivelypropagatingallchangesdownwardsuntilthecodeisreached.However,thisisnotthewayitworksinpracticeformostsystems.Sincehigh-levelspecificationcanonlyrepresentacrudesketchofasystem,lotsofdetailsandproblemsignoredatthatpointwillhavetobetakencareofbeforethespecificationscanbemadeexecutable.Thismeansthatawholenewworldofabstractionsintermsofimplementationlanguageconceptswillbecreated,andthemaininterestandcreativeeffortwillgraduallyshifttothisenvironment.Successiverefinementsandcorrectionswilltendtobeapplieddirectlytotheprogramcode,sinceonlytheredowehaveenoughexpressivepowertoresolveallobscuritiesanddetaileddecisionsthatcouldnotbeaddressedbythespecifications.Andsomeofthesedetailswillnearlyalwaysturnouttohaveasignificantimpactonthesystemstructure.(Iftheprogramcodecouldbeautomaticallygeneratedfromthespecifications,thelatterwouldsimplybecomeournewprogramminglanguageandwewouldnotneedtotalkAboutthelowerlevelsatall.)However,ifabstractsystemdescriptionistokeepitsvaluebeyondthefirsttranslationintoprogramcode,changestothecodemustbereflectedbackintothespecificationsatregularintervals.Hereiswherealltraditionalmethodsbreakdown.Iftheconceptualprimitivesusedbythespecificationandimplementationlanguages,respectively,cannotbedirectlymappedtoeachother(whichisalwaysthecaseinnon-object-orientedapproaches)thiswillleadtoacreepingdivergencebetweenspecificationandimplementation.Itsimplybecomestooexpensivetokeepthetwoworldsconsistentasthesystemevolves,sincethiswouldmeanrepeatednon-trivialtranslationsbetweenmoreorlessincompatibleconceptualstructures.Infact,evenifyoutryhardtokeepallspecificationsuptodate,thereisnowayofknowingiftheyreallyare(becauseoftheconceptualmismatch)sopeoplewillusuallynottrustthemanyway.Afterall,onlytheexecutablespecifications,thatistheprogramcode,evergettotalktothehardwarewhichcarriesoutthesystemactions.Itisthecompleteprogramcodethatdecideswhethertheairplanewilltakeoffandlandsafely,nottheblueprintsdrawnbytheanalyst/designer.Acorrectsystemcanrunwithoutproblemsevenifitsspecificationiswrong,butnotthereverse.Therefore,whenweneedtochooseinpracticewhichdescriptiontofavor,thechoiceiseasy.Thevalueofthespecificationsisthereforedirectlyrelatedtotheeasebywhichtheycanbeseamlesslytranslatedtoandfromprogramcode.Thoseclaimingthatonlytheveryhigh-levelrequirementsandanalysismodelsmatter,withoutgivinganyhintastohowthemappingtoandfromtheexecutablecodecanbedone,donotseemtohavefullyunderstoodwhatitmeanstomanagethemulti-billiondollarinvestmentrepresentedbytoday’ssoftware.Itisprobablynotacoincidencethatthehigh-levelmodelingconceptsofobject-orientedtechnologywerediscoveredbypeoplewhowerestrugglingtomasterthecomplexityofprogramming.Unlikeanyotherapproach,theobject-orientedmethodisinherentlyreversible.Sincetheclassesofanalysisanddesigncanbemadepartofthefinalsystem,anychangestotheimplementationaffectingthestructureandinterfaceoftheseclassesthenbecomeimmediatelyvisible,butonlyifwerefrainfromincludingelementsfromotherfields,suchasentity−relationshipdiagrams,statetransitiondiagrams,ordataflowdiagramsasstandardpartsofourapproach.Mixingparadigmsbreaksthereversibilityandintroducesnewcomplexity,whichwillinmostcasesoutweightheexpectedbenefits.Thisdoesnotmeanthatsuchtechniquescanneverbeusedinobject-orientedsystems.Someapplicationsmaybenefitfromanoccasionalentity−relationshipdiagram,andmodelingcertainabstractionsusingstatetransitiondiagramscanbeextremelypowerful,butbasingageneralmethodonthemmissesthepoint.Instead,weshouldtakeadvantageofthespecialqualitiesofobject-orientation:itssimplicity,coherence,andextremegenerality.Itprovidesthesamesupportforabstractionatalllevelswithoutforcingthemtobeviewedinanyparticularway.Thismakestheapproachuniqueamongdevelopmentmethods,anditsbasicconceptshaveprovedsufficienttospecifyandimplementmostofthesoftwareweneed,almostregardlessofapplicationarea.1.4SOFTWARECONTRACTINGSoftwaredesignedforreuseneedstobeofextrahighquality,sinceitspotentialtoincreaseproductivityalsobringstheriskofcausingmuchmoreharmthanbefore.Writingmostofthesoftwarefromscratchintraditionalstyleatleasthastheadvantageoflimitingtheeffectsofmistakestotheparticularsystembeingdeveloped.However,ifaninadequatesoftwarecomponentis