一切皆可抽象

業務用例對角色（什么樣的個體和接口訪問到我們識別出來的各種業務任務）
業務對象對業務對象（各個業務對象之間是如何彼此交互的，和他們共享信息的種類）
用例對用例（任務彼此之間的依賴，和被一定的過程共享的公用任務

用例設計誤區
用例被創建的太大或者太小 －－ 粒度問題
用例在跨越團隊的情況下不一致? －－ 用例一致性（形式 含義）
沒有對用例分組的包進行良好的計劃? －－ 模塊劃分不合理
不合理的對模型的訪問進行控制，導致在團隊分析協作的過程中發生沖突? －－ 開放式團隊管理
過于細致的定義用例，在用例進入原型、設計和開發任務之前就定義每一件事情? －－ 粒度太小 需求確定的可以這么做 不穩定的當抽象為主 對應變更
定義用例時過于簡單，使需求被工程團隊可以有眾多的解釋? －－ 言語還是不確定 無法用語言表達的借助圖形 圖形無法描述的 定義術語集合 語言支持

角色模型
模塊模型

在從用例向設計類轉化的過程中，我們希望能夠實現：

將分析小組的知識傳授給工程團隊。?? －－ 文檔傳承 結構合理易于理解的文檔（加以詳細注釋）不失為最好的選擇
識別能夠滿足所有需求的技術方案 — 或者，什么地方不是可能的，識別與技術方案沖突的需求，并確定是否他們是重要的或者被改變或者被刪除。
?－－ 需求階段應該加入這樣的分析和模型了
識別能夠幫助確定團隊結構、架構層次和對于購買軟件的候選的接口。
?－－ 整合好的方案 不能整合的以清晰的頭腦單做
指定技術方案的細節并開始計劃如何在團隊之中分配工作。
?－－
基于設計模型的細化時間進行計劃和預算的預估。
?－－ 經驗 改進
分配類到平臺、產品和私有代碼。
?－－ 拿手完
為了反饋和同步的目的，生成軟件架構文檔，軟件架構文檔能夠被分發到內部和外部的團隊成員。
?－－ 傳承溝通

我們如何組織通用的服務？
回答：公用服務被單獨的放在一個子包中（日志服務；數據同步和備份服務；訪問控制服務和登陸服務）。
我們應該在 shipping 和 part management 之間畫線嗎？
回答: 我們不需要連接他們兩個。
我們根據領域還是架構來定義子系統？
回答：架構在大多數地方都能與領域結合。
我們允許包之間的雙向依賴嗎？
回答：不。這是違背我們內部設計指導方針的不好的設計實踐。
MDA 的觀點下有四個原則：

以一種定義良好的符號表示的模型是理解企業級方案系統的基礎。
系統的構建能夠圍繞著一系列模型通過使用在模型之間的一系列轉換被組織的，并且能被組織到一個分層的和轉換的體系架構框架中。
以一系列元模型來描述模型的一種正式的支持能力能夠使在模型中有意義的集成和轉換變得容易，并且是通過工具實現自動化的基礎。
接受和廣泛采納基于模型的方法需要工業的標準提供開放性給客戶，并鼓勵供應商之間的競爭。

OMG已經定義了一系列的層次和轉換，他們為MDA提供了概念性的框架和詞匯表。
特別的，OMG 確定了四種模型類型：
計算無關的模型（CIM），
平臺無關的模型（PIM），
被一個平臺模型（PM）描述的平臺相關的模型（PSM）和
一個實現相關的模型（ISM）。

問題領域模型和方案領域模型
業務建模 數據建模 安全建模 性能建模
狹義上講，它是關于一個系統的不同抽象模型，和在模型之間定義良好的模型轉換的。
廣義上講，它是關于抽象的各種級別上的模型，這些抽象作為基礎為軟件架構服務，這些架構最終將通過各種實現技術被實現。