(上接帖子“从分析到实现，几个维度---用户功能” http://umlchina.smiling.com/group/posts/view_forum.ecgi?group_id=9986&res_message_id=1147755 中的关于模型参照系的讨论) 我只是在纸上画了八个“格子”，大家就急着把自己头脑里的东西往格子里装，装不进去，就更加迷惑了。看来必须讨论“格子”里的东西了。 参照系的作用就是“格子”，我们不要把它理解得太玄，它既不是模型，也不是视图，就是8个“抽屉”（啊，比“格子”形象多了），并且每个“抽屉”上写着，这个“抽屉”里面应该放什么模型，那个“抽屉”应该放什么模型，仅此而已。所有的模型，有这8个“抽屉”就够装的了。 在往“抽屉”里放模型之前，我们再回顾一下有哪些“抽屉”。 在我列出我认为模型空间的最重要的三个维后，我给出了8个子空间的列表，他们就是这8个“抽屉”： 1.在组织外部描述组织业务的现象模型； 2.在组织内部描述组织业务的现象模型； 3.在组织外部描述组织业务的本质模型； 4.在组织内部描述组织业务的本质模型； 5.在软件外部描述系统过程的现象模型； 6.在软件内部描述系统过程的现象模型； 7.在软件外部描述系统过程的本质模型； 8.在软件内部描述系统过程的本质模型； 随后，我要一个抽屉一个抽屉打开，把应该装在里面的东西展现给大家检阅，也许有的东西是我们以前很熟悉的，有的是不太熟悉的，没有关系。如果你理解了每个抽屉的用处，也可以往抽屉里扔你认为应该属于这个抽屉的东西。
您的论述我想解决了很多人的困惑：既然有了视图，为什么还要有参照系呢 原来不是一回事，每个抽屉中的模型都是完整的说明了整个问题。都有 一组视图来描述它 各个抽屉中的模型之间的关系您的图里已经说明了，是否应该说明真正的建模 过程不一定要装满每个抽屉，关键是认识到8个抽屉的存在。没有建模，并不说明模型不存在，而是没必要将其计入文档而乙 这样讲有什么问题吗
请牢记，放在这个抽屉里放的东西必须满足以下三个条件： 1.是站在业务组织外部看到的。 2.是描述组织业务过程的。 3.是表面看到的。 不满足这三条的东西请千万不要往里放，别忘了，后面还有7个抽屉，他们也许更加适合放在后面7个抽屉中的某个中。 接受Frankwoo的意见，我用一个例子讲解后续内容。 民以食为天，我们就以酒楼为例吧， 站在酒楼外面，看酒楼的业务过程，只看表面现象，看看能看到什么？ 阿哈，吉大有个“东北人”酒楼，提供正宗的东北菜，东北老乡可爱去过瘾了。 哦，附近还有一家“川包子”呀，最近新装修了，说是川包子店，其实更受欢迎的是四川、湖南老乡都爱吃的四川小菜，经济实惠，美味可口呢！ 什么？你是内蒙的哥们，好啊，再往海边去点，那有个“大草原”火锅城，肥牛和涮羊肉都不错。 好了，不要流口水了，我们现在的任务是说明，这叫什么模型。 当然是业务用例模型了。 东北老乡是主角，他们享受东北菜馆的大鱼大肉服务。 四川湖南老乡是主角，他们享受四川菜馆的麻辣小吃服务。 内蒙老乡是主角，他们享受内蒙菜馆的火锅服务。 这里， 被研究的对象是“东北菜馆”、“四川菜馆”和“内蒙菜馆”这三类企业，是这些企业哦，不是“计算机餐饮系统”哦。这就是所谓研究对象是“组织”。 这里， 我们是站在菜馆的“外部”观察菜馆的表现，我们没有去探究他们是如何做出各种菜色来的。这就是“外部”，我们只看到他们提供的服务项目，没看到他们怎么提供服务，“怎么”的意思就是：这个服务内部是谁提供的，谁招揽食客，谁写菜单，谁掌厨，谁收账。暂且不管。反正服务项目已经列出，进了这道门，还怕没机会宰你？这就是用例驱动。 这里， 我们看到的是“表面”的现象，“东北人”是一家“东北菜馆”类型的，“川包子”是"四川菜馆"类型的，“大草原”是“蒙古菜馆”类型的。各有特色，各有主顾。这里的“表面”打上引号，是因为也不纯粹是表面，因为我们已经看到了"XXX类型菜馆"，已经有一个小小的抽象了。更加抽象的说法，我想应该放在第三个抽屉中去。 好了，点到了，更多的例子请读者列举，列出来需要我点评的，我一定点评。也欢迎大家点评我。
你的项目也许用不到所有这8个抽屉，但如果你的项目干系人如果不知道这8个抽屉的存在，他们会怎么样？ 有可能乱说，把本应放在不同抽屉中内容写在一个模型中，然后随意乱丢。 有可能乱放，就算他们没有把内容搞混，他们还有可能把本应放在这个抽屉的模型，放到那个抽屉中。 有可能乱争，就算所有的模型都正好放到了正确的抽屉中，但交流的时候，你说这个抽屉里的模型，他脑子里想的是另一个抽屉里的模型，于是争论，折衷，反而破坏模型的完整性。 以上三乱，难道不是普遍的，令人震惊的失误吗？ 原因其实如此简单，他们只是没有准备好8个抽屉。
尽管我不想罗索，还是要再重复强调一下（XX体育界说员语录：也许有的观众刚刚打开电视机...），请牢记，放在这个抽屉里放的东西必须满足以下三个条件： 1.是站在业务组织内部看到的。 2.是描述组织业务过程的。 3.是表面看到的。 和第一个抽屉的说明只改了一个字，把"站在业务组织外..."改成了“站在业务组织内...”。站在酒楼外面我们可以一次看几个酒楼，现在我们只能选择先进一家酒楼看看了。 就选“东北人”吧。 进“东北人”看什么？不是看上酸菜的“菜花”，而是东北菜馆的内部模型。 这个模型当然是“业务对象模型”，进去时，可千万不要说术语，说是进去“找对象”——虽然我们就是进去“找对象”，否则，门口大哥会揍你——他以为你把这当哪嘎达了！ 我们为什么要进去找对象？是什么“驱动”我们进去找对象？ 对了，是第一个抽屉中站在外面看到的那个用例“驱动”我们进去找对象的，我们想知道，到底“东北人”是怎么做出那美味醇香的东北菜的。 里面的就不细说了，前面也提到了，无非是谁带你上楼入席，谁帮你点菜，谁上菜之类。对了，说到上菜，“东北人”在上一道鱼的时候可吓人了，一下子附近的服务员会呼啦跑过来，围住你的桌子，齐声高唱：“.....年年有余，日子过的贼棒贼棒贼贼棒！”。好不热闹，你吃了美味，还听了中听的祝词，心里可美了——下次你准还会来挨宰。 里面这一大堆什么你干什么，他干什么，大伙一起干什么，先干什么，后干什么等等，要建出模型来，可真有些意思——不信，改明我用UML写篇东北人酒楼内见闻的小说给你瞧瞧。 记得哦，我们现在不是在谈论“计算机餐饮管理系统”内部的信息流哦！我们还在谈“企业”哦。 谁来写“川包子”和“大草原”的内部业务对象模型啊？
川包子经营一直不错，门面虽小，但服务员工穿戴整齐，菜品除传统的夫妻肺片 之类，还经常出新。原来有个爱捉么的大师傅。但近来旁边多了一个川妹子店，经理决定，每天退出一个特价菜，低于成本出售
放在这个抽屉的东西不太被我们熟悉，其实又很重要。 更多的不是UML形式的模型，而是一个 Word文档或企业的一些经营理念和方针这类的文件。 在RUP介绍的工件中，最应该放在这个抽屉里的东西，也许是“业务前景”文档和企业的高层业务用例。 这些模型，在一定范围内是“与企业无关”的。也就是同类的企业的从外部看到的本质模型是相同的。 继续用前面的例子来说，不管是“东北人”、“川包子”还是“大草原”，他们从外部看到的本质模型，就是一个提餐饮服务的企业。 “食客”这种主角，驱动“餐饮服务”用例的执行。除了得到“吃饱喝足”的享受之外，现代的餐饮服务，也许能带来更多的“附加值”。如何充分挖掘这些附加值，成了各大酒楼提升竞争力的有力手段。 例如，“东北人”的“齐声道贺”用例在本质上就是“祝愿客户”用例，带来的是通过听觉而享受到的“虚荣”。当然，“川包子”也可以有自己形式的“祝愿客户”用例,这要取决于“川包子”的老板是否认识到客户愉悦需求这样的本质层面上来。估计不通过外在的本质的客户需求的分析，很难让“川包子老板”认识到。这种分析是否必须用uml表达，另当别论，至少，uml是可以通过核心的业务用例来表达的。
我们已经知道，在第二个抽屉里放的是业务对象模型，是站在组织内部描述组织向外提供服务的内部实现细节。这个抽屉也是从组织内部描述业务过程，应该也是业务对象模型，这个业务对象模型和第二个抽屉里放的有什么不同呢？ 我们可以从第一个抽屉里的实际业务用例模型和第三个抽屉里的抽象业务用例模型对比发现的不同来推断： 放在第四个抽屉里的业务对象模型一定也是一个“和具体组织无关”的一组用例的实现。但它当然要关于某一类型的业务组织。从表面的理解，就是关于指定领域的内部业务实现的模型，我就把它理解为是：领域模型。 “领域模型就是抽象的业务对象模型”，不知道这个结论是否准确，我一直希望有博士来指导。我对我把它扔到第四个抽屉里的做法，还不太敢确定。 还是用餐饮业的例子来说明吧。 假设我们在第三个抽屉里放了一个有以下两个用例的业务用例模型： 1.主角：食客，用例1：提供餐饮； 2.主角：食客，用例2：点菜； 其中，用例1使用用例2。当然，还有其他业务用例，不一一列举了。 那么，第四个抽屉就应该放关于这两个核心业务用例的抽象实现的对象模型。 涉及到的类可能有： 1.酒楼员工 1.1 咨客 1.2 写单员 1.3 上菜员； 1.4 收银员； 1.5 助兴员； 1.6 经理； 1.7 厨师； 1.8 工人； 1.9 会计/出纳； 1.10 总经理 2.酒楼场地 3.厨房设备 4.用餐家具/用餐餐具 5.点菜菜谱/菜单/账单 6.菜色点心 7.酒水饮料 关于用例“点菜”的实现过程如下： 当客人在座位座稳，示意需要点菜的时候... 写单员.手拿点菜菜谱； 写单员.走近客人； 写单员.出示点菜菜谱； 点菜菜谱.翻动； 点菜菜谱.显示菜色名称/价格； 当客人询问菜色特点的时候... 写单员.介绍菜色特点； 写单员.询问客人口味； 写单员.推荐菜色； 当客人同意选定某项菜色的时候... 写单员.拿出点菜菜单； 写单员.迅速写下选定菜色名称； 点菜菜单.记下所选菜色名称； 点菜菜单.显示所选菜色名称； .... 以上可以说是食客发出点菜请求，写单员和菜谱，菜单相互协作满足点菜请求的内部实现过程。在这个过程中，每个类都必须有自己的行为能力（方法），也必须表现出一些可视的形象（属性），这些类，运用他们的方法和属性，响应一件件事件，完成一个个活动。最终实现用例的目标。 关键是，上述的过程与具体是那家酒楼无关，也就是说，不管是哪家酒楼，都无非是一群这样的人和物，有这样的能力和属性，响应这样的事件，按这样的关系协作，满足食客这样的服务要求。虽然不同的酒楼具体的实现办法不同，但本质就是这么一回事。 这就是所谓本质的对象模型。
楼主很有想法。
我们为什么要做出这前四个抽屉中的关于业务组织的模型？ 我们仅仅是为了把他们清晰的表达出来吗？ 仅仅是为了让IS的开发人员“熟悉业务”吗？ 不是，远远不是。 把它们清晰地表达出来是为了能够清晰地评估业务组织的运作成本和效益。 评估业务组织活动的成本和效益是为了发现问题和机会。 发现了问题和机会就会驱动我们去解决问题和抓住机会。 为了解决问题和抓住机会，就会让我们利用一切手段想更好的方法，做更好的工具来工作。当然，自然就包括IT工具。 从业务模型到IS模型中间出现了一道鸿沟，就是基于业务模型的组织运作成本/效益的评估。这需要管理人员和财务人员的积极参与。 比如，还是这个餐饮业的例子。 我们分析了餐饮业的业务用例模型和业务对象模型，清楚地描述了发生在一个酒楼中的每一种活动和这些活动的目的。在这些活动中消耗的人力物力和时间变得更加容易统计，并能看清它们被消耗的过程和原因，他们的消耗是否合理。也更容易让酒楼老板和其他员工发现改进的机会，想到解决问题的办法。 例如，酒楼点菜的效率太低，送菜经常送错桌子，记账太慢，想知道什么菜色更受欢迎，想知道什么菜色利润更高等等。这些问题和机会在清晰的业务模型下会显得有根有据。 这些根据，正好是驱动酒楼老板投资开发酒楼管理系统的动力，于是，一个“计算机餐饮管理系统”呼之欲出。
CSDN上有个帖子：http://expert.csdn.net/Expert/topic/2253/2253840.xml?temp=.6340601 里面讲了7个模型： 应用架构：从使用视角看架构。系统实现的功能，以及各功能模块间的关系。 业务架构：业务模型，流程模型，组织模型等企业本身 信息架构：企业的信息系统规划 体系架构：三层或N层体系 系统架构: 软硬件部署 安全架构：安全了 软件架构：此部分主要描述各个应用软件间的关系结构，如数据库，was，portal等 感觉跟这个帖子很像呢。不过已经很久没有下文了……
我后面还有很多东东倒，现在只是开个头，搭个架子。 在这个架子中，将填充大量的实例，我肯定这对把程序员引向设计师发展方面能起到一些积极作用。因为我本人就是这样走过来的。 请多关注，多宣传，大家的关注是我唯一需要的坚持下去的动力。
从这个抽屉开始，我们改换了研究的对象，我们从业务组织换到了软件系统。 而连接这个转换的桥梁就是通过业务活动的成本/效益/竞争力分析得到的业务组织的问题和机会列表。 所以，当人问“什么时候不需要业务建模？”这个问题的时候，我知道，也许是他对业务模型应该为系统模型做的工作不明确。如果你的客户已经有一张明确的问题和机会的列表，并深信这是提高他的企业组织竞争力的关键，那么为IS建模去做业务分析和设计的理由就少了一半。 进行业务建模的另一半理由在技术层面，是FrankWoo所说的“IS和BS接轨部分”，如果这部分还是黑箱，那么，就很容易产生“孤立的IS”,如果现有的IS和待建的IS有成为“孤立的IS”的风险，这个风险对组织比较严重的话，就多半要进行BS建模。 这第五个抽屉里的模型和第一个抽屉里的模型有一比。这是我见了最多的概念混淆的环节。很多系统分析员总是把这两个抽屉里的模型混在一起，让你不知道他说的是企业组织还是软件系统。比如，在同一个用例模型中，既有纯粹人进行的活动，又有纯粹计算机进行的活动，还有二者混合的活动。我们并不能说这种模型是错误的，因为它确实在某种程度上反映了现实情况——人和计算机系统密不可分。 但不要忘记，我们做计算机系统的模型的主要任务之一是为了确定信息系统的范围边界，而不是为了证明人和计算机系统的不可分割性。相反，这种不可分割性应该在“问题-解决方案”和“请求-服务”这两个层面的接口映射中清晰地表达出来。 系统用例模型正好就是为了清晰地描述和反映这一接口的方法。系统用例模型的主角来自业务场景中的人或待开发系统以外的系统，也就是业务用例模型的主角或业务对象模型中的角色或对象。系统用例模型的用例，来自业务活动中可以由计算机完成的部分。 继续用餐饮业的例子讨论。 假设经过业务分析我们发现目前点菜这个环节是一个容易出错，而且效率较低，并导致后续工作被动的瓶颈问题。因为人工填写纸质菜单到收银台汇总，当客人较多时候，菜单很多，分不清先后不说，还容易丢失，搞乱。 经过粗略的估计，由于菜单填写传递过程导致的失误引起食客投诉和不满已经占到所有的50%以上，食客花在点菜和等待出菜、结账上的时间占到了总进餐时间的20-30%，换句话说，如果在菜单填写传递过程提高50%的质量和效率，将减少25%的投诉和缩短10-15%的食客无效进餐时间。节省了无效进食时间意味着每个餐台在一个营业高峰期内可能接待多一名顾客，同时还可以大大提高客户满意度，增加回头客的概率。 象这种既解决问题又创造机会的事当然会受酒楼老板的欢迎。于是，在这个项目中，我们会在第五个抽屉中开发一个“电子点菜系统”的用例模型。 待续...
作为一个企业提供一种产品或服务，获得利润，在竞争中取胜并获得发展 这是很本质的。 因此竞争企业和客户群是否都应考虑为组织外部角色 川包子需要有一个信息入口了解对手的动向 有一个决策机制对对手的经营做出反应 整个市场行情与环境也是影响其经营的因素 例如肉类价格大涨，，，， 这些东西也属于内外部边界上的关系，好像是从内部考虑的，不知改不改放到这里
软件与组织的边界，关于这个问题引发了很多有价值的讨论。 我也谈谈我的浅见 1、为组织活动自动化的部分 2、为组织活动的信息流系统 3、对企业的运营与管理融为一体 1）、为信息化低级阶段 2）、为高级阶段 3）、为最高阶段 关键在于软件能产生价值，国内信息化在这方面的误区可谓不少，浪费也很大。我觉得可能每个阶段都是不可跨越的。 点菜系统应属于1。为2,3做准备 这种认识也影响了软件的设计
持续关注中... 很精美的系统理论，就是自己现在一下子没灵感了，先看看再说
这一生存环境中有各种各样的要素，从不同的主角立场出发会看到不同的过程需求。当考虑多主角立场的时候，就能更加清楚地发现业务过程应如何按不同的目标口径分解，才能找到多主角共同的立场和各自的立场，从而为评估未来系统特性的优先级打下伏笔。 比如“东北人”酒楼，在他的全局的生存环境中，我们不仅仅能看到“食客”这一类主角，还有投资人，工商所，卫生检疫部门，税务部门，场地房东，菜市场....等等等等。我们是否需要在一个业务模型中把所有这些主角的需求全部列出？一般来说不必要。这要看项目的具体目标是什么，企业生存和竞争力的首要因素是什么，企业的可能做出的改进是什么等。
看到老兄的高论，觉得确实很好。这个系统是否是比较完整的系统？ 我想这个不是问题，因为开发本身并不是科学，不存在一个对应的 被证明的唯一的系统。所以系统的可用性成为一个很主要的标准。 我想对于开发可以考虑的方面，我想应该很有用，可以让开发人员对 遇到的问题确定问题的领域，比如用户的某些用例隐含着对其本质的 一个更深的需求，比如使用电子菜单是为了提高速度，但是其点菜的 流程就限制了这个速度的提高（或者速度说对流程更敏感），开发人员 就可以确定这个问题的抽屉，避免吃力不讨好（使用自动化来解决这个 问题）。 只是这些问题一般不会由系统分析员来完成，而最可能由内部管理人员 或者咨询公司来完成，所以系统分析员可能不会看到这些问题，由此 对某些抽屉不感兴趣，开发员就更加的对某些抽屉不感兴趣了。 当然，最好我们可以提供8个抽屉的服务，这样我们这个行业将变的很大， 各位兄弟也都有口好饭吃。
如果不知道有这8个抽屉，反而更有机会让不合适的人做不合适的事。 成就一个软件项目，必定有关于项目目标的一个最少需要的信息集合，而且不同的信息，必定要最佳的提供和处理人。这8个抽屉只是对这些信息最顶层的划分而已。 这不是一个谁给谁饭吃的问题，是没有同桌的吃饭人，你可能也吃不香的问题。
上个礼拜其实已经把第五个抽屉的下篇写好了，可是在提交前一个误操作，让我写下的2000多字不翼而飞。实在让我沮丧，灵感一下没了。 我想，老是我一个人写，实在也没多大意思。如果大家还想继续下去，拜托做一件事：下次您下馆子的时候，问问上来给你点菜的，如果他们老板决定要做一个电子点菜系统，他会建议在这个系统中做些什么事？ 或者你和某个酒楼老板很熟悉，你可以说你的一个朋友正想投资开发一个电子点菜系统，把我的业务分析讲给他听，听听他有什么看法。 回来大家把得到的信息都如实跟在本贴下。也许会再次调动我的灵感。
服务员(真的) 1.让我及时根据客户的口味(大类：淡/重，小类：麻/辣/酸/鲜/甜等)特点找到合适的推荐菜，而不是等用户想自己应该点什么菜，这样我的点菜额会提高，用户满意率也会较高。 2.最好能提醒我老用户上次点的是哪些菜和酒水，这样我的客户会更高兴。(有小费哦) 老板(自已想象的) 1.根据点菜时间，菜的配料，得出统计信息，用以优化采购计划，尽可能减少浪费 2.识别用户，并能记住所点的菜，对回头客有针对性地给以一定的折扣优惠。
1. 第五个抽屉建立在第一和第二个抽屉的分析基础上。 2. 第五个抽屉可以对应为RUP中的用于验收的测试用例 3. 第五个抽屉有助于将开发人员的精力集中于实现最终用户有价值的特性上，一定程度上避免出现需求蔓延的现象 4. 第五个抽屉要尽量迎合用户[我们的上帝]，以减少用户的学习时间。(而第六个抽屉应尽量的合理化原流程中不合理之外，说服投资人并引导操作员[我们的助手]适应优化后的流程，体会优化所带来的好处。)
其实，我上次写过又丢失的第五个抽屉中的点菜系统的模型是写错了，写了应该放在第七个抽屉——在软件外部描述系统过程的本质的模型中的内容。在那次写作中，我写完了才发现，自己写了一个通用的点菜系统的基本特性的实现方案。而这第五个抽屉，应该是一个与客户有关的一个“个性化”的方案，这才能显出是“现象”层的模型。 我的这次失误体现了这样一个规律：做通用型的产品，第七个抽屉的内容是不能省略的；而做定制的产品，在初级阶段不能省略第五个抽屉的内容，如果有了第七个抽屉的内容，则能大大降低定制的成本。 我在考虑点菜系统的第五个抽屉的内容时遇到的困难，表现出我目前缺乏真实的客户，缺乏深入的生活体验，挖掘不到个性化的需求。所作的模型自然就只能基于空想，而空想的东西，自然就更加容易泛泛而谈，也就更加抽象而接近本质。 我现在还是写不出这第五个抽屉中的具体内容。还得请大家继续帮忙。 先谢过Joekazz
