(大致2023年左右寫的。由於訂正筆誤重發布，時間變了）
在我們的設計過程裡,"角色"這個術語是相對來說被提的很少的,"業務","流程"則更多.我們拿到的需求或設計文件裡,序列圖,流程圖是主要組成部分.use case也是有的,主要是用於簡單描述事件流.
也許是認為角色這個概念並不是很複雜,或者已經分析的夠透徹了，所以不用再提.實際上大家對系統相關都有哪些角色是有感性認識的，但感覺對角色的實質，角色的細節，角色之間的互操作等方面，細化的不夠，抽象歸納的也不夠。
如果從角色出發,也許大致可以如此分析
1:定義角色的職責
2:定義角色的一般屬性
3:定義角色可能有的擴充套件屬性（考慮實現的話可以通過繼承等方法）
4:定義角色的一般行為，包括訪問管理其屬性的方法。
5:定義角色之間的互動行為和操作介面 ，介面很大程度上是基於角色的屬性和行為
6:定義當角色本身發生變更，新角色加入或角色消失時的行為。
需要考慮角色定義的粒度，層次（整個系統或子系統），是否有互相依賴或衝突。角色應該是高內聚，低耦合的。
角色作為系統中相對來說是比較固定的一部分，當角色本身和角色之間的互動基本確定清晰後，流程的更改更多的是改變角色之間互動的次序。
以上思路個人還沒有成熟的示例，只是一點隨想。總之事在人為，首先做人，再考慮做事，這個原則是不會錯的。
重新出發，從「心」出發
首先真的很幸運有機會能讀到這麼多大牛的文章，感觸真的很多，也有了更多的思考，我覺得還是需要一定是時間消化一下這些思想。有一段時間沒用了，甚至連之前的賬號資訊都不記得了，雖然找得回來，但想既然想重新開始，就乾脆用乙個新的賬戶了，希望這個賬戶的生命能陪伴我吧。接下來來回答一下一些問題當初高考完我一心想要...
試著從問題出發
方法總比問題多 相信大家對這句勵志名言都不陌生，還有一些大師以此為題寫成了著作。不過作為乙個理科生，我對這種的心靈雞湯是沒有太多興趣的。從理性的角度出發，現實生活中的 方法 和 問題 的數量都是無限，也就是存在無窮多個 方法 和無窮多個 問題 所以並不存在誰比誰多的問題！不過我們倒是可以從中發現乙個...
SOA, 從復合應用出發
距離 gartner 提出soa 都十年有餘了，現在 soa剛剛逐步被企業接受和採納。soa的始作俑者 gartner soa的廣泛採用才剛剛開始。到 2008 年soa 會終結單一軟體架構 40年的統治地位 70 可能 成為流行的軟體工程實踐 原文參見 但要說服企業投資採用任何新技術的時候，都要做...