Login | Register
My pages Projects Community openCollabNet

Discussions > users > Models sharing core entities

argouml
Discussion topic

Hide all messages in topic

All messages in topic

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

Re: [argouml-users] Models sharing core entities

Author rwheeler
Full name Ron Wheeler
Date 2007-05-25 19:34:29 PDT
Message Great.
It sounds like the project is really getting some good support and is
getting to the point of being a real contender with a user community
that is active and looking at enterprise-scale modelling.
I have a lot to learn but I am optimistic that ArgoUML is going to be
able to support what I need in the longer term.

Ron

Tom Morris wrote:
>> 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.
>>
>
> No, it won't. Any profile element, whether from our standard profile or a
> user-specified one like the AndroMDA profile, gets copied into the project
> when it's first used. It's definition is effectively frozen at that point
> unless you change the copy in the project. If you open the project again
> with an updated version of the profile, nothing changes in the project.
>
> We recognize that this isn't desirable and are working to change the
> behavior.
>
> Tom
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: users-unsubscribe@ar​gouml.tigris.org
> For additional commands, e-mail: users-help at argouml dot tigris dot org
>
>
>
>

Re: [argouml-users] Models sharing core entities

Author rwheeler
Full name Ron Wheeler
Date 2007-05-25 19:31:30 PDT
Message 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​>
>
>

RE: [argouml-users] Models sharing core entities

Author tfmorris
Full name Tom Morris
Date 2007-05-25 13:55:02 PDT
Message > 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.

No, it won't. Any profile element, whether from our standard profile or a
user-specified one like the AndroMDA profile, gets copied into the project
when it's first used. It's definition is effectively frozen at that point
unless you change the copy in the project. If you open the project again
with an updated version of the profile, nothing changes in the project.

We recognize that this isn't desirable and are working to change the
behavior.

Tom

Re: [argouml-users] Models sharing core entities

Author phidias
Full name Mark Fortner
Date 2007-05-25 13:08:07 PDT
Message 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> 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>> 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>
> > 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
>
>
Attachments

URLs in diagrams

Author tfmorris
Full name Tom Morris
Date 2007-05-25 12:52:47 PDT
Message [Please start a new thread with an appopriate subject for new topics]

Bob Palank asked:

> From: Bob Palank [mailto:srfpala at earthlink dot net]
> Sent: Thursday, May 24, 2007 4:12 PM
> Subject: Re: [argouml-users] Latest release 0.253 - File
> Format from 0.252 to 0253 is not compatible
>
> Has anyone considered adding a feature to all displayed
> objects in all UML
> Diagrams that allows one to right click on the
> object and then click on a URL that allows further
> description/details for
> that object ?

Here's a list of the currently requested features and enhancements
http://argouml.tigri​s.org/issues/buglist​.cgi?Submit+query=Su​bmit+query&issue​
_type=ENHANCEMENT​&issue_type=FEATURE​&issue_status=NE​W&issue_status=S​TARTED&i
ssue_status=REOPENED

If you find a request that matches what you are interested in, feel free to
add your vote and/or your comments.

> If not, how does one start to work on such a service?

One easy way to approach this might be to extend the Documentation field
(stored in a TaggedValue) to allow HTML instead of just plain text. This
would have the benefit of allowing formatting as well as clickable links.

If you're interested in working on such an enhancement, check out the
developer notes http://argouml.tigri​s.org/dev.html and follow up on the dev
list with any questions that you might have.

Tom

RE: [argouml-users] Models sharing core entities

Author tfmorris
Full name Tom Morris
Date 2007-05-25 12:34:47 PDT
Message > 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.

There isn't a good way to do this right now. Our current profile mechanism
uses copy-on-reference semantics, so even if a profile were powerful enough
to meet your needs, you'd be left with stale versions of the elements
(stereotypes, etc) which had been copied into your project that wouldn't
reflect any updates to the profile.

This enhancement request
http://argouml.tigri​s.org/issues/show_bu​g.cgi?id=3497 deals with this issue,
so you can add your votes there.

Some of the underlying framework needed to implement our improved profile
support (a Google Summer of Code project) will also benefit what you want to
do, so you should see improvements by the end of the summer.

Tom

Don't use 0.25.3

Author tfmorris
Full name Tom Morris
Date 2007-05-25 12:24:52 PDT
Message If you are using the developer releases don't upgrade to 0.25.3. It has a
critical problem which prevents it from being useful.
 
Of course, the safest option is to use the latest stable release, 0.24, but
if you want to help with testing develop releases, please use either 0.25.2
or wait for 0.25.4.
 
Tom

-----Original Message-----
From: Raymond Hurst [mailto:Raymond dot Hurst at wdc dot com]
Sent: Thursday, May 24, 2007 1:04 PM
To: users at argouml dot tigris dot org
Subject: [argouml-users] Latest release 0.253 - File Format from 0.252 to
0253 is not compatible



Hi,

Is there a file format change between 0.252 and 0,253?

 

I tried reading a file previously edited with 0.252 and I got the following:

 

Error opening file : FDE.zargo
Attachments

Re: [argouml-users] Models sharing core entities

Author rwheeler
Full name Ron Wheeler
Date 2007-05-25 11:11:00 PDT
Message 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>> 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>
> For additional commands, e-mail: users-help at argouml dot tigris dot org
> <mailto:users-hel​p@argouml.tigris.org​>
>
>

Re: [argouml-users] Models sharing core entities

Author phidias
Full name Mark Fortner
Date 2007-05-25 08:08:59 PDT
Message 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> 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
> For additional commands, e-mail: users-help at argouml dot tigris dot org
>
>
Attachments

Re: [argouml-users] Latest release 0.253 - File Format from 0.252 to 0253 is not compatible

Author Bob Palank <srfpala at earthlink dot net>
Full name Bob Palank <srfpala at earthlink dot net>
Date 2007-05-24 13:12:24 PDT
Message Has anyone considered adding a feature to all displayed objects in all UML
Diagrams that allows one to right click on the
object and then click on a URL that allows further description/details for
that object ?
If not, how does one start to work on such a service?
I think this would offer tremendous versatility and value.
BR
  Bob Palank
----- Original Message -----
From: "Bob Tarling" <bob dot tarling at gmail dot com>
To: <users at argouml dot ti​gris.org>
Sent: Thursday, May 24, 2007 12:07 PM
Subject: Re: [argouml-users] Latest release 0.253 - File Format from 0.252
to 0253 is not compatible


> This look to be a bug in the latest non-stable release that I'm
> intending to take a look at this evening.
>
> If you're testing the releases in development then please keep
> questions to the dev list rather than user list.
>
> Regards
>
> Bob.
>
>
>
> On 24/05/07, Raymond Hurst <Raymond dot Hurst at wdc dot com> wrote:
>>
>>
>>
>>
>> Hi,
>>
>> Is there a file format change between 0.252 and 0,253?
>>
>>
>>
>> I tried reading a file previously edited with 0.252 and I got the
>> following:
>>
>>
>>
>> Error opening file : FDE.zargo
>> ____________________​____________
>>
>>
>> System Info:
>>
>> ArgoUML version : 0.25.3
>>
>> Java Version : 1.6.0_01
>>
>> Java Vendor : Sun Microsystems Inc.
>>
>> Java Vendor URL : http://java.sun.com/
>>
>> Java Home Directory : C:\Program Files\Java\jre1.6.0_01
>>
>> Java Classpath : argouml.jar
>>
>> Operation System : Windows XP, Version 5.1
>>
>> Architecture : x86
>>
>> User Name : hurst_r
>>
>> User Home Directory : C:\Documents and Settings\hurst_r
>>
>> Current Directory : C:\programs\ArgoUM​L\ArgoUML_0253
>>
>> JVM Total Memory : 1065484288
>>
>> JVM Free Memory : 1005323512
>> ____________________​____________
>>
>>
>> Error occurred at : Thu May 24 10:02:56 PDT 2007
>>
>> Cause : java.lang.NullPointerException
>>
>> at org.tigris.gef.prese​ntation.Fig.setBound​s(Fig.java:1432)
>>
>> at
>> org.argouml.persiste​nce.PGMLStackParser.​constructFig(PGMLSta​ckParser.java:465)
>>
>> at
>> org.tigris.gef.persi​stence.pgml.PGMLStac​kParser.getHandler(P​GMLStackParser.java:​385)
>>
>> at
>> org.argouml.persiste​nce.PGMLStackParser.​getHandler(PGMLStack​Parser.java:140)
>>
>> at
>> org.tigris.gef.persi​stence.pgml.BaseHand​ler.getElementHandle​r(BaseHandler.java:1​41)
>>
>> at
>> org.tigris.gef.persi​stence.pgml.BaseHand​ler.getElementOrUnkn​ownHandler(BaseHandl​er.java:110)
>>
>> at
>> org.tigris.gef.persi​stence.pgml.BaseHand​ler.startElement(Bas​eHandler.java:159)
>>
>> at
>> com.sun.org.apache.x​erces.internal.parse​rs.AbstractSAXParser​.startElement(Unknow​n
>> Source)
>>
>> at
>> com.sun.org.apache.x​erces.internal.impl.​XMLDocumentFragmentS​cannerImpl.scanStart​Element(Unknown
>> Source)
>>
>> at
>> com.sun.org.apache.x​erces.internal.impl.​XMLDocumentFragmentS​cannerImpl$Fragment​ContentDriver.next(U​nknown
>> Source)
>>
>> at
>> com.sun.org.apache.x​erces.internal.impl.​XMLDocumentScannerIm​pl.next(Unknown
>> Source)
>>
>> at
>> com.sun.org.apache.x​erces.internal.impl.​XMLDocumentFragmentS​cannerImpl.scanDocum​ent(Unknown
>> Source)
>>
>> at
>> com.sun.org.apache.x​erces.internal.parse​rs.XML11Configuratio​n.parse(Unknown
>> Source)
>>
>> at
>> com.sun.org.apache.x​erces.internal.parse​rs.XML11Configuratio​n.parse(Unknown
>> Source)
>>
>> at
>> com.sun.org.apache.x​erces.internal.parse​rs.XMLParser.parse(U​nknown
>> Source)
>>
>> at
>> com.sun.org.apache.x​erces.internal.parse​rs.AbstractSAXParser​.parse(Unknown
>> Source)
>>
>> at
>> com.sun.org.apache.x​erces.internal.jaxp.​SAXParserImpl$JAXPS​AXParser.parse(Unkno​wn
>> Source)
>>
>> at javax.xml.parsers.SA​XParser.parse(Unknow​n Source)
>>
>> at
>> org.tigris.gef.persi​stence.pgml.PGMLStac​kParser.readDiagram(​PGMLStackParser.java​:157)
>>
>> at
>> org.tigris.gef.persi​stence.pgml.PGMLStac​kParser.readDiagram(​PGMLStackParser.java​:123)
>>
>> at
>> org.argouml.persiste​nce.PGMLStackParser.​readDiagram(PGMLStac​kParser.java:289)
>>
>> at
>> org.argouml.persiste​nce.DiagramMemberFil​ePersister.load(Diag​ramMemberFilePersist​er.java:67)
>>
>> at
>> org.argouml.persiste​nce.UmlFilePersister​.doLoad(UmlFilePersi​ster.java:372)
>>
>> at
>> org.argouml.persiste​nce.ZargoFilePersist​er.doLoad(ZargoFileP​ersister.java:324)
>>
>> at
>> org.argouml.ui.Proje​ctBrowser.loadProjec​t(ProjectBrowser.jav​a:1482)
>>
>> at org.argouml.applicat​ion.Main.main(Main.j​ava:369)
>>
>> -------
>>
>> Full exception : org.argouml.persiste​nce.OpenException:
>> java.lang.NullPointerException
>>
>> at
>> org.argouml.persiste​nce.DiagramMemberFil​ePersister.load(Diag​ramMemberFilePersist​er.java:74)
>>
>> at
>> org.argouml.persiste​nce.UmlFilePersister​.doLoad(UmlFilePersi​ster.java:372)
>>
>> at
>> org.argouml.persiste​nce.ZargoFilePersist​er.doLoad(ZargoFileP​ersister.java:324)
>>
>> at
>> org.argouml.ui.Proje​ctBrowser.loadProjec​t(ProjectBrowser.jav​a:1482)
>>
>> at org.argouml.applicat​ion.Main.main(Main.j​ava:369)
>>
>> Caused by: java.lang.NullPointerException
>>
>> at org.tigris.gef.prese​ntation.Fig.setBound​s(Fig.java:1432)
>>
>> at
>> org.argouml.persiste​nce.PGMLStackParser.​constructFig(PGMLSta​ckParser.java:465)
>>
>> at
>> org.tigris.gef.persi​stence.pgml.PGMLStac​kParser.getHandler(P​GMLStackParser.java:​385)
>>
>> at
>> org.argouml.persiste​nce.PGMLStackParser.​getHandler(PGMLStack​Parser.java:140)
>>
>> at
>> org.tigris.gef.persi​stence.pgml.BaseHand​ler.getElementHandle​r(BaseHandler.java:1​41)
>>
>> at
>> org.tigris.gef.persi​stence.pgml.BaseHand​ler.getElementOrUnkn​ownHandler(BaseHandl​er.java:110)
>>
>> at
>> org.tigris.gef.persi​stence.pgml.BaseHand​ler.startElement(Bas​eHandler.java:159)
>>
>> at
>> com.sun.org.apache.x​erces.internal.parse​rs.AbstractSAXParser​.startElement(Unknow​n
>> Source)
>>
>> at
>> com.sun.org.apache.x​erces.internal.impl.​XMLDocumentFragmentS​cannerImpl.scanStart​Element(Unknown
>> Source)
>>
>> at
>> com.sun.org.apache.x​erces.internal.impl.​XMLDocumentFragmentS​cannerImpl$Fragment​ContentDriver.next(U​nknown
>> Source)
>>
>> at
>> com.sun.org.apache.x​erces.internal.impl.​XMLDocumentScannerIm​pl.next(Unknown
>> Source)
>>
>> at
>> com.sun.org.apache.x​erces.internal.impl.​XMLDocumentFragmentS​cannerImpl.scanDocum​ent(Unknown
>> Source)
>>
>> at
>> com.sun.org.apache.x​erces.internal.parse​rs.XML11Configuratio​n.parse(Unknown
>> Source)
>>
>> at
>> com.sun.org.apache.x​erces.internal.parse​rs.XML11Configuratio​n.parse(Unknown
>> Source)
>>
>> at
>> com.sun.org.apache.x​erces.internal.parse​rs.XMLParser.parse(U​nknown
>> Source)
>>
>> at
>> com.sun.org.apache.x​erces.internal.parse​rs.AbstractSAXParser​.parse(Unknown
>> Source)
>>
>> at
>> com.sun.org.apache.x​erces.internal.jaxp.​SAXParserImpl$JAXPS​AXParser.parse(Unkno​wn
>> Source)
>>
>> at javax.xml.parsers.SA​XParser.parse(Unknow​n Source)
>>
>> at
>> org.tigris.gef.persi​stence.pgml.PGMLStac​kParser.readDiagram(​PGMLStackParser.java​:157)
>>
>> at
>> org.tigris.gef.persi​stence.pgml.PGMLStac​kParser.readDiagram(​PGMLStackParser.java​:123)
>>
>> at
>> org.argouml.persiste​nce.PGMLStackParser.​readDiagram(PGMLStac​kParser.java:289)
>>
>> at
>> org.argouml.persiste​nce.DiagramMemberFil​ePersister.load(Diag​ramMemberFilePersist​er.java:67)
>>
>> ... 4 more
>>
>>
>>
>>
>>
>> Ray Hurst
>>
>> Western Digital
>>
>> 20511 Lake Forest Drive
>>
>> Lake Forest, CA 92630
>>
>> 949-672-9853
>>
>>
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: users-unsubscribe@ar​gouml.tigris.org
> For additional commands, e-mail: users-help at argouml dot tigris dot org
>

Re: [argouml-users] Latest release 0.253 - File Format from 0.252 to 0253 is not compatible

Author bobtarling
Full name Bob Tarling
Date 2007-05-24 10:07:27 PDT
Message This look to be a bug in the latest non-stable release that I'm
intending to take a look at this evening.

If you're testing the releases in development then please keep
questions to the dev list rather than user list.

Regards

Bob.



On 24/05/07, Raymond Hurst <Raymond dot Hurst at wdc dot com> wrote:
>
>
>
>
> Hi,
>
> Is there a file format change between 0.252 and 0,253?
>
>
>
> I tried reading a file previously edited with 0.252 and I got the following:
>
>
>
> Error opening file : FDE.zargo
> ____________________​____________
>
>
> System Info:
>
> ArgoUML version : 0.25.3
>
> Java Version : 1.6.0_01
>
> Java Vendor : Sun Microsystems Inc.
>
> Java Vendor URL : http://java.sun.com/
>
> Java Home Directory : C:\Program Files\Java\jre1.6.0_01
>
> Java Classpath : argouml.jar
>
> Operation System : Windows XP, Version 5.1
>
> Architecture : x86
>
> User Name : hurst_r
>
> User Home Directory : C:\Documents and Settings\hurst_r
>
> Current Directory : C:\programs\ArgoUM​L\ArgoUML_0253
>
> JVM Total Memory : 1065484288
>
> JVM Free Memory : 1005323512
> ____________________​____________
>
>
> Error occurred at : Thu May 24 10:02:56 PDT 2007
>
> Cause : java.lang.NullPointerException
>
> at org.tigris.gef.prese​ntation.Fig.setBound​s(Fig.java:1432)
>
> at
> org.argouml.persiste​nce.PGMLStackParser.​constructFig(PGMLSta​ckParser.java:465)
>
> at
> org.tigris.gef.persi​stence.pgml.PGMLStac​kParser.getHandler(P​GMLStackParser.java:​385)
>
> at
> org.argouml.persiste​nce.PGMLStackParser.​getHandler(PGMLStack​Parser.java:140)
>
> at
> org.tigris.gef.persi​stence.pgml.BaseHand​ler.getElementHandle​r(BaseHandler.java:1​41)
>
> at
> org.tigris.gef.persi​stence.pgml.BaseHand​ler.getElementOrUnkn​ownHandler(BaseHandl​er.java:110)
>
> at
> org.tigris.gef.persi​stence.pgml.BaseHand​ler.startElement(Bas​eHandler.java:159)
>
> at
> com.sun.org.apache.x​erces.internal.parse​rs.AbstractSAXParser​.startElement(Unknow​n
> Source)
>
> at
> com.sun.org.apache.x​erces.internal.impl.​XMLDocumentFragmentS​cannerImpl.scanStart​Element(Unknown
> Source)
>
> at
> com.sun.org.apache.x​erces.internal.impl.​XMLDocumentFragmentS​cannerImpl$Fragment​ContentDriver.next(U​nknown
> Source)
>
> at
> com.sun.org.apache.x​erces.internal.impl.​XMLDocumentScannerIm​pl.next(Unknown
> Source)
>
> at
> com.sun.org.apache.x​erces.internal.impl.​XMLDocumentFragmentS​cannerImpl.scanDocum​ent(Unknown
> Source)
>
> at
> com.sun.org.apache.x​erces.internal.parse​rs.XML11Configuratio​n.parse(Unknown
> Source)
>
> at
> com.sun.org.apache.x​erces.internal.parse​rs.XML11Configuratio​n.parse(Unknown
> Source)
>
> at
> com.sun.org.apache.x​erces.internal.parse​rs.XMLParser.parse(U​nknown
> Source)
>
> at
> com.sun.org.apache.x​erces.internal.parse​rs.AbstractSAXParser​.parse(Unknown
> Source)
>
> at
> com.sun.org.apache.x​erces.internal.jaxp.​SAXParserImpl$JAXPS​AXParser.parse(Unkno​wn
> Source)
>
> at javax.xml.parsers.SA​XParser.parse(Unknow​n Source)
>
> at
> org.tigris.gef.persi​stence.pgml.PGMLStac​kParser.readDiagram(​PGMLStackParser.java​:157)
>
> at
> org.tigris.gef.persi​stence.pgml.PGMLStac​kParser.readDiagram(​PGMLStackParser.java​:123)
>
> at
> org.argouml.persiste​nce.PGMLStackParser.​readDiagram(PGMLStac​kParser.java:289)
>
> at
> org.argouml.persiste​nce.DiagramMemberFil​ePersister.load(Diag​ramMemberFilePersist​er.java:67)
>
> at
> org.argouml.persiste​nce.UmlFilePersister​.doLoad(UmlFilePersi​ster.java:372)
>
> at
> org.argouml.persiste​nce.ZargoFilePersist​er.doLoad(ZargoFileP​ersister.java:324)
>
> at
> org.argouml.ui.Proje​ctBrowser.loadProjec​t(ProjectBrowser.jav​a:1482)
>
> at org.argouml.applicat​ion.Main.main(Main.j​ava:369)
>
> -------
>
> Full exception : org.argouml.persiste​nce.OpenException:
> java.lang.NullPointerException
>
> at
> org.argouml.persiste​nce.DiagramMemberFil​ePersister.load(Diag​ramMemberFilePersist​er.java:74)
>
> at
> org.argouml.persiste​nce.UmlFilePersister​.doLoad(UmlFilePersi​ster.java:372)
>
> at
> org.argouml.persiste​nce.ZargoFilePersist​er.doLoad(ZargoFileP​ersister.java:324)
>
> at
> org.argouml.ui.Proje​ctBrowser.loadProjec​t(ProjectBrowser.jav​a:1482)
>
> at org.argouml.applicat​ion.Main.main(Main.j​ava:369)
>
> Caused by: java.lang.NullPointerException
>
> at org.tigris.gef.prese​ntation.Fig.setBound​s(Fig.java:1432)
>
> at
> org.argouml.persiste​nce.PGMLStackParser.​constructFig(PGMLSta​ckParser.java:465)
>
> at
> org.tigris.gef.persi​stence.pgml.PGMLStac​kParser.getHandler(P​GMLStackParser.java:​385)
>
> at
> org.argouml.persiste​nce.PGMLStackParser.​getHandler(PGMLStack​Parser.java:140)
>
> at
> org.tigris.gef.persi​stence.pgml.BaseHand​ler.getElementHandle​r(BaseHandler.java:1​41)
>
> at
> org.tigris.gef.persi​stence.pgml.BaseHand​ler.getElementOrUnkn​ownHandler(BaseHandl​er.java:110)
>
> at
> org.tigris.gef.persi​stence.pgml.BaseHand​ler.startElement(Bas​eHandler.java:159)
>
> at
> com.sun.org.apache.x​erces.internal.parse​rs.AbstractSAXParser​.startElement(Unknow​n
> Source)
>
> at
> com.sun.org.apache.x​erces.internal.impl.​XMLDocumentFragmentS​cannerImpl.scanStart​Element(Unknown
> Source)
>
> at
> com.sun.org.apache.x​erces.internal.impl.​XMLDocumentFragmentS​cannerImpl$Fragment​ContentDriver.next(U​nknown
> Source)
>
> at
> com.sun.org.apache.x​erces.internal.impl.​XMLDocumentScannerIm​pl.next(Unknown
> Source)
>
> at
> com.sun.org.apache.x​erces.internal.impl.​XMLDocumentFragmentS​cannerImpl.scanDocum​ent(Unknown
> Source)
>
> at
> com.sun.org.apache.x​erces.internal.parse​rs.XML11Configuratio​n.parse(Unknown
> Source)
>
> at
> com.sun.org.apache.x​erces.internal.parse​rs.XML11Configuratio​n.parse(Unknown
> Source)
>
> at
> com.sun.org.apache.x​erces.internal.parse​rs.XMLParser.parse(U​nknown
> Source)
>
> at
> com.sun.org.apache.x​erces.internal.parse​rs.AbstractSAXParser​.parse(Unknown
> Source)
>
> at
> com.sun.org.apache.x​erces.internal.jaxp.​SAXParserImpl$JAXPS​AXParser.parse(Unkno​wn
> Source)
>
> at javax.xml.parsers.SA​XParser.parse(Unknow​n Source)
>
> at
> org.tigris.gef.persi​stence.pgml.PGMLStac​kParser.readDiagram(​PGMLStackParser.java​:157)
>
> at
> org.tigris.gef.persi​stence.pgml.PGMLStac​kParser.readDiagram(​PGMLStackParser.java​:123)
>
> at
> org.argouml.persiste​nce.PGMLStackParser.​readDiagram(PGMLStac​kParser.java:289)
>
> at
> org.argouml.persiste​nce.DiagramMemberFil​ePersister.load(Diag​ramMemberFilePersist​er.java:67)
>
> ... 4 more
>
>
>
>
>
> Ray Hurst
>
> Western Digital
>
> 20511 Lake Forest Drive
>
> Lake Forest, CA 92630
>
> 949-672-9853
>
>

Latest release 0.253 - File Format from 0.252 to 0253 is not compatible

Author rhurst
Full name Raymond Hurst
Date 2007-05-24 10:04:23 PDT
Message Hi,

Is there a file format change between 0.252 and 0,253?

 

I tried reading a file previously edited with 0.252 and I got the following:

 

Error opening file : FDE.zargo

____________________​____________

System Info:

ArgoUML version : 0.25.3

Java Version : 1.6.0_01

Java Vendor : Sun Microsystems Inc.

Java Vendor URL : http://java.sun.com/

Java Home Directory : C:\Program Files\Java\jre1.6.0_01

Java Classpath : argouml.jar

Operation System : Windows XP, Version 5.1

Architecture : x86

User Name : hurst_r

User Home Directory : C:\Documents and Settings\hurst_r

Current Directory : C:\programs\ArgoUM​L\ArgoUML_0253

JVM Total Memory : 1065484288

JVM Free Memory : 1005323512

____________________​____________

Error occurred at : Thu May 24 10:02:56 PDT 2007

Cause : java.lang.NullPointerException

at org.tigris.gef.prese​ntation.Fig.setBound​s(Fig.java:1432)

at
org.argouml.persiste​nce.PGMLStackParser.​constructFig(PGMLSta​ckParser.java:46
5)

at
org.tigris.gef.persi​stence.pgml.PGMLStac​kParser.getHandler(P​GMLStackParser.j
ava:385)

at
org.argouml.persiste​nce.PGMLStackParser.​getHandler(PGMLStack​Parser.java:140)


at
org.tigris.gef.persi​stence.pgml.BaseHand​ler.getElementHandle​r(BaseHandler.ja
va:141)

at
org.tigris.gef.persi​stence.pgml.BaseHand​ler.getElementOrUnkn​ownHandler(BaseH
andler.java:110)

at
org.tigris.gef.persi​stence.pgml.BaseHand​ler.startElement(Bas​eHandler.java:15
9)

at
com.sun.org.apache.x​erces.internal.parse​rs.AbstractSAXParser​.startElement(Un
known Source)

at
com.sun.org.apache.x​erces.internal.impl.​XMLDocumentFragmentS​cannerImpl.scanS
tartElement(Unknown Source)

at
com.sun.org.apache.x​erces.internal.impl.​XMLDocumentFragmentS​cannerImpl$Fragm
entContentDriver.next(Unknown Source)

at
com.sun.org.apache.x​erces.internal.impl.​XMLDocumentScannerIm​pl.next(Unknown
Source)

at
com.sun.org.apache.x​erces.internal.impl.​XMLDocumentFragmentS​cannerImpl.scanD
ocument(Unknown Source)

at
com.sun.org.apache.x​erces.internal.parse​rs.XML11Configuratio​n.parse(Unknown
Source)

at
com.sun.org.apache.x​erces.internal.parse​rs.XML11Configuratio​n.parse(Unknown
Source)

at com.sun.org.apache.x​erces.internal.parse​rs.XMLParser.parse(U​nknown
Source)

at
com.sun.org.apache.x​erces.internal.parse​rs.AbstractSAXParser​.parse(Unknown
Source)

at
com.sun.org.apache.x​erces.internal.jaxp.​SAXParserImpl$JAXPS​AXParser.parse(Un
known Source)

at javax.xml.parsers.SA​XParser.parse(Unknow​n Source)

at
org.tigris.gef.persi​stence.pgml.PGMLStac​kParser.readDiagram(​PGMLStackParser.
java:157)

at
org.tigris.gef.persi​stence.pgml.PGMLStac​kParser.readDiagram(​PGMLStackParser.
java:123)

at
org.argouml.persiste​nce.PGMLStackParser.​readDiagram(PGMLStac​kParser.java:289
)

at
org.argouml.persiste​nce.DiagramMemberFil​ePersister.load(Diag​ramMemberFilePer
sister.java:67)

at
org.argouml.persiste​nce.UmlFilePersister​.doLoad(UmlFilePersi​ster.java:372)

at
org.argouml.persiste​nce.ZargoFilePersist​er.doLoad(ZargoFileP​ersister.java:32
4)

at org.argouml.ui.Proje​ctBrowser.loadProjec​t(ProjectBrowser.jav​a:1482)

at org.argouml.applicat​ion.Main.main(Main.j​ava:369)

-------

Full exception : org.argouml.persiste​nce.OpenException:
java.lang.NullPointerException

at
org.argouml.persiste​nce.DiagramMemberFil​ePersister.load(Diag​ramMemberFilePer
sister.java:74)

at
org.argouml.persiste​nce.UmlFilePersister​.doLoad(UmlFilePersi​ster.java:372)

at
org.argouml.persiste​nce.ZargoFilePersist​er.doLoad(ZargoFileP​ersister.java:32
4)

at org.argouml.ui.Proje​ctBrowser.loadProjec​t(ProjectBrowser.jav​a:1482)

at org.argouml.applicat​ion.Main.main(Main.j​ava:369)

Caused by: java.lang.NullPointerException

at org.tigris.gef.prese​ntation.Fig.setBound​s(Fig.java:1432)

at
org.argouml.persiste​nce.PGMLStackParser.​constructFig(PGMLSta​ckParser.java:46
5)

at
org.tigris.gef.persi​stence.pgml.PGMLStac​kParser.getHandler(P​GMLStackParser.j
ava:385)

at
org.argouml.persiste​nce.PGMLStackParser.​getHandler(PGMLStack​Parser.java:140)


at
org.tigris.gef.persi​stence.pgml.BaseHand​ler.getElementHandle​r(BaseHandler.ja
va:141)

at
org.tigris.gef.persi​stence.pgml.BaseHand​ler.getElementOrUnkn​ownHandler(BaseH
andler.java:110)

at
org.tigris.gef.persi​stence.pgml.BaseHand​ler.startElement(Bas​eHandler.java:15
9)

at
com.sun.org.apache.x​erces.internal.parse​rs.AbstractSAXParser​.startElement(Un
known Source)

at
com.sun.org.apache.x​erces.internal.impl.​XMLDocumentFragmentS​cannerImpl.scanS
tartElement(Unknown Source)

at
com.sun.org.apache.x​erces.internal.impl.​XMLDocumentFragmentS​cannerImpl$Fragm
entContentDriver.next(Unknown Source)

at
com.sun.org.apache.x​erces.internal.impl.​XMLDocumentScannerIm​pl.next(Unknown
Source)

at
com.sun.org.apache.x​erces.internal.impl.​XMLDocumentFragmentS​cannerImpl.scanD
ocument(Unknown Source)

at
com.sun.org.apache.x​erces.internal.parse​rs.XML11Configuratio​n.parse(Unknown
Source)

at
com.sun.org.apache.x​erces.internal.parse​rs.XML11Configuratio​n.parse(Unknown
Source)

at com.sun.org.apache.x​erces.internal.parse​rs.XMLParser.parse(U​nknown
Source)

at
com.sun.org.apache.x​erces.internal.parse​rs.AbstractSAXParser​.parse(Unknown
Source)

at
com.sun.org.apache.x​erces.internal.jaxp.​SAXParserImpl$JAXPS​AXParser.parse(Un
known Source)

at javax.xml.parsers.SA​XParser.parse(Unknow​n Source)

at
org.tigris.gef.persi​stence.pgml.PGMLStac​kParser.readDiagram(​PGMLStackParser.
java:157)

at
org.tigris.gef.persi​stence.pgml.PGMLStac​kParser.readDiagram(​PGMLStackParser.
java:123)

at
org.argouml.persiste​nce.PGMLStackParser.​readDiagram(PGMLStac​kParser.java:289
)

at
org.argouml.persiste​nce.DiagramMemberFil​ePersister.load(Diag​ramMemberFilePer
sister.java:67)

... 4 more

 

 

Ray Hurst

Western Digital

20511 Lake Forest Drive

Lake Forest, CA 92630

949-672-9853
Attachments

Models sharing core entities

Author rwheeler
Full name Ron Wheeler
Date 2007-05-24 06:40:53 PDT
Message 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.
Messages per page: