類和子系統(tǒng)在 UML 中定義為；在 UML 中更大的聚合是子系統(tǒng)（包含子系統(tǒng)），為了更簡單的進行描述，我進行了不同的命名。對于那些知道 2167 和 498 軍方標準（稱子系統(tǒng)為 CSC，稱類為 CSU）中的術語的人來說，子系統(tǒng)組（subsystemGroup）的規(guī)模用 CSCI -來表示。我記得，經(jīng)過 2167 天的關于 Ada 的結構應該映射到哪一層次的爭論后，塵埃落定，Ada 包通常映射為 CSU。我并不建議系統(tǒng)必須嚴格的遵循這種層次結構，還將存在層次之間的混合，這種層次結構使我能夠更好地了解規(guī)模對于每個用例工作量的影響。

在每一層上都會有用例（盡管對于單個的類可能不是這樣），但并不是單純的大量細節(jié)堆砌 ，而是用例針對那個層上的每個組件（例如子系統(tǒng)、子系統(tǒng)組，等等）。在上文中我曾斷言對于每一層的每一個組件都有 10 個用例――如果用例的描述平均是 10 頁，那么將會給出一個潛在的、大約 100 頁長度的說明文檔（還要加上類似的或者少一些的關于非系統(tǒng)性需求的相應說明），這是 Stevens 98 提倡的數(shù)字，并且和Royce98推薦的數(shù)字很接近。但是為什么是 10 個用例呢？為了得出這個數(shù)字，基于對每一個子系統(tǒng)的類的數(shù)量、類的規(guī)模、操作規(guī)模等等我認為的合理的規(guī)模，我進行了自下向上的推理。這些和其他假設共同搜集在下表中供大家引用。

我沒有大量的經(jīng)驗數(shù)據(jù)－貫穿文中的是瑣碎的、分散的數(shù)據(jù)，Lorentz 94 和 Henderson-Sellers 96 有一些數(shù)據(jù)，我也有一些在澳大利亞的項目中得出的數(shù)據(jù)，主要是在軍用航空航空領域。任何情況下，在這個階段，將框架或多或少的定位到合適的位置是非常重要的。

分層結構中組件的大小
這里我應該指出的是，我曾經(jīng)使用代碼行來度量組件的大小，但許多人不喜歡這種度量。這些是 C++（或者相同層次的語言）代碼行，所以，要回到功能點非常容易。

在容器中的類的數(shù)目和能表達的行為的豐富性之間肯定有許多關系。我選擇了 8 個類/子系統(tǒng) ，8 個子系統(tǒng)/子系統(tǒng)組，8 個子系統(tǒng)組/子系統(tǒng)，等等。那么為什么是 8 個呢？

1. 它在 7 或－2 之間；

2. 由于每個類有 850 slocs（每 70 slocs 有 12 個操作）的 C++代碼，它得出了一個子系統(tǒng)的規(guī)模是 7000 slocs－一個可以由小的團隊（3－7人）在 4－9 個月能夠交付的功能/代碼的程序塊，其中系統(tǒng)的迭代長度該調整到 30 萬－100 萬slocs (RUP 99) 的范圍內 。

那么，多少用例能夠表達八個類的行為（外部的）？，哪些是屬于子系統(tǒng)的并且已經(jīng)被定位在子系統(tǒng)中了？決定豐富性的原因不僅僅是用例的數(shù)量，還有每個用例的場景數(shù)量�，F(xiàn)在，并沒有多少方法來指導場景/用例擴展――在Booch 98中，Grady Booch 指出"存在一個從用例到場景的"膨脹系統(tǒng)"，一個復雜度適當?shù)南到y(tǒng)中可能有幾十個用于捕獲系統(tǒng)行為的用例，每個用例可能具有幾十個場景…."，Bruce Powel Douglass 在 Douglass 99 中指出，"….為了詳細描述用例需要很多場景，通常需要1打到幾打"。我選擇了 30 個場景/用例――這處于"幾打"的較低的一邊，但是 Rechtin（在 Rechtin 91中）指出，工程師能夠處理 5 到 10 個互相作用的變量（對于這個變量，我解釋為互相協(xié)作的 5 到 10 個類）并且 10 到 50 種交互（我解釋為場景）。以這種方式解釋，多個用例即為該變量空間的多個實例。

因此，10 個用例，每個用例 30 個場景，也是說一共 300 個場景（后面將導致大約 300 個測試用例）對于覆蓋 8 個類的有意義的行為來說已經(jīng)足夠了。是否有其他的跡象表明這是個合理的數(shù)字呢？如果應用 Pareto 的 80-20 規(guī)則，那么20%的類將表達80%的功能，同樣，80% 的功能將被每個類中20%的操作來表達。讓我們保守的說，我們需要20%的類（等）來達到75%的功能并且通過這點來構建一個 Pareto 分布圖。（圖 1）

圖 1: 一個 Pareto 式樣的分布圖

如果我們想要描述 80% 的系統(tǒng)行為，并且將 Pareto 規(guī)則應用到類、操作和場景數(shù)量方面，那么對于每一者都需要描述其行為的 93%(0.933＝ 0.8)－－也是對于每一個都需要 50%，例如，4 個類和 5 個操作(= (12 － 2 構建器/析構器)/2)。節(jié)點樹的不同分叉的數(shù)量可能達到數(shù)千個（其中節(jié)點樹用來代表4個類及每個類5個操作的執(zhí)行模式）。我為每個節(jié)點創(chuàng)建了 1 到 3 個鏈接，假設在頂層有 10 個操作（接口操作）的層次結構，并且形成了一個三層的樹。這將會有 1000 條路徑或者場景。所以，500 個場景將會得到 93% 的覆蓋。使用 300 個場景（用相同的假定）我們可以得到 73% 的覆蓋。根據(jù)一個選定的算法，可以對這個樹進行修剪，從而刪除冗余的行為說明，甚至更少的數(shù)量完全可以符合要求。

達到該目的的另一個方法是研究一下對于 7000 slocs 的 C++代碼需要多少測試用例（從場景派生而來）。這些測試用例不受單元測試層次的制約，并且在 Jones 91 和 Boeing 777 項目中有許多證據(jù)表明這個數(shù)字是安全的，至少它符合實踐。這些來源表明在 250 到 280 之間是合適的。在一個完全不同的層次上，加拿大自動空中交通系統(tǒng)（Canadian Automated Air Traffic System ，CAATS)項目使用了 200 項系統(tǒng)測試（我私下里獲悉的）。

用例的規(guī)模
用例應該具有多大規(guī)模呢？是否應該足夠大以及表達足夠的細節(jié)才能表達所需要的行為－－這取決于與系統(tǒng)有關的用例復雜性、內部用例和外部用例。－－這里我們應該描述多少系統(tǒng)的內部動作來深入探討一下這個問題。很明顯，從外部行為描述來構建系統(tǒng)，要求將輸出與輸入關聯(lián)起來。例如，如果行為對歷史記錄敏感并且很復雜，那么在沒有系統(tǒng)內部的一些概念模型及行為的動作時，很難描述它。注意，沒有必要描述一個系統(tǒng)是如何從內部構建的－－任何滿足非功能性需求和匹配模型行為的設計能夠滿足要求。

UML 1.3 中提供的定義是："用例【類】：一個系統(tǒng)可以執(zhí)行的動作（包括變體）序列的說明，其中這些動作與系統(tǒng)參與者進行交互"。對復雜的行為的內部動作，可能合理的采用這個定義也可以在實現(xiàn)階段再進行定義――這對于終用戶來說是個更遠的步驟。業(yè)務規(guī)則也應該納入到用例中以便約束參與者的行為（例如，在一個ATM系統(tǒng)中，銀行需要有一條規(guī)則：在一次交易中，提取的金額不能超過 500 美元，無論賬號中的余額為多少）。

根據(jù)這種解釋，事件的用例流描述的頁數(shù)可以為 2－20 。從計算的角度上看，具有簡單行為的系統(tǒng)顯然不需要冗長的描述�；蛟S我們可以認為簡單的商務系統(tǒng)通常用 2 到 10 頁來描述，平均為 5 頁。對于更復雜的系統(tǒng)來說，業(yè)務系統(tǒng)和科學系統(tǒng)在 6 到 15 頁之間，平均為 9 頁。復雜的命令和控制系統(tǒng)在 8 到 20 頁之間，平均為 12 頁（這些比率反映了相同規(guī)模系統(tǒng)的工作量與類型之間的非線性關系），盡管我沒有數(shù)據(jù)來支持這種觀點。更富有表達力和描述性的形式（例如狀態(tài)機或者活動圖）可能需要更少的篇幅－－我們仍舊傾向于加強文本，所以此處不討論其他形式，畢竟相關資料很少或者根本沒有。

與上述規(guī)模有系統(tǒng)差異的開發(fā)應該運用乘法規(guī)則來計算在這些假設基礎上得出的每個用例的小時數(shù)（我建議增加一個 COCOMO -樣式的成本驅動，該驅動是系統(tǒng)類型的（簡單的業(yè)務類型、更復雜的類型、命令及控制類型等等）的觀察到的平均規(guī)�；蚪ㄗh的平均規(guī)模。

用例規(guī)模的另一個方面是場景的數(shù)量。例如，一個 5 頁長的用例可能是一個具有很多路徑的復雜結構。再一次重申，需要將場景的數(shù)量以及這個比例估計為 30（這是我對于每個用例的場景數(shù)的初步估計），將其作為成本的驅動因素。

得到的結果是，我們假設基于大約長度為 100 頁說明的用例，對于任何給定層次的外部說明及補充說明來說，都是足夠的。范圍是 20 到 200 頁之間（這些界限是模糊的）。注意，一個系統(tǒng)（子系統(tǒng)組）在低的層次上的總數(shù)是 3－15 頁/ ksloc（簡單的業(yè)務系統(tǒng)）到 12－30 頁/ ksloc（復雜的命令和控制系統(tǒng)）。這或許能夠解釋 Royce 98 表中的 14－9 和實際項目之間明顯的矛盾之處，前者的工件所占用的篇幅非常少，而實際項目卻占用了大量的頁。本文的觀點認為規(guī)格說明的層次不應受頁數(shù)的限制。－－Royce 是正確的，對于大型的、復雜的系統(tǒng)而言，重要內容的說明（如版本聲明）可以達到范圍的上限――200 頁