架構設計軟體
軟體系統架構設計方法步驟
基於體系架構的軟體設計模型把軟體過程劃分為回體系架構需求、設計、文檔化答、復審、實現和演化6個子過程，現逐一簡要概述如下。
體系架構需求。即將用戶對軟體系統功能、性能、界面、設計約束等方面的期望（即「需求」）進行獲取、分析、加工，並將每一個需求項目抽象定義為構件(類的集合)。
體系架構設計。即採用迭代的方法首先選擇一個合適的軟體體系架構風格(如C/S、B/S、N層、管道過濾器風格、C2風格等)作為架構模型，然後將需求階段標識的構件映射到模型中，分析構件間的相互作用關系，最後形成量身訂做的軟體體系架構。
體系架構文檔化。即生成用戶和研發人員能夠閱讀的體系架構規格說明書和體系架構設計說明書。
體系架構復審。即及早發現體系架構設計中存在的缺陷和錯誤，及時予以標記和排除。
體系架構實現。即設計人員開發出系統構件，按照體系架構設計規格說明書進行構件的關聯、合成、組裝和測試。
體系架構演化。如果用戶需求發生了變化，則需相應地修改完善優化、調整軟體體系結構，以適應新的變化了的軟體需求。
『貳』 如何描述一款產品的軟體架構設計
作為一名多次做過報告的架構設計師，我給出一些我的看法。
如果可以使用圖形的話，給你兩個方案：第一是使用專業圖形，如UML圖，頂層架構圖，時序圖（好吧，這個包含於UML）等。非常適合專業人士之間交流。第二是使用XMIND（或者類似軟體），站在產品角度，通過XMIND來描述產品各個模塊功能及聯系。
如果不可以使用圖形的話，也給你兩個方案：第一是你的受眾（就是看你報告的人）的專業素養較高，那麼你可通過將系統進行業務的拆分（橫+縱），如Web服務端的接入層，應用層，服務層，數據層等方式進行分層匯報。第二是你的受眾的專業素養較低，那你需要從多個維度來對你的系統架構進行描述，並做出一些生動的例子輔證。
當然，最好的方式就是圖形加一定的文字描述。如果時間充裕的話，你還可以建立對應動態圖片，來說明。
（純手打，如果幫助到你，希望點個贊。）
『叄』 用什麼工具畫 軟體架構設計圖
1、Microsoft Office Visio
Office Visio 是office軟體系列中的負責繪制流程圖和示意圖的軟體，是一款便於IT和商務人員就復雜信息、系統和流程進行可視化處理、分析和交流的軟體。
2、ProcessOn
是一款網頁版的在線作圖工具，優點是無需下載安裝、破解這些破事，同時支持在線協作，可以多人同時對一個文件協作編輯，而且上手比較容易，它提供很多流程圖模版，可以方便的畫出流程圖、思維導圖、原型圖、UML圖。
3、OmniGraffle
OmniGraffle可以用來繪制圖表，流程圖，組織結構圖以及插圖，也可以用來組織頭腦中思考的信息，組織頭腦風暴的結果，繪制心智圖，作為樣式管理器，或設計網頁或PDF文檔的原型。只能於運行在Mac OS X和iPad平台之上。
4、億圖
是一款基於矢量的繪圖工具，包含大量的事例庫和模板庫。可以很方便的繪制各種專業的業務流程圖、組織結構圖、商業圖表、程序流程圖、數據流程圖、工程管理圖、軟體設計圖、網路拓撲圖等等。
5、Axure RP
Axure RP是美國Axure Software Solution公司旗艦產品，是一個專業的快速原型設計工具，讓負責定義需求和規格、設計功能和界面的專家能夠快速創建應用軟體或Web網站的線框圖、流程圖、原型和規格說明文檔。
『肆』 如何進行軟體系統概要設計及總體架構設計
其實，我覺得你不必要拘泥在那幾個什麼設計的稱謂上。
做軟體和蓋樓一樣，都要先規劃版框架，再權細摳內容，最後一磚一石的去做。
至於你管這個前期的整體規劃叫什麼，那都行。如果你只是想在同事中找共同語言，那大家叫它什麼，你就跟著叫就行了。
很簡單，不必拘泥。
『伍』 什麼是軟體系統架構設計
「架構」一詞最早來自建築學，原意為建築物設計和建造的藝術。但是在軟體工程領域，軟體架構不是一個新名詞，只是在早期的著作中人們將軟體架構稱為軟體體系架構。這就是架構的概念。所謂架構，就是人們對一個結構內的元素及元素間關系的一種主觀影射的產物。
系統架構的主要任務是界定系統級的功能與非功能要求、規劃要設計的整體系統的特徵、規劃並設計實現系統級的各項要求的手段，同時利用各種學科技術完成子系統的結構構建。
在系統架構中，由於對軟體越來越深入的依賴，軟體架構的任務也體現出重要的作用。而且系統架構與軟體架構是緊密聯系和相互依賴的。
1997年，Eberhadrt Rechtin 與MarkW Maier 在其論著中，為計算機科學總結了系統架構方面的實踐成果，從而奠定了系統科學和系統架構在計算機科學中的基石：
無論何種系統架構應用領域，目的都是一樣的，即完整地、高一致性的、平衡各種利弊的、有技術和市場前瞻性的設計系統和實施系統。
『陸』 架構師必看：談軟體架構師如何做好架構設計（
此文轉載至：帳前卒
1 前言
軟體架構設計是軟體設計的一部分，相當於總體設計，是軟體設計過程中一個決定性的環節，架構確定了，軟體基本也就定型了。而軟體架構師則是軟體項目的領軍人物，是軟體設計過程中最具挑戰性的角色，從技術角度來講，他承擔了項目的成敗責任。
EEEC給「架構師」的定義為「軟體架構師是技術主管」，這就意味著他不僅要有高超的技術才能，還要有很好的領導才能，他的領導能力在團隊中和軟體質量控制中起著十分重要的作用。作為一個架構師，他要掌握整個軟體項目的前景，調節各小組間關系，要讓所有的項目組成成員了解大家共同的目的和目標，並發布標准和章程；要能正確理解軟體過程，要在宏觀上擁有專業知識，應該擁有很好的設計技巧；要是一個很好的溝通員和談判代表，要能做出正確的決策等，除此，還有許多他要具備的其它素質。
2. 做好需求調研和分析
為保證軟體的可用性，要從需求出發設計架構，即：做軟體先做需求，這是軟體業內人士的共識，但這項工作做得好的卻很少。根據調查，屬於需求分析和軟體設計錯誤與缺陷的約占軟體錯誤與缺陷的64%；而屬於程序代碼錯誤的僅佔36%；而因軟體錯誤積累與放大效應，造成整個軟體項目拖延或失敗情況的高達20%～60%。這些數據表明，搞好需求調研和分析是軟體設計和開發的第一步。架構師必須要在需求調研的初期就介入，以保證需求獲取的及時、可靠、准確，並對下步工作起指導作用。進行需求調研，不能就事論事，對用戶的需求調研要全面、細致。需求要進行全局性的分析，需要有全局的觀點，而不是分散地、根據具體的應用開發而進行的調研，這樣才能系統地、本質地、概括地把握軟體的功能結構。在調研過程中，自始至終都要有用戶方的業務人員參加，尤其是強調高層管理人員的重視和親自參與，架構師及其相應的工作小組要有足夠的溝通和理解能力，要能使業務人員在需求調研階段起主導作用，架構師僅起協助和引導作用，並提供需求調研的科學方法和過程。
2.1 熟悉建設單位，定義職能域
在需求調研階段，架構師首先要全面了解用戶中所有人員的需求，首先要了解建設單位的組織機構、業務關系，並根據建設單位中的一些主要業務活動領域，研究定義職能域，這是第一重要任務。職能域是用戶功能規劃的抽象，應符合建設單位內部各種業務的邏輯關系，而不是現行機構部門的翻版，一經識別，就要保持相對穩定。研製職能域模型時，需要特別注意，要自頂向下規劃，並把握好設計職能域的數目；注意用戶需求的主次關系，按照重要性、優先順序進行權衡取捨。
2.2 詳細調研各項業務過程及其功能分解
每個職能域都包括一定數目的業務過程，業務過程可以繼續分解為業務活動（對應於未來的軟體功能），每個功能再分解為更低層的功能，逐級向下分解，直到產生最基本的、不可再分的最小功能單元。
職能域和業務過程都要獨立於當前的組織機構，因為組織機構可能變化，部門的分工也會變化，但整個單位的基本職能和業務相對穩定。職能域或業務過程可能橫跨兩個或多個業務部門。業務過程的確定可以對照組織機構中各部門負責人的職責來考慮，這樣，也可能獲得未來軟體的操作許可權、數據許可權的分配和功能模塊的劃分，這些業務過程是一個單位運作的基本工作，不受報告層次和具體負責人變動的影響。
調研前，架構師要對調研的內容事先准備，針對不同管理層的用戶詢問不同的問題，列出問題清單，將操作層、管理層、決策層的需求既聯系又區分開來，形成一個金字塔，使下層滿足上層的需求。調研時，要收集用戶工作中涉及的所有內容，如各種單據、報表、處理規則，再將其串成流程圖，以流程圖為主線，同時把握以下方面：
（1）該流程中是否存在不必要的環節；
（2）流程是否可以簡化，是否可以省略一些環節；
（3）流程中的每個處理環節是否起到了增值提效的作用；
（4）哪些流程可以並行處理。
2.3 在調研具體業務時工作小組要把握的重點
（1）平均頻度
業務發生的頻繁程度稱為頻度，這個數字可以是一個平均值或統計值。頻度越高，數據量越大，對響應時間、易操作性等要求就越高。在數據存儲時，對大頻度的業務或單據要進行充分的考慮。
（2）高峰期的頻度
必須保證軟體在高峰期的響應時間，對軟體進行測試時，要模擬高峰期的業務頻度。
（3）單據要求
單據上的內容也就是單據的屬性，它是進行數據結構設計的最基本依據。數據的精度是定義資料庫中欄位長度的依據；計算生成方法是設計演算法的依據；取值范圍與計算生成方法是數據完整性檢測的依據。
（4）利於減輕工作量
減輕人員的工作量是採用新軟體的一個目的，花費時間最多、處理方法最復雜的地方往往是軟體最關鍵的地方，也是用戶將來驗收時最關心的地方。實際上有很多報表由於工作量相當大，用戶沒有足夠的人力與時間來進行處理，這時他便想到了計算機。
（5）單據報表流程
要了解單據或報表的來源、單據聯數、每聯用途、送交單位、送交時間，對來源與去向的追蹤可以調查出各個業務、各個單據、各個報表及各個部門之間的聯系。
（6）特殊情況的處理與糾錯
對於特殊情況的處理，體現了軟體靈活性，但這其中也隱含著安全危機。用戶領域中有很多「合理但不合法，不合理也不合法」的特殊情況，它們出現的機會比較少，在調研時要將這些易遺漏的問題挖掘出來，這些特殊情況有時是軟體必須要處理的。
當用戶在某個作業環節出現失誤時，手工軟體有的採用正規的手續進行糾錯，有的則相當隨便，這些情況出現的概率也很小，在調研時，可採用窮舉的方法，假定在每一個環節都出現失誤，逐個環節詢問用戶的處理方法，防止遺漏。這些細節如果不調研清楚，往往會對軟體產生深遠的影響。
（7）考慮長遠
將來用戶需求的變化是很正常的現象，如果僅僅著眼於現在，而不對將來有所考慮，軟體的壽命便不會長久，要將以後可能的變化考慮在內。需求獲取後，務必要將調研的成果編制為文檔，可視化需求調研，提供不同的圖給不同層次的用戶進行確認。對高層領導，可提供總體職能域圖或業務流程圖，對業務管理人員可提供業務流程圖或業務活動圖，甚至可以畫出用戶界面的草圖。
3 需求分析與設計
架構師所帶領的團隊做出的關於軟體體系結構的決策，將直接影響軟體開發的難度和軟體維護的難易度，最終決定軟體開發的成敗。
作為一個架構師，在進行架構設計時，必須具備以下基本能力：
（1）他要把整個團隊組織在架構周圍，並積極地投入到計劃活動上，要把架構轉化完成任務的先後順序，這樣才能及時地確定在什麼位置用什麼技術。
（2）架構師要在技術上做宏觀決策，不必關心細節化的事情，由於技術的變化過於頻繁，架構師要時與這些變化同步；架構師必須至少能對各種技術有一個整體上的了解，能夠熟知每種技術特點及優缺點，只有這樣，架構設計師才能在特定的應用場景下，正確地選擇各種技術來設計軟體架構。
（3）架構師要能預測最小化項目中可能出現的風險，因為這直接影響到軟體架構的穩定性。
（4）架構師要能與開發人員保持良好的溝通，確保軟體設計的實現。
『柒』 java軟體開發的架構設計
軟體架構作為一個概念，體現在技術和業務兩個方面。
從技術角度來說：軟體架構隨著技術的革新不斷地更新其內容，軟體架構建立於當前技術和一些基本原則的基礎之上。
先說一些基本原則：
分層原則：分層是為了降低軟體深度復雜性而使用的關鍵思想，就像社會有了階級一樣，軟體有了層次結構。
模塊化原則：模塊化是化解軟體廣度復雜的必然手段，模塊化的目的就是讓軟體分工。
介面實現分離原則隨著軟體模塊化的不斷深入改進，面向介面編程而不是面向實現編程可以讓復雜度日趨增高的軟體降低模塊之間的耦合度，從而讓各模塊更輕松改進。從這個原則出發，軟體也從微觀進行了細致的規范化。
還有兩個比較小但很重要的原則：
細節隱藏原則很顯然把復雜問題簡化，把難看的細節隱去，能讓軟體結構更清晰。其實這個原則使用很普遍，java/c++語言中的封裝原則以及設計模式中的Facade(外觀)模式就很能體現這個原則的精神。
依賴倒置原則隨著軟體結構的進一步發展,層與層之間、模塊與模塊之間的依賴逐漸加深，而層、模塊的動態可插拔要求不端增大。依賴倒置原則可看視為介面實現分離原則的深化，根據此原則的精神，軟體進入了工具時代。這個原則有點類似於知名的好萊塢法則：Don't call us, we'll call you。
以上這些原則奠定了我們的軟體架構的價值指標。但軟體架構畢竟是建立在當前技術之上的。而每一代技術都有架構模式。過去的不再說了，讓我們就來看一下當前流行的技術，以及當前我們能採用的架構。
因為面向對象是當前最流行開發技術，且設計模式的大量使用使面向對象的走向成熟，而資料庫是當前最有效的存儲結構、web界面是當前最流行的用戶介面，所以當前最典型的三層次架構就架構在以上幾項技術的基礎之上，用資料庫作存儲層、用面向對象來實現業務層、用web來作為用戶介面層。我們從三層次架構談起：
因為面向對象技術和資料庫技術不適配，所以在標准三層次架構的基礎上，我們增加了數據持久層，來管理O-R雙向映射，但目前一直沒有最理想的實現技術。cmp和entity bean技術因為其實現復雜，功能前景有限，已接近被淘汰的邊緣。JDO及hibernate作為o-r映射的後期之秀，尤其是hibernate，功能相當完備。推薦作為持久層的首選
在業務層，因為當前業務日趨負載，且變動頻繁，所以我們必須有足夠敏捷的技術來保證我們的適應變化的能力，在標准j2ee系統中session bean負責業務處理，且有不錯的性能表現，但採用ejb系統對業務架構模式改變太大，且其復雜而昂貴，業務代碼移植性差。而spring 作為一個bean配置的輕量級架構，漂亮的IOC模式實現，對業務架構影響小，所以推薦作為中間層業務框架。
在用戶結構層,雖然servlet/jsp/jstl/javaBean 能夠實現MVC架構，但終究過於粗糙。struts對MVC架構的實現就比較完美，Taperstry也極好地實現MVC架構，且採用基於事件的方式，非常誘人，惜其不夠成熟，我們仍舊推薦struts作為用戶介面層基礎架構。
因為業務層是三層次架構中最有決定意義的，所以讓我們回到業務層細致地分析一下，在復雜的業務我們常常需要以下基礎服務的一種或幾種：事務一致 性服務acid(tool:jta/jts)、並發加鎖服務concurrent&&lock、池化管理服務cache、訪問控制服務(tool:jaas)、流程式控制制服務workflow、動態實現服務IOC，串列化消息服務(tool:jms)、負載平衡服務blance等。如果我們不採用重量級應用伺服器(如weblogic,websphere,jboss等)及重量級組件(EJB)，我們必須自己實現其中一些服務。雖然我們大 多情況下，不需要所有這些服務，但實現起來卻非易事。幸運的是我們有大量的開源實現代碼，但採用開源代碼卻常常是件不輕松的事。
隨著xml作為結構化信息傳輸和存儲地位日漸重要,一些xml文檔操作工具(DOM,Digester,SAX等)的使用愈發重要，而隨著 xml schema的java binding工具(jaxb,xmlbean等)工具的成熟，採用xml schema來設計xml文檔格式，然後採用java binding來生成java bean 會成為主要編程模式,而這又進一步使數據中心向xml轉移，使在中小數據量上,愈發傾向於以xquery為查詢語言的xml資料庫。現還有一個趨勢， microsoft,ibm等紛紛大量開發中間軟體如(microsoft office之infopath)，可以直接從xml schema 生成錄入頁面等非常實用的功能。還有web service 的廣泛應用，都將對軟體的架構有非常重大的影響。至於面向服務架構(SOA)前景如何，三層次架構什麼時候走入歷史，現還很難定論。
aop的發展也會對軟體架構有很深的影響，但在面向對象架構里，無論aspectJ還是jboss-aop抑是aspectWerks、 nanning都有其自身的嚴重問題：維護性很差，所以說它將很難走遠。也許作為一個很好的思想，它將在web service里大展身手。
rdf,owl作為w3c語義模型的標志性的語言，也很難想像能在當前業務架構發揮太大影響。但如果真如它所聲稱那樣，廣泛地改變著信息的結構。那麼對軟體架構也會有深遠影響。
『捌』 畫構架圖使用的是什麼軟體
可以利用word文檔畫構架圖，詳細步驟：
1、打開word文檔，選擇菜單欄【插入】內下邊的【AmartArt】工具。容
『玖』 軟體架構模式基本概念及三者區別
在做軟體架構設計時,根據不同的抽象層次可分為三種不同層次的模式：架構模式(Architectural Pattern)、設計模式(Design Pattern)、代碼模式(Coding Pattern)。
架構模式是一個系統的高層次策略，涉及到大尺度的組件以及整體性質和力學。架構模式的好壞可以影響到總體布局和框架性結構。
設計模式是中等尺度的結構策略。這些中等尺度的結構實現了一些大尺度組件的行為和它們之間的關系。模式的好壞不會影響到系統的總體布局和總體框架。設計模式定義出子系統或組件的微觀結構。
代碼模式（或成例）是特定的範例和與特定語言有關的編程技巧。代碼模式的好壞會影響到一個中等尺度組件的內部、外部的結構或行為的底層細節，但不會影響到一個部件或子系統的中等尺度的結構，更不會影響到系統的總體布局和大尺度框架。
架構模式(Architectural Pattern)
一個架構模式描述軟體系統里的基本的結構組織或綱要。架構模式提供一些事先定義好的子系統，指定它們的責任，並給出把它們組織在一起的法則和指南。稱之為系統模式。
•MVC模式,一個架構模式常常可以分解成很多個設計模式的聯合使用。MVC模式常常包括調停者（Mediator）模式、策略（Strategy）模式、合成（Composite）模式、觀察者（Observer）模式等。
•Layers（分層）模式，有時也稱Tiers模式
•Blackboard（黑板）模式
•Broker（中介）模式
•Distributed Process（分散過程）模式
•Microkernel（微核）模式
架構模式常常劃分成如下的幾種：
一、 模塊結構(From Mud to Structure)型。幫助架構師將系統合理劃分，避免形成一個對象的海洋。包括Layers（分層）模式、Blackboard（黑板）模式、Pipes/Filters（管道/過濾器）模式等。
二、分散系統（Distributed Systems）型。為分散式系統提供完整的架構設計，包括像Broker（中介）模式等。
三、人機互動（Interactive Systems）型，支持包含有人機互動介面的系統的架構設計，例子包括MVC（Model-View-Controller）模式、PAC（Presentation-Abstraction-Control）模式等。
四、Adaptable Systems型，支持應用系統適應技術的變化、軟體功能需求的變化。如Reflection（反射）模式、Microkernel（微核）模式等。
設計模式(Design Pattern)
一個設計模式提供一種提煉子系統或軟體系統中的組件的，或者它們之間的關系的綱要設計。設計模式描述普遍存在的在相互通訊的組件中重復出現的結構，這種結構解決在一定的背景中的具有一般性的設計問題。
設計模式常常劃分成不同的種類，常見的種類有：
創建型設計模式，如工廠方法（Factory Method）模式、抽象工廠（Abstract Factory）模式、原型（Prototype）模式、單例（Singleton）模式，建造（Builder）模式等
結構型設計模式，如合成（Composite）模式、裝飾（Decorator）模式、代理（Proxy）模式、享元（Flyweight）模式、門面（Facade）模式、橋梁（Bridge）模式等
行為型模式，如模版方法（Template Method）模式、觀察者（Observer）模式、迭代子（Iterator）模式、責任鏈（Chain of Responsibility）模式、備忘錄（Memento）模式、命令（Command）模式、狀態（State）模式、訪問者（Visitor）模式等等。
以上是三種經典類型，實際上還有很多其他的類型，比如Fundamental型、Partition型，Relation型等等。設計模式在特定的編程語言中實現的時候，常常會用到代碼模式。比如單例（Singleton）模式的實現常常涉及到雙檢鎖（Double-Check Locking）模式等。
代碼模式(Coding Pattern)
代碼模式（或成例）是較低層次的模式，並與編程語言密切相關。代碼模式描述怎樣利用一個特定的編程語言的特點來實現一個組件的某些特定的方面或關系。
較為著名的代碼模式的例子包括雙檢鎖（Double-Check Locking）模式等