[Arch] 03. Practice UML in project

學前複習

• 搜索：跟我學UML建模工具StarUML 系列文章

第一部分，下載和安裝及破解StarUML工具軟件

第二部分，StarUML工具軟件的主要功能界面和UML圖的建立示例

 

• 第一篇、[Design Patterns] 01. Before Design Patterns - UML

結合starUML，在項目中如何靈活使用各類Diagram。

 

• 第二篇、[Design Patterns] 02. Design principle and Software Pattern

在Diagram內部設計時，方針是什麼：SOLID原則

以及若干軟件模式：

- 體系結構模式，好比MVC，高層次的架構設計，須要先肯定。

- 分析模式，不懂～

- 過程模式，項目開始後的各個階段，每一個階段理論上能夠有對應的文檔。

- 設計模式，一線碼農對待具體問題時需掌握的各類代碼設計技巧。

 

 

StarUML經常使用圖表

1、概覽

 

UML Minimal	Model	Main
UML Conventional	Use Case Model	Use Cases用例圖	Analysis Model	Analysis	Design Model	Classes	Implementtation Model	Components	Deployment Model	Deployment
4+1 View Model	Scenarios	Scenarios用例圖	Logical View	Logical View類圖	Development View	Developmenet View類圖、組件圖	Process View	Process View無徹底對應	Physical View	Physical View部署圖
Rational	Use Case View	Use Case View	Logical View	Logical View	Component View	Component View			Deployment View	Deployment View
Data Model	Data Model	Main

方法有許多，選一個4+1便可。 

 

 

2、4+1 View Model

Ref: 4+1VIEW 軟件系統視角模型

特色介紹

用於同時表達軟件系統架構之多種觀點的模型。 
從系統共同利益人的角度(包括end-user、開發者和項目管理者)，分紅4個觀點。

　　

 

• DevelopmentView (開發觀點):

從開發人員的角度來看軟件的管理，也被稱做implementation view。他使用了UML圖中的Componentdiagram來表達組件，Package diagram則用來表達更大型的系統。

 

• LogicalView (邏輯觀點):

關心的是系統提供給end-user的功能。可表達的UML圖包含activitydiagram, class diagram, state diagram。

 

• Physicalview (實體觀點): 

系統工程師的觀點，關心的是系統 拓樸，包含組件之間實體上怎麼鏈接。其也被稱做deployment diagram。

包含的UML圖有deploymentdiagram

• Processview (進程觀點):

着重在動態方面，關注解釋系統在執行中的動做和組件如何溝通，用以解決同步問題、發佈問題、整合問題、效能問題等等。
可表的UML圖爲 activitydiagram

• Scenarios (使用情景):

使用某些用例來描述系統架構，被稱爲第5個視角，也被稱做use caseview，一般被用做測試雛型階段的初始動做，被用來驗證架構設計正確性。 

 

 

3、學習總結

Jeff 筆記：

項目初期，Scenarios的用例圖，以及配合更詳細的用例規約表格，需求分析。

以後，LogicalView的活動圖、狀態圖　是須要文檔的。

而後就是，DevelopmentView的組件圖，若是涉及多線程則考慮Process View。

最後就是，Physicalview的部署圖，包括數據庫的設計。

以上即是最起碼須要掌握的。

實踐筆記：

Back-end設計 

需求分析：用例圖，用例規約 

業務流程：活動圖，狀態圖

部署架構：數據庫

Front-end設計

功能設計：UI流程圖

 

 

軟件工程各階段的開發文檔

Ref: 軟件工程各階段的開發文檔

一：開發文檔1.0（需求分析階段）

    所需材料：與客戶面對面交流，經過一些針對性的引導問題讓客戶描述目標產品的要求。好比：您遇到了什麼樣的業務需求？您想作出一個怎樣的東西去解決這個問題？

                  在這個系統中，會有哪些人（用戶角色）？您的業務流程是怎樣的？每一種角色，分別用這個系統作什麼？

    生成文檔：從採集到的需求資料中得出《開發文檔1.0》，主要有三部份內容：

                一：系統概述：系統設計初衷（遇到的問題、想系統怎麼解決這個問題）

                二：用戶角色：有什麼角色會使用這個系統

                三：概要需求：系統的功能、每一個角色會怎麼使用這個系統

 

　　【系統概述＋基本用例圖】

 

二：開發文檔2.0+項目計劃書（概要設計階段）

    所需材料：把《開發文檔1.0》交予客戶審覈確認修改。而後同時再次溝通，獲取整個系統的使用流程、各個角色的使用流程、整個系統的具體功能列表。

    生成文檔：《開發文檔2.0》：在《開發文檔1.0》基礎上，補全、新增：

                 三：概要需求：補全系統使用流程圖、各個角色的使用流程圖

                 四：功能列表：得出系統功能列表、每一個角色模塊的功能列表

                 五：系統架構：採用什麼架構來開發這個系統

                《項目計劃書》：根據《開發文檔2.0》大概估計項目的開發成本（時間、資源），而後針對各個項目模塊的功能做出相應報價

                 一：開發成本彙報：所需時間、人力物力

                 二：項目模塊報價：各個功能模塊的功能列表以及實現這個模塊的報價

                 三：總體項目報價

 

　　【系統架構＋詳細用例圖＋業務流程圖＋報價】

 

三：開發文檔3.0（詳細設計階段）

    所需材料：《開發文檔2.0》與《項目計劃書》交付客戶審覈、確認、溝通修改，獲取客戶進一步的要求。

    生成文檔：《開發文檔3.0》：在《開發文檔2.0》的基礎上新增：

                 六：功能詳細設計：對每一個角色的的每一個功能進行詳細設計，主要包括：

                                    1：功能描述

                                    2：功能流程

                                    3：界面Demo     

                                    4：數據規約

                                    5：數據實體　　----> 開始思考」類「

 

　　【功能詳細設計(僞UI) + 數據規約】

 

四：開發文檔4.0（詳細設計階段）

    所需材料：《開發文檔3.0》交予客戶審覈確認，特別是對詳細設計部分的功能描述、界面Demo等做出確認。

    生成文檔：《開發文檔4.0》：在《開發文檔3.0》基礎上新增：

                 七：模塊劃分：對角色各個功能進行劃分，成爲系統的模塊。

                 八：數據庫設計：由詳細設計部分涉及到的數據實體與數據規約，以及對角色功能劃分後獲得的系統模塊，進行數據庫設計（建立什麼表？表中屬性有哪些？）

 

　　【肯定系統各個子模塊＋數據庫設計】  <----　架構內部細節逐漸清晰

 

五：開發文檔5.0（詳細設計階段）

    所需材料：《開發文檔4.0》

    生成材料：根據《開發文檔4.0》中的數據庫設計，對 第六點：功能詳細設計  作出補充完善：

                                   6：設計數據庫中的表

                                   7：功能實現的架構（把功能流程用架構表示，如：交互的操做在 XX.jsp，請求傳給 xxservlet、數據操做 xx數據表）

 

補充：軟件工程各階段的UML圖

詳細設計階段的類圖。

詳細設計階段的時序圖。

 

　　【進一步補充、完善】

    

六：根據《開發文檔5.0》進行編碼開發工做，生成《註釋文檔》

七：單元測試、集成測試、系統測試，生成《測試日誌》

八：編寫《用戶使用手冊》，交付並指導客戶使用

 

  

課外參考

Ref: 深刻業務成爲更好的軟件架構師——信息化建設圖鑑一二例

Ref: 孫宇聰 《SRE: Google運維解密》

Ref: 王概凱(Kevin) 《聊聊架構》

 

軟件的終極目標是模擬業務

王概凱(Kevin)的《聊聊架構》，其中特別強調軟件架構師應深刻到業務中，並以業務的問題是否解決做爲工做優良的判斷標準。

 

• • 在明確了業務主體後，業務目標天然就能夠獲得聚焦，
  • 有了清晰的業務目標，就值得花精力來探知業務的生命週期，
  • 接下來就能夠像外科手術醫生同樣細緻地實行架構拆分。

因而可知，軟件架構師在實行架構拆分行爲時，基本上都把業務從頭至尾捋了一遍，不然勢必陷入設計不足或過分設計的漩渦。

 

強調了「軟件運行生命週期」的重要性

孫宇聰在高可用架構裏提到的《SRE: Google運維解密》

 

在軟件運行這樣一個最爲核心的生命週期中，發佈更新的質量直接影響到企業信息部門的運維表現，結合孫宇聰的諸多建議我也列舉一些值得注意的要點：

• • 線下測試（Offline Test）。重點檢查線下測試環境是否完善，除此以外還須要產品人員和開發人員的督促。除了通常的代碼邏輯測試，儘可能再兼顧到壓力測試。

  • 灰度發佈（Gray Released）。指的是根據業務特色、數據特色來選擇一批有極強表明性的線上服務器實例進行發佈，其發佈的比例能夠考慮按 1%、10%，最後 100% 這一指數型方式來增加。這樣有利於把新上線功能可能的不良影響降到最低，固然也能夠做爲小範圍收集用戶的反饋意見以待完善產品功能。灰度發佈能夠視做是上線前的最後一道安全防禦機制。

  • 回滾機制（Rollback）。通常來講用上一個版本的相關程序集進行覆蓋便可，但有時還會出現數據格式的兼容性問題。好比數據庫表字段的類型此前發生了變化，那這時候還須要有配套的回滾 SQL 腳本。另外一種情形是新的變動內容把數據刪掉了，回滾後數據也回不來了，這種狀況是沒有補救措施的，建議的作法是將程序代碼分紅兩塊邏輯，先發布第一段邏輯並記錄好日誌，等發現沒有問題後再將刪除的代碼做爲第二次發佈。

 

End.