Stereotype best practice

[Thomas Mercer-Hursh]

In defining a Profile for Progress ABL, I am finding a couple of points where I am wondering about what is considered best practice in stereotype usage.

This relates primarily to the fact that we have two different sorts of top level elements.  One is source code and is called «oeProgram» and is a Component and the other is the compiled unit which is actually executed and that is called «oeCompileUnit» and is a Package.

One question arises from the fact that there are certain of these general elements which we want to have a special stereotype, e.g., «oeMenuProgram» instead of just «oeProgram».  It seems to me that there should be two stereotypes here, one for each original type, e.g., «oeProgram» and «oeProgramCU» or some such.  So, I am pretty clear on that question.

The other question relates to connectors between these elements, e.g., one element can execute another element.  These links are always within kind, i.e., source to source or compiled to compiled.  So the question is whether it is reasonable practice to use one stereotype, e.g., «oeRunProgram» for the links between both types of elements on the basis that it is the same relationship which is being indicated or should it be two different stereotypes to indicate the difference in the elements being connected?

The latter will result in rather more stereotypes being defined, of course, but might also result in greater clarity.

Opinions?

[thomas.kilian]

I don't think that adding stereotypes in this way to connectors brings more clarity. To me a stereotype is used to create groups of related things. So these stereotyped connectors need to be different in some way from other connectors. If you could describe that difference it would be okay. But only in rare cases I would see the added semantics (clearly!).

OTOH it seems to depend. I also saw this being in use elsewhere in a similar way. Being asked why it was made this way they answered: to add clarity. :-/

[Thomas Mercer-Hursh]

For a "run" connector, the link between compile units is something that happens in the deployed system, which the link between the corresponding source units is a logical dependency or relatedness.  Close, but not quite the same.

I should note that actual confusion is highly unlikely since the two are unlikely to appear on the same diagram.  I.e., a summary diagram of deployable components will only have the compile units while a detail diagram of code structure will only have the program units and sub program units.

Once place where there may be a practical issue, however, is in the links to the data components.  In tracing all compile units or program units which have modify access to a particular table, being able to ignore a large percentage of those because they were of the wrong stereotype might be useful.  There are 8500+ modify summary links and 33000 readonly summary links.