Sub class diagram

[danm]

Hello,
  When, and when would you not, put a diagram under a class? I mean, right click on a class and add a behavioral diagram. I do this sometimes to investigate some aspect of the classes behavior, but I don't know of any generally agreed on stylistic choices for this.

[MrDX]

I think, it's very usefull if you would like to add a state machine to the class 'A'. Then, you know, that the state machine belongs the the class 'A' (and not to 'B', ...).

We are using the models for codegeneration (own code generator) and it's easier to have this hierachie, instead of searching informations in the model (like 'Statemachine C belongs to Class D', 'Class B has NO statemachine', ...).

It's a nice feature to specify an element in all details.

[«Midnight»]

danm,

There's no real stylistic protocol. What works best for you in a given circumstance is the way to go. MrDX provides an excellent example.

You might want to add an 'inner' diagram of your own type to an element, and have the inner diagram open automatically. There are a few tricks to do this on the forum, but they are difficult to find.

What I've sometimes done in the past - and this still works in EA 7.0 - is to make the 'outer' element (a class in the MrDX example) a composite element. [You can do this via the context menu by choosing Advanced | Composite Element.] Now drill down to the inner diagram by double-clicking the element. From the main menu choose Diagram | Change Diagram Type. Now you can set a new diagram type (a State Machine in our example). So now you have a state machine for your class, that is available by double-clicking the class.

There are other tricks in the forum, so dig them out if you want to try more.

HTH, David

[sargasso]

Why would a class exhibit behaviour?  An instance of a class may exhibit a certain behaviour of interest in a certain scenario.  

A class is a structural entity that collects a bunch of stuff that may realise one or more behaviours specified elsewhere.  

I have a great deal of trouble conceptualising a system that is described structurally and then trying to realise behaviour based on that structure.  A class, (type) sic, has no behavior.  If I describe, model and implement a type based on its' structure and subsequently its' behaviour given that structure then I reckon I've forgotten all the bloody rules.

Domain -> objects -> classifiers -> conditions -> behavior. No.

Domain -> behavior -> participants -> co-operative behavior -> outcomes -> redefinition -> etc etc.

To put it more metaphorically, on this island there are "me", chickens, komodo dragons and dugites. I would like to drink a glass of milk.   Please, explain how you would decide which of these types you like to exhibit the "give milk" behaviour.  Credit poinits will be given for explaining how you would implement your chosen behavior given these types.


hth
bruce


edit:  to put it more bluntly. Putting a behavioral diagram under a clssifier is saying that this type will exhibit the same behavior under any circumstance.  The only example I can think of is that class of operatingsystems known as MSDos (or derivatives thereof) that will inevitably ... "hang".

[«Midnight»]

Quite right bruce,

Which is likely why such diagrams are not included in the default context menus in EA.

However, to the extent I'd do this at all, it would be for documentation rather than implementation purposes.

I know the purists out there would scoff. After all, if you build it (whatever "it" might be) right, why document it at all? Still, there are still a (very very very) few out there who have some interest in knowing how it was supposed to work, if only for amusement while we wait for the next major version.

David

[jeshaw2]

I know the purists out there would scoff.

 I do not hold purists in high regard.  I'll take a critical thinking realist every time.

I still like the idea of being able to drill down to a behavior diagram through items in the behavior compartment of a class element.  This is discussed in other threads though.

[Oliver F.]

To put it more metaphorically, on this island there are "me", chickens, komodo dragons and dugites. I would like to drink a glass of milk.   Please, explain how you would decide which of these types you like to exhibit the "give milk" behaviour.  Credit poinits will be given for explaining how you would implement your chosen behavior given these types.

As a user I would look at the exhibited interfaces of those creatures whether there is one of the milk giving type and select only those. However I am not interested in the functional details unless I had to file a bug report to the veterinary on duty.

As some sort of godness or creator of these creatures I would have to establish a contract by introducing the aforementioned milk giving interface and assign it to the abstract "milk creature" type (which can be sub type of "creature" anyway, gods ways are strange sometimes and so are mine). Again, at this point here, no functional internals necessary for the "creature" or "milk creature".

But as a god I can not rely on abstract creatures for long because people will start starving if no realisation of the "creature" type will occur so I have to start building up chickens, komodo dragons and dugites. The milk giving  creatures will expose the "milk creatures" interface contract and now, as we have been talking about evolution enough, comes the fact into play where I would like to see documentation: The specific realisation of the interface in the specific definition of the "milk creature".

This is something where a drill down of behavior in classes can be definitely helpful.
I have to describe behavior anyway because class member show  a contractural behavior to their outside so where shall I put it if not at the place it belongs to ?

Oliver

[jeshaw2]

IMO, behavior is a collective term:  the sum of all the operations defined on a class or promised by an interface.  Quite often a class specifies multiple operations.  Each operation is realized by a method.  Behavior diagrams model the nature of the method, not of the class nor the effects promised by an operation.  What we think we need need is the ability to drill down from an operation to its underlying method, not from the class element.  We think we need to be able to click on the operation, not just anywhere in the class element.  But this does not tell the whole story.

For example:  I can Cry and I can Pound my fist on the table.  However, I exhibit this behavior (collectively) only when I'm in the state of being Upset.  Therefor, an object's state is an important aspect to its behavior.  And since I cannot conceive of any animated object (or one having variable attribute values) not having multiple states, our path to activity diagrams must be through a state diagram and thence onto the action or activity specified therein; and the way to get to the state diagram is by clicking on the class element itself.  

Yet again, the full story is not told;  there may be multiple reasons to drill down in to greater detail on a class.  Off-hand I can't think of any such reasons, but I'm sure the creative talent available on this forum can provide them.  Thus, a class element (and in reality any element) is a parent node in a tree with multiple child elements.

IMHO, whenever one clicks on any element in a UML diagram, a list of the child diagrams should be presented for selection. If we are going to get a problem fixed, we ought to fix the whole problem and be done with it.  What's the problem?  EA does not view the drill down feature as a tree navigation.

-Jim