Η παρουσίαση φορτώνεται. Παρακαλείστε να περιμένετε

Η παρουσίαση φορτώνεται. Παρακαλείστε να περιμένετε

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

Παρόμοιες παρουσιάσεις


Παρουσίαση με θέμα: "09:47Μηχανική Λογισμικού Ι1. ΜΟΝΤΕΛΟ ΠΕΡΙΠΤΩΣΕΩΝ ΧΡΗΣΗΣ 09:47Μηχανική Λογισμικού Ι2."— Μεταγράφημα παρουσίασης:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

59

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

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

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

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

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

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

66

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

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

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

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

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

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


Κατέβασμα ppt "09:47Μηχανική Λογισμικού Ι1. ΜΟΝΤΕΛΟ ΠΕΡΙΠΤΩΣΕΩΝ ΧΡΗΣΗΣ 09:47Μηχανική Λογισμικού Ι2."

Παρόμοιες παρουσιάσεις


Διαφημίσεις Google