Control Flow links

[Thomas Mercer-Hursh]

In a model which I generated from some ABL code, I have Menus and Functional Units (all code reachable from a given menu selection).  Both are packages.  When I generated this model, I connected menu to menu and menu to functional unit with a connector of type Control Flow, which seemed like a reasonable idea.

In trying to move this repository to an EAP file via XMI (see thread under bugs) I have lost the stereotypes on the menus and these Control Flow links.  In trying to manually recreate them, I don't see anywhere that I can directly specify Control Flow as the type.  If I create some other type of connector, e.g., Dependency, and then right click->Advanced->Change Type then Control Flow is available, but selecting it tells me that is not UML compliant.

What *should* I be doing here?

[Paolo F Cantoni]

Hi Thomas,

Disable UML compliance during this process...

It may be that EA is checking UML compliance at the wrong point in the type conversion.

If you do this for one connector, then reenable and make a change, you should get NO complaint.  In which case the outcome you were desiring is UML compatible (according to EA ) and the process was flawed.

HTH,
Paolo

[«Midnight»]

...and a bug report to Sparx would be in order.

[Thomas Mercer-Hursh]

FWIW, what I ended up doing was creating the links as Dependency and then using Access to change them to ControlFlow.

[Paolo F Cantoni]

FWIW, what I ended up doing was creating the links as Dependency and then using Access to change them to ControlFlow.

Been there done that... It's one of EA's saving graces that you can do an AWFUL lot behind it's back.  To get around the issues at the front...

Paolo

[KP]

According to UML, a ControlFlow connects two ActivityNode elements, and Package isn't an ActivityNode, so the error message is correct. Paolo's suggestion of disabling UML syntax checking (Tools > Options > Diagram > Strict UML Syntax) will allow you to get around the error message, if you wish.

[Thomas Mercer-Hursh]

OK, that explains why it is supposedly a violation, but what would one use in its place to be more correct.?

[KP]

I think either a Dependency (suitably stereotyped) denoting that one package depends on a flow of control from the other package, or an InformationFlow which will allow you to define what it is that is flowing.

Any other suggestions, anyone?

[Paolo F Cantoni]

In a model which I generated from some ABL code, I have Menus and Functional Units (all code reachable from a given menu selection).  Both are packages.  When I generated this model, I connected menu to menu and menu to functional unit with a connector of type Control Flow, which seemed like a reasonable idea.

Hi Thomas,

Just to be clear, are you saying previously EA allowed you to do this?  Did you do it via the API and thus you're discussing a difference between the automation API and the UI?

Paolo

[Thomas Mercer-Hursh]

The model was created by directly writing to the database, not even the API.

[Thomas Mercer-Hursh]

Neither Dependency nor Information Flow seem to convey quite the same meaning as ControlFlow.  True, the stereotype overrides whatever is underneath, but this really is a flow of control.

[Paolo F Cantoni]

The model was created by directly writing to the database, not even the API.

Been there, doing that...

It can be quite satisfying...  

I think one reason why you're having the UML related problem is actually a form of self inconsistency in UML.  "Packages" in UML have peculiar aspects, in my view, and we make a mistake (and I did, till I thought about things more) in imbuing them with the normal real world ontological aspects of packages.

So, I think the notion of flow of control from one UML package to another is actually fundamentally incorrect.  That's not to say that there isn't a flow of control from one entity to another here (and I agree with you about the connection between the menus and the functional units).  What I'm questioning is using a package as the representation of the entities.  If you like, we could continue discussion on this either on-line or off.

Paolo

[Thomas Mercer-Hursh]

OK, I'm game ... what would one use besides a Package?  In my model overall (a copy of which is available here http://www.cintegrity.com/FTP/ProLintEA_20081128.zip ), there is a Data Model for the database aspects, a Component Model which includes Program Units, Compile Units, and Include Units ... all physical units of code in the real system, and a User Interface Model.  The User Interface Model consists of Functional Units, Menus, and Dynamic Choice Sets.  We can ignore the latter in the present discussion because it is a menu-like thing where the choice is made at a different time than the real time menu selection.

Functional Units are a container for all of the code which is reachable by a given menu selection.  Hence, a Package, although the package doesn't actually contain anything since the components are all over in the Component Model.  A Menu links to one or more Functional Units, thus I also used Package for a menu, even though it doesn't contain anything.

[Paolo F Cantoni]

Right...  A brief response because I'm actually at work at my day job (here down under).

A package in UML IS a namespace.  That's it's only REAL job - to collect together a set of things that can be uniquely identified within that namespace.

The problem, in my view, is that most modelling products also use the fact that ipso facto, a namespace is a "container" to have the UML package also perform the functions of a "folder" and general container.  This is where things get conflated.

If you need a container element to actually contain (by nesting) other elements, then you should use an element, not a package.  While I was still at Ripple (RIP - pun intended!) my fellow architect and I came to the conclusion that we should use packages only as namespaces and use other types of elements for grouping.  The fact that EA forced that on us (since you can't place packages under elements - see postings on the subject) sort of helped refine our understanding.

So, in summary, if you have a "real" container within the model, don't use a package to model - use an element.

Does that help?
Paolo

[Thomas Mercer-Hursh]

Does that help?

Sounds reasonable ...