Komponentenbasierte Softwareentwicklung

Ich
• Prof. Dr. Stephan Kleuker, geboren 1967, verheiratet, 2
Kinder
• seit 1.9.09 an der FH, Professur für Software-Entwicklung
• vorher 4 Jahre FH Wiesbaden
• davor 3 Jahre an der privaten FH Nordakademie in Elmshorn
• davor 4 ½ Jahre tätig als Systemanalytiker und
Systemberater in Wilhelmshaven
Komponentenbasierte
Softwareentwicklung
Prof. Dr. Stephan Kleuker
Fachhochschule Osnabrück
• [email protected], Raum SI 0109
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
1
Ablauf
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
2
Verhaltenscodex
• 2h Vorlesung + 2h Praktikum = 5 CP
• Praktikum:
– 12-13 Übungsblätter mit jeweils 8 Punkten (Σ ≥ 100)
– Praktikum mit 80 oder mehr Punkten bestanden
• Prüfung: Projektaufgabe (Kenntnisse aus der Vorlesung
anwenden + eigene Untersuchungen, 2-3 Studis)
•
•
•
•
Rechner sind zu Beginn der Veranstaltung aus
Handys sind aus
Wir sind pünktlich
Es redet nur eine Person zur Zeit
• Sie haben die Folien zur Kommentierung in der Vorlesung
vorliegen, ab So-Abend mit Aufgaben im Netz,
Aufgabenzettel liegen in der Übung vor (Ihre Aufgabe)
• Folienveranstaltungen sind schnell, bremsen Sie mit Fragen
• von Studierenden wird hoher Anteil an Eigenarbeit erwartet
http://www.edvsz.fhhttp://www.edvsz.fh-osnabrueck.de/kleuker/index.html
• Probleme sofort melden
• Wer aussteigt teilt mit warum
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
3
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
4
Minimale Grundvoraussetzungen
Konzept der Lehrveranstaltung
• Gute Programmierkenntnisse in Java (z. B. Polymorphie)
• Gute Kenntnisse in objektorientiertem Design (z. B. einfache
Pattern, wie Observer-Observable bzw. Model-ViewController)
• Ordentliche Kenntnisse in der Datenbankmodellierung (ERModelle und deren Übersetzung in Tabellen)
• Ordentliche Kenntnisse des Transaktionsbegriffs
• Ordentliche Kenntnisse der Problematiken verteilter
Systeme (z. B. Deadlock, Livelock, synchronized)
synchronized
• Grundkenntnisse HTML/HTTP
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
• Zentrale, sich immer wiederholende Ideen des
Komponentenansatzes verstehen
• Zentrales Beispiel: Java Enterprise Edition (JEE) Technologien; ein zentraler Jobmotor im Enterprise-/WebBereich
• Ergänzung um Darstellungs- und Verknüpfungsschichten (z.
B. JavaServer Faces (JSF))
• Vorlesung: Vermittlung grundlegender Konzepte (20% mit
denen 80% erledigt werden)
• Praktikum: konkrete Umsetzung der Vorlesungsinhalte;
Selbststudium weiterer Teilbereiche
5
Themengebiete (Planung)
0
1
2
3
4
5
6
7
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
6
Literatur
• DAS Buch gibt es nicht, aber viele passende Bücher /
Internetquellen für Teilthemen
• Sun, The Java EE 5 Tutorial, 2008,
http://java.sun.com/javaee/5/docs/tutorial/doc/
• Sun, The Java EE 6 Tutorial - Volume I, 2009,
http://java.sun.com/javaee/6/docs/tutorial/doc/
• Martin Marinschek, Michael Kurz, Gerald Müllan, JavaServer
Faces 2.0, 2. Auflage , dpunkt.verlag , 2010
• Oliver Ihns, Dierk Harbeck, Stefan M. Heldt, und Holger
Koschek, EJB 3 professionell, dpunkt.verlag , 2007
• Thomas Stark, Java EE 5.0, Addison-Wesley, 2006
Grundlagen
Historie und Ziele der Softwareentwicklung
JavaBeans als Komponenten
Java Persistence API (JPA)
JavaServer Faces (JSF)
Enterprise JavaBeans (EJB) ???
Reflection
??
Dependency Injection
???
• Weitere: wird konkret zum jeweiligen Kapitel angegeben
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
7
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
8
0. Grundlagen
Erinnerung: XML (1/2)
• XML-Erinnerung
• Datenbanken
– ER-Modellierung
– Tabellenableitung
– SQL
– JDBC
– Transaktionen
• Design-Pattern Observer-Observable
• Java Naming and Directory Interface (JNDI)
• eXtensible Markup Language
• strukturierte maschinen- und ansatzweise menschenlesbare
Informationsbeschreibung
• Processing Instruction am Anfang (evtl. mit encoding-Info)
<?xml
<?xml version="1.0"?>
• Aufbau eines Elements mit Start- und End-Tags als Klammer
<Elementname> Inhalt </Elementname>
• Inhalt kann wieder aus Elementen bestehen, es ergibt sich
Baumstruktur
• Elemente können Attribute enthalten
<Elementname att1="bla" att2="blubb" >
Inhalt
</Elementname>
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
9
Erinnerung: XML (2/2)
Prof. Dr.
Stephan Kleuker
10
Erinnerung: Relationale Datenbanken
• Relationen (Tabellen) beschreiben einfache Entitäten
(Stammdaten)
• Relationen beschreiben Verknüpfungen zwischen Entitäten
(-> Fremdschlüssel)
• Elemente, die maximal Attribute, aber keinen Inhalt haben,
können verkürzt geschrieben werden
<Elementname att1="bla" att2="blubb" />
• Kommentar
<!-<!-- Isch bin ähn Gommenta -->
-->
•
•
•
•
•
• weitere Möglichkeiten, wie Querverweise
• Neben reiner Syntax kann auch die erlaubte inhaltliche
Struktur spezifiziert werden (DTD: Document Type
Definition), XML-Schema
• Viele spannende Werkzeuge zur XML-Verarbeitung
Komponentenbasierte SoftwareEntwicklung
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
Modellierung mit ER-Diagramm
Einfache Übersetzung in Tabellen
Effizienter Zugriff mit SQL
ACID-Transaktionen
Zugriff von Java mit JDBC
• Wir nutzen JavaDB (Apache Derby)
http://developers.sun.com/javadb/
11
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
12
Studenten besuchen Vorlesungen (1/5)
Student
Hoert
Vorlesung
Studenten besuchen Vorlesungen (2/5)
CREATE TABLE Student(
matnr INTEGER,
name VARCHAR(16),
semester VARCHAR(6),
CONSTRAINT PK_Student
PRIMARY KEY(matnr)
KEY(matnr)
);
matnr name
semester
matnr modulnr
modulnr titel
42
Ute
WiSe09
42
6942
6942
OOAD 3
43
Uwe
WiSe09
42
6943
6943
DB
2
44
Urs
SoSe10
43
6942
6944
Java
1
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
semester
INSERT INTO Student VALUES(42,'Ute','WiSe09');
INSERT INTO Student VALUES(43,'Uwe','WiSe09');
INSERT INTO Student VALUES(44,'Urs','SoSe10');
13
Studenten besuchen Vorlesungen (3/5)
INTO
INTO
INTO
VORLESUNG
VORLESUNG
VORLESUNG
Komponentenbasierte SoftwareEntwicklung
14
CREATE TABLE Hoert(
Hoert(
Matnr INTEGER,
Modulnr INTEGER,
CONSTRAINT PK_Hoert
PRIMARY KEY (MatNr,Modulnr
(MatNr,Modulnr),
MatNr,Modulnr),
CONSTRAINT FK_Hoert1
FOREIGN KEY (Matnr
(Matnr)
Matnr) REFERENCES Student(Matnr),
Student(Matnr),
CONSTRAINT FK_Hoert2
FOREIGN KEY (Modulnr
(Modulnr)
Vorlesung(Modulnr)
Modulnr) REFERENCES Vorlesung(Modulnr)
);
VALUES(6942,'OOAD',3);
VALUES(6943,'DB',2);
VALUES(6944,'Java',1);
Prof. Dr.
Stephan Kleuker
Prof. Dr.
Stephan Kleuker
Studenten besuchen Vorlesungen (4/5)
CREATE TABLE Vorlesung(
modulnr INTEGER,
titel VARCHAR(10),
semester INTEGER,
CONSTRAINT PK_Vorlesung
PRIMARY KEY(modulNr)
KEY(modulNr)
);
INSERT
INSERT
INSERT
Komponentenbasierte SoftwareEntwicklung
INSERT INTO Hoert VALUES(42,6942);
INSERT INTO Hoert VALUES(42,6943);
INSERT INTO Hoert VALUES(43,6943);
15
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
16
Studenten besuchen Vorlesungen (5/5)
Erinnerung: ACID-Transaktionen
public static void main(String[]
main(String[] s) {
try {
Connection con = DriverManager.getConnection(
DriverManager.getConnection(
"jdbc:derby://localhost:1527/Hochschule",
"kleuker",
kleuker", "kleuker
"kleuker");
kleuker");
Statement stmt = con.createStatement();
con.createStatement();
ResultSet rs = stmt.executeQuery("SELECT * FROM Student");
while (rs.next())
rs.next()) {
System.out.print(rs.getInt(1) + ": "
+ rs.getString(2)+" Start:" + rs.getString(3));
}
con.close();
con.close();
} catch (SQLException
(SQLException e) {
e.printStackTrace();
e.printStackTrace();
42: Ute Start:WiSe09
}
43: Uwe Start:WiSe09
}
44: Urs Start:SoSe10
Atomicity
(Atomarität)
Transaktionen werden entweder ganz
oder gar nicht ausgeführt
Consistency Transaktionen überführen die Datenbank
(Konsistenz)
Isolation
(Isolation)
Durability
(Dauerhaftigkeit)
von einem konsistenten Zustand in einen
anderen konsistenten Zustand
Nebenläufige (gleichzeitige) Transaktionen
laufen jede für sich so ab, als ob sie alleine
ablaufen würden.
Die Wirkung einer abgeschlossenen
Transaktion bleibt (auch nach einem
Systemausfall) erhalten.
Benötigt derbyclient.jar als JDBC-Treiber (im Installationsverzeichnis)
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
17
Transaktionen
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
18
Design-Pattern Observer-Observable
Zustände einer Transaktion
• Es gibt Subjekte, für deren Zustand sich viele interessieren, (z.
B. Nachrichtenkanäle)
• Die Subjekte bieten die Möglichkeit, dass sich Interessenten
anmelden (z. B. Kanal abonnieren)
• Bei jeder Subjektzustandsänderung werden Interessenten
informiert (neue Nachrichten)
• Interessent muss sich bei Subjekt anmelden
• Damit obiges Objekt weiß, wie Interessent angesprochen
werden soll, muss Interessent Schnittstelle realisieren
• Hinweis: Enge Verwandtschaft zu Model-View-Controller
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
19
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
20
Beobachter (Observer – Observable)
Neu: Java Naming and Directory Interface
• JNDI: flexible Anbindung sehr unterschiedlicher Systeme
(Drucker, Filesystem, LDAP, Services eines Server),
betriebssystemunabhängig
• Sun spezifiziert API; andere Systeme müssen es realisieren
• Grundidee: man kann unter festgelegten Namen bestimmte
Objekte erhalten
„Hey, JNDI-Realisierung, gib mit mal zu „datenbank“
passendes Objekt, das ich auf Datenbankklasse casten
kann“
• Man kann über JNDI Eigenschaften der verwalteten Objekte
abfragen (gelbe Seiten, directory service)
• Literatur: http://java.sun.com/developer/technicalArticles/
Programming/jndi/index.html
http://java.sun.com/products/jndi/tutorial/index.html
Anmerkung: Gibt Varianten; diese ist C++-typisch
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
21
Konzept JNDI
Komponentenbasierte SoftwareEntwicklung
22
Generelle Idee des Naming Service
• Grundidee: Zentrale Servicekomponente verwaltet Objekte
unterschiedlicher Klassen
• Objekten sind Namen (Strings) zugeordnet
• Nutzer kennt Namen des ihn interessierenden Objekts
• Nutzer erhält Objekt (und muss Typ ggfls. casten) und nutzt es
• Service erweitert um Gruppierungsmöglichkeiten
(Verzeichnisse), Suchmöglichkeiten (gelbe Seiten),
Möglichkeit Eigenschaften der Objekte abzufragen
• Ansatz sollte von JDBC bekannt sein
Meine Java-Applikation
nutzt
JNDI-Interface
fbau
indungsau
1: v=Verb
JNDI-Realisierung
2: o=v.lookup("KEY1")
„wildes System“
Nutzer
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
Prof. Dr.
Stephan Kleuker
23
Komponentenbasierte SoftwareEntwicklung
JNDI (Prinzip)
Name
Objektreferenz
KEY1
obj1
BLA7
...
reales Objekt
z. B. Datei
z. B. DB-Anbindung
...
Prof. Dr.
Stephan Kleuker
24
Konzept des JNDI-Ablaufes
Beispiel
• Zusammenbasteln der Aufrufparameter (was will ich genau,
was muss JNDI wissen), z. B. mit Properties oder HashTable
• Zentral: Context.INITIAL_CONTEXT_FACTORY
• Erstellung eines Zugriffs über ein Context-Objekt
• Abfrage von Informationen über Context-Objekt; Ergebnisse
vom Typ Object (zu casten)
• Typischer Aufruf Object o = context.lookup(<name>)
context.lookup(<name>)
• Beispiel im Folgenden: Zugriff auf Dateisystem (geht auch
über File-Klassen)
• Benötigt fscontext.jar, providerutil.jar
(fscontext-1_2-beta3.zip)
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
25
Beispiel
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
26
Weitere Details zu JNDI
public static void main(String[]
main(String[] args)
args) {
Hashtable env = new Hashtable();
Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY,
env.put(Context.INITIAL_CONTEXT_FACTORY,
"com.sun.jndi.fscontext.RefFSContextFactory");
com.sun.jndi.fscontext.RefFSContextFactory");
env.put(Context.PROVIDER_URL,
env.put(Context.PROVIDER_URL, "file:///arbeit/lib
"file:///arbeit/lib");
file:///arbeit/lib");
try {
Context context = new InitialContext(env);
InitialContext(env);
NamingEnumeration ne = context.listBindings("");
context.listBindings("");
while (ne.hasMore())
ne.hasMore()) {
Binding b = (Binding) ne.next();
ne.next();
System.out.println(b.getName()
System.out.println(b.getName() + " :: " + b.getObject());
b.getObject());
}
context.close();
context.close();
} catch (NamingException
(NamingException ex) {
System.out.println("Frust weil: " + ex.getExplanation());
ex.getExplanation());
}
fscontext.jar :: D:\
D:\arbeit\
arbeit\lib\
lib\fscontext.jar
}
providerutil.jar :: D:\
D:\arbeit\
arbeit\lib\
lib\providerutil.jar
}
test :: com.sun.jndi.fscontext.RefFSContext@3a6727
Komponentenbasierte SoftwareEntwicklung
public static void main(String[]
main(String[] args)
args) {
Hashtable env = new Hashtable();
Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY,
env.put(Context.INITIAL_CONTEXT_FACTORY,
"com.sun.jndi.fscontext.RefFSContextFactory");
com.sun.jndi.fscontext.RefFSContextFactory");
env.put(Context.PROVIDER_URL,
env.put(Context.PROVIDER_URL, "file:///arbeit/lib
"file:///arbeit/lib");
file:///arbeit/lib");
try {
Context context = new InitialContext(env);
InitialContext(env);
Object ob = context.lookup("fscontext.jar");
context.lookup("fscontext.jar");
System.out.println(ob);
System.out.println(ob);
context.rename("test",
context.rename("test", "tast");
Object ob2 = context.lookup("tast");
context.lookup("tast");
System.out.println(ob2.getClass());
context.rename("tast",
context.rename("tast", "test");
context.close();
context.close();
} catch (NamingException
(NamingException ex) {
System.out.println("Frust weil: " + ex.getExplanation());
ex.getExplanation());
}
D:\
D:\arbeit\
arbeit\lib\
lib\fscontext.jar
}
class com.sun.jndi.fscontext.RefFSContext
Prof. Dr.
Stephan Kleuker
27
• Informationen sind hierarchisch gruppiert (vergleichbar zum
Dateisystem)
• Nutzer kann neue Daten mit Hilfe von JNDI anlegen
• Nutzer kann Daten über JNDI verändern
• Nutzer kann sich anmelden, um über Änderungen von JNDIEinträgen informiert zu werden
• JNDI bietet Möglichkeit zum Informationsaustausch
zwischen Programmen
• JNDI wird eher für statische Informationen genutzt
(Funktionalität abfragen, Funktionalität anbieten)
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
28
JNDI etwas systematischer (1/2)
JNDI etwas systematischer (2/2)
• Directory Object
– Objekt, zu dem Attribute gespeichert werden
– Z. B. Nutzer-Objekt mit Attributen Name, Passwort, E-Mail
(-> z. B. LDAP-Eintrag)
• Directory Service
– ist Naming Service
– erlaubt, Attribute abzufragen, zur Auswertung zu nutzen,
zu ergänzen, …
– Z. B. bind(name, objekt, attribute)
• Directory
– Menge von verbundenen Directory Objects (z. B.
Dateibaum)
http://www.javaworld.com/javaworld/jw-01-2000/jw-01howto.html
• Name
– Atomarer Name, z. B. usr oder com
– Zusammengesetzter Name, z. B. /usr/local/bin
• Naming Service
– Verbindet verständliche Namen mit technischen Kürzel
Telefonbuch: Kleuker -> 05419693884
Verzeichnis: io.sys -> Datei auf der Platte
– Methoden lookup(name), bind(name, objekt)
• Binding: Verbindung zwischen Namen und einem Objekt
• Context: Menge von Bindings (atomarer Name -> Objekt)
• Objekt kann wieder Kontext sein
(local -> Objekt, das (auch) (Sub-)Context ist)
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
29
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
30