案例和问题征集启事

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

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

这本书是写UML的，但绝不仅是简单介绍或手册式的书籍。更多的，我希望告诉大家UML背后的思想，如何用UML解决现实的问题，如何用面向对象的思想完成从需求到分析设计到实现的整个过程。在本书中将引用大量的实例和实例分析。特在这里向朋友们征集案例以及你们所关心的，困惑的问题。如果这些案例和问题在书中引用了，要是愿意，本书会为你们挂名。其次，如果某位朋友提供了很好的，较大的典型案例，成为本书的主章节的话，本书出版后我将送一本书给这位朋友。

为了符合本书的主题，您所提供的案例和问题应当：

• 不违反知识产权
• 不泄露商业机密
• 是面向对象分析设计相关的
• 是与软件工程相关的
• 是与UML和RUP相关的
• 是与需求工程相关的
• 是实际工作中常见的

恭喜COFFEEWOO走上与我同样的道路

就针对你的这句话,给个好建议:
"是与UML和RUP相关的"
请在书里解释为什么是UML和RUP相关的,为什么是对象化软件过程(统一过程)而不是其他?UML和RUP有必然联系吗?

就针对你的这句话,给个好建议:
"是与UML和RUP相关的"
请在书里解释为什么是UML和RUP相关的,为什么是对象化软件过程(统一过程)而不是其他?UML和RUP有必然联系吗?

Thanks for rwyx's good suggestion!

恭喜咖啡要出书了,一定买。
真心感谢咖啡这几个月来的无私奉献。

思考：我关注的人都在出书，难道我应该去炒股票 ？？

难道出书真的成了过街老鼠 ？？？

恭喜coffeewoo要出书了。希望咖啡能在不违反出版协议的情况下在博里把分析设计的文章继续下去。

一阵没来，刚上来就看到这大好事！鞭炮伺候、鞭炮伺候！

写书就没有写博自由了，有时间限制的
不过有些东西应该是可以发布在博里的，呵呵，最好两不耽误

恭喜,恭喜啊，期待中...

现场象咖啡请教个问题啊：现在常提的三层结构，表示层、业务逻辑层没有异议，但是最下面那层，有的叫数据层有的叫数据访问层，叫数据层的把数据库当做一层，叫数据访问层的把访问数据的那层当作一层，再或者混在一起含糊的叫数据层或者数据访问层。按你的理解，下面这层到底应该是个什么含义呢？感谢感谢！

统称持久层的比较多吧
从理论上说,这一层没有什么意义的,因为它只是把数据放到硬盘上,但是从实际上看,这一层是最重要的,支撑当前业务的所有可以持久化的数据.
数据层和数据访问层的话,我觉得是这样的:
数据层:数据库,由于当前流行的是ORM,所以它想表达的是持久化数据并对象关系映射
数据访问层AO
一般来说持久层数据访问层数据层是同一个含义,都想表达数据库的一些原子操作

恭喜！！！
你的文章很易懂，而且有个很好的例子，使我受益不少，非常感谢。
不过例子好像不是很完整，也不详细，特别是业务用例到系统用例，我一直搞得不是很清楚，希望在你的书中能看到更为详尽的例子。
期待你的新书。

书里一定会把这个问题讲清楚的，这个系列文章里的确很多东西是没讲清楚的。

再次发出了“隔行如隔山”的感叹。但可以让你知道，在遥远的家乡，有一个朋友在关注着你，而且会一直关注你。

老火还是喜欢玩躲猫猫的游戏

这回你隐藏不了了！谢谢你的关注哦，不会让你失望的！！！

你好，看了你的博客，对我帮助很大。目前很多用户都是做网站方面的开发，
但是这方面的比较好的建模案例却非常少。
假设我要做一套新闻发布系统，简要描述如下：
该系统有用户：
1、浏览用户 （访问前台网页）
2、注册用户 （访问前台，有些信息需注册才能查看）
3、信息发布员（发布网站信息，注册用户经授权后可以转换为信息发布员）
4、网站总管理员（负责整个网站基本信息的设置，同时可以授权信息发布员管理发布栏目信息，设置分管理员）
5、网站分管理员（注册用户经授权后可以转换为网站分管理员，根据网站总管理员的授权来管理网站，可以将某些栏目授权给信息发布员）
对这套系统的用户关系，用例描述有很多疑惑，始终不太得要领，并且大多数的网站开发
都会涉及到这些问题，望能指导！

根据你现在的描述，实际上已经是在系统层面的讨论了，而非需求层面。所以在需求层面缺失的情况下，这些结果就成了无源之水。没有基准就没有比较，没有比较就无从说好坏和对错。
对新闻发布这样一个网站来说，要先考虑它的涉众。比如新闻的发布人，新闻的浏览人和网站管理人。从这些涉及众的角度出发，看他们对系统的要求是什么，能够得出用例。针对每个用例的分析才能导出你现在的这个结果。比如，新闻的浏览人因为有一个业务规则是说有些信息需注册才能查看，这个原因导致新闻的浏览人被泛化成注册用户和非注册用户。
需求分析和系统设计是需要有一个完整的过程的，这个过程就是涉众->主角 主角要求->业务用例 业务用例分析->系统用例 系统用例分析->用例实现（分析模型） 架构文档+分析模型->设计模型

环环相扣，相互映证，步步推导。我觉得如果是这样去做的，应不会对结果有什么疑惑的。

非常感谢版主的热心回答，我会一直支持你，祝你的大做早日出版！

非常感谢版主的热心回答，我会一直支持你，祝你的大做早日出版！

版主果然要出作品了，我早已将贵站介绍给我的学兄、学弟，希望更多的人能够从本博与即将出版的book中获益！

看了一段时间，受益很大，谢谢你的无私奉献！
如果能够在下列方面多给一些可操作的说明，更好：
用例的粒度选择不是每一个人都能够马上学会并切实应用的。但是，现在大部分从事这方面工作的同行确实需要做这方的工作，并想做好，提一个建议：
给出几种需求分析的工作模型，分别针对大、中、小型项目，说明工作模型中每一个环节必须要做的事、建议使用的工具、基本方法、结果模型、文档格式和内容。让同行先学会怎么去完成工作，然后再自己体会提高。
这几天，自己的工作比较忙，过几天，发一个中型项目的案例给你，希望对你出书有一点帮助！
预祝你成功，并希望在辛苦一下，在架构和框架方面多用一些文章，谢谢！

谢谢雪山的支持！！期待你的案例！！
另，经过这段时间的思考，我开始感觉到用例的粒度并非是粒度选择本身的问题，而是一个抽象层次选择的问题，是抽象层次决定了粒度的大小。我相信从这里入手可以解开粒度的秘密。
在我的书里将会包括这部分内容，就我自己的感觉来看，这个过程对粒度的决定是自然而然的。这里就先透点内容吧，呵呵。

一直以来,受您的博客影响很大,从中收益菲浅,也得到了你身上的很多经验,由衷的感谢您!!!不知,您能否针对各种设计模式及模式应用的场景,给大家一些启发,让大家不只是了解设计模式,而无法合理的进行应用或很盲目的应用.多谢了,您也辛苦了!

另外,您是做项目管理的,能否把您对项目管理的经验分享给大家,帮助大家一起提高呢?

另外,您是做项目管理的,能否把您对项目管理的经验分享给大家,帮助大家一起提高呢?

谢谢！很好的提议。我已经规划了关于设计模式的章节。在书中会就设计模式的应用进行一些方法上的讨论。至于项目管理，现在还没有很好的想法。等忙完现在的内容，会好好总结一下，然后在博客里写一些文章的。感谢你的关注

对于捕获了业务用例之后,可以对业务用例,逐个描述其内部是如何实现该业务用例目标的(也就是需要对业务用例场景进行描述).通过用例场景,可以得出业务实体模型.我想请问一下版主,下一步的工作应该是业务用例分析了,该如何进行业务用例分析呢?需要哪些原材料作为分析的输入呢?不知,能否举个例子呢?多谢啊!!!

对于捕获了业务用例之后,可以对业务用例,逐个描述其内部是如何实现该业务用例目标的(也就是需要对业务用例场景进行描述).通过用例场景,可以得出业务实体模型.我想请问一下版主,下一步的工作应该是业务用例分析了,该如何进行业务用例分析呢?需要哪些原材料作为分析的输入呢?不知,能否举个例子呢?多谢啊!!!

业务场景描述本身就是分析的过程啊，从业务场景中得到概念用例，业务实体，就是分析的结果。
分析的输入来自客户访谈，业务规则，业务手册，行业规范等等。其实这个过程就是需求收集的过程。

快快,我等一干涉众研墨洗笔,就等您的大作出世了.
PS:预定时间是?

预定时间是明年三月正式出版....时间好长啊！
呵呵，不过要谅解，一本书几十万字...不是那么容易写的吧？精工出细活儿么。
我会跟出版社协商，写书过程中的一部分章节可以提前发表在blog上的：）

现在的关于这方面的书都是以一些管理和业务有关的例子来说明，建议咖啡兄收录一些自动化设备软件的例子，为从事这方面开发的人员提供一个有益的参考，我想会成为这本书的一大特色的。

正有此意！！！

菜鸟，看不懂，路过，顺便帮顶

我主导开发过

国际货运软件
国际船舶代理软件
电子订舱
EDI数据交换
外贸管理软件

这些案例有需要可以联系我，我可以以任意角色参与帮助
联系MAIL：q88992723[at]gmail.com

太感谢了！在我构思过程中如果觉得有哪方面的案例需要，一定找你！呵呵！
我很少用QQ了，你有MSN吗？不想公开的话发邮件给我就行 我的邮件和MSN都是coffeewoo@263.net

首先感谢版主的辛苦与无私奉献精神！在此有个问题就是看了不少书中，对于uml的一些概念，比如翻译等有时有不同的说法，有时甚至是矛盾的。还有就是在做uml图的时候，同样的图，比如用例之间的包含关系，该用虚线还是实现，用三角箭头还是右箭头等问题，一本书上是这样说的，另外一本数就是另外一个说法。希望版主能解答一下，或是用一个专题的形式！对于这些概念是否应该从uml三位作者出的书中来找答案。提前谢谢版主了！

如果要寻求标准，那我的建议是阅读OMG授权出版的原版读物，以及Rational的联机文档。凡是翻译过来的，就会有不同叫法...有一本讲RUP的书，原版就是三位UML老大写的，结果中文译本中usecase被翻译为用况；而Rational的联机文档中usecase又被翻译为用例。哪一个是标准？我也不知道。
至于实线还是虚线，同样的association，Rose中是带有箭头的，Visio中是不带的，PD里也是不带的...哪个是标准？从规范上来说不带箭头才是正确的，但，UML的三位老大有两个就在Rational，Booch至今还在，不至于视而不见吧？俺也糊涂了。
窃以为，如果可能的情况下，尽量使用英文原文以避免用词歧义。若主要读者是中文读者，那么在项目中维护一个词汇表或图例来解决用例还是用况，虚线还是实现的问题我觉得是比较可行的方法。大家都搞明白什么是包含关系比搞明白包含是用实线还是虚线更有意义。你觉得呢？

谢谢楼主的细心解答！看来标准还是不太标准阿！

其实要认真研究还是能得到标准的，以OMG发布的文档为准就行。只是我觉得比研究这个更重要的掌握方法，不太愿意在这个方面花太多精力。呵呵，有点治学不严谨的嫌疑。

什么时候可以见到书？在市场上，期待中...

预定时间是明年三月正式出版....时间好长啊！
呵呵，不过要谅解，一本书几十万字...不是那么容易写的吧？精工出细活儿么。
我会跟出版社协商，写书过程中的一部分章节可以提前发表在blog上的

时间太长了，我等不急了...

1. 公司产品经理把需求整理好以后，提交给我（项目经理）
2. 根据需求，画用例图（直接画系统用例图）
步骤：a. 找出有哪些用户，即执行者
b. 找出用户要做的事情，即useCase
c. 画出主要的用例场景（活动图）
d. 画出复杂用例的流程图：时序图
e. 根据用例，找出关系到的实体，在这里直接用powerdesigner来画ER图了
（之所以这样，是因为刚进公司的时候，就要求要设计数据库）
f. 编写归档用例。对每一个用例进行细化，描述每一个步骤及流程、扩展步骤、
异常流程、业务规则及用例涉及到的实体。如果有复杂流程的，将时序图附上。
g. 将一些系统间交互的时序图附在用例文档中
h. 在写归档用例的时候，发现实体设计方面的问题，则进行修正。
i. 根据ER图中的逻辑视图生成物理视图，再生成对应数据库的sql脚本，创建数据库表
j. 在这些事情完成以后，就算一个模块完成了，直接提交给程序员进行coding，并在JIRA
中加入任务安排
k. 继续下一个模块的设计，就此迭代，直到所有的模块完成

3.在以上的过程中，还要加入项目管理的事务。跟踪项目进度，组员及组间协调等。
需求如果有问题，需要进行沟通

几点问题，
1. 业务模型设计目前还没有做，做的是直接画ER图,如果通过业务建模，分析出实体后，
的流程还有一些疑问，由模型设计导出数据库实体的流程还没有尝试过
2. 边界类，控制类，实体类，是否有必要，不是直接有用例分析及实体建模就可以了。
3. 邻域模型的设计，是只包括（实体建模）还是包括(边界类，控制类，实体类)
4. 用例分析与传统数据库表设计结合的方式，是否会引起一些模型设计上的一些问题，
导致类编写处理时复杂化，数据查询处理复杂化
5. 没有业务用例，直接画系统用例了。

从流程上来看没什么太大的问题，至少有一个固定的过程

很多公司都会采用这种办法。应该是成本和过程平衡的结果。这种办法不至于使过程失控，也不至于花费太管理成本。

从商业的角度无可厚非，如果抛开商业不谈，只说技术层面，那这个过程还是欠缺了些东西的。关键就是没有机会维护一个stable的架构。现在的设计抽象层次显得低了一点。如果从底向上的去抽象架构，不是不可以，只是这就象先盖房子后搭梁，有点修修补补的嫌疑。而且最终一个好的设计会服从已经存在的大量看上去不优美的代码。

老实说这种以数据库设计为中心的开发模式基本上是与面向对象无缘的。但绝大多数商业软件倒也的确就是以数据为中心的应用模式，采用以数据库设计为中心的方法也许也是正确的选择。商业--技术，有时不是一体的。所以部分采用某些技术，某些过程也说得过去，做生意嘛。以技术为导向的公司估计生存也会有问题。

祝coffee老兄，五一节日快乐！

两个字:恭喜!

楼主什么时候出书啊

请问问题比较简单还需要进行业务建模吗？直接进行建立系统用例模型可以吗？ 业务建模是否包括用例图、用例文档、活动图等，需要顺序图或者写作图等等？

when will your book come to market? I eager for it.

when will your book come to market? I eager for it.

顺序图用于描述对象之间如何交互实现用例，那它用于分析还是设计？还是分析和设计都可以用，只是细化程度不同而已？

你好，我打开你用web publisher做的例子总是闪个不停，无法阅读，怎么回事？

在图书管理系统中，“借书”这个系统用例中，读者将借书证和书交给 管理员实现借书，我觉得“管理员“应该是primary actor,但是，好多人认为是“读者”。请问您的意见？