ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης

ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης
ΟΙΚΟΝΟΜΙΚΟ ΠΑΝΕΠΙΣΤΗΜΙΟ ΑΘΗΝΩΝ ΤΜΗΜΑ ΠΛΗΡΟΦΟΡΙΚΗΣ ΤΕΧΝΟΛΟΓΙΑ ΛΟΓΙΣΜΙΚΟΥ Απαιτήσεις Λογισμικού 2009 ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης

Σημερινή παρουσίαση Τι είναι οι απαιτήσεις Δραστηριότητες προσδιορισμού απαιτήσεων Η εξαγωγή απαιτήσεων Περιπτώσεις χρήσης 2009 ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης

Τι είναι οι απαιτήσεις πριν βρούμε τη λύση πρέπει να καταλάβουμε το πρόβλημα Οι απαιτήσεις είναι μια περιγραφή του τι μπορεί το σύστημα να κάνει έτσι ώστε να ικανοποιεί το σκοπό για τον οποίο αναπτύσσεται Με τις απαιτήσεις διατυπώνουμε το πρόβλημα και όχι τη λύση του 2009 ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης

Λειτουργικές και μη λειτουργικές απαιτήσεις
Το σύνολο των { fi } περιγράφει τη λειτουργικότητα του συστήματος . (xi: διάνυσμα εισόδου, yi: διάνυσμα εξόδου) Μία Λειτουργική απαίτηση (functional requirement) περιγράφει μια αλληλεπίδραση μεταξύ του συστήματος και του περιβάλλοντός του. 2009 ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης

Ορολογία απαιτήσεων 2009 ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης

Χαρακτηριστικά των καλών απαιτήσεων
Ορθότητα Πληρότητα Συνέπεια Εφικτότητα υλοποίησης Αναγκαιότητα Επαληθευσιμότητα Ιχνηλασιμότητα Σαφήνεια – ακρίβεια Προτεραιοποίηση 2009 ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης

Ποιους ενδιαφέρουν οι Απαιτήσεις – ενδιαφερόμενοι (stakeholders) (1/2)
Οι πελάτες που χρηματοδοτούν το έργο της ανάπτυξης του λογισμικού και αναμένουν το λογισμικό για να επιτύχουν τους επιχειρησιακούς στόχους του οργανισμού τους. Οι άμεσοι χρήστες του λογισμικού Οι έμμεσοι χρήστες του λογισμικού (αυτοί που λαμβάνουν υπηρεσίες από το λογισμικό μέσω τρίτων) Οι μηχανικοί λογισμικού που συντάσσουν τις απαιτήσεις Οι μηχανικοί λογισμικού που θα σχεδιάσουν, υλοποιήσουν, συντηρήσουν το λογισμικό 2009 ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης

Ποιους ενδιαφέρουν οι Απαιτήσεις- ενδιαφερόμενοι (stakeholders) (2/2)
Οι ελεγκτές που θα επιβεβαιώσουν ότι το λογισμικό ανταποκρίνεται στις απαιτήσεις Οι συντάκτες των εγχειριδίων χρήσης και οι εκπαιδευτές των χρηστών Οι διοικητές του έργου της ανάπτυξης του λογισμικού Η ομάδα διασφάλισης ποιότητας του έργου Οι νομικοί που διασφαλίζουν ότι το λογισμικό συμμορφώνεται με τους κανονισμούς και τους νόμους Οι παραγωγοί συστημάτων που θα χρησιμοποιήσουν το λογισμικό για να κτίσουν συστήματα Οι πωλητές, διαφημιστές και στελέχη που θα προωθήσουν το λογισμικό στην αγορά ή θα προωθήσουν τις υπηρεσίες που αυτό θα παράγει στην αγορά. 2009 ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης

Επίπεδα απαιτήσεων Επιχειρησιακές Απαιτήσεις (Business Requirements) Απαιτήσεις Χρηστών (User Requirements) Απαιτήσεις Συστήματος - Λογισμικού 2009 ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης

Απαιτήσεις Συστήματος και Απαιτήσεις Λογισμικού
2009 ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης

ΕΠΑΣ (1/2) 1. Εισαγωγή 1.1 Σκοπός του συστήματος 1.2 Εμβέλεια του συστήματος 1.3 Ορισμοί, ακρώνυμα και συντομογραφίες 1.4 Αναφορές 1.5 Επισκόπηση του συστήματος 2. Γενική περιγραφή του συστήματος 2.1 Περιβάλλον του συστήματος 2.2 Καταστάσεις λειτουργίας του συστήματος 2.3 Κύριες δυνατότητες του συστήματος 2.4 Κύριες συνθήκες (conditions) του συστήματος 2.5 Κύριοι περιορισμοί του συστήματος 2.6 Χαρακτηριστικά χρηστών 2.7 Υποθέσεις και εξαρτήσεις 2.8 Σενάρια λειτουργίας 2009 ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης

ΕΠΑΣ (2/2) 3. Δυνατότητες, συνθήκες και περιορισμοί του συστήματος 3.1 Φυσική διάσταση 3.1.1 Κατασκευή 3.1.2 Ανθεκτικότητα στο χρόνο (durability) 3.1.3 Προσαρμοστικότητα 3.1.4 Συνθήκες περιβάλλοντος 3.2 Χαρακτηριστικά απόδοσης του συστήματος 3.3 Ασφάλεια του συστήματος 3.4 Διαχείριση πληροφορίας 3.5 Λειτουργίες του συστήματος 3.5.1 Ανθρώπινοι παράγοντες 3.5.2 Συντηρισιμότητα του συστήματος 3.5.3 Αξιοπιστία του συστήματος 3.6 Ρυθμιστικές πολιτικές 3.7 Υποστήριξη του κύκλου ζωής του συστήματος 4. Διεπαφές του συστήματος 2009 ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης

Δραστηριότητες Απαιτήσεων

Μελέτη σκοπιμότητας (feasibility study)
Η μελέτη σκοπιμότητας ξεκινά με ένα σύνολο προκαταρκτικών επιχειρησιακών απαιτήσεων, μια προσεγγιστική σκιαγράφηση του συστήματος που θα αναπτυχθεί και μια περιγραφή του τρόπου υποστήριξης των επιχειρησιακών διαδικασιών από το σύστημα. Το αποτέλεσμα της μελέτης είναι μια έκθεση που απαντά στο ερώτημα αν αξίζει ή όχι το κόπο να συνεχίσουμε τη διαδικασία ανάπτυξης. Η επιχειρηματολογία της έκθεσης εστιάζει σε ερωτήματα όπως : κατά πόσο το σύστημα συνδράμει στη επιτυχία των στόχων του οργανισμού που θα το χρησιμοποιήσει, κατά πόσο το σύστημα είναι υλοποιήσιμο με τις τρέχουσες τεχνολογίες και στα πλαίσια συγκεκριμένων ορίων κόστους και χρόνου και τέλος κατά πόσο το σύστημα είναι ολοκληρώσιμο με άλλα υπάρχοντα συστήματα. 2009 ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης

Εξαγωγή Απαιτήσεων (Requirements elicitation)
Σε αυτή τη δραστηριότητα οι μηχανικοί λογισμικού συνεργάζονται με τους ενδιαφερομένους (stakeholders) του λογισμικού με σκοπό να προσδιορίσουν : το πεδίο εφαρμογής του λογισμικού, τις υπηρεσίες που θα παρέχει το σύστημα, τις απαιτούμενες επιδόσεις του συστήματος, τους περιορισμούς που θέτει το υλικό του υπολογιστή στο υπό ανάπτυξη λογισμικό ή τους περιορισμούς που θέτει το υπό ανάπτυξη λογισμικό στο υλικό του υπολογιστή κτλ. 2009 ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης

Ανάλυση Απαιτήσεων (Requirements analysis )
Η ανάλυση επιχειρεί να προσδιορίσει το λογισμικό μας περιγράφοντας ένα μοντέλο του λογισμικού χωρίς να λαμβάνει υπόψη το πραγματικό περιβάλλον υλοποίησης του λογισμικού. Η ανάλυση δεν ασχολείται με το περιβάλλον υλοποίησης του λογισμικού παρά μόνο με το χώρο του προβλήματος και την λειτουργικότητα του λογισμικού. Η ανάλυση έχει ως αποτέλεσμα τον αναλυτικότερο και σαφέστερο προσδιορισμό των λειτουργικών απαιτήσεων του λογισμικού. 2009 ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης

Προδιαγραφή Απαιτήσεων (Requirements specification)
Σκοπός της δραστηριότητας αυτής είναι η διατύπωση – σύνταξη των απαιτήσεων που προσδιορίστηκαν από τις προηγούμενες δραστηριότητες έτσι ώστε αυτές να είναι αξιοποιήσιμες από τους μηχανικούς λογισμικού που εμπλέκονται στην ανάπτυξη του λογισμικού και επιβεβαιώσιμες από τους ενδιαφερόμενους για τις απαιτήσεις λογισμικού. 2009 ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης

Επικύρωση απαιτήσεων (Requirements validation)
εξετάζεται η πληρότητα των απαιτήσεων (έχουν καταγραφεί όλες οι απαιτήσεις), η ορθότητα τους (το σύνολο των ενδιαφερομένων συμφωνούν με τον τρόπο που προσδιορίζεται η κάθε απαίτηση), η συνέπεια τους (δεν είναι αντικρουόμενες μεταξύ τους), η σαφήνεια τους (ερμηνεύονται μονοσήμαντα), η δυνατότητα πραγματοποίησης τους (με τις δεδομένες τεχνολογίες, με το δεδομένο προϋπολογισμό, με το δεδομένο χρονοδιάγραμμα και με τους δεδομένους ανθρώπινους πόρους) και τέλος ο τρόπος επιβεβαίωσης (σύνολο ελέγχων που απαντά για την επιβεβαίωση των απαιτήσεων) τους όταν με το καλό υλοποιηθεί το σύστημα μας. 2009 ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης

Διαχείριση δραστηριοτήτων προσδιορισμού απαιτήσεων

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

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

Δραστηριότητες εξαγωγής απαιτήσεων
Επιχειρησιακή μοντελοποίηση Παρατήρηση Η επικοινωνία με τους ενδιαφερομένους (stakeholders) του έργου ανάπτυξης 2009 ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης

Επιχειρησιακή Μοντελοποίηση (1/3)
Η επιχειρησιακή μοντελοποίηση σχετίζεται πολύ περισσότερο με τη λειτουργία του οργανισμού και λιγότερο με το λογισμικό. Στοχεύει στη καταγραφή των λειτουργιών του οργανισμού, των διαδικασιών με τις οποίες εκτελούνται οι λειτουργίες και των βημάτων των διαδικασιών. Κατά κανόνα οι μηχανικοί λογισμικού βρίσκουν έτοιμα τα επιχειρησιακά μοντέλα, τα οποία αποτελούν καλή πρώτη ύλη για την παραγωγή των απαιτήσεων. Ένα επιχειρησιακό μοντέλο απεικονίζει κυρίως δύο ενότητες πληροφορίας : τη στατική όψη του οργανισμού δηλαδή την οργανωτική του δομή και τη δυναμική όψη δηλαδή τις διαδικασίες που ακολουθούνται εντός του οργανισμού. Τα επιχειρησιακά μοντέλα αναδεικνύουν μόνο τα σημαντικά στοιχεία της λειτουργίας του οργανισμού και αγνοούν λεπτομέρειες δευτερεύουσας σημασίας. 2009 ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης

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

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

Υιοθέτηση πλαισίου επικοινωνίας
Επικοινωνία: Μηχανικοί Λογισμικού --- Ενδιαφερόμενοι για τις απαιτήσεις (stakeholders) Καταγραφή ενδιαφερομένων Προγραμματισμός συναντήσεων Agenda για κάθε συνάντηση Μέριμνα για διαμόρφωση κοινής ορολογίας 2009 ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης

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

Περιπτώσεις Χρήσης Οι περιπτώσεις χρήσης χρησιμοποιούνται για την εξαγωγή (elicitation) των λειτουργικών απαιτήσεων Είναι διηγήσεις χρήσης του συστήματος λογισμικού. Μία περίπτωση χρήσης παρέχει αξία στον τελικό χρήστη παράγοντας κάποιο ευδιάκριτο αποτέλεσμα 2009 ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης

Περιπτώσεις Χρήσης και Απαιτήσεις
Απαιτήσεις Λογισμικού. Τι θα κάνει το σύστημα λογισμικού. Περιπτώσεις χρήσης. Τι θα κάνει το σύστημα για κάποιον χρήστη του. Δίνεται έμφαση στην οπτική του τελικού χρήστη. Αποδεχόμαστε ότι υπάρχουν διαφορετικές οπτικές του λογισμικού γιατί υπάρχουν διαφορετικές ανάγκες. 2009 ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης

Περιπτώσεις χρήσης τι θα κάνει το λογισμικό για κάποιον χρήστη ; (όχι τι κάνει το λογισμικό) Το σύνολο των περιπτώσεων χρήσης περιγράφουν την λειτουργικότητα που παρέχεται από το σύστημα η UML παρέχει τα διαγράμματα περιπτώσεων χρήσης (use case diagrams) 2009 ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης

Actors Actor: μία οντότητα εκτός του συστήματος που αλληλεπιδρά με αυτό Actor: άνθρωπος ή σύστημα Actor: τύπος χρήστη πρωτεύων actor για μία περίπτωση χρήσης είναι ο actor που κατά κανόνα την εκκινεί. Μία περίπτωση χρήσης ικανοποιεί κυρίως τους στόχους του πρωτεύοντος actor. Η εξυπηρέτηση των στόχων του πρωτεύοντος actor είναι το στοιχείο με το οποίο αποτιμάται η αξία που παρέχει μία περίπτωση χρήσης. 2009 ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης

Διαγράμματα Περιπτώσεων Χρήσης
Η ανθρώπινη φιγούρα συμβολίζει τον actor Η έλλειψη την περίπτωση χρήσης Η γραμμή μεταξύ τους (συσχέτιση) συμβολίζει την αλληλεπίδραση 2009 ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης

Γενίκευση Actors Χρησιμοποιούμε τη γενίκευση των actor όταν θέλουμε να δείξουμε ομοιότητες μεταξύ των actors Οι actors θα πρέπει να εμφανίζουν κοινή συμπεριφορά σε σχέση με το σύστημα 2009 ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης

Γενίκευση actors 2009 ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης

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

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

Σενάρια (1/2) Οι περιπτώσεις χρήσης περιγράφονται σε φυσική γλώσσα με τρόπο που να είναι κατανοητές από τον πελάτη και τους χρήστες. Δεν περιγράφονται όμως όλες οι δυνατότητες εκτέλεσης της περίπτωσης χρήσης και όλα τα δυνατά μονοπάτια στη ροή εκτέλεσης των βημάτων. Τα διαφορετικά μονοπάτια στη ροή εκτέλεσης ονομάζονται σενάρια. Ένα σενάριο (ή στιγμιότυπο περίπτωσης χρήσης) είναι μία ακολουθία ενεργειών και αλληλεπιδράσεων actors και συστήματος. Μία περίπτωση χρήσης μπορεί να θεωρηθεί ως ένα σύνολο πιθανών σεναρίων που εξυπηρετούν ένα συγκεκριμένο στόχο του πρωτεύοντος actor και είναι πιθανό να εκτελεστούν, όταν ο πρωτεύων actor εκκινεί την περίπτωση χρήσης. Οι ροές των βημάτων σε μία περίπτωση χρήσης χωρίζονται σε δύο κατηγορίες. Η πρώτη κατηγορία είναι η βασική ροή (basic flow) η οποία περιγράφει το κύριο σενάριο και είναι μία τυπική ροή των βημάτων με επιτυχή κατάληξη. Η δεύτερη κατηγορία, είναι οι εναλλακτικές ροές (alternative flows) που είναι εναλλακτικές επιτυχημένες ή αποτυχημένες ροές εκτέλεσης της περίπτωσης χρήσης. 2009 ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης

Σενάρια (2/2) Ανάλογα με το πόσο λεπτομερής είναι η διατύπωση των βημάτων και των δυνατών σεναρίων, έχουμε τρεις μορφές περιπτώσεων χρήσης που είναι: Σύντομη . Περιγράφουμε την περίπτωση χρήσης σε μία παράγραφο καταγράφοντας τη βασική ροή Ουσιώδης (essential use cases). Περιγράφονται αναλυτικά όλα τα βήματα της αλληλεπίδρασης με όλες τις εναλλακτικές ροές. Συστήματος (system use cases). Χρησιμοποιούνται κυρίως ως μέσο προδιαγραφής των απαιτήσεων. Η σύντομη περιγραφή χρησιμοποιείται κυρίως για μία πρώτη καταγραφή της περίπτωσης χρήσης στα πρώτα στάδια της εξαγωγής των απαιτήσεων. Όταν οι περιπτώσεις χρήσης εξετάζονται λεπτομερέστερα, περιγράφονται με χρήση της ουσιώδους μορφής. Εάν θέλουμε να προδιαγράψουμε με λεπτομέρεια την αλληλεπίδραση του actor με το σύστημα χρησιμοποιούμε τη μορφή του συστήματος. 2009 ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης

Περιεχόμενα περιπτώσεων χρήσης
Τα βήματα των περιπτώσεων χρήσης περιγράφονται με απλές καταφατικές και σύντομες προτάσεις. Διατυπώνουν με ακρίβεια για το τι κάνει το σύστημα και τι ο πρωτεύων actor. Δεν περιγράφεται το πώς δουλεύει το σύστημα αλλά μόνο το τι κάνει. Δεν περιγράφονται στοιχεία της διεπαφής χρήστη, όπως και άλλα στοιχεία που αφορούν τη σχεδίαση του λογισμικού. Ένα σχετικά λιτό πρότυπο για την ουσιώδη περιγραφή περιπτώσεων χρήσης είναι το παρακάτω: 1. Όνομα Περίπτωσης χρήσης 2. Πρωτεύων Actor 3. Ενδιαφερόμενοι 4. Προϋποθέσεις 5. Βασική Ροή 6. Εναλλακτικές Ροές 2009 ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης

Βασική ροή: ”δανεισμός αντιτύπων”
1. Ο δανειζόμενος έρχεται στο βιβλιοθηκονόμο κρατώντας τα αντίτυπα των βιβλίων προς δανεισμό. 2. Ο βιβλιοθηκονόμος αναζητά τον δανειζόμενο. 3. Το Σύστημα παρουσιάζει τα στοιχεία του δανειζομένου. 4. Ο βιβλιοθηκονόμος αναζητά το αντίτυπο. 5. Το Σύστημα παρουσιάζει τα στοιχεία του αντιτύπου. 6. Ο βιβλιοθηκονόμος επιλέγει το αντίτυπο προς δανεισμό. 7. Το Σύστημα επιβεβαιώνει ότι ο δανειζόμενος μπορεί να δανειστεί το αντίτυπο. 8. Το Σύστημα καταχωρίζει το δανεισμό και εμφανίζει την προθεσμία επιστροφής. 9. Ο βιβλιοθηκονόμος ενημερώνει τον δανειζόμενο για την προθεσμία επιστροφής του αντιτύπου. Ο βιβλιοθηκονόμος επαναλαμβάνει τα βήματα 4 έως 9 για όλα τα αντίτυπα. 2009 ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης

Εναλλακτικές ροές: ”δανεισμός αντιτύπων”
* Σε οποιοδήποτε σημείο το λογισμικό καταρρέει. 1. Ο βιβλιοθηκονόμος εκκινεί το Σύστημα. 2. Το Σύστημα ταυτοποιεί το βιβλιοθηκονόμο. 3. Ο βιβλιοθηκονόμος εκκινεί το δανεισμό για τα εναπομείναντα αντίτυπα. 2α. Ο δανειζόμενος έρχεται για πρώτη φορά για δανεισμό. 1. Ο βιβλιοθηκονόμος επιβεβαιώνει ότι ο δανειζόμενος μπορεί να δανειστεί βιβλία από τη Βιβλιοθήκη. 1α. Ο δανειζόμενος δε δικαιούται να δανειστεί από τη Βιβλιοθήκη. 1. Ο δανεισμός τερματίζει. 2. Ο βιβλιοθηκονόμος καταχωρίζει τον δανειζόμενο στο σύστημα με τη Διαχείριση Δανειζομένου. 5α. Το Σύστημα δε βρίσκει το αντίτυπο του βιβλίου 1. Ο βιβλιοθηκονόμος κρατά το αντίτυπο για να διαπιστώσει το σφάλμα αργότερα. 2. Ο δανεισμός τερματίζει. 7α. Ο δανειζόμενος δεν μπορεί να δανειστεί βιβλία. 1. Ο βιβλιοθηκονόμος ενημερώνει το δανειζόμενο. 2. Κρατά τα εναπομείναντα αντίτυπα για να επιστρέψουν στα ράφια. 3. Ο δανεισμός τερματίζει. 2009 ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης

Σχέσεις περιπτώσεων χρήσης
Συμπερίληψη: Σε αρκετές περιπτώσεις τα βήματα που εκτελούνται σε μία περίπτωση χρήσης μπορεί να επαναλαμβάνονται στην εκτέλεση βημάτων κάποιας άλλης περίπτωσης χρήσης. Προκειμένου να αποφύγουμε την επανάληψη των βημάτων μπορούμε να εισάγουμε τη σχέση της συμπερίληψης (include) μεταξύ δύο περιπτώσεων χρήσης όπου μία περίπτωση χρήσης συμπεριλαμβάνει στις ροές των σεναρίων της, ροές μίας δεύτερης περίπτωσης χρήσης. 2009 ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης

Σχέση Συμπερίληψης Στα βήματα της περίπτωσης χρήσης Α συμπεριλαμβάνονται τα βήματα της περίπτωσης χρήσης Β Η Α αναφέρεται ως βασική και η Β ως συμπεριλαμβανόμενη (included) περίπτωση χρήσης 2009 ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης

Επέκταση Εκτός από τη συμπερίληψη υπάρχει και μία δεύτερη σχέση των περιπτώσεων χρήσης η σχέση της επέκτασης. Αυτή η σχέση υποδηλώνει ότι μία περίπτωση χρήσης Α επεκτείνει τη λειτουργικότητα μίας περίπτωσης χρήσης Β, χωρίς όμως η Β να το γνωρίζει. 2009 ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης

Σχέση Επέκτασης Η περίπτωση χρήσης Β επεκτείνει τη λειτουργικότητα της περίπτωσης χρήσης Α χωρίς η Α να το γνωρίζει Δεν γίνεται αναφορά στην περίπτωση χρήσης Β στο κείμενο της Α. Οι επεκτάσεις εισάγονται σε διαφορετική ενότητα που ονομάζεται «Σημεία Επέκτασης» 2009 ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης

Χρήση της σχέσης επέκτασης
Θέλουμε να τροποποιήσουμε μία περίπτωση χρήσης, χωρίς να αλλάξουμε το κείμενό της. Το τελικό προϊόν λογισμικού παράγεται σε παραπάνω από μία εκδόσεις, οι οποίες προσθέτουν λειτουργικότητα σε μία βασική έκδοση. Οι περιπτώσεις χρήσης της βασικής έκδοσης συντάσσονται αγνοώντας την πιθανή πρόσθετη λειτουργικότητα των εμπλουτισμένων εκδόσεων. Οι περιπτώσεις χρήσης των εμπλουτισμένων εκδόσεων συντάσσονται ως επεκτάσεις της λειτουργικότητας της βασικής έκδοσης. Υπάρχουν πολλά ασύγχρονα γεγονότα που μπορεί να διακόψουν τη ροή των βημάτων της περίπτωσης χρήσης. 2009 ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης

Διαφορές συμπερίληψης - επέκτασης
Στη συμπερίληψη, έχουμε σαφή αναφορά της συμπεριλαμβανόμενης περίπτωσης χρήσης στο κείμενο που περιγράφει τη βασική. Στη σχέση της επέκτασης η λειτουργικότητα της βασικής περίπτωσης χρήσης επεκτείνεται, χωρίς η ίδια να το γνωρίζει. Όταν χρησιμοποιείται η επέκταση, δε γίνεται κάποια αναφορά στα βήματα της βασικής περίπτωση χρήσης σε αυτή που την επεκτείνει. Οι επεκτάσεις στις περιγραφές των περιπτώσεων χρήσης περιγράφονται εκτός των βημάτων των ροών, σε ξεχωριστή ενότητα, ως σημεία επέκτασης (extension points). Ένα τελευταίο σημαντικό σημείο διαφοροποίησης της επέκτασης από τη συμπερίληψη είναι ότι η βασική περίπτωση χρήσης μπορεί να νοηθεί ανεξάρτητα από τις επεκτάσεις της. 2009 ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης

Σχέση Γενίκευσης Οι περιπτώσεις χρήσης B και C κληρονομούν τη συμπεριφορά της Α. Μπορούν να εξειδικεύσουν τα βήματα των ροών της Α. 2009 ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης

Παράδειγμα Use Case 2009 ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης

Παράδειγμα Διαγράμματος Χρήσης UML
Σωστό Λάθος 2009 ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης

Μοντέλο περιπτώσεων χρήσης
Μία συχνή παρεξήγηση είναι ότι το μοντέλο περιπτώσεων χρήσης είναι τα διαγράμματα περιπτώσεων χρήσης Το μοντέλο περιπτώσεων χρήσης (use case model) τεκμηριώνει το σύνολο των λειτουργικών απαιτήσεων του υπό ανάπτυξη συστήματος. Το μοντέλο περιπτώσεων χρήσης βασίζεται κυρίως στις περιγραφές των περιπτώσεων χρήσης οι οποίες γίνονται σε φυσική γλώσσα. Το μοντέλο περιπτώσεων χρήσης μπορεί βέβαια να περιλαμβάνει και διαγράμματα που αποσαφηνίζουν τις απαιτήσεις. Ένα μοντέλο περιπτώσεων χρήσης περιέχει κυρίως: • Τους actors του συστήματος. • Τις περιπτώσεις χρήσης. • Διαγράμματα περιπτώσεων χρήσης. • Άλλα διαγράμματα που θα προκύψουν από την ανάλυση των απαιτήσεων και τα οποία διευκολύνουν στη συνολικότερη κατανόηση των απαιτήσεων. 2009 ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης

Το πρόβλημα του Δανεισμού Βιβλίων
Στις επόμενες διαφάνειες: Περιγραφή της Εξαγωγής απαιτήσεων Μοντελοποίηση Περιπτώσεων Χρήσης 2009 ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης

ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης

Παρόμοιες παρουσιάσεις

Παρουσίαση με θέμα: "ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης"— Μεταγράφημα παρουσίασης:

Παρόμοιες παρουσιάσεις

Σχετικά με το έργο

Σχόλια

Είσοδος

Σύνδεση μέσω των κοινωνικών δικτύων:

ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης

Παρόμοιες παρουσιάσεις

Παρουσίαση με θέμα: "ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης"— Μεταγράφημα παρουσίασης:

Παρόμοιες παρουσιάσεις

Σχετικά με το έργο

Σχόλια