Διάλεξη 6:

Χρησιμοποιήστε διαγράμματα περιπτώσεων από κοντά

Λίγα λόγια για τις απαιτήσεις

Ας μιλήσουμε λοιπόν για απαιτήσεις. Τι είναι, καταλαβαίνουμε γενικά - όταν ένας πελάτης μας περιγράφει τι ακριβώς θέλει, ακούμε πάντα φράσεις όπως "Θα ήθελα να ελέγχονται αυτόματα οι ενημερώσεις, όπως στα προγράμματα προστασίας από ιούς", "Θέλω ένα μεγάλο πράσινο κουμπί στο το κέντρο του παραθύρου , το οποίο ξεκινά τη διαδικασία", " πρόγραμμαπρέπει να σας επιτρέπει να βλέπετε και να εκτυπώνετε αναφορές", "και έτσι ώστε όλα να ήταν όμορφα, με ημιδιαφάνειες, όπως στα Vista", "θα πρέπει να εμφανίζεται μια επιβεβαίωση κατά την έξοδο", κ.λπ. κλπ. Φυσικά, ως πραγματικοί προγραμματιστές, καταλαβαίνουμε ότι ότι ο πελάτης ποτέ δεν ξέρει τι ακριβώς χρειάζεται, και αν καταλάβει, δεν μπορεί να εξηγήσει. Μεουσιαστικά το ίδιο! Περιγράφουν πώς φαντάζεται ο πελάτης το σύστημα, τι θέλει ο πελάτης από το σύστημα, τη λειτουργικότητα που περιμένει από αυτό, τις απαιτήσεις που θέτει σε αυτό.

Αν στραφούμε στους κλασικούς, για παράδειγμα, στην ίδια «συμμορία των τριών» (Jacobson, Butch, Rambo), διαπιστώνουμε ότι μια απαίτηση είναι μια επιθυμητή λειτουργικότητα, χαρακτηριστικό ή συμπεριφορά ενός συστήματος. Είναι με τη συλλογή των απαιτήσεων που ξεκινά η διαδικασία ανάπτυξης. ΜΕ. Εάν απεικονίζετε τη διαδικασία ανάπτυξης ΜΕόπως και " μαύρο κουτί" (είμαστε σίγουροι ότι ο αναγνώστης ξέρει τι είναι, αν όχι, η Wikipedia είναι στη διάθεσή σας), στην έξοδο της οποίας παίρνουμε λογισμικό, στη συνέχεια είσοδοςαυτό το "μαύρο κουτί" θα υποβληθεί ακριβώς το σύνολο των απαιτήσεων για το προϊόν λογισμικού (ρύζι. 6.1)!

Ρύζι. 6.1.

Παρεμπιπτόντως, με ποιο διάγραμμα μοιάζει αυτή η εικόνα; Σωστά, διάγραμμα δραστηριότητας. Και η επιλογή αυτού του διαγράμματος εδώ είναι απολύτως δικαιολογημένη - θυμηθείτε, το είπαμε διαγράμματα δραστηριότηταςχρησιμοποιείται συχνά για να περιγράψει επιχειρηματικές διαδικασίες; Η μόνη προειδοποίηση: συνήθως η διαδικασία ανάπτυξης δεν τελειώνει με την κυκλοφορία ενός προϊόντος λογισμικού - έρχεται ένα νέο επανάληψη, νέες, εκλεπτυσμένες απαιτήσεις, μια νέα έκδοσηκαι τα λοιπά.

Με την ευκαιρία, πίσω στις απαιτήσεις. Ναι, είπαμε ότι η είσοδος του «μαύρου κουτιού» μας είναι ένα σύνολο απαιτήσεων. Με ποια μορφή όμως; Πώς τεκμηριώνονται, αυτές οι απαιτήσεις; Νομίζω ότι οι περισσότεροι αναγνώστες θυμούνται τι τεχνικό έργο- το κύριο έγγραφο, χωρίς το οποίο κανένα έργο δεν ξεκίνησε στη σοβιετική εποχή. Αυτό το έγγραφο ήταν μεγάλο, πολυσέλιδο, με σαφή δομή που καθορίζεται από GOST (κρατικά πρότυπα βιομηχανίας). Και περιέγραψε Μεστην πραγματικότητα, τίποτα περισσότερο από τις απαιτήσεις για το σύστημα που δημιουργείται!

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

· διαγράμματα περιπτώσεων χρήσης ;

· μη λειτουργικές απαιτήσεις.

Χρησιμοποιήστε Διαγράμματα περίπτωσης απαρτίζω μοντέλο προηγούμενου(περιπτώσεις χρήσης, περιπτώσεις χρήσης). Προηγούμενο- αυτή είναι η λειτουργικότητα του συστήματος που επιτρέπει στον χρήστη να έχει κάποιο ουσιαστικό, απτό και μετρήσιμο αποτέλεσμα για αυτόν. Κάθε προηγούμενοαντιστοιχεί σε μια ενιαία υπηρεσία που παρέχεται από το προσομοιωμένο σύστημα ως απόκριση σε αίτησηχρήστη, δηλαδή καθορίζει πώς θα χρησιμοποιηθεί το σύστημα. Ακριβώς ΜεΓια το λόγο αυτό, οι περιπτώσεις χρήσης ή τα προηγούμενα εμφανίζονται συχνά στη ρωσική ορολογία ως περιπτώσεις χρήσης. Οι περιπτώσεις χρήσης χρησιμοποιούνται συχνότερα για τον καθορισμό εξωτερικών απαιτήσεων για ένα σύστημα που σχεδιάζεται ή για τον καθορισμό της λειτουργικής συμπεριφοράς ήδη υπάρχον σύστημα. Επιπλέον, οι περιπτώσεις χρήσης περιγράφουν έμμεσα τους τυπικούς τρόπους με τους οποίους ένας χρήστης αλληλεπιδρά με το σύστημα, επιτρέποντάς του να συνεργαστεί σωστά με τις υπηρεσίες που παρέχει το σύστημα.

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

Ρύζι. 6.2.

Αλλά πίσω στα προηγούμενα (υποθέσεις χρήσης). Είναι ευθύνη του αναλυτή συστημάτων να προσδιορίσει περιπτώσεις χρήσης και φορείς. Και το κάνει αυτό για να:

· ξεκάθαρη διάκριση μεταξύ του συστήματος και του περιβάλλοντος του·

· να καθορίσει ποιοι παράγοντες και πώς ακριβώς αλληλεπιδρούν με το σύστημα, ποια λειτουργικότητα (περιπτώσεις χρήσης) αναμένεται από το σύστημα.

· ορίστε και περιγράψτε σε ένα λεξικό τομέα (γλωσσάρι) γενικές έννοιες, τα οποία είναι απαραίτητα για μια λεπτομερή περιγραφή της λειτουργικότητας του συστήματος (περιπτώσεις χρήσης).

Αυτός ο τύπος δραστηριότητας εκτελείται συνήθως με την ακόλουθη σειρά:

1. Ορισμός ηθοποιών.

2. Ορισμός προηγούμενων.

3. Γράψτε μια περιγραφή για κάθε περίπτωση.

4. Περιγραφή του μοντέλου περίπτωσης χρήσης στο σύνολό του (αυτό το στάδιο περιλαμβάνει τη δημιουργία ενός λεξικού τομέα).

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

Εξετάστε ένα παράδειγμα. Η γραμματέας φιλοξενεί στον διακομιστή μενούδείπνο για την εβδομάδα. Οι εργαζόμενοι θα πρέπει να έχουν πρόσβαση μενούκαι κάντε μια παραγγελία επιλέγοντας πιάτα για κάθε μέρα της επόμενης εβδομάδας. Γραφείο- ο διαχειριστής θα πρέπει να μπορεί να δημιουργήσει ένα τιμολόγιο και να το πληρώσει. Το σύστημα πρέπει να είναι γραμμένο ΑΣΠΙΔΑ..ΚΑΘΑΡΑ. Τέτοιο είναι το απλό Διαδίκτυο εφαρμογήγια την αυτοματοποίηση των παραγγελιών μεσημεριανού γεύματος γραφείο.

Νομίζουμε ότι όλα είναι ξεκάθαρα εδώ. Τραπέζιμε μια περιγραφή των απαιτήσεων μπορεί να είναι, για παράδειγμα, αυτό:

Προηγούμενο	Ηθοποιός
μενού θέσεων	γραμματέας Η κατεύθυνση της σχέσης είναι πάντα από τη γεννήτρια προς τη γενικευμένη. Παρακάτω είναι ένα διάγραμμα με ένα σενάριο παρόμοιο με το παραπάνω, που απεικονίζει τη σχέση. Στο διάγραμμα, έχουμε τέσσερις περιπτώσεις χρήσης και τρεις διαφορετικές σχέσεις: συμπερίληψη, επέκταση και γενίκευση. Η περίπτωση χρήσης "Αίτηση υλικού" περιλαμβάνει την περίπτωση χρήσης "Έλεγχος αποθέματος". Αυτό οφείλεται στο γεγονός ότι όποτε υπάρχει ένα αίτημα υλικού, θα υπάρχει πάντα ένα αίτημα περίληψης για να δούμε εάν το υλικό είναι διαθέσιμο. Εάν υπάρξει ποτέ, θα συμπεριληφθεί η σωστή σχέση.
δείτε το μενού
κάντε μια παραγγελία	υπάλληλος, γραμματέας, διευθυντής γραφείου
δημιουργία λογαριασμού	Διευθυντής γραφείου
πληρώνω το λογαριασμό Η περίπτωση χρήσης υλικού Αγορά επεκτείνει τη χρήση της περίπτωσης χρήσης Αίτημα υλικού. Αυτό οφείλεται στο γεγονός ότι όταν ζητείται ένα υλικό, εάν το υλικό έχει εξαντληθεί, μπορεί να σας ζητηθεί να αγοράσετε το αντικείμενο. Ωστόσο, ενδέχεται να μην σας ζητηθεί να αγοράσετε, καθώς το προϊόν μπορεί να είναι εκτός αποθέματος. Εάν μπορεί να ζητηθεί μια αγορά, μια έγκυρη σχέση αποτελεί επέκταση. Η περίπτωση χρήσης υλικού Αγοράς συνοψίζει την περίπτωση χρήσης Εντολής Αγοράς. Έτσι, δεν δικαιολογείται η αντιγραφή της αντίστοιχης προδιαγραφής σε άλλη περίπτωση χρήσης, αρκεί να επαναλάβουμε αυτό που είναι ήδη έτοιμο, αλλά γενικευμένο σε τέτοιο βαθμό ώστε να μπορεί να χρησιμοποιηθεί από αυτόν που το εξειδικεύει.	Διευθυντής γραφείου

Πουθενά δεν λέει ότι το σύστημα πρέπει να είναι γραμμένο ΑΣΠΙΔΑ..ΚΑΘΑΡΑ. Γιατί - είναι ξεκάθαρο: είναι μια μη λειτουργική απαίτηση! Κι όμως, είναι προφανές ότι ο γραμματέας και γραφείο- Διευθυντής είναι και οι εργαζόμενοι. Ο αναγνώστης, που έχει διαβάσει προσεκτικά τις προηγούμενες διαλέξεις, θα υποψιαστεί ότι σε αυτή την περίπτωση, δημιουργώντας ένα μοντέλο προηγούμενων, μιλώντας για ηθοποιούς, θα μπορούσε κανείς να εφαρμόσει γενίκευση. Πραγματικά, διάγραμμα περίπτωσης χρήσης, που χτίστηκε με βάση αυτόν τον πίνακα, μπορεί να είναι, για παράδειγμα, όπως (ρύζι. 6.3):

Ρύζι. 6.3.

Χρησιμοποιήστε διαγράμματα περιπτώσεων και τη σημειογραφία τους

Λοιπόν, έχουμε ένα παράδειγμα γραφήματος. Λοιπόν, ποια στοιχεία βλέπουμε σε αυτό; Το πρώτο πράγμα που σου τραβάει την προσοχή είναι το μεγάλο ορθογώνιο παραλληλόγραμμο, μέσα στο οποίο τοποθετούνται ελλείψεις, που δηλώνουν, όπως έχουμε ήδη καταλάβει, προηγούμενα. Το όνομα του προσομοιωμένου συστήματος υποδεικνύεται στο πάνω μέρος του ορθογωνίου και ονομάζεται Σύστημα (Σύστημα Όριο, θέμα Όριο),συμφραζόμεναή απλά Σύστημα. Αυτό το στοιχείο του διαγράμματος δείχνει το όριο μεταξύ αυτού που σας αρέσει αναλυτήςπαρουσιάζονται με τη μορφή προηγούμενων (μέσα σε αυτά τα πλαίσια) και αυτό που απεικονίζατε ως ηθοποιοί (εκτός αυτών). Τις περισσότερες φορές, ένα τέτοιο ορθογώνιο δείχνει τα όρια του συστήματος που μοντελοποιείται. Δηλαδή, μέσα στο όριο υπάρχουν προηγούμενα - η λειτουργικότητα που εφαρμόζει το σύστημα (και υπό αυτή την έννοια, τα προηγούμενα μπορούν να θεωρηθούν ως αναπαραστάσεις υποσυστημάτων και κλάσεων του μοντέλου) και έξω - χαρακτήρες: χρήστες και άλλοι εξωτερικές οντότητεςαλληλεπίδραση με το προσομοιωμένο σύστημα.

Θα πρέπει να ειπωθεί ότι το πλαίσιο του συστήματος σπάνια απεικονίζεται σε διαγράμματα περιπτώσεων χρήσης, καθώς υπονοούνται σιωπηρά από το ίδιο το διάγραμμα. ΜεΣτην πραγματικότητα, αυτό το στοιχείο δεν προσθέτει καμία επιπλέον σημαντική πληροφορία στο διάγραμμα, επομένως η χρήση του είναι θέμα γούστου του αναλυτή. Η εμφάνιση του εύρους του συστήματος στο διάγραμμα περίπτωσης χρήσης υπαγορεύεται τις περισσότερες φορές από τις ιδιαιτερότητες του προσωπικού στυλ σχεδιασμού.

Εκτός από το πλαίσιο του συστήματος ή το πλαίσιο του στο διάγραμμα, βλέπουμε δύο ακόμη τύπους οντοτήτων που σχετίζονται με αυτό - αυτοί είναι χαρακτήρες(ηθοποιοί) και προηγούμενα. Ας ξεκινήσουμε από τους ηθοποιούς. Αρκετά συχνά στη ρωσόφωνη λογοτεχνία Με UMLγια να ορίσετε ηθοποιούς, μπορείτε να βρείτε τον όρο " ηθοποιόςΚατ' αρχήν, το νόημά του είναι λίγο πολύ ξεκάθαρο στο πρωτότυπο Αγγλικός όροςείναι σύμφωνο. Επιπλέον, υπάρχει και άλλος λόγος για μια τέτοια μεταγραφή. Οι οποίες λέξητο πρώτο πράγμα που σου έρχεται στο μυαλό όταν ακούς λέξη "ηθοποιός"? Ναι φυσικά - λέξη"ρόλος"! Πρόκειται για ρόλους για τους οποίους θα μιλήσουμε σύντομα όταν προσπαθήσουμε να καταλάβουμε τι κρύβεται πίσω από την έννοια του «ηθοποιού». Στο μεταξύ, συγχωρέστε τον αναγνώστη, θα συνεχίσουμε να χρησιμοποιούμε τη λέξη "έκτορας" - μια μεταγραφή του αρχικού όρου. Θυμάμαι ότι είχαμε ήδη γράψει για τη στάση μας στην κυριολεκτική μετάφραση της ορολογίας...

Λοιπόν, ποια είναι η έννοια της έννοιας του ector; Έκτοραςείναι ένα σύνολο ρόλων που χρήστηςκατά τη διάρκεια της αλληλεπίδρασης με κάποια οντότητα (σύστημα, υποσύστημα, τάξη). Ένας ηθοποιός μπορεί να είναι ένα άτομο, ένα άλλο σύστημα, ένα υποσύστημα ή μια τάξη που αντιπροσωπεύει κάτι έξω από την εν λόγω οντότητα. Οι ηθοποιοί «επικοινωνούν» με το σύστημα ανταλλάσσοντας μηνύματα. Προσδιορίζοντας με σαφήνεια τους φορείς, ορίζετε με σαφήνεια το όριο μεταξύ αυτού που βρίσκεται μέσα στο σύστημα και αυτού που βρίσκεται έξω - το πλαίσιο του συστήματος.

Ίσως οι λέξεις "ρόλοι που έπαιξε ο χρήστης" στον ορισμό του εκτελεστή να μην ακούγονται πολύ σαφείς. Πολύ αστείο αυτή η έννοια εξηγείται στο Zicom Mentor:

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

Πράγματι, βάλε ένα πειρατικό καπέλο και είσαι ο Captain Jack Sparrow, και βάλε ένα top hat και είσαι ο Jack the Ripper! Ανέκδοτο... "Φυσικό" χρήστηςμπορεί να παίξει το ρόλο ενός ή και περισσότερων παραγόντων, εκτελώντας τις λειτουργίες τους κατά τη διάρκεια της αλληλεπίδρασης με το σύστημα. Αντίθετα, ο ρόλος του ίδιου ηθοποιού μπορεί να εκτελεστεί από πολλούς χρήστες.

Στα διαγράμματα UMLΟι ηθοποιοί απεικονίζονται ως στυλιζαρισμένοι άντρες, γιατί, όπως φυσικά θυμάστε, η ιδέα ήταν να δημιουργηθεί μια σημειογραφία, κάθε σύμβολο της οποίας μπορεί εύκολα να σχεδιαστεί με το χέρι (ρύζι. 6.4):

Ρύζι. 6.4.

Παρά την «ανθρώπινη» εμφάνιση αυτού του χαρακτηρισμού, δεν πρέπει να ξεχνάμε ότι οι ηθοποιοί δεν είναι απαραίτητα άνθρωποι. Ένας ηθοποιός, όπως είπαμε νωρίτερα, μπορεί να είναι ένα εξωτερικό σύστημα, υποσύστημα, Τάξηκλπ. Με την ευκαιρία, ανθρωπάκι ("κολλητό άτομο" ) δεν είναι ο μόνος συμβολισμός ector που χρησιμοποιείται σε UML. Στα διαγράμματα περίπτωσης χρήσης, συνήθως χρησιμοποιείται η «ανθρωποειδής» μορφή του εκτοξευτή, αλλά σε άλλα διαγράμματα, και ειδικά σε περιπτώσεις που ο ηθοποιός έχει ιδιότητες, που είναι σημαντικό να δείξουμε, χρησιμοποιείται η εικόνα του έκτορα ως τάξης με στερεότυπο<> (εικ. 6.5):

Ρύζι. 6.5.

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

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

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

Οι περιπτώσεις χρήσης εμφανίζονται με τη μορφή έλλειψης, μέσα στο περίγραμμα της οποίας τοποθετείται το όνομα (περιγραφή) της περίπτωσης χρήσης. Το όνομα της περίπτωσης χρήσης είναι συνήθως πολύ μεγαλύτερο από τα ονόματα άλλων στοιχείων του μοντέλου. Το γιατί συμβαίνει αυτό, κατ' αρχήν, είναι σαφές: το όνομα του προηγούμενου περιγράφει την αλληλεπίδραση του ηθοποιού με το σύστημα, λέει ποια μηνύματα ανταλλάσσουν μεταξύ τους. Στο παράδειγμά μας για την παραγγελία δείπνων, έχουμε δει αρκετές περιπτώσεις χρήσης και ο αναγνώστης πιθανότατα θα παρατηρήσει ότι το όνομα της περίπτωσης χρήσης είναι μάλλον το όνομα του σεναρίου που αναπαράγεται κατά την αλληλεπίδραση του ηθοποιού με το σύστημα. Και είναι πάντα μια περιγραφή. από τη σκοπιά ενός ηθοποιού, περιγραφή των υπηρεσιών που παρέχει το σύστημα στον χρήστη. Ας δώσουμε ένα παράδειγμα του απλούστερου διαγράμματος που επεξηγεί αυτό που είπαμε για τη σημειογραφία προηγουμένου (ρύζι. 6.6).

Ρύζι. 6.6.

Σε αυτό το παράδειγμα, ένας επιβάτης μπορεί να αγοράσει ένα εισιτήριο για ένα συγκεκριμένο είδος μεταφοράς σε ένα ταμείο εξυπηρέτησης. Αγορά εισιτηρίου είναι το όνομα του σεναρίου, Μεπου ο ηθοποιός (επιβάτης) μπορεί να αλληλεπιδράσει με το σύστημα (ταμείο). Σημειώστε ότι αυτό Χωρίς περιγραφήσενάριο, δηλαδή ο τίτλος - μας λέει Τικάνει έναν ηθοποιό στη διαδικασία της αλληλεπίδρασης, αλλά δεν λέει ακριβώς πώς! Και όμως - τα προηγούμενα ορίζουν κομματιάζωσενάρια συμπεριφοράς. Η εκτέλεση μιας περίπτωσης χρήσης δεν μπορεί να διακοπεί από άλλη περίπτωση χρήσης. Με άλλα λόγια, η εκτέλεση μιας περίπτωσης χρήσης δεν μπορεί να διακοπεί από γεγονότα ή ενέργειες που προκαλούνται από την εκτέλεση μιας άλλης περίπτωσης χρήσης. προηγούμενα εμφανίζονται ως ατομικές συναλλαγές, του οποίου η εκτέλεση δεν μπορεί να διακοπεί.

Ο προσεκτικός αναγνώστης μπορεί να παρατήρησε πόσο ανεπαίσθητα έχουμε εισαγάγει λέξη " σενάριο". Τι είναι σενάριοκαι πώς συνδέεται η έννοια του σεναρίου με την έννοια του προηγούμενου; Οι κλασικοί απαντούν καλά στην πρώτη ερώτηση (G. Butch):

Ένα σενάριο είναι μια συγκεκριμένη ακολουθία ενεργειών που απεικονίζει τη συμπεριφορά.

Σενάριο- πρόκειται για μια αφηγηματική ιστορία για τις ενέργειες που εκτελεί ο ηθοποιός, μια ιστορία, ένα επεισόδιο που διαδραματίζεται σε ένα δεδομένο χρονικό πλαίσιο και ένα δεδομένο πλαίσιο αλληλεπίδρασης. Τα σενάρια (σε διάφορες μορφές) χρησιμοποιούνται ευρέως στη διαδικασία ανάπτυξης λογισμικού. Όπως μόλις σημειώσαμε, η συγγραφή ενός σεναρίου είναι σαν να γράφεις μια φανταστική ιστορία, και αυτό εξηγεί γιατί η χρήση σεναρίων είναι ευρέως διαδεδομένη μεταξύ των αναλυτών, οι οποίοι συχνά έχουν καλλιτεχνικές ή λογοτεχνικές ικανότητες. Παρά τη συνεχή αφηγηματική τους φύση, τα σενάρια μπορούν να θεωρηθούν ως αλληλουχίες ενεργειών (do σενάριο). Κατά το σχεδιασμό μιας διεπαφής χρήστη, τα σενάρια περιγράφουν την αλληλεπίδραση μεταξύ ενός χρήστη (ή μιας κατηγορίας χρηστών, όπως οι διαχειριστές συστήματος, οι τελικοί χρήστες) και το σύστημα. Τέτοιος σενάριοαποτελείται από μια διαδοχική περιγραφή συνδυασμών μεμονωμένων ενεργειών και εργασιών (για παράδειγμα, πληκτρολογήσεις, κλικ Μεστοιχεία ελέγχου, εισαγωγή δεδομένων στα αντίστοιχα πεδία κ.λπ.). Θυμηθείτε, για παράδειγμα, περιγραφές ακολουθιών ενεργειών χρήστη (που έχουν σχεδιαστεί για την επίτευξη συγκεκριμένων αποτελεσμάτων, την επίλυση συγκεκριμένων εργασιών) που βρίσκετε στη βοήθεια για ένα άγνωστο πρόγραμμα. Το ίδιο μπορεί να ειπωθεί και για τα μοντέρνα πλέον «πώς να βίντεο», στα οποία τέτοιες σεκάνς εμφανίζονται οπτικά, με συγκεκριμένα παραδείγματα. Σε κάθε περίπτωση, σκοπός τέτοιων υλικών αναφοράς είναι να παρέχουν μια περιγραφή τυπικών σεναρίων για τη χρήση του συστήματος, σεναρίων αλληλεπίδρασης μεταξύ του χρήστη και του συστήματος.

Τα σενάρια μπορούν επίσης μερικές φορές να φανούν σε ένα διάγραμμα περίπτωσης χρήσης. Μερικές φορές απεικονίζονται ως φύλλο χαρτιού"πάνω στο οποίο είναι γραμμένο όνομα αρχείου, - ένα ορθογώνιο με διπλωμένη κάτω αριστερή γωνία. Στην περίπτωση αυτή, τα καθορισμένα αρχείοπεριέχει μια περιγραφή αυτού του σεναρίου. Και μερικές φορές σενάριογραμμένο σε σχόλιο. Όπως ίσως θυμάστε, τα σχόλια (σημειώσεις, σημειώσεις) απεικονίζονται ως ορθογώνια με κυρτή πάνω δεξιά γωνία και συνδέονται με το στοιχείο που εξηγούν με μια διακεκομμένη γραμμή (ρύζι. 6.7).

Ρύζι. 6.7.

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

Ακολουθεί ένα παράδειγμα απλής (μη επισημοποιημένης) κειμενικής περιγραφής του σεναρίου.

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

Δεν είναι μια γνωστή διαδικασία; Ναι, αυτή είναι μια περιγραφή της εγγραφής χρήστη σε κάποια τοποθεσία. Αληθινή, όχι εντελώς πλήρης: οι περιπτώσεις κατά τις οποίες η σύνδεση που έχει επιλέξει ο χρήστης έχει ήδη ληφθεί δεν λαμβάνονται υπόψη, διεύθυνση email που έχει εισαχθεί λανθασμένα Κωδικός πρόσβασηςδεν πληροί τις απαιτήσεις ή ο κωδικός δεν ταιριάζει με αυτόν που φαίνεται στην εικόνα. Σχετικά με τέτοιες περιπτώσεις εναλλακτικά σενάρια- Θα τα πούμε λίγο αργότερα.

Και εδώ είναι το ίδιο σενάριοσε προβολή πίνακα:

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

Εν τω μεταξύ, ας προσπαθήσουμε να απαντήσουμε στο δεύτερο ερώτημα, δηλαδή: Πώς συνδέονται οι έννοιες του σεναρίου και της περίπτωσης χρήσης;. Οι περιπτώσεις χρήσης, όπως έχουμε ήδη πει, γεννιούνται από τις απαιτήσεις του συστήματος. Αλλά μιλούν για το τι κάνει το σύστημα. Πώς το κάνει το σύστημα, λένε τα σενάρια. Ετσι, προηγούμενομπορεί να προσδιοριστεί περιγράφοντας τη ροή των ενεργειών ή των γεγονότων σε κειμενική μορφή - σε μια μορφή κατανοητή από έναν «αουτσάιντερ» (που δεν εμπλέκεται στην άμεση ανάπτυξη του συστήματος) αναγνώστη. Αλλά μια τέτοια περιγραφή είναι σενάριο! Ετσι, Τα σενάρια καθορίζουν περιπτώσεις χρήσης. Και επιπλέον. Γιατί τα σενάρια είναι ΜεΣτην ουσία, οι ιστορίες είναι ένα πολύ αποτελεσματικό μέσο εξαγωγής πληροφοριών από συνομιλίες με τον πελάτη και παρέχουν μια εξαιρετική, φιλική προς τον χρήστη περιγραφή της εφαρμογής που δημιουργείται. Σενάρια, και μάλιστα διαγράμματα περιπτώσεων χρήσης(συμπληρωμένα με σενάρια) είναι υπέροχα μέσα επικοινωνίας μεταξύ προγραμματιστών και πελάτη, και, λόγω της απλότητας της σημειογραφίας, με τρόπο κατανοητό και από τα δύο μέρη. Τελικά, η σχέση μεταξύ απαιτήσεων, περιπτώσεων χρήσης και σεναρίων μπορεί να αναπαρασταθεί από ένα τέτοιο «ψευδοδιάγραμμα» (ρύζι. 6.8).

Ρύζι. 6.8.

Όπως μπορείτε να δείτε, για κάθε συσχέτιση, φαίνεται το διάγραμμα πολλαπλότητακαι το νόημά του είναι αρκετά σαφές, αλλά παρόλα αυτά, η πολλαπλότητα θα πρέπει να συζητηθεί χωριστά. Ενας προηγούμενοορίζει πολλά σενάρια, καθένα από τα οποία αντιπροσωπεύει μία από τις πιθανές παραλλαγές της ροής των γεγονότων που ορίζεται από το προηγούμενο. Τα σενάρια σχετίζονται με περιπτώσεις χρήσης με τον ίδιο τρόπο όπως οι περιπτώσεις μιας κλάσης, π.χ. Το σενάριο είναι ένα παράδειγμα μιας περίπτωσης χρήσης, Πως ένα αντικείμενο- παράδειγμα τάξης. Το σύστημα μπορεί να περιέχει, για παράδειγμα, πολλές δεκάδες περιπτώσεις, καθεμία από τις οποίες, με τη δική της Ουρά, μπορεί να εκτυλιχθεί σε δεκάδες σενάρια. Συνήθως, προηγούμενοπεριγράφει όχι μία ακολουθία ενεργειών, αλλά πολλές, και είναι συνήθως αδύνατο να εκφραστούν όλες οι λεπτομέρειες του προηγουμένου που εξετάζουμε με τη βοήθεια μιας ακολουθίας ενεργειών. Για σχεδόν οποιοδήποτε προηγούμενο, μπορεί κανείς να ξεχωρίσει το κύριο σενάριο, που περιγράφει την «κανονική» ακολουθία δράσης, και βοηθητικήπεριγράφοντας εναλλακτική λύσηαλληλουχίες που ενεργοποιούνται όταν συμβαίνουν ορισμένες συνθήκες.

Ένα άλλο ερώτημα είναι εάν απαιτείται μια τέτοια βελτίωση του προηγουμένου μοντέλου, εάν δικαιολογείται για ένα δεδομένο επίπεδο προσέγγισης ή "υποδηλώνεται" εναλλακτική λύσητα σενάρια μπορούν να παραληφθούν; Για παράδειγμα, στο προηγούμενο παράδειγμα με την αγορά εισιτηρίου σε ταμείο εξυπηρέτησης, δεν απεικονίσαμε σενάρια (και, κατά συνέπεια, προηγούμενα) που να αντιστοιχούν στις επιλογές όταν δεν έχουν απομείνει άλλα εισιτήρια για την πτήση που έχει επιλέξει ο επιβάτης, ο επιβάτης άλλαξε γνώμη και θέλει να πάρει εισιτήριο για άλλη πτήση, όταν πληρωμήπηγαίνει σε μετρητά ή Μεπιστωτική κάρτα κ.λπ.

"Σταμάτα να χτυπάς γύρω από τον θάμνο!" - θα αναφωνήσει ο ανυπόμονος αναγνώστης. Ήδη τελειώνουμε. Θέλαμε απλώς να οδηγήσουμε απαλά τον αναγνώστη στο ζήτημα των σχέσεων μεταξύ των περιπτώσεων χρήσης. Και αυτές οι σχέσεις είναι πολύ διαφορετικές. Ας ξεκινήσουμε με έναν παλιό φίλο - σχέσεις γενίκευσης (κληρονομικότητα, γενίκευση). Έχουμε ήδη μιλήσει για γενίκευση περισσότερες από μία φορές όταν σκεφτήκαμε διαγράμματα τάξης. Ωστόσο, ας θυμηθούμε την ουσία αυτής της έννοιας. Όπως λένε οι κλασικοί γενίκευση- Αυτό στάσηεξειδίκευση (γενίκευση), στην οποία τα αντικείμενα ενός εξειδικευμένου στοιχείου (παιδί) μπορούν να αντικατασταθούν από αντικείμενα ενός γενικευμένου στοιχείου (γονέας ή πρόγονος).

Με τον ίδιο τρόπο που κάνουμε συνήθως με τις τάξεις, αφού έχουμε εντοπίσει και περιγράψει την καθεμία προηγούμενο, πρέπει να τις εξετάσουμε όλες για την παρουσία των ίδιων ενεργειών - για να δούμε, και αν κάποιες ενέργειες εκτελούνται (χρησιμοποιούνται) από κοινού από πολλές περιπτώσεις χρήσης. Αυτό το κοινόχρηστο τμήμα περιγράφεται καλύτερα σε ξεχωριστή περίπτωση χρήσης. Έτσι θα μειώσουμε πλεονασμόςμοντέλα μέσω της χρήσης της γενίκευσης των προηγούμενων (μερικές φορές, ωστόσο, δεν μιλούν για γενίκευση, αλλά για χρήσηπροηγούμενα? γιατί - τώρα θα καταλάβετε). Όπως «υποτίθεται» στην κληρονομικότητα, οι περιπτώσεις γενικευμένων προηγούμενων (παιδιά) διατηρούν τη συμπεριφορά που είναι εγγενής στο γενικευμένο προηγούμενο (πρόγονος). Με άλλα λόγια, η παρουσία (χρήση) στην περίπτωση χρήσηςΧ περίπτωση γενικής χρήσηςΥ μας λέει ότι το προηγούμενο παράδειγμαΧ περιλαμβάνειπροηγούμενη συμπεριφοράΥ . Τα γενόσημα χρησιμοποιούνται για να γίνει πιο κατανοητό το μοντέλο περίπτωσης χρήσης, χρησιμοποιώντας επανειλημμένα "γεμισμένες" θήκες χρήσης για να δημιουργήσετε τις περιπτώσεις χρήσης που θέλει ο πελάτης (θυμηθείτε πώς συζητήσαμε εάν πρέπει πάντα να δημιουργείτε μια νέα). Τάξη, ή είναι καλύτερα να χρησιμοποιήσουμε μια έτοιμη λύση, νιώθετε την αναλογία;). Τέτοιες «πλήρες» περιπτώσεις λέγονται συγκεκριμένα προηγούμενα. Τα «κενά» περιπτώσεων χρήσης, που δημιουργούνται μόνο για επαναλαμβανόμενη χρήση σε άλλες περιπτώσεις χρήσης, ονομάζονται περιπτώσεις αφηρημένης χρήσης. Αφηρημένη προηγούμενο(αρέσει αφηρημένη τάξη) δεν υπάρχει η ίδια Μεη ίδια, αλλά ένα παράδειγμα μιας συγκεκριμένης περίπτωσης χρήσης παρουσιάζει τη συμπεριφορά που περιγράφεται από τις περιπτώσεις αφηρημένης χρήσης που (επανα)χρησιμοποιεί. Προηγούμενο, το οποίο παρατηρούν οι ηθοποιοί όταν αλληλεπιδρούν με το σύστημα ("πλήρες" προηγούμενο, όπως το λέγαμε πριν), που συχνά αναφέρεται ως " πραγματικός"Προηγούμενο.

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

απεικονίζεται γενίκευση, όπως θυμάται φυσικά ο προσεκτικός αναγνώστης, μια γραμμή με ένα «απλήρωτο» τριγωνικό βέλος στο τέλος. Γενίκευση- Αυτό στάσηανάμεσα σε έναν πρόγονο και έναν απόγονο, και το βέλος δείχνει πάντα τον πρόγονο. Αν θυμηθούμε ότι οι απόγονοι κληρονομούν (χρησιμοποιούν) τις ιδιότητες του προγόνου, τότε είναι πολύ λογικό να θυμηθούμε τη δήλωσή μας ότι τα βέλη στο UMLπάντα απευθύνεται σε αυτόν από τον οποίο απαιτείται κάτι, του οποίου χρησιμοποιούνται οι υπηρεσίες (ρύζι. 6.9):

Ρύζι. 6.9.

Όπως είπαμε νωρίτερα και είδαμε στο πρώτο μας παράδειγμα διαγράμματα περιπτώσεων χρήσης, γενίκευσημπορεί να χρησιμοποιηθεί για τη δημιουργία διαφορετικών τύπων ηθοποιών. Οι απόγονοι ηθοποιοί κληρονομούν βασικά χαρακτηριστικά από τον πρόγονο και τα συμπληρώνουν με τις δικές τους ιδιαιτερότητες. Παρόμοιος προηγούμενο-απόγονοςκληρονομεί τη συμπεριφορά και τη σημασιολογία της περίπτωσης γονικής χρήσης και συμπληρώνει τη συμπεριφορά της.

Το επόμενο είδος σχέσης μεταξύ των περιπτώσεων χρήσης είναι η συμπερίληψη. Στάσησυμπερίληψη σημαίνει ότι σε κάποιο σημείο της βασικής περίπτωσης χρήσης περιέχει τη συμπεριφορά μιας άλλης περίπτωσης χρήσης. περιλαμβάνεται προηγούμενοδεν υπάρχει από μόνη της Μεη ίδια, αλλά αποτελεί μόνο μέρος του εγκληματικού προηγούμενου. Η βάση λοιπόν προηγούμενοσαν να δανείζεται τη συμπεριφορά των περιλαμβανόμενων, αποσυντίθεται σε απλούστερα προηγούμενα. Για παράδειγμα, όταν αγοράζουμε ένα συγκεκριμένο είδος σε ένα κατάστημα, η κατάσταση ενημερώνεται τη στιγμή που ο ταμίας διαβάζει τον γραμμωτό κώδικα. Βάση δεδομένωναγαθά σε απόθεμα - ο αριθμός των μονάδων μετρητών των αγορασθέντων αγαθών μειώνεται. Η ίδια ενέργεια εκτελείται εάν η αγορά προϊόναποδείχθηκε ελαττωματικό, άχρηστο ή απλά δεν μας άρεσε: η κατάσταση του αναφερόμενου Βάση δεδομένωνενημερώθηκε ξανά - αλλά τώρα προς την κατεύθυνση της αύξησης του αριθμού των ταμειακών μονάδων ενός συγκεκριμένου προϊόντος. Δηλαδή, και οι δύο αυτές ενέργειες - τόσο η αγορά όσο και η επιστροφή - περιέχουν (περιλαμβάνουν) μια τέτοια ενέργεια όπως η ενημέρωση του περιεχομένου DB.

Πώς όμως απεικονίζεται η συμπερίληψη; Ναι, πολύ απλό - σαν εθισμός (διακεκομμένη γραμμή με βέλος, θυμάσαι;) με ένα στερεότυπο<> . Στην περίπτωση αυτή, το βέλος κατευθύνεται, φυσικά, προς το συμπεριλαμβανόμενο προηγούμενο. Αυτό το γεγονός είναι εύκολο να εξηγηθεί αν θυμηθούμε τη δήλωση που έχουμε ήδη χρησιμοποιήσει αρκετές φορές σε αυτό το μάθημα: το βέλος κατευθύνεται πάντα προς το στοιχείο από το οποίο απαιτείται κάτι, του οποίου οι υπηρεσίες χρησιμοποιούνται. Κι αν υποθέσουμε ότι η αγκαλιά προηγούμενοπεριλαμβάνει, δανείζεται (χρησιμοποιεί) τη συμπεριφορά των περιπτώσεων που περιλαμβάνονται, γίνεται σαφές ότι το βέλος μπορεί να κατευθυνθεί μόνο με αυτόν τον τρόπο. Και εδώ είναι διάγραμμαεπεξηγώντας τα παραπάνω, τα οποία δανειστήκαμε από τον Zicom Mentor (ρύζι. 6.10):

μεγέθυνση εικόνας
Ρύζι. 6.10.

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

Ο επόμενος στη σειρά - στάση επεκτάσεις. Για να καταλάβετε την έννοια της επέκτασης, φανταστείτε ότι μιλάμε για πληρωμή για κάποιο προϊόν που έχουμε αγοράσει. Μπορούμε να πληρώσουμε προϊόνμετρητά εάν το ποσό είναι μικρότερο από $100. Ή πληρώστε με πιστωτική κάρτα εάν το ποσό είναι μεταξύ $100 και $1000. Εάν το ποσό είναι μεγαλύτερο από $1000, θα πρέπει να λάβουμε πίστωση. Έτσι διευρύνουμε την κατανόησή μας επιχειρήσειςπληρωμή για τα αγορασμένα αγαθά και σε περιπτώσεις που χρησιμοποιούνται άλλα μέσα πληρωμής εκτός από μετρητά. Αλλά αυτές οι ίδιες οι περιπτώσεις προκύπτουν μόνο υπό αυστηρά καθορισμένες προϋποθέσεις: πότε την τιμή του προϊόντοςεμπίπτει σε ορισμένα όρια.

Συμπληρώματα επέκτασης προηγούμενοάλλα προηγούμενα που «λειτουργούν» υπό προϋποθέσεις - απλώς προσθέτει στο πρωτότυπο προηγούμενομια σειρά ενεργειών που περιέχονται σε άλλη περίπτωση χρήσης. Στάσηεπεκτάσεις της περίπτωσης χρήσης Α στην περίπτωση χρήσης Β σημαίνει ότι μια περίπτωση χρήσης Β μπορεί να περιλαμβάνει (υπό ορισμένες προϋποθέσεις, οι οποίες μπορούν να περιγραφούν στην επέκταση, πώς ακριβώς περιγράφεται, θα πούμε λίγο αργότερα) τη συμπεριφορά που περιγράφεται στην περίπτωση χρήσης Α Ένα παράδειγμα φαίνεται στο παρακάτω διάγραμμα (ρύζι. 6.11):

Ρύζι. 6.11.

Ωστόσο, στο παραπάνω παράδειγμα, δεν είναι σαφές υπό ποιες συνθήκες ένα άτομο χρησιμοποιεί κάθε συγκεκριμένη μέθοδο πληρωμής. Ταυτόχρονα, κατά τη μοντελοποίηση χρησιμοποιώντας μια επέκταση, μπορείτε να καθορίσετε τόσο τις προϋποθέσεις για την υλοποίηση της εκτεταμένης συμπεριφοράς όσο και θέση - σημείο επέκτασηςμια περίπτωση χρήσης που συνδέει ενέργειες από την επέκταση περιπτώσεων χρήσης. Θυμάμαι χειριστή άνευ όρων άλματος, το οποίο ελπίζουμε να μην χρησιμοποιείτε πολύ συχνά στα προγράμματά σας. Μόλις διερμηνέαςφτάνει σε αυτήν τη δήλωση, μεταφέρει τον έλεγχο στη γραμμή που επισημαίνεται με την ετικέτα που καθορίζεται σε αυτήν τη δήλωση. Είναι αλήθεια ότι στην περίπτωση επέκτασης, μιλάμε περισσότερο για έναν τελεστή άλματος υπό όρους - όταν το πρωτότυπο προηγούμενο(δηλαδή, η ακολουθία των ενεργειών που περιέχονται σε αυτό) φτάνει στο σημείο επέκτασης, αξιολογούνται οι συνθήκες επέκτασης. Εάν πληρούνται οι προϋποθέσεις, προηγούμενοπεριλαμβάνει την ακολουθία ενεργειών από την περίπτωση επέκτασης χρήσης.

Το σημείο επέκτασης περιγράφεται στο πρόσθετο τμήμαπροηγούμενο, χωρισμένο από το όνομά του με μια οριζόντια γραμμή - με τον ίδιο τρόπο που οι ξεχωριστές ενότητες απαριθμούν τα χαρακτηριστικά μιας κλάσης και της επιχειρήσεις. Παρακάτω είναι ένα παράδειγμα περιγραφής σημείου επέκτασης που δανειστήκαμε από τον Zicom Mentor (ρύζι. 6.12).

Ρύζι. 6.12.

Σε αυτό το παράδειγμα εγγραφήπεριλαμβάνονται οι επιβάτες της πτήσης έλεγχοςυπηρεσίες ασφαλείας και υπό τον όρο (που καθορίζεται στη σημείωση μετά τη λέξη υπηρεσίας " Κατάσταση:") ότι ένα άτομο πετά συχνά και η καμπίνα είναι γεμάτη (προσοχή στον χειριστή ΚΑΙ, που κάνει λόγο για ταυτόχρονη πλήρωση των προϋποθέσεων), Τάξητο εισιτήριο μπορεί να αναβαθμιστεί, για παράδειγμα, από «οικονομία» σε «business class». Επιπλέον, μια τέτοια αναβάθμιση μπορεί να συμβεί μόνο μετά την παρουσίαση του εισιτηρίου στο γκισέ check-in - αυτό είναι το σημείο επέκτασης. Περιγράφεται (το όνομά της δίνεται) στο πρόσθετο τμήμαπροηγούμενο μετά την υπηρεσιακή φράση " Επέκτασησημεία:».Προβλέποντας την ερώτηση του αναγνώστη ας το πούμε προηγούμενομπορεί να έχει όσα σημεία επέκτασης επιθυμείτε. Και ταιριάζουν με ένα συγκεκριμένο extension προηγούμενομε ένα συγκεκριμένο σημείο επέκτασης, μπορείτε να διαβάσετε τις συνθήκες επέκτασης που καθορίζονται στα σχόλια - η ίδια η συνθήκη γράφεται μετά τη λέξη υπηρεσίας " Κατάσταση:" σε σγουρές αγκύλες ακολουθούμενη από μια φράση υπηρεσίας " Επέκταση σημείο:", ακολουθούμενο από το όνομα του σημείου επέκτασης. Κοιτάξτε ξανά το παράδειγμα ελέγχου επιβατών στο αεροδρόμιο και δείτε μόνοι σας ότι όλα είναι πολύ απλά!

Κάποια σύγχυση μπορεί να προκληθεί από το γεγονός ότι το βέλος στρέφεται πάντα προς το διευρυμένο προηγούμενο. Αλλά ακόμα και αυτό είναι εύκολο να εξηγηθεί από την άποψη της διατριβής μας ότι «το βέλος δείχνει πάντα αυτόν από τον οποίο ζητείται κάτι»: τελικά, για να προηγούμενοέχει επεκταθεί, πρέπει να χτυπήσει το σημείο επέκτασης και να ελέγχονται οι συνθήκες, μόνο τότε οι ενέργειες που περιέχονται στην επεκτεινόμενη περίπτωση χρήσης μπορούν να προστεθούν στην ακολουθία ενεργειών της αρχικής περίπτωσης χρήσης. Όλα λοιπόν είναι σωστά - η επεκτάσιμη περίπτωση χρήσης απαιτεί σημείο επέκτασης και έλεγχο κατάστασης, γι' αυτό το βέλος δείχνει σε αυτήν.

Συνοψίζοντας όλα τα παραπάνω, μπορούμε να πούμε ότι Η επέκταση σάς επιτρέπει να μοντελοποιήσετε την προαιρετική συμπεριφορά του συστήματος(επίδοξος Τάξητο εισιτήριο αναβαθμίστηκε εάν ο επιβάτης δεν είχε διανύσει τον απαιτούμενο αριθμό μιλίων και η καμπίνα ήταν σχεδόν άδεια;). Το ίδιο το γεγονός της επέκτασης εξαρτάται από την εκπλήρωση των προϋποθέσεων - τελικά, η επέκταση μπορεί να μην συμβεί! Πρόκειται απλώς για ξεχωριστές ακολουθίες ενεργειών που εκτελούνται μόνο υπό ορισμένες συνθήκες και περιλαμβάνονται σε ορισμένα σημεία του σεναρίου (συνήθως ως αποτέλεσμα ρητής αλληλεπίδρασης με τον ηθοποιό).

Η οργάνωση περιπτώσεων χρήσης διαχωρίζοντας την κοινή συμπεριφορά (συμπερίληψη) και τις διαφορετικές συμπεριφορές (επέκταση) είναι ένα σημαντικό μέρος της διαδικασίας ανάπτυξης ενός απλού, ισορροπημένου και κατανοητού συνόλου περιπτώσεων χρήσης. Θα μπορούσε να πει κανείς ότι η χρήση της συμπερίληψης και της επέκτασης είναι σημάδι καλού στυλ στη μοντελοποίηση περιπτώσεων χρήσης.

Σε αυτό, η συζήτηση σχετικά με τη σημείωση των διαγραμμάτων περίπτωσης χρήσης θα μπορούσε να ολοκληρωθεί. Θα ήθελα απλώς να πω λίγα ακόμη λόγια για τη σχέση μεταξύ των εννοιών του προηγούμενου και συνεργασία. Έχουμε ήδη μιλήσει για συνεργασία νωρίτερα (θυμηθείτε διαγράμματα αλληλεπίδρασης?) τι θα λέγατε για πολλούς ρόλους που συνεργάζονται για να παρέχουν κάποια συμπεριφορά συστήματος. Αναφέραμε επίσης ότι οι περιπτώσεις χρήσης απαντούν στην ερώτηση «τι κάνει το σύστημα;», αλλά δεν αναφέρουμε ακριβώς πώς το κάνει. Στο στάδιο της ανάλυσης, δεν είναι πραγματικά απαραίτητο να κατανοήσουμε ακριβώς πώς το σύστημα εφαρμόζει τη συμπεριφορά του. Αλλά όταν μεταβαίνουμε στην υλοποίηση, θα ήταν ωραίο να το γνωρίζουμε ποιες κλάσεις (ή άλλα στοιχεία του μοντέλου), δουλεύοντας μαζί, παρέχουν την επιθυμητή συμπεριφορά. Δηλαδή, λογικά έχουμε περάσει από το να μιλάμε για προηγούμενα στο να μιλάμε για συνεργασία! Δεν είναι τυχαίο ότι οι ονομασίες της συνεργασίας και του προηγούμενου μοιάζουν πολύ (ο αναγνώστης, φυσικά, θυμάται ότι συνεργασίασυμβολίζεται με διακεκομμένη έλλειψη) (ρύζι. 6.13).

Ρύζι. 6.13.

Ποια είναι λοιπόν η σχέση προηγούμενοΚαι συνεργασία? Από την προηγούμενη παράγραφο προκύπτει λογικά ότι αυτό στάσηεκτέλεση. Κάθε προηγούμενουλοποιείται από μία ή περισσότερες συνεργασίες. Αυτό, φυσικά, δεν σημαίνει ότι οι τάξεις είναι αυστηρά κατανεμημένες. Μεσυνεργασίες: τάξεις που παίρνουν μέρος σε συνεργασία που υλοποιεί μια ορισμένη προηγούμενοθα συμμετάσχει και σε άλλες συνεργασίες.

Μοντελοποίηση με Διαγράμματα Περιπτώσεων Χρήσης

μοντέλο προηγούμενου, ΜεΣτην ουσία είναι ένα εννοιολογικό μοντέλο του συστήματος. Όπως έχουμε σημειώσει περισσότερες από μία φορές, περιγράφει μόνο τη συμπεριφορά (λειτουργικότητα) του συστήματος με γενικούς όρους, αλλά δεν μιλά για λεπτομέρειες υλοποίησης - σε αυτό το στάδιο, η υλοποίηση δεν είναι σημαντική, είναι πολύ πιο σημαντικό να συλλέξουμε τις απαιτήσεις για το σύστημα και τακτοποιήστε τα σε μια σαφή, κατανοητή μορφή, τόσο προγραμματιστές όσο και πελάτες.

Έτσι, συνοψίζοντας, μπορούμε να διατυπώσουμε τρεις λόγους για τη χρήση προηγούμενων. Ή, μάλλον, τρεις τρόποι χρήσης προηγούμενων (δεν είναι τυχαίο ότι στη ρωσική μετάφραση μπορεί κανείς να βρει συχνά φράση "περίπτωση χρήσης"!) ενώ εργάζεστε στο σύστημα:

· Οι περιπτώσεις χρήσης επιτρέπουν σε αναλυτές, χρήστες και προγραμματιστές να μιλούν την ίδια γλώσσα : χρησιμοποιώντας περιπτώσεις χρήσης, οι αναλυτές (εμπειρογνώμονες τομέα) μπορούν, με βάση τις επιθυμίες του πελάτη, να περιγράψουν τη συμπεριφορά του συστήματος από τη σκοπιά του χρήστη με τέτοιο βαθμό λεπτομέρειας ώστε οι προγραμματιστές να μπορούν εύκολα να κατασκευάσουν τα «μέσα» του συστήματος . Ταυτόχρονα, η σημείωση των διαγραμμάτων περίπτωσης χρήσης είναι τόσο απλή που ακόμη και ένας απροετοίμαστος χρήστης (πελάτης) είναι σε θέση να κατανοήσει το νόημά τους και να βοηθήσει στη διευκρίνισή τους - τελικά, εικόνες (και ακόμη περισσότερα κόμικ, τα οποία, στην πραγματικότητα, είναι UML τα διαγράμματα) γίνονται αντιληπτά πολύ πιο εύκολα από το κείμενο!

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

· Οι περιπτώσεις χρήσης αποτελούν τη βάση για τη δοκιμή ενός στοιχείου σε όλη την ανάπτυξη : το μοντέλο περίπτωσης χρήσης περιγράφει την επιθυμητή συμπεριφορά του συστήματος (τη λειτουργικότητά του) από τη σκοπιά του χρήστη. Έτσι, συγκρίνοντας συνεχώς την (πραγματική) λειτουργικότητα που παρέχει το στοιχείο με τις διαθέσιμες περιπτώσεις χρήσης, μπορείτε να ελέγξετε αξιόπιστα την ορθότητα της υλοποίησης του στοιχείου. Εδώ είναι μια αξιόπιστη πηγή για δοκιμές παλινδρόμησης. Επιπλέον, η εμφάνιση μιας νέας περίπτωσης χρήσης μας αναγκάζει συχνά να επανεξετάσουμε την εφαρμογή ενός στοιχείου για να διασφαλίσουμε ότι είναι επαρκώς ευέλικτο, ευμετάβλητο και επεκτάσιμο.

Οι περιπτώσεις χρήσης είναι χρήσιμες τόσο για μπροστινή όσο και για αντίστροφη μηχανική. Στον άμεσο σχεδιασμό, εμείς Μεμάλιστα πραγματοποιούμε «μετάφραση» από UMLγια ορισμένες γλώσσα προγραμματισμού. Και δοκιμάστε το δημιουργημένο εφαρμογήακολουθεί, με βάση ακριβώς τις ροές των γεγονότων που περιγράφονται από προηγούμενα. αντίστροφη μηχανικήπεριλαμβάνει μετάφραση από μια γλώσσα προγραμματισμού σε μια γλώσσα UML-διαγράμματα. Αυτά τα πράγματα πρέπει να γίνουν για διάφορους λόγους:

· Για να βρείτε λάθη και να βεβαιωθείτε ότι ο σχεδιασμός είναι επαρκής :

Είναι καλή ιδέα να κάνετε μια αντίστροφη μετάφραση μετά την πρώτη μετάφραση από την UML σε μια γλώσσα προγραμματισμού και να συγκρίνετε τα πρωτότυπα και τα αποκατεστημένα μοντέλα UML (είναι επιθυμητό αυτές οι μεταφράσεις να εκτελούνται από διαφορετικές ομάδες). Αυτό θα βεβαιωθείτε ότι η σχεδίαση του συστήματος ταιριάζει με το μοντέλο, ότι δεν χάθηκαν πληροφορίες κατά τη μετάφραση και απλώς θα συλλάβει κάποια "bugs". Αυτή η προσέγγιση ονομάζεται αντίστροφη σημασιολογική ανίχνευση (ή RST - Reverse Semantic Ιχνηλασιμότητα) και αναπτύσσεται από το INTSPEI ( http://www.intspei.com ) ως μία από τις βασικές τεχνικές της μεθοδολογίας INTSPEI P-Modeling Framework, περίληψη της οποίας μπορείτε να βρείτε στο παράρτημα αυτού του μαθήματος.

· Όταν δεν υπάρχει τεκμηρίωση : μερικές φορές η εργασία είναι να τροποποιήσετε ένα υπάρχον σύστημα, ο κώδικας του οποίου είναι ανεπαρκώς τεκμηριωμένος. Σε αυτήν την περίπτωση, η μετάφραση από μια γλώσσα προγραμματισμού σε μια γλώσσα διαγράμματος UML είναι ένας πολύ καλός τρόπος για να κατανοήσετε τον σκοπό του συστήματος και των τμημάτων του, τη λειτουργικότητα που παρέχει κ.λπ.

Και τέλος, πρέπει να σημειωθεί ότι, φυσικά, τα διαγράμματα περιπτώσεων χρήσης από μόνα τους, καθώς και τα σενάρια που ορίζουν, δεν αρκούν για τη δημιουργία ενός μοντέλου συμπεριφοράς του συστήματος. Όπως έχουμε αναφέρει προηγουμένως, οι περιπτώσεις χρήσης λένε τι κάνει το σύστημα, αλλά δεν λένε πώς. Τα σενάρια το λένε αυτό, αλλά σε κειμενική μορφή, που τα δυσκολεύει αρκετά. Τα γραφήματα έρχονται στη διάσωση αλληλεπιδράσεις που οπτικοποιούν σενάρια. Έτσι, μπορούμε τώρα να συμπληρώσουμε το παλιό μας «ψευδοδιάγραμμα» και να ηρεμήσουμε σε αυτό (ρύζι. 6.14):

Ρύζι. 6.14.

Ολοκληρώνουμε με μερικά παραδείγματα ολοκληρωμένων διαγραμμάτων περίπτωσης χρήσης. Το πρώτο παράδειγμα (του οποίου το νόημα είναι σαφές χωρίς περαιτέρω εξήγηση) καταδεικνύει τη συμπερίληψη, την επέκταση και κληρονομίαπροηγούμενα. Δώστε προσοχή στα βέλη που κατευθύνονται στους ηθοποιούς που αντιπροσωπεύουν τις πύλες. Αυτό είναι σωστό - τελικά, το σύστημα χρησιμοποιεί τις υπηρεσίες του κατά την αποστολή μηνυμάτων, ενώ ο έμπορος, αντίθετα, χρησιμοποιεί τις υπηρεσίες του συστήματος και επομένως τα βέλη κατευθύνονται μακριά από αυτόν (ρύζι. 6.15

Ρύζι. 6.16.

Δεύτερος διάγραμμα, επίσης καλά σχεδιασμένο, μας λέει ότι στις πάπιες πραγματικά δεν αρέσει να πληρώνουν για μπύρα, προτιμώντας να πίνουν με πίστωση (ρύζι. 6.17).

Ρύζι. 6.17.

Παρεμπιπτόντως, δώστε προσοχή στα πλαίσια γραφήματος που εμφανίζονται σε αυτό το παράδειγμα - ορθογώνιο παραλληλόγραμμο A που διαχωρίζει την περιοχή περιεχομένου του γραφήματος και έχει μια ειδική ενότητα στην κορυφή για το όνομά του.

Και τέλος, η τρίτη εικόνα, που δεν είναι καλό παράδειγμα διαγράμματα περιπτώσεων χρήσηςαλλά απλά αστείο. Αυτή είναι μια ιστορία για συμπεριφορές που σου επιτρέπουν να αποτύχεις σε οποιαδήποτε εξέταση (!)ρύζι. 6.18):

Ρύζι. 6.18.

συμπεράσματα

· Το μοντέλο περίπτωσης χρήσης σάς επιτρέπει να περιγράψετε το σύστημα σε εννοιολογικό επίπεδο.

· Χρησιμοποιήστε Διαγράμματα περίπτωσης - ένα εξαιρετικό μέσο επικοινωνίας μεταξύ ειδικών, χρηστών και προγραμματιστών, καθώς και η βάση για τη δοκιμή του συστήματος που δημιουργείται.

· Μια περίπτωση χρήσης είναι μια περιγραφή ενός συνόλου διαδοχικών γεγονότων (συμπεριλαμβανομένων πιθανών παραλλαγών) που εκτελούνται από το σύστημα και οδηγούν στο αποτέλεσμα που παρατηρεί ο ηθοποιός.

· Ένας ηθοποιός είναι ένα σύνολο ρόλων που εκτελεί ένας χρήστης κατά τη διάρκεια της αλληλεπίδρασης με κάποια οντότητα.

· Τα προηγούμενα (όπως οι ηθοποιοί) μπορούν να γενικευτούν, δηλαδή να κληρονομήσουν και να συμπληρώσουν τις ιδιότητες των προγόνων τους.

· Οι περιπτώσεις χρήσης μπορούν επίσης να συνάψουν σχέσεις συμπερίληψης και επέκτασης μεταξύ τους, γεγονός που σας επιτρέπει να αποσυνθέσετε τις περιπτώσεις χρήσης σε απλούστερα στοιχεία και να τονίσετε την προαιρετική συμπεριφορά.

· Κάθε περίπτωση χρήσης υλοποιείται από μία ή περισσότερες συνεργασίες.

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

Ερωτήσεις ελέγχου

· Ποιες είναι οι μη λειτουργικές απαιτήσεις; Πώς εμφανίζονται στα διαγράμματα περιπτώσεων χρήσης;

· Ποιους τρόπους αναπαράστασης ηθοποιών γνωρίζετε;

· Τι σχέσεις μπορούν να έχουν οι ηθοποιοί μεταξύ τους;

· Ποιο είναι το νόημα των σχέσεων συμπερίληψης και επέκτασης;

· Τι είναι ένα σημείο επέκτασης;

· Καταγράψτε τους λόγους που γνωρίζετε για τη χρήση προηγούμενων.

· Πώς εφαρμόζονται οι περιπτώσεις χρήσης στην μπροστινή και αντίστροφη μηχανική;

Αυτοματοποίηση- αυτή είναι η διαδικασία χρήσης αυτοματισμού, ηλεκτρονικών, τεχνολογίας υπολογιστών, κ.λπ. σε διάφορους τομείς της ανθρώπινης δραστηριότητας: στη βιομηχανία (βιομηχανική), στις μεταφορές, στην καθημερινή ζωή, στην ιατρική, στο διάστημα, στην πυρηνική ενέργεια κ.λπ. αποτέλεσμα των οποίων είναι η δημιουργία διαφόρων αυτοενεργούμενων συστημάτων ή συστημάτων αυτοματισμού.
Αυτοματοποίηση- ένα σύνολο μέτρων για την εισαγωγή αυτοματοποιημένων συσκευών στη μηχανολογία.
Αυτοματοποίηση- το υψηλότερο στάδιο μηχανοποίησης.

[Προηγούμενη διάλεξη ] [ Για να μην βλέπετε διαφημίσεις στον ιστότοπο, πρέπει να γίνετε πολύ σπουδαίο πρόσωπο-χρήστης.
Αυτό μπορεί να γίνει εντελώς δωρεάν. Ανάγνωση.

Εργαστήριο #1

Θέμα: "Μεθοδολογία αντικειμενοστρεφούς μοντελοποίησης"

1. Σκοπός της εργασίας:

Εξοικείωση με τα βασικά στοιχεία ορισμού, αναπαράστασης, σχεδίασης και μοντελοποίησης συστήματα λογισμικούχρησιμοποιώντας τη γλώσσα UML.

2. Οδηγίες

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

3. Γενικές πληροφορίες για τη μοντελοποίηση αντικειμένων της IP

Υπάρχουν πολλές τεχνολογίες και εργαλεία που μπορούν να χρησιμοποιηθούν για την υλοποίηση ενός βέλτιστου έργου IS υπό μια ορισμένη έννοια, ξεκινώντας από το στάδιο ανάλυσης και τελειώνοντας με τη δημιουργία του κώδικα προγράμματος του συστήματος. Στις περισσότερες περιπτώσεις, αυτές οι τεχνολογίες επιβάλλουν πολύ αυστηρές απαιτήσεις στη διαδικασία ανάπτυξης και στους πόρους που χρησιμοποιούνται και οι προσπάθειες μετατροπής τους για συγκεκριμένα έργα είναι ανεπιτυχείς. Αυτές οι τεχνολογίες αντιπροσωπεύονται από εργαλεία CASE ανώτατου επιπέδου ή εργαλεία CASE πλήρους κύκλου ζωής (εργαλεία άνω ΠΕΡΙΠΤΩΣΗΣ ή εργαλεία CASE πλήρους κύκλου ζωής). Δεν σας επιτρέπουν να βελτιστοποιήσετε τις δραστηριότητες σε επίπεδο μεμονωμένων στοιχείων του έργου, και ως αποτέλεσμα, πολλοί προγραμματιστές έχουν μεταβεί στα λεγόμενα εργαλεία CASE χαμηλότερου επιπέδου (εργαλεία χαμηλότερης ΠΕΡΙΠΤΩΣΗΣ). Ωστόσο, αντιμετώπισαν ένα νέο πρόβλημα - το πρόβλημα της οργάνωσης της αλληλεπίδρασης μεταξύ των διαφορετικών ομάδων που υλοποιούν το έργο.

Η Unified Modeling Language (UML) ήταν ένα μέσο για την επίτευξη συμβιβασμού μεταξύ αυτών των προσεγγίσεων. Υπάρχει επαρκής αριθμός εργαλείων που υποστηρίζουν τον κύκλο ζωής χρησιμοποιώντας το UML. πληροφοριακά συστήματα, και, ταυτόχρονα, η UML είναι αρκετά ευέλικτη ώστε να προσαρμόζει και να υποστηρίζει τις ιδιαιτερότητες των δραστηριοτήτων διαφόρων ομάδων ανάπτυξης.

Η δημιουργία του UML ξεκίνησε τον Οκτώβριο του 1994, όταν ο Jim Rumbaugh και ο Grady Booch της Rational Software Corporation άρχισαν να εργάζονται για τη συγχώνευση των μεθόδων OMT και Booch. Επί του παρόντος, η κοινοπραξία χρηστών UML Partners περιλαμβάνει εκπροσώπους τέτοιων κολοσσών πληροφορικής όπως η Rational Software, η Microsoft, η IBM, η Hewlett-Packard, η Oracle, η DEC, η Unisys, η IntelliCorp, η Platinum Technology.

Η UML είναι μια αντικειμενοστραφής γλώσσα μοντελοποίησης με τα ακόλουθα κύρια χαρακτηριστικά:

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

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

Η UML είναι μια τυπική σημείωση για την οπτική μοντελοποίηση συστημάτων λογισμικού, που υιοθετήθηκε από την Ομάδα Διαχείρισης Αντικειμένων (OMG) το φθινόπωρο του 1997 και τώρα υποστηρίζεται από πολλά αντικειμενοστραφή προϊόντα CASE.

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

Δημιουργία μοντέλων βασισμένων σε εργαλεία πυρήνα, χωρίς τη χρήση μηχανισμών επέκτασης για τις περισσότερες τυπικές εφαρμογές.

Προσθέστε νέα στοιχεία και συμβάσεις, εάν είναι απαραίτητο, εάν δεν περιλαμβάνονται στον πυρήνα ή εξειδικεύστε στοιχεία, συμβάσεις (σημειογραφία) και περιορισμούς για συγκεκριμένες θεματικές περιοχές.

Ρύζι. 1. Ένα ολοκληρωμένο μοντέλο ενός πολύπλοκου συστήματος στη σημειογραφία της γλώσσας UML

Το πρότυπο UML προσφέρει το ακόλουθο σύνολο διαγραμμάτων για μοντελοποίηση:

Διαγράμματα περιπτώσεων χρήσης (διαγράμματα περίπτωσης χρήσης) - για τη μοντελοποίηση των επιχειρηματικών διαδικασιών του οργανισμού και των απαιτήσεων για το σύστημα που δημιουργείται).

Διαγράμματα κλάσεων (διαγράμματα κλάσεων) - για τη μοντελοποίηση της στατικής δομής των κλάσεων συστήματος και των σχέσεων μεταξύ τους.

Διαγράμματα συμπεριφοράς συστήματος (διαγράμματα συμπεριφοράς):

Διαγράμματα αλληλεπίδρασης:

Διαγράμματα ακολουθίας και

Διαγράμματα συνεργασίας - για τη μοντελοποίηση της διαδικασίας ανταλλαγής μηνυμάτων μεταξύ αντικειμένων.

Διαγράμματα κατάστασης (διαγράμματα statechart) - για τη μοντελοποίηση της συμπεριφοράς των αντικειμένων του συστήματος κατά τη μετάβαση από τη μια κατάσταση στην άλλη.

Διαγράμματα δραστηριότητας (διαγράμματα δραστηριότητας) - για τη μοντελοποίηση της συμπεριφοράς του συστήματος στις διάφορες περιπτώσεις χρήσης ή των δραστηριοτήτων μοντελοποίησης.

Διαγράμματα υλοποίησης:

Διαγράμματα εξαρτημάτων (διαγράμματα συνιστωσών) - για τη μοντελοποίηση της ιεραρχίας των στοιχείων (υποσυστημάτων) του συστήματος.

Διαγράμματα ανάπτυξης - για τη μοντελοποίηση της φυσικής αρχιτεκτονικής του συστήματος.

Χρησιμοποιήστε Διαγράμματα περίπτωσης

Η έννοια της περίπτωσης χρήσης εισήχθη για πρώτη φορά από τον Ivar Jakobson και της δόθηκε τέτοια σημασία που στις μέρες μας η περίπτωση χρήσης έχει γίνει το κύριο στοιχείο ανάπτυξης και σχεδιασμού έργου.

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

Εικ.2. Θήκη χρήσης

Ο ηθοποιός είναι ο ρόλος που παίζει ο χρήστης σε σχέση με το σύστημα. Οι ηθοποιοί αντιπροσωπεύουν ρόλους, όχι συγκεκριμένα άτομα ή τίτλους εργασίας. Αν και απεικονίζονται ως στυλιζαρισμένες ανθρώπινες φιγούρες σε διαγράμματα περίπτωσης χρήσης, ο ηθοποιός μπορεί επίσης να είναι εξωτερικό σύστημα, το οποίο χρειάζεται κάποιες πληροφορίες από το δεδομένο σύστημα. Εμφάνιση ηθοποιών σε ένα διάγραμμα μόνο όταν χρειάζονται πραγματικά κάποιες θήκες χρήσης. Στο UML, οι ηθοποιοί αντιπροσωπεύονται ως σχήματα:

Εικ.3. Χαρακτήρας (ηθοποιός)

Οι ηθοποιοί χωρίζονται σε τρεις βασικούς τύπους:

Χρήστες.

Συστήματα;

Άλλα συστήματα που αλληλεπιδρούν με αυτό.

Ο χρόνος γίνεται ηθοποιός εάν η έναρξη οποιωνδήποτε γεγονότων στο σύστημα εξαρτάται από αυτόν.

Σχέσεις μεταξύ περιπτώσεων χρήσης και ηθοποιών

Στο UML, τα διαγράμματα περίπτωσης χρήσης υποστηρίζουν διάφορους τύπους σχέσεων μεταξύ των στοιχείων του διαγράμματος. Αυτοί είναι οι σύνδεσμοι επικοινωνίας (επικοινωνία), συμπερίληψης (συμπεριλαμβάνονται), επέκτασης (επέκταση) και γενίκευσης (γενίκευση).

Ένας σύνδεσμος επικοινωνίας είναι ένας σύνδεσμος μεταξύ μιας περίπτωσης χρήσης και ενός ηθοποιού. Στο UML, οι σύνδεσμοι επικοινωνίας εμφανίζονται χρησιμοποιώντας μια μονόδρομη συσχέτιση (συμπαγή γραμμή).

Εικ.4. Παράδειγμα συνδέσμου επικοινωνίας

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

Μια σχέση επέκτασης χρησιμοποιείται για να περιγράψει αλλαγές στην κανονική συμπεριφορά ενός συστήματος. Επιτρέπει σε μια περίπτωση χρήσης να χρησιμοποιεί τη λειτουργικότητα μιας άλλης μόνο όταν χρειάζεται.

Εικ.5. Ένα παράδειγμα σχέσης ένταξης και επέκτασης

Με τη βοήθεια της σύνδεσης, οι γενικεύσεις δείχνουν ότι αρκετοί ηθοποιοί έχουν κοινά χαρακτηριστικά.

Εικ.6. Ένα παράδειγμα σχέσης γενίκευσης

Διαγράμματα αλληλεπίδρασης

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

Ένα μήνυμα είναι ένα μέσο με το οποίο ένα αντικείμενο αποστολέα ζητά από ένα αντικείμενο δέκτη να εκτελέσει μία από τις λειτουργίες του.

Ένα πληροφοριακό μήνυμα είναι ένα μήνυμα που παρέχει στο αντικείμενο λήψης ορισμένες πληροφορίες για την ενημέρωση της κατάστασής του.

Ένα μήνυμα αίτησης (ερωτητικό) είναι ένα μήνυμα που ζητά την έξοδο ορισμένων πληροφοριών σχετικά με το αντικείμενο παραλήπτη.

Ένα επιτακτικό μήνυμα είναι ένα μήνυμα που ζητά από τον παραλήπτη να εκτελέσει κάποια ενέργεια.

Υπάρχουν δύο τύποι διαγραμμάτων αλληλεπίδρασης: διαγράμματα ακολουθίας και διαγράμματα συνεργασίας.