下面所涉及到的名詞「機構」，可以理解為要為某個單位開發專案中的「單位」的概念
標準：·
你和工作組不熟悉機構。
·機構最近進行了一些業務過程重建工作。
·機構準備進行業務過程重建工作。
·建立機構主要部分使用軟體。
·機構中有些大型複雜工作流的文件不足。
·你到別人的公司當顧問。
下列情況可能不需要業務模型：
·你徹底了解機構的結構、目標、業務前景和主體。
·建立的軟體只在機構的區域性使用，不會影響到公司其他部分。
·機構中的工作流很簡單，文件齊備。
·沒時間。我們要現實一些，並不是所有專案都有進行完全業務分析所需的時間。但要小心，不要吧沒時間當藉口。如果業務模型有助於專案成功，就應擠出時間。
看誰與業務交流，這個誰可以是自然人也可以是其他的實體，它必須在整個機構的範圍之外。
與業務角色相對應，它要在機構範圍之內。
這個不好說，應該說是從對甲方的了解和任務報告開始研究，或者從高層介紹公司向外部提供的價值。
或者開會檢查機構的過程，與客戶和其他股東交談或利用自己的業務知識。
·公司生產什麼產品
·公司提供什麼服務
·公司購買什麼產品
·公司傳送或接收什麼專案
·什麼東西從業務工人傳給另乙個業務工人處理
1、理解文件。
2、詢問專案的保管員
·這個保管人要用這個系統做什麼？
·保管人是否要維護任何資訊（建立、讀取、更新、刪除）？
·保管人是否要把外部事件告訴系統？
·系統是否要把某些變化和事件告訴保管人？
事件流是系統用例必須要的，所以這裡就不說明如何判斷了，只是指出事件流應該包含什麼東西。
·簡要說明
·前提條件
·主事件流
·其他事件流
·事後條件
主事件流和其他事件流：
①用例如何開始
②使用用例的各種途徑
③使用用例的正常流程
④使用用例主事件流（其他事件流）的變形
⑤錯誤流
⑥使用用例如何結束
如何判斷事件流的詳細程度：
1、開發者與客戶不能有分歧，但是文件也不能太複雜。
2、一定要足夠詳細到能夠指導建立系統設計和最終建立系統。
3、能夠建立測試指令碼。
如果是角色與用例之間的關係，那麼就是關聯關係。
如果是用例之間的關係，那麼就是關係、擴充套件關係和一般化關係。
如果是描述角色之間的關係，那麼就是一般化關係。
角色一般化關係：
如果角色一般化能使小組得到有用的資訊，則進行角色一般化，否則就沒必要進行角色一般化。
*特別是，如果公司客戶啟動一些個人客戶不啟動的用例，則最好進行角色一般化。如果兩種客戶使用相同的用例，則沒必要進行角色一般化。如果兩種客戶使用相同的用例，但只是稍有不同，則仍然沒有必要進行角色一般化。
其實，最一般的理解就是類的繼承，如果有
a類，它繼承於
b類，那麼a類和
b類就要進行角色一般化。*引用
rational rose 2002
從入門到精通
總之，看角色是否啟動相同的用例，如果啟動的話就沒必要一般化，否則，就要一般化。
同樣，這個規則適用於其他的
uml元件。
mysql各個元件 mysql各個元件的說明
在大多數情況下,你只需要安裝mysql server和mysql client得到乙個功能mysql軟體包安裝。另乙個包是不需要乙個標準的安裝。如果你想開辦乙個mysql max伺服器,有更多的能力,你也應該安裝mysql max每分鐘轉速。但是,你應該這樣做的只是在安裝mysql server每分...
scrapy各個元件的作用
1 items是將要裝載抓取的資料的容器，它工作方式像python裡面的字典，但它提供更多的保護，比如對未定義的字段填充以防止拼寫錯誤。它通過建立乙個scrapy.item.item類來宣告，定義它的屬性為scrpiy.item.field物件，就像是乙個物件關係對映 orm 2 spider是使用...
理解「資料庫」中的各個元件
任何資料庫都是依賴於許多層次的，而且每個層次都與其他層次同樣重要，如圖 1 3所示。這些層次之間可能是相互交迭的，而且對於 d b a是透明的。但無論如何，這些層次可以概括 為 硬體層 作業系統層 網路層 dbms 資料庫管理系統，在這裡就是o r a c l e 層 使用d b m s的應用程式層...