844 lines
No EOL
37 KiB
HTML
844 lines
No EOL
37 KiB
HTML
<!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> |