Hi Marcos, See answers inline below. I'm copying the dev list since some of it is of general interest > 1) What do you mean by "hierarchical" ? Is it like an UML 2.0 PackageImport ? > > I mean: if A -- <<import>> --> B, A can use the elements of B and anyone using A will be able > to "see" the elements in B. Thus, if I apply a JavaBeans profile I get a Beans+Java+UML profile. > Is this right?
Yes, that's correct. UML 1.4 also has a facility like this called ElementImport. I don't believe we have a way of creating this from the user interface, but there is support in the Model subsystem. I'm currently testing changes that will allow profiles to consist of multiple top level packages (as they would for this scenario). We already support reading multi-file profiles, but we don't do the bookkeeping correctly to cleanup afterwards. I hope to have this committed today. A related development is a new explorer rule which shows all top level packages in the explorer so that you can see the profile package(s) as well as multiple top level packages from the user models if they exist. One problem with this is that we currently only write out modifications to the main user model, but the user isn't prevented modifying the other models. > 2) I saw that ArgoUML still doesn't support references between different models... so how > would I implement this? Is it worth implementing this support now or is it better to try > some "extra-xmi" support? (I really don't know how complex it is). This is another thing that I'm testing. Currently we can read in multi-file models, but we don't preserve the HREFs when we write them back out. The reading support is a little hidden, but if you look at XmiReferenceResolverImpl.registerSearchPath(), you'll see that it looks up the property "org.argouml.model.modules_search_path" and interprets it as a comma-separated list of directories to look in for external references. I don't think this is documented anywhere and there isn't any UI for setting it, but this could be used as the basis for a search list of profile library directories. I've implemented support so that we correctly write out HREFs for cross-file references and am testing that now. It will preserve HREFs in files that it reads in, but there are still several pieces missing for usable support. Some of the things I can think of off the top of my head include: - We currently copy anything referenced from the profile to the user model. We need to stop doing this and use the profile model elements directly for things to work correctly. - A lot of our code that searches for model elements to present to the user for selection assumes that there is a single root model that can be used as the starting point for all searches. This needs to be generalized to support multi-part profiles and multi-file user models. - Models need to be loaded before they can be referenced. Currently we will load any additional XMI files referenced from the main profile file or user model file, but we need a way for the user to specify new files to be loaded so that they can be referenced. As a first step, we'll probably load any additional files as read-only. When we develop more sophisticated multi-file capabilities we can allow the user the option of specifying which files are read-only and updating/writing multiple files at once. - As mentioned above, we need a way to indicate to the user that a file is read-only. This wasn't an issue when the profile was mostly hidden because anything referenced was copied and the user was allowed to modify the copy. We probably want to have read-only elements greyed out at a minimum and hopefully prevent the user from modifying them at all. I'll send you a note when I've committed the current set of changes and then we can figure out what to do next. Tom --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
