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

Transcript

1 ΟΙΚΟΝΟΜΙΚΟ ΠΑΝΕΠΙΣΤΗΜΙΟ ΑΘΗΝΩΝ ΤΜΗΜΑ ΠΛΗΡΟΦΟΡΙΚΗΣ ΜΕΤΑΠΤΥΧΙΑΚΟ ΔΙΠΛΩΜΑ ΕΙΔΙΚΕΥΣΗΣ (MSc) στα ΠΛΗΡΟΦΟΡΙΑΚΑ ΣΥΣΤΗΜΑΤΑ ΔΙΠΛΩΜΑΤΙKH ΕΡΓΑΣΙΑ «Μετρικές και ποιότητα αντικειμενοστραφούς λογισμικού» Νομικός Ιάκωβος Μ ΑΘΗΝΑ, Φεβρουάριος 2014

2

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

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

5 Περίληψη Ένα από τα σημαντικότερα προβλήματα που συναντά ένας μηχανικός λογισμικού, είναι η ποσοτικοποίηση της ποιότητας του λογισμικού που σχεδιάζει και παράγει. Ανεξάρτητα από το μέγεθος του έργου που υλοποιείται, μπορεί να παρατηρηθούν λάθη και αδυναμίες σε επίπεδο υλοποίησης ακόμα και μετά τη διάθεση του προϊόντος στην αγορά. Επομένως είναι απαραίτητο να ελέγχουμε έγκαιρα και να προλαμβάνουμε τα προβλήματα, πριν αυτά εμφανιστούν στο τελικό προϊόν. Σε αυτό του το πρόβλημα, έρχονται να βοηθήσουν οι μετρικές ποιότητας λογισμικού. Η χρήση τους παρέχει στον μηχανικό τη δυνατότητα να ποσοτικοποιήσει και να ελέγξει τις διαφορετικές παραμέτρους που συναντά κατά τον έλεγχο και την ανάπτυξη του λογισμικού. Παρότι δεν αποτελούν πανάκεια για την τελική ποιότητα και αρτιότητα του κώδικα, εντούτοις δίνουν μια εμπεριστατωμένη εικόνα για τις αδυναμίες που μπορεί να υπάρχουν και επομένως τον βοηθούν να τις εντοπίσει και να τις αντιμετωπίσει. Μετά από διεξοδική αναζήτηση της βιβλιογραφίας, βρέθηκε πως οι μετρικές που αφορούν την κληρονομικότητα είναι πολύ λίγες και ιδιαίτερα απλοϊκές, αφού δεν δίνουν στον χρήστη επαρκή εικόνα της εσωτερικής δομής του κώδικα. Συχνά τα μετρήσιμα μεγέθη που υπολογίζουν, περιέχουν μόνο μια απαρίθμηση δομών, χωρίς να παρέχουν περισσότερες πληροφορίες για την σχεδίαση. Για το λόγο αυτό προτείνονται μια σειρά μετρικών οι οποίες ποσοτικοποιούν την χρήση της κληρονομικότητας σε αντικειμενοστραφείς γλώσσες προγραμματισμού, ώστε να οδηγήσουν τον προγραμματιστή σε ασφαλή συμπεράσματα για την υλοποίησή του. Συγκεκριμένα οι μετρικές εντοπίζουν την ύπαρξη κλήσεων "super" και template μεθόδων στον κώδικα, αφού εφαρμοστεί κανονικοποίηση ως προς άλλα μετρήσιμα μεγέθη, όπως για παράδειγμα ο αριθμός των overrides. Η μέθοδος που ακολουθήθηκε για τον υπολογισμό των μετρικών, έχει το πλεονέκτημα πως βασίζει τα αποτελέσματά της στη σύγκριση μεγεθών τα οποία αποτελούν δείκτες "καλής" και "κακής" σχεδίασης. Υπολογίζονται σε επίπεδο project, αλλά ο χρήστης μπορεί να δει αναλυτικά τα αποτελέσματα των επιμέρους αρχείων στον φυλλομετρητή του. 2

6 Η μεθοδολογία υλοποιήθηκε στη γλώσσα προγραμματισμού Java και στην πλατφόρμα ανάπτυξης λογισμικού Eclipse. Συγκεκριμένα η υλοποίηση βασίστηκε στην πλατφόρμα ανοιχτού λογισμικού SonarQube, η οποία επεκτάθηκε για τον υπολογισμό νέων μετρικών ποιότητας. Χρησιμοποιήθηκε η υπάρχουσα δομή των AST και bytecode στην οποία έγιναν προσαρμογές για να συνθέσουμε τα εργαλεία, ενώ αλλαγές και προσθήκες έγιναν και σε επίπεδο interface για την εμφάνιση και αποθήκευση των αποτελεσμάτων. Επίσης έγινε χρήση της επέκτασης Metrics για το Eclipse, η οποία παρείχε υποστήριξη για όσα μετρήσιμα μεγέθη δεν ήταν δυνατόν να υπολογιστούν με την υπάρχουσα υποδομή του SonarQube. Τόσο η διαδικασία ελέγχου της λειτουργίας του εργαλείου, όσο και τα αποτελέσματά του, βασίστηκαν σε προγράμματα ανοιχτού κώδικα. 3

7 Abstract One of the most common problems that a Software Engineer can face, during the software design and implementation phase, is the quantification of his work. No matter the size of the project he deals with, errors and weaknesses can be observed, even after the product release. In other words, it is mandatory to check our code early and prevent any issues that could affect our final product. This problem can minimize by using software quality metrics. Their use provides the means for the software engineer to quantify and control the different parameters addressed during software development. Although they are not a one size fits all solution for any software development process, they give a comprehensive idea for the possible weaknesses of the program and they do so by helping detect and treat them. Following a thorough search of the literature, the metrics related to inheritance are few and have a rather shallow approach, since they don't present a clear view to the user regarding the internal structure of the code. In many cases, the measurables offer only a structure enumeration without providing enough information for the internal structure of the code. For these aforementioned reasons, a new metrics suite is proposed, which quantifies the use of inheritance in object oriented programming languages and gives the programmer a better insight for his design. The proposed metrics suite identifies the use of super calls and template methods within the code, after normalization with other measures is used, such as the number of overridden methods. The advantage of the used methodology, is that its results are based on comparing factors that indicate good or bad design. In addition, although the proposed metrics are calculated in project level, but the user has the ability to see in detail results of the individual files and folders in his browser. 4

8 The proposed methodology was implemented using Java programming language, on Eclipse software development platform. Specifically, the implementation was based on the SonarQube open source software quality management platform, which was extended to compute additional metrics. Using the existing AST and bytecode layer, changes and additions were made to compute the metrics suite. Amendments were also made at the interface level as well, in order to store and display the results. In addition Metrics plug-in was used, in order to support the calculation of those measures that were not possible to compute using excisting SonarQube structure. Both testing and results were based on open source programs. 5

9 Περιεχόμενα Πρόλογος... 1 Περίληψη... 2 Abstract... 4 Περιεχόμενα Ευρετήριο εικόνων... 8 Ευρετήριο πινάκων Εισαγωγή Μέτρηση ποιότητας λογισμικού Ποιότητα και λογισμικό Παράγοντες ποιοτικού λογισμικού Εξωτερικοί παράγοντες ποιότητας Εσωτερικοί παράγοντες ποιότητας Ποιότητα σχεδίασης Κόστος κακής σχεδίασης Μετρικές ποιότητας λογισμικού Κατηγορίες μετρικών CK Metrics Suite MOOD Metrics Suite Lorenz and Kidd Metrics Suite Άλλες χρήσιμες μετρικές Μετρικές κληρονομικότητας Συμπεράσματα βιβλιογραφικής έρευνας Προτάσεις μετρικών κληρονομικότητας Μέθοδος υπόδειγμα - Template Method Κλήσεις super και overrides Προτάσεις μετρικών Templateability (TILT) Hookability Super to Override Calls (SOV) Σημασιολογία των προτεινόμενων μετρικών Τεκμηρίωση μετρικών βάση των ιδιοτήτων Weyuker Υλοποίηση μετρικών και αποτελέσματα μετρήσεων... 56

10 5.1 Παρουσίαση πλατφόρμας SonarQube Βήματα ανάλυσης κώδικα Βήματα επέκτασης κώδικα Παρουσίαση διεπαφής SonarQube Η επέκταση Metrics Αποτελέσματα μετρήσεων Ανάλυση αποτελεσμάτων Συμπεράσματα Παράρτημα Α: Βήματα Εγκατάστασης του Maven Παράρτημα Β: Σημεία επέκτασης του SonarQube Βιβλιογραφία

11 Ευρετήριο εικόνων Εικόνα 1. Προσπέλαση διαδρομής Εικόνα 2. Διάγραμμα ποιότητας Εικόνα 3. Αρχείο properties Εικόνα 4. Διεπαφή χρήστη Εικόνα 5. Εμφάνιση μετρικών Εικόνα 6. Επέκταση Metrics Εικόνα 7. Δημιουργία τοπικών μεταβλητών Εικόνα 8. Δημιουργία τοπικής μεταβλητής Εικόνα 9. Περιβάλλον εργασίας

12 Ευρετήριο πινάκων Πίνακας 1. Έρευνα NASA Πίνακας 2. Χαρακτηριστικά συστήματος Πίνακας 3. Αποτελέσματα Μετρήσεων Πίνακας 4. Στατιστικά στοιχεία

13 1. Εισαγωγή Με το πέρασμα του χρόνου, οι μεθοδολογίες κατασκευής λογισμικού έχουν εξελιχθεί. Ξεκινώντας από το μοντέλο σπιράλ και το μοντέλο καταρράκτη, πλέον οι σύγχρονες ανάγκες, στην πλειονότητα των περιπτώσεων, επιτάσσουν την χρήση Agile μεθοδολογιών. Αντίστοιχα τα εργαλεία που υπάρχουν διαθέσιμα για την ανάπτυξη λογισμικού, έχουν εξελιχθεί. Ενώ μέχρι τα μέσα της δεκαετίας του 90 μεγάλο μέρος του λογισμικού που παραγόταν βασιζόταν στην χρήση γλωσσών διαδικαστικού προγραμματισμού, πλέον ο προσανατολισμός της αγοράς έχει εδραιώσει τις αντικειμενοστραφείς γλώσσες, όπως η Java, C++, C#, Ruby κ.α.. Αν μπορούσαν να ενταχθούν σε ένα κοινό πλαίσιο, η μεθοδολογία για την ανάπτυξη λογισμικού (μοντέλο καταρράκτη, agile κ.λ.π.) και η γλώσσα προγραμματισμού, αυτές αποτελούν το πλαίσιο της ανάπτυξης. Για την παραγωγή άρτιου λογισμικού, το οποίο πληροί τις προδιαγραφές του και δεν παρουσιάζει "μη αναμενόμενη συμπεριφορά" χρειάζονται να εκτιμηθούν και άλλοι παράγοντες. Ένας από αυτούς είναι ο συνεχής έλεγχος καθ όλα τα στάδια παραγωγής του, τόσο με την κλασική χρήση τεχνικών testing (unit testing, integration testing, System testing κ.λ.π.), όσο και με την χρήση μετρικών. Με την εξέλιξη του πλαισίου ανάπτυξης τις τελευταίες δεκαετίες, ήταν φυσικό να χρειαστούν εργαλεία προσαρμοσμένα στις νέες ανάγκες. Οι μετρικές που περιλαμβάνονται στην παρούσα εργασία καλύπτουν μια μακρά περίοδο, από τα τέλη της δεκαετίας του 80 έως σήμερα, καθώς η χρησιμότητά πολλών εξ αυτών είναι ανεξάρτητη από το έτος δημοσίευσής τους. Παρέχουν ένα σύνολο πληροφοριών που περιλαμβάνει απλά χαρακτηριστικά αλλά και πληροφορίες για την εσωτερική δομή του λογισμικού, μεγέθη χρήσιμα για κάθε προγραμματιστή. 10

14 Στο κεφάλαιο 2, γίνεται αναφορά στην έννοια της ποιότητας σε βιομηχανικό επίπεδο και πως αυτή συγκρίνεται με την ποιότητα λογισμικού. Στη συνέχεια γίνεται διαχωρισμός στους εσωτερικούς και εξωτερικούς παράγοντες του λογισμικού και περιγράφεται ο ρόλος και η σημασία τους κατά τη διάρκεια της ανάπτυξης. Έπειτα γίνεται αναφορά στην ποιότητα σχεδίασης, την σημασία της και τους παράγοντες από τους οποίους εξαρτάται. Τέλος γίνεται αναφορά στην κακή σχεδίαση και πως αυτή μπορεί να επηρεάσει τον προϋπολογισμό ενός έργου. Στο κεφάλαιο 3, γίνεται αναφορά στις μετρικές ποιότητας λογισμικού, τα οφέλη που παρουσιάζουν για τον προγραμματιστή και γιατί είναι χρήσιμες για κάθε έργο πληροφορικής. Στη συνέχεια, γίνεται παρουσίαση των πλέον αντιπροσωπευτικών, από το σύνολο των μετρικών που βρέθηκαν στην βιβλιογραφία. Στην τελευταία ενότητα γίνεται ειδικότερη ανάλυση των μετρικών κληρονομικότητας. Στο κεφάλαιο 4, γίνεται ανάλυση των προτεινόμενων μετρικών κληρονομικότητας. Αρχικά επεξηγούνται τα στοιχεία τους όπως, Template μέθοδοι, hook μέθοδοι, κλήσεις "super" και overrides. Στη συνέχεια παρουσιάζεται η δομή και η εννοιολογία τους ενώ στο τέλος του κεφαλαίου γίνεται και η τεκμηρίωσή τους βάση των ιδιοτήτων Weyuker. Στο κεφάλαιο 5, δίνονται χρήσιμες πληροφορίες για την πλατφόρμα υλοποίησης όπως η διεπαφή, ο τρόπο εγκατάστασης, τα χαρακτηριστικά και τις δυνατότητές της. Στη συνέχεια γίνεται παρουσίαση των αποτελεσμάτων, τα οποία αποτελούν τη βάση για την δημιουργία ορίων ποιότητας στην σχεδίαση. Τέλος αναλύεται η συσχέτιση ανάμεσα στην μετρική SOV και TILT και πως αυτές οι δυο μετρικές αποτελούν ένδειξη της συνολικής ποιότητας του έργου. Το κεφάλαιο 6 περιλαμβάνει τα συμπεράσματα της μελέτης. 11

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

16 2.1 Ποιότητα και λογισμικό Ο όρος ποιότητα λογισμικού περιλαμβάνει ένα σύνολο χαρακτηριστικών και σίγουρα δεν μπορεί να περιοριστεί σε έναν μόνο ορισμό. Κάποια χαρακτηριστικά αφορούν τον τελικό χρήστη, άλλα τον προγραμματιστή και άλλα τη διοίκηση. Η ανάπτυξη λογισμικού δεν αποτελεί μια στατική διαδικασία, αλλά μια συνεχή προσπάθεια για την επίτευξη του στόχου, που είναι η εκπλήρωση (τουλάχιστον) των αρχικών προδιαγραφών. Τι ονομάζουμε όμως αρχικά σαν ποιότητα; Σύμφωνα με τον ειδικό Philip Crosby, ένα παραγόμενο προϊόν ονομάζεται ποιοτικό, όταν αυτό έχει μηδέν ελαττώματα [88]. Με άλλα λόγια πρέπει πάντα το τελικό προϊόν να υπακούει στις αρχικές προδιαγραφές και να μην εμφανίζει χαρακτηριστικά που δεν είχαν σχεδιαστεί ή προβλεφθεί. Ένα καλός ορισμός μπορεί να βρεθεί και στο πρότυπο ISO 8402:1986. Συγκεκριμένα ως ποιότητα ορίζεται "το σύνολο των δυνατοτήτων και χαρακτηριστικών ενός προϊόντος ή μιας υπηρεσίας, που φέρει την ικανότητα να ικανοποιεί δηλωθέντες ανάγκες" [89]. Ο Walter A. Shewhart στο βιβλίο του " Out of the crisis: quality, productivity and competitive position " προσπαθεί να δώσει έναν ορισμό. "Η δυσκολία στον καθορισμό της ποιότητας, είναι η μετάφραση των μελλοντικών αναγκών του χρήστη σε μετρήσιμα χαρακτηριστικά, έτσι ώστε ένα προϊόν που θα σχεδιαστεί, να καταλήξει να δώσει ικανοποίηση σε μια τιμή που θα πληρώσει ο χρήστης" [90]. Στο βιβλίο "Production And Operations Management" η ποιότητα ορίζεται ως ένα "υποκειμενικό χαρακτηριστικό που μπορεί να γίνει κατανοητό με διαφορετικό τρόπο από διαφορετικούς ανθρώπους".[94] Οι παραπάνω ορισμοί απευθύνονται κυρίως σε βιομηχανικά προϊόντα, τα οποία έχουν μετρήσιμα χαρακτηριστικά και εύκολα προκύπτει αν το τελικό αποτέλεσμα συμφωνεί με τις αρχικές προδιαγραφές. Σε ποιο βαθμό είναι όμως αυτό εφικτό για το λογισμικό; Σε πόσο στενά πλαίσια μπορεί να οριστεί η ποιότητα λογισμικού και τι ακριβώς αυτή περιλαμβάνει, αφού αναφέρεται σε κάτι άυλο; 13

17 Για να δοθεί ικανοποιητική απάντηση, θα πρέπει πρώτα να κατανοηθούν οι αντικειμενικές δυσκολίες που συναντά ένας προγραμματιστής κατά τη συγγραφή ενός έργου. Έστω ότι υπάρχει ένα καλά δομημένο πρόγραμμα, το οποίο ανά 1000 γραμμές κώδικα παρουσιάζει 10 διακλαδώσεις. Τότε ένα πρόγραμμα ενός εκατομμυρίου γραμμών θα αποτελείται από διακλαδώσεις. Για να γίνει προσπέλαση σε όλες τις δυνατές διαδρομές ενός πίνακα 100 Χ 100, θα πρέπει να εξεταστούν 2.28 * 10^58 πιθανά μονοπάτια! [92] Φυσικά κάτι τέτοιο είναι αδύνατο να πραγματοποιηθεί. Επομένως για κάθε πρόγραμμα που βγαίνει στην παραγωγή, δεν μπορεί να υπάρξει εγγύηση πως είναι 100% άρτιο και πληροί τις προδιαγραφές που τέθηκαν εξ αρχής ή τις απαιτήσεις του πελάτη. Το πιο πιθανό είναι πως θα εμφανίσει κατά τη διάρκεια του κύκλου ζωής του, μη αναμενόμενη συμπεριφορά. Άμεσα γίνεται αντιληπτό, πως αν στον ορισμό ποιότητας των βιομηχανικών προϊόντων υπάρχει βεβαιότητα για την εναρμόνιση του τελικού προϊόντος με τις προδιαγραφές που τέθηκαν, στην περίπτωση του λογισμικού υπάρχει μόνο "προσεγγιστική βεβαιότητα". Α Β Εικόνα 1: Ενδεικτικό διάγραμμα προσπέλασης διαδρομής, από το κόμβο Α στον Β 14

18 2.2 Παράγοντες ποιοτικού λογισμικού Ένας βασικός διαχωρισμός που μπορεί να πραγματοποιηθεί στους παράγοντες που καθορίζουν την ποιότητα του λογισμικού, είναι ανάμεσα σε εξωτερικούς και εσωτερικούς. Τους εσωτερικούς παράγοντες μπορεί να τους αντιληφθεί μόνο ο προγραμματιστής. Τους εξωτερικούς τους αντιλαμβάνεται ο χρήστης και αυτοί είναι βαρόμετρο για την επιτυχία της εφαρμογής, ενώ η επίδοσή τους βασίζεται στους εσωτερικούς παράγοντες Εξωτερικοί παράγοντες ποιότητας Κατηγοριοποιώντας τους πιο σημαντικούς εξωτερικούς παράγοντες που πρέπει να εκτιμηθούν κατά τη συγγραφή του λογισμικού, αυτοί είναι [96] [91] : Αξιοπιστία (Reliability) Η αξιοπιστία είναι ένα χαρακτηριστικό που αναφέρεται στην ανθεκτικότητα και την δομική ακεραιότητα ενός έργου πληροφορικής. Μετρά το μέγεθος του ρίσκου το οποίο είναι άμεσα εξαρτώμενο από την συχνότητα εμφάνισης σφαλμάτων στο πρόγραμμα. Επίσης μετρά τα ελαττώματα που πιθανόν να προκύπτουν μετά από αλλαγές που πραγματοποιούνται στο λογισμικό. Για την αύξηση της αξιοπιστίας, πρέπει να μειωθούν ή δυνατόν να αποτραπούν διαστήματα "downtime", διακοπές λειτουργίας της εφαρμογής ή άλλα σφάλματα που επηρεάζουν άμεσα τους χρήστες. Ορθότητα (Correctness) Η ορθότητα, είναι η ικανότητα των προϊόντων πληροφορικής, να εκτελούν τον ακριβή σκοπό των προδιαγραφών βάσει των οποίων σχεδιάστηκαν. Αποτελεί το πλέον σημαντικό χαρακτηριστικό κάθε προγράμματος γιατί ταυτίζεται με την λειτουργία της εφαρμογής. Αν ένα προϊόν για παράδειγμα έχει γρήγορη απόκριση, ελκυστική διεπαφή ή οποιοδήποτε άλλο καλά σχεδιασμένο χαρακτηριστικό, δεν θα έχει κανένα αντίκρισμα αν δεν εκτελεί το σύνολο των λειτουργιών για τις οποίες σχεδιάστηκε. 15

19 Η πιο διαδεδομένη μέθοδος διασφάλισης της ορθότητας, είναι η υπό όρους προσέγγιση. Σε αυτή την τεχνική γίνεται η παραδοχή, πως το επίπεδο που προηγείται της εφαρμογής και κατ επέκταση όλα τα χαμηλότερα επίπεδα, δεν παρουσιάζουν κάποια ατέλεια. Για να γίνει εύκολα κατανοητό, ας θεωρήσουμε πως έχουμε δυο επίπεδα που το ένα βασίζεται στο άλλο. Στο πρώτο επίπεδο βρίσκεται ο compiler και στο δεύτερο το λειτουργικό σύστημα. Κατά την ανάπτυξη του compiler, υποθέτουμε πως το επίπεδο του λειτουργικού συστήματος δεν έχει κάποια ατέλεια και ασχολούμαστε μόνο με το πρώτο επίπεδο. Ευρωστία (Robustness) Ευρωστία, είναι η ικανότητα των προγραμμάτων στο να αντιδρούν σωστά, όταν παρουσιάζονται μη αναμενόμενες συνθήκες. Η ευρωστία συμπληρώνει την ορθότητα, καθώς στην πρώτη περίπτωση εξετάζεται η συμπεριφορά του συστήματος σε συνθήκες που δεν έχουν περιγραφεί από τις προδιαγραφές, ενώ στην δεύτερη περίπτωση συγκρίνεται η συμπεριφορά του συστήματος σύμφωνα με την περιγραφή των προδιαγραφών. Πάντα θα υπάρχουν περιπτώσεις οι οποίες δεν έχουν προβλεφθεί από τον αρχικό σχεδιασμό. Ο ρόλος της ευρωστίας, είναι να κάνει σίγουρο πως αν τέτοιες περιπτώσεις εμφανιστούν κατά την εκτέλεση του προγράμματος, δεν θα προκαλέσουν ανεξέλεγκτα γεγονότα. Ο χρήστης πρέπει να ενημερώνεται με κατάλληλα διαγνωστικά μηνύματα λάθους και στη συνέχεια να τερματίζεται ομαλά η λειτουργία του προγράμματος. Συμβατότητα (Compatibility) Συμβατότητα είναι η ευκολία με την οποία ένα κομμάτι λογισμικού συνδυάζεται με κάποιο άλλο, δηλαδή σχετίζεται με την παρουσίαση ή μη, αναμενόμενων συμπεριφορών κατά την αλληλεπίδρασή του με άλλα στοιχεία. Προφανώς είναι ένα πολύ σημαντικό χαρακτηριστικό, καθώς τα περισσότερα από τα προγράμματα που χρησιμοποιούνται σήμερα αλληλεπιδρούν με ένα σύνολο άλλων εφαρμογών. Για παράδειγμα ένας text editor κάνει export ένα αρχείο σε μια δεύτερη εφαρμογή, ένα IDE πρόγραμμα, χρησιμοποιεί επεκτάσεις για να προσθέσει λειτουργικότητα κ.ο.κ.. Βασική παράμετρος εγγύησης της συμβατότητας έγκειται στην ομοιογένεια του σχεδιασμού και του ορισμού τυποποιημένων συμβάσεων επικοινωνίας μεταξύ των προγραμμάτων. Η προσέγγιση αυτή περιλαμβάνει: 16

20 Τυποποιημένες διεπαφές χρήστη, οι οποίες υπάρχουν για παράδειγμα σε εκδόσεις των Windows και MacOS, όπου όλα τα εργαλεία χρησιμοποιούν ένα καθορισμένο πρότυπο για την επικοινωνία με τον χρήστη, μέσα από συγκεκριμένα στοιχεία, όπως παράθυρα, εικονίδια, μενού κλπ Τυποποιημένες δομές δεδομένων, όπως τα Lisp συστήματα, όπου όλα τα δεδομένα και τα προγράμματα, αντιπροσωπεύονται από δυαδικά δέντρα Τυποποιημένες μορφές αρχείων, όπως στο σύστημα Unix, όπου κάθε αρχείο κειμένου είναι απλά μια ακολουθία χαρακτήρων Αποτελεσματικότητα (Efficiency) Αποτελεσματικότητα, είναι η ικανότητα ενός συστήματος λογισμικού να πραγματοποιεί τη λιγότερη δυνατή χρήση των πόρων του υλικού, όπως επεξεργαστική ισχύ, μνήμη, χωρητικότητα του μέσου αποθήκευσης κ.λ.π.. Η αποτελεσματικότητα είναι σημαντικό να μην αντιμετωπίζεται χωριστά, αλλά να συνδυάζεται με άλλους παράγοντες, όπως η επεκτασιμότητα και η επαναχρησιμοποίηση. Γίνεται κατανοητό, πως η επιδίωξη της βέλτιστης διαχείρισης των πόρων ενός συστήματος κατά τη σχεδίαση, μπορεί να έχει σημαντικές συνέπειες στην λειτουργικότητα της εφαρμογής. Παρόλα αυτά καλό είναι να υπάρχει μια ισορροπία. Κανένας χρήστης δεν θα εγκαθιστούσε μια εφαρμογή που προκαλεί μεγάλο φόρτο στην επεξεργαστική μονάδα του υπολογιστή του ή καταλαμβάνει το μεγαλύτερο μέρος της μνήμης του. Σε γενικές γραμμές, η αποτελεσματικότητα πρέπει να συμβαδίζει με την ορθότητα. Για παράδειγμα, μια εφαρμογή πρέπει να αποκρίνεται σε ένα ορισμένο διάστημα χρόνου από τη στιγμή που ο χρήστης την εκκινήσει. Σε ένα άμεσα αντιληπτό παράδειγμα, αν υποθέσουμε πως ένα αυτοκίνητο στο οποίο οι λειτουργίες του ελέγχονται από μία κεντρική μονάδα, όταν ο οδηγός πατήσει το φρένο, το σήμα πρέπει ανιχνευθεί και να μετατραπεί σε επιβράδυνση, μέσα σε ένα εύλογα μικρό χρονικό διάστημα. 17

21 Ευκολία χρήσης (Usability) Η ευκολία χρήσης, αναφέρεται στην ευκολία με την οποία χρήστες από διαφορετικά γνωστικά υπόβαθρα στην λειτουργία του υπολογιστή, μπορούν να χρησιμοποιήσουν μια εφαρμογή. Η απαίτηση αυτή αποτελεί μια από τις μεγαλύτερες προκλήσεις για τους σχεδιαστές λογισμικού που ασχολούνται σε αυτό τον τομέα. Είναι ιδιαίτερα σημαντικό κάθε εφαρμογή, όταν διατίθεται, να είναι σχεδιασμένη με τέτοιον τρόπο που να επιτρέπει σε έναν αρχάριο χρήστη να την κατανοήσει σχετικά εύκολα, χωρίς βέβαια να γίνεται αρκετά απλοϊκή για τους πιο έμπειρους. Ο σχεδιασμός πρέπει να προσεγγίζει την οπτική γωνία και να εξυπηρετεί τις ανάγκες του χρήστη. Λειτουργικότητα (Functionality) Λειτουργικότητα είναι η έκταση των δυνατοτήτων που παρέχει το λογισμικό. Ένα από τα μεγαλύτερα προβλήματα που έχει να αντιμετωπίσει ένας αρχιτέκτονας λογισμικού, είναι πόση λειτουργικότητα θα προσθέσει στο έργο που αναλαμβάνει. Κατά τη σχεδίαση πρέπει να υπολογιστεί η χρυσή τομή ανάμεσα στις απαιτήσεις της εταιρίας για περισσότερα χαρακτηριστικά, τις προσδοκίες των χρηστών και τον υπάρχων ανταγωνισμό της αγοράς. Απόρροια της ανεξέλεγκτης προσθήκης χαρακτηριστικών, είναι άλλοι δύο κίνδυνοι. Ο πιο αντιμετωπίσιμος, είναι η απώλεια συνοχής του προγράμματος, σε βαθμό που να επηρεάζει την ευκολία χρήσης. Ο μεγαλύτερος κίνδυνος είναι η υπέρμετρη προσήλωση στην λειτουργικότητα, που μπορεί να οδηγήσει στην υποβάθμιση της προτεραιότητας των υπολοίπων παραγόντων της ανάπτυξης του λογισμικού. Όπως φαίνεται στην εικόνα 3 η οποία περιγράφει τις ιδέες του Roger Osmond [97], η μαύρη γραμμή αφορά την διαρκή προσπάθεια, αύξησης της λειτουργικότητας, με συνέπεια να χάνεται η συνολική ποιότητα του προϊόντος. Στο τελικό στάδιο, όλες οι ενέργειες εστιάζουν στην αποσφαλμάτωση και την βελτίωση της εικόνας του τελικού προϊόντος χωρίς να είναι σίγουρο πως ο στόχος αυτός θα επιτευχθεί. Σε περίπτωση που λόγω πίεσης από τους χρήστες ή τον ανταγωνισμό χρειαστεί να διατεθεί το λογισμικό νωρίτερα στην αγορά (ενδεικτικά ας υποθέσουμε πως αυτές οι περίοδοι σημειώνονται σαν τετράγωνο), τότε διακυβεύεται η εικόνα της επιχείρησης. 18

22 Αυτό που προτείνει ο Osmnod και παριστάνεται με την χρωματιστή γραμμή, είναι η διατήρηση της ποιότητας των υπολοίπων παραγόντων (συμβατότητα, επεκτασιμότητα κ.λ.π.), καθ όλη τη διάρκεια ανάπτυξης του λογισμικού και την προσθήκη νέων χαρακτηριστικών μόνο όταν τα υπάρχοντα πληρούν τις προδιαγραφές. Η μέθοδος αυτή παρόλη τη δυσκολία της, παρέχει πιο αποτελεσματική κατεύθυνση για την απόδοση καλύτερων ποιοτικά προϊόντων. Ακόμα και αν το τελικό προϊόν είναι το ίδιο στις δυο περιπτώσεις, η απόφαση να διοχετευθεί στην αγορά μια πρώιμη έκδοση γίνεται πιο εύκολη. Ποιότητα Λειτουργικότητα Εικόνα 2 : Διάγραμμα εκτίμησης ποιότητας λογισμικού σε σχέση με τη λειτουργικότητα. Τα τετράγωνα αναπαριστούν αποφάσεις για πρώιμη διάθεση του λογισμικού στην αγορά Εσωτερικοί παράγοντες ποιότητας Κατηγοριοποιώντας τους πιο σημαντικούς εσωτερικούς παράγοντες που πρέπει να εκτιμηθούν κατά τη συγγραφή ενός προγράμματος, αυτοί είναι [96][91] : 19

23 Επαναχρησιμοποίηση (Reusability) Επαναχρησιμοποίηση, είναι η δυνατότητα των στοιχείων λογισμικού, να μπορούν να χρησιμοποιηθούν στην κατασκευή διαφορετικών εφαρμογών, από αυτές για τις οποίες σχεδιάστηκαν αρχικά. Η ανάγκη για επαναχρησιμοποίηση προήλθε από την παρατήρηση ότι εμφανίζονται περιπτώσεις όπου διαφορετικά συστήματα λογισμικού, ακολουθούν παρόμοια πρότυπα. Επομένως, η σπατάλη χρόνου και χρημάτων για την εύρεση λύσεων που έχουν υλοποιηθεί στο παρελθόν είναι περιττή. Η επαναχρησιμοποίηση, επηρεάζει και άλλους τομείς της ποιότητας λογισμικού όπως είναι η ορθότητα και η ευρωστία που προαναφέρθηκαν. Επεκτασιμότητα (Extensibility) Επεκτασιμότητα είναι η ευκολία προσαρμογής των προϊόντων λογισμικού σε αλλαγές των προδιαγραφών. Το βασικό πρόβλημα της επεκτασιμότητας είναι η κλίμακα. Για μικρά προγράμματα η πραγματοποίηση αλλαγών συνήθως δεν είναι δύσκολο έργο, αλλά όσο αυξάνει το μέγεθος, τόσο πιο απαιτητική γίνεται. Δυο βασικές τεχνικές για την βελτίωση της επεκτασιμότητας είναι: Απλούστευση του σχεδιασμού: Μια απλή αρχιτεκτονική είναι ευκολότερο να προσαρμοστεί σε αλλαγές από ότι μια πολύπλοκη. Αφαίρεση: Όσο πιο αυτόνομες είναι οι μονάδες του λογισμικού, τόσο περισσότερο αυξάνεται η πιθανότητα, μια μικρή αλλαγή να επηρεάσει μόνο μια μονάδα από το να προκαλέσει μια αλυσιδωτή αντίδραση αλλαγών σε ολόκληρο το σύστημα. Η χρήση αντικειμενοστραφών γλωσσών προγραμματισμού που εξετάζεται στην παρούσα διπλωματική εργασία, υποστηρίζει αυτές τις δυο τεχνικές. 20

24 Συντηρησιμότητα (Maintainability) Η συντηρησιμότητα αναφέρεται στην ευκολία με την οποία μπορούν να γίνουν αλλαγές σε ένα σύστημα λογισμικού, να προστεθούν δυνατότητες, να βελτιωθεί η απόδοση ή να διορθωθούν πιθανά σφάλματα. Η μέτρηση και η παρακολούθηση της συντηρησιμότητας είναι ιδιαίτερα σημαντική, ειδικά όταν αφορά κρίσιμες για την εταιρία εφαρμογές, όπου κάθε αλλαγή επηρεάζει άμεσα τον χρόνο διάθεσης του προϊόντος στην αγορά. Επίσης είναι πολύ σημαντικό να κρατηθεί το κόστος συντήρησης κάτω από ένα επιθυμητό όριο. Φορητότητα (Portability) Φορητότητα, είναι η ευκολία με την οποία ένα προϊόν λογισμικού μπορεί να τροποποιηθεί με τρόπο που να επιτρέπει τη μεταφορά του σε συστήματα τα οποία υποστηρίζουν διαφορετικό υλικό και λογισμικό. Κάνοντας μια δεύτερη ανάγνωση στον ορισμό, γίνεται ευδιάκριτο, ότι η φορητότητα εξαρτάται από την αλληλεπίδραση ανάμεσα σε υλικό και λογισμικό, δηλαδή αναφέρεται κυρίως σε λειτουργικά συστήματα και άλλα θεμελιώδη εργαλεία. Ελεγξιμότητα (Testability) Η ελεγξιμότητα αναφέρεται στην ευκολία με την οποία, ο μηχανικός λογισμικού μπορεί να πραγματοποιήσει διαδικασίες ελέγχου στο πρόγραμμα, ώστε να επαληθεύσει πως το σύστημα πληροί τις απαιτήσεις. Είναι προφανές πως όσο απλούστερη είναι η εσωτερική δομή του προγράμματος, τόσο πιο εύκολα μπορούν να πραγματοποιηθούν έλεγχοι. Άλλοι παράγοντες Επικαιρότητα (Timeliness) : Ορίζεται ως η ικανότητα του λογισμικού να εξυπηρετήσει τις προβλεπόμενες ανάγκες των χρηστών και είναι άμεσα εξαρτώμενο μέγεθος από το πόσο άμεσα μπορεί να διοχετευθεί το λογισμικό στην αγορά. Είναι ένας αρκετά σημαντικός παράγοντας καθώς αν δεν εκτιμηθεί σωστά, μπορεί η κυκλοφορία του προϊόντος να γίνει με σημαντική χρονική καθυστέρηση, αναλογικά με τις προσδοκίες των χρηστών. Ακεραιότητα (Integrity) : Είναι η ικανότητα των προϊόντων λογισμικού, να προστατεύουν τα συστατικά τους (όπως δεδομένα), ενάντια σε μη εξουσιοδοτημένη πρόσβαση. Οικονομικότητα (Economy) : Κατά πόσον το πρόγραμμα μπορεί να ολοκληρωθεί μέσα στον αρχικό προϋπολογισμό. 21

25 2.3 Ποιότητα σχεδίασης Το σύνολο των παραγόντων που αναφέρθηκαν στην παράγραφο 2.2, αφορούν την ποιότητα του λογισμικού σε επίπεδο έργου. Η ποιότητα σχεδίασης αφορά την εσωτερική δομή των προγραμμάτων και εξαρτάται από τις μονάδες λογισμικού που το απαρτίζουν, όπως κλάσεις, μέθοδοι και πακέτα. Ο ρόλος της ποιότητας σχεδίασης είναι ζωτικής σημασίας για μια επιχείρηση, διότι: είναι βαρόμετρο της τελικής ποιότητας του προϊόντος η ποιοτική σχεδίαση μειώνει τον χρόνο ελέγχου της εφαρμογής, επομένως μειώνει το κόστος για την επιχείρηση κάνει πιο εύκολη την τροποποίηση χαρακτηριστικών του λογισμικού αυξάνει την αξιοπιστία κάνει πιο εύκολη και μειώνει το κόστος της συντήρησης του λογισμικού είναι θεμέλιος λίθος των εσωτερικών παραγόντων ποιότητας και των προδιαγραφών τις οποίες αυτοί πληρούν. Κάνοντας μια σύνοψη των σχεδιαστικών χαρακτηριστικών που καθιστούν ένα έργο ποιοτικό, αυτά είναι : Αφαίρεση Η αφαίρεση είναι μια μέθοδος η οποία εξυπηρετεί την διαχείριση της πολυπλοκότητας από τον προγραμματιστή. Με την χρήση της αφαίρεσης, πληροφορίες οι οποίες δεν ενδιαφέρουν τον σχεδιαστή εκείνη τη στιγμή, αγνοούνται και η προσοχή του εστιάζεται σε εκείνες οι οποίες κρίνονται ως σημαντικές [108]. 22

26 Για παράδειγμα αν υπάρχουν δυο ή περισσότερες κλάσεις, οι οποίες εμφανίζουν αρκετές ομοιότητες στην υλοποίησή τους, μπορούν να αγνοηθούν οι μεταξύ τους διαφορές ώστε να υλοποιηθεί μια υπερκλάση. Έτσι, θα ομαδοποιηθούν τα μεταξύ τους κοινά στοιχεία σε μια μονάδα, και θα απλουστευτεί η σχεδίαση. Η αφαίρεση πρέπει να χρησιμοποιείται με τρόπο που δεν αλλοιώνει το πρόβλημα. Τμηματικότητα Με την τμηματικότητα, ο προγραμματιστής μπορεί να διαχειριστεί την πολυπλοκότητα του λογισμικού εστιάζοντας κάθε φορά σε μια μονάδα λογισμικού. Η χρήση της επιτρέπει την απομόνωση μερών του προβλήματος που είναι περισσότερο δύσκολα, χωρίς να λαμβάνονται υπόψιν όλα τα υπόλοιπα. Επίσης δίνει τη δυνατότητα να περιοριστούν σε μια μονάδα λεπτομέρειες που δεν αφορούν άλλες μονάδες, με αποτέλεσμα την ευελιξία και την κατανοησιμότητα [108]. Η τμηματικότητα είναι ανάλογη του αριθμού των μονάδων που έχουν ορισθεί κατά το σχεδιασμό του συστήματος. Όσο περισσότερες μονάδες χαμηλής πολυπλοκότητας υπάρχουν, τόσο μειώνεται το κόστος ανάπτυξής τους και αυξάνεται αντίστροφα το κόστος της μεταξύ τους επικοινωνίας. Απόκρυψη πληροφοριών Με την χρήση της απόκρυψη πληροφορίας δίνεται η δυνατότητα στον προγραμματιστή να αποκρύψει επιλογές σχεδίασης μια μονάδας λογισμικού σε όσους την χρησιμοποιούν. Οι βασικότεροι λόγοι χρήσης της απόκρυψης πληροφορίας, είναι για την απόκρυψη της πολυπλοκότητας της υλοποίησης και την απόκρυψης στοιχείων της μονάδας, που εκτιμάται πως θα αλλάξουν στο μέλλον. Η χρήση της, καθιστά ευκολότερη την τροποποίηση και τη συντήρηση του λογισμικού [108]. Σύζευξη Η σύζευξη είναι ένα μέτρο εξάρτησης των μονάδων λογισμικού. Όσο μεγαλύτερο βαθμό εξάρτησης έχουν δυο μονάδες τόσο υψηλότερη σύζευξη εμφανίζουν, ενώ με μικρότερο βαθμό εξάρτησης παρουσιάζουν πιο χαλαρή σύζευξη. Επομένως, στην πρώτη περίπτωση αν χρειαστεί να γίνουν αλλαγές σε μια μονάδα λογισμικού, αναπόφευκτα θα επηρεαστούν και άλλες. Οι βασικότεροι λόγοι που καθιστούν την μείωση της σύζευξης επιθυμητή είναι [108]: 23

27 Οι αλλαγές σε μονάδες λογισμικού έχουν τοπικό χαρακτήρα. Για παράδειγμα, αν πραγματοποιηθούν αλλαγές στο σχεδιασμό μιας λειτουργίας, εφόσον η σύζευξη είναι χαλαρή, τότε η αντικατάσταση αυτής της λειτουργίας θα είναι μια σχετικά εύκολη υπόθεση και δεν θα επηρεαστούν πολλές μονάδες. Διευκολύνεται η συντήρηση του λογισμικού. Όταν χρειαστεί να γίνουν ρυθμίσεις σε μια μονάδα λογισμικού, αν η σύζευξη με άλλα στοιχεία του προγράμματος είναι μικρή, οι αλλαγές θα είναι ελεγχόμενες. Όσο μικρότερη είναι η σύζευξη μεταξύ των μονάδων, διευκολύνεται η επαναχρησιμοποίηση των στοιχείων σε άλλα προγράμματα, καθώς ο βαθμός εξάρτησης είναι πολύ μικρός. Διευκολύνεται ο έλεγχος και η εκσφαλμάτωση του λογισμικού. Κατά το στάδιο ελέγχου του έργου, εάν παρατηρηθεί κάποιο σφάλμα γίνεται πιο εύκολο να ελέγξουμε τη συγκεκριμένη μονάδα από το να ελέγξουμε και το σύνολο των μονάδων με τις οποίες σχετίζεται και ενδεχομένως να επηρεάζουν τη συμπεριφορά της. Συνεκτικότητα Η συνεκτικότητα είναι ένα μέτρο που απεικονίζει τον βαθμό συσχέτισης μεταξύ των δομικών στοιχείων μια μονάδας λογισμικού. Κατά τη σχεδίαση, στόχος είναι η επίτευξη υψηλής συνεκτικότητας, ώστε να εξασφαλιστεί πως τα στοιχεία κάθε μονάδας λογισμικού εξυπηρετούν έναν συγκεκριμένο σκοπό. Σε αντίθεση με τη σύζευξη που εξετάζει εξαρτήσεις διαφορετικών μονάδων, η συνεκτικότητα εστιάζει σε μια μονάδα [108]. 2.4 Κόστος κακής σχεδίασης Έως τώρα αναφέρθηκαν τα πλεονεκτήματα και τα χαρακτηριστικά που πρέπει να έχει ένα προϊόν λογισμικού για να θεωρείται ποιοτικό. Κλείνοντας αυτό το κεφάλαιο, θα γίνει αναφορά στο κόστος της κακής ποιοτικά σχεδίασης και πως αυτή μπορεί να επηρεάσει σημαντικά το κόστος του τελικού προϊόντος. Το κόστος κακής ποιότητας (Cost Of Poor Quality) ορίζεται σαν το άθροισμα τεσσάρων επιμέρους μεταβλητών. Αυτές είναι, το κόστος 24

28 καθυστερημένης διάθεσης, χαμένων εσόδων, επεξεργασίας και τεχνικού χρέους [100]. Αναλυτικά: Το κόστος καθυστερημένης διάθεσης είναι το χαμένο κόστος ευκαιρίας ανά μονάδα χρόνου που το προϊόν δεν βρίσκεται στην αγορά. Το κόστος τεχνικού χρέους αφορά την αποσφαλμάτωση λογισμικού που έχει φτάσει στο στάδιο παραγωγής. Το κόστος επεξεργασίας είναι το μέγεθος της προσπάθειας που απαιτείται για λογισμικό, το οποίο έχει περάσει το στάδιο της ανάπτυξης αλλά έχει κάποια ελαττωματικά χαρακτηριστικά τα οποία δεν έχουν περάσει τα στάδια ελέγχου. Το κόστος χαμένων εσόδων αφορά τις παραπάνω τρεις περιπτώσεις και είναι αρκετά δύσκολο να υπολογιστεί. Παρότι δεν κρίνεται σκόπιμο να γίνει εκτενής παρουσίαση αριθμητικών στοιχείων στα πλαίσια της παρούσας διπλωματικής εργασίας, αξίζει να αναφερθεί ένα ενδεικτικό παράδειγμα το οποίο φανερώνει την κρισιμότητα της ποιοτικής σχεδίασης από έναν οργανισμό. Έστω πως μια εταιρία πληροφορικής υλοποιεί ένα έργο με γραμμές κώδικα. Σύμφωνα με την COCOMO, η μέση παραγωγικότητα ενός υπαλλήλου σε ένα έργο αυτού του μεγέθους είναι 330 γραμμές κώδικα τον μήνα και για να ολοκληρωθεί θα χρειαστούν 303 μήνες εργασίας. Ο μέσος μισθός ενός προγραμματιστή με γνώσεις Java υπολογίζεται στα τον χρόνο και αν εκτιμηθεί πως το πραγματικό κόστος του εργαζόμενου για την επιχείρηση είναι 1.5 φορές περισσότερο, τότε προκύπτει ένα εκτιμώμενο κόστος αξίας Επομένως το συνολικό κόστος του έργου υπολογίζεται κοντά στα 2.2 εκατομμύρια ευρώ [100]. Το μέσο κόστος επεξεργασίας υπολογίζεται σε 2 ανά γραμμή κώδικα, το οποίο οδηγεί σε συνολικό κόστος [100]. Αν το έργο βασίζεται στην Java, το κόστος επεξεργασίας αυξάνεται σε 3.75 ανά γραμμή κώδικα, το οποίο οδηγεί σε συνολικό κόστος

29 Το μέσο κόστος τεχνικού χρέους είναι 5 ελαττώματα ανά 1000 γραμμές κώδικα, οπότε συνολικά παρουσιάζονται περίπου 500 ελαττώματα, με το κόστος της κάθε επιδιόρθωσης να εκτιμάται σε 5 ώρες. Μέσα σε ένα οκτάωρο με την αποδοτικότητα κάθε εργαζόμενου να κυμαίνεται στο 65%, μπορούν να διορθωθούν 22 ελαττώματα τον μήνα ανά εργάτη. Με τον τρόπο αυτό η εταιρία οδηγείται σε έξοδα περίπου [100]. Η μέση απόκλιση στην παράδοση έργων πληροφορικής υπολογίζεται περίπου στο 27% [100]. Αν το έργο έχει αρχικό προϋπολογισμό 2.2 εκατομμύρια ευρώ, αυτό σημαίνει πως η εταιρία θα καταγράψει πρόσθετα έξοδα αξίας Επομένως, συνολικά το έργο παρουσιάζει επιπλέον κόστος αξίας δηλαδή 51% του αρχικού προϋπολογισμού. Τα συμπεράσματα στα οποία μπορεί να μας οδηγήσει το παραπάνω παράδειγμα είναι πως : α) οι εταιρίες πληροφορικής δεν είναι αρκετά ικανές στη διαχείριση του κόστους κάθε έργου καθώς και του χρόνου ολοκλήρωσής του, β) ένα έργο πληροφορικής δεν είναι εύκολο να περιοριστεί σε ένα σταθερό προϋπολογισμό. Σε περίπτωση που οι παραπάνω παραδοχές δεν βασίζονται στον μέσο όρο, το κόστος της κακής ποιότητας σχεδίασης είναι πιθανόν να εκτροχιαστεί σε πολλαπλάσια μεγέθη του αρχικού προϋπολογισμού. Είναι σαφές, πως όσο περισσότερη σημασία δίνει μια σχεδιαστική ομάδα στα ποιοτικά χαρακτηριστικά του λογισμικού που κατασκευάζει, τόσο καλύτερα αποτελέσματα θα έχει. Χαρακτηριστικά, οι Barry Boehm και Victor R. Basili περιγράφουν στο άρθρο τους "Software Defect Reduction Top 10 List", στατιστικά για τον αριθμό των σφαλμάτων που παρουσιάζονται κατά τη διάρκεια της ανάπτυξης [99]. Παραθέτουμε τα πιο σημαντικά. 1) Ο εντοπισμός και η επίλυση ενός προβλήματος λογισμικού, μετά την διάθεση του προϊόντος στην αγορά, είναι εκατό φορές πιο ακριβό από το να διορθωθεί κατά τη διάρκεια της φάσης σχεδίασης και καθορισμού των απαιτήσεων. 2) Στα έργα λογισμικού, το 40%-50% της σπατάλης του χρόνου οφείλεται στην προσπάθεια επίλυσης προβλημάτων τα οποία θα μπορούσαν να αποφευχθούν 3) Σχεδόν το 80% των προβλημάτων προέρχεται από 20% των σφαλμάτων 26

30 4) Μεθοδευμένες πρακτικές από τους υπαλλήλους, μπορούν να μειώσουν τα ελαττώματα κατά 75% 5) Το 40%-50% των προγραμμάτων περιέχουν τετριμμένα λάθη. 27

31 3 Μετρικές ποιότητας λογισμικού Ο Humphrey εκτιμά πως οι έμπειροι προγραμματιστές λογισμικού, ανά 1000 γραμμές κώδικα, έχουν 100 ή περισσότερα σφάλματα στον κώδικά τους, εκ των οποίων τα 50 εντοπίζονται αυτόματα [93]. Αν για ένα πρόγραμμα των γραμμών παρουσιάζονται πιθανές απειλές, πως μπορούν αυτές να εντοπιστούν πριν προκαλέσουν προβλήματα στην υλοποίηση του αρχικού σχεδίου; Αν για κάθε μια χρειαστεί ένας μέσος όρος πέντε ωρών για την επίλυσή τους, ο προϋπολογισμός του έργου κινδυνεύει να εκτροχιαστεί επικίνδυνα! Για την πρόληψη και αντιμετώπιση αυτού του προβλήματος, υπάρχουν εργαλεία που αυτοματοποιούν μεγάλο μέρος της διαδικασίας ελέγχου και δείχνουν χαρακτηριστικά της εσωτερικής δομής του προγράμματος που αλλιώς δεν γίνονται εύκολα αντιληπτά. Τα εργαλεία αυτά είναι οι μετρικές ποιότητας κώδικα. Η σημαντική τους συνεισφορά έγκειται στο ότι δίνουν ένα μετρήσιμο μέγεθος (αποτέλεσμα μετρικής) για ένα άυλο αντικείμενο (κώδικας). Αυτό το γεγονός τις καθιστά απαραίτητες, καθώς ο προγραμματιστής μπορεί να ποσοτικοποιήσει το αποτέλεσμα της εργασίας του και να έχει μια πιο ευκρινή εικόνα για την εξέλιξη του έργου. Συνήθως αφορούν τα εσωτερικά χαρακτηριστικά του προγράμματος. Επίσης δίνουν μια πολύ καλή εικόνα στους υπεύθυνους της εταιρίας για την εξέλιξη του έργου. Μπορούν να εμφανίσουν αποτελέσματα για την πρόοδο του project, αλλά και την παραγωγικότητα κάθε υπαλλήλου ξεχωριστά. Οι μετρικές ποιότητας εξετάζουν ένα σύνολο χαρακτηριστικών και όχι μόνο γραμμές κώδικα. Η πληροφορία που λαμβάνει η διοίκηση μπορεί να φανεί χρήσιμη τόσο για την πρόοδο του έργου όσο και για την στρατηγική της. Αν για παράδειγμα ένας χαρακτηριστικό του προγράμματος υστερεί αρκετά σε ποιότητα ή παρουσιάζει προβλήματα με αποτέλεσμα να χρειάζεται αρκετές εργατικές ώρες για να έχει την επιθυμητή συμπεριφορά, μπορεί να εγκαταλειφθεί και οι προσπάθειες της ομάδας να εστιαστούν σε άλλα χαρακτηριστικά. Από τα μέσα της δεκαετίας του 80, εξελίσσονται διαρκώς και κάθε μια παρέχει μια διαφορετική οπτική στην εσωτερική δομή του κώδικα. Εκτός από την στατική εικόνα, η οποία αποτυπώνει πληροφορίες για ένα έργο μια συγκεκριμένη χρονική στιγμή, παρέχει και μια συγκριτική εικόνα για την εξέλιξή του σε βάθος χρόνου. 28

32 Ας υποθέσουμε για παράδειγμα πως μια μετρική υπολογίζει τον αριθμό των διπλοτύπων που εμφανίζονται σε ένα project και τον βρίσκει ίσο με Χ το πρώτο τρίμηνο. Αν το project έχει έναν εκτιμώμενο χρόνο ολοκλήρωσης ίσο με 1 χρόνο και στους 6 μήνες ο αριθμός των διπλοτύπων είναι Χ/2, τότε αυτό σημαίνει πως η συγκεκριμένη παράμετρος βελτιώνεται και θα περιοριστεί σε μία επιθυμητή τιμή μέχρι το τέλος του project. Αν πάλι ο αριθμός των διπλοτύπων είναι σχεδόν ίδιος μετά από τρεις μήνες δουλειάς από την αρχική μέτρηση, αυτό σημαίνει πως χρειάζεται να γίνει σχετικά σύντομα επέμβαση για την αφαίρεσή τους, αλλιώς ο φόρτος θα αυξηθεί σημαντικά όσο πλησιάζει η προθεσμία ολοκλήρωσης. Παρότι έχουν αρκετά οφέλη η χρήση τους δεν είναι πανάκεια. Για παράδειγμα είναι δύσκολο να εντοπίσουν περιπτώσεις όπου υπάρχουν "bugs" ή υλοποίηση που δεν ανταποκρίνεται στον αρχικό σχεδιασμό. Αυτές οι δύο περιπτώσεις ευνοϊκά βρίσκονται και λύνονται στο στάδιο της ανάπτυξης και ελέγχου του λογισμικού, ενώ στην χειρότερη περίπτωση εντοπίζονται, όταν το λογισμικό διατεθεί στην αγορά. Επίσης, ενώ δίνουν πολλές χρήσιμες πληροφορίες για πιθανά σχεδιαστικά ελαττώματα, δεν εξασφαλίζουν πως το τελικό προϊόν θα είναι ποιοτικό. Η ποιότητα λογισμικού καλύπτει ένα ευρύ φάσμα απαιτήσεων που δεν είναι δυνατόν να εξασφαλιστεί μόνο με τη χρήση μετρικών. Όπως αναφέρθηκε και στο προηγούμενο παράδειγμα, η αξία των μετρικών ποιότητας έγκειται και στην αξιολόγηση του συγκριτικού αποτελέσματος. Δεν έχει νόημα να γίνει αναφορά στα αποτελέσματα μιας μόνο χρονικής στιγμής αν δεν υπάρχει ιστορικό προηγούμενων μετρήσεων που εξασφαλίζουν ένα σημείο αναφοράς για την πρόοδο του έργου. Για το λόγο αυτό είναι βασικό ο επιβλέπον της ανάπτυξης του λογισμικού να παρακολουθεί την εικόνα ανά τακτά χρονικά διαστήματα και να καταγράφει την εξέλιξή του. Επίσης στο στάδιο του σχεδιασμού, πριν τη χρήση μετρικών, η διεύθυνση πρέπει να αποφασίσει ποια ποιοτικά χαρακτηριστικά την ενδιαφέρει να μετρήσει, τουλάχιστον σε πρώτη φάση. Αφενός, έτσι εξασφαλίζεται η εστίαση των προσπαθειών στα πιο σημαντικά προβλήματα, αφετέρου γίνεται έγκαιρη επιλογή των εργαλείων που υπολογίζουν τα επιλεγμένα μετρήσιμα μεγέθη. Η στοχοθεσία είναι ιδιαίτερα σημαντική καθώς χωρίς αυτή ο προγραμματιστής κινδυνεύει να χαθεί σε μια αέναη μάχη για να παραδώσει ένα άρτιο προϊόν ξεχνώντας τον αρχικό του στόχο. 29

33 3.1 Κατηγορίες μετρικών Κάνοντας μια σύνοψη της βιβλιογραφίας από [1] έως [87], οι μετρικές που βρέθηκαν, καλύπτουν ένα ευρύ φάσμα λειτουργικότητας. Εξετάζουν παραμέτρους όπως το μέγεθος του προγράμματος, τα σχόλια, τη χρήση κληρονομικότητας, τη σύνδεση μεταξύ κλάσεων, τη χρήση πλεονασμών κ.ο.κ. και σε διαφορετικά επίπεδα ιεραρχίας (επίπεδο project, επίπεδο πακέτου, κλάσης, μεθόδου κ.λ.π.). Δεν κρίνεται σκόπιμο να αναφερθούν όλες, παρά μόνο οι πιο σημαντικές εξ αυτών. Για περισσότερες πληροφορίες σχετικά με το σύνολο των μετρικών που έχουν προταθεί, ο αναγνώστης ενθαρρύνεται να ανατρέξει στην βιβλιογραφία CK Metrics Suite Ξεκινώντας από την CK metrics suite, οι Chidamber and Kemerer περιέγραψαν ένα σύνολο έξι μετρικών, οι οποίες είχαν μεγάλη αποδοχή και εμφανίζονται στην βιβλιογραφία μέχρι σήμερα [14] [15]. Συγκεκριμένα είναι οι: Weighted Methods per Class (WMC) Έστω μια κλάση C1 μέσα στην οποία ορίζονται μέθοδοι M1 έως Mn. Έστω c1 έως cn η πολυπλοκότητα των μεθόδων. Τότε ορίζουμε : Από αυτή την μετρική εξάγονται τρία συμπεράσματα: Ο αριθμός και η πολυπλοκότητα των μεθόδων αποτελούν μια ένδειξη του χρόνου που θα χρειαστεί για την ανάπτυξη και τη συντήρηση μιας κλάσης. Όσο μεγαλύτερος είναι ο αριθμός των μεθόδων σε μια κλάση, τόσο μεγαλύτερη επίδραση θα έχει η κλάση αυτή στους απογόνους της, αφού αυτοί θα την κληρονομήσουν. 30

34 Κλάσεις με μεγάλο αριθμό μεθόδων είναι πιο πιθανό να εστιάζουν σε μια μόνο εφαρμογή, περιορίζοντας την πιθανότητα επαναχρησιμοποίησής τους. DIT (Depth of Inheritance Tree) Η μετρική DIT εστιάσει στην απόσταση που έχει μια κλάση από την ρίζα του δέντρου. Για παράδειγμα, δοσμένης μια κλάση Α που κληρονομεί τα χαρακτηριστικά της στις επόμενες π.χ. Α->Β->Γ->Δ, τότε το DIT( Δ ) = 3. Από αυτή την μετρική εξάγονται τρία συμπεράσματα[14] : Όσο πιο βαθιά είναι μια κλάση στο δέντρο της ιεραρχίας, τόσο μεγαλύτερος θα είναι ο αριθμός των μεθόδων που κληρονομεί. Δέντρα που έχουν μεγαλύτερο βάθος σχετίζονται με μεγαλύτερη πολυπλοκότητα στη σχεδίαση, αφού μετέχουν περισσότερες κλάσεις και μέθοδοι. Όσο πιο βαθιά είναι μια κλάση στην ιεραρχία, τόσο μεγαλύτερη είναι η πιθανότητα χρήσης κληρονομημένων μεθόδων. Number of Children (ΝΟC) Η NOC αναφέρεται στους άμεσους απόγονους μια κλάσης. Δηλαδή, πόσες κλάσεις θα κληρονομήσουν τα χαρακτηριστικά μιας κλάσης Χ (σε πρώτο επίπεδο). Από αυτή την μετρική εξάγονται τρία συμπεράσματα[14] : Όσο μεγαλύτερη είναι η τιμή της NOC, τόσο πιο διαδεδομένη είναι η επαναχρησιμοποίηση, αφού η κληρονομικότητα αποτελεί ένα είδος επαναχρησιμοποίησης. 31 Όσο μεγαλύτερη είναι η τιμή της NOC, τόσο αυξάνουν οι πιθανότητες να υπάρχει κακός σχεδιασμός και να γίνεται κακή χρήση κληρονομικότητας.

35 Όσο μεγαλύτερη είναι η τιμή της NOC, τόσο μεγαλύτερη είναι η επιρροή της κλάσης αυτής στο συνολικό πρόγραμμα και επομένως θα πρέπει να ετοιμαστούν περισσότερα σενάρια ελέγχου. Coupling Between Object classes (CBO) H CBO, μετράει το σύνολο των κλάσεων με τις οποίες μια κλάση Χ είναι συζευγμένη. Δηλαδή αν η Χ καλεί μεθόδους ή τοπικές μεταβλητές μιας άλλης κλάσης, τότε η τιμή της CBO αυξάνεται κατά ένα. Από αυτή την μετρική εξάγονται τρία συμπεράσματα: Όσο μεγαλύτερη σύζευξη υπάρχει μεταξύ δύο κλάσεων, τόσο δυσκολότερη είναι η επαναχρησιμοποίηση. Η σωστή σχεδίαση απαιτεί χαλαρή σύζευξη μεταξύ των κλάσεων και πιο συχνή χρήση της ενθυλάκωσης. Έτσι, η ευαισθησία στις αλλαγές είναι μικρότερη και το 77πρόγραμμα είναι πιο εύκολο να συντηρηθεί. Η CBO είναι χρήσιμη για να τον καθορισμό της πολυπλοκότητας των ελέγχων που θα πραγματοποιηθούν σε μία κλάση. Response For a Class (RFC) Ως RFC μιας κλάσης ορίζεται το σύνολο των μεθόδων που μπορούν να εκτελεστούν μετά την λήψη ενός μηνύματος από αντικείμενο της ίδιας κλάσης. Το μέγεθος της μετρικής αποτελεί έναν δείκτη για το σύνολο των αντικειμένων μιας κλάσης. Από αυτή την μετρική εξάγονται τρία συμπεράσματα: 32 Αν ένας μεγάλος αριθμός μεθόδων κληθούν μετά από ένα μήνυμα, ο έλεγχος και η αποσφαλμάτωση της κλάσης γίνεται πιο περίπλοκη, αφού χρειάζεται βαθύτερη κατανόηση της λειτουργίας της από τον προγραμματιστή που θα την ελέγξει.

36 Όσο μεγαλύτερος είναι ο αριθμός των μεθόδων που καλούνται από μια κλάση, τόσο μεγαλύτερη είναι η πολυπλοκότητά της. Η χρήση ενός κάτω ορίου στην RFC, θα βοηθήσει στην καλύτερη διαχείριση του χρόνου προς διάθεση για τον έλεγχο μιας κλάσης. Lack of Cohesion in Methods (LCOM) Η LCOM υπολογίζει την έλλειψη συνεκτικότητας των μεθόδων μιας κλάσης. Επειδή η συγκεκριμένη μετρική έχει χαρακτηριστεί ως αναξιόπιστη από την επιστημονική κοινότητα, έχουν δημιουργηθεί άλλες τρεις μετρικές που υπολογίζουν το ίδιο μέγεθος. Ξεχωρίζεται σαν LCOM1 και υπολογίζεται ως : LCOM1 = Όπου P είναι το σύνολο των μεθόδων μιας κλάσης το οποίο δεν παρουσιάζει συνεκτικότητα και Q ορίζεται το σύνολο των μεθόδων της ίδιας κλάσης που παρουσιάζουν συνεκτικότητα. Αν η τιμή της LCOM1 είναι ίση με μηδέν σημαίνει πως η κλάση παρουσιάζει υψηλή σύζευξη. Διαφορετικά η κλάση πρέπει να χωριστεί σε δυο ή περισσότερες υποκλάσεις. Από αυτή την μετρική εξάγονται τέσσερα συμπεράσματα[14] : 1) Η συνεκτικότητα μέσα σε μία κλάση είναι επιθυμητή, καθώς προάγει την ενθυλάκωση. 2) Η έλλειψη συνεκτικότητας συνεπάγεται ότι μια κλάση θα πρέπει να διασπαστεί σε δυο ή περισσότερες. 3) Κάθε μέτρηση που υποδεικνύει ανομοιογένεια, βοηθάει στην εύρεση ελαττωμάτων στον σχεδιασμό μιας κλάσης. 4) Η χαμηλή συνεκτικότητα αυξάνει την πολυπλοκότητα και επομένως αυξάνει την πιθανότητα εμφάνισης σφαλμάτων κατά την ανάπτυξη του λογισμικού. 33

37 Παρακάτω ακολουθεί μια έρευνα της NASA [101] η οποία έγινε χρησιμοποιώντας τις CK μετρικές. Η ανάλυση περιλαμβάνει την ανάλυση τριών ειδών λογισμικού : εμπορικού κώδικα που γράφτηκε σε Java, κώδικα Java γραμμένο από την NASA και κώδικα C++ γραμμένο από την NASA και τις τιμές που βρέθηκαν. Όπως φαίνεται και από τον πίνακα 1, όσο υψηλότερες είναι οι τιμές της CBO της WMC και της LCOM, τόσο χαμηλότερη είναι η ποιότητα του λογισμικού. Systems Analyzed Java Commercial Java NASA Software C++ NASA Software Classes Lines Quality Low High Medium CBO LCOM RFC NOC DIT WMC Πίνακας 1: Έρευνα της NASA για τον υπολογισμό τιμών των CK μετρικών MOOD Metrics Suite Οι μετρικές MOOD, που ορίζονται από τον Fernando Brito e Abreu [102], έχουν σχεδιαστεί για να παρέχουν μια σύνοψη της συνολικής ποιότητας ενός έργου, το οποίο βασίζεται σε αντικειμενοστραφείς γλώσσες προγραμματισμού και αποτελείται από έξι μετρικές. Method Hiding Factor (MHF) Η MHF ορίζεται ως το σύνολο των private μεθόδων μιας κλάσης προς το σύνολο των μεθόδων της κλάσης αυτής. Αν όλες οι μέθοδοι δηλωθούν σαν private, τότε η τιμή της MHF είναι 100% και επομένως η λειτουργικότητα και η δυνατότητα επαναχρησιμοποίησης της κλάσης αυτής είναι χαμηλή. Αν όλες δηλωθούν σαν public, τότε η τιμή της είναι 0% και αυξάνεται η πιθανότητα εμφάνισης σφαλμάτων [109]. 34

38 Συνίσταται ότι η MHF δεν πρέπει να είναι μικρότερη από μία συγκεκριμένη τιμή και δεν υπάρχει ανώτατο όριο. Με άλλα λόγια προτείνεται, όλοι οι μέθοδοι σε μία κλάση να δηλώνονται ως private. [63] Attribute Hiding Factor (AHF) Η ΑHF ορίζεται ως το σύνολο των private μεταβλητών μιας κλάσης προς το σύνολο των μεταβλητών της κλάσης αυτής. Αν όλες οι μεταβλητές δηλωθούν σαν private, τότε η τιμή της ΑHF είναι 100% και επομένως η λειτουργικότητα και η δυνατότητα επαναχρησιμοποίησης της κλάσης είναι χαμηλή. [109] Method Inheritance Factor (MIF) H MIF ορίζεται ως το άθροισμα όλων των κληρονομημένων μεθόδων στο σύνολο των κλάσεων, προς το άθροισμα του συνόλου των μεθόδων που περιλαμβάνονται σε αυτές. Μία κλάση που κληρονομεί ένα μεγάλο σύνολο μεθόδων από την υπερκλάση της, αυξάνει τον δείκτη MIF. Όταν μια κλάση κάνει override στις μεθόδους της υπερκλάσης της, τότε μειώνει τον δείκτη MIF. Η επιθυμητή τιμή της MIF κυμαίνεται ανάμεσα σε 20% και 80% [109]. Attribute Inheritance Factor (AIF) H AIF ορίζεται ως το άθροισμα όλων των κληρονομημένων μεταβλητών στο σύνολο των κλάσεων, προς το άθροισμα του συνόλου των μεταβλητών που περιλαμβάνονται σε αυτές. Μία κλάση που κληρονομεί ένα μεγάλο σύνολο μεταβλητών από την υπερκλάση της, αυξάνει τον δείκτη ΑIF. Όταν μια κλάση κάνει override τις μεταβλητές της υπερκλάσης της, τότε μειώνει τον δείκτη ΑIF. Η επιθυμητή τιμή της ΑIF κυμαίνεται ανάμεσα σε 0% και 48% [109]. Polymorphism Factor (PF) H PF ορίζεται ως το άθροισμα των overrides στο σύνολο των κλάσεων, προς το σύνολο των μέγιστων δυνατών overrides. Είναι ένας δείκτης του βαθμού χρήσης των overrides από τις υποκλάσεις. Οι τιμές που μπορεί να πάρει κυμαίνονται από 0% έως 100% [109]. 35

39 Coupling Factor (CF) H CF υπολογίζει τον αριθμό των συζεύξεων μεταξύ των κλάσεων, προς τον μέγιστο αριθμό πιθανών συζεύξεων. Όταν γίνεται χρήση κληρονομικότητας, η CF δεν προσμετρά αυτές τις περιπτώσεις γιατί εμφανίζεται μεγάλος βαθμός σύζευξης ανάμεσα στις υπερκλάσεις - υποκλάσεις. Υψηλές τιμές της CF δεν είναι επιθυμητές, καθώς υποδηλώνουν υψηλή σύζευξη για το σύστημα [109][63] Lorenz and Kidd Metrics Suite Οι Lorenzz και Kidd παρουσίασαν ένα μεγάλο πλήθος μετρικών για την εκτίμηση της ποιότητας λογισμικού. Αυτές μπορούν να χωριστούν σε δυο κατηγορίες, τις Class size metrics και Class inheritance metrics, οι οποίες παρέχουν πληροφορίες σε επίπεδο κλάσης και χρήσης της κληρονομικότητας αντιστοίχως. Αναλυτικά [37][63] : Class Size metrics NM (number of methods) : Η NM υπολογίζει το πλήθος των μεθόδων μιας κλάσης. Υψηλότερες τιμές της μετρικής είναι ένδειξη πως η κλάση που εξετάζεται παρέχει μεγάλο βαθμό λειτουργικότητας. PM (number of public method) : H PM μετρά το σύνολο των public μεθόδων μιας κλάσης. NV (number of variables per class) : Η NV μετρά το σύνολο των μεταβλητών που περιέχει μια κλάση. Συνολικά αθροίζει το σύνολο των public, protected και private μεταβλητών. NPV (number of public variables per class) : H NPV υπολογίζει το σύνολο των public μεθόδων μιας κλάσης. Υψηλότερες τιμές της μετρικής είναι ένδειξη πως η κλάση που εξετάζεται επικοινωνεί με άλλες κλάσεις και επομένως έχει βαρύνουσα σημασία στο πρόγραμμα. 36

40 Class Inheritance metrics NMO (Number of methods overridden by a subclass) : Η ΝΜΟ υπολογίζει το σύνολο των μεθόδων που γίνονται override από το σύνολο των υποκλάσεων. Σύμφωνα με τους Lorenzz και Kidd, όσο μεγαλύτερη είναι η τιμής της ΝΜΟ, τόσο αυξάνεται το ενδεχόμενο η σχεδίαση να είναι προβληματική. NMI (Number of methods inherited by a subclass) : H NMI υπολογίζει τον αριθμό των μεθόδων που κληρονομούνται από μια υποκλάση. ΝΜΑ (Number of methods added by a subclass) : H NMA υπολογίζει το σύνολο των μεθόδων που προσθέτει μια υποκλάση, σε αυτές που κληρονομεί από την υπερκλάση της. Σε αυτές δεν περιλαμβάνονται όσες μέθοδοι έχουν το ίδιο όνομα με αυτές της υπερκλάσης. SIX (Specialization index) : Η μετρική SIX υπολογίζει τον βαθμό στον οποίο οι υποκλάσεις επαναπροσδιορίζουν την συμπεριφορά των υπερκλάσεών τους. Ορίζεται ως SI = (NMO * Level) / M total, όπου η Level ορίζει την ιεραρχία της κλάσης και M total είναι το σύνολο των μεθόδων της κλάσης Άλλες χρήσιμες μετρικές Εκτός των μετρικών που αναλύθηκαν στις προηγούμενες ενότητες και είναι οι πιο διαδεδομένες, υπάρχει ένα σύνολο άλλων που θα αναφερθούν συνοπτικά. Αυτές είναι [41][63]: Code percentage (CP) : η αναλογία των σχολίων σε ένα πρόγραμμα. Lines of Code (LOC) : ο αριθμός των γραμμών κώδικα σε ένα πρόγραμμα. McCabe's cyclomatic complexity (CC) : υπολογίζει τον διακριτό αριθμό ελέγχων που χρειάζεται να πραγματοποιηθούν σε μια μέθοδο και υπολογίζεται με την χρήση γράφων. Afferent Coupling (Ca) : o αριθμός των κλάσεων εκτός πακέτου, που εξαρτάται από κλάσεις εντός πακέτου. 37

41 Efferent Coupling (Ce) : o αριθμός των κλάσεων εντός πακέτου, που εξαρτάται από κλάσεις εκτός πακέτου. 3.2 Μετρικές κληρονομικότητας Στην προηγούμενη ενότητα αναλύθηκαν οι πιο διαδεδομένες μετρικές που χρησιμεύουν στην εκτίμηση της ποιότητας του παραγόμενου λογισμικού. Ανάμεσά τους υπήρχαν και αρκετές οι οποίες αφορούσαν περιπτώσεις κληρονομικότητας, όπως οι MIF,AIF και οι Class Inheritance metrics των Lorenz και Kidd. Στο παρόν κεφάλαιο θα γίνει αναφορά σε λιγότερο γνωστές μετρικές κληρονομικότητας. Class Inheritance Complexity Measure (CISM) H CISM είναι ένα μέτρο της πολυπλοκότητας μιας κλάσης, το οποίο εξαρτάται από την κληρονομικότητα των στοιχείων της στους απογόνους. Όσο αυξάνει το βάθος της ιεραρχίας, υπάρχουν περισσότερες υποκλάσεις που κληρονομούν τα στοιχεία της αρχικής κλάσης και επαναχρησιμοποιούν τον κώδικά της. Βέβαια, η αρχική κλάση μπορεί να μην είναι μόνο μια. Μπορεί να υπάρχει πολλαπλή κληρονομικότητα, μονή ή πολλαπλών επιπέδων. Σε κάθε περίπτωση η CICM υπολογίζει την πολυπλοκότητα κάθε κλάσης ξεχωριστά, βάσει του διαφορετικού τύπου κληρονομικότητας που χρησιμοποιείται [57]. Η τιμή της ορίζεται ως : CICM = όπου το n είναι ίσο με τον αριθμό των άμεσων προγόνων της κλάσης και το Ri ισούται με την τιμή της CICM στον i κόμβο της ιεραρχίας. Class Complexity due to inheritance (CCI) H CCI είναι ένα μια μετρική που υπολογίζει την πολυπλοκότητα μιας κλάσης λόγω κληρονομικότητας και ορίζεται ως [22]: 38 CCI i =

42 Όπου : CCIi είναι η πολυπλοκότητα της iοστής κλάσης λόγω κληρονομικότητας k είναι ο αριθμός των κλάσεων, τα στοιχεία των οποίων κληρονομεί η iοστή κλάση CCIifrom είναι η πολυπλοκότητα της γονικής κλάσης, τα στοιχεία της οποίας κληρονομεί η iοστή κλάση l είναι ο αριθμός των μεθόδων της iοστής κλάση MCj είναι η πολυπλοκότητα της jοστής μεθόδου στην iοστή κλάση Όπως προκύπτει και από την ανάλυση των παραγόντων, η CCI υπολογίζει και την πολυπλοκότητα των μεθόδων της κλάσης. Παρότι φαίνεται να είναι πιο ακριβής από την CISM, παρουσιάζει αρκετά μεγαλύτερη πολυπλοκότητα. Average Complexity of a program due to Inheritance (ACI) H συγκεκριμένη μετρική υπολογίζει την μέση πολυπλοκότητα της CCI ως [22]: ACI = Όπου : n είναι ο συνολικός αριθμός των κλάσεων του προγράμματος CCI i είναι η πολυπλοκότητα λόγω κληρονομικότητας της iοστής κλάσης του προγράμματος Derive Base Ratio Metric (DBRM) Σαν DBRM ορίζεται το πηλίκο του συνόλου των παραγόμενων κλάσεων προς το σύνολο των υπερκλάσεών τους. Συγκεκριμένα η DBRM ορίζεται ως [49]: DBRM = Όπου ο αριθμητής ισούται με το σύνολο των παραγόμενων κλάσεων στο βάθος της ιεραρχίας και ο παρανομαστής με το σύνολο των υπερκλάσεών τους. Όσο περισσότερες παραγόμενες κλάσεις υπάρχουν, τόσο μεγαλύτερος είναι ο βαθμός επαναχρησιμοποίησης. 39

43 Average Number of Direct Child Metric (ANDC) Σαν ΑΝDC ορίζεται το πηλίκο του συνόλου των άμεσων απογόνων μιας κλάσης, προς το σύνολο των κλάσεων στο δέντρο της ιεραρχίας. Συγκεκριμένα η ΑΝDC ορίζεται ως [49]: ANDC = Με τον αριθμητή να ισούται με το σύνολο των άμεσων απογόνων στο δέντρο της ιεραρχίας και με τον παρανομαστή να είναι ίσος με το σύνολο των κλάσεων που περιλαμβάνονται στο δέντρο της ιεραρχίας. Η ANDC απαριθμεί το σύνολο των άμεσων απογόνων που θα κληρονομήσουν τα χαρακτηριστικά των προγόνων τους και δίνει μια ένδειξη του βαθμού στον οποίο επηρεάζει μια κλάση την συνολική σχεδίαση. Average Number of Indirect Child (ANIC) Σαν ΑΝIC ορίζεται το πηλίκο του συνόλου των έμμεσων απογόνων μιας κλάσης, προς το σύνολο των κλάσεων στο δέντρο της ιεραρχίας. Συγκεκριμένα η ANΙC ορίζεται ως [49]: ANΙC = Με τον αριθμητή να ισούται με το σύνολο των έμμεσων απογόνων στο δέντρο της ιεραρχίας και με τον παρανομαστή να είναι ίσος με το σύνολο των κλάσεων που περιλαμβάνονται στο δέντρο της ιεραρχίας. Τα συμπεράσματα που προκύπτουν από των ANΙC είναι πως όσο βαθύτερο είναι το δέντρο της ιεραρχίας, τόσο μεγαλύτερη είναι η πολυπλοκότητα, αφού εμπλέκονται περισσότερες κλάσεις. Επίσης όσο βαθύτερα είναι μια κλάση στο δέντρο της ιεραρχίας, τόσο μεγαλύτερος είναι ο αριθμός των κληρονομούμενων μεθόδων και επομένως είναι πιο δύσκολο να προβλεφθεί η συμπεριφορά της. Εκτός των μετρικών που αναφέρθηκαν, υπάρχει ένα σύνολο άλλων που απαριθμεί απλές δομές. Συγκεκριμένα αυτές είναι [86]: Average Depth of Inheritance (ADI) : υπολογίζεται ως το άθροισμα του βάθους όλων των δέντρων ιεραρχίας, προς τον αριθμό των κλάσεων. 40

44 Average Number of Ancestors (ANA) : ορίζεται ως ο μέσος αριθμός απογόνων στο σύνολο των κλάσεων Factoring Effectiveness (FEF) : ορίζεται ως το σύνολο των μοναδικών μεθόδων, προς το σύνολο των μεθόδων FAN-IN (FIN) : ορίζεται ως ο αριθμός των κλάσεων, τις οποίες μια κλάση κληρονομεί. Όσο μεγαλύτερη είναι η τιμή της, υποδηλώνει πως γίνεται κακή χρήση κληρονομικότητας. Class Hierarchy Nesting Level (HNL) : υπολογίζει το βάθος της ιεραρχίας κάθε κλάσης Method Reuse metrics (MRE) : προσδιορίζει τον βαθμό επαναχρησιμοποίησης μεθόδων. Number of Children (NOC) : υπολογίζει το σύνολο των απογόνων μιας κλάσης. Ratio between Depth and Breadth (RDB) : είναι το πηλίκο ανάμεσα στο βάθος και το πλάτος του δέντρου ιεραρχίας. Reuse Ratio (RΕR) : ορίζεται ως το πηλίκο του αριθμού των υπερκλάσεων, προς το σύνολο των κλάσεων. Specialization Ratio (SPR) : ορίζεται ως το πηλίκο των υποκλάσεων, προς τον αριθμό των υπερκλάσεων 3.3 Συμπεράσματα βιβλιογραφικής έρευνας Εξετάζοντας το σύνολο των μετρικών στο κεφάλαιο 3, διακρίνεται πως αν και η κληρονομικότητα αποτελεί μία από τις πλέον βασικές έννοιες του αντικειμενοστραφούς προγραμματισμού, δεν υπάρχουν αρκετά εργαλεία για να ποσοτικοποιήσουν το εύρος των ποιοτικών της χαρακτηριστικών. Η πλειοψηφία των μετρικών που εξετάστηκαν αναφέρονται σε μια απλή απαρίθμηση δομών, όπως : ο αριθμός των κληρονομούμενων μεθόδων μιας κλάσης, σχέσεις αναλογίας μεταξύ υπερκλάσεων και υποκλάσεων, βαθμός πολυπλοκότητας στην χρήση κληρονομικότητας, αριθμός και τύπος απογόνων κ.λ.π. οι οποίες δεν δίνουν επαρκείς πληροφορίες για τις επιπτώσεις του τρόπου χρήσης της κληρονομικότητας στη σχεδίαση. Μετρικές που βάση των συμπερασμάτων που αναφέρθηκαν, μπορούν να παρέχουν κάποιες ενδείξεις για την ποιότητα της σχεδίασης είναι : 41

45 η μετρική MIF, η οποία μπορεί να προσφέρει πληροφορίες για την χρήση της κληρονομικότητας. Αν κληρονομείται μεγάλος αριθμός μεθόδων, σημαίνει πως ενδεχομένως η χρήση της κληρονομικότητας δεν γίνεται με σωστό τρόπο και πρέπει να επανασχεδιαστούν οι κλάσεις που εμφανίζουν πρόβλημα. η μετρική ΝΜΟ, η οποία όσο μεγαλύτερη τιμή έχει, είναι ένδειξη πως η χρήση της κληρονομικότητας δεν γίνεται με ορθό τρόπο και πρέπει να επανασχεδιαστούν οι κλάσεις που εμφανίζουν πρόβλημα. η μετρική CISM, η οποία παρέχει πληροφορίες για την πολυπλοκότητα μιας κλάσης και αν αυτή είναι μεγάλη, κληρονομεί ένα μεγάλο αριθμό στοιχείων, επομένως έχει βαρύνουσα σημασία για το πρόγραμμα. Επίσης παρατηρείται ένα κενό στην ανάδειξη "καλών πρακτικών" στην χρήση κληρονομικότητας, όπως η υλοποίηση αφηρημένων abstract μεθόδων (μεθόδων χωρίς υλοποίηση). Για τον σκοπό αυτό, όπως εξηγείται αναλυτικά και στο κεφάλαιο 4, προτείνεται ένα σύνολο μετρικών που υπολογίζουν τις παραπάνω έννοιες και δίνουν μια εικόνα στον χρήστη για την ποιότητα σχεδίασης του project. 42

46 4 Προτάσεις μετρικών κληρονομικότητας Στο κεφάλαιο 3 εξετάστηκε το πιο αντιπροσωπευτικό μέρος των μετρικών της βιβλιογραφίας. Όπως διαπιστώθηκε, η πλειοψηφία των μετρικών που αφορούν την κληρονομικότητα, δεν παρέχει ουσιαστικές πληροφορίες για την σχεδίαση, αλλά αναλώνεται στην απαρίθμηση δομών. Επίσης, ο αριθμός των μεγεθών που χρησιμοποιείται για την εξαγωγή συμπερασμάτων είναι πολύ περιορισμένος με αποτέλεσμα να γίνεται ανακύκλωση στη χρήση τους από διαφορετικούς συγγραφείς. Αντίθετα, υπάρχουν μεγέθη κληρονομικότητας τα οποία χρησιμοποιούνται συχνά, όπως η κλήση super, η χρήση abstract μεθόδων ή λιγότερο συχνά όπως η template μέθοδος, τα οποία μπορούν να παρέχουν συμπεράσματα στον προγραμματιστή για την ποιότητα της σχεδίασής του και παραμένουν ανεκμετάλλευτα. Για το λόγο αυτό προτείνεται μια σειρά νέων μετρικών που έχουν σαν στόχο να δώσουν τα εργαλεία στον χρήστη, ώστε να βελτιώσει την ποιότητα του έργου του. Πριν γίνει αναφορά όμως στις νέες μετρικές, είναι σημαντικό να γίνει μια σύντομη επισκόπηση των στοιχείων που τις αποτελούν. 4.1 Μέθοδος υπόδειγμα - Template Method Η μέθοδος υπόδειγμα ανήκει στην κατηγορία των design patterns, τεχνικών που έχουν σαν στόχο να λύσουν κοινά σχεδιαστικά προβλήματα. Κατατάσσεται στα εξειδικευμένα προγραμματιστικά εργαλεία, τα οποία παρέχουν ευελιξία στον προγραμματιστή για την απλοποίηση σύνθετων προβλημάτων. Συγκεκριμένα, η μέθοδος υπόδειγμα με την οποία θα ασχοληθούμε, δηλώνεται σαν concrete μέθοδος στο σώμα μιας αφηρημένης κλάσης. Μέσα στην concrete μέθοδο ορίζεται η σειρά κλήσης abstract και concrete μεθόδων της κλάσης και από τις υποκλάσεις παρέχεται υλοποίηση των abstract μεθόδων που κληρονομούνται. Όταν η υποκλάση καλέσει την template μέθοδο, αυτή με τη σειρά της καλεί με συγκεκριμένη σειρά το σύνολο των μεθόδων που περιλαμβάνει, ανάμεσά τους και τις abstract μεθόδους που ορίστηκαν στην υποκλάση. 43

47 Χρησιμοποιείται σε περιπτώσεις όπου υπάρχει ένας προκαθορισμένος αριθμός βημάτων σε έναν αλγόριθμο, αλλά ο τρόπος εφαρμογής των βημάτων μπορεί να διαφέρει. Η χρήση της template μεθόδου εξασφαλίζει την σειρά εκτέλεσης των βημάτων του αλγορίθμου και αφήνει το περιθώριο αλλαγής της συμπεριφοράς στην υποκλάση. Επίσης εφαρμόζεται όταν μπορούν να αποφευχθούν διπλότυπα κώδικα και η κοινή υλοποίηση των υποκλάσεων μεταφέρεται στην υπερκλάση. Αναλυτικά τα βήματα που περιγράφουν μια template μέθοδο είναι [110][103] : ορίζεται στο σώμα μιας abstract κλάσης στο σώμα αυτής τη κλάσης ορίζονται οι abstract μέθοδοι, με σκοπό να υλοποιηθούν στις υποκλάσεις που τις κληρονομούν μέσα στην abstract κλάση, ορίζεται μια concrete μέθοδος, η οποία καθορίζει την σειρά κλήσης των abstract μεθόδων από τις υποκλάσεις και ονομάζεται template μέθοδος μια template μέθοδος περιέχει δυο ή περισσότερες μοναδικές abstract μεθόδους μπορούν να οριστούν concrete μέθοδοι μέσα στην template μέθοδο και συνήθως έχουν βοηθητικό ρόλο. Έχει τα εξής χαρακτηριστικά : Υλοποιεί την αρχή του Hollywood, (don't call us, we will call you). Δηλαδή, η κλήση της κληρονομημένης template μεθόδου στην υποκλάση προκαλεί κλήσεις των μεθόδων της υποκλάσης. Προωθεί την επαναχρησιμοποίηση κώδικα, καθώς η υπερκλάση ορίζει ένα σχεδιαστικό πρότυπο και ένα σύνολο abstract μεθόδων, οι οποίες αποκτούν συμπεριφορά στις υποκλάσεις. Η concrete μέθοδος δεν πρέπει να γίνεται override από την υποκλάση Τα παραδείγματα Α αναπαριστά την χρήση template μεθόδου. Α) public abstract class AnotherAbstractClass { public final void templatemethod() { 44

48 } } int initial = 10; step1(); step2(); step3(); protected void step1() { System.out.println("Hello World!"); } protected abstract int step2(); protected abstract int step3(); 4.2 Κλήσεις super και overrides Η χρήση της υποκατάστασης (override) γίνεται όταν δοσμένης μιας υποκλάσης δηλώνονται σε αυτή μέθοδοι, που έχουν το ίδιο όνομα, τις ίδιες παραμέτρους και τον ίδιο τύπο επιστροφής, με τουλάχιστον μια από τις μεθόδους της υπερκλάσης. Στο παράδειγμα που ακολουθεί, η RandomMethod της Subclass υποκαθιστά την μέθοδο RandomMethod της Superclass. Η υποκατάσταση χρησιμοποιείται όταν μια μέθοδος της υποκλάσης χρειάζεται να διαφοροποιήσει τη συμπεριφορά της ή να προσθέσει λειτουργικότητα σε μια μέθοδο της υπερκλάσης. Η χρήση της υποκατάστασης είναι μια επιθυμητή συνθήκη, αρκεί η χρήση της να μην ακυρώνει ολόκληρη την συμπεριφορά της υπερκλάσης. H χρήση της λέξης super χρησιμοποιείται στην περίπτωση που καλείται μέθοδος της υπερκλάσης η οποία υποκαθίσταται στην υποκλάση. Κατά την χρήση της κληρονομικότητας, μια υπερκλάση μπορεί να υποκατασταθεί με σκοπό την προσθήκη λειτουργικότητας από την υποκλάση και επομένως χάνει τη λειτουργικότητά της. Για το λόγο αυτό καλείται η super μέθοδος, ώστε να αποκαταστήσει την λειτουργικότητα της υπερκλάσης. Στο παρακάτω παράδειγμα, φαίνεται πως η μέθοδος RandomMethod έχει δηλωθεί τόσο στην Superclass όσο και στην Subclass. Όταν κληθεί η RandomMethod της Subclass, αυτή θα εκτυπώσει τα παρακάτω μηνύματα διαδοχικά : Printed from RandomMethod in Superclass 45

49 Printed from RandomMethod in Subclass public class Superclass { public void RandomMethod() { System.out.println("Printed from RandomMethod in Superclass."); } } public class Subclass extends Superclass { public void RandomMethod() { super.randommethod (); System.out.println("Printed from RandomMethod in Subclass"); } } Σύμφωνα με τον Martin Fowler, η χρήση της super μεθόδου είναι ένδειξη κακής σχεδίασης, η οποία παρατηρείται συνήθως στην χρήση frameworks [115]. Στην περίπτωση που μια υποκλάση θέλει να επεκτείνει την λειτουργικότητα της υπερκλάσης, είναι προτιμότερο η μέθοδος της υπερκλάσης να οριστεί σαν μέθοδος υπόδειγμα και μέσα στο σώμα της να περιλαμβάνει δυο μεθόδους. Η μια θα παρέχει υλοποίηση που θα κληρονομούν όλες οι υποκλάσεις, ενώ η άλλη θα είναι χωρίς υλοποίηση ώστε να υποκατασταθεί. 4.3 Προτάσεις μετρικών Στα κεφάλαια 4.1 και 4.2 έγινε αναφορά σε βασικές έννοιες (template μέθοδος, κλήση super και χρήση override) που σχετίζονται με την κληρονομικότητα και δεν τυχαίνουν της ανάλογης προσοχή στην υπάρχουσα βιβλιογραφία. Για παράδειγμα δεν υπάρχει μετρική, η οποία να υπολογίζει την υποκατάσταση abstract μεθόδων έναντι όσων έχουν υλοποίηση. Επομένως ένα κομμάτι της κληρονομικότητας, από το οποίο μπορούν να βγουν χρήσιμα συμπεράσματα, παραμένει ανεκμετάλλευτο. Το σημαντικό κενό που υπάρχει, ελπίζουμε πως θα καλυφθεί με την παρούσα εργασία και τις μετρικές που προτείνονται. 46

50 4.3.1 Templateability (TILT) Η πρώτη από τις τρεις μετρικές, αναφέρεται στην χρήση template μεθόδου. Αφού εντοπιστεί η ύπαρξη template μεθόδων σε ένα πρόγραμμα, υπολογίζεται ο συνολικός αριθμός των μοναδικών abstract και concrete μεθόδων που περιλαμβάνονται στο σώμα τους και επιστρέφεται ένα κλάσμα το οποίο δηλώνει τον βαθμό χρήσης τους στο project. Συγκεκριμένα η TILT ορίζεται ως ο αριθμός των abstract μεθόδων που καλούνται στο σώμα του συνόλου των template μεθόδων ενός προγράμματος, προς το άθροισμα των concrete μεθόδων που καλούνται στο σώμα του συνόλου των template μεθόδων του ίδιου προγράμματος, συν τον αριθμητή. Δηλαδή η μετρική έχει τη μορφή : TILT = όπου Abstract no ισοδυναμεί με τον αριθμό των ξεχωριστών κλήσεων abstract μεθόδων από την μέθοδο υπόδειγμα. Η Concrete no ισοδυναμεί με το σύνολο των μοναδικών κλήσεων concrete μεθόδων της μεθόδου υπόδειγμα. Το σύνολο τιμών της βρίσκεται ανάμεσα στο διάστημα [0,1] με 0 να υποδηλώνει κακή σχεδίαση, καθώς σκοπός της μεθόδου υπόδειγμα είναι να παρέχει αφηρημένη υλοποίηση ώστε αυτή να υποκατασταθεί από τις υποκλάσεις [110]. Επίσης η συμπεριφορά της κλάσης που κληρονομεί την μέθοδο υπόδειγμα, πρέπει να μπορεί να επαναορίσει τις abstract μεθόδους με τρόπο που επιθυμεί εκείνη και να μην εξαρτάται από την υλοποίηση της υπερκλάσης. Στην παρούσα εργασία μετρήθηκαν οι μέθοδοι υπόδειγμα που έχουν περισσότερες από δυο abstract μεθόδους στο σώμα τους. Για την καλύτερη κατανόηση του τρόπου υπολογισμού της TILT, παρατίθεται ένα ενδεικτικό παράδειγμα που αποτελείται από τρεις μεθόδους υπόδειγμα. public abstract class FirstAbstractClass { public final void templatemethod1() { step1(); step2(); 47

51 } } step3(); protected int step1() { return -1; } protected abstract int step2(); protected abstract int step3(); public abstract class SecondAbstractClass { public final void templatemethod2() { step1(); step1(); step2(); step2(); step3(); } protected int step1() { return -1; } protected abstract int step2(); protected abstract int step3(); } public abstract class ThirdAbstractClass { public final void templatemethod3() { step2(); step3(); step3(); } protected int step1() { return -1; } protected abstract int step2(); protected abstract int step3(); } 48

52 Αρχικά, θα υπολογιστεί το άθροισμα των μοναδικών Abstract μεθόδων που δηλώνονται μέσα σε κάθε template μέθοδο. Για την FirstAbstractClass είναι ίσος με 2, για την SecondAbstractClass είναι 2 και για την ThirdAbstractClass είναι 2. Αντίστοιχα, ο αριθμός των concrete μεθόδων είναι 1,1,0. Επομένως συνολικά η TILT είναι ίση με Hookability Σαν Hookability ορίζεται η περίπτωση μεθόδου υπόδειγμα που έχει μια μόνο abstract μέθοδο στο σώμα της. Σε αντίθεση με την hook μέθοδο η οποία είναι concrete, επομένως δεν είναι απαράιτητο να υλοποιηθεί από τις υποκλάσεις που την καλούν, η abstract μέθοδος πρέπει να υποκατασταθεί. Hookability = Hooks No Όπου το Hooks No είναι ίσο με τον αριθμό των μεθόδων υπόδειγμα που έχουν μια μόνο abstract μέθοδο. Παρατίθεται ένα ενδεικτικό παράδειγμα για την κατανόησή της. public abstract class AbstractClass { public void Hook1() { step1(); } public void Hook1() { step2(); } protected abstract int step1(); protected abstract int step2(); } Για την AbstractClass η τιμή της Ηοοkability είναι ίση με 2. 49

53 4.3.3 Super to Override Calls (SOV) H τρίτη κατά σειρά μετρική, είναι η SOV. Ορίζεται ως ο αριθμός των μοναδικών super κλήσεων στο σώμα μιας κλάσης στο σύνολο του project, προς τον αριθμό των overrides στο σύνολο του project. Συγκεκριμένα η SOV ορίζεται ως : SOV = Supers/Overrides Όπου ο όρος Supers αντιστοιχεί στο σύνολο των super κλήσεων και ο όρος Overrides αντιστοιχεί στο σύνολο των override. Όπως αναφέρθηκε στο εδάφιο 4.2, η χρήση super μεθόδου είναι ένδειξη κακής σχεδίασης, επομένως όσο μεγαλύτερη είναι η τιμή της τόσο χειρότερη ενδέχεται να είναι η ποιότητα σχεδίασης. Επίσης οι μεγαλύτερες τιμές είναι ένδειξη πως η συμπεριφορά των υπερκλάσεων επαναορίζεται από τις υποκλάσεις. Επομένως, οι τιμές της SOV βρίσκονται στο διάστημα [0,1] με 1 να υποδηλώνει κακή σχεδίαση. 4.4 Σημασιολογία των προτεινόμενων μετρικών Ο ορισμός ενός μετρήσιμου μεγέθους, δεν έχει καμία πρακτική αξία αν δεν προσδιορίζεται ο σκοπός και οι ανάγκες τις οποίες εξυπηρετεί. Στο κεφάλαιο αυτό θα οριστεί η σημασιολογία των προτεινόμενων μετρικών. Συγκεκριμένα : Σημασιολογία της TILT α) Όσο η τιμή της TILT τείνει στο 0, η ποιότητα της σχεδίασης γίνεται κακή. Με την αύξηση του πλήθους των concrete μεθόδων, μειώνεται σε μεγάλο βαθμό η διαφοροποίηση της συμπεριφοράς των υποκλάσεων από τις υπερκλάσεις. Σκοπός των template μεθόδων είναι να παρέχουν ελευθερία υλοποίησης στις κλάσεις που τις κληρονομούν και να μην καθορίζουν την συμπεριφορά τους. Όταν παρατηρείται τέτοια συμπεριφορά, κρίνεται σκόπιμο να μειωθεί το σύνολο των concrete μεθόδων εντός μιας template μεθόδου. Αυτό μπορεί να γίνει είτε αφαιρώντας τις cocncrete μεθόδους που δεν είναι απαραίτητες από την template μέθοδο, είτε να γίνει συνένωση concrete μεθόδων που έχουν κοινά χαρακτηριστικά. 50

54 β) Όσο η τιμή της TILT τείνει στην μονάδα, τόσο αυξάνεται η αφαιρετικότητα του προγράμματος και η ποιότητα σχεδίασης γίνεται καλύτερη, καθώς οι υλοποιήσεις των υποκλάσεων δεν εξαρτώνται από το την υλοποίηση της υπερκλάσης. γ) Όσο μεγαλύτερο είναι το πλήθος των abstract και concrete ορισμάτων της TILT, τόσο αυξάνεται ο βαθμός επαναχρησιμοποίησης μέσα στο πρόγραμμα. Σημασιολογία της Hookability α) Όσο μεγαλύτερη είναι η τιμή της hookability, τόσο αυξάνει η επεκτασιμότητα του προγράμματος. β) Όσο μεγαλύτερο είναι το πλήθος των hook μεθόδων, τόσο αυξάνεται ο βαθμός επαναχρησιμοποίησης μέσα στο πρόγραμμα. γ) Η χρήση της hookability είναι δείγμα καλής σχεδίασης, καθώς όπως και στην TILT είναι παράγοντας αφαίρεσης. Σημασιολογία της SOV α) Όσο η τιμή της SOV τείνει στην μονάδα, το πλήθος των super μεθόδων αυξάνεται, επομένως η σχεδίαση δεν είναι καλή. β) Όσο η τιμή της SOV τείνει στο μηδέν, το πλήθος των super κλήσεων ελαττώνεται και η συμπεριφορά των υπερκλάσεων επαναορίζεται στις υποκλάσεις, επομένως η ποιότητα σχεδίασης βελτιώνεται. γ) Όσο μεγαλύτερες είναι οι τιμές των super και override, τόσο αυξάνει ο βαθμός επαναχρησιμοποίησης, 51

55 4.5 Τεκμηρίωση μετρικών βάση των ιδιοτήτων Weyuker Οι Weyuker ιδιότητες[114] είναι ένα σύνολο 9 κανόνων, οι οποίες ορίστηκαν για την αξιολόγηση μετρικών. Η αρχική τους υλοποίηση ήταν με γνώμονα τις διαδικαστικές γλώσσες προγραμματισμού, αλλά έχουν χρησιμοποιηθεί σαν τεκμηρίωση σε αναγνωρισμένες δημοσιεύσεις αντικειμενοστραφούς λογισμικού [14]. Μια καλή μετρική ποιότητας θα πρέπει να ικανοποιεί όσο το δυνατόν περισσότερες Weyuker ιδιότητες. Ιδιότητα 1 η ( P) ( Q) ( P Q ), με P και Q να είναι δυο διαφορετικές κλάσεις. Δηλαδή, μια μετρική δεν μπορεί να ταξινομεί κάθε κλάση με την ίδια τιμή. Ιδιότητα 2 η Δεδομένου ενός μη αρνητικού αριθμού n, υπάρχει ένας πεπερασμένος αριθμός προγραμμάτων πολυπλοκότητας n. Ιδιότητα 3 η Υπάρχουν δυο διακριτές κλάσεις P και Q οι οποίες P = Q. Δηλαδή δυο διακριτές κλάσεις μπορεί να έχουν την ίδια μετρική τιμή. Ιδιότητα 4 η ( P)( Q)(P Q and P Q ). Αν υπάρχουν δυο προγράμματα που υλοποιούν μια λειτουργία, η μέτρησή τους μπορεί να διαφέρει. Ιδιότητα 5 η ( P) ( Q) ( P P; Q & Q P; Q ). Για κάθε κλάση P,Q η συνένωση αυτών των δυο κλάσεων σε μια νέα, σημαίνει πως η μετρική που την υπολογίζει θα έχει αποτέλεσμα μεγαλύτερο ή ίσο από τις επιμέρους μετρήσεις. Ιδιότητα 6 η ( P) ( Q) ( R) ( P = Q & P;R Q;R )) και ( P) ( Q) ( R)( P = Q & R; P R;Q ). Οι δύο αυτές εξισώσεις δηλώνουν πως δεδομένου κλάσεων P και Q οι οποίες εμφανίζουν την ίδια τιμή σε μια μετρική, αν αυτές ενωθούν με μια κλάση R τότε η τιμή τους θα διαφέρει. 52

56 Ιδιότητα 7 η Υπάρχουν προγράμματα P,Q όπου το Q σχηματίζεται αλλάζοντας την σειρά των ορισμάτων του P και ( P Q ). Η ιδιότητα αυτή ορίζει πως η εναλλαγή των στοιχείων μιας κλάσης, μεταβάλλει την μέτρησή της. Ιδιότητα 8 η Η μετονομασία των κλάσεων δεν επηρεάζει τις τιμές της μετρικής. Ιδιότητα 9 η ( P) ( Q) ( P + Q ) < ( P; Q ). Η ιδιότητα 9 δηλώνει πως το αποτέλεσμα μέτρησης μιας κλάσης η οποία αποτελείται από το άθροισμα δυο άλλων κλάσεων, είναι μεγαλύτερο από το άθροισμα των ξεχωριστών μετρήσεων των κλάσεων αυτών. Ακολουθεί η απόδειξη των ιδιοτήτων Ιδιότητες 1 Οι μετρικές υπολογίζουν χαρακτηριστικά τα οποία διαφέρουν ανάμεσα σε κλάσεις, οπότε η ιδιότητα ισχύει. Ιδιότητα 2 Συνολικά, υπάρχει ένας πεπερασμένος αριθμός προγραμμάτων και κλάσεων. Κάθε κλάση έχει ένα σύνολο πεπερασμένων χαρακτηριστικών. Οι μετρικές ποσοτικοποιούν χαρακτηριστικά των κλάσεων και παράγουν ένα μοναδικό αποτέλεσμα. Ιδιότητα 3 Η ιδιότητα αυτή ισχύει για όλες τις μετρικές. Αν σε μια template μέθοδο που ανήκει στην κλάση P υπάρχουν 2 abstract και 2 concrete μέθοδοι και σε μια template μέθοδο που ανήκει στην κλάση Q υπάρχουν 4 abstract και 4 concrete μέθοδοι, το αποτέλεσμα της TILT θα είναι το ίδιο. Αν υπάρχουν δυο μέθοδοι υπόδειγμα όπου η κάθε μια περιέχει από μια abstract μέθοδο, αλλά η δεύτερη έχει διπλάσιο αριθμό μεθόδων από την πρώτη, τότε πάλι η τιμή της μετρικής είναι η ίδια. Αντίστοιχα, αποδεικνύεται η ιδιότητα για την SOV. 53

57 Ιδιότητα 4 Ισχύει για όλες τις προτεινόμενες μετρικές. Ένας Ν αριθμός προγραμμάτων μπορεί να έχει έως Ν διαφορετικές υλοποιήσεις για την ίδια λειτουργία. Οι μετρικές που προτείνονται μπορούν να δώσουν διαφορετικά αποτελέσματα για προγράμματα που υλοποιούν την ίδια λειτουργία, καθώς αυτές εξαρτώνται αποκλειστικά από την υλοποίηση. Ιδιότητα 5 Ισχύει για την Hookability. Δεδομένων δυο κλάσεων, αν αυτές ενωθούν και τόσο οι μέθοδοι που περιέχουν τις hook όσο και οι ίδιες οι hook μέθοδοι έχουν το ίδιο όνομα, τότε το αποτέλεσμα είναι ίσο με τις επιμέρους μετρήσεις. Αν είναι διαφορετικό το όνομα των μεθόδων, η τιμή θα είναι μεγαλύτερη. Σε περίπτωση που το όνομα των μεθόδων είναι ίδιο αλλά των hooks διαφορετικό, τότε το μέγεθος που προκύπτει υπολογίζεται από την TILT. Η ιδιότητα 5 δεν ισχύει πάντα για την TILT. Έστω δυο κλάσεις P,Q, όπου η P περιέχει template μέθοδο με 2 abstract μεθόδους και η Q περιέχει template μέθοδο με 2 abstract και 2 concrete μεθόδους. Στην πρώτη περίπτωση, η τιμή της TILT είναι ίση με 1 ενώ στη δεύτερη ίση με 0.5. Αν όλα τα χαρακτηριστικά των δυο κλάσεων έχουν διαφορετικό όνομα και δημιουργηθεί μια νέα κλάση PQ, αυτή θα έχει 4 abstract και 2 concrete μεθόδους και η τιμή της TILT θα είναι ίση με 0.6. Η τιμή αυτή είναι μεγαλύτερη μόνο στην περίπτωση της κλάσης Q. Αντίστοιχα, αποδεικνύεται ότι δεν ισχύει πάντα για την μετρική SOV. Ιδιότητα 6 H ιδιότητα 6 δεν αποτελεί μια απαραίτητη προϋπόθεση που πρέπει να ικανοποιούν οι μετρικές αντικειμενοστραφούς λογισμικού[14], εντούτοις θα εξεταστεί αν ικανοποιείται από το σύνολο των μετρικών. 54

58 Δεν ισχύει για την TILT. Έστω, πως υπάρχουν δυο κλάσεις P,Q, με κάθε μια να περιέχει από μια template μέθοδο με δυο abstract και 2 concrete μεθόδους. Η τιμή της TILT για κάθε μια είναι 0.5. Αν ενωθούν αυτές οι κλάσεις σε μια, τότε το αποτέλεσμα θα είναι πάλι 0.5. Αντίστοιχα, αποδεικνύεται πως η μετρική δε ισχύει για την SOV. Για την Hookability η ιδιότητα 6 ισχύει. Έστω, πως υπάρχουν δυο κλάσεις P,Q, που στο σώμα τους περιέχουν πέντε μεθόδους υπόδειγμα, με κάθε μια να περιέχει μια abstract κλάση. Αν ενωθούν αυτές οι κλάσεις σε μια, τότε το αποτέλεσμα της Hookability θα είναι διαφορετικό γιατί συνολικά θα περιλαμβάνονται 10 μέθοδοι. Ιδιότητα 7 Οι ιδιότητες 7,9 δεν ισχύουν για μετρικές που υπολογίζουν στοιχεία αντικειμενοστραφών γλωσσών προγραμματισμού [14][113]. Ιδιότητα 8 Οι μετρικές δεν σχετίζονται με την ονομασία κάθε κλάσης, οπότε ισχύει 55

59 5. Υλοποίηση μετρικών και αποτελέσματα μετρήσεων Στο παρόν κεφάλαιο, αρχικά θα γίνει αναλυτική παρουσίαση των εργαλείων που χρησιμοποιήθηκαν για την υλοποίηση των μετρικών που προτάθηκαν στο κεφάλαιο 4. Στη συνέχεια, θα ακολουθήσει η παρουσίαση του περιβάλλοντος εκτέλεσης των πειραμάτων και έπειτα θα γίνει παρουσίαση των αποτελεσμάτων. Μετά τον σχολιασμό τους, θα προταθεί ένα ενδεικτικό εύρος τιμών, όπως αυτό προέκυψε από τα πειραματικά δεδομένα, το οποίο μπορούν να πάρουν οι μετρικές ώστε να διαπιστωθεί αν η ποιότητα της σχεδίασης που ακολουθείται είναι η επιθυμητή. 5.1 Παρουσίαση πλατφόρμας SonarQube Το SonarQube είναι μια πλατφόρμα ανοιχτού λογισμικού η οποία χρησιμοποιείται για τον έλεγχο ποιότητας κώδικα. Έχει αναπτυχθεί από την εταιρία SonarSource και ο κώδικάς της είναι ελεύθερα διαθέσιμος στο internet. Είναι γραμμένη σε Java και μπορεί να αναλύσει ένα σύνολο γλωσσών προγραμματισμού που ξεπερνά της 20, είτε άμεσα είτε, με την χρήση επεκτάσεων. Ενδεικτικά, είναι συμβατό με έργα που έχουν γραφτεί σε Java, C#, C/C++, PL/SQL, Cobol κ.α. [116]. Σε αντίθεση με άλλες αντίστοιχες εφαρμογές, είναι ένα "ζωντανό" project το οποίο εξελίσσεται συνεχώς καθώς υπάρχει μια ολόκληρη κοινότητα που το υποστηρίζει. Η δύναμή του έγκειται στο ότι χρησιμοποιεί ένα σύνολο άλλων επεκτάσεων και δωρεάν εργαλείων, τα οποία ενσωματώνει για να βγάλει στατιστικά και μετρικά αποτελέσματα στον χρήστη για την ποιότητα του κώδικά του. Επίσης δίνει τη δυνατότητα απεικόνισης της εξέλιξης του έργου, καθώς αποθηκεύει τα αποτελέσματα των μετρήσεων σε βάθος χρόνου [116]. Χρησιμοποιείται από μεγάλες εταιρίες σε όλο τον κόσμο, όπως η CISCO, η SIEMENS, το ebay κ.α.. Για την παρουσίαση των αποτελεσμάτων της εφαρμογής είναι απαραίτητη η χρήση φυλλομετρητή, ενώ υπάρχει και επέκταση για την παρουσίαση των αποτελεσμάτων στο περιβάλλον ανάπτυξης Eclipse. Ανάμεσα στα άλλα χαρακτηριστικά του, δίνει την δυνατότητα στον χρήστη να δει την εξέλιξη του κώδικά του συγκριτικά σε βάθος χρόνου. Τα αποτελέσματα παρουσιάζονται στην οθόνη σε επίπεδο έργου, αλλά είναι διαθέσιμα και για τους επιμέρους φακέλους και τα αρχεία του προγράμματος. 56

60 Για την ανάλυση και παρουσίαση των στατιστικών και άλλων στοιχείων ενός έργου, είναι απαραίτητο να γίνει χρήση δυο συστατικών, το ένα είναι το SonarQube server και το άλλο το SonarQube Runner. Το πρώτο, επιτρέπει την εμφάνιση των αποτελεσμάτων στην πλευρά του χρήστη, αφού πρώτα τα αντλεί από την βάση δεδομένων του SonarQube. Το δεύτερο, αναλύει τον κώδικα και αποθηκεύει τα αποτελέσματα στην βάση δεδομένων. Τα δυο αυτά εργαλεία είναι διαθέσιμα για λήψη στην διεύθυνση από όπου ο χρήστης μπορεί να επιλέξει και παλαιότερες εκδόσεις. Η έκδοση η οποία χρησιμοποιήθηκε για την παρούσα εργασία είναι η 3.7. Μετά την εγκατάσταση της εφαρμογής, ο χρήστης μπορεί να εγκαταστήσει ένα σύνολο από 50 επεκτάσεις που είναι διαθέσιμες δωρεάν, για να αυξήσει τη λειτουργικότητα και το πλήθος των εργαλείων που έχει στη διάθεσή του. Αυτά έχουν δημιουργηθεί είτε από την εταιρία SonarSource είτε από την κοινότητα που το υποστηρίζει. Επίσης, με τη βοήθεια πακέτων, ο χρήστης μπορεί να αλλάξει τη γλώσσα προτίμησής του ανάμεσα σε Κινέζικα, Ελληνικά, Ιταλικά, Αγγλικά, Ισπανικά, Πορτογαλικά και Γιαπωνέζικα Βήματα ανάλυσης κώδικα Αξίζει να γίνει αναφορά στα βασικά βήματα που χρειάζονται για την ανάλυση ενός έργου από το SonarQube. Όταν πρόκειται να αναλυθεί ένα project, θα πρέπει πρώτα να εντοπιστεί το μονοπάτι στο οποίο είναι αποθηκευμένο και να δημιουργηθεί ένα αρχείο.properties μέσα στον φάκελό του, το οποίο θα χρησιμοποιήσει το SonarQube Runner για την ανάλυση του συντακτικού του κώδικα. Ενδεικτικά, παραθέτουμε το περιεχόμενο ενός αρχείου.properties όπως αυτό δημιουργήθηκε για τον έλεγχο των αποτελεσμάτων (εικόνα 4). Οι δυο πρώτες παράμετροι αφορούν τα μοναδικά χαρακτηριστικά του project που είναι το όνομα και ο κωδικός. Σε γενικές γραμμές, καλό είναι να έχουν το ίδιο όνομα για λόγους απλότητας. Η παράμετρος sonar.projectversion, υπάρχει για την ομαδοποίηση των αποτελεσμάτων του έργου, βάσει της έκδοσης του προγράμματος που ελέγχεται. Οι παράμετροι sonar.sources και sonar.binaries, δείχνουν η μία τον φάκελο στον οποίο έχει αποθηκευτεί ο πηγαίος κώδικας της εφαρμογής και η δεύτερη προαιρετική παράμετρος, αφορά το μονοπάτι στο οποίο είναι αποθηκευμένη η δυαδική ανάλυση του κώδικα. Σε περίπτωση που ο κώδικας είναι διαμερισμένος σε περισσότερο από ένα φάκελο, τα ονόματά 57

61 τους χωρίζονται με κόμμα. Η sonar.language παράμετρος αναφέρεται στην γλώσσα προγραμματισμού στην οποία είναι γραμμένο το έργο και τέλος η παράμετρος sonar.sourceencoding αφορά τον τύπο κωδικοποίησης των χαρακτήρων του project. Πιο πολλές πληροφορίες για το σύνολο των παραμέτρων και την λειτουργία τους, μπορεί να βρεθεί εδώ: Εικόνα 3: Ενδεικτικό.properties αρχείο Μετά την δημιουργία του.properties αρχείου, ακολουθεί η εκκίνηση του Server. Για να γίνει αυτό, σε μια κονσόλα των windows γίνεται επικόλληση της ακόλουθης εντολής : C:\sonarqube\bin\windows-x86-xx\StartSonar.bat. όπου η τιμή xx θα είναι 64 ή 32 ανάλογα με τον τύπο του συστήματος. Στη συνέχεια εκτελείται ο SonarQube Runner για την ανάλυση του προγράμματος. Αντίστοιχα, εκτελείται μια κονσόλα σε περιβάλλον Windows και γίνεται αντικατάσταση του μονοπατιού που εμφανίζεται, με αυτό στο οποίο βρίσκεται το project που θα αναλυθεί, για παράδειγμα cd C:\Users\Beast\SOAPUI. Μετά την αλλαγή του φακέλου, εκτελείται το SonarQube Runner με την εντολή C:\sonar-runner\bin\sonar-runner.bat. Αφού ολοκληρωθεί η ανάλυση, ο χρήστης μπορεί να ανοίξει έναν φυλλομετρητή να πληκτρολογήσει τη διεύθυνση και να δει την παρουσίαση των αποτελεσμάτων. Περισσότερες πληροφορίες για την δημιουργία ανάλυσης σε διαφορετικό περιβάλλον μπορούν να βρεθούν εδώ: 58

62 5.1.2 Βήματα επέκτασης κώδικα Τα εργαλεία που εμπλέκονται στην διαδικασία επέκτασης του SonarQube είναι τα Maven και Eclipse. Η λέξη Maven, σημαίνει "συσσωρευτής της γνώσης" και κατά μια έννοια είναι. Ξεκίνησε σαν προσπάθεια απλούστευσης των διαδικασιών διαμοιρασμού των JAR αρχείων σε διάφορα έργα. Πιο συγκεκριμένα, κάνει τη διαδικασία μεταγλώττισης εύκολη, καθώς παρέχει ένα ενιαίο σύστημα "build" χρησιμοποιώντας POM αρχεία (project object model), τα οποία περιέχουν οδηγίες για το "χτίσιμο" ενός project. Το πλεονέκτημα του Maven, είναι πως μειώνει πολύ τον χρόνο που χρειάζεται για να γίνει "build" ένα project και είναι ιδιαίτερα εύχρηστο [104]. Χρησιμοποιήθηκε κατά τη διάρκεια της ανάπτυξης, για να φορτωθούν οι βιβλιοθήκες και τα σχόλια του πηγαίου κώδικα του SonarQube, καθώς και για την δημιουργία των βιβλιοθηκών Jar των plugins που επεκτάθηκαν. Επίσης, χρησιμοποιήθηκε για την μετατροπή των open source προγραμμάτων που εξετάστηκαν σε project που μπορούν να εισαχθούν στο Eclipse. Το γνωστό Eclipse είναι η βάση στην οποία έγινε η επέκταση της πλατφόρμας. Είναι ένα IDE framework, το οποίο αναπτύχθηκε αρχικά από την IBM 2001, ενώ το 2004 ιδρύθηκε ο ανεξάρτητος, μη κερδοσκοπικός οργανισμός Eclipse Foundation [105]. Το plugin του SonarQube, το οποίο χρησιμοποιήθηκε για να εξυπηρετήσει τις ανάγκες υλοποίησης των μετρικών, είναι το java-squid καθώς και ο φάκελός του sonar-squid-javaplugin. Κρίθηκε σκόπιμο να επεκταθεί ένα υπάρχον plugin από την ανάπτυξη ενός νέου εξ αρχής, αφού έτσι παρέχεται η δυνατότητα να γίνει χρήση την υπάρχουσας υποδομής (συντακτική ανάλυση, αποθήκευση δεδομένων στην βάση, επικοινωνία με την εφαρμογή κ.λ.π. ) για την ανάλυση κώδικα, που αλλιώς θα ήταν ιδιαίτερα χρονοβόρα να αναπτυχθεί. 59

63 Ο λόγος που επιλέχτηκε το Java-Squid, είναι γιατί περιλαμβάνεται στην αρχική εγκατάσταση της πλατφόρμας, επομένως είναι ελεγμένο και ανεπτυγμένο από την ίδια την εταιρία και η πιθανότητα να εμφανιστούν προβλήματα συμβατότητας είναι πολύ μικρή. Επίσης το Java- Squid είναι η επέκταση που χρησιμοποιείται από το SonarQube για να υπολογίσει το σύνολο των μετρικών που υποστηρίζει. Αυτή η επιλογή παρέχει τη δυνατότητα καλύτερης κατανόησης της λειτουργίας των μετρικών στο εργαλείο, ενώ παράλληλα βοηθάει στην κατανόηση του τρόπου με τον οποίο πρέπει να δομηθούν οι νέες. Η επέκταση έγινε από το χαμηλότερο επίπεδο της Java που είναι το bytecode, έως την αποθήκευση και εμφάνιση των αποτελεσμάτων στον χρήστη. Το Java-Squid βασίζεται τις εξής κλάσεις για να αναλύσει τον κώδικα και να εμφανίσει τα αποτελέσματα στον χρήστη. Visitor : Οι Visitor, χρησιμοποιούνται από το Java-Squid για να διαβάσουν τον κώδικα εισόδου υπό μορφή bytecode και αποθηκεύουν τις μετρήσεις που πραγματοποιούν σε όλα τα αρχεία και του φακέλους. Bridge : Οι Bridge, αποθηκεύουν τα αποτελέσματα των visitors στην βάση. Αυτά τα αποτελέσματα αντλούνται στην συνέχεια και εμφανίζονται στο interface του χρήστη Παρουσίαση διεπαφής SonarQube Στην αρχική οθόνη που αντικρίζει ο χρήστης όταν ανοίξει τον φυλλομετρητή του, εμφανίζεται το σύνολο των projects που έχει αναλύσει και κάποιες πληροφορίες σχετικά με αυτά, όπως η έκδοση, ο αριθμός των γραμμών του κώδικα και η τελευταία ανάλυση (εικόνα 4). 60

64 Εικόνα 4 : Διεπαφή χρήστη της πλατφόρμας SonarQube Αφού επιλέξει κάποιο από τα παραπάνω projects, θα μεταφερθεί σε μια νέα οθόνη η οποία αριστερά περιλαμβάνει τον πίνακα ελέγχου και το όνομα του project που ανέλυσε και δεξιά ένα σύνολο από μετρικές (εικόνα 5). Υπάρχει η δυνατότητα επιλογής των μετρικών που θα εμφανιστούν στην οθόνη και για να γίνει αυτό, πάνω δεξιά στο παράθυρο υπάρχει η επιλογή login. Χρησιμοποιώντας το όνομα χρήστη: admin και το συνθηματικό: admin ο χρήστης συνδέεται στο σύστημα. Στη συνέχεια, αφού επιστρέψει στην προηγούμενη οθόνη που εμφανίζει την ανάλυση, εμφανίζονται δυο νέες καρτέλες configure widget και manage dashboard. Επιλέγοντας την πρώτη, ο χρήστης μπορεί να κάνει ότι αλλαγές κρίνει πως είναι σκόπιμες για την ανάλυση του project. Στην περίπτωση επέκτασης του SonarQube, οι μετρικές που υλοποιούνται εμφανίζονται με την επιλογή add widget στα custom measures. Το interface του SonarQube είναι πολύ απλό και εύχρηστο, περισσότερες πληροφορίες σχετικά με την λειτουργικότητά του μπορεί να βρει κανείς εδώ: 61

65 Εικόνα 5 : Προβολή μετρικών στη διεπαφή χρήστη 5.2 Η επέκταση Metrics Όπως αναφέρθηκε, η πλατφόρμα SonarQube βασίζει τον υπολογισμό των μετρικών της στο επίπεδο bytecode. Αυτό όμως θέτει κάποιους περιορισμούς για τα μεγέθη που χρειάστηκε να υλοποιηθούν, καθώς ένα μέρος εξ αυτών υπολογίζονται με ακρίβεια στο AST επίπεδο της Java. Για το λόγο αυτό επιλέχτηκε η χρήση ενός open-source εργαλείου, το οποίο υπολογίζει τα μεγέθη των κλήσεων super και override. Συγκεκριμένα η επέκταση metrics για το Eclipse, δίνει τη δυνατότητα στον χρήστη να δει αποτελέσματα για το πρόγραμμά του σε ένα σύνολο μετρικών, πολλές εξ αυτών παρουσιάστηκαν στο κεφάλαιο 3. Αναλυτικές οδηγίες για την εγκατάστασή του, καθώς και ο πηγαίος του κώδικας είναι διαθέσιμα στην τοποθεσία 62

66 Εικόνα 6 : Σύνολο μετρικών που υπολογίζονται από την επέκταση metrics 5.3 Αποτελέσματα μετρήσεων Ένας από τους βασικούς λόγους που επιλέχτηκαν open source προγράμματα για την υλοποίηση και τον υπολογισμό των μετρικών, είναι πως βρίσκονται διαθέσιμα σε όλους για την επαλήθευση και τον έλεγχο των αποτελεσμάτων. Για τον ίδιο λόγο επιλέχτηκαν open source προγράμματα στον έλεγχο των αποτελεσμάτων, τα οποία είναι υλοποιημένα σε γλώσσα Java για λόγους συμβατότητας. Το σύνολο των project βρίσκονται διαθέσιμα 63

67 στις διευθύνσεις και Συνολικά, αναλύθηκαν 50 projects τα οποία αντιστοιχούν σε περισσότερες από 2.5 εκατομμύρια γραμμές κώδικα. Σκοπός της ανάλυσης ήταν να υπάρξει όσο το δυνατόν μεγαλύτερο εύρος, τόσο στον αριθμό των εφαρμογών, όσο και στο πλήθος γραμμών του πηγαίου κώδικα, για την εγκυρότητα των αποτελεσμάτων. Επίσης, τα projects που αναλύθηκαν περιλαμβάνουν ένα σύνολο ετερογενών εφαρμογών όπως compiles, clientservers, apis, frameworks κ.α.. Ο υπολογισμός των μετρικών TILT και Hookability έγινε χρησιμοποιώντας την επέκταση του SonarQube που υλοποιήθηκε στα πλαίσια της διπλωματικής. Για τον υπολογισμό της μετρικής SOV χρησιμοποιήθηκε η επέκταση Metrics. Για τον υπολογισμό των αποτελεσμάτων κρίθηκε πως αρκεί η χρήση ενός μηχανήματος και στον πίνακα 2 φαίνονται τα χαρακτηριστικά του. Λειτουργικό Σύστημα Επεξεργαστής Μνήμη Microsoft Windows 7 64 bit Intel Core i5 CPU 3570K 3.4GHz 8.00 GB Πίνακας 2 : Χαρακτηριστικά μηχανήματος ελέγχου Το σύνολο των αποτελεσμάτων φαίνεται αναλυτικά στον πίνακα 3. Η πρώτη στήλη αντιστοιχεί στο όνομα του project, η δεύτερη στον αριθμό των εμφανιζόμενων template μεθόδων, η τρίτη υπολογίζει το σύνολο των hook μεθόδων, η τέταρτη και πέμπτη αναφέρεται στον αριθμό των abstract και concrete μεθόδων της template μεθόδου, η έκτη υπολογίζει την τιμή της TILT, η έβδομη παρουσιάζει το πλήθος των overrides και τέλος η όγδοη παρουσιάζει την μετρική SOV. Project Name Templ ate metho ds Hook ability No of Abs trac ts No of Concr etes TILT Super Calls Ove rride s SOV 64

68 Barbecue Batik Dom4j SOAP Ui Drawswf Jade JavaGeom Jaxen Jdom Nutch Jfreechart Jhotdraw Xalan Xerces jist-swans PMD Junit Evernote api activiti-bpmnmodel activiti-engine Atmosphere Blueprintsgraph-sail Blueprintsorient-graph Broadleafcommon Broadleafcontentmanag ement-module Broadleafframework Broadleaf open-admin- platform Droolscompiler Drools-core Encog Gremlin Hazelcast Jasmine jbpm-flow jbpm-bpmn Sonar-java Squid Sonar-squidjava-plugin

69 Jooq Mavenandroi d plugin Mongo-javadriver Nutz Okhttp Orientdb-core Robotium Solandra Worldedit Wr04j Undertow Spring-Core Spring-datajpa Πίνακας 3 : Αποτελέσματα μετρήσεων 5.4 Ανάλυση αποτελεσμάτων Σε αυτό το κεφάλαιο θα γίνει μια προσπάθεια ανάλυσης του συνόλου των τιμών των αποτελεσμάτων. Όπως αναφέρθηκε και στο κεφάλαιο 4, όσο μικρότερες είναι οι τιμές της TILT και όσο μεγαλύτερες της SOV τόσο χειρότερη σχεδίαση ενδέχεται να υπάρχει σε ένα πρόγραμμα. Η κατώτερες τιμές είναι 0 για την TILT και 1 για την SOV. Η Hookability είναι ένδειξη της επεκτασιμότητας και της αφαίρεσης του προγράμματος και όσο μεγαλύτερες είναι οι τιμές που παίρνει, τόσο ενισχύονται τα δυο αυτά χαρακτηριστικά του προγράμματος. Στον πίνακα 4, φαίνονται κάποια βασικά χαρακτηριστικά του συνόλου των μετρήσεων, όπως η μέση τιμή, η τυπική απόκλιση, η μέγιστη και ελάχιστη τιμή. Μετρική TILT SOV M.O Τυπική απόκλιση Μέγιστη τιμή Ελάχιστη τιμή Πίνακας 4 : Στατιστικά στοιχεία μετρήσεων 66

70 Από τα 50 projects που αναλύθηκαν, τα 26 εμφανίζουν μη μηδενική τιμή για την TILT ( δηλαδή υπάρχει τουλάχιστον μια μέθοδος υπόδειγμα στο πρόγραμμα που εξετάστηκε). Το 38% των project εμφανίζουν τιμή μεγαλύτερη από αυτή του μέσου όρου, δηλαδή εμφανίζουν αναλογία abstract μεθόδων προς concrete μικρότερη από δυο προς ένα. Αυτό σημαίνει πως σε μεγάλο βαθμό οι μέθοδοι υπόδειγμα δεν καθορίζουν τη συμπεριφορά των υποκλάσεών τους αλλά επιτρέπουν την ευελιξία υλοποίησης. Το 27% των 26 project εμφανίζουν τιμή ίση με ένα. Επομένως επιτρέπουν την μεγαλύτερη δυνατή αφαίρεση, κατά την χρήση των μεθόδων υπόδειγμα. Στην περίπτωση της SOV, η μέση τιμή των αποτελεσμάτων βρίσκεται στο που σημαίνει πως περίπου το 36% των μεθόδων που υποκαθίστανται από τις υποκλάσεις τους, καλούν τις υπερκλάσεις τους. Πιθανόν μια σχεδίαση που θα διαχώριζε τις super κλήσεις σε μια μέθοδο υπόδειγμα όπου το ένα μέρος της θα παρείχε concrete υλοποίηση και το άλλο θα επέτρεπε την επέκταση (υπό την μορφή abstract μεθόδου), να μείωνε και άλλο αυτό το ποσοστό. Υπολογίζοντας τον βαθμό συσχέτισης ανάμεσα στις δυο αυτές μετρικές, αυτός προκύπτει Το αρνητικό πρόσημο οφείλεται στο ότι οι τιμές που υποδεικνύουν καλή σχεδίαση στην TILT, εκτιμούνται ως κακές στην SOV (για παράδειγμα μια τιμή 0.8 στην TILT μπορεί να θεωρηθεί σαν καλή σχεδίαση ενώ αντίστοιχη τιμή στην SOV όχι). Ο σχετικά χαμηλός βαθμός συσχέτισης, οφείλεται στο ότι οι μετρικές αναφέρονται σε διαφορετικά χαρακτηριστικά του project, καθώς και στο ότι υπολογίζονται σε επίπεδο έργου και όχι σε επίπεδο κλάσης. 67

71 6 Συμπεράσματα Στην παρούσα εργασία ερευνάται το πρόβλημα της χρήσης μετρικών για τον προσδιορισμό της καλής ή κακής ποιότητας σε ένα έργο πληροφορικής. Η προτεινόμενη προσέγγιση εστιάζεται στην χρήση μετρικών κληρονομικότητας, οι οποίες βασίζεται στην χρήση template και hook μεθόδων, στην κλήση super και των overrides. Οι μετρικές που αναπτύχθηκαν υπολογίζονται σε επίπεδο έργου. Αναλυτικότερα, αναπτύχθηκαν τρεις μετρικές ποιότητας μετά από επέκταση της πλατφόρμας SonarQube και χρήσης του ενθέματος Metrics για το Eclipse. Συγκεκριμένα, έγινε επέκταση του bytecode επιπέδου του SonarQube για τον υπολογισμό της μετρικής TILT και Hookability, ενώ η SOV υπολογίστηκε με την Metrics. Οι προτεινόμενες μετρικές εφαρμόστηκαν σε ένα σύνολο προγραμμάτων ανοιχτού κώδικα που ανέδειξαν την χρησιμότητα των μετρικών. Υπολογίστηκε ένα σύνολο στατιστικών στοιχείων, τα οποία παρείχαν πληροφορίες για τις μετρικές TILT και SOV αλλά και για την μεταξύ τους σχέση. Περαιτέρω διερεύνηση που θα μπορούσε να γίνει στο μέλλον σχετικά με την χρησιμότητα των μετρικών TILT και SOV είναι ο βαθμός στον οποίο βελτιώνεται η σχεδίαση κατά τη χρήση τους. Προτείνεται η μέτρηση του αριθμού των σφαλμάτων που παρουσιάζονται σε ένα σύνολο προγραμμάτων, πριν και μετά τη βελτίωση των τιμών των δυο μετρικών. Η παρούσα διπλωματική εργασία συμβάλει στην χρήση εργαλείων για τον προσδιορισμό της ποιότητας του παραγόμενου λογισμικού. Ωστόσο, η συμβολή του προγραμματιστή είναι εκείνη που θα δώσει το επιθυμητό αποτέλεσμα. Το σύνολο των μετρικών που παρουσιάστηκαν δεν είναι παρά το πλαίσιο υποστήριξης του χρήστη. 68

72 Παράρτημα Α: Βήματα Εγκατάστασης του Maven H εμπειρία που αποκτήθηκε κατά τη διάρκεια επέκτασης του SonarQube, κρίνεται σκόπιμο να καταγραφεί με λεπτομέρεια, έτσι ώστε να είναι η βάση αναφοράς για μελλοντικά project, καθώς το σύνολο των πληροφοριών που περιγράφεται δεν υπάρχει αλλού διαθέσιμο. Πριν αναλυθούν οι λεπτομέρειες εγκατάστασης του Maven, να αναφερθεί πως ο πηγαίος κώδικας της εφαρμογής SonarQube είναι διαθέσιμος για λήψη στο: ενώ στο υπάρχει το σύνολο του πηγαίου κώδικα των επεκτάσεων της εφαρμογής. Αφού γίνει η λήψη του Maven από τον σύνδεσμο ακολουθούνται τα παρακάτω βήματα [107]: 1) Γίνεται αποσυμπίεση του.zip αρχείου στον φάκελο που επιθυμεί ο χρήστης να γίνει η εγκατάσταση του Maven. Στην περίπτωσή μας, ο φάκελος βρίσκεται στην τοποθεσία C:\apache-maven ) Δημιουργείται η μεταβλητή συστήματος M2_HOME ανοίγοντας τις ρυθμίσεις συστήματος, αφού ακολουθηθεί η διαδρομή "Control Panel\System and Security\System". Στη συνέχεια επιλέγεται η καρτέλα "Advanced" και το κουμπί "Environment Variables". Στις μεταβλητές χρήστη γίνεται προσθήκη της M2_HOME, η οποία παίρνει τιμή "C:\apachemaven " και σβήνονται πιθανά κενά που μπορεί να υπάρχουν στο τέλος. 3) Στην ίδια καρτέλα των μεταβλητών χρήστη, δημιουργείται μια νέα μεταβλητή με ονομασία M2 και τιμή " %M2_HOME%\bin". 4) (προαιρετικό βήμα) Επίσης, στις μεταβλητές χρήστη μπορεί να γίνει προσθήκη της μεταβλητής MAVEN_OPTS, η οποία μας παρέχει επιπλέον λειτουργικότητα κατά την χρήση του Maven. 5) Επιλέγεται η μεταβλητή Path, η οποία γίνεται edit και προστίθεται η τιμή "%M2%", ώστε να συμπεριληφθεί το Maven στην γραμμή εντολών. 69

73 6) Γίνεται έλεγχος για την ύπαρξη της τοπικής μεταβλητής JAVA_HOME στις μεταβλητές χρήστη και πως η τιμή της αντιστοιχεί στην τοποθεσία του JDK (εικόνα 7). Επίσης ελέγχεται πως το " %JAVA_HOME%\bin" περιλαμβάνεται στην PATH μεταβλητή περιβάλλοντος. 7) Τέλος εκτελείται στο command prompt η εντολή "mvn --version", για να επιβεβαιωθεί η ορθή εγκατάσταση του Maven. Εικόνα 7 : Δημιουργία τοπικών μεταβλητών Μετά την λήψη του πηγαίου κώδικα και την εγκατάσταση του Maven στο σύστημα, αυτό θα χρησιμοποιηθεί για την ενσωμάτωση των βιβλιοθηκών στον πηγαίο κώδικα, ώστε το υπάρχον Java project να μετατραπεί σε Eclipse project. Πριν εκτελεστεί όμως το maven στην κονσόλα των windows, πρέπει να δημιουργηθεί μια τοπική "classpath" μεταβλητή M2_REPO, η οποία δεν είναι ορισμένη στο Eclipse. Για το λόγο αυτό, ακολουθούνται τα παρακάτω βήματα : 70

74 Από το menu του Eclipse γίνεται επιλογή της καρτέλας "Window" και στη συνέχεια της επιλογής "Preferences". Επιλέγεται από την καρτέλα αριστερά η διαδρομή Java > Build Path > Classpath Variables. Επιλέγεται το new, και δηλώνεται για όνομα το M2_REPO, ενώ για path ορίζεται η τοποθεσία του τοπικού repository του Maven. Εικόνα 8 : Δημιουργία τοπικής μεταβλητής στο Eclipse Εναλλακτικά, μπορεί να δημιουργηθεί η μεταβλητή M2_REPO μέσω του command prompt των windows, πληκτρολογώντας την κάτωθι εντολή: mvn -Declipse.workspace="your Eclipse Workspace" eclipse:configure-workspace Από τη στιγμή που θα δημιουργηθεί η classpath μεταβλητή M2_REPO, είναι προσβάσιμη από όλα τα project που υπάρχουν στην επιφάνεια εργασίας. 71

75 Τώρα που ολοκληρώθηκαν όλες οι απαραίτητες ρυθμίσεις για την εκτέλεση του Maven, πρέπει να εκτελεστούν οι παρακάτω εντολές για να ενημερωθεί το τοπικό repository. "mvn dependency:resolve -Dclassifier=javadoc" "mvn dependency:resolve -Dclassifier=sources" Για να προστεθεί το Maven στην επιφάνεια εργασίας του Eclipse εκτελείται η ακόλουθη εντολή: "mvn -Declipse.workspace=<path-to-eclipse-workspace> eclipse:add-maven-repo" Τέλος, για την μετατροπή ενός maven project σε eclipse project εκτελείται η κάτωθι εντολή στον φάκελο του project που πρόκειται να αναλυθεί [106]. mvn eclipse:eclipse -DdownloadSources=true -Denforcer.skip=true Περισσότερες και πιο αναλυτικές οδηγίες μπορούν να βρεθούν στον ακόλουθο σύνδεσμο : 72

76 Παράρτημα Β: Σημεία επέκτασης του SonarQube Έχοντας ακολουθήσει όλα τα βήματα του παραρτήματος Α, η επιφάνεια εργασίας έχει διαμορφωθεί με τρόπο που ομοιάζει με την εικόνα που ακολουθεί (εικόνα 9). Στον project explorer του Sonar, φαίνεται το σύνολο των plugins που χρησιμοποιεί η εφαρμογή μετά την εγκατάστασή της, αλλά η διαφορά είναι πως τώρα είναι διαθέσιμος ο πηγαίος της κώδικας και δεν είναι υπό την μορφή jars. Με τον τρόπο αυτό, ο χρήστης μπορεί τώρα να επέμβει και να κάνει ότι αλλαγές κρίνει ο ίδιος πως είναι αναγκαίες. Εικόνα 9 : Περιβάλλον εργασίας στο Eclipse μετά την εκτέλεση του Maven Όσον αφορά τα βήματα επέκτασης, αυτά έχουν ως εξής : Φάκελος java-squid Αρχικά, στη διαδρομή java-squid/src/main/java/org.sonar.java.bytecode.visitor δημιουργήθηκε το TemplateFinderVisitor.java αρχείο, το οποίο μετράει τις template μεθόδους, τις περιπτώσεις hook μεθόδων (δηλαδή τις περιπτώσεις που καλείται μόνο μια abstract μέθοδος) και τέλος τον αριθμό των concrete και abstract μεθόδων όπως αυτές ορίστηκαν στο κεφάλαιο 3. Έπειτα, προστέθηκε το αρχείο TemplateMetric.java, το οποίο επεκτείνει την υπάρχουσα υποδομή και στο οποίο προστέθηκαν κλειδιά για τις μετρικές που υπολογίζονται. Τα κλειδιά χρησιμεύουν για την προσωρινή αποθήκευση των αποτελεσμάτων σε επίπεδο αρχείων και φακέλων. 73