[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-kuml-devel
Subject:    Re:Project goals
From:       Gerard Flynn <gerard.flynn () free ! fr>
Date:       2000-10-26 3:26:06
[Download RAW message or body]

Am Wed, 25 Oct 2000 schriebst Du:
>Hi guys,
>
>So my suggestion is to first give each individual a chance to introduce

>himself. This shouldn't be an extensive CV, but i am thinking about
>information like:
>- what's your expertise (education and work)
>- what are your interrests

Gérard Flynn, 31 years old.  I work as an engineer at the Laboratoire
pour
l'Utilisation du Rayonnement Electromagnétique (a synchrotron radiation
laboratory) in Orsay, near Paris.  I'm currently working on a
distributed
object-oriented control system using CORBA (TAO ORB) for a new particle
accelerator project.

My academic background is in physics, not computer science, but I've
been doing
essentially software developement for the last couple of years.

My strongest skill areas are C++ and CORBA.  I don't have a lot of
practical
experience with UML or other OO modeling methodologies but I am strongly

interested in them.

The main things that I hope to gain from a good UML tool are :
  --aid in understanding and designing OO systems both at the static
structure
    and at the run-time interaction level

  --aid in documenting OO systems

  --automate many of the repetitive tasks involved in C++/CORBA
programming (class
    declarations, function prototypes, getter/setter methods, etc.)

Another more specialized area would be complete automatic code
generation for
certain types of systems -- notably finite state machines.

In general what I see as the force of UML is the fact that it provides
not just
diagrams but also an abstract, implementation independent way of
representing the
essential properties of an OO system.  I suspect that the full potential
of
this representation goes way beyond what is currently exploited by
existing tools
and methods.

One example of what I think should someday be possible with UML is using

it as a basis for the "design by contract approach" advocated by
Bertrand Meyer
in "Object Oriented Software Construction".  I think that this idea is
an
important one for the improvement of software quality but the approach
advocated by Meyer -- use a language which allows constraints to be
explitly
defined (Eiffel) -- raises practical problems because of the difficulty
of
                    using a relatively new language for which library
support is far more limited
than for languages like C++.  So why not use a UML model as the basis
for
defining contracts (say with OCL or some variant of it) and, if desired,

automatically generate code in the implemetation language to verify the
the
contracts are respected at run-time ?

For these reasons I think that the development of the UML model/XMI
library is
as important as the GUI application itself.

>- what's your thoughts about GNU projects and open source

  I strongly believe in Free Software and support the intent of the GPL
to keep
Free software free.  I do have some practical problems with the GPL --
the fact that it
strongly limits ones ability to integrate other free but non-GPL
software as we
are seeing with Xerces/Xalan -- but I still think that the GPL (or
possibly the
LGPL) is the best choice of license at the current time.


>- what do you want to contribute to the project e.g. on what part do
you
>want to work

  At the current time I see myself working mainly on the library side of

things.  My ideas about the GUI are far less clear.  Since I have a bit
of
experience with CORBA I might be able to help out with some code of the
CORBA interface code, including on the client side.

>- how much time do you think you are going to spend on it (per week)

  I hope on the order of 10 hours/week.

>- what do you think is the most important goal we should achieve with
kUML
>i.e. is the reusability the most important or is it the wish to have a
good
>working tool, or something else.

  I think the single most important thing is designing a good, highly
extensible
architecture.  Knowing exactly which functionality we are going to
implement
when is much less important then designing the system in such a way that
all of
the extensions we might want will be possible.

  I think that what has already been discussed will get us a long way
toward
this goal for what concerns the library.

  I'm much less clear about the design of the GUI which has received
much less
attention on the list so far.  In particular I think that the ability to

interface with other KDE apps is very important (even if it isn't
necessarily
implemented right away) and I think we will need to think and discuss
much more
about this before getting too far along on the GUI implementation.
Personally
my knowledge of the KDE component model is rather limited so I hope that
there
are other people who will have a better idea of what needs to be done in
this
area.  Of course before we even get this far I think we need much
greater
detail in the requirements about this aspect so that we have a clear
idea of
what we are trying to achieve.

  Aside from this basic early focus on architecture, I agree with what
Thomas
said about the open/closed approach.  I think we should keep the
iteration
period short, which means limiting the functionality added in each
iteration.
I don't think we should limit the ultimate functionality though.

  To sum up, I think we should try to get kUML working with minimal
funcionality as
soon as possible as long as our means of doing so won't limit our
ability to
achieve all of the functionality we want in the long run.

  I think that the best means of achieving this goal is to implement the
UML
model CORBA facility (actually we already have a partial implementation)
and
our own extensions for PresentationElement's and for XMI loading/saving.


  I think its important that the library be kept independent of GUI
facilities
so that it may be reused by as many other open source projects as
possible.


>- what do you think about the Kde-Gnome discussion (mind you, i DO NOT
WANT
>to get into another discussion about this subject. However, i do think
that
>this is influencing us so i think we should make some kind of project
>statement about it)

  So far I've been mainly a KDE user.  My preference for KDE stems in
large
part from my preference for Qt over GTK and this stems mainly from my
preference for using a real OO language rather than using OO methods in
a
language which wasn't designed to support them.

I'm not anti-GNOME though.  I've had the opportunity lately to see the
GNOME
desktop and it looks quite good (both in terms of appearence and
functionality).  I also like the fact that the GNOME component model is
based
on an industry standard, CORBA, rather than some private system.

I think the ultimate solution will be for more cooperation between the
two
projects and their software.  Once KDE2 has fully stabilized I think
that
it should be possible to build bridges between the two component models
in
order to allow GNOME and KDE applications to cooperate at the component
level.


>- why do you want to support kUML, why don't you support Argo or Dia or
....

I've been looking for a way to contribute to the free software community
for
some time.  I've chosen kUML because :

 -- no satisfactory open source UML tool exists

 -- the need for one seems obvious

 -- the kUML redesign has provided an opportunity to get involved in an
open
    source project at an early stage of conception

  In my opinion Argo is unusable because of its slowness and I suspect
that
this is intrinsically related to using Java rather than to any design or

implementation defect which could be corrected.  If someone can point me
to a
complex graphical application written in Java which can be used
comfortably I
might reconsider my position.

  Dia is a great program but its not a UML tool, just a diagram editor.

  Sorry this is so long.

    Gerard

[prev in list] [next in list] [prev in thread] [next in thread]