软件工程的十月革命
开篇：润墨网以专业的文秘视角，为您筛选了一篇软件工程的十月革命范文，如需获取更多写作素材，在线客服老师一对一协助。欢迎您的阅读与分享！
瓦萨战舰为什么沉没？
17世纪上半叶，北欧新教势力与中欧天主教势力发生了一场“三十年战争”，作为北欧新教势力的代表，瑞典的军事力量达到鼎盛时期。1625年，号称“北方飓风”的瑞典国王古斯塔夫斯．阿道弗斯（Gustavs Adolphus）决心建造一艘史无前例的巨型新战舰――瓦萨（Vasa）战舰。瓦萨战舰确实是一艘令人望而生畏的战舰：舰长70米，载员300人，在三层的甲板上共装有64门重炮，火力之强让人难以置信。
1628年8月10日，这艘巨大的战舰终于完工。在斯德哥尔摩，瓦萨战舰举行了盛大的下水典礼。礼炮声中，战舰扬帆起航，乘风前进。在1万多名围观者的目光注视下，忽然，瓦萨号奇怪地摇晃了一下，便向左舷倾斜。海水从炮孔处涌入船舱，战舰迅速翻入水中，几分钟后，这艘雄伟战舰的处女航――也是唯一的一次航行结束了。瓦萨战舰在它壮丽的起航时刻，带着全身飘扬的彩旗，沉没于它诞生的港口。
人们对瓦萨的沉没做出了各种各样的分析，最后的主要结论是：该舰制造工艺精良，但“比例严重失调”，也就是说，该战舰的架构存在缺陷。
瓦萨的沉没早已成为往事。然而，300多年后的今天，在企业信息系统领域，类似“瓦萨”这样的故事却比比皆是。处在工业高度发达的今天，在机械、电子、建筑、车船制造等各个领域，作为学科和工业的基石―“架构体系”早已形成完整的理论和方法体系，但是，与这些成熟的工业领域相比，与企业信息系统相关的架构体系，几乎还处在原始和蒙昧的状态。
今天，如果你向一个建筑专业的设计工程师提问：“建筑的架构由哪些部分构成？”，相信一定会得到确切的回答。同样，如果你向一个开发“企业信息系统”的软件设计师或工程师提问：“企业信息系统的架构由那些部分构成？”，很遗憾，没有人可以告诉你答案。
就是在这样的背景下，在对企业信息化相关的业务架构体系一无所知的情况下，无数的企业信息系统项目，在茫然无知中，启动了一次又一次早已注定的“失败之旅”。
什么是业务基础架构？
简单来说，架构就是针对某种特定目标系统的具有体系性的、普遍性的问题而提供的通用的解决方案。架构往往是对复杂系统的一种共性的体系抽象，架构让我们能够正确、合理地理解、设计和构建复杂的系统。
比如，建筑学认为，所有的高楼大厦（复杂建筑），应该是由建筑结构、暖通系统、强电系统、弱电系统（监控系统、综合布线等）、给排水系统等构成。（体现在建筑图、总平面图、综合管线、结构图、给排水、暖通、强电、弱电等图纸上）。这种建筑学的思想方案，就是建筑设计的“架构体系”。
业务架构体系，就是针对企事业信息管理系统中具有体系性的、普遍性的问题而提供的通用的解决方案。更确切地说，业务架构体系，就是基于业务导向和驱动的架构来理解、分析、设计、构建、集成、扩展、运行和管理信息系统。
比如，最简单地讲，业务架构体系认为，一个信息系统，必须由组织机构、业务流程、业务信息、业务功能、业务语义等层次构成。
假如信息系统没有架构……
为什么需要业务架构体系？其实，这和为什么需要建筑架构体系是同一个道理。简单地说，架构体系是为了帮助我们正确理解、设计一个复杂的系统，以确保我们最终可以成功构建出这种复杂系统。
最好的一个回答，可以借用G.Booch的一个著名的比喻：“开发一个复杂的软件系统和编写一个简单程序大不一样。其间的差别，如同建造一座大厦和搭一个狗窝的差别。”企业的信息系统，无疑也是相当复杂的系统，而复杂的系统的建立，有赖于合理的架构。
架构体系对我们构建信息系统是至关重要的，软件架构在质量、进度、成本和风险方面具有极高的投资回报率。架构的重要性体现在两个方面，第一，架构出现产品生命周期的早期，第二，架构在产品的整体能力上占据了主导作用。合理的架构为软件系统生命周期的所有阶段――设计、开发、测试、集成和更改都奠定了关键的基础。相反，如果架构体系不当，就意味着系统存在巨大的体系性缺陷，并且无法通过细小的修补或调整得到更正，架构不当往往导致系统的彻底报废，或者需要系统的全部拆解重建。
1986年，弗雷德里克.布鲁克斯（Frederick P Brooks）在《没有银弹--软件工程的主要问题和次要问题》中提出了一个迄今为止尚未打破的一个著名论断:
"没有一种单纯的技术或管理上的进步，能够独立地承诺在10年内大幅度地提高软件的生产率、可靠性和简洁性。”
在论证这一论断时，弗雷德里克指出：所有软件活动包括根本任务--打造构成抽象软件实体的复杂概念结构；次要任务--使用编程语言表达这些抽象实体，在时间和空间内将它们影射成机器语言。从这一点观点出发，在对几乎现有所有的软件工程解决方案作了考察和评估后，弗雷德里克发现，现有所有方案全都在致力于解决软件工程中的次要问题，因此，无论这些方案多么完善，都不可能在根本上解决问题，因为，即使将全部次要任务的时间缩减到零，也不会带来生产率数量级上的提高。
当然，我们也不能保证业务架构体系就是软件业渴求以久的“银弹”，但我们至少可以肯定一点：业务架构体系是一个正确的方向――因为业务架构平台是唯一致力于解决关键问题的方案。
构建和集成复杂系统！
在某种意义上，可以说引入架构体系的一个最终目的，就是构建和集成一个复杂的系统。由于复杂系统往往是一个分层的体系结构，并且，每一层次的作用都是完全不同的。复杂系统的集成，就是要使体系中的各个层次能够彼此有效配合而形成一个有机的整体。
从本质上讲，复杂系统集成，不是一些功能类似的部件（或组件）的简单堆砌和拼接，而是功能不同的组成部分的复杂配合。
管理信息系统的构建和集成也是如此，我们不能将“组织机构管理”、“流程控制”和“订单管理”这三个完全不同层次上的构成部分简单堆砌起来。事实上，“订单管理”和其它业务模块需要共同依赖统一的“组织机构管理”和“流程控制”体系支持。
诺贝尔奖获得者赫伯特 A. 西蒙曾论述到：“要构造一门关于复杂系统的比较正规的理论，有一条路就是求助于层级理论……复杂系统是层级结构的”。架构体系往往就是一个由不同层级构成的体系。
因此，我们必须按照架构体系来定制部件和组件，并将其安装到合适的层次位置上，才能使系统有效运作和集成。复杂系统集成的关键，是基于架构（或体系）的集成，而不是基于部件（或组件）的集成。优秀的架构设计者都清楚一点，只有基于良好的架构，组件才会被有效集成和发挥应有的作用。
基于业务架构体系的软件开发过程
复杂系统的正确理解和设计，有赖于架构体系的建立，复杂系统的构建，往往需要采用建模的方法。基于业务架构体系来设计和构建企业信息系统的过程，我们称为业务建模。业务建模的直接产品，我们称为业务模型应用资源。
将业务模型应用资源到业务架构平台上，就可以得到相应的业务信息系统。业务架构平台，就是基于某种业务架构体系的一种现成的(Ready)解决方案和制品。或者说，是针对企事业信息系统中具有体系性的、普遍性的问题而提供的现成的、通用的解决方案和制品。
利用业务架构平台这种现成的制品，可以大幅度地简化开发工作，降低开发成本，并提供更好的质量保证。
基于业务架构体系的软件开发过程大致如下：
这一过程体现了“以模型应用资源为中心”的思想，这一思想要求使用业务建模的开发模式，并将建模的结果――“业务模型应用资源”作为管理软件开发的主体产品，以“业务模型应用资源”为主要的目标对象，进行信息系统的设计、构造、、集成、维护和管理。
业务建模过程的主要组成部分及作用：
业务建模：基于业务架构体系的关键开发模式和过程。业务建模的开发模式一般具有如下特征：
1. 业务导向性
2. 尽可能的技术无关性
3. 设计更加规范和体系
4. 快速开发
5. 快速迭代
6. 建模的结果是资源，资源需要管理
业务模型应用资源库：一组独立的、完整的完成企业业务的模型资源的集合,通过技术平台无关的持久存储方式保存。资源库提供如下：
1. 统一的资源对象引用规范
2. 统一的资源对象存储和访问
3. 所有业务模型资源的版本管理
4. 所有业务对象的安全访问控制
5. 允许开发者或团队构造特权，如资源保护，维护授权等
业务架构运行平台：一个完成了业务架构体系中通用解决方案的制成品。业务架构运行平台自上而下地构架和集成整个业务系统，并与实际业务系统对应一致。业务模型应用资源应该在业务架构运行平台上和运行，以实现：
1. 在运行系统无中断情况下快速添加和实施新的功能
2. 实现系统的快速迁移
3. 来自不同生产厂商的模型资源的可重用性
4. 使来自不同生产厂商的系统，与同一厂商的系统，具有相同的可集成性和协作性
5. 非常高的可伸缩性
JUSTEP BUSINESS 3.0业务架构平台
Justep Business业务架构平台是业务导向和驱动的软件构架体系。Justep Business平台的基本思想是：采用业务架构平台统一信息系统的基本运行支撑环境，以业务建模工具（Business Studio）作为信息系统的开发维护工具。
Justep Business平台通过引入企业模型理论（EE/EM），为管理软件设计和开发提供业务层面的导向和依据。企业模型规范了描述企业业务的各类要素和方法规则，可以全面、准确地描述用户需求，保证信息系统按照正确的架构开发。
那么，为什么要分离运行环境和开发环境呢？因为我们的开发方式主要以建立模型为主，而且我们的模型不同于以往的计算模型，我们建立的模型首先是业务模型，而不是为编程服务的程序结构模型，另外，我们的业务模型是可以直接运行，表现为完整的应用系统。为了让业务模型可以直接运行，就需要一个可以理解模型的运行环境，也就是说，在Justep Business里，我们把一个完整应用系统的应用内容与运行部分进行了分离。
分离的结果是，应用相关的内容全部被存储在服务端的数据库里，而运行部分则独立于应用，可以用多种不同的分布方式跨越各种不同的软件系统。这样，我们就把底层的实现技术从应用系统中剥离出来，应用开发人员不用再花大部分时间解决底层的实现问题，例如不用再过多关注后台数据库的ＳＱＬ语句的特性，不用关注应用的方式，不用关注某一种ＥＪＢ服务器的配置和维护方式，可以集中精力解决应用中的问题。即在很大程度上实现了应用开发的技术无关性。
运行环境与应用部分（业务内容）分离，可以使运行环境随时用最新技术重新实现，而不影响已经的应用，即应用部分可以不做任何改变，就能以新的分布方式运行，或迁移到更新的技术平台之上，或迁移到性能更高的服务环境（例如从ＮＴ服务器迁移到小型机的ＵＮＩＸ环境中）。
当然运行问题的解决只是解决了布鲁克斯所谓的次要问题，将某种描述出来的概念体系，在时间和空间内将它们影射成机器语言，并使之运行。虽然是次要问题，但不是说这个问题不重要，只是我们还有更重要的任务，那就是解决根本问题，“打造构成抽象软件实体的复杂概念结构”，就是按照业务模型构造整体的信息系统。
我们已经把企业的各种活动抽象为一系列的业务要素，并整理出了各层级业务要素之间的关系。
建立一套应用系统的任务已经转换为按业务模型构建这些内容。
举例说明，我们要完成下图所示的订单处理的业务，对于传统开发方式对于这个问题的解决，我们不在此赘述。
我们看在Justep Business业务架构平台中，如何解决。
我们可以采取自上而下，或者从底向上的开发方式。
对于从底向上，是大多数开发模式所采用的，先完成数据建模，然后开发数据的表现和操作界面，在用编程方式实现这些内容的同时，要考虑到用什么样的方式运行该系统，并且不同的开发习惯会出现完全不同的实现结果。
在业务架构平台的构建过程中，我们更推荐用自上而下的方式进行，再辅助以快速迭代的方式可以更快更准确地完成任务。
首先，我们可以在Justep Business Studio中将上图的流程按图例所示，在业务流程定制工具中绘制出来，完成对流程的描述。从流程中，我们可以容易地抽取出业务功能环节，对订单的确认，收预付款，规划生产，这些是需要人为参与的环节，流程的其他部分是一些由其他功能环节触发的动作或者对一些业务要素状态的检测等，作为业务规则进行定义。
整个的这个流程构建过程都不涉及代码的编写，当然，在Justep Business的流程模型中提供了强大的事件处理机制，可以让我们对流程中的环节，或其他一些业务对象按事件驱动的方式进行编码，控制流程在流转中完成更细节的任务。
例如，可以对功能环节在流入之前，流出之后，功能回退时需要执行的定制代码都可以按具体任务定制。
接下来，对抽取出来的业务功能进行进一步描述。
确认订单的功能是对订单这样一个业务信息进行的操作，所以我们需要在业务信息中定义这样的一个订单业务信息。
如果这个信息不在别的业务功能中重用，我们也可以直接在当前的功能中直接定制。
但按照业务架构的模型体系，把可能会被重用的业务对象提取到业务信息层，往往更符合面向对象的开发。
在这里，订单对象的重用应该是一定会发生的，我们可以在订单业务信息中对这个对象进行完整的定义和描述。
在“确认订单”这个业务功能中，只是在需要的时候添加一些对“订单信息”的调度控制。
对于“订单信息”的描述，可以在Justep Business中采用可视化的（ＲＡＤ）方式完成。
也可以利用Justep Business提供的各种信息模板自动生成。业务信息是业务数据加上数据的表现形式，所以我们可以从业务信息中提取要持久存储的业务数据，这些业务数据及相互之间的关系就是我们构建业务数据模型的基础，Justep Business的业务数据建模部分，可以让开发人员按统一的方式把这些数据模型建立在任何一种数据库中，对业务数据的关系描述，可以脱离数据库的具体特性，在业务数据层中进行定义。
这样对数据库服务的要求就降到了最低，在保证可以平滑迁移到不同的数据库平台的同时，还获得了非常高的数据服务效率。
到此，一般意义上的应用开发已经几乎完成。比一般管理信息系统多出的还有我们在最开始完成的业务流程。这在以往是由程序组使用第三方工作流工具或自己写的简单工作流引擎来做的，现在我们可以把这一切集成在一个开发平台里进行。但我们现在还缺一层，那就是分别对应的系统功能分配给机构中的不同的人。这问题在越大的企业里，就越是严重。复杂的组织机构的实现不只是影响某单一应用系统的运行和管理，对于一个企业的不同部门，不同的应用模块，更需要从一个统一的组织机构进行整合。而目前按统一的组织机构模型实现企业信息系统配置的工具或软件在市场上几乎是空白。Justep Business业务架构平台从许多管理模型中对这一问题的解决进行了统一的抽取。可以按照企业的组织机构图，快速由用户自己对组织模型进行定义和维护，可以按纵向的金字塔结构或扁平化的矩阵结构描述企业的组织机构，可以建立岗位模型和人员模型。把信息系统中的各种功能或数据权限分配到某一个机构、岗位或成员。
这些内容只是业务架构平台的一部分，更多的细节，我们都没有提及。这个订单业务模型资源，可以选择在J2EE、COM+、甚至CORBA上运行。
业务架构平台本身牵涉的范围很广，理论和纯技术方面都需要很广泛的知识。实现业务架构平台，需要引入多种不同领域的理论，融合各类技术，跨越很多技术难关。因此，在我们构建Justep Business业务架构平台开发中，产品创新很重要。业务模型是业务架构平台的核心，模型的合理性尤其重要。用户的业务需求千变万化，让有限的模型元素和特性满足复杂多变的需求，对业务模型的抽象提出了非常高的要求。一个好的业务模型必须在模型的一致性、完整性、精度、通用性、可扩展性等方面都达到较高的水准。
通过这个简单的小例子我们就可以看到，应用系统的开发已经被业务架构平台转化为一种科学，一种工程方法，利用这种方法我们可以让更多的企业降低信息系统的风险成本，获得企业真正想要的应用系统。