Klausurvorbereitung Software Engineering TFH Berlin

Transkript

1 Teil 1 Einführung in Software Engineering Definition: Was ist Software Engineering? Unter Software Engineering (SE) versteht man den systematischen, disziplinierten und in seiner Größe abschätzbaren Ansatz, Software zu entwickeln, zu betreiben und zu warten (IEEE). Man versteht darunter aber auch die zielorientierte Bereitstellung und systematische Verwendung von Prinzipien, Methoden, Konzepten, Notationen und Werkzeugen für die arbeitsteilige, ingenieursmäßige Entwicklung und Anwendung von umfangreichen Software-Systemen. (H. Balzert, Lehrbuch der Software-Technik). Zielorientiert Berücksichtigung von z.b. Kosten, Zeit, Qualität. Zusammengefasst kann man sagen, dass SE Die Entwicklung komplexer Software erlaubt Den Einsatz von Werkzeugen und Methoden bedeutet Zeit und Kosten spart (sparen kann) Qualität und Produktivität erhöht (erhöhen kann) Hinweis: Die Definition des IEEE ist von mir frei aus dem Englischen übersetzt. Dort lautet sie: The systematic, disciplined, quantifiable approach to the development, operation and maintenance of software. Ich gehe davon aus, dass man diesen englischen Satz zwar verstehen aber nur schwer übersetzen kann und rate zur Verwendung der deutschsprachigen Definition. Das Teufelsquadrat nach Sneed Das Teufelsquadrat nach Sneed zeigt die vier wichtigsten Faktoren bei der Entwicklung von Software-Projekten. Dabei hängen die einzelnen Faktoren voneinander ab, wodurch sich die beiden inneren Vierecke ergeben (eigentlich sind das rote, verzerrte Viereck und das Quadrat in der Mitte das gleiche, nur in unterschiedlichen Situationen). Im Beispiel ist zu sehen, dass eine Erhöhung der Qualität bei Verkürzung der Entwicklungsdauer zwangsweise mit einer Reduktion der Quantität und einer Erhöhung der Entwicklungskosten einhergeht. Das Viereck, welches aus den vier Faktoren gebildet wird, zeigt die Produktivität an, die mit den gegebenen Faktoren erreicht werden kann. Die Fläche des Vierecks bleibt immer gleich. Verschiebungen eines Faktors ergeben also weitere Verschiebungen, so dass sich Gebilde wie das hier rot eingezeichnete Viereck ergeben. Klar, ohne direkten Zusammenhang zum Teufelsquadrat: Erhöht man die Anforderungen an eine Software (z.b. die Quantität der implementierten Funktionen), so muss entweder die Qualität darunter leiden, oder aber Entwicklungsdauer und/oder kosten steigen an. Eben diesen Sachverhalt stellt das Teufelsquadrat dar. Anmerkung: In der heutigen Vorlesung ( ) hieß es, dass die senkrechten Seiten des Produktivitäts-Vierecks immer senkrecht sein müssen Das würde allerdings bedeuten, dass man ein Software-Projekt nur dann mit einer höheren Qualität ausstatten kann, wenn man die Entwicklungsdauer reduziert und das ergibt in meinen Augen wenig Sinn 1

2 Wissensgebiete des Software Engineering nach IEEE Software Requirements Was soll eine Software leisten? Software Design Wie wird die Software aufgebaut (Architektur)? Software Construction Realisierung der Software gemäß dem Design Software Testing Systematische Fehlerfindung und behebung Software Maintenance Wartung und Weiterentwicklung nach Auslieferung Software Configuration Management Verwaltung von Software-Versionen und Konfigurationen Software Engineering Management Projektmanagement von Personen, Organisationen, Zeit, etc. Software Engineering Process Definition und Verbesserung von Software-Entwicklungsprozessen Software Engineering Tools and Methods Werkzeuge und Methoden für die Software-Entwicklung Software Quality Messung und Verbesserung der Software-Qualität 2

3 Teil 1.1 Die Pre-Analyse-Phase Die Pre-Analyse-Phase beinhaltet alle Schritte, die getan werden müssen, bevor man mit der OOA beginnen kann bzw. sollte. Entsprechend Ein erster Schritt ist die Machbarkeitsstudie (Feasibility Study), in der vor dem Beginn des eigentlichen Projekts geprüft wird, ob das Projekt überhaupt durchführbar ist. Diese Prüfung kann projekt- oder marktbezogen durchgeführt werden. Es wird also eine Analyse des Projekts durchgeführt, die zu Lösungsvorschlägen führt. Aufgaben der Machbarkeitsstudie Beschreibung und Analyse des Projekts selbst Prioritäten der Funktionen setzen (was muss drin sein, was kann, was nicht,...) Verschiedene Lösungsansätze erarbeiten Abschätzung von Kosten (ROI Return of Investment), Umfang und Risiken sowie Zeitund Personalaufwand Erstellen eines Angebots Aus der Machbarkeitsstudie gehen hervor: Lastenheft (grobe fachliche Anforderungen) Projektkalkulation (Schätzung von Umfang und Entwicklungskosten) Projektplan (Zeitplan und Festlegung der Phasenergebnisse) Angebot an den Auftraggeber Das Lastenheft Das Lastenheft besteht aus sieben Teilen: 1. Zielbestimmung Hier wird festgelegt, welche Ziele das Projekt erreichen soll 2. Produkteinsatz Welche Anwendungsbereiche hat die Software? 3. Produktfunktionen Dieser Teil beschreibt die Hauptfunktionen des Projekts 4. Produktdaten Beschreibt die Hauptdaten zur permanenten Speicherung 5. Produktleistungen Hier finden sich besondere Anforderungen an Hauptfunktionen oder Hauptdaten 6. Qualitätsanforderungen Funktionalität, Zuverlässigkeit, Benutzbarkeit, Effizienz, Änderbarkeit, Portierbarkeit, Ergänzungen Sonstiges eben Glossar Erklärung aller in den Punkten 1 bis 7 verwendeten Begriffe Adressaten für das Lastenheft sind sowohl Auftraggeber, als auch Auftragnehmer. Es sollte übersichtlich gegliedert sein und auf wenigen Seiten prägnante Sätze in natürlicher Sprache enthalten, die die fundamentalen Eigenschaften des Produktes aus der Sicht des Kunden zusammenfassen. Es sollte vor einem Vertragsabschluss angefertigt werden. 3

4 Anforderungen Man unterscheidet zwischen funktionalen und nichtfunktionalen Anforderungen. Nichtfunktionale Anforderungen Produktanforderungen o Benutzbarkeit o Effizienz (Performanz und Speicher) o Zuverlässigkeit o Portierbarkeit Unternehmensanforderungen o Lieferung o Umsetzung o Standards Externe Anforderungen o Kompatibilität o Interoperabilität o Ethische Anforderungen o Rechtliche Anforderungen (Datenschutz, Sicherheit,...) Funktionale Anforderungen Fachliche Funktionen Ein-/Ausgabedaten Verhalten der Software 4

5 Teil 2 Vorgehensmodelle Vorgehensmodell im Software Engineering werden auch als Software-Lebenszyklus bezeichnet und stellen verschiedene Vorgehensweisen zur Software-Entwicklung zur Verfügung. Sie sind in Phasen unterteilt, die entweder inhaltlich oder zeitlich voneinander abgegrenzt sind. Mit den Vorgehensmodellen ist die Steuerung komplexer Projekte möglich. Für jedes Projekt kann und muss das richtige bzw. passende Modell gefunden werden, da es unterschiedliche Detaillierungsgrade gibt. Vorgehensmodelle können sehr komplex sein, helfen aber dabei, komplexe Projekte zu bewältigen. Oft sind sie firmenintern oder vom jeweiligen Auftraggeber vorgegeben. Je mehr Erfahrung ein Entwickler oder ein Team von Entwicklern mit einem solchen Modell hat, desto effizienter können Zeit und Kosten gespart werden. Das Wasserfallmodell Dieses Modell stammt aus dem Jahre 1970 und ist auch als Phasenmodell bekannt. Es ist in die folgenden Phasen unterteilt: Anforderungsdefinition System- und Software-Design Implementierung (Programmierung) und Modultest Integration und Systemtest Installation und Wartung Diese Phasen bauen (mit Ausnahme der obersten natürlich), als Kaskade aufeinander auf. Man kann von einer Phase zu ihrem Vorgänger zurückgehen, aber keine Stufe überspringen. Wichtig ist, dass jede Phase erst komplett abgeschlossen sein muss, bevor die ihr nachfolgende Phase begonnen werden kann. abgeschlossene und genehmigte Dokumente. Jede Phase liefert ein oder mehrere Vorteile Dokumentation am Ende jeder Phase Kompatibel zu anderen Vorgehensmodellen Geeignet für den Einsatz bei Projekten mit klaren Anforderungen Nachteile Anforderungen werden früh eingefroren Unflexibel (nachträgliche Änderungen sind nicht eingeplant) Die Kosten- und Ressourceneinschätzung ist ungenau 5

6 Das Spiralmodell (Boehm, 1988) Beim Spiralmodell nach Boehm handelt es sich um eine Kombination vorhandener Modelle unter Berücksichtigung von Managementaspekten. Es enthält zwei Achsen: 1. Die Zeitachse 2. Die Kostenachse In den Windungen finden sich die Aktivitäten, in den Winkeln die Fortschritte der einzelnen Projektzyklen. Die einzelnen Windungen sind in vier Sektoren aufgeteilt: Festlegung von Zielen, Beurteilung von Alternativen Risikoanalyse Planung des nächsten Zyklus Entwicklung und Test Im Spiralmodell beginnt der Lebenszyklus eines Projekts im Zentrum der Spirale und verläuft auf ihr nach außen hin. Vorteile Frühzeitiges Erkennen von Risiken und Fehlern Lösungsalternativen Prototypbasiert Kontinuierliche Wartung und Erweiterung Iterativ und inkrementell Nachteile Nicht geeignet für kurzzeitige, kleine Projekte 6

7 Das V-Modell (1986) Beim V-Modell handelt es sich um eine Erweiterung des Wasserfallmodells, in dem aber keine strikten zeitlichen Abfolgen und keine Abnahmen am Ende der einzelnen Phasen vorhanden ist. Beim V-Modell XT handelt es sich um den Entwicklungsstandard für IT-Systeme des Bundes. Es wurde im Februar 2005 in der Version 1.2 vorgestellt. Aktivitäten und Produkte des Entwicklungs- und Planungsprozesses sind festgelegt. Eine Qualitätssicherung ist integriert. So werden die einzelnen Phasen verifiziert ( Wird ein korrektes Produkt entwickelt? ) und validiert ( Wird das richtige Produkt entwickelt? ). Vorteile Das V-Modell ist standardisiert und dennoch flexibel Die Softwarequalität wird gewährleistet Kosten werden reduziert Die Kommunikation zwischen den einzelnen Mitarbeitern/Teams wird erhöht Auftraggeber und nehmer haben eine gemeinsame Sprache Nachteile Anfangs sind Abstimmungsprozesse notwendig 7

8 Weitere Vorgehensmodelle (nicht im Detail relevant für die Klausur) RUP Rational Unified Process Beim RUP handelt es sich um ein Vorgehensmodell und Produkt von IBM Rational. Es bietet statische, dynamische und Praxis-Perspektiven. XP extreme Programming Bei XP findet die Entwicklung in kleinen Schritten statt. Dadurch werden Kommunikation und Tests besonders wichtig. MMD Model Driven Development Auf Grundlage von UML 2.0 wird zunächst ein Modell entwickelt, aus dem später der Code generiert wird (viele UML-Tools können dies automatisch durchführen). 8

9 Teil 3 UML 3.1 Phasen der objektorientierten Entwicklung Die objektorientierte Entwicklung teilt sich in drei Stufen bzw. Phasen ein: OOA, OOD und OOP. Am Anfang steht die OOA, die objektorientierte Analyse. Hier werden fachliche Anforderungen erfasst und beschrieben. Die zweite Phase, das OOD, das objektorientierte Design, befasst sich mit dem technischen Design und der Architektur des Projekts. Am Schluss wird in der OOP, der objektorientierten Programmierung, das Design in einer objektorientierten Sprache (z.b. Java, C#,...) umgesetzt Die Phasen der objektorientierten Analyse (OOA) Die einzelnen Phasen werden mit UML realisiert. 1. Beschreibung von Anwendungsfällen mit Use-Case-Diagrammen 2. Modellierung von Abläufen mit Aktivitätsdiagrammen 3. Darstellung von Zustandsänderungen mit Zustandsdiagrammen 4. Datenmodellierung mit Objekt- und Klassendiagrammen 5. Textuelle Beschreibung der Anforderungen Als Ergebnis erhält man ein detailliertes Pflichtenheft Unterschied zwischen Pflichten- und Lastenheft Unter einem Lastenheft versteht man die Anforderungen eines Kunden, die auch eine grobe Beschreibung des Konzepts enthalten sollen. Ein Pflichtenheft wird dagegen meistens vom Auftragnehmer erstellt. Es geht aus dem Lastenheft hervor und enthält detaillierte Anforderungen. 3.2 Was ist UML? Bei UML (Unified Modelling Language) handelt es sich um eine Modellierungssprache, die als Spezifikation von OMG (Object Management Group), einem Konsortium der Computerindustrie, die Integrationsstandards für Unternehmen entwickelt, herausgegeben wird und sich seit 2004 in der Version 2.0 befindet. UML wird als visuelle bzw. grafische Programmiersprache eingesetzt und hat wie alle anderen Programmiersprachen eine feste Syntax bzw. eine einheitliche Notation. Unter xuml versteht man die ausführbare Variante von UML. Diese ermöglicht es, ein erstelltes Analysemodell als Prototyp auszuführen (man spricht dann vom ausführbaren Pflichtenheft). 9

10 3.3 Die verschiedenen UML-Diagrammarten In UML 2.0 gibt es zunächst einmal zwei verschiedene Typen von Diagrammen: 1. Strukturdiagramme (statisch) 2. Verhaltensdiagramme (dynamisch) Strukturdiagramme Klassendiagramm Objektdiagramm Paketdiagramm Komponentendiagramm Kompositionsstrukturdiagramm Einsatz- und Verteilungsdiagramm (Deployment) Verhaltensdiagramme Anwendungsfalldiagramm (Use Case) Aktivitätsdiagramm (Activity) Zustandsdiagramm (State Machines) Interaktionsdiagramm o Sequenzdiagramm o Kommunikationsdiagramm o Interaktionsübersichts-Diagramm o Zeitdiagramm 10

11 3.4 Das Anwendungsfalldiagramm (Use Case-Diagramm) Beim Anwendungsfalldiagramm in UML werden Geschäftsprozesse dargestellt. Ebenso wird das Verhalten des Systems aus der Sicht des Anwenders beschrieben Die Notation Geschäftsprozesse werden als Oval dargestellt und enthalten eine Beschreibung von sich selbst, die immer aus Substantiv und Verb bestehen muss. Akteure werden als Strichmännchen dargestellt. Bei ihnen handelt es sich um eine Person oder auch ein Teilsystem, welche(s) einen Geschäftsprozess auslöst. Assoziationen Anwendungsfalldiagramme unterscheiden sechs Arten von Assoziationen, die die Beziehungen zwischen den Geschäftsprozessen und Akteuren untereinander darstellen. Einfache Assoziation Beide sind beteiligt, bidirektionaler Informationsfluss Gerichtete Assoziation Quelle löst Ziel aus, Informationsfluss unidirektional Generalisierung Quelle ist Spezialisierung des Ziels Abhängigkeit Quelle ist vom Ziel abhängig, Ziel ist unabhängig Include-Beziehung Quelle enthält die Funktionalität des Ziels Extend-Beziehung Quelle erweitert die Funktionalität des Ziels Sonstige Assoziationen können durch Label beschriften werden. Notizen sind auch möglich und können mit Geschäftsprozessen und/oder Akteuren verlinkt werden. 11

12 Beispiel für ein Anwendungsfalldiagramm Erläuterungen Die gedachte Firma hat sowohl Privat- als auch Geschäftskunden. Diese werden unter dem Begriff Kunde zusammengefasst, haben aber unterschiedliche Eigenschaften. Die Generalisierungen unter den Akteuren auf der linken Seite zeigen diesen Umstand. Der Akteur Kunde kann den Geschäftsprozess Kfz reservieren auslösen, der auch über eine integrierte -Bestätigung verfügt (include). Natürlich sind sowohl Kunde als auch Mitarbeiter am Geschäftsprozess Kfz vermieten beteiligt, der durch den Geschäftsprozess Kfz-Zubehör vermieten in seiner Funktionalität erweitert wird. Der Kfz-Mitarbeiter ist am Geschäftsprozess Kfz reservieren beteiligt (klar). Unten rechts findet sich ein Beispiel für eine Notiz, die mit dem Akteur Kfz-Mitarbeiter verlinkt ist. Beschriftungen über Label wurden hier nicht vorgenommen. Diese erscheinen als Text an den Assoziationen. Findung der Anwendungsfälle Um die Anwendungsfälle zu finden, geht man wie folgt vor: Geschäftsprozesse werden von einem Ereignis ausgelöst und enden mit einem Ergebnis. Zum Beispiel wäre in diesem Fall der Wunsch eines Kunden nach einer Reservierung das auslösende Ereignis und die Reservierung das Ergebnis. Sowohl Auslöser als auch Ergebnis müssen eindeutig festgelegt sein! Anwendungsfälle sind abstrakt. Sie sind daher unabhängig von konkreten Möglichkeiten und technischer Umsetzung. In den Anwendungsfällen spielt es keine Rolle, ob der Kunde einen VW Golf oder einen Raumgleiter reservieren möchte diese Beschränkungen werden erst später berücksichtigt. 12

13 Textuelle Beschreibung Zu einem Anwendungsfalldiagramm gehört auch eine textuelle Beschreibung in Tabellenform. Diese ergänzt das Diagramm, ermöglicht eine detaillierte Beschreibung und bietet zusätzliche Möglichkeiten. Beispiel für eine textuelle Beschreibung Beschreibung des Anwendungsfalls Name (Use Case) Kurzbeschreibung Auslöser oder Motivation Ergebnis Akteure Eingehende Informationen Vorbedingungen Nachbedingungen Kfz reservieren Kunde reserviert ein Kfz Kunde wendet sich mit dem Wunsch nach einer Reservierung an die Firma Für den Kunden wird ein Kfz reserviert Kunde Kundennr., Kundendaten, Reservierungswunsch Keine Es wurde ein Kfz für den Kunden reserviert Ablaufschritte Kunde identifizieren Reservierungswunsch aufnehmen Reservierung prüfen Kfz reservieren Reservierung bestätigen Achtung! Textuelle Beschreibung ist nicht klausurrelevant, sondern nur der Vollständigkeit halber hier! 13

14 3.5 Das Aktivitätsdiagramm (activity) Aktivitätsdiagramme beschreiben in UML einen Ablauf. Es handelt sich dabei um die Schritte der Anwendungsfälle, wobei Bedingungen und Sonderfälle berücksichtigt werden. Aktivitätsdiagramme bestehen aus einer Reihe von Knoten, die miteinander verbunden sind. Im UML 2.0-Standard gilt: Aktivität Aktivitätsdiagramm Aktion Ablaufschritt Die Notation Aktionsknoten Abgerundetes Rechteck. Aktionsknoten stellen einen Ablaufschritt dar und werden mit einem Substantiv und einem Verb bezeichnet. Objektknoten Gibt ein Objekt an und kann als ein- oder ausgehender Parameter genutzt werden. Startknoten (Kontrollknoten) Zeigt den Anfang einer Aktivität bzw. des Diagramms an Endknoten (Kontrollknoten) Das Gegenteil vom Startknoten, zeigt also das Ende an Ablaufende (Kontrollknoten) Zeigt das Ende eines einzelnen Kontrollflusses an Entscheidung, Zusammenführung oder beides (Kontrollknoten) Mit einer Raute wird eine Entscheidung, eine Zusammenführung oder beides dargestellt (genauere Informationen nächste Seite) Teilung, Synchronisation oder beides (Kontrollknoten) Mit einem Balken wird eine Teilung, eine Synchronisation oder beides dargestellt (genauere Informationen nächste Seite) Signal senden/gesendetes Signal Benachrichtigung über ein Ereignis wird verschickt Signal empfangen/empfangenes Signal Benachrichtigung über ein Ereignis löst einen Kontrollfluss aus 14

15 Teilungen, Synchronisationen Von links nach rechts: Teilung (Splitting) Ein Wert geht als Eingangsparameter hinein, zwei gehen hinaus. Beispielsweise könnte man so den Preis einer Ware in Warenwert und Mehrwertsteuer teilen. Synchronisation (und) Das Gegenteil der Teilung ist die Synchronisation. Hier wäre ein gutes Beispiel das addieren der Mehrwertsteuer zum Warenwert, da aus zwei Eingangsparametern ein Ausgangsparameter gemacht wird. Teilung und Synchronisation Eine Kombination der beiden vorherigen Kontrollknoten. Eigentlich müsste dieser Kontrollknoten Synchronisation und Teilung heißen. Ein Beispiel wäre vielleicht ebenfalls, dass als Eingangsparameter Warenwert und Mehrwertsteuer synchronisiert werden und als Ausgangsparameter der Endpreis und die Mehrwertsteuer hinausgehen (wenn man sie dem Kunden anzeigen will). Spezifizierte Synchronisation Hier handelt es sich um eine Art der logischen Verknüpfung. Drei Eingangsparameter gehen hinein, nur einer kommt hinaus. Nehmen wir an, dass es sich bei den drei Eingangsparametern um boolean-werte handelt, die als Beispiel die Werte A = true, B = false und C = true annehmen, dann müsste als Ausgangsparameter ein true herauskommen ( ( w f) ( w w) ergibt ( f w) und das ist natürlich wahr). Das soll aber nur ein Beispiel sein. 15

16 Entscheidungen und Zusammenführungen Von links nach rechts: Entscheidung Von oben kommt ein Eingangsparameter (hier: x) in die Entscheidung. Die drei Pfeile stehen für bestimmte Wege, die der Aktivitätsfluss nehmen kann. Links entspräche der Tatsache, dass x < 0 ist. Rechts entspräche der Tatsache x > 0, während unten für x = 0 stehen würde. Diese Entscheidung in UML entspricht einer if-else if-else-struktur. Zusammenführung (oder) Die drei Eingangsparameter werden sozusagen mit einem logischen oder verknüpft. Ein Beispiel wäre, dass ein Entwickler drei Benutzereingaben erwartet. Sobald auch nur eine davon ausbleibt, möchte er eine Fehlermeldung ausgeben. Also wären die drei Eingangsparameter entsprechende Werte, die kontrollieren würden, ob eine Eingabe ausgeblieben ist und der Ausgangsparameter der Weg zur Fehlermeldung (etwas umständlich, zugegeben, aber was besseres fiel mir grad nicht ein). Entscheidung und Zusammenführung Die Kombination der beiden vorherigen Kontrollstrukturen. Am linken Pfeil steht x<0, am rechten x>0. Swimlanes Swimlanes bezeichnen Verantwortungsbereiche innerhalb eines Aktivitätsdiagramms. Sie werden beispielsweise nach Sachverhalten oder Aufgabenbereichen/Fachbereichen getrennt. 16

17 Beispiel für ein Aktivitätsdiagramm Der Benutzer (der sich bereits registriert hat, klar) möchte sich am System anmelden. Dazu muss er seine Benutzerdaten, also Benutzername und Passwort, eingeben. Hat er dies getan, wird zunächst der Benutzername überprüft. Ist er in der Datenbank nicht vorhanden, also falsch, geht es zum Ausgangspunkt zurück. Ist der Benutzername in Ordnung, wird das Passwort geprüft. Ist dieses falsch, geht es wieder zurück zum Ausgangspunkt. Ist das Passwort korrekt, wird eine Willkommensmeldung ausgegeben und der Benutzer ist am System angemeldet. Anmerkung: Das ist nicht unbedingt ein Beispiel aus der Realität, da hier nur ein Bruchteil dessen gezeigt wird, was bei einem reellen Login, beispielsweise bei einem Forum, tatsächlich passiert. Als Beispiel sollte es aber reichen. 17

18 Testfälle Unter Testfällen versteht man detaillierte Anforderungen an die Abläufe im Aktivitätsdiagramm. Sie stellen die Vollständigkeit der Abläufe sicher. Pro Kontrollfluss gibt es einen Testfall, wobei alle Pfade und Varianten durchlaufen werden müssen. Es kann auch vorkommen, dass ein Testfall eine neue Aktion zur Folge hat (es kann ja immer passieren, dass beim Erstellen des Diagramms ein wichtiger Punkt vergessen wurde). Testfälle decken also praktisch die möglichen Situationen ab, die ein Kontrollfluss im Betrieb des Projekts zu bewältigen haben könnte. Beispiel für Testfälle Benutzername prüfen Benutzername nicht gefunden Benutzername gefunden Passwort prüfen Passwort falsch Passwort richtig Diese Testfälle würden also bedeuten, dass die Entwickler das System/Projekt auf vier Fälle testen müssten: Sie geben jeweils einen falschen und einen richtigen Benutzernamen ein, gleiches gilt für das Passwort. Andere Anwendungsfälle sind beispielsweise: Spezielle Eingabedaten für Algorithmen (z.b. 0, 1, negative Zahlen, etc.). Achtung! Ableitung der Testfälle aus dem Aktivitätsdiagramm ist nicht klausurrelevant und nur der Vollständigkeit halber hier! 18