Download pdf - Ανάπτυξη συστήματος λογισμικού βάσει της μεθοδολογίας ICONIX

ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ

Αλέξανδρος Ν. Χατζηγεωργίου

Ανάπτυξη συστήματος λογισμικού βάσει της μεθοδολογίας ICONIX

Διαχείριση Παραγγελιών


Θεματική Ενότητα ΠΛΗ 24

2008


Πίνακας Περιεχομένων

1. Γνωσιολογικοί Στόχοι ............................................................................. 7

1.1 Σκοπός - Περιεχόμενο ....................................................................... 7

1.2 Προσδοκώμενα Αποτελέσματα ........................................................ 8

1.3 Λέξεις Κλειδιά .................................................................................. 8

2. Εισαγωγή στη Μεθοδολογία ICONIX .................................................... 9

2.1 Γενικά ................................................................................................ 9

2.2 ICONIX ........................................................................................... 11

2.2.1 Ανάλυση Απαιτήσεων ............................................................. 13

2.2.2 Ανάλυση – Αρχική Σχεδίαση ................................................... 14

2.2.3 Σχεδίαση .................................................................................. 14

2.2.4 Υλοποίηση ............................................................................... 15

3. Απαιτήσεις Υψηλού Επιπέδου ......................................................... 16

4. Καθορισμός Απαιτήσεων ............................................................ 17

4.1 Μοντέλο Πεδίου Προβλήματος (Domain Modelling) .................... 17

4.1.1. Εξαγωγή αρχικής λίστας υποψηφίων κλάσεων ...................... 17

4.1.2 Περιορισμός υποψηφίων κλάσεων .......................................... 18

4.1.3 Καθορισμός σχέσεων μεταξύ κλάσεων ................................... 20

4.2 Μοντέλο Περιπτώσεων Χρήσης (Use Case Model) ....................... 22

4.2.1 Περιπτώσεις χρήσης ................................................................ 22

2 ΠΛΗ 24 – Σχεδιασμός Λογισμικού

Σύστημα Διαχείρισης Παραγγελιών

4.2.2 Τεκμηρίωση περιπτώσεων χρήσης .......................................... 24

4.2.3 Πρότυπα τεκμηρίωσης περιπτώσεων χρήσης .......................... 27

4.2.4 Ενδεικτικές Οθόνες του Συστήματος ....................................... 29

4.3 Τεκμηρίωση Περιπτώσεων Χρήσης ............................................... 33

4.3.1 Περίπτωση Χρήσης 1: Δημιουργία Πιάτου ................... 34

4.3.2 Περίπτωση Χρήσης 2: Προσθήκη Παραγγελίας ........... 36

4.3.3 Περίπτωση Χρήσης 3: Ετοιμασία Παραγγελίας ............ 38

4.3.4 Περίπτωση Χρήσης 4: Υπολογισμός Χρόνου ............... 40

5. Ανάλυση ...................................................................................... 42

5.1 Ανάλυση Ευρωστίας ....................................................................... 42

5.1.1 Γέφυρα μεταξύ ανάλυσης και σχεδίασης ................................ 42

5.1.2 Κανόνες σχεδίασης διαγραμμάτων ευρωστίας ........................ 44

5.2 Διαγράμματα Ευρωστίας Συστήματος ............................................ 45

5.2.1 Διάγραμμα Ευρωστίας 1: Δημιουργία Πιάτου .............. 46

5.2.2 Διάγραμμα Ευρωστίας 2: Προσθήκη Παραγγελίας ....... 50

5.2.3 Διάγραμμα Ευρωστίας 3: Ετοιμασία Παραγγελίας ....... 51

5.2.4 Διάγραμμα Ευρωστίας 4: Υπολογισμός Χρόνου ........... 52

5.3 Αναθεώρηση του μοντέλου πεδίου προβλήματος .......................... 52

6. Σχεδίαση ...................................................................................... 56

6.1 Διαγράμματα Ακολουθίας (Sequence diagrams) ............................ 56

6.1.1 Κατανομή λειτουργικότητας .................................................... 56

6.1.2 Παράδειγμα διαγράμματος ακολουθίας ................................... 57

6.1.3 Τύποι μηνυμάτων σε διαγράμματα ακολουθίας ...................... 59



6.1.4 Εναλλακτικές ........................................................................... 62

6.1.5 Βρόχοι ...................................................................................... 64

6.2 Σύστημα Διαχείρισης Παραγγελιών ............................................... 66

6.2.1 Διάγραμμα Ακολουθίας 1: Δημιουργία Πιάτου ............. 66

6.2.2 Διάγραμμα Ακολουθίας 2: Προσθήκη Παραγγελίας ..... 70

6.2.3 Διάγραμμα Ακολουθίας 3: Ετοιμασία Παραγγελίας ..... 71

6.2.4 Διάγραμμα Ακολουθίας 4: Υπολογισμός Χρόνου ......... 72

6.3 Διάγραμμα Κλάσεων ...................................................................... 73

6.3.1 Στατικό μοντέλο συστήματος .................................................. 73

6.3.2 Εξαγωγή μεθόδων συστήματος ............................................... 74

6.3.3 Αναθεωρημένο διάγραμμα κλάσεων ....................................... 76

6.3.4 Απλουστεύσεις - Συμβάσεις .................................................... 79

6.4 Ποιότητα Σχεδίασης........................................................................ 80

6.5 Αξιολόγηση Σχεδίασης με χρήση Μετρικών Λογισμικού .............. 82

6.5.1 Σύζευξη .................................................................................... 85

6.5.2 Συνεκτικότητα .......................................................................... 88

6.5.3 Πολυπλοκότητα ....................................................................... 92

6.6 Αρχές Αντικειμενοστρεφούς Σχεδίασης ......................................... 98

6.6.1 Εισαγωγή ................................................................................. 98

6.6.2 Αρχή της Ενσωμάτωσης ........................................................ 100

6.7 Ευρετικοί Κανόνες ........................................................................ 105

6.7.1 Θεϊκές κλάσεις ....................................................................... 106

6.7.2 Νόμος της Δήμητρας ............................................................. 107



7.Υλοποίηση ................................................................................. 110

7.1 Επισκόπηση δυνατοτήτων σύγχρονων CASE tools ..................... 110

7.2 Αντιστοίχιση UML και Java ......................................................... 111

7.2.1 Κλάσεις .................................................................................. 112

7.2.2 Συσχετίσεις ............................................................................ 116

7.2.3 Συσχετίσεις με πολλαπλότητα ............................................... 119

7.2.4 Σχέσεις Περιεκτικότητας ....................................................... 121

7.2.5 Σχέσεις Κληρονομικότητας ................................................... 123

7.3 Αντίστροφη Μηχανική.................................................................. 127

7.3.1 Συνέπεια μεταξύ κώδικα και τεκμηρίωσης ............................ 127

7.3.2 Εξαγωγή διαγράμματος κλάσεων .......................................... 128

7.3.3 Εξαγωγή διαγράμματος ακολουθίας ...................................... 130

8. Πλήρης κωδικοποίηση του συστήματος ....................................... 133

8.1 Κλάσεις Λογικής Συστήματος ................................................ 136

8.1.1 Κλάση Plate ........................................................................... 136

8.1.2 Κλάση Ingredient ................................................................... 139

8.1.3 Κλάση Order .......................................................................... 141

8.1.4 Κλάση Queue ......................................................................... 143

8.1.5 Κλάση PlateCatalog ............................................................... 146

8.1.6 Κλάση IngredientCatalog ...................................................... 148

8.2 Δημιουργία μιας απλής γραφικής διασύνδεσης χρήστη ............... 150

8.2.1 Δημιουργία παραθύρων ......................................................... 150

8.2.2 Εισαγωγή γραφικών συστατικών ........................................... 152



8.2.3 Χειρισμός συμβάντων ............................................................ 156

8.3 Κλάσεις γραφικής διασύνδεσης χρήστη ....................................... 163

8.3.1 Κλάση MainFrame ................................................................. 163

8.3.2 Κλάση AddOrderFrame ......................................................... 167

8.3.3 Κλάση CreatePlateFrame ....................................................... 173

8.3.4 Κλάση CalculateTimeFrame .................................................. 178

8.3.5 Κλάση PrepareOrderFrame .................................................... 181

8.4 Αρχιτεκτονική Γραφικής Διασύνδεσης ........................................ 185

9. Συμπεράσματα .................................................................................... 187

10. Βιβλιογραφία .................................................................................... 188

Τα βέλη που υπάρχουν στο κείμενο μπορούν να χρησιμοποιηθούν για την

πλοήγηση στη μεθοδολογία ICONIX (ανά στάδιο της μεθοδολογίας και ανά

περίπτωση χρήσης)



1. Γνωσιολογικοί Στόχοι

1.1 Σκοπός - Περιεχόμενο

Σκοπός της παρούσας μελέτης περίπτωσης που αναλύεται υπό μορφή

υπερκειμένου είναι η παρουσίαση των σταδίων ανάπτυξης μιας απλής

εφαρμογής διαχείρισης παραγγελιών εστιατορίου σύμφωνα με τη

μεθοδολογία ICONIX. Η προσέγγιση έχει ως στόχο αφενός να περιγράψει

θεωρητικά τα βήματα της μεθοδολογίας, εστιάζοντας στην καταγραφή

των απαιτήσεων, την ανάλυση, τη σχεδίαση αλλά και την υλοποίηση του

συστήματος, δηλαδή τη μετάβαση στον κώδικα (στη συγκεκριμένη

μελέτη περίπτωσης σε Java). Αφετέρου, παρουσιάζεται η εφαρμογή της

μεθοδολογίας στη συγκεκριμένη μελέτη περίπτωσης χρησιμοποιώντας ως

εργαλείο τα αντίστοιχα διαγράμματα της Ενοποιημένης Γλώσσας

Μοντελοποίησης (UML). Παράλληλα εξετάζεται η αξιολόγηση της

ποιότητας του παραγόμενου σχεδίου, θέμα που απασχολεί την ομάδα

ανάπτυξης οποιουδήποτε έργου λογισμικού. Τέλος, για την

ολοκληρωμένη επίδειξη του συστήματος διαχείρισης παραγγελιών

πραγματοποιείται μια συνοπτική επισκόπηση της ανάπτυξης γραφικής

διασύνδεσης χρήστη.

7

ΠΛΗ 24 – Σχεδιασμός Λογισμικού


1.2 Προσδοκώμενα Αποτελέσματα

Μετά την μελέτη του παραδείγματος ο αναγνώστης θα είναι σε θέση:

- να κατανοήσει τη χρησιμότητα μιας αντικειμενοστρεφούς μεθοδολογίας

ανάπτυξης λογισμικού όπως η ICONIX

- να πραγματοποιήσει με συστηματικό τρόπο την αντικειμενοστρεφή

ανάλυση και σχεδίαση για ένα πρόβλημα

- να χρησιμοποιεί τα διαγράμματα της Ενοποιημένης Γλώσσας

Μοντελοποίησης για τη δημιουργία των κατάλληλων μοντέλων σε κάθε

φάση της ανάπτυξης

- να δημιουργεί κώδικα στην αντικειμενοστρεφή γλώσσα Java βάσει των

μοντέλων που ανέπτυξε

- να αξιολογεί την ποιότητα της σχεδίασης

- να αναπτύσσει τη γραφική διασύνδεση χρήστη

- να αξιοποιεί τις δυνατότητες εργαλείων υποστήριξης της διαδικασίας

ανάπτυξης

1.3 Λέξεις Κλειδιά

Αντικειμενοστρεφής Ανάπτυξη Λογισμικού Ενοποιημένη Γλώσσα Μοντελοποίησης (UML) ICONIX Ανάλυση και Σχεδίαση Μετρικές Λογισμικού Ποιότητα Σχεδίασης Εργαλεία CASE



2. Εισαγωγή στη Μεθοδολογία ICONIX

2.1 Γενικά

9

Το αντικειμενοστρεφές υπόδειγμα προγραμματισμού είναι ευρέως

αποδεκτό ότι προσφέρει πολλά πλεονεκτήματα έναντι άλλων

υποδειγμάτων (π.χ. διαδικασιακού). Αυτά σχετίζονται κυρίως με την

ευκολία κατανόησης, συντήρησης, ελέγχου και επαναχρησιμοποίησης του

λογισμικού. Ωστόσο, τα πλεονεκτήματα αυτά γίνονται εμφανή κυρίως σε

έργα λογισμικού μεγάλης κλίμακας. Με τον όρο μεγάλη κλίμακα

αναφερόμαστε σε έργα όπου το μείζον πρόβλημα δεν είναι η κατάστρωση

των αλγορίθμων και η υλοποίησή τους σε κάποια γλώσσα

προγραμματισμού (όπως συμβαίνει στα έργα μικρής κλίμακας) αλλά η

δυσκολία επικοινωνίας και συντονισμού μεταξύ των μονάδων του έργου.

Ως μονάδες του έργου θεωρούνται αφενός οι μονάδες του λογισμικού (τα

φυσικά ή λογικά συστατικά του) που αναπτύσσονται χωριστά και πρέπει

να συνεργαστούν για την επίτευξη της ζητούμενης λειτουργικότητας.

Αφετέρου, ως μονάδες θεωρούνται και οι εμπλεκόμενοι στη διαδικασία

ανάπτυξης, δηλαδή οι πελάτες, οι τελικοί χρήστες, οι αναλυτές, οι

σχεδιαστές, οι προγραμματιστές και τα μέλη της διοίκησης της εταιρείας

ανάπτυξης. Τα άτομα αυτά, με διαφορετικά ενδιαφέροντα ως προς το έργο

και με διαφορετικό υπόβαθρο πρέπει να συντονιστούν και να

επικοινωνήσουν αποτελεσματικά, ώστε η ανάπτυξη ενός έργου

λογισμικού να είναι επιτυχής.



Ένα δεύτερο χαρακτηριστικό έργων μεγάλης κλίμακας είναι η

εξελισσόμενη φύση τους. Μία από τις πλέον αποδεκτές "αλήθειες" στην

Τεχνολογία Λογισμικού είναι ότι οι απαιτήσεις των πελατών πάντοτε θα

αλλάζουν. Η παρατήρηση αυτή αποτυπώνει την αναγκαιότητα για

συντήρηση του λογισμικού με την πάροδο του χρόνου. Με τον όρο

συντήρηση αναφερόμαστε στον εμπλουτισμό του λογισμικού με νέες

δυνατότητες που ανταποκρίνονται στα ζητούμενα των πελατών

(τροποποιητική συντήρηση) όσο και στη διόρθωση σφαλμάτων ή

ατελειών του λογισμικού καθώς αυτά εντοπίζονται από την εκτεταμένη

χρήση του λογισμικού (διορθωτική συντήρηση). Ένα μοντέλο

ανάπτυξης λογισμικού είναι επομένως αποτελεσματικό εάν λαμβάνει

υπόψη την αναγκαιότητα συνεχούς εξέλιξης του λογισμικού και επιτρέπει

τη συντήρησή του με μικρή προσπάθεια και χαμηλό κόστος.

Το αντικειμενοστρεφές υπόδειγμα και η χρήση της Ενοποιημένης

Γλώσσας Μοντελοποίησης στα πλαίσια κάποιας μεθοδολογίας ανάπτυξης,

όπως η ICONIX, παρέχουν τα εργαλεία και τις τεχνικές για την

αποτελεσματική διαχείριση των προβλημάτων αυτών σε έργα λογισμικού

μεγάλης κλίμακας. Αξίζει να σημειωθεί ότι η χρήση αντικειμενοστρεφούς

προσέγγισης σε έργα πολύ μικρής κλίμακας ενδέχεται να μην προσφέρει

πλεονεκτήματα αλλά αντίθετα να συνεισφέρει στην πολυπλοκότητα του

έργου.



2.2 ICONIX

Η ICONIX είναι μια μεθοδολογία ανάπτυξης λογισμικού που επιτρέπει τη

συστηματική μετάβαση από τις αρχικές απαιτήσεις όπως αυτές

διατυπώνονται από τον πελάτη, στον κώδικα που τελικά υλοποιεί τις

απαιτήσεις αυτές. Είναι μια απλούστερη εκδοχή της ευρέως διαδεδομένης

Ενοποιημένης Προσέγγισης (Unified Process). Το μείζον χαρακτηριστικό

της μεθοδολογίας ICONIX είναι η επαναληπτικότητα. Αφενός, η

διαδικασία είναι επαναληπτική διότι επιτρέπει την παραγωγή

λειτουργικού κώδικα για κάθε μια περίπτωση χρήσης του συστήματος

ξεχωριστά. Σε κάθε επανάληψη, εξετάζεται μια νέα περίπτωση χρήσης

που καταλήγει στην προσθήκη λειτουργικότητας στο τελικό προϊόν.

Αφετέρου, η διαδικασία είναι επαναληπτική διότι επιτρέπει (και

υποβοηθά) την επιστροφή από ένα στάδιο της διαδικασίας ανάπτυξης (π.χ.

το σχεδιασμό) σε προηγούμενα (π.χ. την ανάλυση απαιτήσεων) με σκοπό

την αποσαφήνιση, βελτίωση και διόρθωση προηγούμενων ενεργειών. Η

επαναληπτικότητα βρίσκεται στο κέντρο του αντικειμενοστρεφούς

υποδείγματος προγραμματισμού καθώς αναγνωρίζει ότι ένα μεγάλο

σύστημα λογισμικού δεν μπορεί να αναπτυχθεί με μιας και ότι οι αλλαγές

σε προηγούμενες επιλογές είναι αναπόφευκτες.

Η φιλοσοφία της μεθοδολογίας ICONIX αποτυπώνεται στο διάγραμμα

του σχήματος 2.1. Το ζητούμενο είναι από τις απαιτήσεις του χρήστη να

παραχθεί το τελικό προϊόν, δηλαδή ο λειτουργικός κώδικας. Ο κώδικας

παράγεται με τη διαδοχική εκλέπτυνση και βελτίωση δύο μοντέλων:



α) του στατικού μοντέλου που περιγράφει την αρχιτεκτονική του

συστήματος, δηλαδή τις δομικές του μονάδες και τις σχέσεις μεταξύ τους

και β) του δυναμικού μοντέλου που περιγράφει τον τρόπο με τον οποίο οι

μονάδες αλληλεπιδρούν για την επίτευξη της επιθυμητής

λειτουργικότητας. Οι απαιτήσεις του πελάτη/χρήστη του συστήματος

θεωρείται ότι διατυπώνονται σε κάποιο αρχικό κείμενο (γνωστό ως

απαιτήσεις υψηλού επιπέδου) και ενδεχομένως σε κάποια σκίτσα της

επιθυμητής γραφικής διασύνδεσης χρήστη. Η μεθοδολογία ICONIX

βασίζεται στην αξιοποίηση ενός υποσυνόλου της UML για τη δημιουργία

διαγραμμάτων ως ενδιάμεσα προϊόντα κατά την εξέλιξη του δυναμικού

και στατικού μοντέλου του συστήματος που αναπτύσσεται. Συγκεκριμένα,

από το σύνολο των διαγραμμάτων της UML, χρησιμοποιούνται τα

διαγράμματα περιπτώσεων χρήσης, τα διαγράμματα κλάσεων, τα

διαγράμματα ευρωστίας (ειδική περίπτωση των διαγραμμάτων

συνεργασίας) και τα διαγράμματα ακολουθίας.



Απαιτήσεις Πελάτη

Κύρια Οθόνη

Σύστημα ∆ιαχείρισης Παραγγελιών Εστιατορίου

Καταχώρηση Παραγγελίας

Πληροφόρηση Χρόνου

∆ημιουργία Πιάτου

Ετοιμασία Πιάτου

Ενημέρωση Αποθέματος

Εκτύπωση Λογαριασμού

Παρακολούθηση Οικον.Στοιχείων

Ενημέρωση Τιμών

Προσχέδιο Γραφικής ∆ιασύνδεσης

Blah blah

∆ιάγραμμα Ευρωστίας

a1:A b1:B c1:C d1:D

do()m1()

m2()

∆ιάγραμμα Ακολουθίας

∆ημιουργία Πιάτου

Ετοιμασία Πιάτου

Ενημέρωση Αποθέματος

∆ιάγραμμα Περιπτώσεων Χρήσης

ΠιάτοΠαραγγελία

Ουρά

Συστατικό

ΠιάτοΠαραγγελία

Ουρά

Συστατικό

-attr1 : int-attr2 : String

-x1 : int-x2 : double

-quantity : int-name : String

Μοντέλο Πεδίου Προβλήματος Αναθεωρημένο ∆ιάγραμμα Κλάσεων Τελικό ∆ιάγραμμα Κλάσεων

∆ΥΝΑΜΙΚΟ ΜΟΝΤΕΛΟ ΣΥΣΤΗΜΑΤΟΣ

ΣΤΑΤΙΚΟ ΜΟΝΤΕΛΟ ΣΥΣΤΗΜΑΤΟΣ

Public class Plate

private int quantity;private String name;

. . .

ΚώδικαςΠιάτοΠαραγγελία

Ουρά

Συστατικό

-attr1 : int-attr2 : String

-x1 : int-x2 : double

-quantity : int-name : String

+getFirstOrder()

+isAvailable()+calculateTime()

Σχήμα 2.1: Γραφική Επισκόπηση της Μεθοδολογίας ICONIX

Από τη στιγμή που οι απαιτήσεις του πελάτη δοθούν στην εταιρεία

ανάπτυξης λογισμικού (και η εταιρεία αναλάβει το έργο) η διαδικασία

ακολουθεί τις εξής φάσεις:

2.2.1 Ανάλυση Απαιτήσεων

Πρώτο βήμα στην ανάλυση των απαιτήσεων είναι η καταγραφή των

οντοτήτων του πεδίου που διαπραγματεύεται το σύστημα που πρόκειται

να αναπτυχθεί (πεδίο προβλήματος) και των σχέσεων μεταξύ τους. Οι

οντότητες αυτές αποτελούν τη βάση του στατικού αντικειμενοστρεφούς

μοντέλου καθώς η λειτουργία του λογισμικού βασίζεται στην

αλληλεπίδραση μεταξύ τους. Έχοντας το μοντέλο του πεδίου

προβλήματος στη διάθεσή μας, επόμενο βήμα στην ανάλυση απαιτήσεων



είναι η λεπτομερής και σαφής περιγραφή των απαιτήσεων του πελάτη υπό

μορφή περιπτώσεων χρήσης.

2.2.2 Ανάλυση – Αρχική Σχεδίαση

Σε επίπεδο δυναμικού μοντέλου κύριο εργαλείο στη φάση αυτή είναι τα

διαγράμματα ευρωστίας για τη διερεύνηση των ενεργειών που

υπαγορεύονται από τις περιπτώσεις χρήσης και κυρίως την βελτίωση του

κειμένου των ίδιων των περιπτώσεων χρήσης. Με το πέρας της ανάλυσης

ευρωστίας προκύπτει συνήθως ένα αναθεωρημένο και εμπλουτισμένο

διάγραμμα κλάσεων (ως μετεξέλιξη του μοντέλου πεδίου προβλήματος)

που περιλαμβάνει επιπρόσθετες κλάσεις καθώς και ορισμένες από τις

ιδιότητες των κλάσεων.

2.2.3 Σχεδίαση

Στη φάση της σχεδίασης επιχειρείται η ακριβής διερεύνηση της δυναμικής

συμπεριφοράς του συστήματος και η κατανομή της λειτουργικότητας στις

κλάσεις. Κύριο εργαλείο για το σκοπό αυτό είναι τα διαγράμματα

ακολουθίας. Με το πέρας της σχεδίασης η ομάδα ανάπτυξης παράγει το

τελικό διάγραμμα κλάσεων που αποτελεί την είσοδο για τη φάση της

υλοποίησης του λογισμικού.



2.2.4 Υλοποίηση

Το σημαντικότερο προϊόν της διαδικασίας ανάπτυξης δεν είναι φυσικά τα

διαγράμματα αλλά ο ίδιος ο κώδικας που ικανοποιεί τις απαιτήσεις του

πελάτη. Στη φάση της υλοποίησης αναπτύσσεται ο κώδικας βάσει της

σχεδίασης που προηγήθηκε (σε μεγάλο βαθμό υπάρχει η δυνατότητα

παραγωγής κώδικα από τα διαγράμματα κλάσεων και ακολουθίας).

Παρόλο που δεν εξετάζεται στην παρούσα μελέτη, σημαντικό μέρος της

υλοποίησης είναι και ο έλεγχος μονάδων (unit testing) δηλαδή η

εξασφάλιση της ορθής λειτουργίας των κλάσεων που δημιουργήθηκαν.

Σύμφωνα με τη μεθοδολογία ICONIX αλλά και τις γενικότερες

επιταγές της Τεχνολογίας Λογισμικού, στο τέλος κάθε φάσης θα πρέπει να

πραγματοποιείται μια συστηματική επισκόπηση (inspection/review). Στις

επισκοπήσεις αυτές τα μέλη της ομάδας ανάπτυξης (αλλά ενδεχομένως

και εκπρόσωποι του πελάτη ή της διοίκησης) ελέγχουν την ορθότητα των

μοντέλων που δημιουργήθηκαν και τη συνέπεια προς τις απαιτήσεις.

Στη συνέχεια παρουσιάζονται οι φάσεις ανάπτυξης για ένα έργο

λογισμικού που αφορά σε ένα σύστημα διαχείρισης παραγγελιών

εστιατορίου. Όπως αναφέρθηκε, η διαδικασία ξεκινά από την αρχική

διατύπωση των απαιτήσεων από πλευράς του πελάτη. Σημειώνεται ότι οι

προδιαγραφές που τίθενται από το χρήστη (αναφέρονται ως απαιτήσεις

υψηλού επιπέδου – high level requirements specification) είναι συχνά

περιληπτικές, ασαφείς και όχι πλήρεις.



3. Απαιτήσεις Υψηλού Επιπέδου Το λογισμικό που πρόκειται να αναπτυχθεί αφορά σε ένα σύστημα

διαχείρισης παραγγελιών σε εστιατόριο. Ο σερβιτόρος, αφού λάβει την

παραγγελία από τον πελάτη την εισάγει στο σύστημα. Η παραγγελία

μπορεί να περιλαμβάνει πιάτα που έχει ετοιμάσει ο μάγειρας. Η

παραγγελία τοποθετείται σε μια ουρά έως ότου ετοιμαστεί από τον

μάγειρα.

Ο σερβιτόρος μπορεί να μάθει ανά πάσα στιγμή το χρόνο που

απαιτείται μέχρι να ετοιμαστεί μια παραγγελία (δίνοντας τον

αναγνωριστικό αριθμό της) βάσει της θέσης της στην ουρά.

Ο μάγειρας έχει τη δυνατότητα μέσω του συστήματος να δημιουργεί

πιάτα καθορίζοντας τα συστατικά που απαιτούνται και τις ποσότητές

τους. Επίσης, ο μάγειρας μπορεί να δηλώνει στο σύστημα την ετοιμασία

(ολοκλήρωση) κάθε πιάτου που πρέπει να σερβιριστεί. Μόλις ετοιμαστεί

ένα πιάτο αφαιρούνται οι αντίστοιχες ποσότητες από το απόθεμα κάθε

συστατικού. Μόλις ο μάγειρας ετοιμάσει όλα τα πιάτα μιας παραγγελίας,

η παραγγελία απομακρύνεται από την ουρά.

16

(Χάριν απλότητας, θεωρείται ότι τα συστατικά και το απόθεμά τους δεν

τροποποιούνται από τους χρήστες του συστήματος. Μπορούν να

τροποποιηθούν μόνο προγραμματιστικά με απευθείας επίδραση στον

κώδικα. Προφανώς σε ένα πραγματικό σύστημα θα υπήρχε

λειτουργικότητα που θα επέτρεπε και την εισαγωγή/διαγραφή συστατικών

καθώς και την τροποποίηση του αποθέματος).



4. Καθορισμός Απαιτήσεων

4.1 Μοντέλο Πεδίου Προβλήματος (Domain Modelling)

4.1.1. Εξαγωγή αρχικής λίστας υποψηφίων κλάσεων

Το πρώτο στάδιο ανάπτυξης ενός συστήματος λογισμικού για το οποίο

έχουν δοθεί οι προδιαγραφές από τον πελάτη, είναι στη μεθοδολογία

ICONIX η κατασκευή του μοντέλου του πεδίου προβλήματος (domain

model). Το μοντέλο αυτό είναι μια γραφική απεικόνιση των

οντοτήτων/εννοιών (κλάσεις πεδίου) που χρησιμοποιούνται για την

περιγραφή των απαιτήσεων του συστήματος καθώς και των σχέσεων

μεταξύ τους.

Υπάρχουν αρκετές προσεγγίσεις για την εξαγωγή κλάσεων πεδίου από

τις απαιτήσεις υψηλού επιπέδου, που περιλαμβάνουν γραμματική-

συντακτική ανάλυση του κειμένου για την εύρεση ουσιαστικών, η χρήση

λεξιλογίου από αντίστοιχα συστήματα λογισμικού ή η γνωμοδότηση

ειδικών. Σε κάθε περίπτωση προκύπτει μια λίστα εννοιών οι οποίες

αποτελούν υποψήφιες κλάσεις πεδίου. Η λίστα διαδοχικά περιορίζεται

απομακρύνοντας διπλοεγγραφές, αναφορές σε οντότητες εκτός

συστήματος ή στο ίδιο σύστημα, αφηρημένες έννοιες κλπ. Σύμφωνα δε με

τις θεμελιώδες αρχές ανάπτυξης αντικειμενοστρεφών συστημάτων αλλά

και της μεθοδολογίας ICONIX, το μοντέλο πεδίου προβλήματος που

κατασκευάζεται αρχικά ενδέχεται (και αναμένεται) να τροποποιηθεί



αρκετές φορές κατά τη διάρκεια των σταδίων της ανάλυσης και

σχεδίασης.

Από την περιγραφή απαιτήσεων υψηλού επιπέδου που δόθηκε,

προκύπτει η ακόλουθη αρχική λίστα ουσιαστικών και πιθανών κλάσεων

πεδίου προβλήματος (έχοντας μετατρέψει το πρόσωπο σε πρώτο ενικό):

Λίστα Ουσιαστικών

Σύστημα διαχείρισης παραγγελιών Ουρά

Εστιατόριο Χρόνος

Σερβιτόρος Αναγνωριστικό Αριθμός

Παραγγελία Θέση (στην Ουρά)

Πελάτης Συστατικό

Πιάτο Ποσότητα

Μάγειρας Απόθεμα

4.1.2 Περιορισμός υποψηφίων κλάσεων

Η ανωτέρω λίστα μπορεί να περιοριστεί σημαντικά απαλοίφοντας:

• Αναφορές στο ίδιο το σύστημα λογισμικού που αναπτύσσουμε

(Σύστημα διαχείρισης παραγγελιών)

• Αναφορές σε χειριστές του συστήματος που πρόκειται να

αναπτύξουμε καθώς βρίσκονται "έξω" από τα όρια του

συστήματος (Σερβιτόρος, Μάγειρας)

• Αναφορές σε οντότητες που βρίσκονται εκτός του πεδίου του

προβλήματος και κατά συνέπεια δεν πρόκειται να συμμετάσχουν



ως οντότητες στην υλοποίηση των λειτουργιών του συστήματος

(Εστιατόριο, Πελάτης). Επισημαίνεται ότι αν υπήρχαν απαιτήσεις

που να αναφέρονται σε δυνατότητες ανταλλαγής πληροφοριών

μεταξύ των συστημάτων δύο εστιατορίων τότε η κλάση

Εστιατόριο θα ήταν υποψήφια κλάση του πεδίου προβλήματος.

• Ουσιαστικά που πιθανόν να αποτελέσουν ιδιότητες άλλων

κλάσεων (Χρόνος, Αναγνωριστικός Αριθμός, Θέση, Ποσότητα,

Απόθεμα). Βεβαίως αν προκύψει στη διαδικασία της ανάλυσης ότι

κάποιες από αυτές τις οντότητες έχουν λειτουργίες απαραίτητες

για το σύστημα, είναι απολύτως επιτρεπτό να εισαχθούν στη

συνέχεια στο μοντέλο του πεδίου προβλήματος.

Με βάση τις ανωτέρω εξαιρέσεις οι υποψήφιες κλάσεις του πεδίου

προβλήματος είναι:

Υποψήφιες κλάσεις

Παραγγελία

Πιάτο

Ουρά

Συστατικό



4.1.3 Καθορισμός σχέσεων μεταξύ κλάσεων

Πρωταρχικός στόχος κατά την κατασκευή του μοντέλου του πεδίου

προβλήματος είναι ο εντοπισμός σχέσεων μεταξύ των υποψηφίων

κλάσεων Ωστόσο, καθώς στην αντικειμενοστρεφή σχεδίαση υπάρχουν

πολλά είδη σχέσεων μεταξύ κλάσεων, δεν κρίνεται σκόπιμο στο στάδιο

αυτό να απεικονιστούν ιδιαίτερες λεπτομέρειες. Συνήθως αρκεί η

απεικόνιση στο μοντέλο σχέσεων τύπου "έχει" (has) και σχέσεων τύπου

"είναι" (is). Το πρώτο είδος αναφέρεται σε σχέσεις περιεκτικότητας

μεταξύ δύο κλάσεων που στην απλούστερη μορφή καλούνται

συναρμολογήσεις (ή συσσωματώσεις). Μια συναρμολόγηση υποδηλώνει

ότι αντικείμενα μιας κλάσης περιέχουν αντικείμενα μιας άλλης κλάσης. Η

συναρμολόγηση απεικονίζεται ως μια γραμμή μεταξύ των κλάσεων με

έναν λευκό ρόμβο στο άκρο της περιέχουσας κλάσης. Το δεύτερο είδος

αναφέρεται σε σχέσεις κληρονομικότητας μεταξύ κλάσεων. Μια σχέση

κληρονομικότητας υποδηλώνει ότι μια κλάση (υποκλάση) αποτελεί

ειδικότερη κατηγορία μιας άλλης (υπερκλάση) και κληρονομεί τις

ιδιότητες και τη συμπεριφορά της. Η κληρονομικότητα απεικονίζεται ως

μια γραμμή με ένα τρίγωνο στο άκρο της υπερκλάσης.

Από το κείμενο των απαιτήσεων υψηλού επιπέδου προκύπτει ότι μια

παραγγελία μπορεί να περιλαμβάνει πιάτα, μια ουρά περιλαμβάνει τις

παραγγελίες που τοποθετούνται σε αυτή και ένα πιάτο περιλαμβάνει τα

συστατικά από τα οποία αποτελείται. Σχέσεις κληρονομικότητας δεν



εντοπίζονται με βάση την περιγραφή που δόθηκε καθώς δεν υπάρχει

κάποια οντότητα που να αποτελεί ειδικότερη κατηγορία κάποιας άλλης.

Με βάση τις ανωτέρω πληροφορίες το αρχικό διάγραμμα του πεδίου

προβλήματος που προκύπτει, φαίνεται στο σχήμα 4.1.

Σχήμα 4.1: Διάγραμμα Πεδίου Προβλήματος (αρχικό)



4.2 Μοντέλο Περιπτώσεων Χρήσης (Use Case Model)

4.2.1 Περιπτώσεις χρήσης

Το μοντέλο περιπτώσεων χρήσης είναι μείζονος σημασίας στις

αντικειμενοστρεφείς μεθοδολογίες ανάπτυξης λογισμικού όπως η

ICONIX και η RUP καθώς θέτει τις βάσεις για τη δημιουργία

συστημάτων που δίνουν έμφαση στις απαιτήσεις του πελάτη. Στο μοντέλο

περιπτώσεων χρήσης καταγράφονται οι απαιτήσεις των χρηστών

διερευνώντας εξαντλητικά όλα τα πιθανά σενάρια χρήσης του

συστήματος. Μία περίπτωση χρήσης (use case) είναι μια ακολουθία

ενεργειών που ένας χρήστης του συστήματος (συνήθως πρόκειται για

άνθρωπο αλλά μπορεί να είναι οποιαδήποτε εξωτερική οντότητα όπως ένα

άλλο σύστημα) πραγματοποιεί στο σύστημα για να επιτύχει ένα

συγκεκριμένο σκοπό. Μία περίπτωση χρήσης απεικονίζεται

διαγραμματικά ως μία έλλειψη, μέσα στην οποία αναγράφεται το όνομα

της. Το σύνολο των περιπτώσεων χρήσης ενός συστήματος συνιστούν το

διάγραμμα περιπτώσεων χρήσης. Στα διαγράμματα αυτά είναι σημαντικό

εκτός από τις περιπτώσεις χρήσης να απεικονιστούν οι χρήστες του

συστήματος που συμμετέχουν σε κάθε περίπτωση. Οι χρήστες

απεικονίζονται ως σχηματικά ανθρωπάκια (stick persons). Η συσχέτιση

μεταξύ χρήστη και περίπτωσης χρήσης απεικονίζεται με μια γραμμή

μεταξύ τους (η οποία καλό είναι να μην έχει οποιαδήποτε κατεύθυνση για

την αποφυγή παρερμηνειών). Για το σύστημα διαχείρισης παραγγελιών το

διάγραμμα περιπτώσεων χρήσης φαίνεται στο σχήμα 4.2.



Σχήμα 4.2: Διάγραμμα Περιπτώσεων Χρήσης Συστήματος

Ο ορισμός μιας περίπτωσης χρήσης περιλαμβάνει όλες τις δυνατές

συμπεριφορές, περιλαμβανομένης της κανονικής ή βασικής ροής (όπου

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

του στόχου) αλλά και όλων των "εναλλακτικών" ροών, όπου κάτι για

παράδειγμα αποκλίνει από την "κανονική" συμπεριφορά. Μια περίπτωση

χρήσης είναι επιτυχής όταν προδιαγράφει μόνο "ποια" είναι η

συμπεριφορά του συστήματος χωρίς καμία αναφορά στο "πώς" αυτή

επιτυγχάνεται, χωρίς δηλαδή περιγραφή τεχνικών λεπτομερειών

υλοποίησης.



4.2.2 Τεκμηρίωση περιπτώσεων χρήσης

Προφανώς, διαγράμματα όπως αυτό του σχήματος 4.2 παρέχουν λίγη

πληροφορία σχετικά με τις απαιτήσεις από το σύστημα. Για το λόγο αυτό

κάθε περίπτωση χρήσης πρέπει να συνοδεύεται από κατάλληλη

τεκμηρίωση, όπου καταγράφονται τόσο η βασική όσο και όλες οι

εναλλακτικές ροές. Για την τεκμηρίωση των περιπτώσεων χρήσης

συνιστάται η τήρηση των εξής κανόνων:

• η φιλοσοφία της περιγραφής πρέπει να εστιάζει στην περιγραφή

ενός σεναρίου χρήσης ως σύνολο ενεργειών-αποκρίσεων. Με άλλα

λόγια, ο χρήστης πραγματοποιεί κάποια ενέργεια, το σύστημα

αποκρίνεται, ο χρήστης προβαίνει σε κάποια νέα ενέργεια κ.ο.κ.

μέχρις ότου επιτευχθεί ο σκοπός για τον οποίο ο χρήστης αξιοποιεί

το σύστημα λογισμικού (Σχήμα 4.3).

Σχήμα 4.3: Περίπτωση χρήσης ως σύνολο ενεργειών/αποκρίσεων



• οι προτάσεις είναι καλό να είναι γραμμένες σε ενεργητική φωνή,

στον ενεστώτα και να έχουν τη μορφή υποκείμενο-ρήμα-

αντικείμενο. Για παράδειγμα, Ο Μάγειρας επιλέγει το πλήκτρο

"Δημιουργία Πιάτου". Η μορφή αυτή συμβάλλει στην αποφυγή

περιγραφής τεχνικών λεπτομερειών του συστήματος και κυρίως

επιτρέπει την ευκολότερη μετάβαση στα επόμενα στάδια της

ανάλυσης και σχεδίασης. Στην ιδανική περίπτωση το υποκείμενο

και το αντικείμενο κάθε πρότασης αντιστοιχούν σε αντικείμενα

των κλάσεων του συστήματος και το ρήμα στο μήνυμα που

ανταλλάσσεται μεταξύ τους για την επίτευξη της επιθυμητής

λειτουργικότητας.

• είναι επιθυμητό να χρησιμοποιούνται στη διατύπωση των

περιπτώσεων χρήσης όσο το δυνατόν περισσότερο οι όροι του

μοντέλου του πεδίου προβλήματος. Λαμβάνοντας υπόψη ότι ένα

αντικειμενοστρεφές σύστημα είναι κατ' ουσίαν τα αντικείμενα των

κλάσεων του πεδίου προβλήματος (που βεβαίως εξελίσσεται και

εμπλουτίζεται), είναι χρήσιμο να διατυπωθούν οι απαιτήσεις του

προβλήματος όσο γίνεται πιο πρώιμα με τους όρους αυτών των

αντικειμένων.

• η περιγραφή της περίπτωσης χρήσης μπορεί να περιλαμβάνει

αναφορές σε βασικά στοιχεία της γραφικής διασύνδεσης χρήστη

(όπως οθόνες, πλήκτρα κλπ). Για το λόγο αυτό, είναι εξαιρετικά

χρήσιμο σε πολλές περιπτώσεις, πριν από την καταγραφή των



περιπτώσεων χρήσης, να δημιουργηθούν σε συνεργασία με τους

τελικούς χρήστες πρόχειρα σχέδια της αναμενόμενης γραφικής

διασύνδεσης, τα οποία αναφέρονται στη βιβλιογραφία ως

πρωτότυπα (prototypes). Στα πλαίσια αυτά, τα στοιχεία της

γραφικής διασύνδεσης (πρωτότυπα) που χρησιμοποιούνται πρέπει

να αναφέρονται με κάποιο όνομα και όχι αφηρημένα (π.χ. ο

χρήστης εισάγει στην Οθόνη Δημιουργίας Πιάτο το όνομα του

πιάτου και όχι ο χρήστης εισάγει σε κάποια οθόνη…). Ωστόσο, δεν

θα πρέπει να γίνεται αναφορά σε τεχνικές ή σχεδιαστικές

λεπτομέρειες καθώς ο στόχος της χρήσης πρώιμων δειγμάτων της

γραφικής διασύνδεσης είναι αποκλειστικά η διερεύνηση των

απαιτήσεων του πελάτη.

• τέλος, σημειώνεται ότι στο στάδιο της καταγραφής των

περιπτώσεων χρήσης είναι πολλές φορές κουραστική η αναζήτηση

όλων των πιθανών εναλλακτικών ροών που μπορούν να

εμφανιστούν σε ένα σενάριο χρήσης. Ωστόσο, κρίνεται ιδιαιτέρως

σημαντικό η διερεύνηση αυτή να γίνει σε αυτό το στάδιο, παρά σε

μεταγενέστερο στάδιο όπως η σχεδίαση ή η υλοποίηση. Η έγκαιρη

διατύπωση όλων των απαιτήσεων είναι κατά πολύ οικονομικότερη

και ασφαλέστερη από την τροποποίηση του σχεδίου ή του κώδικα

στη συνέχεια.



4.2.3 Πρότυπα τεκμηρίωσης περιπτώσεων χρήσης

Στη βιβλιογραφία έχουν προταθεί διάφορα πρότυπα για την τεκμηρίωση

των περιπτώσεων χρήσης. Τα πρότυπα μπορούν να ομαδοποιηθούν σε

τρεις γενικές κατηγορίες:

1. Απλές περιγραφές κειμένου χωρίς ιδιαίτερη δομή. Οι υποστηρικτές

αυτού του προτύπου δίνουν έμφαση στο ότι οι περιπτώσεις χρήσης πρέπει

να εστιάζουν στις απαιτήσεις του πελάτη και να μην εμπλέκουν τον

αναλυτή του συστήματος σε άλλες (μη απαιτούμενες) δραστηριότητες.

Προτείνεται η περιγραφή να μην ξεπερνά τις δύο παραγράφους ανά

περίπτωση χρήσης. Το πρότυπο αυτό χρησιμοποιείται στη συνέχεια για

την τεκμηρίωση των περιπτώσεων χρήσης του συστήματος διαχείρισης

παραγγελιών.

2. Πιο εκτεταμένες περιγραφές όπου διατυπώνεται ρητά ποια είναι η

βασική ροή και ποιες είναι οι εναλλακτικές ροές. Συνήθως

χρησιμοποιείται αρίθμηση για κάθε ενέργεια του χρήστη ή απόκριση του

συστήματος. Σε περίπτωση εναλλακτικών ροών χρησιμοποιείται ο

αντίστοιχος αριθμός για να υποδηλώσει το στάδιο του σεναρίου χρήσης

όπου αυτή εφαρμόζεται. Ένα τέτοιο παράδειγμα είναι:



Βασική Ροή

1. Ο χρήστης επιλέγει το πλήκτρο "Πληρωμή μέσω Κάρτας"

2. Το σύστημα εμφανίζει την οθόνη "Πληρωμή μέσω Κάρτας"

3. Ο χρήστης εισάγει τον αριθμό της κάρτας και το ποσό και επιλέγει

Αποστολή

4. Το σύστημα εμφανίζει μήνυμα ολοκλήρωσης της συναλλαγής

Εναλλακτική Ροή

4.α.1 Ο αριθμός της κάρτας δεν είναι έγκυρος

4.α.2 Το σύστημα εμφανίζει μήνυμα σφάλματος

4.α.3 Η περίπτωση χρήσης συνεχίζεται από το βήμα 2 της βασικής

ροής

3. Λεπτομερή πρότυπα όπου για κάθε περίπτωση χρήσης αναφέρονται:

α. Σύντομη περιγραφή

β. Προ-συνθήκες. Συνθήκες που πρέπει να ισχύουν ώστε να είναι

δυνατή η έναρξη της περίπτωσης χρήσης.

γ. Βασική Ροή

δ. Εναλλακτικές Ροές

ε. Μετά-συνθήκες. Συνθήκες που θα ισχύουν μετά την ολοκλήρωση

της περίπτωσης χρήσης.



4.2.4 Ενδεικτικές Οθόνες του Συστήματος

Στη λεκτική περιγραφή των περιπτώσεων χρήσης που ακολουθεί γίνεται

αναφορά σε οθόνες του συστήματος που θα αναπτυχθεί. Η πρόχειρη

σχεδίαση διεπαφών (οθονών) αποτελεί τμήμα της ανάλυσης των

απαιτήσεων, όπου επιχειρούμε να δείξουμε στον μελλοντικό χρήστη του

συστήματος την αναμενόμενη συμπεριφορά του υπό ανάπτυξη

συστήματος λογισμικού. Τα σχέδια αυτά δεν αποτελούν μια λεπτομερή

και ακριβή αποτύπωση της γραφικής διασύνδεσης χρήστη που θα έχει

τελικά το λογισμικό που θα αναπτυχθεί. Απλά θεωρείται ότι αποτελούν

ένα μέσο για την καλύτερη δυνατή συνεννόηση μεταξύ του τελικού

χρήστη και του αναλυτή με σκοπό την αποσαφήνιση της λειτουργικότητας

και τη διευκρίνιση τυχόν ασαφειών στις απαιτήσεις.

Οι ενδεικτικές οθόνες που παρουσιάζονται στη φάση αυτή δεν είναι

αναλυτικές (δηλαδή δεν περιλαμβάνονται όλα τα πλήκτρα, πεδία,

χρώματα, μηνύματα κλπ), καθώς κάτι τέτοιο θα ήταν δεσμευτικό για την

υλοποίηση, στοιχείο που δεν είναι επιθυμητό στο στάδιο της ανάλυσης

των απαιτήσεων. Επίσης, οι οθόνες δεν καλύπτουν το σύνολο των

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

κρίνεται σκόπιμο να διερευνηθούν. Οι οθόνες αυτές μπορούν να

δημιουργηθούν είτε με εργαλεία γραφικής σχεδίασης, είτε με γλώσσες

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

διασύνδεσης είτε ακόμη και ως πρόχειρα σχέδια που μπορούν να

σκαναριστούν.



Οι ενδεικτικές οθόνες που παρουσιάζονται στη συνέχεια είναι:

• η Κύρια Οθόνη της εφαρμογής (που παρουσιάζει στο χρήστη όλες τις

δυνατές επιλογές του),

• η οθόνη "Δημιουργία Πιάτου" που επιτρέπει στο μάγειρα να

δημιουργήσει νέα πιάτα,

• η οθόνη "Προσθήκη Παραγγελίας" που επιτρέπει στο σερβιτόρο να

καταχωρήσει στο σύστημα μια νέα παραγγελία,

• η οθόνη "Ετοιμασία Παραγγελίας" που επιτρέπει στο μάγειρα να

δηλώσει στο σύστημα πότε έχει ολοκληρωθεί η ετοιμασία των πιάτων

μιας παραγγελίας και

• η οθόνη "Υπολογισμός Χρόνου" που επιτρέπει στο μάγειρα να

υπολογίσει το χρόνο που απομένει μέχρι την ετοιμασία μιας

παραγγελίας.



Σχήμα 4.4: Κύρια Οθόνη

31

Σχήμα 4.5: Οθόνη "Δημιουργία Πιάτου"



Σχήμα 4.6: Οθόνη "Προσθήκη Παραγγελίας"

Σχήμα 4.7: Οθόνη "Ετοιμασία Παραγγελίας"



Σχήμα 4.8: Οθόνη "Υπολογισμός Χρόνου"

4.3 Τεκμηρίωση Περιπτώσεων Χρήσης

Στη συνέχεια παρουσιάζεται η τεκμηρίωση των περιπτώσεων χρήσης του

συστήματος Διαχείρισης Παραγγελιών σύμφωνα με το πρώτο και το

δεύτερο πρότυπο. Η ανάλυση βασίζεται στις προδιαγραφές υψηλού

επιπέδου που διατυπώθηκαν από τον πελάτη αλλά και σε (υποθετική)

διευκρίνιση ασαφειών που πραγματοποιήθηκε σε συνεργασία με τους

τελικούς χρήστες του συστήματος. Χάριν απλότητας, οι εναλλακτικές

ροές που έχουν καταγραφεί είναι περιορισμένες.

33



4.3.1 Περίπτωση Χρήσης 1: Δημιουργία Πιάτου

1ο Πρότυπο

Ο Μάγειρας επιλέγει στην Κύρια Οθόνη το πλήκτρο δημιουργία πιάτου.

Το σύστημα εμφανίζει την Οθόνη "Δημιουργία Πιάτου" η οποία λαμβάνει

τα ονόματα των συστατικών από τον Κατάλογο Συστατικών και τα

εμφανίζει. Ταυτόχρονα το σύστημα δημιουργεί το αντίστοιχο Πιάτο. Ο

Μάγειρας εισάγει την ονομασία του Πιάτου και στη συνέχεια επιλέγει το

πλήκτρο Καταχώρηση Ονόματος. Το σύστημα καταχωρεί το όνομα στο

Πιάτο. Στη συνέχεια ο Μάγειρας επιλέγει ένα συστατικό που περιέχει το

Πιάτο και εισάγει την αντίστοιχη ποσότητα που απαιτείται. Όταν ο

Μάγειρας επιλέξει το πλήκτρο Προσθήκη Συστατικού, το συστατικό που

επιλέχθηκε και η αντίστοιχη ποσότητα καταχωρείται στο Πιάτο. Όταν ο

Μάγειρας επιλέξει το πλήκτρο Τερματισμός, το Πιάτο εισάγεται στον

Κατάλογο Πιάτων και το σύστημα επιστρέφει στην Κύρια Οθόνη.



2ο Πρότυπο

Βασική Ροή

1. Ο Μάγειρας επιλέγει στην Κύρια Οθόνη το πλήκτρο

"δημιουργία πιάτου"

2. Το σύστημα εμφανίζει την Οθόνη "Δημιουργία Πιάτου" η

οποία λαμβάνει τα ονόματα των συστατικών από τον

Κατάλογο Συστατικών και τα εμφανίζει

3. Το σύστημα δημιουργεί το αντίστοιχο Πιάτο

4. Ο Μάγειρας εισάγει την ονομασία του Πιάτου και στη

συνέχεια επιλέγει το πλήκτρο "Καταχώρηση Ονόματος"

5. Το σύστημα καταχωρεί το όνομα στο Πιάτο

6. Ο Μάγειρας επιλέγει ένα συστατικό που περιέχει το Πιάτο και

εισάγει την αντίστοιχη ποσότητα που απαιτείται

7. Ο Μάγειρας επιλέγει το πλήκτρο Προσθήκη Συστατικού

8. Το σύστημα καταχωρεί το συστατικό που επιλέχθηκε και την

αντίστοιχη ποσότητα στο Πιάτο.

τα βήματα 6-8 επαναλαμβάνονται για όσα συστατικά επιθυμεί να

επιλέξει ο χρήστης

9. Ο Μάγειρας επιλέγει το πλήκτρο "Τερματισμός"

10. Το σύστημα εισάγει το Πιάτο στον Κατάλογο Πιάτων και

επιστρέφει στην Κύρια Οθόνη.



4.3.2 Περίπτωση Χρήσης 2: Προσθήκη Παραγγελίας

1ο Πρότυπο

Ο Σερβιτόρος επιλέγει στην Κύρια Οθόνη το πλήκτρο προσθήκη

παραγγελίας. Το σύστημα εμφανίζει την οθόνη Προσθήκη Παραγγελίας η

οποία λαμβάνει από τον Κατάλογο Πιάτων τα υπάρχοντα Πιάτα και τα

εμφανίζει. Ταυτόχρονα το σύστημα δημιουργεί μια νέα Παραγγελία με

έναν νέο αύξοντα κωδικό. Στη συνέχεια, ο Σερβιτόρος επιλέγει κάθε

Πιάτο που ζητήθηκε και το αντίστοιχο Πιάτο προστίθεται στην

Παραγγελία. Όταν η επιλογή Πιάτων ολοκληρωθεί ο Σερβιτόρος επιλέγει

το πλήκτρο ολοκλήρωση παραγγελίας, η Παραγγελία καταχωρείται στην

Ουρά Παραγγελιών και το σύστημα εμφανίζει την Κύρια Οθόνη.

Αν ο Σερβιτόρος επιλέξει Πιάτο όπου κάποιο από τα συστατικά έχει

εξαντληθεί, το πιάτο δεν προστίθεται στην παραγγελία και εμφανίζεται

μήνυμα προειδοποίησης.



2ο Πρότυπο

Βασική Ροή

1. Ο Σερβιτόρος επιλέγει στην Κύρια Οθόνη το πλήκτρο "προσθήκη παραγγελίας"

2. Το σύστημα εμφανίζει την οθόνη "Προσθήκη Παραγγελίας" η οποία λαμβάνει από τον Κατάλογο Πιάτων τα υπάρχοντα Πιάτα και τα εμφανίζει

3. Το σύστημα δημιουργεί μια νέα Παραγγελία με έναν νέο αύξοντα κωδικό

4. Ο Σερβιτόρος επιλέγει κάθε Πιάτο που ζητήθηκε και πατάει το πλήκτρο "επιλογή"

5. Το σύστημα προσθέτει το επιλεγμένο Πιάτο στην Παραγγελία. Τα βήματα 4, 5 επαναλαμβάνονται για όσα πιάτα επιθυμεί να επιλέξει ο χρήστης 6. Ο Σερβιτόρος επιλέγει το πλήκτρο "ολοκλήρωση παραγγελίας" 7. Το σύστημα καταχωρεί την Παραγγελία στην Ουρά

Παραγγελιών και εμφανίζει την Κύρια Οθόνη. Εναλλακτική Ροή 1

4.α.1 Ο Σερβιτόρος επιλέγει Πιάτο όπου κάποιο από τα συστατικά έχει εξαντληθεί 4.α.2 Το πιάτο δεν προστίθεται στην παραγγελία και εμφανίζεται μήνυμα προειδοποίησης

37

4.α.3. Η περίπτωση χρήσης συνεχίζει από το βήμα 4 της βασικής ροής



4.3.3 Περίπτωση Χρήσης 3: Ετοιμασία Παραγγελίας

1ο Πρότυπο

Ο Μάγειρας επιλέγει στην Κύρια Οθόνη το πλήκτρο ετοιμασία

παραγγελίας. Το σύστημα εμφανίζει την Οθόνη "Ετοιμασία Παραγγελίας"

η οποία λαμβάνει την πρώτη παραγγελία από την Ουρά παραγγελιών και

εμφανίζει τα πιάτα που περιλαμβάνει. Ο Μάγειρας επιλέγει κάθε πιάτο

και μόλις το ετοιμάσει επιλέγει το πλήκτρο Ολοκλήρωση. Με την

ολοκλήρωση ενός πιάτου αφαιρούνται από τα συστατικά που περιέχει το

πιάτο οι αντίστοιχες ποσότητες. Όταν ολοκληρωθούν όλα τα πιάτα από

μία παραγγελία η παραγγελία αφαιρείται από την Ουρά. Όταν ο Μάγειρας

κλείσει την οθόνη το σύστημα επιστρέφει στην Κύρια Οθόνη.



2ο Πρότυπο

Βασική Ροή

1. Ο Μάγειρας επιλέγει στην Κύρια Οθόνη το πλήκτρο ετοιμασία

παραγγελίας

2. Το σύστημα εμφανίζει την Οθόνη "Ετοιμασία Παραγγελίας" η

οποία λαμβάνει την πρώτη παραγγελία από την Ουρά

παραγγελιών και εμφανίζει τα πιάτα που περιλαμβάνει

3. Ο Μάγειρας επιλέγει ένα πιάτο και πατάει το πλήκτρο

"Ολοκλήρωση"

4. Το σύστημα αφαιρεί από τα συστατικά που περιέχει το πιάτο

τις αντίστοιχες ποσότητες

Τα βήματα 3, 4 επαναλαμβάνονται για όλα τα πιάτα της


5. Όταν ολοκληρωθούν όλα τα πιάτα από μία παραγγελία η

παραγγελία αφαιρείται από την Ουρά.

6. Ο Μάγειρας επιλέγει το πλήκτρο "Κλείσιμο"

7. Το σύστημα επιστρέφει στην Κύρια Οθόνη



4.3.4 Περίπτωση Χρήσης 4: Υπολογισμός Χρόνου

1ο Πρότυπο

Ο Σερβιτόρος επιλέγει στην Κύρια Οθόνη το πλήκτρο υπολογισμός

χρόνου. Το σύστημα εμφανίζει την Οθόνη "Υπολογισμός Χρόνου" η

οποία λαμβάνει από την Ουρά τους κωδικούς των παραγγελιών που

αναμένουν προς εξυπηρέτηση και τους εμφανίζει. Ο Σερβιτόρος επιλέγει

τον κωδικό της παραγγελίας για την οποία επιθυμεί να υπολογίσει τον

εκτιμώμενο χρόνο αναμονής και στη συνέχεια επιλέγει το πλήκτρο

υπολογισμός χρόνου. Η Ουρά υπολογίζει το χρόνο εντοπίζοντας τη θέση

της παραγγελίας που ζητήθηκε και υπολογίζοντας τα πιάτα για τις

παραγγελίες που βρίσκονται "μπροστά" από την ζητούμενη παραγγελία.

Στη συνέχεια αθροίζει 2 λεπτά για κάθε πιάτο της ζητούμενης

παραγγελίας. Το σύστημα εμφανίζει τον εκτιμώμενο χρόνο αναμονής.

Όταν ο Σερβιτόρος κλείσει την οθόνη το σύστημα επιστρέφει στην Κύρια

Οθόνη.



2ο Πρότυπο

1. Ο Σερβιτόρος επιλέγει στην Κύρια Οθόνη το πλήκτρο

υπολογισμός χρόνου

2. Το σύστημα εμφανίζει την Οθόνη "Υπολογισμός Χρόνου" η

οποία λαμβάνει από την Ουρά τους κωδικούς των παραγγελιών

που αναμένουν προς εξυπηρέτηση και τους εμφανίζει

3. Ο Σερβιτόρος επιλέγει τον κωδικό της παραγγελίας για την

οποία επιθυμεί να υπολογίσει τον εκτιμώμενο χρόνο αναμονής

4. Ο Σερβιτόρος επιλέγει το πλήκτρο "υπολογισμός χρόνου"

5. Η Ουρά υπολογίζει το χρόνο εντοπίζοντας τη θέση της

παραγγελίας που ζητήθηκε και υπολογίζοντας τα πιάτα για τις

παραγγελίες που βρίσκονται "μπροστά" από την ζητούμενη

παραγγελία. Στη συνέχεια αθροίζει 2 λεπτά για κάθε πιάτο της

ζητούμενης παραγγελίας

6. Το σύστημα εμφανίζει τον εκτιμώμενο χρόνο αναμονής

7. Ο Σερβιτόρος επιλέγει το πλήκτρο "Κλείσιμο"

8. Το σύστημα επιστρέφει στην Κύρια Οθόνη



5. Ανάλυση

5.1 Ανάλυση Ευρωστίας

5.1.1 Γέφυρα μεταξύ ανάλυσης και σχεδίασης

Η ανάλυση ευρωστίας (robustness analysis) αποτελεί μια τεχνική,

ενταγμένη στη φάση της ανάλυσης απαιτήσεων, για τη μετάβαση από τις

περιπτώσεις χρήσης σε ένα λεπτομερές σχέδιο. Η γεφύρωση του

χάσματος μεταξύ της ανάλυσης (που απαντά στο ερώτημα "τι" θα κάνει

το σύστημα) και της σχεδίασης (που απαντά στο ερώτημα "πώς" θα

ικανοποιηθούν οι απαιτήσεις του πελάτη) αναφέρεται στη μεθοδολογία

ICONIX ως ο πρωταρχικός στόχος της ανάλυσης ευρωστίας (Σχήμα 5.1).

Ως στάδιο, δεν έχει κάποιο παραδοτέο που να είναι απαραίτητο ή

υποχρεωτικό για τη συνέχεια σε άλλες φάσεις της διαδικασίας ανάπτυξης.

Είναι όμως μια εξαιρετική τεχνική για την εκλέπτυνση και αποσαφήνιση

του κειμένου των περιπτώσεων χρήσης και τον εντοπισμό ενός αρχικού

συνόλου αλληλεπιδρώντων αντικειμένων (κλάσεων) για την ικανοποίηση

της ζητούμενης λειτουργικότητας.



Σχήμα 5.1: Σημασία της ανάλυσης ευρωστίας στον κύκλο ζωής

λογισμικού

Κατά την ανάλυση ευρωστίας το κείμενο των περιπτώσεων χρήσης

μεταφράζεται σταδιακά (πρόταση προς πρόταση) σε μια γραφική

απεικόνιση κλάσεων και συμπεριφοράς (διάγραμμα ευρωστίας). Κάθε

οντότητα η οποία σύμφωνα με το μοντέλο πεδίου προβλήματος (ή

σύμφωνα με νεότερη κρίση των αναλυτών-σχεδιαστών) αποτελεί μια

κλάση του συστήματος, απεικονίζεται στο διάγραμμα ευρωστίας,

κατηγοριοποιώντας την με βάση ένα από τα ακόλουθα τρία στερεότυπα

κλάσεων:

• συνοριακές κλάσεις: κλάσεις που αποτελούν διασύνδεση μεταξύ

του συστήματος και του "εξωτερικού κόσμου", δηλαδή των

χειριστών του

• κλάσεις οντοτήτων: κλάσεις του μοντέλου πεδίου προβλήματος



• κλάσεις ελέγχου: κλάσεις που αποτελούν την "κόλλα" μεταξύ των

συνοριακών και των κλάσεων οντοτήτων και αναπαριστούν τη

συμπεριφορά του συστήματος.

Σε ένα διάγραμμα ευρωστίας οι κλάσεις συσχετίζονται μεταξύ τους,

υποδηλώνοντας την εννοιολογική συσχέτιση που υπάρχει ή υπονοείται

στο κείμενο των περιπτώσεων χρήσης.

5.1.2 Κανόνες σχεδίασης διαγραμμάτων ευρωστίας

Κατά τη σχεδίαση διαγραμμάτων ευρωστίας οφείλουν να τηρούνται οι

ακόλουθοι τρεις απλοί κανόνες:

• ουσιαστικά (χειριστές, συνοριακές κλάσεις και κλάσεις

οντοτήτων) δεν μπορούν να συσχετίζονται απευθείας με άλλα

ουσιαστικά

• ουσιαστικά μπορούν να συσχετίζονται με ρήματα (κλάσεις

ελέγχου) και το αντίθετο

• ρήματα μπορούν να συσχετίζονται με άλλα ρήματα.

Εναλλακτικά, δεν συνιστώνται οι συσχετίσεις που απεικονίζονται στο

ακόλουθο σχήμα:



Σχήμα 5.2: Μή συνιστώμενες συσχετίσεις σε διάγραμμα ευρωστίας

Οι κανόνες αυτοί ουσιαστικά επιβάλλουν την οργάνωση του κειμένου των

περιπτώσεων χρήσης κατά τέτοιο τρόπο ώστε να είναι δυνατή στη

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

ακολουθίας.

5.2 Διαγράμματα Ευρωστίας Συστήματος

Για το υπό ανάπτυξη σύστημα διαχείρισης παραγγελιών τα

διαγράμματα ευρωστίας για κάθε περίπτωσης χρήσης είναι (για την πρώτη

περίπτωση χρήσης η εξαγωγή του διαγράμματος ευρωστίας εξετάζεται

αναλυτικά ενώ για τις υπόλοιπες περιπτώσεις η διαδικασία που

ακολουθείται είναι ανάλογη):



5.2.1 Διάγραμμα Ευρωστίας 1: Δημιουργία Πιάτου

46

Η φράση "Ο Μάγειρας επιλέγει στην Κύρια Οθόνη το πλήκτρο δημιουργία

πιάτου" απεικονίζεται ως μια ακμή μεταξύ του χρήστη και της συνοριακής

κλάσης που αντιστοιχεί στην Κύρια Οθόνη. Η φράση "Το σύστημα

εμφανίζει την Οθόνη Δημιουργία Πιάτου" υποδηλώνει την ύπαρξη στο

διάγραμμα ευρωστίας μιας συνοριακής κλάσης για την "Οθόνη

Δημιουργίας Πιάτου". Τηρώντας τον κανόνα που δεν επιτρέπει την

απευθείας συσχέτιση μεταξύ συνοριακών κλάσεων, εισάγεται μια κλάση

ελέγχου που αντιστοιχεί στην ενέργεια της εμφάνισης της οθόνης (από

την Κύρια Οθόνη), ως απόκριση στην επιλογή του χρήστη. Η φράση "η

οποία λαμβάνει τα ονόματα των συστατικών από τον Κατάλογο Συστατικών

και τα εμφανίζει" επιβάλλει την εισαγωγή μια κλάσης οντότητας που

αντιστοιχεί στον Κατάλογο Συστατικών και μιας κλάσης ελέγχου που

αντιστοιχεί στην ενέργεια της λήψης των ονομάτων των συστατικών από

τον κατάλογο. Η φράση "Ταυτόχρονα το σύστημα δημιουργεί το αντίστοιχο

Πιάτο" οδηγεί στην εισαγωγή στο διάγραμμα μια κλάσης οντότητας που

αντιστοιχεί στο Πιάτο και μιας κλάσης ελεγκτή που αντιστοιχεί στην

ενέργεια της δημιουργίας ενός στιγμιοτύπου της κλάσης Πιάτο. Παρόλο

που η σημειολογία των διαγραμμάτων ευρωστίας δεν είναι αυστηρή,

υποθέτουμε ότι η χρονική σειρά των ενεργειών που πραγματοποιείται σε

κάποιο σημείο ακολουθεί τη δεξιόστροφη φορά των ακμών που

εκβάλλουν από το σημείο αυτό. Με άλλα λόγια θεωρούμε ότι πρώτα

πραγματοποιείται η λήψη των συστατικών και η εμφάνισή τους στην



Οθόνη Δημιουργίας Πιάτου και μετά δημιουργείται το αντίστοιχο πιάτο.

Ωστόσο, η θεώρηση αυτή δεν είναι δεσμευτική και μπορεί να

τροποποιηθεί στη συνέχεια.

Η φράση "Ο Μάγειρας εισάγει την ονομασία του Πιάτου και στη

συνέχεια επιλέγει το πλήκτρο Καταχώρηση Ονόματος" θα έπρεπε κανονικά

να συμβολιστεί ως μια ακμή από το χρήστη προς την Οθόνη Δημιουργίας

Πιάτου όπου πραγματοποιούνται αυτές οι ενέργειες. Ωστόσο, αν γινόταν

αυτός ο συμβολισμός, δεν θα ήταν σαφές ποια από τις ενέργειες – ακμές

που εκβάλλουν από τη συνοριακή κλάση Οθόνη Δημιουργίας Πιάτου

οφείλεται στην πρώτη ενέργεια του χρήση (επιλογή δημιουργίας πιάτου)

και ποια στη δεύτερη (εισαγωγή ονομασίας και επιλογή καταχώρησης).

Για το λόγο αυτό επιλέχθηκε ο συμβολισμός της ενέργειας του χρήστη ως

ετικέτα στην αντίστοιχη ακμή που καταλήγει στην κλάση ελέγχου

Καταχώρηση και τελικά συνδέεται με την κλάση οντότητας Πιάτο για να

μοντελοποιήσει το αποτέλεσμα της φράσης "Το σύστημα καταχωρεί το

όνομα στο Πιάτο".

Οι φράσεις "Στη συνέχεια ο Μάγειρας επιλέγει ένα συστατικό που

περιέχει το Πιάτο και εισάγει την αντίστοιχη ποσότητα που απαιτείται" και

"Όταν ο Μάγειρας επιλέξει το πλήκτρο Προσθήκη Συστατικού, το συστατικό

που επιλέχθηκε και η αντίστοιχη ποσότητα καταχωρείται στο Πιάτο"

μοντελοποιούνται ως μια εξερχόμενη ακμή από την Οθόνη Δημιουργίας

Πιάτου με ετικέτα "επιλογή συστατικού/ποσότητα και επιλογή

καταχώρησης" που καταλήγει στην κλάση ελέγχου Καταχώρηση. Η



κλάση ελέγχου μοντελοποιεί την ενέργεια της καταχώρησης των

στοιχείων σε ένα αντικείμενο της κλάση Πιάτο. Η φράση "Όταν ο

Μάγειρας επιλέξει το πλήκτρο Τερματισμός, το Πιάτο εισάγεται στον

Κατάλογο Πιάτων" μοντελοποιείται ως μια ακμή με ετικέτα "επιλογή

τερματισμού" που καταλήγει στην κλάση ελέγχου εισαγωγή Πιάτου. Η

κλάση ελέγχου αντιστοιχεί στην ενέργεια της εισαγωγής του αντικειμένου

(πιάτου) που δημιουργήθηκε στην κλάση οντότητας Κατάλογος Πιάτων.

Τέλος, η φράση "το σύστημα επιστρέφει στην Κύρια Οθόνη" αντιστοιχεί

στην ενέργεια της εμφάνισης από το σύστημα της Κύριας Οθόνης που

πραγματοποιείται όταν ο χρήστης επιλέξει τον τερματισμό.

Το συνολικό διάγραμμα ευρωστίας με βάση την ανωτέρω ανάλυση

παρουσιάζεται στο ακόλουθο σχήμα. Η λύση που προτείνεται δεν είναι η

μοναδική. Σε κάθε περίπτωση η ορθότητα του διαγράμματος είναι

δύσκολο να ελεγχθεί. Ο σκοπός του όμως επιτυγχάνεται όσο το κείμενο

των περιπτώσεων χρήσης αποσαφηνίζεται και προετοιμάζεται ώστε να

επιτρέψει την περαιτέρω σχεδίαση του συστήματος.



49

Σχήμα 5.3: Διάγραμμα Ευρωστίας για την Περίπτωση Χρήσης

"Δημιουργία Πιάτου"

Κύρια Οθόνη εμφάνισεΜάγειρας

επιλογή∆ημιουργίας Πιάτου

Οθόνη ∆ημιουργίας Πιάτου

Κατάλογος Συστατικών

λήψη ονομάτων

Πιάτο

δημιουργία

εισαγωγή Πιάτου

επιλογή τερματισμού

Κατάλογος Πιάτων

καταχώρηση

επιλογή συστατικού/ποσοτήταςκαι επιλογή προσθήκης

εμφάνισε


εισαγωγή ονόματος και επιλογή καταχώρησης

Visual Paradigm for UML Enterprise Edition(ICT_IVE_TY)



5.2.2 Διάγραμμα Ευρωστίας 2: Προσθήκη Παραγγελίας


"Προσθήκη Παραγγελίας"

Κύρια Οθόνη εμφάνισεΣερβιτόρος

επιλογή προσθήκης παραγγελίας


Πιάτο

δημιουργία

Κατάλογος Πιάτων


εμφάνισε

Οθόνη Προσθήκης Παραγγελίας


υπάρχουν συστατικά?

ναι

εμφάνισε

όχι

Μήνυμα Προειδοποίησης


ολοκλήρωση παραγγελίας

Ουρά

επιλογή Πιάτου




5.2.3 Διάγραμμα Ευρωστίας 3: Ετοιμασία Παραγγελίας


"Ετοιμασία Παραγγελίας"

Μάγειρας Κύρια Οθόνη

επιλογή ετοιμασία παραγγελίας

Οθόνη Ετοιμασίας Παραγγελίας

εμφάνισεΟυρά

λήψη πρώτης παραγγελίας

Παραγγελίαεπιλογή πιάτου

επιλογή πιάτουκαι ολοκλήρωση

αφαίρεση συστατικών Πιάτο

ολοκλήρωση όλων των πιάτων;αφαίρεση παραγγελίαςΝΑΙ

εμφάνισε

επιλογή τερματισμούλήψη Πιάτων

Συστατικό

αφαίρεση ποσότητας




5.2.4 Διάγραμμα Ευρωστίας 4: Υπολογισμός Χρόνου


"Υπολογισμός Χρόνου"

Σερβιτόρος Κύρια Οθόνηεπιλογή

Υπολογισμού Χρόνου εμφάνισε

Οθόνη Υπολογισμού Χρόνου

Ουρά

λήψη παραγγελιών

εμφάνισε

επιλογή τερματισμού

υπολογισμός χρόνου

επιλογή κωδικού παραγγελίας

και πλήκτρου υπολογισμούεύρεση θέσης παραγγελίας

υπολογισμός πιάτων που αναμένουν

εμφάνισεεκτιμώμενος χρόνος

άθροιση χρόνων


5.3 Αναθεώρηση του μοντέλου πεδίου προβλήματος

Από τη διερεύνηση των περιπτώσεων χρήσης και τη δημιουργία των

διαγραμμάτων ευρωστίας είναι αναμενόμενο και επιθυμητό να

εντοπιστούν νέες κλάσεις που δεν συμπεριελήφθησαν αρχικά στο μοντέλο

πεδίου προβλήματος. Επίσης, το στάδιο της ανάλυσης οδηγεί και στον

εντοπισμό ορισμένων από τις ιδιότητες των κλάσεων καθώς αυτές είτε

αναφέρονται ρητά στο κείμενο των περιπτώσεων χρήσης αλλά επιλέγεται

να μην αντιστοιχισθούν σε κλάσεις του συστήματος είτε υπονοούνται. Για

το σύστημα που αναπτύσσεται, το μοντέλου του πεδίου προβλήματος

εμπλουτίζεται ως εξής (καθώς από το εξελισσόμενο διάγραμμα κλάσεων

πρόκειται να παραχθεί ένα μεγάλο τμήμα του κώδικα κρίνεται σκόπιμο



από το σημείο αυτό και μετά να παρατίθενται και οι αγγλικοί όροι για τις

ονομασίες κλάσεων, ιδιοτήτων και μεθόδων):

Από την περίπτωση χρήσης 1 και το αντίστοιχο διάγραμμα ευρωστίας

προκύπτει ότι στο μοντέλο πεδίου προβλήματος πρέπει να συμπεριληφθεί

η κλάση Κατάλογος Συστατικών (IngredientCatalog) και η κλάση

Κατάλογος Πιάτων (PlateCatalog). Τέτοιες κλάσεις, που λειτουργούν ως

συλλογές αντικειμένων κλάσεων οντοτήτων είναι αναμενόμενες στις

περισσότερες εφαρμογές, ακόμα και αν δεν αναφέρονται ρητά στις

απαιτήσεις, καθώς επιτρέπουν τον εντοπισμό και την ανάκτηση των

αντικειμένων των κλάσεων οντοτήτων. Οι δύο αυτές κλάσεις

περιλαμβάνουν αντικείμενα των κλάσεων Συστατικό (Ingredient) και

Πιάτο (Plate) αντίστοιχα, και για το λόγο αυτό συνδέονται με σχέση

συναρμολόγησης με αυτές με πολλαπλότητα πολλά στο άκρο των

κλάσεων οντοτήτων. Από το ίδιο διάγραμμα ευρωστίας προκύπτει ότι η

κλάση Συστατικό καθώς και η κλάση Πιάτο θα περιλαμβάνουν μια

ιδιότητα όνομα (name) καθώς τα ονόματα των συστατικών εμφανίζονται

στην Οθόνη Δημιουργίας Πιάτου ενώ ο χρήστης ρητά αναφέρεται ότι

εισάγει το όνομα κάθε πιάτου που δημιουργεί. Ακολουθώντας την αρχή

της ενσωμάτωσης που επιβάλλει η πρόσβαση στις ιδιότητες ενός

αντικειμένου να πραγματοποιείται μόνο μέσω της δημόσιας διασύνδεσης

της κλάσης, όλες οι ιδιότητες μιας κλάσης ορίζονται να έχουν ορατότητα

ιδιωτική (private). Η ιδιωτική ορατότητα υποδηλώνεται στο διάγραμμα

κλάσεων της UML με ένα σύμβολο '-' πριν από το όνομα κάθε ιδιότητας.



Αξίζει να σημειωθεί ότι στο στάδιο της ανάλυσης δεν είναι απαραίτητο να

απεικονίζονται στο διάγραμμα κλάσεων οι τύποι δεδομένων κάθε

ιδιότητας. Η σύμβαση που ακολουθείται είναι τα ονόματα κλάσεων να

ξεκινούν με κεφαλαίο γράμμα, ενώ τα ονόματα των ιδιοτήτων και

μεθόδων να ξεκινούν με πεζό γράμμα.

Από την περίπτωση χρήσης 2 προκύπτει ότι κατά τη δημιουργία μιας

νέας παραγγελίας καταχωρείται σε αυτήν ένας νέος αύξοντας κωδικός και

επομένως μια ιδιότητα κωδικός (code) προστίθεται στην κλάση

Παραγγελία (Order).

Από την περίπτωση χρήσης 3 και το αντίστοιχο διάγραμμα ευρωστίας

συνάγεται ότι κατά την ετοιμασία ενός πιάτου αφαιρούνται από τα

συστατικά που περιέχει οι αντίστοιχες ποσότητες. Επομένως στην κλάση

Συστατικό προστίθεται μια ιδιότητα ποσότητα (amount).

Στο αναθεωρημένο μοντέλο του πεδίου προβλήματος σημειώνονται

πλέον και σύμβολα πολλαπλότητας στις σχέσεις συναρμολόγησης. Το

αναθεωρημένο διάγραμμα απεικονίζεται στο σχήμα 5.7.



Σχήμα 5.7: Αναθεωρημένο Μοντέλο Πεδίου Προβλήματος



6. Σχεδίαση

6.1 Διαγράμματα Ακολουθίας (Sequence diagrams)

6.1.1 Κατανομή λειτουργικότητας

Με την ολοκλήρωση των σταδίων της ανάλυσης οι προδιαγραφές του

συστήματος υπό μορφή περιπτώσεων χρήσης έχουν παγιωθεί και μπορούν

να θεωρηθούν πλήρεις, ορθές, λεπτομερείς και σαφείς. Επιπλέον έχουν

εντοπιστεί οι περισσότερες κλάσεις, δηλαδή ολοκληρώθηκε το

μεγαλύτερο τμήμα της στατικής δομής του λογισμικού.

Ωστόσο, λίγες ενέργειες στη φάση της ανάλυσης είχαν ως στόχο την

κατανομή της συμπεριφοράς στις κλάσεις του συστήματος. Ο ακριβής

καθορισμός του τρόπου με τον οποίο οι κλάσεις (τα αντικείμενά τους)

αλληλεπιδρούν μεταξύ τους, δηλαδή ο προσδιορισμός μέρους της

δυναμικής συμπεριφοράς του συστήματος, αποτελούν αντικείμενο της

σχεδίασης. Ως επακόλουθο αυτής της κατανομής λειτουργικότητας

προκύπτει το αναθεωρημένο διάγραμμα κλάσεων όπου εκτός από τις

κλάσεις και τις ιδιότητές τους, απεικονίζονται οι μέθοδοί τους και τυχόν

νέες σχέσεις μεταξύ τους. Το τελικό αυτό διάγραμμα κλάσεων αποτελεί

την είσοδο για την έναρξη της κωδικοποίησης του συστήματος (αν και

είναι αναμενόμενο το διάγραμμα κλάσεων να τροποποιηθεί ως ένα βαθμό

κατά την υλοποίηση).

56

Η κατανομή της λειτουργικότητας στις κλάσεις επιτυγχάνεται με την

κατάστρωση διαγραμμάτων ακολουθίας. Ένα διάγραμμα ακολουθίας



απεικονίζει τα μηνύματα που ανταλλάσσουν τα αντικείμενα του

συστήματος μεταξύ τους για την ικανοποίηση της λειτουργικότητας ενός

σεναρίου χρήσης (που συνήθως αντιστοιχεί σε μια περίπτωση χρήσης).

Στα πλαίσια του αντικειμενοστρεφούς μοντέλου ένα μήνυμα προς ένα

αντικείμενο A αντιστοιχεί σε αίτημα για την εκτέλεση μιας λειτουργίας

από πλευράς του Α. Η οργάνωση των διαγραμμάτων ακολουθίας γίνεται

σε δύο διαστάσεις. Σε οριζόντια διάταξη παρατίθενται τα αντικείμενα των

κλάσεων που αλληλεπιδρούν στο υπό εξέταση σενάριο. Η κάθετη

διάσταση αντιστοιχεί στην κλίμακα του χρόνου, δηλαδή η εμφάνιση ενός

μηνύματος σε χαμηλότερη θέση από κάποιο άλλο, υποδηλώνει και την

αποστολή του σε μεταγενέστερο χρόνο.

6.1.2 Παράδειγμα διαγράμματος ακολουθίας

Τα συνηθέστερα διαγραμματικά στοιχεία που εμφανίζονται σε ένα

διάγραμμα ακολουθίας απεικονίζονται στο σχήμα 6.1, που αναφέρεται σε

ένα σύστημα τραπεζικών συναλλαγών μέσω ATM.



Σχήμα 6.1: Στοιχεία διαγράμματος ακολουθίας

Στο ανωτέρω διάγραμμα τα μηνύματα μεταξύ των αντικειμένων έχουν

αριθμηθεί για λόγους ευκολότερης αναφοράς. Οι γραμμές που εκτείνονται

κάτω από κάθε αντικείμενο του διαγράμματος ονομάζονται γραμμές ζωής

(lifeline). Με τη λήψη ενός μηνύματος η γραμμή ζωής αντικαθίσταται με

ένα ορθογώνιο που ονομάζεται πλαίσιο ενεργοποίησης και αντιστοιχεί

στη διάρκεια εκτέλεσης της λειτουργίας που εξυπηρετεί το μήνυμα που

λήφθηκε. Η αναπαράσταση του πλαισίου ενεργοποίησης σύμφωνα με

πολλούς συγγραφείς θα πρέπει να αποφεύγεται καθώς προσθέτει περιττή



πολυπλοκότητα στο διάγραμμα, υπό την έννοια ότι δεν συμβάλλει στην

κατανομή της λειτουργικότητας σε κλάσεις.

6.1.3 Τύποι μηνυμάτων σε διαγράμματα ακολουθίας

Ο συνηθέστερος τύπος μηνύματος αντιστοιχεί στην κλήση μιας

λειτουργίας ενός αντικειμένου και συμβολίζεται ως μια

προσανατολισμένη ακμή με το βέλος από τον αποστολέα προς τον

παραλήπτη (τέτοια μηνύματα είναι για παράδειγμα το 2 και το 6 στο

ανωτέρω σχήμα). Ο συμβολισμός αφορά σύγχρονα μηνύματα, δηλαδή

μηνύματα όπου ο αποστολέας αναμένει την ολοκλήρωση της λειτουργίας

από τον παραλήπτη για να συνεχίσει. Επάνω από κάθε μήνυμα

σημειώνεται το όνομα της λειτουργίας που καλείται καθώς και οι

ενδεχόμενες παράμετροι που απαιτούνται.

Η ολοκλήρωση της λειτουργίας που ζητήθηκε από ένα αντικείμενο

απεικονίζεται ως μία διακεκομμένη ακμή που επιστρέφει από το κληθέν

αντικείμενο σε αυτό που πραγματοποίησε την κλήση και ονομάζεται

επιστροφή μηνύματος. Επάνω στην ακμή σημειώνεται προαιρετικά η τιμή

(ή οι τιμές) που επιστρέφονται, αν υπάρχουν. Τέτοια μηνύματα είναι τα

μηνύματα 3 και 9 στο ανωτέρω σχήμα. Συνήθως, οι επιστροφές

μηνυμάτων δεν απεικονίζονται στα διαγράμματα ακολουθίας.

Σε περίπτωση που η αποστολή μηνύματος προκαλεί τη δημιουργία

ενός αντικειμένου πρόκειται για μήνυμα δημιουργίας. Απεικονίζεται ως

ακμή όπου στο όνομα του μηνύματος σημειώνεται ρητά ο όρος



"δημιουργία" μαζί με τυχόν παραμέτρους που απαιτούνται από τον

κατασκευαστή της κλάσης. Για λόγους ευκολότερης κατανόησης, κατά τη

δημιουργία αντικειμένου, το αντικείμενο που υλοποιείται τοποθετείται

χαμηλότερα από τα υπόλοιπα, στο ύψος του μηνύματος, συμβολίζοντας

ότι το αντικείμενο δεν υφίστατο πριν την αποστολή του μηνύματος.

Τέτοιο μήνυμα δημιουργίας είναι το υπ' αριθμό 7 στο σχήμα 6.1.

Το μήνυμα υπ' αριθμό 8 στο διάγραμμα ακολουθίας του σχήματος 6.1

αποτελεί μία αυτοκλήση. Με άλλα λόγια το μήνυμα αποστέλλεται από

ένα αντικείμενο στον εαυτό του. Προγραμματιστικά αντιστοιχεί στην

κλήση μιας μεθόδου (δημόσιας ή συνηθέστερα ιδιωτικής) του ιδίου

αντικειμένου. Μηνύματα αυτοκλήσεων δεν κρίνεται σκόπιμο να

απεικονίζονται για όλες τις κλήσεις μεθόδων εντός μιας κλάσης, αλλά

μόνο στις περιπτώσεις που είναι επιθυμητό να δοθεί έμφαση σε κάποια

λειτουργία που εκτελείται.

Προγραμματιστικά, η αποστολή ενός μηνύματος από ένα αντικείμενο

(αποστολέας) προς κάποιο άλλο (αποδέκτης), προϋποθέτει την ύπαρξη

μιας κατάλληλης μεθόδου στην κλάση του αποδέκτη, ώστε να μπορεί να

αποκριθεί στο αίτημα που υποβάλλεται από τον αποστολέα. Η σύμβαση

αυτή αποτελεί τη βάση για την κατανομή της λειτουργικότητας του

συστήματος. Υπενθυμίζεται, ότι για κάθε περίπτωση χρήσης, οι χειριστές

που εμπλέκονται, τα αντικείμενα που αντιστοιχούν σε συνοριακές κλάσεις

αλλά και τα αντικείμενα των κλάσεων οντοτήτων μεταφέρονται αυτούσια

στο διάγραμμα ακολουθίας. Δεν μεταφέρονται όμως και τα αντικείμενα



των κλάσεων ελεγκτών καθώς συνήθως οι κλάσεις αυτές μεταφράζονται

σε μηνύματα μεταξύ των αντικειμένων.

Σημειώνεται ότι στα διαγράμματα ακολουθίας πρέπει γενικά να

αποφεύγεται η καταγραφή της ροής ελέγχου του συστήματος. Τα

διαγράμματα ακολουθίας δεν αντικαθιστούν τα παλαιότερα διαγράμματα

ροής όπου αναλύεται λεπτομερώς ένας αλγόριθμος, καταγράφοντας όλες

τις πιθανές διαδρομές ανάλογα με τις τιμές διαφόρων συνθηκών (το ρόλο

αυτό στη UML έχουν τα διαγράμματα δραστηριότητας). Σε εξαιρετικές

μόνο περιπτώσεις πρέπει να χρησιμοποιούνται συμβολισμοί για την

απεικόνιση επαναληπτικών δομών ή αποστολής μηνυμάτων υπό συνθήκη.

Παρόλο που πολλοί συγγραφείς είναι τελείως αντίθετοι με την απεικόνιση

της ροής ελέγχου σε διαγράμματα ακολουθίας, η νεότερη έκδοση του

προτύπου της Ενοποιημένης Γλώσσας Μοντελοποίησης (UML 2) παρέχει

τη δυνατότητα απεικόνισης των δομών της επανάληψης και της επιλογής.

Για το σκοπό αυτό έχει εισαχθεί ο συμβολισμός του συνδυασμένου

τμήματος (combined fragment) που χρησιμοποιείται για την ομαδοποίηση

ενός συνόλου μηνυμάτων που εκτελούνται υπό συνθήκη. Σύμφωνα με το

πρότυπο UML 2 υπάρχουν 11 περιπτώσεις για τα συνδυασμένα τμήματα.

Στη συνέχεια θα παρουσιαστούν δύο συνήθεις περιπτώσεις που

αξιοποιούνται και στα διαγράμματα ακολουθίας του συστήματος

διαχείρισης παραγγελιών.



6.1.4 Εναλλακτικές

Οι εναλλακτικές (alternatives) χρησιμοποιούνται για να υποδηλώσουν

έναν αμοιβαίο αποκλεισμό μεταξύ δύο ή περισσοτέρων ακολουθιών από

μηνύματα. Επιτρέπουν τη μοντελοποίηση της κλασσικής "if then else"

λογικής. Ένα παράδειγμα διαγράμματος ακολουθίας όπου

χρησιμοποιείται ο συμβολισμός του συνδυασμένου τμήματος των

εναλλακτικών παρουσιάζεται στο σχήμα 6.2.

Σχήμα 6.2: Αναπαράσταση λογικής if/else σε διάγραμμα ακολουθίας



Το συνδυασμένο τμήμα εναλλακτικών αναπαρίσταται ως ένα πλαίσιο με

το όνομα "alt". Το ευρύτερο ορθογώνιο διαχωρίζεται σε δύο περιοχές που

σύμφωνα με τη UML 2 ονομάζονται τελεστέοι. Οι τελεστέοι

διαχωρίζονται από μία διακεκομμένη γραμμή. Σε κάθε τελεστέο υπάρχει

μία συνθήκη-φρουρός (σημειώνεται μέσα σε [ ] ). Αν κατά την εκτέλεση

του σεναρίου η τιμή της συνθήκης-φρουρού αποτιμάται ως αληθής

εκτελείται ο αντίστοιχος τελεστέος. Στο ανωτέρω διάγραμμα, αν το

υπόλοιπο του λογαριασμού (balance) είναι μεγαλύτερο ή ίσο προς το

ποσό που ζητείται από το τσεκ (amount), αποστέλλεται το μήνυμα

registerTransaction() από το αντικείμενο bank προς το αντικείμενο

account. Σε αντίθετη περίπτωση, αποστέλλεται το μήνυμα

transactionCancelled() από το αντικείμενο bank προς το

αντικείμενο check.

63



6.1.5 Βρόχοι

Οι βρόχοι (loops) χρησιμοποιούνται για να υποδηλώσουν μια

επαναληπτική διαδικασία. Επιτρέπουν τη μοντελοποίηση της κλασσικής

λογικής "while(συνθήκη)". Ένα παράδειγμα διαγράμματος ακολουθίας

όπου χρησιμοποιείται ο συμβολισμός του συνδυασμένου τμήματος των

βρόχων παρουσιάζεται στο σχήμα 6.3.


Σχήμα 6.3: Αναπαράσταση επαναληπτικών δομών σε διάγραμμα

ακολουθίας


Το συνδυασμένο τμήμα βρόχου αναπαρίσταται ως ένα πλαίσιο με το

όνομα "loop". Στο πάνω αριστερό τμήμα του πλαισίου τοποθετείται μία

συνθήκη-φρουρός. Η ακολουθία των μηνυμάτων που περιλαμβάνονται

στο πλαίσιο εκτελείται επαναληπτικά όσο η τιμή της συνθήκης

αποτιμάται ως αληθής. Στο ανωτέρω παράδειγμα όσο υπάρχουν επιπλέον

φοιτητές (hasAnotherStudent = true), το αντικείμενο aCourse αποστέλλει

τo μήνυμα getNextStudent() στο αντικείμενο list, getResult()

στο αντικείμενο aStudent, το μήνυμα addStudent() στο αντικείμενο

aReport (εάν και μόνο αν η τιμή result είναι μεγαλύτερη του 5) και τέλος

το μήνυμα hasAnotherStudent() στο αντικείμενο list για να

ενημερωθεί η τιμή βάσει της οποίας γίνεται ο έλεγχος της συνθήκης για

τις επαναλήψεις.

Για τις περιπτώσεις χρήσης του συστήματος διαχείρισης παραγγελιών,

δημιουργούνται τα ακόλουθα διαγράμματα ακολουθίας χρησιμοποιώντας

ως οδηγό τα αντίστοιχα διαγράμματα ευρωστίας (για το πρώτο διάγραμμα

η κατάστρωση του παρουσιάζεται αναλυτικά).

65



6.2 Σύστημα Διαχείρισης Παραγγελιών

6.2.1 Διάγραμμα Ακολουθίας 1: Δημιουργία Πιάτου Το διάγραμμα ακολουθίας καταστρώνεται ως εξής: Στον οριζόντιο άξονα

των αντικειμένων τοποθετούνται, εξετάζοντας το αντίστοιχο διάγραμμα

ευρωστίας, οι χειριστές της περίπτωσης χρήσης (στην προκειμένη

περίπτωση ο μάγειρας), τα αντικείμενα των συνοριακών κλάσεων (η

Κύρια Οθόνη, η Οθόνη Δημιουργίας Πιάτου) και τα αντικείμενα των

κλάσεων οντοτήτων (Κατάλογος Συστατικών, Συστατικό και Κατάλογος

Πιάτων). Οι κλάσεις ελέγχου δεν εμφανίζονται στη συνήθη περίπτωση ως

αντικείμενα στο διάγραμμα ακολουθίας αλλά "μεταφράζονται" σε

μηνύματα μεταξύ των υπολοίπων κλάσεων. Λαμβάνοντας υπόψη ότι σε

ένα διάγραμμα ακολουθίας απεικονίζεται η αλληλεπίδραση μεταξύ

χρήστη και συστήματος για ένα συγκεκριμένο σενάριο χρήσης, το πρώτο

μήνυμα (με αρίθμηση 1) είναι η επιλογή από το χρήστη του πλήκτρου

"Δημιουργία Πιάτου" που αποστέλλεται στην Κύρια Οθόνη.

66

Στη συνέχεια, και με βάση το διάγραμμα ευρωστίας η Κύρια Οθόνη

αποστέλλει το μήνυμα εμφάνισης (αντικείμενο ελεγκτή "εμφάνισε" στην

Οθόνη Δημιουργίας Πιάτου - αντικείμενο συνοριακής κλάσης).

Εκλαμβάνοντας τις ενέργειες που απεικονίζονται στο διάγραμμα

ευρωστίας με δεξιόστροφη σειρά προτεραιότητας συμπεραίνεται ότι το

πρώτο μήνυμα που αποστέλλει η οθόνη Δημιουργίας Πιάτου είναι το

αίτημα λήψης ονομάτων συστατικών προς τον Κατάλογο Συστατικών. Ο

ίδιος ο κατάλογος δεν περιλαμβάνει μια λίστα των ονομάτων όλων των



συστατικών, απλά περιέχει μια δομή δεδομένων με αναφορές προς τα

συστατικά που περιλαμβάνει. Κατά συνέπεια το όνομα του κάθε

συστατικού μπορεί να "αντληθεί" αποστέλλοντας μήνυμα σε κάθε

αντικείμενο της κλάσης Συστατικό που περιλαμβάνει ο κατάλογος. Για το

λόγο αυτό, παρόλο που κάτι τέτοιο δεν καταγράφεται στο διάγραμμα

ευρωστίας, επιλέγουμε να απεικονίσουμε στο διάγραμμα ακολουθίας την

επαναληπτική αποστολή μηνυμάτων λήψης ονόματος από το αντικείμενο

της κλάσης Κατάλογος Συστατικών προς αντικείμενα της κλάσης

Συστατικό (το οποίο για το λόγο αυτό προστίθεται στον οριζόντιο άξονα

του διαγράμματος ακολουθίας). Όπως γίνεται φανερό, είναι επιτρεπτό και

αναμενόμενο στις περισσότερες περιπτώσεις, το διάγραμμα ακολουθίας

να εμπλουτιστεί με περαιτέρω στοιχεία δυναμικής συμπεριφοράς του

συστήματος, από αυτά που καταγράφηκαν σε προηγούμενες φάσεις. Με

το πέρας της λήψης των ονομάτων από τον κατάλογο Συστατικών και την

επιστροφή της λίστας των ονομάτων στην οθόνη Δημιουργίας Πιάτου, η

οθόνη εμφανίζει τα ονόματα των συστατικών που υπάρχουν στο σύστημα

στον χρήστη.

Η επόμενη ενέργεια που υποδηλώνεται στο διάγραμμα ευρωστίας είναι

η δημιουργία ενός Πιάτου, γεγονός που απεικονίζεται στο διάγραμμα

ακολουθίας με ένα μήνυμα δημιουργίας ενός αντικειμένου προς την

κλάση Πιάτο (η τοποθέτηση της κλάσης οντότητας Πιάτο στο επίπεδο του

μηνύματος υποδηλώνει ότι το αντικείμενο δεν υφίστατο πριν την

αποστολή του μηνύματος).



Η εισαγωγή ονόματος του Πιάτου από το χρήστη δεν απεικονίζεται στο

διάγραμμα ακολουθίας καθώς δεν προκαλεί κάποιο συμβάν στο σύστημα.

Ωστόσο, η επιλογή καταχώρησης του Πιάτου (που ισοδυναμεί με το

πάτημα ενός πλήκτρου άρα και την εμφάνιση ενός συμβάντος)

απεικονίζεται ως ακμή από τον χρήστη προς την οθόνη Δημιουργίας

Πιάτου. Με βάση το διάγραμμα ευρωστίας προκύπτει ότι αμέσως επόμενη

ενέργεια είναι η καταχώρηση του ονόματος στο αντικείμενο της κλάσης

Πιάτο.

Οι ενέργειες του χρήστη "επιλογή Συστατικού/Ποσότητας" και

"επιλογή προσθήκης συστατικού" προκαλούν την αποστολή μηνύματος

καταχώρησης των στοιχείων από την οθόνη Δημιουργίας Πιάτου προς το

αντικείμενο της κλάσης Πιάτο. Καθώς οι πληροφορίες του ονόματος του

συστατικού και της ποσότητάς του πρέπει να αποθηκευτούν στο

αντικείμενο Πιάτο, εισάγονται ως παράμετροι στη μέθοδο καταχώρησης

όπως φαίνεται στο διάγραμμα ακολουθίας. Οι ανωτέρω ενέργειες

μπορούν να εκτελεστούν επαναληπτικά για οποιονδήποτε αριθμό

συστατικών και για το λόγο αυτό τοποθετούνται σε πλαίσιο επανάληψης

στο διάγραμμα ακολουθίας.

Τέλος, η επιλογή του πλήκτρου τερματισμού από το χρήστη, με βάση

το διάγραμμα ευρωστίας προκαλεί την εισαγωγή του πιάτου που

δημιουργήθηκε στον κατάλογο πιάτων. Το γεγονός αυτό απεικονίζεται

στο διάγραμμα ακολουθίας ως ένα μήνυμα με παράμετρο το αντικείμενο

της κλάσης Πιάτο από την οθόνη Δημιουργίας Πιάτου προς τον Κατάλογο



Πιάτων. Η αμέσως επόμενη ενέργεια είναι η εμφάνιση της Κύριας Οθόνης

που απεικονίζεται ως μήνυμα εμφάνισης προς την Κύρια Οθόνη. Το

ολοκληρωμένο διάγραμμα ακολουθίας για την 1η περίπτωση χρήσης

παρουσιάζεται στο σχήμα 6.4.

Σχήμα 6.4: Διάγραμμα Ακολουθίας για την Περίπτωση Χρήσης "Δημιουργία Πιάτου"



6.2.2 Διάγραμμα Ακολουθίας 2: Προσθήκη Παραγγελίας

Σχήμα 6.5: Διάγραμμα Ακολουθίας για την Περίπτωση Χρήσης

"Προσθήκη Παραγγελίας"



6.2.3 Διάγραμμα Ακολουθίας 3: Ετοιμασία Παραγγελίας


"Ετοιμασία Παραγγελίας"



6.2.4 Διάγραμμα Ακολουθίας 4: Υπολογισμός Χρόνου


"Υπολογισμός Χρόνου"



6.3 Διάγραμμα Κλάσεων

6.3.1 Στατικό μοντέλο συστήματος

Ο κύριος σκοπός δημιουργίας των διαγραμμάτων ακολουθίας είναι η

κατανομή της λειτουργικότητας (μεθόδων) στις κλάσεις του συστήματος

και κατά δεύτερο λόγο ο εντοπισμός τυχόν κλάσεων, ιδιοτήτων και

μεθόδων που δεν αναδείχθηκαν στο στάδιο της ανάλυσης. Το στατικό

μοντέλο του υπό ανάπτυξη συστήματος, δηλαδή το διάγραμμα κλάσεων

που περιγράφει την αρχιτεκτονική του είναι επομένως αναμενόμενο να

αναθεωρείται μετά την ολοκλήρωση των διαγραμμάτων ακολουθίας. Στο

αναθεωρημένο διάγραμμα κλάσεων περιλαμβάνονται πλέον οι μέθοδοι

κάθε κλάσης με την πλήρη υπογραφή τους, δηλαδή μαζί με τυχόν

παραμέτρους που απαιτούνται και τον επιστρεφόμενο τύπο τους.

Η λήψη ενός μηνύματος από ένα αντικείμενο μιας κλάσης σε ένα

διάγραμμα ακολουθίας υποδηλώνει την ύπαρξη μιας μεθόδου στην κλάση

που είναι ο αποδέκτης του μηνύματος. Η μέθοδος συνιστά τη λειτουργία

που θα εκτελείται στην κλάση-αποδέκτη με τη λήψη του αντίστοιχου

μηνύματος.



6.3.2 Εξαγωγή μεθόδων συστήματος

Από το διάγραμμα ακολουθίας που αφορά στην περίπτωση χρήσης 1

προκύπτουν οι εξής μέθοδοι για τις κλάσεις των αντικειμένων που

εμφανίζονται στο διάγραμμα (εξαιρώντας τις συνοριακές κλάσεις):

Πίνακας 6.1: Μέθοδοι κλάσεων συστήματος που προκύπτουν από το

διάγραμμα ακολουθίας 1

Συστατικό

(Ingredient)

Πιάτο

(Plate)

Κατάλογος

Συστατικών

(IngredientCatalog)

Κατάλογος

Πιάτων

(Plate

Catalog) λήψη

ονόματος

getName()

καταχώρηση ονόματος (όνομα)

setPlateName(String)


getIngredientNames()


(Πιάτο)

add(Plate)

καταχώρηση(συστατικό, ποσότητα)

storeIngredient(Ingredient,

int)

Τα ονόματα των μεθόδων εμφανίζονται και στα αγγλικά για λόγους ευκολότερης

αντιστοίχισης με το τελικό διάγραμμα κλάσεων. Επιπλέον, ορισμένα ονόματα μεθόδων

έχουν τροποποιηθεί σε σχέση με τα αντίστοιχα μηνύματα στα διαγράμματα ακολουθίας,

ώστε το όνομά τους να αποκαλύπτει τη χρήση τους.




προκύπτουν οι εξής επιπλέον μέθοδοι:




(Order)

Πιάτο

(Plate)

Ουρά

(Queue)

Συστατικό

(Ingredient)

Κατάλογος

Πιάτων

(Plate

Catalog) καταχώρηση

(Πιάτο)

addPlate(Plate)

λήψη ονόματος

getName()


(Παραγγελία)

add(Order)

έλεγχος ποσότητας

(ποσότητα)

checkQuantity(int)


getPlateNames()

έλεγχος

διαθεσιμότητας

isAvailable()





Συστατικό

(Ingredient)

Πιάτο

(Plate)

Ουρά

(Queue)


(Order) αφαίρεση(ποσότητα)

remove(int)

επιλογή

pick()

λήψη πρώτης παραγγελίας

getFirstOrder()

λήψη πιάτων

getPlates()

αφαίρεση πρώτης


removeFirstOrder()

επιλογή Πιάτου(όνομα)

pickPlate(String)







Ουρά

(Queue)


(Order) λήψη κωδικών

getOrderCodes()

λήψη κωδικού

getCode()

υπολογισμός χρόνου(κωδικός)

calculateTime(int)

λήψη αριθμού πιάτων

getNumberOfPlates()

εύρεση θέσης παραγγελίας(κωδικός)

findPosition(int)

υπολογισμός πιάτων που αναμένουν

calculatePlatesWaiting()

6.3.3 Αναθεωρημένο διάγραμμα κλάσεων

Με βάση τις μεθόδους (23 στο σύνολο) που εντοπίστηκαν κατά την

διαδικασία της κατασκευής των διαγραμμάτων ακολουθίας είναι πλέον

δυνατόν να προκύψει το αναθεωρημένο διάγραμμα κλάσεων, το οποίο

στο σημείο αυτό "πλησιάζει" αρκετά τον κώδικα που πρόκειται να

υλοποιηθεί στη συνέχεια. Το διάγραμμα κλάσεων του συστήματος

προκύπτει προσθέτοντας μία προς μία τις μεθόδους που αναφέρονται

στους ανωτέρω πίνακες με δημόσια ορατότητα (public visibility). Ο

επιστρεφόμενος τύπος αν είναι void χάριν απλότητας παραλείπεται ενώ

στις υπόλοιπες περιπτώσεις σημειώνεται στο UML διάγραμμα. Επίσης,



στο στάδιο της σχεδίασης είναι χρήσιμο να απεικονιστούν και

πληροφορίες όπως ο τύπος δεδομένων για όσες ιδιότητες αυτός είναι

γνωστός. Σημειώνεται ότι παρόλο που μέθοδοι πρόσβασης ιδιοτήτων

(μέθοδοι get() και set()) δεν απεικονίζονται συνήθως σε διαγράμματα

κλάσεων, στο διάγραμμα κλάσεων του συστήματος που αναπτύσσεται

απεικονίζονται τέτοιες μέθοδοι αν έχουν προκύψει από τα διαγράμματα

ακολουθίας ώστε να υπάρχει η δυνατότητα ιχνηλάτησης (δηλαδή η

δυνατότητα ελέγχου της αντιστοίχισης μεθόδων στις κλάσεις και

μηνυμάτων στα διαγράμματα ακολουθίας).

Σχήμα 6.8: Διάγραμμα Κλάσεων Συστήματος

77



Στην αρχιτεκτονική που απεικονίζεται στο διάγραμμα επιλέχθηκε, χάριν

απλότητας, οι κλάσεις που περιλαμβάνουν συλλογές άλλων αντικειμένων

υπό μορφή καταλόγου ή λίστας (όπως ο Κατάλογος Πιάτων, ο Κατάλογος

Συστατικών και η Ουρά) να διαθέτουν στατικές ιδιότητες και μεθόδους. Η

απόφαση αυτή λήφθηκε καθώς από κάθε μία από αυτές τις κλάσεις δεν

αναμένεται να δημιουργηθούν περισσότερα του ενός αντικείμενα

(δηλαδή, στο σύστημα θα έχουμε μία ουρά παραγγελιών, έναν κατάλογο

πιάτων και έναν κατάλογο συστατικών). Για να μην απαιτείται η

δημιουργία των μοναδικών αυτών αντικειμένων σε κάποια κεντρική

κλάση (όπως π.χ. η Main) και το "πέρασμα" των αναφορών προς αυτά τα

αντικείμενα σε όλα τα αντικείμενα που θέλουν να καλέσουν μεθόδους

τους, προτιμήθηκε η χρήση στατικών μεθόδων και ιδιοτήτων.

Υπενθυμίζεται ότι οι στατικές ιδιότητες δεν υφίστανται σε επίπεδο

αντικειμένων (δηλαδή ξεχωριστή τιμή της ιδιότητας για κάθε αντικείμενο)

αλλά σε επίπεδο κλάσεων (μία τιμή για την κλάση, ακόμα και αν δεν

υπάρχουν αντικείμενά της). Επιπλέον, οι στατικές μέθοδοι μπορούν να

κληθούν από οποιοδήποτε σημείο του συστήματος μέσω του ονόματος

της κλάσης, χωρίς να απαιτείται αναφορά προς κάποιο αντικείμενό της.

Αξίζει να σημειωθεί ότι στην αντικειμενοστρεφή σχεδίαση υπάρχουν πιο

ενδεδειγμένες λύσεις (και ελαφρώς πιο περίπλοκες) για αντίστοιχες

περιπτώσεις, όπως το πρότυπο σχεδίασης Μοναδιαίο (Singleton Design

Pattern).



Τονίζεται ότι το διάγραμμα κλάσεων είναι ενδεχομένως το σημαντικότερο

διάγραμμα της UML στη διαδικασία ανάπτυξης καθώς αποτυπώνει

λεπτομερώς την αρχιτεκτονική δομή του λογισμικού και αποτελεί το

πρότυπο βάσει του οποίου υλοποιείται ο κώδικας.

6.3.4 Απλουστεύσεις - Συμβάσεις

Στο σύστημα που αναπτύσσεται έχουν γίνει ορισμένες απλουστεύσεις: Για

παράδειγμα η εισαγωγή συστατικών στον Κατάλογο Συστατικών δεν

ορίστηκε ως περίπτωση χρήσης (λόγω της υπερβολικής απλότητάς της)

και θεωρείται ότι τα συστατικά εισάγονται ρητά μέσα από κεντρικές

κλάσεις (στην προκειμένη περίπτωση από τη Main που περιλαμβάνει τη

μέθοδο main()).

Τέλος, σημειώνεται ότι οι επιλογές που πραγματοποιήθηκαν σε επίπεδο

κώδικα δεν είναι οι βέλτιστες από πλευράς απόδοσης ή αξιοποίησης των

δυνατοτήτων των βιβλιοθηκών της Java. Ο λόγος είναι ότι επιχειρήθηκε η

ανάπτυξη του κώδικα ακολουθώντας όσο το δυνατόν πιο πιστά τα

προϊόντα της διαδικασίας ανάλυσης και σχεδίασης.



6.4 Ποιότητα Σχεδίασης

Η αρχιτεκτονική του συστήματος που προέκυψε από την εφαρμογή της

μεθοδολογίας ICONIX (δηλαδή η κατανομή της λειτουργικότητας σε

κλάσεις και ο καθορισμός των σχέσεων μεταξύ τους) προφανώς

ικανοποιεί τις απαιτήσεις του πελάτη, αφού η διαδικασία οδηγείται

αυστηρά από τις περιπτώσεις χρήσης. Κάτι αντίθετο θα ήταν ούτως ή

άλλως παράλογο, αφού η πρωταρχική απαίτηση από το λογισμικό είναι να

παρέχει ποιότητα από την οπτική γωνία του χρήστη. Ωστόσο, το

λογισμικό αξιολογείται από πλευράς ποιότητας και από την πλευρά του

κατασκευαστή και στα πλαίσια αυτά επιχειρείται η αξιολόγηση της

ποιότητας του σχεδίου.

Ωστόσο, η ίδια η ποιότητα εντός αντικειμενοστρεφούς σχεδίου είναι

δύσκολο να καθοριστεί. Εν γένει, είναι δύσκολο να αποφανθεί κανείς αν

μία σχεδίαση είναι "καλή". Αντίθετα, οι επιπτώσεις από μια σχεδίαση

"κακής" ποιότητας γίνονται εμφανείς πολύ ξεκάθαρα, ιδιαίτερα σε έργα

λογισμικού που πρόκειται να εξελιχθούν, δηλαδή να παράγουν πολλαπλές

γενιές του ιδίου προϊόντος λόγω μεταβαλλόμενων και νέων απαιτήσεων.

Η έλλειψη ποιότητας στην αρχιτεκτονική σχεδίαση οδηγεί με βεβαιότητα

στα ακόλουθα συμπτώματα:

• σε δυσκολία κατανόησης του συστήματος από τα μέλη της

ομάδας ανάπτυξης που θα κληθούν μελλοντικά να προσθέσουν ή

να τροποποιήσουν τη λειτουργικότητα



• σε δυσκολία συντήρησης που μεταφράζεται σε υπερβολική

προσπάθεια από πλευράς χρόνου και κόστους για την υλοποίηση

μελλοντικών αλλαγών στο λογισμικό

• σε δυσκολία ελέγχου του συστήματος που συνίσταται στην

επαλήθευση (verification) της ορθότητας των λειτουργιών και

επικύρωση (validation) ότι το λογισμικό ικανοποιεί τις απαιτήσεις

του πελάτη

• σε δυσκολία επαναχρησιμοποίησης τμημάτων του λογισμικού

που θα ήταν ενδεχομένως αξιοποιήσιμα σε διαφορετικές

εφαρμογές ή και περιβάλλοντα

Η αξιολόγηση της σχεδίασης αντικειμενοστρεφών συστημάτων στην

πράξη πραγματοποιείται από τους πλέον έμπειρους σχεδιαστές-

προγραμματιστές των ομάδων ανάπτυξης, λίγο πριν την έναρξη

υλοποίησης του κώδικα. Οι σχεδιαστές αυτοί ελέγχουν την αρχιτεκτονική

του συστήματος βάσει εμπειρικών κανόνων που οι ίδιοι έχουν σχηματίσει

και προτείνουν τυχόν βελτιώσεις ή τροποποιήσεις. Προφανώς μια τέτοια

διαδικασία αξιολόγησης είναι υποκειμενική και παράγει αμφίβολης

αξιοπιστίας αποτελέσματα. Επιπλέον, η αξιολόγηση κατ' αυτόν τον τρόπο

δεν επιδέχεται αυτοματοποίηση. Για το λόγο αυτό, επιχειρήθηκε η

αντικατάσταση της προσφυγής στην γνώμη των ειδικών από

αντικειμενικότερες και ει δυνατόν αυτοματοποιήσιμες τεχνικές

αξιολόγησης.



Στα πλαίσια των τεχνικών αυτών, η αξιολόγηση αντικειμενοστρεφών

σχεδίων μπορεί να πραγματοποιηθεί με τρεις τρόπους: α) συλλέγοντας και

αξιολογώντας τις τιμές επιλεγμένων μετρικών λογισμικού, β) ελέγχοντας

τη συμμόρφωση του σχεδίου με καθιερωμένες αρχές σχεδίασης και γ)

ελέγχοντας την τυχόν παραβίαση ευρετικών κανόνων.

6.5 Αξιολόγηση Σχεδίασης με χρήση Μετρικών Λογισμικού

Ο σκοπός των μετρήσεων είναι η ανάθεση αριθμητικών τιμών ή

συμβόλων σε χαρακτηριστικά οντοτήτων που υπάρχουν στην

πραγματικότητα. Για την πραγματοποίηση των μετρήσεων απαιτείται η

ύπαρξη ενός μοντέλου το οποίο να καθορίζει τους κανόνες με βάση τους

οποίους πρέπει να εκτελούνται οι μετρήσεις και να ερμηνεύονται τα

αποτελέσματά τους. Σε ένα έργο λογισμικού, όπως και σε οποιοδήποτε

τεχνικό έργο, οι μετρήσεις επιτρέπουν την καλύτερη διαχείριση,

παρακολούθηση και αξιολόγηση των παραγόμενων προϊόντων και

παραδοτέων. Σύμφωνα με τη ρήση του DeMarco, "δεν μπορείς να ελέγξεις

αυτό που δεν μπορείς να μετρήσεις" ("you cannot control what you cannot

measure").

Ο όρος "μετρική" στην Τεχνολογία Λογισμικού αναφέρεται στην

ποσοτική εκτίμηση του βαθμού κατά τον οποίο ένα προϊόν ή μία

διαδικασία κατέχει ένα συγκεκριμένο χαρακτηριστικό. Στη βιβλιογραφία

έχουν προταθεί εκατοντάδες μετρικές και στην πράξη είναι δύσκολο να



αξιολογήσει κανείς ποια είναι η καλύτερη επιλογή. Ωστόσο, μια ιδανική

μετρική λογισμικού θα πρέπει να είναι:

• Απλή και υπολογίσιμη: Η εκμάθηση του τρόπου εξαγωγής της μετρικής

θα πρέπει να είναι σχετικά απλή και ο υπολογισμός της όχι

υπερβολικά δαπανηρός από πλευράς προσπάθειας και χρόνου.

• Εμπειρικά και διαισθητικά πειστική: Η χρησιμοποιούμενη μετρική θα

πρέπει να ικανοποιεί την διαίσθηση του μηχανικού λογισμικού

σχετικά με το υπό εξέταση χαρακτηριστικό (π.χ. η αριθμητική τιμή

του μέτρου της συνεκτικότητας μιας μονάδας θα πρέπει να αυξάνει

όσο αυξάνει το επίπεδο συνεκτικότητας)

• Συνεπής και αντικειμενική: Τα αποτελέσματα που προκύπτουν από την

εφαρμογή της μετρικής στο ίδιο λογισμικό και για ίδια δεδομένα

εισόδου, σε διαφορετικές χρονικές στιγμές, θα πρέπει να είναι πάντοτε

τα ίδια. Οποιοσδήποτε χρήστης της μετρικής θα πρέπει να καταλήγει

στα ίδια αποτελέσματα.

• Συνεπής ως προς τη χρήση μονάδων και διαστάσεων: Η χρήση

μαθηματικών μεθόδων σε μία μετρική δεν θα πρέπει να καταλήγει σε

"περίεργα" αποτελέσματα από πλευράς μονάδων μέτρησης. Για

παράδειγμα ο πολλαπλασιασμός των ατόμων μιας ομάδας σχεδίασης

με τον αριθμό μεταβλητών του προγράμματος οδηγεί σε μονάδες

μέτρησης που δεν είναι διαισθητικά αποδεκτές.

• Ανεξάρτητη από τη γλώσσα προγραμματισμού: Οι μετρικές θα πρέπει να

βασίζονται στην ανάλυση του αλγορίθμου ή στη δομή ενός



προγράμματος και όχι στις ιδιαιτερότητες σύνταξης και

σημασιολογίας κάθε γλώσσας προγραμματισμού.

• Ένας ουσιαστικός μηχανισμός ανάδρασης: Μία μετρική θα πρέπει να

παρέχει στο σχεδιαστή λογισμικού κατάλληλη πληροφορία ώστε να

μπορεί να βελτιώσει την ποιότητα του παραγόμενου προϊόντος.

Στην Τεχνολογία Λογισμικού υπάρχουν ήδη από τις αρχές της δεκαετίας

του 1970 δύο θεμελιώδεις έννοιες που χρησιμοποιούνται για την

αξιολόγηση της αρχιτεκτονικής δομής ενός συστήματος λογισμικού (όχι

μόνο αντικειμενοστρεφούς λογισμικού). Η έννοια της σύζευξης και της

συνεκτικότητας.



6.5.1 Σύζευξη

Η σύζευξη (coupling) αναφέρεται στο βαθμό αλληλεξάρτησης μεταξύ των

μονάδων ενός συστήματος (κλάσεων για αντικειμενοστρεφή συστήματα).

Όσο μικρότερη είναι η αλληλεξάρτηση, τόσο ευκολότερη είναι η

κατανόηση, η συντήρηση, ο έλεγχος και η επαναχρησιμοποίηση κάθε

μονάδας. Κατά συνέπεια, βασικός στόχος κατά τη διάρκεια της σχεδίασης

είναι η ελαχιστοποίηση της σύζευξης. Ο στόχος αυτός δεν είναι εύκολο να

επιτευχθεί ακολουθώντας μια συγκεκριμένη διαδικασία. Ωστόσο, είναι

σχετικά εύκολη η μέτρηση της σύζευξης ενός συστήματος λογισμικού

(είτε αυτό υπάρχει ως διάγραμμα κλάσεων είτε ως κώδικας) και η

παρακολούθηση της εξέλιξής της. Η εμφάνιση υψηλών τιμών σύζευξης

είτε για ολόκληρο το σύστημα είτε για μεμονωμένες κλάσεις λειτουργεί

ως ένα σήμα προειδοποίησης που επιβάλλει την αναδιοργάνωση του

σχεδίου.

Στη βιβλιογραφία έχουν προταθεί δεκάδες μετρικές για την

ποσοτικοποίηση της σύζευξης που διαφέρουν κυρίως στον αριθμό και το

είδος των παραμέτρων που λαμβάνουν υπόψη για να εκτιμήσουν αν

υπάρχει σύζευξη μεταξύ δύο κλάσεων ή όχι. Στην ανάλυση που

ακολουθεί χρησιμοποιείται ο παλαιότερος ορισμός της σύζευξης που

συμβολίζεται ως CBO (Coupling Between Objects). Σύμφωνα με αυτή τη

μετρική η τιμή της σύζευξης για μια κλάση C ισούται με το πλήθος άλλων

κλάσεων του συστήματος με τις οποίες υπάρχει σύζευξη (εξαιρώντας

σύζευξη λόγω κληρονομικότητας). Ως σύζευξη μεταξύ της κλάσης C και



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

ως τύπο την D, ή η ύπαρξη παραμέτρων σε μεθόδους που έχουν ως τύπο

την D. Η τιμή της μετρικής μπορεί φυσικά να εξαχθεί εξετάζοντας τον

πηγαίο κώδικα του συστήματος, είναι όμως δυνατός και ο υπολογισμός

στην περίπτωση που είναι διαθέσιμο ένα λεπτομερές διάγραμμα κλάσεων.

Ως τιμή της σύζευξης για ολόκληρο το σύστημα θεωρείται η μέση τιμή

της σύζευξης των κλάσεων του συστήματος.

Για το σύστημα διαχείρισης παραγγελιών που αναπτύχθηκε οι τιμές

της σύζευξης για κάθε κλάση ξεχωριστά καθώς και η τιμή για ολόκληρο

το σύστημα παρουσιάζονται στον πίνακα 6.5.

Πίνακας 6.5: Τιμές σύζευξης για το σύστημα διαχείρισης παραγγελιών Κλάση Σύζευξη

Ingredient 0

Order 1

Plate 1

Queue 1

PlateCatalog 1

IngredientCatalog 1

Σύστημα 0.833

Για να γίνει κατανοητός ο τρόπος εξαγωγής της μετρικής θεωρούμε την

κλάση Plate. Από το διάγραμμα κλάσεων του συστήματος (σχήμα 6.8)

προκύπτει ότι στην υπογραφή της μεθόδου storeIngredient()



εμφανίζεται μια παράμετρος με τύπο την κλάση Ingredient. Επομένως

υπάρχει σύζευξη από την κλάση Plate προς την κλάση Ingredient. Το ίδιο

συμπέρασμα μπορεί να εξαχθεί βλέποντας και τη συναρμολόγηση μεταξύ

των δύο κλάσεων (που υλοποιείται ως κατάλληλη ιδιότητα της κλάσης

Plate). Επειδή η Ingredient είναι η μοναδική κλάση με την οποία υπάρχει

σύζευξη η τιμή της μετρικής για την κλάση Plate ισούται με τη μονάδα.

Στην πράξη οι τιμές τέτοιων μετρικών εξάγονται αυτόματα μέσω των

εργαλείων υποστήριξης της διαδικασίας ανάπτυξης.

Στο παράδειγμα του συστήματος διαχείρισης παραγγελιών αξίζει να

σημειωθεί ότι η τιμή της σύζευξης για όλες τις κλάσεις είναι πολύ μικρή.

Θα ήταν φυσικά αδύνατο η σύζευξη να λάμβανε μηδενική τιμή για όλες

τις κλάσεις, διότι τότε θα επρόκειτο για ένα σύστημα όπου οι κλάσεις

είναι τελείως ανεξάρτητες και κατά συνέπεια δεν συνεργάζονται μεταξύ

τους. Η χαμηλή τιμή της μετρικής του συστήματος υποδηλώνει ότι η

διαδικασία ανάλυσης και σχεδίασης οδήγησε σε ποιοτικά "καλή"

αρχιτεκτονική του συστήματος. Σημειώνεται ότι από τους υπολογισμούς

της σύζευξης εξαιρέθηκε η κλάση Main καθώς συνήθως τέτοιες κλάσεις

παίζουν το ρόλο της κλάσης-εργοστάσιο, δηλαδή χρησιμοποιούνται για

τη δημιουργία άλλων αντικειμένων. Οι κλάσεις-εργοστάσια έχουν κατά

κανόνα μεγάλη τιμή σύζευξης κάτι που όμως δεν είναι απαραιτήτως

ανεπιθύμητο, καθώς "συγκεντρώνουν" την εξάρτηση από άλλες κλάσεις

σε ένα σημείο του συστήματος.



6.5.2 Συνεκτικότητα

Η συνεκτικότητα (cohesion) αναφέρεται στο βαθμό εσωτερικής συνοχής

των τμημάτων μιας μονάδας λογισμικού. Στα πλαίσια των

αντικειμενοστρεφών συστημάτων ποσοτικοποιεί το βαθμό λειτουργικής

συνάφειας των μεθόδων μιας κλάσης. Όσο πιο συνεκτική είναι μια κλάση,

τόσο πιο πολύ οι μέθοδοί της σχετίζονται μεταξύ τους και συνεργάζονται

για την επίτευξη ενός και μόνο κοινού σκοπού. Για λόγους ευκολότερης

κατανόησης, συντήρησης και ελέγχου μιας κλάσης, είναι γενικά

επιθυμητό μια κλάση να μην αναλαμβάνει διαφορετικές αρμοδιότητες.

Υπό αυτή την έννοια μια κλάση πρέπει να είναι όσο το δυνατόν πιο

συνεκτική και αν είναι εφικτό, όλες οι μέθοδοί της να είναι συνεκτικές

μεταξύ τους. Δύο μέθοδοι θεωρούνται συνεκτικές εάν προσπελαύνουν

έστω και μία κοινή ιδιότητα της κλάσης, θεωρώντας ότι η χρήση κοινών

ιδιοτήτων υποδηλώνει και κάποιου είδους λειτουργική συνάφεια.

Κατ' αντιστοιχία με την μετρική της σύζευξης θα αναφερθούμε στην

παλαιότερη μετρική συνεκτικότητας που είναι γνωστή ως LCOM (Lack of

Cohesion Of Methods). Η μετρική αυτή ποσοτικοποιεί την έλλειψη

συνεκτικότητας μιας κλάσης, δηλαδή όσο μικρότερη τιμή έχει για μια

κλάση, τόσο μεγαλύτερη συνεκτικότητα υπάρχει. Ονομάζοντας P το

πλήθος των μη συνεκτικών ζευγών μεθόδων και Q το πλήθος των

συνεκτικών ζευγών μεθόδων μιας κλάσης, η τιμή της συνεκτικότητας

υπολογίζεται ως QPLCOM −= (αν ), αλλιώς η τιμή της μετρικής

LCOM θεωρείται ίση με το 0 (ιδανική περίπτωση). Ως τιμή της

QP >



συνεκτικότητας για ένα σύστημα θεωρείται η μέση τιμή της

συνεκτικότητας των κλάσεων. Η εξαγωγή της τιμής της μετρικής απαιτεί

τη γνώση του πηγαίου κώδικα ώστε να διαπιστωθεί ποιές ιδιότητες

προσπελαύνει κάθε μέθοδος (πληροφορία που δεν απεικονίζεται στα

διαγράμματα κλάσεων της UML).

Για να γίνει κατανοητός ο τρόπος υπολογισμού της μετρικής

εξετάζουμε τον κώδικα της κλάσης Plate (ενότητα 8.1). Εξαιρώντας τις

μεθόδους get() και set() (που επιστρέφουν την τιμή μιας ιδιότητας ή

θέτουν τιμή σε αυτήν), η κλάση περιλαμβάνει τρεις μεθόδους. Στη

συνέχεια παρατίθενται οι τρεις μέθοδοι και η λίστα των ιδιοτήτων που

προσπελαύνουν στο σώμα τους

• storeIngredient() map

• isAvailable() map

• pick() map

Από τις τρεις μεθόδους είναι δυνατόν να σχηματιστούν ( ) 32

133=

−⋅

ζεύγη μεθόδων. Στο συγκεκριμένο παράδειγμα όλα τα ζεύγη μεθόδων

είναι συνεκτικά (καθώς προσπελαύνουν την ιδιότητα map). Κατά

συνέπεια το πλήθος των μη συνεκτικών ζευγών P είναι ίσο με 0 ενώ το

πλήθος των συνεκτικών ζευγών μεθόδων Q είναι ίσο με 3. Αφού P < Q, η

τιμή της μετρικής LCOM για τη συγκεκριμένη κλάση είναι ίση με 0,

δηλαδή σύμφωνα με αυτή τη μετρική, η κλάση είναι όσο το δυνατόν πιο

συνεκτική γίνεται.



Για το σύστημα διαχείρισης παραγγελιών που αναπτύχθηκε οι τιμές

της συνεκτικότητας για κάθε κλάση ξεχωριστά καθώς και η τιμή για

ολόκληρο το σύστημα παρουσιάζονται στον πίνακα 6.6.

Πίνακας 6.6: Τιμές συνεκτικότητας για το σύστημα διαχείρισης

παραγγελιών Κλάση LCOM

Ingredient 0

Order 0

Plate 0

Queue 0

PlateCatalog 0

IngredientCatalog 0

Σύστημα 0

Όπως γίνεται φανερό, το πλήθος των συνεκτικών ζευγών μεθόδων για

όλες τις κλάσεις του συστήματος είναι μεγαλύτερο από το πλήθος των μη

συνεκτικών ζευγών μεθόδων. Το αποτέλεσμα αυτό είναι άμεση συνέπεια

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

ICONIX, καθώς ήδη από τα πρώτα στάδια δημιουργίας του στατικού

μοντέλου, οι ιδιότητες έχουν τοποθετηθεί μαζί με τις μεθόδους που τις

προσπελαύνουν, με αποτέλεσμα η συνεκτικότητα όλων των κλάσεων να

είναι υψηλή. Συνήθως, οι τιμές της σύζευξης και συνεκτικότητας είναι

αρκετά ικανοποιητικές στην πρώτη γενιά ενός συστήματος λογισμικού. Η



ποιότητα της σχεδίασης αρχίζει να υποβαθμίζεται ωστόσο κατά την

εξέλιξη του λογισμικού όταν προτεραιότητα δίνεται στην ικανοποίηση

των απαιτήσεων (και μάλιστα υπό πίεση χρόνου) και όχι στην διατήρηση

της ποιότητας σχεδίασης. Για το λόγο αυτό η εξέλιξη της σύζευξης και

της συνεκτικότητας σε σχέση με το χρόνο ακολουθεί συνήθως μια

φθίνουσα πορεία.



6.5.3 Πολυπλοκότητα

Η πολυπλοκότητα του λογισμικού είναι από ένα από τα πρώτα

χαρακτηριστικά που η κοινότητα της Τεχνολογίας Λογισμικού

προσπάθησε να ποσοτικοποιήσει. Η έννοια της πολυπλοκότητας γίνεται

αντιληπτή με διαφορετικούς τρόπους ανάλογα με την οπτική γωνία από

την οποία εξετάζει κανείς το λογισμικό. Η πολυπλοκότητα δεν αφορά

μόνο στα αντικειμενοστρεφή συστήματα αλλά σε οποιοδήποτε τμήμα

κώδικα, ανεξαρτήτως γλώσσας και υποδείγματος προγραμματισμού.

Ωστόσο, στα πλαίσια της αντικειμενοστρεφούς σχεδίασης η

πολυπλοκότητα δεν εξαρτάται μόνο από τη φύση των αλγορίθμων που

υλοποιούνται αλλά και από την κατανομή της λειτουργικότητας σε

κλάσεις και μεθόδους. Από πληθώρα εμπειρικών μελετών έχει αποδειχθεί

ότι τμήματα λογισμικού με μεγάλη πολυπλοκότητα, είναι πιθανό να

εμφανίσουν περισσότερα σφάλματα κατά τη διάρκεια εκτέλεσης.

Επιπλέον, η πολυπλοκότητα συμβάλλει στη δυσκολία κατανόησης και

στην αύξηση του κόστους συντήρησης του λογισμικού.

Ο παλαιότερος ορισμός πολυπλοκότητας σε αντικειμενοστρεφή

συστήματα αφορά στη μετρική πολυπλοκότητας μεθόδων κλάσης που

συμβολίζεται ως WMC (Weighted Methods per Class). Η μετρική αυτή

υποστηρίζεται από όλα τα εργαλεία CASE που υπολογίζουν τιμές

μετρικών. Θεωρούμε μια κλάση C με μεθόδους M1, M2, …, Mn. Έστω c1,

c2, …, cn ένα μέτρο πολυπλοκότητας των μεθόδων (όπως η κυκλωματική

πολυπλοκότητα που περιγράφεται στη συνέχεια). Η τιμή της μετρικής



είναι το άθροισμα των τιμών πολυπλοκότητας για όλες τις μεθόδους της

κλάσης ( ). ∑=

=n

iicWMC

1

Η έννοια της κυκλωματικής πολυπλοκότητας (ή πολυπλοκότητα

McCabe) βασίζεται στην αντίληψη ότι αυτό που αυξάνει την

πολυπλοκότητα σε ένα πρόγραμμα είναι το πλήθος των δομών ελέγχου

που περιλαμβάνει. Η ροή του ελέγχου σε οποιοδήποτε πρόγραμμα είναι

δυνατόν να αναπαρασταθεί με έναν προσανατολισμένο γράφο. Σε έναν

γράφο ροής ελέγχου, κάθε κόμβος αναπαριστά μια ομάδα εντολών που

εκτελούνται ακολουθιακά, ενώ κάθε ακμή αναπαριστά μεταφορά της ροής

ελέγχου. Με άλλα λόγια, για την κατασκευή του γράφου ροής ελέγχου

ενός προγράμματος, το πρόγραμμα διασπάται σε μπλοκ κώδικα που

διαχωρίζονται από εκφράσεις που επηρεάζουν τη ροή του ελέγχου (π.χ.

εντολές if, if/else, while, break κ.ο.κ.). Κάθε μπλοκ κώδικα αντιστοιχεί σε

ένα κόμβο του γράφου, ενώ αν ο έλεγχος (λόγω κάποιας εντολής ελέγχου)

είναι δυνατόν να μεταφερθεί από το μπλοκ i στο μπλοκ j, σχεδιάζεται μια

προσανατολισμένη ακμή από τον κόμβο i προς τον κόμβο j.

Στη συνέχεια παρουσιάζεται ο αλγόριθμος ταξινόμησης φυσαλίδας

(bubblesort) (αριθμώντας τις γραμμές για ευκολία αναφοράς) και ο

αντίστοιχος προσανατολισμένος γράφος ροής ελέγχου. Σε κάθε κόμβο του

γράφου αναγράφονται οι αριθμοί των εντολών που αναπαριστά:



94

0

1 i = n-1;

2 while(i >= 1)

3 j = 0;

4 while(j < i)

5 if(A[i] < A[j])

6 temp = A[i];

7 A[i] =A[j];

8 A[j] = temp;

9

10 j = j + 1;

11

12 i = i – 1;

13

14

15 ..επόμενο τμήμα κώδικα

Σχήμα 6.9: Γράφος ροής ελέγχου για τον αλγόριθμο bubblesort



Η τιμή της κυκλωματικής πολυπλοκότητας V(G) ενός γράφου G=<V, E>,

όπου V το σύνολο των κόμβων του και Ε το σύνολο των ακμών του,

ορίζεται με τους εξής τρεις ισοδύναμους τρόπους:

1. 2)( +−= VEGV ,

όπου E είναι ο αριθμός των ακμών και V ο αριθμός των κόμβων του

γράφου. Για το γράφο του σχήματος 6.9 ο αριθμός των ακμών είναι 9, ο

αριθμός των κόμβων είναι 7 και κατά συνέπεια η τιμή της κυκλωματικής

πολυπλοκότητας είναι 4279)( =+−=GV

2. , 1)( += PGV

όπου P o αριθμός των κόμβων απόφασης του γράφου ροής ελέγχου. Ένας

κόμβος χαρακτηρίζεται κόμβος απόφασης εάν έχει περισσότερες από μία

εξερχόμενες ακμές. Για το παράδειγμα του αλγορίθμου bubblesort, το

πλήθος των κόμβων απόφασης είναι τρεις και κατά συνέπεια,

. 413)( =+=GV

3. V(G) = αριθμός περιοχών του γράφου,

όπου περιοχή ενός γράφου είναι το τμήμα που περικλείεται από

οποιοδήποτε στοιχειώδη κύκλο του, συμπεριλαμβανομένης και της

εξωτερικής περιοχής εκτός του γράφου. Ένας στοιχειώδης κύκλος είναι

μια διαδρομή όπου ταυτίζονται ο πρώτος και ο τελευταίος κόμβος, όπου

όλοι οι κόμβοι είναι διακεκριμένοι και δεν περιλαμβάνονται άλλοι κύκλοι.

Για τον γράφο του αλγορίθμου bubblesort ο αριθμός των περιοχών είναι

4, και κατά συνέπεια V(G) = 4.



Για ένα πρόγραμμα που περιλαμβάνει μόνο μια γραμμική ακολουθία

εντολών χωρίς καμία εντολή ελέγχου, η κυκλωματική πολυπλοκότητα

είναι ίση με 1. Η συνήθης παραδοχή είναι ότι η κυκλωματική

πολυπλοκότητα για μία συνάρτηση/μέθοδο δεν θα πρέπει να ξεπερνά την

τιμή 10. Σε αντίθετη περίπτωση, η αντίστοιχη συνάρτηση/μέθοδος είναι

επιρρεπής στην εμφάνιση σφαλμάτων και θα πρέπει να τυγχάνει

ιδιαίτερης προσοχής.

Η τιμή της κυκλωματικής πολυπλοκότητας για ένα τμήμα κώδικα που

αναπαρίσταται ως γράφος ροής ελέγχου, εκτός από μέτρο

πολυπλοκότητας, καθορίζει και τον αριθμό των ανεξάρτητων διαδρομών

του γράφου. Μια ανεξάρτητη διαδρομή είναι μια διαδρομή στο

πρόγραμμα που εισάγει τουλάχιστον μια νέα συνθήκη ή ένα νέο σύνολο

εκτελούμενων εντολών. Επειδή για τον πλήρη έλεγχο της ορθότητας ενός

προγράμματος πρέπει να ελεγχθούν όλες οι ανεξάρτητες διαδρομές του, η

τιμή της κυκλωματικής πολυπλοκότητας παρέχει επίσης ένα μέτρο του

αριθμού των ελέγχων που πρέπει να πραγματοποιηθούν. Με άλλα λόγια,

αν έχουν ελεγχθεί τόσες ανεξάρτητες διαδρομές όσες καθορίζει η

κυκλωματική πολυπλοκότητα, οποιοσδήποτε νέος έλεγχος θα είναι

πλεονασματικός, δηλαδή δεν θα διατρέχει κάποιο νέο τμήμα του κώδικα

ούτε θα εκτελεί το πρόγραμμα για κάποια νέα διακλάδωση συνθήκης.

Για τις κλάσεις του συστήματος διαχείρισης παραγγελιών οι τιμές της

μετρικής WMC παρουσιάζονται στον πίνακα 6.7.



Πίνακας 6.7: Τιμές μετρικής WMC για το σύστημα διαχείρισης

παραγγελιών Κλάση WMC

Ingredient 6

Order 7

Plate 8

Queue 10

PlateCatalog 4

IngredientCatalog 4

Σύστημα 6.5

Όπως είναι αναμενόμενο, η κλάση Queue που περιλαμβάνει αφενός τις

περισσότερες μεθόδους και αφετέρου μεθόδους με εντολές ελέγχου ή

επανάληψης (σε μία περίπτωση μία εντολή ελέγχου βρίσκεται

φωλιασμένη σε μια εντολή επανάληψης), έχει τη μεγαλύτερη

πολυπλοκότητα από όλες τις κλάσεις του συστήματος. Από τη μελέτη του

κώδικα επιβεβαιώνεται ότι η συγκεκριμένη κλάση παρουσιάζει τη

μεγαλύτερη δυσκολία κατανόησης και ελέγχου.



6.6 Αρχές Αντικειμενοστρεφούς Σχεδίασης

6.6.1 Εισαγωγή

Η σχεδίαση λογισμικού, ως διαδικασία για την κατάτμηση της

λειτουργικότητας σε μονάδες και τον καθορισμό των σχέσεων μεταξύ

τους, είναι φυσικό να μην επιδέχεται μοναδική λύση. Ωστόσο, στα

πλαίσια της αντικειμενοστρεφούς σχεδίασης υπάρχουν ορισμένες αρχές

που ενσωματώνουν τη συλλογική πείρα που έχει αποκτηθεί από την

κοινότητα των αναλυτών και προγραμματιστών. Η τήρηση των αρχών

αυτών δεν αποτελεί πανάκεια, δεν οδηγεί δηλαδή στη δημιουργία

συστημάτων που δεν πάσχουν από καμία σχεδιαστική ατέλεια. Ωστόσο, η

παραβίαση των αρχών οδηγεί με βεβαιότητα στα συμπτώματα κακής

ποιότητας που αναφέρθηκαν στην ενότητα 6.3.

Ορισμένες από τις αρχές αυτές παρατίθενται στη συνέχεια με

συνοπτική περιγραφή, ώστε ο ενδιαφερόμενος αναγνώστης να ανατρέξει

σε σχετική βιβλιογραφία:

- η Αρχή της Μοναδικής Αρμοδιότητας, σύμφωνα με την οποία

κάθε κλάση πρέπει να έχει μόνο έναν λόγο για να αλλάξει. Σε

επίπεδο ανάλυσης αυτό σημαίνει ότι σε κάθε κλάση δεν θα πρέπει

να ανατίθενται περισσότερες της μιας αρμοδιότητες. Η παραβίασή

της οδηγεί στη δημιουργία κλάσεων που υπόκεινται στις

απαιτήσεις πολλών κλάσεων-πελατών. Αλλαγές που

πραγματοποιούνται λόγω ενός πελάτη ενδέχεται να

δημιουργήσουν προβλήματα στους υπόλοιπους.



- η Αρχή της Ανοικτής-Κλειστής Σχεδίασης, σύμφωνα με την οποία

κάθε μονάδα λογισμικού θα πρέπει να είναι ανοικτή για επέκταση

και κλειστή σε τροποποίηση. Προγραμματιστικά, η αρχή αυτή

επιβάλλει τη χρήση του πολυμορφισμού, ώστε η λειτουργικότητα

μιας κλάσης-πελάτη να μπορεί να επεκτείνεται μέσω της

προσθήκης υποκλάσεων σε κατάλληλη ιεραρχία κλάσεων χωρίς να

τροποποιείται ο κώδικας του πελάτη.

- η Αρχή της Υποκατάστασης, σύμφωνα με την οποία τα

αντικείμενα των υποκλάσεων θα πρέπει να μπορούν να

υποκαθιστούν τα αντικείμενα των υπερκλάσεων. Με άλλα λόγια,

εάν σε ένα σύστημα υπάρχει κληρονομικότητα και κάποιο

πρόγραμμα πελάτης λειτουργεί με αντικείμενα της υπερκλάσης, θα

πρέπει να μπορεί να λειτουργήσει και με αντικείμενα

οποιασδήποτε υποκλάσης.

- η Αρχή της Αντιστροφής των Εξαρτήσεων, σύμφωνα με την οποία

στην αρχιτεκτονική ενός συστήματος λογισμικού οι κλάσεις

υψηλού επιπέδου (αυτές που καθορίζουν τη γενική πολιτική του

συστήματος) δεν θα πρέπει να εξαρτώνται από κλάσεις χαμηλού

επιπέδου (αυτές που καθορίζουν τις λεπτομέρειες υλοποίησης).

Επιτυγχάνεται με κατάλληλη χρήση αφαιρέσεων (αφηρημένων

κλάσεων ή διασυνδέσεων).



6.6.2 Αρχή της Ενσωμάτωσης

Εκτός από τις ανωτέρω αρχές, εκ των οποίων οι τρεις τελευταίες αφορούν

συστήματα που περιλαμβάνουν αφαιρέσεις και ιεραρχίες

κληρονομικότητας (και κατά συνέπεια δεν αφορούν στο σύστημα

Διαχείρισης Παραγγελιών), υπάρχει μια ακόμη θεμελιώδης αρχή, η Αρχή

της ενσωμάτωσης. Σύμφωνα με αυτήν η εσωτερική κατάσταση ενός

αντικειμένου πρέπει να είναι τροποποιήσιμη μόνο μέσω της δημόσιας

διασύνδεσής του. Πρακτικά η αρχή αυτή επιβάλλει η ορατότητα όλων

των ιδιοτήτων μιας κλάσης να είναι ιδιωτική (private). Τροποποιήσεις

στις τιμές των ιδιοτήτων είναι δυνατές μόνο μέσω κατάλληλων δημόσιων

μεθόδων που ο σχεδιαστής της κάθε κλάσης παρέχει ή όχι.

Με τον ορισμό μιας κλάσης επιτυγχάνεται ομαδοποίηση της

συμπεριφοράς και της κατάστασης: Κάθε αντικείμενο – στιγμιότυπο μιας

κλάσης περιλαμβάνει μέλη δεδομένων (ιδιότητες) που συνιστούν την

εσωτερική κατάσταση του αντικειμένου και μεθόδους (που δηλώνονται σε

επίπεδο κλάσης) και καθορίζουν τη συμπεριφορά μιας οικογένειας

αντικειμένων. Σύμφωνα με την ανωτέρω αρχή, οι ιδιότητες πρέπει να μην

είναι προσπελάσιμες εκτός της κλάσης, δηλαδή η τροποποίηση των τιμών

των ιδιοτήτων θα πρέπει να επιτρέπεται μόνο μέσω της πρόσβασης που

παρέχουν οι δημόσια διαθέσιμες μέθοδοι (σχήμα 6.10).



101

Σχήμα 6.10: Αρχή της Ενσωμάτωσης σε ένα αντικείμενο τύπου

Λογαριασμός

Αντικείμενο1 : Λογαριασμός

- όνομα_κατόχου- αριθμός- υποκατάστημα_Τράπεζας- υπόλοιπο

+ υπολογισμός_Τόκων( )+ εκτύπωση_Υπολοίπου( )+ κατάθεση( )+ ανάληψη( )

κατάσταση

συμπεριφορά

πρόσβαση στιςιδιότητες μόνο μέσωτων δημόσιων μεθόδων

Κατ' αυτόν τον τρόπο, ο σχεδιαστής της κλάσης, επιβάλλοντας στον "έξω

κόσμο" να προσπελάσει τις ιδιότητες μέσω των δημόσια διαθέσιμων

μεθόδων, έχει τη δυνατότητα να καθορίσει τους κανόνες και τα

δικαιώματα πρόσβασης. Τα ιδιωτικά μέλη δεδομένων αποκρύπτονται

κατά συνέπεια από τους προγραμματιστές άλλων κλάσεων ή άλλων

συστημάτων (παραμένει ωστόσο η δυνατότητα προσπέλασής τους από

άλλα αντικείμενα της ίδιας κλάσης).

Η παραβίαση της αρχής της ενσωμάτωσης ενδέχεται να οδηγήσει στη

δημιουργία μη έγκυρων αντικειμένων, δηλαδή αντικειμένων των οποίων η

κατάστασή τους δεν είναι ορθή. Για την καλύτερη κατανόηση της έννοιας

της εγκυρότητας ενός αντικειμένου θεωρούμε μια κλάση TimeStamp που



αφορά χρονικά στιγμιότυπα, τα οποία περιλαμβάνουν την ώρα, λεπτά και

δευτερόλεπτα μιας δεδομένης χρονικής στιγμής:

class TimeStamp public: TimeStamp(); TimeStamp(int hr, int min, int sec); void printTimeStamp(); int hour; //μέλη δεδομένων με δημόσια ορατότητα !!! int minute; int second; ;

Στην ανωτέρω κλάση οι προγραμματιστές έχουν αφήσει περιθώρια για

την εμφάνιση σφαλμάτων θέτοντας την ορατότητα των μελών δεδομένων

ως δημόσια (public). Έστω ένα συγκεκριμένο αντικείμενο αυτής της

κλάσης όπως δημιουργείται από την κλήση του κατασκευαστή:

TimeStamp T1(23, 45, 17);

Αν κάποια κλάση – πελάτης της κλάσης TimeStamp θελήσει να αυξήσει

κατά δύο ώρες την χρονική στιγμή επιχειρώντας να τροποποιήσει

απευθείας την ιδιότητα hour του αντικείμενου T1 ως εξής:

//κώδικας κλάσης – πελάτη . . . Τ1.hour++; T1.hour++;

θα προκύψει ένα αντικείμενο (το Τ1), του οποίου η κατάσταση δεν θα

είναι έγκυρη καθώς η χρονική στιγμή στην οποία θα αναφέρεται θα είναι

25:45:17 (!!). Με άλλα λόγια, η ορθότητα του αντικειμένου θα έχει

πάψει να ισχύει, καθώς μια από τις αναλλοίωτες ενός αντικειμένου



TimeStamp δεν θα είναι πλέον αληθής (όπου αναλλοίωτη είναι μια

λογική πρόταση που πρέπει να είναι πάντοτε αληθής).

Αν από την άλλη, η πρόσβαση στα μέλη δεδομένων επιτυγχάνεται

μόνο μέσω των δημόσια διαθέσιμων μεθόδων, τότε ο σχεδιαστής της

κλάσης μπορεί να εγγυηθεί την εγκυρότητα των αντικειμένων σε όλες τις

χρονικές στιγμές. Σχεδιάζοντας τον κατασκευαστή ώστε να παράγει μόνο

έγκυρα αντικείμενα της κλάσης TimeStamp (τα οποία για παράδειγμα

έχουν τιμές ιδιοτήτων που πληρούν προκαθορισμένες συνθήκες π.χ.

) και τις μεθόδους, ώστε να μην καταργούν την ισχύ των

αναλλοίωτων, εξασφαλίζεται ότι ο κώδικας καμιάς άλλης κλάσης δεν

μπορεί να αλλοιώσει την ορθότητα ενός αντικειμένου. Στο ανωτέρω

παράδειγμα, η δυνατότητα αύξησης της ώρας κατά ένα, μπορεί και πρέπει

να παρέχεται μόνο μέσω κατάλληλης μεθόδου incrementHour(), η

οποία θα ελέγχει την περίπτωση υπέρβασης των ορίων. Ταυτοχρόνως, όλα

τα δεδομένα πρέπει να είναι ιδιωτικά. Για παράδειγμα:

230 ≤≤ hour

class TimeStamp . . . public: void incrementHour(); private: int hour; int minute; int second; . . . ;

103



104

void TimeStamp::incrementHour() hour++; if(hour == 24) hour = 0;

Συμπερασματικά, θα πρέπει να σημειωθεί ότι η παραβίαση της αρχής της

ενσωμάτωσης είναι δυνατόν να προκαλέσει ορισμένα από τα πιο

σημαντικά προβλήματα συντήρησης αντικειμενοστρεφούς λογισμικού.

Επιτρέποντας την τροποποίηση ιδιοτήτων ενός αντικειμένου μέσα από

μεθόδους άλλων κλάσεων, στην ουσία καταργείται η ομαδοποίηση

δεδομένων και συμπεριφοράς, στοιχείο που είναι υπεύθυνο για τα

περισσότερα πλεονεκτήματα του αντικειμενοστρεφούς μοντέλου. Αν τα

δεδομένα είναι δημόσια, είναι πολύ δύσκολο να καθοριστεί ποιο τμήμα

του κώδικα του συστήματος εξαρτάται από αυτά τα δεδομένα

χρησιμοποιώντας τα. Το πρόβλημα αυτό, είναι ακριβώς ένα από τα

μειονεκτήματα των διαδικασιακών γλωσσών. Αν λόγω μελλοντικών

απαιτήσεων αλλάξει η αναπαράσταση των δεδομένων, τότε όλα τα

τμήματα κώδικα που τα χρησιμοποιούν πρέπει να ενημερωθούν, ενώ ο

εντοπισμός αυτών των τμημάτων είναι εξαιρετικά επίπονη διαδικασία.



6.7 Ευρετικοί Κανόνες

Όπως ήδη αναφέρθηκε, στην πράξη, η αξιολόγηση της ποιότητας του

σχεδίου μετά το πέρας των φάσεων της ανάλυσης και σχεδίασης

πραγματοποιείται από τους πιο έμπειρους σχεδιαστές της ομάδας

ανάπτυξης. Οι σχεδιαστές αυτοί ουσιαστικά ελέγχουν υποσυνείδητα ή

συνειδητά μια λίστα εμπειρικών ή ευρετικών κανόνων (heuristics) που

έχουν καταρτίσει οι ίδιοι με βάση την εμπειρία τους. Οι κανόνες αυτοί, αν

και μη συστηματικοί, αποτελούν οδηγίες για την εφαρμογή καλών

πρακτικών (best practices). Συνήθως, λόγω πίεσης χρόνου και μεγάλης

κλίμακας, ο έλεγχος περιορίζεται στα τμήματα του έργου που θεωρούνται

σημαντικά ή "ύποπτα" για την εμφάνιση προβλημάτων. Ωστόσο, αυτή η

διαδικασία αξιολόγησης είναι αφενός υποκειμενική και αφετέρου δεν

μπορεί να αυτοματοποιηθεί ώστε να εφαρμοστεί συστηματικά και σε

μεγάλη κλίμακα.

Για το λόγο αυτό, διάφοροι συγγραφείς έχουν επιχειρήσει να

καταγράψουν τους ευρετικούς κανόνες που χρησιμοποιούνται

συνηθέστερα στην πράξη καθώς και τις τεχνικές που απαιτούνται για να

διαπιστωθεί εάν ένα τμήμα λογισμικού παραβιάζει κάποιους από αυτούς.

Οι ευρετικοί κανόνες (το πλήθος των οποίων είναι αρκετά μεγάλο) δεν

είναι αυστηρές προδιαγραφές που πρέπει να τηρούνται απαρέγκλιτα σε

κάθε περίπτωση. Η παραβίαση ενός η περισσοτέρων κανόνων θα πρέπει

να εκλαμβάνεται ως προειδοποιητικό σήμα που υποδηλώνει ότι τμήματα

της σχεδίασης πρέπει να επανεξεταστούν ως προς την ποιότητά τους.



Ενδεικτικά, δύο από τους πλέον διαδεδομένους ευρετικούς κανόνες

περιγράφονται στη συνέχεια ενώ ταυτόχρονα γίνεται μια αναφορά στη

μεθοδολογία ICONIX και στην εφαρμογή τους στο σύστημα διαχείρισης

παραγγελιών που αναπτύσσουμε.

6.7.1 Θεϊκές κλάσεις

Μη δημιουργείτε "θεϊκές" κλάσεις στο σύστημά σας

Ο κανόνας αναφέρεται στην αποφυγή δημιουργίας υπερβολικά "μεγάλων"

κλάσεων (God classes) που αναλαμβάνουν πολύ μεγάλο μέρος της

συνολικής λειτουργικότητας του συστήματος (μορφή συμπεριφοράς) ή

συγκεντρώνουν πολύ μεγάλο πλήθος ιδιοτήτων (μορφή δεδομένων). Τα

συμπτώματα που σχετίζονται με την παραβίαση αυτού του κανόνα είναι

πολλά. Πρώτα από όλα μια υπερβολικά ανεπτυγμένη κλάση συνεπάγεται

δυσκολία κατανόησής της. Επιπλέον, η συγκέντρωση μεθόδων και

ιδιοτήτων (που ενδεχομένως έπρεπε να βρίσκονται σε άλλες κλάσεις)

καταργεί την ομαδοποίηση δεδομένων και συμπεριφοράς (δημιουργώντας

προβλήματα συντήρησης και εντοπισμού εξαρτήσεων στο λογισμικό) και

επιβάλλει την αποστολή μεγάλου αριθμού μηνυμάτων από και προς την

θεϊκή κλάση αυξάνοντας τη σύζευξη του συστήματος.

Ο ανωτέρω ευρετικός κανόνας είναι από τους απλούστερους στον

έλεγχο τους καθώς ακόμα και η απλή εξέταση του διαγράμματος κλάσεων

μπορεί να οδηγήσει σε διαπίστωση της τυχόν παραβίασής του. Ωστόσο,

κυρίως από τους προγραμματιστές με υπόβαθρο σε διαδικασιακές



γλώσσες προγραμματισμού, είναι αρκετά εύκολο να δημιουργηθούν

θεϊκές κλάσεις που μεταφέρουν στο αντικειμενοστρεφές μοντέλο το

μηχανισμό ελέγχου και συντονισμού ή μεγάλες δομές δεδομένων που

υπάρχουν σε μη αντικειμενοστρεφή συστήματα.

Η εφαρμογή μιας μεθοδολογίας ανάλυσης και σχεδίασης όπως η

ICONIX λόγω της προσέγγισης που βασίζεται στις απαιτήσεις (οι οποίες

στις περισσότερες περιπτώσεις κατανέμουν τη λειτουργικότητα σε

διαφορετικές περιπτώσεις χρήσεις), συνήθως καταλήγει στη σχεδίαση

συστημάτων χωρίς θεϊκές κλάσεις. Για το λόγο αυτό στο σύστημα

διαχείρισης παραγγελιών, όπως φαίνεται στο διάγραμμα κλάσεων του

σχήματος 6.8, υπάρχει σχετικά ομοιόμορφη κατανομή της

λειτουργικότητας (και των δεδομένων), χωρίς να εμφανίζονται

υπερβολικά ανεπτυγμένες κλάσεις.

6.7.2 Νόμος της Δήμητρας

Κάθε κλάση θα πρέπει να έχει περιορισμένη γνώση των υπολοίπων

κλάσεων. Θα πρέπει να γνωρίζει μόνο τις μονάδες που σχετίζονται

"στενά" με αυτήν (Νόμος της Δήμητρας)

Ο ανωτέρω ευρετικός κανόνας έχει διατυπωθεί απλούστερα ως "Να μιλάτε

μόνο σε φίλους σας. Μη μιλάτε σε ξένους" και υπονοεί ότι μια κλάση δεν

θα πρέπει να προσπελαύνει μεθόδους κλάσεων που δεν είναι "άμεσοι"

γείτονές της (δηλαδή κλάσεις προς τις οποίες έχει κάποια αναφορά).



Σύμφωνα με τον κανόνα αυτό μια μέθοδος f μιας κλάσης C θα πρέπει να

καλεί μόνο:

- άλλες μεθόδους της C

- μεθόδους κλάσεων που αποτελούν τύπους ιδιοτήτων της C

- μεθόδους κλάσεων που αποτελούν παραμέτρους της f

- μεθόδους κλάσεων των οποίων αντικείμενα δημιουργούνται στην f

- μεθόδους κλάσεων που αποτελούν επιστρεφόμενους τύπους

μεθόδων της C

Η παραβίαση του κανόνα εμφανίζεται όταν για παράδειγμα μια μέθοδος

καλεί μεθόδους αντικειμένων για τα οποία λαμβάνει αναφορές από άλλες

κλάσεις όπως στο ακόλουθο τμήμα κώδικα: public class C

public int method1(ClassType ref)

int value;

value = ref.getX().getY().getZ().getValue();

return value;

Στην περίπτωση αυτή η κλάση C "μιλάει" (αποστέλλει μηνύματα) με

κλάσεις που δεν είναι "άμεσοι" γείτονες της με βάση τις περιπτώσεις που

αναφέρθηκαν. Δημιουργείται επομένως μια αναίτια σύζευξη μεταξύ των

κλάσεων αυτών που δημιουργεί σημαντικά προβλήματα συντήρησης. Αν

για παράδειγμα αλλάξει λόγω μελλοντικών απαιτήσεων η υπογραφή της

μεθόδου getValue() στο ανωτέρω παράδειγμα, θα επηρεαστούν όχι



μόνο οι κλάσεις που καλούν άμεσα τη μέθοδο, αλλά και η κλάση C που

αποκτά πρόσβαση στη μέθοδο δια μέσου μιας αλυσίδας κλήσεων,

στοιχείο που είναι δύσκολο να εντοπιστεί ώστε να προληφθούν

σφάλματα.

Η εφαρμογή της μεθοδολογίας ICONIX συμβάλλει στην αποφυγή

παραβίασης του κανόνα της Δήμητρας καθώς η επικοινωνία μεταξύ των

αντικειμένων που τεκμηριώνεται στα διαγράμματα ακολουθίας στηρίζεται

στην ύπαρξη αντίστοιχων συσχετίσεων μεταξύ των κλάσεών τους στο

στατικό μοντέλο του συστήματος.



7.Υλοποίηση 7.1 Επισκόπηση δυνατοτήτων σύγχρονων CASE tools

Όπως ισχύει και για άλλα τεχνικά έργα, η ανάπτυξη σύγχρονων

συστημάτων λογισμικού δεν μπορεί να πραγματοποιηθεί αποδοτικά χωρίς

τη χρήση κατάλληλων εργαλείων. Τα εργαλεία αυτά στην Τεχνολογία

Λογισμικού είναι γνωστά ως εργαλεία υποστήριξης της διαδικασίας

ανάπτυξης ή συνηθέστερα ως εργαλεία CASE (Computer-Aided Software

Engineering tools). Οι δυνατότητες των εργαλείων αυτών ποικίλουν και

εμπλουτίζονται διαρκώς με την πρόοδο που συντελείται σε ερευνητικό

επίπεδο στην Τεχνολογία Λογισμικού. Στη γενική περίπτωση ένα

εργαλείο CASE επιτρέπει τη διαχείριση (δημιουργία, τροποποίηση,

παρακολούθηση και συσχέτιση) όλων των κατασκευασμάτων (artifacts)

της διαδικασίας ανάπτυξης λογισμικού, είτε αυτά είναι κώδικας, έγγραφα

τεκμηρίωσης, περιπτώσεις ελέγχου, απαιτήσεις, γραφικά κλπ. Σημαντικό

είναι το γεγονός ότι στα εργαλεία CASE η πληροφορία που αφορά τα

διαφορετικά μοντέλα του υπό ανάπτυξη συστήματος (απαιτήσεις,

αρχιτεκτονική, κώδικας, περιπτώσεις ελέγχου) αποθηκεύεται σε μία μόνο

θέση. Οποιαδήποτε αλλαγή στην πληροφορία μεταβιβάζεται αυτόματα σε

όλα τα εμπλεκόμενα μοντέλα. Επιπλέον υπάρχει η δυνατότητα πλοήγησης

από μία περιγραφή ενός μοντέλου (π.χ. κάποιο διάγραμμα) σε

οποιαδήποτε άλλη. Τέλος, τα περισσότερα εργαλεία CASE επιτρέπουν τη

συγχρονισμένη ανάπτυξη λογισμικού από πολλούς χρήστες



χρησιμοποιώντας μια κοινή αποθήκη (repository) των παραγόμενων

προϊόντων.

7.2 Αντιστοίχιση UML και Java

Σύμφωνα με το επίσημο εγχειρίδιο αναφοράς, η Ενοποιημένη Γλώσσα

Μοντελοποίησης δεν είναι μια γλώσσα προγραμματισμού. Ωστόσο,

υπάρχει αντιστοίχιση σε μεγάλο βαθμό μεταξύ των διαγραμμάτων της

UML (και ειδικά των διαγραμμάτων κλάσεων και ακολουθίας) και των

δομών που υποστηρίζουν οι αντικειμενοστρεφείς γλώσσες

προγραμματισμού, όπως η Java και η C++. Επειδή ως γλώσσα

προγραμματισμού για το σύστημα διαχείρισης παραγγελιών επιλέχθηκε η

Java, θα εξεταστούν στη συνέχεια ορισμένοι συμβολισμοί στα

διαγράμματα κλάσεων της UML και του κώδικα Java που αντιστοιχεί σε

αυτούς.



7.2.1 Κλάσεις

Για την κλάση Ingredient του συστήματος που αναπτύσσουμε, η οποία

στη UML συμβολίζεται ως εξής:

ο αντίστοιχος κώδικας στη γλώσσα Java είναι:

//Java public class Ingredient private String name; private int amount; public String getName() return; public boolean checkQuantity(int x) return; public void remove(int x) return;

Όπως γίνεται εύκολα αντιληπτό, οι ιδιότητες και οι μέθοδοι που

απεικονίζονται στο διάγραμμα "μεταφράζονται" σε ιδιότητες και

μεθόδους της αντίστοιχης κλάσης, λαμβάνοντας υπόψη τους τύπους

δεδομένων των ιδιοτήτων (π.χ. String για την ιδιότητα name) καθώς και




τους τύπους δεδομένων για τις επιστρεφόμενες τιμές και τις παραμέτρους

των μεθόδων (π.χ. boolean για τη μέθοδο checkQuantity). Τα

προσδιοριστικά ορατότητας των ιδιοτήτων και των μεθόδων που

καθορίζονται σε ένα μοντέλο UML μεταφράζονται στα αντίστοιχα

προσδιοριστικά της γλώσσας προγραμματισμού. Ο συμβολισμός που

χρησιμοποιείται στη UML για την ορατότητα είναι ' + ' (για public), ' - '

(για private), ' # ' (για protected).

Στα περισσότερα εργαλεία ανάπτυξης, για όλες τις ιδιότητες που είναι

δηλωμένες ως ιδιωτικές (private) υπάρχει η δυνατότητα αυτόματης

προσθήκης στον παραγόμενο κώδικα, των αντίστοιχων μεθόδων

πρόσβασης και τροποποίησης των τιμών τους (μέθοδοι get() και set()

αντίστοιχα). Επίσης, υπάρχει η δυνατότητα προσθήκης ενός κενού

κατασκευαστή στον παραγόμενο κώδικα, ακόμα και αν αυτός δεν

υποδηλώνεται ρητά στο διάγραμμα μιας κλάσης. Οι δυνατότητες αυτές

παρέχονται συνήθως ως δυνητικές επιλογές στο χρήστη, δηλαδή μπορούν

να ενεργοποιηθούν ή να απενεργοποιηθούν.

Παρόλο που είναι λογικό να αναμένει κανείς ότι ένα εργαλείο δεν

μπορεί να "συμπληρώσει" με κώδικα το σώμα των μεθόδων μιας κλάσης,

στα σύγχρονα περιβάλλοντα ανάπτυξης λογισμικού έχουν γίνει

προσπάθειες και προς αυτή την κατεύθυνση. Για παράδειγμα, αν στα

διαγράμματα ακολουθίας του μοντέλου προσδιορίζεται επακριβώς ποια

μηνύματα αποστέλλει μια κλάση μετά τη λήψη ενός μηνύματος alpha,

τότε στο σώμα της μεθόδου alpha() προστίθεται αυτόματα κώδικας


για την αποστολή των αντίστοιχων μηνυμάτων (κλήση των αντίστοιχων

μεθόδων). Έστω ότι σε ένα διάγραμμα ακολουθίας απεικονίζεται το

σενάριο που παρουσιάζεται στο σχήμα 7.1:

Σχήμα 7.1: Διάγραμμα ακολουθίας από το οποίο μπορεί να παραχθεί

κώδικας

τότε κατά την παραγωγή του κώδικα για την κλάση Β (θεωρώντας ότι

υφίστανται ήδη στην κλάση Β αναφορές προς τις κλάσεις C και D) είναι

δυνατόν να παραχθεί αυτόματα το σώμα της μεθόδου doSmth(), όπως

φαίνεται από τα σχόλια στον ακόλουθο κώδικα:



public class B

private C c1;;

private D d1;

public void doSmth()

// generated by Together

// Message #1.1 to c1:C

c1.method1(); //αποστολή μηνύματος method1

// Message #1.2 to d1:D

d1.method2(); //αποστολή μηνύματος method2

115



7.2.2 Συσχετίσεις

Στην περίπτωση όπου μεταξύ δύο κλάσεων υπάρχει μονόδρομη συσχέτιση

(association), δηλαδή συσχέτιση με κατεύθυνση από τη μία μόνο κλάση

προς την άλλη, όπως για παράδειγμα μεταξύ της κλάσης που αναλαμβάνει

τη γραφική διασύνδεση χρήστη για την οθόνη "Ετοιμασία Παραγγελίας"

(PrepareOrderFrame) και της πρώτης παραγγελίας στην ουρά

παραγγελιών, που απεικονίζεται στο ακόλουθο διάγραμμα κλάσεων:

τότε ο κώδικας της κλάσης PrepareOrderFrame αποκτά μια ιδιότητα

τύπου Order (αναφορά προς την κλάση Order) όπως φαίνεται στη

συνέχεια: public class PrepareOrderFrame . . . private Order firstOrder; //αναφορά λόγω της //συσχέτισης . . .



Επισημαίνεται ότι το όνομα της αντίστοιχης αναφοράς λήφθηκε από το

όνομα της αντίστοιχης συσχέτισης. Καθώς η συσχέτιση είναι μονόδρομη,

αναφορά από την κλάση Order προς την κλάση PrepareOrderFrame δεν

υπάρχει, δηλαδή μόνο η κλάση PrepareOrderFrame μπορεί να αποστείλει

μηνύματα (να καλέσει μεθόδους) στην κλάση Order. Σε ορισμένα

εργαλεία CASE υπάρχει η δυνατότητα αυτόματου εφοδιασμού της

κλάσης όπου προστίθεται η αναφορά, με μεθόδους get() και set() για

την επιστροφή της τιμής ή τον καθορισμό της τιμής της αναφοράς,

αντίστοιχα.

Εάν η συσχέτιση μεταξύ δύο κλάσεων είναι αμφίδρομη, υπάρχουν

αναφορές από κάθε κλάση προς την άλλη. Στην περίπτωση αυτή

οποιαδήποτε κλάση μπορεί να αποστείλει μηνύματα στην άλλη. Ο

απλούστερος τρόπος συμβολισμού σε ένα διάγραμμα κλάσεων είναι η

χρήση μιας γραμμής χωρίς βέλη:

Στο ανωτέρω διάγραμμα, δεν απεικονίζεται το όνομα της αμφίδρομης

συσχέτισης, αλλά τα ονόματα των ρόλων που έχει η κάθε κλάση, στα

πλαίσια της σχέσης. Τα ονόματα των ρόλων αξιοποιούνται για την



ονομασία των αντίστοιχων ιδιοτήτων σε κάθε κλάση, όπως φαίνεται στον

αντίστοιχο κώδικα: public class PrepareOrderFrame . . . private Order firstOrder; //αναφορά λόγω της //συσχέτισης . . . public class Order . . . private PrepareOrderFrame frame; //αναφορά λόγω της //συσχέτισης . . .



7.2.3 Συσχετίσεις με πολλαπλότητα

Στην περίπτωση που το ένα άκρο μιας συσχέτισης έχει πολλαπλότητα

διαφορετική από 1 (οπότε και κρίνεται σκόπιμο να σημειωθεί η τιμή της

πολλαπλότητας στο διάγραμμα κλάσεων), η υλοποίηση της συσχέτισης

τροποποιείται ανάλογα. Αν υποθέσουμε ότι ένα αντικείμενο της κλάσης

PrepareOrderFrame μπορούσε να σχετίζεται με περισσότερες από μία

παραγγελίες (αντικείμενα της κλάσης Order), το διάγραμμα κλάσεων της

UML θα είχε την ακόλουθη μορφή:

Στον κώδικα της κλάσης PrepareOrderFrame θα πρέπει να υπάρχει πλέον

μια δομή δεδομένων που να επιτρέπει την ύπαρξη πολλών αναφορών από

ένα αντικείμενο PrepareOrderFrame προς αντικείμενα της κλάσης Order.

Πολλές εναλλακτικές δυνατότητες υπάρχουν για το σκοπό αυτό σε

επίπεδο υλοποίησης, μια απλή ωστόσο περίπτωση είναι η χρήση μιας

λίστας αντικειμένων τύπου Order, όπως φαίνεται στον ακόλουθο κώδικα

(στην περίπτωση αυτή χρησιμοποιούμε τη δυνατότητα των generics που

υπάρχει από την έκδοση 1.5 της Java όπου δηλώνουμε ρητά τον τύπο των

στοιχείων που περιλαμβάνονται σε μία δομή δεδομένων):

119



120

import javax.util.ArrayList; public class PrepareOrderFrame . . . private ArrayList<Order> orders; //λίστα αναφορών //λόγω της //συσχέτισης //με πολλαπλότητα . . .

Στην περίπτωση που η τιμή της πολλαπλότητας έχει μια συγκεκριμένη

τιμή (διάφορη του 1), υπάρχει η δυνατότητα υλοποίησης της συσχέτισης

με απλούστερες μορφές τύπων, όπως για παράδειγμα απλοί πίνακες

αναφορών. Αν για παράδειγμα, στο προηγούμενο παράδειγμα η τιμή της

πολλαπλότητας στη συσχέτιση orders ήταν 5 (στο άκρο της κλάσης

Order), ο κώδικας της κλάσης PrepareOrderFrame θα μπορούσε να

περιλαμβάνει έναν πίνακα 5 θέσεων όπου κάθε στοιχείο να είναι αναφορά

προς αντικείμενο τύπου Order.

Όπως αναφέρθηκε, ένα συνηθισμένο σφάλμα κατά τη σχεδίαση είναι ο

συμβολισμός των συσχετίσεων και ως ακμές μεταξύ κλάσεων και ως

ιδιότητες στις αντίστοιχες κλάσεις. Εκτός του ότι η ανωτέρω πρακτική

οδηγεί σε περιττή πολυπλοκότητα των διαγραμμάτων κλάσεων, οι

πλεονασματικοί συμβολισμοί θα προκαλέσουν τη διπλή παραγωγή των

αντίστοιχων ιδιοτήτων από τα εργαλεία αυτόματης παραγωγής κώδικα.



7.2.4 Σχέσεις Περιεκτικότητας

Οι σχέσεις περιεκτικότητας της UML αναπαριστούν μια σχέση συνόλου-

τμήματος μεταξύ των αντικειμένων δύο κλάσεων. Η συναρμολόγηση ή

συσσωμάτωση (aggregation) είναι μια σχέση περιεκτικότητας ασθενούς

μορφής, όπου τα αντικείμενα της κλάσης που αντιστοιχεί στο σύνολο

περιλαμβάνουν τα αντικείμενα που αντιστοιχούν στα τμήματα. Στα

πλαίσια της συναρμολόγησης θεωρείται ότι το σύνολο δεν έχει την

αποκλειστική ευθύνη διαχείρισης των τμημάτων, δηλαδή τα τμήματα

μπορούν να υφίστανται στο σύστημα ακόμα και αν διαγραφεί το σύνολο.

Η συναρμολόγηση συμβολίζεται ως συσχέτιση με ένα λευκό ρόμβο στο

άκρο που αντιστοιχεί στο σύνολο.

Η σύνθεση (composition) είναι μια σχέση περιεκτικότητας

ισχυρότερης μορφής, όπου τα αντικείμενα της κλάσης που αντιστοιχεί στο

σύνολο έχουν την αποκλειστική ευθύνη διαχείρισης των τμημάτων. Με

άλλα λόγια, αν διαγραφεί σε μια σχέση σύνθεσης το αντικείμενο που

αντιστοιχεί στο σύνολο θα διαγραφούν από το σύστημα και τα

αντικείμενα που αντιστοιχούν στα τμήματα. Η σύνθεση συμβολίζεται ως

συσχέτιση με ένα μαύρο ρόμβο στο άκρο που αντιστοιχεί στο σύνολο. Ως

ιδιαίτερες περιπτώσεις συσχετίσεων, οι σχέσεις περιεκτικότητας μπορούν

να περιλαμβάνουν πολλαπλότητα.

Παρόλο που σε ορισμένες αντικειμενοστρεφείς γλώσσες

προγραμματισμού όπως η C++ η συναρμολόγηση διακρίνεται από τη

σύνθεση σε επίπεδο υλοποίησης, στη γλώσσα Java τα δύο είδη σχέσεων



δεν διαφέρουν στην υλοποίηση αλλά ούτε και διαφέρουν από την

υλοποίηση μιας απλής συσχέτισης. Σε όλες τις περιπτώσεις η αντίστοιχη

σχέση υλοποιείται με την προσθήκη κατάλληλων αναφορών στις

εμπλεκόμενες κλάσεις. Η διαφοροποίηση έχει ισχύ μόνο στο εννοιολογικό

μοντέλο και όπως έγινε ήδη φανερό από την κατασκευή του μοντέλου του

πεδίου προβλήματος, στόχος είναι ο εντοπισμός σχέσεων περιεκτικότητας

μεταξύ των κλάσεων. Επομένως, η συναρμολόγηση μεταξύ Παραγγελίας

και Πιάτου στο σύστημα που αναπτύσσουμε και παρουσιάζεται στο

ακόλουθο διάγραμμα:

122

υλοποιείται στη γλώσσα Java (λαμβάνοντας υπόψη την πολλαπλότητα) ως

εξής:

public class Order . . . private ArrayList<Plate> plates; //λίστα αναφορών //λόγω της //συναρμολόγησης . . .



7.2.5 Σχέσεις Κληρονομικότητας

Όλες οι αντικειμενοστρεφείς γλώσσες προγραμματισμού περιλαμβάνουν

μηχανισμούς που υποστηρίζουν την έννοια της κληρονομικότητας, η

οποία στηρίζεται στη γενίκευση/εξειδίκευση - σχέση που συνδέει μια

γενική κλάση (βασική κλάση ή υπερκλάση) με μια ειδικότερη κλάση

(παράγωγη κλάση ή υποκλάση), η οποία κληρονομεί από τη γενική

κλάση ιδιότητες και συμπεριφορά.

Στο σύστημα διαχείρισης παραγγελιών δεν υπάρχει (χάριν απλότητας)

κάποια σχέση κληρονομικότητας, αλλά ας υποθέσουμε ότι το σύστημα

μπορούσε να διαχειριστεί εκτός από πιάτα και ποτά. Τότε, σε κάθε

παραγγελία θα μπορούσαν να προστεθούν δύο Στοιχεία Παραγγελίας είτε

Πιάτα, είτε Ποτά. Αν υποθέσουμε επίσης ότι τα πιάτα και ποτά είχαν

κάποιες κοινές ιδιότητες (όπως το όνομά τους) και κάποιες κοινές

λειτουργίες (όπως ο έλεγχος διαθεσιμότητας ή η επιλογή), αλλά και

κάποιες διαφορετικές λειτουργίες (για παράδειγμα η μέθοδος

καταχώρησης συστατικών – storeIngredient() δεν θα είχε νόημα για

ένα ποτό), τότε η μοντελοποίηση των δύο αυτών κλάσεων θα μπορούσε

να γίνει με βέλτιστο τρόπο, αξιοποιώντας το μηχανισμό της

κληρονομικότητας. Συγκεκριμένα, στο πεδίο προβλήματος θα μπορούσε

να προστεθεί μία αφαίρεση (μια αφηρημένη κλάση από την οποία δεν

δημιουργούνται αντικείμενα) για την αναπαράσταση της έννοιας Στοιχείο

Παραγγελίας (OrderItem). Οι κλάσεις Πιάτο και Ποτό θα αποτελούσαν

υποκλάσεις του Στοιχείου Παραγγελίας, κληρονομώντας από αυτό τις



κοινές τους ιδιότητες και μεθόδους. Ωστόσο, κάθε υποκλάση μπορεί να

περιλαμβάνει επιπρόσθετες ιδιότητες ή μεθόδους που αφορούν μόνο

αυτήν. Το υποθετικό αυτό μοντέλο απεικονίζεται στο διάγραμμα κλάσεων

που ακολουθεί:

Σημειώνεται ότι, στο ανωτέρω διάγραμμα το όνομα της κλάσης

OrderItem είναι γραμμένο με πλάγιους χαρακτήρες, στοιχείο που

υποδηλώνει ότι η κλάση είναι αφηρημένη (το ότι μια κλάση είναι

αφηρημένη θα μπορούσε εναλλακτικά να συμβολιστεί με χρήση κάποιου

στερεοτύπου, όπως <<abstract>>). Για το λόγο αυτό στον κώδικα

προστίθεται το προσδιοριστικό abstract πριν από το όνομα της κλάσης.

Επίσης, η υπογραφή της μεθόδου isAvailable() στην κλάση

OrderItem είναι με πλάγιους χαρακτήρες, υποδηλώνοντας πάλι ότι η

μέθοδος είναι αφηρημένη, δεν έχει δηλαδή υλοποίηση. Για το λόγο αυτό,



η μέθοδος isAvailable() εμφανίζεται στις δύο υποκλάσεις όπου

πρέπει υποχρεωτικά να έχει υλοποίηση. Η υλοποίηση σε κάθε υποκλάση

μπορεί (και πρέπει) να είναι διαφορετική αφενός γιατί η διαθεσιμότητα

ενός πιάτου μπορεί να υπολογίζεται διαφορετικά από τη διαθεσιμότητα

ενός ποτού, αφετέρου διότι αν η υλοποίηση ήταν κοινή, σχεδιαστικά θα

ήταν ορθό η κοινή υλοποίηση να μεταφερθεί στην υπερκλάση. Η δήλωση

μιας κλάσης στη Java ως υποκλάσης μιας κλάσης Α, υποδηλώνεται με το

προσδιοριστικό extends A. Ο αντίστοιχος κώδικας για τις τρεις κλάσεις

στην Java είναι:

public abstract class OrderItem private String name; public void setName(String text) public String getName() return; public abstract boolean isAvailable(); public void pick() public class Plate extends OrderItem private int calories; public void storeIngredient(Ingredient ingr, int amount) public int getCalories()

125



126

public boolean isAvailable() return; public class Drink extends OrderItem private double percentageOfAlcohol; public double getPercentageOfAlcohol() return; public boolean isAvailable() return;



7.3 Αντίστροφη Μηχανική

7.3.1 Συνέπεια μεταξύ κώδικα και τεκμηρίωσης

Ένα από τα σημαντικότερα προβλήματα που αντιμετωπίζουν οι εταιρείες

ανάπτυξης λογισμικού, είναι η ασυνέπεια που παρατηρείται μεταξύ

τεκμηρίωσης ενός έργου λογισμικού και του κώδικα, μετά από κάποιο

χρονικό διάστημα εξέλιξης ενός έργου. Ο λόγος είναι ότι πολύ συχνά, η

προσπάθεια για την ικανοποίηση νέων απαιτήσεων από τους πελάτες

γίνεται με πολύ στενά χρονικά περιθώρια, με αποτέλεσμα τα μέλη της

ομάδας ανάπτυξης να δίνουν προτεραιότητα στην υλοποίηση του κώδικα

παραμελώντας την ενημέρωση των υπολοίπων εγγράφων ή διαγραμμάτων

που αντιστοιχούν στις διάφορες φάσεις ανάπτυξης. Έτσι, δεν είναι σπάνιο,

το έγγραφο περιγραφής απαιτήσεων λογισμικού ή το έγγραφο περιγραφής

σχεδίου να αναφέρονται στην 1η γενιά ενός συστήματος λογισμικού, ενώ

ο κώδικας να έχει τροποποιηθεί σε πολλές γενιές και να σχετίζεται σε

μικρό βαθμό με τις απαιτήσεις ή το σχέδιο που είναι καταγεγραμμένο.

Στην περίπτωση αυτή, η αξία της τεκμηρίωσης ως εργαλείο για την

ευκολότερη κατανόηση και συντήρηση του λογισμικού περιορίζεται

σημαντικά.

Ένα από τα σημαντικά πλεονεκτήματα των εργαλείων που

υποστηρίζουν την ανάπτυξη λογισμικού αξιοποιώντας τη UML είναι η

δυνατότητα εξαγωγής πληροφορίας από πηγαίο κώδικα (ή και μορφή

bytecode) και η κατασκευή ή ενημέρωση ενός μοντέλου UML. Με άλλα

λόγια, η συνήθης διαδικασία παραγωγής κώδικα από διαγράμματα



αντιστρέφεται, και εξάγονται διαγράμματα (συνήθως κλάσεων και

ακολουθίας) από υπάρχοντα κώδικα. Η δυνατότητα αυτή είναι γνωστή ως

αντίστροφη μηχανική (reverse engineering) και επιτρέπει τη διατήρηση

ενός μοντέλου σε συνέπεια με τον κώδικα καθώς οποιαδήποτε αλλαγή

στον κώδικα ενημερώνει αυτόματα τη σχετική τεκμηρίωση με

διαγράμματα UML (συγχρονισμός μοντέλου - κώδικα).

7.3.2 Εξαγωγή διαγράμματος κλάσεων

Για να γίνουν αντιληπτές ορισμένες από τις δυνατότητες αντίστροφης

μηχανικής των σύγχρονων εργαλείων CASE, θεωρούμε το ακόλουθο (μη

πλήρες) τμήμα κώδικα:

public abstract class Employee protected String name; protected String socialSecNumber; public abstract void calculateTax(); public class AdministrativeEmployee extends Employee public void calculateTax() import java.util.ArrayList; public class Department private String name;

128



129

private ArrayList employees; public void addEmployee(Employee emp) employees.add(emp); Από τον ανωτέρω κώδικα παράγεται αυτόματα το αντίστοιχο μοντέλο υπό

μορφή διαγράμματος κλάσεων της UML:

Σχήμα 7.2: Διάγραμμα κλάσεων παραγόμενο από αντίστροφη μηχανική

Αξίζει να σημειωθεί ότι κατά την αντίστροφη μηχανική παρατηρήθηκε ότι

υπάρχει λίστα αναφορών στην κλάση Department και ιδιαίτερα ότι με τη

μέθοδο add() της κλάσης, προστίθενται αντικείμενα τύπου Employee

στη λίστα αυτή. Για το λόγο αυτό προστέθηκε στο διάγραμμα κλάσεων η

συσχέτιση από την κλάση Department και διαπιστώθηκε ότι πρέπει να

καταλήγει στην κλάση Employee και μάλιστα με πολλαπλότητα "πολλά".

(Η δυνατότητα αυτή αποτελεί ένα από τα πλέον εξελιγμένα



χαρακτηριστικά των εργαλείων CASE και προς το παρόν δεν προσφέρεται

στα περισσότερα εργαλεία). Η συσχέτιση απέκτησε το όνομα της

αντίστοιχης ιδιότητας στην κλάση Department (employees).

Επιπλέον, από τον πηγαίο κώδικα αντλήθηκαν και όλες οι υπόλοιπες

πληροφορίες που μπορούν να απεικονιστούν στο διάγραμμα κλάσεων,

όπως ονόματα κλάσεων, μεθόδων και ιδιοτήτων καθώς και τα

προσδιοριστικά ορατότητας των μεθόδων και ιδιοτήτων (public, private

και protected). Τέλος, στο διάγραμμα επισημαίνεται με χρήση πλαγίων

χαρακτήρων, το γεγονός ότι η κλάση Employee καθώς και η μέθοδος

calculateTax() στην ίδια κλάση είναι αφηρημένες.

7.3.3 Εξαγωγή διαγράμματος ακολουθίας

Αντίστοιχες δυνατότητες υπάρχουν και για την εξαγωγή διαγραμμάτων

ακολουθίας από πηγαίο κώδικα. Θεωρούμε για παράδειγμα το ακόλουθο

τμήμα κώδικα ενός συστήματος ενοικίασης ταινιών που περιλαμβάνει τις

κλάσεις Rental και Μοvie. import java.util.ArrayList; public class Rental private ArrayList movies; public Rental() movies = new ArrayList();



131

public void addMovie(Movie movie) movies.add(movie); public double getRentalCost() double sum = 0; for(int i=0; i<movies.size(); i++) Movie movie = (Movie)movies.get(i); sum += movie.getPrice(); return sum; public class Movie private String title; private double price; public Movie(String title, double price) this.title = title; this.price = price; public String getTitle() return this.title; public double getPrice() return this.price;

Η αυτόματη εξαγωγή διαγράμματος ακολουθίας από τη μέθοδο

getRentalCost() της κλάσης Rental παράγει το διάγραμμα που

παρουσιάζεται στο σχήμα 7.3. Όπως γίνεται φανερό, εντοπίστηκε η

αποστολή του μηνύματος getPrice() από το αντικείμενο της κλάσης



Rental προς το συσχετιζόμενο αντικείμενο της κλάσης Movie και

επιπλέον, εντοπίστηκε το γεγονός ότι η κλήση της αντίστοιχης μεθόδου

πραγματοποιείται μέσα σε βρόχο επαναλήψεων.

Σχήμα 7.3: Διάγραμμα ακολουθίας παραγόμενο από αντίστροφη

μηχανική



8. Πλήρης κωδικοποίηση του συστήματος Το διάγραμμα κλάσεων που δημιουργήθηκε από τη διαδικασία της

αντικειμενοστρεφούς ανάλυσης και σχεδίασης (σχήμα 6.8) αντιστοιχεί

πλήρως στον κώδικα που πρόκειται να υλοποιηθεί. Ωστόσο, δεν

περιλαμβάνει τις κλάσεις της γραφικής διασύνδεσης χρήστη που

αναλαμβάνουν να εμφανίσουν τις οθόνες του συστήματος και να

χειριστούν την αλληλεπίδραση με το χρήστη. Είναι καλή σχεδιαστική

αρχή να διακρίνουμε τη λειτουργικότητα της λογικής του συστήματος

(business logic) από τη λειτουργικότητα που σχετίζεται με την

αλληλεπίδραση με το χρήστη. Το πλεονέκτημα που προκύπτει είναι η

μείωση της εξάρτησης μεταξύ των κλάσεων οντοτήτων του συστήματος

και των κλάσεων της γραφικής διασύνδεσης με αποτέλεσμα αλλαγές στην

εμφάνιση της εφαρμογής να μην "διαδίδονται" ως αλλαγές στις κλάσεις

του μοντέλου καθώς και το αντίστροφο. Η αρχή αυτή εφαρμόζεται

αποφεύγοντας την προσθήκη στις κλάσεις της γραφικής διασύνδεσης

χρήστη μεθόδων που δεν σχετίζονται με την εμφάνιση γραφικών

συστατικών ή τον χειρισμό συμβάντων. Ένα σχετικό πρότυπο με αυτή την

αρχή είναι η αρχιτεκτονική Μοντέλου-Όψης-Ελεγκτή που παρουσιάζεται

στην ενότητα 8.4.

Το πλήρες διάγραμμα κλάσεων, συμπεριλαμβανομένων των κλάσεων

διασύνδεσης με το χρήστη απεικονίζεται στο σχήμα 8.1.



Σχήμα 8.1: Πλήρες διάγραμμα κλάσεων του συστήματος

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

διασύνδεση χρήστη απεικονίζονται με γκρι φόντο. Η κλάση MainFrame

που αντιστοιχεί στην Κεντρική Οθόνη του συστήματος, σχετίζεται με μια

σχέση creates με τις υπόλοιπες κλάσεις της διασύνδεσης χρήστη (μια

διακεκομμένη γραμμή με το στερεότυπο <<creates>>) που δηλώνει ότι

η κλάση δημιουργεί στιγμιότυπα των άλλων κλάσεων (μόλις ο χρήστης

επιλέξει το αντίστοιχο πλήκτρο). Η μοναδική κλάση που δεν

απεικονίζεται στο διάγραμμα είναι η κλάση Main που περιλαμβάνει τη

στατική μέθοδο main() από όπου ξεκινά η εκτέλεση του προγράμματος.

Με βάση την τρέχουσα σχεδίαση, η μέθοδος main() δημιουργεί ένα



αντικείμενο της κλάσης MainFrame καθώς και αντικείμενα της κλάσης

Συστατικό (Ingredient) που τα τοποθετεί στον Κατάλογο Συστατικών.

Ο κώδικας των 11 κλάσεων του συστήματος παρατίθεται στη συνέχεια

μαζί με περιγραφή των ιδιοτήτων και της υλοποίησης των μεθόδων τους.

Τα σχόλια που περιέχονται στους κώδικες είναι περιορισμένα καθώς ένα

από τα πλεονεκτήματα του αντικειμενοστρεφούς προγραμματισμού είναι

ότι με τον κατάλληλο διαχωρισμό της λειτουργικότητας σε κλάσεις και

μεθόδους και την επιλογή κατάλληλων ονομάτων, απαιτούνται ελάχιστα ή

καθόλου σχόλια. Όπως χαρακτηριστικά αναφέρεται, ο ίδιος ο κώδικας

επεξηγεί τη λειτουργία του.

Ο πηγαίος κώδικας του συστήματος καθώς και ένα εκτελέσιμο αρχείο

(.jar) της εφαρμογής είναι διαθέσιμα στη διεύθυνση

http://java.uom.gr/OOD/OrderManagement.zip.


http://java.uom.gr/OOD/OrderManagement.zip


8.1 Κλάσεις Λογικής Συστήματος

8.1.1 Κλάση Plate import java.util.HashMap; public class Plate private String name; private HashMap<Ingredient, Integer> map = new HashMap<Ingredient, Integer>(); public void setPlateName(String text) name = text; public String getName() return name; public void storeIngredient(Ingredient ingr, int quantity) map.put(ingr, quantity); public boolean isAvailable() for (Ingredient key : map.keySet()) if(!key.checkQuantity(map.get(key))) return false; return true; public void pick() for (Ingredient key : map.keySet()) key.remove(map.get(key)); System.out.println("removed from " + key.getName() + " : " + map.get(key) + "grams");

136

Η κλάση Plate έχει ως μοναδική ιδιότητα το όνομα (name) του κάθε

πιάτου. Με την ιδιότητά αυτή σχετίζονται οι μέθοδοι setPlateName()



και getName() που θέτουν τιμή στην ιδιότητα και επιστρέφουν την τιμή

της αντίστοιχα. Η σχέση περιεκτικότητας με την κλάση Συστατικό

υλοποιείται με τη χρήση ενός χάρτη κατακερματισμού (HashMap). Ο

λόγος είναι ότι για κάθε Πιάτο δεν θέλουμε να γνωρίζουμε μόνο τα

συστατικά που περιλαμβάνει αλλά για κάθε συστατικό να γνωρίζουμε και

την ποσότητά που απαιτείται. Η κλάση HashMap αποτελεί μια δομή

δεδομένων που περιλαμβάνει ζεύγη κλειδιών και δεδομένων. Και τα

κλειδιά και τα δεδομένα μπορούν να είναι αυθαίρετα αντικείμενα. Ένα

συγκεκριμένο κλειδί μπορεί μόνο μία φορά να αποτελέσει στοιχείο της

δομής και μπορεί να συνδεθεί με μόνο μία τιμή. Στην προκειμένη

περίπτωση το κλειδιά είναι αντικείμενα της κλάσης Συστατικό ενώ ως

τιμή αντιστοιχίζεται σε κάθε κλειδί ένας ακέραιος που υποδηλώνει την

ποσότητα του συστατικού που απαιτείται για το συγκεκριμένο πιάτο.

Η μέθοδος storeIngredient() επιτρέπει την καταχώρηση ενός

συστατικού και της ποσότητάς του στο Πιάτο (για το λόγο αυτό λαμβάνει

ένα αντικείμενο Ingredient και έναν ακέραιο ως παραμέτρους). Στο σώμα

της μεθόδου καλείται η μέθοδος put() της κλάσης HashMap που εισάγει

ένα ζεύγος κλειδιού-τιμής στη δομή δεδομένων.

137

Η κατηγορηματική μέθοδος isAvailable() ελέγχει τη

διαθεσιμότητα του πιάτου και επιστρέφει την τιμή true εάν και μόνον αν

όλα τα συστατικά του πιάτου είναι διαθέσιμα. Στο σώμα της "σαρώνει" το

χάρτη κατακερματισμού των συστατικών και για κάθε στοιχείο ελέγχεται

η διαθεσιμότητα της απαιτούμενης ποσότητας, καλώντας τη μέθοδο



checkQuantity() κάθε συστατικού και περνώντας στη μέθοδο ως

όρισμα το κλειδί που αντιστοιχεί στο εξεταζόμενο συστατικό (αφού

αντιπροσωπεύει την ποσότητα που απαιτείται για την παρασκευή του

πιάτου).

Τέλος, η μέθοδος pick() καλείται όταν ένα πιάτο επιλέγεται από το

μάγειρα που δηλώνει κατ' αυτόν τον τρόπο την ολοκλήρωση της

ετοιμασίας του. Στην περίπτωση αυτή "σαρώνεται" πάλι ο χάρτης

κατακερματισμού των συστατικών και για κάθε κλειδί-συστατικό

αφαιρείται η τιμή-ποσότητα που αντιστοιχεί στο κλειδί.



8.1.2 Κλάση Ingredient public class Ingredient private String name; private int amount; public Ingredient(String text, int num) name = text; amount = num; public boolean checkQuantity(int quantity) if(quantity <= amount) return true; else return false; public boolean remove(int quantity) if(checkQuantity(quantity)) amount = amount - quantity; return true; else return false; public String getName() return name;

139

Η κλάση Ingredient έχει ως ιδιότητες το όνομα (name) και την ποσότητα

(amount) που αντιστοιχεί στο απόθεμα κάθε συστατικού. Καθώς τα

συστατικά είναι τα μόνα αντικείμενα που δημιουργούνται στη μέθοδο

main() του συστήματος, παρέχεται ένας κατασκευαστής που λαμβάνει

ως παραμέτρους ένα αλφαριθμητικό και έναν ακέραιο για το όνομα και

την ποσότητα αντίστοιχα.



Η κατηγορηματική μέθοδος checkQuantity() ελέγχει την επάρκεια

μιας ποσότητας για το συγκεκριμένο συστατικό και λαμβάνει ως

παράμετρο την ποσότητα που πρέπει να ελεγχθεί. Η μέθοδος επιστρέφει

true εάν και μόνο αν η ποσότητα που ζητείται είναι μικρότερη ή ίση με

την τρέχουσα τιμή του αποθέματος.

Η κατηγορηματική μέθοδος remove() λαμβάνει ως παράμετρο την

ποσότητα που πρέπει να αφαιρεθεί από το απόθεμα του συστατικού. Η

ποσότητα αφαιρείται από το απόθεμα εάν και μόνο αν το απόθεμα που

απομένει είναι μεγαλύτερο του μηδενός (ο έλεγχος πραγματοποιείται με

κλήση της μεθόδου checkQuantity()). Στην περίπτωση αυτή η

μέθοδος επιστρέφει true. Σε αντίθετη περίπτωση το απόθεμα δεν επαρκεί

και επιστρέφεται false.



8.1.3 Κλάση Order import java.util.ArrayList; public class Order private int code; private ArrayList<Plate> plates = new ArrayList<Plate>(); public Order(int ID) code = ID; public int getCode() return code; public void pickPlate(String plateName) Plate pickedPlate = plates.get(0); for(int i=0; i<plates.size(); i++) if(plateName == plates.get(i).getName()) pickedPlate = plates.get(i); break; pickedPlate.pick(); public void addPlate(Plate aPlate) plates.add(aPlate); public ArrayList<Plate> getPlates() return plates; public int getNumberOfPlates() return plates.size();

141

Η κλάση Order έχει ως μοναδική ιδιότητα τον κωδικό της παραγγελίας

(code), ο οποίος επιστρέφεται από τη μέθοδο getCode(). Η

συναρμολόγηση με την κλάση Plate υλοποιείται ως λίστα πίνακα



(ArrayList). Αξιοποιείται η δυνατότητα των generics και δηλώνεται ο

τύπος δεδομένων των στοιχείων που πρόκειται να δεχθεί η δομή

δεδομένων ώστε να μην απαιτείται η μετατροπή τύπων κατά την εξαγωγή

στοιχείων. Η μέθοδος addPlate() επιτρέπει την προσθήκη ενός

αντικειμένου τύπου Plate στη λίστα πίνακα. Η μέθοδος getPlates()

επιστρέφει ολόκληρη τη λίστα πίνακα (τα πιάτα μιας παραγγελίας). Ο

κατασκευαστής της κλάσης παρέχεται καθώς καλείται από την κλάση που

αναλαμβάνει τη δημιουργία και το χειρισμό της οθόνης "Προσθήκη

Παραγγελίας".

Η μέθοδος επιλογής Πιάτου (pickPlate()) που προστέθηκε λόγω

της τρίτης περίπτωσης χρήσης και των συναφών διαγραμμάτων ευρωστίας

και ακολουθίας, λαμβάνει ως παράμετρο το όνομα (ως αλφαριθμητικό)

ενός πιάτου που έχει επιλεχθεί για ετοιμασία. Στο σώμα της μεθόδου μια

επαναληπτική δομή διατρέχει τη λίστα πίνακα που περιλαμβάνει τα πιάτα

της παραγγελίας και αποστέλλει το μήνυμα pick() στο αντικείμενο του

οποίου το όνομα ταυτίζεται με το ζητούμενο.

Η μέθοδος getNumberOfPlates() επιστρέφει το πλήθος των πιάτων

που περιλαμβάνει η παραγγελία (παρέχεται από τη μέθοδο size() της

λίστας πίνακα). Η μέθοδος χρησιμοποιείται κατά τον υπολογισμό του

υπολειπόμενου χρόνου μέχρι να ετοιμαστεί κάποια παραγγελία.



8.1.4 Κλάση Queue import java.util.LinkedList; import java.util.ArrayList; public class Queue private static LinkedList<Order> ordersWaiting = new LinkedList<Order>(); public static void add(Order order) ordersWaiting.add(order); public static Order getFirstOrder() if(ordersWaiting.size() > 0) return ordersWaiting.getFirst(); else return null; public static void removeFirst() ordersWaiting.removeFirst(); public static ArrayList<String> getOrderCodes() ArrayList<String> orderIDs = new ArrayList<String>(); for(Order o: ordersWaiting) int orderID = o.getCode(); orderIDs.add(Integer.toString(orderID)); return orderIDs; public static int calculateTime(int ID) int platesWaiting = 0; int timeInSecs = 0; int positionInQueue = findPosition(ID); platesWaiting = calculatePlatesWaiting(positionInQueue); timeInSecs = platesWaiting * 2; return timeInSecs;

143



144

private static int findPosition(int id) int positionInQueue = 0; for(Order o: ordersWaiting) if(id == o.getCode()) positionInQueue = ordersWaiting.indexOf(o); break; return positionInQueue; private static int calculatePlatesWaiting(int position) int plates = 0; for(int i=position; i>=0; i--) plates += ordersWaiting.get(i).getNumberOfPlates(); return plates;

Η κλάση Queue έχει ως μοναδική (στατική) ιδιότητα την

ordersWaiting τύπου συνδεδεμένης λίστας (LinkedList). Η ιδιότητα

περιλαμβάνει μια λίστα από αναφορές προς τα αντικείμενα της κλάσης

Order που αναμένουν την ετοιμασία τους από τον Μάγειρα. Οι μέθοδοι

addOrder() και removeFirst() προσθέτουν ένα αντικείμενο

παραγγελίας στη λίστα και απομακρύνουν την πρώτη παραγγελία από τη

λίστα αντίστοιχα, καλώντας τις μεθόδους add() και removeFirst()

της κλάσης LinkedList. Η μέθοδος getFirstOrder() ελέγχει το

μέγεθος της λίστας παραγγελιών. Αν είναι μεγαλύτερο του μηδενός

επιστρέφει την πρώτη παραγγελία, αλλιώς επιστρέφει τη μηδενική

αναφορά (null).

Η μέθοδος getOrderCodes() διατρέχει τη λίστα των παραγγελιών,

εισάγει τον κωδικό κάθε παραγγελίας σε μια δομή τύπου



ArrayList<String> και επιστρέφει τη δομή αυτή στην οθόνη

υπολογισμού χρόνου από όπου καλείται.

Η μέθοδος findPosition() λαμβάνει ως παράμετρο τον κωδικό

μιας παραγγελίας και επιστρέφει τη θέση της παραγγελίας στη λίστα των

παραγγελιών. Αυτό επιτυγχάνεται διατρέχοντας τη λίστα των

παραγγελιών και για την παραγγελία της οποίας ο κωδικός ταυτίζεται με

τον ζητούμενο, η θέση υπολογίζεται από τη μέθοδο indexOf() της

κλάσης LinkedList.

Η μέθοδος calculatePlatesWaiting() λαμβάνει ως παράμετρο

τη θέση μιας παραγγελίας και επιστρέφει το πλήθος των πιάτων που

περιλαμβάνουν οι παραγγελίες που βρίσκονται "μπροστά" από την εν

λόγω παραγγελία. Το πλήθος υπολογίζεται διατρέχοντας τη λίστα από τη

θέση που δόθηκε ως όρισμα μέχρι τη θέση 0 και λαμβάνοντας από κάθε

παραγγελία τον αριθμό των πιάτων που περιλαμβάνει καλώντας τη

μέθοδο getNumberOfPlates().

145

Η μέθοδος calculateTime() λαμβάνει ως παράμετρο τον κωδικό

μιας παραγγελίας και επιστρέφει το χρόνο που υπολείπεται μέχρι να

ετοιμαστεί η παραγγελία. Ο χρόνος υπολογίζεται εντοπίζοντας τη θέση

της παραγγελίας στη λίστα (καλώντας τη μέθοδο findPosition()),

λαμβάνοντας το πλήθος των πιάτων που περιλαμβάνουν οι προηγούμενες

παραγγελίες (καλώντας τη μέθοδο calculatePlatesWaiting()) και

τέλος πολλαπλασιάζοντας το πλήθος των πιάτων επί 2, αφού εξ' αρχής

έγινε η υπόθεση ότι ο μέσος χρόνος ετοιμασίας κάθε πιάτου είναι 2 λεπτά.



8.1.5 Κλάση PlateCatalog import java.util.ArrayList; public class PlateCatalog private static ArrayList<Plate> plates = new ArrayList<Plate>(); public static void add(Plate plate) plates.add(plate); public static Plate getPlate(String name) for(int i=0; i<plates.size(); i++) if(name.equals((plates.get(i)).getName())) return plates.get(i); return null; public static ArrayList<String> getPlateNames() ArrayList names = new ArrayList(); for(int i=0; i<plates.size(); i++) names.add((plates.get(i)).getName()); return names;

Όπως ήδη αναφέρθηκε η κλάση PlateCatalog και η κλάση

IngredientCatalog περιλαμβάνουν στατικές μεθόδους ώστε να μπορούν

να κληθούν από όλα τα αντικείμενα του συστήματος χωρίς να απαιτείται

η ύπαρξη αναφοράς προς συγκεκριμένα αντικείμενα των κλάσεων αυτών.

Οι εξαρτήσεις αυτές (μεταξύ των κλάσεων του συστήματος και των

κλάσεων PlateCatalog και IngredientCatalog) δεν απεικονίζονται στο

διάγραμμα κλάσεων του σχήματος 8.1 χάριν απλότητας.

Η κλάση PlateCatalog υλοποιεί τη συναρμολόγηση προς την κλάση

Plate με μια στατική λίστα πίνακα (plates) που δηλώνεται ρητά ότι



περιλαμβάνει αντικείμενα τύπου Plate. Η στατική μέθοδος addPlate()

επιτρέπει την εισαγωγή ενός πιάτου στη λίστα πίνακα. Η στατική μέθοδος

getPlate() λαμβάνει ως παράμετρο το όνομα ενός πιάτου και

επιστρέφει αναφορά προς το αντίστοιχο αντικείμενο. Καλείται δε από την

κλάση που χειρίζεται την οθόνη "Προσθήκη Παραγγελίας" όπου ο

χρήστης έχει στη διάθεσή του μια λίστα με τα ονόματα των πιάτων. Η

στατική μέθοδος getPlateNames() επιστρέφει μια λίστα πίνακα που

περιλαμβάνει (ως αλφαριθμητικά) όλα τα ονόματα των πιάτων του

καταλόγου. Και αυτή η μέθοδος καλείται από την κλάση που χειρίζεται

την οθόνη "Προσθήκη Παραγγελίας" για να εμφανίσει τα ονόματα όλων

των πιάτων.




8.1.6 Κλάση IngredientCatalog public class IngredientCatalog private static ArrayList<Ingredient> ingredients = new ArrayList(); public static void add(Ingredient i) ingredients.add(i); public static Ingredient getIngredient(String name) for(int i=0; i<ingredients.size(); i++) if(name.equals((ingredients.get(i)).getName())) return ingredients.get(i); return null; public static ArrayList<String> getIngredientNames() ArrayList names = new ArrayList(); for(int i=0; i<ingredients.size(); i++) names.add((ingredients.get(i)).getName()); return names; Η κλάση IngredientCatalog υλοποιεί τη συναρμολόγηση προς την κλάση

Ingredient με μια στατική ιδιότητα ingredients τύπου λίστα πίνακα

(ArrayList<Ingredient>). Η στατική μέθοδος add() επιτρέπει την

προσθήκη ενός συστατικού στη λίστα πίνακα. Η στατική μέθοδος

getIngredient() λαμβάνει ως παράμετρο το όνομα ενός συστατικού

και αν αυτό υπάρχει επιστρέφει την αναφορά προς το συστατικό αυτό. Η

μέθοδος καλείται από την οθόνη που χειρίζεται τη δημιουργία ενός πιάτου

για την καταχώρηση ενός συστατικού (το οποίο είναι γνωστό με το όνομά

του) σε ένα πιάτο. Τέλος η στατική μέθοδος getIngredientNames()

επιστρέφει μια λίστα πίνακα από αλφαριθμητικά που περιλαμβάνει τα

ονόματα όλων των συστατικών του καταλόγου. Η μέθοδος καλείται για


την εμφάνιση στην οθόνη "Δημιουργία Πιάτου" των συστατικών του

συστήματος.

Αξίζει να σημειωθεί ότι η εφαρμογή αντίστροφης μηχανικής (reverse

engineering) στον κώδικα που παρουσιάζεται στις προηγούμενες ενότητες

για τις κλάσεις του συστήματος, οδηγεί χωρίς καμία απολύτως

διαφοροποίηση, στο διάγραμμα κλάσεων που προέκυψε από την ανάλυση

και σχεδίαση σύμφωνα με τη μεθοδολογία ICONIX, όπως αυτό

αποτυπώνεται στο σχήμα 6.8.



8.2 Δημιουργία μιας απλής γραφικής διασύνδεσης χρήστη

8.2.1 Δημιουργία παραθύρων

Η δημιουργία γραφικής διασύνδεσης χρήστη, στην απλούστερη εκδοχή

της, περιλαμβάνει την εμφάνιση γραφικών στην οθόνη (παραθύρου,

κειμένου, εικόνων) και στοιχείων με τα οποία μπορεί να αλληλεπιδράσει ο

χρήστης (πλήκτρα, μενού, πεδία κειμένου) καθώς και το χειρισμό των

συμβάντων που προκαλούνται από τις ενέργειες του χρήστη (π.χ. πάτημα

ενός πλήκτρου, μετακίνηση της δεικτικής συσκευής).

Η δημιουργία εφαρμογής που περιλαμβάνει γραφική διασύνδεση

χρήστη μπορεί να απλοποιηθεί αξιοποιώντας τη βιβλιοθήκη Swing είτε τη

βιβλιοθήκη AWT (Abstract Windowing Toolkit) της Java. Ωστόσο, η

βιβλιοθήκη Swing είναι νεότερη και είναι καλό να προτιμάται. Όλα τα

γραφικά συστατικά που εμφανίζονται σε μια γραφική διασύνδεση έχουν

ως κοινή υπερκλάση την κλάση javax.swing.JComponent ή την

java.awt.Component, για τις βιβλιοθήκες swing και awt αντίστοιχα.

Λόγω του πλήθους των διαθέσιμων κλάσεων στις βιβλιοθήκες αυτές, ο

ενδιαφερόμενος αναγνώστης μπορεί να βρει την πλήρη τεκμηρίωση στις

σελίδες της Java (http://java.sun.com).

Η γραφική διασύνδεση του συστήματος διαχείρισης παραγγελιών

βασίζεται σε οθόνες που στη Java υλοποιούνται ως παράθυρα. Ο

ευκολότερος τρόπος για την υλοποίηση ενός παραθύρου είναι η

δημιουργία ενός αντικειμένου της κλάσης JFrame. Ωστόσο, επειδή σε

κάθε παράθυρο επιθυμούμε να τοποθετήσουμε διαφορετικά συστατικά, η


http://java.sun.com/


προσέγγιση που ακολουθείται είναι η δημιουργία υποκλάσεων της

JFrame, μιας για κάθε οθόνη της εφαρμογής. Η εμφάνιση ενός

παραθύρου απαιτεί την κλήση του κατασκευαστή του (π.χ. από τη main).

Στον ίδιο τον κατασκευαστή της κλάσης που υλοποιεί το παράθυρο

προσθέτουμε την κλήση των εξής μεθόδων:

- της μεθόδου setSize() με όρισμα το επιθυμητό μέγεθος του

παραθύρου (σε pixels),

- της μεθόδου setTitle() για τον καθορισμό του τίτλου του

παραθύρου,

- της μεθόδου setVisible() με όρισμα true για την εμφάνιση

του παραθύρου

- της μεθόδου setDefaultCloseOperation() με όρισμα τη

σταθερά JFrame.EXIT_ON_CLOSE έτσι ώστε με την επιλογή του

συμβόλου "X" στο άνω δεξί τμήμα του παραθύρου, το παράθυρο

να κλείνει

Στο ακόλουθο δείγμα κώδικα παρουσιάζεται η κλάση MainFrame που

υλοποιεί το απλό παράθυρο που παρουσιάζεται στο σχήμα 8.2.

151



152

import javax.swing.JFrame; public class MainFrame extends JFrame public MainFrame() this.setSize(200, 200); this.setTitle("Κύρια Οθόνη Συστήματος Διαχείρισης Παραγγελιών"); this.setVisible(true); this.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);

Σχήμα 8.2: Παράθυρο με χρήση της JFrame

8.2.2 Εισαγωγή γραφικών συστατικών

Κάθε παράθυρο – αντικείμενο κλάσης που κληρονομεί την JFrame

περιέχει έναν υποδοχέα (αντικείμενο της κλάσης Container) επί του

οποίου μπορούν να τοποθετηθούν γραφικά συστατικά. Η προσέγγιση που

χρησιμοποιήθηκε στην παρούσα μελέτη είναι η δημιουργία ενός

ξεχωριστού πάνελ (αντικειμένου της κλάσης JPanel επί του οποίο επίσης

μπορούν να τοποθετηθούν γραφικά συστατικά) και η τοποθέτηση του




πάνελ στον υποδοχέα του παραθύρου με την εντολή

this.setContentPane(panel) στον κατασκευαστή κάθε

παραθύρου.

Εστιάζοντας για παράδειγμα στην Κύρια Οθόνη της εφαρμογής, τα

συστατικά που επιθυμούμε να προσθέσουμε είναι πλήκτρα, στοιχεία που

υλοποιούνται ως αντικείμενα της κλάσης JButton. Τα πλήκτρα

δηλώνονται ως ιδιότητες της κλάσης MainFrame και δημιουργούνται

στιγμιότυπά τους στον κατασκευαστή. Μετά τη δημιουργία των πλήκτρων

(και την εισαγωγή του κειμένου που εμφανίζεται σε αυτά ως όρισμα

στους κατασκευαστές τους), τα πλήκτρα τοποθετούνται στο πάνελ με

χρήση της μεθόδου add() (το πάνελ με τη σειρά του έχει τοποθετηθεί

στον υποδοχέα του παραθύρου) και με τον τρόπο αυτό εμφανίζονται στην

οθόνη. Το ακόλουθο τμήμα κώδικα παράγει το παράθυρο που φαίνεται

στο σχήμα 8.3. import javax.swing.*; public class MainFrame extends JFrame //δήλωση πλήκτρων ως ιδιότητες private JButton createPlateButton; private JButton addOrderButton; private JButton prepareOrderButton; private JButton calculateTimeButton; private JPanel panel; public MainFrame() //δημιουργία πλήκτρων createPlateButton = new JButton("Δημιουργία Πιάτου"); addOrderButton = new JButton("Προσθήκη Παραγγελίας"); prepareOrderButton = new JButton("Ετοιμασία Παραγγελίας"); calculateTimeButton = new JButton("Υπολογισμός Χρόνου");


154

//δημιουργία πάνελ panel = new JPanel(); //προσθήκη πλήκτρων στο πάνελ panel.add(createPlateButton); panel.add(addOrderButton); panel.add(prepareOrderButton); panel.add(calculateTimeButton); //τοποθέτηση πάνελ στον υποδοχέα του παραθύρου this.setContentPane(panel); this.setSize(500, 200); this.setTitle("Κύρια Οθόνη Συστήματος Διαχείρισης Παραγγελιών"); this.setVisible(true); this.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);

Σχήμα 8.3: Παράθυρο με αντικείμενα της κλάσης JButton



Στο παράθυρο είναι επίσης δυνατό να προστεθεί μια εικόνα που υπάρχει

ήδη ως αρχείο GIF ή JPEG ως εξής: ImageIcon image = new ImageIcon("cook.gif"); JLabel imageLabel = new JLabel(image);

Η πρώτη εντολή δημιουργεί ένα αντικείμενο της κλάσης ImageIcon – μια

εικόνα από ένα αρχείο εικόνας GIF. Η δεύτερη εντολή εμφανίζει την

εικόνα προσαρτώντας την σε μία ετικέτα – αντικείμενο της κλάσης

JLabel. Η τοποθέτηση του αντικειμένου imageLabel σε ένα παράθυρο

θα έχει ως αποτέλεσμα την εμφάνιση της εικόνας στο παράθυρο.

Η διάταξη της θέσης των διαφόρων γραφικών συστατικών που

τοποθετούνται σε ένα παράθυρο είναι δυνατόν να ελεγχθεί με χρήση

κατάλληλων διαχειριστών διάταξης. Οι διαχειριστές διάταξης είναι

αντικείμενα κλάσεων της βιβλιοθήκης AWT που μπορούν να ελέγξουν

την διάταξη των στοιχείων σε οποιαδήποτε κλάση-υποδοχέα συστατικών.

Για παράδειγμα, ο καθορισμός της χρήσης ενός αντικειμένου

BorderLayout στην κατασκευή ενός αντικειμένου JPanel, όπως φαίνεται

στην ακόλουθη εντολή: JPanel panel = new JPanel(new BorderLayout());

επιτρέπει να ορίζουμε τη θέση ενός συστατικού που προστίθεται στο

αντικείμενο panel με βάση τις σταθερές BorderLayout.NORTH

(βόρεια), BorderLayout.SOUTH (νότια), BorderLayout.EAST

(ανατολικά), BorderLayout.WEST (δυτικά), BorderLayout.CENTER

(κεντρικά). Όπως γίνεται φανερό, αυτός ο διαχειριστής διάταξης παρέχει



περιορισμένες δυνατότητες για έλεγχο της θέσης. Ωστόσο, υπάρχουν

διάφοροι διαχειριστές διάταξης, όπως ο FlowLayout , GridLayout,

GridBagLayout κλπ). Ο συνδυασμός πολλών πάνελ με διαφορετικούς

διαχειριστές διάταξης επιτρέπει την απεικόνιση οποιαδήποτε γραφικής

δομής συστατικών επιθυμεί ο προγραμματιστής.

8.2.3 Χειρισμός συμβάντων

Πέρα από την εμφάνιση γραφικών συστατικών στην οθόνη, αυτό που

είναι σημαντικό σε μια εφαρμογή που αλληλεπιδρά με το χρήστη είναι η

απόκριση στις ενέργειες του χρήστη, τεχνική που είναι γνωστή ως

προγραμματισμός οδηγούμενος από συμβάντα (event-driven

programming). Ο χειρισμός των συμβάντων που προκαλούνται από το

χρήστη απαιτεί τη στοιχειώδη γνώση της διαδικασίας που λαμβάνει χώρα

όταν ο χρήστης πατήσει κάποιο πλήκτρο, ή κάποιο άλλο στοιχείο που

αναμένεται να προκαλέσει κάποια ενέργεια στο εκτελούμενο πρόγραμμα.

Για παράδειγμα, όταν ο χρήστης πατήσει κάποιο πλήκτρο ή μετακινήσει

τη δεικτική συσκευή, ο διαχειριστής παραθύρων της Java (Java Window

Manager) αποστέλλει ειδοποίηση στο πρόγραμμα ότι ένα συμβάν έχει

λάβει χώρα. Στη γενική περίπτωση, ο διαχειριστής παραθύρων παράγει

ένα τεράστιο αριθμό συμβάντων. Ωστόσο, κάθε εφαρμογή δεν

ενδιαφέρεται για όλα τα συμβάντα που λαμβάνουν χώρα. Για το λόγο

αυτό κάθε πρόγραμμα το οποίο πρόκειται να αλληλεπιδρά με το χρήστη,

οφείλει να δηλώνει ρητά ποια συμβάντα ενδιαφέρεται να δεχθεί. Αυτό



επιτυγχάνεται με τη χρήση αντικειμένων που λειτουργούν ως "ακροατές"

για συγκεκριμένους τύπους συμβάντων. Οι ακροατές συνδέονται με

συγκεκριμένα γραφικά συστατικά και "ακροώνται" συγκεκριμένους

τύπους συμβάντων. Μόλις λάβει χώρα το αντίστοιχο συμβάν, ο ακροατής

ενεργοποιείται και εκτελείται ο επιθυμητός κώδικας. Η φιλοσοφίας αυτής

της διαδικασίας παρουσιάζεται στο ακόλουθο σχήμα:

Σχήμα 8.4: Ακρόαση συμβάντων στη Java

Οι ακροατές συμβάντων είναι κλάσεις που υλοποιούν συγκεκριμένες

διασυνδέσεις, ανάλογα με το είδος των συμβάντων που πρόκειται να

χειριστούν. Για παράδειγμα, μια κλάση- ακροατής για συμβάντα που

προκαλούνται από το πάτημα ενός πλήκτρου πρέπει να υλοποιεί τη



διασύνδεση ActionListener. Η διασύνδεση, που αποτελεί τμήμα της

βιβλιοθήκης java.awt.event είναι η εξής: public interface ActionListener

void actionPerformed(ActionEvent event);

Η διασύνδεση περιλαμβάνει μόνο μία μέθοδο, την actionPerformed()

που λαμβάνει ως παράμετρο ένα αντικείμενο τύπου ActionEvent. Το

αντικείμενο αυτό (παρέχεται από τον διαχειριστή παραθύρων της Java)

περιέχει πληροφορίες για το ίδιο το συμβάν, όπως για παράδειγμα το ποιο

πλήκτρο πατήθηκε.

Σε περίπτωση που κάποιο πρόγραμμα ενδιαφέρεται για τέτοιου τύπου

συμβάντα, οφείλει να δημιουργήσει μια κλάση που υλοποιεί τη

διασύνδεση ActionListener. Στην υλοποίηση των μεθόδων της

διασύνδεσης (στην προκειμένη περίπτωση στην υλοποίηση της μεθόδου

actionPerformed()) τοποθετείται ο κώδικας που θέλουμε να

εκτελείται όταν λαμβάνει χώρα το συμβάν. Στη συνέχεια οφείλει να

δημιουργήσει έναν ακροατή, υλοποιώντας ένα αντικείμενο της κλάσης

αυτής.

Τέλος, για την εγκατάσταση του ακροατή στο πρόγραμμα απαιτείται η

σύνδεσή του με την πηγή του συμβάντος. Πηγή ενός συμβάντος είναι το

συστατικό της γραφικής διασύνδεσης (στην προκειμένη περίπτωση ένα

πλήκτρο) που μπορεί να παράγει ένα σχετικό συμβάν. Με αυτή τη

δυνατότητα, ένας ακροατής μπορεί να συνδεθεί με πολλές πηγές



συμβάντων ή κάθε πηγή μπορεί να έχει διαφορετικό ακροατή. Η σειρά

των ενεργειών που απαιτείται προγραμματιστικά ώστε ένα πρόγραμμα να

έχει τη δυνατότητα χειρισμού συμβάντων απεικονίζεται γραφικά στο

ακόλουθο σχήμα.

159

Σχήμα 8.5: Ακολουθία ενεργειών για τον χειρισμό συμβάντων

Στο παρακάτω τμήμα κώδικα που αφορά σε μια κλάση MyFrame που

υλοποιεί ένα παράθυρο και περιλαμβάνει ένα πλήκτρο button (όπως

φαίνεται στο δείγμα εκτέλεσης του σχήματος 8.6), έχει δημιουργηθεί μια

κλάση-ακροατής (ButtonListener), έχει υλοποιηθεί ένας ακροατής

listener ως στιγμιότυπο της κλάσης ButtonListener και έχει συνδεθεί

με το πλήκτρο του παραθύρου ώστε να ακροάται συμβάντα που

σχετίζονται με αυτό (μέσω κλήσης της μεθόδου addActionListener()

στο αντικείμενο button. Ο κώδικας που εκτελείται κάθε φορά που ο



χρήστης πατά το πλήκτρο περιλαμβάνεται στη μέθοδο

actionPerformed() της κλάσης ButtonListener.

import javax.swing.*; import java.awt.event.*; public class MyFrame extends JFrame private JButton button; private JPanel panel; public MyFrame() button = new JButton("Press Me"); //υλοποίηση ακροατή ButtonListener listener = new ButtonListener(); //σύνδεση ακροατή με πηγή συμβάντων (πλήκτρο button) button.addActionListener(listener); panel = new JPanel(); panel.add(button); this.setContentPane(panel); this.pack(); this.setTitle("MyFrame"); this.setVisible(true); this.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);



161

//δημιουργία κλάσης ακροατή class ButtonListener implements ActionListener public void actionPerformed(ActionEvent e) JOptionPane.showMessageDialog(null, "Button Pressed");

Σχήμα 8.6: Δείγμα Εκτέλεσης παραθύρου με χειρισμό συμβάντων

Στην περίπτωση που υπάρχουν πολλά πλήκτρα, όπου η επιλογή του

καθενός προκαλεί την εκτέλεση διαφορετικών ενεργειών (όπως για

παράδειγμα στο σύστημα διαχείρισης παραγγελιών) υπάρχουν οι εξής δύο

δυνατότητες: 1) να χρησιμοποιηθούν διαφορετικές κλάσεις-ακροατές για

κάθε πλήκτρο με διαφορετική υλοποίηση της μεθόδου

actionPerformed() σε κάθε μία και 2) να χρησιμοποιηθεί ένας κοινός

ακροατής. Στην περίπτωση αυτή, στο σώμα της μεθόδου



actionPerformed() που καλείται όταν επιλέγεται ένα πλήκτρο, μπορεί

να αξιοποιηθεί η πληροφορία που μεταφέρεται από το ίδιο το συμβάν (η

παράμετρος ActionEvent της μεθόδου) ώστε να διαπιστώνεται ποιο

πλήκτρο ήταν η πηγή του συμβάντος (καλώντας τη μέθοδο

getSource()). Η δεύτερη αυτή δυνατότητα υλοποιήθηκε στις κλάσεις

της γραφικής διασύνδεσης του συστήματος διαχείρισης παραγγελιών.



8.3 Κλάσεις γραφικής διασύνδεσης χρήστη

8.3.1 Κλάση MainFrame import javax.swing.*; import java.awt.event.*; import java.awt.*; public class MainFrame extends JFrame private JButton createPlateButton; private JButton addOrderButton; private JButton prepareOrderButton; private JButton calculateTimeButton; private ImageIcon image; private JLabel imageLabel; private JPanel panel; private JPanel buttonPanel; public MainFrame() createPlateButton = new JButton("Δημιουργία Πιάτου"); addOrderButton = new JButton("Προσθήκη Παραγγελίας"); prepareOrderButton = new JButton("Ετοιμασία Παραγγελίας"); calculateTimeButton = new JButton("Υπολογισμός Χρόνου"); image = new ImageIcon("cook.gif"); imageLabel = new JLabel(image); panel = new JPanel(new BorderLayout()); buttonPanel = new JPanel(); panel.add(imageLabel, BorderLayout.NORTH); buttonPanel.add(createPlateButton); buttonPanel.add(addOrderButton); buttonPanel.add(prepareOrderButton); buttonPanel.add(calculateTimeButton); panel.add(buttonPanel, BorderLayout.CENTER);

163



164

ButtonListener buttonListener = new ButtonListener(); createPlateButton.addActionListener(buttonListener); addOrderButton.addActionListener(buttonListener); prepareOrderButton.addActionListener(buttonListener); calculateTimeButton.addActionListener(buttonListener); this.setContentPane(panel); this.pack(); this.setTitle("Κύρια Οθόνη Συστήματος Διαχείρισης Παραγγελιών"); this.setVisible(true); this.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); class ButtonListener implements ActionListener public void actionPerformed(ActionEvent e) if (e.getSource() == createPlateButton) new CreatePlateFrame(); if (e.getSource() == addOrderButton) new AddOrderFrame(); if (e.getSource() == prepareOrderButton) new PrepareOrderFrame(); if (e.getSource() == calculateTimeButton) new CalculateTimeFrame();

Στιγμιότυπο της κλάσης MainFrame δημιουργείται στη μέθοδο main()

του προγράμματος για την εμφάνιση της Κύριας Οθόνης του συστήματος.

Κάθε αντικείμενο της κλάσης υλοποιεί ένα παράθυρο καθώς η κλάση

κληρονομεί την JFrame. Το παράθυρο περιλαμβάνει μια εικόνα και



τέσσερα πλήκτρα που αντιστοιχούν στις επιλογές του χρήστη. Το

παράθυρο φαίνεται στο ακόλουθο σχήμα:

Σχήμα 8.7: Κύρια Οθόνη Συστήματος

Το παράθυρο περιλαμβάνει δύο πάνελ (panel και buttonPanel), με το

δεύτερο να περιλαμβάνει τα τέσσερα πλήκτρα (createPlateButton,

addOrderButton, prepareOrderButton και

calculateTimeButton) και να βρίσκεται εμφωλευμένο μέσα στο

πρώτο panel όπως φαίνεται στο σχήμα 8.8.



Σχήμα 8.8: Διάταξη των panel στην κύρια οθόνη

Στη συγκεκριμένη οθόνη, ο διαχειριστής διάταξης του περικλείοντος

panel τίθεται ρητά ως BorderLayout κατά την κλήση του κατασκευαστή

της κλάσης JPanel, ενώ ο διαχειριστής διάταξης για το buttonPanel

παραμένει ο εξ'ορισμού διαχειριστής FlowLayout. Ο διαχειριστής

διάταξης FlowLayout είναι σχετικά απλός: τοποθετεί τα συστατικά σε μία

γραμμή. Αν το μέγεθος της γραμμής δεν επαρκεί, τοποθετεί τα επόμενα

συστατικά σε νέα γραμμή.

Στην κλάση-ακροατή ButtonListener διακρίνονται τέσσερις

περιπτώσεις ανάλογα με την πηγή του συμβάντος (που μπορεί να είναι

ένα από τα τέσσερα πλήκτρα). Η απόκριση στο πάτημα οποιουδήποτε

πλήκτρου είναι η δημιουργία ενός (ανώνυμου) αντικειμένου της κλάσης-

παραθύρου για την αντίστοιχη οθόνη. Το αντικείμενο που δημιουργείται

είναι ανώνυμο υπό την έννοια ότι το δημιουργούμενο αντικείμενο δεν

ανατίθεται σε κάποια αναφορά, καθώς δεν χρειάζεται να προσπελαστεί

από κάποιο άλλο σημείο του προγράμματος.



8.3.2 Κλάση AddOrderFrame import javax.swing.*; import java.awt.*; import java.awt.event.ActionListener; import java.awt.event.ActionEvent; import java.util.ArrayList; public class AddOrderFrame extends JFrame private List platesList, addedPlatesList; private JPanel panel, namePanel, itemsPanel; private JLabel orderID; private JTextArea iD; private JButton addOrderButton, addPlateButton; private Order order; private static int ID = 0; private AddOrderFrame selfReference; public AddOrderFrame() selfReference = this; panel = new JPanel(new BorderLayout()); namePanel = new JPanel(); itemsPanel = new JPanel(); orderID = new JLabel("Κωδικός Παραγγελίας"); platesList = new List(); iD = new JTextArea(1, 20); iD.setText(Integer.toString(ID)); addOrderButton = new JButton("Καταχώρηση Παραγγελίας"); addPlateButton = new JButton("Προσθήκη Πιάτου"); addedPlatesList = new List(); ButtonListener buttonListener = new ButtonListener(); addPlateButton.addActionListener(buttonListener); addOrderButton.addActionListener(buttonListener);

167



168

//Δημιουργία Παραγγελίας order = new Order(ID); ArrayList<String> plateNames = PlateCatalog.getPlateNames(); //Καταχώρηση ονομάτων πιάτων στη λίστα για εμφάνιση for(int i=0; i<plateNames.size(); i++) platesList.add(plateNames.get(i)); namePanel.add(orderID); namePanel.add(iD); itemsPanel.add(platesList); itemsPanel.add(addPlateButton); itemsPanel.add(addedPlatesList); panel.add(namePanel, BorderLayout.NORTH); panel.add(itemsPanel, BorderLayout.CENTER); panel.add(addOrderButton, BorderLayout.SOUTH); this.setContentPane(panel); this.setSize(500,400); this.setTitle("Οθόνη Προσθήκης Παραγγελίας"); this.setVisible(true); this.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE); class ButtonListener implements ActionListener public void actionPerformed(ActionEvent e) if(e.getSource() == addOrderButton) ID++; Queue.add(order); selfReference.setVisible(false); selfReference.dispose();



169

else if(e.getSource() == addPlateButton) String selectedPlateName = platesList.getSelectedItem(); Plate selectedPlate = PlateCatalog.getPlate(selectedPlateName); if(selectedPlate.isAvailable()) addedPlatesList.add(selectedPlateName); order.addPlate(selectedPlate); else JOptionPane.showMessageDialog(null, "Αυτό το πιάτο δεν είναι διαθέσιμο", "Alert", JOptionPane.ERROR_MESSAGE);

Η οθόνη που δημιουργείται από την υλοποίηση στιγμιοτύπων της

κλάσης AddOrderFrame φαίνεται στο σχήμα 8.9.



Σχήμα 8.9: Οθόνη Προσθήκης Παραγγελίας

Ένα από τα σημαντικότερα γραφικά συστατικά σε αυτή την οθόνη

είναι το αντικείμενο της κλάσης List της βιβλιοθήκης java.awt. Μια τέτοια

λίστα επιτρέπει την παρουσίαση στοιχείων (π.χ. αλφαριθμητικών) στο

χρήστη, με μπάρα κύλισης σε περίπτωση που ο χώρος απεικόνισής του

δεν επαρκεί και επιπλέον επιτρέπει την επιλογή στοιχείων από το χρήστη

μέσω δεικτικής συσκευής.

170

Μία λίστα στην ανωτέρω κλάση είναι η ιδιότητα platesList που

περιλαμβάνει τα ονόματα των πιάτων που υπάρχουν καταχωρημένα στο

σύστημα. Μόλις η platesList αρχικοποιηθεί προστίθενται σε αυτήν

επαναληπτικά (καλώντας τη μέθοδο add()) τα ονόματα των πιάτων του



συστήματος. Τα ονόματα των πιάτων βρίσκονται αποθηκευμένα σε μια

δομή ArrayList<String> που έχει επιστραφεί από τη στατική μέθοδο

getPlateNames() της κλάσης PlateCatalog.

Η κλάση περιλαμβάνει μια ιδιότητα ID που αποτελεί τον κωδικό κάθε

παραγγελίας. Στον κατασκευαστή της κλάσης περιλαμβάνεται και η

δημιουργία μιας νέα παραγγελίας με όρισμα την ιδιότητα ID. Η αναφορά

προς τη νέα παραγγελία ανατίθεται στην ιδιότητα order, που υλοποιεί τη

συσχέτιση μεταξύ της κλάσης AddOrderFrame και της κλάσης Order.

Η οθόνη περιλαμβάνει δύο πλήκτρα. Η απόκριση στο πάτημα του

πλήκτρου "Προσθήκη Πιάτου" (addPlateButton) είναι η λήψη του

ονόματος του επιλεγμένου πιάτου, καλώντας τη μέθοδο

getSelectedItem() του αντικειμένου platesList. Στη συνέχεια

εντοπίζεται η αναφορά προς το επιλεγμένο αντικείμενο – πιάτο καλώντας

τη στατική μέθοδο getPlate() του καταλόγου πιάτων. Τέλος,

πραγματοποιείται ο έλεγχος διαθεσιμότητας του πιάτου καλώντας τη

μέθοδο isAvailable(). Εάν το πιάτο είναι διαθέσιμο, η αντίστοιχη

αναφορά προστίθεται στη νέα παραγγελία και το όνομα του πιάτου

καταχωρείται στη δεύτερη λίστα της οθόνης, την addedPlatesList που

εμφανίζει τα ήδη επιλεγμένα πιάτα. Σε περίπτωση που το πιάτο δεν είναι

διαθέσιμο (λόγω ανεπάρκειας των συστατικών του) εμφανίζεται

κατάλληλο μήνυμα.

171

Η απόκριση στο πάτημα του πλήκτρου "Καταχώρηση Παραγγελίας"

(addOrderButton) αυξάνει την τιμή της ιδιότητας ID κατά ένα (ώστε η



επόμενη παραγγελία να έχει τον αμέσως επόμενο κωδικό), καταχωρεί την

παραγγελία στην ουρά καλώντας τη στατική μέθοδο add(), και μέσω

αναφοράς προς το αντικείμενο της κλάσης AddOrderFrame

(selfReference) απελευθερώνει τους πόρους που καταναλώνει το

παράθυρο και το θέτει ως μη ορατό (καλώντας τη μέθοδο dispose()).



8.3.3 Κλάση CreatePlateFrame import javax.swing.*; import java.util.*; import java.awt.*; import java.awt.List; import java.awt.event.ActionListener; import java.awt.event.ActionEvent; public class CreatePlateFrame extends JFrame private CreatePlateFrame selfReference; private List ingredientsList, addedIngredientsList; private JPanel panel, namePanel, ingredientsPanel; private JLabel plateNameText, ingredientQuantityText; private JTextArea plateName, quantity; private JButton storeNameButton, addButton, finishedButton; private Plate plate; public CreatePlateFrame() selfReference = this; panel = new JPanel(new BorderLayout()); namePanel = new JPanel(); ingredientsPanel = new JPanel(); plateNameText = new JLabel("Όνομα Πιάτου"); ingredientQuantityText = new JLabel("Ποσότητα του επιλεγμένου συστατικού (gr)"); ingredientsList = new List(); plateName = new JTextArea(1, 20); quantity = new JTextArea(1,4); storeNameButton = new JButton("Αποθήκευση Ονόματος"); addButton = new JButton("Προσθήκη Συστατικού"); addButton.setEnabled(false); //μη επιλέξιμο πλήκτρο finishedButton = new JButton("ΈΞΟΔΟΣ"); finishedButton.setEnabled(false);//μη επιλέξ. πλήκτρο addedIngredientsList = new List();

173



174

ButtonListener buttonListener=new ButtonListener(); addButton.addActionListener(buttonListener); storeNameButton.addActionListener(buttonListener); finishedButton.addActionListener(buttonListener); ArrayList<String> ingredientNames = IngredientCatalog.getIngredientNames(); for(int i=0; i<ingredientNames.size(); i++) ingredientsList.add(ingredientNames.get(i)); namePanel.add(plateNameText); namePanel.add(plateName); namePanel.add(storeNameButton); ingredientsPanel.add(ingredientsList); ingredientsPanel.add(ingredientQuantityText); ingredientsPanel.add(quantity); ingredientsPanel.add(addButton); ingredientsPanel.add(addedIngredientsList); panel.add(namePanel, BorderLayout.NORTH); panel.add(ingredientsPanel, BorderLayout.CENTER); panel.add(finishedButton, BorderLayout.SOUTH); plate = new Plate(); //δημιουργία πιάτου this.setContentPane(panel); this.setSize(500,400); this.setTitle("Οθόνη Δημιουργίας Πιάτου"); this.setVisible(true); this.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE); class ButtonListener implements ActionListener public void actionPerformed(ActionEvent e) if(e.getSource() == storeNameButton) plate.setPlateName(plateName.getText()); addButton.setEnabled(true); finishedButton.setEnabled(true);



175

else if(e.getSource() == addButton) String ingredientName = ingredientsList.getSelectedItem(); addedIngredientsList.add( ingredientName + ", " + quantity.getText()); plate.storeIngredient( IngredientCatalog.getIngredient(ingredientName), Integer.parseInt(quantity.getText())); else if(e.getSource() == finishedButton) PlateCatalog.add(plate); selfReference.dispose(); Η οθόνη που δημιουργείται από την υλοποίηση στιγμιοτύπων της

κλάσης CreatePlateFrame φαίνεται στο σχήμα 8.10.

Σχήμα 8.10: Οθόνη Δημιουργίας Πιάτου



Η κλάση CreatePlateFrame περιλαμβάνει την ιδιότητα plate, τύπου

Plate, που υλοποιεί τη συσχέτιση μεταξύ της κλάσης και της κλάσης

Πιάτο, όπως φαίνεται στο σχήμα 8.1. Στον κατασκευαστή της κλάσης

δημιουργείται ένα νέο αντικείμενο Plate η τιμή του οποίου ανατίθεται

στην ιδιότητα plate.

Η οθόνη περιλαμβάνει τρία πλήκτρα, το πλήκτρο αποθήκευσης

ονόματος (storeNameButton), το πλήκτρο προσθήκης συστατικού

(addButton) και το πλήκτρο εξόδου (finishedButton). Επειδή δεν

είναι επιθυμητό ο χρήστης να επιλέξει συστατικά ή να τερματίσει την

οθόνη προτού επιλέξει ένα όνομα για το πιάτο που δημιουργείται, μέχρι

το πάτημα του πλήκτρου storeNameButton, τα άλλα δύο πλήκτρα

τίθενται ως μη επιλέξιμα (καλώντας τη μέθοδο setEnabled(false)).

Η απόκριση στο πάτημα του πλήκτρου αποθήκευσης ονόματος είναι η

λήψη του ονόματος του πιάτου από το πεδίο plateName και η

καταχώρηση του ονόματος στο συσχετιζόμενο πιάτο. Επίσης, τίθενται ως

επιλέξιμα τα άλλα δύο πλήκτρα.

176

Η απόκριση στο πάτημα του πλήκτρου προσθήκης συστατικού είναι η

εμφάνιση του ονόματος του επιλεγμένου στοιχείου στη λίστα των

επιλεγμένων συστατικών και κυρίως η καταχώρηση του επιλεγμένου

συστατικού και της ποσότητάς του στο αντίστοιχο πιάτο. Αυτό

επιτυγχάνεται με την κλήση της μεθόδου storeIngredient() στο

αντικείμενο plate. Η μέθοδος λαμβάνει δύο παραμέτρους, την αναφορά

προς το συστατικό και έναν ακέραιο που αντιστοιχεί στην απαιτούμενη



ποσότητα. Η αναφορά λαμβάνεται καλώντας τη μέθοδο

getIngredient() του καταλόγου συστατικών με όρισμα το όνομα του

συστατικού. Η ποσότητα λαμβάνεται από το αλφαριθμητικό που

πληκτρολόγησε ο χρήστης στο αντίστοιχο πεδίο

(quantity.getText()) και μετατρέποντας το σε ακέραιο καλώντας τη

στατική μέθοδο parseInt() της κλάσης Integer.

Η απόκριση στο πάτημα του πλήκτρου εξόδου είναι η προσθήκη του

δημιουργηθέντος πιάτου στον κατάλογο πιάτων

(PlateCatalog.add(plate)) και η απελευθέρωση των πόρων που

καταναλώνει το παράθυρο (selfReference.dispose()).

177



8.3.4 Κλάση CalculateTimeFrame import javax.swing.*; import java.awt.*; import java.awt.event.ActionListener; import java.awt.event.ActionEvent; import java.util.ArrayList; public class CalculateTimeFrame extends JFrame private List ordersInQueue; private JPanel panel; private JButton calculateTimeButton; private ArrayList<String> idsOfWaitingOrders; public CalculateTimeFrame() ordersInQueue = new List(); calculateTimeButton = new JButton("Εκτίμηση Χρόνου για την Επιλεγμένη Παραγγελία"); panel = new JPanel(); ButtonListener buttonListener=new ButtonListener(); calculateTimeButton.addActionListener(buttonListener); //λήψη κωδικών παραγγελιών από την ουρά idsOfWaitingOrders = Queue.getOrderCodes(); //εμφάνιση κωδικών παραγγελιών που βρίσκονται στην ουρά for(int i=0; i<idsOfWaitingOrders.size(); i++) ordersInQueue.add(idsOfWaitingOrders.get(i)); panel.add(ordersInQueue, BorderLayout.NORTH); panel.add(calculateTimeButton, BorderLayout.CENTER); this.setContentPane(panel); this.setSize(500,400); this.setTitle("Οθόνη Υπολογισμού Χρόνου");

178

this.setVisible(true);



179

this.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE); class ButtonListener implements ActionListener public void actionPerformed(ActionEvent e) String sel = ordersInQueue.getSelectedItem(); int selectedID = Integer.parseInt(sel); int timeInSecs; timeInSecs = Queue.calculateTime(selectedID); String text = "Εκτιμώμενος χρόνος: " + timeInSecs; JOptionPane.showMessageDialog(null, text, "Εκτιμώμενος Χρόνος", JOptionPane.INFORMATION_MESSAGE);


κλάσης CalculateTimeFrame φαίνεται στο σχήμα 8.11.

Σχήμα 8.11: Οθόνη Υπολογισμού Χρόνου



Η κλάση λαμβάνει στον κατασκευαστή της από την κλάση Queue τη

λίστα των κωδικών όλων των παραγγελιών που αναμένουν την ετοιμασία

τους (idsOfWaitingOrders = Queue.getOrderCodes()). Οι

κωδικοί εμφανίζονται στο συστατικό λίστας της οθόνης

(ordersInQueue) διατρέχοντας τη δομή idsOfWaitingOrders. Η

απόκριση στο πάτημα του (μοναδικού) πλήκτρου

calculateTimeButton είναι η λήψη του επιλεγμένου κωδικού

παραγγελίας από τη λίστα και η μετατροπή του σε ακέραιο. Η τιμή

μεταβιβάζεται ως όρισμα κατά την κλήση της μεθόδου

calculateTime() της κλάσης Queue, η οποία και επιστρέφει τον

εκτιμώμενο χρόνο. Τέλος, το αποτέλεσμα εμφανίζεται σε πλαίσιο

διαλόγου καλώντας τη μέθοδο JOptionPane.showMessageDialog().



8.3.5 Κλάση PrepareOrderFrame import javax.swing.*; import java.awt.*; import java.awt.event.ActionListener; import java.awt.event.ActionEvent; import java.util.ArrayList; public class PrepareOrderFrame extends JFrame private Order firstOrder; private ArrayList<Plate> platesToPrepare; private List plateNamesToPrepare; private JPanel panel, buttonPanel; private JButton preparedButton, finishButton; private PrepareOrderFrame selfReference; public PrepareOrderFrame() selfReference = this; preparedButton = new JButton("Ολοκλήρωση Ετοιμασίας Πιάτου"); finishButton = new JButton("ΕΞΟΔΟΣ"); panel = new JPanel(new BorderLayout()); buttonPanel = new JPanel(); plateNamesToPrepare = new List(); //λήψη πρώτης παραγγελίας από την Ουρά firstOrder = Queue.getFirstOrder(); if(firstOrder != null) platesToPrepare = firstOrder.getPlates(); for(int i=0; i<platesToPrepare.size(); i++) Plate selection = platesToPrepare.get(i); plateNamesToPrepare.add(selection.getName()); ButtonListener buttonListener = new ButtonListener();

181

preparedButton.addActionListener(buttonListener);



182

finishButton.addActionListener(buttonListener); panel.add(plateNamesToPrepare, BorderLayout.NORTH); buttonPanel.add(preparedButton); buttonPanel.add(finishButton); panel.add(buttonPanel, BorderLayout.CENTER); this.setContentPane(panel); this.setSize(500,400); this.setTitle("Οθόνη Ετοιμασίας Παραγγελίας"); this.setVisible(true); this.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE); class ButtonListener implements ActionListener public void actionPerformed(ActionEvent e) if(e.getSource() == preparedButton) firstOrder.pickPlate( plateNamesToPrepare.getSelectedItem()); int selectedIndex = plateNamesToPrepare.getSelectedIndex(); plateNamesToPrepare.remove(selectedIndex); if(plateNamesToPrepare.getItemCount() == 0) Queue.removeFirst(); else selfReference.dispose();


κλάσης PrepareOrderFrame φαίνεται στο σχήμα 8.12.



Σχήμα 8.12: Οθόνη Ετοιμασίας Παραγγελίας

Η κλάση περιλαμβάνει την ιδιότητα firstOrder, που υλοποιεί τη

συσχέτιση προς την κλάση Order και έχει ως τιμή την αναφορά προς την

πρώτη παραγγελία της ουράς παραγγελιών. Αυτή λαμβάνεται καλώντας

τη μέθοδο getFirstOrder() της κλάσης Queue. Αν η αναφορά έχει

τιμή διάφορη από null (αν δηλαδή υπάρχει έστω και μία παραγγελία

στην ουρά), λαμβάνονται τα πιάτα που αυτή περιλαμβάνει καλώντας τη

μέθοδο firstOrder.getPlates() και αναθέτοντας την

επιστρεφόμενη τιμή στην ιδιότητα platesToPrepare τύπου

ArrayList<Plate>. Σαρώνοντας τη δομή platesToPrepare

εμφανίζονται τα ονόματα των πιάτων της πρώτης παραγγελίας στο

γραφικό συστατικό λίστας plateNamesToPrepare.

Η απόκριση στο πάτημα του πλήκτρου ολοκλήρωσης ετοιμασίας ενός

πιάτου (preparedButton) και έχοντας επιλέξει κάποιο όνομα πιάτου

από τη λίστα, είναι η αποστολή του μηνύματος pickPlate() στο



αντικείμενο firstOrder, με όρισμα το όνομα του αντίστοιχου πιάτου.

Επίσης, αφαιρείται από τη λίστα plateNamesToPrepare της οθόνης το

όνομα του πιάτου που ετοιμάστηκε. Τέλος, ελέγχεται αν το πλήθος των

στοιχείων της λίστας είναι μηδενικό. Σε αυτή την περίπτωση, αφαιρείται η

πρώτη παραγγελία από την ουρά παραγγελιών καλώντας τη μέθοδο

removeFirst() από την κλάση Queue.

Η επιλογή του πλήκτρο "Έξοδος" οδηγεί στην απελευθέρωση των

πόρων του παραθύρου.



8.4 Αρχιτεκτονική Γραφικής Διασύνδεσης

Όπως γίνεται φανερό από τις ανωτέρω περιγραφές των κλάσεων που

υλοποιούν τις οθόνες του συστήματος, η γραφική διασύνδεση δεν

περιλαμβάνει λειτουργίες επί των κλάσεων οντοτήτων του συστήματος

αλλά απλά μεταβιβάζει τα αιτήματα των χρηστών σε αυτές. Από την άλλη

οι κλάσεις οντοτήτων δεν διατηρούν αναφορές προς τις κλάσεις της

γραφικής διασύνδεσης και δεν καλούν μεθόδους αυτής. Με άλλα λόγια η

διασύνδεση εξαρτάται από το μοντέλο του συστήματος (κλάσεις

οντοτήτων) αλλά το μοντέλο είναι ανεξάρτητο από τη διασύνδεση.

Η αρχιτεκτονική αυτή συμμορφώνεται με ένα από τα κλασσικότερα

πρότυπα σχεδίασης λογισμικού, το πρότυπο Μοντέλου-Όψης-Ελεγκτή

(Model-View-Controller, MVC) που παρουσιάζεται στο σχήμα 8.13. Το

πρότυπο επιβάλλει το διαχωρισμό της επιχειρηματικής λογικής του

συστήματος (το μοντέλο) από τις δύο απόψεις της διασύνδεσης χρήστη

(όψης και ελεγκτή). Η όψη αφορά τα γραφικά συστατικά που

εμφανίζονται ενώ ο ελεγκτής περιλαμβάνει τα αντικείμενα που

χειρίζονται την αλληλεπίδραση με το χρήστη και ορίζει την χρονική

ακολουθία των ενεργειών που μπορούν να λάβουν χώρα. Το πλεονέκτημα

της αρχιτεκτονικής αυτή είναι ότι αλλαγές στη δομή των δεδομένων του

μοντέλου μπορούν να διατηρήσουν (υπό προϋποθέσεις) ανέπαφη τη

γραφική διασύνδεση αλλά κυρίως ότι αλλαγές στη γραφική διασύνδεση

δεν επηρεάζουν τις κλάσεις οντοτήτων που προέκυψαν από την

αντικειμενοστρεφή ανάλυση και σχεδίαση.



Σχήμα 8.13: Πρότυπο Μοντέλου-Όψης-Ελεγκτή



9. Συμπεράσματα Η εφαρμογή της αντικειμενοστρεφούς μεθοδολογίας ανάλυσης και

σχεδίασης κατέδειξε ότι με απλά και συστηματικά βήματα είναι δυνατόν

να μεταβούμε από τις αρχικές απαιτήσεις χρήστη σε ένα λεπτομερές

σχέδιο του συστήματος λογισμικού και εν συνεχεία να υλοποιήσουμε τον

κώδικα. Βεβαίως η διαδικασία αυτή απαιτεί εμπειρία και γνώσεις από την

πλευρά του αναλυτή-σχεδιαστή-προγραμματιστή και για το λόγο αυτό δεν

είναι αυτοματοποιήσιμη. Ωστόσο, η τήρηση των βημάτων της

μεθοδολογίας ICONIX, η αξιοποίηση της Ενοποιημένης Γλώσσας

Μοντελοποίησης για τη δημιουργία των απαραίτητων μοντέλων και η

χρήση σύγχρονων εργαλείων CASE διευκολύνουν σημαντικά τη

διαδικασία ανάπτυξης λογισμικού. Εκτός της παραγωγής λειτουργικού

κώδικα που ικανοποιεί πλήρως τις απαιτήσεις του πελάτη, αξίζει να

σημειωθεί ότι η προσήλωση σε μια μεθοδολογία ανάπτυξης οδηγεί και

στην κατασκευή ποιοτικού λογισμικού, που μπορεί να κατανοηθεί, να

ελεγχθεί, να συντηρηθεί και να επαναχρησιμοποιηθεί με μικρό κόστος και

προσπάθεια.



10. Βιβλιογραφία Ξενόγλωσση

1. G. Booch, Object Solutions: Managing the Object-Oriented Project,

Addison-Wesley, 1996.

2. G. Booch, J. Rumbaugh and I. Jacobson, The Unified Modeling

Language User Guide, Addison Wesley, 1999.

3. S. R. Chidamber and C. F. Kemerer, "A Metrics Suite for Object

Oriented Design", IEEE Transactions on Software Engineering, vol.

20, no. 6, pp. 476-493, June 1994.

4. E. Gamma, R. Helm, R. Johnson and J. Vlissides, Design Patterns:

Elements of Reusable Object-Oriented Software, Addison-Wesley,

1995.

5. C. Ghezzi, M. Jazayeri and D. Mandrioli, Fundamentals of Software

Engineering, 2nd edn., Prentice Hall, 2003.

6. C. Horstmann, Big Java, 3rd edn, Wiley, 2008.

7. C. Larman, Applying UML and Patterns: An Introduction to Object-

Oriented Analysis and Design and Iterative Development, 3rd edn.,

Prentice Hall, 2005.

8. E. Lervik and V. B. Havdal, Java the UML way, Wiley, 2002.

9. L. A. Maciaszek, Requirements Analysis and System Design:

Developing Information Systems with UML, Addison-Wesley, 2001.

188

10. R. C. Martin, Agile Software Development: Principles, Patterns and

Practices, Prentice Hall, 2003.




11. T. Quatrani, Visual Modeling with Rational Rose 2000 and UML,

Addison-Wesley, 2000.

12. A. J. Riel, Object-Oriented Design Heuristics, Addison-Wesley,

1996.

13. D. Rosenberg, K. Scott, Use Case Driven Object Modeling with

UML: A Practical Approach, Addison-Wesley, 1999.

14. D. Rosenberg and M. Stephens, Use Case Driven Object Modeling

with UML: Theory and Practice, Apress, 2007.

15. J. Rumbaugh, I. Jacobson and G. Booch, Unified Modeling Language

Reference Manual, 2nd edn., Addison-Wesley, 2004.

Ελληνική

1. Β. Βεσκούκης, Τεχνολογία Λογισμικού ΙΙ, Ελληνικό Ανοικτό

Πανεπιστήμιο, Πάτρα 2001.

2. Β. Γερογιάννης, Γ. Κακαρόντζας, Α. Καμέας, Γ. Σταμέλος, Π.

Φιτσιλής, Αντικειμενοστρεφής Ανάπτυξη Λογισμικού με τη UML,

Κλειδάριθμος, 2006.

3. Α. Χατζηγεωργίου, Αντικειμενοστρεφής Σχεδίαση: UML, Αρχές,

Πρότυπα και Ευρετικοί Κανόνες, Κλειδάριθμος, 2005.

4. Fowler M. and Scott K., Εισαγωγή στη UML (UML Distilled: A Bried

Guide to the Standard Object Modeling Language), Κλειδάριθμος,

2001.