Hi = Michael,

<= /font>

To clarify things: = it’s all just theory. I’m not actually working on this API; I’m = just trying to figure out why extending abstract association can be = beneficial.

since the derived = association can have a different name than the abstract association, how do you plan = on handling that in generating Java code where the method names must be the = same?

<= /font>

It’s a very = interesting question. Since CustomMaterial can have more = than one association extended from Components (e.g. MainComponent and AuxiliaryComponent), simply overriding = getComponents() method won’t work anyway

<= /font>

But it’s possible = to do something like this:

<= /font>

public class CustomMaterial extends = Material {

= Collection<Material> getComponent() //overrides abstract getComponent()

= {

Collection<M= aterial> result = =3D new ArrayList<Material>();

result.addAll(getMainComponent());

result.addAll(getAuxiliaryComponent());<= /p>

//and so on = for all associations extended from Components

return result;

= }

= Collection<Material> getMainComponent(){

return mainComponent;

= }

= Collection<Material> getAuxiliaryComponent (){

return auxiliaryComponent;

= }

}

<= /font>

Any thoughts?=

<= /font>

Olga

<= /font>

-----Original = Message-----
From: fuge-devel-bounces@lists.sourceforge.net [mailto:fuge-devel-bounces@lists.sourceforge.net] On Behalf Of Miller, Michael D (Rosetta)
Sent: = Friday, February 08, = 2008 12:26 PM
To: fuge-devel@lists.sourceforge.net
Subject: Re: [Fuge-devel] = abstract associations

hi = olga,

"In this case API would get all associations extended from abstract Components association (including = MainComponent), and would return all appropriate instances of Materials (including CustomMaterialComponents)."

basically i = agree with what you are doing and it makes sense. it is important to realize = that the Material you are going to query on will always be a subclass of = Material (since it is abstract) and if it can have subcomponents will override = the abstract method, otherwise it will not override the association and = never have subcomponents (the latter use case allows restrictions in a derived = model).

to me, what this translates to in the java in the first case is implementing the method = as abstract in Material and overridden in the derived class as setter and = getter (and probably a remove) methods and having a list to hold the = subcomponents or in the second case the same idea but the methods are empty in the = derived Material class.

since the = derived association can have a different name than the abstract association, how = do you plan on handling that in generating Java code where the method names = must be the same?

cheers,

michael

From: fuge-devel-bounces@lists.sourceforge.net [mailto:fuge-devel-bounces@lists.sourceforge.net] On Behalf Of Olga Tchuvatkina
Sent: = Friday, February 08, = 2008 6:40 AM
To: fuge-devel@lists.sourceforge.net
Subject: Re: [Fuge-devel] = abstract associations

So what is the verdict? Should those who extend FuGE extend abstract = associations as well (see e-mail below)? Or are they just guidelines, to remind = developers about recommended associations to be = created?

Thank you,

Olga

-----Original = Message-----
From: fuge-devel-bounces@lists.sourceforge.net [mailto:fuge-devel-bounces@lists.sourceforge.net] On Behalf Of Olga Tchuvatkina
Sent: = Monday, February 04, = 2008 1:53 PM
To: fuge-devel@lists.sourceforge.net
Subject: [Fuge-devel] = abstract associations

Hello everyone,

Andy wrote: “The abstract associations should stay in the = UML as they are intended as a guide for how to extend the model but it should = be stressed they have no functionality as such.”

I thought that abstract associations in FuGE are intended to be used = functionally as well. For example, if someone extends self-association to Material Components (see diagram below), then later once API or tools are = available, it will be possible to query things like “give me all components for = this material”. In this case API would get all associations extended = from abstract Components association (including MainComponent), and would = return all appropriate instances of Materials (including CustomMaterialComponents). =

Speaking Java, Material is going to be an AbstractClass with abstract method = called getComponents(), while concrete class CustomMaterial will have = implementation of getComponents(). Concrete getComponents() will return Materials = obtained with getMainComponent() and other methods, generated from associations = extended from Components. =

Please let me know if that’s not correct (or realistic), so we = wouldn’t waste time extending abstract associations while we extend FuGE for flowcytometry

Thank you,

Olga

-----Original = Message-----
From: fuge-devel-bounces@lists.sourceforge.net = [mailto:fuge-devel-bounces@lists.sourceforge.net] On Behalf Of Jones, = Andy
Sent: = Monday, February 04, = 2008 8:16 AM
To: fuge-devel@lists.sourceforge.net
Subject: Re: [Fuge-devel] = stk choices

The abstract associations should = stay in the UML as they are intended as a guide for how to extend the model but = it should be stressed they have no functionality as = such.

Describable to OntologyTerm is = not an abstract association?

Cheers
Andy

From: fuge-devel-bounces@lists.sourceforge.net [mailto:fuge-devel-bounces@lists.sourceforge.net] On Behalf Of Allyson Lister
Sent: = 04 February = 2008 13:10
To: fuge-devel@lists.sourceforge.net
Subject: Re: [Fuge-devel] = stk choices

Yes, this is what I = thought as well - that the a2a associations were meant to stay in the UML to guide = extension developers...?

On = Feb 4, 2008 1:07 PM, Hermida, Leandro <Leandro.Hermida@fmi.ch> = wrote:

Hi,

I think you don't want to ignore all of the abstract associations in = the
FuGE model. Some are meant to stay no? For example, the = Describable to
OntologyTerm association "Annotations". This is why I = think you guys
created this special <<AbstractAssociation>> stereotype = which is to tag
associations that shouldn't really exist but are there to guide
extension developers?

-Leandro

-----Original Message-----
From: fuge-devel-bounc= es@lists.sourceforge.net
[mailto:fuge-devel-bounc= es@lists.sourceforge.net] On Behalf Of Angel
Pizarro

Sent: = Monday, February 04, 2008 13:45
To: fuge-devel@lists.sourcef= orge.net
Subject: Re: [Fuge-devel] stk choices

For the abstract-to-abstract associations, aren't all of these also
tagged as abstract? If so why not just ignore abstract associations
within the cartridges?

In a perfect world we would have the main model and model to model
transformations to produce the appropriate extension models for = other
PSMs. But since this is not in place then I admit that this seems = like
the best solution. The obvious con is that the models will go out of
sync very quickly, but this probably won't matter as the FuGE = version
is frozen for quite some time.

For the time being, though, until we have discussed this a bit more,
can you just branch off development for the other UML model instead = of
putting it in the root?

thanks!

angel
On 2/4/08, Allyson Lister <a.l.lister@newcastle.ac.uk= > wrote:
> Hi all,
>
> We've had a lot of discussion about what kind of STK to build. = It
seems
> clear that the kind of changes we have to make to the UML in order = to
get
> databases of various types to build (e.g hibernate or ejb3-type
databases)
> are not the sort of changes we want XSD-only developers to see, = though
I'm
> not sure we've had complete agreement yet?
>
> It's also becoming clear that we won't be able to run all the = database
> cartridges without some changes to associations that may = confuse
XSD-only
> developers, though we are now pretty sure that the resulting FuGE = XSD
will
> be identical to the one generated from the "pristine" = UML.
>
> So, trying to summarize the recent discussions, if people don't = mind
> maintaining separate versions of the stk, perhaps we should, as = has
already
> been suggested (I think by Angel or Michael?), remove ourselves = from
the
> idea of a "one stk to rule them all", and produce a = number of specific
> implementations. Some suggestions already made include:
>
> 1. XSD-only development: suitable for developers and communities = who
wish to
> create a community-specific extension to FuGE, but who do not need = to
create
> a FuGE-structured database.
> 2. Hibernate+spring and XSD STK: Suitable for developers who want = to
build
> FuGE databases via a Hibernate persistence layer, and who also want = to
use
> FuGE-ML to exchange data (i.e. move data out of the database and = dump
data
> in from elsewhere). Could also be used for communities extending = FuGE
who
> wish to use a database back-end.
> 3. ejb3 and XSD STK: The same as #2, but using ejb3 as a = persistence
layer.
> This STK would still need to be written, perhaps by Leandro? We = should
> include a caveat with this, as the ejb3 cartridge is, as far as = I
know, not
> yet part of andromda core like the hibernate cartridge is.
>
> If people are happy with this solution, the subversion = directory
top-level
> would then quickly (as the initial checkins procede) have = something
like:
> m3-stk-maven1
> xsd-stk
> xsd-hibernate-spring-stk
> xsd-ejb3-stk
> uml
> xsd
>
> (though I'm no good at naming, so these names can be changed if
someone else
> has a better idea!).
>
> I've added a "uml" directory so we can have a master = location for
storage of
> the various versions of the UML without any stk bits and pieces = (as
has been
> suggested by Andy), and we may also want to have an "xsd" directory
for
> people just wishing to download and use the official current = version
of the
> xsd.
>
> Some requirements that would fall out of such an arrangement, = and
which
> should be confirmed before committing of any changes of the = *-stk
> directories to the subversion repo:
> 1. All developers of the *-stk directories should ensure that = their
UML
> files are always drawn from (and in the case of the xsd-stk = ONLY,
identical
> to) the latest revision of the uml directory. Any time there is a = new
> revision to the UML directory, this should result in a cascade = of
updates in
> quick succession to the *-stk projects as well as to the xsd = project.
> 2. All developers of the *-stk directories should ensure that = their
> resulting XSDs are identical to the latest revision of the one in = the
XSD
> directory.
>
> I can continue to develop the xsd-stk and = xsd-hibernate-spring-stk,
and
> probably have those ready next week now (rather than this week), = as
it's
> taken some time to resolve all of this.
>
> Does this fit with people's general opinion?
>
> --
> Thanks,
> Allyson :)
>
> Allyson Lister
> Research Associate
> Centre for Integrated Systems Biology for Ageing and Nutrition
> Newcastle University
> http://www.cisban.ac.uk
> School of Computing Science
> Newcastle University
> Newcastle upon Tyne, NE1 = 7RU
>

--
Angel Pizarro
Director, ITMAT Bioinformatics Facility
806 Biological Research Building
421 Curie Blvd.
Philadelphia, = PA = 19104-6160
215-573-3736

------------------------------------------------------------------------<= br> -
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/=
_______________________________________________
Fuge-devel mailing list
Fuge-devel@lists.sourcef= orge.net
https://lists.sourceforge.net/lists/listinfo/fuge-devel=

-------------------------------------------------------------------------=
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/=
_______________________________________________
Fuge-devel mailing list
Fuge-devel@lists.sourcef= orge.net
https://lists.sourceforge.net/lists/listinfo/fuge-devel=

--
Thanks,
Allyson :)

Allyson Lister
Research Associate
Centre for Integrated Systems Biology for Ageing and Nutrition
Newcastle University
http://www.cisban.ac.uk
School of Computing Science
Newcastle University
Newcastle upon Tyne, NE1 7RU