Georg Heeg Objektorientierte Systeme Baroper Str. 337 D Dortmund

Präsentation zum Thema: "Georg Heeg Objektorientierte Systeme Baroper Str. 337 D Dortmund"—  Präsentation transkript:

1 Georg Heeg Objektorientierte Systeme Baroper Str. 337 D-44227 Dortmund
Germany Tel: Fax: Georg Heeg Objektorientierte Systeme Mühlenstr. 19 D Köthen Germany Tel: Fax: Georg Heeg AG Objektorientierte Systeme Riedtlistr. 8 CH-8006 Zürich Switzerland Tel: Fax:

2 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

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

4 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!

5 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 ...

6 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)

7 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

8 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“

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

10 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

11 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

12 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)

13 Wenn Java so dominant ist, warum dann Smalltalk?

14 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

15 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.

16 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 )

17 Cincom Smalltalk

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

19 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

20 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

21 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">

22 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)

23 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

24 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

25 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

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

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

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

29 Die Softwarekrise ( ) 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.

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

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

32 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.

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

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

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

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

37 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

38 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.

39 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.

40 Was ist für Johannes wichtig?

41 Was ist für Johannes wichtig?
MALEN

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

43 Klassenhierarchie Pen draw Pencil draw BallPen draw

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

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

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

47 Ä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. $ € $ € $ € $ € $ € $ € $ € $ € $ € $ € $ € $ € $ € $ € $ € $ € $ € $ € $ €

48 Nun entwickeln wir unsere Anwendung weiter

49 Was ist für Johannes wichtig?

50 Was ist für Johannes wichtig?
ZIEHEN

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

52 Klassenhierarchie Vehicle sitIn Wagon pull Car makeNoise Trabi
Van lookOut

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

54 ? ? ? 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() ? ?

55 Ä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. $ € $ € $ € $ € $ € $ € $ € $ € $ € $ € $ € $ € $ € $ € $ € $ € $ € $ € $ €

56 Ä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. $ € $ € $ € $ € $ € $ € $ € $ € $ € $ € $ € $ € $ € $ € $ € $ € $ € $ € $ €

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

58 Weiterentwicklung von Software

59 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 )

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

61 Georg Heeg: georg@heeg.de oder in der Mühlenstr. 19, 06366 Köthen
Sie erreichen mich Georg Heeg: oder in der Mühlenstr. 19, Köthen

62 Diskussion

63 Georg Heeg Objektorientierte Systeme Baroper Str. 337 D-44227 Dortmund
Germany Tel: Fax: Georg Heeg Objektorientierte Systeme Mühlenstr. 19 D Köthen Germany Tel: Fax: Georg Heeg AG Objektorientierte Systeme Riedtlistr. 8 CH-8006 Zürich Switzerland Tel: Fax: