Προχωρημένη Τεχνολογία Λογισμικού (Advanced Software Engineering) Ενότητα – Critical Συστήματα Κεφάλαιο – Ανάπτυξη Critical Συστημάτων.

Παρουσίαση με θέμα: "Προχωρημένη Τεχνολογία Λογισμικού (Advanced Software Engineering) Ενότητα – Critical Συστήματα Κεφάλαιο – Ανάπτυξη Critical Συστημάτων."— Μεταγράφημα παρουσίασης:

1 Προχωρημένη Τεχνολογία Λογισμικού (Advanced Software Engineering) Ενότητα – Critical Συστήματα Κεφάλαιο – Ανάπτυξη Critical Συστημάτων

2 Στόχοι Να εξηγηθεί πώς η ανεκτικότητα σφαλμάτων και η αποφυγή σφαλμάτων συνεισφέρουν στην ανάπτυξη αξιόπιστων συστημάτων Να περιγραφούν χαρακτηριστικά αξιόπιστων διαδικασιών λογισμικού Να εισαχθούν προγραμματιστικές τεχνικές για την αποφυγή σφαλμάτων Να περιγραφούν μηχανισμοί ανεκτικότητας σφαλμάτων και η χρήση της ποικιλίας και πλεονασμού τους

3 Θέματα που καλύπτονται Αξιόπιστες διαδικασίες Αξιόπιστος προγραμματισμός Ανεκτικότητα σφαλμάτων Αρχιτεκτονικές ανεκτικές σε σφάλματα

4 Αξιοπιστία λογισμικού Γενικά, οι πελάτες λογισμικού προσδοκούν όλο το λογισμικό να είναι αξιόπιστο. Ωστόσο, για non-critical εφαρμογές, ίσως είναι πρόθυμοι να δεχτούν μερικές αποτυχίες συστήματος. Κάποιες εφαρμογές, ωστόσο, έχουν πολύ υψηλές απαιτήσεις αξιοπιστίας και μπορούν να χρησιμοποιηθούν ειδικές τεχνικές μηχανικής λογισμικού για να επιτευχθεί αυτό.

5 Επίτευξη αξιοπιστίας Αποφυγή σφαλμάτων – Το σύστημα έχει αναπτυχθεί με τέτοιο τρόπο ώστε να αποφεύγονται τα ανθρώπινα λάθη και έτσι ελαχιστοποιούνται τα σφάλματα συστήματος. – Η διαδικασία ανάπτυξης οργανώνεται έτσι ώστε να εντοπίζονται λάθη του συστήματος και να διορθώνονται πριν την παραλαβή από τον πελάτη. Εντοπισμός σφαλμάτων – Οι τεχνικές επικύρωσης και αξιολόγησης χρησιμοποιούνται για να ανακαλύπτονται και να αφαιρούνται σφάλματα από ένα σύστημα πριν αυτό αναπτυχθεί. Ανεκτικότητα σφαλμάτων – Το σύστημα σχεδιάζεται έτσι ώστε τα σφάλματα στο λογισμικό που έχει παραδοθεί να μην συμβάλουν στην αποτυχία του συστήματος.

6 Ποικιλία και πλεονασμός Πλεονασμός – Να κρατείται πάνω από μία έκδοση ενός critical συστατικού έτσι ώστε αν αποτύχει ένα τότε να είναι διαθέσιμο ένα εφεδρικό. Ποικιλία – Να παρέχεται η ίδια λειτουργικότητα με διαφορετικούς τρόπους έτσι ώστε να μην αποτύχουν με τον ίδιο τρόπο. Ωστόσο, η προσθήκη ποικιλίας και πλεονασμού προσθέτει πολυπλοκότητα και αυτό μπορεί να αυξήσει τις πιθανότητες λαθών. Μερικοί μηχανικοί υποστηρίζουν ότι η απλότητα και οι εκτεταμένες V & V είναι ένας πιο αποτελεσματικός δρόμος για να οδηγηθούμε στην αξιοπιστία λογισμικού.

7 Παραδείγματα ποικιλίας και πλεονασμού Πλεονασμός. Όπου είναι σημαντική η διαθεσιμότητα (π.χ. σε συστήματα ηλεκτρονικού εμπορίου), οι εταιρείες διαθέτουν εφεδρικούς εξυπηρετητές και μεταβαίνουν σε αυτούς αυτόματα όταν γίνεται μια αποτυχία. Ποικιλία. Για να παρέχεται ανθεκτικότητα σε εξωτερικές επιθέσεις, μπορεί να υλοποιούνται διαφορετικοί εξυπηρετητές με διαφορετικά λειτουργικά συστήματα (π.χ. Windows και Linux).

8 Λογισμικό χωρίς σφάλματα Πρόσφατες μέθοδοι μηχανικής λογισμικού επιτρέπουν την παραγωγή λογισμικών χωρίς σφάλματα, τουλάχιστον σε σχετικά μικρά συστήματα. Ένα λογισμικό χωρίς σφάλματα σημαίνει ένα λογισμικό το οποίο συμμορφώνεται με τις προδιαγραφές του. ΔΕΝ σημαίνει ότι είναι ένα λογισμικό το οποίο πάντα θα λειτουργεί σωστά καθώς μπορεί να υπάρχουν λάθη στις προδιαγραφές του. Το κόστος παραγωγής λογισμικών χωρίς σφάλματα είναι πολύ υψηλό. Είναι cost-effective μόνο σε εξαιρετικές περιπτώσεις. Συνήθως είναι φθηνότερο να γίνουν δεκτά σφάλματα λογισμικού και να πληρωθούν οι συνέπειές τους παρά να εξαντληθούν οι πόροι για την ανάπτυξη λογισμικού χωρίς σφάλματα.

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

10 Κόστος αφαίρεσης σφαλμάτων a

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

12 Χαρακτηριστικά αξιόπιστων διαδικασιών

13 Δραστηριότητες αξιολόγησης Επιθεωρήσεις απαιτήσεων. Διαχείριση απαιτήσεων. Έλεγχος μοντέλου. Επιθεώρηση σχεδιασμού και κώδικα. Στατική ανάλυση. Σχεδιασμός και διαχείριση ελέγχου. Η διαχείριση διαμόρφωσης, που συζητείται στο Κεφάλαιο 29, είναι επίσης σημαντική.

14 Αξιόπιστος προγραμματισμός Χρήση προγραμματιστικών κατασκευών και τεχνικών που συμβάλλουν στην αποφυγή σφαλμάτων και την ανεκτικότητα σφαλμάτων – Σχεδιασμός για απλότητα – Προστασία πληροφορίας από μη εγκεκριμένη πρόσβαση – Ελαχιστοποίηση της χρήσης μη ασφαλών προγραμματιστικών κατασκευών.

15 Προστασία πληροφορίας Η πληροφορία πρέπει να εκτίθεται μόνο στα σημεία εκείνα του προγράμματος που χρειάζεται να έχουν πρόσβαση. Αυτό περιλαμβάνει τη δημιουργία αντικειμένων ή αφηρημένων τύπων δεδομένων τα οποία διατηρούν την κατάσταση και παρέχουν λειτουργίες σε αυτήν την κατάσταση. Αυτό αποφεύγει τα σφάλματα για τρεις λόγους: – Μειώνεται η πιθανότητα τυχαίας κατάρρευσης της πληροφορίας – Η πληροφορία είναι περικυκλωμένη από ‘τοίχους προστασίας’ έτσι ώστε να είναι λιγότερο πιθανό να εξαπλωθούν τα προβλήματα και σε άλλα μέρη του προγράμματος – Καθώς όλη η πληροφορία είναι τοπική, είναι λιγότερο πιθανό κάποιος να κάνει λάθη και λιγότερο πιθανό να βρουν οι ελεγκτές λάθη.

16 Προδιαγραφή ουράς στη Java

17 Δήλωση της Signal στη Java

18 Ασφαλής προγραμματισμός Τα σφάλματα στα προγράμματα είναι συνήθως μια συνέπεια των λαθών που κάνουν οι προγραμματιστές. Αυτά τα λάθη γίνονται γιατί οι άνθρωποι δεν ‘ακολουθούν’ τις σχέσεις μεταξύ των μεταβλητών του προγράμματος.. Μερικές προγραμματιστικές κατασκευές έχουν μεγαλύτερη προδιάθεση στα λάθη από άλλες, έτσι η αποφυγή της χρήσης τους μειώνει τα λάθη του προγραμματιστή.

19 Δομημένος προγραμματισμός Αρχικά προτάθηκε το 1968 σαν μια προσέγγιση στην ανάπτυξη που κάνει τα προγράμματα πιο κατανοητά και αποφεύγει τα λάθη των προγραμματιστών. Προγραμματισμός χωρίς go-to. Βρόγχοι While και δηλώσεις if ως οι μόνοι έλεγχοι κατάστασης. Top-down σχεδιασμός. Μια σημαντική ανάπτυξη επειδή προώθησε τη σκέψη και τη συζήτηση για τον προγραμματισμό.

20 Κατασκευές με προδιάθεση στα λάθη Floating-point numbers – Έμφυτα ανακριβείς. Η ανακρίβεια μπορεί να οδηγήσει σε μη έγκυρες συγκρίσεις. Δείκτες – Δείκτες που αναφέρονται σε λάθος περιοχές μνήμης μπορούν να καταστρέψουν δεδομένα. Λανθασμένη ονομασία μπορεί να κάνει τα προγράμματα δυσνόητα και δύσκολα στην αλλαγή. Διανομή δυναμικής μνήμης – Η επιτόπου διανομή μπορεί να προκαλέσει υπερχείλιση μνήμης. Παραλληλισμός – Μπορεί να προκαλέσει περίπλοκα λάθη χρονισμού λόγω απρόβλεπτης αλληλεπίδρασης μεταξύ παράλληλων διαδικασιών. Αναδρομή – Λάθη στην αναδρομή μπορούν να προκαλέσουν υπερχείλιση μνήμης.

21 Κατασκευές με προδιάθεση στα λάθη Διακοπές – Οι διακοπές μπορούν να προκαλέσουν τον τερματισμό μιας σημαντικής λειτουργίας και κάνουν το πρόγραμμα δυσνόητο. Κληρονομικότητα – Ο κώδικας δεν είναι τοπικός. Αυτό μπορεί να έχει ως αποτέλεσμα απροσδόκητη συμπεριφορά όταν γίνονται αλλαγές και προβλήματα κατανόησης. Λάθος ονομασία – Η χρήση περισσότερων από ένα ονόματα για την αναφορά στην ίδια μεταβλητή. Μη οριοθετημένοι πίνακες – Μπορούν να συμβούν αποτυχίες λόγω υπερχείλισης του προσωρινού χώρου αποθήκευσης δεδομένων, αν δεν υπάρχει έλεγχος στα όρια των πινάκων. Διαδικασία προεπιλεγμένης εισόδου – Μια ενέργεια εισόδου που συμβαίνει άσχετα με την είσοδο.

22 Χειρισμός εξαιρέσεων Μια εξαίρεση προγράμματος είναι ένα λάθος ή κάποιο απροσδόκητο γεγονός όπως μια διακοπή ρεύματος. Οι κατασκευές χειρισμού εξαιρέσεων επιτρέπουν τη διαχείριση τέτοιων γεγονότων χωρίς να υπάρχει ανάγκη για συνεχή έλεγχο της κατάστασης για τον εντοπισμό εξαιρέσεων. Η χρήση κανονικών κατασκευών ελέγχου για τον εντοπισμό εξαιρέσεων απαιτεί πολλές επιπλέον καταστάσεις να προστεθούν στο πρόγραμμα. Αυτό προσθέτει σημαντικά παραπάνω πληροφορία και δημιουργεί ενδεχομένως προδιάθεση για λάθη.

23 Εξαιρέσεις στη Java 1

24 Εξαιρέσεις στη Java 2

25 Ένας ελεγκτής θερμοκρασίας Οι εξαιρέσεις μπορούν να χρησιμοποιηθούν ως μια κανονική τεχνική προγραμματισμού και όχι μόνο ως ένας τρόπος για ανάκαμψη από σφάλματα. Σκεφτείτε ένα παράδειγμα ενός ελεγκτή καταψύκτη που διατηρεί τη θερμοκρασία ψύξης μέσα σε ένα συγκεκριμένο όριο. Ανάβει ή σβήνει μια αντλία με ψυκτική ουσία. Σημαίνεται προειδοποίηση όταν υπερβαίνεται ένα μέγιστο επιτρεπτό όριο θερμοκρασίας.. Χρησιμοποιεί τις εξαιρέσεις σαν μια κανονική τεχνική προγραμματισμού.

26 Ελεγκτής θερμοκρασίας 1

27 Ελεγκτής θερμοκρασίας 2

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

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

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

31 Περιορισμοί κατάστασης αντλίας ινσουλίνης

32 Αναζήτηση σφαλμάτων Προληπτική αναζήτηση σφαλμάτων – Ο μηχανισμός αναζήτησης σφαλμάτων αρχικοποιείται πριν πραγματοποιηθεί η αλλαγή κατάστασης. Αν εντοπιστεί μια λανθασμένη κατάσταση, δε γίνεται η αλλαγή. Αναδρομική αναζήτηση σφαλμάτων – Ο μηχανισμός αναζήτησης σφαλμάτων αρχικοποιείται αφού έχει αλλάξει η κατάσταση του συστήματος. Αυτό χρησιμοποιείται όταν μια λανθασμένη ακολουθία από σωστές ενέργειες οδηγεί σε μια λανθασμένη κατάσταση ή όταν η αναδρομική αναζήτηση σφαλμάτων περιλαμβάνει πολύ επιπλέον πληροφορία.

33 Type system extension Preventative fault detection really involves extending the type system by including additional constraints as part of the type definition. Αυτοί οι περιορισμοί υλοποιούνται προσδιορίζοντας βασικές λειτουργίες μέσα στον ορισμό μιας κλάσης.

34 PositiveEvenInteger 1

35 PositiveEvenInteger 2

36 Αποτίμηση βλαβών Ανάλυση της κατάστασης του συστήματος για να κριθεί η έκταση της καταστροφής που προκλήθηκε από την αποτυχία του συστήματος. Η αποτίμηση πρέπει να ελέγχει ποια σημεία της κατάστασης έχουν επηρεαστεί από την αποτυχία. Είναι γενικά βασισμένη πάνω σε ‘validity functions’ οι οποίες μπορούν να εφαρμοστούν σε state elements για να αξιολογήσουν εάν οι τιμές τους εμπίπτουν μέσα σε αποδεκτά όρια τιμών.

37 Robust array 1

38 Robust array 2

39 Τεχνικές αποτίμησης βλαβών Checksums χρησιμοποιούνται για αποτίμηση βλαβών στη μετάδοση δεδομένων. Εφεδρικοί δείκτες μπορούν να χρησιμοποιηθούν για τον έλεγχο της ακεραιότητας των δομών δεδομένων. Watch dog χρονομετρητές μπορούν να ελέγχουν για μη-τερματιζόμενες διαδικασίες. Αν δεν υπάρχει απόκριση μετά από λίγη ώρα τότε υποθέτουμε ότι υπάρχει πρόβλημα.

40 Ανάκαμψη σφαλμάτων και διόρθωση Forward recovery – Εφαρμόζει διορθώσεις σε μια κατάσταση συστήματος που έχει καταρρεύσει. Backward recovery – Επαναφέρει την κατάσταση του συστήματος σε μια γνωστή ασφαλή κατάσταση. Forward recovery είναι συνήθως συγκεκριμένης εφαρμογής- απαιτούνται γνώσεις του πεδίου για να υπολογιστούν οι πιθανές διορθώσεις κατάστασης. Η backward ανάκαμψη λαθών είναι πιο απλή. Διατηρούνται λεπτομέρειες μιας ασφαλής κατάστασης και αυτή αντικαθιστά την κατάσταση του συστήματος που έχει καταρρεύσει.

41 Forward recovery Κατάρρευση της κωδικοποίησης λαθών – Τεχνικές κωδικοποίησης λαθών, οι οποίες προσθέτουν πλεονασμό σε κωδικοποιημένα δεδομένα, μπορούν να χρησιμοποιηθούν για διόρθωση δεδομένων που καταρρέουν κατά τη διάρκεια μιας μετάδοσης. Εφεδρικοί δείκτες – Όταν εφεδρικοί δείκτες συμπεριλαμβάνονται στις δομές δεδομένων (π.χ. λίστες διπλής διαδρομής) μια κατεστραμμένη λίστα ή filestore μπορεί να ξαναχτιστεί αν ένας ικανοποιητικός αριθμός δεικτών είναι αδιάφθοροι. – Συνήθως χρησιμοποιούνται για διόρθωση βάσεων δεδομένων και φακέλων συστήματος.

42 Backward recovery Οι συναλλαγές είναι μια συχνά χρησιμοποιούμενη μέθοδος της backward ανάκαμψης. Δεν εφαρμόζονται οι αλλαγές ωσότου ολοκληρωθούν οι υπολογισμοί. Αν προκύψει ένα λάθος, το σύστημα παραμένει στην κατάσταση που προηγείται της συναλλαγής. Περιοδικά σημεία ελέγχου επιτρέπουν στο σύστημα να επανέρχεται στη σωστή κατάσταση.

43 Ασφαλής διαδικασία ταξινόμησης Μια λειτουργία ταξινόμησης ελέγχει μόνη της την εκτέλεσή της και κάνει την αποτίμηση αν η ταξινόμηση έχει εκτελεστεί σωστά. Διατηρεί ένα αντίγραφο της εισόδου της έτσι ώστε αν συμβεί κάποιο λάθος να μην καταρρεύσει η είσοδος. Βασίζεται στην αναγνώριση και διαχείριση εξαιρέσεων. Είναι δυνατή σε αυτή την περίπτωση καθώς είναι γνωστή η προϋπόθεση για μια ‘έγκυρη’ ταξινόμηση. Ωστόσο, σε πολλές περιπτώσεις είναι δύσκολο να γραφτούν έλεγχοι εγκυρότητας.

44 Safe sort 1

45 Safe sort 2

46 Αρχιτεκτονική ανεκτική σε σφάλματα Ο αμυντικός προγραμματισμός δεν μπορεί να αντιμετωπίσει σφάλματα που περιλαμβάνουν αλληλεπιδράσεις μεταξύ υλικού και λογισμικού. Δυσνόηση των απαιτήσεων μπορεί να σημαίνει ότι οι έλεγχοι και ο σχετικός κώδικας είναι λανθασμένοι. Όπου τα συστήματα έχουν υψηλές απαιτήσεις διαθεσιμότητας, πρέπει να εφαρμόζεται μια συγκεκριμένη αρχιτεκτονική σχεδιασμένη για να υποστηρίζει ανεκτικότητα σφαλμάτων. Αυτό πρέπει να ανέχεται τόσο την αποτυχία του υλικού όσο και την αποτυχία του λογισμικού.

47 Ανεκτικότητα σφαλμάτων λογισμικού Εξαρτάτε από triple-modular redundancy (TMR). Υπάρχουν τρία επαναλαμβανόμενα πανομοιότυπα συστατικά που λαμβάνουν την ίδια είσοδο και των οποίων οι έξοδοι συγκρίνονται. Αν διαφέρει μία έξοδος, τότε αυτό αγνοείται και θεωρείται ότι υπάρχει αποτυχία συστατικών. Βασίζεται περισσότερο σε σφάλματα που προκύπτουν από αποτυχίες συστατικών απ’ ότι σε σχεδιαστικά σφάλματα και στη μικρή πιθανότητα μιας ταυτόχρονης αποτυχίας συστατικών.

48 Αξιοπιστία υλικού με TMR

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

50 Αρχιτεκτονικές λογισμικού ανεκτικό σε σφάλματα Η επιλογή της TMR στο να παρέχει ανεκτικότητα στα σφάλματα βασίζεται σε δύο θεμελιώσεις υποθέσεις – Τα συστατικά του υλικού δεν περιλαμβάνουν σφάλματα κοινού σχεδιασμού – Τα συστατικά αποτυγχάνουν τυχαία και υπάρχει μικρή πιθανότητα ταυτόχρονης αποτυχίας συστατικών. Καμία από αυτές τις υποθέσει δεν είναι αληθινή για το λογισμικό – Δεν είναι δυνατό να αντιγράφεις απλά το ίδιο συστατικό καθώς θα είχαν τα ίδια σχεδιαστικά σφάλματα – Η ταυτόχρονη αποτυχία συστατικών είναι ωστόσο ουσιαστικά ανέφικτη. Τα συστήματα λογισμικού πρέπει επομένως να είναι διαφορετικά.

51 Ποικιλία σχεδιασμού Διαφορετικές εκδόσεις ενός συστήματος σχεδιάζονται και υλοποιούνται με διαφορετικούς τρόπους. Επομένως, πρέπει να έχουν διαφορετικούς τρόπους αποτυχίας. Διαφορετικές προσεγγίσεις για σχεδιασμό (π.χ. προσανατολισμός στα αντικείμενα και προσανατολισμός στις συναρτήσεις) – Υλοποίησης σε διαφορετικές γλώσσες προγραμματισμού – Χρήση διαφορετικών εργαλείων και περιβάλλοντος ανάπτυξης – Χρήση διαφορετικών αλγορίθμων στην υλοποίηση.

52 Αναλογίες λογισμικού στην TMR Προγραμματισμός N-έκδοσης – Υλοποιούνται οι ίδιες προδιαγραφές σε έναν αριθμό διαφορετικών εκδόσεων από διαφορετικές ομάδες. Όλες οι εκδόσεις υπολογίζουν ταυτόχρονα και επιλέγεται η πλειοψηφία εξόδου χρησιμοποιώντας ένα σύστημα ψηφοφορίας. – Αυτή είναι η πιο κοινά χρησιμοποιούμενη προσέγγιση π.χ. σε πολλά μοντέλα του εμπορικού αεροσκάφους Airbus. Μπλοκ ανάκτησης – Γράφονται και εκτελούνται στη σειρά ένας αριθμός από ρητά διαφορετικές εκδόσεις με τις ίδιες προδιαγραφές. – Χρησιμοποιείται ένας έλεγχος αποδοχής για να επιλεγεί η έξοδος που θα μεταδοθεί.

53 Προγραμματισμός Ν-έκδοσης

54 Σύγκριση εξόδου Στα συστήματα υλικού, ο συγκριτής εξόδου είναι ένα απλό κομμάτι λογισμικού που χρησιμοποιεί ένα μηχανισμό ψηφοφορίας για να επιλέξει την έξοδο. Στα συστήματα πραγματικού χρόνου, μπορεί να υπάρχει η απαίτηση ότι τα αποτελέσματα από τις διαφορετικές εκδόσεις να παράγονται στο ίδιο χρονικό πλαίσιο.

55 Προγραμματισμός Ν-έκδοσης Οι διαφορετικές εκδόσεις συστήματος σχεδιάζονται και υλοποιούνται από διαφορετικές ομάδες. Θεωρείται ότι υπάρχει μικρή πιθανότητα να κάνουν τα ίδια λάθη. Οι αλγόριθμοι που χρησιμοποιούνται θα έπρεπε αλλά μπορεί να μη διαφέρουν. Υπάρχουν μερικές εμπειρικές αποδείξεις ότι οι ομάδες εξηγούν λανθασμένα τις προδιαγραφές με τον ίδιο τρόπο και διαλέγουν τους ίδιους αλγόριθμους στα συστήματά τους.

56 Μπλοκ ανάκτησης

57 Επιβάλλουν τη χρήση διαφορετικών αλγορίθμων για κάθε έκδοση έτσι ώστε να μειωθεί η πιθανότητα να υπάρχουν κοινά λάθη. Ωστόσο, ο σχεδιασμός του ελέγχου αποδοχής είναι δύσκολος καθώς πρέπει να είναι ανεξάρτητος από τον υπολογισμό που χρησιμοποιείται. Υπάρχουν προβλήματα με αυτήν την προσέγγιση για τα συστήματα πραγματικού χρόνου λόγω της ακολουθιακής λειτουργίας των εφεδρικών εκδόσεων.

58 Προβλήματα με την ποικιλία σχεδιασμού Οι ομάδες δεν είναι μορφωτικά διαφορετικές και έτσι τείνουν να αντιμετωπίζουν τα προβλήματα με τον ίδιο τρόπο. Χαρακτηριστικά λάθη – Διαφορετικές ομάδες κάνουν τα ίδια λάθη. Μερικά σημεία της υλοποίησης είναι πιο δύσκολα από άλλα, έτσι όλες οι ομάδες τείνουν να κάνουν λάθος στο ίδιο σημείο – Λάθη προδιαγραφών – Αν υπάρχει ένα λάθος στις προδιαγραφές τότε αυτό αντανακλάται σε όλες τις υλοποιήσεις – Αυτό μπορεί να ελεγχθεί σε κάποιο βαθμό, χρησιμοποιώντας πολλαπλές αναπαραστάσεις προδιαγραφών.

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

60 Σημαντικά σημεία Η αξιοπιστία σε ένα σύστημα μπορεί να επιτευχθεί μέσω της αποφυγής σφαλμάτων, του εντοπισμού σφαλμάτων και της ανεκτικότητας σφαλμάτων. Η χρήση του πλεονασμού και της ποικιλίας είναι σημαντική στην ανάπτυξη αξιόπιστων συστημάτων. Η χρήση καλά ορισμένης επαναλαμβανόμενης διαδικασίας είναι σημαντική εάν είναι να ελαχιστοποιηθούν σφάλματα σε ένα σύστημα. Μερικές προγραμματιστικές κατασκευές έχουν μια έμφυτη προδιάθεση στα λάθη – πρέπει να αποφεύγεται η χρήση του όπου είναι δυνατό.

61 Σημαντικά σημεία Οι εξαιρέσεις χρησιμοποιούνται για την υποστήριξη της διαχείρισης λαθών σε αξιόπιστα συστήματα. Οι τέσσερεις φάσεις της ανεκτικότητας σφαλμάτων σε ένα σύστημα είναι ο εντοπισμός σφαλμάτων, η αποτίμηση βλαβών, η ανάκτηση σφαλμάτων και η διόρθωση σφαλμάτων. Ο προγραμματισμός Ν-έκδοσης και τα μπλοκ ανάκτησης είναι εναλλακτικές προσεγγίσεις της αρχιτεκτονικής ανεκτικής σε σφάλματα.