Modeling a Type specification

[jeshaw2]

From the UML 2.0 Infrastructure Document.

type
A stereotyped class that specifies a domain of objects together with the operations applicable to the objects, without defining the physical implementation of those objects.

I know how to put a stereotyped class on a UML diagram, but how might one model the specification of a domain of objects?
Is the Type a generalization, an aggregate, a composite?  We know from the source text that it is not an interface...so what is it?

If one of the objects is destroyed, then is the Type also destroyed?

Can one or more of the objects be an instantiation of a class of a different type?

Perhaps, since a type specifies a range of objects, its better diagrammed on a Composite Structure Diagram?

Thoughts?

[sargasso]

(pretty tired - worked all weekend - so I may be a bit off)

I've found the best way to deal with these nutters (OMG) is to go all the way back to basics.

So, class "<<Type>> Jumbuck" specifies the operations  existent to that domain of sheeplike objects, viz GiveWool, GiveChops, etc. So what's different to that and a normal class? Pretty well nothing, but perhaps there is a pertinant operation "MakeLittleJumbucks" that is specific to instances that type and tht type only.  Similarly, <<Type>> Integer may have an operation "Factor" that is not shared with <<Type>> Real. etc.

I think the definition of the domain is intrinsic in the type, it's not a (sub-)modelable(?) facet.  Jumbuck defines  the jumbuck domain, Integer defines the integer domain.

.. gotta go look at the inside of my eyelids for a couple of hours...

b  

[«Midnight»]

And then inevitably one goes on to extend via a profile.

Not the easiest thing to do, but it is very quickly evident this is produces less misery than other choices.

That's not saying much, but support for profiles is one area where Sparx has made progress in 7.0, so they might be listening if we can extend this further.

David