ICONIX过程

《用例驱动的UML对象建模应用－范例分析》这本书在大半年前就接触过了，当时是为了编写用例文档，从王老师那里搞到的。最近在做的即时消息系统的失败（没能按时交付），让自己深感一个合适的软件过程在项目开放中的重要地位。固重新找来这本书，好好温习。以下是对ICONIX的摘录：

ICONIX过程的规模介于RUP和XP之间。也RUP一样，ICONIX也是用例驱动的，但不需要RUP使记录延续到表中带来的巨大开销；和XP一样，相对较小，比较紧凑，但不像XP那样摒弃了分析和设计过程。ICONIX是一种高效的UML建模方法，它力图使用UML的一个子集来表达整个开发过程。从整体上来说，ICONIX的动态模型包含用例模型、健壮性图、时序图，静态模型部分包含域模型和类图。在整个软件过程中，用例驱动了整个动态模型的推进，而动态模型的完善驱动了静态模型的推进，最后，根据模型编写出代码。
ICONIX提倡在项目开始阶段，就因该构建域模型和用例模型，其中用例模型驱动了整个动态模型，而域模型则驱动着整个静态模型。从另一个角度看，动态模型又驱动静态模型的完善。所以，整个系统都是有用例直接或间接驱动的。用例驱动，也就是说软件的体系结构和设计方案都是通过分析使用场景推断出来的。
 
                                                             （ICONIX过程）

Step1：获取需求－域建模
  域建模是UML模型的静态部分的基础。建立域模型时，首先确定真实世界中的抽象，即系统中将涉及的主要概念性对象。设计OO软件时，应根据这些实际问题空间对象设计软件的结构。这里的思想是，同软件需求相比，真是世界发生变化的频率更低。域建模起一个术语表的作用，用例编写者可以在编写用例的早期就使用它。
  在确定对象的同时，也可以确定他们之间的关系（泛化和聚集）。域建模的重点是确定对象以及他们之间的关系，对于对象的属性和方法，都是以后详细设计的议题。域类的最佳来源很可能是高级问题陈述、低级需求和问题空间的专业知识。要发现域类，首先从这些来源中挖掘尽可能多的相关陈述（名词和名词短语会成为对象和属性；动词和动词短语会成为操作和关联）。快速的构建域模型，并期望在以后的工作中将其逐步完善。

10种常见的域建模错误
＃10.立即给关联指定多重性，确保每个关联都有明确的多重性。不因该在域建模期间就指定多重性，这将占用大量的时间，事导致分析瘫痪的主要原因之一。
＃9. 对名词和动词的分析过渡，而背离初衷。多度的分析会使设计处于过低的抽象层次，同时有神经崩溃的危险>_<
＃8.不对用例和时序图进行研究，就将操作分配给类。不因该在域建模期间将任何操作分配给类，因为目前还没有足够的信息可以作出正确的决策。
＃7.在确保已满足用户需求之前，对代码进行优化以提高重用性。要实现完整性和重用性，需考虑属性和操作，但目前没有这些信息，所以将过多精力用于提供类的可重用性并不明智。
＃6.对于每个“...部分（part of）”关联，就使用聚集还是组合而争论不休。在域建模期间统一使用聚集即可，至于要区分他们，等到详细设计的时候吧。
＃5.未对问题空间进行建模前，就假定一种具体的实现策略。在高级类图中