PCOM模塊設計概要

引言

[ 最新進度： PCOM模塊設計-第一章.Foundation 1126 22:40

“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在其中的地位了。

從後面“”可以看到，SOA是<表4、應用對象> 第一行中Provider對象的方案框架，它給出了作爲服務的Provider對象基於服務描述、發現和交互等公共協議下的一個架構，從而讓應用組件可以不用關心不同層( 網絡層=>通訊層=>會話層=》應用層)的差別，直接在應用協議約定的Box上交互，但SOA的範疇中，並不涉及到與應用領域相關的任何事情-包括業務邏輯本身以及一個應用系統所需要的運行相關的各種支撐和支持等等。

2018-11-18 9：40

幾句閒話

這篇博文貼出來幾天，承蒙業內人士擡愛，不少人都翻看了這篇博文。在此，謝謝各位！

但，各位卻沒有留下隻字片語，這讓我多少有些失落。我知道，這些介紹，對大多數人來說，不足以讓你們瞭解，我要做的，到底是什麼。

我貼出這些博文的目的，是希望能建立和軟件開發人員的一個溝通、討論、交流和甚至合作的橋樑。因爲，我正在設計的目標系統，涉及到軟件開發的方方面面，希望能得到有有相關積累、和有興趣的專業人士的幫助和指導，來完善本模塊，直至整個系統的設計。

所以，我後續會持續修改、補充，以便能讓看到這篇博文的你們，能瞭解設計中的部分或全部含義，方便找到能交流的點和麪。

另外，爲這套系統，我之前專門建立了一個QQ羣，歡迎有興趣的加入，以方便更直接的交流和討論。

QQ羣號：568747284

名稱：aaas討論羣

另附：相關博文我也同步發佈到我的QQ空間中了。qq: 1751193850

“名詞解釋”

(說明：以下內容是從本人的另一篇博文閒話 “名詞解釋” 同步到這裏的）

一般來說，瞭解一個名詞或單詞釋義的最好方法，大多習慣“百度一下”。但如果，你的重點不是這個名詞本身的意義，而是更想完整的知道它可以起作用的地方，那“百度一下”就不夠了。

有什麼好辦法呢？我想到了“統籌”二字。

第一個念頭：一個單詞，不管它有多少層含義，但總會有個邊界。要想能提煉出它完整的作用範圍，沒有“統籌”的思想和知識恐怕是不能了。

既然已知不可能查到滿意的結果，這次，乾脆不去查，自己想。

緊接着，冒出幾個單詞：範疇、類別、分類；目錄、條目。

第二個念頭：搞清楚它們的關係，應該就是“統籌”的全部了？

那它們是什麼呢？

提煉一個單詞的完整作用範圍，首先得知道這個單詞本身應該在哪裏？

最好的方法，當然是在列舉的選項中選擇。

但問題來了：列出的選項必須是並列的概念，即：可能需要分層，還需要看看是否能去掉有交集、甚至相重或包含的。如果不在同一層上，這個層怎麼分，分幾層？不同層上(面)應該有一一對應的概念來表示不同層上的概念是等價的。一個面上需要分幾個？

第三個念頭： “範疇”和“類別”重的可能性極大。那，“類別”是 “範疇”更通用的說法？

現在，我們來決定一下。

“類別”，從字面上看，它應該是"分類"的區別，而“範疇”呢，應該是嚴格意義上要求分類的排他性了，就像一塊土地分給了張三家就不能再分給李四家一樣。

既然這樣，就可以將“類別”從中去掉。

回到最初的念頭：在最前面提出問題時，想到的“統籌”應該就是用來解決這個問題的：怎樣劃分才能同時知道單詞的釋義和單詞的作用範圍。

這個問題的解決，確實是“統籌”要做的事情了。還是那句話：要想知道怎樣做，先得知道準確的目標。

這個問題的提出，本來就給出了單詞的兩面-內涵/外延(構成一個完整的概念)，同時暗示了一個單詞可以有位於兩層上的意義-具體和抽象(一對對立統一的兩個側面)。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模塊實現概要”中補充過來的)

https://blog.csdn.net/ChuanfangChen/article/details/84334006

實現構思 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類元(Classifier)，前三種是用於應用描述或配置的類元，最後的“對象Object型”定義了應用系統中的應用組件的通用模型。

表8、PCOM服務

PCOM功能 (提供了Portable特性的基礎實現)	Profile	由不同的協議層次約定了*Box*的"服務提供者"的產生式：
		網絡層=>通訊層=>會話層=>應用層
		由不同的環境層次決定了*Box*上的“更新活動者”的產生式：
		平臺=>框架=>運行時=>容器=>活動單元
	Configration	技術特徵表達式 --表達了一個特定的技術特徵及其技術元數據 =>
		*Block( Box服務側，服務對象)***
		業務特徵表達式 --表達了一個已知的業務邏輯特徵及其元數據 => *Lable(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圖譜”中補充過來的)

https://blog.csdn.net/ChuanfangChen/article/details/84334006

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種模式類別(見http://java.sun.com/blueprints/patterns/catalog.html)。
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圖

設計目標及最佳實踐

最後，回到原點：

PCOM模塊設計的目標，就是爲構件平臺的模式提供了一個統一的外觀，使之能融入各種構件平臺作爲模式提供者。當今可用的構件開發平臺(簡稱爲“生態平臺”)，我所知道的，只有三個：J2EE、MS的DNA 和 CORBA。任何一個都可以作爲驗證PCOM模塊的實踐基礎，其中，目前最具條件的是JavaEE。

2018-11-23 9:00

應用架構的基礎設施-- PCOM模塊