Kapitel 5: Entwurf

Überblick Dienstleistungen Bausteine Methodiken Entwurfsmuster 

Teil V 

Entwurf 

201


5.1 Überblick: Entwurf 

• aus Anforderungen (Pflichtenheft, Produktmodell (OOA)) 

Software-Architektur und Spezifikation der Systemkomponenten 

entwerfen 

• Software-Architektur: 

• Zerlegung in Systemkomponenten und Beziehungen hierzwischen 

• Systemkomponente: Klasse, Modul, . . . 

• bei vielen Komponenten ggfs. Strukturierung in Schichten 

202


Schichtenarchitektur 

• innerhalb von Schicht: beliebige Zugriffe zwischen Komponenten 

• zwischen Schichten: 

• Zugriff nur auf niedrigere Schichten 

• Ordnung z.B. strikt, linear (Bsp.: OSI) oder baumartig 

• enge Schnittstellen 

• Vor- und Nachteile: 

• übersichtlich 

• gute Wiederverwendbarkeit, Wartbarkeit und Testbarkeit 

• geringer Effizienzverlust (z.B. Fehlermeldungen durchreichen) 

• typisch: ≥ 3 Schichten 

203


Schichtenarchitektur: Typische Beispiele 

Web−Client Server Client 

Präsentation 

HTML 

Browser 

Webzugang 

JSP, Servlets, ASP, PHP 

Geschäftslogik 

EJB, .NET, PHP 

Datenhaltung 

RDBMS 

Präsentation 

Swing, VB 

204


Entwurfsentscheidungen 

• sequentiell ↔ parallel/verteilt/nebenläufig? 

Bsp.: verteilt → Client/Server 

• ein Benutzer ↔ mehrere Benutzer? 

→ Zugriffsrechte, Transaktionen? 

• Zuordnung der Schichten zu Client bzw. Server 

z.B. Client: Schichten 1+2, Server: 3, oder 

Client: 1, Server: 2+3, oder: C: 1+2a, S: 2b+3 

• unterschiedliche Plattformen nötig? → z.B. welche Sprache? 

• Wiederverwendung vorhandener Bausteine? 

205


Entwurfsentscheidungen (Fortsetzung) 

• ob und welche Hilfesysteme? (Hypertext?) 

• ob und welches DBMS (relational, OO)? 

• wie Benutzerschnittstelle? (GUI, . . . ) 

• Einbinden von sonstigen Dienstleistungen? 

z.B. Business Rules Engine wie Drools (→ KI) 

• Ziel: möglichst viele und mächtige Dienstleistungen in Anspruch 

nehmen → Kostensenkung 

206


1. nicht graphisch 

5.2 Einbinden von Dienstleistungen 

5.2.1 Realisierung der Benutzeroberfläche 

2. GUI (graphical user interface) 

z.B. mit Frameworks wie Java AWT, Swing oder SWT 

3. HTML mit Formular und ggf. AJAX 

4. . . . 

unter Verwendung von Servlets, JSP, JSF, . . . 

207


Graphische Benutzerschnittstellen (GUIs) 

• Bibliothek zur Unterstützung von Fenstern, Menüs, Piktogrammen, 

Schaltflächen, Maus, . . . 

• GUI bemerkt, interpretiert und leitet Ereignisse weiter an 

Anwendung 

• Anwendung reagiert auf Ereignisse 

• Ereignisreihenfolge unvorhersehbar 

• → Entwurf: verwendet unabhängige Systemkomponenten 

• Kommunikation zwischen GUI und Anwendung über Callbacks: 

• Anwendung registriert Ereignisse, 

über die sie informiert werden will 

• Callback aktiviert bei Ereignis zugehörige Anwendungsmethode 

• Verbindung von Anwendung zu GUI über API 

208


Anwendung 3 

Anwendung 1 

¡ ¡ ¡ ¡ 

¢¡¢¡¢¡¢¡¢¡¢ 

¡ 

¡ ¡ ¡ ¡ ¡ 

¢¡¢¡¢¡¢¡¢¡¢ 

£¡£¡£¡£¡£¡£¡£¡£¡£ 

¤¡¤¡¤¡¤¡¤¡¤¡¤¡¤¡¤ 

¢¡¢¡¢¡¢¡¢¡¢ 

£¡£¡£¡£¡£¡£¡£¡£¡£ 

¤¡¤¡¤¡¤¡¤¡¤¡¤¡¤¡¤ 

¡ ¡ ¡ ¡ ¡ 

¤¡¤¡¤¡¤¡¤¡¤¡¤¡¤¡¤ 

£¡£¡£¡£¡£¡£¡£¡£¡£ 

£¡£¡£¡£¡£¡£¡£¡£¡£ 

¤¡¤¡¤¡¤¡¤¡¤¡¤¡¤¡¤ 

¤¡¤¡¤¡¤¡¤¡¤¡¤¡¤¡¤ 

£¡£¡£¡£¡£¡£¡£¡£¡£ 

Einsatz eines GUI 

GUI 

API 

Programmierer 

Anwendung 2 

Anwendung 1 

Anwendung 3 

209


direkte Verarbeitung durch GUI 

FU1 

A 

B 

Fenster 

FU2 

Callback-Mechanismus mit Listen 

Benutzeraktion callback−Listen Anwendung 

button 

key event 

sizing event 

menucommand event 

button 

event 

Event− und 

Translation− 

Manager 

FU1 

FU2 

... 

press 

menu 

button 

release Proc 4 

... ... 

down 

up 

... 

Proc 1 

Proc 2 

... 

Proc 3 

key 

Proc 5 

Proc 6 

... 

callback 

Proc 1 

Menuevent(FU1) 

... 

case B: ... 

Proc 3 

on Buttonclick: 

if ... 

Proc 5 

InputControl::Keydown 

... 

case A: ... 

if (ASCIIChar(e)==X) 

210


Name 

Benutzerschnittstellen-Frameworks (Bsp. Java AWT) 

Kunde 

Abbruch 

Neu 

Mai 

1 

3 

AWTEventMulticaster 

... 

... ... 

ActionListener 

GUI 

4 

2 

Mai 

Object 

Component 

... 

FlowLayout 

Button Label TextComponent Container 

Programmierer erzeugt Objektnetz 

:Frame :Label :Button 

:Button 

label= "Neu" 

Text="Name" 

text= "Mai" 

5 "Mai" 

:TextField 

... 

... ... ... ... 

TextField Window 

label= "Abbruch" 

6 

Mai 

... ... 

Frame 

Anwendung 

Kunde 

Name 

Init 

Kunde 

Name= "Mai" 

211


Beispiel: Java AWT 

import java.awt.*; import java.awt.event.*; 

public class KundenGUI extends Frame 

} 

implements ActionListener{ 

protected Kunde kunde = new Kunde(); 

private Button Neu = new Button("Neu"); 

private Button Abbruch = new Button("Abbruch"); 

private Label textlabel = new Label("Name"); 

private TextField Namensfeld = new TextField(10); 

public KundenGUI(){...} 

public void actionPerformed(ActionEvent event){...} 

static public void main(String[] args){ 

new KundenGUI();} 

212


public KundenGUI(){ 

super("KundenGUI"); 

setLayout(new FlowLayout()); 

Neu.addActionListener(this); 

Abbruch.addActionListener(this); 

Namensfeld.setEnabled(true); 

Namensfeld.setText(""); 

add(textlabel); add(Namensfeld); 

add(Abbruch); add(Neu); 

setBounds(400,400,150,200); 

setVisible(true);} 

Beispiel: Java AWT (Fortsetzung) 

public void actionPerformed(ActionEvent event){ 

try{ 

if (event.getSource().equals(Neu)) 

kunde.Init(Namensfeld.getText()); 

else if (event.getSource().equals(Abbruch)) 

dispose();} 

catch (Exception e){e.printStackTrace();}} 

public class Kunde { 

} 

protected String Name; 

public Kunde(){;} 

public void Init(String n){ 

Name = n;} 

213


5.2.2 Realisierung der Datenhaltung 

• Dateien: nur geeignet bei Daten, die 

• einfach strukturiert sind 

• nicht von mehreren Systemen/Benutzern gleichzeitig verwendet 

• einfache (und unveränderliche) Zugriffsmechanismen haben und 

• kein (kompliziertes) Recovery nach Systemabsturz erfordern 

• relationales DBMS: heute üblich, → Datenbank-Vorlesungen 

• OO-DBMS: bei OO geeignet, aber gescheitert (?!) 

• objekt-relationales DBMS: Effizienz von RDBMS, Funktionalität 

vgl. OO-DBMS 

• deduktives DBMS: 

geeignet, wenn umfangreiche Datenhaltung und Inferenz benötigt 

(ggfs. Alternative zu: relationalem DBMS + Expertensystem) 

214


5.2.3 Verteilte Anwendungen 

• → Vorlesungen Verteilte Systeme, EAI 

• Verbindung der Prozesse z.B. durch 

• Sockets (TCP/IP, . . . ) 

• CORBA (bei Client-Server-Architektur) 

• RMI, EJB (in Java EE) 

• .NET, DCOM, . . . 

• Web-Services auf Basis von SOAP, WSDL, UDDI 

• RESTful Web-Services auf Basis von HTTP (oft mit JSON) 

• Message Oriented Middleware 

215


Demarshalling 

Stumpf s 

Entfernte Methodenaufrufe 

Anwendung Objekt o 

Ergebnis 

Aufruf Aufruf o.m(args) 

o.m(args) 

s.m(args) 

s.m(args) 

Marshalling 

Demarshalling 

Verteiler 

... 

Ergebnis 

Marshalling 

Ergebnis 

216


5.2.3.1 Enterprise JavaBeans 

• Java-basierte Middleware für verteilte OO-Anwendungen 

• Komponenten (Beans) in EJB-Container (auf Server) bereitgestellt 

• EJB Container: z.B. IBM WebSphere, BEA WebLogic, JBoss . . . 

• Dienste des Containers: (u.a.) 

• Verwaltung und Suche von Beans (basierend auf JNDI) 

• Transaktionen (basierend auf JTS und JTA) 

• Persistenz 

• Zugriff auf entfernte Objekte (basierend auf RMI/IIOP bzw. JMS) 

• Ressourcenverwaltung (Instance Pooling, Bean-Ein-/Auslagerung) 

• Autorisierung und Authentifizierung (basierend auf JAAS) 

• Vorteil: Basisdienste bei Anwendungsentwicklung “geschenkt” 

• Nachteil: Overhead; keine Threads, keine BS-Aufrufe (wegen 

Transaktionen) 

217


Wo werden EJBs eingesetzt? 

• typische 4-Schichten-Architektur: 

• Client Tier (HTML) 

• Web Tier (JSP,Servlets) 

• Business Tier (EJB) 

• EIS Tier (DB) 

218


Arten von Beans 

• Entity: kapselt persistente Daten; Zugriff (z.B.) über Session Bean 

• Session-Bean: realisiert (z.B.) Use-Case 

nicht persistent; Zugriff basierend auf RMI (z.B. aus Servlet) 

• zustandslos: effizient, gemeinsam nutzbar durch mehrere Clients 

• zustandsbehaftet: exklusiv für einen Client; 

Zustand wird über eine Sitzung hinweg bewahrt; bei Absturz 

verloren 

• Message-driven Bean 

219


Aufbau eines Enterprise Java Beans 

• Remote Interface (bzw. Local Interface bei ausschließlich lokalem 

Zugriff): “Business”-Methoden (nur bei Session-Beans) 

• Verwaltungsoperationen (ab EJB 3 transparent) 

(z.B. Erzeugen, Löschen, Aktivieren, Passivieren) 

• Bean-Klasse: 

Implementierung der Business-Methoden (ab EJB 3: “POJO”) 

• optionaler Deployment Descriptor: 

• XML-Dokument zur Konfiguration eines Beans u.a. bzgl. 

Persistenz, Transaktionen und Primärschlüssel 

• ab EJB 3 i.d.R. durch Annotationen in Bean-Klasse ersetzt 

• alle zusammengefasst in .jar Archiv-Datei (Packaging) 

220


Remote 

Client 

EJB 3.0-Programmiermodell 

EJB−Container JVM 

Business 

Interface 

Local 

Client 

Container−erzeugte 

Wrapper−Klasse 

EJB−Klasse 

Middleware−Dienste: 

− Lebenszyklus−Management 

− Persistenz 

−Zugriffsschutz 

−Transaktionen 

... 

221


Deployment 

• Bean wird gemäß Deployment-Angaben konfiguriert und 

im Container bereitgestellt 

• hierbei werden Hilfsklassen zur Einbindung der Bean-Klasse in 

den Container automatisch erstellt und compiliert (u.a. Stubs, 

Skelette) 

• wahlweise komfortable Container-verwaltete Persistenz oder 

flexiblere Bean-verwaltete Persistenz (mit expliziten 

JDBC-Aufrufen) 

• wahlweise Container- oder Bean-verwaltete Transaktionen 

222


datum 

name 

adresse 

Ausleihe 

* 

1 

Benutzer 

Beispielanwendung: Bibliothek 

0..1 

1 

Exemplar 

Medium 

inventarnr 

* 1 

bezeichnung 

autor 

Buch CD 

isbn asin 

interpret 

223


package bibliothek; 

Entity: Klasse Benutzer 

import java.util.ArrayList; import java.util.Collection; import javax.persistence.*; 

@Entity 

public class Benutzer implements java.io.Serializable { 

protected int bid; /** Primärschlüssel */ 

protected String name; 

protected String adresse; 

protected Collection ausleihen = new ArrayList(); 

@Id @GeneratedValue(strategy=GenerationType.AUTO) 

public int getBid(){return bid;} 

public void setBid(int id){bid = id;} 

public String getName(){return name;} 

public void setName(String name){this.name = name;} 

public String getAdresse(){return adresse;} 

public void setAdresse(String adresse){this.adresse = adresse;} 

@OneToMany(cascade = CascadeType.ALL, mappedBy="benutzer") 

public Collection getAusleihen(){return ausleihen;} 

public void setAusleihen(Collection coll){ausleihen = coll;} 

public void addAusleihe(Ausleihe vorgang){ausleihen.add(vorgang);} 

public void removeAusleihe(Ausleihe vorgang){ausleihen.remove(vorgang);} 

} 224


... 

@Remote 

public interface BenutzerFassade { 

} 

... 

Beispiel: Session-Bean 

public void benutzerAnlegen(String name, String adresse) throws Exception; 

@PermitAll 

@Stateless 

public class Benutzerverwaltung implements BenutzerFassade{ 

@PersistenceContext 

private EntityManager em; 

@TransactionAttribute(TransactionAttributeType.REQUIRED) 

public void benutzerAnlegen(String name, String adresse) throws Exception{ 

} 

Query q = em.createQuery("SELECT COUNT(*) FROM Benutzer b WHERE b.name = :n"); 

q.setParameter("n",name); 

if (((Long) q.getSingleResult()).intValue() == 0){ 

Benutzer benutzer = new Benutzer(); 

benutzer.setName(name); 

benutzer.setAdresse(adresse); 

em.persist(benutzer);} 

else throw new Exception("Name bereits verwendet"); 

} 225


5.2.3.2 Webapplikationen 

Web−Client Server 

Präsentation 

HTML 

+ JavaScript? 

+Java−Applets? 

Browser 

Cookies 

HTTP mit HTML+Cookies 

HTTP mit Formularinhalt 

und Cookie 

Webzugang 

JSP, Servlets, ASP, PHP 

Geschäftslogik 

EJB, PHP, ... 

ggf. JDBC 

Datenhaltung 

RDBMS 

226


5.2.3.2.1 HTML 

• “Markup”-Sprache zur Beschreibung von Struktur (→ Tags), Inhalt 

und ggf. Layout einer Webseite 

• bietet u.a.: Text, Listen, Tabellen, Verweise, Bilder, Frames, 

Formulare 

• für jede HTML-Version eigene vordefinierte 

Dokumenten-Typ-Definition (DTD) 


Die wichtigsten Tags 

Tag-Name Funktion 

. . . deklariert eine HTML-Seite 

. . . enthält den Kopf der HTML-Seite 

. . . definiert den Titel der Seite 

. . . enthält den Körper der HTML-Seite 

. . . definiert eine Überschrift der Ebene n 

. . . setzt . . . in Fett-Schrift 

. . . setzt . . . in Kursiv-Schrift 

. . . bzw. beschränkt eine ungeordnete Liste, 

. . . bzw. eine nummerierte Liste 

. . . Listenelement 

. . . Absatz 

fügt eine horizontale Linie ein 

. . . vorformatierter Text; wird nicht umformatiert 

lädt ein Bild 

. . . fügt einen Link mit der Beschreibung . . . ein 

Kommentar 

228


Neuerungen in HTML5 

• neue semantische Markup-Elemente wie , 

, , 

• Schlüssel-Wert-Paare (Microdata) für Suchmachinen 

• neue validierbare input-Typen wie tel, url, email, number für 

Formulare 

• Client-seitiger Speicherplatz (Web Storage, Indexed Database 

(inkl. Transaktionen), File API, Web SQL) ggf. auch über Dauer 

einer Sitzung hinaus 

• Möglichkeit von Offline-Applikationen 

• Gerätezugriff insbesondere für mobile Endgeräte 

(u.a. Geolocation API) 

229


Neuerungen in HTML5 (2) 

• Kommunikation über Websockets und Cross Document 

Messaging 

• Multimedia (Videos mit WebM, OGG, H.264; Audio) ohne Plug-ins 

• 2D- und 3D-Graphiken (u.a. SVG), MathML 

• Web Workers erlauben JavaScript-Berechnungen im Hintergrund 

(→ Threading) 

• XMLHttpRequest Level 2 (→ Ajax) 

• durch CSS3 verbessertes Geräte-abhängiges Layout 

230


• HTTP ist zustandslos 

Sitzungen 

• Rekonstruktion einer Sitzung aus Einzelzugriffen unmöglich 

• Trick: Sitzungsinformationen in versteckten Formularfeldern (s.u.), 

verlängerten URLs oder Cookies 

231


5.2.3.2.2 Cascading Style Sheets (CSS) 

• Layout-Eigenschaften werden durch Tags festgelegt, z.B. 

Einleitung 

• um diese nicht bei jedem Textelement wiederholen zu müssen, 

können Style-Sheets festgelegt werden, z.B. 

H2 text-align: center; color: red 

• festlegbare Eigenschaften: Farbe, Font-Familie, Font-Stil (z.B. italic), 

Font-Größe, Zeichenabstand, Wortabstand, Text-Dekoration (z.B. 

underline, blink), horizontale und vertikale Ausrichtung und Einrückung, 

Hintergrund-Farbe bzw. -Bild usw. 

• Einbindung z.B. durch -Tag im Head-Teil eines Dokuments 

232


5.2.3.2.3 Formulare 

• erlauben die interaktive Zusammenstellung von Informationen 

zur Übermittlung an eine Anwendung auf einem Server 

• Teil einer Web-Seite 

233


Tags in Formularen 

1) Beginn und Ende eines Formulars, z.B. 

... 

• ACTION-Attribut definiert URL des Verarbeitungsprogramms 

• METHOD-Attribut bestimmt Methode der Übertragung an den 

Server: 

GET: Eingaben werden als Teil der URL übertragen 

Zugriff aus CGI-Skript über Umgebungsvariablen 

QUERY_STRING und/oder PATH_INFO 

POST: Eingaben in “Payload” übertragen und über 

Standardeingabe an CGI-Skript geleitet 

234


2) Text- und Passwort-Eingabe 

Tags in Formularen (2) 

 

 

3) Knöpfe 

 

 

 

4) Radio-Knöpfe und Ankreuzfelder 

 

 

235


5) Menüs und Scroll-Listen 

Tags in Formularen (3) 

 

Telgte 

Greven 

 

• bei SIZE > 1: Scroll-Liste (ggfs. MULTIPLE) 

6) Textfelder 

 

 

7) Datei (mit Browser) auswählen und an Server schicken 

 

Beispiele siehe Webseite 

236


5.2.3.2.4 Java-Applets 

• Applet-Tag wird eingebunden in Web-Seite 

• das zugehörige Applet (d.h. eingeschränkte Java-Programmstück) 

wird vom Server geladen und beim Client ausgeführt 

• ohne Einschränkungen könnten Applets beim Client Schäden 

anrichten 

• daher: Java-Byte-Code wird von der abstrakten Maschine JVM 

interpretiert 

• unsichere Operationen werden hierbei abgefangen (z.B. keine 

Festplattenzugriffe, Kommunikation nur mit dem Server) 

• Applets erweitern Web-Seiten um die Ausdruckskraft einer 

Programmiersprache (insbesondere auch: Grafik, Audio) 

237


5.2.3.2.5 JavaScript 

• von Netscape entwickelte Skriptsprache 

• typischer Einsatz in Web-Seiten 

• Java-ähnliche Syntax 

• JavaScript-Programmstücke werden vom Browser beim Client 

ausgeführt 

• erlaubt Interaktion zwischen Web-Seite und Benutzer ohne 

Rückgriff auf den Server 

• Kernelement von AJAX 

238


• Formulare validieren 

• html-Seiten generieren 

Was können JavaScripte? 

• die Browserumgebung ändern (Farbe,. . . ) 

• html-Dokumente laden 

• Web-Seiten Benutzer- bzw. Umgebungs-abhängig aufbereiten 

• Bedienkomfort wie bei einer Desktop-Applikation bieten 

(z.B. Drag & Drop, Tool-Tips) 

• Beispiele siehe Web-Seite 

239


Was ist bei JavaScript eingeschränkt? 

• Zugriff auf lokale Dateien 

• Netzwerk-Operationen 

• Multithreading (nur simulierbar) 

240


5.2.3.2.6 Cookies 

• sind kurze Informationen, die der Client einer Seite zuordnet und 

lokal speichert (mit Verfallsdatum) 

• verleihen dem Browser ein Gedächtnis 

• z.B.: beim erneuten Besuch einer Web-Seite brauchen 

Informationen nicht neu eingegeben zu werden 

• werden in HTTP-Nachricht an den Server mitübertragen 

• werden bei der Übertragung i.allg. nicht geschützt 

241


Bestandteile eines Cookies 

• Domäne: erzeugender Webserver (≤ 20 Cookies pro Client und Domäne) 

• Pfad im Dateibaum des Servers mit Programmen, die Cookie verwenden dürfen 

• sicher?: wenn ja: Cookie wird nur an sicheren Server weitergegeben 

• bei Ablauf der “gültig-bis”-Zeit wird Cookie gelöscht 

• entsprechendes Überschreiben erzwingt Löschen 

• Anwendung: z.B. Warenkorb, benutzerbezogene Informationsaufbereitung, 

CRM (Benutzerprofile), Log-in-Informationen 

242


5.2.3.2.7 Java-Servlets 

• werden von Java-Laufzeitgebung interpretiert, die in den 

Webserver (z.B. Apache) integriert wird 

• erlauben die dynamische Generierung von Web-Seiten 

• zur Bearbeitung einer Anfrage: 

neuer Thread in JVM (statt neuer Prozess) 

Client 

Internet 

Webserver 

HTML 

API 

response request 

JVM 

Servlet 

DB 

243


Java-Servlets (Fortsetzung) 

• Servlets werden z.B. in speziellem Verzeichnis gesammelt 

• Server wird so konfiguriert, dass bei Zugriff hierauf 

das jeweilige Servlet ausgeführt wird 

• Anfrage an ein Servlet über HTTP, z.B.: 

http://servername/servlets/Welcome?name=Ute+Mai 

• Parameterübergabe und Ergebnis nicht über 

Umgebungsvariablen bzw. Standardein-/ausgabe sondern 

komfortabler über vorgegebene Anfrage- und Antwort-Objekte 

(Argumente von doGet) 

244


import java.io.*; 

import javax.servlet.*; 

import javax.servlet.http.*; 

Beispiel: Java-Servlet 

public class Welcome extends HttpServlet{ 

public void doGet(HttpServletRequest req, 

HttpServletResponse res) 

throws ServletException, IOException{ 

String name = req.getParameter("name"); 

if ((name==null) || (name.length()==0)) 

name = "Unbekannter"; 

res.setContentType("text/html"); 

PrintWriter out =res.getWriter(); 

} 

out.println("\n 

\n 

Hallo 

\n 

"); 


Hallo "+name+". 

"); 


out.close();} 

"); 

245


Vorteile von Servlets 

• Servlets ggf. über mehrere Anfragen hinweg im Hauptspeicher 

• Code ggf. gemeinsam genutzt 

• Servlet und Applet können kontinuierlich über beliebiges Protokoll 

(auch verschlüsselt) kommunizieren 

• Kommunikation von Servlets untereinander über gemeinsame 

Variablen/Objekte synchronisiert durch Java-“Monitore” 

• Servlets bieten komfortable Methoden zur Aufrechterhaltung einer 

Sitzung (session tracking; intern basierend auf Low-Level-Techniken wie 

Cookies) 

• (lange) Datenbanktransaktionen können hiermit leicht realisiert werden 

• Datenbankverbindungen (ggf. auch Connection-Pools) bleiben geöffnet 

246


5.2.3.2.8 JavaServer Pages (JSP) 

• Nachteil von Servlets: wenn Webseiten aus viel vorgefertigtem 

Text mit wenig Logik generiert werden, besteht das Servlet fast 

nur aus Ausgabe-Anweisungen 

• dann übersichtlicher: Logik (Java) in HTML-Seite integrieren 

• hierzu: JSP 

• JSP-Code wird intern in Servlets transformiert 

• eigene Tag-Libraries erlauben Trennung von Webdesign und Logik 

247


 

Hallo 

 

JSP-Beispiel 

JSP-Beispiel 1: Hallo 

 

out.println("Hallo!"); 

else out.println("Hallo "+request.getParameter("name")+"!"); 

Herzlich willkommen! 

 

248


 

Quadrat 

 

 

JSP-Beispiel 

 

JSP-Beispiel 2: Quadrat 

 

 

Das Quadrat der von Ihnen eingegebenen Zahl ist 

. 

 

 

249


Vordefinierte Variablen 

• verwendbar im Java-Code innerhalb einer JSP-Seite 

• HttpServletRequest request 

• HttpServletResponse response 

• javax.servlet.jsp.JspWriter out 

• HttpSession session 

• ServletContext application 

• javax.servlet.jsp.PageContext pageContext 

250


JSP-Features 

Java-Code c wird ausgeführt 

Java-Ausdruck e wird ausgewertet 

und das Ergebnis als String eingefügt 

Java-Deklaration d wird vor der 

Hauptservlet-Methode (doGet) in das generierte Servlet eingefügt 

Direktive d wird zur Transformationszeit ausgeführt 

z.B. Cookies abschalten, Fehlerbehandlungsseite festlegen, 

Datei einfügen 

JavaBean (�= EJB) einfügen 

 

Datei zur Zugriffszeit einfügen 

 

Zugriff umlenken 

 

251


Frameworks für Benutzerschnittstellen von 

Webapplikationen 

• Struts 2 basiert auf Entwurfsmuster Model-View-Controller (MVC) 

• JavaServer Faces ebenfalls basierend auf MVC 

• (z.B.) EJBs für Model, JSP für View 

• insbesondere geeignet für komplexe Systeme von dynamischen 

Webseiten 

252


5.2.3.3 Web-Services 

• Kommunikation zwischen Client und Server über 

XML-Format SOAP 

• Beschreibung von Webservices in WSDL 

(Web Services Description Language) 

• Suche passender Dienste mit UDDI (Universal 

Description, Discovery, and Integration) 

• Potential: führende Integrationsinfrastruktur 

(“kleinster gemeinsamer Nenner”) 

• Nachteil: (z.Z.) unzureichende Sicherheit und 

Transaktionsunterstützung 

Client SOAP Server 

Web Service Protokollstapel 

Entdeckung UDDI 

Beschreibung 

Verpackung 

Übertragung 

WSDL 

SOAP 

HTTP, SMTP, FTP 

253


5.2.3.3.1 SOAP 

• XML-Format zur Kodierung von entfernten Aufrufen (RPC) von 

Web-Services und deren Antworten 

• Vorteil(?): über HTTP (Port 80) wird Firewall meist durchdrungen 

SOAP−Envelope 

SOAP−Header 

Header−Block 

Header−Block 

SOAP−Body 

Nachrichten−Body 

254


Beispiel: SOAP-Anfrage 

 

 

 

 

48149 

 

 

 

(angelehnt an: E. Cerami: Web Services, O’Reilly, 2002) 

255


Beispiel: SOAP-Antwort 

 

 

 

 

23 

 

 

 

256


SOAP 

• Typen: neben üblichen Basistypen (int,float) auch Arrays, 

Strukturen und XML 

• bei Fehler: spezielle fault-Antwort ( ˆ= Exception) 

• durch Header: u.a. optionale Zugangskontrolle, 

Transaktionsverwaltung 

• unübersichtliche XML-Struktur wird in Client- und Server-Code 

durch Java-Klassen versteckt 

• Implementierungen: z.B. Apache SOAP (→ Tomcat), MS SOAP 

Toolkit 

257


Beispiel: Wetter-Web-Service in Java 

public class WeatherService{ 

} 

public int getWeather(String zipcode) { 

return 23;} 

• wird deployed (z.B. in Webcontainer Tomcat) 

258


5.2.3.3.2 WSDL 

• Format zur Beschreibung von Web-Services 

 

 

 

 

 

Datentypen 

Nachrichten 

Operationen 

Übertragungsprotokolle 

Zugriffsadresse 

259


Beispiel: WSDL-Beschreibung des Wetter-Web-Service 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

260


WSDL-Beispiel (Fortsetzung) 

 

 

 

 

 

 

 

 

 

 

261


 

WSDL-Beispiel (Fortsetzung) 

WSDL File for Weather Service 

 

 

262


5.2.3.4 RESTful Webservices 

• basieren direkt auf HTTP statt auf SOAP 

• Adressierung von Ressourcen über Uniform Resource Locator 

(URI) 

• idempotente HTTP-Methoden POST, GET, PUT und DELETE zur 

Realisierung von Erzeugen, Lesen, Ändern und Löschen einer 

Ressource 

• Repräsentation von Inhalten meist im kompakteren JSON-Format 

statt mit SOAP 

• REST = representational state transfer 

• Trend: gewinnen wegen höherer Effizienz an Beliebtheit 

gegenüber SOAP-basierten Webservices 

263


Modul 

5.3 Bausteine einer Software-Architektur 

• kapselt Operationen (Funktionen) und ggfs. Daten 

• Trennung von Schnittstelle und Rumpf (Implementierung) 

(getrennt compilierbar, Geheimnisprinzip) 

• Zugriff auf Datenstruktur ausschließlich über vorgegebene Operationen 

• dadurch: Änderungen von Datenstrukturen und Operationen lokal 

begrenzt 

• Schnittstelle wird in Entwurfsphase spezifiziert: 

• Aufgabe 

• Ein-/Ausgabe-Parameter, Vor- und Nachbedingungen der 

Operationen 

• ggfs. Leistungsmerkmale (Platzbedarf, . . . ) 

264


Funktionsmodul 

Modularten 

• enthält ≥ 1 Funktion, die Eingaben in Ausgaben transformiert 

(kein Gedächtnis!) 

• funktionale Abstraktion in Programmiersprache 

realisiert durch Funktion oder Prozedur 

Datenobjektmodul 

• Kapselung von Zugriffsoperationen und Daten (→ Gedächtnis) 

• realisiert ein abstraktes Datenobjekt 

• Abhängigkeiten zwischen Zugriffsoperationen 

durch Algebraische Spezifikation oder Automaten beschreiben 

265


Datentypmodul 

Modularten (2) 

• realisiert einen abstrakten Datentyp 

(ggfs. mit Parametern, ≥ 1 Objekt) 

• Instanzen sind Datenobjekte 

Klasse 

• wie Datentypmodul, jedoch zusätzlich Vererbung 

• nur bei OO (und dort auschließlich) 

266


generic 

Beispiel: Polymorphes Datentypmodul in Ada 

Max: natural := 100, 

type ElementT is private; 

package WarteschlangeT is 

procedure insert(Element: in ElementT; 

Status: out StatusT); 

procedure delete(Element: out ElementT; 

end Warteschlange; 

Status: out StatusT); 

package body Warteschlange is 

... Deklaration von Variablen und Typen 

z.B. head, tail 

... Implementierung von insert , delete 

begin 

head := 0; 

tail := 0; 

end Warteschlange 

Verwendung: 

package QueueF is 

new WarteschlangeT(10,float); 

package QueueI is 

... 

new WarteschlangeT(5,int); 

QueueF.insert(3.5,Status); 

QueueI.insert(2,Status); 

267


• Funktionsmodule: 

Eignung der Modultypen 

• Steuerung und Koordination 

• Transformation 

• komplizierte Auswertung 

• als Hilfsdienst in Datenstrukturen als 

funktionale Zwischenschicht zwischen Datenabstraktionen 

• Datenobjektmodule: 

• komplexes Einzelobjekt (z.B. Hypertext) 

• Sammlung von Objekten (z.B. Stack) 

• Datentypmodule: 

• bei mehreren gleichartigen komplexen Einzelobjekten oder 

Kollektionen 

268


Einbindungsalternativen von Modulen 

a) Import: Entwerfer erlaubt Import eines Moduls explizit 

b) Schachtelung: (vgl. innere Klassen in Java) 

• blockstrukturierte Programmiersprachen haben 

baumstrukturierte Gültigkeitsbereiche 

module A 

module B 

module C 

module D 

... B ... A ... C ... 

module E 

... E ... A ... 

• Modul hat Zugriff auf Kinder, Geschwister, Vorfahren und deren 

Geschwister 

• ein Modul mit darunterhängendem Enthaltenseinsbaum heißt 

Teilsystem 

269


Vor- und Nachteile der Schachtelung 

• Vorteil: Hilfsmodule außerhalb des Teilsystems unsichtbar 

(Geheimnisprinzip) 

• Nachteil: Blockstruktur erzwingt z.T. schlechte Modulanordnung, Bsp.: 

• Hilfsmodul H wird von M und M ′ benutzt 

• H daher unter einem gemeinsamen Vorfahren V von M und M ′ 

anordnen 

• H für sein Abstraktionsniveau zu hoch 

• Verletzung des Geheimnisprinzips 

lokale Benutzbarkeit 

V V 

H 

M M’ M M’ 

allgemeine 

Benutzbarkeit 

H 

270


Moduleinbindung bei Schichtenarchitektur 

Schicht 2 

Schicht 1 

Schicht 0 

• innerhalb einer Schicht: Schachtelung, z.T. auch import 

• zwischen Schichten: import 

271


5.4 Entwurfsmethodiken 

• herkömmliche Methodiken: (Details s. Balzert) 

• Strukturierter Entwurf (SD): → Hierarchie von Funktionsmodulen 

• Modularer Entwurf (MD): → Funktions-, Datenobjekt- und 

Datentyp-Module 

• Objektorientierter Entwurf (OOD): 

• → System von Klassen und Paketen 

• Ausganspunkt: OOA-Modell (ohne Optimierungen, Assoziationen 

bidirektional, . . . ) 

• Schritte bei OOD: 

1) Architekturentwurf 

2) Implementierungsentwurf 

272


Architekturentwurf 

• Anbindung an Benutzerschnittstelle, Datenhaltung und 

Systemschnittstellen 

• Verteilung im Netz 

• Anpassung, Erweiterung und Verfeinerung des OOA-Modells 

zu OOD-Modell (auch in UML) 

• OO unterstützt Wiederverwendung; daher beim Entwurf 

überprüfen, ob Klassenbibliotheken oder Halbfabrikate 

wiederverwendbar 

273


• Anpassung an Zielsprache 

Implementierungsentwurf 

• dazu u.a. ggfs. Transformation von Mehrfachvererbung in 

Einfachvererbung bzw. Elimination von Vererbung 

274


Klassenbibliotheken 

• oft kommerziell angeboten oder in Programmierumgebung 

• z.B. für GUI, Graphik, grundlegende Datenstrukturen, 

Datenbankzugriff, IPC 

• übliche Topologien: 

• Baum: nutzt Vererbung, aber komplizierte Handhabung, z.B. in GUI 

• flach: einfache Handhabung, z.B. bei grundlegenden 

Datenstrukturen 

• Wald: Kompromiss 

• Framework: anpassbares System kooperierender Klassen 

275


Halbfabrikate 

• z.B. für Hilfe, Rechtschreibeprüfung, Silbentrennung, Diagramme 

• erstrebenswert: unabhängig von Sprache und Plattform, verteilbar 

• Ansätze für Interoperabilität: 

• CORBA 

• .NET (Microsoft; COM, DCOM) 

• Webservices (→ Service-oriented Architecture (SOA)) 

276


Entwurfsmuster 

• wiederkehrendes Entwurfsproblem für das bewährte Lösung 

existiert 

• siehe: E. Gamma et al.: Entwurfsmuster, Addison Wesley, 2009. 

277


Erweiterung des OOA-Modells um 

5.4.1 Architekturentwurf 

• weitere Klassen (z.B. “technisch” bedingte) 

• Richtungsangaben für Assoziation und Aggregationen 

• Kommentare 

• um Sichtbarkeitsangaben für Attribute und Operationen 

(public,protected,private) 

• Klassenattribute und Klassenoperationen 

278


5.4.1.1 Anbindung an eine relationale Datenbank 

OO-Zwischenschicht transformiert: 

1) Klassen in Relationen 

2) Beziehungen in Fremdschlüssel (und z.T. Klassen) 

3) Vererbung in System von Relationen (Details s. Balzert) 

4) komplexe Typen in Basistypen 

5) OO-Zugriffsmethoden in SQL 

• hierfür Middleware, z.B. JDO, EJB (Entity-Beans), Hibernate, 

JDBC 

279


create table Person 

Transformation von Klassen in Relationen 

Person OID 

Nr. 

Name 

( OID number(8) not null, 

Nr number(8) not null, 

Vorname char(20), 

Nachname char(20) not null, 

primary key (Nr) ); 

create secondary index PersonIndex 

on Person(Nachname); 

Nr 

Person 

Vorname Nachname 

• Abb. von Attributtyp auf 

SQL-Typ 

• OID-Spalte hinzufügen 

• optionale Attribute festlegen 

• ggfs. Index anlegen 

280


Beziehungen in Fremdschlüssel umwandeln 

(vgl. Vorlesung Datenmanagement) 

• bei 1 : m-Assoziation/Aggregation: 

A1 

A2 

K1 

K2 

K1 K2 

OID1 A1 A2 OID2 A3 A4 OID1 

1 * A3 

A4 

• bei n : m-Assoziation/Aggregation (n, m > 1): 

A1 

A2 

K1 

K2 

K1 K2 

OID1 A1 A2 OID2 A3 A4 

* * A3 

A4 

K1-2 

OID1 OID2 

281


5.4.1.2 Verteilung der Anwendung 

• OOD-Modell aufteilen in Client-OOD-Modell und 

Server-OOD-Modell 

• Verknüpfung von Client und Server z.B. über CORBA oder EJB 

• Behandlung von Klassenattributen, selbstdefinierte Typen, 

Aufzählungstypen in eigene Klasse “herausziehen” 

• falls Objektverwaltung erforderlich (von CORBA nicht unterstützt!), 

wird hierfür Hilfsklasse wie zur Behandlung von Klassenattributen 

angelegt 

282


5.4.2 Implementierungsentwurf 

• Anpassung an Zielprogrammiersprache 

• z.B. durch Elimination mehrfacher Vererbung 

1. Aggregation von Rollen 

2. Abflachen zu einfacher Hierarchie 

• oder durch vollständige Elimination von Vererbung 

283


Fahrzeug 

Ort 

km/h 

bewegen 

Flugzeug 

max. Flughöhe 

bewegen 

bewegen 

Wasserflugzeug 

Aggregation von Rollen 

Schiff 

Tiefgang 

bewegen 

Ort 

km/h 

bewegen 

Flugzeug 


bewegen 

Fahrzeug 

1 

1..2 

Rolle 

Schiff 

Tiefgang 

bewegen 

284


Flugzeug 


bewegen 

Abflachen zu einfacher Hierarchie 

Fahrzeug 

Ort 

km/h 

bewegen 

Wasserflugzeug 


Tiefgang 

bewegen 

Schiff 

Tiefgang 

bewegen 

285


Vollständige Elimination von Vererbung 

• bei Sprachen ohne Vererbung (z.B. Ada) 

• Übernahme aller Attribute und Operationen der Oberklassen 

in jede (konkrete) Klasse 

Flugzeug Wasserflugzeug Schiff 

Ort Ort Ort 

km/h 

km/h km/h 

max. Flughöhe max. Flughöhe Tiefgang 

bewegen 

Tiefgang 

bewegen 

bewegen 

286


Weitere Anpassung an Zielsprache 

• Namenskonventionen beachten 

• alle Basistypen müssen unterstützt werden 

• Verwaltungsoperationen (Konstruktoren, Destruktoren, 

Initialisierung, Verwaltung von Assoziationen und Aggregationen, 

Lesen und Schreiben von Attributen) ggfs. ergänzen 

• ggfs. Containerklassen für Objektverwaltung hinzufügen 

• Sichtbarkeit festlegen (+,-,#) 

• Objekt-Lebenszyklen (z.B. Harel-Automaten) in Algorithmen 

transformieren 

287

Kapitel 5: Entwurf

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?