Folien ab 25.9.12 - Hochschule Osnabrück

Grundlagen der
Komponentenbasierten
Softwareentwicklung
Prof. Dr. Stephan Kleuker
Hochschule Osnabrück
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
1
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
• [email protected], Raum SI 0109
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
2
Ablauf
• 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)
• Folienveranstaltungen sind schnell, bremsen Sie mit Fragen
• von Studierenden wird hoher Anteil an Eigenarbeit erwartet
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
3
Verhaltenscodex
•
•
•
•
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 (Ihre Aufgabe), Folien zweite Tage vor VL abends
mit Aufgaben im Netz
http://
http://www.edvsz.hs
://www.edvsz.hswww.edvsz.hs-osnabrueck.de/kleuker/index.html
• Probleme sofort melden
• Wer aussteigt, teilt mit, warum
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
4
Minimale Grundvoraussetzungen
• 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)
• Grundkenntnisse HTML/HTTP
• Grundkenntnisse verteilte Systeme
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
5
Konzept der Lehrveranstaltung
• Zentrale, sich immer wiederholende Ideen des
Komponentenansatzes verstehen
• Zentrales Beispiel: Teile der 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
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
6
Themengebiete (Planung)
0 Grundlagen
1 Historie und Ziele der Softwareentwicklung
2 JavaBeans als Komponenten
3 Annotationen und Bean Validation
4 Java Persistence API (JPA)
5 JavaServer Faces (JSF)
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
7
Literatur
• DAS Buch gibt es nicht, aber viele passende Bücher /
Internetquellen für Teilthemen
• Sun, The Java EE 6 Tutorial - Volume I, 2009,
http://download.oracle.com/javaee/6/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
• Weitere: wird konkret zum jeweiligen Kapitel angegeben
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
8
0. Grundlagen
• XML-Erinnerung
• Datenbanken
– ER-Modellierung
– Tabellenableitung
– SQL
– JDBC
– Transaktionen
• Design-Pattern Observer-Observable
• Java Naming and Directory Interface (JNDI)
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
9
Erinnerung: XML (1/2)
• eXtensible Markup Language
• strukturierte maschinen- und ansatzweise menschenlesbare
Informationsbeschreibung
• Processing Instruction am Anfang (evtl. mit encoding-Info)
<?xml
<?xml version="1.0"?>
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
att1="bla"
bla" att2="blubb
att2="blubb"
blubb" >
Inhalt
</Elementname>
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
10
Erinnerung: XML (2/2)
• Elemente, die maximal Attribute, aber keinen Inhalt haben,
können verkürzt geschrieben werden
<Elementname att1="bla
att1="bla"
bla" att2="blubb
att2="blubb"
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
Prof. Dr.
Stephan Kleuker
11
Erinnerung: Relationale Datenbanken
• Relationen (Tabellen) beschreiben einfache Entitäten
(Stammdaten)
• Relationen beschreiben Verknüpfungen zwischen Entitäten
(-> Fremdschlüssel)
•
•
•
•
•
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://www.oracle.com/technetwork/java/javadb/overview
/index.html
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
12
Studenten besuchen Vorlesungen (1/5)
Student
Hoert
Vorlesung
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
13
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)
);
INSERT INTO Student VALUES(42,'Ute','WiSe09');
INSERT INTO Student VALUES(43,'Uwe','WiSe09');
INSERT INTO Student VALUES(44,'Urs','SoSe10');
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
14
Studenten besuchen Vorlesungen (3/5)
CREATE TABLE Vorlesung(
modulnr INTEGER,
titel VARCHAR(10),
semester INTEGER,
CONSTRAINT PK_Vorlesung
PRIMARY KEY(modulNr
KEY(modulNr)
modulNr)
);
INSERT INTO VORLESUNG VALUES(6942,'OOAD',3);
INSERT INTO VORLESUNG VALUES(6943,'DB',2);
INSERT INTO VORLESUNG VALUES(6944,'Java',1);
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
15
Studenten besuchen Vorlesungen (4/5)
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),
Matnr),
CONSTRAINT FK_Hoert2
FOREIGN KEY (Modulnr
(Modulnr)
Modulnr) REFERENCES Vorlesung(Modulnr
Vorlesung(Modulnr)
Modulnr)
);
INSERT INTO Hoert VALUES(42,6942);
INSERT INTO Hoert VALUES(42,6943);
INSERT INTO Hoert VALUES(43,6943);
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
16
Studenten besuchen Vorlesungen (5/5)
public static void main(String[]
main(String[] s) throws SQLException {
DriverManager.registerDriver(
DriverManager.registerDriver(
new org.apache.derby.jdbc.ClientDriver());
org.apache.derby.jdbc.ClientDriver());
try (Connection con = DriverManager
.getConnection("
getConnection("jdbc:derby
("jdbc:derby://localhost:1527/Hochschule",
jdbc:derby://localhost:1527/Hochschule",
"kleuker",
kleuker", "kleuker
"kleuker"))
kleuker")) {
Statement stmt = con.createStatement();
con.createStatement();
ResultSet rs = stmt.executeQuery("SELECT
stmt.executeQuery("SELECT * FROM Student");
while (rs.next())
rs.next()) {
System.out.print(
System.out.print(rs.getInt(1
rs.getInt(1)
(1)
+ ": " + rs.getString(2)
rs.getString(2) + " Start:");
System.out.println(
System.out.println(rs.getString(3
rs.getString(3));
(3)); 42: Ute Start:WiSe09
}
43: Uwe Start:WiSe09
}
44: Urs Start:SoSe10
}
• Benötigt derbyclient.jar als JDBC-Treiber (im
Installationsverzeichnis)
• Connection realisiert ab Java 7 Interface AutoCloseable
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
17
Erinnerung: ACID-Transaktionen
Atomicity
Transaktionen werden entweder ganz
oder gar nicht ausgeführt
(Atomarität)
Consistency
(Konsistenz)
Isolation
(Isolation)
Durability
(Dauerhaftigkeit)
Transaktionen überführen die Datenbank
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
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
18
Transaktionen
Zustände einer Transaktion
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
19
Design-Pattern Observer-Observable
• 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
20
Beobachter (Observer – Observable)
Anmerkung: Gibt Varianten; diese ist C++-typisch
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
21
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 mir mal zu „datenbank“
passendes Objekt, das ich auf Datenbankklasse casten kann“
• Man kann über JNDI Eigenschaften der verwalteten Objekte
(z. B. eines Servers) abfragen (gelbe Seiten, directory service)
• Literatur:
http://java.sun.com/developer/technicalArticles/Programmi
ng/jndi/index.html
http://download.oracle.com/javase/jndi/tutorial/index.html
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
22
Konzept JNDI
• Ansatz sollte von JDBC bekannt sein
Meine Java-Applikation
nutzt
JNDI-Interface
JNDI-Realisierung
„wildes System“
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
23
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
JNDI (Prinzip)
2: o=v.lookup("KEY1")
Nutzer
Komponentenbasierte SoftwareEntwicklung
Name
Objektreferenz
KEY1
obj1
BLA7
...
reales Objekt
z. B. Datei
z. B. DB-Anbindung
...
Prof. Dr.
Stephan Kleuker
24
Konzept des JNDI-Ablaufes
• 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(<
context.lookup(<name
(<name>)
name>)
• Beispiel im Folgenden: Zugriff auf Dateisystem (geht auch
über File-Klassen)
• Benötigt fscontext.jar, providerutil.jar
(fscontext-1_2-beta3.zip)
• Hinweis: Dient als kleines, einfach zu
nutzendes Beispiel
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
25
Beispiel
public static void main(String[]
main(String[] args)
args) {
Hashtable<
Hashtable<String,String>
String,String> env = new Hashtable<>();
Hashtable<>();
env.put(
env.put(Context.INITIAL_CONTEXT_FACTORY,
Context.INITIAL_CONTEXT_FACTORY,
"com.sun.jndi.fscontext.RefFSContextFactory");
com.sun.jndi.fscontext.RefFSContextFactory");
env.put(
env.put(Context.PROVIDER_URL,
Context.PROVIDER_URL, "file:///arbeit/lib");
try {
Context context = new InitialContext(
InitialContext(env);
env);
Object ob = context.lookup("fscontext.jar");
context.lookup("fscontext.jar");
System.out.println(ob);
System.out.println(ob);
context.rename("
context.rename("test
("test",
test", "tast
"tast");
tast");
Object ob2 = context.lookup("
context.lookup("tast
("tast");
tast");
System.out.println(ob2.getClass());
System.out.println(ob2.getClass());
context.rename("
context.rename("tast
("tast",
tast", "test
"test");
test");
context.close();
context.close(); // gehoert besser nach finally
} catch (NamingException
(NamingException ex) {
System.out.println("Frust
System.out.println("Frust weil: " + ex.getExplanation());
ex.getExplanation());
}
D:\
D:\arbeit\
arbeit\lib\
lib\fscontext.jar
}
class com.sun.jndi.fscontext.RefFSContext
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
26
Beispiel
public static void main(String[]
main(String[] args)
args) {
Hashtable<
Hashtable<String,String>
String,String> env = new Hashtable<>();
Hashtable<>();
env.put(
env.put(Context.INITIAL_CONTEXT_FACTORY,
Context.INITIAL_CONTEXT_FACTORY,
"com.sun.jndi.fscontext.RefFSContextFactory");
com.sun.jndi.fscontext.RefFSContextFactory");
env.put(
env.put(Context.PROVIDER_URL,
Context.PROVIDER_URL, "file:///arbeit/lib");
try {
Context context = new InitialContext(
InitialContext(env);
env);
NamingEnumeration ne = context.listBindings("");
context.listBindings("");
while (ne.hasMore())
ne.hasMore()) {
Binding b = (Binding) ne.next();
ne.next();
System.out.println(
System.out.println(b.getName()
b.getName() + " :: " + b.getObject());
b.getObject());
}
context.close();
context.close();
} catch (NamingException
(NamingException ex) {
System.out.println("Frust
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
Prof. Dr.
Stephan Kleuker
27
Weitere Details zu JNDI
• 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)
• 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 bind(name, objekt), lookup(name),
• 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
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
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
30
1. Historie und Ziele der Softwareentwicklung
•
•
•
•
•
•
Entwicklung der Programmierung
Bedeutung von Abstraktion
Domain Specific Languages
Model Driven Architecture
Komponenten-Ansatz
Komponenten-Architekturen
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
31
Entwicklung der Programmierung (1/2)
• Erste Rechner: Programmierung extrem HW-nah
(Maschinenbefehle eng verwandt mit Stromschaltern)
• Assembler: Befehle wie
– Lege Wert der Speicherzelle X in Register R1
– Wenn Wert in R1 gleich Null springe zu Zeile 4242
Ein Assemblerbefehl ersetzt mehre Maschinenbefehle
• Einfache Programmiersprachen, Fortran, Algol 60, z. B.
– n:=n+1
– for q:=1 step s until n do A[q]:=B[q]
– Sprünge (goto), Unterprogramme und Funktionen
Programmiersprachenbefehl umgesetzt als mehrere
Assemblerbefehle
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
32
Entwicklung der Programmierung (2/2)
• Modularisierung von Programmen / Bibliothekennutzung
– z. B. Trennung von Header-Dateien und
Implementierung
– stdio.h, math.h
• Objektorientierung
– Weitere logische Strukturierung mit Klassen
– Information Hiding
– Statische und dynamische Polymorphie
• Frameworks
– Programmierte Teillösungen für Standardaufgaben (z. B.
Datenverwaltung, Transaktionsmanagement)
– Entwickler muss zur Nutzung Interfaces erfüllen
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
33
Abstraktion
Framework
Bibliothek
Programmiersprache
Assembler
Maschinensprache
• Entwicklung auf/mit abstrakterer Ebene immer wesentlich
schneller als auf unterer Ebene
• Jeder Abstraktionsschritt kann Performance kosten
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
34
Generelle Ziele der Softwareentwicklung
• Schnelle Entwicklung
– Keine fachliches Ergebnis doppelt
– Einfache Nutzung existierender Ergebnisse (ohne
Detailkenntnisse)
• Qualitativ hochwertige Ergebnisse
– Nutzung validierter und verifizierter Verfahren
– Korrektheit und Performance
• Übertragbarkeit der Ergebnisse
– Schnelle Wiederverwendung bei ähnlichen Aufgaben
– Unabhängigkeit von konkreten Sprachen und
Betriebssystemen
– Integrierbar in andere Software-Architekturen
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
35
Aktuelle Themen der Softwareentwicklung (1/4)
Domain Specific Languages
• Problem: General Purpose Sprachen sind sehr mächtig, aber
für spezifische Entwicklungsbereiche geht sehr viel Energie
in für den Bereich gleichartige Programmierung
• Spezielle Entwicklungssprache für individuellen Bereich,
spezielle komplexe Hochsprachelemente anbietet
• Neue Sprache z. B. mit XML (Syntax mit XML-Schema)
darstellbar; Umwandlung in Programm mit Übersetzung (z.
B. XSLT) ; hilfreich ist Visualisierungsmöglichkeit der DSL
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
36
Aktuelle Themen der Softwareentwicklung (2/4)
Model Driven Architecture
• Ansatz: Häufig benötigt man die gleichen Ideen (z. B.
Sortierverfahren) in sehr unterschiedlichen Sprachen;
warum nicht in einer Sprache modellieren und dann in
andere Sprachen transformieren?
• Zur Modellbeschreibung wird eigene Sprache mit eigener
Semantik benötigt (Metamodell und Metametamodell)
• Ansatz: Umwandlung des CIM mit Transformationsregeln in
ein PIM und dann ein PSM
CIM: Computer Independent Model
PIM: Platform Independent Model
PSM: Platform Specific Model
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
37
Aktuelle Themen der Softwareentwicklung (3/4)
Metamodell
Codegenerator
Verwaltung
liname:String
*
element
Element
name:String
typ:String
public class {Verwaltung.liname} {
<foreach Element e:Verwaltung.element>
private List<{e.typ}> {e.name};
}
Verwaltung
Modell liname=„Hauptliste“
Element
name=„kunden“
typ=„Kunde“
Element
name=„produkte“
typ=„Produkt“
generierter Code
public class Hauptliste {
private List<Kunde> kunden;
private List<Produkt> produkte;
}
http://www.openarchitectureware.org/ jetzt Teil von Eclipse
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
38
Aktuelle Themen der Softwareentwicklung (4/4)
Komponentenbasierte Entwicklung
• Idee: Software besteht aus Bausteinen
• Komplexe Software wird aus einfachen Bausteinen
zusammengebaut
• Beispiel 1: GUI aus Buttons, ListBox, Slider, Panel, ....
• Beispiel 2: Kundenverwaltung, Lagerhaltung,
Bestellabwicklung, Finanzabwicklung
• Bausteine können getrennt genutzt werden; sind
konfigurierbar
• Bausteine müssen zusammenarbeiten können
• Konkretes Beispiel: Eclipse mit Plugins
• Hinweis: Trotz üblichem Methodenkrieg können Teilideen
aller Ansätze integriert werden
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
39
Komponentenidee genauer (1/2)
• Funktionalität nutzbar für andere (Schnittstelle)
– Benötigt klare Schnittstellendefinition
– Welche Methoden/Dienste werden angeboten
(Parameter, Ergebnisse, Ausnahmen)
– Welche Objekte (die Schnittstellenspezifikationen
erfüllen) werden benötigt
• Einstellungsmöglichkeiten
– z. B. spezielle Methoden
– z. B. Einstellungsdatei (XML)
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
40
Komponentenidee genauer (2/2)
• Funktionsgarantie
– Genannte Dienste werden immer (auch bei neuen
Versionen) angeboten
– Dienstqualität (Korrektheit, Performance) ist garantiert
• direkt nutzbar
– Möglichst Installation durch Kopieren
– Möglichst plattformunabhängig
– Möglichst leicht in andere Systeme integrierbar
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
41
Komponentenframework
• Komponente muss bestimmte Schnittstellen befriedigen,
damit Framework nutzbar wird
• Typische Aufgaben eines Frameworks:
– Framework kennt aktive Komponenten, kann so
Konflikte lösen
– Framework ermöglicht es, dass Komponenten
Informationen austauschen
– Framework bietet Standarddienste: Persistenz,
Transaktionssicherheit, Anmeldung, Suche
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
42
Zentrale Aspekte der Komponentenorientierung
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
43
Komponentendiagramm
• Bilder zeigen zwei alternative
Darstellungen
• Komponenten bieten
Schnittstellen(realisierungen) (Kreis)
und benötigen
Schnittstellen(realisierungen)
(Halbkreis)
• Komponenten können über
Schnittstellen in Diagrammen verknüpft
werden
• in Komponenten können zugehörige
Klassen eingezeichnet werden
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
44
Zusammenspiel von Komponenten (1/3)
• Variante 1: Direkte Kommunikation
• Komponenten bieten Schnittstellen zur Nutzung und
benötigen Objekte zur Ausführung
• Direktes Netzwerk von Komponenten
• Vorteil: wenig Restriktionen in Entwicklung
(Individualentwicklung)
• Nachteil: keine Standardisierung; gleichartige Aufgaben
evtl. mehrfach realisiert
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
45
Beispiel: direkt verbundene Komponenten
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
46
Zusammenspiel von Komponenten (2/3)
• Variante 2: Nutzung einer Kommunikationsplattform mit
zentralen Diensten
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
47
Beispiele zentraler Dienste
• Plattform bietet Kommunikationsdienste
– Komponente abonniert sie interessierende Daten
– Komponente bietet neue Daten zum abonnieren an
• Lokalisationsdienst : Finden von Daten /Komponenten
• Darstellungsdienst: Visualisierung der Daten
• Transportdienst : transparenter und sicherer
Datentransport der Komponenten untereinander
• Speicherungsdienst : Daten persistieren, Konsistenz,
Replikation und Backup
• Sicherungsdienst : Sicherung der Integrität , Kontrolle von
Nutzerauthentifizierung und –autorisierung
• Vorteil: klar strukturiertes Kommunikationsverhalten;
modularer Aufbau
• Nachteil: Plattform muss hoch performant sein; kein
direkter Informationsaustausch
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
48
Beispiel mit Kommunikationsplattform
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
49
Zusammenspiel von Komponenten (3/3)
• Variante 3:
Komponentenframework
• Komponente selbst läuft
in einem Container
• Container stellt Dienste
zur Verfügung (s. vorher)
• Plattform regelt
Zusammenspiel der
Container
• Vorteil: Konzentration auf
Container
Geschäftsprozess
• Nachteil: Abhängigkeit vom Framework; Performance (?)
• Hinweis: gibt weitere Varianten; Varianten nicht disjunkt
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
50
Beispiel: Komponenten in Containern
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
51
Entwicklung von Komponenten
• Zentrales Ziel der Komponentenentwicklung durchzieht
gesamten Entwicklungsprozess
• Anforderungsanalyse: nicht-triviale unabhängige
Teilaufgaben
• Generell typisch: zentrale Informationsverwaltung (z. B.
Stammdaten)
• Komponentensysteme wachsen schrittweise
– Klärung zentraler Prozesse (Stammdatenverwaltung)
– Anschluss weiterer Prozesse
• Migration erfolgt ebenfalls schrittweise; häufig aber Beginn
mit einzelnen Komponenten, die sich an Altsystem
anschließen
• Komponentenentwicklung hat (einmaligen) Mehraufwand
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
52
Beispiele Komponentenarchitekturen
• Microsoft: Component Object Model (COM, bzw. COM+,
DCOM, ActiveX)
• OMG: Common Object Request Broker Architecture
(CORBA)
• Sun: Java Beans und Enterprise Java Beans
• OSGi Alliance: OSGi (früher „Open Services Gateway
initiative“)
– Basis Java Virtual Machine
– Ziel ist Gerätevernetzung (Handy,
Gebäudeautomatisierung, Automotive)
– Grundlage für Eclipse-Plugins (Equinox)
Komponentenbasierte SoftwareEntwicklung
Prof. Dr.
Stephan Kleuker
53