本节书摘来异步社区《敏捷制造——敏捷集成基础结构设计》一书中的第2章，第2.2节，作者：苏金泷，更多章节内容可以访问云栖社区“异步社区”公众号查看
2.2 敏捷企业集成基础结构建模技术
敏捷企业集成基础结构的建模之所以有别于传统建模，根本原因是其建模对象和管理思想的改变。传统建模的目的是在企业内部对企业进行建模改造，而敏捷企业集成基础结构的建模是在企业外部建设敏捷化公共服务平台，通过设立一定的接口标准，由外部来规范其成员企业的组织结构。集成基础结构中的各个模块，可以分别属于不同的成员企业，模块之间既有共性又有个性。集成基础结构的建模是根据特定行业的共同经验，结合特定成员企业自身的情况，来设立虚拟企业的成员企业内部和虚拟企业的整体组织结构模型。因此，系统构建必须建立在充分认识、完整表达和准确分析企业动态联盟中角色行为的基础上，也就是说基于网络的敏捷化制造平台的系统模型的优劣是网络化制造平台能否成功运行的关键。可见，如何选择并改进适应网络化制造平台的建模方案显得至关重要。
2.2.1 体系结构为中心的建模步骤
集成基础结构建模是以敏捷制造和敏捷供应链的成员企业为背景，因此，我们这里的领域建模首先是指对敏捷企业进行建模。企业建模是一个通用的术语，它涉及一组活动、方法和工具，它们被用来建立描述企业不同侧面的模型[Y07] [L04]；是根据关于建模企业的知识、以前的模型、企业参考模型，领域的本体论和模型表达语言来完成建立全部或部分企业模型（过程模型、数据模型、资源模型、新的本体等）的一个过程。
如图2-2所示，集成基础结构建模中，体系结构是设计过程的一个阶段，它关心的是如何将复杂的系统划分为主/子系统，以及如何约定子系统的构成和性能。以体系结构为中心的建模目标[L04]就是建立一个一致的系统及其部分的视图集，并以满足终端用户和后期设计者需要的结构形式化表达，其中包括需求规划、规划设计、综合建模、技术支持等多个方面。因此，集成基础结构软件体系的构建有两个特定的广泛目标。一个外向目标，建立满足终端用户要求的系统需求，一个内向目标，建立满足后期设计者需要以及易于系统实现、维护和扩展的系统部件构成。从构建体系结构，到使用该体系结构实现系统的设计，直到此系统的最终完成和进一步拓展，应包括如下阶段[L04]：
1．建立领域模型与本体；
2．根据领域模型与本体，建立系统需求模型。包括基于用况模型的系统需求分析，对用况进行角色模型分析，识别Agent；
3．构建选用组织结构模式，并与有关各方进行交流，对此组织（体系）结构进行风险和评价；对Agent间的交互进行描述，建立交互协议与交互模型；
4．根据交互模型以及Agent结构，建立各个Agent进行信念知识库模型；
5．系统实现，产生代码模型；
6．实施构造并运行测试。
集成基础结构建模过程的各个阶段包括[L04]：
1．本体建模。关于本体的构造，Gruber中给出了指导本体构造的5个准则[S06]：（1）明确性和客观性；（2）一致性；（3）可扩展性；（4）最小编码偏差；（5）最小本体承诺。Uschold & Gruninger提出了一个本体构造的方法学框架，在这个框架内，他们详细地描述了本体捕获和形式化的本体设计和评估方法[O03]。M. Gruninger & M.S. Fox在进行TOVE本体的研究和开发时，也总结了设计和评估本体的方法学，包括背景和需求描述、非形式化的能力问题描述、词汇和术语确定、形式化的能力问题描述、用一阶谓词逻辑进行规范描述、确定完整性定理等步骤[FWG01]。Bertolazzi等提出了建立核心企业本体（Core Enterprise Ontology，CEO）的方法[GO93]。
2．领域建模。建立领域ontology的关键是参照一定的领域模型给出该领域中的概念以及概念之间的关系。在领域工程，领域本体则反映了一个特定领域中可重用的、本质的概念[UKM98]。它提供特定领域的概念定义、概念之间的关系、领域活动、领域理论和原理等，从而描述领域知识。领域知识可以划分3个层次，领域具体知识、领域概念知识和领域通用（概念）知识。其中领域通用（概念）知识是一种公理化的知识。领域概念知识是领域内本质的知识，即领域本体。领域具体知识是领域内具体事物、具体事件的知识，可以用领域概念知识表达的知识。显式定义语义信息的基础概念已经在分布式问题求解（DPS）、Agent和知识共享等研究领域建立起来了。XML为这些概念和方法以一种既符合Web标准，又符合商业需求的形式重新应用奠定了基础。这些考虑都直接导致本体技术应用于XML研究领域。基于XML的本体描述语言有：XOL（XML-based Ontology Language），这是一种基于XML语法和OKBC（Open Knowledge Base Connectivity）语义的本体交换语言。
3．系统需求建模。这是在领域模型和本体的指导下进行，充分利用本体描述系统需求，并根据过程模型与本体进行分析。对于大型的软件开发在很好地了解领域范围的基础上创建一个粗略的临时体系结构轮廓；对系统总目标（战略目标）进行分析并分解成用户目标、子目标，用用况描述描述用户目标或子目标，构造用况模型。然后采用基于角色模型的用况分析，即确定需要哪些角色以及各角色之间如何进行交互去实现用况目标，然后进行角色合并，把角色分配给具体的Agent即确定系统中的Agent。[L04]
4．组织结构建模。多Agent系统（Multi Agent System，MAS）的组织结构与人类的组织模式有着可类比的关系。从宏观来看，二者都存在任务、资源和信息的分配；从微观来看，西蒙[GF95]的有限合理性理论表明，二者都要为解决复杂问题而不断改进组织结构。组织结构模型是系统建模的核心模型，即系统的软件体系结构，它包含了系统中最重要的静态和动态特征[L04]。体系结构是根据企业的需要逐渐发展起来的，受到用户和其他项目相关人员需求的影响。
5．交互建模[L04]。本阶段主要根据交互模型进行信念知识库建模、行为（任务）建模；根据行为进行交互协议选择，确定通信的本体以及内容语言格式；分析交互协议制定交互策略，创建效用函数以及约定。理想的交互协议应当存放在协议服务器上，Agent根据交互的需要自动下载协议。如果协议不能满足交互的需要，我们才会采用图形工具进行协议规范及建模。Agent在交互过程中应自动实现协议的嵌套以实现复杂的交互（会话）。
2.2.2 面向对象的MAS建模思想
面向Agent程序设计（Agent-Oriented Programming, AOP）已成为软件开发的主流，它是面向对象程序设计（Object-Oriented Programming, OOP）的成功应用。OOP中的对象（Object）是封装了状态和一系列方法的实体，其方法对应于可以对其状态进行操作的行为，并通过消息激发而被调用以便为其他对象提供服务。传统的面向对象程序只有一个控制线程，不足以描述并发性。因此，人们对其进行了改进，从而产生了基于对象的并行计算[PCM01]，建立了活动对象（Active Object）的思想以描述并发对象，这些对象都有自己的控制线程[KG97]，同时也出现了并发性的编程语言，如Java。从很多方面来看，Agent都与对象很相像，特别是活动对象：它们都封装了状态和行为，并通过消息传递来通信，都跟进程（Process）一样有自己的控制线程。但是Agent决不仅仅是对象的另一个名称，因为它是一个决策推理系统，它与对象具有不同的任务：Agent通过其目标和计划的驱动而自主运行，它能感知环境并能对其进行反应；而对象主要是为其他对象提供服务，即便是活动对象，也不具备目标驱动的行为或者叫主动性以及相关的自治性[L04]。而且，OOP没有涉及到协作、竞争、协商、计算经济等问题，而这些却是形成多Agent系统开发的基础[HX89] [SR91]。
面向Agent软件工程（Agent-Oriented Software Engineering, AOSE）是面向对象软件工程（Object-Oriented Software Engineering, OOSE）的主要支撑技术，AOSE分为需求说明、分析、设计和实现等多个阶段。其中Gaia[WG96]方法吸取面向对象开发的经验并对OOSE中的技术进行扩展后用于AOSE，借用了面向对象的分析和设计的一些术语和符号，试图采用类似设计社会组织的过程一样的方法来构建一个MAS。其分析阶段的目标是获得由一系列具有某种关系和相互作用的角色（Role）而构成的系统组织。角色用4个属性来进行定义：职责、权利、活动和协议。它和Agent间没有一对一的关系，一个Agent可以担任多种角色。扩展UML的方法：UML是面向对象建模的事实上的标准。当研究者寻求面向Agent 的建模语言和工具时，他们发现UML是一个显而易见的开始点，并因此而试图采用UML的符号来建模 MAS。其中干得比较出色的是Odell和他的同事们，他们提出了多种扩展UML符号的方法HM98。与此同时，OMG和FIPA两个组织也正在致力于开发基于 UML的符号来支持Agent 系统的建模。
由于采用传统的面向对象和知识工程的建模方法缺乏很好地表达主动性、自治性等Agent特有的属性的能力，人们提出了扩展的方法以期全面地对Agent系统进行建模并对 AOSE做出了较大的贡献。由于基于知识工程的建模很少有图形化的工具，而基于面向对象的建模大多采用了扩展UML的方法以便进行图形化表述[L04]。
2.2.3 集成基础结构基本建模工具
统一建模语言（Unified Modeling Language, UML）是面向对象软件的标准化建模语言。这是一种由Grady Booch、Jim Rumbaugh和 Ivar Jacobson综合其Booch、OMT和OOSE 方法B99[JVP00]构建的单一标记语言，用于建模开发的面向对象系统。1997年11月，OMG采用UML，并促使其成为业界标准。UML主要用于建模过程以形成图形化的文档，它能够从不同角度体现系统的动态和静态行为。
UML提供了用例图、静态图、行为图、交互图和实现图等共5类10种模型图B99[JVP00]：用例图（Use Case Diagram）从用户角度描述系统功能，并指出各功能的操作者；静态图描述了系统的静态结构，包括类图（Class Diagram）、对象图（Object Diagram）和包图（Package Diagram）；行为图描述系统的动态模型和组成对象间的交互关系，包括状态图（State Diagram）和活动图（Activity Diagram）；交互图描述对象间的动态交互关系，包括顺序图（Sequence Diagram）和协作图（Collaboration Diagram）；实现图描述系统的组件关系和物理设备的配置关系，包括组件图（Component Diagram）和配置图（Deployment Diagram）。UML并没有涵盖所有领域的不同的概念，而是提供了一种扩展机制以便定义符合各自领域的更为精确和清晰的模型。它提供了标记值、约束和版类3种方法，对模型元素的性质、规则限制及语义进行扩展。
2.2.4 集成基础结构中的建模
模型是建立系统的基础。模型与系统的关系主要体现在宏观与微观两个层面上。系统在宏观上可以理解为一个模型，系统的建立过程就是以计算机为基础的模型的建立过程；系统在微观上是由一系列模型构成的有序集合。
集成基础结构建模是在集成基础结构理论的基础上，构建高层即应用层的体系结构。因此，以体系结构为中心的集成基础结构建模有两层含义[L04]：（1）充分考虑集成基础结构提供的体系结构模式（包括Agent 群体结构以及个体结构模式），根据系统要求，选择合适的体系结构模式，并按照具体的结构模型去构建实际模型；（2）建模过程中所建立的各种模型是对系统不同视图的描述，它们的组合构成了应用层的体系结构，可以解决需求与实现之间的差距。
集成基础结构建模中采用体系结构为中心的建模步骤、面向对象的MAS建模思想、UML统一建模工具，针对集成基础结构的具体特点，构建出一系列的模型。其中，功能上包括：供应链的过程模型、数据访问模型、生产制造的流程模型、企业资源模型、决策和博弈模型等等；构建过程包括：系统需求模型、组织模型、交互模型、个体模型、代码模型、实现模型等等。构造模型的基本技术手段是抽象，同一个事物可以有不同的抽象，如何选择取决于构造它的目的。
敏捷企业的集成基础结构建模是以Agent为关键抽象机制，以产品/服务为中心通过Agent对企业经营过程进行描述，同时创建一个通用的、可重用的企业知识本体表示，通过跨行业跨企业的通信与信息处理来支持企业间的合作博弈，为集成基础结构中的敏捷供应链和基于网络的敏捷化制造创造条件。企业建模要支持敏捷制造企业工程与基础，能够通过建模分析、优化、流程重组、模型改进、转向信息系统需求分析与设计、实现等一系列连续的螺旋式的上升的过程，有助于企业业务过程的不断改进与优化，支持敏捷信息系统的快速、成功建设及评价与改进的过程[L04]。
来看敏捷供应链中采购过程建模示例：图2-3、图2-4和图2-5所示为敏捷企业的集成基础结构中企业采购过程的部分UML建模示图。其中，图2-4所示是基于面向对象的MAS建模思想的采购过程需求模型，对采购过程中的各个Agent角色模型进行分析，研究各个Agent之间的关系。图2-5所示从体系结构建模的角度来看是一个领域模型，该阶段评估了系统的体系结构，分析了各个角色的信息流向和交互协议，确定功能分块和每一个功能块主要任务。图2-6所示则是交互模型，它确定采购过程中通信的本体以及内容语言格式等，分析交互协议制定交互策略，分析每一个进程的生命周期。
敏捷制造中工作流建模示例：工作流过程具有典型的生命周期特性，根据过程的复杂性及其所含内容的不同，它可以仅仅维持几分钟，也可以长达几天甚至几个月；它在不同的周期过程具有不同属性[L04]。如同操作系统中的进程的概念，在工作流管理系统中，工作流可以被抽象为一个状态机FSM(Finite State Machine)，由于系统中各种内外部事件的发生，或者由于工作流引擎执行特定的操作，使得工作流实例状态不断改变[L04]。
DAO数据模型示例：DAO数据访问对象模式将数据访问逻辑抽象为特殊的资源，将系统资源的接口从其底层访问机制中隔离出来，通过将数据访问的调用打包，促进对于不同数据库类型和模式的数据访问。数据访问对象实际上就是包含对于所有数据访问逻辑的对象，并管理着对于数据源的连接，根据数据源的不同，数据访问对象实现了不同的访问机制。数据访问对象将数据源的物理实现细节与其用户完全分离开来，并且在底层数据源变化的时候，数据访问对象向用户提供的接口是不会变化的。这种方法使应用系统使用数据访问对象时可以适应多种数据存储介质，在这里数据访问对象就是系统组件和数据源中间的适配器。[BQ02] [BH02] [ERH03] [PCQY03]
在图2-7所示的序列图中，业务对象（Business Object）表示使用数据的客户端，一个业务对象可以用会话Bean、实体Bean或是其他Java程序来实现。数据访问对象（Data Access Object）是这种模式中的主体，它是底层数据访问的对象，并将其提供给业务对象以使得后者能够透明地访问数据源。同时业务对象也将数据的加载和存储操作移交给数据访问对象处理。数据源（Data Source）可以是一个数据库，包括关系型数据库、面向对象数据库或文件系统。传输对象（Transfer Object）指的是数据载体，数据访问对象可以使用传输对象来向用户返回数据，而数据访问对象同样可以从用户那里得到传输对象来对数据源中的数据进行更新。该模式具有良好的透明性、高可移植性、低复杂性、高可操作性。在该模式下，由于数据访问细节被数据访问对象隐藏，业务对象可以在不了解数据源实现细节的情况下访问数据，形成一种“透明”访问过程；由于业务对象与数据实现是隔离的，所以在移植过程中，仅需对数据访问对象进行一些变化即可，因此可以方便地在应用系统中添加访问对象，表现出高可移植性；由于数据访问对象可以管理所有的数据访问复杂细节简化了业务模块和其他数据客户的代码，系统整体上具有较高的可读性、高开发率，即代码具有低复杂性；该模式下系统所有数据访问操作都移交给数据访问对象，简化了相关操作BQ02ERH03。该模式的不足表现为：如果EJB容器采取容器管理的方式，那么所有对于持久性数据存储的管理都由容器负责，则意味着数据访问对象在数据用户和数据源之间添加了一个层面，增加了一些额外的设计和实现的负担BQ02ERH03。
