論軟體的元件式開發 (轉)

論軟體的元件式開發 (轉)[@more@]

  論的式開發

吳旭東  

提綱：

1、 我所擔任的工作。
2、 開發和領域的選擇。
3、 體系結構的選擇。
4、 複用資產和複用元件的建立。
5、 通用短訊息介面SORBA。
6、 元件在各種環境下的實現。
7、 對第三方開發的支援。
8、 長期不懈地培訓。
9、 工作中的缺陷。

摘要：

　　在我所擔任的某移動短訊息增值應用系統的規劃和開發工作中，面對移動短訊息廣闊的應用領域，和眾多不同行業的，巨大的工作量。我們選擇了元件式軟體開發方式，在系統的功能、、開發和投資等方面都達到了理想的效果。

正文：

　　2000年10月我開始擔任四川某公司移動短訊息增值應用系統（簡稱SMASP）開發部的負責人，主要工作是對SMASP進行規劃並實施開發，為總經理提供SMASP開發的參考方案。SMASP的通訊服務提供商為中國聯通公司，服務內容提供商為如：計程車排程系統的計程車管理公司；電碼防偽系統的商用電碼公司；水電氣三表抄表系統的水電氣公司；移動證券系統的證券公司等，還有許多已知的和未知的對移動短訊息增值應用有潛在需求的應用領域會不段地加入到SMASP中來。SMASP首期工程應用到聯通四川公司，二期工程將推廣到山東、河南、廣東、福建、湖北等省市，並逐步推廣應用到全國聯通。由於專案處於起步階段，還沒有定型的系統模型及成功的應用模式，因此，選擇一個好的系統體系結構和開發模式就成為當務之急。

　　對領域的選擇。通常一個領域的專用資產要應用到不相關的領域是比較困難的，元件式開發的首要工作是領域工程，在這個領域內提取可被複用的系統，建立可複用資產，開發複用元件。而SMASP正好是這樣一個面對具體應用領域的，系統需要不斷升級，有著長期的持續開發需求。因此，在SMASP建設的初級階段，為SMASP建立複用資產是可行的，有回報的。

　　對元件（COM）式體系結構的選擇。SMASP已經有一部分應用是建立在/NT上了，但考慮到本系統將推廣到全國各地聯通公司，將來的和遠端操作控制以及系統整體效能的需要，我建議公司將系統後臺應用部分移植到以SUN系統為主的系統上來，這一建議得到了公司的支援。我們的服務內容提供商是各式各樣的，處在不同的行業，有不同的應用系統在執行，對UNIX、WINDOWS、WINDOWS/NT、WARE等都有應用，是一個多平臺系統。為對這樣一個多平臺、多應用、長期持續開發的系統選擇一個良好的體系結構和開發方式，將決定在將來的開發實踐中SMASP的質量、連續可用性、可升級維護性、可擴充套件性、開發工作量和投資等各項指標。經過反覆考慮，我們將整個系統劃分為各個獨立的組成物件，各物件獨立工作又相互協調來完成系統的功能，這樣各個獨立的物件就形成了系統的元件。在這些元件中，有些是SMASP內通用的，其功能定義在系統內長期穩定；也有面對不同ASP（服務內容提供商）的各式各樣的元件。這些元件的開發工作均相對獨立，互不干擾，因此可以實現系統的無代演進。

　　建立複用資產和複用元件。通常可以被複用的資產是在領域內通用性比較好的物件。透過深入的分析，我們決定建立短訊息增值應用系統平臺MIS Platform。MIS Platform本身是由多個元件構成的多層次的、元件化的體系結構，在他上面執行的ASP的各種應用也可看作MIS Platform的各個元件。MIS Platform的體系結構，各元件的詳細定義，介面定義，專化規範，大量程式碼以及各部分的文件都是潛在的可複用資產。複用資產和複用元件之間有一定區別，複用資產的範圍相對廣泛，而複用元件則更為具體，通常指可以直接嵌入到目標系統內或獨立執行以完成某一特定功能的模組或物件。並不是所有可複用資產都可以製作成複用元件的，在劃定了複用資產後還要進一步提煉，如我們在MIS Platform中建立的基本表管理元件、管理元件、通訊元件、介面元件、元件等，都具有很好的通用性。

　　通用介面的定義。在元件式開發中，由於系統是依靠預製的或獨立執行的元件協同工作來達到系統功能目標，各元件之間對資訊的就成為必然，而要使各元件之間順利交換資訊，就需要定義一個各元件都能解析的通訊介面。在我們的系統中SORBA（短訊息物件請求結構）承擔了這個角色，他的定義能為MIS Platform中所有元件識別和解析，成為元件協同工作的紐帶。SORBA的定義要考慮到獨立於平臺、獨立於、獨立於編譯系統、獨立於開發工具，因為在這個應用範圍廣大的多平臺、長期持續開發的應用系統中，我們無法保證大家都使用相同的開發工具，即使開發工具相同，也不可能保證通訊的資料結構絕對不發生改變，因此SORBA的定義的獨立性和靈活性就相當重要。

　　在各種平臺下實現元件。由於我們的系統是多平臺的，所以複用元件也需要在多平臺下實現。而目前大家討論得多的如COM、、等是以WINDOWS為平臺的，WINDOWS能夠提供給元件的實現方式為DLL或OLE技術。而我認為，這個理解是狹隘的，元件可以以多種方式在多種平臺下實現。在WINDOWS系統上除了DLL和OLE外，還可以使用靜態連線、訊息佇列等方式來實現；在UNIX上可以採用靜態連線、訊息佇列、共享等技術來實現。可以看出，在UNIX和WINDOWS（2000以上版本）上均提供了訊息佇列。MIS Platform中獨立執行的元件是透過訊息佇列聯絡起來的，在UNIX和WINDOWS下均採用這個機制，如加密元件和通訊元件之間、短訊息處理中心和通訊元件之間、通訊元件和ASP應用元件之間均透過訊息佇列通訊。而嵌入式元件如基本表、索引、SORBA介面協議等元件在UNIX下的實現採用的是靜態連線技術，在WINDOWS下采用靜態連線和DLL兩種技術。不管是嵌入元件還是獨立執行的元件，在實現的時候都應當考慮多平臺的需求，元件要獨立於開發工具、具有高度的可塑性、介面清晰可靠。

　　對第三方開發的支援。我們不能保證在整個SMASP的建設過程中始終都由我們一家承擔所有的軟體開發工作，MIS Platform提供對第三方開發的的支援是必須的。第三方開發者只要得到SORBA介面元件“DataPack.DLL”（在Windows下）或“DataPack.Lib”（在Windows下或Unix下），及相關的文件資料，他們即可訪問MIS Platform，不管MIS Platform如何升級換代，也不管MIS Platform是由什麼平臺來提供服務，我們的客戶都不必修改他們的應用系統。

　　重視培訓工作。我們的多層次元件式體系結構首先是由極少數的幾個核心開發人員所掌握的，而在SMASP的建設工作中，其他軟體人員的工作也是不能忽視的，還有人員的流動。大家在SMASP中的工作是協作性的，為了把大家都納入到整個系統的應用體系結構中，必須首先讓大家瞭解體系結構，熟練掌握可複用資產和複用構件，這樣才能使大家知道自己所做的工作在整個系統中的位置，以及怎樣使自己所做的軟體和整個系統有機地結合起來，怎樣進行元件的專化。最初，我們認為只要將構件的設計文件等資料共享給大家，我們的程式設計師就知道去學習和使用，而實際上，這些程式設計師都養成了不愛看別人軟體及文件的習慣，他們喜歡無論什麼都自己做，所以，儘管我們的SORBA介面和系統體系結構的相關文件都共享了，但大家只對SORBA介面看了一些，而對體系結構就不怎麼關心了，更談不上遵守系統體系結構。培訓工作實際上是非常重要的，沒有培訓工作，大家就很難理解整個系統的體系結構，複用資產也形同虛設。在SMASP的開發中，元件也不是一成不變的，需要升級和增加新的內容，大家對體系結構的認識應當不斷強化，因此，我們培訓工作也需要不斷的開展，持之以恆。

　　綜上所述，在元件式軟體系統開發工作中，我們首先要選定一個領域，然後確定軟體的體系結構，挖掘潛在的可複用資產，建立複用構件，持之以恆的培訓工作，讓我們的軟體人員都在充分理解系統體系結構以後隨心所欲地使用複用構件，我們的元件式開發工作就能達到滿意的效果。