在我們分析模型的時候經常會遇到不同型別的事物在某些特性上有共同點，比如，人和公司，他們都有位址，**，電子郵件等屬性，在分析模型的時候，我們可能得出如下的模型：
看到上述的模型的時候，我們是否會覺得模型中的冗餘呢？很顯然，我們會想如何將這兩者融合在一起呢，我們偉大的martin fowler同志提出了party模式來描述此種型別的模型。我們用一種通用（父）的型別來定義人和公司，這樣，只需要在模型中指定該通用型別和****的關係即可，而人和公司則從屬於該類型別。其模型如下：
在這個時候，大家停下來想一想，第二個模型為什麼比第乙個模型更好，難道只是模型沒有冗餘嗎？很顯然不是。考慮下面的情況，當乙個應用中和****相關的實體除了人和公司外，還有團隊，子公司，部門等的時候，在第一種模型中，我們應該如何描述呢，很顯然第一種模型將會變得很複雜且混亂。而第二種模型，我們可以很容易增加一種或多種和****相關的實體，只是這些實體都是屬於party的。
從上面的例子我們可以看出，使用party模式會使得類似的模型變得容易擴充套件。
回過頭來我們再看看party模式：
problem：
問題是什麼呢？問題是當有很多元素擁有相同的特性，或擁有相同責任的時候，我們應該如何去分析和描述它呢？
solution：
解決方案是，定義一種通用的型別，這些擁有相同責任或特性的元素都從屬於這種型別，我們只需要描述該通用型別的責任或特性即可，這裡我們將這種通用型別稱之為party（參與者）
UML核心元素之參與者
一 概述 在系統之外與系統互動的某人或某事物。1 如何找到參與者，確定系統邊界。在乙個業務中可以問自己兩個問題 a.誰對系統有著明確的目標和和要求並且主動發出動作。b.系統是為誰服務。參與者還有另一種叫法 主角。參與者容易讓人誤解為只要參與了業務的，都是參與者，而主角很明確的指出，只有主動啟動這個業...
UML核心元素之參與者
一 概述 在系統之外與系統互動的某人或某事物。1 如何找到參與者，確定系統邊界。在乙個業務中可以問自己兩個問題 a.誰對系統有著明確的目標和和要求並且主動發出動作。b.系統是為誰服務。參與者還有另一種叫法 主角。參與者容易讓人誤解為只要參與了業務的，都是參與者，而主角很明確的指出，只有主動啟動這個業...
工作流參與者和工作項模式分析
對於當前的工作流應用來說，人工節點無疑扮演著乙個非常重要的角色。因為無論是傳統的協同辦公系統還是越來越多的企業應用，都需要有人參與到具體的流程中來。這篇文章著重分析工作流應用中人工節點所涉及到的參與者模式以及與此關聯的工作項模式，最後會提供部分的解決方案作為參考。先簡單說說什麼是人工節點。人工節點的...