Mathematisch-

Naturwissenschaftliche Fakultät

Software Engineering II

Sommersemester 2022
Dr. Michael Striewe

Universität Potsdam
 Mathematisch-
Naturwissenschaftliche Fakultät

Kapitel 1

Einführung

Universität Potsdam
 Software-Systeme

• Betriebssysteme
• Steuerungssysteme
• Compiler
• Editoren
• Spiele
• Enterprise Applications / Informationssysteme /
Datenverarbeitung
• ...

Universität Potsdam 3
 Enterprise Applications - Beispiele

• Banken- und Versicherungsanwendungen

Software zur
– Kontoführung Unterstützung oder
– Analyse von Kreditwürdigkeit Automatisierung von
Geschäftsprozessen
– Prämienmanagement
in Unternehmen
– Mahnverfahren oder anderen
• Zahlungsabwicklung und Rechnungslegung Organisationen

• betriebliche Kostenanalyse
• Lagerverwaltung und Lieferkontrolle (shipping tracking)
• Online-Shops und Buchungssysteme
• Verwaltung von Patientendaten
• ...

Universität Potsdam 4
 Enterprise Applications - Merkmale (1)

• Große Datenmengen
– meist in relationalen Datenbanken, oft verteilt
• Persistente Daten
– in mehreren Programmläufen verfügbar
– überdauern oft Systemversionen, Hardware- oder
Betriebssystemwechsel
• Nebenläufige Datenzugriffe
– von mehreren Terminals des Unternehmens
– über Web-Interfaces / durch Web-Services
• Verschiedene Benutzer-Interfaces
– unterschiedliche Präsentation derselben Daten
– verschiedene Möglichkeiten/Rechte des Datenzugriffs

Universität Potsdam 5
 Enterprise Applications - Merkmale (2)

• Integration mit anderen Enterprise Applications

– Anwendungen verschiedener Generationen auf
unterschiedlichen Plattformen
– teilweise mit Zugriffen auf dieselben Daten
– Kommunikation mit anderen Anwendungen, z.T. von
anderen Unternehmen (z.B. Geschäftspartnern)

Universität Potsdam 6
 Enterprise Applications - Merkmale (3)

• Komplexe „Business-Logik”
– Fülle von Sonderfällen, häufig historisch gewachsen
– komplexe Bedingungen, die sich gegenseitig beeinflussen
– häufige und starke Veränderungen
– uneinheitliche Terminologie in verschiedenen
Unternehmensbereichen
-> Modellierung des Gegenstandsbereichs notwendig

Universität Potsdam 7
 Arten von Enterprise Applications

• Design-Entscheidungen abhängig von konkretem Fall

– Alternativen kennen! (Patterns, Tools, ...)
– Entscheidungsgrundlage entwickeln!
• Zwei Beispiele verschiedener Enterprise Applications:

Online-Shop
• einfacher Zugang
• einfache GUIs
• sehr viele nebenläufige
Transaktionen
• einfache Workflows
• Skalierbarkeit
Auto-Leasing
• weniger Geschäftsfälle
• komplexere Daten
• spezifische UIs
• komplexere Workflows
(Ausnahmen)

Universität Potsdam 8
 Architekturentscheidungen

Merkmale
• persistente Daten
• große Datenmengen
• nebenläufige Datenzugriffe
• verschiedene Benutzer-Interfaces
• Integration mit anderen Enterprise Applications
• komplexe Business-Logik / Domänenstruktur

... bestimmen Architekturentscheidungen

... bestimmt die Performance
(Antwortzeiten, Datendurchsatz, Skalierbarkeit etc.)

Universität Potsdam 9
 Frühe Datenverarbeitungssysteme

1.Batch-Systeme
Programme, die Dateien manipulierten
2.Client-Server-Systeme
1.Datenserver
2.Client mit UI und Anwendungscode

Wo ist die Business-Logik ?!

UI / Präsentation
Client
Domänenschicht
Datenserver
Datenschicht

Universität Potsdam 10
 Schichten-Architekturen

• Beispiel Netzwerkprotokolle FTP

(z.B. TCP/IP) TCP
• eine Schicht kennt/benutzt nur IP
die direkt darunter liegende Schicht ETHERNET
• Schichten haben Komponentencharakter
– kohärente, wiederverwendbare Einheiten
– weitgehend autonom
– wohldefinierte Schnittstellen
• geringe Abhängigkeiten (z.B. Wechsel des physikalischen
Netzes)
• Schichten leicht austauschbar (z.B. TCP - UDP; FTP - TELNET)
• Ausgangspunkte für Standardisierungen und Teamwork
• Anzahl der Schichten beeinflusst Performance

Universität Potsdam 11
 Die drei prinzipiellen Schichten
von Enterprise Applications
UI / Präsentation
Domänenschicht
Datenschicht
1.Präsentationsschicht
– UI: Interaktion mit Benutzer (lebend oder andere Anwendung)
– von Kommandozeile bis komplexes GUI oder Web-Interface
2.Domänenschicht
– Business-Logik
– Kern des Systems: was die Anwendung für die Domäne leistet
– z.B. Berechnungen anhand der Eingabe- und gespeicherten Daten,
Datenvalidierung, Auswahl der Daten, auf die zugegriffen wird etc.
3.Datenschicht
– Kommunikation mit anderen Systemen, die Aufgaben für die
Anwendung erfüllen (Datenbanken, Nachrichtensysteme,
Transaktionsmanager, andere Anwendungen, ...)

Universität Potsdam 12
 Domänenschicht

• Repräsentation von Daten und Verhalten der spezifischen

Anwendungsdomäne
• Klassenmodell, meist durch „Noun Identification“
– SE 1:
– Termini der Domäne werden durch Klassen repräsentiert
– Zusammenhänge zwischen den Termini werden durch
Klassenbeziehungen gekennzeichnet
– sehr eng am Domänenmodell (CIM) orientiert
– „Beherrschen” der semantischen Lücke

Universität Potsdam 13
 Warum ein Domänenmodell? (1)

• Beispiel: Umsatzabgrenzung aus Verträgen

– oft komplexe, vom Produkt abhängige Strategie
• ohne Domänenmodell:
– Prozeduraufruf am UI
– Sammlung der nötigen Daten (Vertrag, Produkt)
– Berechnung des Erlöses in Abhängigkeit von den Daten
(Business-Logik innerhalb der Prozedur)

mit wachsender Komplexität der

– Business-Logik

– Code-Duplizierung
– unstrukturierte Sammlung von Subroutinen

Universität Potsdam 14
 Warum ein Domänenmodell? (2)

• mit Domänenmodell:

vertrag: :Berechnungs-
:Produkt
Vertrag strategie

berechneUmsatz
berechneUmsatz(vertrag)
berechneUmsatz(vertrag)
new :Umsatz-
abgrenzung

Universität Potsdam 15
 Verantwortlichkeiten

• Verteilung der Verantwortlichkeiten (Use Cases) auf Klassen

– keine Häufung auf wenige Klassen; ggf. Split von Klassen
– z.T. Kapselung in reinen Serviceklassen
• oft Aufteilung der Domänenschicht in mehrere Teilschichten

UI/Präsentation
Serviceschicht agiert wie eine „API“ für die Anwendung
…
Domänenschicht

Datenschicht

Universität Potsdam 16
 Serviceschicht

• enthält Serviceklassen
• realisieren Use Cases
• Transaktions- und Sicherheitsmanagement
• Wieviel Verhalten (Business-Logik) in Serviceklassen?

kein Verhalten viel Verhalten

Service-Fassade: Zugriff auf Klassen

Weiterleitung von eines
Aufrufen Datenmodells

Universität Potsdam 17
 Beispiel

• Es sei folgendes Use Case Diagramm gegeben:

• Aufgabe:
– Erstellen Sie ein Datenmodell als Klassendiagramm.
– Erstellen Sie ein Servicemodell als Klassendiagramm.

Universität Potsdam 18
 Beispiel (Forts.)

Universität Potsdam 19
 Beispiel (Forts.)

Universität Potsdam 20
 Datenschicht

• riesige Datenmengen in EA meist in relationalen

Datenbanken
• Datenschicht der EA realisiert die Kommunikation
der Domänen-Schicht mit der Datenbank
(und anderen Teilen der Infrastruktur / des „Back-Ends“)
• prominente Kommunikationssprache: SQL

→ Konzentration der SQL-Befehle in ausgewiesenen Klassen

→ Business-Logik unabhängig von SQL
→ SQL-Anteile einfach zu finden / zu warten durch SQL-
Spezialisten

Universität Potsdam 21
 Relationale Datenbanken

• DB ist Menge von Tabellen (Relationen), z.B.:

Buch Erscheinungs-
Signatur Autor Titel Verlag
jahr
Id-1 I. Sommerville Software Engineering Pearson 2012
Patterns of Enterprise Addison-
Id-2 M. Fowler 2013
Application Architecture Wesley
Id-3 P. Stevens Using UML Pearson 2005
H. R. Nielson, Semantics with
Id-4 Springer 2007
F. Nielson Applications
• Zeile: Datensatz (Record)
• Spalte: Attribut
• Schlüssel: Attribut, das jede Zeile eindeutig identifiziert
• Tabelle als Relation: Buch ⊆ String × String × String × String × Integer
• Relationsschema: Buch ⊆ Signatur × Autor × Titel × Verlag ×
Erscheinungsjahr

Universität Potsdam 22
 Verknüpfung von Tabellen

Nutzer
Benutzer-ID Name Vorname

U-1 Mustermann Max

Tabellen ohne
Fremdschlüssel:
U-2 Musterfrau Maxi
„flache Tabellen”
U-3 Normalausleiher Otto

Entliehen
Benutzer-ID Signatur
Verbindung zu anderen
U-3 Id-2 Tabellen über deren Schlüssel
U-3 Id-4
(Fremdschlüssel)

U-1 Id-1

Universität Potsdam 23
 Objekt-Relationales Mapping (ORM)

• Transformation von Daten der Domänenschicht (Objekte) in

Formate anderer Systeme, meist relationaler Datenbanken
(Tabellen) und umgekehrt
• Objekt-Relationales Mapping (ORM)

Instanzen von Zeilen in

Datenklassen Datenbanktabellen

repräsentieren Instanzen von Tabellenspalten

Datenobjekte der Klassen der repräsentieren
Domäne Datenschicht Objektattribute

Klasse Tabelle

Universität Potsdam 24
 ORM

• grundlegende Techniken:
– Referenzen auf andere Objekte: Fremdschlüssel-Primärschlüssel-
Beziehung
– Schatteninformationen: ggf. Surrogatschlüssel, Zeitstempel etc.
• Herausforderungen:
– Assoziationen (many-to-many)
– Vererbung
– Attribute mit besonderem Datentyp (Collections, Maps, ...)
• Patterns (wiederverwendbare Lösungsschemata)
– Martin Fowler: Patterns of Enterprise Application Architecture. Addison
Wesley, Boston, 2003.
• kommerzielle ORM-Tools
– Hibernate
– ADO.NET
– ...

Universität Potsdam 25
 Abgrenzung der Schichten

• abhängig von der Komplexität der Anwendung

geringe Komplexität hohe Komplexität

Realisierung der Schichten Organisation der Domänenlogik

in Subroutinen in mehreren Schichten

• Unabhängigkeit der Daten- und Domänenschicht von der

Präsentationsschicht
– keine Aufrufe von unteren Schichten in die Präsentationsschicht
– UI-Austausch darf keine Änderungen „weiter unten” erfordern
(wie beim MVC-Pattern)

Universität Potsdam 26
 Code-Duplikationstest

• informaler Test, ob Schichten sinnvoll abgegrenzt sind:

Würde das Hinzufügen einer neuen Präsentation

Code-Duplikation bewirken?

• Zu duplizierender Code gehört nicht zur Präsentationslogik.

Würde das Hinzufügen einer neuen Datenquelle

Code-Duplikation bewirken?

• Zu duplizierender Code gehört nicht zur Domänenlogik.

Universität Potsdam 27
 EA und Nebenläufigkeit

• Enterprise Applications sind meist:

– Multi-User-Systeme
→ nebenläufige Business-Transaktionen
– Verteilte Systeme, die auf eine gemeinsame Datenbank
zugreifen
→ nebenläufige System-Transaktionen

UI / Präsentation Business-
System Domänenschicht Transaktionen
Transaktionen Datenschicht

Universität Potsdam 28