32 |
Requirements traceability research |
Requirements traceability research |
33 |
- [humppake] couldn't find yet |
- [humppake] couldn't find yet |
34 |
|
|
35 |
|
|
36 |
|
Sketching |
37 |
|
========= |
38 |
|
|
39 |
- short description about problem: |
- short description about problem: |
40 |
* how to make fragmented documentation connected with |
* programming language specific tools generate |
41 |
minimum additional work |
well linked but distinct documentations from source code |
42 |
|
* above all is human written abstraction to the system |
43 |
|
as whole - the design documentation |
44 |
|
* how to make these documentation fragments interconnected |
45 |
|
with each other with minimum additional work |
46 |
|
|
47 |
- resolving: |
- resolving: |
48 |
* using programming language specific tools to generate |
* connecting distinct fragments together using design |
49 |
documentations from source code level |
documentation's UML diagrams |
|
* generate higher level design documentation |
|
|
* connect these levels via UML diagrams drawn design documentation |
|
50 |
|
|
51 |
- why UML |
- why UML |
52 |
* UML as de facto standard for describing software architecture |
* UML is de facto standard for describing software architecture |
53 |
* diagrams already exists, so why not use them |
- probably not best, but good enough and widely used |
54 |
* probably not best for navigation, but still better than nothing |
* diagrams must be drawn anyway, if they already exists, why not use them |
55 |
|
* we do not claim that UML work as the best possible diagrams |
56 |
|
for documentation navigation, but it's still much better than nothing |
57 |
|
|
58 |
- why UML-diagrams would work as menus |
- why UML-diagrams would work as menus |
59 |
* human made abstraction of the system |
* UMLs human made abstraction of the system containing |
60 |
|
all the most relevant parts |
61 |
* don't link to everywhere, but to the most essential places |
* don't link to everywhere, but to the most essential places |
62 |
* UMLs are already natural part of the design documentation |
* UMLs are already natural part of the design documentation |
63 |
|
and thus, familiar to development grew reading documentation |
64 |
|
|
65 |
|
- how are UMLs embedded into documentation |
66 |
|
* using lexical UML language |
67 |
|
|
68 |
- why lexical UML language: |
- why lexical UML language: |
69 |
* no need for additional tools, when writing documentation |
* no need for additional tools, when writing documentation |
70 |
|
* describing is fast |
71 |
|
* setting layout may be more |
72 |
|
|
73 |
|
- why html |
74 |
|
* platform and software independent documentation |
75 |
|
* could be distributed in WWW, intranets etc... as it is |
76 |
|
|
77 |
- why Free Software |
- why Free Software |
78 |
|
* good tools exist already for parts of toolchain |
79 |
* availibility |
* availibility |
80 |
* openess (parts of docutils have been overwritten) |
* openess (parts of docutils is overwritten - implementation |
81 |
|
not possible / more difficult without open code) |
82 |
* ideology |
* ideology |
83 |
* cheapness |
* cheapness |
84 |
|
|
|
- why html |
|
|
* independent from possible CASE-tools |
|
|
* could be distributed in WWW |
|
|
|
|
85 |
- pictures? |
- pictures? |
86 |
|
|
87 |
- current implemention state |
- current implemention state |
88 |
* gzz version ready |
* created under gzz |
89 |
* separate navidoc version coming up |
* separated as navidoc |
90 |
|
|
91 |
|
- does it really work |
92 |
|
* WWW statistics from himalia, some comparison |
93 |
|
between pages containing UML and pages that |
94 |
|
does not contain |
95 |
|
* what does the previous prove? |
96 |
|
|
97 |
- future |
- future |
98 |
* fenfire |
* fenfire |