如何用UML表示MAP？

[scalene]

假设有这样一个类，保存了全局的Object，以及Map形式的Key到Object的影射关系
class A {
static MAP<class Key, class Object> keymap;
}
应该如何用UML表示呢？

[stonespace]

rose的UML有一个参数化的类图标，可以用来表示template。先建立一个类，然后在class specification中的type中，把“class”改为“parameterizedClass”，然后可以在"detail"选项卡中加入参数。

[scalene]

我问的是Map，不是参数化。

[stonespace]

Object和Key之间是一对一的关联关系(association)，map是实现关联关系的一种具体的方法。

[scalene]

To stonespace：“A和Object是关联关系，A和Key是依赖关系。”
一定是这样吗？而且，如果UML中画出这些关系，你认为这个结构就表示清楚了吗？

[abenzm]

如果类A中只有一个内成员keymap，且它是全局的，就可以不要再包装成一个类。
我认为，参数化类在C++中是指类模板，它没有具体指定参数是什么形式（int，string..)，上面
MAP<class Key, class Object> 可以用InstantiatedClass来表示.
class key ，class object的对象与keymap的关系是constituent(组合关系），
keymap消亡，key和object对象也就不存在了，在UML中用这样的符号表示：
一条线加一个实心的菱形（图COPY不过来，论坛要改进）
如有不对，请指正。

[twinsant124]

1.如果是实际开发过程，你确实没有必要在设计视图里描述那么多的关系，
根据我的经验和对你问题的理解，在设计时你只需要描述A和Object的关系（Object is part of A,
and it can exist without A,so they associate with whole-part
relation,that means aggregation.You can get the answer of their multiply urself.),然后
把它交给程序员，程序员自然会用更高精度的描述－－代码来做到你的要求。我认为用UML来
描述实现没有任何价值,在实现时，作为一个程序员，我们应该用代码思考。

2.如果你非要用UML描述你的实现，你还得从你的实现里抽取概念：
首先看看有几个类：
A,MAP,Key,Object
their relations:
A is an aggregation,which aggregates with an instance of MAP.
MAP is associative class between Key & Object.
You can describe MAP using stereotype OR constraint OR etc.

3.实际上如果你要关注两个类之间的联系，觉得联系很重要，就得把它抽象成类（当然实现未必要用类，呵呵）。

4.Tips:
a.我们要描述什么问题？
b.用UML来描述是不是使问题更清楚？是不是更有利于我们解决问题？
c.Remember that UML is ONLY a language,is ONLY a kind of description.
if UML confuse you, forget it please!

[scalene]

To abenzm(凤凰台) :当然A里不只有一个Map，要不然它真的没什么用？
To twinsant124(蚂蚁的天空) ：你的意思是“此题无解”？Map和static问题只能到实现阶段在考虑？So your answer is : 只记录is part of关系再加上Key-Object的对应关系，Okay?
或者真是如此，以前我也确实是这么做的（因为没有办法啊）。但我真希望能够有更好的方法。

[scalene]

也许我的问题问的不够清楚。stonespace(stonespace) ：你说的我明白，而且你说的也不准确，Key, Object, Map间应该是一种三元关系，可以化为二元关系。我想问的是，对于具体实现来说，Map应该是一种实现细节，应该在UML图中不显示；象我上面写的伪码，A，Key, Object之间可能有几种关系：A拥有Key, Object；Key是临时变量，A拥有B；Key被另一个类（如B）拥有，Object被另一个类（如C）拥有；Key是临时变量，Object被另一个类（如C）拥有。那么，该UML图在各个情况下应该如何表示呢？

[stonespace]

你是不是要用UML描述具体实现，

如果是你最前面写的伪码，我认为关系是这样：

MAP<class Key, class Object>是一个容器，聚合Key和Object；这个容器类只有一个实例。

因为MAP<class Key, class Object>是全局，所以A和MAP<class Key, class Object>应该是多对1的关联关系。

A和Key的关系，因为Key是临时变量，所以应该是依赖关系。其他使用到Key的类和Key之间也是依赖关系。

因为MAP<class Key, class Object>包含了Object，那么其他的类用到Object的，比如A，应该只保存Object的指针，指向Map容器内部的Object，因此A和Object的关系是1对多的关联关系。其他类不能拥有Object，因为map已经拥有Object。

这些关系都可以用UML描述出来。

[abenzm]

我想南瓜汤的意思是：用UML表示出类A和MAP<>的关系，而不是自己写一个模板类。stonespace没有必要分析的那么详细。问题是，MAP在UML中怎么表达，它与A的关系，A的全局性又怎么表示？这也是我不清楚的地方：）

[stonespace]

我上面说了，我认为类A和MAP<>的关系的关系是1对多的关联关系，不是聚合关系。理由是，A的实例没有包括Map，而是每个A的实例可以引用map，这样的关系应该是关联。

另外特殊的地方是，map<>类只有一个实例。

应该是Map有全局性而不是A有全局性，我认为所有的类似C++的static成员，都是关联关系而不是聚合关系。

[stonespace]

MAP<class Key, class Object> 在UML中应该描述成为一个参数化的类。

[scalene]

abenzm(凤凰台)说的比较符合我的本意，stonespace：你总是在纠缠一些细节的编程级别的问题，这些我都清楚，我问的是一个设计级别的问题：A-Key-Object三者的关系如何表现？Map是一个detail的实现，在UML中可以不显示出来的。

[stonespace]

如果从设计级别上说，我只看到了Key到Object的1对1的关联关系，UML只要把Key类和Object类拉一条线就可以。

A和Object是关联关系，A和Key是依赖关系。

但是我感觉这个结构，在设计层次上不完整，缺少一个东西。因为在实现中MAP不仅表示关联关系，还承担了另外的职责。

其实我觉得如果先做设计的话，不应当写出这样的伪码；从设计上看，感觉这个结构缺乏一个Object的管理者，你在实现中用MAP来承担这个职责，但是MAP只是一个低层次的类，无法在设计的阶段表示和业务相关的语义。

我认为设计的时候应当有一个类承担Object管理职责，内部封装MAP，对外A用关联关系取得这个类的指针。这样才在设计层次上职责的分配才完整。

[scalene]

这里的伪码只是为了让大家看懂这个问题才写的。做设计的时候，当然不会先写这样的程序。
“从设计上看，感觉这个结构缺乏一个Object的管理者，你在实现中用MAP来承担这个职责，”——你没有看我写的回复吧，根据实际需要，这里Object的管理有若干种可能的。
“但是MAP只是一个低层次的类，无法在设计的阶段表示和业务相关的语义”——当然，我只是问当A-Key-Object之间的逻辑关系是一种Map时UML怎么做，我已经再三强调Map不是UML的内容，你为什么还在这里纠缠不清？

[twinsant124]

I do NOT understand your question actually :( as well as i can't get the reason why you MUST desc your implmentation in UML.In fact, if i was playing a designer role,i'd rather write the UML docs as we have talked above.And if i was playing a programmer role, i'd rather read these kind of UML docs too,which are enough for our coding works. More details are unnecessary, which waste your working time. I DID think i could do more valuable work instead of doing this.Don't you agree with me?

[scalene]

最初的设计可能不需要；不过有些时候你会需要用UML来分析一下系统结构和性能，这时候，有一些细节可能是必要的。