摘要: 軟件架構設計編檔之參考文件 閱讀全文
架構師篇
架構師篇
摘要: 目前磁盤存儲市場上,存儲分類(如下表一)根據服務器類型分為:封閉系統的存儲和開放系統的存儲,封閉系統主要指大型機,AS400等服務器,開放系統指基于包括Windows、UNIX、Linux等操作系統的服務器;開放系統的存儲分為:內置存儲和外掛存儲;開放系統的外掛存儲根據連接的方式分為:直連式存儲(Direct-Attached Storage,簡稱DAS)和網絡化存儲(Fabric-Attached Storage,簡稱FAS);開放系統的網絡化存儲根據傳輸協議又分為:網絡接入存儲(Network-Attached Storage,簡稱NAS)和存儲區域網絡(Storage Area Network,簡稱SAN)。由于目前絕大部分用戶采用的是開放系統,其外掛存儲占有目前磁盤存儲市場的70%以上,因此本文主要針對開放系統的外掛存儲進行論述說明。 表一: [url=http://www.wangchao.net.cn/bbsdetail_1782308.html][img]http://images.wangchao.net.cn/images/upload/images/lsdn/121 閱讀全文
摘要: 描述了一經典的架構設計過程,并在此基礎上提出了四層驅動設計模型,在CKM項目中初次進行了實踐,想看的可以下載看看 閱讀全文
摘要: 分層是軟件架構的基本理論。任何軟件在邏輯上都可以分層,也可以適當的映射到物理層次上,至于怎么分,分多少層,要不要分等要看你的軟件領域(每個領域都有一些現成的架構模式可以參考,所謂領域架構),在拿到需求的時候我們習慣上進行水平和垂直的分割,其實分層技術也是一種基本的架構模式 閱讀全文
摘要: 在描述大而復雜的軟件中,最復雜的抽象層次就是軟件架構。因此,在這個抽象層次我們能更好的理解構件組裝原理和交互方式。軟件架構被認為是軟件開發方面的驅動力,他允許指定每層那些方面和模型需要依照架構來設計。早期的架構描述語言 ADL,比較獨立,側重結構抽象層次而忽略行為描述層次、觀念層次和元模型層次。這篇文章描述了適當的“理性的”軟件架構視圖并用 C3 元模型描述(最小的并且完整的描述語言),我們提供了一個機制集合以處理不同層次的不同級別,我也提出了一新的用C3元模型描述的連接件的增強定義。 閱讀全文
摘要: 知識管理是伴隨知識經濟出現的一種創新管理,知識管理要綜合運用戰略、組織、流程、技術、變化等多種措施和管理工具,以富有效率的方式動員組織擁有的一切資源來實現其管理目標。
閱讀全文
閱讀全文
摘要: 基于構件的開發(CBD)觀念已廣泛應用于軟件開發中,便于構件的重用。眾所周知的CBD體系結構有 ActiveX, CORBA, RMI以及 SOAP 等。文章主要通過與傳統軟件開發方法的比較研究支持基于CBD的實踐,同時也評價了面向對象的過程模型以及提出了一種新型的基于 CBD 的軟件開發過程模型,并探討了倉儲的重要概念。 閱讀全文
摘要: 最大化的重用,在體系結構風格和構件方面形成了經驗庫,指導后續軟件開發。可真正實現快速軟件開發,特別是在特定領域中的應用! 閱讀全文
摘要: 這篇文章說的很好,和大家分享一下,可能一些實戰的朋友并不喜歡這種理論的東西,可以不看,這篇文章把軟件體系結構和建筑學類比,形象化了體系結構設計。文章提到算法和數據結構有擴張和取代SA的可能,個人覺得有點欠妥,算法和數據結構畢竟是解決細粒度的問題,而體系結構最初從算法和數據結構脫離出來,形成一抽象的分析層次,就是因為軟件越來越復雜,單憑算法和數據是很難解決問題的。算法數據結構和體系結構應該是屬于不同的層次解決不同的問題罷了。文章也提到了黑盒復用和白盒復用的概念,強調了軟件體系結構設計的意義。不過個人并不同意“軟件體系結構是一個高層次上的抽象,它并不涉及具體的系統結構(比如B/S還是C/S),也不關心具體的實現。”筆者這句話,B/S和C/S 其實是一種設計風格,是軟件體系結構的設計模式,其實模式的目的就是重用。在實際的架構設計中你不僅要可慮體系結構設計風格、框架以及復用構件等等,你也要考慮實現的技術和關鍵點的決策,這些都是需要在開發前期確定的。所以軟件體系結構是高層抽象是不關心實現,但是他要涉及到具體的系統結構。
閱讀全文
閱讀全文
摘要: 由于工作和學習的需要,強制自己這2到3個星期看完40篇論文 閱讀全文
摘要: 當架構模型進行迭代的過程中,必然伴隨著對模型進行修改和改進。我們如何防止對模型的修改,又如何保證對模型進行正確的改進? 閱讀全文
摘要: 分層對現代的軟件開發而言是非常重要的概念。也是我們必須學習的知識。分層的總體思路并沒有什么特別的地方,但是要和自己的開發環境、應用環境結合起來,你還需要付出很多的努力才行。
在完成了分層之后,軟件架構其實已經清晰化了。 閱讀全文
在完成了分層之后,軟件架構其實已經清晰化了。 閱讀全文
摘要: 近來讀了一篇《怎樣成為優秀的軟件模型設計者》的文章,感觸頗深。仔細對比分析,發現原來我自己和周圍的軟件開發人員平常的一些自認為對的做法,有很多是有問題的。 閱讀全文
摘要: 可伸縮性有時候被叫做“非功能性需求”,言下之意是它與功能無關,也就比較不重要。這么說簡直錯到了極點。我的觀點是,可伸縮性是功能的先決條件——優先級為0的需求,比一切需求的優先級都高。
希望以上最佳實踐能對你有用,希望能幫助你從新的角度審視你的系統,無論其規模如何。
閱讀全文
希望以上最佳實踐能對你有用,希望能幫助你從新的角度審視你的系統,無論其規模如何。
閱讀全文
摘要: XXX 作為一名架構師從程序員轉到分析設計員再就爬到了架構師群體。當然架構師也分很多種比如應用級架構師,信息架構師等,從應用級架構師又可進一步發展到企業級架構師和平臺架構師。當然你可能對這些不以為然,但這卻是一個架構師的發展之路。本筆記是在XX培訓時的體會,說實話本人在這領域也是菜的要死,不過我的研究方向是這個,以后繼續努力,請大牛們多多指導。 閱讀全文
摘要: 很多人都看過 DDD, 從2002 年開始在中國開發者社區已經炒的沸沸揚揚,但直到現在有多少家公司是這么做的?實話,我自己沒用DDD,也是用數據庫驅動開發的,即以數據設計為中心,至少從思想上是這樣的。雖然我上一個公司的開發模式是用----- 用例模型-》服務對象-》業務對象-》數據對象----這樣一個過程。但分析的實質還是以數據設計為中心,只能說是弱弱的DDD吧,批著DDD,實則是以數據庫中心。
閱讀全文
閱讀全文
摘要: 網絡上對 restlet 的評判褒貶不一,有的說框架封裝的很好,很有彈性,有的說 rest 架構風格本身是一種簡單的風格,restlet 過設計以使編程過于復雜,其實我倒不覺得 restlet 有什么復雜,相反很簡潔明了,不論他的類結構還是整個體系結構,個人很喜歡,昨天晚上匆匆看看他的文檔和實例,很不錯!本筆記對入門足以! 閱讀全文
摘要: “依賴”是和“變化”緊密聯系在一起的概念。由于依賴關系的存在,變化在某處發生時,影響會波及開去,造成很多修改工作,這就是依賴的危害。可以說,變化是始作俑者,依賴是助紂為虐。 閱讀全文
摘要: 前幾天看完了《領域驅動設計》這本書,本來想寫點東西,看到已有兄弟撰寫,貼過來分享一下。當然上面也只是淺顯的談論了下領域設計的基本內容以及自己的想法,很不錯。可能很多朋友有些迷惑,個人覺得舉一個實際開發項目例子,一步一步的講明,可能會更好些。現在正準備稿件中... 閱讀全文
摘要: 反模式作為一種新視角模式,在表述和指導開發上與傳統設計模式不同,他先提出模式的反面案例,而后在給出重構方案,這在指導開發人員(尤其是新手)不無裨益。本系列筆記為個人學習總結,也希望沒有接觸過反模式的朋友們一起學習進步。 閱讀全文
摘要: 反模式作為一種新視角模式,在表述和指導開發上與傳統設計模式不同,他先提出模式的反面案例,而后在給出重構方案,這在指導開發人員(尤其是新手)不無裨益。本系列筆記為個人學習總結,也希望沒有接觸過反模式的朋友們一起學習進步。 閱讀全文
摘要: 由于[GOF95]是論述軟件模式的著作的第一本,也是OO設計理論著作中最流行的一本,因此有些人常常使用設計模式(Design Pattern)一詞來指所有直接處理軟件的架構、設計、程序實現的任何種類的模式。另外一些人則強調要劃分三種不同層次的模式:架構模式(Architectural Pattern)、設計模式(Design Pattern)、成例(Idiom)。成例有時稱為代碼模式(Coding Pattern)。
這三者之間的區別在于三種不同的模式存在于它們各自的抽象層次和具體層次上。架構模式是一個系統的高層次策略,涉及到大尺度的組件以及整體性質和力學。架構模式的好壞可以影響到總體布局和框架性結構。設計模式是中等尺度的結構策略。這些中等尺度的結構實現了一些大尺度組件的行為和它們之間的關系。模式的好壞不會影響到系統的總體布局和總體框架。設計模式定義出子系統或組件的微觀結構。代碼模式(或成例)是特定的范例和與特定語言有關的編程技巧。代碼模式的好壞會影響到一個中等尺度組件的內部、外部的結構或行為的底層細節,但不會影響到一個部件或子系統的中等尺度的結構,更不會影響到系統的總 閱讀全文
這三者之間的區別在于三種不同的模式存在于它們各自的抽象層次和具體層次上。架構模式是一個系統的高層次策略,涉及到大尺度的組件以及整體性質和力學。架構模式的好壞可以影響到總體布局和框架性結構。設計模式是中等尺度的結構策略。這些中等尺度的結構實現了一些大尺度組件的行為和它們之間的關系。模式的好壞不會影響到系統的總體布局和總體框架。設計模式定義出子系統或組件的微觀結構。代碼模式(或成例)是特定的范例和與特定語言有關的編程技巧。代碼模式的好壞會影響到一個中等尺度組件的內部、外部的結構或行為的底層細節,但不會影響到一個部件或子系統的中等尺度的結構,更不會影響到系統的總 閱讀全文
摘要: 對軟件體系結構風格的研究和實踐促進了對設計的復用,一些經過實踐證實的解決方案也可以可靠地用于解決新的問題。體系結構風格的不變部分使不同的系統可以共享同一個實現代碼。只要系統是使用常用的、規范的方法來組織,就可使別的設計者很容易地理解系統的體系結構。例如,如果某人把系統描述為"客戶/服務器"模式,則不必給出設計細節,我們立刻就會明白系統是如何組織和工作的。 閱讀全文
摘要: 最近好多朋友問我關于 SSO 的問題,其實市面上有很多成型的產品,SSO 理論本身也提和好多年了,下面是我以前寫的一篇文章《基于 Web 的單點登錄理論研究》里的一部分關于跨域和票據設計問題,相信對問我的朋友們有些幫助。
閱讀全文
閱讀全文
摘要: 目前軟件體系結構的現狀如何呢?軟件體系結構的發展趨勢又是什么呢?這就是本文要介紹的內容。
目前,軟件體系結構尚處在迅速發展之中,越來越多的研究人員正在把注意力投向軟件體系結構的研究。用于對軟件體系進行規格描述的模型、標記法和工具仍很不正規。盡管這些不正規的模型是有用的,為使之更為精確和健壯,在很多方面的研究工作還需要繼續進行。
閱讀全文
目前,軟件體系結構尚處在迅速發展之中,越來越多的研究人員正在把注意力投向軟件體系結構的研究。用于對軟件體系進行規格描述的模型、標記法和工具仍很不正規。盡管這些不正規的模型是有用的,為使之更為精確和健壯,在很多方面的研究工作還需要繼續進行。
閱讀全文
摘要: 最近晚上抽出點時間寫了這篇文章,關于 Flex 開發方面的語言和架構,按照嚴格分層,高解耦合性并結合 Flex 技術實驗了一個用戶管理小模塊,案例不是目的。本文第一部分介紹 Flex 相關技術以及 ActionStript3.0 語言。第二部分介紹開發實例的開發過程,代碼可以下載。由于本人 flex 經驗不足,在以后的工作中會不斷補充。 閱讀全文
摘要: 每次設計新東西的時候,總要到 google 是去找或參考設計模式的書,比如 GOF 的。有時努力的去找些簡單的模式卡片似乎很難,不過終于找的了,是位外國朋友做的,目前只是 GOF 的23個模式圖例,其他的經典模式,我會陸續補上。 閱讀全文
摘要: 單點登錄(Single Sign On , 簡稱 SSO )是目前比較流行的服務于企業業務整合的解決方案之一, SSO 使得在多個應用系統中,用戶只需要登錄一次就可以訪問所有相互信任的應用系統。CAS(Central Authentication Service)是一款不錯的針對 Web 應用的單點登錄框架,本文介紹了 CAS 的原理、協議、在 Tomcat 中的配置和使用,對于采用 CAS 實現輕量級單點登錄解決方案的入門讀者具有一定指導作用。 閱讀全文
摘要: SOA作為一種IT架構已經廣受業界追捧,幾乎所有的大廠商都加入了有關SOA的開發之中.有關SOA將能夠帶來的激動人心的一切,也在這幾年的宣傳中眾所周知.如何轉向SOA,如何實現SOA,成為討論得最多的話題. 閱讀全文
摘要: 一年閃光似的就過去了,至今依舊保留著老師接受我做為弟子時的那份激動,很感激王老師在這一年給我的關懷與幫助,讓我學到很多很多。因為我是從公司里出來的,學習目標很明確,技術上我有較強的自學能力,管理上我比較欠缺,所以這一年刻意學了些管理方面的知識,比如和余世維博士學習企業管理;和曾仕強學習中國式管理等等。總之,這一年進步很快,加上自己的努力,在技術,基本知識以及管理方面都有很大的進步,也受到同學和老師的表揚,在技術上:J2EE 13 種技術,尤其是 EJB,JMS,RMI,CORBA等中間件的學習,分布式數據處理,流媒體技術(實做一流媒體播放器),SOA,架構體系,以及Linux, C++, C#.net,DCOM 等等的學習使我的知識面更廣了。基礎知識:學習了算法分析,工程數學,最優化,數據挖掘,分布式數據處理,中間件,管理經濟學,高級計算機網絡,高級軟件開發過程等基礎知識。管理方面,除了和老師學習項目管理之外,每天都看視頻,有的可以使我聯想起以前的工作經驗,使我受益匪淺 閱讀全文
摘要: 對于String s = "haha" ,它的虛擬機指令:
0: ldc #16; //String haha
2: astore_1
3: return
對于上面虛擬機指令,其各自的指令流程在《深入JAVA虛擬機》這樣描述到(結合上面實例):
ldc指令格式:ldc,index
ldc指令過程:
要執行ldc指令,JVM首先查找index所指定的常量池入口,在index指向的常量池入口,JVM將會查找CONSTANT_Integer_info,CONSTANT_Float_info和CONSTANT_String_info入口。如果還沒有這些入口,JVM會解析它們。而對于上面的hahaJVM會找到CONSTANT_String_info入口,同時,將把指向被拘留String對象(由解析該入口的進程產生)的引用壓入操作數棧。
astore_1指令格式:astore_1
astore_1指令過程: 閱讀全文
0: ldc #16; //String haha
2: astore_1
3: return
對于上面虛擬機指令,其各自的指令流程在《深入JAVA虛擬機》這樣描述到(結合上面實例):
ldc指令格式:ldc,index
ldc指令過程:
要執行ldc指令,JVM首先查找index所指定的常量池入口,在index指向的常量池入口,JVM將會查找CONSTANT_Integer_info,CONSTANT_Float_info和CONSTANT_String_info入口。如果還沒有這些入口,JVM會解析它們。而對于上面的hahaJVM會找到CONSTANT_String_info入口,同時,將把指向被拘留String對象(由解析該入口的進程產生)的引用壓入操作數棧。
astore_1指令格式:astore_1
astore_1指令過程: 閱讀全文
摘要: 分布式系統其實就是進程集,進程之間本質上是通過消息傳遞的,只不過在我們這個抽象層次,看到的都是對象,似乎就像單進程引用一樣,很多技術比如 CORBA, RMI, DCOM, EJB 都抽象到了對象這一層,屏蔽了底層細節! 既然分布式都是一樣的,那么為什么有這么都技術,一. 應用的領域不同。二. 抽象的層次不同,其實人們為什么去抽象一些東東,應該是關注點的轉移,比如 SOA 的提出,就是將對象或組件的關注點轉移到了業務這個層面!
閱讀全文
閱讀全文
摘要: 去年由于項目的需要,研究了下軟件架構設計,讀了些書和論文,以前認為架構師做的工作不太多,看完之后,感覺自己和架構師還有一段路程,筆者認為架構師不僅要熟悉技術和業務,更重要的是要有自己的思想,架構設計在我看來,他不是技術,而是一種藝術。我喜歡藝術,我熱愛架構,以前在自己的學習道路上總是渺茫,似乎現在找到了方向。 閱讀全文
摘要: 今天偶爾在 rocket (http://www.aygfsteel.com/rocket/archive/2008/05/25/202709.html)的 blog上看到這篇隨筆,
《感慨于我們的技術土壤》,頗有感觸,和大家分享一下。
閱讀全文
《感慨于我們的技術土壤》,頗有感觸,和大家分享一下。
閱讀全文
摘要: 本文通過對JVM的體系結構的深入研究以及一個Java程序執行時虛擬機的運行過程的詳細分析,意在剖析清楚Java虛擬機的機理。 閱讀全文
摘要: 要開發出用戶滿意的軟件并不是件容易的事,軟件架構師必須全面把握各種各樣的需求、權衡需求之間有可能的矛盾之處,分門別類地將不同需求一一滿足。本文從理解需求種類的復雜性談起,通過具體案例的分析,展示了如何通過RUP的4+1視圖方法,針對不同需求進行架構設計,從而確保重要的需求一一被滿足 閱讀全文
摘要: 最近做項目準備引入 CRC 模型,可以很好的加強用戶和開發方的溝通,以便準確的獲得需求。 閱讀全文
摘要: 先推薦一本書:《軟件架構設計》溫昱著。今天剛拿到這本書,非常高興。這本書非常好,它對軟件架構描述得非常清晰,理論包含了很多實踐的例子,看上去很爽呀,嘿嘿。
閱讀全文
閱讀全文
摘要: 今日去導師公司拜聽了 H3C 產品經理的 IP 存儲方案報告,真是受益匪淺。最近也在搞系統架構
方面的東西,真是頗有體會,不由之中想在這里總結下,以備翻看。 閱讀全文
方面的東西,真是頗有體會,不由之中想在這里總結下,以備翻看。 閱讀全文
摘要: 作為應用系統的負責人,一直被要求"要少花錢多辦事"----用更少的硬件,更少的網絡帶寬,以及更短的時間完成更多的任務。J2EE通過提供組件方式和通用的中間件服務是目前首選的最優方式。而要能夠構建一個具有高性能和可擴展性的J2EE應用,需要遵循一些基本的架構策略 閱讀全文
摘要: N條1000M光纖,N個服務器級的硬盤組成陣列, 當然快! 閱讀全文