4. 業務建模時期的主要任務
項目涉眾的共同愿景：要想項目成功，可離不開項目涉眾的支持。在項目一開始，不論是項目涉眾還是開發人員，對項目的任務、范圍都是模糊不清的。但隨著項目的深入，原來模糊的景象會慢慢清晰、立體起來。但是為了不浪費時間，我們有必要在項目射入之前，現在項目涉眾中豎立一個共同的愿景。
共同愿景的豎立可沒有想象中的那么簡單，因為每位涉眾都關心自己的利益，都有自己的評判標準。你可以把大家的意見都列在白板上，然后逐項集中討論，做出修正，直到大家的意見一致的時候為止。在共同遠景的豎立過程中，其實有兩件事情也已經同時做了，項目范圍（scope）和高階（high-level）需求。
項目范圍：項目該做什么，不該做什么，需要在一開始就有明確的定義。對于項目范圍內的需求，一個也不要放過，而項目之外的，一個也不要去關心。雖然有的時候，范圍的變化會有利于項目本身，例如客戶的合理要求或是市場目標客戶的變化，但是這種變化應該要在"資源能夠支持"和"得到審批"的前提下進行。
項目范圍的描述可以通過陳述和圖示來進行。我建議大家使用圖示。因為陳述語句比較含糊不清。例如常常聽到有客戶說。"我要建立我公司的電子商務系統。"這句話就是含糊不清的，你的電子商務系統是銷售什么產品？面向什么客戶？是否要支持在線支付？根據這些疑問，這個陳述句可以做進一步的修改，"建立在線訂貨系統，針對當前的目標客戶銷售公司的目前產品。"這樣就清楚許多了。不過圖示的方法會更好一些，在圖的選擇上，你可以使用DFD圖或是用例圖。根據經驗，DFD圖比較容易為客戶所接受。
高階需求：這個部分我們在下面會詳細討論。既然是高階需求，就不能討論過多的細節。在討論高階需求的時候，盡量保證快速的討論出系統的概貌，建立需求模型，得到項目涉眾的一致通過。 取得支持：為了保證需求計劃的順利進行，取得項目涉眾的支持至關重要。你可以選擇在這個時候告訴項目涉眾他們的權利和義務，以及開發人員的權利和義務。在這個方面，具體的我不想多說，大家可以參考『軟件需求』的第二章。主要的就是"涉眾有改變需求的權利，同時要承擔向開發人員講解需求的義務。"開發人員的權利和義務正好和涉眾相反。
業務建模會議：所有的這一切都通過業務建模會議進行，和其它會議不同的是，這個會議需要所有的項目涉眾參加，如果不能獲取所有項目涉眾的意見，那就不是完美的。會議中最重要的工具就是白板，一位出色的速記員也是必須的。 建模原理
5. 業務建模中的用例
在上一篇中我們討論了很多用例的知識，可是落實到企業中的時候，我們往往會感覺難以把握企業的用例，這一點我們在用例的誤區中也有提到。在實際的情況中，你可能會對角色的歸類，用例的劃分，粒度的把握等很細節的方面都沒有底，偏偏這些實際的東西對你的項目有非常大的影響。
RUP中，有多種的概念來支持用例的實現：業務主角（Business Actor）、業務實體（Business Entity）、業務用例（Business Use Case）、業務角色（Business Worker）、業務用例實例（Business Use-Case Instance）。為了能夠比較清楚的展示出業務建模，我們采用了UP方法的代表――RUP。但在實際中，要視大家具體的情況而定，這里所講到的概念，都是為了幫助大家理解建模過程，并不是讓大家生搬硬套。
在我們對系統還絲毫不了解的時候，我們就會把系統看成一個很大很大的黑盒，這個大黑盒子我們會叫他業務域（Business Domain），把它的外部看成一個業務環境（business environment）。而那些在業務環境中和業務域有關系的人（也可能是物）就被稱為業務主角（Business Actor）。在實際的例子中，我們可能會把信貸業務（注意不是信貸業務系統，這里是業務建模，系統還不存在。）稱為業務域，我們經過調查，發現平時和信貸業務打交道的有客戶，人民銀行，外匯管理局，其他銀行，信貸部門使用的其他系統，銀行內部的其他部門。所以這些人（物）就是業務主角。業務主角的實例一般包括了客戶、供應商、合作伙伴、潛在客戶（"市場"）、當地政府、在業務中未建模部分工作的同事等。必須注意的是，業務主角表示的特定類型的用戶，而不是某一個具體的用戶。一個角色可能會有很多實際用戶擔任，一個實際的用戶也可能會擔任很多的角色。
業務用例以及業務用例實例在RUP中的定義如下：
A business use-case instance is a sequence of actions performed in a business that produces a result of observable value to an individual actor of the business. A business use case defines a set of business use-case instances. A business use case has a name.
業務用例實例是在業務中執行的一系列動作，這些動作為業務的個體主角產生具有可見價值的結果。業務用例定義了一組業務用例實例。業務用例具有名稱。
剛開始大家可能會對業務用例以及業務用例實例有所疑問。其實可以把他們看成基類和子類的關系。在一個企業中，具體的工作流程可能有很多很多，比如你去麥當勞的時候，點漢堡和點薯條的工作流程就不一樣。眾多的流程給需求的調查工作造成了一定的難度。即使是最古老的哲學也告訴我們，表面現象是復雜的，本質是簡單的。為了簡化需求工作，我們就把點漢堡和點薯條歸納為點餐。這樣，點餐就是一個業務用例，而點漢堡、點薯條就是相對應的業務用例實例。
業務用例
業務角色和業務主角的概念也很容易讓人摸不著頭腦。其實看它們的英文愿意會更容易理解它們的區別：Business Worker，Business Actor。Worker有工人的意思，而Actor有參與者的意思。所以它們的區別就是一個在內部，一個在外部。業務角色是實現業務用例的人，業務主角是和業務有關的人。例如，對銀行的押匯業務而言，客戶就是業務主角，他和業務有關。而押匯人員就是業務角色，因為他們是實現業務用例的人。在RUP中，二者定義如下：
A business worker represents a role or set of roles in the business. A business worker interacts with other workers and manipulates business entities while participating in business use-case realizations.
業務角色代表業務中的一個或一組角色。參與業務用例實現時，一個業務角色和其他角色進行交互，并操縱業務實體
A business actor represents a role played in relation to the business by someone or something in the business environment.
業務主角代表了與業務有關的角色，此角色由業務環境中的某個人或物來擔任。
業務角色
文章來源于領測軟件測試網 http://www.kjueaiud.com/
