1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
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>
|
