nicht angemeldet
Hallo, Philipp,
Was wolltest du eingentlich _genau_ wissen?
Da das Testen ja einen betraechtlichen Mehraufwand generiert, so versprach ich mir von der "UML-Geschichte" eine betraechtliche Minderung dieses Aufwandes.Jain. UML vermindert genau _eine_ "Gattung" von Fehler: Konzeptionelle Fehler. Logische,
pysikalische, etc. Fehler lassen sich damit genauso wenig beheben wie finden.
Moment, ich dachte, dass der typische kleine Denkfehler des Entwicklers (nehmen wir mal die nicht unterbundene Division durch 0), also der logische Fehler, dann nicht mehr auftauchen kann. - "Physikalische" Fehler koennten Hardwarefehler meinen, diese koennen auch durch UML nicht zuverlaessig vermieden werden.
Interessant, ich dachte, dass es fast nur noch konzeptionelle Fehler geben wuerde - Ausnahme o.g.
Ich würde jetzt mal behaupten, dass genau _diese_ Gattung von Fehlern bei grossen
Softwareprojekten verherend sind und deshalb lohnt sich auch der grosse Aufwand and
Konzeptionierung in der ersten Phase (sei dies nun über UML, ER, ORM oder was auch
immer). Aber nochmals: das Testing ist damit nicht implizit gemacht, sondern nur um einen
Faktor verkürzt (Faktor Modellierungsfehler, ggf. Redundante Programmierung durch
schlecht oder ungenügend atomare Konzeption [sprich: ein Modul hat eine oder mehrere
themenfremde Aufgaben]).
Also UML ist gut, weil die konzeptionelle Herangehensweise bei der Softwareentwicklung unterstuetzend, aber die Codegeneratoren kann man vergessen ?!
Interessieren tat mich Deine Meinung zur "UML-Geschichte". Konkretes wollte ich nicht wissen, bzw. wusste nicht was ich wissen wollte, oder so aehnlich...
here you are ;-)
Wie immer vielen Dank.
Gruss,
Lude