ΜΟΝΤΕΛΟ ΠΕΡΙΠΤΩΣΕΩΝ ΧΡΗΣΗΣ (USE CASEs)

Παρουσίαση με θέμα: "ΜΟΝΤΕΛΟ ΠΕΡΙΠΤΩΣΕΩΝ ΧΡΗΣΗΣ (USE CASEs)"— Μεταγράφημα παρουσίασης:

1 ΜΟΝΤΕΛΟ ΠΕΡΙΠΤΩΣΕΩΝ ΧΡΗΣΗΣ (USE CASEs)
09:26 Μηχανική Λογισμικού Ι

2 ΜΟΝΤΕΛΟ ΠΕΡΙΠΤΩΣΕΩΝ ΧΡΗΣΗΣ
ΜΟΝΤΕΛΟ ΠΕΡΙΠΤΩΣΕΩΝ ΧΡΗΣΗΣ 09:26 Μηχανική Λογισμικού Ι

3 09:26 Μηχανική Λογισμικού Ι

4 Περιπτώσεις Χρήσης (Προδιαγραφές Απαιτήσεων)
Ιδέα του Jacobson (’92, OOSE) μηχανισμός ανακάλυψης και καταγραφής των λειτουργικών απαιτήσεων ιστορίες χρήσης του συστήματος εργαλείο ανάλυσης – ακόμη και σε μη Α/Σ έργα Η ΕΔ ορίζει το μοντέλο περιπτώσεων χρήσης στο γνωστικό πεδίο των Απαιτήσεων 09:26 Μηχανική Λογισμικού Ι

5 Στόχοι Οι πελάτες και οι τελικοί χρήστες έχουν στόχους, γνωστούς ως ανάγκες, οι οποίοι περιμένουν να εκπληρωθούν από τα συστήματα υπολογιστών. ο καλύτερος τρόπος διατύπωσης & τεκμηρίωσης θα πρέπει να είναι: απλός και οικείος με τους εμπλεκόμενους, συμβάλλοντας έτσι τόσο στον διατύπωσή τους όσο και στην αξιολόγησή τους. 09:26 Μηχανική Λογισμικού Ι

6 Οι περιπτώσεις χρήσης συντάσσονται
… με 3 τρόπους (μορφές): Συνοπτική – μια παράγραφος Συνήθης – άτυπη μορφή μερικών παραγράφων (παράδειγμα «Διαχείριση επιστροφής»). Πλήρους ανάπτυξης πολύ αναλυτική και δομημένη. Ολα τα βήματα και οι παραλλαγές συντάσσονται με λεπτομέρεια. 09:26 Μηχανική Λογισμικού Ι

7 Περίπτωση χρήσης: Συνοπτική μορφή
Διεκπεραίωση Πώλησης: Ενας πελάτης φτάνει σε ένα ταμείο έχοντας κάποια προϊόντα που θέλει να αγοράσει. Ο ταμίας χρησιμοποιεί το σύστημα POS για την καταγραφή κάθε προϊόντος. Το σύστημα εμφανίζει τη συνολική χρέωση, καθώς και πληροφορίες για κάθε προϊόν. Ο ταμίας εισάγει τις απαραίτητες πληροφορίες για την πληρωμή, οι οποίες επαληθεύονται και καταγράφονται από το σύστημα. Το σύστημα ενημερώνει την Αποθήκη. Ο πελάτης παίρνει από το σύστημα μια απόδειξη και αποχωρεί με τα προϊόντα. 09:26 Μηχανική Λογισμικού Ι

8 ΠΧ Συνηθισμένης μορφής
09:26 Μηχανική Λογισμικού Ι

9 Περίπτωση Χρήσης ΠΧ01: Διεκπεραίωση Πώληση Σύντομη περιγραφή:
Περίπτωση Χρήσης ΠΧ01: Διεκπεραίωση Πώληση Σύντομη περιγραφή: Κύριος χρήστης: Ταμίας Εμπλεκόμενοι και Ενδιαφέροντα: Ταμίας: Θέλει ακριβή, γρήγορη εισαγωγή δεδομένων και καθόλου λάθη πληρωμών, αφού πιθανά ελλείμματα αφαιρούνται από το μισθό του. Πωλητής: Θέλει καθημερινή ενημέρωση της προμήθειάς του από τις πωλήσεις. Πελάτης: Θέλει αγορά και γρήγορη εξυπηρέτηση με τον ελάχιστο δυνατό κόπο. Θέλει απόδειξη αγοράς για το ενδεχόμενο επιστροφών. Εταιρία: Θέλει να καταγράφει με ακρίβεια τις συναλλαγές και να ικανοποιεί τις ανάγκες των πελατών. Θέλει κάποια ανοχή στα σφάλματα, ώστε οι πωλήσεις να μπορούν να καταγραφούν ακόμα και αν κάποια μηχανικά συστήματα (όπως για παράδειγμα το σύστημα επιβεβαίωσης των πιστωτικών καρτών) δεν είναι διαθέσιμα λόγω βλάβης. Θέλει αυτόματη και γρήγορη ενημέρωση των λογιστικών και των αποθεμάτων. 09:26 Μηχανική Λογισμικού Ι

10 Προϋποθέσεις: Ο ταμίας έχει αναγνωρισθεί και ταυτοποιηθεί.
Εφορία: Θέλει να εισπράττει φόρο για κάθε πώληση. Μπορεί να εμπλέκονται διαφορετικοί φορείς (εθνικοί, δημοτικοί, κλπ). Υπηρεσία Εξουσιοδότησης Πληρωμών: Θέλει να λαμβάνει ψηφιακές αιτήσεις για έγκριση πληρωμών, στη σωστή μορφή και με το σωστό πρωτόκολλο. Θέλει τον ακριβή υπολογισμό των πληρωμών του καταστήματος. Προϋποθέσεις: Ο ταμίας έχει αναγνωρισθεί και ταυτοποιηθεί. Εγγύηση Επιτυχίας: Η πώληση αποθηκεύεται. Ο φόρος υπολογίστηκε σωστά. Τα λογιστικά και τα αποθέματα ενημερώθηκαν. Οι προμήθειες καταγράφηκαν. Η απόδειξη εκτυπώθηκε. Οι εγκρίσεις πληρωμών καταγράφηκαν. 09:26 Μηχανική Λογισμικού Ι

11 Κύριο Σενάριο Επιτυχίας (ή Βασική Ροή):
Ο Πελάτης έρχεται σε ένα ταμείο POS για να αγοράσει προϊόντα ή/και υπηρεσίες. Ο Ταμίας ξεκινά μια νέα πώληση. Ο Ταμίας εισάγει τον κωδικό του προϊόντος. Το Σύστημα καταγράφει το προϊόν και παρουσιάζει την περιγραφή, την τιμή και το τρέχον σύνολο. Η τιμή υπολογίζεται σύμφωνα με συγκεκριμένους κανόνες τιμολόγησης. Ο ταμίας επαναλαμβάνει τα βήματα 3-4 μέχρι να δηλώσει την ολοκλήρωση της διαδικασίας. Το Σύστημα εμφανίζει το συνολικό κόστος, συμπεριλαμβανομένων και των φόρων. Ο Ταμίας ενημερώνει τον Πελάτη για το κόστος και ζητάει την πληρωμή. Ο Πελάτης πληρώνει και το Σύστημα διαχειρίζεται την πληρωμή. Το Σύστημα καταγράφει την ολοκληρωμένη πώληση και στέλνει πληροφορίες σχετικές με την πώληση και την πληρωμή στο εξωτερικό Λογιστικό σύστημα (για λογιστική επεξεργασία και υπολογισμό προμηθειών), καθώς και στο Αποθεματικό σύστημα (για την ενημέρωση των αποθεμάτων). Το Σύστημα εκδίδει απόδειξη. Ο Πελάτης αναχωρεί με την απόδειξη και τα προϊόντα. 09:26 Μηχανική Λογισμικού Ι

12 Επεκτάσεις (ή Εναλλακτικές Ροές):
*α. Σε οποιαδήποτε στιγμή, το Σύστημα αποτυγχάνει: Για να είναι δυνατή η ανάκαμψη και η διόρθωση των λογιστικών, πρέπει όλα τα σχετικά με μια συναλλαγή στοιχεία να μπορούν να ανακτηθούν, σε οποιοδήποτε βήμα του σεναρίου. Ο Ταμίας επανεκκινεί το Σύστημα, συνδέεται σε αυτό και ζητά την επαναφορά της προηγούμενης κατάστασης. Το Σύστημα ανακατασκευάζει την προηγούμενη κατάσταση. 2α. Το Σύστημα ανιχνεύει δυσλειτουργίες που εμποδίζουν την επαναφορά: Το Σύστημα εμφανίζει στον Ταμία ένα μήνυμα σφάλματος, καταγράφει το σφάλμα και εισέρχεται σε μια αρχική κατάσταση λειτουργίας. Ο Ταμίας ξεκινάει μια νέα πώληση. 3α. Εσφαλμένος κωδικός προϊόντος: Το Σύστημα εμφανίζει μήνυμα σφάλματος και απορρίπτει την εισαγωγή. 3β. Υπάρχουν πολλά ίδια προϊόντα ώστε δεν ενδείκνυται η καταγραφή καθενός ξεχωριστά: Ο Ταμίας έχει τη δυνατότητα να εισάγει τον κωδικό του προϊόντος και την ποσότητα. 09:26 Μηχανική Λογισμικού Ι

13 Το Σύστημα εμφανίζει την ενημερωμένη συνολική χρέωση.
3-6α. Ο Πελάτης αλλάζει γνώμη και ζητά από τον Ταμία να αφαιρέσει ένα προϊόν: Ο Ταμίας εισάγει τον κωδικό του προϊόντος και την αίτηση αφαίρεσής του. Το Σύστημα εμφανίζει την ενημερωμένη συνολική χρέωση. 3-6β. Ο Πελάτης λέει στον Ταμία να ακυρώσει την πώληση: Ο Ταμίας ακυρώνει την πώληση στο Σύστημα. 3-6γ. Ο Ταμίας αναβάλλει την πώληση: Το Σύστημα αποθηκεύει την πώληση ώστε να είναι δυνατή η μετέπειτα ανάκτησή της από οποιοδήποτε τερματικό POS 4α. Η τιμή που εμφάνισε το Σύστημα για ένα προϊόν δεν είναι η επιθυμητή (π.χ. ο Πελάτης παραπονέθηκε για κάτι και το προϊόν του δίνεται σε χαμηλότερη τιμή): Ο Ταμίας παρακάμπτει την τιμή του Συστήματος και εισάγει άλλη. Το Σύστημα εμφανίζει τη νέα τιμή. 5α. Το Σύστημα αποτυγχάνει να επικοινωνήσει με το εξωτερικό σύστημα υπολογισμού φόρου: Το σύστημα επανεκκινεί την σχετική υπηρεσία στον κόμβο POS και συνεχίζει. α. Το Σύστημα ανιχνεύει ότι η υπηρεσία δεν επανεκκινείται. Το Σύστημα εμφανίζει μήνυμα σφάλματος. Ο Ταμίας μπορεί είτε να υπολογίσει χειροκίνητα το φόρο, είτε να ακυρώσει την πώληση. 09:26 Μηχανική Λογισμικού Ι

14 Ο Ταμίας εισάγει την αίτηση για χρήση υπολοίπου.
5β. Ο Πελάτης λέει ότι δικαιούται έκπτωση: Ο Ταμίας εισάγει την αίτηση για έκπτωση. Ο Ταμίας εισάγει τον κωδικό του Πελάτη. Το Σύστημα εμφανίζει το μειωμένο συνολικό κόστος, βασιζόμενο σε συγκεκριμένους κανόνες έκπτωσης. 5γ. Ο Πελάτης λέει ότι έχει πιστωτικό υπόλοιπο στο λογαριασμό του και επιθυμεί να το χρησιμοποιήσει για την αγορά: Ο Ταμίας εισάγει την αίτηση για χρήση υπολοίπου. Το Σύστημα χρησιμοποιεί το υπόλοιπο για να καλύψει το κόστος της αγοράς και μειώνει το διαθέσιμο υπόλοιπο. 6α. Ο Πελάτης λέει ότι σκόπευε να χρησιμοποιήσει ρευστό αλλά δεν έχει αρκετό: 1α. Ο Πελάτης χρησιμοποιεί έναν εναλλακτικό τρόπο πληρωμής. 1β. Ο Πελάτης λέει στον Ταμία να ακυρώσει την πώληση. Ο Ταμίας ακυρώνει την πώληση στο Σύστημα. 7α. Πληρωμή με μετρητά: Ο Ταμίας εισάγει το χρηματικό ποσό που έδωσε ο Πελάτης. Το Σύστημα εμφανίζει τα ρέστα και ανοίγει το συρτάρι του ταμείου. Ο Ταμίας τοποθετεί τα χρήματα του Πελάτη και του επιστρέφει τα ρέστα. 09:26 Μηχανική Λογισμικού Ι

15 ΠΛΗΡΟΥΣ ΑΝΑΠΤΥΞΗΣ 09:26 Μηχανική Λογισμικού Ι

16 09:26 Μηχανική Λογισμικού Ι

17 09:26 Μηχανική Λογισμικού Ι

18 09:26 Μηχανική Λογισμικού Ι

19 09:26 Μηχανική Λογισμικού Ι

20 Η παραλλαγή των Δύο στηλών
Διαλογική παραλλαγή, δίνει έμφαση στο γεγονός ότι υπάρχει μια αλληλεπίδραση μεταξύ χρηστών και του συστήματος [R. Wirfs-Brock]. 09:26 Μηχανική Λογισμικού Ι

21 09:26 Μηχανική Λογισμικού Ι

22 Ορισμοί Χειριστής ή Χρήστης (Actor) Σενάριο (ή στιγμιότυπο μιας ΠΧ)
Κάτι που έχει συμπεριφορά άτομο, σύστημα Η/Υ, οργανισμός. Σενάριο (ή στιγμιότυπο μιας ΠΧ) Συγκεκριμένη ακολουθία από ενέργειες και αλληλεπιδράσεις μεταξύ χρήστη και συστήματος Περίπτωση Χρήσης συλλογή από σχετιζόμενα επιτυχή και ανεπιτυχή (εναλλακτικά) σενάρια τα οποία περιγράφουν τη χρήση ενός συστήματος από τους χρήστες για την προώθηση των στόχων τους. 09:26 Μηχανική Λογισμικού Ι

23 Το κύριο χαρακτηριστικό στην δημιουργία ΠΧ είναι η εστίαση στο ερώτημα:
«Πως μπορούμε χρησιμοποιώντας το σύστημα να προσδίδουμε προφανή αξία στον χρήστη ή να εκπληρώνονται οι στόχοι του;». 09:26 Μηχανική Λογισμικού Ι

24 Είναι κείμενα και όχι διαγράμματα
Οι ΠΧ στην ΕΔ κεντρικός μηχανισμός ανακάλυψης και ορισμού των λειτουργικών απαιτήσεων. υπόσχεση ή σύμβαση για το πως θα συμπεριφέρεται ένα σύστημα. Είναι κείμενα και όχι διαγράμματα η μοντελοποίησή τους συνιστά σύνταξη κειμένου. η UML ορίζει ένα ‘Διάγραμμα Περιπτώσεων Χρήσης’ για την απεικόνιση των τίτλων τους, των συσχετίσεών τους, και των χρηστών 09:26 Μηχανική Λογισμικού Ι

25 Τύποι και Φόρμες ΠΧ δεν περιγράφουν τις εσωτερικές λειτουργίες ενός συστήματος, τα μέρη του, ή τη σχεδίασή του, αλλά τις αρμοδιότητές του (ΑΣ τρόπος σκέψης). Τί θα πρέπει ένα σύστημα να κάνει (λειτουργικές απαιτήσεις) 09:26 Μηχανική Λογισμικού Ι

26 Επεξήγηση των τμημάτων της ΠΧ
Κύριος Χειριστής (Primary Actor) Ο κύριος συμμετέχων καλεί τις υπηρεσίες του συστήματος για την εκπλήρωση των στόχων του Εμπλεκόμενοι και Λίστα ενδιαφερόντων Η λίστα οριοθετεί τι θα πρέπει να κάνει το σύστημα «Το σύστημα συνάπτει ένα συμβόλαιο μεταξύ των εμπλεκομένων, με τις ΠΧ να αναφέρουν λεπτομερώς τα φέροντα συμπεριφορά μέρη του συμβολαίου... Η ΠΧ, ως το συμβόλαιο συμπεριφοράς, περικλείει μόνο εκείνες τις συμπεριφορές για την ικανοποίηση των ενδιαφερόντων των εμπλεκομένων» (Cockburn). 09:26 Μηχανική Λογισμικού Ι

27 Προϋποθέσεις (preconditions)
δηλώνει τι πρέπει οπωσδήποτε να ισχύει πριν την έναρξη του σεναρίου σε μια ΠΧ. Οι προϋποθέσεις δεν εξετάζονται σε μια ΠΧ, αλλά είναι καταστάσεις οι οποίες θεωρούνται δεδομένα αληθείς. Μετα-συνθήκες (postconditions) δηλώνουν τι θα ισχύει μετά την επιτυχή ολοκλήρωση μιας ΠΧ. Η εγγύηση θα πρέπει να ικανοποιεί τις ανάγκες όλων των εμπλεκομένων. 09:26 Μηχανική Λογισμικού Ι

28 Βασικό (επιτυχές) σενάριο (ή Βασική Ροή)
περιγράφει το τυπικό επιτυχημένο μονοπάτι (διαδικασία) που ικανοποιεί τα ενδιαφέροντα όλων των εμπλεκομένων. δεν περιλαμβάνει συνθήκες ή διακλαδώσεις, οι οποίες μετατίθενται στο ‘τμήμα των επεκτάσεων’ ή εναλλακτικών σεναρίων. καταγράφει 3 ειδών βήματα : 1. ενέργειες Χρηστών 2. επικύρωσης (συνήθως από το σύστημα) 3. κατάστασης αλλαγής από το σύστημα (καταγραφή, τροποποίηση) 09:26 Μηχανική Λογισμικού Ι

29 Εναλλακτικές ροές (ή σενάρια)
δείχνουν όλα τα άλλα σενάρια ή τις διακλαδώσεις, επιτυχή ή ανεπιτυχή Συντάσσονται με βάση το κύριο σενάριο. Μια Επέκταση έχει δύο μέρη: τη συνθήκη τον χειρισμό Στο τέλος κάθε επέκτασης ο έλεγχος ροής επιστρέφει στο βασικό σενάριο 09:26 Μηχανική Λογισμικού Ι

30 Εναλλακτικές ροές 09:26 Μηχανική Λογισμικού Ι

31 Ειδικές απαιτήσεις Πρόκειται για: Μη λειτουργικές απαιτήσεις,
χαρακτηριστικά ποιότητας, Περιορισμούς, που σχετίζονται ειδικά με την περίπτωση χρήσης 09:26 Μηχανική Λογισμικού Ι

32 Λίστα Παραλλαγών Τεχνολογιών και Δεδομένων
Τεχνικές παραλλαγές για το πως πρέπει να γίνει κάτι, αλλά όχι τι, σημαντικό να καταγράφονται στις ΠΧ. (Ο κανόνας συνιστά να αποφεύγονται οι πρώιμες σχεδιαστικές αποφάσεις) 09:26 Μηχανική Λογισμικού Ι

33 Στόχοι και Εκταση των περιπτώσεων χρήσης
Ερωτήσεις που πρέπει να απαντηθούν: Πως ανακαλύπτουμε τις περιπτώσεις χρήσης; Σε τι επίπεδο και έκταση θα πρέπει να εκφραστούν;; Κανόνας: Στοιχειώδης Επιχειρηματική Διεργασία (ΣΕΔ) Κατά την ανάλυση των απαιτήσεων μιας εφαρμογής λογισμικού, να επικεντρωνόμαστε σε περιπτώσεις χρήσης επιπέδου ΣΕΔ. 09:26 Μηχανική Λογισμικού Ι

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

35 Περιπτώσεις χρήσης και Στόχοι
η ΣΕΔ θα μπορούσε να ονομάζεται και ΠΧ επιπέδου Χρήστη – Στόχου. Αυτό οδηγεί στη συνιστώμενη διαδικασία: 1.  βρες τους στόχους του χρήστη 2.  όρισε για κάθε στόχο μια ΠΧ πχ. Στόχος: ολοκλήρωση ή επεξεργασία μιας πώλησης. Περίπτωση χρήσης: ‘Επεξεργασία πώλησης’ 09:26 Μηχανική Λογισμικού Ι

36 Στόχοι υπολειτουργιών και Περιπτώσεις χρήσης
Δεν συνιστά παράβαση του κανόνα ΣΕΔ να συντάσσουμε ΠΧ για στόχους υπολειτουργιών, αυξάνει όμως την πολυπλοκότητα σε ένα μοντέλο Σημαντική παρατήρηση: ο αριθμός και ο βαθμός λεπτομέρειας των ΠΧ επηρεάζει τον χρόνο και δυσκολεύει την κατανόηση, συντήρηση, και τη διαχείριση των απαιτήσεων. Να εκφραστεί μια υπολειτουργία ως ΠΧ, όταν η υπολειτουργία επαναλαμβάνεται αποτελεί μια προϋπόθεση πολλαπλών χρηστών στόχων επιπέδου περιπτώσεις χρήσης. 09:26 Μηχανική Λογισμικού Ι

37 Εύρεση Κύριων Χρηστών, Στόχων και ΠΧ
Η βασική διαδικασία είναι: 1. Οριοθέτηση του συστήματος (είναι εφαρμογή ενός ατόμου ή ενός ολόκληρου οργανισμού;) 2. Ταυτοποίηση των Κύριων χρηστών 3. Για κάθε χρήστη προσδιόρισε τους στόχους του, αρκεί να ικανοποιεί τον κανόνα ΣΕΔ 4. Ορισε ΠΧ που ικανοποιούν του στόχους χρηστών. 09:26 Μηχανική Λογισμικού Ι

38 Βήμα 1: Οριοθέτηση του συστήματος
Εάν δεν είναι ξεκάθαρο τι περιλαμβάνεται εντός των ορίων τότε, Να καθοριστεί του τι είναι εκτός εξωτερικοί Κύριοι Χειριστές και βοηθητικοί Χειριστές 09:26 Μηχανική Λογισμικού Ι

39 Βήμα 2 και 3: εύρεση Κύριων Χειριστών και Στόχων
Μερικές φορές οι στόχοι αποκαλύπτουν τους Κύριους Χειριστές ή αντίστροφα Κανόνας: «Εμφαση να δοθεί πρώτα στην εύρεση των Κύριων χρηστών, καθώς αυτό θα θέσει το πλαίσιο για περαιτέρω διερεύνηση» 09:26 Μηχανική Λογισμικού Ι

40 Ερωτήσεις για εύρεση μη εμφανών Κύριων Χειριστών και Στόχων:
Ποιος ξεκινά και σταματά το σύστημα; Ποιος είναι υπεύθυνος για το διαχείριση χρηστών και ασφάλειας; Υπάρχει κάποια διαδικασία επανεκκίνησης του συστήματος σε περίπτωση «κατάρευσης»; Πως γίνεται ο χειρισμός της αναβάθμισης του λογισμικού; Ποιος διαχειρίζεται το σύστημα; Ποιος αξιολογεί τις λειτουργίες ή την απόδοση του συστήματος; 09:26 Μηχανική Λογισμικού Ι

41 Κύριοι και Υποστηρικτικοί Χειριστές (Actors)
Οι Κύριοι Χειριστές επιδιώκουν να εκπληρώσουν στόχους τους χρησιμοποιώντας λειτουργίες του υπό σχεδίαση συστήματος οι υποστηρικτικοί Χειριστές, αντίθετα, διαθέτουν λειτουργίες (προς εξυπηρέτηση) 09:26 Μηχανική Λογισμικού Ι

42 Κατάλογος Κύριων Χρηστών - Στόχων
Οι Κύριοι Χρήστες και οι στόχοι τους να καταγράφονται σε έναν κατάλογο ο οποίος περιλαμβάνεται στο ‘τμήμα Οράματος’ (Vision sections) της ΕΔ (σχήμα) 09:26 Μηχανική Λογισμικού Ι

43 09:26 Μηχανική Λογισμικού Ι

44 Βήμα 4: Ορισμός ΠΧ Γενικά, Μια εξαίρεση στον κανόνα
όριζε μια ΠΧ επιπέδου ΣΕΔ για κάθε στόχο χρήστη. Ονόμαζε την ΠΧ με παρόμοιο όνομα με το στόχο χρήστη. Πχ. Στόχος: επεξεργασία πώλησης. Περίπτωση χρήσης: επεξεργασία πώλησης. Μια εξαίρεση στον κανόνα η ομαδοποίηση των CRUD (create, retrieve, update, delete) στόχων σε μια CRUD περίπτωση χρήσης. τα ονόματα των περιπτώσεων χρήσης να αρχίζουν με κεφαλαίο γράμμα 09:26 Μηχανική Λογισμικού Ι

45 Συγγραφή περιπτώσεων χρήσης σε UI-free τρόπο
Ουσιαστικός τρόπος συγγραφής Κανόνας: «κράτησε απ’ έξω τη διεπαφή χρήστη». Αποφεύγοντας τις λεπτομέρειες των διεπαφών η επικέντρωση γίνεται στον πραγματικό σκοπό του χρήστη. Σε ένα ουσιαστικό τρόπο συγγραφής η ιστορία εκφράζεται στο επίπεδο των στόχων των χρηστών και των αρμοδιοτήτων του συστήματος παρά σε συγκεκριμένες ενέργειες. Οι Στόχοι παραμένουν ελεύθεροι από λεπτομέρειες μηχανισμών και τεχνολογίας, και ειδικά αυτών που σχετίζονται με τις διεπαφές χρηστών. 09:26 Μηχανική Λογισμικού Ι

46 Χρήστες (Actors) είναι: οτιδήποτε με συμπεριφορά,
συμπεριλαμβανομένου του συστήματος υπό ανάπτυξη όταν καλεί λειτουργίες από άλλα συστήματα. δεν είναι μόνο ρόλοι που παίζονται από ανθρώπους, αλλά από οργανισμούς, λογισμικό και μηχανές. 09:26 Μηχανική Λογισμικού Ι

47 3 ειδών εξωτ. Χρηστών σε σχέση με το ΣυΑ:
Κύριοι έχουν στόχους χρήστη οι οποίοι ικανοποιούνται με λειτουργίες του ΣυΑ (πχ. Ταμείας). Γιατί να ταυτοποιηθεί; για να βρεθούν στόχοι χρηστών οι οποίοι οδηγούν τις περιπτώσεις χρήσης Υποστηρικτικοί παρέχουν μια λειτουργία στο ΣυΑ (αυτόμ. πληρωμή) Γιατί να ταυτοποιηθεί; για να καθοριστούν οι εξωτερικές διεπιφάνειες χρήστη και τα πρωτόκολλα Εξωτερικοί έχουν ενδιαφέρον στη συμπεριφορά της ΠΧ. (πχ. κρατικός εφοριακός) 09:26 Μηχανική Λογισμικού Ι

48 Διαγράμματα περιπτώσεων χρήσης
Η UML διαθέτει σημειογραφία των ονομάτων των περιπτώσεων χρήσης των συμμετεχόντων, των συσχετίσεών τους (εικ. 6.2). λειτουργεί σαν ένα εργαλείο επικοινωνίας το οποίο συνοψίζει τη συμπεριφορά ενός συστήματος και των συμμετεχόντων του. 09:26 Μηχανική Λογισμικού Ι

49 09:26 Μηχανική Λογισμικού Ι

50 Το κουτί του Χειριστή με το σύμβολο «actor» ονομάζεται UML στερεότυπο.
Τα διαγράμματα περιπτώσεων χρήσης και οι συσχετίσεις τους θεωρούνται δευτερεύοντα. Οι περιπτώσεις χρήσης είναι πρώτιστα τεκμηρίωση κειμένου, το οποίο σημαίνει συγγραφή κειμένου. Πρόταση: Σχεδίασε ένα απλό διάγραμμα ΠΧ σε συνεργασία με μια λίστα Χειριστών-Στόχων. Το κουτί του Χειριστή με το σύμβολο «actor» ονομάζεται UML στερεότυπο. 09:26 Μηχανική Λογισμικού Ι

51 09:26 Μηχανική Λογισμικού Ι

52 Οι ΠΧ στην ΕΔ ζωτικής και κεντρικής σημασίας,
Ενθαρρύνουν την καθοδηγούμενη από περιπτώσεις χρήσης ανάπτυξη. Αυτό σημαίνει ότι: Οι απαιτήσεις καταγράφονται κυρίως σε ΠΧ. Οι ΠΧ είναι σημαντικό μέρος της επαναληπτικής σχεδίασης, και κύριο στοιχείο για εκτίμηση Η πραγματοποίηση των ΠΧ οδηγεί τη σχεδίαση. Οι ΠΧ επηρεάζουν την οργάνωση των εγχειριδίων χρηστών 09:26 Μηχανική Λογισμικού Ι

53 Η ΕΔ διακρίνει τις περιπτώσεις χρήσης από τις επιχειρηματικές.
Οι ΠΧ δημιουργούνται στην γνωστική περιοχή των Απαιτήσεων, και είναι μέρος του Μοντέλου Περιπτώσεων χρήσης. Οι Επιχειρηματικές Περιπτώσεις χρήσης δημιουργούνται στο γνωστικό πεδίο του Επιχειρηματικού Μοντέλου. Περιγράφουν μια ακολουθία ενεργειών στο σύνολο της επιχείρησης για την εκπλήρωση ενός στόχου του Χειριστή στην επιχείρηση (πχ. «Σέρβηρε ένα γεύμα» σε ένα εστιατόριο) 09:26 Μηχανική Λογισμικού Ι

54 Οι ΠΧ και ο καθορισμός των Απαιτήσεων στη διάρκεια των Επαναλήψεων
πίνακας δείγμα της ΕΔ στρατηγικής για το πως αναπτύσσονται οι απαιτήσεις. κατασκευή του πυρήνα του συστήματος μόνο όταν περίπου 10% των απαιτήσεων έχουν συγγραφεί λεπτομερώς. (προηγ.) κύρια διαφορά με την διεργασία «καταρράκτη». 09:26 Μηχανική Λογισμικού Ι

55 09:26 Μηχανική Λογισμικού Ι

56 09:26 Μηχανική Λογισμικού Ι

57 Οι ΠΧ στη Σύλληψη Το πρώτο μέρος της ημέρας
ταυτοποίηση των στόχων και των εμπλεκομένων, και τι είναι εντός και εκτός του έργου. Συντάσσεται ένας πίνακας συμμετέχοντα-χρήστη περιπτώσεων χρήσης. Αρχίζει διάγραμμα συνάφειας περιπτώσεων χρήσης. σχηματίζει μια εικόνα υψηλού επιπέδου της λειτουργικότητας του συστήματος. απόφαση αν το έργο αξίζει ουσιαστικής διερεύνησης (ανήκει στην φάση επεξεργασίας). 09:26 Μηχανική Λογισμικού Ι

58 Οι ΠΧ στην Επεξεργασία Είναι η φάση των πολλαπλών διαχρονικά επαναλήψεων (πχ. 4 επαναλήψεις), όπου αυξημένου κινδύνου, υψηλής αξίας, ή αρχιτεκτονικά σημαντικά μέρη ενός συστήματος, κατασκευάζονται αυξητικά, και η πλειονότητα των απαιτήσεων ταυτοποιείται και διασαφηνίζονται. 09:26 Μηχανική Λογισμικού Ι

59 ΤΑΥΤΟΠΟΙΗΣΗ ΑΛΛΩΝ ΑΠΑΙΤΗΣΕΩΝ

60 Συμπληρωματικές Προδιαγραφές
Οι Περιπτώσεις χρήσης δεν αρκούν για να περιγράψουμε πλήρως ένα σύστημα. Χρειάζεται να συμπληρωθούν με τα ακόλουθα: Συμπληρωματικές Προδιαγραφές Θα πρέπει να καθοριστούν και άλλες απαιτήσεις, όπως Τεκμηρίωση, Πακετοποίηση, Υποστηρικτηκότητα κατοχύρωση των δικαιωμάτων, ποιοτικά χαρακτηριστικά, κά. Λεξιλόγιο περιλαμβάνει όρους και ορισμούς και μπορεί να παίξει το ρόλο του λεξικού δεδομένων. Όραμα (Vision) Εξυπηρετεί την επικοινωνία των κεντρικών ιδεών σχετικά με προτάσεις για το προτεινόμενο έργο: ποια είναι τα προβλήματα, ποιοι οι συμμετέχοντες, τι χρειάζονται, και ποια η προτεινόμενη λύση.

61 Ορισμός της RUP ορίζει για το όραμα:
«Το Οραμα ορίζει την οπτική των συμμετεχόντων για το υπό ανάπτυξη έργο, προσδιορισμένο με όρους τις κύριες ανάγκες και τα χαρακτηριστικά των συμμετεχόντων. Περιλαμβάνει ένα περίγραμμα από τον πυρήνα των οραματιζόμενων απαιτήσεων, διασφαλίζωντας έτσι το βασικό συμφωνητικό για πιο λεπτομερείς τεχνικές απαιτήσεις» Παράδειγμα: Το σύστημα ‘ΠΥΘΙΑ’

62 ΟΡΑΜΑ: σύνταξη προβλήματος
Το πρόβλημα ... ... Επηρεάζει Οι συνέπειες του οποίου είναι Μια επιτυχημένη λύση θα ήταν

63 Συμπληρωματικές Προδιαγραφές για το παράδειγμα NextGen POS (μοντέλο FURPS)
Λειτουργικότητα (Functionality) (αφορά πολλές ΠΧ) Logging and Error Handling (καταγραφή λαθών) Ενσωμάτωση επιχειρησιακών κανόνων (Pluggable Business Rules) Ασφάλεια Ευχρηστία (Usability) Ανθρώπινοι παράγοντες Αναγνώσιμο κείμενο από απόσταση 1 μέτρου Αποφυγή πολύχρωμων διεπαφών-χρήστη Αξιοπιστία (Reliability) Επαναφορά από απρόσμενες καταστάσεις Τοπική υποστήριξη σε περίπτωση διακοπής επικοινωνίας με εξωτερικά συστήματα

64 Απόδοση (Performance) Υποστηριξιμότητα (Supportability)
Εστίαση σε σημεία που μπορούν να προκαλέσουν «συμφόρηση» επικοινωνίας Υποστηριξιμότητα (Supportability) Προσαρμοστικότητα Ειδικοί πελάτες (Pluggable Business Rules) Configurability Διαφορετικές δικτυακές απαιτήσεις (network configurations)

65 Επιχειρησιακοί Κανόνες Πεδίου προβλήματος <<βλ. πίνακα>>
Περιορισμοί Υλοποίησης (πχ. Java) Αγορασμένες μονάδες λογισμικού (υπολ. Φόρου) Ελεύθερες μονάδες λογισμικού Ανοικτού Κώδικα Διεπαφές χρήστη Αξιοσημείωτες διασυνδέσεις υλικού Οθόνη επαφής, σαρωτής γραμμωτού κώδικα, αναγν. καρτών, κλπ Διεπαφές λογισμικού Για εξωτερικά συνεργαζόμενα συστήματα (Λογιστήριο, Αποθήκη) Επιχειρησιακοί Κανόνες Πεδίου προβλήματος <<βλ. πίνακα>> Νομικά ζητήματα Άδεια χρήσης Ανοικτού κώδικα Φορολογικοί νόμοι Πληροφορίες στο Πεδίο προβλήματος ενδιαφέροντος Τιμολόγηση (original price, perm. markdown) Χειρισμός Χρεωστικής και Πιστωτικής συναλλαγής (εισπράττει ο πωλητής) Φόροι πωλήσεων

66

67 Ποιοτικά χαρακτηριστικά
Μερικές απαιτήσεις ονομάζονται ποιοτικά χαρακτηριστικά. Είναι δε, δύο ειδών: Παρατηρούμενες κατά την εκτέλεση, όπως: λειτουργικότητα, ευχρηστία, αξιοπιστία, απόδοση, ... 2. Μη παρατηρούμενες κατά την εκτέλεση υποστηρικτικότητα, ελεγξιμότητα, ...) Τα χαρακτηριστικά ποιότητας έχουν αλληλεξαρτήσεις και είναι αντικείμενο βέλτιστων επιλογών (trade-offs).

68 Επιχειρησιακοί Κανόνες Περιοχής προβλήματος
υπαγορεύουν πως πρέπει να λειτουργεί μια περιοχή προβλήματος. Δεν πρόκειται για απαιτήσεις κάποιας εφαρμογής Η πολιτική της επιχείρησης, φυσικοί νόμοι, και κυβερνητικοί νόμοι βοηθούν στην αποσαφήνιση ανεπαρκών και ασαφών περιπτώσεων χρήσης. πχ. είναι επιτρεπτή η πληρωμή με πίστωση δίχως υπογραφή;

69 Χαρακτηριστικά του συστήματος – Λειτουργικές απαιτήσεις
Οι περιπτώσεις χρήσης δεν είναι ο μοναδικός τρόπος για να εκφραστούν οι λειτουργικές απαιτήσεις. Ένας εναλλακτικός αλλά και συμπληρωματικός τρόπος είναι τα χαρακτηριστικά του συστήματος: (πχ. Λογισμικό ΑΤΕΙΘ) υψηλού επιπέδου, λακωνικές προτάσεις που συνοψίζουν τις λειτουργίες του συστήματος. Στην RUP ένα χαρακτηριστικό του συστήματος είναι «μια εξωτερικά παρατηρούμενη λειτουργία, η οποία παρέχεται από το σύστημα και ικανοποιεί άμεσα τις ανάγκες ενός χρήστη».

70 Κανόνας: Τα χαρακτηριστικά είναι πράγματα που ένα σύστημα μπορεί να κάνει. Αυτά θα πρέπει να περνούν τον ακόλουθο γλωσσολογικό έλεγχο: Το σύστημα θα κάνει το <χαρακτηριστικό Χ> Πχ. το σύστημα θα εγκρίνει την πληρωμή. Τα χαρακτηριστικά είναι ένας μηχανισμός για να συνοψίσουμε τι θα πρέπει να κάνει το σύστημα. Αυτά είναι συμπληρωματικά στις ΠΧ, καθώς δηλώνονται επιγραμματικά.

71 Όραμα, Χαρακτηριστικά, ή Περιπτώσεις χρήσης – Προτεραιότητα;
Δεν συνιστάται κάποια αυστηρή προτεραιότητα η συνεργασία μεταξύ τους βοηθά στην αποσαφήνιση Μια προτεινόμενη σειρά είναι: Ένα σύντομο προσχέδιο Οράματος Ταυτοποίηση στόχων και υποστήριξη ΠΧ Συγγραφή μερικών ΠΧ και αρχή Συμπλ. προδιαγραφών Ανάλυση της Οράματος και συνόψιση πληροφοριών

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