Contents of a class that is composed and inherits

[Włodek]

Hi everyone,

My problem is such: I'm trying to model a class hierarchy that represents messages flowing through my communication system.

My current approach is to define a parent message that is composed of absolute minimum information for it to be called a message in the system. Other messages would then inherit from the base message and replace or add some message parts.

See the diagram:


What I'm trying to achieve is to show the resulting message including all the information that comes from inheritance and composition.
Relating it to the diagram: is it possible to show on a diagram (or generated documentation) that SpecificMessage class actually is composed of Data, Checksum, Header and Footer taking into account their multiplicity?

If so, how?

Also how would I show that SpecificMessage does not contain Footer for example?

What I tried so far:
Making the Message class contain attributes like header: Header, chksum: Checksum and so on, but then how do I show that Specific_data overrides data in SpecificMessage?

Best Regards,
W[ch322]odek

[qwerty]

Create a MessageBase without Footer and make Message generalize MessageBase and include a Footer While SpecificMessage does just generalize from MessageBase.

q.

[Włodek]

By including footer you mean composition of existing footer class or an attribute of type Footer?

That does not show me the full contents of the resulting class. If Message is composed of, say, only Header (multiplicity 1) how to show the fact that SpecificMessage does in fact include the Header?
The only way I can see this is going to the Traceability window and navigating the tree there but I cannot generate any documentation from that.

[KP]

Relating it to the diagram: is it possible to show on a diagram (or generated documentation) that SpecificMessage class actually is composed of Data, Checksum, Header and Footer taking into account their multiplicity?

I would say that is exactly what your diagram shows.

Also how would I show that SpecificMessage does not contain Footer for example?

Try an association to Footer with multiplicity of 0.

but then how do I show that Specific_data overrides data in SpecificMessage?

If you name the role at the Data class end of the association (e.g. to "data") then you can right-click the association between SpecificMessage and Specific_data and find the "Specialize Associations" command. Use this command to define that the Specific_data "{redefines data}"

[Włodek]

I would say that is exactly what your diagram shows.

True,  the diagram shows that. Maybe I wasn't clear on this. What I wanted to show was the resulting instance of the SpecificMessage in a way that you see every attribute inside that instance, taking into account the fact that SpecificMessage's superclass  (Message) is composed of multiple classes that contain their own attributes. In other words in the generated documentation I'd like to see the resulting message (possibly in the form of a table) with all the fields (e.g. classes that compose Message)  from parent classes taking into account their multiplicity.

Try an association to Footer with multiplicity of 0.

Ok.

If you name the role at the Data class end of the association (e.g. to "data") then you can right-click the association between SpecificMessage and Specific_data and find the "Specialize Associations" command. Use this command to define that the Specific_data "{redefines data}"

The redefinition is not shown with Composition relation, if I use plain Association between Specific_data and SpecificMessage with source roles I get nice curly braces saying the role from the superclass is redefined in this relation.

[Kevin G. Watson]

Hi Wlodek,

My reading of your class diagram is as you have stated, and KP confirmed... the redefine trick improves the diagram.

What I wanted to show was the resulting instance of the SpecificMessage in a way that you see every attribute inside that instance...

I would have thought an object diagram would be more appropriate for what you are trying to express, a clue is in your use of the phrase '...resulting instance...'.  Using instance variables you can illustrate every attribute ( and it's representative value ) of your SpecificMessage object.

  According to your class diagram there are 8 variants of Message, and a further 4 variants of SpecificMessage.  An object diagram would enable you to express which are valid variants, perhaps using the instance name to hint at how its used.   You could add a diagram fragment to your class diagram to include the object diagram, if you wanted to maintain the all in one view.

Regards
Kevin [smiley=2vrolijk_08.gif]

[Włodek]

Hi Kevin,

Forgive me for the late reply.

I would have thought an object diagram would be more appropriate for what you are trying to express, a clue is in your use of the phrase '...resulting instance...'.  Using instance variables you can illustrate every attribute ( and it's representative value ) of your SpecificMessage object.

How would you do that?
Defining run state in an Instance of a class gives me access only to direct attributes of a SpecificMessage.

According to your class diagram there are 8 variants of Message, and a further 4 variants of SpecificMessage.  An object diagram would enable you to express which are valid variants, perhaps using the instance name to hint at how its used.   You could add a diagram fragment to your class diagram to include the object diagram, if you wanted to maintain the all in one view.

My intent was to have something like this (see the image).
Either in the form a table in the generated documentation or some kind of _object_ in EA.


The reason for this form of presentation is that the designed protocol is to be shown to people unfamiliar with UML.
The problem with name "Instance" is that it implies assigning values to attributes (the state of the object). I just want to show the resulting structure of the message.

BR
W[ch322]odek

[qwerty]

I don't know how the table would make it more readable. It even misses that Data has mult. 0..1. So it duplicates information and introduces (wrong) redundancy. What's wrong with people teaching to read this subset of UML?

q.

[Włodek]

I don't know how the table would make it more readable. It even misses that Data has mult. 0..1. So it duplicates information and introduces (wrong) redundancy

I'm showing the SpecificMessage in the table, not Message, so it contains redefined Data (Specific_data) with multiplicity 1 and header inherited from Message with multiplicity 1.

What's wrong with people teaching to read this subset of UML?

It's not wrong, it's just not going to happen. Part of the team I'm working with (from another company) does not use UML in their work but would like to know how the protocol is designed. The best way to present this sort of information that comes to mind is simple table. It doesn't need to be embedded in the EA model, it can be generated from the model.