| 劉愛軍 序言 2006年8月底，我有幸參加了一個架構(gòu)師培訓(xùn),，通過這個培訓(xùn),，清晰了很多概念，結(jié)合自己的知識和經(jīng)驗(yàn)，對公司軟件應(yīng)用系統(tǒng)的架構(gòu)設(shè)計有了很多想法,，特撰寫本文檔,，把自己學(xué)得的系統(tǒng)架構(gòu)知識和自己的思考與大家共享，希望對公司設(shè)計人員進(jìn)行設(shè)計工作時有所幫助,。本文中很多內(nèi)容都是我個人的觀點(diǎn),，我個人技術(shù)的深度和廣度也不夠，肯定會有不少不太嚴(yán)謹(jǐn)?shù)牡胤健? 1. 系統(tǒng)架構(gòu)知識 1.1. 什么是企業(yè)應(yīng)用 很難給出一個精確定義,，不過企業(yè)應(yīng)用一般都有這些特點(diǎn)： l 持久化數(shù)據(jù) l 大量的數(shù)據(jù) l 很多人同時訪問數(shù)據(jù) l 大量操作數(shù)據(jù)的用戶界面 l 通常要與散布在企業(yè)周圍的其他企業(yè)應(yīng)用集成 所以,，企業(yè)應(yīng)用一般都比較復(fù)雜，架構(gòu)設(shè)計大多都是針對企業(yè)應(yīng)用的,。 1.2. 什么是系統(tǒng)架構(gòu) “架構(gòu)”用很多種不同的定義,，這些定義很難統(tǒng)一，但基本上有兩點(diǎn)都能統(tǒng)一：1）架構(gòu)是最高層次的分解 2）架構(gòu)是系統(tǒng)中不易改變的決定,。 而通過這次架構(gòu)培訓(xùn),，我這么定義架構(gòu)：從核心概念上講，架構(gòu)是一套構(gòu)建系統(tǒng)的規(guī)則,；從表象上看,，軟件架構(gòu)是一套模板，以文檔,、代碼,、工具程序等方式表現(xiàn),。（其他更多的軟件架構(gòu)的概念描述,，請查看8月24日發(fā)的郵件――《軟件架構(gòu)基礎(chǔ)知識.doc》） 軟件架構(gòu)的成果是一套模板，這套模板會通過一種方式去組織,，這個組織形式也很重要,，應(yīng)該從不同視角去表現(xiàn)，以適合不同人去理解和應(yīng)用,。 1.3. 系統(tǒng)架構(gòu)設(shè)計師干什么 根據(jù)系統(tǒng)架構(gòu)的定義,，系統(tǒng)架構(gòu)師的職責(zé)當(dāng)然是制定軟件系統(tǒng)構(gòu)建規(guī)則，不過一般認(rèn)為,，系統(tǒng)架構(gòu)師的主要職責(zé)有： 1） 負(fù)責(zé)領(lǐng)導(dǎo)和協(xié)調(diào)整個項目中的技術(shù)活動 2） 在個人綜合素養(yǎng)方面,，系統(tǒng)構(gòu)架師應(yīng)該具有領(lǐng)導(dǎo)才能，能夠在壓力下作出關(guān)鍵性的決策并善始善終,； 3） 能夠贏得項目經(jīng)理,、客戶、用戶群體以及管理團(tuán)隊的認(rèn)同和尊敬,，尤其要善于和項目經(jīng)理緊密協(xié)作,； 4） 在各個方面都能展現(xiàn)出面向目標(biāo)的實(shí)干作風(fēng)。在專業(yè)技能方面，與其他角色相比,，系統(tǒng)構(gòu)架師通常具有全方位的技能,，其見解重在廣度，而不是深度,。 5） 系統(tǒng)構(gòu)架師不僅需要具備設(shè)計師的各項技能,，而且應(yīng)該具有問題領(lǐng)域和軟件工程領(lǐng)域的實(shí)踐經(jīng)驗(yàn)，從而有能力在無法獲得完整信息的情況下迅速領(lǐng)會問題并根據(jù)經(jīng)驗(yàn)作出審慎的判斷,。 6） 如果項目較大,，系統(tǒng)構(gòu)架師將是一個團(tuán)隊，上述的關(guān)鍵素質(zhì)要求可由團(tuán)隊成員來分擔(dān),，但其中要有一名系統(tǒng)構(gòu)架師具有足夠的權(quán)威,。 架構(gòu)師與設(shè)計師的職責(zé)有所不同，最重要的是架構(gòu)師工作的關(guān)注點(diǎn)是軟件系統(tǒng)的全局問題,，他是制定軟件系統(tǒng)的規(guī)則和原則的,，對整個軟件系統(tǒng)進(jìn)行規(guī)劃；設(shè)計師相對來說是關(guān)注軟件系統(tǒng)的局部和具體問題,，把架構(gòu)師的架構(gòu)設(shè)計進(jìn)行細(xì)化,。 架構(gòu)師是由國外引進(jìn)的一個概念，國外軟件開發(fā)的幾個職位是技術(shù)官,、架構(gòu)師,、設(shè)計師、開發(fā),、測試,，對應(yīng)我們公司應(yīng)該是技術(shù)總監(jiān)、架構(gòu)師,、系統(tǒng)分析員,、程序員、測試人員,。 1.4. 常用架構(gòu)設(shè)計模式 很多OO設(shè)計原則和設(shè)計模式同樣適用與架構(gòu)設(shè)計,，架構(gòu)中使用這些原則的主要目的是為了使架構(gòu)具有更好的可維護(hù)性和可復(fù)用性，并使架構(gòu)具有穩(wěn)定性,，這些目的也是一個架構(gòu)的核心價值所在,。 模式的定義也不統(tǒng)一，一般是這樣的解釋,，每個模式描述了一個在我們周圍不斷重復(fù)發(fā)生的問題以及該問題解決方案的核心,。（在古代流傳至今的“三十六計”就是三十六個模式，對中國人來說,，這可能是讓人最容易理解模式概念的一個類比,。）使用模式能夠減少設(shè)計的難度,，更能加快設(shè)計人員之間交流和溝通。 以下是幾個常用的頂層架構(gòu)設(shè)計的模式 1) 分層模式 2) MVC模式 3) 客戶/服務(wù)器模式 4) 流程處理模式 這些模式的介紹在8月24日發(fā)的郵件――《軟件架構(gòu)基礎(chǔ)知識.doc》中都有清晰的解釋,，這里不在贅述,。 1.5. AOP AOP是OOP的延續(xù)，是Aspect Oriented Programming的縮寫,，意思是面向方面編程,。AOP實(shí)際是GoF設(shè)計模式的延續(xù)，設(shè)計模式孜孜不倦追求的是調(diào)用者和被調(diào)用者之間的解耦,，AOP可以說也是這種目標(biāo)的一種實(shí)現(xiàn),。AOP是近兩年比較熱門的技術(shù)，給我們帶來了一個新的視角和軟件架構(gòu)方法,。 通過使用AOP技術(shù),，可以把分散在多個模塊中共同的行為分離出來統(tǒng)一編程，減少重復(fù)代碼,。 AOP和OO,、SOA一樣，都是架構(gòu)設(shè)計中的重要視角,。 1) 基本原理 AOP機(jī)制一般都需要開發(fā)語言和編譯器支持,，Java和.C#都支持。實(shí)現(xiàn)AOP有不同的方法,，常見的方法是利用代理機(jī)制,，其基本原理是為“其他對象提供一種代理，以控制對這個對象的訪問”,。 2) 常見使用AOP技術(shù)的地方 n Authentication 權(quán)限驗(yàn)證 n Caching 緩存 n Context passing 內(nèi)容傳遞 n Error handling 錯誤處理 n Lazy loading 懶加載 n Debugging 調(diào)試 n logging, tracing, profiling and monitoring 記錄跟蹤 優(yōu)化 校準(zhǔn) n Performance optimization 性能優(yōu)化 n Persistence 持久化 n Resource pooling 資源池 n Synchronization 同步 n Transactions 事務(wù) 3) AOP也可以用于封裝業(yè)務(wù)邏輯 比如,，進(jìn)銷存軟件中，更多模塊的功能操作都需要重新計算庫存,，所以可以把庫存計算分離出來,，用AOP技術(shù)偶合到那些功能模塊中,。 在業(yè)務(wù)功能模塊中用AOP技術(shù)很多情況下都不是很經(jīng)濟(jì),，因?yàn)闃I(yè)務(wù)邏輯復(fù)雜多變，可能經(jīng)過仔細(xì)分析抽取出共性代碼會因?yàn)橐粋€需求變化而變得不再適用,，不如用普通方法實(shí)現(xiàn)需求變化來得方便和簡單,。因此，AOP技術(shù)在做基礎(chǔ)框架平臺,、組件容器時用得比較多,。 1.6. SOA 1) 什么是SOA 關(guān)于SOA，可以找到很多的文章從不同的角度來描述它,，不同的軟件提供商也有不同的定義方式,。每個人都可以從不同的視角來理解SOA，從程序員的角度，SOA是一種全新的開發(fā)技術(shù),，新的組件模型,，比如說Web Service；從架構(gòu)設(shè)計師的角度,，SOA就是一種新的設(shè)計模式,，方法學(xué)；從業(yè)務(wù)分析人員的角度,，SOA就是基于標(biāo)準(zhǔn)的業(yè)務(wù)應(yīng)用服務(wù),。 Service-architecture.com將SOA定義為：“本質(zhì)上是服務(wù)的集合。服務(wù)間彼此通信,，這種通信可能是簡單的數(shù)據(jù)傳送,，也可能是兩個或更多的服務(wù)協(xié)調(diào)進(jìn)行某些活動。服務(wù)間需要某些方法進(jìn)行連接,。所謂服務(wù)就是精確定義,、封裝完善、獨(dú)立于其他服務(wù)所處環(huán)境和狀態(tài)的函數(shù),。” Looselycoupled.com將SOA定義為：“按需連接資源的系統(tǒng),。在SOA中，資源被作為可通過標(biāo)準(zhǔn)方式訪問的獨(dú)立服務(wù),，提供給網(wǎng)絡(luò)中的其他成員,。與傳統(tǒng)的系統(tǒng)結(jié)構(gòu)相比，SOA規(guī)定了資源間更為靈活的松散耦合關(guān)系,。” Gartner則將SOA描述為：“客戶端/服務(wù)器的軟件設(shè)計方法,，一項應(yīng)用由軟件服務(wù)和軟件服務(wù)使用者組成……SOA與大多數(shù)通用的客戶端/服務(wù)器模型的不同之處，在于它著重強(qiáng)調(diào)軟件組件的松散耦合,，并使用獨(dú)立的標(biāo)準(zhǔn)接口,。” 從概念的角度，SOA是一種構(gòu)造分布式系統(tǒng)的方法,，它將業(yè)務(wù)應(yīng)用功能以服務(wù)的形式提供給最終用戶應(yīng)用或其他服務(wù),。 2) SOA架構(gòu)有哪些基本的要求： n SOA在相對較粗的粒度上對應(yīng)用服務(wù)或業(yè)務(wù)模塊進(jìn)行封裝與重用； n 服務(wù)間保持松散耦合,，基于開放的標(biāo)準(zhǔn),， 服務(wù)的接口描述與具體實(shí)現(xiàn)無關(guān)； n 靈活的架構(gòu) －－服務(wù)的實(shí)現(xiàn)細(xì)節(jié),，服務(wù)的位置乃至服務(wù)請求的底層協(xié)議都應(yīng)該透明,； 3) 架構(gòu)設(shè)計中的SOA視角 在架構(gòu)設(shè)計中，SOA是一個非常重要的視角,。SOA以一種粗粒度的角度去分解系統(tǒng)的不同功能,，去分析不同功能服務(wù)之間的關(guān)系和接口,，不同功能服務(wù)之間是松散偶合的。SOA也是解決不同系統(tǒng)功能集成和異構(gòu)系統(tǒng)之間功能互用的一個比較不錯的解決辦法,。 一般提到SOA時,，都會把它和Web Service聯(lián)系到一起，因?yàn)槟壳癢eb Service是最能表達(dá)SOA架構(gòu)的技術(shù),。 4) SOA的引申 SOA的出現(xiàn)應(yīng)該說是一個必然的過程,，是軟件行業(yè)發(fā)展中必然會出現(xiàn)的一個概念。軟件一開始是一些代碼行,，代碼行多了之后就成了代碼塊或者叫子程序,，然后就繼續(xù)發(fā)展出了函數(shù)，隨著OO的出現(xiàn),，為了便于管理函數(shù)出現(xiàn)了類和類庫,，類庫多到難以管理的時候出現(xiàn)了組件的概念，當(dāng)軟件復(fù)雜到組件這個概念仍現(xiàn)粒度太細(xì)的時候,，就出現(xiàn)了服務(wù)這個概念,，系統(tǒng)架構(gòu)就對應(yīng)出現(xiàn)了SOA概念。由此可以推論,，不久以后,，軟件業(yè)一定還會出現(xiàn)粒度更大的軟件概念，它由多個服務(wù)組成,。 現(xiàn)在是SOA發(fā)展的初級階段,，SOA為在線服務(wù)的商業(yè)模式提供了很好的技術(shù)手段，隨著可用的服務(wù)越來越多,，服務(wù)越來越方便和可靠,，一定會出現(xiàn)很多以服務(wù)（狹義的概念，指軟件的某項功能）進(jìn)行盈利的組織,，一大類是專業(yè)的在線服務(wù)提供商,，提供各種類型的軟件功能，提供服務(wù)租賃,；當(dāng)可用服務(wù)爆炸式增長后,，尋找到合適的服務(wù)會越來越難，這時就會出現(xiàn)另一類公司――在線服務(wù)集成商,，他們對無數(shù)的在線服務(wù)進(jìn)行評測和篩選,，然后按照客戶的需求或行業(yè)的需求提供服務(wù)包解決方案。 1.7. ESB 1) 什么是ESB ESB（Enterprise Service Bug,，企業(yè)服務(wù)總線）是一種在松散耦合的服務(wù)和應(yīng)用之間標(biāo)準(zhǔn)的集成方式。它可以作用于： * 面向服務(wù)的架構(gòu) -分布式的應(yīng)用由可重用的服務(wù)組成 * 面向消息的架構(gòu) - 應(yīng)用之間通過ESB發(fā)送和接受消息 * 事件驅(qū)動的架構(gòu) - 應(yīng)用之間異步地產(chǎn)生和接收消息 通俗地說,，ESB就是在SOA架構(gòu)中實(shí)現(xiàn)服務(wù)間智能化集成與管理的中介,。它與SOA的關(guān)系是：ESB是邏輯上與SOA 所遵循的基本原則保持一致的服務(wù)集成基礎(chǔ)架構(gòu),，它提供了服務(wù)管理的方法和在分布式異構(gòu)環(huán)境中進(jìn)行服務(wù)交互的功能。ESB實(shí)現(xiàn)了SOA三個基本要求中的第三個,。 ESB是特定環(huán)境下(SOA架構(gòu)中)實(shí)施EAI的方式,，應(yīng)為 n 被集成的對象被明確定義為服務(wù)，而不是傳統(tǒng)EAI中各種各樣的中間件平臺 n ESB明確強(qiáng)調(diào)消息(Message)處理在集成過程中的作用 n 事件驅(qū)動成為ESB的重要特征 2) ESB適用場景 ESB應(yīng)該構(gòu)筑在完善的SOA架構(gòu)上,，它應(yīng)該做的事是服務(wù)集成,。它的常見應(yīng)用模式是 n 協(xié)議轉(zhuǎn)換模型，用于當(dāng)服務(wù)的請求者與服務(wù)提供者基于不同協(xié)議時的消息轉(zhuǎn)換情形 n 消息廣播模式,，用于事件驅(qū)動多個動作或者消息廣播的情形 n 服務(wù)匹配模式,，用于需要動態(tài)選擇服務(wù)提供者的情形，例如可以根據(jù)消息的內(nèi)容,，或負(fù)載情況,，或服務(wù)級別約定(SLA)，來為服務(wù)請求者選擇合適的服務(wù) 參考資料：http://www-128.ibm.com/developerworks/cn/webservices/ws-esb1/ 1.8. 區(qū)分出非功能性需求 舉例： 1) 什么是非功能性需求 非功能性需求是這樣一種需求,，它解決“如何使這個系統(tǒng)能在實(shí)際環(huán)境中運(yùn)行”,。 2) 重要嗎？ 在設(shè)計解決方案的過程中滿足功能性需求當(dāng)然是很重要的,。但是,，如果沒有考慮非功能性需求，那么這個解決方案則很難取得實(shí)效,，因?yàn)橛脩艨赡茈y以甚至無法使用系統(tǒng)的功能,。 很多非功能需求一般會在底層的基礎(chǔ)技術(shù)平臺去仔細(xì)設(shè)計和實(shí)現(xiàn)。 3) 非功能性需求要考慮那些方面 非功能性的特性一般有這些： n 可靠性 只顯示系統(tǒng)可以做某些事情是不夠的,。如果一個系統(tǒng)不能可靠地運(yùn)行（例如,，在加載時，或者在系統(tǒng)故障時,，等等）,，則它就不能滿足客戶的需要。 有一些問題應(yīng)該自問一下： * 即使硬件出現(xiàn)故障,，系統(tǒng)也可以可靠運(yùn)行嗎,？ * 復(fù)制和故障轉(zhuǎn)移方案是什么？ * 需要手動干預(yù),，還是系統(tǒng)可以自動進(jìn)行故障轉(zhuǎn)移,？ * 實(shí)現(xiàn)可靠性會對性能造成負(fù)面影響嗎？ * 實(shí)現(xiàn)可靠性的成本有多高,？ 可靠性需要考慮的一些具體方面是： 安全性：假設(shè)攻擊者就在外面,。如何知道系統(tǒng)用戶就是他們所聲稱的，并只讓他們訪問經(jīng)過授權(quán)的功能,？如何保護(hù)我的系統(tǒng)不受攻擊,？考慮到網(wǎng)絡(luò)攻擊,、機(jī)器攻擊，甚至從您自己的系統(tǒng)內(nèi)部發(fā)起的攻擊,。 事務(wù)性：如何設(shè)計系統(tǒng)來保存工作單元的 ACID 屬性,？如果在設(shè)計中涉及多個獨(dú)立的子系統(tǒng)（Web 服務(wù)和 SOA 就是這種情況），則這一點(diǎn)就顯得特別重要,。不要假設(shè)始終可以進(jìn)行兩階段提交 (two phase commit),。 n 可用性 如果用戶不能夠從他們可用的渠道（例如 Web）方便地訪問您的產(chǎn)品，那么它的好處何在呢,？這有時是作為功能性的一部分一起考慮（或者應(yīng)該在理想的環(huán)境下）的,，但是常常被忽視，以致于整個項目處于危險之中,。這里需要考慮的一些問題是： * 您是否為用戶帶來不適當(dāng)?shù)呢?fù)擔(dān)（例如,，需要特殊的瀏覽器版本）？ * 系統(tǒng)是否根據(jù)模型-視圖-控制器 (Model-View-Controller) 體系結(jié)構(gòu)設(shè)計以使多用戶界面成為可能,？如果是這樣,，如何將它們綁定在一起？ * 是否界面本來就有狀態(tài)而功能無狀態(tài)（反之亦然）,？ n 有效性 如果沒有有效地使用資源（例如處理器,、內(nèi)存和磁盤空間），功能性,、可靠性和可用性再好的系統(tǒng)最后都會失敗,。我們經(jīng)常發(fā)現(xiàn)將有效性劃分成兩個子范圍是很有用的，這兩個子范圍都應(yīng)該加以考慮： 性能：這個系統(tǒng)的運(yùn)行情況有多好,？它只是平穩(wěn)緩慢地運(yùn)行嗎,？系統(tǒng)可以達(dá)到其響應(yīng)時間目標(biāo)嗎？應(yīng)用程序的設(shè)計是否符合性能要求,？您利用緩存了嗎,？ 可伸縮性：如果系統(tǒng)在小范圍內(nèi)運(yùn)行看起來相當(dāng)快，那么當(dāng)擴(kuò)展至每秒,、每分鐘或者每小時幾千或成千上萬個活動的時候呢,？它的設(shè)計是否達(dá)到吞吐量目標(biāo)？可以復(fù)制系統(tǒng)來實(shí)現(xiàn)線性擴(kuò)展嗎,？是否存在瓶頸（例如公共數(shù)據(jù)庫）,？ n 可維護(hù)性 這是一個極其重要的需求，因?yàn)槿绻_發(fā)人員,、管理員和操作人員不能夠解決如何管理應(yīng)用程序的問題,，則它在首次發(fā)布之前就會夭折。假設(shè)您是一位管理員，您承 擔(dān)了解決此問題的任務(wù),，那么您如何配置它,？如何監(jiān)視它,？如果您一件事情需要執(zhí)行很多次（例如,，安裝許多應(yīng)用程序），那么會怎么做呢,？您是否有一個可復(fù)制的 部署流程呢,？您是否可以使重復(fù)的任務(wù)自動化，使之在大范圍內(nèi)可行呢,？ n 可移植性 雖然列在最后,，但它并非最不重要。例如,，如何采用標(biāo)準(zhǔn)來提供某種形式的平臺中立性呢,？是否計劃將應(yīng)用程序遷移到您的最新和最高版本的應(yīng)用服務(wù)器上呢？如果不打算這樣做,，則當(dāng)供應(yīng)商撤消對該版本的支持時您要怎么做呢,？如果您的項目基于開放源代碼，則也有類似的問題,。如果每當(dāng)某人有個更好的捕鼠器 (mousetrap) 您就必須重寫整個應(yīng)用程序,，則沒有人會問津。 2. 公司的軟件架構(gòu) 2.1. 技術(shù)戰(zhàn)略 2.1.1. 定位 公司長期的戰(zhàn)略重點(diǎn)在于為電力行業(yè)提供解決方案和各種技術(shù)服務(wù),，因此公司軟件技術(shù)要長期地為電力行業(yè)服務(wù),。所以，公司的技術(shù)體系架構(gòu)的定位是面向電力行業(yè)的企業(yè)級應(yīng)用技術(shù)架構(gòu),。 出于電力行業(yè)市場目前情況和發(fā)展趨勢的綜合考慮,，公司同時發(fā)展JavaEE和.Net技術(shù)，其中JavaEE技術(shù)定位在高端企業(yè)級解決方案,，當(dāng)中的.Net技術(shù)重點(diǎn)在于提供低成本的企業(yè)級應(yīng)用解決方案,。 2.1.2. 技術(shù)依賴性 公司在戰(zhàn)略上提倡擁有自己的核心技術(shù)，同時也提倡快速集成應(yīng)用第三方技術(shù),，因此公司的技術(shù)體系架構(gòu)盡量減少對第三方技術(shù)的依賴性,，應(yīng)該使公司的技術(shù)體系架構(gòu)符合各種國際標(biāo)準(zhǔn)，能夠容易的集成和替換第三方技術(shù),。 2.1.3. 技術(shù)體系的功能復(fù)用 公司同時發(fā)展.Net,、JavaEE、嵌入式三條技術(shù)路線,，為了避免同樣的功能在不同技術(shù)體系下重復(fù)實(shí)現(xiàn),，浪費(fèi)開發(fā)資源，公司的技術(shù)體系架構(gòu)必須充分考慮多個技術(shù)體系功能的復(fù)用能力,，努力使不同技術(shù)體系下應(yīng)用系統(tǒng)能夠使用其他技術(shù)體系下的功能,，也能為其他技術(shù)體系下的應(yīng)用系統(tǒng)提供服務(wù),。 另外，在設(shè)計時,，也更多地體現(xiàn)一些與平臺無關(guān)性的設(shè)計,，以方便不同技術(shù)體系架構(gòu)設(shè)計的成果公用。 2.1.4. 技術(shù)更新的應(yīng)對策略 公司在電力行業(yè)市場上將會長期發(fā)展,，這個戰(zhàn)略重點(diǎn)會保持10年以上的時間,，而技術(shù)的發(fā)展更新?lián)Q代比較快，尤其是Microsoft的技術(shù),。對此,，公司的技術(shù)體系架構(gòu)的應(yīng)對策略是要做到“設(shè)計起點(diǎn)高，發(fā)展前景廣”,。設(shè)計起點(diǎn)高是指在架構(gòu)設(shè)計起始就盡量采用已達(dá)到實(shí)用化的最先進(jìn)的技術(shù),，保證這些技術(shù)有更長的生命周期；發(fā)展前景廣是指設(shè)計時多考慮架構(gòu)的可持續(xù)發(fā)展能力,，使技術(shù)架構(gòu)能夠方便地集成新技術(shù),，替換老技術(shù)。公司的技術(shù)體系架構(gòu)設(shè)計的生命周期應(yīng)在5－10年,。 2.2. 最佳實(shí)踐 說明：分成三個層次,， 最底層是基礎(chǔ)框架層，主要提供對象的管理,、數(shù)據(jù)的存取和轉(zhuǎn)換,、日志、事務(wù)處理等的基礎(chǔ)服務(wù)功能,，通過封裝成企業(yè)服務(wù)接口對上層提供服務(wù),。 中間層次是業(yè)務(wù)領(lǐng)域?qū)哟危谶@層內(nèi)部可以分成業(yè)務(wù)基礎(chǔ)領(lǐng)域?qū)雍碗娏︻I(lǐng)域?qū)?，業(yè)務(wù)基礎(chǔ)層提供了通用領(lǐng)域的業(yè)務(wù)管理服務(wù),，比如文檔處理服務(wù)、工作流處理,、報表處理等,；電力領(lǐng)域?qū)觿t提供了電力行業(yè)相關(guān)的特殊領(lǐng)域模型和服務(wù)，比如基于61970的電網(wǎng)領(lǐng)域,，資產(chǎn)和物資管理領(lǐng)域等,，這一層通過封裝成業(yè)務(wù)功能服務(wù)接口對上層提供服務(wù)。 最上層是展現(xiàn)層,，展現(xiàn)層內(nèi)部也分為兩個層次,，底層是UI處理層，主要作用是管理一些固定化的UI邏輯，根據(jù)各種狀態(tài)選擇前端的用戶界面視圖,。向上是界面層,，按照表現(xiàn)形式分成B/S、C/S,、移動終端三種,。 按照這個架構(gòu)，根據(jù)使用技術(shù)的不同,，可以分為.Net和J2EE兩個實(shí)現(xiàn)版本,。不過,，為了避免重復(fù)開發(fā)又兼顧技術(shù)體系的特殊性,，這三個層次中的基礎(chǔ)架構(gòu)層應(yīng)該用兩種技術(shù)分別實(shí)現(xiàn)出一套框架程序并提供企業(yè)服務(wù)接口，其他兩層的功能可以使用任意的技術(shù)實(shí)現(xiàn),，并且每種功能盡量只實(shí)現(xiàn)一次,，通過集成技術(shù)把不同技術(shù)體系的功能組合成業(yè)務(wù)系統(tǒng)。企業(yè)服務(wù)總線主要解決的問題是提供異構(gòu)系統(tǒng)的功能集成,。 －－－劉愛軍 2006年9月,。 9:48:34 | 添加評論 | 固定鏈接 | 引用通告 (0) | 寫入日志 | 軟件設(shè)計&架構(gòu) 軟件開發(fā)公司技術(shù)管理辦法的一個設(shè)想 （轉(zhuǎn)貼請注明出自xsfox.spaces.live.com） 1. 目的 為了規(guī)范公司軟件技術(shù)的研發(fā)、使用及升級維護(hù)流程,，加強(qiáng)公司對公共軟件技術(shù)的管理,，對公司公用軟件技術(shù)生命周期進(jìn)行有效的控制，提高公司軟件產(chǎn)品的開發(fā)效率和質(zhì)量,。 2. 范圍 1． 公司級公共軟件技術(shù)的研發(fā)和升級維護(hù)過程,。 2． 公司級公共軟件技術(shù)應(yīng)用過程。 3． 公共軟件技術(shù)包括：Delphi,、.Net,、Java、嵌入式開發(fā)4條技術(shù)線的軟件應(yīng)用框架,、外購控件包,、公共基類、通用技術(shù)解決方案,、通用工具軟件,。 3. 職責(zé) 技術(shù)委員會： 1） 發(fā)布公共軟件技術(shù)的某個版本。 2） 甄選和招募技術(shù)委員會成員,。 3） 收集技術(shù)提議,，做出技術(shù)規(guī)劃。 4） 組織軟件技術(shù)人員進(jìn)行公司公共軟件技術(shù)的研發(fā),。 公共軟件技術(shù)研發(fā)項目組： 1） 負(fù)責(zé)公共軟件技術(shù)的技術(shù)論證,、開發(fā)。 2） 對應(yīng)用人員進(jìn)行培訓(xùn)。 3） 跟蹤技術(shù)的發(fā)展,，解決技術(shù)應(yīng)用中的問題,。 應(yīng)用系統(tǒng)軟件項目組： 負(fù)責(zé)實(shí)施和應(yīng)用公共軟件技術(shù)，對應(yīng)用情況進(jìn)行反饋,。 4. 控制流程 1． 技術(shù)規(guī)劃 1） 技術(shù)委員會平時負(fù)責(zé)收集整理公司范圍內(nèi)的軟件技術(shù)的自主研發(fā),、技術(shù)升級擴(kuò)展或技術(shù)外購的提議。 2） 每年定期（經(jīng)理會期間）,，技術(shù)委員會組織人員對收集整理的提議進(jìn)行評估篩選,，確定下階段軟件技術(shù)研發(fā)的重點(diǎn)，并制定研發(fā)任務(wù),。 3） 對于急需技術(shù)的提議,，技術(shù)委員會隨時組織人員進(jìn)行評估篩選，安排研發(fā)任務(wù),。 2． 技術(shù)論證 1） 確立研發(fā)任務(wù)后,，技術(shù)委員會甄選合適人員作為某項技術(shù)的技術(shù)研究員，對確定的研發(fā)任務(wù)進(jìn)行技術(shù)論證和試驗(yàn),。 2） 技術(shù)研究員收集和驗(yàn)證某項技術(shù)的技術(shù)資料,，撰寫技術(shù)可行性研究報告，明確技術(shù)自主研發(fā)或采購要求,，人力和時間投入估算,，預(yù)期收益等內(nèi)容。 3） 技術(shù)委員會組織人員對技術(shù)可行性研究報告進(jìn)行評審,，確定技術(shù)研發(fā)的策略,，策略包括取消、繼續(xù)論證,、暫時掛起,、進(jìn)行開發(fā)。 4） 對繼續(xù)論證的技術(shù)重復(fù)1）-3）,，直到次技術(shù)的研發(fā)策略變化,。 5） 如果是由于目前公司資源不足或是目前形勢尚不足以做出判斷，可以讓技術(shù)研發(fā)進(jìn)入暫時掛起狀態(tài),，等待重新提議和評審,。 3． 技術(shù)開發(fā) 1） 對于技術(shù)可研報告評審評定為進(jìn)行開發(fā)的技術(shù)，技術(shù)委員會組織人員進(jìn)行下一步開發(fā)工作,。 2） 技術(shù)委員會甄選人員組成公共軟件技術(shù)研發(fā)項目組,，確定研發(fā)項目任務(wù)目標(biāo)和工期要求，確定項目組負(fù)責(zé)人,。技術(shù)研發(fā)項目組可以并入應(yīng)用系統(tǒng)項目組進(jìn)行管理,。 3） 研發(fā)項目的負(fù)責(zé)人指定詳細(xì)的開發(fā)計劃,，并按計劃進(jìn)行開發(fā)工作，開發(fā)工作包括設(shè)計,、編碼,、測試和撰寫開發(fā)文檔。 4） 開發(fā)完成后,，項目負(fù)責(zé)人組織相關(guān)人員對開發(fā)成果進(jìn)行評審,，一般情況下，技術(shù)總監(jiān),、技術(shù)委員會主席以及技術(shù)應(yīng)用的相關(guān)人員要參與評審,。 5） 評審不通過時，需要根據(jù)評審意見進(jìn)行修改,，然后重新評審,。 4． 技術(shù)應(yīng)用 1） 評審?fù)ㄟ^后，研發(fā)項目組負(fù)責(zé)撰寫培訓(xùn)材料,，對應(yīng)用此項技術(shù)的開發(fā)人員進(jìn)行技術(shù)應(yīng)用培訓(xùn),。 2） 如果需要，研發(fā)項目組成員進(jìn)入應(yīng)用系統(tǒng)項目組進(jìn)行有關(guān)開發(fā)工作,。 3） 項目組指定一個此項技術(shù)的負(fù)責(zé)人，項目組解散,。 5． 技術(shù)維護(hù) 1） 技術(shù)負(fù)責(zé)人跟蹤此項技術(shù)發(fā)展,，收集此技術(shù)的應(yīng)用反饋意見，處理Bug,。 2） 技術(shù)應(yīng)用的項目組把技術(shù)的改進(jìn)要求和建議統(tǒng)一提交到技術(shù)負(fù)責(zé)人,，技術(shù)負(fù)責(zé)人根據(jù)收集的反饋和對此項技術(shù)的跟蹤情況，不定期向技術(shù)委員會提交技術(shù)升級提議,。 3） 技術(shù)委員會進(jìn)行合并提議進(jìn)行下一輪技術(shù)規(guī)劃,。 |
|
|
