ICONIX Μεθοδολογία Αντικειμενοστρεφούς

Παρουσίαση με θέμα: "ICONIX Μεθοδολογία Αντικειμενοστρεφούς"— Μεταγράφημα παρουσίασης:

1 ICONIX Μεθοδολογία Αντικειμενοστρεφούς
Ανάλυσης και Σχεδίασης Λογισμικού: ICONIX Μελέτη Περίπτωσης: Σύστημα Διαχείρισης Παραγγελιών Εστιατορίου Αλέξανδρος Χατζηγεωργίου, Τμήμα Εφαρμοσμένης Πληροφορικής, Πανεπιστήμιο Μακεδονίας

2 ICONIX...ορισμός Mεθοδολογία ανάπτυξης λογισμικού:
συστηματική μετάβαση από αρχικές απαιτήσεις στον κώδικα Mείζον χαρακτηριστικό: επαναληπτικότητα παραγωγή λειτουργικού κώδικα ανά περίπτωση χρήσης επιτρέπει την επιστροφή από ένα στάδιο της διαδικασίας ανάπτυξης σε προηγούμενα Η επαναληπτικότητα βρίσκεται στο κέντρο του αντικειμενοστρεφούς υποδείγματος προγραμματισμού: ένα μεγάλο σύστημα λογισμικού δεν μπορεί να αναπτυχθεί με μιας και ότι οι αλλαγές σε προηγούμενες επιλογές είναι αναπόφευκτες.

3 ICONIX...ορισμός use case driven approach
- αξιοποίηση UML: αποφυγή analysis paralysis

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

5 Ανάλυση – Αρχική Σχεδίαση
Κύριο εργαλείο στη φάση αυτή: διαγράμματα ευρωστίας διερεύνηση των ενεργειών που υπαγορεύονται από τις περιπτώσεις χρήσης βελτίωση του κειμένου των ίδιων των περιπτώσεων χρήσης Αποτέλεσμα: αναθεωρημένο και εμπλουτισμένο διάγραμμα κλάσεων επιπρόσθετες κλάσεις ιδιότητες κλάσεων

6 Σχεδίαση Ακριβής διερεύνηση της δυναμικής συμπεριφοράς του συστήματος = κατανομή της λειτουργικότητας στις κλάσεις Κύριο εργαλείο: διαγράμματα ακολουθίας Αποτέλεσμα: τελικό διάγραμμα κλάσεων που αποτελεί την είσοδο για τη φάση της υλοποίησης του λογισμικού.

7 Υλοποίηση Το σημαντικότερο προϊόν της διαδικασίας ανάπτυξης: κώδικας
Ο κώδικας αναπτύσσεται βάσει του διαγράμματος κλάσεων που παρήχθει: βελτιώσεις και προσθήκες είναι αναμενόμενο να υπάρχουν Η μεθοδολογία ICONIX αφορά κυρίως στις κλάσεις της επιχειρηματικής λογικής του συστήματος (business logic). Η γραφική διασύνδεση χρήστη υπάγεται σε ξεχωριστά μοντέλα ανάπτυξης Σημαντικό μέρος της υλοποίησης είναι η εξασφάλιση της ορθής λειτουργίας των κλάσεων που δημιουργήθηκαν

8 Εφαρμογή Μεθοδολογίας ICONIX σε
Μελέτη Περίπτωσης: Εφαρμογή Μεθοδολογίας ICONIX σε Σύστημα Διαχείρισης Παραγγελιών Εστιατορίου

9 Απαιτήσεις Υψηλού Επιπέδου
Το λογισμικό που πρόκειται να αναπτυχθεί αφορά σε ένα σύστημα διαχείρισης παραγγελιών σε εστιατόριο. Ο σερβιτόρος, αφού λάβει την παραγγελία από τον πελάτη την εισάγει στο σύστημα. Η παραγγελία μπορεί να περιλαμβάνει πιάτα που έχει ετοιμάσει ο μάγειρας. Η παραγγελία τοποθετείται σε μια ουρά έως ότου ετοιμαστεί από τον μάγειρα. Ο σερβιτόρος μπορεί να μάθει ανά πάσα στιγμή το χρόνο που απαιτείται μέχρι να ετοιμαστεί μια παραγγελία (δίνοντας τον αναγνωριστικό αριθμό της) βάσει της θέσης της στην ουρά.

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

11 Καθορισμός Απαιτήσεων
Μοντέλο Πεδίου Προβλήματος (Domain Modelling) Εξαγωγή αρχικής λίστας υποψηφίων κλάσεων Λίστα Ουσιαστικών Σύστημα διαχείρισης παραγγελιών Ουρά Εστιατόριο Χρόνος Σερβιτόρος Αναγνωριστικό Αριθμός Παραγγελία Θέση (στην Ουρά) Πελάτης Συστατικό Πιάτο Ποσότητα Μάγειρας Απόθεμα

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

13 Καθορισμός Απαιτήσεων
Υποψήφιες κλάσεις Παραγγελία Πιάτο Ουρά Συστατικό

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

15 Καθορισμός Απαιτήσεων
Μοντέλο Περιπτώσεων Χρήσης Μία περίπτωση χρήσης (use case) είναι μια ακολουθία ενεργειών που ένας χρήστης του συστήματος (συνήθως πρόκειται για άνθρωπο αλλά μπορεί να είναι οποιαδήποτε εξωτερική οντότητα όπως ένα άλλο σύστημα) πραγματοποιεί στο σύστημα για να επιτύχει ένα συγκεκριμένο σκοπό.

16 Καθορισμός Απαιτήσεων
Ο ορισμός μιας περίπτωσης χρήσης περιλαμβάνει όλες τις δυνατές συμπεριφορές, περιλαμβανομένης της κανονικής ή βασικής ροής (όπου για παράδειγμα εκτελούνται όλα όσα αναμένει ο χρήστης για την επίτευξη του στόχου) και όλων των "εναλλακτικών" ροών, όπου κάτι για παράδειγμα αποκλίνει από την "κανονική" συμπεριφορά. Μια περίπτωση χρήσης είναι επιτυχής όταν προδιαγράφει μόνο "ποια" είναι η συμπεριφορά του συστήματος χωρίς καμία αναφορά στο "πώς" αυτή επιτυγχάνεται, χωρίς δηλαδή περιγραφή τεχνικών λεπτομερειών υλοποίησης. .

17 Τεκμηρίωση Περιπτώσεων Χρήσης - Κανόνες
Περιγραφή ενός σεναρίου χρήσης ως σύνολο ενεργειών-αποκρίσεων. Με άλλα λόγια, ο χρήστης πραγματοποιεί κάποια ενέργεια, το σύστημα αποκρίνεται, ο χρήστης προβαίνει σε κάποια νέα ενέργεια κ.ο.κ. μέχρις ότου επιτευχθεί ο σκοπός για τον οποίο ο χρήστης αξιοποιεί το σύστημα .

18 Τεκμηρίωση Περιπτώσεων Χρήσης
οι προτάσεις είναι καλό να είναι γραμμένες σε ενεργητική φωνή, στον ενεστώτα και να έχουν τη μορφή υποκείμενο-ρήμα-αντικείμενο. Για παράδειγμα: Ο Μάγειρας επιλέγει το πλήκτρο "Δημιουργία Πιάτου". Η μορφή αυτή συμβάλλει στην αποφυγή περιγραφής τεχνικών λεπτομερειών του συστήματος και κυρίως επιτρέπει την ευκολότερη μετάβαση στα επόμενα στάδια της ανάλυσης και σχεδίασης. Στην ιδανική περίπτωση το υποκείμενο και το αντικείμενο κάθε πρότασης αντιστοιχούν σε αντικείμενα των κλάσεων του συστήματος και το ρήμα στο μήνυμα που ανταλλάσσεται μεταξύ τους για την επίτευξη της επιθυμητής λειτουργικότητας.

19 Τεκμηρίωση Περιπτώσεων Χρήσης
είναι επιθυμητό να χρησιμοποιούνται στη διατύπωση των περιπτώσεων χρήσης όσο το δυνατόν περισσότερο οι όροι του μοντέλου του πεδίου προβλήματος. Η περιγραφή μπορεί να περιλαμβάνει αναφορές σε βασικά στοιχεία της γραφικής διασύνδεσης χρήστη Για το λόγο αυτό, είναι χρήσιμο πριν από την καταγραφή των περιπτώσεων χρήσης, να δημιουργηθούν σε συνεργασία με τους τελικούς χρήστες πρόχειρα σχέδια της αναμενόμενης γραφικής διασύνδεσης Τα στοιχεία της γραφικής διασύνδεσης πρέπει να αναφέρονται με κάποιο όνομα και όχι αφηρημένα (π.χ. ο χρήστης εισάγει στην Οθόνη Δημιουργίας Πιάτο το όνομα του πιάτου και όχι ο χρήστης εισάγει σε κάποια οθόνη…). Ο στόχος της χρήσης πρώιμων δειγμάτων γραφικής διασύνδεσης είναι αποκλειστικά η διερεύνηση των απαιτήσεων του πελάτη.

20 Τεκμηρίωση Περιπτώσεων Χρήσης
Η αναζήτηση όλων των πιθανών εναλλακτικών ροών που μπορούν να εμφανιστούν σε ένα σενάριο χρήσης είναι ιδιαιτέρως κοπιαστική. Ωστόσο, είναι σημαντικό η διερεύνηση αυτή να γίνει σε αυτό το στάδιο, παρά σε μεταγενέστερο στάδιο όπως η σχεδίαση ή η υλοποίηση. Η έγκαιρη διατύπωση όλων των απαιτήσεων είναι κατά πολύ οικονομικότερη και ασφαλέστερη από την τροποποίηση του σχεδίου ή του κώδικα στη συνέχεια.

21 Πρότυπα Τεκμηρίωσης Απλές περιγραφές κειμένου χωρίς ιδιαίτερη δομή.
Οι υποστηρικτές αυτού του προτύπου δίνουν έμφαση στο ότι οι περιπτώσεις χρήσης πρέπει να εστιάζουν στις απαιτήσεις του πελάτη και να μην εμπλέκουν τον αναλυτή του συστήματος σε άλλες (μη απαιτούμενες) δραστηριότητες. Προτείνεται η περιγραφή να μην ξεπερνά τις δύο παραγράφους ανά περίπτωση χρήσης.

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

23 Πρότυπα Τεκμηρίωσης 3. Λεπτομερή πρότυπα όπου για κάθε περίπτωση χρήσης αναφέρονται: α. Σύντομη περιγραφή β. Προ-συνθήκες. Συνθήκες που πρέπει να ισχύουν ώστε να είναι δυνατή η έναρξη της περίπτωσης χρήσης. γ. Βασική Ροή δ. Εναλλακτικές Ροές ε. Μετά-συνθήκες. Συνθήκες που θα ισχύουν μετά την ολοκλήρωση της περίπτωσης χρήσης.

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

25 Κύρια Οθόνη

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

27 Οθόνη Προσθήκης Παραγγελίας

28 Οθόνη Ετοιμασίας Παραγγελίας

29 Οθόνη Υπολογισμού Χρόνου

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

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

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

33 Περίπτωση Χρήσης 3: Ετοιμασία Παραγγελίας
Βασική Ροή Ο Μάγειρας επιλέγει στην Κύρια Οθόνη το πλήκτρο ετοιμασία παραγγελίας Το σύστημα εμφανίζει την Οθόνη "Ετοιμασία Παραγγελίας" η οποία λαμβάνει την πρώτη παραγγελία από την Ουρά παραγγελιών και εμφανίζει τα πιάτα που περιλαμβάνει Ο Μάγειρας επιλέγει ένα πιάτο και πατάει το πλήκτρο "Ολοκλήρωση" Το σύστημα αφαιρεί από τα συστατικά που περιέχει το πιάτο τις αντίστοιχες ποσότητες Τα βήματα 3, 4 επαναλαμβάνονται για όλα τα πιάτα της παραγγελίας Όταν ολοκληρωθούν όλα τα πιάτα από μία παραγγελία η παραγγελία αφαιρείται από την Ουρά. Ο Μάγειρας επιλέγει το πλήκτρο "Κλείσιμο" Το σύστημα επιστρέφει στην Κύρια Οθόνη

34 Περίπτωση Χρήσης 4: Υπολογισμός Χρόνου
Βασική Ροή Ο Σερβιτόρος επιλέγει στην Κύρια Οθόνη το πλήκτρο υπολογισμός χρόνου Το σύστημα εμφανίζει την Οθόνη "Υπολογισμός Χρόνου" η οποία λαμβάνει από την Ουρά τους κωδικούς των παραγγελιών που αναμένουν προς εξυπηρέτηση και τους εμφανίζει Ο Σερβιτόρος επιλέγει τον κωδικό της παραγγελίας για την οποία επιθυμεί να υπολογίσει τον εκτιμώμενο χρόνο αναμονής Ο Σερβιτόρος επιλέγει το πλήκτρο "υπολογισμός χρόνου" Η Ουρά υπολογίζει το χρόνο εντοπίζοντας τη θέση της παραγγελίας που ζητήθηκε και υπολογίζοντας τα πιάτα για τις παραγγελίες που βρίσκονται "μπροστά" από την ζητούμενη παραγγελία. Στη συνέχεια αθροίζει 2 λεπτά για κάθε πιάτο της ζητούμενης παραγγελίας Το σύστημα εμφανίζει τον εκτιμώμενο χρόνο αναμονής Ο Σερβιτόρος επιλέγει το πλήκτρο "Κλείσιμο" Το σύστημα επιστρέφει στην Κύρια Οθόνη

35 Ανάλυση Ανάλυση Ευρωστίας (Robustness Analysis)
Η ανάλυση ευρωστίας αποτελεί μια τεχνική, ενταγμένη στη φάση της ανάλυσης απαιτήσεων, για τη μετάβαση από τις περιπτώσεις χρήσης σε ένα λεπτομερές σχέδιο. Στόχος: Η γεφύρωση του χάσματος μεταξύ της ανάλυσης (που απαντά στο ερώτημα "τι" θα κάνει το σύστημα) και της σχεδίασης (που απαντά στο ερώτημα "πώς" θα ικανοποιηθούν οι απαιτήσεις του πελάτη) αναφέρεται στη μεθοδολογία ICONIX ως ο πρωταρχικός στόχος της ανάλυσης ευρωστίας

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

37 Διαγράμματα Ευρωστίας
Κατά τη σχεδίαση διαγραμμάτων ευρωστίας οφείλουν να τηρούνται οι ακόλουθοι τρεις απλοί κανόνες: ουσιαστικά (χειριστές, συνοριακές κλάσεις και κλάσεις οντοτήτων) δεν μπορούν να συσχετίζονται απευθείας με άλλα ουσιαστικά ουσιαστικά μπορούν να συσχετίζονται με ρήματα (κλάσεις ελέγχου) και το αντίθετο ρήματα μπορούν να συσχετίζονται με άλλα ρήματα

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

39 Περίπτωση Χρήσης 1

40 Περίπτωση Χρήσης 2

41 Περίπτωση Χρήσης 3

42 Περίπτωση Χρήσης 4

43 Αναθεώρηση του domain model
Από τη διερεύνηση των διαγραμμάτων ευρωστίας είναι αναμενόμενο και επιθυμητό να εντοπιστούν νέες κλάσεις Επίσης, το στάδιο της ανάλυσης οδηγεί και στον εντοπισμό ορισμένων από τις ιδιότητες των κλάσεων καθώς αυτές είτε αναφέρονται ρητά στο κείμενο των περιπτώσεων χρήσης αλλά επιλέγεται να μην αντιστοιχισθούν σε κλάσεις του συστήματος είτε υπονοούνται. Για παράδειγμα:

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

45 Αναθεώρηση του domain model

46 Σχεδίαση Κατανομή λειτουργικότητας
Με την ολοκλήρωση της ανάλυσης οι προδιαγραφές του συστήματος έχουν παγιωθεί και μπορούν να θεωρηθούν πλήρεις, ορθές, λεπτομερείς και σαφείς. Επιπλέον έχουν εντοπιστεί οι περισσότερες κλάσεις, δηλαδή ολοκληρώθηκε το μεγαλύτερο τμήμα της στατικής δομής του λογισμικού. Ωστόσο, λίγες ενέργειες στη φάση της ανάλυσης είχαν ως στόχο την κατανομή της συμπεριφοράς στις κλάσεις του συστήματος. Ο ακριβής καθορισμός του τρόπου με τον οποίο οι κλάσεις (τα αντικείμενά τους) αλληλεπιδρούν μεταξύ τους, δηλαδή ο προσδιορισμός μέρους της δυναμικής συμπεριφοράς του συστήματος, αποτελούν αντικείμενο της σχεδίασης. Ως επακόλουθο αυτής της κατανομής λειτουργικότητας προκύπτει το αναθεωρημένο διάγραμμα κλάσεων όπου εκτός από τις κλάσεις και τις ιδιότητές τους, απεικονίζονται οι μέθοδοί τους

47 Σχεδίαση Η κατανομή της λειτουργικότητας επιτυγχάνεται με την κατάστρωση διαγραμμάτων ακολουθίας. Ένα διάγραμμα ακολουθίας απεικονίζει τα μηνύματα που ανταλλάσσουν τα αντικείμενα του συστήματος μεταξύ τους για την ικανοποίηση της λειτουργικότητας ενός σεναρίου Στα πλαίσια του αντικειμενοστρεφούς μοντέλου ένα μήνυμα προς ένα αντικείμενο A αντιστοιχεί σε αίτημα για την εκτέλεση μιας λειτουργίας από πλευράς του Α.

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

49 Εναλλακτικές

50 Βρόχοι (UML 2.0)

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

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

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

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

55 Στατικό μοντέλο συστήματος
Ο κύριος σκοπός δημιουργίας των διαγραμμάτων ακολουθίας είναι η κατανομή της λειτουργικότητας (μεθόδων) στις κλάσεις και ο εντοπισμός τυχόν νέων κλάσεων, ιδιοτήτων και μεθόδων που δεν αναδείχθηκαν στο στάδιο της ανάλυσης. Η λήψη ενός μηνύματος από ένα αντικείμενο μιας κλάσης σε ένα διάγραμμα ακολουθίας υποδηλώνει την ύπαρξη μιας μεθόδου στην κλάση που είναι ο αποδέκτης του μηνύματος. Η μέθοδος συνιστά τη λειτουργία που θα εκτελείται στην κλάση-αποδέκτη με τη λήψη του αντίστοιχου μηνύματος.

56 Εξαγωγή μεθόδων συστήματος - 1
Από το διάγραμμα ακολουθίας που αφορά στην περίπτωση χρήσης 1 προκύπτουν οι εξής μέθοδοι για τις κλάσεις (εξαιρώντας τις συνοριακές κλάσεις): Συστατικό (Ingredient) Πιάτο (Plate) Κατάλογος Συστατικών (IngredientCatalog) Κατάλογος Πιάτων (Plate Catalog) λήψη ονόματος getName() καταχώρηση ονόματος (όνομα) setPlateName(String) λήψη ονομάτων getIngredientNames() καταχώρηση (Πιάτο) add(Plate) καταχώρηση(συστατικό, ποσότητα) storeIngredient( Ingredient, int)

57 Συστατικό (Ingredient)
Εξαγωγή μεθόδων συστήματος - 2 Από το διάγραμμα ακολουθίας που αφορά στην περίπτωση χρήσης 2 προκύπτουν οι εξής μέθοδοι για τις κλάσεις (εξαιρώντας τις συνοριακές κλάσεις): Παραγγελία (Order) Πιάτο (Plate) Ουρά (Queue) Συστατικό (Ingredient) Κατάλογος Πιάτων (Plate Catalog) καταχώρηση (Πιάτο) addPlate λήψη ονόματος getName() καταχώρηση (Παραγγελία) add(Order) έλεγχος ποσότητας (ποσότητα) checkQuantity (int) λήψη ονομάτων getPlate-Names() έλεγχος διαθεσιμότητας isAvailable() Ομοίως και για τις άλλες δύο περιπτώσεις χρήσης

58 Αναθεωρημένο διάγραμμα κλάσεων
Με βάση τις 23 μεθόδους που εντοπίστηκαν είναι πλέον δυνατόν να προκύψει το αναθεωρημένο διάγραμμα κλάσεων Το διάγραμμα κλάσεων του συστήματος προκύπτει προσθέτοντας μία προς μία τις μεθόδους που αναφέρονται στους ανωτέρω πίνακες με δημόσια ορατότητα (public visibility). Ο επιστρεφόμενος τύπος αν είναι void χάριν απλότητας παραλείπεται ενώ στις υπόλοιπες περιπτώσεις σημειώνεται στο UML διάγραμμα. Επίσης, στο στάδιο της σχεδίασης είναι χρήσιμο να απεικονιστούν και πληροφορίες όπως ο τύπος δεδομένων για όσες ιδιότητες είναι γνωστός. Σημειώνεται ότι παρόλο που μέθοδοι πρόσβασης ιδιοτήτων (μέθοδοι get() και set()) δεν απεικονίζονται συνήθως, στο διάγραμμα κλάσεων του συστήματος που αναπτύσσεται απεικονίζονται τέτοιες μέθοδοι αν έχουν προκύψει από τα διαγράμματα ακολουθίας ώστε να υπάρχει η δυνατότητα ιχνηλάτησης (δηλαδή η δυνατότητα ελέγχου της αντιστοίχισης μεθόδων στις κλάσεις και μηνυμάτων στα διαγράμματα ακολουθίας).

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

60 Αναθεωρημένο διάγραμμα κλάσεων – με GUI

61 Αναθεωρημένο διάγραμμα κλάσεων
Στην αρχιτεκτονική επιλέχθηκε, χάριν απλότητας, οι κλάσεις που περιλαμβάνουν συλλογές άλλων αντικειμένων (όπως ο Κατάλογος Πιάτων, ο Κατάλογος Συστατικών και η Ουρά) να διαθέτουν στατικές ιδιότητες /μεθόδους. Η απόφαση αυτή λήφθηκε καθώς από κάθε μία από αυτές τις κλάσεις δεν αναμένεται να δημιουργηθούν περισσότερα του ενός αντικείμενα Για να μην απαιτείται η δημιουργία των μοναδικών αυτών αντικειμένων σε κάποια κεντρική κλάση (όπως π.χ. η Main) και το "πέρασμα" των αναφορών προς αυτά τα αντικείμενα σε όλα τα αντικείμενα που θέλουν να καλέσουν μεθόδους τους, προτιμήθηκε η χρήση στατικών μεθόδων και ιδιοτήτων. Υπενθυμίζεται ότι οι στατικές ιδιότητες δεν υφίστανται σε επίπεδο αντικειμένων αλλά σε επίπεδο κλάσεων. Επιπλέον, οι στατικές μέθοδοι μπορούν να κληθούν από οποιοδήποτε σημείο του συστήματος μέσω του ονόματος της κλάσης, χωρίς να απαιτείται αναφορά προς κάποιο αντικείμενό της. Αξίζει να σημειωθεί ότι στην αντικειμενοστρεφή σχεδίαση υπάρχουν πιο ενδεδειγμένες λύσεις για αντίστοιχες περιπτώσεις, όπως το πρότυπο σχεδίασης Μοναδιαίο (Singleton Design Pattern). Τονίζεται ότι το διάγραμμα κλάσεων είναι ενδεχομένως το σημαντικότερο διάγραμμα της UML