第二章介绍组件之间相互传递消息，第三章介绍组件的组合与协作关系，本章则介绍组件的行为。
消息激发组件的行为，行为塑造组件的新关系和状态。
设计软件就是要充分描述组件的行为，掌握组件协作关系，灵活传递消息。
捕捉对象行为应关心的是：事件（Event）、状态（State）和动作（Action）。
事件是外来的刺激。
状态是对象特性的总合，包括静态及动态特性。如：电梯最大载重量是静态特性，电梯目前在第几层楼是动态特性。
动作是有时间和状态共同决定的行为。
事件、状态和动作是如何联系在一起的呢？
我们看个简单的例子：
爱人移情别恋了（事件），则痴情者心碎了（状态改变了），竟然吃香蕉皮了（行为也改变了）。
我们先以电梯为例来看下可能的设计方式：
图一：
图二： 图三：
如果我们关注电梯的使用频率，显然图一最能展示我们关注的信息；
如果我们关注电梯是否故障，显然图二最能展示我们关注的信息；
如果我们是正在等待电梯的乘客，显然图三最能展示我们关注的信息。
所以，以上状态设计都没有错。
由上述例子，我们得知设计状态并非要去找系统本质上有多少种状态，而是要看分为哪些状态最能帮助组织您的软件程序，以达到控制系统的目标。
我们使用UML的 状态转换图 来表达事件、状态与动作。
通过前一节讲述的方法确定状态后，跟状态改变相关的事件和动作也就确定了。
我们用下图的形式来展示事件、状态与动作：
以下还是以电梯为例：
电梯有两个状态：故障维修、正常使用；
电梯正常使用（状态）时，发生故障（事件），则通知维修人员（动作），同时电梯转变为故障维修（状态）；
电梯故障维修（状态）时，维修完成了（事件），则电梯转变为正常使用（状态）。
