Ανάπτυξη συστήματος λογισμικού βάσει της μεθοδολογίας 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

Σύστημα Διαχείρισης Παραγγελιών 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 3

ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ 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 4

Σύστημα Διαχείρισης Παραγγελιών 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 5

ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ 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 (ανά στάδιο της μεθοδολογίας και ανά περίπτωση χρήσης) 6

Σύστημα Διαχείρισης Παραγγελιών 1. Γνωσιολογικοί Στόχοι 1.1 Σκοπός - Περιεχόμενο Σκοπός της παρούσας μελέτης περίπτωσης που αναλύεται υπό μορφή υπερκειμένου είναι η παρουσίαση των σταδίων ανάπτυξης μιας απλής εφαρμογής διαχείρισης παραγγελιών εστιατορίου σύμφωνα με τη μεθοδολογία ICONIX. Η προσέγγιση έχει ως στόχο αφενός να περιγράψει θεωρητικά τα βήματα της μεθοδολογίας, εστιάζοντας στην καταγραφή των απαιτήσεων, την ανάλυση, τη σχεδίαση αλλά και την υλοποίηση του συστήματος, δηλαδή τη μετάβαση στον κώδικα (στη συγκεκριμένη μελέτη περίπτωσης σε Java). Αφετέρου, παρουσιάζεται η εφαρμογή της μεθοδολογίας στη συγκεκριμένη μελέτη περίπτωσης χρησιμοποιώντας ως εργαλείο τα αντίστοιχα διαγράμματα της Ενοποιημένης Γλώσσας Μοντελοποίησης (UML). Παράλληλα εξετάζεται η αξιολόγηση της ποιότητας του παραγόμενου σχεδίου, θέμα που απασχολεί την ομάδα ανάπτυξης οποιουδήποτε έργου λογισμικού. Τέλος, για την ολοκληρωμένη επίδειξη του συστήματος διαχείρισης παραγγελιών πραγματοποιείται μια συνοπτική επισκόπηση της ανάπτυξης γραφικής διασύνδεσης χρήστη. 7

ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ 1.2 Προσδοκώμενα Αποτελέσματα Μετά την μελέτη του παραδείγματος ο αναγνώστης θα είναι σε θέση: - να κατανοήσει τη χρησιμότητα μιας αντικειμενοστρεφούς μεθοδολογίας ανάπτυξης λογισμικού όπως η ICONIX - να πραγματοποιήσει με συστηματικό τρόπο την αντικειμενοστρεφή ανάλυση και σχεδίαση για ένα πρόβλημα - να χρησιμοποιεί τα διαγράμματα της Ενοποιημένης Γλώσσας Μοντελοποίησης για τη δημιουργία των κατάλληλων μοντέλων σε κάθε φάση της ανάπτυξης - να δημιουργεί κώδικα στην αντικειμενοστρεφή γλώσσα Java βάσει των μοντέλων που ανέπτυξε - να αξιολογεί την ποιότητα της σχεδίασης - να αναπτύσσει τη γραφική διασύνδεση χρήστη - να αξιοποιεί τις δυνατότητες εργαλείων υποστήριξης της διαδικασίας ανάπτυξης 1.3 Λέξεις Κλειδιά Αντικειμενοστρεφής Ανάπτυξη Λογισμικού Ενοποιημένη Γλώσσα Μοντελοποίησης (UML) ICONIX Ανάλυση και Σχεδίαση Μετρικές Λογισμικού Ποιότητα Σχεδίασης Εργαλεία CASE 8

Σύστημα Διαχείρισης Παραγγελιών 2. Εισαγωγή στη Μεθοδολογία ICONIX 2.1 Γενικά Το αντικειμενοστρεφές υπόδειγμα προγραμματισμού είναι ευρέως αποδεκτό ότι προσφέρει πολλά πλεονεκτήματα έναντι άλλων υποδειγμάτων (π.χ. διαδικασιακού). Αυτά σχετίζονται κυρίως με την ευκολία κατανόησης, συντήρησης, ελέγχου και επαναχρησιμοποίησης του λογισμικού. Ωστόσο, τα πλεονεκτήματα αυτά γίνονται εμφανή κυρίως σε έργα λογισμικού μεγάλης κλίμακας. Με τον όρο μεγάλη κλίμακα αναφερόμαστε σε έργα όπου το μείζον πρόβλημα δεν είναι η κατάστρωση των αλγορίθμων και η υλοποίησή τους σε κάποια γλώσσα προγραμματισμού (όπως συμβαίνει στα έργα μικρής κλίμακας) αλλά η δυσκολία επικοινωνίας και συντονισμού μεταξύ των μονάδων του έργου. Ως μονάδες του έργου θεωρούνται αφενός οι μονάδες του λογισμικού (τα φυσικά ή λογικά συστατικά του) που αναπτύσσονται χωριστά και πρέπει να συνεργαστούν για την επίτευξη της ζητούμενης λειτουργικότητας. Αφετέρου, ως μονάδες θεωρούνται και οι εμπλεκόμενοι στη διαδικασία ανάπτυξης, δηλαδή οι πελάτες, οι τελικοί χρήστες, οι αναλυτές, οι σχεδιαστές, οι προγραμματιστές και τα μέλη της διοίκησης της εταιρείας ανάπτυξης. Τα άτομα αυτά, με διαφορετικά ενδιαφέροντα ως προς το έργο και με διαφορετικό υπόβαθρο πρέπει να συντονιστούν και να επικοινωνήσουν αποτελεσματικά, ώστε η ανάπτυξη ενός έργου λογισμικού να είναι επιτυχής. 9

ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ Ένα δεύτερο χαρακτηριστικό έργων μεγάλης κλίμακας είναι η εξελισσόμενη φύση τους. Μία από τις πλέον αποδεκτές "αλήθειες" στην Τεχνολογία Λογισμικού είναι ότι οι απαιτήσεις των πελατών πάντοτε θα αλλάζουν. Η παρατήρηση αυτή αποτυπώνει την αναγκαιότητα για συντήρηση του λογισμικού με την πάροδο του χρόνου. Με τον όρο συντήρηση αναφερόμαστε στον εμπλουτισμό του λογισμικού με νέες δυνατότητες που ανταποκρίνονται στα ζητούμενα των πελατών (τροποποιητική συντήρηση) όσο και στη διόρθωση σφαλμάτων ή ατελειών του λογισμικού καθώς αυτά εντοπίζονται από την εκτεταμένη χρήση του λογισμικού (διορθωτική συντήρηση). Ένα μοντέλο ανάπτυξης λογισμικού είναι επομένως αποτελεσματικό εάν λαμβάνει υπόψη την αναγκαιότητα συνεχούς εξέλιξης του λογισμικού και επιτρέπει τη συντήρησή του με μικρή προσπάθεια και χαμηλό κόστος. Το αντικειμενοστρεφές υπόδειγμα και η χρήση της Ενοποιημένης Γλώσσας Μοντελοποίησης στα πλαίσια κάποιας μεθοδολογίας ανάπτυξης, όπως η ICONIX, παρέχουν τα εργαλεία και τις τεχνικές για την αποτελεσματική διαχείριση των προβλημάτων αυτών σε έργα λογισμικού μεγάλης κλίμακας. Αξίζει να σημειωθεί ότι η χρήση αντικειμενοστρεφούς προσέγγισης σε έργα πολύ μικρής κλίμακας ενδέχεται να μην προσφέρει πλεονεκτήματα αλλά αντίθετα να συνεισφέρει στην πολυπλοκότητα του έργου. 10

Σύστημα Διαχείρισης Παραγγελιών 2.2 ICONIX Η ICONIX είναι μια μεθοδολογία ανάπτυξης λογισμικού που επιτρέπει τη συστηματική μετάβαση από τις αρχικές απαιτήσεις όπως αυτές διατυπώνονται από τον πελάτη, στον κώδικα που τελικά υλοποιεί τις απαιτήσεις αυτές. Είναι μια απλούστερη εκδοχή της ευρέως διαδεδομένης Ενοποιημένης Προσέγγισης (Unified Process). Το μείζον χαρακτηριστικό της μεθοδολογίας ICONIX είναι η επαναληπτικότητα. Αφενός, η διαδικασία είναι επαναληπτική διότι επιτρέπει την παραγωγή λειτουργικού κώδικα για κάθε μια περίπτωση χρήσης του συστήματος ξεχωριστά. Σε κάθε επανάληψη, εξετάζεται μια νέα περίπτωση χρήσης που καταλήγει στην προσθήκη λειτουργικότητας στο τελικό προϊόν. Αφετέρου, η διαδικασία είναι επαναληπτική διότι επιτρέπει (και υποβοηθά) την επιστροφή από ένα στάδιο της διαδικασίας ανάπτυξης (π.χ. το σχεδιασμό) σε προηγούμενα (π.χ. την ανάλυση απαιτήσεων) με σκοπό την αποσαφήνιση, βελτίωση και διόρθωση προηγούμενων ενεργειών. Η επαναληπτικότητα βρίσκεται στο κέντρο του αντικειμενοστρεφούς υποδείγματος προγραμματισμού καθώς αναγνωρίζει ότι ένα μεγάλο σύστημα λογισμικού δεν μπορεί να αναπτυχθεί με μιας και ότι οι αλλαγές σε προηγούμενες επιλογές είναι αναπόφευκτες. Η φιλοσοφία της μεθοδολογίας ICONIX αποτυπώνεται στο διάγραμμα του σχήματος 2.1. Το ζητούμενο είναι από τις απαιτήσεις του χρήστη να παραχθεί το τελικό προϊόν, δηλαδή ο λειτουργικός κώδικας. Ο κώδικας παράγεται με τη διαδοχική εκλέπτυνση και βελτίωση δύο μοντέλων: 11

ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ α) του στατικού μοντέλου που περιγράφει την αρχιτεκτονική του συστήματος, δηλαδή τις δομικές του μονάδες και τις σχέσεις μεταξύ τους και β) του δυναμικού μοντέλου που περιγράφει τον τρόπο με τον οποίο οι μονάδες αλληλεπιδρούν για την επίτευξη της επιθυμητής λειτουργικότητας. Οι απαιτήσεις του πελάτη/χρήστη του συστήματος θεωρείται ότι διατυπώνονται σε κάποιο αρχικό κείμενο (γνωστό ως απαιτήσεις υψηλού επιπέδου) και ενδεχομένως σε κάποια σκίτσα της επιθυμητής γραφικής διασύνδεσης χρήστη. Η μεθοδολογία ICONIX βασίζεται στην αξιοποίηση ενός υποσυνόλου της UML για τη δημιουργία διαγραμμάτων ως ενδιάμεσα προϊόντα κατά την εξέλιξη του δυναμικού και στατικού μοντέλου του συστήματος που αναπτύσσεται. Συγκεκριμένα, από το σύνολο των διαγραμμάτων της UML, χρησιμοποιούνται τα διαγράμματα περιπτώσεων χρήσης, τα διαγράμματα κλάσεων, τα διαγράμματα ευρωστίας (ειδική περίπτωση των διαγραμμάτων συνεργασίας) και τα διαγράμματα ακολουθίας. 12

Καταχώρηση Παραγγελίας Πληροφόρηση Χρόνου ημιουργία Πιάτου Ετοιμασία Πιάτου Κύρια Οθόνη Σύστημα ιαχείρισης Παραγγελιών Εστιατορίου Ενημέρωση Αποθέματος Εκτύπωση Λογαριασμού Παρακολούθηση Οικον.Στοιχείων Ενημέρωση Τιμών Σύστημα Διαχείρισης Παραγγελιών ΥΝΑΜΙΚΟ ΜΟΝΤΕΛΟ ΣΥΣΤΗΜΑΤΟΣ ημιουργία Πιάτου a1:a b1:b c1:c d1:d Ετοιμασία Πιάτου do() m1() m2() Ενημέρωση Αποθέματος ιάγραμμα Περιπτώσεων Χρήσης ιάγραμμα Ευρωστίας ιάγραμμα Ακολουθίας Public class Plate { Προσχέδιο Γραφικής ιασύνδεσης Blah blah Ουρά ΣΤΑΤΙΚΟ ΜΟΝΤΕΛΟ ΣΥΣΤΗΜΑΤΟΣ Ουρά -attr1 : int -attr2 : String Ουρά -attr1 : int -attr2 : String +getfirstorder() private int quantity; private String name;... Κώδικας Απαιτήσεις Πελάτη Παραγγελία Πιάτο Συστατικό Παραγγελία -x1 : int -x2 : double Πιάτο -quantity : int -name : String Συστατικό Παραγγελία -x1 : int -x2 : double +calculatetime() Πιάτο -quantity : int -name : String +isavailable() Συστατικό Μοντέλο Πεδίου Προβλήματος Αναθεωρημένο ιάγραμμα Κλάσεων Τελικό ιάγραμμα Κλάσεων Σχήμα 2.1: Γραφική Επισκόπηση της Μεθοδολογίας ICONIX Από τη στιγμή που οι απαιτήσεις του πελάτη δοθούν στην εταιρεία ανάπτυξης λογισμικού (και η εταιρεία αναλάβει το έργο) η διαδικασία ακολουθεί τις εξής φάσεις: 2.2.1 Ανάλυση Απαιτήσεων Πρώτο βήμα στην ανάλυση των απαιτήσεων είναι η καταγραφή των οντοτήτων του πεδίου που διαπραγματεύεται το σύστημα που πρόκειται να αναπτυχθεί (πεδίο προβλήματος) και των σχέσεων μεταξύ τους. Οι οντότητες αυτές αποτελούν τη βάση του στατικού αντικειμενοστρεφούς μοντέλου καθώς η λειτουργία του λογισμικού βασίζεται στην αλληλεπίδραση μεταξύ τους. Έχοντας το μοντέλο του πεδίου προβλήματος στη διάθεσή μας, επόμενο βήμα στην ανάλυση απαιτήσεων 13

ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ είναι η λεπτομερής και σαφής περιγραφή των απαιτήσεων του πελάτη υπό μορφή περιπτώσεων χρήσης. 2.2.2 Ανάλυση Αρχική Σχεδίαση Σε επίπεδο δυναμικού μοντέλου κύριο εργαλείο στη φάση αυτή είναι τα διαγράμματα ευρωστίας για τη διερεύνηση των ενεργειών που υπαγορεύονται από τις περιπτώσεις χρήσης και κυρίως την βελτίωση του κειμένου των ίδιων των περιπτώσεων χρήσης. Με το πέρας της ανάλυσης ευρωστίας προκύπτει συνήθως ένα αναθεωρημένο και εμπλουτισμένο διάγραμμα κλάσεων (ως μετεξέλιξη του μοντέλου πεδίου προβλήματος) που περιλαμβάνει επιπρόσθετες κλάσεις καθώς και ορισμένες από τις ιδιότητες των κλάσεων. 2.2.3 Σχεδίαση Στη φάση της σχεδίασης επιχειρείται η ακριβής διερεύνηση της δυναμικής συμπεριφοράς του συστήματος και η κατανομή της λειτουργικότητας στις κλάσεις. Κύριο εργαλείο για το σκοπό αυτό είναι τα διαγράμματα ακολουθίας. Με το πέρας της σχεδίασης η ομάδα ανάπτυξης παράγει το τελικό διάγραμμα κλάσεων που αποτελεί την είσοδο για τη φάση της υλοποίησης του λογισμικού. 14

Σύστημα Διαχείρισης Παραγγελιών 2.2.4 Υλοποίηση Το σημαντικότερο προϊόν της διαδικασίας ανάπτυξης δεν είναι φυσικά τα διαγράμματα αλλά ο ίδιος ο κώδικας που ικανοποιεί τις απαιτήσεις του πελάτη. Στη φάση της υλοποίησης αναπτύσσεται ο κώδικας βάσει της σχεδίασης που προηγήθηκε (σε μεγάλο βαθμό υπάρχει η δυνατότητα παραγωγής κώδικα από τα διαγράμματα κλάσεων και ακολουθίας). Παρόλο που δεν εξετάζεται στην παρούσα μελέτη, σημαντικό μέρος της υλοποίησης είναι και ο έλεγχος μονάδων (unit testing) δηλαδή η εξασφάλιση της ορθής λειτουργίας των κλάσεων που δημιουργήθηκαν. Σύμφωνα με τη μεθοδολογία ICONIX αλλά και τις γενικότερες επιταγές της Τεχνολογίας Λογισμικού, στο τέλος κάθε φάσης θα πρέπει να πραγματοποιείται μια συστηματική επισκόπηση (inspection/review). Στις επισκοπήσεις αυτές τα μέλη της ομάδας ανάπτυξης (αλλά ενδεχομένως και εκπρόσωποι του πελάτη ή της διοίκησης) ελέγχουν την ορθότητα των μοντέλων που δημιουργήθηκαν και τη συνέπεια προς τις απαιτήσεις. Στη συνέχεια παρουσιάζονται οι φάσεις ανάπτυξης για ένα έργο λογισμικού που αφορά σε ένα σύστημα διαχείρισης παραγγελιών εστιατορίου. Όπως αναφέρθηκε, η διαδικασία ξεκινά από την αρχική διατύπωση των απαιτήσεων από πλευράς του πελάτη. Σημειώνεται ότι οι προδιαγραφές που τίθενται από το χρήστη (αναφέρονται ως απαιτήσεις υψηλού επιπέδου high level requirements specification) είναι συχνά περιληπτικές, ασαφείς και όχι πλήρεις. 15

ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ 3. Απαιτήσεις Υψηλού Επιπέδου Το λογισμικό που πρόκειται να αναπτυχθεί αφορά σε ένα σύστημα διαχείρισης παραγγελιών σε εστιατόριο. Ο σερβιτόρος, αφού λάβει την παραγγελία από τον πελάτη την εισάγει στο σύστημα. Η παραγγελία μπορεί να περιλαμβάνει πιάτα που έχει ετοιμάσει ο μάγειρας. Η παραγγελία τοποθετείται σε μια ουρά έως ότου ετοιμαστεί από τον μάγειρα. Ο σερβιτόρος μπορεί να μάθει ανά πάσα στιγμή το χρόνο που απαιτείται μέχρι να ετοιμαστεί μια παραγγελία (δίνοντας τον αναγνωριστικό αριθμό της) βάσει της θέσης της στην ουρά. Ο μάγειρας έχει τη δυνατότητα μέσω του συστήματος να δημιουργεί πιάτα καθορίζοντας τα συστατικά που απαιτούνται και τις ποσότητές τους. Επίσης, ο μάγειρας μπορεί να δηλώνει στο σύστημα την ετοιμασία (ολοκλήρωση) κάθε πιάτου που πρέπει να σερβιριστεί. Μόλις ετοιμαστεί ένα πιάτο αφαιρούνται οι αντίστοιχες ποσότητες από το απόθεμα κάθε συστατικού. Μόλις ο μάγειρας ετοιμάσει όλα τα πιάτα μιας παραγγελίας, η παραγγελία απομακρύνεται από την ουρά. (Χάριν απλότητας, θεωρείται ότι τα συστατικά και το απόθεμά τους δεν τροποποιούνται από τους χρήστες του συστήματος. Μπορούν να τροποποιηθούν μόνο προγραμματιστικά με απευθείας επίδραση στον κώδικα. Προφανώς σε ένα πραγματικό σύστημα θα υπήρχε λειτουργικότητα που θα επέτρεπε και την εισαγωγή/διαγραφή συστατικών καθώς και την τροποποίηση του αποθέματος). 16

Σύστημα Διαχείρισης Παραγγελιών 4. Καθορισμός Απαιτήσεων 4.1 Μοντέλο Πεδίου Προβλήματος (Domain Modelling) 4.1.1. Εξαγωγή αρχικής λίστας υποψηφίων κλάσεων Το πρώτο στάδιο ανάπτυξης ενός συστήματος λογισμικού για το οποίο έχουν δοθεί οι προδιαγραφές από τον πελάτη, είναι στη μεθοδολογία ICONIX η κατασκευή του μοντέλου του πεδίου προβλήματος (domain model). Το μοντέλο αυτό είναι μια γραφική απεικόνιση των οντοτήτων/εννοιών (κλάσεις πεδίου) που χρησιμοποιούνται για την περιγραφή των απαιτήσεων του συστήματος καθώς και των σχέσεων μεταξύ τους. Υπάρχουν αρκετές προσεγγίσεις για την εξαγωγή κλάσεων πεδίου από τις απαιτήσεις υψηλού επιπέδου, που περιλαμβάνουν γραμματικήσυντακτική ανάλυση του κειμένου για την εύρεση ουσιαστικών, η χρήση λεξιλογίου από αντίστοιχα συστήματα λογισμικού ή η γνωμοδότηση ειδικών. Σε κάθε περίπτωση προκύπτει μια λίστα εννοιών οι οποίες αποτελούν υποψήφιες κλάσεις πεδίου. Η λίστα διαδοχικά περιορίζεται απομακρύνοντας διπλοεγγραφές, αναφορές σε οντότητες εκτός συστήματος ή στο ίδιο σύστημα, αφηρημένες έννοιες κλπ. Σύμφωνα δε με τις θεμελιώδες αρχές ανάπτυξης αντικειμενοστρεφών συστημάτων αλλά και της μεθοδολογίας ICONIX, το μοντέλο πεδίου προβλήματος που κατασκευάζεται αρχικά ενδέχεται (και αναμένεται) να τροποποιηθεί 17

ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ αρκετές φορές κατά τη διάρκεια των σταδίων της ανάλυσης και σχεδίασης. Από την περιγραφή απαιτήσεων υψηλού επιπέδου που δόθηκε, προκύπτει η ακόλουθη αρχική λίστα ουσιαστικών και πιθανών κλάσεων πεδίου προβλήματος (έχοντας μετατρέψει το πρόσωπο σε πρώτο ενικό): Λίστα Ουσιαστικών Σύστημα διαχείρισης παραγγελιών Ουρά Εστιατόριο Χρόνος Σερβιτόρος Αναγνωριστικό Αριθμός Παραγγελία Θέση (στην Ουρά) Πελάτης Συστατικό Πιάτο Ποσότητα Μάγειρας Απόθεμα 4.1.2 Περιορισμός υποψηφίων κλάσεων Η ανωτέρω λίστα μπορεί να περιοριστεί σημαντικά απαλοίφοντας: Αναφορές στο ίδιο το σύστημα λογισμικού που αναπτύσσουμε (Σύστημα διαχείρισης παραγγελιών) Αναφορές σε χειριστές του συστήματος που πρόκειται να αναπτύξουμε καθώς βρίσκονται "έξω" από τα όρια του συστήματος (Σερβιτόρος, Μάγειρας) Αναφορές σε οντότητες που βρίσκονται εκτός του πεδίου του προβλήματος και κατά συνέπεια δεν πρόκειται να συμμετάσχουν 18

Σύστημα Διαχείρισης Παραγγελιών ως οντότητες στην υλοποίηση των λειτουργιών του συστήματος (Εστιατόριο, Πελάτης). Επισημαίνεται ότι αν υπήρχαν απαιτήσεις που να αναφέρονται σε δυνατότητες ανταλλαγής πληροφοριών μεταξύ των συστημάτων δύο εστιατορίων τότε η κλάση Εστιατόριο θα ήταν υποψήφια κλάση του πεδίου προβλήματος. Ουσιαστικά που πιθανόν να αποτελέσουν ιδιότητες άλλων κλάσεων (Χρόνος, Αναγνωριστικός Αριθμός, Θέση, Ποσότητα, Απόθεμα). Βεβαίως αν προκύψει στη διαδικασία της ανάλυσης ότι κάποιες από αυτές τις οντότητες έχουν λειτουργίες απαραίτητες για το σύστημα, είναι απολύτως επιτρεπτό να εισαχθούν στη συνέχεια στο μοντέλο του πεδίου προβλήματος. Με βάση τις ανωτέρω εξαιρέσεις οι υποψήφιες κλάσεις του πεδίου προβλήματος είναι: Υποψήφιες κλάσεις Παραγγελία Πιάτο Ουρά Συστατικό 19

ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ 4.1.3 Καθορισμός σχέσεων μεταξύ κλάσεων Πρωταρχικός στόχος κατά την κατασκευή του μοντέλου του πεδίου προβλήματος είναι ο εντοπισμός σχέσεων μεταξύ των υποψηφίων κλάσεων Ωστόσο, καθώς στην αντικειμενοστρεφή σχεδίαση υπάρχουν πολλά είδη σχέσεων μεταξύ κλάσεων, δεν κρίνεται σκόπιμο στο στάδιο αυτό να απεικονιστούν ιδιαίτερες λεπτομέρειες. Συνήθως αρκεί η απεικόνιση στο μοντέλο σχέσεων τύπου "έχει" (has) και σχέσεων τύπου "είναι" (is). Το πρώτο είδος αναφέρεται σε σχέσεις περιεκτικότητας μεταξύ δύο κλάσεων που στην απλούστερη μορφή καλούνται συναρμολογήσεις (ή συσσωματώσεις). Μια συναρμολόγηση υποδηλώνει ότι αντικείμενα μιας κλάσης περιέχουν αντικείμενα μιας άλλης κλάσης. Η συναρμολόγηση απεικονίζεται ως μια γραμμή μεταξύ των κλάσεων με έναν λευκό ρόμβο στο άκρο της περιέχουσας κλάσης. Το δεύτερο είδος αναφέρεται σε σχέσεις κληρονομικότητας μεταξύ κλάσεων. Μια σχέση κληρονομικότητας υποδηλώνει ότι μια κλάση (υποκλάση) αποτελεί ειδικότερη κατηγορία μιας άλλης (υπερκλάση) και κληρονομεί τις ιδιότητες και τη συμπεριφορά της. Η κληρονομικότητα απεικονίζεται ως μια γραμμή με ένα τρίγωνο στο άκρο της υπερκλάσης. Από το κείμενο των απαιτήσεων υψηλού επιπέδου προκύπτει ότι μια παραγγελία μπορεί να περιλαμβάνει πιάτα, μια ουρά περιλαμβάνει τις παραγγελίες που τοποθετούνται σε αυτή και ένα πιάτο περιλαμβάνει τα συστατικά από τα οποία αποτελείται. Σχέσεις κληρονομικότητας δεν 20

Σύστημα Διαχείρισης Παραγγελιών εντοπίζονται με βάση την περιγραφή που δόθηκε καθώς δεν υπάρχει κάποια οντότητα που να αποτελεί ειδικότερη κατηγορία κάποιας άλλης. Με βάση τις ανωτέρω πληροφορίες το αρχικό διάγραμμα του πεδίου προβλήματος που προκύπτει, φαίνεται στο σχήμα 4.1. Σχήμα 4.1: Διάγραμμα Πεδίου Προβλήματος (αρχικό) 21

ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ 4.2 Μοντέλο Περιπτώσεων Χρήσης (Use Case Model) 4.2.1 Περιπτώσεις χρήσης Το μοντέλο περιπτώσεων χρήσης είναι μείζονος σημασίας στις αντικειμενοστρεφείς μεθοδολογίες ανάπτυξης λογισμικού όπως η ICONIX και η RUP καθώς θέτει τις βάσεις για τη δημιουργία συστημάτων που δίνουν έμφαση στις απαιτήσεις του πελάτη. Στο μοντέλο περιπτώσεων χρήσης καταγράφονται οι απαιτήσεις των χρηστών διερευνώντας εξαντλητικά όλα τα πιθανά σενάρια χρήσης του συστήματος. Μία περίπτωση χρήσης (use case) είναι μια ακολουθία ενεργειών που ένας χρήστης του συστήματος (συνήθως πρόκειται για άνθρωπο αλλά μπορεί να είναι οποιαδήποτε εξωτερική οντότητα όπως ένα άλλο σύστημα) πραγματοποιεί στο σύστημα για να επιτύχει ένα συγκεκριμένο σκοπό. Μία περίπτωση χρήσης απεικονίζεται διαγραμματικά ως μία έλλειψη, μέσα στην οποία αναγράφεται το όνομα της. Το σύνολο των περιπτώσεων χρήσης ενός συστήματος συνιστούν το διάγραμμα περιπτώσεων χρήσης. Στα διαγράμματα αυτά είναι σημαντικό εκτός από τις περιπτώσεις χρήσης να απεικονιστούν οι χρήστες του συστήματος που συμμετέχουν σε κάθε περίπτωση. Οι χρήστες απεικονίζονται ως σχηματικά ανθρωπάκια (stick persons). Η συσχέτιση μεταξύ χρήστη και περίπτωσης χρήσης απεικονίζεται με μια γραμμή μεταξύ τους (η οποία καλό είναι να μην έχει οποιαδήποτε κατεύθυνση για την αποφυγή παρερμηνειών). Για το σύστημα διαχείρισης παραγγελιών το διάγραμμα περιπτώσεων χρήσης φαίνεται στο σχήμα 4.2. 22

Σύστημα Διαχείρισης Παραγγελιών Σχήμα 4.2: Διάγραμμα Περιπτώσεων Χρήσης Συστήματος Ο ορισμός μιας περίπτωσης χρήσης περιλαμβάνει όλες τις δυνατές συμπεριφορές, περιλαμβανομένης της κανονικής ή βασικής ροής (όπου για παράδειγμα εκτελούνται όλα όσα αναμένει ο χρήστης για την επίτευξη του στόχου) αλλά και όλων των "εναλλακτικών" ροών, όπου κάτι για παράδειγμα αποκλίνει από την "κανονική" συμπεριφορά. Μια περίπτωση χρήσης είναι επιτυχής όταν προδιαγράφει μόνο "ποια" είναι η συμπεριφορά του συστήματος χωρίς καμία αναφορά στο "πώς" αυτή επιτυγχάνεται, χωρίς δηλαδή περιγραφή τεχνικών λεπτομερειών υλοποίησης. 23

ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ 4.2.2 Τεκμηρίωση περιπτώσεων χρήσης Προφανώς, διαγράμματα όπως αυτό του σχήματος 4.2 παρέχουν λίγη πληροφορία σχετικά με τις απαιτήσεις από το σύστημα. Για το λόγο αυτό κάθε περίπτωση χρήσης πρέπει να συνοδεύεται από κατάλληλη τεκμηρίωση, όπου καταγράφονται τόσο η βασική όσο και όλες οι εναλλακτικές ροές. Για την τεκμηρίωση των περιπτώσεων χρήσης συνιστάται η τήρηση των εξής κανόνων: η φιλοσοφία της περιγραφής πρέπει να εστιάζει στην περιγραφή ενός σεναρίου χρήσης ως σύνολο ενεργειών-αποκρίσεων. Με άλλα λόγια, ο χρήστης πραγματοποιεί κάποια ενέργεια, το σύστημα αποκρίνεται, ο χρήστης προβαίνει σε κάποια νέα ενέργεια κ.ο.κ. μέχρις ότου επιτευχθεί ο σκοπός για τον οποίο ο χρήστης αξιοποιεί το σύστημα λογισμικού (Σχήμα 4.3). Σχήμα 4.3: Περίπτωση χρήσης ως σύνολο ενεργειών/αποκρίσεων 24

Σύστημα Διαχείρισης Παραγγελιών οι προτάσεις είναι καλό να είναι γραμμένες σε ενεργητική φωνή, στον ενεστώτα και να έχουν τη μορφή υποκείμενο-ρήμααντικείμενο. Για παράδειγμα, Ο Μάγειρας επιλέγει το πλήκτρο "Δημιουργία Πιάτου". Η μορφή αυτή συμβάλλει στην αποφυγή περιγραφής τεχνικών λεπτομερειών του συστήματος και κυρίως επιτρέπει την ευκολότερη μετάβαση στα επόμενα στάδια της ανάλυσης και σχεδίασης. Στην ιδανική περίπτωση το υποκείμενο και το αντικείμενο κάθε πρότασης αντιστοιχούν σε αντικείμενα των κλάσεων του συστήματος και το ρήμα στο μήνυμα που ανταλλάσσεται μεταξύ τους για την επίτευξη της επιθυμητής λειτουργικότητας. είναι επιθυμητό να χρησιμοποιούνται στη διατύπωση των περιπτώσεων χρήσης όσο το δυνατόν περισσότερο οι όροι του μοντέλου του πεδίου προβλήματος. Λαμβάνοντας υπόψη ότι ένα αντικειμενοστρεφές σύστημα είναι κατ' ουσίαν τα αντικείμενα των κλάσεων του πεδίου προβλήματος (που βεβαίως εξελίσσεται και εμπλουτίζεται), είναι χρήσιμο να διατυπωθούν οι απαιτήσεις του προβλήματος όσο γίνεται πιο πρώιμα με τους όρους αυτών των αντικειμένων. η περιγραφή της περίπτωσης χρήσης μπορεί να περιλαμβάνει αναφορές σε βασικά στοιχεία της γραφικής διασύνδεσης χρήστη (όπως οθόνες, πλήκτρα κλπ). Για το λόγο αυτό, είναι εξαιρετικά χρήσιμο σε πολλές περιπτώσεις, πριν από την καταγραφή των 25

ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ περιπτώσεων χρήσης, να δημιουργηθούν σε συνεργασία με τους τελικούς χρήστες πρόχειρα σχέδια της αναμενόμενης γραφικής διασύνδεσης, τα οποία αναφέρονται στη βιβλιογραφία ως πρωτότυπα (prototypes). Στα πλαίσια αυτά, τα στοιχεία της γραφικής διασύνδεσης (πρωτότυπα) που χρησιμοποιούνται πρέπει να αναφέρονται με κάποιο όνομα και όχι αφηρημένα (π.χ. ο χρήστης εισάγει στην Οθόνη Δημιουργίας Πιάτο το όνομα του πιάτου και όχι ο χρήστης εισάγει σε κάποια οθόνη ). Ωστόσο, δεν θα πρέπει να γίνεται αναφορά σε τεχνικές ή σχεδιαστικές λεπτομέρειες καθώς ο στόχος της χρήσης πρώιμων δειγμάτων της γραφικής διασύνδεσης είναι αποκλειστικά η διερεύνηση των απαιτήσεων του πελάτη. τέλος, σημειώνεται ότι στο στάδιο της καταγραφής των περιπτώσεων χρήσης είναι πολλές φορές κουραστική η αναζήτηση όλων των πιθανών εναλλακτικών ροών που μπορούν να εμφανιστούν σε ένα σενάριο χρήσης. Ωστόσο, κρίνεται ιδιαιτέρως σημαντικό η διερεύνηση αυτή να γίνει σε αυτό το στάδιο, παρά σε μεταγενέστερο στάδιο όπως η σχεδίαση ή η υλοποίηση. Η έγκαιρη διατύπωση όλων των απαιτήσεων είναι κατά πολύ οικονομικότερη και ασφαλέστερη από την τροποποίηση του σχεδίου ή του κώδικα στη συνέχεια. 26

Σύστημα Διαχείρισης Παραγγελιών 4.2.3 Πρότυπα τεκμηρίωσης περιπτώσεων χρήσης Στη βιβλιογραφία έχουν προταθεί διάφορα πρότυπα για την τεκμηρίωση των περιπτώσεων χρήσης. Τα πρότυπα μπορούν να ομαδοποιηθούν σε τρεις γενικές κατηγορίες: 1. Απλές περιγραφές κειμένου χωρίς ιδιαίτερη δομή. Οι υποστηρικτές αυτού του προτύπου δίνουν έμφαση στο ότι οι περιπτώσεις χρήσης πρέπει να εστιάζουν στις απαιτήσεις του πελάτη και να μην εμπλέκουν τον αναλυτή του συστήματος σε άλλες (μη απαιτούμενες) δραστηριότητες. Προτείνεται η περιγραφή να μην ξεπερνά τις δύο παραγράφους ανά περίπτωση χρήσης. Το πρότυπο αυτό χρησιμοποιείται στη συνέχεια για την τεκμηρίωση των περιπτώσεων χρήσης του συστήματος διαχείρισης παραγγελιών. 2. Πιο εκτεταμένες περιγραφές όπου διατυπώνεται ρητά ποια είναι η βασική ροή και ποιες είναι οι εναλλακτικές ροές. Συνήθως χρησιμοποιείται αρίθμηση για κάθε ενέργεια του χρήστη ή απόκριση του συστήματος. Σε περίπτωση εναλλακτικών ροών χρησιμοποιείται ο αντίστοιχος αριθμός για να υποδηλώσει το στάδιο του σεναρίου χρήσης όπου αυτή εφαρμόζεται. Ένα τέτοιο παράδειγμα είναι: 27

ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ Βασική Ροή 1. Ο χρήστης επιλέγει το πλήκτρο "Πληρωμή μέσω Κάρτας" 2. Το σύστημα εμφανίζει την οθόνη "Πληρωμή μέσω Κάρτας" 3. Ο χρήστης εισάγει τον αριθμό της κάρτας και το ποσό και επιλέγει Αποστολή 4. Το σύστημα εμφανίζει μήνυμα ολοκλήρωσης της συναλλαγής Εναλλακτική Ροή 4.α.1 Ο αριθμός της κάρτας δεν είναι έγκυρος 4.α.2 Το σύστημα εμφανίζει μήνυμα σφάλματος 4.α.3 Η περίπτωση χρήσης συνεχίζεται από το βήμα 2 της βασικής ροής 3. Λεπτομερή πρότυπα όπου για κάθε περίπτωση χρήσης αναφέρονται: α. Σύντομη περιγραφή β. Προ-συνθήκες. Συνθήκες που πρέπει να ισχύουν ώστε να είναι δυνατή η έναρξη της περίπτωσης χρήσης. γ. Βασική Ροή δ. Εναλλακτικές Ροές ε. Μετά-συνθήκες. Συνθήκες που θα ισχύουν μετά την ολοκλήρωση της περίπτωσης χρήσης. 28

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

ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ Οι ενδεικτικές οθόνες που παρουσιάζονται στη συνέχεια είναι: η Κύρια Οθόνη της εφαρμογής (που παρουσιάζει στο χρήστη όλες τις δυνατές επιλογές του), η οθόνη "Δημιουργία Πιάτου" που επιτρέπει στο μάγειρα να δημιουργήσει νέα πιάτα, η οθόνη "Προσθήκη Παραγγελίας" που επιτρέπει στο σερβιτόρο να καταχωρήσει στο σύστημα μια νέα παραγγελία, η οθόνη "Ετοιμασία Παραγγελίας" που επιτρέπει στο μάγειρα να δηλώσει στο σύστημα πότε έχει ολοκληρωθεί η ετοιμασία των πιάτων μιας παραγγελίας και η οθόνη "Υπολογισμός Χρόνου" που επιτρέπει στο μάγειρα να υπολογίσει το χρόνο που απομένει μέχρι την ετοιμασία μιας παραγγελίας. 30

Σύστημα Διαχείρισης Παραγγελιών Σχήμα 4.4: Κύρια Οθόνη Σχήμα 4.5: Οθόνη "Δημιουργία Πιάτου" 31

ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ Σχήμα 4.6: Οθόνη "Προσθήκη Παραγγελίας" Σχήμα 4.7: Οθόνη "Ετοιμασία Παραγγελίας" 32

Σύστημα Διαχείρισης Παραγγελιών Σχήμα 4.8: Οθόνη "Υπολογισμός Χρόνου" 4.3 Τεκμηρίωση Περιπτώσεων Χρήσης Στη συνέχεια παρουσιάζεται η τεκμηρίωση των περιπτώσεων χρήσης του συστήματος Διαχείρισης Παραγγελιών σύμφωνα με το πρώτο και το δεύτερο πρότυπο. Η ανάλυση βασίζεται στις προδιαγραφές υψηλού επιπέδου που διατυπώθηκαν από τον πελάτη αλλά και σε (υποθετική) διευκρίνιση ασαφειών που πραγματοποιήθηκε σε συνεργασία με τους τελικούς χρήστες του συστήματος. Χάριν απλότητας, οι εναλλακτικές ροές που έχουν καταγραφεί είναι περιορισμένες. 33

ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ 4.3.1 Περίπτωση Χρήσης 1: Δημιουργία Πιάτου 1ο Πρότυπο Ο Μάγειρας επιλέγει στην Κύρια Οθόνη το πλήκτρο δημιουργία πιάτου. Το σύστημα εμφανίζει την Οθόνη "Δημιουργία Πιάτου" η οποία λαμβάνει τα ονόματα των συστατικών από τον Κατάλογο Συστατικών και τα εμφανίζει. Ταυτόχρονα το σύστημα δημιουργεί το αντίστοιχο Πιάτο. Ο Μάγειρας εισάγει την ονομασία του Πιάτου και στη συνέχεια επιλέγει το πλήκτρο Καταχώρηση Ονόματος. Το σύστημα καταχωρεί το όνομα στο Πιάτο. Στη συνέχεια ο Μάγειρας επιλέγει ένα συστατικό που περιέχει το Πιάτο και εισάγει την αντίστοιχη ποσότητα που απαιτείται. Όταν ο Μάγειρας επιλέξει το πλήκτρο Προσθήκη Συστατικού, το συστατικό που επιλέχθηκε και η αντίστοιχη ποσότητα καταχωρείται στο Πιάτο. Όταν ο Μάγειρας επιλέξει το πλήκτρο Τερματισμός, το Πιάτο εισάγεται στον Κατάλογο Πιάτων και το σύστημα επιστρέφει στην Κύρια Οθόνη. 34

Σύστημα Διαχείρισης Παραγγελιών 2 ο Πρότυπο Βασική Ροή 1. Ο Μάγειρας επιλέγει στην Κύρια Οθόνη το πλήκτρο "δημιουργία πιάτου" 2. Το σύστημα εμφανίζει την Οθόνη "Δημιουργία Πιάτου" η οποία λαμβάνει τα ονόματα των συστατικών από τον Κατάλογο Συστατικών και τα εμφανίζει 3. Το σύστημα δημιουργεί το αντίστοιχο Πιάτο 4. Ο Μάγειρας εισάγει την ονομασία του Πιάτου και στη συνέχεια επιλέγει το πλήκτρο "Καταχώρηση Ονόματος" 5. Το σύστημα καταχωρεί το όνομα στο Πιάτο 6. Ο Μάγειρας επιλέγει ένα συστατικό που περιέχει το Πιάτο και εισάγει την αντίστοιχη ποσότητα που απαιτείται 7. Ο Μάγειρας επιλέγει το πλήκτρο Προσθήκη Συστατικού 8. Το σύστημα καταχωρεί το συστατικό που επιλέχθηκε και την αντίστοιχη ποσότητα στο Πιάτο. τα βήματα 6-8 επαναλαμβάνονται για όσα συστατικά επιθυμεί να επιλέξει ο χρήστης 9. Ο Μάγειρας επιλέγει το πλήκτρο "Τερματισμός" 10. Το σύστημα εισάγει το Πιάτο στον Κατάλογο Πιάτων και επιστρέφει στην Κύρια Οθόνη. 35

ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ 4.3.2 Περίπτωση Χρήσης 2: Προσθήκη Παραγγελίας 1ο Πρότυπο Ο Σερβιτόρος επιλέγει στην Κύρια Οθόνη το πλήκτρο προσθήκη παραγγελίας. Το σύστημα εμφανίζει την οθόνη Προσθήκη Παραγγελίας η οποία λαμβάνει από τον Κατάλογο Πιάτων τα υπάρχοντα Πιάτα και τα εμφανίζει. Ταυτόχρονα το σύστημα δημιουργεί μια νέα Παραγγελία με έναν νέο αύξοντα κωδικό. Στη συνέχεια, ο Σερβιτόρος επιλέγει κάθε Πιάτο που ζητήθηκε και το αντίστοιχο Πιάτο προστίθεται στην Παραγγελία. Όταν η επιλογή Πιάτων ολοκληρωθεί ο Σερβιτόρος επιλέγει το πλήκτρο ολοκλήρωση παραγγελίας, η Παραγγελία καταχωρείται στην Ουρά Παραγγελιών και το σύστημα εμφανίζει την Κύρια Οθόνη. Αν ο Σερβιτόρος επιλέξει Πιάτο όπου κάποιο από τα συστατικά έχει εξαντληθεί, το πιάτο δεν προστίθεται στην παραγγελία και εμφανίζεται μήνυμα προειδοποίησης. 36

Σύστημα Διαχείρισης Παραγγελιών 2ο Πρότυπο Βασική Ροή 1. Ο Σερβιτόρος επιλέγει στην Κύρια Οθόνη το πλήκτρο "προσθήκη παραγγελίας" 2. Το σύστημα εμφανίζει την οθόνη "Προσθήκη Παραγγελίας" η οποία λαμβάνει από τον Κατάλογο Πιάτων τα υπάρχοντα Πιάτα και τα εμφανίζει 3. Το σύστημα δημιουργεί μια νέα Παραγγελία με έναν νέο αύξοντα κωδικό 4. Ο Σερβιτόρος επιλέγει κάθε Πιάτο που ζητήθηκε και πατάει το πλήκτρο "επιλογή" 5. Το σύστημα προσθέτει το επιλεγμένο Πιάτο στην Παραγγελία. Τα βήματα 4, 5 επαναλαμβάνονται για όσα πιάτα επιθυμεί να επιλέξει ο χρήστης 6. Ο Σερβιτόρος επιλέγει το πλήκτρο "ολοκλήρωση παραγγελίας" 7. Το σύστημα καταχωρεί την Παραγγελία στην Ουρά Παραγγελιών και εμφανίζει την Κύρια Οθόνη. Εναλλακτική Ροή 1 4.α.1 Ο Σερβιτόρος επιλέγει Πιάτο όπου κάποιο από τα συστατικά έχει εξαντληθεί 4.α.2 Το πιάτο δεν προστίθεται στην παραγγελία και εμφανίζεται μήνυμα προειδοποίησης 4.α.3. Η περίπτωση χρήσης συνεχίζει από το βήμα 4 της βασικής ροής 37

ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ 4.3.3 Περίπτωση Χρήσης 3: Ετοιμασία Παραγγελίας 1ο Πρότυπο Ο Μάγειρας επιλέγει στην Κύρια Οθόνη το πλήκτρο ετοιμασία παραγγελίας. Το σύστημα εμφανίζει την Οθόνη "Ετοιμασία Παραγγελίας" η οποία λαμβάνει την πρώτη παραγγελία από την Ουρά παραγγελιών και εμφανίζει τα πιάτα που περιλαμβάνει. Ο Μάγειρας επιλέγει κάθε πιάτο και μόλις το ετοιμάσει επιλέγει το πλήκτρο Ολοκλήρωση. Με την ολοκλήρωση ενός πιάτου αφαιρούνται από τα συστατικά που περιέχει το πιάτο οι αντίστοιχες ποσότητες. Όταν ολοκληρωθούν όλα τα πιάτα από μία παραγγελία η παραγγελία αφαιρείται από την Ουρά. Όταν ο Μάγειρας κλείσει την οθόνη το σύστημα επιστρέφει στην Κύρια Οθόνη. 38

Σύστημα Διαχείρισης Παραγγελιών 2ο Πρότυπο Βασική Ροή 1. Ο Μάγειρας επιλέγει στην Κύρια Οθόνη το πλήκτρο ετοιμασία παραγγελίας 2. Το σύστημα εμφανίζει την Οθόνη "Ετοιμασία Παραγγελίας" η οποία λαμβάνει την πρώτη παραγγελία από την Ουρά παραγγελιών και εμφανίζει τα πιάτα που περιλαμβάνει 3. Ο Μάγειρας επιλέγει ένα πιάτο και πατάει το πλήκτρο "Ολοκλήρωση" 4. Το σύστημα αφαιρεί από τα συστατικά που περιέχει το πιάτο τις αντίστοιχες ποσότητες Τα βήματα 3, 4 επαναλαμβάνονται για όλα τα πιάτα της παραγγελίας 5. Όταν ολοκληρωθούν όλα τα πιάτα από μία παραγγελία η παραγγελία αφαιρείται από την Ουρά. 6. Ο Μάγειρας επιλέγει το πλήκτρο "Κλείσιμο" 7. Το σύστημα επιστρέφει στην Κύρια Οθόνη 39

ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ 4.3.4 Περίπτωση Χρήσης 4: Υπολογισμός Χρόνου 1ο Πρότυπο Ο Σερβιτόρος επιλέγει στην Κύρια Οθόνη το πλήκτρο υπολογισμός χρόνου. Το σύστημα εμφανίζει την Οθόνη "Υπολογισμός Χρόνου" η οποία λαμβάνει από την Ουρά τους κωδικούς των παραγγελιών που αναμένουν προς εξυπηρέτηση και τους εμφανίζει. Ο Σερβιτόρος επιλέγει τον κωδικό της παραγγελίας για την οποία επιθυμεί να υπολογίσει τον εκτιμώμενο χρόνο αναμονής και στη συνέχεια επιλέγει το πλήκτρο υπολογισμός χρόνου. Η Ουρά υπολογίζει το χρόνο εντοπίζοντας τη θέση της παραγγελίας που ζητήθηκε και υπολογίζοντας τα πιάτα για τις παραγγελίες που βρίσκονται "μπροστά" από την ζητούμενη παραγγελία. Στη συνέχεια αθροίζει 2 λεπτά για κάθε πιάτο της ζητούμενης παραγγελίας. Το σύστημα εμφανίζει τον εκτιμώμενο χρόνο αναμονής. Όταν ο Σερβιτόρος κλείσει την οθόνη το σύστημα επιστρέφει στην Κύρια Οθόνη. 40

Σύστημα Διαχείρισης Παραγγελιών 2ο Πρότυπο 1. Ο Σερβιτόρος επιλέγει στην Κύρια Οθόνη το πλήκτρο υπολογισμός χρόνου 2. Το σύστημα εμφανίζει την Οθόνη "Υπολογισμός Χρόνου" η οποία λαμβάνει από την Ουρά τους κωδικούς των παραγγελιών που αναμένουν προς εξυπηρέτηση και τους εμφανίζει 3. Ο Σερβιτόρος επιλέγει τον κωδικό της παραγγελίας για την οποία επιθυμεί να υπολογίσει τον εκτιμώμενο χρόνο αναμονής 4. Ο Σερβιτόρος επιλέγει το πλήκτρο "υπολογισμός χρόνου" 5. Η Ουρά υπολογίζει το χρόνο εντοπίζοντας τη θέση της παραγγελίας που ζητήθηκε και υπολογίζοντας τα πιάτα για τις παραγγελίες που βρίσκονται "μπροστά" από την ζητούμενη παραγγελία. Στη συνέχεια αθροίζει 2 λεπτά για κάθε πιάτο της ζητούμενης παραγγελίας 6. Το σύστημα εμφανίζει τον εκτιμώμενο χρόνο αναμονής 7. Ο Σερβιτόρος επιλέγει το πλήκτρο "Κλείσιμο" 8. Το σύστημα επιστρέφει στην Κύρια Οθόνη 41

ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ 5. Ανάλυση 5.1 Ανάλυση Ευρωστίας 5.1.1 Γέφυρα μεταξύ ανάλυσης και σχεδίασης Η ανάλυση ευρωστίας (robustness analysis) αποτελεί μια τεχνική, ενταγμένη στη φάση της ανάλυσης απαιτήσεων, για τη μετάβαση από τις περιπτώσεις χρήσης σε ένα λεπτομερές σχέδιο. Η γεφύρωση του χάσματος μεταξύ της ανάλυσης (που απαντά στο ερώτημα "τι" θα κάνει το σύστημα) και της σχεδίασης (που απαντά στο ερώτημα "πώς" θα ικανοποιηθούν οι απαιτήσεις του πελάτη) αναφέρεται στη μεθοδολογία ICONIX ως ο πρωταρχικός στόχος της ανάλυσης ευρωστίας (Σχήμα 5.1). Ως στάδιο, δεν έχει κάποιο παραδοτέο που να είναι απαραίτητο ή υποχρεωτικό για τη συνέχεια σε άλλες φάσεις της διαδικασίας ανάπτυξης. Είναι όμως μια εξαιρετική τεχνική για την εκλέπτυνση και αποσαφήνιση του κειμένου των περιπτώσεων χρήσης και τον εντοπισμό ενός αρχικού συνόλου αλληλεπιδρώντων αντικειμένων (κλάσεων) για την ικανοποίηση της ζητούμενης λειτουργικότητας. 42

Σύστημα Διαχείρισης Παραγγελιών Σχήμα 5.1: Σημασία της ανάλυσης ευρωστίας στον κύκλο ζωής λογισμικού Κατά την ανάλυση ευρωστίας το κείμενο των περιπτώσεων χρήσης μεταφράζεται σταδιακά (πρόταση προς πρόταση) σε μια γραφική απεικόνιση κλάσεων και συμπεριφοράς (διάγραμμα ευρωστίας). Κάθε οντότητα η οποία σύμφωνα με το μοντέλο πεδίου προβλήματος (ή σύμφωνα με νεότερη κρίση των αναλυτών-σχεδιαστών) αποτελεί μια κλάση του συστήματος, απεικονίζεται στο διάγραμμα ευρωστίας, κατηγοριοποιώντας την με βάση ένα από τα ακόλουθα τρία στερεότυπα κλάσεων: συνοριακές κλάσεις: κλάσεις που αποτελούν διασύνδεση μεταξύ του συστήματος και του "εξωτερικού κόσμου", δηλαδή των χειριστών του κλάσεις οντοτήτων: κλάσεις του μοντέλου πεδίου προβλήματος 43

ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ κλάσεις ελέγχου: κλάσεις που αποτελούν την "κόλλα" μεταξύ των συνοριακών και των κλάσεων οντοτήτων και αναπαριστούν τη συμπεριφορά του συστήματος. Σε ένα διάγραμμα ευρωστίας οι κλάσεις συσχετίζονται μεταξύ τους, υποδηλώνοντας την εννοιολογική συσχέτιση που υπάρχει ή υπονοείται στο κείμενο των περιπτώσεων χρήσης. 5.1.2 Κανόνες σχεδίασης διαγραμμάτων ευρωστίας Κατά τη σχεδίαση διαγραμμάτων ευρωστίας οφείλουν να τηρούνται οι ακόλουθοι τρεις απλοί κανόνες: ουσιαστικά (χειριστές, συνοριακές κλάσεις και κλάσεις οντοτήτων) δεν μπορούν να συσχετίζονται απευθείας με άλλα ουσιαστικά ουσιαστικά μπορούν να συσχετίζονται με ρήματα (κλάσεις ελέγχου) και το αντίθετο ρήματα μπορούν να συσχετίζονται με άλλα ρήματα. Εναλλακτικά, δεν συνιστώνται οι συσχετίσεις που απεικονίζονται στο ακόλουθο σχήμα: 44

Σύστημα Διαχείρισης Παραγγελιών Σχήμα 5.2: Μή συνιστώμενες συσχετίσεις σε διάγραμμα ευρωστίας Οι κανόνες αυτοί ουσιαστικά επιβάλλουν την οργάνωση του κειμένου των περιπτώσεων χρήσης κατά τέτοιο τρόπο ώστε να είναι δυνατή στη συνέχεια η παραγωγή λεπτομερούς σχεδίου υπό μορφή διαγραμμάτων ακολουθίας. 5.2 Διαγράμματα Ευρωστίας Συστήματος Για το υπό ανάπτυξη σύστημα διαχείρισης παραγγελιών τα διαγράμματα ευρωστίας για κάθε περίπτωσης χρήσης είναι (για την πρώτη περίπτωση χρήσης η εξαγωγή του διαγράμματος ευρωστίας εξετάζεται αναλυτικά ενώ για τις υπόλοιπες περιπτώσεις η διαδικασία που ακολουθείται είναι ανάλογη): 45

ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ 5.2.1 Διάγραμμα Ευρωστίας 1: Δημιουργία Πιάτου Η φράση "Ο Μάγειρας επιλέγει στην Κύρια Οθόνη το πλήκτρο δημιουργία πιάτου" απεικονίζεται ως μια ακμή μεταξύ του χρήστη και της συνοριακής κλάσης που αντιστοιχεί στην Κύρια Οθόνη. Η φράση "Το σύστημα εμφανίζει την Οθόνη Δημιουργία Πιάτου" υποδηλώνει την ύπαρξη στο διάγραμμα ευρωστίας μιας συνοριακής κλάσης για την "Οθόνη Δημιουργίας Πιάτου". Τηρώντας τον κανόνα που δεν επιτρέπει την απευθείας συσχέτιση μεταξύ συνοριακών κλάσεων, εισάγεται μια κλάση ελέγχου που αντιστοιχεί στην ενέργεια της εμφάνισης της οθόνης (από την Κύρια Οθόνη), ως απόκριση στην επιλογή του χρήστη. Η φράση "η οποία λαμβάνει τα ονόματα των συστατικών από τον Κατάλογο Συστατικών και τα εμφανίζει" επιβάλλει την εισαγωγή μια κλάσης οντότητας που αντιστοιχεί στον Κατάλογο Συστατικών και μιας κλάσης ελέγχου που αντιστοιχεί στην ενέργεια της λήψης των ονομάτων των συστατικών από τον κατάλογο. Η φράση "Ταυτόχρονα το σύστημα δημιουργεί το αντίστοιχο Πιάτο" οδηγεί στην εισαγωγή στο διάγραμμα μια κλάσης οντότητας που αντιστοιχεί στο Πιάτο και μιας κλάσης ελεγκτή που αντιστοιχεί στην ενέργεια της δημιουργίας ενός στιγμιοτύπου της κλάσης Πιάτο. Παρόλο που η σημειολογία των διαγραμμάτων ευρωστίας δεν είναι αυστηρή, υποθέτουμε ότι η χρονική σειρά των ενεργειών που πραγματοποιείται σε κάποιο σημείο ακολουθεί τη δεξιόστροφη φορά των ακμών που εκβάλλουν από το σημείο αυτό. Με άλλα λόγια θεωρούμε ότι πρώτα πραγματοποιείται η λήψη των συστατικών και η εμφάνισή τους στην 46

Σύστημα Διαχείρισης Παραγγελιών Οθόνη Δημιουργίας Πιάτου και μετά δημιουργείται το αντίστοιχο πιάτο. Ωστόσο, η θεώρηση αυτή δεν είναι δεσμευτική και μπορεί να τροποποιηθεί στη συνέχεια. Η φράση "Ο Μάγειρας εισάγει την ονομασία του Πιάτου και στη συνέχεια επιλέγει το πλήκτρο Καταχώρηση Ονόματος" θα έπρεπε κανονικά να συμβολιστεί ως μια ακμή από το χρήστη προς την Οθόνη Δημιουργίας Πιάτου όπου πραγματοποιούνται αυτές οι ενέργειες. Ωστόσο, αν γινόταν αυτός ο συμβολισμός, δεν θα ήταν σαφές ποια από τις ενέργειες ακμές που εκβάλλουν από τη συνοριακή κλάση Οθόνη Δημιουργίας Πιάτου οφείλεται στην πρώτη ενέργεια του χρήση (επιλογή δημιουργίας πιάτου) και ποια στη δεύτερη (εισαγωγή ονομασίας και επιλογή καταχώρησης). Για το λόγο αυτό επιλέχθηκε ο συμβολισμός της ενέργειας του χρήστη ως ετικέτα στην αντίστοιχη ακμή που καταλήγει στην κλάση ελέγχου Καταχώρηση και τελικά συνδέεται με την κλάση οντότητας Πιάτο για να μοντελοποιήσει το αποτέλεσμα της φράσης "Το σύστημα καταχωρεί το όνομα στο Πιάτο". Οι φράσεις "Στη συνέχεια ο Μάγειρας επιλέγει ένα συστατικό που περιέχει το Πιάτο και εισάγει την αντίστοιχη ποσότητα που απαιτείται" και "Όταν ο Μάγειρας επιλέξει το πλήκτρο Προσθήκη Συστατικού, το συστατικό που επιλέχθηκε και η αντίστοιχη ποσότητα καταχωρείται στο Πιάτο" μοντελοποιούνται ως μια εξερχόμενη ακμή από την Οθόνη Δημιουργίας Πιάτου με ετικέτα "επιλογή συστατικού/ποσότητα και επιλογή καταχώρησης" που καταλήγει στην κλάση ελέγχου Καταχώρηση. Η 47

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

Σύστημα Διαχείρισης Παραγγελιών Visual Paradigm for UML Enterprise Edition(ICT_IVE_TY) Κατάλογος Συστατικών επιλογή ημιουργίας Πιάτου λήψη ονομάτων δημιουργία Μάγειρας Κύρια Οθόνη εμφάνισε εισαγωγή ονόματος και επιλογή καταχώρησης Οθόνη ημιουργίας Πιάτου καταχώρηση Πιάτο επιλογή τερματισμού επιλογή συστατικού/ποσοτήτας και επιλογή προσθήκης εμφάνισε εισαγωγή Πιάτου καταχώρηση Κατάλογος Πιάτων Σχήμα 5.3: Διάγραμμα Ευρωστίας για την Περίπτωση Χρήσης "Δημιουργία Πιάτου" 49

ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ 5.2.2 Διάγραμμα Ευρωστίας 2: Προσθήκη Παραγγελίας Visual Paradigm for UML Enterprise Edition(ICT_IVE_TY) Κατάλογος Πιάτων επιλογή προσθήκης παραγγελίας λήψη ονομάτων Σερβιτόρος Κύρια Οθόνη εμφάνισε Οθόνη Προσθήκης Παραγγελίας δημιουργία ολοκλήρωση παραγγελίας εμφάνισε καταχώρηση επιλογή Πιάτου Παραγγελία Πιάτο Ουρά υπάρχουν συστατικά? ναι καταχώρηση όχι εμφάνισε Μήνυμα Προειδοποίησης Σχήμα 5.4: Διάγραμμα Ευρωστίας για την Περίπτωση Χρήσης "Προσθήκη Παραγγελίας" 50

Σύστημα Διαχείρισης Παραγγελιών 5.2.3 Διάγραμμα Ευρωστίας 3: Ετοιμασία Παραγγελίας Visual Paradigm for UML Enterprise Edition(ICT_IVE_TY) επιλογή ετοιμασία παραγγελίας εμφάνισε λήψη πρώτης παραγγελίας Ουρά Μάγειρας Κύρια Οθόνη Συστατικό Οθόνη Ετοιμασίας Παραγγελίας επιλογή τερματισμού επιλογή πιάτου και ολοκλήρωση λήψη Πιάτων αφαίρεση ποσότητας εμφάνισε επιλογή πιάτου Παραγγελία αφαίρεση συστατικών Πιάτο ολοκλήρωση όλων των πιάτων; ΝΑΙ αφαίρεση παραγγελίας Σχήμα 5.5: Διάγραμμα Ευρωστίας για την Περίπτωση Χρήσης "Ετοιμασία Παραγγελίας" 51

ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ 5.2.4 Διάγραμμα Ευρωστίας 4: Υπολογισμός Χρόνου Visual Paradigm for UML Enterprise Edition(ICT_IVE_TY) Σερβιτόρος επιλογή Υπολογισμού Χρόνου Κύρια Οθόνη εμφάνισε λήψη παραγγελιών επιλογή κωδικού παραγγελίας και πλήκτρου υπολογισμού Ουρά εύρεση θέσης παραγγελίας επιλογή τερματισμού Οθόνη Υπολογισμού Χρόνου υπολογισμός χρόνου εμφάνισε υπολογισμός πιάτων που αναμένουν άθροιση χρόνων εκτιμώμενος χρόνος εμφάνισε Σχήμα 5.6: Διάγραμμα Ευρωστίας για την Περίπτωση Χρήσης "Υπολογισμός Χρόνου" 5.3 Αναθεώρηση του μοντέλου πεδίου προβλήματος Από τη διερεύνηση των περιπτώσεων χρήσης και τη δημιουργία των διαγραμμάτων ευρωστίας είναι αναμενόμενο και επιθυμητό να εντοπιστούν νέες κλάσεις που δεν συμπεριελήφθησαν αρχικά στο μοντέλο πεδίου προβλήματος. Επίσης, το στάδιο της ανάλυσης οδηγεί και στον εντοπισμό ορισμένων από τις ιδιότητες των κλάσεων καθώς αυτές είτε αναφέρονται ρητά στο κείμενο των περιπτώσεων χρήσης αλλά επιλέγεται να μην αντιστοιχισθούν σε κλάσεις του συστήματος είτε υπονοούνται. Για το σύστημα που αναπτύσσεται, το μοντέλου του πεδίου προβλήματος εμπλουτίζεται ως εξής (καθώς από το εξελισσόμενο διάγραμμα κλάσεων πρόκειται να παραχθεί ένα μεγάλο τμήμα του κώδικα κρίνεται σκόπιμο 52

Σύστημα Διαχείρισης Παραγγελιών από το σημείο αυτό και μετά να παρατίθενται και οι αγγλικοί όροι για τις ονομασίες κλάσεων, ιδιοτήτων και μεθόδων): Από την περίπτωση χρήσης 1 και το αντίστοιχο διάγραμμα ευρωστίας προκύπτει ότι στο μοντέλο πεδίου προβλήματος πρέπει να συμπεριληφθεί η κλάση Κατάλογος Συστατικών (IngredientCatalog) και η κλάση Κατάλογος Πιάτων (PlateCatalog). Τέτοιες κλάσεις, που λειτουργούν ως συλλογές αντικειμένων κλάσεων οντοτήτων είναι αναμενόμενες στις περισσότερες εφαρμογές, ακόμα και αν δεν αναφέρονται ρητά στις απαιτήσεις, καθώς επιτρέπουν τον εντοπισμό και την ανάκτηση των αντικειμένων των κλάσεων οντοτήτων. Οι δύο αυτές κλάσεις περιλαμβάνουν αντικείμενα των κλάσεων Συστατικό (Ingredient) και Πιάτο (Plate) αντίστοιχα, και για το λόγο αυτό συνδέονται με σχέση συναρμολόγησης με αυτές με πολλαπλότητα πολλά στο άκρο των κλάσεων οντοτήτων. Από το ίδιο διάγραμμα ευρωστίας προκύπτει ότι η κλάση Συστατικό καθώς και η κλάση Πιάτο θα περιλαμβάνουν μια ιδιότητα όνομα (name) καθώς τα ονόματα των συστατικών εμφανίζονται στην Οθόνη Δημιουργίας Πιάτου ενώ ο χρήστης ρητά αναφέρεται ότι εισάγει το όνομα κάθε πιάτου που δημιουργεί. Ακολουθώντας την αρχή της ενσωμάτωσης που επιβάλλει η πρόσβαση στις ιδιότητες ενός αντικειμένου να πραγματοποιείται μόνο μέσω της δημόσιας διασύνδεσης της κλάσης, όλες οι ιδιότητες μιας κλάσης ορίζονται να έχουν ορατότητα ιδιωτική (private). Η ιδιωτική ορατότητα υποδηλώνεται στο διάγραμμα κλάσεων της UML με ένα σύμβολο '-' πριν από το όνομα κάθε ιδιότητας. 53

ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ Αξίζει να σημειωθεί ότι στο στάδιο της ανάλυσης δεν είναι απαραίτητο να απεικονίζονται στο διάγραμμα κλάσεων οι τύποι δεδομένων κάθε ιδιότητας. Η σύμβαση που ακολουθείται είναι τα ονόματα κλάσεων να ξεκινούν με κεφαλαίο γράμμα, ενώ τα ονόματα των ιδιοτήτων και μεθόδων να ξεκινούν με πεζό γράμμα. Από την περίπτωση χρήσης 2 προκύπτει ότι κατά τη δημιουργία μιας νέας παραγγελίας καταχωρείται σε αυτήν ένας νέος αύξοντας κωδικός και επομένως μια ιδιότητα κωδικός (code) προστίθεται στην κλάση Παραγγελία (Order). Από την περίπτωση χρήσης 3 και το αντίστοιχο διάγραμμα ευρωστίας συνάγεται ότι κατά την ετοιμασία ενός πιάτου αφαιρούνται από τα συστατικά που περιέχει οι αντίστοιχες ποσότητες. Επομένως στην κλάση Συστατικό προστίθεται μια ιδιότητα ποσότητα (amount). Στο αναθεωρημένο μοντέλο του πεδίου προβλήματος σημειώνονται πλέον και σύμβολα πολλαπλότητας στις σχέσεις συναρμολόγησης. Το αναθεωρημένο διάγραμμα απεικονίζεται στο σχήμα 5.7. 54