Category	Featured projects
scm	Subversion, Subclipse, TortoiseSVN, RapidSVN
issuetrack	Scarab
requirements	xmlbasedsrs
design	ArgoUML
techcomm	SubEtha, eyebrowse, midgard, cowiki
construction	antelope, scons, frameworx, build-interceptor, propel, phing
testing	maxq, aut
deployment	current
process	ReadySET
libraries	GEF, Axion, Style, SSTree
Over 500 more tools...

Subversion and IDEs
Eclipse
JDeveloper
NetBeans
Visual Studio

[ framework ] [ architecture ] [ screenshots ] [ contribution ] [ resources ] [ new Wheel ]

Lets try to explain, why there has to be a new tool. Start at begin. Why an UML tool at all?

Why use a UML Tool?

First of all we must assume, that there is something (lets call it an idea) which shall be realized! Assume further, that we already decided to do it in C++. So we have the "idea" on the one hand, and itsRealization on the other hand. Lets draw it that way:

How do you do the realization? Normally you use some coding editor for it. If we call the coding editor the "InputDialog" for the Realization we might come to this picture:

One Idea can have more than one Realization and even one Realization can have more than one InputDialog, but leave that aside, for now. Some people prefer to get some Documentation for the Idea (they say: "for the Realization" but the mean "for the Idea" otherwise bugs could be only in the Documentation)

To do the Documentation you could use various tools. lets assume you use a "DrawingProgram" to draw nice UML diagrams for the documentation. Than we end up with this picture:

In practice this ends up with documentation which has nothing to do (after a while) with the realization, because both are done total different ways and if one changes at the one end, the other end will not change too.

Now we come to the theory: Inside the UML tool is a very clever coder, with praxis proven design patterns, that is able to do the coding automatically for you, right off the documentation (the UML graphs):

Why is Astade different?

Now the realization and the documentation have the same source (the drawing) and stay always consistent. The problem is solved. That is, what the sales people of UML tools tell you.

Do you believe that? No? - you're right! In practice that doesn't work. There are hundreds of examples, let me give you just one: You want to use something from a library, lets say a "String". How you do that? If you draw it, the coder will code it, that's not what you want.

If you don't draw it, your code doesn't know it, you can not use it, its nether what you want (and its not in the documentation!). But the tool manufacturer are not so stupid. They define some "ExtraInputDialog" for you, where you can put these extra stuff and all the exceptions. We end up here:

You see, how simple it is now? Instead of making the code with a code editor on the one hand and the documentation with a drawing tool on the other hand and get them always be inconsistent -

You make the code from a mixture from drawings and extra dialogs on the one hand and the documentation only with the drawing tool and get them inconsistent, too.

In addition to that, you might ask, whether a drawing tool is the ideal input dialog for creating code. From practice I can tell you, it is possible not ideal.

Now we come to the point, where Astade tries to be better. Astade develops a common "ExtraInputDialog" which is suitable for both, coding and documentation. lets call it "CommonInputDialog". For that reason it has no drawing tool inside. you end up here:

The dialog is much more comfortable for coding than a drawing tool, believe me. Even for drawing its not so bad, the pictures on this site are done with Astade! And you really have a chance to achieve what UML tools want to: a documentation which is always consistent with the realization.

[ Project overview ]