ΟΙΚΟΝΟΜΙΚΟ ΠΑΝΕΠΙΣΤΗΜΙΟ ΑΘΗΝΩΝ ΤΜΗΜΑ ΠΛΗΡΟΦΟΡΙΚΗΣ. ΜΕΤΑΠΤΥΧΙΑΚΟ ΔΙΠΛΩΜΑ ΕΙΔΙΚΕΥΣΗΣ (MSc) στα ΠΛΗΡΟΦΟΡΙΑΚΑ ΣΥΣΤΗΜΑΤΑ ΔΙΠΛΩΜΑΤΙKH ΕΡΓΑΣΙΑ

Transcript

1 ΟΙΚΟΝΟΜΙΚΟ ΠΑΝΕΠΙΣΤΗΜΙΟ ΑΘΗΝΩΝ ΤΜΗΜΑ ΠΛΗΡΟΦΟΡΙΚΗΣ ΜΕΤΑΠΤΥΧΙΑΚΟ ΔΙΠΛΩΜΑ ΕΙΔΙΚΕΥΣΗΣ (MSc) στα ΠΛΗΡΟΦΟΡΙΑΚΑ ΣΥΣΤΗΜΑΤΑ ΔΙΠΛΩΜΑΤΙKH ΕΡΓΑΣΙΑ «Αναδόμηση Κώδικα με Πρότυπα Σχεδίασης» Γαϊτάνη Μαρία-Άννα ΜΜ ΑΘΗΝΑ, ΣΕΠΤΕΜΒΡΙΟΣ 2013

2

3 ΜΕΤΑΠΤΥΧΙΑΚΟ ΔΙΠΛΩΜΑ ΕΙΔΙΚΕΥΣΗΣ (MSc) στα ΠΛΗΡΟΦΟΡΙΑΚΑ ΣΥΣΤΗΜΑΤΑ ΔΙΠΛΩΜΑΤΙKH ΕΡΓΑΣΙΑ «Αναδόμηση Κώδικα με Πρότυπα Σχεδίασης» Γαϊτάνη Μαρία-Άννα ΜΜ Επιβλέπων Καθηγητής: Γιακουμάκης Εμμανουήλ Εξωτερικός Κριτής: Μαλεύρης Νικόλαος ΟΙΚΟΝΟΜΙΚΟ ΠΑΝΕΠΙΣΤΗΜΙΟ ΑΘΗΝΩΝ ΤΜΗΜΑ ΠΛΗΡΟΦΟΡΙΚΗΣ ΑΘΗΝΑ, ΣΕΠΤΕΜΒΡΙΟΣ 2013

4 Ευχαριστίες Θα ήθελα να ευχαριστήσω όλους τους ανθρώπους οι οποίοι συνέβαλαν καθοριστικά στην ολοκλήρωση αυτής της διπλωματικής εργασίας. Καταρχάς, θα ήθελα να εκφράσω την ευγνωμοσύνη μου στον επιβλέποντα καθηγητή μου κ. Εμμανουήλ Γιακουμάκη για την εμπιστοσύνη που μου έδειξε και για την ευκαιρία που μου έδωσε να ασχοληθώ με ένα τόσο ενδιαφέρον ερευνητικό θέμα. Επίσης, θερμά τον ευχαριστώ για την καθοδήγηση που μου παρείχε καθ όλη τη διάρκεια της εκπόνησης της διπλωματικής μου εργασίας. Επιπλέον, θα ήθελα να ευχαριστήσω θερμά τον διδάκτορα Πληροφορικής κ. Νικόλαο Διαμαντίδη και τον διδάκτορα Πληροφορικής κ. Βασίλη Ζαφείρη γιατί χωρίς την πολύτιμη βοήθειά τους δε θα ήταν δυνατή η ολοκλήρωση της διπλωματικής μου εργασίας. Ιδιαιτέρως τους ευχαριστώ για την άψογη συνεργασία μας και για τον πολύτιμο χρόνο που διέθεσαν για να με υποστηρίξουν και καθοδηγήσουν καθ όλη τη διάρκεια της εκπόνησης της εργασίας μου. Και οι δυο τους με τις γνώσεις τους, τις ιδέες τους, τις χρήσιμες συμβουλές τους και με περίσσεια υπομονή στάθηκαν αρωγοί μου καθ όλη τη διάρκεια της ερευνητικής μου μελέτης και της συγγραφής της διπλωματικής μου εργασίας. Αφιερώνω τη διπλωματική μου εργασία στους γονείς μου Γιώργο και Ελένη και στον αδερφό μου Παναγιώτη, που πάντα στέκονται στο πλευρό μου και με στηρίζουν σε όλες μου τις επιλογές, και στον αρραβωνιαστικό μου Γιάννη, για την αμέριστη συμπαράσταση, βοήθεια και υπομονή που επέδειξε καθ όλη τη διάρκεια των μεταπτυχιακών μου σπουδών και με αυτόν τον τρόπο βοήθησε να γίνει πιο εύκολο και ευχάριστο αυτό το δύσκολο έργο. 4

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

6 αναπτυχθεί. Ωστόσο, η πλειοψηφία των εργαλείων αυτόματης αναδόμησης υποστηρίζει μόνο απλές αναδομήσεις χαμηλού επιπέδου, χωρίς να παρέχει τη δυνατότητα αυτοματοποιημένης εκτέλεσης πιο σύνθετων αναδομήσεων, όπως οι αναδομήσεις που αποσκοπούν στην εισαγωγή κάποιου σχεδιαστικού προτύπου. Την έλλειψη αυτή προτίθεται να μειώσει η παρούσα διπλωματική εργασία, η οποία και μελετά το πρόβλημα της αυτοματοποίησης της αναδόμησης προς το σχεδιαστικό πρότυπο Null Αντικείμενο (Null Object). Το πρότυπο Null Object, βασιζόμενο στις αρχές της κληρονομικότητας και του πολυμορφισμού, ενδείκνυται να χρησιμοποιηθεί στις περιπτώσεις όπου υπάρχουν στον κώδικα επαναλαμβανόμενοι έλεγχοι αν ένα αντικείμενο είναι διάφορο του null προτού σταλεί ένα μήνυμα σε αυτό. Στόχος της μεθοδολογίας που αναπτύχθηκε είναι η αυτοματοποιημένη ανίχνευση περιπτώσεων που είναι δυνατή η εφαρμογή του προτύπου Null Object. Επιπλέον, η προτεινόμενη προσέγγιση επιτρέπει, για τις περιπτώσεις που πληρούν τα κριτήρια αυτόματης εφαρμογής της αναδόμησης, και την αυτοματοποιημένη ανασύνταξη του πηγαίου κώδικα ώστε να εφαρμοστεί η δομή του προτύπου. Πιο συγκεκριμένα, η προτεινόμενη μεθοδολογία περιορίζεται στην ανίχνευση και απομάκρυνση υποθετικής λογικής που ελέγχει αν ένα πεδίο είναι ίσο ή όχι με null προτού καλέσει κάποια μέθοδο αυτού, ώστε να αποφευχθεί η πρόκληση Null Pointer Exception, μιας και o προγραμματιστής δεν είναι σίγουρος αν στο πεδίο έχει τεθεί τιμή διάφορη του null. Προκειμένου να οριοθετηθεί το πρόβλημα της ανίχνευσης των περιπτώσεων αναδόμησης προς το πρότυπο Null Object, η προτεινόμενη μεθοδολογία ανίχνευσης, αρχικά προσπαθεί να εντοπίσει σε κάθε κλάση του υπό εξέταση κώδικα εκείνα τα πεδία της που είναι τύπου κάποιας κλάσης του υπό εξέταση συστήματος, ώστε να είναι δυνατή η εφαρμογή της αναδόμησης. Τα πεδία αυτά στη συνέχεια εξετάζονται για να εξακριβωθεί αν ικανοποιούν ένα σύνολο επιλεγμένων κριτηρίων που υποδηλώνουν ότι υπάρχει μεγάλη πιθανότητα στην κλάση όπου ορίζονται να υπάρχουν υποθετικές εκφράσεις που ελέγχουν αν η τιμή τους ισούται ή όχι με null. Κάθε πεδίο που ικανοποιεί τα κριτήρια της προηγούμενης ανάλυσης χαρακτηρίζεται ως υποψήφιο για την εφαρμογή της αναδόμησης προς το πρότυπο Null Object. Στη συνέχεια εξετάζεται κατά πόσο υπάρχουν υποθετικές δηλώσεις που ελέγχουν αν το 6

7 πεδίο είναι ίσο ή διάφορο του null και οι οποίες πληρούν ένα σύνολο κριτηρίων που καθιστούν δυνατή τη διαγραφή τους, εξασφαλίζοντας παράλληλα τη μη εισαγωγή σφαλμάτων και τη διατήρηση της συμπεριφοράς του λογισμικού. Μόνο τα πεδία για τα οποία θα ανιχνευτούν υποθετικές δηλώσεις υποψήφιες για διαγραφή θα θεωρηθούν τελικά κατάλληλα για την εφαρμογή της αναδόμησης προς το πρότυπο Null Object, μιας και μόνο τότε θα έχουμε όφελος από τη χρήση του προτύπου. Επιπλέον, ένα τρίτο σύνολο κριτηρίων εξετάζεται ώστε να αποφανθούμε αν για τα κατάλληλα πεδία δύναται να αυτοματοποιηθεί η εφαρμογή της αναδόμησης προς το πρότυπο Null Object. Σε διαφορετική περίπτωση, η προτεινόμενη μεθοδολογία θα κατατάσσει αυτό το πεδίο ως suggested refactorable, μιας και απαιτείται η επέμβαση του προγραμματιστή για την εφαρμογή της αναδόμησης προς το πρότυπο Null Object. Αναφορικά με την υλοποίηση της αυτόματης ανίχνευσης υποψήφιων περιπτώσεων αναδόμησης προς το πρότυπο Null Object, η προτεινόμενη μεθοδολογία βασίστηκε στην τεχνική της στατικής ανάλυσης (static analysis) του πηγαίου κώδικα, ώστε να παραχθεί ως κύρια μορφή αναπαράστασής του το Αφηρημένο Συντακτικό Δέντρο (Abstract Syntax Tree, AST). Το AST δέντρο αναλύεται ώστε να εντοπιστούν τα πεδία και οι υποθετικές δομές που ικανοποιούν τις προϋποθέσεις που ορίζονται από τη μεθοδολογία, ενώ για ένα συγκεκριμένο υποσύνολο των κριτηρίων ανίχνευσης, που οι απαιτούμενες πληροφορίες δεν ήταν δυνατό να εξαχθούν από αυτό, χρησιμοποιήθηκε τόσο ο Γράφος Ροής Ελέγχου (Control Flow Graph, CFG) όσο και ο Γράφος Εξαρτήσεων Προγράμματος (Program Dependence Graph, PDG). Οι προτάσεις αναδόμησης που προκύπτουν ως αποτέλεσμα της διαδικασίας ανίχνευσης και εμφανίζονται στον χρήστη, αντιστοιχούν στις υποθετικές δηλώσεις που η έκφρασή τους ελέγχει την τιμή κάποιου υποψήφιου για αναδόμηση πεδίου. Οι προτάσεις αυτές εμφανίζονται στο χρήστη ταξινομημένες ανάλογα με το αν μπορούν να διαγραφούν και ομαδοποιημένες ανά υποψήφιο πεδίο. Ακολούθως, ο χρήστης δύναται να επιθεωρήσει τις προτάσεις αναδόμησης μία προς μία και να επιλέξει εκείνες που επιθυμεί να εκτελέσει. Κατά την εφαρμογή της επιλεγμένης από το χρήστη πρότασης αναδόμησης, το αφηρημένο συντακτικό δέντρο του υπό εξέταση κώδικα ανασυντάσσεται και 7

8 παρέχεται στο χρήστη η δυνατότητα προεπισκόπησης της προτεινόμενης αναδόμησης προτού επιλέξει την εφαρμογή της, καθώς και η δυνατότητα απόρριψής της. Όταν ο χρήστης επιβεβαιώσει την εφαρμογή της προτεινόμενης αναδόμησης, οι μετασχηματισμοί του AST δέντρου χρησιμοποιούνται ώστε να τροποποιηθεί ο πηγαίος κώδικας του λογισμικού χωρίς την παρέμβαση του χρήστη. Κατά την εφαρμογή μιας αναδόμησης με χρήση του προτύπου Null Object, οι μετασχηματισμοί που εφαρμόζονται στο AST δέντρο αποσκοπούν στην υλοποίηση των δομικών στοιχείων του προτύπου στο αναδομούμενο σύστημα, καθώς και στην εξασφάλιση της διατήρησης της αρχικής συμπεριφοράς του υπό εξέταση συστήματος. Τα δομικά στοιχεία από τα οποία αποτελείται το πρότυπο Null Object, όταν ακολουθείται η προσέγγιση δημιουργίας αφηρημένης υπερκλάσης, είναι η κλάση πελάτης που δηλώνει το υποψήφιο πεδίο, το πεδίο για το οποίο διαγράφονται οι υποθετικοί έλεγχοι, η αφηρημένη κλάση και οι συγκεκριμένες υποκλάσεις της. Κατά συνέπεια, οι εκτελούμενοι μετασχηματισμοί της αναδόμησης, συνοψίζονται στην δημιουργία της αφηρημένης κλάσης και της συγκεκριμένης Null Object υποκλάσης της, οι μέθοδοι της οποίας θα έχουν την κατάλληλη συμπεριφορά ώστε να είναι δυνατή η διαγραφή όσο το δυνατόν περισσότερων υποθετικών δηλώσεων από το πρόγραμμα. Επιπλέον, το επιλεγμένο πεδίο θα πρέπει να δηλωθεί με τύπο την αφηρημένη υπερκλάση και να αρχικοποιηθεί με ένα στιγμιότυπο της Null Object υποκλάσης. Τέλος, η κλάση πελάτης πρέπει να τροποποιηθεί καταλλήλως, ώστε να διαγραφούν οι υποθετικές δηλώσεις που δύναται να διαγραφούν, αλλά και να διατηρηθεί ίδια η συμπεριφορά του λογισμικού. Η προτεινόμενη μεθοδολογία υλοποιήθηκε με χρήση της γλώσσας προγραμματισμού Java και των βιβλιοθηκών JDT και LTK του Eclipse και ενσωματώθηκε σαν τμήμα του υπάρχοντος εργαλείου αναδόμησης του Eclipse IDE, JDeodorant. Το εργαλείο JDeodorant, στο οποίο και στηρίχτηκε η υλοποίηση της προτεινόμενης μεθοδολογίας, είναι ένα plug-in του Eclipse που παρέχει τη δυνατότητα εκτέλεσης αναδομήσεων που επιλύουν τα σχεδιαστικά προβλήματα «God Class», «Long Method», «Type Checking» και «Feature Envy». Μετά την ολοκλήρωση της υλοποίησης του σχετικού υποστηρικτικού εργαλείου, η προτεινόμενη μεθοδολογία δοκιμάστηκε σε διάφορα συστήματα λογισμικού ανοιχτού κώδικα, προκειμένου να αξιολογηθεί η αποτελεσματικότητα της τόσο αναφορικά με 8

9 τη χρησιμότητα και την εφαρμοσιμότητά της στην πράξη όσο και ως προς την κλιμακωσιμότητά της. Ιδιαίτερη μέριμνα δόθηκε ώστε τα συστήματα λογισμικού που χρησιμοποιήθηκαν κατά την πειραματική αξιολόγηση να είναι αρκετά σε πλήθος και μεγάλα από άποψη μεγέθους και συνθετότητας. Η απόφαση αυτή πάρθηκε για λόγους πληρότητας, ώστε η χρησιμότητα αλλά και η κλιμακωσιμότητα της μεθοδολογίας να εξεταστεί σε διάφορα συστήματα λογισμικού που διαφέρουν ως προς τα χαρακτηριστικά μεγέθους και πολυπλοκότητας και αντιπροσωπεύουν συστήματα λογισμικού που χρησιμοποιούνται στην πράξη. Στα πλαίσια της αξιολόγησης της χρησιμότητας και της εφαρμοσιμότητας στην πράξη της προτεινόμενης μεθοδολογίας, για καθένα από τα υπό εξέταση συστήματα λογισμικού καταγράφηκαν τόσο οι περιπτώσεις πεδίων που ανιχνεύονται ως κατάλληλες για αυτοματοποιημένη εφαρμογή της αναδόμησης, όσο και τα suggested refactorable πεδία. Όσον αφορά την αξιολόγηση της κλιμακωσιμότητας της προτεινόμενης μεθοδολογίας, κατεγράφησαν για καθένα σύστημα λογισμικού οι χρόνοι εκτέλεσης της διαδικασίας ανίχνευσης των προτάσεων αναδόμησης. Τα αποτελέσματα των προαναφερθέντων πειραμάτων παρουσιάζονται και χρησιμοποιούνται προκειμένου να εξαχθούν ορισμένα χρήσιμα συμπεράσματα. Τέλος, η παρούσα διπλωματική εργασία καταγράφει τους περιορισμούς και τις ελλείψεις που παρουσιάζει η προτεινόμενη προσέγγιση αναδόμησης προς το πρότυπο Null Object. Οι περιορισμοί αυτοί μπορούν να γίνουν αντικείμενο μελλοντικής ερευνητικής μελέτης, ώστε να επεκταθεί και εμπλουτιστεί η προτεινόμενη μεθοδολογία. 9

10 Abstract The need to ensure the longevity and competitiveness of modern software systems has led to the adoption of the evolutionary software development methodology, according to which the software evolves throughout its life cycle, even past its release. However, the continuous modifications to which a software system is subject, can lead to a gradual deterioration of its design quality. The methodology of refactoring to patterns, which is one of the key principles of evolutionary design, aims towards improving the design quality of software. Refactoring is the process of applying small and formalized transformations to the internal structure of the software, in order to improve some of its quality characteristics, without changing its externally observable behavior. Design patterns, on the other hand, are widely accepted, ready or almost ready high-level design solutions to commonly occurring design problems. The technique of refactoring to patterns attempts to combine the benefits of refactoring with the advantages of design patterns, with the ultimate aim of improving the design quality of a software system. However, refactoring is a highly demanding process, both in terms of effort required, and of time that should be spent in order to be performed safely, without introducing errors and by guaranteeing the preservation of the software s initial behavior. The above requirements combined with the constant growth of the size of modern software systems make manual refactoring difficult to be done by software engineers. The value of automation the process of refactoring has been confirmed by the software industry and a plethora of automatic refactoring tools has been developed. However, the majority of automatic refactoring tools support only primitive refactorings, without enabling the automated execution of more complex refactorings, such as refactorings aimed at introducing a design pattern. This thesis intends to contribute a solution to the above problem, by examining the problem of automating the refactoring to Null Object design pattern. The Null Object pattern, based on the principles of inheritance and polymorphism, should be used in cases where repetitive checks if an object is not null before sending a message to it 10

11 exist throughout the code. The aim of the developed methodology is the automatic identification of cases where it is possible to apply the Null Object design pattern. Moreover, the proposed approach allows, for cases that meet the criteria for automatic implementation of the refactoring, the automatic reconstruction of the source code in order for the structure of the pattern to be implemented. More specifically, the proposed methodology is limited to the detection and removal of conditional logic that checks whether a field is equal or not to null before invocating some of its methods, in order to avoid causing a Null Pointer Exception, since developer is not sure whether the field has been assigned value other than null. In order to define the problem of identification of refactoring to Null Object opportunities, the proposed identification methodology, first, tries to identify in each class of the examined code those of its fields which are of type of some class that belongs to the system under consideration, in order to be possible to apply the refactoring process. These fields are then examined in order to determine whether they meet a set of selected criteria which denote that there is a high probability to exist in the class they are defined conditional expressions that check whether their value equals null or not. Each field that meets the criteria of the previous analysis is characterized as candidate for the application of refactoring to Null Object pattern. It is then examined whether there exist conditional expressions that check whether the field is equal or not to null and which meet a set of criteria which allow their removal, while ensuring that no errors are introduced and maintaining the software behavior. Only the fields for which conditional statements candidates for elimination will be detected, will be finally considered suitable for the application of refactoring to Null Object pattern, since only then will we benefit from the use of the pattern. Moreover, a third set of criteria is examined in order to determine whether for the candidate fields the application of the refactoring to the Null Object pattern can be automated. Otherwise, the proposed methodology will classify this field as suggested refactorable, since it requires the intervention of the programmer in order for the refactoring to Null Object pattern to be applied. 11

12 Regarding the automatic identification of refactoring to Null Object candidates, the proposed methodology is based on the technique of static analysis of the examined source code in order for its Abstract Syntax Tree (AST) to be produced. The AST tree is analyzed so as to detect the fields and conditional statements that satisfy the preconditions defined by the methodology, while for a specific subset of the identification criteria that the required information could not be drawn from it, the Control Flow Graph (CFG) and the Program Dependence Graph (PDG) were used. The refactoring suggestions that arise as a result of the identification process and are presented to the user, correspond to conditional statements that their branch condition checks the value of a candidate for refactoring field. These suggestions are presented to the user sorted according to whether they can be eliminated, and grouped per candidate field. Then, the user is able to preview the refactoring suggestions one by one and select the ones who wishes to apply. During the application of a user-selected refactoring suggestion, the abstract syntax tree of the examined code is being restructured and the user is given the option to preview the proposed refactoring prior to selecting its application, as well as the option to reject it. When the user confirms the application of the proposed refactoring, the transformations of the AST tree are used in order to modify the source code of the software without user s contribution. During the application of a refactoring to Null Object pattern, the transformations applied to the AST tree intend to apply the structural elements of the pattern in the reconstructed system, as well as to guarantee the preservation of the initial behavior of the system under consideration. The structural elements that make up the Null Object pattern, when following the approach of abstract superclass, is the client class that defines the candidate field, the field for which conditional statements are eliminated, the abstract class and its concrete subclasses. Consequently, the transformations performed during refactoring are summarized in the creation of the abstract class and its concrete Null Object subclass whose methods will have the suitable behavior in order to be able to eliminate as many conditional statements from the program. In addition, the selected field should be declared having as type the abstract superclass and instantiated with an object of the Null Object subclass. Finally, the client class should be appropriately modified, in order for the conditional statements to be 12

13 eliminated and also for the software behavior to be maintained the same. The proposed methodology has been implemented with the use of Java programming language and also of the JDT and LTK Eclipse libraries and has been integrated in the already existing refactoring tool for Eclipse IDE, JDeodorant, as part of it. The tool JDeodorant, on which the implementation of the proposed methodology was based, is an Eclipse plug-in that allows the automatic application of refactorings which solve the design problems «God Class», «Long Method», «Type Checking» and «Feature Envy». After having constructed the corresponding support tool, the proposed methodology was tested on several open source software systems in order to evaluate its effectiveness both in terms of its usefulness and applicability as well as of its scalability. Particular attention was given to use a large number of software systems in the experimental evaluation that were big in terms of size and complexity. This decision was taken for the sake of completeness, so that the usefulness and scalability of the methodology be examined in several software systems that differ in size and complexity and represent software systems used in practice. In the context of evaluating the usefulness and applicability of the proposed methodology, both cases of fields detected as suitable for automated application of refactoring, and cases of the suggested refactorable fields are recorded for each of the examined software systems. Regarding the evaluation of the scalability of the proposed methodology, the execution time required for the identification process was recorded for each of the examined software systems. The results of the above experiments are being presented and used to infer some useful conclusions. Finally, the present thesis records the limitations and the deficiencies of the proposed methodology of refactoring to Null Object pattern. These limitations can be the subject of future research study to extend and enrich the proposed methodology. 13

14 Πίνακας περιεχομένων Ευχαριστίες... 4 Περίληψη... 5 Abstract Πίνακας Πινάκων Πίνακας Εικόνων Κεφάλαιο 1 Εισαγωγή Σκοπός και Συμβολή της Διπλωματικής Εργασίας Δομή της Διπλωματικής Εργασίας Κεφάλαιο 2 - Αναδόμηση και Πρότυπα Σχεδίασης Αναδόμηση Κώδικα Πλεονεκτήματα και Μειονεκτήματα της Αναδόμησης Περιπτώσεις Εφαρμογής μιας Αναδόμησης Κακές Οσμές (Bad Smells) Είδη Αναδόμησης Τρόποι και Εργαλεία Αναδόμησης Πρότυπα Σχεδίασης Αναδόμηση με Πρότυπα Σχεδίασης Κεφάλαιο 3 - Αυτοματοποίηση Αναδόμησης προς το Πρότυπο Null Object Το Πρότυπο Σχεδίασης Null Object Χειρωνακτική Αναδόμηση προς το Πρότυπο Null Object Προσεγγίσεις Αυτόματης Αναδόμησης με Χρήση του Προτύπου Σχεδίασης Null Object Μέθοδοι Ανάλυσης Κώδικα στην Αυτοματοποιημένη Αναδόμηση Αφηρημένα Συντακτικά Δέντρα (AST) Γράφος Ροής Ελέγχου (CFG) Γράφος Εξαρτήσεων Προγράμματος (PDG) Τεχνική Slicing Κεφάλαιο 4 Προτεινόμενη Μεθοδολογία Τα Προβλήματα της Χρήσης Υποθετικής Λογικής και Διπλότυπου Κώδικα Στόχος της Προτεινόμενης Μεθοδολογίας Ανίχνευση Περιπτώσεων Αναδόμησης

15 4.3.1 Εντοπισμός των Υποψήφιων Πεδίων Εντοπισμός της Δυνατότητας Αυτόματης Εφαρμογής της Αναδόμησης Εντοπισμός Υποθετικών Δηλώσεων Υποψήφιων για Διαγραφή Ανάλυση των Προϋποθέσεων για τις Υποψήφιες για Διαγραφή Υποθετικές Δηλώσεις Ανάλυση των Διαφορετικών Ειδών Υποθετικών Δομών Εντοπισμός των Suggested Refactorable Πεδίων Εφαρμογή Αναδόμησης Λεπτομέρειες Υλοποίησης Παρουσίαση του Εργαλείου Αναδόμησης Παρουσίαση Εκτελούμενης Αναδόμησης Συμπεράσματα και Περιορισμοί Κεφάλαιο 5 - Πειραματική Αξιολόγηση Συστήματα Λογισμικού για την Αξιολόγηση Αποτελέσματα από την Πειραματική Εκτέλεση της Μεθοδολογίας Συμπεράσματα Βάσει των Αποτελεσμάτων Κεφάλαιο 6 - Συμπεράσματα και Μελλοντική Έρευνα Παράρτημα Παράρτημα Α Υλοποίηση Προτεινόμενης Μεθοδολογίας Παράρτημα Β Οδηγίες Εγκατάστασης του plug-in JDeodorant Συντομογραφίες Βιβλιογραφία

16 Πίνακας Πινάκων Πίνακας 1: Οι δώδεκα κακές οσμές του Kerievsky και οι αντίστοιχες αναδομήσεις που αποσκοπούν στην απομάκρυνσή τους Πίνακας 2: Ο κατάλογος των 72 αναδομήσεων του Fowler και η αντίστοιχη κατηγοριοποίησή τους Πίνακας 3: Δημοφιλή εργαλεία αυτοματοποιημένης αναδόμησης για τις γλώσσες προγραμματισμού Java, C++ και.net Πίνακας 4: Τα 23 πρότυπα σχεδίασης της συγγραφικής ομάδας GoF και η κατηγοριοποίησή τους Πίνακας 5: Οι 27 αναδομήσεις με πρότυπα σχεδίασης του Kerievsky και η κατηγοριοποίησή τους Πίνακας 6: Χαρακτηριστικά μεγέθους των υπό εξέταση συστημάτων λογισμικού Πίνακας 7: Αποτελέσματα αξιολόγησης της μεθοδολογίας στα υπό εξέταση συστήματα λογισμικού Πίνακας 8: Ποσοστό των κατάλληλων πεδίων για κάθε υπό εξέταση σύστημα λογισμικού Πίνακας 9: Χρόνοι υπολογισμού για τη διαδικασία ανίχνευσης προτάσεων αναδόμησης προς το πρότυπο Null Object Πίνακας 10: Οι κλάσεις που χρησιμοποιούνται για την υλοποίηση του γραφικού περιβάλλοντος του εργαλείου Πίνακας 11: Οι κλάσεις που χρησιμοποιούνται στη διαδικασία ανίχνευσης προτάσεων αναδόμησης Πίνακας 12: Οι κύριες κλάσεις που χρησιμοποιούνται στη διαδικασία εκτέλεσης μιας αναδόμησης

17 Πίνακας Εικόνων Εικόνα 1: Ο κατάλογος των αναδομήσεων που υποστηρίζει το Eclipse Εικόνα 2: Η δομή του προτύπου Null Object με χρήση της προσέγγισης δημιουργίας υποκλάσης Εικόνα 3: Η δομή του προτύπου Null Object με χρήση της προσέγγισης δημιουργίας αφηρημένης κλάσης Εικόνα 4: Η δομή του προτύπου Null Object με χρήση της προσέγγισης δημιουργίας διεπαφής Εικόνα 5: Το διάγραμμα κλάσεων του παραδείγματος πριν και μετά την εφαρμογή του προτύπου Null Object Εικόνα 6: Ο κώδικας του παραδείγματος πριν και μετά την εφαρμογή του προτύπου Null Object [31] Εικόνα 7: Παράδειγμα κλάσης Hello.java Εικόνα 8: Απόσπασμα του αφηρημένου συντακτικού δέντρου της κλάσης Hello.java της Εικόνας 7, όπως παράγεται από το ASTViewer plug-in του Eclipse Εικόνα 9: Τμήμα κώδικα χωρισμένο σε βασικές ενότητες [41] Εικόνα 10: Γράφος ροής ελέγχου (αριστερά) και γράφος ροής ελέγχου με βασικές ενότητες (δεξιά) για το τμήμα κώδικα της Εικόνας 9 [41] Εικόνα 11: Ο γράφος εξαρτήσεων κλάσεων για το τμήμα κώδικα της Εικόνας 9, στον οποίο περιέχεται τόσο ο υπογράφος με τις εξαρτήσεις ελέγχου όσο και ο υπογράφος με τις εξαρτήσεις δεδομένων [41] Εικόνα 12: Ο block-based γράφος εξαρτήσεων ελέγχου (block-based control dependence graph) της μεθόδου statement που παρουσιάστηκε στην Εικόνα 9 [41]. 68 Εικόνα 13: Οι βασικές ενότητες της μεθόδου της Εικόνας 9, οι γραμμοσκιασμένοι leader κόμβοι τους, καθώς και τα boundary blocks για την εντολή της γραμμής 10 [41] Εικόνα 14: Κώδικας του παραδείγματος Room Customer που θα χρησιμοποιηθεί στην ανάλυση της προτεινόμενης μεθοδολογίας Εικόνα 15: Διάγραμμα κλάσεων του παραδείγματος Room Customer Εικόνα 16: Περίπτωση κατασκευαστή που θέτει το πεδίο λόγω ύπαρξης εντολής ανάθεσης

18 Εικόνα 17: Περίπτωση κατασκευαστή που θέτει το πεδίο λόγω κλήσης setter μεθόδου πρώτης μορφής Εικόνα 18: Περίπτωση κατασκευαστή που θέτει το πεδίο λόγω κλήσης setter μεθόδου δεύτερης μορφής Εικόνα 19: Περίπτωση κατασκευαστή που θεωρείται ότι θέτει το πεδίο λόγω κλήσης μεθόδου της context κλάσης Room που δεν είναι setter μέθοδος κάποιου άλλου πεδίου της κλάσης Room Εικόνα 20: Διάγραμμα κλάσεων της μορφής του κώδικα πριν και μετά την εφαρμογή της αναδόμησης Εικόνα 21: Παραδείγματα υποθετικών δηλώσεων για το πεδίο customer και ο τρόπος που έχουν χαρακτηριστεί από τη μεθοδολογία Εικόνα 22: Η αλλαγή στη δομή του κώδικα μετά την εφαρμογή της αναδόμησης για το πεδίο customer Εικόνα 23: Η δημιουργηθείσα κλάση AbstractCustomer Εικόνα 24: Η δημιουργηθείσα κλάση NullCustomer Εικόνα 25: Η μορφή της κλάσης Customer πριν και μετά την εφαρμογή της αναδόμησης Εικόνα 26: Η κλάση Room πριν και μετά την εφαρμογή της αναδόμησης Εικόνα 27: Το μενού Bad Smells και η όψη Null Checks με τις επιλογές ανίχνευσης, αποθήκευσης και εφαρμογής των προτάσεων αναδόμησης προς το πρότυπο Null Object Εικόνα 28: Παρουσίαση των προτάσεων αναδόμησης προς το πρότυπο Null Object και προεπισκόπηση της επιλεγμένης υποθετικής δήλωσης που ανιχνεύτηκε Εικόνα 29: Ο οδηγός για την προεπισκόπηση και τροποποίηση από το χρήστη των προεπιλεγμένων ονομάτων των κλάσεων και των μεθόδων που θα δημιουργηθούν 109 Εικόνα 30: Ο οδηγός για την προεπισκόπηση και αποδοχή ή απόρριψη του προτεινόμενου μετασχηματισμού Εικόνα 31: Το κατάλληλο για εφαρμογή του προτύπου Null Object πεδίο perm της κλάσης JUnitTestRunner με δυο υποθετικές δηλώσεις υποψήφιες για διαγραφή Εικόνα 32: Η δήλωση του πεδίου perm πριν την εφαρμογή της αναδόμησης Εικόνα 33: Κατασκευαστής της κλάσης JUnitTestRunner ο οποίος δε θέτει το πεδίο perm

19 Εικόνα 34: Η δημιουργηθείσα κλάση AbstractPerm Εικόνα 35: Η δημιουργηθείσα κλάση NullPerm Εικόνα 36: Η κλάση Permissions που αντιστοιχεί στον τύπο του πεδίου δηλώνεται ως υποκλάση της κλάσης AbstractPerm Εικόνα 37: Η προσθήκη των μεθόδων isnull() και getreference() στην κλάση Permissions Εικόνα 38: Η τροποποίηση της δήλωσης του πεδίου perm στην context κλάση JUnitTestRunner Εικόνα 39: Η προσθήκη της μεθόδου assigntoperm στην context κλάση JUnitTestRunner Εικόνα 40: Περίπτωση εντολής ανάθεσης που τροποποιήθηκε, καθώς και υποθετικής λογικής που διαγράφηκε Εικόνα 41: Ραβδόγραμμα όπου συνοψίζονται τα αποτελέσματα της εφαρμογής της μεθοδολογίας σε καθένα εξεταζόμενο σύστημα λογισμικού Εικόνα 42: Συσχέτιση του χρόνου δημιουργίας του AST με τον αριθμό γραμμών κώδικα του συστήματος (TLOC) Εικόνα 43: Ραβδόγραμμα όπου συγκρίνονται οι χρόνοι υπολογισμού της διαδικασίας ανίχνευσης προτάσεων αναδόμησης προς το πρότυπο Null Object Εικόνα 44: Γραφική παράσταση της συσχέτισης μεταξύ του χρόνου ελέγχου των προϋποθέσεων για την ανίχνευση προτάσεων αναδόμησης και του συνολικού αριθμού γραμμών κώδικα (TLOC) στο σύνολο των εξεταζόμενων συστημάτων λογισμικού 136 Εικόνα 45: Γραφική παράσταση της συσχέτισης μεταξύ του χρόνου ελέγχου των προϋποθέσεων για την ανίχνευση προτάσεων αναδόμησης και του αριθμού των εν δυνάμει υποψήφιων πεδίων στο σύνολο των εξεταζόμενων συστημάτων λογισμικού Εικόνα 46: Διάγραμμα πακέτων στα οποία περιλαμβάνονται οι κλάσεις οι οποίες χρησιμοποιήθηκαν για την υλοποίηση της προτεινόμενης μεθοδολογίας Εικόνα 47: Διάγραμμα των κλάσεων που χρησιμοποιούνται για την υλοποίηση του γραφικού περιβάλλοντος του εργαλείου αναδόμησης προς το πρότυπο Null Object 145 Εικόνα 48: Οι βασικότερες κλάσεις που χρησιμοποιούνται στη διαδικασία ανίχνευσης προτάσεων αναδόμησης προς το πρότυπο Null Object Εικόνα 49: Οι βασικότερες κλάσεις που συμμετέχουν στην εκτέλεση μιας 19

20 αναδόμησης προς το πρότυπο Null Object

21 Κεφάλαιο 1 Εισαγωγή 1.1 Σκοπός και Συμβολή της Διπλωματικής Εργασίας Οι αλλαγές αποτελούν αναπόσπαστο μέρος της ανάπτυξης ενός συστήματος λογισμικού. Αυτό οφείλεται στη δυναμική φύση των συστημάτων λογισμικού, τα οποία συνεχώς ενημερώνονται, είτε προκειμένου να ακολουθήσουν τις τεχνολογικές εξελίξεις, είτε εξαιτίας επιβεβλημένων τροποποιήσεων των απαιτήσεων σχεδίασης, είτε προκειμένου να επεκταθεί η λειτουργικότητά τους και να παραμείνουν βιώσιμα. Ωστόσο, οι διαρκείς τροποποιήσεις ενός συστήματος λογισμικού μπορεί να έχουν αρνητικό αντίκτυπο στην ποιότητα της σχεδίασής του. Η χαμηλή ποιότητα σχεδίασης με τη σειρά της επηρεάζει αρνητικά την κατανοησιμότητα (understandability) του λογισμικού και δυσχεραίνει την επέκταση και τη συντήρησή του (maintenance). Προς την κατεύθυνση της βελτίωσης της ποιότητας σχεδίασης ενός συστήματος λογισμικού στοχεύει η εφαρμογή αναδομήσεων του κώδικα (refactorings). Η διαδικασία της αναδόμησης είναι μια διαδικασία τροποποίησης της δομής του κώδικα με τέτοιο τρόπο ώστε να βελτιωθούν κάποια ποιοτικά χαρακτηριστικά του, χωρίς, όμως, να τροποποιηθεί η εξωτερικά παρατηρούμενη συμπεριφορά του. Μια ακόμα πολύ διαδεδομένη μέθοδος για τη βελτίωση της ποιότητας σχεδίασης ενός συστήματος λογισμικού είναι η χρήση των προτύπων σχεδίασης (design patterns). Τα πρότυπα σχεδίασης είναι μια συστηματική προσπάθεια καταγραφής λύσεων σε κοινά προβλήματα σχεδίασης. Τα πρότυπα σχεδίασης αναπτύχθηκαν βασιζόμενα σε βασικές αρχές της αντικειμενοστραφούς σχεδίασης, όπως ο διαχωρισμός των διεπαφών από την υλοποίηση, η προτίμηση της μεταβίβασης έναντι της κληρονομικότητας και η ενθυλάκωση της μεταβλητότητας. Ως εκ τούτου, η δομή του παραγόμενου τρόπου σχεδίασης του συστήματος λογισμικού επιτρέπει την ευκολότερη τροποποίηση και εν γένει συντήρηση του συστήματος λογισμικού. Στην παρούσα διπλωματική εργασία μελετάται ο συνδυασμός της αναδόμησης με τα πρότυπα σχεδίασης, ώστε να συνδυαστούν τα οφέλη των δύο τεχνικών, με απώτερο σκοπό τη μείωση της πολυπλοκότητας ενός συστήματος λογισμικού, με ταυτόχρονη αύξηση της κατανοησιμότητας, της επαναχρησιμοποιησιμότητας (reusability) και της συντηρησιμότητάς του (maintainability). Πιο συγκεκριμένα, η παρούσα εργασία 21

22 ασχολείται με το πρόβλημα της αυτοματοποιημένης αναδόμησης προς το σχεδιαστικό πρότυπο Null Αντικείμενο (Null Object). Στον ερευνητικό τομέα της αυτοματοποιημένης αναδόμησης προς κάποιο σχεδιαστικό πρότυπο παρατηρείται σχετική έλλειψη. Ενώ η βιομηχανία λογισμικού έχει επιβεβαιώσει τη σημασία και την αξία της αυτοματοποιημένης αναδόμησης και έχουν αναπτυχθεί αρκετά εργαλεία αυτόματης αναδόμησης, αυτά περιορίζονται κυρίως στην υποστήριξη αναδομήσεων χαμηλού επιπέδου, χωρίς να παρέχουν τη δυνατότητα αυτοματοποιημένης εκτέλεσης πιο σύνθετων αναδομήσεων, όπως οι αναδομήσεις που αποσκοπούν στην εισαγωγή κάποιου σχεδιαστικού προτύπου. Αυτή η έλλειψη οφείλεται κυρίως στην εννοιολογική φύση των προτύπων σχεδίασης, η οποία και καθιστά δύσκολο τον αυτοματοποιημένο εντοπισμό των περιπτώσεων εφαρμογής τους. Αντίστοιχη έλλειψη υπάρχει και στον τομέα της αυτοματοποιημένης αναδόμησης προς το πρότυπο Null Object, την οποία και επιχειρεί να καλύψει η παρούσα διπλωματική εργασία. Η προσέγγιση που αναπτύχθηκε αποσκοπεί τόσο στην αυτοματοποιημένη ανίχνευση των προβληματικών σημείων του κώδικα που ενδείκνυται η εφαρμογή του προτύπου Null Object, όσο και στην αυτόματη εκτέλεση της αναδόμησης. Ιδιαίτερη μέριμνα δόθηκε ώστε η προτεινόμενη μεθοδολογία να είναι αρκετά γενική, ώστε να εντοπίζονται όσο το δυνατόν περισσότερες υποψήφιες περιπτώσεις για την εφαρμογή του προτύπου, αλλά και να εξασφαλίζεται η μη εισαγωγή σφαλμάτων και η διατήρηση της συμπεριφοράς του συστήματος κατά την εφαρμογή της αναδόμησης. 1.2 Δομή της Διπλωματικής Εργασίας Ακολούθως παρουσιάζεται συνοπτικά το περιεχόμενο που πραγματεύεται κάθε κεφάλαιο της παρούσας διπλωματικής εργασίας. Στο Κεφάλαιο 2 αναλύονται οι έννοιες της τεχνολογίας λογισμικού αναφορικά με την αναδόμηση (refactoring), τα πρότυπα σχεδίασης (design patterns) και την αναδόμηση με πρότυπα σχεδίασης (refactoring to patterns). Η ανάλυση αυτή κρίνεται αναγκαία προκειμένου να είναι δυνατή η πλήρης κατανόηση της σημασίας των όρων που χρησιμοποιούνται σε όλη την έκταση της παρούσας διπλωματικής εργασίας. Εν συνεχεία, στο Κεφάλαιο 3, καταρχάς, αναλύεται η δομή και η χρήση του σχεδιαστικού προτύπου Null Object και στη συνέχεια πραγματοποιείται μια 22

23 επισκόπηση της βιβλιογραφίας τόσο αναφορικά με τη χειρωνακτική αναδόμηση όσο και με την αυτοματοποιημένη αναδόμηση με χρήση του προτύπου Null Object. Ακολούθως, στο Κεφάλαιο 4 παρουσιάζεται αναλυτικά η μεθοδολογία που αναπτύχθηκε στα πλαίσια της παρούσας διπλωματικής εργασίας και παρέχονται εκτενείς πληροφορίες αναφορικά με την υλοποίηση της. Επιπλέον, για λόγους πληρότητας της παρουσίασης της προτεινόμενης προσέγγισης, παρουσιάζεται, μέσω ενός αντιπροσωπευτικού παραδείγματος από πραγματικό σύστημα λογισμικού, η εφαρμογή της αναδόμησης προς το πρότυπο Null Object, όπως δύναται να πραγματοποιηθεί αυτοματοποιημένα μέσω του εργαλείου που αναπτύχθηκε. Τέλος, αναλύονται οι περιορισμοί στους οποίους υπόκειται η προτεινόμενη προσέγγιση αναδόμησης. Προκειμένου να αξιολογηθεί η αποτελεσματικότητα της προτεινόμενης μεθοδολογίας τόσο αναφορικά με τη χρησιμότητα και την εφαρμοσιμότητά της στην πράξη όσο και ως προς την κλιμακωσιμότητά της, κρίθηκε αναγκαία η πειραματική εφαρμογή της σε πραγματικά συστήματα λογισμικού, τα αποτελέσματα της οποίας παρουσιάζονται στο Κεφάλαιο 5. Τέλος, στο Κεφάλαιο 6 συνοψίζεται η συνεισφορά της προτεινόμενης αυτοματοποιημένης μεθόδου αναδόμησης προς το πρότυπο Null Object, ενώ επαναλαμβάνονται οι περιορισμοί της προτεινόμενης προσέγγισης οι οποίοι δύναται να αποτελέσουν ενδιαφέροντα ερευνητικά ζητήματα για περαιτέρω διερεύνηση. 23

24 Κεφάλαιο 2 - Αναδόμηση και Πρότυπα Σχεδίασης 2.1 Αναδόμηση Κώδικα Τα συστήματα λογισμικού ανεξαρτήτως του σχεδιασμού τους και της γλώσσας ανάπτυξής τους είναι σίγουρο ότι κάποια στιγμή θα πρέπει να επεκταθούν ή, αν μη τι άλλο, να τροποποιηθούν, διαφορετικά κινδυνεύουν να οδηγηθούν σε αχρηστία. Οι αλλαγές σε ένα σύστημα λογισμικού είναι συνήθως αρκετά συχνές και πηγάζουν κυρίως από τροποποιήσεις των απαιτήσεων σχεδίασης, από την ανάγκη τροποποίησης της υπάρχουσας λειτουργικότητας, από την απαίτηση προσθήκης νέων δυνατοτήτων ή από την ανάγκη προσαρμογής στις τεχνολογικές εξελίξεις. Οι αλλαγές σε ένα σύστημα λογισμικού πολλές φορές γίνονται βεβιασμένα και υπό την πίεση προθεσμιών, χωρίς να προηγηθεί η κατάλληλη προσαρμογή του τρόπου σχεδίασης (design) του λογισμικού, ώστε αυτές να ενσωματωθούν με τον πιο πρόσφορο τρόπο. Ως εκ τούτου, η ποιότητα του τρόπου σχεδίασης του λογισμικού πλήττεται σε πολύ μεγάλο βαθμό, κάτι που έχει σοβαρό αντίκτυπο στην κατανοησιμότητα (understandability), στην συντηρησιμότητα (maintainability) και στην επεκτασιμότητα (extendability) του λογισμικού. Δεν είναι τυχαίο άλλωστε που η διαδικασία της συντήρησης και της τροποποίησης ενός συστήματος λογισμικού απαιτεί σχεδόν πάντα πολύ περισσότερο χρόνο από τη διαδικασία ανάπτυξής του. Προς την κατεύθυνση της βελτίωσης της ποιότητας του τρόπου σχεδίασης ενός συστήματος λογισμικού στοχεύει η διαδικασία της αναδόμησης (refactoring). Ο όρος αναδόμηση εμφανίστηκε για πρώτη φορά στη διδακτορική διατριβή του Griswolt [1] το 1991, η οποία και ασχολήθηκε με την αναδόμηση σε προγράμματα που ακολουθούν τις αρχές της συναρτησιακής και διαδικαστικής σχεδίασης (functional and procedural design). Στη συνέχεια, ακολούθησε ο Opdyke [2] το 1992, ο οποίος στη διδακτορική του διατριβή ανέλυσε την αναδόμηση σε αντικειμενοστραφή συστήματα λογισμικού (object-oriented programs) και την όρισε ως τη διαδικασία αναδιάρθρωσης της εσωτερικής δομής του κώδικα, η οποία όμως διατηρεί ίδια τη συμπεριφορά του. Ο Kerievsky αναφέρει ότι ο όρος αναδόμηση αφορά σε ένα μετασχηματισμό του λογισμικού που διατηρεί όμως τη συμπεριφορά του (behavior-preserving transformation) [3], ενώ ο Folwer ορίζει ότι η αναδόμηση 24

25 είναι η διαδικασία τροποποίησης ενός συστήματος λογισμικού ώστε να μην αλλάζει η εξωτερικά παρατηρήσιμη συμπεριφορά του κώδικα, όμως παρ όλα αυτά να βελτιώνεται η εσωτερική δομή του [4]. Πιο συγκεκριμένα, ο Folwer αναφέρει ότι η έννοια αναδόμηση έχει δύο ορισμούς, έναν που αφορά στη χρήση του όρου ως ουσιαστικό και έναν σαν ρήμα. Αναδόμηση (ουσιαστικό): μια αλλαγή που πραγματοποιείται στην εσωτερική δομή ενός λογισμικού ούτως ώστε να βελτιωθεί η κατανοησιμότητα του και να γίνει οικονομικότερη η τροποποίησή του, χωρίς όμως να αλλάζει η παρατηρήσιμη συμπεριφορά του. Αναδομώ (ρήμα): αναδιαρθρώνω το λογισμικό μέσω της εφαρμογής μιας σειράς αναδομήσεων χωρίς να τροποποιείται η παρατηρήσιμη συμπεριφορά του. Επιπλέον, και ο Beck [5] δίνει έναν ορισμό του όρου, αναφέροντας ότι η αναδόμηση είναι η διαδικασία προσθήκης αξίας σε ένα σύστημα λογισμικού, χωρίς να τροποποιείται η συμπεριφορά του, αλλά μέσω της ενσωμάτωσης κάποιων ποιοτικών χαρακτηριστικών, όπως η κατανοησιμότητα, η απλότητα και η ευελιξία, τα οποία και επιτρέπουν την ταχύτερη ανάπτυξη του λογισμικού. Η διαδικασία της αναδόμησης θα λέγαμε ότι έχει το ρόλο του συμπληρώματος της διαδικασίας του προκαταρκτικού σχεδιασμού (upfront design). Μια άποψη είναι ότι η αναδόμηση μπορεί να είναι η εναλλακτική του προκαταρκτικού σχεδιασμού. Πιο συγκεκριμένα, σε μια τέτοια θεώρηση σχεδιάζεις το λογισμικό χωρίς να κάνεις εκτιμήσεις για τις μελλοντικές επεκτάσεις ή τροποποιήσεις, αλλά μόνο με βάση τις απαιτήσεις που είναι γνωστές εκείνη τη χρονική στιγμή. Στη συνέχεια, το λογισμικό αναδομείται ώστε να βελτιωθεί ο τρόπος σχεδίασής του. Παρόλο που αυτή η προσέγγιση δεν είναι και η πιο αποτελεσματική, πολύ συχνά ωστόσο οδηγεί στη δημιουργία αξιόλογου λογισμικού από πλευράς σχεδίασης. Η πιο συνήθης χρήση της αναδόμησης, βέβαια, είναι ο συνδυασμός της με κάποιας μορφής αρχικό σχεδιασμό. Σε μια τέτοια περίπτωση, δεν καταβάλλεις μεγάλο χρόνο και προσπάθεια στον αρχικό σχεδιασμό ώστε να βρεις την καλύτερη σχεδιαστική λύση. Αντιθέτως, σου αρκεί η εύρεση μιας λογικής λύσης, μιας και ξέρεις ότι στην πορεία, όταν κατανοήσεις καλύτερα το πρόβλημα και οι απαιτήσεις παγιωθούν, μπορείς μέσω της αναδόμησης, εύκολα και με μικρός κόστος, να τη βελτιώσεις. Με 25

26 τη χρήση της αναδόμηση, λοιπόν, μετατοπίζεται η έμφαση από τη δημιουργία ενός ευέλικτου τρόπου σχεδίασης που θα έχει λάβει υπόψη όλες τις πιθανές μελλοντικές αλλαγές, στη δημιουργία ενός απλού αρχικού τρόπου σχεδίασης του λογισμικού, ο οποίος, όμως, θα είναι εύκολο στην πορεία να αναδομηθεί στην πιο ευέλικτη σχεδιαστική λύση που θα απαιτηθεί από τις μελλοντικές ανάγκες. Με άλλα λόγια η αναδόμηση μπορεί να οδηγήσει στην υιοθέτηση απλούστερων αρχικών σχεδιαστικών λύσεων χωρίς όμως να θυσιαστεί η ευελιξία του τρόπου σχεδίασης του λογισμικού. Αυτή η προσέγγιση κάνει τη σχεδιαστική διαδικασία πιο εύκολη και λιγότερο αγχωτική. Οι δυνατότητες που μας προσφέρει η αναδόμηση μας εισάγουν και την έννοια της εξελικτικής σχεδίασης (evolutionary design). Η βασική ιδέα της εξελικτικής σχεδίασης είναι ότι, δεδομένου ότι η ανάπτυξη του λογισμικού κινείται σε ένα περιβάλλον μεταβαλλόμενων απαιτήσεων, κάθε προσπάθεια βελτιστοποίησης της προκαταρκτικής σχεδίασης, η οποία προηγείται της κωδικοποίησης, κινδυνεύει να μην έχει το προσδοκώμενο αποτέλεσμα. Σύμφωνα, λοιπόν, με την εξελικτική σχεδίαση, η σχεδίαση του λογισμικού δεν περιορίζεται στο στάδιο της προκαταρκτικής σχεδίασης, αλλά γίνεται διαρκώς και κατά τη φάση της υλοποίησης του λογισμικού, μέσω κατάλληλων αναδομήσεων του κώδικα. Εν κατακλείδι, ο σκοπός της αναδόμησης είναι να καταστήσει το λογισμικό πιο κατανοητό και πιο εύκολα τροποποιήσιμο και επεκτάσιμο. Πρέπει να επισημάνουμε ότι ο σκοπός της αναδόμησης είναι εκ διαμέτρου αντίθετος με αυτόν μιας διαδικασίας βελτιστοποίησης της απόδοσης του λογισμικού (performance optimization). Μπορεί και οι δύο διαδικασίες να μην επεμβαίνουν στην εξωτερική συμπεριφορά του λογισμικού, όμως, εν αντιθέσει με την αναδόμηση, μια διαδικασία βελτιστοποίησης της απόδοσης πολλές φορές έχει ως αποτέλεσμα την παραγωγή ενός πιο πολύπλοκου και δυσνόητου κώδικα Πλεονεκτήματα και Μειονεκτήματα της Αναδόμησης Ο σκοπός και το πιο σημαντικό θα λέγαμε πλεονέκτημα της αναδόμησης είναι η βελτίωση της κατανοησιμότητας του λογισμικού. Μπορείς να πραγματοποιήσεις πολλές αλλαγές σε ένα σύστημα λογισμικού, μόνο, όμως, αυτές που κάνουν το λογισμικό πιο κατανοητό θεωρούνται αναδομήσεις. Λίγος χρόνος αφιερωμένος σε 26

27 αναδόμηση του κώδικα, μπορεί να κάνει τον κώδικα πιο ευανάγνωστο και να καταστήσει πιο εμφανή σε τρίτους τον σκοπό που αυτός επιτελεί. Η αναδόμηση, επίσης, βοηθά στη βελτίωση του τρόπου σχεδίασης του λογισμικού. Όπως προαναφέρθηκε, οι συνεχείς αλλαγές του κώδικα του λογισμικού, οι οποίες γίνονται βεβιασμένα και χωρίς οι προγραμματιστές να κατανοούν πλήρως τον τρόπο σχεδίασης του λογισμικού, έχουν αρνητική επίδραση στη δομή και στην ποιότητα της σχεδίασης του λογισμικού. Μέσω της αναδόμησης, λοιπόν, βελτιώνεται ο τρόπος σχεδίασης του λογισμικού και ως εκ τούτου διευκολύνεται η επέκταση, η τροποποίηση και εν γένει η συντήρηση του λογισμικού. Επιπρόσθετα, δεδομένου ότι μέσω της αναδόμησης ο προγραμματιστής αποκτά βαθειά γνώση της λειτουργικότητας και της δομής του κώδικα του λογισμικού, αυτό τον βοηθά στον ευκολότερο εντοπισμό σφαλμάτων (bugs) στον κώδικα. Επίσης, δεδομένης της βελτίωσης της ποιότητας του τρόπου σχεδίασης του λογισμικού που συνεπάγεται η αναδόμηση, συμπεραίνουμε ότι η αναδόμηση, επιπλέον, βοηθά στην επιτάχυνση της διαδικασίας ανάπτυξης του λογισμικού, καθώς και στην αύξηση της παραγωγικότητας των προγραμματιστών. Όντως, ένας καλός και ποιοτικός τρόπος σχεδίασης του λογισμικού είναι καθοριστικής σημασίας για τη γρήγορη ανάπτυξη του κώδικα, αλλά και την εύκολη και γρήγορη επέκταση, τροποποίηση και προσθήκη νέας λειτουργικότητας στο λογισμικό. Η αναδόμηση παρ όλα τα προαναφερθέντα οφέλη, δεν παύει να είναι μια διαδικασία χρονοβόρα και επίπονη. Η εφαρμογή μιας αναδόμησης απαιτεί να καταβληθεί αρκετή προσπάθεια και χρόνος από πλευράς του προγραμματιστή. Επίσης, τα οφέλη μιας αναδόμησης δεν είναι συνήθως άμεσα αντιληπτά και ως εκ τούτου οι υπεύθυνοι του έργου κρατούν συνήθως μια αρνητική στάση απέναντι στην υιοθέτησή της ως καλή πρακτική. Για τους παραπάνω λόγους και κυρίως επειδή η αναδόμηση είναι μια επίπονη διαδικασία, θα πρέπει αυτή να εκτελείται συνεχώς έτσι ώστε το λογισμικό να διατηρεί ανά πάσα στιγμή ένα καλό επίπεδο ποιότητας. Επιπρόσθετα, ένα ακόμα μειονέκτημα της αναδόμησης είναι ότι ενέχει τον κίνδυνο εισαγωγής σφαλμάτων, καθώς και τον κίνδυνο τροποποίησης της παρατηρούμενης συμπεριφοράς του συστήματος, αν δε γίνει προσεχτικά και μέσα από συγκεκριμένα, προβλέψιμα και μικρά βήματα (small steps). Ως εκ τούτου η αναδόμηση πρέπει να είναι καλά δομημένη και να περιλαμβάνει την εφαρμογή μικρών και ασφαλών βημάτων. Επίσης, 27

28 πολύ σημαντικό είναι να διενεργούνται οι απαραίτητες δοκιμασίες ελέγχου (tests) μετά την εφαρμογή κάθε αλλαγής, ώστε να επιβεβαιώνεται η διατήρηση της συμπεριφοράς του συστήματος λογισμικού. Η εκτέλεση αυτόματων ελέγχων, πριν, κατά τη διάρκεια και μετά από κάποια αναδόμηση είναι το δίχτυ ασφαλείας που θα επικυρώσει μια σωστή αναδόμηση Περιπτώσεις Εφαρμογής μιας Αναδόμησης Η διαδικασία της αναδόμησης πρέπει να αποτελεί αναπόσπαστο τμήμα της διαδικασίας ανάπτυξης του λογισμικού. Όπως αναφέρει και ο Fowler [4], η αναδόμηση δεν είναι δυνατόν να προγραμματιστεί και ο προγραμματιστής να είναι υποχρεωμένος να αφιερώνει ένα συγκεκριμένο μέρος του χρόνου ανάπτυξης ανά τακτά χρονικά διαστήματα σε αυτήν. Αντιθέτως, η αναδόμηση πρέπει να ενσωματωθεί ως αναπόσπαστη πρακτική στη διαδικασία ανάπτυξης του λογισμικού και να εκτελείται διαρκώς. Δεν εφαρμόζεις αναδόμηση επειδή πρέπει, αλλά επειδή θα διευκολύνει τη διαδικασία ανάπτυξης. Η αναδόμηση ενδείκνυται, καταρχάς, σε περιπτώσεις που πρέπει να προστεθεί νέα λειτουργικότητα και νέα χαρακτηριστικά στο λογισμικό. Ένας από τους λόγους που η αναδόμηση συνιστάται σε μια τέτοια περίπτωση είναι διότι βοηθάει στην καλύτερη κατανόηση του κώδικα που τροποποιείται. Επίσης, σε περίπτωση που η δομή του σχεδίου του λογισμικού είναι τέτοια που δεν επιτρέπει την προσθήκη της νέας λειτουργικότητας, μέσω της αναδόμησης μπορεί να τροποποιηθεί ο τρόπος σχεδίασης του λογισμικού ώστε να διευκολυνθεί η επέκταση και η συντήρηση του λογισμικού, τώρα αλλά και στο μέλλον. Επιπρόσθετα, η αναδόμηση ενδείκνυται όταν έχει αναφερθεί ένα σφάλμα που πρέπει να διορθωθεί. Η αναφορά ενός σφάλματος καταδεικνύει ότι ο κώδικας του λογισμικού ήταν αρκετά πολύπλοκος και δυσνόητος και για αυτόν το λόγο το σφάλμα δεν είχε εντοπιστεί πριν το λογισμικό δοθεί σε χρήση. Κατά τη διόρθωση ενός σφάλματος, λοιπόν, η αναδόμηση μπορεί να συμβάλει καθοριστικά στον εντοπισμό του, αλλά και στην πρόληψη μελλοντικών σφαλμάτων. Τέλος, κατά τη διάρκεια των επιθεωρήσεων του κώδικα του λογισμικού (code reviews), η εφαρμογή της αναδόμησης μπορεί να βοηθήσει τους προγραμματιστές επιθεωρητές να κατανοήσουν καλύτερα το υπό εξέταση λογισμικό και να διοχετευτεί η γνώση και στα υπόλοιπα μέλη της ομάδας ανάπτυξης του λογισμικού. 28

29 Αντιθέτως, υπάρχουν και περιπτώσεις που δεν πρέπει να εφαρμόζεται η αναδόμηση. Μία από αυτές είναι, όπως αναφέρει ο Folwer [4], όταν υπάρχουν έντονα σημάδια ότι ο κώδικας πρέπει να γραφτεί από την αρχή (rewrite from scratch). Υπάρχουν περιπτώσεις που ο κώδικας είναι τόσο κακογραμμένος, πολύπλοκος και δυσνόητος ή περιπτώσεις που ο κώδικας δε δουλεύει σωστά, στις οποίες, ενώ μπορεί να εφαρμοστεί αναδόμηση, μοιάζει ευκολότερο ο κώδικας να γραφτεί εκ του μηδενός. Σε αυτές τις περιπτώσεις η αναδόμηση δε μοιάζει ως η καλύτερη λύση. Επίσης, η αναδόμηση θα πρέπει να αποφεύγεται σε περιπτώσεις που πλησιάζει μια αυστηρή προθεσμία παράδοσης του λογισμικού. Παρόλο που η αναδόμηση βελτιώνει την παραγωγικότητα, σε μια τέτοια περίπτωση το κέρδος αυτό θα καταφανεί πολύ αργά, μετά το πέρας της προθεσμίας. Συνεπώς, παρόλο που η αναδόμηση πρέπει να είναι διαρκής και να εφαρμόζεται σε κάθε ευκαιρία, θα πρέπει να συνυπάρχει αρμονικά με τις προτεραιότητες της διοίκησης και να γίνεται την κατάλληλη χρονική στιγμή. Η αναδόμηση, όπως και άλλες μέθοδοι της τεχνολογίας λογισμικού, έχει τα όριά της. Ορισμένες φορές η προσεχτική προκαταρκτική σχεδίαση μπορεί να είναι η πιο δόκιμη προσέγγιση στην κατασκευή του λογισμικού. Για παράδειγμα, η αναδόμηση έχει προβλήματα κλιμάκωσης σε μεγάλα συστήματα λογισμικού. Επιπλέον, υπάρχει δυσκολία να εφαρμοστεί η αναδόμηση σε συστήματα στα οποία δεν έχει δοθεί η απαραίτητη προσοχή στη σχεδίαση της αρχιτεκτονικής τους [6]. Σε μια τέτοια περίπτωση η παράλειψη του καθορισμού της κατάλληλης αρχιτεκτονικής, η οποία θα παρέχει τα ποιοτικά χαρακτηριστικά του λογισμικού, ενδέχεται να μην μπορεί εύκολα να καλυφθεί με αναδόμηση. Τέλος, ένα ακόμα σημείο που δεν επιτρέπεται η αναδόμηση είναι αν αφορά αλλαγές σε διεπαφές για τις οποίες υπάρχει δέσμευση για τη μη τροποποίησή τους. Σε μια τέτοια περίπτωση μια πιθανή λύση είναι να διατηρούνται τόσο η παλιά όσο και η νέα διεπαφή, μέχρι οι χρήστες της να ενημερωθούν και να αντιδράσουν σε αυτήν την αλλαγή Κακές Οσμές (Bad Smells) Η γνώση της έννοιας της αναδόμησης, καθώς και του τρόπου που μπορεί να πραγματοποιηθεί μια αναδόμηση, δεν είναι αρκετή προκειμένου να επωφεληθούμε από τα πλεονεκτήματά της. Ιδιαίτερη σημαντικότητα και αξία έχει ο εντοπισμός του 29