1 |
:Stamp: $Id$ |
:Stamp: $Id$ |
2 |
|
|
3 |
|
Issues |
4 |
|
------ |
5 |
|
|
6 |
|
- How much should we talk about *our* process, how much about |
7 |
|
processes in general? |
8 |
|
OTOH, talking more about us makes it more personal but may make it |
9 |
|
also seem less relevant to others' efforts. |
10 |
|
|
11 |
|
SUGGESTED RESOLUTION: "Setting of problem" should be about us: |
12 |
|
describe exactly what docs **we** have. Everything else |
13 |
|
should be more general, and we should point out that |
14 |
|
this situation is probably not uncommon. |
15 |
|
|
16 |
|
- why even outdated but well simplified diagram |
17 |
|
is better than too detailed, automaticly up-to dated |
18 |
|
and reverse engineered diagram. |
19 |
|
|
20 |
|
SUGGESTED RESOLUTION: We use UML in our architectural |
21 |
|
documentation to support our group's intercommunication and |
22 |
|
describing our project to the open software community. In |
23 |
|
this use the readability and intelligibility (well abstracted |
24 |
|
and neatly adjustedt) matters over detailed up-to-dated |
25 |
|
class spesifications. |
26 |
|
|
27 |
|
- how rational rose links diagrams into code and documentation? |
28 |
|
|
29 |
|
PARTIAL RESOLUTION: Probably all documentation is primary stored |
30 |
|
within its own datamodel. The documentation within datamodel could |
31 |
|
be browsed at least by Rose's hierachical tree menu. Implementation |
32 |
|
of cross-hierarchical links and browsin along them still unkown. |
33 |
|
When generating sourcecode, the documentation could be embedded into |
34 |
|
source as comments. Some user comment didn't like Rose's way of |
35 |
|
adding extra comments into generated code |
36 |
|
<http://c2.com/cgi/wiki?RationalRose> |
37 |
|
|
38 |
trashbin |
trashbin |
39 |
-------- |
-------- |
40 |
|
|