潘加宇：謝謝大家的光臨。今天第一個話題是軟件工程最新趨勢，從我的理解來看，和Ivar 來談有四個方面，第一個是用例；第二是UP；第三，Ivar離開Rational做自己的新事業，在北京也成立了Ivar雅各布森中國有限公司，到底是做什麼呢？這是他的新事業。大家可以關心一下；第四個主題是想聽聽Ivar對MDA新進展的形象。
第一個話題就是用例，大家使用用例的時候會有很多困惑，用例力度是多少？業務用例跟系統分道有什麼問題關係呀。上課的時候大家也問過我，我也回答了，但覺得不權威。今天用例發言人來到這裏，機會比較難得，看大家在用例有什麼問題可以問Ivar。
提問：所謂現在提出MDA，Ivar提出Usecase，我現在帶學生，到底是怎樣從Usecase開發一個項目，現在要做的就是做設計，是怎樣的流程？設計比較粗略，用序列圖去解釋，實現功能性的需求怎樣去合作？怎樣完成這個定義。從設計來講，哪幾個是最關鍵的？我們建立類圖、序列圖或者協作圖，目的是要建模，建模就是要建類，把屬性和方法填滿。從用戶需求怎麼得到一個類，得到這個類裏頭的屬性方法，所有類建全了，模就建全了。序列圖是消息，是到類的一個消息，活動圖也是描述消息，我這種理解對嗎？也就是哪些圖是最重要的？
Ivar Jacobson：回答第一個問題，從業務建模開始到編寫代碼，哪一個步驟或者方法是最重要的？序列圖是最重要的一個圖，活動圖是幫助你解決了在你的對象上怎麼分配，怎麼分配每一個職責，這裏起到一個非常重要的作用，序列圖在很大程度上幫助你回答Usecase是怎樣實現的，所以序列圖是最重要的。但是有一個非常重要的一點，協作圖可能會比較細節，就是說取決於你現在到底做什麼？如果已經到了非常低的細節層次的時候，序列圖會幫助你很多。序列圖關鍵一點就是你要有泳道，你的泳道一定要清晰，否則就會有一個混沌的泳道，整個思維就亂掉了。
我們在電信當中曾經在SDL的方式曾經用過狀態圖和活動圖在一起用，來表達正在運行的進程的狀態，這是一個很好的方式。在其他的環境下，我們非常強調活動圖一定要有泳道。
我們在業務流程當中，長期在業務活動圖當中描述流程，這個方式已經很多。但是我們看到的是，在業務流程描述當中要有泳道來給你一個明確的標記，如果沒有一個明確標記的話，業務流程畫出來以後，只有業務流程作者才能理解業務流程，因爲別人沒有任何一個方式作爲參照來理解到底這個業務流程在說什麼，所以這是一個非常重要的。
提問：就是分不清到底誰來做。
Ivar Jacobson：最有用的是對象。
劉新生：我想問一問，您最近在研究AOP，您對AOP和用例結合這方面有什麼最新的研究進展？
Ivar Jacobson：在1969年的時候就已經在思考類似關於Use Case的問題，有一天突然領悟到新的想法幫助他來解決如何描述用戶需求，如何來把整個開發的鏈路打通，在這中間就想到Use Case的概念，當時發現有一個非常大的缺點在什麼呢？Use Case非常好的概念就是可以用Use Case來做設計，你可以用它來做測試，把它轉化爲測試用例，但是一旦到了實施階段，真正編碼的時候，發現Use Case有哪些類、協作圖參與到Use Case，具體到每一個模塊參與到Use Case當中，這是長期困擾的一個問題。
我在1978年的時候，在愛立信內部發表了一篇技術報告，就是來討論橫跨很多個組件的關注，實際上爲什麼做這樣的事情呢？解決了我們經常面向對象裏經常遇到哪個詞，一個叫“散佈”，一個叫“纏繞”，Use Case 遇到這個模塊就會有一個現象，就是散步和纏繞，爲了解決這個問題，當時提出了一個方案，但愛立信內部不喜歡這個解決方案，在1986年的時候，我寫了一篇論文在面向對象年會上，當時把主體思路做了一個闡述。
在這中間解決了什麼問題呢？也就是我們現在看到在Use Case從需求開始一直貫穿到測試中間一個缺失的鏈條，也就是在實現這一塊。之前論文上就提出如何把這些關注點真正的從頭到尾的割離開。
在面向方面編程方式的幫助下，我們能夠做一件以前做不道的事情，在項目當中可以根據Use Case來分隊開發團隊的職責，有人根據一兩個Use Case做需求，有一兩個人對Use Case做設計，有人專門對幾個Use Case編寫代碼，這是在以前做不到的。以前編寫代碼的時候一定是分配組件了。
透明：剛纔講到方面用在Use Case的實現提供幫助，怎樣保證方面取得組合作用。在實現的時候，怎樣能保證方面用在Use Case上，有沒有契約的保證？
Ivar Jacobson：實際上是一對一的對應關係，每一個Use Case的擴展會對應到方面，它們之間是同級的關係或同輩的關係，這實際上是用類來體現Use Case。在擴展上有一個方面的對應關係。
潘加宇：我有一個問題，您有沒有自己用過方面的工具，例如自己嘗試過用AspectJ來做一些東西？
Ivar Jacobson：我本人用AspectJ寫過一些小的程序，我知道有一些很好的朋友在用AspectJ開發，開發過很多大系統，所以它能夠發現大系統當中的大問題，這些關鍵問題點上做AspectJ上會發生什麼變化，它也提出了在UML標準當中對AspectJ方面有一個支持，包括Pointcut。
錢嶺：我們工作當中有通訊系統，會用到一些時序圖，我們關注的是Dialog，如何保證模型是正確的，而不是這個圖畫就畫出來了。我想在這方面有沒有相關的技術呢？
Ivar Jacobson：1967年－1972年之間，我用序列圖的原型，包括序列圖、活動圖，在1967年－1972年和1970年－1976年分別組織開發過兩個大的時序圖，確實有一個現象，我們有一個很重要的發現，在用序列圖、Dialog原來小很多，我們以前爲有很多Dialog，我們正規描述下來發現Dialog沒有那麼多。同時藉助狀態圖來描述每一個處理的時候，這個地方要非常小心來識別哪些地方的對話，如果細心的話，不會碰到那麼多Dialog。據我所知，UML2.0放了很多新的東西來幫助解決這個方面的問題。同時有人建議peri網和UML應該很好結合起來來解決這方面的問題。這更多是學術的問題。
潘加宇：這裏有一個在線網友的問題，請Ivar先生評價一下UML2.0當中的Use Case。
Ivar Jacobson：我並沒有參與到UML2.0的制定工作當中去，但是我聽說當時有計劃在2.0對Use Case做比較大的改變，當時我非常反對他們所提的一些建議，現在回想起來，當時的反對是非常正確的，如果不反對他們那些改變的話，我們今天就沒有辦法這麼清晰的把Use Case和麪向方面結合起來。
如果只是針對1.1的問題，我有一個基本的假設，1.1到2.0沒有發生很大變化的話，我是非常滿意在目前UML標準中對Use Case的定義，爲什麼呢？首先從形式的角度上來看的話，你可以識別他，Use Case本身有行爲和屬性，所以這是一個很好的。從根本來說，Use Case並不是從數學證明的東西，是非常實用型的東西，在形式化上已經做到這麼一個程度已經很好了。另外一個角度，Use Case在UML定義上有很多用途，表現出它一個強大表現力，在軟件建模、業務建模當中都可以用，在用戶建模當中可以用，在用戶體驗當中也可以用，在系統交互當中也可以用，一句話總結就是自己一個漂亮的孩子有很多很多的名字，Use Case就是這樣一個東西。
提問：我想是否一定要在系統開發當中必須使用用例？用良好的交流對內的溝通和對外的溝通，某種意義上可否可以取代用例圖。我們前期做了一個項目，跟客戶交流很好，內部交流也很好，項目做得非常成功，但當中沒有使用任何用例圖。
Ivar Jacobson：這有點像哲學問題，是不是一定要用Use Case，應該反問你一句，你剛纔談到內部的交流和外部交流都非常好，在內部交流的時候怎樣確保交流之間的連接關係，你是怎樣管理的？你有這麼多人交流，連接關係是怎樣的？外部交流有那麼多外部關聯關係，怎樣把它拿到一起形成一個完整的圖畫，如果你真正在思考這兩個問題、回答這兩個問題的時候，實際上你已經自覺不自覺用類似於有Use Case的想法，雖然沒有把Use Case的圖畫出來。所以Use Case並不是讓你覺得很困難的東西，它是非常符合直覺的東西，包括上午談到從Use Case得到測試用例，包括整個集成測試，實際上就是對用例的測試等等，像這些都是非常符合大家開發經驗的直覺，而不是讓你額外花很多東西要做的事情。
實際上，這是一個直覺，是每個人想的東西，用不用Use Case是另外一回事，只是把它變得更系統化而已，把這個系統化以後，就把這個事情變得更加像流水線，同時給團隊也帶來很多價值。
潘加宇：下面進入第二個階段，關於UP，統一過程，這個統一過程是成型的，當一個產品來賣的東西，這是Ivar的成就。現在又出現很多敏捷的思路，我想大家對統一過程和迭代開發有什麼困惑。
錢嶺：UP對於軟件開發來說，難度比較高的可以用，難度低的不可以用，我想對於全新的系統是怎麼用的？這個項目用了很多新技術，並不是一個發明創新的項目，並不是讓過程引導發明創造，這不需要，我們自己可以想，但這怎樣在過程當中把很多新項目集中在一起，是這樣的意思。
Ivar Jacobson：我們的理解是你在問一個創新型項目或者一個完全新的項目。每一個過程都能支撐你來做創新，但並不能幫助你做創造性的思考。
這個問題我還沒有真正理解你的意思，我理解的是看不到RUP不能使用的東西是哪些？沒有看出哪些項目不適用RUP。如果把一些新的技術組合一起，因爲RUP可以加快整個開發的進程，實際上能夠幫助你更快來推出。
潘加宇：我認爲RUP的思想是一個迭代的思想，在每次迭代出來一個SQ的版本，這個版本可以顯示給顧客，讓售客看一下是否要求的需求？RUP的思想和人的認知過程是一樣，人的認知過程對一個事不是馬上認識，而是經過迭代來認識的，所以RUP是一個大綱，這是什麼意思呢？它的大綱就是有很大擴展空間，可以根據擴展去思考和創作，RUP Rose沒有規定哪些圖不可以劃，也可以劃，設計得好，就可以做得出好的東西。UML和Rose有擴大性，根據語言產生新的東西。
提問：RUP是否幫助我們解決一些風險性和不確定性的問題呢？規避新技術的風險？
Ivar Jacobson：這中間會幫助RUP，它是迭代開發的東西。爲什麼統一過程能夠幫助呢？因爲統一過程實際上是一個迭代的開發模式，它把你的項目分爲若干個小項目，每個小項目有兩個星期到四個星期的實習時間。這樣的話，應該能很好回答你剛纔提到的高風險性的問題，在中間每一步邁得比較小，你的決策被分散到若干個小的迭代當中去。
中間具體操作是什麼方式呢？比如剛纔談到我在用一個新的編程語言或者新的編程平臺也好，就會當成一個很高的風險，類似的風險還會把全部風險列出來，然後回過頭看Use Case，哪些用例？我做這個用例能幫助我從某種程度解決或者規避左邊畫的風險，把用例識別出來的是最開始在迭代的時候要實現的問題。
提問：剛纔說要講RUP和敏捷開發，好象都沒有講到敏捷開發。以前有一種說法，RUP和XP這些東西屬於矛盾的，RUP屬於稍微重量級，敏捷開發屬於輕量級的。但是我覺得從我這邊的體會，RUP可能更像一個理論性，從理論上給它定了一些什麼樣的工程，是怎樣進行的。但XP在實踐當中比較有指導性，但中間有很多相重的地方，比如RUP是迭代開發，和敏捷持續開發有類似的想法，所以在這個過程當中，能否請Ivar先生講一講？我上午聽了Ivar的講座，當你聽到需要敏捷方式開發軟件的時候，是否意味着UP也是敏捷的一種方法？
Ivar Jacobson：關於XP和統一過程，在目前有很多錯誤的理解或者對它的一些錯誤的觀念，我在這裏做一個澄清。在很多方面，XP和統一過程是非常接近的，剛纔那位小姐提到重構是否跟迭代很像，的確是這樣的，他們差不多是一個意思。Use Case和用戶故事是否很像，幾乎是一個意思。在這中間討論事情的時候，如果細心來看會有背後的思想基本是一致的。這裏面有很大的區別是什麼呢？統一過程中非常強調我需要首先把一個穩定的架構搭建出來。如果一開始沒有穩定的架構，在後期項目會花更多錢甚至數十倍的架構彌補這個錯誤。另外一個方面，實際上更多是人性因素，極限編程談到很多人與人之間的交往，仔細讀統一過程的話，我們絕對不是說不關心人和人之間的交往，只是沒有做那麼深的強調。
我們討論一個最大區別的話，作爲XP和統一過程的話，中間真實的區別是什麼呢？XP強調所謂的隱含知識，也就是沒有明確表達的知識，這個知識存在開發人員的腦子裏頭，今天團隊有這麼多知識，就用這些知識，沒有別的知識來幫助你。我們在統一過程當中的另外一個方式是表達出來的，這個知識不一定在團隊當中已經存在的知識，可以通過學習和操練獲得新的知識，這點是兩種體系最大的區別。
在這種情況的話，我們所說的敏捷開發方法，大家知道有一個若干方法，剛纔我提到XP比較多，針對的是整個敏捷開發的運動。敏捷開發的運動在這個思想上會給人一種感覺是什麼呢？任何人都可以編軟件，只要利用你現有的知識就可以了，可能給人造成的感覺就是在這幾個大的原則下利用現有的知識就能獲得成功。這個讓大學生知道會比較高興的，因爲一出來就可以自由工作了。另外一些數不清的方法學的專家們可以定新的方法，這是它背後的一個驅動。
統一過程則不同，我們通過長期的工程實踐發現和識別了一系列最佳實踐，這些最佳實踐最小的項目是好用的，最大項目也是好用的，從成功經驗當中得出一系列知識，把這些知識明確表達出來和記錄出來，這種方式和敏捷開發方式不一樣，因爲敏捷方式更多強調原則，沒有真正把知識提煉出來，在形成體系的方式上是有區別的。作爲統一過程來說，可以當成很大一本書，是非常豐富的知識寶庫。
這個大的知識庫有用嗎？當然有好的方面，因爲它是一個很好的知識結構，它也有缺陷的地方，這麼大的知識庫誰會去讀一萬頁或者這麼大的知識體。但這個地方關鍵在於哪裏呢？做軟件開發，作爲開發人員需要有相應的知識，需要知識來裝備你，這些知識能夠幫助你真正的達到敏捷，當工程師掌握這些知識的話，開發是非常敏捷的，我想這是一個真正的敏捷。
在我最開始設計的過程中，我就知道只有10％－20％的工程師會真正來應用統一過程，爲什麼呢？因爲統一過程太大了，是一個非常大的知識體。另外一個方面，必須要用一個非常嚴謹的工程方法來開發這樣的過程，我把它當做一個很重要的產品來做，這個時候必須要有一套嚴謹方式把這套東西做出來，這套東西做出來一定是很大的東西。同時我意識到人們是不喜歡讀書的，現在又找到一個新的解決方法，從而幫助大家更快應用這個過程。
1980年的時候，我提出用智能助理幫助你來開發軟件，2000年，我成立一個公司Jaczon來實現這個夢想，這個公司開發出一個產品叫Waitpoint，這個產品已經得過Jolt獎，這個工具能夠幫助你來識別用例，來描述用例，來幫助你設計，來幫助你做架構，來幫助你做測試等等，所以在這種方式下，智能助理的知識從而變爲硬盤的知識，這種知識是作爲一個輔助工具存在的。我認爲這是比所謂鼓吹敏捷方法更敏捷的方式。謝謝。
潘加宇：第一階段的時間就到這裏，現在交給熊妍妍。