大家一起来提高建模能力吧：）

感谢凤舞凰扬的回帖：）
怎么说呢，我出的这个题目毕竟不是一个实际的系统，仅仅是一个GAME，所以仅仅就是一个业务模型的建模，而没有涉及到流程，如果牵扯业务流，那就不是一句两句的问题了，还有很多行业相关的知识，也许就会陷入细节中的扯皮了。

其实就是单纯的实体建模也有很多值得探讨研究的，我画的UML图，其实只用到了n v n这种关系图，而没用用到其他的概念，这些都是希望大家改进和探讨的。现在大家都在O/R，那么对象建模就是很重要的第一步，实体模型不够合理，也会给开发带来很大麻烦。

：）终于看到新图了，真好。我会继续放上我修改的图
保持气氛，继续交流，呵呵

你们继续，必要的时候我会做一个点评。
就目前情况看，你们对于类的命名都不是很好。

哈哈，欢迎o6z兄指点，大家讨论讨论

：）我做了一些修改。
1。去掉了房间订单类。从和旅店的关系中，即可知道所订数量

o6z:
：）说一下类命名的事情吧

名词法你们知道吧。现在就按照名词法把你们的类整理一下，现在的图基本没有办法看。

o6z说得是
   另外，回清风：
1.所谓付款方式，只是你程序将它处理放在常量文件中，它并不是类（当然它是以类的形式来表示，不过更可以以其他方式，比如约定什么），不是建模层次需要考虑和做的。
2.如o6z兄所说，至于自驾车和乘飞机，作为对象，命名是不恰当的
3.另外，更重要的问题是对象的属性，描述得不恰当，比如说旅馆的出发时间，自驾车的欧洲海关，还有属性的值类型，都是Int,。
   如果单纯从几个对象的关系图来看，也许找不出更多，但是，问题是对象的建模是否恰当而准确地描述了业务实体的关系呢？

有道理：）继续修改之

另外，类型选为int实在是我手懒，就没选择类型

改后我再放上，呵呵

你们可以注意到这些类都是以数据为主，也就是以属性为主。这基本上是一种ER建模的风格，这样不好。
同时也要注意，建模的时候对于命名和联系的确立要保持一个统一的风格，这样才会给阅读的人以及自己进行检查和修改带来方便。
你们继续！
同时我们要注意区分，我们是在为业务进行建模还是在为编程进行建模。这之间是有微妙的区别的。就目前情况看，我建议大家先做好对于业务的建模。

为业务进行建模还是在为编程进行建模确实是我目前把握得不好的地方，能说说这之间的差别吗？