最近评论回复汇总

 

Re: 《大�?Thinking in UML》读者专用反馈、答疑、讨论贴 cej19820202 | 5/16/2009 10:19:44 PM | 删除 回复 | 选择

大哥 我的光盘丢了 怎么�?d=0.21383061977772044

re:cej19820202 5/19/2009 12:25:32 PM | 删除

有网友在CSDN上传了随书光盘的下载，你去下一个吧

Re: OO系统分析员之路--用例分析系列（1）--什么是用例 rosered2 | 5/16/2009 3:27:00 PM | 删除 回复 | 选择

怎么感觉你的文件很多是抄袭过来的啊

re:rosered2 5/19/2009 12:26:21 PM | 删除

抄袭是很严肃的指控哦，请贴出我所抄袭的原文出处！

Re: OO系统分析员之路--用例分析系列（1）--什么是用例 JimFire | 5/15/2009 12:24:53 AM | 删除 回复 | 选择

郁闷的是我在读研究生的时候，我读你的文章发现，我在思想上已经OO了，但是我的导师还没有，我无法说服他（此人比较固执）。所以，那几年很郁闷。

re:JimFire 5/19/2009 12:29:24 PM | 删除

很正常的，通常越是经验丰富的程序员有时越难改变。因为面向对象不是一门技术，而是一种思维模式，要改变一种思维模式是很难的。不过师傅领进门，修行靠个人，相信你从你导师那里也能学到很多东西的。很多情况下面向过程也是很好的思维模式。

Re: OO系统分析员之路--用例分析系列（8）--如何编写一份完整的UML需求规格说明书[整理重发] FeeLang | 5/14/2009 11:14:59 PM | 删除 回复 | 选择

学习。。。3QU博主

Re: OO系统分析员之�?-用例分析系列�?�?-如何编写一份完整的UML需求规格说明书[整理重发] anmy123 | 5/14/2009 9:17:32 PM | 删除 回复 | 选择

非常�?d=0.3862329398997243

Re: 《大象-Thinking in UML》读者专用反馈、答疑、讨论贴 yuanbocsut | 5/12/2009 10:47:47 PM | 删除 回复 | 选择

咖啡兄，我想问一个问题，微软的PowerPoint，就其业务用例来说，只有制作PPT和演示PPT两个吗？最终系统实现当中，用户从绘图工具栏选择一个椭圆，并且制作出来，到最后能放映出来，这个用例该怎么写？希望您能抽空回答类是PowerPoint的这种交互密集型的软件的用例编写方法，不胜感激！

re:yuanbocsut 5/14/2009 3:33:09 PM | 删除

虽然看上去制作PPT和放映PPT看上去有些怪异，但是除了它们，你还能想出其它的完整的业务目标来吗？一个客户使用你们的软件，除了用来制作PPT和放映PPT之外，他还有什么别的目的吗？借用福尔摩斯的一句话，一旦你排除了所有不可能的事实外，那么剩下的，不管多么不可思议，那就是事实的真相。很明显，客户使用这个软件的目的不会是选择一个椭圆，也不会是画一个椭圆。如果非要找，用你们的软件打开和另存powerpoint格式的文件也许会是一个独立的目的。
制作PPT和放映PPT作为业务用例仅仅只是指明了业务需求的范围，它并不说明实现。那么，在概念分析阶段时，客户要如何制作一个PPT呢？新建文件，打开文件，绘制图形，保存文件，就是关键的概念用例。
在实现阶段，新建文件过程是怎样的呢？点按钮还是点菜单，这就是实现的来源，也就是系统用例。对于绘制图形概念来说就更复杂了，如你所说，绘制一个图形是一个系统用例，它的操作过程包括选择一个图形，拖放到工作区；用户可以放大缩小一个图形；可以拷贝粘贴一个图形；可以删除一个图形；可以旋转一个图形...这些就都是系统用例了。

Re: 《大象》勘误专用帖 zpy0901a | 5/9/2009 8:11:48 AM | 删除 回复 | 选择

P70：图3.21展示了实体发现的结果。网友newsunet指出应是“翻阅前面的图，发现应该是图3.17”，其实图3.17是用例图，并不是实体图，应该为图3.22吧

re:zpy0901a 5/14/2009 3:36:29 PM | 删除

十分感谢！

Re: 《大象》勘误专用帖 xxxbird | 4/24/2009 4:55:26 PM | 删除 回复 | 选择

P215: 9.2.3.2 Stackholder 应为 stakeholder

re:xxxbird 4/27/2009 10:37:18 AM | 删除

十分感谢！！

Re: 回复网友xiaobai1023的用例分析问题 ll_e_mail | 4/28/2009 4:23:41 PM | 删除 回复 | 选择

有一点不太明白，actor的最终目地是上传数据，感到“采集数据”用例也不是一个完整的用例，采集完之后做什么呢？好象只有一个业务用例“上传数据”，这一点不知道我理解的思路是否正确，请老师指教.

re:ll_e_mail 5/14/2009 3:44:17 PM | 删除

采集数据用例是一个名称的缩写，在我文章里，完整的用例描述是 a:采集我需要的数据并转换成相应的格式再返回给我；这里，我的目的就是获得转换格式以后的数据，这个目标是完整的。
采集完了是不是就一定要上传呢？未必，采集完了就放在那里什么都不做是合理的场景。因此上传数据不是采集数据的步骤，也不是目的。这两个用例是独立的。

Re: 回复网友xiaobai1023的用例分析问题 ll_e_mail | 4/28/2009 5:08:41 PM | 删除 回复 | 选择

以前我对业务用例的理解是“业务主角做一件事情”,但读到“大象”第9章 获取需求，特别是“供电企业电力管理系统”例子在第223页，用户主任的业务用列“监控业务流程”,发现我的理解出现了错误。业务用例是主角的期望，由主角触发，但不是象在生活中主角亲自去做这件事情(可以由别人或系统来做)。我理解的思路是否正确，请老师指教.

re:ll_e_mail 5/14/2009 3:36:02 PM | 删除

你的理解是正确的。业务用例是主角做一件事情，但是这里少了关键的两个字，业务用例例是主角做的一件“完整”的事情，这件事情必须能够达到主角的一个业务目标。是不是主角亲自去做，那是实现的问题。

Re: OO系统分析员之�?-用例分析系列�?�?-用例规约的编�?-业务规则和实体描述[整理重发] psuynixk | 4/20/2009 10:22:08 AM | 删除 回复 | 选择

不懂

回复:《大象-Thinking in UML》读者专用反馈、答疑、讨论贴 jokerjhm | 3/16/2009 8:54:52 PM | 删除 回复 | 选择

谭老师你好，我刚开始看您的大象，这里看得不明白，
p14，最后一句：
这件事是怎么做，依据什么规则，则通过业务场景（business scenario）和用例场景（use case scenario）的uml视图来描绘的，这些场景便是现实世界中的“规则”。
感觉这里场景指的是“规则”的意思。但是在p28，也是最后一句话：
静态的事物（物）+特定的条件（规则）+特定的动作（参与者的驱动）=特定的场景（事件）
这里的场景和前面的场景是指一个东西吗，但是这里指的是事件，事件是不是就是前面所所说的“事”。
那就被搞混了，场景到底是“事”，还是“规则”。
能帮我解释一下吗？谢谢。

re: jokerjhm 4/20/2009 2:37:46 PM | 删除

很感谢你发现这个问题。我同样用了“规则”这个词，但是两个地方表达的的确不是同一个含义。写作时忽略了这一点，用词不太准确。
第一个“规则”，由于是映射现实生活，所以这里的“规则”应当作“规律”解，做事要依据“规律”，例如办理户口要依据“户籍管理条例”，这就是一个“法规法律”，这个“法规法律”决定了你办理户口时的“场景”。这点应当很好理解吧？
第二个“规则”则是指计算机当中的逻辑了，指的是具体到一个计算机逻辑要遵守的“约束和条件”。例如要启动一个用例，要推进到下一个步骤，等等。
以后再版时应当会把这段解释加上。

回复:《大象-Thinking in UML》读者专用反馈、答疑、讨论贴 czjearth | 3/6/2009 9:12:49 AM | 删除 回复 | 选择

谭老师，
正在拜读大作-<大象>, 遇到一些设计问题，特请教。
问题已发到你的邮箱: [email protected]


先谢过！

re:czjerth 3/6/2009 5:16:58 PM | 删除

邮件已经回复，请查收。

Re: 《大�?Thinking in UML》读者专用反馈、答疑、讨论贴 clarck_913 | 4/18/2009 10:40:31 PM | 删除 回复 | 选择

谭老师，我最近也买了本您的书，没事的时候看一看。现在遇到了一个问题在第三章里，您说：参与者的是主动向系统发出请求，并得到反馈的人。并在第41页里举例子说：情况二：假如机票购买者通过呼叫中心，由人工坐席操作订票系统，那么人工坐席才是真正的参与者，而机票购买者是人工坐席的参与者。但是在�?4页您又说：区别参与者和业务工人的直接方法就是确定系统边界，如果不清楚系统边界，可通过下面的三个问题予以澄清： 1.他是主动向系统发出的动作吗？ 2.他有完整的业务目标吗�?3.系统是为他服务的吗？人工坐席只有在有购票人打电话的情况下才去买票，是被动的订票的最终目的是拿到票，但人工坐席只负责订，票最终不到他手里，他没有完整的业务目标。系统是为购票者服务的。所以，人工坐席是业务工人，购票者是参与者。这两段描述是否是互相矛盾的呢？我应该如何理解？是否是因为在41页里的例子中，情况二，情况三中，呼叫中心（不论是人工坐席还是语音订票）不在机票预订系统中，所以才说呼叫中心是机票预订系统的参与者？判断系统边界的三个问题，您说如果答案都是否，那么一定是业务工人，那如果有一个或两个不是否呢？如何确定该角色是业务工人还是参与者呢？谢�?d=0.9780080134802744

re:clarck_913 4/20/2009 2:13:50 PM | 删除

这里的关键是边界。假如边界如：机票购买者->[人工座席、在线网站、语音系统->[订票系统]]，[]代表边界。这跟我们生活中的实际情况相符，你是买票人，系统是从买票人开始分析的，那么当然，“人工坐席只有在有购票人打电话的情况下才去买票，是被动的订票的最终目的是拿到票，但人工坐席只负责订，票最终不到他手里，他没有完整的业务目标。系统是为购票者服务的。所以，人工坐席是业务工人，购票者是参与者。”
但是，如果边界如：人工座席->[订票系统]，这种情况是在机票代理处内部，系统是从机票代理处的代售人员开始分析的，所以这时的参与者是人工座席，或者说人工座席是买票人的“代理”，全权代理了买票人，可以忽略买票人的存在。同样的道理，如果边界是语音系统->[订票系统]，那么参与者就是语音系统了。这种情况一般发生在你在做语音系统与订票系统的集成时。
从上面的例子你也可以看出，后面两种情况是第一种情况的子集。其实这正是做系统分析当中从业务用例到概念用例的转化过程。订票是一个业务用例；这个业务用例通过分析，可以得出人工订票、语音订票、自助订票（在线网站）等概念用例；这些概念用例的操作过程不同，甚至不是由同一个开发商完成的，但是它们都为了完成订票这个业务用例的业务目标。
如果你是订票系统的总包商，那么通常应当从整个业务用例开始；如果你只是一个分包商，例如语音系统提供商，那么你可以不管网站、不管人工，从语音->[定票系统]这个边界出发就可以了。

回复:OO系统分析员之路--用例分析系列（4）--业务建模一般步骤和方法[整理重发] wsgaero | 3/14/2009 12:56:15 AM | 删除 回复 | 选择

请教咖啡一个问题：现在有一个上位机通过网络来统一管理所有挂接在同一局域网内的所有下位机，下位机负责功能处理，并把处理的结果通过网络传递给上位机，上位机负责把收集到的来自所有下位机处理的结果统一呈现在用户面前。用户可以坐在上位机面前使用上位机软件来修改每台下位机的配置信息，也可以通过远程客户端软件的形式来对下位机的配置进行调整。类似这样的需求，是否远程用户、最终用户、上位机和下位机都是参与者呢？多谢！

re:wsgaero 4/20/2009 1:30:47 PM | 删除

参与者是远程用户和最终用户应该是参与者。上位机、下位机只是业务工人。如果你画一个活动图，就会发现所有的发出动作都是由远程用户和最终用户发出的，上位机、下位机都是被动参与管理流程的。

Re: OO系统分析员之路--用例分析系列（7）--用例规约的编写--业务规则和实体描述[整理重发] showerXP | 4/15/2009 10:02:07 PM | 删除 回复 | 选择

虽然洋洋洒洒写了不少字，不过关于用例本身却寥寥无几。飘的太严重了。

showerXP 4/20/2009 1:27:02 PM | 删除

如果你是从系列（1）一路看过来作出如此评价的，那我真得好好反思一下了。

Re: OO系统分析员之路--用例分析系列（7）--用例规约的编写--业务规则和实体描述[整理重发] axiform | 4/17/2009 11:55:32 AM | 删除 回复 | 选择

太阳炉？

re:axiform 4/20/2009 1:32:00 PM | 删除

广告？

Re: OO系统分析员之�?-用例分析系列�?�?-用例规约的编�?-业务规则和实体描述[整理重发] meinvxiezhen | 4/17/2009 5:05:06 PM | 删除 回复 | 选择

太阳炉？

Re: OO系统分析员之�?-用例分析系列�?�?-用例规约的编�?-业务规则和实体描述[整理重发] fkljb | 4/18/2009 12:57:42 AM | 删除 回复 | 选择

“题外话说了不少，书归正传�?d=0.8259433943532639

re:fkljb 4/20/2009 1:56:15 PM | 删除

我也没看懂

回复:关于非行业服务软件的业务建模问题 xiaobai1023 | 3/2/2009 11:49:16 PM | 删除 回复 | 选择

谭老师，你好：
我有这样一个需求：
通过调度框架如（quartz）定时去执行一些动作，动作的内容是去取一些“原始数据”可能是一些文件，也有可能是通过socket向第三方系统发送一条命令得到的数据，将得到的这些原始数据通过一些数据的映射、转换组装成我的上层系统中的值对象上传。
可能是需求简单的缘故，本身实践UML的时间也不长，产生了如下疑问，希望您能帮助解答一下，谢谢。
1、我刚开始把我的系统使用者作为业务主角去分析获取他的用例，但是发现从他的身上得到的用例只有两个：控制调度、配置“原始数据”和上层系统的值对象的对于关系，其中控制调度包括配置和启、停调度，后来又觉得作为业务用例的话我的业务主角只有一个业务用例那就是 采集数据，但是后来发现不管从哪个业务用例出发，到了系统用例的时候却依然还是那些用例，有些迷茫了，可能是我的角度没有站对吧。
2、系统中的调度框我老是觉得有些系统用例是由他发出来的，按照老师书中所讲的他应该是一个 业务工人，不是业务主角，但是这样的话就觉得有些用例没有了发出者~
目前就是这样，望能解惑，谢谢。

re: xiaobai1023 3/6/2009 5:22:07 PM | 删除

回复看此帖http://blog.csdn.net/coffeewoo/archive/2009/03/04/3956500.aspx