UML應用RationalRose進行狀態機分析與設計實例解析
本節向大家介紹一下UML應用方面的知識，通過應用RationalRose進行狀態機分析與設計實例向大家介紹，內容主要包括用戶的需求和分析狀態機等，相信通過本節的介紹大家對UML應用有新的認識。
UML應用－應用RationalRose進行狀態機分析與設計實例
前言
本文結合一個具體的實例，試圖通過對一個對象狀態機的分析，畫出一個完整的狀態圖。筆者初學UML，大膽下筆此文，難免紕漏，以期能拋磚引玉，請您不吝批評指正。
狀態機用于對系統中的動態行為建模，一般使用一個狀態機對一個對象經歷的狀態變化序列進行建模，狀態是指對象在生命周期中的一個條件或狀況，把這個狀態機用UML圖的形式表現出來，就是一個狀態圖。
一個系統中會有很多對象，一般僅對狀態序列復雜的對象畫出狀態圖，從而進行細致的分析。
UML應用中用戶的需求
首先介紹一下我們要實現系統的需求，本系統是一個專家網絡，主要包括三種資源。
第一，網絡服務的提供者。與專家合作，簽署協議。
第二，領域專家，通過專家網絡進行專業問題解答，并可以通過網絡服務的提供者收取提問者的傭金。
第三，專家網絡的最終用戶，即提問者，可以通過專家網絡提出問題，并選擇相應的領域專家進行回答。
此系統中的一個核心對象就是問題（Questions），我們要針對它的狀態機進行分析，給出狀態圖。
一個問題將籍由系統中不同角色的行為而相應改變自己的狀態。
起初一個問題由提問者添加到系統中，編輯完成后，選擇一個專家并提交，相應的專家在登錄后可以查看到此問題，此時，提問者不能夠再對問題進行修改。
一個問題在未提交給任何專家之前，提問者可以刪除此問題。但一旦提交或者已經回答，就無法刪除。
專家可以選擇接受或者拒絕，如果專家拒絕此問題，則問題會重新發回給提問者，其可以在此編輯此問題，并選擇不同的專家進行提問。當選擇編輯此問題，則提問者可以在自己的視圖看到問題已經被接受，并正在進行回答，但提問者看不到正在編輯的問題解答內容。
專家解答完成之后，把問題提交給提問者，提交之后，專家無法再進行編輯。此時，提問者可以查看專家的解答內容，如果認可解答內容，可以選擇接受，問題被歸檔。否則，可以提出拒絕解答內容，拒絕的問題由網絡服務提供者進行處理。如果提問者在問題解答后的一個確定的時間內沒有作出明確的接受或者拒絕的回復，則系統會自動認為問題已經解答完畢，并歸檔。
提問者在提出問題時，可以選擇問題的解答級別，分為簡單解答和詳細解答，在選擇專家時，可以查看專家對不同級別問題進行解答所需要花費的最長時間以及費用。當專家開始編輯此問題后，則計時開始，若沒有在規定的時間內完成解答，則問題會過期，由網絡服務提供者確認后重新發送給提問者。提問者可以重新進行編輯提交。
如果提問者第一次提問要求為簡單解答，在專家回復后，提問者可以選擇要求更為詳細的回答，問題會被再次提交給同一個專家。
以上概要描述了主要的需求，通過需求我們需要分析出Question對象所要經歷的狀態序列，以及觸發狀態轉換的事件和對象的動作。
UML應用中分析狀態機
當問題被提問者加入系統，但還未提交給專家前，問題處于編輯狀態，我們稱狀態為"Uploaded"。
當提問者刪除了一個問題，則問題處于無效狀態，我們稱狀態為"Removed"。
當問題由提問者第一次提交給專家后，問題處于等待解答狀態，我們稱狀態為"New"。
當專家拒絕此問題后，問題狀態處于被拒絕狀態，我們稱狀態為"Refusedbyexpert"。
當專家開始編輯解答內容，表示問題已經被接受，正在進行編輯，我們稱狀態為"Workinprogress"。
如果專家沒有及時解答完問題，問題會在規定的時間內過期，我們稱狀態為"Expired"。
當專家解答完問題，提交給提問者之后，問題等待提問者進行Check，我們稱狀態為"Answered"。
如果提問者拒絕了專家的回答，則問題處于被拒絕狀態，我們稱狀態為"RefusedbyAsker"。
如果提問者接受了專家的解答，則問題結束，我們稱狀態為"Finished"。
提問者還可以要求專家更詳細的回答，提問者再次向同一個專家提交更詳細的解答請求后，問題在此回到等待解答狀態，與前面的"New"狀態進行區分，我們稱狀態為"2th.New"。
此外還有兩個特殊的狀態，就是初態和終態。
以上我們根據需求列舉出了問題對象在系統中經歷的所有狀態可能，以及出發狀態轉換的條件。接下來我們在RationalRose中使用狀態圖畫出狀態的序列。本節關于UML應用就簡單介紹到這里。
畫出狀態圖
狀態圖如下：
【編輯推薦】
