Model-driven testing und UML

Computer: Software & Programmierung Programmierung allgemein
#1

Hallo!

Meine Frage geht an Softwarearchitekten, die mit UML/UTP Erfahrung gesammelt haben.

Einführung:
Wir sind gerade in der Anlaufphase eines neuen Projekts, wo Dokumentation für eine Hardware mit eingebetteter Software geschrieben wird. Ich soll die grafische Benutzerschnittstelle (GUI) entwickeln. Als Ausgangspunkt wurde ein Vorgängermodell genommen, dessen GUI mir als erstes Dokument vorgelegt wurde. Einige Anpassungen sind im Kommen.

Trotz über 15-jähriger Erfahrung in der Softwareentwicklung war ich als Ausleihpersonal eher selten in der Anfangsphase von Projekten. Man wird meist erst gerufen, wenn es brennt.

Es ist sicher wichtig, so früh wie möglich auch mit der Testdokumentation zu beginnen. Da bietet sich für den Entwurf der Software als „Sprache“ UML, für MDT UTP (UML Test Profile) an.

Details:
Es gibt drei Arten von Anwender (Akteure): Anlagen- & Inbetriebnahmetechniker sowie Systemexperte. Es wird mit der GUI hauptsächlich

  1. Werte überwacht
  2. Die Inbetriebnahme des Gerätes durchgeführt (Inbetriebsetzung)
  3. Neue Software eingespielt/Wartung des Betriebsystems durchgeführt (Expertenmodus)

Es gibt nur für die Inbetriebsetzung gewisse Vorschriften, wie man vorgehen soll. Das Ablesen der Werte über derzeit neue Menüs und deren Untermenüs ist nicht in Detail beschrieben, da man einfach das Menü auswählt, die Tasten (Touchscreen) betätigt, gewisse Sollwerte verändert, usw.

MEINE FRAGE:
Inwiefern ist in diesem Umfang auch mit Blick auf Testfälle die Anwendung von UML zu empfehlen? Sollte man z.B. für jeden „einfachen“ Zugriff auf die neun Menüs erst einmal Anwendungsfalldiagramme zeichnen?! Ich will mich ja nicht zu Tode mit UML zumüllen (siehe http://queue.acm.org/detail.cfm?id=984495). Wäre es überhaupt in so einem „Quasi-schon-vorhanden-Fall“ es sinnvoll, UML überhaupt anzuwenden?

#2

Die Stärke von UML ist klar die Ausdruckskraft. Anwendungsfall-Diagramme (use cases) können auch von fachfremden verstanden werden. Nicht weniger wichtig ist die Wahl des UML Werkzeuges und das Verständnis, dass UML nicht eine lose Sammlung einzelner Bilder (Diagramme) ist.

Wer in UML arbeitet, arbeitet an einem Model. UML Werkzeuge erlauben das Erstellen von Sichten (Diagrammen). Einzelne Elemente einer Sicht dürfen sich auch in anderen Sichten wiederfinden. Ändere ich eine Element in der Sicht, so ist die Änderung auch in anderen Sichten wirksam.

Anwendungsfalldiagramme eignen sich gut für die Anforderungsanalyse. Die bekannten Testfälle werden aufgezeichnet und bei der Überarbeitung verfeinert. Ähnliche Testfälle können verfeinert oder generalisiert werden. UML ist eine Alternative oder Ergänzng zu anderen Vorgehensmodellen, wie Mind Maps.

Mit UML Profilen arbeitet heisst bestimmte Teile des Modells für die spätere Verarbeitung zu markieren. Das ganze Model oder Teile davon werden dazu aus dem UML exportiert und in ein anderes Format transformiert. Das kann eine automatischer oder händischer Prozess sein. Am Ende der Verarbeitung kann eine Dokument mit dem Testplan stehen.

Ob das Endprodukt automatisch erzeugt oder manuell abgeglichen wird, ist geschmackssache. Im Fall der Automatik muss aber klar sein, dass das Zieldokument nicht händisch modifiziert werden kann. Änderungen gehen bei der nächsten Generierung sonst verloren, der Input muss über das Model erfolgen.

Das modellieren und Ausarbeiten von Anwendungsfällen sowie das Erstellen von Testplänen sind unterschiedliche Aspekte. Ob sie Deckungsgleich sind hängt vom Projekt ab. Beispiel: Für die Pflichtenheft-Erstellung ist eine ausführliche Dokumentation der Anwendungsfälle notwendig. Das Budget für Qualitätsicherung ist vergleichsweise klein, außerdem ähneln sich viele Anwendungsfälle und können zusammengefasst werden.

Wichtig bei der Arbeit ist der Pragmatismus. Ich habe erlebt, das UML Modelle zweckentfremdet werden. Weil ein hintergeschalteter Generator bestimmte Anforderungen an das UML stellt, werden dem UML Architekten Einschränkungen auferlegt. Eigentlich möchte der Architekt modellieren, stösst aber immer wieder an diese künstlich geschaffenen Constraints.

Spätestens wenn der Praktikant beauftragt wird, hunderte UML Diagramme zu zeichnen, damit der Testplan hinterher korrekt generiert wird, sollte man sich fragen, ob das der richtige Weg ist. Ist es vielleicht sinnvoller die Dokumente direkt zu Erstellen und zu bearbeiten?

Deshalb mein Rat: vorher überlegen, was mit dem Model bezweckt wird. Es ist legitim mit mehreren Modellen zu arbeiten, etwa eines zum Modellieren und eines um Testpläne zu generieren. Der Abgleich der Diagramme erfolgt über einen Betriebsprozeß.
Stets Kosten und Nutzen in Verhältnis stellen. Welche Vorteile bringt der eingeschlagene Weg und kann die Aufgabe nicht anderes einfacher erledegt werden.

Den Königsweg gibt es nicht. Die Arbeit mit UML ist ein ständiger Prozeß und wird von Projekt zu Projekt varriieren.

#3

Hallo,

ich glaube, dies ist noch nicht so sehr ausgereift. Ich würde eher ein professionelles Test-Framework verwenden (Mercury Interactive, etc.)

Viele Grüße,

Thomas

#4

Ich habe leider wenig Erfahrung mit UML.
Wenn dich meine Meinung dennoch interessiert:

Zitat: "Sollte man z.B. für jeden „einfachen“ Zugriff auf die neun Menüs erst einmal Anwendungsfalldiagramme zeichnen?! "

  • NEIN! Das ist doch Blödsinn.(Sorry)
    Wir sind doch Menschen mit gesundem Verstand. Ich würde
    in dem Fall wahrscheinlich die einfachen Use-Cases in tabellarischer Form anfertigen. Die komplexeren Fälle dann allerdings schon in UML.
    Viel Spaß noch beim Projekt :smile:
#5

Super beantwortet. Danke vielmals!

#6

Hallo,

vereinfacht gesagt, bietet UML ein standardisiertes Set an Grafiken an, mit denen allerlei mögliche Aspekte bei der Softwareentwicklung visualisiert werden können.

UML schreibt weder vor, in welcher Detailtiefe ein System dargestellt werden soll, noch wie vollständig es abgebildet sein muss - was etlichen Entwicklern Problemen bereitet.

In diesem Fall würde ich die Frage, ob man „jeden ‚einfachen‘ Zugriff auf die neun Menüs erst einmal Anwendungsfalldiagramme zeichnen“ soll, für mich umformulieren und fragen, wem es in welcher Phase des Projekts nützt, welche Information in welcher Detailtiefe grafisch vorliegen zu haben. Davon würde ich mich bei der Erstellung leiten lassen.

Anwendungsfalldiagramme dienen üblicherweise dazu, Anforderungen eines Benutzers, und zwar WAS er von einem System erwartet, zu beschreiben. Ich würde mich also mit den Technikern zusammensetzen und sie fragen, was sie zur Interaktion benötigen. Dabei anfallende WIE Anforderungen (z.B. per Menüpunkt x, im Untermenü y etc.) würde ich erst einmal als zusätzliche Beschreibung in den Anwendungsfall mit aufnehmen - wie man hier sieht, kommt man ohne Beschreibung nicht aus, d.h. es kann und es muss auch nicht alles grafisch dargestellt werden, sondern das wesentliche und wichtige; Details und Erläuterungen wandern erst einmal in die Beschreibung / Erläuterung.

Das schließt nicht aus, dass man im Verlauf des Projekts aus den Beschreibungen der Andwendungsfälle weitere Aspekte extrahiert und in einer eigenen Grafik darstellt. Hat z.B. ein Techniker Hinweise zum Ablauf gegeben, hätte ich das erst einmal grob mit in die Beschreibung des Anwendungsfalls aufgenommen und evtl. zu einem späteren Zeitpunkt daraus ein detaillierteres Ablaufdiagramm erstellt (natürlich verbunden mit weiteren Interviews).

Dinge, die eher banal sind oder weniger im Focus stehen, z.B. ein „Über“ Eintrag im Hilfemenü, würde ich gar nicht in UML modellieren, sondern erst einmal einfach in einer Liste von Anforderungen erfassen - und mich mit den Diagrammen auf das wesentliche des Systems konzentrieren. Sollte sich später Anforderungen von meiner Liste als wichtig erweisen, besteht immer noch die Möglichkeit, entweder ein eigenes UML Diagramm daraus zu machen oder die Info als zusätzliches Detail in bereits bestehenden Diagrammen mit aufzunehmen.

Als Vorteil meines oben beschriebenen Vorgehens sehe ich, dass man sich mit seiner begrenzten Zeit erst einmal auf die wichtigen Dinge des Systems konzentriert, durch die Erstellung von Diagrammen für diese Bereiche nicht in einer Diagrammflut ertrinkt und damit auch einen recht guten Überblick über die wichtigen Aspekte eines System erhält.

Gruß
Christian

#7

Hallo,

vereinfacht gesagt, bietet UML ein standardisiertes Set an
Grafiken an, mit denen allerlei mögliche Aspekte bei der

[…]

Gruß
Christian

Vielen Dank, Christian! Als Unerfahrener ziehe ich nun den Schluss, dass ich in allen schon vom Vorprojekt abgeklärten Fällen - sprich grafisch festgelegten Bedienoberflächen - nur bei Bedarf UML-Diagramme zeichnen werde. Sollten neue Anforderungen kommen, werde ich nur für die Zeichnungen fertigen.

Da das Erzeugen von Testfällen aus UML-Diagrammen - was ich so gelesen habe - sowieso noch in den Kinderschuhen steckt, wird das hier nichts damit werden. Denn eine unvollständige Darstellung der Gesamtfunktionalität kann nicht als Basis für Testfälle dienen, will man auch nur halbwegs den Umfang der Funktionalität überprüfen. Da werde ich wohl wie gehabt Testfälle aufschreiben müssen.

Grüße!
Ekrem

#8

Hallo!

Ich habe leider mit UTP keine Erfahrung. Ich generiere zwar auch Testfälle für diverse Testsysteme, aber aus Aktivitätsdiagrammen und den damit verbundenen Anforderungen.
Zur GUI-Modellierung benutze ich ein BPMN-Dervivat in meinem Modellierungstool Innovator von der Firma MID GmbH.

Mich als Fan der modellgetriebenen Entwicklung dürfen Sie eigentlich nicht fragen, ob Sie einem Standard der Softwareentwicklung anwenden sollen. Was wäre den die Alternative!? Eine proprietäre Sprache eines Herstellers oder gar Office-Produkte?

Es hängt leider (wie immer) sehr von Ihrer Methode ab und ob bei Ihnen durchgängig modellgetrieben vorgegangen wird oder sie einer der wenigen sind und nicht auf ihr Modell, also ihre Ergebnisse, aufgesetzt wird.

Gruß

#9

Ich habe die Erfahrung gemacht, dass die Dokumentation mittels UML auf Systemebene sehr effektiv ist. Gerade zu Beginn eines Projektes, ist es wichtig, die Zusammenhänge zu visualisieren. Deine Arbeitsschritte und Änderungen solltest du ja ohnehin Dokumentieren.

In deinem Fall würde ich ein Use Case Diagramm des Systems auf mittlerer Ebene erstellen. Also in dem Stil, wie du es in den drei Punkten schon schriftlich dargestellt hast, nur eine Ebene Tiefer:
-Firmware einlesen
-Target programmieren
-Testdaten laden
-…
Dann kann auch der Auftraggeber (also in deinem Fall dein Chef) und du selbst feststellen, ob noch eine Anwendung fehlt oder Anwendungen zusammen gefasst werden können.
Die Kunst ist, auf der richtigen Ebene zu bleiben, also nicht: Testablauf für Test1 durchführen, Testdaten für TestXYZ durchführen,…

ALSO: Ein Use Case Diagramm fürs Gesamtsystem.

Dann musst du dich ja in verschiedene Details einarbeiten. Ich mache mir da nebenher direkt Skizzen in UML, dann brauch ich beim nächsten mal nur aufs Diagramm zu schauen und bin wieder drin. Gerade bei zu großen Modulen mit komplexen Zusammenhängen sinnvoll.

ALSO: Alles was du einmal durchdacht und nachvollzogen hast und was nicht offensichtlich ist.

Vor allem aber müssen alle Neuerungen deinerseits dokumentiert werden und zwar am besten auf allen Detaillierungsebenen. Also: Welche Komponente wurde verändert, welche Klassen wurden verändert, hinzugefügt oder entfernt und Beschreibung der bearbeiteten Klassen und Änderungen.

Für mich ist die UML für Beschreibung von einzelnen Klassen nicht übersichtlich genug. Ich mache mir einfach Exeltabellen mit den Eingenschaften und verwende Diagramme nur für die Zusammenhänge und Abläufe.

Gruß
Andreas Seeger

#10

Hallo

gleich vorab: in meinem beruflichen Umfeld setzen wir UML als Designnotation ein. Hin und wieder taucht ein Use-Case-Diagramm auf, was aber viel essentieller ist - wenn man mit Use Cases arbeitet -, sind die Use-Case-Beschreibungen. Mit Model Driven Testing habe ich eingeschränkte, mit UTP keine praktischen Erfahrungen.

Der erste Satz gibt mir Rätsel auf: „Wir sind in der Anlaufphase eines neuen Projektes, wo Dokumentation […] geschrieben wird.“ Was meinen Sie damit? In der Anlaufphase eines Projektes versucht man den Umfang und die Machbarkeit bzw. Rentabilität zu klären. Mit Dokumentation hat das m.E. wenig zu tun. Zur Beschreibung des Umfangs kann man Use Cases benutzen, wenn es sich vor allem um interaktive Systeme mit einem klaren Workflow handelt. Die Use Cases können benutzt werden, um Testfälle herzuleiten.

Da unser System aber nicht so einem strikten Interaktionsmuster unterliegt, wirken die Use Cases irgendwie künstlich oder trivial. Wir sind deshalb auf eine „Methode“ umgestiegen, die sehr ähnlich ist zu der, die Mike Cohn im Buch „User Stories Applied: For Agile Software Development“ beschrieben hat. Dort gehört die Testfallbeschreibung als wesentlicher Teil du den User Stories. In gewissem Sinne ist das auch Model Driven Testing, denn so wie ich MDT verstehe heißt das soviel wie: mache dir ein Modell deines Systems und leite daraus systematisch Testfälle ab. Das Modell ist aber nicht zwingenderweise das Designmodel, das mit UML beschrieben wird.

Ich finde es schwierig, auf dieser allgemeinen Ebene über das Thema zu sprechen. Wir können uns gerne mal direkter darüber unterhalten und unsere Erfahrungen austauschen.

#11

Hallo!

Danke für die Antwort! Es ist ein Projekt, wo ich mich funktionell gar nicht auskenne, denn ich bin nur ein externer Mitarbeiter. Das Projekt baut auf ein Vorgängerprojekt auf, das mehr oder weniger übernommen wird. D.h., alle Masken der GUI entsprechen wohl zu 98% dem Vorgängermodell. Die Masken werden also übernommen, wie sie sind; da dachte ich, es hat keinen Sinn, alle noch einmal mit UML-Diagrammen zu belegen.

Hier bei unserem Kunden ist es so, dass am Anfang eines Projekts an Hand der Ausschreibung vom Kunden das sogenannte Lastenheft kommt, auf das dann das vertraglich bindende Pflichtenheft erstellt wird. In dieser Phase befinden wir uns, und ich selbst kann natürlich an dem 150-Seiten-langen Pflichtenheft nicht mitarbeiten, da ich mich nicht auskenne. Da dachte ich, ich will die GUI mit UML-Diagrammen nachbilden und dann - irgendwie - daraus Testfälle erzeugen. Da stieß ich auf den Artikel „UML fewer“, das mich stutzig gemacht hat. Wie ich jetzt einsehe, wäre ich wohl bald von dem Fieber überfallen worden. :smiley:

Hallo

gleich vorab: in meinem beruflichen Umfeld setzen wir UML als