2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης1 ΟΙΚΟΝΟΜΙΚΟ ΠΑΝΕΠΙΣΤΗΜΙΟ ΑΘΗΝΩΝ ΤΜΗΜΑ ΠΛΗΡΟΦΟΡΙΚΗΣ ΤΕΧΝΟΛΟΓΙΑ ΛΟΓΙΣΜΙΚΟΥ Κατασκευή Λογισμικού (2/2) Μανόλης Γιακουμάκης αναπληρωτής καθηγητής ΟΠΑ

2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης2 Σημερινή παρουσίαση (1/3) Έλεγχος συνένωσης –Συνένωση big-bang –Ανοδική συνένωση –Καθοδική συνένωση –Συνένωση σάντουιτς –Συνένωση λειτουργικότητας –Συνένωση και οικοδόμηση

2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης3 Σημερινή παρουσίαση (2/3) Διασφάλιση ποιότητας πέρα από τον έλεγχο –Απόδειξη της ορθότητας των προγραμμάτων –Τεχνικές ανασκοπήσεις –Προγραμματισμός κατά ζεύγη –Σχετικές επιδόσεις μεθόδων διασφάλισης ποιότητας –Μετρικές –Αυτόματες επιθεωρήσεις

2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης4 Σημερινή παρουσίαση (3/3) Αναδόμηση –Τι είναι η αναδόμηση –Ένα παράδειγμα αναδόμησης –Όρια αναδόμησης Ανάπτυξη καθοδηγούμενη από τον έλεγχο

Έλεγχος συνένωσης Η συνένωση (integration) είναι η διαδικασία με την οποία οι διαφορετικές μονάδες λογισμικού συνδυάζονται, έτσι ώστε να προκύψει το σύστημα λογισμικού.

Συνένωση big-bang

Ανοδική συνένωση

Καθοδική συνένωση

Τροποποιημένη Καθοδική συνένωση

Συνένωση σάντουιτς

Συνένωση τροποποιημένου σάντουιτς

Συνένωση λειτουργικότητας

Συνένωση και οικοδόμηση Η συνένωση των μονάδων λογισμικού σχετίζεται άμεσα και με την οικοδόμηση (build) του συστήματος. Η οικοδόμηση του συστήματος είναι η μεταγλώττιση και η συνένωση όλου του κώδικα, έτσι ώστε να προκύψει το λογισμικό ως σύστημα. Η οικοδόμηση του λογισμικού, όταν αυτό αποτελείται από ένα αρχείο πηγαίου κώδικα και αναπτύσσεται από έναν και μόνο προγραμματιστή, δεν είναι ιδιαίτερα προβληματική. 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης13

Συνένωση και οικοδόμηση Από τη στιγμή όμως που η ανάπτυξη του λογισμικού πραγματοποιείται από μία ομάδα και περιλαμβάνει δεκάδες, εκατοντάδες ή και χιλιάδες αρχεία πηγαίου κώδικα, η οικοδόμηση του λογισμικού, προκειμένου να φθάσει στην εκτελέσιμη μορφή του, είναι αρκετά πολύπλοκη. Η οικοδόμηση του λογισμικού φέρνει και στην επιφάνεια και τα σφάλματα συνένωσης. 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης14

Ημερήσια Οικοδόμηση Η ημερήσια οικοδόμηση είναι μία στρατηγική, με την οποία το λογισμικό οικοδομείται καθημερινά. Η οικοδόμηση συνοδεύεται από ένα γρήγορο έλεγχο (smoke test) ο οποίος, αν και δεν είναι εξαντλητικός, θεωρείται ως επαρκής για να διαπιστωθεί η υγεία της οικοδόμησης. Εάν η οικοδόμηση του συστήματος αποτύχει, τότε η ανάκαμψη σε σωστή οικοδόμηση θεωρείται για την ομάδα ανάπτυξης ως πρώτη προτεραιότητα. Επειδή η ημερήσια οικοδόμηση γίνεται καθημερινά, είναι απαραίτητη η αυτοματοποίησή της. 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης15

Ημερήσια Οικοδόμηση Η ημερήσια οικοδόμηση παρέχει πολλά πλεονεκτήματα, όπως: Μείωση κινδύνων. Διατηρεί την υψηλή ποιότητα του λογισμικού. Η ημερήσια οικοδόμηση γίνεται καθημερινά άρα και ο γρήγορος έλεγχος θα πρέπει να εξασκείται καθημερινά. Η ημερήσια οικοδόμηση παρέχει συνεχή πληροφόρηση για την κατάσταση του έργου. 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης16

Συνεχής συνένωση Επειδή ακριβώς η συνένωση και η οικοδόμηση που τη συνοδεύει είναι μία επίπονη διαδικασία, πολλοί προτείνουν την ακόμα πιο συχνή συνένωση και οικοδόμηση του λογισμικού. Η συνεχής συνένωση (continuous integration) [Duvall 07] μας προτείνει καταρχήν ότι ένας προγραμματιστής θα πρέπει να υποβάλλει τον κώδικα (check-in) πολλές φορές την ημέρα. Αντιστοίχως το λογισμικό θα πρέπει να οικοδομείται επίσης πολλές φορές την ημέρα. 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης17

Συνεχής συνένωση Η βασική ιδέα της συνεχούς συνένωσης είναι απόρροια μίας εκ των βασικότερων αρχών της τεχνολογίας λογισμικού, ότι όσο νωρίτερα διαπιστωθεί ένα σφάλμα, τόσο λιγότερο κοστίζει η διόρθωσή του. Είναι προφανές ότι στη συνεχή συνένωση οι ανάγκες αυτοματοποίησης είναι πιο επιτακτικές. 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης18

Συνεχής συνένωση

Απόδειξη της ορθότητας των προγραμμάτων Θέλουμε κατά κάποιο τρόπο να καταδείξουμε πως το πρόγραμμα είναι σωστό. Ένας τρόπος για την εξέταση της ορθότητας του προγράμματος είναι να δούμε το πρόγραμμα ως κατάσταση λογικής ροής. Αν μπορούμε να ξαναγράψουμε το πρόγραμμα με όρους τυπικού λογικού συστήματος (όπως μια σειρά καταστάσεων και πράξεων πάνω σε δεδομένα), τότε μπορούμε να ελέγξουμε την ορθότητα αυτής της νέας διατύπωσης. 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης20

Απόδειξη της ορθότητας των προγραμμάτων

Μετρικές Μετρική (metric) είναι η ποσοτικοποιημένη μέτρηση του βαθμού με τον οποίο ένα σύστημα, μία συνιστώσα ή διαδικασία κατέχει κάποιο συγκεκριμένο χαρακτηριστικό [IEEE 90]. Με άλλα λόγια η μετρική μάς προσφέρει μία ποσοτικοποίηση κάποιου χαρακτηριστικού του λογισμικού. Έχουμε για παράδειγμα το χαρακτηριστικό της πολυπλοκότητας του λογισμικού. Θα πρέπει να ορίσουμε μία μετρική (ή μετρικές) με την οποία να μπορούμε να ποσοτικοποιήσουμε αυτό το χαρακτηριστικό. 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης22

Μετρικές Μία κατηγοριοποίηση των μετρικών για την ανάπτυξη λογισμικού είναι : Μετρικές του προϊόντος (product metrics). Είναι μετρικές που σχετίζονται με το προϊόν που αναπτύσσεται. Μετρικές του έργου (project metrics). Είναι μετρικές που αφορούν το συγκεκριμένο έργο ανάπτυξης. Μετρικές της διαδικασίας (process metrics). Μετρικές που αφορούν την ίδια τη διαδικασία ανάπτυξης λογισμικού και αφορούν πολλά έργα ανάπτυξης στην πάροδο του χρόνου. 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης23

Μέγεθος Η απλούστερη μετρική είναι ο αριθμός των γραμμών κώδικα (Lines of Code ή LOC) ή χιλιάδων γραμμών κώδικα (KLOC). Η μέτρηση των γραμμών κώδικα (χωρίς τα σχόλια και κενές γραμμές) γίνεται σε επίπεδο μονάδας (μεθόδου ή κλάσης) ή ακόμα και στο σύνολο του λογισμικού. Σε επίπεδο μεθόδου είναι μία ένδειξη για την πολυπλοκότητα και την κατανοησιμότητα της μεθόδου. Σε επίπεδο του συνόλου του λογισμικού είναι ένα κριτήριο για να κατατάξουμε την πολυπλοκότητα και το μέγεθος του λογισμικού που αναπτύσσουμε. 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης24

Μέγεθος Αν και οι γραμμές κώδικα δεν μετρούν την πολυπλοκότητα του λογισμικού, είναι προφανές ότι σχετίζονται με αυτή. Όσο αυξάνονται οι γραμμές του κώδικα, τόσο αυξάνει και η πολυπλοκότητα του λογισμικού. 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης25

Πολυπλοκότητα Μία παλαιά μετρική που έχει αποδείξει την αξία της στο πέρασμα του χρόνου είναι η κυκλωματική πολυπλοκότητα (cyclomatic complexity – CC) [McCabe 76]. Βασικό κριτήριο για την εκτίμηση της πολυπλοκότητας μίας μονάδας λογισμικού (π.χ. μίας μεθόδου) είναι η διακλάδωση στη ροή ελέγχου. Προτάσεις if, switch, for και while διακλαδώνουν τη ροή ελέγχου. Το αποτέλεσμα είναι η αύξηση της πολυπλοκότητας του λογισμικού. 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης26

Πολυπλοκότητα Η κυκλωματική πολυπλοκότητα μετρά τον αριθμό των διαφορετικών μονοπατιών στη ροή μίας μονάδας. Περισσότερα μονοπάτια σημαίνει και μεγαλύτερη πολυπλοκότητα. Ο τύπος υπολογισμού της κυκλωματικής πολυπλοκότητας είναι: CC = P + 1 Όπου P ο αριθμός των Boolean αποφάσεων σε μονάδα. Μία σειριακή εκτέλεση εντολών μας δίνει CC=1 και κάθε εντολή ροής ελέγχου προσθέτει κατά ένα. Ένας τρόπος υπολογισμού για κώδικα σε Java είναι να ξεκινήσουμε από ένα και να προσθέτουμε κάθε φορά που συναντούμε προτάσεις if, for, while, case και catch ή τους τελεστές &&, || και ?. 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης27

Πολυπλοκότητα Στο αντικειμενοστρεφές λογισμικό η κυκλωματική πολυπλοκότητα εφαρμόζεται στο επίπεδο μίας μεθόδου. Μία μετρική για την πολυπλοκότητα μίας κλάσης είναι οι Σταθμισμένες Μέθοδοι ανά Κλάση (Weighted Methods per Class – WMC) [Chidamber 94]. Υπολογίζεται ως εξής: n WMC = Σ ci i = 1 Η WMC υπολογίζεται ως το άθροισμα των μετρικών της πολυπλοκότητας κάθε μεθόδου για όλες τις μεθόδους (όπου n ο αριθμός των μεθόδων ανά κλάση και ci η πολυπλοκότητα κάθε μεθόδου). 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης28

Πολυπλοκότητα Η χρήση της μετρικής είναι γενική και δεν ορίζει ποια είναι η μετρική ci της πολυπλοκότητας κάθε μεθόδου. Είναι προφανές ότι, αν θεωρήσουμε ως ci την κυκλωματική πολυπλοκότητα μίας μεθόδου, έχουμε μία μετρική πολυπλοκότητας στο επίπεδο της κλάσης. 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης29

Συνεκτικότητα Για την αντικειμενοστρεφή σχεδίαση μία κλάση πρέπει να απεικονίζει μία αφαίρεση. Η έλλειψη συνεκτικότητας σημαίνει ότι η κλάση μπορεί να αναπαριστά δύο αφαιρέσεις και ίσως θα πρέπει να αλλάξει η σχεδίαση σε περισσότερες της μίας κλάσης. Θα εξετάσουμε δύο μετρικές για τη έλλειψη συνεκτικότητας των μεθόδων μίας κλάσης (Lack of Cohesion in Methods – LCOM). Η βασική ιδέα των παρακάτω μετρικών είναι να συσχετίσουμε τις μεθόδους μίας κλάσης με τα πεδία της. Μία κλάση θεωρείται συνεκτική, εάν οι μέθοδοι της κλάσης χρησιμοποιούν μεγάλο μέρος των πεδίων της. 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης30

Συνεκτικότητα Η πρώτη μετρική LCOM1, [Chidamber 94] λαμβάνει υπόψη της δύο όρους P και Q. Ο όρος P είναι ο αριθμός των ζευγών των μεθόδων της κλάσης που δεν έχουν κάποιο κοινό πεδίο. Ο όρος Q είναι ο αριθμός των ζευγών των μεθόδων της κλάσης που χρησιμοποιούν έστω και ένα κοινό πεδίο. Η μετρική LCOM1 υπολογίζεται ως εξής: LCOM1 = P – Q εάν P > Q, ή 0 εάν P<=Q Υψηλές τιμές της μετρικής σημαίνει και χαμηλότερη συνεκτικότητα. Αυτό με τη σειρά του σημαίνει ότι οι μέθοδοι είναι ανόμοιες, επειδή δε χρησιμοποιούν κοινά πεδία της κλάσης. 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης31

Συνεκτικότητα Ας θεωρήσουμε, για παράδειγμα, ότι μία κλάση έχει τα πεδία f1, f2, f3, και f4 και τις μεθόδους Μ1, Μ2, Μ3, και M4. Τα πεδία που χρησιμοποιεί κάθε μέθοδος είναι: Μ1f1, f2 M2f3 M3f2, f4 M4f1 Για να υπολογίσουμε του όρους P και Q, παίρνουμε όλα τα ζεύγη των μεθόδων και εξετάζουμε εάν έχουν κοινά πεδία. Ο όρος P είναι 4, επειδή τα ζεύγη M1-M2, M2-Μ3, M2-M4, M3-M4 δεν έχουν κάποιο κοινό πεδίο. Ο όρος Q είναι 2, επειδή τα ζεύγη M1-M3 και M1-M4 χρησιμοποιούν κοινά πεδία. Η μετρική LCOM1 είναι ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης32

Συνεκτικότητα Μία δεύτερη μέτρηση της έλλειψης συνεκτικότητας η LCOM2 έχει διαφορετικό τρόπο υπολογισμού [Henderson-Sellers 96]. Έστω: M: Το σύνολο των μεθόδων μίας κλάσης όπου ο αριθμός των μεθόδων ορίζεται ως m. F: Το σύνολο των πεδίων της κλάσης. p(f) ο αριθμός των μεθόδων της κλάσης που χρησιμοποιούν το πεδίο f το οποίο ανήκει στο F. ap ο μέσος αριθμητικών των p(f) ως προς το F 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης33

Συνεκτικότητα Η μετρική LCOM2 είναι: LCOM2 = (ap – m) / (1 – m) Η μετρική LCOM2 κινείται στο πεδίο [0-2]. Η τέλεια συνεκτικότητα είναι, όταν όλες οι μέθοδοι χρησιμοποιούν όλα τα πεδία της κλάσης και η τιμή της LCOM2 είναι 0. Εάν η LCOM2 είναι μεγαλύτερη του 1, έχουμε ένδειξη για χαμηλή συνεκτικότητα. 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης34

Συνεκτικότητα Για την προηγούμενη περίπτωση έχουμε: m=4 p(f1) = 2 p(f2) = 2 p(f3) = 1 p(f4) = 1 ap=6/4 Η LCOM2 υπολογίζεται: LCOM2 = 0, ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης35

Σύζευξη Οι απλούστερες μετρικές της σύζευξης είναι το fan-in και το fan-out. Για μία μονάδα λογισμικού το fan-in υπολογίζεται ως ο αριθμός των μονάδων που χρησιμοποιούν τη συγκεκριμένη μονάδα. Το fan-out αποτυπώνει την αντίστροφη σχέση. Τον αριθμό των μονάδων λογισμικού που χρησιμοποιεί η συγκεκριμένη μονάδα. Για το αντικειμενοστρεφές λογισμικό οι δύο μετρικές χρησιμοποιούνται σε επίπεδο κλάσης. Έτσι για μία κλάση υπολογίζουμε το fan-in ως τον αριθμό των κλάσεων που τη χρησιμοποιούν και το fan-out ως τον αριθμό των κλάσεων που χρησιμοποιεί η κλάση. 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης36

Σύζευξη Υψηλό fan-out θεωρείται ως ένδειξη υψηλής σύζευξης και πιθανή ένδειξη για τροποποίηση της σχεδίασης. Το fan-out το συναντούμε και ως μετρική για τη σύζευξη μεταξύ αντικειμένων (Coupling Between Objects – CBO) [Chidamber 94]. Η αξιολόγηση υψηλού fan-in είναι πιο σύνθετη. Αν για παράδειγμα επιδιώκουμε να μεγιστοποιήσουμε την επαναχρησιμοποίηση μίας κλάσης, τότε υψηλό fan-in σημαίνει και υψηλό βαθμό επαναχρησιμοποίησης και δε θα πρέπει να θεωρείται αναγκαστικά ως κακό σημάδι. 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης37

Σύζευξη Οι μετρικές του fan-in και fan-out μπορούν να γενικευτούν και σε επίπεδο πακέτων [Martin 03]. Έτσι ορίζουμε: Φυγόκεντρη Σύζευξη (Efferent Coupling-Ce). Είναι ο αριθμός των κλάσεων εντός του πακέτου οι οποίες εξαρτώνται από κλάσεις εκτός του πακέτου. Κεντρομόλος Σύζευξη (Afferent Coupling – Ca). Είναι ο αριθμός των κλάσεων εκτός του πακέτου οι οποίες εξαρτώνται από τις κλάσεις εντός του πακέτου. 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης38

Σύζευξη Μπορούμε να συνδυάσουμε τις δύο μετρικές Ca και Ce για να υπολογίσουμε την αστάθεια (instability) I ενός πακέτου ως εξής: I = Ce / (Ca + Ce) Η μετρική I της αστάθειας κινείται στο [0-1], όπου το 0 δείχνει τη μέγιστη ευστάθεια και το 1 τη μέγιστη αστάθεια. 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης39

Αναδόμηση πώς θα βελτιώσουμε τη σχεδίαση του λογισμικού, ενώ ήδη έχουμε προχωρήσει στον προγραμματισμό; Την απάντηση σε αυτό το ερώτημα τη δίνει η αναδόμηση η οποία είναι μία δομημένη και πειθαρχημένη μέθοδος που βελτιώνει τη σχεδίαση του λογισμικού σε υπάρχουσα βάση κώδικα [Fowler 99]. Η αναδόμηση είναι η διαδικασία που βελτιώνει την εσωτερική δομή του λογισμικού, χωρίς όμως να αλλάζει τη συμπεριφορά του. Κατά τη διάρκεια της αναδόμησης δεν προσθέτουμε κάτι στη λειτουργικότητα που παρέχει το λογισμικό, αλλά αλλάζουμε τον τρόπο με τον οποίο παρέχεται αυτή η λειτουργικότητα. 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης40

Αναδόμηση Ο σκοπός της αναδόμησης είναι η διατήρηση της καλής σχεδίασης που απεικονίζεται στον κώδικα. Η ποιότητα της σχεδίασης μπορεί να μειώνεται όσο γίνονται απείθαρχες αλλαγές στον κώδικα. Η αναδόμηση βελτιώνει τη δομή του λογισμικού, έτσι ώστε να διευκολύνει περαιτέρω αλλαγές που ίσως κριθούν αναγκαίες. Σε αντίθεση με τις απείθαρχες αλλαγές στον κώδικα, η αναδόμηση είναι μία διαδικασία που διαπιστώνει κάποιο συγκεκριμένο σύμπτωμα κακής σχεδίασης και με συγκεκριμένα και προβλέψιμα βήματα καταλήγει σε κάποια συγκεκριμένη βελτιωμένη εκδοχή του κώδικα. 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης41

Αναδόμηση Ορισμένα συμπτώματα κακής σχεδίασης που μπορούν να διαπιστωθούν σε υφιστάμενο κώδικα είναι: Διπλότυπα κώδικα. Δηλαδή η εμφάνιση του ίδιου τμήματος κώδικα σε δύο ή περισσότερα σημεία. Μεγάλες μέθοδοι με πολλές γραμμές κώδικα. Μεγάλες κλάσεις με χαμηλή συνεκτικότητα. Μέθοδοι με πολλές παραμέτρους. Μέθοδοι που βασίζονται περισσότερο σε παραμέτρους παρά στα πεδία της κλάσης στην οποία ανήκουν. Χρήση προτάσεων if ή switch οι οποίες μπορεί να αντικατασταθούν με πολυμορφισμό. 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης42

Αναδόμηση Χρήση πρωταρχικών τύπων αντί κλάσεων και αντικειμένων τιμών Παράλληλες ιεραρχίες κλάσεων όπου η εισαγωγή μίας υποκλάσης στη μία ιεραρχία οδηγεί αναγκαστικά και στην εισαγωγή μία άλλης υποκλάσης στη δεύτερη ιεραρχία. Συμπτώματα υψηλής σύζευξης μεταξύ κλάσεων. 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης43

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

Αναδόμηση Τα βήματα για την αντικατάσταση της κληρονομικότητας από τη μεταβίβαση είναι: Η δημιουργία ενός πεδίου στην υποκλάση με τύπο την υπερκλάση. Η αρχικοποίηση του πεδίου γίνεται σε this. Αλλαγή κάθε μεθόδου της υποκλάσης, έτσι ώστε να αναφέρεται στο προανεφρθέν πεδίο. Μετά την αλλαγή κάθε μεθόδου γίνεται μεταγλώττιση και εκτέλεση των αυτόματων ελέγχων. Διαγραφή της δήλωσης τη κληρονομικότητας και αρχικοποίηση του προανεφερθέντος πεδίου σε νέο αντικείμενο (αντί του this). 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης45

Αναδόμηση Για κάθε μέθοδο της υπερκλάσης που τη χρησιμοποιεί κάποιος κώδικας πελάτη εισάγεται μία νέα μέθοδος μεταβίβασης. Μεταγλώττιση και εκτέλεση των ελέγχων. 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης46