1. Domain Modelierung
1.1. Finden von Konzepten
1.1.1. Strategie 1: Von existierenden Modellen ausgehen
1.1.2. Strategie 2: Checkliste mit Kategorien
1.1.3. Strategie 3: Substantive suchen
1.2. Multiplizitäten
1.2.1. * -> zero or more; "many"
1.2.2. 1 .. * -> one or more
1.2.3. 1 .. 40 -> one to 40
1.2.4. 5 -> exactly 5
1.2.5. 3,5,8 -> exactly 3, 5, or 8
1.3. Refining the Domain Model
1.3.1. Aggregation
1.3.1.1. Spezielle Assoziation zur Modellierung von Ganzes-Teile-Beziehungen, aus „Has-a“-Beziehung
1.3.1.2. ganzes <>-- teil
1.3.2. Composition
1.3.2.1. Composite Aggregation oder Composition: Aggregation, bei welcher, die Teile ausschliesslich dem Ganzen gehören
1.3.2.2. ganzes <0>-- teil
1.3.2.3. Multiplizität ist beim Ganzen genau 1!
2. GRASP
2.1. General Responsibility Assignment Patterns
2.1.1. Pattern
2.1.1.1. Information Expert
2.1.1.1.1. geringe Kopplung (low coupling) und hohe Kohäsion (high cohesion)
2.1.1.2. Creator
2.1.1.2.1. lose Kopplung (low coupling)
2.1.1.3. High Cohesion
2.1.1.3.1. Mass für den inneren Zusammenhalt von Klassen
2.1.1.4. Low Coupling
2.1.1.4.1. Mass für die Abhängigkeit eines Elementes (z.B. einer Klasse) von Umgebung (z.B. von anderen Klassen)
2.1.1.4.2. Teile Responsibilities so zu, dass eine lose Kopplung resultiert
2.1.1.5. Controller
2.1.1.5.1. Objekt verantwortlich, Systemereignisse zu verarbeiten, gehört nicht zum Userinterface
2.1.1.6. Polymorphism
2.1.1.6.1. GoF-Pattern
2.1.1.7. Pure Fabrication
2.1.1.7.1. Technologie-Know-How gehört nicht in Domainklasse
2.1.1.8. Indirection
2.1.1.8.1. Objekt einführen, das zwischen Objekten vermittelt
2.1.1.8.2. GoF-Pattern
2.1.1.9. Protected Variations
2.1.1.9.1. 1. Bereiche identifizieren, die Änderungen unterworfen sind
2.1.1.9.2. 2. Variation Points von Umgebung abschotten (d.h. stabile „Interfaces“)
2.1.1.9.3. Nutzen
2.1.1.9.4. alternative Namen
3. Visibility
3.1. Attribute Visibility
3.1.1. a besitzt als Attribut Referenz auf b (Aggregation oder Assoziation)
3.1.2. existiert über längeren Zeitraum
3.2. Parameter Visibility
3.2.1. b ist ein Parameter einer Methode von a
3.2.2. Temporäre Form der Sichtbarkeit
3.3. Local Visibility
3.3.1. b ist lokales Objekt in Methode von a
3.3.2. Temoräre Form der Sichtbarkeit, wenn
3.3.2.1. 1. Lokale Instanz erzeugt u. lokaler Variablen zugewiesen
3.3.2.2. 2. Rückgabwert ist Objekt, das lokaler Instanz zugewiesen
3.4. Global Visibility
3.4.1. b ist global sichtbar
3.4.2. Permanente Form der Sichtbarkeit
3.4.3. Sollte eigentlich nie verwendet werden (hohe Kopplung!)
4. Architektur
4.1. Views
4.1.1. Logical View
4.1.1.1. Gliederung in Packages und Klassen
4.1.1.2. statisch
4.1.1.3. dynamisch
4.1.1.4. Layer
4.1.2. Process View
4.1.2.1. Nebenläufigkeit
4.1.3. Deployement View
4.1.3.1. Zuordnung auf Hardware-Elemente
4.1.3.2. Tier
4.1.4. Implementation View
4.1.4.1. Quellcode, ausführbare Programme
4.1.5. Use Case View
4.1.5.1. Realisierung Architektur- relevanter Use Cases
4.1.6. Data View
4.1.6.1. Persistente Datenspeicherung
4.2. Definition Software Architektur
4.2.1. signifikante Entscheidungen zur Organisation eines SW-Systems
4.2.2. Struktur
4.2.2.1. Anordnung der Strukturelemente - statisch
4.2.2.2. Interfaces zwischen Strukturelementen
4.2.2.3. Zusammenspiel zwischen Strukturelementen - dynamisch
4.3. Ausgangslage für Architekturen
4.3.1. Funktionale Anforderungen
4.3.2. Nichtfunktionale Anforderungen
4.3.3. Randbedingungen (constraints)
5. Objektorientierte Analyse
5.1. klassisch
5.1.1. Domainmodell mit Operationen
5.1.2. Interaktionsdiagramm zwischen Objekten
5.1.3. "white box" Analyse
5.2. Larman
5.2.1. Domainmodell ohne Operationen
5.2.2. Systemsequenzdiagramm SSD
5.2.3. System als "black box"
5.2.4. Contracts und Systemoperationen
5.3. Activity-Diagramm
5.3.1. Basiselemente
5.3.1.1. Start & End
5.3.1.1.1. An initial or start node is depicted by a large black spot, as shown below.
5.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.
5.3.1.2. Activity
5.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.
5.3.1.3. Action
5.3.1.3.1. An action represents a single step within an activity. Actions are denoted by round-cornered rectangles.
5.3.1.4. Control Flow
5.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.
5.3.1.5. Fork & Join
5.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
5.3.1.6. Branch mit Kondition & Merge
5.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.
5.3.2. Weitere Elemente
5.3.2.1. Swimlanes
5.3.2.2. Objectflow
5.3.2.3. Partition
5.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.
6. Testen
6.1. Spezifikationsorientiertes Testen
6.1.1. Basis Use Cases
6.1.1.1. "tut's das, was der Kunde spezifiziert hat?"
6.1.2. Ein Szenario pro (Sub-) Use Case erstellen
6.1.3. Gut durch Kunden ausführbar
6.1.4. Black-box Test
6.2. Definition Testen
6.2.1. Ausführung von Software mit dem Ziel
6.2.1.1. Fehler zu finden
6.2.1.2. Sicherstellen, dass Vorgaben erfüllt
6.3. Anforderungen an Software Test
6.3.1. Geplant -> Testplanung
6.3.2. Systematisch spezifiziert -> Testspezifikation
6.3.3. Resultate festgehalten -> Testprotokoll
6.3.4. reproduzierbar
6.3.5. automatisiert
6.4. Test kategorisieren
6.4.1. link auf funktionale / nf Anforderungen!!!
6.5. Software-Prüfung
6.5.1. Dynamische Prüfung: Code ausführen
6.5.1.1. Testen
6.5.1.2. Dynamische Analyse
6.5.2. Statische Prüfung
6.5.2.1. Metrikanalyse
6.5.2.2. Ohne Rechner: Review
6.6. Begriffe: Verifikation und Validierung
6.6.1. Verifikation (verification)
6.6.1.1. „Are we building the product right?“
6.6.2. Validierung (validation)
6.6.2.1. „Are we building the right product?“
6.7. Testmethoden
6.7.1. Black-Box Tests
6.7.1.1. Äquivalenzklassen
6.7.1.1.1. Wertebereich einer Eingabegrösse, für welche der Prüfling voraussichtlich das gleiche Verhalten zeigt
6.7.1.1.2. einTestfallpro Äquivalenzklasse
6.7.1.2. Grenzwertanalyse
6.7.1.2.1. Fehler sehr oft an Grenzen zulässiger Eingabewertebereiche
6.7.1.2.2. wählt Testfälle an den Grenzen
6.7.1.2.3. Erweiterung der Äquivalenzklassenmethode
6.7.1.3. Zustandbasiertes Testen
6.7.2. White-Box-Tests
6.7.2.1. Kontrollfluss-orientiertes Testen
6.7.2.1.1. Anweisungsüberdeckung
6.7.2.1.2. Zweigüberdeckung
6.7.2.1.3. Pfadüberdeckung
6.7.2.2. Datenfluss-orientiertes Testen
6.8. Testüberdeckung (test coverage)
6.8.1. Anweisungsüberdeckung (statement coverage)
6.8.1.1. Prozentualer Anteil der Anweisungen, die in Test ausgeführt werden
6.8.1.2. 100% Anweisungsüberdeckung ist Minimum
6.8.2. Zweigüberdeckung
6.8.2.1. Prozentualer Anteil der Kanten (Zweige), die in Test durchlaufen werden
6.8.2.2. Eine 100% Zweigüberdeckung enthält auch eine 100% Anweisungsüberdeckung
6.8.2.3. Zusätzlich werden auch alle „leeren Zweige“ durchlaufen
6.8.3. Pfadüberdeckung
6.8.3.1. Prozentualer Anteil der Pfade, die in Test durchlaufen werden
6.8.3.2. Ein Pfad ist ein möglicher Weg durch den Kontrollgraph
6.8.3.2.1. kleine Programme mit Schleifen -> riesige Anzahl Pfade
6.8.3.2.2. 100% Pfadüberdeckung nicht zu erreichen
6.8.4. Bedingungsüberdeckung
6.8.4.1. Zusammengesetzte Bedingungen - > verschiedene Kombinationen testen
6.8.4.2. Einfache Bedingungsüberdeckung
6.8.4.2.1. alle atomaren Bedingungen mind. einmal true und einmal false
6.8.4.2.2. garantiert keine 100%ige Anweisungsüberdeckung
6.9. Automatisierte Tests
6.9.1. Vorteile
6.9.1.1. Wiederholbarkeit -> Regressionstests
6.9.1.1.1. Absicherung bei Änderung, Portierung, Erweiterung
6.9.1.1.2. geringe/keine Kosten bei Wiederholung
6.9.1.2. Eindeutige Spezifikation
6.9.1.2.1. Testcode ist Programmcode und damit eindeutig
6.9.2. Nachteile
6.9.2.1. Mehr Code zu schreiben und zu pflegen
6.9.2.2. Testcode ist Programmcode
6.9.2.2.1. Werden wirklich die richtigen Anforderungen getestet?
6.9.2.2.2. Was muss überhaupt getestet werden?
6.10. Right-BICEP
6.10.1. Are the results right?
6.10.2. Are all boundary conditions CORRECT?
6.10.2.1. Conformance
6.10.2.2. Ordering
6.10.2.3. Range
6.10.2.4. Reference
6.10.2.5. Existence
6.10.2.6. Cardinality
6.10.2.7. Time
6.10.3. Can you check inverse relationships?
6.10.4. Can you cross-check results using other means?
6.10.5. Can you force error conditions to happen?
6.10.6. Are performance characteristics within bounds?
6.11. A TRIP
6.11.1. Automatic
6.11.2. Thorough
6.11.2.1. sorgfältig
6.11.3. Repeatable
6.11.4. Independent
6.11.4.1. keine Abhängigkeit zwischen Tests
6.11.5. Professional
7. Einführung
7.1. Software Engineering Definition
7.1.1. Software engineering is the application
7.1.1.1. of a systematic, disciplined, quantifiable approach
7.1.1.2. to the development, operation, and maintenance of software,
7.1.1.3. that is, the application of engineering to software.
7.1.2. Elemente Software-Engineering
7.1.2.1. Prozesse
7.1.2.1.1. beschreibt, wer was wann und wie tut
7.1.2.2. Prinzipien
7.1.2.3. Modelle
7.1.2.4. Notationen
7.1.2.5. Werkzeuge
7.2. RUP
7.2.1. Inception
7.2.2. Elaboration
7.2.3. Construction
7.2.4. Transition
7.2.5. Disciplines
7.2.5.1. Eine Displin (discipline) ist eine Menge zusammengehöriger Aktivitäten (activities) eines bestimmten Schwerpunktes der Softwareentwicklung
7.2.6. Modelle
7.2.6.1. Domain-Modell
7.2.6.1.1. abstrahiert den Problembereich
7.2.6.1.2. Zerlegt Problem in verständliche Teile -> Konzeptionelle Klassen, Konzepte (domain objects)
7.2.6.1.3. Kommunikation zwischen verschiedenen Rollen in Entwicklung
7.2.6.2. Design-Modell
7.2.6.2.1. abstrakte Darstellung der Lösung
7.3. Syntax vs. Semantik
7.3.1. Syntax
7.3.1.1. bezeichnet die (formal) definierte äussere Form einer Notation
7.3.2. Semantik
7.3.2.1. ist die Bedeutung einer Notation
8. Softwareanforderungen
8.1. Klassifikation
8.1.1. Software Anforderungen
8.1.1.1. Funktionale Was?
8.1.1.2. Nichtfunktionale Wie gut?
8.1.1.2.1. Leistung
8.1.1.2.2. Mengen
8.1.1.2.3. Qualitätsmerkmale
8.1.1.2.4. Randbedingungen
8.1.1.2.5. Schnittstellenanforderungen
8.2. Use Cases
8.2.1. Begriffe
8.2.2. Formate
8.2.2.1. Brief
8.2.2.2. Casual
8.2.2.3. Fully Dressed
8.2.3. Teile eines Uses Cases
8.2.3.1. Primary Actor
8.2.3.1.1. Supporting Actors
8.2.3.1.2. Offstage Actors
8.2.3.2. Stakeholders and Interests
8.2.3.3. Preconditions
8.2.3.4. Post Conditions / Success Guarantees
8.2.3.5. Main Success Scenario
8.2.3.6. Extensions
8.2.3.7. Special Requirements
8.2.3.8. Technology and Data Variation Lists
8.2.4. Vorgehen Use Cases
8.2.4.1. 1. Systemgrenzen festlegen
8.2.4.1.1. Software, HW/SW-System, Organisation
8.2.4.2. 2. Primäre Aktoren identifizieren
8.2.4.2.1. Ihre Ziele als Systembenutzer werden durch System erfüllt
8.2.4.3. 3. Ziele jedes Aktoren identifizieren
8.2.4.3.1. So abstrakt wie möglich auf Ebene EBP
8.2.4.4. 4. Use Cases schreiben
8.2.5. Details Use Case Diagramme
8.2.5.1. «include»
8.2.5.1.1. Teil von Use Case in separaten Subfunction Use Case ausgelagert
8.2.5.2. «extend»
8.2.5.2.1. Erweitert Basis Use Case
8.3. Anforderungsspezifikation
8.3.1. Korrektheit
8.3.2. Eindeutigkeit
8.3.3. Vollständigkeit
8.3.4. Konsistenz
8.3.5. Mit Gewichtung versehen bezüglich Wichtigkeit / Priorität / Stabilität
8.3.6. Überprüfbarkeit
8.3.7. Änderbarkeit
8.3.8. Verfolgbarkeit
9. Systemsequenzdiagramme
9.1. Aktoren, System als Blackbox
9.2. SSD beschreibt Use Case Szenario
10. Konfigurationsmanagement
10.1. Locking Verfahren
10.1.1. pessimistic Locking (default bei rcs)
10.1.2. optimistic Locking (default bei cvs/svn)
10.2. CVS Commands
10.2.1. Directory erzeugen
10.2.1.1. mkdir ~/foobar
10.2.2. CVS init
10.2.2.1. cvs -d ~/foobar init
10.2.3. neues Modul
10.2.3.1. mkdir sesame
10.2.3.2. cd sesame
10.2.3.3. files erzeugen...
10.2.3.4. cvs -d ~/foobar import -m"" sesame sesame initial
10.2.3.5. im importierten Directory (sesame) NICHT weiterarbeiten.
10.2.4. Arbeitsbereich anlegen
10.2.4.1. mkdir ~/work
10.2.4.2. cd ~/work
10.2.4.3. Modul auschecken:
10.2.4.3.1. cvs -d ~/foobar co sesame
10.2.5. Sonstige
10.2.5.1. Status einer Datei
10.2.5.1.1. cvs status Color.txt
10.2.5.2. Unterschiede?
10.2.5.2.1. cvs diff Color.txt
10.2.5.3. Commit Changes
10.2.5.3.1. cvs commit
10.2.5.4. Arbeitsbereich aktuell?
10.2.5.4.1. cvs -nq update
10.2.5.5. Status neuer Datei
10.2.5.5.1. cvs status Color.txt
10.2.5.6. Historie
10.2.5.6.1. cvs log Color.txt
10.2.5.7. Datei hinzufügen
10.2.5.7.1. cvs add Color.txt
11. Entwurf
11.1. logische Architektur
11.1.1. Klassendiagramm
11.1.1.1. Packages
11.1.1.2. Dependencies
11.2. physische Architektur
11.2.1. Tiers
11.2.2. UML Deployment Diagramm
11.3. Auswahl von Packages
11.3.1. Kohäsion (cohesion)
11.3.1.1. Mass für Zusammenhalt innerhalb (z.B. Packages)
11.3.1.2. In Package gruppieren, was zusammen eine gemeinsame Funktion erfüllt
11.3.2. Kopplung (coupling)
11.3.2.1. Mass für Abhängigkeit zwischen (z.B. Packages)
11.3.2.2. Schnittstellen möglichst schmal und einfach zwischen Packages
11.4. Interaktionsdiagrammen
11.4.1. Interaktionsdiagramme zeigen dazu das dynamisches Verhalten des Systems
11.4.2. Participants
11.4.2.1. unnamed instance
11.4.2.1.1. : Sale
11.4.2.2. named instance
11.4.2.2.1. s1 : sale
11.4.2.3. class based on another class
11.4.2.3.1. <<metaclass>> iClass
11.4.2.4. instance of ArrayList, parameterized to hold Sales
11.4.2.4.1. sales : ArrayList<Sale>
11.4.2.5. instance of Sale, from an ArrayList<Sale>
11.4.2.5.1. sales[i] : Sale
11.4.2.6. Singletons top right corner a 1
11.4.3. Instanz löschen
11.4.3.1. «destroy»
11.5. Notationselemente für Design-Klassendiagramme
11.5.1. Klassen, abstrakte Klassen, Vererbung, Interfaces
11.5.2. Assoziationen, Kompositionen, Aggregationen
11.5.3. Navigationspfade
11.5.3.1. Semantische Zusammenhänge
11.5.3.2. Nur dort, wo Links zwischen Objekten bestehen müssen (Sichtbarkeit nötig)
11.5.4. Abhängigkeiten (Dependencies)
11.5.4.1. Modelliert allgemein Abhängigkeiten zwischen Elementen
11.5.4.2. Wenn Assoziation, Vererbung braucht keine Dependency eingezeichnet werden
11.5.5. Attribute mit Typinformation und Sichtbarkeit
11.5.6. Methoden ev. mit Parameter und Rückgabewerten
12. GoF Pattern
12.1. Creational
12.1.1. Abstract Factory
12.1.1.1. Dann macht es Sinn, die Factories zusammenzufassen und eine gemeinsame abstrakte Klasse für diese Factory- Eigenschaften zu definieren.
12.1.1.1.1. oft bei umgebungsabhängigen Klassenhierarchien
12.1.1.1.2. mehrere Factory Methods zusammengefasst
12.1.2. Prototype
12.1.3. Singleton
12.1.3.1. Definiere eine statische Methode in der Singleton- Klasse. Diese Methode gibt das Singleton zurück
12.1.3.1.1. Achtung: Singletons sind globale Objekte ( -> hohe Kopplung! )
12.1.4. Factory Method
12.1.4.1. Unterklassen können das Verhalten ändern, durch Überschreiben der Factory Method
12.1.5. Builder
12.2. Structural
12.2.1. Adapter
12.2.1.1. Konvertiere inkompatible Schnittstelle über Adapterklasse, die das gewünschte Interface implementiert.
12.2.2. Bridge
12.2.3. Composite
12.2.3.1. Implementiere Klassen für einzelne (atomare) Objekte und zusammengesetzte Objekte mit einer gemeinsamen Schnittstelle.
12.2.4. Decorator
12.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
12.2.5. Flyweight
12.2.6. Facade
12.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.
12.2.7. Proxy
12.3. Behavioral
12.3.1. Chain of Responsibility
12.3.2. Command
12.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.
12.3.3. Iterator
12.3.3.1. Der Container stellt einen Iterator zur Verfügung, welcher Element um Element aus dem Container liefert
12.3.4. Mediator
12.3.5. Memento
12.3.6. Observer
12.3.7. State
12.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.
12.3.8. Strategy
12.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
12.3.9. Visitor
12.3.10. Template Method
12.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.
12.4. Null Object
12.4.1. Eine Klasse implementieren, welche das erforderliche Interface implementiert, deren Methoden aber nichts tun oder den geforderten Defaultwert liefern.
13. Projektmanagement
13.1. 4 Planungsfaktoren
13.1.1. Funktionalität (Scope)
13.1.2. Qualität
13.1.3. Zeit
13.1.4. Kosten