來自：網上
軟件架構是一種思想，一個系統藍圖，對軟件結構組成的規劃和職責設定。而軟件框架是一個實現，一個半成品，是針對一個特定問題的解決方案和輔助工具。
這一篇講軟件架構和軟件框架在UML設計過程中所起的作用。本系列文章不是專門討論軟件架構和軟件框架的，所以不會深入講怎麼做軟件架構和軟件框架。另一個原因是筆者尚無這個自信能夠在這裏班門弄斧講軟件架構。之所以要講，是因爲在設計過程中，設計類必然會受到軟件架構和框架的約束。從分析類到設計類，軟件架構和框架是不得不考慮的一個重要因素。
軟件架構和軟件框架是一回事兒嗎？相信有相當一部分人搞不清楚這個問題，也會有相當一部分人認爲是一回事兒，只是不同的叫法而已。架構的英文原文是Architecture,而框架呢，則是Framwork。顯然這是兩個完全不同的詞兒。從技術上講，IT有一個職業是架構師，架構師代表了軟件技術人員最高的職業頂峯，卻從沒有聽說過有軟件框架師的。所以肯定的說，軟件架構和軟件框架是兩回事兒。
那麼什麼是軟件架構，什麼又是軟件框架呢？軟件架構是一種思想，一個系統藍圖，對軟件結構組成的規劃和職責設定。而軟件框架是一個實現，一個半成品，是針對一個特定問題的解決方案和輔助工具。因此，架構是一個邏輯的構成，而框架是一個可用的半成品。比如說，J2EE規範描述了一系列邏輯部件，描述了這些部件的職責和它們的規範，約定了這些部件之間交互的接口和協議、標準，規劃出一個如何利用這些邏輯部件來實現一個應用系統的藍圖。J2EE是一個軟件架構。而根據這一設想，各產商開發出了各自的產品，包括開發工具和應用容器，開發者利用這些工具和容器就能方便的開發出符合J2EE規範的應用程序。這些工具和容器就是軟件框架。再比如，MVC是一個設計模式，它將應用程序劃分爲實體，控制和視圖三個邏輯部件，我們可以說它是一個軟件架構。而Strus，JSF，WEBWork等分別以自己的方式實現了這一架構，提供了一個半成品，幫助開發人員迅速地開發一個符合MVC架構的應用程序，我們說Strus,JSF,WEBWork是軟件框架。
在一個商業軟件的開發過程中，如何去設定軟件的架構和框架，在設計過程中，軟件架構和框架又是如何影響設計的呢？
軟件架構在一個商業系統的開發過程中，是由軟件架構師這一角色來完成的。架構師要從很高的角度，根據應用環境，用戶需求，公司技術發展要求等等來對這一個系統作出邏輯的劃分。例如是集中式還是分佈式？採用什麼中間件？採用何種技術體系？應用什麼標準？符合什麼規範？軟件的層次是什麼？傳輸協議是什麼？與公司其它產品如何銜接？如何使公司產生核心競爭力？可見一個架構師對一個公司的重要性。
可惜架構師這一角色在很大程度上被誤解，架構師這一稱謂也被濫用。知道幾個設計模式，用過幾個框架，有過幾箇中間件或應用服務器的經歷，就號稱是架構師了。也難怪有人說架構師己死。掌握以上技能的，在我看來，只是經驗豐富的設計師而已。因爲他能做的，只是應用現成的技術。架構師要做的，是發明J2EE規範，是創造SOA架構，是構架出領先於市場的技術產品，是領導軟件技術潮流，是引導軟件技術發展趨勢。這種差別，就如同科學家和工程師的差別。
因此，在一般的中小企業裏，如果沒有領先於業界的產品，沒有引導了市場的思想，沒有稱霸一方的應用領域，就不需要架構師這個角色，也產生不了架構師。有幾個高級設計師，能緊緊跟住技術潮流，把先進技術玩兒轉並應用到自己的產品裏，也就足夠了。也因此，在一般的商業系統開發過程中，軟件架構這一個領域，最主要的工作是選擇適合自己的現成的軟件架構。換句話說是用好現有的技術。比如，決定採用J2EE架構。再能做的一點，是劃分軟件邏輯層次，決定使用的標準和規範。
作爲例子，一個軟件架構和商業系統開發過程中可以用這樣的形式來表述：
一個軟件架構的表述例子：
此主題相關圖片如下：
有的讀者可能會說，沒什麼難的嘛，我也懂，我們的項目也是這樣做的。呵呵，是的，在很多人心目的，架構師做的可能就是這樣的工作。可是仔細想想，雖然懂得這麼多已經不容易了，可這樣的人並不少見，那不就是滿天都是架構師了麼？雖然這個工作的確是在做軟件架構，可是我認爲並不能稱爲架構師，頂多是高級設計師，懂得如何應用現有技術而已。
好了，軟件架構已經定下來了，現在該由設計師（實際上，絕大多數公司裏的架構工作也是由設計師來做的）來決定每一個層次的具體框架設計了。
下面的例子，是以Entity層作爲例子來表述框架的。
此主題相關圖片如下：
這個例子只給出了靜態圖。爲了讓開發人沒明白這個設計，還應當給出交互圖。例如，如果應用程序增加一個VO，Business層怎麼調用EntityControl，EntityControl如何分解VO，怎麼訪問Relationship,怎麼處理PO，怎麼訪問DBControl層。也就是這些框架基類如何交互來完成業務要求。這個圖筆者就不再繪製了。建議有興趣的讀者設計自己的框架，並自己繪製這些交互圖。自己動手認識會更深。
架構有了，框架也有了，對於設計類來說，架構和框架形成了規範，設計類必須遵守這些規範，並瞭解如何使用框架的接口。當然，這個架構和框架僅僅是一個例子，現實中的架構和框架可不僅僅這一點，考慮的東西會更多，比如日誌如何處理，事務如何處理，異常如何處理。每一個可能又都是一個框架。另外，如果選擇了某一個成熟產商的架構，例如Websphere,Weblogic，可能就不需要自己來設計架構和框架了，這些產品已經提供了。
這一篇就到這裏。下一篇本來是應當講如何從分析類到設計類的，不過覺得好象沒什麼可講，因爲框架既然規定了，並且正常的業務邏輯都已經由框架處理了，分析類轉化成設計類應當是一件水到渠成的事情。
