音樂家若要將腦中的旋律化成一首動聽的樂曲，可以寫在樂譜上，讓演奏家按照樂譜進行表演；建築師腦中的大樓設計概念，可以透過建築藍圖來呈現，然後按圖施工建造；那麼軟體工程師在撰寫程式碼之前，是不是也應該在確認需求後，規劃整個系統設計藍圖，然後再開始動手寫出程式碼呢？

這就是UML（Unified Modeling Language，統一模組化語言）創始人之一的Ivar Jacobson博士所倡導「軟體工程（Software Engineering）」要達成的目標！讓軟體開發不再只是天才設計師發揮個人獨一無二程式天分的產物，而是有一套方法論（Methodology）、規範程序（Process）與表示法（Notation），為一個系統化及統一化，易於溝通可以再用的過程。UML所要談論的內容，則是跟軟體工程的表示法有關，與程序本身沒有直接關係（Process Independent）。

程式設計師可以用各式各樣的開發程序來生產軟體系統，例如常見的瀑布模式、雛型模式及螺旋模式，但是在模型與文件表達方面，則可遵循UML的標準。目前在UML基礎上開發出來的工具有Rational Rose、Microsoft Visio與Borland Together等。Ivar則是Rational的創辦人之一，身體力行地依照UML的要求，一步一步建構出Rational，而現在Rational已經是一套涵蓋有：問題與需求分析管理、基本元件和開發測試、功能、可靠性及性能測試的完整開發工具，並且廣被國際軟體業界所採用。雖然Rational已經發展到這樣的規模，Ivar仍然要繼續推動下一世代的軟體開發流程：「智慧型代理人程式（Intelligent Agents）」，持續為引領軟體開發領域的創新而努力。

Ivar是瑞典人，1967年當他還在易利信（Ericsson）負責重要的電信交換機軟體開發工作，即開始著手利用圖像視覺來表達軟體開發流程中的每樣零件，將流程中每個軟體零件定義出代表意義的圖示後，有利於程式人員之間的軟體分析資料交換與溝通。漸漸地，這樣的一套表示法變成了SDL（Specification Description Language，規格描述語言），可以很清楚地表達整個流程以取代文字上的描述，最後SDL成了電信產業中的標準。

但SDL的成功，卻沒有讓Ivar停止開創的腳步，反而激勵Ivar 持續創造新的軟體開發流程概念，例如使用案例（Use Case）的方法可將軟體需求落實在圖形視覺的表現中。一直到了1987年，Ivar 選擇離開易利信，自己創辦了Objectory AB公司，繼續發展軟體開發流程的規範。在1992年則發展出OOSE（Object Oriented Software Engineering，物件導向軟體工程）。1995年，Objectory 公司併入Rational 軟體公司，他開始跟Grady Booch 與James Rumbaugh 在1997年創立了OMG（Object Management Group，物件管理群體）組織，期望能將軟體開發的描述語言，利用物件導向的方法加以標準化，同時也對軟體開發分析方法及程序加以統一，嚴謹地落實軟體工程所希望達成的目標。基於這個理念，他們共同發展並定義出UML，後來又提出了RUP（Rational Unified Process，Rational 統一程序），作為Rational建構軟體開發模型的統一標準程序。

2003年，IBM購併Rational軟體公司，Ivar選擇不再繼續加入IBM公司服務，但仍然擔任IBM的執行技術顧問角色，直到2004年4月為止。直到現在，Ivar馬不停蹄地在美國、英國、新加坡、韓國等地區分別成立自己的公司，希望能提供當地的軟體業者，更加好用及便利的軟體開發與管理解決方案。

對於UML，Ivar 認為軟體的設計與規劃，純用文字表現顯得太複雜，如果可以透過統一的塑模（Modeling）方式來撰寫，建立標準且可以廣泛應用在全世界的繪製軟體藍圖與工具軟體，使得軟體開發工作團隊有所依循。建立這些軟體模型，可以將系統規劃設計圖像化（Visualization），將系統架構及作業元素規格化（Specification）。在系統發展的過程中，我們會去定義系統規格並且依照需求的變動修改規格與流程，這些記錄都需要各式文件來留存，重點還是必須時時保持這些文件的更新維護，以跟實際現況符合，所以最好是能夠利用UML工具，一旦變更系統規劃，只要在UML文件上改變後，就自動更新好文件，並主動告知給工作團隊的成員。

提出軟體開發的需求，並不是偶然觸發的。在實作程式碼撰寫之前，從需求確認、系統分析與設計開始，盡可能地把各種可能的環節設想清楚，並且確認發展程序，換句話說就是建立軟體系統的設計藍圖，如此一來才能免於一邊寫程式一邊又修改的狀況，反而增加系統內部的流程負擔與日後維護上的困難。

Ivar說明UML所包含的內容是軟體發展方法論的表示法（Notation），並非是程序（Process）。後來Ivar 則就程序部份發展出RUP（Rational Unified Process）。UML可以接受各種型式的開發程序，也無損於使用UML來建構軟體模型。而且UML中的各種符號與規則，可以跟物件導向的程式語言（如C++），在程式結構上互相呼應。當然這並不代表UML只能適用在物件導向程式語言上，對於不採用物件導向方法的程式語言，仍可使用UML。

以現在UML的規範來看，其內容已經包括有：基本建構區塊（Basic Building Blocks）的顯現符號，如事件（Events）、關係（Relationships）、圖示（Diagrams）；其次是符號使用規則（Rules）；之後是各類符號及圖示的共通機制（Common Mechanisms）。對於這些UML內容，Ivar 簡明地說，就是標準通用的符號及規則，兩者一起建構描繪出軟體系統的規劃架構及設計概念。

如何學會區別UML 模型（model）與UML圖示（diagram）之間的差別，是件重要的事情。Ivar指出像使用案例（Use Case）圖示、協同作業（Collaboration）圖示、部署（Deployment）圖示、元件（Component）圖示等等，這些UML 圖示是將資訊用圖形化的方式，呈現在UML 模型中。它們很像是模型之中的圖形零件，透過符合系統需求的組合方式，成為各自獨立描述系統內部設計的模型。

雖然UML已經開始在國際上被廣泛使用並且變成一種標準，但總有人以很主觀的想法提出批評。Ivar繼續說，例如批評者會說使用者在採用UML時，必須額外提供某些用來解釋模型的說明；還有另一個問題是UML並沒有充分支援分散式的系統架構，因為在這種系統中，動態（lives）存在的元件，將會跨過許多伺服器來執行運作，這種橫跨特性UML似乎無法標示得很清楚。對於上述的這些批評，Ivar說UML其實有提供使用者自行定義延伸（Extension）圖示，以滿足使用者特定的系統需求。目前有兩種較通用的延伸圖示定義，一種是使用在商業流程的UML商業模組（Business Modeling with UML），另一種則是「客觀流程（Objectory Process）」。

批評者提出UML所包括的內容項目非常龐大與繁雜，造成學習使用上的進入門檻。關於這點，Ivar則覺得雖然在使用UML的過程中，必須投入相當多的心力，因此讓開發者感到複雜與困難。不過這是因為要用嚴謹的方式來描述軟體開發藍圖，這種圖示定義與流程仍然有其存在之必要。為解決此一現象，簡化軟體開發流程，並降低學習UML的門檻，Ivar已經計劃投入開發UML的智慧型代理人程式（Intelligent Agents），透過這類智慧型自動輔助程式，可以協助使用UML的開發者，一步一步地按照指引去進行UML塑模的開發規劃及設計工作。他相信這種智慧型代理人程式，將有助於縮短學習UML的時間與障礙，提昇UML的規劃設計效率。

就Ivar過去30年來的大型軟體專案開發經驗來看，他認為第一代的軟體開發流程是採用系統分析與設計（SA&SD）、物件導向軟體工程（OOSE，Object Oriented Software Engineering）之類的觀點，這是一種像兩台電腦點對點連線（Ad Hoc）的制式化流程，是教科書上一再教導的觀念；至於第二代的軟體發展流程則是詳盡地用結構化方式來進行，如UP（Unified Process，統一流程）；到了第三代則要採用更加聰敏機靈的方式進行開發，像在UP工具之中，導入Intelligent Agents，協助開發。

Ivar覺得目前的元件技術（Component Technology）是可以將重覆使用的程式執行程序，撰寫成元件的方式來加以重覆使用，不必凡事都要從頭開發一次。利用像J2EE與.NET這種程式語言來開發程式元件，若在著手開發之前能夠使用UML來規劃設計出完整的軟體系統藍圖，有助於找出哪些部份可以採用元件方式進行。

雖然UML與元件技術已是目前的趨勢，但Ivar認為這樣子仍然有所不足，必須在元件與UML之上再加入最適當的執行程序（Best Practices），因為UML可以用各式各樣的不同方法去規劃，元件的定義必須符合系統的使用需求，如何管理元件的開發等等這些問題，就必須要有軟體發展的最佳執行程序。

Ivar指出他認為三種最適當且重要的基礎執行程序（Foundation Practices）：反覆週期的發展程序（Iterative development）；使用案例導向的發展程序（Use cases driven development）及階段式中心建構的發展程序（Architecture-centric）。這三種方式是在發展元件及UML 模型時，Ivar建議可採用的程序方法，如果能掌握上述的開發程序，至少能幫助適當地規劃元件功能及建立UML的開發圖示模型。

基於以上的概念，Ivar在Rational軟體公司研發出RUP（Rational Unified Process）這種反覆式軟體設計程序方法。RUP是描述如何有效地部署發展軟體的一套商業化工具軟體，它不單只是流程而已，而是可以包含大量不同的開發程序，並且可以量身打造適用於各種狀況。對特定軟體專案，可將需要被開發出來的功能加入RUP設計之中，並且還能設想得到系統的規模與類型，尤其適合大型軟體開發專案使用。

RUP的目的主要是協助開發人員，在進行開發的過程中，對於方法和技術上能有規範可循，通常程式設計師對整個軟體系統開發的過程，都只知道個別的某些片段，難窺系統全貌。如果有一套適合的程序、方法與步驟，足以提供軟體開發歷程之中，清楚地規劃設計說明，那麼可以讓大家在團隊工作中，彼此有共同的開發概念，易於溝通。

Ivar指出在軟體開發的過程中，若同樣能夠透過一些智慧型輔助性程式，透過程式自動判斷與指導，讓軟體開發的程序變得相對容易，節省學習RUP的時間，降低進入門檻，亦能增進理解RUP。Ivar自認為，RUP的好處在於提供基本方法及指引，協助軟體開發者建立標準化的開發程序。

RUP能提供使用者豐富的開發系統的知識基礎， RUP同時也具備有工具及訓練與顧問的指導方法。Ivar建議若能將「尋找知識」→「學習知識」→「應用知識」→「控制知識的使用」，再回歸到「尋找知識」，變成一種軟體開發程序的循環，將可達到善用RUP的效益。另外一種方式則為建立智慧型代理人程式，以打造足夠聰敏的流程，幫助企業進行軟體開發。

基礎的執行程序就是UP（統一流程）的本體，Ivar說不要去預先設想軟體規模、產品型態、平台或組織；最重要的事情不是這些，而是「標準」。執行程序並不是強制性的，而是為了增加軟體開發的成功機會。Ivar也提醒：執行程序必須是能夠被個別地描述與使用，一旦選擇要使用某個執行程序後，最好是能從發展小型的程式核心（kernel）開始。用這種方式進行，可稱之為SDP（Software Development Process，軟體發展程序），可以先增加系統所需求的元件在程式核心之中，然後從中發現何時會真的需要這些元件。

智慧型代理人程式（Intelligent Agents）是Ivar一直看好會成為下一世代軟體開發的重要技術。軟體開發者，可以藉由跟智慧式代理人程式交談，尋求提示與建議，逐步完成UML及RUP的設計規劃，並且可以主動地提昇更具有附加價值的軟體開發流程。

由於軟體工程的落實，讓之後的軟體系統架構有了改變。Ivar對於目前SOA（Service Oriented Architecture，服務導向架構）的概念表示贊同，因為SOA可以從不同的平台上連結各種的元件，且SOA可以降低過去應用程式（Applic-ations）不易呼叫元件（或服務）的困難度；還能讓元件在不同的平台之間，能夠互通與使用。只是SOA也會面臨到如何清楚地定義系統需求跟應用程式與服務之間的對應，另外還有要如何管理與應用眾多的服務（元件）之挑戰。

未來在網路上要進行的工作就是開放資源，最適當的執行程序就是演化出一個生態系統出來，讓下一世代的軟體開發流程可以充滿激情，縮小使用的成本，並且還能增加生產力及品質，增進工作團隊的潛力，當然還希望能增加工作樂趣。

對於未來的發展，Ivar樂觀地表示，若欲充分應用實施必要的統一流程（Essential Unified Process），拼貼裁縫及接納必要的統一流程，是軟體開發得要經歷的過程之一。他還預期未來各項執行程序與必要的統一流程，全部只要花費11天即可以完成訓練課程。運用工具與代理程式自動化的輔助，將讓軟體開發流程，從以機器為中心的世界，進化到以人為中心的世界，而且這段過渡的時間將不會花費太久的時間。

Ivar最後給年輕軟體工程師的建議是：善用開發工具，擴大自己在軟體界的常識與知識，懂得如何利用各類已上市或公開傳佈的模組，要成為一個整合者（integrator），而非開發者（developer），才能掌握系統需求並縮短開發時程。

智慧型代理人程式（Intelligent Agents）是Ivar 一直看好會成為下一世代軟體開發的重要技術。軟體開發者，可以藉由跟智慧式代理人程式交談，尋求提示與建議，逐步完成UML及RUP的設計規劃，落實具有附加價值的軟體開發流程。