Unified Modeling Language (UML) ΠΑΠΑΔΑΚΗΣ ΝΙΚΟΛΑΟΣ.

Παρουσίαση με θέμα: "Unified Modeling Language (UML) ΠΑΠΑΔΑΚΗΣ ΝΙΚΟΛΑΟΣ."— Μεταγράφημα παρουσίασης:

1 Unified Modeling Language (UML) ΠΑΠΑΔΑΚΗΣ ΝΙΚΟΛΑΟΣ

2 Μοντελοποίηση συστημάτων Μοντέλο ενός συστήματος ονομάζουμε την αναπαράσταση του με χρήση συνήθως κάποιας αυστηρά καθορισμένης γλώσσας/σημειογραφίας. Χρήση μοντέλων είναι ιδιαίτερα σημαντική στην ανάπτυξη συστημάτων. -Στην κατανόηση και ανάλυση σύνθετων τεχνικών προβλημάτων -Στην περιεκτική παρουσίαση πολύπλοκων συστημάτων -Στην επικοινωνία μεγάλων και ενδεχομένως χωρικά διασπαρμένων ομάδων ανάπτυξης Διαφορετκά μοντέλα μπορούν να παρουσιάζουν το ίδιο σύστημα από διαφορετική οπτική γωνία.

3 Οντοκεντρική Μοντελοποίηση Ένα οντοκεντρικό σύστημα λογισμικού μοντελοποιείται ως αλληλεπίδραση ενός συνόλου οντοτήτων (αντικειμένων). Η επικρατέστερη γλώσσα οντοκεντρικής μοντελοποίησης είναι η Unified Modeling Language (UML) -Προδιαγαφές από το διεθή οργανισμό Object Management Group (OMG) -Περιλαμβάνει σημειογραφία σημειογραφία για γραφική αναπαράσταση μοντέλων.

4 Οντοκεντρική Μοντελοποίηση Ένα αντικείμενο είναι ένα μοντέλο μιας οντότητας που αναπαριστάται στο σύστημα μας. Κάθε αντικείμενο έχει: -Κατάσταση: Το σύνολο των ιδιοτήτων (attributes) του αντικειμένου και των τρεχουσών τιμών τους. Ιδιότητα (attribute) του αντικειμένου ονομάζεται κάθε επώνυμο χαρακτηριστικό του. -Συμπεριφορά: Το σύνολο των λειτουργιών (συναρτήσεων) που μπορεί να εκτελέσει το αντκείμενο. Η εκτέλεση μιας λειτουργίας είναι αποτέλεσμα λήψης ενός μηνύματος από το αντικείμενο και μπορεί να έχει ως αποτέλεσμα τη μεταβολή της κατάστασης του αντικειμένου. -Ταυτότητα: Κάθε αντικείμενο πρέπει να διακρίνεται από τα υπόλοιπα. Αυτό σε κάποιες περιπτώσεις μπορεί να γίνεται βάσει της τιμής μιας ή και περισσοτέρων ιδιοτήτων του που δεν αλλάζουν τιμή σε όλη τη διάρκεια ζωής του αντικειμένου.

5 Οι υπόλοιπες διαφάνειες βασίζονται στο βιβλίο Αντικειμενστρεφής Ανάπτυξη Λογισμικού με τη UML,Κλειδάριθμος 2006.

6 Διαγράμματα στην UML Διαγράμματα Περιπτώσεων Χρήσης(Use Case Diagram) Διαγράματα Κλάσεων (Class Diagram) Διαγράμματα Συμπεριφοράς (Behavior Diagram) –Διαγράμματα Καταστάσων (State chart Diagram) –Διαγράμματα Δραστηριωτήτων (Activity Diagram) –Διαγράμματα Αλληλεπίδρασης (Interaction Diagram) - Διαγράμματα Ακολουθίας (Sequence Diagram) - Διαγράμματα Συνεργασίας (Collaboration Diagram) Διαγράμματα Υλοποίησης (Implementation Diagram) –Διαγράμματα Συστατικών (Component Diagram) –Διαγράμματα Διάταξης (Deployment Diagram)

7 Διαγράμματα Περιπτώσεων Χρήσης(Use Case Diagram) Το βασικότερο θέμα στην κατασκευή ενός πηροφοριακού συστήματος είναι η κατασκευή του ορθού συστήματος == αυτού που ικανοποιεί τις απαιτήσεις του χρήστη. Πολλά συστήματα αποτυγχάνουν σε αυόν τον σκοπό. Το μοντέλο περιπτώσεων χρήσης δίνει έμφαση στη λειτουργιότητα ενός συστήματος όπως αυτό είναι ορατό από τους χρήστες του. Μια περίπτωση χρήσης διμερίζει την λειτουργικότητα ενός συστήματος σε συναλλαγές (περιπτώσεις χρήσης) που έχουν νόημα για τους χρήστες του συστήματος (Χειριστές).

8 Διαγράμματα Περιπτώσεων Χρήση – Περίπτωση Χρήσης Άναπαραστά ένα εξωτερικό χρήστη του συστήματος. Οι χρήστες μπορεί να είναι άνθρωποι ή εξωτερικά συστήματα(π.χ. Διατραπεζικό σύστημα συναλλαγών). Το σύμβολο για μια περίπτωση χρήσης είναι μια έλλειψη, μέσα στν οποία αναγράφεται το όνομα της περίπτωσης χρήσης

9 Διαγράμματα Περιπτώσεων Χρήση – Χειριστής Ο χειριστής ενός συστήματος μπορεί να είναι άνθρωπος ή υποσύστημα. Το σύμβολοπου χρησιμοποιείται για τους χειρισμούς είναι Κάτω απο την φιγούρα υπάρχει το όνομα, το οποίο δείχνει τον ρόλο που παίζει.

10 Διαγράμματα Περιπτώσεων Χρήση – Χειριστής Σε περίπτωση που ο χειριστής είναι ένα υποσύστημα μπορούμε να χρησιμοποιήσομε το παρακάτω σύμβολο

11 Διαγράμματα Περιπτώσεων Χρήση – Χειριστής Οι χειριστές παίζουν σημαντικό ρόλο στην διαδικασία εύρεσης των προδιαγραφών του συστήματος. Είναι η πηγή από την οποία θα προκύψουν οι προδιαγραφές. Απλά οι λειτουργίες που χρειάζεται να υποστηρίζει το σύστημα είναι αυτές που χρειάζονται οι χειριστές του συστήματος. Γι’ αυτόν τον λόγο είναι κρίσιμο να μπορούμε να εντοπίσομε τους χειριστές του συστήματος γιατί οι στόχοι αυτών θα μας υποδείξουν και τις προδιαγραφές του υπό ανάπτυξη συστήματος.

12 Διαγράμματα Περιπτώσεων Χρήση – Σύστημα Για να διακρίνουμε τις προιαγραφές του υπονάπυξη συστήματος από τα πιθανά εξωτερικά συστήματα και τους χρήστες, περιλαμβάνουμε τις περιπτώσεις χρήσης σε ένα πλαίσιο.

13 Διαγράμματα Περιπτώσεων Χρήση – Σχέση Υποδηλώνει τη σχέση ενός χειριστή με μια περίπτωση χρήσης. Ένας χειριτής μπορεί να είναιο βασικός με μια περίπτωση χρήση αλλά μπορεί να σχετίζονται και άλλοι χειριστές με αυτήν την περίπτωση.

14 Διαγράμματα Περιπτώσεων Χρήση – Σχέση Η διάκριση μεταξύ βασικού χειριστή και λοιπών είναι σημαντική γιατί οι προδιαγραφές μπορεί να είναι διαφορετικές για διαφορετικούς χρήστες. π.χ αν μιλάμε για ανάλψη από τράπεζα με βιβλάριο τότε ο βασικός χεριστής είναι ο ταμίας. Άρα δεν χρειάζεται πιστοποίηση κάθε φορά που κάνει μια ανάληψη. Αντίθετα στ ΑΤΜ ο βασικό χειριστής είναι ο πελάτης και χρειάζεται πιστοποίηση για κάθε συναλλαγή.

15 Διαγράμματα Περιπτώσεων Χρήση – Συμπερίληψη Η συμπερίληψη(include) είναι μια ειδική περίπτωση χρήσης στην οποία σχετίζουμε δύο περιπώσης χρήσης. Η έννοια της συμπερίληψης είναι υποχρεωτική δηλαδή πάντα μια περίπτωση χρήσης θα συμπεριλαμβάνεται στην άλλη. Η συμπερίληψη γίνεται όταν η ίδια λειτουργικότητα περιαμβάνεται σε περισσότερες από μια περιπτωσης χρήσης.

16 Διαγράμματα Περιπτώσεων Χρήση – Συμπερίληψη

17 Διαγράμματα Περιπτώσεων Χρήση – Επέκταση Η επέκταση(extend) καθορίζει μια σχέση μεταξύ δύο περιπτώσεων χρήσης, στην οποία σχέση (μεταξύ των 2) η μια περίπτωση επεκτείνεται προερετικά από την άλλη. Σχέση αυτή μπορεί να προκύψει σε συκεκριμμένα σημεία της λειτουργικότητας της βασκής ροής της περίπτωσης χρήσης τα οποία ονομάζονται σημεία επέκτασης.

18 Διαγράμματα Περιπτώσεων Χρήση – Επέκταση

19 Διαγράμματα Περιπτώσεων Χρήση Τα διαγράμματα περιπτώσων χρήσης είναι διγράμματα καταγραφής ποδιαγραφών και είναι χρήσιμα για κάθε σύστημα.

20 Διαγράμματα Κλάσεων Τα διαγράμματα κλάσεων είναι ο πρώτος τύπος διαγραμμάτων της UML ο οποίος έχει άμεση σχέση με τα αντικειμενοστρεφή συστήματα. Τα αντικειμενοστρεφή συστήματα λειτουργούν ως μια συλλογή συνεργαζόμενων αντικειμένων. Τα αντικείμενα αποτελούν στιγμιοτυπα κλάσεων. Είναι χρήσιμο η καταγραφή των κλάσεω που ανήκουν σε ένα σύστημα και οι συσχετίσεις που υπάρχουν μεταξύ τους.

21 Διαγράμματα Κλάσεων Η κλάση συμβολίζονται με ένα παραλληλόγραμμο το οποίο χωρίζεται σε τρία μέρη. Στο πρώτο είναι το όνομα της κλάσης, στο δεύτερο είναι οι ιδιότητες (χαρατηριστικά) της κλάσης και σο τρίτο οι λειτουργίες τις κλάσεις (αντιστοιχούν στις μεθόδους) Με το σύμβολο – αναφερόμαστε σε ιδιωτικα(private) χαρακτηριστικά/λειτουργίες, με το σύβολο + σε δημόσια(public) και με το σύμβολο # προστατευόμενα (protected)

22 Διαγράμματα Κλάσεων

23 Διαγράμματα Κλάσεων συντακτικό για την δήλωση ιδιοτήτων Προσδιοριστής-Πρόσβασης όνομα-ιδιοτήτας: Τύπος [Πολλαπλότητα διάταξης] = Αρχική-τιμή{συβολοσειρά ιδιοτήτων} Αρχική-τιμή{συβολοσειρά ιδιοτήτων} Προσδιοριστής-Πρόσβασης +,-, # Τύπος π.χ. int, String, Employee(η ιδιότητα είναι αντικείμενο της κλάσης Employee) [Πολλαπλότητα διάταξη] : Η πολλαπλότητα μπορεί να μην υπάρχεί. Αν υπάρχει μπορεί να είναι ένα διάστμα π.χ 1...5 ή 1...* σημαίνει τουλάχιστον ένα και απροσδιορίσα ως προς το πανω όριο, ή ακόμα και συγκεκριμμένη τιμή π.χ. 1. Τελός μπρεί να είναι * (σημαίνει ότι μπορεί 0 ή πολλά). Η διάταξη έχει νόημα αν η πολλαιπλότητα μπορεί να είναι μεγαλύτερη του 1 και μπορεί να άρει τιμές ordered και unordered. Αν είναι ordered σημαίνει ότι πρέπει να επιλεξεί δομή που υλοποιείει διάταξη όπως λίστα ή πίνακας και όχι δομή όπως το σύνολο(set).

24 Διαγράμματα Κλάσεων συντακτικό για την δήλωση ιδιοτήτων Προσδιοριστής-Πρόσβασης όνομα-ιδιοτήτας: Τύπος [Πολλαπλότητα διάταξης] = Αρχική-τιμή{συβολοσειρά ιδιοτήτων} Αρχική-τιμή{συβολοσειρά ιδιοτήτων} Αρχική-τιμή: αποδίδει αρχικές τιμές στην ιδιότητα. Η συμβλοσειρά ιδιοτήτων: περιέχει ιδιότητες για την συγκεκριμμένη ιδιότητα. Π.χ αν θέλουμε να δηλώσουμε ότι η τιμή της ιδιότητας δεν μεταβάλλεται τότε την δηλώνουμε {frozen} interestRate:double=0,02{frozen}

25 Διαγράμματα Κλάσεων συντακτικό για την δήλωση λειτουργιών Προσδιοριστής-Πρόσβασης όνομα(λίστα-παραμέτρων): Τύπος-Επιστροφής {συβολοσειρά ιδιοτήτων} Προσδιοριστής-Πρόσβασης +,-, # Η λίστα παραμέτρων είναι η παράμετροι που παίρνει ως είσοδο η λειτουργία. [in | out | inout] Όνομα-παραμέτρου: τύπος=εξ’ ορισμού τιμη [in | out | inout] Όνομα-παραμέτρου: τύπος=εξ’ ορισμού τιμη [in | out | inout] : είναι προερετικά, το in σημαίνει ότι η παράμετρος είναι μόνο είσοδος και δεν μπορεί η λειτουργία να αλλάξει την τιμή της. Το out σημαίνει ότι η λειτουργία αλλάζει την τιμή της παραμέτρου για να επιστρέψει κάτι μέσω αυτής. Το inout σημαίνει ότι γίνονται και τα δύο. Τύπος-Επισροφής προσδιορίζει τον τύπο που θα επιστρέψει η λειτουργία. {συβολοσειρά ιδιοτήτων} : προσδιορίζουμε κάποιες ιδιότητες της λειουργίας. Π.χ. {query} σημαίνει ότι η λειτουργία είναι ερώτημα συνεπώς δεν μεταβαλει την κατάσταση του αντικειμένου. Αυτό είναι πολύ χρήσιμο όταν έχουμε παράλληλη εκτέλεση γιατί ξέρουμε ότι δεν μεταβάλλεται η κατάσταση του αντικειμένου.

26 Διαγράμματα Κλάσεων συντακτικό για την δήλωση λειτουργιών (εμβέλεια κλάσης) Κάποιες λειτουργίες έχουν εμβέλεια κλάσης και όχι ατικειμένου. Για παράδειγμα θεωρήστε ότι έχουμε την μέθοδο +createAccount(AccountID:String):Account Αυτή η μέθοδο επιστρέφει ένα αντικείμενο της κλασης Account και δεν χρησιμοποιείται για να αλλάζει τις ιδιότητες του αντικειμένου που την καλεί. Γι’ τον λόγο αυτό θα πρέπει να δηλωθεί με εμβέλεια της κλάσης (class scope) στην κλάση Acount Στην UML η λειτουργία με εμβέλεια κλάσης δηλώνεται με υπογράμμιση

27 Διαγράμματα Κλάσεων συντακτικό για την δήλωση λειτουργιών (εμβέλεια κλάσης)

28 Διαγράμματα Κλάσεων - Συσχετίσεις κλάσεων Μια συσχέτιση μεταξύ δύο κλάσεων απεικονίζει μια στατικη σχέση μεταξύ των δύο κλάσεων. Η συσχέτιση προκύπτει από την διαπίστωση ότι για την λειτουργία της κλάσης απαιτείται η συνεργασία της με μια ή περισότερες άλλες κλάσεις. Αν η συνεργασία απαιτείται σε μόνιμη βάση τότε χρησιμοποιούμε συσχέτιση. Αν η συνεργασία είναι παροδική (π.χ. Τα αντικείμενα της μια κλάσης είναι παραμέτροι στις μεθόδους της άλλης) τότε χρησιμοποιούμε εξάρτηση. Σην UML για την αναπαράσταση της συσχέτισης χρησιμοποιούμε μια γραμμή μεταξύ των δύο κλάσεων

29 Διαγράμματα Κλάσεων - Συσχετίσεις κλάσεων

30 Διαγράμματα Κλάσεων - Συσχετίσεις κλάσεων μέρη (1/3) Σε μια συσχέτιση έχουμε τα παρακάτω -Όνομα Συσχέτισης: Το όνομα μιας συσχέτισης μπορεί να είναι μια λέξη που υποδηλώνει το νόημα της συσχέτισης. (Αποφεύγουμε λέξεις όπως έχει ανήκει) -Ονόματα άκρων συσχέτισης: Σε κάθε άκρο μπορούμε να βάλουμε ένα όνομα που υοδηλώνει το νόημα της συσχέτισης.

31 Διαγράμματα Κλάσεων - Συσχετίσεις κλάσεων μέρη (2/3) -Πολλαπλότητα: Η πολυπλοκότητα αφορά ένα άκρο μιας συσχέτισης και είναι το πλήθος των αντικειμένων που μπορεί πιθανώς να συσχετίζονται με ένα αντικείμενο της άλλης κλάσης κατά την διάρκεια της εκτέλεσης ενός πργράμματος. Πιθανές πολλαπλότητες είναι 1..* (σημαίνει ότι έχουμε ένα ή περισσότερους) 1..* (σημαίνει ότι έχουμε ένα ή περισσότερους) 0..* (σημαίνει ότι έχουμε 0 ή περισσότερους) 0..1 (σημαίνει ότι έχουμε μηδέςν ή ένα) 0..1 (σημαίνει ότι έχουμε μηδέςν ή ένα) 1 (σημαίνει ότι έχουμε ένα) 1 (σημαίνει ότι έχουμε ένα) 2..4 (σημαίνει ότι έχουμε 2 έως τέσσερα)

32 Διαγράμματα Κλάσεων - Συσχετίσεις κλάσεων μέρη (3/3) - Πλοιμότητα: Η πλοιμότητα αναφέρεται στην δυνατότητα που υπάρχει από αντικείμενα μιας κλάσης που συμμετέχουν σε μια συσχέτιση να ανακτήσουν αντικείμενα της άλλης κλάσης που συμμετέχουν στην συσχέτιση - Πλοιμότητα: Η πλοιμότητα αναφέρεται στην δυνατότητα που υπάρχει από αντικείμενα μιας κλάσης που συμμετέχουν σε μια συσχέτιση να ανακτήσουν αντικείμενα της άλλης κλάσης που συμμετέχουν στην συσχέτιση Η πλοιμότητα συμβολίζεται με ένα βέλος στο τέλος της συσχέτισης. Αν δεν υπάρχει βέλος σημαίνει ότι η πλοιμότητα ισχύει και για τις δύο κλάσεις. Η πλοιμότητα συμβολίζεται με ένα βέλος στο τέλος της συσχέτισης. Αν δεν υπάρχει βέλος σημαίνει ότι η πλοιμότητα ισχύει και για τις δύο κλάσεις.

33 Διαγράμματα Κλάσεων Συσχετίσεις κλάσεων πλοιμότητα (Παράδειγμα) Έχοντας ένα αντικείμενο της κλάσης department μπορούμε να βρούμε ποίος διδάσκει στο τμήμα και ποίος είναι ο πρόεδρος. Αντίθετα έχωντας ένα αντικείμενο της κλάσης Teacher δεν μπορούμε να βρούμε σε ποίο τμήμα ανήκει

34 Διαγράμματα Κλάσεων Συσχετίσεις κλάσεων πλοιμότητα (Παράδειγμα)

35 Διαγράμματα Κλάσεων - Συσχετίσεις Γενίκευσης Η γενίκευση είναι μια ειδική μορφή συσχέτιση κατά την οποία μια κλάση αποτελεί τη βάση για τη δήλωση μιας ή περισσοτέρων κλάσεων (Κληρονομικότητα στο αντικειμενοστρφή)

36 Διαγράμματα Κλάσεων - Συσχετίσεις Γενίκευσης Στην γενίκευσης ισχύει η κηρονομικότητα των χαρακτηριστικών, μεθόδων, το Overrides, κτλ. Η γενίκευση δηλώνεται με ένα βέλος από την υποκλάση στην υπερκλάση.

37 Διαγράμματα Κλάσεων - Αφαιρετικές κλάσεις Κάποιες κλάσεις δηλώνοντι ως abstract. Αυτές οι κλάσεις παρέχουν κώδικα για κάποιες λειτουργίες αλλά αφήνουν άλλες λειτουργίες τους χωρίς κώδικα. Η ιδέα είναι κάποιες υποκλάσεις θα υλοποιήσουν αυτές τις λειτουργίες.Αυτές οι υποκλάσεις ονομάζονται συγκεκριμμένες (concrete). Οι concrete κλάσεις συγκεκριμμενοποιούν τις αφαιρετικές λειτουργίες που κληρονομούν. Στην UML οι concrete κλάσεις αναπαραστώνται με πλάγια γράμματα στο όνομα της κλασης.

38 Διαγράμματα Κλάσεων - Αφαιρετικές κλάσεις

39 Διαγράμματα Κλάσεων - Διασυνδέσεις Μια διασύνδεση είναι ένας τύπος που παρέει μόνο αφαιρτικές λειτουργίες. Κάποιες άλλες κλάσεις υλοποιούν τη διασύνδεση. Η διασύνδεση δεν έχει πλοιμότητα προς τη κλάση που την υλοποιεί. Η κλάση που υλοποιεί την διασύνδεση έχει διακεκομένο βελάκι προς την διασύνδεση. Η διασύνδεση είναι χρήσιμη γιατί τα αντικείμενα της θα έχουν τον τύπο της διασύνδεσης και επομένως θα μπορούν να χρησιμποιηθούν όπου αναμένονται αντικείμενα του τύπου της διασύνδεσης.

40 Διαγράμματα Κλάσεων - Διασυνδέσεις

41 Ενναλακτκός τρόπος παρουσιάσης της υλοποίησης της διασύνδεσης(lollipop γλειφιτζούρι )

42 Διαγράμματα Κλάσεων - Διασυνδέσεις

43

44 Διαγράμματα Κλάσεων - Παραμετρικές Κλάσεις Πολλές φορές θέλουμε να ορίσουμε μια κλάση, στην οποία κάποιος τύπος τον ιδιοτήτων της κλάσης είναι παράμετρος (π.χ στις συλλογές στοιχείων, πόσα στοιχεία θα έχει ένας πίνακας) όπως επίσης και το μέγεθος της συγκεκριμένης ιδιότητας. Στην UML μια παραμετρική κλάση συμβολίζεται με τον παρακάτω τρόπο. Μέσα σε διακομμένο πλαίσιο σο πάνω δεξιό μέρος της κλάσης βάνομε τον τύπο της ιδιότητα που είναι παραμετρική και μετά την παράμετρο. Στο πιο κάτω παράδειγμα η ιδιότητα T έχει πολλαπλότητα 1...Ν (το Ν παράμετρος.

45 Διαγράμματα Κλάσεων - Παραμετρικές Κλάσεις Το πλεονέκτημα των παραμετρικών κλάσεων είναι ότι μπορούμε να ορίσουμε κλάσης γενικού σκοπού π.χ. Μια ουρά χωρίς τύπο. Αυτό παρέχει ευελιξία και ισχυρό έλεγχο τύπων

46 Διαγράμματα Κλάσεων - Παραμετρικές Κλάσεις Δεν μπορούμε να δημιουργήσομε αντικείμενα μιας παραμετρική κλάσης. Για να προκύψουν κλάσεις από τις οποίες μπορούν να δημιοργηθούν αντικείμενα, θα πρέπει να δεσμευθούν οι παραμέτροι σε συγκεκριμμένους τύπους, τιμές κτλ.

47 Διαγράμματα Κλάσεων - Παραμετρικές Κλάσεις Η κλάση PersonArray χρησιμοποιεί την παραμετρική κλάση δηλώσει το Array για να δηλώσει την ιδιότητα elements. Χρήση της λέξης bind.

48 Διαγράμματα Κλάσεων - Συναρμολόγηση Υποδηλώνει μια συσχέτιση μιας κλάσης με κάποια άλλη που αποτελεί μέρος της. Υπάρχουν 2 κομμάτια το όλο και το μέρος Περιορισμός: Δεν επιτρέπεται κυκλική συσχέτιση του όλου με το μέρος Πάντως στην συναρμολόγηση μπορεί ένα μέρος να αποτελεί μέρος και κάποιου άλλου «όλου»

49 Διαγράμματα Κλάσεων - Συναρμολόγηση Με άδειο ρόμβο από την πλευρά του όλου και με βελάκι από την πλευρά των μερών.

50 Διαγράμματα Κλάσεων - Σύνθεση Υποδηλώνει μια συσχέτιση μιας κλάσης με κάποια άλλη που αποτελεί μέρος της. Υπάρχουν 2 κομμάτια το όλο και το μέρος Περιορισμόι: 1. Δεν επιτρέπεται κυκλική συσχέτιση του όλου με το μέρος 2. Στην σύνθεση δεν μπορεί ένα μέρος να αποτελεί μέρος και κάποιου άλλου «όλου». Το όλο περιέχει αποκλειστικά τα μέρη του 3. Υπάρχει σχέση ζωής και θανάτου. Τα μέρη δημουργούνται και καταστρέφονται μαζί με το όλο.

51 Διαγράμματα Κλάσεων - Σύνθεση Με γεμάτο ρόμβο από την πλευρά του όλου και με βελάκι από την πλευρά των μερών. Οι πληθηκότητες όπως μαθαμε.

52 Διαγράμματα Κλάσεων - Σύνθεση

53 Διαγράμματα Κλάσεων - Προσδιορισμένες συσχετίσεις Πολλές φορές όταν υλοποιούμε συσχετίσεις μιας κλάσης με πολλαπλότητα μεγαλύτερη του 1, θέλουμε να περιοσίσουμε τη συσχέτιση έτσι ώστε με τη χρήση κάποιας ιδιότητας να ταυτοποίησουμε τα αντικείμενα που συμμετέχουν την συσχέτιση στο άλλο άρο της συσχέτισης Παράδειγμα: Το βαθμολόγιο, το οποίο περιεχει γραμμές σε κάθε γραμμή ένα φοιτητή.

54 Διαγράμματα Κλάσεων - Προσδιορισμένες συσχετίσεις Αυτό φαινομενικά είναι σωστό. Όμως θα μπορούσα 2 διαφορετικές γραμμές του ίδιου βαθμολογίου να αφορούν τον ίδιο φοιτητή.

55 Διαγράμματα Κλάσεων - Προσδιορισμένες συσχετίσεις Η κλάση βαθμολογίο έχει πάλι πολλές γραμμές αλλά με προσδιοριστικό αντεικίμενο της κλάσης φοτητής. Αυτό σημαίνει ότι σε κάθε φοιτητή αντιστοιχεί μια ή καμία γραμμή.

56 Διαγράμματα Κλάσεων - Προσδιορισμένες συσχετίσεις Μια προσδιορισμένη συσχέτιση συμβολίζεται με ένα παραλληλόγραμμο στην κλάση που αποτελεί την πηγή της συσχέτισης. Μέσα στο παραλλλόγραμμο αναγράφεται το προσδιοριστικό. Το προσδιοριστικό χρησιμοποιείται για τον προσδιορισμό των αντικειμένων που συμμετέχουν στο άλλο άκρο της συσχέτισης.

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

58 Διαγράμματα αντικειμένων Ένα διάγραμμα αντικειμένων είναι ένα στιγμιότυπο του συστήματος σε κάποια χρονική στιγμή Σε αυτό απεικονίζονται αντικείμενα που προέρχονται από κλάσεις σε ένα διάγραμμα κλάσεων καθώς και οι σύνδεσμοι μεταξύ των αντικειμένων που προέρχονται από συσχετίσεις μεταξύ των κλάσεων

59 Διαγράμματα αντικειμένων

60 Εξαρτήσεις Οι εξαρτησεις συμβολίζονται με διακεκομένο βέλος. Το σημείο από το οποίο ξεκινούν ονομάζεται στοιχείο προέλευσης και το σημείο στο οποίο καταλάγουν ονομάζεται στοιχείο προορισμός. Μια αλλαγή στο στοιχείο προέλευσης μπορεί να προκαλέσει αλλαγή στο σημείο προορισμού. Έχουμε δει τις εξαρτήσεις bind, use (οι οποία συνδέει δύο πακέτα). Υπάρχει και το import αν θέλουμε να δείξουμε ότι ένα πακέτο εισάγεται σε ένα άλλο. Οι εξαρτήσεις δεν είναι μεταβατικές. Δηλαδή αν «Α εξαρταται από την Β», «Β εξαρτάται από την Γ» τότε ΔΕΝ σημαίνει ότι «Α εξαρτάται από την Γ». Αυτό είναι σημαντιό γιατί αλλαγές στην Γ μπορεί να μην επηρεασούν την Α.

61 Εξαρτήσεις Η κλάση course δεν σχετίζεται με την student, όμως μέσω της μεθόδου getBestname καλεί την getName για να βρει το όνομα του καλύτερου φοιτητή. Αλλαγή πχ.του ονόματος της getName επηρεάζει την Course.

62 Διαγράμματα αντικειμένων Ένα διάγραμμα αντικειμένων είναι ένα στιγμιότυπο του συστήματος σε κάποια χρονική στιγμή Σε αυτό απεικονίζονται αντικείμενα που προέρχονται από κλάσεις σε ένα διάγραμμα κλάσεων καθώς και οι σύνδεσμοι μεταξύ των αντικειμένων που προέρχονται από συσχετίσεις μεταξύ των κλάσεων

63 Διαγράμματα αντικειμένων

64 Εξαρτήσεις Οι εξαρτήσεις συμβολίζονται με διακεκομμένο βέλος. Το σημείο από το οποίο ξεκινούν ονομάζεται στοιχείο προέλευσης και το σημείο στο οποίο καταλήγουν ονομάζεται στοιχείο προορισμός. Μια αλλαγή στο στοιχείο προέλευσης μπορεί να προκαλέσει αλλαγή στο σημείο προορισμού. Έχουμε δει τις εξαρτήσεις bind, use (οι οποία συνδέει δύο πακέτα). Υπάρχει και το import αν θέλουμε να δείξουμε ότι ένα πακέτο εισάγεται σε ένα άλλο. Οι εξαρτήσεις δεν είναι μεταβατικές. Δηλαδή αν «Α εξαρτάται από την Β», «Β εξαρτάται από την Γ» τότε ΔΕΝ σημαίνει ότι «Α εξαρτάται από την Γ». Αυτό είναι σημαντικό γιατί αλλαγές στην Γ μπορεί να μην επηρεάσουν την Α.

65 Εξαρτήσεις Η κλάση course δεν σχετίζεται με την student, όμως μέσω της μεθόδου getBestname καλεί την getName για να βρει το όνομα του καλύτερου φοιτητή. Αλλαγή πχ.του ονόματος της getName επηρεάζει την Course.

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

67 Διαγράμματα αλληλεπίδρασης Στην αρχική φάση της ανάλυσης ενός συστήματος οι αναλυτές προσδιορίζουν τις υποχρεώσεις υψηλού επιπέδου και πλέον προφανείς κλάσεις. Δεν προσδιορίζουν με ακρίβεια ποίες είναι οι λειτουργίες που θα πρέπει να έχουν οι διάφορες κλάσεις Επιπλέον δεν έχουν προσδιοριστεί όλες οι κλάσεις παρά μόνο αυτές που είναι οι οντότητες του πεδίου προβλήματος. Υπάρχουν δύο τύποι διαγραμμάτων Διαγράμματα Ακολουθίας (Sequence Diagram) - Διαγράμματα Ακολουθίας (Sequence Diagram). Το διάγραμμα ακολουθίας δίνει έμφαση στην χρονική ακολουθία των μηνυμάτων. - Διαγράμματα Συνεργασίας (Collaboration Diagram). Αυτό απεικονίζει τους συνδέσμους μεταξύ των αντικειμένων σε αυτό και για να γίνει προφανής η χρονική σειρά των μηνυμάτων απαιτείται η απαρίθμηση τους

68 Διαγράμματα αλληλεπίδρασης - Διαγράμματα Ακολουθίας Το διάγραμμα ακολουθίας δίνει έμφαση στην χρονική ακολουθία των μηνυμάτων. Τα αντικείμενα απεικονίζονται με παραλληλόγραμμα, στα οποία αναγράφεται το όνομα του αντικειμένου και μετά με άνω-κάτω τελεία αναγράφεται το όνομα της κλάσης. Το όνομα του αντικειμένου μπορεί να παραληφθεί. Κάτω από το παραλληλόγραμμο επεκτείνεται μια διακεκομμένη γραμμή η οποία ονομάζεται γραμμή ζωής του αντικειμένου. Το τέλος ζωής συμβολίζεται με ένα x. Τα αντικείμενα επεκτείνονται στον οριζόντιο άξονα.

69 Διαγράμματα αλληλεπίδρασης - Διαγράμματα Ακολουθίας Τα αντικείμενα ανταλλάσσουν μηνύματα τα οποία ονομάζονται ερεθίσματα. Τα ερεθίσματα μπορεί να είναι:  Κλήση μια λειτουργίας: Όταν ένα αντικείμενο καλεί μια λειτουργία ενός άλλου αντικειμένου. Πρόκειται για σύγχρονο μήνυμα, δηλαδή ο αποστολέας θα περιμένει την ολοκλήρωση της λειτουργίας για να συνεχίσει. Γίνεται με χρήση του συμβόλου

70 Διαγράμματα αλληλεπίδρασης - Διαγράμματα Ακολουθίας  Σήμα: Όταν ένα αντικείμενο αποστέλλει ένα ασύγχρονο μήνυμα σε άλλο αντικείμενο. Αυτό εφαρμόζεται στα νήματα. Η απεικόνιση. Το αντικείμενο αποστολέας μπορεί να συνεχίσει την εκτέλεση του.  Δημιουργία αντικειμένου: ένα ερέθισμα που καταλήγει στη δημιουργία ενός νέου αντικειμένου. (κλήση constructor).

71 Διαγράμματα αλληλεπίδρασης - Διαγράμματα Ακολουθίας Επιστροφή κλήσης: είναι ένα διακεκομμένο βέλος το οποίο συμβολίζει την επιστροφή από μια κλήση. Θα πρέπει φυσικά να έχει προηγηθεί η κλήση και να έχουν ολοκληρωθεί τυχόν υποκλίσεις. Πάνω στο διακεκομμένο βέλος αναγράφεται η τιμή επιστροφή.

72 Διαγράμματα αλληλεπίδρασης - Διαγράμματα Ακολουθίας  Καταστροφή αντικειμένου: είναι ερεθίσματα τα οποία καταλήγουν στο σύμβολο τερματισμού.

73 Παράδειγμα Έστω ότι θέλουμε να ανακτήσουμε το όνομα του καλύτερου φοιτητή για ένα μάθημα (Programming) μέσω του μέσου όρου που έχει στις εργασίες.

74

75 Επεξήγηση παραδείγματος Ο ρόλος secretary αποστέλλει μήνυμα getBestName() (η οποία είναι λειτουργία της κλήσης “Course”. To πλαίσιο ενεργοποίησης(activation frame) που ξεκινάει στην αρχή της κλάσης. Η getBestName() περιέχει τις average() και getMark(). Επειδή οι average() και getMark() καλούνται επαναληπτικά πάνω από το βελάκι με την κλήση βάνουμε * και μέσα σε [ … ] την συνθήκη επανάληψης. Η κλήση της average() θα γίνει για όλα τα CourseRecord του μαθήματος Programming. H average() με την σειρά της καλεί επαναληπτικά την GetMark για να αποκτήσει τον βαθμό για κάθε εργασία. Το πλαίσιο ενεργοποίηση της getMark περιέχεται στις average Η κλήση s:=getStudent() καλεί την getStudent και αυτό που επιστρέφεται ανατίθεται στο s

76 Παρατηρήσεις Στο διάγραμμα ακολουθίας δεν αναπαριστάται ο αλγόριθμος των μεθόδων (π.χ. Της average()). Για να τα αναπαραστήσομε αυτά μπορούμε να χρησιμοποιήσομε διαγράμματα ροής προγράμματος ή ψευδοκώδικα ή οποιαδήποτε διαγράμματα μια μεθοδολογίας ανάπτυξης λογισμικού Τα πλαίσια ενεργοποίηση είναι σημαντικά γιατί βοηθούν τον προγραμματιστή να γράψει το πρόγραμμα. Το κάθε αντικείμενο το οποίο καλεί μια λειτουργία ενός άλλου αντικειμένου άλλης κλάσης θα πρέπει ο δύο κλάσεις να συνδέονται μόνιμα ή εφήμερα. Οι λειτουργίες που καλούνται θα πρέπει να υπάρχουν στο διάγραμμα κλάσεων. Το διάγραμμα αλληλεπίδραση μας βοηθά να κάνουμε κατανομή των λειτουργιών μεταξύ των κλάσεων

77 Δημιουργία αντικειμένου

78 Καταστροφή ενός αντικειμένου

79 Αυτόκληση Όταν ένα αντικείμενο καλεί μια λειτουργία στον εαυτό του απεικονίζεται σαν μια κλήση που ξεκινάει από το αντικείμενο και καταλήγει πάλι σε αυτό.(κλήση μεθόδου της κλάσης στην οποία ανήκει και αναφέρεται σε αυτό). Το πλαίσιο ενεργοποίηση εμφανίζεται εμφωλευμένο στο πλαίσιο ενεργοποίηση.

80 Αυτόκληση

81 Μηνύματα Υπό συνθήκη Στα μηνύματα τοποθετούνται μέσα σε [ ] η συνθήκη η οποία πρέπει να ικανοποιείται για να γίνει η κλήση.

82 Μηνύματα Υπό συνθήκη

83 Διαγράμματα Αλληλεπίδρασης - Διαγράμματα συνεργασίας Ισοδύναμα με τα διαγράμματα ακολουθίας Τα αντικείμενα είναι διάσπαρτα στο χώρο. Οι ανταλλαγές των μηνυμάτων απαριθμούνται για φαίνεται η σειρά τους. Για να δείξουμε ποίες κλήσεις περιέχονται μέσα σε άλλες κλήσεις χρησιμοποιούμε υπό-αρίθμηση (π.χ 1.1 1.2 1.3.1 1.3.2)

84

85 Διαγράμματα Κατάστασης Ένα διάγραμμα καταστάσεων απεικονίζει την δυναμική κατάσταση των αντικειμένων μια κλάσης και του τρόπου με τον οποίο αλλάζουν αυτά ως ανάδραση σε κάποια συμβάντα. Μπορούν να χρησιμοποιηθούν και για άλλους σκοπούς όπως μοντελοποίηση των χειριστών. Συνήθως σχεδιάζονται διαγράμματα καταστάσεων μόνο για τις κλάσεις που παρουσιάζουν δυναμική συμπεριφορά

86 Διαγράμματα Κατάστασης Κάθε κατάσταση συμβολίζεται με ένα παραλληλόγραμμο με στρογγυλοποιημένες γωνίες. Στο πάνω μέρος της κατάστασης εμφανίζεται το όνομα της. Προαιρετικά: μπορεί να εμφανίζονται στο εσωτερικό της κατάστασης δραστηριότητες που λαμβάνουν χώρα: -κατά την είσοδο στην κατάσταση (με την ένδειξη entry) -κατά την έξοδο από την κατάσταση (με την ένδειξη exit) -κατά ην διάρκεια της κατάστασης (με την ένδειξη do)

87 Διαγράμματα Κατάστασης Κάθε κατάσταση συνδέεται με τις άλλες καταστάσεις με βέλη που ονομάζονται μεταβάσεις. Μια μετάβαση λαμβάνει χώρα όταν προκύπτει ένα συμβάν. Το συμβάν αναγράφεται πάνω στο βέλος. Μπορούμε μετά το όνομα του συμβάντος να βάλουμε το / και να γράψουμε τι συμβαίνει με το συμβάν. Η μετάβαση μπορεί να είναι στην ίδια κατάσταση. Η αρχική κατάσταση (ψευδό-κατάσταση) συμβολίζεται με μαύρο κύκλο.

88 Διαγράμματα Κατάστασης - παράδειγμα Θέλουμε να μοντελοποιήσομε τις καταστάσεις ενός ρολογιού. Αυτό έχει δύο καταστάσεις την DISPLAY-TIME και την SET-TIME. Η SET-TIME αποτελείται από δύο υποκαταστάσεις την set-hours και την set-minutes. Η μετάβαση από την DISPLAY-TIME στην SET-TIME γίνεται με το πάτημα κουμπιού Pressed. Η μετάβαση από την SET-TIME στην DISPLAY-TIME γίνεται με δύο τρόπους -με το πάτημα cancel οπότε θα πρέπει να γίνει restore της παλιάς ώρας -με το πάτημα pressed οπότε αποθηκεύεται η νέα ώρα.

89 Διαγράμματα Κατάστασης - παράδειγμα

90 Όπως παρατηρούμε η κατάσταση set-time είναι σύνθετη και αποτελείται από δύο άλλες καταστάσεις Οι μεταβάσεις από την κατάσταση set-hours είναι -προς την ίδια κατάσταση με το πάτημα του κουμπιού + και το αποτέλεσμα είναι να αυξηθούν οι ώρες κατά μια. -προς την κατάσταση set-minutes με το πάτημα του Pressed.

91 Διαγράμματα Κατάστασης – Σύμβολο Τέλους Συμβολίζεται με ένα κύκλο και στην μέση ένα μαύρο γεμισμένος κύκλος. Η κατάσταση living είναι σύνθετη (συνήθως με διπλό κλικ γίνεται ζοομ).

92 Διαγράμματα Κατάστασης – Ταυτόχρονες Σύνθετες Καταστάσεις Πολλές φορές θέλουμε να απεικονίσουμε διαγράμματα στα οποία ένα αντικείμενο βρίσκεται σε δύο ή περισσότερες καταστάσεις. Για τον σκοπό αυτό χωρίζουμε μια κατάσταση σε δύο ή περισσότερες καταστάσεις. Η μετάβαση από μια κατάσταση σε μια ταυτόχρονη σύνθετη κατάσταση σημαίνει ότι το αντικείμενο βρίσκεται ταυτόχρονα στις αρχικές ψευδοκαταστάσεις.

93 Διαγράμματα Κατάστασης – Ταυτόχρονες Σύνθετες Καταστάσεις

94 Διαγράμματα δραστηριοτήτων Το διάγραμμα δραστηριοτήτων είναι μια παραλλαγή του διαγράμματος καταστάσεων στο οποίο οι κόμβοι αναπαραστούν καταστάσεις ενεργειών και οι μεταβάσεις λαμβάνουν χώρα με την ολοκλήρωση αυτών των ενεργειών και όχι ως συνέπεια ενός συμβάντος. Χρησιμοποιούνται για την περιγραφή υπολογισμών ή ροών εργασιών (workflows).

95 Διαγράμματα δραστηριοτήτων

96 Ο παραλληλισμός συμβολίζεται με μια μαύρη μπάρα και μια διχάλα. Η συγχώνευση συμβολίζεται με μια μαύρη μπάρα. Μετά την συγχώνευση η εκτέλεση συνεχίζεται ως μια ροή. Για να γίνει συγχώνευση πρέπει να έχουν τελειώσει όλες οι παράλληλες διεργασίες.

97 Διαγράμματα συστατικών Συστατικό είναι μια οντότητα λογισμικού που εκθέτει τις λειτουργίες της μέσω ενός συνόλου δημοσίων διασυνδέσεων και μπορεί να συνδεθεί δυναμικά με άλλα συστατικά για τη δημιουργία μεγαλύτερων συστατικών και εφαρμογών. Κάθε συστατικό -διαθέτει τις λειτουργίες του μέσω διασυνδέσεων και άρα κρυφή την εσωτερική δομή -μπορεί να συνδεθεί δυναμικά με άλλα συστατικά -είναι επαναχρησιμοποιήσιμα

98 Διαγράμματα συστατικών

99 Διαγράμματα Διάταξης Το διάγραμμα διάταξης χρησιμοποιείται κυρίως σε κατανεμημένα συστήματα για να δείξει την φυσική διάταξη των διαφόρων τμημάτων

100 Διαγράμματα Διάταξης

101 Παράδειγμα διαγράμματος αλληλεπίδρασης Θέλουμε να υλοποιήσομε την πιο πάνω εφαρμογή. Με το πάτημα του κουμπιού θα εμφανίζεται το νέο παράθυρο showDialog() 1 2

102 Παράδειγμα διαγράμματος αλληλεπίδρασης

103 ΜΕΘΟΔΟΛΟΓΙΑ ICONIX Νίκος Παπαδάκης

104 Οι υπόλοιπες διαφάνειες βασίζονται στο βιβλίο Αντικειμενστρεφής Ανάπτυξη Λογισμικού με τη UML,Κλειδάριθμος 2006.

105 Μεθοδολογίες Ανάπτυξης Λογισμικού Μια μεθοδολογία ανάπτυξης λογισμικού παρέχει μια συστηματική προσέγγιση στη διαδικασία ανάλυσης, σχεδίασης, κατασκευής και εξέλιξης ενός έργου πληροφορικής. Μια μεθοδολογία είναι ουσιαστικά μια σειρά σταδίων τα οποία περιγράφουν συγκεκριμένες εργασίες. Η UML δεν είναι μεθοδολογία αλλά γλώσσα μοντελοποίησης την οποία μπορούν να χρησιμοποιήσουν η μεθοδολογίες ανάπτυξης λογισμικού με διάφορους τρόπους

106 Μεθοδολογίες Ανάπτυξης Λογισμικού Πάντα κατά την διάρκεια ανάπτυξης ενός συστήματος λογισμικού, οι διαχειριστές του έργου πιέζουν την ομάδα ανάπτυξης να προχωρήσει γρήγορα στην παραγωγή κώδικα. Αποτέλεσμα είναι να μην υπάρχει αρκετός χρόνος για σωστή ανάλυση και σχεδιασμό του υπο ανάπτυξη συστήματος. Αντίθετα όλες οι μεθοδολογίες ανάπτυξης λογισμικού υπερτονίζουν τη σημασία των δραστηριοτήτων ανάπτυξης και σχεδιασμού. Η μεθοδολογία ICONIX με τη αμεσότητα και την πληρότητα της καταφέρνει να ελαττώσει τον ανταγωνισμό ανάμεσα στην ανάπτυξη και διαχείριση ενός έργου λογισμικού.

107 Η μεθοδολογία ICONIX Χρησιμοποιεί τέσσερα είδη διαγραμμάτων της UML. 1. Διαγράμματα περιπτώσεων χρήσης για να αναπαραστήσουμε τα σενάρια χρήσης και τους χειριστές του συστήματος 2. Διαγράμματα κλάσεων (αναπαράσταση του πεδίου εφαρμογής – στατική δομή) 3. Διαγράμματα συνεργασίας για να αναπαραστήσουμε τον τρόπο με τον οποίο στατική δομή υλοποιεί τα σενάρια χρήσης του συστήματος. 4. Διαγράμματα ακολουθίας για να συσχετίσουμε λεπτομερώς την δυναμική με την στατική δομή του συστήματος.

108 Η δομή της μεθοδολογία ICONIX Η μεθοδολογία αποτελείται από τρεις φάσεις 1. Ανάλυση απαιτήσεων 2. Αρχικός σχεδιασμός 3. Σχεδιασμός Εαν εφαρμοστεί σωστά η μεθοδολογία μετά τον σχεδιασμό θα είναι δυνατή η άμεση υλοποίηση ενός ορθού και λειτουργικού συστήματος

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

110 Η δομή της ICONIX - Σημεία Ελέγχου Στα σημεία ελέγχου μιας αντικειμετρεφούς μεθοδολογίας θα πρέπει να περιλαμβάνονται 1. Εντοπισμός και περιγραφή όλων των σεναρίων χρήσης του συστήματος 2. Εντοπισμός των οντοτήτων που ανήκουν στο πεδίο εφαρμογής και οι οποίες αποτελούν δομικά τμήματα(κλάσεις) – στατικό μοντέλο 3. Επαλήθευση ότι όλες οι λειτουργικές απαιτήσεις ικανοποιούνται στο σχεδιασμό του συστήματος 4. Εφαρμογή βασικών αρχών σχεδιασμού( ελαχιστοποίηση εξαρτήσεων, μεγιστοποίηση συνοχής, γενικότητα πληρότητα κλπ) και ανάθεση λειτουργικής συμπεριφοράς σε τμήματα λογισμικού.

111 Τι χρειάζεται να απαντήσουμε εφαρμόζοντας την μεθοδολογία Ποίοι είναι οι χρήστες του συστήματος και τι θέλουν να κάνουν με αυτό Ποια είναι τα αντικείμενα του πραγματικού κόσμου και ποίες οι συσχετίσεις μεταξύ τους Ποία από αυτά τα αντικείμενα χρησιμοποιούνται σε κάθε περίπτωση χρήσης Πως χειριζόμαστε τα θέματα ελέγχου Πως θα φτάσουμε στην πραγματική κατασκευή του συστήματος

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

113 Εφαρμογή της μεθοδολογία -Ανάλυση 1. Ο στόχος της ανάλυσης είναι να περιγράψουμε τις περιπτώσεις χρήσεις του συστήματος ανά σενάριο λειτουργίας. 2. Πρέπει να αποφύγουμε να περιγράψουμε γενικές και ασαφείς περιπτώσεις χρήσης (ασαφής = δεν περιέχουν αρκετή πληροφορία για να μας οδηγήσουν στο σχεδιασμό του συστήματος) 3. Το 2 επιτυγχάνεται αν όταν κάνουμε την περιγραφή των περιπτώσεων χρήσης έχουμε κατά νου το μοντέλο του πεδίου εφαρμογής. Μοντέλο πεδίου εφαρμογής είναι ένα λεξικό όπου περιγράφονται οι βασικές αφαιρέσεις που κάνουμε κατά την αναπαράσταση του προβλήματος.  Αυτές οι αφαιρέσεις ονομάζονται αντικείμενα του πεδίου εφαρμογής – προκύπτουν από τα ουσιαστικά της περιγραφής του υπό-ανάπτυξη συστήματος  Αυτά τα ουσιαστικά περιγράφουν το πεδίο εφαρμογής, δηλαδή το πεδίο στο οποίο θα λειτουργεί το σύστημα

114 Εφαρμογή της μεθοδολογία - Ανάλυση Μαζί με το προσχέδιο διασύνδεσης θα πρέπει να καταστρώσουμε και ένα αρχικό σχέδιο του μοντέλου του πεδίου εφαρμογής. Αυτό μπορεί να είναι ένα ενοποιημένο διάγραμμα κλάσεων, το οποίο θα περιλαμβάνει και όλα τα αντικείμενα του πεδίου εφαρμογής.  σε αυτό δεν περιλαμβάνονται λεπτομέρειες όπως κατηγορήματα (μέθοδοι) των κλάσεων. απλώς συνοψίζει τις κλάσεις. Αρχικά το μοντέλο προκύπτει από την περιγραφή της διασύνδεσης και των σεναρίων χρήσης. Καθώς θα σχεδιάζουμε τις περιπτώσεις χρήσης χρησιμοποιώντας διαγράμματα και κείμενο το αρχικό διάγραμμα κλάσεων θα αλλάζει και θα εμπλουτίζεται.

115 Εφαρμογή της μεθοδολογία – Αρχικός σχεδιασμός Ξεκινώντας από τις περιπτώσεις χρήσης και έχοντας υπόψη την στατική δομή προχωράμε σε λεπτομερή περιγραφή του συστήματος. 1. Ποια είναι η δυναμική συμπεριφορά του συστήματος; 2. Πως υλοποιείται (η συμπεριφορά) στο σύστημα;

116 Εφαρμογή της μεθοδολογία – Αρχικός σχεδιασμός Ποια είναι η δυναμική συμπεριφορά του συστήματος; Η απάντηση  Σχεδιάζουμε το μοντέλο συνεργασίας στο οποίο περιλαμβάνεται ένα σύνολο από διαγράμματα συνεργασία.  Σε κάθε διάγραμμα συνεργασίας φαίνεται ποιες κλάσεις του συστήματος συνεργάζονται για να υλοποιήσουν κάθε περίπτωση χρήση. Αυτό το στάδιο είναι κρίσιμο γιατί σηματοδοτεί την μετάβαση από τις απαιτήσεις λειτουργικότητας του συστήματος (όπως αυτή περιγράφεται στα διαγράμματα περιπτώσεων χρήσης) σε μια φάση πιο κοντά στον λεπτομερή σχεδιασμό του συστήματος (όπως αυτός θα περιγράφεται στα διαγράμματα ακολουθίας)

117 Εφαρμογή της μεθοδολογία – Αρχικός σχεδιασμός Με βάση τα διαγράμματα συνεργασίας  θα εμπλουτίσομε το κείμενο που περιγράφει τις περιπτώσεις χρήσης  θα ενσωματώσουμε στο μοντέλο του πεδίου εφαρμογής τα συνοριακά αντικείμενα. Τα συνοριακά αντικείμενα αναπαριστούν τον τρόπο με τον οποίο επικοινωνεί το σύστημα – οι κλάσεις που αναπαριστούν οθόνες χρήστη και επικοινωνίας με υποσυστήματα.

118 Εφαρμογή της μεθοδολογία – Σχεδιασμός Στη συνέχεια σχεδιάζουμε τα διαγράμματα ακολουθίας. Σε αυτά ουσιαστικά μετατρέπουμε τις λειτουργίες που υλοποιούν την δυναμική συμπεριφορά σε μεθόδους τις οποίες κατανέμουμε σε κλάσεις Για κάθε σενάριο χρήσης του συστήματος θα σχεδιάσουμε ένα διάγραμμα ακολουθίας, το οποίο μας δείχνει ποιο αντικείμενο μέσα στον κώδικα είναι υπεύθυνο για ποια λειτουργία του συστήματος. Κατά τον σχεδιασμό των διαγραμμάτων ακολουθίας θα αποφασίσουμε την κατανομή των λειτουργιών σε κλάσεις.

119 Εφαρμογή της μεθοδολογία – Τελικά εξαγόμενα της ICONIX Λεπτομερές διάγραμμα κλάσεων, από το οποίο είναι εύκολο να παραχθεί ο κώδικας του συστήματος. Το διάγραμμα αυτό περιλαμβάνει 1. Όλες τις κλάσεις του συστήματος (στατική δομή) 2. Για κάθε κλάση τις μεθόδους που υλοποιούν τις λειτουργίες του συστήματος (δυναμική λειτουργία) 3. Τα δεδομένα που αυτές χρησιμοποιούν (μοντέλο δεδομένων)

120 Οπτικοποιημένη Περιγραφή της ICONIX

121 Συνοπτική Περιγραφή της ICONIX 1. Ξεκινάμε με μια γρήγορη πρώτη εκτίμηση των αντικειμένων (την καταγράφουμε σε ένα συνοπτικό διάγραμμα κλάσεων) 2. Φτιάχνουμε τα σενάρια χρήσης 3. Στην συνέχεια εφαρμόζουμε μια μακρά διαδικασία βασισμένο στην ανάλυση της δυναμικής συμπεριφοράς του συστήματος κατά τη οποία αναλύουμε λεπτομερώς την αναμενόμενη λειτουργία κάθε σεναρίου χρησιμοποιώντας διαγράμματα συνεργασίας και ακολουθίας ενημερώνοντας ταυτόχρονα το διάγραμμα κλάσεων. 4. Έπειτα επιστρέφουμε στο σενάριο και αναλύουμε περισσότερο τη συμπεριφορά του συστήματος, επαναλαμβάνοντας την διαδικασία.  Στην INCONIX αναλύουμε το σύστημα με βάση τα όρια των σεναρίων χρήση, και στην συνέχεια ανάλογα με το αποτέλεσμα της ανάλυσης των σεναρίων δημιουργούμε λεπτομερή μοντέλα της δομής του συστήματος.

122 Στην ICONIX μπορούμε Να ελέγξουμε τα παραγόμενα μοντέλα τρεις φορές. 1. Στο τέλος της ανάλυσης απαιτήσεων, όπου ελέγχουμε κυρίως τα διαγράμματα περιπτώσεων χρήσης σε συνδυασμό με το μοντέλο πεδίου εφαρμογής 2. Στο τέλος του αρχικού σχεδιασμού ελέγχουμε τα διαγράμματα κλάσεων σε συνδυασμό με τα διαγράμματα συνεργασίας 3. Στο τέλος του σχεδιασμού ελέγχουμε τα διαγράμματα κλάσεων σε συνδυασμό με τα διαγράμματα ακολουθίας

123 Ανάλυση Απαιτήσεων – Αναπαράσταση πεδίου εφαρμογής Το βήμα αυτό είναι βασικό γιατί σε αυτό θα βασίσουμε το στατικό μοντέλο του υπό- ανάπτυξη συστήματος. Συνεπώς το μοντέλο αυτό θα πρέπει να αποτελεί μια ειλικρινή και ανεξάρτητη από το χρόνο περιγραφή του πεδίου εφαρμογής. Το βήμα αυτό περιλαμβάνει τον εντοπισμό εννοιολογικών οντοτήτων Η προσέγγιση «από μέσα προς τα έξω»

124 Ανάλυση Απαιτήσεων – Αναπαράσταση πεδίου εφαρμογής Βασικές δραστηριότητες  Εντοπισμός κλάσεων που αναπαριστούν με ακρίβεια τις εννοιολογικές οντότητες του πεδίου εφαρμογής  Επεξεργασία του αρχικού διαγράμματος και απαλοιφή των περιττών ή των λανθασμένων κλάσεων  Εντοπισμός σχέσεων γενίκευσης και συναρμολόγησης ανάμεσα στις κλάσεις.

125 Ανάλυση Απαιτήσεων – Αναπαράσταση πεδίου εφαρμογής Σε αυτό το στάδιο πρέπει  Να μην ασχοληθούμε με τις πολυπλοκότητες των σχέσεων ή με λεπτομέρειες σχετικά με την υλοποίηση των σχέσεων  Να μην επιδιώξουμε την εξαντλητική ανάλυση της λεκτικής περιγραφής του συστήματος προσπαθώντας να εντοπίσουμε όλες τις κλάσεις και τις σχέσεις  Να μην ασχοληθούμε εξαντλητικά με την πιθανή επαναχρησιμοποίηση κλάσεων αφού ο στόχος είναι να ικανοποιήσουμε τις απαιτήσεις των χρηστών  Να μην σχεδιάσουμε μεθόδους για τις κλάσεις πριν σχεδιάσουμε μεθόδους για τις κλάσεις πριν σχεδιάσουμε τις περιπτώσεις χρήσης και τα διαγράμματα ακολουθίας  Να μην χρησιμοποιήσουμε περίπλοκα και δυσνόητα ονόματα κλάσεων  Να μην δεσμευόμαστε με αποφάσεις υλοποιήσεις  Να μην εμπλακούμε σε προσπάθειες εύρεσης έξυπνων και γενικών λύσεων  Να μην χρησιμοποιούμε δομές υλοποίησης(π.χ παραμετρικές κλάσεις)  Να μην αντιστοιχούμε τις κλάσεις με δομές που δεν ανήκουν εξ’ ολοκλήρου στο στατικό μοντέλο

126 Ανάλυση Απαιτήσεων – Αναπαράσταση πεδίου εφαρμογής Από τα ουσιαστικά και τα ρηματικά ουσιαστικά προκύπτουν κλάσεις και κατηγορήματα. Από τα ρήματα και τις ρηματικές εκφράσεις προκύπτουν μέθοδοι και συσχετίσεις Οι κτητικές φράσεις αποτελούν ένδειξη ότι τα αναφερόμενα ουσιαστικά περιγράφουν κατηγορήματα και όχι κλάσεις

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

128 Ανάλυση Απαιτήσεων – Σχεδιασμός Περιπτώσεων Χρήσης Οι βασικές δραστηριότητες 1. Σχεδιασμός προτύπων οθονών και σεναρίων χρήσης του συστήματος 2. Ανάλυση σεναρίων (ένα – ένα) και σχεδιασμός των περιπτώσεων χρήσης 3. Ανάλυση κάθε περίπτωσης χρήσης: η περιγραφή πρέπει να είναι λιτή, κατανοητή και πλήρης με αναφορές στα αντικείμενα του μοντέλου πεδίου εφαρμογής 4. Εμπλουτισμός του μοντέλου του πεδίου εφαρμογής με όποια νέα αντικείμενα εντοπίστηκαν κατά την ανάλυση 5. Εντοπισμός περιπτώσεων χρήσης που εμφανίζονται σε πολλά σενάρια και παραγονοποίηση του μοντέλου (για αποφυγή επανάληψης)

129 Ανάλυση Απαιτήσεων – Σχεδιασμός Περιπτώσεων Χρήσης 6. Τα τρία τελευταία βήματα θα πρέπει να επαναλαμβάνονται μέχρι  Να έχουμε σχεδιάσει ένα σύνολο περιπτώσεων χρήσης που περιγράφει πλήρως και αναλυτικά την επιθυμητή λειτουργία του συστήματος  Να έχουμε γράψει πλήρεις και κατανοητές περιγραφές για όλες τις βασικές λειτουργίες και για όλες τις εναλλακτικές ακολουθίες ενεργειών και αποκρίσεων που σχετίζονται με καθεμία από τις λειτουργίες  Να έχουμε παραγοντοποιήσει λειτουργίες που είναι κοινές σε πολλές περιπτώσεις χρήσης 7. Ομαδοποίηση των περιπτώσεων χρήσης σε πακέτα.

130 Ανάλυση Απαιτήσεων – Λεκτική Περιγραφή Περιπτώσεων Χρήσης Για κάθε περίπτωση χρήσης συμπληρώνουμε μια φόρμα, η οποία περιέχει 1. Το όνομα της περίπτωσης χρήσης 2. Ένα τμήμα με τίτλο «Βασική ακολουθία ενεργειών/αποκρίσεων». Στο τμήμα αυτό καταγράφουμε (με λιτές αριθμημένες φράσεις) την απάντηση στην ερώτηση τι συμβαίνει στην περίπτωση χρήσης 3. Ένα τμήμα με τίτλο «Εναλλακτικές ακολουθίες ενεργειών/αποκρίσεων». Στο τμήμα αυτό καταγράφεται με τον ίδιο τρόπο διαφορετικές απαντήσεις στην ερώτηση «τι άλλο μπορεί να συμβεί». Πρέπει να εξαντλήσουμε όλες τις περιπτώσεις.

131 Ανάλυση Απαιτήσεων – Σχεδιασμός Περιπτώσεων Χρήσης Στο στάδιο αυτό πρέπει  Να αποφεύγουμε να γράψουμε λειτουργικές απαιτήσεις αντί να περιγράψουμε τα σενάρια χρήσης  Να αποφεύγουμε να περιγράφουμε κατηγορήματα και μεθόδους κλάσεων  Να μην κάνουμε οικονομία στην περιγραφή των περιπτώσεων χρήσης  Να μην περιγράφουμε μόνο τις ενέργειες των χρηστών. Πρέπει να περιγραφούν και οι αποκρίσεις του συστήματος στις πιο πάνω ενέργειες  Να μην αποξενωθούμε από τη διασύνδεση του συστήματος  Να είμαστε σαφείς στον εντοπισμό και την περιγραφή των συνοριακών αντικειμένων (αυτά τα οποία αλληλεπιδρούν οι χειριστές)  Να μην εμπλακούμε σε περιγραφές άσχετες με την περίπτωση χρήσης

132 Ανάλυση Απαιτήσεων – Σχεδιασμός Περιπτώσεων Χρήσης Πρακτικός οδηγός 1. Φροντίζουμε να εκφράσουμε κάθε περίπτωση χρήσης από τη σκοπιά του χρήστη και να χρησιμοποιούμε χρόνο ενεστώτα σε ενεργητική φωνή 2. Κάθε περίπτωση χρήσης περιλαμβάνει απλές προτάσεις (Υποκείμενο – ρήμα –αντικείμενο), οι οποίες περιγράφουν εναλλάξ μια ενέργεια χρήστη και την απόκριση (εις) του συστήματος 3. Αριθμούμε κάθε ενέργεια ή απόκριση της βασικής και των εναλλακτικών ροών. 4. Κάνουμε αναφορά σε όσα αντικείμενα των οθονών του συστήματος γνωρίζουμε.

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

134 Επισκόπηση Απαιτήσεων τι πρέπει να γίνει (1/2) Επισκόπηση Απαιτήσεων τι πρέπει να γίνει (1/2) Να εξετάσουμε μόνο τις απαιτήσεις των χρηστών, ρητά και αυστηρά. Αποφεύγοντας την εισαγωγή στο σύστημα νέων εντυπωσιακών αλλά άχρηστων χαρακτηριστικών. Να βεβαιωθούμε ότι το κείμενο που περιγράφει τις περιπτώσεις χρήσης περιγράφει επακριβώς τι θα κάνει το σύστημα με βάση τις απαιτήσεις των χρηστών. Να χρησιμοποιήσομε ένα πρότυπο διασύνδεσης του συστήματος, το οποίο θα επιτρέψει να βεβαιωθούμε ότι οι περιγραφές των περιπτώσεων χρήσης ταιριάζουν με τις αναμενόμενες δραστηριότητες αλληλεπίδρασης του χρήστη με το λογισμικό. Ταυτόχρονα το πρότυπο μας επιτρέπει να συμφωνήσουμε με τους χρήστες. Να φροντίσουμε ώστε οι περιγραφές τω περιπτώσεων χρήσης να είναι συνοπτικές και ακριβείς.

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

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

137 Αρχικός σχεδιασμός- Ανάλυση Ευρωστίας Στο βήμα αυτό κατατάσσουμε τα αντικείμενα σε τρεις βασικές κατηγορίες 1. Αντικείμενα Οντοτήτων 2. Συνοριακά Αντικείμενα 3. Αντικείμενα Ελέγχου

138 Αρχικός σχεδιασμός- Ανάλυση Ευρωστίας Στην συνέχεια ακολουθεί μια εξαντλητική ανάλυση των σεναρίων χρήσης, προσπαθώντας να εντοπίσουμε εναλλακτικές στρατηγικές σχεδιασμού και αρχιτεκτονικές υλοποίησης. Θέλουμε να αποκαλύψουμε τα σημεία που επηρεάζουν τις επιδόσεις του συστήματος. Να πάρουμε τις αρχικές αποφάσεις σχεδιασμού

139 Αρχικός σχεδιασμός- Ανάλυση Ευρωστίας Ο στόχος είναι να παραχθούν διαγράμματα συνεργασίας, ένα για κάθε σενάριο. Κάθε διάγραμμα θα αναπαριστά τα αντικείμενα του συστήματος που συμμετέχουν στο σενάριο και τον τρόπο με τον οποίο αλληλεπιδρούν. Το διάγραμμα συνεργασίας στην πραγματικότητα είναι ένα διάγραμμα κλάσεων στην θέση της κάθε κλάσης βρίσκεται ένα αντικείμενο το οποίο ανήκει σε κάποια από τις τρεις κατηγορίες. Τέλος εμπλουτίζομε τις περιγραφές των περιπτώσεων χρήσης αλλά και το στατικό μοντέλο του συστήματος.  Τα διαγράμματα συνεργασία είναι ενδιάμεσο στάδιο το οποίο μπορεί στο τέλος να το πετάξουμε κάτι το οποίο δεν ισχύει για τα διαγράμματα κλάσεων και περιπτώσεις χρήσης

140 Αρχικός σχεδιασμός- Ανάλυση Ευρωστίας Ο ρόλος της υπό-φάσης αυτής είναι σημαντικός στην ICONIX γιατί 1. Γεφυρώνει το χάσμα που υπάρχει ανάμεσα στην ανάλυση και τον λεπτομερή σχεδιασμό 2. Μας επιτρέπει να κάνουμε έλεγχο ορθότητας των περιπτώσεων χρήσης και να βεβαιωθούμε ότι αυτά που έχουμε περιγράψει δεν είναι ανέφικτα. 3. Μας επιτρέπει να κάνουμε έλεγχο πληρότητας και να βεβαιωθούμε ότι οι περιπτώσεις χρήσεις περιγράφουν πραγματικά όλες τις δυνατές εναλλακτικές ακολουθίες ενεργειών 4. Υποβοηθά τη συνεχή ανακάλυψη αντικειμένων, τον εντοπισμό σχεδιαστικών ασυμβατοτήτων ή επικαλύψεων, και το συνεπακόλουθο εμπλουτισμό του μοντέλου του πεδίου εφαρμογής (πριν τα διαγρ. Ακολουθίας)

141 Αρχικός σχεδιασμός- Ανάλυση Ευρωστίας Βασικές δραστηριότητες είναι 1.Διατρέχουμε το κείμενο που περιγράφει τις περιπτώσεις χρήσης, ένα σενάριο κάθε φορά και σχεδιάζουμε χειριστές αντικείμενα και συνδέσεις ανάμεσα τους εφαρμόζοντας τα παρακάτω  οι χειριστές επικοινωνούν μόνο με συνοριακά αντικείμενα  Τα συνοριακά αντικείμενα επικοινωνούν με χειριστές και ελεγκτές  Τα αντικείμενα οντοτήτων επικοινωνούν μόνο με ελεγκτές  Οι ελεγκτές επικοινωνούν με συνοριακά αντικείμενα, αντικείμενα οντοτήτων, και άλλους ελεγκτές, αλλά όχι με χειριστές

142 Αρχικός σχεδιασμός- Ανάλυση Ευρωστίας Βασικές δραστηριότητες είναι 2. Ελέγχουμε την ορθότητα και την πληρότητα ενός διαγράμματος συνεργασίας κάνοντας τεστ ακμών. 3. Εντοπίζουμε την εμφάνιση προτύπων σχεδιασμού στα διαγράμματα συνεργασίας 4. Σχεδιάζουμε την αρχιτεκτονική ενός συστήματος, η οποία περιλαμβάνει και τις επιλογές της τεχνολογίας που θα χρησιμοποιήσομε για την υλοποίηση

143 Αρχικός σχεδιασμός- Ανάλυση Ευρωστίας 5. Εμπλουτίζουμε το κείμενο των περιπτώσεων χρήση μειώνοντας την ασάφεια των περιγραφών  Επιπλέον προσθέτουμε άμεσα όποια αντικείμενα εντοπίστηκαν κατά τον αρχικό σχεδιασμό καταγράφοντας βασικά κατηγορήματα στις πιο σημαντικές κλάσεις  Καθώς εξετάζουμε τα συνοριακά αντικείμενα πρέπει να είμαστε σε θέση να ιχνηλατήσουμε ροές από τα συνοριακά αντικείμενα προς τα αντικείμενα οντοτήτων και αντίστροφα  Τα δεδομένα αυτά θα αποτελέσουν κατηγορήματα των αντιστοίχων κλάσεων του στατικού μοντέλου

144 Αρχικός σχεδιασμός- Ανάλυση Ευρωστίας Τι αποφεύγουμε  Αποφεύγουμε να επικεντρωθούμε μόνο στην βασική ακολουθία και να παραλείψουμε τις εναλλακτικές ακολουθίες ενεργειών στο διάγραμμα συνεργασίας  Να αποφύγουμε να καταχωρίσουμε και να περιγράψομε μεθόδους των κλάσεων  Να μη συμπεριλάβουμε πολύ λίγους ή υπερβολικά πολλούς ελεγκτές σε ένα διάγραμμα συνεργασίας. Στην πρώτη οι περιπτώσεις χρήσεις είναι απλές ενώ στην δεύτερη δύσχρηστες  Να μην ξοδεύουμε χρόνο προσπαθώντας να τελειοποιήσουμε τα διαγράμματα συνεργασίας.  Να μην παραλείψουμε τον οπτικό έλεγχο της ανιστοίχισης των διαγραμμάτων συνεργασίας με τις περιγραφές των ακολουθιών ενεργειών και γεγονότων τω περιπτώσεων χρήσης

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

146 Σε αυτήν την φάση θα χρησιμοποιήσουμε 1. Το μοντέλο του πεδίου εφαρμογής 2. Τα σχέδια των οθόνων του συστήματος 3. Τα διαγράμματα περιπτώσεων χρήσης μαζί με τις περιγραφές τους 4. Τα διαγράμματα συνεργασίας που σχεδιάσαμε για κάθε σενάριο χρήσης Αρχικός σχεδιασμός- Προκαταρκτική επισκόπηση σχεδιασμού

147 Σε αυτήν την φάση συμμετέχουν οι χρήστες και η ομάδα ανάπτυξης Αποτελεί την τελευταία ευκαιρία που έχουν οι πελάτες να τροποποιήσουν τις απαιτήσεις τους πριν αρχίσει η καθαυτή ανάπτυξη του συστήματος Μετά από αυτό το σημείο οι πελάτες δεν συμμετέχουν άλλο στη διαδικασία μέχρι να αρχίσει η δοκιμαστική λειτουργία του συστήματος. Αρχικός σχεδιασμός- Προκαταρκτική επισκόπηση σχεδιασμού

148 Τι περιλαμβάνει 1. Επισκόπηση των διαγραμμάτων συνεργασίας σε σχέση με τις περιγραφές των περιπτώσεων χρήσης για κάθε σενάριο χρήσης που θα υποστηρίζει από το σύστημα που αναπτύσσουμε. Οι στόχοι είναι να βεβαιωθούμε  Τα διαγράμματα ταιριάζουν με τις περιγραφές  Τα διαγράμματα είναι πλήρη  Αναπαριστούν σωστά την επιθυμητή συμπεριφορά του συστήματος 2. Επισκόπηση του στατικού μοντέλου με στόχο να βεβαιωθούμε ότι αναπαριστούμε στο διάγραμμα κλάσεων όλα τα αντικείμενα οντοτήτων που εμφανίζονται στο διάγραμμα συνεργασίας Αρχικός σχεδιασμός- Προκαταρκτική επισκόπηση σχεδιασμού

149 3. Επισκόπηση των κλάσεων του στατικού μοντέλου σε σχέση με τις οθόνες του συστήματος. Εδώ οι στόχοι είναι να βεβαιωθούμε ότι οι κλάσεις περιλαμβάνουν τα πιο σημαντικά κατηγορήματα  ότι μπορούμε να ιχνηλατήσουμε τη ροή δεδομένων από τα στοιχεία των οθόνων σε κλάσεις οντοτήτων και ίσως σε κάποια αρχικά υποσυστήματα αποθήκευσης 4. Επισκόπηση τεχνολογικών επιλογών για να βεβαιωθούμε ότι ο σχεδιασμός που επιχειρούμε είναι εφικτός μέσα στα πλαίσια που επιβάλει η τεχνική αρχιτεκτονική Αρχικός σχεδιασμός- Προκαταρκτική επισκόπηση σχεδιασμού

150 Κατά την φάση αυτή πρέπει να βεβαιωθούμε 1. Ότι οι πελάτες μας έχουν αντιληφθεί ότι αυτή είναι η τελευταία τους ευκαιρία να παρέμβουν στις προδιαγραφές του συστήματος 2. Να βεβαιωθούμε ότι για κάθε σενάριο χρήσης, η περιγραφή κάθε περίπτωσης χρήσης ταιριάζει ακριβώς με το αντίστοιχο διάγραμμα συνεργασίας, καθώς και ότι σε κάθε διάγραμμα έχουμε αναπαραστήσει τόσο τη βασική όσο και όλες τις εναλλακτικές ακολουθίες ενεργειών Αρχικός σχεδιασμός- Προκαταρκτική επισκόπηση σχεδιασμού

151 3. Να έχουμε εξαλείψει οποιαδήποτε ασάφεια στην περιγραφή καθεμιάς περίπτωσης χρήσης και στην αντίστοιχη λογική ακολουθία ενεργειών στο διάγραμμα συνεργασίας 4. Να βεβαιωθούμε ότι προσθέτουμε όλες τις νέες κλάσεις και τα βασικά κατηγορήματα στο διάγραμμα κλάσεων 5. Να διαγράψουμε όποιες μεθόδους εμφανίζονται στο διάγραμμα κλάσεων 6. Να δώσουμε βαρύτητα στο λογικό σχεδιασμό της συμπεριφοράς του συστήματος και όχι στο λεπτομερή σχεδιασμό κλάσεων Αρχικός σχεδιασμός- Προκαταρκτική επισκόπηση σχεδιασμού

152 Σχεδιασμός του Συστήματος – Λεπτομερής Σχεδιασμός Είναι το τέταρτο και πιο σημαντικό βήμα της μεθοδολογίας το οποίο οδηγεί στον λεπτομερή σχεδιασμό της δυναμικής συμπεριφοράς και της στατικής δομής του συστήματος. Το αποτέλεσμα ενός λεπτομερή σχεδιασμού μπορεί εύκολα να μετατραπεί σε κώδικα

153 Σχεδιασμός του Συστήματος – Λεπτομερής Σχεδιασμός Περιλαμβάνει το σχεδιασμό της συμπεριφοράς των αντικειμένων που έχουμε εντοπίσει μέσα από την αντιστοίχηση μεθόδων στις κλάσεις του συστήματος Σε αυτό το βήμα θα ακολουθήσομε μια επαναληπτική διαδικασία, επανεξετάζοντας λεπτομερώς τον αρχικό σχεδιασμό μέσα από τα σενάρια χρήσης και προσπαθούμε να περιγράψουμε επακριβώς πως συνεργάζονται τα αντικείμενα που εντοπίσαμε. Εάν για κάποιο λόγο δεν είμαστε σίγουροι για τα αποτελέσματα κάποιας περιγραφής των προηγούμενων βημάτων τότε επαναλαμβάνουμε το προηγούμενο βήμα και δεν προχωράμε στο βήμα 4

154 Σχεδιασμός του Συστήματος – Λεπτομερής Σχεδιασμός Στόχος είναι να παραχθούν τα πλήρη μοντέλα της στατικής δομής και της δυναμικής συμπεριφοράς του συστήματος  Το μοντέλο της στατικής δομής συνίσταται στο πλήρες διάγραμμα κλάσεων του συστήματος, το οποίο περιλαμβάνει 1. τις κλάσεις υλοποιούν τα αντικείμενα οντοτήτων, 2. τις κλάσεις που υλοποιούν τα συνοριακά αντικείμενα 3. Όποια αντικείμενα ελέγχου κρίνουμε ότι πρέπει να αποτελέσουν διακριτές κλάσεις

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

156 Σχεδιασμός του Συστήματος – Λεπτομερής Σχεδιασμός Επιμέρους στόχοι  Αντιστοίχηση συμπεριφοράς στα συνοριακά αντικείμενα, τα αντικείμενα οντοτήτων, και τους ελεγκτές.  Λεπτομερή σχεδιασμό των αλληλεπιδράσεων κατά την διάρκεια του χρόνου ανάμεσα στα αντικείμενα που εμπλέκονται σε κάθε περίπτωση χρήσης.  Οριστική και πλήρη κατανομή κατηγορημάτων και μεθόδων στις κλάσεις

157 Σχεδιασμός του Συστήματος – Λεπτομερής Σχεδιασμός Βασικές δραστηριότητες 1. Αντιγράφουμε στο αριστερό άκρο της σελίδας το κείμενο που περιγράφει τα βήματα της βασικής ακολουθίας και των εναλλακτικών ακολουθιών ενεργειών (από το μοντέλο των περιπτώσεων χρήσης) 2. Προσθέτουμε σε μια γραμμή στην κορυφή τα αντικείμενα οντοτήτων (από το μοντέλο ευρωστίας)

158 Σχεδιασμός του Συστήματος – Λεπτομερής Σχεδιασμός 3. Προσθέτουμε στην ίδια γραμμή τα συνοριακά αντικείμενα και τους χειριστές. 4. Καταχωρούμε μεθόδους σε κλάσεις 5. Ελέγχουμε αν έχουμε συμπεριλάβει όλη την επιθυμητή δυναμική συμπεριφορά του συστήματος κατά την υλοποίηση της συγκεκριμένης περίπτωσης χρήσης στο αντίστοιχο διάγραμμα ακολουθίας. 6. Εξετάζουμε συνεχώς την περίπτωση να εμφανίζονται στα διαγράμματα ακολουθίας πρότυπα σχεδιασμού λογισμικού 7. Εμπλουτίζουμε το διάγραμμα κλάσεων

159 Σχεδιασμός του Συστήματος – Λεπτομερής Σχεδιασμός Να αποφεύγουμε να σχεδιάσουμε πολλά διαγράμματα ακολουθίας για μια περίπτωση χρήσης και μην ενσωματώσουμε πολλές χρήσης στο ίδιο διάγραμμα Να μην ξεχάσουμε να προσθέσουμε στο αριστερό άκρο κάθε διαγράμματος το κείμενο που περιγράφει την αντίστοιχη περίπτωση χρήσης Να σχεδιάζουμε αναλυτικά ποιο αντικείμενο στέλνει και ποιο λαμβάνει κάθε μήνυμα Να ακολουθήσουμε τους κανόνες σχεδιασμού κλάσεων του αντικειμενοστρεφές Να εμπλουτίσουμε το στατικό μοντέλο του συστήματος

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

161 Σχεδιασμός του Συστήματος – Κρίσιμη Επισκόπηση Σχεδιασμού Η διαδικασία περιλαμβάνει  Επιβεβαίωση ότι για κάθε περίπτωση χρήσης, η ροή μηνυμάτων στο διάγραμμα ακολουθίας ταιριάζει με την ακολουθία ενεργειών στην περιγραφή της περίπτωσης χρήσης (βασική & εναλλακτικές)  Έλεγχο της ορθότητας της ροής ελέγχου σε κάθε διάγραμμα ακολουθίας με έλεγχο της ορθότητα της κατεύθυνσης μηνυμάτων και διασφάλιση της συνεχούς λειτουργίας του συστήματος. Δεν πρέπει να υπάρχει μεταφορά του ελέγχου ανάμεσα σε αντικείμενα χωρίς ανταλλαγή μηνύματος

162 Σχεδιασμός του Συστήματος – Κρίσιμη Επισκόπηση Σχεδιασμού  Έλεγχο της καλής κατανομής μεθόδων σε κλάσεις 1.Επαναχρησιμοποιησμότητα: όσο πιο γενική είναι μι κλάση τόσο πιο επαναχρησιμοποιήσιμη είναι 2.Εφαρμοσιμότητα: πρέπει να εξετάσουμε αν μια μέθοδο ταιριάζει στην κλάση 3.Πολυπλοκότητα: εξετάζουμε πόσο δύσκολα υλοποιείται μια μέθοδο σε μια ή σε άλλη κλάση 4.Εσωτερική γνώμη υλοποίησης της κλάσης: εξετάζουμε αν η υλοποίηση μιας μεθόδους μέσα σε μια κλάση απαιτεί γνώση εσωτερικών λεπτομερειών

163 Σχεδιασμός του Συστήματος – Κρίσιμη Επισκόπηση Σχεδιασμού  Έλεγχο της ποιότητας των κλάσεων. Θέλουμε να ικανοποιούνται τα κριτήρια 1.Σύζευξη: θέλουμε χαμηλή σύζευξη – μεγάλη ανεξαρτησία των κλάσεων 2.Συνοχή: θέλουμε μεγάλη συνοχή μεταξύ των κατηγορημάτων και μεθόδων της κλάσης 3.Επάρκεια: κάθε κλάση πρέπει να ενθυλακώνει πολλά αντικείμενα του πεδίου εφαρμογής ώστε να αποτελεί αυτόνομο λογικό τμήμα του συστήματος 4.Πληρότητα: στοχεύουμε σε υψηλή πληρότητα έτσι ώστε μια κλάση να είναι επαναχρησιμοποιήσιμη σε παρόμοια πεδία εφαρμογής 5. Πρωτογένεια

164 Σχεδιασμός του Συστήματος – Κρίσιμη Επισκόπηση Σχεδιασμού  Διασφάλιση ότι τα διαγράμματα ακολουθίας περιγράφουν στη μεγαλύτερη δυνατή λεπτομέρεια τον τρόπο υλοποίησης του συστήματος συμπεριλαμβάνοντας πρότυπα σχεδιασμού και τα απαραίτητα στοιχεία της τεχνικής αρχιτεκτονικής και τον τρόπο με τον οποίο τα πρότυπα και τα στοιχεία αυτά επηρεάζουν την υλοποίηση του συστήματος

165 Σχεδιασμός του Συστήματος – Κρίσιμη Επισκόπηση Σχεδιασμού Πρέπει να προσέξουμε 1. Να μην εμπλέξουμε άτομα που δεν έχουν γνώσεις τεχνολογίας λογισμικού ή προγραμματισμού 2. Να ελέγξουμε κάθε σενάριο λειτουργίας που θα υλοποιήσουμε στο σύστημα 3. Να ελέγξουμε πολύ προσεκτικά το κείμενο που περιγράφει κάθε περίπτωση χρήσης με το αντίστοιχο διάγραμμα ακολουθίας και ταυτόχρονα να εξετάσουμε προέλευση και προορισμό του κάθε μηνύματος ου διαγράμματος. 4. Να εφαρμόσουμε τα κριτήρια κατανομής μεθόδων σε κλάσεις 5. Να εφαρμόσουμε τα κριτήρια ποιότητας του σχεδιασμού των κλάσεων

166 Σχεδιασμός του Συστήματος – Κρίσιμη Επισκόπηση Σχεδιασμού 6. Να βεβαιωθούμε ότι γνωρίζουμε όλες τις λεπτομέρειες που χρειαζόμαστε για να υλοποιήσουμε το σύστημα 7. Να αποφύγουμε τη συγγραφή κώδικα οποιαδήποτε μορφής

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

168 Παράδειγμα χρήσης ICONIX – Εντοπισμός Ουσιαστικών Εντοπίζουμε τα ουσιαστικά: επίσκεψη, ιατρείο, γραμματεία, ασθενής, ιστοσελίδα, καταχώριση επισκέψεων, αναγνώριση χρήστη, εξουσιοδοτημένος χρήστης, κωδικός χρήστη, όνομα ασθενούς, όνομα ιατρού, ημερομηνία και ώρα επίσκεψης, ημέρα εβδομάδας και ώρα ημέρας, τμήμα επίσκεψης, διάρκεια τμήματος, αναφορά επισκέψεων ημέρας εβδομάδας.

169 Παράδειγμα χρήσης ICONIX – Εντοπισμός κλάσεων Από αυτά μπορούμε να ισχυριστούμε ότι το σύστημα θα περιέχει τις κλάσεις:  Ασθενής, Ιατρός, Γραμματέας, Επίσκεψη, Αναφορά Επισκέψεων Από την εμπειρία μας προσθέτουμε τις κλάσεις  Ιστορικό (που σχετίζεται με κάθε ασθενή) Διάγνωση (σχετίζεται με κάθε επίσκεψη) Ημερολόγιο (από το οποίο προέρχονται οι ημέρες και ώρες των επισκέψεων)

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

171 Διαγράμματα Περιπτώσεων Χρήσης Εκτός από τη γραμματεία και τους πελάτες που προαναφέραμε, εντοπίζουμε ως χειριστή του συστήματος και το υποσύστημα βάσης δεδομένων το οποίο διατηρεί τα στοιχεία ιατρών και των πελατών. Το υποσύστημα αυτό είναι ανεξάρτητο

172 Διαγράμματα Περιπτώσεων Χρήσης – χειριστής πελάτης

173 Διαγράμματα Περιπτώσεων Χρήσης – χειριστής γραμματεία

174 Διαγράμματα Περιπτώσεων Χρήσης Επειδή πρόκειται για διαλογικό σύστημα δίνουμε στους χρήστες τη δυνατότητα να χρησιμοποιούν το ημερολόγιο για να κάνουν καταχώρηση ή διαγραφής μιας επίσκεψης Κάθε βασική περίπτωση χρήση προϋποθέτει την ταυτοποίηση του χρήστη, άρα συνδέεται με σχέση include με την περίπτωση χρήσης «Είσοδος στο σύστημα»

175

176

177

178 Διάγραμμα Συνεργασίας για «Διαγραφή επίσκεψης

179 Διάγραμμα ακολουθίας – Διαγραφή Επίσκεψης