[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ormf-dev] Evaluation and selection of UML modelling tool
|
Certainly there is.
I remember quite well having answered the Bugzilla issue.
OK, getting serious again. Given the set of requirements Joel has
stated, the list got extremely thin. It is therefore extremely important
for the team to get together and decide on the priority of requirements
in order to find a viable compromise.
I for myself consider modelling an important tool in my toolbox and
would not want to miss it. Therefore - get up and raise your voices!
Wolfgang
Joel Rosi-Schwartz schrieb:
Certainly there is one amongst us who would be proud to take this on
their shoulders :-)
Kidding aside, is the lack of response here that the team in general
does not believe that modelling adds value to the project? Possibly
that is subject that we should be discussing prior to which modeller
to use.
Joel
On 13 Oct 2008, at 15:25, Joel Rosi-Schwartz wrote:
Hi,
I would very much like for the entire ORMF team to embrace modelling
as both an aid to analysis and design and for documentation. The
issue is what tool do we use. The two obvious choices are the eclipse
UML2 Tools and Topcased.
The issues with UML2 are that it does not support reverse engineering
nor sequence diagrams. This limits its usefulness as a long term
complete solution.
I have tried Topcased <http://topcased.gforge.enseeiht.fr/> UML2
Tools. I find that it has usability issues and was also not able to
successfully create class models from the reverse engineered model of
a fairly simply one plug-in, 6 package, 12 class project. Halfway
into walking through the packages it threw a transformation
exception. This was using their latest RCP standalone version
on Windows, so it is not local configuration issue.
With Topcased there is also the consideration that it is aimed at the
"Critical systems Topcased is a software environment primarily
dedicated to the realisation of critical embedded systems including
hardware and/or software." So it surely has complexity that ORMF does
not have to buy into.
If there are recommendations from the team as to other options that
would be great.
What I would like is a team member to pick this up, do whatever
research and evaluation is required and report back, so that the team
can make a decision.
I have opened a bugzilla issue
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=250648> to track this
work.
Thanks,
Joel
_______________________________________________
ormf-dev mailing list
ormf-dev@xxxxxxxxxxx <mailto:ormf-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/ormf-dev
------------------------------------------------------------------------
_______________________________________________
ormf-dev mailing list
ormf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ormf-dev
