Modeling Menus

[Thomas Mercer-Hursh]

One of the things I would like to do in my current modeling of some legacy software is to model the menu system.  My original thought was to create nested packages corresponding to the menu structure with components for the terminal nodes.  This is quite nice, actually, but has the problem that in this menu structure the same submenu and the same menu selections appear on more than one parent menu.  I.e., Menu A contains Menu B which contains to Menu C, but also Menu D contains Menu E which contains Menu C.  If I put Menu C in the Menu B package, I can create a diagram which shows the nesting link to Menu E, but in the project browser, Menu E doesn't show an entry for Menu C.  I can put the full menu in the Notes and display that, but still the project browser is missing the visual clue.

I could create two nodes, one under each containing menu and link them together, but then the diagram is going to show two of Menu C with links between them instead of a single menu.

Is there any other way by which I could have Menu C show up within both the Menu B and Menu E packages, but there be only one actual instance of Menu C?

[peter.zrnko]

What about to define two classes Menu and MenuItem and model your menu as instances of these classes.

In project (Project Browser) you can have:
Menu System
- Menu A (Instance of Menu)
 - Item A1 (Instance of MenuItem)
 - Item A2
 ...
- Menu B
 - Item A1
 - Item A2
 ...
...

It means there will be no menu hierarchy in Project browser. Just items under menus. The menu hierarchy will be in diagrams.

You can model menu hierarchy in diagram(s) using some kind of connector (e.g. dependency). Or you can model each level on a separate diagram and use composite elements to navigate to sublevel.

In case you want one instance of Menu with name "Menu C" and use it more than one time in your hierarchy, it's necessary to use separate diagrams.

In case you prefer using just one diagram, you can have two instances of Menu with identical names "Menu C", but these will duplicate Menu C in your project (Project Browser).

[Thomas Mercer-Hursh]

In diagrams, at whatever level of coverage, I have no problem showing the menu relationships.  My issue is the the Project browser.  There, it appears I can't have one menu be parented by two parents.  This isn't just a UI issue since I can see that t_project and t_object both contain just a single parent id field, so there is no data structure to support multiple parents.

If this was just menus, I would just fudge something and move on, but I have the same issue in a number of other places as well.  E.g., this code uses include files and an include file can be included in multiple programs, i.e., it has multiple parent.  Likewise, we would like to have a stereotype «oeFunctionalUnit» for all of the code which might be reached from any given menu selection, one or more compile units.  Again, the same compile unit can be in more than one functional unit.

I was hoping for some kind of standard best practice for creating clones which would like together or something.

[«Midnight»]

Thomas,

I get the impression you're asking too much of the (current) project browser.

Read through the Suggestions section of the forum for the past day - look for Favorites. Neil has given a glimpse of something in the works for EA 7.1 (ish) that might give you some relief, though it is apparently just coming off the drawing board now.

[BTW, I get the impression that we're fairly close to 7.1 (a month or two). This would match past x.1 version timings well.]

David

[Thomas Mercer-Hursh]

While that 7.1 enhancement may be nice, I don't think it relates to the problem.  This isn't just a UI thing, but a down deep structural thing since t_package and t_object both have just a single parent.  My guess is that it is an example of OO bias in UML.  In OO code, I would have a clean package hierarchy and, if two different objects needed to use some common class or whatever, then they would both point to it at some specific position in the class hierarchy.

Here, however, that is just not the way things are.  While some of the include files may be in common library directories as source, this isn't mandatory and, besides, the code is incorporated directly into the compiled code.  Similarly, there is no reason why exactly the same menu ... not to mention menu item ... can't be pointed to by two or more different parent menus.  A simple example is having two different top level menus, one for headquarters and one for the store.  Both probably need a customer maintenance menu and the contents of that menu are probably identical.

I have pretty much come to the conclusion that I simply can't use packages for this, or, if I do use packages, I can't rely on the package contents being complete, but instead will need to use the notes to list the complete contents.

[«Midnight»]

Perhaps your real issue is with the UML metamodel, which is out of our hands, as well as Sparx' hands.

[Thomas Mercer-Hursh]

Perhaps ... that OO bias thing.  That doesn't keep me from hoping that there is a standard way of addressing the issue within the context of that model.

[KP]

Thomas, it seems to me that you are trying to represent 0..* ---- 0..* associations within a tree structure, and that is using the wrong tool for the job. Such associations are best represented on a diagram using Association relationships, so maybe that is the direction you should be looking?

[Thomas Mercer-Hursh]

I know that I can do it on the diagram, but I still want to be able to find the component in the project browser, so the issue is how to categorize it.  What I am experimenting with now is as follows:

The basic principle will be that common code would be "lifted" to the level of its commonality.  I.e., if I have a package structure of
A
..B
....F
..C
....D
....E

And D and E shared a component which was not shared anywhere else, then the shared component would be put in a package under C at the same level as D and E, but, if the component were shared by D and F, then the component would be put in a package at the level of B and C.   For now, all shared components within a package will just be put in a package called Shared, but this could be broken down into meaningful units when there were a lot of them.

The actual contents of a package will be shown in the notes and we will display the note on the diagram instead of the package contents.  When a component is not in the current package, but is instead in one of the shared packages, the path name will be shown for that component.

This is going to create a potential maintenance nightmare since notes won't automatically readjust to package changes, but possibly we can create an add-in for that.

[«Midnight»]

Thomas,

I think it is worth rereading what Neil said, you're trying to use the wrong tool for the job.

In any case, you can solve your immediate problem by having the shared items owned the lowest common ancestor of their users. In the case you describe that would be A.

David

[Thomas Mercer-Hursh]

Well, there is more than one job here.  As I have said, I have no problem modeling any of these situations in the diagrams, which implies that components, packages, connectors, etc. work together to describe the actual relationships.  But, one doesn't want to just list 5000 components in alphabetical order in the project browser and have to scroll forever when one wanted to find a particular component.  Likewise, with 5000 components, one is going to want to have hierarchical and localized diagrams because otherwise it is just going to be too complex to find anything.  So, there is a need to organize components in the project browser so that one can find them and the same organization can help organize the diagrams so that one can find the diagram of interest as well.  I'm not trying to model using the project browser, I'm just trying to organize.

[«Midnight»]

Perhaps the new browser views in 7.1 will work for you then.

Otherwise, perhaps you should whip up an add-in and design your own dockable pane to work in concert with the Browser. There's some work there of course, but if this is really bothering you it is worth considering.

David

[Thomas Mercer-Hursh]

Given that I can't declare more than one parent in the underlying schema, I don't know what would drive a special browser view or a custom add-in.  It would need to be a browser based on links.

[peter.zrnko]

... browser based on links

Hierarchy window is a kind of browser based on links.

Limitations of this view:
Depth of the hierarchy is limited by setting "Max Hierarchy View Depth".
Context menu in this window is very limited.

Another browser based on links is the Relationship window.
There is no tree in this window.


I agree with you, that a better Browser based on links would be a real improvement.
I suggest to start from the Hierarchy window and makes some improvements:
- remove the option "Max Hierarchy View Depth", thus enabling unlimited depth
- construct the tree in this window dynamically, as user click on the "+" to expand a branch
- add functionality to the context menu in Hierarchy window.

[Thomas Mercer-Hursh]

Very interesting at first glance.  I'll have to explore that along with my other approaches and see what I can come up with.