Georg Heeg Objektorientierte Systeme Baroper Str. 337 D-44227 Dortmund Germany Tel: +49-231-97599-0 Fax: +49-231-97599-20 Georg Heeg Objektorientierte Systeme Mühlenstr. 19 D-06366 Köthen Germany Tel: +49-3496-214 328 Fax: +49-3496-214 712 Georg Heeg AG Objektorientierte Systeme Riedtlistr. 8 CH-8006 Zürich Switzerland Tel: +41-1-356 3311 Fax: +41-1-356 3312 Email: info@heeg.de http://www.heeg.de

Georg Heeg (Georg Heeg - Objektorientierte Systeme) Geschwindigkeit ist keine Hexerei - Anpassung und Weiterentwicklung von Java- und Smalltalk-Servern Georg Heeg (Georg Heeg - Objektorientierte Systeme) Erfurt, 10. Oktober 2000

Inhalt Georg Heeg – das Unternehmen Software-Trend: Java Software-Krise: Softwarekosten Objektorientiertes Programmieren Software-Krise: Änderungskosten Evolutionäre Software Weiterentwicklung von Internetservern

Anspruchsvolle Projekte unserer Kunden Wir über uns... gegründet 1987 mit Hauptsitz in Dortmund, seit 1996 in Zürich, seit 1999 in Köthen/Anhalt Beratungs- und Schulungsunternehmen mit dem Schwerpunkt Smalltalk Hotline Support, Wartung, Bug-Fixes Entwicklung virtueller Maschinen für VisualWorks Technologie- und Vertriebspartner von Anspruchsvolle Projekte unserer Kunden zum Erfolg führen!

Georg Heeg in Köthen Seit 1999 in Köthen Qualifizierte Informatiker in Sachsen-Anhalt Aktuelle Spezialität Portierung von VisualWorks-Anwendungen nach 5i Verbesserung der Code-Qualität der portierten Anwendungen Kunden in Frankfurt am Main Zürich Kalifornien ...

Trend Low-Tech Projektanforderungen Dampfradio Transistor-Radio Welche Röhre? Transistor-Radio Wieviele Transistoren? Hifi-Radio Tunertechnik (PLL), Ausstattung Heute Aussehen, Preis, Bedienbarkeit, (Digital-Radio)

Projekte Die Sicht von außen zählt! Externe Sicht: Interne Sicht: Fachfunktionalität Integration, Interoperabilität Distribution, Wartung Interne Sicht: Programmiersprache Verwendete Standards Werkzeuge

Java wird nicht als Technologie wahrgenommen Phänomen Java Java wird nicht als Technologie wahrgenommen „Die Technologie spielt heute keine Rolle mehr. Hauptsache es ist Java“

Phänomen Java Java beeinflusst Projekte: Anforderungen, Entscheidung, Erwartungen Die Möglichkeiten von Java bestimmen die Anforderungen an Projekte

Java Technologie JTS, JDK 1.1.8, Java Servlet, JMS, JRE 1.2.2, Java Media Framework, JDBC, Java IDL, JTA, JDK 1.2.2, BDK, Java 2D, RMI-IIOP, JMAPI, Java Mail, JRE 1.1.8, JDNI, Java Server Pages, EJB, Java Help, COMM, Java Beans, Swing, RMI, JDK 1.0.2, Hot Spot, JMX, JCE, Info Bus, JSSE, JFC, Java 3D, JAF, JAAS, Jini Technologien einschl. Standard Extension und Enterprise

Java Technologie Welche Teile der Java Technologie sind sinnvollerweise Teil der externen Sicht eines Projekts? Alle Technologien, die folgende externe Qualitäten eines Projekts beeinflussen: Integration, Interoperabilität Distribution, Wartung

Java Technologie Durch Java bestimmte Projektanforderungen 1. Web-Server Anwendungen (Servlets) 2. Einfache Distribution (JAR) 3. Läuft im Web-Browser 4. Write once, run everywhere 5. Interoperabilität 6. Datenbankanbindung (JDBC) 7. Verteilte Architekturen (RMI, RMI-IIOP, Corba) 8. Application Server (EJB)

Wenn Java so dominant ist, warum dann Smalltalk?

Gründe für Smalltalk Projekte mit offenen oder unklaren Konzepten Bedarf an Prototypen Unvollständige Spezifikation und Modellierung „Moving Targets“ i-Business-Strategien Flexibilität und Geschwindigkeit trennen den Erfolg vom Scheitern

Schnelle Entwicklungszeiten Smalltalk ist das beste System für objektorientierte Modellierung Erfahrungsgemäß ist es bis zu 20 Mal schneller, in Smalltalk zu entwickeln und anzupassen als in Java oder C++ This is a reiteration of the informationvia messages.

Das Smalltalk Phänomen Endbenutzer sagen: „Diese Software leistet exakt das, was ich mir schon immer gewünscht habe.” Beispiel (neben vielen anderen) Wahlberichterstattung von Infratest Dimap Jede Wahl ein neues Projekt Vorlaufzeit manchmal nur 10 Tage (Computerwoche 40/99, S. 71-72)

Cincom Smalltalk

1. Web-Anwendungen VisualWave Ausgereifter Web-Anwendungsserver Lastverteilung Automatische HTML Generierung Sessionverwaltung WikiWorks kostenfreier offener Web-Server mit Editiermöglichkeiten für alle

2. Einfache Distribution (JAR) Parcels leisten dieselben Dienste Transportieren Klassen, Methoden, statische Variablen Abhängigkeiten zwischen Parcels Automatisches Laden fehlender Parcels Versionierung Parcels leisten mehr JAR Pre- und Post-Aktionen beim Laden Dynamisches Laden und Entladen zu jeder Zeit mit/ohne Source

3. Läuft im Web-Browser VisualWorks PlugIn Web-Server HTML-Seite liefert Web-Server HTML-Seite Parcel zeigt an lädt Plugin VM Plugin-Image

3. Läuft im Web-Browser <EMBED NAME="VisualWorks Calculator" SRC="Calculator.pcl" WIDTH="233" HEIGHT="245" ALIGN="BOTTOM" TYPE="application/x-visualworks-parcel" VWOPEN="CalculatorExample" PLUGINSPAGE="vwplugin-install.html">

4. Write once, run everywhere Binäre Kompatibilität seit 1982 (ST80) Abstraktion von Plattform-Eigenarten Dateisystem Betriebssystemaufrufe Benutzeroberfläche Auswechselbares Look&Feel seit VisualWorks 1.0 (1991)

4. Write once, run everywhere VisualWorks 5i.1 VMs gibt es für Win 95/98/NT/2000 Apple Macintosh Solaris HP-UX AIX Tru64 UNIX SGI Linux 86

5. Interoperabilität/Integration DLL&C-Connect für alle Plattformen Voraussetzung für COMConnect Verwendet in DatabaseConnect COMConnect für Windows-Plattformen COM Clients COM Server z.B. SAP-Connect, RoseLink XML-Unterstützung Hilfe-System, Sourcecode

6. Datenbankanbindungen(JDBC) Anbindungen für Oracle Sybase SQL Server ODBC Postgres/SQL Gemstone/S Low-Level-Schnittstellen wie JDBC High-Level Objekt-Relationen-Mapper

7. Verteilte Architekturen DST (Distributed Smalltalk) Erster Corba ORB (Entwickelt von HP)

8. Application Server (EJB) Opentalk derzeit in beta Frameworks für verschiedene Protokolle Gemstone/S  EJB mit Persistenz

VisualWorks 5i Neu in VisualWorks 5i Name-Spaces StORE XML Microsoft SQL-Server Erweiterte Parcels

Die Softwarekrise (10.10.1968) Die Kosten für Software übersteigen den geplanten Wert um ein Vielfaches sofern die Software überhaupt fertiggestellt wird. Termine können nur selten eingehalten werden. Die Änderung existierender Programme ist zeitraubend und kostspielig.

Bewältigung der Software-Krise Objektorientierte Programmierung 4., 5. Generation-Sprachen 4GL, 5GL CASE Strukturierte Programmierung Normierte Programmierung Unterprogramme Prozeduren

1. Imperative Softwarewelt Computerorientiert: Von-Neumann-Computer: Rechenwerk + Speicher => Prozedur + Datenstruktur Die meisten Programmiersprachen haben: Anweisungen + Deklarationen Analysemethoden beschreiben: Informationen + Funktionen

2. Funktionale und logische Softwarewelt Mathematikorientiert Deklarative Programmiersprachen: Funktionales Programmieren: Lisp, Miranda Logisches Programmieren: Prolog Mengenorientiertes Programmieren: SETL Keine Darstellung für Zeit, Dynamik wird durch Tricks realisiert.

3. Objektorientierte Softwarewelt Wer ist verantwortlich? Orientiert an den Begriffen der Anwendungsdisziplin Begriffe werden direkt in Software abgebildet „Modellieren statt Programmieren“

Modellieren in der guten alten Zeit Patient Formular 1:1 Zahnarzt Phänomene Modell Akte Person

Traditionelle Software-Analyse Zustände Datenstrukturen Prozesse Prozeduren “link“ Phänomene Modell ausführbares Programm Person

Objektorientiertes Modellieren Begriff Klasse 1:1 Gesichtspunkt des Fach-gebiets Erkennen, Definieren Instanz Phänomen Modell Objekt „Die Welt“

Objektorientiertes Modellieren Der Gesichtspunkt bestimmt das Modell „Das korrekte Modell” existiert nicht! Für eine Anwendung gibt es nur angemessene Modelle und nicht angemessene Modelle

Was ist das? Ein zylindrischer Körper aus Holz mit etwa 20 cm Länge und 6 mm Durchmesser. Im Zentrum des Zylinders ist eine Bohrung von 1 mm, die mit gepresstem Grafit gefüllt ist. An einem Ende ist der Zylinder kegelförmig verjüngt. Das Grafit kann auf andere Körper abgerieben werden.

Was ist das? Ein zylindrisches Plastikrohr mit etwa 20 cm Länge und 6 mm Durchmesser. Im Inneren ist ein weiteres Plastikrohr mit 2 mm Durchmesser and einer Metallkugel an einem Ende. Das innere Rohr ist mit viskoser Farbe gefüllt. Die Farbe kann über die Kugel auf andere Medien übertragen werden.

Was ist für Johannes wichtig?

Was ist für Johannes wichtig? MALEN

Über Bleistifte und Kugelschreiber Der objektorientierte (und Johannes) Gesichtspunkt: Bleistift = etwas zum Schreiben und Malen Kugelschreiber = etwas zum Schreiben und Malen

Klassenhierarchie Pen draw Pencil draw BallPen draw

Johannes (Smalltalk) Boy hand (Instanzvariable) Irgendwo in der Klasse Boy steht: hand := Mommy givePen. ... hand draw

Johannes (Java) Boy private pen hand; (Instanzvariable) Irgendwo in der Klasse Boy steht: hand = Mommy.givePen(); ... hand.draw()

Die Softwarekrise (heute) 60 % bis 80 % der Softwarekosten sind Änderungskosten

Änderungskosten (konventionell) Preis(Änderung) = Änderungsfaktor * Größe(Änderung) + Projektfaktor * Größe(Projekt) In den meisten Software-Lebenszyklen gilt: Projektfaktor >> 0 Daher dominiert die Projektgröße die Änderungskosten. Die Größe der Änderung spielt fast keine Rolle. Kunden verstehen dies nicht. $ € $ € $ € $ € $ € $ € $ € $ € $ € $ € $ € $ € $ € $ € $ € $ € $ € $ € $ €

Nun entwickeln wir unsere Anwendung weiter

Was ist für Johannes wichtig?

Was ist für Johannes wichtig? ZIEHEN

Über Bollerwagen Der objektorientierte (und Johannes) Gesichtspunkt : Bollerwagen = etwas zum Ziehen (und drin Sitzen)

Klassenhierarchie Vehicle sitIn Wagon pull Car makeNoise Trabi Van lookOut

Johannes (Smalltalk) Boy hand (Instanzvariable) Irgendwo in der Klasse Boy steht: hand := Daddy getWagon. ... hand pull

? ? ? Johannes (Java) Boy private object hand; (Instanzvariable) Irgendwo in der Klasse Boy steht: hand = Daddy.giveWagon(); ... ((Wagon)hand).pull() Nun müssen wir noch das Bleistift-Beispiel anpassen (alle Vorkommen von „hand“ sind zu prüfen): ((Pen)hand).draw() ? ?

Änderungskosten und Java Preis(Änderung) = Änderungsfaktor * Größe(Änderung) + Projektfaktor * Größe(Projekt) In Java gilt: Projektfaktor >> 0 Daher dominiert die Projektgröße die Änderungskosten. Die Größe der Änderung spielt fast keine Rolle. Kunden verstehen dies nicht. $ € $ € $ € $ € $ € $ € $ € $ € $ € $ € $ € $ € $ € $ € $ € $ € $ € $ € $ €

Änderungskosten und Smalltalk Preis(Änderung) = Änderungsfaktor * Größe(Änderung) + Projektfaktor * Größe(Projekt) In Smalltalk gilt: Projektfaktor = 0 Daher bestimmt die Größe der Änderung die Änderungskosten. Das verstehen die Kunden. $ € $ € $ € $ € $ € $ € $ € $ € $ € $ € $ € $ € $ € $ € $ € $ € $ € $ € $ €

Was ist Software? In Java In Smalltalk Software ist ein Programm, das gestartet wird In Smalltalk Software ist ein System, das verändert wird

Weiterentwicklung von Software

Das Smalltalk Phänomen Endbenutzer sagen: „Diese Software leistet exakt das, was ich mir schon immer gewünscht habe.” Beispiel (neben vielen anderen) Wahlberichterstattung von Infratest Dimap Jede Wahl ein neues Projekt Vorlaufzeit manchmal nur 10 Tage (Computerwoche 40/99, S. 71-72)

Zusammenfassung Zufriedene Benutzer Geschwindigkeit ist keine Hexerei Finden angemessener Begrifflichkeit Ständige Weiterentwicklung Erfüllen der Anforderungen Zufriedene Benutzer

Georg Heeg: georg@heeg.de oder in der Mühlenstr. 19, 06366 Köthen Sie erreichen mich Georg Heeg: georg@heeg.de http://www-koethen.heeg.de oder in der Mühlenstr. 19, 06366 Köthen

Diskussion

Georg Heeg Objektorientierte Systeme Baroper Str. 337 D-44227 Dortmund Germany Tel: +49-231-97599-0 Fax: +49-231-97599-20 Georg Heeg Objektorientierte Systeme Mühlenstr. 19 D-06366 Köthen Germany Tel: +49-3496-214 328 Fax: +49-3496-214 712 Georg Heeg AG Objektorientierte Systeme Riedtlistr. 8 CH-8006 Zürich Switzerland Tel: +41-1-356 3311 Fax: +41-1-356 3312 Email: info@heeg.de http://www.heeg.de