『壹』 用什麼工具畫 軟體架構設計圖
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網站的線框圖、流程圖、原型和規格說明文檔。
『貳』 什麼是軟體系統結構圖的寬度
軟體系統結構圖的寬度是指整體控制跨度（最大模塊數的層）的表示。
軟體產品線架構就是說根據一個公司或者是某一個組織內部那些一系列的產品所進行設計的相應的通用架構。那麼就能夠了解到這樣的一系列產品存在著特別多的相似之處那麼這些能夠藉助同一個架構或者部分共享來實施具體實現，使得生產率得到最大限度的提升。
(2)軟體架構的圖片擴展閱讀：
相應的系統存在著性能、強壯性、可擴展性、靈活性、可靠性等這些非功能性特徵。設計系統的架構比要讓系統架構設計人員存在著過硬的軟體與硬體的性能與功能，往往從事這樣的工作這是屬於設計系統架構環節最為困難的工作。
『叄』 軟體架構的視圖
我們決定以多種構架視圖來表示軟體構架。每種構架視圖針對於開發流程中的涉眾（例如最終用戶、設計人員、管理人員、系統工程師、維護人員等）所關注的特定方面。
構架視圖顯示了軟體構架如何分解為構件，以及構件如何由連接器連接來產生有用的形式 [PW92]，由此記錄主要的結構設計決策。這些設計決策必須基於需求以及功能、補充和其他方面的約束。而這些決策又會在較低層次上為需求和將來的設計決策施加進一步的約束。
構架由許多不同的構架視圖來表示，這些視圖本質上是以圖形方式來摘要說明「在構架方面具有重要意義」的模型元素。在 Rational Unified Process 中，您將從一個典型的視圖集開始，該視圖集稱為「4+1 視圖模型」[KRU95]。它包括：
用例視圖：包括用例和場景，這些用例和場景包括在構架方面具有重要意義的行為、類或技術風險。它是用例模型的子集。
邏輯視圖：包括最重要的設計類、從這些設計類到包和子系統的組織形式，以及從這些包和子系統到層的組織形式。它還包括一些用例實現。它是設計模型的子集。
實施視圖：包括實施模型及其從模塊到包和層的組織形式的概覽。 同時還描述了將邏輯視圖中的包和類向實施視圖中的包和模塊分配的情況。它是實施模型的子集。
進程視圖：包括所涉及任務（進程和線程）的描述，它們的交互和配置，以及將設計對象和類向任務的分配情況。只有在系統具有很高程度的並行時，才需要該視圖。在 Rational Unified Process 中，它是設計模型的子集。
配置視圖：包括對最典型的平台配置的各種物理節點的描述以及將任務（來自進程視圖）向物理節點分配的情況。只有在分布式系統中才需要該視圖。它是部署模型的一個子集。構架視圖記錄在軟體構架文檔中。
您可以構建其他視圖來表達需要特別關注的不同方面：用戶界面視圖、安全視圖、數據視圖等等。對於簡單系統，可以省略 4+1 視圖模型中的一些視圖。
『肆』 軟體系統架構圖 用visio畫 怎麼新建
用VISIO畫的分層架構設計圖
『伍』 圖解幾種常見的軟體架構模式
本篇經驗將和大家介紹幾種常見的軟體架構模式，希望對大家的工作和學習有所幫助！
方法/步驟分層模式
這種模式也稱為多層體系架構模式。它可以用來構造可以分解為子任務組的程序，每個子任務都處於一個特定的抽象級別。每個層都為下一個提供更高層次服務。
一般信息系統中最常見的是如下所列的4層。
表示層(也稱為UI層)
應用層(也稱為服務層)
業務邏輯層(也稱為領域層)
數據訪問層(也稱為持久化層)
使用場景：
一般的桌面應用程序
電子商務Web應用程序
客戶端-伺服器模式
這種模式由兩部分組成：一個伺服器和多個客戶端。伺服器組件將為多個客戶端組件提供服務。客戶端從伺服器請求服務，伺服器為這些客戶端提供相關服務。此外，伺服器持續偵聽客戶機請求。
使用場景：
電子郵件，文件共享和銀行等在線應用程序
主從設備模式
這種模式由兩方組成;主設備和從設備。主設備組件在相同的從設備組件中分配工作，並計算最終結果，這些結果是由從設備返回的結果。
使用場景：
在資料庫復制中，主資料庫被認為是權威的來源，並且要與之同步
在計算機系統中與匯流排連接的外圍設備(主和從驅動器)
管道-過濾器模式
此模式可用於構造生成和處理數據流的系統。每個處理步驟都封裝在一個過濾器組件內。要處理的數據是通過管道傳遞的。這些管道可以用於緩沖或用於同步。
使用場景：
編譯器。連續的過濾器執行詞法分析、解析、語義分析和代碼生成
生物信息學的工作流
代理模式
此模式用於構造具有解耦組件的分布式系統。這些組件可以通過遠程服務調用彼此交互。代理組件負責組件之間的通信協調。
伺服器將其功能(服務和特徵)發布給代理。客戶端從代理請求服務，然後代理將客戶端重定向到其注冊中心的適當服務。
使用場景：
消息代理軟體，如Apache ActiveMQ，Apache Kafka，RabbitMQ和JBoss Messaging
點對點模式
在這種模式中，單個組件被稱為對等點。對等點可以作為客戶端，從其他對等點請求服務，作為伺服器，為其他對等點提供服務。對等點可以充當客戶端或伺服器或兩者的角色，並且可以隨時間動態地更改其角色。
使用場景：
像Gnutella和G2這樣的文件共享網路
多媒體協議，如P2PTV和PDTP
像Spotify這樣的專有多媒體應用程序
事件匯流排模式
這種模式主要是處理事件，包括4個主要組件：事件源、事件監聽器、通道和事件匯流排。消息源將消息發布到事件匯流排上的特定通道上。偵聽器訂閱特定的通道。偵聽器會被通知消息，這些消息被發布到它們之前訂閱的一個通道上。
使用場景：
安卓開發
通知服務
模型-視圖-控制器模式
這種模式，也稱為MVC模式，把一個互動式應用程序劃分為3個部分，
模型：包含核心功能和數據
視圖：將信息顯示給用戶(可以定義多個視圖)
控制器：處理用戶輸入的信息
這樣做是為了將信息的內部表示與信息的呈現方式分離開來，並接受用戶的請求。它分離了組件，並允許有效的代碼重用。
使用場景：
在主要編程語言中互聯網應用程序的體系架構
像Django和Rails這樣的Web框架
黑板模式
這種模式對於沒有確定解決方案策略的問題是有用的。黑板模式由3個主要組成部分組成。
黑板——包含來自解決方案空間的對象的結構化全局內存
知識源——專門的模塊和它們自己的表示
控制組件——選擇、配置和執行模塊
所有的組件都可以訪問黑板。組件可以生成添加到黑板上的新數據對象。組件在黑板上查找特定類型的數據，並通過與現有知識源的模式匹配來查找這些數據。
使用場景：
語音識別
車輛識別和跟蹤
蛋白質結構識別
聲納信號的解釋
解釋器模式
這個模式用於設計一個解釋用專用語言編寫的程序的組件。它主要指定如何評估程序的行數，即以特定的語言編寫的句子或表達式。其基本思想是為每種語言的符號都有一個分類。
使用場景：
資料庫查詢語言，比如SQL
用於描述通信協議的語言
『陸』 軟體工程中軟體結構圖和層次圖的異同
結構圖主要用於呈現各業務模塊之間的關系：
『柒』 軟體結構圖的介紹
軟體結構圖是為了反映軟體系統中組件之間相互關系和約束的體系結構設計圖，稱為軟體體系結構圖更為合適，一般通過分層次或分時間段等方式說明體系結構的各個組成部分的組合關系。在結構化設計方法中，軟體結構圖主要分為變換型軟體結構圖和事務型軟體結構圖兩種。
『捌』 軟體結構中層次方框圖與層次圖的區別
1、作用不同：模塊結構圖表現的是上下級模塊之間層次化的調用和控制關系，功能層次圖只展示任務的分解，不涉及數據的流動。
2、矩形框表示不同：層次圖只表示上層任務可同哪些子任務協同完成，不管順序與調用，嚴格按層次畫出，不同任務的相同子任務也分別重畫。方框代表一個模塊，方框之間的直線表示模塊的調用關系，尾部是空心圓箭頭表示傳遞的是數據；尾部實心圓箭頭表示傳遞的是控制信息。
3、連線不同：功能層次圖實際上就是數據流程圖去掉數據處理外的所有其他元素，再按層次集成為一張完整的圖。個矩形框代表一個模塊方框間的連線表示調用關系而不像層次方框圖那樣表示組成關系。
(8)軟體架構的圖片擴展閱讀：
注意事項：
請求一般先走網關。攔截非法請求，分發分流（負載均衡）。
請求到達應用層伺服器，處理業務。假如這單台伺服器發生故障（單點故障），整個系統就掛。所以對應需要做冗餘、集群，保證請求能分發到集群中的某一台應用伺服器，是能正常工作的。
在設計軟體體系結構的時候，必須考慮有現有系統的兼容性、安全性和可靠性。
『玖』 軟體結構圖怎麼畫
軟體體系結構參考圖如下：
－Paul Clements 《軟體架構編檔》
正如上面提到的，不同的受眾，比如用戶、客戶、開發人員、測試人員、運維人員，需要從各自工作的角度去理解和使用架構。所以回答這個問題，需要首先了解這幅架構圖畫出來是給誰看，你想從那個維度去入手。
確定了這個問題之後，再來了解架構視圖有哪些維度和組成要素：
1. 架構視圖
最經典的當屬4+1視圖：
- 邏輯視圖
- 開發視圖
- 過程視圖
- 物理視圖
- 場景視圖
4+1視圖提出後，業界也有其它的觀點提出，諸如SEI(模塊視圖、組建和連接件視圖、分配視圖)、西門子4種視圖（概念、模塊、代碼、執行視圖）、以及RM-ODP(企業視圖、信息視圖、計算視圖、工程師圖）等。
常見的視圖除了上述4+1視圖外還包括：數據視圖、安全視圖、實現視圖等。
2. 了解架構視圖的四要素
- 圖示化主要元素和元素之間的關系
- 具有明確的圖例、定義和說明元素
- 每個元素具備明確的介面和行為規范
- 設計原理和設計決策的信息
3. 簡單說一下幾個視圖針對的角色和維度：
邏輯視圖一般針對客戶、用戶、業務人員、開發組織，主要從系統的功能元素、以及它們的介面、職責、交互維度入手。主要元素包括系統、子系統、功能模塊、子功能模塊、介面等。
開發視圖一般針對開發和測試相關人員，主要描述系統如何開發實現；主要元素包括描述系統的分層、分區、框架、系統通用服務、業務通用服務、類和介面、系統平台和大基礎框架。用途是知道開發設計和實現。
物理視圖一般針對系統運維人員、集成人員，它是系統邏輯組件到物理節點的映射，節點與節點間的物理網路配置等，主要關注非功能性需求，諸如性能（吞吐量）、可伸縮性、可靠性，可用性等，從而得出相關的物理部署結構圖。
『拾』 軟體工程中軟體結構圖和層次圖的異同
兩者之間沒有區別。兩者指的均是軟體構架，為軟體系統的草圖。
軟體工程中軟體結構圖和層次圖均是為了反映軟體系統中組件之間相互關系和約束的體系結構設計圖，屬於一系列相關的抽象模式，用於指導大型軟體系統各個方面的設計。
軟體結構圖（又被叫做軟體構架）一般通過分層次或分時間段等方式說明體系結構的各個組成部分的組合關系。描述的對象是直接構成系統的抽象組件，各個組件之間的連接則明確和相對細致地描述組件之間的通訊關系。
(10)軟體架構的圖片擴展閱讀：
其他介紹：
軟體結構圖包括架構元件、聯結器、任務流。所謂架構元素，也就是組成系統的核心磚瓦，而聯結器則描述這些元件之間通訊的路徑、通訊的機制、通訊的預期結果，任務流則描述系統如何使用這些元件和聯結器完成某一項需求。
通過一個軟體結構圖建造一個系統所作出的最高層次的、以後難以更改的，商業的和技術的決定。在建造一個系統之前會有很多的重要決定需要事先作出，而一旦系統開始進行詳細設計甚至建造，這些決定就很難更改甚至無法更改。顯然，這樣的決定必定是有關系統設計成敗的最重要決定，必須經過非常慎重的研究和考察。