Difference between revisions of "XCSG:Classifier"
| Line 22: | Line 22: | ||
== Specifications == | == Specifications == | ||
| + | |||
| + | |||
| + | |||
| + | |||
| + | == See Also == | ||
| + | * [[:Category:XCSG Node Kinds]] | ||
| + | * [[:Category:XCSG Edge Kinds]] | ||
| + | * [[:Category:XCSG Tags]] | ||
| + | |||
| + | [[Category:XCSG]] | ||
Revision as of 15:05, 5 March 2014
Classifier is the parent of Interface, Class, and Datatype in the metamodel. It defines structure and behavior in terms of features (attributes, operations, and methods). The features, associations, and constraints defined by a Classifier are inherited by all its subtypes (children).
The semantics of Classifier are those defined by UML [5, pp. 2-30, 2-61]. However, only the attributes and associations given above are of interest.
Inv supports the specification of user defined invariants in an OCL-like style. It is equivalent to associating a constraint with the element that has the stereotype «invariant», but less cumbersome to write. Such invariants must be established by constructors (object initialization methods) and maintained by other operations associated with the Classifier. The invariant is implicitly a part of the precondition and the postcondition of every public operation.
The use of the subtyping (Generalization) relationship between classifiers implies behavioral subtyping as well as inheritance: an instance of a child is substitutable for an instance of a parent in any context in which the parent appears. The required relationships between parent and child elements are those defined by Liskov [18], and described (less formally) by Meyer [19][20].
The subtyping relationship can be extended to include multiple dispatch as described by Castagna [21] and Leavens [39] by stereotyping the Classifier (with «multipleDispatch»).
The UML 1.4 semantics of for inheritance involve taking the union of the all the features inherited by a given classifier together with those defined by the classifier itself. The model is considered ill-formed if this result contains more than one feature with the same signature.
This rule is applied recursively to deal with hierarchies with a depth greater than two, i.e. the feature set formed for each classifier is inherited by each of its children, the feature set formed for each of these children is inherited by their children, etc.
Because features are combined using union, each inherited feature will appear only once in the result, even if it is inherited by more than one path (appears in the feature set of more than one parent). [In the terminology of Bertrand Meyer [Object Oriented Software Construction], features are shared rather than replicated]. Because a Classifier is a Namespace, the resulting set of features may not contain different features with the same signature.
The introduction of feature redefinition in UML 2 extends these semantics. If redefinition is not used, the results are the same as before. Where redefinition is used, however, we replace all redefined features inherited by a classifier with their new definitions before we form the overall union. [This gives us a choice of replicating features if we explicitly redefine them but does not affect the fact that repeatedly inherited features are shared by default].
The semantics of inheritance and subtyping are discussed further in the definitions of Generalization and Class. The redefinition of inherited elements is discussed in the definitions for Operation and Field.
