Sie sind auf Seite 1von 89

6.

1 Analyse und Design


6.2 Programmerstellung und

Dokumentation
IHK Intensivlehrgang 2007 für IT-Berufe

Wolf-Günter Hebel
Inhalt
• Objektorientierte Analyse (OOA)
• Objektorientierter Entwurf (OOD)
• Objektorientierte Implementation
• Software-Ergonomie
• Entwicklungsumgebungen auswählen
• Konfigurationsmanagement
Konventionelle Analyse
Oft umgangssprachliche Beschreibung
der Anforderungen

 die Anforderungen
• vollständig
• widerspruchsfrei
• eindeutig und präzise
• verständlich
zu beschreiben gestaltet sich schwierig
Objektorientierte Analyse (OOA)
• Ermittlung und Beschreibung der
Anforderungen an ein Softwaresystem
mittels objektorientierter Konzepte und
Notationen.
• Das Ergebnis ist ein OOA-Modell

Problem:
Auftragsstellung oft unklar, widersprüchlich
fallorientiert, auf unterschiedlichen Abstraktions-
ebenen
OOA-Modell
• ist fachliche (keine technische!) Lösung für ein Problem
• Beschreibt essentielle Struktur und Semantik des Problems
• beschreibt Funktionalitäten/ Interaktionen auf abstrakter Ebene
• ist implementierungsunabhängig
• muss vollständig, widerspruchsfrei, eindeutig, realisierbar sein
• abstrahiert von technischen Rahmenbedingungen
• keine Berücksichtigung von Optimierungsstrategien
• kann umgangssprachlich oder z.B. in Diagrammen ( UML)
vorliegen
Software-Architektur
• bestimmt die Strukturierung des Systems in
Komponenten (Klassen, Packages, …)
• legt Beziehungen zwischen Komponenten fest
• definiert, wie Komponenten interagieren
• beschränkt sich auf die Black-Box-Eigenschaften
(d.h. nur diejenigen Informationen, die für die
Benutzung der Komponente erforderlich sind;
anders: nur das „was“, nicht das „wie“)
Pilotsysteme
• Ablauffähiges Programm
• können z.T. automatisch aus OOA generiert werden
• Prototyp der Benutzeroberfläche
• Enhält Menüs, Dialoge, Fenster usw.
• Keine Funktionalität (z.B. kein Speichern)
• dient zur Früherkennung von Fehlern im OOA-Modell
• Ermöglicht frühzeitige Erkennung von
Missverständnissen zw. Auftraggeber und
Systemanalytiker
Klassen (1)
• abstrakte Repräsentation der Real-World-
Entities
• definiert Struktur (Attribute)
• definiert Verhalten (Operationen)
• definiert Beziehungen (zu anderen Klassen)
• definiert Vererbungsbeziehungen
• Intension der Menge aller gleichartigen
Objekte (Klassenextension bezeichnet die
Menge aller Instanzen einer Klasse)
• Visualisierung in Klassendiagrammen
Klassen (2)
• Klassen müssen identifiziert werden;
in erstem Schritt z. B. aus Dokumentanalyse (z. B. aus
Rechnungsformular o. ä.)
• Ziel ist nicht die vollständige Darstellung aller Klassen,
sondern die Identifikation einiger Klassen
• Modellierung sollte aus Benutzersicht erfolgen (z.B. Auftrag
statt Bestellung)
• Attribute modellieren die zu verwaltenden Daten
• Operationen modellieren das Verhalten
• im weiteren Verlauf Identifikation z.B. aus Use Cases
Klassen (3)
Unterscheidung:

• Elementare Klassen (support classes)


modellieren Typen von Attributen

• Anwendungsklassen (problem domain


classes)
Stereotypen
• Klassifizieren Elemente des UML-Modells (z.B.
class, enumeration, structure)

«enumeration» «structure»
LandT AdresseT

Straße: string<30>
Belgien PLZ: string<5>
Deutschland Ort: string<30>
Finnland Land: LandT
Frankreich
Großbrittanien
Schweden
Schweiz
Spanien
USA
Aufzählungstyp
• enumeration type
• Wenn Attribut nur diskrete Werte annehmen
kann
• Modellierung als Klasse möglich
• Angaben zur minimalen und maximalen
Anzahl der zu selektierenden Elemente erf.
• Festlegung erforderlich, ob Werteliste
erweiterbar oder nicht
Strukturierter Typ
• structure
• setzt sich aus mehreren
unterschiedlichen Typen zusammen
• kann aus Standardtypen,
Aufzählungstypen oder anderen
strukturierten Typen bestehen
Defaults und Restriktionen
• Attribute können mit Vorgabewerten belegt
werden
• Es kann Abhängigkeiten zwischen Attributen
geben, die stets erfüllt sein müssen (z.B. für
Plausibilitätsprüfungen)

Default: AktuelleMwSt: Short = 19

Constraint: { Rechnungsdatum >= Bestelldatum}


Klassenattribute
• Attribute sind normalerweise Instanzattribute
 je instanziiertem Objekt kann dem Attribut ein eigener Wert
zugewiesen werden

• Klassenattribute existieren nur einmal gemeinsam für alle aus


der Klasse instanziierten Objekte

• Klassenattribute definieren Eigenschaften, die allen Objekten


gemeinsam sind

• Klassenazttribute werden in UML unterstrichen


Beispiel für extrahierte Klassen
Kunde Auftrag Artikel

Nummer: Serial Nummer: Serial Nummer: String<10>


Name: String<30> Bestelldatum: Date Bezeichnung: String<30>
Telefon: String<30> Rechnungsdatum: Date = current Preis: Currency
Fax: String<30> Bearbeiter: String<30> MwSt: Short = 19
E-Mail: Email Kreditkarte: KreditkarteT
Adresse: AdresseT

«enumeration» «structure» «structure» «enumeration»


LandT AdresseT KreditkarteT KarteT

Belgien Straße: string<30> Karte: KarteT = Mastercard Mastercard


Deutschland PLZ: string<5> Nummer: String<20> Visa
Finnland Ort: string<30> Gültig bis: String<20> Diners
Frankreich Land: LandT American Express
Großbrittanien
Schweden
Schweiz
Spanien
USA
Abgeleitete Attribute
• engl. derived attributes
• können aus ‚echten‘ Attributwerten berechnet werden
• werden in UML durch vorangestellten ‚/‘
gekennzeichnet

Artikel

Nummer: String<10>
Bezeichnung: String<30>
Preis: Currency
/Enthaltene MwSt: Currency
MwSt: Short = 19
Generelle Überlegungen
• Welche Attribute gibt es (Namen)?
• Von welchem Typ sind die Attribute?
• Welche Attribute sind mit Anfangswert belegt?
• Welche Restriktionen gelten?
• Welche Attribute sind Klassenattribute?
• Welche Attribute sind abgeleitete Attribute?
• Welche Attribute sind Muss-Attribute?
• Welche Attribute sind Schlüsselattribute?
• Welche Attribute sind nach Ersteingabe
‚eingefroren‘?
• Welche Attribute sind nicht im GUI änderbar?
Assoziationen (1)
• beschreiben Zusammenhänge zwischen Klassen
• besitzten Kardinalitäten
• können benannt werden
• sind binär oder höherwertig
• können reflexiv sein
• können gerichtet oder ungerichtet sein
• beteiligte Klassen erfüllen evtl. eine Rolle

Klasse 1 Klasse 2

Rolle Assoziationsname Rolle


Attribut1 Attribut1
Attribut2 1 0..* Attribut2

Operation1 Operation1
Operation2 Operation2
Assoziationen (2)
Besteller
Kunde Auftrag
1 0..*
Nummer: Serial Nummer: Serial
Name: String<30> Bestelldatum: Date
Telefon: String<30> Rechnungsdatum: Date = current
Fax: String<30> Geschenkempfänger Bearbeiter: String<30>
E-Mail: Email Kreditkarte: KreditkarteT
Adresse: AdresseT 0..1 0..*

Angestellter Chef

Name: String<40> Gehalt: Currency 0..1


Position: String<40>

Mitarbeiter
0..*
Assoziationen (3)
• Rollen- oder Assoziationsnamen sind anzugeben,
wenn mehr als eine Assoziation zwischen zwei
Klassen besteht

• Reflexive Assoziationen sind ohne Rollennamen im


Allgemeinen nicht verständlich
Assoziative Klassen
• an Assoziationen können Attribute hängen
• diese Attribute können keiner der beteiligten Klassen
zugeordnet werden

Auftrag
Artikel

Nummer: Serial
Nummer: String<10>
Bestelldatum: Date 0..* 1..* Bezeichnung: String<30>
Rechnungsdatum: Date = current
Preis: Currency
Bearbeiter: String<30>
MwSt: Short = 19
Kreditkarte: KreditkarteT
Position

Anzahl: Short
Abgeleitete Assoziationen
• Assoziationen, die Abhängigkeiten beschreiben, welche durch
andere Assoziationen bereits beschrieben werden
• werden durch vorangestelltes ‚/‘ gekennzeichnet

Kunde Auftrag
1 0..*

0..* 1

/kauft

0..* 1..*

Artikel Position
1 0..*
Navigationsrichtung (1)
Assoziationen können
• unidirektional oder
• bidirektional
sein

• Eine unidirektionale Assoziation drückt eine ‚kennt‘-


• Beziehung aus

• In UML wird von Navigation (navigability) gesprochen


Navigationsrichtung (2)

Kunde kennt Auftrag kennt


Aufträge Kunde
Kunde Auftrag
1 0..*
1

Auftrag kennt
Positionen

1..*

Artikel Position
1 Position kennt 0..*
Artikel
Aggregation
• Semantisches Konzept
• Entspricht einer ‚besteht aus‘- bzw. ‚ist Teil von‘-Beziehung

Ganzes Ganzes

besteht aus
ist äquivalent zu

Teil Teil
Komposition (1)
• Semantisches Konzept
• „Starke Form der Aggregation
• Jedes Objekt der Teilklasse kann zu einem Zeitpunkt
nur Komponente eines einzigen Objekts der
Aggregatklasse sein
• Die dynamische Semantik des Ganzen gilt auch für
seine Teile (propagation semantics)
• Die Lebensdauer der Teile ist an die Lebensdauer
des Ganzen gebunden (they live and die with it)
Komposition (2)
• Ein Dateiordner enthält 0 oder mehr
Dateiordner
Dateien
• Eine Datei kann maximal in einem
0..1 Ordner liegen (oder im
Stammverzeichnis)
• Wird ein Dateiordner verschoben,
0..*
so werden die enthaltenen Dateien
ebenfalls verschoben
Datei • Wird ein Dateiordner gelöscht, so
werden die enthaltenen Dateien
ebenfalls gelöscht
Restriktionen (1)
• beschreiben Abhängigkeiten von
Attributen
• durch Assoziationen Beschreibung über
Klassengrenzen hinweg möglich
Restriktionen (2)
Kunde
Auftrag
Nummer: Serial
Name: String<30> Besteller Bestellungen Nummer: Serial
Telefon: String<30> Bestelldatum: Date
Fax: String<30> 1 0..* Rechnungsdatum: Date = current
E-Mail: Email Bearbeiter: String<30>
Adresse: AdresseT Kreditkarte: KreditkarteT
/Gesamtumsatz: Currency Gesamtumsatz = /Gesamtbetrag: Currency
/Anzahl Bestellungen: Short Bestellungen.Gesamtbetrag
1 Gesamtbetrag =
to_Position.Gesamtpreis

Anzahl Bestellungen =
Bestellungen.cardinality

1..*
Artikel
Position
Nummer: String<10>
Bezeichnung: String<30> 1 0..*
Preis: Currency Anzahl: Short
/Enthaltene MwSt: Currency /Gesamtpreis: Currency Gesamtpreis =
Aktuelle MwSt: Short = 19 to_Artikel.Preis * Anzahl
Objektdiagramm (1)
• Modelliert Objekte, Attributwerte und Verbindungen
zwischen Objekten zu einem bestimmten Zeitpunkt
• ist Momentaufnahme des Systems
• Objekte können eindeutige Namen besitzen (z.B.
Auftrag_13454 :Auftrag) oder nur mit dem
Klassennamen benannt sein (:Auftrag); in letzterem
Fall handelt es sich um anonyme Objekte
• dienen zur Verdeutlichung der Aussage von
Klassendiagrammen
Objektdiagramm (2)

: Position : Artikel

: Kunde : Auftrag

: Position : Artikel
Vererbung (1)
• beschreibt Beziehung zwischen allgemeiner Klasse
(Basisklasse/Oberklasse) und spezialisierter Klasse
(Unterklasse)
• Unterklasse ist vollständig konsistent mit Oberklasse
• Unterklasse enthält zusätzliche Attribute und
Assoziationen
• Objekt der Unterklasse kann überall verwendet
werden, wo Objekt der Oberklasse erwartet wird
• nur zulässig zwischen Anwendungsklassen
• drückt eine ‚ist-ein‘-Beziehung aus
Vererbung (2)
• abstrakte Klassen sind nur als Oberklassen sinnvoll
• abstrakte Klassen können nicht instanziiert werden
• abstrakte Klassen definieren Gemeinsamkeiten ihrer
Unterklassen
• Oberklassenkandidaten lassen sich identifizieren
durch Suche nach Gemeinsamkeiten zwischen
Klassen (Generalisierung)
• Unterklassenkandidaten lassen sich identifizieren
durch Suche nach Spezialisierungen (werden immer
alle Attribute der Klasse verwendet?)
Vererbung (3)
Geschäftspartner
Artikel
{abstract}

Telefon: String<30>
Fax: String<30>
Nummer: String<10>
E-Mail: Email Bezeichnung: String<30>
Adresse: AdresseT Preis: Currency

Lieferant Kunde
Lagerartikel
Firma: String<30> Nummer: Serial
Ansprechpartner: String<30> Name: String<30>
/Gesamtumsatz: Currency Mindestmenge: Short
/Anzahl Bestellungen: Short Bestand: Short = 0
Vererbung (4)
Auftrag
Kunde
Nummer: Serial
Besteller Bestellungen Bestelldatum: Date
Nummer: Serial Rechnungsdatum: Date = current
Name: String<30>
1 0..* Bearbeiter: String<30>
Adresse: AdresseT
Kreditkarte: KreditkarteT
/Gesamtumsatz: Currency
/Gesamtumsatz: Currency
/Anzahl Bestellungen: Short
/Enthaltene MwSt: Currency
Kontakte: KontaktT MwSt: Short
Aktuelle MwSt: Short = 16

1..*
Lieferant
Artikel Position
0..1 0..* 1 0..*
Firma: String<30> Nummer: String<10> Anzahl: Short
Ansprechpartner: String<30> Bezeichnung: String<30> Einzelpreis: Currency
Adresse: AdresseT Preis: Currency /Gesamtpreis: Currency
Kontakte: KontaktT

«structure»
KontaktT Lagerartikel

Telefon: String<30>
Mindestmenge: Short
Fax: String<30>
Bestand: Short = 0
E-Mail: Email
Vererbung (5)
Auftrag
Kunde
Nummer: Serial
Besteller Bestellungen Bestelldatum: Date
Nummer: Serial
Rechnungsdatum: Date = current
Name: String<30>
1 0..* Bearbeiter: String<30>
Adresse: AdresseT
Kreditkarte: KreditkarteT
/Gesamtumsatz: Currency
/Gesamtumsatz: Currency
/Anzahl Bestellungen: Short
/Enthaltene MwSt: Currency
Kontakte: KontaktT
MwSt: Short
Aktuelle MwSt: Short = 16

Artikel 1

Nummer: String<10>
0..1 0..* 1 1..*
Bezeichnung: String<30> 0..*
Lieferant Preis: Currency
Position

Firma: String<30> { or } Anzahl: Short


Ansprechpartner: String<30> 1 0..*
0..1 0..* Einzelpreis: Currency
Adresse: AdresseT
Lagerartikel /Gesamtpreis: Currency
Kontakte: KontaktT

Nummer: String<10>
Bezeichnung: String<30>
Preis: Currency
Mindestmenge: Short
Bestand: Short = 0
Vererbung (6)
• Vererbungsstrukturen sollten den ‚natürlichen‘
Strukturen des Problembereichs entsprechen (ist
semantisch ein Objekt der Unterklasse tatsächlich
auch ein Objekt der Oberklasse?
• Vererbungsstrukturen sollten nicht zu tief sein (max.
3 Ebenen); sonst kann es zu Verständnisproblemen
kommen

ES GIBT NICHT DAS EINE RICHTIGE MODELL UND


ALLE ANDEREN MODELLE SIND FALSCH!
Pakete (1)
• Packages
• dienen der Bildung von Teilsystemen
• fassen Modellelemente (z.B. Klassen) zusammen
• können selbst andere Pakete enthalten
• definieren einen Namespace für die enthaltenen
Modellelemente
• jedes Element gehört zu höchstens einem Paket,
kann aber aus mehreren anderen Paketen referenziert werden
• werden in UML in Klassendiagrammen eingetragen
• enthält das Klassendiagramm nur Pakete, so sprechen wir von
einem Paketdiagramm
Pakete (2)
Anwendungsklassen Elementare Klassen

+ Artikel
+ AdresseT
+ Auftrag
+ KarteT
+ Kunde
+ KontaktT
+ Lagerartikel
+ KreditkarteT
+ Lieferant
+ LandT
+ Position
Pakete (3)
Shopklassen

Anwendungsklassen Elementare Klassen

+ Artikel
+ AdresseT
+ Auftrag
+ KarteT
+ Kunde
+ KontaktT
+ Lagerartikel
+ KreditkarteT
+ Lieferant
+ LandT
+ Position
Definition: Use Case
Business Use Case, Geschäftsprozess

Ein Use Case beschreibt die Funktionalität des


Softwaressystems, die ein Akteur ausführen muss, um
ein gewünschtes Ergebnis zu erhalten oder um ein Ziel
Zu erreichen.

Use Cases ermöglichen das Sprechen über


Funktionalität des Systems, ohne sich gleich in Details
zu verlieren.
Use Case (1)
• modelliert genau einen Geschäftsprozess
• beschreibt einen Vorgang bzw. eine
Funktionalität
• ermöglichen Verständnis über Struktur und Abläufe in
einer Organisation
• erlauben die Ableitung von Funktionalitäten des
Softwaresystems
• unabhängig von Implementierung
• Darstellung natürlichsprachlich und/oder z.B. in UML
durch Aktivitätsdiagramm
• Abstraktionsgrad nach Bedarf wählbar
Use Case (2)
• Welches Ziel soll mit dem Geschäftsprozess erreicht werden?
• Welches Ereignis löst den Geschäftsprozess aus?
• Welche Voraussetzungen (Vorbedinungen) müssen erfüllt sein?
• Welche Verarbeitungsschritte müssen im Standardfall
ausgeführt werden?
• In welcher Reihenfolge müssen sie ausgeführt werden?
• Welche Erweiterungen des Standardfalls sind möglich?
• Welche Alternativen sind möglich?
• Wo ist Parallelverarbeitung erlaubt?
• Wer ist für welche Verarbeitungsschritte verantwortlich?
Use Case (3)
• Geschäftsprozess: Auftrag ausführen
• Ziel: Ware an Kunden geliefert
• Kategorie: primär
• Vorbedingung: Artikel sind erfasst
• Nachbedingung Erfolg: Ware ausgeliefert
• Nachbedingung Fehlschlag: Ware nicht lieferbar
• Beteiligte: Kundensachbearbeiter, Lagersachbearbeiter
• Auslösendes Ereignis: Bestellung des Kunden trifft ein
Use Case (4)
Beschreibung
1 Kundendaten abrufen
2 Auftragspositionen erfassen
3 Rechnung drucken
4 Kreditkarte belasten
5 Auftrag vom Lagersachbearbeiter ausführen lassen

Erweiterungen
1a Kundendaten aktualisieren
2a Artikel vom Lieferanten beziehen
2b Artikel herstellen

Alternativen
1a Neukunden erfassen
Start

Kundendaten
Verarbeitungsschritt
abrufen

Verzweigung Anfang

Bedingung [Neu- Kunde]


[„alter“ Kunde mit
neuen Daten]
Aktivitäts-
Kunde neu
erfassen
[„alter“
Kunde]
Kundendaten
aktualisieren
Diagramm (1)
Verzweigung Ende

Auftragsposi-
tionen erfassen
Reihenfolge der
Schritte
Rechnung
drucken

Kreditkarte
belasten

Ware packen und


Versenden lassen

Beispiel: Auftrag ausführen


Ende
Kundendaten
abrufen

[Neu- Kunde]
[„alter“ Kunde mit
neuen Daten]
Aktivitäts-
Diagramm (2)
[„alter“
Kunde]
Kunde neu Kundendaten
erfassen aktualisieren

Auftragsposi-
tionen erfassen

Gabelung

Rechnung Kreditkarte
drucken belasten

Zusammenführung

Ware packen und


Versenden lassen

Beispiel: Auftrag ausführen


Verkauf Lager

Kundendaten
abrufen

[Neu- Kunde]
[„alter“
[„alter“ Kunde mit
neuen Daten]
Aktivitäts-
Diagramm (3)
Kunde]
Kunde neu Kundendaten
erfassen aktualisieren

Auftragsposi-
tionen erfassen

Rechnung Kreditkarte
drucken belasten

Darstellung der Aktivitäten


gruppiert nach organi-
Ware packen und
Versenden lassen

satorischer Einheit in sog.


Schwimmbahnen.
Szenarios (1)
Ein Use Case beschreibt in der Regel
verschiedene mögliche Wege bzw.
Abläufe vom Start zum Ziel.

Ein Szenario beschreibt genau einen


möglichen Weg, also eine genau
definierte Reihenfolge von Schritten
durch einen Use Case.
Aktion 1 Szenarios (2)
Aktion 2a erf. Aktion 2b erf.

Aktion 2a Aktion 2b

Aktion 3
Aktion 1 Szenarios (3)
Aktion 2a erf. Aktion 2b erf.

Aktion 2a Aktion 2b

Szenario 1
Szenario 2

Aktion 3
Use Case-Modell
Die Menge aller Use Cases in einem
Softwaresystem, d.h. die komplette
Funktionalität.

Das Use Case-Modell ersetzt die


traditionelle funktionale Beschreibung.
Definition: Use Case-Diagramm

Ein Use Case-Diagramm beschreibt die


Beziehungen zwischen Akteuren und Use
Cases in einem Softwaresystem.
Auch Beziehungen zwischen Use Cases
können eingetragen werden
Use-Case-Diagramm (1)
• beschreibt funktionale Anforderungen
an ein Softwaresystem
• beschreibt Benutzerfunktionalitäten
• definiert Akteure, die mit dem System
interagieren
• definiert das wer und was
• abstrahiert vom wie und wann
Use-Case-Diagramm (2)

Akteur Kommunikation zwischen Use Case


Akteur und Use Case

Auftrag
bearbeiten

Kunden-
Sachbearbeiter
Use-Case-Diagramm (3)
System-Grenze Use Case
Akteur
Online-Shop

Online-Auftrag Online-Auftrag
erteilen bearbeiten

Online-Kunde

Kunden-
Artikel Auftrag Sachbearbeiter
erfassen bearbeiten

Hilfskraft
Methoden (1)
Akteure identifizieren

• Wer wird das System benutzen?


• Wer gibt Daten in das System ein?
• Wer erhält Daten aus dem System?
Methoden (2)
Use Cases identifizieren und spezifizieren
• Wie werden die Akteure das System nutzen?
• Welches Ergebnis will der Akteur erreichen?
• Wann beginnt/endet der Use Case?
• Welche Vorbedingungen müssen erfüllt sein?
• Was ist der Standardfall?
• Welche Alternativen gibt es?
• Welche Erweiterungen sind möglich?
Extension Points
• ermöglicht zunächst Konzentration auf
die Standardfunktionalität
• ermöglicht spätere Erweiterung

extension points
«extend» Artikel bei Lieferant
Artikel nicht auf Lager
beziehen

Auftrag ausführen
Include-Beziehung
• Auslagerung von Teil-Use Cases in
seperaten Use Case (wie Prozedur)

Wareneingang aus Wareneingang aus


Einkauf bearbeiten Produktion bearbeiten

« in
clu de»
de
» i nclu
«

Gemeinsame
Ware einlagern Komponente beider
Use Cases bildet
neuen Use Case
Botschaften
• Synonym: message, Nachricht
• Aufforderung eines Senders (Client) an
einen Empfänger (Server), eine
Dienstleistung zu erbringen
• Operations-/Methodenaufruf zwischen
Objekten
Sequenz
• Abfolge von Botschaften zwischen
Objekten im Rahmen eines Szenarios
• Visualisierung als Sequenzdiagramm
Sequenzdiagramm (1)
• zeigt Kommunikation zwischen
Objekten untereinander
• alle beteiligten Objekte werden in
beliebiger Reihenfolge an der
Horizontalen angetragen
• Vertikale definiert die zeitliche
Reihenfolge, in der die Teilaufgaben
ausgeführt werden
Sequenzdiagramm (2)
Fragestellungen

• Welche Objekte wirken im Szenario mit?

• Existieren die Objekte für die gesamte Zeitdauer des


Szenarios? (Objektlinie def.)

• Mit welcher Botschaft beginnt die Interaktion der


Objekte?
Sequenzdiagramm (3)
:Auftrag :Kunde :Position :Lagerartikel
Kundensachbearbeiter

erfassen

auswählen

erfassen
Zeitachse

auswählen

Drucke Rechnung

reduziere Bestand
Software-Entwurf
• erstellt auf Basis des OOA-Modells eine technische
Lösung
• Weiterentwicklung des OOA-Modell in ein OOD-
Modell unter Berücksichtigung von Effizienz und
Standardisierung
• Einsatz von Entwurfsmustern (Design patterns)
• Nutzung von Frameworks
• Definition Objekt-relationale Abbildung
• OOD-Modell kann direkt implementiert werden
Entwurfsmuster
Gibt eine bewährte, generische Lösung für ein immer
wiederkehrendes Entwurfsproblem an, das in
bestimmten Situationen auftritt.

Es gibt Entwurfsmusterkataloge (z.B. „Gang-of-Four“),


die Einsatzzweck, Vorteile, Einschränkungen und
allgemeine Struktur (Klassen, Assoziationen usw.)
beschreiben
Observer-Pattern

Subjekt Beobachter
{abstract} {abstract}

meldeAn(Beobachter) meldeAb(Beobachter) 0..*


aktualisiere()
benachrichtige()

Beobachter
konkretes Subjekt
{abstract}

Subjekt-Daten Beobachter-Daten
1
leseDaten()
aktualisiere()
schreibeDaten()
Singleton-Pattern
Stellt sicher, dass eine Klasse nur ein einziges Mal
instanziiert wird

public class Singleton{


Singleton private static Singleton s = null;

public Singleton getInstance(){


-instance
if (s == null)
s = new Singleton();
-Singleton()
+Instance(): Singleton return s;
}
}
Frameworks
• besteht aus einer Menge zusammenarbeitender Klassen,
die einen wiederverwendbaren Entwurf für einen
bestimmten Anwendungsbereich definieren
• besteht aus konkreten und v. a. abstrakten Klassen
• kann vom Entwickler erweitert werden, um konkrete
Aufgabenstellung zu lösen
• reduziert Entwicklungsaufwand durch vorgefertigte
Funktionalitäten
• erfordert z. T. hohen Einarbeitungsaufwand
• erzeugt Abhängigkeit vom Framework-Hersteller
O/R-Mapping
• Speicherung von Daten meist in relationaler
Datenbank
• Klassen und Assoziationen müssen auf Tabellen und
Fremdschlüsselbeziehungen abgebildet werden
• Berücksichtigung von Performance-Aspekten!

Probleme:
• Abbildung von Vererbung
• Abbildung von Strukturtypen
Schichten-Architekturen
• Aufteilung der Funktionalität einer Anwendung in
sogenannte Schichten
• Schichten kommunizieren über definierte Schnittstellen
ausschließlich mit der/den direkt benachbarten
Schicht(en)
• einzelne Schichten sind austauschbar; sofern die
Schnittstelle beibehalten wird beinflusst der Austausch
nicht die Funktionsfähigkeit des Ganzen
• Wir unterscheiden Zwei- oder Mehrschicht-Architekturen
(Two-Tier/Multi-Tier-Architecture)
Zwei-Schichten-Architektur
Typischerweise
• eine Datenhaltungs-Schicht
• Eine Anwendungs-Schicht
für Darstellung und Anwendungsschicht

Anwendungslogik.

Datenhaltungsschicht
Drei-Schichten-Architektur
GUI-Schicht
Typischerweise
• eine Datenhaltungs-Schicht,
• eine Anwendungslogik-Schicht
• eine Präsentation-Schicht GUI).
Fach-Konzeptschicht

Datenhaltungsschicht
Mehr-Schichten-Architektur
GUI-Schicht

Präsentation der Information

Fachkonzept-Zugriffsschicht

Kommunikation zwischen GUI


und Fachkonzept

Fachkonzeptschicht

Modellierung des Problembereichs


Datenhaltungs-Zugriffsschicht

Kommunikation zwischen Fachkonzept


Und Datenhaltung
Datenhaltungsschicht

z. B. Datenbank
Software-Ergonomie (1)
Unter Software-Ergonomie verstehen wir normalerweise
die Gestaltung der Benutzeroberfläche (GUI) in einer
Art und Weise, die

• vom Design ansprechend ist


• übersichtlich ist
• Suchzeiten (in der Maske) vermeidet
• zügige Arbeitsabläufe ermöglicht
• den Benutzer ‚an die Hand‘ nimmt
• sich an gültige Standards und Konventionen hält
Software-Ergonomie (2)
• Semantisch zusammengehörige Elemente gruppieren
• Bei Bedarf Hervorhebungen z.B. durch Farbe/Kontrast, Größe,
Einzelstellung, …
• Gleichmäßige Verteilung
• Symmetrische Aufteilung
• Sinnvolle Anordnung/Reihenfolge der Felder
• Benutzer führen (sequenziell, keine unnötigen Sprünge!)
• „Keep it Simple“: keine Überfrachtung mit Farben,
verschiedenen Schriften usw.
• Virtuelle Linien minimieren
• Aber: Fachlicher Verwendungszweck hat Vorrang vor Linien-
Minimierung (z.B. Textfelder nicht unnötig vergrößern)
Entwicklungsumgebung (1)
• welche Programmiersprache soll/muss verwendet
werden?
• welche Kenntnisse besitzen die Entwickler?
• für welche Compiler liegen Lizenzen vor?
• für welche(s) Betriebssystem(e) wird die Anwendung
entwickelt?
• welche Schnittstellen müssen verwendet werden?
• welche Komponenten müssen integriert werden?
• wie beschleunigt eine bestimme Sprache /
Entwicklungsumgebung die Entwicklung?
Entwicklungsumgebung (2)
• können zusätzliche Tools in die IDE integriert
werden?
• ggf. Zusammenarbeit mit CASE-Tools?
• inwieweit unterstützt die IDE die Entwickler?
(Debugging, autom. Vervollständigung, …)
• wie gut ist die Sprache/IDE dokumentiert und
supported? (Newsgroups, Communities, …)
• wird Teamarbeit direkt unterstützt? Wie?
• wird Konfigurationsmanagement unterstützt? Wie?
• Vorlieben der Entwickler
Konfigurationsmanagement (1)
Software-Konfigurationsmanagement behandelt

• das Bearbeiten von Quellcode durch mehrere


Entwickler zur selben Zeit
• das Verfolgen von Versionsständen und ihren
Änderungen (nicht nur von Quellcode!!!)
• das Steuern der Integration der einzelnen Teile der
Software zu einem Produkt
Konfigurationsmanagement (2)
• Konfigurationsmanagement erfolgt mit Hilfe von Tools
• es existiert keine universelle All-in-one-Lösung
• flexible Lösungen entstehen durch den gezielten
Einsatz verschiedener spezialisierter Tools für
definierte Teilaufgaben.

• Versionsverwaltung, gemeinsames Arbeiten:


z.B. CVS, SVN, Visual Source Safe, …
• Dokumentenmanagement: z.B. WiKi, MS SharePoint,

• Integration: Make-Tools (meist in IDE integriert)
Konfigurationsmanagement (3)
• Konfigurationsmanagement ist mehr als eine Menge
von Tools!
• Konfigurationsmanagement ist mehr eine
Vorgehensweise
• Vorgehensweise muss definiert, kommuniziert und
festgehalten werden
• Vorgehensweise muss eingehalten werden!
Dokumentation (1)
• Anwenderdokumentation (Benutzerhandbuch)

• Administrationsdokumentation (Admin-Handbuch)

• Entwicklerdokumentation

• OOA-Modell

• OOD-Modell
Dokumentation (2)
Entwicklerdokumentation
„Der Quellcode ist die einzig gültige Dokumentation“

• Quellcode muss dokumentiert werden


• Es muss Vorgaben geben, wie die Codierung und
deren Dokumentation zu erfolgen hat
• Die Einhaltung dieser Vorgaben ist sicherzustellen
Dokumentation (3)
Best Practices

Je Prozedur/Funktion ein Dokumentationskommentar:

• was tut die Funktion?


• welche Vor-/Nachbedingungen müssen erfüllt sein?
• was bedeuten die Parameter (welche Werte können
sie ggf. angeben)?
• was liefert die Funktion zurück (wie ist der
Rückgabewert zu interpretieren)?
Dokumentation (4)
• Bei ‚trivialen‘ Funktionen Abweichung möglich
• komplexe oder schwer nachvollziehbare Codeteile
sind gesondert zu dokumentieren
• Nach Möglichkeit sollte eine Methode verwendet
werden, welche eine automatische Erstellung einer
Dokumentation ermöglich
(z.B. JavaDoc, .NET-Dokumentationskommentare +
NDoc od. Sandcastle, …)

• Machen Sie Dokumentationen allgemein verfügbar!!!


Dokumentation (5)
Beispiel (C#):

///<summary>
///Speichert eine Objektinstanzen vom Typ Adresse (das Objekt _
muß bereits seinen Primärschlüssel besitzen!)
///</summary>
///<param name="data">das zu speichernde Objekt vom Typ _
Adresse</param>
///<param name="lazySave">gibt an, ob zunächst geprüft werden _
soll, ob eine Datenänderung stattgefunden hat und führt die _
eigentliche Speicherung nur im Bedarfsfall aus</param>
///<param name="maId">Referenz auf die Person, die die Aktion _
ausgelöst hat (Guid oder int)</param>
public static bool storeAdresse
(Adresse data, bool lazySave, object maId)
{
...
}
Danke für Ihre
Aufmerksamkeit!