Re: Models sharing core entities

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]>
>
>