Fichas
Software Engineering I
Fichas del conjunto (96)
- 1Komplexitätstheorieexponentiell: k^n
polynominal: n^k
logarithmisch: log n
linear: n
konstant: 1 - 2Darstellungsarten von Endliche AutomatenDiagramm
Tabelle
Matrix - 3TransduktorenMealy-Automat
Moore-Automat - 4Mealy Automat- Ausgabe bei jedem Zustandsübergang
- relativ wenige Zustände
- Wahl der Ausgabe: aktueller Zustand + Eingabe - 5Moore-Automat- Ausgabe bei Erreichen eines Zustands
- eher mehr Zustände, aber bei gleicher Anzahl dafür weniger verschiedene Ausgaben
- Wahl der Ausgabe: neuer Zustand
- übersichtlicher, wenn alle Ausgaben bei jeweils einem Zustand gleich sind - 6Akzeptorohne Ausgabe
nur Endzustände - 7Mutexwechselseitiger Ausschluss
Wer darf zuerst?
Philosophen Problem - 8Race ConditionGeschwindigkeit der Verarbeitung beeinflusst das Ergebnis
besonders bei verteilten Systemen oder nebenläufiger Programmierung - 9SemaphoreVerwaltung von Ressourcen
abstrakte Datenstruktur
konkurrierende (CPU-Zeit) und kooperative Semaphore (Erzeuger-Verbraucher)
löst das Erzeuger-Verbraucher-Problem - 10Connection Pooling (Probleme)Leaks: Ressourcen nicht freigegeben
Starvation: Ressourcen zu spät zugeteilt
Deadlocks: Threads blockieren sich gegenseitig - 11Synchronisationüber Callback geregelt:
Aufruf einer Funktion, welcher eine andere Funktion als Parameter übergeben wird.
Aufruf eines Buchungssystems, welches außerhalb des aktuellen Programms liegt; Warten auf Antwort des Callbacks - 12Callback (Probleme)- Wie lange wartet man?
- Nachrichten können verloren gehen
- fehlerhafte oder nicht erreichbare Systeme
- Race Conditions - 13AbstraktionWeglassen irrelevanter Details
Konzentration auf das Wesentliche - 14KapselungGeheimnisprinzip / Sichtbarkeit
Zugriff auf Daten nur über Methoden (GET/SET) - 15VererbungErweiterung durch Spezialisierung
Subklasse erbt alle Merkmale der Superklasse - 16PolymorphismusAustauschbarkeit
Gleiche Schnittstelle, anderes Verhalten
überschriebene Methoden - 17KohäsionMaß für die Verantwortlichkeiten der Bestandteile einer Komponente
starke Kohäsion: eine Komponente - eine Aufgabe
schwache Kohäsion: eine Komponente - viele Aufgaben - 18KopplungMaß für die Abhängigkeit zwischen Komponenten
lose Kopplung: Änderung an der Komponente beeinflussen andere Komponenten nicht
kann nie auf 0 gebracht werden - 19DRY (Don't repeat yourself)Vermeidung von dupliziertem Code
Fehler müssen sonst an mehreren Stellen verbessert werden - 20SOC (Seperation of concerns)Eine Komponente soll genau eine Aufgabe/Verantwortlichkeit haben (hohe Kohäsion)
Eine Komponente soll so wenig wie möglich von anderen abhängen (lose Kopplung) - 21SRP (Single Responsibility Principle)es sollte nur einen Grund geben eine Klasse zu ändern
ansonsten hätte die Klasse mehrere Verantwortungen
(Auto Beispiel: Was sind die zentralen Aufgaben eines Autos?) - 22OCP (Open Closed Principle)Klassen sollen offen gegenüber Erweiterungen sein, aber geschlossen gegenüber Veränderungen
Verwendung von abstrakten Basisklassen
Klassen sind somit robuster - 23LSP (Liskov Substitution Principle)Ein Programm, welches Objekte der Basisklasse verwendet, soll auch mit Objekten einer davon abgeleiteten Klasse umgehen können
Verhalten der Methoden bei einer Vererbung beachten
(Quadrat - Rechteck - Beispiel) - 24ISP (Interface Segregation Principle)Clients sollen nicht gezwungen werden Interfaces zu implementieren, die sie nicht benötigen
Vermeidung von Interface Pollution
Wenn eine Klasse ein Interface implementiert, dann braucht es die darin vorhandenen Methoden auch wirklich - 25DIP (Dependency Inversion Principle)Module höherer Ebene sollten nicht von Modulen niedrigerer Ebene abhängen
Das Modul höherer Ebene definiert eine Schnittstelle, mit der es arbeitet. Module niedrigerer Ebene realisieren die Schnittstellen
beide sollten also von Abstraktionen abhängen
(Schalter - Lampe - Beispiel) - 26SDP (Stable Dependencies Principle)Abhängigkeiten zwischen Packages sollten in der selben Richtung wie die Stabilität verlaufen
Stabilität = ausgehende Kopplung / totale Kopplung
Packages sollten nur von Packages abhängen, welche stabiler sind als es selbst
= 0 --> stabiles Package
= 1 --> instabiles Package - 27SAP (Stable Abstraction Principle)Packages, die maximal stabil sind, sollten auch maximal abstrakt sein (und umgekehrt)
Abstraktheit = #abstrakte Klassen / #alle Klassen
= 0 --> konkretes Package
= 1 --> abstraktes Package - 28Zone of Painstabile, nicht abstrake Klassen
Stabilität = 0 und Abstraktion = 0
Diese Komponenten sind schwer zu verändern - 29Zone of Uselessnessinstabile und abstrakte Klassen
Stabilität = 1
Abstraktheit = 1
Klassen sind abstrakt, werden aber nirgends erweitert - 30Definition einer Sprache1) Eigenschaftsspezifikation (verbale Beschreibung)
2) Erzeugungsverfahren (Grammatiken)
3) Erkennungsverfahren (Erkennen durch Automaten) - 31GrammatikGrammatik G bestehend aus:
- Menge N aus Nonterminalsymbolen (Variablen)
- Terminalsymbole (Zeichenvorrat)
- endliche Menge an Produktionen
- Startvariabel S aus N - 32ProduktionAbleitungen einzelner Bestandteile in neue Bestandteile
- 33Syntaxbaumauch: Ableitungsbaum
stelle Produktion grafisch als Baumstruktur dar - 34Chomsky Typ 3: Reguläre Sprachen- erzeugt durch reguläre Grammatiken
- Produktionen haben die Form: - 35Endliche Automaten in Bezug auf Grammatiken1) Für jede reguläre Grammatik gibt es einen nichtdeterministischen endlichen Automaten
2) Jeder nichtdeterministische endliche Automat ist in einen deterministischen endlichen Automaten überführbar
3) Zu jedem deterministischen endlichen Automaten gibt es eine reguläre Grammatik - 36Chomsky Typ 2: Kontextktfreie SpracheBsp.: Programmiersprachen
Definition:
- 37SyntaxdiagrammeRechtecke: Nonterminalsymbole
Ovale: Terminalsymbole - 38Backus-Naur-Form (BNF)formale Metasprache
- 39EBNFDefinition: =
Aufzählung: ,
Terminalsymbol: "text"
Nonterminalsymbol: nichts spezielles
Alternative: |
Option: []
Wiederholung {}
Ende einer Regel: ;
Gruppierung: () - 40Abstrakter SyntaxbaumWeglassen von:
- Knoten
- Klammern
- Zwischenschritten
Anreicherung, z.B. Variablen Deklaration
Bsp.: DOM - 41SingletonVon einer Klasse soll es nur eine Instanz geben
- 42Factory MethodEin Objekt wird durch Aufruf einer Methode anstatt durch direkten Aufruf eines Konstruktors erzeugt.
Product <-- Concrete Product
Creator <-- Concrete Creator - 43Abstract FactorySchnittstelle zur Erzeugung einer Familie von Objekten, wobei die konkreten Klassen der zu instanziierenden Objekte nicht näher festgelegt werden.
Definition einer zusammenhängenden Familie aus Produkten - 44FacadeUnterteilung eines komplexen Systems in mehrere einfache Subsysteme
Facade als high-level-interface, um das Subsystem leichter nutzen zu können - 45DecoratorHinzufügen / Entfernen von Funktionalitäten über eine Schnittstelle
- 46AdapterÜbersetzung einer Schnittstelle in eine andere.
Kommunikation von Klassen mit zueinander imkompatiblen Schnittstellen wird ermöglicht - 47Template MethodTeilschritte eines Algorithmus können variabel gehalten werden
Definition einer Schablone, die ähnliche Algorithmen implementiert und einzelne Ausführungsschritte an Unterklassen delegiert - 48Strategydefiniert eine Familie austauschbarer Algorithmen
bei vielen ähnlichen Klassen, die sich nur im Verhalten unterscheiden, können diese durch gemeinsame Strategy-Schnittstelle - 49ObserverWenn ein Objekt seinen Zustand ändert, erfahren dies alle abhängigen Objekte und werden direkt aktualisiert. Bsp.: Wenn die Veränderung eines Objekts die Modifikation eines oder mehrerer Objekte nötig macht
- 50JSONeinfaches Modell, welches insbesondere für Webtechnologien eingesetzt wird
leicht lesbare Syntax
Praktisch: siehe Aufgabe und Skript - 51JSON - Beispiel
- 52XML (wohlgeformt)Wohlgeformt:
- geordnete, syntaktische Eigenschaften
- alle Elemente haben öffnendes und schließendes Tag
- ein Wurzelelement
- nur ein Wert pro Attribut - 53XML (Validierung)valid: es folgt einem Schema
--> DTD oder XML Schema
Einschränkungen der Elementnamen oder der Sturktur
ergänzend zur Wohlgeformtheit - 54DTD- beschreibt ein Dokument
- inhaltliche Einschränkungen
eigene Syntax, kein XML
Syntax:
(a,b,c): Liste von Unterelementen
(a|b|c): Alternativen
Kardinalitäten: * + ?
Attribute:
Zusätze: #REQUIRED, #IMPLIED, Default-Wert - 55XML SchemaSchema selbst ist wieder ein XML
simpleType:
- auf Basis von base (ähnlich Vererbung)
- restriction: Einschränkung bzgl. Wertebereich, Aufzählung, Muster, Länge
- sequence: entspricht (A,B) bei DTD
- choice: entspricht (A|B) bei DTD
- all: beliebige Reihenfolge
-Kardinalitäten: minOccurs, max Occurs
Attribute: - 56DOMDarstellung von XML als Baum-Struktur
Root: Wurzelknoten
Children: Kindknoten
Parent: Elternknoten
previous/next Sibling: Knoten mit gemeinsamen Parent
Methoden:
- Navigation
- Manipulation
- Serialisierung (DOM in XML wandeln) - 57XPathbestehend aus Location Steps
/Achse::node [prädikat]
Achse: child, self, parent, attribute
Node Test: auf Knotenname, *, comment()
Prädikat: [1]: wählt erstes Element aus, [@lang='de'] wählt ELement mit dem Wert "de" für lang Attribut aus - 58XQueryFLOWR-Ausdrücke:
for: Iterationsvariable
let: Nicht-iterierende Varibale
where: einschränkende Bedingungen
order by: Sortierung
return: Einbettung - 59XSLTPrinzip:
1) Einlesen eines Dokumens
2) Vorbereitung Zielbaum
3) Transformationen (Template Rules) bestimmen welche Inhalte was im Zielbaum bewirken
Template Rules:
- bestehend aus Pattern zum matchen und Template für Änderungen
value-of: extrahiert den Wert des Knotens, alternativ: username = {@username} - 60XSLT - weitere Anweisungen
- 61XSLT - Conflict ResolutionWenn Knoten von mehreren Templates gematched
--> importierte Regeln: niedrigste Priorität
--> spezifischere Patterns haben höhere Priorität als unspezifischere
--> mehrere gleichberechtigte Patterns/Regeln führen zu einem Fehler - 62Software Infrastruktur- Konfigurationsmanagement (Verwaltung der Artefakte)
- Build-Automatisierung (automat. Erzeugen und Zusammenfügen von Komponenten)
- Testautomatisierung
- Defektmanagement - 63Management-Prozesse- Vorgehensmodelle (grundlegende Arbeitsweise)
- Reifegradmodelle (objektive Analyse und Optimierung der Prozesse) - 64Konstruktive QSArbeitstechniken und Tätigkeiten die zur Erfüllung der Anforderungen angewendet werden
Prozess im Fokus
Fehlervermeidungsstrategie
- Software-Richtlinien: Programmiersprache, Best-Practices
- Typisierung: Verwendung typisierter Programmiersprachen
- Vertragsbasierte & Fehlertolerante Programmierung:
- Dokumentation - 65Analytische QSgeplante und systematische Tätigkeiten
Produkt im Fokus
Fehlerfindungsstrategie
- statischer Test
- dynamischer Test - 66Statischer TestSoftware wird nicht ausgeführt
- Software-Metriken: quantitative Erfassung von Qualitätsmerkmalen
- Anomalie-Analyse: Entdecken von Unstimmigkeiten im Programmablauf (nicht verwendete Objekte)
- Manuelle Software-Prüfung: Review - 67Dynamischer TestSoftware wird ausgeführt
- BlackBox Test: Code muss nicht bekannt sein, Ableitung der Testfälle aus Spezifikation
- WhiteBox-Test: Code ist bekannt, Ableitung der Testfälle aus Codestruktur
- GreyBox Test: vereint Vorteile von BlackBox und WhiteBox Tests, TDD
- Akzeptanztest: BlackBox Test zur Überprüfung der Anforderungen - 68BlackBox-Test (Vor- und Nachteile)
- 69WhiteBox-Test (Vor- und Nachteile)
- 70TDDTestgetriebene Programmierung: jede Verhaltensänderung am Code wird durch automatisierten Test motiviert
Refactoring: Code in einfacher Form und Design wird Schritt für Schritt während der Programmierung entwickelt
Häufige Integration
Warum TDD?
- sichert den Erhalt der Funktionen bei Erweiterung
- Refactoring verlängert produktive Lebensdauer der Software
- Code lässt sich im Nachhinein oft schlechter testen - 71TDD - Ablauf
- 72Unit TestTesten einzelner Komponenten
Nutzen:
- Änderungen können sofort überprüft werden
- kürzere Entwicklungszeiten
- einfachere Dokumentation
Voraussetzungen:
- einfache Implementierung
- schnelle & automatisierte Ausführung der Tests - 73Integrationstest- Prüft zusammengesetzte Programmeinheiten in ihrer Interaktion
- Schnittstellentest - 74RegressionstestFolgefehler und Seiteneffekte in einer neuen Version von Software erkennen
Problem:
- Programmänderungen können unerwünschte Nebenwirkungen oder neue Fehler mit sich bringen
Vorgehensweise:
- Wiederholung von bereist durchgeführten Tests mit gleichen Eingaben
- als Unit-Test oder Integrationstest möglich
Annahmen:
- Änderungen sind geringfügig
- Programm war vorher möglichst fehlerfrei - 75Continious Integration- regelmäßiges und vollständiges Bauen, Testen und Verteilen einer Anwendung
- frühes und häufiges Einchecken von Änderungen
- inkrementelle und funktionsfähige Änderungen
- bei Änderung wird Gesamtsystem neu gebaut und automatisch getestet - 76Continious DeliveryAutomatisierung aller Schritte bis zur produktiven Auslieferung einer Software
automatisierte Deployments
bei jedem neuen Einchecken von Änderungen werden automatisiert Unit- und Integrationstests durchgeführt und evtl. direkt deployed
jederzeit steht ein deploy-bereiter Zustand der Software zur Verfügung
Voraussetzungen:
- CI muss etabliert sein
- regelmäßige Commits und automatisierte Tests müssen durchgeführt werden - 77Adressierte Risiken (CI+CD)- späte Fehlerbehebung
- schlechte Code-Qualität
- nicht oder erst spät verfügbare ausführbare Software
- mangelnde Transparenz - 78Voraussetzungen CI + CD- gemeinsame Codebasis
- automatisierte Kompilierung
- kontinuierliche Test-Entwicklung
- häufige Integration
- kurze Testzyklen
- Testumgebung (falls möglich)
- automat. Reporting & Deployment - 79Wasserfallmodell
- 80V-Modell- basierend auf Wasserfallmodell
- V-förmiger Aufbau
- jeder Entwicklungsphase steht eine Testphase gegenüber
- Erhöhung der Testabdeckung - 81Iterativ vs. inkrementelliterativ: in Zyklen, reagieren auf Änderungen
inkrementell: kleine Einheiten fertigstellen und nacheinander bearbeiten - 82Requirements Engineering (RE)Anforderungen ermitteln, spezifizieren und analysieren, validieren sowie abnehmen
Artefakte: Lastenheft, Pflichtenheft - 83LastenheftAnforderungsspezifikation durch Auftraggeber
Aufbau:
1) Visionen und Ziele
2) Rahmenbedingungen
3) Kontext und Überblick
4) Funktionale Anforderungen
5) Qualitätsanforderungen - 84Pflichtenheftvom Auftragnehmer erstellt, beschreibt die Realisierung aller Anforderungen auf fachlicher Ebene
Aufbau:
1) Visionen und Ziele
2) Rahmenbedingungen
3) Kontext und Überblick
4) Funktionale Anforderungen
5) Qualitätsanforderungen
6) Abnahmekriterien
7) Subsystemstruktur (optinal)
8) Glossar - 85RE-Prozessals eigenständige Entwicklungsphase
entwicklungsbegleitend
produktübergreifend - 86RE RahmenbedingungenOrganisatorisch:
- Anwendungsbereiche
- Zielgruppen
- Betriebsbedingungen
Technisch:
- Soft- und Hardware
- Zugriff auf andere Systeme - 87Kontext und ÜberblickSystemgrenze: was gehört zum System und was nicht
Kontext: relevante Umgebung für das System
Abgrenzung: was gehört nicht dazu - 88funktionale vs nicht-funktionale Anforderungenfunktionale:
- eine bereitzustellende Funktion
-Use Cases
nicht-funktional:
- Qualitätsmerkmale
- Performance
- Verfügbarkeit - 89Abnahmekriterien3 Stufen:
1) Ausgangssituation
2) Ereignis
3) Erwartetes Ergebnis - 90Agiles VorgehenAnforderungen in Form von User Stories
INVEST-Modell:
Independent
Negotiable
Valuable
Estimatable
Small
Testable
"As a ROLE I want to GOAL, so I can REASON" - 91SchätzverfahrenAnalogiemethode: anhand bereits abgeschlossener Projekte
Expertenschätzung: durch Erfahrung
Bottom-Up: Expertenschätzung auf unterer Ebene
Algorithmische Schätzung: z.B.: Function-Points-Methode - 92Implementierungbeinhaltet:
- Programmierung
- Dokumentation
- Testen - 93ProgrammierrichtlinienFormatierung: Abstände, Einrückung,...
Namens-Konventionen: In Englisch, Camel Case
Implementierungs-Dokumentation: JavaDoc, so wenig wie möglich, so viel wie nötig - 94Test & AbnahmeTest: Finden von Fehlern & Nachweis der Funktionalität
Abnahme: formale Abnahme: schriftlich Erklärung der Annahme eines Produkts - 95Testarten (ergänzend)Smoke-Test: kurzer, minimaler Test
Usability-Test: verstehen Anwender die Oberfläche?
Entwicklertest: während der Entwicklung von Entwicklern selbst durchgeführt, frühzeitiges Erkennen von Fehlern - 96Wartung vs. PflegePflege:
- Änderung, Erweiterung
- ist planbar
Wartung:
- ereignisgesteuert
Información
- Descripción
- Kein Anspruch auf Vollständigkeit
- Creado por
- daniel-eberwein
- Visitas
- 70
- Valoración