Login | Register
My pages Projects Community openCollabNet

Discussions > users > Re: [argouml-users] Models sharing core entities

argouml
Discussion topic

Back to topic list

Re: [argouml-users] Models sharing core entities

Author dgz
Full name Diego Gutierrez Zaldivar
Date 2007-05-26 07:34:17 PDT
Message 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* <rwheeler@artifac​t-software.com
>> <mailto:rwheeler@​artifact-software.co​m>> 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* <rwheeler@artifac​t-software.com
>> <mailto:rwheeler@​artifact-software.co​m>
>> > <mailto: rwheeler at artifact-software dot com
>> <mailto:rwheeler@​artifact-software.co​m>>> 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: users-unsubscribe@ar​gouml.tigris.org
>> <mailto:users-uns​ubscribe at argouml dot tig​ris.org>
>> > <mailto:users-uns​ubscribe at argouml dot tig​ris.org
>> <mailto:users-uns​ubscribe at argouml dot tig​ris.org>>
>> > For additional commands, e-mail:
>> users-help at argouml dot tigris dot org <mailto:users-hel​p@argouml.tigris.org​>
>> > <mailto:users-hel​p@argouml.tigris.org​
>> <mailto:users-hel​p@argouml.tigris.org​>>
>> >
>> >
>>
>>
>> --------------------​--------------------​--------------------​---------
>> To unsubscribe, e-mail: users-unsubscribe@ar​gouml.tigris.org
>> <mailto:users-uns​ubscribe at argouml dot tig​ris.org>
>> For additional commands, e-mail: users-help at argouml dot tigris dot org
>> <mailto:users-hel​p@argouml.tigris.org​>
>>
>>
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: users-unsubscribe@ar​gouml.tigris.org
> For additional commands, e-mail: users-help at argouml dot tigris dot org
>
>

--

**XNG **| Diego Gutierrez Zaldivar
Tel.: [54] 11 4780.0667

Fax: [1] 320 514.4271http://xng.dyndns.biz/
Attachments

« Previous message in topic | 13 of 14 | Next message in topic »

Messages

Show all messages in topic

Models sharing core entities rwheeler Ron Wheeler 2007-05-24 06:40:53 PDT
     Latest release 0.253 - File Format from 0.252 to 0253 is not compatible rhurst Raymond Hurst 2007-05-24 10:04:23 PDT
         Re: [argouml-users] Latest release 0.253 - File Format from 0.252 to 0253 is not compatible bobtarling Bob Tarling 2007-05-24 10:07:27 PDT
             Re: [argouml-users] Latest release 0.253 - File Format from 0.252 to 0253 is not compatible Bob Palank <srfpala at earthlink dot net> Bob Palank <srfpala at earthlink dot net> 2007-05-24 13:12:24 PDT
                 URLs in diagrams tfmorris Tom Morris 2007-05-25 12:52:47 PDT
         Don't use 0.25.3 tfmorris Tom Morris 2007-05-25 12:24:52 PDT
     Re: [argouml-users] Models sharing core entities phidias Mark Fortner 2007-05-25 08:08:59 PDT
         Re: [argouml-users] Models sharing core entities rwheeler Ron Wheeler 2007-05-25 11:11:00 PDT
             Re: [argouml-users] Models sharing core entities phidias Mark Fortner 2007-05-25 13:08:07 PDT
                 RE: [argouml-users] Models sharing core entities tfmorris Tom Morris 2007-05-25 13:55:02 PDT
                     Re: [argouml-users] Models sharing core entities rwheeler Ron Wheeler 2007-05-25 19:34:29 PDT
                 Re: [argouml-users] Models sharing core entities rwheeler Ron Wheeler 2007-05-25 19:31:30 PDT
                     Re: [argouml-users] Models sharing core entities dgz Diego Gutierrez Zaldivar 2007-05-26 07:34:17 PDT
     RE: [argouml-users] Models sharing core entities tfmorris Tom Morris 2007-05-25 12:34:47 PDT
Messages per page: