PowerTypes


The contents of the PowerTypes package is shown below. The PowerTypes package is one of the packages of the Classes package.

In order to locate the metaclasses that are referenced from this package,

· See "Classifier (from Kernel, Dependencies, PowerTypes)" .
· See "Generalization (from Kernel, PowerTypes)" .
· See "PackageableElement (from Kernel)".

  Classifier (from PowerTypes)


See "Classifier (from Kernel, Dependencies, PowerTypes)".

  Generalization (from PowerTypes)


See "Generalization (from Kernel, PowerTypes)".

  GeneralizationSet (from PowerTypes)


A GeneralizationSet is an AutonomousElement (from Foundation :: Kernel :: PackagingNamespaces) whose instances define partitioned sets of Generalization relationships.

Description

Each Generalization is a binary relationship that relates a specific Classifier to a more general Classifier (i.e., a subclass). Each GeneralizationSet defines a particular set of Generalization relationships that describe the way in which a specific Classifier (or superclass) may be partitioned. For example, a GeneralizationSet could define a partitioning of the class Person into two subclasses: Male Person and Female Person. Here, the GeneralizationSet would associate two instances of Generalization.

Both instances would have Person as the specific classifier, however one Generalization would involve Male Person as the general Classifier and the other would involve Female Person as the general classifier. In other words, the class Person can here be said to be partitioned into two subclasses: Male Person and Female Person. Person could also be partitioned into North American Person, Asian Person, European Person, or something else. This partitioning would define a different
GeneralizationSet that would associate with three other Generalization relationships. All three would have Person as the specific Classifier; only the general classifiers would differ: i.e., North AmericanPerson, Asian Person, and European Person.

Attributes

  • isCovering : Boolean
Indicates (via the associated Generalizations) whether or not the set of specific Classifiers are covering for a particular general classifier. When isCovering is true, every instance of a particular general Classifier is also an instance of at least one of its specific Classifiers for the GeneralizationSet. When isCovering is false, there are one or more instances of the particular general Classifier that are not instances of at least one of its specific Classifiers defined for the GeneralizationSet. For example, Person could have two Generalization relationships each with a different specific Classifier: Male Person and Female Person. This GeneralizationSet would be covering because every instance of Person would be an instance of Male Person or Female Person. In contrast, Person could have a three Generalization relationships involving three specific Classifiers: North AmericanPerson, Asian Person, and European Person. This GeneralizationSet would not be covering because there are instances of Person for which these three specific Classifiers do not apply. The first example, then, could be read: any Person would be specialized as either being a Male Person or a Female Person--and nothing else; the second could be read: any Person would be specialized as being North American Person, Asian Person, European Person, or something else.
  • isDisjoint : Boolean
Indicates whether or not the set of specific Classifiers in a Generalization relationship have instance in common. If isDisjoint is true, the specific Classifiers for a particular GeneralizationSet have no members in common; that is, their intersection is empty. If isDisjoint is false, the specific Classifiers in a particular GeneralizationSet have one or more members in common; that is, their intersection is not empty. For example, Person could have two Generalization relationships, each with the different specific Classifier: Manager or Staff. This would be disjoint because every instance of Person must either be a Manager or Staff. In contrast, Person could have two Generalization relationships involving two specific (and non-covering) Classifiers: Sales Person and Manager. This GeneralizationSet would not be disjoint because there are instances of Person which can be a Sales Person and a Manager.

Associations


Constraints

[1] Every Generalization associated with a particular GeneralizationSet must have the same general Classifier.

[2] The Classifier that maps to a GeneralizationSet may neither be a specific nor a general Classifier in any of the Generalization relationships defined for that GeneralizationSet. In other words, a power type may not be an instance of itself nor mayits instances be its subclasses.

Semantics

The generalizationSet association designates the partition to which the Generalization link belongs. All of the Generalization links that share a given general Classifier are divided into disjoint sets (that is, partitions) using the generalizationSet association. Each partition represents an orthogonal dimension of specialization of the general Classifier.

As mentioned above, in essence, a power type is a class whose instances are subclasses of another class. Power types, then, are metaclasses with an extra twist: the instances are also be subclasses. The powertype association relates a classifier to the instances of that classifier--which are the specific classifiers identified for a GeneralizationSet. For example, the Bank

Account Type classifier could associate with a Generalization relationship that has specific classifiers of Checking Account and Savings Account. Here, then, Checking Account and Savings Account are instances of Bank Account Type. Furthermore, if the Generalization relationship has a general classifier of Bank Account, then Checking Account and Savings Account are also subclasses of Bank Account. Therefore, Checking Account and Savings Account are both instances of Bank Account

Type and subclasses of Bank Account. (For more explanation and examples, see Examples in the Generalization section, below.)

Notation

The notation to express the grouping of Generalizations into GeneralizationSets were presented in the Notation section of Generalization, above. To indicate whether or not a generalization set is covering and disjoint, each set should be labeled with one of the constraints indicated below.

{complete, disjoint} - Indicates the generalization set is covering and its specific Classifiers have no common instances
{incomplete, disjoint} - Indicates the generalization set is not covering and its specific Classifiers have no common instances*
{complete, overlapping} - Indicates the generalization set is covering and its specific Classifiers do share common instances
{incomplete, overlapping} - Indicates the generalization set is not covering and its specific Classifiers do share common instances


*Default is {incomplete, disjoint}

Figure 69 - Generalization set constraint notation



Power type specification is indicated by placing the name of the powertype Classifier--preceded by a colon--next the GeneralizationSet graphically containing the specific classifiers that are the instances of the power type. The illustration below indicates how this would appear for both the "shared arrowhead" and the "dashed-line" notation. for GeneralizationSets.



Examples

In the illustration below, the Person class can be specialized as either a Female Person or a Male Person. Because this partitioning, or GeneralizationSet, is constrained to be complete and disjoint, each instance of Person must either be a Female Person or a Male Person; that is, it must be one or the other and not both. (Therefore, Person is an abstract class because a Person object may not exist without being either a Female Person or a Male Person.) Furthermore, Person's can be specialized as an Employee. The generalization set here is expressed as {incomplete, disjoint}, which means that instances of Persons can be partitioned as Employees or some other unnamed collection that consists of all non-Employee instances. In other words, Persons can either be an Employee or in the complement of Employee, and not both. Taken together, the diagram indicates that a Person may be 1) either a Male Person or Female Person, and 2) an Employee or not. When expressed in this manner, it is possible to partition the instances of a classifier using a disjunctive normal form (DNF).



Grouping the objects in our world by categories, or classes, is an important technique for organizations. For instance, one of the ways botanists organize trees is by species. In this way, each tree we see can be classified as an American elm, sugar maple, apricot, saguaro--or some other species of tree. The class diagram below expresses that each Tree Species classifies zero or more instances of Tree, and each Tree is classified as exactly one Tree Species. For example, one of the instances of  Tree could be the tree in your front yard, the tree in your neighbor's backyard, or trees at your local nursery. Instances of Tree Species, such as sugar maple and apricot. Furthermore, this figure indicates the relationships that exist between these two sets of objects. For instance, the tree in your front yard might be classified as a sugar maple, your neighbor's tree as an apricot, and so on. This class diagram expresses that each Tree Species classifies zero or more instances of Tree, and each Tree is classified as exactly one Tree Species. It also indicates that each Tree Species is identified with a Leaf Pattern and has a general location in any number of Geographic Locations. For example, the saguaro cactus has leaves reduced to large spines and is generally found in southern Arizona and northern Sonora. Additionally, this figure indicates each Tree has an actual location at a particular Geographic Location. In this way, a particular tree could be classified as a saguaro and be located in Phoenix, Arizona.

Lastly, this diagrams illustrates that Tree is subtyped as American Elm, Sugar Maple, Apricot, or Saguaro--or something else. Each subtype, then, can have its own specialized properties. For instance, each Sugar Maple could have a yearly maple sugar yield of some given quantity, each Saguaro could be inhabited by zero or more instances of a Gila Woodpecker, and so on. At first glance, it would seem that a modeler should only use either the Tree Species class or the subclasses of Tree--since the instances of Tree Species are the same as the subclasses of tree. In other words, it seems redundant to represent both on the
same diagram. Furthermore, having both would seem to cause potential diagram maintenance issues. For instance, if botanists got together and decided that the American elm should no longer be a species of tree, the American Elm object would then be removed as an instance of Tree Species. To maintain the integrity of our model in such a situation, the American Elm subtype of Tree must also be removed. Additionally, if a new species were added as a subtype of Tree, that new species would have to be added as an instance of Tree Species. The same kind of situation exists if the name of a tree species were changed--both the
subtype of Tree and the instance of Tree Species would have to be modified accordingly.

As it turns out, this seemis redunadancy is not a redundancy semantically (although it may be implemented that way). different modeling approaches depicted above are not really all that different. In reality, the subtypes of Tree and the instances of Tree Species are the same objects. In other words, the subtypes of Tree are instances of Tree Species. Furthermore, the instances of  Tree Species are the subtypes of Tree. The fact that an instance of Tree Species is called sugar maple and a subtype of Tree is called Sugar Maple is no coincidence. The sugar maple instance and Sugar Maple subtype are the same object. The instances of Tree Species are--as the name implies--types of trees. The subtypes of Tree are--by definition--types of trees. While Tree may be partitioned in various ways (based on size or age, for example), in this example it is partitioned on the basis of species.

Therefore, the integrity issue mentioned above is not really an issue here. Deleting the American Elm subtype from the Tree partition does not require also deleting the corresponding Tree Species instance, because the American Elm subtype and the corresponding Tree Species instance are the same object. Figures 23.4 and 23.5 depict another way of thinking about this. .



As established above, the instances of Classifiers can also be Classifiers. (This is the stuff that metamodels are made of.) These same instances, however, can also be specific classifiers (i.e. subclasses) of another classifier. When this occurs, we have what is called a power type. Formally, a power type is a classifier whose instances are also subclasses of another classifier

In the examples above, Tree Species is a power type on the Tree type. Therefore, the instances of Tree Species are subtypes of Tree. This concept applies to many situations within many lines of business. The figure below depicts other examples of power types. The name on the generalization set beginning with a colon indicates the power type. In other words, this name is the name of the type of which the subtypes are instances.

Diagram (a) in the figure below, then, can be interpreted as: each instance of Account is classified with exactly one instance of Account Type. It can also be interpreted as: the subtypes of Account are instances of Account Type. This means that each instance of Checking Account can have its own attributes (based on those defined for Checking Account and those inherited from Account), such as account number and balance. Additionally, it means that Checking Account as an object in its own right can have attributes, such as interest rate and maximum delay for withdrawal. (Such attributes are sometime referred to as
class variables, rather than instance variables.) The example (b) depicts a vehicle-modeling example. Here, each Vehicle can be subclassed as either a Truck or a Car or something else. Furthermore, Truck and Car are instances of Vehicle Type. In (c), Disease Occurrence classifies each occurrence of disease, e.g. my chicken pox and your measles. Disease Classification is the power type whose instances are classes such as Chicken Pox and Measles.



Labeling partitions with the power type becomes increasingly important when a type has more than one power type. The figure below is one such example. Without knowing which partition contains Policy Coverage Types and which Insurance Lines, clarity is compromised. This figure depicts an even more complex situation. Here, a power type is expressed with multiple partitions. For instance, a Policy can be subtyped as either a Life, Health, Property/Casualty, or some other Insurance Line.

Furthermore, a Property/Casualty policy can be further subtyped as Automobile, Equipment, Inland Marine, or some other Property/Casualty line of insurance. In other words, the subtypes in the partitions labeled Insurance Line are all instances of the Insurance Line power type.



Power types are a conceptual, or analysis, notion. They express a real-world situation. Implementing, however, them may not be easy and efficient. To implement power types with a relational database would mean that the instances of a relation could also be relations in their own right. In object-oriented implementations, the instances of a class could also be classes. However, if the software implementation can not directly support classes being objects and vice versa, redundant structures must be defined. In other words, unless you're programming in Smalltalk or CLOS, the designer must be aware of the integrity problem of keeping the list of power type instances in sync with the existing subclasses. Without the power type designation, implementors would not be aware that they need to consider keeping the subclasses in sync with the instances of the power type; with the power type indication, the implementor knows that a) an data integrity situation exists, and b) how to manage the integrity situation. For example, if the Life Policy instance of Insurance Line were deleted, the subclass called Life Policy can no longer exist. Or, is a new subclass of Policy were added, a new instance must also be added to the appropriate power type.