從用例到代碼：用例分析

　　從用例到代碼：用例分析  軟件測試

　　自從1992年 Ivar Jacobson 發表了關于如何使用用例，從系統用戶的角度來提取軟件需求的方法的論文之后，這種方法已經逐漸流行起來。但是有一個最常見的問題是：當我得到了用例之后，如何才能把他們用代碼實現出來?本文由兩部份組成，將會用一個實際的案例來說明這一點。如何從用例中提取需求，并加以分析，進一步將其轉化為可以直接進行編碼的格式。我希望能夠把這一過程講清楚，這樣你在當前的，或是下一個軟件項目中就可以使用它們了!

　　IBM Rational Unified Process(RUP) 提倡通過用例來提取系統中可操作的需求。 1 軟件需求說明書，即 Software Requirements Specification (SRS)，包括軟件的所有需求，其中包括很多相關的文檔。用例就是其中的一個重要部分。 SRS主要包括以下幾部分：

　　用例模型，包括：

　　用例圖：可視化的描述系統用戶，和系統為用戶提供的服務。

　　角色定義：用文字描述系統功能，和系統所需的服務。

　　用例描述：用文字描述系統提供的主要功能。

　　軟件補充規格文檔：這個文檔包括了整個系統相關的各種需求，和一些與對系統用戶和用例都不直接相關的隱藏需求。

　　在RUP方法中，這個需求文檔是后續的分析和設計工作的起點。不同的開發方式，對項目的推動力是不同的，也就會產生不同的文檔。如果軟件發布之后，你還總是在不停的修補缺陷，你很可能根本沒有需求文檔。只能從Bug報告中看出，軟件已經和最開始設計的樣子不一樣了。如果你在維護或者改進一個軟件版本(比如增加一項新功能)，你可能有一兩個用例，他們描述了這些新功能和用戶之間如何交互，但是你不會有軟件補充規格文檔，因為這些功能之外的部分并沒有改變。

　　在這里，用一個虛構的軟件項目"green-field" 作為例子。這是一個面向對象的軟件項目，使用UML來描述系統中的各種概念與關系。讀者需要具有對象和類的基礎知識，熟悉UML 版本1.x 或者2.0中的類圖、順序圖和協作圖。

　　用例分析活動

　　下面我們討論一下RUP中的用例分析。如圖1所示，將RUP中結構分析的結果整合起來。

　　圖1： 結構分析的工作流程(early Elaboration)

原文轉自：http://www.anti-gravitydesign.com