Tests / Qualitätssicherung - aber wie?

[Philipp Hasenfratz]

Halihallo Lude

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.

Missing Begriffsdefinition. Das logisch und physikalisch in UML ist IMHO nicht direkt mit
logischem oder physikalischem Fehler gleichzusetzen. Meistens wird in UML gar nicht auf
diese Ebene runter modelliert (bzw. diese Ebene ist gar nicht mehr Bestandteil der
Modellierungsarbeit). Die konzeptionelle Schicht definiert z.B. die Relation zwischen
Kunde und Warenkorb, wobei eine logische Schicht z.B. definiert, welche Artikel welcher
Kunde sehen darf, bzw. wie man die Gesamtzahl aller Artikel oder Endsumme der Bestellung
berechnet. Hm, eigentlich gar nicht unwahr, dass das ein logischer Fehler ist, evtl. sind
die Begriffe doch einigermassen synonym verwendbar; dennoch geht man mit UML oftmals
nicht so weit in die Tiefe, dass man logische Fehler wirklich 100% ausschliessen kann.
Zudem ist nicht jede "division durch 0" (um beim Beispiel zu bleiben) durch die
konzeptionelle, logische oder physikalische Sicht sichtbar, denn dieser Fehler wird
meistens in der Programmlogik per se verursacht, nicht in der Relation mehrerer
Programmlogiken. UML modelliert ja nicht den Quelltext einer Methode, sondern höchstens
die Verbindung/Nachrichtenaustausch jener.

Interessant, ich dachte, dass es fast nur noch konzeptionelle Fehler geben wuerde - Ausnahme o.g.

Das ist IMHO stark von der Tiefe der Modellierung abhängig... Zudem: ggf. erkennt man
Fehler bereits während der Konzeptionierung, aber man kann sie genauso leicht
übersehen, wie es im resultierenden Quelltext geschieht. Die Maschine kann nicht
entscheiden, was richtig und was falsch ist; demnach muss der Mensch es dem Computer
beibringen (eg. Test-Module) oder es in der Konzeptionierung bereits erkennen. Wenn der
Computer über UML feststellen soll, wo ein Fehler ist, musst du ihm beibringen, was
richtig und was falsch ist und somit verschiebt sich das Testing einfach auf das UML
Modell (irgendwelche sinnvollen Constraints definieren, wie dies in den Test-Modulen
der Fall wäre).

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 ?!

Nein, das würde ich nicht sagen. Sie sind lediglich ein Werkzeug, das man verwenden kann,
oder man lässt es. Sie machen nichts schlechter oder besser (vorausgesetzt der
Programmierer bildet das Modell ebenfalls 100% richtig ab, was IMHO nicht unmöglich ist,
denn wenn er falsch abbildet merkt er es früher oder später [eg. eine Klasse vergessen,
oder einen Inputparameter nicht angegeben]). Um das Programmieren kommt aber (noch)
keiner herum und _da_ entstehen eben noch weitere Fehler (welche ich vorher mit dem
"anderen" logisch und physikalisch umschrieben habe).

Viele Grüsse

Philipp