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

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

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

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

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

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

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

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

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

8 Περιπτώσεις χρήσης και Στόχοι Συνιστώμενη διαδικασία: 1. βρες τους στόχους του χρήστη 2. όρισε για κάθε στόχο μια ΠΧ πχ. Στόχος: ολοκλήρωση ή επεξεργασία μιας πώλησης. Περίπτωση χρήσης: ‘Επεξεργασία πώλησης’ 15:21Μηχανική Λογισμικού Ι8

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

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

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

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

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

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

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

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

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

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

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

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

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

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

23 Συσχετιζόμενες Περιπτώσεις Χρήσης

24 Ι. Δεληγιάννης, Τμ. Πληροφορικής ΤΕΙ-ΘUNIFIED PROCESS - ΑΝΑΛΥΣΗ24 Έμφαση Συσχετιζόμενες περιπτώσεις χρήσης Γενίκευση / Ειδίκευση

25 Ι. Δεληγιάννης, Τμ. Πληροφορικής ΤΕΙ-ΘUNIFIED PROCESS - ΑΝΑΛΥΣΗ25 Συσχετίσεις «include» «extend» Μηχανισμός οργάνωσης για καλύτερη επικοινωνία, κατανόηση και διαχείριση των περιπτώσεων χρήσης Επιδιώκεται η αποφυγή δηλώσεων κοινών, επαναλαμβανόμενων περιπτώσεων χρήσης, για περισσότερες από μία φορές

26 Ι. Δεληγιάννης, Τμ. Πληροφορικής ΤΕΙ-ΘUNIFIED PROCESS - ΑΝΑΛΥΣΗ26 Η συσχέτιση «include» Για κοινή υπο-συμπεριφορά που χρησιμοποιείται σε περισσότερες από μια ΠΧ Πχ. Πιστωτική πληρωμή

27 Ι. Δεληγιάννης, Τμ. Πληροφορικής ΤΕΙ-ΘUNIFIED PROCESS - ΑΝΑΛΥΣΗ27

28 Ι. Δεληγιάννης, Τμ. Πληροφορικής ΤΕΙ-ΘUNIFIED PROCESS - ΑΝΑΛΥΣΗ28

29 Ι. Δεληγιάννης, Τμ. Πληροφορικής ΤΕΙ-ΘUNIFIED PROCESS - ΑΝΑΛΥΣΗ29

30 Ι. Δεληγιάννης, Τμ. Πληροφορικής ΤΕΙ-ΘUNIFIED PROCESS - ΑΝΑΛΥΣΗ30 Σύνδεσης

31 Ι. Δεληγιάννης, Τμ. Πληροφορικής ΤΕΙ-ΘUNIFIED PROCESS - ΑΝΑΛΥΣΗ31 Includes relationships Includes relationships from base use case classes to inclusion use case classes are used to indicate that the base use case classes will contain the inclusion use case classes; that is, the base use case will contain the inclusion use case. A base use case defines the location at which the inclusion use case is included. Includes relationships are denoted as dashed lines or paths with an open arrow−head pointing at the inclusion use case and are labeled with the «include» keyword (stereotype). The insertion of the inclusion use case involves the execution of the base use case up to the inclusion point, inserting and executing the inclusion use case, and then continuing with the execution of the base use case. Figure 2 shows that a project manager may add projects and remove projects using the project management system. When removing projects, the functionality of finding a project is included into removing a project.

32 Ι. Δεληγιάννης, Τμ. Πληροφορικής ΤΕΙ-ΘUNIFIED PROCESS - ΑΝΑΛΥΣΗ32

33 Ι. Δεληγιάννης, Τμ. Πληροφορικής ΤΕΙ-ΘUNIFIED PROCESS - ΑΝΑΛΥΣΗ33 Είδη περιπτώσεων χρήσης Συγκεκριμένη (αυτοδύναμη) Process Sale Αφηρημένη (μη αυτοδύναμη) Handle Credit Payment Βασική (με δυνατότητα επέκτασης) Process Sale Προσθετική (Addition use case) Handle Credit Payment

34 Ι. Δεληγιάννης, Τμ. Πληροφορικής ΤΕΙ-ΘUNIFIED PROCESS - ΑΝΑΛΥΣΗ34 Η συσχέτιση «extend» Προσθήκη περίπτωσης χρήσης δίχως να επηρεαστεί η βασική Αιτιολογία Όταν δεν είναι επιθυμητή ή τροποποίηση της βασικής περίπτωσης χρήσης You can add extend relationships to a model to show the following situations: A part of a use case that is optional system behavior A subflow is executed only under certain conditions A set of behavior segments that may be inserted in a base use case

35 Ι. Δεληγιάννης, Τμ. Πληροφορικής ΤΕΙ-ΘUNIFIED PROCESS - ΑΝΑΛΥΣΗ35

36 Ι. Δεληγιάννης, Τμ. Πληροφορικής ΤΕΙ-ΘUNIFIED PROCESS - ΑΝΑΛΥΣΗ36

37 Ι. Δεληγιάννης, Τμ. Πληροφορικής ΤΕΙ-ΘUNIFIED PROCESS - ΑΝΑΛΥΣΗ37

38 Ι. Δεληγιάννης, Τμ. Πληροφορικής ΤΕΙ-ΘUNIFIED PROCESS - ΑΝΑΛΥΣΗ38 Extends relationships from extension use case classes to base use case classes are used to indicate that the base use case classes may be augmented by the extension use case classes; that is, the inclusion use case will augment the base use case if an extension condition is satisfied. A base use case defines the extension point. An extension use case defines the extension condition that must be satisfied in order to insert the extension use case into the base use case. The insertion of the extension use case involves the execution of the base use case up to the extension point, testing the extension condition and inserting and executing the extension use case if the condition is satisfied, and then continuing with the execution of the base use case. Extends relationships are denoted as dashed lines or paths with an open arrow−head pointing at the extension use case and are labeled with the extension condition in square brackets, the «extend» keyword (stereotype), and the extension point name in parentheses. Extension points are identified in a compartment labeled "Extension Points" in the base use case. Figure 3 shows that a project manager may update projects using the project management system. When updating projects, a project manager may manage tasks if the project manager selects the task option, and a project manager may manage resource if the project manager selects the resource option.

39 Ι. Δεληγιάννης, Τμ. Πληροφορικής ΤΕΙ-ΘUNIFIED PROCESS - ΑΝΑΛΥΣΗ39

40 Ι. Δεληγιάννης, Τμ. Πληροφορικής ΤΕΙ-ΘUNIFIED PROCESS - ΑΝΑΛΥΣΗ40 The > relationship means that the flow of that use case is always included. But a > relationship means that the flow of the extending use case is only included under specific conditions, which must be specified as the extension point of the use case being extended.

41 Ι. Δεληγιάννης, Τμ. Πληροφορικής ΤΕΙ-ΘUNIFIED PROCESS - ΑΝΑΛΥΣΗ41 Η συσχέτιση Γενίκευσης Οι ειδικοί των περιπτώσεων χρήσης θεωρούν ότι: Μάλλον δεν είναι χρήσιμη Δεν έχουν συμφωνήσει για την χρησιμότητά της Προσθέτει περισσότερη πολυπλοκότητα στις περιπτώσεις χρήσης

42 Ι. Δεληγιάννης, Τμ. Πληροφορικής ΤΕΙ-ΘUNIFIED PROCESS - ΑΝΑΛΥΣΗ42 Generalization relationships from specialization use case classes to generalized use case classes are used to indicate the specialization use case classes are consistent with the generalized use case classes and may add additional information. A specialization use case may be used in place of a generalized use case and may use any portions of the interaction of the generalized use case. Generalization relationships are denoted as solid lines or paths with a hollow arrow−head pointing at the generalized use case. Figure 4 shows that a project manager may publish a project schedule by sending e−mail to project team members using an e−mail system or by generating a web−site on a web−site host. In either case, there will be common functionality used from the generalized use case, for example: inputting project name, extracting the relevant project information form the project database, etc.

43 Ι. Δεληγιάννης, Τμ. Πληροφορικής ΤΕΙ-ΘUNIFIED PROCESS - ΑΝΑΛΥΣΗ43

44 Ι. Δεληγιάννης, Τμ. Πληροφορικής ΤΕΙ-ΘUNIFIED PROCESS - ΑΝΑΛΥΣΗ44