UML is organized around the object-oriented concept of namespace, which refers to a collection of objects to be treated as a named group. The architecture of object-oriented programming is predicated on this concept. The problem with this, however—as described above in the section on relationships—is that it makes it extremely difficult to treat a subject/predicate/object as a logical unit, since the object class cannot be contained in the namespace that is the subject class. A “property” of the subject class is the rolename only, without the class that is being named. For example, in Figure 2-11, above, “an example of” can be a property of Internal Organization, but “an example of Internal Organization Type” cannot. Moreover, since in the object-oriented world, there can be no duplicate role names, there could not also be “an example of Internal Organization Class”, or some such—even though the total meaning of the predicate is not duplicated. Here is another place where the architectural entity/relationship modeler must part company from the object-oriented designer.A bunch of words dreamed up by the utterly deranged