Heath Frankel wrote:
>Andrew,
>I thought that the archetype approach was certainly extension. In fact
>there examples of such. Refer to Adverse-Reaction and
>Adverse-Reaction-Medication.
>
Hi Heath,
these are restriction, not extension. They look like extension because
the parent constraint node is typically something like:
CLUSTER[at0001] matches {
other_items cardinality matches {0..*} matches {
ELEMENT[at1000] matches {*}
}
}
So if the specialised archetype says:
CLUSTER[at0001] matches {
other_items cardinality matches {4} matches {
ELEMENT[at1000.1] matches {value matches {C_QUANTITY matches {...}}}
ELEMENT[at1000.2] matches {value matches {C_QUANTITY matches {...}}}
ELEMENT[at1000.3] matches {value matches {C_QUANTITY matches {...}}}
ELEMENT[at1000.4] matches {value matches {C_QUANTITY matches {...}}}
}
}
It looks like extension, but mathematically, it is further restriction.
The specialised archetype is saying that there now can only be 4
ELEMENTs, of prescribed structure, whereas the parent indicated any
number of ELEMENTS, containing anything.
> I am also sure it supports restriction, the
>same example also supports this. Unlike some people, I believe that
>restriction is a valid form of specialisation as far as UML is concerned.
>
>
Well, it depends on what you mean by this. There are multiple possible
meanings:
1. (as you indicate below) The property of a parent class (needn't be
abstract) is limited to a particular value in a descendant class.
However, value setting has nothing to do with specialisation semantics
of the model.
2. Properties defined in a parent class are "removed" by writing
invariants which force them to 0 or Void in a child. It could be argued
that this is just like 1 above, but when applied systematically, it is
not. The reason is that this practice is usually accompanied (as in the
HL7 RIM) by the definition in parent classes of properties which have no
meaning for some or many of the descendant classes, and are 'zero-d out'
by the use of invariants. It breaks fundamental principle of openness
(extensibility) of object-oriented models, because a) you have to try
and think of all properties that will ever be needed in advance
(impossible), and b) in real systems, programmers always have to write
code to make sure that the Voided or zeroed fields are handled
correctly, and not understood as being normal proeprties which happen to
have a null value in a particular situation.
As a general concept, UML and other object-oriented systems don't
support restriction in modelling, they support specialisation, which is
not the same thing. Restriction (as defined above) means logically
removing things, while specialisation usually means the addition of
descendant classes with new properties, and with some properties refined
to a subtype of their corresponding parent. The latter practice does not
require pushing irrelevant properties up into high level classes and
then "removing" them in descendants where they don't make sense.
- thomas
>Certainly in OOP, I often have an abstract property that has its value set
>(sometimes in hardcode) in the concrete class.
>
>Heath
>
>
>
-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org
