[Uml-devel] [ uml-Feature Requests-625879 ] Integration with KlassModeller
Heiko Nardmann
h.nardmann at secunet.de
Mon Oct 21 21:47:02 UTC 2002
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Montag, 21. Oktober 2002 19:46, Luis De la Parra Blum wrote:
> On Monday 21 October 2002 11:17, Heiko Nardmann wrote:
> > => is umbrello capable of this? I found a directory class parser without
>
> yes, Umbrello reads code as well, altough so far only C++ is supported, the
> idea is to extend it to other languages as well
>
If umbrello supports this then how do I use this? I did not find some menu
item like "Read Class from Header File" (okay - probably something shorter
than this example :-) ... give me a hint ...
> > => what about a global setting in umbrello to make this available, too? A
> > checkbox which when activated makes it possible to let a class be
> > declared as Q_OBJECT and an operation be declared as either signal or
> > slot (can it be both?). Is there something inside UML which models things
> > like signals and slots?
>
> we've been discussing here that for the next mayor release, we want to add
> "profiles" to UML, I guess with those little things you could support
> Signals and Slots (I dont know if this is strict UML, but it would be nice
> and I would like to go for it) actually, there should be the standard, 100%
> compilant mode, and one profile for each language supported (C++ pure, C++
> QT, Java, PHP, Python, etc) which would add special features for that
> language. The goal would be (IMO) to make such profiles easy to make, so
> that the users can start creating profiles and contributing them back to
> the project.
> sound good, doenst it???
>
Then lets start gather things which might be useful inside of user
profile/setting:
- - Qt support (i.e. signals/slots/Q_OBJECT); does this make sense only for C++?
I did not use any other Qt language binding - thinking of perl and python
e.g.; how are Q_OBJECT declaration done there?
- - syntax style of generated code
> > - - inline code.
> > => I am not sure whether this makes sense in an UML tool.
>
> I dont see this as a "we-MUST-implement-this-right-away" feature either..
> of course inline code can be nice for accessors and such things, but not
> only as you said, this is language dependant and doesnt have much to do
> with UML, but also, the goal of Umbrello is to help you design your
> programs. Code generator is a tool so that you dont have to write
> everything by hand, but its not meant to generate applications ready to be
> run. (at least i think we are not so far, yet)
So adding it to the feature list with a low priority is a good idea.
> if you want to inline code, you can modify the sources after the generation
>
We should keep in mind that generating the model from available sources would
be a nice feature, too. So maybe another property of code generation whether
an operation shall be implemented inlined or not. Okay, whether this is
possible depends on the language.
> > => This means that we have an incomplete model.
>
> I think this is fine. If you inherit from, lets say, QWidget, you sould not
> be forced to model QWidget, with all its methods and attributes, and then
> model QPaintDevice and QObject as well (oterwise the model would be
> incomplete! =)
>
I understand and agree.
> ps. maybe we should still have a look at the code to see if we can reuse
> some of the parsing code, but I am not sure we should try to integrate the
> whole thing, or even less, depend on the program for code generation
> (someone mentioned DCOP?) it also only seems to support C++, and we want to
> support more languages.
I have asked yesterday whether the parsing 'part's of KDevelop can be easily
reused by other applications without the need of KDevelop itself. I am going
to give a summary as soon as I receive some useful information.
- --
Heiko Nardmann (Dipl.-Ing.), h.nardmann at secunet.de, Software Development
secunet Security Networks AG - Sicherheit in Netzwerken (www.secunet.de),
Weidenauer Str. 223-225, D-57076 Siegen
Tel. : +49 271 48950-13, Fax : +49 271 48950-50
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iEYEARECAAYFAj2017UACgkQpm53PRScYyiJlACgtbS/xU8JvCVF4kP8AAvMsZbV
eDcAnRnwSTscnYLhSFpSNs8rBhTBk0mg
=ai6r
-----END PGP SIGNATURE-----
More information about the umbrello-devel
mailing list