领导力大挑战
在实施Scrum项目的过程中，Scrum Master的角色是相当关键的，因为他是团队的推动者。本文围绕什么是仆人式领导、仆人式领导的起源、如何将领导力传达给团队、Scrum Master作为仆人式领导者的角色展开叙述，同时重点阐述仆人式领导者应有的基本内外特征。
文章
该内容已经被标记书签！
标记书签错误，请重试！
运用四色建模法进行领域分析
作者 徐昊 发布于 2011年11月7日
领域建模有很多种方法，对于同样的问题域使用不同的建模手段得到的模型可能也不尽相同。于是我经常听到这样一个问题：怎么才能保证建模的正确性？
这听起来是个合理的质疑，但实际上却不是那么有道理。首先我们需要明白建模的目的是什么？如果仅仅是为了描画问题，那么并没有什么对错之分——仅仅是立场和角度的差别；而如果是为了企业业务系统而进行建模，那么这个问题应该变为：如何保证模型能够支撑企业的运营？
我想用下面这个例子来简要的回答一下这个问题。
在开始分析和建模之前，我们需要知道企业业务系统的目的是什么；而企业业务系统的目的往往跟决策者或者管理的诉求相关。我们现在需要移情到一位管理者身上，看看他的诉求到底是什么。
现在假想你是一家在线电子书店的COO。突然有一天，有一位顾客向你投诉，说他订购的书少了一本，并且价钱算错了，他多给了钱。在你承诺理赔之前，你需要核对一下这位顾客说的是否属实。那么这个时候你需要知道什么样的信息才能做出准确的判断呢？
简单来说，你需要知道这位顾客订购了那些书籍，付了多少钱以及书店到底为这个顾客递送了那些书籍。不幸的是，由于科技不够发达，你无法直接驾驶时间机器回到从前去亲眼看看发生了那些事。但幸运的是，你并不需要这么做，你只需要看看这位顾客的订单，和网银的支付记录以及你们书店交给EMS的快递单存根，就应该知道这些信息了。
你找到了订单和EMS快递存根。发现这位顾客是在三天前订购的书，而你们在前天就已经将书邮寄出去了。并在订单上看到这位顾客一共订购了7本书，但是在EMS的快递存根上，并没有任何书籍的信息，只有地址，包裹号，邮费和重量什么的信息。这时候你觉得应该去询问一下配送部门，看看他们做了什么。
在配送部门你根据包裹号查到了那个包裹的信息，果然里面只有6本书。同时你在包裹部门发现了一张延期交货单。上面说明由于缺货，这位顾客另外一本书正在等待发货。
那么剩下的问题就是支付问题了，从网银的记录上看，客户不含邮费一共支付了132.5。订单上显示的价钱也是132.5，显然这位顾客并没有多付钱。
为了保证准确，你重新从网站上选了这7本书，想看看是否也会是这个价钱。但你却意外的发现，一共只需要128.3。仔细辨认后，你发现有一本图书现在是促销。那么现在的问题是，促销到底是什么时候开始的？
你到了市场部，市场部给了你一份近期促销计划。你发现那本书是昨天才开始促销的，也就是说在那位顾客在下订单的时候，促销还没有开始。
这个时候，你觉得应该给你的顾客打一个电话致歉，商讨如何后续邮寄的问题，并向他说明促销的事情。
你是否觉得这个COO当得有点累呢？这当然是虚构的。但是从这故事里面我们看到什么呢？
任何的业务事件都会以某种数据的形式留下足迹。我们对于事件的追溯可以通过对数据的追溯来完成。正如上面这个故事里，你无法回到从前去看看到底发生了什么，但是却可以在单据的基础上，一定程度的还原当时事情发生的场景。当我们把这些数据的足迹按照时间顺序排列起来，我们几乎可以清晰的推测出这个在过往的一段时间内到底发生了那些事情。
那么为什么这些数据形成的链条能够成帮助我们追溯业务的营运呢？
因为这些数据并不是随便挑选的。如果我们回顾一下你作为COO检查这个疏漏的过程，你首先选择了订单和EMS快递存根，换句话说，如果订单出现差错，或者EMS快递存根上说明你的确邮寄了7本书，那么这个疏漏的责任并不在你。所以这两个订单实际上这个你这个企业法律责任的起点和终点。
当你确定这个疏漏的责任在你之后，你选择审查一些流程执行的结果，比如包裹存根。从而验证一些主要的业务流程执行的结果是否正确。换句话讲，这些数据是支撑你运营体系的关键流程的执行结果。
正是由于这些数据是流程执行的结果，它们才使我们可以在不了解流程细节的前提下，对某些突发事件进行追述和分析。
除了上面那个极端的例子（投诉），对于任何一笔正常的经济往来，我们都需要知道：
- 如果我付出一笔资金，那么我的权益是什么？
- 如果我收到一笔资金，那么我的义务是什么？
而这些问题都需要业务系统捕捉到相应的足迹才能够回答。所以企业的业务系统主要的目的之一，就是记录这些足迹，并将这些足迹形成一条有效的追溯链。
而作为业务分析师的你，则应该知道那些事件在运营上是需要追溯的，这些事件都留下了什么足迹。
这些足迹通常都具有一个有意思的特性，即它们都是时标性对象（moment-interval）。发现这些时标性对象就是建模的起点。对于这些时标性对象稍加整理，我们就得到了整个领域模型的骨干：
在得到骨干之后，我们需要丰富这个模型，使它可以更好的描述业务概念。这时候，我们需要补充一些实体对象。通常实体对象有三类：人，地点， 物（party/place/thing）。
在这个基础上，我们可以进一步抽象这些实体事如果参与到各种不同的流程中去的，这时候，我们就需要用到角色（role）：
最后再把一些需要描述的信息放入描述对象（description）。
我们就得了应用四色建模方法（color modeling）建立的一套领域模型。
简要回顾一下上面的过程，不难发现我们建模的次序和重点：
- 首先以满足管理和运营的需要为前提，寻找需要追溯的事件。
- 根据这些需要追溯，寻找足迹以及相应的时标性对象。
- 寻找时标对象周围的人／事／物
- 从中抽象角色
- 把一些信息用描述对象补足。
由于在第一步中，我们就将管理和运营目标做为建模的出发点。因此，整套模型实际上是围绕这些“如何有效地追踪这些目标”而建立的，这样的模型可以保证模型支撑企业的运营。
附言
几位同事帮我审校这篇文章的时候，有人问了一个很有意思的问题：为什么你会以一个看上去像极端情况的例子来说明这个建模方法？ 以我的经验来看，对于业务系统有两个东西是很重要的：可追溯性（traceability）和执行效率（efficiency）。这里的可追溯性是指责任的可追溯性（traceability of liability），而通常都是在一些不太好的事情发生之后，才需要对责任进行追溯。所以想一个相对负面的例子更容易帮助我们找到建模所需要解决的问题。
另外还有位同事说，你的四色方法与Peter Coad的四色法并不完全相同。是的，我所介绍的并不是Peter Coad的四色法， 我不敢说是发展， 仅仅是对于Peter Coad四色的一种变化吧。
感谢张凯峰对本文的审校。
给InfoQ中文站投稿或者参与内容翻译工作，请邮件至editors@cn.infoq.com。也欢迎大家加入到InfoQ中文站用户讨论组中与我们的编辑和其他读者朋友交流。
来得早，不如来得巧——此文甚合我意，嘿嘿
发表人
高 翌翔
发表于
Re: 来得早，不如来得巧——此文甚合我意，嘿嘿
发表人
张 逸
发表于
Re: 恩，俺又Out了
发表人
高 翌翔
发表于
Re: 恩，俺又Out了
发表人
张 逸
发表于
Re: 建议已收到，Thanks！
发表人
高 翌翔
发表于
学到了一个名词：追溯性
发表人
田 美嘉
发表于
我是幸福的小杨明~~我又来了~~HoHo
发表人
yang ming
发表于
在一个业务场景下识别moment/interval显得很关键
发表人
lu ning
发表于
写的不错
发表人
s z
发表于
相对于于方法而言，coad给出各领域的那些图价值更高
发表人
s z
发表于
Goooooooooooood
发表人
lianhao gao
发表于
好文
发表人
wang jie
发表于
-
从极端场景切入->追溯到数据流->相关业务流程，这样对系统有了初步了解；
然后分析整理时标性对象（moment-interval）之间ER关系
->融入业务实体
->结合业务流程融入角色
->丰富实体融入描述对象（description）。
乍一看“四色法”的题目挺唬人，还以为与图论中的四色定理有关
（其实早忘的差不多了），
仔细一读才发现此法实用、清晰，甚合我意，嘿嘿
不妨将题目改得更直接一些，改成：
运用时标性对象（moment-interval）进行领域分析及建模
另，建议为【时标性对象（moment-interval）】给出清晰的定义。
以上个人建议，仅供参考 :) -
老高：
四色建模法作为一种建模方法的名称，在建模过程中已经得到较为广泛的认可，时标性对象是四色建模法中提出的一种分类。所以文章不可能改成你说的题目。可以参考《彩色UML建模》一书。 -
多谢兄弟指正，俺又Out了，哈
《彩色UML建模》已加入书单 :)
几个链接，分享给大家：
彩色UML建模
book.douban.com/subject/3354137/
Peter Coad's 'Modeling in Color'
www.step-10.com/SoftwareDesign/ModellingInColou...
Typical Responsibilities of Moment-Interval Classes
www.step-10.com/SoftwareDesign/ModellingInColou... -
不太建议买《彩色UML建模》这本书，讲得太简略了。还没有徐昊这篇文章说得清楚呢。看看相关资料就可以了。个人意见，仅供参考。
-
确实，满篇都是ER图，与UML好像没有太多联系。
看错书，花钱是小，浪费时间、扰乱思路是大，非常感谢 :) -
追溯性的确很重要，最近在做一个业务比较复杂的系统，有多个足迹，万一系统出错了，找问题还是很费劲，看了文，学会了一种分析方法，很受益
-
天啊~~楼主我又来了~
-
在一个业务场景下识别moment/interval显得很关键
-
四色模型看着简单易用，其实对人的要求很高，这样才能够用看似简单的方法从总体上把控整个系统
-
彩色UML还是很棒的，不是入门级的书，不是给新手看的
-
好文。
对于涉及到资金、权利、义务和法律的系统，系统的‘追溯’功能尤其重要。
文中的方法以事实为依据，法律为准绳，真是需求分析和建模的不二法门。 -
此文有一种让人茅塞顿开的感觉。
12 条回复
关注此讨论 回复