按钮处理模块的状态图，在前面的文章中已经说明过了，但是当我们对信号系统引擎建模时，发现当初的设计并不能满足需求，所以需要对已经完成的模型进行修改。
这样的修改在软件开发过程中经常出现，需要做的不是抑制这种修改，而是让这种修改尽量早的发生。这也是建模的一个作用。
在前面的例子中，希望将停止按钮和行人通过请求按钮用一个时序图表达出来，结果导致两种情况都不合适。本文采用另一种策略：
- 设计标准按钮处理的状态图，停止按钮可以适用该状态图
- 行人通过请求按钮模块对标准按钮模块进行扩展
标准按钮模块状态机
Work状态
装置工作状态，在这个状态中包含有效和无效两个子状态。Work状态中如果接受到Shutdown要求，则迁移到完了状态。从UML状态机的语义来讲，无论状态处于Working的那个子状态，上述迁移都有效。
Disable状态
设备不接受用户按钮操作。接受到DeviceEnable事件之后，向Enable状态迁移。
Enable状态
接受DeviceDisable事件以后，向Disable状态迁移；接收到按钮按下事件时，向Disable状态迁移，但同时发送按钮按下事件。
如果和之前的按钮装置状态图比较，应该可以看出这个方案更清晰，重点也更突出。
行人通过请求按钮状态机
首先和标准按钮模块状态图进行一下比较，可以看出区别在于Enable状态又进一步细化，同时相应的迁移也发生了变化。以下只说明增加的部分。
LaterReportWait状态
本状态中如果用户按下按钮，不会立即发送按钮按下事件，而是向CmdReady状态迁移。如果接收到SetInstantReport通知，则向InstantReportWait状态迁移。
InstantReportWait状态
本状态中接收到按钮按下事件时，向Disable状态迁移，但同时发送按钮按下事件。
CmdReady状态
进入本状态就意味着，用户按下了请求按钮。当接收到HandlerReady事件时，向Disable状态迁移，但同时发送按钮按下事件。
补充说明
虽然文章发出的次序有先后，但实际上信号系统引擎模块和行人通过请求按钮模块和的状态图是同时设计，同时完成的。当然也可以先后完成。
在前一篇说明按钮模块的文章中设计的状态图虽然被大幅度修改的，但是面向对象的思想却是不变的。
参考资料：
14.2 Behavior StateMachines (6)--子状态机状态
14.2 Behavior StateMachines (10) --记法
打开方法如下:
- 进入【面向对象思考】 公众号
- 打开【UML】-【UML2.5中文译文】菜单
- 选择【状态图】分类
- 选择相关文章
写在文章的最后
阅读更多更新文章，请扫描下面二维码，关注微信公众号【面向对象思考】
