1,265
社区成员
发帖
与我相关
我的任务
分享关于状态转换图到类图的转换
现在有如下状态转换图
员工雇用系统
apply→hired（hourly salaried commissioned）→fired
很多细节我略去了
问题是apply指向的是hired的三个子状态，而fired却是从hired状态转换得到了
另外还有一个休假状态，从hired转换后又转换为hired（并没有明确是哪个子状态）
请问在类设计中，如何去处理子状态呢？谢谢各位大神
员工雇用系统
apply→hired（hourly salaried commissioned）→fired
很多细节我略去了
问题是apply指向的是hired的三个子状态，而fired却是从hired状态转换得到了
另外还有一个休假状态，从hired转换后又转换为hired（并没有明确是哪个子状态）
请问在类设计中，如何去处理子状态呢？谢谢各位大神
...全文
请发表友善的回复…
发表回复
光脚满地跑 2012-04-02
- 打赏
- 举报
多谢解答，受益匪浅，明白了
^_^
^_^
以专业开发人员为伍 2012-04-02
- 打赏
- 举报
比如说我们来描述“病人”在住院部跟门诊部之间的转换，可能住院部病人在一些特定时期要临时转门诊部去做检查，然后住院部再决定病人下一步治疗方案。在这样一个大的背景下，住院部病人因为所住的“科”不同，可能也有不同的治疗流程。我觉得没有必要把这两层设计纠结在一个大的状态流程图上去嵌套显示。我们只要知道，不管住院部如何治疗病人，都遵循作为一个普通住院病人的流程而跟门诊部打交道，这就是你那个图中的“黑箱”跟它的右边的分层关系。
我没有仔细看你的状态图。许多状态图都是一些人“抠字眼”而根据对象的属性、类型而生搬硬套出来的。如果你仔细研究每一个状态转移连线是否是不同的事件触发，是否是要描述独立、结果不会有分支的状态，就能用自己的眼睛看出那种状态都是否实用。其实状态图是非常有用的，但是不知道这个诀窍也实在是看不懂它。关键诀窍就是：创意是不应该有分支的。
当你发现一个状态描述有分支，那么就是分析不到位，所以理解起来就会稀里糊涂。
我没有仔细看你的状态图。许多状态图都是一些人“抠字眼”而根据对象的属性、类型而生搬硬套出来的。如果你仔细研究每一个状态转移连线是否是不同的事件触发，是否是要描述独立、结果不会有分支的状态，就能用自己的眼睛看出那种状态都是否实用。其实状态图是非常有用的，但是不知道这个诀窍也实在是看不懂它。关键诀窍就是：创意是不应该有分支的。
当你发现一个状态描述有分支，那么就是分析不到位，所以理解起来就会稀里糊涂。
以专业开发人员为伍 2012-04-02
- 打赏
- 举报
所谓状态设计，其实是状态“类”设计，并不是状态实例。
系统每当有一个动作，哪怕是一个循环，状态也是勇往直前不会回头的。这就好像赫拉克利特说的“人不能两次踏入同一条河流”，永远不会重复。但是为了抽象地用符号来表示，我们可以把同一个动作、并且其结果不会有分支的东西，叫做状态。比如说同样是送给一个人100万块钱，假设我们想说出会有三种不同的结果，那么这就要把“给一个人100万块钱”这个事件的后果区分为三种状态。
但是假如说把这三种状态（以及它们之间的转化）放到一个“黑盒子”里边，在一下子弄出什么从父状态的转换，其实我觉得是烦琐的，没有必要。
实际上状态的抽象化没有必要。不论是状态图，还是计算用的功能图，等等，都可以因为对象的继承和多态而抽象。但是这就没有必要在状态图上再搞什么抽象。子类的状态如果比父类更复杂，可以单独写一个小的状态转移图。假设说想描述子类对象虽然扩展的属性不同，但是它们都会因为父类定义的某些属性为条件而经历某些事件、转移到新的状态，实际上你把父类的状态图画一个，再把子类中紧紧围绕扩展属性的变化（而不影响从父类继承的属性的变化）单独画一个图就行了。我认为没有必要硬要嵌套到一个图上去。
系统每当有一个动作，哪怕是一个循环，状态也是勇往直前不会回头的。这就好像赫拉克利特说的“人不能两次踏入同一条河流”，永远不会重复。但是为了抽象地用符号来表示，我们可以把同一个动作、并且其结果不会有分支的东西，叫做状态。比如说同样是送给一个人100万块钱，假设我们想说出会有三种不同的结果，那么这就要把“给一个人100万块钱”这个事件的后果区分为三种状态。
但是假如说把这三种状态（以及它们之间的转化）放到一个“黑盒子”里边，在一下子弄出什么从父状态的转换，其实我觉得是烦琐的，没有必要。
实际上状态的抽象化没有必要。不论是状态图，还是计算用的功能图，等等，都可以因为对象的继承和多态而抽象。但是这就没有必要在状态图上再搞什么抽象。子类的状态如果比父类更复杂，可以单独写一个小的状态转移图。假设说想描述子类对象虽然扩展的属性不同，但是它们都会因为父类定义的某些属性为条件而经历某些事件、转移到新的状态，实际上你把父类的状态图画一个，再把子类中紧紧围绕扩展属性的变化（而不影响从父类继承的属性的变化）单独画一个图就行了。我认为没有必要硬要嵌套到一个图上去。
以专业开发人员为伍 2012-04-02
- 打赏
- 举报
我不知道你说的“子状态”是个什么概念。我跟你说一些更基础、更通用的知识。
对状态贴一些标签，往往跟它的动作有关系，往往是用“动词+名词”的方式来说明状态，而不是说一种静态的类型名称或者属性值来标记状态，属性值枚举值具有什么hire之类的，纯粹是某种状态下具有此值，但是不能说凡是具有此值的就是此种状态。
让我们拿上面的“积木世界”的行为来说，我们可以把一个积木从一处移动到另外一处，条件是积木上面再没有其它积木压住，并且目的地（其它积木或者是地面）上面是空的。这个积木世界是最简单的状态转移设计范例，每一次移动一块积木都是改变了状态而产生新的状态。再举一个最简单的状态转移的例子，比如说拨电话号码，比如说我拨号码8088，这里有四个状态，我们拨第二个号码8的时候状态跟拨第一个8时显然不同，这就好像你第二次踏入同一条河流时跟上一次踏入它显然不同。状态就好象是电影胶片，不管它推演是的什么样的历史进程，哪怕的蒙太奇，但是电影胶片永远是一条直线勇往直前的不再回头的，每一个胶片格子都代表了上一个状态的了解和县一个状态的开始，而假设要给状态归类的话我们可以用促使旧状态变为新状态的时的触发的动作来说明，这样状态都跟活动图就有了联系。
当一个动作结束，对象有很多属性，分别可能有不同的值，比如说电话线和能有“电压”属性，也可能有“电流”属性，也可能有“彩铃设置”属性，也可能有“分机号”属性，等等。你打算用什么作为状态分类名称？
实际上用什么属性值来作为状态分类名称，总是围绕着动作而改变的。例如上面的拨号8088，当拨第一个号码8之后，电话听筒中的初始提示音消失了，而变成了“滴”的一声短提示音，可是我们拨最后一个8之后，电话听筒中的提示音变成了振铃音（对方分机正在振铃），可见同一个状态已经不够了，因为任何状态都应该有一个独立的、没有分支的功能描述，所以同样是两次拨号，我们必须根据两个动作的结果不同而给出两个不同的状态分类来。由于这类分析，才产生了状态。
在一个系统中，状态当然是越少越好，一边简化开发。但是如果该描述用户需求的状态你没有考虑到，你的分析就是不到位的。这种矛盾的解决就是艺术的体现。所以没有必要搞什么“子状态”时就不要搞繁琐，而需要独立分解不同的状态时，则独立分解状态（例如上述同样是拨号动作需要分解出两类状态出来）。
状态首先是依赖于行为动作，然后行为动作不足以产生独立的、没有分支的功能描述，所以才分解出真正的状态。不要一上来就用对象的属性的枚举值、或者对象的类型名来描述状态。后一种简单地用名词来“抠字眼”得到状态图的做法，其实会产生很多没有意义的状态图，而忽略重要的状态图，最后还是一头雾水。
对状态贴一些标签，往往跟它的动作有关系，往往是用“动词+名词”的方式来说明状态，而不是说一种静态的类型名称或者属性值来标记状态，属性值枚举值具有什么hire之类的，纯粹是某种状态下具有此值，但是不能说凡是具有此值的就是此种状态。
让我们拿上面的“积木世界”的行为来说，我们可以把一个积木从一处移动到另外一处，条件是积木上面再没有其它积木压住，并且目的地（其它积木或者是地面）上面是空的。这个积木世界是最简单的状态转移设计范例，每一次移动一块积木都是改变了状态而产生新的状态。再举一个最简单的状态转移的例子，比如说拨电话号码，比如说我拨号码8088，这里有四个状态，我们拨第二个号码8的时候状态跟拨第一个8时显然不同，这就好像你第二次踏入同一条河流时跟上一次踏入它显然不同。状态就好象是电影胶片，不管它推演是的什么样的历史进程，哪怕的蒙太奇，但是电影胶片永远是一条直线勇往直前的不再回头的，每一个胶片格子都代表了上一个状态的了解和县一个状态的开始，而假设要给状态归类的话我们可以用促使旧状态变为新状态的时的触发的动作来说明，这样状态都跟活动图就有了联系。
当一个动作结束，对象有很多属性，分别可能有不同的值，比如说电话线和能有“电压”属性，也可能有“电流”属性，也可能有“彩铃设置”属性，也可能有“分机号”属性，等等。你打算用什么作为状态分类名称？
实际上用什么属性值来作为状态分类名称，总是围绕着动作而改变的。例如上面的拨号8088，当拨第一个号码8之后，电话听筒中的初始提示音消失了，而变成了“滴”的一声短提示音，可是我们拨最后一个8之后，电话听筒中的提示音变成了振铃音（对方分机正在振铃），可见同一个状态已经不够了，因为任何状态都应该有一个独立的、没有分支的功能描述，所以同样是两次拨号，我们必须根据两个动作的结果不同而给出两个不同的状态分类来。由于这类分析，才产生了状态。
在一个系统中，状态当然是越少越好，一边简化开发。但是如果该描述用户需求的状态你没有考虑到，你的分析就是不到位的。这种矛盾的解决就是艺术的体现。所以没有必要搞什么“子状态”时就不要搞繁琐，而需要独立分解不同的状态时，则独立分解状态（例如上述同样是拨号动作需要分解出两类状态出来）。
状态首先是依赖于行为动作，然后行为动作不足以产生独立的、没有分支的功能描述，所以才分解出真正的状态。不要一上来就用对象的属性的枚举值、或者对象的类型名来描述状态。后一种简单地用名词来“抠字眼”得到状态图的做法，其实会产生很多没有意义的状态图，而忽略重要的状态图，最后还是一头雾水。
光脚满地跑 2012-04-02
- 打赏
- 举报
光脚满地跑 2012-04-02
- 打赏
- 举报
嗯，首先有实例，然后才有实例的状态变化，受教了
如果知道这样的图，可否反推出类的可能结构呢
这是我们软测课堂的一个例子
要求是构造出类，然后描述状态，再然后描述状态转换，做一个测试用例
感觉无从下手呢
以专业开发人员为伍 2012-04-02
- 打赏
- 举报
状态图得到类图？没有分类，哪来的状态？
你的状态到底是什么呢？你到底如何标记状态呢？难道是用一个string字段胡乱标记一下这就叫做状态？
比如说我们来“搭积木”，我们把A放在B上面，把C放在B旁边的地面上，然后我们把A从B上拿起来放到了C上面，这就是从一种状态变到另外一种状态。这里先知道了类型（积木）然后考虑了状态变化。这不是什么用一个名字去胡乱起一个状态名就叫状态了。如果你是先用一个名字来代表状态然后才去考虑类型设计的问题，我想你最好把状态图先忘记了吧。
你的状态到底是什么呢？你到底如何标记状态呢？难道是用一个string字段胡乱标记一下这就叫做状态？
比如说我们来“搭积木”，我们把A放在B上面，把C放在B旁边的地面上，然后我们把A从B上拿起来放到了C上面，这就是从一种状态变到另外一种状态。这里先知道了类型（积木）然后考虑了状态变化。这不是什么用一个名字去胡乱起一个状态名就叫状态了。如果你是先用一个名字来代表状态然后才去考虑类型设计的问题，我想你最好把状态图先忘记了吧。
