Software Engineering 1

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.