類圖的概念
一、概述
類圖（Class Diagram）是描述類、介面、協作以及它們之間關係的圖，用來顯示系統中各個類的靜態結構。類圖是定義其他圖的基礎，在類圖基礎上，可以使用狀態圖、協作圖、元件圖和配置圖等進一步描述系統其他方面的特性。
類圖包括7個元素：類（Class）、介面（Interface）、協作（collaboration）、依賴關係（Dependency）、泛化關係（Generalization）、關聯關係（Association）以及實現關係（Realization）。
二、類
類定義了一組有著狀態和行為的物件。其中，屬性和關聯用來描述狀態。屬性通常用沒有身份的資料值表示，如數字和字串。關聯則用有身份的物件之間的關係表示。行為由操作來描述，方法是操作的實現。物件的生命期則由附加給類的狀態機來描述。
1、 名稱：類的名稱是每個類中所必有的構成元素。
2、 屬性（Attribute）
（1） 可見性：類中屬性的可見性主要包括公有（public）、私有（Private）和受保護（Protected）。在UML中，公有型別的用“+”表達，私有型別用“-”表達，而受保護型別則用“#”表達。UML的類中不存在預設的可見性，如果沒有顯示任何一種符號，就表示沒有定義該屬性的可見性。
（2） 屬性名：按照UML的約定，單字屬性名小寫。如果屬性名包含多個單詞，這些單詞要合併，且除了第一個單詞外其餘單詞的首字母要大寫。
（3） 屬性字串。屬性字串用來指定關於屬性的其他資訊，例如某個屬性應該是永久的。任何希望新增在屬性定義字串值但又沒有合適地方可以加入的規則，都可以放在屬性字串裡。
（4） 類屬性。屬性也可以作為一個類屬屬性來定義，這就意味著此屬性被該類的所有物件共享。在類圖中，類屬性帶有一條下劃線。
3、 操作。類的操作是對類的物件所能做的事務的抽象，相當於一個服務的實現。
4、 職責：在操作部分下面的區域，可以用來說明類的職責。職責是類或其他元素的契約或義務。類的職責是是自由形式的文字，寫一個短語，一個句子等。在UML中，把職責列在類圖底部的分隔欄中。
5、 約束。說明類的職責是消除二義性的一種非形式化的方法，形式化的方法是使用約束。約束指定了該類所要滿足的一個或多個規則。在UML中，約束是用一個花括號括起來的自由文字。
三、介面
介面包含操作但不包含屬性，且它沒有對外界可見的關聯。
四、類之間的關係
類之間的關係最常見的有四種：依賴關係、泛化關係、管理關係、實現關係。
1、 依賴關係（Dependency）
依賴表示兩個或多個模型元素之間語義上的關係。它表示了這樣一種情形，對於一個元素（提供者）的某些改變可能會影響或提供訊息給其他元素（客戶），即客戶以某種形式依賴於其他類元。根據這個定義，關聯、實現和泛化都是依賴關係，但是它們有更特別的語義。在UML中，依賴用一個從客戶指向提供者的虛箭頭表示，用一個構造型的關鍵字來區分它的種類。
UML定義了4種基本依賴型別，分別是使用（Usage）依賴、抽象（Abstraction）依賴、授權（Permission）依賴和繫結（Binding）依賴。
（1）、使用依賴。使用依賴都是非常直接的，通常表示客戶使用提供者提供的服務以實現它的行為。以下列出了5種使用依賴關係.
（2）、抽象依賴。抽象依賴用來表示客戶與提供者之間的關係，依賴於在不同抽象層次上的事物。
（3）、授權依賴。授權依賴表示一個事物訪問另一個事物的能力。提供者透過規定客戶的許可權，可以控制和限制對其內容訪問的方法。
（4）、繫結依賴。繫結依賴是較高階的依賴型別，用於繫結模板以建立新的模型元素。
2、泛化關係（Generalization）
泛化關係是一種存在於一般元素和特殊元素之間的分類關係，它只使用在型別上，而不是例項上。在類中，一般元素被稱為超類或父類，而特殊元素被稱為子類。在UML中，泛化關係用一條從子類指向父類的空心三角箭頭表示
3、關聯關係（Association）
關聯關係是一種結構關係，它指明一個事物的物件與另一個事物的物件之間的聯絡。也就是說，關聯描述了系統中物件或例項之間的離散連線。在UML中，關聯關係用一條連線兩個類的實線表示
關聯關係有6種對應的修飾，它們分別是：名稱、角色、多重性、聚合、組合和導航性。
（1）、名稱（Name）。名稱用來描述關聯的性質，通常使用一個動詞或動詞短語來命名關聯。名稱以字首或字尾一個指引閱讀的方向指示符以消除名稱含義上可能存在的歧義，方向指示符用一個實心的三角形箭頭表示。
（2）、角色（Role）。角色是關聯關係中一個類對另一個類所表現出來的職責。角色名稱是名詞或名詞短語，以解釋物件是如何參與關聯的。
（3）、多重性（Multiplicity）。約束是UML三大擴充套件機制之一，多重性是其中使用最廣泛的一種約束。關聯的多重性是指有多少物件可以參與該關聯，多重性可以用來表達一個取值範圍、特定值、無限定的範圍或一組離散值。
（4）、聚合（Aggregation）。聚合關係表示整體和部分關係的關聯。聚合關係描述了“has a”的關係。在UML中聚合關係用帶空心的實線來表示，其中頭部指向整體。
（5）、組合關係(Composition)。組合關係是聚合關係中的一種特殊情況，是更強形式的聚合，又被稱為強聚合。在組合中，成員物件的生命週期取決於聚合的生命週期，聚合不僅控制著成員物件的行為，而且控制著成員物件的建立和析構。在UML中，組合關係用帶實心菱頭的實線來表示，其中頭部指向整體。
（6）、導航性(Nevigation)。導航性描述的是一個物件透過鏈（關聯的例項）進行導航訪問另一個物件，即對一個關聯端點設定導航屬性意味著本端的物件可以被另一端的物件訪問。可以在關聯關係上加箭頭表示導航方向。只在一個方向上可以導航的關聯稱為單向關聯(Unidirection Association),用一條帶箭頭的實線來表示。在兩個方向上都可以導航的關聯稱為雙向關聯(Bidirection Association),用一條沒有箭頭的實線來表示。另外使用導航性可以降低類之間的耦合度，在也是好的面向物件分析與設計的目標之一。
4、實現關係（Realization）
實現是規格說明和其實現之間的關係，它將一種模型元素與另一種模型元素連線起來，比如類和介面。
泛化和實現關係都可以將一般描述與具體描述聯絡起來。泛化將同一語義層上的元素連線起來，並且通常在同一模型內。實現關係則將不同語義層內的元素連線起來，通常建立在不同的模型內。
實現關係通常在兩種情況下被使用：在介面與實現該介面的類之間；在用例以及實現該用例的協作之間。
在UML中，實現關係的符號與泛化關係的符號類似，用一條帶指向介面的空心三角箭頭的虛線表示。下圖所示的是實現關係的一個示例，描述的是Keyboard保證自己的部分行為可以實現Typewriter的行為
實現關係還有一種省略的表示方法，即介面表示為一個小圓圈，並和實現介面的類用一條線段連線，如圖
類圖建模技術
一、對簡單協作建模
類不是單獨存在的，而是要與其他類協同工作。協作是動態互動在靜態檢視上的對映，協作的靜態結構透過類圖來描述。
對協作建模要遵循如下策略
1、識別要建模的機制。一個機制描述了正在建模的部分系統的一些功能和行為，這些功能和行為是由類、介面和一些其他元素的相互作用產生的。
2、對每種機制，識別參與協作的類、介面和其他協作，並識別這些事物之間的關係。
3、用協作的指令碼檢測事物，透過這種方法可以發現模型中被遺漏的部分和有明顯語義錯誤的部分。
4、把元素和它們的內容聚合在一起。對於類，首先平衡好職責，隨著時間的推移，將它們轉換成具有的屬性和操作。
二、對邏輯資料庫模式建模
通用的邏輯資料庫建模工具是“實體-關係（E-R）”圖，傳統的E-R圖只針對資料，而UML的類圖還允許對行為建模。在物理資料庫中，類圖一般要把邏輯操作轉化成觸發器或儲存過程。
對模式建模要遵循如下策略：
1、在模型中識別的類，其狀態必須超過其應用系統的生命週期。
2、建立包含這些類的類圖，並把它們標記為永久（persistent）。對於特定的資料庫細節，可以定義自己的標記值集合。
3、展開這些類的結構性細節，即詳細描述屬性的細節，並注重於關聯和構造類的基數。
4、觀察系統中的公共模式（如迴圈關聯、一對一關聯和n元關聯），它們常常造成物理資料庫設計的複雜化。
5、考慮這些類的行為，擴充套件對資料庫儲存和資料完整性來說重要的操作。一般情況下，與物件集的操作相關的業務規則應該被封裝在永久類的上一層。
三、正向工程和逆向工程
1、正向工程（Forward Engineering）
正向工程是透過實現語言的對映把模型轉換為程式碼的過程。由於UML中描述的模型在語義上比當前的任何面嚮物件語言要豐富，所以正向工程會導致一定資訊的損失，這也是需要模型的原因。
對類圖進行正向工程，要遵循如下的策略
(1)、識別對映到所選擇的實現語言的規則
(2)、根據所選擇的語言的語義，可能會限定一些對UML特性的使用
(3)、用標記值詳細描述目標語言，若需要精確的控制，該操作可以在單個類的層次上進行，也可以在較高的層次(如協作或包)上進行
(4)、使用工具對模型進行正向工程
2、逆向工程（Reverse Engineering）
逆向工程是透過從特定實現語言的對映，把程式碼轉換為模型的過程。逆向工程會導致大量的冗餘資訊同時逆向工程又是不完整的。
對類圖進行逆向工程，要遵循如下的策略
(1)、識別從實現語言或所選的語言進行對映的規則
(2)、使用工具，指向要進行逆向工程的程式碼，用工具生成新的模型或修改以前進行正向工程時已有的模型。
(3)、使用工具，透過查詢模型建立類圖。
物件圖
物件圖(Object Diagram)描述的是參與互動的各個物件在互動過程中某一時刻的狀態。物件圖可以被看作是類圖在某一時刻的例項。
在UML中，物件圖使用的是與類圖相同的符號和關係，因為物件就是類的例項。下圖顯示了物件圖的模型。其中節點可以是物件也可以是類，連線表示物件之間的關係：
二、類圖和物件圖的區別
類圖
類具有3個分欄：名稱、屬性和操作 物件只有兩個分欄：名稱和屬性 在類的名稱分欄中只有類名 物件的名稱形式為“物件名：類名”，匿名物件的名稱形式為“：類名” 類的屬性分欄定義了所有屬性的特徵 物件則只定義了屬性的當前值，以便用於測試用例或例子中 類中列出了操作 物件圖中不包括操作，因為對於同屬於同一個類的物件而言，其操作是相同的 類使用關聯連線，關聯使用名稱、角色、多重性以及約束等特徵定義。類代表的是對物件的分類所以必須說明可以參與關聯的物件的數目 物件使用鏈連線、鏈擁有名稱、角色，但是沒有多重性。物件代表的是單獨的實體，所有的鏈都是一對一的，因此不涉及到多重性。物件圖建模技術
一、對物件結構建模
對系統的設計檢視建模時，可以使用一組類圖完整地描述抽象的語義以及它們之間的關係。但是使用物件圖不能完整地描述系統的物件結構。對於一個個體類，可能存在多個例項，對於相互之間存在關係的一組類，物件間可有的配置可能是相當多的。所以，在使用物件圖時，只能在一定意義上顯示感興趣的具體或原型物件集。這就是對物件結構建模，即一個物件圖顯示了某一時刻相互聯絡的一組物件。
對物件結構建模，要遵循以下策略：
(1)、識別將要使用的建模機制。該機制描述了一些正在建模的部分系統的功能和行為，它們由類、介面和其他元素的互動而產生。
(2)、對於各種機制，識別參與協作的類、介面和其他元素，同時也要識別這些事物之間的關係。
(3)、考慮貫穿這個機制的指令碼。凍結某一時刻的指令碼，並且彙報每個參與這個機制的物件。
(4)、按照需要顯示出每個物件的狀態和屬性值，以便理解指令碼。
(5)、顯示出物件之間的鏈，以描述物件之間關聯的例項。
二、正向工程和逆向工程
1、正向工程
對物件圖工程進行正向工程在理論上是可行的，但是在實際上卻是受限制的。
2、逆向工程
對物件圖進行逆向工程是非常困難的。當對系統進行除錯時，總要依靠開發人員或工具來進行。
類圖的概念
一、概述
類圖（Class Diagram）是描述類、介面、協作以及它們之間關係的圖，用來顯示系統中各個類的靜態結構。類圖是定義其他圖的基礎，在類圖基礎上，可以使用狀態圖、協作圖、元件圖和配置圖等進一步描述系統其他方面的特性。
類圖包括7個元素：類（Class）、介面（Interface）、協作（collaboration）、依賴關係（Dependency）、泛化關係（Generalization）、關聯關係（Association）以及實現關係（Realization）。
二、類
類定義了一組有著狀態和行為的物件。其中，屬性和關聯用來描述狀態。屬性通常用沒有身份的資料值表示，如數字和字串。關聯則用有身份的物件之間的關係表示。行為由操作來描述，方法是操作的實現。物件的生命期則由附加給類的狀態機來描述。
1、 名稱：類的名稱是每個類中所必有的構成元素。
2、 屬性（Attribute）
（1） 可見性：類中屬性的可見性主要包括公有（public）、私有（Private）和受保護（Protected）。在UML中，公有型別的用“+”表達，私有型別用“-”表達，而受保護型別則用“#”表達。UML的類中不存在預設的可見性，如果沒有顯示任何一種符號，就表示沒有定義該屬性的可見性。
（2） 屬性名：按照UML的約定，單字屬性名小寫。如果屬性名包含多個單詞，這些單詞要合併，且除了第一個單詞外其餘單詞的首字母要大寫。
（3） 屬性字串。屬性字串用來指定關於屬性的其他資訊，例如某個屬性應該是永久的。任何希望新增在屬性定義字串值但又沒有合適地方可以加入的規則，都可以放在屬性字串裡。
（4） 類屬性。屬性也可以作為一個類屬屬性來定義，這就意味著此屬性被該類的所有物件共享。在類圖中，類屬性帶有一條下劃線。
3、 操作。類的操作是對類的物件所能做的事務的抽象，相當於一個服務的實現。
4、 職責：在操作部分下面的區域，可以用來說明類的職責。職責是類或其他元素的契約或義務。類的職責是是自由形式的文字，寫一個短語，一個句子等。在UML中，把職責列在類圖底部的分隔欄中。
5、 約束。說明類的職責是消除二義性的一種非形式化的方法，形式化的方法是使用約束。約束指定了該類所要滿足的一個或多個規則。在UML中，約束是用一個花括號括起來的自由文字。
三、介面
介面包含操作但不包含屬性，且它沒有對外界可見的關聯。
四、類之間的關係
類之間的關係最常見的有四種：依賴關係、泛化關係、管理關係、實現關係。
1、 依賴關係（Dependency）
依賴表示兩個或多個模型元素之間語義上的關係。它表示了這樣一種情形，對於一個元素（提供者）的某些改變可能會影響或提供訊息給其他元素（客戶），即客戶以某種形式依賴於其他類元。根據這個定義，關聯、實現和泛化都是依賴關係，但是它們有更特別的語義。在UML中，依賴用一個從客戶指向提供者的虛箭頭表示，用一個構造型的關鍵字來區分它的種類。
UML定義了4種基本依賴型別，分別是使用（Usage）依賴、抽象（Abstraction）依賴、授權（Permission）依賴和繫結（Binding）依賴。
（1）、使用依賴。使用依賴都是非常直接的，通常表示客戶使用提供者提供的服務以實現它的行為。以下列出了5種使用依賴關係.
（2）、抽象依賴。抽象依賴用來表示客戶與提供者之間的關係，依賴於在不同抽象層次上的事物。
（3）、授權依賴。授權依賴表示一個事物訪問另一個事物的能力。提供者透過規定客戶的許可權，可以控制和限制對其內容訪問的方法。
（4）、繫結依賴。繫結依賴是較高階的依賴型別，用於繫結模板以建立新的模型元素。
2、泛化關係（Generalization）
泛化關係是一種存在於一般元素和特殊元素之間的分類關係，它只使用在型別上，而不是例項上。在類中，一般元素被稱為超類或父類，而特殊元素被稱為子類。在UML中，泛化關係用一條從子類指向父類的空心三角箭頭表示
3、關聯關係（Association）
關聯關係是一種結構關係，它指明一個事物的物件與另一個事物的物件之間的聯絡。也就是說，關聯描述了系統中物件或例項之間的離散連線。在UML中，關聯關係用一條連線兩個類的實線表示
關聯關係有6種對應的修飾，它們分別是：名稱、角色、多重性、聚合、組合和導航性。
（1）、名稱（Name）。名稱用來描述關聯的性質，通常使用一個動詞或動詞短語來命名關聯。名稱以字首或字尾一個指引閱讀的方向指示符以消除名稱含義上可能存在的歧義，方向指示符用一個實心的三角形箭頭表示。
（2）、角色（Role）。角色是關聯關係中一個類對另一個類所表現出來的職責。角色名稱是名詞或名詞短語，以解釋物件是如何參與關聯的。
（3）、多重性（Multiplicity）。約束是UML三大擴充套件機制之一，多重性是其中使用最廣泛的一種約束。關聯的多重性是指有多少物件可以參與該關聯，多重性可以用來表達一個取值範圍、特定值、無限定的範圍或一組離散值。
（4）、聚合（Aggregation）。聚合關係表示整體和部分關係的關聯。聚合關係描述了“has a”的關係。在UML中聚合關係用帶空心的實線來表示，其中頭部指向整體。
（5）、組合關係(Composition)。組合關係是聚合關係中的一種特殊情況，是更強形式的聚合，又被稱為強聚合。在組合中，成員物件的生命週期取決於聚合的生命週期，聚合不僅控制著成員物件的行為，而且控制著成員物件的建立和析構。在UML中，組合關係用帶實心菱頭的實線來表示，其中頭部指向整體。
（6）、導航性(Nevigation)。導航性描述的是一個物件透過鏈（關聯的例項）進行導航訪問另一個物件，即對一個關聯端點設定導航屬性意味著本端的物件可以被另一端的物件訪問。可以在關聯關係上加箭頭表示導航方向。只在一個方向上可以導航的關聯稱為單向關聯(Unidirection Association),用一條帶箭頭的實線來表示。在兩個方向上都可以導航的關聯稱為雙向關聯(Bidirection Association),用一條沒有箭頭的實線來表示。另外使用導航性可以降低類之間的耦合度，在也是好的面向物件分析與設計的目標之一。
4、實現關係（Realization）
實現是規格說明和其實現之間的關係，它將一種模型元素與另一種模型元素連線起來，比如類和介面。
泛化和實現關係都可以將一般描述與具體描述聯絡起來。泛化將同一語義層上的元素連線起來，並且通常在同一模型內。實現關係則將不同語義層內的元素連線起來，通常建立在不同的模型內。
實現關係通常在兩種情況下被使用：在介面與實現該介面的類之間；在用例以及實現該用例的協作之間。
在UML中，實現關係的符號與泛化關係的符號類似，用一條帶指向介面的空心三角箭頭的虛線表示。下圖所示的是實現關係的一個示例，描述的是Keyboard保證自己的部分行為可以實現Typewriter的行為
實現關係還有一種省略的表示方法，即介面表示為一個小圓圈，並和實現介面的類用一條線段連線，如圖
類圖建模技術
一、對簡單協作建模
類不是單獨存在的，而是要與其他類協同工作。協作是動態互動在靜態檢視上的對映，協作的靜態結構透過類圖來描述。
對協作建模要遵循如下策略
1、識別要建模的機制。一個機制描述了正在建模的部分系統的一些功能和行為，這些功能和行為是由類、介面和一些其他元素的相互作用產生的。
2、對每種機制，識別參與協作的類、介面和其他協作，並識別這些事物之間的關係。
3、用協作的指令碼檢測事物，透過這種方法可以發現模型中被遺漏的部分和有明顯語義錯誤的部分。
4、把元素和它們的內容聚合在一起。對於類，首先平衡好職責，隨著時間的推移，將它們轉換成具有的屬性和操作。
二、對邏輯資料庫模式建模
通用的邏輯資料庫建模工具是“實體-關係（E-R）”圖，傳統的E-R圖只針對資料，而UML的類圖還允許對行為建模。在物理資料庫中，類圖一般要把邏輯操作轉化成觸發器或儲存過程。
對模式建模要遵循如下策略：
1、在模型中識別的類，其狀態必須超過其應用系統的生命週期。
2、建立包含這些類的類圖，並把它們標記為永久（persistent）。對於特定的資料庫細節，可以定義自己的標記值集合。
3、展開這些類的結構性細節，即詳細描述屬性的細節，並注重於關聯和構造類的基數。
4、觀察系統中的公共模式（如迴圈關聯、一對一關聯和n元關聯），它們常常造成物理資料庫設計的複雜化。
5、考慮這些類的行為，擴充套件對資料庫儲存和資料完整性來說重要的操作。一般情況下，與物件集的操作相關的業務規則應該被封裝在永久類的上一層。
三、正向工程和逆向工程
1、正向工程（Forward Engineering）
正向工程是透過實現語言的對映把模型轉換為程式碼的過程。由於UML中描述的模型在語義上比當前的任何面嚮物件語言要豐富，所以正向工程會導致一定資訊的損失，這也是需要模型的原因。
對類圖進行正向工程，要遵循如下的策略
(1)、識別對映到所選擇的實現語言的規則
(2)、根據所選擇的語言的語義，可能會限定一些對UML特性的使用
(3)、用標記值詳細描述目標語言，若需要精確的控制，該操作可以在單個類的層次上進行，也可以在較高的層次(如協作或包)上進行
(4)、使用工具對模型進行正向工程
2、逆向工程（Reverse Engineering）
逆向工程是透過從特定實現語言的對映，把程式碼轉換為模型的過程。逆向工程會導致大量的冗餘資訊同時逆向工程又是不完整的。
對類圖進行逆向工程，要遵循如下的策略
(1)、識別從實現語言或所選的語言進行對映的規則
(2)、使用工具，指向要進行逆向工程的程式碼，用工具生成新的模型或修改以前進行正向工程時已有的模型。
(3)、使用工具，透過查詢模型建立類圖。
物件圖
一、概述
物件圖(Object Diagram)描述的是參與互動的各個物件在互動過程中某一時刻的狀態。物件圖可以被看作是類圖在某一時刻的例項。
在UML中，物件圖使用的是與類圖相同的符號和關係，因為物件就是類的例項。下圖顯示了物件圖的模型。其中節點可以是物件也可以是類，連線表示物件之間的關係：
二、類圖和物件圖的區別
類圖
物件圖
類具有3個分欄：名稱、屬性和操作 物件只有兩個分欄：名稱和屬性 在類的名稱分欄中只有類名 物件的名稱形式為“物件名：類名”，匿名物件的名稱形式為“：類名” 類的屬性分欄定義了所有屬性的特徵 物件則只定義了屬性的當前值，以便用於測試用例或例子中 類中列出了操作 物件圖中不包括操作，因為對於同屬於同一個類的物件而言，其操作是相同的 類使用關聯連線，關聯使用名稱、角色、多重性以及約束等特徵定義。類代表的是對物件的分類所以必須說明可以參與關聯的物件的數目 物件使用鏈連線、鏈擁有名稱、角色，但是沒有多重性。物件代表的是單獨的實體，所有的鏈都是一對一的，因此不涉及到多重性。物件圖建模技術
一、對物件結構建模
對系統的設計檢視建模時，可以使用一組類圖完整地描述抽象的語義以及它們之間的關係。但是使用物件圖不能完整地描述系統的物件結構。對於一個個體類，可能存在多個例項，對於相互之間存在關係的一組類，物件間可有的配置可能是相當多的。所以，在使用物件圖時，只能在一定意義上顯示感興趣的具體或原型物件集。這就是對物件結構建模，即一個物件圖顯示了某一時刻相互聯絡的一組物件。
對物件結構建模，要遵循以下策略：
(1)、識別將要使用的建模機制。該機制描述了一些正在建模的部分系統的功能和行為，它們由類、介面和其他元素的互動而產生。
(2)、對於各種機制，識別參與協作的類、介面和其他元素，同時也要識別這些事物之間的關係。
(3)、考慮貫穿這個機制的指令碼。凍結某一時刻的指令碼，並且彙報每個參與這個機制的物件。
(4)、按照需要顯示出每個物件的狀態和屬性值，以便理解指令碼。
(5)、顯示出物件之間的鏈，以描述物件之間關聯的例項。
二、正向工程和逆向工程
1、正向工程
對物件圖工程進行正向工程在理論上是可行的，但是在實際上卻是受限制的。
2、逆向工程
對物件圖進行逆向工程是非常困難的。當對系統進行除錯時，總要依靠開發人員或工具來進行。