假如你是架構師，你要作些什麼

不少作軟件開發同窗的夢想都是成爲一名架構師，而架構師的核心工做就是作好軟件設計。軟件設計是軟件開發過程當中的一個重要環節，那麼如何進行軟件設計，其輸出標準又是什麼呢？軟件設計過程當中，如何和各個相關方溝通，使軟件設計能同時知足用戶的功能需求和非功能需求，並下降公司的開發成本？　

前期思考

　　不少軟件開發同窗的職業規劃都是架構師，試想這樣一個場景，若是公司安排你作架構師，讓你在項目開發前期進行了一些架構設計。

• 你該如何開展你的工做？
• 應該如何說出你的工做成果？
• 你如何肯定你的設計是否知足用戶需求的？
• 你是否有把握最後交付的軟件是知足要求的？
• 是否有把握讓軟件團隊每一個工程師清晰瞭解本身的職責範圍，並有效的完成開發工做?

　　架構師的核心工做就是作好軟件架構設計，軟件設計是軟件開發過程當中一個重要的環節。

• 如何進行軟件設計？
• 軟件設計的輸出是什麼？
• 軟件升級過程當中如何和各個相關方溝通？
• 軟件設計如何既能知足用戶的功能需求，又能知足用戶的非功能需求，也能知足用戶的成本要求？
• 如何可以使開發工程師，測試工程師，運維工程師，理解軟件的總體架構，主要模塊劃分，關鍵技術實現，核心領域模型，使他們可以作好本身的工做，從而使整個軟件開發過程，處於一個可控的範圍以內，並在軟件開發之初，就對軟件將來的藍圖有個清晰的認識？

　　以上這些訴求能夠說是軟件開發管理與技術的核心訴求，這些問題搞定了，軟件的開發過程和結果也就獲得了保障。

核心關鍵點

兩個客觀存在

　　咱們再來看看，解決這些問題你須要理解的核心關鍵點，也就是說究竟如何作軟件設計，解決方法就是軟件建模，就是軟件的抽象模型，這些模型之上配上文字說明，就造成了軟件的設計文檔。

　　模型是對客觀存在的抽象，在軟件開發中有兩個客觀存在：

　　一個是咱們要解決的領域問題，好比咱們要開發一個電子商務網站，那麼客觀的領域問題就是如何作生意，賣家如何管理商品，管理訂單服務用戶，買家如何挑選商品，如何下單，如何支付等等，對於這些客觀領域問題的抽象就是各類功能及其關係，各類模型對象及其關係，各類業務處理流程。

　　另外一個客觀存在就是最終開發出來的軟件系統，這個軟件系統也是客觀存在的。

• 軟件有哪些主要組成？
• 這些類如何組織成一個一個的組件？
• 這些內核組件之間的依賴關係是如何的？
• 運行期如何調用，須要部署多少臺服務器？
• 服務器之間如何通訊？

　　因此這兩方面的客觀存在的抽象就是咱們的軟件模型。

　　一方面，咱們要對領域問題和軟件系統進行分析，設計抽象，另外一方面，咱們根據抽象出來的模型，進行軟件開發，這就是軟件開發的主要過程。

　　

　　而對領域問題和軟件系統進行分析，設計抽象，這個過程咱們稱它爲軟件建模與設計。

UML工具

　　軟件建模工具不少，目前主要是統一建模語言UML。

　　所謂的建模，就是對領域問題和軟件系統進行抽象設計，一個工具完成前述軟件開發過程當中的兩個客觀存在的建模。

　　而所謂的語言，一則用於溝通，知足設計階段和各個相關方溝通的目的，一則用於思考，即便軟件開發過程當中不須要跟其餘人溝通，或者尚未到了溝通的時候，依然可使用UML建模，幫助本身進行設計思考。

　　此外，語言還有個特色，就是有方言，就我觀察不一樣公司，不一樣團隊，都有本身的特色，並不須要拘泥於以往那樣規範和語法，只要不引發歧義，在使用過程當中對語法元素適當變通，這是UML的最佳實踐。

　　軟件建模與設計過程又能夠拆分紅需求分析，概要設計，詳細設計三個階段，而軟件建模的主要工具是UML，下面咱們看一下使用方法包含了哪些軟件模型，經常使用的有7種。

7種軟件模型

　　下面咱們討論這7種模型圖，如何在三個階段使用。

類圖

　　

　　類圖是最多見的UML圖形，用來描述類的特性和類之間的靜態關係，一個類包含三個部分，類的名稱，類的屬性列表，類的方法列表之間有6種靜態關係關聯，關聯，依賴，聚合，組合，繼承，泛化，而相關的一組類及其關係，用一張圖畫出來就是類圖，類圖主要是在詳細設計階段化，若是內圖已經設計出來了，那麼開發工程師只須要按照內圖實現代碼就能夠了，只要類的方法邏輯不是太複雜，不一樣的工程是實現出來的代碼幾乎是同樣的，從而保證軟件的規範統一。

　　實踐中一般不須要把一個軟件全部的類都畫出來，把核心的有表明性的，有必定技術難度的內畫出來，通常就能夠了，除了在詳細設計階段畫類圖，在需求分析階段，也能夠將關鍵的領域模型對象圖，用例圖畫出來，這個階段，關注的是領域對象的識別及其關係，因此一般用簡化的類圖來描述。

序列圖

　　

　　序列圖描述類之間的關係，描述參與者本身的動態調用關係，每一個參與者有一條垂直向下的生命線，用虛線表示，而參與者之間的消息，也從上到下表示其調用的先後順序關係。

　　每一個生命線都有個結果，只有在參與者活動的時候纔是激活的，序列圖一般用於描述對象之間的交互，這個對象能夠是類對象，也能夠是更大粒度的參與者，好比組件，好比服務器，好比子系統。總之，只要描述不一樣參與者之間的交互的，均可以使用序列圖，也就是說，在軟件設計的各個階段，均可以畫序列圖。

組件圖

　　

　　組件是更大粒度的設計元素，一個組件中一般包含多個類，組件圖有時候和包的用途比較接近，組件能夠描述邏輯上的組件，也能夠描述物理上的組件，好比一個JAR，一個DLL的，所以組件圖更靈活一點，實踐中，用組件圖而不是包圖進行模塊設計更常見一些。

　　組件圖描述中間之間的靜態關係，主要是依賴關係，若是想要描述組件之間的動態調用關係，可使用組件序列圖，以組建做爲參與者，描述組件之間的消息調用關係，由於組件的力度比較粗，一般用於描述設計軟件的模塊及其之間的關係，須要在設計早期階段就畫出來。

部署圖

　　

　　他是描述軟件系統的最終部署狀況，須要部署多少臺服務器？關鍵組件都部署在哪些服務器上？部署圖呈現的是系統最終物理呈現的藍圖。

• 根據部署圖，全部相關者，客戶，老闆，工程師，都可以清晰的瞭解到最終運行的系統，物理上是什麼樣子？和現有系統服務器的關係，和第三方服務器的關係。
• 根據部署圖，還能夠估算出服務器和第三方軟件的採購成本。

　　所以，部署圖是整個軟件設計模型中比較宏觀的一張圖，在設計早期就須要畫的一張模型圖。根據部署，各方能夠討論是否對這個方案承認，只有對部署圖達成共識，纔可以繼續後面的細節設計，部署圖主要用在概要設計階段。

用例圖

　　

　　主要在需求分析階段，經過反映用戶和軟件系統之間的交互，描述軟件的功能需求，圖中小人物被稱爲角色，角色能夠是人，也能夠是其餘的系統，系統的功能可能會很複雜，因此一個用例圖，可能只包含其中一小部分功能，這些功能被一個巨型框框起來，這個巨型框被稱爲用力的邊界，框裏的橢圓，表示一個一個的功能，功能之間能夠調用依賴，也能夠進行功能擴展，由於用例圖中功能描述比較簡單，一般還須要對用例圖配以文字說明，造成需求文檔。

狀態圖

　　

　　用來展現單個對象生命週期的狀態變動，業務系統中，不少重要的領域對象對於比較複雜的狀態變遷，好比帳號，有創業狀態，激活狀態，凍結狀態，欠費狀態等等各類狀態，所以，用戶訂單商品紅包這些常見的領域模型，都有多種狀態，這些狀態的變遷描述，能夠在用例圖中用文字描述，隨着角色的各類操做而改變，可是這種描述方式，狀態散落在各處，作開發的時候容易搞錯，就是產品經理本身在設計的時候，也容易搞錯對象的狀態變遷，狀態圖能夠很好的解決這一問題。

　　一張狀態圖描述一個對象生命週期的各類狀態及其變遷的關係。

活動圖

　　

　　主要用來描述過程邏輯，業務流程。UML中沒有流程圖，不少時候人們用活動圖代替流程圖，活動圖和早期流程圖的圖形元素也很接近.

　　實心圓表明流程開始，空心圓表明流程結束，圓角矩形表示活動，菱形表示分支判斷，此外，引入了一個重要的概念，泳道。能夠根據活動的範圍，將活動根據領域，系統角色的，劃分到不一樣的泳道中，使流程邊界更加清晰明瞭。

總結

　　模型圖自己並不複雜，幾分鐘的時間就能夠學習一個模型圖的畫法。難的是如何在合適的場合下用正確的UML模型，表達本身的設計意圖，從而造成一套完整的軟件模型，進而組織起一個言之有物，井井有條，能夠指導開發，在團隊內部達成共識的設計文檔。

　　咱們從軟件設計的不一樣階段這一維度從新梳理一下，如何使用正確的模型進行軟件建模。

需求分析

　　在需求分析階段，主要是經過用例圖描述系統的功能與使用場景；對於關鍵的業務流程，能夠經過活動圖描述。若是在需求階段，就提出要和現有的某些子系統整合，能夠經過時序圖，描述新系統和原來的子系統的調用關係。

　　核心領域對象，能夠經過簡化的類圖進行模型領域抽象，並描述核心領域對象之間的關係。

　　若是某些對象內部有複雜的狀態變化，好比用戶，訂單這些，能夠用狀態圖進行描述。

概要設計

　　在概要設計階段，經過部署圖，描述系統最終的物理藍圖，經過組件圖以及組件時序圖，設計軟件主要模塊及其關係，還能夠經過組建活動圖，描述組件之間的流程邏輯。

詳細設計

　　在詳細設計階段，主要輸出的就是類圖和類的時序圖，直到最終的代碼開發，若是某個類方法內部，有比較複雜的邏輯，那麼能夠畫方法的活動圖進行描述，UML的工具能夠是很複雜的，收費的，好比EA這樣的大型軟件工具。也可使用processon在線的免費的工具。對於通常的開發者，建議從簡單的用起，由於那個建模能夠很複雜，也能夠很簡單，簡單掌握類圖，時序圖，組件圖，部署圖，用例圖，狀態圖，活動圖。在7種模型圖，靈活的在需求分析，概要設計詳細設計階段，根據場景的不一樣，繪製對應的模型圖，能夠實實在在的作好軟件建模，搞好系統設計，做爲一個掌控局面，引領技術團隊的架構師。

來源：http://www.javashuo.com/article/p-ciajrhcf-er.html 歡迎關注公衆號 【碼農開花】一塊兒學習成長 我會一直分享Java乾貨，也會分享免費的學習資料課程和麪試寶典 回覆：【計算機】【設計模式】【面試】有驚喜哦