JAVA基本概念

对象：对象是要研究的任何事物。从一本书到一家图书馆，单的整数到整数列庞大的数据库、极其复杂的自动化工厂、航天飞机都可看作对象，它不仅能表示有形的实体，也能表示无形的（抽象的）规则、计划或事件。对象由数据（描述事物的属性）和作用于数据的操作（体现事物的行为）构成一独立整体。从程序设计者来看，对象是一个程序模块，从用户来看，对象为他们提供所希望的行为。在对内的操作通常称为方法。


类：类是对象的模板。即类是对一组有相同数据和相同操作的对象的定义，一个类所包含的方法和数据描述一组对象的共同属性和行为。类是在对象之上的抽象，对象则是类的具体化，是类的实例。类可有其子类，也可有其它类，形成类层次结构。

消息：消息是对象之间进行通信的一种规格说明。一般它由三部分组成：接收消息的对象、消息名及实际变元。

面向对象主要特征：
　　

封装性：封装是一种信息隐蔽技术，它体现于类的说明，使数据更安全.是对象的重要特性。封装使数据和加工该数据的方法（函数）封装为一个整体，以实现独立性很强的模块，使得用户只能见到对象的外特性（对象能接受哪些消息，具有那些处理能力），而对象的内特性（保存内部状态的私有数据和实现加工能力的算法）对用户是隐蔽的。封装的目的在于把对象的设计者和对象者的使用分开，使用者不必知晓行为实现的细节，只须用设计者提供的消息来访问该对象。

继承性：继承性是子类自动共享父类之间数据和方法的机制。它由类的派生功能体现。一个类直接继承其它类的全部描述，同时可修改和扩充。
继承具有传递性和单根性.如果B类继承了A类,而C类又继承了B类,则可以说,C类在继承了B类的同时,也继承了A类,C类中的对象,可以实现A类中的方法.一个类,只能够同时继承另外一个类,而不能同时继承多个类,通常所说的多继承是指一个类在继承其父类的同时,实现其他接口.类的对象是各自封闭的，如果没继承性机制，则类对象中数据、方法就会出现大量重复。继承支持系统的可重用性,从而达到减少代码量的作用，而且还促进系统的可扩充性。


　多态性：对象根据所接收的消息而做出动作。同一消息为不同的对象接受时可产生完全不同的行动，这种现象称为多态性。利用多态性用户可发送一个通用的信息，而将所有的实现细节都留给接受消息的对象自行决定，如是，同一消息即可调用不同的方法。例如：Print消息被发送给一图或表时调用的打印方法与将同样的Print消息发送给一正文文件而调用的打印方法会完全不同。多态性的实现受到继承性的支持，利用类继承的层次关系，把具有通用功能的协议存放在类层次中尽可能高的地方，而将实现这一功能的不同方法置于较低层次，这样，在这些低层次上生成的对象就能给通用消息以不同的响应。在OOPL中可通过在派生类中重定义基类函数（定义为重载函数或虚函数）来实现多态性。

SOA（Service-oriented architecture，面向服务架构）

SOA是在计算环境下设计、开发、应用、管理分散的逻辑（服务）单元的一种规范。这个定义决定了SOA的广泛性。SOA要求开发者从服务集成的角度来设计应用软件，即使这么做的利益不会马上显现。SOA要求开发者超越应用软件来思考，并考虑复用现有的服务，或者检查如何让服务被重复利用。SOA鼓励使用可替代的技术和方法（例如消息机制），通过把服务联系在一起而非编写新代码来构架应用。经过适当构架后，这种消息机制的应用允许公司仅通过调整原有服务模式而非被迫进行大规模新的应用代码的开发，使得在商业环境许可的时间内对变化的市场条件做出快速的响应。

SOA 帮助企业信息系统迁移到"leave-and-layer"架构之上，这意味着在不用对现有的企业系统做修改的前提下，系统可对外提供 Web 服务接口，这是因为它们已经被可以提供 Web 服务接口的应用层做了一层封装，所以在不用修改现有系统架构的情况下，SOA 可以将系统和应用迅速转换为服务。SOA 不仅覆盖来自于打包应用、定制应用和遗留系统中的信息，而且还覆盖来自于如安全、内容管理、搜索等 IT 架构中的功能和数据。因为基于 SOA 的应用能很容易地从这些基础服务架构中添加功能，所以基于SOA的应用能更快地应对市场变化，为使企业业务部门设计开发出新的功能应用。


BPM是英文字母缩写，大致有五个意思。Business Process Management，即业务流程管理，是一套达成企业各种业务环节整合的全面管理模式。Business Process Modeling，即业务流程建模，是对业务流程进行表述的方式，它是过程分析与重组的重要基础


企业的流程管理一般分为生产流程层、运作层、计划层和战略层四个层次




在这个阶段的企业需要解决的问题如何提高企业的效率和反应速度。通常采用的方法是先对现有流程的绩效进行评估，识别缺失的关键环节和需要改善的环节，针对流程各环节从可以以下四个角度进行分析：
　　－活动：是否过于复杂，存在精简的可能性
　　－活动实现形式：是否能用更有效率的工具来实现活动
　　－活动的逻辑关系：各环节的先后关系可否作调整以达到改进目标
　　－活动的承担者：是否可以通过改变活动的承担者来使流程更有效率

面向工作流的BPM
　　工作流描述了在BPM空间内人与人的交互和人与系统的交互。根据独立分析师Sandy Kemsley所述，工作流就是我们所熟知的BPM的初始阶段。“一开始就有工作流，”Kemsley在她网站的第二专栏中写道。“更确切地说，在预先确定的流程图中有一个扫描过的人与人之间交互的路由文档。”在当代BPM的大背景下，工作流和EAI（企业应用集成）平起平坐，并在某种程度上，可以看成是人的集成。工作流BPM旨在优化业务流程中以人为本的活动。这些措施包括活动监控，流程治理，正如BPM的成因，是对未完成文档向下进一步处理的编制。


面向文档的BPM
　　文档管理和工作流齐头并进。当文件穿过工作流时，追踪文件的去向以及它们的变动，维护文档记录的可靠性、安全性、可用性，早在计算机革命之前，已经成为了业务的必要元素。今天的企业文档管理系统利用计算机技术来提供存储、安全、索引和检索选项。可用性正日益重要，因为多方参与者经常需要凭借多个应用来使用同一个文件。因此，依靠现有业务系统的集成是面向文档BPM成功的一个主要元素。
面向业务规则的BPM
　　自动化这门学科可以追溯到人工智能的早期，当时研究人员试图以最简单的术语，集中于规则的使用来描述复杂的系统。像最早的尝试模拟国际象棋游戏实验计算机，这些系统按照状态机的模式工作。有点像游戏规则，组织显式地或隐式地按照关键“规则”来定义过程，这些关键“规则”在流程的某些点上提出要做出哪些决定或更改——或请求哪些授权。一旦被称为推理机，同类的软件系统就发展成了业务规则引擎或者业务规则管理系统。创建和维护业务规则的复杂性常常成为这些推广这些系统的阻碍成分。
　　这些系统承担了类似以建模为中心的BPM工具的角色。（诚然，很多用户会将以建模为中心的BPM作为一个独特的类别。）以建模为中心的方法起初倾向于自上而下的进行工作，这些工作就是在模型中用特殊符号描述一个组织，或组织的改进。近年来一些工具厂商已经完成对可执行模型的支持——他们的模型可以生成或者帮助形成可用的业务逻辑的代码。与这里介绍的其他类型的BPM系统相比，业务规则引擎在纯BPM系统中的规模将变得更大。
面向EAI的BPM
　　在整个90年代从不同系统对集成可操作型数据方法的改进，采取的是企业应用集成或EAI的形式。虽然这些往往是硬接线的一对一集成，消息队列这种应用集成变得尤其流行，同时隐含业务流程表现为有组织的队列，例如，清除银行支票或执行库存订单，让集成服务器很大程度上有了面向工作流的BPM的味道。今天，许多架构师都倾向于把数据集成问题看成业务流程问题。同样地，一些架构师将期望根据B2B或电子数据交换（EDI）来集成的过程自动化。


工作流(Workflow)，就是“业务过程的部分或整体在计算机应用环境下的自动化”，它主要解决的是“使在多个参与者之间按照某种预定义的规则传递文档、信息或任务的过程自动进行，从而实现某个预期的业务目标，或者促使此目标的实现”