摘要： 我們用許多模型來設(shè)計(jì)、開發(fā)、部署和管理技術(shù)解決方案。其中一些模型包括商業(yè)案例（business cases）、用例（use case）圖解、實(shí)體關(guān)系模型、對象模型、代碼、測試套件、開發(fā)計(jì)劃、邏輯數(shù)據(jù)中心模型和異常管理計(jì)劃。軟件生命周期方法已經(jīng)努力發(fā)展成可以自動化的從“上游”模型產(chǎn)生“下游”模型，甚至可以在不同的模型間保持同步。 本文簡要描述了建?？臻g，概覽了當(dāng)前的發(fā)展，這些都可以在整個技術(shù)生命周期中提高模型的使用效率。
模型是真實(shí)世界中對象和系統(tǒng)的 “簡化”抽象,可忽略大小、細(xì)節(jié)和外觀(例如，一個關(guān)注成本或持久性，而忽略不相關(guān)系統(tǒng)因素的模型)。 在信息技術(shù)解決方案的開發(fā)中，模型被用來控制復(fù)雜度，并在客戶、解決方案和系統(tǒng)架構(gòu)師、開發(fā)者和運(yùn)營人員之間傳達(dá)系統(tǒng)需求。
以工程項(xiàng)目大量使用的模型為例：用例模型可表達(dá)系統(tǒng)的高級功能需求和需要被支持的角色；風(fēng)險(xiǎn)模型可通過盡早地在項(xiàng)目周期中規(guī)避風(fēng)險(xiǎn)來優(yōu)化工作；實(shí)體關(guān)系模型捕捉被解決方案管理的基本信息，并且提供將其適當(dāng)分解為表格、對象和服務(wù)的建議；邏輯系統(tǒng)模型組成了開發(fā)和運(yùn)營之間的通信基礎(chǔ)；邏輯系統(tǒng)模型可以進(jìn)行需求和解決方案策略的早期確認(rèn)，等等。
所有這些模型都使項(xiàng)目參與者能在最終系統(tǒng)的開發(fā)和管理中發(fā)揮其專長。所有這些模型都通過盡早避免誤解和疏忽來減少項(xiàng)目的代價和風(fēng)險(xiǎn)。建模工具和框架通過在各個級別的方案設(shè)計(jì)中提供更高級別的追溯性、可視性和說明性促進(jìn)了商業(yè)部門和信息技術(shù)團(tuán)體的合作。
在整個的軟件生命周期-從開發(fā)概念形成到運(yùn)營和管理中，微軟關(guān)注如何使模型更有使用價值。由于歷史原因，在生命周期中通行的僅有的模型是含義模糊、冗余和很不完善的模型，而且是使用系統(tǒng)源代碼所描述。系統(tǒng)模型之間的不協(xié)調(diào)經(jīng)常在組織內(nèi)部和其間造成理解和溝通錯誤，導(dǎo)致項(xiàng)目和系統(tǒng)的失敗。
微軟的目標(biāo)是讓所有的項(xiàng)目參與者--技術(shù)人員，專家和管理者都能夠獲取公司組織系統(tǒng)最適時、精確和有效的描述，并表達(dá)為各自熟悉的語言。微軟的意圖是使所有的項(xiàng)目參與者--從商業(yè)分析員到數(shù)據(jù)架構(gòu)師，還有安全專家和網(wǎng)絡(luò)工程師，在解決方案的開發(fā)過程中盡可能的發(fā)揮他們的專長，盡量減少信息和知識的損失。
某些模型力圖在多個抽象層面上描述一個完全的系統(tǒng)。另外的模型則著重于系統(tǒng)的某些特定方面，諸如怎樣保持安全性，或者從系統(tǒng)的各個方面跟蹤性能表現(xiàn)。某些模型與解決的創(chuàng)建和開發(fā)過程有關(guān)，還有一些則預(yù)測并分析其在運(yùn)營中的行為。
用例圖有可能是軟件工程中的最簡單的“完全”模型：系統(tǒng)的用例集合建立了對系統(tǒng)功能的展望，為系統(tǒng)用戶確定角色，并且提出了對運(yùn)營的需求。用例可以發(fā)展成商務(wù)過程模型，派生出詳盡的需求模型，數(shù)據(jù)模型，對象模型，和最終的可編輯模型。 這些模型的層疊使人們聯(lián)想起軟件工程中熟悉的“瀑布”的概念。
系統(tǒng)建模的一個更好的概念是一系列的鎖定。不是隨隨便便的，被工具支持的系統(tǒng)化過程應(yīng)該在良好的管理下從一個模型遞交給下一個模型。 遞交過程應(yīng)該是平滑可預(yù)見的。 最重要的是，這些遞交應(yīng)該是雙向的。用例應(yīng)可以被轉(zhuǎn)換成為商業(yè)過程模型，而商業(yè)過程模型也應(yīng)該是能轉(zhuǎn)換成用例的(雖然由于信息損失，你不能全保真的完成從客觀到抽象再到客觀的完整轉(zhuǎn)換周期)。理想情況下，這種映射的階梯流要允許所有描述系統(tǒng)的模型之間的同步。
在項(xiàng)目中支持這些相互映射模型的集合，將產(chǎn)生模型驅(qū)動 (model-driven development MDD)的開發(fā)模式。 在MDD中，模型成為開發(fā)過程中的最重要的原材料之一。 當(dāng)一個系統(tǒng)架構(gòu)模型允許或禁止橫跨企業(yè)數(shù)據(jù)中心安全區(qū)域的信息路徑時，這個模型就指導(dǎo)和約束了服務(wù)模型，很有可能影響服務(wù)設(shè)計(jì)。當(dāng)數(shù)據(jù)架構(gòu)模型確定數(shù)據(jù)訪問方法，工具就產(chǎn)生代理代碼和語言捆綁。MDD并不是一種全新的想法；成功的實(shí)現(xiàn)了模型同步的例子包括，多視圖數(shù)據(jù)建模工具，它可以使圖例化模型，基于實(shí)體的模型，和相關(guān)的數(shù)據(jù)架構(gòu)都保持同步，還有就是可以在開發(fā)中保持外觀和代碼模型一致性的集成開發(fā)環(huán)境設(shè)計(jì)器。 我們可以從這些案例中汲取成功經(jīng)驗(yàn)以大大擴(kuò)寬MDD的應(yīng)用范圍。
模型是真實(shí)世界中對象和系統(tǒng)的 “簡化”抽象,可忽略大小、細(xì)節(jié)和外觀(例如，一個關(guān)注成本或持久性，而忽略不相關(guān)系統(tǒng)因素的模型)。 在信息技術(shù)解決方案的開發(fā)中，模型被用來控制復(fù)雜度，并在客戶、解決方案和系統(tǒng)架構(gòu)師、開發(fā)者和運(yùn)營人員之間傳達(dá)系統(tǒng)需求。
以工程項(xiàng)目大量使用的模型為例：用例模型可表達(dá)系統(tǒng)的高級功能需求和需要被支持的角色；風(fēng)險(xiǎn)模型可通過盡早地在項(xiàng)目周期中規(guī)避風(fēng)險(xiǎn)來優(yōu)化工作；實(shí)體關(guān)系模型捕捉被解決方案管理的基本信息，并且提供將其適當(dāng)分解為表格、對象和服務(wù)的建議；邏輯系統(tǒng)模型組成了開發(fā)和運(yùn)營之間的通信基礎(chǔ)；邏輯系統(tǒng)模型可以進(jìn)行需求和解決方案策略的早期確認(rèn)，等等。
所有這些模型都使項(xiàng)目參與者能在最終系統(tǒng)的開發(fā)和管理中發(fā)揮其專長。所有這些模型都通過盡早避免誤解和疏忽來減少項(xiàng)目的代價和風(fēng)險(xiǎn)。建模工具和框架通過在各個級別的方案設(shè)計(jì)中提供更高級別的追溯性、可視性和說明性促進(jìn)了商業(yè)部門和信息技術(shù)團(tuán)體的合作。
在整個的軟件生命周期-從開發(fā)概念形成到運(yùn)營和管理中，微軟關(guān)注如何使模型更有使用價值。由于歷史原因，在生命周期中通行的僅有的模型是含義模糊、冗余和很不完善的模型，而且是使用系統(tǒng)源代碼所描述。系統(tǒng)模型之間的不協(xié)調(diào)經(jīng)常在組織內(nèi)部和其間造成理解和溝通錯誤，導(dǎo)致項(xiàng)目和系統(tǒng)的失敗。
微軟的目標(biāo)是讓所有的項(xiàng)目參與者--技術(shù)人員，專家和管理者都能夠獲取公司組織系統(tǒng)最適時、精確和有效的描述，并表達(dá)為各自熟悉的語言。微軟的意圖是使所有的項(xiàng)目參與者--從商業(yè)分析員到數(shù)據(jù)架構(gòu)師，還有安全專家和網(wǎng)絡(luò)工程師，在解決方案的開發(fā)過程中盡可能的發(fā)揮他們的專長，盡量減少信息和知識的損失。
某些模型力圖在多個抽象層面上描述一個完全的系統(tǒng)。另外的模型則著重于系統(tǒng)的某些特定方面，諸如怎樣保持安全性，或者從系統(tǒng)的各個方面跟蹤性能表現(xiàn)。某些模型與解決的創(chuàng)建和開發(fā)過程有關(guān)，還有一些則預(yù)測并分析其在運(yùn)營中的行為。
用例圖有可能是軟件工程中的最簡單的“完全”模型：系統(tǒng)的用例集合建立了對系統(tǒng)功能的展望，為系統(tǒng)用戶確定角色，并且提出了對運(yùn)營的需求。用例可以發(fā)展成商務(wù)過程模型，派生出詳盡的需求模型，數(shù)據(jù)模型，對象模型，和最終的可編輯模型。 這些模型的層疊使人們聯(lián)想起軟件工程中熟悉的“瀑布”的概念。
系統(tǒng)建模的一個更好的概念是一系列的鎖定。不是隨隨便便的，被工具支持的系統(tǒng)化過程應(yīng)該在良好的管理下從一個模型遞交給下一個模型。 遞交過程應(yīng)該是平滑可預(yù)見的。 最重要的是，這些遞交應(yīng)該是雙向的。用例應(yīng)可以被轉(zhuǎn)換成為商業(yè)過程模型，而商業(yè)過程模型也應(yīng)該是能轉(zhuǎn)換成用例的(雖然由于信息損失，你不能全保真的完成從客觀到抽象再到客觀的完整轉(zhuǎn)換周期)。理想情況下，這種映射的階梯流要允許所有描述系統(tǒng)的模型之間的同步。
在項(xiàng)目中支持這些相互映射模型的集合，將產(chǎn)生模型驅(qū)動 (model-driven development MDD)的開發(fā)模式。 在MDD中，模型成為開發(fā)過程中的最重要的原材料之一。 當(dāng)一個系統(tǒng)架構(gòu)模型允許或禁止橫跨企業(yè)數(shù)據(jù)中心安全區(qū)域的信息路徑時，這個模型就指導(dǎo)和約束了服務(wù)模型，很有可能影響服務(wù)設(shè)計(jì)。當(dāng)數(shù)據(jù)架構(gòu)模型確定數(shù)據(jù)訪問方法，工具就產(chǎn)生代理代碼和語言捆綁。MDD并不是一種全新的想法；成功的實(shí)現(xiàn)了模型同步的例子包括，多視圖數(shù)據(jù)建模工具，它可以使圖例化模型，基于實(shí)體的模型，和相關(guān)的數(shù)據(jù)架構(gòu)都保持同步，還有就是可以在開發(fā)中保持外觀和代碼模型一致性的集成開發(fā)環(huán)境設(shè)計(jì)器。 我們可以從這些案例中汲取成功經(jīng)驗(yàn)以大大擴(kuò)寬MDD的應(yīng)用范圍。