四色原型板橋里人 http://www. 2006/2/19（轉(zhuǎn)載請保留） 前言 我們搞技術(shù)的有很多誤區(qū)，比如經(jīng)常陷入純技術(shù)鉆牛角尖的爭辯，而全然不顧業(yè)務場景，技術(shù)活做太多，經(jīng)驗一籮筐，但是有時會疑惑，這些經(jīng)驗是否適合其他自己沒有經(jīng)歷過的新系統(tǒng)呢？我們在技術(shù)設計路線上走得太久，容易迷失方向，什么是設計不足；什么是過度設計，如何把握這個度？ 在對待項目上，有一種極端是認為每個項目都是特殊的，不可能和其他項目有共同之處；這算是一種經(jīng)驗主義吧。 甚至有些程序員唯大項目不做，認為只有大項目才能鍛煉自己，做過大項目的認才是牛人。 這些誤區(qū)都是因為我們軟件基礎知識的缺失，沒有人告訴我們，大小不同項目是否有共同點？ 我們現(xiàn)在做的項目需求是處于所有項目需求領(lǐng)域中何種位置？為滿足這個業(yè)務需求我高質(zhì)量高效率完成了這個軟件系統(tǒng)，那么在這個軟件系統(tǒng)中體現(xiàn)的解決方案是否適合其他項目中其他類似的需求呢？ 以前，通過設計模式我們已經(jīng)完成了設計上重用，再通過重用框架，可以更高效粒度高大地更高質(zhì)量地實現(xiàn)大部分系統(tǒng)， 但是，看上去同一個業(yè)務需求，在不同的項目，每次還是需要我們對這些框架進行重新組織設計，哪怕它們有些相同之處， 例如： 在電子購物系統(tǒng)中有商品和用戶兩種重要元素，商品本身是一個物，而且可能有層次類別區(qū)分；商品和用戶必然發(fā)生關(guān)系；在論壇系統(tǒng)中也存在帖子和用戶兩個元素，帖子是一個物，本身也有 類別區(qū)分，每個帖子必然和一個用戶發(fā)生聯(lián)系。這兩個系統(tǒng)使用J2EE實現(xiàn)，當我們進行建模分析時，發(fā)現(xiàn)彼此之間隱約有一些共同之處。具體架構(gòu)時又會涉及到表現(xiàn)層、業(yè)務層和持久層設計，兩者幾乎都可以使用相同的架構(gòu)如（Struts+Jdon+Hibernate） 等等。 那么，能不能省卻我們在每個項目上都會這些類似相同的需求重新再做一次設計架構(gòu)呢？如果設計模式重用是針對一個具體設計場景而實現(xiàn)的重用，現(xiàn)在我們幾乎不再滿足這種細粒度的低效重用效率，如果我們能抓助軟件源頭：業(yè)務需求，總結(jié)出某一類問題的共同之處，那么與之相聯(lián)系的整個解決方案 也許就能夠得到重用，這種重用粒度更大，從而更高帶來開發(fā)效率。 但是，有一個問題：不同項目的業(yè)務需求之間到底是否有共同之處？大項目和小項目的業(yè)務需求是否有共同之處？ 我們每做一個項目，是否可以達到一葉知秋的效果呢？ 業(yè)務需求在我們軟件系統(tǒng)一般用Model來統(tǒng)指，筆者曾經(jīng)提出：域建模、模式和框架是Java軟件的三個大方面， 其中域建模起著關(guān)鍵龍頭作用，如何分析業(yè)務需求，如何實現(xiàn)正確的類圖（建模）表達，是決定整個系統(tǒng)成敗所在。更有這樣的觀點：No model,no patterns ,then no framework Model代表業(yè)務場景，沒有業(yè)務需求，就沒有設計模式，也沒有框架。 幾年前誕生的MDA是在這個方向進行了探索，很多先驅(qū)大師更在這方面進行了理論探索，如果說OO是對現(xiàn)實世界的一種抽象，那么MDA是比OO更加抽象的一種技術(shù)或方法論。“我們在一個軟件革命的開始，它象90年代我們看到的面向?qū)ο缶幊虖膫鹘y(tǒng)過程語言中抽象出來一樣。” 原型archetypes 比如英雄這個原型在美國或在中國看上去可能不一樣，但是英雄就是英雄，我們還是能夠很快地總結(jié)出英雄的一些特點。 因為原型是人類組織、總結(jié)和概括客觀世界的基本概念，我們完全有理由在軟件開發(fā)領(lǐng)域應用這些概念。 業(yè)務原型business archetypes OO軟件系統(tǒng)是對業(yè)務領(lǐng)域（business domain）的思考抽象并進行管理操作，注意業(yè)務領(lǐng)域這個概念，我們相信應該能在業(yè)務領(lǐng)域中發(fā)現(xiàn)原型，或者在軟件系統(tǒng)；或者這些系統(tǒng)模型中。我們稱這種原型類型為業(yè)務原型（business archetype） 一個業(yè)務原型應該是一個在業(yè)務領(lǐng)域或商業(yè)軟件系統(tǒng)持續(xù)發(fā)生并且普遍存在的最初級的事物。 Party是一個業(yè)務原型例子，一個Party代表可標識的、可定位的單元或單位，這些單位有正常的 狀態(tài)。 通常一個Party用來表示某個人或某個組織。所有商業(yè)系統(tǒng)都或多或少有Party概念。 原型之間是相互交互的，Party, Product, 和 Order是每個虛擬商業(yè)系統(tǒng)的基本概念，在這個商業(yè)系統(tǒng)中，你可以賣產(chǎn)品或服務。我們將這些原型之間的協(xié)作看成是業(yè)務原型模式(business archetype patterns). 業(yè)務原型模式business archetype pattern定義：它是在業(yè)務領(lǐng)域或商業(yè)軟件系統(tǒng)持續(xù)發(fā)生并且普遍存在業(yè)務原型之間的協(xié)作。 原型（Archetypes）和分析類（analysis classes）區(qū)別 分析類（analysis class）是代表問題域中一種即時抽象，它對應真實世界的業(yè)務概念。 原型總是比正常的分析類更加抽象，屬于位于目前抽象層次的更高端，因此，通常原型模式可以生成一個或多個分析類。 原型模式和分析模式的關(guān)系怎樣，原型模式是分析模式嗎？不是，從定義范圍上看，原型模式有很多特性看上去要比分析模式多。分析模式是首先由Matin Fowler提出并定義如下："分析模式是一組概念，這些概念代表業(yè)務建模中一個普遍的構(gòu)建，它也許和一個域相關(guān)；或跨越多個域。 其中并沒有任何原型的概念。 原型模式比分析模式要更加豐富，體現(xiàn)以下幾點： 四色原型 四色原型是誕生于90年代，現(xiàn)在被廣泛使用的一種系統(tǒng)分析方法，如Borland的Together架構(gòu)師版，準確地說，是由Peter Coad 和 Mark Mayfield首先提出[Coad92],然后由David North拓展[Coad95-97]
前面已經(jīng)說過，域建模是整個軟件系統(tǒng)的龍頭，在現(xiàn)代Java技術(shù)如JiveJdon3.0開始之前，我們都是需要領(lǐng)域建模，也就是在UML中畫出類圖，然后標記上類圖四種關(guān)系（關(guān)聯(lián)、依賴、繼承和實現(xiàn)），但是這些只是UML圖的表面，只是一種畫圖技巧，就象CAD畫圖一樣，你可能沒有被告知：這個類圖是怎么出來的？為什么選用關(guān)聯(lián)而不是依賴，這些實際都屬于分析領(lǐng)域的知識，而四色圖可以說為我們這種分析提煉提供了一種模板或分析框架，這樣我們可以按圖索驥去分析每個陌生的系統(tǒng)，我們擁有強大的分析方法工具。 moment-interval archetype 賣東西是在某個時刻發(fā)生的，它有發(fā)生日期和時間。租賃行為是在一段時間內(nèi)發(fā)生，從開始出租和歸還所租物品；預定也是持續(xù)一段時間，什么時候預定；什么時候過期等。 這些我們都使用moment-interval原型來表達，UML圖如下：
Moment-intervals是和組件模型捆綁在一起，代表了組件模塊關(guān)注的核心和靈魂，在一個Model中，Moment-intervals經(jīng)常封裝的是最關(guān)鍵的方法，為讓其顯目，moment-interval的UML圖我們使用粉紅顏色表示。在代碼上用@標識符標識： /** @archetype moment-interval*/ 在任何領(lǐng)域中，我們都能尋找moment-intervals原型并且開始建模，在原材料資源管理系統(tǒng)中，我們可以這樣對待從報價單（RFQ）到購買訂單（PO）直至發(fā)票，在一個制造管理系統(tǒng)中，我們也就可以將一個計劃的過程和步驟分析到實際過程和詳細步驟。 原型在幫助指導建模方面一個有效方式是：它能標識那些被包含在Model模型中的類（Classes）以便于區(qū)分，原型不只是簡化了類的區(qū)別；原型還可以區(qū)分類的行為職責（responsibilities），例如類的屬性，方法等。 role archetype 角色原型比較容易理解，任何一個系統(tǒng)都需要人或某個組織介入運行，例如論壇系統(tǒng)需要注冊者角色發(fā)言；銷售訂單需要業(yè)務員角色制定，等等。 這里有一個Party原型定義：它表示一個可標識、可定位的單元，這個單元有自己正常的狀態(tài)并且能夠自主控制自己的一些行為，通常情況下，人或組織是一種Party，但象護照，身份證等注冊性標志等都可以作為Party。 注意，并不是說Party或人或組織就是Role原型，必須Party或人或組織參與一種活動后才為角色，就象張三在電影中表演皇帝，他只有參與電影表演才是皇帝角色；李四在XX公司的角色才是經(jīng)理，他只有參與這家公司運作才是角色經(jīng)理；否則他們只是一個Party原型。 所以，Role角色是Party扮演的（a role that a Party plays），Party是角色Role的扮演者（role-player）。 當我們在建模時，對于一個角色扮演者，可以有他自己的核心屬性如名稱、年齡（以人為例子），也可以有與業(yè)務相關(guān)的方法，比如一個小店，當?shù)昀习迦ナ斟X時，他的角色就是收銀員（cashier），此時可以將與收銀員角色相關(guān)業(yè)務特點加于其上；當然，同時他也可以是老板（Owner）角色。那么下圖中authorizedFor方法就是參與每個角色的行為，當他作為某個角色被授權(quán)登錄后，與此角色相關(guān)的業(yè)務特點就應用在他身上。
大家已經(jīng)注意到了：角色原型在UML中是使用黃顏色標識的。角色模型是第二重要的原型，所以使用黃色。 我們已經(jīng)知道，Party是一個又自主行為、能夠控制自己行為的表示，如人或組織，還有其他沒有自主行為的表示，也就是某個地方或位置或某個事情，我們一般稱( place, or thing)，不但Party可以成為角色，而且 place或thing也可以成為角色，比如，一個商品Product可能又兩種角色：在銷售過程中商品；正在使用的商品。 party, place, or thing archetype 上面我們說過，party place或thing都可以成為角色原型，注意到角色原型中的UML圖，party圖是以綠色表達。 Party表示有自己正常的狀態(tài)并且能夠自主控制自己的一些行為，通常情況下，人或組織是一種Party，但象護照，身份證等注冊性標志等都可以作為Party。 Place or thing表示一樣不會說話沒有行為的東西，例如商品，當然這個商品可以扮演不同角色，既可以是零售的一個電源插座；也可以批發(fā)系統(tǒng)中的一個電源插座，它是被賣的，可能在不同業(yè)務系統(tǒng)被賣的方式不一樣。 description archetype 種類description原型其實是第三重要的原型，一般情況下，它類似目錄級別catalog-entry-like的種類，例如某個商品電源插座屬于家用電器這個種類，當然家用電器又屬于電器這個目錄，是一個樹形的目錄結(jié)構(gòu)。例如論壇中帖子和回帖之間也是一種種類原型。 比如你的紅色?？怂故歉Ｌ厣a(chǎn)的一輛轎車，它有車牌號、購買日期、顏色和里程表等，這些代表Thing原型，那么作為轎車這個種類來說，它有一些種類屬性，例如：生產(chǎn)廠家、生產(chǎn)批號、適用顏色等，這些屬性是轎車這類所有車輛都共有的。 在設計模式這個實現(xiàn)級別，我們通常使用組合模式來實現(xiàn)種類原型。 四色原型圖
每個原型圖有屬性和連接（關(guān)聯(lián) 依賴等關(guān)系）兩個部分組成。 |
|
|
