SE2-w11-Zusammenfassung
Werbung
Slideshow SE 2
In 80 Folien durchs Semester
Engineering?
Softwarekonstruktion ist Ingenieurleistung:
Kenntnis der technologischen Alternativen
Einsatz von Norm- und Fertigteilen
Einsatz von Standardstrukturen
Einsatz von Standardtechniken / Best Practices
Hauptaufgabe: Strukturierung und Kombination
(nicht Programmierung)
Themen der LV
© schmiedecke 10
Java-Web-Technologie
JSF-Framework als Standard-Präsentationsstruktur (MVC-2)
JPA als Persistenzframework
Scaffolding zur Erstellung einer Standard-Architektur (CRUD)
Konstruktionstechniken am Klassenmodell:
Modelldetaillierung, Konstruktionsprinzipien
und Entwurfsmuster
Produktsteuerung
SE 2
2
Praxis: aus einem Klassenmodell mit 10 Klassen
© schmiedecke 10
SE 2
3
… wird ein System mit
50 Klassen und 28 XML- Dateien!
© schmiedecke 10
SE 2
4
Ist das wirklich nötig?
Es gibt gute Gründe dafür, dass das die richtige Technik ist!
Einige der Zauberworte heißen
–
–
–
–
–
–
Referenzarchitektur
Skalierbarkeit
Änderbarkeit
Sicherheit
Stabilität
Fehlervermeidung bei "Boiler Plate Code"
© schmiedecke 10
SE 2
5
Web-Anwendung: Dynamischer Content
dynamischer Content
CGI
PHP
JSP/
Servlet
ASP
URL
WebClient
Web -
Server
Programm
DB
HTML
+JavaScript
+Applets
Front End
Web Publishing
(c) schmiedecke 11
SE2-2-Java-Webapps
Back End
6
Programmiermodelle
Programmorientiert (Perl -- Servlets)
– serverseitige Applikation besteht aus Programmen
– erzeugen HTML-Dokument als Ausgabestrom
+ Fachlogik gut strukturierbar, Kontrolle übersichtlich
- Dokumentenstruktur verborgen
- Layout-Veränderungen erfordern Programmänderungen
-
Dokumentenorientiert (ColdFusion – JSP, Facelets)
- serverseitige Applikation ist HTML-Dokument mit eingebetteten
Scripten
+ Dokumentenstruktur gut erkennbar (gestaltbar)
+ einfaches Handling
- (c)
Fachlogische
schmiedecke 11 Struktur verwischt
SE2-2-Java-Webapps
7
Simple JSP
<html>
<head><title>Simple JSP</title></head>
<body>
Your browser is: <%= request.getHeader("User-Agent") %><br>
Your IP address is: <%= request.getRemoteAddr() %><br>
</body>
</html>
(c) schmiedecke 11
SE2-2-Java-Webapps
8
SimpleServlet
public class SimpleServlet extends HttpServlet {
public void doGet(HttpServletRequest request, HttpServletResponse response)
throws IOException, ServletException{
// 1. process request-parameters and -headers...
String client = request.getHeader("User-Agent");
String ipAddress = request.getRemoteAddress();
// 2. prepare the response...
response.setContentType("text/html");
// 4. write to Response PrintWriter
PrintWriter out = response.getWriter();
out.println("<html>");
out.println("<head>");
out.println("<title> SimpleServlet</title>");
out.println("</head>");
out.println("<body>");
out.println("Your browser is: "+ client +
"<br> Your IP address is: "+ ipAddress + "<br>);
out.println("</body></html>");
(c) schmiedecke 11
SE2-2-Java-Webapps
9
}
Der JSP-Lebenszyklus (im Web-Container)
1.
Transformieren:
–
–
–
2.
Kompilieren
–
3.
Das Servlet wird "normal" kompiliert. (Benötigt Servlet-API)
Instanziieren
–
4.
Die gesamte JSP-Seite wird in eine Java-Klasse umgeformt
Klasse vom Typ Servlet
Leistet das, was wir intuitiv von der JSP erwarten
und erzeugt ("druckt") HTML-Code
Das Servlet wird geladen und instanziiert.
Der Web-Container verwaltet die Instanz.
Aufruf
–
Bei jeder Client-Anfrage wird eine bestimmte Service-Methode der ServletInstanz gerufen (meistens "doGet" oder "doPost")
Schritte 1-3 geschehen implizit beim "Deployen"
(c) schmiedecke 11
SE2-2-Java-Webapps
10
Deployment
Genormte Verzeichnisstruktur für Java-Web-Anwendungen
Gesamtes Verzeichnis packen:
WAR-Datei ("Web Archive") == JAR mit fester Struktur
In ein bestimmtes Unterverzeichnis des Web-Containers "schieben"
– bei Tomcat ist das "webapps“
– bei Glassfish "autodeploy"
Ggf. den Web-Container starten (Tomcat, Glassfish, JBoss…)
Der Web-Container realisiert den Lebenszyklus der
Jsp-s, Servlets, Beans
myJsp
myJsp.war
(c) schmiedecke 11
SE2-2-Java-Webapps
11
web.xml – der Deployment Descriptor
<?xml version="1.0" encoding="UTF-8"?>
<web-app>
<servlet>
<servlet-name>start</servlet-name>
<servlet-class>myapps.StartServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>start</servlet-name>
<url-pattern>/index.html</url-pattern>
</servlet-mapping>
</web-app>
(c) schmiedecke 11
SE2-2-Java-Webapps
12
Java-Web-Technologie: JEE
Ohne EJBContainer:
JSE
(c) schmiedecke 11
SE2-2-Java-Webapps
13
Servlets müssen reentrant sein!
Servlets werden beim Deployment instanziiert und dann von
verschiedenen Clients genutzt:
Servlet 1
Client 1
Servlet 2
Client 2
Servlet 3
Web-Container
(c) schmiedecke 11
SE2-2-Java-Webapps
14
Was sind Beans?
public class Bohne {
private String prop;
public void setProp(..);
public String getProp();
}
Beans sind "Pojos"
–
–
–
–
"plain old java objects"
Attribute heißen "Properties"
und haben Getter- und Setter-Methoden
(ggf. gibt es ein genormtes Event-Modell)
Durch diese "genormte" Form
– können Attribut-Zugriffe automatisch generiert werden
– können Bean-Objekte durch Werkzeuge "konfiguriert" werden
– und das war's schon!
Für die Datenspeicherung von JSPs gut geeignet...
(c) schmiedecke 11
SE2-2-Java-Webapps
15
Beans verschiedener Sessions
Die Beans einer
Session bilden
einen Kontext.
Servlet 1
Der Zugriff erfolgt
über diesen
Kontext.
(Das Servlet
bedient jeden
Kunden aus seinem
Konto)
(c) schmiedecke 11
Web-Container
SE2-2-Java-Webapps
16
Beans mit verschiedenen Lebensdauern
Jsp1
Jsp2
Jsp3
request
session
(c) schmiedecke 11
application
SE2-2-Java-Webapps
17
Beans zur Seitendynamisierung
(Zwischen-)Speichern von Eingaben:
– Eingaben werden als Request-Parameter an die JSP übergeben
– mit <jsp:setProperty> werden sie in einer Bean-Property gespeichert.
– Soll die Eingabe persistent gespeichert werden, so kann in der SetterMethode ein DB-oder Dateizugriff programmiert werden.
Anzeigen dynamischer Werte:
– Die Getter-Methode der Bean greift auf Anwendungsdaten (z.B. eine
Datenbank) zu oder errechnet einen Wert dynamisch
– Der Wert wird mit <jsp:getProperty> in die JSP eingebunden und so beim
Erzeugen der HTML-Seite dynamisch generiert.
(c) schmiedecke 11
SE2-2-Java-Webapps
18
Sessions?
HTTP ist zustandslos
Der Web-Container verwaltet Sessions über ein Session-ID
(generierte Nummer)
Wird beim ersten Response wenn möglich als Cookie gesendet,
sonst an die URL gehängt
Wird bei weiteren Anfragen als Request-Parameter "jsessionid"
mitgegeben
bei GET sichtbar
(c) schmiedecke 11
SE2-2-Java-Webapps
19
Modell-1-Architektur
...damit kann
man ALLES
machen!
Jsp1
JavaAnwendung
Jsp2
Jsp3
DB
request
session
(c) schmiedecke
11
application
SE2-2-Java-Webapps
20
Modell 1
JSP
Bean
JSP
JSP
Client
Bean
Fachlogik
JSP
Bean
JSP
Jede JSP reagiert selbständig auf Benutzeranfragen
erstellt und benutzt Beans, die die Fachlogik aufrufen
verzweigt ggf. für die Response zu einer anderen JSP
(c) schmiedecke 11
SE2-3-JSF
21
MVC - klassisch
Model (auch Domain Model oder Fachlogisches Modell) enthält und
verwaltet die persistenten Daten und die Fachoperationen darauf
View liest die erforderlichen Daten aus dem Model, bereitet sie auf
und präsentiert sie.
View registriert sich beim Model, um Veränderungen zu erfahren
Controller nimmt die Nutzeranfragen entgegen und leitet sie an die
(c) schmiedecke
11
SE2-3-JSF
zuständigen
Stellen weiter.
22
MVC 2 – oder Modell 2
Front Controller
Front
Controller
Servlet
Bean
Client
Bean
JSP
Bean
JSP
– empfängt alle
Requests
– instanziiert und
füllt Beans
– ruft die Aktionen
– leitet an die
passende
Antwort-JSP
weiter.
JSP
JSP
– liest Beans
– erzeugt und
sendet Response
(c) schmiedecke 11
SE2-3-JSF
23
Skalierbarkeit von Modell 2
Modell 2 macht Web-Anwendungen beliebiger Größe prinzipiell
beherrschbar:
–
–
–
–
–
klare Trennung zwischen Darstellung und Kontrolle
alle Komponenten separat entwickelbar
beliebig komplexes Domänen-Modell anschließbar
zentralisierte Ablaufsteuerung
Aufgabenteilung zwischen Designern und Programmierern
(c) schmiedecke 11
SE2-3-JSF
24
Realisierung durch
Web Application Frameworks
Definieren Objekttypen und ihre Zusammenarbeit:
praktisch immer MVC2
Bieten (erweiter- oder konfigurierbare) Standardobjekte
Ersetzen harte Verdrahtung der Seitennavigation durch
Konfiguration
Unterstützen die Zuordnung von Beans oder entsprechenden
Objekten
Unterstützen den Aufbau von GUIs
deutlich verbesserte Wiederverwendbarkeit der Komponenten.
(c) schmiedecke 11
SE2-3-JSF
25
Modell 2 mit dem JSF-Framework
Fertigteil von JSF
– empfängt alle
Requests
– füllt Beans
– leitet an das passende
Antwort-Facelet weiter.
Faces
Servlet
Managed
Bean
Client
Managed
Bean
Facelet
Managed
Bean
Facelet
(XHTML-Datei)
– liest Bean-Daten
– erzeugt und sendet
Response
xml-konfiguriert statt "hart verdrahtet"
(c) schmiedecke 11
FacesContext
– instanziiert die
ManagedBeans
Facelet
Facelet
FacesServlet
SE2-3-JSF
26
JSF - Features
Klare Model2-Architektur
Front Controller heißt FacesServlet
JSF-UI-Komponenten als Bausteine für Seiten
verschiedene Renderer möglich (z.B. für Handys)
ein- und ausblendbar
View-Definition-Languages: Facelets und JSP
Ereignisbehandlung
Datentransfer
Konfigurierbare Managed Beans
Einfaches Data Binding an Managed Beans über EL (Expression Language)
Konvertierung und Validation
Konfigurierbare Seitennavigation
Unterstützung von Meldungen
Internationalisierungs- und Zugänglichkeits-Unterstützung
(c) schmiedecke 11
SE2-3-JSF
27
Faces Servlet-Spezifikation in web.xml
Faces-Servlet wird als zentraler Einstiegspunkt festgelegt
<!-- Faces Servlet -->
<servlet>
<servlet-name>Faces Servlet</servlet-name>
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
<load-on-startup> 1 </load-on-startup>
</servlet>
<!-- Faces Servlet Mapping -->
<servlet-mapping>
<servlet-name>Faces Servlet</servlet-name>
<url-pattern>MyApp/*</url-pattern>
</servlet-mapping>
(c) schmiedecke 11
SE2-3-JSF
28
JSF-Entwicklungsprozess beginnt beim UI
1. Entwirf die UIs und binde die Datenfelder an das Datenmodell
2. Entwickle ein (Interaktions-)Datenmodell aus Beans
3. Entwirf die Seitennavigation abhängig von Ergebnissen
4. Führe die "Verdrahtung" im web.xml und faces-config.xml bzw.
durch Methodenergebnisse durch
(c) schmiedecke 11
SE2-3-JSF
29
JSF-UI-Komponenten
Ähnlich Swing-Komponenten, grafisch zusammenstellbar
Instanziierung und Platzierung durch JSF-tags:
<h: form id="customer_form">
<h: panelGrid id="grid" columns="2" >
<h: outputLabel value="First Name:" for "firstnameField"/>
<h: inputText id="firstnameField" value="#{customer.firstName}"/>
…
<h: commandButton id="saveBtn" action="#{customer.save}"
value="Save"/>
</h:panelGrid>
</h:form>
VDL – View Definition Language
– Facelets sind XHTML-Seiten (erscheinen im Browser mit der Endung .jsf)
– JSP wird auch unterstützt.
(c) schmiedecke 11
SE2-3-JSF
30
Managed Beans
JSF instanziiert und verwaltet alle deklarierten Beans
Managed Beans sind über Managed Properties verknüpfbar
Deklaration in der faces-config.xml oder durch Annotationen
Dependency Injection
@ManagedBean (name="address")
@SessionScoped
class AddressBean {
String surname;
String Address;
}
@ManagedBean (name="mail")
@SessionScoped
class MailBean {
String mailprovider;
String mailaddress;
@ManagedProperty
(value="#{address}")
AddressBean ref;
}
Mithilfe der EL ansprechbar:
#{address.surname} #{mail.ref.surname}
Scopes: none /request / view / session / application
Lazy Creation
(c) schmiedecke 11
SE2-3-JSF
31
Managed Beans und Data Binding
class MailBean {
String mailprovider;
String mailaddress;
AddressBean ref;
JSP
}
class AddressBean {
String surname;
String Address;
}
...
File register.jsp
<f:view> <h:form>
<b>Please provide your name</b><br/>
<h:outputText value="Name*"/></td>
<h:inputText id="name" required="true" value="#{address.surname}" size="20">
<f:validateLength minimum="2" maximum="12"/>
</h:inputText>
<h:message for="name" style="color: red;"/>
ruft
<p> ...
setter
</f:view>
(c) schmiedecke 11
SE2-3-JSF
32
Zugriffschutz
Authentifizierung
(Authentification)
WER IST DAS?
Autorisierung
(Authorization)
WER DARF WAS?
Zugriffsüberprüfung
(Checkpoint)
DARF DER DAS?
(c) schmiedecke 11
33
SE2-4-Authentifizierung
Server-basierte Authentifizierung
Container unterstützt Authentifizierung:
Login setzt Identität und Rolle der Session.
Identität und Rolle können aus dem Session-Kontext jederzeit
abgefragt werden
Technik ist im Prinzip egal (Fingerprint, Eyescan, …)
Principal und Rolle werden ermittelt und gespeichert.
Wichtig:
Credentials werden außerhalb der Anwendung (nämlich im
Container) verwaltet – weniger leicht hackbar!
(c) schmiedecke 11
34
SE2-4-Authentifizierung
Zugriffsschutz-Schema:
Server
Client
user
pw
Authentifi
-cation
role
Authoriza
tion Check
(c) schmiedecke 11
35
user
resource
role
SE2-4-Authentifizierung
Was ist Persistenz?
Persistenz bedeutet ursprünglich, dass Objekte die
Programmausführung "überleben"
durch Auslagerung auf externe Speichermedien,
z.B. durch Serialisierung und Dateiausschrieb bei Shutdown
Für langlaufende Programme:
Zwischenauslagerung nicht benötigter Objekte
"Hibernation" (Winterschlaf)
Persistenz heute:
Dynamische Ein- und Auslagerung von Objekten
(Materialisierung und Dematerialisierung)
normalerweise in Datenbanken
(c) schmiedecke 11
SE2-5-DB
36
Datenbank-Modellierung
Datenbanken verwalten Entitäten und ihre Beziehungen
Datenmodelle auf verschiedenen Abstraktionsstufen
ERM – Entity-Relationship-Modell
– ähnlich dem UML-Klassendiagramm
aber ohne Vererbung
– unabhängig vom Datenmodell
(m:n-Beziehungen sind möglich)
– kanonische Abbildung auf das Relationale Modell
(Verknüpfungstabellen)
– Notationsfalle:
Kardinalitäten werden an der Quelle notiert (UML am Ziel)
(c) schmiedecke 11
SE2-5-DB
37
ERM-Beispiel (UML-Notation)
class ERM online shop
Produk t
-
Orde r
Produktnummer: int
Preis: double
Name: String
*
Info: String
AnzKolli: int
Gewicht: double
* -
Bestelldatum: Date
Lieferdatum: Date
Versandform: String
Rechnungsnummer: int
Bearbeiter: String
*
*
*
1
*
1
Kunde
Einkaufsw agen
-
Datum: Date
(c) schmiedecke 11
Kreditk arte
1
1 -
Name: String
Strasse: String 1
Ort: String
PLZ: int
SE2-5-DB
1.. *
-
Kartentyp: String
Kartennummer: int
Gültigkeit: Date
38
Das Relationale Datenmodell
Das Relationale Modell
–
–
–
–
Entitäten als Tupel in Relationen (Zeilen in Tabellen)
Tupel (Zeilen) eindeutig identifizierbar durch Primärschlüssel
alle Attribute (Spalten) skalar (1.NF)
Beziehungen als Verweise in andere Relationen (Fremdschlüssel)
Integritätsbedingungen
– Entitätsintegrität: Primärschlüssel sind eindeutig
– Referentielle Integrität: Zu jedem Fremdschlüssel existiert ein Ziel.
Relationale Datenbank-Managementsysteme
– extrem effiziente und zuverlässige Implementierungen
(c) schmiedecke 11
SE2-5-DB
39
ERM Relationales Modell
Jedes Tupel benötigt einen Primärschlüssel
– inhärenter Schlüssel: eindeutiges Attribute
oder eindeutige Attributgruppe
– Surrogatschlüssel:
hinzugefügter eindeutiger Wert ohne
eigene Semantik, zumeist ein Zahlenwert
In der Softwareentwicklung benutzen wir
immer Surrogatschlüssel
– durch inhaltliche Anpassungen der Daten kann sonst die
Eindeutigkeit nachträglich verloren gehen.
(c) schmiedecke 11
SE2-5-DB
40
ERM Relationales Modell
Eine unidirektionale m:1-Beziehung wird als Fremdschlüssel
dargestellt
(c) schmiedecke 11
SE2-5-DB
41
ERM Relationales Modell
1:m-Beziehungen, m:n-Beziehungen und bidirektionale m:1Beziehungen werden mithilfe einer Verknüpfungstabelle dargestellt.
– Die Verknüpfungstabelle benötigt keinen eigenen Primärschlüssel
– ein eigener Primärschlüssel ermöglicht die Abbildung assoziativer
Klassen (im ORM)
(c) schmiedecke 11
SE2-5-DB
42
ERM Relationales Schema
Umformung kann automatisch erfolgen
Zahl der Tabellen wächst.
– Problem?
– Joins für Zugriffe kosten Zeit
class ERM online shop
Produk t
-
Orde r
Produktnummer: int
Preis: double
Name: String
*
Info: String
AnzKolli: int
Gewicht: double
* -
Bestelldatum: Date
Lieferdatum: Date
Versandform: String
Rechnungsnummer: int
Bearbeiter: String
*
*
*
1
*
1
Kunde
Einkaufsw agen
-
Datum: Date
Kreditk arte
1
1 -
Name: String
Strasse: String 1
Ort: String
PLZ: int
(c) schmiedecke 11
1.. *
-
Kartentyp: String
Kartennummer: int
Gültigkeit: Date
SE2-5-DB
43
Datenzugriffe - SQL
Datenbanksprache SQL
– deklarative Sprache
– Definition (DDL), Änderung (DML) und Abfrage (QL)
– äußerst effizient implementiert.
SELECT Name, Strasse, Ordernummer, Versanddatum
FROM Kunde, Order
WHERE Kunde.PLZ > 1200 AND Order.kunde = Kunde
AND Versanddatum < 01-10-2010
ORDER BY Versanddatum
(c) schmiedecke 11
SE2-5-DB
44
ODBC - SQL-Nutzung aus Programmen
Open Database Connectivity
– Spezifikation, nicht produktgebunden
– Microsoft-Entwicklung inzwischen standardisiert
– BS-Bestandteil ab Windows 2000/NT
Programmierschnittstelle (API) für RDBMS
– Registrierung der Verbindungsdaten
(URL, DB-Name, User, PW)
– Weitergabe von SQL-Anweisungen (Strings)
an die Datenbank
– Erzeugung weiterverarbeitbarer Daten
aus dem SQL-Ergebnis.
C++-Programm
C++-ODBC-API
ODBC-Treiber
für Oracle
Breite Unterstützung:
– Es gibt ODBC-"Treiber" für (praktisch) jedes RDBMS
(unter Windows – Unix ist noch nicht so gut unterstützt)
– Objektorientierte Programmiersprachen bieten APIs mit Klassen zum
Umgang mit ODBC-Aufrufen und –Daten.
(c) schmiedecke 11
SE2-5-DB
OracleRDBMS
45
JDBC
Java Database Connectivity
– Spezifikation, nicht produktgebunden
Programmierschnittstelle (API) für RDBMS
– Registrierung der Verbindungsdaten (URL, DB-Name, User, PW)
Klasse Connection
– Weitergabe von SQL-Anweisungen (Strings) an die Datenbank
Klasse Statement
– Erzeugung weiterverarbeitbarer Java-Objekte aus dem SQL-Ergebnis.
Klasse ResultSet
JDBC-"Treiber" für jede RDB-Implementierung
ODBC-JDBC-"Bridge" als generischer Treiber
(c) schmiedecke 11
SE2-5-DB
46
ORM – Objekt-relationales Mapping
JDBC ermöglicht den Zugriff auf Daten
Wir wollen Persistenz von Objekten!
Die Abbildung von Klassen auf Relationen (Tabellen)
gleicht der Abbildung von ERM-Entitäten auf Relationen
Nur die Vererbung fehlt noch.
Automatisierbar!
(c) schmiedecke 11
SE2-5-DB
47
ORM - Vererbung
Tabelle-je-Klasse
– Für jede Klasse der Hierarchie eine Tabelle
– enthält nur die nicht-geerbten Attribute
– Verweis auf Oberklassentabelle über OID (Primärschlüssel)
– Zusatzspalte mit dem Objekttyp
Daten eines Objekts auf mehrere Tabellen verteilt
aufwändige Zugriffe
Einzeltabelle
– Tabelle enthält eigene und geerbte Attribute
– Polymorphismen nur programmatisch erfassbar
Tabelle-je-konkrete-Klasse
– Zwischenform, weniger Redundanz,
– einfachere Zugriffe als Tabelle-je-Klasse
– weniger Redundanz als Einzeltabelle
(c) schmiedecke 08
SE2-4-Persistenzmodelle
48
ORM: Einzeltabelle
Vorteil: einfacher Zugriff ohne Join
(c) schmiedecke 08
SE2-4-Persistenzmodelle
49
ORM: Tabelle-je-konkrete-Klasse
Vorteil:
– einfacher Zugriff ohne Join
Graphik aus: Heide Balzert,
Lehrbuch der Objektmodellierung
Nachteil:
– Änderungen der Oberklasse müssen in mehreren
Tabellen durchgeführt werden.
(c) schmiedecke 08
SE2-4-Persistenzmodelle
50
ORM: Tabelle-je-Klasse
Vorteile:
– Nahe am Klassenmodell
– Änderungen in alle Klassen leicht durchzuführen
Graphik aus: Heide Balzert,
Lehrbuch der Objektmodellierung
Nachteile:
– viele Tabellen
– Zugriffe über Joins
(c) schmiedecke 08
SE2-4-Persistenzmodelle
51
Der "Traum"
Völlige Transparenz
Some
Secret
Mechanis
m
Nicht alle Objekte müssen persistent sein
Klassen als "persistent" deklarieren:
persistent class MyClass { ... }
Nicht alle Attribute müssen persistent sein:
persistent int myAttribute;
Alles andere könnte "automatisch ablaufen"
(c) schmiedecke 08
SE2-4-Persistenzmodelle
52
Direkte Datenbank-Anbindung per JDBC
class ERM online shop
Produk t
-
Orde r
Produktnummer: int
Preis: double
Name: String
*
Info: String
AnzKolli: int
Gewicht: double
* -
Bestelldatum: Date
Lieferdatum: Date
Versandform: String
Rechnungsnummer: int
Bearbeiter: String
*
*
*
1
*
1
Kunde
Einkaufsw agen
-
Datum: Date
Kreditk arte
1
1 -
Name: String
Strasse: String 1
Ort: String
PLZ: int
JDBC
(c) schmiedecke 11
1.. *
-
Kartentyp: String
Kartennummer: int
Gültigkeit: Date
Beziehung zwischen Klassen
und Tabellen nicht erkennbar
Regeln für den
"Zusammenbau" von Objekten
aus DB-Daten müssen explizit
programmiert werden
SE2-Zusammenfassung
SQL-Verwendung:
Datenbank enthält Daten, nicht
Objekte, d.h. es kann nicht
direkt nach Objekten gesucht
werden
53
ORM
class ERM online shop
Produk t
-
Orde r
Produktnummer: int
Preis: double
Name: String
*
Info: String
AnzKolli: int
Gewicht: double
* -
Bestelldatum: Date
Lieferdatum: Date
Versandform: String
Rechnungsnummer: int
Bearbeiter: String
*
*
ORM liefert die
Abbildung
zwischen Klassen
und Tabellen (gruppen)
Query Language
ermöglicht Suche
auf Objektebene
Es gibt keine
DML, sondern
Objekte werden
manipuliert und
dann persistiert
*
1
*
1
Kunde
Einkaufsw agen
-
Datum: Date
Kreditk arte
1
1 -
Name: String
Strasse: String 1
Ort: String
PLZ: int
1.. *
-
Kartentyp: String
Kartennummer: int
Gültigkeit: Date
ORM
(c) schmiedecke 11
SE2-Zusammenfassung
54
Das JPA-Persistenzframework
von ArgoUML generierter Code:
komplettierter und annotierter Code:
public class Student
extends Unimitglied {
public int matrikelnummer;
public int semester;
/**
*
* @element-type Dozent
*/
public Vector myDozent;
public Dozent myDozent;
}
(c) schmiedecke 11
@Entity
public class Student
extends Unimitglied {
@Id
Integer id;
int matrikelnummer;
int semester;
@ManyToMany
Collection<Dozent> myDozent;
@ManyToOne
Dozent myTutor;
public
public
…
publíc
public
SE2-Zusammenfassung
…
}
Integer getID() {…}
int getMatrikelnummer() {…}
void setId(Integer id) {…}
void setMatrikelnummer(…){…}
55
Automatisch erzeugtes DB-Schema
Das
Schema hängt von der gewählten
Vererbungs-Strategie ab!
(c) schmiedecke 11
SE2-Zusammenfassung
56
Entity-Annotation
@Entity
@Table(name="T_Student")
public class Student extend Unimitglied{
@Id @GeneratedValue int id;
public int getId() { return id; }
public void setId(int id) { this.id=id; }
…
}
@Entity deklariert eine Klasse als persistent.
Die Angabe des Tabellennamens ist optional
standardmäßig wird der Klassenname verwendet.
Alle Attribute müssen als Properties gekapselt werden.
Es muss eine numerische @Id – Property eingefügt werden,
am besten mit generierten Werten.
(c) schmiedecke 11
SE2-Zusammenfassung
57
Vererbungs-Annotation
@Entity
@Table(name="T_Mitglied")
@Inheritance(Strategy=Inheritance.JOINED
public class Unimitglied { ….}
Die Vererbungs-Strategie wird bei der Basisklasse annotiert
Standard ist SINGLE_TABLE
JOINED entspricht Einzeltabellen für alle Klassen der Hierarchie
Die Strategie TABLE_PER_CLASS (Tabelle je konkrete Klasse)
muss nicht auf allen Servern implementiert sein (Testen Sie
Glassfish daraufhin)
(c) schmiedecke 11
SE2-Zusammenfassung
58
ORM: Attributspezifikation per Annotation
@Basic
– Basisdatentyp
@LOB
– BLOB oder CLOB nach Bedarf
@Temporal
– Zeitwert
@Embedded
– eigebettetes Objekt (strukturiertes Objekt mit 1:1-Beziehung)
(c) schmiedecke 11
SE2-Zusammenfassung
59
Assoziations-Annotation
@ManyToMany
private Collection<Dozent> myDozent;
@ManyToOne
private Dozent myTutor;
@ManyToMany(mappedBy = "myDozent")
private Collection<Student> myStudent;
Annotation entweder immer der Attribute oder immer der Getter.
Annotation entsprechend den Kardinalitäten.
bei @XToMany sollte der Typ eine generische Collection sein (oder eine
Unterklasse von Collection).
Ersatzweise kann der Elementtyp als Attribut targetEntity="Dozent"
angegeben werden.
Bei bidirektionalen Assoziationen muss auf der zweiten Seite in einer
mappedBy-Angabe der Name des bezugnehmenden Attributs der ersten
Seite angegeben werden.
Bei @OneToOne kann das Attribut optional=false gesetzt werden
(c) schmiedecke 11
SE2-Zusammenfassung
60
Der Objekte-Cache
Sammelbecken für materialisierte Objekte
Dematerialiserung bei
– Transaktionsende
– Speicherbedarf
– expliziter Speicherung oder Synchronisation
Transaktionszustände der Cache-Objekte
– Es gibt materialisierte und neu erzeugte Objekte
– Objekte können im Cache verändert oder gelöscht werden
– 6 Transaktionszustände:
new clean, old clean
new dirty,
old dirty
new deleted, old deleted
– pro Transaktionszustand ein Cachebereich
(c) schmiedecke 11
SE2-Zusammenfassung
61
Synchronisation (bei Transaktionsende)
new clean
old clean
new dirty
old dirty
new deleted
old deleted
Cache-Aktionen abhängig von Transaktionszuständen
(c) schmiedecke 11
SE2-6-7-Architekturübersicht
62
JPA-Arbeitsweise:
Ein paar Vokabeln vorweg
Persistence Provider
- die JPA-Implementierung
Persistence Unit
- Umsetzung einer DB-Anbindung
- konfiguriert in der persistence.xml
Persistence Context
- der Cache
Entity-Manager
- realisiert (De-)Materialisierung
- setzt die Objektsuche um
- verwaltet den Cache
(c) schmiedecke 11
SE2-Zusammenfassung
63
Entity-Manager
find
query
Applikation
Detached objects
Persistenz-Kontext
persist
remove
(c) schmiedecke 11
SE2-Zusammenfassung
flush
merge
refresh
Entity
Manager
DB
64
Queries in JPA
Entity Manager ermöglicht Queries
– Dynamisch erzeugte Queries
– Statische "NamedQueries" als Entity-Annotationen
– Flush-Modus: Vor jeder Query wird der Persistenz-Kontext synchronisiert
JPQL – die Abfragesprache von JPA
– SQL-ähnliche Abfragen auf der Basis von Objekten (nicht Tabellen)
– Nicht unmittelbar DB-tauglich weniger Hacking-gefährdet
SQL-Abfragen – sog. "Native Queries"
– eher weniger sinnvoll, da das DB-Schema verborgen ist
– werden als Strings an die DB weitergericht
Criteria API
– Programmatischer Aufbau von Abfragen
(c) schmiedecke 11
SE2-Zusammenfassung
65
DAO – Data Access Objects
Annahme aus der Analysephase:
–
–
–
–
Klasse verwaltet die Menge ihrer Objekte
würde jetzt bedeuten, dass jede Klasse die DB-Details kennt
nicht transparent
DB-Wechsel sehr aufwändig
Data Access Object – der Objekte-Baumeister:
– Klassenspezifisches Zugriffsobjekt
– kapselt die DB-Details
– liefert und persistiert die
Anwendungsobjekte
Nachteile
Für jede Klasse ein DAO
Viel redundanter Code
Viel Aufwand bei DB-Wechsel
(c) schmiedecke 11
SE2-Zusammenfassung
66
OR-Mapping – Lazy Materialization
Laden externer Objekte:
– Was ist mit den assoziierten Objekten?
– Objektstruktur kann stark verzweigen...
Proxy-Entwurfsmuster:
–
–
–
–
Objekt erreichbar über ein Stellvertreterobjekt (Proxy)
Proxy liegt im Speicher
besorgt das Nachladen des Objekts bei Bedarf
enthält das OID
(c) schmiedecke 08
SE2-4-Persistenzmodelle
67
Proxy-Entwurfsmuster
Objektassoziation des Client verweist auf einen Platzhalter
– Proxy,
– imitiert Struktur des realen Subjekts.
Anfrage (request) erzeugt Bedarf:
– Das reale Subjekt wird geladen
– und die Anfrage delegiert.
(c) schmiedecke 08
SE2-4-Persistenzmodelle
68
Referenz-Architektur
IdeenListen
IdeeErstellen
IdeeService
IdeeDAO
Idee
(c) schmiedecke 11
KommentarDAO
Kommentar
Idee
Kommentieren
IdeeEinbringen
WettbewerbService
MitarbeiterDAO
Mitarbeiter
EntityManager
SE2-7-Geamtarchitektur
Wettbewerb
-DAO
Wettbewerb
69
Schichtentrennung durch Fassade
IdeenListen
IdeeErstellen
Idee
Kommentieren
IdeeService
IdeeEinbringen
WettbewerbService
ModellFassade
IdeeDAO
Idee
(c) schmiedecke 11
KommentarDAO
Kommentar
MitarbeiterDAO
Mitarbeiter
SE2-7-Geamtarchitektur
Wettbewerb
-DAO
Wettbewerb
70
Schichtentrennung durch EJB-Injection oder Lookup
IdeenListen
IdeeErstellen
IdeeService
IdeeDAO
Idee
(c) schmiedecke 11
KommentarDAO
Kommentar
Idee
Kommentieren
IdeeEinbringen
WettbewerbService
MitarbeiterDAO
Mitarbeiter
EntityManager
SE2-7-Geamtarchitektur
Wettbewerb
-DAO
Wettbewerb
71
Schritte zum Entwurfsmodell
(c) schmiedecke 11
SE2-7-Geamtarchitektur
72
Grundprinzipien des OO-Entwurfs
Lose Kopplung – starke Kohäsion
Kapselung
Client1
SOC
Client2
Client-2
Client-2
SOC – Sepration of Concerns
<<interface>>
Interface1
– Auftrennung von Schnittstellen
DIP – Dependency Inversion Principle
Service
<<interface>>
Interface2
Service-
(Nicht: Dependency Injection)
– Programmierung gegen Schnittstellen
NOC – No Circular Dependencies
– Auflösung zirkulärer Abhängigkeiten
DIP
Client
OCP – Open Cosed Principle
SE 2
NOC
C
<<interface>>
Interface2
Service-1
Service-2
<<interface>>
A-Interface
C
+aMethod()
A
© schmiedecke 10
<<interface>>
Interface1
Service2
Service1
– offen für Erweiterungen, aber
geschlossen für Veränderungen, d.h.
stabile Schnittstelle
Client-
+aMethod()
B
A
B
73
Kapselung von Abhängigkeiten:
Adapter
Zweck:
Strukturmuster
– Anpassung einer gelieferten Schnittstelle an eine erwartete
– Wiederverwendung von Klassen trotz leichter Inkompatibilitäten
– Verwendung von Bibliotheken
Kontext:
– Klasse hat die gewünschten Daten und das gewünschte Verhalten
– Schnittstelle passt nicht (Namen, Parameter, Ausnahmen...)
Client
<<interface>>
Target
+Request()
Adapter
e.g. a library class
+adaptee
Adaptee
+SpecificRequest()
SE2-7-Entwurfsmuster
74
Kapselung von Abhängigkeiten:
Fassade
Strukturmuster
Zweck:
– Vereinfachter Zugriff auf en
komplexes Subsystem
– Kapseln der inneren Struktur
Client
Client
Kontext:
– Verwendung eines Subsystems
mit wichtigen inneren
Abhängigkeiten
– Verwendung eines Subsystems,
bei dem die Gesamtfunktionalität
sich aus den Schnittstellen
mehrerer Klassen
zusammensetzt
– Alternative Subsysteme mit
unterschiedlicher Struktur
– "Querschnitt-Aufgaben" wie
Logging, Transaktionen oder
Zugangskontrolle
Facade
Package1
Subsystem Class
Subsystem Class
Subsystem Class
Subsystem Class
Subsystem Class
SE2-7-Entwurfsmuster
Subsystem Class
75
Kapselung von Abhängigkeiten:
Proxy
Zweck:
Strukturmuster
– Möglichkeit, ein Objekt durch ein Stellvertreter-Objekt (zeitweise) zu ersetzen
Kontext:
– Zugang zum echten Objekt schwierig oder teuer
– Direkter Zugang zum echten Objekt aus Sicherheitsgründen unerwünscht
<<interface>>
Client.
Subject
+someOperation()
RealSubject
Proxy
SE2-7-Entwurfsmuster
76
Kapselung von Änderungen:
Bridge
Zweck:
– Trennung von funktionaler Abstraktion und Implementierung
– so dass beide unabhängig voneinander verändert werden können
Strukturmuster
Kontext:
– Eine Klasse bietet eine bestimmte Leistung (Service) an
Beispiel: Transport
– Sie benutzt dazu eine andere Klasse als "Betriebsmittel" (Facility) Beispiel: Transportmittel
– Sowohl Service als auch Facility sollen unabhängig weiterentwickelt werden können
<<interface>>
Facility
ServiceAbstraction
+OperationImp()
+Operation()
RefinedService2
RefinedService2
ConcreteFacility2
SE2-7-Entwurfsmuster
ConcreteFacility2
77
Open-Closed-Priciple:
Strategy (schon bekannt)
Zweck:
Verhaltensmuster
– Austauschbarkeit von Algorithmen zur Laufzeit
– unabhängig von den nutzenden Clients
Kontext:
– Ein Dienstmerkmal soll von außen steuerbar ausgetauscht werden können
– sehr wichtig z.B. für Internationalisierung: länderspezifische Funktionalität
Context
+strategy
<<abstract>>
Strategy
+contextOperation()
+operation()
ConcreteStrategy
SE2-7-Entwurfsmuster
ConcreteStrategy
78
DRY:
Template Method
Zweck:
Verhaltensmuster
– Verwendung der Struktur eines Algorithmus mit verschiedenen Einzeloperationen
– "Generischer" Algorithmus
Kontext:
– Ein Algorithmus besteht aus einer globalen Ablaufstruktur (z.B. Iterieren über eine
Liste)
– und innerhalb dieser Struktur Detailoperationen (z.B. Verdoppeln des Elementwerts)
– Die Ablaufstruktur ist unabhängig von den Detailoperationen und wird an
verschiedenen Stellen benötigt.
AbstractClass
+templateMethod()
+Operation1()
+Operation2()
calls abstract operations
Operation1 and Operation 2
ConcreteClass
ConcreteClass
+Operation1()
+Operation2()
SE2-7-Entwurfsmuster
+Operation2()
+Operation1()
79
Kapselung von Abhängigkeiten:
Iterator
Zweck:
Verhaltensmuster
– Ursprünglich in Kombination mit Compositum
– Iteration über die Struktur ohne Kenntnis der Implementierung mit der Möglichkeit,
die in der Schnittstelle angegebene (für Knoten und Blätter implementierte) Methode
an beliebiger Stelle auszuführen.
– Verallgemeinert für traversierbare rekursive Strukturen.
Iterator
Aggregate
+First()
+Next()
+IsDone()
+CurrentItem()
+CreateIterator()
ConcreteAggregate
ConcreteIterator
SE2-7-Entwurfsmuster
80
Weitere sehr wichtige Entwurfsmuster
….die aus anderen Kontexten als bekannt vorausgesetzt werden:
Factory Method, Abstract Factory
Singleton
State
Composite
© schmiedecke 10
SE 2
81
Maßnahmen für die Skalierbarkeit
Programmieren gegen Interfaces (DIP)
– Interfaces reduzieren die Abhängigkeiten
– Erleichtern die Einführung perfomanterer Lösungen
(Nur die betroffenen EJBs müssen neu deployed werden)
Lose Kopplung durch Dependency Injection (IoC)
– Reduziert die Kopplung
– stellt dennoch eine feste Beziehung zwischen zwei Objekten her
Extra-lose Kopplung durch Directory-Lookup
– Bei Bedarf wird ein Service über die Registry gefunden
– Service-Locator-Pattern
Alle drei Techniken finden Sie im 2. CRUD-Modell
82
PROZESSMANAGEMENT
Prozessmanagement bedeutet
– Gestaltung und Kontrolle des Entwicklungsprozesses
– nach anerkannten Regeln
Management ist Voraussetzung für Prozessreife
z.B. nach CMM (Capability Maturity Model) :
–
–
–
–
–
Stufe 1: Initialer Prozess
Stufe 2: Wiederholbarer Prozess
Stufe 3: Definierter Prozess
Stufe 4: Gesteuerter Prozess
Stufe 5: Optimierender Prozess
(c) schmiedecke 11
= Ad-hoc-Prozess
= Intuitiver Prozess
= Qualitativer Prozess
= Quantitativer Prozess
= Rückgekoppelter Prozess
SE2-11-Software-Management
83
Produktsteuerung
Produktsteuerung umfasst
Anforderungsmanagement
Konfigurationsmanagement
Änderungsmanagement
Qualitätsmanagement
Konfiguration
Anforderung
Reviews
Änderungswunsch
Änderungsauftrag
Anforderung
Anforderung
(c) schmiedecke 11
Bewertung
Änderung
SE2-11-Software-Management
Integrationstest
84
KONFIGURATIONSMANAGEMENT (SCM)
Eine Konfiguration ist ein "Freeze"
– Projektzustand zu einem bestimmten Zeitpunkt
– freigegeben
– mit zugesicherten Eigenschaften
umfasst Vielzahl von Software-Elementen
–
–
–
–
Modelle, Spezifikationen, Dokumentationen
Module mit Testfällen
Werkzeuge
Datenbestände
beschrieben durch ein KID
(Konfigurations-Identifizierungs-Dokument).
Auslieferung umfasst nur einen Teil einer Konfiguration.
(c) schmiedecke 11
SE2-11-Software-Management
85
... viele, viele Konzepte.
Aber erst, wenn sie die große Linie erkennen,
habe ich mein Ziel erreicht.
Vielen Dank fürs Mitmachen!
