IDEA: Improved Notes window

[Paolo F Cantoni]

It would improve the usability of EA if the Notes window [Ctrl+Shift+1] had an indication of which internal EA object it was displaying the notes for.  My suggestion is:

Notes (for: Classifier.Feature)

Thus for class Fred, operation GetBill it would display:

Notes (for Fred.GetBill)

For just class Fred it would show:

Notes (for Fred)

Thoughts? Votes?
Paolo

[size=0]©2007 Paolo Cantoni, -Semantica-[/size]

[«Midnight»]

Simple, clear, useful. I like it!

Certainly gets my vote.

[SF_lt]

this idea is similar to my one year old suggestion, but I support idea.

However suggest, that note visualization should account class realization language:
for C#/Java would show Fred.GetBill
for C++ would show Fred::GetBill

Paolo, would you register your proposal?

[Paolo F Cantoni]

Already done on the first post.

As to language specific, this can be a bit problematic, as (in the general case) you could have elements from multiple languages / no language on the same diagram.

I think the dot notation is standard UML - hence why I suggested it.

Paolo

[Jan ´Bary´ Glas]

If this useful thing needs support, here it is.

[SF_lt]

so I refine proposal:
if class is set to be realized in C#/Java or None, dot notation should be used Fred.GetBill
if class is set to be realized in C++, column notation should be used Fred::GetBill (Fred.GetBill would mean class attribute, not method)

another point is how to distinct class attributes, methods, overloaded methods?

method   -(for Fred.GetBill())
attribute-(for Fred.GetBill)

what about overloaded params if there several GetBill methods
Fred.GetBill(), Fred.GetBill(Sum), Fred.GetBill(date) & etc

[Paolo F Cantoni]

Hi SF_lt,

Implicit in my original proposal was that you could clearly identify the object - so you are correct in indicating that operations should be distinguishable from attributes and that the parameter list needs to be shown to distinguish between overloaded methods.

I'm not so sure on making the rendering language specific because there are a large number of languages (not just the few you mentioned) - that why I stuck with standard UML (actually OCL) notation.

Paolo

[«Midnight»]

Another 0.02 CAD here, if I may.

You also have to consider MDA and other such paradigms, where specifying a language would be contrary to the whole idea.

Perhaps best to leave language-specific notations until later in the modeling or rendering chain.

That said, other features of EA could well provide considerable leverage here. Something along the lines of language sensitive documentation capabilities. Perhaps some kind of callable (or callback or whatever) facility at various points in the document generation process. Maybe even something event driven, that could be further exploited via the API. Worth considering...

David