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

Από Βικιβιβλία
Πήδηση στην πλοήγηση Πήδηση στην αναζήτηση

Ασχολούνται με αυτή τη σελίδα[επεξεργασία]

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

Ύλη εβδομάδας[επεξεργασία]

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

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

Γιατί σχεδιάζουμε[επεξεργασία]

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

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

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

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

Μεθοδολογίες[επεξεργασία]

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

Κατεύθυνση σχεδίασης[επεξεργασία]

Russian-Matroshka no bg.jpg

Σχεδίαση από πάνω προς τα κάτω (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)

Σύζευξη ελέγχου[επεξεργασία]

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

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

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

Σύζευξη δεδομένων[επεξεργασία]

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

Εκτός Ύλης[επεξεργασία]