ΑΡΙΣΤΟΤΕΛΕΙΟ ΠΑΝΕΠΙΣΤΗΜΙΟ ΘΕΣΣΑΛΟΝΙΚΗΣ ΠΟΛΥΤΕΧΝΙΚΗ ΣΧΟΛΗ

Transcript

1 ΑΡΙΣΤΟΤΕΛΕΙΟ ΠΑΝΕΠΙΣΤΗΜΙΟ ΘΕΣΣΑΛΟΝΙΚΗΣ ΠΟΛΥΤΕΧΝΙΚΗ ΣΧΟΛΗ ΤΜΗΜΑ ΗΛΕΚΤΡΟΛΟΓΩΝ ΜΗΧΑΝΙΚΩΝ ΚΑΙ ΜΗΧΑΝΙΚΩΝ ΥΠΟΛΟΓΙΣΤΩΝ ΤΟΜΕΑΣ ΗΛΕΚΤΡΟΝΙΚΗΣ ΚΑΙ ΥΠΟΛΟΓΙΣΤΩΝ ΕΡΓΑΣΤΗΡΙΟ ΕΥΦΥΩΝ ΣΥΣΤΗΜΑΤΩΝ ΚΑΙ ΤΕΧΝΟΛΟΓΙΑΣ ΛΟΓΙΣΜΙΚΟΥ DPDHMMY - Εργαλείο Ανίχνευσης Σχεδιαστικών Προτύπων Λογισμικού Νούτσος Αντώνης anoutsos@auth.gr ΑΕΜ 6992 Διπλωματική εργασία υπό την επίβλεψη του Επίκουρου Καθηγητή κ. Ανδρέα Λ. Συμεωνίδη και του υποψήφιου διδάκτορα Θεμιστοκλή Διαμαντόπουλου Θεσσαλονίκη 2015

2 Ευχαριστίες Πρώτα από όλα θα ήθελα να ευχαριστήσω τον επιβλέποντα της διπλωματικής μου εργασίας, κ, Ανδρέα Συμεωνίδη, Επ. Καθηγητή του τμήματος Ηλεκτρολόγων Μηχανικών και Μηχανικών Υπολογιστών, για την πολύτιμη βοήθεια, την καθοδήγηση και τη δυνατότητα που μου έδωσε να ασχοληθώ με το αντικείμενο αυτό. Επιπλέον, οφείλω να ευχαριστήσω τον κ. Διαμαντόπουλο Θεμιστοκλή, υποψήφιο διδάκτορα του τμήματος, ο οποίος μου προσέφερε ανεκτίμητη βοήθεια κατά την εκπόνηση της διπλωματικής. Τέλος, θα ήθελα να ευχαριστήσω την οικογένειά μου, τους φίλους και τους συμφοιτητές μου για την πολυδιάστατη βοήθεια τους κατά τα ακαδημαϊκά μου χρόνια. ii

3 Περίληψη Στις μέρες μας, η σωστή σχεδίαση και ανάπτυξη λογισμικού αποτελεί ένα δύσκολο πρόβλημα τόσο για τους μηχανικούς λογισμικού όσο και για τους προγραμματιστές. Ο σκοπός της διαδικασίας ανάπτυξης λογισμικού αφορά όχι μόνο την κάλυψη της λειτουργικότητας της εκάστοτε εφαρμογής, αλλά και τη σωστή οργάνωση του κώδικα, ώστε να ικανοποιεί βασικές μη λειτουργικές απαιτήσεις. Η επεκτασιμότητα, η στιβαρότητα, η ευχρηστία, η συντηρησιμότητα, η μεταφερσιμότητα, η ελεγξιμότητα και η δυνατότητα επαναχρησιμοποίησης κώδικα είναι έννοιες που ο προγραμματιστής χρειάζεται να λαμβάνει υπόψη κατά τη δημιουργία του έργου του. Μια δεδομένη μεθοδολογία για την εξασφάλιση της καλής οργάνωσης και ποιότητας του κώδικα είναι η εφαρμογή διαφόρων προτύπων σχεδίασης που είναι αναγνωρισμένα για την αξία και την χρησιμότητά τους ανά τα χρόνια. Σε αυτό το πλαίσιο, η ανίχνευση σχεδιαστικών προτύπων σε τμήματα κώδικα μπορεί να ενισχύσει την καλύτερη κατανόηση των αρχιτεκτονικών κώδικα, να παρέχει μια μετρική για την αξιολόγηση της ποιότητας του κώδικα, καθώς και να χρησιμεύσει στην εφαρμογή μοτίβων σε υπάρχων κώδικα. Η παρούσα διπλωματική εργασία προτείνει ένα νέο τρόπο απεικόνισης προτύπων σχεδίασης. Η βασική ιδέα στηρίζεται στις συνδέσεις μεταξύ κλάσεων του κώδικα και αντιστοίχηση αυτών σε προκαθορισμένα μοτίβα αρχιτεκτονικών κώδικα. Υλοποιώντας τα παραπάνω, παρουσιάζεται το εργαλείο DPDHMMY, που αποτελεί μια αρκετά φιλική προς τον χρήστη εφαρμογή για την ανίχνευση προτύπων σχεδίασης. Ένα από τα δυνατά σημεία του DPDHMMY είναι η δυνατότητα εισαγωγής κώδικα που δεν έχει περάσει από τον compiler, καθώς εφαρμόζεται καθαρά στατική ανάλυση. Με τον τρόπο αυτό, γίνεται δυνατή η ανίχνευση μοτίβων σε κομμάτια κώδικα που δεν είναι απολύτως ολοκληρωμένα ή μεταγλωττίσιμα, έτσι ώστε ο προγραμματιστής να μπορεί να τα βελτιώσει. Έτσι, είναι δυνατή η χρήση του εργαλείου κατά τη διαδικασία της οργάνωσης του κώδικα (π.χ. κατά τη δημιουργία interfaces) ώστε να διαπιστωθεί κατά πόσο ακολουθούνται τα επιθυμητά μοτίβα. Επιπλέον, παρέχεται η δυνατότητα στο χρήστη να ορίσει τα δικά του σχεδιαστικά πρότυπα, δίνοντας, έτσι, άμεση δυνατότητα επεκτασιμότητας. Νούτσος Αντώνης, Θεσσαλονίκη, Ιούλιος 2015 iii

4 Abstract DPDHMMY: A Design Pattern Detection tool Currently, designing and developing software has grown to be a tedious task. The ultimate goal of the software development process includes not only satisfying the desired functionality of a software product, but also various, sometimes critical, nonfunctional requirements. Extensibility, robustness, usability, maintainability, portability, testability και reusability are concepts that the developer has to take into account during the development of their project. A methodology that ensures proper structured and good quality code is the application of various code design patterns, which are acknowledged for their added. In this context, design pattern detection can improve the understanding of code architectures, while it can also offer an asset in applying patterns in existing code, while ensuring the satisfaction of non-functional criteria. This thesis proposes a new way for representing well known, but also custom design patterns. The methodology builds upon the connections among classes inside a project, in order to match them to predefined design pattern structures. Following the above methodology, we designed and developed DPDHMMY (pronounced dee-pee-deemee), a user-friendly application for design pattern detection. One of the main advantages of DPDHMMY is the capability of detecting patterns even in noncompilable code. Using DPDHMMY, design patterns can be detected in incomplete code or code with errors, in order for the programmer to fix and improve it. Thus, the tool can be used when structuring the source code of an application (e.g. during the definition of interfaces) in order to determine whether proper design patterns are taken into consideration. Furthermore, it provides the users with the option to define their own design patterns, thus, promoting high extensibility. Noutsos Antonis, anoutsos@auth.gr Thessaloniki, July 2015 iv

5 Περιεχόμενα Ευχαριστίες... ii Περίληψη...iii Abstract... iv 1 Εισαγωγή Αντικείμενο Διπλωματικής Στόχος Διπλωματικής Διάρθρωση Κεφαλαίων Σχετική Βιβλιογραφία Εισαγωγή Σχεδιαστικά Πρότυπα Αρχιτεκτονικής Λογισμικού (Design Patterns for Software Architecture) Δημιουργικά σχεδιαστικά πρότυπα (Creational design patterns) Δομικά σχεδιαστικά πρότυπα (Structural design patterns) Σχεδιαστικά πρότυπα Συμπεριφοράς (Behavioral design patterns) Συστήματα αναγνώρισης προτύπων σχεδίασης λογισμικού σε συστήματα και έργα λογισμικού Επισκόπηση τεχνικών ανίχνευσης σχεδιαστικών προτύπων Εργαλεία DPD και DPDHMMY Εισαγωγή DP-Miner (Design Pattern Miner) DPRE (Design Pattern Recovery Environment) PINOT (Pattern INference and recovery Tool) DeMIMA Σύγκριση των εργαλείων DPD Προσέγγιση και Υλοποίηση Εισαγωγή v

6 4.2 Αναπαράσταση Αντικειμένων και Σχέσεων του Κώδικα Αναπαράσταση γνωστών προτύπων σχεδίασης Abstract Factory (Δημιουργικό πρότυπο) Command (Πρότυπο συμπεριφοράς) Bridge (Δομικό πρότυπο) Builder (Δημιουργικό πρότυπο) Visitor (Πρότυπο συμπεριφοράς) Observer (Πρότυπο συμπεριφοράς) Factory Method (Δημιουργικό πρότυπο) Parser Java Compiler Tree API Δομικά Μέρη του Parser και Ανίχνευση Συνδέσεων Αλγόριθμος Ανίχνευσης Προτύπων Σχεδίασης Δομικά μέρη του ανιχνευτή προτύπων σχεδίασης Αλγόριθμος PatternDetection Αλγόριθμος FastPatternDetection Ομαδοποίηση αποτελεσμάτων Γραφικό Περιβάλλον Διεπαφής του DPDHMMY Εισαγωγή Βασικό Παράθυρο Pattern Creator Detect Pattern Αποτελέσματα Πειραμάτων Πείραμα 1: Ειδικά κατασκευασμένα project προτύπων σχεδίασης Abstract Factory Command Bridge vi

7 6.1.4 Builder Visitor Observer Factory Method Κοινό Project Πείραμα 2: Βιβλιοθήκες της Java Συμπεράσματα & Μελλοντική εργασία vii

8 Λίστα Σχημάτων Εικόνα 1. Ομαδοποίηση Σχεδιαστικών Προτύπων (6)... 6 Εικόνα 2. Δομή του σχεδιαστικού προτύπου Factory Method... 7 Εικόνα 3. Δομή του σχεδιαστικού προτύπου Abstract Factory... 8 Εικόνα 4.Δομή σχεδιαστικού προτύπου Builder... 9 Εικόνα 5. Δομή του σχεδιαστικού προτύπου Adapter Εικόνα 6. Δομή του σχεδιαστικού προτύπου Composite Εικόνα 7. Δομή του σχεδιαστικού προτύπου Facade Εικόνα 8. Δομή του σχεδιαστικού προτύπου Template Method Εικόνα 9. Δομή του σχεδιαστικού προτύπου Strategy Εικόνα 10. Δομή του σχεδιαστικού πρότυπου Observer Εικόνα 11. Ανίχνευση του Adapter προτύπου στο Java.awt project Εικόνα 12. Η βαρύτητα των κλάσεων στο Java.awt project Εικόνα 13. Αρχιτεκτονική του DP-Miner Εικόνα 14. DPRE Εικόνα 15. Η διαδικασία ανάκτησης σχεδιαστικών προτύπων Εικόνα 16. Αρχιτεκτονική VLDesk Εικόνα 17. Κατάταξη των 23 GoF σχεδιαστικών προτύπων Εικόνα 18. Μοντέλα του μοτίβου και του πηγαίου κώδικα. (a) MDM (b) Ms (c) MI (d) MD Εικόνα 19. Παράδειγμα δυνατών συνδυασμών προς έλεγχο Εικόνα 20. Παράδειγμα ανίχνευσης design pattern Εικόνα 21.Δέντρο πιθανών συνδυασμών προς έλεγχο Εικόνα 22. Οπτική αναπαράσταση του σχεδιαστικού προτύπου του παραδείγματος προς ομαδοποίηση Εικόνα 23. Οπτική αναπαράσταση των PatternCandidates του παραδείγματος προς ομαδοποίηση viii

9 Εικόνα 24. Οπτική αναπαράσταση των SuperCandidates του παραδείγματος προς ομαδοποίηση Εικόνα 25. Οπτική αναπαράσταση του HyperCandidate του παραδείγματος προς ομαδοποίηση Εικόνα 26. Βασικό παράθυρο gui Εικόνα 27. Πρώτο παράθυρο του Pattern Creator Εικόνα 28. Δεύτερο παράθυρο του Pattern Creator Εικόνα 29. Τρίτο παράθυρο του Pattern Creator Εικόνα 30. Παράδειγμα δημιουργημένου pattern Εικόνα 31. Παράδειγμα αρχείου αποτελεσμάτων Εικόνα 32. Διάγραμμα αποτελεσμάτων DPDHMMY-PINOT για τη βιβλιοθήκη JHotDraw Εικόνα 33. Διάγραμμα αποτελεσμάτων DPDHMMY-PINOT για τη βιβλιοθήκη της Java AWT Εικόνα 34. Διάγραμμα αποτελεσμάτων DPDHMMY-PINOT για τη βιβλιοθήκη Apache Ant ix

10 Λίστα Πινάκων Πίνακας 1. Παράδειγμα Αποτελεσμάτων Ανίχνευσης Σχεδιαστικών Προτύπων Πίνακας 2. Επεξήγηση συνδέσεων Πίνακας 3. Μέλη του Abstract Factory Πίνακας 4. Συνδέσεις του Abstract Factory Πίνακας 5. Μέλη του Command Πίνακας 6. Συνδέσεις του Command Πίνακας 7. Μέλη του Bridge Πίνακας 8. Συνδέσεις του Bridge Πίνακας 9. Μέλη του Builder Πίνακας 10. Συνδέσεις του Builder Πίνακας 11. Μέλη του Visitor Πίνακας 12. Συνδέσεις του Visitor Πίνακας 13. Μέλη του Observer- Μορφή 1 η Πίνακας 14. Συνδέσεις του Observer - Μορφή 1 η Πίνακας 15. Μέλη του Observer - Μορφή 2 η Πίνακας 16. Συνδέσεις του Observer - Μορφή Πίνακας 17. Μέλη του Factory Method- Μορφή 1 η Πίνακας 18. Συνδέσεις του Factory Method - Μορφή 1 η Πίνακας 19. Μέλη του Factory Method - Μορφή 2 η Πίνακας 20. Συνδέσεις του Factory Method - Μορφή 2 η Πίνακας 21. Χρόνοι περάτωσης των δύο αλγορίθμων στο Σύστημα Πίνακας 22. Χρόνοι περάτωσης των δύο αλγορίθμων στο Σύστημα Πίνακας 23. Τα PatternCandidates του παραδείγματος προς ομαδοποίηση Πίνακας 24. Τα SuperCandidates του παραδείγματος προς ομαδοποίηση Πίνακας 25. Το τελικό HyperCandidate του παραδείγματος προς ομαδοποίηση Πίνακας 26. Αποτελέσματα παραδειγμάτων Abstract Factory x

11 Πίνακας 27. Αποτελέσματα παραδειγμάτων Command Πίνακας 28. Αποτελέσματα παραδειγμάτων Bridge Πίνακας 29. Αποτελέσματα παραδειγμάτων Builder Πίνακας 30. Αποτελέσματα παραδειγμάτων Visitor Πίνακας 31. Αποτελέσματα παραδειγμάτων Observer Πίνακας 32. Αποτελέσματα παραδειγμάτων Factory Method Πίνακας 33. Αποτελέσματα Εκτέλεσης σε κοινό Project που περιέχει όλα τα πρότυπα σχεδίασης Πίνακας 34. Συγκεντρωτικά αποτελέσματα DPDHMMY-PINOT xi

12 1 DPDHMMY Εργαλείο Ανίχνευσης Σχεδιαστικών Προτύπων Λογισμικού 1 Εισαγωγή 1.1 Αντικείμενο Διπλωματικής Στην εποχή μας η σχεδίαση και ανάπτυξη λογισμικού αποκτά κάθε μέρα μεγαλύτερη σημασία και επηρεάζει άμεσα τόσο τον κόσμο των επιχειρήσεων και της επιστημονικής έρευνας, όσο και τους καταναλωτές. Η ανάγκη εφαρμογής κοινών προτύπων ανάπτυξης κώδικα μέσω σχεδιαστικών μοτίβων/αρχιτεκτονικών (Design Patterns) για την οργάνωση του κώδικα εφαρμογών είναι επιτακτική [1] [2]. Πολλές φορές όμως, οι μηχανικοί λογισμικού καλούνται να ανασχηματίσουν έργα λογισμικού, εφαρμόζοντας σε αυτά απαραίτητες για τη συντήρησή τους, αρχιτεκτονικές. Για να το επιτύχουν αυτό, χρειάζεται να χρησιμοποιήσουν εργαλεία ανίχνευσης διαφόρων αρχιτεκτονικών και συνδέσεων, γνωστά και ως Design Pattern Detection (DPD) tools. Με τη χρήση αυτών των εργαλείων, η δομή και η οργάνωση του κώδικα βελτιώνεται, ενσωματώνοντας μη λειτουργικές απαιτήσεις όπως επεκτασιμότητα (extensibility), στιβαρότητα (robustness), ευχρηστία (usability), συντηρησιμότητα (maintainability), μεταφερσιμότητα (portability), ελεγξιμότητα (testability) και δυνατότητα επαναχρησιμοποίησης (reusability). [3] [4] Κατανοώντας τη σημασία των DPD στην ανάπτυξη ποιοτικού λογισμικού, αυτή η διπλωματική επιδιώκει να παρουσιάσει μια νέα οπτική γωνία στο αντικείμενο, αναπτύσσοντας ένα νέο εργαλείο DPD στο πλαίσιο μιας μεθοδολογίας για την ανίχνευση μοτίβων σε κώδικα. 1.2 Στόχος Διπλωματικής Στόχος της παρούσας διπλωματικής εργασίας είναι η ανάδειξη ενός τρόπου επίλυσης του προβλήματος της ανίχνευσης αρχιτεκτονικών λογισμικού σε κώδικα, που αποτελεί μέρος της γενικότερης επιστήμης της αντίστροφης μηχανικής συστημάτων λογισμικού (reverse engineering of software systems). Αφορμή για την ανάπτυξη μιας τέτοιας μεθοδολογίας, και κατ επέκταση εργαλείου, ήταν η ανάγκη ανίχνευσης αρχιτεκτονικών λογισμικού. Κατά την αναζήτηση εργαλείων DPD, διαπιστώνεται πως πληθώρα τέτοιων εργαλείων χρησιμοποιεί στατική και δυναμική ανάλυση για την εύρεση των αποτελεσμάτων. Έτσι, καθίσταται ιδιαίτερα δύσκολη η αυτοματοποίηση της διαδικασίας, μιας και απαιτούνται precompiled αρχεία (.class), πράγμα που σημαίνει πως ο χρήστης πρέπει πρώτα να περάσει τον κώδικα του

13 2 DPDHMMY Εργαλείο Ανίχνευσης Σχεδιαστικών Προτύπων Λογισμικού από τον compiler (χωρίς να έχει λάθη) και μετά να χρησιμοποιήσει το εργαλείο. Επιπλέον, τα περισσότερα συστήματα που βρέθηκαν είτε δε λειτουργούν (λόγω έλλειψης απαραίτητων ενημερώσεων) ή δε διαθέτουν επαρκή σχολιασμό και βοηθητικό υλικό για το χρήστη. Σαν λύση σε όλα τα παραπάνω, η συγκεκριμένη διπλωματική προτείνει το DPDHMMY. Το DPDHMMY χρησιμοποιεί μόνο στατική ανάλυση (δέχεται αρχεία.java) μέσω ενός parser, είναι εύκολο στη χρήση και, σαν επιπλέον στοιχείο, δίνει στο χρήστη τη δυνατότητα να σχεδιάσει δικά του πρότυπα σχεδίασης και να τα ανιχνεύσει στον κώδικα. 1.3 Διάρθρωση Κεφαλαίων Η παρούσα διπλωματική αποτελείται από επτά κεφάλαια. Στο κεφάλαιο 2 αναφέρονται τα βασικά πρότυπα σχεδίασης που χρησιμοποιούνται σήμερα, ενώ επίσης γίνεται μια βιβλιογραφική επισκόπηση των μεθόδων που χρησιμοποιούνται για την ανίχνευσή τους. Το κεφάλαιο 3 αναλύει τη δομή και τη λειτουργία μερικών δημοφιλών DPD tools και προσδιορίζει τις δυνατότητες βελτίωσής τους. Μετέπειτα, στο κεφάλαιο 4 αναλύεται η λειτουργία του DPDHMMY και επεξηγείται ο αλγόριθμος ανίχνευσης ενώ στο κεφάλαιο 5 παρουσιάζεται το γραφικό περιβάλλον διεπαφής (GUI) του DPDHMMY. Το κεφάλαιο 6 περιέχει τα αποτελέσματα των πειραμάτων που πραγματοποιήθηκαν, ενώ η διπλωματική κλείνει με συμπεράσματα και προτάσεις για επέκταση στο κεφάλαιο 7.

14 3 DPDHMMY Εργαλείο Ανίχνευσης Σχεδιαστικών Προτύπων Λογισμικού 2 Σχετική Βιβλιογραφία 2.1 Εισαγωγή Σε αυτό το κεφάλαιο αναφέρονται μερικά γενικά στοιχεία για τα σχεδιαστικά πρότυπα αρχιτεκτονικής λογισμικού, ενώ στη συνέχεια αναλύονται ενδεικτικά κάποια από τα βασικά πρότυπα. Επιπλέον, γίνεται αναφορά στις υπάρχουσες μεθόδους και τα εργαλεία λογισμικού για την αναγνώριση γνωστών προτύπων σχεδίασης σε συστήματα και έργα λογισμικού. 2.2 Σχεδιαστικά Πρότυπα Αρχιτεκτονικής Λογισμικού (Design Patterns for Software Architecture) «Κάθε πρότυπο (pattern) περιγράφει ένα πρόβλημα που εμφανίζεται ξανά και ξανά στο περιβάλλον μας και περιγράφει τον πυρήνα της λύσης ενός συγκεκριμένου προβλήματός, με τέτοιο τρόπο ώστε να είναι δυνατή η χρήση αυτής της επίλυσης ένα εκατομμύριο φορές, χωρίς ποτέ να γίνει με τον ίδιο ακριβώς τρόπο.» Christopher Alexander [5] Αυτή η πρόταση του Christopher Alexander είναι άκρως κατατοπιστική για την αξία των σχεδιαστικών προτύπων, στην περίπτωσή μας λογισμικού, και η επιστήμη της πληροφορικής δεν θα έχανε την ευκαιρία να ενσωματώσει οποιοδήποτε εργαλείο θα της προσέφερε τη δυνατότητα επαναχρησιμοποίησης και απλούστευσης. Πιο συγκεκριμένα, τα σχεδιαστικά πρότυπα λογισμικού διευκολύνουν την επαναχρησιμοποίηση επιτυχημένων σχεδιασμών και αρχιτεκτονικών. Επιπλέον, είναι εξαιρετικά κερδοφόρο για τους νέους σχεδιαστές λογισμικού να χρησιμοποιούν έτοιμα μοτίβα που δημιουργήθηκαν από την πολυετή εμπειρία των προκατόχων τους. Ακόμη, τα σχεδιαστικά πρότυπα βοηθούν στην επιλογή εναλλακτικών μεθόδων που κάνουν ένα σύστημα επαναχρησιμοποιήσιμο, αποφεύγοντας τον κίνδυνο επιλογής κάποιου μη επαναχρησιμοποιήσιμου σχεδιασμού. Επίσης, η χρήση προτύπων συνεισφέρει στο σχολιασμό και στη συντήρηση των ήδη υπαρχόντων συστημάτων, παρέχοντας μια σαφή περιγραφή των σχέσεων και αλληλεπιδράσεων μεταξύ κλάσεων και αντικειμένων. Συνοπτικά, τα σχεδιαστικά πρότυπα βοηθούν έναν σχεδιαστή λογισμικού να στήσει την αρχιτεκτονική του συστήματός του σωστά και γρήγορα. Η πλειοψηφία των πληροφοριών για τα σχεδιαστικά πρότυπα που αναφέρονται σε αυτό το κεφάλαιο βρέθηκαν στο βιβλίο Design Patterns: Elements of Reusable Object- Oriented Software [6] που θεωρείται ένα από τα σημαντικότερα βιβλία επί του

15 4 DPDHMMY Εργαλείο Ανίχνευσης Σχεδιαστικών Προτύπων Λογισμικού θέματος, ή ακόμη και σήμα κατατεθέν των σχεδιαστικών προτύπων. Οι ιδιαίτερα καταξιωμένοι στο χώρο του λογισμικού συγγραφείς του Erich Gamma, Richard Helm, Ralph Johnson και John Vlissides έχουν ονομαστεί Gang of Four (GoF), η συμμορία των τεσσάρων. Τα πρότυπα σχεδίασης σε αυτό το βιβλίο θεωρούνται περιγραφές της επικοινωνίας αντικειμένων και κλάσεων που είναι προσαρμοσμένα έτσι ώστε να λύνουν ένα γενικό πρόβλημα σχεδίασης εντός ενός συγκεκριμένου πλαισίου. Σύμφωνα με τους GoF, κάθε σχεδιαστικό πρότυπο αποτελείται από: Το όνομα του προτύπου Το πρόβλημα προς επίλυση Την λύση του αντίστοιχου προβλήματος Τις συνέπειες και τους συμβιβασμούς που επιφέρονται Επιπλέον, τα πρότυπα ταξινομούνται σύμφωνα με δύο κριτήρια: Σκοπός (purpose): αντικατοπτρίζει το αποτέλεσμα της εφαρμογής ενός προτύπου σχεδίασης. Πεδίο Δράσης (scope): προσδιορίζει κατά πόσο εφαρμόζεται το πρότυπο σχεδίασης κατά κύριο λόγο σε κλάσεις ή αντικείμενα. Όσον αφορά τον σκοπό, τα πρότυπα σχεδίασης μπορούν να είναι δημιουργικά (creational), δομικά (structural) ή συμπεριφοράς (behavioral). Τα δημιουργικά πρότυπα έχουν να κάνουν με τη διαδικασία της δημιουργίας αντικειμένων. Τα δομικά αφορούν τη σύνθεση των κλάσεων και των αντικειμένων. Και τέλος τα συμπεριφοράς χαρακτηρίζουν τους τρόπους με τους οποίους οι κλάσεις ή τα αντικείμενα αλληλοεπιδρούν και ανακατανέμουν την ευθύνη μεταξύ τους. Σύμφωνα με το κριτήριο του πεδίου δράσης, τα πρότυπα χωρίζονται σε πρότυπα κλάσεων και αντικειμένων. Τα πρότυπα κλάσεων ασχολούνται με τις σχέσεις μεταξύ κλάσεων και υποκλάσεων. Αυτές οι σχέσεις έχουν κατοχυρωθεί μέσω κληρονομικότητας, οπότε είναι στατικές, καθορισμένες κατά την διαδικασία μεταγλώττισης (compile time). Τα πρότυπα αντικειμένων αναφέρονται σε σχέσεις μεταξύ αντικειμένων, που μπορούν να μεταβληθούν κατά το χρόνο εκτέλεσης (run time) και συνεπώς είναι δυναμικές. Η πλειοψηφία των προτύπων χρησιμοποιεί κληρονομικότητα σε κάποιο βαθμό και για αυτό το λόγο τα μόνα πρότυπα στην

16 5 DPDHMMY Εργαλείο Ανίχνευσης Σχεδιαστικών Προτύπων Λογισμικού κατηγορία των προτύπων κλάσεων είναι αυτά που εστιάζουν στις σχέσεις κλάσεων. Τα περισσότερα πρότυπα ανήκουν στην κατηγορία των προτύπων αντικειμένων. Παρακάτω αναφέρονται τα 23 πρότυπα σχεδίασης που προτείνουν οι GoF ταξινομημένα ως προς τον σκοπό, μαζί με έναν αντιπροσωπευτικό πίνακα. Στην συνέχεια του κεφαλαίου, θα αναλυθούν εκτενέστερα μερικά από αυτά τα 23 μοτίβα. Δημιουργικά (Creational) Factory Method (Μέθοδος εργοστασίου) Abstract Factory (Αφαιρετικό εργοστάσιο) Builder (Χτίστης) Prototype (Πρωτότυπο) Singleton (Μοναδιαίο) Δομικά (Structural) Adapter (Προσαρμογέας) Bridge (Γέφυρα) Composite (Σύνθετο Πρότυπο) Decorator (Διακοσμητής) Flyweight Facade (Πρόσοψη) Proxy Συμπεριφοράς (Behavioral) Interpreter (Διερμηνέας) Template Method (Μέθοδος υπόδειγμα) Chain of Responsibility (Αλυσίδα ευθύνης) Command (Πρότυπο Εντολής) Iterator Mediator (Μεσολαβητής) Memento (Ενθύμιο) Observer (Παρατηρητής) State (Πρότυπο Κατάστασης) Strategy (Πρότυπο Στρατηγικής) Visitor (Επισκέπτης)

17 6 DPDHMMY Εργαλείο Ανίχνευσης Σχεδιαστικών Προτύπων Λογισμικού Εικόνα 1. Ομαδοποίηση Σχεδιαστικών Προτύπων [6]

18 7 DPDHMMY Εργαλείο Ανίχνευσης Σχεδιαστικών Προτύπων Λογισμικού Δημιουργικά σχεδιαστικά πρότυπα (Creational design patterns) Τα δημιουργικά πρότυπα επιχειρούν να προτυποποιήσουν την διαδικασία δημιουργίας υλοποιήσεων (instances). Βοηθούν στο να δημιουργηθεί ένα σύστημα ανεξάρτητο από το πώς τα αντικείμενά του δημιουργούνται, από τί αποτελούνται και πώς αναπαρίστανται. Ένα πρότυπο κλάσης σε αυτήν την κατηγορία χρησιμοποιεί κληρονομικότητα για να μεταβάλει την κλάση που υλοποιείται, ενώ ένα αντίστοιχο πρότυπο αντικειμένου θα αναθέτει την υλοποίηση σε κάποιο άλλο αντικείμενο. Μερικά από αυτά αναλύονται στις επόμενες παραγράφους a Factory Method Σκοπός: Να ορισθεί μια διεπαφή για τη δημιουργία ενός αντικειμένου, αφήνοντας όμως τις υποκλάσεις να αποφασίσουν ποια κλάση να υλοποιήσουν. Η Factory Method αφήνει μια κλάση να υποβάλει την υλοποίηση στις υποκλάσεις. Δομή: Εικόνα 2. Δομή του σχεδιαστικού προτύπου Factory Method Συμμετέχοντα μέρη: Product: καθορίζει την διεπαφή των αντικειμένων που δημιουργούνται. ConcreteProduct: υλοποιεί την διεπαφή Product. Creator: καθορίζει την FactoryMethod, που επιστρέφει ένα αντικείμενο τύπου Product. ConcreteCreator: παρακάμπτει τη FactoryMethod για να επιστρέψει μια υλοποίηση ενός ConcreteProduct.

19 8 DPDHMMY Εργαλείο Ανίχνευσης Σχεδιαστικών Προτύπων Λογισμικού Πλεονεκτήματα-Μειονεκτήματα: Εξαλείφει την ανάγκη για δέσμευση συγκεκριμένων ως προς την εφαρμογή κλάσεων στον κώδικα. Παρέχει πατήματα για τις υποκλάσεις. Συνδέει ιεραρχίες παράλληλων κλάσεων. Οι πελάτες μπορεί να χρειαστεί να δημιουργήσουν υποκλάσεις στην Creator κλάση για να δημιουργήσουν ένα ConcreteProduct αντικείμενο b Abstract Factory Σκοπός: Να δοθεί μια διεπαφή για την δημιουργία οικογενειών συναφών ή εξαρτώμενων αντικειμένων χωρίς να προσδιορίζονται οι κλάσεις τους αυτές καθ αυτές. Δομή: Εικόνα 3. Δομή του σχεδιαστικού προτύπου Abstract Factory Συμμετέχοντα μέρη: AbstractFactory: δηλώνει μια διεπαφή για τις λειτουργίες που δημιουργούν AbstractProduct αντικείμενα. ConcreteFactory: υλοποιεί τις λειτουργίες για την δημιουργία ConcreteProduct αντικειμένων. AbstractProduct: δηλώνει μια διεπαφή για έναν τύπο Product αντικειμένου. ConcreteProduct: ορίζει ένα αντικείμενο Product για να το δημιουργήσει το αντίστοιχο ConcreteFactory. Επίσης, υλοποιεί την διεπαφή AbstractProduct.

20 9 DPDHMMY Εργαλείο Ανίχνευσης Σχεδιαστικών Προτύπων Λογισμικού Client: Χρησιμοποιεί μόνο τις διεπαφές που ανακηρύχθηκαν από κλάσεις AbstractFactory και AbstractProduct. Πλεονεκτήματα-Μειονεκτήματα: Απομονώνει συγκεκριμένες κλάσεις. Κάνει την ανταλλαγή οικογενειών προϊόντων ευκολότερη. Προωθεί την συνοχή μεταξύ των προϊόντων. Η υποστήριξη νέων ειδών προϊόντων είναι δύσκολη c Builder Σκοπός: Να διαχωριστεί η κατασκευή ενός σύνθετου αντικειμένου από την απεικόνισή του, έτσι ώστε η ίδια διαδικασία κατασκευής να μπορεί να δημιουργήσει διαφορετικές απεικονίσεις. Δομή: Εικόνα 4.Δομή σχεδιαστικού προτύπου Builder Συμμετέχοντα μέρη: Builder: καθορίζει μια γενικευμένη διεπαφή για την δημιουργία τμημάτων του Product. ConcreteBuilder: κατασκευάζει και συναρμολογεί τα τμήματα του Product υλοποιώντας την Builder διεπαφή. Επιπλέον, καθορίζει και παρακολουθεί την απεικόνιση που δημιουργεί. Τέλος, παρέχει μια διεπαφή για την ανάκτηση του Product. Director: κατασκευάζει ένα αντικείμενο χρησιμοποιώντας την διεπαφή Builder.

21 10 DPDHMMY Εργαλείο Ανίχνευσης Σχεδιαστικών Προτύπων Λογισμικού Product: αντιπροσωπεύει το σύνθετο αντικείμενο υπό κατασκευή. Το ConcreteBuilder χτίζει την εσωτερική απεικόνιση του Product και καθορίζει τη διαδικασία με την οποία συναρμολογείται. Περιλαμβάνει κλάσεις που καθορίζουν τα συστατικά μέλη, συμπεριλαμβανομένων των διεπαφών που συναρμολογούν τα διάφορα μέλη στο τελικό αποτέλεσμα. Πλεονεκτήματα-Μειονεκτήματα: Επιτρέπει την ποικιλομορφία στην εσωτερική απεικόνιση ενός προϊόντος. Απομονώνει κώδικα για την κατασκευή και την απεικόνιση. Προσδίδει καλύτερο έλεγχο κατά την διάρκεια της κατασκευαστικής διαδικασίας Δομικά σχεδιαστικά πρότυπα (Structural design patterns) Τα δομικά σχεδιαστικά πρότυπα αφορούν το πώς οι κλάσεις και τα αντικείμενα δομούνται για να σχηματίσουν μεγαλύτερες δομές. Τα πρότυπα αυτά χρησιμοποιούν κληρονομικότητα για να συνθέσουν διεπαφές ή υλοποιήσεις. Η προστιθέμενη ευελιξία της σύστασης αντικειμένων προέρχεται από την ικανότητα να αλλαχθεί η σύσταση κατά τον χρόνο της εκτέλεσης, το οποίο είναι αδύνατο με μια στατική σύνθεση κλάσεων. Μερικά από αυτά αναλύονται στις επόμενες παραγράφους: a Adapter Σκοπός: Να μετατρέψει τη διεπαφή μιας κλάσης σε άλλη διεπαφή την οποία προσδοκούν οι πελάτες. O Adapter επιτρέπει σε κλάσεις, που αλλιώς δεν θα μπορούσαν λόγω των ασυμβίβαστων διεπαφών τους, να δουλέψουν μαζί. Δομή: Εικόνα 5. Δομή του σχεδιαστικού προτύπου Adapter

22 11 DPDHMMY Εργαλείο Ανίχνευσης Σχεδιαστικών Προτύπων Λογισμικού Συμμετέχοντα μέρη: Target: καθορίζει τη συγκεκριμένη ως προς τον τομέα διεπαφή που χρησιμοποιεί ο Client. Client: συνεργάζεται με τα αντικείμενα που συμμορφώνονται με τη διεπαφή Target. Adaptee: καθορίζει μία υπάρχουσα διεπαφή που χρειάζεται προσαρμογή. Adapter: προσαρμόζει τη διεπαφή του Adaptee στη διεπαφή Target. Πλεονεκτήματα-Μειονεκτήματα: Το σχεδιαστικό πρότυπο Adapter παρουσιάζει διαφορετικά πλεονεκτήματα και μειονεκτήματα ανάλογα με το πεδίο δράσης του. Έτσι : Class Adapter Επιτρέπει στον Adapter να παρακάμψει κάποιες από τις συμπεριφορές του Adaptee. Εισάγει μόνο ένα αντικείμενο. Ένας Class Adapter δεν θα λειτουργήσει όταν θελήσουμε να προσαρμόσουμε μια κλάση και όλες τις υποκλάσεις της. Object Adapter Επιτρέπει σε ένα και μόνο Adapter να δουλέψει με πολλούς Adaptees. Καθιστά δυσκολότερη την παράκαμψη συμπεριφοράς του Adaptee b Composite Σκοπός: Να συνθέσει αντικείμενα σε δομές δέντρων ώστε να απεικονίσει ολομελείς ιεραρχίες. Επιτρέπει στους πελάτες να μεταχειριστούν μεμονωμένα αντικείμενα και συνθέσεις αντικειμένων ομοιόμορφα.

23 12 DPDHMMY Εργαλείο Ανίχνευσης Σχεδιαστικών Προτύπων Λογισμικού Δομή: Εικόνα 6. Δομή του σχεδιαστικού προτύπου Composite Συμμετέχοντα μέρη: Component: δηλώνει τη διεπαφή για τα αντικείμενα στη σύνθεση και υλοποιεί την προεπιλεγμένη συμπεριφορά για την κοινή σε όλες τις κλάσεις διεπαφή. Επίσης, καθορίζει μια διεπαφή για την πρόσβαση και την διαχείριση των παιδιών του. Προαιρετικά, ορίζει μια διεπαφή για την πρόσβαση ενός πατέρα ενός συστατικού μέρους στην επαναληπτική δομή και την υλοποιεί αν είναι δόκιμο. Leaf: απεικονίζει τα αντικείμενα φύλλα στην σύνθεση. Ένα φύλλο δεν έχει παιδιά. Επιπλέον, καθορίζει τη συμπεριφορά για πρωταρχικά αντικείμενα στη σύνθεση. Composite: καθορίζει τη συμπεριφορά για τα συστατικά μέλη των παιδιών. Επίσης, αποθηκεύει τα συστατικά μέλη των παιδιών και υλοποιεί διαδικασίες στην διεπαφή Component που έχουν να κάνουν με τα παιδιά. Client: χειρίζεται αντικείμενα στη σύνθεση μέσω της διεπαφής Component. Πλεονεκτήματα-Μειονεκτήματα: Ορίζει ιεραρχίες κλάσεων αποτελούμενες από πρωταρχικά αντικείμενα και σύνθετα αντικείμενα. Κάνει τον Client (πελάτη) πιο εύκολο στην διαχείριση και υλοποίηση.

24 13 DPDHMMY Εργαλείο Ανίχνευσης Σχεδιαστικών Προτύπων Λογισμικού Καθιστά ευκολότερη την προσθήκη νέων ειδών συστατικών μελών. Μπορεί να κάνει τη σχεδίαση υπερβολικά γενικευμένη c Façade Σκοπός: Να παρέχει μια ενιαία διεπαφή σε ένα σύνολο διεπαφών σε ένα υποσύστημα. Να ορίσει μια υψηλού επιπέδου διεπαφή που καθιστά το υποσύστημα ευκολότερο στη χρήση. Δομή: Εικόνα 7. Δομή του σχεδιαστικού προτύπου Facade Συμμετέχοντα μέρη: Façade: γνωρίζει ποιες κλάσεις του υποσυστήματος είναι υπεύθυνες και αναθέτει αιτήσεις πελατών σε κατάλληλα αντικείμενα του υποσυστήματος. Subsystem Classes: υλοποιούν την λειτουργικότητα του υποσυστήματος. Επιπλέον, χειρίζονται την εργασία που τους ανατέθηκε από το Façade αντικείμενο και δεν έχουν καμία γνώση επί του Façade, δηλαδή δεν έχουν καμιά αναφορά σε αυτό. Πλεονεκτήματα-Μειονεκτήματα: Μειώνει την σύζευξη πελάτη-υποσυστήματος Επιτρέπει την έκθεση μόνο των δημόσιων κλάσεων του υποσυστήματος Σχεδιαστικά πρότυπα Συμπεριφοράς (Behavioral design patterns) Τα σχεδιαστικά πρότυπα συμπεριφοράς αφορούν αλγορίθμους και αναθέσεις ευθυνών μεταξύ αντικειμένων. Περιγράφουν όχι μόνο την σχεδίαση των αντικειμένων ή των κλάσεων, αλλά και την σχεδίαση της επικοινωνίας μεταξύ τους. Χαρακτηρίζουν μία πολύπλοκη ροή ελέγχου (control flow) που είναι δύσκολο να ακολουθηθεί κατά τον

25 14 DPDHMMY Εργαλείο Ανίχνευσης Σχεδιαστικών Προτύπων Λογισμικού χρόνο εκτέλεσης. Τα σχεδιαστικά πρότυπα συμπεριφοράς στρέφουν το βλέμμα του προγραμματιστή μακριά από τη ροή ελέγχου, ώστε να επικεντρωθεί μόνο στον τρόπο με τον οποίο τα αντικείμενα συνδέονται. Μερικά από αυτά αναλύονται στις επόμενες παραγράφους a Template Method Σκοπός: Να ορίσει τον σκελετό ενός αλγορίθμου σε μια διεργασία, αναβάλλοντας μερικά βήματα σε υποκλάσεις. Να επιτρέπει σε υποκλάσεις να επαναπροσδιορίσουν ορισμένα βήματα χωρίς να αλλάξει η αλγοριθμική δομή. Δομή: Εικόνα 8. Δομή του σχεδιαστικού προτύπου Template Method Συμμετέχοντα μέρη: AbstractClass: ορίζει γενικευμένες πρωταρχικές διεργασίες που συγκεκριμένες υποκλάσεις καθορίζουν για να υλοποιήσουν βήματα ενός αλγορίθμου. Υλοποιεί μια TemplateMethod, ορίζοντας τον σκελετό ενός αλγορίθμου και στην συνέχεια αυτή καλεί πρωταρχικές διεργασίες, καθώς και διεργασίες καθορισμένες στο AbstractClass ή σε άλλα αντικείμενα. ConcreteClass: υλοποιεί τις πρωταρχικές διεργασίες για την διεξαγωγή συγκεκριμένων ως προς τις υποκλάσεις βημάτων του αλγορίθμου. Πλεονεκτήματα-Μειονεκτήματα: Το σχεδιαστικό πρότυπο Template Method είναι μία θεμελιώδης τεχνική για επαναχρησιμοποίηση κώδικα. Είναι ιδιαίτερα σημαντικό σε βιβλιοθήκες κλάσεων.

26 15 DPDHMMY Εργαλείο Ανίχνευσης Σχεδιαστικών Προτύπων Λογισμικού Μια υποκλάση μπορεί να παρακάμπτει την συμπεριφορά μιας διεργασίας μιας κλάσης γονιού παρακάμπτοντας την διεργασία και καλώντας ρητά την διεργασία του γονιού. Παρατηρείται ότι συχνά παραλείπεται η κλήση της κληρονομημένης διεργασίας b Strategy Σκοπός: Να ορίσει μια οικογένεια αλγορίθμων, να τους συμπυκνώσει και να τους καταστήσει εναλλάξιμους. Να επιτρέψει στον αλγόριθμο να ποικίλει ανεξάρτητα από τους πελάτες που τον χρησιμοποιούν. Δομή: Εικόνα 9. Δομή του σχεδιαστικού προτύπου Strategy Συμμετέχοντα μέρη: Strategy: καθορίζει μια διεπαφή, κοινή σε όλους τους υποστηριζόμενους αλγορίθμους. Το Context χρησιμοποιεί αυτήν την διεπαφή για να καλέσει τον αλγόριθμο που καθορίζει το ConcreteStrategy. ConcreteStrategy: υλοποιεί τον αλγόριθμο που χρησιμοποιεί η διεπαφή Strategy. Context: έχει ρυθμιστεί με ένα αντικείμενο ConcreteStrategy και διατηρεί μια αναφορά σε ένα αντικείμενο Strategy. Επιπλέον, μπορεί να καθορίσει μια διεπαφή που επιτρέπει στο Strategy να έχει πρόσβαση στα δεδομένα. Πλεονεκτήματα-Μειονεκτήματα: Ορίζει οικογένειες σχετικών αλγορίθμων. Προσδίδει μια εναλλακτική λύση για subclassing.

27 16 DPDHMMY Εργαλείο Ανίχνευσης Σχεδιαστικών Προτύπων Λογισμικού Εξαλείφει υπό όρους δηλώσεις (conditional statements) Παρουσιάζει μια ευρεία επιλογή εφαρμογών. Οι πελάτες πρέπει να έχουν επίγνωση των διαφορετικών στρατηγικών. Υπερβολική επικοινωνία μεταξύ Strategy και Context. Αύξηση του αριθμού των αντικειμένων c Observer Σκοπός: Να ορίσει μια εξάρτηση ένα-προς-πολλά μεταξύ αντικειμένων, έτσι ώστε όταν ένα αντικείμενο αλλάζει κατάσταση, όλα τα εξαρτώμενα σε αυτό αντικείμενα να ενημερώνονται και να αναβαθμίζονται αυτόματα. Δομή: Εικόνα 10. Δομή του σχεδιαστικού πρότυπου Observer Συμμετέχοντα μέρη: Subject: γνωρίζει τους Observers του. Οσαδήποτε Observer αντικείμενα μπορούν να παρακολουθούν ένα Subject. Επιπλέον, παρέχει μια διεπαφή για τη σύνδεση και αποσύνδεση αντικειμένων Observer. Observer: ορίζει μια διεπαφή αναβάθμισης για αντικείμενα που πρέπει να ενημερωθούν για τυχόν αλλαγές στο Subject.

28 17 DPDHMMY Εργαλείο Ανίχνευσης Σχεδιαστικών Προτύπων Λογισμικού ConcreteSubject: αποθηκεύει καταστάσεις ενδιαφέροντος σε αντικείμενα ConcreteObserver και στέλνει μια ειδοποίηση στους Observers, όταν η κατάστασή του αλλάζει. ConcreteObserver: διατηρεί μια αναφορά σε ένα αντικείμενο ConcreteSubject και αποθηκεύει την κατάσταση που θα έπρεπε να μένει συνεπής ως προς αυτή του Subject. Επίσης, υλοποιεί την διεπαφή ενημέρωσης του Observer, ώστε η κατάστασή του να κρατηθεί συνεπής ως προς αυτή του Subject. Πλεονεκτήματα-Μειονεκτήματα: Προσφέρει γενικευμένη και ελάχιστη σύζευξη μεταξύ Subject και Observer. Υποστηρίζει αναμετάδοση επικοινωνίας. Μπορεί να προκύψουν απρόοπτες ενημερώσεις.

29 18 DPDHMMY Εργαλείο Ανίχνευσης Σχεδιαστικών Προτύπων Λογισμικού 2.3 Συστήματα αναγνώρισης προτύπων σχεδίασης λογισμικού σε συστήματα και έργα λογισμικού Τα μεγάλα συστήματα λογισμικού είναι συνήθως δύσκολο να κατανοηθούν και να μεταβληθούν λόγω της έλλειψης τεκμηρίωσης για την αρχιτεκτονική και τη σχεδίαση λογισμικού. Μετά την ολοκλήρωση τέτοιων συστημάτων, οι πληροφορίες για την αρχική αρχιτεκτονική και τον σχεδιασμό συνήθως χάνεται. Έτσι, ο μόνος τρόπος για να κατανοηθούν αυτά τα συστήματα είναι να ανακτηθεί πληροφορία από τον πηγαίο κώδικα. Ωστόσο, ο πηγαίος κώδικας είναι συνήθως μεγάλος σε έκταση και εξαιρετικά δύσκολος στην κατανόηση. Η χειροκίνητη ανάγνωσή του είναι μια ιδιαίτερα χρονοβόρα και επιρρεπής σε λάθη διαδικασία. Η κατανόηση των συστημάτων είναι πολύ σημαντική, δεδομένου ότι μπορεί να βοηθήσει στην διαχείριση και την αλλαγή τους. Τα συστήματα λογισμικού γενικότερα πρέπει να επιδέχονται μεταβολές λόγω των διαρκών αλλαγών στις απαιτήσεις των χρηστών, στις πλατφόρμες, στις τεχνολογίες και στα διάφορα περιβάλλοντα. Η διαδικασία κατανόησης του κώδικα λογισμικού εντάσσεται στο γενικότερο πλαίσιο της αντίστροφης μηχανικής (reverse engineering).τα εργαλεία για κατανόηση προγραμμάτων σήμερα είναι ικανά να εξάγουν διάφορες πηγαίες πληροφορίες, όπως δομές κλάσεων, εσωτερικές σχέσεις κλάσεων, διαγράμματα κλήσεων κ.λπ. Κάποια εργαλεία μπορεί ακόμη και να παράγουν UML διαγράμματα. Στο πλαίσιο της παρούσας διπλωματικής εργασίας, επικεντρωνόμαστε σε εργαλεία αναγνώρισης σχεδιαστικών προτύπων. Ένα παράδειγμα αναγνώρισης σχεδιαστικών προτύπων σε ένα κώδικα φαίνεται στον παρακάτω πίνακα. Πίνακας 1. Παράδειγμα Αποτελεσμάτων Ανίχνευσης Σχεδιαστικών Προτύπων

30 19 DPDHMMY Εργαλείο Ανίχνευσης Σχεδιαστικών Προτύπων Λογισμικού Οι προσεγγίσεις για την αναγνώριση προτύπων σχεδίασης εμπίπτουν σε δύο βασικές κατηγορίες: αυτές που προσδιορίζουν τη δομική πτυχή των προτύπων και αυτές που κάνουν ένα βήμα παραπάνω προσπαθώντας να διακρίνουν την συμπεριφορά τους. Οι πρώτες αναλύουν τις εσωτερικές σχέσεις μεταξύ των κλάσεων για να προσδιορίσουν τη δομική πλευρά του μοτίβου ανεξαρτήτως της συμπεριφοράς του. Αυτές οι σχέσεις συμπεριλαμβάνουν κληρονομικότητα κλάσεων, ιεραρχίες διεπαφών, τροποποιήσεις κλάσεων και μεθόδων, τύπους και προσβασιμότητα χαρακτηριστικών, αντιπροσώπευση μεθόδων, παραμέτρους και επιστρεφόμενους τύπους. Αυτές οι προσεγγίσεις δε δύναται να αναγνωρίσουν πρότυπα που είναι όμοια δομικά, αλλά διαφέρουν ως προς την συμπεριφορά, όπως State-Strategy, Chain of Responsibility- Decorator. Οι προσεγγίσεις που ασχολούνται με την συμπεριφορά των προτύπων προσπαθούν να λύσουν το πρόβλημα αυτό χρησιμοποιώντας μηχανική μάθηση (machine learning), δυναμική ανάλυση και στατική ανάλυση προγράμματος. Στο επόμενο υποκεφάλαιο, θα γίνει εκτενέστερη ανάλυση στις κατηγορίες των διαφόρων τεχνικών αναγνώρισης σχεδιαστικών προτύπων. 2.4 Επισκόπηση τεχνικών ανίχνευσης σχεδιαστικών προτύπων Λόγω της ύπαρξης διαφόρων εργαλείων και μεθόδων αναγνώρισης προτύπων λογισμικού, δημιουργήθηκε η ανάγκη να κατηγοριοποιηθούν οι τεχνικές σύμφωνα με τις οποίες λειτουργούν. Με αυτόν τον τρόπο γίνεται δυνατή η ανάλυση των μεθόδων και κατ επέκταση των προτερημάτων και μειονεκτημάτων καθεμιάς από αυτές. Υπάρχουν διάφοροι τρόποι να κατηγοριοποιήσουμε τα εργαλεία που υπάρχουν αυτή τη στιγμή στη βιβλιογραφία. Σύμφωνα με την βιβλιογραφία [7], η ομαδοποίηση των τεχνικών αναγνώρισης προτύπων βασίζεται στον τύπο της ανάλυσης που χρησιμοποιείται και στη μεθοδολογία αναζήτησης που υιοθετείται. Οι κατηγορίες ανάλυσης είναι: Δομική ανάλυση Ανάλυση συμπεριφοράς Σημασιολογική ανάλυση Ανάλυση τυπικών προδιαγραφών/σύνθεσης Η δομική ανάλυση στηρίζεται στα δομικά στοιχεία του πηγαίου κώδικα και κατ επέκταση στις συνδέσεις και αλληλεπιδράσεις μεταξύ των κλάσεών του. Σημαντικά στοιχεία για αυτή την ανάλυση είναι η κληρονομικότητα (inheritance), η συσχέτιση

31 20 DPDHMMY Εργαλείο Ανίχνευσης Σχεδιαστικών Προτύπων Λογισμικού (association), η «φιλία» (friend relationship), η ιεραρχία διεπαφών (interface hierarchy) και άλλα. Οι μέθοδοι αυτής της κατηγορίας χρησιμοποιούν εργαλεία για την εξαγωγή των στοιχείων και των συσχετίσεων από τον κώδικα και εφαρμόζουν τεχνικές αναγνώρισης προτύπων σε [8] [9]. Οι προσεγγίσεις που χρησιμοποιούν ανάλυση συμπεριφοράς αφορούν τη συμπεριφορά της εκτέλεσης του προγράμματος. Βασίζονται στη δυναμική ανάλυση, σε τεχνικές Μηχανικής Μάθησης και στατικής ανάλυσης προγράμματος, με σκοπό να εξάγουν στοιχεία συμπεριφοράς προτύπων. Η συγκεκριμένη ανάλυση χρησιμοποιείται όταν η στατική ανάλυση αδυνατεί να ξεχωρίσει πρότυπα που είναι πανομοιότυπα όσον αφορά τη δομή τους. Συνήθως, χρησιμοποιείται σε συνεργασία με τη δομική ανάλυση για μια πιο ολοκληρωμένη και ακριβή εικόνα των σχεδιαστικών προτύπων του κώδικα. Η σημασιολογική ανάλυση, συνήθως, αποτελεί ένα στάδιο ανάλυσης πολλών εργαλείων, αφού έχει επέλθει η δομική και η ανάλυση συμπεριφοράς. Οι τεχνικές αυτής της κατηγορίας ανάλυσης χρησιμοποιούνται κυρίως για την ελάττωση των ψευδώς θετικών αποτελεσμάτων (false positives). Αυτό επιτυγχάνεται με την αναγνώριση διαφόρων συμβάσεων ονομασίας και σχολίων, τα οποία περιέχουν πληροφορίες ρόλων για κλάσεις και μεθόδους [10] [11]. Η ανάλυση τυπικών προδιαγραφών/σύνθεσης είναι επίσης σημαντική στο τομέα της ανίχνευσης σχεδιαστικών προτύπων. Οι προσεγγίσεις αυτής της κατηγορίας επικεντρώνονται στην τυποποίηση και τη σύνθεση των σχεδιαστικών προτύπων για τον προσδιορισμό τους σε μια τυπική γλώσσα (formal language. Έτσι, η ανάλυση αυτή ενισχύει τις προηγούμενες αναλύσεις ορίζοντας τυποποιημένα είδη προτύπων [12] [13] [14] [15]. Οι διάφορες προσεγγίσεις χωρίζονται επίσης με βάση τις μεθοδολογίες αναζήτησης προτύπων που χρησιμοποιούν [7]. Οι μεθοδολογίες αυτές είναι οι εξής: Ερωτήματα βάσεων δεδομένων: Πληθώρα εργαλείων χρησιμοποιεί αυτή τη μεθοδολογία. Τα εργαλεία αυτά μετατρέπουν τον πηγαίο κώδικα σε αναπαραστάσεις όπως AST, XMI, UML κ.α. και μετά χρησιμοποιούν ερωτήματα SQL για να εξάγουν σχετική πληροφορία προτύπων πάνω σε αυτές τις αναπαραστάσεις [11] [16] [8] [17] [18]. Αναλυτές περιορισμών: Η μεθοδολογία αυτή αναπτύχθηκε κυρίως από την ερευνητική ομάδα του PTIDEJ [19]. Βασίζεται στην ανάπτυξη μιας

32 21 DPDHMMY Εργαλείο Ανίχνευσης Σχεδιαστικών Προτύπων Λογισμικού πλατφόρμας αντίστροφης μηχανικής λογισμικού που αναγνωρίζει ιδιώματα, μακρο-πρότυπα και σχεδιαστικά πρότυπα που βασίζονται σε περιορισμούς προγραμματιστικών τεχνικών. Κάθε ρόλος αντιπροσωπεύεται από μια μεταβλητή, ενώ οι συνδέσεις μεταξύ ρόλων αναπαρίστανται ως περιορισμοί μεταξύ μεταβλητών Μετρικές: Οι προσεγγίσεις αυτές επεξεργάζονται μετρικές προγραμμάτων, όπως γενικεύσεις (generalizations), συναθροίσεις (aggregations), συσχετίσεις (associations), ιεραρχίες διεπαφών (interface hierarchies) και άλλα, από διαφορετικές αναπαραστάσεις πηγαίου κώδικα και μετέπειτα χρησιμοποιούν διάφορες τεχνικές για τον ορισμό σχεδιαστικών προτύπων με βάση αυτές τις μετρικές. Οι προσεγγίσεις αυτής της κατηγορίας είναι ιδιαίτερα ταχείες, αλλά καλύπτουν μια μικρή γκάμα σχεδιαστικών προτύπων [20] [21] [22] [23]. XPG formalism και parsing: Αυτές οι τεχνικές χρησιμοποιούν το SVG (scalable vector graphics) format για την άμεση αναπαράσταση του πηγαίου κώδικα και των σχεδιαστικών προτύπων σε οπτική γλώσσα. Τα σχεδιαστικά πρότυπα ανακτώνται με τη χρήση μιας γραμματικής οπτικής γλώσσας που εφαρμόζεται για κάθε πρότυπο [24] [25] [11]. UML δομές και πίνακες: Οι τεχνικές αυτής της κατηγορίας αναπαριστούν δομικές πληροφορίες και πληροφορίες συμπεριφοράς των συστημάτων λογισμικού ως δομές και πίνακες UML. Χρησιμοποιούν διάφορες τεχνικές για το ταίριασμα των μετρικών των σχεδιαστικών προτύπων με τους πίνακες των δομών UML. Συνήθως, αυτές οι τεχνικές είναι ιδιαίτερα αποδοτικές και έχουν καλή ακρίβεια, αλλά δε παρέχουν τη δυνατότητα αλληλεπίδρασης με το χρήστη και δε καλύπτουν μεγάλη γκάμα σχεδιαστικών προτύπων [25] [10] [26]. Η παραπάνω κατηγοριοποίηση καλύπτει ένα μεγάλο μέρος τεχνικών για την ανάκτηση σχεδιαστικών προτύπων. Αναφέρεται, ωστόσο, ότι υπάρχουν επίσης τεχνικές που δεν ανήκουν αυστηρά σε κάποια από αυτές τις κατηγορίες [7]. Ειδικότερα για την περιγραφή ενός εργαλείου DPD χρειάζεται ο προσδιορισμός των εξής χαρακτηριστικών [27]: Τύπος ανάλυσης: Όπως αναφέρθηκε και παραπάνω, η ανάλυση είναι ένα κύριο ζήτημα στα εργαλεία/τεχνικές ανίχνευσης σχεδιαστικών προτύπων. Τύπος αναγνώρισης: Αφορά τις διάφορες μεθόδους ταιριάσματος/αναγνώρισης των σχεδιαστικών προτύπων με βάση την

33 22 DPDHMMY Εργαλείο Ανίχνευσης Σχεδιαστικών Προτύπων Λογισμικού πληροφορία που εξάγεται. Παραδείγματα των παραπάνω τεχνικών είναι το ταίριασμα γράφων (graph matching), το ταίριασμα προτύπων (pattern matching), οι κανονικές εκφράσεις (regular expressions), τα ερωτήματα SQL (SQL queries), τα ερωτήματα SPARQL πάνω σε RDF, οι λύτες περιορισμών (constraint solvers) και η λογική πρώτης τάξης (first order logic). Τύπος εισόδου: Προφανώς ο τρόπος και ο τύπος της εισόδου των δεδομένων παίζει σημαντικό ρόλο στη διαδικασία ανίχνευσης σχεδιαστικών προτύπων, είτε αυτό γίνεται με συγκεκριμένη γλώσσα, ή με απευθείας είσοδο του κώδικα. Ενδιάμεση αναπαράσταση: Πολλές φορές είναι χρήσιμο να μετατρέπεται η πληροφορία εισόδου σε μια ενδιάμεση μορφή, όπως ASTs (Abstract Syntax Trees), Abstract Semantic Graphs, UML ή άλλα ad-hoc μετα-μοντέλα. Τέλος, για την πιο συστηματική κατηγοριοποίηση και αξιολόγηση ενός εργαλείου DPD, χρειάζεται ο προσδιορισμός των παρακάτω στοιχείων [7]: Input: Ο τύπος και ο τρόπος της εισόδου. Output: Ο τύπος και ο τρόπος αναπαράστασης των αποτελεσμάτων. Analysis type: Όπως αναφέρθηκε παραπάνω, οι διάφοροι τύποι ανάλυσης. Automated/Semi-automated: Η αυτοματοποίηση της διαδικασίας. Variant handling (customization): Η δυνατότητα επιρροής του χρήστη στο εργαλείο και στα αποτελέσματά του. Scalability: Η δυνατότητα επεκτασιμότητας. Recovered patterns: Τα σχεδιαστικά πρότυπα που μπορεί να ανιχνεύσει. Intermediate representations: Ο τύπος ενδιάμεσης αναπαράστασης που χρησιμοποιεί. Experiments: Τα πειράματα που έχει παραθέσει σαν αποδεικτικά της αποτελεσματικότητάς του. Accuracy: Η ακρίβεια των αποτελεσμάτων. Pattern representation: Η μέθοδος αναπαράστασης των σχεδιαστικών προτύπων. Matching roles: Το είδος ταιριάσματος που χρησιμοποιείται, δηλαδή αν χρησιμοποιείται απόλυτο ταίριασμα (exact matching) ή μερικό (partial matching).

34 23 DPDHMMY Εργαλείο Ανίχνευσης Σχεδιαστικών Προτύπων Λογισμικού 3 Εργαλεία DPD και DPDHMMY 3.1 Εισαγωγή Σε αυτό το κεφάλαιο αρχικά παρουσιάζονται πιο αναλυτικά μερικά γνωστά εργαλεία ανίχνευσης σχεδιαστικών προτύπων. Στη συνέχεια, οι δυνατότητες αυτών των εργαλείων σχολιάζονται με σκοπό τον προσδιορισμό των στοιχείων τα οποία βελτιώνονται στο πλαίσιο της παρούσας διπλωματικής. 3.2 DP-Miner (Design Pattern Miner) Το DP-Miner είναι ένα εργαλείο που εισήγαγαν οι Jing Dong, Dushyant S. Lad και Yajing Zhao στο τμήμα επιστήμης υπολογιστών από το πανεπιστήμιο των Ηνωμένων Πολιτειών, University of Texas at Dallas Richardson [28]. Η προσέγγισή τους στηρίζεται στο να ανακαλύπτει σχεδιαστικά πρότυπα προσδιορίζοντας τα δομικά χαρακτηριστικά κάθε προτύπου με βάση ένα συντελεστή «βαρύτητας» και έναν πίνακα. Η διαδικασία αυτή περιλαμβάνει διάφορες φάσεις ανάλυσης και χρησιμοποιεί το πρότυπο XMI (XML Metadata Interchange), έτσι ώστε να είναι συμβατή με άλλες τεχνικές. Εικόνα 11. Ανίχνευση του Adapter προτύπου στο Java.awt project Όπως αναφέρθηκε το DP-Miner χρησιμοποιεί την έννοια ενός συντελεστή «βαρύτητας» και αντιπροσωπευτικούς πίνακες. Συγκεκριμένα, η δομή του συστήματος απεικονίζεται σε ένα πίνακα, με τις στήλες και τις γραμμές να είναι όλες οι κλάσεις του

35 24 DPDHMMY Εργαλείο Ανίχνευσης Σχεδιαστικών Προτύπων Λογισμικού συστήματος. Η τιμή κάθε κελιού αντιπροσωπεύει τις σχέσεις μεταξύ των κλάσεων. Αυτό γίνεται και για κάθε σχεδιαστικό πρότυπο παράγοντας έτσι επιπλέον πίνακες. Η ανίχνευση σχεδιαστικών προτύπων από τον πηγαίο κώδικα πραγματοποιείται αντιπαραβάλλοντας τους δύο πίνακες μεταξύ τους. Αν ο πίνακας του προτύπου ταιριάζει με αυτόν του συστήματος, τότε αυτό σημαίνει πως ένα υποψήφιο μέρος του σχεδιαστικού προτύπου βρέθηκε. Εικόνα 12. Η βαρύτητα των κλάσεων στο Java.awt project Εκτός των πινάκων, χρησιμοποιείται η βαρύτητα της ομοιότητας με κάθε πρότυπο για να αντιπροσωπευτούν οι ιδιότητες/λειτουργίες κάθε κλάσης και οι σχέσεις της με τις υπόλοιπες κλάσεις. Επιπρόσθετα του δομικού πλαισίου, εξετάζεται και η σημασιολογική δομή και η συμπεριφορά του συστήματος για την ανίχνευση σχεδιαστικών προτύπων. Όπως αναφέρθηκε παραπάνω, το DP-Miner χρησιμοποιεί το πρότυπο XMI που είναι ένα format εναλλαγής για μεταδεδομένα. Το XMI προσδιορίζει πως τα μοντέλα UML αποθηκεύονται σε ένα XML αρχείο. Έτσι, απεικονίζοντας ένα μοντέλο UML σε XML είναι δυνατή η αναζήτηση για σχεδιαστικά πρότυπα. Γενική λειτουργία: Τα αντικειμενοστραφή συστήματα μπορούν να αναπαρασταθούν σε UML διαγράμματα με υπάρχοντα εργαλεία, όπως το IBM Rational Rose. Αν και τα UML διαγράμματα αποθηκεύονται σε ιδιόκτητα format των αντίστοιχων εργαλείων, η εξαγωγή τους σε format XMI είναι συνήθως δυνατή. Αυτά τα αρχεία XMI

36 25 DPDHMMY Εργαλείο Ανίχνευσης Σχεδιαστικών Προτύπων Λογισμικού περιλαμβάνουν όλες τις πληροφορίες συστήματος και έτσι αντί να αναλύεται ο πηγαίος κώδικας, δίνεται η δυνατότητα ανάλυσης των αρχείων XMI. Όπως φαίνεται στο αντιπροσωπευτικό σχήμα που ακολουθεί, η προσέγγιση του DP- Miner αποτελείται από τρεις φάσεις: την δομική ανάλυση, την ανάλυση συμπεριφοράς και τη σημασιολογική ανάλυση. Εικόνα 13. Αρχιτεκτονική του DP-Miner Η δομική ανάλυση αφορά τα δομικά χαρακτηριστικά του συστήματος, όπως τις κλάσεις και τις σχέσεις μεταξύ τους. Τα αποτελέσματα της δομικής ανάλυσης μπορεί να συμπεριλαμβάνουν περιστατικά που δεν είναι στην πραγματικότητα σχεδιαστικά πρότυπα. Τέτοια περιστατικά ονομάζονται ψευδώς θετικά (false positives). Η ανάλυση συμπεριφοράς ελέγχει τα αποτελέσματα από την δομική ανάλυση για false positives. Σε μερικές περιπτώσεις είναι εξαιρετικά δύσκολο να διακριθούν μερικά σχεδιαστικά πρότυπα μεταξύ τους, όπως Strategy-Bridge, επειδή έχουν κοινά δομικά και χαρακτηριστικά συμπεριφοράς. Σε τέτοιες περιπτώσεις επιβάλλεται η χρήση σημασιολογικής ανάλυσης. Όταν ένα σχεδιαστικό πρότυπο εφαρμοστεί σε ένα σύστημα, οι προγραμματιστές μπορεί να ακολουθήσουν μια σύμβαση ονομασίας και να συμπεριλάβουν πληροφορίες ρόλων του προτύπου κατά την ονομασία των κλάσεων. Έτσι, το DP-Miner ελέγχει αν η σύμβαση ονομασίας μπορεί να ανιχνεύσει κάποιο σχεδιαστικό πρότυπο. Και οι τρεις αυτοί τύποι ανάλυσης έχουν ενσωματωθεί στο DP-Miner έτσι ώστε οι χρήστες να χρειάζονται μόνο να δημιουργήσουν την είσοδο XMI από ήδη υπάρχοντα εργαλεία.

37 26 DPDHMMY Εργαλείο Ανίχνευσης Σχεδιαστικών Προτύπων Λογισμικού 3.3 DPRE (Design Pattern Recovery Environment) Το DPRE είναι ένα εργαλείο που αναπτύχθηκε στο τμήμα μαθηματικών και πληροφορικής του πανεπιστημίου του Salerno στην Ιταλία από τους Gennaro Costagliola, Andrea De Lucia, Vincenzo Deufemia, Carmine Gravino και Michele Risi [29]. Το DPRE ακολουθεί μια προσέγγιση ως προς την ανίχνευση αντικειμενοστραφών σχεδιαστικών προτύπων που χρησιμοποιεί μια βιβλιοθήκη σχεδιαστικών προτύπων, εκφρασμένη με όρους οπτικής γραμματικής (visual grammar) και βασισμένη σε μια οπτική τεχνική κατάτμησης γλώσσας (visual language parsing technique). Στην ουσία, η εφαρμογή της συγκεκριμένης προσέγγισης έχει σαν είσοδο UML διαγράμματα κλάσεων και σαν έξοδο αυτόματα προκύπτουν τα διάφορα σχεδιαστικά πρότυπα. Εικόνα 14. DPRE Το σύστημα επικεντρώνεται στα δομικά σχεδιαστικά πρότυπα, όπου οι πληροφορίες είναι ρητές στην συντακτική απεικόνισή τους. Η διαδικασία της ανάκτησης χωρίζεται σε δύο μέρη: πρώτα ο εισαγόμενος αντικειμενοστραφής κώδικας μεταφράζεται σε διαγράμματα κλάσεων απεικονιζόμενα σε SVG format και στη συνέχεια τα σχεδιαστικά πρότυπα ανακτώνται χρησιμοποιώντας μια προσέγγιση κατάτμησης οπτικής γλώσσας. Έτσι, το πρόβλημα ανάγεται στην αναγνώριση υποπροτάσεων σε ένα διάγραμμα κλάσεων, όπου κάθε υποπρόταση αντιστοιχεί σε ένα ξεχωριστό

38 27 DPDHMMY Εργαλείο Ανίχνευσης Σχεδιαστικών Προτύπων Λογισμικού σχεδιαστικό πρότυπο καθορισμένο από μια γραμματική. Επίσης, το περιβάλλον του DPRE επιτρέπει την οπτική απεικόνιση του εισαγόμενου UML διαγράμματος. Γενική Λειτουργία: Όπως αναφέρθηκε, η γενική λειτουργία του DPRE οργανώνεται σε δύο φάσεις: Την φάση εξαγωγής διαγραμμάτων κλάσεων UML: όπου ο αντικειμενοστραφής κώδικας μεταφράζεται σε διαγράμματα κλάσεων σε SVG format. Την φάση αναγνώρισης προτύπων: όπου το DPRE ανακτά τα σχεδιαστικά πρότυπα χρησιμοποιώντας μία προσέγγιση κατάτμησης γράφων. Εικόνα 15. Η διαδικασία ανάκτησης σχεδιαστικών προτύπων Στην φάση της εξαγωγής διαγραμμάτων κλάσεων UML, η είσοδος της διαδικασίας, δηλαδή ο αντικειμενοστραφής κώδικας, προεπεξεργάζεται από το Source Code Extractor (εξαγωγέας πηγαίου κώδικα), έτσι ώστε να διεξαχθεί μια ενδιάμεση αναπαράστασή του. Στην συνέχεια, ο Class Diagram Abstractor ( αφαιρέτης διαγραμμάτων κλάσεων) εισάγει τα εξαγόμενα έγγραφα και δημιουργεί την αντίστοιχη δομή γραφήματος. Ο μεταφραστής SVG (SVG translator) προσθέτει πληροφορίες διάταξης στο γράφημα και το αντίστοιχο UML διάγραμμα κλάσεων μεταφράζεται σε SVG format. Στην φάση της αναγνώρισης προτύπων το DPRE οπτικοποιεί το εισαγόμενο διάγραμμα κλάσεων. Το DPRE υποστηρίζει το SVG ως εσωτερική μορφή δεδομένων και περιλαμβάνει έναν αλγόριθμο οπτικοποίησης γραφημάτων ώστε να οπτικοποιήσει το διάγραμμα κλάσεων. Μετέπειτα, τα σχεδιαστικά πρότυπα ανακτώνται χρησιμοποιώντας ένα πρόγραμμα κατάτμησης που είναι ενσωματωμένο στο οπτικό περιβάλλον. Αφού η διαδικασία της αναγνώρισης έχει τελειώσει, το οπτικό περιβάλλον εμφανίζει μια αναφορά που περιέχει όλα τα στατιστικά ως προς τα ανακτημένα

39 28 DPDHMMY Εργαλείο Ανίχνευσης Σχεδιαστικών Προτύπων Λογισμικού σχεδιαστικά πρότυπα, περιγράφοντας επίσης τις κλάσεις και τους ρόλους τους για κάθε πρότυπο. Δημιουργία του DPRE: Το DPRE κατασκευάστηκε με το VLDesk (Visual Language Desk), ένα σύστημα παραγωγής οπτικού περιβάλλοντος που βασίζεται σε γραμματικές. Τα βασικά στοιχεία του συστήματος VLDesk είναι: Symbol Editor: Χρησιμοποιείται από τον σχεδιαστή, ώστε να δημιουργήσει τερματικά και μη σύμβολα της γραμματικής. Ουσιαστικά, επιτρέπει στον σχεδιαστή να προσδιορίσει την εμφάνιση των συμβόλων, μαζί με τα συντακτικά τους χαρακτηριστικά και τα δυνατά οπτικά ή γραπτά σχόλια που επισυνάπτονται σε αυτά. Visual Production Editor: Είναι ένα οπτικό στοιχείο που επιτρέπει στο σχεδιαστή γλώσσας τον καθορισμό μιας γραμματικής XPG (extended Positional Grammars) και των σημασιολογικών ρουτινών. Textual Production Editor: Επιτρέπει στον σχεδιαστή να ορίσει τους κανόνες της γραμματικής μαζί με σημασιολογικές δράσεις μέσω ενός επεξεργαστή κειμένου. Visual Programming Environment Generator: Παράγει τον οπτικό συντάκτη (visual editor) και έναν XpLR αναλυτή (XpLR parser), αφού η γραμματική XPG έχει οριστεί από τον σχεδιαστή γλώσσας. Εικόνα 16. Αρχιτεκτονική VLDesk

40 29 DPDHMMY Εργαλείο Ανίχνευσης Σχεδιαστικών Προτύπων Λογισμικού 3.4 PINOT (Pattern INference and recovery Tool) Το PINOT αναπτύχθηκε στο τμήμα πληροφορικής του πανεπιστημίου της California των Ηνωμένων Πολιτειών από τους Nija Shi και Ronald A. Olsson [30]. Η προσέγγιση που ακολουθεί το σύστημα αυτό βασίζεται στην ανακατάταξη των GoF σχεδιαστικών προτύπων με βάση την πρόθεση του κάθε προτύπου. Σύμφωνα με τους σχεδιαστές του PINOT, η κλασική κατάταξη των GoF σχεδιαστικών προτύπων είναι βασισμένη στην έννοια της κατά μέτωπο σχεδίασης (forward engineering), ενώ η ανακατάταξη που προτείνουν είναι καταλληλότερη για αντίστροφη σχεδίαση (reverse engineering). Έτσι, το PINOT χρησιμοποιεί ελαφριές τεχνικές στατικής ανάλυσης προγράμματος για να συλλάβει την πρόθεση του προγράμματος. Κατάταξη σχεδιαστικών προτύπων PINOT: Στην παρακάτω εικόνα φαίνεται η κατάταξη των σχεδιαστικών προτύπων ακολουθεί το PINOT με βάση τη λειτουργία του κάθε προτύπου. που Εικόνα 17. Κατάταξη των 23 GoF σχεδιαστικών προτύπων Οι 5 κατηγορίες των προτύπων είναι οι εξής: Σχεδιαστικά πρότυπα παρεχόμενα από γλώσσες (Language-provided Patterns): Πολλές γλώσσες (Java, Python κ.α.) υλοποιούν κάποια κοινά σχεδιαστικά πρότυπα για την διευκόλυνση των προγραμματιστών. Έτσι, οι προγραμματιστές χρησιμοποιούν τέτοια ενσωματωμένα εργαλεία για την αποτελεσματική και αποδοτική ανάπτυξη συστημάτων λογισμικού. Τέτοιες περιπτώσεις προτύπων μπορούν να αναγνωριστούν ανιχνεύοντας συγκεκριμένα ονόματα μεθόδων ή ελέγχοντας αν μια κλάση υλοποιεί μια συγκεκριμένη διεπαφή της Java. Τέτοια είναι τα Iterator και Prototype.

41 30 DPDHMMY Εργαλείο Ανίχνευσης Σχεδιαστικών Προτύπων Λογισμικού Σχεδιαστικά πρότυπα οδηγούμενα από την δομή (Structure-driven Patterns): Σε αυτή την κατηγορία τα πρότυπα μπορούν να αναγνωριστούν μέσω των ενδο-κλασικών σχέσεων. Τέτοιες σχέσεις καθορίζουν την ολική αρχιτεκτονική του συστήματος, αλλά δεν ορίζουν την πραγματική συμπεριφορά του. Ενδο-κλασικές σχέσεις χρησιμοποιούνται για τον διαχωρισμό των αρμοδιοτήτων των κλάσεων που περιέχουν δηλώσεις, γενικεύσεις, σχέσεις σύνδεσης και αντιπροσώπευσης. Τέτοια είναι τα Bridge, Composite, Adapter, Façade, Proxy, Template Method και Visitor. Σχεδιαστικά πρότυπα οδηγούμενα από την συμπεριφορά (Behavior-driven Patterns): Μερικά πρότυπα έχουν σχεδιαστεί για να πραγματοποιούν μερικές απαιτήσεις συμπεριφοράς. Τέτοια πρότυπα σχεδιασμού είναι ενσωματωμένα με κάποια πρόθεση προγράμματος που πραγματοποιείται μέσω των ενδοκλασικών σχέσεων και μεθόδων. Τέτοια είναι τα Singleton, Abstract Factory, Factory Method, Flyweight, Chain of Responsibility (CoR), Decorator, Strategy, State, Observer και Mediator. Σχεδιαστικά πρότυπα συγκεκριμένα ως προς τον τομέα (Domain-specific Patterns): Μερικά σχεδιαστικά πρότυπα συνδυάζουν άλλα GoF πρότυπα και εξειδικεύονται σε ένα συγκεκριμένο τομέα εφαρμογής. Για παράδειγμα το πρότυπο Interpreter χρησιμοποιεί την δομή του Composite και την συμπεριφορά του Visitor. Τέτοια είναι τα Interpreter και Command. Γενικές έννοιες (Generic Concepts): Τα πρότυπα που απομένουν ασχολούνται μόνο με γενικές έννοιες και δεν έχουν ανιχνεύσιμα στοιχεία. Τέτοια είναι τα Builder και Memento. Το PINOT μπορεί να αναγνωρίσει όλες τις παραπάνω κατηγορίες εκτός των δύο τελευταίων, Domain-specific και Generic Concepts. Ανίχνευση Προτύπων: Η ανίχνευση των σχεδιαστικών προτύπων διαφέρει για κάθε κατηγορία από αυτές που αναφέρθηκαν παραπάνω. Ενδεικτικά για την κατηγορία των Structure-driven προτύπων, τα πρότυπα αυτά μπορούν να ανιχνευτούν από τις ενδο-κλασικές τους σχέσεις που μπορούν να αντληθούν από ανάλυση του κώδικα. Ένα παράδειγμα είναι για το Visitor πρότυπο. Εδώ οι ενδο-κλασικές σχέσεις που πρέπει να ανιχνευτούν είναι μια δήλωση μεθόδου accept (π.χ. void Accept(Visitor v)), καθορισμένη στο στοιχείο

42 31 DPDHMMY Εργαλείο Ανίχνευσης Σχεδιαστικών Προτύπων Λογισμικού κλάση που καλεί έναν visitor (επισκέπτη) και μια επίκληση μεθόδου (method invocation) visit (π.χ. v.visit(this)), όπου ένα στοιχείο εκτίθεται στον επισκέπτη. Για την κατηγορία των Behavior-driven προτύπων, χρησιμοποιείται ανάλυση ροής δεδομένων (data-flow analysis) σε δέντρα AST σαν βασικά μπλοκ. Επεξεργάζοντας κάθε μέθοδο, αναγνωρίζονται τα βασικά μπλοκ, το καθένα από τα οποία περιέχει δηλώσεις που εκτελούνται κάτω από ίδιες συνθήκες. Ύστερα, τα βασικά μπλοκ που βασίζονται στην ροή εκτέλεσης ενώνονται για να σχηματίσουν έναν γράφο ελέγχου ροής (Control-flow graph-cfg).

43 32 DPDHMMY Εργαλείο Ανίχνευσης Σχεδιαστικών Προτύπων Λογισμικού 3.5 DeMIMA Το DeMIMA αναπτύχθηκε από τους Yann-Gaël Guéhéneuc και Giuliano Antoniol το 2007 [24]. Ακολουθεί μια προσέγγιση για την ημιαυτόματη αναγνώριση μικροαρχιτεκτονικών όμοιων με σχεδιαστικά μοτίβα σε πηγαίο κώδικα, το οποίο πραγματοποιεί σε τρία στρώματα, δύο για την ανάκτηση ενός αφαιρετικού μοντέλου από τον πηγαίο κώδικα και ένα τρίτο για την αναγνώριση σχεδιαστικών προτύπων στο αφαιρετικό αυτό μοντέλο. Βασίζεται στην ανίχνευση δύο ειδών σχεδιαστικών μορφών στον κώδικα, των ιδιωμάτων (idioms) και των μοτίβων (motifs). Τα ιδιώματα είναι χαμηλού επιπέδου πρότυπα σχεδιασμένα για μια προγραμματιστική γλώσσα και για την υλοποίηση συγκεκριμένων χαρακτηριστικών κλάσεων και σχέσεων. Μοτίβο, σύμφωνα με τους σχεδιαστές του DeMIMA, είναι η λύση ενός σχεδιαστικού προτύπου σαν ένα αξιόπιστο δείγμα χαρακτηριστικών, δράσεων, τάσεων ή άλλων παρατηρήσιμων χαρακτηριστικών. Οι συντηρητές λογισμικού συνήθως αναλύουν τον πηγαίο κώδικα του συστήματος S, είτε χειροκίνητα είτε με την χρήση διαφόρων εργαλείων και έτσι προσδιορίζουν τα υποσύνολα του πηγαίου κώδικα που είναι παρόμοια με γνωστά μοτίβα. Σε αυτή την επίπονη διαδικασία έρχεται το DeMIMA να βοηθήσει τους συντηρητές παρέχοντας μια διαδικασία τριών βημάτων που αναγνωρίζει τα σχεδιαστικά μοτίβα DM σε ένα πηγαίο κώδικα S ενός συστήματος βασισμένου σε διαγράμματα τύπου UML. Αυτά τα τρία βήματα είναι : Μοντελοποίηση του πηγαίου κώδικα S σαν μοντέλο Ms Εμπλουτισμός του μοντέλου Ms με ιδιώματα που αποκαλύπτουν δυαδικές σχέσεις κλάσεων για να αποκτηθεί το μοντέλο MI Εμπλουτισμός του μοντέλου MI ακολουθώντας τρία υποβήματα: o Δημιουργία ενός μοντέλου MDM ενός μοτίβου DM ως διάγραμμα κλάσεων για να περιγράψει το MI. o Αναγνώριση μικροαρχιτεκτονικών στο MI όμοιων με το MDM o Δημιουργία ενός μοντέλου ΜD βασισμένο στο MI και εμπλουτισμένο με μοντέλα MμA των αναγνωρισμένων μικροαρχιτεκτονικών

44 33 DPDHMMY Εργαλείο Ανίχνευσης Σχεδιαστικών Προτύπων Λογισμικού Εξίσωση 1. Τα 3 στρώματα του DeMIMA Στο DeMIMA χαρακτηρίζονται τα συστατικά των διαγραμμάτων κλάσεων και προτείνονται αλγόριθμοι για την αναγνώριση των συστατικών αυτών στον πηγαίο κώδικα. Για αυτό τον λόγο, αναπτύχθηκε ένα μεταμοντέλο, Pattern and Abstract-level Description Language (PADL), για να εκφράσει αυτά τα συστατικά. Εικόνα 18. Μοντέλα του μοτίβου και του πηγαίου κώδικα. (a) MDM (b) Ms (c) MI (d) MD Γενική λειτουργία: Όπως αναφέρθηκε το DeMIMA οργανώνεται σε τρία στρώματα : 1 ο Στρώμα: Source Code Model-MS : Το πρώτο στρώμα αποτελείται από μια υποδομή, π.χ. αναλυτές, για να αποκτήσει τα μοντέλα Ms του πηγαίου κώδικα συστημάτων. Τα συστατικά του περιγράφουν την δομή των συστημάτων και ένα υποσύνολο των συμπεριφορών. Τα βασικά συστατικά στο μεταμοντέλο και οι σχέσεις τους είναι η κλάση οντότητα (Class Entity), για να περιγράψει τις οντότητες του συστήματος, και το στοιχείο κλάσης (Class Element), για να

45 34 DPDHMMY Εργαλείο Ανίχνευσης Σχεδιαστικών Προτύπων Λογισμικού περιγράψει τα στοιχεία των οντοτήτων. Class Entities μπορούν να είναι οι κλάσεις ή οι διεπαφές, ενώ Class Elements οι μέθοδοι και τα πεδία. 2 ο Στρώμα: Idiom-Level Model-MI : Το δεύτερο στρώμα περιγράφει τα συστήματα σε ένα υψηλότερο αφαιρετικό επίπεδο από τον πηγαίο κώδικα, καθιστώντας έτσι σαφέστερα συγκεκριμένα ιδιώματα. Τα ιδιώματα αποκαλύπτουν ιδιαίτερα χαρακτηριστικά κλάσεων ή σχέσεων αυτών. 3 ο Στρώμα: Design-Level Model-MD : Στο τρίτο στρώμα πρώτα περιγράφεται το μοντέλο MD ενός σχεδιαστικού μοτίβου με την ίδια γλώσσα που χρησιμοποιήθηκε για το MI. Στη συνέχεια, το DeMIMA ψάχνει για μικροαρχιτεκτονικές MμΑ όμοιες με το σχεδιαστικό μοτίβο DM σε ένα μοντέλο MI ενός συστήματος. 3.6 Σύγκριση των εργαλείων DPD Τα εργαλεία που παρουσιάστηκαν παραπάνω αποτελούν χαρακτηριστικό δείγμα της βιβλιογραφίας στην ανίχνευση σχεδιαστικών προτύπων. Στο πλαίσιο της παρούσας διπλωματικής, μετά από έρευνα στο αντικείμενο, διαπιστώθηκε η ανάγκη κατασκευής ενός νέου εργαλείου με σκοπό την ευκολότερη και εγκυρότερη ανίχνευση των προτύπων. Το εργαλείο που κατασκευάσαμε, το DPDHMMY, παρουσιάζεται στο επόμενο κεφάλαιο, ενώ σε αυτό το σημείο αναλύονται οι επιπρόσθετες δυνατότητές του σε σχέση με τα άλλα εργαλεία. Το DPDHMMY είναι ένα εργαλείο αναγνώρισης σχεδιαστικών προτύπων λογισμικού, που χρησιμοποιείται πάνω σε κώδικα σε γλώσσα Java. Στηρίζεται μόνο στη δομική ανάλυση σε αντίθεση με αρκετά άλλα εργαλεία που κυκλοφορούν. Έτσι, ένα βασικό πλεονέκτημα του εργαλείο είναι ότι επιτρέπει την εξέταση κώδικα που δεν έχει μεταγλωττισθεί (compiled) και κατ επέκταση κώδικα με πιθανά λάθη (errors). Αυτό βοηθάει στην μεταφερσιμότητα, μιας και ο χρήστης δε χρειάζεται να μεταγλωττίσει τον κώδικα του σε κάποιο σύστημα, αλλά αρκεί να τον εισάγει στο εργαλείο. Η ευελιξία αυτή είναι ένα σχετικά πρωτόγνωρο χαρακτηριστικό στα συστήματα της βιβλιογραφίας, πράγμα που ήταν και η κύρια μέριμνα κατά τη δημιουργία του DPDHMMY. Επιπλέον, η δομική ανάλυση προσφέρει αμεσότητα και ταχύτητα στο εργαλείο, ενώ η αποτελεσματικότητα της ανάλυσης δεν περιορίζεται στις περισσότερες περιπτώσεις, παρά μόνο σε πρότυπα που είναι αρκετά παρόμοια.

46 35 DPDHMMY Εργαλείο Ανίχνευσης Σχεδιαστικών Προτύπων Λογισμικού Ένα άλλο σημαντικό στοιχείο των συστημάτων της βιβλιογραφίας είναι η αναπαράσταση που χρησιμοποιούν. Οι απλές αναπαραστάσεις περιορίζουν τον αριθμό των προτύπων που μπορούν να ανιχνευτούν. Αντίθετα οι πολύπλοκες αναπαραστάσεις είναι αρκετά περιγραφικές, ωστόσο δεν είναι εύκολο ο χρήστης να αλλάξει τα στοιχεία τους. Η γλώσσα είναι αρκετά απλή με σαφώς ορισμένα και γνωστά είδη αντικειμένων και συνδέσεων, ενώ δίνεται η δυνατότητα στο χρήστη να εισάγει τους δικούς του κανόνες και να ορίσει έτσι δικά του σχεδιαστικά πρότυπα προς ανίχνευση. Αυτό το κύριο στοιχείο του εργαλείου προσφέρει επιπλέον ευελιξία, όπως επίσης επεκτασιμότητα και διαδραστικότητα. Ο χρήστης μπορεί ανά πάσα στιγμή να εξελίξει και να αναβαθμίσει το DPDHMMY στις δικές του ανάγκες. Το DPDHMMY ταιριάζει απόλυτα τα σχεδιαστικά πρότυπα με μέρη του κώδικα (exact matching). Αυτό επιλέχθηκε γιατί θεωρήθηκε πως αρμόζει στον τρόπο απεικόνισης των προτύπων και της διαδικασίας ανίχνευσης. Το DPDHMMY δίνει μια μικρή ευελιξία στην αυστηρότητα αυτή, προσθέτοντας τη δυνατότητα επιλογής wildcard (*) σαν σύνδεση μεταξύ στοιχείων σε ένα πρότυπο, όπου wildcard (*) θεωρείται κάθε δυνατή σύνδεση. Συνοψίζοντας, η παρούσα διπλωματική αφορά την κατασκευή ενός ευέλικτου DPD εργαλείου με χρήση δομικής ανάλυσης. Σε σχέση με τα εργαλεία της βιβλιογραφίας, το εργαλείο αυτό επιτρέπει την ανίχνευση προτύπων σε μη μεταγλωττίσιμο κώδικα. Επιπρόσθετα, η αναπαράσταση που χρησιμοποιεί είναι περιγραφική και πλήρης (αφού βασίζεται στη γλώσσα UML), ενώ ταυτόχρονα είναι αρκετά απλή ώστε να επιτρέπει ευελιξία στην ανίχνευση προτύπων.

47 36 DPDHMMY Εργαλείο Ανίχνευσης Σχεδιαστικών Προτύπων Λογισμικού 4 Προσέγγιση και Υλοποίηση 4.1 Εισαγωγή Στο παρόν κεφάλαιο αναλύονται σε βάθος οι τεχνικές και μέθοδοι που υλοποιεί το DPDHMMY όπως επίσης και η γλώσσα που δημιουργήθηκε για τις ανάγκες του. Αρχικά αναπτύσσεται ο τρόπος αναπαράστασης των αντικειμένων και των σχέσεων που ακολουθείται. Στη συνέχεια, παρουσιάζεται ο τρόπος αναπαράστασης γνωστών προτύπων σχεδίασης από το σύστημα και ακολουθεί μια ανάλυση των αλγορίθμων που αναπτύχθηκαν. 4.2 Αναπαράσταση Αντικειμένων και Σχέσεων του Κώδικα Για να γίνει εφικτή η αναζήτηση προτύπων σχεδίασης σε κώδικα, είναι αναγκαίο να μπορούν αυτά να ορισθούν με κάποιο τρόπο, ο οποίος είναι ανιχνεύσιμος μέσω των εργαλείων που προσφέρει ο μεταγλωττιστής της γλώσσας Java. Η αφορμή δόθηκε από μια διπλωματική εργασία από το πανεπιστήμιο Bonn-Rhein- Sieg Sankt Augistin της Γερμανίας [31]. Σύμφωνα με αυτή, κατά τη στατική ανάλυση κάθε κλάση μέλος ενός προτύπου σχεδίασης συνδέεται με μία ή περισσότερες κλάσεις μέλη του ιδίου. Οι συνδέσεις αυτές είναι κατευθυνόμενες, δηλαδή έχει σημασία η κατεύθυνση της σύνδεσης, και μπορούν να είναι δύο ειδών: σύνδεση uses και σύνδεση inherits. Οι συνδέσεις αυτές για δύο κλάσεις Α και Β ορίζονται ως εξής: uses(α, Β) = calls(a, B) references(a, B) creates(a, B) inherits(a, B) = extends(a, B) implements(a, B) overrides(a, B) Έτσι, η σύνδεση uses ορίζεται από την κλάση Α στην κλάση Β είτε από τη σύνδεση calls, είτε από τη σύνδεση references, είτε από τη σύνδεση creates. Calls έχουμε όταν μια μέθοδος της κλάσης A καλεί μια μέθοδο της κλάσης Β. References έχουμε όταν η κλάση Α περιέχει ένα ή περισσότερα αντικείμενα της κλάσης Β, ενώ creates όταν η κλάση Α δημιουργεί ένα αντικείμενο της κλάσης Β. Η σύνδεση inherits ορίζεται από την κλάση Α στην κλάση Β είτε από τη σύνδεση extends, είτε από τη σύνδεση implements, είτε από τη σύνδεση overrides. Extends έχουμε όταν η κλάση Α κληρονομεί την κλάση Β. Implements έχουμε όταν η κλάση Α υλοποιεί το Β που σε αυτήν την περίπτωση αποτελεί διεπαφή (interface). Τέλος, overrides έχουμε όταν μια μέθοδος της κλάσης Α παρακάμπτει μια μέθοδο της κλάσης Β.

48 37 DPDHMMY Εργαλείο Ανίχνευσης Σχεδιαστικών Προτύπων Λογισμικού Η παρούσα διπλωματική επέκτεινε την παραπάνω λογική, σχηματίζοντας επιπλέον συνδέσεις και χωρίζοντας το uses στα αρχικά του κομμάτια. Οι συνδέσεις που επιλέχθηκαν βασίζονται στις προτεινόμενες συνδέσεις της γλώσσας UML [32] [33] [34] και αναλύονται ειδικότερα στον παρακάτω πίνακα. Πίνακας 2. Επεξήγηση συνδέσεων Τύπος Σύνδεσης Περιγραφή Σχέση UML Σύμβολο UML A calls B Μια μέθοδος της κλάσης A καλεί μία μέθοδο της κλάσης B Εξάρτηση Η κλάση A δημιουργεί ένα A creates B αντικείμενο της κλάσης Β με την Σύνθεση εντολή new Μια μέθοδος της κλάσης Α A uses B επιστρέφει ένα αντικείμενο της Εξάρτηση κλάσης Β A has B Η κλάση A έχει ένα ή περισσότερα αντικείμενα τύπου κλάσης Β Συσσωμάτωση/ Πολλαπλότητα Μια μέθοδος της κλάσης Α έχει ως A references B όρισμα ένα αντικείμενο της κλάσης Σύνδεσμος Β A inherits B Η κλάση A κληρονομεί την κλάση B Κληρονομιά/ Πραγματοποίηση Στον παραπάνω πίνακα, εκτός από το διαχωρισμό των σχέσεων, προστίθεται επίσης η σχέση has, που σηματοδοτεί ότι η κλάση Α έχει ένα ή περισσότερα αντικείμενα της κλάσης Β ως μεταβλητές. Οι συνδέσεις αυτές χρησιμοποιούνται από ένα σύνολο κλάσεων που ενδέχεται να είναι μέλη ενός πρότυπου σχεδίασης, που περιέχει κάθε design pattern. Κάθε κλάση έχει μία από τις εξής ιδιότητες:

49 38 DPDHMMY Εργαλείο Ανίχνευσης Σχεδιαστικών Προτύπων Λογισμικού Normal: Αντιπροσωπεύει μια απλή κλάση. Abstract: Αντιπροσωπεύει μια αφηρημένη (abstract) κλάση. Interface: Αντιπροσωπεύει μια διεπαφή (interface). Abstracted: Αντιπροσωπεύει μια κλάση που είναι είτε interface ή abstract. Any: Αντιπροσωπεύει έναν οποιοδήποτε τύπο κλάσης από τους παραπάνω.

50 39 DPDHMMY Εργαλείο Ανίχνευσης Σχεδιαστικών Προτύπων Λογισμικού 4.3 Αναπαράσταση γνωστών προτύπων σχεδίασης Χρησιμοποιώντας την αναπαράσταση που αναλύθηκε στο προηγούμενο υποκεφάλαιο, είναι δυνατός ο ορισμός ενός μεγάλου πλήθους προτύπων σχεδίασης. Συγκεκριμένα, δίνεται η δυνατότητα ορισμού ακόμα και μη γνωστών, δηλαδή custom, προτύπων από το χρήστη. Στις ακόλουθες παραγράφους περιγράφουμε τον ορισμό κάποιων γνωστών προτύπων σχεδίασης των GoF [6] με βάση την αναπαράσταση που ορίστηκε. Οφείλεται να αναφερθεί, πως σκοπός της παρούσας διπλωματικής δεν είναι να ορίσει επακριβώς τα pattern αυτά, αλλά να παρουσιάσει ένα παράδειγμα του τρόπου που προτείνει για την απεικόνισή τους Abstract Factory (Δημιουργικό πρότυπο) Σκοπός: Να δοθεί μια διεπαφή για την δημιουργία οικογενειών συναφών ή εξαρτώμενων αντικειμένων χωρίς να προσδιορίζονται οι κλάσεις τους αυτές καθ αυτές. Πίνακας 3. Μέλη του Abstract Factory Member Abstraction Ability A Normal Concrete Factory B Abstracted Abstract Factory C Normal Product D Abstracted Abstract Product Πίνακας 4. Συνδέσεις του Abstract Factory From Connection Type To A inherits B C inherits D A creates C A uses D

51 40 DPDHMMY Εργαλείο Ανίχνευσης Σχεδιαστικών Προτύπων Λογισμικού Command (Πρότυπο συμπεριφοράς) Σκοπός: Να ορισθεί μια εξάρτηση ένα-προς-πολλά μεταξύ αντικειμένων, έτσι ώστε όταν η κατάσταση ενός αντικειμένου αλλάξει, όλα τα εξαρτώμενα αντικείμενα από αυτό να ενημερωθούν και αναβαθμιστούν αυτόματα. Πίνακας 5. Μέλη του Command Member Abstraction Ability A Normal Concrete Command B Abstracted Command C Normal Receiver D Normal Invoker Πίνακας 6. Συνδέσεις του Command From Connection Type To A inherits B A has C A calls C D has B D calls B

52 41 DPDHMMY Εργαλείο Ανίχνευσης Σχεδιαστικών Προτύπων Λογισμικού Bridge (Δομικό πρότυπο) Σκοπός: Να αποσυνδέσει μια αφαιρετικότητα από την εφαρμογή της, έτσι ώστε και οι δύο να μπορούν να μεταβάλλονται ανεξάρτητα. Πίνακας 7. Μέλη του Bridge Member Abstraction Ability A Normal Refined Abstraction B Abstract Abstraction C Normal Concrete Implementor D Interface Implementor Πίνακας 8. Συνδέσεις του Bridge From Connection Type To A inherits B C inherits D B has D

53 42 DPDHMMY Εργαλείο Ανίχνευσης Σχεδιαστικών Προτύπων Λογισμικού Builder (Δημιουργικό πρότυπο) Σκοπός: Να διαχωριστεί η κατασκευή ενός σύνθετου αντικειμένου από την απεικόνισή του, έτσι ώστε η ίδια διαδικασία κατασκευής να μπορεί να δημιουργήσει διαφορετικές απεικονίσεις. Πίνακας 9. Μέλη του Builder Member Abstraction Ability A Normal Director B Abstracted Builder C Normal Concrete Builder D Normal Product Πίνακας 10. Συνδέσεις του Builder From Connection Type To A has B A calls B C inherits B C creates D

54 43 DPDHMMY Εργαλείο Ανίχνευσης Σχεδιαστικών Προτύπων Λογισμικού Visitor (Πρότυπο συμπεριφοράς) Σκοπός: Να αντιπροσωπεύσει μια λειτουργία που πρόκειται να εκτελεστεί στα στοιχεία μιας δομής ενός αντικειμένου. Επιπλέον, να ορίσει μια νέα λειτουργία, χωρίς να αλλάζει τις κλάσεις των στοιχείων επί των οποίων λειτουργεί. Πίνακας 11. Μέλη του Visitor Member Abstraction Ability A Normal Concrete Element B Abstracted Element C Normal Concrete Visitor D Abstracted Visitor Πίνακας 12. Συνδέσεις του Visitor From Connection Type To A inherits B C inherits D B references D D references A

55 44 DPDHMMY Εργαλείο Ανίχνευσης Σχεδιαστικών Προτύπων Λογισμικού Observer (Πρότυπο συμπεριφοράς) Σκοπός: Να ορίσει μια εξάρτηση ένα-προς-πολλά μεταξύ αντικειμένων, έτσι ώστε όταν ένα αντικείμενο αλλάζει κατάσταση, όλα τα εξαρτώμενα σε αυτό αντικείμενα να ενημερώνονται και να αναβαθμίζονται αυτόματα a Μορφή 1 η Με Subject Πίνακας 13. Μέλη του Observer- Μορφή 1 η Member Abstraction Ability A Normal Concrete Observer B Normal Concrete Subject C Abstracted Observer D Abstracted Subject Πίνακας 14. Συνδέσεις του Observer - Μορφή 1 η From Connection Type To A inherits C B inherits D A calls D D references C

56 45 DPDHMMY Εργαλείο Ανίχνευσης Σχεδιαστικών Προτύπων Λογισμικού b Μορφή 2 η Χωρίς Subject Πίνακας 15. Μέλη του Observer - Μορφή 2 η Member Abstraction Ability A Normal Concrete Observer B Normal Concrete Subject C Abstracted Observer Πίνακας 16. Συνδέσεις του Observer - Μορφή 2 From Connection Type To A inherits C A calls Β Β references C Factory Method (Δημιουργικό πρότυπο) Σκοπός: Να ορισθεί μια διεπαφή για τη δημιουργία ενός αντικειμένου, αφήνοντας όμως τις υποκλάσεις να αποφασίσουν ποια κλάση να υλοποιήσουν. Η Factory Method αφήνει μια κλάση να υποβάλει την υλοποίηση στις υποκλάσεις a Μορφή 1 η Με Creator Πίνακας 17. Μέλη του Factory Method- Μορφή 1 η Member Abstraction Ability A Normal Concrete Product B Abstracted Product C Normal Concrete Creator D Abstracted Creator

57 46 DPDHMMY Εργαλείο Ανίχνευσης Σχεδιαστικών Προτύπων Λογισμικού Πίνακας 18. Συνδέσεις του Factory Method - Μορφή 1 η From Connection Type To A inherits B C inherits D C creates A C uses B b Μορφή 2 η Χωρίς Creator Πίνακας 19. Μέλη του Factory Method - Μορφή 2 η Member Abstraction Ability A Normal Concrete Product B Abstracted Product C Normal Concrete Creator Πίνακας 20. Συνδέσεις του Factory Method - Μορφή 2 η From Connection Type To A inherits B C creates A C uses B

58 47 DPDHMMY Εργαλείο Ανίχνευσης Σχεδιαστικών Προτύπων Λογισμικού 4.4 Parser Στο υποκεφάλαιο αυτό, αναλύεται αρχικά το parsing, η διαδικασία, δηλαδή, εξαγωγής της αναπαράστασης, που ορίστηκε στο προηγούμενο κεφάλαιο, από το εργαλείο. Στη συνέχεια παρουσιάζεται ο αλγόριθμος ανίχνευσης προτύπων σχεδίασης Java Compiler Tree API Για τη διαδικασία του parsing, χρησιμοποιήθηκε το Tree API του Compiler της Java [35]. Συγκεκριμένα, χρησιμοποιήθηκε η κλάση Treescanner, που υλοποιεί το interface TreeVisitor και σαρώνει όλα τα παιδιά ενός δέντρου, το οποίο περιέχει όλες τις οντότητες ενός αρχείου.java. Έτσι, για να εκμεταλλευτεί κάποιος τη συγκεκριμένη κλάση, αρκεί να κάνει override την αντίστοιχη visitxyz συνάρτηση, όπου Xyz είναι η οντότητα προς επεξεργασία. Για παράδειγμα, αν χρειάζεται να εκτελεσθεί μία συνάρτηση κάθε φορά που σαρώνεται μία κλάση, τότε γίνεται override η συνάρτηση visitclass(classtree node, Void p) και μέσα σε αυτή καλείται η επιθυμητή συνάρτηση. Οι βασικές οντότητες που χρησιμοποιήθηκαν και οι λόγοι για τους οποίους επιλέχθηκαν αναφέρονται στη συνέχεια: visitcompilationunit: Καλείται κάθε φορά που διαβάζεται ένα καινούριο αρχείο. Χρησιμοποιείται σαν εναρκτήριος κόμβος του δέντρου. visitclass: Σε κάθε επίσκεψη μιας κλάσης, ο parser δημιουργεί ένα καινούριο αντικείμενο ClassObject ή συμπληρώνει ένα ήδη υπάρχον. visitvariable: Καλείται σε κάθε επίσκεψη μεταβλητής, την οποία και καταχωρεί στο αντίστοιχο ClassObject. visitnewclass: Κάθε φορά που δημιουργείται ένα αντικείμενο μέσω της new, καλείται αυτή η συνάρτηση και καταχωρείται το new αυτό στο αντίστοιχο ClassObject για μετέπειτα χρήση. visitmethodinvocation: Με το που συναντιέται μια νέα κλήση συνάρτησης, αυτή καταχωρείται στο αντίστοιχο ClassObject Δομικά Μέρη του Parser και Ανίχνευση Συνδέσεων Σε αυτό το σημείο αξίζει να αναλυθούν μερικά βασικά δομικά στοιχεία του parser, όπως και οι αλγόριθμοι ανίχνευσης των έξι συνδέσεων που αναφέρθηκαν στο υποκεφάλαιο 3.2.

59 48 DPDHMMY Εργαλείο Ανίχνευσης Σχεδιαστικών Προτύπων Λογισμικού Βασικό δομικό μέλος του parser (και κατ επέκταση όλου του DPDHMMY) είναι η κλάση ClassObject (ΑντικείμενοΚλάση). Κάθε αντικείμενο ClassObject αντιπροσωπεύει μια κλάση που ανιχνεύθηκε από τον parser, είτε αυτή αντιμετωπίστηκε κανονικά ή σαν απλή αναφορά. Κάθε ClassObject, περιλαμβάνει ιδιότητες όπως όνομα, ιδιότητα, αφαιρετικότητα (abstraction) και περιέχει, επίσης, μεθόδους, μεταβλητές, συνδέσεις και μερικά ακόμη στοιχεία που περιγράφουν την κλάση την οποία αναπαριστά. Αφού κατασκευαστεί ένα αντικείμενο, τοποθετείται στη λίστα ClassObjects που περιέχει όλα τα ανιχνευμένα ClassObject και χρησιμοποιείται στη συνέχεια. Ένα ακόμη βασικό κομμάτι του parser, είναι η κλάση Connection (Σύνδεση). Τα αντικείμενα αυτής περιγράφουν τη σύνδεση μεταξύ δύο ClassObjects. Έτσι, ένα αντικείμενο Connection περιλαμβάνει τον τύπο της σύνδεσης (calls, references, creates, uses, inherits, has) και δύο ClassObject, ένα για το πρώτο μέρος της σύνδεσης (From) και ένα για το δεύτερο (To). Αξίζει να σημειωθεί πως οι συνδέσεις αυτές είναι μονοσήμαντες, δηλαδή ένα ClassObject A δεν μπορεί να συνδέεται παραπάνω από μία φορά με την ίδια σύνδεση με ένα ClassObject B. Για την εύρεση των συνδέσεων που αναφέρθηκαν παραπάνω, χρησιμοποιούνται οι συναρτήσεις findxyz, με Xyz τις αντίστοιχες συνδέσεις uses, inherits κλπ. Οι αλγόριθμοι των συναρτήσεων αυτών αναλύονται στη συνέχεια: finduses: Η συνάρτηση αυτή ανιχνεύει τις συνδέσεις τύπου uses που ανήκουν στο ClassObject που την καλεί. Αυτό που κάνει είναι να ψάχνει τι επιστρέφει η κάθε μέθοδος του και αν ο τύπος της επιστροφής είναι ένα πιθανό άλλο ClassObject, καταχωρεί τη σύνδεση uses. findinherits: Η συνάρτηση αυτή ανιχνεύει τις συνδέσεις τύπου inherits που ανήκουν στο ClassObject που την καλεί. Καταχωρεί σαν συνδέσεις inherits τα διάφορα extends και implements του εκάστοτε ClassObject. findhas: Η συνάρτηση αυτή ανιχνεύει τις συνδέσεις τύπου has που ανήκουν στο ClassObject που την καλεί. Ελέγχει μία-μία όλες τις μεταβλητές του ClassObject και καταχωρεί σαν has αυτές που δεν αποτελούν πρωταρχικούς τύπους δεδομένων (primitive data types) προσέχοντας τις διπλοεγγραφές. Δηλαδή στοχεύει στις μεταβλητές που αποτελούν αντικείμενα πιθανών κλάσεων.

60 49 DPDHMMY Εργαλείο Ανίχνευσης Σχεδιαστικών Προτύπων Λογισμικού findcalls: Η συνάρτηση αυτή ανιχνεύει τις συνδέσεις τύπου calls που ανήκουν στο ClassObject που την καλεί. Ελέγχει τις κλήσεις συναρτήσεων (method invocation) του ClassObject με τον ακόλουθο τρόπο. Σπάει τη κλήση μεθόδου σε μέρη και ψάχνει για μεταβλητές του ClassObject σε αυτά. Μόλις βρει μία, προσπαθεί να αντιστοιχίσει το αμέσως επόμενο κομμάτι με μία από τις συναρτήσεις από όλα τα ClassObject που έχουν βρεθεί. Αν τα καταφέρει, καταχωρεί τη σύνδεση μεταξύ του αρχικού ClassObject και αυτού στο οποίο ανήκει η συνάρτηση. Ένα πιθανό πρόβλημα με τον αλγόριθμο αυτόν, είναι η περίπτωση στην οποία μία συνάρτηση επιστρέφει ένα αντικείμενο το οποίο καλεί μια άλλη συνάρτηση, πράγμα που δε μπορεί να ανιχνεύσει. Παρ όλα αυτά θεωρείται εξεζητημένη και σπάνια περίπτωση, οπότε και αγνοείται. findcreates: Η συνάρτηση αυτή ανιχνεύει τις συνδέσεις τύπου creates που ανήκουν στο ClassObject που την καλεί. Αυτό που κάνει είναι να ελέγχει τα new που ανιχνεύτηκαν στο εκάστοτε ClassObject και να ξεχωρίζει αυτά που παράγουν αντικείμενα καινούριων κλάσεων. findreferences: Η συνάρτηση αυτή ανιχνεύει τις συνδέσεις τύπου references που ανήκουν στο ClassObject που την καλεί. Ελέγχει τους τύπους των εισόδων για κάθε μέθοδο του ClassObject και ξεχωρίζει αυτές που οι τύποι τους δεν αποτελούν μέρος των πρωταρχικών τύπων δεδομένων (primitive data types). Δηλαδή στοχεύει στις εισόδους των μεθόδων που αποτελούν αντικείμενα κλάσεων. 4.5 Αλγόριθμος Ανίχνευσης Προτύπων Σχεδίασης Στο υποκεφάλαιο αυτό, θα αναλυθεί ο βασικός αλγόριθμος εύρεσης προτύπων σχεδίασης και η βελτιστοποιημένη, ως προς την ταχύτητα, εκδοχή του, αφού πρώτα περιγραφούν τα βασικά δομικά στοιχεία του κώδικα Δομικά μέρη του ανιχνευτή προτύπων σχεδίασης Όπως και στο κομμάτι του parser, η υλοποίηση στηρίζεται σε μερικά καίρια σημεία. Αυτά είναι η κλάση Pattern που αντιπροσωπεύει τη δομή ενός design pattern, η κλάση PatternCandidate που χρησιμοποιείται ως μια μορφή αποθήκευσης πιθανών προτύπων σχεδίασης και η PatternDetectionAlgorithm η οποία αποτελεί το βασικό μέρος του αλγορίθμου.

61 50 DPDHMMY Εργαλείο Ανίχνευσης Σχεδιαστικών Προτύπων Λογισμικού Η κλάση Pattern, όπως αναφέρθηκε, αποτελεί τον τρόπο προσέγγισης του DPDHMMY απέναντι στα πρότυπα σχεδίασης. Κάθε αντικείμενο αυτής της κλάσης αντιπροσωπεύει ένα διαφορετικό πρότυπο σχεδίασης και περιέχει ένα σύνολο από αντικείμενα ClassObject (τα μέλη του), ένα σύνολο από αντικείμενα Connection (τις συνδέσεις του) και ένα όνομα. Η κλάση PatternCandidate αντιπροσωπεύει ένα υποψήφιο πρότυπο σχεδίασης που βρέθηκε στον κώδικα και τις αντιστοιχίες του ως προς τα μέλη του αρχικού προτύπου σχεδίασης προς ανίχνευση. Περιέχει το όνομα του προτύπου σχεδίασης, μια λίστα με τα ClassObject μέλη σε σειρά, μια λίστα με τα ονόματα σε σειρά (A, B κλπ) και μια λίστα με τις ιδιότητες των μελών σε σειρά (ConcreteCommand, Command κλπ). Η κλάση PatternDetectionAlgorithm περιέχει δύο αλγορίθμους, τον αλγόριθμο PatternDetection και τον αλγόριθμο FastPatternDetection. Αυτοί οι αλγόριθμοι αντιστοιχούν στις συναρτήσεις detectpattern(pattern p) και detectpatternfast(pattern p) και αναλύονται στα επόμενα υποκεφάλαια Αλγόριθμος PatternDetection Ο βασικός αλγόριθμος στη πρώτη, μη βελτιστοποιημένη, μορφή του, χρησιμοποιεί την έννοια της «ωμής δύναμης» (brute force). Σύμφωνα με την έννοια αυτή, ελέγχει όλους τους δυνατούς συνδυασμούς των ClassObject που έχουν ανιχνευτεί, για να εντοπίσει κάποιους από αυτούς που συμφωνούν με τους κανόνες που ορίζει το πρότυπο σχεδίασης. Στη συνέχεια παρουσιάζεται και αναλύεται ο αλγόριθμος σε ψευδοκώδικα.

62 51 DPDHMMY Εργαλείο Ανίχνευσης Σχεδιαστικών Προτύπων Λογισμικού Κλάση Pattern{ } Λίστα Members Λίστα Connections Κλάση Connection{ } Member from Member to Type type Hashmap Classes : Περιέχει όλα τα ClassObject Συνάρτηση DetectPattern(Pattern p){ n = p.members.size() Για κάθε συνδυασμό n στοιχείων του πίνακα Classes{ 1. Έλεγξε αν ταιριάζει το abstraction των member του συνδυασμού με τα member του pattern 2. Καθάρισε το Hashmap Classes, γέμισε το με [String, ClassObject] ώστε να υπάρχει σύνδεση των μελών του Pattern και των εξεταζόμενων ClassObject 3. Για κάθε Connection του Pattern{ switch (type): case: has IF Classes.getitem(connection.from).has( Classes.getitem(connection.to)) THEN Συνέχισε για το επόμενο connection ELSE Αυτός ο συνδυασμός αποτυγχάνει, συνέχισε στον επόμενο συνδυασμό case: use κλπ. } 4. Βρέθηκε Candidate, αποθήκευσε το και συνέχισε Σημείωση: Η σειρά των συνδυασμών έχει σημασία

63 52 DPDHMMY Εργαλείο Ανίχνευσης Σχεδιαστικών Προτύπων Λογισμικού Φαίνεται λοιπόν, πως στην απλή του μορφή ο αλγόριθμος χρησιμοποιεί τις κλάσεις Connection και Pattern. Η πρώτη περιέχει τα μέλη και τον τύπο της σύνδεσης, ενώ η δεύτερη μια λίστα με τα μέλη και μια λίστα με τις συνδέσεις τους. Μέσα στη κυρίως συνάρτηση, επαναλαμβάνεται η ίδια διαδικασία για κάθε πιθανό συνδυασμό μεταξύ n αντικειμένων ClassObject, όπου n ο αριθμός των μελών του pattern. Εδώ αξίζει να σημειωθεί, πως έχει ιδιαίτερη σημασία η σειρά των αντικειμένων ClassObject στους συνδυασμούς, καθώς για μεγάλο αριθμό αντικειμένων ClassObject ο αριθμός των πιθανών συνδυασμών ανεβαίνει τουλάχιστον εκθετικά. Έτσι λοιπόν, κάθε συνδυασμός εξετάζεται αν είναι δυνατόν να ταιριάζει στο πρότυπο του pattern. Ένα απλό παράδειγμα παρατίθεται στην επόμενη εικόνα. Εικόνα 19. Παράδειγμα δυνατών συνδυασμών προς έλεγχο

64 53 DPDHMMY Εργαλείο Ανίχνευσης Σχεδιαστικών Προτύπων Λογισμικού Εδώ έχουμε τρία μέλη στο pattern μας και τέσσερα ClassObject. Άρα, οι δυνατοί συνδυασμοί προς έλεγχο είναι 24, όπως φαίνεται. Για κάθε έναν από αυτούς, αρχικά ελέγχεται το abstraction τους αν συμφωνεί με το abstraction των αντίστοιχων μελών του pattern. Αν ναι, τοποθετούνται σε ένα Hashmap<String, ClassObject> όπου ClassObject είναι το αντικείμενο που ελέγχεται και String το όνομα του αντίστοιχου αντικειμένου του pattern στο οποίο ταιριάζεται (A ή B ή C κλπ). Συνεχίζοντας, εξετάζεται κάθε Connection του pattern, που ανάλογα με τον τύπο του, ελέγχεται αν το ClassObject που αντιστοιχεί στο όνομα του μέλους του pattern έχει την ίδια σύνδεση με το αντίστοιχο ClassObject που αντιστοιχίζεται στο άλλο μέλος του pattern Αν όλα τα Connection ταιριάζουν, ο συνδυασμός αυτών των ClassObject αποθηκεύεται ως pattern candidate και συνεχίζεται ο έλεγχος για περαιτέρω candidates.. Η εικόνα που ακολουθεί εξηγεί καλύτερα την παραπάνω διαδικασία με ένα παράδειγμα. Εικόνα 20. Παράδειγμα ανίχνευσης design pattern Ο αλγόριθμος που αναφέρεται παραπάνω, είναι απλός και γρήγορος για μικρά αρχεία, αλλά όταν ο όγκος των δεδομένων μεγαλώνει, καθίσταται απαγορευτικός.

65 54 DPDHMMY Εργαλείο Ανίχνευσης Σχεδιαστικών Προτύπων Λογισμικού Αλγόριθμος FastPatternDetection Όπως αναφέρθηκε στο προηγούμενο υποκεφάλαιο, ο βασικός αλγόριθμος καθίσταται απαγορευτικός για μεγάλο όγκο δεδομένων. Έτσι, δημιουργήθηκε η ανάγκη για έναν πιο «έξυπνο» και γρήγορο αλγόριθμο, ικανό να αντιμετωπίσει τέτοιου είδους εισόδους. Το αποτέλεσμα ήταν ο αλγόριθμος FastPatternDetection. Η βασική ιδέα πίσω από τη βελτιστοποίηση του προηγούμενου αλγορίθμου, είναι η μείωση συνδυασμών προς έλεγχο. Για το σκοπό αυτό, εισάγεται ένα-ένα κάθε μέλος στον πιθανό συνδυασμό. Πριν την εισαγωγή του μέλους αυτού, ελέγχεται αν εξυπηρετεί το αντίστοιχο abstraction και αν το μέλος αυτό έχει τις απαραίτητες συνδέσεις με τα προηγούμενα μέλη που έχουν ήδη εισαχθεί. Έτσι, υποθέτοντας πως όλοι οι δυνατοί συνδυασμοί αποτελούν τα άκρα ενός μεγάλου δέντρου, αυτό που γίνεται είναι να «κόβουμε» αυτά τα υποδέντρα πιο κοντά στη ρίζα. Τα πιθανά αποτελέσματα φαίνονται στο παράδειγμα στην εικόνα που ακολουθεί. Εικόνα 21.Δέντρο πιθανών συνδυασμών προς έλεγχο Και στη συνέχεια, παρουσιάζεται ο νέος, βελτιωμένος αλγόριθμος.

66 55 DPDHMMY Εργαλείο Ανίχνευσης Σχεδιαστικών Προτύπων Λογισμικού Συνάρτηση DetectPattern(Pattern p){ } Για κάθε ClassObject του πίνακα Classes{ 1. Έλεγξε αν ταιριάζει το abstraction του με αυτό του πρώτου member του pattern 2. Δημιούργησε ένα καινούριο πίνακα (ClassObjects) με ClassObject όπου θα περάσεις όλα τα ClassObject του Classes εκτός από αυτό που επιλέχθηκε. 3. Κάλεσε την αναδρομική συνάρτηση Recursive(ClassObjects, Candidate, 1) όπου ClassObjects ο πίνακας με τα εναπομείναντα ClassObject, Candidate το ClassObject που μόλις ελέγξαμε και 1 το βάθος αναδρομής{ Συνάρτηση Recursive(ClassObjects, Candidate, depth){ } IF depth < pattern.member_number THEN { } Για κάθε ClassObject στο ClassObjects{ IF AbstractionCheck && ConnectionCheck THEN Recursive(ClassObjectsnew, Candidatenew, depth+1) } ELSE{ } Επανέλεγξε όλα τα Connections και αν είναι σωστά πρόσθεσε τα μέλη που επιλέχθηκαν σαν νέα PatternCandidate Σημειώσεις: AbstractionCheck Τσεκάρει αν το abstraction του ClassObject αντιστοιχεί στο abstraction του αντίστοιχου μέλους του pattern. ConnectionCheck- Τσεκάρει αν τα Connection του ClassObject με τα υπόλοιπα ClassObject που επιλέχθηκαν πριν από αυτό, συμφωνούν με τα Connection του αντίστοιχου μέλους του pattern.

67 56 DPDHMMY Εργαλείο Ανίχνευσης Σχεδιαστικών Προτύπων Λογισμικού Τα αποτελέσματα στη βελτίωση χρόνου είναι αρκετά εντυπωσιακά. Τα πειράματα πραγματοποιήθηκαν σε δύο συστήματα. Το Σύστημα 1 είναι ένας φορητός υπολογιστής Acer Aspire 5930G, με λειτουργικό Windows 8.1, επεξεργαστή Intel Core 2 Ghz και 3GB RAM. Το Σύστημα 2 είναι ένας σταθερός υπολογιστής με λειτουργικό σύστημα Windows 8.1, επεξεργαστή Intel Core Ghz με δύο πυρήνες και 4GB RAM. Τα σετ δεδομένων που χρησιμοποιήθηκαν ήταν: Ένα παράδειγμα του design pattern Abstract Factory. Περιέχει 10 κλάσεις. Μια συλλογή από παραδείγματα έξι design pattern (Abstract Factory, Factory Method, Command, Visitor, Bridge και Visitor). Περιέχει 39 κλάσεις. Η έκδοση 6.0b1 της βιβλιοθήκης JHotDraw. Περιέχει 600 κλάσεις. Όπως φαίνεται και από τον πίνακα που ακολουθεί, το μεγαλύτερο ποσοστό βελτίωσης παρατηρείται για μεγαλύτερο όγκο δεδομένων εισόδου. Πίνακας 21. Χρόνοι περάτωσης των δύο αλγορίθμων στο Σύστημα 1. Abstract Factory Example PatternDetection 93ms FastPatternDetection 16ms Pattern Compilation 2563ms 31ms JHotDraw * 594ms Πίνακας 22. Χρόνοι περάτωσης των δύο αλγορίθμων στο Σύστημα 2. Abstract Factory Example PatternDetection 27ms FastPatternDetection 2ms Pattern Compilation 1400ms 7ms JHotDraw * 210ms *: Αδυναμία ολοκλήρωσης για τουλάχιστον 2 ώρες.

68 57 DPDHMMY Εργαλείο Ανίχνευσης Σχεδιαστικών Προτύπων Λογισμικού Ομαδοποίηση αποτελεσμάτων Πολλές φορές σε ένα έργο λογισμικού, στιγμιότυπα αρχιτεκτονικών λογισμικού συνδέονται μεταξύ τους δημιουργώντας μια μεγαλύτερη δομή. Στην περίπτωση αυτή, είναι ιδιαίτερα σημαντικό από το εργαλείο ανίχνευσης να ομαδοποιεί τα μικρότερα αυτά στιγμιότυπα, έτσι ώστε να υπάρχει μια πιο αντιπροσωπευτική εικόνα των σχεδιαστικών προτύπων στην ολομέλεια του κώδικα. Στο κομμάτι αυτό, το DPDHMMY χρησιμοποιεί μια καινούρια δομή για την μεταεπεξεργασία (post-processing) των αποτελεσμάτων. Η διαδικασία που ακολουθεί είναι να ενώνει τα PatternCandidate που έχει ήδη βρει και έχουν ένα μόνο διαφορετικό Ability. Έτσι, αν δύο ή περισσότερα PatternCandidate έχουν όλα τα Ability τους ίδια εκτός από ένα συγκεκριμένο, δημιουργούν ένα SuperCandidate. Με τη σειρά τους, δύο SuperCandidate ή PatternCandidate μπορούν να ενωθούν σε ένα HyperCandidate που περιέχει δύο διαφορετικά Abilities. Στο σημείο αυτό πρέπει να σημειωθεί, πως η διαδικασία αυτή συνένωσης θα μπορούσε να συνεχιστεί, αλλά θεωρήθηκε ιδανικό το να σταματήσει στα δύο διαφορετικά Ability. Παρακάτω φαίνεται ένα κλασικό παράδειγμα του σχεδιαστικού πρότυπου Abstract Factory με τα PatternCandidate, τις αντίστοιχες κλάσεις και τα Ability. Πίνακας 23. Τα PatternCandidates του παραδείγματος προς ομαδοποίηση Candidates Concrete Factory Reptile Factory Reptile Factory Mammal Factory Mammal Factory Abstract Factory Species Factory Species Factory Species Factory Species Factory Product Snake Tyrannosaurus Cat Dog Abstract Product Animal Animal Animal Animal Εδώ βλέπουμε πως τα τέσσερα PatternCandidate έχουν τις ίδιες κλάσεις σαν Abilities ανά δύο, εκτός της Ability Product. Οι ομοιότητες είναι επισκιασμένες με πράσινο, ενώ οι διαφορές με κόκκινο. Στη συνέχεια βλέπουμε το αποτέλεσμα της πρώτης ομαδοποίησης σε επίπεδο SuperCandidate.

69 58 DPDHMMY Εργαλείο Ανίχνευσης Σχεδιαστικών Προτύπων Λογισμικού Πίνακας 24. Τα SuperCandidates του παραδείγματος προς ομαδοποίηση. SuperCandidates Concrete Factory Reptile Factory Mammal Factory Abstract Factory Species Factory Species Factory Product (Snake, Tyrannosaurus) (Cat, Dog) Abstract Product Animal Animal Συνεχίζοντας την ομαδοποίηση, τώρα ψάχνουμε για δύο ανόμοια Ability. Και πάλι με κόκκινο φαίνονται τα διαφορετικά και με πράσινο τα όμοια. Μετά την τελική ομαδοποίηση, δημιουργείται το τελικό HyperCandidate με τη μορφή που ακολουθεί. Πίνακας 25. Το τελικό HyperCandidate του παραδείγματος προς ομαδοποίηση HyperCandidates Concrete Factory Abstract Factory Product Abstract Product [Reptile Factory, Mammal Factory] Species Factory [(Snake, Tyrannosaurus), (Cat, Dog)] Animal Στις εικόνες που ακολουθούν μπορεί κανείς να δει γραφικά και να καταλάβει περαιτέρω τη διαδικασία της ομαδοποίησης του DPDHMMY. Εικόνα 22. Οπτική αναπαράσταση του σχεδιαστικού προτύπου του παραδείγματος προς ομαδοποίηση

70 59 DPDHMMY Εργαλείο Ανίχνευσης Σχεδιαστικών Προτύπων Λογισμικού Εικόνα 23. Οπτική αναπαράσταση των PatternCandidates του παραδείγματος προς ομαδοποίηση Εικόνα 24. Οπτική αναπαράσταση των SuperCandidates του παραδείγματος προς ομαδοποίηση

71 60 DPDHMMY Εργαλείο Ανίχνευσης Σχεδιαστικών Προτύπων Λογισμικού Εικόνα 25. Οπτική αναπαράσταση του HyperCandidate του παραδείγματος προς ομαδοποίηση

72 61 DPDHMMY Εργαλείο Ανίχνευσης Σχεδιαστικών Προτύπων Λογισμικού 5 Γραφικό Περιβάλλον Διεπαφής του DPDHMMY 5.1 Εισαγωγή Στο παρόν κεφάλαιο θα παρουσιαστεί το γραφικό περιβάλλον του DPDHMMY, δίνοντας έμφαση στην απλή λειτουργικότητά του και τη φιλικότητά του για έναν χρήστη που δεν ξέρει εκ των προτέρων τον τρόπο λειτουργίας του εργαλείου. Θα χωρίσουμε το κεφάλαιο αυτό σε τρία βασικά μέρη, το βασικό παράθυρο, το κομμάτι του Pattern Creator (Δημιουργός αρχιτεκτονικής κώδικα) και του Detect Pattern (Ανιχνευτής αρχιτεκτονικής κώδικα). Το DPDHMMY δέχεται σαν είσοδο projects με αρχεία.java για την ανίχνευση, ενώ επίσης δέχεται τα δικά του αρχεία.pattern για τον ορισμό των σχεδιαστικών προτύπων προς ανίχνευση, με επίσης τη δυνατότητα δημιουργίας των τελευταίων μέσα από το εργαλείο. Σαν έξοδο προσφέρει αρχεία.txt με τα τελικά αποτελέσματα. 5.2 Βασικό Παράθυρο Το πρώτο πράγμα που αντικρίζει ο χρήστης μόλις ανοίγει την εφαρμογή είναι το βασικό παράθυρο που φαίνεται παρακάτω. Εικόνα 26. Βασικό παράθυρο gui Εδώ υπάρχουν τα εξής στοιχεία Τρία κουμπιά με πεδία κειμένου για επιλογή τοποθεσίας φακέλων Το κουμπί Detect Pattern

73 62 DPDHMMY Εργαλείο Ανίχνευσης Σχεδιαστικών Προτύπων Λογισμικού Το κουμπί Create Custom Pattern Ένα Drop Down Menu, Choose a Pattern File System Browsers (Buttons/TextFields): Τα τρία αυτά κουμπιά με πεδία κειμένου χρησιμοποιούνται από το χρήστη για να ορίσει την τοποθεσία των φακέλων των pattern, του project και των αποτελεσμάτων. Επιλέγοντας ένα φάκελο pattern, το DPDHMMY ανιχνεύει αρχεία.pattern σε αυτό το φάκελο και τα εισάγει στο Choose a Pattern dropdown menu, ενώ αν δεν υπάρχουν τέτοια αρχεία στο φάκελο αυτό, εμφανίζεται ένα μήνυμα που ενημερώνει το χρήστη. Με την επιλογή του φακέλου του project, ο χρήστης δίνει στο DPDHMMY τη βασική του είσοδο, δηλαδή τα αρχεία κώδικα.java που πρέπει να ανιχνεύσει. Τέλος, με το φάκελο αποτελεσμάτων καθορίζεται η τοποθεσία, όπου θα δημιουργηθούν τα αρχεία που θα περιέχουν τα τελικά αποτελέσματα του DPDHMMY. Ο χρήστης μπορεί να επιλέξει τις τοποθεσίες των παραπάνω φακέλων είτε μέσω των αντίστοιχων κουμπιών, που τον μεταβιβάζουν σε ένα παράθυρο πλοήγησης στο σύστημα αρχείων, είτε γράφοντας τη διεύθυνση του φακέλου στο αντίστοιχο textfield. Detect Pattern (Button): Το συγκεκριμένο κουμπί ξεκινάει τη διαδικασία της ανίχνευσης προτύπων. Για να αρχίσει όμως η συγκεκριμένη διαδικασία πρέπει πρώτα να ολοκληρωθούν τα προαπαιτούμενα βήματα, να οριστούν δηλαδή οι φάκελοι και το πρότυπο σχεδίασης που αναζητείται όπως θα εξηγηθεί παρακάτω. Αν ο χρήστης επιδιώξει να πατήσει το συγκεκριμένο κουμπί πριν ολοκληρωθούν τα βήματα αυτά, εμφανίζεται αντίστοιχο μήνυμα που τον καθοδηγεί στην πλήρωση των βημάτων που υπολείπονται. Οι λειτουργίες του κουμπιού αυτού θα αναλυθούν περαιτέρω σε παρακάτω υποκεφάλαιο. Create Custom Pattern (Button): Το κουμπί αυτό εμφανίζει ένα νέο παράθυρο που οδηγεί τον χρήστη στο να δημιουργήσει το δικό του πρότυπο σχεδίασης. Προαπαίτηση είναι να έχει καθορίσει τη τοποθεσία του φακέλου των αρχείων.pattern, μιας και εκεί θα αποθηκευτεί το πρότυπο σχεδίασης που θα δημιουργήσει. Σε περίπτωση που προσπαθήσει ο χρήστης να δημιουργήσει ένα πρότυπο σχεδίασης χωρίς να έχει ορίσει τοποθεσία φακέλου αρχείων.pattern, εμφανίζεται ένα κατάλληλο μήνυμα που τον προτρέπει να το κάνει πριν συνεχίσει. Η λειτουργία του Pattern Creator θα αναλυθεί σε παρακάτω υποκεφάλαιο.

74 63 DPDHMMY Εργαλείο Ανίχνευσης Σχεδιαστικών Προτύπων Λογισμικού 5.3 Pattern Creator Όπως προαναφέρθηκε, πατώντας το κουμπί Create Custom Pattern, ο χρήστης μεταφέρεται σε μια σειρά παραθύρων, που υλοποιούν τα βήματα σχεδίασης ενός ειδικά κατασκευασμένου pattern. Το πρώτο παράθυρο που εμφανίζεται φαίνεται στην Εικόνα 27. Εικόνα 27. Πρώτο παράθυρο του Pattern Creator Σε αυτό το παράθυρο, ο χρήστης ενημερώνει το DPDHMMY για το όνομα του καινούριου προτύπου, όπως επίσης και για τον αριθμό των μελών και των συνδέσεων μέσα σε αυτό. Πατώντας το OK, ελέγχεται αν υπάρχει pattern με το ίδιο όνομα στον αντίστοιχο φάκελο των αρχείων.pattern και αν όχι συνεχίζει στο επόμενο βήμα/παράθυρο. Το κουμπί CANCEL και το κλείσιμο παραθύρου τερματίζουν τη διαδικασία ζητώντας πρώτα την επιβεβαίωση του χρήστη. Συνεχίζοντας, το δεύτερο παράθυρο του Pattern Creator φαίνεται στην Εικόνα 28:

75 64 DPDHMMY Εργαλείο Ανίχνευσης Σχεδιαστικών Προτύπων Λογισμικού Εικόνα 28. Δεύτερο παράθυρο του Pattern Creator Όπως φαίνεται, σε αυτό το βήμα ο χρήστης καλείται να συμπληρώσει τις ιδιότητες των μελών του pattern καθώς και τα abstraction τους (τύπος αφαιρετικότητας). Το παράθυρο προσαρμόζεται αυτόματα ανάλογα με τον αριθμό των μελών. Το τρίτο και τελευταίο παράθυρο φαίνεται στην Εικόνα 29. Εικόνα 29. Τρίτο παράθυρο του Pattern Creator Στο τελευταίο αυτό κομμάτι του Pattern Creator, ο χρήστης ενημερώνει το DPDHMMY για τις διάφορες συνδέσεις που καθορίζουν το πρότυπο σχεδίασης.

76 65 DPDHMMY Εργαλείο Ανίχνευσης Σχεδιαστικών Προτύπων Λογισμικού Μπορεί να διαλέξει ανάμεσα στις έξι βασικές συνδέσεις που αναλύσαμε στα προηγούμενα κεφάλαια μεταξύ των μελών που έχει ορίσει ήδη ο ίδιος. Το σύστημα απαγορεύει στον χρήστη να επιλέξει μια σύνδεση ανάμεσα στο ίδιο μέλος του προτύπου σχεδίασης. Επιλέγοντας τις συνδέσεις και πατώντας το κουμπί OK, η διαδικασία του Pattern Creator τερματίζεται και δημιουργείται το αντίστοιχο αρχείο.pattern στο φάκελο που έχει οριστεί. Επιστρέφοντας στο βασικό παράθυρο, ενημερώνεται το dropdown menu και ο χρήστης μπορεί να επιλέξει το καινούριο αυτό pattern για ανίχνευση. Το αρχείο.pattern που προκύπτει από το παράδειγμα των παραπάνω εικόνων φαίνεται στην Εικόνα 30. Εικόνα 30. Παράδειγμα δημιουργημένου pattern 5.4 Detect Pattern Η βασική λειτουργικότητα του DPDHMMY κρύβεται πίσω από αυτό το κουμπί. Μόλις ο χρήστης το πατήσει, ελέγχεται από το σύστημα αν έχουν προηγηθεί τα απαιτούμενα βήματα. Έτσι, ελέγχει αν έχει επιλεγεί ένα pattern στο dropdown menu, αν έχει επιλεγεί ο φάκελος του project και αν έχει επιλεγεί ο φάκελος όπου θα αποθηκευτούν τα αποτελέσματα. Αν κάποιος έλεγχος αποτύχει, εμφανίζεται το αντίστοιχο μήνυμα που προτρέπει τον χρήστη να το επιλύσει, διαφορετικά ξεκινάει η διαδικασία εύρεσης προτύπων σχεδίασης. Καλείται η συνάρτηση detectpatternfast και εμφανίζεται ένα παράθυρο αναμονής για την ολοκλήρωση της εκτέλεσης του αλγορίθμου. Όταν τελειώσει η ανίχνευση προτύπων, τα αποτελέσματα αποθηκεύονται σε ένα αρχείο.txt στο φάκελο των αποτελεσμάτων. Το αρχείο αυτό ονομάζεται με βάση το project και το pattern το οποίο ψάχνει. Ένα παράδειγμα αποτελέσματος εύρεσης Abstract Factory pattern φαίνεται παρακάτω.

77 66 DPDHMMY Εργαλείο Ανίχνευσης Σχεδιαστικών Προτύπων Λογισμικού Εικόνα 31. Παράδειγμα αρχείου αποτελεσμάτων