OpaqueBehavior

[qwerty]

You can evaluate it via automation. Issue a SQL search for the desired connector (you can do that via the API), examine the attribute StyleEx and you will find something like

Code: [Select]

LFEP={FE593047-D503-4f20-B16D-FDAFF00DEDF3}L;LFSP={54D09D25-A01F-4bda-B097-9C8E1B3C1515}R;

The two guids are that of the according operations. You need to experiment a bit to figure out what the LFEP/SP prefix and the L/R suffix mean (likely how the attachment is built on the diagram). But just to grab the two operations a simple regular expression can extract them.

Regarding your further question (it's already late here): IP is probably not a unique acronym. Could you tell me the long form?

q.

[Thomas Mercer-Hursh]

IP is just shorthand for Internal Procedure.  In the current structure I have IPPrivate and IPPublic (which I can reduce if I use operation since that has a visibility attribute) and RunIPPrivate and RunIPPublic for the control flow links.  (actually, all of my stereotypes begin with OE for OpenEdge, which clusters them in the list, but which I am omitting here for ease of reading).

[qwerty]

Still late but my head is a bit clearer after a cup of coffee. Well, it's obvious. ControlFlow is to be used between activities. Pretty sure this is written somewhere in the Superstructures. Instead you should simply use an association which you could stereotype with something like <<ControlFlow>>.

Btw: How do you create your Profile? Do you forward engineer from a domain model or is it already a kind of domain model? The reason I ask is that some 3 years ago I was involved in a similar task where we had to describe legacy system which were to be replaced by SOA. In the beginning everything was modelled "by convention" but later we adopted a SOA profile.

q.

[Thomas Mercer-Hursh]

Technically, this is not yet a Profile in the sense in which EA expects a Profile to be loaded ... I am looking to make that transition with the current revision.  Right now, it is just a collection of stereotypes that one loads.  We are actually building the model computationally and then just generating specific diagrams or manually dragging items of interest on to a diagram rather than expecting the user to actually draw anything.  The diagrams are for analysis of the existing application, not for creating a new application.  Downstream, we may look at model to model transforms to build the sort of models one would want for OOA/D, but that is a whole separate issue to just analyzing the existing application.  Current users are doing maintenance, not modernization.

[qwerty]

Sounds like an interesting task. Good luck with the next steps.

Cheers, q.