Reply To: Why Aren't Interfaces Tied To Components?

homepage Forums BridgePoint/xtUML Usage and Training Why Aren't Interfaces Tied To Components? Reply To: Why Aren't Interfaces Tied To Components?

Lee Riemenschneider

Things have gone from disconnected to horrifying. I was playing with the GPS Watch example model some more, looking at EE and interface usage.

First let me list my assumptions: (Many based on the out-of-date “System Modeling with Components” document)
1. Components have replaced the former graphical representation of domains.
2. Interfaces have replaced bridges/domain functions. (Revisiting said document shows that domain functions are no longer considered the external interface.)
3. EEs are deprecated. (which per this discussion no longer seems true)
4. A component diagram is used to show the domain chart.

I didn’t expect any of this to affect the way one models a domain. The horror came when I opened the state model for the Display class in the Tracking domain(?). I noticed that there were two different event designators, Display_A(n) and UI. The UI designator referred to the UI domain(?), and I thought it unpleasant that formalizing the interface signal to an event would change the event in the model. From looking at the tree for Display, it looked like there was a local version of the same event, which there MUST be or the domain model couldn’t be complete and stand-alone. What was really horrifying is when I unformalized the interface; the event disappeared from the Display tree and the state model reverted to no event assigned.

This is bad behavior, but not surprising, given that the xtUML_Metamodel is looking like spaghetti these days. I think some thought needs to be given to what is method (metamodel domain), what is graphical representation (not metamodel domain), and what needs to use them (tool application domain(s)).