应用架构的基础设施-- PCOM模块

一水鉴天

已于 2022-03-06 20:45:32 修改

阅读量4.8k

点赞数 25

分类专栏：全渠道文章标签：架构

于 2018-11-18 09:45:57 首次发布

本文链接：https://blog.csdn.net/ChuanfangChen/article/details/84196070

版权

全渠道专栏收录该内容

9 篇文章

订阅专栏

PCOM模块设计概要

引言

[ 最新进度： PCOM模块设计-第一章.Foundation 1126 22:40

PCOM模块设计之首页 1125 15:45 ]

“PCOM”是设计的模块名，PCOM是 Portable Common Object Model(可移植组件对象模型) 的首字母简称。由于PCOM作为计算机行业的专业名词已经有它的含义，加之COM本身就是为可移植性特征而设计的，考虑要将模块名修改为COMF(Common Object Model Facility )。具体可留待将来再说。

简单的说，PCOM模块的设计目标，就是软件PLC（可编程序控制器，Programmable Logic Controller）。在后面“PCOM图谱”部分，称之为 COMPLC （组件对象模型的可编程逻辑控制器），将工业制造的自动控制模式应用为信息系统的自动化制造的基础设施。

具体起因、解释和设计目标，请参见之前的几篇文章：

PCOM与SOA

PCOM模块既然是解决互联架构的方案，一定会和SOA中的各种概念相关，PCOM本身的架构和实现都是基于SOA思想的，但它并不是一个SOA框架，PCOM的目标是一个COM的公共设施。

如何才能将设计的PCOM模块和SOA框架区别开来呢？我最后想到的办法，就是写一份PCOM模块的内容和方案提要了。

所以，为了清晰PCOM模块的范围，并且同时也是为PCOM模块的程序设计做个提要，今天起早写了< PCOM模块概要>。希望能从中能看出这个整体构成中SOA在其中的地位了。

从后面“表4、PCOM概念图”可以看到，SOA是其中<应用对象> 第一行中Provider对象的方案框架，它给出了作为服务的Provider对象基于服务描述、发现和交互等公共协议下的一个架构，从而让应用组件可以不用关心不同层( 网络层=>通讯层=>会话层=》应用层)的差别，直接在应用协议约定的Box上交互，但SOA的范畴中，并不涉及到与应用领域相关的任何事情-包括业务逻辑本身以及一个应用系统所需要的运行相关的各种支撑和支持等等。

2018-11-18 9：40

几句闲话

这篇博文贴出来几天，承蒙业内人士抬爱，不少人都翻看了这篇博文。在此，谢谢各位！

但，各位却没有留下只字片语，这让我多少有些失落。我知道，这些介绍，对大多数人来说，不足以让你们了解，我要做的，到底是什么。

我贴出这些博文的目的，是希望能建立和软件开发人员的一个沟通、讨论、交流和甚至合作的桥梁。因为，我正在设计的目标系统，涉及到软件开发的方方面面，希望能得到有有相关积累、和有兴趣的专业人士的帮助和指导，来完善本模块，直至整个系统的设计。

所以，我后续会持续修改、补充，以便能让看到这篇博文的你们，能了解设计中的部分或全部含义，方便找到能交流的点和面。

另外，为这套系统，我之前专门建立了一个QQ群，欢迎有兴趣的加入，以方便更直接的交流和讨论。

QQ群号：568747284

名称：aaas讨论群

另附：相关博文我也同步发布到我的QQ空间中了。qq: 1751193850

（当前时间 2022-03-06。几年过去了，系统设计仍在进行中。这一轮的主题是“软件智能:”。设计讨论一般在微信群：aaas开发讨论组。）

“名词解释”

(说明：以下内容是从本人的另一篇博文闲话 “名词解释” 同步到这里的）

一般来说，了解一个名词或单词释义的最好方法，大多习惯“百度一下”。但如果，你的重点不是这个名词本身的意义，而是更想完整的知道它可以起作用的地方，那“百度一下”就不够了。

有什么好办法呢？我想到了“统筹”二字。

第一个念头：一个单词，不管它有多少层含义，但总会有个边界。要想能提炼出它完整的作用范围，没有“统筹”的思想和知识恐怕是不能了。

既然已知不可能查到满意的结果，这次，干脆不去查，自己想。

紧接着，冒出几个单词：范畴、类别、分类；目录、条目。

第二个念头：搞清楚它们的关系，应该就是“统筹”的全部了？

那它们是什么呢？

提炼一个单词的完整作用范围，首先得知道这个单词本身应该在哪里？

最好的方法，当然是在列举的选项中选择。

但问题来了：列出的选项必须是并列的概念，即：可能需要分层，还需要看看是否能去掉有交集、甚至相重或包含的。如果不在同一层上，这个层怎么分，分几层？不同层上(面)应该有一一对应的概念来表示不同层上的概念是等价的。一个面上需要分几个？

第三个念头： “范畴”和“类别”重的可能性极大。那，“类别”是 “范畴”更通用的说法？

现在，我们来决定一下。

“类别”，从字面上看，它应该是"分类"的区别，而“范畴”呢，应该是严格意义上要求分类的排他性了，就像一块土地分给了张三家就不能再分给李四家一样。

既然这样，就可以将“类别”从中去掉。

回到最初的念头：在最前面提出问题时，想到的“统筹”应该就是用来解决这个问题的：怎样划分才能同时知道单词的释义和单词的作用范围。

这个问题的解决，确实是“统筹”要做的事情了。还是那句话：要想知道怎样做，先得知道准确的目标。

这个问题的提出，本来就给出了单词的两面-内涵/外延(构成一个完整的概念)，同时暗示了一个单词可以有位于两层上的意义-具体和抽象(一对对立统一的两个侧面)。4个特征词完整刻画出一个单词。

正好，上面写的时候，就已经分开了，那是第一感觉，第一感觉一般都会是对的。

现在就剩下4个单词：范畴Category、分类Classification；目录Catalog、条目Entry。

结论出来了： “范畴”和“分类”是一对，“目录”和“条目”是一对。 “范畴”和“目录”是抽象的，“分类”和“条目”是具体的。

如果存在这样一个域，能将所有术语这样来描述，就构成了一个完整的知识体系。在这个知识体系，使得它们在不断在实践中迭代，得以不断分化和演进。

这是否就是“统筹学”，我不想去求证，但我将以上的4元统称为“术语地图”，它们也是我目前正在设计的系统的根本之根本，几乎系统中的所有模块都使用了它。

20181124 12:40

PCOM模块概要 --前情提要 1118

根据前三篇，从问题发起，到一些基本考虑将想到的各个离散点组成表，作为设计的第一步。

表1、PCOM边集

Feature
Enumeration::(Literals:Term)
Feature	Lable
Charateristic	Entry

表2、PCOM 域集

PCOM
Classifier::(Items:Information)
Scheme	Model	Prototype
Domain	Mode	Style
Exprssion	Scope	Case

表3、PCOM点集

个体-信息项

(如,字段/属性/参数等)

Charateristic

特点：已知的模Mode或式Style或调用 CallAction

Entry

条目：任何一个可连接的对象

表4、PCOM概念图

逻辑图				用例图
取向	Term术语	单词Word	PCOM分支	用途
对个体特点概念的抽象	Feature	特征	静态：特征化/行为化	提供组织能力-结构成员
			动态：情景化/范畴化	提供变化能力-行为成员
对个体特点概念的具体	Lable	标签	可变：变体/分体	表示任何可运行对象
			不可变：信息项	表示任何有“确定”意义的东西

(接上表右)

组件图		部署图
分支	变体	应用对象一个完整的应用系统中的不同对象角色在系统的位置
Provider	Service	协议层次约定了服务提供的产生式：网络层=>通讯层=>会话层=>应用层 Provider::(API:SPI:Adapter)
Change	Box	环境条件决定了box的产生式：平台=>框架=>运行时=>容器=>活动单元 Activity:: (UI:Operetion:Action(发起,捕获,处理))(EventHandler:Event: Action)
Compenent	Object	一个已知的具体类型的特征表达式。该类型及其特征本身所表示的语义决定了lable的表达式的形式组件::(事务:会话:应用)
Information	Vlaue	一个已知个体的价值表达-Llable本身的语义决定了Lable表达式的不同形式. Information::(Text:Tag:RDB)

设计基础

基本点

<表2、PCOM域集集>中“类元Classifier” 是PCOM的原型，是<表4、PCOM系统图>“应用对象”列第三行的Compenent是PCOM的实例(用品/产品)；
COM和Classifier在表示基础对象基础(基类*ObjectBase)的给定的特征基范围上对齐。
对象特征基(范围)从两个根基Root Base上分支Branch：OLE属性(对象/嵌入对象/链接对象)，Domain属性(实体对象/值对象/域服务对象)；
Classifier是应用特征的表现所在(主体Master)；
特点Charateristic是一切个体可以独立具有，同时又能被其它个体感知的某个应用价值，是建立共识的基点。具体的应用特点包括(暂列，有待细化)：
- 仅声明：可移植,可插入；可识别,可实例；
- 可应用：可见,可引用,可访问,可操作，可变化/不可变

<表2、PCOM域集>中Classifier后面的Items是包括字段,构参、属性、方法、事件在内的应用程序中具有具体意义的所有可枚举项；
PCOM模块的设计目的就是使用<表1、PCOM边集>中Enumeration枚举出的枚举文字Literals来提供Classifier的特定Item的已知替换集，通过函数式(见“下一节 PCOM基础”)加上映射方法，最终得到具体的Classifier对象--它们是<表4、PCOM系统图>“应用对象”列上列出的所有应用对象，共分为4个包，12个对象。

PCOM基础

PCOM的基类是函数空间的"式"，其实例是设施。

函数式 Style_Function
正规式	组织设施
产生式	工厂设施
表达式	行为(准则)设施

PCOM的基础实现是提供COM对象特性映射为基于对象的已知特点范围的方法(“式”)设施来解决的。

对象特征范围

对象特征基(范围)从两个根基Root Base上分支Branch：OLE属性(对象/嵌入对象/链接对象)，Domain属性(实体对象/值对象/域服务对象)；

COM对象三大(封装性、多态性和继承性)的特征基类Box、Preserver和Lineage(参考上一篇《“模式”是什么》)表达了对象的三种不同的特征基：

1. Lineage血统通过枚举特征集映射出一个Classifier的模型(Domain属性=实体对象/值对象，OLE属性=对象)。
2. Box枚举边集和点集分别映射出一个Classifier的特性集(范围)和可用连接外部的点集(条目)-(Domain属性=域服务对象，OLE属性分别是嵌入对象/链接对象)
3. 血统特征和Box特征确定了一个具体的应用组件 (《表4、角色表》最右列"应用对象"的第三行组件::(事务:会话:应用) 中的应用组件。即，12个应用对象中的一个- 组件包中的应用组件；
4. 维持问题映射为一个组件包的应用组件所需要各种应用支撑和应用支持，包括设施/实用工具/中间件等等，它包括《表4、角色表》最右列"应用对象"所列出的所有12种应用对象中除应用组件以外剩余的所有其它11种应用对象，分属4个包。

说明

准确理解这些内容，至少要了解 Classifier和Feature的关系，以及函数空间、拓扑空间、领域、对象的一些基本概念；
双冒号表示"包"、包关系是类元变体Variant -应用对象在不同层(系统深度)上的角色转换。
单冒号表示"继承"。继承关系是特征范围分支-分体Branch，其顺序表达了分支的程度，或者叫血统上的分化步骤。

补充说明 1121

目标系统设计的最终目标，是要做一个信息系统的通用组态工具。设计这个PCOM模块的主要目的，是解决结构维持问题，提供COM对象的动态移植性和多参与方动态更新的信息同步。

表4右下单元格给出了PCOM模块为应用系统提供的IO : Information::(Text:Tag:RDB)，这表示了任何类元中的一个项的信息原型在3种不同存储区域中的变体。也就是说，PCOM为应用系统中的信息提供一套软件意义上的通用语义标记系统。所以，换句话说，PCOM模块提供的就是信息化的标准化设施。

最后，我使用前面“PCOM基础”中来给出PCOM模块设计目标的解释。

函数式 Style_Function (信息的标准化设施)
正规式	组织设施
产生式	工厂设施
表达式	行为(准则)设施

PCOM模块作为信息系统信息组织的标准化设施，它是信息系统的顶级组织设施，按照信息在软件中的角色和地位，从抽象/具体两个侧面给出了信息系统中各种应用对象的产生式(信息生产标准设施)和表达式(信息表达的标准设施)。

2018-11-21 8:30

(注：以下内容是从另一篇博客“PCOM模块实现概要”中补充过来的)

PCOM模块实现构思_ChuanfangChen的博客-CSDN博客

实现构思 1122

继上一篇“PCOM模块概要”之后，急着落地程序设计。到今天，总算将这些年来积累下来的知识，能一个个对号入座了。

下面几张表是对PCOM模块概要的补充和修正。

其中表5，是在“PCOM模块概要”表3的基础上进行了修改，本应该替换下来，但感觉差距比较大，更重要的是，表5是实现的基础，放在这里好像更合适。

其它表，是这次新添加的内容。

表5、PCOM点集

Term 术语
PCOM个体-COM的成员项 (如,字段/属性/参数等)	Category-对应法则	Term设施：模Mode或式Style或调用 CallAction
	Factor-定义域	确定需要某个Term的因素：Scope,Charateristic,Entry,
	Type-值域	需要具体化一个Term的所在：Case,Lable,Feature
	TaggedValue

每个“Term”唯一标识一个有着特定的“确定”意义的元素，这种“确定”意义是通过函数三要素(定义域、对应法则和值域)来描述的。

“TaggedValue ”是“KV型”(见表7)的一个实例。

PCOM就是围绕着这种一个Term的“确定”意义的解决方案。它基于COM对象具有的最根本的以下两个特征所表现的函数特性：

COM对象可移植性。COM对象的可移植性的函数特性表现为：任何特定的逻辑模型实例在任何一个应用环境中有且只有且必须有唯一的一个提供者实例和它拥有相同的函数；
COM对象自身作为应用表达的功能性特征。COM对象的功能性的函数特性表现为：一个确定的技术术语在一个应用系统中有且只有且必须有唯一的一个业务术语和它拥有相同的函数。

表6、PCOM实体

PCOM实例 (附加了Portable特性的COM对象)	Provider	服务提供的不同方式：API,SPI,Adapter
	Activity	活动的不同交互所在: UI,Operetion,Action
	Component	组件(*技术术语*)的功能划分：Transaction,Session,Application
	Information	信息价值表达(*业务术语*)的不同形式：Text,Tag,RDB
	COM

表7、PCOM模型

PCOM的逻辑模型(表示了COM除Portable特性以外的特性)	阐述Statement型	适用于表6 Information::Text	=> Exression元类
	KV型	适用于表6 Information::Tag	=> Mapping元类
	关系型Relational	适用于表6 Informatiom::RDB	=> Table元类
	对象Object型	适用于表6中其它三个包(Provider/Activity/Compent）的9个PCOM实体。是OOP(面向对象编程)中类Class的元类(MetaClass)
	COM Model

COM Model为COM对象提供了依据它们在应用系统中不同原子职能划分的PCOM实体模型。本表定义了4种COM元类，前三种是用于应用描述或配置的类元，最后的“对象Object型”定义了应用系统中的应用组件的通用模型。

表8、PCOM服务

PCOM功能 (提供了Portable特性的基础实现)	Profile	由不同的协议层次约定了*Box*的"服务提供者"的产生式：
		网络层=>通讯层=>会话层=>应用层
		由不同的环境层次决定了*Box*上的“更新活动者”的产生式：
		平台=>框架=>运行时=>容器=>活动单元
	Configration	技术特征表达式 --表达了一个特定的技术特征及其技术元数据 =>
		*Block( Box服务侧，服务对象)***
		业务特征表达式 --表达了一个已知的业务逻辑特征及其元数据 => *Label(Box客户侧,应用对象)***

	组态

提供两个级别的组态：Profile--产生式的配置文件 /Configration-表达式的装配方案。

表9、PCOM原型

PCOM标架体系(一个可编程的COM控制器COMPLC)	MachineCS	机器坐标系(scope,case,style)
	ProgrammingCS	编程坐标系(charateristic, lable, callAction)
	ArtifactsCS	工件坐标系(entry,feature,mode）
	FrameArchitecture

“PCOM原型”是由以上3套坐标系构成的一个“标架体系 FrameArchitecture”。表中的“CS”是“坐标原点Coordinate System ”的首字母（不知道专业的简称和英文是什么，暂时先用着^_^）。
“COM Model”通过提供"确定"的能在特定平面(表8中"服务提供者"或"更新活动者"的产生式初始所在的层面)上对齐3套坐标系原点影像的 COM Profile文件到其中；
PCOM模块利用本模块表5中的各种已知技术术语/业务术语及它们的对齐法则、提供的基本实现来解析Profile，通过发现、定位等，最终导航到该COM Profile文件所需的“对象型”集合：

(表7 第三行的“对象Object型”映射到具体的某个PCOM实体--表6 的前三行，分属3个包的9种PCOM实体，统称“对象型PCOM实体”)

4. 最后根据特定对象型PCOM实体在表6中提供的对象元模型，输出这个对应这个COM Profie的软件系统中各种级别对象的可配置清单、配置范围及其装配方案。

5. PCOM模块输出的应用系统原型的开发/应用实践活动，可以在通过“term”在“标架体系”中通过不断迭代、优化、分支、发展和演进。

2018-11-22 9:40

(注：以下内容是从另一篇博客“PCOM图谱”中补充过来的)

PCOM模块实现构思_ChuanfangChen的博客-CSDN博客

PCOM图谱 1123

分析

总结前面的所有设计，PCOM模块的架构最后就是 “图9”了。为方便程序模型的设计，让我们再重新标记说明一下这个表：

表9、PCOM原型
PCOM架构	3系M/P/A	9元 3套(x,y,z)
PCOM标架体系(一个可编程的COM控制器COMPLC)	MachineCS	机器坐标系(case,scope,*style*)
	ProgrammingCS	编程坐标系(charateristic, lable, *callAction*)
	ArtifactsCS	工件坐标系(entry,feature,*mode*）
	FrameArchitecture

上表只是在原表上增加了标题行，并标记了3个斜体。

3套坐标系的任意一个点(x,y,z)表示了一个COM对象的一个具体的构件元件。不同坐标系则表示了软件系统的不同横切面-工作空间层次。每个作元件在标架体系中以特有的形式关联。

“z元”(加粗斜体) 是各自空间的动态元件， 它是空间上决定一个具体COM实例的变元--定义域；
“x元”是各自空间的行为元件。
“y元”是各自空间的结构元件。

下面具体给出这张表给出的全部“确定”意义(包括使它们有意义所需要的有关设施)：

Frame：任何一个坐标系所提供的用来填充动态元件的“框”，即任何PCOM扩展都是对一个特定Frame实体的扩展。一种Frame给出了一种具体的可扩展的范围和/或一个具体扩展方案适用的范围，换句话说，Frame表示了局部更新的类别Category。即：任何与领域相关的部分都在其中；
Widget：表示一个特定的Frame实体(提供基类模型并提供基础实现，由领域专家或设计者在设计图中完成)。
在每个坐标系中的任意一个点(x,y,z)：z 恒等 Widget(x,y)；
Box：任意一个动态元素在一个特定的应用系统中表示为一个Box实例。PCOM模块给它们提供了一个统一的外观。
Pattern：模式。应用者当前所使用的系统(集成环境/开发环境/运行环境)中提供的、可直接使用的模式。顶级模式是提供了能构件应用系统平台的系统架构级别的构件模式(有这种模式能力的平台，被称为“生态平台”)。比如JavaEE中提供了13种模式类别(见J2EE[tm] Design Patterns > Design Patterns Catalog)。
Mapping：任意两个相邻的不同元件之间的映射关系/对齐方法。这里“相邻”包括空间层相邻、平面上共边或同一层的两侧等一切需要建立两个元件之间的显式关系。(隐式关系通过转换)；
Transformation：
对P系：应用程序的所在，作为应用系统的架构根级，提供与应用有关的不同级别(如，应用框架/应用组件）的对象模型，同时提供需要的编程空间。PCOM模块中的P集元件(简称“应用元件”)表示了应用系统架构的元构件。一个生态平台提供的P集中， P(x,y,z)上：

一个z元件是真实意义上的应用程序，简称为“实元件”；
对任何一个z： Pz 恒等 Pattern(Mz,Wz)；
整个P系：原点恒等 Mapping(Box，Block,Lable)。意思是：一个应用系统的编程目标，就是要为在特定目标运行环境下用来表示需求的那些确定的Box类别的具体Lable填充实现/表达它的程序块.

9. 对M、A系：模式Pattern ，M/W(x,y,z)，是已知的架构模式： Schema(应用元件的ode/Style)，它表达了P系上的一个实元件(z元件) 在机器坐标系/工件坐标系的 z轴上的影像。同时：

x表示z的范围(结构元件)；
y表示z的情况(情景元件)；

关于设施：

设施是一个独立功能性组织为公民的不同公共目的而提供的必要的公共手段/公共设施。
在PCOM模块中，公民就是元件，各元件是彼此独立的。模块提供了基础的元设施(标记体系和三个坐标系)，并在其上提供了一套基础的公共设施，上面列出的Frame、Widge、Mapping、Transformation等。
其中Mapping 和 Transformation 提供了面向动态元件的公共基础手段-是动态元件起作用的方法；
一个生态平台中，将提供除Transformation以外的全部实现，而任何应用系统都可以直接使用Mappng来建立元件之间的动态特性。

PCOM构成

根据以上分析，给出PCOM的完整构成：

3种系、9种元件；
9种图：见“表10、PCOM图谱”
1个类：元件

表10、PCOM图谱

表10、PCOM图谱
设施	图
Box	部署图
Block	组件图
Lable	逻辑图
Widget	小部件图
Frame	框图
Pattern	模式
Transformation	转换
Mapping	映射
Schema	配置Profile图