Softwaretechnik2

- Kunde kann jeder Zeit seine anforderung ändern (evolutionär) und agile mitwirken

- Anforderungen werden in Iteraktionen Stufen entwickelt und dem Kunden am Festegelegten Release vorgelegt.

- Kunde hat die möglichkeit vorher zu testen so dass festgestrellte fehler bugs gefixgt werden können.

Pair Programming

Kiss (Keep it short and simple 

TDD/Test drivern development

Zu zweit Programmiert. Einer ist für Qualitätssicherung und der andere Programmiert.

So einfach wie möglich halten um ein schnelles ergebniss vorzubringen. Unnötioges wird weggelassen.

Es wird zuerst getestet bevor produktiver Programm code geschrieben wird. 

- Kleine Aktion mit ergebnis

- mit wert für Akteure

- Grober Überblick des System Kernfunkionalitäten

                  - Was wird vom System UNterstützt

                  - nicht wie

- Use Cases werden immer von einem Akteur ausgelöst

- Rolle eines Useres im System

- Interagiert mit dem spezifizierten System

- löst das System aus 

Erweiterung vom Funktionen eines USe Cases 

1.   _____

2. ______ >>>>>>>>>>>

                            Condition fullfield   3. _______

                                                          4.________

Condition not fullfilled

5. ________________

6.__________

Der eine Anwenudngsfall beinhaltet einen anderen anwendungsfall 

Z.B: Password includes Passwort vergessen. Nach Passwort vergessen kommt die kommt es wieder zurück auf Passwort.

Schritt für Schritt

- Keine Paralle durchführung der Schritte

- Jeder Schritt wird nur einmal durchgeführt

- Jeder Schritt endet mit einer Doku

- Start mit den Kernanforderungen des Kunden

Die Vorstudie ist da für die Umsetzbarkeit zu prüfen, dazu muss das Problem bekannt sein und über mögliche lösungen diskutiert werden. 

Die Anforderungsanalyse dient zur definition der Anforderungen die an das Projekt gestellt werden. Dabei ist wichtig "was" das Produkt erfüllen soll und nicht "wie" es genau Implementiert werden soll. Das Ergeniss der Anforderungsanalyse ist das Pflichtenheft.

Die Objekte können nicht eigenständig existieren: z.B wenn der Ordner gelöscht wird, wird die Datei auch gelöscht.

Einfach verbindung zwischen den Objekten z.B. ein Kunde hat (0....*) nulll oder * Rechnung, aber eine Rechnung hat immer nur 1 Kunde.

Die Objekte können einsetig existieren z.B. das Rad kann auch ohne Auto existieren.

1. Vorstudie:

- was soll gelöst werrden (Problem "Wir brauchen ein eShop"

- Wie soll es gelöst werden (Technisch "Überwsicht")

- Wie vielk geld wird benötigt (Geld "1000")

- Wer wird benötigt (personal "Hardware")

2. Anforderungsanalyse:

-Anforderung spezifiezieren und festlegen

- Was soll das System können ?

- Resultat: Pflichtenheft

3. Design:

- Wie genau sieht die Software aus die die Anforderung erfüllt

- Grafik/Audio/Interaktions design

4. Implemntierung:

- Realisierung der SWA in Code

-Kurzes Testen

5. Integration und Einführung:

- Zusammenfassung der Programm - einzelteile

-Testen des ganzen Systems

- Testen beim Kunden + Installation

- Kunden Training + Start der Einführung /Installation

Wartung:

- Fehlerbehebung

- Optiemeieren (Verbesserungen)

- Anpassungen auf Gesetzliche und Technische Anforderungen.

Verbindung zwischen Akteuren und Use Cases

- Entdeckt welcher Akteuer an der use case ausführung teilnimmt

- Akteuer kann 

          - ein trigger sein für die ausführung eines use cases

          - ein aktiver oder passiver teilnehmer.

- Ein Akteuer kann in allen Use Cases teilnehmen in den der generelle teilnehmen kann.

- Für die Strukturierung der Use Cases

- Erbt das Verhalten vom den Mehr generalisierten usw case und überschreibt teile des verhalten.

- Erbt auch die Kommunikations Relations

Use Case: Name (Predikat + Objekt)

Kurze Beschreibung:

Kategorie: 

Precondition: Vor der Ausführung

Postcondition (erfolgreich): Was passiert wenn erfolgreich ausgeführt

Postcondition (nicht erfolgreich): Was passiert wenn nicht erfolgreich ausgeführt

Akteuere: 

Ausführer/Trigger:

Beschreibung:

Alternativen:

Bemerkungen: 

Viele andere Methoden gisbt noch.

- Klassen Diagramme zeigen die Stuktur des Systems die analysiert oder designed werden soll.

- Klassen Diagramme beantworten die frage wie die daten und die handlung struktiert sind

Grund:

- Objects

- Klassen 

- Generalisierung/Spezialisierung der Klassen

- assoziationen zwischen klassen und Objekten

mit minus werden die Atribute geschrieben und mit + die Operationen 

Notation: mit - und kleiner Buchstabe

Verschiedene Typen

z.B:

- number : int

-balance : float = 0,0

- owner : Customer

Statische Attribute ("Klassenatribute") werden mit einer unterlinie beschrieben die gelten für die ganze klasse

Generlaization zwischen klassen:

          - general class wird auch sper klasse genannt

          - spezifische klasse wird auch sub klasse genannt

Specialsierung ist das gegenteil von generalisierung

Bottom Up ist generalizierung.

Spezilation

Wenn eine Klasse nicht ein oder mehrere attribute hat die nicht immer einen richtigien value haben ? dann macht man spezialsierung.

- Leichte erstellung neuer Klassen, Spezielle Klassen

- wiederbenutzbarkeit der klassen ist empfehelsnwert

- veränderung in super klassen haben einen effect auf die subklassen: ein komfortabelen weg für veränderung mehrer klassen z.b. die Attribute verändern.

Cons:

- Veränderung der Super klasse wirkt direkt auf die subklassen aus: wenn man z.B. die Methoden ändert kann es sein das die effekte der veränderung nicht nachvollziehbar sind.

- um die sub klassen zu nverstehen müssen alle super klassen verstanden werden

- vererbung relationshio kann nicht verändert werden at runtime

1

0...1

*

3...*

0...2

2

2,4,6

seite 85

Create, Read, update, delete

Create: Erstellen eines neues Objekt  KundenManager::erstelleKunde():Kunde

Read: Liefert ein oder mehrer Objekte KundenManager::findKundebyIDC:Kunde

Update: Aktuallisiert ein Objekt KundenManager::updateKunde(KundenupdateObj)

Delete: entfernt ein Objekt: KundenManager :: delte (kundeObjektDelete)

Abstrakte klassen werden Kursiv geschrieben. 

Es muss mindestens eine Methode Implementiert sein

Nicht immer soll eine Klasse sofort ausprogrammiert werden. Zum Beispiel dann nicht, wenn die Oberklasse lediglich Methoden für die Unterklassen vorgeben möchte, aber nicht weiß, wie sie diese implementieren soll. In Java gibt es dazu zwei Konzepte: abstrakte Klassen und Schnittstellen (engl. interfaces).

Können nur in Abstrakten Klassen definiert werden. 

Werden Kursiv geschrieben.

102

107