Professional Documents
Culture Documents
Ανάπτυξη συστήματος λογισμικού βάσει της μεθοδολογίας ICONIX
Ανάπτυξη συστήματος λογισμικού βάσει της μεθοδολογίας ICONIX
Χατζηγεωργίου
Ανάπτυξη συστήματος λογισμικού
βάσει της μεθοδολογίας ICONIX
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
Διαχείριση Παραγγελιών
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
Θεματική Ενότητα ΠΛΗ 24
2008
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
Πίνακας Περιεχομένων
2
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
3
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
4
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
5
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
6
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
1. Γνωσιολογικοί Στόχοι
7
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
8
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
2.1 Γενικά
Το αντικειμενοστρεφές υπόδειγμα προγραμματισμού είναι ευρέως
αποδεκτό ότι προσφέρει πολλά πλεονεκτήματα έναντι άλλων
υποδειγμάτων (π.χ. διαδικασιακού). Αυτά σχετίζονται κυρίως με την
ευκολία κατανόησης, συντήρησης, ελέγχου και επαναχρησιμοποίησης του
λογισμικού. Ωστόσο, τα πλεονεκτήματα αυτά γίνονται εμφανή κυρίως σε
έργα λογισμικού μεγάλης κλίμακας. Με τον όρο μεγάλη κλίμακα
αναφερόμαστε σε έργα όπου το μείζον πρόβλημα δεν είναι η κατάστρωση
των αλγορίθμων και η υλοποίησή τους σε κάποια γλώσσα
προγραμματισμού (όπως συμβαίνει στα έργα μικρής κλίμακας) αλλά η
δυσκολία επικοινωνίας και συντονισμού μεταξύ των μονάδων του έργου.
Ως μονάδες του έργου θεωρούνται αφενός οι μονάδες του λογισμικού (τα
φυσικά ή λογικά συστατικά του) που αναπτύσσονται χωριστά και πρέπει
να συνεργαστούν για την επίτευξη της ζητούμενης λειτουργικότητας.
Αφετέρου, ως μονάδες θεωρούνται και οι εμπλεκόμενοι στη διαδικασία
ανάπτυξης, δηλαδή οι πελάτες, οι τελικοί χρήστες, οι αναλυτές, οι
σχεδιαστές, οι προγραμματιστές και τα μέλη της διοίκησης της εταιρείας
ανάπτυξης. Τα άτομα αυτά, με διαφορετικά ενδιαφέροντα ως προς το έργο
και με διαφορετικό υπόβαθρο πρέπει να συντονιστούν και να
επικοινωνήσουν αποτελεσματικά, ώστε η ανάπτυξη ενός έργου
λογισμικού να είναι επιτυχής.
9
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
10
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
2.2 ICONIX
Η ICONIX είναι μια μεθοδολογία ανάπτυξης λογισμικού που επιτρέπει τη
συστηματική μετάβαση από τις αρχικές απαιτήσεις όπως αυτές
διατυπώνονται από τον πελάτη, στον κώδικα που τελικά υλοποιεί τις
απαιτήσεις αυτές. Είναι μια απλούστερη εκδοχή της ευρέως διαδεδομένης
Ενοποιημένης Προσέγγισης (Unified Process). Το μείζον χαρακτηριστικό
της μεθοδολογίας ICONIX είναι η επαναληπτικότητα. Αφενός, η
διαδικασία είναι επαναληπτική διότι επιτρέπει την παραγωγή
λειτουργικού κώδικα για κάθε μια περίπτωση χρήσης του συστήματος
ξεχωριστά. Σε κάθε επανάληψη, εξετάζεται μια νέα περίπτωση χρήσης
που καταλήγει στην προσθήκη λειτουργικότητας στο τελικό προϊόν.
Αφετέρου, η διαδικασία είναι επαναληπτική διότι επιτρέπει (και
υποβοηθά) την επιστροφή από ένα στάδιο της διαδικασίας ανάπτυξης (π.χ.
το σχεδιασμό) σε προηγούμενα (π.χ. την ανάλυση απαιτήσεων) με σκοπό
την αποσαφήνιση, βελτίωση και διόρθωση προηγούμενων ενεργειών. Η
επαναληπτικότητα βρίσκεται στο κέντρο του αντικειμενοστρεφούς
υποδείγματος προγραμματισμού καθώς αναγνωρίζει ότι ένα μεγάλο
σύστημα λογισμικού δεν μπορεί να αναπτυχθεί με μιας και ότι οι αλλαγές
σε προηγούμενες επιλογές είναι αναπόφευκτες.
Η φιλοσοφία της μεθοδολογίας ICONIX αποτυπώνεται στο διάγραμμα
του σχήματος 2.1. Το ζητούμενο είναι από τις απαιτήσεις του χρήστη να
παραχθεί το τελικό προϊόν, δηλαδή ο λειτουργικός κώδικας. Ο κώδικας
παράγεται με τη διαδοχική εκλέπτυνση και βελτίωση δύο μοντέλων:
11
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
12
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
do()
m1()
Ετοιμασία Πιάτου
m2()
Κύρια Οθόνη
Καταχώρηση
Παραγγελίας
Ενημέρωση Αποθέματος Ενημέρωση Αποθέματος
Πληροφόρηση Χρόνου Εκτύπωση Λογαριασμού
Παρακολούθηση
∆ημιουργία Πιάτου
Οικον.Στοιχείων
Κώδικας
Παραγγελία Πιάτο
Παραγγελία Πιάτο Παραγγελία Πιάτο
-x1 : int -quantity : int -x1 : int -quantity : int
-x2 : double -name : String -x2 : double -name : String
+calculateTime() +isAvailable()
Απαιτήσεις
Πελάτη
Συστατικό Συστατικό Συστατικό
13
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
είναι η λεπτομερής και σαφής περιγραφή των απαιτήσεων του πελάτη υπό
μορφή περιπτώσεων χρήσης.
2.2.3 Σχεδίαση
Στη φάση της σχεδίασης επιχειρείται η ακριβής διερεύνηση της δυναμικής
συμπεριφοράς του συστήματος και η κατανομή της λειτουργικότητας στις
κλάσεις. Κύριο εργαλείο για το σκοπό αυτό είναι τα διαγράμματα
ακολουθίας. Με το πέρας της σχεδίασης η ομάδα ανάπτυξης παράγει το
τελικό διάγραμμα κλάσεων που αποτελεί την είσοδο για τη φάση της
υλοποίησης του λογισμικού.
14
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
2.2.4 Υλοποίηση
Το σημαντικότερο προϊόν της διαδικασίας ανάπτυξης δεν είναι φυσικά τα
διαγράμματα αλλά ο ίδιος ο κώδικας που ικανοποιεί τις απαιτήσεις του
πελάτη. Στη φάση της υλοποίησης αναπτύσσεται ο κώδικας βάσει της
σχεδίασης που προηγήθηκε (σε μεγάλο βαθμό υπάρχει η δυνατότητα
παραγωγής κώδικα από τα διαγράμματα κλάσεων και ακολουθίας).
Παρόλο που δεν εξετάζεται στην παρούσα μελέτη, σημαντικό μέρος της
υλοποίησης είναι και ο έλεγχος μονάδων (unit testing) δηλαδή η
εξασφάλιση της ορθής λειτουργίας των κλάσεων που δημιουργήθηκαν.
Σύμφωνα με τη μεθοδολογία ICONIX αλλά και τις γενικότερες
επιταγές της Τεχνολογίας Λογισμικού, στο τέλος κάθε φάσης θα πρέπει να
πραγματοποιείται μια συστηματική επισκόπηση (inspection/review). Στις
επισκοπήσεις αυτές τα μέλη της ομάδας ανάπτυξης (αλλά ενδεχομένως
και εκπρόσωποι του πελάτη ή της διοίκησης) ελέγχουν την ορθότητα των
μοντέλων που δημιουργήθηκαν και τη συνέπεια προς τις απαιτήσεις.
Στη συνέχεια παρουσιάζονται οι φάσεις ανάπτυξης για ένα έργο
λογισμικού που αφορά σε ένα σύστημα διαχείρισης παραγγελιών
εστιατορίου. Όπως αναφέρθηκε, η διαδικασία ξεκινά από την αρχική
διατύπωση των απαιτήσεων από πλευράς του πελάτη. Σημειώνεται ότι οι
προδιαγραφές που τίθενται από το χρήστη (αναφέρονται ως απαιτήσεις
υψηλού επιπέδου – high level requirements specification) είναι συχνά
περιληπτικές, ασαφείς και όχι πλήρεις.
15
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
16
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
4. Καθορισμός Απαιτήσεων ◄ ►
17
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
18
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
19
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
20
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
21
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
22
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
23
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
24
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
25
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
26
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
27
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
Βασική Ροή
1. Ο χρήστης επιλέγει το πλήκτρο "Πληρωμή μέσω Κάρτας"
2. Το σύστημα εμφανίζει την οθόνη "Πληρωμή μέσω Κάρτας"
3. Ο χρήστης εισάγει τον αριθμό της κάρτας και το ποσό και επιλέγει
Αποστολή
4. Το σύστημα εμφανίζει μήνυμα ολοκλήρωσης της συναλλαγής
Εναλλακτική Ροή
4.α.1 Ο αριθμός της κάρτας δεν είναι έγκυρος
4.α.2 Το σύστημα εμφανίζει μήνυμα σφάλματος
4.α.3 Η περίπτωση χρήσης συνεχίζεται από το βήμα 2 της βασικής
ροής
28
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
29
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
30
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
31
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
32
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
33
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
34
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
2ο Πρότυπο
Βασική Ροή
1. Ο Μάγειρας επιλέγει στην Κύρια Οθόνη το πλήκτρο
"δημιουργία πιάτου"
2. Το σύστημα εμφανίζει την Οθόνη "Δημιουργία Πιάτου" η
οποία λαμβάνει τα ονόματα των συστατικών από τον
Κατάλογο Συστατικών και τα εμφανίζει
3. Το σύστημα δημιουργεί το αντίστοιχο Πιάτο
4. Ο Μάγειρας εισάγει την ονομασία του Πιάτου και στη
συνέχεια επιλέγει το πλήκτρο "Καταχώρηση Ονόματος"
5. Το σύστημα καταχωρεί το όνομα στο Πιάτο
6. Ο Μάγειρας επιλέγει ένα συστατικό που περιέχει το Πιάτο και
εισάγει την αντίστοιχη ποσότητα που απαιτείται
7. Ο Μάγειρας επιλέγει το πλήκτρο Προσθήκη Συστατικού
8. Το σύστημα καταχωρεί το συστατικό που επιλέχθηκε και την
αντίστοιχη ποσότητα στο Πιάτο.
τα βήματα 6-8 επαναλαμβάνονται για όσα συστατικά επιθυμεί να
επιλέξει ο χρήστης
9. Ο Μάγειρας επιλέγει το πλήκτρο "Τερματισμός"
10. Το σύστημα εισάγει το Πιάτο στον Κατάλογο Πιάτων και
επιστρέφει στην Κύρια Οθόνη.
35
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
36
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
2ο Πρότυπο
Βασική Ροή
Εναλλακτική Ροή 1
4.α.1 Ο Σερβιτόρος επιλέγει Πιάτο όπου κάποιο από τα συστατικά
έχει εξαντληθεί
4.α.2 Το πιάτο δεν προστίθεται στην παραγγελία και εμφανίζεται
μήνυμα προειδοποίησης
4.α.3. Η περίπτωση χρήσης συνεχίζει από το βήμα 4 της βασικής
ροής
37
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
38
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
2ο Πρότυπο
Βασική Ροή
1. Ο Μάγειρας επιλέγει στην Κύρια Οθόνη το πλήκτρο ετοιμασία
παραγγελίας
2. Το σύστημα εμφανίζει την Οθόνη "Ετοιμασία Παραγγελίας" η
οποία λαμβάνει την πρώτη παραγγελία από την Ουρά
παραγγελιών και εμφανίζει τα πιάτα που περιλαμβάνει
3. Ο Μάγειρας επιλέγει ένα πιάτο και πατάει το πλήκτρο
"Ολοκλήρωση"
4. Το σύστημα αφαιρεί από τα συστατικά που περιέχει το πιάτο
τις αντίστοιχες ποσότητες
Τα βήματα 3, 4 επαναλαμβάνονται για όλα τα πιάτα της
παραγγελίας
5. Όταν ολοκληρωθούν όλα τα πιάτα από μία παραγγελία η
παραγγελία αφαιρείται από την Ουρά.
6. Ο Μάγειρας επιλέγει το πλήκτρο "Κλείσιμο"
7. Το σύστημα επιστρέφει στην Κύρια Οθόνη
39
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
40
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
2ο Πρότυπο
1. Ο Σερβιτόρος επιλέγει στην Κύρια Οθόνη το πλήκτρο
υπολογισμός χρόνου
2. Το σύστημα εμφανίζει την Οθόνη "Υπολογισμός Χρόνου" η
οποία λαμβάνει από την Ουρά τους κωδικούς των παραγγελιών
που αναμένουν προς εξυπηρέτηση και τους εμφανίζει
3. Ο Σερβιτόρος επιλέγει τον κωδικό της παραγγελίας για την
οποία επιθυμεί να υπολογίσει τον εκτιμώμενο χρόνο αναμονής
4. Ο Σερβιτόρος επιλέγει το πλήκτρο "υπολογισμός χρόνου"
5. Η Ουρά υπολογίζει το χρόνο εντοπίζοντας τη θέση της
παραγγελίας που ζητήθηκε και υπολογίζοντας τα πιάτα για τις
παραγγελίες που βρίσκονται "μπροστά" από την ζητούμενη
παραγγελία. Στη συνέχεια αθροίζει 2 λεπτά για κάθε πιάτο της
ζητούμενης παραγγελίας
6. Το σύστημα εμφανίζει τον εκτιμώμενο χρόνο αναμονής
7. Ο Σερβιτόρος επιλέγει το πλήκτρο "Κλείσιμο"
8. Το σύστημα επιστρέφει στην Κύρια Οθόνη
41
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
5. Ανάλυση ◄ ►
42
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
43
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
44
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
45
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
46
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
47
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
48
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
Κατάλογος Συστατικών
δημιουργία
επιλογή
∆ημιουργίας Πιάτου λήψη ονομάτων
καταχώρηση Πιάτο
Οθόνη ∆ημιουργίας Πιάτου
επιλογή τερματισμού
επιλογή συστατικού/ποσοτήτας
και επιλογή προσθήκης
εμφάνισε
εισαγωγή Πιάτου καταχώρηση
Κατάλογος Πιάτων
49
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
Κατάλογος Πιάτων
επιλογή
προσθήκης
παραγγελίας
λήψη ονομάτων
ολοκλήρωση παραγγελίας
εμφάνισε καταχώρηση
επιλογή Πιάτου
Παραγγελία
Πιάτο
Ουρά ναι
καταχώρηση
υπάρχουν συστατικά?
όχι
50
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
λήψη Πιάτων
επιλογή τερματισμού επιλογή πιάτου αφαίρεση ποσότητας
και ολοκλήρωση
εμφάνισε
επιλογή πιάτου Παραγγελία αφαίρεση συστατικών Πιάτο
51
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
λήψη παραγγελιών
επιλογή
Σερβιτόρος Υπολογισμού Χρόνου Κύρια Οθόνη εμφάνισε
επιλογή
κωδικού παραγγελίας Ουρά εύρεση θέσης παραγγελίας
και πλήκτρου υπολογισμού
επιλογή τερματισμού
Οθόνη Υπολογισμού Χρόνου υπολογισμός χρόνου
εμφάνισε
υπολογισμός πιάτων που αναμένουν
άθροιση χρόνων
52
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
από το σημείο αυτό και μετά να παρατίθενται και οι αγγλικοί όροι για τις
ονομασίες κλάσεων, ιδιοτήτων και μεθόδων):
Από την περίπτωση χρήσης 1 και το αντίστοιχο διάγραμμα ευρωστίας
προκύπτει ότι στο μοντέλο πεδίου προβλήματος πρέπει να συμπεριληφθεί
η κλάση Κατάλογος Συστατικών (IngredientCatalog) και η κλάση
Κατάλογος Πιάτων (PlateCatalog). Τέτοιες κλάσεις, που λειτουργούν ως
συλλογές αντικειμένων κλάσεων οντοτήτων είναι αναμενόμενες στις
περισσότερες εφαρμογές, ακόμα και αν δεν αναφέρονται ρητά στις
απαιτήσεις, καθώς επιτρέπουν τον εντοπισμό και την ανάκτηση των
αντικειμένων των κλάσεων οντοτήτων. Οι δύο αυτές κλάσεις
περιλαμβάνουν αντικείμενα των κλάσεων Συστατικό (Ingredient) και
Πιάτο (Plate) αντίστοιχα, και για το λόγο αυτό συνδέονται με σχέση
συναρμολόγησης με αυτές με πολλαπλότητα πολλά στο άκρο των
κλάσεων οντοτήτων. Από το ίδιο διάγραμμα ευρωστίας προκύπτει ότι η
κλάση Συστατικό καθώς και η κλάση Πιάτο θα περιλαμβάνουν μια
ιδιότητα όνομα (name) καθώς τα ονόματα των συστατικών εμφανίζονται
στην Οθόνη Δημιουργίας Πιάτου ενώ ο χρήστης ρητά αναφέρεται ότι
εισάγει το όνομα κάθε πιάτου που δημιουργεί. Ακολουθώντας την αρχή
της ενσωμάτωσης που επιβάλλει η πρόσβαση στις ιδιότητες ενός
αντικειμένου να πραγματοποιείται μόνο μέσω της δημόσιας διασύνδεσης
της κλάσης, όλες οι ιδιότητες μιας κλάσης ορίζονται να έχουν ορατότητα
ιδιωτική (private). Η ιδιωτική ορατότητα υποδηλώνεται στο διάγραμμα
κλάσεων της UML με ένα σύμβολο '-' πριν από το όνομα κάθε ιδιότητας.
53
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
Αξίζει να σημειωθεί ότι στο στάδιο της ανάλυσης δεν είναι απαραίτητο να
απεικονίζονται στο διάγραμμα κλάσεων οι τύποι δεδομένων κάθε
ιδιότητας. Η σύμβαση που ακολουθείται είναι τα ονόματα κλάσεων να
ξεκινούν με κεφαλαίο γράμμα, ενώ τα ονόματα των ιδιοτήτων και
μεθόδων να ξεκινούν με πεζό γράμμα.
Από την περίπτωση χρήσης 2 προκύπτει ότι κατά τη δημιουργία μιας
νέας παραγγελίας καταχωρείται σε αυτήν ένας νέος αύξοντας κωδικός και
επομένως μια ιδιότητα κωδικός (code) προστίθεται στην κλάση
Παραγγελία (Order).
Από την περίπτωση χρήσης 3 και το αντίστοιχο διάγραμμα ευρωστίας
συνάγεται ότι κατά την ετοιμασία ενός πιάτου αφαιρούνται από τα
συστατικά που περιέχει οι αντίστοιχες ποσότητες. Επομένως στην κλάση
Συστατικό προστίθεται μια ιδιότητα ποσότητα (amount).
Στο αναθεωρημένο μοντέλο του πεδίου προβλήματος σημειώνονται
πλέον και σύμβολα πολλαπλότητας στις σχέσεις συναρμολόγησης. Το
αναθεωρημένο διάγραμμα απεικονίζεται στο σχήμα 5.7.
54
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
55
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
6. Σχεδίαση ◄ ►
56
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
57
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
58
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
πολυπλοκότητα στο διάγραμμα, υπό την έννοια ότι δεν συμβάλλει στην
κατανομή της λειτουργικότητας σε κλάσεις.
59
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
60
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
61
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
6.1.4 Εναλλακτικές
Οι εναλλακτικές (alternatives) χρησιμοποιούνται για να υποδηλώσουν
έναν αμοιβαίο αποκλεισμό μεταξύ δύο ή περισσοτέρων ακολουθιών από
μηνύματα. Επιτρέπουν τη μοντελοποίηση της κλασσικής "if then else"
λογικής. Ένα παράδειγμα διαγράμματος ακολουθίας όπου
χρησιμοποιείται ο συμβολισμός του συνδυασμένου τμήματος των
εναλλακτικών παρουσιάζεται στο σχήμα 6.2.
62
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
63
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
6.1.5 Βρόχοι
Οι βρόχοι (loops) χρησιμοποιούνται για να υποδηλώσουν μια
επαναληπτική διαδικασία. Επιτρέπουν τη μοντελοποίηση της κλασσικής
λογικής "while(συνθήκη)". Ένα παράδειγμα διαγράμματος ακολουθίας
όπου χρησιμοποιείται ο συμβολισμός του συνδυασμένου τμήματος των
βρόχων παρουσιάζεται στο σχήμα 6.3.
64
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
65
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
66
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
67
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
68
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
69
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
70
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
71
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
72
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
73
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
διάγραμμα ακολουθίας 1 ◄
Συστατικό Πιάτο Κατάλογος Κατάλογος
(Ingredient) (Plate) Συστατικών Πιάτων
(IngredientCatalog) (Plate
Catalog)
λήψη καταχώρηση ονόματος (όνομα) λήψη ονομάτων καταχώρηση
ονόματος setPlateName(String) getIngredientNames() (Πιάτο)
getName() add(Plate)
καταχώρηση(συστατικό, ποσότητα)
storeIngredient(Ingredient,
int)
Τα ονόματα των μεθόδων εμφανίζονται και στα αγγλικά για λόγους ευκολότερης
αντιστοίχισης με το τελικό διάγραμμα κλάσεων. Επιπλέον, ορισμένα ονόματα μεθόδων
έχουν τροποποιηθεί σε σχέση με τα αντίστοιχα μηνύματα στα διαγράμματα ακολουθίας,
ώστε το όνομά τους να αποκαλύπτει τη χρήση τους.
74
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
διάγραμμα ακολουθίας 2 ◄
Παραγγελία Πιάτο Ουρά Συστατικό Κατάλογος
(Order) (Plate) (Queue) (Ingredient) Πιάτων
(Plate
Catalog)
καταχώρηση λήψη ονόματος καταχώρηση έλεγχος ποσότητας λήψη ονομάτων
(Πιάτο) getName() (Παραγγελία) (ποσότητα) getPlateNames()
addPlate(Plate) add(Order) checkQuantity(int)
έλεγχος
διαθεσιμότητας
isAvailable()
διάγραμμα ακολουθίας 3 ◄
Συστατικό Πιάτο Ουρά Παραγγελία
(Ingredient) (Plate) (Queue) (Order)
αφαίρεση(ποσότητα) επιλογή λήψη πρώτης παραγγελίας λήψη πιάτων
remove(int) pick() getFirstOrder() getPlates()
αφαίρεση πρώτης επιλογή Πιάτου(όνομα)
παραγγελίας pickPlate(String)
removeFirstOrder()
75
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
διάγραμμα ακολουθίας 4 ◄
Ουρά Παραγγελία
(Queue) (Order)
λήψη κωδικών λήψη κωδικού
getOrderCodes() getCode()
υπολογισμός χρόνου(κωδικός) λήψη αριθμού πιάτων
calculateTime(int) getNumberOfPlates()
εύρεση θέσης παραγγελίας(κωδικός)
findPosition(int)
υπολογισμός πιάτων που αναμένουν
calculatePlatesWaiting()
76
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
77
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
78
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
79
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
80
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
81
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
82
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
εφαρμογή της μετρικής στο ίδιο λογισμικό και για ίδια δεδομένα
εισόδου, σε διαφορετικές χρονικές στιγμές, θα πρέπει να είναι πάντοτε
τα ίδια. Οποιοσδήποτε χρήστης της μετρικής θα πρέπει να καταλήγει
στα ίδια αποτελέσματα.
• Συνεπής ως προς τη χρήση μονάδων και διαστάσεων: Η χρήση
83
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
Στην Τεχνολογία Λογισμικού υπάρχουν ήδη από τις αρχές της δεκαετίας
του 1970 δύο θεμελιώδεις έννοιες που χρησιμοποιούνται για την
αξιολόγηση της αρχιτεκτονικής δομής ενός συστήματος λογισμικού (όχι
μόνο αντικειμενοστρεφούς λογισμικού). Η έννοια της σύζευξης και της
συνεκτικότητας.
84
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
6.5.1 Σύζευξη
Η σύζευξη (coupling) αναφέρεται στο βαθμό αλληλεξάρτησης μεταξύ των
μονάδων ενός συστήματος (κλάσεων για αντικειμενοστρεφή συστήματα).
Όσο μικρότερη είναι η αλληλεξάρτηση, τόσο ευκολότερη είναι η
κατανόηση, η συντήρηση, ο έλεγχος και η επαναχρησιμοποίηση κάθε
μονάδας. Κατά συνέπεια, βασικός στόχος κατά τη διάρκεια της σχεδίασης
είναι η ελαχιστοποίηση της σύζευξης. Ο στόχος αυτός δεν είναι εύκολο να
επιτευχθεί ακολουθώντας μια συγκεκριμένη διαδικασία. Ωστόσο, είναι
σχετικά εύκολη η μέτρηση της σύζευξης ενός συστήματος λογισμικού
(είτε αυτό υπάρχει ως διάγραμμα κλάσεων είτε ως κώδικας) και η
παρακολούθηση της εξέλιξής της. Η εμφάνιση υψηλών τιμών σύζευξης
είτε για ολόκληρο το σύστημα είτε για μεμονωμένες κλάσεις λειτουργεί
ως ένα σήμα προειδοποίησης που επιβάλλει την αναδιοργάνωση του
σχεδίου.
Στη βιβλιογραφία έχουν προταθεί δεκάδες μετρικές για την
ποσοτικοποίηση της σύζευξης που διαφέρουν κυρίως στον αριθμό και το
είδος των παραμέτρων που λαμβάνουν υπόψη για να εκτιμήσουν αν
υπάρχει σύζευξη μεταξύ δύο κλάσεων ή όχι. Στην ανάλυση που
ακολουθεί χρησιμοποιείται ο παλαιότερος ορισμός της σύζευξης που
συμβολίζεται ως CBO (Coupling Between Objects). Σύμφωνα με αυτή τη
μετρική η τιμή της σύζευξης για μια κλάση C ισούται με το πλήθος άλλων
κλάσεων του συστήματος με τις οποίες υπάρχει σύζευξη (εξαιρώντας
σύζευξη λόγω κληρονομικότητας). Ως σύζευξη μεταξύ της κλάσης C και
85
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
μιας άλλης κλάσης D νοείται η ύπαρξη ιδιοτήτων της κλάσης C που έχουν
ως τύπο την D, ή η ύπαρξη παραμέτρων σε μεθόδους που έχουν ως τύπο
την D. Η τιμή της μετρικής μπορεί φυσικά να εξαχθεί εξετάζοντας τον
πηγαίο κώδικα του συστήματος, είναι όμως δυνατός και ο υπολογισμός
στην περίπτωση που είναι διαθέσιμο ένα λεπτομερές διάγραμμα κλάσεων.
Ως τιμή της σύζευξης για ολόκληρο το σύστημα θεωρείται η μέση τιμή
της σύζευξης των κλάσεων του συστήματος.
Για το σύστημα διαχείρισης παραγγελιών που αναπτύχθηκε οι τιμές
της σύζευξης για κάθε κλάση ξεχωριστά καθώς και η τιμή για ολόκληρο
το σύστημα παρουσιάζονται στον πίνακα 6.5.
86
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
87
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
6.5.2 Συνεκτικότητα
Η συνεκτικότητα (cohesion) αναφέρεται στο βαθμό εσωτερικής συνοχής
των τμημάτων μιας μονάδας λογισμικού. Στα πλαίσια των
αντικειμενοστρεφών συστημάτων ποσοτικοποιεί το βαθμό λειτουργικής
συνάφειας των μεθόδων μιας κλάσης. Όσο πιο συνεκτική είναι μια κλάση,
τόσο πιο πολύ οι μέθοδοί της σχετίζονται μεταξύ τους και συνεργάζονται
για την επίτευξη ενός και μόνο κοινού σκοπού. Για λόγους ευκολότερης
κατανόησης, συντήρησης και ελέγχου μιας κλάσης, είναι γενικά
επιθυμητό μια κλάση να μην αναλαμβάνει διαφορετικές αρμοδιότητες.
Υπό αυτή την έννοια μια κλάση πρέπει να είναι όσο το δυνατόν πιο
συνεκτική και αν είναι εφικτό, όλες οι μέθοδοί της να είναι συνεκτικές
μεταξύ τους. Δύο μέθοδοι θεωρούνται συνεκτικές εάν προσπελαύνουν
έστω και μία κοινή ιδιότητα της κλάσης, θεωρώντας ότι η χρήση κοινών
ιδιοτήτων υποδηλώνει και κάποιου είδους λειτουργική συνάφεια.
Κατ' αντιστοιχία με την μετρική της σύζευξης θα αναφερθούμε στην
παλαιότερη μετρική συνεκτικότητας που είναι γνωστή ως LCOM (Lack of
Cohesion Of Methods). Η μετρική αυτή ποσοτικοποιεί την έλλειψη
συνεκτικότητας μιας κλάσης, δηλαδή όσο μικρότερη τιμή έχει για μια
κλάση, τόσο μεγαλύτερη συνεκτικότητα υπάρχει. Ονομάζοντας P το
πλήθος των μη συνεκτικών ζευγών μεθόδων και Q το πλήθος των
συνεκτικών ζευγών μεθόδων μιας κλάσης, η τιμή της συνεκτικότητας
υπολογίζεται ως LCOM = P − Q (αν P > Q ), αλλιώς η τιμή της μετρικής
LCOM θεωρείται ίση με το 0 (ιδανική περίπτωση). Ως τιμή της
88
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
89
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
90
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
91
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
6.5.3 Πολυπλοκότητα
Η πολυπλοκότητα του λογισμικού είναι από ένα από τα πρώτα
χαρακτηριστικά που η κοινότητα της Τεχνολογίας Λογισμικού
προσπάθησε να ποσοτικοποιήσει. Η έννοια της πολυπλοκότητας γίνεται
αντιληπτή με διαφορετικούς τρόπους ανάλογα με την οπτική γωνία από
την οποία εξετάζει κανείς το λογισμικό. Η πολυπλοκότητα δεν αφορά
μόνο στα αντικειμενοστρεφή συστήματα αλλά σε οποιοδήποτε τμήμα
κώδικα, ανεξαρτήτως γλώσσας και υποδείγματος προγραμματισμού.
Ωστόσο, στα πλαίσια της αντικειμενοστρεφούς σχεδίασης η
πολυπλοκότητα δεν εξαρτάται μόνο από τη φύση των αλγορίθμων που
υλοποιούνται αλλά και από την κατανομή της λειτουργικότητας σε
κλάσεις και μεθόδους. Από πληθώρα εμπειρικών μελετών έχει αποδειχθεί
ότι τμήματα λογισμικού με μεγάλη πολυπλοκότητα, είναι πιθανό να
εμφανίσουν περισσότερα σφάλματα κατά τη διάρκεια εκτέλεσης.
Επιπλέον, η πολυπλοκότητα συμβάλλει στη δυσκολία κατανόησης και
στην αύξηση του κόστους συντήρησης του λογισμικού.
Ο παλαιότερος ορισμός πολυπλοκότητας σε αντικειμενοστρεφή
συστήματα αφορά στη μετρική πολυπλοκότητας μεθόδων κλάσης που
συμβολίζεται ως WMC (Weighted Methods per Class). Η μετρική αυτή
υποστηρίζεται από όλα τα εργαλεία CASE που υπολογίζουν τιμές
μετρικών. Θεωρούμε μια κλάση C με μεθόδους M1, M2, …, Mn. Έστω c1,
c2, …, cn ένα μέτρο πολυπλοκότητας των μεθόδων (όπως η κυκλωματική
πολυπλοκότητα που περιγράφεται στη συνέχεια). Η τιμή της μετρικής
92
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
είναι το άθροισμα των τιμών πολυπλοκότητας για όλες τις μεθόδους της
n
κλάσης ( WMC = ∑ ci ).
i =1
93
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
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 ..επόμενο τμήμα κώδικα
94
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
όπου E είναι ο αριθμός των ακμών και V ο αριθμός των κόμβων του
γράφου. Για το γράφο του σχήματος 6.9 ο αριθμός των ακμών είναι 9, ο
αριθμός των κόμβων είναι 7 και κατά συνέπεια η τιμή της κυκλωματικής
πολυπλοκότητας είναι V (G ) = 9 − 7 + 2 = 4
2. V (G ) = P + 1 ,
όπου P o αριθμός των κόμβων απόφασης του γράφου ροής ελέγχου. Ένας
κόμβος χαρακτηρίζεται κόμβος απόφασης εάν έχει περισσότερες από μία
εξερχόμενες ακμές. Για το παράδειγμα του αλγορίθμου bubblesort, το
πλήθος των κόμβων απόφασης είναι τρεις και κατά συνέπεια,
V (G ) = 3 + 1 = 4 .
3. V(G) = αριθμός περιοχών του γράφου,
όπου περιοχή ενός γράφου είναι το τμήμα που περικλείεται από
οποιοδήποτε στοιχειώδη κύκλο του, συμπεριλαμβανομένης και της
εξωτερικής περιοχής εκτός του γράφου. Ένας στοιχειώδης κύκλος είναι
μια διαδρομή όπου ταυτίζονται ο πρώτος και ο τελευταίος κόμβος, όπου
όλοι οι κόμβοι είναι διακεκριμένοι και δεν περιλαμβάνονται άλλοι κύκλοι.
Για τον γράφο του αλγορίθμου bubblesort ο αριθμός των περιοχών είναι
4, και κατά συνέπεια V(G) = 4.
95
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
96
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
97
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
98
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
99
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
100
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
Αντικείμενο1 : Λογαριασμός
{
- όνομα_κατόχου
κατάσταση - αριθμός
- υποκατάστημα_Τράπεζας
- υπόλοιπο πρόσβαση στις
ιδιότητες μόνο μέσω
των δημόσιων μεθόδων
{
+ υπολογισμός_Τόκων( )
+ εκτύπωση_Υπολοίπου( )
συμπεριφορά + κατάθεση( )
+ ανάληψη( )
Σχήμα 6.10: Αρχή της Ενσωμάτωσης σε ένα αντικείμενο τύπου
Λογαριασμός
Κατ' αυτόν τον τρόπο, ο σχεδιαστής της κλάσης, επιβάλλοντας στον "έξω
κόσμο" να προσπελάσει τις ιδιότητες μέσω των δημόσια διαθέσιμων
μεθόδων, έχει τη δυνατότητα να καθορίσει τους κανόνες και τα
δικαιώματα πρόσβασης. Τα ιδιωτικά μέλη δεδομένων αποκρύπτονται
κατά συνέπεια από τους προγραμματιστές άλλων κλάσεων ή άλλων
συστημάτων (παραμένει ωστόσο η δυνατότητα προσπέλασής τους από
άλλα αντικείμενα της ίδιας κλάσης).
Η παραβίαση της αρχής της ενσωμάτωσης ενδέχεται να οδηγήσει στη
δημιουργία μη έγκυρων αντικειμένων, δηλαδή αντικειμένων των οποίων η
κατάστασή τους δεν είναι ορθή. Για την καλύτερη κατανόηση της έννοιας
της εγκυρότητας ενός αντικειμένου θεωρούμε μια κλάση TimeStamp που
101
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
class TimeStamp {
public:
TimeStamp();
TimeStamp(int hr, int min, int sec);
void printTimeStamp();
102
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
class TimeStamp {
. . .
public:
void incrementHour();
private:
int hour;
int minute;
int second;
. . .
};
103
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
void TimeStamp::incrementHour() {
hour++;
if(hour == 24)
hour = 0;
}
Συμπερασματικά, θα πρέπει να σημειωθεί ότι η παραβίαση της αρχής της
ενσωμάτωσης είναι δυνατόν να προκαλέσει ορισμένα από τα πιο
σημαντικά προβλήματα συντήρησης αντικειμενοστρεφούς λογισμικού.
Επιτρέποντας την τροποποίηση ιδιοτήτων ενός αντικειμένου μέσα από
μεθόδους άλλων κλάσεων, στην ουσία καταργείται η ομαδοποίηση
δεδομένων και συμπεριφοράς, στοιχείο που είναι υπεύθυνο για τα
περισσότερα πλεονεκτήματα του αντικειμενοστρεφούς μοντέλου. Αν τα
δεδομένα είναι δημόσια, είναι πολύ δύσκολο να καθοριστεί ποιο τμήμα
του κώδικα του συστήματος εξαρτάται από αυτά τα δεδομένα
χρησιμοποιώντας τα. Το πρόβλημα αυτό, είναι ακριβώς ένα από τα
μειονεκτήματα των διαδικασιακών γλωσσών. Αν λόγω μελλοντικών
απαιτήσεων αλλάξει η αναπαράσταση των δεδομένων, τότε όλα τα
τμήματα κώδικα που τα χρησιμοποιούν πρέπει να ενημερωθούν, ενώ ο
εντοπισμός αυτών των τμημάτων είναι εξαιρετικά επίπονη διαδικασία.
104
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
105
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
106
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
107
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
108
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
μόνο οι κλάσεις που καλούν άμεσα τη μέθοδο, αλλά και η κλάση C που
αποκτά πρόσβαση στη μέθοδο δια μέσου μιας αλυσίδας κλήσεων,
στοιχείο που είναι δύσκολο να εντοπιστεί ώστε να προληφθούν
σφάλματα.
Η εφαρμογή της μεθοδολογίας ICONIX συμβάλλει στην αποφυγή
παραβίασης του κανόνα της Δήμητρας καθώς η επικοινωνία μεταξύ των
αντικειμένων που τεκμηριώνεται στα διαγράμματα ακολουθίας στηρίζεται
στην ύπαρξη αντίστοιχων συσχετίσεων μεταξύ των κλάσεών τους στο
στατικό μοντέλο του συστήματος.
109
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
7.Υλοποίηση ◄ ►
110
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
111
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
7.2.1 Κλάσεις
Για την κλάση Ingredient του συστήματος που αναπτύσσουμε, η οποία
στη UML συμβολίζεται ως εξής:
//Java
112
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
τους τύπους δεδομένων για τις επιστρεφόμενες τιμές και τις παραμέτρους
των μεθόδων (π.χ. boolean για τη μέθοδο checkQuantity). Τα
προσδιοριστικά ορατότητας των ιδιοτήτων και των μεθόδων που
καθορίζονται σε ένα μοντέλο UML μεταφράζονται στα αντίστοιχα
προσδιοριστικά της γλώσσας προγραμματισμού. Ο συμβολισμός που
χρησιμοποιείται στη UML για την ορατότητα είναι ' + ' (για public), ' - '
(για private), ' # ' (για protected).
Στα περισσότερα εργαλεία ανάπτυξης, για όλες τις ιδιότητες που είναι
δηλωμένες ως ιδιωτικές (private) υπάρχει η δυνατότητα αυτόματης
προσθήκης στον παραγόμενο κώδικα, των αντίστοιχων μεθόδων
πρόσβασης και τροποποίησης των τιμών τους (μέθοδοι get() και set()
αντίστοιχα). Επίσης, υπάρχει η δυνατότητα προσθήκης ενός κενού
κατασκευαστή στον παραγόμενο κώδικα, ακόμα και αν αυτός δεν
υποδηλώνεται ρητά στο διάγραμμα μιας κλάσης. Οι δυνατότητες αυτές
παρέχονται συνήθως ως δυνητικές επιλογές στο χρήστη, δηλαδή μπορούν
να ενεργοποιηθούν ή να απενεργοποιηθούν.
Παρόλο που είναι λογικό να αναμένει κανείς ότι ένα εργαλείο δεν
μπορεί να "συμπληρώσει" με κώδικα το σώμα των μεθόδων μιας κλάσης,
στα σύγχρονα περιβάλλοντα ανάπτυξης λογισμικού έχουν γίνει
προσπάθειες και προς αυτή την κατεύθυνση. Για παράδειγμα, αν στα
διαγράμματα ακολουθίας του μοντέλου προσδιορίζεται επακριβώς ποια
μηνύματα αποστέλλει μια κλάση μετά τη λήψη ενός μηνύματος alpha,
τότε στο σώμα της μεθόδου alpha() προστίθεται αυτόματα κώδικας
113
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
τότε κατά την παραγωγή του κώδικα για την κλάση Β (θεωρώντας ότι
υφίστανται ήδη στην κλάση Β αναφορές προς τις κλάσεις C και D) είναι
δυνατόν να παραχθεί αυτόματα το σώμα της μεθόδου doSmth(), όπως
φαίνεται από τα σχόλια στον ακόλουθο κώδικα:
114
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
public class B {
private C c1;;
private D d1;
115
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
7.2.2 Συσχετίσεις
Στην περίπτωση όπου μεταξύ δύο κλάσεων υπάρχει μονόδρομη συσχέτιση
(association), δηλαδή συσχέτιση με κατεύθυνση από τη μία μόνο κλάση
προς την άλλη, όπως για παράδειγμα μεταξύ της κλάσης που αναλαμβάνει
τη γραφική διασύνδεση χρήστη για την οθόνη "Ετοιμασία Παραγγελίας"
(PrepareOrderFrame) και της πρώτης παραγγελίας στην ουρά
παραγγελιών, που απεικονίζεται στο ακόλουθο διάγραμμα κλάσεων:
. . .
. . .
116
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
117
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
. . .
. . .
. . .
. . .
118
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
119
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
import javax.util.ArrayList;
. . .
120
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
121
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
δεν διαφέρουν στην υλοποίηση αλλά ούτε και διαφέρουν από την
υλοποίηση μιας απλής συσχέτισης. Σε όλες τις περιπτώσεις η αντίστοιχη
σχέση υλοποιείται με την προσθήκη κατάλληλων αναφορών στις
εμπλεκόμενες κλάσεις. Η διαφοροποίηση έχει ισχύ μόνο στο εννοιολογικό
μοντέλο και όπως έγινε ήδη φανερό από την κατασκευή του μοντέλου του
πεδίου προβλήματος, στόχος είναι ο εντοπισμός σχέσεων περιεκτικότητας
μεταξύ των κλάσεων. Επομένως, η συναρμολόγηση μεταξύ Παραγγελίας
και Πιάτου στο σύστημα που αναπτύσσουμε και παρουσιάζεται στο
ακόλουθο διάγραμμα:
. . .
122
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
123
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
124
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
125
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
126
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
127
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
}
}
import java.util.ArrayList;
128
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
129
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
public Rental() {
movies = new ArrayList();
}
130
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
131
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
132
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
133
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
134
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
135
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
136
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
και getName() που θέτουν τιμή στην ιδιότητα και επιστρέφουν την τιμή
της αντίστοιχα. Η σχέση περιεκτικότητας με την κλάση Συστατικό
υλοποιείται με τη χρήση ενός χάρτη κατακερματισμού (HashMap). Ο
λόγος είναι ότι για κάθε Πιάτο δεν θέλουμε να γνωρίζουμε μόνο τα
συστατικά που περιλαμβάνει αλλά για κάθε συστατικό να γνωρίζουμε και
την ποσότητά που απαιτείται. Η κλάση HashMap αποτελεί μια δομή
δεδομένων που περιλαμβάνει ζεύγη κλειδιών και δεδομένων. Και τα
κλειδιά και τα δεδομένα μπορούν να είναι αυθαίρετα αντικείμενα. Ένα
συγκεκριμένο κλειδί μπορεί μόνο μία φορά να αποτελέσει στοιχείο της
δομής και μπορεί να συνδεθεί με μόνο μία τιμή. Στην προκειμένη
περίπτωση το κλειδιά είναι αντικείμενα της κλάσης Συστατικό ενώ ως
τιμή αντιστοιχίζεται σε κάθε κλειδί ένας ακέραιος που υποδηλώνει την
ποσότητα του συστατικού που απαιτείται για το συγκεκριμένο πιάτο.
Η μέθοδος storeIngredient() επιτρέπει την καταχώρηση ενός
συστατικού και της ποσότητάς του στο Πιάτο (για το λόγο αυτό λαμβάνει
ένα αντικείμενο Ingredient και έναν ακέραιο ως παραμέτρους). Στο σώμα
της μεθόδου καλείται η μέθοδος put() της κλάσης HashMap που εισάγει
ένα ζεύγος κλειδιού-τιμής στη δομή δεδομένων.
Η κατηγορηματική μέθοδος isAvailable() ελέγχει τη
διαθεσιμότητα του πιάτου και επιστρέφει την τιμή true εάν και μόνον αν
όλα τα συστατικά του πιάτου είναι διαθέσιμα. Στο σώμα της "σαρώνει" το
χάρτη κατακερματισμού των συστατικών και για κάθε στοιχείο ελέγχεται
η διαθεσιμότητα της απαιτούμενης ποσότητας, καλώντας τη μέθοδο
137
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
138
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
if(checkQuantity(quantity)) {
amount = amount - quantity;
return true;
}
else
return false;
}
139
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
140
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
141
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
142
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
for(Order o: ordersWaiting) {
int orderID = o.getCode();
orderIDs.add(Integer.toString(orderID));
}
return orderIDs;
}
platesWaiting = calculatePlatesWaiting(positionInQueue);
timeInSecs = platesWaiting * 2;
return timeInSecs;
}
143
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
144
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
145
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
146
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
147
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
148
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
149
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
150
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
151
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
import javax.swing.JFrame;
public MainFrame() {
this.setSize(200, 200);
this.setTitle("Κύρια Οθόνη Συστήματος
Διαχείρισης Παραγγελιών");
this.setVisible(true);
this.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
}
152
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
public MainFrame() {
//δημιουργία πλήκτρων
createPlateButton = new JButton("Δημιουργία Πιάτου");
addOrderButton = new JButton("Προσθήκη Παραγγελίας");
prepareOrderButton = new JButton("Ετοιμασία Παραγγελίας");
calculateTimeButton = new JButton("Υπολογισμός Χρόνου");
153
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
//δημιουργία πάνελ
panel = new JPanel();
this.setSize(500, 200);
this.setTitle("Κύρια Οθόνη
Συστήματος Διαχείρισης Παραγγελιών");
this.setVisible(true);
this.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
}
}
154
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
Στο παράθυρο είναι επίσης δυνατό να προστεθεί μια εικόνα που υπάρχει
ήδη ως αρχείο GIF ή JPEG ως εξής:
ImageIcon image = new ImageIcon("cook.gif");
JLabel imageLabel = new JLabel(image);
155
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
156
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
157
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
158
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
Στο παρακάτω τμήμα κώδικα που αφορά σε μια κλάση MyFrame που
υλοποιεί ένα παράθυρο και περιλαμβάνει ένα πλήκτρο button (όπως
φαίνεται στο δείγμα εκτέλεσης του σχήματος 8.6), έχει δημιουργηθεί μια
κλάση-ακροατής (ButtonListener), έχει υλοποιηθεί ένας ακροατής
listener ως στιγμιότυπο της κλάσης ButtonListener και έχει συνδεθεί
με το πλήκτρο του παραθύρου ώστε να ακροάται συμβάντα που
σχετίζονται με αυτό (μέσω κλήσης της μεθόδου addActionListener()
στο αντικείμενο button. Ο κώδικας που εκτελείται κάθε φορά που ο
159
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
import javax.swing.*;
import java.awt.event.*;
public MyFrame() {
//υλοποίηση ακροατή
ButtonListener listener = new ButtonListener();
//σύνδεση ακροατή με πηγή συμβάντων (πλήκτρο button)
button.addActionListener(listener);
panel.add(button);
this.setContentPane(panel);
this.pack();
this.setTitle("MyFrame");
this.setVisible(true);
this.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
}
}
160
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
161
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
162
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
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
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
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);
}
164
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
165
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
166
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
public AddOrderFrame() {
selfReference = this;
addOrderButton =
new JButton("Καταχώρηση Παραγγελίας");
addPlateButton = new JButton("Προσθήκη Πιάτου");
ButtonListener buttonListener =
new ButtonListener();
addPlateButton.addActionListener(buttonListener);
addOrderButton.addActionListener(buttonListener);
167
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
//Δημιουργία Παραγγελίας
order = new Order(ID);
ArrayList<String> plateNames =
PlateCatalog.getPlateNames();
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);
}
168
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
169
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
170
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
171
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
172
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
public CreatePlateFrame() {
selfReference = this;
173
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
ArrayList<String> ingredientNames =
IngredientCatalog.getIngredientNames();
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);
this.setContentPane(panel);
this.setSize(500,400);
this.setTitle("Οθόνη Δημιουργίας Πιάτου");
this.setVisible(true);
this.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
}
174
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
175
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
176
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
177
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
public CalculateTimeFrame() {
panel.add(ordersInQueue, BorderLayout.NORTH);
panel.add(calculateTimeButton,
BorderLayout.CENTER);
this.setContentPane(panel);
this.setSize(500,400);
this.setTitle("Οθόνη Υπολογισμού Χρόνου");
this.setVisible(true);
178
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
this.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
}
timeInSecs = Queue.calculateTime(selectedID);
String text = "Εκτιμώμενος χρόνος: " +
timeInSecs;
JOptionPane.showMessageDialog(null, text,
"Εκτιμώμενος Χρόνος",
JOptionPane.INFORMATION_MESSAGE);
}
}
}
179
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
180
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
public PrepareOrderFrame() {
selfReference = this;
preparedButton =
new JButton("Ολοκλήρωση Ετοιμασίας Πιάτου");
finishButton = new JButton("ΕΞΟΔΟΣ");
ButtonListener buttonListener =
new ButtonListener();
preparedButton.addActionListener(buttonListener);
181
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
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);
}
182
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
183
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
184
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
185
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
186
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
9. Συμπεράσματα
Η εφαρμογή της αντικειμενοστρεφούς μεθοδολογίας ανάλυσης και
σχεδίασης κατέδειξε ότι με απλά και συστηματικά βήματα είναι δυνατόν
να μεταβούμε από τις αρχικές απαιτήσεις χρήστη σε ένα λεπτομερές
σχέδιο του συστήματος λογισμικού και εν συνεχεία να υλοποιήσουμε τον
κώδικα. Βεβαίως η διαδικασία αυτή απαιτεί εμπειρία και γνώσεις από την
πλευρά του αναλυτή-σχεδιαστή-προγραμματιστή και για το λόγο αυτό δεν
είναι αυτοματοποιήσιμη. Ωστόσο, η τήρηση των βημάτων της
μεθοδολογίας ICONIX, η αξιοποίηση της Ενοποιημένης Γλώσσας
Μοντελοποίησης για τη δημιουργία των απαραίτητων μοντέλων και η
χρήση σύγχρονων εργαλείων CASE διευκολύνουν σημαντικά τη
διαδικασία ανάπτυξης λογισμικού. Εκτός της παραγωγής λειτουργικού
κώδικα που ικανοποιεί πλήρως τις απαιτήσεις του πελάτη, αξίζει να
σημειωθεί ότι η προσήλωση σε μια μεθοδολογία ανάπτυξης οδηγεί και
στην κατασκευή ποιοτικού λογισμικού, που μπορεί να κατανοηθεί, να
ελεγχθεί, να συντηρηθεί και να επαναχρησιμοποιηθεί με μικρό κόστος και
προσπάθεια.
187
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
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.
10. R. C. Martin, Agile Software Development: Principles, Patterns and
Practices, Prentice Hall, 2003.
188
ΠΛΗ 24 – Σχεδιασμός Λογισμικού
Σύστημα Διαχείρισης Παραγγελιών
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.
189
ΠΛΗ 24 – Σχεδιασμός Λογισμικού