At the moment, there are two distinct ways to define tagged values (aside from ad hoc definitions): profiles and tagged value types (structured tags). It seems that the two methods can be made to cooperate, as follows:

1. Create the desired tagged values as untyped attributes of stereotype elements in a profile (it seems you can use built-in types as well, but using untyped attributed avoids possible type collisions).2. In parallel, define the same tagged values using "Settings > UML > Tagged Value Types" and define the types of the tagged values there.3. When applying a stereotype from your profile, the tagged values will pick up their type definitions from the structured tagged value type definitions created in 2.

While this appears to work, it is clunky and error-prone. Furthermore, the two methods of type definition work in different ways: enumerated values from a profile, for example, store the list of values in the tagged values Notes field every time the tag is used (which is not the best way to do things), whereas structured tagged value enumerated types leave the Notes field free (values list is stored in t_propertytypes).

Sparx should seriously consider unifying these two methods somehow or at least documenting how the two methods can be made to work and play nicely together.

Actually, we 'Murkans are far better informed than you realize... for example, we know that those sprouts we all hate are from Brussels (wherever that is), and that if Caesar hadn't won the Garlic wars there'd be no such thing as marinara sauce. Or that salad of his. But what does Ned Flanders have to do with all of this?

I was making a comment regarding Geert's "If it's 37 Celsius, it must be Belgium!" exclamation, not the importance of bug swatting. But then, Batvir would probably whip a few quick software fixes out from his utility belt and we'd all be happy.

Well, "forbidden" is a bit too dramatic - shall we say "non-compliant" instead? What I'm on about here is the fact that the EA user interface, in many cases, happily lets the user add features to elements that are not specified (or specified as not allowed!) for the element by the OMG specifications. For example, I can add an operation to a flow specification by clicking on the purple cube on the "Elements" toolbar, yet the SysML 1.1 spec clearly says, "[1] Flow specifications cannot own operations or receptions (they can only own FlowProperties)", and "[2] Every “ownedAttribute” of a FlowSpecification must be a FlowProperty" (I can also add arbitrary attributes that are not flow properties in the same manner).

What does the community think? Is EA's "libertine" attitude toward what is and isn't permitted for a given element a good thing (it lets the user extend UML beyond what the specs define) or a bad thing? I lean toward "bad," but YMMV.

One shortcoming in the EA implementation of SysML is its lack of support for compartment-based representations of SysML features. For example, the SysML specification (e.g. Figure 9.7 in section 9.4.3) shows a "flow properties" compartment with flow properties represented as attributes with "in", "out", or "inout" prefixes. EA, on the other hand, only provides* the composite diagram + Flow Property "part" as a "built-in" method of realizing a flow specification. Likewise, Block properties (parts) can only be displayed by showing the composite diagram contents, not by means of compartments (as shown in Table 8.1 of the SysML 1.1 spec).

Ideally, both representations should be available for a given set of model elements. In other words, it should be possible to represent properties on a SysML internal block diagram in a "properties" or "parts" compartment on the parent block definition diagram, or as elements in a diagram frame on the parent block definition diagram, depending on the "display features" options for the block. As it is, the need to use "show composite diagram contents" in order to display a block's owned features is clumsy and gets in the way of a compact, neat representation of SysML system models.

* It's possible to "fake in" compartment-based SysML features by judicious choice of attribute stereotypes, but this isn't directly supported by the SysML stereotypes provided by EA and is in any case just that - "faking it in".

This seems like a likely candidate for automating UI actions otherwise available only by manual user action (e.g. opening the properties dialog for an element, along the lines of DoCmd in Office VBA). I know that at least one such action is CustomCommand("Repository", "Sync", "<yadayada>") to synchronize stereotypes from the AI; in fact, I found this out from y'all at Sparx!

I would seriously consider (but then I don't have to do the work!) standardizing on an existing set of "CustomCommand" calls (the "interoperable" command set) while leaving room for custom calls that may change with time. Other than the work involved, I don't see why this would be a problem.

Does anyone know if there is a way to set the background of a composite diagram (i.e. a composite element with "show composite diagram" selected) to something other than transparent? I have some interface diagrams (hybrid SysML + UML) where the element with the "focus" is shown as a verrrrry tall composite diagram (in order to show all its interfaces to other model elements while also providing a "white box" view) on a diagram with a matrix background, and it's all too easy to lose track of what's an element border and what's a row divider, even with the element border width increased for emphasis. And, it's all too easy to craft run-on sentences in order to describe this particular conundrum!