2006-12-8 9:41:33 火 柴： 最近在作一个网站项目，其中有用户子系统，我们的网站会在发布以后在客户使用的过程中根据客户的需求加入一些子系统
2006-12-8 9:41:54 火 柴： 每个子系统都涉及到用户子系统
2006-12-8 9:42:32 火 柴： 但是子系统之间对用户的操作不一样，权限控制也不一样
2006-12-8 9:44:38 火 柴： 要求加入新的子系统不要影响原有系统的运行或重新部署整个系统，象这样的应用，我应该为每个子系统在数据库中单独做一个用户表吗？
2006-12-8 9:46:51 潘： 再说得具体一些，例如"对用户的操作不一样"，"一些子系统"是什么东西
2006-12-8 9:53:46 火 柴： 我正在做的相当于一个母体，或是主体，包含了用户相关的基本操作，入登录、修改密码、登出等，那么我们还会针对行业的需求开发很多针对不同业务的子系统，假设我现在要开发两个子系统A 和B，A 系统里需要涉及到用户的积分、消费金额，而B 系统不需要，B 需要涉及到用户的信用度而A 不需要
2006-12-8 9:54:43 火 柴： A 和B 的需求是在开发母体的时候不能预料的
2006-12-8 9:55:53 潘： 那么为什么会想到要问"每个子系统在数据库中单独做一个用户表吗"呢？
2006-12-8 9:55:55 火 柴： 单是A 和B 的用户管理又不能完全分离，避免在同以站点下，用户使用不同的系统而多次注册
2006-12-8 9:57:29 火 柴： 应为以前没有做过类似的应用，心理没底:)
2006-12-8 9:58:16 火 柴： 所以想请潘老师指点一二
2006-12-8 10:04:24 潘： 你说问题的时候已经比较清楚了啊，用户资料的构件（子系统）、权限管理的构件（子系统），AB 等其他构件分开。增加新系统时，不需要修改用户资料构件。你的意思是不是要问：A、B...里面还有没有用户类？
2006-12-8 10:07:56 火 柴： 嗯，我是这么想的，母体里的用户类是所有子类用户类的父类，子类中的用户类和母体里的用户类是isa..关系，然后在母体内定义一些接口，由子类去具体实现
2006-12-8 10:10:35 火 柴： 就是因为以前没有这样做过，所以心里没底，想听听向您这样经验丰富的前辈的意见:)
2006-12-8 10:14:17 潘： 首先，"母体"等说法值得商榷，这样似乎"用户"的位置和别的业务概念的地位不同，其实它只是预测中短期内变化不大的一个概念
2006-12-8 10:16:07 火 柴： 嗯是的，我指的母体是用户的一个基础实现，就是不管怎样，子系统都会用到的部分，入用户名，密码，登陆等
2006-12-8 10:18:33 火 柴： 涉及到子系统具体业务逻辑的部分就由子系统来实现，不知我这样的理解是否正确
2006-12-8 10:22:32 潘： 这个是对的，但不使用子类方式，使用"角色"来描述不同业务会给用户带来的一些需要关注的新特征会更好
2006-12-8 10:26:39 火 柴： 这个我也想过，但是这样我必须要在用户类中考虑到所有可能的角色，这正是
不能预料到的
2006-12-8 10:27:37 火 柴： 比如User.IsAdministrator,User.IsAgent,User.IsPlayer
2006-12-8 10:27:38 潘： 用户类不需要考虑角色啊
2006-12-8 10:30:48 火 柴： 但是在数据库中做权限和角色的映射的话，系统如何知道那个角色对应可以做哪写操作呢？
2006-12-8 10:32:05 潘： 用户－角色－权限－访问对象，你看哪些能分到哪里
2006-12-8 10:35:10 火 柴： 我认为如果说访问对象在开始做系统时是已知的话，这样做是很好的，从访问对象定义访问权限，然后将权限分配给角色，再将角色附加到用户。
2006-12-8 10:37:12 潘： 所以角色－权限－访问对象只能由"权限"和AB...来负责，通过继承和组合扩展现有的用户都可以
2006-12-8 10:39:01 火 柴： 这样就是再A 和B 中还是要做各自的用户类，来继承或扩展现有的用户类？
2006-12-8 10:41:05 火 柴： 然后再各自的用户类中明确其访问权限？
2006-12-8 10:47:08 潘： 对啊，把现有的"用户"构件看成是生成用户对象的仓储
2006-12-8 10:50:46 火 柴： "把现有的"用户"构件看成是生成用户对象的仓储"，这句话我看得不太明白，
可以详细解释一下吗？
2006-12-8 11:02:20 潘： 就是不要绕过它又通过别的方式来生成AB...里的用户对象
2006-12-8 11:04:58 火 柴： 明白了。。。那还需要再数据库中为不同子系统的用户建不同的表吗？我感觉这样就不需要在数据库中做角色映射了
2006-12-8 11:07:46 潘： 不用。而且"数据库"和"对象"的表达方式不需要一定是一致的。
2006-12-8 11:09:46 火 柴： 这样我就糊涂了，那我如何确定某个用户在某一子系统下是否有访问权限，可以做特定的操作呢？
2006-12-8 11:11:34 潘： 你说的"角色映射"指的是什么
2006-12-8 11:14:06 火 柴： 就是在数据库中有一个权限表，每条记录都对应一个可以做的操作，然后给不同的角色添加权限，这样就可以知道那个角色可以做哪些操作
2006-12-8 11:20:26 潘： 那就是回到了你最开始的问题嘛，"每个子系统在数据库中单独做一个用户表吗"，要的，但它只需要维护标识和角色、权限、积分...的关系，不再保存"用户"构件所涉及的资料。但在业务层对象的级别上，你的代码应该对此一无所知
2006-12-8 11:24:04 火 柴： 嗯是的，这是我所想的，每个子系统的用户表只保存与其业务相关的用户信息，
不重复保存用户构件的资料
2006-12-8 11:28:14 火 柴： 我已经明白要怎么做了，谢谢您潘老师，占用了您很多时间。
2006-12-8 11:29:00 潘： 其实关键点不在于表怎么设计，而是"在业务层对象的级别上，你的代码应该（尽量）对此一无所知"，能做到这点就行了
2006-12-8 11:32:47 火 柴： 我想使用工厂方法的模式，由子系统负责创建用户对象，我现在担心的是不同的用户对象有不同的操作，也就是类里面的方法，在业务层对象的级别上使用时，还是要依赖于用户的具体类型
2007-3-9 11:27:07 火 柴： 潘老师你好
2007-3-9 11:27:43 火 柴： 对于网站建模您有什么好的建议吗？
2007-3-9 11:39:11 潘： 网站只是一种表现，背后还是业务，都是一样的
2007-3-9 11:41:35 火 柴： 我觉的不好描述网站背后的业务，因为很多网站的功能都是相似的，这些东西都已经在电脑上实现了，我如何开始对网站进行业务建模呢？
2007-3-9 11:42:12 潘： 你说你要做什么东西吧
2007-3-9 11:44:38 火 柴： 我现在要做一个网上商店，但是我们都知道网上商店有商品分类，添加商品，会员管理，促销活动，订单，购物车等等，在这中情况下，我应该如何利用建模的力量，做出好的设计，以便让团队其他成员能很好的进行开发呢？
2007-3-9 11:45:41 潘： 首先你要搞清楚问题，你为什么要搞网上商店，现在已经有很多了
2007-3-9 11:46:47 火 柴： 网上商店是我们公司的产品，我们给商家提供这个产品，他们用我们的产品在网上开店
2007-3-9 12:30:16 潘： 也就是说现在商家要开店需要很多时间，而且自己不会做交给别人做的话，还会花很多钱
2007-3-9 12:30:29 火 柴： 是的
2007-3-9 12:30:47 潘： 有了你们这个产品，他们自己就能开店，省下时间和金钱？
2007-3-9 12:31:34 火 柴： 我们为商家把网店、域名、空间等所有的东西弄好，商家只需登录运营，而且价
格很低
2007-3-9 12:33:52 火 柴： 哦，我先自己学习一下，有一定的经验后再请你们来指导，呵呵，我们领导很重视学习，我们也是刚组建开发团队，以前的产品都是一个人做的，现在他不肯公开源码，我们又不好维护，所以只能重新开发一个产品
2007-3-9 12:34:33 潘： 你好好复习一下我们课上的业务序列图，用那个就可以。
2007-3-9 12:34:49 潘： 那个模型还在吗
2007-3-9 12:35:12 火 柴： 还在，当宝贝收着的。。。
2007-3-9 12:36:09 火 柴： 那这样一个网站，它包含了哪些业务呢，我列举的这些模块和业务又是什么样的关系呢？
2007-3-9 12:37:25 潘： 你先不要想他包含什么，你先把目前商家要开成一家店多么辛苦这个过程画出来，再把你要开发的系统放进去
2007-3-9 12:37:38 潘： 就知道需要哪些功能了
2007-3-9 12:39:16 火 柴： 但是这个系统本身并不包含域名和空间的管理，要开发的系统只是网店本身
2007-3-9 12:40:11 潘： 不管包括不包括，你就如实照画啊
2007-3-9 12:41:12 潘： "系统本身并不包含域名和空间的管理"这里要讨论，如果能帮它管理域名空间，时间不是更节省吗
2007-3-9 12:41:30 潘： 你先想清楚业务上的问题，系统做什么自然会出来
2007-3-9 12:42:06 潘： 如果只是想做一个东西出来，不管人家买不买，那分分钟都可以交付
2007-3-9 12:43:54 火 柴： 我们的产品是免费的，域名和空间都是我们的技术人员管理的
2007-3-9 12:44:41 潘： 那么如果用的人多了，你们公司会有什么好处
2007-3-9 12:46:41 火 柴： 用的人多了，就会有很多人需要一些特殊的功能去支撑他的业务，那么他们找我们开发这些功能是收费的，还有就是网站样式的定制也是收费的，基本上大家都希望自己的网站和别人的看起来不同，再就是技术支持服务费
2007-3-9 12:49:24 潘： 那么对公司领导来说，目标的度量是：被吸引使用特殊功能的人数？
2007-3-9 12:50:18 火 柴： 对，公司领导最大的目标就是扩大产品市场占有率
2007-3-9 12:50:52 火 柴： 有了占有率，他就有很多样的操作空间和方法了
2007-3-9 12:51:43 潘： 目前占有率多少
2007-3-9 12:54:17 火 柴： 目前占有率很低，有比我们做的好的产品，我们自己开发的目的就是根据商家的需要加快产品的更新，给商家提供更好用的系统，以此和对手竞争，超越对手
2007-3-9 12:57:29 潘 发送 问题卡.jpg
2007-3-9 12:59:30 火 柴： 因为网上商店要做些什么我们从几年的经营经验和商家的反馈都已经比较清楚了，现在我最大的疑惑就是如何将我和公司其他同事以及客户知道的东西在开发之前很好的分析设计出来，给我们整个团队一个清晰的指导，我们以前什么都是一个人做的，虽然知道要怎么去做，但是在做的过程就会出问题，比如偏离目标或进度延迟等等。。。
2007-3-9 12:59:51 潘： 你按照这个思路从1-6 填一下，
2007-3-9 13:00:18 潘： 开发团队最大的毛病是直接从6 开始
2007-3-9 13:00:23 火 柴： 好的，谢谢
2007-3-9 13:00:41 潘： 既然比较清楚了，怎么会表达不出来？
2007-3-9 13:00:59 潘： 如果表达出来了，可以把需求文档给我看看
2007-3-9 13:02:08 火 柴： 还没有，正在着手做这件事，昨天就和几个熟悉业务的同事把后台的功能模块整理了一下，因为以前的系统都有，我们加了一些改进意见
2007-3-9 13:04:57 火 柴： 因为以前的系统有很多不好用的地方，还常出错，现在要改又没有源码，做特殊功能的开发没有源码也不能进行
2007-3-9 13:05:31 火 柴： 所以我们组建了开发团队重新开发
2007-3-9 13:07:18 潘： 很多不好用就等于废品嘛，甚至连废品都不如，因为它制造了假象。不能说有了一个。只能说某个开发人员写了一个东西，在他拿工资的角度来说，开发过程已经结束了，有了一个系统。但对公司和商家来说，什么都没有，甚至更糟。
2007-3-9 13:07:46 火 柴： 是的，没错
2007-3-9 13:08:53 潘： 所以不能盲目乐观，说"网上商店要做些什么我们从几年的经营经验和商家的反馈都已经比较清楚了"，你要先尝试表达清楚，再来讨论对不对。
2007-3-9 13:10:01 火 柴： 嗯，是的，那我现在的问题潘老师您明白了吗？
2007-3-9 13:21:42 火 柴： 卡片我填好了，请潘老师看看： 1、问题现有的产品质量很差，导致我们的产品市场占有率很低 2、当前度量市场占有率可能低于10％ 3、目标度量市场占有率达到60％ 4、原因市场占有率提高后会带动公司业绩的提高 5、涉众利益 a.在网上开店的商家，商家可以使用功能很强大、很稳定的网上商店系统在网上销售商品，获得利润 b.公司股东，公司的业绩提高了可以带给股东更大的回报 c.公司员工，公司业绩提高了，公司发展了，员工的价值可以得到更好的体现 d.为社会创造价值
2007-3-9 17:12:06 潘： 原因指，问题的原因
2007-3-9 17:13:28 火 柴： :$ 问题的原因是产品质量差，但是又无法完善现有产品
2007-3-9 17:13:43 潘： 业务上的问题是：市场占有率低
2007-3-9 17:13:56 火 柴： 是的
2007-3-9 17:14:49 潘： 市场占有率指的是什么东西的市场占有率？产品质量指的是什么产品的质量
2007-3-9 17:17:04 火 柴： 我们的产品就是当初一个程序员开发的网上商店系统市场占有率低就是指我们的网上商店系统比同行的同类系统的占有率要低
2007-3-9 17:20:32 潘： OK，我们来看原因：产品质量差，这是不够的
2007-3-9 17:21:00 潘： 需要把竞争对手的优势劣势写出来
2007-3-9 17:21:11 潘： 差在哪里？
2007-3-9 17:22:43 潘： 要看到这些，可能需要围绕竞争对手的产品进行业务建模，从中找到怎样在对手的基础上再进一步或者反过来做
2007-3-9 17:22:52 火 柴： 在系统稳定性和功能完善程度以及操作友好性方面都不如对手
2007-3-9 17:23:05 潘： 而不是在现在的那个烂摊子上改
2007-3-9 17:23:27 火 柴： 是的，我们已经决定不在维护以前这个产品
2007-3-9 17:23:32 潘： 在系统稳定性和功能完善程度以及操作友好性方面都不如对手－－哪些？需要一一指出来，这就是需求
2007-3-9 17:25:18 火 柴： 哦...那我现在还需要做业务建模吗？
2007-3-9 17:26:20 潘： 业务建模和需求是一样的，一个是大的研究范围，一个是小的
2007-3-9 17:27:17 潘： 其实你只要做好一件事：用业务序列图把最好的竞争对手的产品是如何为商家提供价值的这个过程说清楚就行
2007-3-9 17:27:56 潘： 然后在这个基础上调整和改进，自然就得到了系统的各种应有的功能
2007-3-9 17:29:20 火 柴： 序列图我们上次讲课的时候好像没有讲到?
2007-3-9 17:29:52 潘： 讲了，而且是重点，你打开我们的模型
2007-3-9 17:30:27 火 柴： 好，打开了
2007-3-9 17:31:34 潘： usecaseview--业务用例下面，"解决使用故障"业务用例，下面有个序列图就是
2007-3-9 17:34:22 火 柴： 就是做按箭头方向判定一个对象包含哪些操作练习的那种图吧
2007-3-9 17:35:27 火 柴： 这个又叫顺序图？
2007-3-9 17:35:54 潘： 对
2007-3-9 17:38:23 火 柴： 我明白了，还有最后一个问题，我如何围绕竞争对手的产品或是我们自己罗列的需求提炼出产品的业务用例？
2007-3-9 17:39:38 潘： 你先列出来再问你们老总，这是公司决策的问题，不一定是模仿，也许模仿是死路。请看课上幻灯umlchina_r.pdf。老总不同的决策导致不同的需求。
2007-3-9 17:40:19 火 柴： 嗯，没错，我们也不向一味的模仿
2007-3-9 17:40:44 潘： 我如何围绕竞争对手的产品或是我们自己罗列的需求提炼出产品的业务用例？－－没有这个说法
2007-3-9 17:40:45 潘： 其实你只要做好一件事：用业务序列图把最好的竞争对手的产品是如何为商家提供价值的这个过程说清楚就行
2007-3-9 17:41:25 潘： 然后在这个基础上调整和改进（怎么调，要问老总的决策，否则一百个人有一百个人的调法），自然就得到了系统的各种应有的功能
2007-3-9 17:46:36 火 柴： 需要把每一个业务用例都列出来做一个业务序列图吗？
2007-3-9 17:50:05 潘： 一个业务用例可能有几张业务序列图。同学，你没有把我们课上讲的东西复习好啊。
2007-3-9 17:50:24 火 柴： :$
2007-3-9 17:50:45 潘： 序列图是干什么的，有几张...请看umlchina_seq.pdf(或umlchina_5.pdf)
2007-3-9 17:50:46 火 柴： 是的，我回来后一直没有实践的机会
2007-3-9 17:51:04 潘： 你先做，做出来再给我看看
2007-3-9 17:54:19 火 柴： 添加商品能算是一个用例吗？
2007-3-9 17:54:52 潘： 不算。
2007-3-9 17:55:17 潘： 业务用例就是两个：建店，日常维护
2007-3-9 17:55:49 火 柴： 这是把商家做为研究对象吧
2007-3-9 17:56:13 潘： 商店
2007-3-9 17:58:15 火 柴： 那添加商品应该怎么理解呢？
2007-3-9 18:00:05 潘： 商店是一个整体概念，是能为商家提供利润的东西。你的网站系统只不过是商店的一部分。
2007-3-9 18:01:39 潘： 商家进货，向你的系统添加商品（更准确地说，上架。添加商品是技术人员的口气），在别的地方打广告，发垃圾邮件。。。。才算完，这些价值你的系统能包含吗？
2007-3-9 18:02:28 潘： 把商品在网上商店上架，只是一个小小步骤而已
2007-3-9 18:03:07 火 柴： 现在在系统里面还不能包含这些价值
2007-3-9 18:04:10 火 柴： 那对于商店的日常维护来讲，就包括了订单管理、商品促销等这些对吗？
2007-3-9 18:04:59 潘： 那应不应该包含呢？这不是你说了算的。
2007-3-9 18:05:31 潘： 在我这个外人看来，也许一个包含了发垃圾邮件功能的系统最受欢迎
2007-3-9 18:06:07 火 柴： 如果包含了，我就应该在日常维护的用例下面做订单管理和商品促销的序列图，对吗？
2007-3-9 18:06:10 潘： 把商家赚钱的过程描述清楚，问问老总，看看哪些还能帮到商家
2007-3-9 18:07:45 火 柴： 嗯，确实没错
2007-3-9 18:15:04 火 柴： 我在rationalmodeler6.0 里面看一个例子，它用一个在线银行系统做为演示对象，它把显示账户余额、兑现支票、转账分别做为了三个用例，这与我所说的商品上架有什么区别吗？我觉得是一回事...
2007-3-9 18:43:44 潘： 那是系统用例
2007-3-9 18:44:15 潘： 你把我们上课模型好好研究一下，想想里面的脉络
2007-3-14 21:14:04 火 柴： 潘老师我现在面临一个很大的难题，我一直都是些程序的，可能是公司里面比较有经验的程序员吧，公司组建开发团队老板让我来带头，我是从去年上公开课前一点才接触uml，才开始了解项目管理，也看了一些书籍，通过去年的一个项目才确实认识到项目管理的重要性，才知道编码确实只是软件开发过程中很小的一个组成部分，我现在期望一些改变，想从公司这次的这个项目开始，实践的过程遇到很多的问题，很难按照预想的方式进行下去，但是产品要求的交付时间很紧，面对这种情况，您能给我一些建议吗？
2007-3-14 21:15:25 潘： 老总怎么想
2007-3-14 21:18:52 火 柴： 老总也意识到以前的开发模式对公司的整体发展很不利，现在就是产品这一块使公司的发展产生了很严重的瓶颈，产品的更新和升级都跟不上，所以也希望通过团队的力量把产品的更新速度和质量提上去
2007-3-14 21:19:57 火 柴： 现在开发新产品、完善开发团队就是我最重要的工作
2007-3-14 21:22:47 潘： 现在的开发模式是怎样的
2007-3-14 21:26:15 火 柴： 现在的开发模式就是一个人包揽所有事情，开发活动从头到尾就是不断的写代码，这样导致的结果就是周期长，期间没有任何可以交付的产品，公司里其他人也不知道做到什么样子了，然后几个月过去了，做完的东西就不是原本想要的，完全偏离了，要不就是时间到了，自己也觉得已经快写完了，可以出产品了，但就是出来，很郁闷
2007-3-14 21:27:01 火 柴： 就是出不来
2007-3-14 21:30:56 潘： 首先要改善的应该是，需求（定义问题）和编码（解决问题）的人员要分开。可以从简单的需求管理开始，引入一个需求工程师的角色（如果你杂务不多，可以你来做），他负责向涉众探索需求、定义需求和跟踪需求，有权力监督编码人员的工作。
2007-3-14 21:31:22 潘： 公司开发人员不多吧
2007-3-14 21:32:28 火 柴： 现在有6 个，还没敢引入太多
2007-3-14 21:33:40 火 柴： 这个分工现在可以实现，我也确实在做这些事情，也是由于没有一点经验，很多地方力不从心
2007-3-15 16:48:05 火 柴： 潘老师下午好，我在看《编写有效用例》一书时，里面说道了用例的层次，分为概要、目标和子功能，我们所说的业务用例是不是属于概要层的用例？
2007-3-15 16:51:21 潘： Cockburn 这种划分只是一种参照，用例就是：给定研究对象，从外面描述他的价值。概要层用例是什么，就看它描述的是什么研究对象
2007-3-22 9:15:59 火 柴： 请问在业务建模中，有没有一种角色既是业务执行者也是业务工作者？
2007-3-22 9:17:51 潘： 谈这些东西，首先要说清楚研究对象是什么
2007-3-22 9:18:51 潘： 研究对象确定下来了，谁是业务执行者业务工人就定下来了
2007-3-22 9:19:09 火 柴： 我在做一个知识库系统的建模作为练习，研究对象是我们公司
2007-3-22 9:20:18 火 柴： 我昨天识别了业务执行者和业务用例，画了活动图，您能不能帮我看看？
2007-3-22 9:20:44 潘： 好
2007-3-22 9:21:27 火 柴 发送 kb.mdl
2007-3-22 11:45:57 火 柴： 潘老师您帮我看了吗？
2007-3-22 11:46:11 潘： 还没:$，下午吧
2007-3-22 11:46:35 火 柴： 哦，好的，我可不可以先问两个问题？
2007-3-22 11:49:15 潘： 请说
2007-3-22 11:50:55 火 柴： 在业务建模时，是不是先画活动图，再分析业务对象，再画序列图？
2007-3-22 11:52:26 潘： 画活动图或序列图即可
2007-3-22 11:52:36 潘： 只要一个
2007-3-22 11:53:04 火 柴： 活动图没法给每个对象分配责任？
2007-3-22 11:53:24 潘： 是，最好学会画序列图
2007-3-22 11:54:42 火 柴： 画序列图牵扯到一些业务对象，这些业务对象怎么分析出来呢？是根据自己对业务的理解直接在类图中画吗？
2007-3-22 19:53:43 潘： 这些业务对象怎么分析出来呢？是根据自己对业务的理解直接在类图中画吗－－对
2007-3-22 19:53:53 潘： 就是对领域建模
2007-3-22 19:54:59 火 柴： 那就是说在识别了业务用例以后，就可以画业务对象图了是吗？然后在画业务序列图的时候引入涉及的对象？
2007-3-22 19:56:03 潘： 是
2007-3-22 19:57:40 火 柴： 知道了，您帮我看看我的业务用例有没有问题，没什么大问题的话我就接着画序列图:$
2007-3-22 19:59:18 潘： 好
2007-3-22 20:00:51 火 柴： 我在看编写有效用例这本书的时候，它提到如果用例是用例记录组织的业务过程，那么研究对象应该是组织，如果是一个软件的行为需求，那么研究对象应该是这个软件本身，我前段实践向您请教的网店系统建模研究对象是不是这个系统本身呢？
2007-3-22 20:01:47 潘： 你喜欢是什么就是什么啊
2007-3-22 20:02:22 潘： 你要搞清楚：网店系统软件和网店的区别
2007-3-22 20:03:15 火 柴： 我现在觉得，对组织的业务进行建模，识别业务执行者和业务用例还是比较有把握，但是对于这种没有固定组织的东西，我不知如何去识别
2007-3-22 20:03:55 火 柴： 我确实不知道网店系统软件和网店的区别，不知道从哪个角度上去区分他们两个的不同，您可以教我吗？
2007-3-22 20:04:49 潘： 你的客户是要赚到钱。光安装你的系统，能直接给他带来钱吗
2007-3-22 20:06:22 火 柴： 不能
2007-3-22 20:07:32 火 柴： 这么说客户还是与我们告诉发生业务，客户从业务中得到的价值就是在网上销售赚钱？
2007-3-22 20:07:49 火 柴： 打错字了，我们公司
2007-3-22 20:08:11 潘： 对了吗。你就描述他平时怎样赚钱，然后再从他平时赚钱的过程研究，你的系统怎样插进去，帮它赚到更多的钱
2007-3-22 20:11:50 火 柴： 我想这正是难题，因为我无法描述客户现在的业务过程，无法找到可以改进的地方，还有些人平时就没有卖东西，但是他也想开网店
2007-3-22 20:14:14 火 柴： 或许我忽略了现实中商店老板的开店赚钱这个业务过程了？在做业务建模的时候过早考虑到网店系统了？
2007-3-22 20:15:48 潘： 可以去研究竞争对手的产品，看看他们的客户怎么赚钱，然后在此基础上再改进
2007-3-22 20:16:43 潘： 网店系统是现实的一部分，但不是你要做那个，而是现在起作用的那个，特别是好的竞争对手的那个
2007-3-22 20:18:23 火 柴： 网店系统软件是一个计算机程序，网店是一个业务组织？
2007-3-22 20:19:06 火 柴： 这两个问题的区别我一直没有转过弯:$
2007-3-22 20:20:47 潘： 我看看你的模型再讨论
2007-3-22 21:30:00 火 柴： 看完了吗潘老师？
2007-3-22 21:36:26 潘： 刚刚看。首先，把"海维"作为研究对象可能不合适。因为根据之前的讨论，问题是：网上商店系统市场占有率比同行的同类系统的占有率要低。这不是改善你们公司内部管理的问题。而是改善为什么顾客不愿意使用你们的产品的问题
2007-3-22 21:37:10 火 柴： 我这个是做的一个知识库系统
2007-3-22 21:37:45 潘： 啊，不是给顾客用的自助网店系统吗？
2007-3-22 21:38:56 火 柴： 上次是，但是网店系统时间很紧，要等我做完分析设计来不及，我们已经结合以前的经验在做了
2007-3-22 21:39:12 火 柴： 知识库系统是我自己做的一个练习
2007-3-22 21:39:44 潘： 那你像上次一样填一个问题卡。
2007-3-22 21:39:51 潘： 要解决的问题是什么？
2007-3-22 21:42:31 火 柴： 要解决的问题是公司各部门的员工在日常工作中的经验和教训没有记录下来，日后碰到同样的问题可能又要很长时间才能解决，在就是解决客户没有一个很好的了解产品使用相关知识平台的问题
2007-3-22 22:22:56 火 柴： 问题： 1、客户没有很好的查询产品使用帮助的地方 2、公司员工的工作经验没有得到积累，工作技能提高缓慢 当前度量： 1、客户不能方便的查询产品使用帮助，会流失客户。 2、同时客户会直接找工作人员，如果工作人员平常没有积累，每次都会花很多时间解决类似的问题，耽误工作时间 目标度量： 1、让客户随时查找遇到的问题，减少客户的抱怨 2、让工作人员及时为客户解决问题 原因：公司本身在产品的开发上存在问题，没有完善的开发过程，没有文档记录，也没有完整的产品使用文档没有一个很好的平台和奖
励机制鼓励员工积累经验知识 涉众利益： 1、客户：可以及时解决产品使用过程中的问题 2、公司：增强客户忠诚度 3、员工：提升自身能力
2007-3-22 22:59:31 潘： 我先想想，再答复你。
2007-3-23 20:37:27 潘： 昨天的问题我还没有仔细看
2007-3-23 20:37:43 火 柴： 没关系，我问题一个新问题
2007-3-23 20:38:56 火 柴： 我在做业务建模的时候，需要做业务序列图，在做业务序列图之前需要先识别
业务对象，是吗？
2007-3-23 20:39:26 潘： 可以边画边识别
2007-3-23 20:39:52 潘： 也可以先识别好了，画出业务对象模型，再画序列图，都可以
2007-3-23 20:41:12 火 柴： 那在业务建模的时候就对业务对象有职责分配了，这个职责分配跟在分析阶段对类的职责分配有和区别？而且在分析阶段也需要做序列图对类分配职责，这个时候的序列图和分析阶段的序列图有什么不同？
2007-3-23 20:41:54 潘： 研究对象不同。请比较课上模型的两个序列图
2007-3-23 20:43:58 火 柴： 哦，看到了，系统用例也有序列图，类图及类的职责就是根据用例文档和系统用例的序列图做的吧
2007-3-23 20:44:26 潘： 对
2007-3-23 20:45:17 火 柴： 那假设先业务序列图已经做好了，如何在业务序列图的基础上映射系统执行者和系统用例呢？
2007-3-23 20:46:01 潘 发送 对象技术在业务建模中的应用.pdf
2007-3-23 20:47:29 火 柴： 这个问题可以在这个pdf 中找到答案？
2007-4-29 9:42:10 火 柴 <<编写有效用例>>一书中将用例分成了好几个层次,它所说的用户目标层,能否理解为就是系统用例?
2007-4-29 9:43:35 潘： 可以这样理解。但书中不严谨。所谓目标可大可小，应该从"研究对象"来说是不是系统用例
2007-4-29 9:46:57 火 柴 那这样的话,可以直接询问用户希望使用系统完成哪些目标,并遵循书中提到的一些原则,就可以得到系统用例?
2007-4-29 9:48:40 潘： 如果这样能得到当然是很好，但用户往往是不知道系统能为他做什么，该为他做什么。还是要象我们课上的那样，从业务建模着手
2007-4-29 9:48:59 火 柴 嗯,没错
2007-4-29 9:49:05 潘： 其实你按照我们的幻灯片作即可，比什么书都要好
2007-4-29 9:51:05 火 柴 我反复看了很多次幻灯片,确实每次看都会有收获,但是实际做的时候就有不少疑惑,主要结合我要做的网店系统有不少问题,我上次发到您的邮箱里面了
2007-4-29 9:51:25 潘： 好，我看看
2007-5-9 19:36:33 火 柴 我在做的过程中发现,通过业务建模,不足以映射所有系统用例
2007-5-9 19:38:16 潘： 那当然了，本来就不是一一映射
2007-5-9 19:39:28 火 柴 比如在业务发生之前就应该存在的一些数据,这些数据我想也是通过某一个用例输入到系统里面的,但是在业务过程中没有对这些数据增加或修改的操作
2007-5-9 19:40:04 火 柴 那没有被映射的系统用例,用什么方法去挖掘呢?
2007-5-9 19:40:55 潘： 不可以映射的倒不是说这种，这种是可以映射的，比如说什么数据，你举个例子
2007-5-9 19:43:34 火 柴 比如我前几天一直请教您的网上商店的业务建模,把网点作为研究对象,业务用例应该只有"顾客-->购买商品"这一个,在画购买商品用例的序列图时,其中就有浏览商品、把希望购买的商品加入购入车，商品这个数据，就是我上面说的情况
2007-5-9 19:45:29 潘： 难道在你开发你这个系统之前，"商品"就不存在了，商家就不入库了？他也会用手工记录入库，或者用其他厂家的产品来记录啊。
2007-5-9 19:47:18 火 柴 但是在购买商品这个用例的序列图里面没有商家入库商品这一步，当然我只画了基本路径，这也是我的另一个疑问，光画基本路径好像不够
2007-5-9 19:51:16 潘： 对于一个业务组织来说，入库只是一个步骤，它在很多个用例里都可以出现，例如，"顾客－购物"用例，发现短缺，就要引发采购，入库等活动；例如"商店老板－－管理商店"里，可能定期就会有采购，入库的活动。你的任务就是去观察现实中"入库"这样的事情是怎么引发的，如实记录下来就可以了。
|