在整理了“渲染器在游戏中的架构”问题后，开始准备找个小项目练习下《UML基础、案例与应用》一书中提供的开发方法。这将对UML进行更大程度的练习。
练习用的DEMO是一个贪食蛇游戏。
这个练习项目在编码部分完成DEMO后我决定结束它。因为设计部分已经做完，而后面要写的代码已经没任何难度，并且和以前的项目有太多的相似之处。
可能是练习的项目太小了的缘故，按照这种新的开发方法学进行设计，有很多步骤都感觉没有必要！例如绘制顺序图，协作图，以及用例图。
在设计类图之前绘制的活动图，感觉而言就是用来进行需求收集的。这里的活动图目的是拿来了解业务过程，确实算是一种需求收集。
事实上，在以往的项目中（SuperTux以后），设计类图之前进行的一切活动都是在进行需求收集，目的是为了让开发者得到系统的足够信息，要能很容易地抽象出类图，以及设计出每一个类。这些活动包括：问题描述；系统运作描述；问题域中每个物体的具体描述（这些物体很大程度上会成为以后抽象出的类）；系统模块划分（相当于高层类图）。
在设计类图时，一般会进行多次迭代。把握的原则是由粗到细。设计完整体类图后，还要对每个类进行单独的描述，相当于设计类的属性和方法。
设计完类图后，通常还会设计一幅系统运作图，也就相当于活动图。这主要是为了搞清游戏运行过程中最为复杂的逻辑，好让编码时有依据。
然后就可以开始编码。
而在这个新的开发方法学中，很多步骤其本质只是在于换了种描述方式而已，即换成用UML图表来描述。例如设计类图之前的活动图，就相当于理清了系统的运作过程。
总之，个人觉得，在设计详细类图之前进行的一切活动都是在为设计类图做准备。包括对象的状态图。而在设计完类图之后设计的顺序图协作图之类，则是在验证设计的类图是否正确合理。
可以粗略地把握这么一个原则：类图是编码前的必需品，其他一切活动（编码之前）都是为了设计类图而做的准备。
类图设计完后应该设计一些活动图，来描述系统的一些比较复杂的逻辑，这样有利于编码。
也就是说，在编码之前需要准备的东西就有：详细类图；详细活动图。
|