建模的價值

2019-11-17 04:43:50

字體：大中小

來源：轉載

供稿：網友

引言

本白皮書將討論建模在軟件開發過程中的價值。建模的概念并非新鮮出爐——資深軟件專業人士已經有過多年的建模實踐。但是在主流軟件開發社區中，只有一部分軟件開發人員對他們的軟件開發進行了建模。本白皮書將考查什么是促進軟件建模實踐的基礎。本白皮書旨在為精通軟件建模的人員、一無所知的人員，以及聽說過但從未實踐過的人員，闡述建模實踐所能帶來的利益和價值。

什么是建模？

多年以來，業務分析人員、工程師、科學家，以及其他構建復雜結構或系統的專業人員已經為他們所構建的系統創建了模型。有時是物理模型，例如，飛機、房子或者汽車的按一定比例制作的實物大模型，有時候模型并不是那么明確，如商業金融模型、市場貿易模擬以及電子電路圖。在所有情況下，模型作為一種抽象——即被構建的真實事物的近似代表。

為什么建模？

為什么在構建某些事物之前首先要建模？或許不需要。簡單的事物不需要在創建之前進行建?！?，一個簡單的支票簿簽發記錄、簡單的貨幣換算工具、一間犬舍或者用于打開一組常規文件的字處理程序中的宏。

這樣的項目具有下列全部或大部分特點：

問題域很清楚。

相對來說易于構建解決方案。

需要很少的人進行協作來構建或使用該解決方案（通常只有一個人）。

該解決方案需要最少量的持續維護。

未來需要的范圍不會有實質性的擴大。

但是假如假設這些特點都不具備呢？為什么一些專業人員要費心去創建模型呢？為什么他們不直接構建具體事物呢？答案在于復雜性和風險，并且最初的專業人員并不是一直適合開發任務，甚至根本不能完成任務。

建模使架構師及其他人員能夠可視化整個系統，評估不同選擇，并且更清楚地交流設計，從而避免了技術風險、財務風險或實際的構建風險。假如不先創建一項設計、一個藍圖或者另一個抽象表示，就直接構建某種復雜系統，在技術上是不明智的、在經濟上也是行不通的。盡管專業建筑師無需設計圖就可以建造一間犬舍，但是假如他們不首先開發一批計劃、圖和某種可視化實物模型，那么就不能建造一幢15層的辦公大樓。

為什么對軟件進行建模？

多年以來，軟件開發實踐置于建模話題之外。由于其本質屬性，軟件易于創建和變更。幾乎不需要固定設備，并且實際上沒有制造成本。這些屬性孕育了一種DIY（do-it-yourself）文化——每當需要時才進行構思、構建及變更?？傊疀]有“最終”系統，那么為什么在編寫代碼之前還要進行構思呢？

今天，軟件系統已經變得非常復雜。它們必須與其他系統進行集成，來運行日常生活中用到的對象。例如，汽車現在大規模裝備了計算機及相關軟件，用來控制從引擎和定速控制到所有新的車載導航和通訊系統的各個方面。軟件還經常用于自動處理各種業務流程——諸如客戶看見并經歷過的那些業務流程，和后臺辦公的業務流程。

一些軟件支持健康有關或財產有關的重要功能，這就使得開發、測試以及維護必定很復雜。甚至那些對健康或者財產不是非凡要害的系統對于業務來說卻非常要害。在許多組織中，軟件開發已經不再是居于成本中心的孤立事物——而成為公司戰略性業務流程的一個整體部分。對這些公司來說，軟件已經成為市場競爭中一個要害的鑒別標志。

在許多組織中，軟件開發已經不再是居于成本中心的孤立事物－―而成為公司戰略性業務流程的一個整體部分。

由于很多方面的原因，開發者需要更好的理解他們正在構建什么，建模為此提供了有效的方法。同時，建模一定不要影響開發速度?？蛻艉蜆I務用戶始終希望軟件能夠按時交付以及能夠像所期望的那樣具有隨需應變的功效。為了達到這種“速度與質量并重”的目標，IBM 提出了軟件開發的四項必要措施：迭代開發、重視構架、持續的質量保證以及治理變更和資產。

其他復雜的高風險系統建模的相同理由同樣適用于軟件——治理復雜性并理解設計和相關的風險。尤其是通過軟件建模，開發人員能夠：

在提交額外的資源之前創建并交流軟件設計。

從設計追溯到需求階段，有助于確保構建正確的系統。

進行迭代開發，在開發中，模型和其他的更高層次的抽象推動了快速而頻繁的變更。

為什么一些開發人員不選擇軟件建模？

盡管建模有許多原因和優點，但是仍然有很大一部分軟件開發人員不在源代碼更高的層次上進行任何形式的抽象。這是為什么呢？正如前面描述的那樣，有時候問題或者解決方案的實際復雜度無需建模。再一次重申，假如您預備建造一間犬舍，您根本就不需要雇傭一個建筑師或者聘請一位建造者來做一系列的設計規格說明。但是在軟件世界中，系統經常是開始時簡單并且易于理解，在通過一系列成功實施的自然演進，就變得越來越復雜。在其他情況中，開發人員不采用建模的簡單理由是沒有熟悉到建模的需要，直到很遲的時候才察覺到建模的必要。

許多人爭論，軟件建模的阻力更多的是來自文化上的因素而不是其他的。傳統的程序員對于通常的編寫代碼的技術非常擅長。甚至遭碰到不希望的復雜情況的時候，大多數開發人員仍然堅持使用他們的集成開發環境（IDE）和調試工具，以及在問題上花費更多的時間。因為建模需要額外的培訓和工具，并且相應地需要額外的時間、財力和工作量上的投資―－不是正式開發工作的時間，而是在項目開發生命周期早期的時間。傳統開發人員在這方面不超前的原因在于，他們認為建模將減慢他們的速度。在下一節中將幫助人們消除這種觀念。

何時建模？

為復雜的應用程序建模有幾項一般獲益。在某些特定情況下，建模工作是值得的，這包括：

為了更好理解手頭上的業務情況或工程情況（“as-is”模型）并且為了設計更好的系統（“to-be”模型）

為了構建和設計系統的構架

為了創建可視化代碼和其他實施形式

建模不主張全有或全無（all-or-nothing）。模型可以在軟件開發過程的很多方面發揮作用。圖1描述了實踐模型驅動開發的方法的使用范圍。

集成的開發環境

在建模的最自由的概念中，集成開發環境（IDE）可以看作是模型驅動開發實踐的入口點?，F在的集成開發環境在創建和維護代碼方面提供了許多提高抽象層次方面的機制。有許多工具，例如，諸如語言敏感的編輯器、導航器、表單生成器和其他GUI控制，在更嚴格的術語上講都不算是模型。但是，它們能夠提高源代碼之上的抽象層次，提高開發人員的生產率，幫助創建更可靠的代碼，以及提供更高效的維護過程。所有的這些屬性都是模型驅動開發的本質。建模的價值（圖一）

圖1 時間、地點及建模方法的范圍圖 QQRead.com 推出數據恢復指南教程數據恢復指南教程數據恢復故障解析常用數據恢復方案硬盤數據恢復教程數據保護方法數據恢復軟件專業數據恢復服務指南引言

本白皮書將討論建模在軟件開發過程中的價值。建模的概念并非新鮮出爐——資深軟件專業人士已經有過多年的建模實踐。但是在主流軟件開發社區中，只有一部分軟件開發人員對他們的軟件開發進行了建模。本白皮書將考查什么是促進軟件建模實踐的基礎。本白皮書旨在為精通軟件建模的人員、一無所知的人員，以及聽說過但從未實踐過的人員，闡述建模實踐所能帶來的利益和價值。

什么是建模？

多年以來，業務分析人員、工程師、科學家，以及其他構建復雜結構或系統的專業人員已經為他們所構建的系統創建了模型。有時是物理模型，例如，飛機、房子或者汽車的按一定比例制作的實物大模型，有時候模型并不是那么明確，如商業金融模型、市場貿易模擬以及電子電路圖。在所有情況下，模型作為一種抽象——即被構建的真實事物的近似代表。

為什么建模？

為什么在構建某些事物之前首先要建模？或許不需要。簡單的事物不需要在創建之前進行建模——例如，一個簡單的支票簿簽發記錄、簡單的貨幣換算工具、一間犬舍或者用于打開一組常規文件的字處理程序中的宏。

這樣的項目具有下列全部或大部分特點：

問題域很清楚。

相對來說易于構建解決方案。

需要很少的人進行協作來構建或使用該解決方案（通常只有一個人）。

該解決方案需要最少量的持續維護。

未來需要的范圍不會有實質性的擴大。

但是假如假設這些特點都不具備呢？為什么一些專業人員要費心去創建模型呢？為什么他們不直接構建具體事物呢？答案在于復雜性和風險，并且最初的專業人員并不是一直適合開發任務，甚至根本不能完成任務。

建模使架構師及其他人員能夠可視化整個系統，評估不同選擇，并且更清楚地交流設計，從而避免了技術風險、財務風險或實際的構建風險。假如不先創建一項設計、一個藍圖或者另一個抽象表示，就直接構建某種復雜系統，在技術上是不明智的、在經濟上也是行不通的。盡管專業建筑師無需設計圖就可以建造一間犬舍，但是假如他們不首先開發一批計劃、圖和某種可視化實物模型，那么就不能建造一幢15層的辦公大樓。

為什么對軟件進行建模？

多年以來，軟件開發實踐置于建模話題之外。由于其本質屬性，軟件易于創建和變更。幾乎不需要固定設備，并且實際上沒有制造成本。這些屬性孕育了一種DIY（do-it-yourself）文化——每當需要時才進行構思、構建及變更。總之沒有“最終”系統，那么為什么在編寫代碼之前還要進行構思呢？

今天，軟件系統已經變得非常復雜。它們必須與其他系統進行集成，來運行日常生活中用到的對象。例如，汽車現在大規模裝備了計算機及相關軟件，用來控制從引擎和定速控制到所有新的車載導航和通訊系統的各個方面。軟件還經常用于自動處理各種業務流程——諸如客戶看見并經歷過的那些業務流程，和后臺辦公的業務流程。

一些軟件支持健康有關或財產有關的重要功能，這就使得開發、測試以及維護必定很復雜。甚至那些對健康或者財產不是非凡要害的系統對于業務來說卻非常要害。在許多組織中，軟件開發已經不再是居于成本中心的孤立事物——而成為公司戰略性業務流程的一個整體部分。對這些公司來說，軟件已經成為市場競爭中一個要害的鑒別標志。

在許多組織中，軟件開發已經不再是居于成本中心的孤立事物－―而成為公司戰略性業務流程的一個整體部分。

由于很多方面的原因，開發者需要更好的理解他們正在構建什么，建模為此提供了有效的方法。同時，建模一定不要影響開發速度?？蛻艉蜆I務用戶始終希望軟件能夠按時交付以及能夠像所期望的那樣具有隨需應變的功效。為了達到這種“速度與質量并重”的目標，IBM 提出了軟件開發的四項必要措施：迭代開發、重視構架、持續的質量保證以及治理變更和資產。

其他復雜的高風險系統建模的相同理由同樣適用于軟件——治理復雜性并理解設計和相關的風險。尤其是通過軟件建模，開發人員能夠：

在提交額外的資源之前創建并交流軟件設計。

從設計追溯到需求階段，有助于確保構建正確的系統。

進行迭代開發，在開發中，模型和其他的更高層次的抽象推動了快速而頻繁的變更。

為什么一些開發人員不選擇軟件建模？

盡管建模有許多原因和優點，但是仍然有很大一部分軟件開發人員不在源代碼更高的層次上進行任何形式的抽象。這是為什么呢？正如前面描述的那樣，有時候問題或者解決方案的實際復雜度無需建模。再一次重申，假如您預備建造一間犬舍，您根本就不需要雇傭一個建筑師或者聘請一位建造者來做一系列的設計規格說明。但是在軟件世界中，系統經常是開始時簡單并且易于理解，在通過一系列成功實施的自然演進，就變得越來越復雜。在其他情況中，開發人員不采用建模的簡單理由是沒有熟悉到建模的需要，直到很遲的時候才察覺到建模的必要。

許多人爭論，軟件建模的阻力更多的是來自文化上的因素而不是其他的。傳統的程序員對于通常的編寫代碼的技術非常擅長。甚至遭碰到不希望的復雜情況的時候，大多數開發人員仍然堅持使用他們的集成開發環境（IDE）和調試工具，以及在問題上花費更多的時間。因為建模需要額外的培訓和工具，并且相應地需要額外的時間、財力和工作量上的投資―－不是正式開發工作的時間，而是在項目開發生命周期早期的時間。傳統開發人員在這方面不超前的原因在于，他們認為建模將減慢他們的速度。在下一節中將幫助人們消除這種觀念。

何時建模？

為復雜的應用程序建模有幾項一般獲益。在某些特定情況下，建模工作是值得的，這包括：

為了更好理解手頭上的業務情況或工程情況（“as-is”模型）并且為了設計更好的系統（“to-be”模型）

為了構建和設計系統的構架

為了創建可視化代碼和其他實施形式

建模不主張全有或全無（all-or-nothing）。模型可以在軟件開發過程的很多方面發揮作用。圖1描述了實踐模型驅動開發的方法的使用范圍。

集成的開發環境

在建模的最自由的概念中，集成開發環境（IDE）可以看作是模型驅動開發實踐的入口點?，F在的集成開發環境在創建和維護代碼方面提供了許多提高抽象層次方面的機制。有許多工具，例如，諸如語言敏感的編輯器、導航器、表單生成器和其他GUI控制，在更嚴格的術語上講都不算是模型。但是，它們能夠提高源代碼之上的抽象層次，提高開發人員的生產率，幫助創建更可靠的代碼，以及提供更高效的維護過程。所有的這些屬性都是模型驅動開發的本質。建模的價值（圖一）

圖1 時間、地點及建模方法的范圍圖

上一篇：解析UML的靜態建模機制

下一篇：界面需求的分析方法