该是基本数据类型（如整形、浮点型、布尔型、字符串型）。如果一个属性是复 杂数据类型（可以进一步分成多个数据项的数据），最好把它作为单独的类，然 后将这两个类关联起来。 2.关联的添加 关联刻画了两个类结构方面的联系。那么，我们需要把所有可能的关联关系 都刻画出来吗？显然并不必要。因为从某种意义上讲，世界上的万事万物都是关 联的，小世界定理甚至告诉我们世界上任意两个人只要通过不多于六个中间人就 可以联系起来。那么我们需要添加什么样的关联关系呢？以下为一些指南： (1)添加那些重要的、需要持续一段时间的关联信息： (2)添加那些能够表示聚合、组合这种“整体-部分"关系的关联信息； (3)在此阶段，我们只要从领域知识出发来考虑关联，并不需要考虑关联将来 如何在软件中实现的问题： (4)不要添加那些可以从其他关系中推导出来的关联关系。 完整的关联信息包括了：关联的方向、关联的名字、多重性、角色。 3.对象模型的精化 对象模型的构建并不是一次完成的。我们应该对建立的对象模型进行多次重 新检查并在必要的时候进行模型的调整。 在模型中可能会发现如下问题： 1) 重复的定义：由于我们通过多种渠道（如通过文本分析、构建交互图、依 据领域知识等)去识别类，因此有时候可能将一个类重复定义了两次，或 者将同一属性、同一操作定义了两次，我们需要将它们进行合并： 2)应该建模为类的属性，或者不必要作为类的属性：有些属性类型比较复杂， 或者有相应的操作与其关联，那么最好将其建模为类，而相反，有些类只 有很少的属性，并且只有写入和读取的操作，那么就可以简化其为属性。 随着分析的深入，可能会发现以下情况从而可以建立类之间的“泛化-例化” 结构： 1) 一个概念在现实中可以分成子类型，并且子类型具有不同的行为，那么可 以将子类型建模成子类。但是值得注意的是，并不是在现实中的子类型都 需要建模成子类，过于复杂的继承结构也会造成软件的复杂，因此只有在 子类型对于应用有意义时，才需要建模成子类。 2) 发现多个类具有共同点，因此抽象出一个父类。通过抽象出的父类，并定该是基本数据类型（如整形、浮点型、布尔型、字符串型）。如果一个属性是复 杂数据类型（可以进一步分成多个数据项的数据），最好把它作为单独的类，然 后将这两个类关联起来。 2. 关联的添加 关联刻画了两个类结构方面的联系。那么，我们需要把所有可能的关联关系 都刻画出来吗？显然并不必要。因为从某种意义上讲，世界上的万事万物都是关 联的，小世界定理甚至告诉我们世界上任意两个人只要通过不多于六个中间人就 可以联系起来。那么我们需要添加什么样的关联关系呢？以下为一些指南： （1） 添加那些重要的、需要持续一段时间的关联信息； （2） 添加那些能够表示聚合、组合这种“整体-部分”关系的关联信息； （3） 在此阶段，我们只要从领域知识出发来考虑关联，并不需要考虑关联将来 如何在软件中实现的问题； （4） 不要添加那些可以从其他关系中推导出来的关联关系。 完整的关联信息包括了：关联的方向、关联的名字、多重性、角色。 3. 对象模型的精化 对象模型的构建并不是一次完成的。我们应该对建立的对象模型进行多次重 新检查并在必要的时候进行模型的调整。 在模型中可能会发现如下问题： 1） 重复的定义：由于我们通过多种渠道（如通过文本分析、构建交互图、依 据领域知识等）去识别类，因此有时候可能将一个类重复定义了两次，或 者将同一属性、同一操作定义了两次，我们需要将它们进行合并； 2） 应该建模为类的属性，或者不必要作为类的属性：有些属性类型比较复杂， 或者有相应的操作与其关联，那么最好将其建模为类，而相反，有些类只 有很少的属性，并且只有写入和读取的操作，那么就可以简化其为属性。 随着分析的深入，可能会发现以下情况从而可以建立类之间的“泛化-例化” 结构： 1） 一个概念在现实中可以分成子类型，并且子类型具有不同的行为，那么可 以将子类型建模成子类。但是值得注意的是，并不是在现实中的子类型都 需要建模成子类，过于复杂的继承结构也会造成软件的复杂，因此只有在 子类型对于应用有意义时，才需要建模成子类。 2） 发现多个类具有共同点，因此抽象出一个父类。通过抽象出的父类，并定