近日有一些朋友问到一些关于业务实体获取的问题。在新书中有关于业务实体内容的章节，正好很久没有新的内容发布了，因此把它帖出来，希望能解决这些疑问。

业务实体是类（class）的一种版型，特别用于在业务建模阶段建立领域模型。业务实体是业务模型中非常重要的一个因素，它为问题领域中的关键概念建立概念化的理解，是人们认识问题领域的重要手段。如果说参与者和用例描述了我们在这个问题领域中达到什么样的目标，那么业务实体就描述了我们使用什么来达到业务目标以及通过什么来记录这个业务目标。实际上，业务实体抽象出了问题领域内核心和关键的概念，如果把问题领域比喻成一幢大楼的话，业务实体就是构成这幢大楼的砖瓦和石头。

很久没能上网，呵呵，大伙儿估计俺是消失了吧？还真差不多就是消失了。至少现在MSN还是不能用……

再忍一忍，就快过去了……

今天上来发表新书的一部分，关于参与者的基本概念。

亲爱的关注本博的朋友，最近一段时间俺都忙于写书，没有时间更新博客，让许多朋友久等了。

由于书的写作和出版需要较长的时间，预计出版时间已经排到了明年的三月份。俺曾经答应过一些朋友，在书没有出版之前，在这段时间内将书的一部分内容先在博客上发表，一方面为了感谢他们对俺一直的支持，另一方面也为书做点宣传，毕竟要是销路不好的话浪费这一年的辛苦倒也罢了，要是还要自己贴钱那就真是赔了夫人又折兵了^_^

目前书已经完成了三分之一左右，从今天开始，每隔一段时间都会发表书中内容的一部分。当然，出于可以理解的原因，请原谅俺不能发表完整的章节，也不能披露过多的内容，那里还有一纸合同呢……

本书的英名定为《Think in UML》，这是因为笔者在书中写了大量的自己的思考和经验，与之前的OO之路系列相似。中文名称等过一段时间再行披露，当然出版时会以中文名称出版^_^

今天这贴算是一个公告吧，顺带把书中《写给读者的话》先发表出来。下一帖再发表实际的内容。谢谢朋友们的支持哦！！

亲爱的朋友们，感谢你们一直以来对本博的支持和喜爱。由于你们的支持，我这些写在博客里的随意的技术文章引起了出版社的注意，前段时间与出版社进行了一些沟通，终于决定将自己多年的经验好好沉淀一下，完整而全面的写一本书。这本书与博客的初衷一致，将站在广大分析设计爱好者的角度，将我的经验传达给你们。写你们关心的问题，为你们最困惑的地方给予指点，以完的整软件过程为纲，以实际案例为点。希望这本书能够成为爱好面象对向方法，喜欢用例分析技术，想成为设计师甚至架构师的朋友们的案头书籍和最佳伙伴。

这本书是为你们而写的，为了更好的符合你们的需求，特在这里向广大朋友征集案例和问题。(更多内容请点击标题...)

这是最近做的一个PPT文件，对用例分析方法做了一个总结。应该对朋友们理解用例分析有所帮助。

软件架构是一种思想，一个系统蓝图，对软件结构组成的规划和职责设定。而软件框架是一个实现，一个半成品，是针对一个特定问题的解决方案和辅助工具。

 查看全文

草图代表了需求的实现，是一个细节的表露。接下来的优化的调整，就以此为基础。主要的输入：草图，系统架构，业务规则，补充用例规约，系统原型。主要的输出：调整后的分析模型，子系统，组件视图和部署视图（针对分布式应用而言）。

 查看全文

分析模型是系统的高层抽象，是高于实现语言和实现方式的。因此在做分析模型过程中，要跳出固有的java思维，C++思维，同时也暂时不要考虑设计模式的应用，而专心的，用OO思维把四个分析类的职责和交互，以及它们之间的关系定义清楚。如果说用例分析大部分情况下是程式化的（笔者正希望它是程式化的），那么你会发现，分析模型大部分工作也是程式化的。

 查看全文

一位名叫Midhael Yan的朋友给我发来一封信，信中谈到这样一个问题。我觉得很有代表性，因此公开发布到BLOG上。这位朋友的问题是这样的：

一个租房中介准备提供一个网上中介服务系统，主要包括以下服务：
给求租者发布求租信息，寻找房屋信息
给出租者注册一个店面，在小店里发布出租房信息，也支持寻找求租信息
使用该服务必须注册一个用户
对房屋有收藏和评论的需要
我和几个朋友初步探讨了一下，在业务建模阶段出现了争执
我的分析：
一个求租者业务角色
一个出租者业务角色
发布求租信息业务用例
找房屋信息业务用例
注册店面业务用例
发布出租房屋信息业务用例
注册用户业务用例
朋友的分析：
一个求租者业务角色
一个出租者业务角色
发布信息业务用例（注册店面业务用例也被合并进来了）
查询信息业务用例
注册用户业务用例
另外一个朋友的分析更简单：
客人业务角色
发布信息业务用例
查询信息业务用例
请您给出您的见解，谢谢！

分析模型是高层次的系统视图，在语义上，分析类不代表最终的实现。它是计算机系统元素的高层抽象。

笔者认为分析模型正是OO设计的核心，而设计类只是OO的实现手段。

分析模型是MVC模式的经典应用。对比分析类的名称，MVC模式，读者应该能够发现分析类在OO和商业目标中精妙的对应关系：人，事，物，规则--actor,boundary,engity,control。这就是为什么笔者说分析模型是OO设计的核心。

为了让我们的需求更完美，这一篇所要做的工作也是必不可少的。这一篇将要讨论到的内容包括：用例补充规约，系统原型，以及需求规格说明书

 查看全文

上一篇我们图形化建模的部分基本上完成了，得到了业务用例模型， 这帮助我们获得了功能性需求。得到了业务场景和用例场景，这帮助我们获得了面对业务的执行过程描述和概念（逻辑）模型，让我们知道业务将如何的运作。得到了用例实现以及领域模型，这帮助我们得知哪些业务用例将在系统中实现，对应这些用例，哪些业务实体将会被包括进来，以及它们如何帮助业务实现。上一篇我们也留下了悬念，对于业务执行过程来说，除了以上的成果，我们还需要知道业务规则，以及业务实例的属性。即我们要如何做以及做什么。这一篇就来讨论这些内容。

上一篇确定了业务用例，以及业务场景。该场景只描述了业务框架，接下来要对业务用例进行场景分析。用例场景分析要用到三种视图，业务用例实现视图、业务用例场景、业务实体模型（领域模型），每个业务用例还应当写一份用例文档，也称为用例规约（UseCase Specification）。若有非功能性需求，例如性能要求，吞吐量要求等，还应当写一份补充用例规约。

 查看全文

用户、业务用例以及业务场景。这三项工作成果已经形成了基本的需求框架，并圈定了业务范围。就笔者的工作习惯而言，在得到这三个成果后，就会暂停调研，而通过评审会，研讨会等形式充分论证这些成果的正确性和完备性。求得业务专家，用户代表，开发方，项目经理等各方的一致认可，将其作为第一份基线。

 查看全文

我发现，在OO和UML几乎一统天下的今天，仍有很多系统分析员对OO和UML一知半解，甚至包括很多已经使用了很久UML的系统分析员。

于是打算写一个系列文章，将多年来的工作经验做一个总结。对初学者起个启蒙作用，也希望抛砖引喻，与各路大虾共同探讨，共同提高。

这个系列文章将以我对OO和系统分析的理解为主，从UML基础开始，阐述面向对象的需求分析方法，过程，并以RUP为例，阐述如何将OO过程与软件过程有机结合在一起，做一个真正OO应用。

好了，今天是第一篇。想得很远，真希望我能坚持下去，呵呵