1. Testen
1.1. Spezifikationsorientiertes Testen
1.1.1. Basis Use Cases
1.1.1.1. "tut's das, was der Kunde spezifiziert hat?"
1.1.2. Ein Szenario pro (Sub-) Use Case erstellen
1.1.3. Gut durch Kunden ausführbar
1.1.4. Black-box Test
1.2. Definition Testen
1.2.1. Ausführung von Software mit dem Ziel
1.2.1.1. Fehler zu finden
1.2.1.2. Sicherstellen, dass Vorgaben erfüllt
1.3. Anforderungen an Software Test
1.3.1. Geplant -> Testplanung
1.3.2. Systematisch spezifiziert -> Testspezifikation
1.3.3. Resultate festgehalten -> Testprotokoll
1.3.4. reproduzierbar
1.3.5. automatisiert
1.4. Test kategorisieren
1.4.1. link auf funktionale / nf Anforderungen!!!
1.5. Software-Prüfung
1.5.1. Dynamische Prüfung: Code ausführen
1.5.1.1. Testen
1.5.1.2. Dynamische Analyse
1.5.2. Statische Prüfung
1.5.2.1. Metrikanalyse
1.5.2.2. Ohne Rechner: Review
1.6. Begriffe: Verifikation und Validierung
1.6.1. Verifikation (verification)
1.6.1.1. „Are we building the product right?“
1.6.2. Validierung (validation)
1.6.2.1. „Are we building the right product?“
1.7. Testmethoden
1.7.1. Black-Box Tests
1.7.1.1. Äquivalenzklassen
1.7.1.1.1. Wertebereich einer Eingabegrösse, für welche der Prüfling voraussichtlich das gleiche Verhalten zeigt
1.7.1.1.2. einTestfallpro Äquivalenzklasse
1.7.1.2. Grenzwertanalyse
1.7.1.2.1. Fehler sehr oft an Grenzen zulässiger Eingabewertebereiche
1.7.1.2.2. wählt Testfälle an den Grenzen
1.7.1.2.3. Erweiterung der Äquivalenzklassenmethode
1.7.1.3. Zustandbasiertes Testen
1.7.2. White-Box-Tests
1.7.2.1. Kontrollfluss-orientiertes Testen
1.7.2.1.1. Anweisungsüberdeckung
1.7.2.1.2. Zweigüberdeckung
1.7.2.1.3. Pfadüberdeckung
1.7.2.2. Datenfluss-orientiertes Testen
1.8. Testüberdeckung (test coverage)
1.8.1. Anweisungsüberdeckung (statement coverage)
1.8.1.1. Prozentualer Anteil der Anweisungen, die in Test ausgeführt werden
1.8.1.2. 100% Anweisungsüberdeckung ist Minimum
1.8.2. Zweigüberdeckung
1.8.2.1. Prozentualer Anteil der Kanten (Zweige), die in Test durchlaufen werden
1.8.2.2. Eine 100% Zweigüberdeckung enthält auch eine 100% Anweisungsüberdeckung
1.8.2.3. Zusätzlich werden auch alle „leeren Zweige“ durchlaufen
1.8.3. Pfadüberdeckung
1.8.3.1. Prozentualer Anteil der Pfade, die in Test durchlaufen werden
1.8.3.2. Ein Pfad ist ein möglicher Weg durch den Kontrollgraph
1.8.3.2.1. kleine Programme mit Schleifen -> riesige Anzahl Pfade
1.8.3.2.2. 100% Pfadüberdeckung nicht zu erreichen
1.8.4. Bedingungsüberdeckung
1.8.4.1. Zusammengesetzte Bedingungen - > verschiedene Kombinationen testen
1.8.4.2. Einfache Bedingungsüberdeckung
1.8.4.2.1. alle atomaren Bedingungen mind. einmal true und einmal false
1.8.4.2.2. garantiert keine 100%ige Anweisungsüberdeckung
1.9. Automatisierte Tests
1.9.1. Vorteile
1.9.1.1. Wiederholbarkeit -> Regressionstests
1.9.1.1.1. Absicherung bei Änderung, Portierung, Erweiterung
1.9.1.1.2. geringe/keine Kosten bei Wiederholung
1.9.1.2. Eindeutige Spezifikation
1.9.1.2.1. Testcode ist Programmcode und damit eindeutig
1.9.2. Nachteile
1.9.2.1. Mehr Code zu schreiben und zu pflegen
1.9.2.2. Testcode ist Programmcode
1.9.2.2.1. Werden wirklich die richtigen Anforderungen getestet?
1.9.2.2.2. Was muss überhaupt getestet werden?
1.10. Right-BICEP
1.10.1. Are the results right?
1.10.2. Are all boundary conditions CORRECT?
1.10.2.1. Conformance
1.10.2.2. Ordering
1.10.2.3. Range
1.10.2.4. Reference
1.10.2.5. Existence
1.10.2.6. Cardinality
1.10.2.7. Time
1.10.3. Can you check inverse relationships?
1.10.4. Can you cross-check results using other means?
1.10.5. Can you force error conditions to happen?
1.10.6. Are performance characteristics within bounds?
1.11. A TRIP
1.11.1. Automatic
1.11.2. Thorough
1.11.2.1. sorgfältig
1.11.3. Repeatable
1.11.4. Independent
1.11.4.1. keine Abhängigkeit zwischen Tests
1.11.5. Professional
2. Einführung
2.1. Software Engineering Definition
2.1.1. Software engineering is the application
2.1.1.1. of a systematic, disciplined, quantifiable approach
2.1.1.2. to the development, operation, and maintenance of software,
2.1.1.3. that is, the application of engineering to software.
2.1.2. Elemente Software-Engineering
2.1.2.1. Prozesse
2.1.2.1.1. beschreibt, wer was wann und wie tut
2.1.2.2. Prinzipien
2.1.2.3. Modelle
2.1.2.4. Notationen
2.1.2.5. Werkzeuge
2.2. RUP
2.2.1. Inception
2.2.2. Elaboration
2.2.3. Construction
2.2.4. Transition
2.2.5. Disciplines
2.2.5.1. Eine Displin (discipline) ist eine Menge zusammengehöriger Aktivitäten (activities) eines bestimmten Schwerpunktes der Softwareentwicklung
2.2.6. Modelle
2.2.6.1. Domain-Modell
2.2.6.1.1. abstrahiert den Problembereich
2.2.6.1.2. Zerlegt Problem in verständliche Teile -> Konzeptionelle Klassen, Konzepte (domain objects)
2.2.6.1.3. Kommunikation zwischen verschiedenen Rollen in Entwicklung
2.2.6.2. Design-Modell
2.2.6.2.1. abstrakte Darstellung der Lösung
2.3. Syntax vs. Semantik
2.3.1. Syntax
2.3.1.1. bezeichnet die (formal) definierte äussere Form einer Notation
2.3.2. Semantik
2.3.2.1. ist die Bedeutung einer Notation
3. Domain Modelierung
3.1. Finden von Konzepten
3.1.1. Strategie 1: Von existierenden Modellen ausgehen
3.1.2. Strategie 2: Checkliste mit Kategorien
3.1.3. Strategie 3: Substantive suchen
3.2. Multiplizitäten
3.2.1. * -> zero or more; "many"
3.2.2. 1 .. * -> one or more
3.2.3. 1 .. 40 -> one to 40
3.2.4. 5 -> exactly 5
3.2.5. 3,5,8 -> exactly 3, 5, or 8
3.3. Refining the Domain Model
3.3.1. Aggregation
3.3.1.1. Spezielle Assoziation zur Modellierung von Ganzes-Teile-Beziehungen, aus „Has-a“-Beziehung
3.3.1.2. ganzes <>-- teil
3.3.2. Composition
3.3.2.1. Composite Aggregation oder Composition: Aggregation, bei welcher, die Teile ausschliesslich dem Ganzen gehören
3.3.2.2. ganzes <0>-- teil
3.3.2.3. Multiplizität ist beim Ganzen genau 1!
4. Softwareanforderungen
4.1. Klassifikation
4.1.1. Software Anforderungen
4.1.1.1. Funktionale Was?
4.1.1.2. Nichtfunktionale Wie gut?
4.1.1.2.1. Leistung
4.1.1.2.2. Mengen
4.1.1.2.3. Qualitätsmerkmale
4.1.1.2.4. Randbedingungen
4.1.1.2.5. Schnittstellenanforderungen
4.2. Use Cases
4.2.1. Begriffe
4.2.2. Formate
4.2.2.1. Brief
4.2.2.2. Casual
4.2.2.3. Fully Dressed
4.2.3. Teile eines Uses Cases
4.2.3.1. Primary Actor
4.2.3.1.1. Supporting Actors
4.2.3.1.2. Offstage Actors
4.2.3.2. Stakeholders and Interests
4.2.3.3. Preconditions
4.2.3.4. Post Conditions / Success Guarantees
4.2.3.5. Main Success Scenario
4.2.3.6. Extensions
4.2.3.7. Special Requirements
4.2.3.8. Technology and Data Variation Lists
4.2.4. Vorgehen Use Cases
4.2.4.1. 1. Systemgrenzen festlegen
4.2.4.1.1. Software, HW/SW-System, Organisation
4.2.4.2. 2. Primäre Aktoren identifizieren
4.2.4.2.1. Ihre Ziele als Systembenutzer werden durch System erfüllt
4.2.4.3. 3. Ziele jedes Aktoren identifizieren
4.2.4.3.1. So abstrakt wie möglich auf Ebene EBP
4.2.4.4. 4. Use Cases schreiben
4.2.5. Details Use Case Diagramme
4.2.5.1. «include»
4.2.5.1.1. Teil von Use Case in separaten Subfunction Use Case ausgelagert
4.2.5.2. «extend»
4.2.5.2.1. Erweitert Basis Use Case
4.3. Anforderungsspezifikation
4.3.1. Korrektheit
4.3.2. Eindeutigkeit
4.3.3. Vollständigkeit
4.3.4. Konsistenz
4.3.5. Mit Gewichtung versehen bezüglich Wichtigkeit / Priorität / Stabilität
4.3.6. Überprüfbarkeit
4.3.7. Änderbarkeit
4.3.8. Verfolgbarkeit
5. Systemsequenzdiagramme
5.1. Aktoren, System als Blackbox
5.2. SSD beschreibt Use Case Szenario
6. Konfigurationsmanagement
6.1. Locking Verfahren
6.1.1. pessimistic Locking (default bei rcs)
6.1.2. optimistic Locking (default bei cvs/svn)
6.2. CVS Commands
6.2.1. Directory erzeugen
6.2.1.1. mkdir ~/foobar
6.2.2. CVS init
6.2.2.1. cvs -d ~/foobar init
6.2.3. neues Modul
6.2.3.1. mkdir sesame
6.2.3.2. cd sesame
6.2.3.3. files erzeugen...
6.2.3.4. cvs -d ~/foobar import -m"" sesame sesame initial
6.2.3.5. im importierten Directory (sesame) NICHT weiterarbeiten.
6.2.4. Arbeitsbereich anlegen
6.2.4.1. mkdir ~/work
6.2.4.2. cd ~/work
6.2.4.3. Modul auschecken:
6.2.4.3.1. cvs -d ~/foobar co sesame
6.2.5. Sonstige
6.2.5.1. Status einer Datei
6.2.5.1.1. cvs status Color.txt
6.2.5.2. Unterschiede?
6.2.5.2.1. cvs diff Color.txt
6.2.5.3. Commit Changes
6.2.5.3.1. cvs commit
6.2.5.4. Arbeitsbereich aktuell?
6.2.5.4.1. cvs -nq update
6.2.5.5. Status neuer Datei
6.2.5.5.1. cvs status Color.txt
6.2.5.6. Historie
6.2.5.6.1. cvs log Color.txt
6.2.5.7. Datei hinzufügen
6.2.5.7.1. cvs add Color.txt
7. Entwurf
7.1. logische Architektur
7.1.1. Klassendiagramm
7.1.1.1. Packages
7.1.1.2. Dependencies
7.2. physische Architektur
7.2.1. Tiers
7.2.2. UML Deployment Diagramm
7.3. Auswahl von Packages
7.3.1. Kohäsion (cohesion)
7.3.1.1. Mass für Zusammenhalt innerhalb (z.B. Packages)
7.3.1.2. In Package gruppieren, was zusammen eine gemeinsame Funktion erfüllt
7.3.2. Kopplung (coupling)
7.3.2.1. Mass für Abhängigkeit zwischen (z.B. Packages)
7.3.2.2. Schnittstellen möglichst schmal und einfach zwischen Packages
7.4. Interaktionsdiagrammen
7.4.1. Interaktionsdiagramme zeigen dazu das dynamisches Verhalten des Systems
7.4.2. Participants
7.4.2.1. unnamed instance
7.4.2.1.1. : Sale
7.4.2.2. named instance
7.4.2.2.1. s1 : sale
7.4.2.3. class based on another class
7.4.2.3.1. <<metaclass>> iClass
7.4.2.4. instance of ArrayList, parameterized to hold Sales
7.4.2.4.1. sales : ArrayList<Sale>
7.4.2.5. instance of Sale, from an ArrayList<Sale>
7.4.2.5.1. sales[i] : Sale
7.4.2.6. Singletons top right corner a 1
7.4.3. Instanz löschen
7.4.3.1. «destroy»
7.5. Notationselemente für Design-Klassendiagramme
7.5.1. Klassen, abstrakte Klassen, Vererbung, Interfaces
7.5.2. Assoziationen, Kompositionen, Aggregationen
7.5.3. Navigationspfade
7.5.3.1. Semantische Zusammenhänge
7.5.3.2. Nur dort, wo Links zwischen Objekten bestehen müssen (Sichtbarkeit nötig)
7.5.4. Abhängigkeiten (Dependencies)
7.5.4.1. Modelliert allgemein Abhängigkeiten zwischen Elementen
7.5.4.2. Wenn Assoziation, Vererbung braucht keine Dependency eingezeichnet werden
7.5.5. Attribute mit Typinformation und Sichtbarkeit
7.5.6. Methoden ev. mit Parameter und Rückgabewerten
8. GRASP
8.1. General Responsibility Assignment Patterns
8.1.1. Pattern
8.1.1.1. Information Expert
8.1.1.1.1. geringe Kopplung (low coupling) und hohe Kohäsion (high cohesion)
8.1.1.2. Creator
8.1.1.2.1. lose Kopplung (low coupling)
8.1.1.3. High Cohesion
8.1.1.3.1. Mass für den inneren Zusammenhalt von Klassen
8.1.1.4. Low Coupling
8.1.1.4.1. Mass für die Abhängigkeit eines Elementes (z.B. einer Klasse) von Umgebung (z.B. von anderen Klassen)
8.1.1.4.2. Teile Responsibilities so zu, dass eine lose Kopplung resultiert
8.1.1.5. Controller
8.1.1.5.1. Objekt verantwortlich, Systemereignisse zu verarbeiten, gehört nicht zum Userinterface
8.1.1.6. Polymorphism
8.1.1.6.1. GoF-Pattern
8.1.1.7. Pure Fabrication
8.1.1.7.1. Technologie-Know-How gehört nicht in Domainklasse
8.1.1.8. Indirection
8.1.1.8.1. Objekt einführen, das zwischen Objekten vermittelt
8.1.1.8.2. GoF-Pattern
8.1.1.9. Protected Variations
8.1.1.9.1. 1. Bereiche identifizieren, die Änderungen unterworfen sind
8.1.1.9.2. 2. Variation Points von Umgebung abschotten (d.h. stabile „Interfaces“)
8.1.1.9.3. Nutzen
8.1.1.9.4. alternative Namen
9. Visibility
9.1. Attribute Visibility
9.1.1. a besitzt als Attribut Referenz auf b (Aggregation oder Assoziation)
9.1.2. existiert über längeren Zeitraum
9.2. Parameter Visibility
9.2.1. b ist ein Parameter einer Methode von a
9.2.2. Temporäre Form der Sichtbarkeit
9.3. Local Visibility
9.3.1. b ist lokales Objekt in Methode von a
9.3.2. Temoräre Form der Sichtbarkeit, wenn
9.3.2.1. 1. Lokale Instanz erzeugt u. lokaler Variablen zugewiesen
9.3.2.2. 2. Rückgabwert ist Objekt, das lokaler Instanz zugewiesen
9.4. Global Visibility
9.4.1. b ist global sichtbar
9.4.2. Permanente Form der Sichtbarkeit
9.4.3. Sollte eigentlich nie verwendet werden (hohe Kopplung!)
10. GoF Pattern
10.1. Creational
10.1.1. Abstract Factory
10.1.1.1. Dann macht es Sinn, die Factories zusammenzufassen und eine gemeinsame abstrakte Klasse für diese Factory- Eigenschaften zu definieren.
10.1.1.1.1. oft bei umgebungsabhängigen Klassenhierarchien
10.1.1.1.2. mehrere Factory Methods zusammengefasst
10.1.2. Prototype
10.1.3. Singleton
10.1.3.1. Definiere eine statische Methode in der Singleton- Klasse. Diese Methode gibt das Singleton zurück
10.1.3.1.1. Achtung: Singletons sind globale Objekte ( -> hohe Kopplung! )
10.1.4. Factory Method
10.1.4.1. Unterklassen können das Verhalten ändern, durch Überschreiben der Factory Method
10.1.5. Builder
10.2. Structural
10.2.1. Adapter
10.2.1.1. Konvertiere inkompatible Schnittstelle über Adapterklasse, die das gewünschte Interface implementiert.
10.2.2. Bridge
10.2.3. Composite
10.2.3.1. Implementiere Klassen für einzelne (atomare) Objekte und zusammengesetzte Objekte mit einer gemeinsamen Schnittstelle.
10.2.4. Decorator
10.2.4.1. Umgib das ursprüngliche Objekt mit einem Decorator, welcher das gleiche Interface implementiert, wie das Originalobjekt. Der Decorator implementiert die zusätzliche Funktionalität und delegiert für die Kernfunktionalität an das Originalobjekt
10.2.5. Flyweight
10.2.6. Facade
10.2.6.1. Definiere einen einzigen Einstiegspunkt zum Subsystem für Nutzer. Ein Façade-Objekt das das Subsystem "einwickelt" (wrapped). Alle Interaktion mit dem Subsystem läuft über dieses Façade-Objekt. Der innere Aufbau des Subsystems bleibt verborgen.
10.2.7. Proxy
10.3. Behavioral
10.3.1. Chain of Responsibility
10.3.2. Command
10.3.2.1. Kapsle die Aktion als Command Objekt. Gib allen Command Objekten eine gemeinsamen Schnittstelle, welche die notwendigen Anforderungen widerspiegelt. Statt eine Aktionsmethode direkt aufzurufen, erzeuge das entsprechende Command Objekt, auf dem dann die Aktion ausgeführt wird.
10.3.3. Iterator
10.3.3.1. Der Container stellt einen Iterator zur Verfügung, welcher Element um Element aus dem Container liefert
10.3.4. Mediator
10.3.5. Memento
10.3.6. Observer
10.3.7. State
10.3.7.1. Implementiere für jeden Zustand eine eigene Klasse. Alle Zustandsklassen haben eine gemeinsame Schnittstelle. Die Ausgangsklasse delegiert die zustandsabhängigen Methoden an diese Schnittstelle. Jeder Zustandswechsel tauscht das aktuelle Zustandsobjekt aus.
10.3.8. Strategy
10.3.8.1. Definiere eine gemeinsame Schnittstelle für die Algorithmen, implementiere das Objekt gegen diese Schnittstelle und lasse die einzelnen Algorithmen diese Schnittstelle implementieren
10.3.9. Visitor
10.3.10. Template Method
10.3.10.1. Definiere die Struktur des Algorithmus (Skelett) in der Basisklasse. Diese Template Methode ruft andere Methoden für die variierenden Details auf. Diese anderen Methoden (Hook methods) werden in den Unterklassen entsprechend überschrieben.
10.4. Null Object
10.4.1. Eine Klasse implementieren, welche das erforderliche Interface implementiert, deren Methoden aber nichts tun oder den geforderten Defaultwert liefern.
11. Architektur
11.1. Views
11.1.1. Logical View
11.1.1.1. Gliederung in Packages und Klassen
11.1.1.2. statisch
11.1.1.3. dynamisch
11.1.1.4. Layer
11.1.2. Process View
11.1.2.1. Nebenläufigkeit
11.1.3. Deployement View
11.1.3.1. Zuordnung auf Hardware-Elemente
11.1.3.2. Tier
11.1.4. Implementation View
11.1.4.1. Quellcode, ausführbare Programme
11.1.5. Use Case View
11.1.5.1. Realisierung Architektur- relevanter Use Cases
11.1.6. Data View
11.1.6.1. Persistente Datenspeicherung
11.2. Definition Software Architektur
11.2.1. signifikante Entscheidungen zur Organisation eines SW-Systems
11.2.2. Struktur
11.2.2.1. Anordnung der Strukturelemente - statisch
11.2.2.2. Interfaces zwischen Strukturelementen
11.2.2.3. Zusammenspiel zwischen Strukturelementen - dynamisch
11.3. Ausgangslage für Architekturen
11.3.1. Funktionale Anforderungen
11.3.2. Nichtfunktionale Anforderungen
11.3.3. Randbedingungen (constraints)
12. Projektmanagement
12.1. 4 Planungsfaktoren
12.1.1. Funktionalität (Scope)
12.1.2. Qualität
12.1.3. Zeit
12.1.4. Kosten
13. Objektorientierte Analyse
13.1. klassisch
13.1.1. Domainmodell mit Operationen
13.1.2. Interaktionsdiagramm zwischen Objekten
13.1.3. "white box" Analyse
13.2. Larman
13.2.1. Domainmodell ohne Operationen
13.2.2. Systemsequenzdiagramm SSD
13.2.3. System als "black box"
13.2.4. Contracts und Systemoperationen
13.3. Activity-Diagramm
13.3.1. Basiselemente
13.3.1.1. Start & End
13.3.1.1.1. An initial or start node is depicted by a large black spot, as shown below.
13.3.1.1.2. There are two types of final node: activity and flow final nodes. The activity final node is depicted as a circle with a dot inside.
13.3.1.2. Activity
13.3.1.2.1. An activity is the specification of a parameterized sequence of behaviour. An activity is shown as a round-cornered rectangle enclosing all the actions, control flows and other elements that make up the activity.
13.3.1.3. Action
13.3.1.3.1. An action represents a single step within an activity. Actions are denoted by round-cornered rectangles.
13.3.1.4. Control Flow
13.3.1.4.1. A control flow shows the flow of control from one action to the next. Its notation is a line with an arrowhead.
13.3.1.5. Fork & Join
13.3.1.5.1. Forks and joins have the same notation: either a horizontal or vertical bar (the orientation is dependent on whether the control flow is running left to right or top to bottom). They indicate the start and end of concurrent threads of control. The following diagram shows an example of their use
13.3.1.6. Branch mit Kondition & Merge
13.3.1.6.1. Decision nodes and merge nodes have the same notation: a diamond shape. They can both be named. The control flows coming away from a decision node will have guard conditions which will allow control to flow if the guard condition is met. The following diagram shows use of a decision node and a merge node.
13.3.2. Weitere Elemente
13.3.2.1. Swimlanes
13.3.2.2. Objectflow
13.3.2.3. Partition
13.3.2.3.1. An activity partition is shown as either a horizontal or vertical swimlane. In the following diagram, the partitions are used to separate actions within an activity into those performed by the accounting department and those performed by the customer.