ΤΕΧΝΟΛΟΓΙΑ ΛΟΓΙΣΜΙΚΟΥ

Παρουσίαση με θέμα: "ΤΕΧΝΟΛΟΓΙΑ ΛΟΓΙΣΜΙΚΟΥ"— Μεταγράφημα παρουσίασης:

1 ΤΕΧΝΟΛΟΓΙΑ ΛΟΓΙΣΜΙΚΟΥ
ΠΡΟΔΙΑΓΡΑΦΕΣ ΑΠΑΙΤΗΣΕΩΝ 22 Νοεμβρίου 2007

2 Προδιαγραφές Απαιτήσεων
Εισαγωγή Περιεχόμενο Προδιαγραφών Απαιτήσεων Τρόποι Αναπαράστασης Προδιαγραφών Απαιτήσεων Περιπτώσεις Χρήσης και UML use case diagrams Ορισμός,Χειριστές (actors), σενάρια Αναπαράσταση Προδιαγραφών Απαιτήσεων με Σενάρια Περιπτώσεων Χρήσης, UML use case diagrams, Διαγράμματα Ροής Δεδομένων ή Activity Diagrams και συγκεκριμένες λεπτομερείς περιγραφές

3 Εισαγωγή (1/2) Οι προδιαγραφές απαιτήσεων
Είναι το πρώτο βήμα σε ένα έργο ανάπτυξης λογισμικού Όλες οι επόμενες φάσεις της ανάπτυξης του έργου ξεκινούν από αυτό το σημείο προδιαγράφουν ΤΙ θέλουν οι χρήστες και ΤΙ απαιτείται γιά να πετύχει το προτεινόμενο σύστημα είναι η βάση για το σχεδιασμό του συστήματος. δεν ασχολούνται με λεπτομέρειες της υλοποίησης εκτός από το σχετικά επιφανειακό επίπεδο της διαίρεσης εργασίας ανάμεσα σε υλικό, λογισμικό και χειριστή αλλά με το ΤΙ πρέπει να υλοποιηθεί.

4 Εισαγωγή (2/2) Είναι σημαντικό να προδιαγραφούν όλες οι απαιτήσεις
Αν μία απαίτηση δεν μπορεί να προδιαγραφεί, τότε δεν μπορεί να υλοποιηθεί Είναι απαραίτητη κάποια μορφή γραπτής επικοινωνίας μεταξύ της ομάδας υλοποίησης και της ομάδας αποτύπωσης των απαιτήσεων Όταν συμφωνηθούν μεταξύ του πελάτη και του προμηθευτή γίνονται το πρώτο συμφωνημένο έγγραφο, το πρώτο σημείο αναφοράς Είναι αναγκαίο να οριστούν τα όρια των προδιαγραφών απαιτήσεων

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

6 Τρόποι Αναπαράστασης των Προδιαγραφών Απαιτήσεων
Τρόποι Αναπαράστασης των Προδιαγραφών Απαιτήσεων Μπορούν να υιοθετηθούν διάφοροι τρόποι αναπαράστασής τους και διάφορες μεθοδολογίες. Είδαμε μερικούς στα παραρτήματα από το IEEE standard for requirements specifications Στη συνέχεια θα δούμε έναν από αυτούς που προτείνεται να χρησιμοποιήσετε στην εργασία σας. Ο τρόπος αυτός χρησιμοποιεί τις περιπτώσεις χρήσης, τα διαγράμματα use cases της UML και στη συνέχεια την περιγραφή λειτουργιών κλπ με ένα συγκεκριμένο τρόπο Πριν να δούμε αυτό τον συγκεκριμένο τρόπο, θα πούμε λίγα λόγια για τις περιπτώσεις χρήσης

7 Τι είναι οι περιπτώσεις χρήσης (use cases)
Mια τεχνική αποτύπωσης των λειτουργικών απαιτήσεων ενός συστήματος Περιγράφουν τις τυπικές αλληλεπιδράσεις μεταξύ των χρηστών (χειριστών) ενός συστήματος και του συστήματος Παρέχουν μια εξιστόρηση του τρόπου χρήσης του συστήματος

8 Τι είναι οι Χειριστές Χειριστής (actor) είναι ένας ρόλος που παίζει ένας χρήστης σε σχέση με το σύστημα Π.χ. Πελάτης, Διαχειριστής Οι χειριστές διεκπεραιώνουν περιπτώσεις χρήσης Ένας χειριστής μπορεί να εμπλέκεται σε πολλές περιπτώσεις χρήσεις, και αντίστροφα Ένας χρήστης μπορεί να παίζει περισσότερους από έναν ρόλους Ένας χειριστής δεν είναι απαραίτητα άνθρωπος Μπορεί να είναι κάποιο περιφερειακό (π.χ. Εκτυπωτής), πρόγραμμα, οργανισμός κλπ

9 Κατηγορίες χειριστών Πρωτεύοντες χειριστές Δευτερεύοντες χειριστές
Είναι αυτοί που καλούν το σύστημα για την παροχή μιας υπηρεσίας Συνήθως, αλλά όχι πάντα, είναι αυτοί που ξεκινούν μια περίπτωση χρήσης Η περίπτωση χρήσης προσπαθεί να εκπληρώσει το στόχο τους Δευτερεύοντες χειριστές Το σύστημα επικοινωνεί μαζί τους, ενώ διεκπεραιώνει μια περίπτωση χρήσης

10 Περιγραφή περιπτώσεων χρήσης
Με χρήση Σεναρίων Η χρήση σεναρίων είναι μια δημοφιλής τεχνική για την περιγραφή περιπτώσεων χρήσης Ένα σενάριο (scenario) είναι μια ακολουθία βημάτων που περιγράφουν την αλληλεπίδραση ενός χρήστη με το σύστημα Η περιγραφή των περιπτώσεων χρήσης με τη χρήση σεναρίων βοηθά στη σωστή ανάπτυξή τους

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

12 Εναλλακτικά Σενάρια Αφορούν σε υπο-περιπτώσεις του αρχικού σεναρίου, που προκύπτουν κάτω από συγκεκριμένες συνθήκες Έχουν τον ίδιο στόχο με το αρχικό σενάριο Παραδείγματα εναλλακτικών σεναρίων στην «Αγορά Προϊόντος» Η επαλήθευση των στοιχείων της πιστωτικής κάρτας μπορεί να αποτύχει Οι τακτικοί πελάτες δε χρειάζεται να δίνουν με κάθε αγορά τα στοιχεία αποστολής, ούτε αυτά της πιστωτικής τους κάρτας

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

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

15 Παράδειγμα: Αγορά προϊόντος
Κύριο σενάριο επιτυχίας Ο πελάτης ξεφυλλίζει τον κατάλογο κι επιλέγει προϊόντα για αγορά Ο πελάτης πηγαίνει στη σελίδα εξόδου Ο πελάτης συμπληρώνει τα στοιχεία αποστολής Το σύστημα παρουσιάζει τις πλήρεις πληροφορίες τιμολόγησης, μαζί με τα έξοδα αποστολής Ο πελάτης συμπληρώνει τα στοιχεία της πιστωτικής του κάρτας Το σύστημα εγκρίνει την αγορά Το σύστημα επιβεβαιώνει αμέσως την πώληση Το σύστημα στέλνει μήνυμα επιβεβαίωσης μέσω ηλεκτρονικού ταχυδρομείου

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

17 Εύρεση Επεκτάσεων Προκύπτουν από την ίδια τη δομή της περίπτωσης χρήσης Για κάθε βήμα του ΚΣΕ Πώς μπορεί αυτό να εξελιχθεί διαφορετικά; Πώς μπορεί να αποτύχει; Είναι προτιμότερο να εξετάζονται πρώτα όλες οι συνθήκες των επεκτάσεων, πριν εξεταστούν οι συνέπειές τους

18 Παράδειγμα: Αγορά προϊόντος
Κύριο σενάριο επιτυχίας Ο πελάτης ξεφυλλίζει τον κατάλογο κι επιλέγει προϊόντα για αγορά Ο πελάτης πηγαίνει στη σελίδα εξόδου Ο πελάτης συμπληρώνει τα στοιχεία αποστολής Το σύστημα παρουσιάζει τις πλήρεις πληροφορίες τιμολόγησης, μαζί με τα έξοδα αποστολής Ο πελάτης συμπληρώνει τα στοιχεία της πιστωτικής του κάρτας Το σύστημα εγκρίνει την αγορά Το σύστημα επιβεβαιώνει αμέσως την πώληση Το σύστημα στέλνει μήνυμα επιβεβαίωσης μέσω ηλεκτρονικού ταχυδρομείου

19 Παράδειγμα: Αγορά προϊόντος
Επεκτάσεις 3α. Ο πελάτης είναι τακτικός πελάτης Το σύστημα παρουσιάζει τις τρέχουσες πληροφορίες για τη διεύθυνση αποστολής, την τιμολόγηση και τη χρέωση Ο πελάτης ενδέχεται να αποδεχθεί ή να αναθεωρήσει αυτές τις πληροφορίες. Επιστροφή στο βήμα 6 του ΚΣΕ 6α. Το σύστημα αποτυγχάνει να εγκρίνει την αγορά μέσω πιστωτικής κάρτας Ο πελάτης μπορεί να καταχωρήσει πάλι τα στοιχεία της πιστωτικής του κάρτας, ή να κάνει ακύρωση

20 Επιπλέον πληροφορίες στην περιγραφή σεναρίων
Επιπλέον πληροφορίες στην περιγραφή σεναρίων Συνθήκη Εισόδου (pre-condition) Περιγράφει τί πρέπει να επαληθεύσει το σύστημα ότι ισχύει, πριν επιτρέψει την εκκίνηση μιας περίπτωσης χρήσης Εγγύηση (guarantee) Περιγράφει τί θα εξασφαλίζει το σύστημα στο τέλος της περίπτωσης χρήσης Εγγυήσεις επιτυχίας: ισχύουν πάντα μετά από ένα επιτυχημένο σενάριο Ελάχιστες εγγυήσεις: ισχύουν μετά από κάθε σενάριο Σκανδάλη (trigger) Καθορίζει το συμβάν που αποτελεί αφορμή εκκίνησης της περίπτωσης χρήσης

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

22 Σύνδεσμος Επικοινωνίας
Βασικά Σύμβολα Σύμβολο Περιγραφή Χειριστής Σχέση Συμπερίληψης Περίπτωση Χρήσης Σύνδεσμος Επικοινωνίας Όριο Συστήματος Σχόλιο «include» Όνομα Περίπτωσης Χρήσης

23 Παράδειγμα: Αγορά Προϊόντος
Συμπλήρωση Στοιχείων Αποστολής Πιστωτικής Κάρτας Έγκριση Αγοράς Επιβεβαίωση Πώλησης Αποστολή Επιβεβαίωσης Επιλογή Προϊόντος «include» Πελάτης

24 Για Περισσότερες Πληροφορίες για τη UML και τα Use Case Diagrams...
... ανατρέξτε στις διαφάνειες του μαθήματος ΑΝΑΛΥΣΗ ΣΥΣΤΗΜΑΤΩΝ που βρίσκονται στο eclass

25 Προτεινόμενη Μεθοδολογία για Ανάλυση Λειτουργικών Απαιτήσεων με Περιπτώσεις Χρήσης και UML (1/3)
Σ’ αυτη τη μεθοδολογία, χρησιμοποιούμε τις περιπτώσεις χρήσης (use cases) για να: δώσουμε μια «εξιστόρηση» του τρόπου χρήσης του συστήματος Ορίσουμε τα όρια του συστήματος κατανοήσουμε τις βασικές λειτουργικές απαιτήσεις προσδιορίσουμε τους χειριστές του συστήματος δώσουμε μια αρχική, υψηλού επιπέδου προδιαγραφή της χρήσης του συστήματος Στη συνέχεια συνεχίζουμε την ανάλυση απαιτήσεων είτε με τεχνικές της Δομημένης Ανάλυσης είτε με UML

26 Bήματα της Προτεινόμενης Μεθοδολογίας
Προτεινόμενη Μεθοδολογία για Ανάλυση Λειτουργικών Απαιτήσεων με Περιπτώσεις Χρήσης και UML (2/3) Bήματα της Προτεινόμενης Μεθοδολογίας Βήμα 1: Σύντομη περιγραφή της λειτουργίας του συστήματος με τη χρήση κειμένου σε φυσική γλώσσα Βήμα 2: Αναγνώριση των βασικών περιπτώσεων χρήσης Βήμα 3: Για κάθε μια από τις περιπτώσεις χρήσης Καταγραφή των αλληλεπιδράσεων χρήστη-συστήματος με τη χρήση κυρίων σεναρίων επιτυχίας (ΚΣΕ) Καταγραφή εναλλακτικών συμπεριφορών ή/και επεκτάσεων (π.χ. αντιμετώπιση εξαιρέσεων, σφαλμάτων, κτλ.) με τη χρήση εναλλακτικών σεναρίων Βήμα 4: Γραφική αναπαράσταση όλων των βασικών περιπτώσεων χρήσης, καθώς και των χειριστών, με τη χρήση UML διαγραμμάτων Use Cases

27 Προτεινόμενη Μεθοδολογία για Ανάλυση Λειτουργικών Απαιτήσεων με Περιπτώσεις Χρήσης και UML (3/3)
Βήμα 5: Διαγραμματική Περιγραφή των Use Cases με Διαγράμματα Ροής Δεδομένων σε Επίπεδα (γιά όσους ακολουθήσουν τη Δομημένη Ανάλυση) ή με Διαγράμματα Δραστηριοτήτων (γιά όσους ακολουθήσουν την Αντικειμενοστραφή Ανάλυση με UML) Βήμα 6: Περιγραφή (με τον τρόπο που αναλύεται παρακάτω) των λειτουργιών που έχουν εντοπιστεί στο προηγούμενο βήμα είτε στα Διαγράμματα Ροής Δεδομένων ως στοιχειώδεις διαδικασίες (δηλ. διαδικασίες που δεν αναλύονται περαιτέρω), είτε σαν tasks στα Διαγράμματα Δραστηριοτήτων Βήμα 7:Καταγραφή των απαιτήσεων για User Interface Βήμα 7:Κατασκευή του διαγράμματος Οντοτήτων-Συσχετίσεων (γιά όσους ακολουθούν τη Δομημένη Ανάλυση) ή Διαγράμματος Κλάσεων (γιά όσους ακολουθούν Αντικειμενοστραφή Ανάλυση)

28 Παράδειγμα ΕΝΑ ΣΥΣΤΗΜΑ ΠΟΥ ΘΑ ΕΠΙΤΡΕΠΕΙ ΤΗΝ ΑΠΟΘΗΚΕΥΣΗ ΚΑΙ ΑΝΑΚΤΗΣΗ ΟΝΟΜΑΤΩΝ ΚΑΙ ΑΡΙΘΜΩΝ ΤΗΛΕΦΩΝΟΥ

29 Βήμα 1 Σύντομη περιγραφή της λειτουργίας του συστήματος με τη χρήση φυσικού κειμένου ΕΝΑ ΣΥΣΤΗΜΑ ΕΥΡΕΤΗΡΙΟΥ ΤΗΛΕΦΩΝΩΝ ΕΝΟΣ ΧΡΗΣΤΗ, ΒΑΣΙΣΜΕΝΟ ΣΕ ΔΙΣΚΟ ΠΟΥ ΘΑ ΥΠΟΣΤΗΡΙΖΕΙ ΤΗΝ ΑΠΟΘΗΚΕΥΣΗ ΚΑΙ ΑΝΑΚΤΗΣΗ ΟΝΟΜΑΤΩΝ ΚΑΙ ΑΡΙΘΜΩΝ ΤΗΛΕΦΩΝΟΥ. ΠΡΕΠΕΙ ΝΑ ΠΡΟΣΦΕΡΟΝΤΑΙ ΤΡΕΙΣ ΒΑΣΙΚΕΣ ΛΕΙΤΟΥΡΓΙΕΣ: ΠΡΟΣΘΗΚΗ ΝΕΩΝ ΑΝΤΙΚΕΙΜΕΝΩΝ ΣΤΟ ΕΥΡΕΤΗΡΙΟ, ΤΡΟΠΟΠΟΙΗΣΗ ΥΠΑΡΧΟΝΤΩΝ ΑΝΤΙΚΕΙΜΕΝΩΝ, ΚΑΙ ΑΝΑΖΗΤΗΣΗ ΣΤΟ ΕΥΡΕΤΗΡΙΟ ΕΝΟΣ ΑΝΤΙΚΕΙΜΕΝΟΥ ΠΟΥ ΔΙΝΕΤΑΙ ΠΡΕΠΕΙ ΝΑ ΕΝΣΩΜΑΤΩΘΟΥΝ ΜΗΧΑΝΙΣΜΟΙ ΠΛΗΡΟΥΣ ΕΠΙΚΥΡΩΣΗΣ ΤΩΝ ΔΕΔΟΜΕΝΩΝ ΚΑΙ ΧΕΙΡΙΣΜΟΥ ΛΑΘΩΝ.

30 Αναγνώριση των βασικών περιπτώσεων χρήσης
Βήμα 2 Αναγνώριση των βασικών περιπτώσεων χρήσης ΕΝΑ ΣΥΣΤΗΜΑ ΕΥΡΕΤΗΡΙΟΥ ΤΗΛΕΦΩΝΩΝ ΕΝΟΣ ΧΡΗΣΤΗ, ΒΑΣΙΣΜΕΝΟ ΣΕ ΔΙΣΚΟ ΠΟΥ ΘΑ ΥΠΟΣΤΗΡΙΖΕΙ ΤΗΝ ΑΠΟΘΗΚΕΥΣΗ ΚΑΙ ΑΝΑΚΤΗΣΗ ΟΝΟΜΑΤΩΝ ΚΑΙ ΑΡΙΘΜΩΝ ΤΗΛΕΦΩΝΟΥ. ΠΡΕΠΕΙ ΝΑ ΠΡΟΣΦΕΡΟΝΤΑΙ ΤΡΕΙΣ ΜΕΓΑΛΕΣ ΛΕΙΤΟΥΡΓΙΕΣ: ΠΡΟΣΘΗΚΗ ΝΕΩΝ ΑΝΤΙΚΕΙΜΕΝΩΝ ΣΤΟ ΕΥΡΕΤΗΡΙΟ ΤΡΟΠΟΠΟΙΗΣΗ ΥΠΑΡΧΟΝΤΩΝ ΑΝΤΙΚΕΙΜΕΝΩΝ, ΚΑΙ ΑΝΑΖΗΤΗΣΗ ΣΤΟ ΕΥΡΕΤΗΡΙΟ ΕΝΟΣ ΑΝΤΙΚΕΙΜΕΝΟΥ ΠΟΥ ΔΙΝΕΤΑΙ ΠΡΕΠΕΙ ΝΑ ΕΝΣΩΜΑΤΩΘΟΥΝ ΜΗΧΑΝΙΣΜΟΙ ΠΛΗΡΟΥΣ ΕΠΙΚΥΡΩΣΗΣ ΤΩΝ ΔΕΔΟΜΕΝΩΝ ΚΑΙ ΧΕΙΡΙΣΜΟΥ ΛΑΘΩΝ

31 Βήμα 3 Κύριο Σενάριο Επιτυχίας
Καταγραφή αλληλεπιδράσεων χρήστη-συστήματος με τη χρήση σεναρίων Κύριο Σενάριο Επιτυχίας για την ΠΡΟΣΘΗΚΗ Ο χρήστης εισέρχεται στο σύστημα Ο χρήστης πληκτρολογεί την τιμή του πεδίου ΟΝΟΜΑ της νέας εγγραφής Ο χρήστης πληκτρολογεί την τιμή του πεδίου ΤΗΛΕΦΩΝΟ της νέας εγγραφής Ο χρήστης επιλέγει την αποθήκευση της εγγραφής Το σύστημα ενημερώνει το χρήστη σχετικά με την επιτυχή προσθήκη στη ΒΔ Ο χρήστης εξέρχεται από το σύστημα

32 Βήμα 3 Εναλλακτικά Σενάρια Επιτυχίας
Βήμα 3 Εναλλακτικά Σενάρια Επιτυχίας Καταγραφή εναλλακτικών συμπεριφορών ή/και επεκτάσεων (π.χ. αντιμετώπιση εξαιρέσεων, σφαλμάτων, κτλ.) με τη χρήση εναλλακτικών σεναρίων Εναλλακτικά Σενάρια για την ΠΡΟΣΘΗΚΗ 5α. Η τιμή του πεδίου ΤΗΛΕΦΩΝΟ περιλαμβάνει μή αριθμητικούς χαρακτήρες Το σύστημα ενημερώνει το χρήστη σχετικά με την λανθασμένη τιμή. Επιστροφή στο βήμα 3 του ΚΣΕ 5β. Η τιμή του πεδίου ΟΝΟΜΑ είναι κενή Το σύστημα ενημερώνει το χρήστη σχετικά με την κενή τιμή. Επιστροφή στο βήμα 2 του ΚΣΕ

33 Γραφική Αναπαράσταση των Περιπτώσεων Χρήσης με UML
Βήμα 4 Γραφική Αναπαράσταση των Περιπτώσεων Χρήσης με UML

34 Βήμα 5 Εδώ γίνεται διαγραμματική αναπαράσταση των περιπτώσεων χρήσης είτε με Διαγράμματα Ροής Δεδομένων σε επίπεδα, μέχρι να καταλήξουμε σε στοιχειώδεις διαδικασίες που θεωρούμε ότι είναι οι στοιχειώδεις λειτουργίες που θα περιγραφούν στη συνέχεια με λεπτομέρειες Είτε με Διαγράμματα Δραστηριοτήτων, τα οποία μας βοηθούν να εντοπίσουμε τις στοιχειώδεις λειτουργίες οι οποίες περιγράφονται λεπτομερώς στη συνέχεια

35 Βήμα 6 Περαιτέρω ανάλυση με την καταγραφή των προδιαγραφών απαιτήσεων, έτσι όπως αναφέραμε στην αρχή. Δηλαδή, η καταγραφή θα πρέπει να περιλαμβάνει τις λειτουργικές και μη-λειτουργικές απαιτήσεις και συγκεκριμένα: Λειτουργίες: από το «μάτι του χρήστη» Κατανομή των λειτουργιών: περιγραφή και κατανομή των ευθυνών για τις ορισμένες λειτουργίες σε λογισμικό, υλικό και χειριστή Περιορισμοί: όρια στη λειτουργία του συστήματος και βαθμός σπουδαιότητάς τους Πρότυπα: τεχνικές που θα εφαρμοστούν κατά την ανάπτυξη του συστήματος Ποιότητα: Λεπτομέρειες των διαδικασιών ελέγχου της ποιότητας με τις οποίες θα παρακολουθείται και θα ελέγχεται η πρόοδος και η ποιότητα του έργου. Χρονοδιάγραμμα: Στόχοι ανάπτυξης - τι αναμένεται να είναι έτοιμο πότε.

36 Τρόπος περιγραφής λειτουργιών 1/8
Για κάθε λειτουργία που έχει εντοπιστεί είτε στο τελευταίο επίπεδο των διαγραμμάτων ροής δεδομένων είτε σαν task στο activity diagram θα πρέπει να παρέχονται: Τύπος της πληροφορίας εισόδου & μέσα εισόδου Λεπτομέρειες της επεξεργασίας:έλεγχος των δεδομένων εισόδου, τροποποίηση, ψάξιμο, πληροφορίες όπως ελάχιστα μήκη για αντικείμενα χαρακτήρων και βαθμός ακριβείας για αριθμητικούς υπολογισμούς. Η επεξεργασία περιγράφεται με Activity Diagrams ή με πίνακες αποφάσεων/δέντρα αποφάσεων ή δομημένα Αγγλικά. Τύπος της πληροφορίας εξόδου & μέσα εξόδου Στοιχεία που πρέπει να αποτρέπει το σύστημα και ο τρόπος αναφοράς της ανίχνευσης τους (πχ. Μηνύματα λάθους) Φόρτος που πρέπει να διαχειρίζεται το σύστημα Ταχύτητα λειτουργιών Γιά όλο το σύστημα δίνουμε πληροφορίες για Επαναδιαμόρφωση ή επεκτάσεις Απαιτούμενη διαθεσιμότητα του συστήματος & όρια αξιοπιστίας (πχ. Συνεχώς διαθέσιμο, αποδεκτή συχνότητα και διάρκεια βλαβών) Απαιτήσεις για αποδοχή του ολοκληρωμένου συστήματος

37 Τρόπος περιγραφής λειτουργιών 2/8
Θα δώσουμε ένα παράδειγμα περιγραφής με βάση την προηγούμενη διαφάνεια χρησιμοποιώντας το ίδιο παράδειγμα που περιγράψαμε με σενάρια και use cases: ΕΝΑ ΣΥΣΤΗΜΑ ΕΥΡΕΤΗΡΙΟΥ ΤΗΛΕΦΩΝΩΝ ΕΝΟΣ ΧΡΗΣΤΗ, ΒΑΣΙΣΜΕΝΟ ΣΕ ΔΙΣΚΟ ΠΟΥ ΘΑ ΥΠΟΣΤΗΡΙΖΕΙ ΤΗΝ ΑΠΟΘΗΚΕΥΣΗ ΚΑΙ ΑΝΑΚΤΗΣΗ ΟΝΟΜΑΤΩΝ ΚΑΙ ΑΡΙΘΜΩΝ ΤΗΛΕΦΩΝΟΥ. ΠΡΕΠΕΙ ΝΑ ΠΡΟΣΦΕΡΟΝΤΑΙ ΤΡΕΙΣ ΜΕΓΑΛΕΣ ΛΕΙΤΟΥΡΓΙΕΣ: ΠΡΟΣΘΗΚΗ ΝΕΩΝ ΑΝΤΙΚΕΙΜΕΝΩΝ ΣΤΟ ΕΥΡΕΤΗΡΙΟ ΤΡΟΠΟΠΟΙΗΣΗ ΥΠΑΡΧΟΝΤΩΝ ΑΝΤΙΚΕΙΜΕΝΩΝ, ΚΑΙ ΑΝΑΖΗΤΗΣΗ ΣΤΟ ΕΥΡΕΤΗΡΙΟ ΕΝΟΣ ΑΝΤΙΚΕΙΜΕΝΟΥ ΠΟΥ ΔΙΝΕΤΑΙ ΠΡΕΠΕΙ ΝΑ ΕΝΣΩΜΑΤΩΘΟΥΝ ΜΗΧΑΝΙΣΜΟΙ ΠΛΗΡΟΥΣ ΕΠΙΚΥΡΩΣΗΣ ΤΩΝ ΔΕΔΟΜΕΝΩΝ ΚΑΙ ΧΕΙΡΙΣΜΟΥ ΛΑΘΩΝ

38 Τρόπος περιγραφής λειτουργιών 3/8
Μέσα Εισόδου Το μέσο εισόδου που θα χρησιμοποιηθεί για όλες τις λειτουργίες είναι το πληκτρολόγιο. Πληροφορίες που θα εισάγονται Οι πληροφορίες θα πρέπει να δίνονται στο σύστημα από το χρήστη ως ακολούθως: ΠΡΟΣΘΗΚΗ : όνομα και αριθμός τηλεφώνου ΤΡΟΠΟΠΟΙΗΣΗ : όνομα ή αριθμός τηλεφώνου της εγγραφής που θα τροποποιηθεί, ακολουθούμενα από τις λεπτομέρειες των αλλαγών που θα γίνουν ΑΝΑΖΗΤΗΣΗ : όνομα ή αριθμός τηλεφώνου για το οποίο θα γίνει η αναζήτηση

39 Τρόπος περιγραφής λειτουργιών 4/8
Επεξεργασία: Η επεξεργασία περιγράφεται με Activity Diagrams ή με πίνακες αποφάσεων/δέντρα αποφάσεων ή δομημένα Αγγλικά. Το παράδειγμα είναι απλό γι αυτό χρησιμοποιούμε απλή φυσική γλώσσα. Προσθήκη:εγγραφή στη βάση Τροποποίηση: εγγραφή στη βάση με παράλληλη διαγραφή της αρχικής εγγραφής Αναζήτηση:ανακτάται η εγγραφή με όνομα/αριθμό τηλεφώνου Ακρίβεια: Συγκρίσεις συμβολοσειρών δεδομένων εισόδου με αποθηκευμένου αντικειμένου Η επεξεργασία περιγράφεται με Activity Diagrams ή με πίνακες αποφάσεων/δέντρα αποφάσεων ή δομημένα Αγγλικά Μέσα εξόδου: οθόνη ή εκτυπωτής Πληροφορίες που θα εξάγονται: ΠΡΟΣΘΗΚΗ : Μια ένδειξη ότι η λειτουργία διεξήχθη επιτυχώς ΤΡΟΠΟΠΟΙΗΣΗ : Μια ένδειξη ότι η αρχική εγγραφή έχει τροποποιηθεί επιτυχώς, μαζί με επιβεβαίωση του περιεχομένου της τροποποιημένης εγγραφής. ΑΝΑΖΗΤΗΣΗ : Όνομα και αριθμός τηλεφώνου από κάθε εγγραφή που ταιριάζει με τη συμβολοσειρά αναζήτησης που δόθηκε. Αν το μέσο εξόδου είναι η οθόνη, τότε πρέπει να δοθεί έλεγχος στον χρήστη για να επιτραπεί έξοδος ενός βήματος.

40 Λειτουργίες 5/8 Αναγνώριση λαθών του συστήματος
Ανίχνευση και αναφορά στο χρήστη Βλάβες κατά τη μεταφορά δεδομένων απο/προς το δίσκο: πρέπει να γίνει επανάληψη και μόνο μετά από επανειλημένη αποτυχία θα εμφανίζεται λάθος. Σε όλες τις περιπτώσεις πρέπει να διατηρείται η ακεραιότητα της βάσης δεδομένων. Στην περίπτωση που η βάση γίνει 75% γεμάτη πρέπει να παρέχεται μια προειδοποίηση Αναγνώριση λαθών του χρήστη: Εμφάνιση μηνύματος λάθους. Η διόρθωση μιας λανθασμένης κατάστασης από τον χρήστη πρέπει φυσιολογικά να μην απαιτεί να επαναεισάγονται τα έγκυρα δεδομένα. Θα πρέπει να είναι δυνατό για τον χρήστη να εγκαταλείψει κάθε λειτουργία καθώς αυτή εκτελείται, με την ακεραιότητα της βάσης να διατηρείται. Λάθη κατά την προσθήκη, τροποποίηση και αναζήτηση.

41 Λειτουργίες 6/8 Φόρτος Συστήματος:
Το σύστημα θα πρέπει να μπορεί να υποστηρίξει έως . .x. . τερματικά [σύστημα πολλών χρηστών (multi user)] Απόδοση (ταχύτητα): Χρόνος απόκρισης για ταυτόχρονη λειτουργία χχ τερματικών ΠΡΟΣΘΗΚΗ: μέσος όρος. .x. . δευτερόλεπτα, μέγιστο . .x. . δευτερόλεπτα

42 Λειτουργίες 7/8 7. Επέκταση/Επαναδιαμόρφωση: Αύξηση . .x. .% των αποθηκευμένων ονομάτων/ αριθμών τηλεφώνου. Αύξηση . .x. .% στην ορισμένη χρήση των λειτουργιών ανά ώρα, ομοιόμορφα κατανεμημένη σε όλες τις λειτουργίες. Αύξηση . .x. . τερματικών σε ταυτόχρονη λειτουργία [πολλοί χρήστες] Επομένως: Πρέπει να υπάρχει επαρκής διαθέσιμη χωρητικότητα όσον αφορά την κύρια και δευτερεύουσα αποθήκευση και επαρκής ισχύ του επεξεργαστή για να εξυπηρετήσει μια επέκταση τέτοιου μεγέθους (μπορούν να δίνονται νούμερα)

43 Λειτουργίες 8/8 Διαθεσιμότητα συστήματος: 24-ωρη, 7-ήμερη βάση
ανάκαμψη από μια ολοκληρωτική πτώση το πολύ σε 5 λεπτά Παράλληλη λειτουργία backup με την κανονική λειτουργία του συστήματος Αποδοχή σε 3 φάσεις: τυπικοί έλεγχοι εγκατάστασης του προμηθευτή ο πελάτης θα εκτελέσει τον έλεγχο αποδοχής του συστήματος σύμφωνα με τις προαδιαγραφές χρήση του συστήματος για 2 μήνες για να αποφασιστεί ότι μπορεί να εξασφαλιστεί ένα 99% ποσοστό της αδιάλειπτης λειτουργίας του συστήματος (δηλ. χωρίς πτώση).

44 Κατανομή Λειτουργιών 1/2
Η κατανομή λειτουργιών γίνεται σε υλικό, λογισμικό και χειριστή ΥΛΙΚΟ Ολόκληρη η βάση δεδομένων να είναι on-line Αποτυχία μιας πρόσβασης στο δίσκο προκαλεί έναν κώδικα λάθους ανιχνεύσιμου από το λογισμικό ο οποίος θα του δώσει τη δυνατότητα να ενεργοποιήσει διορθωτική ενέργεια ή ενέργεια ανάκαμψης, και μια οπτική/ακουστική προειδοποίηση στο χειριστή στην περίπτωση οποιουδήποτε λάθους που μπορεί να επιδιορθωθεί με την παρέμβαση του

45 Κατανομή Λειτουργιών 2/2
ΛΟΓΙΣΜΙΚΟ Η επεξεργασία των δεδομένων εισόδου και η παραγωγή εξόδου αναμένεται να εκτελεστεί από λογισμικό που φορτώνεται από εξωτερικό μέσο. Ωστόσο, οι εργασίες της ανάγνωσης/επικύρωσης των δεδομένων εισόδου, και η δημιουργία απεικονίσεων εξόδου, μπορούν να εκτελεστούν από ένα συνδυασμό φορτωμένου λογισμικού και firmware Απαιτήσεις για αρχεία δεδομένων: Χρήση βάσης δεδομένων που θα παραδοθεί μαζί με το σύστημα

46 Περιορισμοί 1/3 Τεχνικοί και διαχειριστικοί περιορισμοί
Τυπικές κατηγορίες περιλαμβάνουν: Περιβάλλον: θερμοκρασία, επίπεδο υγρασίας κλπ Πόροι, απαιτούμενη διαθέσιμη χωρητικότητα χρόνου/μνήμης ΚΜΕ (Cpu time/memory) Χρονοδιάγραμμα, προθεσμίες, σημεία προόδου κλπ Κόστος (όχι περισσότερο από € )

47 Περιορισμοί 2/3 Παραδείγματα:
Όταν η on-line βάση δεδομένων έχει εκκινηθεί, το 50% του διαθέσιμου χώρου του δίσκου θα πρέπει να παραμείνει αχρησιμοποίητο, έτσι ώστε να εξυπηρετήσει μελλοντική επέκταση. Το υλοποιημένο σύστημα θα πρέπει να παραδοθεί μέσα σε 12 μήνες από την ημερομηνία του συμβολαίου. Ο προϋπολογισμός γι’ αυτό το έργο είναι €.

48 Περιορισμοί 3/3 Παράδειγμα επιπέδου περιορισμού:
Ελαστικός περιορισμός: Όταν η on-line βάση δεδομένων έχει εκκινηθεί, περίπου 50% (και όχι λιγότερο από 40%) του διαθέσιμου χώρου του δίσκου θα πρέπει να παραμείνει αχρησιμοποίητο, έτσι ώστε να εξυπηρετήσει μελλοντική επέκταση.

49 Πρότυπα Δηλώνουν τον τρόπο εργασίας του σχεδιαστή/αναλυτή συστημάτων/προγραμματιστή Παραδείγματα: Μεθοδολογία Συλλογής Απαιτήσεων, Ανάλυσης, Σχεδιασμού Εργαλεία για καταγραφή απαιτήσεων, ανάλυση, σχεδιασμό, περιβάλλον ανάπτυξης Προγραμματιστική γλώσσα Ελευθερία δράσης: μη ύπαρξη προτύπων στις προδιαγραφές

50 Ποιότητα 1/3 Απαιτήσεις για έλεγχο και εξασφάλιση ποιότητας
Παράδειγμα: «ο προμηθευτής θα πρέπει να ορίσει τον Κώδικα Πρακτικής τον οποίο θα ακολουθήσει....» «θα κάνουμε ό,τι κάνουμε πάντα»

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

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

53 Χρονοδιάγραμμα Παράδοση του συστήματος απαιτείται μέσα σε 12 μήνες από την υπογραφή του συμβολαίου

54 Επικύρωση απαιτήσεων 1/2
Στόχοι της επικύρωσης απαιτήσεων : Να εξασφαλίσουν ότι οι προδιαγραφές είναι πλήρεις Να εξασφαλίσουν ότι οι προδιαγραφές είναι συνεπείς πχ για μια λειτουργία ΠΡΟΣΘΗΚΗ, ένα όνομα και ένας αριθμός τηλεφώνου θα είναι είσοδος. Αν η λειτουργία ΤΡΟΠΟΠΟΙΗΣΗ που ακολουθεί είχε προσδιορίσει την είσοδο του ονόματος ή της διεύθυνσης του αντικειμένου που επρόκειτο να τροποποιηθεί, οι δύο απαιτήσεις θα ήταν ασυνεπείς Να εξασφαλίζουν ότι οι προδιαγραφές είναι ρεαλιστικές: Η ΑΝΑΖΗΤΗΣΗ να πρέπει να βρίσκει έναν αριθμό τηλεφώνου ενός ονόματος που ο δε μπορεί να θυμηθεί χρήστης

55 Επικύρωση απαιτήσεων 1/2
Η επικύρωση των απαιτήσεων γίνεται ένας μεγάλος πονοκέφαλος όταν οι απαιτήσεις αυτές προσδιορίζονται σε φυσική γλώσσα. Παράδειγμα: «Όλες οι συγκρίσεις συμβολοσειρών πρέπει να γίνονται χρησιμοποιώντας ολόκληρο το αντικείμενο δεδομένων σαν είσοδο από τον χρήστη. Η σύγκριση κρίνεται ως επιτυχής αν αυτή η συμβολοσειρά ταιριάζει με τους χαρακτήρες του αποθηκευμένου αντικειμένου.» Τι γίνεται εάν το αποθηκευμένο όνομα είναι ΠΑΠΑΓΕΩΡΓΑΚΟΠΟΥΛΟΣ; Για να επιτευχθεί επικύρωση θα πρέπει να εφαρμοστεί ένας στενά ορισμένος συμβολισμός αναπαράστασης των απαιτήσεων

56 Επικύρωση απαιτήσεων 2/2
Ορισμός <αντικείμενο δεδομένων> ορίζεται_ως (<όνομα> Ή <αριθμός τηλεφώνου>) ΚΑΙ ΟΧΙ <κενό> ΛΕΙΤΟΥΡΓΙΑ ΑΝΑΖΗΤΗΣΗΣ ΕΙΣΑΓΩΓΗ <αντικείμενο δεδομένων του χρήστη> ΑΝ <αντικείμενο δεδομένων του χρήστη> είναι_ένα <αντικείμενο δεδομένων> ΤΟΤΕ όλοι_οι_χαρακτήρες_του <αντικείμενο δεδομένων του χρήστη> = αρχικοί_χαρακτήρες_του <αντικείμενο βάσης> σύγκριση_εντάξει ΑΛΛΙΩΣ ανάφερε_ένα_λάθος