zu dem einwand: "weiterhin kann man meiner meinung nach nicht alles vorher planen und in umls stecken, um daraus dann das klassengerüst zu erzeugen. denn während der programmierung tauchen probleme auf, die änderungen nach sich ziehen, die widerrum in das uml müssen." ja, allerdings macht man dann was falsch (wenn man alleine oder zu zweit arbeitet geht das noch, aber stelle dir den wust mit mehreren dutzend entwicklern vor), zumindest wenn man im toplevel aendern muss.
ich denke nich das man dann was falsch gemacht hat.
ich gehe soweit mit, dass man mit genügend zeit nahezu jedes problem (im softwaretechnischen sinne) mittels uml soweit vorplanen kann, dass die implementations-phase nur noch reines runterschreiben ist.
allerdings ergibt sich daraus eine hierarchie. und genau das mißfällt mir an uml. was ich meine:
Der software-architekt (oder mehrere) geben sich unendlich viel mühe ein gutes uml zu erstellen. alles ist (scheinbar) perfekt und sollte auch so funktionieren.
nun kommt der programmierer, nimmt sich das uml und stellt irgendeine ungereimtheit fest. also etwas, was er anders machen würde. jetzt gibt es zwei fälle:
1. der programmierer denkt falsch
2. der programmierer hat recht, denn er hat etwas entdeckt, was die architekten übersehen haben.
weiterhin hat der programmierer nun 2 möglichkeiten:
1. er setzt alles exakt so um, wie es im uml spezifiziert ist
2. er kontaktiert den architekt, der beruft ein meeting ein, dort muss der programmierer erklären was er entdeckt hat und wie es besser gehen würde. anschließend beraten alle, und kommen so irgendwann zu einem kompromiß (oder auch nicht).
punkt 1 würde mir persönlich nicht gefallen, denn da wäre der programmierer eine art maschine, die nicht denken muss, sondern nur tippen.
punkt 2 nimmt viel zeit in anspruch. schätzungsweise mindestens 1 tag braucht sowas (bei größeren projekten) schon. immerhin muß ein termin gefunden werden, der programmierer muss seine (wirren) gedanken in eine präsentierbare form bringen (z.b. folien), die architekten müssen es verstehen und einen ausweg finden.
deswegen denke ich, dass es hier wesentlich effektiver wäre, wenn jeder programmierer die volle kontrolle über sein teil-stück hat (damit natürlich auch die volle verantwortung). er kann so programmieren wie er das will/kann.
damit ergibt sich allerdings die notwendigkeit, das projekt in kleine 1-2mann-teil-projekte (nennen wir es modul) zu zerlegen, was nicht einfach aber möglich ist.
was man dann weiterhin benötigt, ist eine api für jedes modul, die möglichst von anfang an fest sein sollte. diese kann auch von den architekten vorgegeben werden und in eine uml verpackt werden.
naja, ich kann mich hier auch täuchen, denn soviel erfahrung mit großen projekten hab ich nicht.
dennoch nervt mich dieses hochgepushe von uml irgendwie. alle welt guckt nur noch nach einem möglichst schicken uml, auch wenn es nix aussagt. ist irgendwie eine art k.o kriterium für ein softwareprojekt geworden. viel wichtiger ist eine wirklich gute dokumentation (hier reicht javadoc nich), die die zusammenhänge mit worten beschreibt. das versteht jeder, auch ohne die komplette uml2.0 spezifikation verstanden zu haben (is ja wirklich nicht wenig...). ich persönlich komme mit (guten) tutorials am besten klar. durcharbeiten, abtippen, verstanden haben. is aber nur meine persönliche einstellung.
ja und um zu meinem ersten post zurückzukommen: natürlich reicht zettel+stift nicht um präsentierbare umls zu erstellen. aber für die planung und das festhalten erster ideen und konzepte ist der stift einfach mal unersetzlich. so!
schalentier.
) ]
