Transcript Στόχοι του use case modeling

Moντελοποίηση
Περιπτώσεων Χρήσης
(Use Case Modelling)
Περίπτωση Χρήσης
Ορισμός
Ένα σύνολο σεναρίων που συνδέονται με ένα
κοινό σκοπό (για τον χρήστη)
Συνήθως περιλαμβάνει:
- Ενα πρωταρχικό σενάριο (σαν μια
ακολουθία απο βήματα)
- Τις εναλλακτικές περιπτώσεις (σαν
παραλλαγές της κύριας ακολουθίας
βημάτων)
Παράδειγμα Σεναρίου
Ο πελάτης ξεφυλλίζει τον κατάλογο και προσθέτει
αντικείμενα στο καλάθει αγορών. Όταν θελήσει να
πληρώσει, περιγράφει τον επιθυμητό τρόπο αποστολής
προϊόντων, δίνει τα στοιχεία της πιστωτικής του κάρτας,
και επιβεβαιώνει την αγορά. Το σύστημα ελέγχει την
εγκυρότητα της πιστωτικής κάρτας και επιβεβαιώνει την
αγορά αμέσως αλλά κα με την αποστολή ενός μηνύματος
ηλεκτρονικού ταχυδρομείου
Παράδειγμα Περίπτωσης
Χρήσης (1)
1. Ο πελάτης ξεφυλλίζει τον κατάλογο και επιλέγει τα προϊόντα που θα
αγοράσει
2. Ο πελάτης προχώρει προς την έξοδο
3. Ο πελάτης συμπληρώνει τις πληροφορίες αποστολής
4. Το σύστημα παρουσιάζει την πλήρη πληροφορία τιμολόγησης
συμπεριλαμβανομένων και των εξόδων αποστολής
5. Ο πελάτης συμπληρώνει τα στοιχεία της πιστωτικής του κάρτας
6. Το σύστημα εγκρίνει την αγορά
7. Το σύστημα επιβεβαιώνει αμέσως την πώληση
8. Το σύστημα στέλνει ένα μήνυμα βεβαίωσης της πώλησης στον πελάτη
μέσω ηλεκτρονικού ταχυδρομείου
Παράδειγμα Περίπτωσης
Χρήσης (2)
Εναλλακτικό σενάριο: Αποτυχία έγκρισης
Στο βήμα 6, το σύστημα αποτυγχάνει να εγκρίνει την πίστωση για την αγορά.
Να επιτραπεί στον πελάτη να ξαναδώσει τα στοιχεία της πιστωτικής του
κάρτας και να γίνει προσπάθεια.
Εναλλακτικό σενάριο: Τακτικός Πελάτης
3α. Το σύστημα παρουσιάζει την ισχύουσα μέθοδο αποστολής, τις
πληροφορίες τιμολόγησης και τα τέσσερα τελευταία ψηφία της ισχύουσας
πιστωτικής κάρτας.
3β. Ο πελάτης ενδέχεται να απορρίψει ή να αποδεχθεί τις προεπιλογές
Επιστροφή στο βήμα 6 του βασικού σεναρίου.
Στόχοι της Μοντελοποίησης
Περιπτώσεων Χρήσης
• Να καθορίσει και να περιγράψει τις λειτουργικές
απαιτήσεις του συστήματος
• Να δώσει μια σαφή και συνεπή περιγραφή για το
τι θα πρέπει να κάνει το σύστημα
• Να παρέχει την κατάλληλη βάση για να γίνονται
έλεγχοι γιά επαλήθευση του συστήματος.
• Να παρέχει την ικανότητα ν’ανιχνεύονται
(εντοπίζονται) οι λειτουργικές απαιτήσεις μέσα
στις κλάσεις και τις λειτουργίες του συστήματος
Διαγράμματα Περιπτώσεων
Χρήσης

Περιγράφουν τη λειτουργική διάσπαση του
συστήματος σε περιπτώσεις χρήσης και χαρακτήρες
(actors) που αλληλεπιδρούν με αυτές
– Οι περιπτώσεις χρήσης αναπαριστούν τις απαιτήσεις του
πελάτη

Αποτέλεσμα δημιουργίας του μοντέλου της
περίπτωσης χρήσης
– Γενικό (καθολικό) διάγραμμα περίπτωσης χρήσης
– Λεπτομερής περιγραφή με κείμενο (textual description)
κάθε περίπτωσης χρήσης
Διάγραμμα Περίπτωσης
Χρήσης
Διάγραμμα Πείπτωσης Χρήσης-δείχνει τους χρήστες,τις
διάφορες εφαρμογές και τις μεταξύ τους σχέσεις
Υπογραφή του συμβολαίου
ασφάλειας
Στατιστικά στοιχεία πωλήσεων
ΠΕΛΑΤΗΣ
Στατιστικά πελάτη
ΑΝΤΙΠΡΟΣΩΠΟΣ
ΑΣΦΑΛΕΙΩΝ
Μοντελοποίηση γενικής
εικόνας του συστήματος
ΣΥΣΤΗΜΑ ΕΠΙΚΥΡΩΣΗΣ
ΠΙΣΤΩΤΙΚΩΝ ΚΑΡΤΩΝ
Εκτέλεση συναλλαγής
με πιστωτική κάρτα
Πελάτης
Επεξεργασία λογαριασμού
πελάτη
Εταιρεία Λιανικής
Πώλησης
Διευθέτηση συναλλαγών
Πελάτης
Ανθρωπος
Πελάτης
Εταιρεία
Διαχείριση λογαριασμού
πελάτη
Οργανισμός
Οικονομικής
Χρηματοδότησης
Bήματα για τη δημιουργία των
διαγραμμάτων περιπτώσεων
χρήσης
•
•
•
•
•
•
Kαθορισμός των ορίων του συστήματος
Εύρεση των χαρακτήρων (actors) καί των
περιπτώσεων χρήσης
Κατασκευή γενικού (καθολικού) διαγράμματος
περιπτώσεων χρήσης
Περιγραφή των περιπτώσεων χρήσης (με απλό
κείμενο ή με activity diagrams)
Eύρεση των συσχετίσεων μεταξύ των
περιπτώσεων χρήσης
Επικύρωση του μοντέλου των περιπτώσεων
χρήσης
Συστήματα στα διαγράμματα
περιπτώσεων χρήσης
Επιχείρηση ασφαλειών
Σύστημα σ’ένα μοντέλο Περίπτωσης Χρήσης. Το
σύστημα μπορεί να είναι ένα λογισμικό, μια
επιχείρηση ή ένα μηχάνημα
Διάγραμμα Περίπτωσης
Χρήσης– Χαρακτήρες (1)


Οι Χαρακτήρες (Actors) αλληλεπιδρούν με το σύστημα
– χρησιμοποιώντας το σύστημα, δηλ. ξεκινώντας την εκτέλεση
των περιπτώσεων χρήσης
– με το να χρησιμοποιούνται από το σύστημα, δηλ.
παρέχοντας τη λειτουργικότητα για να πραγματοποιούνται
οι περιπτώσεις χρήσης
– κάθε χαρακτήρας πρέπει να επικοινωνεί με τουλάχιστον μία
περίπτωση χρήσης
– η σχέση επικοινωνίας είναι μη κατευθυνόμενη
Οι χαρακτήρες αναπαριστούν ρόλους (roles)
– οι πραγματικοί χρήστες μπορούν να έχουν περισσότερους
από έναν ρόλους σε κάθε χρονική στιγμή.
– οι χαρακτήρες βρίσκονται εκτός των ορίων του συστήματος
Διάγραμμα Περίπτωσης
Χρήσης– Χαρακτήρες (2)






Ο χαρακτήρας εκπροσωπεί ένα ρόλο κι όχι έναν
συγκεκριμένο χρήστη του συστήματος
Ενας χαρακτήρας μπορεί να έχει πολλούς ρόλους
Επικοινωνεί με το σύστημα στέλνοντας και
λαμβάνοντας μηνύματα
Μια περίπτωση χρήσης ενεργοποιείται από έναν
χαρακτήρα
Ο χαρακτήρας εκπροσωπεί ένα ρόλο κι όχι έναν
συγκεκριμένο χρήστη του συστήματος
Ένας χαρακτήρας είναι μια κλάση, όχι ένα
στιγμιότυπο
Διάγραμμα Περίπτωσης
Χρήσης– Χαρακτήρες (3)
Πρωτεύων
χαρακτήρας
Δευτερεύων
χαρακτήρας
Ενεργητικός
χαρακτήρας
Παθητικός
χαρακτήρας
Χρησιμοποιεί τις πρωτεύουσες
λειτουργίες του συστήματος
(π.χ. Λογιστής)
Χρησιμοποιεί δευτερεύουσες
λειτουργίες όπως αυτές που
συντηρούν το σύστημα κ.α
(π.χ. Δ/ντής Οικονομικών)
Είναι αυτός που ενεργοποιεί μια περίπτωση
χρήσης
Δεν αρχικοποιεί αλλά συμμετέχει
σε μια περίπτωση χρήσης, π.χ. εκτυπωτής
Διάγραμμα Περίπτωσης
Χρήσης– Χαρακτήρες (4)
Οι χαρακτήρες στην UML
«Χαρακτήρας»
Πράκτορας
Ασφαλειών
Πράκτορας ασφαλειών
Ο χαρακτήρας είναι μια κλάση και σχεδιάζεται σαν ένα ορθογώνιο
κλάσεων με το στερεότυπο “ χαρακτήρας ”. H διπλανή εικόνα με το
ανθρωπάκι (stickman) έχει το όνομα του χαρακτήρα (actor) από κάτω
Σχέση γενίκευσης μεταξύ
χαρακτήρων (actors)
Ένας χαρακτήρας που κληρονομεί από έναν
άλλον χαρακτήρα Α είναι ικανός να
επικοινωνεί με τις ίδιες περιπτώσεις χρήσεις
όπως ο Α
 Η πολλαπλή κληρονομικότητα επιτρέπεται

Telephone
Customer
Customer
Personal Visit
Customer
Ερωτήσεις γιά την εύρεση των
χαρακτήρων (actors)
•
•
•
•
•
•
Ποιοί θα χρησιμοποιούν την κύρια λειτουργικότητα
του συστήματος;
Ποιοί χρειάζονται υποστήριξη από το σύστημα στις
καθημερινές τους ασχολίες;
Ποιοί θα συντηρούν καί διαχειρίζονται το σύστημα;
Ποιά περιφερειακά υλικού χρειάζεται το σύστημα να
χρησιμοποιεί;
Με ποιά άλλα συστήματα χρειάζεται να επικοινωνεί
το σύστημα;
Ποιός ή τί έχει ενδιαφέρον γιά τα αποτελέσματα που
θα παράγει το σύστημα;
Διάγραμμα Περίπτωσης
Χρήσης– Τι είναι η περίπτωση
χρήσης
• Είναι ένα σύνολο από ενέργειες που καταλήγουν
σε ένα αποτέλεσμα χρήσιμο στον εξωτερικό actor
• Μια περίπτωση χρήσης ενεργοποιείται από έναν
actor
• Προσφέρει ένα χρήσιμο αποτέλεσμα στον
εξωτερικό actor
• Είναι μια πλήρης περιγραφή.Ένα κοινό λάθος
είναι η διαίρεση μιας περίπτωσης χρήσης σε
μικρότερα διαγράμματα των περιπτώσεων χρήσης
Αναπαράσταση Περίπτωσης
Χρήσης
Οι περιπτώσεις χρήσεις παριστάνονται
σαν ελλείψεις στα όρια του συστήματος κι έχουν
συνδέσεις με τους χαρακτήρες.
Σύνδεσμος
επικοινωνίας
Όνομα Χαρακτήρα
Όνομα Περίπτωσης
U
Χρήσης
System name
Use case
Περίπτωση
Χρήσης Α
θΘΘΣΕ
Περίπτωση
Χρήσης Β
Περίπτωση
Χρήσης Β
Παράδειγμα Περίπτωσης
Χρήσης - CALENDARIUM
insert
appointment
Ένα ραντεβού μπορεί να εισαχθεί
για
έναν
ή
περισσότερους
συμμετέχοντες από ένα χρήστη
που έχει γίνει authorized και ο
οποίος δε χρειάζεται να είναι ένας
από τους συμμετέχοντες. Όλοι οι
συμμετέχοντες
πρέπει
να
ενημερωθούν για το νέο ραντεβού.
Τα νέα ραντεβού πρέπει να είναι
άμεσα ορατά σε όλα τα ανοιχτά
ημερολόγια
των
αντίστοιχων
συμμετεχόντων
Παράδειγμα Περίπτωσης
Χρήσης
Πρόσθεσε τίτλο
Πρόσθεσε έναν καινούριο τίτλο με
τον τίτλο, συγγραφέα και ISBN
στο σύστημα
Ερωτήματα για την εύρεση
των περιπτώσεων χρήσης
•
•
•
•
Ποιες λειτουργίες απαιτεί ο χρήστης από το
σύστημα; τι χρειάζεται να κάνει;
Πρέπει ο χρήστης να διαβάσει,αποθηκεύσει,
δημιουργήσει, διαγράψει κάποια πληροφορία στο
σύστημα;
Χρειάζεται ο χρήστης να ειδοποιήσει το σύστημα ή
να ειδοποιηθεί από αυτό σε σχέση με κάποια
γεγονότα; πώς μεταφράζονται αυτά σε
λειτουργικότητα του συστήματος;
Μπορεί η καθημερινή δουλειά του χρήστη
ν’απλοποιηθεί με νέες λειτουργίες του συστήματος
Αλλες ερωτήσεις που δεν
ξεκινούν από actors
Tι εισόδους/εξόδους χρειάζεται το
σύστημα; Από που έρχονται καί πού
πηγαίνουν;
 Ποιά είναι τα κύρια προβλήματα με το
παρόν σύστημα (χειρογραφικό ή
αυτοματοποιημένο)

Αφαιρετική Περίπτωση
Χρήσης

Μία περίπτωση χρήσης που χρησιμοποιείται από
άλλες, αλλά δεν χρησιμοποιείται ποτέ από μόνη της.

Τη χρησιμοποιούμε απλά γιά οικονομία στις
περιγραφές μας. Δεν έχει υπόσταση μόνη της.
Σχέσεις μεταξύ των
περιπτώσεων χρήσης (1)
•
•
•
•
Σχέση «επεκτείνει» (extends):Μια περίπτωση χρήσης επεκτείνει
κάποια άλλη προσθέτοντας επιπλέον ενέργειες στη γενική
περίπτωση χρήσης.
Σχέση «γενικεύει/εξειδικεύει» (generalization/specialization): Mια
περίπτωση χρήσης κληρονομεί τη συμπεριφορά καί την
περιγραφή μιάς άλλης περίπτωσης χρήσης
Σχέση «περιλαμβάνει» (includes): Mιά περίπτωση χρήσης
περιλαβάνει τη συμπεριφορά μιάς άλλης
Σχέση ομαδοποίησης : Όταν ένας αριθμός περίπτωσης χρήσης
παρουσιάζει παρόμοια λειτουργικότητα ή σχετίζονται μεταξύ τους
με κάποιο τρόπο μπορούν να συμπεριληφθούν σε ένα UML πακέτο.
Ένα UML πακέτο ομαδοποιεί σχετικά στοιχεία μεταξύ τους. Αυτά
μπορούν να αναπαρασταθούν γραφικά από ένα σύμβολο ή
αναλυτικά όλα μαζί. Επιτρέπουν να βλέπουμε τμηματικά το
σύστημα.
Σχέσεις μεταξύ των
περιπτώσεων χρήσης(2)

Σχέση «επεκτείνει»
– Μια περίπτωση χρήσης «επεκτείνει» μια άλλη
περίπτωση χρήσης: η πρώτη περιλαμβάνει κάποια από
τη συμπεριφορά της κλάσης που επεκτείνει.
– Η περίπτωση χρήσης B που επεκτείνεται χρειάζεται τη
λειτουργία της βασικής περίπτωσης χρήσης A
«επεκτείνει»
A
B
Σχέσεις μεταξύ των
περιπτώσεων χρήσης (3)
Υπογραφή συμβολαίου ασφάλειας
«επεκτείνει»
Υπογραφή συμβολαίου αγοράς αυτοκινήτου
Σχέσεις μεταξύ των
περιπτώσεων χρήσης (4)
Configure program
Σημεία επέκτασης
Αλλαγή δικαιωμάτων προσπέλασης
Αλλαγή παραμέτρων
Configure δικαιώματα
προσπέλασης
Configure παραμέτρους





Πρέπει να καθοριστεί η συνθήκη υπό την οποία ενσωματώνεται η
επεκτείνουσα use case
Για κάθε περίπτωση χρήσης μπορούν να οριστούν πάνω από ένα σημεία
επέκτασης
Tα ονόματα των σημείων επέκτασης πρέπει να είναι μοναδικά
Tα ονόματα των σημείων επέκτασης δε χρειάζεται να είναι τα ονόματα των
περιπτώσεων χρήσης που κάνουν την επέκταση
Tα ονόματα των σημείων επέκτασης είναι απλά labels που εμφανίζονται
στη ροή των γεγονότων της βασικής περίπτωσης χρήσης
Σχέσεις μεταξύ των
περιπτώσεων χρήσης (5)
Σχέση «Περιλαμβάνει»
– Η συμπεριφορά της περίπτωσης χρήσης Α ενσωματώνεται στις
περιπτώσεις χρήσης Β καί Γ
– Η ενσωματωμένη περίπτωση χρήσης Α είναι απαραίτητη για τη
λειτουργικότητα των περιπτώσεων χρήσης Β καί Γ.
Α
«περιλαμβάνει»
Signing Car Insurance
Β
Signing Insurance Policy
«περιλαμβάνει»
Signing Life Insurance
Γ
Σχέσεις μεταξύ των
περιπτώσεων χρήσης (6)
Σχέση «Γενικεύει/Εξειδικεύει»
– Αντίστοιχη της σχέσης γενίκευσης ανάμεσα στις κλάσεις.
– Η περίπτωση χρήσης Α κληρονομεί τη συμπεριφορά της περίπτωσης
χρήσης Β και μπορεί να την επεκτείνει αλλά και να την υποσκελίσει
(override).
– Η περίπτωση χρήσης Α κληρονομεί τις σχέσεις επικοινωνίας της
περίπτωσης χρήσης Β.
– Επιτρέπει τη μοντελοποίηση των αφαιρετικών (abstract) περιπτώσεων
χρήσης.
A
B
Γενικεύει, Περιλαμβάνει &
Επεκτείνει
Place Order
--------------Extension Points
•Set priority
«επεκτείνει»
{set priority}
Place
Rush Order
«περιλαμβάνει»
Check Password
Validate User
Track Order
«περιλαμβάνει»
Main Flow of Events for Use Case Track Order:
Obtain and verify order number. Include (Validate
user). For each part in the order,query its status,
then report back to the user
Retinal Scan
ΣΧΕΣΕΙΣ ΓΕΝΙΚΕΥΣΗΣ/
ΕΞΕΙΔΙΚΕΥΣΗΣ
Main Flow of Events for Use Case Place Order: Include
(Validate user). Collect the user’s order items. (set priority).
Submit the order for processing.
Διάγραμμα Περίπτωσης
Χρήσης –Παράδειγμα
Library system
Add
title
Borrower
Make
Reservation
Remove
Reservation
Remove
title
«περιλαμβάνει»
Add item
«περιλαμβάνει»
Lend item
Librarian
Return of item
«περιλαμβάνει»
«περιλαμβάνει»
«περιλαμβάνει»
Maintenance
Remove item
«περιλαμβάνει»
Add
Borrower
«περιλαμβάνει»
Remove or
update borrοwer
Librarian
Calendarium
query entry
Export entries
Χρήστης
Delete entry
Change entry
Insert entry «περιλαμβάνει»
Configure program
Notify participants
Administrator
Administer entry type
Administer users
Update calendar
«actor»
Fax-system
«actor»
E-mail system
Calendarium
{abstract}
Insert entry
Insert appointment
Insert to-do entry
Ομαδοποίηση των περιπτώσεων
χρήσης σε πακέτα



Μεγάλα διαγράμματα περιπτώσεων χρήσης: πολύ
πολύπλοκα
UML μηχανισμός αφαίρεσης: πακέτα
Κριτήρια για διάσπαση
– Functional cohesion
«system»
– Χαρακτήρες (Actors)
Callendarium
– Εμπειρία
– ...
Appointment
System
Administration
Manager
Περιγράφοντας τις περιπτώσεις
χρήσεις (τι θα πρέπει να
περιλαμβάνει η περιγραφή κειμένου)
•
•
•
•
•
Αντικειμενικός στόχος των περιπτώσεων χρήσης : ο
στόχος που επιτυγχάνει κάθε περίπτωση χρήσης θα πρέπει
να είναι ολοφάνερος
Πώς ενεργοποιείται η περίπτωση χρήσης
H ροή των μηνυμάτων ανάμεσα στους χαρακτήρες (actors)
και στις περιπτώσεις χρήσεις : ποια μηνύματα
εναλλάσονται ανάμεσά τους.
Εναλλακτική ροή στη περίπτωση χρήσης : Μια περίπτωση
χρήσης μπορεί να παρουσιάζει εναλλακτικές εκτελέσεις
αναλόγως με κάποιες συνθήκες ή εξαιρέσεις
Πως μια περίπτωση χρήσης τελειώνει δίνοντας κάποιο
αποτέλεσμα στον χαρακτήρα (actor)
Παράδειγμα περιγραφής
περίπτωσης χρήσης:
Validate User σε ένα ΑΤΜ




Κύρια Ροή Γεγονότων: Η περίπτωση χρήσης αρχίζει όταν o πελάτης εισάγει την
κάρτα του. Το σύστημα ζητά από τον πελάτη PIN. Ο πελάτης εισάγει το PIN από
το πληκτρολόγιο καί στο τέλος πατά το κουμπί ENTER. To σύστημα ελέγχει την
εγκυρότητα του PIN. Eάν το PIN είναι έγκυρο, το σύστημα γνωστοποιεί την
εισαγωγή των στοιχείων καί η περίπτωση χρήσης τελειώνει.
Εναλλακτική Ροή Γεγονότων: Ο Πελάτης μπορεί ανά πάσα στιγμή να ακυρώσει
τη συναλλαγή με το πάτημα του κουμπιού CANCEL, κι έτσι η περίπτωση χρήσης
ξαναρχίζει
Εναλλακτική Ροή Γεγονότων: Ο Πελάτης μπορεί ανά πάσα στιγμή να
διαγράψει το PIN πριν το τελικό πάτημα του κουμπιού ENTER καί να ξαναβάλει
ένα νέο PIN.
Εναλλακτική Ροή Γεγονότων: Εάν ο πελάτης δώσει λανθασμένο PIN, η
περίπτωση χρήσης ξαναρχίζει. Αν αυτό συμβεί τρείς φορές συνεχόμενες, το
σύστημα ακυρώνει όλη τη συναλλαγή καί εμποδίζει τον πελάτη να κάνει άλλη
συναλλαγή στα επόμενα 60 δευτερόλεπτα.
Περιγραφή των
περιπτώσεων χρήσης

Να θυμάστε ότι:
– H περιγραφή σχετίζεται με τον εξωτερικό
χαρακτήρα (actor), όχι με το πως γίνονται τα
πράγματα μέσα στο σύστημα
– Το κείμενο να είναι σαφές, πλήρες, συνεπές,
γιά να μπορεί να κατανοηθεί καί να ελεγχθεί
από τον πελάτη - Σύνθετες καί περίπλοκες
προτάσεις να αποφεύγονται
Εναλλακτική Περιγραφή μιας
περίπτωσης χρήσης
•
Όνομα/σύντομη περιγραφή
•
Preconditions: προαπαιτούμενα για σωστή εκτέλεση
•
Post condition: κατάσταση του συστήματος μετά από επιτυχή
εκτέλεση
•
Καταστάσεις λάθους: μόνο λάθη που έχουν σχέση με το πεδίο
ορισμού
•
Post condition σε κατάσταση λάθους
•
Χαρακτήρες (actors): που επικοινωνούν με την περίπτωση χρήσης
•
Trigger: ένα συμβάν που προκαλεί την περίπτωση χρήσης
•
Κύριο σενάριο επιτυχίας: απλά βήματα/ άλλες περιπτώσεις χρήσεις
•
Επεκτάσεις/Διαφοροποιήσεις: αποκλίσεις από το κύριο σενάριο
επιτυχίας
Εναλλακτική Περιγραφή
περίπτωσης χρήσης-Παράδειγμα

Όνομα και σύντομη περιγραφή: Insert appointment «Ένα ραντεβού
μπορεί να εισαχθεί για έναν ή περισσότερους συμμετέχοντες από ένα χρήστη
που έχει γίνει authorized και ο οποίος δε χρειάζεται να είναι ένας από τους
συμμετέχοντες. Όλοι οι συμμετέχοντες πρέπει να ενημερωθούν για το νέο
ραντεβού. Τα νέα ραντεβού πρέπει να είναι άμεσα ορατά σε όλα τα ανοιχτά
ημερολόγια των αντίστοιχων συμμετεχόντων.»

Precondition: Ο χρήστης είναι γνωστός στο σύστημα

Postcondition:
– Εισάγεται ένα νέο ραντεβού
– Ειδοποιούνται οι συμμετέχοντες είτε για το νέο ραντεβού ή για το ότι δεν
επιτεύχθει λόγω προβλημάτων authorisation η εισαγωγή στο ημερολόγιο
– Ενημερώνονται όλες οι όψεις του ημερολογίου

Καταστάσεις λάθους: Ο χρήστης δεν έχει τα κατάλληλα δικαιώματα για
κάθε συμμετέχοντα ώστε να εισάγει το νέο ραντεβού στα ημερολόγιά τους.
Εναλλακτική Περιγραφή μίας
περίπτωσης χρήσης-Παράδειγμα

Postcondition σε περίπτωση λάθους:
– Το ραντεβού δεν μπορεί να εισαχθεί
– Τα ημερολόγια των συμμετεχόντων δεν τροποποιούνται, ούτε οι
διαφορετικές όψεις των ημερολογίων.

Χαρακτήρες (Actors): Χρήστης (πρωτεύων χαρακτήρας), E-mail-system
(δευτερεύων χαρακτήρας), Fax-system (δευτερεύων χαρακτήρας).

Trigger: -

Κύριο σενάριο επιτυχίας:
– (1) Ο χρήστης ταυτοποιείται
– (2) Καταγράφονται οι λεπτομέρειες του ραντεβού (πού πότε ποιοι)
– (3) Ο χρήστης έχει δικαίωμα να εισάγει το ραντεβού για όλους τους
συμμετέχοντες
– (4) Το ραντεβού δεν προκαλεί συγκρούσεις και εισάγεται
Εναλλακτική Περιγραφή μίας
περίπτωσης χρήσης-Παράδειγμα

– (5) Όλοι οι συμμετέχοντες (εκτός από το χρήστη αν είναι και
συμμετέχων) ενημερώνονται ανάλογα με τον τρόπο που έχουν
επιλέξει (fax ή e-mail) («include» notify participants)
– (6) Όλα τα ανοιχτά ημερολόγια των συμμετεχόντων
ενημερώνονται («include» update calendar)
Επεκτάσεις/Διαφοροποιήσεις:
– (3’) Ο χρήστης δεν έχει δικαίωμα για τουλάχιστον ένα
συμμετέχοντα
– (4’) Ανάλογα για το (4)
– (5’) Ανάλογα για το (5), όπου κάθε συμμετέχοντας του οποίου το
ημερολόγιο δεν μπορούσε να τροποποιηθεί ενημερώνεται για το
πρόβλημα
– (6’) Ενημερώνονται όλα τα ημερολόγια για τα οποία δεν υπάρχει
πρόβλημα
Forward Engineering των
περιπτώσεων χρήσης
•
•
•
•
Forward Engineering: είναι η διαδικασία μετατροπής ενός μοντέλου σε
κώδικα με στόχο τον έλεγχό του.
Κάθε περίπτωση χρήσης σε ένα διάγραμμα περίπτωσης χρήσης περιγράφει
τη ροή των γεγονότων (βασική καί εναλλακτικές). Αυτές οι ροές δείχνουν
την αναμενόμενη συμπεριφορά του συστήματος. Αυτό αξίζει να ελεχθεί.
Μιά καλοσχεδιασμένη περίπτωση χρήσης θα περιλαμβάνει καί pre-, postconditions που μπορούν να χρησιμοποιηθούν γιά καθορισμό της αρχικής
κατάστασης του ελέγχου καί των κριτηρίων επιτυχίας του.
Μπορείτε να κατασκευάσετε μιά test case γιά κάθε περίπτωση χρήσης
μέσα σε ένα διάγραμμα περίπτωσης χρήσης, έτσι ώστε να το ‘τρέχετε’
κάθε φορά που κατασκευάζετε μιά νέα έκδοση, εξασφαλίζοντας με αυτό
τον τρόπο ότι αυτό δουλεύει έτσι όπως χρειάζεται, πριν προχωρήσετε στην
κατασκευή άλλων διαγραμμάτων που εξαρτώνται από αυτό.
Θυμηθείτε ότι οι περιπτώσεις χρήσης περιγράφουν ΤΙ
κάνει κομμάτι του συστήματος, πως συμπεριφέρεται
καί όχι πώς υλοποιείται αυτή η συμπεριφορά
Άλλοι τρόποι περιγραφής
των περιπτώσεων χρήσης

Περιγραφή μέσω των διαγραμμάτων δραστηριοτήτων
(activity diagrams) : φανερώνουν την ακολουθία των
γεγονότων και τις αποφάσεις που λαμβάνονται για το ποια
δραστηριότητα θα επακολουθήσει

Περιγραφή μέσω σεναρίου :To σενάριο δείχνει μια
συγκεκριμένη περίπτωση ,στην οποία εμπλέκονται
εξωτερικοί χρήστες σε άμεσα προσδιορισμένα
στιγμιότυπα. Το σενάριο αποτελεί μόνο συμπλήρωμα του
use-case και δεν υποκαθιστά πλήρως μια περιγραφή του
use-case
Ερωτήσεις γιά το τέλος της
μοντελοποίησης των
περιπτώσεων χρήσεις

Στοχεύουν:
– Να επιβεβαιώσουν ότι δεν έχει παραληφθεί
κάποια περίπτωση χρήσης ή κάποιος
χαρακτήρας (actor).
– Nα αναδείξουν διάφορες συσχετίσεις μεταξύ
των χαρακτήρων (actors) ή μεταξύ των
περιπτώσεων χρήσης (σχέσεις «γενικεύει»,
«περιλαμβάνει», «επεκτείνει»).
Ερωτήσεις γιά το τέλος της
μοντελοποίησης των
περιπτώσεων χρήσεις
•
•
•
•
•
•
Υπάρχει μία τουλάχιστον σύνδεση γιά κάθε χαρακτήρα με μια ή περισσότερες
περιπτώσεις χρήσης?
Υπάρχουν χαρακτήρες ή περιπτώσεις χρήσεις που δεν έχουν καμμιά σύνδεση
επικοινωνίας; Αν ναί, κάτι πάει λάθος: ή έχουμε παραλείψει κάτι, ή είναι περιττοί
οι χαρακτήρες ή οι περιπτώσεις χρήσεις
Υπάρχουν ομοιότητες μεταξύ κάποιων actors που αντιπροσωπεύουν κάποιο ρόλο
καί θα μπορούσαν να περιγραφούν σαν μιά «βασική κλάση χαρακτήρα»?
Υπάρχουν ομοιότητες μεταξύ των κάποιων περιπτώσεων χρήσεις που μπορούν
να απομονωθούν καί να περιγραφούν με μιά σχέση «περιλαμβάνει» ή με μιά
σχέση «γενίκευσης/εξειδίκευσης»?
Υπάρχουν ειδικές περιπτώσεις σε μιά περίπτωση χρήσης που θα μπορούσαν να
περιγραφούν με μιά σχέση «επεκτείνει»?
Υπάρχουν κάποιες λειτουργικές απαιτήσεις που δεν συμπεριλαμβάνονται σε
καμιά περίπτωση χρήσης? Αν ναί, δημιιουργείστε ανάλογες περιπτώσεις χρήσεις
γι’ αυτές τις απαιτήσεις
Mιά καλοσχεδιασμένη
πέριπτωση χρήσης…
•
•
•
•
Περιγράφει μιά συγκεκριμένη καί λογικά ατομική
(ανεξάρτητη) συμπεριφορά του συστήματος (ή μέρους
του συστήματος)
Περιγράφει τη ροή των γεγονότων με σαφή καί εύληπτο
τρόπο γιά κάποιον μη ειδικό πληροφορικής
Περιγράφεται με ένα ελάχιστο σύνολο σεναρίων που
περιγράφουν την κανονική συμπεριφορά καί
εναλλακτικές συμπεριφορές της περίπτωσης χρήσης
Έχει χρησιμοποιήσει με επιτυχία τις σχέσεις
γενίκευσης/εξειδίκευσης, «περιλαμβάνει» καί
«επεκτείνει»
Οταν σχεδιάζετε
περιπτώσεις χρήσεις στη
UML …
•
Δείξτε μόνο τις περιπτώσεις χρήσεις που είναι
απαραίτητα γιά την κατανόηση της
συμπεριφοράς του συστήματος ή μέρους του
συστήματος εντός των ορίων του
•
Δείξτε μόνο τους χαρακτήρες (actors) που
σχετίζονται με αυτές τις περιπτώσεις χρήσεις
Οταν σχεδιάζετε
περιπτώσεις χρήσεις στη
UML …
•
•
•
•
•
Δώστε ένα όνομα που δείχνει το σκοπό της περίπτωσης
χρήσης
Bάλτε τα διάφορα στοιχεία με τέτοιο τρόπο ώστε να
ελαχιστοποιηθούν οι γραμμές που διασταυρώνονται
Οργανώστε το έτσι ώστε οι ρόλοι καί οι συμπεριφορές που
συσχετίζονται να βρίσκονται κοντά καί φυσικά
Χρησιμοποιείστε χρώμα καί σημειώσεις γιά να τραβήξετε
την προσοχή σε σημαντικά σημεία του διαγράμματος
Μη δείχνετε πολλά είδη συσχετίσεων. Γενικά, αν έχετε
πολύπλοκες συσχετίσεις «γενίκευσης/εξειδίκευσης»,
«περιλαμβάνει» ή «επεκτείνει», βάλτε τες σε ξεχωριστό
διάγραμμα
Τρόποι επαλήθευσης
των περιπτώσεων χρήσης
Επαλήθευση
(Verification)
Επιβεβαιώνει ότι το σύστημα
έχει αναπτυχθεί σωστά
Επικύρωση
(Validation)
Επιβεβαιώνει ότι το υπό
ανάπτυξη σύστημα πληρεί
τις απαιτήσεις του χρήστη
Walking the use case
(τρόπος ελέγχου της εγκυρότητας/πληρότητας
των περιπτώσεων χρήσης)

Οι συμμετέχοντες παίζουν εναλλάξ τους εξής
ρόλους:
– Χαρακτήρας (Actor)
– Σύστημα
– Ακροατές που κρατούν σημειώσεις

Πολύτιμη πηγή γιά πληροφορία που έχει
παραληφθεί (λεπτομέρειες γιά κάποιες
περιπτώσεις χρήσεις ή καί ολόκληρες περιπτώσεις
χρήσεις)
Οι αρχές της UML για την υλοποίηση
των περιπτώσεων χρήσεις
• Μια περίπτωση χρήσης υλοποιείται σαν μια συνεργασία
κλάσεων καί αντικειμένων (collaboration) : δείχνει την
εσωτερική υλοποίηση στο επίπεδο των αντικειμένων και
των κλάσεων και τις μεταξύ τους σχέσεις (το πεδίο
(context) της συνεργασίας (collaboration).
• Επίσης φανερώνει τη μεταξύ τους αλληλεπίδραση για την
επίτευξη της επιθυμητής λειτουργικότητας
(αλληλεπίδραση (interaction) της συνεργασίας των
κλάσεων).
• H collaboration εκπροσωπείται στη UML από έναν αριθμό
διαγραμμάτων που δείχνουν τόσο το πεδίο όσο και την
αλληλεπίδραση μεταξύ των συστατικών.
• Το σενάριο είναι ένα στιγμιότυπο της περίπτωσης χρήσης ή
του collaboration, που περιγράφει τις εμπλεκόμενες
κλάσεις, τις λειτουργίες του και τη μεταξύ τους
επικοινωνία
Σενάριο

Όταν το σενάριο περιγράφει μιά περίπτωση
χρήσης, περιορίζεται μόνο στην εξωτερική
συμπεριφορά που είναι ορατή προς τους
χαρακτήρες (actors)

Όταν το σενάριο είναι ένα στιγμιότυπο ενός
collaboration, τότε περιγράφει την εσωτερική
υλοποίηση των σχετικών κλάσεων, των
λειτουργιών τους καί της επικοινωνίας τους.
Υλοποίηση Περίπτωσης Χρήσης
Μια περίπτωση χρήσης υλοποιείται απο ένα “collaboration” και από ένα
σύνολο απο κλάσεις που συμμετέχουν στο collaboration
«πραγματοποιεί»
Use case
Collaboration
υλοποιεί
Κλάση Α
Περιγραφή του use-case
1.O actor πατά ένα κουμπί
2.Το use-case υλοποιεί μια
ενέργεια.
3.Το use-case απαντά με ένα
μήνυμα στον χρήστη
Λειτουργ. 1
Λειτουργ. 2
υλοποιεί
υλοποιεί
Κλάση Β
Λειτουργ. 1
Λειτουργ. 2
Κλάση Γ
Λειτουργ. 1
Λειτουργ. 2
Για την υλοποίηση μιας περίπτωσης χρήσης , η ευθύνη κάθε
βήματος που περιγράφεται στο κείμενο μεταφέρεται στη συνεργασία ανάμεσα
στις κλάσεις ,στις μεταξύ τους συσχετίσεις και λειτουργίες
Είδη αντικειμένων
• Χρησιμοποιούνται για την περιγραφή του collaboration που
υλοποιεί μια περίπτωση χρήσης (μέθοδος Jacobson)
Αντικείμενα ορίων : αυτό το είδος των αντικειμένων
βρίσκεται κοντά στα όρια του συστήματος και
αλληλεπιδρά με τους χρήστες έξω από τα όρια του
συστήματος
Αντικείμενα ελέγχου : ελέγχουν τις αλληλεπιδράσεις
ανάμεσα σε ομάδες αντικειμένων
Αντικείμενα οντότητας : o τύπος αυτού του
αντικειμένου εκπροσωπεί μια οντότητα στην περιοχή
εφαρμογής του συστήματος. Είναι κυρίως παθητικό
και δεν αρχικοποιεί αλληλεπιδράσεις από μόνο του.
Εναλλακτικοί Μέθοδοι
Ανάπτυξης Συστημάτων

Oδηγούμενη από τις περιπτώσεις χρήσεις

Οδηγούμενη από αρχική δημιουργία ενός
μοντέλου κλάσεων καί των συσχετίσεών τους
στο χώρο του προβλήματος

Συνδυασμός
Η διαδικασία ανάπτυξης είναι
ΕΠΑΝΑΛΗΠΤΙΚΗ
Περιπτώσεις Χρήσεις –
Περίληψη (1/4)

Οι περιπτώσεις χρήσεις είναι μιά τεχνική γιά την
περιγραφή των λειτουργικών απαιτήσεων ενός
συστήματος από την άποψη του χρήστη

Τα διαγράμματα περιπτώσεων χρήσεις
περιλαμβάνουν χαρακτήρες (actors), περιπτώσεις
χρήσεις καί τις μεταξύ τους συσχετίσεις μέσα στα
όρια του συστήματος που μοντελοποιείται

Ο χαρακτήρας (actor) αναπαριστά ένα ρόλο κάποιας
εξωτερικής οντότητας (π.χ. ενός χρήστη, κάποιου
υλικού, κάποιου άλλου συστήματος, κλπ.) που
αλληλεπιδρά με το σύστημα
Περιπτώσεις Χρήσεις –
Περίληψη (2/4)

Οι χαρακτήρες (actors) ενεργοποιούν καί επικοινωνούν με τις
περιπτώσεις χρήσεις.

Μία περίπτωση χρήσης είναι μία σειρά από ενέργειες που εκτελούνται
γιά να παραχθεί κάποιο χειροπιαστό αποτέλεσμα (που είναι χρήσιμο
γιά κάποιον actor).

Oι χαρακτήρες (actors) καί οι περιπτώσεις χρήσεις είναι γενικές
περιγραφές (όπως οι κλάσεις). Στιγμιότυπα των περιπτώσεων χρήσης
δημιουργούνται όταν εξετάζουμε συγκεκριμένα σενάρια με
συγκεκριμένες τιμές στα δεδομένα, τους actors κλπ.

Ένας χαρακτήρας (actor) συνδέεται με μιά ή περισσότερες περιπτώσεις
χρήσεις.
Περιπτώσεις Χρήσεις –
Περίληψη (3/4)

Καί οι χαρακτήρες (actors) καί οι περιπτώσεις χρήσεις μπορεί να
έχουν συσχετίσεις γενίκευσης/εξειδίκευσης, μέσω των οποίων
κληρονομούν περιγραφή καί συμπεριφορά

Ένα μοντέλο Περίπτωσης Χρήσης μπορεί να περιλαμβάνει ένα ή
περισσότερα διαγράμματα περίπτωσης χρήσης

Οι περιπτώσεις χρήσεις υλοποιούνται με collaborations που
περιλαμβάνουν κλάσεις/αντικείμενα καί συσχετίσεις καθώς καί τη
μεταξύ τους αλληλεπίδραση προκειμένου να παράγουν την
απαιτούμενη λειτουργικότητα.

Ένα collaboration περιγράφεται με διαγράμματα δραστηριοτήτων,
συνεργασίας καί αλληλεπίδρασης (θα αναλυθούν αργότερα)
Περιπτώσεις Χρήσεις –
Περίληψη (4/4)

Κατά την υλοποίηση μιάς περίπτωσεις χρήσης, κάθε βήμα
πρέπει να υλοποιείται από τις μεθόδους κάποιας κλάσης ή
κλάσεων καί την μεταξύ τους αλληλεπίδραση

Ένα σενάριο είναι ένα στιγμιότυπο μιάς περίπτωσης χρήσης ή
μιάς collaboration καί περιγράφει ένα συγκεκριμένο μονοπάτι
εκτέλεσης
– Όταν το σενάριο είναι στιγμιότυπο μιάς περίπτωσης χρήσης, δείχνει
μόνο την αλληλεπίδραση μεταξύ της περίπτωσης χρήσης καί των
εξωτερικών χαρακτήρων (actors)
– Όταν το σενάριο είναι στιγμιότυπο ενός collaboration, δείχνει την
αλληλεπίδραση μεταξύ των κλάσεων/αντικειμένων που υλοποιούν
μιά συγκεκριμένη συμπεριφορά μέσα στο σύστημα
Παράδειγμα - Calendar
Manager CALENDARIUM



Διαχείριση ημερολογίων πολλών χρηστών μέσω του Internet.
Visualisation
– όψεις σε ετήσια, μηνιαία, εβδομαδιαία και ημερήσια βάση
– εισαγωγή/ενημέρωση ραντεβού σε οποιαδήποτε όψη
– highlighting των ημερών με ραντεβού (μόνο σε ετήσια όψη)
Ραντεβού
– απλά και επαναλαμβανόμενα ραντεβού
– δυνατότητα ορισμού διαφορετικών ειδών ραντεβού (προσωπικά,
για δουλειά, με το γιατρό κλπ)
– διαχείριση λίστας “to-do”
– τα ραντεβού μπορούν να αλλάξουν θέση ή είναι σταθερά
Παράδειγμα –
CALENDARIUM (συνέχεια)




Επικοινωνία
– έγκαιρη ενημέρωση όλων όσων συμμετέχουν σε ένα ραντεβού
– προηγούμενη ειδοποίηση για τα ραντεβού
– διαχείριση δικαιωμάτων προσπέλασης
– διαχείριση κοινών ραντεβού
– δυνατότητα αναζήτησης για πιθανά ραντεβού ν συμμετεχόντων
Ορισμός ονοματισμένων ομάδων ατόμων
Εξαγωγή ραντεβού μίας συγκεκριμένης χρονικής περιόδου
– στον εκτυπωτή, σε ένα λογιστικό φύλλο, σε HTML
Διάφορες παράμετροι παρουσίασης που καθορίζονται από το
χρήστη
Use Case Diagram CALENDARIUM
query
appointment
CALENDARIUM
export
appointments
delete
appointment
Χρήστης
Σημ. Ο «χρήστης»
έιναι τύπου
«actor». Έίναι
γενική περιγραφή,
δηλαδή δεν
αναφέρεται σε ένα
συγκεκριμένο
άτομο – περιγράφει
το ρόλο με το
όνομα «χρήστης»
change
appointment
insert
appointment
CALENDARIUM
query entry
Export entries
Χρήστης
Delete entry
Change entry
Insert entry
Update calendar
« include»
Configure program
Notify participants
Administrator
Administer entry type
Administer users
«actor»
Fax-system
«actor»
E-mail system
CALENDARIUM
{abstract}
Insert entry
Χρήστης
Insert appointment
Insert to-do entry
Βιβλιογραφία (1/3)
– “UML Toolkit” by Hans-Erik Eriksson and Magnus
Penker, Wiley Computer Publishing
– “UML Distilled: Applying the Standard Object
Modeling Language” by Martin Fowler, Kendall
Scott and Ivar Jacobson, Addison-Wesley Object
Technology Series
– “Unified Modeling Language User Guide” by Grady
Booch, James Rumbaugh and Ivar Jacobson,
Addison-Wesley Object Technology Series
Βιβλιογραφία (2/3)
– “The Unified Modeling Language Reference Manual” by
James Rumbaugh, Ivar Jacobson and Grady Booch, AddisonWesley Object Technology Series
– “Visual Modeling With Rational Rose and Uml” by Terry
Quatrani, Addison-Wesley Object Technology Series,
Published 1998
– “Visual Modeling with Rational Rose 2000 and UML” by
Terry Quatrani, Addison-Wesley Object Technology Series,
Published 1999
– Kruchten P., Nov. 95, “The 4+1 View Model of
Architecture”, IEEE Software
Βιβλιογραφία (3/3)

UML Resource Centers
– http://www.rational.com/uml
– http://www.sdmagazine.com/uml