Περιεχόμενο του μαθήματος

ΠΛΗΡΟΦΟΡΙΑΚΑ ΣΥΣΤΗΜΑΤΑ ΜΟΥΣΕΙΩΝ Ανάλυση Απαιτήσεων Μοντέλο περιπτώσεων χρήσης Δρ Βαγγελιώ Καβακλή Τμήμα Πολιτισμικής Τεχνολογίας και Επικοινωνίας Πανεπιστήμιο Αιγαίου Χειμερινό Εξάμηνο 2010-2011 1 Περιεχόμενο του μαθήματος Η έννοια της απαίτησης από το ΠΣΜ Ορισμός, σπουδαιότητα, προσδιορισμός Περιπτώσεις Χρήσης (Use Cases) Ορισμός, πλεονεκτήματα Δομικά στοιχεία των διαγραμμάτων use case Actors (πράκτορες) Use Cases (περιπτώσεις χρήσης) Συσχετίσεις Δημιουργία use case διαγραμμάτων Αναγνώριση πρακτόρων και περιπτώσεων χρήσης Τεκμηρίωση των περιπτώσεων χρήσης Ανάλυση περιπτώσεων χρήσης Κλάσεις Πακέτα 2 1

Απαιτήσεις από το ΠΣΜ Ορισμός: Μια λειτουργία που θα πρέπει το ΠΣΜ να επιτελεί ή μια συνθήκη που θα πρέπει να ικανοποιεί όταν θα έχει ολοκληρωθεί η κατασκευή του αφορούν τη συμπεριφορά του ΠΣ προς το εξωτερικό του περιβάλλον (χρήστης, άλλες εφαρμογές, λογισμικού) και όχι εσωτερικά του στοιχεία Λειτουργικές απαιτήσεις: περιγράφουν τις εργασίες (λειτουργίες) πουθαπρέπειναεκτελείτοπσ καθορίζουν τη συμπεριφορά του συστήματος, δηλ. την απόκριση που πρέπει να εμφανίζει στο περιβάλλον του όταν ισχύουν συγκεκριμένες συνθήκες Μη λειτουργικές απαιτήσεις: περιγράφουν χαρακτηριστικά που πρέπει να έχει το ΠΣ τα οποία δεν αφορούν την εκτέλεση κάποιας λειτουργίας από αυτό καθορίζουν ιδιώματα εμφάνισης (αισθητική, επικοινωνία με το χρήστη), επιδόσεων (αξιοπιστία, χρόνος εκτέλεσης, 3 χρήση πόρων), υλοποίησης, κ.τ.λ. Ταξινόμηση απαιτήσεων Απαιτήσεις από το λογισμικό Λειτουργικές Μη Λειτουργικές Χρήσης Αξιοπιστίας Επιδόσεων Υποστήριξης Επικοινωνίας Υλοποίησης Φυσικές Βάσεων Δεδομένων Σχεδίασης 4 2

Παράδειγμα: ΠΣ Τεκμηρίωσης Αντικειμένων ΚΑΡΤΕΛΑ ΑΝΤΙΚΕΙΜΕΝΟΥ ΚΑΡΤΕΛΑ ΑΝΤΙΚΕΙΜΕΝΟΥ ΚΑΡΤΕΛΑ ΑΝΤΙΚΕΙΜΕΝΟΥ Να ορίσετε τις λειτουργικές και μη λειτουργικές απαιτήσεις ενός πληροφοριακού συστήματος που θα διευκολύνει την τεκμηρίωση των αντικειμένων της συλλογής ενός μουσείου 5 Στατιστικά επιτυχίας έργων ανάπτυξης ΠΣ ακύρωση πριν την ολοκλήρωση Εκτός προϋπολογισμού, καθυστερημένο, χωρίς τα απαιτούμενα χαρακτηριστικά Πηγή: The Standish Group International, Inc., Chaos: A Recipe for Success 6 3

Γιατί είναι σημαντικές οι απαιτήσεις; Παράγοντες αποτυχίας έργων λογισμικού Άλλοι παράγοντες 20% Το σύστημα δεν χρειαζόταν πλέον πουθενά 8% Μη πλήρεις απαιτήσεις 13% Έλλειψη ενασχόλησης των χρηστών 12% Έλλειψη πόρων 11% Έλλειψη σχεδιασμού 8% Αλλαγή απαιτήσεων και προδιαγραφών 9% Έλλειψη διευθυντικής υποστήριξης 9% Μη ρεαλιστικές προσδοκίες 10% Έρευνα της Standish Group σε 350 εταιρίες και 8000 έργα (1995) 7 Γιατί είναι σημαντικές οι απαιτήσεις; Κόστος διόρθωσης λαθών απαιτήσεων Διαδικασία εξέλιξης (μετά την παράδοση) Διαδικασία επ αλήθευσης Διαδικασία ανάπ τυξης (συγγραφή κώδικα) Διαδικασία ανάπ τυξης (σχεδίαση) Διαδικασία π ροδιαγραφής απ αιτήσεων 20 500 10 5 1 0 100 200 300 400 500 Ευρώ Boehm and Papaccio (1998) 8 4

Πηγές για τις πιθανές απαιτήσεις Επιθυμίες και ανάγκες των εμπλεκομένων Μοντέλα πεδίων Τρέχουσα οργάνωση και συστήματα Ήδη υπάρχοντα έγγραφα Εξαγωγή απαιτήσεων Τρέχον μοντέλο κατάστασης Προτεινόμενος τύπος απαιτήσεων Επαναχρησιμοποιήσιμες απαιτήσεις Πίνακας-πρότυπο απαιτήσεων Βιβλιοθήκη επαναχρησιμοποίησης 9 Προσδιορισμός των απαιτήσεων από το ΠΣ Από τις μεγαλύτερες προκλήσεις της ανάπτυξης ΠΣ είναι: η ανακάλυψη των σωστών και απαραίτητων προδιαγραφών του συστήματος όπως αυτές εκφράζονται μέσω των απαιτήσεων των ενδιαφερόμενων μερών ο προσδιορισμός τους έτσι ώστε να είναι κατανοητές και να μπορούν να επαληθευτούν και επικυρωθούν από τους χρήστες. Τα διάφορα μοντέλα (δεδομένων, διεργασιών) είναι κατανοητά από τους σχεδιαστές όχι απαραίτητα από τους χρήστες. Αυτό οδηγεί σε αποκλίσεις / λάθη στην οριοθέτηση, προγραμματισμός και κοστολόγηση του συστήματος. The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is a difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. No other work so cripples the resulting system if done wrong. No other part is more difficult to rectify later. [Fred Brooks, 1987] 10 5

Mοντελοποίηση περιπτώσεων χρήσης Μοντελοποίηση περιπτώσεων χρήσης (Use-case modeling) η μοντελοποίηση της λειτουργίας του συστήματος σε σχέση με τα επιχειρησιακά γεγονότα, αυτών που τα προκαλούν και πως το σύστημα ανταποκρίνεται σε αυτά αρχικά αποτέλεσε μέρος αντικειμενοστρεφών προσεγγίσεων (Jacobson, 1992) υιοθετήθηκαν από άλλες προσεγγίσεις λόγω της εύκολης επικοινωνίας των διαγραμμάτωνuse case στους χρήστες συμπληρώνει παραδοσιακά εργαλεία μοντελοποίησης 11 Χρήση - Πλεονεκτήματα Χρησιμοποιούνται σε όλη τη διάρκεια της διαδικασίας ανάπτυξης του συστήματος. Κατά την ανάλυση, μοντελοποιούν την λειτουργία του προτεινόμενου συστήματος και ξεκινούν την αναγνώριση των δομικών στοιχείων του συστήματος. Κατά την υπόλοιπη διάρκεια της ανάπτυξης συνεχώς βελτιώνονται παράλληλα µε την διαδικασία σχεδιασμού αντικειμένων. Καθώς περιγράφουν με λεπτομέρεια τη λειτουργικότητα του συστήματος, αποτελούν συνεχή πηγή για τον έλεγχο και επικύρωση του συστήματος. Πλεονεκτήματα Βοηθούν στην ανάλυση / αποσύνθεση του συστήματος σε μικρότερα διαχειρίσιμα μέρη. Παρέχουν στους αναλυτές μια κατανοητή γλώσσα επικοινωνίας με τους χρήστες και τα λοιπά ενδιαφερόμενα μέρη του συστήματος. Βοηθούν στην εκτίμηση του εύρους και στον προγραμματισμό του έργου ανάπτυξης ΠΣ. Διευκολύνουν την τεκμηρίωση του συστήματος και τη δημιουργία εγχειριδίων χρήσης. Αποτελούν εργαλείο ανίχνευσης των απαιτήσεων. Αποτελούν αρχικό σημείο για την αναγνώριση αντικειμένων / οντοτήτων. Αποτελούν τηβάσηγιατονσχεδιασμότωνδιασυνδέσεων(interface) ανάμεσα στο σύστημα στους χρήστες και σε άλλα συστήματα. Βοηθούν στον ορισμό των απαιτήσεων πρόσβασης στις βάσεις δεδομένων του συστήματος. 12 6

Ορισμοί Διάγραμμα περίπτωσης χρήσης (use case diagram) απεικονίζει την αλληλεπίδραση του συστήματος με τους χρήστες του ή και με άλλα συστήματα περιγράφει με σχηματικό τρόπο τους χρήστες του συστήματος και τον τρόπο με τον οποίο αναμένουν να αλληλεπιδρούν με αυτό Περιγραφή περίπτωσης χρήσης (use-case narrative) αφηγηματική περιγραφή των δραστηριοτήτων της επιχείρησης και του πως ο χρήστης (θα) αλληλεπιδρά με το σύστημα για να εκτελέσει κάποια εργασία Περίπτωση χρήσης (Use case) μια σειρά σχετιζόμενων βημάτων (σενάριο), αυτοματοποιημένων και µη, µε απώτερο σκοπό την ολοκλήρωση μιας επιχειρησιακής δραστηριότητας. περιγραφή της λειτουργίας του συστήματος από την σκοπιά του χρήστη με ορολογία που εκείνος κατανοεί 13 Παράδειγμα διαγράμματος περίπτωσης χρήσης 14 7

Βασικά στοιχεία Περίπτωση χρήσης (Use case) υποσύνολο της συνολικής λειτουργίας του συστήματος Παριστάνεται από μια οριζόντια έλλειψη με το όνομα της περίπτωσης πάνω, κάτω ή μέσα στην έλλειψη. Πράκτορας (Actor) οτιδήποτε επικοινωνεί µε το σύστημα για να ανταλλάξει πληροφορίες. µπορεί να είναι χρήστης ή ρόλος που µπορεί να είναι εξωτερικό σύστηµα ήπρόσωπο. Χρονικό συμβάν (Temporal event) λειτουργίες που ενεργοποιούνται σε συγκεκριμένες χρονικές στιγμές. Ο πράκτορας είναι ο χρόνος. 15 Είδη πρακτόρων Πρωτεύων επιχείρησης (Primary business actor) Ο άμεσα ωφελούμενος από την εκτέλεση μιας δραστηριότητας. π.χ. ο εργαζόμενος που λαμβάνει την πληρωμή Πρωτεύων συστήματος (Primary system actor) Ο χρήστης που επιδρά άμεσα με το σύστημα και ενεργοποιεί ή προκαλεί την εκκίνηση μιας δραστηριότητας. π.χ. ο υπάλληλος της τράπεζας που εισάγει τα στοιχεία της κατάθεσης Εξωτερικός εξυπηρετητής (External server actor) Αυτός ο οποίος εξυπηρετεί κάποιο αίτημα που τίθεται από την περίπτωση χρήσης. π.χ. το γραφείο / υπάλληλος που εγκρίνει την αίτηση αλλαγής πιστωτικού ορίου της πιστωτικής κάρτας ενός πελάτη Εξωτερικός αποδέκτης (External receiver actor) Αυτός ο οποίος επηρεάζεται έμμεσα από την εκτέλεση της περίπτωσης χρήσης. π.χ. ο υπάλληλος της αποθήκης ο οποίος παίρνει εντολή να συσκευάσει κάποια προϊόντα αφού δοθεί μια παραγγελία από τον πελάτη 16 8

Αλληλεξαρτήσεις μεταξύ χειριστών και περιπτώσεων χρήσης Συσχέτιση (Association) σχέση ανάμεσα σε ένα χειριστή και στην περίπτωση χρήσης η οποία δηλώνει αλληλεπίδραση μεταξύ τους. Το βέλος που αγγίζει την έλλειψη δηλώνει ότι ο χειριστής ενεργοποιεί τη συγκεκριμένη περίπτωση χρήσης. Συσχέτιση χωρίς βέλος δηλώνει την ύπαρξη εξωτερικού αποδέκτη / εξυπηρετητή. Ανάληψη Μετρητών Πελάτης Σύστημα εξαγωγής χρημάτων 17 Χρησιμοποιεί (uses) Απομόνωση των κοινών βημάτων δύο ή περισσοτέρων περιπτώσεων χρήσης σε μια νέα αφηρημένη περίπτωση χρήσης (abstract use case) με στόχο την αποφυγή πλεονασμών κατά την περιγραφή των επιμέρους περιπτώσεων. Η αφηρημένη περίπτωση μπορεί να χρησιμοποιηθεί από άλλες περιπτώσεις οι οποίες απαιτούν τη συγκεκριμένη λειτουργικότητα. Ανάληψη Χρημάτων Μεταφορά Χρημάτων «uses» «uses» Ταυτοποίηση Πελάτη αφηρημένη use case Αναφέρεται και ως «includes» 18 9

Γενίκευση Υποδηλώνει πως μια περίπτωση χρήσης κληρονομεί τη συμπεριφορά μιας γενικής περίπτωσης χρήσης την οποία και εξειδικεύει. γενική use case Χρησιμοποιείται για να περιγράψουμε παραλλαγή μιας συμπεριφοράς με κομψό τρόπο. Τραπεζική Συναλλαγή Ανάληψη Χρημάτων Κατάθεση Χρημάτων ειδικές use case 19 Εξάρτηση (depends on) Εξαρτάται από (depends on) ορίζει ότι κάποια άλλη περίπτωση χρήσης πρέπει να εκτελεστεί προηγουμένως Ορίζει τη σειρά με την οποία πρέπει να υλοποιηθούν οι περιπτώσεις χρήσης. Δημιουργία Λογαριασμού «depends on» Κατάθεση Χρημάτων Περιγράφεται με ένα βέλος από την περίπτωση χρήσης προς την περίπτωση από την οποία εξαρτάται. Ανάληψη Χρημάτων «depends on» 20 10

Μοντελοποίηση περιπτώσεων χρήσης Στόχος μας είναι η εξαγωγή και ανάλυση πληροφοριών και η δημιουργία ενός μοντέλου το οποίο: Περιγράφει τι απαιτείται από τη σκοπιά του χρήστη Δεν περιγράφει τον τρόπο υλοποίησης του συστήματος. Βήματα 1. Προσδιορισμός πρακτόρων. 2. Προσδιορισμός περιπτώσεων χρήσης. 3. Κατασκευή μοντέλου περιπτώσεων χρήσης. 4. Τεκμηρίωση των περιπτώσεων χρήσης. 21 1: Προσδιορισμός πρακτόρων Σχετικές ερωτήσεις Ποιος ή τι εισάγει στοιχεία στο σύστημα; Ποιος ή τι λαμβάνει κάποιο αποτέλεσμα από το σύστημα; Απαιτείται συνεργασία με κάποιο άλλο σύστημα; Υπάρχουν δραστηριότητες που ξεκινούν αυτόματα σε συγκεκριμένο χρόνο; Ποιος θα συντηρήσει την πληροφορία στο σύστημα; 22 11

2: Προσδιορισμός περιπτώσεων χρήσης Σχετικές ερωτήσεις: Ποια είναι τα κύρια καθήκοντα των πρακτόρων; Τι πληροφορία χρειάζονται οι πράκτορες από το σύστημα; Τι πληροφορίες παρέχουν οι πράκτορες στο σύστημα; Απαιτείται κάποια ενημέρωση των πρακτόρων από το σύστημα σχετικά με την έκβαση κάποιων δραστηριοτήτων; Θα πρέπει οι πράκτορες να ενημερώσουν το σύστημα σχετικά με την έκβαση κάποιων δραστηριοτήτων; Στόχος είναι η αναγνώριση και τεκμηρίωση των σημαντικότερων, ουσιαστικών και απαραίτητων περιπτώσεων. 23 3: Κατασκευή Μοντέλου Υποσύστημα Διαχειριστή Τροποποίηση Λογαριασμού Διαχειριστής Συστήματος Πελάτης Υποσύστημα Πελάτη Τραπεζική Συναλλαγή «uses» Δημιουργία Λογαριασμού «depends on» Ανάληψη Χρημάτων Μεταφορά Χρημάτων Σύστημα εξαγωγής χρημάτων Ταυτοποίηση Πελάτη Κατάθεση Χρημάτων 24 12

Πακέτα (packages) Τα πακέτα αποτελούν γενικό μηχανισμό ομαδοποίησης περιπτώσεων χρήσης Κριτήρια καθορισμού πακέτων: Ένα πακέτο αντιστοιχεί σε περιπτώσεις χρήσης που είναι σημασιολογικά συναφείς στο πεδίο του προβλήματος Ένα πακέτο αντιστοιχεί σε περιπτώσεις χρήσης που σχετίζονται με ένα Χειριστή Ένα πακέτο είναι όσο το δυνατόν περισσότερο ανεξάρτητο από τα υπόλοιπα Ένα πακέτο περιγράφει μια όψη του συστήματος Ο διαχωρισμός μπορεί να γίνει και ανά ομάδα εργασίας, λαμβάνοντας υπόψη την τεχνογνωσία κάθε ομάδας 25 Άσκηση: Η περίπτωση του μουσείου τέχνης Με βάση την παρακάτω περιγραφή να φτιάξετε το μοντέλο περιπτώσεων χρήσης ενός αυτοματοποιημένου collection management συστήματος του μουσείου Α - Τεκμηρίωση αντικειμένων: 1. Ένα αντικείμενο φτάνει στο μουσείο (δωρεά, αγορά, δανεισμός, αρχαιολογική ανασκαφή) για αναγνώριση 2. Ο υπεύθυνος τήρησης μητρώου αντικειμένων συμπληρώνει τη σχετική φόρμα εισόδου. Σε περίπτωση δανεισμού συμπληρώνει τα στοιχεία στον κατάλογο δανεισμών και προωθεί το αντικείμενο στον υπεύθυνο της έκθεσης στην οποία θα συμπεριληφθεί. Σε κάθε άλλη περίπτωση επικοινωνεί με τον Επιμελητή του Μουσείου. 3. Ο Επιμελητής αποφασίζει με βάση τους κανονισμούς του Μουσείου αν το αντικείμενο θα συμπεριληφθεί στη συλλογήτουμουσείουήόχι. Σε περίπτωση απόρριψης το αντικείμενο επιστρέφεται και η σχετική πληροφορία καταγράφεται στη φόρμα εισόδου του αντικειμένου. Σε αντίθετη περίπτωση το αντικείμενο καταχωρείται στο μητρώο αντικειμένων του μουσείου. 4. Ο Επιμελητής μετά από σχετική έρευνα συλλέγει όλα τα απαραίτητα στοιχεία για την τεκμηρίωση του αντικειμένου τα οποία και καταχωρεί στον κατάλογο του Μουσείο. 5. Αν απαιτείται συντήρηση του αντικειμένου τότε ο Επιμελητής το προωθεί στο τμήμα συντήρησης διαφορετικά το μεταφέρει στο μόνιμο σημείο αποθήκευσής του. Β Παροχή πληροφοριών 1. Ερώτημα για κάποιο αντικείμενο τίθεται στον υπάλληλο του Μουσείου από κάποιον επισκέπτη ή ερευνητή 2. Αν υπάρχει ήδη η πληροφορία σε κάποια έκδοση του μουσείου τότε ο επισκέπτης / ερευνητής παραπέμπεται στο σχετικό κείμενο. Διαφορετικά ο υπάλληλος παραπέμπει τον επισκέπτη / ερευνητή στον Επιμελητή του Μουσείου ο οποίος έχει πρόσβαση στον κατάλογο της συλλογής του Μουσείου. 26 13

Υποσύστημα Μητρώου αντικειμένων Αξιολόγηση αντικειμένου Υποσύστημα Καταλόγου Μουσείου Υπ. Μητρώου Εισαγωγή στο μητρώο αντικειμένων εξαρτάται από Δημιουργία καρτέλας νέου αντικειμένου Επιμελητής Ενημέρωση μητρώου αντικειμένων Τροποποίηση καρτέλας αντικειμένου Εισαγωγή στον κατάλογο δανεισμών Υπ. Έκθεσης χρησιμοποιεί Δημιουργία καρτέλας συντήρησης Αναζήτηση αντικειμένου Επισκέπτης Υπ. Συντήρησης 27 4: Τεκμηρίωση περιπτώσεων χρήσης Τίτλος Σύντομη περιγραφή Χειριστές Ροή γεγονότων Βασική ροή Εναλλακτικές ροές Μη λειτουργικές απαιτήσεις Π.χ. απαιτήσεις επίδοσης ή περιβάλλοντος Κατάσταση εισόδου προσυνθήκες (preconditions) Π.χ. δικαιώματα χρήστη Κατάσταση εξόδου μετασυνθήκες (postconditions) Π.χ. μεταβολές στην κατάσταση πόρων του συστήματος Σημεία επέκτασης 28 14

Περιγραφή περίπτωσης χρήσης «Ταυτοποίηση Πελάτη» 1. Τίτλος περίπτωσης χρήσης: Ταυτοποίηση πελάτη 1.1. Σύντομη περιγραφή Επιτρέπει στον πελάτη της τράπεζας να ταυτοποιηθεί στο σύστημα και να αποκτήσει πρόσβαση στο λογαριασμό του στην τράπεζα. 1.2. Χειριστές: πελάτης τράπεζας 2. Ροές γεγονότων 2.1. Βασική ροή: Βήμα 1. Το σύστημα εμφανίζει φόρμα εισαγωγής σε αυτό με την οποία ζητάει από το χρήστη να δώσει τα στοιχεία αναγνώρισης Βήμα 2. Ο χρήστης εισάγει τα στοιχεία Βήμα 3. Το σύστημα ελέγχει αν τα στοιχεία που δόθηκαν αντιστοιχούν σε πελάτη της τράπεζας Βήμα 4. Ο χρήστης εισέρχεται στο σύστημα αποκτώντας πρόσβαση στον αντίστοιχο λογαριασμό Βήμα 5. Το σύστημα παρουσιάζει μήνυμα επιτυχίας σύνδεσης Η περίπτωση χρήσης τελειώνει 2.2. Εναλλακτικές ροές 2.2.1. Εναλλακτική ροή 1 Νέος πελάτης Ο χρήστης δεν έχει ενεργοποιήσει τη δυνατότητα αυτόματων συναλλαγών. Το σύστημα παραπέμπει στην αντίστοιχη περίπτωση χρήσης «Ενεργοποίηση Αυτόματων Συναλλαγών» 2.2.2. Εναλλακτική ροή 2 Αποτυχία ταυτοποίησης χρήστη Το σύστημα δεν μπόρεσε να αναγνωρίσει τα στοιχεία χρήστη Βήμα 4α. Το σύστημα εμφανίζει σχετικό μήνυμα Βήμα 4β. Η ροή μεταφέρεται στο Βήμα 1 3. Μη λειτουργικές απαιτήσεις Τα στοιχεία χρήστη πρέπει να δίδονται με τέτοιο τρόπο ώστε να αποφεύγεται ο κίνδυνος υποκλοπής δεδομένων (ασφάλεια). Η ταυτοποίηση πρέπει να γίνεται σε χρόνο < 5 (ταχύτητα) 4. Κατάσταση εισόδου Δεν υπάρχει 5. Κατάσταση εξόδου 1. Ο πελάτης ταυτοποιήθηκε επιτυχώς και ξεκίνησε να χρησιμοποιεί το σύστημα 29 2. Το σύστημα απέτυχε να ταυτοποιήσει τον πελάτη Εναλλακτική περιγραφή ροής γεγονότων Διαγράμματα δραστηριότητας Τα διαγράμματα δραστηριότητας (activity diagrams) παρουσιάζουν την ακολουθιακή ή παράλληλη εκτέλεση δραστηριοτήτων. Έχουν γενική χρήση. Μπορούν να χρησιμοποιηθούν για να περιγράψουμε τη λειτουργία ενός οργανισμού. Χρησιμοποιούνται για την μοντελοποίηση των περιπτώσεων χρήσης, βοηθώντας στην οπτικοποίηση των διαφορετικών μονοπατιών και στην κατανόηση της αναμενόμενης συμπεριφοράς του συστήματος. 30 15

Διάγραμμα δραστηριοτήτων Έναρξη Λήξη Ροή εργασιών Δ1 Δ2 Τίτλος Δ Δραστηριότητα Παράλληλη εκτέλεση εργασιών Δ1 Δ2 Σύγκλιση ροών Δ1 Δ2 Απόφαση [Συνθήκη 1] [Συνθήκη 2] Δ1 Δ2 31 Παράδειγμα: «Ταυτοποίηση Πελάτη» happy path Εμφάνιση φόρμας εισαγωγής στοιχείων πελάτη Εισαγωγή στοιχείων πελάτη Έλεγχος στοιχείων πελάτη Εμφάνιση μηνύματος λάθος στοιχείων [λάθος στοιχεία] [μη ενεργή δυνατότητα] [σωστά στοιχεία] Σύνδεσημελογαριασμόπελάτη Εμφάνιση μηνύματος επιτυχίας 32 16

Πρακτικοί κανόνες Μια περίπτωση χρήσης περιγράφει την εργασία που μπορεί να εκτελέσει ένας χειριστής σε λίγα λεπτά της ώρας και μα έχει ένα ολοκληρωμένο αποτέλεσμα. Δεν περιγράφει απλά ένα βήμα για την επίτευξη του τελικού στόχου του χειριστή. Η λεκτική περιγραφή των περιπτώσεων χρήσης είναι εξίσου σημαντική με τη χρήση των διαγραμμάτων και πρέπει να της δίδεται ιδιαίτερη σημασία. Το όνομα της περίπτωσης χρήσης δείχνει ενέργεια Ο αριθμός των βημάτων της βασικής ροής είναι καλό να μην είναι μεγάλος (~10 βήματα). Κάθε βήμα να είναι μια απλή πρόταση σε ενεργητική φωνή. Η περίπτωση χρήσης θα πρέπει να μπορεί να ολοκληρωθεί. Δηλ. υπάρχει μια ροή εκτέλεσης που θα οδηγεί στην ολοκλήρωση της επιθυμητής συμπεριφοράς (happy path). Κάθε περίπτωση χρήσης μπορεί να τελειώσει με τουλάχιστον δύο τρόπους: επιτυχία και αποτυχία. Μια περίπτωση χρήσης πρέπει πέρα από την αλληλεπίδραση του χειριστή με το σύστημα να εγγυάται τα συμφέροντα των συμμετεχόντων. Πχ στην περίπτωση χρήσης «Ανάληψη Μετρητών» το σύστημα πρέπει να εξασφαλίσει ότι ο πελάτης δε θα πάρει περισσότερα χρήματα από όσα έχει καταθέσει και ότι δε θα υπερβεί το εβδομαδιαίο όριο αναλήψεων κλπ. Όλα αυτά πρέπει να καταγράφονται στη βασική και στις εναλλακτικές ροές. Η ανάπτυξη του μοντέλου περιπτώσεων χρήσης γίνεται πρώτα σε πλάτος και στη συνέχεια σε βάθος. Δηλ. πρώτα καλύπτουμε όλες τους βασικούς στόχους του συστήματος και στη συνέχεια περιγράφουμε με λεπτομέρειες τις διακριτές λειτουργίες του συστήματος. 33 Ανάλυση περιπτώσεων χρήσης Το μοντέλο ανάλυσης μεταφέρει τις απαιτήσεις του μοντέλου περιπτώσεων χρήσης στη γλώσσα των κατασκευαστών, δηλ. με όρους δομικών μονάδων λογισμικού (κλάσεις) Καθορίζει Τις κλάσεις που θα αποτελέσουν την εφαρμογή λογισμικού Την ομαδοποίησή τους Τις μεταξύ τους συσχετίσεις Δεν περιλαμβάνει κατασκευαστικές λεπτομέρειες και χαρακτηριστικά του περιβάλλοντος ανάπτυξης και λειτουργίας 34 17

Κλάσεις στο μοντέλο ανάλυσης Συνοριακή κλάση Παριστάνει την αλληλεπίδραση του λογισμικού με τους Χειριστές Συνήθως αντιστοιχούν σε παράθυρα διαλόγου, οδηγούς συσκευών, πρωτόκολλα επικοινωνιών Κλάση οντοτήτων Παριστάνει οντότητες και συμβάντα του πραγματικού κόσμου Αντιστοιχούν στις οντότητες του μοντέλου ΟΣ Κλάση ελέγχου Αντιστοιχεί στο συντονισμό και τη διαχείριση δοσοληψιών και γεγονότων, καθώς και τον έλεγχο ροής προγράμματος και υπολογισμών που δεν μπορούν να αποδοθούν σε συνοριακές κλάσεις ή κλάσεις οντοτήτων 35 Παράδειγμα Κατατάξτε τις παρακάτω κλάσεις ανάλυσης Καθηγητής Φοιτητής Φόρμα εισαγωγής στοιχείων Παράθυρο επιβεβαίωσης διαγραφής Βιβλίο Διαχειριστής συστήματος backup Δανεισμός Οδηγός αισθητήρα θερμοκρασίας Διαχειριστής εκτυπώσεων συστήματος 36 18

Εντοπισμός κλάσεων Δεδομένα που εντοπίζονται στην περιγραφή μιας περίπτωσης χρήσης αντιστοιχούν σε κλάσεις οντοτήτων (ή σε πεδία τέτοιων κλάσεων) Για κάθε χειριστή ορίζεται τουλάχιστον μια συνοριακή κλάση, η οποία αντιστοιχεί στη διεπιφάνεια (user interface) μέσω της οποίας ο Χειριστής αλληλεπιδρά με το σύστημα αν ο χειριστής αντιστοιχεί σε εξωτερικό σύστημα, οι κλάσεις αυτές αντιστοιχούν σε πρωτόκολλα, οδηγούς συσκευών κτλ Ορίζεται μια τουλάχιστον κλάση ελέγχου για τον έλεγχο της ροής της περίπτωσης χρήσης σε απλές περιπτώσεις η κλάση αυτή ενσωματώνεται στη συνοριακή κλάση με το χειριστή σε πιο σύνθετες περιπτώσεις μπορεί να αντιστοιχεί σε σύστημα διαχείρισης δοσοληψιών, μηνυμάτων, κτλ 37 Παράδειγμα: Ανάληψη ποσού Διάβασμα στοιχείων κάρτας Επαλήθευση στοιχείων Εμφάνιση μηνύματος λάθους στοιχείων [λάθος στοιχεία] [σωστά στοιχεία] Σύνδεση με λογαριασμό Διάβασμα ποσού Εμφάνιση μηνύματος λάθους ποσού [άκυρο ποσό] [έγκυρο ποσό] Εμφάνιση υπολοίπου Ανάληψη από λογαριασμό Δημιουργία ανάληψης 38 19

Κλάσεις ανάλησης Ανάληψη Κάρτα Βήμα1. Δεδομένα που σχετίζονται με την περίπτωση χρήσης Έλεγχος Ανάληψης Λογαριασμός Ανάληψη Βήμα3. Η απαραίτητη κλάση ελέγχου Βήμα2. Ο χειριστής, το κύριο παράθυρο επικοινωνίας με την εφαρμογή (Console), το μήνυμα υπολοίπου και τα μηνύματα λάθους Μήνυμα λάθος στοιχείων Πελάτης Console Μήνυμα υπολοίπου Μήνυμα λάθος ποσού 39 Μελέτη περίπτωσης: Γραμματεία Πελάτης: υπεύθυνος λειτουργίας της γραμματείας Σκοπιμότητα: Το μεγάλο πλήθος φοιτητών, καθηγητών και μαθημάτων καθώς και η πολυπλοκότητα των εργασιών υποστήριξης επιβάλουν τη χρήση αυτοματοποιημένης εφαρμογής Περιγραφή: Η εφαρμογή θα πρέπει να τηρεί αρχεία φοιτητών, καθηγητών, μαθημάτων, εγγραφής σε μαθήματα, καθώς και αποτελέσματα βαθμολογίας. Η εφαρμογήθαπρέπεινατυπώνει καταστάσεις φοιτητών, καθηγητών, μαθημάτων και βαθμολογίας, με κριτήρια που θα δίνει ο χρήστης. Η εφαρμογήδεθαπρέπεινα επιτρέπει τη διαγραφή ενός φοιτητή ή καθηγητή από το αρχείο αν αυτός έχει εγγραφεί σε ή του έχει ανατεθεί μάθημα, αντίστοιχα. Το περιβάλλον λειτουργίας θα είναι ένας αυτόνομος ηλεκτρονικός υπολογιστής με Windows XP (ή επόμενη έκδοση). 40 20

Γραμματεία: Διάγραμμα περιπτώσεων χρήσης Τήρηση αρχείου καθηγητών Διαγραφή καθηγητή Τήρηση αρχείου φοιτητών Χειριστής γραμματείας Διαγραφή φοιτητή Τήρηση αρχείου μαθημάτων Διαγραφή μαθήματος Το διάγραμμα αυτό παριστάνει υποσύνολο των λειτουργικών απαιτήσεων. Μπορείτε να βρείτε κι άλλες περιπτώσεις χρήσεις; Τι θα συμβεί στην περίπτωση που ο διδάσκων ενός μαθήματος είναι δυνατό να καταχωρεί ο ίδιος τη βαθμολογία των σπουδαστών; 41 Αρχή περίπτωσης χρήσης Παράδειγμα: Διάγραμμα δραστηριότητας «τήρηση αρχείου φοιτητών» Τήρηση αρχείου φοιτητών Επιλογή εργασίας «τήρηση αρχείου φοιτητών» Άνοιγμα αρχείου φοιτητών Εμφάνιση φόρμας διαλόγου Εισαγωγή στοιχείων από το χρήστη CANCEL Τέλοςπερίπτωσηςχρήσης ΟΚ Έλεγχος εγκυρότητας στοιχείων Εμφάνιση μηνύματος ΑΚΥΡΑ ΕΓΚΥΡΑ Δημιουργία νέας εγγραφής φοιτητή 42 21

Παράδειγμα: Κλάσεις εφαρμογής Γραμματείας Τήρηση αρχείου φοιτητών Φοιτητές Βήμα1. Προφανή δεδομένα που σχετίζονται με την περίπτωση χρήσης (Έλεγχος ) Τήρηση αρχείου φοιτητών Βήμα3. Η απαραίτητη κλάση ελέγχου Βήμα2. Ο χειριστής, το κύριο παράθυρο επικοινωνίας με την εφαρμογή, ο διάλογος εισόδου δεδομένων και το μήνυμα σε περίπτωση άκυρων δεδομένων Χειριστής γραμματείας Interface Χειριστή γραμματείας Εισαγωγή δεδομένων φοιτητή Μήνυμα ακυρότητας 43 δεδομένων 22