color uml and dci 的问题

11-04-15 dArtist
前段时间看了下color uml 和 dci 发现 四色原型可以直接通过dci来实现 觉得非常不错。
在网上看了几个dci的例子——主要是转账那个，然后自己开始琢磨1个使用技能子系统的实现（我是做游戏的...）

通过trait 实现了 部分类之后 发现了1个比较严重的基础问题：是ppt在参加mi中扮演role 还是ppt扮演role参加mi。

这里考虑的一个例子是：

ppt: Character
role: SkillUser SkillTarget Skill
desc: SkillInfo
mi: UseSkill

我在useskill的实例中 应该保存的是 role 还是 ppt
在转账的例子中transfer的实例中保存了 Account（ppt） 而不是 TransferMoneySource(role) 和 TransferMoneySink(role)

我总觉得理解起来怪怪的 还望各位指教

[该贴被dArtist于2011-04-15 13:43修改过]

banq
2011-04-15 14:16
2011年04月15日 13:41 "@dArtist"的内容
是ppt在参加mi中扮演role 还是ppt扮演role参加mi ...


都不应该是，PPT是PPT，表达在什么地方什么事情，而Role是角色，两个意思分明很清楚。

转账案例有一个特殊地方是Account，Account在一些系统是ROle，而在一些系统是PPT，不能按照通常意义来理解。

dArtist
2011-04-15 14:34
2011年04月15日 14:16 "@banq"的内容
2011年04月15日 13:41 "@dArtist"的言论
是ppt在参加mi中扮演role 还是ppt扮演role参加mi ...


都不应该是，PPT是PPT，表达在什么地方什么事情，而Role是角色，两个意思分明很清楚 ...


我想表述的意思是在四色原型中ppt应该是通过一个role间接的进入mi
但这个间接性发生的时机应该是什么样的，也就是说对于mi来说 他能处理的是ppt
还是role
就好像我现在的UseSkill
new UseSkill(Skill skill, Character user, Character target).execute();
new UseSkill(Skill skill, SkillUser user, SkillTarget target).execute();
这2者区别在于第1个mi他获知了ppt 在execute的时候把 ppt 赋予了1个role
即 context.act(user,SkillUser.class);
而第2个mi则是只获知了role 进而直接进行操作。
对于我说的转帐来说 就是第1种


[该贴被dArtist于2011-04-15 14:53修改过]

banq
2011-04-17 10:24
在我看来，ppt不是每次都需要的，我对四色原型的归纳是：什么人role在什么地方ppt做什么事mi
有时情况简单，就是：什么人role做什么事mi

dArtist
2011-04-18 09:43
2011年04月17日 10:24 "@banq"的内容
在我看来，ppt不是每次都需要的，我对四色原型的归纳是：什么人role在什么地方ppt做什么事mi
有时情况简单，就是：什么人role做什么事mi ...


banq大 我的理解和你的好像有偏差，我记得color uml中有1张DNC的图
里面很清楚的表现出了所有的PPT都不是直接与MI产生联系的

就好像你说的 什么人 其实是ppt 而不是role 什么地方是ppt但不能直接在mi(活动中使用) 而应该变成相应的 活动场所(role)

所以最后的的四色原型(可能)是这样的：

现在有1个活动（mi）,
某某某（ppt）将作为本次活动的参与者(role),
本次活动的地点(role)将选在某地(ppt),
本次活动的活动物品(role)有某物...(ppt).

上面是我的理解，可以很清楚的看出带某字的都是ppt,带活动的前缀的都是role,而活动就是mi,而desc其实就是对ppt的划分.

但是现在的重要问题是如果我以接口的形式实现role的话，在每个mi中保存接口信息是非常无用的，因为很多情况下都可能要查询历史记录，而查询则需要具体的类型信息，现在我就对此比较困惑，不知哪位能提供1个比较好的解决方案。

banq
2011-04-18 09:58
我们理解是有偏差的，主要差别是你对角色概念比我广泛，我承认PPT有时可以作为Role，但这些都是特例，四色原型就象色彩三原色，它们是基本的颜色，互相不可替代，如果相互复合，就可以组合成另外一种颜色。

PPT是可以扮演Role的，就象黄色和青可以组合成绿，PPT可以和Role组合来表达一个事物。

如果抓住四色是基本色，不可互相替代，它们之间是严格的边界关系，那么，象你的问题就迎刃而解。

解答不了你的问题，说了这么多废话啊。

tangxuehua
2011-04-25 17:03
banq, 我有一个想法。DCI强调，某个PPT只有在参与某个场景时，才具有那些所谓的场景状态和场景行为。离开了该场景，则这些场景状态和场景行为就不需要了。从而，大家得出一个想法：需要动态为某个对象增加状态或行为。

其实我觉得我们可以换个角度来理解：

PPT始终是PPT,对象永远是那个对象，并且该对象永远已经具有了所有的可能参与到所有场景的状态或行为。只是在没有参与任何场景时，该对象的所有和场景有关的状态和行为都是对外不可见的，即私有的，而只有到参与时才可见。我得出这个想法的原因是：我发现现实生活中的客观存在，比如一个人，他虽然在一天中扮演了不同的角色，每种角色会具有不同的行为，然后大家自然而然地得出“动态注入行为”的思路。但我觉得恰恰相反，其实一个人本质上已经具有所有的行为了，只是在特定的场景下，也就是在扮演特定的角色时才会表现出来。但不管有没有表现出来，人本质上应该也一定已经具备了所有可能的行为了。因此，我觉得这应该是一个”表现出来和没有表现出来“的问题，而不应该是一个“具有和不具有“的问题。从这个角度来看的话，我觉得一个人的身份（角色）不能决定一个人可能具有的行为。最多只能表示一个“触发器”，即一个人具有了一个什么什么样的身份时，才会触发他的一些行为并会暴露到外部。因此，我觉得我们还要重新考虑和认识到底什么是PPT，什么是Role，而什么又是场景活动。我觉得这些概念没有目前我们所认识的那么简单。很多事情可以从多个角度和方面去理解，往往会得出不同的结论。banq,希望我的话能带给你一些思考，呵呵。

这样的思路会引导出这样一种设计，我们可以将一个对象的所有和场景有关的状态属性和方法行为全部私有化，然后当某个场景发生时，会触发一些和场景相关的事件，然后对象会去主动响应这些事件，从而完成“参与场景活动的效果”。至于如何去主动响应事件，可以有很多实现方法，比如事件总线，事件驱动等设计。这样就避免了“动态注入行为”的难题。因为在我观察看来，目前在C等静态语言里，我们无法动态为一个对象增加状态或行为。不知道C#4.0中的动态类型是否能实现这个功能。当然一些动态语言如javascript是可以实现的。但我记得一位大师说过，动态语言不太适合做大项目，还是强类型的静态语言比较适合做大的工程，呵呵。

banq觉得我的想法如何呢？


[该贴被tangxuehua于2011-04-25 17:25修改过]

[该贴被tangxuehua于2011-04-25 17:42修改过]

banq
2011-04-25 17:53
2011年04月25日 17:03 "@tangxuehua"的内容
banq觉得我的想法如何呢 ...


你的想法很有创新性，我们首先抛开语言是否能够实现的约束，讨论一下你的想法。

PPT的场景行为可以进行隐藏或打开，关键问题是：PPT的类就会变得很大，而且这种思路也表现为：行为强制服从于实体类。

实际上，我们真的不能受Java或C等语言的误导了，这些语言的约束前提是：对象就是类，实际对象不一定是类，也可以是行为。在“对象就是类”这种约束下，我们才不得不引入事件或消息触发。

如果我们更换一下思路，正如楼主理解一样，将一些场景行为理解为PPT在某个活动中扮演某个角色Role时才具有的，也就是如同演员演戏一样，你再拓展一下，我们真实生活也是在“演戏”，这是真戏罢了。

可以将四色原型和DCI对应如下：
MI:场景
Role:参与角色
PPT:参与实体
DES:实体有关特征数据定义。

实体PPT参与某个场景活动，扮演其中某个角色，然后实施与这个特定场景有关行为交互。这个结合过程还是非常自然，从分析到设计到架构实现几乎是一步到位，不存在类似数据库的转换，DDD方法可以作为PPT和DES等静态事物的细化方法。

这样，四色 DCI DDD几乎是对需求进行系统分析系统设计的非常直接，大道至简的一套好方法，如此简单易懂，真不知道国家还进行“软件系统分析师”和“软件系统设计师”考试的脸往哪儿搁？

tangxuehua
2011-04-25 22:46
呵呵，谢谢banq老师的指导。

1）首先关于你提到的行为会强制服从于实体类的问题，我并没有觉得有什么不妥，因为我觉得行为不能独立存在，肯定是某个客观存在表现出来的某种“动作”。可能你说的是所有的行为都在一个类里了是吗？呵呵，当然，在OO的世界里，我们可以用继承和组合来达到复用的目的。所以，正确的说法应该是行为固化在所有相关的类里；

2）现在的我确实还无法理解为什么行为也可以是一个对象。我觉得对象应该是可以被界定的东西，而行为只是一段逻辑，逻辑本质上我觉得不应该是一个对象，而是应该依附于对象才有存在的意义；

3）另外，你还提到PPT的类会变得很大的问题，对于这个问题我不怎么觉得是一个真正的问题，呵呵。比如，现实生活中的一个客观存在，比如人，他有很多很多的能力，具有很多很多的行为。但我们并没有认为他行为太多了而把他的所有行为按照角色来拆分到不同的你刚才提到的“行为对象中”。一个人一旦通过学习而具有了某种能力后，就已经永远具有该能力（行为）了，不管他有没有表现出该能力（行为）。

角色这个东西，我觉得是我们人类思考出来的一个东西，是人类主观意识的产物。按照我的理解，能参与MI即场景活动的参与者一定是客观存在的东西，比如PPT，虽然此时的参与者在我们人类看来具有一定的角色，但本质上还是一个PPT，角色只是我们主观意识上的一种理解。我们不能理解为是角色在参与活动，而还是应该理解为是PPT在参与活动；角色只是一个定语，即什么什么样的人或物，这个“什么什么样的”其实就是角色。但不管角色是什么，都不会改变PPT在参加活动这个本质。

呵呵，最后我还是觉得应该只要用下面的方式来理解就可以了：
PPT直接参与MI，不需要有角色的概念，角色仅仅是人类的一个思想产物，并且目的也只是为了帮助我们人类更清晰的分清职责而已，但并不意味着要参与到建模中来；实际上我们关心的核心目标是确保当前参与场景活动的各个参与者具有应有的状态和行为即可；当然另外一点我们还需要确保的是，PPT除了一些基本的本质行为和状态外，其他的和当前场景无关的场景状态和场景行为应该隐藏起来，只暴露当前场景需要的场景状态和场景行为即可，因为用不到。

[该贴被tangxuehua于2011-04-25 23:02修改过]

banq
2011-04-26 10:16
2011年04月25日 22:46 "@tangxuehua"的内容
角色仅仅是人类的一个思想产物 ...


同意你这句话，角色这个概念是一个主观产物，也算人的一种方法论工具吧，不过透过角色来分析事物也确实很方便，比如Java中就很成功应用了RBAC，将角色权限和特殊业务进行了分离，如果有用，我们能不能进一步挖掘呢？

动作是可以成为单独对象，现在Node.js很热，应该说最热，其Javascript的面向函数动作特征被大家挖掘，例如var o=function(){}，这就是为一个动作创建名称为O的对象。

如果我们用静止的眼光看待世界，那么整个世界都是实体类，可是如果我们用动态眼光看待世界，则会发现千姿百态，比如经典的银行转帐案例，转帐涉及到两个账户实例PPT，那么转帐功能是放在哪个PPT中呢？很显然，转帐属于账户PPT参与的MI。这样很自然直接。

还有，如果一个类代码很大，虽然不违背分析原理，但是违背了设计原理，如何进行切分细化呢？分析设计编程的过程实际是一个专业细分分解过程，然后所有代码整合在一起运行，达到最初需求的目标，首尾相和，但是中间是被分解的。很多产品都是这样，生产喝水的钢杯子，需要分解为钢铁行业，锻造行业，模具行业等方面。

总之，你的想法很好，值得探索，如果能够解决这些细节问题，也许可以成为一种公认的模式，而且这种模式方法好处是能够在现有平台语言上拓展。

关于你说的“我们不能理解为是角色在参与活动，而还是应该理解为是PPT在参与活动”，这和楼主疑惑：“ppt在参加mi中扮演role 还是ppt扮演role参加mi”应该是一样的。我可能倾向于后者：PPT扮演Role参加MI，MI是场景，戏剧中一个个场景，而PPT是一个实体，有其自己固有特征，通过穿上角色的戏服，实施和角色有关的动作，比如包拯升堂等。













[该贴被banq于2011-04-26 10:22修改过]

SpeedVan
2011-04-26 10:39
角色是主观产物，但同时职责（或者权限）分配也是主观产物。想用PPT来描述实体“能”干什么，那是痛苦的事。正如banq，所说的，不违背分析，但是违背设计。若果你看见一个类，拥有着10页纸方法，多么痛苦的一件事。从另外一个方面所，所有都归为PPT是一种非组件化得思维。

tangxuehua
2011-04-26 10:49
感谢大家分指导，确实从设计实现这个角度来看的话，很多方法全部放在一个PPT中，不是很好，确实不是很方便的管理。我还要在思考思考。但关键是目前的DCI在静态OO语言中确实比较难实现。

tangxuehua
2011-04-26 10:55
其实我现在还在思考另外一种模型设计的方式，简要描述如下：

该模型具有如下三个特点：
1）模型中的各个对象之间没有任何关系（无对象引用，无唯一键关联），并且对象的所有行为不需要暴露出来，全部私有（private）即可。因为对象的所有的行为都是自己主动去“表现”出来的，即对象的行为（方法）都是对象自己表现（调用）的；
2）一个非常强劲的关系引擎（该关系引擎维持了所有对象之间的关系，并且是智能的，非常类似于人类的大脑）；另外，该关系引擎可以接受消息和智能地将消息传递给需要响应的对象（这点也非常类似于人类的大脑）；通过消息机制完成对象之间的任何形式的交互与协作；
3）非常重要和关键的一点是：任何对象需要关注的只是发送消息给关系引擎，不需要关心消息如何被传递，如何被响应；对于响应消息的对象而言，也不需要关心什么时候该去响应消息，什么时候不该响应。因为关系引擎会自动通知那些需要响应该消息的对象去响应；

但是感觉按照我目前的能力，还无法将我的想法变成现实，尤其是关系引擎的实现，因为这个相当于要设计一个人类的大脑呢。但我确实在为之不断努力，大家从我最近发表的文章和发布的代码就应该能看出来。

希望我没有走火入魔，呵呵。

banq
2011-04-26 11:02
2011年04月26日 10:55 "@tangxuehua"的内容
希望我没有走火入魔 ...


很有创新性，数据库使用NoSQL，关系使用EDA或ESB，应该是一种全新的角度，首先肯定一下，待我慢慢沿着你的思路进行战术性深入思考一下才能和你进一步交流。

tangxuehua
2011-04-26 11:06
哈哈，谢谢banq的肯定，这也极大振奋了我继续研究思考下去的士气。

有2页 Go 1 2 下一页