Eclipse Community Forums: UML2 Tools » does the UML2 Tools project need our help?

Help

Home

Home » Modeling » UML2 Tools » does the UML2 Tools project need our help?

Show: Today's Messages :: Show Polls :: Message Navigator

does the UML2 Tools project need our help? [message #469961]

Fri, 20 April 2007 03:34

Rafael Chaves

Messages: 362
Registered: July 2009

Senior Member

Hi,

I tried to find bugs in the UML2 Tools bugzilla inbox marked as
helpwanted, but could not find any. I am very interested in helping
making UML2 Tools a better product, and I guess others in the community
might want to give a hand as well.

It would be great if more of the communication between committers were
happening in the development mailing list, or even here. Transparency is
key for success in open source projects - it is hard for a community to
form around a project if only those few in the loop (committers and
their sponsor companies) know what is going on.

Please take this as constructive criticism. I (and likely others) would
really like to help, just give the community more opportunities for
figuring out how.

Thanks,

Rafael

Report message to a moderator

Re: does the UML2 Tools project need our help? [message #469968 is a reply to message #469961]

Tue, 24 April 2007 10:51

Michael Golubev

Messages: 383
Registered: July 2009

Senior Member

Hello Rafael,

First of all, thank you.

Answering this after 3 days of silence, I have to agree that there was lack
of communication.
Its our fault and we will do our best to improve this.

Regarding the helpwanted SCR, I am going to review the list of scr's tomorrow,

right after preparing new integration build with latest GMF and some urgent
fixes.

In general, I feel that the least covered area of the project plan right
now is Component diagram.
Due to the lack of resources, I don't expect significant progress with this
next 1-2 weeks,
and it is certianly the area of helpwanted.

One of the blockers for this diagram is #183754 "Port Provided/Required interface
links".
As stated in SCR,

The main problem with these links is that port provided/required interfaces
are
both derived features.

Say, the set of provided interfaces of the port is defined by the set of
interfaces implemented by port's type classifier.

Thus, creation of the link on diagram is not related to port itself,
but should
modify the typing classifier of this port or one of its super-classes.

This also affects the ClassD, but for ComponentD with ports as key concept
it seems to be on of a most severe issues.

For now, I am taking in mind the following approach (considering the use
case of creation provided interface link from port p to interface I)

1. If p is not typed, ban link creation
2. If p is typed by classifier C that is not involved into inheritance hierarchy,
than add I into the set of interfaces implemented by C
3. If p is typed by classifier C that has direct generalization to C1, C2,
as well as indirect generalizations to D1, D2, E1, E2,
(that is: C extends (C1 extends D1, D2), (C2 extends E1, E2))
then creation of provided interface should display the popup menu prompting
for
the classifier where to implementation should be added.

I would highly appreciate any discussion about this particlual issue and
about ComponentD features in general.

Regards,
Michael

> Hi,
>
> I tried to find bugs in the UML2 Tools bugzilla inbox marked as
> helpwanted, but could not find any. I am very interested in helping
> making UML2 Tools a better product, and I guess others in the
> community might want to give a hand as well.
>
> It would be great if more of the communication between committers were
> happening in the development mailing list, or even here. Transparency
> is key for success in open source projects - it is hard for a
> community to form around a project if only those few in the loop
> (committers and their sponsor companies) know what is going on.
>
> Please take this as constructive criticism. I (and likely others)
> would really like to help, just give the community more opportunities
> for figuring out how.
>
> Thanks,
>
> Rafael
>

Report message to a moderator

Re: does the UML2 Tools project need our help? [message #469970 is a reply to message #469968]

Wed, 25 April 2007 02:40

Rafael Chaves

Messages: 362
Registered: July 2009

Senior Member

Hi Michael,

Marking bugs as helpwanted is a great first step, thanks a lot. Moving
development discussions to the developers' mailing list (or even here)
would be even better, and I hope you guys consider doing that at some
point, because that makes it easier for us outsiders to identify areas
where we could help, and also to understand the strategic directions the
project is taking.

I have no experience whatsoever with GEF at this point, but I plan to
change that soon. As an ex-committer in the Platform/Core team and
experienced Java developer, I believe I can potentially make quality
contributions to the project. Personally, I am mostly interested in
making contributions in the area of class diagram support (disclosure: I
am building a tool for MDD based on UML2, and plan to incorporate the
class diagram support from the UML2 Tools project). But I do not reject
the idea of helping in other areas if it feels appropriate, and with the
description of the issue you made I bet others here that are more
interested in the Component diagram will now feel more able to give a hand.

Thanks again for listening, and keep up the good work!

Rafael

Michael Golubev wrote:
> Hello Rafael,
>
> First of all, thank you.
> Answering this after 3 days of silence, I have to agree that there was
> lack of communication. Its our fault and we will do our best to improve
> this.
> Regarding the helpwanted SCR, I am going to review the list of scr's
> tomorrow,
> right after preparing new integration build with latest GMF and some
> urgent fixes.
> In general, I feel that the least covered area of the project plan right
> now is Component diagram. Due to the lack of resources, I don't expect
> significant progress with this next 1-2 weeks, and it is certianly the
> area of helpwanted.
> One of the blockers for this diagram is #183754 "Port Provided/Required
> interface links". As stated in SCR,
> The main problem with these links is that port provided/required
> interfaces are
> both derived features.
> Say, the set of provided interfaces of the port is defined by the set of
> interfaces implemented by port's type classifier.
> Thus, creation of the link on diagram is not related to port itself,
> but should
> modify the typing classifier of this port or one of its super-classes.
>
> This also affects the ClassD, but for ComponentD with ports as key
> concept it seems to be on of a most severe issues.
> For now, I am taking in mind the following approach (considering the use
> case of creation provided interface link from port p to interface I)
>
> 1. If p is not typed, ban link creation 2. If p is typed by classifier C
> that is not involved into inheritance hierarchy, than add I into the set
> of interfaces implemented by C
> 3. If p is typed by classifier C that has direct generalization to C1,
> C2, as well as indirect generalizations to D1, D2, E1, E2, (that is: C
> extends (C1 extends D1, D2), (C2 extends E1, E2)) then creation of
> provided interface should display the popup menu prompting for the
> classifier where to implementation should be added.
> I would highly appreciate any discussion about this particlual issue and
> about ComponentD features in general.
>
> Regards, Michael
>
>> Hi,
>>
>> I tried to find bugs in the UML2 Tools bugzilla inbox marked as
>> helpwanted, but could not find any. I am very interested in helping
>> making UML2 Tools a better product, and I guess others in the
>> community might want to give a hand as well.
>>
>> It would be great if more of the communication between committers were
>> happening in the development mailing list, or even here. Transparency
>> is key for success in open source projects - it is hard for a
>> community to form around a project if only those few in the loop
>> (committers and their sponsor companies) know what is going on.
>>
>> Please take this as constructive criticism. I (and likely others)
>> would really like to help, just give the community more opportunities
>> for figuring out how.
>>
>> Thanks,
>>
>> Rafael
>>
>
>

Report message to a moderator

Re: does the UML2 Tools project need our help? [message #470214 is a reply to message #469968]

Thu, 26 April 2007 10:21

Philippe

Messages: 100
Registered: July 2009

Senior Member

Hello Michael,

as I want to start getting in touch with the gmf models of uml2tools, I
chose ComponentD as it is smaller than ClassD, and if possible, I'd like
to help a little.
Regarding the problem you mentioned about port/interface linking,
I'm not quite clear about some points. I hope discussing it can also
help you in your thinking.
(reusing your use case of creation provided interface link from port p
to interface I)
- If p is typed by classifier C, can C be a component,an interface or
whatever ?
I though that it should be only be the interface I, regarding the UML2 Specs
"A provided Interface is one that is either implemented directly by the
component or one of its realizingClassifiers, or it is the type of a
provided Port of the Component."

But reading it like this make me believe that one port could only have
one type, so I may have miss something.

-As p is typed by classifier C, from where come C ? I don't think it can
come directly from the componentD. Supposed it comes from a related
classD, would it trigger issues of crossed-references between interfaces
in the classD and componentD ?

Otherwise I had some surprises while editing a ComponentD and I didn't
found any related bugs (if they are bugs).

1- An unknown connection of type Edge4006 can appear (only on the
diagram) between a port and an interface
Step to reproduce using eclipse 3.3M6 and all M6 plug-ins,
-create a component, a port and an interface
-set the type of the port to interface using the propertysheet
-create an element (all but port)
-the edge appears between the port and the interface

2-when deleting an interface realization between a component and a
interface from the model (using the tree view in .uml editor)
the edge is not deleted from the diagram but a cross-shaped circle
appears on it.

Regards,
Philippe

Report message to a moderator