调查的目的是什么？

作个标记

我的场景是超市，是那种自助的

客户到了 

PUBLIC CLASS client
{
 
选择商品；
付款 ； 

} 

选择了商品 PRODUCT
{
   外观 （）；
   性能（） ；
单价（） ；


}



付款后离开
商场 
{  合算（）；
   收款（）；

}


水平较低，敢于参与，就不错了，请大家指教

我也来掺和（只列主要的相互有交互的部分）：
商品类：
{
  价格等；
}

客户类：
{
  商品列表;  //商品类的集合
}

收银员类：
{
  收银方法（客户类）
}

仓库类等....

调查的目的是验证我的一个关于面向对象风格的设想。通过对于我qq和msn上的网友调查，我发现基本上都是会有：
商品－客户－售货员
这三个类。
我只是想知道是不是这是最普遍的方法，以决定我是不是需要给大家介绍一下另外的一种划分类的方式。

本来去哦觉得OO也是自然界的描述
!当然用自然的哦!

TSalesperson:Department,Duty;
TCustomer﹕CustomerType,PaymentType,DriveWay;
TCommodity:CommodityType,

to ozzzzzz:
我也觉得有其他方式，没有必要拘泥于现实存在的类，比如说一个交易类，等我想想再贴

Fusuli(大刀向鬼子们的头上砍去) 
方式很多，但是我想知道的是大家习惯的方式是什么。至少我就有好几种划分类的风格，而且有的还是非常有意思的风格。但是我想知道的是别人习惯于什么风格。

来乱说了:

商品类：
{
  价格等；
}

<<interface>> Payment; //支付方法类,保存客户如何支持;
ConcretePayment1;
ConcretePayment2;
...

<<interface>> Profit;  //优惠方法类,计算如何给客户优惠;
ConcreteProfit1;
ConcreteProfit2;
...

客户类：
{
  客户ID;
  一些记录;   //比如以往购物的记录(涉及如何给客户优惠的问题)
  商品列表;   //商品类的集合
  m_payment;  //一个支付方法类
  m_profit;   //优惠类
}

收银员类：
{
  收银（客户类）
}

很想听听 o6z的介绍, 期待中

另一种方法：
收银员类
{
员工号；
收银记录；
收银方法();
}

商品类
{
价格等；
}

购物车类
{
商品列表；//商品类的集合
}

发票类：
{
购物车类；
收银员类；
打印方法()；
修改库存方法()；
}

交易类：
{
购物车；
收银员；
开票()；//返回发票类
}

仓促之间的考虑，大家讨论；

我觉得这个类的划分不会有错误出现，所以大家只管说好了。我唯一的目的就是想知道凭直觉大家会怎么划分。因为在实际工作中大家往往都会很快掠过这个过程，而直接到实际设计中去了。
我唯一的目标就是了解你的直觉，不要受他人影响，告诉我你最初的感受。

呵呵，估计大部分人的直觉就直接去考虑数据库表的设计了，而不是对象的设计

Fusuli(大刀向鬼子们的头上砍去) 
从我调查的结果看刚好相反啊，人们考虑数据库总是在非常后面的事情，大家都是先看到对象。

我来说说我的分析
现在只有一个场景描述“客户到了，选择了商品，付款后离开”
首先从场景中提取名词（客户、商品、款）以得到领域模型的分析类。
我不知道为什么会得到“售货员”这个类，可能是大家习惯的思维模式，但是从这个场景中根本就没有，这可能是一个自动售货机等等，可能根本就没有“售货员”这个对象
然后就是“客户”，也许系统需求根本不要求记录客户信息，这个类根本不需要
我现在只能通过场景假设（这很危险，因为是分析人员凭空假设的）系统有记录交易这个需求，那么商品和款这两个类是系统必须出现的对象，而这时候也可以加上“记录”这个对象，记录相应商品和货款以及交易时间。
我只能分析出这3个类，具体的属性和方法就不再分析了
这是我的第一感觉，请版主指点

你问他们怎么找到类当然会到最后考虑数据库，如果你问给大家个场景，请设计一个程序来实现估计就有一部分人数据库先了:)
不过我接触的人不多，他们都是这样的，而且他们对自己的方法毫不怀疑。可能你我观察的范围不一样吧

zhaoxichao(小西) 
我现在不想指点谁，我只是想知道大家怎么想问题的，想知道大家的习惯。
记得前些天的关于是数据库在先还是对象在先的讨论吗？调查的结果是大家其实都习惯对象在先。
当然我还无法联系上gigix，我特别想知道他的习惯。嘿嘿。

Fusuli(大刀向鬼子们的头上砍去) 
你和他们自己都被他们骗了。其实人最开始还是在关注于名词概念，然后才会考虑数据库。其实名词还是他们的核心，其实还是对象是他们的核心。

数据库再先设计也不可能凭空出来，也是先ER分析，其实这时候也可以看成分析对象，Jacobson的类图和关联也是参考了ER图。
所以我的看法还是对象在先
这个帖子不需要再讨论这个问题了吧

zhaoxichao(小西) 
当然不需要，我只是在看看我是否准备一下明年推出一个COLOR UML的讲座。
如果按照现在的情况看，作这样一个推广工作还是很有用的。

一个简单的场景：客户到了，选择了商品，付款后离开。
请大家使用面向对象的方法，简单回答，你会找到什么类，类中会有什么方法，什么属性。简单回答就可以，我明白意思就可以了。
==========================================
概念:客户,商品,款
行为:到,选择,付款,离开
--------------------------------
类:客户,商品,付款
属性:
客户属性
 --姓名等
 ...
商品属性
 --商品名
 --价格
 ...
方法:
付款类方法:
 --付款
 --付款时间
 ...


这个问题也许还要看我们的系统具体的边界在哪吧!!
如果以营业员收款系统为观察点,那客户就不在系统边界内了,因为我们去沃尔码等地方,也并没有存储我们作为客户的信息

而如果以整个购物商品过程作为观察点.
那系统边界内应该包括客户这些信息

ozzzzzz:
如果你说地是逻辑层次的对象我同意你说地，我说的是物理实现层次的对象划分他们不考虑
小西：
讨论一下也无妨，这个板块好多天没有这么受关注的帖子了，就算是顶了一下也行呵:)

huarick(rick) 
我不想看你那么复杂的分析，但是你已经告诉我我想知道的。

Fusuli(大刀向鬼子们的头上砍去) 
不需要讨论了，因为大家现在还在消化那次讨论的过程。而且我觉得最后往往又成为哲学的问题了。还是让我调查结束，然后给大家讲讲面向对象的方法吧。

类:客户,商品,付款

收款机类,商品类,商品目录类,销售事件类

我还是喜欢最简单的方法：先用一句话描述需要建模的系统（你已经有了），然后抽出里面的名词就是类了，虽然很简单，但却很实用。

class 顾客
{

}

class 顾客
{
 付款（class 商品1，int 价格）
 所在地（class 商店1）
}
class 商品1
{
 Prop int 价格
 Prop char 名称
}
商店1
{
商店1（）{顾客到达}
~商店1（）{顾客离开}
}

我只了解两种分类：

一种与大家一样，按实体分类：顾客、商品、商店

另一种是按事件分类：达到、选择、交易、放弃

按实体分类，适用于一些对并发性要求不是很高的处理过程。
如果对并发性的要求比较高的话，则按事件分类的方式来处理。

class 人
{
属性：
　　性别；
　　年龄；
};

class 商品
{
属性：
　　名称；
　　标识；
　　单价；
};

class 客户 : public 人
{
方法:
　　到达商店；
　　选择商品；
　　付款；
　　离开商店；
};

不知道大家对《数字逻辑电路》这门课还有没有映象。

在《数字逻辑电路》中的主体思想就是事件驱动（状态转移）。

在《有限状态自动机》中，也是围绕事件驱动－－状态转移来阐述的。

这是一个如此简单的问题，以至于回答它是如此困难。
很多人都说需要有客户类。如果是一个B2C的电子商务网站，这没有问题。可是如果是一个面向零售行业的POS系统，能够和需要跟踪客户信息吗？不可能，也不需要。所以此时就不需要客户类。
商品类是需要的。但还不够。客户选择商品？如何选择？如果是网站，恐怕需要对商品进行分类，以供客户浏览、挑选。而如果是POS系统，那挑选商品的过程就在系统以外了。
付款，这涉及到一个大问题：对财务部分要考虑到怎样的程度。是需要有“财务科目”、“付款凭证”这样的类呢？还是只需要一个付款记录就可以了？
客户购买了商品，必然涉及到商店库存的变化，那么对库存我们又需要关心到什么程度呢？
所以对o6z所提出的这个简单场景要进行对象建模，缺少最重要的因素：我们到底关心什么？不了解这一点，是没法进行建模的。

BirdGu(鲲鹏) 
我提供了我能够提供的所有东西。而其实我唯一的目标就是想知道大家是不是都在使用名词法了寻找对象。从这一天的调查结果来看，和我的设想完全一致－－大家都是本者直觉先设立一个客户对象。这就够了，我很满意。但是我想这样的问题其实也会引起你们大家的一些思考，比如我在QQ上问了青润这个问题，他给我一个复杂的回答，但是本质还是名词系统的。
而我最近又拿起了我前一段时间已经放弃的USECASE，使用阎博士的泳道法来寻找对象。但是我虽然用泳道但是方法却和一般的朋友不同，我想和一些面向对象经验比较有基础的朋友就我的想法作讨论。而实际上color UML使我更加觉得有必要讨论面向对象风格的问题。

you caught me.

我的设计很简单。首先一个party模式，进门的顾客和门里的售货员都是party。party记录名字之类的静态信息，基本上没什么操作，尤其不会有“付款”之类的操作。然后是一个role object模式，顾客进门以后得到customer角色，售货员上班以后得到sale角色。恩，这也是一个基于名词系统的设计。

另外还需要一个事务型工作流，管理钱和货物的流转，以及开具发票之类的操作。我就想到这些。

mark

gigix(透明) 

我现在介绍一下我想这个问题的背景。前些天，我们这里讨论怎么寻找对象，阎博士谈到几种分析寻找对象的方法－－名词法、CRC法、RUP的泳道法。你也知道我是一个喜欢刨根问底的人，于是我就找到《软件工程》看看到底是怎么名词法的。其实很简单，就是在需求说明中找到名词、动词，然后把名词作为类、以及类的属性，动词作为方法。然后他们找到一个例子，用黑体字表示类。这个时候我忽然想到为什么一定要用名词作类名称，谁规定我就必须这样作。而我以前确实也没有这样作，我只是凭着我的直觉在解决问题。我现在有时间把以前做的事情好好总结，于是就有了这个问题。

我自己回答的话，我可能会有两个答案。当然我不能肯定我使用哪一个，这是我要去权衡的。

一个方案是：客户类，。。。。。。。
一个方案是：买东西类，这个时候客户是它的属性，商品是它的属性，时间这个属性有没有不是大问题，反正现在已经说明了问题。
方案一客户类会有一个方法买东西，而方案二则有一个属性客户。记得has a关系吗？如果沿着这条线索想下去，看看会有什么新的发现吗？

正襟危坐，把马甲换回来了。

首先分析一下你的“方案一”的缺陷——不是分析给o6z听的，当我自言自语好了。“客户类会有一个方法‘买东西’”，这就是一件挺糟糕的事情，因为你不知道这个对象跑到下一个场景可以做什么事情。我前面提到role object模式，就是这个目的：作为“人”，这个对象不知道自己下一分钟可以做什么；只有进入了那个场景，被赋予了那个角色，他才知道。

然后，如果深探role object模式在这里的实现，那么这个role object就不光是一个“角色的标记”——它本身就负责操作的实现，最多是给party一个回调（要按我的想法，这个回调都是不必要的，我会用动态类增强或者AOP来搞定）。假如在“商店”的场景里“顾客”只有“购买”这一个操作，那么你可以把role object看成一个command object。到这里，o6z，我们的方案基本走上同一条路了。

不过我不太喜欢你所谓的“从动词出发”。在我看来，“买东西类”其实就是一个角色。如果是用type 1 IoC，拥有这个角色的对象将实现“买able”接口。如果照我的想法，把“顾客”当作一个角色，角色的操作将包括“购买”、“退货”、“投诉”等等操作，每个操作可能是一个command object，这还是从名词出发的设计。你只不过是把每个操作孤立下来，只看这个command object了。

gigix(透明) 
嘿嘿！你开始了长篇大论，我想说你说的都是对的。但是你就是不按照我的思路去想下面的问题，而且我要说明的也只是分析问题时候遇到的类，是分析模型，不是设计模型。我们知道对象之间的关系有USE A，IS A，HAS A。那么到底上面的我的方案中的关系是什么呢？
我们知道HAS A两段的类是可以互相转换的，那么USE A是不是可以呢，这三种关系间是不是可以转化呢？这是我想到的第一个问题。
而显然买东西类是moment-interval archetype，我们沿着蓝色线下去就是role archetype，这个时候你发现了什么？下面是"party, place, or thing" archetype，然后是description archetype。是不是很有意思呢。（看看color UML）和方案一对照一下，你有什么结果。
现在你至少应该明白为什么together这么流行，但是color uml为什么不流行了。然而这还不是问题的全部，你会发现其实方法和属性的界限模糊起来，也就是行为特征和结构特征界限模糊起来。为什么会这样呢？
我还没有答案，难道唯一的解释就是不能用动词作分析类吗？但是这至少说明了为什么会有基于职责的建模。

我也来说几句，对象是依赖于“软件规模”的（这正是我不喜欢它的原因），楼主只说了业务场景而未约束软件规模，所以我只好提两套方案

一.顾客、备选商品、收银员
就这些，不多说了

二.顾客、备选商品、收银员、货款
货款类有三个子类：交易、清算和余额；顾客聚合余额类的实例
备选商品有一个已被订购的“修饰”

如果我做，也许就是
顾客 基本顾客属性，进入离开商店方法，
货物 基本货物属性，选择货物，购买货物方法，我可能放在货物里面。

从动词出发，我个人不是特别习惯，因为个人觉得比较复杂和零散，和常规思维不太符合，这样的系统比较难以理解。

为什么要把“购物”、“退货”、“投诉”这些作为“客户”的方法呢？到底什么是类的方法？
有一种对对象方法的理解是把方法看成对象能接受的消息，对象接受到消息后做出一定的响应。那么说“客户”接受“购物”、“退货”、“投诉”这样的消息合理吗？客户在得到这些消息后又能做出怎样的响应的。
我理解对象的方法是对象能对外提供的服务。这和对象能主动发起的行为是有区别的。

类分析的过程及时分析问题域中的概念的过程。寻找类的过程，也就是寻找问题域中的概念的过程。
由动词可不可以发现类呢？可以啊。动词名词化嘛！把动作作为一种概念抽象出来。Command Pattern虽然是个Design Pattern，也可以帮助我们理解这个问题吧？Fowler的Analysis Pattern中的Transaction Pattern算是把动作变为类了吧？

系统管理的业务功能需求不同，所检索的类，类中会有什么方法，什么属性等是不同的。

前面说得不好，现在我把交易类改成购物车类、去除余额类、然后把清算认为是收银员类的方法

改写后如果是小规模软件的话，将有三个类
购物车、备选商品、收银员
另外有一个消费者类从购物车类中继承



如果是大规模如下：
一备选商品　　Goods
　　无效　　　Goods::ObjectIsBad
　　备选　　　Goods::ObjectIsReady
　　订购　　　Goods::ObjectIsOrdered
　　出货　　　Goods::ObjectIsSaled
　　状态通知　AskForStatusChange(enum statusNew)
　　价格　　　price as CreditPoint
二商品目录　　GoodsShelf，所有ObjectIsReady 状态中的Goods 的列表

三购物车　　　GoodsList
　　无效　　　GoodsList::ObjectIsBad
　　筹备　　　GoodsList::ObjectIsReady
　　下单　　　GoodsList::ObjectIsOrdering
　　清算　　　GoodsList::ObjectIsLiquidated
　　状态通知　AskForStatusChange(enum statusNew)
　　选购　　　ObjectIsReady_AddGoods (Goods aGoods)
　　放弃选购　ObjectIsReady_RemoveGoods (Goods aGoods)
四消费者　　　Customer，零个或多个购物车
　　开始选购　CreateGoodsList ()
　　放弃选购　DiscardGoodsList (GoodsList someGoods)
　　查看　　　LookOverAllTheGoods (GoodsShelf allTheGoods)

五消费力　　　CreditPoint
六收银员　　　CashRegister
　　清算　　　Liquidate (GoodsList someGoods, CreditPoint money)



Goods::price 属性中也可能被要求附加上商品的折扣规则
CashRegister::Liquidate 方法也可能会产生一个帐单／发票类型的日志数据

［把折扣规则理解为CreditPoint，是运用了“修饰模式”］
［Goods，Customer，CashRegister还具有其它属性］

前几天忙，都没上网，现在来交考卷，权当补考吧。
分析用例我没怎么做过，谈不上习惯，看了大家的发言，就说说我的感觉吧，如果楼主真要做调查统计，就不要算我，呵呵。

首先我觉得这是一个高层用例，还不到设计类的地步，如果非要，我会提取出以下关键词（我才不管它是名词还是动词，只要我觉得关键）：客户、到、选择商品、付款、离开。这里面，到和离开与本系统无关（当然有些系统会有关），不在考虑范围内。客户当然是一个实体类，选择商品和付款应该是两个用例，还需进一步研究。至于什么销售员呀、信用卡呀、pos机呀都是研究了后两个用例发现的，就当前的用例描述，只能得到小西所说的客户、商品、款三个领域对象。当然我们也可以把选择商品和付款看成两个控制类，这就与o6z所说的方案二走到一块了。就这个用例，我不赞成就把选择商品和付款看成控制类，还应当作用例，做进一步的研究。选择商品不复杂，当作控制类或边界类可以说得过去，但至少付款不应该直接当作控制类，这大概就是粒度问题了。

如需要服务员先出付款通知，则付款是动作，付款通知、服务员、收款人才是类。

场景必须与系统管理的业务功能需求相结合进行检索类、类中会有什么方法及什么属性等信息。单以一个场景分析类、类中会有什么方法及什么属性等，就相当于上学时写作业，凭想当然了。