[Modeling] Modeling an Agent Class

[James Odell]

Giovanni,

Good points.  I was using the property, or association end, name.  The end
name for the association from Namespace to NamedElement (Fig. 1-6) is called
"member".   The end name for the association from Classifier to NamedElement
(Fig. 1-22) is called "inherited member" -- and is constrained to be a
subset of the Namespace "member".   This is the reason why  I was saying
that the instances of Classifiers are members.  Does that make sense?  So,
to glue our two approaches together, one could say that the
InstanceSpecification property of a classifier is a member (or more
precisely, an inheritedMember -- which is derived from the Namespace
property of member).

In this way, it could also be stated as:
UML members = UML objects + AUML agents + <other instance-level stuff>

Or as you quite rightly stated in your email:
UML Classifiers = UML classes + AUML AgentClasses + <other type-level stuff>

Are we in violent agreement, now.  Or, do we still differ.


Cheers,

Jim 


On 6/11/03 4:59 AM, "Giovanni Rimassa" indited:

>> So, on to your question: In UML 2.0, an Object is defined as an instance of
>> Class.  So, Classes have objects, and Classifiers have members.  So, would
>> it be useful to use the following, instead:
>>        UML members = UML objects + AUML agents + UML Actors + UML Signals +
>> UML Activity + ....
>> 
> 
>> Would this work?
>> 
>> 
> 
> 
> I'm not sure. It looks to me that if 'Classes have Objects' means
> Object-instanceOf-Class, then 'Classifiers have InstanceSpecifications'.
> Now, the definition of Classifier says 'A Classifiers is a namespace
> whose members can include features'.
> If I understand correctly, Classifier and Feature are in the type
> space, whereas InstanceSpecification and Slot are in the instance
> space (with 'in the type space' I mean that they appear on the right
> hand side of an 'instanceOf' relationship, with 'in the instance space'
> I mean that they appear on the left hand side of the same).
> 
> So, I would say InstanceSpecification-instanceOf-Classifier and
> Slot-instanceOf-Feature (actually, it is StructuralFeature, page 34)
> 
> I couldn't find the definition of Member, but my 'natural' understanding
> from OO languages terminology is:
> 
> 
> class Point {
> 
> public:
> 
> Point(double x, double y);
> 
> double getX();
> double getY();
> 
> private:
> 
> double m_x;
> double m_y;
> 
> }
> 
> };
> 
> 
> Point p(0.12, 3.14);
> 
> 
> In terms of the UML metamodel, 'Point' is a Class, 'p' is an Object,
> and both 'm_x' and 'm_y' are members (and they could have features, if
> they were of some non-primitive type).
> 
> So, to me, 'Point has p' and 'Point has m_x' are both true but 'has'
> means two different things.
> 
> 
> I would rewrite the equation in the type space as follows:
> 
> 
> UML Classifiers = UML classes + AUML AgentClasses + <other type-level
> stuff>
> 
> And, in the instance space:
> 
> UML InstanceSpecifications = UML objects + AUML Agents + <other
> instance-level stuff>
> 
> 
> I wrote <other XXXX-level stuff> because I don't know whether Actors,
> Activities and the like are type-level or instance-level. Moreover, I
> don't know whether for each type-level element (read: for each subclass
> of Classifier) there is a corresponding instance-level element (read:
> a subclass of InstanceSpecification).
> 
> Do you think it works now? If so, do you know whether we can write the
> two equations completely, and with one-to-one correspondence between
> type-level and instance-level equation parts?
>