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]> 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]
For additional commands, e-mail: [EMAIL PROTECTED]


Reply via email to