MarkMail: thread:sfm5qwkxujjxglia

Re: [argouml-dev] the road to UML2

2009-04-03T14:12:49.406535-08:00

From:	Thomas Neustupny (thn...@gmx.de)
List:	org.tigris.argouml.dev

Hi!

We all (should) know UML, the main UML metamodel elements (class, operation,
package, namespace etc.). With this knowledge everybody should understand the purpose of most methods in argouml-core-model, and that everything there is the interface to a concrete UML implementation like Netbeans MDR or our eUML (that uses eclipse UML2). Very few further details are needed to know for now.

Then, the eclipse environment should be set up and understood so that one can run the ArgoUML UML2-EUML debug launch configuration.

Ready to start, launch it! The ArgoUML application will start and looks as if everything is fine. Of course it's not: create a class (OK), then an attribute for it (DANG!). Whatever you do, you'll eventually run into a problem. Concentrate on one simple case (e.g. attribute creation) and try to understand and fix it. Ask questions here, add found further tasks to the wiki. Create a JUnit test for your case (or, as Tom suggested, run an existing one without searching your own case).

To the experienced: is this approach OK?

Open the argouml-core-model-euml project of course, aditionally to the projects you have opened for normal ArgoUML debugging. (You can close the argouml-core-model-mdr project probably.)

Where do I find the tests and how do I run them?

I don't know (yet), but it should be easy to figure out.

How do I set up ArgoUML with the new model, in whatever functional/non-functional state it is in?

It's in the wiki (Bogdan's report, a good starting point btw.). But you'll see when you launch as described, really!

How do I know what has or hasn't been updated yet?

We must synchronize (issuezilla, wiki, here), but that's not a problem yet, a mail here if you start working on something is OK for now, but better create an issue for the euml subcomponent and mark it as STARTED (can be reverted).

How do I know if it is working?

When it seems to work. Details will come later. We are at the beginning!

How do I know the difference between a test that is supposed to pass and an obsolete test that will never pass?

Only the spec will tell, or ask here.

The topic sounds vast and complicated - are there any safe bits I can work on without risking breaking something? Sorry for all the questions.

I believe that after trying the above it won't look complicated anymore. Two topics of higher complexity probably (like getting ModelMemento work for Undo/Redo), but it's not needed to start with it.

If someone could break down some tasks to the beginner level, then there would probably be a lot more help available, as (baring the top 5 or 6 people involved), this is probably where most of the developers are. If there are no tasks at this level, then I seriously think that those with knowledge of the subject need to invest some time in creating training materials for those without. The Wiki is a great start on this, but at the moment, most of it goes over my head!

Yes the wiki! I try to write down any simple task I see, but I'm just a beginner too! Quite late to admit this... ;-)

Try and have fun! Thomas

-- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für
nur 17,95 Euro/mtl.!* dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a

------------------------------------------------------ argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=1536191

To unsubscribe from this discussion, e-mail:
[dev-...@argouml.tigris.org]. To be allowed to post to the list contact the mailing list moderator, email:
[lin...@tigris.org]

Re: [argouml-dev] the road to UML2

2009-04-02T02:03:00.558392-08:00

From:	Thomas Neustupny (thn...@gmx.de)
List:	org.tigris.argouml.dev

Hi Dave,

it's great that you pointed out the need to make things understandable/usable for the whole team! I added a section to the tasks page (I have not much experience with eUML, so it needs to be improved) and added the remaining questions in your mail to the section that Linus addded.

Everybody should not only add information to the wiki, but also questions/comments!

Thomas

-------- Original-Nachricht --------

Datum: Thu, 2 Apr 2009 07:17:43 +0200 Von: Linus Tolke <lto...@gmail.com> An: de...@argouml.tigris.org Betreff: Re: [argouml-dev] the road to UML2

To attempt at helping in the understanding of how to develop this, I added a short section (with my guesses) to the argouml.tigris.org/wiki/UML_2.x_support wiki page. We will have to work together also to improve this.

/Linus

2009/4/1 Dave Thompson <argo...@davet.org>

On Tue, 31 Mar 2009 16:21 -0400, "Tom Morris" <tfmo...@gmail.com> wrote:

I'd suggest that anyone who wants to work on this, pick a test and get it to pass or pick a diagram and implement some functionality. After you've done a few days work, you'll have a better understanding of what's needed.

Thanks Tom for your voice of experience on this topic. It does sound like one of the key areas in ArgoUML that we need to work on, and in that respect, I am keen to help.

However, I have to admit that I'm approaching this from a very basic perspective, and I suspect that many other developers reading this list will be in a similar position. Without any prior knowledge on the subject, where should we start? I have only just learned what eUML actually is, and I have only very sketchy ideas about how it fits into ArgoUML at all. I gather that the data on the screen is mirrored in some sort of data structure, which is internal to the application, but not directly browsable in any of the GUI panels, and what we are talking about is changing this data structure (i.e. model) to a different format.

I don't know the reasons or the history behind it, but I suppose what I'm really lacking at the moment is some sort of practical steps on what to actually do. Which project do I have to load to start working on it? Where do I find the tests and how do I run them? How do I set up ArgoUML with the new model, in whatever functional/non-functional state it is in? How do I know what has or hasn't been updated yet? How do I know if it is working? How do I know the difference between a test that is supposed to pass and an obsolete test that will never pass? The topic sounds vast and complicated - are there any safe bits I can work on without risking breaking something? Sorry for all the questions.

Dave

------------------------------------------------------

argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=1506374

To unsubscribe from this discussion, e-mail: [ dev-...@argouml.tigris.org]. To be allowed to post to the list contact the mailing list moderator, email: [lin...@tigris.org]

------------------------------------------------------ argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=1514094

To unsubscribe from this discussion, e-mail: [dev-...@argouml.tigris.org]. To be allowed to post to the list contact the mailing list moderator, email: [lin...@tigris.org]

-- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für
nur 17,95 Euro/mtl.!* dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a

------------------------------------------------------ argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=1516931

To unsubscribe from this discussion, e-mail:
[dev-...@argouml.tigris.org]. To be allowed to post to the list contact the mailing list moderator, email:
[lin...@tigris.org]

Re: [argouml-dev] the road to UML2

2009-04-01T21:17:24.855829-08:00

From:	Linus Tolke (lto...@gmail.com)
List:	org.tigris.argouml.dev

/Linus

2009/4/1 Dave Thompson <argo...@davet.org>

On Tue, 31 Mar 2009 16:21 -0400, "Tom Morris" <tfmo...@gmail.com> wrote:

Thanks Tom for your voice of experience on this topic. It does sound like one of the key areas in ArgoUML that we need to work on, and in that respect, I am keen to help.

Dave

------------------------------------------------------

argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=1506374

To unsubscribe from this discussion, e-mail: [ dev-...@argouml.tigris.org]. To be allowed to post to the list contact the mailing list moderator, email: [lin...@tigris.org]

------------------------------------------------------ argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=1514094

To unsubscribe from this discussion, e-mail:
[dev-...@argouml.tigris.org]. To be allowed to post to the list contact the mailing list moderator, email:
[lin...@tigris.org]

Re: [argouml-dev] the road to UML2

2009-04-01T04:08:38.456734-08:00

From:	Dave Thompson (argo...@davet.org)
List:	org.tigris.argouml.dev

On Tue, 31 Mar 2009 16:21 -0400, "Tom Morris" <tfmo...@gmail.com> wrote:

Thanks Tom for your voice of experience on this topic. It does sound like one of the key areas in ArgoUML that we need to work on, and in that respect, I am keen to help.

Dave

------------------------------------------------------ argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=1506374

To unsubscribe from this discussion, e-mail:
[dev-...@argouml.tigris.org]. To be allowed to post to the list contact the mailing list moderator, email:
[lin...@tigris.org]

Re: [argouml-dev] the road to UML2

2009-03-31T12:20:47.822677-08:00

From:	Tom Morris (tfmo...@gmail.com)
List:	org.tigris.argouml.dev

The biggest planning item is prioritization. Who is going to stop doing what they're doing and work on UML 2 instead? If no one's going to do the work, no planning is needed. Those who are going to make it a priority can then get together and do the planning.

The very first thing on the wiki planning page is "pick a release date." That's simply not possible at this point, so isn't even worth discussing.

Similarly the task list reads like something out of a Microsoft Project or some other project management tool with dependencies, percent complete, etc. Most fine grained dependencies aren't going to be known until someone starts doing the work. Things are either "done" or "not done", so %complete is 0% or 100%. If you want percentages which aren't tied to specific user functionality, just run the JUnit tests using the eUML subsystem and see what percentage pass.

I do think it's valuable to discuss and agree on overall goals. What is it that you are trying to achieve? Who are your customers? From my personal point of view, if you aren't going to upgrade ArgoUML UML 1.4 projects or if you're going to reimplement large chunks of functionality anyway, you should consider basing your efforts on Papyrus or Topcase-d or another open source UML 2.x editor and save yourself some time and effort.

From a work organization point of view, I believe that diagram by diagram is exactly the right way (and I told Bogdan the same thing when we were planning the 2007 work as well as mentioning it to a GSoC applicant last year markmail.org/message/rqzxp2a43tfetv2s). Vertical slices are a much better way to organize things than horizontal layers. Users don't care about "subsystems." Diagrams are things that they can see and use. I think the Use Case diagram is pretty much done. The Class Diagram should be the next focus from the point of view of usefulness to users, but if someone has a burning desire to do, say, the State Diagram, I wouldn't want to discourage them. The Sequence Diagram was just redone, so presumably that's pretty much fully UML 2 compatible and we just need to finish up the underlying plumbing.

In keeping with the verticality theme, I'd say that the Undo framework should be chosen and implemented up front so that as each new command is implemented the corresponding undo can be tested as well.I think, but am not 100% sure, that there are currently got two different Undo frameworks, one which is eUML specific and one which is tied to GEF.

BTW, the same vertical vs horizontal thing applies to property panels. If people are dead set on reimplementing things, it would be much, MUCH more valuable to have a even just a single property panel implemented for UML 2.x and UML 1.4 (and perhaps SWT & Swing) than to have all existing property panels reimplemented with no clue as to whether or not this was going to help you move forward into the future. I know I said that before, but it bears repeating.

The eUML work that I did recently was basically to repair things that got broken when I added support for read-only extents/models for the profiles and to implement missing functionality required for an OMG UML 2.x interoperability test that I wanted to participate in. I also cleaned up the copyright notices which reference "The ArgoUML team" to instead reference a legal entity "<initial contributor> and other contributors." As an aside the eUML subsystem uses the New BSD license which doesn't reference the U. of California Regents since I didn't see any point in starting an entirely new subsystem which continued the past's bad habits, but moving forward, if I'm able to spend significant time on it, my copy is going to switch to EPL. This probably isn't an issue since I've been the only one working on it, but just wanted to be up front about it.

On some other topics which were mentioned:

Explorer - The Explorer view is not strongly tied to the meta model structure. It uses collections of rules to organize the different perspectives. If there are places where the existing rules don't match up, new ones can be written and the default contents (they are user customizable) for each perspective defaults chosen based on the metamodel.

Property Panels - The reason property panels throw lots of exceptions is that a) they use a lot of the Model API and b) the way that I stubbed out the API in May 2007 was to have everything throw a NotYetImplemented exception, because I wasn't confident in the test coverage and wanted it to be obvious when you used something that wasn't implemented. If people would rather have things not throw exceptions, that's an easy change to make, but I don't personally consider it an issue that importing XMI files with unsupported elements cause errors. When you find a test file that doesn't work, implement the missing functionality so that it does.

OK, that's kind of rambling, but I don't have time to go back and edit it into a coherent whole. I'd suggest that anyone who wants to work on this, pick a test and get it to pass or pick a diagram and implement some functionality. After you've done a few days work, you'll have a better understanding of what's needed.

Tom

------------------------------------------------------ argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=1499283

To unsubscribe from this discussion, e-mail:
[dev-...@argouml.tigris.org]. To be allowed to post to the list contact the mailing list moderator, email:
[lin...@tigris.org]

Re: [argouml-dev] the road to UML2

2009-03-31T11:31:57.284292-08:00

From:	Thomas Neustupny (thn...@gmx.de)
List:	org.tigris.argouml.dev

Hi Bob!

This page splits out work on property panels as if they are a part of working on a diagram. That is not really the case. We could have someone work on panels for just those elements on a class diagram but the user can still load some XMI that contain other elements that will fail if they select them in the explorer and they display in an incomplete property panel.

I'd suggest the blocks in that wiki for Class Diagram Implementation, Use Case Diagram Implementation are reorgansied to contain also other relevant subsystem as main blaock such as Property Panels and Explorer. I don't think we can release any single diagram until those are working.

I'm happy to edit the wiki if this is agreeable but didn't want to go to the effort unless others follow my logic.

You are absolutely right, put the explorer, persistence, property panels and
whatever is needed to the appropriate sections. We can later restructure it
again as soon as the dependencies get clearer. Thanks for clarifying.

Could we instead split a second explorer implementation following UML2 design with ArgoUML loading one or the other depending on the UML implementation? (hopefully there will still be some common logic we can keep in just one place).

I don't know if this is needed, and how much work it would be to let only one
explorer instance handle both UML1.x and UML2.x elements, so I can't say
anything here (yet). I have not found in Bogdan's reports that the explorer
needed a significant change, he only wrote that he needed to change the core
ArgoUML because he had not the time to use mementos but wanted to demonstrate
undo/redo.

If we can first get the explorer into its own eclipse subproject we can have only the eUML launcher include the replacement at startup and current standard Argo load the existing explorer.

If I understand correctly this also supports further modularization, am I right?
It seems to be one possible approach.

Christian (penyaskito) and myself are concentrating at the moment on revisiting the XML property panel module from his last GSOC in order to get that in a state for release.

The module is driven from an XML file that is derived from the UML1.4 metamodel. The intention is then to drive that same module from an XML derived from the UML2.x metamodel.

This allows us to contribute towards UML2.x without actually getting directly involved in the eUML subsystem.

I agree. Christian (Penyaskito) already told me about it. Great! Can you add
this to the wiki then?

For this reason I'd appreciate it if people kept enhancements to our current property panels to a minimum. Please wait on the replacement panels (or contribute you work there) or you will be giving us more work to do to complete the replacement.

OK.

My intention after this was to work on visualizing templates in FigClass. I think thats long overdue but if others think I would do better to contribute elsewhere then please suggest.

It is really a missing feature, even for UML 1.4, and as a CG/RE module
developer (for Java), I appreciate that work.

I see Tom has made some recent commits to eUML, that is good to see. I wonder if Bogdan still intends to contribute. It is those two devs with most experience in this area.

Yes I wish he could review our ideas/plans.

What are your plans Thomas?

I wanted to concentrate on UML2 only in the core project, and then only on the
Java module. (I'll try at least.)

The first one: How will the legacy UML 1.4 projects be handled? I think if we can make it a little easier by doing a "hard cut" (and maintain two ArgoUML separated streamlines for a while: UML1.4 and UML 2.x). Because I don't know how much it takes to create a migration tool. The worst would be to make ArgoUML deal with both UML1.4 and UML2 models...

What do you mean by separate stream?

Two branches with regular releases: the 0.28 (UML1.4) based stable trunk with
maintainance releases, and the eUML based developer releases. In the eUML branch
I'd be willing to radically tear down all bridges to UML 1.4 (maybe an project
upgrade to UML2 feature only) and break everything in a first step, then build
up feature by feature again, but I know that this is probably not what others
think.

I think the best would be to make ArgoUML deal with both UML1.4 and UML2 but I don't know for how long this will be practically possible.

Uhm... :-)

Maybe that's the better approach. I only thought: the more it hurts, the more
effort is taken to make it work again (quick but painful). :D

I don't see why we can't have a release that can still do all of UML1.4 and can also do just class diagrams in UML2 with extra diagrams being added over time.

Yes, probably. I don't know. Bogdans suggestion for a GSoC participant was: "The
student should implement the model subsystem's interfaces, but this should be
done incrementally. Incrementally means that you will implement what is needed
in the model subsystem for a specific functionality." But maybe for us as the
team another approach is more appropriate.

How about this - ArgoUML moves to release 1.0 then every subsequent release is 1.x until we have the final UML2 diagram and go to release 2.0

The 1.0 release for me would be your 2.0 release. So I'd move to 0.30 first.
(For others 1.0 might stand for full RCP support and eclipse integration.)

Thomas

-- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen:
www.gmx.net/de/go/multimessenger01

------------------------------------------------------ argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=1498928

To unsubscribe from this discussion, e-mail:
[dev-...@argouml.tigris.org]. To be allowed to post to the list contact the mailing list moderator, email:
[lin...@tigris.org]