ΤΕΧΝΟΛΟΓΙΑ ΛΟΓΙΣΜΙΚΟΥ (SOFTWARE ENGINEERING) Διαχείριση πολυπλοκότητας, έννοιες, επισκόπηση UML, βασικοί συμβολισμοί και διαγράμματα.

Παρουσίαση με θέμα: "ΤΕΧΝΟΛΟΓΙΑ ΛΟΓΙΣΜΙΚΟΥ (SOFTWARE ENGINEERING) Διαχείριση πολυπλοκότητας, έννοιες, επισκόπηση UML, βασικοί συμβολισμοί και διαγράμματα."— Μεταγράφημα παρουσίασης:

1 ΤΕΧΝΟΛΟΓΙΑ ΛΟΓΙΣΜΙΚΟΥ (SOFTWARE ENGINEERING) Διαχείριση πολυπλοκότητας, έννοιες, επισκόπηση UML, βασικοί συμβολισμοί και διαγράμματα

2 Θέματα που θα παρουσιάσουμε
Διαχείριση πολυπλοκότητας Αφαίρεση και μοντελοποίηση Αποσύνθεση Ιεραρχίες Έννοιες συστημάτων Ανάπτυξη βασιζόμενη σε μοντέλα Επισκόπηση UML Γενικά για τη UML

3 Ποιο είναι το πρόβλημα με το διάγραμμα που βλέπουμε;

4 Αφαίρεση Τα πολύπλοκα συστήματα είναι δύσκολο να κατανοηθούν
Το φαινόμενο του 7 ± 2: η βραχυπρόθεσμη μνήμη μας (short term memory) μπορεί να αποθηκεύσει 7 ± 2 ταυτόχρονα (περιορισμός του εγκέφαλου). Ο αριθμός μητρώου: Κατάτμηση (chunking): Ομαδοποίηση αντικειμένων για μείωση πολυπλοκότητας Κωδικός τμήματος, έτος εγγραφής, αριθμός έτους Αριθμός μητρώου Κωδικός τμήματος Έτος εγγραφής Αριθμός έτους

5 Αφαίρεση Η αφαίρεση μας επιτρέπει να αγνοήσουμε λεπτομέρειες που (στην εκάστοτε φάση) δεν είναι σημαντικές Μπορούμε να θεωρήσουμε την αφαίρεση από δύο προοπτικές: Η αφαίρεση ως δραστηριότητα: Η αφαίρεση είναι μία διαδικασία συλλογισμού όπου οι ιδέες διαχωρίζονται από τα αντικείμενα Η αφαίρεση ως οντότητα: Η αφαίρεση είναι η ιδέα που προκύπτει από μία διαδικασία συλλογισμού, στην οποία οι ιδέες έχουν διαχωριστεί από τα αντικείμενα Οι ιδέες μπορούν να εκφράζονται μέσω μοντέλων

6 Μοντέλα Το μοντέλο είναι η αφαίρεση ενός συστήματος Χρήσιμο για:
Το μοντέλο είναι η αφαίρεση ενός συστήματος Χρήσιμο για: Συστήματα που δεν υπάρχουν πια Συστήματα που υπάρχουν Συστήματα που πρόκειται να κατασκευαστούν στο μέλλον

7 Χρήση μοντέλων για περιγραφή συστήματα λογισμικού
Υπάρχουν διάφορα μοντέλα: Το μοντέλο αντικειμένων: ποια είναι η δομή του συστήματος; Το λειτουργικό μοντέλο: Ποιες είναι οι λειτουργίες του συστήματος; Το δυναμικό μοντέλο: Πώς αντιδρά το σύστημα στα εξωτερικά συμβάντα; Μοντέλο συστήματος: Μοντέλο αντικειμένων + Λειτουργικό Μοντέλο + Δυναμικό μοντέλο

8 Ποια άλλα μοντέλα χρησιμοποιούμε για περιγραφή συστημάτων λογισμικού; [1/3]
Μοντέλο δράσεων (task model) Διάγραμμα PERT (program evaluation review technique): ποιες είναι οι εξαρτήσεις μεταξύ των δράσεων; Στόχος να αποτυπωθούν οι δράσεις, οι εξαρτήσεις και οι διάρκειες και να βρεθεί η κρίσιμη διαδρομή που δίνει τη διάρκεια του έργου Το διάγραμμα pert του παραδείγματος έχει δύο κρίσιμες διαδρομές, (10  30  40  50) και (10  20  50) που δίνουν διάρκεια έργου 7 μήνες.

9 Ποια άλλα μοντέλα χρησιμοποιούμε για περιγραφή συστημάτων λογισμικού; [2/3]
Μοντέλο δράσεων (task model) Χρονοπρογραμματισμός (schedule): Πώς μπορεί να επιτευχθεί ο στόχος μέσα σε χρονικό όριο; Οργανωτικό διάγραμμα: ποιοι είναι οι ρόλοι εντός του έργου;

10 Ποια άλλα μοντέλα χρησιμοποιούμε για περιγραφή συστημάτων λογισμικού; [3/3]
Μοντέλο ζητημάτων (issues model) Ποια ζητήματα είναι ανοικτά και ποια έχουν κλείσει; Τι με εμποδίζει από το να συνεχίσω; Ποιοι οι περιορισμοί που έχουν τεθεί από τον πελάτη; Ποιες αποφάσεις πρέπει να ληφθούν; ... όλα αυτά οδηγούν σε ενέργειες που πρέπει να γίνουν

11 Παράδειγμα μοντέλου ζητημάτων
Πού να κωδικοποιήσω τον έλεγχο; Πρόταση 2: Στη βάση δεδομένων Πρόταση 1: Στη διεπαφή χρήστη Υπέρ: Ταχύτερη ανταπόκριση για τον χρήστη Κατά: Ο έλεγχος δεν καλύπτει εναλλακτικές μεθόδους εισαγωγής στη Β.Δ. Υπέρ: Καλύπτονται όλες οι μέθοδοι εισαγωγής Κατά: Αν η Javascript είναι απενεργοποιημένη, δεν λειτουργεί Κατά: Λιγότερο φιλικό μήνυμα σφάλματος

12 Παράδειγμα μοντέλου ζητημάτων
Πού να κωδικοποιήσω τον έλεγχο; Απόφαση 1: επιλέγουμε το (2) γιατί οι χρήστες είναι λίγοι και ειδικοί Πρόταση 2: Στη βάση δεδομένων Πρόταση 1: Στη διεπαφή χρήστη Υπέρ: Ταχύτερη ανταπόκριση για τον χρήστη Κατά: Ο έλεγχος δεν καλύπτει εναλλακτικές μεθόδους εισαγωγής στη Β.Δ. Υπέρ: Καλύπτονται όλες οι μέθοδοι εισαγωγής Κατά: Αν η Javascript είναι απενεργοποιημένη, δεν λειτουργεί Κατά: Λιγότερο φιλικό μήνυμα σφάλματος

13 Παράδειγμα μοντέλου ζητημάτων
Απόφαση 2: επιλέγουμε το (1) γιατί η εφαρμογή χρησιμοποιείται και από άλλους χρήστες Πού να κωδικοποιήσω τον έλεγχο; Απόφαση 1: επιλέγουμε το (2) γιατί οι χρήστες είναι λίγοι και ειδικοί Πρόταση 2: Στη βάση δεδομένων Πρόταση 1: Στη διεπαφή χρήστη Πρόταση 3: Και στα δύο επίπεδα Υπέρ: Ταχύτερη ανταπόκριση για τον χρήστη Κατά: Ο έλεγχος δεν καλύπτει εναλλακτικές μεθόδους εισαγωγής στη Β.Δ. Υπέρ: Καλύπτονται όλες οι μέθοδοι εισαγωγής Κατά: Αν η Javascript είναι απενεργοποιημένη, δεν λειτουργεί Κατά: Λιγότερο φιλικό μήνυμα σφάλματος

14 Τεχνική αντιμετώπισης πολυπλοκότητας: αποσύνθεση [1/8]
Η αποσύνθεση (decomposition) είναι μία τεχνική για να αντιμετωπίσουμε την πολυπλοκότητα που ακολουθεί τη στρατηγική διαίρει και βασίλευε (divide and conquer) Δύο κύριοι τύποι αποσύνθεσης: Λειτουργική αποσύνθεση Αντικειμενοστρεφής αποσύνθεση Το σύστημα αποσυντίθεται σε ενότητες Κάθε ενότητα είναι μία μείζων λειτουργία της εφαρμογής Οι ενότητες μπορούν να αποσυντίθενται σε μικρότερες ενότητες

15 Τεχνική αντιμετώπισης πολυπλοκότητας: αποσύνθεση [2/8]
Παράδειγμα λειτουργικής αποσύνθεσης (με χρήση διαγραμμάτων ροής δεδομένων) (1) σύστημα και αλληλεπιδρώσες οντότητες περιβάλλοντος

16 Τεχνική αντιμετώπισης πολυπλοκότητας: αποσύνθεση [3/8]
Παράδειγμα λειτουργικής αποσύνθεσης (με χρήση διαγραμμάτων ροής δεδομένων) (2) περαιτέρω ανάλυση του συστήματος δανεισμού

17 Τεχνική αντιμετώπισης πολυπλοκότητας: αποσύνθεση [4/8]
Παράδειγμα λειτουργικής αποσύνθεσης (με χρήση διαγραμμάτων ροής δεδομένων) (3) περαιτέρω ανάλυση της λειτουργίας διαχείρισης δανεισμού

18 Τεχνική αντιμετώπισης πολυπλοκότητας: αποσύνθεση [5/8]
Αντικειμενοστρεφής αποσύνθεση Το σύστημα αποσυντίθεται σε κλάσεις (αντικείμενα) Κάθε κλάση είναι μία μείζων οντότητα της εφαρμογής Οι κλάσεις μπορούν να αποσυντίθενται σε μικρότερες κλάσεις Ποια αποσύνθεση είναι καλύτερη; Λειτουργική ή αντικειμενοστρεφής;

19 Τεχνική αντιμετώπισης πολυπλοκότητας: αποσύνθεση [6/8]
Η λειτουργικότητα συνήθως διατέμνει όλη την έκταση του συστήματος Π.χ. αλλαγή στη μοντελοποίηση ενός φοιτητή  συντήρηση δομών αποθήκευσης, οθονών παρουσίασης & εισαγωγής στοιχείων, βάσης δεδομένων, κώδικα που χειρίζεται οποιοδήποτε στοιχείο του φοιτητή Άρα ο συντηρητής πρέπει να κατανοεί όλο το σύστημα για να κάνει τις αλλαγές Συνέπεια Ο κώδικας γίνεται δυσχερής στην κατανόηση Ο κώδικας γίνεται πολύπλοκος και σχεδόν αδύνατο να συντηρηθεί Η διεπαφή του χρήστη δεν είναι διαισθητική Οι αναπαραστάσεις δεδομένων στη βάση είναι ημιβέλτιστες Έχει αποδειχθεί ότι η λειτουργική προσέγγιση δεν μπορεί να ανταποκριθεί σε έργα άνω των γραμμών κώδικα (συνήθη μεγέθη σήμερα: ) Οι συνέπειες είναι πολύ σημαντικές, διότι το 60%-75% του προϋπολογισμού για λογισμικό σχετίζεται με τη συντήρηση

20 Τεχνική αντιμετώπισης πολυπλοκότητας: αποσύνθεση [7/8]
Παράδειγμα: Λειτουργική αποσύνθεση στα «αυτόματα σχήματα» του Microsoft Office Autoshape Draw Change Change Rectangle Change Oval Change Circle Draw Rectangle Draw Oval Draw Circle Τι θα συμβεί αν προσθέσουμε ένα καινούργιο σχήμα; Πρέπει σε όλες τις λειτουργίες να προβλέψουμε εξειδίκευση για το νέο είδος σχήματος

21 Τεχνική αντιμετώπισης πολυπλοκότητας: αποσύνθεση [8/8]
Αντικειμενοστρεφής αποσύνθεση Autoshape Draw() Change() Rectangle Draw() Change() Oval Draw() Change() Circle Draw() Change()

22 Προσδιορισμός κλάσεων
Βασική πράξη στην αντικειμενοστρεφή αποσύνθεση Είναι δυνατόν να γίνεται για ένα νέο σύστημα (σχεδιασμός εξ αρχής - greenfield engineering) Είναι δυνατόν να γίνεται για ένα υπάρχον σύστημα (ανασχεδιασμός – reengineering) Είναι δυνατόν να θέλουμε να φτιάξουμε μία βασισμένη σε κλάσεις διεπαφή για ένα υπάρχον σύστημα (σχεδιασμός διεπαφών – interface engineering) Ανάλογα με τον σκοπό του συστήματος μπορούμε να εντοπίσουμε αντικείμενα διαφορετικού είδους Συνεπώς πρώτα προσδιορίζουμε τον σκοπό του συστήματος!

23 Προσδιορισμός κλάσεων ανάλογα με τον σκοπό
Παράδειγμα: «συγγράμματα μαθήματος» Σκοπός: να καταγράφονται τα συγγράμματα για τον οδηγό σπουδών Αρκεί η κλάση «Μάθημα» όπου υπάρχει ένα πεδίο κειμένου «Συγγράμματα» Να αποστέλλεται ενημερωτικό στους φοιτητές που παρακολουθούν το μάθημα όταν είναι διαθέσιμο το σύγγραμμα στη βιβλιοθήκη Χρειάζεται και η κλάση «Φοιτητής» που έχει τουλάχιστον το και σύνδεση μεταξύ κλάσεων «Μάθημα» και «Φοιτητής» Να γίνονται παραγγελίες βιβλίων Χρειάζονται ξεχωριστές κλάσεις «Σύγγραμμα», «Εκδοτικός οίκος», «Δήλωση μαθημάτων» (για έλεγχο) κ.λπ.

24 Ιεραρχία Μέσω της αφαίρεσης προσδιορίζουμε κλάσεις και αντικείμενα
Μέσω της αφαίρεσης προσδιορίζουμε κλάσεις και αντικείμενα Που ουσιαστικά είναι τμήματα πληροφορίας Ένας συμπληρωματικός τρόπος για να αντιμετωπίσουμε την πολυπλοκότητα είναι να εγκαθιδρύσουμε συσχετίσεις ανάμεσα στα τμήματα Μία από τις πιο σημαντικές συσχετίσεις είναι η ιεραρχία Και από όλες τις ιεραρχίες, υπάρχουν δύο με μεγάλο ενδιαφέρον: «τμήμα-του» (part of) «είναι-ένα» (is-a ή is-kind-of)

25 Παράδειγμα ιεραρχίας «τμήμα-του» (συνάθροιση)
Υπολογιστής Συσκευές εισόδου-εξόδου Κ.Μ.Ε. Μνήμη Κρυφή μνήμη Αριθμητική-Λογική Μονάδα Καταχωρητές

26 Παράδειγμα ιεραρχίας «είναι-ένα» (ταξονομία)
Συσκευές εισόδου-εξόδου Συσκευές αποθήκευσης δεδομένων Συσκευές δικτύου Συσκευές εισόδου χρήστη Σκληρός δίσκος Flash disk Μαγνητική ταινία Πληκτρο-λόγιο Ποντίκι Joystick

27 Σύνοψη Έχουμε τρεις τρόπους να χειριστούμε την πολυπλοκότητα
Αφαίρεση, αποσύνθεση, ιεραρχία Η αντικειμενοστρεφής αποσύνθεση είναι καλή προσέγγιση Ανάλογα όμως με τον σκοπό του συστήματος μπορούμε να καταλήξουμε σε διαφορετικά αντικείμενα Μπορούμε να οδηγηθούμε στα σωστά αντικείμενα; Πρέπει να ξεκινήσουμε με μία περιγραφή της λειτουργικότητας του συστήματος, μετά να συνεχίσουμε στην περιγραφή της δομής του. Σημαντική είναι επίσης η οριοθέτηση του συστήματος τι ανήκει δηλαδή στο σύστημα και τι όχι Διατάσσουμε τις δραστηριότητες Η διάταξη μας οδηγεί στον κύκλο ζωής του λογισμικού

28 Συστήματα Ένα σύστημα είναι ένα οργανωμένο σύνολο από αλληλεπιδρώντα μέρη Στα φυσικά συστήματα, δεν είναι γνωστός ο σκοπός του Στα σχεδιασμένα συστήματα, ο σκοπός τους είναι αυτός για τον οποίο φτιάχτηκαν Τα τμήματα των συστημάτων μπορεί να θεωρηθούν με τη σειρά τους ως συστήματα Αυτά καλούνται υποσυστήματα Παραδείγματα συστημάτων Φυσικά: σύμπαν, γη, ωκεανός Σχεδιασμένα: Αεροπλάνο, ρολόι, GPS Υποσυστήματα: τουρμπίνα, μπαταρία, δορυφόρος

29 Συστήματα, Μοντέλα, Όψεις, Σημειογραφίες
Ένα μοντέλο είναι μία αφαίρεση που περιγράφει ένα σύστημα ή ένα υποσύστημα Μία όψη απεικονίζει συγκεκριμένες πλευρές ενός μοντέλου Μία σημειογραφία είναι ένα σύνολο από κανόνες για την αναπαράσταση μοντέλων είτε με γραφικό τρόπο είτε με κείμενο Υπάρχουν τόσο τυπικές συντομογραφίες όσο και άτυπες Παραδείγματα για το σύστημα: αεροπλάνο Μοντέλα: εξομοιωτής πτήσης, μοντέλο κλίμακας Όψεις: σχέδια των συνιστωσών του αεροπλάνου, διάγραμμα καλωδιώσεων ρεύματος, σύστημα καυσίμων, το ηχητικό κύμα που δημιουργεί το αεροπλάνο

30 Συστήματα, μοντέλα, Όψεις, Σημειογραφίες – άτυπη αναπαράσταση
Εξομοιωτής πτήσης Αεροπλάνο Σύστημα καυσίμων Μοντέλο 2 Όψη 2 Όψη 1 Σύστημα Όψη 3 Μοντέλο 1 Καλωδιώσεις ρεύματος Σχέδια Μοντέλο κλίμακας Οι όψεις και τα μοντέλα σε πολύπλοκα συστήματα συνήθως επικαλύπτονται

31 Συστήματα, μοντέλα, Όψεις, Σημειογραφίες – σημειογραφία UML
Διάγραμμα κλάσεων Σύστημα Μοντέλο * Όψη * Απεικονίζεται από Περιγράφεται από Αεροπλάνο: Σύστημα Διάγραμμα αντικειμένων Μοντέλο κλίμακας:Μοντέλο Εξομοιωτής πτήσης:Μοντέλο Σύστημα καυσίμων: Όψη Ηλεκτρικές καλωδιώσεις: Όψη Σχέδιο: Όψη

32 Ανάπτυξη καθοδηγούμενη από μοντέλα (model-driven development) [1/2]
Είναι η «τελευταία λέξη» στην ανάπτυξη λογισμικού Δημιουργία ενός ανεξάρτητου από πλατφόρμα μοντέλου της λειτουργικότητας και της συμπεριφοράς της εφαρμογής Περιγράφεται το μοντέλο με σημειογραφία μοντελοποίησης (UML) Μετατρέπεται το μοντέλο σε μοντέλο για συγκεκριμένη πλατφόρμα (platform specific) Δημιουργία εκτελέσιμου από το μοντέλο για συγκεκριμένη πλατφόρμα

33 Ανάπτυξη καθοδηγούμενη από μοντέλα (model-driven development) [2/2]
Πλεονεκτήματα: Ο κώδικας παράγεται (σε κάποιο βαθμό) από τα μοντέλα Το ανεξάρτητο από πλατφόρμα μοντέλο παραμένει σταθερό, ανεξάρτητα από την πρόοδο της τεχνολογίας Η μεταφερσιμότητα και η διαλειτουργικότητα είναι ενσωματωμένες στο μοντέλο ανάπτυξης Δείτε: OMG: Object Management Group

34 Ανάπτυξη λογισμικού καθοδηγούμενη από μοντέλα [1/2]
Ξεκινάμε με αποτύπωση της πραγματικότητας Σε ένα χρηματιστήριο υπόκεινται σε διαπραγμάτευση μετοχές πολλών εταιρειών. Κάθε εταιρεία προσδιορίζεται από μία συντομογραφία Συνεχίζουμε με την ανάλυση που μας δίνει το μοντέλο δεδομένων ανάλυσης (ή μοντέλο πεδίου) [διάγραμμα κλάσεων UML) StockExchange * * Company Lists tickerSymbol Είναι σωστή η πληθικότητα * στις δύο πλευρές της συσχέτισης;

35 Ανάπτυξη λογισμικού καθοδηγούμενη από μοντέλα [2/2]
Ακολουθεί η υλοποίηση (παράδειγμα σε Java) public class StockExchange { public m_Company = new Vector(); }; public class Company { public int m_tickerSymbol; public Vector m_StockExchange = new Vector();

36 Παράδειγμα ανάπτυξης καθοδηγούμενης από μοντέλα: Apache Cordova
Περιβάλλον ανάπτυξης για εφαρμογές κινητών τηλεφώνων / smartphones Βασίζεται στις τεχνολογίες HTML, CSS & JS Η ανάπτυξη γίνεται μία φορά και λειτουργεί σε όλες τις συσκευές Δωρεάν διάθεση, ανοικτός κώδικας Αντίστοιχα υπάρχουν και άλλες πλατφόρμες π.χ. Adobe phonegap, Appcelerator

37 Παράδειγμα ανάπτυξης καθοδηγούμενης από μοντέλα: Apache Cordoba

38 Παράδειγμα ανάπτυξης καθοδηγούμενης από μοντέλα: Apache Cordoba

39 Η UML – Unified Modeling Language
Πρότυπο που δεν ανήκει σε συγκεκριμένο κατασκευαστή (nonproprietary) για τη μοντελοποίηση συστημάτων (όχι μόνο λογισμικού) Σύγκλιση συμβολισμών που χρησιμοποιούνται σε αντικειμενοστρεφείς μεθόδους OMT (James Rumbaugh and colleagues) Booch (Grady Booch) OOSE (Ivar Jacobson) Συντηρείται από τον OMG, τρέχουσα έκδοση 2.5 Δείτε: Εμπορικά εργαλεία: Rational (IBM),Together (Borland), Visual Architect (business processes, BCD) Εργαλεία ανοικτού λογισμικού: ArgoUML, StarUML, Umbrello

40 UML: χρειάζεται όλη; Στην έκδοση 2.5:
794 σελίδες για τον προσδιορισμό της γλώσσας! Ευτυχώς ισχύει ο κανόνας Pareto (κανόνας «σημαντικών ολίγων» ή κανόνας 80-20) Στην περίπτωσή μας: «Με το 20% της UML μπορούμε να μοντελοποιήσουμε πλήρως το 80% των προβλημάτων» Θα εστιάσουμε στο συγκεκριμένο 20%

41 Βασικά διαγράμματα Διαγράμματα περιπτώσεων χρήσης (use case diagrams)
Περιγράφουν τη λειτουργική συμπεριφορά του συστήματος από την οπτική του χρήστη Διαγράμματα κλάσεων Περιγράφουν τη στατική δομή του συστήματος: Διαγράμματα ακολουθίας Περιγράφουν τη δυναμική συμπεριφορά ανάμεσα σε αντικείμενα του συστήματος Διαγράμματα μηχανής καταστάσεων Περιγράφουν τη δυναμική συμπεριφορά μεμονομένων αντικειμένων Διαγράμματα δραστηριότητας Περιγράφουν τη δυναμική συμπεριφορά του συστήματος, και συγκεκριμένα της ροής εργασιών

42 Βασικοί συμβολισμοί της UML
H UML χρησιμοποιεί γραφικές αναπαραστάσεις με μορφή γραφημάτων που έχουν κόμβους και ακμές Οι κόμβοι αναπαριστούν οντότητες και σημειώνονται με: Παραλληλόγραμμα αν πρόκειται για κλάσεις ή στιγμιότυπα Ελλείψεις αν πρόκειται για λειτουργίες Τα ονόματα των κλάσεων δεν υπογραμμίζονται Book Τα ονόματα των στιγμιοτύπων υπογραμμίζονται DonQuixote:Book Μία ακμή μεταξύ δύο κόμβων δηλώνει μία συσχέτιση μεταξύ των κόμβων

43 Μια γρήγορη ματιά: Διαγράμματα περιπτώσεων χρήσης
Οι περιπτώσεις χρήσης χρησιμοποιούνται για την εξαγωγή (elicitation) και περιγραφή των λειτουργικών απαιτήσεων Είναι διηγήσεις χρήσης του συστήματος λογισμικού – κάνουν συστηματική την καταγραφή των σεναρίων αλληλεπίδρασης του συστήματος με το περιβάλλον του

44 Μια γρήγορη ματιά: Διαγράμματα περιπτώσεων χρήσης
Κατηγοριοποίηση Περίπτωση χρήσης Μάθημα Δώσε διάλεξη Διδάσκων Actor Βάλε εργασία Φοιτητής Βοηθός διδασκαλίας Λύσε την εργασία Όριο συστήματος Τα διαγράμματα περιπτώσεων χρήσης αναπαριστούν τη λειτουργικότητα του συστήματος από την προοπτική του χρήστη

45 Μια γρήγορη ματιά: Διαγράμματα κλάσεων
Είναι διαγράμματα που απεικονίζουν τη στατική δομή του συστήματος, δείχνοντας κλάσεις, ιδιότητες, λειτουργίες και σχέσεις μεταξύ κλάσεων Χρησιμοποιούνται στην ανάλυση των απαιτήσεων και στη σχεδίαση του λογισμικού Μοντελοποιούν αντικείμενα που θα είναι και τα δομικά στοιχεία του λογισμικού που θα αναπτύξουμε Θεωρούνται από τα σημαντικότερα διαγράμματα της UML

46 Μια γρήγορη ματιά: Διαγράμματα κλάσεων
Συσχέτιση Κλάση Πολλαπλότητα SimpleWatch 1 1 1 1 2 1 2 1 PushButton Display Battery Time Τα διαγράμματα κλάσεων αναπαριστούν τη δομή του συστήματος

47 Μια γρήγορη ματιά: Διαγράμματα κλάσεων
Συσχέτιση Κλάση Πολλαπλότητα Watch 1 1 1 1 2 1 2 1 PushButton LCDDisplay Battery Time state Now push() release() Load blinkIdx blinkSeconds() blinkMinutes() blinkHours() stopBlinking() referesh() Λειτουργίες Χαρακτηριστικό

48 Μια γρήγορη ματιά: διαγράμματα ακολουθίας
Τα διαγράμματα κλάσεων παρέχουν την στατική όψη (δομή) των κλάσεων Τα διαγράμματα ακολουθίας (sequence diagrams) παρέχουν τη δυναμική όψη, όπως και τα διαγράμματα επικοινωνίας Εμφανίζουν την επικοινωνία αντικειμένων μέσω της ανταλλαγής μηνυμάτων

49 Μια γρήγορη ματιά: διαγράμματα ακολουθίας
Actor Μήνυμα Αντικείμενο Γραμμή ζωής :WatchUser :Watch :LCDDisplay :Time pressButton1() blinkHours() pressButton1() blinkMinutes() pressButton2() incrementMinutes() refresh() pressButton1and2() commitNewTime() stopBlinking() Ενεργοποίηση Τα διαγράμματα ακολουθίας αναπαριστούν τη συμπεριφορά του συστήματος με μορφή μηνυμάτων (αλληλεπιδράσεων) μεταξύ αντικειμένων

50 Μια γρήγορη ματιά: διαγράμματα μηχανής καταστάσεων
Τα διαγράμματα μηχανής καταστάσεων (state machine diagrams) χρησιμοποιούνται για τη μοντελοποίηση της διακριτής συμπεριφοράς κάποιου συστήματος. Η συμπεριφορά του συστήματος μοντελοποιείται ως η μετάβαση από μία κατάσταση σε κάποια άλλη. Τα διαγράμματα μηχανής καταστάσεων μπορούν να χρησιμοποιηθούν και για τη μοντελοποίηση της συμπεριφοράς των αντικειμένων. Κατάσταση αντικειμένων: το σύνολο των τιμών των ιδιοτήτων σε κάποια χρονική στιγμή.

51 Μια γρήγορη ματιά: διαγράμματα μηχανής καταστάσεων
Αρχική κατάσταση Συμβάν πάτημαΚουμπιού2 πάτημαΚουμπιού1&2 Αναβόσβησε ώρες Αύξησε ώρες μετάβαση πάτημαΚουμπιού1 πάτημαΚουμπιού1&2 κατάσταση πάτημαΚουμπιού2 Αύξησε λεπτά Αναβόσβησε λεπτά πάτημαΚουμπιού1 Σταμάτα να αναβοσβήνεις Αναβόσβησε δευτερόλεπτα πάτημαΚουμπιού2 Αύξησε δευτερόλεπτα Τελική κατάσταση Αναπαριστά τη συμπεριφορά ενός μοναδικού αντικειμένου την οποία κρίνουμε ενδιαφέρουσα.

52 Άλλοι συμβολισμοί της UML
Διαγράμματα θέσης σε λειτουργία για μοντελοποίηση διαμορφώσεων Χρήσιμο για έλεγχο και διαχείριση εκδόσεων Θα εισάγουμε τις σημειογραφίες σταδιακά, όταν τις χρειαζόμαστε Η UML πλέον ενσωματώνει την OCL (Object constraint language) για ορισμό περιορισμών στα αντικείμενα (δείτε: Παράδειγμα αμετάβλητης (invariant): inv: self.age >= 0 Παράδειγμα προ-συνθήκης (precondition) context Auction::placeBid(bidder:Id, bid:Money) pre : not bidder.oclIsUndefined() pre : not bid.oclIsUndefined() pre : bid.currency = self.bids->first().amount.currency pre : bid > self.currentBid().money