376 |
to another so we have no data on that --- we expect the number |
to another so we have no data on that --- we expect the number |
377 |
would be even higher. |
would be even higher. |
378 |
|
|
379 |
Anecdotally XXX |
.. Anecdotally XXX |
380 |
|
|
381 |
.. , how much usage of UML diagrams |
.. , how much usage of UML diagrams |
382 |
as spatial menus replace usage of documentation's internal navigation. |
as spatial menus replace usage of documentation's internal navigation. |
398 |
We have presented a navigational aid, which hypertexturally connects |
We have presented a navigational aid, which hypertexturally connects |
399 |
two distinct areas of documentation, using human-authored UML diagrams |
two distinct areas of documentation, using human-authored UML diagrams |
400 |
as spatial menus. |
as spatial menus. |
|
|
|
401 |
It is not a new idea to use UML diagrams in documentation |
It is not a new idea to use UML diagrams in documentation |
402 |
navigation. There already exists Javadoc like documentation generation |
navigation. For example, Doxygen [heesch03doxygen]_ automatically |
403 |
tools, which generate automaticly class diagrams from program source |
generates class |
404 |
code to help navigation inside the generated documentation. |
inheritance tree for navigation inside the embedded documentation. |
405 |
[heesch03doxygen]_, for example, generates diagrams of class |
There has also been work on connecting the design documentation and |
406 |
inheritance tree for that purpose. |
program code through textual analysis [maletic03recovering]_. |
407 |
|
However, automatically generated diagrams and indices often include |
408 |
Our approach is different, since we prefer fully human created |
too much irrelevant information; human-made UML diagrams are quite different |
409 |
diagrams in our design documentation. We want to avoid being bloated |
from automatically generated ones since they try to *express* a part of |
410 |
by a large amount of too detailed diagrams, which are often resulted |
the system's semantics. |
411 |
by generators interpreting only the source code. On the other hand, |
|
412 |
recently there has been promising work based on textual analysis of |
What is new in our approach is the use of UML diagrams from the design |
413 |
connectable documentations [maletic03recovering]_. XXX need for the |
documentation and their insertion to the relevant Javadoc / other embedded |
414 |
last sentence :). |
documentation pages as spatial menus allowing traversal between the design |
415 |
|
documentation and the Javadoc pages. |
416 |
|
|
417 |
.. Of course, generated documentation may give well detailed information |
.. Of course, generated documentation may give well detailed information |
418 |
from the current implementation, but the design documentation should |
from the current implementation, but the design documentation should |