基于UML的計算機軟件開發(fā)方法研究

摘要：在基于構(gòu)件的計算機軟件系統(tǒng)管理軟件開發(fā)中，利用UML圖的良好溝通特性，促進用戶、設計人員、分析人員、編碼及測試人員對所開發(fā)系統(tǒng)的統(tǒng)一認識，將UML建模貫穿整個過程。在構(gòu)件開發(fā)的過程中用UML把對單例模型的描述統(tǒng)一起來，才能達到構(gòu)件的最大程度重用的目的。但目前還沒有把兩者的優(yōu)勢充分結(jié)合起來，計算機軟件系統(tǒng)服務模型接口設計在項目開發(fā)中進行了嘗試。

關(guān)鍵詞：UML;構(gòu)件;計算機軟件

一、引言

UML（Unified Modeling Language）是業(yè)內(nèi)統(tǒng)一的建模語言，有著豐富的基于面向?qū)ο蟾拍畹哪Ｐ驮丶皥D形表示元素，還具有強大的描述能力以及廣泛的描述范圍，其為不同領域的用戶提供統(tǒng)一的交流標準。基于UML 的工作流建?？梢赃\用用戶例圖捕獲用戶需求，使用活動圖闡述業(yè)務邏輯，使用狀態(tài)圖描述工作流邏輯中實體狀態(tài)的變化。基于UML 的工作流建模具有如下優(yōu)點[1]：

1.具有定義明確的通用的語義及表示法，便于理解與溝通。工作流管理系統(tǒng)往往是大型的、結(jié)構(gòu)復雜的，需要眾多人員協(xié)同工作，因此參與者之間能否對彼此在各階段設計與開發(fā)的成果進行有效的無歧義的交流尤為重要，采用UML建模便能很好地解決這個問題。

2.具有種類繁多的概念與模型，對模型的描述更加全面。

3.對用戶友好。然而，用UML 用例圖、活動圖、狀態(tài)圖對工作流建模，無法直觀地區(qū)分業(yè)務邏輯與工作流邏輯，限制了對外部事件如事件的表達，并且不支持模型驗證與優(yōu)化。在基于UML 的建模過程中，常使用活動圖對流程的動態(tài)行為進行建模。它支持對信息流的描述，體現(xiàn)活動時序，支持對選擇路由與并發(fā)路由的描述。與基于Petri 網(wǎng)的建模方法相比，二者各有所長。

二、UML計算機軟件系統(tǒng)設計方法

（一）UML工廠建模設計

UML工廠方法模式是一種常用的創(chuàng)建型設計模式。該模式將各對象的共同屬性抽取出來，構(gòu)造一個抽象類，將各實例的特有屬性抽取出來生成不同的子類，子類繼承共同屬性對應的抽象類。它為用戶提供了創(chuàng)建對象的接口[2]。工廠模式符合并體現(xiàn)了面向?qū)ο笾蟹庋b、分派等思想。常見的工廠模式有：簡單工廠模式、工廠方法模式及抽象工廠模式三種。

工廠方法模式的優(yōu)點：

1.隱藏實例化細節(jié)

在工廠方法模式中，客戶不需要關(guān)心創(chuàng)建具體產(chǎn)品類的過程與細節(jié)（所有的實例化細節(jié)都將被隱藏），甚至無需知道具體產(chǎn)品類的類名，只要獲取需對應的工廠方法，就能創(chuàng)建所需要的具體類（即使用戶對該具體類一無所知）。

2.角色的多態(tài)性

在工廠方法模式中，無論是產(chǎn)品類還是工廠方法都具有多態(tài)性，這也是該模式又稱之為多態(tài)工廠模式的原因。由于多態(tài)性，具體產(chǎn)品類的生成細節(jié)完好的封裝在具體的生成方法內(nèi)。使用戶可以自主確定創(chuàng)建哪一種產(chǎn)品對象，然而如何創(chuàng)建這個對象的細節(jié)，則完全封裝在具體工廠內(nèi)部。

3.符合“開閉原則”

當應用系統(tǒng)引入新產(chǎn)品時，工廠方法模式可以在不影響現(xiàn)有的具體工廠與具體產(chǎn)品類，也不修改現(xiàn)有的客戶端代碼的情況下實現(xiàn)新功能的添加。只要添加一個新的具體方法和特定的產(chǎn)品類，添加新的用戶界面（如果需要的話），就能實現(xiàn)系統(tǒng)的功能擴展。對修改關(guān)閉，對擴展開放，完全符合“開閉原則”。

工廠模式的缺點：

1.增加了系統(tǒng)復雜度

對于每個產(chǎn)品，不僅要提供一個具體的產(chǎn)品類，還要提供與之對應的具體工廠類，系統(tǒng)中類的個數(shù)將成對增加，增加了系統(tǒng)的復雜性，會給系統(tǒng)帶來一些額外的開銷。

2.增加了系統(tǒng)的抽象性和理解難度。

（二）UML軟件工作流系統(tǒng)對象設計

工作流的業(yè)務過程中存在各種業(yè)務對象，即實體。以CRCC 標準運維平臺為例，平臺中有立項申請、標準制定、標準修訂、標準廢止、添加分類、數(shù)據(jù)元管理等多個流程。每個流程中都有隨著工作流一起流動的對象實體[3]。不同類型的實體之間既有共性，如需求申請?zhí)?、流程ID 等信息，又有各自特定屬性。利用工廠方法模式，首先，將不同類型的實體共性抽取出來作為一個抽象的Product;然后，再構(gòu)建對應的ConcreteProduct 實現(xiàn)類（如立項申請實體、標準制定實體等），各實現(xiàn)類繼承上述Product 抽象類，并實現(xiàn)Product 接口，或者重寫Product 中定義的虛函數(shù);再者，構(gòu)建一個抽象工廠類Factory，聲明創(chuàng)建對象的工廠方法;最后，構(gòu)建對應的產(chǎn)品工廠（如立項申請實體生產(chǎn)工廠、標準制定實體生產(chǎn)工廠等），即ConcreteFactory 類，各具體工廠返回對應的具體產(chǎn)品實體。

采用這種方案，由核心工廠類負責定義創(chuàng)建對象的公共接口，具體工廠（如立項申請工廠）繼承核心工廠類，實現(xiàn)CreateEntity 方法，用于創(chuàng)建具體類。具體類是否實例化、實例化哪個類的判斷與操作中延遲到子類完成。并且，當新的產(chǎn)品類被增加時，只需要新增一個產(chǎn)品類和一個工廠類，無需對其他子類進行修改。這意味著當一個新的業(yè)務流程被引進時，如在實現(xiàn)了立項申請功能的基礎上增加標準制定的業(yè)務流程，只需要增加一個標準制定的流程實體類和一個對應的工廠類（其中標準制定實體繼承流程實體類，標準制定工廠繼承核心工廠類并實現(xiàn)CreateEntity 方法），無需對立項申請模塊進行任何修改，就能實現(xiàn)系統(tǒng)功能的擴展，符合面向?qū)ο蟮拈_閉原則。此外，一個大型項目的實施需要多名開發(fā)人員協(xié)同工作，采用工廠方法模式，可以使功能模塊之間相對獨立，有效地避免了代碼版本沖突的問題。

（三）UML軟件系統(tǒng)過程設計

過程定義（Process Definition）： 過程定義即過程建模。本功能模塊通過對Workflow（工作流模板）和Activity（活動節(jié)點）對象的操作，成功實現(xiàn)了過程定義、過程管理的功能[4]。

過程定義——新建一個業(yè)務過程時：

首先，創(chuàng)建一個新的Workflow 對象，定義業(yè)務過程名稱、標識符等信息，每個Workflow 實例相當于一個業(yè)務過程實例（Process）的模板。

其次，為新業(yè)務過程創(chuàng)建并添加新的Activity，Activity 即是工作流程中的一個邏輯節(jié)點。在Activity 中，定義該節(jié)點是否為起始節(jié)點或者終止節(jié)點;定義該節(jié)點的當前狀態(tài)、順序操作狀態(tài)、駁回狀態(tài)，以及節(jié)點的上級節(jié)點與下級節(jié)點;并定義在當前節(jié)點上的流程操作（e.g.：順序操作、駁回操作，或者并行操作等）Process 和Task 分別作為Workflow 與Activity 的實例。當一個實例流程被發(fā)起時，系統(tǒng)根據(jù)對應的流程模板，創(chuàng)建相應的Process 和Task 實例。過程編輯——修改一個已有的業(yè)務流程時，只需要更改相對應的流程對象與它的邏輯節(jié)點對象的相關(guān)信息即可。除非要為流程設定默認任務處理角色，否則任務分配不會在過程定義中進行。

三、UML軟件系統(tǒng)模型設計

（一）單例模型設計

軟件設計中，單例模式是確保類只生成一個實例對象的一種模式。這是一種十分有用的設計模式，如果在系統(tǒng)中只能有一個對象出現(xiàn)時，單例模式可以很好地發(fā)揮作用。這種模式對于某些系統(tǒng)來說，效率是很高的，因為限制了對象生成的個數(shù)，系統(tǒng)的開銷大大降低了。一些人認為這是一種不符合設計模式思想的設計方法，認為這種用法完全沒必要，它只是增加了一些沒必要了限制，完全可以使用全局變量來代替[5]。然而經(jīng)過多年實踐的考驗，這種模式的確給編程帶來了極大的方便，在Java 的JDK 實現(xiàn)中也多處使用了單例模式來實現(xiàn)，比如：Calendar類，java.lang.Runtime 類等。

單例模式的實現(xiàn)必須滿足，只生成一個實例并且是可以全局訪問的。這就需要一種機制來保證其他的類不能創(chuàng)建該類的實例，其訪問方式也不能通過創(chuàng)建對象的方式來訪問。對于這兩點限制，可以通過創(chuàng)建一個靜態(tài)實例的方法和限制構(gòu)造方法為私有的方式來實現(xiàn)。因為每一個類中靜態(tài)變量在內(nèi)存中的實例只有一個，另外構(gòu)造方法為私有的，并且自己構(gòu)造了自己的實例，其他的類沒有權(quán)限調(diào)用其構(gòu)造方法創(chuàng)建實例，這樣就實現(xiàn)了單例模式。

單例和類中靜態(tài)實例成員經(jīng)常容易被人們混淆，下面闡述一下這兩者的區(qū)別。類中的靜態(tài)實例成員，是類的靜態(tài)成員，使用static 修飾符修飾，在類對象實例化時，靜態(tài)成員被初始化，一個類實例只對應一個靜態(tài)成員。多個類實例會對應多個不同的靜態(tài)成員。而單例只會有一個實例，其中的靜態(tài)成員也理所當然只有一個。

如果是多線程訪問單例時，需要十分小心。當兩個線程同時調(diào)用其生成實例的方法創(chuàng)建實例對象，他們都需要檢查單例是否已經(jīng)存在，并且只有一個能夠創(chuàng)建新的實例。這就要求在多并發(fā)處理時，應該使用互斥訪問的機制來創(chuàng)建實例。一個比較傳統(tǒng)的方式就是在類上使用互斥機制，來表明對象正在被實例化。Java 語言提供了多種多線程安全訪問單例的方法，對于不同的Java 版本，實現(xiàn)的方式也不一樣，從Java5.0 開始，最簡單的方式是使用enum 類型的方法，后面會對其進行說明。傳統(tǒng)的多線程安全的解決方式不需要語言結(jié)構(gòu)的支持，但是這種方式不能實現(xiàn)懶加載。

很多專家提出的雙檢鎖機制，曾經(jīng)一度被認為是解決單例多線程安全問題的最好方法，而被廣泛地使用。后來推翻了雙檢鎖策略，指出其在Java語言中是不能使用雙檢鎖來解決多線程安全問題。對于雙檢鎖的單例實現(xiàn)，本文就不贅述，下面介紹一種簡單的單例實現(xiàn)方式，是Joshua Bloch 推薦的一種方式，代碼如下：

public enum Singleton {INSTANCE;//唯一實例

public static Singleton getInstance（）{return INSTANCE;}

使用enum 來實現(xiàn)單例的好處很明顯，簡潔并且無償提供了序列化，即使是在面對復雜的序列化或者反射攻擊的時候，也能絕對防止多次實例化。

（二） UML系統(tǒng)服務框架設計

數(shù)據(jù)層地應用集成（data-level）：簡單來說，可以把各種不同的數(shù)據(jù)進行存儲并且實現(xiàn)有效的移動。一般情況下就是將信息從源數(shù)據(jù)庫中抽取出來，進行需要的格式轉(zhuǎn)換，并對目標數(shù)據(jù)庫進行更新。在對所有的數(shù)據(jù)進行集成的過程中，其最大優(yōu)勢在于付出的多少，對數(shù)據(jù)進行集成并不需要對所有的代碼進行更換，只需要對代碼進行開發(fā)：測試和重新部署。通常將數(shù)據(jù)集成看作其他集成技術(shù)與手段的基礎。

應用程序接口層地應用集成（application-interface level）：將應用程序的內(nèi)部接口暴露出來，作為集成開發(fā)者可以有效地利用這些不同的接口，對所有參與系統(tǒng)相關(guān)的業(yè)務進行處理，能夠獲取大量且簡單的信息。采用應用程序技術(shù)，開發(fā)者可以將各種不同應用程序綁定在一處，并且將所有的程序和系統(tǒng)有效地進行集成，確保這些信息能夠被應用。但是這種集成方式所獲取的信息內(nèi)容取決于應用程序所暴露接口的質(zhì)量和數(shù)量。

方法層地應用集成（method-level）：在企業(yè)的內(nèi)部業(yè)務邏輯中共享是十分重要的一個邏輯環(huán)節(jié)，目前很多企業(yè)都在選擇共享的方式進行經(jīng)營管理。而在企業(yè)發(fā)展的過程中，各類不同的共享方法層出不窮，其中包括了：分布式對象、業(yè)務處理監(jiān)控、應用服務器、框架等等。在這樣的過程中，選擇共享的模式不僅僅是創(chuàng)建某一個應用程序，而是需要兩個或多個以上的程序，才能提高應用集成的效果。當前在企業(yè)共存應用過程中，有兩種不同的方式：第一，基于同一個共享物理器上進行應用程序的創(chuàng)建。第二，在企業(yè)中可以將共享放在應用程序之中，使得在應用程序之內(nèi)的用戶變成分布對象，比如SOA。

用戶界面層地應用集成（user-interface level）：是把用戶界面作為整個應用過程中各個不同界面最為重要的公共點，其目的是通過這種方式，將各個不同的系統(tǒng)集成在一起。是一種相對原始，但十分必要的集成方法。界面集成不涉及軟件系統(tǒng)的數(shù)據(jù)和功能這兩個方面。至少能夠在用戶使用角度產(chǎn)生一個“整體”的概念。用戶界面集成的特點：技術(shù)難度不大，更多地需要考慮用戶的感觀和使用習慣。一般應用集成必須要做的集成方式。

四、服務模型創(chuàng)建與接口實現(xiàn)

1. 服務的創(chuàng)建：創(chuàng)建服務分為兩種情況，分別是對原有業(yè)務進行封裝暴露成服務，以及新建服務。而服務具體的實現(xiàn)是采用WebServices技術(shù)對業(yè)務代碼進行封裝。

2. 服務的描述：服務創(chuàng)建后，調(diào)用者如何獲得相應的服務，需要獲取服務的相關(guān)描述信息。為用戶提供詳細的接口說明書。

參? 考? 文? 獻

[1] 于麗.基于UML的面向?qū)ο蠼＜夹g(shù)研究與應用[J].信息與電腦（理論版），2015（20）：16-17.

[2] 唐貽興. 基于web的高校資產(chǎn)管理系統(tǒng)設計[J]. 安徽建筑工業(yè)學院學報（自然科學版）， 2008，（02），17-18 .

[3] 陳佳，吳安青，張建華，劉連忠.基于國際通用流程建模標準的高校儀器設備管理流程[J].實驗室研究與探索，2018，v.37;No.272（10）：297-300.

[4] 謝振超. 基于無標志物的虛擬家居布置系統(tǒng)設計與實現(xiàn)[D].重慶郵電大學，2018.

[4] 皇威，曾蘊波，謝政.基于SOA構(gòu)建集成化企業(yè)應用門戶[J].中國制造業(yè)信息化， 2010，39（05）：15-18+23.

作者單位：孫志明? ? 江蘇省淮陰商業(yè)學校