I agree with Ron that exporting parts of the model like we do when we generate code would be a nice feature. Another nice improvement would be to do the same with the import.
I'm facing similar challenges as Ron and what I did in the meantime y merge the models when I generate the code. To achieve this I create a dummy class on the specific models to stablish the relationships and this dummy class is never generated. An example is I have a module with the Party pattern classes in a separate ArgoUML file so if I need the Party feature in a new project I create a dummy Party class in the project ArgoUML file. In this way I can create associations or generalizations to it. When I generate the code of the project I leave this dummy Party class out because the real Party class was already generated and coded using the Party ArgoUML. I don't know if I was clear enough and hopefully this can help somebody. Best wishes, Diego Ron Wheeler wrote: > I did a quick test. The export seems to export too much (whole model). > Perhaps this can be made to work but it would be nice to be able to > select a package to export. > I did not try the import to see how it deals with duplicates. > > Ron > > Mark Fortner wrote: >> Oh I see what you're trying to do. I misunderstood what you were >> trying to accomplish. >> If you have a core set of classes that you want to reuse in a >> a number of different models you can simply export those core classes >> into an XMI file >> and import that file into other models. >> >> In your dependent projects, you just add those entities that you've >> imported to the appropriate diagrams and add >> whatever associations you want. >> >> I'm not sure if the -D parameter trick I talked about will keep >> updating your dependent >> diagrams, but that should be easy enough to test out. >> >> My earlier comments were around handling deployment of applications, >> rather than construction >> of applications. >> >> Hope I didn't confuse you too much, >> >> Mark >> >> On 5/25/07, *Ron Wheeler* <[EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]>> wrote: >> >> It is a bit over my head but I can understand the direction that >> you are >> pointing. >> Your example is a bit different than what I am looking for but >> perhaps >> not that different in solution. >> >> I suppose that I can take the AndroMDA starting model, add my core >> classes (employee, business unit, etc.) and then save this as a >> model >> for starting each portlet. >> >> It appears that I still have the on-going problem of propagating >> changes >> made to the core classes to all of the models that might be affected >> when I go from one major version to another where most of the core >> classes get minor (I hope) enhancements. >> >> Is there any solution for this? >> >> Are there any tools for applying transformations to XMI? >> >> Ron >> >> Mark Fortner wrote: >> > Ron, >> > I usually create stereotypes and tagged values for the information >> > that I want associated with each object. For example, if I >> want to >> > create an EJB deployment descriptor, I take the fields that are >> > required for the descriptor, create a stereotype called EJB, add >> those >> > fields to the EJB stereotype, and export this as an XMI file. >> > >> > You can then import the XMI file or use it as part of a profile (a >> > collection of stereotypes) to suit your needs. You can use the ' >> > -Dargo.defaultModel=MyProfile.xmi' startup parameter to start >> ArgoUML with your profile. >> > >> > You can apply any of the stereotypes from the profile to the >> objects >> > in each of your projects. When you're finished you can export >> your >> > projects and XMI. You have to apply a transform to the XMI to >> turn it >> > into a deployment descriptor, but that's about the limit of the >> work. >> > >> > I suspect that AndroMDA has the ability to handle those kinds of >> > transformations. How you integrate this in to AndroMDA, is an >> > "exercise for the student", as my old Calculus professor would >> say. >> > >> > If you don't want to rely on AndroMDA to handle the last bit, >> then you >> > can put this into an Ant target. It's simply a matter of >> unzipping the >> > ArgoUML, and applying your transform to the embedded XMI file. >> > >> > Hope this helps, >> > >> > Mark >> > >> > On 5/24/07, *Ron Wheeler* <[EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]> >> > <mailto: [EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]>>> wrote: >> > >> > I am planning to use ArgoUMl with AmdroMDA to generate as >> much of a >> > Jetspeed Portal as possible. >> > >> > One of the issues that I think will come up in using >> Jetspeed is the >> > need/ability to break down a fairly big application into a >> set of >> > JSR-168 portlets. >> > This implies, I think, that I am going to have a number of >> AndroMDA >> > projects in ArgoUML ; one for each Portlet since each >> Portlet is an >> > independent object that is loaded into the Jetspeed Portal >> > depending on >> > the user profile, etc. >> > >> > I think that this is going to result in the same basic >> entities >> > (employee, business unit, code tables, etc.) appearing in >> many ArgoUML >> > models. >> > >> > It seems to make sense to define and maintain these entities >> in one >> > place and import them into each model in much the same way >> that the >> > basic AndroMDA entities are incorporated into the model at the >> > start of >> > a AndroMDA project. >> > >> > Is there some way to do this, using ArgoUML, so that >> changes to >> > the core >> > entities can be easily replicated to all of the portlet >> models without >> > having to go to each model and manually change each class in >> the core >> > that has changed. The work is one issue; the probability of >> > forgetting >> > to make a change or making an error in making the changes in >> one >> > portlet >> > model is pretty high and will be hard to find when different >> portlets >> > handle the same entity differently. >> > >> > Suggestions about how the core entities should be organized >> to make >> > portlet modelling easier would be appreciated. >> > >> > Ideally I think that I would like to be able to export part >> (or >> > all) of >> > a master model of classes and import them into other models >> > overwriting >> > any existing instances of the same entity. >> > >> > >> --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]> >> > <mailto:[EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]>> >> > For additional commands, e-mail: >> [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> >> > <mailto:[EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]>> >> > >> > >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]> >> For additional commands, e-mail: [EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]> >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- **XNG **| Diego Gutierrez Zaldivar Tel.: [54] 11 4780.0667 Fax: [1] 320 514.4271http://xng.dyndns.biz/
