3系统分析-状态图.ppt

* * 9. 建模技巧/2 在实时系统中，状态机可以用于进程（capsules）和协议 (确定实现协议的对象需要满足的状态) 并不是所有的对象都需要状态机. 如果对象的行为是简单的，比如说它只是简单的存储和获取数据，对象的行为是状态不变的（state-invariant ），那么其状态机就没有多少意义 对对象的生命周期的建模涉及到三件事情: 描述对象需要响应的事件 对这些事件的响应 过去对当前行为的影响 对对象的生命周期的建模也涉及到决定对象响应事件的次序，这种响应始于对象的创建时刻，继续直到其销毁 * * 9. 建模技巧/3 为了对对象的生命周期进行建模: 确定状态机的背景， 是类，用例，还是整个系统 如果背景是类或者是一个用例，收集邻近的类，包括父类或者通过关联或依赖关系能够到达的类，这些邻居是动作的可能的目标，或者是保安条件中包含的内容 如果背景是整个系统，将焦点放在系统的某一个行为上，然后考虑对象在该方面的生命周期。整个系统的生命周期太大了。 建立对象的初始和最终状态，如果对于初始和最终状态有前置条件或后置条件，也要定义它们 * * 确定对象能够响应的事件，它们可以从对象的接口中找到，在实时系统中，它们可以从对象的协议中找到 从初始状态到最终状态，画出对象的最高层的状态，将这些状态用转移连接起来，这些连接由特定的事件触发 确定进入和退出动作 通过使用子状态能够扩展和简化状态机 * * 9. 建模技巧/4 检查 是否状态机中所有的事件触发转换与由对象实现的接口所期望的事件匹配 所有的对象接口期望的事件都包含在状态机中 在实时系统中，对进程的协议进行同样的检查。 确定那些明确希望忽略事件的地方 （例如延迟事件） * * 是否状态机中的所有的动作得到了包含的对象的关系、方法和操作支持 在状态图中进行跟踪检查，将它与期待的事件和响应的顺序进行比较，搜索那些到达不了的状态和“死锁”状态 在调整状态机图时，确保语义不变 * * 9. 建模技巧/5 在有选择的情形下，尽量使用状态机的可视化语义而不是写详细的转移说明。例如，不要在一个转移上列出多个信号，然后用文字说明依据不同的信号来管理不同的控制流；代之以单独的转移，由单独的信号触发。 * * 9. 建模技巧/6 状态命名根据在一个状态中等待或发生的情况来确定。记住，状态不是一个“时间点”，它是状态机等待什么事发生的一段时间。例如 ‘waitingForEnd’ 就比‘end’好; ‘timingSomeActivity’ 就比‘timeout’好. 不要把状态命名成动作 * * 9. 建模技巧/7 一致性命名。给状态机中的每一个状态和转换一个唯一的名字；这将使源代码级的调试更容易 小心使用状态变量 (控制行为的属性) * * 9. 建模技巧/8 如果一个图上5 ± 2状态，考虑使用子状态。 一般而言，在通常的情况下十个状态可能没有问题，但是两个状态之间却有四十个转换肯定需要重新考虑。我们需要保证状态图是容易理解的 根据触发事件和/或在转换上发生的情况来命名转换。在选择名字时，也需要从可理解性的角度出发 * * 9. 建模技巧/9 当你看到一个选择点，你需要问一下是否能够将选择条件的责任分配给另外一个组件。在这种情况下，发送者或者其它活动者进行决策，并将带有决策信息的信号发送给另外一个对象，该信号的名字要带有决策信息，例如信号的名字为isFull和isEmpty，而不应该是 value 和checking message data) * * 9. 建模技巧/10 选择点的命名：在选择点处的回答问题的命名要采用描述性的方法例如，‘isThereStillLife’或者isItTimeToComplain 选择点名字是唯一的：对任何对象，尽力保证选择点的名字是唯一的 (同样，保持转换的名字是唯一的) 转换的表达不能过长：如果过长，需要考虑用函数，或者将公共的代码片断用函数表示，转换必须读起来象高层的伪代码，例如，如果转换上的代码长于25行，可能就太长了 * * 9. 建模技巧/11 动作根据它们的任务命名 注意entry和exit动作，很容易发生修改后，忘了修改它们 退出动作可以提供安全特性，例如从‘heaterOn’到heater off状态之间的退出动作，该动作就用以确保状态转换 * * 9. 建模技巧/12 子状态必须包含两个或以上状态，除非状态机是抽象的并将被包含的元素的子类所修饰 选择点必须被用于在动作或转换的条件逻辑的场合。选择点容易被看到，而在代码中表达的条件逻辑是隐藏的，容易被忽略 * * 9. 建模技巧/13 避免下列保安条件： 如果一个事件能触发多个转换，没有一个控制确定对哪一个保安条件首先进行判断，这样的情况下，结果是不可预测的 多个