本节向大家介绍一下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应用就简单介绍到这里。
画出状态图
状态图如下：
【编辑推荐】
