軟件工程-原文鏈接：http://tech.it168.com/a2009/0902/672/000000672853.shtml

此文章詳細給出了軟件設計的基本概念和用途，文章鏈接：http://www.searchsoa.com.cn/showcontent_32604.htm

前言：

???????? 歷史悠久的建筑科學具有成熟的工程方法論，可以給軟件行業發展和軟件工程學大量的借鑒。建筑設計(Architectural Design )是指建筑物在建造之前，設計者按照建設任務，把施工過程和使用過程中所存在的或可能發生的問題，事先作好通盤的設想，擬定好解決這些問題的辦法、方案，用圖紙和文件表達出來。Architecture一詞（維基百科：Architecture）在軟件工程學領域可譯為軟件體系結構，與此對應的還有FrameWork-軟件框架。

???????? Architecture最主要的Design Force就是處理變更。其次，所有可能的問題都是要在Architecture中考慮：復雜性、功能、性能、技術、所有非功能需要等等，FrameWork給出軟件的主框架設計，服從體系結構的必然要求。

???????? 關于軟件工程方面的論述有一些修改，如有疑問，請訪問原作者.

一：區分度：

?? 1、軟件體系結構和框架的定義

?? ? ? ? 軟件體系結構的英文單詞是“architecture”. Architecture的基本詞義是建筑、建筑學、建筑風格。

???????? 軟件體系結構雖然根植于軟件工程，但還處于一個研究發展的階段，迄今為止還沒有一個為大家所公認的定義。

?????? 《設計模式》中對框架的定義是框架就是一組相互協作的類，對于特定的一類軟件，框架構成了一種可重用的設計。

???????? 軟件框架是項目軟件開發過程中提取特定領域軟件的共性部分形成的體系結構，不同領域的軟件項目有著不同的框架類型。框架的作用在于：由于提取了特定領域軟件的共性部分，因此在此領域內新項目的開發過程中代碼不需要從頭編寫，只需要在框架的基礎上進行一些開發和調整便可滿足要求；對于開發過程而言，這樣做會提高軟件的質量，降低成本，縮短開發時間，使開發越做越輕松，效益越做越好，形成一種良性循環。

???????? 框架不是現成可用的應用系統。是一個半成品，需要后來的開發人員進行二次開發，實現具體功能的應用系統。框架不是“平臺”，平臺概念比較模糊可以是一種操作系統，一種應用服務器，一種數據庫軟件，一種通訊中間件等地那個，因此平臺在應用平臺主要指提供特定服務的系統軟件，而框架更側重了設計，開發過程，或者可以說，框架通過調用平臺提供的服務而起的作用。

???????? 框架不是工具包或者類庫，調用API并不就是在使用框架開發，緊緊使用API是，開發者完成系統的主題部分，并不時地調用類庫實現特定任務。而框架構成了通用的、具有一般性的系統主體部分，二次開發人員只是像做填空一樣，根據具體業務，完成特定應用系統中與眾不同的特殊部分。

??? 2、框架與架構之間的關系

?? ? ?? 框架不是構架（即軟件體系機構）。體系結構確定了系統整體結構、層次劃分，不同部分之間的協作等設計考慮。框架比架構更具體。更偏重于技術涉嫌。確定框架后，軟件體系結構也隨之確定，而對于同一軟件體系結構（比如Web開發中的MVC），可以通過多種框架來實現。

??? 3、框架與設計模式之間的關系

??????? 設計模式和框架在軟件設計中是兩個不同的研究領域。設計模式研究的是一個設計問題的解決方法，一個模式可應用于不同的框架和被不同的語言所實現；而框架則是一個應用的體系結構，是一種或多種設計模式和代碼的混合體雖然它們有所不同，但卻共同致力于使人們的設計可以被重用，在思想上存在著統一性的特點，因而設計模式的思想可以在框架設計中進行應用。

???????? 框架和設計模式存在著顯著的區別，主要表現在二者提供的內容和致力應用的領域。

??? 1)、從應用領域上分，框架給出的是整個應用的體系結構；而設計模式則給出了單一設計問題的解決方案，并且這個方案可在不同的應用程序或者框架中進行應用。

??? 2)、從內容上分，設計模式僅是一個單純的設計，這個設計可被不同語言以不用方式來實現；而框架則是設計和代碼的一個混合體，編程者可以用各種方式對框架進行擴展，進而形成完整的不同的應用。

??? 3)、以第二條為基礎，可以得出設計模式比框架更容易移植：框架一旦設計成形，雖然還沒有構成完整的一個應用，但是以其為基礎進行應用的開發顯然要受制于框架的實現環境；而設計模式是與語言無關的，所以可以在更廣泛的異構環境中進行應用。

???????? 總之，框架是軟件，而設計模式是軟件的知識體，提升框架的設計水平。

二：框架的選擇問題：

通用框架與應用框架：

??????? 如果要對框架進行進一步分類，則可以根據框架針對的領域是否具有通用性而將它們分為通用框架（General Framework）和應用框架（Application Framework）。通用框架可以在不同類型的應用中使用，而應用框架只被使用于某一特定類型的應用中。
??????? 比如，ORM框架NHibernate就是一個通用框架，該框架可以用于所有需要解決O/R映射的各種類型的應用中。而某個金融框架則是一個應用框架，它僅僅被用于金融類型的應用中。
???????? 可以這么說，通用框架所解決的是所有類型的應用都關心的“普遍”問題，而應用框架解決的是某一特定類型的應用關心的問題。所以，如果我們需要將某種類型的應用的核心業務邏輯流程提升到一個框架中，所得到的這個框架就是一個應用框架。與通用框架相比，應用框架需要了解更多目標業務領域內的領域知識。
???????? 在實現具體的應用程序時，可以采用一個應用框架與多個通用框架相結合的方式，這樣有利于快速、高質量的應用程序開發。比如，某個金融領域的一個應用，可以采用金融框架作為應用框架來解決與金融業務邏輯相關的問題，采用Nhibernate解決數據訪問，采用ESFramework解決應用中各分布式系統之間的通信。?

?????? 下圖描述了類庫、框架和應用之間的層次關系。

????????????????????????? 艸！圖呢？？？

??????? 當然，一個應用也可以完全不采用任何框架，而是直接從最基礎的底層API（如.NET Framework）開始構建。對于微型的系統，這種方式或許可行。但對于復雜大型的應用，困難度就可想而知了。

?????? （這便涉及了設計的方式問題，是由頂向下還是從底向上，如果是大型系統，最好是采用由頂向下的設計方法）

1 框架之于應用

? ? ? ?? 當一個應用系統選定了框架之后，我們需要做的就是在框架提供擴展點的地方添加應用的具體邏輯，也就是使用“血”和“肉”來填充這個骨架從而得到一個“有機體”。
? ? ? ?? 由于框架通常都是在實踐中經過反復使用和檢驗的，所以質量有一定的保證，這使得我們用更少的時間、更少的編碼來實現一個更穩定的系統成為可能。當然，框架也不是“銀彈”，它不能解決軟件復雜性的根本問題，但是我們卻通過它向這個終極的理想目標又邁進了一步。
? ? ? ? 有一點需要注意，框架使得我們的系統在有所支撐的同時，它也給出了限制。因為通常當我們確定采用了某一個框架之后，我們就必須在這個框架限制的“框框”之內來構建我們的應用。大多數時候，這不是一個問題，但是如果因為框架的限制而嚴重影響了我們系統目標的實現的時候，我們就需要考慮是否應該放棄這個框架，或者換一個其它的同類型的框架。

??????? 但總的來說，框架的使用還是帶給程序構建者很大的方便。

2 框架設計

??????? 框架使得我們開發應用的速度更快、質量更高、成本更低，這些好處是不言而喻的。然而，面對萬千變化日趨復雜的軟件需求，設計和實現一個高度靈活可復用的框架又談何容易！
??????? 框架源于應用，卻又高于應用。
??????? 框架往往是這樣產生的：我們擁有了開發某種類型應用的大量經驗，我們總結這種類型的應用中共性的東西，將其提煉到一個高的層次中，以備復用。這個“高層次”的東西便是框架的原型。隨著我們經驗的不斷積累，框架也會不斷地完善、發展。
? ? ? ?? 框架是一個實踐的產物，而不是在實驗室中理論研究出來的。所以設計一個框架最好的方法就是從一個具體的應用開始，以提供同一類型應用的通用解決方案為目標，不斷地從具體應用中提煉、萃取框架！然后在應用中使用這個框架，并在使用的過程中不斷地修正和完善。
? ? ? ? 有一點需要特別注意，正如所有的軟件架構設計的要點在于權衡（在這方面有點像藝術），框架的設計也不例外，正如前面提到，框架在為應用提供了一個骨架的同時，也給我們的應用圈定了一個框框，我們只能在這個有限的天地內來發揮。所以，一個好的框架設計應當采用了一個非常恰當的權衡決策，以使框架在為我們應用提供強大支持的同時，而又對我們的應用作更少的限制。權衡，從來就不是一件簡單的事情，但是有很多框架設計的經驗可以供我們參考。

2.1 框架設計經驗、原則

（1）框架不要為應用做過多的假設！?????

????? ?? 關于框架為應用做過多的假設，一個非常具體的現象就是，框架越俎代庖，把本來是應用要做的事情攬過來自己做。這是一種典型的吃力不討好的做法。框架越俎代庖，也許會使得某一個具體應用的開發變得簡單，卻會給其它更多想使用該框架的應用增加了本沒有必要的束縛和負擔。

（2）使用接口，保證框架提供的所有重要實現都是可以被替換的。

???? ?? 框架終究不是應用，所以框架無法考慮所有應用的具體情況，保證所有重要的組件的實現都是可以被替換的，這一點非常重要，它使得應用可以根據當前的實際情況來替換掉框架提供的部分組件的默認實現。使用接口來定義框架中各個組件及組件間的聯系，將提高框架的可復用性。

（3）框架應當簡潔、一致、且目標集中。

???????? 框架應當簡潔，不要包含那些對框架目標來說無關緊要的東西，保證框架中的每個組件的存在都是為了支持框架目標的實現。包含過多無謂的元素（類、接口、枚舉等），會使框架變得難以理解，嘗試將這些對于框架核心目標不太重要的元素轉移到類庫中，可以使得框架更清晰、目標更集中。

（4）提供一個常用的骨架，但是不要固定骨架的結構，使骨架也是可以組裝的。

??????? 比如說，如果是針對某種業務處理的框架，那么框架不應該只提供一套不可變更的業務處理流程，而是應該將處理流程“單步”化，使得各個步驟是可以重新組裝的，如此一來，應用便可以根據實際情況來改變框架默認的處理流程。這種框架的可定制化能力可以極大地提高框架的可復用性。

（5）不斷地重構框架。

? ? ? ?? 如果說設計和實現一個高質量的框架有什么秘訣？答案只有一個，重構、不斷地重構。重構框架的實現代碼、甚至重構框架的設計。重構的驅動力源于幾個方面，比如對要解決的本質問題有了更清晰準備的認識，在使用框架的時候發現某些組件職責不明確、難以使用，框架的層次結構不夠清晰等。

2.2 如何稱得上一個優秀的框架？

????? 一個優秀框架的最主要的特點是：簡單。這種簡單性不是輕而易舉就可以獲得的，正如優秀的框架不是一蹴而就的，達到這種簡單性需要對框架不斷地抽絲、不斷地提煉和完善。簡單的真正原因在于它抓住了要解決的問題的本質。一個優秀的框架通常都具有如下特點：

（1）清晰的、簡潔的、一致的。????

?? ? ? “清晰”指的是框架的結構是清晰的、框架的層次是清晰明朗的、框架中各個類和組件的職責是清晰明確的。

??????? “簡潔”指的是框架中沒有無關緊要多余的元素，而且各個類和組件的職責目標是非常集中的，這正是“高內聚、低耦合”設計原則的體現。

??????? “一致”通常會帶來這樣的好處，框架的使用者在熟悉了框架的一部分后，會非常容易地理解框架的另一部分。“一致”通常體現在命名的規則一致、命名的含義一致、組件的裝配方式和使用方式一致等。

（2）易于使用的

??? ? ? 只有易于使用的框架才會走得更遠。

??????? 正是因為易于使用，框架使用者們才有可能試用這個框架，在試用滿意后才有可能決定采用這個框架。一個框架功能即使再強大，如果難以使用，那么框架使用者們很可能根本就不會有試用這個框架的念頭。

??????? 框架的生命力源于框架一直在不斷地完善和發展，如果沒有人使用這個框架，這個框架便沒有了發展和完善的源動力。正如友好的用戶界面是優秀應用程序不可或缺的重要部分，易于使用也是優秀框架的一個重要特性。

（3）高度可擴展的、靈活的

?? ? ? 框架通過高度可擴展性來應對應用程序的萬千變化。

???? ? ? 沒有任何一個框架可以預料所有應用的需求，萬能的框架是不存在的。企圖設計、實現一個萬能框架的想法是荒誕的。框架必須具有“以不變應萬變”的能力，框架可以通過為應用預留恰當的、足夠的擴展點來做到這一點。

?????? 框架的靈活體現在框架可以根據不同的應用進行不同的組裝和配置，就像框架是專門為當前的應用所訂制的一樣。

（4）輕量的

???????? “輕量”，說的通俗點，就是只為自己需要使用的服務付費，而不需要為自己不需要的服務買單。一個重量級的框架有一個很明顯的特征就是，如果你需要一套完整的套餐服務，那是沒有問題的，框架可以很好的滿足你；但是，如果你只需要這份套餐中的一小塊點心，對不起，框架仍然會強加一個完整的套餐給你，你必須付一整份套餐的費用。
???優秀的框架應當支持使用者“按需所取”的原則，框架使用者可以隨意“點菜”進行組裝來滿足自己的需求。

（5）弱侵入性的

???????? 所謂“弱侵入性”，采用了框架的應用程序可以盡可能的以普通的方式來編寫應用邏輯，而不必為了適應框架不得不使用一些特殊的手法。

???????? 這可能有點難以理解，我們可以舉個例子來簡單說明。在.NET中，實現AOP（面向方面編程）機制的兩種主要方式是使用Proxy和動態代理。使用Proxy實現的AOP框架通常要求那些需要使用AOP截獲功能的類必須繼承自ContexBoundObject；而采用動態代理實現的AOP框架則沒有任何如此侵入性的要求，我們仍可以以最普通的方式來編寫應用邏輯類，這類框架會在運行時根據配置動態地生成目標對象的代理對象來實現AOP截獲。所以我們可以說，采用動態代理方式實現的AOP框架相比采用Proxy實現的AOP框架，具有更弱的侵入性。

? ? ? ? 弱侵入性意味著框架對應用邏輯的干擾更少，由于應用邏輯類都是普通的類，這非常方便應用邏輯在另外一個程序中復用，而另外的程序可能采用了一個完全不同的框架。

三：UML工程組織：http://www.uml.org.cn/rjzl/20044643.htm

?????????? 軟件質量之路（4）：建立核心框架

四：知識構架.學習系統

???? 知識學習系統與軟件構架有很大的相似性。如何有效的構建一個完整的學習框架是一個教育學者日夜探討的問題，如果能發現其中的方法，或許能開始最有效率的學習，解決知識傳承的困難。

?? ? 知識的爆發性增長使其數量看似接近人的學習系統所能承受的極限。專家獲得相當知識水平所需要的年限愈來愈長，而看似沒有更好的方法來解決知識學習的速度問題。只能學習——構建完備系統——出現新問題——重構系統——再完備......如此循環，無窮無盡。

總結

以上是生活随笔為你收集整理的知识工程.Vs.软件构架,框架,设计模式.的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。