作用：需求到設計實現的橋梁

• 用于獲取系統中主要的“職責簇”。功能性需求向計算機實現轉化過程的第一步
• 可以產生系統的設計類和子系統，計算機實現時通過某途徑產生出來，而不是拍腦袋出來的。

---

構成：邊界類，實體類，控制類

邊界類：對象A和對象B對象之間進行建模時，充當兩者交互的載體 （架構角度，主要位于展現層）

邊界類常見場景：

• 參與者與用例之間
• 用例與用例之間
• 用例與系統邊界之外的非人對象交互
• 相關聯業務對象有明顯的獨立性要求

特點：

• 提供系統的可用性
• 保持在較高的層次上（概念層次）
• 合理封裝介于系統與主角之間的交互
• 主角改變它們為系統提供的輸入的方式，邊界類就應該是唯一需要改變的對象
• 系統改變主角提供的輸出方式，邊界類就應該是唯一需要改變的對象
• 邊界類必須知道其他對象類型的需求，以便它們能夠得以實施，并相對于系統內部元素保持其可用性和有效性

---

控制類：來源對于用例場景中動詞對的分析和定義，包括限制動詞的描述。具有協調性質，將用例的特有的行為進行封裝。

（架構角度，主要位于業務邏輯）

在設計階段被設計為：Session Bean，COM+,Server Let, JAVA類，C++類等設計類

---

實體類：業務模型中實體?（架構角度，主要位于數據持久層）

在設計階段被設計為：Entity Bean, POJO，SDO, XML Bean等設計類，甚至是一條sql語句

---

分析類三高： 高于設計實現，高于語言實現，高于實現方式? ?（基本停留在 "概念" 階段），專注分析實現需求上，抽象層次較高，比設計和實現更穩定，在一個演進式得軟件生命周期里，維護穩定的分析類比維護易變得設計類花費更少的精力，相對容易獲得一個穩定架構來指導整個軟件的開發。

?

總結

以上是生活随笔為你收集整理的【建模】分析类的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。