Τεχνολογία Λογισμικού

Transcript

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

2 Πανεπιστήμιο Πειραιά Τμήμα Ψηφιακών Συστημάτων Σχεδίαση Συστήματος Λογισμικού Μέρος ΙΙ

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

4 Τι είναι η σχεδίαση Διεργασία μετατροπής του προβλήματος σε λύση Από το Τί στο Πώς Σχέδιο: Λεπτομερής περιγραφή της λύσης Λύση: Ικανοποιεί όλες τις απαιτήσεις της προδιαγραφής Είναι δυνατόν να υπάρχουν πολλαπλές λύσεις Πιθανόν να μην υπάρχει μοναδική «βέλτιστη» Αλλαγές (και πάλι )

5 Σκοπός Σχεδίασης Σχεδίαση λογισμικού η δημιουργική διαδικασία μετατροπής του προβλήματος σε λύση Τι ζητείται από τη σχεδίαση λογισμικού? Ένας τρόπος περιγραφής της κατασκευής του λογισμικού έτσι ώστε να ικανοποιεί τις προδιαγραφές που έχουν τεθεί, να μπορεί να εκτελεί τις επιθυμητές λειτουργίες και να μπορεί να έχει τα επιθυμητά χαρακτηριστικά Σχέδιο λογισμικού: η περιγραφή των μονάδων που αποτελούν το λογισμικό, των συσχετίσεων μεταξύ τους, της διάταξής τους και της εσωτερικής τους λειτουργίας

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

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

8 Εννοιολογικό και Τεχνικό Σχέδιο Παράδειγμα: Προσχέδιο και αναπαράσταση σπιτιού Παράδειγμα: Καλωδίωση, Υδραυλικά, υποστηρίγματα σπιτιού Το εννοιολογικό σχέδιο επικεντρώνει στις λειτουργίες του συστήματος, και το τεχνικό σχέδιο περιγράφει τη μορφή που θα πάρει το σύστημα

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

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

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

12 Εννοιολογικό και Τεχνικό Σχέδιο Παλινδρόμηση μεταξύ εννοιολογικού και τεχνικού σχεδίου ΕΝΝΟΙΟΛΟΓΙΚΟ ΣΧΕΔΙΟ ΤΕΧΝΙΚΟ ΣΧΕΔΙΟ Ο χρήστης θα έχει τη δυνατότητα να στέλνει μηνύματα σε οποιοδήποτε άλλο χρήστη βρίσκεται συνδεδεμένος στο δίκτυο Τοπολογία δικτύου Πρωτόκολλο Ρυθμός σε bps

13 Προσεγγίσεις σχεδίασης Δομημένη σχεδίαση (function oriented) προσανατολισμένη στις διαδικασίες βασίζεται και στις διαδικασίες και στα δεδομένα Αντικειμενοστρεφής σχεδίαση (object oriented) προσανατολισμένη στα αντικείμενα

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

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

16 Αποσύνθεση Αποσύνθεση: Από απεικόνιση υψηλού επιπέδου σε λεπτομερέστερες απεικονίσεις χαμηλότερων επιπέδων Αποσαφήνιση του τρόπου ταιριάσματος χαρακτηριστικών και λειτουργιών των τμημάτων του συστήματος

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

18 Χαρακτηριστικά σχεδίου Τμηματικότητα (Modularity): Κάθε δραστηριότητα του συστήματος (απλή ή σύνθετη) εκτελείται από μία μονάδα και οι είσοδοι έξοδοι κάθε μονάδας είναι καλά ορισμένες Μονάδες υψηλού επιπέδου: Βλέπουμε συνολικά το πρόβλημα Δεν εμπλεκόμαστε στις λεπτομέρειες Απομονώνουμε μέρη που είναι πιο δύσκολα Μονάδες χαμηλού επιπέδου: Απομονώνουν συγκεκριμένες λεπτομέρειες

19 Χαρακτηριστικά σχεδίου

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

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

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

23 Σύζευξη

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

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

26 Σύζευξη περιεχομένου Δύο μονάδες έχουν σύζευξη περιεχομένου (content coupling) εάν κώδικας στη μία μονάδα επηρεάζει και τροποποιεί άμεσα κώδικα στην άλλη μονάδα

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

28 Κοινή σύζευξη Μπορούμε να μειώσουμε τη σύζευξη τοποθετώντας δεδομένα σε κοινή περιοχή (π.χ. καθολικές μεταβλητές) Aλλαγές στις καθολικές μεταβλητές επηρεάζουν όλες τις μονάδες που έχουν πρόσβαση σε αυτές Δυσκολία εξακρίβωσης ποια μονάδα άλλαξε μια μεταβλητή

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

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

31 Σύζευξη δεδομένων Δύο μονάδες έχουν σύζευξη δεδομένων (data coupling) εάν η μία μονάδα περνάει σαν παραμέτρους στην άλλη μονάδα είτε απλούς τύπους δεδομένων είτε τιμές από συγκεκριμένα πεδία κλάσεων / δομών που είναι απολύτως απαραίτητα για τη λειτουργία της δεύτερης μονάδας Μια μονάδα μπορεί να τροποποιήσει τα ίδια τα δεδομένα μιας άλλης μονάδος (κλήση κατ αναφορά) ή να δράσει επάνω σε αντίγραφα των δεδομένων μιας άλλης μονάδος (κλήση κατ αξία)

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

33 Συνεκτικότητα Αναφέρεται στην εσωτερική συνοχή κάθε μονάδας Αν μία μονάδα είναι συνεκτική (cohesive) => όλα τα τμήματά της προορίζονται και είναι απαραίτητα για την εκτέλεση της ίδιας λειτουργίας Στόχος: η μεγαλύτερη δυνατή συνεκτικότητα κάθε μονάδος Υψηλή συνεκτικότητα (High cohesion): Τα τμήματα σε μια μονάδα προσφέρουν συναφείς υπηρεσίες και, έχουν σχέσεις εταιρικότητας Χαμηλή συνεκτικότητα (Low cohesion): Τα τμήματα σε μια μονάδα προσφέρουν άσχετες μεταξύ τους υπηρεσίες και δεν έχουν σχέσεις εταιρικότητας

34 Επίπεδα συνεκτικότητας Λιγότερο επιθυμητή Τυχαία Συνεκτικότητα (Coincidental Cohesion) Λογική Συνεκτικότητα (Logical cohesion) Χρονική Συνεκτικότητα (Temporal cohesion) Διαδικαστική Συνεκτικότητα (Procedural cohesion) Επικοινωνιακή Συνεκτικότητα (Communicational cohesion) Ακολουθιακή Συνεκτικότητα (Sequential cohesion) Λειτουργική Συνεκτικότητα (Functional cohesion) Περισσότερο επιθυμητή

35 Τυχαία συνεκτικότητα Έχουμε τυχαία συνεκτικότητα όταν τα τμήματα μιας μονάδας είναι εντελώς ασυσχέτιστα, έχουν τυχαίο τρόπο συγκρότησης, έχουν δομηθεί με τρόπο που δεν ακολουθεί κανόνες και αρχές της τεχνολογίας λογισμικού, αλλά άλλους «τυχαίους» κανόνες Η τυχαία συνεκτικότητα είναι η χειρότερη μορφή συνεκτικότητας και σχεδιαστικής δομής

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

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

38 Διαδικαστική συνεκτικότητα Μία μονάδα έχει διαδικαστική συνεκτικότητα εάν έχει δομηθεί με το κριτήριο ότι οι λειτουργίες της μονάδας σχετίζονται με κάποια ακολουθία βημάτων που θα πρέπει να ακολουθηθούν για την εκτέλεση κάποιας εργασίας Για παράδειγμα, εάν μία μονάδα έχει δομηθεί έτσι ώστε οι λειτουργίες να σχετίζονται με συγκεκριμένα βήματα μιας διαδικασίας όπως εισαγωγή δεδομένων από το πληκτρολόγιο, επιβεβαίωση δεδομένων, αποθήκευση δεδομένων σε μεταβλητές τότε η μονάδα θα έχει διαδικαστική συνεκτικότητα Η διαδικαστική συνεκτικότητα είναι πρακτικά χρονική συνεκτικότητα με τον επιπρόσθετο περιορισμό ότι οι λειτουργίες θα πρέπει να σχετίζονται και σαν βήματα κάποιας συγκεκριμένης διαδικασίας / εργασίας Ένα σύστημα που έχει δομηθεί με κριτήριο τη διαδικαστική συνεκτικότητα πιθανόν να έχει αρκετά πανομοιότυπα τμήματα πηγαίου κώδικα

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

40 Ακολουθιακή συνεκτικότητα Μία μονάδα έχει ακολουθιακή συνεκτικότητα εάν η έξοδος από το ένα τμήμα μιας μονάδος αποτελεί είσοδο σε επόμενο τμήμα της μονάδος

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

42 Θέματα ελέγχου Fan-in μιας μονάδας Πλήθος μονάδων που την ελέγχουν Fan-out μιας μονάδας Πλήθος μονάδων που ελέγχει

43 Στόχοι Στόχος 1: Ελαχιστοποίηση αριθμού μονάδων με υψηλό fan-out Μία μονάδα που ελέγχει πολλές άλλες, συνήθως εκτελεί πολλές εργασίες (κακή συνεκτικότητα). Δυσκολία στον εντοπισμό σφαλμάτων, στην τροποποίηση, στην επαναχρησιμοποίηση Στόχος 2: Μεγιστοποίηση αριθμού μονάδων με υψηλό fan-in Μία μονάδα που ελέγχεται από πολλές άλλες, είναι μονάδα γενικής χρησιμότητας και είναι σαφώς προτιμότερο μία λειτουργία που εκτελείται συχνά να βρίσκεται σε μία μονάδα, παρά κατανεμημένη ή υλοποιημένη σε πολλές μονάδες

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

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

46 Εξέλιξη σχεδίασης λογισμικού Είσοδο στην εργασία της σχεδίασης αποτελούν τα προϊόντα που έχουν παραχθεί κατά τη φάση της προδιαγραφής των απαιτήσεων από το λογισµικό. Η σχεδίαση λογισµικού είναι µια εργασία που προχωρά από τη µικρότερη στη µεγαλύτερη λεπτοµέρεια. Προδιαγραφές των απαιτήσεων από το λογισμικό Σύλληψη περιγράμματος Άτυπη σχεδίαση Λεπτομερής σχεδίαση Σχέδιο λογισμικού

47 Από την ανάλυση απαιτήσεων στη σχεδίαση

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

49 Δεδομένα και μονάδες λογισμικού στη δομημένη ανάλυση και σχεδίαση Αρχιτεκτονικό Σχέδιο ΜΟΝΑΔΕΣ ΛΟΓΙΣΜΙΚΟΥ Σχέδιο Διαπροσωπειών Σχέδιο Μονάδων Σχέδιο Δεδομένων ΔΕΔΟΜΕΝΑ

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

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

52 Επίπεδα αρχιτεκτονικού σχεδίου λογισμικού Σύστημα Υπό-σύστημα 1 ου επιπέδου Υπό-σύστημα 2 ου επιπέδου Υπό-σύστημα 3 ου επιπέδου

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

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

55 Σχεδίαση διαπροσωπειών Καθορισμός παραµέτρων επικοινωνίας µε άλλες µονάδες λογισµικού της εφαρµογής κατά την αρχιτεκτονική και λεπτοµερή σχεδίαση περιγράφονται στα Διαγράµµατα Δοµής Προγράµµατος και λεπτοµερές σχέδιο µονάδων Σχεδίαση διαπροσωπείας µε τον άνθρωπο εξαιρετικά πολύπλοκο πρόβληµα!

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

57 Σχεδίαση δεδομένων Σύλληψη δοµής και συσχετίσεων δεδοµένων Καθορίζει πολλά από τα χαρακτηριστικά των λειτουργικών µονάδων λογισµικού Από το λεξικό δεδοµένων και το διάγραµµα οντοτήτωνσυσχετίσεων: Βελτιστοποιήσεις στο ΔΟΣ για βελτιστοποίηση επιδόσεων, πληροφοριακή πληρότητα και εξάλειψη πλεονάζουσας (redundant) πληροφορίας Καθορισμός πεδίων και τύπων πινάκων (φυσικό επίπεδο) Καθορισμός των views των δεδοµένων (λογικό επίπεδο) Αντικείµενο των βάσεων δεδοµένων. Αποτέλεσµα: λεπτοµερής περιγραφή οντοτήτων και συσχετίσεων

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

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

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

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

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

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

64 Πηγές / 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