ΕΑΠ-ΠΛΗ10/Εβδομάδα 8

Ασχολούνται με αυτή τη σελίδα

• Μιχάλης Γεωργουλόπουλος

Ύλη εβδομάδας

Δεύτερος τόμος, κεφάλαιο 4

Κεφάλαιο 4 - Σχεδίαση προγράμματος

Γιατί σχεδιάζουμε

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

Η σχεδίαση λογισμικού είναι τέχνη, απαιτεί εμπειρία. Υπάρχουν τεχνικές που μπορεί να ακολουθήσει κανείς, αλλά στην πράξη βασιζόμαστε στην κοινή λογική και την εμπειρία.

Πλεονεκτήματα της σχεδίασης

• η µειωµένη πολυπλοκότητα
• η διευκόλυνση της τροποποίησης
• η αποφυγή ανεπιθύµητων αποτελεσµάτων και
• η ευκολότερη και γρηγορότερη υλοποίηση

Μεθοδολογίες

• Ακολουθιακές - Αυστηρή εκτέλεση των φάσεων τη μία μετά την επιτυχή εκτέλεση της άλλης
• Επαναληπτικές, 2 τύποι
  • Όλες οι φάσεις επαναλαμβάνονται σε ένα κύκλο. Στο τέλος κάθε κύκλου το πρόγραμμα είναι έτοιμο και καλύτερο από ότι στον προηγούμενο.
  • Επομέρους φάσεις επαναλαμβάνονται όσες φορές χρειαστεί μέχρι να οδηγήσουν στην επόμενη φάση (πχ μεθοδολογία "καταρράκτη")

Κατεύθυνση σχεδίασης

Σχεδίαση από πάνω προς τα κάτω (top-down design)

Ξεκινάμε από το πρόβλημα (Μ) που θα πρέπει να λύσει το πρόγραμμά μας. Το σπάμε σε μικρότερα υποπροβλήματα (Ν1, Ν2 ... ΝΚ), και αυτά σε ακόμα μικρότερα ώσπου να καταλήξουμε σε πολύ απλά υποπροβλήματα. Σε κάθε στάδιο "διάσπασης", μας απασχολεί το πώς συντίθεται το Μ από τα Ν1..Κ, και όχι οι λεπτομέρειες του καθενός απο τα Ν. Αυτές τις βλέπουμε στο επόμενο βήμα διάσπασης.

Σχεδίαση από κάτω προς τα πάνω (bottom-up design)

Μερικές φορές ένα από τα υποπροβλήματα του Μ έχει πολύ συγκεκριμένες απαιτήσεις ή/και περιορισμούς. Σε αυτές τις περιπτώσεις συμφέρει πρώτα να ορίσουμε τα υποπροβλήματα και μετά να τα συνθέσουμε στο μεγαλύτερο.

Σχεδίαση από την μέση προς την άκρη (middle-out design)

Πολλές φορές στην πράξη η σχεδίαση είναι ένας συνδυασμός top-down & bottom-up. Αυτό λέγεται middle-out.

Όταν έχουμε να σχεδιάσουμε ένα πολύ πολύπλοκο λογισμικό, είναι δύσκολο τόσο το να δούμε την πλήρη εικόνα όσο και το να εντοπίσουμε τα κρίσιμα σημεία του. Σε αυτή την περίπτωση ξεκινάμε τη σχεδίαση από ένα ελαφρώς απλούστερο σχέδιο, μια υποπερίπτωση του πλήρους σχεδίου πχ. Για αυτή δουλεύουμε top-down ή/και bottom-up, ώσπου να αποκτήσουμε ένα πρώτο σχέδιο, το οποίο είναι μέρος της συνολικής εικόνας. Εξελίσσοντας αυτό το σχέδιο (μέση), φτάνουμε στο πλήρες (άκρη).

Κατεύθυνση υλοποίησης

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

Μπορούμε να χρησιμοποιήσουμε διαφορετική κατεύθυνση στη σχεδίαση και στην υλοποίηση. Πολύ συχνά έχουμε top-down σχεδίαση και bottom-up υλοποίηση.

Top-down programming

• Ασχολούμαστε πρώτα με το κύριο πρόγραμμα και συνθέτουμε τα "υποπρογράμματα" (κλάσεις/συναρτήσεις/ό,τι μας παρέχει η γλώσσα προγραμματισμού), χωρίς να τα έχουμε ακόμα αναπτύξει.
• Τεστάρουμε το μχανισμό συνεργασίας των "υποπρογραμμάτων"
• Τα "υποπρογράμματα" εδώ καλούνται "στελέχη" (stubs) γιατί είναι κενά ώσπου να τα υλοποιήσουμε και αυτά.

Bottom-up programming

• Ξεκινάμε πρώτα με την υλοποίηση των υποπρογραμμάτων
• Τεστάρουμε ένα ένα χωριστά.
• Μετά τα συνθέτουμε για να φτιάξουμε το πλήρες πρόγραμμα.

Επίπεδα αφαιρετικότητας (abstraction layers)

Είναι μια τεχνική σχεδίασης που χωρίζει το λογισμικό σε επίπεδα, και έχει κάποιους κανόνες για να μή γίνει χαμός:

• Κάθε επίπεδο χρησιμοποιεί πόρους μόνο από το αμέσως κατώτερο επίπεδο.
• Κάθε επίπεδο είναι αυτάρκες, δηλαδή μπορεί να λειτουργήσει εξίσου καλά εάν αντικαταστήσουμε το κατώτερό του επίπεδο με κάποιο άλλο που κάνει την ίδια δουλειά.
• Κάθε επίπεδο υλοποιεί κρυφή και φανερή λειτουργικότητα. Η κρυφή χρησιμοποιείται εντός του επιπέδου και δεν εκτίθεται έξω από αυτό. Η φανερή χρησιμοποιείται από το ανώτερο επίπεδο.
• Όσο πάμε προς ανώτερα επίπεδα η λειτουργικότητα γίνεται "αφαιρετική", δηλαδη τα ανώτερα επίπεδα δεν τα απασχολούν οι λεπτομέρειες λειτουργίας των κατώτερων (όπως ένα διευθυντή δεν τον απασχολούν οι λεπτομέρειες της εργασίας ενός υπαλήλλου, αλλά μόνο το αποτέλεσμα αυτής).

Μονάδα διάσπασης

Κατηγοριοποίηση μεθοδολογιών με βάση το πού δίνουν περισσότερη σημασία (στις διεργασίες ή στα δεδομένα):

Μεθοδολογίες βασισμένες στις διεργασίες

• Σπάμε διεργασίες σε μικρότερες διεργασίες κοκ.
• Η δομή του λογισμικού βασίζεται στη διάσπαση διεργασιών

Μεθοδολογίες βασισμένες στα δεδομένα

Χρησιμοποιούνται σε περιπτώσεις όπου οι δομές των δεδομένων θεωρούνται πιο "σταθερές" από τις διεργασίες που δρουν σε αυτά.

• Σπάμε τα δεδομένα σε κατηγορίες και υποκατηγορίες
• Η δομή του λογισμικού βασίζεται στη διάσπαση δεδομένων.

Συνδυαστικές μεθοδολογίες

• Δίνεται έμφαση εξίσου σε δεδομένα και διεργασίες.
• Παράδειγμα η "αντικειμενοστραφής" προσέγγιση.
• Σε αυτή το λογισμικό αποτελείται από αντικείμενα και τις μεταξύ τους σχέσεις.
• Τα αντικείμενα αντιπροσωπεύουν τόσο συλλογές δεδομένων όσο και τις διεργασίες που δρουν σε αυτά τα δεδομένα.

Front-to-back και Back-to-front design

Μια προσέγγιση στη σχεδίαση είναι να μελετήσουμε το σύστημα αναλύοντας τις εισόδους και εξόδους του. Γνωρίζοντας τί είσοδο θα παίρνει και ποιά θα πρέπει να είναι η έξοδος.

• Όταν μελετάμε τις εισόδους και σχεδιάζουμε διεργασίες (ή/και δεδομένα) μέχρι να φτάσουμε στις εξόδους έχουμε "προς τα εμπρός" (back-to-front) σχεδίαση.
• Το ανάποδο είναι "προς τα πίσω" (front-to-back) σχεδίαση.

Λειτουργική ανεξαρτησία

Όταν σπάμε ένα πρόγραμμα σε λίγο έως πολύ ανεξάρτητες μονάδες, οι οποίες ασχολούνται με ένα υποσύνολο του προβλήματος. Μετράμε τη λειτουργική ανεξαρτησία με 2 ποιοτικά κριτήρια: συνοχή και σύζευξη.

Συνοχή (cohesion)

• Το πρόγραμμα χωρίζεται σε τμήματα και κάθε τμήμα σε μονάδες. Μπορεί οι μονάδες να χωριστούν σε υπομονάδες αλλά τα ίδια ισχύουν και τότε.
• Όταν ομαδοποιούμε μονάδες σε τμήματα είναι καλό να βάζουμε τις "ομοειδείς" μονάδες στο ίδιο τμήμα.
• Αυτό λέγεται συνοχή.
• Με την υψηλή συνοχή επιτυγχάνεται καλύτερη "απόκρυψη πληροφοριών".
• Είναι το ίδιο με το να βάζουμε παρόμοια αρχεία στον ίδιο φάκελο (πχ όλα τα mp3 στο "music" και όλα τα jpg στο "photos"). Όσο περισσότερο τακτικά είναι, τόσο περισσότερη "συνοχή" έχει το σχέδιό μας, τόσο καλύτερο το σχέδιο.
• 7 βαθμοί συνοχής κατά Constantine και Yourdon (από χαμηλή σε υψηλή):
• Συµπτωµατική, Λογική, Χρονική,• Διαδικασιακή, Επικοινωνιακή,• Ακολουθιακή, Λειτουργική
• Χοντρικά, αν μπορούμε να περιγράψουμε το τμήμα με απλά λόγια έχουμε υψηλή συνοχή, αν όχι έχουμε χαμηλή.
• Πχ: "Αυτό το τμήμα έχει όλες τις μαθηματικές πράξεις για πίνακες" : ΥΨΗΛΗ ΣΥΝΟΧΗ

Σύζευξη (coupling)

• Η σύζευξη είναι μέτρο του βαθμού διασύνδεσης (αλληλεξάρτησης) μεταξύ των τμημάτων του προγράμματος.
• Ripple effect: Η διάδοση του λάθους που συμβαίνει σε ένα τμήμα, σε άλλα που διασυνδέονται με αυτό (πχ αν ένας υπολογισμός είναι λάθος, θα είναι λάθος και οι υπόλοιποι που εξαρτώνται από αυτόν).
• Στη σχεδίαση επιδιώκουμε χαμηλή σύζευξη και για να αποφύγουμε ripple effects, αλλά κυρίως για να κρατηθεί χαμηλά η πολυπλοκότητα του σχεδίου.

Είδη σύζευξης από το χειρότερο προς το καλύτερο (υψηλή προς χαμηλή):

Σύζευξη περιεχομένου

Το ένα τμήμα μεταφέρει τον έλεγχο στο άλλο ή/και τροποποιεί μεταβλητές του.

Κοινή σύζευξη

Χρήση από κοινού των ίδιων global δεδομένων.

Εξωτερική σύζευξη

Όταν 2 τμήματα επικοινωνούν με την ίδια εξωτερική συσκευή (η οποία επιβάλλει τις ίδιεσ προδιαγραφές και στα 2)

Σύζευξη ελέγχου

Αποστολή από το ένα τμήμα στο άλλο δεδομένων τα οποία επηρεάζουν τη ροή του δεύτερου.

Σύζευξη σφραγίδας

Ανταλλαγή δομών δεδομένων αντί για μια μόνο μεταβλητή.

Σύζευξη δεδομένων

Ανταλλαγή μόνο δεδομένων.

Εκτός Ύλης

• Code smell