You need to select one or more classes or packages. I recommend right-clicking in the project browser; the Code Engineering submenu is the one you want, and in there Generate Source Code.In the dialog which opens you will normally want to tick the "Include all Child Packages" box, otherwise code will only be generated for the classes immediately below the package you selected.

On this topic, I've had problems getting the Code Generation Templates to work after importing them as reference data. I've traced this to the absence of types defined for my language.

In other words, if there is no language X defined in the "Programming Languages Datatypes" dialog (Settings - Code Datatypes...), language X does not appear in the Language dropbox the Code Template Editor (top left).

Defining a single type for language X resolves the issue. The Code Generation Templates do not need to be reimported.

The reason the swimlane classifier doesn't count as a reference in either the Traceability window or the Elements Usage (Find in all Diagrams) dialog is that swimlanes aren't diagram objects.

Exactly how the reference is stored I don't know, but it does work in the sense that the swimlane labels is updated when the classifier's name is changed.

So the potential is there, it's just not implemented. You could post a suggestion and see if anyone likes it.

As a workaround, you could use boundaries or (in activity diagrams) partitions. You can set classifiers on both these, and since a boundary is a diagram object and a partition is a fully-fledged element, the backwards references work.

In the View menu in EA 11.1, there's a disabled item Decision Table. Is it supposed to work, and if so how do I open it?

The help file says it should enable when I select an activity in a diagram. It doesn't.The help file also says there should be a Decision Table item in the diagram context menu for activities, as well as a Decision Table toolbar. I haven't been able to locate either.I am using the Complete command set.

According to the version history, the function was introduced in EA 11.0.1105, not touched in the remaining 11.0 or 11.1 releases, then in 1207 it was added to a portal, and activities became renderable as decision tables.

But I can't find any way to add them in the first place. Is this a case of the help file and bits of the GUI being shipped before the function was in place, or am I just doing something wrong?

It allows you to quickly set up a summary of what interfaces are provided, by what components, to service what dependents.

This would be extremely useful. Except that in order to do that, I must now draw an additional connector. I've drawn a realization and a dependency, from one component each, to the same interface. If I must now also draw a dependency from one component to the other, I introduce a direct dependency between them -- precisely what I wanted to avoid by using an interface in the first place.

If the connector (I suppose an assembly would be most correct, but I just plain don't like those bulky little buggers) was ghosted in the same way as the lollipops, I'd love this feature. Love it.

And, just to pile on for no better reason than it's raining outside, here's how it works in practice.

1) I set my model up the normal way with an interface, a component which realizes it (A), and a component which depends on it (B).2) I drop the components in a diagram and select to display realized / dependent interfaces. Lollipops appear - yay!3) I draw a new dependency from B to the lollipop decoration on A. The dependency sticks to the lollipop on A. Good.4) But what's this? There's a new dependency lollipop on B, called "A"!5) I go to A and deselect presentation of realized interfaces.6) The dependency end now hovers in the air.7) I move "A" around in the diagram. The dependency sort of twitches a bit, but the end stays where it is. I switch A's realized interfaces back on. The dependency sorts itself out.

I should point out that if you close and re-open the diagram after 6) it all works correctly. But 4) makes the function less than intuitive, and having to draw the extra connector myself rules it out altogether -- not because I'm such a lazy sod, which I totally am, but because it requires me to break my precious model.

So IF you're going to have another look at this feature, please consider changing it to auto-draw connectors between the ghosted lollipops. Preferably headless ones, like associations or connectors (ie the ones between ports, which are actually named Connector).

Also, IF you do take a look, the whole thing would be much more useful if you could select which side of the element each type of lollipop appeared on. That way, connectors or no connectors, I could at least set them up roughly facing each other.

I think all you're going to get from that is a correction in the help file.

I've never seen it work that way, the "shown" interfaces (whose names are in italics, not regular font as the help file image claims -- further proof that the help file is wrong) have always1 been unselectable ghosts.

It's a pretty useless feature IMO. In order for it to be useful, the connectors to/from the "shown" interfaces (the ones from Class1 in the help file image) would also need to be drawn in the same ghostly manner, but they're not.

My research over the last decade has convinced me that the more rigorous the relationship between the modelling syntax (especially including [highlight]naming of objects[/highlight] according to their metatype) and the semantics, the better and more insightful the model.

You should read Wittgenstein. Things are only what their name is - and vice versa.

True, but then Wittgenstein was a beery swine who was just as sloshed as Schlegel.

If you return true out of EA_OnContextItemDoubleClicked(), you're telling EA that you have taken over handling of the event and EA should now stop processing it. If you return false, you allow EA to continue processing the event, which in most cases means opening the properties dialog.

It is probably a good idea to return false in this case.

As to why EA crashes, before you call Repository.ShowInprojectView(), make sure that element isn't null. If for instance you have deleted and recreated the use case, element ID 13 will never be reused and so Repository.GetElementByID() will return null.

It looks like the "One Of" filter condition is strictly one of -- not one-or-more-of. Might be worth logging this as a bug, but I have a feeling it might be a case of unexpected design consequence rather than implementation error.