我不怎么同意以请求者和响应者的角度来分析请假领域。

我比较倾向于,直接对于现实的描述和抽象——即请假者,主管,领导,上级等。这是一种领域思维,领域思维讲究直接瞄准当前现实,不要再过分想象和抽象。请求者和响应者已经超出了“请假”的现实描述,从另外一方面说,这已经脱离了客户的心智模型了。

请注意,做应用和做框架是两回事,领域思维,领域分析是让我们更好地做应用。而进一步抽象出专业框架,企业框架,那并不是应用开发的范畴。请求者和响应者,有点过分抽象了,不利于对当前实现的投影。

尽管我们看到了请求和响应这一逻辑,但这是用来验证我们对领域描述是否逻辑严谨,并不是用来描述领域。

关于图书馆例子。入库,出库也已经脱离原来的核心了,入库出库只对图书库的书库而言,与人无关了,但现在核心是“借书”和“还书”,是人,书库,书的一个共同活动过程,从这里就可以看出入库出库和还书借书是不能划上等号的。

角度不同,致使理解角度不同,也就使模型不同了。

最开始时,用主管、领导直接描述或许不会有啥问题,因为此时我们未必可以觉察出哪些是不变的东西,预测出那些是变化的东西。

可是当showerxp和IceQi陈述了更多的用户需求时,就有必要为诸多需求找出共性了。下级在“请假”这个“场景”中扮演的是提交申请或发送请求的角色(submitter),上级在“请假”这个“场景”中扮演的是审批申请或响应请求的角色(approver)。

请假的英文翻译"request for leave",请假的中文解释是“请求休假”,请假本身就是一种“请求”(request),在讨论请假这个业务场景时,用“请求”来简略表示“请求休假”或“请假的请求”,并无不妥呀。

其实,请假是审批流或工作流中一个比较常见的例子,应有现成的解决方案。至于IceQi提到的根据请假的天数由不同的人来审批的需求,即“把请假天数不同的请假条(请求),递交给不同的审批人手中”, 可用“责任链”进行重构。

你所说的建模指什么?UML 用例模型,类图? 还是其他?
横看成岭侧成峰,远近高低各不同。抽象是脑力劳动的结果,没有必然的客观答案。就我描述的用户故事来看,你认为抽象成“请求”-“响应”也行。只是还应当考虑的问题是:如果太过抽象很可能照成沟通上的问题。抽象后的模型,需求分析师、设计师、程序员、用户、涉众都要共享,简单的上下级描述关系不用,非要用上High-Tech名词“请求”-“响应”,势必造成某些关注者理解上的困难。
软件制作不是一个人的战争,抽象又是对实际问题的认为总结,归纳。所以不可能完全无误的反应客观世界。因此,软件相关者需要一个清晰稳定的抽象模型,那么抽象过程就要遵循的一条根本原则就是:从客观实际出发,根据用户需求对业务重点迭代进行。
2011年07月03日 21:17 "@showerxp"的内容
抽象后的模型,需求分析师、设计师、程序员、用户、涉众都要共享,简单的上下级描述关系不用,非要用上High-Tech名词“请求”-“响应”,势必造成某些关注者理解上的困难。 ...

用户描述的用例是用户级别的应用描述,在用例到软件模型之间需要一层抽象,这层抽象主要的作用是归纳和总结用户的核心业务过程为软件模型的分析提供基础。这一层不是面向用户的,只是面向软件模型的设计人员。

用户只需要知道“我要做什么”但是软件人员一定需要考虑“这是为什么”。更多的时候大家都在考虑“用户说了1。2。3”,然后发现用户始终在修改和增加自己的描述,然后总是抱怨用户需求变更。“变化的永远是形式,稳定的始终是核心”。就好像做HTTP客户端我们必须主要参考RFC文档,而不能是微软的IIS实现。面向用户我们也需要挖掘出他们需求的核心内容,核心确定了才能够适应层出不穷的形式变化,如果从开始就只注重形式,那么永远走不出这个迷阵。

通常用户并不知道软件应该怎么帮助他们,只有我们知道。

2011年07月04日 10:00 "@IceQi"的内容
面向用户我们也需要挖掘出他们需求的核心内容,核心确定了才能够适应层出不穷的形式变化,如果从开始就只注重形式,那么永远走不出这个迷阵 ...

说得很好,说个非技术话题:我以前做过企业IT,当你和你的用户意识到即将达到那个核心时,他们突然开始保守,好像不愿意将这些核心告知你,因为这些核心也是他们赖以生存的依靠。这涉及到利益问题,很多软件系统因为这样嘎然而止,很可惜啊。

2011年07月04日 10:39 "@banq"的内容
当你和你的用户意识到即将达到那个核心时,他们突然开始保守,好像不愿意将这些核心告知你,因为这些核心也是他们赖以生存的依靠。 ...

这样呀,那对话看来还需要一些未知的技巧。不过,这个话题涉及的“抽象”主题,我还是有明确的观点。

1)抽象若能带来更清晰的语义,可为之;若不能,则慎之。
2)我们不能低估抽象的力量,同样不能低估直观的力量,只要能带来更清晰的语义,皆可善用之。

例子:爸爸、妈妈和孩子去公园玩->大人与小孩去公园玩->人去公园玩->人去玩···

从上可见,抽象是强大的,但也是恐怖的。

抽象这个度,把握好。可以使语义简单明了。太浅和太高都会带来与我们期待相反的效果。所以我前面就说到“请求”-“响应”,这个在我看来是过度抽象了。

领域建模提出了,建模应该是客观领域中,客户所关注的部分的抽象。而且是跟随领域的各种基本概念,而不需要更深一步的抽象,否则模型变难读,甚至不可读。

>>他们突然开始保守,好像不愿意将这些核心告知你,因为这些核心也是他们赖以生存的依靠。

<<的确,这是一个现实,如联强国际这样的大公司,为什么自身研发的系统会如此合适自己,其实不是外界软件商不能做到,而是自己做则回避了核心利益问题,可以更符合自身的发展规律。

>>他们突然开始保守,好像不愿意将这些核心告知你,因为这些核心也是他们赖以生存的依靠。
同感。遇到过几次。
一个看似简单的“请假”问题,可以有这么多的讨论,看来软件设计真的是没有一个定论的,需要有将现实世界抽象到软件世界的艺术!
软件应该算是工程,恐怕很难算是艺术。

现在的问题是主要依靠个人的想象和创造力,缺乏真正的理论引导使它成为能够被稳定复制的制造过程。

2011年06月27日 19:09 "@IceQi"的内容
您观点我很认同,这更像是进一步的抽象,就像《分析模式》一样,讲的是在具体的业务模型上进一步的抽象。

这种抽象应该不是每个人都具备的吧,最近一直在和朋友讨论,有没有一种很自然的建模方法,让我们尽量减少经验的参与,能不能自然而然的推导出结 ...

这个应该是一种思维模式的问题,经验不经验反而不是那么重要。抽象的过程就是抓住事物本质的过程,而这种思维模式显示不是每个人都具备的,更多的人只会被事物花样繁多的外衣所迷惑。

“这两个是同一种事物”我经常和别人说这种话,可是现实是,能明白的人很少。

我很久以来都在思考如何能让别人养成这种一直见血抓住事物核心的能力,但是很可惜,一直都不得其法,要改变一个人的性格,而且是外因的改变,太难。

2011年08月09日 10:54 "@fhjr999"的内容
。抽象的过程就是抓住事物本质的过程,而这种思维模式显示不是每个人都具备的,更多的人只会被事物花样繁多的外衣所迷惑。 ...

我认为这个能统一的思维模式是“逻辑”。

我说过:中国人缺乏的不是知识,而是逻辑。

很多学习成绩好的人都是把逻辑当知识,结果考试考得很好,喜欢看罗素的“西方哲学史”,而不是罗素悖论和摹状词理论,使用数学来很长时间,却不知道数学符号背后的逻辑。

另外,也可能和中国文字有关,西方文字都是字母,本身没有任何意义,所以,养成西方人关注无意义字母后面的逻辑;而中国人一开始到现在就醉心于文字表面,那么多诗人词人.....

2011年08月09日 14:18 "@banq"的内容
我认为这个能统一的思维模式是“逻辑”。

我说过:中国人缺乏的不是知识,而是逻辑。

很多学习成绩好的人都是把逻辑当知识,结果考试考得很好,喜欢看罗素的“西方哲学史”,而不是罗素悖论和摹状词理论,使用数学来很长时间,却不知道数学符号 ...

你说的很对,这个确实是逻辑,但是这种逻辑很大程度上是依赖的思考习惯。
只重表面,不重本质,不重事物内在联系的思维方式也许正好反映中国教育的失败,我们的教育模式是不停的做题,同一个题目改头换面一下就有了另一个花样,至于有没有老师提点过这不同马甲之间的联系,我记不得了,也许有,也许没有。

一个人和一条狗站在一起:

甲说:“一个人和一条狗”;
乙说:“俩哺乳动物”;
丙说:“俩哺乳动物或者俩动物或者俩生物或者.......”;

你会是甲还是乙还是丙呢?