2011/10/1413:29:15京马志忠(199***90)
这个箭头，这么画对不对
2011/10/1413:29:08京马志忠(199***90)

2011/10/1413:30:28UMLChina潘(704837756)
重了，把_id删掉，要不就把关联删掉
2011/10/1413:31:40UMLChina潘(704837756)
你这个图的背景是什么
2011/10/1413:32:14京马志忠(199***90)
是这样子，id到没什么大问题，主要是一直在考虑关联的方向
2011/10/1413:32:38京马志忠(199***90)
我再画个实际的图2011/10/1413:36:47
UMLChina潘(704837756)关联是概念，id是概念的实现。不要画在一起。
谁有谁的 id，那是关联的实现。A关联 B，如果 id指引用，实现起来是 A有 B的id，如果是数据库，根据多重性的不同，也许就会反过来，B有 A的 id
2011/10/1413:38:20京马志忠(199***90)

2011/10/1413:38:38京马志忠(199***90)
这个线的方向对吗
2011/10/1413:39:06京张伟芝(76****66)
会员积分是不是只是个属性？
2011/10/1413:39:43京马志忠(199***90)
我这单独分开了
2011/10/1413:40:20京马志忠(199***90)
只要说这个箭头的方向对不对就行
2011/10/1413:40:44京张伟芝(76****66)
关联的话，会在对方自动添加属性，会员积分里的会员 ID应该不用写出来
2011/10/1413:42:57UMLChina潘(704837756)
首先，还是老问题，关联和把对方 id作为属性，有一个就够了。其次，你可能问的是关联的方向是谁指谁更合理，这个没有标准答案，看系统上下文中，会员的状态丰富还是积分的状态更丰富。从常识说来，估计是会员的状态更丰富，应该会员知道自己的积分。第三，你这个图倒是象数据库模型，一个会员有多个积分记录，一条积分针对一个会员...
2011/10/1413:43:32广赵华(13****41)
不用纠结于这个，俺觉得
2011/10/1413:43:54京马志忠(199***90)
会员和积分是 1对多
2011/10/1413:44:59UMLChina潘(704837756)
多重性的影响体现在某些媒介的存储考虑不同（例如关系数据库），但不要用多重性来判断关联方向
2011/10/1413:46:04UMLChina潘(704837756)
不纠结就是回避了问题：会员的状态丰富还是积分的状态更丰富，是会员分配责任给积分还是积分分配责任给会员。
2011/10/1413:44:01广赵华(13****41)
uml需要简化，搞这么多箭头，很费劲。
2011/10/1413:44:10京马志忠(199***90)
有箭头还是好的
2011/10/1413:44:11UMLChina潘(704837756)
谁指谁，跟多重性没有必然关系
2011/10/1413:44:52广赵华(13****41)
编码的时候，自然就知道啥关系了。
2011/10/1413:48:32UMLChina潘(704837756)
编码的时候，我说人是狗的一种，照样编译通过。
不能这样想：因为我是这样编码的，所以设计就应该是这样。而应该这样想：因为我的业务逻辑是这样的，所以这样设计更好一些，所以按照设计这样编码更好一些
2011/10/1413:53:25UMLChina潘(704837756)
很多次我让开发人员给我讲他的设计，他就给我讲 A调用 B，B调用C，A调用 D....问他为什么要这样，就说：我编码就是这样编的啊。这是不讲理由了。类似场景：让开发人员讲需求，巴拉巴拉说了系统需要有什么功能，问为什么要有这些功能，一样回答：系统本来就应该有这些功能啊！
2011/10/1413:54:13UMLChina潘(704837756)
建模就是要强迫你去思考，面对这些问题。而不是随便"有个代码出来就行"，"有个需求出来就行"