圖 9. 將項目產品組織到定義完善的抽象層次中的 RUP 配置
| • |
域。域層次捕獲項目的業務環境。 | ||||||||||||
| • |
項目洞察力。項目洞察力對系統將會有的對企業的業務影響進行通訊。它以投資回報分析量化了這個影響。項目洞察力表示該項目的最高抽象層次。 | ||||||||||||
| • |
業務處理。系統層次為公司內的業務處理建模。對于極其復雜的單位來說，這個層次可以再細分到子層次：部門、部門間以及部門內。 | ||||||||||||
| • |
UI 規范。UI 規范設計了實現業務處理的用戶界面。它是由 UI 設計文檔和功能 UI 原型組成的。 | ||||||||||||
| • |
詳細要求。詳細要求指定了系統要求的最低層次抽象。它包括諸如數據類型格式和詳細業務規則等詳細信息。它還包括專業性要求，例如，性能、可用性、安全性、國際化、配置、可擴展性和靈活性要求等。 | ||||||||||||
| • |
體系結構。系統的體系結構被組織到六個視圖中：
|
優點
將系統產品組織到離散的抽象層次有若干優點：
| • |
它將系統要求分離到三個不同的抽象層次：業務處理、UI 規范和詳細要求。我們不會再用令企業用戶感到不知所措的單個整體功能規范了。取而代之，我們在三個改進的詳細層次中對系統要求進行通訊。 |
| • |
分析師和架構師可以將復雜性控制在一個單一的、集成的系統模型中。 |
| • |
架構師可以專注于系統的單個方面，并將那些決策集成到整個解決方案中。 |
| • |
抽象層次形成了系統產品的結構。舉例來說，軟件體系結構文檔為每個視圖專設了一個小節。 |
| • |
抽象層次提供從要求到設計再到實現的直接可跟蹤能力�？筛櫮芰κ剐〗M能夠在評測更改請求時執行精確的影響評估。 |
| • |
在使用同一框架開發幾個系統之后，會在每個抽象層次形成模式。單位可以編錄這些模式和每個抽象層次內的其他最佳實踐。這個最佳實踐的目錄會作為過程改進計劃的基礎。 |
小結
為了處理復雜性，所有工程學科都應用正式抽象層次。軟件也不例外。為了實現抽象層次的優點，項目必須：
| • |
正式標識層次，每個層次都有定義完善的范圍。 |
| • |
將一個層次內的復雜性分開到多個視圖。 |
| • |
在層次間保持一致性。 |
通過一個簡單的示例，本文演示了如何應用抽象層次，然后將該方法擴展到支持企業 IT 解決方案。它提供了一個 RUP 配置框架，該框架將系統產品組織到定義完善的抽象層次。
自我評估
| • |
您當前的項目是否應用了抽象層次？ |
| • |
層次是否定義完善？ |
| • |
項目團隊是否很好地理解了這些層次？ |
| • |
如果復雜性在一個層次中變得過大，團隊是否將其分離到視圖中呢？ |
| • |
團隊是否在層次間保持一致性？ |
| • |
您的項目會從抽象層次中獲益嗎？ |
偉大的架構師本能地遵循這些原則。我們其余的人就必須有意識地應用抽象層次，并運用規則在整個項目生命周期中保持這些層次。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
