[b][color=brown]業務用例是用來捕獲功能性需求的，功能性需求是由actor的業務目標來體現的。[/color][/b]也就是對於actor來說，他所負責的業務需要由一系列的業務目標組成。比如乙個檔案管理員，他的業務目標就是維護檔案。比如論壇管理員，他的業務目標有維護使用者，維護帖子等..這些業務目標構成actor職責的全部。業務用例體現了需求。
而需求的實現有多種方式。如何實現它，是由系統用例來體現的，它們並不是乙個簡單的細分關係，雖然看上去象。就說維護檔案吧，這樣乙個業務目標，會有多種不同的用例場景去完成它，這些場景包括如何增加檔案，如何修改檔案，如何刪除檔案....對於系統用例來說，就是通過分析這些場景，來決定哪些場景中的哪些部分是要納入系統建設範圍的。比如維護檔案業務用例中，假設由於某個原因，修改檔案很困難，只能通過先刪除，再全部重建的方式來實現，那麼系統用例就增加檔案，刪除檔案，而沒有修改檔案。
業務用例和系統用例是分別站在客戶的業務視角和系統建設視角來規劃的。業務用例不是接近，而是完全的直接需求，系統用例也不是業務邏輯的詳細劃分，而是系統對需求的實現方式，但不是與程式設計無關，它只是說，要建設的系統功能性需求由這些系統用例構成。
所以業務用例和系統用例都是需求範疇，它們分別代表了業務範圍和系統範圍。
關於業務用例
本來想把這專案的過程全部記錄下來的,可惜.實言了 這次來講一下用例吧.我這公司是 公司.和公司打交道的就是客戶和 商 其實 商也是客戶 客戶買.公司向 商買.所以呢.其實我就只有二個業務用例.好了,最外圍的邊界已經確定了.這二個用例就是 買產品 和 賣產品 圖我就不畫了,大家發揮想像力吧.要記住這個...
關於用例間的關係
異常處理很好理解，主要想談談抽象功能與具體功能。這種情況下的泛化，我感覺就是類似於質值的互相轉化。根據值的不同採取不同的處理方式是非常常見的函式段 switch var 我覺得，所謂的泛化有點類似更廣義上的質成為了質量，而狹義的質則成了其質，然後成為了一種關於它們之間的switch關係。switch...
單例模式的討論
單例相對於靜態變數的優勢 1 可以支援延遲載入 2 可以支援多型 最簡單的單例模式 public class singleton public static foo getinstance 靜態內部類 只有當有引用時 內部類才會被裝載，從而實現延遲載入 當需求是需要該類有唯一例項，但該類的初始化需要...