Η παρουσίαση φορτώνεται. Παρακαλείστε να περιμένετε

Η παρουσίαση φορτώνεται. Παρακαλείστε να περιμένετε

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

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


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

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

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

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

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

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

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

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

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

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

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

11 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης11 ΕΠΑΣ (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 Σενάρια λειτουργίας

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

50 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης50 Παράδειγμα Use Case cs.gordon.edu/local/courses/cs211 /ATMExample/Intro.html

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

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

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


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

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


Διαφημίσεις Google