Implementierung hydrated
This commit is contained in:
parent
0469d41760
commit
cd79c0f4bd
Binary file not shown.
@ -914,17 +914,17 @@
|
||||
|
||||
Objektorientierter Feinentwurf
|
||||
\begin{itemize*}
|
||||
\item Grobdefinition der Architektur, Zerlegung in Subsysteme (evtl. unter Verwendung von Standardarchitekturen)
|
||||
\item OO-Modell für jedes Subsystem der Architektur
|
||||
\item OO-Modell für unterstützende Subsysteme unter Berücksichtigung gewählter Technologien
|
||||
\item Spezifikationen der Klassen
|
||||
\item Spezifikationen von externen Schnittstellen
|
||||
\end{itemize*}
|
||||
\item Grobdefinition der Architektur, Zerlegung in Subsysteme (evtl. unter Verwendung von Standardarchitekturen)
|
||||
\item OO-Modell für jedes Subsystem der Architektur
|
||||
\item OO-Modell für unterstützende Subsysteme unter Berücksichtigung gewählter Technologien
|
||||
\item Spezifikationen der Klassen
|
||||
\item Spezifikationen von externen Schnittstellen
|
||||
\end{itemize*}
|
||||
|
||||
\subsection{Klassen- und Objektentwurf}
|
||||
\begin{itemize*}
|
||||
\item Klassen der Lösungsdomäne
|
||||
\item Klassen, die nicht durch objektorientierte Analyse der Anwendungsdomäne entstehen
|
||||
\item Klassen, die nicht durch objektorientierte Analyse der Anwendungsdomäne entstehen
|
||||
\item Entstehungsgründe
|
||||
\begin{itemize*}
|
||||
\item Architektur von Software und System
|
||||
@ -1160,7 +1160,7 @@
|
||||
\item Ohne Sicht auf innere Implementierung
|
||||
\item Protokoll = Kollaboration von Protokollrollen
|
||||
\item Modell: Zustandsautomat
|
||||
\item Beschreibung der Synchronisation von Objekten
|
||||
\item Beschreibung der Synchronisation von Objekten
|
||||
\end{itemize*}
|
||||
|
||||
\subsection{Entwurfsmuster}
|
||||
@ -1240,7 +1240,7 @@
|
||||
\item Numerische Routinen, Simulation, ...
|
||||
\end{itemize*}
|
||||
\item Wird in Anwendung eingebunden (importiert), API
|
||||
\item Objekte instanziieren oder Klassen ableiten
|
||||
\item Objekte instanziieren oder Klassen ableiten
|
||||
\item Meist passiv: Kontrollfluss wird von Anwendung gesteuert
|
||||
\end{itemize*}
|
||||
|
||||
@ -1316,78 +1316,31 @@
|
||||
\item Untersuchung des Zeit- und Speicherbedarfs
|
||||
\item Test und Verifikation
|
||||
\end{itemize*}
|
||||
\item „Programmieren im Kleinen“
|
||||
\end{itemize*}
|
||||
|
||||
\subsection{Konventionen und Werkzeuge}
|
||||
Konventionen beim Programmieren
|
||||
\begin{itemize*}
|
||||
\item (Coding Rules, -conventions, -standards)
|
||||
\item Regeln für verständliche Programme
|
||||
\begin{itemize*}
|
||||
\item „wie“ sollte Quellcode formal und strukturell gestaltet sein
|
||||
\item Bezeichner, Einrückungen, Dokumentation, Dateien, ...
|
||||
\item Strukturierung: Block, Methode, Klasse, Package
|
||||
\end{itemize*}
|
||||
\item Firmenspezifische Regeln
|
||||
\begin{itemize*}
|
||||
\item Festlegung Entwurfsprinzipien (z.B. keine Mehrfachvererbung)
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
|
||||
Namenskonventionen
|
||||
\begin{itemize*}
|
||||
\item Klasse
|
||||
\begin{itemize*}
|
||||
\item (mit) Substantiv, „UpperCamelCase“
|
||||
\item Beispiele: Account, StandardTemplate
|
||||
\end{itemize*}
|
||||
\item Methode
|
||||
\begin{itemize*}
|
||||
\item (mit) Verb, Imperativ (Aufforderung), „lowerCamelCase“
|
||||
\item Beispiele: checkAvailability(), getDate()
|
||||
\end{itemize*}
|
||||
\item Attribut, Variable
|
||||
\begin{itemize*}
|
||||
\item (mit) Substantiv, „lowerCamelCase“
|
||||
\item Beispiele: anzahlAutos, fensterBreite
|
||||
\end{itemize*}
|
||||
\item Konstante
|
||||
\begin{itemize*}
|
||||
\item Nur Großbuchstaben, Worte mit "\_" zusammengesetzt
|
||||
\item Standardpräfixe: "MIN\_", "MAX\_", "DEFAULT\_", ...
|
||||
\item Beispiele: NORTH, BLUE, MIN\_WIDTH, DEFAULT\_SIZE
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
\begin{description*}
|
||||
\item[Klasse] (mit) Substantiv, „UpperCamelCase“
|
||||
\item[Methode] (mit) Verb, Imperativ (Aufforderung), „lowerCamelCase“
|
||||
\item[Attribut, Variable] (mit) Substantiv, „lowerCamelCase“
|
||||
\item[Konstante] Nur Großbuchstaben, Worte mit "\_" zusammengesetzt
|
||||
\end{description*}
|
||||
|
||||
Formatierungs-Richtlinien
|
||||
\begin{itemize*}
|
||||
\item Entsprechend Schachtelungstiefe einrücken, aber nicht zu weit
|
||||
\item Einheitliche Verwendung von Leerzeilen und Leerzeichen
|
||||
\item Einheitliche Dateistruktur verwenden
|
||||
\begin{itemize*}
|
||||
\item Eine .java-Datei pro Klasse
|
||||
\item Ein Verzeichnis für jedes package
|
||||
\end{itemize*}
|
||||
\item Werkzeuge: source beautifier, oft in IDEs enthalten
|
||||
\item Editor: syntax highlighting
|
||||
\item Navigationswerkzeuge
|
||||
\begin{itemize*}
|
||||
\item Auf- und Zuklappen, Inhaltsverzeichnis, tagging
|
||||
\item doxygen, Eclipse etc.
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
|
||||
Änderungsfreundlicher Code
|
||||
\begin{itemize*}
|
||||
\item Wahl von Variablen, Konstanten und Typen orientiert an der fachlichen Aufgabe, nicht an der Implementierung:
|
||||
\begin{itemize*}
|
||||
\item `typedef char name [NAME\_LENGTH]`
|
||||
\item `typedef char firstName [FIRST\_NAME\_LENGTH]`
|
||||
\end{itemize*}
|
||||
\item Wahl von Variablen, Konstanten und Typen orientiert an der fachlichen Aufgabe, nicht an der Implementierung
|
||||
\item Symbolische Konstanten statt literaler Werte verwenden, wenn spätere Änderung denkbar
|
||||
\item Algorithmen, Formeln, Standardkonzepte in Methoden/Prozeduren kapseln
|
||||
\item Übersichtlichkeit: Zusammenhängende Einheit nicht größer als Editorfenster (40-60 Zeilen, 70 Zeichen breit)
|
||||
\item Übersichtlichkeit: Zusammenhängende Einheit nicht größer als Editorfenster
|
||||
\item Strukturierte Programmierung (Regeln je nach Schärfe)
|
||||
\begin{itemize*}
|
||||
\item Kein goto verwenden (in anderen Sprachen als Java)
|
||||
@ -1397,171 +1350,71 @@
|
||||
\item return nur am Ende zur Rückgabe des Werts
|
||||
\end{itemize*}
|
||||
\item Übersichtliche Ausdrücke
|
||||
\begin{itemize*}
|
||||
\item Seiteneffektfreie Ausdrücke, schlecht: y += 12*x++;
|
||||
\end{itemize*}
|
||||
\item Variablen möglichst lokal und immer private deklarieren
|
||||
\item Wiederverwendung "äußerer" Namen vermeiden
|
||||
\end{itemize*}
|
||||
|
||||
Werkzeuge
|
||||
\begin{itemize*}
|
||||
\item Integrated Development Environments (Eclipse, KDevelop)
|
||||
\item Compiler, Linker; Build / Make; Versionskontrolle (git, svn)
|
||||
\end{itemize*}
|
||||
|
||||
\subsection{Code-Qualität}
|
||||
Portierbarer Code
|
||||
\begin{itemize*}
|
||||
\item Code, den man ohne Änderungen in ein anderes System (Compiler, Betriebssystem, Rechner) übertragen kann
|
||||
\item Portierbarer Code: ohne Änderungen in anderes System (Compiler, Betriebssystem, Rechner) übertragen kann
|
||||
\item Implementierungsabhängiges Verhalten
|
||||
\begin{itemize*}
|
||||
\item Kein implementierungsabhängiges Verhalten!
|
||||
\end{itemize*}
|
||||
\item ANSI C++ Standard ist nicht vollständig definiert
|
||||
\begin{itemize*}
|
||||
\item Ist das Verhalten nicht festgelegt, unterscheidet der ANSI C++ Standard zwischen:
|
||||
\item Implementierungsabhängigem, unspezifiziertem oder undefiniertem Verhalten
|
||||
\item Code, welcher auf implementierungsabhängigem, unspezifiziertem oder undefiniertem Verhalten basiert, ist
|
||||
\item Nicht portabel und somit häufig verboten
|
||||
\item Wird unter Umständen ungewollt wegoptimiert
|
||||
\item Compiler übersetzen Sprachkonstrukte unterschiedlich
|
||||
\item Verhalten ist konsistent festgelegt und dokumentiert
|
||||
\item Kompilierung von standardkonformem Code ist erfolgreich
|
||||
\item char kann signed oder unsigned sein: Nicht damit rechnen!
|
||||
\end{itemize*}
|
||||
\item Sicherer Code mit const
|
||||
\begin{description*}
|
||||
\item[Const Variable] Stellt sicher, dass sich der Wert nicht verändert
|
||||
\item[Const Parameter] Übergabeparameter ändert sich nicht
|
||||
\item[Const Operationen] Sicherstellen, dass Operation das Exemplar nicht ändert
|
||||
\end{description*}
|
||||
\end{itemize*}
|
||||
|
||||
Implementierungsabhängiges Verhalten
|
||||
\begin{itemize*}
|
||||
\item Compiler übersetzen bestimmte Sprachkonstrukte unterschiedlich, Ergebnis unterscheidet sich
|
||||
\item Voraussetzung:
|
||||
\item Verhalten ist konsistent festgelegt und dokumentiert
|
||||
\item Kompilierung von standardkonformem Code ist erfolgreich
|
||||
\item Beispiel: Speichergröße von Integer-Typen
|
||||
\item char kann signed oder unsigned sein: Nicht damit rechnen!
|
||||
\item 32 Bit System ist wie erwartet
|
||||
\item 16 Bit System: Multiplikation wird mit int durchgeführt $\rightarrow$ Überlauf $\rightarrow$ undefiniertes Verhalten
|
||||
\end{itemize*}
|
||||
|
||||
\begin{itemize*}
|
||||
\item Unspezifiziertes Verhalten:
|
||||
\item Wie implementierungsabhängiges Verhalten
|
||||
\item Compiler muss sich für ein bestimmtes Verhalten entscheiden
|
||||
\item Muss nicht dokumentiert sein
|
||||
\item Beispiel: Evaluierungsreihenfolge von Funktionsargumenten `tuWas(zuerstDas(),oderDochLieberDas());`
|
||||
\item Undefiniertes Verhalten:
|
||||
\item Keinerlei Vorgaben
|
||||
\item Compiler muss mögliches Problem nicht melden
|
||||
\item Keine Voraussage welches Resultat eintritt
|
||||
\item Bereits die Kompilierung kann fehlschlagen
|
||||
\item Oder das laufende Programm kann falsche Resultate liefern.
|
||||
\item Effekt: „Bei mir läuft es aber!?“
|
||||
\item „undefiniertes Verhalten nutzen grenzt an Sabotage!“
|
||||
\end{itemize*}
|
||||
|
||||
Sicherer Code mit const
|
||||
\begin{itemize*}
|
||||
\item Const Variable - Konstante
|
||||
\begin{itemize*}
|
||||
\item Stellt sicher, dass sich der Wert nicht verändert
|
||||
\end{itemize*}
|
||||
\item Const Parameter
|
||||
\begin{itemize*}
|
||||
\item Übergabeparameter ändert sich nicht innerhalb der Operation
|
||||
\item Z.B. bei Übergabe komplexer Daten als Referenz bzw. Zeiger `long calcMeanValue(const image \&i){...}`
|
||||
\end{itemize*}
|
||||
\item Const Operationen
|
||||
\begin{itemize*}
|
||||
\item Sicherstellen, dass Operation das Exemplar nicht ändert
|
||||
\item Aufruf der const Operation bei const Variablen möglich
|
||||
\end{itemize*}
|
||||
\item Verwende const wenn möglich
|
||||
\end{itemize*}
|
||||
|
||||
|
||||
\subsection{Dokumentation}
|
||||
\begin{itemize*}
|
||||
\item Selbstdokumentierende Programme?
|
||||
\begin{description*}
|
||||
\item[Integrierte] Dokumentation
|
||||
\begin{itemize*}
|
||||
\item 2001 Int. Obfuscated C Code Contest Winner, Short Program
|
||||
\item Verständlichkeit, Wartbarkeit - auch für Programmierer!
|
||||
\item Code selbst sollte möglichst verständlich sein
|
||||
\item Dokumentation in Programm schreiben und aktualisieren
|
||||
\item Beschreibung der Bedeutung des Codes!
|
||||
\item Als Konventionen festschreiben
|
||||
\item Programmvorspann
|
||||
\item Kurzbeschreibung Datei / Klasse / Funktion ...
|
||||
\item Verwaltungsinformationen
|
||||
\item Laufende Kommentare im Quellcode
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
|
||||
Integrierte Dokumentation
|
||||
\begin{itemize*}
|
||||
\item Verständlichkeit, Wartbarkeit - auch für Programmierer!
|
||||
\item Code selbst sollte möglichst verständlich sein
|
||||
\item Dokumentation in Programm schreiben und aktualisieren
|
||||
\item Beschreibung der Bedeutung des Codes!
|
||||
\item Als Konventionen festschreiben
|
||||
\item Programmvorspann
|
||||
\item Kurzbeschreibung Datei / Klasse / Funktion ...
|
||||
\item Verwaltungsinformationen
|
||||
\item[Programmierer] Dokumentation
|
||||
\begin{itemize*}
|
||||
\item Autor, Datum, Version, Projekt, ToDo, FixMe, ...
|
||||
\item Zustand: geplant, in Bearbeitung, vorgelegt, akzeptiert
|
||||
\item Als eigenes Dokument elektronisch oder gedruckt
|
||||
\item Einstieg in Programmverständnis (z.B. Bachelor-Arbeit)
|
||||
\item Konsistenz mit Quelltext? Verweise?
|
||||
\item Technische Unterstützung: JavaDoc (Java), doxygen (C++)
|
||||
\item Ergänztes Java-Programm: Dokumentation HTML, PDF,
|
||||
\end{itemize*}
|
||||
\item Laufende Kommentare im Quellcode
|
||||
\end{itemize*}
|
||||
|
||||
Programmierer-Dokumentation
|
||||
\begin{itemize*}
|
||||
\item Als eigenes Dokument elektronisch oder gedruckt
|
||||
\item Einstieg in Programmverständnis (z.B. Bachelor-Arbeit)
|
||||
\item Konsistenz mit Quelltext? Verweise?
|
||||
\item Technische Unterstützung: JavaDoc (Java), doxygen (C++)
|
||||
\item Ergänztes Java-Programm: Dokumentation HTML, PDF,
|
||||
\end{itemize*}
|
||||
% ```js
|
||||
% /** @author name Mustermann */
|
||||
% /** @param name description */
|
||||
% /** @return description */
|
||||
% ```
|
||||
|
||||
Benutzerdokumentation
|
||||
\begin{itemize*}
|
||||
\item Benutzer-Handbuch, Online-Dokumentation
|
||||
\item Unterstützung ohne Support?
|
||||
\item Vollständige und fehlerfreie Beschreibung der Benutzung
|
||||
\item[Benutzer] Dokumentation
|
||||
\begin{itemize*}
|
||||
\item Beispiele, screen shots
|
||||
\item Benutzer-Handbuch, Online-Dokumentation
|
||||
\item Unterstützung ohne Support?
|
||||
\item Vollständige und fehlerfreie Beschreibung der Benutzung
|
||||
\item Arten: Tutorial, Beschreibung
|
||||
\end{itemize*}
|
||||
\item Arten: Tutorial, Beschreibung,
|
||||
\end{itemize*}
|
||||
|
||||
Benutzer-Unterstützungssysteme
|
||||
\begin{itemize*}
|
||||
\item Integrierte Hilfe (Suchfunktion, balloon help / tool tips)
|
||||
\item Assistenz-System (Zustandsabhängige Anleitung)
|
||||
\item Tutor-System zum Erlernen
|
||||
\item Bug-Listen, Mailinglisten, Diskussionsforen
|
||||
\end{itemize*}
|
||||
\end{description*}
|
||||
|
||||
\subsection{Codegenerierung}
|
||||
Bezug zwischen Modell und Programmcode
|
||||
\begin{itemize*}
|
||||
\item Vorwärtsmodellierung: Modell - Code
|
||||
\item Rückwärtsmodellierung: Code - Modell
|
||||
\begin{itemize*}
|
||||
\item Außerdem: Modelltransformation, Refaktorisierung
|
||||
\end{itemize*}
|
||||
\item Idealfall: Automatische Übersetzung durch SW-Werkzeug (in beiden Richtungen)
|
||||
\begin{itemize*}
|
||||
\item „Modellbasierte Entwicklung“
|
||||
\end{itemize*}
|
||||
\item Statisch: Beispiel Klassendiagramm - Quelltext der Klassen mit allen Vererbungsbeziehungen, Attributen und Methodensignaturen (Klassen-Stümpfe mit leeren Methodenrümpfen zum Ausfüllen)
|
||||
\item Dynamisch: Beispiel Zustandsdiagramm - Quelltext der Zustandssteuerung einer Klasse
|
||||
\end{itemize*}
|
||||
|
||||
%
|
||||
|
||||
Weitere statische Transformationen
|
||||
\begin{itemize*}
|
||||
\item Abbildung von Assoziationen auf Sammlungen
|
||||
\item Abbildung von Verträgen auf Ausnahmen
|
||||
\item Abbildung von Objektmodellen auf Datenbankschemata
|
||||
\item Abbildung von Entwurfsmustern auf Codefragmente
|
||||
\item Modelltransformation, Refaktorisierung
|
||||
\item Idealfall: Automatische Übersetzung durch SW-Werkzeug
|
||||
\item Statisch: Quelltext der Klassen mit Beziehungen, Attributen...
|
||||
\item Dynamisch: Quelltext der Zustandssteuerung einer Klasse
|
||||
\end{itemize*}
|
||||
|
||||
Optimierung des Entwurfsmodells
|
||||
\begin{itemize*}
|
||||
\item Grund: nichtfunktionale Eigenschaften
|
||||
\item Zugriffspfade
|
||||
\item Klassen in Attribute umwandeln
|
||||
\item Verzögerung von Berechnungen
|
||||
@ -1572,41 +1425,18 @@
|
||||
\begin{itemize*}
|
||||
\item Einfachste Möglichkeit: Switch (Case) Statement
|
||||
\item Zustände werden durch Datenwerte repräsentiert
|
||||
\begin{itemize*}
|
||||
\item Aktueller Zustand: einzelne skalare Variable
|
||||
\end{itemize*}
|
||||
\item Jedes Ereignis wird durch Methode implementiert
|
||||
\item Ausgehend von aktivem Zustand wird bei Eintreffen eines Ereignisses der entsprechende Programmcode ausgeführt
|
||||
\item Abhängig von Zustandsvariable wird Aktion ausgeführt und der Folgezustand eingestellt
|
||||
\item Wird in einer Klasse realisiert
|
||||
\item Sinnvoll für einfache, “flache” Modelle
|
||||
\begin{itemize*}
|
||||
\item Sonst Logik für Hierarchie nötig
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
|
||||
Anpassung der Generierung
|
||||
\begin{itemize*}
|
||||
\item Verschiedene Zielsprachen (Java, C++, ...)
|
||||
\item Model2Text-Transformationen
|
||||
\begin{itemize*}
|
||||
\item Verschiedene Generatoren, z.B. Eclipse Modelling Project
|
||||
\end{itemize*}
|
||||
\item Generierung aus dem Modellierungswerkzeug
|
||||
\begin{itemize*}
|
||||
\item Parametrisierung der Codegenerierung
|
||||
\item Generierungsvorlagen
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
|
||||
Weitere Werkzeuge
|
||||
\begin{itemize*}
|
||||
\item Compiler-Compiler: Syntaxbeschreibung wird in lexikalische Analyse (tokenizer) und Syntaxanalyse-Programm transformiert (lex \& yacc / flex \& bison / antlr)
|
||||
\item Codegenerierung für grafische Benutzungsoberflächen aus grafischer Beschreibung: GUI toolkits
|
||||
\item XML-Parser
|
||||
\begin{itemize*}
|
||||
\item XSLT, DOM, SAX, ...
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
|
||||
\subsection{Implementierung aktiver Objekte}
|
||||
@ -1617,15 +1447,12 @@
|
||||
\end{itemize*}
|
||||
|
||||
Arten von Programmabarbeitung
|
||||
\begin{itemize*}
|
||||
\item Sequentiell: es gibt immer genau einen nächsten Schritt, alle Schritte werden nacheinander ausgeführt
|
||||
\item Parallel: Spezielle Hardware bzw. Mehrkernprozessor, mehrere Befehlsfolgen werden echt parallel bearbeitet
|
||||
\item Quasi-parallel: Ein Prozessor arbeitet mehrere Befehlsfolgen in freier Einteilung ab
|
||||
\item Nebenläufig: Oberbegriff für Parallel und Quasi-parallel
|
||||
\begin{itemize*}
|
||||
\item concurrent
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
\begin{description*}
|
||||
\item[Sequentiell] es gibt immer genau einen nächsten Schritt, alle Schritte werden nacheinander ausgeführt
|
||||
\item[Parallel] Spezielle Hardware bzw. Mehrkernprozessor, mehrere Befehlsfolgen werden echt parallel bearbeitet
|
||||
\item[Quasi-parallel] Ein Prozessor arbeitet mehrere Befehlsfolgen in freier Einteilung ab
|
||||
\item[Nebenläufig] Oberbegriff für Parallel und Quasi-parallel (concurrent)
|
||||
\end{description*}
|
||||
|
||||
Vorteile
|
||||
\begin{itemize*}
|
||||
@ -1640,71 +1467,7 @@
|
||||
\item Ein Programm, das bei gleichen Eingaben gleiche Ausgaben produziert, heißt determiniert (determined)
|
||||
\item Programme in üblichen Programmiersprachen sind sequentiell, deterministisch und determiniert
|
||||
\item Grund: Herkömmliche Programmiersprachen sind durch das von-Neumann-Modell geprägt
|
||||
\item Determinismus nicht notwendig für Determiniertheit!
|
||||
\begin{itemize*}
|
||||
\item Determiniertheit nebenläufiger Programme: Synchronisation
|
||||
\item Vermeidung von Schreib/Schreib und Schreib/Lese-Konflikten
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
|
||||
Java Threads
|
||||
\begin{itemize*}
|
||||
\item Verwaltung durch die Java Virtuelle Maschine (JVM)
|
||||
\item Realisierung der Threads ist je nach Implementierung der JVM unterschiedlich
|
||||
\begin{itemize*}
|
||||
\item Abbildung auf Betriebssystem-Threads (z.B. unter Windows weitverbreitet)
|
||||
\item Realisierung durch die JVM (z.B. unter Unix und in Java-fähigen Browsern)
|
||||
\item Nachteile: Keine Ausnutzung von Multiprozessorsystemen durch die VM; Zuteilungsstrategie für Threads ist in derzeitigen Implementierungen unterschiedlich
|
||||
\end{itemize*}
|
||||
\item Threads arbeiten immer im Adressraum der JVM (eigener Prozess) und sind außerhalb dieser nicht sichtbar
|
||||
\end{itemize*}
|
||||
|
||||
Erzeugung eines Threads
|
||||
\begin{itemize*}
|
||||
\item Unterklasse der Basisklasse „Thread“ bilden `class MyThread extends Thread`
|
||||
\item Problem: keine Mehrfachvererbung, daher Alternative nötig (Beispiel: Applet):
|
||||
\begin{itemize*}
|
||||
\item Schnittstelle „Runnable“ implementieren
|
||||
\item `class MyThread implements Runnable`
|
||||
\end{itemize*}
|
||||
\item Die vordefinierte Schnittstelle Runnable ist definiert als
|
||||
% ```java
|
||||
% public interface Runnable
|
||||
% { public abstract void run(); }
|
||||
% ```
|
||||
\end{itemize*}
|
||||
|
||||
Starten eines Threads
|
||||
\begin{itemize*}
|
||||
\item Eine Klasse, die Runnable implementiert, muss wie Unterklassen von Thread immer eine run()-Methode definieren
|
||||
\item Seiteneffekt der Runnable-Schnittstelle
|
||||
\begin{itemize*}
|
||||
\item Instanzen der Klasse werden nebenläufig zu den anderen laufenden Threads ausgeführt
|
||||
\item Ausführung beginnt mit der Methode run ()
|
||||
\end{itemize*}
|
||||
\item Ablauf
|
||||
\begin{itemize*}
|
||||
\item Thread-Objekt erzeugen
|
||||
\item Thread starten mit t.start()
|
||||
\item start() ruft implizit run() auf
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
|
||||
Synchronisation von Threads
|
||||
\begin{itemize*}
|
||||
\item Gezielte Einschränkung der Nebenläufigkeit
|
||||
\item Gründe
|
||||
\begin{itemize*}
|
||||
\item Zugriffsbeschränkung, gegenseitiger Ausschluss
|
||||
\item Abhängigkeiten, einseitige Synchronisation
|
||||
\end{itemize*}
|
||||
\item Methoden: Semaphore, Monitore, Schlossvariablen, ...
|
||||
\end{itemize*}
|
||||
|
||||
Java: Monitore
|
||||
\begin{itemize*}
|
||||
\item Zugriffsoperationen werden in Klassen zusammengefasst
|
||||
\item Gegenseitiger Ausschluss: Spezifikation der betroffenen Zugriffsoperation als synchronized
|
||||
\item Determiniertheit nebenläufiger Programme: Synchronisation
|
||||
\end{itemize*}
|
||||
|
||||
\subsection{Verifikation und Testen}
|
||||
@ -1713,127 +1476,68 @@
|
||||
\item Wissen, Erfahrung und Methodenkompetenz der Programmierer
|
||||
\item Projektstruktur, klare Verantwortlichkeiten
|
||||
\item Kosten- und Zeitdruck? Änderungen?
|
||||
\item Programmier- und Testmethoden
|
||||
\begin{itemize*}
|
||||
\item pair programming, code reading etc.
|
||||
\item Qualitätsverantwortlicher, automatisiertes Testen
|
||||
\end{itemize*}
|
||||
\item Technische Unterstützung
|
||||
\begin{itemize*}
|
||||
\item Z.B. Versionierung, Dokumentation, Testen, Entwicklungsumgebung
|
||||
\end{itemize*}
|
||||
\item Programmier- und Testmethoden (pair programming, code reading)
|
||||
\item Technische Unterstützung (Versionierung, Dokumentation, Testen)
|
||||
\end{itemize*}
|
||||
|
||||
Begriffe
|
||||
\begin{itemize*}
|
||||
\item Zuverlässigkeit: Maß für Übereinstimmung des Systemverhaltens mit Spezifikation
|
||||
\item Grund für Unzuverlässigkeit:
|
||||
\begin{itemize*}
|
||||
\item Fehler (bug, fault): fehlerhafter Programmcode o.ä.
|
||||
\item Der Begriff „Bug“:
|
||||
\begin{itemize*}
|
||||
\item Schon vor Computern als Begriff für Fehler benutzt
|
||||
\item Motte im Relais des Computers Mark II Aiken (1947)
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
\item Fehlerhafter Zustand (error): Fehler hat zur Laufzeit zu einem internen fehlerhaften Zustand geführt, der möglicherweise zu einem Ausfall führt
|
||||
\item Störfall, Ausfall (failure): Abweichung vom spezifizierten Verhalten, meist mit negativen Folgen
|
||||
\end{itemize*}
|
||||
\begin{description*}
|
||||
\item[Zuverlässigkeit] Maß für Übereinstimmung des Systemverhaltens mit Spezifikation
|
||||
\item[Unzuverlässigkeit] Fehler (bug, fault), fehlerhafter Programmcode
|
||||
\item[Fehlerhafter Zustand (error)] Fehler hat zur Laufzeit zu einem internen fehlerhaften Zustand geführt, der möglicherweise zu einem Ausfall führt
|
||||
\item[Störfall, Ausfall (failure)] Abweichung vom spezifizierten Verhalten, meist mit negativen Folgen
|
||||
\end{description*}
|
||||
|
||||
Vergleich System / Systemmodell
|
||||
\paragraph{Verifikation}
|
||||
\begin{itemize*}
|
||||
\item Anspruch guter Software: System entspricht Systemmodell (Korrektheit)
|
||||
\item Problem: System nicht vollständig automatisch erzeugbar!
|
||||
\item Auswege
|
||||
\begin{itemize*}
|
||||
\item Fehlervermeidung (Inspektion, pair programming, ...)
|
||||
\item Nachweis, dass System dem Modell entspricht - Verifikation
|
||||
\item Überprüfen, ob System dem Modell entspricht - Testen
|
||||
\item Fehlertoleranz (durch Redundanz)
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
|
||||
Verifikation
|
||||
\begin{itemize*}
|
||||
\item Mathematisch formaler Beweis, dass ein Programm einer Spezifikation genügt
|
||||
\item Mathematisch formaler Beweis genügt
|
||||
\item Vorteil: wenn anwendbar, dann vollständiger Beweis
|
||||
\item Problem: für viele (realistisch große) Fälle nicht anwendbar
|
||||
\begin{itemize*}
|
||||
\item Zu aufwändig
|
||||
\item Umgebung muss ebenfalls verifiziert werden
|
||||
\item Auch in der Theorie nicht immer entscheidbar: Halteproblem, Gödelscher Unvollständigkeitssatz
|
||||
\end{itemize*}
|
||||
\item Theoretische Informatik: Berechenbarkeitstheorie, formale Semantik; aktives Forschungsgebiet
|
||||
\begin{itemize*}
|
||||
\item model checking
|
||||
\end{itemize*}
|
||||
\item Theoretische Informatik: Berechenbarkeitstheorie, Semantik
|
||||
\end{itemize*}
|
||||
|
||||
Testen
|
||||
\begin{itemize*}
|
||||
\item Systematischer Versuch, Defekte in der Software zu finden
|
||||
\item Ingenieurtechnik zur Erhöhung des Vertrauens in Softwaresysteme, aber: unvollständig!
|
||||
\begin{itemize*}
|
||||
\item Kann nur die Anwesenheit von Fehlern nachweisen, aber nicht Korrektheit (Abwesenheit von Fehlern)!
|
||||
\end{itemize*}
|
||||
\item Ingenieurtechnik zur Erhöhung des Vertrauens
|
||||
\item Aufgabe: Unterschiede zwischen Modell und System finden
|
||||
\item Destruktiv im Gegensatz zu sonstigen SWE-Aufgaben
|
||||
\begin{itemize*}
|
||||
\item Daher sollten nicht (nur) Entwickler selbst testen
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
|
||||
Testplanung
|
||||
\begin{itemize*}
|
||||
\item Testen ist aufwändig, deshalb ist gute Planung nötig!
|
||||
\item Testplanung sollte bereits mit der Anforderungsanalyse beginnen und im Entwurf verfeinert werden (V-Modell, Test-First-Ansatz)!
|
||||
\item Testplanung sollte bereits mit der Anforderungsanalyse beginnen
|
||||
\item Typische Bestandteile einer Test-Spezifikation (Testdrehbuch)
|
||||
\begin{itemize*}
|
||||
\item Phasenmodell des Testprozesses
|
||||
\item Zusammenhang zur Anforderungsspezifikation, z.B. dort festgelegte Qualitätsziele
|
||||
\item Zusammenhang zur Anforderungsspezifikation
|
||||
\item Zu testende Produkte
|
||||
\item Zeitplan für die Tests
|
||||
\item Abhängigkeiten der Testphasen
|
||||
\item Aufzeichnung der Testergebnisse
|
||||
\item Hardware\item und Softwareanforderungen
|
||||
\item Hardware- und Softwareanforderungen
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
|
||||
Arten von Tests
|
||||
\begin{itemize*}
|
||||
\item Komponententest: Fehler in einzelnen Objekten oder Subsystemen, losgelöst vom umgebenden System
|
||||
\begin{itemize*}
|
||||
\item Umgebung muss nachgebildet werden
|
||||
\end{itemize*}
|
||||
\item Integrationstest: Zusammenspiel von Komponenten
|
||||
\begin{itemize*}
|
||||
\item Vollständiges System: Systemtest; Szenarios
|
||||
\end{itemize*}
|
||||
\item Strukturtest: innere Zustände, Interaktionen
|
||||
\item Funktionstest: Anforderungen aus Lastenheft
|
||||
\item Leistungstest: nichtfunktionale Anforderungen
|
||||
\item Benutzbarkeitstest: Fehler in der Benutzungsschnittstelle, Verständlichkeit, Akzeptanz bei Anwendern
|
||||
\begin{itemize*}
|
||||
\item Prototypen
|
||||
\end{itemize*}
|
||||
\item Akzeptanztest, Installationstest: Kunde, Abnahme
|
||||
\end{itemize*}
|
||||
\begin{description*}
|
||||
\item[Komponententest] Fehler in einzelnen Objekten oder Subsystemen, losgelöst vom umgebenden System
|
||||
\item[Integrationstest] Zusammenspiel von Komponenten
|
||||
\item[Systemtest] Vollständiges System; Szenarios
|
||||
\item[Strukturtest] innere Zustände, Interaktionen
|
||||
\item[Funktionstest] Anforderungen aus Lastenheft
|
||||
\item[Leistungstest] nichtfunktionale Anforderungen
|
||||
\item[Benutzbarkeitstest] Fehler in der Benutzungsschnittstelle, Verständlichkeit, Akzeptanz bei Anwendern
|
||||
\item[Akzeptanztest, Installationstest]: Kunde, Abnahme
|
||||
\end{description*}
|
||||
|
||||
Komponententests
|
||||
\begin{itemize*}
|
||||
\item Überprüft Verhalten einer Systemkomponenten im Vergleich zur Spezifikation
|
||||
\item Da Tests bereits frühzeitig stattfinden sollten, ist Umgebung meist nicht vollständig implementiert
|
||||
\begin{itemize*}
|
||||
\item Teststumpf (stub, dummy) simuliert aufgerufene Komponenten
|
||||
\item Teststumpf simuliert aufgerufene Komponenten
|
||||
\item Testtreiber simuliert aufrufende Komponenten
|
||||
\end{itemize*}
|
||||
\item Vorgehensweisen
|
||||
\begin{itemize*}
|
||||
\item Bottom-up
|
||||
\item Top-down
|
||||
\item Sandwich
|
||||
\item Schichtenweises Testen
|
||||
\end{itemize*}
|
||||
\item Vorgehensweisen: Bottom-up, Top-down, Sandwich, Schichtenweise
|
||||
\end{itemize*}
|
||||
|
||||
Systematisches Testen
|
||||
@ -1849,7 +1553,7 @@
|
||||
\end{itemize*}
|
||||
\item Weitere Begriffe
|
||||
\begin{itemize*}
|
||||
\item Regressionstest: erneute Durchführung eines Tests anhand einer geänderten Version des Testgegenstands
|
||||
\item Regressionstest: geänderte Version des Testgegenstands
|
||||
\item Alphatest: Test eines Prototypen durch Benutzer
|
||||
\item Betatest: Test der vollständigen Software durch Benutzer
|
||||
\end{itemize*}
|
||||
@ -1862,48 +1566,18 @@
|
||||
\item E/A-Zusammenhang
|
||||
\end{itemize*}
|
||||
|
||||
Äquivalenzklassen im funktionalen Test
|
||||
\begin{itemize*}
|
||||
\item Problem: alle Kombinationsmöglichkeiten der Eingangsdaten sind zu umfangreich für vollständigen Test
|
||||
\item Mögliche Einschränkung: Bildung von Äquivalenzklassen der Eingangsdaten, für die ähnliches Verhalten erwartet wird
|
||||
\item Basierend auf Anwendungsdomäne
|
||||
\item Äquivalenzklasse = Teilmenge der möglichen Datenwerte der Eingabeparameter
|
||||
\item Test je eines Repräsentanten jeder Äquivalenzklasse
|
||||
\item Finden von Äquivalenzklassen
|
||||
\begin{itemize*}
|
||||
\item Zulässige / unzulässige Teilbereiche der Datenwerte
|
||||
\item Unterteilung der Bereiche nach erwarteten Ausgabewerten
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
|
||||
Grenztests
|
||||
\begin{itemize*}
|
||||
\item Ergänzung von Äquivalenztests: Spezialfälle
|
||||
\item Rand der Äquivalenzklasse
|
||||
\item Außerdem: Sonderfälle, erwartete Problemfälle (technisch)
|
||||
\end{itemize*}
|
||||
|
||||
Strukturtest (white box test, glass box test)
|
||||
\begin{itemize*}
|
||||
\item Testfallauswahl beruht auf Programmstruktur
|
||||
\item Wie erreicht man möglichst vollständige Abdeckung?
|
||||
\item Kontrollflussorientiert
|
||||
\begin{itemize*}
|
||||
\item Anweisungsüberdeckung anhand Quellcode
|
||||
\item Zweigüberdeckung und
|
||||
\item Pfadüberdeckung anhand des Flussgraphen reduzierte Variante: bounded interior Pfadtest
|
||||
\end{itemize*}
|
||||
\item Datenflussorientiert
|
||||
\begin{itemize*}
|
||||
\item defines / uses-Verfahren: Abarbeitungspfade von Definition zu jeder Verwendung von Variable oder Objekt durchlaufen
|
||||
\end{itemize*}
|
||||
\item Kontrollflussorientiert (Anweisungsüberdeckung anhand Quellcode)
|
||||
\item Datenflussorientiert (Abarbeitungspfade von Definition)
|
||||
\item Zustandsorientiert
|
||||
\end{itemize*}
|
||||
|
||||
\subsection{Testaktivitäten und Werkzeuge}
|
||||
Wann wird getestet?
|
||||
\begin{itemize*}
|
||||
\item Während der Implementierung!
|
||||
\item Wann wird getestet? Während der Implementierung!
|
||||
\begin{itemize*}
|
||||
\item Auch wenn Schreiben von Tests scheinbar unproduktiv ist
|
||||
\item Tests sind unbeliebt, da Probleme aufgezeigt werden
|
||||
@ -1911,10 +1585,9 @@
|
||||
\end{itemize*}
|
||||
\item Inkrementell, d.h. für jede überschaubare Änderung
|
||||
\item Spezielle Vorgehensweise: test first-Ansatz
|
||||
\item Wie wird getestet? Geplant, systematisch, möglichst automatisiert, dokumentiert, wiederholbar
|
||||
\end{itemize*}
|
||||
|
||||
Wie wird getestet? Geplant, systematisch, möglichst automatisiert, dokumentiert, wiederholbar
|
||||
|
||||
Testplanung
|
||||
\begin{itemize*}
|
||||
\item Iterative Erstellung eines Testplans / Testdrehbuchs
|
||||
@ -1947,7 +1620,7 @@
|
||||
\item Festlegen und Erstellen der Eingabedaten
|
||||
\item Festlegungen zum Testablauf und zur Testreihenfolge
|
||||
\item Festlegen Soll-Ergebnis
|
||||
\item Festlegung der Bedingung(en) für 'Test erfüllt'; ...
|
||||
\item Festlegung der Bedingung(en) für 'Test erfüllt'
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
|
||||
@ -1960,19 +1633,15 @@
|
||||
\item Bereitstellen der Dokumente (Testspezifikation)
|
||||
\item Verfügbar machen von Werkzeugen (Fehlermanagement)
|
||||
\item Aufbauen der Testumgebung(en)
|
||||
\item Integration der Entwicklungsergebnisse in die Testumgebung (Software installieren, konfigurieren, ...)
|
||||
\item Bereitstellung von Testdaten bzw. Eingabedaten in die Testumgebung
|
||||
\item Integration der Entwicklungsergebnisse
|
||||
\item Bereitstellung von Testdaten in die Testumgebung
|
||||
\item Benutzer und Benutzerrechte anlegen
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
|
||||
Testdurchführung
|
||||
\begin{itemize*}
|
||||
\item Durchführung der spezifizierten Tests
|
||||
\begin{itemize*}
|
||||
\item Manuell
|
||||
\item Automatisiert
|
||||
\end{itemize*}
|
||||
\item Durchführung der spezifizierten Tests (Manuell/Automatisiert)
|
||||
\item Aktivitäten
|
||||
\begin{itemize*}
|
||||
\item Auswählen der zu testenden Testfälle
|
||||
@ -1993,9 +1662,8 @@
|
||||
\begin{itemize*}
|
||||
\item Klassifizierung (z. B.: Fehlerursache, Fehlerschwere etc.)
|
||||
\item Fehler reproduzieren!
|
||||
\item Angemessene Fehlerbeschreibung und –erläuterung: Nur ausreichend dokumentierte Fehler sind gültig und können bearbeitet werden!
|
||||
\item Angemessene Fehlerbeschreibung und -erläuterung
|
||||
\item Fehler im Fehlermanagement eintragen (Bug report)
|
||||
\item Testfall bleibt offen
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
|
||||
@ -2005,37 +1673,29 @@
|
||||
\item Ziel ist die Reproduzierbarkeit des Fehlers
|
||||
\item Zuordnung zu Projektplan: Meilenstein, Version
|
||||
\item Fehlerklassifikation
|
||||
\begin{itemize*}
|
||||
\item defect: Fehler in einer bestehenden Funktionalität
|
||||
\item enhancement / feature: Funktionale Anforderung oder Erweiterung der bestehenden Funktionalität
|
||||
\item task: Allgemeine Aufgabe
|
||||
\end{itemize*}
|
||||
\begin{description*}
|
||||
\item[defect] Fehler in einer bestehenden Funktionalität
|
||||
\item[enhancement/feature] Funktionale Anforderung (Erweiterung)
|
||||
\item[task] Allgemeine Aufgabe
|
||||
\end{description*}
|
||||
\item Priorität festlegen
|
||||
\begin{itemize*}
|
||||
\item Unterschiedliche Stufen
|
||||
\item Festlegung innerhalb eines Unternehmens / Projektes
|
||||
\end{itemize*}
|
||||
\item Prioritäten von Fehlern (bugs)
|
||||
\begin{description*}
|
||||
\item[blocker] Schwerwiegender Fehler, führt zur Arbeitsunfähigkeit anderer
|
||||
\item[critical] Schwerer Fehler, grundlegende Funktionalität des Systems nicht gegeben
|
||||
\item[major] normaler Fehler. System kann weiterhin verwendet werden
|
||||
\item[minor] Kleiner Fehler, behindert nicht weiter die Funktionsfähigkeit des Systems
|
||||
\item[trivial] Schönheitsfehler, stört während des Betrieb des Systems nicht.
|
||||
\end{description*}
|
||||
\end{itemize*}
|
||||
|
||||
%| Stufe | Bedeutung | Verhalten |
|
||||
%| -\item | -\item | -\item |
|
||||
%| blocker | Schwerwiegender Fehler. Führt zur Arbeitsunfähigkeit anderer (Entwicklung, QA, Produktion,...). | Verdrängt alle anderen Aufgaben! Muss sofort gelöst werden, um Arbeitsfähigkeit wieder herzustellen. |
|
||||
%| critical | Schwerer Fehler. Eine grundlegende Funktionalität des Systems ist nicht gegeben. Fehler muss bis zur nächsten Version behoben werden. System kann nicht verwendet werden. | Alle anderen Fehler (außer blocker) werden später gelöst. Bis zum nächsten Release muss dieser Bug gelöst sein. |
|
||||
%| major | „normaler“ Fehler. Es tritt ein Fehler innerhalb einer Funktion des Systems auf. Das System kann jedoch weiterhin verwendet werden. | Fehler wird normal eingeplant. |
|
||||
%| minor | Kleiner Fehler. Fehler behindert nicht weiter die Funktionsfähigkeit des Systems. Einfacher Work-Around vorhanden? | Je nach Aufwand und Zeitplanung erledigen. |
|
||||
%| trivial | Schönheitsfehler. Fehler stört während des Betrieb des Systems nicht. | Je nach Aufwand „zwischendrin“ erledigen. Alle anderen Bugs bevorzugt lösen. |
|
||||
|
||||
Testabschluss
|
||||
\begin{itemize*}
|
||||
\item Zusammenfassen der Tests
|
||||
\item Gesamtstatus dokumentieren und kommunizieren
|
||||
\item Entscheidungen herbeiführen z.B.: Auslieferung?
|
||||
\item Zusammenfassen der Tests dokumentieren und kommunizieren
|
||||
\item Entscheidungen herbeiführen
|
||||
\begin{itemize*}
|
||||
\item Ziele erreicht - nächste Schritte (Auslieferung)
|
||||
\item Tests vorzeitig beenden oder unterbrechen
|
||||
\item Gründe dokumentieren
|
||||
\item Vollständiger Nachtest oder Teiltest möglich?
|
||||
\end{itemize*}
|
||||
\item Unterlagen archivieren
|
||||
\end{itemize*}
|
||||
@ -2043,11 +1703,8 @@
|
||||
Testautomatisierung
|
||||
\begin{itemize*}
|
||||
\item Automatische Code-Validierung
|
||||
\begin{itemize*}
|
||||
\item Statisch: lint (C), Compiler
|
||||
\item Dynamisch: run-time checking, memory leaks etc.
|
||||
\end{itemize*}
|
||||
\item Beispiel: Test-Framework JUnit
|
||||
\item Statisch: lint (C), Compiler
|
||||
\item Dynamisch: run-time checking, memory leaks etc.
|
||||
\end{itemize*}
|
||||
|
||||
Behebung funktionaler Fehler
|
||||
@ -2065,28 +1722,21 @@
|
||||
\item Aufrufe, Zeitverbrauch in Methoden usw.
|
||||
\end{itemize*}
|
||||
|
||||
Memory Leaks, JProbe
|
||||
Memory Leaks
|
||||
\begin{itemize*}
|
||||
\item Runtime heap summary: Welche Objekte verbrauchen Speicher?
|
||||
\item Reference graph: Wer referenziert diese Objekte, so dass sie nicht per garbage collection gelöscht werden?
|
||||
\end{itemize*}
|
||||
|
||||
\subsection{Softwareverteilung}
|
||||
Softwareverteilung (deployment)
|
||||
\subsection{Softwareverteilung (deployment)}
|
||||
\begin{itemize*}
|
||||
\item Prozess zur Installation von Software auf
|
||||
\begin{itemize*}
|
||||
\item Anwender-PC‘s, Servern, Maschinen in Produktion ...
|
||||
\end{itemize*}
|
||||
\item Prozess zur Installation von Software auf PC‘s, Servern, Maschinen in Produktion
|
||||
\item Steuerung der Installation der Software
|
||||
\item Voraussetzungen für die Software schaffen
|
||||
\begin{itemize*}
|
||||
\item Schulungen planen und durchführen
|
||||
\end{itemize*}
|
||||
\item Softwareverteilung ist ein kritischer Prozess!
|
||||
\begin{itemize*}
|
||||
\item Fehler können zu vielen Störungen und Ausfällen führen
|
||||
\end{itemize*}
|
||||
\item Ziele
|
||||
\begin{itemize*}
|
||||
\item Automatische Installation, Konfiguration und Wartung einer großen Anzahl von Systemen mit geringem Aufwand
|
||||
@ -2096,85 +1746,36 @@
|
||||
\end{itemize*}
|
||||
|
||||
Installationsarten
|
||||
\begin{itemize*}
|
||||
\item Erstinstallation
|
||||
\item Software-Update (Software-Aktualisierung)
|
||||
\begin{itemize*}
|
||||
\item Aktualisierung der Software, Daten oder Konfiguration
|
||||
\end{itemize*}
|
||||
\item Hotfixes und Service Packs
|
||||
\begin{itemize*}
|
||||
\item Nur bestimmte Teile der Software werden aktualisiert
|
||||
\item Meist nur Fehlerbehebung, keine neuen Features
|
||||
\end{itemize*}
|
||||
\item Upgrade
|
||||
\begin{itemize*}
|
||||
\item Erweitert eine Software deutlich um neue Funktionen
|
||||
\end{itemize*}
|
||||
\item Unbeaufsichtigte (automatische) Installation
|
||||
\begin{description*}
|
||||
\item[Erstinstallation]
|
||||
\item[Software-Update] Aktualisierung der Software, Daten oder Konfiguration
|
||||
\item[Hotfixes/Service Packs] Nur bestimmte Teile der Software werden aktualisiert; Meist nur Fehlerbehebung, keine neuen Features
|
||||
\item[Upgrade] Erweitert eine Software deutlich um neue Funktionen
|
||||
\item[Unbeaufsichtigte (automatische)] Installation
|
||||
\begin{itemize*}
|
||||
\item Installation erfolgt ohne Benutzereingriff
|
||||
\item Periodisch, durch Aufruf des Anwenders, beim Programmstart
|
||||
\item Einstellungen in einem Skript festgelegt oder werden als Parameter übergeben
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
|
||||
Installationshilfsmittel
|
||||
\begin{itemize*}
|
||||
\item Installationsprogramm (Installer)
|
||||
\begin{itemize*}
|
||||
\item Windows: Windows Installer, InstallShield
|
||||
\item Linux: RPM, Port, APT
|
||||
\item MAC-OS: Installer, WarpIn
|
||||
\end{itemize*}
|
||||
\item Installations-Script
|
||||
\item Installationsanweisung
|
||||
\end{itemize*}
|
||||
\end{description*}
|
||||
|
||||
Software-Rollout
|
||||
\begin{itemize*}
|
||||
\item Vorgang des Veröffentlichens und Verteilens von Softwareprodukten auf entsprechende Clients
|
||||
\item Anzahl der Clients kann weit über 10.000 liegen!
|
||||
\item Rollout abhängig von verschiedenen Kriterien (Vorherige Installation, Hardwarekonfiguration, Zeit, Kunde)
|
||||
\item Vorgang des Veröffentlichens und Verteilens
|
||||
\item Rollout abhängig von verschiedenen Kriterien
|
||||
\item Rollout-Varianten
|
||||
\begin{itemize*}
|
||||
\item Zentral / Dezentral
|
||||
\item Manuell (Benutzer löst Installation aus)
|
||||
\item Automatisiert (ohne Benutzerinteraktion)
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
|
||||
Vollständige Verteilung (big bang)
|
||||
\begin{itemize*}
|
||||
\item Alle Installationen werden mit einem Mal installiert
|
||||
\item Sehr hohes Risiko
|
||||
\item Eventuelle Fehler führen zu vielen fehlerhaften Zuständen oder Störfällen - führt zu hohem Druck
|
||||
\item Eventuelle Fehler müssen schnell gelöst werden (Provisorium)
|
||||
\item Sehr kurze Einführungsphase
|
||||
\item Rollback-Mechanismus sehr empfohlen
|
||||
\end{itemize*}
|
||||
|
||||
Rollback
|
||||
\begin{itemize*}
|
||||
\item Wiederherstellung des Ursprungszustands
|
||||
\item Technische Realisierung muss ermöglicht werden
|
||||
\end{itemize*}
|
||||
|
||||
Pilotierte Einführung
|
||||
\begin{itemize*}
|
||||
\item Einführung für wenige ausgewählte Installationen
|
||||
\item Sehr hohe Sicherheit
|
||||
\item Festlegung der späteren Rollout-Schritte
|
||||
\item Benötigt zusätzliche Zeit
|
||||
\item Geringere Auftrittswahrscheinlichkeit von Fehlern
|
||||
\end{itemize*}
|
||||
|
||||
Schrittweise (iterative) Einführung
|
||||
\begin{itemize*}
|
||||
\item Einführung erfolgt schrittweise mit einer definierten Anzahl
|
||||
\item von Installationen (Rampe - ramp-up)
|
||||
\item Höhere Fehlerwahrscheinlichkeit $\rightarrow$ Bessere Reproduzierbarkeit $\rightarrow$ schnelleres Finden von Fehlern $\rightarrow$ Erfahrungsgewinn
|
||||
\item Begrenztes Risiko, mittlerer Zeitaufwand
|
||||
\item Verteilungsarten
|
||||
\begin{description}
|
||||
\item[Vollständige Verteilung] (big bang) Alle Installationen werden mit einem Mal installiert (Sehr hohes Risiko)
|
||||
\item[Rollback] Wiederherstellung des Ursprungszustands
|
||||
\item[Pilot] Einführung für wenige ausgewählte Installationen (Sehr hohe Sicherheit)
|
||||
\item[Iterativ (schrittweise)] mit definierten Anzahl von Installationen bessere Reproduzierbarkeit
|
||||
\end{description}
|
||||
\end{itemize*}
|
||||
|
||||
\newpage
|
||||
|
||||
Loading…
Reference in New Issue
Block a user