Dominoo

在面向引用的OO编程语言中，相等性（Equality）操作有两种：
1、判断两个引用本身是否相等；
2、判断两个引用所引用的对象是否相等。

事实上，第二种操作是第一种操作的超集。因为，如果两个引用本身相等，则两个对象一定是相同的，当然也是相等的；但反之则不然。

对于第一种操作，执行起来非常简单。但第二种操作则相对复杂，需要程序员的指定或干涉。在Java中，具体表现为程序员需要为一个class编写equals方法。

两个对象本身的相等性应该具备下列性质：
o Reflexive：即对象应该等于自身，也就是第一种相等性操作；
o Symmetric：对称性，即 a equals b 意味着 b euqals a；
o Transitive：传递性，如果 a equals b，b equals c，则a equals c；
o Consistent：一致性，在对象内容没有变化的情况下，两个对象之间进行多次比较时，结果应该是一致的。

对象本身的相等性判断，是高度模式化的操作。两个对象之间的相等性，在绝大多数情况下，其实是对象所包含的部分或全部属性之间的相等性。基于这种现实，我们应该把相等性判断的操作交给编译器去做。

首先，并非所有的class都需要进行对象内容的相等性判断，所以程序员可以指定一个class是否是compareable的，像这样：

public compareable class Foo{
   ...
}

编译器只对声明了compareable的class生成内容相等性判断的代码。如果目标代码是Java的话，则只为声明为compareable的class生成equals方法。对于这种class的对象，就可以对其进行内容相等性判断，比如：

Foo foo1 = new Foo();
Foo foo2 = new Foo();

if(foo1 == foo2) // 引用相等性判断，返回false
   ...

if(foo1 equals foo2) // equals是关键字，用以进行内容相等性判断
   ...

只有声明为compareable的类及其子类的对象，才能进行equals操作。编译器会检测这一点。

其次，在对两个compareable class的对象进行内容相等性判断时，并非所有属性都需要对比。所以应该允许程序员指定需要对比的属性。像这样：

public compareable class Foo {
   private compareable int value;
   private compareable string name;
   private int dummy;

   ...
}

在这个例子中，在对两个Foo对象进行相等性判断时，应该仅仅对value和name的值进行对比，由于dummy不是compareable的，所以无需对其进行相等性判断。

如果一个属性被指定为compareable的，则属性所属的类型必须是compareable的。否则编译器需要给出错误。对于基本类型，比如int, boolean, string, real等，默认就是compareable的，由于object是所有class的root class，所以object不是compareable的。比如：

public compareable class Foo {
   private compareable int value; // valid
   private Exam exam;   // Invalid, because class Exam isn't compareable.
}

public class Exam {
   ...
}

如果一个class的super class是被声明为compareable，则其默认就是compareable的；其相等性判断算法等同于super class。比如：

public compreable class Base {
   public compareable int value = 10;
}

public class Derived extends Base{
}

Base base = new Base();
Derived derived = new Derived();

if(base equals derived) // return true
   ...

但是，如果它想扩展super class的相等性判断算法，仍然必须明确声明为compareable的。比如：

public compreable class Base {
   public compareable int value = 10;
}

// Invalid，因为它新指定了属性name为compareable的，
// 所以Derived也必须被明确指定为compareable的。

public class Derived extends Base{
   public compareable string name;
   ...
}

还有一种情况，如果你想让一个类在内容相等性上区别于它的父类，也可以通过明确指定自身为compareable的来完成。例如：

public compreable class Base {
   public compareable int value = 10;
}

public compareable class Derived extends Base{
}

Base base = new Base();
Derived derived = new Derived();

if(base equals derived) // return false，既然Derived也有自己的compareable声明。
   ...

对于集合性质的属性，如果被指定为compareable的，首先集合元素的类型应该是compareable的，其次，集合内元素的数量如果不相等，则两个集合肯定是不相等的。然后需要比较集合内的元素，此时，需要分为不同的情况来处理。

集合通过两种属性（ordered, unique）分为四类：
1、Set (non-ordered, unique)
2、OrderedSet (ordered, unique)
3、Bag (non-ordered, non-unique)
4、Sequence ( ordered, non-unique)

首先如果集合的类型如果不相同，则两个集合肯定是不相等的。

o 对于Set，我们通过判断一个Set中的元素是否包含在另外一个Set中来确定其相等性。
o 对于OrderedSet和Sequence，我们根据顺序依次判断两个集合中元素的相等性。
o 对于Bag的处理要相对复杂一些，我们首先对一个Bag进行过滤操作，把其重复的元素去掉，然后计算每一个非重复元素的数量，得到结果后，通过判断另外一个Bag中的非重复元素的数量是否匹配，得出相等性。

以上所描述的方法都是模式化的，这些都可以利用编译器进行自动代码生成。但有时候，相等性判断是非常特殊的操作。比如下面的Java代码：

public class Foo {
   private int value;
   private string name;

   public boolean equals(Object object) {
      ...
      Foo foo = (Foo)object;
      if(value < 0) {
          if(foo.value > 0)
  return false;
      }
      else {
 if( foo.value != this.value)
     return false;
      }

      return foo.name.equals(this.age);
   }
   ...
}

对于这些特殊情况，我们应该允许程序员来自定义特殊的相等性判断函数。可以像这样：

public compareable class Foo {
   private int value;
   private compareable string name;

   equals {
     this.value < 0 implies rhs.value < 0;
     this.value > 0 implies this.value == rhs.value;
   }

   ...
}

在我们的解决方案中，我们仍然可以指定那些无需特殊处理的属性为compareable的，对于特殊处理的条件，我们可以在equals block中，通过OCL boolean表达式来指定判断条件。在这些表达式都满足的情况下，再对指定为compareable的属性进行默认的相等性判断，以最后的结果来决定两个对象之间的相等性。

我们希望能够尽量避免让程序员编写模式化的操作，通过这些解决方案，应该可以很好的解决相等性模式代码生成的问题。

在UML的class图中，class与class之间可以存在关联(Association)，它意味着，关联两端的类的实例（Instance）之间，或者类与实例之间（如果一个Association End是静态的）可以建立起link。而Link操作正是为了这一目的而存在的。

1. 语法

Link操作的语法为：

1. relate <object instance handle> to <object instance handle> [ across <association specification> ]
2. relate <object instance handle> to <class> [ across <association specification> ]
3. relate <object instance handle> to <object instance handle> [ across <association specification> ] using <object instance handle>

当两个类之间存在关联，关联的两端都不是静态的，就使用第一种语法。
当两个类之间存在关联，并且关联的一端是静态的（两端都是静态的关联是非法的），则是用第二种语法。
当两个类之间存在一个关联类（关联类的关联两端不能使静态的），则使用第三种语法。

其中,association specification的形式为:

R<number>
r<number>
R<number>.<role>
r<number>.<role>

o 普通关联

如果两个类之间存在着普通关联，当设计师需要将两个类实例通过这个普通关联link起来时，使用第一种语法。比如：

 |--------|    R1   |-------|
 |   A    |---------|   B   |
 |--------| 1      *|-------|

 create object instance a of A;
 create object instance b of B;
 relate a to b across R1;

o 静态关联

如果两个类之间存在着静态关联,则使用第2种语法.例如:

 |--------|      R1    *|-------|
 |   A    |------------>|   B   |
 |--------|     all bars|-------|
               
create object instace b of B;
relate b to A across R1.'all bars';

o 关联类

如果两个类之间存在一个关联类,你必须使用之前所述的第三种语法,即必须通过using指明关联类的实例. 比如:

 |--------|    R1   |-------|
 |   A    |---------|   B   |
 |--------| 1  |   *|-------|
               |
               |
          |---------|
          |    C    |
          |---------|

 create object instance a of A;
 create object instance b of B;
 create object instance c of C;
 relate a to b across R1 using c;

2. association specification

上述3种语法中的across部分，并非在任何情况下都是需要的，在不引起二义性的情况下，我们可以尽量的简化。下面我们就各种不同的情况来逐一讨论。

o 单一关联

如果两个类之间只存在一个关联，在进行link操作时，你无需指定association specification. 比如：

 |--------|    R1   |-------|
 |   A    |---------|   B   |
 |--------| 1      *|-------|

图中，class A和B之间仅仅只存在关联R1，当你执行A和B的实例之间的link操作时，不需要指定association specification，编译器为自动识别这一点。比如：

 create object instance a of A;
 create object instance b of B;
 // relate a to b across R1;
 relate a to b;

o 多个关联

如果两个类之间存在一个以上的关联，在进行link操作时，你必须指定association specification. 比如：

 |--------|     R1    |-------|
 |        |-----------|       |
 |        | 1       * |       |
 |   A    |     R2    |   B   |
 |        |-----------|       |
 |        | *     0..1|       |
 |--------|           |-------|

这种情况，如果不指定association specification，编译器无从知道需要在两者之间建立那种link，这就会引起二义性。此时，设计师需要明确的指定association specification。比如：

 create object instance a of A;
 create object instance b of B;
 relate a to b across R2;

两个类之间存在的关联也应该把它们的super class的关联计算在内，比如：

 |--------|        |-------|
 |   B0   |<|------|   B   |
 |--------|        |-------|
     | 1               |*
   R1|               R2|
     | *               |0..1
 |--------|        |-------|
 |   A0   |<|------|   A   |
 |--------|        |-------|

以及这种情况:
 
 |--------|        |-------|
 |   B0   |<|------|   B   |
 |--------|        |-------|
     | 1               |*
   R1|               R2|
     |                 |0..1
     |             |-------|
     |-------------|   A   |
                 * |-------|

这两个例子中,Class A和B之间的关联数量都为2,在link A和B的实例时,都必须指定Association specification.

或许你会建议,在这些情况下, 如果不指定association specification,可以认为设计师的意图是在两个实例之间建立所有的link,这样做看起来合情合理,但事实上存在很大的问题. 这是因为:

1.在现实的模型中,如果两个类之间存在多个关联,往往从语义上,这些关联基本上不会同时出现在同样的两个实例之间.
2.给设计师提供了更多由于疏忽而造成错误的机会.

如果设计师确实想在两个实例之间建立起所有可能存在的link,它必须亲自逐个的执行link操作.

o 自关联

如果关联存在于在两个不同的类之间,当你指定association specification的时候,你只需要制定关联的名字.但,如果一个关联是一个自关联,

你首先必须使用association specification,其次你还必须在association specification中指名角色.

例如:

 |------------|
 |            |
 |     A      | parent
 |            |------|
 |            |0..1  |
 |------------|      |
       *| children   | R1
        |            |
        |------------|

依据这张图,如果你想将class A的两个实例a和b通过R1连接起来,你必须制定它们二者所需要扮演的角色,否则会引起二义性. 比如:

 create object instance a of A;
 create object instance b of A;
 // a is a child of b
 relate a to b across R1.children;

最后一条语句指明了,在a和b建立起的新的连接中,a扮演的角色是children,b扮演的则是parent.

o 普通关联,关联类和静态关联

需要特别指明的是,普通关联,关联类和静态关联是三种不同的关联,在考虑是否会引起二义性的时候,需要分开考虑.例如:

 |--------|    R1  1..*|---------|
 |        |------------|         |
 |        |            |         |
 |        |     R2   * |         |
 |   A    |----------->|    B    |
 |        |        bars|         |
 |        |     R3     |         |
 |        |------------|         |
 |--------|     |      |---------|
                |
           |----------|
           |    C     |
           |----------|

在这个例子中，class A和B之间存在三个关联，其中：
R1是普通关联；
R2是静态关联；
R3是关联类。
尽管A,B之间存在三个关联，但由于他们的类型不同，所以我们对他们进行关联的操作的时候，无需指定association specification。如下：

create object instance a1 of A;
create object instance b1 of B;
// relate a1 to b1 across R1;
relate a1 to b1;

create object instance b2 of B;
// relate b2 to B accross R2;
relate b2 to B;

create object instance a3 of A;
create object instance b3 of B;
create object instance c  of C;
// relate a3 to b3 across R3 using c;
relate a3 to b3 using c;

多重性

组合（Composite）有很强的整体与部分关系语义，一个被组合的对象最多能够被一个组合对象拥有。这意味着，组合端的多重性(Multiplicity)只能为0..1或1..1，其它的多重性都是不符合语义的。

如下图所示（由于用文本作图无法直观的表现出组合关系，所以我们用聚合来表示组合）：

|------| 1     *|-------|
|  A   |<>------|   B   |
|------|        |-------|

|------|0..1   *|-------|
|  A   |<>------|   B   |
|------|        |-------|

一个Class上的多个组合

另外，一个class可能被超过一个其它class组合，比如：

|------| 1     *|-------|*    0..1|-------|
|  A   |<>------|   B   |-------<>|   C   |
|------|        |-------|         |-------|

这种情况下，并不表示一个B的实例能够同时被一个A的实例和C的实例拥有；而是说，一个B的实例要么被一个A的实例拥有，要么被一个C的实例拥有，或者干脆谁也不拥有（因为C端的多重性为0..1）。换句话说，如果一个class被多个其它class组合，那么这些组合关联之间存在着Exclusive的约束。更进一步，如果所有的聚合端的多重性都为1，那么这些组合关联之间存在着XOR约束（Exclusive OR）。

自组合

关于组合的一个有趣的问题是，一个Class可不可以自组合，比如：

|-------| 1
|       |<>--|
|   A   |    |
|       |----|
|-------| 1..*

如果一个对象可以组合同一class的其它实例，并且被组合端的多重性的最小数量大于0（比如1..*, 1..5, 2），那么就会造成无穷的递归问题。因为对象一级的组合链绝对不能形成环，否则就违背了组合的语义，其他类型的关联不直接包含这样的语义。

但是，如果被组合端多重性的最小数量为0（比如*，0..1, 0..5），那么Class自身的组合关系是允许的。因为对象级别的拥有关系存在终止条件。

自组合的一个变形是：
                         |--------|
                      |--|    B   |
                      |  |--------|
|----------------|    |
|                |<|--|
|                |    |
|                |    |    |--------|
|       A        |    |----|        |
|                |1..*     |   C    |
|                |-------<>|        |
|                |         |--------|
|----------------|

这种关系下，C is a A，但C组合了A，由于B is also a A，所以，在这种关系下，由于存在着对象组合链存在着终止条件，所以即使被组合端的多重性的最小值大于1，这种关系仍然是合法的。