Ανάπτυξη συστήματος κράτησης εισιτηρίων κινηματογράφου μέσω διαδικτύου με τεχνολογίες JAVA

fairieshourglassΛογισμικό & κατασκευή λογ/κού

9 Ιουν 2012 (πριν από 5 χρόνια και 5 μήνες)

1.520 εμφανίσεις

Αλεξάνδρειο Τεχνολογικό Εκπαιδευτικό Ίδρυμα
Θεσσαλονίκης
Σχολή Τεχνολογικών Εφαρμογών
Τμήμα Πληροφορικής



Πτυχιακή εργασία

Ανάπτυξη συστήματος κράτησης εισιτηρίων
κινηματογράφου μέσω διαδικτύου με τεχνολογίες
JAVA



ΤΩΝ ΥΠΟΨΗΦΙΩΝ ΜΗΧΑΝΙΚΩΝ ΠΛΗΡΟΦΟΡΙΚΗΣ:
ΝΙΚΟΛΑΟΥ Δ. ΠΑΠΑΓΙΑΝΝΟΠΟΥΛΟΥ
ΝΙΚΟΛΑΟΥ Δ. ΠΟΡΦΥΡΙΑΔΗ

ΕΙΣΗΓΗΤΗΣ:
κ. ΜΙΧΑΗΛ ΒΑΣΙΛΑΚΟΠΟΥΛΟΣ

ΘΕΣΣΑΛΟΝΙΚΗ
ΑΝΟΙΞΗ 2006
Παπαγιαννόπουλος Νικόλαος Πορφυριάδης Νικόλαος

2


















































Παπαγιαννόπουλος Νικόλαος Πορφυριάδης Νικόλαος

3






Αφιέρωση Παπαγιαννόπουλου Νίκου




























Παπαγιαννόπουλος Νικόλαος Πορφυριάδης Νικόλαος

4









Αφιέρωση Πορφυριάδη Νίκου




























Παπαγιαννόπουλος Νικόλαος Πορφυριάδης Νικόλαος

5
Περιεχόμενα

Αφιέρωση Παπαγιαννόπουλου Νίκου 3

Αφιέρωση Πορφυριάδη Νίκου 4

Περιεχόμενα 5

Εισαγωγή 9

Οι απαιτήσεις του συστήματος. 9

Η Αντικειμενοστραφής Ανάλυση και Σχεδίαση 10

Εφαρμογή της UML και των προτύπων στην αντικειμενοστραφή ανάλυση και σχεδιασμό
(OOA/D) 10
Τι είναι ανάλυση και σχεδίαση; 12
Τι είναι αντικειμενοστραφής ανάλυση και σχεδίαση; 12
Καθορισμός των περιπτώσεων χρήσης. (Use Cases) 13
Καθορισμός του Domain Model. 14
Καθορισμός των διαγραμμάτων αλληλεπίδρασης 14
Καθορισμός των διαγραμμάτων τάξεων (Class Diagrams) 15
Επαναληπτική ανάπτυξη και η ενοποιημένη διεργασία 16
Η σημαντικότερη ιδέα της Ενοποιημένης Διεργασίας (UP): Επαναληπτική ανάπτυξη 16
Ζώντας με τις αλλαγές: Ανατροφοδότηση και προσαρμογή 17
Οφέλη της επαναληπτικής ανάπτυξης 19
Μήκος επανάληψης και Χρονοδιάγραμμα 19
Επιπρόσθετες τεχνικές και έννοιες για την Ενοποιημένη Διεργασία (UP) 20
Οι φάσεις της Ενοποιημένης Διεργασίας (UP) 20
Προσαρμογή διαδικασίας ανάλυσης και σχεδίασης και η περίπτωση ανάπτυξης
(Development Case) 21
Προαιρετικά έγγραφα 21
Η Ενοποιημένη Διεργασία (UP) είναι εύκαμπτη 22
Γλώσσα μοντελοποίησης-UML 23

Η UML 23
H γλώσσα προγραμματισμού JAVA 24

Εισαγωγή 24
Τα χαρακτηριστικά της Java 24
Επιδόσεις 26
Εργαλεία ανάπτυξης 26
Σύνθετο περιβάλλον ανάπτυξης (IDE) 26
Τι είναι το Java applet 27
Πως γράφεται ένα Applet; 28
Μέθοδοι-Σταθμοί για ένα Applet 29
Ένα παράδειγμα 30
Το εργαλείο ανάπτυξης Netbeans IDE 31
Η βάση δεδομένων PostGreSQL 39

Εισαγωγή 39
Η ανάπτυξης ξεφεύγει από το Berkeley 40
Λογισμικό ανοιχτού κώδικα 42
Περίληψη 43
Οι Τεχνολογίες 46

3-tier application 46
Παπαγιαννόπουλος Νικόλαος Πορφυριάδης Νικόλαος

6
Το επίπεδο παρουσίασης (GUI layer) 46
The Object layer 46
Το επίπεδο της ΒΔ 46
Ακεραιότητα δεδομένων 47
PostgreSQL JDBC 47
Εγκαθιστώντας τον οδηγό JDBC 48
Χρήση του οδηγού 49
RMI - Remote Method Invocation (RMI) 50
Εισαγωγή 50
Γενικά 51
Επικλήση Απομακρυσμένων Μεθόδων 52
Stubs και Skeletons 53
Εύρεση Απομακρυσμένων Αντικειμένων – Χρήση του Registry 54
Δυναμική φόρτωση κλάσεων 54
Η πλευρά του εξυπηρετητή 54
Η διεπιφάνεια Hello 55
Η κλάση FibonacciImpl 56
Παράδειγμα Η κλάση FibonacciServer 57
Η πλευρά του πελάτη 58
Παράδειγμα Η κλάση FibonacciClient 58
Μεταγλώττιση των Stub 59
Εκκίνηση του Εξυπηρετητή 60
Εκτελώντας την κλάση Πελάτης 60
Φορτώνοντας τις Κλάσεις κατά την Εκτέλεση 61
Περιπτώσεις χρήσης και έγγραφα προδιαγραφών περιπτώσεων χρήσης 62

Use Case UC-V1: Κράτηση Εισιτηρίου 62
Use Case UC-V2: Εισαγωγή σχολίου 63
Use Case UC-V3: Εισαγωγή στοιχείων Θεατή 64
Use Case UC-A1: Στατιστικά ροών δεδομένων. 66
Use Case UC-A2: Διαχείριση Χρηστών 68
Use Case UC-A3: Διαχείριση ΒΔ 69
Use Case UC-A4: Αποστολή μηνυμάτων ηλεκτρονικού ταχυδρομείου 71
Use Case UC-Τ1: Πώληση εισιτηρίου 73
Use Case UC-Τ2: Εμφάνιση διαθεσιμότητας θέσεων 74
Use Case UC-A1: Triggers – Προγραμματισμένες ενέργειες 76
Συμπληρωματικές Προδιαγραφές 78
Χρηστικότητα 79
Αξιοπιστία 79
Interfaces 80
Επιχειρηματικοί κανόνες 80
Νομικά θέματα 81
Πληροφορίες σε τομείς που έχουν ενδιαφέρον 82
Vision-Όραμα 82

Εισαγωγή 82
Η θέση στην αγορά 82
Περιγραφή των εμπλεκομένων 83
Σύνοψη χρηστών 84
Στόχοι κλειδιά υψηλού επιπέδου και προβλήματα των εμπλεκομένων 84
Οι στόχοι σε επίπεδο χρηστών 86
Υποθέσεις και εξαρτήσεις 87
Παπαγιαννόπουλος Νικόλαος Πορφυριάδης Νικόλαος

7
SSD System Sequence Diagrams Διαγράμματα Ακολουθίας Συστήματος 89

SSD System Sequence Diagram Διάγραμμα Ακολουθίας Συστήματος «Θεατής» 89
SSD System Sequence Diagram Διάγραμμα Ακολουθίας Συστήματος «Ταμίας 1» 89
SSD System Sequence Diagram Διάγραμμα Ακολουθίας Συστήματος «Ταμίας 2» 90
SSD System Sequence Diagram Διάγραμμα Ακολουθίας Συστήματος «Administrator-
Τύπος Αίθουσας» 91
SSD System Sequence Diagram Διάγραμμα Ακολουθίας Συστήματος «Administrator-
Αίθουσα» 91
SSD System Sequence Diagram Διάγραμμα Ακολουθίας Συστήματος «Administrator-
Ταινία» 92
SSD System Sequence Diagram Διάγραμμα Ακολουθίας Συστήματος «Administrator-
Παράσταση» 93
SSD System Sequence Diagram Διάγραμμα Ακολουθίας Συστήματος «Δημιουργία
Administrator» 93
Domain Model 94

Η Βάση Δεδομένων 95

Views 98
UML patterns-GRASP 100

Εισαγωγή 100
GRASP: Πρότυπα γενικών αρχών στην ανάθεση ευθυνών 103
Φορέας Πληροφορίας ή Εμπειρογνώμονας (Information Expert) 103
Χαμηλή σύζευξη 110
Υψηλή Συνοχή 113
Τεχνητή Επινόηση 116
Indirection (Έμμεση διασύνδεση ή μεσάζων) 118
PersistentStorage (Μόνιμη αποθήκευση) 119
Το σύνολο των προτύπων GRASP 119
Άλλες τεχνολογίες που χρησιμοποιήθηκαν 121

JavaMail API 121
Τι είναι το JavaMail API 121
Αποστέλλοντας Email 122
Printing API 124
Εισαγωγή 124
Η κλάση PrinterJob 124
Η κλάση Book 125
Το Πλαίσιο Διαλόγου Εκτύπωσης 125
Εκτυπώνοντας 126
Binary large object BLOB 127
JavaBeans 127
Αλγόριθμος Εύρεσης Ελεύθερων Θέσεων 128

Οι Αίθουσες 128
Έννοιες του Αλγόριθμου 129
Κράτηση Θέσης ή Θέσεων 129
Ασφάλεια 131

Ασφάλεια εφαρμογής 132
Class model 132

Γενική όψη κλάσεων 132
Διάγραμμα κλάσεων Πελάτη 133
Διάγραμμα κλάσεων Εξυπηρετητή 133
Παπαγιαννόπουλος Νικόλαος Πορφυριάδης Νικόλαος

8
Αντί επιλόγου 135

Κριτική επάνω στον τρόπο ανάλυσης και σχεδίασης που χρησιμοποιήθηκε 135
Τι έχει να γίνει από εδώ και πέρα 135
Παράρτημα Ι - Οδηγίες εγκατάστασης και χρήσης του προγράμματος 136

Παράρτημα ΙΙ - ΕΞΑΓΩΓΗ ΑΠΑΙΤΗΣΕΩΝ 145

Μελέτη υποδομής (Background reading ) 145
Συνεντεύξεις 146
Επί τόπου παρακολούθηση 148
Δειγματοληψία εγγράφων 149
Ερωτηματολόγια 150
Παράρτημα ΙΙΙ - Java RMI & CORBA Σύγκριση των δύο ανταγωνιζόμενων
τεχνολογιών 151

Τι είναι η RMI 151
Τι είναι η CORBA 152
RMI εναντίον CORBA 153
Επίλογος 154
Παράρτημα ΙV - Benchmarking 154

Παράρτημα V – Πιστοποίηση των Applets με Χρήση Πιστοποιητικών RSA 155

Γλωσσάριο 157

Βιβλιογραφία 162

Βιβλία 162
Ηλεκτρονική Βιβλιογραφία (Ιστοσελίδες) 162





















Παπαγιαννόπουλος Νικόλαος Πορφυριάδης Νικόλαος

9
Εισαγωγή
Σκοπός του κειμένου που ακολουθεί είναι να περιγράψει το πρόγραμμα που
αναπτύχθηκε για την διπλωματικής εργασίας των φοιτητών Παπαγιανόπουλου Νίκου και
Πορφυριάδη Νίκου.
Η εφαρμογή αφορά ένα πρόγραμμα τύπου 3-tier που έχει ως στόχο να υποστηρίξει
μηχανογραφικά κινηματογράφους σε όλη την ελληνική επικράτεια. Η μηχανογραφική
υποστήριξη περιλαμβάνει κράτηση και πώληση εισιτηρίων μέσω διαδικτύου, διαχείριση
επιχειρησιακών δεδομένων και πολλά άλλα που αναλύονται στη συνεχεία.
Η ανάπτυξη του προγράμματος έγινε σύμφωνα με τις αρχές της ενοποιημένης
διεργασίας και με την χρήση της γλώσσας μοντελοποίησης UML.
Τα εργαλεία που χρησιμοποιήθηκαν (Visual paradigm, Netbeans, Java) αλλά και η
βάση δεδομένων PostgreSQL καθώς και άλλα δευτερεύοντα βοηθητικά προγράμματα
αναλύονται λεπτομερώς. Ιδιαίτερη μνεία γίνεται για τον τρόπο εγκατάστασης των
προγραμμάτων, τον τρόπο λειτουργία τους και τα προβλήματα που το κάθε ένα έλυσε στη
διάρκεια της ανάλυσης, σχεδίασης αλλά και κατά την συγγραφή της εφαρμογής.
Ιδιαίτερη προσοχή έχει δοθεί στον τομές της ασφαλείας, για αυτό χρησιμοποιηθήκαν
και τεχνολογίες και εργαλεία προορισμένα να προσφέρουν τη μέγιστη δυνατή ασφάλεια όπως
SSL και κρυπτογράφηση των δεδομένων που αποστέλλονται στο ίντερνετ μιας και το
πρόγραμμα αφορά οικονομικές συναλλαγές.
Τέλος υπάρχουν οδηγίες χρήσης και εγκατάστασης του προγράμματος ώστε η
εφαρμογή να είναι πλήρης όσον αφορά την γραπτή τεκμηρίωση της (documentation) αλλά
και όσο πιο φιλική γίνεται προς τον τελικό χρήστη.
Ως συνοδευτικά και συμπληρωματικά του κειμένου θα βρείτε στο DVD που συνοδεύει
αυτή την εργασία διάφορα video που επεξηγούν βήμα προς βήμα πως γίνεται η εγκατάσταση
όλων των προγραμμάτων της εφαρμογής αλλά και μια μικρή επίδειξη της λειτουργίας της.
Οι απαιτήσεις του συστήματος.
Οι απαιτήσεις όπως περιγράφονται στο παρόν έγγραφο είναι αποτέλεσμα πολλών
συνεντεύξεων με τους εμπλεκομένους και εργασία ενδελεχών βελτιώσεων και
τροποποιήσεων (βλ. παράρτημα ΙΙ). Σε καμιά περίπτωση αυτό το έγγραφο δεν είναι οι
απαιτήσεις έτσι όπως έγιναν κατανοητές μετά την πρώτη συνέντευξη. Συνεπώς μπορούν να
θεωρηθούν ως τελικές.
Σκοπός του συστήματος είναι η δημιουργία κατάλληλης υποδομής ώστε οι θεατές να
μπορούν να κάνουν κρατήσεις εισιτηρίων κινηματογράφου σε κινηματογράφους σε όλη την
Ελλάδα. Επίσης στις λειτουργίες του συστήματος περιλαμβάνεται η διαχείριση των
κινηματογραφικών αιθουσών και η ταμειακή υποστήριξη.
Το σύστημα θα είναι ικανό να διαχειρίζεται κρατήσεις εισιτηρίων μέσω ίντερνετ.
Ακόμη θα μπορεί να κάνει υποστήριξη του ταμείου των κινηματογράφων για την έκδοση
εισιτηρίων. Τέλος το σύστημα θα είναι ικανό να διαχειριστεί τα επιχειρηματικά δεδομένα,
πράγμα που σημαίνει ότι ο διαχειριστής του συστήματος θα μπορεί να εισάγει ταινίες,
παραστάσεις, αίθουσες κινηματογράφου να διαχειρίζεται τα δεδομένα των θεατών και γενικά
να κάνει όλες τις δυνατές επεξεργασίες στα δεδομένα που ήδη διαχειρίζεται πριν την
δημιουργία του συστήματος καθώς και όλες τις δυνατές επεξεργασίες δεδομένων στα
καινούρια δεδομένα που το σύστημα θα συλλέγει.
Παπαγιαννόπουλος Νικόλαος Πορφυριάδης Νικόλαος

10
Το σύστημα θα πρέπει να είναι ικανό να εγκατασταθεί και να τρέχει για να καλύπτει
όλες τις προαναφερθείσες απαιτήσεις με την ελάχιστη δυνατή επιβάρυνση τόσο για αγορά
του καταλλήλου εξοπλισμού όσο και για εκπαίδευση.
Αναλυτικότερα οι λειτουργίες του συστήματος είναι οι εξής:
Ο θεατής θα μπορεί να επιλεγεί την παράσταση της αρεσκείας του συμφωνά με
πολλαπλά κριτήρια επιλογής (πόλη, ημερομηνία, κινηματογράφος, ταινία, παράσταση, ώρα
προβολής, είδος ταινίας). Θα μπορεί να πληρώνει με πιστωτική κάρτα ή απλά να κάνει μια
κράτηση. Θα έχει τη δυνατότητα να κάνει μια εγγραφή στο σύστημα με τα προσωπικά του
στοιχειά ώστε να έχει ειδικά προνομία όπως τη συγγραφή σχολίων και την βαθμολόγηση των
ταινιών που έχει δει.
Όσον αφορά τον ταμία αυτός θα μπορεί να εκδίδει εισιτήρια καθώς και να έχει την
πλήρη εποπτεία των κρατήσεων για τις αίθουσες που εκδίδει εισιτήρια.
Για τον διαχειριστή του συστήματος ή για τον ιδιοκτήτη ενός κινηματογράφου αυτός θα
μπορεί να διαχειρίζεται όλα τα επιχειρηματικά δεδομένα πλήρως.
Αναλυτικά αυτό σημαίνει ότι μπορεί να δημιουργήσει η να τροποποιήσει τα δεδομένα
που αφορούν τις ταινίες, τις παραστάσεις, τους κινηματογράφους τις αίθουσες και τους
τύπους αιθουσών. Όσον αφορά τα πρόσωπα θα μπορεί να δημιουργεί η να τροποποιεί
δεδομένα που αφορούν τους ιδίους τους διαχειριστές-Administrator, τους ταμίες.
Τέλος ένα σημαντικό θέμα είναι η ασφάλεια των δεδομένων μιας και οι
κινηματογράφοι που αναμένεται να υποστηρίζει το σύστημα θα είναι δεκάδες. Είναι
προφανές και αναμενόμενο κάθε κινηματογράφος να έχει πρόσβαση μονό σε εκείνα τα
δεδομένα που είναι σημαντικά για την λειτουργία του και όχι σε δεδομένα που αφορούν
άλλους κινηματογράφους.
Το σύστημα θα δημιουργεί στατιστικά για τις ταινίες που έχουν μεγαλύτερη ζήτηση για
τις μέρες που υπάρχει μεγαλύτερη κίνηση για τις ηλικίες που παρακολουθούν πιο πολύ
κινηματογράφο και γενικά θα εμφανίζει κάθε αξιοποιήσιμο στατιστικά στοιχειό ώστε να
βοηθήσει στην καλύτερη λειτουργία του κινηματογράφου αλλά και του συστήματος.
Με παρόμοιο τρόπο θα εκδίδει οικονομικά και λογιστικά στατιστικά τα οποία είναι
χρήσιμα για την τήρηση των λογιστικών βιβλίων.
Το σύστημα θα κρατάει ένα ιστορικό ταινιών, παραστάσεων αλλά και κρατήσεων για
επιχειρησιακούς λογούς. Η διαγραφή του ιστορικού θα γίνεται χειροκίνητα από
εξουσιοδοτημένα άτομα.
Τέλος το σύστημα θα υποστηρίζει την διαφήμιση με email σε όλους τους θεατές που το
επιθυμούν. Το σύστημα θα προβλέπει εκπτώσεις και αποστολή μηνυμάτων ηλεκτρονικού
ταχυδρομείου σε ομάδες θεατών συμφωνά με πολύπλοκα κριτήρια κατηγοριοποίησης ώστε
τα μηνύματα να είναι πιο άμεσα και η διαφήμιση πιο πετυχημένη.
Η Αντικειμενοστραφής Ανάλυση και Σχεδίαση
1

Εφαρμογή της UML και των προτύπων στην αντικειμενοστραφή ανάλυση και
σχεδιασμό (OOA/D)
Τι σημαίνει να δημιουργηθεί ένας καλός σχεδιασμός αντικειμένων; Αυτό το κεφαλαίο
εστιάζει στις βασικές έννοιες στην αντικειμενοστραφή ανάλυση και το σχεδιασμό (OOA/D).
Ότι περιγράφεται σε αυτό το κεφαλαίο είναι σημαντικό και απαραίτητο για τη δημιουργία


1
Craig Larman, (2001) Applying UML and Patterns 2nd Ed κεφάλαιο 1 (σελ 3-12)
Παπαγιαννόπουλος Νικόλαος Πορφυριάδης Νικόλαος

11
ενός καλά σχεδιασμένου, σταθερού, και συντηρήσιμου λογισμικού με τη χρήση
αντικειμενοστραφών τεχνολογιών και γλωσσών όπως η java, η C ++, η Smalltalk, και η C #.
Η παροιμία "όποιος έχει ένα σφυρί δεν είναι αρχιτέκτονας" βρίσκει εφαρμογή στην
αντικειμενοστραφή τεχνολογία. Η γνώση μιας αντικειμενοστραφούς γλώσσας (όπως η java)
είναι ένα απαραίτητο αλλά ανεπαρκές πρώτο βήμα για τη δημιουργία αντικειμενοστραφών
συστημάτων.
Η UML είναι μια τυποποιημένη σημειογραφία για τη δημιουργία διαγραμμάτων.
Υπάρχουν πολλά και σημαντικότερα αντικειμενοστραφή πράγματα σε σχέση με τη
σημειογραφία για να μάθει κανείς, όπως πώς να σκέφτεται με αντικείμενα και να σχεδιάζει
αντικειμενοστραφή συστήματα. Η UML δεν είναι κομμάτι της αντικειμενοστραφούς
ανάλυσης και σχεδίασης (OOA/D) ή κάποια μέθοδος, είναι απλά μια σημειογραφία. Δεν είναι
τόσο χρήσιμο να μάθει κανείς συντακτικά σωστό σχεδιασμό με UML και ίσως ένα εργαλείο
UML, αλλά μετά να μην είναι σε θέση να δημιουργήσει ένα καλό σχέδιο, ή να αξιολογήσει
και να βελτιώσει ένα υπάρχον. Αυτή είναι η πιο δύσκολη και η πολυτιμότερη ικανότητα.
Η αντικειμενοστραφής ανάλυση και σχεδίαση (OOA/D) (και όλος ο σχεδιασμός του
λογισμικού) συσχετίζεται με την προαπαιτούμενη δραστηριότητα της ανάλυσης των
απαιτήσεων, η οποία περιλαμβάνει τη σύνταξη των περιπτώσεων χρήσης (use cases).
Λαμβάνοντας υπόψη πολλές πιθανές δραστηριότητες από τις απαιτήσεις μέχρι την
υλοποίηση, πώς θα έπρεπε ένας προγραμματιστής ή μια ομάδα να προχωρήσει; Η ανάλυση
απαιτήσεων και η αντικειμενοστραφής ανάλυση και σχεδίαση (OOA/D) πρέπει να
παρουσιαστούν στα πλαίσια κάποιας διαδικασίας ανάπτυξης. Σε αυτήν την περίπτωση, η
ενοποιημένη διαδικασία (UP) χρησιμοποιείται ως παράδειγμα επαναληπτικής διαδικασίας
ανάπτυξης μέσα στην οποία παρουσιάζονται αυτά τα θέματα. Εντούτοις, η ανάλυση και τα
θέματα σχεδιασμού που καλύπτονται είναι παρόμοια για πολλές προσεγγίσεις, και η αναφορά
τους στα πλαίσια της ενοποιημένης διαδικασίας (UP) δεν ακυρώνει τη δυνατότητα
εφαρμογής τους σε άλλες μεθόδους.

Εικόνα 1
Παπαγιαννόπουλος Νικόλαος Πορφυριάδης Νικόλαος

12
Πολλές άλλες δεξιότητες είναι σημαντικές
Η δημιουργία λογισμικού περιλαμβάνει πολλές δεξιότητες και βήματα πέρα από την
ανάλυση απαιτήσεων, την αντικειμενοστραφή ανάλυση και σχεδίαση και τον
αντικειμενοστραφή προγραμματισμό. Για παράδειγμα η μηχανική λειτουργικότητας
(usability engineering) και ο σχεδιασμός της επιφανείας του χρηστή είναι σημεία κρίσιμα για
την επιτυχία ενός προγράμματος, το ίδιο και ο σχεδιασμός της βάσης δεδομένων.
Αναθέτοντας αρμοδιότητες
Υπάρχουν πολλές πιθανές δραστηριότητες που είναι απαραίτητες στην
αντικειμενοστραφή ανάλυση και σχεδιασμό (OOA/D), και ένας πλούτος αρχών και οδηγιών.
Υποθέστε ότι πρέπει να επιλέξουμε μια πρακτική ικανότητα από όλα τα θέματα που
συζητήθηκαν προηγουμένως. Ποια θα ήταν;
Μια κρίσιμη, θεμελιώδης ικανότητα στην αντικειμενοστραφή ανάλυση και σχεδιασμό
(OOA/D) είναι ο επιδέξιος καταμερισμός των αρμοδιοτήτων στα τμήματα λογισμικού.
Γιατί; Επειδή είναι μια δραστηριότητα που πρέπει να εκτελεστεί, είτε σχεδιάζοντας ένα
UML διάγραμμα είτε προγραμματίζοντας και επηρεάζει σημαντικά την αντοχή, την
ικανότητα συντήρησης και την ικανότητα επαναχρησιμοποίησης των τμημάτων λογισμικού.
Φυσικά, υπάρχουν άλλες απαραίτητες δεξιότητες στην αντικειμενοστραφή ανάλυση και
σχεδιασμό OOA/D, αλλά η ανάθεση αρμοδιοτήτων τονίζεται σε αυτήν την εισαγωγή επειδή
τείνει να είναι μια αμφισβητήσιμη ικανότητα για να κυριαρχήσει, και ωστόσο ζωτικά
σημαντική. Σε ένα πραγματικό έργο, ένας που ασχολείται με την ανάπτυξη μπορεί να μην
έχει την ευκαιρία για περαιτέρω ανάλυση ή σχεδιασμό -- η "πίεση για την ανάπτυξη του
κώδικα". Ακόμα και σε αυτήν την κατάσταση, ο καταμερισμός αρμοδιοτήτων είναι
αναπόφευκτος .
Τέλος, κατά τη διάρκεια της υλοποίησης ή του αντικειμενοστραφούς
προγραμματισμού, τα αντικείμενα σχεδιασμού εφαρμόζονται, όπως μια κλάση (class) Βιβλίο
στην java.
Τι είναι ανάλυση και σχεδίαση;
Η ανάλυση δίνει έμφαση στη διερεύνηση του προβλήματος και τις απαιτήσεις του,
παρά στη λύση του. Παραδείγματος χάριν, εάν σκοπός ήταν η δημιουργία ενός
πληροφοριακού συστήματος για τη μηχανογράφηση μιας βιβλιοθήκης, ποια θα ήταν η χρήση
αυτού;
"Η ανάλυση" είναι ένας ευρύς όρος και ορίζεται καλύτερα, ως ανάλυση απαιτήσεων
(μια έρευνα για τις απαιτήσεις) ή ανάλυση αντικειμένου (μια έρευνα για τα εννοιολογικά
αντικείμενα).
Η σχεδίαση δίνει έμφαση στην εννοιολογική λύση που ικανοποιεί τις απαιτήσεις του
προβλήματος, παρά στην υλοποίηση αυτής της λύσης. Παραδείγματος χάριν, η περιγραφή
μιας βάσεως δεδομένων και των αντικειμένων λογισμικού. Το τελικό βήμα είναι η υλοποίηση
των σχεδίων.
Όπως με την ανάλυση, ο όρος είναι καλύτερα ορισμένος, ως σχεδιασμός αντικειμένου ή
σχεδιασμός βάσεων δεδομένων.
Η ανάλυση και ο σχεδιασμός έχουν συνοψιστεί στη φάση do the right thing
(Ανάλυση), and do the thing right (σχεδίαση).
Τι είναι αντικειμενοστραφής ανάλυση και σχεδίαση;
Κατά τη διάρκεια της αντικειμενοστραφούς ανάλυσης, δίνεται έμφαση στην εύρεση
και την περιγραφή των αντικειμένων ή των εννοιών στην περιοχή του προβλήματος.
Παπαγιαννόπουλος Νικόλαος Πορφυριάδης Νικόλαος

13
Παραδείγματος χάριν, στην περίπτωση του πληροφοριακού συστήματος της βιβλιοθήκης, το
βιβλίο, η βιβλιοθήκη, και o πελάτης αποτελούν μερικές από τις έννοιες που ενδιαφέρουν τον
αναλυτή.
Κατά τη διάρκεια του αντικειμενοστραφούς σχεδιασμού, δίνεται έμφαση στον
καθορισμό των αντικειμένων λογισμικού και στο πώς αυτά συνεργάζονται για να
ικανοποιήσουν τις απαιτήσεις. Παραδείγματος χάριν, στο σύστημα βιβλιοθήκης, ένα
αντικείμενο Βιβλίο μπορεί να έχει μια ιδιότητα τίτλος και μια μέθοδο getChapter.
Τελικά κατά την υλοποίηση implementation η κατά τη διάρκεια του αντικειμενοστραφή
προγραμματισμού υλοποιούνται οι κλάσης που σχεδιαστήκαν όπως η κλάση Book σε Java.


Εικόνα 2
Ένα Παράδειγμα
Πριν γίνει αναφορά στις λεπτομέρειες της ανάλυσης απαιτήσεων και την OOA/D
(αντικειμενοστραφή ανάλυση και σχεδίαση), αυτό το κεφάλαιο παρουσιάζει μια σφαιρική
άποψη μερικών βασικών βημάτων και διαγραμμάτων, χρησιμοποιώντας ένα απλό
παράδειγμα -- "ένα παιχνίδι με ζάρια" στο οποίο ένας παίκτης ρίχνει δύο ζάρια. Εάν φέρει
επτά, κερδίζει, διαφορετικά χάνει.
Καθορισμός των περιπτώσεων χρήσης. (Use Cases)
Η ανάλυση απαιτήσεων μπορεί να περιλάβει μια περιγραφή των σχετικών διαδικασιών
με όρους του πραγματικού κόσμου, αυτές μπορούν να γραφτούν ως περιπτώσεις χρήσης.

Εικόνα 3
Οι περιπτώσεις χρήσης δεν είναι αντικειμενοστραφής τεχνολογία– είναι απλά ιστορίες
για το τι αναμένεται να κάνει η εφαρμογή αποτυπωμένες σε ένα κείμενο. Εντούτοις, είναι ένα
δημοφιλές εργαλείο στην ανάλυση απαιτήσεων και είναι ένα σημαντικό μέρος της
ενοποιημένης διαδικασίας (UP).
Παπαγιαννόπουλος Νικόλαος Πορφυριάδης Νικόλαος

14
Καθορισμός του Domain Model.
Η αντικειμενοστραφής ανάλυση ασχολείται με την περιγραφή της περιοχής του
προβλήματος, χρησιμοποιώντας αντικείμενα. Μια ανάλυση της περιοχής του προβλήματος
περιλαμβάνει τον προσδιορισμό των εννοιών, των ιδιοτήτων, και των συσχετίσεων που
θεωρούνται αξιοσημείωτα. Το αποτέλεσμα μπορεί να εκφραστεί σε ένα εννοιολογικό
μοντέλο (domain model), το οποίο παρουσιάζεται από ένα σύνολο διαγραμμάτων τα οποία
περιγράφουν αντικείμενα ή αφηρημένες έννοιες του πραγματικού κόσμου.

Εικόνα 4
Παραδείγματος χάριν, ένα μερικό Domain Model παρουσιάζεται στο σχήμα 1.3.

Εικόνα 5
Αυτό το μοντέλο επεξηγεί τις έννοιες Player, Die, και το DiceGame, με τις συσχετίσεις
και τις ιδιότητές τους.
Σημειώστε ότι ένα εννοιολογικό μοντέλο(domain model) δεν είναι μια περιγραφή των
αντικειμένων του λογισμικού, είναι μια απεικόνιση των εννοιών του πραγματικού κόσμου.
Καθορισμός των διαγραμμάτων αλληλεπίδρασης
Ο αντικειμενοστραφής σχεδιασμός έχει να κάνει με τον καθορισμό των αντικειμένων
του λογισμικού και με το πως αυτά συνεργάζονται. Μια συνηθισμένη σημειογραφία για την
επεξήγηση αυτής της συνεργασίας είναι τα διαγράμματα αλληλεπίδρασης (interaction
diagram), τα οποία παρουσιάζουν τη ροή των μηνυμάτων μεταξύ των αντικειμένων του
λογισμικού, και συνεπώς την κλήση των μεθόδων.

Εικόνα 6
Παπαγιαννόπουλος Νικόλαος Πορφυριάδης Νικόλαος

15
Παραδείγματος χάριν, υποθέστε ότι επιθυμούμε να υλοποιήσουμε σε λογισμικό το
παιχνίδι με τα ζάρια (dice game) . Το διάγραμμα αλληλεπίδρασης στο σχήμα 1.4 επεξηγεί το
σημαντικό βήμα στο σχεδιασμό του παιχνιδιού, δηλαδή πως στέλνονται μηνύματα στα
αντικείμενα του DiceGame και στις κλάσεις του Die.

Εικόνα 7
Παρατηρήστε ότι αν και στην πραγματικότητα ένας παίχτης (player) ρίχνει τα ζάρια,
στο σχεδιασμό λογισμικού, το αντικείμενο DiceGame "ρίχνει" τα ζάρια (δηλαδή στέλνει τα
μηνύματα στα αντικείμενα Die). Ο σχεδιασμός αντικειμένων και προγραμμάτων είναι
εμπνευσμένα από τον πραγματικό κόσμο, αλλά δεν είναι ακριβή πρότυπα ή προσομοιώσεις
του πραγματικού κόσμου.
Καθορισμός των διαγραμμάτων τάξεων (Class Diagrams)
Εκτός από μια δυναμική εικόνα των συνεργαζόμενων αντικειμένων που
παρουσιάστηκε στα διαγράμματα αλληλεπίδρασης (interaction diagrams), είναι χρήσιμο να
δημιουργηθεί μια στατική εικόνα των κλάσεων με το σχεδιασμό ενός διαγράμματος
κλάσεων (class diagram). Αυτό επεξηγεί τις ιδιότητες και τις μεθόδους των κλάσεων.


Εικόνα 8
Παραδείγματος χάριν, στο παιχνίδι με τα ζάρια (dice game), μια επιθεώρηση του
διαγράμματος αλληλεπίδρασης οδηγεί στο μερικό (partial) σχεδιασμό του διαγράμματος
κλάσεων, που παρουσιάζεται στο σχήμα 1.5. Από τη στιγμή που ένα μήνυμα play στέλνεται
σε ένα αντικείμενο DiceGame, η κλάση DiceGame απαιτεί μια μέθοδο play, ενώ η κλάση Die
απαιτεί μία μέθοδο roll και μια μέθοδο getFaceValue.
Παπαγιαννόπουλος Νικόλαος Πορφυριάδης Νικόλαος

16

Εικόνα 9
Συνοψίζοντας
Το dicegame είναι ένα απλό πρόβλημα, που παρουσιάζεται για να εστιάσει σε μερικά
βήματα και αντικείμενα στην ανάλυση και το σχεδιασμό. Για να κρατηθεί το παράδειγμα
απλό δεν αναλυθήκαν όλες οι λεπτομέρειες.
Επαναληπτική ανάπτυξη και η ενοποιημένη διεργασία
2

Η ενοποιημένη διεργασία είναι μια αντικειμενοστραφή προσέγγιση στον τρόπο
σχεδίασης και ανάπτυξης συστημάτων λογισμικού. Μια διαδικασία ανάπτυξης λογισμικού
περιγράφει μια προσέγγιση στο χτίσιμο, στην ανάπτυξη, και ενδεχομένως στη συντήρηση του
λογισμικού. Η ενοποιημένη διαδικασία έχει προκύψει ως δημοφιλής διαδικασία ανάπτυξης
λογισμικού για αντικειμενοστραφή συστήματα. Πιο συγκεκριμένα, η Rational Unified
Process ή RUP, είναι μια λεπτομερής βελτίωση της ενοποιημένης διαδικασίας και είναι
ευρέως υιοθετημένη. Η ενοποιημένη διαδικασία (UP) συνδυάζει κοινώς αποδεκτές καλύτερες
πρακτικές, όπως έναν επαναληπτικό κύκλο ζωής και μια κίνδυνο-καθοδηγημένη ανάπτυξη,
αλλά και μια συνεκτική και καλά τεκμηριωμένη περιγραφή του συστήματος που βρίσκεται
υπό ανάπτυξη. Συνεπώς, χρησιμοποιείται στη συνεχεία ως παράδειγμα μέσα στο οποίο
γίνεται η εισαγωγή στην αντικειμενοστραφή ανάλυση και σχεδίαση (OOA/D).
Η σημαντικότερη ιδέα της Ενοποιημένης Διεργασίας (UP): Επαναληπτική ανάπτυξη
Η Ενοποιημένη Διεργασία (UP) χρησιμοποιεί μερικές από τις καλύτερες πρακτικές για
την ανάλυση και σχεδίαση συστημάτων λογισμικού. Η σημαντικότερη όμως πρακτική είναι η
επαναληπτική ανάπτυξη. Η ανάπτυξη οργανώνεται σε μια σειρά από σύντομα,
καθορισμένου μήκους (παραδείγματος χάριν, τεσσάρων εβδομάδων) μίνι-projects που
ονομάζονται επαναλήψεις. Το αποτέλεσμα κάθε μιας από αυτές τις επαναλήψεις είναι ένα
δοκιμασμένο, ολοκληρωμένο και εκτελέσιμο σύστημα. Κάθε επανάληψη περιλαμβάνει την
ανάλυση απαιτήσεων, τη σχεδίαση, την εφαρμογή και τις δραστηριότητες δοκιμής.
Ο επαναληπτικός τρόπος ανάπτυξης είναι βασισμένος στη διαδοχική διεύρυνση και
αύξησης της ποιότητας του συστήματος μέσω των πολλαπλών επαναλήψεων, με κυκλική
ανατροφοδότηση και αναπροσαρμογή. Το σύστημα αυξάνεται προοδευτικά με την πάροδο
του χρόνου, από επανάληψη σε επανάληψη, έτσι αυτή η προσέγγιση είναι επίσης γνωστή ως
επαναληπτική και αυξητική ανάπτυξη (δείτε το σχήμα 2.1).


2
Craig Larman, (2001) Applying UML and Patterns 2nd Ed κεφάλαιο 2 (σελ 13-27)
Παπαγιαννόπουλος Νικόλαος Πορφυριάδης Νικόλαος

17

Εικόνα 10
Παρατηρήστε ότι σε αυτό το παράδειγμα ότι δεν υπάρχει ούτε βιασύνη για παραγωγή
κώδικα, ούτε ένας μακρόσυρτος σχεδιασμός που προσπαθεί να τελειοποιήσει όλες τις
λεπτομέρειες του σχεδίου πριν αρχίσει ο προγραμματισμός. Με «λίγη» σύνεση σχετικά με το
σχεδιασμό με την οπτική χρησιμοποίηση διαμόρφωσης τραχιά και γρήγορα σχέδια UML
γίνονται ίσως μια μισή ή πλήρης ημέρα από τους υπεύθυνους για την ανάπτυξη να κάνει την
εργασία σχεδίου ανά τα ζευγάρια. Το αποτέλεσμα κάθε επανάληψης είναι ένα εκτελέσιμο
αλλά ελλιπές σύστημα δεν είναι έτοιμος να παραδώσει στην παραγωγή. Το σύστημα μπορεί
να μην είναι έτοιμο να δοθεί στην παραγωγή πριν την ολοκλήρωση πολλών επαναλήψεων
παραδείγματος χάριν, 10 ή 15 επαναλήψεις.
Το αποτέλεσμα μιας επανάληψης δεν είναι κάτι πειραματικό ή ένα πρωτότυπο που είναι
για πέταμα, επίσης η επαναληπτική ανάπτυξη δεν είναι διαμόρφωση πρωτοτύπου. Θα
μπορούσε να πει κανείς ότι το αποτέλεσμα είναι ένα ολοκληρωμένο υποσύνολο του τελικού
συστήματος.
Αν και, γενικά, κάθε επανάληψη αντιμετωπίζει τις νέες απαιτήσεις και αυξητικά
επεκτείνει το σύστημα, μπορεί περιστασιακά σε μια επανάληψη να αναθεωρηθεί το υπάρχον
λογισμικό και να βελτιωθεί. παραδείγματος χάριν, μια επανάληψη μπορεί να εστιάσει στη
βελτίωση της απόδοσης ενός υποσυστήματος, παρά στην επέκταση του με τα νέα
χαρακτηριστικά γνωρίσματα.

Ζώντας με τις αλλαγές: Ανατροφοδότηση και προσαρμογή
«Εναγκαλισμός με την αλλαγή». Αυτή η φράση φέρνει στο νου την βασική αρχή της
επαναληπτικής ανάπτυξης: Οι υπεύθυνοι για την ανάλυση και τη σχεδίαση παλεύουν την
αναπόφευκτη αλλαγή που εμφανίζεται στην ανάπτυξη λογισμικού προσπαθώντας (συνήθως
ανεπιτυχώς) να διευκρινίσουν πλήρως και σωστά και να ¨παγώσουν¨ μια σειρά
προκαθορισμένων απαιτήσεων και στη συνεχεία τη δημιουργία και υλοποίηση ενός
«παγωμένου» σχεδιασμού. Αντίθετα η εργασία γίνεται αποδοτικότερη και τελικά ευκολότερη
με την επαναληπτική ανάπτυξη που είναι βασισμένη στην νοοτροπία-κλειδί του
αγκαλιάσματος της αλλαγής και της προσαρμογής σαν κάτι το αναπόφευκτο και εν τέλει ως
έναν ουσιαστικό οδηγό εργασίας στην ανάπτυξη λογισμικού.
Αυτό δεν σημαίνει ότι η επαναληπτική ανάπτυξη και η Ενοποιημένη Διεργασία (UP)
είναι μια διαδικασία που οδηγείται από ένα ανεξέλεγκτο και συνεχώς ανατροφοδοτούμενο
Παπαγιαννόπουλος Νικόλαος Πορφυριάδης Νικόλαος

18
«ξεγλίστρημα των απαιτήσεων και των χαρακτηριστικών». Η Ενοποιημένη Διεργασία (UP)
ισορροπεί, από τη μια μεριά, την ανάγκη για συμφωνία με τον πελάτη σε ένα σταθερό σύνολο
απαιτήσεων από τη άλλη μεριά την πραγματικότητα των μεταβαλλόμενων απαιτήσεων,
καθώς οι ενδιαφερόμενοι κάνουν πιο ξεκάθαρο το τι θέλουν ή επειδή η αγορά αλλάζει.
Κάθε επανάληψη περιλαμβάνει την επιλογή ενός μικρού υποσυνόλου των απαιτήσεων,
και τον γρήγορο σχεδιασμό, εφαρμογή, και δοκιμή. Στις πρόωρες επαναλήψεις η επιλογή των
απαιτήσεων και ο σχεδιασμός μπορεί να μην είναι ακριβώς αυτό που επιδιώκεται τελικά.
Αλλά η πράξη ‘να κάνουμε γρήγορα ένα μικρό βήμα’, πριν οριστικοποιηθούν όλες οι
απαιτήσεις, ή με μέρος του σχεδιασμού υλοποιημένο πολύ γενικά ή όχι πλήρως
τεκμηριωμένο, οδηγεί σε μια γρήγορη ανατροφοδότηση-ανατροφοδότηση από τους χρήστες,
τους υπεύθυνους για την ανάπτυξη, και δοκιμές (όπως οι δοκιμές με φορτία δεδομένων που
ανταποκρίνονται στην πραγματικότητα και τεστ λειτουργικότητας).
Αυτή η πρόωρη ανατροφοδότηση αξίζει το βάρος της σε χρυσό. Αντί οι υπεύθυνοι για
την ανάλυση και την σχεδίαση να έχουν όλη την προσοχή τους στραμμένη στο ποιες είναι οι
σωστές απαιτήσεις ή ποιος είναι ο καταλληλότερος σχεδιασμός, ανατροφοδοτούμε τις
απαιτήσεις μας από το ρεαλιστικές κτήριο και τη δοκιμή κάτι παρέχει την κρίσιμη πρακτική
διορατικότητα και μια ευκαιρία να τροποποιήσει ή προσαρμόστε την κατανόηση των
απαιτήσεων ή του σχεδιασμού. Οι τελικοί χρήστες έχουν την δυνατότητα γρήγορα να δουν
ένα μερικό σύστημα και να πουν, «ναι, αυτό ζήτησα, αλλά τώρα που το δοκίμασα, αυτό που
πραγματικά θέλω είναι κάτι ελαφρώς διαφορετικό. «1 αυτή η «ναι μεν… αλλά» διαδικασία
δεν είναι ένα σημάδι αποτυχίας μάλλον, νωρίς και συχνοί δομημένοι κύκλοι «ναι μεν αλλά αν
μπορούσε να κάνει και το άλλο;» είναι ένας επιδέξιος τρόπος να σημειωθεί πρόοδος και να
ανακαλυφθεί τι είναι πραγματικής αξίας στους συμμέτοχους. Ακόμα, όπως αναφέρεται, αυτό
δεν είναι μια επικύρωση χαοτικού και αντιδραστική ανάπτυξη στην οποία οι υπεύθυνοι για
την ανάπτυξη αλλάζουν συνεχώς μια κατεύθυνση-μέση ο τρόπος είναι δυνατός.
Εκτός από τη διευκρίνιση απαιτήσεων, δραστηριότητες όπως η δοκιμή φόρτου
εργασίας θα αποδείξει εάν ο μερικός σχεδιασμός και η υλοποίηση του είναι στη σωστή
πορεία, ή εάν πιθανότερα, «δεν καταλάβατε τι θέλησα!» η επόμενη επανάληψη, μια αλλαγή
στην αρχιτεκτονική πυρήνων απαιτείται. Καλύτερα για να επιλύσει και αποδείξτε τις
επικίνδυνες και κρίσιμες αποφάσεις σχεδίου πρόωρες παρά πρόσφατος-και η επαναληπτική
ανάπτυξη παρέχει το μηχανισμό για αυτό.
Συνεπώς, η εργασία προχωρά μέσω μιας σειράς από δομημένος κύκλους κατασκευή-
ανατροφοδότησης-προσαρμογής. Όπως είναι αναμενόμενο, στις πρόωρες επαναλήψεις η
απόκλιση από τη «αληθινή πορεία» του συστήματος (δηλαδή η απόκλιση από τις τελικές
απαιτήσεις και τον τελικό σχεδιασμό) θα είναι μεγαλύτερη απ’ ότι στις επόμενες
επαναλήψεις. Με την πάροδο του χρόνου, το σύστημα συγκλίνει προς αυτή η πορεία, όπως
φαίνεται στο σχήμα 2.2.
Παπαγιαννόπουλος Νικόλαος Πορφυριάδης Νικόλαος

19

Εικόνα 11
Οφέλη της επαναληπτικής ανάπτυξης
Τα οφέλη της επαναληπτικής ανάπτυξης περιλαμβάνουν:
• Πρόωρη παρά αργοπορημένη διαχείριση και μετριασμός των υψηλών κινδύνων
(τεχνικών, απαιτήσεων, στόχων, λειτουργικότητας, και ούτω καθεξής)
• Πρόωρη ορατή πρόοδος
• Πρόωρη ανατροφοδότηση και προσαρμογή, που οδηγεί σε ένα ποιοτικό σύστημα που
ικανοποιεί περισσότερο τις πραγματικές ανάγκες των συμμέτοχων
• Πολυπλοκότητα που μπορεί να διαχειριστεί εύκολα, η ομάδα δεν συντρίβεται από τη
«παράλυση της ανάλυσης» ή σε πάρα πολύ μεγάλα και σύνθετα βήματα
• Η εκμάθηση μέσα σε μια επανάληψη μπορεί να χρησιμοποιηθεί με μεθοδικότητα για
να βελτιώσει τη διαδικασία, επανάληψη με την επανάληψη
Μήκος επανάληψης και Χρονοδιάγραμμα
Η Ενοποιημένη Διεργασία (UP) (αλλά και όσοι έχουν εμπειρία γύρω από αυτήν)
συστήνει ένα μήκος επανάληψης μεταξύ δύο και έξι εβδομάδων. Τα μικρά βήματα, η
γρήγορη ανατροφοδότηση, και η προσαρμογή είναι κεντρικές ιδέες στην επαναληπτική
ανάπτυξη οι μακροχρόνιες επαναλήψεις υπονομεύουν την κυρίως ιδέα της επαναληπτικής
ανάπτυξης και αυξάνουν τον κίνδυνο του project. Σε επαναλήψεις πολύς μικρότερες των δύο
εβδομάδων είναι δύσκολο να ολοκληρωθεί σε ικανοποιητικό βαθμό η εργασία και η
ανατροφοδότηση είναι ελλιπής. Σε επαναλήψεις που κρατάνε πολύ περισσότερο από έξι ή
οκτώ εβδομάδες η πολυπλοκότητα γίνεται τροχοπέδη και η ανατροφοδότηση καθυστερεί.
Μια πολύ μακροχρόνια επανάληψη καταστρέφει το νόημα της επαναληπτικής ανάπτυξης. Το
σύντομο είναι καλό.
Ένα σημείο κλειδί είναι ότι οι επαναλήψεις είναι καθορισμένου μήκους.
Παραδείγματος χάριν, εάν η επόμενη επανάληψη αποφασιστεί να είναι μήκους τεσσάρων
εβδομάδων, τότε το μερικό σύστημα που θα δημιουργηθεί σε αυτήν επανάληψη θα πρέπει να
ολοκληρωθεί, δοκιμαστεί και σταθεροποιηθεί ως την προκαθορισμένη ημερομηνία. Οι
αναβολές στην ολοκλήρωση κάθε επανάληψης θα πρέπει να αποφεύγονται. Εάν φαίνεται ότι
θα είναι δύσκολο να τηρηθεί η προθεσμία, η καλύτερη λύση είναι να αναιρεθούν εργασίες ή
απαιτήσεις από την τρέχουσα επανάληψη, και να συμπεριληφθούν σε μια μελλοντική
επανάληψη, αντί να γίνει αναβολή της ημερομηνίας ολοκλήρωσης.
Παπαγιαννόπουλος Νικόλαος Πορφυριάδης Νικόλαος

20
Οι ογκώδεις ομάδες (παραδείγματος χάριν, αρκετοί υπεύθυνοι για την ανάπτυξη)
μπορούν να απαιτήσουν επαναλήψεις μεγαλύτερες των έξι εβδομάδων για να
αντισταθμιστούν τα γενικά έξοδα του συντονισμού και της επικοινωνίας αλλά συστήνεται σε
κάθε περίπτωση μια επανάληψη να διαρκεί από τρεις έως έξι μήνες. Για παράδειγμα, η
επιτυχής αντικατάσταση στη δεκαετία του '90 του συστήματος ελέγχου της καναδικής
εναέριας κυκλοφορίας αναπτύχθηκε με επαναληπτικούς κύκλους ζωής και άλλες πρακτικές
της Ενοποιημένης Διεργασίας (UP). Μια εξάμηνη επανάληψη είναι η εξαίρεση για τις
ογκώδεις ομάδες, όχι ο κανόνας. Για να επαναλάβει, η Ενοποιημένη Διεργασία (UP)
συστήνει ότι κανονικά μια επανάληψη πρέπει να είναι διάρκειας μεταξύ δύο και έξι
εβδομάδων.
Επιπρόσθετες τεχνικές και έννοιες για την Ενοποιημένη Διεργασία (UP)
Η κεντρική ιδέα είναι η κατανόηση και η υλοποίηση από τους αναλυτές, σχεδιαστές και
προγραμματιστές της Ενοποιημένης Διεργασίας (UP) ως ενός τρόπου ανάπτυξης συστημάτων
που περιλαμβάνει σύντομες επαναλήψεις σταθερού χρονοδιαγράμματος και προσαρμοστική
ανάπτυξη συμφωνά με τις απαιτήσεις των εμπλεκομένων και της αγοράς.
Μια άλλη κεντρική ιδέα στην Ενοποιημένη Διεργασία (UP) είναι η χρήση των
αντικειμενοστραφών τεχνολογιών κάτι που περιλαμβάνει αντικειμενοστραφή ανάλυση και
σχεδίαση αλλά και αντικειμενοστραφή προγραμματισμό.
Μερικές πρόσθετες καλύτερες πρακτικές και βασικές έννοιες στην Ενοποιημένη
Διεργασία (UP) περιλαμβάνουν:
• Αντιμετώπιση των υψηλών κινδύνων και μεγάλης αξίας ζητήματα στις πρόωρες
επαναλήψεις
• Συνεχής όχληση των χρηστών και γενικά των εμπλεκομένων για αξιολόγηση,
ανατροφοδότηση, και επαναπροσδιορισμό των απαιτήσεων
• Χτίσιμο μια συνεκτική, αρχιτεκτονική πυρήνων στις πρώτες επαναλήψεις
• Συνεχής έλεγχος της ποιότητας εξετάστε νωρίς, συχνά, και ρεαλιστικά
• Εφαρμογή των περιπτώσεων χρήσης
• Οπτική διαμόρφωση του λογισμικού (με τη UML)
• Προσεκτική διαχείριση των απαιτήσεων
• Αίτημα αλλαγής πρακτικής και διαχείριση διαμόρφωσης
Οι φάσεις της Ενοποιημένης Διεργασίας (UP)
Ένα πλάνο ανάπτυξης μιας εφαρμογής βασισμένο στην Ενοποιημένη Διεργασία (UP)
οργανώνει την εργασία και τις επαναλήψεις σε τέσσερις σημαντικές φάσεις:
1. Αρχική μελέτη (Inception) Κατά προσέγγιση όραμα έναρξης, επιχειρησιακή
περίπτωση, πεδίο, ασαφείς εκτιμήσεις.
2. Επεξεργασία (Elaboration) καθαρισμένο όραμα, επαναληπτική εφαρμογή του
πυρήνα αρχιτεκτονικής, ψήφισμα των υψηλών κινδύνων, προσδιορισμός των περισσότερων
απαιτήσεων και πεδίο, ρεαλιστικότερες εκτιμήσεις.
3. Κατασκευή (Construction) επαναληπτική εφαρμογή του υπόλοιπου χαμηλότερου
κινδύνου και ευκολότερα στοιχεία, και προετοιμασία για την επέκταση.
4. Μετάβαση (Transition) δοκιμές του λογισμικού, επέκταση.
Αυτό δεν είναι ο παλαιός «καταρράκτης» ή o διαδοχικός κύκλος ζωής όπου πρώτα
πρέπει να καθοριστούν όλες οι απαιτήσεις, και μετά να γίνει όλος ή το μεγαλύτερο μέρος του
σχεδιασμού.
Παπαγιαννόπουλος Νικόλαος Πορφυριάδης Νικόλαος

21
Η έναρξη δεν είναι η φάση των απαιτήσεων, είναι ένα είδος φάσης ανάλυσης του τι
μπορεί να γίνει, όπου γίνεται ακριβώς όση έρευνα χρειάζεται για να παρθεί μια απόφαση αν η
ομάδα θα συνεχίσει την ανάπτυξη ή θα σταματήσει.
Ομοίως, η επεξεργασία δεν είναι η φάση απαιτήσεων ή η φάση σχεδίασης, αλλά είναι η
φάση όπου η κεντρική αρχιτεκτονική εφαρμόζεται επαναληπτικά, και μετριάζονται τα
ζητήματα υψηλού κινδύνου.
Το σχήμα 2.3 επεξηγεί τους συνήθεις όρους που έχουν σχέση με την αλληλουχία των
ενεργειών στην Ενοποιημένη Διεργασία (UP) . Παρατηρήστε ότι ένας κύκλος ανάπτυξης
αποτελείται από πολλές επαναλήψεις.

Εικόνα 12
Προσαρμογή διαδικασίας ανάλυσης και σχεδίασης και η περίπτωση ανάπτυξης
(Development Case)
Προαιρετικά έγγραφα
Μερικές αρχές και πρακτικές που εφαρμόζονται στην Ενοποιημένη Διεργασία (UP)
είναι αμετάβλητες, όπως η επαναληπτική και η κίνδυνο-καθοδηγημένη ανάπτυξη, και η
συνεχής επαλήθευση της ποιότητας.
Εντούτοις, με μια διορατική ματιά στην Ενοποιημένη Διεργασία (UP) γίνεται φανερό
ότι όλες οι δραστηριότητες και τα έγγραφα (πρότυπα, διαγράμματα, κείμενα,…) είναι
προαιρετικά-καλά, ίσως όχι ο κώδικας! Το πιθανό σύνολο των εγγραφών που περιγράφονται
στον Ενοποιημένη Διεργασία (UP) πρέπει να αντιμετωπισθούν όπως ένα σύνολο φαρμάκων
στο φαρμακείο. Ακριβώς όπως κάποιος δεν παίρνει αδιακρίτως πολλά φάρμακα, αλλά κάνει
τις επιλογές που ταιριάζουν με την ασθένεια που έχει, έτσι και σε ένα project όπου
χρησιμοποιείται η Ενοποιημένη Διεργασία (UP), μια ομάδα πρέπει να επιλέξει ένα μικρό
υποσύνολο των εγγράφων που καλύπτουν το συγκεκριμένο προβλήματα και τις ιδιαίτερες
ανάγκες. Γενικά, θα πρέπει να γίνεται εστίαση σε ένα μικρό σύνολο εγγραφών της
Ενοποιημένης Διεργασίας που έχουν υψηλή πρακτική αξία.
Η περίπτωση ανάπτυξης (Development Case)
Η επιλογή των εγγράφων της Ενοποιημένης Διεργασίας (UP) που είναι απαραίτητα για
ένα project μπορεί να καταχωρηθεί γραπτώς σε ένα σύντομο έγγραφο που ονομάζεται
περίπτωση ανάπτυξης (Development Case). Για το παράδειγμα, ο πίνακας 2.1 θα μπορούσε
Παπαγιαννόπουλος Νικόλαος Πορφυριάδης Νικόλαος

22
να είναι η περίπτωση ανάπτυξης (Development Case) που περιγράφει τα έγγραφα για το
project «NextGen» που θα είναι το παράδειγμα για αυτό άλλα και για τα επόμενα κεφάλαια
του κειμένου αυτού. Τα επόμενα κεφάλαια του κειμένου περιγράφουν τη δημιουργία μερικών
από αυτά τα έγγραφα, μέσα στα οποία περιλαμβάνεται το Εννοιολογικό μοντέλο (Domain
Model), το μοντέλο περιπτώσεων χρήσης (usecase diagrams, προδιαγραφές περιπτώσεων
χρήσης και διαγράμματα ακολουθίας συστήματος), και το σχεδιαστικό μοντέλο (class
diagrams).


Εικόνα 13
Η Ενοποιημένη Διεργασία (UP) είναι εύκαμπτη
Οι ειδικοί στην ανάπτυξη και σχεδίαση λογισμικού μιλούν για τις διαδικασίες ανάλυσης
και σχεδίασης με χαρακτηρισμούς όπως ‘βαριά’ εναντίον ‘ελαφριάς’, και ‘προφητική’
εναντίον ‘προσαρμοστικής’. Μια βαριά διαδικασία είναι ένας μειωτικός όρος που
χρησιμοποιείται για να περιγράψει μια διαδικασία ανάπτυξης και σχεδίασης με τις
ακόλουθες ιδιότητες:
Πολλά έγγραφα που δημιουργούνται σε μια γραφειοκρατική ατμόσφαιρα
• Ακαμψία και έλεγχος
• Αναλυτικός, μακροπρόθεσμος και λεπτομερής σχεδιασμός.
• Προφητική (προσπαθεί να προβλέψει τις απαιτήσεις) παρά προσαρμοστική
(προσαρμογή στις νέες απαιτήσεις) διαδικασία

Μια προφητική διαδικασία προσπαθεί να προγραμματίσει και να προβλέψει τις
δραστηριότητες και τις κατανομές των πόρων (άνθρωποι) λεπτομερώς σε έναν μεγάλο
χρονικό ορίζοντα. Κάτι τέτοιο συμβαίνει στην πλειοψηφία των project. Οι προφητικές
διαδικασίες έχουν συνήθως ως κύκλο ζώνης έναν «καταρράκτη» ή έναν ακολουθιακό κύκλο
ζωής. Πρώτα, καθορίζονται όλες τις απαιτήσεις, μετά γίνεται ένας λεπτομερής σχεδιασμός
και τέλος ο σχεδιασμός υλοποιείται. Αντίθετα, μια προσαρμοστική διαδικασία δέχεται τις
αλλαγές ως αναπόφευκτο οδηγό και ενθαρρύνει την εύκαμπτη προσαρμογή. Συνήθως τέτοιου
είδους διαδικασίες ανάπτυξης και σχεδίασης έχουν έναν επαναληπτικό κύκλο ζωής. Μια
εύκαμπτη διαδικασία ανάπτυξης και σχεδίασης υπονοεί μια ελαφριά και προσαρμοστική
διαδικασία, που απαντάει με ευκινησία στις μεταβαλλόμενες ανάγκες. Η Ενοποιημένη
Διεργασία (UP) δεν δημιουργήθηκε για να είναι ούτε βαριά ούτε προφητική, αν και ο
Παπαγιαννόπουλος Νικόλαος Πορφυριάδης Νικόλαος

23
μεγάλος προαιρετικών δραστηριοτήτων που περιλαμβάνει καθώς και τα έγγραφα που τις
συνοδεύουν μπορεί να οδηγήσει δικαιολογημένα σε αντίθετα συμπεράσματα.
Γλώσσα μοντελοποίησης-UML
Η UML
Η ενοποιημένη γλώσσα μοντελοποίησης (UML Unified Modeling Language) είναι μια
γλώσσα για το προσδιορισμό, την εικονική αναπαράσταση, την κατασκευή, και την
τεκμηρίωση των αντικειμένων των συστημάτων λογισμικού, καθώς επίσης και για τη
μοντελοποίηση εργασιών και άλλων συστημάτων που δεν έχουν να κάνουν με λογισμικό.
H UML θεωρείται ως η καλύτερη τυποποιημένη διαγραμματική σημειογραφία για την
αντικειμενοστραφή μοντελοποίηση. Ξεκίνησε σαν μια προσπάθεια από τον Grady Booch και
τον Jim Rumbaugh το 1994 για να συνδυάζει τις διαγραμματικές σημειογραφίες, από τις
δύο δημοφιλείς μεθόδους τους, την Booch και τη μέθοδο OMT (Object Modeling Technique,
τεχνική διαμόρφωσης αντικειμένου). Συνεργάστηκαν αργότερα με τον Ivar Jacobson, το
δημιουργό της μεθόδου Objectory , και σαν ομάδα έγιναν γνωστοί ως οι τρεις «amigos».
Πολλοί άλλοι συνέβαλαν στη UML. Ο πιο αξιοσημείωτος είναι ίσως ο Cris Kobryn. Η UML
υιοθετήθηκε το 1997 ως πρότυπο (standard) από την ομάδα OMG (Object Management
Group, μια βιομηχανία προτύπων και συνέχισε να επανακαθορίζεται στις νέες εκδόσεις OMG
UML.
Στη συνέχεια της πτυχιακής εργασίας εμφανίζονται διαγράμματα και έγγραφα που
περιγράφονται από τη γλωσσά UML χωρίς να γίνεται περεταίρω ανάλυση του τρόπου
δημιουργίας τους. Η σκοπιμότητα τους επίσης θεωρείται προφανής και περιγράφεται
περιληπτικά. Ο αναγνώστης μπορεί να ανατρέξει στα εγχειρίδια της γλωσσάς UML για
περισσότερες πληροφορίες σχετικά με αυτή την γλώσσα μοντελοποίησης.
3

ΣΗΜΕΙΩΣΗ Τα διαγράμματα περιπτώσεων χρήσης τα διαγράμματα ακολουθίας, τα
διαγράμματα εννοιολογικών κλάσεων, τα διαγράμματα κλάσεων και γενικά όποια άλλη
τεχνική περιγράφεται από την UML δεν αναλύεται στον παρόν έγγραφο παρά μονό συμφωνά
με τη UML σημειογραφία, δημιουργούνται τα διαγράμματα που παρουσιάζονται παρακάτω.
Τα διαγράμματα αυτά είναι απαραίτητα για την ανάλυση και σχεδίαση της εφαρμογής και
είναι απαραίτητα βήματα πριν την συγγραφή κώδικα. Για γενικές πληροφορίες σχετικά με
τον τρόπο δημιουργίας των διαγραμμάτων και για εγχειρίδια χρήσης της UML o αναγνώστης
παραπέμπεται στην βιβλιογραφία
4
Ως εργαλείο εφαρμογής της γλωσσάς μοντελοποίησης
UML χρησιμοποιήθηκε το εργαλείο Visual Paradigm. Ο αναγνώστης παραπέμπεται στα
εγχειρίδια χρήσης του εργαλείου που υπάρχουν στο ίντερνετ και στην βιβλιογραφία
5
.


3
Martin Fowler & Kendall Scott Εισαγωγή στην UML Εκδόσεις Κλειδάριθμος ISBN 960-209-481-8
4
Εργαλείο εφαρμογής της γλώσσας μοντελοποίησης-Visual Paradigm
5
http://www.visual-
paradigm.com/edocs.jsp?url=content/product/vpuml/vpuml5UserGuide2/pdf/vpuml_user_guide2.pdf&resourceT
ype=document&resourceDetail=vpuml5UserGuide&preferedSite=http://206.222.18.10/resources

http://www.visual-
paradigm.com/edocs.jsp?url=content/product/vpuml/vpuml5UserGuide/pdf/vpuml_user_guide.pdf&resourceTyp
e=document&resourceDetail=vpuml5UserGuide&preferedSite=http://206.222.18.10/resources

Παπαγιαννόπουλος Νικόλαος Πορφυριάδης Νικόλαος

24

H γλώσσα προγραμματισμού JAVA
6

Εισαγωγή
Όσοι ασχολούνται με τον προγραμματισμό, επαγγελματίες και μη, έχουνε
ακούσει για τη γλώσσα προγραμματισμού Java. Όλα ξεκίνησαν από τη διάσημη
εταιρία στο χώρο της πληροφορικής Sun Microsystems. Στις αρχές του 1991
όταν στη Sun αναζητούσαν το κατάλληλο εργαλείο για ν' αποτελέσει την
πλατφόρμα ανάπτυξης λογισμικού σε μικρό-συσκευές (έξυπνες οικιακές
συσκευές έως πολύπλοκα συστήματα παραγωγής γραφικών). Τα εργαλεία της
εποχής τα οποία πέρασαν από την «πασαρέλα» των υποψηφίων ήταν γλώσσες
όπως η C++ και η C. Μετά από διάφορους πειραματισμούς αποφάνθηκαν ότι οι
υπάρχουσες γλώσσες δεν μπορούσαν να καλύψουν τις ανάγκες τους! Ο πατέρας
της Java, James Gosling που εργαζόταν εκείνη την εποχή για την Sun, έκανε ήδη
πειραματισμούς πάνω στη C++ και είχε παρουσιάσει κατά καιρούς κάποιες πειραματικές
γλώσσες(C++ ++) ως πρότυπα για το νέο εργαλείο που αναζητούσαν στην Sun. Τελικά μετά
από λίγο καιρό κατέληξαν με μια πρόταση για το επιτελείο της εταιρίας, ήταν η γλωσσά Oak.
Το όνομά της το πήρε από το ομώνυμο δένδρο (βελανιδιά) το οποίο ο Gosling είχε έξω από
το γραφείο του και έβλεπε κάθε μέρα!

Από την Oak στη Java
H Oak ήταν μία γλώσσα που διατηρούσε μεγάλη συγγένεια με την C++. Παρόλα αυτά
είχε πολύ πιο έντονο αντικειμενοστραφή χαρακτήρα σε σχέση με την C++ και
χαρακτηριζόταν για την απλότητα της. Σύντομα οι υπεύθυνοι ανάπτυξης της νέας γλώσσας
ανακάλυψαν ότι το όνομα Oak ήταν ήδη κατοχυρωμένο οπότε
κατά την διάρκεια μίας εκ' των πολλών συναντήσεων σε κάποιο
τοπικό καφενείο αποφάσισαν να μετονομάσουν το νέο τους
δημιούργημα σε Java που εκτός των άλλων ήταν το όνομα
αγαπητού καφέ για τους δημιουργούς της (Java στην αγγλική
γλώσσα είναι το φυτό που βγάζει τον καφέ)! Η επίσημη εμφάνιση
της Java αλλά και του HotJava (πλοηγός με υποστήριξη Java) στη
βιομηχανία της πληροφορικής έγινε το Μάρτιο του 1995 όταν η
Sun την ανακοίνωσε στο συνέδριο Sun World 1995. O πρώτος
μεταγλωττιστής (compiler) της ήταν γραμμένος στη γλώσσα C
από τον James Gosling. Το 1994 ο Van Hoffman ξαναγράφει τον
αποδελτίωση της γλώσσας σε Java (από τα πλέον δύσκολα
επιτεύγματα στο χώρο της πληροφορικής είναι να γράψεις έναν
αποδελτίωση μίας γλώσσας στην ίδια τη γλώσσα), ενώ το
Δεκέμβριο του 1995 πρώτες οι IBM, Borland, Mitsubishi
Electronics, Sybase και Symantec ανακοινώνουνε σχέδια να χρησιμοποιήσουν τη Java για
την δημιουργία λογισμικού. Από εκεί και πέρα η Java ακολουθεί μία ανοδική πορεία και είναι
πλέον μία από τις πιο δημοφιλείς γλώσσες στον χώρο της πληροφορικής.
Τα χαρακτηριστικά της Java
Τι κάνει όμως τη Java τόσο δημοφιλή; Ένα από τα βασικά πλεονεκτήματα της Java
έναντι των περισσότερων άλλων γλωσσών είναι η ανεξαρτησία του λειτουργικού συστήματος


6
http://javahellug.org/tutorials/JavaIntroduction.html

Παπαγιαννόπουλος Νικόλαος Πορφυριάδης Νικόλαος

25
και πλατφόρμας. Τα προγράμματα που είναι γραμμένα σε Java τρέχουνε ακριβώς το ίδιο σε
Windows, Linux, Unix και Macintosh (σύντομα θα τρέχουνε και σε Playstation καθώς και σε
άλλες παιχνιδομηχανές) χωρίς να χρειαστεί να ξαναγίνει διάταξη αποδελτίωσης (compiling) ή
να αλλάξει ο πηγαίος κώδικας για κάθε διαφορετικό λειτουργικό σύστημα. Για να επιτευχθεί
όμως αυτό χρειαζόταν κάποιος τρόπος έτσι ώστε τα προγράμματα γραμμένα σε Java να
μπορούν να είναι «κατανοητά» από κάθε υπολογιστή ανεξάρτητα του είδους επεξεργαστή
(Intel x86, IBM, Sun SPARC, Motorola) αλλά και λειτουργικού συστήματος (Windows,
Unix, Linux, Unix, MacOS). Ο λόγος είναι ότι κάθε κεντρική μονάδα επεξεργασίας μπορεί
και «καταλαβαίνει» διαφορετικό assembly κώδικα. Ο συναρμολογούμενος (assembly)
κώδικας που τρέχει σε Windows είναι διαφορετικός από αυτόν που τρέχει σε ένα Macintosh.
Η λύση δόθηκε με την ανάπτυξη της Εικονικής Μηχανής (Virtual Machine ή VM ή ΕΜ στα
ελληνικά).
H εικονική μηχανή της Java
Τι κάνει λοιπόν το Java Virtual Machine; Αφού γραφτεί κάποιο πρόγραμμα σε Java
τότε γίνεται compile μέσω του Java compiler (javac), εκείνος με την σειρά του δίνει ένα
αριθμό από .class αρχεία (=bytocode. Το bytecode είναι η μορφή που παίρνει ο πηγαίος
κώδικας της Java όταν έρθει σε μία διάταξη αποδελτίωσης) αναλόγως με το πόσες κλάσεις
έχουνε γραφτεί για την εφαρμογή. Όταν προσπαθήσουμε λοιπόν να εκτελέσουμε την
εφαρμογή μας το Java Virtual Machine που πρέπει να είναι εγκατεστημένο στο μηχάνημά
μας, θα αναλάβει να διαβάσει τα .class αρχεία και να τα μεταφράσει σε γλώσσα και εντολές
(assembly) που υποστηρίζει το λειτουργικό μας και ο επεξεργαστής μας, έτσι ώστε να
εκτελεστεί (να σημειώσουμε εδώ ότι αυτό συμβαίνει με την παραδοσιακή Εικονική Μηχανή
(Εικόνα 1). Πιο σύγχρονες εφαρμογές της ΕΜ μπορούνε και αποδελτιώνουνε τα πολύχρυσα
τμήματα bytecode απ' ευθείας σε ιθαγενή κώδικα (native code) με αποτέλεσμα να
βελτιώνεται η ταχύτητα). Χωρίς αυτό δε θα ήταν δυνατή η εκτέλεση λογισμικού γραμμένο σε
Java. Πρέπει να πούμε ότι το Virtual Machine είναι λογισμικό platform specific δηλαδή για
κάθε είδος λειτουργικού και ανάλογης τεχνολογίας επεξεργαστή, υπάρχει διαφορετική
έκδοση. Έτσι υπάρχουν διαθέσιμες εκδόσεις του για Windows, Linux, Unix, Macintosh,
κινητά τηλέφωνα, παιχνιδομηχανές και άλλες ηλεκτρονικές συσκευές.


Εικόνα 15
Οτιδήποτε θέλει να κάνει ο προγραμματιστής (ή ο χρήστης) γίνεται μέσω της εικονικής
μηχανής. Αυτό βοηθάει στο να υπάρχει μεγαλύτερη ασφάλεια στο σύστημα γιατί η εικονική
μηχανή είναι υπεύθυνη για την επικοινωνία χρήστη - υπολογιστή. Ο προγραμματιστής δεν
μπορεί να γράψει κώδικα ο οποίος θα έχει καταστροφικά αποτελέσματα για τον υπολογιστή
γιατί η εικονική μηχανή θα τον ανιχνεύσει και δε θα επιτρέψει να εκτελεστεί. Από την άλλη
μεριά ούτε ο χρήστης μπορεί να κατεβάσει «κακό» κώδικα από το δίκτυο και να τον τρέξει.
Αυτό είναι ιδιαίτερα χρήσιμο για μεγάλα διανεμημένα συστήματα όπου πολλοί χρήστες
χρησιμοποιούνε το ίδιο πρόγραμμα συγχρόνως.
Παπαγιαννόπουλος Νικόλαος Πορφυριάδης Νικόλαος

26
Ο συλλέκτης σκουπιδιών (Garbage Collector)
Ακόμα μία ιδέα που βρίσκεται πίσω από τη Java είναι η ύπαρξη του συλλέκτη
σκουπιδιών (Garbage Collector). Συλλέξει σκουπιδιών είναι μία κοινή ονομασία που
χρησιμοποιείται στον τομέα της πληροφορικής για να δηλώσει την ελευθέρωση τμημάτων
μνήμης από δεδομένα που δε χρειάζονται και δε χρησιμοποιούνται άλλο. Αυτή η
απελευθέρωση μνήμης στη Java είναι αυτόματη και γίνεται μέσω του συλλέκτη
απορριμμάτων. Υπεύθυνη για αυτό είναι και πάλι η εικονική μηχανή η οποία μόλις
«καταλάβει» ότι η στοίβα (heap) της μνήμης (στη Java η συντριπτική πλειοψηφία των
αντικειμένων αποθηκεύονται τη στοίβα σε αντίθεση με τη C++ που αποθηκεύονται κυρίως
στο σωρό - stack) κοντεύει να γεμίσει ενεργοποιεί το συλλέκτη απορριμμάτων. Έτσι ο
προγραμματιστής δε χρειάζεται να ανησυχεί για το πότε και αν θα ελευθερώσει ένα
συγκεκριμένο τμήμα της μνήμης, ούτε και για δείκτες (pointers) που εστιάζουνε σε άδειο
κουτάκι μνήμης. Αυτό είναι ιδιαίτερα σημαντικό αν σκεφτούμε ότι ένα μεγάλο ποσοστό
κατάρρευσης των προγραμμάτων οφείλονται σε λάθος χειρισμό της μνήμης.
Επιδόσεις
Πάντως τίποτα σε αυτόν τον κόσμο δεν έρχεται χωρίς κόστος. Έτσι λοιπόν, παρόλο που
η εικονική μηχανή προσφέρει όλα αυτά (και όχι μόνο) τα πλεονεκτήματα, η Java είναι πιο
αργή σε σχέση με άλλες προγραμματιστικές γλώσσες υψηλού επιπέδου (high-level) όπως η C
και η C++. Έχει αποδειχτεί ότι η C++ μπορεί να είναι αρκετές φορές γρηγορότερη από τη
Java. Ευτυχώς γίνονται φιλότιμες προσπάθειες από τη Sun για τη βελτιστοποίηση της
εικονικής μηχανής, ενώ και διάφορες άλλες πραγματοποιήσεις της εικονικής μηχανής
υπάρχουνε από διάφορες άλλες εταιρίες (όπως IBM) οι οποίες μπορεί σε κάποια σημεία να
προσφέρουνε καλύτερα και σε κάποια άλλα χειρότερα αποτελέσματα. Επιπλέον με τον
ερχομό των JIT (Just In Time) compilers, οι οποίοι μετατρέπουνε το bytecode απ' ευθείας σε
γλώσσα μηχανής, η διαφορά ταχύτητας από τη C++ έχει μικρύνει κατά πολύ.
Εργαλεία ανάπτυξης
Όλα τα εργαλεία που χρειάζεται κάποιος για να γράψει Java προγράμματα έρχονται
δωρεάν. Από περιβάλλον ανάπτυξης μέχρι build εργαλεία και βιβλιοθήκες. Ευτυχώς η Sun
και οι υπόλοιπες εταιρίες είναι αρκετά γενναιόδωρες ώστε να μας τα παρέχουνε χωρίς
χρέωση. Όπως είπαμε και πιο πάνω υπάρχουνε πολλές διαφορετικές εφαρμογές της Εικονικής
Μηχανής και του compiler της Java. Είναι στο χέρι του καθενός να επιλέξει το κατάλληλο
περιβάλλον. Πάντως ο δικτυακός τόπος της Sun είναι ένα καλό σημείο για να αρχίσει
κάποιος. Η Εικονική Μηχανή και ο compiler μπορούνε να βρεθούνε στην παρακάτω
διεύθυνση όπου θα συνιστούσαμε να κατεβάσετε τις τελευταίες εκδόσεις (1.4.2 τη στιγμή του
γραψίματος αυτού του κειμένου) καθώς και τα συνοδευτικά έγγραφα (documentation) διότι
είναι αρκετά κατατοπιστικά. Προσοχή, και τα τρία αρχεία είναι αρκετά μεγάλα σε μέγεθος,
οπότε χρήστες με αργή σύνδεση θα πρέπει να περιμένουνε ώρα.
Σύνθετο περιβάλλον ανάπτυξης (IDE)
Για να γράψει κάποιος Java κώδικα δε χρειάζεται τίποτα άλλο παρά έναν επεξεργαστή
κειμένου όπως notepad ή emacs αλλά ένα ολοκληρωμένο περιβάλλον ανάπτυξης βοηθάει
πολύ, ιδιαίτερα στον εντοπισμό σφαλμάτων. Υπάρχουνε αρκετά διαθέσιμα, πολλά από αυτά
έρχονται δωρεάν. Μερικά από αυτά είναι το JCreator (Windows μόνο), το JEdit, το Eclipse
και ο JBuilder.
Παπαγιαννόπουλος Νικόλαος Πορφυριάδης Νικόλαος

27
Τι είναι το Java applet
7

Ένα Applet είναι ένα πρόγραμμα Java το οποίο εκτελείται σε μία ιστοσελίδα. Τα βήματα που
πρέπει να κάνετε για να δημιουργήσετε ένα Java Applet είναι τα ακόλουθα:
• Πρώτα γράφετε το Applet ακριβώς όπως γράφετε και κάθε άλλο πρόγραμμα Java.
• Στη συνέχεια μεταφράζετε το Applet για να παράγετε το αρχείο με επέκταση class με
τα bytecodes
• Τέλος, ενσωματώνετε το Applet σε μία ιστοσελίδα χρησιμοποιώντας (κατ' ελάχιστο)
την ετικέτα <Applet> η οποία έχει την εξής (ελάχιστη) μορφή:
<applet code = όνομα-αρχείου.class width=πλάτος height=ύψος></applet>
Όπως βλέπετε η ετικέτα applet έχει τις υποχρεωτικές φράσεις code, width και height.
Το code προσδιορίζει το αρχείο που θα εκτελεστεί όταν θα φορτωθεί η ιστοσελίδα που
περιέχει την ετικέτα σε ένα browser. Το width προσδιορίζει το πλάτος που θα καταλάβει το
applet σε εικονοστοιχεία (pixels) στην περιοχή του browser και το height είναι το ύψος που
θα καταλάβει το applet σε pixels στην περιοχή του browser. Τέλος το </applet> τερματίζει
την ετικέτα Applet. Το Applet θα καταλάβει το χώρο αυτό στο σημείο που βρίσκετε στην
ιστοσελίδα. Ένα Applet εκτελείται όταν φορτώνεται η ιστοσελίδα που το περιέχει σε κάποιο
browser.
Όπως είναι προφανές από την πιο πάνω συζήτηση ένα Applet θα πρέπει να έχει μια
οπτική παράσταση για να μπορεί να εμφανιστεί σε μια ιστοσελίδα και να καταλάβει κάποιο
χώρο σε αυτή. Γι' αυτό το λόγο τα Applets είναι υποτάξεις της τάξης java.awt.Panel. Σαν
υπό-τάξη της τάξης Panel ένα Applet έχει διαστάσεις που μπορούν να καθοριστούν από την
μέθοδο setBounds και μπορεί να λειτουργήσει ως container άλλων παραθυρικών συστατικών
(windows components). Δηλαδή σε ένα Applet μπορούμε να έχουμε παραθυρικά συστατικά
όπως κουμπιά (buttons), πλαίσια ελέγχου (checkboxes) κ.λ.π. Αυτό που δεν μπορούμε να
έχουμε είναι μενού και αυτό διότι τα μενού προσαρτώνται μόνο σε παράθυρα (Frames) και
ένα Panel δεν είναι Frame. Το παρακάτω UML διάγραμμα παρουσιάζει την ιεραρχία τάξεων
που περιγράφτηκε πριν:

Εικόνα 16
Όπως παρατηρείτε ένα Applet παρότι επεκτείνει τη τάξη java.awt.Panel και επομένως
είναι java.awt.Container για να μπορεί να περιέχει όλα τα παραθυρικά συστατικά που θα


7
http://194.42.54.220/gkakaron/java/Day3/2.html

http://194.42.54.220/gkakaron/java/Day3/3.html

Παπαγιαννόπουλος Νικόλαος Πορφυριάδης Νικόλαος

28
αποτελέσουν την γραφική του εικόνα προς το χρήστη δεν ανήκει στο πακέτο java.awt αλλά
στο πακέτο java.Applet.
Πως γράφεται ένα Applet;
Ένα πρόγραμμα Java το οποίο θα χρησιμοποιηθεί σαν Applet θα πρέπει να επεκτείνει
(extend) την τάξη java.applet.Applet. Έτσι, συνήθως, κάνουμε import το πακέτο java.applet
όπως και το πακέτο java.awt σε κάθε Applet.
Ένα Applet έχει λοιπόν, συνήθως, την ακόλουθη γενική μορφή:
import java.awt.*;
import java.applet.*;
public class όνομα-τάξης-Applet extends Applet {
}
Ένα απλό Applet
Στα πρώτα μαθήματά μας είδαμε ένα Applet - το applet HelloWorld - το οποίο
εμφάνιζε στη περιοχή του Applet το μήνυμα HelloWorld!. Θα επαναλάβουμε αυτό το Applet
εδώ για να δούμε λίγο καλύτερα τα συστατικά του τώρα που γνωρίζουμε λίγα περισσότερα.
import java.applet.Applet;
import java.awt.Graphics;
public class HelloWorldApplet extends Applet {
public void paint(Graphics g) {
g.drawString("Hello world!", 50, 25);
}
}
Όπως βλέπουμε λοιπόν το Applet αυτό επεκτείνει τη τάξη java.applet.Applet. Επίσης
αντί να εισάγουμε με import όλο το πακέτο java.awt εισάγουμε μόνο τη τάξη
java.awt.Graphics που χρησιμοποιούμε για τη μέθοδο paint. Η μέθοδος paint είναι μια
μέθοδος της τάξης Container που είναι υπερτάξη της τάξης Panel που με τη σειρά της είναι
υπέρ-τάξη της τάξης Applet. Η μέθοδος αυτή καλείται αυτόματα όταν εμφανίζεται το Applet
και δουλειά της είναι να εμφανίσει το Container (δηλαδή το Applet) και όλα τα συστατικά
του στην οθόνη. Στη συγκεκριμένη περίπτωση αν δεν υπερβαίναμε (override) τη μέθοδο
paint το Applet μας θα ήταν ένα πολύ βαρετό Applet μια και δεν θα βλέπαμε απολύτως τίποτα
στη περιοχή του. Βεβαίως και τώρα που την υπερβαίνουμε δεν κάνει και τίποτα το
συγκλονιστικό. Το μόνο που κάνει είναι να εμφανίσει στην οθόνη τη φράση Hello World!.
Παρόλα αυτά μην ξεχνάτε ότι είμαστε ακόμα στην αρχή. Τα πράγματα θα γίνουνε πιο
ενδιαφέροντα στα επόμενα μαθήματα. Ίσως να απορείτε για το τι είναι η παράμετρος g που
είναι ένα αντικείμενο της τάξης java.awt.Graphics. Αυτή είναι, ουσιαστικά η περιοχή
σχεδίασης του Applet και διαθέτει μεθόδους που μας επιτρέπουν να γράφουμε, να
σχεδιάζουμε, να εμφανίζουμε εικόνες κ.λ.π. πάνω στην επιφάνεια του Applet όπως η
drawString που καλείται και εμφανίζει το String που δίνεται σαν πρώτη παράμετρος. Το
String αυτό εμφανίζεται χρησιμοποιώντας σαν την πάνω αριστερή γωνία τη θέση που
προσδιορίζεται από τις συντεταγμένες x και y που δίνονται σαν δεύτερη και τρίτη
παράμετρος αντίστοιχα.
Όταν, επομένως, φορτωθεί η ιστοσελίδα που θα περιέχει το πιο πάνω Applet, θα
εμφανιστεί η φράση "Hello World!" στη περιοχή του Applet. Αλλά πως περιλαμβάνουμε ένα
Applet σε μία ιστοσελίδα; Η απάντηση αυτή ήδη έχει δοθεί: Θα πρέπει να βάλουμε στην
ιστοσελίδα την ετικέτα <Applet> προσδιορίζοντας ως code το αρχείο class του Applet.
Η HTML που απαιτείται γι' αυτό δίνεται στη συνέχεια:
Παπαγιαννόπουλος Νικόλαος Πορφυριάδης Νικόλαος

29
<applet code="HelloWorldApplet.class" width=200 height=100> </applet>
Αν, λοιπόν, μεταφράσετε το HelloWorldApplet.java και γράψετε τη πιο πάνω γραμμή
σε ένα αρχείο με επέκταση html (ή htm) και στη συνέχεια φορτώσετε το αρχείο σε ένα
browser θα δείτε το applet να τρέχει και θα δείτε κάτι ανάλογο με αυτό που φαίνεται εδώ:
Μέθοδοι-Σταθμοί για ένα Applet
Σ' αυτό το μάθημα θα εξηγήσουμε τέσσερις μεθόδους-σταθμούς στη ζωή ενός Applet.
Τις μεθόδους: init(), start(), stop() και destroy(). Αυτές οι μέθοδοι καλούνται αυτόματα σε
διάφορα σημεία της ζωής ενός Applet και είναι χρήσιμο να καταλάβουμε τι σημαίνουν και
πως μπορούμε να τις χρησιμοποιήσουμε. Τέλος, θα δούμε ένα παράδειγμα της χρήσης τους.
Η μέθοδος init()
Στα applets συνήθως δεν έχει νόημα η κατασκευή κάποιου constructror
(κατασκευαστή) δηλαδή κάποιας μεθόδου που θα κατασκευάσει το Applet. Αυτό γιατί τα
αντικείμενα της τάξης αυτής δεν τα κατασκευάζουμε εμείς με την εντολή new αλλά τα
κατασκευάζει το σύστημα εκτέλεσης (java runtime system) σαν αποτέλεσμα της φόρτωσης
της σελίδας η οποία περιέχει το Applet σε ένα πρόγραμμα πλοήγησης (browser) με
δυνατότητες Java (java-enabled browser). Παρόλα αυτά είναι πολύ πιθανόν να θέλουμε να
κάνουμε κάποιες αρχικοποιήσεις όταν φορτωθεί το Applet για πρώτη φορά. Αυτό
επιτυγχάνεται με την μέθοδο init(), η οποία πρέπει να έχει την ακόλουθη γενική μορφή:
public void init() {
εντολές αρχικοποίησης του Applet
}
Η κλήση της init όπως ήδη ανέφερα δεν γίνεται από εμάς αλλά από το σύστημα
εκτέλεσης κάθε φορά που φορτώνεται η σελίδα που περιέχει το Applet για πρώτη φορά από
ένα πρόγραμμα πλοήγησης.
Η μέθοδος start()
Η μέθοδος start() μπορείτε να φανταστείτε ότι είναι κάτι ανάλογο με την main(). Μας
δίνει δηλαδή τη δυνατότητα να ξεκινήσουμε κάποιες επεξεργασίες αφού φορτωθεί το Applet.
Το Applet βέβαια συνήθως, θα παρέχει μία γραφική διεπαφή χρήστη (ένα Graphical User
Interface - GUI) με τη χρήση της οποίας ο χρήστης θα μπορεί να κάνει κάποιες ενέργειες. Το
περιβάλλον εκτέλεσης ενός Applet είναι δηλαδή οδηγούμενο από συμβάντα τα οποία
προκαλεί ο χρήστης (event-driven). Έτσι μπορεί η μέθοδος start να μην απαιτείται και
καθόλου αν δεν θέλουμε να ξεκινήσει καμία επεξεργασία και θέλουμε να γίνουν όλα μόλις ο
χρήστης προκαλέσει τα κατάλληλα συμβάντα (για παράδειγμα πατήσει ένα κουμπί - button).
Η μέθοδος start() θα πρέπει να έχει την ακόλουθη μορφή:
public void start() {
ενέργειες που γίνονται μόλις ξεκινά το Applet
}
Όπως και η μέθοδος init έτσι και η μέθοδος start καλείται αυτομάτως από το σύστημα
εκτέλεσης. Η διαφορά τους βρίσκεται στο ότι η μέθοδος start καλείται και τη πρώτη φορά
που θα φορτωθεί το Applet, αλλά και τις επόμενες που ο χρήστης θα επιστρέψει στη σελίδα
με το Applet με το πλήκτρο "Back" του προγράμματος πλοήγησης και η σελίδα εμφανιστεί
στο παράθυρο του προγράμματος πλοήγησης και πάλι.
Η μέθοδος stop()
Παπαγιαννόπουλος Νικόλαος Πορφυριάδης Νικόλαος

30
Η μέθοδος stop() καλείται από το σύστημα εκτέλεσης κάθε φορά που ο χρήστης φεύγει
από τη σελίδα που περιέχει το Applet είτε για να πάει σε κάποια άλλη σελίδα είτε για να πάει
σε κάποιο άλλο πρόγραμμα.
Η μορφή της μεθόδου stop() είναι η ακόλουθη:
public void stop() {
ενέργειες που γίνονται μόλις σταματά το Applet
}
Η μέθοδος destroy()
Η μέθοδος destroy() καλείται κάθε φορά που τερματίζεται η εκτέλεση του Applet
συνήθως σαν αποτέλεσμα του κλεισίματος του προγράμματος πλοήγησης στο οποίο έχει
φορτωθεί η σελίδα με το Applet και χρησιμοποιείται για ενδεχόμενες τελικές ενέργειες που
μπορεί να θέλουμε να συμβούν λίγο πριν σταματήσει το Applet να εκτελείται.
Η μέθοδος αυτή έχει τη μορφή:
public void destroy() {
εντολές για τελικές ενέργειες πριν σταματήσει η εκτέλεση του Applet
}
Ένα παράδειγμα
Το ακόλουθο Appet εμφανίζει το πλήθος των φορών που κλήθηκαν η init(), η start(), η
stop() και η destroy().
Θα πρέπει να διευκρινίσουμε ότι το τι ακριβώς θα δείτε στο πιο πάνω Applet εξαρτάται
και από το πρόγραμμα πλοήγησης στο οποίο βλέπετε τη σελίδα και από το πότε ακριβώς
καλεί τις μεθόδους start και stop. Δεν έχουν όλα τα προγράμματα πλοήγησης την ίδια
συμπεριφορά σ' αυτό το σημείο. Το σίγουρο είναι ότι θα δείτε ότι η μέθοδοι init και start θα
πρέπει να κλήθηκαν από μια φορά όταν φορτώσατε τη σελίδα. Πάντως αν θέλετε να
βεβαιωθείτε για την ορθότητα του κώδικά σας μπορείτε να δοκιμάσετε το Applet με τον
appletviewer ο οποίος στο μενού "Applet" έχει τις επιλογές Start και Stop που ξεκινάνε και
σταματάνε το Applet αντίστοιχα, όπως δείχνει και η ακόλουθη εικόνα:

Εικόνα 17
Ο κώδικας του πιο πάνω Applet είναι ο ακόλουθος:
import java.applet.*;
import java.awt.*;
public class Milestones extends Applet {
int timesInitialized, timesStarted, timesStopped, timesDestroyed;
private String composeString()
{
Παπαγιαννόπουλος Νικόλαος Πορφυριάδης Νικόλαος

31
return "Init: "+timesInitialized+
", Start: "+timesStarted+
", Stop: "+timesStopped+
", Destroyed: "+timesDestroyed;
}
public void destroy()
{
timesDestroyed++;
repaint();
}
public void init()
{
timesInitialized = 1;
timesStarted = 0;
timesStopped = 0;
timesDestroyed = 0;
repaint();
}
public void paint(Graphics g)
{
g.drawString(composeString(), 20, 20);
}
public void start()
{
timesStarted++;
repaint();
}
public void stop()
{
timesStopped++;
repaint();
}
}
Παρατηρείστε ότι μέσα σε κάθε μέθοδο (init, start, stop και destroy) καλούμε τη
μέθοδο repaint αφού αυξήσουμε τον αντίστοιχο μετρητή. Η repaint θα προκαλέσει τη κλήση
της paint που με τη σειρά της "γράφει" στις συντεταγμένες (20, 20) το String που επιστρέφει
η ιδιωτική μέθοδος composeString που συνθέτει το String που βλέπουμε στην οθόνη.
Για να δούμε το Applet να τρέχει σε ένα browser ή με τον appletviewer θα πρέπει να
κατασκευάσουμε και μία HTML σελίδα που να περιέχει την ετικέτα <Applet>. Για
παράδειγμα ένα αρχείο με την ακόλουθη γραμμή και την επέκταση html θα αρκούσε γι' αυτό:
<APPLET CODE=Milestones.class WIDTH=300 HEIGHT=100></APPLET>
Το εργαλείο ανάπτυξης Netbeans IDE
8

Το πρόγραμμα ανάπτυξης λογισμικού (development tool) Net Beans προσφέρεται
δωρεάν από την εταιρεία που δημιούργησε την Java, Sun. Σκοπός του προγράμματος είναι να
προσφέρει στον προγραμματιστή μια γραφική διεπιφάνεια αλληλεπίδρασης με την γλώσσα
με σκοπό να κάνει την ανάπτυξη εφαρμογών με Java μια πιο εύκολη εργασία.
Συνεπώς ο συνδυασμός Java και Net Beans θα μπορούσε να χαρακτηριστεί ως Visual
Java παραφράζοντας την ορολογία της Microsoft για το αντίστοιχο εργαλείο που έχει για την
Basic την δηλαδή την Visual Basic. Αναλυτικά εγχειρίδια αναφοράς και οδηγίες χρήσεως του
Net Beans μπορείτε να βρείτε στην ιστοσελίδα [1], εδώ παρέχουμε κάποια βασικά στοιχεία


8
http://www.netbeans.org/files/documents/40/718/UsingNetBeans5.0.pdf

Παπαγιαννόπουλος Νικόλαος Πορφυριάδης Νικόλαος

32
για το πως μπορεί ο χρήστης να δημιουργήσει μία GUI (Graphical User Interface – Οπτική)
εφαρμογή σε java.
Το NetBeans είναι ένα πρόγραμμα ανοιχτού κώδικα αφιερωμένο στο να παρέχει
προϊόντα ανάπτυξης λογισμικού όπως το NetBeans IDE τα οποία καλύπτουν τις ανάγκες των
προγραμματιστών και των επιχειρήσεων που χρησιμοποιούν το NetBeans ως βάση για τα
προϊόντα τους. Επίσης το πρόγραμμα NetBeans είναι και μία δραστήρια κοινότητα, όπου οι
άνθρωποι από όλο τον κόσμο έχουν την ικανότητα να κάνουν ερωτήσεις, να δίνουν
συμβουλές, να συμμετέχουν με διάφορους τρόπους και να μοιράζονται την επιτυχία των
προϊόντων τους.
Τον Ιούνιο του 2000 το NetBeans δημιουργήθηκε από την Sun Microsystems ως
πρόγραμμα ανοιχτού κώδικα και η οποία παραμένει χορηγός αυτού του προγράμματος.
Το NetBeans IDE είναι δωρεάν για εμπορική ή μη χρήση. Ο πηγαίος κώδικας είναι
διαθέσιμος για τον καθένα προς επαναχρησιμοποίηση.
Το NetBeans IDE έχει πολλές δυνατότητες για την ανάπτυξη διαφόρων εφαρμογών
όπως, γενικές εφαρμογές σε Java, δικτυακές εφαρμογές, δικτυακές υπηρεσίες,
επιχειρηματικές εφαρμογές, εφαρμογές σε J2ME (Java 2 Micro Edition).
Στην δική μας περίπτωση το NetBeans IDE χρησιμοποιήθηκε για την κατασκευή του
GUI, δηλαδή εκείνων των κομματιών που είναι εμφανή στο χρήστη. Σε αυτά
περιλαμβάνονται ο server (βλέπε ... σελίδα) ο οποίος είναι μία εφαρμογή που τρέχει
αυτόνομα στον υπολογιστή καθώς και τα applets που είναι επίσης εφαρμογές που τρέχουν
όμως μέσο ενός browser – φυλλομετρητή (πχ. Internet Explorer).
Εκτός των οπτικών μερών του προγράμματος στο NetBeans IDE αναπτύχθηκε και το
υπόλοιπο πρόγραμμα λόγω των πολλών δυνατοτήτων και ευκολιών που προσφέρει.
Συνοπτικός οδηγός δημιουργίας Applet στο NetBeans IDE
Δημιουργείστε το πρόγραμμα (project) εξ’ αρχής.
1. Επιλέγουμε File > New Project (Ctrl-Shift-N). Στις κατηγορίες, επιλέξτε General.
2. Επιλέξτε Java Class Library κάτω από το Projects, πατήστε Επόμενο.
3. Στο πεδίο Project Name, πληκτρολογήστε το HelloApplet και καθορίστε την
τοποθεσία του προγράμματος.
4. Πατήστε Τέλος (Finish).
Δημιουργήστε το αρχείο πηγαίου κώδικα του applet
1. Πατήστε δεξί-κλικ στον κόμβο του προγράμματος που μόλις φτιάξατε, στο παράθυρο
των προγραμμάτων και επιλέξτε New File/Folder (Ctrl-N).
2. Στις κατηγορίες, επιλέξτε Java Classes. Στους Τύπους Αρχείων επιλέξτε Applet.
Πατήστε Επόμενο.
3. Στο πεδίο Class Name, πληκτρολογήστε MyApplet.. Στο πεδίο package, γράψτε
org.me.hello.
4. Πατήστε Τέλος.
Το IDE θα δημιουργήσει τον πηγαίο κώδικα του applet στο καθορισμένο πακέτο. Το
αρχείο με τον πηγαίο κώδικα του applet ανοίγει στον Source Editor.
5. Ορίστε την κλάση του applet αντιγράφοντας και επικολλώντας τον παρακάτω κώδικα:
package org.me.hello;

import java.applet.Applet;
import java.awt.Graphics;

public class MyApplet extends Applet {
Παπαγιαννόπουλος Νικόλαος Πορφυριάδης Νικόλαος

33
public void paint(Graphics g) {
g.drawString("Hello applet!", 50, 25);
}
}
Κατασκευή και εκτέλεση του applet
1. Πατήστε δεξί-κλικ στον κόμβο του HelloApplet στο παράθυρο των προγραμμάτων
και επιλέξετε Build Project από το συναφή μενού.
2. Δημιουργήθηκε το HelloApplet.jar στον φάκελο dist.
3. Πατήστε δεξί-κλικ στον κόμβο της κλάσης το παράθυρο των προγραμμάτων και
επιλέξτε Run File από το συναφή μενού.
Δημιουργήθηκε το MyApplet.html, το οποίο ενσωματώνει το applet, στον φάκελο build
και εκκινήθηκε στον Applet Viewer.


Εικόνα 18
Αποσφαλμάτωση του applet τροποποιώντας τις παραμέτρους του
Παπαγιαννόπουλος Νικόλαος Πορφυριάδης Νικόλαος

34
Το αρχείο MyApplet.html που βρίσκεται στον φάκελο build ξαναγράφεται κάθε φορά
που τρέχετε ή αποσφαλματώνετε το applet. Για αυτό, μην πειράξετε το αρχείο στον φάκελο
build. Αντ’ αυτού μπορείτε να ακολουθήσετε την ακόλουθη διαδικασία:
1. Ανοίξτε το παράθυρο Αρχεία (Ctrl-2).
2. Αντιγράψτε το MyApplet.html από τον φάκελο build στο πακέτο όπου βρίσκεται η
κλάση του applet στον φάκελο src (στη δική μας περίπτωση, στο org.me.hello).
Σιγουρευτείτε πως το αρχείο MyApplet.html έχει το ίδιο όνομα όπως και η κλάση.
3. Τώρα επεξεργαστείτε το αρχείο MyApplet.html αν χρειάζεται.
Όταν θα κατασκευάζεται το πρόγραμμα, το αρχείο MyApplet.html θα αντιγράφεται από
τον φάκελο src στον φάκελο build.

Συμβουλή: Το αρχείο εκτέλεσης του applet δημιουργείται από το IDE όταν εκτελείτε ή
αποσφαλματώνετε ένα applet. Αν το αντιγράψετε στον φάκελο src για επεξεργασία, θα
συμπεριληφθεί αυτόματα στο αρχείο JAR όταν θα κατασκευάστε το πρόγραμμα. Κανονικά,
δεν χρειάζεται να συμπεριλαμβάνετε αυτό το αρχείο στο πακέτο ή στην εφαρμογή σας.
Αφαιρέστε το αρχείο αυτό από το JAR κάνοντας δεξί-κλικ στο project, επιλέγοντας
Properties, επιλέγοντας Creating JAR, και προσθέτοντας μία έκφραση για να μην
συμπεριλαμβάνονται τα αρχεία εκτέλεσης των applet, όπως το MyApplet.html.
Δημιουργία του δικτυακού προγράμματος (web project)
1. Επιλέξτε File > New Project. Στις κατηγορίες, επιλέξτε Web. Στα προγράμματα
επιλέξτε Web Application. Πατήστε Επόμενο.
2. Στο πεδίο Project Name, πληκτρολογείστε HelloWebApplet. Αλλάξτε την τοποθεσία
του προγράμματος στον υπολογιστή σας.
3. Πατήστε τέλος.
Προσθήκη του αρχείου JAR του applet σε το δικτυακό πρόγραμμα.
Όταν θα θελήσετε να συμπεριλάβετε ένα αρχείο JAR ενός applet σε ένα δικτυακό
πρόγραμμα, μπορείτε να το κάνετε προσθέτοντας στο πρόγραμμα που περιέχει το αρχείο JAR
του NetBeans IDE, ή προσθέτοντας καθ’ αυτό το αρχείο JAR. Αν και η επιλογή είναι δική
σας, σημειώστε πως αν προσθέσετε το πρόγραμμα Java του NetBeans IDE στο δικτυακό
πρόγραμμα, το IDE θα κατασκευάζει το applet κάθε φορά που κατασκευάζετε την εφαρμογή.
Γι αυτό, κάθε φορά που θα τροποποιείτε το applet στο πρόγραμμα του NetBeans IDE, το
IDE θα κατασκευάζει μία καινούρια έκδοση του applet κάθε φορά που το δικτυακό
πρόγραμμα θα κατασκευάζεται. Από την άλλη μεριά, αν το αρχείο JAR δεν βρίσκεται στο
πρόγραμμα του NetBeans IDE, ο πηγαίος κώδικας του applet δεν θα ξανά-κατασκευάζεται
όταν θα κατασκευάζετε το δικτυακό πρόγραμμα.
1. Στο παράθυρο των προγραμμάτων, κάντε δεξί-κλικ στον κόμβο του προγράμματος
HelloWevApplet και επιλέξτε ιδιότητες (properties) από το συναφή μενού.
2. Επιλέξτε ένα από τα παρακάτω:
o Αν το αρχείο JAR του applet βρίσκεται στο πρόγραμμα του NetBeans IDE,
κάντε κλικ στο Packaging Project, και μετά κάντε κλικ στο Add Project.
Βρείτε και επιλέξτε τον φάκελο που περιέχει το πρόγραμμα java του NetBeans
IDE. Σημειώστε πως τα προγράμματα του NetBeans IDE μαρκάρονται με το
εικονίδιο του NetBeans IDE.
o Αν το αρχείο JAR του applet δεν βρίσκεται στο πρόγραμμα του NetBeans
IDE, κάντε κλικ στο Packaging Project, και μετά κάντε κλικ στο Add
JAR/Folder. Βρείτε και επιλέξτε τον φάκελο που περιέχει το αρχείο JAR.
Παπαγιαννόπουλος Νικόλαος Πορφυριάδης Νικόλαος

35
Το αρχείο JAR που περιέχει την πηγή του applet βρίσκεται στη λίστα σε έναν πίνακα
στο κάτω μέρος του πλαισίου διαλόγου Project Properties.
Προαιρετικά, μπορείτε να πληκτρολογήσετε μία τοποθεσία για το applet στο Path του
πίνακα στην στήλη WAR. Εξ’ ορισμού, το αρχείο JAR του applet θα αντιγραφεί στον αρχικό
φάκελο (root) της δικτυακής εφαρμογής, ο οποίος είναι ο φάκελος build/web (υψηλότερο
επίπεδο της δομής των αρχείων της δικτυακής εφαρμογής). Πατήστε OK.
Όταν θα κατασκευάσετε το πρόγραμμα, το JAR του applet θα πακεταριστεί στο αρχείο
WAR του προγράμματος στο φάκελο dist. Επίσης θα προστεθεί στον φάκελο build/web. Για
περισσότερες λεπτομέρειες δείτε την εικόνα πιο κάτω.

Εικόνα 19
Δημιουργία και εκτέλεση JSP ή HTML αρχείου
1. Επιλέξτε ένα από τα παρακάτω:
o Αν θέλετε να ενσωματώσετε το applet σε ένα αρχείο JSP, κάντε διπλό-κλικ
στο εξ’ ορισμού index.jsp αρχείο στο παράθυρο των προγραμμάτων. Αυτό το
αρχείο δημιουργείται από το IDE όταν θα δημιουργήσετε ένα δικτυακό
πρόγραμμα. Ανοίγει στον Source Editor.
o Αν θέλετε να ενσωματώσετε το applet σε ένα HTML αρχείο, κάντε δεξί-κλικ
στον κόμβο του προγράμματος HelloWebApplet, και επιλέξτε New >
File/Folder από το συναφή μενού. Στις κατηγορίες, επιλέξτε Web. Στους
τύπους αρχείων επιλέξτε HTML. Πατήστε επόμενο. Δώστε στο αρχείο HTML
ένα όνομα και πατήστε τέλος.
Παπαγιαννόπουλος Νικόλαος Πορφυριάδης Νικόλαος

36
2. Ενσωματώστε το applet στο αρχείο προσθέτωντας το παρακάτω tag οπουδήποτε
ανάμεσα στο <body></body>: <applet code="org.me.hello.MyApplet"
archive="HelloApplet.jar"/>
o org.me.hello.MyApplet είναι το πλήρες όνομα της κλάσης για το applet.
o HelloApplet.jar είναι το αρχείο JAR που περιέχει το applet
3. Κάντε δεξί-κλικ στον κόμβο του αρχείου JSP ή HTML του προγράμματος στο
παράθυρο των προγραμμάτων και επιλέξτε εκτέλεση από το συναφή μενού.
Ο server τοποθετεί το αρχείο JSP ή HTML στον προεπιλεγμένο browser. Θα πρέπει να
δείτε κάτι σαν και την παρακάτω εικόνα.

Εικόνα 20
Σημειώστε πως το applet τρέχει στην virtual machine του IDE προεπιλεγμένου browser.
Το IDE χρησιμοποιεί διαφορετική virtual machine και για αυτό τα applet δεν
περιλαμβάνονται στη σύνοδο αποσφαλμάτωσης (debug session) του δικτυακού
προγράμματος.
Παπαγιαννόπουλος Νικόλαος Πορφυριάδης Νικόλαος

37

Εικόνα 21

Παπαγιαννόπουλος Νικόλαος Πορφυριάδης Νικόλαος

38

Εικόνα 22
Παπαγιαννόπουλος Νικόλαος Πορφυριάδης Νικόλαος

39

Εικόνα 23
Η βάση δεδομένων PostGreSQL
9

Εισαγωγή
H PostgreSQL είναι ο πιο προηγμένος data base server
ανοικτού κώδικα. Σε αυτό το κεφάλαιο, γίνεται μια εισαγωγική
αναφορά για τις βάσεις δεδομένων, το λογισμικό ανοικτού κώδικα,
και την ιστορία της PostGreSQL.
Υπάρχουν τρεις βασικές εφαρμογές γραφείου: οι
επεξεργαστές κειμένου, οι επεξεργαστές λογιστικών φύλλων
(spreadsheets), και οι βάσεις δεδομένων. Οι επεξεργαστές κειμένου παράγουν κείμενα
κρίσιμα σε οποιαδήποτε επιχείρηση. Τα προγράμματα επεξεργασίας λογιστικών φύλλων
(spreadsheets) χρησιμοποιούνται για οικονομικούς υπολογισμούς και την ανάλυση των
οικονομικών κυρίως στοιχειών. Οι βάσεις δεδομένων χρησιμοποιούνται πρώτιστα για την
αποθήκευση στοιχείων και την ανάκτηση τους. Μπορεί να γίνει χρήση ενός επεξεργαστή
λέξεων ή ενός προγράμματος επεξεργασίας λογιστικών φύλλων (spreadsheet) για την
αποθήκευση δεδομένων μικρών ποσοτήτων. Εντούτοις, με μεγάλους όγκους δεδομένων για
αποθήκευση ή δεδομένων για ανάκτηση που πρέπει να ενημερώνονται συχνά, οι βάσεις
δεδομένων είναι η καλύτερη επιλογή. Οι βάσεις δεδομένων επιτρέπουν την τακτική
αποθήκευση δεδομένων, τη γρήγορη ανάκτηση, και τη σύνθετη ανάλυση τους.


9
http://www.postgresql.org/files/documentation/books/aw_pgsql/node9.html
έως
http://www.postgresql.org/files/documentation/books/aw_pgsql/node-15.html

Παπαγιαννόπουλος Νικόλαος Πορφυριάδης Νικόλαος

40
Το Πανεπιστήμιο Berkeley της Καλιφόρνιας
Ο πρόγονος της PostGreSQL ήταν η Ingres, που αναπτύχθηκε στο
πανεπιστήμιο της Καλιφόρνιας στο Berkeley (1977-1985). Ο κώδικας
της Ingres ενισχύθηκε αργότερα από τη Relational
Technologies/Ingres Corporation, που δημιούργησε ένας από τους
πρώτους εμπορικά επιτυχείς σχεσιακούς servers βάσεων δεδομένων
(RDBMS). Επίσης στο Berkeley, ο Michael Stonebraker οδήγησε
μια ομάδα στην ανάπτυξη ενός αντικειμενοστραφές-σχεσιακού
server βάσεων δεδομένων αποκαλούμενου Postgres (1986-1994).
Δύο τελειόφοιτοι σπουδαστές του Μπέρκλεϋ, ο Jolly Chen και ο
Andrew Yu , στη συνέχεια πρόσθεσαν ικανότητες SQL στην Postgres.
Το πρόγραμμα που δημιουργήθηκε ονομάστηκε Postgres95 (1994-1995).
Οι δύο αργότερα έφυγαν από το Berkeley, αλλά ο Chen συνέχισε να συντηρεί
την Postgres95.
Η ανάπτυξης ξεφεύγει από το Berkeley
Το καλοκαίρι του 1996, έγινε σαφές ότι υπήρχε μεγάλη ανάγκη για έναν SQL server
βάσεων δεδομένων (DBMS) ανοιχτού κώδικα, και δημιουργήθηκε μια ομάδα για να
συνεχίσει την ανάπτυξη. Ο Marc Γ. Fournier απ το Τορόντο του Καναδά προσφέρεται να
φιλοξενήσει το mailing list και να παρέχει έναν server για να φιλοξενήσει το source tree.
Χίλιοι συνδρομητές του mailing list κινήθηκαν προς το νέο κατάλογο.
Ένας server διαμορφώθηκε, δίνοντας μερικα login accounts σε ανθρώπων για να
εφαρμόσουν διορθωσεις στον κώδικα χρησιμοποιώντας cvs.
O Jolly Chen έχει δηλώσει, «αυτό το πρόγραμμα δεν χρειάζεται μερικούς ανθρώπους
με πολύ χρόνο αλλά πολλούς ανθρώπους με λίγο χρόνο.» Λαμβάνοντας υπόψη τις 250.000
γραμμές κώδικα γραμμένες σε γλωσσά C έγινε κατανοητό τι σήμαινε αυτή η δήλωση. Στην
αρχική φάση, ασχολήθηκαν κυρίως τέσσερις άνθρωποι: ο Marc Fournier στον Καναδά, ο
Thomas Lockhart στην Πασαντένα της Καλιφόρνια, ο Vadim Mikheev στο Krasnoyarsk της
Ρωσίας και εγώ
*
στη Φιλαδέλφεια της Πενσυλβανία. Όλοι είχαμε εργασίες πλήρους
απασχόλησης, έτσι συμμετείχαμε στην προσπάθεια στον ελεύθερο χρόνο μας. Ήταν βεβαίως
μια πρόκληση.
Ο πρώτος στόχος μας ήταν να καθαρίσουμε τον παλιό mailing list, αξιολογώντας τις
διορθώσεις που ήταν ταχυδρομημένες για να διορθώσουν τα διάφορα προβλήματα. Το
σύστημα ήταν αρκετά εύθραυστο έπειτα, και όχι εύκολα κατανοητό. Κατά τη διάρκεια των
πρώτων έξι μηνών της ανάπτυξης, υπήρχε φόβος ότι μονό μια διόρθωση κώδικα (patch) θα
μπορούσε να κάνει το σύστημα να καταρρεύσει και εμείς θα ήμασταν ανίκανοι να
διορθώσουμε το πρόβλημα. Πολλές αναφορές σφαλμάτων μας έκαναν να αναρωτιόμαστε, όχι
μονό προσπαθώντας να βρούμε που είναι το λάθος αλλά και πως δούλευε εσωτερικά το
σύστημα.
Είχαμε κληρονομήσει μια τεράστια εγκατεστημένη βάση. Μια χαρακτηριστική
αναφορά σφάλματος ερχόταν στην ακόλουθη μορφή: «Όταν κάνω αυτό, η βάση δεδομένων
καταρρέει.» Είχαμε έναν μακρύ κατάλογο τέτοιων αναφορών σφαλμάτων. Σύντομα έγινε
σαφές ότι χρειαζόταν κάποια οργάνωση. Οι περισσότερες εκθέσεις σφαλμάτων απαιτούσαν
σημαντική έρευνα για την επιδιόρθωση, και πολλές αναφορές σφαλμάτων ήταν διπλές ή
τριπλές, έτσι ο κατάλογος των πραγμάτων (TO-DO list) που έπρεπε να γίνουν περιλάμβανε
όλα SQL ερωτήματα με προβλήματα. Αυτή η προσέγγιση μας βοήθησε να προσδιορίσουμε
τα σφάλματα, και κατέστησε τους χρήστες ενήμερους για αυτά, περιορίζοντας με αυτόν τον


*
Εννοείται ο συγγραφέας του αρχικού κειμένου τα στοιχειά του οποίου είναι άγνωστα
Παπαγιαννόπουλος Νικόλαος Πορφυριάδης Νικόλαος

41
τρόπο τις διπλές αναφορές σφαλμάτων. (σ.τ.μ. προφανώς πρόκειται για λίστα λαθών και
επικειμένων διορθώσεων δημοσιευμένη στο ίντερνετ).
Αν και είχαμε πολλούς πρόθυμους υπεύθυνους για την ανάπτυξη, η καμπύλη
εκμάθησης στην κατανόηση πώς δουλεύει η βάση δεδομένων ήταν ένας δύσκολος δρόμος.
Πολλοί υπεύθυνοι για την ανάπτυξη αναμίχθηκαν με τις άκρες του κώδικα, όπως τις
γλωσσικές διεπαφές (language interfaces) ή τα εργαλεία της βάσης δεδομένων (database
tools), όπου τα πράγματα ήταν ευκολότερα στην κατανόηση. Άλλοι υπεύθυνοι εστίασαν την
προσοχή τους στα προβλήματα συγκεκριμένων ερωτημάτων (σ.τ.μ. SQL ερωτημάτων),
προσπαθώντας να εντοπίσουν την πηγή των σφαλμάτων. Ήταν καταπληκτικό να βλέπει
κανείς ότι πολλά σφάλματα επιδιορθώθηκαν με μόνο μια γραμμή κώδικα C. Επειδή η
Postgres είχε εξελιχθεί σε ένα ακαδημαϊκό περιβάλλον, δεν είχε εκτεθεί στο πλήρες φάσμα
των πραγματικών ερωτημάτων (σ.τ.μ. SQL ερωτημάτων). Κατά τη διάρκεια εκείνης της
περιόδου, έγινε συζήτηση για την προσθήκη και άλλων χαρακτηριστικών, αλλά η αστάθεια
του συστήματος έκανε την επιδιόρθωση σφαλμάτων τον πρώτο στόχο της ομάδας.
Η παγκόσμια ομάδα ανάπτυξης της PostGreSQL
Στα τέλη του 1996, το όνομα του database server άλλαξε από Postgres95 σε
PostGreSQL. Είναι μεγάλη και μη εμπορική λέξη, αλλά τιμά και το όνομα του Μπέρκλεϋ και
τις SQL ικανότητες της βάσης. Άρχισε η διανομή του κώδικα χρησιμοποιώντας
απομακρυσμένα cvs, τα οποία επέτρεψαν στους ανθρώπους να κρατήσουν ενημερωμένα
αντίγραφα του δέντρου ανάπτυξης χωρίς να μεταφορτώνουν ένα ολόκληρο σύνολο αρχείων
κάθε μέρα.
Καινούριες διανομές υπήρχαν κάθε τρεις έως πέντε μήνες. Κάθε περίοδος περιλάμβανε
από δύο έως τρεις μήνες ανάπτυξης, έναν μήνα δοκιμής της δοκιμαστικής έκδοσης, μια κύρια
διανομή, και μερικές εβδομάδες με διανομές μικρών υποσυστημάτων για να διορθώσουν
σοβαρά προβλήματα. Δεν έγινε προσπάθεια ώστε να δημιουργηθεί ένα επιθετικότερο
πρόγραμμα με περισσότερες διανομές. Ένας server βάσεων δεδομένων δεν είναι όπως ένας
επεξεργαστής κειμένου ή ένα παιχνίδι, όπου μπορεί εύκολα να ξανά ξεκινήσει από την αρχή
εάν προκύψει ένα πρόβλημα.
Αντ' αυτού οι βάσεις δεδομένων είναι multi-user, και κλειδώνουν μέσα τους τα
δεδομένα των χρηστών, έτσι πρέπει να είναι όσο το δυνατόν πιο αξιόπιστες.
Η ανάπτυξη πηγαίου κώδικα αυτής της κλίμακας και πολυπλοκότητας δεν είναι για τον
αρχάριο. Είχαμε αρχικά τους πρόβλημα στην προσέλκυση προσωπικού για την ανάπτυξη
αφού το πρόγραμμα με μια τέτοια απότομη καμπύλη εκμάθησης. Εντούτοις, με την πάροδο
του χρόνου, το καλό κλίμα και η συνεχώς βελτιουμένη αξιοπιστία και απόδοσή μας
βοηθήσαν στην προσέλκυση των έμπειρων ταλέντων που είχαμε ανάγκη.
Η μεταλαμπάδευση της γνώσης που απαιτούνταν για να βοηθήσουν με την
PostGreSQL οι καινούριοι developers ήταν σαφώς σε αυξημένη προτεραιότητα. Είχαμε έναν
κατάλογο πραγμάτων που έπρεπε να γίνουν (TODO list) που περιέγραφε τι έπρεπε να γίνει,
αλλά με 250.000 γραμμές κώδικα, οποιαδήποτε εργασία ήταν ένα σημαντικό εγχείρημα.
Συνειδητοποιήσαμε ότι η εκπαίδευση των καινούριων developers θα έφερνε σημαντικά
οφέλη σε όλο το project. Φτιάξαμε ένα λεπτομερές διάγραμμα ροής των υποσυστημάτων απ
τα οποία απαρτίζονταν η βάσεων δεδομένων. Γράψαμε επίσης ένα developers' FAQ
(συνήθεις ερωτήσεις και οι απαντήσεις τους) απαντωντας στις πιο συνηθισμενες ερωτησεις
των νεων developers της PostGreSQL. Με αυτές τις πληροφορίες, οι developers έγιναν
παραγωγικότεροι στην διορθωση σφάλματαs και στην προσθήκη νεων χαρακτηριστικών
γνωρισμάτων.
Αν και ο κώδικας που πηραμε από το Berkeley ήταν πολύ παραμετροποιήσιμος, το
περισσότεροι προγραμματιστες στο Berkeley χρησιμοποιουσαν την PostGreSQL ως εργαλειο
Παπαγιαννόπουλος Νικόλαος Πορφυριάδης Νικόλαος

42
δοκιμής για ερευνητικά προγράμματα. Κατά συνέπεια, η βελτίωση του υπάρχοντος κώδικα
δεν ήταν μια προτεραιότητα. Ακομη το στιλ προγραμματισμου διεφερε από προγραμματιστη
σε προγραμματιστη.
Γράψαμε ένα εργαλείο για να επαναμορφοποιήσουμε το συνολο του κωδικα με έναν
ομοιογενη τροπο. Γράψαμε ένα script για να βρούμε τις μεθόδους που θα μπορούσαν να
χαρακτηριστούν ως static ή μεθόδους που δεν χρησιμοποιούνται πουθενά και θα μπορούσαν
να αναιρεθούν εντελώς. Αυτά τα scripts τρέχουν πάνω στον κώδικα πριν από τη δημοσίευση
κάθε καινούριας έκδοσης. Τελικά δημιουργείται μια λίστα με ότι περιλαμβάνει κάθε νέα
έκδοση ώστε να υπενθυμίζει τα πράγματα που άλλαξαν σε κάθε νέα έκδοση της βάσης
δεδομένων.
Καθώς αποκτούσαμε όλο και καλύτερη γνώση επάνω στον κώδικα, ήμασταν σε θέση
να εκτελέσουμε πιο περίπλοκες διορθώσεις αλλά και προσθήκες νέων χαρακτηριστικών
γνωρισμάτων. Ξανασχεδιάσαμε τον κακώς δομημένο κώδικα. Φτάσαμε σε ένα επίπεδο έτσι
ώστε κάθε νέα έκδοση να έχει σημαντικά νέα χαρακτηριστικά γνωρίσματα, αντί για απλές
διορθώσεις σφαλμάτων. Βελτιώσαμε την προσαρμογή της βάσης δεδομένων προς το SQL
πρότυπο, προσθέσαμε sub-selects, ενισχύσαμε το κλείδωμα όπου χρειαζόταν και προσθέσαμε
τις εντολές SQL που έλειπαν. Σχηματιστικε μια εταιρεια για να προσφέρει τηλεφωνική
υποστήριξη.
Στα αρχεία των ομάδες συζήτησης του USENET μας αποδοκιμαζαν. Συγχρόνως, είχαμε
ψάξει για την PostGreSQL και είχαμε διαπιστώσει ότι πολλοί άνθρωποι σύστηναν άλλες
βάσεις δεδομένων, ακόμα κι αν εξετάζαμε τις ανησυχίες χρηστών και τις ικανοποιουσαμε
όσο το δυνατόν γρηγορότερα. Ένα έτος αργότερα, πολλοί άνθρωποι μας σύστηναν στους
χρήστες που χρειάζονταν υποστήριξη συναλλαγων (transaction support), σύνθετα ερωτήματα
προς τη βαση, υποστήριξη SQL σε επιχειρησιακο επιπεδο (commercial-grade SQL support),