Σχεδίαση Συστήματος Λογισμικού

Transcript

1 Πανεπιστήμιο Πειραιά Τμήμα Ψηφιακών Συστημάτων Τεχνολογία Λογισμικού 11/12/2017 Δρ. Ανδριάνα Πρέντζα Αναπληρώτρια Καθηγήτρια Πανεπιστήμιο Πειραιά Τμήμα Ψηφιακών Συστημάτων Σχεδίαση Συστήματος Λογισμικού 1

2 Εισαγωγή Από τη φάση προδιαγραφής των απαιτήσεων γνωρίζουμε τι θα κάνει το λογισμικό και ποια είναι τα χαρακτηριστικά του ιδιώματα Έγγραφο προσδιορισμού απαιτήσεων από το λογισμικό + Μοντέλα παράστασης λογισμικού (ΔΡΔ, ΔΟΣ, ΔΜΚ) + Λεξικό Δεδομένων: είσοδος στη φάση σχεδίασης! Στη φάση της σχεδίασης αντιμετωπίζουμε το πρόβλημα πώς θα το κάνει πώς θα επιτύχουμε την επιθυμητή συμπεριφορά Διαδικασία σχεδίασης Δύσκολη, δεν αυτοματοποείται εύκολα πολλές επιλογές, πλήθος τεχνικά και μη κριτήρια (κόστος, χρόνος υλοποίησης) για την αναζήτηση του καλύτερου δημιουργική και ενδιαφέρουσα Τι είναι η σχεδίαση Διεργασία μετατροπής του προβλήματος σε λύση Από το Τί στο Πώς Σχέδιο: Λεπτομερής περιγραφή της λύσης Λύση: Ικανοποιεί όλες τις απαιτήσεις της προδιαγραφής Είναι δυνατόν να υπάρχουν πολλαπλές λύσεις Πιθανόν να μην υπάρχει μοναδική «βέλτιστη» Αλλαγές (και πάλι ) 2

3 Σκοπός Σχεδίασης Σχεδίαση λογισμικού η δημιουργική διαδικασία μετατροπής του προβλήματος σε λύση Τι ζητείται από τη σχεδίαση λογισμικού? Ένας τρόπος περιγραφής της κατασκευής του λογισμικού έτσι ώστε να ικανοποιεί τις προδιαγραφές που έχουν τεθεί, να μπορεί να εκτελεί τις επιθυμητές λειτουργίες και να μπορεί να έχει τα επιθυμητά χαρακτηριστικά Σχέδιο λογισμικού: η περιγραφή των μονάδων που αποτελούν το λογισμικό, των συσχετίσεων μεταξύ τους, της διάταξής τους και της εσωτερικής τους λειτουργίας Σχεδίαση Λογισμικού Οι προδιαγραφές ορίζουν το πρόβλημα Κάτι αποτελεί λύση αν ικανοποιεί όλες τις απαιτήσεις των προδιαγραφών ΕΠΟΜΕΝΩΣ μεγάλος αριθμός λύσεων Σύνθετο πρόβλημα η μετάβαση από τις προδιαγραφές στη σχεδίαση! Σημαντικές πλευρές: Με ποια στρατηγική πρέπει να αντιμετωπίσουμε τη μετάβαση από τις προδιαγραφές στη σχεδίαση ώστε η εργασία να είναι αποτελεσματική? Ποιος είναι ο καλύτερος τρόπος μετάβασης από τις προδιαγραφές στη σχεδίαση και πώς τεκμηριώνεται αυτό? Πώς δεσμεύεται η σχεδίαση από το περιβάλλον (γλώσσα προγραμματισμού, λειτουργικό σύστημα) στο οποίο θα γίνει η υλοποίηση? Ποια είναι η περισσότερο επαρκής/κατάλληλη περιγραφή σχεδίου λογισμικού? Πώς διασφαλίζεται η ποιότητα του λογισμικού? 3

4 Καλύτερη λύση? Κριτήρια ποιότητας Καλύτερη δυνατή στις εκάστοτε συνθήκες/συγκεκριμένο περιβάλλον κατασκευής λογισμικού. Κριτήρια ποιότητας σχεδίου λογισμικού: Το σχέδιο πρέπει να ικανοποιεί όλες τις προδιαγραφές των απαιτήσεων από το λογισμικό (λειτουργικές και μη) Το σχέδιο πρέπει να περιγράφει πλήρως όλες τις πλευρές του λογισμικού δεδομένα, λειτουργίες και συμπεριφορά, όπως αυτές θεωρούνται από την πλευρά του κατασκευαστή Το σχέδιο πρέπει να είναι εύκολα κατανοητό από αυτούς που θα κληθούν να συγγράψουν τον πηγαίο κώδικα (προγραμματιστές) Το σχέδιο δεν πρέπει να περιέχει σφάλματα Η Τεχνολογία Λογισμικού παρέχει μεθοδολογίες σχεδίασης που αποτελούν κατευθυντήριες γραμμές για το σχεδιαστή. Εννοιολογικό και Τεχνικό Σχέδιο Παράδειγμα: Προσχέδιο και αναπαράσταση σπιτιού Παράδειγμα: Καλωδίωση, Υδραυλικά, υποστηρίγματα σπιτιού Το εννοιολογικό σχέδιο επικεντρώνει στις λειτουργίες του συστήματος, και το τεχνικό σχέδιο περιγράφει τη μορφή που θα πάρει το σύστημα 4

5 Εννοιολογικό Σχέδιο Conceptual Design Απευθύνεται στον πελάτη Περιγράφει στον πελάτη τι θα κάνει το σύστημα σε σχέση με τις διάφορες πλευρές του (όρια, οντότητες, χαρακτηριστικά, σχέσεις τους) Απαντά σε ερωτήματα όπως: Από πού προέρχονται τα δεδομένα Τι θα συμβεί στα δεδομένα μέσα στο σύστημα Πώς θα δείχνει το σύστημα στους χρήστες Τι επιλογές θα προσφέρονται στους χρήστες Ποιος θα είναι ο χρονισμός των γεγονότων που αφορούν το σύστημα Πώς θα δείχνουν οι αναφορές και οι οθόνες Εννοιολογικό Σχέδιο Conceptual Design Χαρακτηριστικά καλού εννοιολογικού σχεδίου Να είναι γραμμένο στη γλώσσα του πελάτη Να μην περιέχει τεχνικούς όρους (αργκό) Να περιγράφει τις λειτουργίες του συστήματος Να είναι ανεξάρτητο από την κωδικοποίηση/υλοποίηση Να προκύπτει από το έγγραφο απαιτήσεων λογισμικού Να έχει αναφορές στο έγγραφο απαιτήσεων λογισμικού Να ενσωματώνει όλες τις απαιτήσεις με κατάλληλο βαθμό λεπτομέρειας 5

6 Τεχνικό Σχέδιο Technical Design Λεπτομερέστερο, πιο τεχνικό Απευθύνεται στους προγραμματιστές και περιλαμβάνει: Περιγραφή της μορφής που θα πάρει το σύστημα Αρχιτεκτονική του συστήματος: Περιγραφή των διαφόρων τμημάτων Διάταξη υλικού Ανάγκες σε λογισμικό Δομή του λογισμικού: Ιεραρχία και λειτουργία των συστατικών του λογισμικού Δεδομένα: Περιγραφή της δομής των δεδομένων και της ροής τους Ανάγκες επικοινωνίας Ι/Ο format Εννοιολογικό και Τεχνικό Σχέδιο Παλινδρόμηση μεταξύ εννοιολογικού και τεχνικού σχεδίου ΕΝΝΟΙΟΛΟΓΙΚΟ ΣΧΕΔΙΟ ΤΕΧΝΙΚΟ ΣΧΕΔΙΟ Ο χρήστης θα έχει τη δυνατότητα να στέλνει μηνύματα σε οποιοδήποτε άλλο χρήστη βρίσκεται συνδεδεμένος στο δίκτυο Τοπολογία δικτύου Πρωτόκολλο Ρυθμός σε bps 6

7 Προσεγγίσεις σχεδίασης Δομημένη σχεδίαση (function oriented) προσανατολισμένη στις διαδικασίες βασίζεται και στις διαδικασίες και στα δεδομένα Αντικειμενοστρεφής σχεδίαση (object oriented) προσανατολισμένη στα αντικείμενα Δομημένη Σχεδίαση Βασίζεται στις διαδικασίες και τα δεδομένα Προτείνει τρόπους αποσύνθεσης από πάνω προς τα κάτω (top-down) σε μια ιεραρχία (διαδικασιών, συναρτήσεων κτλ) Κατεβαίνοντας στην ιεραρχία => μεγαλύτερη λεπτομέρεια =>απλές δομικές μονάδες (π.χ. εντολές γλώσσας προγραμματισμού) Αυτή η ιεραρχία διαδικασιών, συναρτήσεων και άλλων ενεργών μονάδων λογισμικού επιδρά σε ανεξάρτητο σύνολο δεδομένων. Επικέντρωση προσοχής πρώτα στις διαδικασίες και μετά στα δεδομένα 7

8 Αντικειμενοστρεφής Σχεδίαση Συλλογή οντοτήτων όπου δεν διαχωρίζουν τις διαδικασίες από τα δεδομένα αλλά τα ενσωματώνουν κάτω από το ίδιο «κέλυφος» = κλάση Οι οντότητες αυτές ονομάζονται αντικείμενα Κάθε αντικείμενο παρέχει στο περιβάλλον του ένα σύνολο υπηρεσιών της ευθύνης του. Η συνεργασία του συνόλου των αντικειµένων του πεδίου µιας εφαρµογής λογισµικού παράγει το επιθυµητό αποτέλεσµα. Γνωστές προσεγγίσεις - Meyer (1988), Booch (1994), Jacobson (1993), Rumbaugh (1992) Τα τελευταία χρόνια εµφάνιση «συγχωνευµένων» µεθοδολογιών και ενοποιηµένων συµβολισµών Αποσύνθεση Αποσύνθεση: Από απεικόνιση υψηλού επιπέδου σε λεπτομερέστερες απεικονίσεις χαμηλότερων επιπέδων Αποσαφήνιση του τρόπου ταιριάσματος χαρακτηριστικών και λειτουργιών των τμημάτων του συστήματος 8

9 Επίπεδα αποσύνθεσης Ανεξάρτητα από προσέγγιση σχεδίασης, κάθε είδος αποσύνθεσης διαχωρίζει το σχέδιο σε μονάδες (modules) ή συστατικά στοιχεία (components) Αρθρωτό (modular) σύστημα: όταν κάθε δραστηριότητα εκτελείται ακριβώς από ένα συστατικό και όταν οι είσοδοι και οι έξοδοι κάθε συστατικού ορίζονται με έγκυρο τρόπο Σωστά ορισμένο (well-defined) συστατικό: όλες οι είσοδοι απαραίτητες και όλες οι έξοδοι αποτέλεσμα μίας ενέργειάς του Χαρακτηριστικά σχεδίου Τμηματικότητα (Modularity): Κάθε δραστηριότητα του συστήματος (απλή ή σύνθετη) εκτελείται από μία μονάδα και οι είσοδοι έξοδοι κάθε μονάδας είναι καλά ορισμένες Μονάδες υψηλού επιπέδου: Βλέπουμε συνολικά το πρόβλημα Δεν εμπλεκόμαστε στις λεπτομέρειες Απομονώνουμε μέρη που είναι πιο δύσκολα Μονάδες χαμηλού επιπέδου: Απομονώνουν συγκεκριμένες λεπτομέρειες 9

10 Χαρακτηριστικά σχεδίου Χαρακτηριστικά σχεδίου Αφαιρετικότητα: Η κάθοδος σε χαμηλότερο επίπεδο παρέχει μεγαλύτερη λεπτομέρεια Τα υψηλότερα επίπεδα είναι περισσότερο αφαιρετικά, αποκρύπτουν πληροφορία (information hiding) για την ευκολότερη αντιμετώπιση του προβλήματος (αντίστοιχα με OO) Μπορεί να αλλάξει το σχέδιο μιας μονάδας χωρίς να επηρεαστεί ο σχεδιασμός των υπολοίπων 10

11 Χαρακτηριστικά σχεδίου Ποιότητα σχεδίου ~ βαθμός ανεξαρτησίας μεταξύ των μονάδων - ανεξάρτητα μεταξύ τους συστατικά (δομικές μονάδες) Ευκολότερος έλεγχος, κατανόηση, τροποποίηση Βαθμός ανεξαρτησίας Σύζευξη (coupling) - Συσχέτιση μεταξύ διαφορετικών δομικών μονάδων Συνεκτικότητα (cohesion) - Εσωτερική συνοχή κάθε δομικής μονάδας Στόχος: Χαμηλή σύζευξη & υψηλή συνεκτικότητα Σύζευξη Η σύζευξη αποτελεί ένα μέτρο του κατά πόσο οι μονάδες εξαρτώνται μεταξύ τους Η σύζευξη εξαρτάται από: Κλήσεις από μία μονάδα σε άλλη Ποσότητα δεδομένων που διακινείται από μία μονάδα σε άλλη Το μέγεθος του ελέγχου που έχει μία μονάδα πάνω σε μία άλλη Βαθμός πολυπλοκότητας στη διεπαφή μιας μονάδας με άλλες Υψηλή σύζευξη (High coupling): Αλλαγές σε ένα υποσύστημα προκαλούν αλλαγές σε κάποιο άλλο υποσύστημα (ανάγκη για αλλαγή στην παρουσίαση των δεδομένων, νέα συμβολομετάφραση) Χαμηλή σύζευξη (Low coupling): Αλλαγές σε ένα υποσύστημα δεν προκαλούν αλλαγές σε άλλα υποσυστήματα 11

12 Σύζευξη Επίπεδα σύζευξης Σύζευξη: κλίμακα εξάρτησης Υψηλή σύζευξη Σύζευξη περιεχομένου Κοινή σύζευξη Χαλαρή σύζευξη Σύζευξη ελέγχου Σύζευξη αποτύπωσης Σύζευξη δεδομένων Μη Σύζευξη 12

13 Επίπεδα σύζευξης Περιεχομένου: Άμεση τροποποίηση στοιχείων του ενός συστατικού από το άλλο Άμεση χρήση (π.χ. με διακλάδωση) στοιχείων του ενός συστατικού από το άλλο Κοινών δεδομένων: Στην περίπτωση που τα συστατικά προσπελαύνουν κοινά, κεντρικά διαθέσιμα δεδομένα. Ελέγχου: Καθοδηγητής / Καθοδηγούμενος Αποτύπωσης /α ντιγράφου: Δεδομένα (raw) από το ένα συστατικό στο άλλο. Πρέπει να ταιριάζουν οι τύποι, η τιμή, η οργάνωση Δεδομένων Δομές δεδομένων από το ένα συστατικό στο άλλο Σύζευξη περιεχομένου Δύο μονάδες έχουν σύζευξη περιεχομένου (content coupling) εάν κώδικας στη μία μονάδα επηρεάζει και τροποποιεί άμεσα κώδικα στην άλλη μονάδα 13

14 Κοινή σύζευξη Δύο μονάδες έχουν κοινή σύζευξη (common coupling) εάν κώδικας στη μία μονάδα έχει προσπέλαση (read AND write) σε κοινές μεταβλητές με την άλλη μονάδα Ένα τυπικό παράδειγμα είναι όταν δύο μονάδες διαβάσουν και ενημερώνουν κοινές γενικές μεταβλητές (global variables) Είναι αποδεκτό όμως μία μονάδα να ενημερώνει μια κοινή (γενική) μεταβλητή και οι άλλες μονάδες να διαβάζουν μόνο αυτή τη μεταβλητή Η κοινή σύζευξη δημιουργεί αρκετά προβλήματα κατά τη συντήρηση και αναβάθμιση συστημάτων λογισμικού (δύσκολος να κατανοηθεί κώδικας, μικρές δυνατότητες επαναχρησιμοποίησης, πιθανά προβλήματα σχετικά με την ασφάλεια του συστήματος) Κοινή σύζευξη Μπορούμε να μειώσουμε τη σύζευξη τοποθετώντας δεδομένα σε κοινή περιοχή (π.χ. καθολικές μεταβλητές) Aλλαγές στις καθολικές μεταβλητές επηρεάζουν όλες τις μονάδες που έχουν πρόσβαση σε αυτές Δυσκολία εξακρίβωσης ποια μονάδα άλλαξε μια μεταβλητή 14

15 Σύζευξη ελέγχου Δύο μονάδες έχουν σύζευξη ελέγχου (control coupling) εάν κώδικας στη μία μονάδα μπορεί να μεταβάλλει (π.χ. με την τιμή μιας μεταβλητής) τη ροή ελέγχου στην άλλη μονάδα. Τυπικά παραδείγματα περιλαμβάνουν όταν μία μονάδα περνάει στην άλλη μονάδα μια παράμετρο που χρησιμοποιείται από κάποια έκφραση συνθήκης που επηρεάζει τη ροή ελέγχου στη δεύτερη μονάδα όταν μονάδα (Α) επιστρέφει στην άλλη μονάδα (Β) ένα αποτέλεσμα που χρησιμοποιείται όχι μόνο για να δηλώσει το αποτέλεσμα ενός υπολογισμού του (Α) αλλά και να ορίσει ποια δράση θα πρέπει η δεύτερη μονάδα (Β) πρέπει να καλέσει (π.χ. να τυπώσει ένα μήνυμα λάθους στο χρήστη) Σύζευξη αποτύπωσης Δύο μονάδες έχουν σύζευξη αποτύπωσης (stamp coupling) εάν η μία μονάδα περνάει σαν παραμέτρους στην άλλη μονάδα περισσότερα δεδομένα απ ότι χρειάζεται. Τυπικό παράδειγμα είναι όταν περνάμε μια κλάση ή μια δομή σαν παράμετρο, αλλά μόνο τα συγκεκριμένα στοιχεία της κλάσης/δομής που χρειάζονται Ουσιαστικά θα πρέπει να προσέχουμε να μην έχουμε τον κώδικα πελάτη να εξαρτάται από ονόματα πεδίων έτσι ώστε να μπορούμε να επαναχρησιμοποιήσουμε αυτόν τον κώδικα Η γενική ιδέα είναι να μεταφέρουμε από μία μονάδα μόνο τα απαραίτητα δεδομένα και τίποτε περισσότερο 15

16 Σύζευξη δεδομένων Δύο μονάδες έχουν σύζευξη δεδομένων (data coupling) εάν η μία μονάδα περνάει σαν παραμέτρους στην άλλη μονάδα είτε απλούς τύπους δεδομένων είτε τιμές από συγκεκριμένα πεδία κλάσεων / δομών που είναι απολύτως απαραίτητα για τη λειτουργία της δεύτερης μονάδας Μια μονάδα μπορεί να τροποποιήσει τα ίδια τα δεδομένα μιας άλλης μονάδος (κλήση κατ αναφορά) ή να δράσει επάνω σε αντίγραφα των δεδομένων μιας άλλης μονάδος (κλήση κατ αξία) Επιθυμητή σύζευξη Γενικά είναι επιθυμητή η ελαχιστοποίηση της σύζευξης: Ευκολότερη σχεδίαση (δυνατότητα καταμερισμού εργασιών) Ευκολότερος εντοπισμός σφαλμάτων συστήματος Ευκολότερο debugging Ευκολότερος έλεγχος εύκολη απομόνωση ελαττωματικής μονάδας Σε περίπτωσης αλλαγής απαιτήσεων για αντικατάσταση μιας λειτουργίας, η χαμηλή σύζευξη => απευθείας αντικατάσταση μιας μονάδας από άλλη 16

17 Συνεκτικότητα Αναφέρεται στην εσωτερική συνοχή κάθε μονάδας Αν μία μονάδα είναι συνεκτική (cohesive) => όλα τα τμήματά της προορίζονται και είναι απαραίτητα για την εκτέλεση της ίδιας λειτουργίας Στόχος: η μεγαλύτερη δυνατή συνεκτικότητα κάθε μονάδος Υψηλή συνεκτικότητα (High cohesion): Τα τμήματα σε μια μονάδα προσφέρουν συναφείς υπηρεσίες και, έχουν σχέσεις εταιρικότητας Χαμηλή συνεκτικότητα (Low cohesion): Τα τμήματα σε μια μονάδα προσφέρουν άσχετες μεταξύ τους υπηρεσίες και δεν έχουν σχέσεις εταιρικότητας Επίπεδα συνεκτικότητας Λιγότερο επιθυμητή Τυχαία Συνεκτικότητα (Coincidental Cohesion) Λογική Συνεκτικότητα (Logical cohesion) Χρονική Συνεκτικότητα (Temporal cohesion) Διαδικαστική Συνεκτικότητα (Procedural cohesion) Επικοινωνιακή Συνεκτικότητα (Communicational cohesion) Ακολουθιακή Συνεκτικότητα (Sequential cohesion) Λειτουργική Συνεκτικότητα (Functional cohesion) Περισσότερο επιθυμητή 17

18 Τυχαία συνεκτικότητα Έχουμε τυχαία συνεκτικότητα όταν τα τμήματα μιας μονάδας είναι εντελώς ασυσχέτιστα, έχουν τυχαίο τρόπο συγκρότησης, έχουν δομηθεί με τρόπο που δεν ακολουθεί κανόνες και αρχές της τεχνολογίας λογισμικού, αλλά άλλους «τυχαίους» κανόνες Η τυχαία συνεκτικότητα είναι η χειρότερη μορφή συνεκτικότητας και σχεδιαστικής δομής Λογική συνεκτικότητα Μία μονάδα έχει λογική συνεκτικότητα εάν οι λειτουργίες της μονάδας είναι λειτουργικά συσχετιζόμενες και έχουν μια γενικά κοινή ροή ελέγχου. Οι διαφορές σε κάθε λειτουργία είναι αποτέλεσμα παραμετροποίησης. Η «λογική» έχει να κάνει με τη γενικά κοινή ροή ελέγχου σε κάθε λειτουργία της μονάδας Οι μονάδες που έχουν λογική συνεκτικότητα έχουν σαν αποτέλεσμα μονάδες που είναι δύσκολο να κατανοηθούν και έχουν υψηλή σύζευξη Η λύση είναι να αναλύσουμε και να μετατρέψουμε τις μονάδες που έχουν λογική συνεκτικότητα σε νέες μονάδες ανάλογα με τις συγκεκριμένες λειτουργίες της κάθε μονάδας και όχι σε σχέση με κάποια κοινά στοιχεία ελέγχου που μπορεί να μοιράζονται λειτουργίες 18

19 Χρονική συνεκτικότητα Μία μονάδα έχει χρονική συνεκτικότητα όταν στην ίδια μονάδα υπάρχουν τμήματα που υλοποιούν λειτουργίες οι οποίες εκτελούνται γειτονικά στο χρόνο (π.χ. διαδοχικά) Για παράδειγμα εάν θεωρήσουμε μια εφαρμογή να έχει τα παρακάτω βήματα: Τοποθέτηση αρχικών τιμών, εισαγωγή στοιχείων από το χρήστη, επεξεργασία στοιχείων, παραγωγή αποτελεσμάτων, έξοδος στοιχείων Τότε, εάν η μονάδα δομηθεί με κριτήριο τη χρονική συνεκτικότητα τότε θα έχει πέντε υπομονάδες/λειτουργίες. Κάθε υπομονάδα θα έχει οργανωθεί με λειτουργίες με βάση το γεγονός ότι αυτές συμβαίνουν στην ίδια χρονική στιγμή. Ένα σύστημα που έχει δομηθεί με κριτήριο τη χρονική συνεκτικότητα πιθανόν να έχει αρκετά πανομοιότυπα τμήματα πηγαίου κώδικα Διαδικαστική συνεκτικότητα Μία μονάδα έχει διαδικαστική συνεκτικότητα εάν έχει δομηθεί με το κριτήριο ότι οι λειτουργίες της μονάδας σχετίζονται με κάποια ακολουθία βημάτων που θα πρέπει να ακολουθηθούν για την εκτέλεση κάποιας εργασίας Για παράδειγμα, εάν μία μονάδα έχει δομηθεί έτσι ώστε οι λειτουργίες να σχετίζονται με συγκεκριμένα βήματα μιας διαδικασίας όπως εισαγωγή δεδομένων από το πληκτρολόγιο, επιβεβαίωση δεδομένων, αποθήκευση δεδομένων σε μεταβλητές τότε η μονάδα θα έχει διαδικαστική συνεκτικότητα Η διαδικαστική συνεκτικότητα είναι πρακτικά χρονική συνεκτικότητα με τον επιπρόσθετο περιορισμό ότι οι λειτουργίες θα πρέπει να σχετίζονται και σαν βήματα κάποιας συγκεκριμένης διαδικασίας / εργασίας Ένα σύστημα που έχει δομηθεί με κριτήριο τη διαδικαστική συνεκτικότητα πιθανόν να έχει αρκετά πανομοιότυπα τμήματα πηγαίου κώδικα 19

20 Επικοινωνιακή συνεκτικότητα Μία μονάδα έχει επικοινωνιακή συνεκτικότητα εάν έχει δομηθεί με το κριτήριο ότι οι λειτουργίες της μονάδας σχετίζονται με κάποια ακολουθία βημάτων που θα πρέπει να ακολουθηθούν για την εκτέλεση κάποιας εργασίας ΚΑΙ όλες οι λειτουργίες διαχειρίζονται τα ίδια δεδομένα Η επικοινωνιακή συνεκτικότητα είναι μια βελτίωση της διαδικαστικής συνεκτικότητας διότι όλες οι λειτουργίες διαχειρίζονται τα ίδια δεδομένα του συστήματος. Με άλλα λόγια έχουμε λειτουργίες που σχετίζονται και διαδικαστικά και σε σχέση με τα δεδομένα του συστήματος Ακολουθιακή συνεκτικότητα Μία μονάδα έχει ακολουθιακή συνεκτικότητα εάν η έξοδος από το ένα τμήμα μιας μονάδος αποτελεί είσοδο σε επόμενο τμήμα της μονάδος 20

21 Λειτουργική συνεκτικότητα Μία μονάδα έχει λειτουργική συνεκτικότητα εάν έχει δομηθεί με το κριτήριο ότι οι λειτουργίες της μονάδας σχετίζονται διότι υλοποιούν κάποια συγκεκριμένη λειτουργία ή επιτυγχάνουν κάποιο συγκεκριμένο στόχο του συστήματος Μονάδες που διεκπεραιώνουν μια συγκεκριμένη λειτουργία είναι πιο επαναχρησιμοποιήσιμες. Παραδείγματα τέτοιων ψηφίδων είναι: διάβασμα αρχείου, εκτύπωση γράφου Ένα άλλο πλεονέκτημα της λειτουργικής συνεκτικότητας είναι ότι επιτρέπει την απομόνωση και αναγνώριση μονάδων που σχετίζονται με συγκεκριμένα σφάλματα Θέματα ελέγχου Fan-in μιας μονάδας Πλήθος μονάδων που την ελέγχουν Fan-out μιας μονάδας Πλήθος μονάδων που ελέγχει 21

22 Στόχοι Στόχος 1: Ελαχιστοποίηση αριθμού μονάδων με υψηλό fan-out Μία μονάδα που ελέγχει πολλές άλλες, συνήθως εκτελεί πολλές εργασίες (κακή συνεκτικότητα). Δυσκολία στον εντοπισμό σφαλμάτων, στην τροποποίηση, στην επαναχρησιμοποίηση Στόχος 2: Μεγιστοποίηση αριθμού μονάδων με υψηλό fan-in Μία μονάδα που ελέγχεται από πολλές άλλες, είναι μονάδα γενικής χρησιμότητας και είναι σαφώς προτιμότερο μία λειτουργία που εκτελείται συχνά να βρίσκεται σε μία μονάδα, παρά κατανεμημένη ή υλοποιημένη σε πολλές μονάδες Καλές πρακτικές Χαμηλή σύζευξη => Σύζευξη Δεδομένων Υψηλή συνεκτικότητα => Λειτουργική Συνεκτικότητα Ελαχιστοποίηση του μέγιστου Fan-out του σχεδίου Σχέδιο Α έχει 3 μονάδες με fan-outs = 5, 4, 6 αντίστοιχα Σχέδιο B έχει 4 μονάδες με fan-outs = 7, 1, 3, 2 Καλύτερο το Α Ελαχιστοποίηση των επιπέδων με αύξηση του συνολικού Fan-in Δημιουργία μονάδων που τις «χρησιμοποιούν» αρκετές μονάδες, δηλ. μονάδες που υλοποιούν κοινές υπολειτουργίες Μεταφορά σημείων απόφασης σε υψηλότερα επίπεδα 22

23 Φάσεις σχεδίασης λογισμικού Αρχιτεκτονική σχεδίαση Ποιες μονάδες συγκροτούν το σύστημα λογισμικού και πώς ανατίθενται για εκτέλεση (διατάσσονται) στις διαθέσιμες υπολογιστικές μονάδες Σχεδίαση διαπροσωπειών Καθορισμός επικοινωνίας μεταξύ μονάδων, με άλλα συστήματα, με άλλες συσκευές και με τον άνθρωπο ποια μονάδα επικοινωνεί με ποια, με ποιες παραμέτρους και με όποιο άλλο στοιχείο απαιτείται για να περιγραφεί επαρκώς η επικοινωνία Λεπτομερής σχεδίαση μονάδων Καθορισμός εσωτερικής δομής κάθε μονάδας λογισμικού, ώστε να ικανοποιούνται οι λειτουργικές απαιτήσεις και να συνεργάζεται με άλλες μονάδες όπως έχει καθοριστεί κατά την αρχιτεκτονική σχεδίαση και τη σχεδίαση δεδομένων Σχεδίαση δεδομένων Καθορισμός δομής και συσχετίσεων δεδομένων Εξέλιξη σχεδίασης λογισμικού Είσοδο στην εργασία της σχεδίασης αποτελούν τα προϊόντα που έχουν παραχθεί κατά τη φάση της προδιαγραφής των απαιτήσεων από το λογισµικό. Η σχεδίαση λογισµικού είναι µια εργασία που προχωρά από τη µικρότερη στη µεγαλύτερη λεπτοµέρεια. Προδιαγραφές των απαιτήσεων από το λογισμικό Σύλληψη περιγράμματος Άτυπη σχεδίαση Λεπτομερής σχεδίαση Σχέδιο λογισμικού 23

24 Από την ανάλυση απαιτήσεων στη σχεδίαση Προϊόντα σχεδίασης λογισμικού Διάγραμμα Ροής Δεδομένων Έγγραφο Προδιαγραφών Διάγραμμα Μετάβασης Καταστάσεων Διάγραμμα Οντοτήτων- Συσχετίσεων Λεξικό Δεδομένων ΣΧΕΔΙΑΣΗ Αρχιτεκτονικό Σχέδιο Σχέδιο Διαπροσωπειών Σχέδιο Μονάδων Σχέδιο Δεδομένων 24

25 Δεδομένα και μονάδες λογισμικού στη δομημένη ανάλυση και σχεδίαση Αρχιτεκτονικό Σχέδιο ΜΟΝΑΔΕΣ ΛΟΓΙΣΜΙΚΟΥ Σχέδιο Διαπροσωπειών Σχέδιο Μονάδων Σχέδιο Δεδομένων ΔΕΔΟΜΕΝΑ Αρχιτεκτονική σχεδίαση Προσδιορισμός των µονάδων που αποτελούν το λογισµικό και πώς σχετίζονται µεταξύ τους (σχεδίαση συστήµατος). Στη δοµηµένη σχεδίαση η εργασία αυτή γίνεται λαµβάνοντας ως είσοδο τα διαγράµµατα ροής δεδοµένων. Σε αυτά εφαρµόζεται ένα σύνολο κανόνων και καθορίζονται οι µονάδες λογισµικού που είναι αναγκαίες για την υλοποίηση των µετασχηµατισµών και των ροών δεδοµένων. 25

26 Αρχιτεκτονική σχεδίαση Διαδοχικά επίπεδα λεπτοµέρειας ξεκινώντας από το 1 ο επίπεδο όπου το λογισμικό θεωρείται ως σύνθετο σύστηµα, που αποτελείται από υποσυστήµατα (2 ο επίπεδο), καθένα από τα οποία αποτελείται από υποσυστήµατα 2ας τάξης (3 ο επίπεδο) κοκ, µέχρι να φτάσουµε στις ατοµικές µονάδες λογισµικού (συναρτήσεις, υπορουτίνες, κτλ.). Σε χαµηλότερο επίπεδο, αναγνώριση «κοινών παραγόντων» - µονάδες λογισµικού που ανήκουν σε περισσότερα από ένα υποσυστήµατα του αµέσως παραπάνω επιπέδου. Το φαινόµενο εµφανίζεται κυρίως µετά από την εκτέλεση της συναρτησιακής αποσύνθεσης (functional decomposition). Επίπεδα αρχιτεκτονικού σχεδίου λογισμικού Σύστημα Υπό-σύστημα 1 ου επιπέδου Υπό-σύστημα 2 ου επιπέδου Υπό-σύστημα 3 ου επιπέδου 26

27 Κλήσεις μονάδων λογισμικού Επικοινωνία μονάδων λογισµικού μεταξύ τους «Μία µονάδα λογισµικού χρησιµοποιεί άλλες µονάδες» σημαίνει την κλήση προγραµµάτων, υπορουτινών, συναρτήσεων και άλλων δοµικών στοιχείων λογισµικού. Η κλήση µιας µονάδας Β από µια µονάδα Α σηµαίνει: ενεργοποίηση της µονάδας Β η ροή του προγράµµατος µεταφέρεται στη µονάδα Β και εκτελούνται οι εντολές που περιέχονται σε αυτή και επικοινωνία της µονάδας Α µε τη Β µέσω παραµέτρων που περνά η Α στη Β και ενδεχοµένως και αντίστροφα. Σχεδίαση διαπροσωπειών Καθορίζονται οι λεπτοµέρειες του περάσµατος των παραµέτρων σε όλα τα επίπεδα επικοινωνίας Επικοινωνία µονάδων λογισµικού µεταξύ τους Επικοινωνία µονάδων λογισµικού µε εξωτερικά συστήµατα ή συσκευές Επικοινωνία µονάδων λογισµικού µε τον άνθρωπο Καθορισμός των ακόλουθων Ο αριθµός και ο τύπος των παραµέτρων κατά την κλήση µονάδων λογισµικού Το είδος και οι λεπτοµέρειες της επικοινωνίας µε άλλα συστήµατα λογισµικού Το είδος και οι λεπτοµέρειες της επικοινωνίας µε εξωτερικές συσκευές Η επικοινωνία του λογισµικού µε τον άνθρωπο 27

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

29 Σχεδίαση δεδομένων Σύλληψη δοµής και συσχετίσεων δεδοµένων Καθορίζει πολλά από τα χαρακτηριστικά των λειτουργικών µονάδων λογισµικού Από το λεξικό δεδοµένων και το διάγραµµα οντοτήτωνσυσχετίσεων: Βελτιστοποιήσεις στο ΔΟΣ για βελτιστοποίηση επιδόσεων, πληροφοριακή πληρότητα και εξάλειψη πλεονάζουσας (redundant) πληροφορίας Καθορισμός πεδίων και τύπων πινάκων (φυσικό επίπεδο) Καθορισμός των views των δεδοµένων (λογικό επίπεδο) Αντικείµενο των βάσεων δεδοµένων. Αποτέλεσµα: λεπτοµερής περιγραφή οντοτήτων και συσχετίσεων Έγγραφο περιγραφής σχεδίου λογισμικού (IEEE) 1. Εισαγωγή 2. Περιγραφή αποσύνθεσης του λογισµικού 3. Περιγραφή εξαρτήσεων 4. Περιγραφή διαπροσωπειών 5. Λεπτοµερές σχέδιο µονάδων 6. Λεπτοµερές σχέδιο δεδοµένων Παραρτήµατα 29

30 Έγγραφο περιγραφής σχεδίου λογισμικού (IEEE) 1. Εισαγωγή 1.1 Γενική περιγραφή 1.2 Εµβέλεια 1.3 Ορισµοί και ακρωνύµια Ορισμοί (αλφαβητικά) - Εγγραφή πρόσβασης (Access record) Πληροφορία για μία πρόσβαση ή απόπειρα πρόσβασης. Η πληροφορία περιλαμβάνει ημερομηνία, ώρα, user ID και αποτέλεσμα πιστοποίησης - Τύπος λογαρισμού (Account Type) λογαριασμός όψεως ή ταμιευτηρίου - Μήνυμα Έγκρισης (Approval message) Το μήνυμα που εκδίδει η τράπεζα όταν η συναλλαγή εγκριθεί. Περιλαμβάνει πληροφορίες σχετικά με το χρήστη και τη συναλλαγή 1.4 Αναφορές Έγγραφο περιγραφής σχεδίου λογισμικού (IEEE) 2. Περιγραφή αποσύνθεσης του λογισµικού 2.1 Αποσύνθεση σε µονάδες Περιγραφή µονάδας Περιγραφή µονάδας Αποσύνθεση σε ταυτόχρονες διεργασίες Περιγραφή διεργασίας Περιγραφή διεργασίας 2 Αρχιτεκτονική σχεδίαση 30

31 Έγγραφο περιγραφής σχεδίου λογισμικού (IEEE) 2.3 Αποσύνθεση δεδοµένων Περιγραφή οντότητας δεδοµένων Περιγραφή οντότητας δεδοµένων 2 3. Περιγραφή εξαρτήσεων 3.1 Εξαρτήσεις µεταξύ µονάδων 3.2 Εξαρτήσεις µεταξύ διεργασιών 3.3 Εξαρτήσεις µεταξύ δεδοµένων 4. Περιγραφή διαπροσωπειών 4.1 Διαπροσωπείες µονάδων 4.2 Διαπροσωπείες διεργασιών 4.3 Διαπροσωπείες χρήστη Σχεδίαση δεδομένων Αρχιτεκτονική σχεδίαση Σχεδίαση δεδομένων Σχεδίαση διαπροσωπειών Έγγραφο περιγραφής σχεδίου λογισμικού (IEEE) 4.4 Εξωτερικές διαπροσωπείες Συστήµατα λογισµικού Συσκευές 5. Λεπτοµερές σχέδιο µονάδων 5.1 Λεπτοµερές σχέδιο µονάδας Λεπτοµερές σχέδιο µονάδας 2 6. Λεπτοµερές σχέδιο δεδοµένων 6.1 Οντότητα δεδοµένων Οντότητα δεδοµένων 2 Παραρτήµατα Σχεδίαση διαπροσωπειών Λεπτομερής σχεδίαση μονάδων Σχεδίαση δεδομένων 31

32 Διατάξεις Λογισμικού Διάταξη λογισµικού (software deployment): η κατάτµηση µιας εφαρµογής σε ανεξάρτητα λειτουργικά τµήµατα και η ανάθεση αυτών σε διατιθέµενους υπολογιστικούς πόρους (συστήµατα, επεξεργαστές). Αναφορά στη γενική αρχιτεκτονική του λογισµικού Κατηγοριοποίηση των εργασιών που µπορεί να κάνει µια εφαρµογή λογισµικού: εργασίες παρουσίασης εργασίες διαχείρισης δεδοµένων και εργασίες επιχειρησιακής λογικής. Κατηγορίες εργασιών Εργασίες παρουσίασης όλες οι εργασίες που σχετίζονται µε την επικοινωνία του συστήµατος µε το χρήστη και µε εξωτερικές συσκευές και συστήµατα (εργασίες που υλοποιούν τις διαπροσωπείες λογισµικού) Εργασίες διαχείρισης δεδοµένων οι εργασίες που ασχολούνται µε την αποθήκευση και την ανάκτηση δεδοµένων Εργασίες επιχειρησιακής λογικής (business logic) όλες οι υπόλοιπες εργασίες, δηλαδή εκείνες που υλοποιούν τις ιδιαίτερες λειτουργικές απαιτήσεις κάθε εφαρµογής λογισµικού. 32

33 Μονολιθική διάταξη Η απλούστερη διάταξη λογισµικού - η εφαρµογή τρέχει σε ένα υπολογιστικό σύστηµα. Κατάλληλη για µικρές εφαρµογές µε σχετικά περιορισµένες απαιτήσεις και λειτουργίες - η πρώτη διάταξη που χρησιμοποιήθηκε για µεγάλο χρονικό διάστηµα Διάγραµµα διάταξης λογισµικού (deployment diagram) Μονολιθική Εφαρμογή Λογισμικού Παρουσίαση Επιχειρησιακή Λογική Διαχείριση Δεδομένων Διάταξη πελάτη-εξυπηρετητή Οι εργασίες παρουσίασης και επιχειρησιακής λογικής τρέχουν σε άλλο τµήµα - επικοινωνεί µέσω δικτύου µε τον εξυπηρετητή ΠΡΟΒΛΗΜΑ - η ανάγκη συντήρησης όλων των συστηµάτων πελάτη για όποιες µεταβολές στο επίπεδο της επιχειρησιακής λογικής Ανεπάρκεια συστημάτων πελάτη σε υπολογιστική ισχύ Πελάτης (Client) Εξυπηρετητής (Server) Παρουσίαση Επιχειρησιακή Λογική Διαχείριση Δεδομένων 33

34 Τριμερής διάταξη Ο πελάτης μένει με την ευθύνη της παρουσίασης - ελαφρύς (thin client) Εξυπηρετητής εφαρµογών - κάνει τις εργασίες του επιπέδου της επιχειρησιακής λογικής Συστήµατα εξυπηρετητών δεδοµένων και εφαρµογών είναι συνήθως µεγάλα κεντρικά υπολογιστικά συστήµατα Απαιτήσεις συντήρησης πελατών µόνο όταν συµβαίνουν µεταβολές στο επίπεδο της παρουσίασης Εξυπηρετητής Δεδομένων (Data Server) Διαχείριση Δεδομένων Παρουσίαση Πελάτης (Thin Client) Εξυπηρετητής Εφαρμογών (Application Server) Επιχειρησιακή Λογική Πολυμερής Διάταξη multi-tier web based Ο πελάτης διαθέτει μόνο δικτυακή σύνδεση και browser. Μηδενικά προβλήματα συντήρησης Προβλήματα ταχύτητας & ασφάλειας Παρουσίαση Εξυπηρετητής Παρουσίασης (Presentation Server) Πελάτης (Web Client) Εξυπηρετητής Δεδομένων (Data Server) Εξυπηρετητής Εφαρμογών (Application Server) Διαχείριση Δεδομένων Επιχειρησιακή Λογική 34

35 Φάσεις σχεδίασης λογισμικού Αρχιτεκτονική σχεδίαση Σχεδίαση διαπροσωπειών Λεπτομερής σχεδίαση μονάδων Σχεδίαση δεδομένων Προϊόντα σχεδίασης λογισμικού Διάγραμμα Ροής Δεδομένων Έγγραφο Προδιαγραφών Διάγραμμα Μετάβασης Καταστάσεων Διάγραμμα Οντοτήτων- Συσχετίσεων Λεξικό Δεδομένων ΣΧΕΔΙΑΣΗ Αρχιτεκτονικό Σχέδιο Σχέδιο Διαπροσωπειών Σχέδιο Μονάδων Σχέδιο Δεδομένων 35

36 Δεδομένα και μονάδες λογισμικού στη δομημένη ανάλυση και σχεδίαση Αρχιτεκτονικό Σχέδιο ΜΟΝΑΔΕΣ ΛΟΓΙΣΜΙΚΟΥ Σχέδιο Διαπροσωπειών Σχέδιο Μονάδων Σχέδιο Δεδομένων ΔΕΔΟΜΕΝΑ Αρχιτεκτονική σχεδίαση Προσδιορισμός των µονάδων που αποτελούν το λογισµικό και πώς σχετίζονται µεταξύ τους (σχεδίαση συστήµατος). Στη δοµηµένη σχεδίαση η εργασία αυτή γίνεται λαµβάνοντας ως είσοδο τα διαγράµµατα ροής δεδοµένων. Σε αυτά εφαρµόζεται ένα σύνολο κανόνων και καθορίζονται οι µονάδες λογισµικού που είναι αναγκαίες για την υλοποίηση των µετασχηµατισµών και των ροών δεδοµένων. 36

37 Ορισμοί Αρχιτεκτονικό σχέδιο λογισµικού - Διάγραµµα Δοµής Προγράµµατος (ΔΔΠ) Μονάδες λογισµικού Κλήση µονάδας Β από µονάδα Α (βέλος συνδέει την Α µε τη Β) Πέρασµα παραµέτρων και προς τις δύο (μικρό βέλος σε διεύθυνση παράλληλη µε τη διεύθυνση του βέλους που περιγράφει την κλήση και φέρει το όνοµα της παραµέτρου) M1 A B C D M2 M3 M4 Ορισμοί Για κάθε ΔΡΔ του συστήµατος εκτελείται η διαδικασία παραγωγής ενός ΔΔΠ Εντοπισμός: κεντρικού µετασχηµατισµού ή κέντρου δοσοληψιών Κεντρικός µετασχηµατισµός (ΚΜ): περιοχή του ΔΡΔ όπου οι µετασχηµατισµοί που ανήκουν σε αυτή µπορούμε να θεωρήσουμε ότι µετατρέπουν δεδοµένα εισόδου σε νέα δεδοµένα εξόδου. Οι εργασίες που προηγούνται του ΚΜ προσάγουν τα δεδοµένα εισόδου Οι εργασίες που έπονται του ΚΜ καταναλώνουν τα δεδοµένα εξόδου 37

38 Κεντρικός Μετασχηματισμός Μπορεί να ανήκουν περισσότεροι από ένας µετασχηµατισµοί του ΔΡΔ Ο ΚΜ, η προετοιµασία δεδοµένων εισόδου και η προετοιµασία δεδοµένων εξόδου µπορεί να αντιστοιχούν σε σύνθετα τµήµατα του ΔΡΔ (όχι μόνο σε απλούς µετασχηµατισµούς) Δεν υπάρχει ένας και μοναδικός ΚΜ Σε ένα ΔΡΔ μπορεί περισσότεροι από ένας μετασχηματισμοί να μπορούν να χρησιμοποιηθούν ως ΚΜ Εξαρτάται από το πρόβλημα Κεντρικός Μετασχηματισμός Λήψη και προετοιμασία δεδομένων εισόδου Κεντρικός Μετασχηματισμός Προετοιμασία δεδομένων εξόδου και έξοδος 38

39 Απεικόνιση ΚΜ σε ΔΔΠ Μονάδα ελέγχου εκτέλεσης Μονάδες λήψης δεδοµένων εισόδου (περισσότερες από μία, όσες και οι εισερχόμενες ροές στο συγκεκριμένο μετασχηματισμό στο ΔΡΔ) Μονάδες υπολογισμού δεδομένων ΚΜ (τουλάχιστον μία) Μονάδες εξόδου αποτελεσµάτων (περισσότερες από μία, όσες και οι εξερχόμενες ροές στο συγκεκριμένο μετασχηματισμό στο ΔΡΔ) Το σχέδιο που αντιστοιχεί στον ΚΜ έχει τόσες µονάδες υπολογισμού δεδομένων όσοι είναι και οι απλοί µετασχηµατισµοί που αποτελούν τον ΚΜ Απεικόνιση ΚΜ σε ΔΔΠ Λήψη και προετοιμασία δεδομένων εισόδου Κεντρικός Μετασχηματισμός Προετοιμασία δεδομένων εξόδου και έξοδος Mονάδα ελέγχου Λήψη δεδομένων εισόδου Εκτέλεση υπολογισμ ών Έξοδος αποτελεσμ άτων 39

40 Κέντρο Δοσοληψιών Κέντρο δοσοληψιών (ΚΔ): ένας µετασχηµατισµός του ΔΡΔ που δέχεται κάποια δεδοµένα εισόδου και παράγει ένα σύνολο δεδοµένων εξόδου ανάλογα µε την τιµή των δεδοµένων εισόδου ΠΡΟΣΟΧΗ Ένας ΚΜ µπορεί να περιέχει περισσότερους από ένα µετασχηµατισµούς του ΔΡΔ Ένα ΚΔ περιέχει µόνο ένα μετασχηματισμό του ΔΡΔ Έλεγχος ροής προγράµµατος μενού επιλογών Μεταφορά ροής σε διαφορετικούς µετασχηµατισµούς Κέντρο Δοσοληψιών Λήψη και προετοιμασία δεδομένων εισόδου Κεντρικός Μετασχηματισμός Προετοιμασία δεδομένων εξόδου και έξοδος 40

41 Απεικόνιση ΚΔ σε ΔΔΠ Λήψη και προετοιμασία δεδομένων εισόδου Κεντρικός Μετασχηματισμός Mονάδα ελέγχου Προετοιμασία δεδομένων εξόδου και έξοδος Λήψη δεδομένων εισόδου Εκτέλεση υπολογισμ ών Μονάδα ελέγχου περίπτωσης 1 Μονάδα ελέγχου περίπτωσης 2. Βήματα κατασκευής ΔΔΠ Μετάβαση από ΔΡΔ σε ΔΔΠ με διαδοχική επανάληψη βηµάτων µέχρι να προσδιοριστούν µονάδες για όλους τους µετασχηµατισµούς των ΔΡΔ Βήματα Εντοπισµός ΚΜ Καθορισμός μονάδων εισόδου (αφορούν λήψη δεδομένων) Καθορισμός μονάδων εκτέλεσης διαφόρων υπολογισμών που αφορούν τον ΚΜ Καθορισμός μονάδων εξόδου (αφορούν έξοδο αποτελεσμάτων) Απεικόνιση ΚΜ σε ΔΔΠ - Δηµιουργείται επίπεδο που αντιστοιχεί στον ΚΜ Παραγοντοποίηση (factoring) - και για τα δύο τµήµατα του ΚΜ (είσοδοι και έξοδοι) δηµιουργούμε ΔΔΠ 41

42 Βήματα κατασκευής ΔΔΠ Επανάληψη διαδικασίας µέχρι να φτάσουµε στις πηγές και τους αποδέκτες των δεδοµένων (χρήστη, εξωτερικά συστήµατα, συσκευές ή αρχεία). Συνένωση Όταν τα δεδοµένα δεν λαµβάνονται από εξωτερική πηγή ή δεν καταλήγουν σε εξωτερικό αποδέκτη, η µονάδα που τα εισάγει στον κεντρικό µετασχηµατισµό αντικαθίσταται από τη µονάδα ελέγχου του µετασχηµατισµού που τα παρέχει. Κατά τη διαδικασία αυτή ενδεχοµένως να διαπιστωθεί ότι είναι χρήσιµο να πραγµατοποιηθούν τροποποιήσεις στα ΔΡΔ οπισθοδρόµηση Πανεπιστήμιο Πειραιά Τμήμα Ψηφιακών Συστημάτων Σχεδίαση Συστήματος Λογισμικού Λεπτομερής Σχεδίαση Μονάδων 42

43 Προϊόντα σχεδίασης λογισμικού Διάγραμμα Ροής Δεδομένων Έγγραφο Προδιαγραφών Διάγραμμα Μετάβασης Καταστάσεων Διάγραμμα Οντοτήτων- Συσχετίσεων Λεξικό Δεδομένων ΣΧΕΔΙΑΣΗ Αρχιτεκτονικό Σχέδιο Σχέδιο Διαπροσωπειών Σχέδιο Μονάδων Σχέδιο Δεδομένων Λεπτομερής σχεδίαση μονάδων: ψευδοκώδικας Από το αρχιτεκτονικό σχέδιο (ΔΔΠ) και τις προδιαγραφές των απαιτήσεων πάμε στη λεπτοµερή σχεδίαση των µονάδων λογισµικού που περιέχονται στο αρχιτεκτονικό σχέδιο Προσδιορίζεται η εσωτερική δοµή κάθε µονάδας περιγραφή πηγαίου κώδικα με χρήση «ψευδοκώδικα» Τελευταίο βήμα πριν την κωδικοποίηση Αποτυπώνεται: η ιεραρχία των μονάδων προγράμματος τα δεδομένα με τα οποία επικοινωνούν οι μονάδες ο τρόπος με τον οποίο κινούνται τα δεδομένα 43

44 Λεπτομερής σχεδίαση μονάδων: ψευδοκώδικας Βήματα Κάθε µονάδα του ΔΔΠ αντιστοιχεί σε µια µονάδα κώδικα Εκτενής περιγραφή των μονάδων και όχι του συστήματος Μπορεί να χρειάζεται σε περίπτωση μη αναλυτικού ΔΔΠ, η απεικόνιση μίας μονάδας ΔΔΠ σε περισσότερες από µία µονάδες λογισµικού Ανάλυση σε διαδοχικά βήµατα μέχρι να φτάσουμε σε απλές δοµικές µονάδες λογισµικού «διαδικασίες» και «συναρτήσεις» Εκλέπτυνση σε διαδοχικά βήµατα (stepwise refinement) ή συναρτησιακή αποσύνθεση (functional decomposition) Περιγραφή λεπτομερούς σχεδίασης Διάφοροι τρόποι Πιο συνηθισμένος µε χρήση γλώσσας περιγραφής προγράµµατος (PDL: program description language) Ψευδοκώδικας Τι είναι? Μοιάζει µε γλώσσα προγραµµατισµού, όχι όμως αυστηρή στη σύνταξη και γραµµατική που χαρακτηρίζει τις γλώσσες προγραµµατισµού Παρέχει εικόνα του λογισµικού για εύκολη υλοποίηση σε κάποια γλώσσα προγραµµατισµού. Περιέχει τις βασικές δοµές ελέγχου των γλωσσών προγραµµατισµού 44

45 Προβλήματα στη σχεδίαση Ποιο είναι το καλύτερο από τα σχέδια που µπορεί να συλλάβει ο σχεδιαστής? Ποιος είναι ο προσφορότερος τρόπος για την περιγραφή του λεπτοµερούς σχεδίου µονάδων? Πώς σχετίζεται το σχέδιο µε τη γλώσσα προγραµµατισµού και το περιβάλλον υλοποίησης? Πώς µπορεί ένα λεπτοµερές σχέδιο µονάδων να διατηρείται επίκαιρο? Δύσκολες απαντήσεις Πολλές παράμετροι και υποκειµενικές προσεγγίσεις Προβλήματα στη σχεδίαση Υπάρχει ανεξαρτησία του λεπτοµερούς σχεδίου µονάδων από τη γλώσσα προγραµµατισµού? Ο σχεδιαστής σίγουρα έχει στο µυαλό του τη γλώσσα προγραµµατισµού για την υλοποίηση του σχεδίου Να διατηρείται επίκαιρο? Με εργαλεία υποστήριξης ανάπτυξης λογισµικού (CASE) Το λογισµικό δεν παραµένει στατικό και υπόκειται σε πολλές αλλαγές κατά τον κύκλο ζωής του (για διόρθωση σφαλµάτων ή για µεταβολή χαρακτηριστικών του) Οι αλλαγές πρέπει να γίνονται πρώτα στο σχέδιο κι έπειτα στον πηγαίο κώδικα - στην πράξη ΟΧΙ όταν έχουμε σχεδίαση με το χέρι 45

46 Δημιουργία ψευδοκώδικα Προσέχουμε! Ο ψευδοκώδικας ενός τμήματος προκύπτει από το αντίστοιχο ΔΔΠ και πρέπει να αντικατοπτρίζει τη δομή του ΔΔΠ, συμπληρωμένη με λογική μεταφορά του ελέγχου εκτέλεσης (δηλ. προγραμματισμένες δομές, όπως απόφαση, επανάληψη, καταχώρηση κτλ.) Από τη στιγμή που το ΔΔΠ είναι αρκετά λεπτομερές, κάθε μονάδα του ΔΔΠ αντιστοιχεί σε μία απλή μονάδα κώδικα, δηλ. διαδικασία ή συνάρτηση και επομένως για όλες τις μονάδες του ΔΔΠ χρειάζεται να κατασκευαστεί ψευδοκώδικας. Δημιουργία ψευδοκώδικα Προσέχουμε! Στις κλήσεις των procedures θα πρέπει να βάζουμε και τις παραμέτρους στις οποίες επιστρέφονται οι τιμές όταν εκτελείται η διαδικασία. Και όταν ορίζουμε τις διαδικασίες θα πρέπει να βάζουμε τα ορίσματα και να γράφουμε κι αν είναι μεταβλητές εισόδου (ΙΝ), εξόδου (OUT ή IN/OUT θέμα σύμβασης) ή και τα δύο. 46

47 Λεπτομερές σχέδιο: ψευδοκώδικας Αποτυπώνει: την ιεραρχία των μονάδων προγράμματος τα δεδομένα με τα οποία επικοινωνούν οι μονάδες τον τρόπο με τον οποίο κινούνται τα δεδομένα Υλοποιεί τις προδιαγραφές Δημιουργία ψευδοκώδικα από ΔΔΠ με κεντρικό μετασχηματισμό Α ExecM1 Β Α,Β Γ,Δ Γ Δ Ψευδοκώδικας για τη μονάδα ελέγχου Procedure ExecM1 Local Var Α,Β,Γ,Δ Αρχικοποίηση Α,Β,Γ,Δ Call GetΑ(Α) Call GetΒ(Β) Call CalcM1(Α,Β,Γ,Δ) Call PutΓ(Γ) Call PutΔ(Δ) end_procedure GetA GetB CalcM1 Procedure CalcM1 (Α,Β:IN, Γ,Δ:ΙΝ/OUT) Υπολόγισε τα Γ,Δ από τα Α,Β end_procedure PutΓ Ψευδοκώδικας για τη μονάδα υπολογισμού PutΓ PutΔ 47

48 ExecM1 Α Β Α,Β Γ,Δ Γ Δ GetA GetB CalcM1 PutΓ PutΓ PutΔ Ψευδοκώδικας για τις μονάδες λήψης δεδομένων Procedure GetΑ (Α:ΙΝ/ΟUT) Διάβασε το Α end_procedure Procedure GetΒ (Β:ΙΝ/ΟUT) Διάβασε το Β end_procedure Ψευδοκώδικας για τις μονάδες εξόδου αποτελεσμάτων Procedure PutΓ (Γ:ΙΝ) Γράψε το Γ end_procedure Procedure PutΔ (Δ:ΙΝ) Γράψε το Δ end_procedure Δημιουργία ψευδοκώδικα από ΔΔΠ με κέντρο δοσοληψιών Α ExecM1 Β Α,Β Γ Γ1 Γ2 Γ3 GetA GetB CalcM1 ExecM2 ExecM3 ExecM4 Ψευδοκώδικας για τη μονάδα ελέγχου Procedure ExecM1 Local Var Α,Β,Γ,Γ1,Γ2,Γ3 Αρχικοποίηση Α,Β,Γ,Γ1,Γ2,Γ3 Call GetΑ(Α) Call GetΒ(Β) Call CalcM1(Α,Β,Γ) Case Γ of (Γ1):Call ExecM2(Γ1); (Γ2):Call ExecM3(Γ2); (Γ3):Call ExecM4(Γ3); end_case end_procedure Procedure CalcM1 (Α,Β:IN, Γ:ΙΝ/OUT) Υπολόγισε το Γ από τα Α,Β Ψευδοκώδικας για τη μονάδα υπολογισμού end_procedure 48

49 ExecM1 Α Β Α,Β Γ Γ1 Γ2 Γ3 GetA GetB CalcM1 ExecM2 ExecM3 ExecM4 Ψευδοκώδικας για τις μονάδες λήψης δεδομένων Procedure GetΑ(Α:ΙΝ/ΟUT) Διάβασε το Α End_Procedure Procedure GetΒ(Β: ΙΝ/ΟUT) Διάβασε το Β End_Procedure Ψευδοκώδικας για τις μονάδες ελέγχου Procedure ExecM2(Γ1:ΙΝ) End_Procedure Procedure ExecM3(Γ2:ΙΝ) End_Procedure Procedure ExecM4(Γ3:ΙΝ) End_Procedure Σχεδίαση δεδομένων Σύλληψη δοµής και συσχετίσεων δεδοµένων Καθορίζει πολλά από τα χαρακτηριστικά των λειτουργικών µονάδων λογισµικού Σκοπός είναι ο προσδιορισµός των δοµών δεδοµένων που εντοπίζονται κατά τη φάση της προδιαγραφής των απαιτήσεων από το λογισµικό. Επαρκής προσδιορισµός για την απεικόνιση των δεδοµένων στο περιβάλλον υλοποίησης Στενά συνυφασµένη µε την εργασία κατάστρωσης των υπόλοιπων τµηµάτων του σχεδίου λογισµικού Αντικείµενο των βάσεων δεδοµένων. Αποτέλεσµα: λεπτοµερής περιγραφή οντοτήτων και συσχετίσεων 49

50 Προϊόντα σχεδίασης λογισμικού Διάγραμμα Ροής Δεδομένων Έγγραφο Προδιαγραφών Διάγραμμα Μετάβασης Καταστάσεων Διάγραμμα Οντοτήτων- Συσχετίσεων Λεξικό Δεδομένων ΣΧΕΔΙΑΣΗ Αρχιτεκτονικό Σχέδιο Σχέδιο Διαπροσωπειών Σχέδιο Μονάδων Σχέδιο Δεδομένων Σχεδίαση δεδομένων - Εργασίες Τροποποίηση του διαγράμματος οντοτήτων-συσχετίσεων (ΔΟΣ), ώστε να περιέχει ακριβώς όση πληροφορία απαιτείται, κατανεµηµένη σωστά µεταξύ των οντοτήτων για πληροφοριακή πληρότητα και εξάλειψη πλεονάζουσας (redundant) πληροφορίας «κανονικοποίηση» Καθορισµός των πεδίων που περιέχει κάθε πίνακας στο επίπεδο της φυσικής αποθήκευσης δεδοµένων Καθορισµός των εναλλακτικών µορφών εµφάνισης της οργάνωσης των δεδοµένων πάνω από το φυσικό επίπεδο (ορισµός views στο λογικό επίπεδο) Βελτιστοποιήσεις µε σκοπό τη βελτιστοποίηση των επιδόσεων και, γενικά, την επίτευξη κριτηρίων επάρκειας. 50

51 Σχεδίαση δεδομένων κάποιες αρχές Η σχεδίαση δεδοµένων δεν πρέπει να υποτιµάται. Να αποδίδεται χρόνος και σηµασία. Η πειθαρχηµένη εφαρµογή αρχών σχεδίασης ανταποδίδει το χρόνο Εντοπισμός όλων των δοµών δεδοµένων πάνω στα οποία επιδρούν οι µονάδες λογισµικού. Μετά από τη σχεδίαση δεν θα πρέπει να υπάρχουν απροσδιόριστα δεδοµένα για το µέλλον Το λεξικό δεδοµένων θα πρέπει να τηρείται ενηµερωµένο Σχεδίαση δεδομένων κάποιες αρχές Λήψη αποφάσεων σχεδίασης δεδοµένων σε σχέση με κατασκευαστικές λεπτοµέρειες όσο πιο αργά γίνεται όχι εύκολη η αποφυγή εξάρτησης αποτελεσµάτων σχεδίασης δεδοµένων από το περιβάλλον υλοποίησης ΟΧΙ καλή ιδέα οποιαδήποτε µονάδα λογισµικού να µπορεί να διαβάσει και να µεταβάλει δεδοµένα. ΑΡΑ θα πρέπει να καθορίζεται κατά τη σχεδίαση ποιες µονάδες λογισµικού επιτρέπεται να επιδρούν κατευθείαν στα δεδοµένα µείωση παρενεργειών στο λογισµικό Διερεύνηση δυνατότητας χρήσης έτοιµων δοµών δεδοµένων από βιβλιοθήκες. Γενικευµένη χρήση βιβλιοθηκών συστατικών λογισµικού όχι δυνατή µέχρι σήµερα εφαρµογή όμως σε µικρή κλίµακα µέσα στην εµβέλεια ενός κατασκευαστή λογισµικού συχνά αποδίδει. 51

52 Σχεδίαση δεδομένων αποτελέσματα Τελικό διάγραµµα οντοτήτων-συσχετίσεων (ΔΟΣ) Ενηµερωµένο λεξικό δεδοµένων Παράγραφοι εγγράφου περιγραφής σχεδίου λογισµικού: 2.3 Αποσύνθεση δεδοµένων Περιγραφή οντότητας δεδοµένων Περιγραφή οντότητας δεδοµένων Εξαρτήσεις µεταξύ δεδοµένων 6. Λεπτοµερές σχέδιο δεδοµένων 6.1 Οντότητα δεδοµένων Οντότητα δεδοµένων 2 Πηγές / Acknowledgements Β. Βεσκούκης «Τεχνολογία Λογισμικού Ι», ΕΑΠ, ΠΑΤΡΑ, 2000 X. Κούτσικας «Παραγωγή ψευδοκώδικα από διάγραμμα δομής προγράμματος», Εναλλακτικό Διδακτικό Υλικό, ΕΑΠ Χ. Αντωνόπουλος «Ανάπτυξη και Σχεδίαση Λογισμικού», Τμήμα Μηχ. Η/Υ, Τηελεπικοινωνιών και Δικτύων, Παν. Θεσσαλίας, 2007 S. L. Pfleeger, «Τεχνολογία Λογισμικού Θεωρία και πράξη», 2η έκδοση, Τόμοι Α και Β (μετάφραση, εκδ. Κλειδάριθμος) I. Sommerville, «Βασικές αρχές Τεχνολογίας Λογισμικού», 8 η αγγλική έκδοση (μετάφραση, εκδ. Κλειδάριθμος) Roger S. Pressman. Software Engineering - A Practitioner's Approach. McGraw-Hill, 6 th edition, 2005 ΙΕΕΕ Guide to Software Design Descriptions, ANSI/IEEE, Std