vierseitig - Hochschule Osnabrück
Werbung
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 Hochschule 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 (Ihre Aufgabe), Folien zweite Tage vor VL abends mit Aufgaben im Netz • Folienveranstaltungen sind schnell, bremsen Sie mit Fragen • von Studierenden wird hoher Anteil an Eigenarbeit erwartet http://www.edvsz.hs-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) • 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) 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 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) • 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) • eXtensible Markup Language • strukturierte maschinen- und ansatzweise menschenlesbare Informationsbeschreibung • Processing Instruction am Anfang (evtl. mit encoding-Info) • XML-Erinnerung • Datenbanken – ER-Modellierung – Tabellenableitung – SQL – JDBC – Transaktionen • Design-Pattern Observer-Observable • Java Naming and Directory Interface (JNDI) <?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) ); 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) 14 CREATE TABLE Hoert( Matnr INTEGER, Modulnr INTEGER, CONSTRAINT PK_Hoert PRIMARY KEY (MatNr,Modulnr), CONSTRAINT FK_Hoert1 FOREIGN KEY (Matnr) REFERENCES Student(Matnr), CONSTRAINT FK_Hoert2 FOREIGN KEY (Modulnr) REFERENCES Vorlesung(Modulnr) ); INSERT INTO VORLESUNG VALUES(6942,'OOAD',3); INSERT INTO VORLESUNG VALUES(6943,'DB',2); INSERT INTO VORLESUNG 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) ); Komponentenbasierte SoftwareEntwicklung 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[] s) { try { Connection con = DriverManager.getConnection( "jdbc:derby://localhost:1527/Hochschule", "kleuker", "kleuker"); Statement stmt = con.createStatement(); ResultSet rs = stmt.executeQuery("SELECT * FROM Student"); while (rs.next()) { System.out.print(rs.getInt(1) + ": " + rs.getString(2)+" Start:" + rs.getString(3)); } con.close(); } catch (SQLException e) { 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 JNDI (Prinzip) JNDI-Realisierung 2: o=v.lookup("KEY1") „wildes System“ Nutzer Komponentenbasierte SoftwareEntwicklung Prof. Dr. Stephan Kleuker Prof. Dr. Stephan Kleuker 23 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 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>) • 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[] args) { Hashtable env = new Hashtable(); env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.fscontext.RefFSContextFactory"); env.put(Context.PROVIDER_URL, "file:///arbeit/lib"); try { Context context = new InitialContext(env); NamingEnumeration ne = context.listBindings(""); while (ne.hasMore()) { Binding b = (Binding) ne.next(); System.out.println(b.getName() + " :: " + b.getObject()); } context.close(); } catch (NamingException ex) { System.out.println("Frust weil: " + ex.getExplanation()); } fscontext.jar :: D:\arbeit\lib\fscontext.jar } providerutil.jar :: D:\arbeit\lib\providerutil.jar } test :: com.sun.jndi.fscontext.RefFSContext@3a6727 Komponentenbasierte SoftwareEntwicklung public static void main(String[] args) { Hashtable env = new Hashtable(); env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.fscontext.RefFSContextFactory"); env.put(Context.PROVIDER_URL, "file:///arbeit/lib"); try { Context context = new InitialContext(env); Object ob = context.lookup("fscontext.jar"); System.out.println(ob); context.rename("test", "tast"); Object ob2 = context.lookup("tast"); System.out.println(ob2.getClass()); context.rename("tast", "test"); context.close(); } catch (NamingException ex) { System.out.println("Frust weil: " + ex.getExplanation()); } D:\arbeit\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 1. Historie und Ziele der Softwareentwicklung • • • • • • Komponentenbasierte SoftwareEntwicklung Prof. Dr. Stephan Kleuker 30 Entwicklung der Programmierung (1/2) Entwicklung der Programmierung Bedeutung von Abstraktion Domain Specific Languages Model Driven Architecture Komponenten-Ansatz Komponenten-Architekturen • 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 31 Komponentenbasierte SoftwareEntwicklung Prof. Dr. Stephan Kleuker 32 Entwicklung der Programmierung (2/2) Abstraktion • 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 • Entwicklung auf/mit abstrakterer Ebene immer wesentlich schneller als auf unterer Ebene • Jeder Abstraktionsschritt kann Performance kosten Komponentenbasierte SoftwareEntwicklung Komponentenbasierte SoftwareEntwicklung Prof. Dr. Stephan Kleuker 33 Programmiersprache Assembler Maschinensprache Prof. Dr. Stephan Kleuker 34 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 • 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 Prof. Dr. Stephan Kleuker Bibliothek Aktuelle Themen der Softwareentwicklung (1/4) Generelle Ziele der Softwareentwicklung Komponentenbasierte SoftwareEntwicklung Framework 35 Komponentenbasierte SoftwareEntwicklung Prof. Dr. Stephan Kleuker 36 Aktuelle Themen der Softwareentwicklung (2/4) Aktuelle Themen der Softwareentwicklung (3/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 Metamodell Codegenerator Modell 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 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 37 Aktuelle Themen der Softwareentwicklung (4/4) Komponentenbasierte SoftwareEntwicklung Prof. Dr. Stephan Kleuker 38 Komponentenidee genauer (1/2) 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 • 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) • Hinweis: Trotz üblichem Methodenkrieg können Teilideen aller Ansätze integriert werden Komponentenbasierte SoftwareEntwicklung Prof. Dr. Stephan Kleuker 39 Komponentenbasierte SoftwareEntwicklung Prof. Dr. Stephan Kleuker 40 Komponentenidee genauer (2/2) Komponentenframework • Funktionsgarantie – Genannte Dienste werden immer (auch bei neuen Versionen) angeboten – Dienstqualität (Korrektheit, Performance) ist garantiert • 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 • 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 Zentrale Aspekte der Komponentenorientierung Komponentenbasierte SoftwareEntwicklung Prof. Dr. Stephan Kleuker 42 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 43 Komponentenbasierte SoftwareEntwicklung Prof. Dr. Stephan Kleuker 44 Zusammenspiel von Komponenten (1/3) Beispiel: direkt verbundene Komponenten • 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 Zusammenspiel von Komponenten (2/3) Prof. Dr. Stephan Kleuker Prof. Dr. Stephan Kleuker 46 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 • Variante 2: Nutzung einer Kommunikationsplattform mit zentralen Diensten Komponentenbasierte SoftwareEntwicklung Komponentenbasierte SoftwareEntwicklung 47 Komponentenbasierte SoftwareEntwicklung Prof. Dr. Stephan Kleuker 48 Beispiel mit Kommunikationsplattform 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 49 Beispiel: Komponenten in Containern Komponentenbasierte SoftwareEntwicklung Prof. Dr. Stephan Kleuker 50 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 51 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
