diff options
| author | Jens-Heiner Rechtien <hr@openoffice.org> | 2000-09-18 16:07:07 +0000 |
|---|---|---|
| committer | Jens-Heiner Rechtien <hr@openoffice.org> | 2000-09-18 16:07:07 +0000 |
| commit | f5b2b8667807673ee6e999f13ba7477efab32aa1 (patch) | |
| tree | e7db8e756f4fd005bddcb9b694991cce5e37dc33 /sj2/doc | |
| parent | 9b5f06483e07c3254475f84080995290e30e9242 (diff) | |
initial import
Diffstat (limited to 'sj2/doc')
| -rw-r--r-- | sj2/doc/Todo.txt | 108 | ||||
| -rw-r--r-- | sj2/doc/concepts.html | 844 |
2 files changed, 952 insertions, 0 deletions
diff --git a/sj2/doc/Todo.txt b/sj2/doc/Todo.txt new file mode 100644 index 0000000000..6520abaa10 --- /dev/null +++ b/sj2/doc/Todo.txt @@ -0,0 +1,108 @@ +Erkenntnisse aus sj/sj1, die in sj2 beachtet werden müssen + + +- Call von C++ +"javascript: ..." nicht wie event behandeln, insbesondere werden +this und document nicht implizit als Search-Objekte gesetzt. + + +- prototype Eigenschaft von Objekten: +Manipuliert Klassen-Informationen, falls an einem beliebigen Objekt +eine Property mit gleichem Namen angelegt wird, so gilt dieses +Ueberschreiben jedoch nur fuer dieses eine Objekt !!! +Im Sj/Sj1 Projekt ist dies jedoch nicht erfuellt ! + +Beispiel: +function Ctor() { ... } + +obj1 = new Ctor(); // obj1 obj2 +obj2 = new Ctor(); //------------------------- +Ctor.prototype.toString = myToString; // myToString myToString +obj1.toString = myToString2; // myToString2 myToString +Ctor.prototype.toString = myToString3; // myToString2 myToString3 + + +- toString() und valueOf() Behandlung des BaseObj bei Type-Konversion + +======================================================================== + +Bemerkungen zur Suchreihenfolge und zum Ueberladen von Funktionen: + +* fuer jede 'Klasse' (z.B. Math, Date, String) gibt es ein Konstruktor- + Objekt in der JavaScript-Umgebung. + In dem Konstruktor-Objekt werden die Properties der Klasse angelegt, + z.B. sin, cos. + Der Konstruktor setzt seine Properties an jedem neu erzeugten + Objekt. Daher hat z.B. jedes Date-Objekt eine (default-behandelte) + Property setMonth. + Zum Setzten der Properties des Konstruktor an das neu erzeugte + Objekt sollte die initProp()-Methode noch einen Bereich der zu + kopierenden Properties bekommen, damit nicht alle nachtraeglich + am Konstruktor-Objekt angelegten Properties auch am Objekt gesetzt + werden. + +* jedes Objekt haelt eine Referenz auf seinen Konstruktor (entweder die + vordefinierten Klassen wie Math, Date oder die Funktion mit der das + Objekt erzeugt wurde). + +* fuer die Suchreihenfolge gibt es folgende drei Moeglichkeiten: + + - Default-behandelte Property: + aStrg = new String( "gulp" ); + aStrg.toString() // --> verwendet toString-Property am + // String-Konstruktor (default-Behandlung) + + - Default-Behandlung ueberladen am Konstruktor: + aStrg = new String( "gulp" ); + String.prototype.toString = myToString; // UEBERLADEN ! + aStrg.toString() // --> verwendet myToString-Funktion. + // Das prototype-Objekt wird am String-Ctor. + // angelegt und ueberschreibt daher die + // default-behandelte Property am Objekt !!! + // Der Interpreter muss dann noch an einem + // ggf. vorhandenen prototype-Objekt am + // Konstruktor nach der Property suchen. + + - ueberladen am Objekt: + aStrg = new String( "gulp" ); + String.prototype.toString = myToString; // am Ctor. ueberladen + aStrg.toString = myToString2; + aStrg.toString() // --> verwendet myToString2-Funktion. + // Die Property toString wird am Objekt + // ueberschrieben und somit das Flag, dass + // die default-Behandlung anzeigt, zurueck + // gesetzt. D.h. der Interpreter muss das + // prototype-Objekt des Konstruktors NICHT + // durchsuchen. + + +======================================================================== + +DEMNAECHST: + +Die Properties der Standard-Objekte (z.B. setSeconds() am Date) +werden am prototype-Objekt des Konstruktors (z.B. DateCtor) angelegt. +Bei der Suche nach Properties an einem beliebigen Objekt wird erst +das Objekt durchsucht und anschliessend das prototype-Objekt des +Konstruktors fuer das Objekt durchsucht. Dieses Verhalten gleicht +dem Netscape-Verhalten (Stand 2.7.1997). + +ACHTUNG, AB 11.8: +Das ist so nicht korrekt, da die entsprechenden Properties direkt +am prototype-Objekt nicht bekannt sind. Die an den Objekten als +Default geflagten Properties bilden daher das Netscape-Verhalten +besser ab. + + +======================================================================== + +WEITERE OFFENE PROBLEME: +------------------------ + + * this auf der Wiese funktioniert noch nicht korrekt + + * Konversion von Typen ? + + + + diff --git a/sj2/doc/concepts.html b/sj2/doc/concepts.html new file mode 100644 index 0000000000..49f336b131 --- /dev/null +++ b/sj2/doc/concepts.html @@ -0,0 +1,844 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> +<HEAD> + <TITLE></TITLE> + <META NAME="GENERATOR" CONTENT="StarOffice/4.0 (WinNT/Win95)"> + <META NAME="AUTHOR" CONTENT=" "> + <META NAME="CREATED" CONTENT="19970401;13233926"> + <META NAME="CHANGEDBY" CONTENT=" "> + <META NAME="CHANGED" CONTENT="19970529;8045806"> +</HEAD> +<BODY> +<H1>Stardivision erweiterte Java Grundkonzepte</H1> +<H2><A NAME="Exceptions"></A>Exceptions:</H2> +<P>Die Grundidee von Exceptions ist es einen Fehlerkontext +aufzuspannen, der erst näher betrachtet werden muß, wenn +man Fehler korrigieren will. Der Programmcode sollte durch die +Behandlung von Fehlern nicht undurchsichtig und unleserlich werden. +Meiner Meinung nach sollten Exceptions deswegen auch nicht als +zweiter Returnwert vergewaltigt werden.<BR><B>Ziel:</B> Nach dem +Auftreten einer Exception sollte es möglichst einfach sein das +System in einen definierten arbeitsfähigen Zustand zu +versetzen.<BR>Es gibt grundsätzlich drei verschiedenen Arten von +Exceptions. Diese unterscheiden sich durch den Zustand in dem sie das +Objekt hinterlassen.</P> +<OL> + <LI><P><A NAME="Undefined Exception"></A>Die von der Methode + benutzten Objekte sind in einem undefinierten Zustand. Jede auf dem + Objekt aufgerufene Methode muß nach einer solchen Exception + nicht mehr ihre Spezifikation einhalten. Diese Exception wird im + folgenden mit „Undefined Exception“ benannt. Dabei ist zu + beachten, daß keine weiteren <A HREF="#Resourcen">Resourcen</A>, + außer die angegebenen, benutzt werden. Außerdem werden + „ReadOnly“ Resourcen nicht modifiziert.</P> + <LI><P><A NAME="Defined Exception"></A>Die von der Methode benutzten + Objekte sind in einem genau definierten Zustand, der aber von der + Zusicherung der Methode abweicht. Diese Exception wird im folgenden + mit „Defined Exception“ benannt. Dabei ist zu beachten, + daß keine weiteren <A HREF="#Resourcen">Resourcen</A>, außer + die angegebenen, benutzt werden. Außerdem werden „ReadOnly“ + Resourcen nicht modifiziert.</P> + <LI><P><A NAME="Transacted Exception"></A>Die von der Methode + benutzten Objekte sind in ihrem vorherigen Zustand, der aber von der + Zusicherung der Methode abweicht. Diese Exception wird im folgenden + mit „Transacted Exception“ benannt. Dabei ist zu beachten, + daß keine weiteren <A HREF="#Resourcen">Resourcen</A>, außer + die angegebenen, benutzt werden. Außerdem werden „ReadOnly“ + Resourcen nicht modifiziert. Diese Spezifikation trifft auch auf + „Defined Exception“ zu, wegen ihrer Bedeutung führe + ich sie extra auf.</P> +</OL> +<P>Die Benutzbarkeit eines Objektes, nachdem eine Exception +aufgetreten ist, ist vom obigen Typ der Exception abhängig.</P> +<P><FONT COLOR="#ff0000">Satz 1.1: Nachdem eine „Undefined +Exception“ aufgetreten ist, kann mit dem Objekt sowie allen +„ReadWrite“ Resourcen nicht mehr weiter gearbeitet werden.</FONT></P> +<P><FONT COLOR="#ff0000">Satz 1.2: Nachdem eine „Defined +Exception“ aufgetreten ist, kann aufgrund des genau definierten +Zustandes weiter gearbeitet werden.</FONT></P> +<P><FONT COLOR="#ff0000">Satz 1.3: Nach einer „Transacted +Exception“ ist der gleiche Zustand wie vor dem Aufruf +wiederhergestellt.</FONT></P> +<P>Es sollten möglichst nur „Transacted Exception“ +ausgelöst werden. Bei komplizierten Methoden läßt +sich aber eine „Defined Exception“ nicht immer vermeiden. +Eine „Undefined Exception“ deutet immer auf eine +Programmierfehler hin. Der Typ der Exeption kann nur in Zusammenhang +mit der Methode in der sie Auftritt ermittelt werden.</P> +<P><FONT COLOR="#ff0000">Satz 1.4: Durch die Klasse der Exception +kann niemals alleine der Typ (undefined, defined oder transacted) +entschieden werden.</FONT></P> +<H2><A NAME="Resourcen"></A>Resourcen (under construction)</H2> +<P>Die Grundidee von Resourcen ist die Aufteilung eines Gebildes in +weitere Einheiten. Auf diesen können dann verschiedene Aufträge +gleichzeitig arbeiten, wenn sie nicht dieselben Resourcen benutzen. +Z.B. kann man in einer Textverarbeitung die einzelnen Dokumente als +Einheiten betrachten. Aufträge, die sich nur auf ein Dokument +beziehen, können parallel zu anderen Dokumenten bearbeitet +werden.<BR>Mit Resourcen sind im System bzw. der Applikation +vorhandene Objekte, Services, Kanäle ... gemeint, die zur Zeit +nur von einem Thread benutzt werden können. Als Konsequenz +müssen Resourcen einem Thread zugeordnet werden, bevor dieser +sie benutzt.<BR><B>Ziel:</B> Es muß möglich sein, 1. +Aufträge parallel abzuarbeiten, 2. die Frage „Warum können +zwei Aufträge nicht parallel arbeiten?“ beantwortet zu +können.<BR>Es gibt verschiedene Möglichkeiten diese +Zuordnung vorzunehmen. Zwei stelle ich kurz vor.</P> +<OL> + <LI><P><A NAME="Prealloc Resource Konzept"></A>Eine Art der + Zuordnung ist das vorherige Anfordern aller für den Auftrag + benötigten Resourcen. Ist dies möglich, kann der Auftrag + ohne weitere Störungen ablaufen. Die Resourcen dürfen + freigegeben werden, bevor der Auftrag beendet ist. Dies gilt + natürlich nur für nicht mehr verwendete Resourcen. Es darf + ebenfalls das Zuordnungsrecht von lesend und schreibend auf lesend + zurückgenommen werden. Diese Zuornungsart wird im weiteren mit + „Prealloc Resource Konzept“ bezeichnet.</P> + <LI><P><A NAME="Ondemand Resource Konzept"></A>Eine andere Art der + Zuordnung ist das Anfordern der Resourcen, wenn sie benötigt + werden. Dabei kann es zu Störungen kommen, wenn sich + verschiedene Aufträge um die gleiche Resource bewerben. Die + Resourcen dürfen freigegeben werden, bevor der Auftrag beendet + ist. Dies gilt natürlich nur für nicht mehr verwendete + Resourcen. Es darf ebenfalls das Zuordnungsrecht von lesend und + schreibend auf lesend zurückgenommen werden. Diese Zuornungsart + wird im weiteren mit „Ondemand Resource Konzept“ + bezeichnet.</P> +</OL> +<P>Es gibt noch weitere Möglichkeiten Aufträge zu +bearbeiten, die die gleichen Resourcen benutzen. Häufig findet +man solche Lösungen bei Datenbankanwendungen.<BR>In der +folgenden Tabelle stehen sich die beiden Konzepte mit ihren Vor- und +Nachteilen und ihren Anforderungen gegenüber.</P> +<TABLE WIDTH=100% BORDER=1 CELLPADDING=5 FRAME=BOX RULES=ALL> + <COLGROUP> + <COL WIDTH=85*> + <COL WIDTH=85*> + <COL WIDTH=85*> + </COLGROUP> + <THEAD> + <TR> + <TH WIDTH=33% VALIGN=TOP> + <P><BR></TH> + <TD WIDTH=33% VALIGN=TOP><DL> + <DD>Prealloc Resource Konzept </DD> + </DL> + </TD> + <TD WIDTH=33% VALIGN=TOP> + <DL> + <DD>Ondemand Resource Konzept </DD> + </DL> + </TD> + </TR> + </THEAD> + <TBODY> + <TR> + <TD VALIGN=TOP> + <P>Alle Resourcen müssen vor der Auftragsausführung + bekannt sein.</TD> + <TD VALIGN=TOP> + <P>Ja</TD> + <TD VALIGN=TOP> + <P>Nein</TD> + </TR> + <TR> + <TD VALIGN=TOP> + <P>Nicht mehr benötigte Resourcen dürfen freigegeben + werden.</TD> + <TD VALIGN=TOP> + <P>Ja</TD> + <TD VALIGN=TOP> + <P>Ja</TD> + </TR> + <TR> + <TD VALIGN=TOP> + <P>Es kann zu Verklemmungen oder „Races“ kommen.</TD> + <TD VALIGN=TOP> + <P>Nein</TD> + <TD VALIGN=TOP> + <P>Ja</TD> + </TR> + <TR> + <TD VALIGN=TOP> + <P>In Bearbeitung befindliche Aufträge müssen, aufgrund + fehlender Resourcen, abgebrochen werden.</TD> + <TD VALIGN=TOP> + <P>Nein</TD> + <TD VALIGN=TOP> + <P>Ja</TD> + </TR> + <TR> + <TD VALIGN=TOP> + <P>Der Zustand der Resourcen ist zu jedem Zeitpunkt der + Auftragsabarbeitung bekannt.</TD> + <TD VALIGN=TOP> + <P>Ja</TD> + <TD VALIGN=TOP> + <P>Nein</TD> + </TR> + <TR> + <TD VALIGN=TOP> + <P>Algorithmus zur Resourcevergabe.</TD> + <TD VALIGN=TOP> + <P>Einfach, da nur überprüft werden muß, ob alle + benötigten Resourcen verfügbar sind.</TD> + <TD VALIGN=TOP> + <P>Komplex, da neben dem Anfordern von Resourcen auch noch + überprüft werden muß, ob das System <A HREF="#lebendig">lebendig</A> + ist.</TD> + </TR> + <TR> + <TD VALIGN=TOP> + <P>Parallelität</TD> + <TD VALIGN=TOP> + <P>Hoch, da unabhängige Aufträge meistens nur lesend + auf gemeinsame Resourcen zugreifen.</TD> + <TD VALIGN=TOP> + <P>Sehr hoch, da die benötigten Resourcen erst angefordert + werden, wenn man sie braucht.</TD> + </TR> + </TBODY> +</TABLE> +<P ALIGN=LEFT>Meiner Meinung nach ist nur das „Prealloc Resource +Konzept“ ohne richtige Programmierwerkzeuge zur Entwicklung +paralleler Algorithmen (z.B. Netzprogrammierung) wenigstens ein +bißchen beherschbar.</P> +<P ALIGN=LEFT>Es stellt sich die Frage wie das „Prealloc +Resource Konzept“ in einem Komponenten-Modell und in einem +Objekt-Environment integriert werden kann. Ein Objekt-Environment ist +ein mehr oder weniger dynamische Menge von Objekten die miteinander +in Verbindung stehen. Aus dem obigen Beispiel könnte man die +Verbindung der Textverarbeitung zu ihren Dokumenten als +Objekt-Environment bezeichnen. Ein Objekt in diesem Environment kann +nun über seine Verbindungen mit anderen Objekten kommunizieren. +Die Schnittstellen mit denen über die Verbindung kommuniziert +wird nennt man Komponenten-Modell. Die Idee des Objekt-Environments +ist es weitere Objekte möglichst einfach zu integrieren. So +könnten in unserem Beispiel weitere Dokumenttypen wie ein +HTML-Dokument eingebunden werden. Die Schittstellen müßten +nur dem, von der Textverarbeitung geforderten, Komponenten-Modell +genügen. Liefert aber das Modell, wie heute üblich, keine +Information über die benötigten Resourcen bei Benutzung der +Schnittstellen, dann können Verklemmungen bzw. Inkonsistenzen +nicht vermieden werden. Aus diesem Grunde ist es notwendig, das +Resource-Konzept in das Komponenten-Modell zu integrieren.<BR><B>Ziel:</B> +Es muß ein Kompromiß zwischen hoher Nebenläufigkeit +und der damit verbundenen Komplexität, sowie einfacher +Programmierung und geringer Nebenläufigkeit gefunden +werden.<BR><B>Folgen:</B> In einem Objekt-Environment müssen die +einzelnen Objekte also dynamisch auf Verbindungen zu Objekten mit +hoher oder geringer Nebenläufigkeit reagieren. Die Komplexität +dieser Aufgabe darf aber nicht in die Objekte verlagert werden, da +von einem seriellen Objekt (bzw. dessen Programmierer) nicht die +Steuerung nebenläufiger Aufträge verlangt werden +kann.<BR><B>Lösungsansatz:</B> Die Behandlung der +Nebenläufigkeit wird nicht in einer einfachen Komponente +implementiert. Das bedeutet sie muß mit einer +Default-Behandlung zufrieden sein, die minimale Nebeläufigkeit +nach sich zieht. Eine Komponente kann sich aber in die Vergabe der +Resourcen einmischen. So kann sie ihren Grad der Nebenläufigkeit +erhöhen. Dies ist dann aber auch mit erhöhtem +Implementationsaufwand zu bezahlen. Auf der anderen Seite macht es +aber keinen Sinn serielle oder Komponenten mit zu großem +Resourcebedarf einzubinden, wenn das Objekt-Environment danach +praktisch nicht mehr lauffähig ist. Das bedeutet, daß das +Objekt-Environment auch Forderungen bezüglich des Resourcebedarf +an die Komponenten stellen darf.</P> +<H3>Anforderungen</H3> +<OL> + <LI><P ALIGN=LEFT>Es muß ein Modell geben, in dem alle + vorhandenen Resourcen und deren Beziehung zueinander eingetragen + werden. Dadurch kann abgeschätzt werden, welchen Resourcebedarf + eine Komponente hat. Das „Schätzen“ ist wörtlich + zu nehmen. (Im Zusammenhang mit <A HREF="#Security">Security</A> + wird man aber auch noch sehen, daß der Zugriff auf bestimmte + Resourcen nicht möglich ist.) Für das „Prealloc + Resource Konzept“ gilt, es müssen mindestens die + benötigten Resourcen verfügbar sein. Zur Not sind diese + alle.</P> + <LI><P ALIGN=LEFT>Eine nebenläufige Komponente muß in + jeder ihrer von außen erreichbaren Methoden kontrollieren, ob + die entsprechenden Resourcen für sie angefordert wurden. Damit + serielle Komponenten diese Methoden nutzen können, können + die benötigten Resourcen angefordert werden, wenn vorher noch + <B>keine einzige</B> durch den ausführenden Auftrag belegt war. + Zur Erläuterung: Serielle Komponenten belegen keine Resourcen. + Damit würde jeder Aufruf einer nebenläufigen Komponente + scheitern. Um dies zu vermeiden, werden die Resourcen in der + nebenläufigen Komponente angefordert.</P> + <LI><P ALIGN=LEFT>Serielle Komponenten müssen also damit + rechnen eine Fehlermeldung über nicht verfügbare Resourcen + zu bekommen.</P> +</OL> +<H3>Szenarien</H3> +<P>Von unserem bisherigen Beispiel ausgehend, gibt es eine +Applikation in der sich drei Dokumente befinden. Ein serielles +Textdokument, ein nebenläufiges Tabellendokument und ein +nebenläufiges Präsentationsdokument. Die Applikation selbst +ist nebenläufig. Die Relationen gehen von der Applikation zu den +Dokumenten und umgekehrt. Die Dokumente kennen sich nicht.</P> +<P>Fall 1:<BR>In das serielle Textdokument soll eine Zeichenfolge +eingefügt werden. Da es sich um eine serielle Komponente +handelt, kann dieses Einfügen nicht von selbst ausgelöst +werden, es muß von einer nebenläufigen Komponente, hier +die Applikation, angestoßen werden. Die Applikation ist aber +verpflichtet die Resourcen vorher zu reservieren. Für diese +Abschätzung gibt es drei realistische Möglichkeiten. 1. Sie +reserviert nur das Textdokument selbst. Das bedeutet, das +Textdokument kann mit keinem anderen Objekt, auch nicht mit der +Applikation, kommunizieren. 2. Die Applikation und das Textdokument +wird reserviert. Es ist also nur der Zugriff auf die anderen +Dokumente verwehrt. 3. Alle Objekte werden reserviert. Geht es nach +dem „Prealloc Resource Konzept“ muß 3. gewählt +werden. Aufgrund von Sicherheitsbeschränkungen werden wir aber +noch sehen, das serielle Komponenten in ihrer Auftragsbearbeitung +gestoppt werden können. Wenn der Abbruch eines Auftrags möglich +ist, spielt es aber keine Rolle durch wen (Resourcen oder <A HREF="#Security">Security</A>) +dies geschehen ist.</P> +<P>Fall 2:<BR>In das nebenläufige Tabellendokument soll eine +Zeichenfolge eingefügt werden. Dieser Auftrag kann von der +Applikation oder der Komponente selbst ausgelöst werden. In +jedem Fall müssen die Resourcen vor der Auftragsbearbeitung +reserviert werden. Man kann dies auch der Komponente überlassen +(siehe Anforderung 2.), aber man scheitert, wenn zwei Aufträge +zu einem Auftrag zusammengefaßt werden sollen. Dies passiert +z.B., wenn der Auftrag „Text ersetzen“ aus den Aufträgen +„Löschen“ und „Einfügen“ besteht. Auf +jeden Fall wird nur das Tabellendokument selbst reserviert, da das +Einfügen keine Auswirkung auf andere Komponenten hat.</P> +<P>Fall 3:<BR>In das nebenläufige Tabellendokument wird der +Applikationsname aus der Applikation eingefügt. Dazu fragt das +Tabellendokument nach den benötigten Resourcen, um den Namen zu +holen und ihn einzufügen. Zum Holen wird die Applikation +benötigt und zum Einfügen das Tabellendokument. Beide +müssen vor der Auftragsausführung reserviert werden.</P> +<P>Fall 4:<BR>Das nebenläufige Tabellendokument fügt +selektierten Text aus dem seriellen Textdokument ein. Da das +Textdokument seinen Resourcebedarf nicht mitteilt, wird einer aus +Fall eins abgeschätzte Bedarf genommen. Man kann sehen, daß +der Auftrag für alle drei Möglichkeiten erteilt werden +kann. Seine Nebenläufigkeit wird dann durch die Abschätzung +eingeschränkt. Zusätzlich müssen natürlich die +benötigten Resourcen für das Einfügen geholt werden. +Alle müssen vor der Auftragsausführung reserviert werden.</P> +<H3>Programmierkonzepte</H3> +<P>Welche Konzepte können in einer objektorientierten Sprache +wie c++ oder Java oder einer prozeduralen Sprache wie Fortran oder +„c“ eingesetzt werden, um Nebenläufigkeit zu +erreichen. </P> +<OL> + <LI><P>Es gibt zwei Möglichkeiten eine Resource zu belegen. Das + ist Exclusive (lesen, schreiben) und „ReadOnly“. Eine + Resource kann von mehreren Aufträgen benutzt werden, wenn diese + nur „ReadOnly“ benötigen.</P> + <LI><P>Es gibt Resourcen für die man die Resourceverteilung + optimieren kann. Ein Objekt welches nicht geändert werden kann + und das während der Auftragsausführung immer konsistent + ist kann die Anforderung „Exclusiv“ automatisch auf + „ReadOnly“ abschwächen. Dies lohnt sich, wenn man + serielle Komponenten hat, die nichts über die + Resourceanforderungen mitteilen. Als Beispiel möchte ich eine + Instanz der Klasse String in Java nennen. Ein weitere Art von + Resourcen fordern bei Aufträgen an sie 1. keine weiteren + Aufträge an, 2. beenden sie die Aufträge schnell und 3. + die Reihenfolge der Änderung an ihnen ist für andere nicht + wichtig. Dies ist zum Beispiel bei der Speicherverwaltung in c der + Fall. Diese Art der Resource darf zu einem späteren Zeitpunkt + angefordert werden. Sie muß sofort benutzt und wieder + freigegeben werden. Aus diesem Grund erledigen solche Resourcen das + Anfordern und Freigeben selbst.</P> + <LI><P>Bevor ein Auftrag ausgeführt werden kann, müssen + alle von ihm benötigten Resourcen reserviert werden. Dies ist + für einen Auftrag, der aus mehreren Teilaufträgen besteht, + aufwendig. Eine Optimierung kann darin bestehen die Teilaufträge + asynchron auszuführen. Allerdings dringt diese Verhaltensweise + nach außen. Z.B. müssen Aufträge, die diesen dann + asynchronen Auftrag nutzen, dann auch asynchron sein. Eine weitere + Optimierung in der Autragsvergabe gibt es, wenn ein Autrag die + Resourcervergabe nicht ändert. Es ist dann möglich mehr + Aufträge vorzuziehen.</P> + <LI><P>Es muß eine Queue geben, in die Aufträge eingefügt + werden können. Konfliktfreie Aufträge können parallel + ausgeführt werden. <B>Achtung:</B> Der Resourcebedarf eines + Auftrages kann nur bestimmt werden, wenn alle benötigten + Resourcen „ReadOnly“ reserviert werden können, es sei + denn kein vor ihm laufender Auftrag ändert die Resourcevergabe. + Warum ist das so? Ein Auftrag kann eine Resource dahingehend ändern, + daß danach andere Resourcen benötigt werden als vorher. + Der vorher bestimmte Bedarf ist dann falsch.</P> + <LI><P>Das Modell der Resourcen kann vergröbert oder verfeinert + werden. In einem Tabellendokument könnte man jede einzelne + Zelle zu einer Resource machen. Um die Komplexität der + Resourcemodells zu vereinfachen kann man aber weiter alle Zellen der + Dokument-Resource zuordnen. Wird also aus einer anderen Komponente + die Zelle angefordert, wird automatisch das ganze Dokument + reserviert. Daraus ergeben sich zwei Vorteile: 1. Für den + Auftraggeber ist die Vergröberung transparent und 2. Kann die + Resource an dem Objekt reserviert werden, das man ohnehin kennt.</P> + <LI><P>Das Resource-Modell ist hierarchisch. Eine Resource kann nur + einer Vergröberung zugeordnet werden. Die Tabellenzellen dürfen + also nur dem Tabellendokument zugeordnet werden. Daraus ergibt sich, + daß innerhalb einer solchen Hierarchie nebenläufig + gearbeitet werden kann. Es dürfen dann aber keine Resourcen + außerhalb der Hierarchie benutzt werden, selbst wenn diese + reserviert sind.</P> +</OL> +<H3>Probleme und Lösungen</H3> +<P>Über den Benutzer müssen Daten abgefragt werden, die +über die Benutzung von Resourcen entscheidet (z.B. +Dateiname):<BR>Ein solcher Auftrag muß in zwei Teilaufträge +unterteilt werden. Der erste erledigt die Abfrage. Danach werden alle +Resourcen freigegeben und dann fordert der zweite seine Resourcen und +wird bearbeitet. Eventuell kann ein solcher Auftrag den vorherigen +ersetzten, um zu verhindern das andere abhängige Aufträge +vor dem Aufgeteilten bearbeitet werden.</P> +<P>Ich habe mich bei einem Objekt als Listener angemeldet:<BR>Es gibt +zwei Arten von Benachrichtigungen die ich erhalte. 1. Aufgrund der +Ausführung eines Auftrages und 2. einen Event von einer +nebenläufigen Komponente. Im ersten Fall überprüfe ich +den Resourcebedarf und führe dann den Auftrag aus. Im zweiten +Fall reserviere ich die benötigten Resourcen und führen den +Auftrag aus. Sind Resourcen reserviert, ist dies Fall eins, sonst +Fall zwei.</P> +<P>Ich bin Broadcaster:<BR>Broadcaste ich aufgrund eines Auftrags tue +ich nichts weiter. Löse ich den Broadcast ohne Auftrag aus, muß +ich die Resourcen für die Listener bestimmen und sie vor dem +Aufruf reservieren. Die einzelnen Listener werden als unabhängig +betrachtet. Im Detail findet folgender Ablauf statt. 1. Die Liste der +Listener wird kopiert. 2. Für den ersten Listener wird der +Resourcebedarf ermittelt.</P> +<H3>Implementation</H3> +<P>Die Basis für die Implementation des Resourcekonzeptes legen +die Klassen <A HREF="stardiv.resource.Resource.html#Resource">Resource</A>, +<A HREF="stardiv.resource.ResourceList.html#ResourceList">ResourceList</A>, +<A HREF="stardiv.resource.ResourceLockException.html#ResourceLockException">ResourceLockException</A>, +<A HREF="stardiv.resource.Task.html#Task">Task</A>, <A HREF="stardiv.resource.TaskManager.html#TaskManager">TaskManager</A>, +<A HREF="stardiv.resource.TaskThread.html#Task">TaskThread</A>, +<A HREF="stardiv.resource.ThreadData.html#ThreadData">ThreadData</A> +und das Interface <A HREF="stardiv.resource.Resourceable.html#Resourceable">Resourceable</A> +fest. Um ein Objekt in das Resourcekonzept einbinden zu können +sind folgende Schritte notwendig:<BR>1. Das Resourceable Interface +muß implementiert werden. 2. Ein Konstruktor mit der dem +Objekte zugewiesenen Resource. 3. Jede public Methode bekommt eine +*_Resource(...) Methode zur Seite, mit der der Resourcebedarf +ermittelt werden kann. 4. Innerhalb der public Methode wird der +Resourcebedarf ermittelt. 5. Mit dieser Information die als +ResourceListe vorliegt, wird eine Auftrag (Task) erzeugt. 6. Dieser +Auftrag wird beim TaskManager angemeldet. 7. Nach der Zuteilung durch +den TaskManager wird der Auftrag ausgeführt. 8. Alle Resourcen +und der Auftrag werden wieder freigegeben.<BR>Diese Liste ist +detailliert aber nicht <B>vollständig</B>. In der Klasse +Resource steht imm eine Beispiel, welches aktuell sein sollte.</P> +<P>Folgende Programmierrichtlinien gibt es, um das „Prealloc +Resource Konzept“ in Java zu integrieren:</P> +<OL> + <LI><P ALIGN=LEFT>Es muß das Interface <A HREF="stardiv.resource.Resourceable.html#Resourceable">Resourceable</A> + implementiert werden. Mit Hilfe dieses Interfaces kann der + Resourcebedarf eines Objektes erfragt werden. Diese Richtlinien + gelten dann auch für die Superklasse.</P> + <LI><P ALIGN=LEFT>???Es muß das Interface <A HREF="stardiv.concepts.ModifyTestable.html#ModifyTestable">ModifyTestable</A> + implementiert werden. Damit kann überprüft werden, ob an + den Resourcen Veränderungen vorgenommen wurden.</P> + <LI><P ALIGN=LEFT>Nur Methoden die über die Lebensdauer des + Objektes keine veränderten Werte liefern dürfen immer + gerufen werden. Das sind zum Beispiel alle Methoden der Klasse + java.lang.Object.</P> + <LI><P ALIGN=LEFT>Um den Resourcebedarf einzelner Methoden genauer + zu ermitteln kann eine Methode mit dem, um _Resource( ResourceList + aRL, boolean bCheck, ... ) erweiterten Namen, gerufen werden. Ein + Beispiel befindet sich in der Klasse <A HREF="stardiv.resource.Resource.html#Resource">Resource</A>.</P> +</OL> +<H2><A NAME="Security"></A>Security</H2> +<H2><A NAME="Data Requests"></A>Data Requests</H2> +<P>Diese Schnittstelle soll das Anfordern von Daten vereinheitlichen. +Das Problem, welches zu diesem Ansatz führte, ist das Lesen von +Daten über einen „langsamen“ Internet-Stream. Das +bedeutet es werden Daten benötigt, die erst noch übertragen +werden müssen. Da das Pull-Modell immer einen eigenen Thread +vorraussetzt, um die restliche Anwendung nicht zu blockieren, habe +ich das Push-Modell gewählt.<BR><B>Ziel:</B> Für die +Implementation sollte es möglichst transparent sein, wie die +Daten herangeschafft werden. Als zweites soll die Schnittstelle für +denjenigen einfach sein, der alle Daten sofort bereithält.<BR><B>Lösung:</B> +Der Datenverarbeiter ist passiv. Das bedeutet, beim Entgegennehmen +der Daten beginnt er nicht sie zu verarbeiten. Dies muß extra +angestoßen werden. Zweitens, der Datenverarbeiter hält den +Status des Datenlieferanten. Dies können EOF, für alle +Daten gelesen, READY, für sind Daten da, PENDING, es kommen noch +weitere Daten und NO_SOURCE, es wurden nicht alle Daten verarbeitet +und es kommen keine weiteren Daten mehr. <B>Achtung</B> der Status +ist nur zu bestimmten Zeitpunkten gültig. Der Datenverarbeiter +darf nur im Zustand PENDING Daten bekommen. Diese Annahme schützt +ihn vor der Implementation eines Puffers. Das <A HREF="stardiv.concepts.QueryData.html#QueryData">QueryData</A> +- Interface ist die Spezifikation für dieses Verhalten.</P> +<H2><A NAME="Modify"></A>Modify</H2> +<P>Das Ziel ist nur eine Schnittstelle zu erstellen, mit der ein +Objekt auf Änderungen überprüft werden kann. Da es für +ein Objekt verschiedene Möglichkeiten gibt Änderungen an +sich zu prüfen (z.B. Änderungszähler, Kopie), muß +die Schnittstelle möglichst flexibel sein, um vielen +Implementationen gerecht zu werden. Die Lösung sind zwei +Methoden. Mit der einen (getModifyHandle()) kann der Zeitpunkt +festgemacht werden, zu dem mögliche Änderungen überprüft +werden sollen. Der Rückgabewert ist eine beliebiges Objekt, so +daß in ihm die benötigte Überprüfungsinformation +(z.B. der Änderungszähler) untergebracht werden kann. +Danach kann mit der zweiten Methode (isModified(Object)) überprüft +werden, ob eine Änderung stattgefunden hat. Das Interface für +dieses Konzept heißt <A HREF="stardiv.concepts.ModifyTestable.html#ModifyTestable">ModifyTestable</A> +.</P> +<H2><A NAME="LifeConnect"></A>LifeConnect</H2> +<P>LifeConnect ist die Kommunikation zwischen PlugIns, Applets und +JavaScript. Die Kommunikation kann in beide Richtungen erfolgen.Unter +JavaScript kann auf alle Systemklassen zugegriffen werden. Die +Abbildung der JavaScript-Aufrufe nach Java ist die Aufgabe der Klasse +<A HREF="stardiv.js.ip.CallJava.html#CallJava">CallJava</A>. Dazu +wird das in Java 1.1 implementierte Package java.lang.reflect +benutzt. Da JavaScript eine nicht typisierte Sprache ist, werden die +Werte nach JavaScript-Regeln in die entsprechenden Javatypen +umgesetzt. Bezüglich der Sicherheit wird ein JavaScript-Programm +auf die gleiche Stufe wie ein Applet gestellt. Um den Zugriff der +Applets auf JavaScript zu gestatten, muß das HTML-Tag MYSCRIPT +angegeben werden. Auf die Java-Klassen kann in JavaScript mit dem +Prefix „Package“ zugegriffen werden (sun, java und netscape +benötigen keinen Prefix). Die Klassen netscape.plugin.Plugin, +netscape.javascript.JSObject und netscape.javascript.JSException +dienen zur Kommunikation von Java mit JavaScript.</P> +<P>Konvertierungstabelle anhand der Spezifikation „JavaScript +Language Specifications“ 3.1.2 TypeConversion</P> +<TABLE WIDTH=100% BORDER=1 CELLPADDING=5 CELLSPACING=0 FRAME=HSIDES RULES=ALL> + <COLGROUP> + <COL WIDTH=26*> + <COL WIDTH=40*> + <COL WIDTH=47*> + <COL WIDTH=47*> + <COL WIDTH=47*> + <COL WIDTH=47*> + </COLGROUP> + <THEAD> + <TR> + <TH WIDTH=10% VALIGN=TOP> + <P><BR></TH> + <TH WIDTH=16% VALIGN=TOP> + <P><I>byte</I></TH> + <TH WIDTH=19% VALIGN=TOP> + <P><I>short</I></TH> + <TH WIDTH=19% VALIGN=TOP> + <P><I>char</I></TH> + <TH WIDTH=19% VALIGN=TOP> + <P><I>int</I></TH> + <TH WIDTH=19% VALIGN=TOP> + <P><I>long</I></TH> + </TR> + </THEAD> + <TBODY> + <TR> + <TD VALIGN=TOP> + <P ALIGN=LEFT>Undef.</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>Fehler</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>Fehler</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>Fehler</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>Fehler</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>Fehler</TD> + </TR> + <TR> + <TD VALIGN=TOP> + <P ALIGN=LEFT>Function</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>(10) valueOf/error</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>(11) valueOf/error</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>(11) valueOf/error</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>(12) valueOf/error</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>(13) valueOf/error</TD> + </TR> + <TR> + <TD VALIGN=TOP> + <P ALIGN=LEFT>Object</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>(10) valueOf/error</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>(11) valueOf/error</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>(11) valueOf/error</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>(12) valueOf/error</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>(13) valueOf/error</TD> + </TR> + <TR> + <TD VALIGN=TOP> + <P ALIGN=LEFT>Object (null)</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>(10) 0</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>(11) 0</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>(11) 0</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>(12) 0</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>(13) 0</TD> + </TR> + <TR> + <TD VALIGN=TOP> + <P ALIGN=LEFT>double</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>(10) Zahl oder Fehler, wenn Bereichs-überschreitung</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>(11) Zahl oder Fehler, wenn Bereichs-überschreitung</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>(11) Zahl oder Fehler, wenn Bereichs-überschreitung</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>(12) Zahl oder Fehler, wenn Bereichs-überschreitung</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>(13) Zahl oder Fehler, wenn Bereichs-überschreitung</TD> + </TR> + <TR> + <TD VALIGN=TOP> + <P ALIGN=LEFT>boolean</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>(15) 0/1</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>(15) 0/1</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>(15) 0/1</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>(15) 0/1</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>(15) 0/1</TD> + </TR> + <TR> + <TD VALIGN=TOP> + <P ALIGN=LEFT>Leer String</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>error</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>error</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>error</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>error</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>error</TD> + </TR> + <TR> + <TD VALIGN=TOP> + <P ALIGN=LEFT>String</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>(10) error/ Zahl</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>(11) error/ Zahl</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>(11) error/ Zahl</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>(12) error/ Zahl</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>(13) error/ Zahl</TD> + </TR> + </TBODY> +</TABLE><DL> + <DT><BR></DT> +</DL> +<TABLE WIDTH=100% BORDER=1 CELLPADDING=5 CELLSPACING=0 FRAME=BOX RULES=ALL> + <COLGROUP> + <COL WIDTH=27*> + <COL WIDTH=59*> + <COL WIDTH=44*> + <COL WIDTH=35*> + <COL WIDTH=36*> + <COL WIDTH=55*> + </COLGROUP> + <THEAD> + <TR> + <TH WIDTH=10% VALIGN=TOP> + <P><BR></TH> + <TH WIDTH=23% VALIGN=TOP> + <P><I>float</I></TH> + <TH WIDTH=17% VALIGN=TOP> + <P><I>double</I></TH> + <TH WIDTH=14% VALIGN=TOP> + <P><I>boolean</I></TH> + <TH WIDTH=14% VALIGN=TOP> + <P><I>String</I></TH> + <TH WIDTH=22% VALIGN=TOP> + <P><I>Object</I></TH> + </TR> + </THEAD> + <TBODY> + <TR> + <TD VALIGN=TOP> + <P ALIGN=LEFT>Undef.</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>Fehler</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>Fehler</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>false</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>„undefined“</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>null</TD> + </TR> + <TR> + <TD VALIGN=TOP> + <P ALIGN=LEFT>Function</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>(14) valueOf/error</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>(15) valueOf/error</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>(15) valueOf/ true</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>(15) JS-Code der Funktion</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>(30) netscape .javascript. JSObject</TD> + </TR> + <TR> + <TD VALIGN=TOP> + <P ALIGN=LEFT>Object</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>(14) valueOf/error</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>(15) valueOf/error</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>(15) valueOf/ true</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>(15) valueOf / toString + </TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>(30) Java-Cast/ error</TD> + </TR> + <TR> + <TD VALIGN=TOP> + <P ALIGN=LEFT>Object (null)</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>(14) 0</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>(15) 0</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>(15) false</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>(15) „null“</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>(30) null</TD> + </TR> + <TR> + <TD VALIGN=TOP> + <P ALIGN=LEFT>double</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>(14) Zahl oder Fehler, wenn Bereichs-überschreitung</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>(30) Zahl</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>(7) 0, NaN -> false !0, -+Infinite -> true</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>(8) Zahl, NaN, Infinity oder -Infinity</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>(9) Number/ error + </TD> + </TR> + <TR> + <TD VALIGN=TOP> + <P ALIGN=LEFT>boolean</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>(15) 0/1</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>(15) 0/1</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>(30) boolean</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>(15) „false“/ “true“</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>(15) Boolean/ error</TD> + </TR> + <TR> + <TD VALIGN=TOP> + <P ALIGN=LEFT>Leer String</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>error</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>error</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>(15) false</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>(30) String</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>(15) String/ error</TD> + </TR> + <TR> + <TD VALIGN=TOP> + <P ALIGN=LEFT>String</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>(14) error/ Zahl</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>(15) error/ Zahl</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>(15) true</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>(30) String</TD> + <TD VALIGN=TOP> + <P ALIGN=LEFT>(15) String/ error</TD> + </TR> + </TBODY> +</TABLE> +<P><BR></P> +<P>Der Algorithmus zum mappen der polymorphen Methoden in Java:<BR>1. +Die Anzahl der Parameter muß übereinstimmen.<BR>2. Die +Parameter müssen, nach der obigen Tabelle, konvertiert werden +können.<BR>3. Es gibt ein Punktesystem, nach dem die Methode +ausgewählt wird. Die Punkte stehen in Klammern in den +Tabelleneinträgen. Die Konvertierungspunkte für Zahlen sind +typabhängig und nicht wertabhängig. Dadurch ist +sichergestellt, das nicht unterschiedliche Methoden bei sich +ändernden Werten gerufen werden. Kommt es allerdings zu einem +Konvertierungsfehler (Überlauf), dann wird versucht eine andere +Methode zu finden.<BR>4. Es wird vorausgesetzt, daß die +Methoden „valueOf“ und „toString“ keine +Seiteneffekte haben. Sie dürfen also beliebig oft aufgerufen +werden.<BR>5. Es wird nur null auf eine Java-Array abgebildet.</P> +<H2><A NAME="Testen"></A>Testen</H2> +<P>Das Ziel dieses Abschnitts ist es Vorgehensweisen zu entwickeln, +mit denen sich die Java Grundkonzepte testen lassen. Folgende +Checkliste ist für jede Methode abzuarbeiten.</P> +<OL> + <LI><P>Zu jeder Klasse gibt es eine entsprechende Testklasse. Diese + steht im Package „test“.... Der Name der Klasse wird mit + „Test“ erweitert. Beispiel: stardiv.memory.BitArray wird + zu test.memory.BitArrayTest. Jede dieser Klassen hat eine Methode + „public static void main( String [] )“. Diese Methode wird + aufgerufen, um den Test aller Methoden anzustoßen. Der Test + ist nicht interaktiv. Wird ein Fehler festgestellt, wird das + Programm mit exit( -1 ) verlassen.</P> + <LI><P>Jede Methode muß unabhängig von ihren Environment + getestet werden. Alle Resourcen für die Methode werden als + Dummy für den Test implementiert. Diese Forderung führt zu + sauberen Schnittstellen, da ansonsten für den Test ja ganze + Objekte implementiert werden müssen.</P> + <LI><P>Das Testprotokoll protokolliert mit „System.out.println“. + Vor dem Test der einzelnen Methoden wird in einer Zeile kurz über + den Test informiert. Scheitert der Test, dann wird eine + Fehlermeldung ausgegeben in der „failed“ enthalten sein + muß. </P> + <LI><P>Um <A HREF="#Defined Exception">Defined Exception</A> und + <A HREF="#Transacted Exception">Transacted Exception</A> testen zu + können, sollten die <A HREF="stardiv.concepts.Resource.html#Resource">Resource</A> + und <A HREF="stardiv.concepts.ModifyTestable.html#ModifyTestable">ModifyTestable</A> + Interfaces implementiert werden. Es kann damit automatisch geprüft + werden, ob sich eine Resource unerlaubter Weise geändert hat.</P> +</OL> +<H2>Begriffe</H2> +<P><A NAME="lebendig"></A>Lebendig: Ein System wird als lebendig +bezeichnet, wenn alle in ihm befindlichen Aufträge +fertiggestellt werden können. Sie sich also nicht in einer +Verklemmung oder einem „Race“ befinden.</P> +</BODY> +</HTML>
\ No newline at end of file |