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

业务建模主要是以描述业务环节中的业务对象的种种行为,不会涉及什么界面和数据库表格之类的东西.而程序建模,你就要考虑表和界面以及线程等具体的软件的结构.
实际上业务建模可以应用在对业务层建模,以及企业的商业建模等都方面的应用.在现实中这个活动会更加的复杂.但是作为一种学习,它要简单一些.

试着用colorUml方式建模

tuti
建议你看看领域无关模型，也就是DNC。你的模型有部分合乎DNC，有的部分不合乎。我建议你完全按照DNC来。

什么是"领域无关模型"?

ozzzzzz
你就给我们演示一下啊
别光指点不干嘛

我也没有看懂o6z所说的DNC（领域无关建模）是什么意思。
   不过如果就tuti的模型说一些问题吧。首先tuti建立的应该算是概念模型（Concept Model），简单地讲，就是ER关系模型，而并非对象模型。但如果严重一点讲，这是一个四不象的模型，也就是它既不完全是概念模型，中间还夹杂着业务用例模型。
   这么说吧，在图中所有用红色表明的并不属于概念模型的范畴，他们只算是业务用例而已。而如果这个模型图是业务用例模型图的话，那又有几个非常大的问题，第一就是它不是用Use case图来描述，第二，它将概念模型（比如绿色和灰色，黄色还勉强可以理解成business actor）和表示业务关系的用例描述在一起是不恰当的；第三，在概念模型中关注的应该是业务实体，而并非物理实体数据模型中所有，比如房间类型、酒店类型，这些都不属于专门的业务实体，而只是业务实体的补充描述，也就是属性（简单地讲就是酒店这个业务实体中必定含有所属类型的属性，当然这种属性在物理数据模型中我们会用单独的表来存储或表示）。第四，对于黄色底色的对象实体，也就是所谓role，模型中存在错误的关系描述，比如讲滑雪者和乘客、自驾车、住宿者自己存在怎么样的关系，从图形的表述，似乎都是游客的子类或者说关联对象（因为我实在无法把这个模型确认成什么模型），但是从那种角度去看和理解，都存在相当大的问题的。
    本来以为这个帖子沉了，没有想到又有网友推上来了。大家可以继续讨论讨论

o6z 所说的DNC 是colorUML中的概念.
上面这个模型,是我根据我对coloruml的理解所画的,
确实没按最纯正的DNC来画.

我来瞎掰

其实这个应用不适合用固定的模形来解决的 因为其结构会经常变化 定单本身的条目和内容也会随服务的变化而变化

所以不论是类还是关系数据库的集合概念在这个应用中都是不适合的

这个应用本身是以文档为中心的 中心文档就是定单 定单内容来自 客户选择的服务内容(它们也是文档) 所以这个应用可以采用xml文档作为建模的核心

不懂XML和建模有什么关系

如果解决问题的思路变了 对建模没有影响?

如果以文档为中心就可以忽略数据格式 各种服务之间的关系可以相对松散.只要客户能将选择的服务加到定单中就可以了. 至于加到定单中信息的内容及格式程序无需关心.

不知道我这么说对不对 ?