Komponenten-Orientierte Softwareentwicklung mit JavaBeans. Birngruber Dietrich

Komponenten-Orientierte Softwareentwicklung mit JavaBeans Birngruber Dietrich

Inhalt Einführung zum Thema Software Komponenten Komponenten - Wozu? Schlagwörter Geschichtlicher Hintergrund Wiederverwendung Java Komponentenmodell: JavaBeans

Software Komponenten - Wozu? Software Crises (Ende 60er) Ist sie bereits überwunden? Wiederverwendung (Reuse) Qualitätsverbesserung Reduced time to market Objekt-Orientierung hat sich etabliert - Brauchen wir mehr? Software Komponenten sind trendy Alternativen zu Komponenten: GEP, AOP,...

Komponenten - Schlagwörter componentware, software components, component based programming, component oriented programming, Lego for software engineers, reuse, Java, JavaBeans, DCOM, VBX, ActiveX, CORBA, CORBA-Beans...

Abstraktionsmechanismen - Evolution oder Revolution? 40's - 50's Data Registers Control OP Codes 50's - 60's Predefined Types Predefined Operations 60's - 70's User Defined Types User Defined Operations 70's - 80's (Simula 67) 90's -? Classes Components?????

Erhoffte Vorteile durch OOP Wiederverwendung von Code durch Vererbung (inheritance) Flexibilität durch Polymorphismus Modellieren der realen Welt (object identity) Erhöhung der Produktivität und Qualität Und trotzdem: Software Krise nicht überwunden! Warum?

Fragile Base Class Problem beschreibt Probleme durch Vertragsbruch zwischen Unterund Überklasse Unterklasse hält sich an den Vertrag Überklasse wird später geändert und bricht den Vertrag Ersetzbarkeit ist nicht mehr garantiert! syntactic: Modifizieren der Schnittstelle der Überklasse z.b.: Ändern von Methodennamen, Parameterliste,... semantic: Verhalten der Überklasse ändert sich

OOP Problem: Vererbung Inheritance breaks information hiding Schnittstelle zwischen Klienten / Objekt, Klasse ermöglicht Information Hiding A A C B B Schnittstelle zwischen Unterklasse und Superklasse kann Information Hiding verletzten, indem auf Instanzvariable der Superklasse direkt zugegriffen wird C

Beispiel: OO Framework für Editoren OO-Editor-Framework erlaubt schnelle Anpassung :-))) Framework wird für zwei OS bereitgestellt zwei verschiedene Versionen mehr Aufwand für Framework Hersteller Kunde braucht oft nicht ganze Funktionalität Framework kann schwer zerlegt werden einzelnes Objekt kann nicht ausgeliefert werden Kunde will Framework auch in Sprache X weil er auch ein Framework zur Rechtschreibprüfung, geschrieben in der Sprache X, verwendet Integration

Beispiel: Framework (2) Lösungen Auslieferung von Quellcode? um Framework in Anwendungen verwenden zu können Framework Code in jeder Anwendung (Speicherverschwendung) Preisgabe von Know How Application A Editor V1.0 Application B Editor V1.0 neue Framework Version betrifft viele Anwendungen jede Anwendung muss neu übersetzt werden...

Erwartete Vorteile durch COP Qualitätssteigerung Komponenten werden mehrmals wiederverwendet und Fehler werden sukzessiv beseitigt Senkung der Herstellungskosten Kürze Software-Entwicklungszeit indem, komplexe Komponenten wiederverwendet werden. Wurde das nicht schon mit OOP versprochen?

Lösungsansätze Plattformunabhängigkeit keine teueren parallelen Entwicklungen für jedes OS extra Sprachunabhängigkeit verwenden von Komponenten, programmiert in verschiedenen Sprachen Komponenten als unabhängige Einheiten Ausliefern von dem, was wirklich benötigt wird Markt für verschiedene Implementierungen

Lösungsansätze Zugriff nur über Schnittstelle kein teilweises Information Hiding, sondern vollständiges! blackbox reuse kein Auslieferen von Quellcode - sondern binäres Format kein Fragile Base Class Problem Dynamisches Laden von Komponenten weniger Speicherverschwendung Verhalten kann zur Laufzeit verändert werden... Viele dieser Lösungsansätze auch mit OO möglich!!!

Wiederverwendung (reuse) whitebox reuse Schnittstelle gegeben, aber voller Zugriff auf die Implementierung Anwender muß fremden Code verstehen und lernen Entwickler gibt sein Know How preis z.b.: durch implementation inheritance Gewünscht: blackbox reuse Zugriff nur über wohl definierte Schnittstelle Design by Contract Anwender braucht gute Dokumentation - muß aber Code nicht lernen Möglichkeit von try and buy z.b.: Application Programming Interface (API)

Wiederverwendung Objekt - Orientiert: Whitebox Reuse durch Vererbung Anwender braucht gute Dokumentation und muß fremden Code verstehen Entwickler gibt sein Know How preis Komponenten - Orientiert Blackbox Reuse durch Assoziation, Aggregation Anwender braucht gute Dokumentation Zugriff nur über Schnittstellen, Design by Contract Möglichkeit von Try & Buy

JavaBeans Grundlagen

Ziele Verstehen der grundlegenden JavaBean Technologie Wissen, wie man eine JavaBean baut Wissen, wie man eine JavaBean verwendet Spaß an der Arbeit Als Anfänger beginnen und als Bean... als ein JavaBean Experte enden

JavaBeans - Grundlagen JavaBeans Einführung und Definition Events über den grundlegenden Kommunikationsmechanismus Properties über virtuelle Variable Serialization über Zustand und Persistenz Packaging über das Verpacken von JavaBeans

JavaBeans Einführung Einfache Konzepte Einfache Programmierschnittstelle Plattformneutrales Komponentenmodel Verbindungen zu anderen Komponenten- und Verteilungsmodellen wie DCOM oder CORBA In plattformabhängigen Behältern (containern) einbettbar z.b.: MS Excel, Word etc.

JavaBeans Definition A Java Bean is a reusable software component that can be manipulated visually in a builder tool (JavaBeans Spezification)

JavaBeans Definition Beispiele: GUI widgets, Spreadsheet, HTML-Browser Keine genaue Angabe darüber, was eine "software component" ist. Die Granularität von JavaBeans reicht von einer Klasse bis zur ganzen Applikation. Die meisten sind jedoch "middle grained" - was immer das heißen mag! Eine oder mehrere Klassen realisieren eine Komponente Eine oder mehrere Komponenten realisieren eine komplexere Komponente oder eine Applikation

JavaBeans Definition Explizite Unterstützung von visueller Programmierung Design Time versus Run Time Visible versus Unvisible Beans Erforderliche Features oder Eigenschaften: properties events methods persistence customization introspection

JavaBeans Definition Beans wurden für ein lokales Laufzeitmodell im gleichem Adreßraum konzeptioniert. Beans können jedoch über verschiedene Mechanismen auf entfernte Ressourcen zugreifen. Wozu noch Klassenbibliotheken?

Beispiel einer Montageumgebung: VisualAge

Ereignisse (Events) Allgemeiner Kommunikationsmechanismus Erlaubt loosley coupled communication Beans werden über Ereignisse zusammengesteckt Idee von Ereignissen: Die Änderung eines Zustandes soll allen, die sich dafür interessieren, mitgeteilt werden. Ziele: Ein allgemeines Rahmenwerk, das erweitert werden kann und für verschiedene Anwendungsdomänen geeignet ist Ereignisse müssen auch in anderen Programmierumgebungen (v.a. scripting environments) behandelt werden können Unterstützung durch Werkzeuge

Event Delegation Mechanismus Technische Realisierung in Java (seit JDK 1.1) mit drei Beteiligten: Quelle (event source) Auslöser der Ereignisse (WO ist etwas passiert?) Sie benachrichtigt alle, die sich dafür interessieren Interessierter mit Ereignis Definition (event listener) reagiert auf Ereignisse (WAS ist passiert?) wird bei der Quelle registriert und deregistriert Ereignis Objekt (event) ist Information über Zustandsänderung

Zusammenspiel zwischen Quelle, Interessierter und Ereignis Objekt X Event Source 1 void addfoolistener (FooListener l) Referenz auf Interface l 2 FooListener (Interface) void foobarhappened (FooEvent e1) Status geändert! - Erzeuge FooEvent e1 - Ereignis "foobarhappened" auslösen Objekt X 3 void removefoolistener (FooListener l)

Bean Design Pattern für Ereignis Objekte (Events) erweitern java.util.eventobject Klassenname endet mit Event z.b.: FooEvent, MouseEvent etc. Instanzvariable sind immutabel d.h. nicht veränderbar Der Zugriff auf Instanzvariable erfolgt nur über öffentliche Zugriffsmethoden Die Zugriffsmethoden unterliegen den Design-Pattern für Properties Ereignis Beispiel: public class AlarmEvent extends java.util.eventobject { private long t; public AlarmEvent(Object source, long ms) {super(source);t=ms;} public long gettime() {return t;} }

Beispiel - SimpleAlarmBean Beschreibung Alle x Millisekunden wird ein Alarm ausgelöst Sehr einfaches Bean: AlarmEvent Enthält die Entstehungszeit des Alarms in Millisekunden. AlarmEventListener Behandelt Ereignis alarmoccured SimpleTimerBean Event Source löst alle x Millisekunden den Alarm aus und benachrichtigt die registrierten AlarmEventListner

Beispiel - SimpleAlarmBean AlarmEvent & AlarmListener public class AlarmEvent extends java.util.eventobject { private long time; public AlarmEvent(Object source, long ms) { super(source); time=ms; } } public long gettime() {return time;} /* ---------------------------------------------------- */ public interface AlarmListener extends java.util.eventlistener { // alarmoccured event void alarmoccured(alarmevent ev); }

Beispiel - SimpleAlarmBean (1) (Ereignisquelle) public class SimpleAlarmBean implements Runnable { Thread t; static final int WAIT_MS = 10000; //alarm occures all 10 sec. Vector listeners; //registered listeners //default constructor public SimpleTimerBean() { listeners = new java.util.vector(); t = new java.lang.thread (this); t.start(); } //registration and deregistration of the listeners public synchronized void addalarmlistener(alarmlistener l) { this.listeners.addelement(l); } public synchronized void removealarmlistener(alarmlistener l) { this.listeners.removeelement(l); } //...

Beispiel - SimpleAlarmBean (2) //... protected void firealarmevent() { if (listeners == null) return; Vector targets=(vector)listeners.clone(); AlarmEvent ev=new AlarmEvent(this,System.currentTimeMillis()); for (int i =0; i < targets.size(); i++) { AlarmListener target=(alarmlistener)targets.elementat(i); target.alarmoccured(ev); } } public void run() { while (t!= null ) { try { t.sleep(wait_ms); firealarmevent(); } catch (Exception ex) { ex.printstacktrace(); } } } } //end of class SimpleAlarmBean

Eigenschaften (Properties) Properties oder Eigenschaften sind diskrete, benannte Attribute eines JavaBeans, welche das Aussehen oder das Verhalten eines Beans verändern können. Beispiel: label Property eines GUI Knopfes, welches die Beschriftung darstellt Auf Properties wird immer über Methoden zugegriffen Meistens werden Properties auch gespeichert Properties können zur Run Time und zur Design Time gesetzt werden

Simple Properties Bean Design Pattern Grundlegende Signatur von read / write Properties: public void set<name> ( <Type> value ); //simple setter public <Type> get<name> (); //simple getter z.b.: Simple Property label vom Typ String public void setlabel (String alabel); //simple setter public String getlabel (); //simple getter

Serialization (1) Mechanismus zum Speichern (=Serialisieren) und zum Laden (=Deserialisieren) von Java Objekten Es werden Typinformation und Zustand eines Objektes auf einen beliebigen Ausgabestrom gespeichert API ist zu finden im Package java.io Serialisierbare Klassen implementieren java.io.serializable Unabhängig welcher Serialisierungsmechanismus benutzt wird java.io.serializable enthält keine Methoden Ist nur Typ zum Erkennen ja ich möchte serialisiert werden

Serialization (2) Gespeichert werden nur Instanzvariable Nicht gespeichert werden: transient und Klassenvaraible (static) Ganzer Objektgraph wird gespeichert Wichtige Stream Klassen zum Serialisieren von Objekten java.io.objectinputstream java.io.objectoutputstream Fast alle Klassen des JDK implementieren Serializable Ausnahmen: java.lang.object, java.lang.thread, etc.

Packaging Problem: Ein JavaBean besteht in der Regel aus vielen Dateien Lösung: archivieren als JAR - Java Archive Anwendungsszenario Bean Entwickler packt die notwendigen Dateien in ein JAR Kunde kauft JAR (übers Netz) und importiert es in sein Builder Tool Builder Tool erkennt automatisch alle Beans und ändert die Palette Kunde verwendet die neuen Beans in seinem Builder Tool JAR Tool ist im JDK enthalten Beispiel: Zwei Dateien werden in das Archiv classes.jar gepackt jar cvfm Beans.jar manifest.mf Foo.class B.class

Inhalt eines JAR.class Dateien: Beans, Unterstützende Klassen etc..html Dateien: Dokumentation.avi,.au etc: sonstige Ressourcen, Videos, Bilder etc. Manifest.mf Datei Beschreibt welche Klassen ein Bean ist und welche nicht Beispiel: Manifest-Version: 1.0 Name: com/ibm/led/ledclock.class Java-Bean: True Digest-Algorithms: SHA MD5 SHA-Digest: XspvM2DfvGR7uap4+U7mpgY0p/o= MD5-Digest: jlabnolaisrcy9vba80a0w== Name: com/ibm/led/alarmevent.class Digest-Algorithms: SHA MD5

JavaBeans - Grundlagen FRAGEN? Wir sehen uns im WS00/01