用例(use case)的優勢
用例(use case)是一種描述系統需求的方法，使用用例的方法來描述系統需求的過程就是用例建模。用例方法最早是由iva jackboson博士提出的，後來被綜合到uml規範之中，成為一種標準化的需求表述體系。用例的使用在rup中被推崇備至，整個rup流程都被稱作是「用例驅動」(use-case driven)的，各種型別的開發活動包括專案管理、分析設計、測試、實現等都是以系統用例為主要輸入工件，用例模型奠定了整個系統軟體開發的基礎。
用例方法完全是站在使用者的角度上(從系統的外部)來描述系統的功能的。在用例方法中，我們把被定義系統看作是乙個黑箱，我們並不關心系統內部是如何完成它所提供的功能的。用例方法首先描述了被定義系統有哪些外部使用者(抽象成為actor)，這些使用者與被定義系統發生互動;針對每一參與者，用例方法又描述了系統為這些參與者提供了什麼樣的服務(抽象成為use case)，或者說系統是如何被這些參與者使用的。所以從用例圖中，我們可以得到對於被定義系統的乙個總體印象。
與傳統的功能分解方式相比，用例方法完全是從外部來定義系統的功能，它把需求與設計完全分離開來。在物件導向的分析設計方法中，用例模型主要用於表述系統的功能性需求，系統的設計主要由物件模型來記錄表述。另外，用例定義了系統功能的使用環境與上下文，每乙個用例描述的是乙個完整的系統服務。用例方法比傳統的srs更易於被使用者所理解，它可以作為開發人員和使用者之間針對系統需求進行溝通的乙個有效手段。
在rup中，用例被作為整個軟體開發流程的基礎，很多態別的開發活動都把用例作為乙個主要的輸入工件(artifact)，如專案管理、分析設計、測試等。根據用例來對目標系統進行測試，可以根據用例中所描述的環境和上下文來完整地測試乙個系統服務，可以根據用例的各個場景(scenario)來設計測試用例，完全地測試用例的各種場景，可以保證測試的完備性。
業務用例與系統用例的區別
1 業務用例就是要完成的業務，系統用例是系統要做的事情，兩者的域不同。2 業務建模主要描述了該專案涉及的所有業務，需求模型主要是描述為了滿足業務需求系統要做什麼，因此，需求模型與業務模型相比，它描述的只是業務模型的乙個子集。3 比方說我們設計乙個自動提款機系統，它可以滿足使用者的取款 改密 查詢等需...
業務用例和系統用例
拋開前一篇文章談的總體思路，我們今天來談一下需求分析工作實質性的做些什麼。在這裡，我們，將主要關注於分析層面，也即 uml中的用例模型和邏輯模型。在這裡要申明的是邏輯模型並不能完全算需求分析階段的工作，因為它包含了設計模型的概念，但是我又把它歸納了一塊到需求分析階段，原因在於邏輯模型中存在了業務物件...
業務用例和系統用例
業務用例與系統用例具有同樣的特徵，因此編寫和評審用例的方法對兩者都適用。在業務用例中說明的東西，也會在系統用例中說明。這形成了系統用例和使用者用例之間的合作。但這樣帶來了兩個壞訊息。第乙個壞訊息 編寫者和讀者經常把二者弄混，可能把系統行為放入業務用例中，也可能把業務操作歸於系統用例。如果能夠商量著去...