什麼是軟體架構圖

㈠ 什麼是結構圖

結構圖是指以模塊的調用關系為線索，用自上而下的連線表示調用關系並註明參數傳遞的方向和內容，從宏觀上反映軟體層次結構的圖形，結構圖分建築圖和組織結構圖。

組織結構圖（Organization Chart）又稱組織架構圖。是最常見的表 現雇員、職稱和群體關系的一種圖表，它形象地反映了組織內各機構、崗 位上下左右相互之間的關系。組織結構圖是組織結構的直觀反映，也是對 該組織功能的一種側面詮釋。

(1)什麼是軟體架構圖擴展閱讀：

一般建築的結構平面圖，均應有各層結構平面圖及屋面結構平面圖。具體內容為：

1）繪出定位軸線及梁、柱、承重牆，抗震構造柱等定位尺寸，並註明其編號和樓層標高；

2）註明預制板的跨度方向、板號、數量及板底標高，標出預留洞大小及位置；預制梁、洞口過梁的位置和型號、梁底標高；

3）現澆板應註明板厚、板面標高、配筋（亦可另繪放大比例的配筋圖，必要時應將現澆樓面模板圖和配筋圖分別繪制），標高或板厚變化處繪局部剖面，有預留孔、埋件、已定設備基礎時應示出規格與位置，洞邊加強措施，當預留孔、埋件、設備基礎復雜時亦可放大另繪；

4）有圈樑時應註明位置、編號、標高，可用小比例繪制單線平面示意圖。

5）樓梯間可繪斜線註明編號與所在詳圖號；

6）電梯間應繪制機房結構平面布置（樓面與頂面）圖，註明梁板編號、板的厚度與配筋、預留洞大小與位置、板面標高及吊鉤平面位置與詳圖；

7）屋面結構平面布置圖內容與樓層平面類同，當結構找坡時應標注屋面板的坡度、坡向、坡向起終點處的板面標高，當屋面上有留洞或其他設施時應繪出其位置、尺寸與詳圖，女兒牆或女兒牆構造柱的位置、編號及詳圖；

8）當選用標准圖中節點或另繪節點構造詳圖時，應在平面圖中註明詳圖索引號。

㈡ 什麼是系統架構

問題一：「系統架構」是什麼意思？都有哪些架構？ JDE屬於分布式架構,人和系統恕我孤陋寡聞,沒聽過阿

問題二：軟體架構和系統架構到底是什？生活中有哪些東西可以比喻？ 軟體架構是指軟體整體的組織結構，是在較高層次上的分析設計，體現了軟體系統總體的規化、決策、控制等。
系統架構包括軟體、硬體、網路等多方面的組織結構。架構是分析設計的高層階段，不會涉及到技術實現的細節，是藍圖，是規化，是決策。
現實生活中可比喻為高樓大廈的設計圖紙。

問題三：什麼是架構 架構一般指軟體架構

（software architecture）是一系列相關的抽象模式，用於指導大型軟體系統各個方面的設計。 軟體架構是一個系統的草圖。軟體架構描述的對象是直接構成系統的抽象組件。各個組件之間的連接則明確和相對細致地描述組件之間的通訊。在實現階段，這些抽象組件被細化為實際的組件，比如具體某個類或者對象。在面向對象領域中，組件之間的連接通常用介面(計算機科學)來實現。 軟體體系結構是構建計算機軟體實踐的基礎。與建築師設定建築項目的設計原則和目標，作為繪圖員畫圖的基礎一樣，一個軟體架構師或者系統架構師陳述軟體構架以作為滿足不同客戶需求的實際系統設計方案的基礎。
軟體構架是一個容易理解的概念，多數工程師（尤其是經驗不多的工程師）會從直覺上來認識它，但要給出精確的定義很困難。特別是，很難明確地區分設計和構架：構架屬於設計的一方面，它集中於某些具體的特徵。
在「軟體構架簡介」中，David Garlan 和 Mary Shaw 認為軟體構架是有關如下問題的設計層次：「在計算的演算法和數據結構之外，設計並確定系統整體結構成為了新的問題。結構問題包括總體組織結構和全局控制結構；通信、同步和數據訪問的協議；設計元素的功能分配；物理分布；設計元素的組成；定標與性能；備選設計的選擇。」【GS93】
但構架不僅是結構；IEEE Working Group on Architecture 把其定義為「系統在其環境中的最高層概念」【IEEE98】。構架還包括「符合」系統完整性、經濟約束條件、審美需求和樣式。它並不僅注重對內部的考慮，而且還在系統的用戶環境和開發環境中對系統進行整體考慮，即同時注重對外部的考慮。
在 Rational Unified Process 中，軟體系統的構架（在某一給定點）是指系統重要構件的組織或結構，這些重要構件通過介面與不斷減小的構件與介面所組成的構件進行交互。
從和目的、主題、材料和結構的聯繫上來說，軟體架構可以和建築物的架構相比擬。一個軟體架構師需要有廣泛的軟體理論知識和相應的經驗來實施和管理軟體產品的高級設計。軟體架構師定義和設計軟體的模塊化，模塊之間的交互，用戶界面風格，對外介面方法，創新的設計特性，以及高層事物的對象操作、邏輯和流程。
一般而言，軟體系統的架構（Architecture）有兩個要素：
・它是一個軟體系統從整體到部分的最高層次的劃分。
一個系統通常是由元件組成的，而這些元件如何形成、相互之間如何發生作用，則是關於這個系統本身結構的重要信息。
詳細地說，就是要包括架構元件（Architecture ponent）、聯結器（Connector）、任務流（Task-flow）。所謂架構元素，也就是組成系統的核心磚瓦，而聯結器則描述這些元件之間通訊的路徑、通訊的機制、通訊的預期結果，任務流則描述系統如何使用這些元件和聯結器完成某一項需求。
・建造一個系統所作出的最高層次的、以後難以更改的，商業的和技術的決定。
在建造一個系統之前會有很多的重要決定需要事先作出，而一旦系統開始進行詳細設計甚至建造，這些決定就很難更改甚至無法更改。顯然，這樣的決定必定是有關系統設計成敗的最重要決定，必須經過非常慎重的研究和考察。
詳情參考
......>>

問題四：什麼是系統工程師、系統架構工程師？ 系統工程師資格就是具備較高專業技術水平，能夠分析商業需求，並使用各種系統平台和伺服器軟體來設計並實現商務解決方案的基礎架構。
系統架構師是大型項目的技術領導者,總體負責系統的體系結構設計和指導。

問題五：什麼是分布式系統架構 ke./view/9914海9 網路

問題六：架構，系統架構，技術架構，應用架構都是什麼關系 架構
是有關軟體整體結構與組件的抽象描述，用於指導大型軟體系統各個方面的設計。
系統架構
是對已確定的需求的技術實現構架、作好規劃,運用成套、完整的工具,在規劃的步驟下去完成任務。
技術架構
通過合理的完善的評估途徑對組織、網路、程序的組成框架、模型進行評價和分析,並對其進行完善。
應用架構
以架構圖的方式描述系統的組成和框架，一般從系統功能和系統技術層次兩個架構視角進行設計。

問題七：請問系統架構設計師的職責是什麼 系統架構師的職責主要有如下4條：
1、確認需求
在項目開發過程中，架構師是在需求規格說明書完成後介入的，需求規格說明書必須得到架構師的認可。架構師需要和分析人員反復交流，以保證自己完整並准確地理解用戶需求。
2、系統分解
依據用戶需求，架構師將系統整體分解為更小的子系統和組件，從而形成不同的邏輯層或服務。隨後，架構師會確定各層的介面，層與層相互之間的關系。架構師不僅要對整個系統分層，進行「縱向」分解，還要對同一邏輯層分塊，進行「橫向」分解。
軟體架構師的功力基本體現於此，這是一項相對復雜的工作。
3、技術選型
架構師通過對系統的一系列的分解，最終形成了軟體的整體架構。技術選擇主要取決於軟體架構。
Web Server運行在Windows上還是Linux上？資料庫採用MSSql、Oracle還是Mysql？需要不需要採用MVC或者Spring等輕量級的框架？前端採用富客戶端還是瘦客戶端方式？類似的工作，都需要在這個階段提出，並進行評估。
架構師對產品和技術的選型僅僅限於評估，沒有決定權，最終的決定權歸項目經理。架構師提出的技術方案為項目經理提供了重要的參考信息，項目經理會從項目預算、人力資源、時間進度等實際情況進行權衡，最終進行確認。
4、制定技術規格說明
架構師在項目開發過程中，是技術權威。他需要協調所有的開發人員，與開發人員一直保持溝通，始終保證開發者依照它的架構意圖去實現各項功能。
架構師不僅要保持與開發者的溝通，也需要與項目經理、需求分析員，甚至與最終用戶保持溝通。所以，對於架構師來講，不僅有技術方面的要求，還有人際交流方面的要求。

問題八：系統架構師是干什麼的啊？ 屬於項目的高級分析、規劃、管理人員
系統架構師（System Architecture）系統架構師是負責設計系統整體架構，從需求到設計的每個細節都要考慮到，把握整個項目，使設計的項目盡量效率高，開發容易，維護方便，升級簡單等等。
全文見網路
ke./view/905154?fr=ala0_1_1

問題九：系統架構師的角 *** 別 系統構架師與產品經理的關系及區別產品經理通常是指負責產品設計的「專人」。一個優秀的理想的產品經理，應同時具備較高的商業素質和較強的技術背景。產品經理要有深厚的領域經驗，也就是說，對該軟體系統要應用到的業務領域非常之熟悉。比如，開發房地產銷售軟體的產品經理，應該對房地產公司的標准銷售流程了如指掌，甚至比大多數銷售人員還要清楚。如果開發的是通用產品，他/她還具備對市場、潛在客戶需求的深刻洞察力。 那麼，系統架構師與產品經理有什麼不同呢？我們不應該把二者混為一談，這是不少論述和實踐常犯的錯誤。我看來，如果把開發軟體比作攝制電影，產品經理之於系統架構師，就正像編劇之於導演。產品經理雖然要有一定技術背景，但仍應屬於「商業人士（business people）」，而系統架構師則肯定是一個技術專家。二者看待問題的立場、角度和出發點完全不同。系統構架師與項目經理的關系及區別軟體項目經理是指對項目控制/管理，關注項目本身的進度、質量，分配、調動、協調、管理好人、財、物等資源的負責人。對於軟體項目經理來講，包括項目計劃、進度跟蹤/監控、質量保證、配置/發布/版本/變更管理、人員績效評估等方面。優秀的項目經理需要的素質，並不僅在於會使用幾種軟體或是了解若干抽象的方法論原則，更重要的在於從大量項目實踐中獲得的寶貴經驗，以及交流、協調、激勵的能力，甚至還應具備某種個性魅力或領袖氣質（Chari *** a）。由此可見，項目經理和系統架構師在職責上有很大差異。混同這兩個角色，往往也會導致低效、無序的開發。特別是，從性格因素上講，單純的技術人員傾向於忽視「人」的因素，而這正是管理活動的一個主要方面。另外，就像戰爭中的空軍掩護（Air Cover）一樣，專職的項目經理能夠應付開發過程中大量的偶發事件和雜務，對於一個規模稍大的項目，這些雜務本身就能佔用一個全職工作者的幾乎全部時間。在一個項目中，推動項目發展的是系統構架師，而不是項目經理。項目經理的職責只是配合系統構架師，提供各個方面的支持。主要職責是與內外部溝通和管理資源（包括人）。系統構架師提出系統的總體構架，給出開發指導。一個項目中，項目經理的角色什麼？如果他即使管理人員又是設計人員，則必須比別人強，能夠有讓別人服的東西。如果他只是項目管理人員，系統構架師有專門人員，就可以不用精通或者說了解 it 各個方面的知識，如果了解更好。另外，如果在一個項目沒有人在技術構架上和開發指導上負全部責任，而是每個人都負責一快的架構、分析、設計、代碼和實施等，最後肯定會失去管理。系統構架師與系統分析員的關系及區別系統分析員（System *** yst）是指對系統開發中進行分析、設計和領導實施的人。一般意思上講，系統分析員的水平將影響系統開發的質量，甚至成敗。但在一個完善的系統開發隊伍中，還需要有業務專家，技術專家和其他輔助人員。所以，系統分析員只是其中的角色之一。但我國許多的 IT 公司，一般只有系統分析員而沒有技術專家。系統分析員固然是對特定系統進行分析、設計。所以他的任務、目標是明確的。他只是去執行任務，完成系統的最終設計。系統架構師應該和系統分析員分開，但架構師必須具備系統分析員的所有能力，同時還應該具備設計員所沒有的很多能力。 系統架構師是指導、檢督系統分析員的工作，要求系統分析員按什麼標准，什麼工具，什麼模式，什麼技術去設計系統的。同時，系統架構師應該對系統分析員所提出的問題，碰到的難題及時地提出解決的方法。並檢查、評審系統分析員的工作。

㈢ 軟體體系結構圖怎麼畫啊

軟體體系結構參考圖如下：

正如上面提到的，不同的受眾，比如用戶、客戶、開發人員、測試人員、運維人員，需要從各自工作的角度去理解和使用架構。所以回答這個問題，需要首先了解這幅架構圖畫出來是給誰看，你想從那個維度去入手。
確定了這個問題之後，再來了解架構視圖有哪些維度和組成要素：
1. 架構視圖
最經典的當屬4+1視圖：

• 邏輯視圖
  
• 開發視圖
  
• 過程視圖
  
• 物理視圖
  
• 場景視圖
  

4+1視圖提出後，業界也有其它的觀點提出，諸如SEI(模塊視圖、組建和連接件視圖、分配視圖)、西門子4種視圖（概念、模塊、代碼、執行視圖）、以及RM-ODP(企業視圖、信息視圖、計算視圖、工程師圖）等。
常見的視圖除了上述4+1視圖外還包括：數據視圖、安全視圖、實現視圖等。

2. 了解架構視圖的四要素

• 圖示化主要元素和元素之間的關系
  
• 具有明確的圖例、定義和說明元素
  
• 每個元素具備明確的介面和行為規范
  
• 設計原理和設計決策的信息
  

3. 簡單說一下幾個視圖針對的角色和維度：
邏輯視圖一般針對客戶、用戶、業務人員、開發組織，主要從系統的功能元素、以及它們的介面、職責、交互維度入手。主要元素包括系統、子系統、功能模塊、子功能模塊、介面等。

開發視圖一般針對開發和測試相關人員，主要描述系統如何開發實現；主要元素包括描述系統的分層、分區、框架、系統通用服務、業務通用服務、類和介面、系統平台和大基礎框架。用途是知道開發設計和實現。

物理視圖一般針對系統運維人員、集成人員，它是系統邏輯組件到物理節點的映射，節點與節點間的物理網路配置等，主要關注非功能性需求，諸如性能（吞吐量）、可伸縮性、可靠性，可用性等，從而得出相關的物理部署結構圖。

㈣ 軟體系統結構圖怎麼畫

問題一：軟體系統架構圖 用visio畫 怎麼新建？ 5分 朋友，採用visio畫軟體系統架構圖一般是選擇其中的包圖，非常簡單。

問題二：系統架構圖怎麼畫的? 系統架構常用軟體:
1. MindManager 畫思維導圖
2. Microsoft Office Visio 內有uml建模工具, 上圖也可以用此軟體畫出來
3. Axure RP Pro 可以用來畫產品原型
各軟體怎麼用還是要實踐中去熟悉

問題三：怎麼畫此圖的軟體結構圖？ 5分 你自己下載這個工具吧
Diagram Designer
直接網路搜索這個。。。

問題四：visio軟體系統架構圖怎麼畫 1 新建 選擇模板
2 插入需要的形狀
3 雙擊形狀，填寫內容
4 插入動態連接線，連接上下級
5 調整總體結構
6 完成

問題五：軟體體系結構圖怎麼畫 uml圖嗎。。。。

問題六：怎麼在word中畫功能結構圖？ 首先,想好結構布局圖,然後選擇工具欄上的插入選擇形狀,選擇直線.
在文本需要的地方畫一條合適的直線,然後將這條直線復制多個,如復制三個,共四個,
接著選擇一根直線,利用鍵盤上的上下左右方向按鈕對直線位置調整,擺放整齊.
然後再選擇選擇工具欄上的插入選擇形狀,選擇流程圖里的方形.
在文本合適的地方畫上一個大小合適的長方形圖.然後再復制三個.
接著選擇四邊形圖一個一個利用鍵盤上的上下左右方向按鈕對直線位置調整,擺放整齊.
然後選擇文本檔,添加文字或編輯文字內容即可.

問題七：什麼是系統結構圖？？ 系統結構圖是對軟體系統結構的總體設計的圖形顯示，在需求分析階段,已經從系統開發的角度出發,把系統按功能逐次分割成層次結構,使每一部分完成簡單的功能且各個部分之間又保持一定的聯系,這就是功能設計.在設計階段,基於這個功能的層次結構把各個部分組合起來成為系統.(3)處理方式設計:確定為實現軟體系統的功能需求所必需的演算法,評估演算法的性能.確定為滿足軟體系統的性能飢求所必需的演算法和模塊間的控制方式(性能設計).確定外部信號的接收發送形式.
用Microsoft Visio Trial來畫系統結構圖

問題八：win8系統用什麼軟體畫組織結構圖 可以用Edraw max，專業的組織結構圖軟體，可以插入照片，可以繪制復雜的組織結構圖。能夠導出PDF，jpg，PPT，word，png等多種格式，方便分享和列印。

問題九：網路系統架構圖 用什麼畫（什麼軟體） visio或億圖都可以

㈤ 軟體工程中軟體結構圖和層次圖的異同

兩者之間沒有區別。兩者指的均是軟體構架，為軟體系統的草圖。

軟體工程中軟體結構圖和層次圖均是為了反映軟體系統中組件之間相互關系和約束的體系結構設計圖，屬於一系列相關的抽象模式，用於指導大型軟體系統各個方面的設計。

軟體結構圖（又被叫做軟體構架）一般通過分層次或分時間段等方式說明體系結構的各個組成部分的組合關系。描述的對象是直接構成系統的抽象組件，各個組件之間的連接則明確和相對細致地描述組件之間的通訊關系。

(5)什麼是軟體架構圖擴展閱讀：

其他介紹：

軟體結構圖包括架構元件、聯結器、任務流。所謂架構元素，也就是組成系統的核心磚瓦，而聯結器則描述這些元件之間通訊的路徑、通訊的機制、通訊的預期結果，任務流則描述系統如何使用這些元件和聯結器完成某一項需求。

通過一個軟體結構圖建造一個系統所作出的最高層次的、以後難以更改的，商業的和技術的決定。在建造一個系統之前會有很多的重要決定需要事先作出，而一旦系統開始進行詳細設計甚至建造，這些決定就很難更改甚至無法更改。顯然，這樣的決定必定是有關系統設計成敗的最重要決定，必須經過非常慎重的研究和考察。

㈥ 什麼是軟體架構有沒有具體解釋

軟體架構
軟體架構（software architecture）是一系列相關的抽象模式，用於指導大型軟體系統各個方面的設計。 軟體架構是一個系統的草圖。軟體架構描述的對象是直接構成系統的抽象組件。各個組件之間的連接則明確和相對細致地描述組件之間的通訊。在實現階段，這些抽象組件被細化為實際的組件，比如具體某個類或者對象。在面向對象領域中，組件之間的連接通常用介面_(計算機科學)來實現。

軟體體系結構是構建計算機軟體實踐的基礎。與建築師設定建築項目的設計原則和目標，作為繪圖員畫圖的基礎一樣，一個軟體架構師或者系統架構師陳述軟體構架以作為滿足不同客戶需求的實際系統設計方案的基礎。

軟體構架是一個容易理解的概念，多數工程師（尤其是經驗不多的工程師）會從直覺上來認識它，但要給出精確的定義很困難。特別是，很難明確地區分設計和構架：構架屬於設計的一方面，它集中於某些具體的特徵。

在「軟體構架簡介」中，David GArlan 和 Mary Shaw 認為軟體構架是有關如下問題的設計層次：「在計算的演算法和數據結構之外，設計並確定系統整體結構成為了新的問題。結構問題包括總體組織結構和全局控制結構；通信、同步和數據訪問的協議；設計元素的功能分配；物理分布；設計元素的組成；定標與性能；備選設計的選擇。」[GS93]

但構架不僅是結構；IEEE Working Group on Architecture 把其定義為「系統在其環境中的最高層概念」[IEEE98]。構架還包括「符合」系統完整性、經濟約束條件、審美需求和樣式。它並不僅注重對內部的考慮，而且還在系統的用戶環境和開發環境中對系統進行整體考慮，即同時注重對外部的考慮。

在 Rational Unified ProcESs 中，軟體系統的構架（在某一給定點）是指系統重要構件的組織或結構，這些重要構件通過介面與不斷減小的構件與介面所組成的構件進行交互。

從和目的、主題、材料和結構的聯繫上來說，軟體架構可以和建築物的架構相比擬。一個軟體架構師需要有廣泛的軟體理論知識和相應的經驗來事實和管理軟體產品的高級設計。軟體架構師定義和設計軟體的模塊化，模塊之間的交互，用戶界面風格，對外介面方法，創新的設計特性，以及高層事物的對象操作、邏輯和流程。

是一般而言，軟體系統的架構（ArchitECture）有兩個要素：

·它是一個軟體系統從整體到部分的最高層次的劃分。

一個系統通常是由元件組成的，而這些元件如何形成、相互之間如何發生作用，則是關於這個系統本身結構的重要信息。

詳細地說，就是要包括架構元件（Architecture Component）、聯結器（Connector）、任務流（TASk-flow）。所謂架構元素，也就是組成系統的核心"磚瓦"，而聯結器則描述這些元件之間通訊的路徑、通訊的機制、通訊的預期結果，任務流則描述系統如何使用這些元件和聯結器完成某一項需求。

·建造一個系統所作出的最高層次的、以後難以更改的，商業的和技術的決定。

在建造一個系統之前會有很多的重要決定需要事先作出，而一旦系統開始進行詳細設計甚至建造，這些決定就很難更改甚至無法更改。顯然，這樣的決定必定是有關系統設計成敗的最重要決定，必須經過非常慎重的研究和考察。

歷史
早在1960年代，諸如E·W·戴克斯特拉就已經涉及軟體架構這個概念了。自1990年代以來，部分由於在 Rational Software Corporation 和MiCROSoft內部的相關活動，軟體架構這個概念開始越來越流行起來。

卡內基梅隆大學和加州大學埃爾文分校在這個領域作了很多研究。卡內基·梅隆大學的Mary Shaw和David Garlan於1996年寫了一本叫做 Software Architecture perspective on an emerging DIscipline的書，提出了軟體架構中的很多概念，例如軟體組件、連接器、風格等等。 加州大學埃爾文分校的軟體研究院所做的工作則主要集中於架構風格、架構描述語言以及動態架構。

計算機軟體的歷史開始於五十年代，歷史非常短暫，而相比之下建築工程則從石器時代就開始了，人類在幾千年的建築設計實踐中積累了大量的經驗和教訓。建築設計基本上包含兩點，一是建築風格，二是建築模式。獨特的建築風格和恰當選擇的建築模式，可以使一個獨一無二。

下面的照片顯示了中美洲古代瑪雅建築，Chichen-Itza大金字塔，九個巨大的石級堆壘而上，九十一級台階（象徵著四季的天數）奪路而出，塔頂的神殿聳入雲天。所有的數字都如日歷般嚴謹，風格雄渾。難以想像這是石器時代的建築物。

圖1、位於墨西哥Chichen-Itza（在瑪雅語中chi意為嘴chen意為井）的古瑪雅建築。（攝影：作者）

軟體與人類的關系是架構師必須面對的核心問題，也是自從軟體進入歷史舞台之後就出現的問題。與此類似地，自從有了建築以來，建築與人類的關系就一直是建築設計師必須面對的核心問題。英國首相丘吉爾說，我們構造建築物，然後建築物構造我們（We shape our buildings, and afterwaRDS our buildings shape us）。英國下議院的會議廳較狹窄，無法使所有的下議院議員面向同一個方向入座，而必須分成兩側入座。丘吉爾認為，議員們入座的時候自然會選擇與自己政見相同的人同時入座，而這就是英國政黨制的起源。Party這個詞的原意就是"方"、"面"。政黨起源的關鍵就是建築物對人的影響。

在軟體設計界曾經有很多人認為功能是最為重要的，形式必須服從功能。與此類似地，在建築學界，現代主義建築流派的開創人之一Louis Sullivan也認為形式應當服從於功能（FORMs follows function）。

幾乎所有的軟體設計理念都可以在浩如煙海的建築學歷史中找到更為遙遠的歷史回響。最為著名的，當然就是模式理論和XP理論。

架構的目標是什麼

正如同軟體本身有其要達到的目標一樣，架構設計要達到的目標是什麼呢？一般而言，軟體架構設計要達到如下的目標：

·可靠性（Reliable）。軟體系統對於用戶的商業經營和管理來說極為重要，因此軟體系統必須非常可靠。

·安全行（Secure）。軟體系統所承擔的交易的商業價值極高，系統的安全性非常重要。

·可擴展性（SCAlable）。軟體必須能夠在用戶的使用率、用戶的數目增加很快的情況下，保持合理的性能。只有這樣，才能適應用戶的市場擴展得可能性。

·可定製化（CuSTomizable）。同樣的一套軟體，可以根據客戶群的不同和市場需求的變化進行調整。

·可擴展性（Extensible）。在新技術出現的時候，一個軟體系統應當允許導入新技術，從而對現有系統進行功能和性能的擴展

·可維護性（MAIntainable）。軟體系統的維護包括兩方面，一是排除現有的錯誤，二是將新的軟體需求反映到現有系統中去。一個易於維護的系統可以有效地降低技術支持的花費

·客戶體驗（Customer Experience）。軟體系統必須易於使用。

·市場時機（Time to Market）。軟體用戶要面臨同業競爭，軟體提供商也要面臨同業競爭。以最快的速度爭奪市場先機非常重要。

架構的種類

根據我們關注的角度不同，可以將架構分成三種：

·邏輯架構、軟體系統中元件之間的關系，比如用戶界面，資料庫，外部系統介面，商業邏輯元件，等等。

比如下面就是筆者親身經歷過的一個軟體系統的邏輯架構圖

圖2、一個邏輯架構的例子

從上面這張圖中可以看出，此系統被劃分成三個邏輯層次，即表象層次，商業層次和數據持久層次。每一個層次都含有多個邏輯元件。比如WEB伺服器層次中有HTML服務元件、Session服務元件、安全服務元件、系統管理元件等。

·物理架構、軟體元件是怎樣放到硬體上的。

比如下面這張物理架構圖描述了一個分布於北京和上海的分布式系統的物理架構，圖中所有的元件都是物理設備，包括網路分流器、代理伺服器、WEB伺服器、應用伺服器、報表伺服器、整合伺服器、存儲伺服器、主機等等。

圖3、一個物理架構的例子

·系統架構、系統的非功能性特徵，如可擴展性、可靠性、強壯性、靈活性、性能等。

系統架構的設計要求架構師具備軟體和硬體的功能和性能的過硬知識，這一工作無疑是架構設計工作中最為困難的工作。

此外，從每一個角度上看，都可以看到架構的兩要素：元件劃分和設計決定。

首先，一個軟體系統中的元件首先是邏輯元件。這些邏輯元件如何放到硬體上，以及這些元件如何為整個系統的可擴展性、可靠性、強壯性、靈活性、性能等做出貢獻，是非常重要的信息。

其次，進行軟體設計需要做出的決定中，必然會包括邏輯結構、物理結構，以及它們如何影響到系統的所有非功能性特徵。這些決定中會有很多是一旦作出，就很難更改的。

根據作者的經驗，一個基於資料庫的系統架構，有多少個數據表，就會有多少頁的架構設計文檔。比如一個中等的資料庫應用系統通常含有一百個左右的數據表，這樣的一個系統設計通常需要有一百頁左右的架構設計文檔。

構架描述

為了討論和分析軟體構架，必須首先定義構架表示方式，即描述構架重要方面的方式。在 Rational Unified Process 中，軟體構架文檔記錄有這種描述。

構架視圖

我們決定以多種構架視圖來表示軟體構架。每種構架視圖針對於開發流程中的涉眾（例如最終用戶、設計人員、管理人員、系統工程師、維護人員等）所關注的特定方面。

構架視圖顯示了軟體構架如何分解為構件，以及構件如何由連接器連接來產生有用的形式 [PW92]，由此記錄主要的結構設計決策。這些設計決策必須基於需求以及功能、補充和其他方面的約束。而這些決策又會在較低層次上為需求和將來的設計決策施加進一步的約束。

典型的構架視圖集

構架由許多不同的構架視圖來表示，這些視圖本質上是以圖形方式來摘要說明「在構架方面具有重要意義」的模型元素。在 Rational Unified Process 中，您將從一個典型的視圖集開始，該視圖集稱為「4+1 視圖模型」[KRU95]。它包括：

用例視圖：包括用例和場景，這些用例和場景包括在構架方面具有重要意義的行為、類或技術風險。它是用例模型的子集。
邏輯視圖：包括最重要的設計類、從這些設計類到包和子系統的組織形式，以及從這些包和子系統到層的組織形式。它還包括一些用例實現。它是設計模型的子集。
實施視圖：包括實施模型及其從模塊到包和層的組織形式的概覽。 同時還描述了將邏輯視圖中的包和類向實施視圖中的包和模塊分配的情況。它是實施模型的子集。
進程視圖：包括所涉及任務（進程和線程）的描述，它們的交互和配置，以及將設計對象和類向任務的分配情況。只有在系統具有很高程度的並行時，才需要該視圖。在 Rational Unified Process 中，它是設計模型的子集。
配置視圖：包括對最典型的平台配置的各種物理節點的描述以及將任務（來自進程視圖）向物理節點分配的情況。只有在分布式系統中才需要該視圖。它是部署模型的一個子集。
構架視圖記錄在軟體構架文檔中。您可以構建其他視圖來表達需要特別關注的不同方面：用戶界面視圖、安全視圖、數據視圖等等。對於簡單系統，可以省略 4+1 視圖模型中的一些視圖。

構架重點

雖然以上視圖可以表示系統的整體設計，但構架只同以下幾個具體方面相關：

模型的結構，即組織模式，例如分層。
基本元素，即關鍵用例、主類、常用機制等，它們與模型中的各元素相對。
幾個關鍵場景，它們表示了整個系統的主要控制流程。
記錄模塊度、可選特徵、產品線狀況的服務。

構架視圖在本質上是整體設計的抽象或簡化，它們通過舍棄具體細節來突出重要的特徵。在考慮以下方面時，這些特徵非常重要：

系統演進，即進入下一個開發周期。
在產品線環境下復用構架或構架的一部分。
評估補充質量，例如性能、可用性、可移植性和安全性。
向團隊或分包商分配開發工作。
決定是否包括市售構件。
插入范圍更廣的系統。

構架模式

構架模式是解決復發構架問題的現成形式。構架框架或構架基礎設施（中間件）是可以在其上構建某種構架的構件集。許多主要的構架困難應在框架或基礎設施中進行解決，而且通常針對於特定的領域：命令和控制、MIS、控制系統等等。

構架模式示例

[BUS96] 根據構架模式最適用的系統的特徵將其分類，其中一個類別處理更普遍的結構問題。下表顯示了 [BUS96] 中所提供的類別和這些類別所包含的模式。

類別 模式
結構 層
管道和過濾器
黑板
分布式系統 代理
交互系統 模型-視圖-控制器
表示-抽象-控制
自適應系統 反射
微核

軟體構架是一個容易理解的概念，多數工程師（尤其是經驗不多的工程師）會從直覺上來認識它，但要給出精確的定義很困難。特別是，很難明確地區分設計和構架：構架屬於設計的一方面，它集中於某些具體的特徵。

在「軟體構架簡介」中，David Garlan 和 Mary Shaw 認為軟體構架是有關如下問題的設計層次：「在計算的演算法和數據結構之外，設計並確定系統整體結構成為了新的問題。結構問題包括總體組織結構和全局控制結構；通信、同步和數據訪問的協議；設計元素的功能分配；物理分布；設計元素的組成；定標與性能；備選設計的選擇。」[GS93]

但構架不僅是結構；IEEE Working Group on Architecture 把其定義為「系統在其環境中的最高層概念」[IEEE98]。構架還包括「符合」系統完整性、經濟約束條件、審美需求和樣式。它並不僅注重對內部的考慮，而且還在系統的用戶環境和開發環境中對系統進行整體考慮，即同時注重對外部的考慮。

在 Rational Unified Process 中，軟體系統的構架（在某一給定點）是指系統重要構件的組織或結構，這些重要構件通過介面與不斷減小的構件與介面所組成的構件進行交互。

為闡明其含義，下面將詳述其中的兩個；完整說明請參見 [BUS96]。模式以下列廣泛使用的形式來表示：

模式名
環境
問題
影響，描述應考慮的不同問題方面
解決方案
基本原理
結果環境
示例
模式名
層

環境
需要進行結構分解的大系統。

問題
必須處理不同抽象層次的問題的系統。例如：硬體控制問題、常見服務問題和針對於不同領域的問題。最好不要編寫垂直構件來處理所有抽象層次的問題。否則要在不同的構件中多次處理相同的問題（可能會不一致）。

影響

系統的某些部分應當是可替換的
構件中的變化不應波動
相似的責任應歸為一組
構件大小 -- 復雜構件可能要進行分解
解決辦法
將系統分成構件組，並使構件組形成層疊結構。使上層只使用下層（決不使用上層）提供的服務。盡量不使用非緊鄰下層提供的服務（不跳層使用服務，除非中間層只添加通過構件）。

示例：

1. 通用層

嚴格的分層構架規定設計元素（類、構件、包、子系統）只能使用下層提供的服務， 服務可以包括事件處理、錯誤處理、資料庫訪問等等。 相對於記錄在底層的原始操作系統級調用，它包括更明顯的機制。

2. 業務系統層

上圖顯示了另一個分層示例，其中有垂直特定應用層、水平層和基礎設施層。注意：此處的目標是採用非常短的業務「煙囪」並實現各種應用程序間的通用性。 否則，就可能有多個人解決同一問題，從而導致潛在的分歧。

有關該模式的深入討論，請參見指南：分層。

模式名
黑板

環境
沒有解決問題的確定方法（演算法）或方法不可行的領域。例如 AI 系統、語音識別和監視系統。

問題
多個問題解決顧問（知識顧問）必須通過協作來解決他們無法單獨解決的問題。各顧問的工作結果必須可以供所有其他顧問訪問，使他們可以評估自己是否可以參與解決方案的查找並發布其工作結果。

影響

知識顧問參與解決問題的順序不是確定的，這可能取決於問題解決策略

不同顧問的輸入（結果或部分解決方案）可能有不同的表示方式

各顧問並不直接知道對方的存在，但可以評估對方發布的工作

解決辦法
多名知識顧問都可訪問一個稱為「黑板」的共享資料庫。黑板提供監測和更新其內容的介面。控制模塊/對象激活遵循某種策略的顧問。激活後，顧問查看黑板，以確定它是否能參與解決問題。如果顧問決定它可以參與，控制對象就可以允許顧問將其部分（或最終）解決方案放置於黑板上。

示例：

以上顯示了使用 UML 建模的結構或靜態視圖。 它將成為參數化協作的一部分，然後會綁定到實參上對模式進行實例化。

構架風格
軟體構架（或僅是構架視圖）可以具有名為構架風格的屬性，該屬性減少了可選的形式，並使構架具有一定程度的一致性。樣式可以通過一組模式或通過選擇特定構件或連接器作為基本構件來定義。對給定系統，某些樣式可作為構架描述的一部分記錄在構架風格指南（Rational Unified Process 中設計指南文檔的一部分）中。樣式在構架的可理解性與完整性方面起著主要的作用。

構架設計圖
構架視圖的圖形描述稱為構架設計圖。對於以上描述的各種視圖，設計圖由以下統一建模語言圖組成 [UML99]：

邏輯視圖：類圖、狀態機和對象圖。
進程視圖：類圖與對象圖（包括任務 - 進程與線程）。
實施視圖：構件圖。
部署視圖：配置圖。
用例視圖：用例圖描述用例、主角和普通設計類；順序圖描述設計對象及其協作關系。
構架設計流程
在 Rational Unified Process 中，構架主要是分析設計工作流程的結果。當項目再次進行此工作流程時，構架將在一次又一次迭代中不斷演化、改進、精煉。由於每次迭代都包括集成和測試，所以在交付產品時，構架就相當強壯了。構架是精化階段各次迭代的重點，構架的基線通常會在此階段結束時確定。

架構師

軟體設計師中有一些技術水平較高、經驗較為豐富的人，他們需要承擔軟體系統的架構設計，也就是需要設計系統的元件如何劃分、元件之間如何發生相互作用，以及系統中邏輯的、物理的、系統的重要決定的作出。

這樣的人就是所謂的架構師（Architect）。在很多公司中，架構師不是一個專門的和正式的職務。通常在一個開發小組中，最有經驗的程序員會負責一些架構方面的工作。在一個部門中，最有經驗的項目經理會負責一些架構方面的工作。

但是，越來越多的公司體認到架構工作的重要性，並且在不同的組織層次上設置專門的架構師位置，由他們負責不同層次上的邏輯架構、物理架構、系統架構的設計、配置、維護等工作。

㈦ 軟體結構圖的作用是什麼有哪些構成成分

軟體結構圖是進行軟體結構設計的一種工具，是用來描述軟體結構的圖形工具，這里有張軟體結構圖，直觀啟建你可以看看http://www.studycity.cn/kj/X520400004/course/chapter4/re/
表示軟體模塊的方框可由箭頭或直線聯接，按照慣例軟體結構圖中上方的方框調用下方的，因此用直線仍然可分清調用關系。
帶注視的箭頭（該圖中的紅色箭頭）表示模塊調用種來回傳遞的信息。
菱形代表一個判定，如果為真則調用左邊的模塊，假則調用右邊的模塊。
還有一種弧形箭頭這圖中沒有，它畫在上層模塊與代表調用關系的箭頭或直線的聯接處，穿越每條代表調用關系的箭頭或直線，它表示循環調用下層模塊。

㈧ 軟體結構圖的介紹

軟體結構圖是為了反映軟體系統中組件之間相互關系和約束的體系結構設計圖，稱為軟體體系結構圖更為合適，一般通過分層次或分時間段等方式說明體系結構的各個組成部分的組合關系。在結構化設計方法中，軟體結構圖主要分為變換型軟體結構圖和事務型軟體結構圖兩種。