Einführung in die Softwaretechnik PDF

02 Was ist Softwaretechnik? Ziel: Was versteht man unter Softwaretechnik? 5 AUSGANGSPUNKT Typische Probleme bei der Software-Entwicklung: zu teuer zu spät Kunde nicht mit dem Ergebnis zufrieden......

02 Was ist Softwaretechnik? Ziel: Was versteht man unter Softwaretechnik? 5 AUSGANGSPUNKT Typische Probleme bei der Software-Entwicklung: zu teuer zu spät Kunde nicht mit dem Ergebnis zufrieden... 6 ZIEL: → Angemessene Kosten, hohe Qualität Hohe Qualität heißt insbesondere: – fehlerfrei – schnell – schnell/leicht veränderbar – leicht testbar – benutzerfreundlich – sicher 7 ANSATZ I: INDUSTRIALISIERUNG  Entwicklungsstufen: Laie → Zufallstreffer Handwerker → Teure Einzelanfertigung Ingenieur → Qualität am Fließband → Software-Entwicklung als Ingenieursdisziplin: → Softwaretechnik (Software Engineering)  Erfolgsfaktoren (Erfahrung): erprobte Methoden erprobte Werkzeuge 8 DEFINITIONEN  Softwaretechnik (Software Engineering) = Methoden + Werkzeuge + Hilfsmittel, die Softwareentwickler dabei unterstützen, für Geld reproduzierbar Software hoher Qualität herzustellen. Software = Programm Konfigurationsdateien Dokumentation... 9 HINWEISE ZU DEN BEGRIFFEN  Vielleicht spreche ich auch öfters von Software Engineering  Der englische Begriff  Abkürzung: SE  Auch im deutschsprachigen Raum Weiterer Hinweis: Es gibt auch Systems Engineering → Hier geht es darum ganze Systeme zu entwickeln HW, Software, Mechanik, Elektrotechnik, Chemie, … → Auch hier ist Software involviert – Diesen Aspekt klammern wir hier weitestgehend aus → Hier geht es i.w. nur um reine Softwaresysteme → Näheres zu SysEng können Sie z.B. in der Anforderungsmanagement-Vorlesung von Hr. Turban erfahren 10 ANSATZ II: SOFTWARE CRAFTMANSHIP Ansatz I – Industrialisierung (traditionell) – SE als Ingenieursdisziplin, die zur „Industrialisierung“ führt – Z.B. durch Strukturierte Methoden → Große Fortschritte, aber nicht so durchschlagende Erfolge wie ursprünglich erwartet Ansatz II – Meisterliches Handwerk (Software Craftmanship) – Man ist bescheidener geworden, was die Idee der Industrialisierung angeht. – SW ist anders als z.B. Bauingenieurwesen SW ist z.B. sehr abstrakt und es sind andere Lösungen mögl. → Agile Methoden 11 ANSATZ II: SOFTWARE CRAFTMANSHIP  Ansatz I – Industrialisierung (traditionell)  Ansatz II – Meisterliches Handwerk (Software Craftmanship) → z.B.: Agile Methoden  Erfolgsfaktoren für Ansatz II: erprobte Methoden NUR: Etwas andere Methoden erprobte Werkzeuge und Werkzeuge als für I Was lernen wir hier? – Hauptsächlich Ansatz I + grundlegende Hinweise zu Ansatz II – Ansatz I ist nicht verkehrt → wird noch sehr oft benutzt – Bildet die absolute Basis für weiterführende Überlegungen – ABER: Es gibt eben wesentlich mehr als wir hier lernen können 12 KERNTHEMEN FÜR UNS Das sind für uns die wichtigsten Themen in diesem Semester: Strukturierte Vorgehensweise hier OOAD („Object-Oriented Analysis and Design“) Projektplanung und -management einheitliche Notation für SW-Modelle Hier: UML (Unified Modeling Language) FMC (Fundamental Modeling Concepts) Konzepte und Abstraktionen: z.B. Muster, SW-Architektur Qualitätssicherung – z.B. Testen die wichtigsten Werkzeuge für die SW-Entwicklung 13 03 Der Softwareentwicklungszyklus Ziel: Den grundlegenden Entwicklungszyklus für Software kennenlernen 14 WICHTIGE BEGRIFFE – ARTEFAKT Beschreibt -ganz abstrakt- ein von Menschen künstlich (artifiziell) erstelltes Objekt. Ein Artefakt ist nicht notwendigerweise ein Dokument – Ein Art. kann durch eines oder mehrere Dok. ausgedrückt werden – Ein Dok. kann aber auch mehrere Art. beinhalten Beispiel: Das Artefakt „Quellcode“ besteht meist aus mehreren Codefiles (=mehrere Dokumente). Gut sich selbst dokumentierender Code (z.B. dokumentierte Methodenköpfe) enthält auch schon Teile des Artefaktes „Dokumentation“. → Können (z.B. über JavaDoc) noch in ein explizites Doku- mentationsdokument transformiert werden. 15 WICHTIGE BEGRIFFE – STAKEHOLDER Englisch für Interessenvertreter, Akteur – „Stabhalter“ - Staffellauf – Something is at stake == etwas steht auf dem Spiel Def nach Pohl und Rupp [PR15; S.4]: Ein Stakeholder eines Systems ist: – eine Person oder Organisation, die – direkten oder indirekten Einfluss auf das Projekt (v.a. die Anforderungen) des betrachteten Systems hat. [PR15] Pohl, K.; Rupp, Chr.: Basiswissen Requirements Engineering, dpunkt, 2015 16 LEBENSZYKLUS VON SOFTWARE → Beschreibt die typischen Tätigkeiten bei der SW-Entwicklung 17 LEBENSZYKLUS VON SOFTWARE → Beschreibt die typischen Tätigkeiten bei der SW-Entwicklung 1. Analyse: Was will der Kunde? (= Anforderungen) 2. Entwurf: Wie soll das zu bauende System sein? grob: Grobentwurf (Architektur/Architecture) detailliert: Feinentwurf (Detailed Design) 3. Implementierung: Entwurf → Programm 4. Test: Erfüllt das Programm die Anforderungen und den Entwurf? 5. Betrieb: Verwendung des Programms 6. Wartung und Pflege Änderungswünsche/Fehler → Was will der Kunde? →... 18 LEBENSZYKLUS VON SOFTWARE → Beschreibt die typischen Tätigkeiten bei der SW-Entwicklung Vorsicht: Ist eine Idealisierung! → In der Praxis kann auch mal von Implementierung wieder zur Analyse zurückgesprungen werden,... 19 MEHR VORGABEN SIND NÖTIG  Typische Fragen bei der Software-Entwicklung: – Wie fangen wir an? – Was sollen wir tun? – Wie verteilen wir die Aufgaben? – Wie machen wir’s richtig? –... → Hier sind mehr Vorgaben nötig 20 04 Vorgehensmodelle Ziel: Vorgehensmodelle kennenlernen 21 MEHR VORGABEN SIND NÖTIG → Vorgehensmodelle = Bestimmte Vorgaben für die Durchführung von Software- Entwicklungs-Projekten  Typische Vorgaben:  Abfolge von Phasen/Tätigkeiten  Artefakte = Resultate von Phasen/Tätigkeiten, z.B.  Beschreibung der Anforderungen in bestimmter Form  Testfallbeschreibungen in bestimmter Form  Quellcode-Dateien gemäß Codier-Richtlinien  Zusammenhänge zwischen den Phasen/Tätigkeiten  Andere organisatorische Aspekte 22 VORGEHENSMODELLE – BEISPIELE Frühe Modelle – Wasserfall – V-Modell (Deutsche Erfindung – oft benutzt, z.B. Behörden, Automotive) Iterativ-inkrementell – Spiralmodell (von Barry Boehm) – Rational Unified Process (RUP) Agile Methoden – eXtreme Programming – SCRUM 23  V-MODELL Abwandlung des Wasserfall-Modells – Deutsche Erfindung (TU München → siehe Manfred Broy) – oft in Deutschland benutzt, z.B. Behörden, Automotive, … → Leider sehr starr → Zunächst nicht iterativ geplant → Nur ein Zyklus 24  V-MODELL Weiterentwicklung für iterative Entwicklung: Redesign (seit 2005): V-Modell XT – Iterativ, inkrementell, wesentlich flexibler und besser skalierbar (Reaktion auf RUP, Spiralmodell & Agile Methoden) 25 SPIRALMODELL Entwickelt von Barry Boehm – Iterativ & inkrementell 26 Bildquelle: „Spiralmodel nach Boehm.png“ von WikiMedia Commons RATIONAL UNIFIED PROCESS (RUP) Entwickelt parallel zur UML – Von der Firma Rational (jetzt IBM) – Iterativ & inkrementell Quelle: „Development-iterative.png“ von WikiMedia Commons 27 AGILE METHODEN Kontrast zu den klassischen Vorgehensmodellen – Abkehr von starren Prozessen – Keine richtigen Vorgehensmodelle in klassischen Sinn – Eher Sammlung von Prinzipien (Best Practices) → Muster-Idee → Prozessmuster (siehe Vorlesungseinheit zu Mustern) Typische Beispiele: – eXtreme Programming (XP) → Für Entwicklung z.B. Microsoft hat für Entwicklung von Win 7 auf XP gesetzt – SCRUM Eigentlich eher eine Projektmanagementmethode Für eigentliche SW-Entwicklung kann z.B. XP genutzt werden oder anderes Derzeit richtig „IN“ 28 WAS MACHEN WIR JETZT Das war jetzt nur mal zur Orientierung – Im Januar werden wir darauf nochmals genauer zurückkommen Woran sollten Sie sich jetzt orientieren? – Wir benötigen für das Praktikum & spätere Projekte: einen Rahmen für OOAD solide erprobt → V-Modell und RUP – V-Modell, weil es sehr eingängig von den Phasen her ist – RUP, weil es für Objektorientierte Entwicklung speziell viele geeignete Hilfsmittel vorstellt → Beides ist dazu gut kompatibel 29 WELCHE TÄTIGKEITEN BETRACHTEN WIR? Wir betrachten folgende Tätigkeiten (RUP: „disciplines“) – Anforderungs-Analyse (RUP: „Requirements“) Was will der Kunde? – Analyse und Entwurf (RUP: „Analysis and Design“) Wie soll das zu bauende System sein? – Implementierung (RUP: „Implementation“) Das System programmieren – Testen (RUP: „Test“): Wie stelle ich sicher, dass das System das tut, was es tun soll? Wir gehen nicht ein auf: – Geschäftsprozessmodellierung (RUP: „Business Modeling“) -> dazu gibt es eine eigene Vorlesung! – Inbetriebnahme (RUP: „Deployment“) 30 05 Fazit Ziel: Was haben wir damit gewonnen? 31  Einführung WAS HABEN WIR GELERNT?  Den Begriff Software Engineering kennenlernen  Lehre von Methoden + Werkzeugen + Hilfsmitteln zur systematischen Entwicklung von Software hoher Qualität  Grundlegende Entwicklungszyklus für Software  Vorgehensmodelle  Weiteres, genaueres Vorschriftengerüst 32  Einführung WORUM GEHT ES IN DEN KOMMENDEN VORLESUNGEN?  Modellierung von Software  Mittels Zeichnungen die Eigenschaften einer Software herausarbeiten → Wir lernen die Modellierungssprache UML kennen  Später (ab Mitte des Semesters):  beispielhafter Einsatz dieser Zeichnungen im Projektkontext → Anhand des Vorgehensmodells RUP + Weitere wichtige Sachen jeweils zu diesen Aktivitäten 33 Softwaretechnik 02a Einführung in die UML  MODELLIERUNGSSPRACHEN Bei der Softwareentwicklung haben wir es häufig mit – einem großen Anwendungssystem – und vielen Kolleg:innen zu tun Wichtige Fragen bei der praktischen Durchführung: – Wie können wir uns auch über verzwickte Sachverhalte austauschen? – Wie können uns möglichst viele verstehen? –... → Grafische Modellierungssprachen, z.B. UML – Verständliche Darstellung auch komplexer/komplizierter Sachverhalte durch Grafiken (Zeichnungen) – standardisiert 4  WAS IST UML? = Unified Modeling Language – Standard der OMG OMG = Object Management Group - http://www.omg.org/ Aktuelle Version: UML 2.5.1 (Dezember 2017) > 10 Diagrammarten – Ziel: Graphische Modellierung objektorientierter Softwaresysteme → Mittlerweile de-facto Standard für Modellierung von Software aller Art – BSP aus OOSE: 6  WAS IST UML? Für uns: – Grundlegende Modellierungssprache – Später lernen wir jedoch auch noch FMC kennen → Hat gewisse Vorzüge in der Architekturmodellierung – Aber mit UML kann man das eigentlich auch machen 7  UML-DIAGRAMME SIND VIELSEITIG VERWENDBAR Typische Verwendungsarten: – Anforderungsspezifikation – Analyse – Entwurf – Implementierung Detailed Design (vorher) Dokumentation (ggf. nachher) – Test (Design eines Testszenarios) Das kann verwirrend sein: – Diagramm-Syntax ist unabhängig von der Verwendungsart Syntax (= Regelsystem für das Aussehen/die Form) Semantik (= Bedeutung, Bedeutungsebene) 8  BEISPIEL: ARTEN VON KLASSENDIAGRAMMEN Implementierungs-Klassendiagramm – (fast) gleichwertig zu Quellcode Entwurfs-Klassendiagramm – 1:1-Beziehung zum Quellcode (hoffentlich!) – Aber: programmiersprachenunabh., oder unabh. von Details Analyse-Klassendiagramm – Beschreibt fachliche und keine technischen Konzepte → Gleiche Syntax für alle Arten von Klassendiagrammen → Semantik (Bedeutung) abhängig von der Verwendungsart 9 Softwaretechnik 02b Objektdiagramme  WAS SIND OBJEKTE? 1. Laut Duden: „Objekt“ ist aus dem Lat. ≙ „Gegenstand“ – Objekt ≙ Ding mit Eigenschaften und Fähigkeiten 2. Beim Programmieren (z.B. Java): Klasse: ↔ Objekt: „Turban“ 185“ → Konkrete Instanzen einer Klasse → Objektwerte, Anzahl Objekte, sind veränderlich → Im dynamischen Speicher → Definitionscode unveränderlich → Im statischen Speicher 4 WAS SIND OBJEKTE IN DER UML? 1. Laut Duden: „Objekt“ ist aus dem Lat. ≙ „Gegenstand“ – Objekt ≙ Ding mit Eigenschaften und Fähigkeiten → Es gibt eine Person mit den Eigenschaften Nachname == “Turban” und Fachliches Konzept (≙ Business Object) Grösse == 185 cm z.B. in Anforderungsbe- schreibung oder in der Analyse → Unabhängig von Programmierung oder einer sonstigen technischen Umsetzung → Fachliche Sicht 5 WAS SIND OBJEKTE IN DER UML? 2. Beim Programmieren (z.B. Java): Klasse: ↔ Objekt: → Ein Objekt der Klasse Konkretes Technisches Konzept „Turban“ z.B. in Design 185“ oder mit Attributbelegungen Implementierung → Abhängig von Programmierung oder einer sonstigen technischen Umsetzung → Technische Sicht (Implementierung) 6  Einführung (MÖGLICHE) DARSTELLUNG FÜR BEIDE SICHTEN Immer mit : und unterstrichen! → Kennzeichnet Objekt Art des Objekts im Gegensatz zu Klasse (Classifier, Class Type) Objekt (Instanz) 8  Einführung (MÖGLICHE) DARSTELLUNG FÜR BEIDE SICHTEN Nicht verwechseln! Optional: Name des Objekts (Instance Name) Bei wichtigen Variablen verwenden → Dient in der Regel als Unique Identifier BEM: Bis auf : ist alles optional Minimum, aber macht das Sinn? 9  Einführung (MÖGLICHE) DARSTELLUNG FÜR BEIDE SICHTEN Konkrete Eigenschaft (Slot) → Besteht aus: i) Name der Eigenschaft (Feature Name) ii) Optional: Typ der Eigenschaft (z.B. :String) iii) Belegung / Wert (Value Specification) 10  Einführung WEITERE BEMERKUNG ZUR DARSTELLUNG  Ein Objekt hat (i.d.R.) maximal drei Abschnitte:  (vgl. auch Klassendiagramm kommende Woche) Name + Typ Eigenschaften (Fähigkeiten) → Methoden/Operationen → Methoden lässt man i.d.R. bei Objekten weg → werden im Klassendiagramm definiert und ändern sich nicht mehr → sind bei allen Objekten der gleichen Klasse die gleichen 11  Einführung VERBINDUNGEN (LINKS)  manche Objekte haben miteinander zu tun → Es gibt Verbindungen, die wir modellieren können müssen Verbindung (Link) 13  Einführung VERBINDUNGEN (LINKS) Mögliche Bedeutungen: 1. Fachliche Sicht: – Wir haben ein Paar, das aus der Person mit Namen „Romeo“ – und der Person mit Namen „Julia“ besteht 2. Technische Sicht: Oder: Oder: 14  Einführung VERBINDUNGEN (LINKS) – AGGREGATION & KOMPOSITION  Betonung des Aspekts „besteht aus“: (v.a. in Analysediagrammen* nützlich) „besteht aus“, „enthält“ „besteht aus“, „enthält“ (Aggregation) (Komposition) Stärker als * Diagramme, die im Zuge der Analysephase gemacht werden → Siehe Fachmodell in Vorl. zur Anforderungsanalyse 15  Einführung VERBINDUNGEN (LINKS) – AGGREGATION & KOMPOSITION  UML definiert folgende Bedeutung für & Für beide sind keine zyklischen Abhängigkeiten erlaubt ist in folgendem Sinne stärker als : existienzielle Abhängigkeit zwischen Ganzes Teile Teil kann mit max. 1 Ganzem verbunden sein (0..1) Ganzes ist verantwortlich für Existenz und Speicherung der mit ihm verbundenen Teile → Wenn Ganzes gelöscht wird, dann erzwingt das auch das Löschen der verbundenen Teile Gerne Anlass für (unnötige) Diskussionen → TIPP: dann verwenden, wenn WIRKLICH notwendig 16 WEITERE INFORMATIONEN ZU OBJEKTVERBINDUNGEN (LINKS)  Zu Objektverbindungen (Links) können weitere Infos hinterlegt werden: Name / Typ der Verbindung Optional: (Association Name) Leserichtung (Order of Reading) Rollenname (End Name) ( ) Auch möglich, aber nicht besonders schön: 17 SPEZIALLFALL: KONSTANTEN UND PRIMITIVE OBJEKTE  Konstanten (Werte), oder primitive Objekte, oder berechenbare Werte darstellen: → Objekt mit einer Eigenschaft, deren Name nicht bekannt ist → Da es nur einen Wert gibt, empfiehlt z.B. Rupp et al dann auch den (unbekannten) Eigenschaftsnamen wegzulassen: (Siehe auch: Rupp et al.: UML glasklar, S.189) 19  Einführung DIE BEDEUTUNG DES OBJEKTDIAGRAMMS  Das Objektdiagramm stellt nur einen bestimmten Schnappschuss (Momentaufnahme) dar  Wenig später ist vielleicht folgendes passiert:  Neue Objekte erzeugt  Neue Verbindungen zwischen Objekt entstanden  Es wurden einige Objekte gelöscht  Einige Verbindungen zwischen den Objekten wurden gelöst → Die neue Situation ist ganz anders → Man müsste ein neues Diagramm zeichnen → Mit dem Klassendiagramm kann ein allgemeingültiges Diagramm aller möglichen Objektkonstellationen zeichnen → Definiert alle möglichen Objektdiagramme 21  WIR ERINNERN UNS AN DEN ANFANG: Programmieren: Klasse: ↔ Objekt: → Konkrete Instanzen einer Klasse → Definitionscode unveränderlich → Objektwerte, Anzahl Objekte, … sind veränderlich → Im statischen Speicher → Im dynamischen Speicher „Turban“ 185“ UML: → Klassendiagramm → Objektdiagramm → Eine statische Sicht → Eine dynamische Sicht → UML ermöglicht viele verschiedene Sichten (sog. Sichtenkonzept) 22  WEITERE SICHTEN: 1. Laut Duden: „Objekt“ ist aus dem Lat. ≙ „Gegenstand“ – Objekt ≙ Ding mit Eigenschaften und Fähigkeiten → Fachliche Sicht 2. Beim Programmieren (z.B. Java) → Technische Sicht 23  FACHLICHE ↔ TECHNISCHE SICHT → Fachliche Sicht: alles ohne technische Details → Wird in der Analyse verwendet, um NUR die fachlichen Anforderungen zu ermitteln → Technische Sichten – In Architektur, Detailed Design, Implementierungsdoku. verw. – Es werden auch die für die Lösung relevanten technischen Details dargestellt: + Technische Lösung (z.B. für spezifische Suche nach Städten oder Adressen) 24  Einführung WAS HABEN WIR GELERNT?  Verschiedene Sichten  Fachliche Sicht (Nur fachliche Zusammenhänge aus Sicht des Kunden) → Anforderungsanalyse  Technische Sicht (Technische Umsetzung) → Design & Implementierung → Beide können unterschiedlich zueinander sein  Objektdiagramm  Objekte  Rechteckiger Kasten mit max. 3 Unterteilungen  Instanzname : Typname, Wertbelegungen  Verbindungen  Einfache Links, Aggregation, Komposition  Verbindungsname, Richtung, Rollennamen  Das Objektdiagramm stellt nur einen Schnappschuss dar 26 Softwaretechnik 03 Klassendiagramme  DAS KLASSENDIAGRAMM Neben dem Objektdiagramm – Objekte und deren Beziehungen (Links) – Schnappschuß einer besimmten Situation zu bestimmter Zeit → dynamische Sicht Gibt es das Klassendiagramm – Klassen und deren Beziehungen (Associations) – Allgemeine Definition der Klassen und aller möglichen Beziehungen zwischen Objekten durch Assoziationen zwischen Klassen → statische Sicht 4 BEISPIELE AUS DER OOSE – VORLESUNG  Das Klassendiagramm wurde in OOSE bereits verwendet: Vorsicht: :void als Rückgabeparameter ist kein korrektes UML!! → Nur gemacht, um es im 1. Semester leichter zu vermitteln! → bitte nicht in Klausur verwenden 5 BSP: DEFINITION PAARE UND DEREN BEZIEHUNGEN 1. Es gibt nur Paare, die mit 2 Personen verbunden sind 2. Eine Person kann höchstens mit einem Paar verbunden sein → Man könnte zur Spezifikation dieses Sachverhalts nun einige Objektdiagramme zeichnen: … → Das kann i.d.R. aber nicht mehr als eine unvollständige Auflistung von richtigen & falschen Beispielen sein. 7 DAS KLASSENDIAGRAMM → Wir brauchen eine vollständige Darstellung der Sachverhalte für den allgemeinen Fall → Klassendiagramm: Klassenname (class name) Klasse (class) Vergleiche die Darstellung! Klasse: Objekt: 8  DAS KLASSENDIAGRAMM – ASSOZIATIONEN Verbindungen zwischen Klassen → Assoziationen: Assoziation (association) BEM: Assoziation ≙ Beziehungstyp im Entity-Relationship-Diagramm 9  DAS KLASSENDIAGRAMM – ASSOZIATIONEN Weitere Infos zu einer Assoziation: Name der Assoziation (association name) Optional: Leserichtung Kardinalität / Rollenname Multiplizität (role name) (multiplicity) Kardinalitäten: Allgemeine Form: Untergrenze…Obergrenze ≙ ∞ / beliebig ∈ℕ ∈ ℕ ∪ {*} Spezialformen: a…a | a → nur/genau a (Bsp: 7…7 → genau 7) → unbestimmt 10  DAS KLASSENDIAGRAMM – DEPENDENCY* Neben Assoziationen gibt es noch Dependency-Pfeile → Für einfache Abhängigkeitsbeziehungen Dependency Stereotyp (Stereotype) «... » = Erweiterungsmechanismus der UML → Genauere Definition (Eingrenzung) der Abhängigkeitsbeziehung - Typische Stereotypen für Dependencies*: «use», «import», «create», «call», « abstraction», «instanciate», «instanceOf», … - Eigene Stereotypen möglich 11 *Siehe auch: https://www.guru99.com/uml-relationships-with-example.html 03 Weitere Anmerkungen zu Assoziationen Ziel: Weitere Details zu Assoziationen besprechen 12 KLASSENDIAGR.: ASSOZIATION ↔ OBJEKTDIAGR.: LINKS Weitere Bemerkungen zu Assoziationen:  Eine Assoziation im Klassendiag. (KD): entspricht evtl. n Links in einem Objektdiag. (OD): ↔  Beziehung in der UML: Klassendiag.: Objektdiagr.: 13 KLASSENDIAGR.: ASSOZIATION ↔ OBJEKTDIAGR.: LINKS Weitere Bemerkungen zu Assoziationen:  Eine Assoziation im Klassendiag. (KD): entspricht evtl. n Links in einem Objektdiag. (OD): ↔  1 “normale” Assoziation ist auch nur 1 Link zwischen 2 Objekten Es kann dann nicht 2 geben! ↔ 14 WEITERE BEMERKUNG: ↔  Objektdiagramme sind Schnappschüsse Situation vor Cäsars Tod: Einige Jahre nach Cäsars Tod: 15 WAS IST ZUSAMMENHANG ZW. ASSOZIATIONEN UND CODE? In Programmiersprachen (Java, …) gibt es keine direkte Ent- sprechung für das Konzept “Assoziation” → Wie umsetzen? – Möglichkeit A: ≙ ≙ Auch möglich aber unübersichtlich 16 WAS IST ZUSAMMENHANG ZW. ASSOZIATIONEN UND CODE? In Programmiersprachen (Java, …) gibt es keine direkte Entsprechung für das Konzept “Assoziation” → Wie Umsetzen? – Möglichkeit A: ≙ ≙ Auch möglich aber unübersichtlich! → Empfehlung: Primitive Datentypen (Zahl, Bool, String, Enum) → Attribut Sonst → Assoziation 17  Einführung AGGREGATION & KOMPOSITION IM KLASSEN- & OBJEKTDIAGRAMM  Betonung des Aspekts „besteht aus“: (v.a. in Analysediagrammen* nützlich) „besteht aus“, „enthält“ „besteht aus“, „enthält“ (Aggregation) (Komposition) Stärker als Klassendiagr.: Aggregation & Komposition sind Untertypen von Assoziation Objektdiagr.: Aggregation & Komposition sind Untertypen von Link * Diagramme, die im Zuge der Analysephase gemacht werden 18 → Siehe Fachmodell in Vorl. zur Anforderungsanalyse  Einführung VERBINDUNGEN (LINKS) – AGGREGATION & KOMPOSITION  UML definiert folgende Bedeutung für & Für beide sind keine zyklischen Abhängigkeiten erlaubt ist in folgendem Sinne stärker als : existienzielle Abhängigkeit zwischen Ganzes Teile Teil kann mit max. 1 Ganzem verbunden sein (0..1) Ganzes ist verantwortlich für Existenz und Speicherung der mit ihm verbundenen Teile → Wenn Ganzes gelöscht wird, dann erzwingt das auch das Löschen der verbundenen Teile Gerne Anlass für (unnötige) Diskussionen → TIPP: dann verwenden, wenn WIRKLICH notwendig 19 04 Vererbung Ziel: Wie kann Vererbung dargestellt werden? 20 VERERBUNG Notation Vererbung in UML: → Drückt aus: B erbt von A – (mind.) zwei Bedeutungen: extensional vs. intensional 21 VERERBUNG – AUSWIRKUNGEN AUF OBJEKTE & OBJEKTDIAGRAMM Mögliche Notation für B-Objekte: , (, ) Typ-Info wird unspezifischer Auch möglich: Vererbung ist in der Regel im Objektdiagramm nicht (direkt) sichtbar! Typregel: Die B-Objekte müssen auch die gleichen Eigenschaften Fähigkeiten wie die A-Objekte haben Mit anderen Worten: Jedes B-Objekt ist auch A-Objekt (ABER: Nicht jedes A-Objekt ist auch B-Objekt) 22 MEHRFACHVERERBUNG UML erlaubt echte Mehrfachvererbung (wie C++) – Damit UML auch kompatibel zu Sprachen wie C++ ist – Man sollte Mehrfachvererbung in Designsichten vermeiden, wenn die Sprache das nicht unterstützt Oder zumindest dann eine Beschreibung angeben, wie diese realsiert wird Stereotyp (Stereotype) «...» “Erben” von Interfaces: = Erweiterungsmechanismus der UML Hier: gleiches Modellelement (rechteckiger Kasten) wie für Klasse, aber „Kasten“ hat mit «interface» andere Bedeutung: Interface Implementierungspfeil / Realisierungspfeil ( ≙ ) falsch!! → richtig: ≙ 23 25 05 Attribute, Methoden, Sichtbarkeiten Ziel: Den inneren Aufbau von Klassen detaillierter spezifizieren 24  Einführung (MÖGLICHE) DARSTELLUNG FÜR BEIDE SICHTEN  Analog wie in Objektdiagramm dargestellt: Vgl. Objekt: Konkrete Eigenschaft (Attribut) → Besteht aus: i) Name der Eigenschaft (feature name) ii) optional: Art der Eigenschaft (z.B. :String) iii) optional: Initiale Belegung / Wert (Vorgabewert ≙ default value specification) 25  Einführung WEITERE BEMERKUNG ZUR DARSTELLUNG  Eine Klasse kann in der Regel* maximal drei Abschnitte (Compartments) haben:  (vgl. auch Objektdiagramm vorletzte Woche) Name Eigenschaften (Fähigkeiten) → Methoden/Operationen * Theoretisch gibt die UML keine Vorgaben über Reihenfolge und Anzahl außer, dass oben der Name stehen muss → beliebige Anzahl und Reihenfolge Praktisch werden nur diese 3 immer in dieser Reihenfolge genutzt 26 METHODEN Übliche Namen: Methoden, Operationen, Member Functions Notation: Attribute Rückgabe- Methoden parameter BEM: void ∈ UML void typ == hat zwei Bedeut. unbekannt BEM: Meth. v.a. bei Entwurfs-/Implementierungsdiagramm interessant 27 SICHTBARKEITEN Für Attribute und Methoden können die Sichtbarkeiten definiert werden: Sichtbarkeiten: + == public # == protected - == private ~ == package Empfehle ich natürlich nicht!! ;-) Ein unterstrichenes Attribut oder Methode bedeutet “static” 28 SICHTBARKEITEN Für Attribute und Methoden können die Sichtbarkeiten definiert werden: Sichtbarkeiten können auch weggelassen werden → Wird in Objektdiagrammen üblicherweise weggelassen → Kann in Analysemodellen / Fachmodell auch weggelassen werden – In der Regel nur im Entwurfs-/Implementierungsdiagramm und im Zusammenhang mit Methoden interessant BEM: Leider gibt es Werkzeuge, die Sichtbarkeiten immer anzeigen → Muss man dann einfach ignorieren 29 06 Zwei mögliche Bedeutungsarten Ziel: Verstehen lernen, dass das Klassendiagramm verschiedene Bedeutungsarten annehmen kann 31 GRUNDSÄTZLICH MÖGLICHE BEDEUTUNGSARTEN Auf der Bedeutungsebene (Semantik) kann man mit einem Klassendiagramm zwei Bedeutungsarten abbilden: I. Extensionale Bedeutungsart ≙ Mengenorientiert (Menge aller Objekte mit gleichen Eigenschaften) II. Intensionale Bedeutungsart ≙ Bauplanorientierte Bedeutung (Gleicher Aufbau) Hinweis: Beide Bedeutungsarten wurde von Aristoteles schon in der griech. Antike zur Definition von Begriffen eingeführt und unterschieden. S. z.B.: https://de.wikipedia.org/wiki/Extension_und_Intension 32 I. EXTENSIONALE BEDEUTUNGS- ART Extensional: Darstellung der Gemeinsamen Eigenschaften & Gemeinsamen Fähigkeiten = Gemeinsamkeiten einer Menge an Objekten → 1 Klasse ≙ Menge gleichartiger Objekte → Mengenorientierte Darstellung 33 I. EXTENSIONALE BEDART – BSP → SIEHE BEISPIEL VON OBEN! 1. Es gibt nur Paare, die mit 2 Personen verbunden sind 2. Eine Person kann höchstens mit einem Paar verbunden sein → Man kann nun einige Objektdiagramme zeichnen: … → Nur unvollständige Auflistung von richtigen & falschen Beispielen möglich 34 I. EXTENSIONALE BEDART – BSP → DAS KLASSENDIAGRAMM → Wir brauchen eine vollständige Darstellung der Sachverhalte → Klassendiagramm: 35 II. INTENSIONALE BEDEUTUNGS- ART Intensional: Darstellung des Bauplans für ein(e) Art/Sorte/Typ/Klasse von Objekten → 1 Klasse ≙ Bauplan für gleichartige Objekte → Bauplanorientierte Darstellung 36 II. INTENSIONALE BEDEUTUNGS- ART – BSP Quellcode stellt sicher, dass: Jedes Paar-Objekt genau mit 2 Person- Gegebenenfalls weiterer Code Objekten verbunden ist. Jedes Person-Objekt mit höchstens einem Paar-Objekt verbunden ist → Klassendiagramm: → Selbes Diagramm wie in I. !! Wie passt das jetzt zusammen? 37 EXT. & INT. BEDEUTUNGSART – WIE PASST DAS JETZT ZUSAMMEN?  UML legt nicht eindeutig fest welche Bedeutungsart ein Klassendiagramm hat  Die Bedeutungsarten können zusammenfallen  Müssen aber nicht  Man kann sich zu jedem KD fragen  Ist es Extensional oder Intensional gemeint?  Oder beides? (i.d.R. in Designphase notwendig)  Grundsätzliche Regel:  Ein Diagramm sagt mehr als 1000 Worte  Kann aber auch tausenderlei verschieden interpretiert werden → i.d.R. auch textuelle Beschreibung eines Diagramms nötig 38 VERERBUNG – I. EXTENSIONAL Bedeutungsart I. Extensional → Mengenorientiert: Notation A ist Oberklasse von B bedeutet: Vererbung Die Menge der B-Objekte ist eine in UML: Teilmenge der Menge der A-Objekte Schematisch: Menge der A-Objekte Menge der B-Objekte „gehören zusammen“ 39 VERERBUNG – II. INTENSIONAL Bedeutungsart II. Intensional → Bauplanorientiert A ist Oberklasse von B bedeutet: Der Bauplan für B-Objekte umfasst auch den Bauplan für A-Objekte Schematisch: ≙ → Nutzen von : Kurzschreibweise für die Wiederverwendung von Bauplänen 40  LETZTE WOCHE: FACHLICHE ↔ TECHNISCHE SICHT → Fachliche Sicht betrachtet alles ohne technische Details – Wird in der Analyse verwendet, um NUR die fachlichen Anforderungen zu ermitteln → Technische Sichten – In Architektur, Detailed Design, Implementierungsdoku verw. – Es werden auch die für die Lösung relevanten technischen Details dargestellt: Technische Lösung z.B. für spezifische Suche nach Städten oder Adressen 41  EXTENSIONALE & INTENSIONALE SICHTWEISE → Fachliche Sicht betrachtet alles ohne technische Details – Wird in der Analyse verwendet, um NUR die fachlichen Anforderungen zu ermitteln → Eigentlich immer Extensionale Bedeutungsart → Technische Sichten – Architektur (High-Level) – Detailed Design – Code / Diagramm mit exakter Darstellung des Codes → Beide Bedeutungsarten sollten spätestens beim Implementierungsnahen Diagramm zusammenfallen → Nicht Zusammenfallen deutet auf möglichen Designfehler oder Architekturerosion hin 42 Softwaretechnik 04a Zustandsautomaten (Zustandsdiagramme) 01 EINFÜHRUNG INS THEMA Ziel: Die Eckpunkte des Themas kennenlernen 3  ZUSTANDSDIAGRAMME Offizieller Name: State Machine (Zustandsautomat) Eignen sich zur Modellierung von Systemen/SW, die: – in Zuständen verharren – und diese meist durch ein Signal von außen wechseln Zustand: Unter Umständen verbleibt ein System sehr lange in einem besimmten “Modus” → Zustand Wechsel: Meist durch ein Signal von außen Es kann sehr lange dauern, bis ein Wechsel eintritt 4  ZUSTANDSDIAGRAMME Zustand: Unter Umständen verbleibt ein System sehr lange in einem besimmten “Modus” → Zustand Wechsel: Meist durch ein Signal von außen Es kann sehr lange dauern bis ein Wechsel eintritt Beispiele: – Getränkeautomat: Zustände: Wartend, Geld eingeworfen, Getränkewahl, Bereitstellung Getränk, Wartend – Automobilsteuergeräte: Zustände: Schlafen (23h am Tag) –(Tür öffnet sich)→ aufgewacht Zündschlüssel steckt, Motor gestartet, Motor aus, Zündschlüssel raus –(Tür zu)→ Schlafen 5  2. SEMESTER - PM: MÖGL. ZUSTÄNDE EINES THREADS 6 Nach [Jobst06; p.242]  ANDERE NAMEN FÜR ZUSTANDSDIAGRAMME State Machine, Zustandsautomat (endlich) State Diagram State Chart Mealy-Automat (Aktion im Übergang) Moore-Automat (Aktion im Zustand) → Weitere Details lernen Sie noch im Modul “Automatentheorie und Formale Sprachen” 7 02 Loslegen mit einem Beispiel Ziel: Erste Sachen kennenlernen 8 BSP: PERSONEN AUS SICHT DES STANDESAMTS Klassendiagramm: 9 BSP: PERSONEN AUS SICHT DES STANDESAMTS Zustandsdiagramm: 10 BSP: PERSONEN AUS SICHT DES STANDESAMTS Zustandsdiagramm – Nebenläufigkeit / Schachtelung : 11 03 Zustandsdiagramme - Modellelemente im Überblick Ziel: Die Elemente im Überblick erfassen 12 MODELLELEMENTE – ZUSTÄNDE “Normaler Zustand” (State): Pseudozustände (Pseudostate): End-Zustand (FinalState) – Start → Sonderfall, weil er beendet – Einfache Historie (merkt sich eine Ebene) – Tiefe Historie (merkt sich alle Zustände über gesamte Schachtelungstiefe) 13 MODELLELEMENTE – ZUSTÄNDE Möglicher innerer Aufbau von Zuständen: Internes Verhalten Innere Zustände (beliebige Schachtelungstiefe) 14 MODELLELEMENTE – ÜBERGÄNGE 15 MODELLELEMENTE – ÜBERGÄNGE Mehrere Ereignisse für einen Übergang: Spezielle Auslöser (Trigger): ≙ sobald Bedingung eintritt … ≙ nachdem Δt an Zeit vergangen ist … ≙ zu diesem Zeitpunkt … ≙ Erreichen des Endzust. 16  ZERLEGUNG IN UNTERDIAGRAMME Zustandsdiagramme können auch in mehrere zerlegt werden: 17 TIPPS ZUR MODELLIERUNG  Name eines Zustands == Adjektiv (oder Substantiv+Adjektiv – z.B.: LichtAn, LichtAus)  Erst grob, dann Details  Zustände sammeln  Nach auslösenden Ereignissen suchen  Iterativ verfeinern  Erst auf einer Ebene arbeiten → Später ggfs. schachteln 18 04 Weitere Anmerkungen Ziel: Weitere Sachen 19 WOFÜR EIGNEN SICH ZUSTANDSAUTOMATEN?  Analyse – Anforderungen des Kunden analysieren (Potentielle Zustände des Zielsystems) – Prozesse oder Systeme analysieren, in die das Zielsystem eingebettet sind  Design – Zustände des Zielsystems – Zustände einzelner Objekte – Lebenszyklus von Objekten – …  Implementierung → siehe Design 20 BEVORZUGTE EINSATZGEBIETE Asynchrone Vorgänge: – Auf eine kurze Aktion folgt eine lange Wartezeit Siehe später Analysephase Lebenszyklen über mehrere Use Cases hinweg Interaktive Systeme – Steuerung der Vorgänge über Ereignis (ereignisbasiert) – z.B. GUI: 1 Klick ≙ 1 Ereignis Verhalten hängt von Vorgeschichte/aktuellem Zustand ab – Z.B. Einfügen nicht möglich, wenn Liste schon voll Codegenerierung von zustandbasiertem Verhalten → Besonders geeignet für ereignisbasierte Systeme, da Zustandsdiagramme eine deterministische und vollständige Modellierung erlauben → Erlaubt dann eine ausgiebigere Analyse mit Simulation, … 21 ZUSTANDSAUTOMATEN ALS TABELLEN  Die in Zustandsautomaten enthaltene Information kann auch in Tabellenform spezifiziert werden (kein UML!) Ausgangszu Ereignis Bedingung Aktion Zielzustand stand ledig ledig Hochzeit verheiratet … 22  WIE ZUSTANDSAUTOMATEN IMPLEMENTIEREN? Verschiedene Ansätze zur Implementierung:  Zustandsattribut (z.B. Enum): 1. 1 Trigger ≙ 1 Methode 2. Switch – Case  Tabelle  Array: jede Zeile der Tabelle repräsentiert (Beliebt in C)  ggf. geeignete Programmier-Bibliothek verwenden (z.B. https://github.com/dotnet-state-machine/stateless)  Zustandsobjekte  Jeder Zustand ≙ 1 Objekt → Java: Enum, die Zustände repräsentiert + Methoden, die Verhalten in jeweiligen Zustand repräs. + Methoden, die in neuen Zustand wechseln 23 Softwaretechnik 04b Aktivitätsdiagramme  AKTIVITÄTSDIAGRAMME Eignen sich zur Modellierung von: – Aktionen und deren Ablauf / Zusammenhang Prozesse (Geschäftsprozesse und andere) Algorithmen → Darstellung komplizierter Abläufe mit Schleifen & Verzweigungen → Gleichmäßiges Fließen (im Gegensatz zu stockender Abarbeitung bei Zustandsdiagrammen) 4 02 Loslegen Ziel: Erste Sachen kennenlernen 5  VORSICHT: Aktivitätsdiagramme haben: (Fast) gleiche Syntax (gleiches Aussehen) wie Zustands- diagramme, aber komplementäre Semantik (Bedeutung) Modellelement Zustandsautomat Aktivitätsdiagramm Zustand Aktion (oft: nichts passiert direkt) Übergang (Aktion) Verbindet Aktionen (im „→ “ passiert nichts) 6 BEVORZUGTE EINSATZGEBIETE Ablauf / Prozesse / Algorithmen – Siehe Flussdiagramm Zusammenarbeit bei Nebenläufigkeit – Siehe Petri-Netze 7 03 Beispiel Ziel: Ein Beispiel 8 BEISPIEL Code einer Betragsfunktion: 9 BEISPIEL Betragsfunktion als Aktivitätsd.: → Grafische Darstellung eines Algorithmus 10 04 Aktivitätsdiagramme - Modellelemente im Überblick Ziel: Die Elemente im Überblick erfassen 11 DIE WESENTLICHEN ELEMENTE 12 START- & ENDE- SYMBOLE  Start: Start des Aktivitätsdiagramms (Initial Node)  Ende: Komplettes Ende des Aktivitätsdiagramms (Activity Final Node) Nur Ende des Pfads (Flow Final Node) 13 VERZWEIGUNGEN Einfache Verzweigungen (alternative Wege, keine Parallelität): Braucht auch n-fachen Verbindungsknoten n n … Für jede “öffnende Raute” (Verzweigungsknoten) muss es eine passende “schließende Raute” (Verbindungsknoten) geben → Ansonsten Verklemmung möglich (s. nächste Folie) → s.a. Token-Konzept (folgendes Kap.) OBACHT: Die “schließende Raute” kann auch vor der “öffnenden Raute” stehen (z.B. bei der Darstellung von Schleifen, s.u.). 14 WOZU VERBINDUNGSKNOTEN („SCHLIEẞENDE RAUTEN“)? UML Glasklar, Abbildung 13.75: Im linken Fall (Direktverbindung mit einer Aktion) kann mit der Aktion “Tanzen” erst begonnen werden, nachdem sowohl “Bedürfnis nachgehen” als auch “Essen & Trinken” durchlaufen wurden. Im rechten Fall genügt eine der beiden Vorgängeraktionen. 15 VERZWEIGUNGEN – WIE BEDING. FORMULIEREN? 1. Möglichkeit: Die Aktion vorher liefert die Bedingung: BSP (siehe vorher): Guards nicht vergessen!! 2. Möglichkeit: Spezifikation am Entscheidungsknoten über Guards (Wächter) BSP: → Eignet sich eher für einfache Bedingungen 16 VERZWEIGUNGEN – WIE BEDING. FORMULIEREN? 3. Möglichkeit: Spezifikation am Entscheidungsknoten über Kommentar mit -Stereotypen BSP: Guards nicht vergessen!! → Eignet sich eher für komplexere Bedingungen 17 WIE SCHLEIFEN MODELLIEREN? Schleifen können über Verzweigungskomponente modelliert werden: „schließende Raute“ vor der Verzweigung Verzweigung → Alternativ: Schleifenknoten verwenden – Siehe [UMLGlaskar; S. 317 ff]. 18 DIE PIN-NOTATION Pins zeigen Objektflüsse an:  Einzelne Objekte:  Objektmengen:  auch komplexere Situationen, z.B.: 19 NOTATION VON NEBENLÄUFIGKEIT Prozesse/Threads teilen (fork): Prozesse/Threads zusammenführen (join): Prozesse/Threads müssen immer auch wieder zusammengeführt werden, oder muss verwendet werden 20 WAS IST NEBENLÄUFIGKEIT? Nebenläufigkeit (Parallelität, Concurrency) → parallele, (scheinbar) gleichzeitige Abarbeitung von Aufgaben Einfaches Beispiel: Threads ABER: Nicht nur, sondern auch bei Geschäftsprozessen, Client-Server-Abläufe, Verteilte Systeme (SOA, RPCs), … 21 WAS IST NEBENLÄUFIGKEIT? Aufgabe: Das Bsp. modellieren 22 WAS IST NEBENLÄUFIGKEIT? Aufgabe: Das Bsp. modellieren 23 AKTIVITÄTSBEREICHE – („ACTIVITY PARTITIONS“) Inoffiziell: „Schwimmbahnen (Swimlanes)“ → Erlauben Mapping von Aktionen auf Systeme / Stakeholder: → Beispiel eines Geschäftsprozesses 24 WERFEN UND FANGEN VON AUSNAHMEN Mehrere Möglichkeiten der Darstellung: Kann direct aus einer Aktion/Aktivität kommen: Oder es wird ein Unterbrechungsbereich definiert: 25 WEITERE DARSTELLUNGS- MITTEL Signale: 26 05 Analyse von Nebenläufigkeit Ziel: Das formale Modell des Aktivitätsdiagramms erlaubt die Analyse von Nebenläufigkeit 27 DEF: KONTROLLKNOTEN Als Kontrollknoten werden alle Knoten genannt, die keine Aktionen oder Aktivitäten sind: – Verzweigung und Merge: – Start- und Endknoten: – Fork and Join: (Nebenläuftigkeit, z.B. Threads) 28  Einführung DAS TOKEN-KONZEPT  Das Token-Konzept bildet die Grundlage der Semantik von Aktivitätsdiagrammen  Das Token-Konzept eignet sich insbesondere, um Deadlocks (Verklemmungen) aufzudecken  Vgl. Petri-Netze IDEE:  Ein oder mehrere Token (Münzchips) zeigt / zeigen an in welchem Zustand sich die Verarbeitung gerade befindet.  Token laufen durch das Diagramm → Kontroll-/Datenfluss  Token wird erst weitergeleitet, wenn alle Kanten und Zielknoten bereit sind.  Token darf an Kontrollknoten nicht warten – Ausnahme Join-Knoten: → Synch: Warten bis alle Tokens da 29  Einführung DAS TOKEN-KONZEPT  Münzen zirkulieren (reines Gedankenkonstrukt):  Eine Aktion schaltet die Münze(n) nur weiter, wenn an allen Eingängen Münzen anliegen: Münze bleibt stecken → Münze geht weiter → Münze wird vervielfältigt → Münzen verschmelzen → 30 Softwaretechnik 05 Interaktionsdiagramme  INTERAKTIONSDIAGRAMME Zeigen die Interaktionen zwischen Objekten – Interaktion = Abfolge von Nachrichten, die zwischen Objekten ausgetauscht werden + zugehörige Aktionen Grundsätzlich gibt es 4 Interaktionsdiagramme in UML: – Sequenzdiagramm (wichtigste) Diese besprechen wir – Kommunikationsdiagramm im Detail – Interaktionsübersichtsdiagramm Metadiagramm, das die Zusammenhänge zw. verschied. Interaktionsdiagrammen zeigt – Timing Diagramm: Zeigt Nachrichtenaustausch und Zustandwechsel verschiedener Objekte zu bestimmten Zeitpunkten an. 4 BEVORZUGTE EINSATZGEBIETE Man hat mehrere Einheiten (Objekte), die Nachrichten austauschen Zeitliche Abfolge der Nachrichten soll dargestellt werden Snapshot-Charakter (ähnlich wie Objektdiagramme) 5 02 Sequenzdiagramme - Modellelemente im Überblick Ziel: Elemente im Überblick erfassen 6 CODE-BEISPIEL: 7 DER CODE ALS SEQUENZDIAGRAMM: 8 DIE ELEMENTE IM DETAIL: Objekt / Kommunikationspartner UML 1.x: unterstrichen: UML 2.x: nicht unterstr.: (für mich beides ok) t Lebenslinie (lifeline) Vgl. Objektdiagramm: 9  DIE ELEMENTE IM DETAIL: Create Message „Found Message“ Nachricht (message event) Kommunikations- Aktion Partner unbekannt (action Param. der execution „Lost Message“ Nachricht specification) Ausführung Rückgabe- Wird meistens (execution) Name der weggelassen wert Nachricht (return value) Blockierender Aufruf Antwort- (synchr. call) Nachricht (reply mess.) 10  GENERELL MÖGLICHE NACHRICHTENTYPEN: 1. Erzeugungsnachricht (Create Message): 2. Synchrone Nachricht (blockiert): – Sender wartet, bis Empfänger die Nachricht abgearbeitet hat – Gestrichelter Pfeil für Rücksprung zum Sender nötig! 3. Asynchrone Nachricht (blockiert nicht): – Sender wartet nicht auf Empfänger und arbeitet unmittelbar weiter → Sender und Empfänger befinden sich in unterschiedlichen Ausführungsprozessen – Kein gestrichelter Rückgabepfeil!! BEM: Ausnahmen (Exceptions) werden auch “nur” als normale Nachrichten behandelt. 11 Siehe auch [UMLglasklar; S. 430] DIE ELEMENTE IM DETAIL: Die Lebenslinie im Detail: Aktiver Bereich (execution) - Ausführungssequenz (kann auch geschachtelt werden) Opt: Ende der Lebenslinie (destruction occurrence specification) Tipp: Aktiven Bereich weglassen, wenn diese Information nicht gefordert/benötigt wird. -> nur gestrichelte Linie genügt meistens 12 LOST-FOUND MESSAGES VS SOG. GATES Lost-Found-Messages: Gates: Zeigt Name des SDs an Gates 13 BEM LOST-FOUND MESSAGES UND SOG. GATES → Gates sind Anknüpfungspunkte, die bei Referenzen aufgenommen werden: Zeigt Namen des SDs an Gates „ref“ zeigt an, dass anderes Diagramm referenziert wird 14 03 Sequenzdiagramme – 2 verschiedene Semantiken Ziel: Elemente im Überblick erfassen 15 ZWEI VERSCHIEDENE SEMANTIKEN Die wichtigsten Elemente des Sequenzdiagramms kennengelernt → Syntax Zwei gängige Arten der Interpretation von Nachrichten: – "Aufrufsemantik" Orientiert sich daran wie in Programmiersprachen Methoden aufgerufen werden → Sehr nah an Programmiersprachen – "Signalsemantik" Sagt nur allgemein aus, dass “Signale ausgetauscht” werden → Viel allgemeinere/unbestimmte Aussage 16  DIE "AUFRUF-SEMANTIK": Nachrichtentypen wie Aufruf/Rücksprung von Methoden: 1. Erzeugungsnachricht (Create Message): 2. Synchrone Nachricht (blockiert): 3. Asynchrone Nachricht (blockiert nicht): BEM: Exceptions werden auch “nur” als normale Nachrichten behandelt. → Alle Elemente möglich und Bedeutung wie vorher erklärt 17 Siehe [UMLglasklar; S. 430]  DIE "SIGNAL-SEMANTIK" Übermittlung von Signalen: Es wird nur abstrakt von Signalen gesprochen Mögliche Nachrichten: 1. Erzeugungsnachricht (Create Message): 2. Signale: → Signale sind als asynchron definiert  Deshalb wieder der Asynchronpfeil  -> ggf. unnötige Einschränkung auf asynchron Siehe [UMLglasklar; S. 430] 18  ZWEI VERSCHIEDENE SEMANTIKEN UML lässt diese (üblichen) Interpretationen zu, gibt diese aber nicht zwingend vor. → s. z.B. [UMLglasklar; S. 430]: “Im UML-Kommunikationsmodell bilden Nachrichten zwei Formen des Informationsaustausch ab:” 1. “Aufruf / Rücksprung einer Operation” (≙ Aufrufsemantik) 2. “Übermittlung von Signalen” (≙ Signalsemantik) “Der Aufruf einer Operation … Sie können sowohl synchrone als auch asynchrone Aufrufe modellieren. Hingegen ist die Übermittlung eines Signals immer asynchron …” Warum spreche ich jetzt von Aufruf- und Signalsemantik? → Für Anfänger griffiger, wenn man es unterscheiden kann → Wichtig, weil Sequenzdiagramme in verschiedenen Phasen etwas verschieden verwendet werden. → Siehe folgende Folie 19  WARUM BRAUCHEN WIR ZWEI SEMANTIKEN?  Die “Aufrufsemantik” ist sehr detailliert – Sehr nah an Programmiercode & Programmabläufen Viele Details wie z.B.: wer ruf wen wie genau auf, Rücksprünge müssen definiert sein, … → Schon sehr genaue Festlegungen → nur in Design & Implem.!  Bei der “Signalsemantik” sind die Signale eher unbestimmt → Eignet sich besonders, wenn man noch nicht, weiß ob es wirklich ein Aufruf oder etwas anderes ist → Eignet sich also gut in den frühen Phasen (Analyse oder früher Entwurf), wenn man noch nicht festlegen möchte, ob es ein synch. oder asynch. Aufruf (oder was auch immer...) ist → siehe dazu auch später Robustness Analysis 20 04 Kommunikationsdiagramme – Modellelemente im Überblick Ziel: Die Elemente im Überblick erfassen 21 VORHERIGES BEISPIEL ALS KOMMUNIKATIONSDIAGRAMM: 1: A() 2.1: B(42) 2.1.1: C(42) 2: f(42) 2.2: g(11) 2.2.1: g(11) 2.2.1.1.1.1: 2.2.1.1.1: g(11):53 2.2.1.1: g(11):53 BEM zu rot markiertem Bereich: Vorschlag für lost/found Messages (gibt es nicht in UML2.x bzw. ist dort nicht geklärt) 22 KOMMUNIKATIONSDIAGRAMM WEITERE BEMERKUNGEN 1: A() 2.1: B(42) 2.1.1: C(42) 2: f(42) 2.2: g(11) 2.2.1: g(11) 2.2.1.1.1.1: 2.2.1.1.1: g(11):53 2.2.1.1: g(11):53 Reihenfolge – ist nur anhand der Nummerierung ersichtlich – Punkt (.) -> eine Ebene tiefer in Aufrufhierarchie – Nebenläufigkeit mit Buchstaben auf gleicher Ebene, z.B.: 1.1a, 1.1b BEM zu Pfeilen: – UML 1.x: Gleiche Pfeile wie in Sequenz-Diagramm – UML 2.x: Nur (== Semantikverlust! ) 23 EIGENSCHAFTEN KOMMUNIKATIONSDIAGRAMME Im Prinzip:Kommunikationsdiagramm hat den gleichen Informationsgehalt wie Sequenzdiagramm ABER: Nicht alles kann dargestellt werden: – Fokus auf (Nachrichten-)Verbindungen zwischen den Kommunikationspartnern – Informationsverlust – Zusammenhänge zw. Nachrichten sind schwerer lesbar Stärke des Kommunikationsdiagramms: – Zwitter aus Struktur- und Interaktionsdiagramm → Objekte werden oft in selber Anordnung wie in Klassendiagramm angeordnet (== Struktursicht) → Nachrichten zeigen dann die Interaktionen → Z.B. gut bei Robustness Analysis (später)! 24 ENTSCHEIDUNGSHILFE Wann am besten welches Diagramm einsetzen? Zeitliche Abfolge wichtig → eher Sequenzdiagramm Auch Aktivitäten innerhalb der Objekte teilweise darstellbar Eher Struktur wichtig→ eher Kommunikationsdiagramm BEM: Sequenzdiagramm wird wesentlich häufiger verwendet – Finde ich auch meistens besser geeignet 25 05 Weitere Interaktionsdiagramme Ziel: Kurze Vorstellung der anderen Interaktionsdiagramme 26 INTERAKTIONSÜBERSICHT- DIAGRAMM... zeigt Zusammenhänge zwischen verschiedenen Interaktionsdiagrammen, z.B.: Quelle: UML 2.5-Notationsübersicht auf www.oose.de/uml 27 TIMING-DIAGRAMM (ZEITVERLAUFSDIAGRAMM) Zeigt Nachrichtenaustausch und Zustandswechsel verschiedener Objekte zu bestimmten Zeitpunkten an: Duration Constraint Lifeline (Objekte) Message Time Constraint Timing Ruler State or Event or Condition Stimulus Tick Mark Values Quelle: UML 2.5-Standard 28 Softwaretechnik 06a Test - Einführung TESTS VORBEREITEN UND DURCHFÜHREN Testvorbereitung Vorbereitung Systemtest Vorbereitung Integrationstest Vorbereitung Modultest Modultest schreiben Testdurchführung (Programmiermethoden) 4  UNTERSCHEIDUNG TESTEN ↔ DEBUGGEN Testen: Wie finde ich Fehler? Debuggen: Wie finde (und behebe) ich die Fehlerursache? 5 BEISPIELANWENDUNG: → Wie findet man jetzt hier die Fehler? 7  BEISPIELANWENDUNG – WIE DIE FEHLER FINDEN? Wie soll man beim Testen dieser Anwendung vorgehen? → Typische und sinnvolle Vorgehensweise: – Geeignete Werte eingeben – Vergleich mit erwarteten Ergebnissen ABER: Was sind die geeigneten Eingaben für den Test? 8  BEISPIELANWENDUNG – MIT WELCHEN WERTEN TESTEN? Mit welchen Eingabewerten testen? Schlechte Testansätze: – alle möglichen Werte Alle Werte testen: – nicht testen Eingabe: alle 64-bit-Fließkommazahlen – chaotisch/zufällig testen Anzahl der verschiedenen Eingaben: ≈ 264 ≈ 100,3 64 ≈ 1020 Annahme: 1 Mrd. Testfälle / s → 1020 s / 109=1011 s ≈ 3.000 Jahre 9  ANFORDERUNGEN AN GUTE TESTANSÄTZE Anforderungen an gute Testansätze: strukturiert wiederholbar sinnvolle (ökonomische) Auswahl der Testdaten: – möglichst wenige Testdaten – „möglichst gemein“ BEM: Bei sicherheitskritischen Anwendungen (z.B. Steuer- ung eines Atomkraftwerks) genügt ein Test mit ausgewählten Werten nicht → Test + Verifikation 10  WIE FINDET MAN DIE FEHLERURSACHE? ≠ erwartetes Ergebnis (korrekt: 1,41...) Wo könnte die Fehlerursache liegen? – GUI-Code – Wurzelfunktion – Verbindung zwischen GUI und Wurzelfunktion –... → Wie findet man die Fehlerursache möglichst schnell? 11  WIE FINDET MAN DIE FEHLER- URSACHE MÖGLICHST SCHNELL? → Am besten: Zur rechten Zeit an der richtigen Stelle suchen! – Klingt trivial, aber ist gar nicht so einfach → Mehrstufige Vorgehensweise beim Testen: 1. Jedes Modul (Klasse/Methode) unabhängig von den anderen testen 2. Zusammenarbeit von zwei (oder mehr) Klassen/Methoden testen 3. Gesamte Anwendung testen Integrationstest Systemtest Modultest 12 MEHRSTUFIGE VORGEHENSWEISE → TESTEBENEN Systemtest Integrationstest Modultest 13 03 Black-Box, White-Box, Grey-Box Ziel: Verschiedene Testansätze hinsichtlich der Sichtbarkeit kennenlernen 14  BLACK-BOX Merkmale von Black-Box-Tests: – Test aus Sicht des Verwenders/Anwenders → von außen – keine Sicht auf Implementierung/auf das Innere → undurchsichtige Hülle („black box“) – alleinige Grundlage: Spezifikation – keine Grundlage: Implementierung Einsatz: – Systemtest → immer Black Box!! – Aber auch möglich: Integrations- und Modultest 15  WHITE-BOX Merkmale von White-Box-Tests: – Test aus Sicht des Entwicklers → nach innen – Sicht auf Implementierung/auf das Innere → durchsichtige Hülle („white box“) – Grundlage: Spezifikation + Implementierung Einsatz: – Modultest Bei sicherheitskritischen Anw. → Pfad-/Anweisungsüberdeckung – Integrationstest 16  GREY-BOX Merkmale von Grey-Box-Tests: – Sicht auf Implementierung/auf das Innere manchmal möglich/nötig → leicht durchsichtige Hülle („grey box“) – Grundlage: Hauptsächlich Spezifikation – ABER: Manchmal benutzt man auch Implementierungswissen Einsatz: – Eher Modultest (wahrscheinlich meistens) – Wahrscheinlich auch meistens im Integrationstest 17  FINDEN VON TESTFÄLLEN Beliebte Ansätze zum Finden von Testfällen bei Blackbox (ohne Implementierungswissen): – Äquivalenzklassenbildung – Randwertanalyse – Zustandsbasierter Test – Ursache-Wirkungs-Analyse Beliebte Ansätze zum Finden von Testfällen bei Whitebox (mit Implementierungswissen): – Anweisungs-Überdeckung – Zweig-Überdeckung – Pfad-Überdeckung – Bedingungs-Überdeckung Das sind Ansätze (keine einfachen Lösungsformeln zum Einsetzen) 18 04 Tests auf verschiedenen Abstraktionsebenen Ziel: Verschiedene Ebenen des Tests kennenlernen 19  TESTS AUF VERSCHIEDENEN ABSTRAKTIONSEBENEN Vergleiche Es gibt Tests auf verschiedenen Abstraktionsebenen: V-Modell – Modultest: Jedes Modul für sich – Integrationstest: Verbindungen zwischen den Modulen – Systemtest: Das System als Ganzes – Abnahmetest: Abnahmetest des Kunden (oft Systemtest) 20 I. MODULTEST Merkmale: Jedes Modul für sich. White-Box-Test &&|| Black-Box-Test Test durch Programmierer Empfehlenswert: Test-Driven Development /Test First (erst Testfall entwickeln) 21 I. MODULTEST Werkzeuge: Empfohlen: JUnit (bzw. *Unit) Zusätzliche Module, die nur für den Test benötigt werden: – test stub z.B. im Modultest von B: Testklasse als Ersatz für C → Mocking (Siehe PMT-Folien zu Unittesting) – test driver z.B. im Modultest von B: Testklasse als Ersatz für A  häufig: test driver = *Unit-Klasse 22 II. INTEGRATIONSTEST Merkmale: Nach dem Modultest KEINE Wiederholung des Modultest! Fokus: Schnittstellen Meist: geeignete Mischung aus White-Box- und Black-Box- Tests beliebtes Testwerkzeug: JUnit (*Unit) 23  II. INTEGRATIONSTEST Sinnvolle Integrationsansätze: – bottom-up hier: erst B → C, dann A → (B+C) – top-down hier: erst A → (B+C), dann B → C i.d.R. test stubs notwendig – cluster große Modulanzahl → Gruppieren zu Clustern bottom-up oder top-down in jedem Cluster Zusammenfügen der Cluster: bottom-up oder top-down 24  II. INTEGRATIONSTEST Testansätze: 1. Lassen sich die zu integrierenden Module überhaupt „zusammenstecken“ (z.B. gemeinsam kompilieren)? 2. Quellen für Testfälle: für jede betroffene Schnittstelle (SST): – 1 Testfall für jede Art des Aufrufs – Bsp: SST mit mehreren Methoden → für jede Methode: » 1 Testfall für den Normalfall » 1 Testfall für jeden Ausnahme-/Fehlerfall Sicherstellen, dass die komplette Aufrufhierarchie abgedeckt wird → Jeder noch so tief verschachtelte Methodenaufruf muss mind. 1 Mal getestet werden. BEM: keine Wiederholung der Modultests – ABER: ggfs. Wiederverwendung von Bestandteilen der Modultests 25 III. SYSTEMTEST Merkmale: Test aus Benutzersicht → Grundlage: Anwendungsfälle, Fachmodell, GUI-Entwurf nicht-funktionale Anforderungen,... i.d.R. ausschließlich Black-Box-Tests 26 III. SYSTEMTEST Typische nichtfunktionale Tests auf der System-Ebene: Leistungstest (Volllastverhalten) Stresstest (Überlastverhalten) 27 IV. ABNAHMETEST (SONDERFALL) Merkmale:  Meist: Abnahmetest ≈ Systemtest, aber: Durchführung von/beim Kunden Bei mehreren Installationen: – Alpha-Test: Kunde kommt zum SW-Entwickler – Beta-Test: SW wird bei Pilotkunden getestet 28  Softwaretechnik 06b Test – Überdeckungsansätze Informatik Hochschule RheinMain Überblick White-Box-Ansätze = Überdeckungsansätze Anweisungsüberdeckung: alle Anweisungen Zweigüberdeckung: alle Zweige (if, else,... ) Pfadüberdeckung: alle Pfade Bedingungsüberdeckung: alle Belegungen von Bedingungen Im folgenden werden diese Ansätze anhanden von Beispielen erläutert. Dabei ist zu unterscheiden zwischen: 1 Bedingung für den Testfall: wird durch Analyse des Quellcodes gefunden 2 erwartetes Ergebnis: wird durch Anwendung der Bedingung auf die Spezifikation ermittelt Beispiel: Anweisungsüberdeckung IntMenge.einfuegen: Implementierung 1 public void einfuegen(int x) { 2 if (!istEnthalten(x)) { 3 elems.add(new Integer(x)); 4 } 5 } Testfälle bei Anweisungsüberdeckung 1 istEnthalten(x)==false: Anweisungen 2, 3 werden ausgeführt → mit diesem einen Testfall: alle Anweisungen „überdeckt“ Beispiel: Anweisungsüberdeckung IntMenge.einfuegen: Spezifikation 1... 2 6 public void einfuegen(int x) {...} 7... Testfälle bei Anweisungsüberdeckung + erwartete Ergebnisse 1 istEnthalten(x)==false bedeutet aus Sicht der Spezifikation: x ist in Menge nicht enthalten → erwartetes Ergebnis: x wird hinzugefügt Beispiel: Zweigüberdeckung IntMenge.einfuegen: Implementierung 1 public void einfuegen(int x) { 2 if (!istEnthalten(x)) { 3 elems.add(new Integer(x)); 4 } 5 } Testfälle bei Zweigüberdeckung 1 istEnthalten(x)==false: if-Zweig 2 istEnthalten(x)==true: else-Zweig → mit diesen zwei Testfällen: alle Zweige „überdeckt“ Beispiel: Zweigüberdeckung IntMenge.einfuegen: Spezifikation 1... 2 6 public void einfuegen(int x) {...} 7... Testfälle bei Zweigüberdeckung + erwartete Ergebnisse 1 istEnthalten(x)==false bedeutet aus Sicht der Spezifikation: x ist in Menge nicht enthalten → erwartetes Ergebnis: x wird hinzugefügt 2 istEnthalten(x)==true bedeutet aus Sicht der Spezifikation: x ist in Menge enthalten → erwartetes Ergebnis: keine Veränderung Vergleich der Überdeckungsansätze Aktivitätsdiagramm Unterschiede am deutlichsten beim Betrachten der Wege in [xeI (bI > str.length()) Legende: Was ist mit bI> str.length()? → Anscheinend durch eI > str.length() bI – beginIndex, eI – endIndex, abgedeckt! str – Stringinhalt → Zur Not mit aufnehmen! 17  AK- UND RW-ANALYSE VON ENDINDEX (EI) ID Art Beschreib. der Bedingung Beispielhafte (AK / Äquivalenz- („logischer Werte („konkrete RW) klasse Testfall“) Testfälle“) AK3_1 AK eI kleiner bI eI < bI eI = bI - X eI=bI -1, ei = bI, eI RW3_1 RW eI gleich bI eI = bI = bI+1 eI ist im gültigen bI ≤ eI ≤ AK3_2 AK bI=4, eI=8 Bereich str.length() eI=str.length()-1, eI eI gleich RW3_2 RW eI = str.length() = str.length, str.length() ei= str.length +1 AK3_3 AK eI > str.length eI> str.length() eI=str.length() + X Legende: bI – beginIndex, eI – endIndex, str – Stringinhalt 18 KOMBINIEREN: StringInhalt: beginIndex: endIndex: ID … ID … ID … AK1_1 … AK2_1.. AK3_1.. RW1_1 … RW2_1 … RW3_1 … AK2_2 … AK3_2 … RW2_2 … RW3_2 … AK2_3 … AK3_3 … Menge aller möglichen Kombinationen: {(AK1_1, AK2_1, AK3_1), (AK1_1, AK2_1, RW3_1),...,...} → Kombinatorische Explosion → ungeschickt → Wir müssen die sinnvollen Kombinationen reduzieren! 19  WIE DIE ANZAHL DER SINNV. KOMBINATIONEN REDUZIEREN? → Beziehungen zwischen den Testfällen analysieren und daraufhin die wichtigen Kombinationen aussieben! – Aber wie? → Durch Ursache-Wirkungs-Analyse (in vereinfachter Form): – Aufteilung der Testfälle in zwei Kategorien: Normal („gut“) → Gutfälle Ausnahme/Fehler → Schlechtfälle – (Angenommene) Beziehungen: Fehler in guten Testfällen heben sich nicht gegenseitig auf → gute Testfälle können gemeinsam getestet werden Fehler in Ausnahme-/Fehler-Testfällen können sich überdecken. → Ausnahme-/Fehler-Fälle dürfen nicht gemischt werden 20  KOMBINATION – EINTEILUNG IN GUT- UND SCHLECHTFÄLLE: StringInhalt: beginIndex: endIndex: ID Log. Testfall … ID Log. … ID Log. … AK1 String mit Testf. Testfall … _1 Länge > 0 AK2_1 bI < 0.. AK3_1 eI < bI.. RW String mit RW2_1 bI = 0 … RW3_1 eI = bI … … 1_1 Länge = 0 0 ≤ bI ≤ bI ≤ eI ≤ AK2_2 … AK3_2 … eI str.length RW2_2 bI = eI … eI = RW3_2 … AK2_3 bI>eI … str.length eI> AK3_3 … str.length Hirn einschalten: → Folgende Kriterien sind zueinander gleich (redundant): RW2_2 ↔ RW3_1, AK2_3 ↔ AK3_1 normal → Können wir in einer der Tabellen streichen Ausnahme/ BEM: Passiert, wenn Parameter nicht völlig unabhängig voneinander Fehler 21  KOMBINATION – EINTEILUNG IN GUT- UND SCHLECHTFÄLLE StringInhalt: beginIndex: endIndex: ID Log. Testfall … ID Log. … ID Log. … AK1 String mit Testf. Testfall … _1 Länge > 0 AK2_1 bI < 0.. bI ≤ eI ≤ AK3_2 … RW String mit str.length … RW2_1 bI = 0 … 1_1 Länge = 0 eI = 0 ≤ bI ≤ RW3_2 … AK2_2 … str.length eI eI> RW2_2 bI = eI … AK3_3 … str.length AK2_3 bI>eI … → Jetzt kombinieren 22 KOMBINATION GUT- UND SCHLECHTFÄLLE: String beginIndex endIndex inhalt AK1_1 AK2_1 AK3_2 Ist redundant zu einer Zeile weiter oben (gleicher AK1_1 AK2_1 RW3_2 Schlechtfall) AK1_1 AK2_1 AK3_3 Schlecht, weil sich 2 AK1_1 RW2_1 AK3_2 Schlechtfälle überlagern AK1_1 RW2_1 RW3_2 Ist hier nicht AK1_1 und AK1_1 RW2_1 AK3_3 RW2_1 redundant? … … … Hui, das werden ganz schön viele → Kombinatorische Explosion → Besser: Aussieben!! 23  KOMBINATION GUT- UND SCHLECHTFÄLLE: → (vereinfachte) Ursache-Wirkungs-Analyse nutzen: – Allgemeine Kombinationsregeln (Kochrezept): 1. Gutfälle: 1.1: Jeder Gutfall muss mindestens ein Mal in einer Kombi- nation, in der nur Gutfälle vorkommen, getestet werden 2. Schlechtfälle: 2.1: Jeder Schlechtfall darf nur mit Gutfällen kombiniert werden 2.2: Jeder Schlechtfall muss mind. einmal vorkommen 24  KOMBINATION GUT- UND SCHLECHTFÄLLE: String beginIndex endIndex inhalt AK1_1 RW2_1 AK3_2 Alle Gutfälle schon R1.1 AK1_1 AK2_2 RW3_2 abgedeckt RW1_ RW2_2 RW3_2 1 R2.1 AK1_1 AK2_1 AK3_2 & Alle Schlechtfälle R2.2 AK1_1 AK2_3 RW3_2 schon abgedeckt AK1_1 RW2_1 AK3_3 → Schon fertig! → Lineares Wachstum statt Kombinatorischer Explosion! 25 TESTVEKTOREN & WEITERE HINWEISE String beginIndex endIndex inhalt AK1_1 RW2_1 AK3_2 AK1_1 AK2_2 RW3_2 RW1_ RW2_2 RW3_2 Minimale Menge der 1 Testvektoren AK1_1 AK2_1 AK3_2 für sauberen Test AK1_1 AK2_3 RW3_2 AK1_1 RW2_1 AK3_3 Testvektor Weiterer Hinweise: Diese Parameterkombinationen beim Testen werden oft als Testvektoren bezeichnet → Wie man sieht, funktioniert die hier vorgestellte Vorgehensweise sowohl für Systemtest (z.B. GUI-Eingabe) als auch Modultest, … 26  VON LOG. TESTF. ZU KONKRETEN TESTF. Bisher haben wir nur die log. Testfälle betrachtet. → Bei konkreten Testfällen für Randwerte gibt es aber mehrere Werte: ID Art Beschreib. der Bedingung BSP-Werte (AK / RW) Äquivalenz-klasse („logischer („konkrete Testfall“) Testfälle“) AK2_1 AK bI kleiner 0 bI < 0 bI=-10 RW2_1 RW bI gleich 0 bI = 0 -1, 0, 1 bI im gültigen AK2_2 AK 0 ≤ bI ≤ eI bI=4, eI=8 Bereich … Manche davon sind auch noch Gut- und manche Schlechtfälle → Wie geht man damit um? 27  VON LOG. TESTF. ZU KONKRETEN TESTF. → Zwei Möglichkeiten: 1. Man verteilt die Werte auf die angrenzenden AKs: AK2_1: bI= -1 RW2_1: bI= 0 AK2_2: bI= 1 Möglicher Nachteil: AKs werden nur an den Rändern getestet → Vielleicht geht aber etwas in der Mitte schief? 28  VON LOG. TESTF. ZU KONKRETEN TESTF. → Zwei Möglichkeiten (empfohlen): 2. Man erweitert den Test dann um die spez. Randwerttests: String beginIndex endIndex inhalt AK1_1 RW2_1 (-1) AK3_2 AK1_1 RW2_1 (0) AK3_2 AK1_1 RW2_1 (1) AK3_2 … 29 04 Zustandsbasierte Tests Ziel: Wie testet man Software, die zustandsabhängig ist? Zustandsabhängig ≙ die SW verhält sich je nach Zustand evtl. anders 30  ZUSTANDSBASIERTES TESTEN – MP3-PLAYER BEISPIEL Beschreibung „Playlist anlegen“: … Eine neu angelegte Playlist ist leer … Beschreibung „Titel hinzufüg.“: … … insgesamt höchstens 255 Titel in der Playlist hinzugefügt werden … Beschreibung „Titel löschen“: … Vorbeding.: Mindestens ein Titel in Playlist vorhanden. … → In den einzelnen Anwendungsfällen werden implizit Zustände und Zustandswechsel der Playlist beschrieben → Beim Testen berücksichtigen! → Zustandsbasiertes Testen 31  ZUSTANDSBASIERTES TESTEN Vorraussetzungen: Spezifikation der Zustände und Zustands- übergänge → z.B. Zustandsdiagramm Vorgehen: Zustandsdiagramm → Testfälle ableiten – jeder Übergang → 1 Testfall – jeder „Nicht-Übergang“→ 1 Testfall (z.B. „löschen“ im Zustand im „leer“) BSP: Zustandsdiagramm für Playlist: 32 ZUSTANDSBASIERTES TESTEN – TESTFÄLLE AUS BEISPIEL Testfall Zustand nachher/ Id Zustand vorher Ereignis erwartetes Ergebnis ZT01 – Playlist anlegen leere Playlist ZT02 leer Titel hinzufügen Playlist mit 1 Titel ZT03 leer Titel löschen leer + Fehlermeldung? ZT04 nichtleer, 1 Titel Titel hinzufügen Playlist mit 2 Titeln............ 33 ZUSTANDSBASIERTES TESTEN – TESTFÄLLE AUS BEISPIEL TIP: Mit Zustand-Ids geht‘s leichter Z1: Z3: Z2: Testfall Zustand nachher/ Id Zustand vorher Ereignis erwartetes Ergebnis ZT01 – Playlist anlegen Z1 (leere Playlist) ZT02 Z1 Titel hinzufügen Z2 (Playlist mit 1 Titel) ZT03 Z1 Titel löschen Z1+ Fehlermeldung? ZT04 Z2 (1 Titel) Titel hinzufügen Z2 (Playlist mit 2 Titeln)............ 34 ZUSTANDSBASIERTES TESTEN – TESTFÄLLE AUS BEISPIEL TIP: Mit Zustand-Ids geht‘s leichter Z1: Z3: Z2: Testfall Zustand nachher/ Id Zustand vorher Ereignis erwartetes Ergebnis ZT01 – Playlist anlegen Z1 (leere Playlist) ZT02 Z1 Titel hinzufügen Z2 (Playlist mit 1 Titel) ZT03 Z1 Titel löschen Z1+ Fehlermeldung? ZT04 Z2 (1 Titel) Titel hinzufügen Z2 (Playlist mit 2 Titeln)............ 35  WEITERE ALLGEMEINE HINWEISE ZU ZUSTANDSBASIERTEN TESTS Basis für Testfälle: – Üblich: alle Übergänge – Besser: alle Ereignisse, d.h. auch: Fehlerfälle zu ignorierende Ereignisse Herstellen der Testsituation: – Testsituation kann i.d.R. nicht in 1 Schritt hergestellt werden – i.d.R. mehrere Schritte zur Vorbereitung Ausnahme: Startzustand → Zusammenfassen von Testfällen bei der Testdurchführung: – Auf dem Weg zu einer best. Testsituat. → kann man andere Testfälle „nebenbei“ machen → Zustandsautom. kann durch geschicktes Komb. und Aufbauen der Testfälle durchlaufen werden → effizienter Test – ABER: Scheitert ein Testfall, sind andere auch betroffen! 36 ZUSTANDSBASIERTE TESTS MIT ANDEREN TESTS KOMBINIEREN Zustands- basierte Testfälle Wie jetzt Titel in Playlist: kombinieren? Äquivalenzklassen & Randwertanalyse 37  WIE ZUSTANDSBASIERTE UND ANDERE TESTS KOMBINIEREN? → Wie vorher 1. Gut- und Schlechtfälle bestimmen: Zustände Playlist: Titelname für Titel in Playlist: Testfall Id Beschreibung... Id … Zustand vorher Ereignis ungültige Zeichen in AK1... ZT01 – Playlist anlegen … Name ZT02 Z1 Titel hinzufügen … AK2 Name zu lang... ZT03 Z1 Titel löschen … RW1 maximale Länge... ZT04 Z2, (1 Titel) Titel hinzufügen … Name hat gültige AK3... Länge............ ZT08 Z3 Titel hinzufügen RW2 minimale Länge... … … … … AK4 Name zu kurz... 38  KOMBINIEREN 2. Sinnvoll kombinieren: Zustandsb. Testfälle Äquiv. & Randwerte ZT01 - ZT02 AK1 Nur sinnvoll im Zustand Z1 & Z2 ZT02 AK2 mit Gutfällen ZT02 RW1 → Hirn einschalten! ZT03 - ZT04 AK4 ZT04 RW2 ZT04 AK3 (Hier wird ZT08 AK3 nur aufgefüllt) 39 Softwaretechnik 08 Anforderungsanalyse  Agenda AGENDA Einführung ins Thema Unser OO-Vorgehensmodell Überblick über die Anforderungsanalyse Das Fachmodell Anwendungsfälle Weitere Aspekte der Anforderungsanalyse Fazit 01 EINFÜHRUNG INS THEMA Ziel: Die Eckpunkte des Themas kennenlernen 3  WORUM GEHT‘S? Programmieren im Kleinen: – kleines Programm (≈ 1 - 20 Klassen) – 1 oder 2 Entwickler – Schlankes Vorgehen möglich: (Entwurf, Spezifikation,) Implementierung und Test – ordentlich (fehlerfrei, wartbar,... ) → Kann man auch ohne Prozess oder mit unstrukturiertem Prozess noch einigermaßen gut hinbekommen 4  WORUM GEHT‘S? Programmieren im Großen: – Software-System, z.B.: großes Programm (100 Klassen oder mehr) mehrere Programme als Gesamtsystem – viele Entwickler – echter Kunde(n) → Viele Beteiligte (Stakeholder) – vollständiger Softwareentwicklungsprozess – ordentlich (fehlerfrei, wartbar,... ) → Man braucht einen gescheiten Softwareentwicklungsprozess – Muss Menschen und Artefakte koordinieren → Man braucht Projektmanagement, Anforderungen, Design, Implementierung, Testen, … 5 LEBENSZYKLUS VON SOFTWARE Die typischen Tätigkeiten bei der SW-Entwicklung: heute im Fokus 6 LEBENSZYKLUS VON SOFTWARE (SOFTWARE-LIFE-CYCLE) Typische Tätigkeiten bei der Software-Entwicklung: 1. Analyse: Was will der Kunde? (= Anforderungen) heute im Fokus 2. Entwurf: Wie soll das zu bauende System sein? 1. grob: Grobentwurf (Architektur/Architecture) 2. detailliert: Feinentwurf (Detailed Design) 3. Implementierung: Entwurf → Programm 4. Test: Erfüllt das Programm die Anforderungen und den Entwurf? 5. Betrieb: Verwendung des Programms 6. Wartung und Pflege – Änderungswünsche/Fehler → Was will der Kunde? →... 7 MEHR VORGABEN SIND NÖTIG  Typische Fragen bei der Software-Entwicklung: – Wie fangen wir an? – Was sollen wir tun? – Wie verteilen wir die Aufgaben? – Wie machen wir’s richtig? –... → Hier sind mehr Vorgaben nötig 8 02 Unser OO-Vorgehensmodell Ziel: Unser OO-Vorgehensmodell kennenlernen 9 MEHR VORGABEN SIND NÖTIG → Vorgehensmodelle = Bestimmte