UML應用：業務內涵的分析抽象&表達

標籤：uml建模舉例   高煥堂   

     上一篇，架構設計的UML圖形思考 ，簡單介紹了圖形思考設計，表達設計對於架構師的重要意義，以及簡單介紹了使用整合模組化語言UML描述類以及類之間的繼承關係，這種描述還停留在寫代碼，表達的可是說是如何寫出類代碼來，接下來我們要學慣用UML表示業務的內涵，分析業務的內涵，加以抽象，將細節隱藏起來，用UML圖象表現出來。

一、系統分析       什麼是系統分析？

            大多數情況下，一看到系統分析這個字眼，我們經常迷失於其字面的意義，以為分析的對象是「系統」，這是一種常見的迷失！其實，分析的對象是系統所處的「業務領域知識」(Domain Knowledge)才是正確的。就如同電腦專家James Martin所說：
     「OOA不是要去分析實際的系統；而是用來分析人們對系統的專業認知和做法---- 從收集到的領域概念來分析出業務內涵。」
        (Object-oriented analysis is not an approach that models reality. Instead, it models the way people understand and process reality -- through the concepts they acquire.)

      系統分析的分析對象：領域知識

          所以系統分析的主要對象並非「系統」本身，而是分析專家們如何以其專業知識來敘述系統，亦即，專家心中的「業務(領域)知識」才是系統分析的主要對象。所以焦點是業務知識(Domain Knowledge) ，而不是系統。
      業務(領域)知識 = 業務內涵：

   分析系統的內涵，抽象，表達，讓開發人員懂得業務的內涵

     依據專業知識找到相應的類，相應的對象，用UML表達出來

     知識的組成元素：概念        什麼是概念：

業務(領域)概念
知識的組成要素是「概念」(Concepts)。
◎ 領域知識(Domain Knowledge)的組成要素是領域概念(Domain Concepts)。
◎ 概念有它的屬性(Attribute)，概念之間有其關係(Relationship)。
◎ 系統分析(或OOA)就是要分析領域知識裡的概念，並以UML的類別(Class)等示來表示之。

概念(Concept)是抽象的，代表一群實體，是溝通的重要媒介。

「概念是人人互相分享的。概念提供了能讓人人互相瞭解的共通詞彙。」
(Concepts are shared by others. Concepts provide the common vocabulary for communication.)

       概念理解執行個體：
概念理解舉例：

例如：「請買杯咖啡」，咖啡是個概念，具有這種概念的人，都會瞭解這句話的意思。他會憑其經驗而想到真實的咖啡。
◎ 概念代表一個群體---- 「類別」(Class)，人們藉由天賦的能力運用經驗去想到其所代表的實際東西---- 「對象」(Object)。

例如您聽到「買一隻吉他」，這「吉他」概念讓您想到經驗中的吉他，而去樂器行買一隻「真實的吉他」回家。
找出領域知識裡的概念，就是找出軟體系統的對象和類別。
◎ 例如麥當勞企業有漢堡、薯條、玩具、特餐、點餐、訂購玩具、顧客、員工、玩具商、分店等等的概念，將對應到軟體系統的類別，所以在麥當勞的軟體系統裡就會有漢堡、薯條、玩具、特餐、點餐、訂購玩具、顧客、員工、玩具商、分店等等的類別。

二、建模舉例ECS Operations and Maintenance System奔月：

『后羿從西王母處請來不死之藥，ECS Operations and Maintenance System偷吃了這顆靈藥，成仙了，身不由主飄飄然地飛往月宮之中，在那荒蕪的月宮之中度著無邊的寂寞歲月。』

雖然ECS Operations and Maintenance System可能是傳說虛構的，並非事實(Reality)，但是確確實實是我們心中的清晰概念，傳說中的主角，所以是個重要的類別，表示如下：


跟「ECS Operations and Maintenance System」具有密切關聯的概念是：月亮
和仙丹，常表達如下：


不僅上述的名詞概念而已，其攸關的動作也常是重要概念。動詞常常代表一項事件(Event)的發生，而人們常從人、事、時、地、物等去描述一個事件的發生情境。
◎ 譬如，吃仙丹就有動作(吃)的對象---仙丹，動作的主角---ECS Operations and Maintenance System，當然還有地點、時間，甚至仙丹來源等等。

三、模型與代碼的關係：

在傳統觀點裡，大多先繪製UML模型圖，然後才開始構思程式碼的撰寫，使得UML建模成為撰寫程式碼的前置工作，因此許多程式員將UML建模視為多餘的負擔。為了節省開發成本，就將省略掉UML建模的工作了。在新潮的觀點裡，UML模型與代碼是軟體系統本體的兩個觀點(或面向)，兩者沒有先後循序關聯性，而是並存和兼具於同一個人的腦海裡。這就像兩隻眼睛看到的景象並存於一個人的腦海裡一般，如此才能看到更真實的世界，也能做出更完美的軟體系統來。

UML應用：業務內涵的分析抽象&表達