根据目的性的不同，笔者认为，软件隐喻大致可以分为三种隐喻模式。如果以隐喻的方式给出，即为蓝图模式、地图模式和图示模式。

  (1)蓝图（blueprint）模式

  在中文语境中，蓝图一词通常引申为一种构想和计划。它往往从宏观的角度，高屋建瓴地对整个体系进行规划与设计。蓝图模式的软件隐喻往往意味着软件思想的变迁，甚至在有些时候，是这些隐喻推动了软件思想的变革。

  例如软件设计思想，就经历了从函数发展到对象，从对象发展到组件，再从组件发展到服务的几次变迁。整个发展历程可以从每个阶段的软件隐喻中读出其中变迁的含义：面向过程（procedure）思想，面向对象（object）思想，面向组件（component）思想，面向服务（service）思想。事实上，软件设计思想的每次变迁，都代表了人们对软件开发的一种认知。面向过程思想就是“采用结构化的分析和设计技术来理顺编程中的混乱情况。”而这种结构化模型背后的推动力就是“过程”。

  面向对象思想则以“对象”的方式对数据进行封装、继承与抽象，从而实现软件的可重用性、可扩展性。“组件”则是对象的一种发展，它提供了可交换的、可互操作的二进制组件。而随着分布式系统的大量应用，软件隐喻“服务”则应运而生，通过定义良好的接口和契约，并按照统一和通用的方式实现各种平台之间的交互。服务在内部封装了复杂的业务逻辑和业务流程，以供消费者调用，这与现实生活中的服务概念何其相似。正是“服务”的隐喻，推动了面向服务体系架构（Service Oriented Architecture，SOA）的建立与发展。

  或许我们无法断定，究竟是先产生了设计思想，然后为了便于理解，才找到一个合适的软件隐喻来表述它们；还是由于受到日常事物的启发，从而根据对该事物的深层认知，产生革命性的思想变迁。然而，这种蓝图模式的推动与规划意义却是不言而喻的。

  最能体现软件开发蓝图的是另一个软件隐喻——“软件工程（Software Engineering）”，它来自于工程学领域。按照IEEE的定义，软件工程是指采用一种有组织、有纪律、可计量的方式来开发、使用及维护软件，也即在软件领域中对工程学的采用。软件工程的隐喻影响巨大，甚至在一定程度上左右了软件开发的发展方向，因为它将软件开发推向了工程学的范畴。借助工程学中的概念对软件工程予以规范、指导，包括从软件的可行性分析直到软件交付之后的维护工作。正如在1968年NATO（北大西洋公约组织）的会议报告《软件工程》中提出：“我们之所以选择了‘软件工程’这个颇具争议性的词，是为了暗示这样一种意见：软件的生产有必要建立在某些理论基础和实践指导之上——在工程学的某些成效卓著的分支领域中，这些理论基础和实践指导早已成为了一种传统教义。”

  与之相对的隐喻是“软件工艺（Software Craftsmanship）”。在《软件工艺》一书中，Pete McBreen写道：“用‘工艺学’来比喻软件开发，这可以看成是对软件开发的一次追根溯源。[7]”软件工艺认为“软件开发就是工匠的技艺，它融合了艺术、科学与工程学”。Pete提出软件工艺的隐喻，并非是要颠覆“软件工程”，而是试图纠正过分强调软件工程所带来的问题。例如，软件工程所假设的“有组织、有纪律、可计量的开发方式”，在现实的软件开发过程中很难做到，因为软件开发不是一个确定过程。

  蓝图模式的软件隐喻所指代的含义代表了一种方向、思想与目标，它能起到正本清源的作用。然而，我们不能片面地偏废某一种隐喻，而应全面地看待隐喻的象征意义。因为，不同的隐喻彼此并不排斥，应当使用对你最有益处的某种隐喻组合。