Last active
August 1, 2017 13:06
-
-
Save mhuisi/16bc5eb11d6c140d1ad74e119a09eb60 to your computer and use it in GitHub Desktop.
Überblick Softwaretechnik I (KIT)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Versionskontrolle: | |
| - Produkt: Ergebnis eines Herstellungsprozesses | |
| - Produktlinie: Menge verwandter Produkte | |
| - Software-Element: | |
| - Bestandteil von Produkt/Produktlinie | |
| - Eindeutig identifiziertbar durch systemweiten Bezeichner | |
| - Änderung am Software-Element resultiert in Bezeichner-Änderung | |
| - Arten: | |
| - Quellelement: Manuell generiert | |
| - Abgeleitetes Element: Automatisch generiert | |
| - Werkzeuge | |
| - Version: Stand eines Software-Elements zu einem Zeitpunkt | |
| - Revision: Zeitlich angeordnete Version | |
| - Variante: Angepasste Version | |
| - Softwarekonfiguration: | |
| - Menge von semantisch zusammenhängenden Software-Elementen mit Versionsangaben | |
| - Eindeutig benannt | |
| - Softwarekonfigurationsverwaltung: | |
| - Verfolgung und Steuerung der Evolution von Software | |
| - Identifizierung, Lenkung und Rückverfolgung von Versionen von Software-Elementen | |
| - Ausbuchen: | |
| - Depotkopie installieren | |
| - Strikes Ausbuchen: | |
| - Nur Ausbucher kann nächste Revision ablegen | |
| - Vorteil: Keine Konflikte beim Mergen | |
| - Nachteil: Nur ein einziger Ausbucher | |
| - Einbuchen: Schreibt Kopie in Depot | |
| - Schnappschuss: Zustand von Depot zu bestimmten Zeitpunkt | |
| - Commit: Metadaten zu Schnappschuss | |
| - Verwaltungen von Versionen: | |
| - Vollständiges Abspeichern | |
| - Deltas: | |
| - Vorwärts-Deltas: | |
| - Grundversion und Änderungen bis in Gegenwart | |
| - Vorteil: Schneller Zugriff auf frühere Version | |
| - Nachteil: Langsamer Zugriff auf aktuelle Version | |
| - Rückwärts-Deltas: | |
| - Aktuelle Version und Änderungen bis in Vergangenheit | |
| - Vorteil: Schneller Zugriff auf aktuelle Version | |
| - Nachteil: Langsamer Zugriff auf frühere Version | |
| - Da Zugriff auf aktuelle Version häufiger ist, werden Rückwärts-Deltas vorgezogen | |
| - Entwicklungslinien und Schnappschüsse: | |
| - Anordnung nach Versionen, nicht Dateien | |
| - Unterschied: | |
| - Deltas: Datei hat Delta zu Version | |
| - Entwicklungslinien: Version hat Entwicklungslinie aus Schnappschüssen | |
| - Versionskontrollsysteme: | |
| - RCS: Verwaltet lokale Versionshistorie für Datei | |
| - CVS: Netzwerkfähiges RCS mit Verzeichnisversionierung | |
| - SVN: CVS mit richtigem Projektdepot, atomaren Änderungen und optimistischem Ausbuchen | |
| - Git: | |
| - Versionierung von Objekten: Dateien, Dateiinhalte, Verzeichnisse, Konfigurationen, Varianten | |
| - Kryptografische Historiesicherung | |
| - Verteilte Depots | |
| - Entwicklungslinien und Schnappschüsse | |
| - Commit hat Zeiger auf Parent | |
| - Mehrere Entwicklungslinien durch mehrere Entwicklungslinienzeiger über Commits möglich | |
| - HEAD-Zeiger markiert aktuellen Arbeitsstand | |
| Automatisierung mit Maven: | |
| - Entwicklungsprozess: | |
| - Übersetzen | |
| - Abhängigkeiten verwalten | |
| - Testen | |
| - Verpacken, installieren, veröffentlichen | |
| - Dokumentation erzeugen | |
| - Berichte erstellen | |
| - Maven: | |
| - Automatisiert Entwicklungsprozess | |
| - Archetype: Projektvorlage | |
| - ArtifactID: Name des Artifakts | |
| - GroupID: Package | |
| - Plugin: Teilfunktionalität von Maven | |
| - Goal: Teilausgabe von Maven | |
| - pom.xml: Maven-Konfiguration für Projekt | |
| Übersicht: | |
| - Softwaretechnik (vereinfacht): Lehre der Softwarekonstruktion | |
| - Systematische Entwicklung | |
| - Systematische Pflege | |
| - Behandelt: Anforderungsermittlung, Spezifikation, Entwurf, Pflege, Tests, Prozessmanagement, ... | |
| - Software: | |
| - Programme, Daten und Dokumentation, die für Betrieb von Rechensystemen genutzt werden können | |
| - Keine reinen Daten (Binärdateien) | |
| - Immateriell, verschleißfrei | |
| - Nicht leichter zu ändern als physisches Produkt | |
| - Altert | |
| - Änderungen der letzten Dekaden: Wachsende Relevanz, Komplexität, Vernetzung, Qualitätsanforderung, Altlasten, Outsourcing | |
| - System: | |
| - Ausschnitt aus realer oder gedanklicher Welt | |
| - Besteht aus Komponenten, welche in Beziehungen stehen | |
| - Systemelemente: Nicht weiter zerlegbare Komponenten | |
| - Kommuniziert über Schnittstelle | |
| - Systemsoftware: Software für spezifische Hardware | |
| - Anwendungssoftware: Software für beliebige Hardware | |
| - Computersystem: Anwendungssoftware, Systemsoftware und Hardware | |
| - Systementwicklung: Entwicklung von System aus Hardware und Software | |
| - Softwaretechnik ausführlich: | |
| - Softwaretechnik (engl. software engineering) ist die technologische und organisatorische Disziplin zur systematischen Entwicklung und Pflege von Softwaresystemen, die spezifizierte funktionale und nicht-funktionale Attribute erfüllen. | |
| - Organisatorische Aspekte: | |
| - Planung | |
| - Personalfindung | |
| - Arbeitsorganisation | |
| - Leitung | |
| - Kontrolle | |
| - Systematisch: Konkretes, nicht zufälliges Vorgehen | |
| - Funktionale Attribute: Funktionen der Software | |
| - Nicht-funktionale Attribute: Qualität der Funktionen der Software | |
| - Softwareforschung: Bereitstellung und Bewertung von Methoden, Verfahren und Werkzeugen für die Softwaretechnik | |
| - Methoden: Systematische Vorgehensweisen | |
| - Verfahren: Ausführbahre Vorschriften zum Einsatz von Methoden | |
| - Werkzeuge: Automatisierte Unterstützung von Methoden | |
| - Aufbau Wasserfallmodell: Planung, Definition, Entwurf, Implementierung, Test, Abnahme & Wartung | |
| Planungsphase: | |
| - Ziel: | |
| - Lastenheft: | |
| - Beschreibung des Systems in Worten des Kunden | |
| - Funktionales Modell (d.h. Szenarios und Anwendungsfalldiagramme) | |
| - Durchfürbarkeitsanalyse | |
| - Anforderung: Bedingung oder Feature das vom System erfüllt werden muss | |
| - Techniken zur Ermittlung von Hauptanforderungen: Fragebögen, Interviews, Aufgaben-Analyse, Szenarios, Anwendungsfälle | |
| - Szenario: | |
| - Konkrete Beschreibung eines Ereignisses aus Sicht des Nutzers | |
| - Nutzung: Entwurfsphase, Testphase, Auslieferung | |
| - Szenario-basierte Anforderungsermittlung: | |
| - Entwicklung von Szenarien zu gegebenen Anforderungen | |
| - Verbesserung der Anforderungen mit konkreten Szenarios für den Kunden | |
| - Wichtige Informationen vom Kunden: | |
| - Hauptaufgaben | |
| - Vom Nutzer verwendete Daten | |
| - UML-Anwendungsfalldiagramme: | |
| - Darstellung des Verhaltens des Systems | |
| - Bildbeschreibung: Auf Folien (Kapitel 1) | |
| - Textbeschreibung: Name, Teilnehmende Akteure, Eingangsbedingungen, Ausgangsbedingungen, Ereignisfluss, Spezielle Anforderungen | |
| - Unterschied Anforderungsspezifikation und Analysemodell: Anforderungsspezifikation ist natürlich formuliert, Analysemodell formell | |
| - Anforderungsarten: | |
| - Funktional: | |
| - Interaktion des Systems | |
| - Formuliert als Aktionen | |
| - Nichtfunktional: | |
| - Formuliert als Zusicherungen | |
| - Arten: | |
| - Qualitativ: | |
| - Restliches Verhalten des Systems, das nichts mit Interaktionen zu tun hat | |
| - Möglichkeiten: | |
| - Benutzbarkeit: Messbare Leichtigkeit der Verwendung des Systems | |
| - Zuverlässigkeit: | |
| - Robustheit: Fehlertoleranz bei falschen Eingaben und schlechten Betriebsbedingungen | |
| - Sicherheit | |
| - Geschwindigkeit: | |
| - Antwortzeit | |
| - Skalierbarkeit | |
| - Durchsatz | |
| - Verfügbarkeit: Verhältnis störungsfreier Betriebszeit zu Gesamtzeit | |
| - Wartbarkeit: | |
| - Anpassbarkeit | |
| - Erweiterbarkeit | |
| - Einschränkungen: Restliche Anforderungen, die nichts mit dem Verhalten zu tun haben | |
| - Validierung von Anforderungen: | |
| - Nach Planungsphase oder Definitionsphase | |
| - Überprüfen auf: | |
| - Korrektheit bezüglich der Sicht des Kunden | |
| - Vollständigkeit | |
| - Konsistenz | |
| - Eindeutigkeit | |
| - Realisierbarkeit | |
| - Verfolgbarkeit | |
| - Problem: Änderungen | |
| - Arten der Anforderungsermittlung: | |
| - Entwicklung von null, Anforderungen erzeugt durch Wünsche des Kunden | |
| - Re-Engineering: Neuentwurf eines existierenden Systems, Übernahme der alten Anforderungen | |
| - Schnittstellen-Entwicklung: Verwendung des Systems in neuer Umgebung, Übernahme und Aktualisierung der alten Anforderungen | |
| - Lastenheft: | |
| - Gliederung: | |
| - Zielbestimmung: Ziel des Systems | |
| - Produkteinsatz: Ziel des Systems, Zielgruppe, Plattform | |
| - Funktionale Anforderungen: Wie oben, Darstellung durch ID /FAX0/ und Beschreibung | |
| - Produktdaten: Persistente Daten des Systems, Darstellung durch ID /PDX0/ und Beschreibung | |
| - Nichtfunktionale Anforderungen: Wie oben, Darstellung durch ID /NFX0/ und Beschreibung | |
| - Systemmodelle: | |
| - Szenarien: Wie oben | |
| - Anwendungsfälle: UML-Diagramm und textuelle Darstellung wie oben | |
| - Durchführbarkeitsuntersuchung: | |
| - Fachliche (technische) Durchführbarkeit | |
| - Alternative Lösungsvorschläge | |
| - Personellen Durchführbarkeit | |
| - Risiken | |
| - Ökonomische Durchführbarkeit | |
| - Rechtliche Gesichtspunkte | |
| - Glossar: Begriffe, welche nicht Wort des Kunden sind | |
| - Aufwandsschätzung: | |
| - Wirtschaftlichkeit: Gewinn = Deckungsbeitrag * geschätzte Menge - einmalige Entwicklungskosten (Deckungsbeitrag = Preis - laufende variable Kosten) | |
| - Kostenanteile: | |
| - Personalkosten (Hauptanteil) | |
| - Rechner- und Softwarekosten | |
| - Dienstleistungen, Schulungen, Büromaterial, usw. | |
| - Schätzung der Kosten nach LOC in Personenjahren (PJ) oder Personenmonaten (PM) | |
| - 1 PJ sind 9 bis 10 PM | |
| - 1 PM sind 4 PW (Personenwochen) | |
| - 1 PW sind 5 PT (Personentage) | |
| - 1 PT sind 8 Personenstunden | |
| - Durchschnittliche getestete LOC pro Entwickler pro Monat (beinhaltet gesamten Entwicklungsprozess ab Definition): 350 LOC | |
| - Einflussfaktoren: | |
| - Quantität: | |
| - KLOC | |
| - Komplexität | |
| - Qualität | |
| - Entwicklungsdauer | |
| - Produktivität | |
| - Kosten | |
| - Analogiemethode: | |
| - Schätzung des Aufwands anhand von Ähnlichkeitskriterien zu abgeschlossener Entwicklung | |
| - Kriterien: | |
| - Anwendungsgebiet | |
| - Produktumfang | |
| - Komplexitätsgrad | |
| - Programmiersprache | |
| - Produktumgebung | |
| - Prozentuale Abschätzung | |
| - Relationsmethode: | |
| - Direkte Schätzung anhand von Erfahrungswerten zu abgeschlossener Entwicklung | |
| - Verwendung von Faktorenlisten und Richtlinien zur Bestimmung der Erfahrungswerte | |
| - Verschiedene Eigenschaften (z.B. Programmiersprache) erhalten Werte, die dann voneinander subtrahiert werden | |
| - Punkte werden als Prozente aufgefasst | |
| - Multiplikatormethode: | |
| - Aufteilung des Systems in kleinstmögliche Teilsysteme und Zuweisung von Aufwand zu Teilsystem | |
| - Aufwand für Teilprodukte wird durch Analyse existenter Produkte bestimmt | |
| - Zuordnung von Teilsystem zu einer Kategorie: | |
| - Steuerprogramme | |
| - E/A-Programme | |
| - Datenverwaltungsroutinen | |
| - Algorithmen | |
| - ... | |
| - Multiplikation der Teilaufwände mit Faktor für Kategorie | |
| - Addition der gewichteten Teilaufwände für Gesamtaufwand | |
| - Dauerhafte Überprüfung der Faktoren und Teilsysteme zur Anpassung an sich verändernde Bedingungen | |
| - Phasenmethode: | |
| - Ermittlung der Aufwandsverteilung auf einzelne Entwicklungsphasen bei abgeschlossenen Entwicklungen | |
| - Möglichkeiten für neue Entwicklung: | |
| - Phase abschließen, Phasenaufwand mit Phase alter Entwicklung vergleichen, Aufwand für restliche Phasen anpassen | |
| - Phase aufwändig schätzen, Phasenaufwand mit Phase alter Entwicklung vergleichen, Aufwand für restliche Phasen anpassen | |
| - Methode unbrauchbar, das Schluss auf andere Phasen meistens völlig ungenau ist | |
| - COCOMO II: | |
| - Bestimmt aus geschätzter Größe in KLOC und 22 Einflussfaktoren die Anzahl an PM | |
| - PM = A * Size^(1.01 + 0.01*(sum j=1 to 5: SF_j)) * (prod i=1 to 17: EM_i) | |
| - A: Konstante zur Kalibrierung | |
| - Size: Umfang in KLOC | |
| - SF_j: Skalierungsfaktoren | |
| - EM_i: Multiplikative Kostenfaktoren | |
| - Skalierungsfaktoren: | |
| - Projekterfahrung | |
| - Entwicklungsflexibilität | |
| - Architektur | |
| - Teamzusammenhang | |
| - Prozessmaturität | |
| - Einflussfaktoren: | |
| - Produktfaktoren | |
| - Plattformfaktoren | |
| - Personalfaktoren | |
| - Projektfaktoren | |
| - Konsens-Schätzmethoden: | |
| - Delphi-Methode: | |
| - Experten geben anonym Schätzwerte mit Begründung ab | |
| - Moderator fasst Ergebnisse zusammen | |
| - Wird solange wiederholt, bis Konsens/Durchschnitt erreicht ist | |
| - Planungspoker: | |
| - Analog zur Delphi-Methode | |
| - Teilnehmer besitzen Karten mit stark wachsenden Schätzungen | |
| - Stark abweichende Teilnehmer begründen Schätzungen | |
| - Verwendung: | |
| - Frühe, grobe Schätzung: Analogiemethode, Relationsmethode oder Planungspoker | |
| - Einflussfaktoren bekannt: COCOMO II | |
| - Daten im Unternehmen vorhanden: Multiplikatormethode | |
| Definitionsphase | |
| - Ziel: | |
| - Pflichtenheft: | |
| - Objektmodell, dynamisches Modell, Konzept Benutzeroberfläche | |
| - Definiert was das System tut genau genug für Implementierung | |
| - Verfeinerung des Lastenhefts | |
| - Liefert Modell des Systems | |
| - Modelle: | |
| - Funktionales Modell: Szenarien und Anwendungsfalldiagramme | |
| - Objektmodell: Klassen- und Objektdiagramme | |
| - Dynamisches Modell: Sequenz-, Zustands- und Aktivitätsdiagramme | |
| - Abstrahieren System, um besser Aussagen treffen zu können | |
| - Attribut: Eigenschaft einer Klasse im Modell | |
| - Instanzvariable: Eigenschaft einer Klasse im Code, z.B. Attribute, Zustände oder Assoziationen | |
| - Gleichheit x-ter Stufe: Gleiche Attribute nach (x-1)-ter Stufe | |
| - Zustand: Instanzvariablen die Verhalten beeinflussen | |
| - Kapselungsprinzip: Zustand wird im inneren des Objekts verwaltet und Zugriff von außen erfolgt nur kontrolliert | |
| - Klassendiagramm: | |
| - Stellt die Struktur von Klassen und die Relation zu anderen Klassen dar | |
| - Darstellung: Auf Folien (Kapitel 2.1) | |
| - Liskovsches Substitutionsprinzip: | |
| - Oberklassen können durch Unterklassen ersetzt werden, ohne dass das Programm kaputt geht | |
| - Schwächere Vorbedingungen, stärkere Nachbedingungen in Unterklasse erlaubt | |
| - Varianz: | |
| - Modifikation der Typen der Parameter einer überschriebenen Methode | |
| - Kovarianz: Verwendung einer stärkeren Bedingung (Spezialisierung, Unterklasse) | |
| - Kontravarianz: Verwendung einer schwächeren Bedingung (Verallgemeinerung, Oberklasse) | |
| - Invarianz: Keine Modifikation | |
| - Erlaubt in Subklassen im Sinne des Substitutionsprinzips: | |
| - Eingabeparameter: Kontravarianz | |
| - Ausgabeparameter: Kovarianz | |
| - Ein- & Ausgabeparameter: Invarianz (z.B. Collection<T>-Parameter aus dem sowohl gelesen als auch geschrieben wird) | |
| - Polymorphie: | |
| - statisch (Überladen, Ad-Hoc-Polymorphism): | |
| - Methode mit gleichem Namen aber unterschiedlicher Signatur | |
| - Java: Parameterliste muss unterschiedlich sein | |
| - dynamisch (Vererbung, Subtype-Polymorphism): | |
| - Aufruf von speziellster Methode | |
| - Aktivitätsdiagramm: | |
| - Stellt einen Algorithmus (Anwendungsfall) schematisch dar | |
| - Darstellung: Auf Folien (Kapitel 2.2) | |
| - Sequenzdiagramm: | |
| - Art Interaktionsdiagramm | |
| - Stellt die Ausführung eines Algorithmus (Szenario) zeitlich dar | |
| - Darstellung: Auf Folien (Kapitel 2.2) | |
| - Zustandsdiagramm: | |
| - Stellt die möglichen Zustände eines Objekts dar | |
| - Darstellung: Auf Folien (Kapitel 2.2) | |
| - Paketdiagramm: | |
| - Stellt die Relation von Paketen dar | |
| - Darstellung: Auf Folien (Kapitel 2.2) | |
| - Gliederung von UML-Diagrammen: | |
| - Auf Folien (Kapitel 2.2) | |
| - Ablauf des Anwendungsfalldiagramms wird in Aktivitätsdiagramm dargestellt | |
| - Szenarien des Anwendungsfalldiagramms werden in Sequenzdiagramm dargestellt | |
| - Strukturen des Anwendungsfalldiagramms werden in Klassendiagramm dargestellt | |
| - Verhalten zwischen Klassen in Aktivitätsdiagramm werden in Klassendiagramm dargestellt | |
| - Interaktion zwischen Objekten in Sequenzdiagramm werden in Klassendiagramm dargestellt | |
| - Interaktion zwischen Objekten in Klassendiagramm werden in Sequenzdiagramm dargestellt | |
| - Paketdiagramme stellen die übergeordnete Struktur der Klassendiagramme dar | |
| - Zustandsdiagramme stellen das Verhalten einer Klasse im Klassendiagramm dar | |
| - Sequenzdiagramm modelliert Szenario im Zustandsdiagramm | |
| - Finden von Klassen und Objekten: | |
| - Identifizierung von realen Objekten | |
| - Abstraktionen im existierenden Software-System übernehmen | |
| - Dokumentanalyse: | |
| - Syntaktische Analyse: | |
| - Abbottsche-Methode: | |
| - Nomen: Klasse | |
| - Namen: Exemplar | |
| - Intransitives Verb: Botschaft | |
| - Transitives Verb: Assoziation | |
| - Verb "sein": Vererbung | |
| - Verb "haben": Aggregation | |
| - Modalverb: Zusicherung | |
| - Adjektiv: Attribut | |
| - Linguistische Analyse nach thematischen Rollen | |
| - Inhaltliches Durchforsten | |
| - Bewertung: | |
| - Keine Klassen: | |
| - Keine Attribute oder Operationen | |
| - Identisch zu anderer Klasse | |
| - Nur Operationen, die anderen Klassen zugeordnet werden können | |
| - Implementierungsdetails | |
| - Nur wenige Attribute, die anderen Klassen zugeordnet werden können | |
| - Guter Klassenname: | |
| - Substantiv im Singular | |
| - Konkret | |
| - Beschreibt nicht die Rolle der Klasse in Relation | |
| - Assoziationen sind permanent, problemrelevant und nur von den referenzierten Klassen abhängig | |
| - Attribute: | |
| - Können Werte annehmen | |
| - Sind für Nutzer relevant (sonst Implementationsdetail) | |
| - Wenn für alle Objekte gleich Klassenattribut | |
| - Keine Attribute: | |
| - Nur für Identifikation notwendig | |
| - Referenzierung einer anderen Klasse | |
| - Implementierungsdetail | |
| - Vererbung: | |
| - Nur wenn das Substitutionsprinzip erfüllt ist | |
| - Zusammenfassung von gemeinsamen Attributen und Operationen in Oberklassen | |
| - Keine Vererbung: Keine semantische Spezialisierung | |
| - Erzeugung Sequenzdiagramm und Aktivitätsdiagramm aus Anwendungsfällen: | |
| - Anwendungsfälle in Operationen zerlegen | |
| - Muss konsistent mit Klassendiagramm sein | |
| - Zustandsdiagramme nur für Objekte mit nichttrivialen Lebenszyklen | |
| - Modellierung mit Paketen: | |
| - Innerhalb Paket: Starke Kohäsion | |
| - Zwischen Paketen: Schwache Kopplung | |
| - 10-15 Klassen groß | |
| - Pflichtenheft: | |
| - Gliederung: | |
| - Zielbestimmung | |
| - Zusätzlich: Musskriterien, Wunschkriterien, Abgrenzungskriterien | |
| - Produkteinsatz | |
| - Zusätzlich: Anwendungsbereiche, Zielgruppen, Betriebsbedingungen | |
| - Produktumgebung (neu) | |
| - Zusätzlich: Software, hardware, Orgware, Produkt-Schnittstellen | |
| - Funktionale Anforderungen | |
| - Produktdaten | |
| - Nichtfunktionale Anforderungen | |
| - Globale Testfälle (neu): | |
| - Funktionen, die getestet werden sollen | |
| - Darstellung: /TX0/, Beschreibung | |
| - Systemmodelle | |
| - Szenarien | |
| - Anwendungsfälle | |
| - Objektmodell (neu) | |
| - Dynamische Modelle (neu) | |
| - Benutzerschnittstelle (neu) | |
| - Glossar | |
| Entwurfsphase: | |
| - Softwarearchitektur: | |
| - Komponentengliederung | |
| - Spezifikation der Komponenten | |
| - Aufstellen der Benutzt-Relation | |
| - Optional: Feinentwurf (Algorithmen, Pseudocode) | |
| - Optional: Zuweisung von Softwarekomponenten zu Hardwareeinheiten | |
| - Entscheidung von Maßnahmen zur Erfüllung der nichtfunktionalen Anforderungen | |
| - Auswahl von relevanten nichtfunktionalen Anforderungen | |
| - Modul: Menge von Programmelementen, die nach dem Geheimnisprinzip gemeinsam entworfen und geändert werden | |
| - Geheimnisprinzip: Jedes Modul verbirgt eine wichtige Entwurfsentscheidung hinter einer wohldefinierten Schnittstelle, die sich bei einer Änderung der Entscheidung nicht mit ändert. | |
| - Vorhersehbare Änderungen sollen ohne Schnittstellenänderungen möglich sein | |
| - Entwurfsmethoden: | |
| - Modularer Entwurf: | |
| - Externer Entwurf: | |
| - Modulführer: | |
| - Gliedert in Module | |
| - Beschreibt Funktion und Geheimnis von Modulen | |
| - Modulschnittstellen: | |
| - Beschreibt Schnittstelle von Modulen | |
| - Beispiele: | |
| - Öffentliche Programmelemente | |
| - Nebeneffektsformate | |
| - Signaturen | |
| - Effizienz | |
| - Mögliche Fehler Ausnahmen | |
| - Interner Entwurf: | |
| - Benutztrelation | |
| - (Optional) Feinentwurf | |
| - Anforderungen: | |
| - Module sollen unabhängig voneinander verwendet werden können | |
| - OO Entwurf: | |
| - Verwendet modularen Entwurf | |
| - Module: Pakete/Klassen | |
| - Externer Entwurf: | |
| - Modulführer: Paket-/Klassenführer (UML-Klassen- und UML-Paketdiagramm) | |
| - Modulschnittstellen: Klassenschnittstellen, abstrake Klassen, Interfaces | |
| - Interner Entwurf: | |
| - Benutztrelation für Pakete und alleinstehende Klassen | |
| - (Optional) Feinentwurf | |
| - Hierarchie-Relationen: | |
| - delegiert-an | |
| - ist-ein | |
| - hat-ein | |
| - enthält-ein | |
| - greift-zu-auf | |
| - ist-privilegiert-zu | |
| - ruft auf | |
| - aufgerufen-von | |
| - benutzt | |
| - stellt-Betriebsmittel-bereit | |
| - Benutztrelation: | |
| - A benutzt B gdw. A Verfügbarkeit von B benötigt | |
| - Kriterien: | |
| - A wird durch Benutzung von B einfacher | |
| - B wird nicht viel komplexer durch Nichtverwendung von A | |
| - B wird noch von anderen Modulen verwendet | |
| - A verwendet immer B | |
| - Benutzthierarchie: | |
| - Zyklenfreie Benutztrelation | |
| - Vorteil: Schrittweiser Aufbau | |
| - Allgemeinheit: Programm kann in vielen Situationen ohne Änderungen benutzt werden | |
| - Flexibilität: Programm kann leicht für viele Situationen angepasst werden | |
| - Architekturstile: | |
| - Grobaufbau eines Softwaresystems | |
| - Virtuelle Maschine: | |
| - Maschine, die unterliegende Maschine abstrahiert | |
| - Schnittstelle sind bereitgestellte Befehle und Objekte | |
| - Software-Produktlinie: | |
| - Programme, die Anforderungen, Entwurfs- oder Softwarekomponenten teilen | |
| - Effiziente Entwicklung durch Wiederverwendung | |
| - Schichtenarchitektur: | |
| - Gliederung von Softwarearchitektur in hierarchische Schichten | |
| - Schicht kommuniziert über Schnittstelle zur oberen Schicht und nutzt Schnittstelle von unteren Schichten | |
| - Keine Zyklen in Benutztrelation zwischen Schichten | |
| - Transparente Schichtenarchitektur: Forward-Kanten erlaubt | |
| - Vorteil: Übersichtlich, Schichten wiederverwendbar und Testbar | |
| - Evtl. Vereinfachung der Schnittstelle durch Fassade | |
| - Client/Server: Server stellen Dienste bereit, Clients fordern Dienste an | |
| - Peer-to-Peer: | |
| - Dezentralisiert | |
| - Clients sind zugleich Server | |
| - Partner sind unzuverlässig, Daten müssen also redundant sein | |
| - Depot: | |
| - Subsysteme verwenden gemeinsame Datenablage | |
| - Transaktionskonzept: Synchronisierung bei nebenläufigen Zugriffen | |
| - MVC: | |
| - Model: Daten und Anwendungslogik | |
| - View: Darstellung | |
| - Controller: Nimmt Benutzereingaben entgegen, aktualisiert Modell | |
| - Bekanntgabe von Veränderungen durch Beobachter | |
| - Pipeline: | |
| - Mehrere nebenläufige Stufen hintereinander zur Datenverarbeitung | |
| - Buffer zwischen Schichten | |
| - Framework: | |
| - "Don't call us - we'll call you" | |
| - Erweiterung durch Plugins | |
| - Auch manchmal nur Zusammenfassung von Bibliotheken | |
| - Anwendung: | |
| - Erweiterungen sollen möglich sein | |
| - Steuernder Code ist aufwendig | |
| - Dienstorientierte Architekturen: | |
| - Anwendungen werden aus Diensten zusammengestellt | |
| - Servicemodell: Dienstnutzer fragt Dienstverzeichnis an und kommuniziert dann mit empfohlenen Dienstanbieter | |
| - Entwurfsmuster: | |
| - Familie von Lösungen für Software-Entwurfsproblem | |
| - Vorteil: Verbessern Kommunikation und Code-Struktur | |
| - Entkopplungs-Muster: | |
| - Teilt System auf und entkoppelt System | |
| - Ersetzt Kopplung durch Schnittstelle | |
| - Adapter (Wrapper): | |
| - Schnittstelle von Klasse wird für vom Klienten erwartete Schnittstelle angepasst | |
| - Wrapper erbt von Zielschnittstelle und ersetzt Schnittstelle um die adaptierte Klasse aufzurufen | |
| - Beobachter: | |
| - Aufrechterhaltung von Konsistenz ohne enge Kopplung | |
| - Subjekt: | |
| - Besitzt mehrere Beobachter, erlaubt An-/Abmeldung und Benachrichtigung (Aktualisierung aller Beobachter) | |
| - Konkrete Subjekte haben nach außen konfigurierbaren Zustand | |
| - Konkrete Subjekte benachrichtigen nach Setzen des Zustands | |
| - Beobachter: | |
| - Kann aktualisiert werden | |
| - Konkreter Beobachter holt sich Zustand vom konkreten Subjekt | |
| - Ablauf: | |
| - Zustand im konkreten Subjekt ändert sich | |
| - benachrichtige() wird aufgerufen | |
| - Jeder Beobachter wird aktualisiert, d.h. jeder Beobachter holt sich Zustand | |
| - Anmerkungen: | |
| - Subjekt als Parameter für aktualisiere() auf Beobachter falls Beobachter in mehreren Subjekten verwendet wird | |
| - Bei kaskadierenden Änderungen darf nicht neu benachrichtigt werden, Zustand des Subjekts muss nach aktualisiere() konsistent sein | |
| - Vorteile: | |
| - Unabhängige Verwendung von Subjekt und Beobachter | |
| - Beobachter können zur Laufzeit hinzugefügt werden | |
| - Brücke: | |
| - Entkoppelt Abstraktion von Implementierung | |
| - Vermeidet Abstration/Implementations-Kombinationsklassen | |
| - Abstraktion nutzt Implementierer, welcher konkrete Implementierer versteckt | |
| - Klient nutzt Abstraktion, welche spezialisierte Abstraktion versteckt | |
| - Iterator: | |
| - Aggregat liefert Iterator | |
| - Iterator kann iterieren und entfernen (hatNächstes, nächstes, entferne) | |
| - Stellvertreter: | |
| - Kontrolliert Zugriff auf Objekt und abstrahiert Objekt | |
| - Stellvertreter ist Subjekt, eigentliches Subjekt ist auch Subjekt, Klient kommuniziert mit Subjekt, das Stellvertreter versteckt | |
| - Beispiele: Smart-Pointer, Cache, Remote-Proxy, Laziness, Firewall, Synchronisierer, Dekorierer | |
| - Vermittler: | |
| - Kapselt Zusammenspiel von Objekten, ohne dass sich Objekte kennen | |
| - Objekte sprechen mit Vermittler, Vermittler mit Objekten | |
| - Kollege versteckt konkrete Kollegen, Vermittler versteckt konkrete Vermittler | |
| - Ablauf: Kollege ändert sich, informiert Vermittler, konkreter Vermittler informiert nach Situation andere konkrete Kollegen | |
| - Varianten-Muster: | |
| - Zusammenfassung von Gemeinsamkeiten | |
| - Abstrakte Fabrik: | |
| - Erzeugt Objekte einer Familie | |
| - Abstrakte Fabrik erzeugt Produkte, die konkrete Fabrik, welche hinter der abstrakten versteckt ist, erzeugt konkretes Produkt, welches dann hinter Produkt versteckt wird | |
| - Besucher: | |
| - Kapselt Operationen als Objekt | |
| - Besucher versteckt konkrete Besucher, Klient ruft Element mit Besucher auf, konkretes Element ruft Besucher auf und führt so den vom Klienten verwendeten konkreten Besucher aus | |
| - Fabrikmethode: | |
| - Schablonenmethode zur Erzeugung des Produkts, wobei Produkt konkretes Produkt versteckt | |
| - Unterklassenerzeuger entscheiden, welches konkrete Produkt erzeugt wird | |
| - Kompositum: | |
| - Zusammenfügung von Objekten zu Baumstruktur | |
| - Komponente versteckt Kompositum und Blätter | |
| - Kompositum kann weitere Komponenten enthalten | |
| - Komponenten haben gemeinsame Operationen | |
| - Kompositum führt auch Operation auf Kindern aus | |
| - Möglichkeiten: | |
| - Hinzufügen von Komponenten auf Komponente: Dummy-Code statt Fehler beim Casten | |
| - Hinzufügen von Komponenten auf Kompositum: Fehler beim Casten statt Dummy-Code | |
| - Evtl. Eltern-Referenz | |
| - Schablonenmethode: | |
| - Abstrakte Klasse enthält Schablonenmethode, welche abstrakte Methoden (Einschubsmethoden) verwendet | |
| - Konkrete Klassen überschreiben abstrakte Methoden | |
| - Alternative: Abstrakte Methode wird durch Interface ersetzt, Klasse ruft ggf. Interface auf | |
| - Alternative ohne explizites Setzen der konkreten Klasse: Reflection | |
| - Strategie: | |
| - Austauschbarkeit für Familie von Algorithmen, bei denen sich nur das Verhalten unterscheidet, nicht jedoch die Schnittstelle | |
| - Strategie versteckt konkrete Strategie, Nutzer kennt nur Strategie | |
| - Nutzer entscheidet Strategie je nach Situation | |
| - Unterschied zur Schablonenmethode: Strategien teilen i.A. keinen Code und enthalten komplett unterschiedliche Algorithmen, während sich bei der Schablonenmethode ein Algorithmus nur in wenigen Aspekten unterscheidet | |
| - Dekorierer: | |
| - Fügt dynamisch neue Funktionalität zu Objekt hinzu | |
| - Dekorierer ist Komponente und enthält Komponente, d.h. Komponente wird mit Dekorierer dekoriert | |
| - Konkreter Dekorierer fügt neue Methoden hinzu | |
| - Konkrete Komponente wird erweitert, indem sie mit Dekorierer dekoriert wird | |
| - Dekorierer vs. Stellvertreter: | |
| - Dekorierer: Fügt Funktionalität hinzu | |
| - Stellvertreter: Versteckt Teile des Subjekts | |
| - Zustandhandhabungsmuster: | |
| - Bearbeiten Zustand von Objekten | |
| - Einzelstück: | |
| - Nur eine Instanz für Klasse | |
| - Synchronisierte, statische Methode und statische Instanz | |
| - Fliegengewicht: | |
| - Wiederverwendung unveränderbarer Objekte wenn möglich durch Fabrik | |
| - Memento: | |
| - Zustand wird serialisiert, um später deserialisiert werden zu können | |
| - Memento kapselt Zustand, um Kapselung nicht zu zerstören | |
| - Prototyp: | |
| - Kopiere Objekte, statt explizit neu zu erzeugen | |
| - Prototyp: Objekt, das kopiert werden kann | |
| - Zustand: | |
| - Darstellung von State-Machines | |
| - Konkrete Zustände enthalten Verhalten | |
| - Zustand versteckt konkrete Zustände | |
| - Neuer Zustand wird aus aktuellem Zustand bestimmt | |
| - Steuerungsmuster: | |
| - Steuern Kontrollfluss | |
| - Befehl: | |
| - Befehl (Funktion ohne Parameter und Returnwerte) als Objekt darstellen | |
| - Befehl versteckt konkreten Befehl | |
| - Master/Worker: | |
| - Fehlertolerante parallele Berechnung | |
| - Arbeiter erledigen Teilarbeiten für Master | |
| - Virtuelle Maschinen | |
| - Bequemlichkeitsmuster: | |
| - Sparen Schreib- oder Denkarbeit | |
| - Bequemlichkeits-Klasse: | |
| - Parameter werden zu Objekt zusammengefasst | |
| - Bequemlichkeits-Methode: | |
| - Häufige Parameterverwendungen werden zu überladener Methode zusammengefasst | |
| - Fassade: | |
| - Einheitliche Schnittstelle, welche die Verwendung des Subsystems vereinfacht | |
| - Null-Objekt | |
| - Stellt sane default behavior bereit | |
| Implementierungsphase | |
| - Konzeption von Datenstrukturen und Algorithmen | |
| - Feinere Strukturierung des Programms | |
| - Dokumentation von Entscheidungen: | |
| - Z.B. Zeit- und Speicherkomplexität, Programmoptimierungen | |
| - Programmierung | |
| - Test oder Verifikation des Programms | |
| - Abbildung von UML auf Code: | |
| - Klassen zu Klassen bzw. Structs/Funktionen | |
| - Vererbung zu Vererbung/Komposition | |
| - Polymorphie zu Polymorphie/Void-Pointer | |
| - 1:1 auf Referenz in Navigationsrichtung | |
| - 1:n auf Collections in Navigationsrichtung | |
| - {ordered}: Liste | |
| - {unique}: Set | |
| - Qualifizierer: Map | |
| - Assoziationsklasse: Transformation in zwei 1:n Assoziationen | |
| - Implizite Speicherung von Zuständen: null | |
| - Explizite Speicherung von Zuständen: Enum | |
| - Eingebette Zustände: Jede Methode enthält kompletten Automaten und entscheidet, in welchem Zustand sie sich gerade befindet | |
| - Ausgelagerte Zustände: | |
| - Zustandsklasse für jeden Zustand mit Übergangsmethoden | |
| - Erben von CZustand mit Methoden: entry, exit, Übergänge, zustandsWechsel, nächster mit sinnvollen Defaults | |
| - nächster gibt nächsten Zustand zurück | |
| - Parallelisierung: | |
| - Nebenläufig: Nicht kausal voneinander abhängig | |
| - Parallel: Gleichzeitig | |
| - Speicherarchitekturen: | |
| - Gemeinsamer Speicher, der von mehreren Prozessoren genutzt wird | |
| - Verteilter Speicher, der nur dem Prozessor zugängig ist. Kommunikation per message passing. | |
| - Prozess: | |
| - Vom OS erzeugt | |
| - Code-Segment, Daten-Segment | |
| - Thread: | |
| - Existiert im Prozess | |
| - Eigener Befehlszeiger, Stack (d.h. Aktivierungszeiger, Kellerzeiger), eigene Register | |
| - Teilt Adressraum, Code-/Datensegmente und externe Ressourcen mit anderen Threads | |
| - Vorgehen bei gemeinsamen Speicher: | |
| - Mehrere Fäden mit parallelen Aufgaben | |
| - Kommunikation über geteilte Variablen im Speicher | |
| - Synchronisation des Zugriffes | |
| - Parallelität in Java: | |
| - Starten eines Threads: new Thread(runnable).start(); | |
| - Kritischer Abschnitt: Bereich, in dem auf gemeinsamen Zustand zugegriffen wird | |
| - Wettlaufsituation: Die Korrektheit ist von der Implementation abhängig | |
| - Lösung: Nur eine Aktivität darf einen kritischen Abschniss gleichzeitig bearbeiten | |
| - Atomarität: Zugriffe auf Variablen sind atomar | |
| - Monitore: | |
| - enter() und exit() | |
| - Wird enter() aufgerufen während noch nicht wieder exit() aufgerufen wurde, blockiert der Caller bis exit() aufgerufen wird | |
| - Dieselbe Aktivität kann enter() mehrfach aufrufen | |
| - Jedes Objekt ist Monitor | |
| - synchronized (monitor) {} ist synchronisierter Block | |
| - Bei synchronized als Methoden-Keyword ist das Objekt der Methode automatisch Monitor | |
| - Im synchronized-Block: | |
| - wait(): Wartet bis notify | |
| - notifyAll(): Weckt wartende Threads auf (Evtl. Eintritt in enter()-Warten) | |
| - Production/Consumer-Pattern: | |
| - while (queue full) {wait()} | |
| queue add | |
| notifyAll() | |
| - while (queue empty) {wait()} | |
| queue remove | |
| notifyAll() | |
| - Threads können zufällig aufgeweckt werden | |
| - Unterbrechung von Threads: InterruptedException | |
| - join: Wartet bis Thread fertig ist | |
| - java.util.concurrent: | |
| - Concurrent Collections | |
| - volatile: Atomarer Zugriff auf Variable | |
| - Blocking Queues | |
| - Semaphores: Lock mit Zähler | |
| - Mutex: Semaphore mit Zähler 1 | |
| - Cyclic Barrier: Blockiert n Fäden und setzt dann fort | |
| - Deadlock: Gegenseitiges Warten auf Freigabe | |
| - Parallele Algorithmen: | |
| - Matrix-Vektor-Multiplikation: | |
| - Zeilenweise Aufteilung | |
| - Für eine ixj Matrix multiplizieren i Threads (bzw. weniger, wenn Zeilen in Blöcken abgearbeitet werden) gleichzeitig die Werte der jeweiligen Zeilen und fügen den Wert im Ergebnisvektor zusammen | |
| - Da jeder Thread eine eigene Zeile abarbeitet und die Ergebnisse disjunkt zusammengefügt werden, ist keine Synchronisation notwendig | |
| - Spaltenweise Aufteilung: | |
| - Für eine ixj Matrix multiplizieren j Threads (bzw. weniger, wenn Spalten in Blöcken abgearbeitet werden) gleichzeitig die Werte der Spalten in der aktuellen Zeile und fügen dann alle Ergebnisse im Ergebnisvektor zusammen | |
| - Für das Zusammenfügen ist Synchronisation nötig, weshalb diese Methode sehr langsam ist | |
| - Blockweise Aufteilung (falls gleichzeitiger Lesezugriff auf Vektor nicht möglich): | |
| - Threads arbeiten an disjunkten Teilen von Zeilen, damit auf den Multiplikationsvektor disjunkt zugegriffen wird | |
| - Matrix-Multiplikation: | |
| - (Vorraussetzung: Zeilen in Matrix sind auch Zeilen in Speicher) | |
| - ijk-Algorithmus: | |
| - Zeile * Spalte | |
| - Standartalgorithmus | |
| - Langsam, da ständiger Spaltenwechsel auf rechter Matrix | |
| - ikj-Algorithmus: | |
| - Gehe über linke Matrix und addiere die jwg. multiplikativen Ergebnisse mit den Werten der rechten Matrix auf die jwg. Zellen der Zielmatrix | |
| - Zellen der rechten Matrix werden schrittweise aufgebaut, statt eins für eins komplett fertiggestellt zu werden | |
| - Cachefreundlich, da Iteration über Zeilen | |
| - Bei Parallelisierung: Aufteilung von Threads auf Spalten | |
| - Numerische Integration: | |
| - Bereiche der Funktion approximieren | |
| - Verfahren: | |
| - Gebietszerlegung | |
| - Master/Worker | |
| - Erzeuger/Verbraucher | |
| - Fließband | |
| - Teile-und-Herrsche | |
| - Map/Reduce | |
| - Gesamtlaufzeit: T(p) = o + t/p, mit o der Zeit für Ausführen des sequentiellen Teils und t Zeit für die sequentielle Ausführung des parallelisierbaren Teils | |
| - Beschleunigung: S(p) = T(1) / T(p) | |
| - Effizienz: E(p) = S(p) / p | |
| - Amdahlsches Gesetz: S(p) <= (o+t)/o = 1/f, mit f dem sequentiellen Anteil des Algorithmus | |
| Testphase | |
| - "Testing shows the presence of bugs, not their absence" | |
| - Möglichkeiten um Korrektheit besser zu prüfen: | |
| - Testen | |
| - Korrektheit verifizieren | |
| - Analyseverfahren | |
| - Fehlerarten: | |
| - Versagen/Ausfall: Ereignis, Software weicht von Spezifikation ab | |
| - Defekt: Mangel, der zur Abweichung führt | |
| - Irrtum: Menschliche Aktion, die Defekt verursacht | |
| - Testhelfer: | |
| - Stummel: | |
| - Rudimentär implementierter Teil Software, Platzhalter | |
| - Ersetzen noch nicht implementierte Abhängigkeit | |
| - Attrappe: | |
| - Simuliert Implementierung zu Testzwecken | |
| - Ersetzen noch nicht implementierte Abhängigkeit | |
| - Nachahmung: | |
| - Attrappe mit zusätzlicher Funktionalität | |
| - Enthält Testcode | |
| - Fehlerklassen: | |
| - Anforderungsfehler: Fehler im Pflichtenheft | |
| - Entwurfsfehler: Fehler im Entwurf | |
| - Implementierungsfehler: Fehler in der Implementation | |
| - Test: Ausführung von Komponente/-n unter bekannten Bedingung und Prüfung von Verhalten | |
| - Regressionstest: Prüft, ob ein ehemaliger Fehler wieder auftritt | |
| - Testmenge: Menge von Testfällen | |
| - Automatischer ablaufender Testfall: | |
| - Test wird automatisch und ohne großen Aufwand ausgeführt | |
| - Besonders nützlich für Regressionstests | |
| - Testling: Zu prüfende Komponente/-n | |
| - Testfall: Satz von Daten zur Ausführung des Testlings und Überprüfung des Ergebnisses | |
| - Testtreiber: | |
| - Framework, das Testfälle ausführt | |
| - Beispiel JUnit: | |
| - Rahmenarchitektur für automatische Tests | |
| - Features: | |
| - Organisation von Testmengen als Dateien und Test-Suites | |
| - Automatische Ausführung von Testfällen als Methoden | |
| - Testphasen: | |
| - Komponententest: | |
| - Eingabe: Objektentwurfsdokument | |
| - Überprüft Funktion von Einzelmodulen | |
| - Integrationstest: | |
| - Eingabe: Systementwurfsdokument | |
| - Überprüft iterativ das Zusammenwirken von einzelnen getesteten Komponenten | |
| - Systemtest: | |
| - Eingabe: Anforderungsanalysedokument | |
| - Abschließender Test in realistischer Umgebung ohne Kunden | |
| - Abnahmetest: | |
| - Eingabe: Kundenerwartung | |
| - Abschließender Test in realistischer Umgebung mit und unter Einwirkung des Kunden | |
| - Testverfahren: | |
| - Dynamische Verfahren ("Testen"): | |
| - Strukturtests (white box) | |
| - Funktionale Tests (black box) | |
| - Leistungstests (black box) | |
| - Statische Verfahren ("Prüfen"): | |
| - Manuelle Analyse | |
| - Prüfprogramme | |
| - Komponententests: | |
| - Kontrollflussorientiert: | |
| - Erzeugung Kontrollflussgraph: | |
| - Strukturerhaltende Transformation in Zwischensprache: | |
| - Nur Befehle, welche die Ausführungsreihenfolge beeinflussen, ändern sich | |
| - Wiederholung von gleichen Sprüngen ist zu vermeiden | |
| - Zwischensprache: | |
| - Zeilennummerierung erzeugen | |
| - Transformation Kontrollkonstrukte in if-Abfragen und Sprünge: | |
| - Konditionale Vorwährtsprünge und unkonditionale Rückwärtssprünge: | |
| - Invertierung der meisten Bedingungen mit einem "not" | |
| - Aufteilung in Grundblöcke: | |
| - Eintritt nur am Anfang | |
| - Sprung nur am Ende | |
| - Kontrollflussgraph: | |
| - G = (N, E, n_start, n_stopp) (N Grundblockknoten, E Kanten für Sprünge zwischen Blöcken, n_start Startblock, n_stopp Stoppblock) | |
| - Knoten: | |
| - Rechtecke mit runden Ecken | |
| - Inhalt: n_start/n_stopp/Code des Grundblocks | |
| - Bei Codeblock Durchnummerierung der Knoten in oberer rechten Ecke durch n_i (i in N) | |
| - Kanten ("Zweige"): | |
| - Durchgezogene Pfeile mit ausgefüllter Pfeilspitze | |
| - "ja/nein"-Beschriftung an Kante beim Quellknoten für Sprung bei Erfüllung der Bedingung | |
| - Keine Beschriftung für unkonditionalen Sprung | |
| - Knoten mit nur einem Sprungbefehl werden entfernt und durch Sprungkanten ersetzt | |
| - Vollständige Pfade: Pfad, der bei n_start beginnt und bei n_stopp endet | |
| - Zu beachten: | |
| - Short-circuiting | |
| - If-expressions | |
| - Anweisungsüberdeckung: | |
| - Ausführung aller Grundblöcke | |
| - Coverage: C_Anweisung = Anzahl durchlaufener Anweisungen / Anzahl Anweisungen | |
| - Zweigüberdeckung: | |
| - Ausführung aller Zweige | |
| - Coverage: C_Zweig = Anzahl durchlaufener Zweige / Anzahl Zweige | |
| - Pfadüberdeckung: | |
| - Ausführung aller vollständigen Pfade | |
| - Meistens unmöglich | |
| - X subsumiert Y wenn jede Menge von Pfaden die X erfüllt auch Y erfüllt | |
| - Pfadüberdeckung subsummiert Zweigüberdeckung subsummiert Anweisungsüberdeckung | |
| - Funktionale Tests: | |
| - Testfall aus Spezifikation ableiten (Black-Box-Test) | |
| - Vorteile: | |
| - Unabhängig von Implementation | |
| - Nicht kurzsichtig | |
| - Nachteil: | |
| - Kritische Pfade werden evtl. nicht getestet | |
| - Verfahren zur Testfallbestimmung: | |
| - Funktionale Äquivalenzklassenbildung: | |
| - Bildung von Äquivalenzklassen separat nach Eingabe und Ausgabe | |
| - Aufteilungen von existierenden Äquivalenzklassen: | |
| - Entlang Definitionsbereichsgrenzen | |
| - Entlang anzunehmenden Verarbeitungsmethodengrenzen | |
| - Kombiniere alle möglichen Eingabe- und Ausgabeäquivalenzklassen | |
| - Wähle jeweis einen Repräsentanten zum Testen aus jeder kombinierten Äquivalenzklasse aus | |
| - Grenzwertanalyse: Wähle Repräsentanten aus Äquivalenzklassen auf dem Rand und um den Rand | |
| - Zufallstest: Erzeugung zufälliger Testfälle, nützlich als Ergänzung | |
| - Test von Zustandsautomaten: Testen aller Zustandsübergänge | |
| - Leistungstests: | |
| - Lasttests: Testen die Komponente auf Zuverlässigkeit und das Einhalten der Spezifikation im erlaubten Grenzbereich | |
| - Stresstests: | |
| - Testen die Komponenten auf Zuverlässigkeit beim Überschreiten des Grenzbereichs | |
| - Prüft, ob sich das System wieder erholt nach dem Stresstest | |
| - Manuelle Prüfmethoden: | |
| - Prüfen Semantik | |
| - Aufwendig | |
| - Konfliktpotenzial unter Mitarbeitern | |
| - Software-Inspektion: | |
| - Inspektoren untersuchen unabhängig das Software-Dokument | |
| - Defekte werden aufgeschrieben und diskutiert | |
| - Ziel: Identifikation, nicht Lösung der Probleme | |
| - Strukturierung: Rollen, Formulare, Prüflisten, Perspektiven | |
| - Unterarten: | |
| - Inspektion: Überprüfung anhand von Prüflisten oder Lesetechniken | |
| - Überprüfung: Formalisierter Prozess zur Überprüfung von schriftlichen Dokumenten durch externen Gutachter | |
| - Durchsicht: Entwickler führt Kollegen durch Code oder Entwurf und Kollegen geben Feedback | |
| - Prüfliste: Konkrete Liste an Fragen, nach denen Dokument analysiert wird | |
| - Perspektiven: Liste an Fragen zu mehreren Sichtweisem (z.B. Warter, Code-Analyse, Tester, Entwerfer) | |
| - Phasen: | |
| - Vorbereitung: | |
| - Teilnehmer und Rollen festlegen | |
| - Dokumente und Formulare vorbereiten | |
| - Lesetechniken festlegen | |
| - Zeitlichen Ablauf planen | |
| - Individuelle Fehlersuche: | |
| - Jeder Inspektor prüft für sich das Dokument | |
| - Notiert Defekte, Vorschläge und Fragen | |
| - Gruppensitzung: | |
| - Individuelle Problempunkte sammeln | |
| - Problempunkte diskutieren | |
| - Weitere Problempunkte aus der Diskussion sammeln | |
| - Nachbereitung: | |
| - Editor klassifiziert Problempunkte | |
| - Editor führt Änderungen durch | |
| - Restdefekte: | |
| - Anzahl nicht entdeckter Defekte ist etwa gleich den entdeckten Defekten | |
| - 1/6 der Korrekturen ist fehlerhaft | |
| - Freigabe des Dokuments wenn die Anzahl entdeckter Defekte klein genug ist | |
| - Prozessverbesserung: Planung, Durchführung und Prüflisten verbessern | |
| - Rollen: | |
| - Inspektionsleiter: Leitet Inspektion | |
| - Moderator: Leitet Gruppensitzung | |
| - Inspektoren | |
| - Schriftführer: Protokolliert Probleem in Gruppensitzung | |
| - Editor: Behebt Defekte | |
| - Prozess: Verpflichtende Inspektion entweder vor Einbuchung oder optionale Inspektion nach Einbuchung durchführen | |
| - Insgesamt: | |
| - Effektiv | |
| - Sehr aufwendig | |
| - Prüfprogramme: Programme, die mögliche Fehler finden oder Programmierstil überprüfen | |
| - Integrationstest: | |
| - Iterativ Komponenten zu Komponentenmenge hinzufügen und Komponentenmenge als Ganzes testen | |
| - Schrittweises Ersetzen von Stummeln und Attrappen durch Implementierungen | |
| - Inkrementell: | |
| - Vorteil: Leicht zu konstruieren, Fehler leicht zu entdecken | |
| - Nachteil: Evtl. viel Testcode notwendig | |
| - Vorgehensorientiert: | |
| - Integrationsreihenfolge leitet sich aus Systemarchitektur ab | |
| - Top-down: | |
| - Integration von oben (z.B. GUI) | |
| - Viele Testhelfern benötigt | |
| - Leichtes Erkennen von Spezifikationsproblemen | |
| - Spätes Erkennen von hardwarenahen Problemen | |
| - Bottom-up: | |
| - Integration von unten | |
| - Spätes Erkennen von Spezifikationsproblemen | |
| - Frühes Erkennen von hardwarenahen Problemen | |
| - Outside-in: Integration von oben und unten gleichzeitig (vereint Vorteile von bottom-up und top-down) | |
| - Inside-out: Integration von der Mitte (vereint Nachteile von bottom-up und top-down) | |
| - Hardest-first: Die kompliziertesten Komponenten werden zu erst getestet und integriert und somit am Ende am meisten getestet | |
| - Testzielorientiert: | |
| - Testfälle werden nach Testzielen erstellt | |
| - Funktionsorientiert: Komponenten werden integriert, nachdem Komponenten von funktionaler Anforderung vollständig getestet sind | |
| - Nach Verfügbarkeit: Komponenten werden abwechselnd getestet und integriert, Komponenten werden nach Fertigstellungsreihenfolge getestet | |
| - Unmittelbar und testzielorientiert: | |
| - Big bang: Alles wird auf einmal getestet | |
| - Geschäftsprozessorientiert: Alle Komponenten werden integriert, die von Anwendungsfall betroffen sind (Big bang nach Anwendungsfällen) | |
| - Vorteil: Keine Testtreiber oder Platzhalter benötigt | |
| - Nachteile: System muss als Ganzes getestet werden, Defekte schwer zu lokalisieren | |
| - Systemtests: | |
| - Prüfung des Gesamtsystems als Black-Box-Test in realistischer Umgebung | |
| - Funktionaler Systemtest: Prüft Korrektheit und Vollständigkeit | |
| - Nichtfunktionaler Systemtest: Prüft nichtfunktionale Qualitätsmerkmale | |
| - Abnahmetest: | |
| - Systemtest, bei dem Kunde beobachtet und mitwirkt | |
| - Verwendet Umgebung und Daten des Kunden | |
| - Kunde nimmt nach Abnahmetest Produkt an | |
| Wartungsphase | |
| - Besteht aus Abnahme-, Einführungs- & Wartungsphase | |
| - Abnahmephase: | |
| - Übergabe des Produkts & Dokumentation an Auftraggeber | |
| - Abnahmeprotokoll | |
| - Einführungsphase: | |
| - Aufgaben: | |
| - Installation | |
| - Eventuelle Schulung der Nutzer und des Betriebspersonals | |
| - Inbetriebnahme | |
| - Dokumentation durch Einführungsprotokoll | |
| - Bei Ersatz eines existierenden Systems: | |
| - Umstellung der Datenbestände zu konkreten Deadlines | |
| - Verwendung von Werkzeugen für Umstellung und Prüfung der Richtigkeit der Konversion | |
| - Inbetriebnahme: | |
| - Direkte Umstellung: | |
| - Das gesamte System wird an wenigen Tagen umgestellt | |
| - Risikoreich | |
| - Parallellauf: | |
| - Beide Systeme laufen gleichzeitig | |
| - Weniger Risiko, aber dafür hohe Kosten | |
| - Versuchslauf: | |
| - Möglichkeiten: | |
| - Neues System arbeitet mit alten Daten, altes System mit neuen Daten | |
| - Neues System wird in Stufen in neue Funktionsbereiche eingeführt | |
| - Bei anonymem Markt: Betatest für Pilotkunden | |
| - Wartungsphase: | |
| - Archivierung von Versionen und Informationen zu Versionen von Kunden | |
| - Kategorien 1: | |
| - Korrektive Tätigkeiten (Wartung): | |
| - Korrektur: Wartungsdefekte (Defekte, die bei der Wartung entstehen) besonders häufig | |
| - Optimierung | |
| - Progressive Tätigkeiten (Pflege): | |
| - Anpassung an Umgebung und neue Anforderungen | |
| - Erweiterung | |
| - Kategorien 2: Korrigierend, Anpassend, Perfektionierend (Optimierung, Erweiterung) | |
| - Wartung ist ereignisgesteuert, Pflege ist planbar | |
| - Pflegeaktivitäten sollten regulären Entwicklungsprozess durchlaufen | |
| - Sanierung (Re-Engineering): Neuentwicklung alter Software | |
| - Änderungsverwaltung: | |
| - Effektivere Bearbeitung mit ausführlichen Bug-Reports in Bug-Tracker | |
| - Organisation der Wartung: | |
| - Eigene Wartungsorganisation: | |
| - Bessere Effizienz durch Spezialisierung | |
| - Koordinationsprobleme | |
| - Entwickler müssen keine Konsequenzen tragen | |
| - Dauerhafte Wartung sehr anstrengend | |
| - Kompromiss: Rotation zwischen Organisationen | |
| Prozessmodelle | |
| - Programmieren durch Probieren: | |
| - Prozess: | |
| - Programmieren | |
| - Anforderung, Entwurf, Tests und Wartung überlegen | |
| - Programm verbessern | |
| - Einfach und schnell | |
| - Für Teamarbeit ungeeignet, evtl. mangelnde Anforderungserfüllung und kostspielige Wartung | |
| - Wasserfallmodell (auch Phasenmodell): | |
| - Keine Rückkopplung | |
| - Keine Parallelisierung | |
| - Wenig Möglichkeiten für Kunden | |
| - V-Modell 97: | |
| - Prozess: | |
| - Anforderungsdefinition | |
| - Grobentwurf | |
| - Feinentwurf | |
| - Implementierung | |
| - Modultest | |
| - Integrationstest | |
| - Systemtest | |
| - Abnahmetest | |
| - Prüfungsschritte symmetrisch zu Entwurfsschritten | |
| - V-Modell-XT: Keine Ordnung der Schritte, dafür Rollenverteilung | |
| - Prototypenmodell: | |
| - Prozess: | |
| - Prototyp entwickeln | |
| - Prototyp neu entwickeln, z.B. mit Wasserfallsmodell | |
| - Prototyp wegwerfen | |
| - Iteratives Modell: | |
| - Funktionalität wird Schritt für Schritt erstellt und hinzugefügt | |
| - Evolutionär: | |
| - Nur der Teil, der als nächstes hinzugefügt wird, wird geplant | |
| - Problem: Spätere Teile können eventuell nicht integriert werden | |
| - Inkrementell: | |
| - Alles planen und analysieren | |
| - Dann mehrfach über Entwurfs-, Implementierungs- und Testphase iterieren | |
| - Erfordert viel Planung | |
| - Synchronisiere und Stabilisiere: | |
| - Viele kleine Teams die unabhängig arbeiten | |
| - Ergebnise werden nächtlich synchronisiert und regelmäßig (z.B. im 3-Monats-Zyklus) stabilisiert | |
| - Phasen: | |
| - Planungsphase: | |
| - Wunschbild: Manager identifizieren Produkteigenschaften | |
| - Spezifikation: Manager und Entwickler spezifizieren Funktion, Architektur und Komponenten-Abhängigkeiten | |
| - Zeitplan und Produktfunktionsgruppen: Manager, Entwickler, Tester in jeweils einer Gruppe | |
| - Dauer 3-12 Monate | |
| - Entwicklungsphase: | |
| - Manager koordinieren Weiterentwicklung der Spezifikation | |
| - Entwickler entwerfen/entfernen Fehler, Tester testen | |
| - Regelmäßiges Ausbuchen, Bearbeiten, Übersetzen, Testen | |
| - Automatische Regressionstest und nächtliche Synchronisierung durch vollständiges Neuübersetzen der Quelldateien | |
| - Drei Teilprojekte: Wichtigste Funktionalität, mittelwichtige Funktionalität, unwichtige Funktionalität | |
| - Teilprojekte werden hintereinander entwickelt | |
| - Dauer Teilprojekt: 2-4 Monate | |
| - 6-10 Wochen Entwicklung | |
| - 2-5 Wochen Integration | |
| - 2-5 Wochen Pufferzeit | |
| - Teilprojektstabilisierung nach Teilprojekt | |
| - Stabilisierungsphase: | |
| - Manager koordinieren Beta-Tester | |
| - Entwickler stabilisieren | |
| - Tester isolieren Fehler | |
| - Tests: Interne und externe Tests | |
| - Vorbereitung für Auslieferung | |
| - Dauer: 3-8 Monate | |
| - Vorteile: | |
| - Kurze Produktzyklen | |
| - Gute Priorisierung | |
| - Effektive Entwicklung | |
| - Regelmäßiges Einfließen von Rückmeldungen | |
| - Nachteile: | |
| - Kein Lernen über Teamgrenzen | |
| - Agile Methoden | |
| - Agile Manifest: | |
| - Individuen und Interaktionen wichtiger als Prozesse und Werkzeuge | |
| - Laufende Software wichtiger als vollständige Dokumentation | |
| - Kundenmitarbeit wichtiger als Vertragsverhandlung | |
| - Einstellen auf Änderungen wichtiger als Verfolgen eines Plans | |
| - Etwaiger Prozess: | |
| - Dauerhafte Planung und Entwicklung inkrementell mit dauerhaft verfügbarem Kunden | |
| - Dokumente werden vermieden | |
| - Extreme Programming: | |
| - Paarprogrammierung: Paarentwicklung am gleichen PC, höhere Kosten, höhere Qualität aber bei erfahrenen Entwicklern eher nutzlos | |
| - Effizientes Testen: | |
| - Testen zeitnah nach Programmierung | |
| - Häufig und viele Komponententests durch Entwickler | |
| - Akzeptanztests nach Spezifikation vom Kunden | |
| - TDD: | |
| - Testcode vor Implementation | |
| - Jede Verhaltensänderung am Quelltext durch Test motivieren | |
| - Integriere häufig | |
| - Resultate: | |
| - Vorhandene Funktionalität wird gesichert | |
| - Entwurf entsteht Stück für Stück | |
| - Viele Stummel nötig | |
| - Code muss stärker modularisiert werden | |
| - Tests als ausführbare Spezifikation und Dokumentation | |
| - Eventuell falsches Gefühl von Sicherheit | |
| - Refactoring: | |
| - Interne Struktur verbessern (vereinfachen) | |
| - Benötigt automatische Tests | |
| - Einfachste Form: | |
| - Alle Tests erfüllt | |
| - Wird einfach verstanden | |
| - Ist explizit | |
| - Enthält keine Duplikation | |
| - Hat wenige Klassen und Methoden | |
| - Bad smells: | |
| - Duplizierter Programmtext | |
| - Parallele Vererbungsbäume | |
| - Kaskadierende Änderungen bei neuen Funktionen | |
| - Kommentare, die schlechten Code kompensieren | |
| - Inkrementelles Design: Kleine inkrementelle Entwurfsschritte statt großer Entwurfsphase | |
| - Planungsspiel: | |
| - Planung der nächsten Iteration und der nächsten Auslieferung | |
| - Rollen: | |
| - Kunde entscheidet Umfang Prioritäten und Deadlines | |
| - Entwicklungsteam schätzt Kosten, Risiko, Konsequenzen und entscheidet Entwicklungsprozess | |
| - Auslieferungsplanung: | |
| - Dauer: 1-4 Monate | |
| - Prozess: | |
| - Kunde äußert Wünsche | |
| - Team schätzt Kosten und Risiken | |
| - Kunde priorisiert Wünsche | |
| - Team stellt Zeitplan auf | |
| - Iterationsplanung: | |
| - Planung für 1-4 Wochen | |
| - Aufteilung von Anwendungsfällen in kleinere Aufgaben | |
| - Zusammenlegen kleinerer Aufgaben | |
| - Identifizierung zusätzlicher Aufgaben | |
| - Aufgaben werden Entwicklern zugewiesen | |
| - Rückkopplung zum Kunden | |
| - Kritik: | |
| - Fehlende Dokumentation | |
| - Nicht reproduzierbarer Prozess | |
| - Dauerhafte Mitarbeit von Kundem benötigt | |
| - Eher praktisch für kleinere Teams | |
| - Scrum: | |
| - Prozess: | |
| - Anforderungsliste: | |
| - Priorisierung durch Kunden vor jedem Sprint | |
| - Aufgabenliste für aktuellen Sprint aus Anforderungsliste | |
| - Hindernisliste mit Problemen für Projekt | |
| - Aufgabenliste abarbeiten | |
| - Dauer: 2-4 Wochen | |
| - Tägliches Meeting | |
| - Auslieferbarer Produktteil | |
| - Rollen: | |
| - Auftraggeber: | |
| - Legt Anforderungen und Deadline fest | |
| - Akzeptiert Arbeitsergebnisse oder lehnt sie ab | |
| - Priorisiert Anforderungen und passt sie für jeden Sprint an | |
| - Scrum Master: | |
| - Sorgt für Einhaltung des Scrum-Plans | |
| - Beseitigt Hindernisse von Hindernisliste | |
| - Entwicklungsteam: | |
| - Organisiert sich selbst | |
| - Scrum-Treffen: | |
| - Sprintplanung: Auswahl der Anforderungen und Erstellung der Aufgabenliste vor jedem Sprint durch Entwicklungsteam | |
| - Themen des täglichen Scrum-Treffen: | |
| - Gestrige Arbeit | |
| - Heutige Arbeit | |
| - Hindernisse | |
| - Review-Treffen am Ende eines Sprints: Ergebnisse des Sprints durch direkte Demonstration (keine Folien!) | |
| - Retrospektive: Analyse des vergangenen Sprints durch Team, Scrum Master und Kunden | |
| ... Und das wäre alles, was ich zum Thema "Softwaretechnik" zu sagen habe. ... | |
| ... | |
| ... | |
| ... | |
| ... Nevermind, es gibt ja noch SWT2. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment