Μηχανική και Τεχνολογία Λογισμικού: Διάλεξη 4

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

ΘΕΩΡΙΑ

4: Σχεδίαση Συστήματος

• Αρχιτεκτονική και Σχέδιο Λογισμικού:

• Η φάση σχεδίασης κατά την ανάπτυξη λογισμικού περιλαμβάνει δύο κύριες λειτουργίες: την αρχιτεκτονική και την τεχνική σχεδίαση. Το τελικό προϊόν της σχεδίασης, το τεχνικό σχέδιο του λογισμικού, συνιστά την περιγραφή μίας λύσης στο εξής πρόβλημα: την κατασκευή ενός συστήματος το οποίο να ικανοποιεί τις απαιτήσεις και τις προδιαγραφές που έχουν ήδη καθοριστεί.
• Η αρχιτεκτονική του λογισμικού είναι μία υψηλού επιπέδου περιγραφή των επιμέρους μονάδων από τις οποίες πρέπει να αποτελείται το ζητούμενο σύστημα, καθώς και των αλληλεξαρτήσεων μεταξύ τους.
• Η τεχνική σχεδίαση προκύπτει από την ανάλυση κάθε μονάδας σε διαδοχικά  επίπεδα ολοένα αυξανόμενης λεπτομέρειας. Έτσι κάθε υποσύστημα αναλύεται σε συστατικά για τα οποία δίνεται αναλυτική περιγραφή, ενώ διευκρινίζονται οι τρόποι με τους οποίους αυτά αλληλεπιδρούν και σχετίζονται. Στη συνέχεια τα εν λόγω συστατικά αναλύονται περαιτέρω, και ούτω καθεξής.
• Επομένως, το τεχνικό σχέδιο παράγεται από την αρχιτεκτονική. Η επικρατέστερη μέθοδος για την επίτευξη αυτής της παραγωγής είναι η αντικειμενοστρεφής ανάλυση, όπου κάθε υποσύστημα αναλύεται σε κλάσεις σχετιζόμενων αντικειμένων. Αυτό δεν συνεπάγεται ότι κατά τη φάση της υλοποίησης το λογισμικό θα προγραμματιστεί σύμφωνα με το αντικειμενοστρεφές προγραμματιστικό παράδειγμα.
• Το πρότυπο UML καθορίζει ορισμένα διαγράμματα τα οποία αφορούν τη φάση σχεδίασης. Π.χ. τα διαγράμματα πακέτων απεικονίζουν την αρχιτεκτονική, ενώ τα διαγράμματα κλάσεων (στατικά ως προς τον χρόνο) και διαγράμματα κατάστασης (δυναμικά ως προς τον χρόνο) απεικονίζουν το τεχνικό σχέδιο.
  
  

• Ποιότητα Λογισμικού:

• Η φάση σχεδίασης πρέπει να δίνει ως αποτέλεσμα ποιοτικό λογισμικό. Αυτό σημαίνει πως το τεχνικό σχέδιο έχει τέτοιο χαρακτήρα, ώστε να επιτρέπει την εύκολη υλοποίηση, έλεγχο και συντήρηση του λογισμικού. Είναι επομένως σημαντικό, στο μέτρο του δυνατού φυσικά, κάθε αλλαγή σε ένα συστατικό να μην επηρεάζει άλλα συστατικά, ώστε να διευκολύνεται η μελλοντική συντήρηση του κώδικα.
• Δύο έννοιες παίζουν κεντρικό ρόλο στον καθορισμό της ποιότητας ενός αντικειμενοστρεφούς τεχνικού σχεδίου λογισμικού: η «σύζευξη» (coupling) και η «συνεκτικότητα» (cohesion). Εξίσου σημαντική είναι η υποστήριξη ανοχής σε βλάβες και η ανίχνευση σφαλμάτων.

• Σύζευξη:

• Σύζευξη ονομάζεται ο βαθμός στον οποίον έναν συστατικό εξαρτάται από άλλα. Υψηλή σύζευξη οδηγεί σε ανεπιθύμητες αλληλεπιδράσεις, αφού το συστατικό είναι πολύ ευαίσθητο σε αλλαγές ή σφάλματα άλλων κλάσεων, ενώ μειώνεται η ευκολία με την οποία μπορεί να επαναχρησιμοποιηθεί, εφόσον δεν είναι αυτοτελές. Ένα ελάχιστο σύζευξης είναι προφανώς αναγκαίο να εμφανίζεται στο σχέδιο, καθώς κάποιο τελείως ανεξάρτητο συστατικό το οποίο δεν αλληλεπιδρά ποτέ με άλλα συνήθως δεν έχει καμία χρησιμότητα, αλλά η ποιοτική σχεδίαση πρέπει να οδηγεί σε όσο το δυνατόν μικρότερη ολική σύζευξη.
• Η εξάρτηση μίας κλάσης Α από μία κλάση Β μπορεί να προκύψει με πολλαπλούς τρόπους:
  

  • Μία μέθοδος της Α καλεί εσωτερικά μία μέθοδο της Β.
  • Μία μέθοδος της Α τροποποιεί απευθείας ένα γνώρισμα / πεδίο της Β.
  • Μία μέθοδος της Α προσπελαύνει τα ίδια κοινά δεδομένα με μία μέθοδο της Β.
  • Μία μέθοδος της Α περιέχει μία δομή επιλογής (π.χ. «if - then - else»), έτσι ώστε η ροή ελέγχου του προγράμματος να εξαρτάται από την τιμή εξόδου κάποιας μεθόδου της Β.
• Ένα συστατικό Α το οποίο εξαρτάται από ένα άλλο συστατικό Β, είναι πιθανώς ευαίσθητο σε κάθε τροποποίηση της λειτουργικότητας, της προγραμματιστικής διασύνδεσης που εξάγει (αγγλ: Application Programming Interface, API), της υλοποίησης ή του τρόπου αναπαράστασης δεδομένων του Β.

• Συνοχή:

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

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

• Σφάλματα και Βλάβες::

• Ένα ποιοτικό λογισμικό πρέπει να έχει, ήδη από τη φάση της σχεδίασης, πρόβλεψη για μηχανισμούς ανίχνευσης σφαλμάτων και ανοχής σε βλάβες.
• Η ανίχνευση σφαλμάτων αφορά τη διαχείριση λαθών στα οποία μπορεί να περιέλθει ένα σύστημα κατά τον χρόνο εκτέλεσής του. Είναι αναγκαίο κατά τη σχεδίαση να προβλεφθούν όσο το δυνατόν περισσότερα σφάλματα και λάθη τα οποία μπορεί να προκύψουν κατά τη λειτουργία του τελικού λογισμικού (π.χ. αποτυχία λόγω παροχής εσφαλμένων δεδομένων εισόδου από τους χρήστες).
• Στο τεχνικό σχέδιο πρέπει να προβλέπονται συστατικά ή στοιχεία συστατικών τα οποία αναλαβάνουν να χειριστούν λάθη και καταστάσεις αποτυχίας. Αυτό είναι εφικτό με διάφορους τρόπους: π.χ. με επαναφορά του συστήματος σε προγενέστερη ορθή και αυτοσυνεπή κατάσταση, με επανάληψη της διαδικασίας η οποία προκάλεσε το λάθος, με αυτόματη αναφορά του προβλήματος σε κάποιο αρχείο καταγραφής αναγνώσιμο από διαχειριστές συστήματος κλπ.
• Για τη διαχείριση κατά τον χρόνο εκτέλεσης του συστήματος λαθών τα οποία δεν είναι δυνατόν να προβλεφθούν από τους σχεδιαστές, είναι απαραίτητη η υποστήριξη ανοχής σε βλάβες. Έτσι π.χ. όλα τα συστατικά του σχεδίου λειτουργούν υποθέτωντας ότι τα άλλα συστατικά ίσως παρουσιάζουν κάποιο σφάλμα, επομένως διενεργούν πάντα ελέγχους ορθότητας για τα δεδομένα εισόδου που λαμβάνου από άλλα συστατικά. Ακόμα, ένας συνηθισμένος τρόπος επίτευξης ανοχής σε βλάβες είναι ο πλεονασμός (redundancy).
• Πλεονασμός σημαίνει πως τα σημαντικότερα συστατικά του λογισμικού υπάρχουν σε πολλαπλά αντίγραφα («ρέπλικες»), επομένως αν το κύριο συστατικό αποτύχει κατά τον χρόνο εκτέλεσης για οποιονδήποτε λόγο, μία ρέπλικα μπορεί να αναλάβει τη διεκπεραίωση της λειτουργίας του.
• Για λόγους μεγιστοποίησης της αξιοπιστίας, είναι δυνατόν όλες οι ρέπλικες να ενεργοποιούνται από κοινού με το κύριο συστατικό για την εκτέλεση μίας λειτουργίας, ακόμα και αν το τελευταίο δεν εμφανίσει κανένα λάθος. Στη συνέχεια οι έξοδοι όλων των αντιγράφων συγκρίνονται και, αν είναι ταυτόσημες, αυξάνεται η πιθανότητα να έχουν όλα κυλήσει ομαλά.