Download Become A Software Engineer and more Study notes Software Engineering in PDF only on Docsity!
Created
Class 7SE
Type Materials Reviewed
Περιπτώσεις Χρήσης (Use Cases)
Thinks to keep in mind
All “include” arrows should be presented in the basic flow All “extend” arrows should be presented in at least one alternative flow There are UCs that start from actors, and others that are triggered from other UCs. This should be mentioned in the 1st step of the UC Checks should be followed by the outcome of the check When interaction is needed be sure to mention the name of the UI, from/to which you get/provide information Most of the UCs have some kind of interaction, one-sided UC descriptions are probably faulty if the actor is on the left, it means that's a "primary actor", the actor who activates the use case. If the actor is on the right, it means that the actor is a secondary one: he participates to use case but does not activate it. (Stack overflow ). Primary actors are those that initiate use cases and interact with the system. They are usually placed on the left side of the system. On the other hand, secondary actors are used by the system but they do not interact with the system on their own. They are displayed on the right side of the system
@February 5, 2023 11:58 AM
Κατασκευάστε το Διάγραμμα Περιπτώσεων Χρήσης που περιγράφει τις λειτουργίες του βιβλίου διευθύνσεων σε ένα πρόγραμμα διαχείρισης ηλεκτρονικού ταχυδρομείου σύμφωνα με την παρακάτω περιγραφή:
«Ο χρήστης έχει τη δυνατότητα να πραγματοποιήσει αναζήτηση στις υπάρχουσες επαφές καθώς και να διαγράψει μία υπάρχουσα επαφή. Επίσης, μπορεί να δημιουργήσει μια καινούρια επαφή ή να τροποποιήσει μία υπάρχουσα. Κατά τη διαδικασία της δημιουργίας μιας καινούριας επαφής ή την τροποποίηση μιας υπάρχουσας επαφής του έχει τη δυνατότητα είτε να αποθηκεύσει τις αλλαγές του είτε να ακυρώσει τις μέχρι εκείνη τη στιγμή αλλαγές που έχει κάνει».
Για να δημιουργήσουμε το διάγραμμα περιπτώσεων χρήσης πρέπει
δικό του λογαριασμό σε λογαριασμό τρίτου. Για να μπορέσει να πραγματοποιήσει οποιαδήποτε από αυτές τις συναλλαγές θα πρέπει πρώτα να έχει πιστοποιηθεί ως χρήστης του συστήματος. Τις ίδιες λειτουργίες με τον πελάτη της τράπεζας μπορεί να πραγματοποιήσει και ο προϊστάμενος της τράπεζας χωρίς όμως να απαιτείται η πιστοποίησή του. Ο ταμίας της τράπεζας μπορεί μόνο να κάνει μεταφορά χρημάτων μεταξύ λογαριασμών. Τέλος, την τροφοδότηση του ΑΤΜ με μετρητά την πραγματοποιεί ο υπεύθυνος τροφοδοσίας».
Για να δημιουργήσουμε το διάγραμμα περιπτώσεων χρήσης πρέπει
- Να εντοπίσουμε τους χρήστες
- Να εντοπίσουμε τις ενέργειες που κάνουν αυτοί οι χρήστες
Υπογραμμίζοντας με κόκκινο χρώμα τους χρήστες και με πράσινο χρώμα τις ενέργειες, προκύπτει η παρακάτω εκφώνηση
«Ο πελάτης της τράπεζας μπορεί να πραγματοποιήσει ανάληψη μετρητών, κατάθεση μετρητών σε υπάρχοντα λογαριασμό (δικό του ή τρίτου) και μεταφορά ποσού από δικό του λογαριασμό σε λογαριασμό τρίτου. Για να μπορέσει να πραγματοποιήσει οποιαδήποτε από αυτές τις συναλλαγές θα πρέπει πρώτα να έχει πιστοποιηθεί ως χρήστης του συστήματος. Τις ίδιες λειτουργίες με τον πελάτη της τράπεζας μπορεί να πραγματοποιήσει και ο προϊστάμενος της τράπεζας χωρίς όμως να απαιτείται η πιστοποίησή του. Ο ταμίας της τράπεζας μπορεί μόνο να κάνει μεταφορά χρημάτων μεταξύ λογαριασμών. Τέλος, την τροφοδότηση του ΑΤΜ με μετρητά την πραγματοποιεί ο υπεύθυνος τροφοδοσίας».
Για την κατασκευή του διαγράμματος χρειάζεται
- να δημιουργήσουμε ένα τετράφωνο με το όνομα system και μέσα σε αυτό να το τοποθετήσουμε τις ενέργειες που υπογραμμίσαμε
- Τοποθετούμε τους πρωτεύων χρήστες στην αριστερή πλευρά, στην περίπτωση μας τους χρήστες Πελάτης, Προϊστάμενος και ταμίας
- Τοποθετούμε τους δευτερεύων χρήστες στην δεξιά πλευρά, στην περίπτωση μας τον χρήστη υπεύθυνος τροφοδοσίας
- Ενώνουμε με γραμμές τις ενέργειες που κάνει ο κάθε χρήστης.
- Για τον χρήστη Πελάτη βάζουμε τις ενέργειες ανάληψη ,κατάθεση και μεταφορά να είναι extend του πιστοποίηση επειδή η εκφώνηση μας λέει ότι ο πελάτης για να μπορέσει να κάνεις τις παραπάνω ενέργειες πρέπει να έχει πιστοποιηθεί (σε αντίθεση με τον προϊστάμενο)
Άσκηση 3
Πληροφοριακό Σύστημα Καταγραφής Ιατρικών Πράξεων
Το σύστημα θα απευθύνεται σε ιατρούς για την επίσημη μηχανογράφηση των ιατρικών του πράξεων (συνταγογράφηση, επισκέψεις και διαγνωστικών εξετάσεων) ανά επίσκεψη του εκάστοτε ασθενή. Το σύστημα αυτό θα ενσωματωθεί σε ένα κλασικό σύστημα πελατολογίου και online ραντεβού από τον ασθενή.
- Πιστοποίηση των στοιχείων χρήστη για είσοδο στην υπηρεσία και δικαιώματα του διαχειριστή : Θα γίνεται αντιστοίχιση των στοιχείων χρήστη με
: Ο/η γραμματέας θα έχει την δυνατότητα να καταχωρεί τα ραντεβού των ασθενών (που δεν είναι online) και να διαχειρίζεται την βάση που περιέχει τους ασθενείς αλλά και τα ραντεβού για την εισαγωγή, διαγραφή και τροποποίηση των στοιχείων των προαναφερθέντων βάσεων. Ο/η γραμματέας δεν θα έχει την δυνατότητα για την μεταβολή ευαίσθητων στοιχείων στην καρτέλα του εκάστοτε ασθενή, αρμοδιότητα που θα κατέχει πλήρως και μόνο ο θεράπων ιατρός.
Διαβάζοντας την εκφώνηση δημιουργούμε τον πίνακα χρηστών στόχων. Ο παρακάτω πίνακας περιέχει 2 στήλες, στην πρώτη έχουμε τους χρήστες του συστήματος και στην δεύτερη τις ενέργειες που κάνουν οι αντίστοιχοι χρήστες.
💡 το CRUD είναι συντομογραφία του CREATE-READ-UPDATE-DELETE
User Goal
Doctor
CRUD Appointment CRUD Patient Create Report for EOPYY Manage Appointment Add Medication View History Add Appointment Details Search Patient View Schedule View Warnings
Patient Register CRUD Appointment Login / LogoutView History Delete Account
Secretary CRUD Appointment CRUD Patient View Schedule Search Patient View History
EOPYY Retrieve Patient Data Retrieve MedicineDetails
Η κάθε ενέργεια είναι ένα use case. Βάση όλων αυτών που αναφέραμε στις ασκήσεις 1 και 2 δημιουργούμε το διάγραμμα περιπτώσεων χρήσης
Κανονικά για κάθε use case πρέπει να δημιουργηθεί το αντίστοιχο use case specification(προδιαγραφή). Για την ανάγκη της άσκησης υλοποιήθηκαν μόνο 3 use case specifications
Use case specification για το Search Patient (UC03)
Διαγράμματα Ακολουθίας (Sequence
Diagrams)
Λίγα λόγια
Ένα διάγραμμα ακολουθίας παρουσιάζει την αλληλεπίδραση μεταξύ αντικειμένων σε δύο διαστάσεις, όπου:
η κάθετη διάσταση αντιστοιχεί στην κλίμακα του χρόνου η οριζόντια διάσταση στα ανεξάρτητα αντικείμενα.
Για όσο χρόνο ένα αντικείμενο υφίσταται, η γραμμή αυτή είναι διακεκομμένη ενώ για όσο χρόνο μία διαδικασία του εν λόγω αντικειμένου είναι ενεργή η γραμμή ζωής σχεδιάζεται ως μία διπλή γραμμή. να μήνυμα συμβολίζεται ως μία ακμή από τη γραμμή ζωής ενός αντικειμένου προς τη γραμμή ζωής ενός άλλου. Απαντήσεις σε μηνύματα υποδηλώνονται ως οριζόντιες διακεκομμένες ακμές
Υλοποιούμε ένα διάγραμμα ακολουθίας για κάθε περίπτωση χρήσης.
Whereas the Model-View-Controller pattern is used for user interfaces, the Entity-Control-Boundary Pattern (ECB) is used for systems. The following aspects of ECB can be likened to an abstract version of MVC, if that's helpful:
Entities (model) Objects representing system data, often from the domain model.
Boundaries (view/service collaborator) Objects that interface with system actors (e.g. a user or external service ). Windows, screens and menus are examples of boundaries that interface with users.
Controls (controller) Objects that mediate between boundaries and entities. These serve as the glue between boundary elements and entity elements, implementing the logic required to manage the various elements and their interactions. It is important to understand that you may decide to implement controllers within your design as something other than objects – many controllers are simple enough to be implemented as a method of an entity or boundary class for example.
- Ένα αντικείμενο τύπου Customer δημιουργεί αντικείμενο τύπου Order
- δεν επιστρέφει κάτι
- Για κάθε product να γίνει η κλίση της συνάρτησης addItem( product, qty).
Για καλύτερη κατανόηση του βήματος 3 το συγκεκριμένο iteration σε κώδικα python γράφεται ως εξής
for product in ["Ntomates","Mpananes","Mpires"]: addItem(product,5)
- το αντικείμενο τύπου Order καλεί την μέθοδο checkAvailable(product,qty) ενός αντικειμένου τύπου Stock , για να ελέγχει εάν υπάρχει διαθέσιμη ποσότητα για το επιλεγμένο προϊόν
- Η μέθοδος επιστρέφει done
- το αντικείμενο τύπου Order καλεί την δικιά του μέθοδο addProduct(product) και περνάει παραμετρικά το αντικείμενο για το οποίο έχει γίνει έλεγχος ότι υπάρχει διαθέσιμη ποσότητα
- το αντικείμενο τύπου Order καλεί την μέθοδο reduceStock(product,qty) του αντικειμένου τύπου Stock , για να αφαιρέσει από το Stock της ποσότητα που έγινε προηγουμένως add
- Η μέθοδος επιστρέφει done
- Η μέθοδος επιστρέφει done
- Γίνεται save της παραγγελίας
- Η μέθοδος επιστρέφει done
- Το αντικείμενο τύπου Order γίνετε delte
Άσκηση Moodle
Να μετατραπεί το παρακάτω use case specification σε
Sequence Diagram (SD) και σε System Sequence Diagram
Λύση : SSD
Διαγράμματα Κλάσεων
Απεικόνιση Κλάσεων
Στην UML οι κλάσεις απεικονίζονται με ένα τετράγωνο τριών τμημάτων που περιέχουν: το όνομα της κλάσης, τις ιδιότητες (attributes) της κλάσης, και τις λειτουργίες (operations) της κλάσης.
Attributes With & Without Types
Μια κλάση μπορεί να έχει ιδιότητες ή να μην έχει Οι ιδιότητες είναι κοινές για όλα τα αντικείμενα της κλάσης Σε οποιαδήποτε χρονική στιγμή ένα αντικείμενο της κλάσης θα έχει συγκεκριμένες τιμές για κάθε μια ιδιότητα της κλάσης Μπορεί να φαίνεται το όνομα της ιδιότητας, ο τύπος των δεδομένων, αλλά και αρχική τιμή σε όλες ή κάποιες από αυτές
Προσπελασημότητα
Ορατότητα (Visibility)
Η ορατότητα ορίζει αν μια ιδιότητα ή λειτουργία είναι ορατή, δηλαδή μπορεί να προσπελασθεί από άλλες κλάσεις.
Η UML παρέχει τέσσερα σύμβολα για την ορατότητα :
+ δημόσια ορατότητα (public). Προσπέλαση και από άλλες κλάσεις.
- ιδιωτική ορατότητα (private). Προσπέλαση μόνο μέσα στην ίδια κλάση. # προστατευμένη ορατότητα (protected). Προσπέλαση έξω από το πακέτο αλλά από υποκλάσεις της τρέχουσας (κληρονομικότητα)
Σχέσεις μεταξύ κλάσεων
Οι πιο σημαντικές σχέσεις στην αντικειμενοστρεφή τεχνολογία λογισμικού είναι οι :
Συσχετίσεις (associations) are represented by a solid line between classes. Associations are typically named using a verb or verb phrase which reflects the real world problem domain. Εξαρτήσεις (dependencies) An object of one class might use an object of another class in the code of a method. If the object is not stored in any field, then this is modeled as a dependency relationship. Γενικεύσεις (generalizations) Represents an "is-a" relationship Συσσωματώσεις (aggregations) It represents a "part of" relationship. Class2 is part of Class1. Objects of Class1 and Class2 have separate lifetimes.
Συνθέσεις (Compositions) is entirerly made of stronger version of affregation Objects of Class2 live and die with Class Class2 cannot stand by itself
