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.未对问题空间进行建模前，就假定一种具体的实现策略。在高级类图中，不因该涉及具体技术内容。
＃4.将类命名为难以理解的名字，而不是直观名字。
＃3.直接进入到实现结构，如友元关系和参数化类。这些东西与解决方案空间相关，而与问题空间无关，域建模绝对是属于问题空间的。
＃2.在域类和关系型数据库表之间建立一对一映射。关系数据库表中很多属性不能照搬到对象模型环境中，应该尽可能通过聚集，将属性组转换为‘助手（helper）’类。这种类包含的属性和操作可被组合成更小的‘部分（piece-part）’类。
＃1.过早地执行‘模式化’，这将导致根据同用户问题毫无关系的模式创建解决方案。模式通常在健壮性分析的时候才能发现。

Step2：获取需求－用例建模
  为新系统创建用例的任务因该是这样完成的：首先确定尽可能多的用例，然后不断地编写和改经描述这些用例的文本。在这一过程中，将发现新的用例和通用情况。确定用例时必须切记一个最重要的原则：他们必须同系统用户手册中的材料密切相关。每个用户和用户指南的各个部分间的关系必须是显而易见的。也就是说，必须从用户的角度设计系统。同时这也是对用例驱动的含义做了总结，首先编写用户手册，然后编写代码。
  用例文本的基本格式因该是‘名词－动词－名词’。当发现新对象的时候，因该及时更新域模型。对于每个用例，尽可能考虑到各种可能的分支，这需要大量的时间。
 
  一些对于用例的建议
  1。创建一个用例模版，其中只包含‘基本流程’和‘分支流程’。不要放入其他内容，他们只会分散我们的注意力。
  2。提出问题‘将发生什么？’，进入基本流程。
  3。提出问题‘然后将如何？’，不断提出这样的问题，知道获得有关基本流程的所有细节。
  4。提出问题‘否则将如何？’，是否还可能发生其他情况？确定吗？不断提出这些问题，直到记录下来   大量分支流程为止。

  这里的目标不是构建完美的用例，而是考虑用户可能执行的各种操作。对系统行为的定义越完美，构建系统的工作将越容易。这里，Rosenberg还推荐将用例分组分包，因为包为小组间分配工作提供了逻辑边界。同时，一条不错的规则是：每个包因该对应于用户手册的一章或者至少一个大节。

10种最常见的用例建模错误
＃10.编写功能性需求，而不是编写使用场景文本。需求通常表述为系统应具备的功能，而使用场景描述的是用户执行操作以及系统作出的响应。最终，我们的用例文本将作为系统运行阶段行为的规范（文本将被放置在时序图的左边）。因此，（主动语态的）使用描述（行为）和（被动语态的）系统需求之间必须有清晰的界限。
＃9.描述属性和方法而不是使用情况。用例文本不因该包含过多的细节，但也不因该没有任何关于屏幕字段的细节。字段名通常直接对应于域类中的属性名，所以，在用例中不应该命名或描述方法，用例说明的是系统将如何完成工作，而不是系统将完成什么工作。
＃8.编写用例过于简洁。对于用例文本来说，冗长更胜于简洁。用户手册将基于用例文本，对编写用户文档而言，细节过多总比不足强。
＃7.让自己同用户界面完全脱离。
＃6.不给边界对象提供明确的名称。边界对象（boundary object）是参与者与之交互的对象，通常包括窗口，屏幕，对话筐和菜单。为包含足够细节并明确指出用户的导航情况，必须在用例文本中明确的对边界对象命名。
＃5.不从用户的角度进行编写，并使用被动语态。从用户的角度，使用主动语态编写的用例文本效率是最高的。
＃4.止描述用户交互，而忽略系统作出的响应。用例描述的是对话双方（用户－系统）以及我们自己试图发现的发生在系统中的所有软件行为。遗漏系统的响应，也就忽略了软件行为。
＃3.不描述操作的分之流程文本。
＃2.不将重点放在用例的内部，而是放在如何到达这里或以后将发生的情况。Rosenberg认为冗长的模版是在浪费时间（包含前置条件，后置条件等等）。
＃1.花一个月的时间来决定使用包含结构还是扩展结构。选择哪一种并不重要，重要的是因该选择一种机制，并一直使用它。与一种结构相比，同时使用两种结构更糟糕，因为容易混淆并陷入困境。

Step3：里程碑1－需求复核
  需求复核旨在确保用例和域模型一道满足客户的功能性需求，同时确保客户知道开发小组将根据这些需求做何种设计。需求复核必须有客户代表、开发小组代表和经理参加，目标是在各方之间就已有的用例、域模型和原型元素达成基本一致，以确定系统的功能需求。

10种最常见的需求复核错误
＃10.根本不进行需求复核，而是让编码人员随心所裕地编写。汗...
＃9. 不确保用例文本符合所需的系统行为。
＃8.不使用任何GUI圆形或屏幕模型来帮助验证系统行为。
＃7.用例高度抽象，让不懂技术的客户就像在看天书。客户不可能在它不理解的用例上签字。
＃6.不确保裕模型准确的反映真实世界的概念性对象。
＃5.不确保用例文本参考域对象。
＃4.不质疑不包含任何分支流程的用例。90％以上的好用例都包含至少一个分之流程。
＃3.不质疑每个用例是否考虑到了所有的分之流程。
＃2.不管用例是否是用被动语态书写的。
＃1.不管用例是否占4页的篇幅。避免过长的用例模版。

Step4：需求的健康检查－健壮性分析
 在软件开发中，最难解决的问题之一是，从‘什么’视图演变到‘如何’视图，健壮性分析正是一种帮助人们完成这项工作的技术。在ICONIX过程中，这种简单但很有用的技术在分析（什么）和设计（如何）之间架起了一座至关重要的桥梁。我们通过健壮性图进行健壮性分析：先绘制健壮性图，仔细检查用例文本，检查每一个句子，然后根据句子的描述绘制出参与者、边界对象、实体对象和控制器以及图中不同元素间的关系。然后复核健壮性图，通过观察用例文本和图是否‘图文一致’来发现问题，修改用例文本，当然也要修改静态模型。在这个阶段，因该把一些关键属性添加到类图中。健壮性图是一个类图，由三种图例组成：
    边界对象（boundary object）：参与者使用它来同系统交互，通常包含窗口、屏幕、对话筐和菜单。可以从GUI原型和用例文本中找出边界对象。
    实体对象（entity objct）：通常是来自域模型中的对象，常对应于数据表和文件。
    控制对象（control object）：将边界对象和实体对象关联起来（通常叫控制器，因为他们一般不是正真的对象）。它包含大部分应用程序逻辑，比如经常修改的业务规则和策略。控制器偶尔会是设计中的‘真正的对象’，然而大部分时间里，它只是一个占位符，用于避免我们遗漏用例要求的任何功能和系统行为。
  在初步设计阶段，应仔细考虑各种可供选择的设计策略和技术体系结构。此时，应开始找出与系统性能相关的问题。在健壮性分析期间，我们将以需求级用例文本为基础，做出一些初步设计方面的假设。
  对健壮性图，必须遵守如下4条规则：
  参与者只同边界对象交互。
  边界对象只能同控制器和参与者交互。
  实体对象只能同控制器交互。
  控制器可同边界对象、实体对象以及其他控制器交互，但不能和参与者交互。

  健壮性分析要素
  1。它是对用例文本的一次健康检查，帮助确保用例文本的正确性，且没有指定不合理或不可能的系统行为。这种改进使用例文本的特性从纯粹的用户手册角度变成为对象模型上下文中的使用描述。
  2。帮助确保用例考虑到了所有必须的分支流程。把这件事情放在健壮性图上完成，将使得绘制时序图可以节省3～4倍的时间。
  3。发现在域建模中遗漏的对象。发现对象命名冲突等问题。同时确保在绘制时序图之前确定了大部分的实体类的边界类。
  4。缩小分析和设计之间的鸿沟，从而完成系统的初步设计。

  10种最常见的健壮性分析错误
  #10.违反一种或多种健壮性分析规则。
  #9.不使用健壮性分析来帮助我们在用例文本中采用一致的格式。通过分析可以确保用例文本都是以‘主－谓－宾’的句子格式描述的。
  #8.健壮性图中不包含分支流程。
  #7.不使用健壮性分析来确保类图和用例文本中的类名一致。
  #6.给健壮性图中的类分配属性。目前还没有足够的信息，因该等到时序图的时候。
  #5.包含的控制器过多或过少。Rosenberg建议每个图包含2～5个控制器，如果控制器草过10个，因该考虑将用例分解。
  #4.试图使健壮性图十全十美，而花费过多时间。健壮性图只充当辅助引擎，它驱动用例向前发展，成为一个OO的设计方案。当我们完成这个任务后，就不需要它了。
  #3.试图在健壮性图上完成详细设计。临时图的概念对初步设计很有用，但对详细设计没任何用处。
  #2.不在用例文本和健壮性图之间进行可视化跟踪。
  #1.不更新静态模型。

Step5：里程碑2－初步设计复核
  初步设计复核（PDR）指的是对要构建的每个场景的健壮性图和用例文本进行复核，确保他们一致，并完善、正确的表现了系统的行为。PDR也应该有客户代表、开发小组代表和经理参加。一个重要的区别是，这时客户修改其需求的最后机会，，之后开发人员根据指定的用例向前推进，最终编写出代码。PDR是一个分水岭，过了该分水岭之后，客户的主动参与将不再受欢迎。

  10种最常见的PDR错误
  #10.不确保客户知道这是他们修改行为的最后机会，之后将开始构建系统。
  #9.不确保用例文本和健壮性图之间的一致性。
  #8.不确保将新的实体对象加入到域模型中。
  #7.不考虑域类的属性。对一组用例进行健壮性分析时，应获得域模型中的类的完整属性集。
  #6.期望PDR期间已经将操作分配给了类。
  #5.不再次向客户重申，用例文本是开发人员和客户之间的契约。
  #4.要求在初步静态设计中大量使用设计模式。找出健壮性图中的模式，尤其是那些容易对应到已有的设计模式的模式或自己发明的模式是对的。但将健壮性图中出现的简单的初步设计模式扩展为详细设计模式却是错误的。后一种工作应该留到时序图和高级类图中去完成。
  #3.不对健壮性分析的名词、动词规则进行复核。
  #2.期望健壮性图中包含完整的详细设计而不是概念设计。
  #1.仔细复核健壮性图中每个箭头的方向，而不是进行快速跟踪以核实是否考虑到了所有的行为。

Step6：详细设计－时序图
  健壮性分析旨在发现对象，而详细设计则主要是关于分配行为：将确定的软件操作（函数、方法）分配给发现的一组对象。时序图是详细设计的核心，也是系统动态模型的核心。
 
  ICONIX方式绘制时序图的步骤
  1。复制用例文本，粘贴到页面的左边。
  2。加入健壮性图中的实体对象。
  3。加入健壮性图中的边界对象和参与者。
  4。将方法分配给类。这时需要将健壮性图中的控制器转换为一组执行所需行为的方法和消息（有时候，控制器也可能转换为一个控制对象）。

  10种最常见的时序图错误
  #10.不为每个用例绘制一个时序图。只有为每个用例中的所有事件流程绘制交互图后，才能确定自己找出系统要求每一个对象扮演的角色，即每个对象的职责。
  #9.不将用例文本添加到时序图中。
  #8.不首先在健壮性图上确定所有必须的对象。
  #7.不在用例文本和消息箭头之间提供可视化跟踪。
  #6.不说明对象间的通信管道，让时序图表示高级抽象。健壮性图上无需说明对象间的通信管道，因为他们反映的是初步设计。然而编码将根据时序图来完成，因此需要极其详细的说明实际的设计方案。
  #5.将时序图绘制成流程图，而不是使用它在对象间分配行为。
  #4.不将重点放在有趣的方法上，而是放在getter、setter上。
  #3.不仔细考虑消息箭头的起点（即特定时间内，哪个对象拥有控制权）。
  #2.通过绘制消息箭头 分配行为时，不遵循职责驱动的OOD这一基本原则。对象只能有一种‘性格’，应避免对象有‘精神分裂症’。常常自问：该方法分配给该对象是否是最合适的，该方法完成的任务是否同该对象明显有关。
  #1.不为每个用例包绘制本地类图，以更新静态模型。绘制本地化静态类图，以列出解决方案空间对象和问题空间对象是一个不错的主意。一条不错的知道原则是，对每一个用例包，绘制一个本地类图。静态模型可能很庞大，无法在一张易于阅读的途中完全表现出来。

Step7：里程碑3－关键设计复核
关键设计复核（CDR）旨在确保详细设计的‘如何’同用例指定的‘什么’完全一致，同时确保详细设计足够详细，并可根据它来编写代码。对于CDR，差不多所有的设计人员和开发人员都必须参加。

  10种最常见的CDR错误
  #10.邀请不懂技术的客户参与这种设计复核。
  #9.不对照时序图仔细地检查用例文本。
  #8.不仔细检查每个时序图中所有消息箭头的起点和终点。对于不连贯的时序图，没办法用于指导编码。
  #7.复核时序图时，不仔细考虑面向对象的设计原则。
  #6.不根据‘高品质类’标准对静态模型进行复核。
  #5.不考虑细节。
  #4.不考虑设计模式在设计中是否有用。
  #3.允许漠视诸如DCOM或EJB等实现技术的‘总体’时序图的存在。此刻应该尽可能缩短从详细设计进入实现时需要跨越的距离。
  #2.不复核当前版本中要构建的所有场景的时序图。
  #1.编写代码之前不关系细节，认为重构代码可以修复所有的问题。
 

 ICONIX的作者Dong Rosenberg在建模方面有着丰富的经验，书中描述的ICONIX也顺利成章的方便快捷。但是自己对它还是有些疑问。书中Rosenberg好像没对ICONIX的迭代过程进行过较详细的描述，还有就是在画健壮性图的时候总感觉不大自然，估计还是因为经验不足吧Orz。