Ερώτημα για διαγραμμα περιπτώσης χρησης UML

[xarda]

Υποθέτουμε πως έχουμε το παρακάτω "πρόβλημα" να λύσουμε.

 

Κατασκευάσε ενα λογισμικό με το οποίο θα μπορεί ο διευθυντής της τραπεζας αλλά και ο υπάλληλος ακολουθώντας ακριβώς την ίδια διαδικασία να εισάγουν , διαγράφουν , επεξεργάζονται τα στοιχεία ενός πελάτη.Τα στοιχεία τα οποία θα εισάγωνται στο σύστημα θα ελέγχονται αν υπάρχουν στην βάση δεδομένων και σε περίπτωση που υπάρχουν θα ενημερώνει τον χρήστη.

 

Η ερώτηση μου είναι:

 

1.Ξερω πως πρωτα θα πρέπει να αναγνωρίσουμε τους actors του συστήματος ( δλδ αυτούς που αλληλεπιδρούν ) με το σύστημα.

Ομως παρατηρω στην εκφώνηση οτι το προγραμμα θα μπορεί να το χρησιμοποιει ο διευθυντής αλλα ΚΑΙ ο υπαλληλος με τον ίδιο ακριβώς τρόπο!!!Θα πρέπει στο διάγραμμα μου να δηλώσω σαν ανθρωπάκι ( actor ) και τους δύο; , μόνο τον υπάλληλο ; , μονο τον διευθυντή;.

 

 

2.Επίσης η βάση δεδομένων θα είναι ξεχωριστός actor;

[thanocaster]

1. Θα βαλεις τον έναν σαν generalisation του άλλου (λογικά ο διευθυντής θα είναι generalisation του υπαλλήλου) ή θα φτιάξεις μια superclass 'χρήστης' (πχ) και θα βάλεις και τους δυο σαν generalisation αυτής (αν υπάρχουν κι άλλες σχέσεις actor - use case στο υπόλοιπο της εκφώνησης).

 

2. Όχι.

 

Δες εδώ για μια ωραία επεξήγηση των use case diagrams (και γενικότερα οτιδήποτε πάνω στη uml).

[xarda]

Οκ ευχαριστώ κ για το Link.Φαινεται πως εχει αρκετα πραγματα αναλυτικά.

 

Ομως η db γιατι να μην είναι actor;; Αφού αλληλεπιδρά με το σύστημα , δεχεται και στέλνει "μηνύματα"...

 

 

επίσης...Αν στην παραπάνω εκφώνηση έλεγε για παράδειγμα πως " εμφανίζει μια οθόνη μεσω της οποίας ο υπαλληλος/διευθυντής μπορεί να εισάγει , διαγράψει και επεξεργαστεί.... "

 

τοτε θα έπρεπε η "" εμφάνιση οθόνης "" να είναι και αυτή μέθοδος του use case diagram;;

[x_maras]

Εξαρτάται σε τι επίπεδο σχεδιάζεις. Σε ένα low level diagram που θα σχεδιάσεις και την παραμικρή λεπτομέρια θα πρέπει να τη συμπεριλάβεις ως actor. Σε ένα higher level διαγραμμα (μιλάμε για use case παντα) μπορείς να τη θεωρήσεις ως component του συστήματος.

Θα πρέπει λοιπόν να ξεκαθαρίσεις σε τι επίπεδο θα σχεδιάσεις το use case σου...

 

Προσωπικά όταν γράφω αρχιτεκτονικές είμαι αναλυτικός στα διάφορα σενάρια, αλλά σχεδιάζω μόνο τα high-level (μόνο για τα use case).

 

Επίσης την οθόνη συγκεκριμένα δε την έχω χρησιμοποιήσει ποτέ, αλλά φυσικά θα πρέπει να σχεδιάσεις το input και το output.

[xarda]

Μαθαίνω για τα διαγράμματα και τελικά έχουν ενδιαφέρον!!

 

Υποθέτουμε πως έχουμε την παρακάτω εκφώνηση:

 

 

>
Έχουμε μια αεροπορική εταιρεία. Θέλουμε να φτιάξουμε ένα σύστημα που να καταγράφει σε αρχεία τις απαιτούμενες
πληροφορίες για την εταιρία αυτή.Το σύστημα θα μπορούν να το χρησιμοποιούν με τον ίδιο ακριβώς τρόπο ο διευθυντής της εταιρίας και οι υπάλληλοι.

Οι πληροφορίες αυτές περιλαμβάνουν:

Τα ταξίδια της εταιρίας:
Κάθε ταξίδι θα εμφανίζεται στην οθόνη και θα έχει ένα σημείο εκκίνησης,
ένα σημείο προορισμού και μια χιλιομετρική απόσταση.

Τα αεροσκάφη της:
• Κάθε αεροσκάφος θα εμφανίζεται στην οθόνη και θα έχει ένα κωδικό, όνομα, και το ατομικό του
κόστος συντήρησης.
• Έχουμε δύο τύπους αεροσκαφών: Boeing και Ελικοφόρα.
• Κάθε τύπος αεροσκάφους έχει μια ακτίνα πτήσης, και ένα
στάνταρτ ποσό συντήρησης.
• Επιπλέον κάθε τύπος αεροσκάφους χαρακτηρίζεται και από ένα
bonus ποσό χρημάτων για κάθε πιλότο που είναι διαπιστευμένος
να το πετάει.

 

Παρακάτω εκανα μια προσπάθεια...Πως την βλέπετε;

[x_maras]

Το σχεδιάγραμμα είναι καλό.

3 παρατηρήσεις μόνο που μου ήρθαν μετά από μια γρήγορη ματια στο διαγραμμα και την εκφώνηση.

 

1. Προσωπικά δε θα έβαζα τη βαση σαν actor (αιτιολογώ την αποψή μου στο παραπάνω μου ποστ)

2. Ο Υπ. και π Διευθ. έχουν ακριβώς τις ίδιες δυνατότητες οπότε δε θα τους ανέφερα. Θα κρατούσα μόνο το χρήστη

3. Τα χαρακτηριστικά των αεροσκαφών πιστεύω ότι χωρίς το τύπο του αεροσκάφους δε σημαίνουν τίποτα οπότε θα τα έκανα <<extend>>

 

EDIT

 

υ.γ.

Τα σημεία εκκίνησης και σ. προ. τα εισάγει ο χρήστης ή είναι απλά πληροφορίες που εμφανίζει το σύστημα

[xarda]

υ.γ.

Τα σημεία εκκίνησης και σ. προ. τα εισάγει ο χρήστης ή είναι απλά πληροφορίες που εμφανίζει το σύστημα

 

Τα εισάγει ο χρήστης.

 

Άλλο παράδειγμα:

 

 

Σχεδιάζετε ένα σύστημα παραγγελειοληψίας από σερβιτόρους. Ο σερβιτόρος στο palmtop παίρνει την παραγγελία από

τον πελάτη, και σημειώνει με τη σειρά τα ορεκτικά, το κυρίως πιάτο και το επιδόρπιο. Στο τέλος πατά αποστολή και

στέλνει την παραγγελία στο σεφ. Όταν η παραγγελία είναι έτοιμη ο σεφ στέλνει ειδοποίηση στο palmtop του σερβιτόρου.

Τέλος όταν ο πελάτης θέλει να πληρώσει, ο σερβιτόρος σημειώνει την πληρωμή στον palmtop και κλείνει έτσι την

εξυπηρέτηση του πελάτη. Ποιο είναι το πιο κατάλληλο μοντέλο περιπτώσεων χρήσης για το σύστημα αυτό;

 

 

Εγω το σκέφτηκα κάπως έτσι:

[thanocaster]

Έχε υπ' όψιν πως τα use cases πρέπει να είναι ρήματα. Κοινώς εκεί που λες "παραγγελία" για παράδειγμα στην τελευταία εικόνα, πρέπει να γίνει "καταχώρησε παραγγελία" ή "υπόβαλε παραγγελία" κλπ. Δεν είναι 100% αναγκαίο, αλλά όποιο σοβαρό use case diagram και να δεις, χρησιμοποιούν αυτό το naming convention.

 

Επίσης, ως actors ορίζονται οι παράγοντες εκτός συστήματος που αλληλεπιδρούν με το σύστημά σου. Η βάση δεδομένων σου είναι μέρος του συστήματος, οπότε, κατά τη γνώμη μου, το σωστό είναι να μην είναι actor.

 

Μερικά ακόμα χρήσιμα λινκς:

1. Agile Modelling

2. Tyner Blain: How to write good use case names

Επεξ/σία 25 Μαΐου 2012 από Thanocaster

[Lanike71]

 

Η βάση δεδομένων σου είναι μέρος του συστήματος, οπότε, κατά τη γνώμη μου, το σωστό είναι να μην είναι actor.

 

 

+1 και από μένα.

[x_maras]

Επίσης κάτι που δε σχεδιάζεις στα διαγράμματά σου είναι το παραλληλόγραμμο που συμβολίζει το σύστημά σου. Ίσως γι' αυτό να σε μπερδεύει ο ρόλος της βάσης δεδομένων...

[thanocaster]

Λοιπόν, μιας και είχα λίγο ελεύθερο χρόνο κάθισα και είδα εκφωνήσεις και διαγράμματα. Πέραν, λοιπόν, όσων ήδη ειπώθηκαν, σε κάποιο από τα παραπάνω λινκς που σου παρέθεσα, έχει μια πολύ καλή ρουτίνα για να είναι πιο ευανάγνωστα τα διαγράμματά σου: όταν έχεις μια διαδικασία που ακολουθεί βήματα (όπως πχ στην παραγγελία όπου έχεις 1. επιλογή ορεκτικού -> 2. επιλογή κ.π. -> 3. επιλογή επιδορπίου -> 4. ολοκλήρωση παραγγελίας) καλό είναι να βάζεις τα λογικά βήματα το ένα κάτω από το άλλο. Δηλαδή έχεις τα 1 πάνω πάνω, από κάτω του το 2, από κάτω του το 3 κοκ. Καλό, επίσης, θα είναι να προσπαθείς να μην γίνονται overlap οι γραμμές σχέσεως με τα use cases (όσο αυτό είναι δυνατό).

 

 

Επίσης, μια συμβουλή, να αποφεύγεις να βάζεις βέλη κατεύθυνσης στα relations. Αυτό γιατί τα βέλη κατεύθυνσης υποδηλώνουν τον κύριο actor ενός use case ή κατεύθυνση της κλήσης του use case (δηλαδή σε ποιον αναφέρεται το ρήμα του use case), αλλά πολλοί το μπερδεύουν με την κατεύθυνση των δεδομένων.

 

 

Τέλος, τα use cases βγαίνουν συνήθως από την περιγραφή. Βλέποντας την 2η περιγραφή με τον σερβιτόρο, βλέπω τα εξής ρήματα:

 

 

σερβιτόρος: "παίρνει παραγγελία", "σημειώνει ορεκτικά", "σημειώνει κυρίως πιάτο", "σημειώνει επιδόρπιο", "πατά αποστολή", "στέλνει παραγγελία", "σημειώνη πληρωμή", "κλείνει εξυπηρέτηση"

σεφ: "στέλνει ειδοποίηση"

πελάτης: "πληρώσει"

 

Από αυτά βλέπεις, λοιπόν, πως έχεις 3 actors και καμιά 10αριά use cases. Βλέπεις επίσης πως ο σημαντικότερος actor είναι αναμφισβήτητα ο σερβιτόρος. Οπότε ξεκινάς ζωγραφίζοντας πάνω αριστερά τον actor σερβιτόρος. Το πρώτο ρήμα σου είναι το "παίρνει παραγγελία" το οποίο το κάνεις "Λάβε παραγγελία" (δώσε βάση στο naming convention: η πρώτη λέξη είναι ρήμα που ξεκινάει με κεφαλαίο και ακολουθεί το αντικείμενο, όσο πιο λακωνικά γίνεται, με μικρά γράμματα. Ακολουθούν τα 3 included use cases, το ένα κάτω από το άλλο, και από κάτω το "Στείλε παραγγελία". Σε αυτό το σημείο της εκφώνησης εμφανίζεται ένας ακόμη actor, ο Σεφ. Πας απέναντι, λοιπόν, και ζωγραφίζεις και αυτόν τον actor. Συνεχίζοντας σε αυτό το μοτίβο, θα πρέπει να καταλήξεις σε κάτι τέτοιο:

 

[xarda]

thanks για το παράδειγμα σου!

 

επίσης...

 

Εστω οτι έχουμε το παρακάτω:

 

Φτιάχνετε ένα σύστημα το οποίο θα χρησιμοποιηθεί από έναν υπάλληλο αεροδρομίου. Μία από τις λειτουργίες του συστήματος είναι να επιτρέπει το check-in επιβατών. Η διαδικασία του check-in περιλαμβάνει τη διαδικασία του ζυγίσματος των αποσκευών καθώς και την έκδοση ενός εισιτηρίου για συγκεκριμένη θέση σε συγκεκριμένη πτήση. Η διαδικασία της έκδοσης του εισητηρίου αλλάζει ελαφρά αν πρόκειται για επιβάτη business class. Μια άλλη από τις λειτουργίες του συστήματος είναι η κράτηση. Η διαδικασία της κράτησης περιέχει τις ανεξάρτητες διαδικασίες του ελέγχου για διαθεσιμότητα της πτήσης και τη δημιουργία της κράτησης. Σε περίπτωση που η κράτηση είναι επιτυχής, τα στοιχεία της κράτησης αποστέλλονται στο υποσύστημα χρέωσης.

 

Ποιο διαγραμμα κλάσεων είναι πιο σωστό ;

το imgOne ή το imgTwo ??

[thanocaster]

Βασικά, κατά τη γνώμη μου το 2ο είναι πιο σωστό με 4 λεπτομέρειες:

 

1. Το Business class πρέπει να γίνει όπως στο 1ο διάγραμμα "Έλεγξε τύπο εισητηρίου",

2. Πρέπει να βάλεις ένα note με το extension point (πχ "Extension point: Επιλογή business class"),

3. Τον actor "Υποσύστημα χρέωσης" καλό θα είναι να τον επισημάνεις με την ένδειξη <<σύστημα>> (όπως έχεις τα includes και το extension), και είναι και μια από τις περιπτώσεις (το output προς άλλα συστήματα που βάζω το βελάκι στο relationship - δική μου παράλειψη σε προηγούμενο μήνυμα - εξακολουθεί όμως να μην είναι απαραίτητο) και

4. Το σημαντικότερο απ' όλα είναι να αλλάξεις το "Ολοκλήρωσε κράτηση" από included σε extension. Αυτό γιατί όπως το έχεις τώρα, σημαίνει πως ΠΑΝΤΑ θα ολοκληρώνεται η κράτηση και θα αποστέλλεται στο υποσύστημα χρέωσης. Εσύ όμως θες να μην γίνεται πάντα αυτό, αλλά μόνο όταν "η κράτηση είναι επιτυχής". Άρα, γίνεται extension με extension point "Επιτυχής κράτηση".