很多做軟體開發同學的夢想都是成為一名架構師，而架構師的核心工作就是做好軟體設計。軟體設計是軟體開發過程中的乙個重要環節，那麼如何進行軟體設計，其輸出標準又是什麼呢？軟體設計過程中，如何和各個相關方溝通，使軟體設計能同時滿足使用者的功能需求和非功能需求，並降低公司的開發成本？很多軟體開發同學的職業規劃都是架構師，試想這樣乙個場景，如果公司安排你做架構師，讓你在專案開發前期進行了一些架構設計。
架構師的核心工作就是做好軟體架構設計，軟體設計是軟體開發過程中乙個重要的環節。
以上這些訴求可以說是軟體開發管理與技術的核心訴求，這些問題搞定了，軟體的開發過程和結果也就得到了保障。
我們再來看看，解決這些問題你需要理解的核心關鍵點，也就是說究竟如何做軟體設計，解決方法就是軟體建模，就是軟體的抽象模型，這些模型之上配上文字說明，就形成了軟體的設計文件。
模型是對客觀存在的抽象，在軟體開發中有兩個客觀存在：
乙個是我們要解決的領域問題，比如我們要開發乙個電子商務**，那麼客觀的領域問題就是如何做生意，賣家如何管理商品，管理訂單服務使用者，買家如何挑選商品，如何下單，如何支付等等，對於這些客觀領域問題的抽象就是各種功能及其關係，各種模型物件及其關係，各種業務處理流程。
另乙個客觀存在就是最終開發出來的軟體系統，這個軟體系統也是客觀存在的。
所以這兩方面的客觀存在的抽象就是我們的軟體模型。
一方面，我們要對領域問題和軟體系統進行分析，設計抽象，另一方面，我們根據抽象出來的模型，進行軟體開發，這就是軟體開發的主要過程。
而對領域問題和軟體系統進行分析，設計抽象，這個過程我們稱它為軟體建模與設計。
軟體建模工具很多，目前主要是統一建模語言uml。
所謂的建模，就是對領域問題和軟體系統進行抽象設計，乙個工具完成前述軟體開發過程中的兩個客觀存在的建模。
而所謂的語言，一則用於溝通，滿足設計階段和各個相關方溝通的目的，一則用於思考，即使軟體開發過程中不需要跟其他人溝通，或者還沒有到了溝通的時候，依然可以使用uml建模，幫助自己進行設計思考。
此外，語言還有個特點，就是有方言，就我觀察不同公司，不同團隊，都有自己的特點，並不需要拘泥於以往那樣規範和語法，只要不引起歧義，在使用過程中對語法元素適當變通，這是uml的最佳實踐。
軟體建模與設計過程又可以拆分成需求分析，概要設計，詳細設計三個階段，而軟體建模的主要工具是uml，下面我們看一下使用方法包含了哪些軟體模型，常用的有7種。
下面我們討論這7種模型圖，如何在三個階段使用。
類圖是最常見的uml圖形，用來描述類的特性和類之間的靜態關係，乙個類包含三個部分，類的名稱，類的屬性列表，類的方法列表之間有6種靜態關係關聯，關聯，依賴，聚合，組合，繼承，泛化，而相關的一組類及其關係，用一張圖畫出來就是類圖，類圖主要是在詳細設計階段化，如果內圖已經設計出來了，那麼開發工程師只需要按照內圖實現**就可以了，只要類的方法邏輯不是太複雜，不同的工程是實現出來的**幾乎是一樣的，從而保證軟體的規範統一。
實踐中通常不需要把乙個軟體所有的類都畫出來，把核心的有代表性的，有一定技術難度的內畫出來，一般就可以了，除了在詳細設計階段畫類圖，在需求分析階段，也可以將關鍵的領域模型物件圖，用例圖畫出來，這個階段，關注的是領域物件的識別及其關係，所以通常用簡化的類圖來描述。
序列圖描述類之間的關係，描述參與者自己的動態呼叫關係，每個參與者有一條垂直向下的生命線，用虛線表示，而參與者之間的訊息，也從上到下表示其呼叫的前後順序關係。
每個生命線都有個結果，只有在參與者活動的時候才是啟用的，序列圖通常用於描述物件之間的互動，這個物件可以是類物件，也可以是更大粒度的參與者，比如元件，比如伺服器，比如子系統。總之，只要描述不同參與者之間的互動的，都可以使用序列圖，也就是說，在軟體設計的各個階段，都可以畫序列圖。
元件是更大粒度的設計元素，乙個元件中通常包含多個類，元件圖有時候和包的用途比較接近，元件可以描述邏輯上的元件，也可以描述物理上的元件，比如乙個jar，乙個dll的，因此元件圖更靈活一點，實踐中，用元件圖而不是包圖進行模組設計更常見一些。
元件圖描述中間之間的靜態關係，主要是依賴關係，如果想要描述元件之間的動態呼叫關係，可以使用元件序列圖，以組建作為參與者，描述元件之間的訊息呼叫關係，因為元件的力度比較粗，通常用於描述設計軟體的模組及其之間的關係，需要在設計早期階段就畫出來。
他是描述軟體系統的最終部署情況，需要部署多少臺伺服器？關鍵元件都部署在哪些伺服器上？部署圖呈現的是系統最終物理呈現的藍圖。
因此，部署圖是整個軟體設計模型中比較巨集觀的一張圖，在設計早期就需要畫的一張模型圖。根據部署，各方可以討論是否對這個方案認可，只有對部署圖達成共識，才能夠繼續後面的細節設計，部署圖主要用在概要設計階段。
主要在需求分析階段，通過反映使用者和軟體系統之間的互動，描述軟體的功能需求，圖中小人物被稱為角色，角色可以是人，也可以是其他的系統，系統的功能可能會很複雜，所以乙個用例圖，可能只包含其中一小部分功能，這些功能被乙個巨型框框起來，這個巨型框被稱為用力的邊界，框裡的橢圓，表示乙個乙個的功能，功能之間可以呼叫依賴，也可以進行功能擴充套件，因為用例圖中功能描述比較簡單，通常還需要對用例圖配以文字說明，形成需求文件。
用來展示單個物件生命週期的狀態變更，業務系統中，很多重要的領域物件對於比較複雜的狀態變遷，比如賬號，有創業狀態，啟用狀態，凍結狀態，欠費狀態等等各種狀態，因此，使用者訂單商品紅包這些常見的領域模型，都有多種狀態，這些狀態的變遷描述，可以在用例圖中用文字描述，隨著角色的各種操作而改變，但是這種描述方式，狀態散落在各處，做開發的時候容易搞錯，就是產品經理自己在設計的時候，也容易搞錯物件的狀態變遷，狀態圖可以很好的解決這一問題。
一張狀態圖描述乙個物件生命週期的各種狀態及其變遷的關係。
主要用來描述過程邏輯，業務流程。uml中沒有流程圖，很多時候人們用活**代替流程圖，活**和早期流程圖的圖形元素也很接近.
實心圓代表流程開始，空心圓代表流程結束，圓角矩形表示活動，菱形表示分支判斷，此外，引入了乙個重要的概念，泳道。可以根據活動的範圍，將活動根據領域，系統角色的，劃分到不同的泳道中，使流程邊界更加清晰明了。
模型圖本身並不複雜，幾分鐘的時間就可以學習乙個模型圖的畫法。難的是如何在合適的場合下用正確的uml模型，表達自己的設計意圖，從而形成一套完整的軟體模型，進而組織起乙個言之有物，層次分明，可以指導開發，在團隊內部達成共識的設計文件。
我們從軟體設計的不同階段這一維度重新梳理一下，如何使用正確的模型進行軟體建模。
在需求分析階段，主要是通過用例圖描述系統的功能與使用場景；對於關鍵的業務流程，可以通過活**描述。如果在需求階段，就提出要和現有的某些子系統整合，可以通過時序圖，描述新系統和原來的子系統的呼叫關係。
核心領域物件，可以通過簡化的類圖進行模型領域抽象，並描述核心領域物件之間的關係。
如果某些物件內部有複雜的狀態變化，比如使用者，訂單這些，可以用狀態圖進行描述。
在概要設計階段，通過部署圖，描述系統最終的物理藍圖，通過元件圖以及元件時序圖，設計軟體主要模組及其關係，還可以通過組建活**，描述元件之間的流程邏輯。
架構師主要做些什麼，你知道嗎？
小夥伴們，新年好！感謝大家對 it老兵哥 原創文章的支援頂贊，把有價值的知識或經驗分享給更多人，在分享中提公升個人價值，這是我寫作 分享的初衷和動力，在新的一年裡我會更加努力，也希望能夠繼續獲得各位小夥伴的支援！堅持原創不易，如果文章有價值，千萬要記得在手動點個 推薦 哦，祝大家新年在家庭 事業和生...
什麼是架構師
什麼是架構師？架構師是軟體行業中的新興角色，主導系統全域性的分析設計和實施 負責軟體構架和關鍵技術決策。架構師的工作職責 在軟體專案開發過程中，將客戶的需求轉化為規範的開發計畫和文字，並指定這個專案的總體架構，指導整個開發團隊完成這個計畫。梁永昌，趨勢科技研究部和軟體系統架構部副總裁 軟體架構師的工...
什麼是架構師
軟體行業架構師兩個定義 系統架構師是乙個既需要掌控整體又需要洞悉區域性瓶頸並依據具體的業務場景給出解決方案的人。具體來說是乙個確認和評估系統需求，給出開發規範，搭建系統實現的核心構架，並澄清技術細節 掃清主要難點的技術人員。主要著眼於系統的 技術實現 因此他 她應該是特定的開發平台 語言 工具的大師...