面向對象開發中的本質用例及其職責（4）

討論

在本章中，將討論幾個與本質用例相關的面向對象設計主題，包括：

· 無界面系統（實時系統）設計；

· 定制界面系統的設計；

· 迭代和增量開發過程；

· 界面和應用的并行開發；

· 基于業務過程的面向對象設計。

1.無界面系統（實時系統）設計

在實時系統和軟件引擎中，系統只與系統主角交互，并且沒有傳統的人機界面，那么，能否采用本質用例呢？答案是肯定的。本質用例同樣適用于這類系統。

在這類系統中，有一個重要概念就是“外部世界（outside world）”。在任何系統中，都需要對系統的內部和外部進行明確的劃分，從而確定系統的邊界；確定系統交互的原則（無論是人還是機器）；設計交互方式。我們發現，在這樣的系統中，本質用例同樣有許多優點。在適當的抽象層次上，本質用例擺脫了表達和實現的具體細節的束縛，能夠更準確的捕捉用戶意圖和系統職責的本質，它不受具體系統類型限制，簡潔明了，易于理解，便于編輯，方便復審，可以實現分析和設計的無縫連接和平滑過渡。

系統常常有一些附加的非功能性約束，例如響應時間、交換速率、信息容量、可靠性等。因為用例著眼于交互的過程，所以不是發現和確定這類需求的理想工具。但是，它可以幫助記錄和管理這類需求。在常規用例方法中，通常采用文字描述的方法，并與用例同步管理，且其管理過程與用例結構無關。本質用例也可以采用類似的方法。在以用為中心的設計中，這類指標往往與本質用例相關，因為它們對高性能的用戶界面設計至關重要。

本質用例的系統職責、系統對象的職責以及中間對象的職責之間的可追溯性彌補了系統設計的不足，保證系統滿足這類非功能性指標的要求。例如，用例級的系統約束可以分解到對象中，對象的性能又直接影響到用例職責。采用公共任務標簽的辦法可以調整最終設計，確保滿足非功能性指標要求。

2.定制界面系統

本質用例同樣適用于已經定義好界面的情形。在這種情況下，我們先對界面進行分析，然后描述交互過程的本質用例，并在此基礎上進行面向對象的設計。這樣，從系統交互和職責的本質著眼進行設計的中間系統更穩定，更能夠適應界面細節的變化，同樣具有本質用例方法的主要優點。

3.設計業務流程

長期以來，常規用例被認為是業務流程建模的好方法，它主要描述的是業務單元（人）之間的交互，而不是計算機系統和人之間的交互過程。

本質用例與技術無關，它描述用例之中抽象的意圖和任務，因此，無論采用何種界面技術，都可以實現用例。例如，采用相同的一個呼叫中心的用例，既可以支持用桌面應用的方法實現，也可以支持用Web的方式實現。還可以支持采用交互的語音提示的方法實現。這就是說，本質用例與采用何種技術途徑無關，需要的僅僅是最基本的計算支持。

使用本質用例的成功經驗告訴我們：本質用例既適用于軟件設計，也適用于業務流程設計，它們在抽象、對話和任務中具有相同的優點。

4.開發過程

本節主要描述我們建立的軟件設計模型，并為模型構建的過程提供參考。非常重要的是，從本質用例到系統對象，然后到面向對象的中間設計描述是開發的抽象過程，而不是構建模型的具體步驟，并不是類似于瀑布的過程，先對本質用例進行“分析”，接著確認其“完整性”和“正確性”，然后進行設計等等。

我們希望這個過程是一個增量的、可迭代的過程：先有一個備選用例表和一個初步的領域模型；其中的關鍵用例首先被細化，按用戶意圖和系統任務編寫到用例卡片中；然后進行初步的設計，劃分對象任務，并對用例的措詞進一步細化和調整。再細化其它的用例，獲得更多的對象模型，這些工作可根據后續工作中情況進行必要的復查和調整。

本質用例有助于軟件開發的迭代過程，其抽象層次、用例與模型間的通用詞匯決定了迭代開發的過程更易于跟蹤，具有更好的一致性，對象和用例之間具有更良好的可追溯性。當設計完成時，所有的用例和對象都使用相同的詞匯表，所有的系統任務被設計劃分成適當的中間對象，所有的用例都可以被對象模型執行，能夠更方便地檢驗設計和系統任務的一致性。

5.并行開發

在以用為中心的設計中，使用本質用例同樣可以產生用戶界面。在這種情況下，基于本質用例采用面向對象設計方法進行中間設計具有更加顯著的優點。它可以避免重復工作：它設計的用戶界面可以直接在軟件設計中重用，無須重新捕捉和進一步細化，使軟件設計和界面設計可以同步進行，只要二者同時支持本質用例就可以保證良好的一致性。

這和其它的過程方法（特別是RUP過程）略有不同，不需要在早期就完成界面設計，可以在軟件設計階段進行，支持軟件設計和界面設計的同步進行，不會因為界面設計沒有完成而延宕工期，可以有效地縮短項目周期，特別是在用戶界面設計要求高、數量多的項目中，可以為整個項目節約好幾個月的時間。

并行設計特別適合于Web系統的開發，前端界面和后臺服務軟件可以獨立設計，并有專門的技術支撐其實現。在這樣的并行開發過程中，要求對迭代過程進行有效地管理，協調設計過程中用例的變更和實現，使二者保持良好的一致性和可追溯性。

與其它方法的比較

軟件開發技術在不斷地向前發展，也提出了許多其它的手段和方法。在此，我們著重介紹它們處理需求和設計之間關系的不同方法。

面向對象的軟件工程（OOSE）對建立對象模型中對象和用例之間的關系提出了許多有用的建議。Jacobson等人用系統邊界、控制和實體對象實現用例的方法來建立分析模型，但是在分配系統行為和產生類（class）的過程，要求有一個附加的翻譯過程。與這種方法相比，我們使用的本質用例方法具有更好的可操作性。

還有一些更簡單和直接的方法來組織需求和進行面向對象設計。例如，在第二章中提到，Jacobson等人介紹用例概念，以及Lockwood提出在用例界面設計中使用本質用例方法就是基于這樣的思想。還有許多指導用例寫作及其在軟件開發中具體應用的書籍。例如，Cockburn最近就出版了一本詳細介紹用例寫作方法的書籍，并對各種風格的用例進行了介紹。Amour和Miller還討論作了為需求搜集工作的一部分，如何發現和管理用例。但是，這些工作很少提及用例如何在分析和設計階段的工作中反映，討論用例和設計關系的工作在領域模型的開發中完成，把領域模型作為設計和開發的第一步。領域模型固然非常重要，但是，從需求到發現領域模型、領域模型滿足需求之間還應該有大量的工作需要完成。

大量的文獻都提到可追溯性的重要性。Pfleeger指出，可追溯性包括橫向和縱向的可追溯性�？v向的可追溯性是指開發過程中模型內部的關系，橫向的可追溯性是指模型與模型之間的關系。加強系統的可追溯性可以有效地提高開發過程的質量和降低維護成本。

我們致力于需求與設計橫向可追溯性的工作，將二者的關系直接反映到任務的分配中，成為設計工作的一部分。

任何軟件開發方法都伴隨相應的過程。最近經常提到的過程是Rational（瑞理公司）統一過程，即RUP。RUP是用例驅動的軟件開發過程，用例連接開發過程的各個階段。在我們使用的本質用例方法中，本質用例在開發過程中具有同等重要的地位，只是在用例格式的選擇上有所差異。事實上，本質用例方法與RUP方法中用例的描述沒有任何矛盾，甚至可以認為本質用例是基于前文中指出的OOSE方法中分析和設計工作流的細化。

還有一種開放式的軟件開發過程，準確地說，它是一種軟件開發方法的框架，而我們只關注其過程部分。特別值得關注的是它的開放式工具技術，為不同職責的軟件開發需求提供完整的技術支持。它提供從原始需求到設計模型的技術，包括：協作分析技術、CRC卡片建模技術、委托分析技術、領域分析技術、泛化和繼承技術以及對象模型轉換技術等。上述所有技術都可以和我們的研究聯系起來，而我們的工作在指導操作和提供可追溯性方面做出了貢獻。

最近，輕量級方法XP等大行其道�；�于XP方法的設計要求功能需求盡量簡化，在真正需要以前，不輕易增加別的功能。XP是帶有獨立“用戶故事”的增量開發過程（與用例類似但完全固化），通過再分解現存的程序實現用例，達到增量的目的。我們的方法與XP的方法也有所類似，所有的設計都可以再生。但在XP的方法中，當需要擴展支持新的用例時就需要重新設計，而在我們的方法中，設計從完整的系統目標出發，以實現整個系統為目的，所有的再分解都維持了對象的任務，都可以在中間組件之間重新進行分配。

結論

用例適用于各種軟件的開發，本質用例起源于用戶界面設計的細化和描述。我們嘗試在面向對象的系統開發中使用本質用例，并在本文中進行了總結。

本質用例能夠簡單快速地發現需求，支持通過角色扮演進行溝通，有助于發現系統邊界。它簡明扼要，易于學習，避開了繁瑣的實現細節，支持快速開發。使用這種方法易于確定用例模式。它還同時支持界面和系統設計，可以實現二者的并行開發。

本質用例標識系統任務，將需求和面向對象的設計聯系起來。在設計中，其職責啟發分配協作對象之間的抽象行為。使用本質用例描述需求，采用職責驅動的方法進行設計，可以更好地為設計提供指導，使設計和需求具有良好的可追溯性。