传统OOAD可能存在的问题

step365he

为什么要 OOAD/BE/BPM 的OOAD到SOAD来转变呢肯定会有人这样问，那么我就说有三个原因决定了我们需要转变的原因:

1.我觉得本来的BPM(Business Process Modeling)--->BE(Enterprise Architecture)-->OOAD(Object-Oriented Analysis and Design)是我们比较传统的开发方式通常叫OOAD，随着我们对软件或者抽象思维和管理RUP的过程中已经暴露出一些不合理的地方: OOAD 还是与像类和单独的对象实例这样的微观层次的抽象有关。由于每个问题域常常都创建单独的用例分析模型，因此，应用程序开发项目，这个企业的大方向在许多情况下变得模糊；此外，由于种种原因，用例分析模型并不总是与其对等的 BPM 保持同步------------这样的架构方式存在的风险大了，很难集中观看架构系统的总目标。

2.同时在我们日常简单的开发过程有时候会遇到对原有系统（或者遗留系统）进行维护重构，这个时候除正规的正向工程化（自顶向下流程），同时也需要我们对复杂和混乱的业务数据和逻辑进行必要研究包装和重构的逆向工程化(自底向上的分析)，因此现有应用程序的考虑会将我们带到中间相遇的开发设计流程,传统的OOAD没有很好解决这样的问题。

3.应该这么说SOA 虽然可以等同BPM,BE,OOD的综合，形成一个有效而且可以解决上面的问题一个思路，其实他们之间没有任何抵触的地方，反而是BPM,BE,OOD是为SOA提供技术的支持,并且能统一协调了各个层面的整合，为以前独立而分散的层次有了一个更合理方便的，减少在这个方面的成本和风险。

我越来越相信SOAD的年代已经到来了，随着IBM/MS/BEA 等公司主推的SOA标准也越来越清晰和健全，我们是时候来迎接它的到来;同时也要做好适应SOAD准备----其实SOAD并不是要推翻以前的OOAD/BE/BPM，恰恰是一种必然客观进步必然的结果


上一篇：北理工面向对象分析与设计资料
下一篇：OOAD with UML Designer

step365he

所谓BPM(Business Process Management), 即业务流程管理，是指根据业务环境的变化，推进人与人之间、人与系统之间以及系统与系统之间的整合及调整的经营方法与解决方案的IT工具。业务流程管理应该包括"建模-实施-监控-管理"等过程，要具备其所需的所有服务与工具才能叫作BPM。
现在的信息系统开发方式的缺点在于对需求表达不清晰、效率不高。在这种思维方式下流程被固化在系统中，企业不能随着商业环境的变化而方便迅速地改变业务流程，而企业环境的变化促使企业必须快速地调整业务来响应。实时性企业将敏捷地使用最新信息，以积极地消除其关键性业务流程中的管理与执行层面出现的低效率延迟。BPM的出现正是为了解决企业流程实时改变所带来的敏捷性、实时效果评估、资源整合与优化等问题，而这些问题是不能为传统的OA和工作流所解决的。
通过BPM，可以对业务流程进行自动化,并通过流程的分析及监控功能,对业务进行整合及计量,从业务角度、组织角度、IT角度都可得到可量化的改善效果，这种效果随着管理者通过BPM分析与优化流程，将越来越显著。

完整的BPM系统需由图形化流程设计环境、流程管理与监控、BPM引擎、使用者执行环境以及整合各种资源的底层EAI平台等主要元素所架构而成。一般来说，BPM基于SOA(Service Oriented Architecture)架构。BPM通过捆绑其他应用系统的服务来制作并提供跨应用系统的BPM流程，也可以组合各个单纯的业务服务生成新的服务，对其基本要素进行模块化管理，并且可以循环使用。基于SOA的架构将对J2EE平台的适应性提出更高的要求，Gartner的研究表明，未来2年与J2EE平台结合紧密的BPM产品将占据主导地位。
另外，由于BPM记录了业务流程的所有活动，可以对流程管理所需的关键性指标进行设置，向流程实施者及管理者提供实时而直观的业务、组织和个人的绩效数据，可以实现有效的客观性成果测定效果。

step365he

面向服务的体系结构（Service-Oriented Architecture，SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以一种统一和通用的方式进行交互。

这种具有中立的接口定义（没有强制绑定到特定的实现上）的特征称为服务之间的松耦合。松耦合系统的好处有两点，一点是它的灵活性，另一点是，当组成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时，它能够继续存在。而另一方面，紧耦合意味着应用程序的不同组件之间的接口与其功能和结构是紧密相连的，因而当需要对部分或整个应用程序进行某种形式的更改时，它们就显得非常脆弱。

对松耦合的系统的需要来源于业务应用程序需要根据业务的需要变得更加灵活，以适应不断变化的环境，比如经常改变的政策、业务级别、业务重点、合作伙伴关系、行业地位以及其他与业务有关的因素，这些因素甚至会影响业务的性质。我们称能够灵活地适应环境变化的业务为按需（On demand）业务，在按需业务中，一旦需要，就可以对完成或执行任务的方式进行必要的更改。

虽然面向服务的体系结构不是一个新鲜事物，但它却是更传统的面向对象的模型的替代模型，面向对象的模型是紧耦合的，已经存在二十多年了。虽然基于 SOA 的系统并不排除使用面向对象的设计来构建单个服务，但是其整体设计却是面向服务的。由于它考虑到了系统内的对象，所以虽然 SOA 是基于对象的，但是作为一个整体，它却不是面向对象的。不同之处在于接口本身。SOA 系统原型的一个典型例子是通用对象请求代理体系结构（Common Object Request Broker Architecture，CORBA），它已经出现很长时间了，其定义的概念与 SOA 相似。

不同种类的操作系统，应用软件，系统软件和应用基础结构（application infrastructure）相互交织，这便是IT企业的现状。一些现存的应用程序被用来处理当前的业务流程（business processes），因此从头建立一个新的基础环境是不可能的。企业应该能对业务的变化做出快速的反应，利用对现有的应用程序和应用基础结构（application infrastructure）的投资来解决新的业务需求，为客户，商业伙伴以及供应商提供新的互动渠道，并呈现一个可以支持有机业务（organic business）的构架。SOA凭借其松耦合的特性，使得企业可以按照模块化的方式来添加新服务或更新现有服务，以解决新的业务需要，提供选择从而可以通过不同的渠道提供服务，并可以把企业现有的或已有的应用作为服务， 从而保护了现有的IT基础建设投资。

阳光一号

画扇描眉染尽席

很有见地的探讨，先收藏着~

炫烨

看帖要回，回帖才健康，在踩踩，楼主辛苦了！

道拉格斯

众里寻他千百度，蓦然回首在这里！

反方向的钟

没人回帖。。。我来个吧！

老明

确实不错，顶先

浅挚半离兮つ

顶不错 支持下

夏天

其实，很多情况下都是这样的，习惯就好。

随遇而安丶

前排支持下了哦~

boys吶雪眞羙

非常好，顶一下占位编辑

呐些、伤痛

非常好，顶一下占位编辑

じ☆ve﹏知

以我的经验来看，楼主的想法是可以执行的~