Model windows messages processed by a class

[CJ]

G'day folks,

I started modeling some abstract classes for our system.  No problem setting up instance/state variables as attributes and class functions as operations.

How do we specify for a class what user-defined messages are processed by that class?

Thanks in advance.

[CJ]

G'day folks,

Did a little digging in "The Unified Modeling Language User Guide", and I think the right way to set things up is to add, for example, a WM_LBUTTONDOWN operation with the two message parameters and the return value defined.

Is that appropriate at all?

(My thoughts are that messages (or signals, as defined in the book) are the same as operations in that they are a means of making a class do something.)

Thanks in advance.

[jaimeglz]

Hi again, Jason!

Yup, you are right. A class can have:

1. Components, which we model through the aggregation relationship.
2. Attributes.
3. Behaviour, which we model as operations. All behaviour starts either from an internal or external signal (received as messages).

It can also have pointers to ancestors (which we model through generalization and inheritance), and a "handle" (which the programming language resolves for us, and so we generally don't have to worry about).

I hope this helps.

Jaime

[Bebe Stanie]

Jaime.

I'm not familiar with the 'handle' concept, can you please give me a small explanation? Thanks!

Bebe

[jaimeglz]

Hi Bebe,

You're probably familiar with the practical definition of a class as a template to produce object instances, but I'll quickly give an example for the sake of clarity.

If I'm modeling an electronic zoo, for kids to play with in a PC, I can create a "mammal" class that models the ancestor of all mammals. I then model a "feline" class (to use one of my favorite examples), that inherits components, attributes and behaviour from "mammal"; and then I can model "cat", that inherits from "feline". I proceed then to model "Timmy" as an instance of "cat", and at rutime he will be an object that needs a unique identifier so the system can get a hold of him. This is the handle, which object-oriented languages have the capacity to generate, use and manage without the programmer having to worry too much about it.

There might be other cases, but the only circumstances where I have had to worry about the handle is when I want to know if a particular instance is already running (I have enough with one Timmy running around). OO languages provide "handle(name_of_instance:class)" functions mainly for this purpose.

It is the class template, however, that provides for objects to have handles, and classes themselves need also these unique identifiers (internally resolved as memory addresses) so that components can have pointers to "belongs to", signals can know where to deliver messages, and inherited classes can have pointers to "ancestor".

I'll admit to being a bit outdated on the best literature for a clear-but-not-too-extensive explanation of this, but I definitely recommend the chapter on object-orientation in Ivar Jacobson's et al. "Object-Oriented Software Engineering" (Addison-Wesley - acm Press, 1992). For an in-depht view, I'd recommend Meilir Page-Jones' works on OO.

Jaime

[Bebe Stanie]

Jaime,

Thanks for the (entertaining) explanation! I'll read the suggested chapter as well.

Bebe