ΤΜΗΜΑ ΠΛΗΡΟΦΟΡΙΚΗΣ. ΜΕΤΑΠΤΥΧΙΑΚΟ ΔΙΠΛΩΜΑ ΕΙΔΙΚΕΥΣΗΣ (MSc) στα ΠΛΗΡΟΦΟΡΙΑΚΑ ΣΥΣΤΗΜΑΤΑ ΔΙΠΛΩΜΑΤΙΚΗ ΕΡΓΑΣΙΑ. Εμμανουήλ Τζαγκαράκης

Transcript

1 ΤΜΗΜΑ ΠΛΗΡΟΦΟΡΙΚΗΣ ΜΕΤΑΠΤΥΧΙΑΚΟ ΔΙΠΛΩΜΑ ΕΙΔΙΚΕΥΣΗΣ (MSc) στα ΠΛΗΡΟΦΟΡΙΑΚΑ ΣΥΣΤΗΜΑΤΑ ΔΙΠΛΩΜΑΤΙΚΗ ΕΡΓΑΣΙΑ Μετρικές κληρονομικότητας για αντικειμενοστραφές λογισμικό Εμμανουήλ Τζαγκαράκης ΜΜ Αθήνα, Σεπτέμβριος 2017

2 2

3 Περιεχόμενα 1 Εισαγωγή Βασικές Έννοιες Εισαγωγή Επιστημονική προσέγγιση Μέτρο, Μέτρηση και Μετρική Επικύρωση των μετρικών Μετρικές και Οριακές Τιμές Ιδιότητες των Μετρικών Λογισμικού Εγκυρότητα Αξιοπιστία Ευρωστία Αρχές Μετρικών Κριτικές Μετρικές Λογισμικού Αντικείμενο Μετρικών Μετρικές Διαδικασίας Ανάπτυξης Μετρικές Έργου Μετρικές προϊόντος Τύποι Μετρικών Εσωτερικά Χαρακτηριστικά Εξωτερικά Χαρακτηριστικά Μετρικές και Φάση Ανάπτυξης Λογισμικού Φάση Ανάλυσης Function Points Μετρική Bang

4 3.3.2 Μετρικές για την Ποιότητα των Προδιαγραφών Φάση Σχεδίασης Fan-in/Fan-out Μορφολογικές μετρικές σχεδίασης Μετρικές Φάση Ανάπτυξης Μετρικές Πολυπλοκότητας Άλλες μετρικές βασισμένες στην κυκλωματική πολυπλοκότητα Μέγεθος Κώδικα Halstead s complexity metrics Μετρικές αντικειμενοστραφούς λογισμικού Μέθοδοι ανά κλάση (Weighted Method per Class - WMC) Βάθος δέντρου κληρονομικότητας (Depth of Inheritance Tree - DIT) Αριθμός απογόνων (Number of Children NOC) Σύζευξη μεταξύ κλάσεων (Coupling Between Objects CBO) Απόκριση μιας κλάσης (Response For a Class RFC) Βαθμός συνεκτικότητας των μεθόδων (Lack of Cohesion in Methods LCOM) Fan in και Fan-out κλάσεων Σύζευξη μεταδιδόμενων μηνυμάτων (Message passing coupling MPC) Μέσος Όρος Σύζευξης μεθόδων (Average Method Coupling AMC) Άλλες μετρικές σύζευξης Μετρικές Mood Αντικειμενοστραφής μετρικές Συστήματος RC Martin Μετρικές Αφαίρεσης (Abstraction) Σχέση μεταξύ σταθερότητας και αφαίρεσης

5 3.4 Συσχέτιση μετρικών με σφάλματα λογισμικού Μετρικές και σφάλματα λογισμικού Εμπειρικές μελέτες Isong, Bassey και Obeten, Ekabua Danijel Radjenovic et al Cagatay Catal et al Μελέτες πρόβλεψης λαθών Yue Jiang et al Tibor Gyimothy et al Michael English et al Shihab et al Catal et al Olague et al Grave et al Jureczko Marian Raed Shatnawi et al Foutse Khomh et al Fehmi Jaafar et al Seyyed Ehsan Salamati Taba et al Cristina Marinescu et al Śliwerski, Jacek et al Μετρικές κληρονομικότητας και συσχέτιση με λάθη Κληρονομικότητα, επαναορισμοί μεθόδων και σφάλματα λογισμικού Μετρική επαναορισμού υλοποίησης σε μονοπάτια κληρονομικότητας Περιγραφή της διαδικασίας συλλογής δεδομένων

6 5.2.1 Συλλογή Σχολίων από αποθετήρια κώδικα (SVN) Εύρεση Λαθών από μηνύματα καταχωρήσεων Συλλογή και επεξεργασία SVN Tags Ανάλυση jars και εξαγωγή πληροφοριών των κλάσεων Εξαγωγή μονοπατιών κληρονομικότητας Συσχέτιση των δεδομένων των jars με τις κλάσεις της καταχώρησης Περιγραφή στατιστικών μεθόδων Συσχέτιση Pearson Λογιστική παλινδρόμηση Αποτελέσματα Συμπεράσματα Βιβλιογραφία Παράρτημα Α Χρήση Εργαλείου Παράρτημα Β Αναλυτικά Στατιστικά Αποτελέσματα Bval Camel Mina OpenJPA PdfBox Tomcat Tomcat

7 Ευρετήριο εικόνων Εικόνα 1 Κατηγορίες Μετρικών Εικόνα 2 Διαδικασία Ανάπτυξης Λογισμικού [24] Εικόνα 3 Κατηγορίες μετρικών από Fenton [23] Εικόνα 4 Ποιότητα Λογισμικού [2] Εικόνα 5 Function Points [31] Εικόνα 6 Fan in Fan out [2] Εικόνα 7 Γράφος μορφολογικών μετρικών Εικόνα 8 Παράδειγμα γράφου κυκλωματικής πολυπλοκότητας [2] Εικόνα 9 Παράδειγμα KNOTS σε γράφους κώδικα [2] Εικόνα 10 Γραμμές κώδικα συστημάτων αεροπλάνων και διαστημοπλοίων [40] Εικόνα 11 Θεωρητική προσέγγιση μετρικών αντικειμενοστραφούς κώδικα Εικόνα 12 Παράδειγμα DIT Εικόνα 13 Παράδειγμα NOC Εικόνα 14 Παράδειγμα MPC, RFC, Fan out [43] Εικόνα 15 Διάγραμμα σταθερότητας αφαίρεσης [49] Εικόνα 16 Διάγραμμα διακύμανσης σταθερότητας αφαίρεσης [49] Εικόνα 17 Γνωστική Πολυπλοκότητα [51] Εικόνα 18 Αποτελέσματα Tibor Gyimothy [55] Εικόνα 19 Shihab et al [57] Εικόνα 20 Αποτελέσματα Jureczko [61] Εικόνα 21 Ροή πληροφορίας Seyyed Ehsan Salamati Taba et al [65] Εικόνα 22 Cristina Marinescu και Mihai Codoban ορισμός κλάσης πελάτη [66] Εικόνα 23 Αποτελέσματα Śliwerski [50] Εικόνα 24 Δέντρο SVN [69] Εικόνα 25 Ροές στο SVN [69] Εικόνα 26 Ιστορικό μεταξύ καταχωρήσεων Εικόνα 27 Με σειρά r=-0.9, r=0.0, r= Εικόνα 28 Παράδειγμα Λογιστικής Παλινδρόμησης από το SPSS

8 8

9 Περίληψη Η παρούσα έρευνα έγινε με σκοπό να ερευνηθεί το πεδίο των μετρικών κώδικα και ειδικά των μετρικών του αντικειμενοστραφούς προγραμματισμού καθώς και η συσχέτιση αυτών με την πιθανότητα εμφάνισης σφαλμάτων. Στην προσπάθεια αυτή έγινε εκτενής αναφορά στη μέχρι τώρα έρευνα τόσο στις μετρικές όσο και στις προσπάθειες συσχέτισής τους με σφάλματα. Ακόμη γίνεται αναφορά στις στατιστικές μεθόδους που χρησιμοποιήθηκαν για την εξαγωγή αυτών των συμπερασμάτων. Η αφορμή για τη μελέτη των χαρακτηριστικών της κληρονομικότητας ήταν η διαπίστωση ότι στη βιβλιογραφία υπάρχει ένα κενό στην μελέτη των χαρακτηριστικών της κληρονομικότητας, στις μετρικές της καθώς και στις έρευνες συσχέτισης με λάθη. Ακόμη στη βιβλιογραφία οι μετρικές που χρησιμοποιούνται είναι λίγες, δεν εστιάζουν σε ειδικά χαρακτηριστικά της κληρονομικότητας και τις περισσότερες φορές έχουν αλληλοσυγκρουόμενα αποτελέσματα. Η παρούσα έρευνα με αφορμή το παραπάνω έλλειμμα αλλά και το γεγονός ότι ο επαναορισμός υλοποίησης είναι μη ενδεικνυόμενο μοτίβο μιας και παραβιάζει την αρχή υποκατάστασης Liskov, προσπάθησε να εξετάσει αν μπορεί να υπάρξει συσχέτιση του επαναορισμού υλοποίησης με την εμφάνιση λαθών. Με στόχο τη μέτρηση της έκτασης του φαινομένου του επαναορισμού υλοποίησης σε ένα μονοπάτι κληρονομικότητας δημιουργήθηκε η μετρική Concrete Override Metric (COM) που αποτελεί το πηλίκο του αριθμού των επαναορισμών υλοποίησης σε ένα μονοπάτι κληρονομικότητας προς τον μέγιστο αριθμό των επαναορισμών υλοποίησης που θα μπορούσαν να υπάρξουν στο μονοπάτι αυτό. Για το σκοπό αυτής της εργασίας δημιουργήθηκε λογισμικό το οποίο εξετάζει αποθετήρια κώδικα (SVN) και εξάγει από αυτά πληροφορίες όπως ποια είναι οι καταχωρήσεις που αφορούν διορθώσεις σφαλμάτων, ποιες είναι οι κυκλοφορίες του κάθε έργου που βγήκαν στην παραγωγή (tags). Ταυτόχρονα εξετάζονται οι κυκλοφορίες του εξεταζόμενου λογισμικού και από αυτές δημιουργούνται τα μονοπάτια κληρονομικότητας της κάθε έκδοσης. Στη συνέχεια το λογισμικό συσχετίζει τις κλάσεις αυτές με τις καταχωρήσεις του πρώτου βήματος και έτσι δημιουργείται ένα σύνολο αποτελεσμάτων που μας λέει πως κάθε μονοπάτι κληρονομικότητας συνδέεται με τη διόρθωση ενός ή περισσοτέρων σφαλμάτων. Τέλος τα δεδομένα της κάθε έκδοσης περνάνε από στατιστική ανάλυση στο SPSS. Συγκεκριμένα για κάθε έκδοση του λογισμικού υπολογίζεται η 9

10 συσχέτιση Pearson στην προσπάθεια να συσχετιστεί ο αριθμός σφαλμάτων με το μήκος του μονοπατιού κληρονομικότητας, τη μετρική COM και τον απόλυτο αριθμό των επαναορισμών υλοποίησης και στη συνέχεια εκτελείται Λογιστική Παλινδρόμηση για να εξεταστεί αν μπορεί να υπάρξει ένα μοντέλο πρόβλεψης της ύπαρξης ή μη λαθών. Τα έργα που εξετάστηκαν ήταν όλα από το Apache Foundation, συγκεκριμένα τα: Bcel, Camel, Mina, OpenJPA, PdfBox, Tomcat 7 και Tomcat 8. Τα αποτελέσματα μπορεί να τα δει κανείς από δύο όψεις. Αρχικά μπορεί κάποιος να πει ότι δεν υπάρχει συσχέτιση μεταξύ των λαθών και των επαναορισμών υλοποίησης συνεπώς, ο επαναορισμός υλοποίησης δεν προκαλεί λάθη. Στη συνέχεια όμως μπορεί κάποιος με μια πιο προσεκτική ματιά να εστιάσει στο ότι υπήρχε συσχέτιση, άλλες φορές ισχυρή και άλλες ανίσχυρη, με τον αριθμό των επαναορισμών που σημαίνει ότι υπάρχει χώρος για περαιτέρω διερεύνηση. 10

11 Abstract This thesis was written for the purpose of researching the field of code metrics, especially objectoriented code metrics, to find out if there is a correlation of metrics with software bugs. Furthermore, this thesis also includes an extended review of current research of software metrics field but also research about the association between software metrics and bug occurrence and the statistical methods used in order to make this association. An inspiration for this thesis was the lack of research papers found, which study inheritance characteristics and inheritance metrics, as well as its association with software bugs. We only found a few studies where the above was in research questions, and their results most of the time were either non-conclusive or conflicting. Given the lack of research and the fact that concrete overriding is an anti-pattern, as it violates the Liskov substitution principle, this thesis tries to answer the question if there is a correlation between concrete overriding and software bugs occurrence. In order to represent how intense was the concrete override phenomenon in a class inheritance path, we created a metric called Concrete Override Metric (COM). COM is defined as the division of actual concrete overrides found in a class hierarchy path to the maximum number of overrides which is possible in the inheritance path. For the purpose of studying the relation between COM and error occurrence we created special software which has capabilities of iterating through SVN repositories, finding the commits that are bug fixes and also find repository tags. Then it takes as input a given set of jar files (one for each version - tag) and extracts class hierarchy paths as well as its metrics (COM, actual concrete overrides and maximum possible overrides). Then the software examines the commit data as well as hierarchy path data and finds out how many bugs each hierarchy path class was involved in, so it can calculate the total bug count for the hierarchy path. Then the data of hierarchy path, its calculated metrics and bug count is extracted and used as input to the SPSS so it can calculate Pearson correlation to find out if there is a correlation with any of the hierarchy path metrics and the bug count. We also used Logistic Regression to find out if the combination of actual overrides and maximum possible overrides in a hierarchy path can predict the existence of a bug. 11

12 We look at the Apache Foundation to find solid software projects to examine. We choose: Bcel, Camel, Mina, OpenJPA, PdfBox, Tomcat7 and Tomcat8. The results can be misleading. At first glance, someone can suggest that there is no correlation between concrete overriding and bug occurrence but a more careful look will notice that there is correlation between bug occurrence and actual overrides found in the class hierarchy path. This correlation most of the time is somewhat moderate, but there are examples of high correlation found in the results, so there is motive for future work to carefully study this correlation. 12

13 1 Εισαγωγή Η παρούσα έρευνα αποτελεί μία μελέτη πάνω στις μετρικές κώδικα. Στόχος της μελέτης αυτής είναι να εξεταστεί το ερώτημα σχετικά με το αν υπάρχει συσχέτιση των μετρικών κώδικα με την ύπαρξη σφαλμάτων και ειδικότερα πως η μετρική μέτρησης των επαναορισμών υλοποίησης που προτείνεται επηρεάζει την εμφάνιση σφαλμάτων. Αναλυτικότερα, η παρούσα εργασία ξεκινά στο κεφάλαιο 2, προσπαθώντας να απαντήσει το ερώτημα, τι είναι μετρική κώδικα, καθώς και να κάνει μία εκτενή ανάλυση πάνω στα χαρακτηριστικά που πρέπει να έχει μία μετρική. Γίνεται ανάλυση των διάφορων επιπέδων στα οποία μπορούν να χωριστούν οι μετρικές προσπαθώντας να αντικατοπτρίσουν την έννοια της ποιότητας σε ένα έργο λογισμικού. Στη συνέχεια στο κεφάλαιο 3 ακολουθεί παρουσίαση των πιο διαδεδομένων μετρικών κώδικα χωρισμένες στα διάφορα επίπεδο όπως αυτά παρουσιάστηκαν στο κεφάλαιο 2. Τέλος στο κεφάλαιο 4 εξετάζεται στο πεδίο της συσχέτισης μετρικών με την ύπαρξη ή την πιθανότητα εμφάνισης λαθών σε έργα κώδικα. Η έρευνα της βιβλιογραφίας τεκμηρίωσε την αίσθηση ότι υπάρχει ένα κενό σε ότι αφορά το αντικείμενο της μελέτης των χαρακτηριστικών της κληρονομικότητας, μέσω μετρικών και τη συσχέτιση αυτών με την ύπαρξη λαθών. Στην παρούσα έρευνα έγινε μία προσπάθεια να καλυφθεί ένα μικρό μέρος αυτού του θέματος. Το πρόβλημα που επιλέχθηκε είναι ο επαναορισμός υλοποίησης και κατά πόσο αυτή η μη ενδεδειγμένη πρακτική [1] επηρεάζει την εμφάνιση λαθών στον κώδικα. Αναλυτικότερα, παρουσιάζεται το εργαλείο που δημιουργήθηκε, το οποίο εξετάζει αποθετήρια κώδικα, τις κυκλοφορίες του λογισμικού και τα μονοπάτια κληρονομικότητας που περιέχει κάθε έκδοση του λογισμικού και συσχετίζει τα λάθη και τις κλάσεις που τα συνοδεύουν στο αποθετήριο με τα μονοπάτια κληρονομικότητας που υπολογίζονται στις κυκλοφορίες του λογισμικού. Το λογισμικό είναι ικανό να αποθηκεύσει όλα αυτά τα στοιχεία που προκύπτουν από τη διαδικασία σε μία βάση δεδομένων. Στη συνέχεια χρησιμοποιήθηκε το SPSS για να γίνει στατιστική ανάλυση πάνω στα αποτελέσματα που το πρόγραμμα συλλέγει. Χρησιμοποιήθηκε συσχέτιση Pearson σε μία προσπάθεια να βρεθεί αν υπάρχει γραμμική σχέση μεταξύ του αριθμού των σφαλμάτων μίας κλάσης ενός μονοπατιού κληρονομικότητας και της μετρικής των επαναορισμών υλοποίησης αλλά και με τον απόλυτο αριθμό των επαναορισμών υλοποίησης. Ακόμη χρησιμοποιήθηκε η μέθοδος της Λογιστικής Παλινδρόμησης για να εξεταστεί το κατά πόσο είναι δυνατό το σύνολο των επαναορισμών 13

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

15 2 Βασικές Έννοιες 2.1 Εισαγωγή Η εξέλιξη του λογισμικού σήμερα οφείλεται σε μια σειρά από παράγοντες όπως είναι: η προσθήκη νέων χαρακτηριστικών για την κάλυψη των επιχειρησιακών αναγκών, η εισαγωγή νέων τεχνολογιών, η διόρθωση σφαλμάτων, η βελτίωση της ποιότητας και άλλα. Η συσσώρευση των αλλαγών που προέρχονται από τα παραπάνω, μπορεί να οδηγήσει όμως σε υποβάθμιση της ποιότητας του λογισμικού [2]. Είναι σημαντικό λοιπόν να παρακολουθείται ο τρόπος με τον οποίο εξελίσσεται η ποιότητα του, ώστε να μπορούν να σχεδιαστούν σωστά οι δραστηριότητες διασφάλισης της. Σε όλες σχεδόν τις διαδικασίες ανάπτυξης λογισμικού, η ποιότητα του τελικού προϊόντος συνδέεται στενά με τις μετρικές που χρησιμοποιούνται για την παρακολούθηση των διάφορων παραγόντων ποιότητας. Πιο συγκεκριμένα, οι μετρικές του λογισμικού χρησιμοποιούνται καθώς μπορούν να συμβάλλουν στην πρόληψη σφαλμάτων και ελαττωμάτων στην ανάπτυξη του λογισμικού. Τα παραπάνω αφορούν όλα τα στάδια του κύκλου ανάπτυξης του προϊόντος αλλά και την παρακολούθηση του κατά τη διάρκεια ζωής του. Για να μπορέσει να κάνει πιο κατανοητή την έννοια της μετρικής ο Handersron-Sellers [2] παρουσιάζει το επόμενο παράδειγμα: Μέλη μιας συγκεκριμένης ομάδας ανάπτυξης λογισμικού έχουν επιλεχτεί να συμμετάσχουν σε ένα πείραμα. Αυτό αφορά τη μέτρηση κάποιων συγκεκριμένων χαρακτηριστικών που αφορούν την ομάδα όπως για παράδειγμα το ύψος τους, το πόσοι είναι υπέρβαροι και την παραγωγικότητα τους (αντιστοιχεί στον αριθμό γραμμών κώδικα που έγραψαν μία συγκεκριμένη μέρα). Το ύψος είναι μία μεταβλητή που μπορεί εύκολα να μετρηθεί. Υπάρχουν όμως άλλα σημεία του πειράματος που είναι προβληματικά. Για παράδειγμα, το αν είναι κάποιο άτομο υπέρβαρο επηρεάζεται από τα χαρακτηριστικά του ύψους και του βάρους. Το βάρος όμως δεν ανήκει στα χαρακτηριστικά του πειράματος που αρχικά ζητήθηκε να καταγραφούν. Αν θεωρηθεί ότι το βάρος (W) και το ύψος (H) είναι ανεξάρτητες μεταβλητές και η μεταβλητή που ορίζει το αν είναι υπέρβαρος (O) εξαρτημένη, τότε για κάθε άτομο i προκύπτει η παρακάτω εξίσωση: f o (H i, W i ) = { 0 1 Ένα άλλο πρόβλημα αφορά τις γραμμές κώδικα (Lines of Code - LOC). Σίγουρα μπορούν να μετρηθούν οι LOC που γράφτηκαν σε μια δεδομένη ημέρα, αλλά πρέπει πρώτα να οριστεί με σαφήνεια ο ορισμός του τι είναι «γραμμές κώδικα» (π.χ. αν επιτρέπονται οι πολλαπλές δηλώσεις 15

16 σε μια γραμμή, τα σχόλια κτλ.). Επίσης, είναι προφανές ότι δεν υπάρχει άμεση σύνδεση μεταξύ των LOC και της παραγωγικότητας τουλάχιστον ποιοτικού κώδικα [3]. Σε τέτοια πειράματα επίσης θα πρέπει να περιλαμβάνονται και άλλοι παράγοντες οι οποίοι μπορεί να επηρεάσουν το δείγμα, όπως τα χρόνια εμπειρίας του προγραμματιστή και το περιβάλλον ανάπτυξης του λογισμικού αλλά και η γλώσσα που χρησιμοποιείται. Οι μετρικές που πληρούν αυτές τις προϋποθέσεις θα πρέπει να δηλώνεται ρητά ότι έγιναν σε συγκεκριμένο περιβάλλον. Η διαφορά εδώ βρίσκεται μεταξύ εσωτερικών (LOC) και εξωτερικών μεταβλητών (ποιότητα κώδικα). Μια εσωτερική μεταβλητή όπως η LOC μπορεί να μετρηθεί αντικειμενικά καθώς όλες οι μετρήσεις καταλήγουν στην ίδια τιμή. Αντίθετα, μεταβλητές όπως η ποιότητα, η παραγωγικότητα και η συντηρισιμότητα που επηρεάζονται από τον ανθρώπινο παράγοντα, πολλές φορές είναι αδύνατο να οριστούν ή να μετρηθούν αντικειμενικά. Αυτός είναι ο λόγος που έχουν γίνει αντικείμενο έρευνας. Ο Sellers [2] με βάση το παραπάνω παράδειγμα συμπεραίνει ότι είναι δυνατό να οριστούν έννοιες όπως το ύψος, το βάρος και η παραγωγικότητα του ατόμου. Όσον αφορά το τελευταίο, η παραγωγικότητα πρέπει να συνυπολογιστεί με ένα αριθμό μετρήσεων (όπως για παράδειγμα μέσος, διάμεσος κτλ.) και σε βάθος χρόνου. Στην περίπτωση του λογισμικού όμως, είναι δύσκολο να βγάλεις συμπεράσματα για την ποιότητα, τη συντηρισιμότητα ή την πολυπλοκότητα του. Γενικότερα, έννοιες όπως οι παραπάνω αποτελούν εξωτερικές μεταβλητές οι οποίες επηρεάζονται από την αντίληψη του παρατηρητή για αυτές. 2.2 Επιστημονική προσέγγιση Ο Tycho Brahe έκανε ένα μεγάλο αριθμό παρατηρήσεων σχετικά με τις κινήσεις στο ηλιακό σύστημα στα τέλη του 16ου αιώνα. Συνέθεσε πάρα πολλούς αριθμούς, ανέλυσε τα δεδομένα και αναγνώρισε τα αντίστοιχα μοτίβα. Ο Johannes Kepler από την άλλη, ξεκίνησε να μορφοποιεί μαθηματικά μοντέλα για να υποστηρίξει αυτά τα δεδομένα. Ο Boehm [4] χρησιμοποιεί τα παραπάνω παραδείγματα για να αποδείξει ότι στην περίπτωση του λογισμικού είναι απαραίτητο να εφαρμόζεται η επιστημονική προσέγγιση τόσο των Kepler και αλλά και Brahe. Βασιζόμενος στα παραπάνω ο Sellers [2] διαπιστώνει ότι ούτε η συλλογή δεδομένων ούτε η θεωρητική προσέγγιση είναι από μόνες τους αρκετές. Μια επιστημονική θεωρία πρέπει να βασίζεται πάνω στην συνέργεια αυτών των δύο. Ως εκ τούτου, μοτίβα στα δεδομένα μπορεί να εξηγούνται με τους όρους της θεωρίας. Ταυτόχρονα, οι θεωρίες χρειάζονται επικύρωση με χρήση επαρκούς ποσότητας ποιοτικών δεδομένων. Υπάρχει η τάση της απόλυτη εμπιστοσύνης στα 16

17 δεδομένα που οδηγεί στο λανθασμένο ορισμένες φορές συμπέρασμα, ότι αν τα δεδομένα δεν τεκμηριώνουν την θεωρία, τότε η θεωρία πρέπει να απορριφθεί. Είναι σημαντικό να τονίσουμε ότι σε πολλές περιπτώσεις στις οποίες η θεωρία δεν συμφωνεί με τα δεδομένα, τότε τα δεδομένα είναι λάθος και ως εκ τούτου αυτά πρέπει να απορριφτούν και όχι η θεωρία. Στην περίπτωση των μετρικών λογισμικού, πρέπει πρώτα να οριστούν σαφώς ο πληθυσμός και τα χαρακτηριστικά του προς μέτρηση λογισμικού και δεύτερον να σχεδιαστούν οι κατάλληλες μετρήσεις για αυτά τα χαρακτηριστικά μαζί με τα αντίστοιχα εργαλεία. Με τον τρόπο αυτό επιτυγχάνεται η παραπάνω επιστημονική προσέγγιση: η συλλογή δεδομένων και αναζήτηση μοτίβων και ταυτόχρονα ο ορισμός θεωριών οι οποίες μπορεί να έχουν μια πιο σφαιρική εφαρμογή. Ο Card [5] επισημαίνει ότι η «τέλεια μέτρηση» βασίζεται σε μια άμεμπτη θεωρία και υποδεικνύει ότι πρέπει να έχει «υψηλές συσχετίσεις» με το χαρακτηριστικό που επιθυμούμε να εκτιμήσουμε. 2.3 Μέτρο, Μέτρηση και Μετρική Στη βιβλιογραφία υπάρχει εκτενής αναφορά στη διαφορά μεταξύ των εννοιών του μέτρου (measure), της μέτρησης (measurement) και της μετρικής (metric). Το μέτρο είναι η ποσοτική ένδειξη αριθμού, διαστάσεων, χωρητικότητας, όγκου ενός προϊόντος ή μίας διαδικασίας όπως του αριθμού λαθών σε ένα πρόγραμμα. Η μέτρηση αναφέρεται στη διαδικασία υπολογισμού του μέτρου όπως η συλλογή και η καταμέτρηση λαθών. Τέλος, μετρική είναι η ποσοτική εκτίμηση του βαθμού κατά τον οποίο ένα σύστημα κατέχει ένα χαρακτηριστικό. Για παράδειγμα, πάνω από 100 λάθη δηλώνει κακή ποιότητα, αλλιώς καλή ποιότητα. Σύμφωνα με τον Sellers [2], η μετρική είναι μία συνάρτηση με δύο μεταβλητές, ενώ το μέτρο είναι η αριθμητική τιμή ενός συγκεκριμένου χαρακτηριστικού. Στην περίπτωση του μέτρου, αυτό έχει εκτιμηθεί σε σύγκριση με μία συγκεκριμένη μονάδα. Υπάρχουν όμως περιπτώσεις στη βιβλιογραφία, στις οποίες οι δύο λέξεις χρησιμοποιούνται με τον ίδιο τρόπο. Τη διαφορά μέτρου, μέτρησης και μετρικής ανέφερε και ο Fenton [3]. Κατά τον Fenton, μέτρηση ονομάζεται η διαδικασία κατά την οποία οι αριθμοί και τα σύμβολα συνδέονται µε ιδιότητες οντοτήτων του πραγματικού κόσμου έτσι ώστε να τα περιγράφουν σύμφωνα µε αυστηρά καθορισμένους κανόνες. Μία μετρική ορίζει ένα απλό χαρακτηριστικό ενώ το μέτρο αποτελεί μία συνάρτηση μετρικών [6] η οποία χρησιμοποιείται για την αξιολόγηση πιο σύνθετων χαρακτηριστικών όπως η ποιότητα και η πολυπλοκότητα. 17

18 Σε κάθε περίπτωση, γίνεται σαφές ότι η χρήση των παραπάνω όρων δεν είναι αυστηρή στο εύρος της βιβλιογραφίας. Η επιτυχημένη χρήση κρίνεται από τον τρόπο που τα μέτρο, η μέτρηση ή οι μετρικές θεμελιώνονται από τη θεωρία και είναι επαρκώς διακριτές. 2.4 Επικύρωση των μετρικών Η επικύρωση των μετρικών είναι μία δύσκολη διαδικασία και έχει οδηγήσει σε κατάχρηση της επιστημονικής μεθόδου. Έχει παρατηρηθεί ότι πολλές μετρικές έχουν επικυρωθεί με μόνο μια ομάδα δεδομένων. Αυτό από μόνο του δεν καθιστά την διαδικασία της επικύρωσης εσφαλμένη, αλλά δεν μπορεί να χρησιμοποιηθεί παρά μόνο για να αποδείξει μια πολύ περιορισμένη και προσεκτική χρήση των μετρικών. Μια παραλλαγή αυτού είναι η χρήση πολλαπλών τεχνικών που συνδυάζουν μία ομάδα μετρήσεων σε ένα μοναδικό αριθμό πολυπλοκότητας [2]. Μια δεύτερη τεχνική επικύρωσης είναι αυτή της συσχέτισης. Μια καλή προσέγγιση της επαγωγικής στατιστικής απαιτεί την a priori δήλωση της υπόθεσης. Ακολουθώντας αυτή την δήλωση γίνεται ξεκάθαρο ποιες οντότητες πρέπει να μετρηθούν. Για παράδειγμα η υπόθεση μπορεί να είναι ότι δεν υπάρχει διαφορά στο μέσο αριθμό των λειτουργιών ανά κλάση, για συστήματα ίδιου σχεδιασμού που έχουν γραφτεί σε δύο διαφορετικές γλώσσες προγραμματισμού. Αυτό που συχνά χρησιμοποιείται και έχει επικριθεί από τους Courtney και Gustafson [7] είναι: 1. η συλλογή μεγάλης ποσότητας δεδομένων 2. η συσχέτιση κάθε μέτρησης με κάθε άλλη μέτρηση 3. η αναγνώριση της σωστής συσχέτισης και μόνο τότε 4. η αναγνώριση μιας υπόθεσης της έρευνας. Αυτή την εσφαλμένη προσέγγιση την ονομάζουν «κυνηγητική» προσέγγιση. Μια τρίτη λανθασμένη προσέγγιση είναι η συσχέτιση της νέας μέτρησης με μια παλιά και ο Fenton παρατήρησε τη διαδεδομένη χρήση αυτής της τεχνικής [8]. 2.5 Μετρικές και Οριακές Τιμές Μια εφαρμογή των εσωτερικών μετρικών η οποία χρησιμοποιείται συχνά από τους μηχανικούς λογισμικού κατά τη διάρκεια της ανάπτυξης είναι ο ορισμός της οριακής τιμής ή της τιμής συναγερμού. O συναγερμός μπορεί να ενεργοποιηθεί όταν μια τιμή μια συγκεκριμένης εσωτερικής μετρικής ξεπεράσει ένα προκαθορισμένο όριο. Οι οριακές τιμές πρέπει να 18

19 χρησιμοποιούνται απλά για να τραβήξουν την προσοχή σε ένα το συγκεκριμένο προβληματικό κομμάτι του κώδικα. Μια άλλη εναλλακτική θα ήταν να προκαθορίσουμε τρία εύρη τιμών για κάθε μετρική: ασφαλές εύρος σημείο καμπής επικίνδυνο Έτσι χωρίς να γίνει υπόθεση για αιτιότητα, τα παραπάνω θα μπορούσαν να επιστήσουν την προσοχή σε ένα συγκεκριμένο κομμάτι προγράμματος ώστε αυτό να αξιολογηθεί περαιτέρω [2]. Τέλος, να σημειωθεί ότι τα παραπάνω δεν μπορούν να είναι απόλυτες τιμές, αλλά σχετικές και εξαρτώμενες από το προγραμματιστικό περιβάλλον και την πολυπλοκότητα του προβλήματος [9]. 2.6 Ιδιότητες των Μετρικών Λογισμικού Πολλοί συγγραφείς έχουν ασχοληθεί με την καταγραφή των επιθυμητών ιδιοτήτων των μετρικών λογισμικού. Σε γενικές γραμμές, αυτές πρέπει να είναι: αντικειμενικές, η τιμή τους δηλαδή να υπολογίζεται με ακριβή τρόπο. Πρέπει ακόμη, να έχουν μία μορφή εσωτερικής εγκυρότητας [10]. Για να είναι χρήσιμη, μία μετρική πρέπει να είναι εύρωστη. Επιπρόσθετα, μία μετρική πρέπει να παρέχει πληροφορίες τέτοιες ώστε ο προγραμματιστής να μπορεί να βελτιώσει το σχεδιασμό του [11]. Τέλος, μια μετρική πρέπει να μπορεί να χρησιμοποιηθεί στα πλαίσια της στατιστικής ανάλυσης. Στις επόμενες παραγράφους παραθέτουμε κάποιες από τις αντίστοιχες αναφορές στη βιβλιογραφία. Schneidewind Ο Schneidewind πρότεινε κάθε μετρική να είναι συνδεδεμένη με ένα συγκεκριμένο παράγοντα ποιότητας και μια συγκεκριμένη συνάρτηση ποιότητας. Σημειώνει ακόμα ότι μια μετρική πρέπει να είναι συνεπής, επαναλαμβανόμενη, και ικανή να παρακολουθεί τις αλλαγές που γίνονται στην οντότητα. Τέλος, πιστεύει ότι για να είναι χρήσιμη μια μετρική θα πρέπει να έχει δυνατότητες πρόβλεψης. Αυτό σημαίνει ότι μια μετρική είναι χρήσιμη αν για παράδειγμα μπορεί να χρησιμοποιηθεί κατά τη διαδικασία της εκτίμησης. Αυτή είναι όμως η αντίθεση μεταξύ της περιγραφικής στατιστικής και της επαγωγική στατιστικής. Και τα δύο είναι χρήσιμα αλλά δίνουν διαφορετικές πληροφορίες [12]. 19

20 Kearny et al. Στο [13] τονίζεται η σημασία του ανθρώπινου παράγοντα στον ορισμό μιας μετρικής διότι, ένας προγραμματιστής είναι πάντα μέρος της ανάπτυξης λογισμικού. Πιστεύει επίσης ότι οι μετρικές με ευρύτερο χαρακτήρα δεν έχουν χρησιμότητα. Για να είναι χρήσιμη μια μετρική, πρέπει να έχει δημιουργηθεί για συγκεκριμένες εφαρμογές. Για παράδειγμα, τα function points έχει φανεί ότι είναι χρήσιμα για τα πληροφοριακά συστήματα αλλά όχι για μηχανικά συστήματα. Οι συγγραφείς παραθέτουν επίσης μια σειρά από ιδιότητες για τις μετρικές όπως για παράδειγμα: ευρωστία, κανονικοποίηση και άλλες. Η ευρωστία τείνει να σημαίνει εσωτερική εγκυρότητα. Αν μια οντότητα αλλάξει και η μετρική αυξηθεί σε τιμή, τότε η οντότητα θα έπρεπε να αυξηθεί με βάση την ιδιότητα της μετρικής. Είναι δύσκολο, αν όχι αδύνατο να εξηγήσει κανείς την αξιολόγηση μιας οντότητας όσον αφορά μια ιδιότητα αν δεν έχει αναπτυχθεί μια συγκεκριμένη σειρά από τιμές για αυτή την ιδιότητα. Παρ όλα αυτά πρέπει να αναφερθεί ότι δεν είναι πιθανό να αναπτυχτεί ένα πρότυπο μέχρι να προκύψουν αρκετές μετρικές. Η εξειδίκευση αφορά την ιδέα ότι μια μετρική πρέπει να είναι συνδεδεμένη με μια ιδιότητα της οντότητας που μετριέται. Αν η μετρική είναι συνδεδεμένη με παραπάνω ιδιότητες, τότε πρέπει να αξιολογηθεί ξεχωριστά για κάθε μία. Brito e Abreu Εδώ [14] οι ερευνητές εστίασαν στα στάδια του κύκλου ζωής του λογισμικού και τη σχέση του με τον έλεγχο ποιότητας. Ο συγγραφέας προτείνει την εκτενή και συγκριτική αξιολόγηση μετρικών σε όλο το εύρος της κοινότητας του αντικειμενοστραφούς προγραμματισμού έτσι ώστε να βρεθούν οι βέλτιστες τεχνικές σχεδιασμού. Προτείνει μάλιστα την υιοθέτηση των επόμενων επτά κριτηρίων: Ο προσδιορισμός των μετρικών πρέπει να είναι επίσημα καθορισμένος. Μετρικές χωρίς μέγεθος πρέπει να είναι ανεξάρτητες του μεγέθους του συστήματος. Οι μετρικές δεν πρέπει να έχουν διαστάσεις ή να εκφράζονται με κάποια μονάδα μέτρησης. Οι μετρικές θα πρέπει να είναι προσιτές από την αρχή του κύκλου ζωής. Οι μετρικές πρέπει να είναι εύκολα υπολογίσιμες. Οι μετρικές πρέπει να είναι ανεξάρτητες από τη γλώσσα προγραμματισμού. Sheetz et al. Εδώ [15] οι συγγραφείς προτείνουν τα παρακάτω σχετικά με τις ιδιότητες που αφορούν μετρικές πολυπλοκότητας: Πρέπει να περιλαμβάνουν μια μετρική σχετική με τη δομή των δεδομένων. 20

21 Οι μετρικές πρέπει να έχουν συνοχή. Οι μετρικές πρέπει να αντιπροσωπεύουν τουλάχιστον ένα είδος αδύναμης διάταξης. Οι μετρικές πρέπει να είναι αθροιστικές δηλαδή ότι η συνολική πολυπλοκότητα της συνδυαστικής δομής είναι το άθροισμα των πολυπλοκοτήτων των ανεξάρτητων δομών. Οι μετρικές πρέπει να μπορούν να αυτοματοποιηθούν. Ο Sellers [1], κάνοντας μια επισκόπηση της παραπάνω βιβλιογραφίας καταλήγει στα εξής συμπεράσματα. Για να είναι χρήσιμη μια μετρική, πρέπει να είναι τουλάχιστον: Έγκυρη: Γενικά, μια μετρική είναι έγκυρη αν μετράει αυτό φτιάχτηκε για να μετράει. Πρακτική: H πρακτικότητα μιας μετρικής αφορά το θέμα της οικονομίας δηλαδή πόσο κοστίζει να υπολογιστεί, την ευκολία, δηλαδή ποσό εύκολο είναι να υπολογιστεί, και τη διαλειτουργικότητά της, δηλαδή πόσο εύκολο είναι να ερμηνεύσουμε τα αποτελέσματα του υπολογισμού της. Αξιόπιστη: Μια μετρική είναι αξιόπιστη αν η εφαρμογή του αλγορίθμου παράγει το πάντα το ίδιο αποτέλεσμα υπό τις ίδιες συνθήκες. Σημειώνει επίσης, ότι μια μετρική μπορεί να είναι αξιόπιστη αλλά όχι έγκυρη. Για παράδειγμα, το Source Lines of Code (SLOC) θα μπορούσε να χρησιμοποιηθεί ως μετρική της πολυπλοκότητας. Ο αλγόριθμος που μετράει το SLOC θα μπορούσε να οριστεί ως ο αριθμός των ερωτηματικών ( ; ) σε ένα πρόγραμμα γραμμένο σε C. Αυτή η μετρική θα μπορούσε να θεωρηθεί αξιόπιστη. Παρόλα αυτά η εγκυρότητα της μπορεί να αμφισβητηθεί. Με άλλα λόγια, δεν υπάρχει ένα αντικειμενικό μοντέλο το οποίο να συνδέει το μέγεθος και την πολυπλοκότητα Εγκυρότητα Έχουν αναγνωριστεί πολλοί διαφορετικοί τύποι εγκυρότητας στην βιβλιογραφία [8] [3] [2]. Εν γένει μπορούν να χωριστούν σε 3 κατηγορίες. Κατ όψη (face validity), εσωτερικές και εξωτερικές. Η εγκυρότητα κατ όψη δεν είναι τύπος εγκυρότητας, αλλά υποδηλώνει ότι μια μέτρηση φαίνεται να είναι έγκυρη με την πρώτη ματιά. Συνεπώς, είναι χρήσιμες μόνο από πρακτική πλευρά. Αν μια μέτρηση δεν φαίνεται έγκυρη με την πρώτη ματιά, είναι αμφίβολο αν θα υιοθετηθεί, γεγονός που δεν μπορεί να παραλειφθεί εύκολα. Η εσωτερική εγκυρότητα ασχολείται με το πόσο καλά μια μετρική δείχνει τις διαφορές στις τιμές των χαρακτηριστικών των πραγματικών οντοτήτων που μετρούνται. Για παράδειγμα, χρησιμοποιώντας το παράδειγμα του SLOC, το οποίο συγκρίνει δύο προγράμματα γραμμένα σε 21

22 C, βασιζόμενο στο μέγεθος/μήκος του χαρακτηριστικού αν ο αριθμός των semicolons είναι μεγαλύτερος, τότε το ένα πρόγραμμα είναι μεγαλύτερο από το άλλο. Αυτή η μετρική θα μπορούσε να έχει μια μορφή εσωτερικής εγκυρότητας αν μπορούσε να συμπεριλάβει τη σημασία του μήκους δηλαδή πόσο πιο μεγάλο είναι το ένα πρόγραμμα από το άλλο. Υπάρχουν τρεις γενικές μορφές εσωτερικής εγκυρότητας που έχουν οριστεί: εγκυρότητα σχετικά με το περιεχόμενο, σχετικά με κάποιο κριτήριο και σχετικά με την κατασκευή. Η εγκυρότητα σχετικά με το περιεχόμενο δείχνει πόσο καλά μία μετρική καλύπτει το χαρακτηριστικό το οποίο μετράται. Πηγαίνοντας πίσω στη μετρική του μήκους (αριθμός semicolons), θα σήμαινε το πόσο καλά δείχνει την κατανόηση για το μήκος ενός χαρακτηριστικού. Υπάρχουν όμως διάφορα ερωτήματα σχετικά με το μήκος ενός χαρακτηριστικού όπως: Τι εννοούμε μήκος ενός προγράμματος; Από την άποψη της εγκυρότητας περιεχομένου, ο αριθμός των bytes του πηγαίου κώδικα πρέπει να αποθηκευτούν στο δίσκο για να μετρηθούν; Ο Sellers καταλήγει [2] ότι μια προσέγγιση για να μπορεί να καθοριστεί το επίπεδο της εγκυρότητας περιεχομένου, είναι να χρησιμοποιήσουμε μια ομάδα ειδικών για να κρίνουν την κάλυψη της μετρικής ως προς ένα χαρακτηριστικό. Η εγκυρότητα σχετικά με κάποιο κριτήριο δείχνει πόσο καλά μια μετρική προβλέπει ένα μελλοντικό γεγονός ή πόσο καλά εκτιμάει μια τωρινή συνθήκη. Για παράδειγμα, μια μετρική σχεδιασμού για το μήκος/μέγεθος ενός προγράμματος θα μπορούσε να χρησιμοποιηθεί για να προβλέψει το μέγεθος του προγράμματος. Το δύσκολο μέρος της εγκυρότητας σχετικά με κάποιο κριτήριο είναι η ταυτοποίηση του κριτηρίου που θα χρησιμοποιηθεί για να δείξει αν η μετρική είναι έγκυρη η όχι. Η δομική εγκυρότητα, ασχολείται με την ταυτοποίηση των χαρακτηριστικών μιας οντότητας, τις διάφορες μετρικές των χαρακτηριστικών και τις θεωρίες πάνω στις οποίες βασίζονται. Για παράδειγμα, η πολυπλοκότητα, η οποία είναι ένα εξωτερικό χαρακτηριστικό, πρέπει να οριστεί με βάση κάποια θεωρία. Αλλιώς, δε μπορεί να είναι σαφές τι σημαίνει πολυπλοκότητα. Από τη στιγμή που το χαρακτηριστικό (πχ πολυπλοκότητα) βγάζει νόημα από θεωρητικής άποψης, τότε η αντίστοιχη μετρική ή μια σειρά από μετρικές που θα δημιουργηθούν, θα χρησιμοποιηθούν για να μετρηθεί το χαρακτηριστικό αυτό. Ο Sellers [2] σημειώνει ακόμα ότι 22

23 αν δοθεί μια έγκυρη μετρική ενός χαρακτηριστικού, η νέα μετρική θα μπορούσε να συσχετιστεί με την υπάρχουσα. Αυτό οδηγεί στην αθροιστική εγκυρότητα, ένα τύπο της δομικής εγκυρότητας. Οι δύο μετρικές πρέπει να είναι θεωρητικά σωστές και ότι η αρχική μετρική πρέπει να έχει θεωρηθεί έγκυρη ως προς συγκεκριμένο χαρακτηριστικό. Η εξωτερική εγκυρότητα αφορά το θέμα της δυνατότητας γενίκευσης. Υπάρχουν συγκεκριμένα ερωτήματα σχετικά με το παραπάνω. Μπορεί μία μετρική να γενικευθεί πέραν από τα δείγματα οντοτήτων τα οποία έχουν μετρηθεί; Για παράδειγμα, χρησιμοποιώντας οποιοδήποτε μέθοδο μέτρησης μεγέθους ενός προγράμματος, είναι δυνατόν να υπάρχει δυνατότητα γενίκευσης πέρα από τα όρια του αρχικού προγράμματος που μετρήθηκε; Αν η μέτρηση αφορά δύο προγράμματα C τότε ναι ισχύει. Αν όμως γίνει γενίκευση σε προγράμματα COBOL η μετρική θα αποτύγχανε. Ακόμη, πολλές μετρικές έχουν προταθεί γιατί χρειάζεται να «βαθμονομηθούν» για ένα συγκεκριμένο περιβάλλον [10]. Σε αυτή την περίπτωση, η μετρική δεν είναι εξωτερικά έγκυρη. Αντίθετα με την εσωτερική εγκυρότητα, η εξωτερική εγκυρότητα δε μπορεί να καθοριστεί πειραματικά. Στην πραγματικότητα, σπάνια μπορεί να επιτευχθεί [16] [17] Αξιοπιστία Η αξιοπιστία είναι χρήσιμη, αλλά όχι επαρκής ιδιότητα της μέτρησης. Όπως έχει παρατηρηθεί η αξιοπιστία διευθετεί το αν η μέτρηση παράγει συνεπή αποτελέσματα. Υπάρχουν δύο θέματα που σχετίζονται με την αξιοπιστία: σταθερότητα και ισοδυναμία. Η σταθερότητα έχει να κάνει με την ιδέα ότι η μέτρηση πρέπει να παράγει τα ίδια αποτελέσματα δοθείσας ίδιας οντότητας στο ίδιο περιβάλλον. Ανάλογα με τον τύπο της μέτρησης, δύο πιθανά προβλήματα μπορεί να εμφανιστούν. Πρώτον αν χρησιμοποιήθηκε ένα σχήμα «δοκιμής/δεύτερης-δοκιμής» το υποκείμενο πιθανώς να θυμάται τις απαντήσεις της πρώτης δοκιμής. Για παράδειγμα δίνεται σε ένα προγραμματιστή μια εργασία συντήρησης, πολλαπλές φορές, για να εξακριβώσει αν μια μέτρηση πρόβλεψης κόστους συντήρησης είναι αξιόπιστη ή όχι. Αν ο προγραμματιστής θυμάται την εργασία από προηγούμενες φορές τότε η μέτρηση μπορεί να αποδειχθεί μη σταθερή. Δεύτερον η πραγματική διαδικασία της μέτρησης μπορεί να αλλάξει την οντότητα η οποία μετράται. Χρησιμοποιώντας το ίδιο παράδειγμα ο προγραμματιστής μπορεί να μάθει τον σκοπό της μέτρησης. Γνωρίζοντας αυτό ο προγραμματιστής θα μπορούσε να διαβάσει για πιθανές προσεγγίσεις συντήρησης. Αυτό θα μπορούσε να επηρεάσει τα αποτελέσματα της δεύτερης 23

24 δοκιμής. Το θέμα της ισοδυναμίας διευθετεί το αν διαφορετικά δείγματα επηρεάζουν την μέτρηση [2] Ευρωστία Οι Tsai et al [18] προτείνουν ότι μια μέτρηση πρέπει να είναι θεωρητικά καθηλωμένη, εύληπτη και εφαρμόσιμη στα αρχικά στάδια της παραγωγής κώδικα. Επίσης ότι μια μέτρηση πρέπει να είναι εύρωστη. Η ευρωστία όπως περιγράφεται από τους συγγραφείς βασίζεται στην ικανότητα της μέτρησης να ανέχεται μη πλήρεις πληροφορίες καθώς και η ικανότητα να επανακάμπτει από μια αποτυχία και να μπορεί να διαχειριστεί μη ορθές εισόδους. 2.7 Αρχές Μετρικών Κριτικές Μια μέτρηση είναι «καλή» όταν η αριθμητική της τιμή χαρακτηρίζει µε ακρίβεια την συγκεκριμένη ιδιότητα του αντικειμένου. Η Weyuker [19] πρότεινε μια σειρά από εννιά αξιώματα με βάση τα οποία θα μπορούσε να οριστεί η πολυπλοκότητα λογισμικού. Αν και άλλοι ερευνητές, όπως ο Zuse [20] και ο Fenton [3] παρατήρησαν ότι τα συγκεκριμένα αξιώματα δεν είναι πλήρως συνεπή, μπορούν να ορίσουν μία βασική δομή η οποία μπορεί να προσαρμοστεί σε ένα αντικειμενοστραφές περιβάλλον. Στη συνέχεια παρουσιάζονται τα αξιώματα. Τα τέσσερα πρώτα τέσσερα από αυτά αφορούν την ευαισθησία ενός μέτρου. Το πέμπτο απαιτεί το μέτρο να παράγει μια τιμή για κάθε συστατικό ενός προγράμματος, η οποία δεν είναι μεγαλύτερη από την τιμή που παράγεται για όλο το πρόγραμμα. Αυτό προϋποθέτει ότι κάθε συστατικό δεν μπορεί να είναι πολυπλοκότερο από όλο το πρόγραμμα. Το έκτο αξίωμα αναφέρεται στην αλληλεπίδραση μεταξύ δύο προγραμμάτων. Ορίζει ότι η αλληλεπίδραση μεταξύ του Προγράμματος Α και του Προγράμματος Γ μπορεί να είναι διαφορετική από αυτή μεταξύ του Β και του Γ (το πρόγραμμα Γ μπορεί να κληθεί και από το Α και από το Β). Συνεπώς, οι τιμές της πολυπλοκότητας μπορεί να είναι διαφορετικές για τους δύο συνδυασμούς (Α-Γ και Β-Γ). Το έβδομο αξίωμα απαιτεί ότι ένα μέτρο θα είναι ευαίσθητο στη σειρά των δηλώσεων ενός προγράμματος. Το όγδοο αξίωμα ορίζει ότι η μετονομασία των μεταβλητών δεν επηρεάζουν την τιμή ενός μέτρου. Το τελευταίο αξίωμα ορίζει ότι το άθροισμα της πολυπλοκότητας των επιμέρους συστατικών ενός προγράμματος μπορεί να είναι μικρότερο του προγράμματος αν αυτό θεωρηθεί ενιαίο. Τα αξιώματα της Weyuker διατυπώθηκαν με βάση προγράμματα και όχι αντικείμενα. Η συγκεκριμένη ορολογία θα χρησιμοποιηθεί και παρακάτω. 24

25 Ορίζουμε το πρόγραμμα P, την πολυπλοκότητα του P. Συνεπώς για δύο προγράμματα P και Q μπορεί να ισχύει είτε P Q είτε Q P. Ακόμη, αν P Q και Q R τότε P = R. Αξίωμα 1 (ⱻP)(ⱻQ) ( P Q ) Το παραπάνω εξασφαλίζει ότι ένα μέτρο, το οποίο εκτιμά ότι όλα τα προγράμματα έχουν την ίδια πολυπλοκότητα θα πρέπει να εξαλείφεται. Αξίωμα 2 Αν χ ένας θετικός αριθμός τότε ο αριθμός των κλάσεων με πολυπλοκότητα χ σε ένα σύστημα δεν είναι άπειρος Αξίωμα 3 Έστω δύο προγράμματα P και Q, τέτοια ώστε P = Q. Το αξίωμα δηλώνει ότι μπορούν να υπάρξουν διαφορετικές κλάσεις με την ίδια πολυπλοκότητα Η Weyuker αναφέρει ότι τα τρία πρώτα αξιώματα αφορούν τις μετρικές και δεν αναφέρονται στη συντακτική ή τη σημασιολογική φύση της των μετρικών πολυπλοκότητας του λογισμικού. Αξίωμα 4 (ⱻP)(ⱻQ)(P=Q & P Q ) Το τέταρτο αξίωμα προτείνει ότι είναι πιθανό η ίδια λειτουργικότητα, να βρίσκεται σε δύο διαφορετικά προγράμματα, στα οποία όμως αυτή εφαρμόζεται με διαφορετικό τρόπο. Για παράδειγμα ένα πρόγραμμα για ταξινόμηση μπορεί να εφαρμοστεί και με bubble sort και με heap sort. Όπως προηγουμένως, αν P=Q σημαίνει ότι δύο κομμάτια προγράμματος έχουν ίδια συμπεριφορά, δηλαδή ότι παράγουν την ίδια έξοδο για ίδια είσοδο τότε ισχύει ότι : Σε αντικειμενοστραφές περιβάλλον, μια ερμηνεία θα ήταν ότι δύο κλάσεις με την ίδια υπογραφή θα επέστρεφαν το ίδιο αποτέλεσμα. Αξίωμα 5 Το πέμπτο αξίωμα αφορά τη μονοτονικότητα. Αν δύο κομμάτια προγράμματος ενωθούν, η συνολική πολυπλοκότητα θα είναι μεγαλύτερη από την πολυπλοκότητα κάθε κομματιού χωριστά. 25

26 Αξίωμα 6 (ⱻP)(ⱻQ) (ⱻR) ( P = Q & ( P;R!= Q;R )) Το αξίωμα αυτό υποθέτει ότι αν ένα πρόγραμμα R μπορούσε να μπει στο τέλος δύο προγραμμάτων P και Q για τα οποία ισχύει P = Q, τότε δεν είναι απαραίτητο ότι η τελική πολυπλοκότητα των αθροισμάτων θα είναι P+R και Q+R. Αξίωμα 7 Υπάρχουν προγράμματα P και Q τέτοια ώστε το Q ξεκινώντας από το P και αλλάζοντας τη σειρά των δηλώσεων του, τότε P Q Αξίωμα 8 Το αξίωμα αυτό αφορά την ψυχολογική πολυπλοκότητα και θέτει το ερώτημα αν η μετονομασία μερών ενός προγράμματος επηρεάζει τη πολυπλοκότητα. Το αξίωμα αναφέρει ότι αν P είναι μια μετονομασία του Q τότε P = Q Αξίωμα 9 (ⱻP)(ⱻQ)( P + Q ) < ( P;Q ) Το τελευταίο αξίωμα ορίζει ότι η πολυπλοκότητα μίας κλάσης που συντίθεται από δύο άλλες κλάσεις είναι μεγαλύτερη από το άθροισμα της πολυπλοκότητας των κλάσεων αυτών. Κριτικές O Fenton [8] σημειώνει ότι το πρόβλημα με τα παραπάνω αξιώματα είναι ότι ο ορισμός της πολυπλοκότητα. Συγκεκριμένα ότι ο όρος πολυπλοκότητα δεν είναι σαφώς ορισμένος και μπορεί να μεταφραστεί ως ορθότητα, κατανόηση, ευκολία υλοποίησης, μέγεθος, συντηρισιμότητα κα. Η ανησυχία του αφορά επίσης τα αξιώματα 5 και 6 και τη μεταξύ τους ασυμβατότητα. Το αξίωμα 5 είναι κατάλληλο για μέτρα πολυπλοκότητας που αφορούν το μέγεθος αλλά όχι αυτά που σχετίζονται με την κατανόηση. Αντιστρόφως, το αξίωμα 6 παραβιάζεται από τα μέτρα που σχετίζονται με το μέγεθος αλλά που είναι κατάλληλα για την κατανόηση. Ο Zuse [20] ασχολήθηκε με την παραπάνω ασυμβατότητα καθώς επίσης και με τις κλίμακες μεγεθών. Αναφέρει αρχικά ότι τα αξιώματα δεν είναι σε συμφωνία με τη θεωρία του μέτρου καθώς απαιτούν μία αναλογία κλίμακας σε συγκεκριμένα σημεία ενώ σε άλλα όχι. O Ejiogu [11] προτείνει ότι οποιοδήποτε χρήσιμο και επικυρωμένο μέτρο πρέπει να έχει τη δύναμη της σύγκρισης. Με αυτό εννοεί ότι η μετρική πρέπει να υποστηρίζει τις παρακάτω αρχές: Η μετρική του τίποτα (άδειο σύνολο) πρέπει να παράγει τιμή μηδέν. 26

27 Η μετρική ενός κομματιού προγράμματος πρέπει να παράγει μια τιμή μικρότερη ή ίση της τιμής που παράγεται όταν μετράται ένα ολόκληρο πρόγραμμα. Η μετρική μιας ομάδας κομματιών ενός προγράμματος πρέπει να παράγουν τιμή μικρότερη ή ίση του αθροίσματος των ατομικών τιμών που παράγονται όταν μετρούνται τα ατομικά κομμάτια. 27

28 28

29 3 Μετρικές Λογισμικού Στα επόμενα κεφάλαια γίνεται μία προσπάθεια κατηγοριοποίησης και ανάλυσης κάποιων από τις σημαντικότερες μετρικές λογισμικού. Το παρακάτω σχήμα παρουσιάζει τον τρόπο με τον οποίο αυτές έχουν χωριστεί σε κατηγορίες. Τα κριτήρια (ή επίπεδα) τα οποία θα μπορούσαν να χρησιμοποιηθούν είναι τα εξής [21] [22] [23]: Αντικείμενο: Αναφέρεται στην ανάπτυξη λογισμικού ως σύνολο. Σε αυτή διακρίνει το έργο, τις διαδικασίες και το προϊόν. Η παρούσα εργασία επικεντρώνεται στις μετρικές προϊόντος. Τύπος: Σύμφωνα με τον τύπο τους, οι μετρικές προϊόντος διαχωρίζονται σε εσωτερικές και εξωτερικές. Αυτός ο διαχωρισμός βέβαια μπορεί να εφαρμοστεί και στα άλλα είδη μετρικών. Φάση του κύκλου ζωής: Σε κάθε φάση του κύκλου ζωής του λογισμικού (απαιτήσεις, ανάλυση, σχεδιασμός, υλοποίηση, έλεγχος) χρησιμοποιούνται διαφορετικές μετρικές. Στα πλαίσια της εργασίας αναλύονται οι μετρικές που ανήκουν στις τέσσερις πρώτες. Μοντέλο Προγραμματισμού: Οι μετρικές μπορούν τέλος να διαχωριστούν με βάση το μοντέλο προγραμματισμού (διαδικαστικό και αντικειμενοστραφές). Πρέπει να σημειωθεί ότι πολλές μετρικές ισχύουν και για τα δύο μοντέλα. Εικόνα 1 Κατηγορίες Μετρικών 29

30 3.1 Αντικείμενο Μετρικών Μετρικές Διαδικασίας Ανάπτυξης Η λογική της βελτίωσης μιας διαδικασίας ανάπτυξης λογισμικού στηρίζεται στην αντίληψη ότι μετρώντας συγκεκριμένα χαρακτηριστικά της διαδικασίας και αναπτύσσοντας κατάλληλες μετρικές, είναι δυνατόν να εξαχθούν συγκεκριμένοι δείκτες για την βελτίωση της ακολουθούμενης στρατηγικής. Μία διαδικασία αναπαρίσταται από ένα τρίγωνο που συνδέει τρείς παράγοντες όπως φαίνεται στο παρακάτω σχήμα, οι οποίοι επηρεάζουν την ποιότητα του παραγόμενου λογισμικού και την απόδοση του έργου. Οι δεξιότητες και το κίνητρο των ανθρώπων που συμμετέχουν θεωρείται ο πλέον καθοριστικός παράγοντας στην ποιότητα του παραγόμενου λογισμικού και την απόδοση του έργου. Σημαντικό επίσης ρόλο παίζει η πολυπλοκότητα και το είδος του παραγόμενου προϊόντος ενώ τέλος η τεχνολογία λογισμικού που χρησιμοποιείται κατά τη διαδικασία ανάπτυξης μπορεί να συμβάλλει στη βελτίωση της ποιότητας και την επίτευξη των στόχων με μικρότερο κόστος και σε μικρότερο χρονικό διάστημα. Επιπλέον παράγοντες δευτερεύουσας σημασίας είναι τα χαρακτηριστικά του πελάτη για τον οποίο αναπτύσσεται το προϊόν (π.χ. ευκολία επικοινωνίας), το περιβάλλον ανάπτυξης (π.χ. χρήση ειδικών εργαλείων) καθώς και τα χαρακτηριστικά που σχετίζονται με την επιχείρηση (π.χ. χρονικοί - οικονομικοί περιορισμοί). Για την μελέτη δεικτών σχετικά με τη διαδικασία ανάπτυξης λογισμικού θα πρέπει συνεπώς να χρησιμοποιηθούν κατάλληλες μετρικές για όλους τους παραπάνω παράγοντες [24]. Εικόνα 2 Διαδικασία Ανάπτυξης Λογισμικού [24] Μετρικές Έργου Η εφαρμογή μετρικών κατά τη διάρκεια ανάπτυξης ενός συγκεκριμένου έργου και η εξαγωγή κατάλληλων δεικτών, χρησιμοποιείται από τη διοίκηση του έργου και την ομάδα ανάπτυξης για την τροποποίηση των δραστηριοτήτων (τεχνικών ή μη) ώστε να επιτευχθούν οι επιδιωκόμενοι 30

31 στόχοι. Η πρώτη εφαρμογή μετρικών στο επίπεδο του έργο λαμβάνει χώρα κατά την εκτίμηση της διάρκειας και του κόστους του έργου. Χρησιμοποιώντας μετρικές που αναπτύχθηκαν κατά τη διάρκεια προηγούμενων έργων και στοιχεία από τις τρέχουσες προδιαγραφές, εκτιμήσεις παρέχονται στη διοίκηση του έργου ώστε να λάβει τις κατάλληλες αποφάσεις σχετικά με την οργάνωση και τον χρονοπρογραμματισμό του έργου. Με την εξέλιξη του έργου, οι πραγματικοί χρόνοι και το αντίστοιχο κόστος, συγκρίνονται με τις αρχικές εκτιμήσεις, ώστε να παρακολουθείται και να ελέγχεται η πρόοδος. Με την έναρξη των τεχνικών εργασιών αξιολογούνται επιπρόσθετες μετρικές που έχουν σχέση με τους ρυθμούς παραγωγής (αριθμός γραμμών κώδικα, αριθμός σελίδων τεκμηρίωσης), τον αριθμό λαθών, τον αριθμό ωρών που καταναλώνονται ανά φάση του έργου καθώς και ειδικότερες τεχνικές μετρικές. Σε πρακτικό επίπεδο, οι μετρικές στο επίπεδο του έργου χρησιμοποιούνται για α) αποφυγή καθυστερήσεων στην εκτέλεση των επιμέρους τμημάτων του έργου και β) τη συνεχή τροποποίηση της τεχνικής προσέγγισης που ακολουθείται για τη βελτίωση της ποιότητας. Όσο η ποιότητα βελτιώνεται, τόσο μειώνεται ο αριθμός των λαθών με συνέπεια να μειώνεται και ο αριθμός των ωρών εργασίας που απαιτούνται για τη διόρθωση των σφαλμάτων [24] Μετρικές προϊόντος Ως προϊόν σε ένα έργο λογισμικού, δεν θεωρείται μόνο ο κώδικας που η διοίκηση του έργου έχει δεσμευθεί να παραδώσει στον πελάτη. Το σύνολο της τεκμηρίωσης που αναπτύσσεται σε ολόκληρο τον κύκλο ζωής του προϊόντος, από τα έγγραφα που συνοδεύουν το λογισμικό και παραδίδονται στον πελάτη μέχρι τα έγγραφα που παράγονται για εσωτερική χρήση της εταιρείας, αποτελούν τμήμα του προϊόντος. Για παράδειγμα ένα έγγραφο οδηγιών χρήσης (user guide) είναι δυνατόν να αξιολογηθεί με βάση μετρικές που αφορούν την ποιότητά του, τη σαφήνειά του ή το μέγεθος του [24]. 3.2 Τύποι Μετρικών H κατηγοριοποίηση των μετρικών λογισμικού μπορεί να γίνει χρησιμοποιώντας διάφορα κριτήρια. Για παράδειγμα ο Fenton [3] διαχώρισε τις μετρικές σε: αντικειμενικές και λιγότερο αντικειμενικές (ή αντίστοιχα εσωτερικές και εξωτερικές). Η παραπάνω κατηγοριοποίηση θεωρείται θεμελιώδης αν και δεν έχει χρησιμοποιηθεί κατάλληλα στη βιβλιογραφία μέχρι σήμερα. Γενικότερα, έχει παρατηρηθεί παραπλανητική χρήση των όρων που αφορούν τις μετρικές λογισμικού γεγονός που οδηγεί σε λανθασμένα συμπεράσματα. Στο παρακάτω σχήμα φαίνεται ο 31

32 διαχωρισμός των μετρικών όπως αυτός ορίστηκε από τον Fenton. Πιο συγκεκριμένα, ο διαχωρισμός επικεντρώνεται στη διαφορά μεταξύ εσωτερικών και εξωτερικών χαρακτηριστικών. Εικόνα 3 Κατηγορίες μετρικών από Fenton [23] Πρέπει να σημειωθεί, ότι υπάρχει σύγχυση σχετικά με τη χρήση των όρων χαρακτηριστικό και μέτρο. Για παράδειγμα, στο τι σημαίνει πολυπλοκότητα του λογισμικού. Η πολυπλοκότητα αποτελεί έναν από τους σημαντικότερους αλλά πιο ελλιπώς καθορισμένους όρους. Σύμφωνα με τον Fenton, η πολυπλοκότητα περιλαμβάνει τον ανθρώπινο παράγοντα και συνεπώς είναι εξωτερική έννοια. Συνεπώς, η πολυπλοκότητα που τις περισσότερες φορές αναφέρεται στη δυσκολία κατανόησης ή διατήρησης του λογισμικού, είναι ένα χαρακτηριστικό το οποίο μπορεί να χρησιμοποιηθεί για να περιγραφγεί ένα κομμάτι κώδικα, η σχεδίαση μιας λύσης, οι προδιαγραφές ενός προβλήματος κτλ. Λανθασμένα, ο όρος πολυπλοκότητα συχνά υποδεικνύει τη μετρική που χρησιμοποιούμε για να μετρήσουμε την πολυπλοκότητα. Σε αυτή την περίπτωση είναι καλύτερα να ορίζεται σαν μέτρο της πολυπλοκότητας και όχι ως η πολυπλοκότητα. Υπάρχει μια αλληλεπίδραση μεταξύ του χαρακτηριστικού και του μέτρου του χαρακτηριστικού και πρέπει να τονιστεί ότι η χρήση μίας λέξης όπως ποιότητα ή πολυπλοκότητα δε συνηγορεί και στη χρήση ενός αριθμού Εσωτερικά Χαρακτηριστικά Τα πρώτα αφορούν συνήθως την πολυπλοκότητα της δομής. Τέτοια μπορούν να είναι: το μέγεθος, η δομή των δεδομένων, ο έλεγχος ροής (για παράδειγμα η μετρική της κυκλωματικής πολυπλοκότητας του McCabe [25]) και η σύνδεση μεταξύ των διαφορετικών μονάδων (για παράδειγμα τη μετρική ροής πληροφορίας των Henry and Kafura [26]). Η πολυπλοκότητα της δομής είναι υποκειμενικό χαρακτηριστικό το οποίο αποτελεί μέρος της συνολικής 32

33 πολυπλοκότητας ενός συστήματος. Επηρεάζεται όπως είναι αναμενόμενο από τον προγραμματιστή ο οποίος τη δημιουργεί, την πολυπλοκότητα του προβλήματος που επιλύει, την πολυπλοκότητα του μέσου που χρησιμοποιείται και άλλα Εξωτερικά Χαρακτηριστικά Τα εξωτερικά χαρακτηριστικά είναι δυσκολότερο να οριστούν. Ο Shepperd [27], επικεντρώθηκε σε μια ομάδα από ποιοτικούς παράγοντες και κυρίως στη συντηρισιμότητα και την αξιοπιστία του λογισμικού. Ο Pfleeger [28] ορίζει την ποιότητα λογισμικού ως συνδυασμό της αξιοπιστίας, της συντηρησιμότητας και της διαθεσιμότητας. Ακόμη, ο Fenton [3] προσθέτει στα παραπάνω την ευχρηστία. Ο Henderson-Sellers [29] θεωρεί ότι στους ποιοτικούς παράγοντες ανήκουν επίσης η δυνατότητα επαναχρησιμοποίησης και την πληρότητα της αφαίρεσης. Τέλος, οι Li και Cheung [30] επικεντρώθηκαν κυρίως στο χαρακτηριστικό της συντηρησιμότητας. Αυτό αποτελείται από την κατανόηση, τη δυνατότητα τροποποίησης και το βαθμό στον οποίο μπορεί να δοκιμαστεί (testability). Σύμφωνα με τον Sellers [2], όλα τα παραπάνω θα οδηγούν σε έναν ιεραρχικό ορισμό της ποιότητας λογισμικού, ο οποίος είναι ο εξής: Ποιότητα Λογισμικού= Αξιοπιστία + Διαθεσιμότητα + Κατανοησιμότητα + Δυνατότητα τροποποίησης + Δυνατότητα Δοκιμής + Ευχρηστία Όλα τα παραπάνω συστατικά επηρεάζονται από την πολυπλοκότητα. Εικόνα 4 Ποιότητα Λογισμικού [2] 33

34 3.3 Μετρικές και Φάση Ανάπτυξης Λογισμικού Φάση Ανάλυσης Η τεχνική εργασία σε έργα λογισμικού ξεκινά με την ανάλυση και τον καθορισμό των απαιτήσεων που θέτει τις βάσεις για τη μετέπειτα σχεδίαση και ανάπτυξη του. Για τον λόγο αυτό απαιτούνται μετρικές οι οποίες να παρέχουν πληροφορίες σχετικά με την ποιότητα του μοντέλου ανάλυσης. Οι υπάρχουσες μετρικές στοχεύουν στην πρόβλεψη του μεγέθους του συστήματος το οποίο θα αναπτυχθεί λαμβάνοντας υπόψη μόνο την περιγραφή του συστήματος σε υψηλό επίπεδο Function Points Πολλοί μηχανικοί λογισμικού υποστηρίζουν ότι το μέγεθος του κώδικα είναι μία παραπλανητική μέτρηση της πολυπλοκότητάς του και ότι το μέγεθος της λειτουργικότητάς ενός προγράμματος παρέχει μία πληρέστερη εικόνα της μεγέθους του [2]. Υπήρξαν διαφορετικής προσπάθειες μέτρησης της λειτουργικότητας με την πιο γνωστή να είναι αυτή του των function points. Γενικά οι μετρικές αυτές αποτελούν μέρος μίας μεγαλύτερης προσπάθειας να αντιστοιχηθεί το μέγεθος του κώδικα με το κόστος παραγωγής του και με την παραγωγικότητα των προγραμματιστών. Μία διαισθητική αρχή στην οποία στηρίζονται αυτές οι μετρικές είναι ότι δύο προγράμματα που υλοποιούν μία προδιαγραφή θα πρέπει να έχουν αντίστοιχο μέγεθος λειτουργικότητας. Εικόνα 5 Function Points [31] 34

35 Συγκεκριμένα όσον αφορά τη μέτρηση Function Points που πρότεινε ο Albrecht [32], τα FPs έχουν ως στόχο να μετρήσουν την ποσότητα της λειτουργικότητας σε ένα σύστημα όπως αυτή περιγράφεται στις προδιαγραφές του. Η μετρική μπορεί να υπολογιστεί χωρίς οι προδιαγραφές να είναι γραμμένες σε ένα συγκεκριμένο σύστημα ή τεχνική προδιαγραφών. Για τον υπολογισμό πρώτα υπολογίζεται το UFC Unadjusted function point που αποτελεί μία αναπαράσταση ενός από τα παρακάτω: Εξωτερικοί είσοδοι: Είναι τα αντικείμενα αυτά που παρέχονται από το χρήστη και περιγράφουν δεδομένα σχετικά με την εφαρμογή, όπως ονόματα αρχείων και επιλογές μενού. Εξόδους: Τα διαφορετικά είδη αντικειμένων που παρέχονται στον χρήστη ως έξοδος (όπως μηνύματα και αναφορές) Τα σημεία εκείνα του προγράμματος που χρειάζονται αλληλεπίδραση και άμεση απάντηση από το χρήστη (αυτά δεν μετρούνται στις εισόδους του προγράμματος) Εξωτερικά αρχεία που αποτελούν κυρίως διεπαφές με άλλα συστήματα Εσωτερικά αρχεία. Στη συνέχεια σε κάθε από αυτά τα αντικείμενα ανατίθενται μία τιμή πολυπλοκότητας με τιμή κάποια από: απλή, μέτρια και αυξημένη και ένα βάρος που ανατίθεται σε αυτή. Υπάρχουν 15 διαφορετικές τιμές (τρεις τιμές πολυπλοκότητας για κάθε χαρακτηριστικό) οπότε η UFC υπολογίζεται ως: n UFC = (διαφορετικά αντικείμενα κατηγορίας i) x(βάρος του i) i=1 Ένας ενδεικτικός πίνακας βαρών θα μπορούσε να είναι: Πολυπλοκότητα Παράμετρος Απλή Μέτρια Πολύπλοκη είσοδοι χρήστη έξοδοι χρήστη ερωτήσεις χρήστη αρχεία συστήματος εξωτερικές διεπαφές

36 Στη συνέχεια για να ολοκληρωθεί ο υπολογισμός πολλαπλασιάζεται το UFC με ένα παράγοντα τεχνικής πολυπλοκότητας (TCF technical complexity factor) που φαίνεται στον πίνακα παρακάτω που παίρνει τιμές από στο [0, 5] όπου το 0 σημαίνει ότι δεν παίζει κάποιο σημαντικό ρόλο και το 5 ότι παίζει κρίσιμης σημασίας ρόλο. F1: Αξιόπιστες δυνατότητες backup και F2: Επικοινωνίες δεδομένων επαναφοράς F3: Κατανεμημένες λειτουργίες (Distributed F4: Απόδοση functions) F5: Υψηλή χρήση αρχείων επιλογών (Heavily Used Configuration) F6: Είσοδος δεδομένων online (Online data entry) F7: Ευκολία χρήσης F8: Online αναβάθμιση (Online update) F9: Πολύπλοκη διεπαφή F10: Πολύπλοκοι υπολογισμοί (Complex processing) F11: Επαναχρησιμοποίηση (Reusability) F12: Ευκολία εγκατάστασης F13: Τοποθέτηση σε πολλά μέρη (Multiple F14: Ευκολία ενσωμάτωσης αλλαγής Sites) (Facilitate change) Όπου τελικά: TCF = x (Fi) Τέλος σαν Function Point ορίζεται το γινόμενο UFC x TCF.. Εδώ πρέπει να αναφερθεί ότι έχουν γίνει προσπάθειες μεταφοράς της μεθοδολογίας των FP και στον αντικειμενοστραφές κώδικα σχεδίαση χωρίς διαδεδομένη επιτυχία. Ακόμη σημειώνονται n i=1 τα προβλήματα που έχει η μέθοδος και συνοπτικά είναι: [2] Υποκειμενικότητα στους τεχνικούς παράγοντες Προβλήματα διπλού υπολογισμού κάποιων παραγόντων Προβλήματα με τιμές που δεν ταιριάζουν με τη διαίσθηση Προβλήματα ακρίβειας Προβλήματα με προδιαγραφές που αλλάζουν Προβλήματα σχετικά με τη διαφοροποίηση των υπολογιζόμενων αντικειμένων Υποκειμενική τοποθέτηση των βαρών Προβλήματα με τη θεωρία μετρήσεων 36

37 Μετρική Bang H μετρική Bang που προτάθηκε από τον Tom Demarco [33] βασίζεται επίσης σε περιγραφές των απαιτήσεων και χρησιμοποιείται για την εκτίμηση του μεγέθους ενός έργου λογισμικού. Η εφαρμογή της μετρικής αυτής προϋποθέτει την περιγραφή των απαιτήσεων με διαγράμματα ροής δεδομένων και χρήση ενός λεξικού δεδομένων. Το βασικό δεδομένο εισόδου στην μετρική Bang είναι οι στοιχειώδεις λειτουργίες που αντιστοιχούν στους μετασχηματισμούς του διαγράμματος ροής δεδομένων οι οποίοι δεν είναι δυνατόν να αναλυθούν περαιτέρω σε απλούστερους. Σε κάθε στοιχειώδη λειτουργία, κάθε ροή δεδομένων που εισέρχεται ή εξέρχεται από το μετασχηματισμό χαρακτηρίζεται από τον αριθμό των μονάδων πληροφορίας (token) που μεταφέρει. Κάθε μονάδα πληροφορίας θεωρείται ότι αντιμετωπίζεται ανεξάρτητα και ως διακριτό δεδομένο από τον μετασχηματισμό. Για παράδειγμα, αν η ροή δεδομένων είναι μία εγγραφή (record) αποτελούμενη από πέντε πεδία (fields) και κάθε πεδίο εξετάζεται ξεχωριστά από την στοιχειώδη λειτουργία, τότε η ροή δεδομένων χαρακτηρίζεται με 5 μονάδες πληροφορίας. Ωστόσο, αν η συνολική εγγραφή αντιμετωπίζεται ως ένα δεδομένο από την στοιχειώδη λειτουργία, η ροή δεδομένων χαρακτηρίζεται με 1 μονάδα πληροφορίας. Αν TCi είναι ο συνολικός αριθμός μονάδων πληροφορίας που σχετίζονται με την στοιχειώδη λειτουργία i, τότε η συμβολή αυτής της στοιχειώδους λειτουργίας στο μέγεθος του συστήματος συμβολίζεται με CFPIi και είναι ίση με : CFPI i = TC i log 2 TC i 2 Ο λόγος για τον οποίο χρησιμοποιείται ο λογάριθμος με βάση το 2, είναι ότι κατ' αυτό τον τρόπο η ποσότητα CFPIi γίνεται ανάλογη του συνολικού αριθμού των bits που απαιτούνται για την αναπαράσταση των μονάδων πληροφορίας. Η ποσότητα αυτή συσχετίζει το μέγεθος μιας στοιχειώδους λειτουργίας με τον αριθμό των μονάδων πληροφορίας που διαχειρίζεται. Ωστόσο, δεν διακρίνει τις στοιχειώδεις λειτουργίες βάσει της επεξεργασίας των δεδομένων που πραγματοποιούνται στον μετασχηματισμό: Δύο διαφορετικές στοιχειώδεις λειτουργίες είναι δυνατόν να πραγματοποιούν διαφορετική επεξεργασία δεδομένων με την ανάλογη πολυπλοκότητα, ακόμα και αν διαχειρίζονται τον ίδιο αριθμό μονάδων πληροφορίας. Το γεγονός αυτό αντιμετωπίζεται κατηγοριοποιώντας τις στοιχειώδεις λειτουργίες σε 16 διαφορετικούς τύπους και προσδιορίζοντας ένα διαφορετικό βάρος πολυπλοκότητας για κάθε τύπο. Ορισμένοι τύποι, η σημασία και το αντίστοιχο βάρος παρουσιάζονται στην ακόλουθη λίστα: 37

38 Διαχωρισμός ή Ενοποίηση: Στοιχειώδεις λειτουργίες που διαχωρίζουν ή ενοποιούν εισερχόμενα δεδομένα. Βάρος: 0.6 Απλή Ενημέρωση: Στοιχειώδεις λειτουργίες που ενημερώνουν κάποια δεδομένα. Βάρος: 0.5 Επαλήθευση: Λειτουργίες που εκτελούν ελέγχους επαλήθευσης. Βάρος: 1.0 Παραγωγή Εξόδων: Λειτουργίες που εμπλέκονται στην δημιουργία εξόδων του συστήματος. Βάρος: 1.0 Αριθμητικές: Λειτουργίες που εκτελούν απλές αριθμητικές πράξεις. Βάρος: 0.7 Διαχείριση Συσκευών: Λειτουργίες που ελέγχουν περιφερειακά ή επικοινωνούν με το λειτουργικό σύστημα. Βάρος: 2.5 Στη συνέχεια, η ποσότητα CFPI για κάθε στοιχειώδη λειτουργία πολλαπλασιάζεται με το βάρος της αντίστοιχης κατηγορίας. Η τελική μετρική του συστήματος είναι: N Bang = CFPI i weight i i=1 όπου N είναι ο συνολικός αριθμός των στοιχειωδών λειτουργιών στο σύστημα. Η μετρική αυτή είναι σαφώς πιο λεπτομερής από την μετρική των λειτουργικών σημείων, αλλά προϋποθέτει συγκεκριμένο τρόπο περιγραφής των απαιτήσεων Μετρικές για την Ποιότητα των Προδιαγραφών Η ποιότητα του μοντέλου που χρησιμοποιείται για την ανάλυση και των καθορισμό των απαιτήσεων είναι δυνατόν να εκτιμηθεί βάσει των επιθυμητών χαρακτηριστικών της: σαφήνεια, πληρότητα, συνέπεια, τη δυνατότητα επαλήθευσης και τροποποίησης. Παρόλο που τα χαρακτηριστικά αυτά είναι κυρίως ποιοτικά, ορισμένα είναι δυνατόν να αναπαρασταθούν χρησιμοποιώντας μία ή περισσότερες μετρικές. Οι μετρικές που αναπτύσσονται στη φάση της ανάλυσης των απαιτήσεων, δεν αξιολογούν μόνο το συγκεκριμένο προϊόν που αναπτύσσεται αλλά την ίδια την διαδικασία ανάπτυξης η οποία χρησιμοποιείται σε διάφορα προϊόντα. Για παράδειγμα, θεωρούμε ότι υπάρχουν n r απαιτήσεις στις προδιαγραφές έτσι ώστε: n r = n f + n nf όπου n f είναι ο αριθμός των λειτουργικών (functional) απαιτήσεων και n nf ο αριθμός των μη λειτουργικών (non -funtional) απαιτήσεων. 38

39 Για τον προσδιορισμό της σαφήνειας των απαιτήσεων, θεωρούμε ότι οι απαιτήσεις έχουν δοθεί σε ένα αριθμό ελεγκτών και η μετρική βασίζεται στην κατανόηση των απαιτήσεων από τον κάθε ελεγκτή και ορίζεται ως: Q 1 = n ui n r Όπου n ui είναι αριθμός των απαιτήσεων για τις οποίες όλοι οι ελεγκτές είχαν την ίδια ερμηνεία (δηλαδή κατανόησαν τις απαιτήσεις με τον ίδιο ακριβώς τρόπο). Όσο πλησιέστερος είναι ο ανωτέρω λόγος προς τη μονάδα, τόσο μεγαλύτερη είναι η σαφήνεια των απαιτήσεων. Η περιγραφή των απαιτήσεων λογισμικού θεωρείται πλήρης αν προσδιορίζεται η απόκριση του συστήματος για όλες τους δυνατούς συνδυασμούς εισόδων (εσωτερική πληρότητα). Ειδικότερα, σύμφωνα με αυτόν τον ορισμό της πληρότητας θεωρείται ότι η συνάρτηση f(κατάσταση, είσοδος) (κατάσταση, απόκριση) είναι ορισμένη για όλους τους επιτρεπτούς συνδυασμούς καταστάσεων και εισόδων του συστήματος. Θεωρώντας ότι ο αριθμός των εισόδων που ορίζονται κατά την περιγραφή των απαιτήσεων είναι n i, ο αριθμός των καταστάσεων του συστήματος που ορίζονται (άμεσα ή έμμεσα) είναι n s και ο αριθμός των διακριτών λειτουργιών είναι n u, η πληρότητα των λειτουργικών απαιτήσεων μπορεί να καθοριστεί υπολογίζοντας το λόγο: n u Q 2 = n i n s Ο λόγος αυτός αντιστοιχεί στο ποσοστό των απαιτούμενων λειτουργιών που έχουν καθοριστεί για το σύστημα [24] Φάση Σχεδίασης Θα ήταν αδιανόητο να θεωρήσει κανείς ότι στη φάση της σχεδίασης ενός προγράμματος δεν χρησιμοποιούνται μετρικές οι οποίες να αξιολογούν την ποιότητα του σχεδίου, ώστε να καθοδηγούν την εξέλιξη του σχεδίου. Ωστόσο, η σχεδίαση έργων λογισμικού συχνά πραγματοποιείται χωρίς καμία χρήση κατάλληλων μετρικών, όχι γιατί δεν είναι διαθέσιμες, αλλά γιατί η πλειοψηφία των μηχανικών λογισμικού αγνοούν την ύπαρξή τους. Οι μετρικές που αναφέρονται στη σχεδίαση υψηλού επιπέδου επικεντρώνονται σε χαρακτηριστικά της αρχιτεκτονικής του προγράμματος και την αποτελεσματικότητα των δομικών μονάδων. Οι 39

40 μετρικές αυτές είναι black-box υπό την έννοια ότι δεν απαιτούν γνώση της εσωτερικής υλοποίησης μιας μονάδας του συστήματος [24] Fan-in/Fan-out Έστω μία διαδικασία Α. Το fan-in αναφέρεται στον αριθμό των μερών όπου παραδίδεται ο έλεγχος στη διαδικασία Α, συν τον αριθμό των δομών που δίνουν δεδομένα στη διαδικασία Α. Το fan-out αναφέρεται στον αριθμό των μονάδων που χρησιμοποιεί η διαδικασία Α συν τον αριθμό των δομών δεδομένων που ο κώδικας επηρεάζει. Ένα μεγάλο νούμερο fan-in ή/και fan-out υποδηλώνει ένα μεγάλο αριθμό συνδέσεων με εξωτερικές οντότητες το οποίο με τη σειρά του δηλώνει ότι η διαδικασία εκτελεί περισσότερες από μία λειτουργίες και ίσως χρειάζεται να διασπαστεί σε μικρότερες διαδικασίες. Σύμφωνα με τους Henry and Kafura [26] προτάθηκαν τρεις μετρικές: (fanin fanout) 2 length (fanin fanout) 2 (fanin fanout) 2 Όπου το length αφορά τη μετρική του Lines Of Code (SLOC). Ακόμη, οι Card and Agresti [34] ορίζουν την πολυπλοκότητα του συστήματος ως το άθροισμα της δομικής πολυπλοκότητας και της πολυπλοκότητας των δεδομένων. Όπου η δομική πολυπλοκότητα ορίζεται ως: Και η πολυπλοκότητας δεδομένων ως: C(i) = S(i) + D(i) S(i) = fan 2 out (i) D(i) = v(i) fout(i)

41 Εικόνα 6 Fan in Fan out [2] Όσο αυξάνει η τιμή κάθε μίας από τις ανωτέρω μετρικές, τόσο αυξάνει η συνολική αρχιτεκτονική πολυπλοκότητα του συστήματος. Κατά συνέπεια, αυξάνεται και η προσπάθεια που πρέπει να καταβληθεί για την κωδικοποίηση και τον έλεγχο του συστήματος Μορφολογικές μετρικές σχεδίασης Υπάρχουν επίσης ορισμένες μορφολογικές μετρικές που επιτρέπουν τη σύγκριση διαφορετικών αρχιτεκτονικών χρησιμοποιώντας απλές διαστάσεις. Οι κόμβοι στο σχήμα είναι components κώδικα και οι ακμές είναι οι συνδέσεις μεταξύ τους. Για παράδειγμα, για το σχέδιο του παρακάτω σχήματος είναι δυνατόν να οριστεί η ακόλουθη μετρική: size = n + a όπου n o αριθμός των κόμβων (μονάδων) και a ο αριθμός των ακμών (γραμμών ελέγχου). Για την αρχιτεκτονική του σχήματος είναι μέγεθος = = 35. Ακόμη ορίζονται οι μετρικές: Αριθμός κόμβων Αριθμός ακμών βάθος = η μεγαλύτερη διαδρομή από τον κόμβο-ρίζα προς κάποιο κόμβο φύλλο. Στο σχήμα βάθος = 4 πλάτος = ο μέγιστος αριθμός κόμβων σε οποιοδήποτε επίπεδο της αρχιτεκτονικής. Στο σχήμα πλάτος = 6 41

42 Η πυκνότητα των συνδέσμων της αρχιτεκτονικής δίνεται από το λόγο ακμών προς κόμβους: r = a n Για το ανωτέρω παράδειγμα r=18/17=1.06 Tree Impurity Metric που δηλώνει πόσο η δομή του γράφου αποκλίνει από τη δομή ενός δέντρου και ορίζεται ως: Tree Impurity = (Id(n)) 2 Όπου το Id είναι ο αριθμός εισερχόμενων ακμών σε ένα κόμβο. Η μετρική αυτή δηλώνει μικρότερη πολυπλοκότητα όσο μειώνεται η τιμή της [35]. n G Εικόνα 7 Γράφος μορφολογικών μετρικών 42

43 3.3.4 Μετρικές Φάση Ανάπτυξης Μετρικές Πολυπλοκότητας Το μέγεθος ενός προϊόντος πληροφορικής μας λέει πολλά σχετικά με τη προσπάθεια που καταβλήθηκε για τη δημιουργία του. Κάποιος μπορεί να κάνει μία διαισθητική υπόθεση ότι ένα κομμάτι του κώδικα που ήταν μεγάλο στις μετρικές μεγέθους κώδικα συνήθως απαιτεί και περισσότερο χρόνο να σχεδιαστεί, υλοποιηθεί και να ελεγχθεί συγκριτικά με ένα μικρότερο. Αυτή η διαίσθηση δεν είναι κάτι που αντικατοπτρίζεται πάντα στη πραγματικότητα. Μεγάλο ρόλο παίζει και η δομή του κώδικα όχι μόνο για τη δημιουργία του αλλά και για τη συντήρησή του [2]. Η δομή του κώδικα μπορεί να χαρακτηριστεί από δύο οπτικές: Ροή ελέγχου Ροή δεδομένων Η ροή ελέγχου ελέγχει την αλληλουχία με την οποία εκτελούνται οι εντολές ενός προγράμματος. Αυτή η πλευρά της ροής ελέγχου αντικατοπτρίζει την ακολουθιακή και επαναληπτική φύση των προγραμμάτων. Ενώ οι μετρικές μεγέθους δίνουν μία εικόνα για το πόσες είναι οι εντολές του προγράμματος οι ροές ελέγχου μας δείχνουν ποια και πόσες φορές θα εκτελεστεί η κάθε εντολή. Η ροή δεδομένων ακολουθεί τα ίχνη των δεδομένων που δημιουργούνται ή επεξεργάζονται από το πρόγραμμα. Πολλές φορές η επεξεργασία αυτή πάνω στα δεδομένα είναι πιο πολύπλοκη από τις εντολές του προγράμματος που τις δημιουργούν. Αυτός είναι και ο λόγος που η μετρικές της ροής δεδομένων υπάρχουν, για να δείξουν αυτή τη πολυπλοκότητα [24]. Κυκλωματική Πολυπλοκότητα [25] Η μετρική αυτή είναι ο πιο διαδεδομένος εκπρόσωπος της κατηγορίας των μετρικών που αφορούν την πολυπλοκότητα. Χρησιμοποιείται για να αξιολογήσει την πολυπλοκότητα ενός αλγορίθμου ή μίας μεθόδου. Η μετρική στηρίζεται στη θεωρία γράφων. Συγκεκριμένα έστω ο κυκλωματικός αριθμός V(G) ενός γράφου με n κόμβους, e ακμές και p συνδεδεμένα μέρη τότε:. V(G) = e n + p Ακόμη ορίζεται το θεώρημα ότι σε ένα ισχυρά συνδεδεμένο γράφο, ο κυκλωματικός αριθμός είναι ίσος με τον μέγιστο αριθμό των γραμμικά ανεξάρτητων μονοπατιών. Χρησιμοποιώντας τα παραπάνω μία μέθοδος ή ένας αλγόριθμος μπορεί να αναπαρασταθεί ως γράφος με τον εξής 43

44 τρόπο: ένας κόμβος είναι ένα block κώδικα που εκτελείται σειριακά και μία ακμή είναι τα σημεία του κώδικα όπου υπάρχει κάποια διακλάδωση. Ο γράφος αυτός είναι γνωστός ως γράφος ελέγχου προγράμματος και υποθέτει ότι κάθε κόμβος είναι προσπελάσιμος από τον κόμβο εισόδου και ότι κάθε κόμβος μπορεί να φτάσει στον κόμβο εξόδου. Ο γράφος ελέγχου προγράμματος για να γίνει ισχυρά συνδεδεμένος γράφος πρέπει να του προστεθεί μία ακμή από τον κόμβο εξόδου προς τον κόμβο εισόδου συνεπώς η κυκλωματική πολυπλοκότητα τελικά ορίζεται ως εξής: V(G) = e n + 2p (μιας και πρέπει να προσθέσουμε μία ακμή ακόμα σε κάθε συνδεδεμένο μέρος p για να γίνει ο γράφος ισχυρά συνδεδεμένος). Ο Henderson-Sellers προτείνει ότι η εξίσωση πρέπει να γραφεί ως: V li = e n + p + 1 υποστηρίζοντας ότι δεν χρειάζεται κάθε συνδεόμενο μέρος p να είναι ένας ισχυρά συνδεδεμένος γράφος. Εικόνα 8 Παράδειγμα γράφου κυκλωματικής πολυπλοκότητας [2] V(G) = e n + 2p = = 5 44

45 Άλλες μετρικές βασισμένες στην κυκλωματική πολυπλοκότητα Έγιναν διάφορες προσπάθειες στο να βρεθούν ακριβέστερες μετρικές μέτρησης της πολυπλοκότητας ενός κώδικα. Θα παρουσιαστούν δύο από αυτές τις μετρικές. Η πρώτη μετρική παρουσιάστηκε από τον Piwowarski [36] το 1982 και αρχικά ορίζει τα παρακάτω μεγέθη. Ν = V (G) + N Όπου N = P (i) i Και το P*(i) είναι το βάθος εμφώλευσης του i κόμβου ορισμένο ως τον αριθμό των εντολών που περιέχονται στον κόμβο i. Η προσπάθεια του Piwowarksi αποσκοπούσε να δώσει μεγάλες τιμές σε μη δομημένα προγράμματα, μέτριες τιμές σε δομημένα προγράμματα με εμφωλευμένες δομές ελέγχου και τις μικρότερες τιμές χωρίς καθόλου δομές ελέγχου ή με δομές ελέγχου ενός επιπέδου. Εδώ πρέπει να οριστεί η μετρική KNOT ως: έστω ένα πρόγραμμα του οποίου οι εντολές έχουν έναν αυξάνονται αριθμό. Έστω ένα ζευγάρι αριθμών (α, β) που δηλώνει ότι υπάρχει μεταφορά εκτέλεσης από τη γραμμή με αριθμό α σε αυτή με αριθμό β. Έστω 2 τέτοια ζευγάρια (α,β) και (χ,ψ) υπάρχει KNOT αν μία από τις παρακάτω συνθήκες είναι αληθής: Min(α,β ) < min(χ,ψ)< max(α,β) ΚΑΙ max(χ,ψ) > max (α,β) Min(α,β ) < max(χ,ψ)< max(α,β) ΚΑΙ min(χ,ψ) < min (α,β) Με αυτό τον τρόπο η μετρική του Piwowarski τιμωρεί προγράμματα όπως τα παρακάτω (που περιέχουν knots) και Εικόνα 9 Παράδειγμα KNOTS σε γράφους κώδικα [2] 45

46 Άλλες μετρικές που αφορούν την πολυπλοκότητα περιλαμβάνουν: Αριθμός λογικών τελεστών: Ο συνολικός αριθμός των λογικών τελεστών (&&, ==, ) στις δομές ελέγχου και επανάληψης (do-while, for, if, switch, while). Myer s Interval: Μία μετρική που ορίζεται ως η κυκλωματική πολυπλοκότητα / αριθμός λογικών τελεστών [37]. Μέγιστο βάθος εμφώλευσης δομών ελέγχου (maximum nesting of control structures). Κάθε δομή ελέγχου που βρίσκεται μέσα σε μία άλλη δομή ελέγχου αυξάνει την μετρική κατά 1. Εκτιμώμενος αριθμός μονοπατιών (Estimated Static Path count [38]): Η μετρική αυτή εντοπίζει τα διαφορετικά μονοπάτια που μπορεί να πάρει μία δομή ελέγχου και τα αθροίζει Μέγεθος Κώδικα Η πιο διαδεδομένη μετρική για το μέγεθος κώδικα είναι οι γραμμές κώδικα (LOC Lines of Code ή SLOC Source Lines of Code). Η μετρική αυτή έχει τις καταβολές της στην εποχή της assembly. Τα προβλήματα με τον ορισμό αυτής της μετρική ξεκίνησαν όταν έπρεπε να εφαρμοστεί σε πιο εξελιγμένες γλώσσες προγραμματισμού. Σύμφωνα με τον Henderson-Sellers [2] ο πιο διαδεδομένος ορισμός για τις γραμμές κώδικα σήμερα είναι ο εξής: Σαν γραμμή κώδικα μετριούνται όλες οι γραμμές κώδικα που δεν είναι σχόλιο ή κενές γραμμές. Ο ορισμός αυτός περιλαμβάνει όλες τις υπόλοιπες γραμμές όπως οι επικεφαλίδες, οι δηλώσεις καθώς και οι εκτελούμενες και μη εντολές. Η μετρική αυτή, γνωστή και με το όνομα NCLOC not commented lines of code, είναι χρήσιμη για τη σύγκριση διαφορετικών υποσυστημάτων και μερών του κώδικα καθώς και γλωσσών υλοποίησης των διάφορων συστημάτων. Για παράδειγμα το 71% των γραμμών κώδικα του Debian είναι γραμμένο σε C. Μία άλλη χρήση είναι η εκτίμηση της αύξησης του συστήματος σε συνάρτηση με το χρόνο. Κάποιες έρευνες που έγιναν πάνω στις διανομές Linux δείχνουν γραμμική αύξηση της μετρικής ενώ κάποιες άλλες έρευνες δείχνουν ότι η μετρική αυξάνεται με ακόμη μεγαλύτερο ρυθμό. Υπάρχουν και άλλοι τρόποι να μετρήσει κανείς τις γραμμές κώδικα. Επιγραμματικά θα αναφερθούν κάποιες: 46 Μέγεθος/Πολυπλοκότητα [39]. Η μετρική αυτή είναι μία επέκταση της SLOC. Προέκυψε σαν μία προσπάθεια να περιοριστεί η αδυναμία της SLOC να προσδιορίσει και άλλα χαρακτηριστικά του κώδικα, πέρα από το μέγεθός του όπως η συντηρισιμότητα, η ευκολία

47 στο στην διόρθωση σφαλμάτων και στον έλεγχο. Χρησιμοποιώντας την έννοια της κυκλωματικής πολυπλοκότητας στον παρονομαστή αυτής της μετρικής εξάγεται πληροφορία σχετικά με το πόσο «πυκνή» είναι η κάθε γραμμή. Έτσι με αυτό τον τρόπο η μετρική SC διαφοροποιεί τα προγράμματα που έχουν τις ίδιες γραμμές κώδικα βάση πολυπλοκότητας. LOC = NCLOC+CLOC (Non-Commented LOC + Commented LOC) καθώς και η αναλογία CLOC LOC Fenton [23]. Η μετρική αυτή χρησιμοποιείται για να μετρήσει αποτελεσματικά το μέγεθος του λειτουργικού κομματιού του κώδικα και την ανάπτυξή του στο χρόνο καθώς και το μέγεθος των σχολίων. Συνολικά μπορούμε να πούμε ότι ο ορισμός του μεγέθους του κώδικα εξαρτάται από τον τρόπο με τον οποίο πρόκειται να χρησιμοποιηθεί (σύγκριση έργων πληροφορικής, μέτρηση παραγωγικότητας, εξέλιξη έργου στο χρόνο, μέτρηση επιδόσεων ομάδων προγραμματιστών κα). Εικόνα 10 Γραμμές κώδικα συστημάτων αεροπλάνων και διαστημοπλοίων [40] 47

48 Halstead s complexity metrics Οι μετρικές αυτές ορίστηκαν το 1977 από τον Halstead [41] και εκφράζουν το μέγεθος ενός προγράμματος ως προς τους τελεστές που χρησιμοποιεί. Συνοπτικά οι μετρικές είναι οι παρακάτω: Αριθμός διακριτών τελεστέων: πόσοι διαφορετικοί τελεστέοι βρίσκονται σε ένα μέρος του προγράμματος Αριθμός διακριτών τελεστών: πόσοι διαφορετικοί τελεστές βρίσκονται σε ένα μέρος του προγράμματος Αριθμός εμφάνισης τελεστέων, σε ένα μέρος του προγράμματος Αριθμός εμφάνισης τελεστών, σε ένα μέρος του προγράμματος Μέγεθος λεξικού: είναι το άθροισμα διακριτών τελεστέων και τελεστών σε ένα μέρος του προγράμματος Μέγεθος component: είναι το άθροισμα του αριθμού εμφάνισης τελεστέων και τελεστών Όγκος προγράμματος: V = N log 2 (n) Όπου Ν είναι το μέγεθος component και n είναι το μέγεθος λεξικού Μετρικές αντικειμενοστραφούς λογισμικού Οι μετρικές που αφορούν τον αντικειμενοστραφές κώδικα έχουν διαφορετικά χαρακτηριστικά από αυτές του δομημένου προγραμματισμού. Οι μετρικές του αντικειμενοστραφούς κώδικα εστιάζουν πάνω στα ειδικά χαρακτηριστικά του και τις ιδιότητές του. Συγκεκριμένα: πολυμορφισμός, ενσωμάτωση, απόκρυψη πληροφορίας, κληρονομικότητα, μετάδοση μηνυμάτων και επαναχρησιμοποίηση. Στη συνέχεια θα παρουσιαστούν κάποια πακέτα μετρικών που υπάρχουν στη βιβλιογραφία. 48

49 Εικόνα 11 Θεωρητική προσέγγιση μετρικών αντικειμενοστραφούς κώδικα Μέθοδοι ανά κλάση (Weighted Method per Class - WMC) Η μετρική αυτή ορίζεται ως εξής: WMC = n i=1 c i, Όπου το εκάστοτε c είναι ένα κανονικοποιημένο μέτρο (0-1.0) πολυπλοκότητας της κάθε μεθόδου της κλάσης. Ένας τρόπος μέτρησης της πολυπλοκότητας είναι η κυκλωματική πολυπλοκότητα [42] Βάθος δέντρου κληρονομικότητας (Depth of Inheritance Tree - DIT) Η μετρική αυτή ορίζεται [42] ως το μέγιστο μήκος από την ρίζα του δέντρου κληρονομικότητας των κλάσεων προς οποιοδήποτε κόμβο του. Όσο αυξάνει το βάθος του δέντρου, οι κλάσεις χαμηλών επιπέδων κληρονομούν περισσότερες μεθόδους, γεγονός που αυξάνει την πολυπλοκότητα και περιορίζει τη δυνατότητα πρόβλεψης της συμπεριφοράς μιας κλάσης. Παράδειγμα: 49

50 Εικόνα 12 Παράδειγμα DIT DIT (C0) = 0 DIT (C0 ) = 0 DIT (C1) = 1 DIT (C2) = 2 DIT (C3) = 3 DIT (C4) = Αριθμός απογόνων (Number of Children NOC) Οι κλάσεις που κληρονομούν μία άλλη κλάση είναι οι άμεσοι απόγονοί της [42]. Η μετρική αυτή μετράει ακριβώς αυτό, τους άμεσους απογόνους μίας κλάσης. Όσο αυξάνει ο αριθμός των απογόνων αυξάνει ο βαθμός επαναχρησιμοποίησης, αλλά ταυτόχρονα αυξάνεται η προσπάθεια που απαιτείται για τον έλεγχο του συστήματος. Παράδειγμα: 50

51 Εικόνα 13 Παράδειγμα NOC DIT (C0) = 0 DIT (C0 ) = 0 DIT (C1) = 1 DIT (C2) = 2 DIT (C3) = 1 DIT (C4) = Σύζευξη μεταξύ κλάσεων (Coupling Between Objects CBO) Η μετρική αυτή αναφέρεται στον αριθμό των κλάσεων που παρέχουν σε μία κλάση Α τις απαραίτητες πληροφορίες (δεδομένα ή λειτουργίες) ώστε να ολοκληρώνονται οι μέθοδοί της. Η τιμή CBO σχετίζεται με τη δυνατότητα επαναχρησιμοποίησης της κλάσης, τροποποίησής και ελέγχου της. Η απαίτηση να είναι η σύζευξη μεταξύ κλάσεων χαμηλή είναι παρόμοια με την απαίτηση για χαμηλή σύζευξη στον διαδικαστικό προγραμματισμό. Στη βιβλιογραφία υπάρχουν και άλλες ιδέες σχετικά με το CBO όπως για παράδειγμα αν στη σύζευξη υπολογίζεται και η κληρονομικότητα. Οι Chidmaber και Kemmerer [42] παρότι δεν ορίζουν ακριβώς πότε δύο κλάσεις είναι συζευγμένες αναφέρουν στο άρθρο τους χαρακτηριστικά ότι δύο κλάσεις είναι 51

52 συζευγμένες όταν μία κλάση χρησιμοποιεί μεθόδους ή χαρακτηριστικά ή στιγμιότυπα της άλλης κλάσης. Ο Henderson-Sellers [2] αναφέρει ότι η σύζευξη είναι εν γένη χαρακτηριστικό της ιδιοτήτων της κληρονομικότητας και του πολυμορφισμού στα αντικειμενοστραφή συστήματα. Αναφέρει ακόμα χαρακτηριστικά πως ενώ η χρήση του πολυμορφισμού μειώνει την πολυπλοκότητα ταυτόχρονα μειώνει και την χρησιμότητα των παραδοσιακών μετρικών εξαιτίας της σύζευξης που προκύπτει λόγω κληρονομικότητας. Ως αντίμετρο στο παραπάνω γεγονός προτείνεται η μετρική fan-down των Sheetz et al [15] που ορίζεται ως ο αριθμός των υποκλάσεων που αντικαθιστούν μία υλοποιημένη μέθοδο του προγόνου τους. Ένας γενικός τύπος για τον υπολογισμό της CBO είναι: CBO = Αριθμός διακριτών κλάσεων που χρησιμοποιεί ένα πακέτου/υποσυστήμα Αριθμός των κλάσεων του πακέτου/υποσυστήματος Απόκριση μιας κλάσης (Response For a Class RFC) Ορίζεται ως το άθροισμα όλων των μεθόδων μιας κλάσης C καθώς και των μεθόδων άλλων κλάσεων που καλούνται από τις μεθόδους της C [42]. Η μετρική αυτή είναι ενδεικτική της πολυπλοκότητας της κλάσης και του βαθμού συσχέτισής της με άλλες κλάσεις. Από πειραματικά δεδομένα, έχει προκύψει ότι όσο μεγαλύτερη είναι η τιμή RCF τόσο υψηλότερη είναι η πιθανότητα η εν λόγω κλάση να παρουσιάσει λάθη [2]. Παράδειγμα: 52

53 new ClassB() dosomething() System.out.println(..) dosomethingbasedonclassb() ClassB.toString() Άδειος constructor της ClassA() Συνεπώς RFC = Βαθμός συνεκτικότητας των μεθόδων (Lack of Cohesion in Methods LCOM) Η μετρική αυτή προσπαθεί να εντοπίσει την ομοιότητα σε μια κλάση με σκοπό να φανερώσει αν υπάρχουν κλάσεις που θα μπορούσαν να χωριστούν σε περισσότερες κλάσεις. Ορίζεται ως εξής. Έστω μία κλάση C με n μεθόδους M1, M2,, Mn και Ιj οι μεταβλητές του στιγμιότυπου (instance variable) που χρησιμοποιούνται από τη μέθοδο Mj. Υπάρχουν n τέτοια σύνολα μεταβλητών I. Σχηματίζοντας δύο σύνολα ζευγών μεθόδων σε κάθε κλάση: Η μετρική LCOM ορίζεται ως: P = {(I i, I j ) I i I j = } Και Q = {(I i, I j ) I i I j } P Q, P > Q LCOM = { 0, αλλιώς Συνεπώς η μετρική μπορεί να οριστεί και ως ο αριθμός των ζευγών μεθόδων που έχουν ομοιότητα παραμέτρων 0 μείον τον αριθμό των ζευγών μεθόδων που έχουν ομοιότητα παραμέτρων [42]. Ο Henderson-Sellers [2] εντόπισε προβλήματα σε αυτή τη μετρική αναφέροντας χαρακτηριστικά ότι προσπαθεί να μετρήσει μόνο τη δομική συνεκτικότητα, όταν ένα από τα σημαντικότερα χαρακτηριστικά της αντικειμενοστραφούς σχεδίασης είναι η λογική συνεκτικότητα των αντικειμένων. Ακόμη εντόπισε προβλήματα στο γεγονός ότι παρότι μικρές τιμές του LCOM θα έπρεπε να υποδηλώνουν υψηλή συνεκτικότητα αυτό δεν ισχύει πάντα. Έτσι ο Henderson-Sellers δοκίμασε να ορίσει ξανά τη μετρική ως εξής: 53

54 LCOM = (1 a a j=1 μ(a j) ) m Όπου a είναι ο αριθμός των μεταβλητών της κλάσης, m είναι ο αριθμός των μεθόδων της κλάσης, Aj είναι το σύνολο των μεταβλητών που χρησιμοποιεί η συνάρτηση j και m(aj) είναι ο αριθμός των μεθόδων που χρησιμοποιούν το σύνολο μεταβλητών Aj. Η μετρική αυτή δίνει τιμές από το 0 έως και το 1, όπου 0 σημαίνει ότι όλες οι μέθοδοι προσπελαύνουν όλες τις μεταβλητές και έχουν υψηλή συνεκτικότητα και η τιμή 1 σημαίνει κάθε συνάρτηση προσπελαύνει μόνο μία μεταβλητή (όταν m=a) Fan in και Fan-out κλάσεων Ο Henderson-Sellers [2] ορίζει το fan-in ως το αριθμό των κλάσεων που αναφέρουν τη μετρούμενη κλάση και ως fan-out τον αριθμό των κλάσεων στις οποίες η μετρούμενη κλάση αναφέρεται. Τόσο το fan-in όσο και το fan-out μετρούνται μία φορά ανεξαρτήτως από το πόσες φορές γίνεται αναφορά σε μία κλάση. Η μετρική fan-out τυπικά είναι ίδια με την CBO που πρότειναν οι Chidamber και Kemmerer [42], ακόμη η μετρική fan-out ταυτίζεται με τον αριθμό κλάσεων που έχει σύζευξη μία κλάση χωρίς να υπολογίζει την κληρονομικότητα. Τέλος ο Handerson-Sellers υποστηρίζει ότι ένα μεγάλο μέγεθος fan-out αυξάνει την πολυπλοκότητα λόγω των αυξημένων συσχετίσεων και ότι ένας μεγάλο μέγεθος fan-in δηλώνει ένα καλό αρχιτεκτονικό σχεδιασμό και καλή επαναχρησιμοποίηση του κώδικα. Εδώ υπάρχει βέβαια μία αντίφαση μιας και σε επίπεδο συστήματος το fan-in είναι ίσο με το fan-out οπότε χρειάζεται περισσότερη έρευνα σχετικά με το ποια αναλογία φανερώνει ένα καλό σχεδιασμό Σύζευξη μεταδιδόμενων μηνυμάτων (Message passing coupling MPC) Αυτή η μετρική προτάθηκε από τους Li και Henry [43] και ορίζεται ως ο αριθμός των εντολών αποστολής που ορίζονται σε μία κλάση. Σε αντίθεση με το fan-in/fan-out κλάσεων εδώ κάθε «αποστολή» προσμετράτε κάθε φορά. Οι συγγραφείς υποστηρίζουν ότι η μετρική αυτή δείχνει το κατά πόσο η υλοποίηση της μετρούμενης κλάσης βασίζεται σε συναρτήσεις άλλων κλάσεων 1 m, 54

55 Εικόνα 14 Παράδειγμα MPC, RFC, Fan out [43] Μέσος Όρος Σύζευξης μεθόδων (Average Method Coupling AMC) Αυτή η μετρική προτάθηκε από τους Rajaraman και Lyu [44] και ορίζεται ως εξής: Αρχικά ορίζεται η σύζευξη σε επίπεδο μεθόδου MC Method Coupling ως το άθροισμα των σχετιζόμενων με τη κληρονομικότητα συζεύξεων και το άθροισμα των μη σχετιζόμενων με την κληρονομικότητα συζεύξεων. Συγκεκριμένα: MC = gv + gf + om + iv, Όπου gv είναι ο αριθμός των μη τοπικών μεταβλητών, gf ο αριθμός των μη τοπικών συναρτήσεων, om ο αριθμός των μηνυμάτων σε άλλες κλάσεις και iv ο αριθμός των αναφορών σε στιγμιότυπα μεταβλητών (instance variables) άλλων κλάσεων. Στη συνέχεια ορίζεται η σύζευξη σε επίπεδο κλάσης (Class Coupling CC) ως εξής: Class Coupling of class C = i=1 MC i, για κάθε μέθοδο MC της κλάσης C. Τέλος o μέσος όρος σύζευξης μεθόδων ορίζεται ως: AMC = CC/n, όπου n είναι ο αριθμός των μεθόδων της κλάσης Άλλες μετρικές σύζευξης Υπάρχουν και άλλες μέθοδοι μέτρησης της σύζευξης στη βιβλιογραφία όπως ο μέσος όρος παραμέτρων ανά μέθοδο (Parameters Per Method PPM) που προτάθηκε από τους Lorenz και 55 n

56 Kidd [45] με ένα όριο να τίθεται από τους συγγραφείς ως το 0.7. Ένα ακόμη μέτρο προτάθηκε από τους Sharble και Cohen [46] και ορίζεται ως ο αριθμός των μη χρησιμοποιούμενων μεταβλητών (tramps) και ονομάστηκε NOT number of tramps. Ακόμη στο ίδιο άρθρο τους οι συγγραφείς ορίζουν το μέτρο Violations of the Law of Demeter VOD που ορίζεται ως ο αριθμός των κλάσεων που παραβιάζουν το Law of Demeter. Το Law of Demeter ορίστηκε από τους K. Lieberherr, I. IIolland, A. Riel [47] Μετρικές Mood O Abreu [48] όρισε ένα σύνολο μετρικών σε επίπεδο συστήματος σε ένα αντικειμενοστραφές περιβάλλον. Οι μετρικές που όρισε αφορούν τα χαρακτηριστικά της απόκρυψης πληροφορίας, της κληρονομικότητας και του πολυμορφισμού. Αναλυτικά: Method Hiding Factor (MHF) Οι μέθοδοι μιας κλάσης μπορεί να είναι εμφανείς από άλλες κλάσεις μπορεί να και μην είναι. Έτσι με αυτό τον τρόπο ορίζουμε το σύνολο των μεθόδων μιας κλάσης C ως: M d (C) = M v( (C) + M h (C), Όπου v, visible δηλαδή οι εμφανείς κλάσεις και h, hidden δηλαδή οι μη εμφανείς κλάσεις. Το MHF ορίζεται ως εξής: MHF = TC i=1 M h (C i ) TC i=1 M d (C i ) = 1 TC i=1 M v (C i ) TC i=1 M d (C i ) Όπου το TC αναφέρεται στο συνολικό αριθμό των κλάσεων του συστήματος που μετριέται. Attribute Hiding Factor (AHF) Αντίστοιχα με το MHF ορίζεται και το AHF με τη διαφορά ότι αναφέρεται στα γνωρίσματα (attributes) μιας κλάσης αντί για τις μεθόδους της. Συγκεκριμένα ορίζεται ως συνολικός αριθμός γνωρισμάτων μίας κλάσης C: Και το AHF ως: M d (C) = M v( (C) + M h (C) AHF = TC i=1 A h (C i ) TC i=1 A d (C i ) = 1 TC i=1 A v (C i ) TC i=1 A d (C i ),, 56

57 Το να έχει είτε η MHF είτε η AHF τιμή ίση με ένα σημαίνει ότι όλες οι μέθοδοι ή τα χαρακτηριστικά τους δεν είναι προσβάσιμα κάτι το οποίο συνεπάγεται μειωμένη λειτουργικότητα. Αντίθετα αν οι τιμές των μετρικών είναι 0 τότε όλες οι μέθοδοι και τα χαρακτηριστικά είναι διαθέσιμα κάτι το οποίο συνεπάγεται κακή σχεδίαση και μη χρήση της απόκρυψης πληροφορίας. Οι τιμές του ΜHF προτείνεται να κυμαίνονται στο διάστημα και οι τιμές του ΑΗF να βρίσκονται όσο πιο κοντά στο 0. Method Inheritance Factor (MIF) Το σύνολο των μεθόδων μίας κλάσης ορίζεται ως εξής: M a (C) = M d( (C) + M i (C), Όπου Μa είναι το σύνολο των μεθόδων της κλάσης και το σύνολο των μεθόδων που η κλάση κληρονομεί. Ως Md ορίζεται το σύνολο των μεθόδων που ορίζονται στην κλάση και των μεθόδων που η κλάση κληρονομεί αλλά έχει και υλοποίηση. Δεδομένων των παραπάνω το MIF ορίζεται ως: Attribute Inheritance Factor (AIF) MIF = TC i=1 M i(c i ) TC M a (C i ) i=1 = 1 TC i=1 M d(c i ) TC M a (C i ) Αντίστοιχα ορίζεται και το AIF. Το σύνολο των χαρακτηριστικών μίας κλάσης ορίζεται ως: Και το AIF ως: i=1 Α a (C) = Α d( (C) + Α i (C) ΑIF = TC i=1 Α i(c i ) TC Α a (C i ) i=1 = 1 TC i=1 Α d(c i ) TC Α a (C i ) Οι μετρικές MIF και AIF ως μετρικές κληρονομικότητας προσπαθούν να εκφράσουν την ομοιότητα μεταξύ των κλάσεων, τις σχέσεις γενίκευσης και εξειδίκευσης μεταξύ τους καθώς και την επαναχρησιμοποίηση του κώδικα. Οι τιμές του MIF συνίσταται να κυμαίνονται στο διάστημα και οι τιμές του AIF στο διάστημα i=1 57

58 Polymorphism Factor (PF) Η μετρική POF μετράει τον πολυμορφισμό δηλαδή το βαθμό που μία κλάση που κληρονομεί μεθόδους παρέχει υλοποίηση για τις μεθόδους της κλάσης που τις κληρονόμησε. Συγκεκριμένα ως POF ορίζεται: TC i=1 M o (C i ) POF = TC [M n (C i ) DC(C i )] i=1 Όπου Mn είναι ο αριθμός των νέων μεθόδων που ορίζονται στην κλάση, Mo είναι ο αριθμός των μεθόδων που ορίζονται στην κλάση όπου η κλάση C κληρονομεί και ταυτόχρονα όμως η κλάση παρέχει υλοποίηση και DC ο αριθμός των κλάσεων που κληρονομούν την κλάση C. Η μετρική POF παίρνει τιμές από το 0 έως το 1 με το ένα να σημαίνει ότι όλες οι μέθοδοι στις κλάσεις που κληρονομούν από άλλες κλάσεις έχουν υλοποίηση από την κλάση και το μηδέν συμβολίζει ένα από τα παρακάτω: Το σύστημα δεν έχει κλάσεις ή δε χρησιμοποιεί κληρονομικότητα Το σύστημα δεν χρησιμοποιεί την ιδιότητα του πολυμορφισμού (no overriding) Ο Abreu αναφέρει ότι τιμές POF μεγαλύτερες από 0.1 θεωρούνται υψηλές. Coupling Factor (CF) Ο Abreu ορίζει και αυτός μία μετρική που αφορά τη σύζευξη μεταξύ κλάσεων. Συγκεκριμένα αναφέρει ότι μία κλάση είναι πελάτης μίας άλλης κλάσης (παροχέας) αν αυτή η κλάση έχει τουλάχιστον μία αναφορά στον παροχέα. Η σύζευξη μπορεί να είναι δυναμική ή στατική με δυναμική σύζευξη να ορίζεται όταν μία κλάση στέλνει ένα μήνυμα σε μία άλλη κλάση και στατική όταν υπάρχει μία αναφορά στην άλλη κλάση. Δεδομένων των παραπάνω η COF ορίζεται ως: TC TC COF = i=1 [ j=1 isclient(c i, C j )] TC 2 TC 2 TC DC(C i ) Η μετρική παίρνει τιμές από το 0 έως το 1, με το μηδέν να συμβολίζει μηδαμινή σύζευξη και το ένα να συμβολίζει ότι όλες οι κλάσεις ενώνονται με όλες τις άλλες. Οι σχέσεις κληρονομικότητας μεταξύ των κλάσεων δεν συμπεριλαμβάνονται στον υπολογισμό του COF. Η προτεινόμενη τιμή i=1 58

59 για τη μέγιστη τιμή της μετρικής είναι το Μεγαλύτερα νούμερα υποδηλώνουν κακή σχεδίαση και κακή χρήση των χαρακτηριστικών της αντικειμενοστραφούς σχεδίασης Αντικειμενοστραφής μετρικές Συστήματος RC Martin Ο R.C. Martin [49] υποστηρίζει ότι η σχεδίαση του κώδικα δεν μπορεί να είναι εντελώς στατική, χρειάζεται κάποια ευελιξία. Η ευελιξία αυτή επιτυγχάνεται μέσω της συμμόρφωση με το Common Closure Principle CCP που αναφέρει ότι όταν γίνεται αλλαγή στην κλάση ενός component τότε αλλαγές θα χρειάζονται μόνο οι κλάσεις αυτού του component και καμία άλλη κλάση. Χρησιμοποιώντας την αρχή CCP δημιουργούνται components τα οποία μπορούν να δεχτούν ευκολότερα αλλαγές. Στη συνέχεια και δεδομένων των παραπάνω ορίζεται η Αρχή των Σταθερών Εξαρτήσεων (Stable-Dependencies Principle SDP) η οποία αναφέρει ότι η εξαρτήσεις των component πρέπει να είναι σταθερές. Σε ότι αφορά τη σταθερότητα ο Martin αναφέρει ότι ΜΗ σταθερή είναι μία κλάση η οποία είναι δύσκολο να αλλάξει γιατί έχει πολλές εξαρτήσεις προς εκείνη. Ορίζονται οι μετρικές Ca ως ο αριθμός των κλάσεων εκτός του component που βασίζονται σε κλάσεις του component, Ce ως ο αριθμός των κλάσεων του component που βασίζονται σε κλάσεις εκτός component. Δεδομένων των ορισμών αυτών ορίζεται ο παράγοντας της ΜΗ Σταθερότητας I ως εξής: I = Ce Ca + Ce Όπου I=0 υποδηλώνει ένα σταθερό component και I=1 δηλώνει ένα μη σταθερό component. Συγκεκριμένα όταν η μετρική είναι 1 τότε το Ca είναι 0 και το οποίο σημαίνει ότι κανένα άλλο component δεν εξαρτάται από το component που μετράμε. Έτσι οποιαδήποτε αλλαγή στο component που μετράμε δεν επηρεάζει το υπόλοιπο σύστημα άρα το component είναι ΜΗ σταθερό. Ακόμη όταν η μετρική είναι 0 σημαίνει ότι το Ce είναι 0 το οποίο σημαίνει ότι το component που μετράμε δεν εξαρτάται από άλλα components αλλά πολλά components εξαρτώνται από αυτό κάτι το οποίο κάνει το component δύσκολο στην αλλαγή και άρα σταθερό. Είναι φανερή η ομοιότητα του Ca με τη μετρική fan-in και του Ce με τη μετρική fan-out με τη διαφορά ότι τα Ca, Ce ορίζονται σε επίπεδο component και όχι σε επίπεδο κλάσης. 59

60 Μετρικές Αφαίρεσης (Abstraction) Ο Martin ορίζει τη σχέση μεταξύ σταθερότητας και αφαίρεσης ως εξής: Ένα component πρέπει να έχει το αντίστοιχο επίπεδο αφαίρεσης με το επίπεδο σταθερότητάς του. Την αρχή αυτή την ονομάζει Stable-Abstraction Principle SAP και θεμελιώνει το επιχείρημα του λέγοντας ότι τα σταθερά components πρέπει να περιέχουν και abstract κλάσεις ώστε να μην περιορίζεται η επεκτασιμότητά τους. Για τη μέτρηση του επιπέδου της αφαίρεσης ο Martin προτείνει την μετρική A = Na Nc Όπου Nc είναι ο αριθμός των κλάσεων σε ένα component και Na είναι ο αριθμός των αφαιρετικών κλάσεων σε ένα component. Αν η μετρική είναι 0 τότε το component δεν έχει αφαιρετικές κλάσεις και αν είναι 1 περιέχει μόνο αφαιρετικές κλάσεις Σχέση μεταξύ σταθερότητας και αφαίρεσης Ο Martin όρισε τη επιθυμητή σχέση μεταξύ σταθερότητας και αποφυγής ως εξής: Εικόνα 15 Διάγραμμα σταθερότητας αφαίρεσης [49] Στο παραπάνω διάγραμμα ο κάθετος άξονας συμβολίζει το επίπεδο της αφαίρεσης και ο οριζόντιος άξονας συμβολίζει το επίπεδο της σταθερότητας. Οι επιθυμητές τιμές σταθερότητας και αφαίρεσης ενός component πρέπει να βρίσκονται πάνω στη γραμμή που ενώνει τα σημεία 60

61 (0,1) και (1, 0). Οποιοδήποτε από αυτά τα σημεία έχει την ιδανική κατά Martin αναλογία μεταξύ επιπέδου αφαίρεσης και επιπέδου σταθερότητας. Για να μετρήσει την απόσταση από την κύρια γραμμή ο Martin όρισε τη μετρική της απόστασης που ορίζεται ως εξής: A + I 1 D = 2 Καθώς και τη D = A + I 1 Όπου D η απόσταση που κυμαίνεται από στο διάστημα [0, ~0.707] και την κανονικοποιημένη εκδοχή της D που παίρνει τιμές στο διάστημα [0, 1]. O Martin αναφέρει ότι οποιαδήποτε τιμή του D κοντά στο 0 για κάποιο component πρέπει οδηγήσει σε επανεξέταση του component και συνήθως σε αναδιάρθρωσή του. Για την εικόνα του συστήματος ο Martin προτείνει τον υπολογισμό του μέσου όρου και της διακύμανσης των τιμών του D για όλα τα components του συστήματος. Συγκεκριμένα δίνει το παρακάτω διάγραμμα ως παράδειγμα: Εικόνα 16 Διάγραμμα διακύμανσης σταθερότητας αφαίρεσης [49] Και αναφέρει ότι για τιμές διακύμανσης (Z) μεγαλύτερες της μονάδας τα components αυτά πρέπει να επανεξεταστούν. Επίσης προτείνει να παρατηρείται η πορεία του D κάθε component σε κάθε έκδοση και αν η τιμή του ξεπεράσει το 0.1 τότε το component να επανεξετάζεται. 61

62 3.4 Συσχέτιση μετρικών με σφάλματα λογισμικού Η εξάπλωση και η ευρεία χρήση του λογισμικού τόσο στην καθημερινότητα όσο και σε κρίσιμα συστήματα αναδεικνύει συνεχώς την ανάγκη για ανάπτυξη καλύτερων μεθόδων για τη διασφάλιση της ποιότητάς του ειδικά αν συνυπολογίσει κανείς το πόσο έχει μεγαλώσει σε μέγεθος και πολυπλοκότητα τα τελευταία χρόνια. Ένα από τα χαρακτηριστικά της ποιότητας του λογισμικού είναι το αν έχει λάθη. Τα σφάλματα δημιουργούνται κατά τη διάρκεια της ανάπτυξης του κώδικα και μπορούν να εμφανιστούν κατά τη διάρκεια όλου του χρόνου ζωής του. Όσο πιο νωρίς λοιπόν εντοπιστεί ένα λάθος τόσο μικρότερο γίνεται το κόστος της διόρθωσής του και ταυτόχρονα όσο λιγότερα είναι τα λάθη και όσο πιο νωρίς εντοπίζονται τόσο αυξάνεται και η παραγωγικότητα την ομάδας του λογισμικού και η αποτελεσματικότητά της να συναντήσει τις προσδοκίες του πελάτη [50]. Γίνεται μεγάλη προσπάθεια ώστε να μελετηθούν τα χαρακτηριστικά του λογισμικού που οδηγούν σε λάθη. Σκοπός είναι να βρεθεί ποια είναι τα χαρακτηριστικά ενός λογισμικού που συστηματικά οδηγούν σε αυξημένη πιθανότητα εμφάνισης σφάλματος. Ένα από τα χαρακτηριστικά του λογισμικού που μπορούν να συσχετιστούν με την εμφάνιση λαθών είναι και οι μετρικές κώδικα και αυτή είναι η συσχέτιση που μελετά αυτή η εργασία. Η χρήση μετρικών λογισμικού κατά τη διάρκεια της ανάπτυξής του και ειδικά στις αρχικές φάσεις της ανάπτυξης είναι μία κρίσιμή διαδικασία για τη διασφάλιση της ποιότητας. Όπως θα εξηγηθεί αναλυτικά στο κεφάλαιο 4 είναι τόσο ισχυρή η συσχέτιση κάποιων μετρικών με λάθη που οι εταιρίες παραγωγής λογισμικού θα μπορούσαν να επενδύσουν πάνω τους στην προσπάθεια για τη διασφάλιση ποιότητας. Το δύσκολο σημείο βρίσκεται στην επιλογή των κατάλληλων μετρικών. Ένας από τους λόγους που πρέπει να γίνει επιλογή των μετρικών είναι ότι δεν είναι όλες οι μετρικές λογισμικού που έχουν προταθεί στη βιβλιογραφία ίσης σημαντικότητας. Στο κεφάλαιο 4 αυτό φαίνεται ξεκάθαρα από τη μελέτη εμπειρικών μελετών. Υπάρχουν βέβαια φορές που τα αποτελέσματα είναι μη συνεπή μεταξύ των ερευνών στη βιβλιογραφία κάτι που κάνει την επιλογή των μετρικών ακόμα πιο περίπλοκη διαδικασία. 62

63 4 Μετρικές και σφάλματα λογισμικού Στο προηγούμενο κεφάλαιο ορίστηκαν ένα μεγάλο σύνολο μετρικών. Σε αυτό το κεφάλαιο θα γίνει μία εκτενής περιγραφή των μελετών που έχουν γίνει πάνω στις μετρικές λογισμικού. Συγκεκριμένα θα γίνει εστίαση πάνω στο κομμάτι της βιβλιογραφίας που μελετά τη συσχέτιση μεταξύ διαφόρων μετρικών και της ύπαρξης ή της πιθανότητας εμφάνισης σφαλμάτων στον κώδικα. Στην ενότητα 4.1 θα παρουσιαστεί η δουλειά που έχει γίνει πάνω στο αντικείμενο και θα εστιάσει στις εμπειρικές μελέτες που δίνουν ένδειξη σχετικά με το τι χρησιμοποιείται στη βιβλιογραφία. Στην ενότητα 4.2 γίνεται περιγραφή των ερευνών της βιβλιογραφίας που συσχετίζουν την ύπαρξη ή την πιθανότητα εμφάνισης λαθών με μετρικές και κυρίως με μετρικές αντικειμενοστραφούς λογισμικού. Στην ενότητα 4.3 θα γίνει η ανάλυση των αιτιών που οδήγησαν στην δημιουργία της παρούσας έρευνας. 4.1 Εμπειρικές μελέτες Isong, Bassey και Obeten, Ekabua Οι Isong, Bassey και Obeten, Ekabua [51] έκαναν μία βιβλιογραφική έρευνα προσπαθώντας να εξερευνήσουν τα παραπάνω ερωτήματα. Τα ερωτήματα που τέθηκαν είναι Ποιες μετρικές στη σουίτα μετρικών CK σχετίζονται στατιστικά με την ύπαρξη λαθών. Ποιες τεχνικές χρησιμοποιούνται για να γίνει η στατιστική συσχέτιση μεταξύ μετρικών και λαθών. Σε ποιο βαθμό οι μετρικές του πρώτου ερωτήματος έχουν επικυρωθεί και για αυτό το λόγο εξετάζουν τον τρόπο και τα συστήματα που χρησιμοποιήθηκαν για την επικύρωσή τους. Σε ποιο βαθμό είναι σημαντικές οι εμπειρικές αναλύσεις που αφορούν τις μετρικές λογισμικού. Υπάρχουν μετρικές λογισμικού που κάθε φορά να μπορούν να προβλέψουν την ύπαρξη λαθών. 63

64 Με σκοπό την απάντηση των παραπάνω ερωτημάτων ελέγχθηκαν 29 έρευνες και τα αποτελέσματα παρουσιάζονται παρακάτω: Μετρική Σημαντική Μη σημαντική Δε μελετήθηκε WMC 22/29 1/29 6/29 CBO 23/29 1/29 5/29 RFC 24/29 0/29 5/29 LCOM 13/29 4/29 12/29 DIT 9/29 15/29 5/29 NOC 3/29 15/29 11/29 SLOC 18/29 0/29 11/29 H έρευνα συνεχίζει με κάποια ακόμα πολύ ενδιαφέρονται ευρήματα όπως ότι το 76% των ερευνών χρησιμοποιεί Λογιστική Παλινδρόμηση για την εξαγωγή της πληροφορίας σχετικά με το αν οι μετρικές μπορούν να προβλέψουν λάθη. Ακόμη το 87% των ερευνών χρησιμοποιούν την ύπαρξη λάθους σαν την εξαρτημένη μεταβλητή τους. Όσον αφορά τον τρίτο ερώτημα που αφορά την επικύρωση των μετρικών, βρέθηκε ότι το 79% έγινε από επαγγελματίες/εταιρείες και το 21% από ερευνητές, και σε ότι φορά το λογισμικό που χρησιμοποιήθηκε για τη συλλογή των δεδομένων το 20% είχε παραχθεί από φοιτητές, το 47% ήταν μη ελεύθερο λογισμικό και το 33% ήταν ελεύθερο λογισμικό. Τέλος το 53% αφορούσε λογισμικό γραμμένο σε c++ και το 44% σε Java. Επιπροσθέτως παρατηρείται ότι μόνο το 14% των ερευνών έχουν αποτελέσματα που έχουν επαληθευτεί. Ακόμα το 97% των αποτελεσμάτων αφορά λογισμικό που δεν έχει δημοσιευτεί, κάτι που σημαίνει ότι οι μετρικές μετρήθηκαν κατά τη διάρκεια την δημιουργίας του (ανάπτυξη και έλεγχος). Αυτό το γεγονός τονίζει ιδιαίτερα την αξία των μετρικών στην εύρεση λαθών πριν δημοσιευτεί το λογισμικό που όπως αναφέρθηκε καθιστά τη διόρθωση λαθών μία λιγότερο δαπανηρή και επιβλαβή διαδικασία. Σε ότι αφορά το τέταρτο ερώτημα που αφορά τη σημαντικότητα των αναλύσεων που αφορούν τις μετρικές λογισμικού όλες οι έρευνες τη βρίσκουν σημαντική κάνοντας την υπόθεση (και 64

65 επιβεβαιώνοντάς τη) ότι οι μετρικές σχετίζονται με τη γνωστική πολυπλοκότητα και αυτό επηρεάζει την ύπαρξη λαθών κατά τρόπο που φαίνεται στο παρακάτω σχήμα: Εικόνα 17 Γνωστική Πολυπλοκότητα [51] Τέλος σχετικά με την απάντηση στου πέμπτου ερωτήματος που αφορά τη δυνατότητα των μετρικών να προβλέπουν σφάλματα, η απάντηση είναι πως ναι όπως ξεκάθαρα φαίνεται για μετρικές από το CBO, RFC, WMC και SLOC από τα αποτελέσματα της έρευνας Danijel Radjenovic et al Σε μία ακόμα συστηματική έρευνα της βιβλιογραφίας οι Danijel Radjenovic [52] και άλλοι μελέτησαν πληθώρα ερευνών πάνω στις μετρικές και τη δυνατότητα πρόβλεψης λαθών. Μελέτησαν έρευνες που αφορούσαν τόσο μετρικές διαδικαστικού κώδικα όσο και μετρικές αντικειμενοστραφούς κώδικα καθώς και μετρικές διαδικασίας. Κατέληξαν σε ενδιαφέροντα συμπεράσματα όπως ότι το 49% των μετρικών στη βιβλιογραφία αφορούν αντικειμενοστραφείς μετρικές, σε αντίθεση με της μετρικές κώδικα (27%) και τις μετρικές διαδικασίας (24%) και οι πιο συνήθεις μετρικές ήταν των Chidamber-Kemerer. Το συμπέρασμα της έρευνας ήταν ότι περισσότερες έρευνες πρέπει να γίνουν σε βιομηχανικά συστήματα ώστε να μπορεί να απαντηθεί με καλύτερη ακρίβεια το ερώτημα ποιες μετρικές είναι καλύτερες στη πρόβλεψη λαθών ανάλογα με το περιεχόμενο 65

66 4.1.3 Cagatay Catal et al Άλλη μία συστηματική έρευνα έγινα από τους Catal και άλλους [53]. Αναλύθηκαν 74 έρευνες που αφορούν την πρόβλεψη σφαλμάτων στο λογισμικό. Η έρευνα χωρίζει τις έρευνες σε αυτές πριν το 2005 και σε αυτές μετά το 2005 και προσπαθεί να αναλύσει την εξέλιξη του ενδιαφέροντος των ερευνητών. Στα αποτελέσματα της έρευνας παρατηρήθηκε σημαντική αύξηση της έρευνας πάνω στην πρόβλεψη λαθών στον κώδικα, αύξηση των ερευνών που χρησιμοποιούν δημόσια σύνολα δεδομένων κάτι που βοηθάει στην δυνατότητα επιβεβαίωσης τους, καθώς και μία συνεχή αύξηση της χρήσης μεθόδων μηχανικής μάθησης πάντα σε συνδυασμό με τα στατιστικά μοντέλα. Τέλος η πλειοψηφία των μετρικών αφορά μετρικές σε επίπεδο μεθόδου και ακολουθεί το επίπεδο κλάσης αν και τα τελευταία χρόνια παρατηρήθηκε αύξηση στις έρευνες που μελετούν τις αλλαγές σε επίπεδο αρχείου. 4.2 Μελέτες πρόβλεψης λαθών Σε αυτό το κεφάλαιο σχολιάζεται η βιβλιογραφία που ασχολείται με το πως σχετίζονται οι μετρικές κώδικα με την εμφάνιση λαθών αλλά και ποιες μέθοδοι χρησιμοποιούνται για τη συσχέτιση αυτή. Υπάρχει πληθώρα νέων μεθόδων συσχέτισης κυρίως από τον τομέα της μηχανικής μάθησης καθώς, νέες μετρικές που εξετάζονται καθώς και ενναλακτικοί τρόποι συλλογής δεδομένων προς επεξεργασία Yue Jiang et al Οι Yue Jiang και άλλοι [54] χρησιμοποίησαν μηχανική μάθηση (Random Forest, Baggin, Λογιστική Παλινδρόμηση, Boostring, Naive Bayes) πάνω στο σύνολο δεδομένων NASA MDP που περιέχει μετρικές σχεδίασης και κώδικα και εξέτασαν τη συσχέτιση με την ύπαρξη λαθών. Στα συμπεράσματά τους κατέληξαν ότι ο συνδυασμός μετρικών σχεδίασης και κώδικα έδωσε τα καλύτερα αποτελέσματα με διαφορά από μόνο τις μετρικές κώδικα και μεγάλη διαφορά από τις μετρικές σχεδίασης Tibor Gyimothy et al Οι Tibor Gyimóthy, Rudolf Ferenć, and István Siket [55] ερεύνησαν έργα ανοιχτού λογισμικού της Mozilla και προσπάθησαν να εξετάσουν αν υπάρχει συσχέτιση μεταξύ των μετρικών και της αυξημένης πιθανότητας ύπαρξης λαθών. Χρησιμοποίησαν κυρίως τις μετρικές των Chidamber-Kemerer και πέραν της λογιστικής παλινδρόμησης χρησιμοποίησαν μοντέλα μηχανικής μάθησης όπως δέντρα απόφασης και νευρωνικά δίκτυα για να εξετάσουν τη 66

67 χρησιμότητα των μετρικών στην πρόβλεψη λαθών. Τα αποτελέσματα της έρευνας φαίνονται στην παρακάτω εικόνα: Εικόνα 18 Αποτελέσματα Tibor Gyimothy [55] Συνοπτικά από τα αποτελέσματα φαίνεται ότι δεν υπήρχαν σημαντικές διαφορές στην ορθότητα και την ακρίβεια της κατηγοριοποίησης που να εξαρτώνται από τη μέθοδο της κατηγοριοποίησης. Ακόμη δεν υπήρχε σημαντική διαφορά στην ικανότητα εύρεσης λαθών ανάλογα με τη μετρική με την εξαίρεση τις μετρικές LCOM όταν κατηγοριοποιήθηκαν με λογιστική παλινδρόμηση Michael English et al Οι Michael English και άλλοι [56] υποστηρίζουν ότι η συντήρηση λογισμικού συνεχίζει να είναι μία ακριβή διαδικασία τόσο σε χρόνο όσο και σε πόρους που καταναλώνει, συνεπώς κάθε προσπάθεια που βοηθάει αυτή τη διαδικασία είναι ευπρόσδεκτο. Ένα τέτοιο βήμα λοιπόν θα ήταν η αναγνώριση εκείνων των σημείων στον κώδικα που ενδέχεται να χρειαστούν αλλαγές μιας και 67

68 υπάρχει μεγάλη πιθανότητα να προκαλέσουν λάθη. Οι ερευνητές μάζεψαν δεδομένα από CVS αποθετήρια και χρησιμοποίησαν Bugzilla με σκοπό να αναγνωρίσουν τα μέρη που έχουν λάθη, τη σημαντικότητα του λάθους. Τα ερωτήματα που έθεσαν ήταν: Ισχύει ο νόμος του Pareto ότι το 80% των λαθών βρίσκεται στο 20% των κλάσεων Είναι οι μετρικές CK καλές στο να αναγνωρίζουν κλάσεις με και χωρίς λάθη; Μπορούν οι μετρικές CK να αναγνωρίσουν αποτελεσματικά το αν υπάρχουν λάθη που βρίσκονται σε κλάσεις που είναι επιρρεπείς σε σφάλματα; Οι ερευνητές μελέτησαν το έργο του Mozilla και το JDT και μάζεψαν δεδομένα χρησιμοποιώντας το εργαλείο Venus (Eclipse plugin) καθώς και το εργαλείο Understand για ανάλυση του πηγαίου κώδικα. Για την απάντηση των ερωτημάτων και τη συσχέτιση μετρικών με πιθανότητα λάθους χρησιμοποίησαν Λογιστική Παλινδρόμηση. Στα συμπεράσματα της έρευνας βρέθηκε ότι ο νόμος του Pareto ισχύει και ότι οι μετρικές CBO, RFC και LOC είναι οι πιο σημαντικές μετρικές όσον αφορά τις προβλέψεις σφαλμάτων Shihab et al O Shihab και άλλοι ερεύνησαν τρεις διαφορετικές κυκλοφορίες του eclipse [57]. Η μεθοδολογία φαίνεται στην παρακάτω εικόνα. Σκοπός της έρευνας ήταν να βρει ένα μικρό αριθμό από μετρικές που θα είναι πολύ αποδοτικές σε μοντέλα πρόβλεψης σφαλμάτων. Ελέγχθηκαν 34 μετρικές και χρησιμοποιήθηκε Λογιστική Παλινδρόμηση και οι συγγραφείς οδηγήθηκαν πράγματι σε ένα μικρότερο σετ μετρικών, συγκεκριμένα τις Anonymous Type Declarations (ACD), Number of Static Methods (NSM), Max Number of Parameters (PAR max), Total Prior Changes (TPC), Total Lines of Code (TLOC) και Pre-release Defects (PRE). Η ροή της διαδικασίας που ακολούθησαν φαίνεται στην παρακάτω εικόνα: 68

69 Εικόνα 19 Shihab et al [57] Οι συγγραφείς συμπέραναν ότι χρησιμοποιώντας ένα μικρότερο σύνολο στατιστικά σημαντικών μεταβλητών δεν επηρεάζει αρνητικά την ικανότητα να προβλέπουν την πιθανότητα σφάλματος Catal et al Οι Catal και άλλοι [58] εξέτασαν τις μετρικές των Chidamber-Kemerer καθώς και αυτές των McCabe και Halstead προσπαθώντας να εντοπίσουν το μοντέλο πρόβλεψης λαθών το οποίο να βασίζεται στον αλγόριθμο Artificial Immune Recognition System (AIRS). Οι συγγραφείς εξέτασαν 94 μετρικές εκ των οποίων οι 84 ήταν μετρικές μεθόδων και οι 10 μετρικές κλάσεων. Τα δεδομένα που εξετάστηκαν αποτελούνταν από ένα πρόγραμμα της NASA που αντικείμενό του είναι να δέχεται και να επεξεργάζεται μηνύματα. Το έργο αυτό είναι γραμμένο σε C++. Τα αποτελέσματα έδειξαν ότι τα καλύτερα αποτελέσματα σχετικά με την πρόβλεψη λαθών προκύπτουν από των συνδυασμό των μετρικών των Chidamber-Kemerer σε συνδυασμό με τη μετρική LOC Olague et al Οι Olague και άλλοι [59] ερεύνησαν τρεις σουίτες μετρικών (CK, MOOD και QMOOD) ως προς την ικανότητά τους να εντοπίζουν πιθανότητα σφαλμάτων. Οι ερευνητές χρησιμοποίησαν το έργο Mozilla Rhino το οποίο είναι μία πλατφόρμα εκτέλεσης της Javascript γραμμένη αποκλειστικά σε Java. Όσον αφορά τα αποτελέσματα οι συγγραφείς κατέληξαν ότι τα καλύτερα αποτελέσματα είχαν οι μετρικές των Chidamber-Kemerer αλλά και ότι κάποιες από τις μετρικές της σουίτας μετρικών QMOOD ήταν αποτελεσματικές ως προς την ικανότητά τους να προβλέπουν σφάλματα. 69

70 4.2.7 Grave et al Οι Graves και άλλοι [60] έδειξαν ότι ο αριθμός των αλλαγών που έχουν γίνει σε ένα αρχείο κώδικα είναι η πιο σημαντική πληροφορία σχετικά το αν θα παρουσιαστεί σφάλμα. Συγκεκριμένα χρησιμοποιώντας Generalized linear models (GLMs μία επέκταση της Λογιστικής Παλινδρόμησης) βρήκαν ότι οι γραμμές κώδικα από μόνες τους δεν είναι μία στατιστικά σημαντική μεταβλητή για την πρόβλεψη σφαλμάτων όταν ο λαμβάνει κανείς υπόψιν τον αριθμό των αλλαγών σε ένα αρχείο κώδικα. Οι συγγραφείς συμπέραναν ότι το ιστορικό αλλαγών περιέχει πολύ περισσότερη και χρήσιμη πληροφορία από αυτή που μπορεί να προκύψει από τις μετρικές μεγέθους και τις μετρικές δομής Jureczko Marian Ο Jureczko [61] χρησιμοποίησε δεκατέσσερα έργα για να αξιολογήσει πληθώρα μετρικών σχετικά με την ικανότητά τους να προβλέπουν σφάλματα. Οι μετρικές που εξέτασε είναι αυτές των Chidamber-Kemerer, η LCOM που πρότεινε ο Handerson-Sellers, οι μετρικές του Rob Martin, οι μετρικές Mood και του McCabe σε συνδυασμό με κάποιες μετρικές που πρότεινε ο ίδιος. Οι μετρικές που προτάθηκαν ήταν η Number of Revision NR, Number of Distinct Committers NDC, Number of Modified Lines NML Number of Defects in Previous Version NDPV που μετράνε τα αντίστοιχα το πόσες φορές άλλαξε μία κλάση, πόσοι την άλλαξαν, πόσες γραμμές αλλάχτηκαν και τον αριθμό των σφαλμάτων στην προηγούμενη έκδοση. Ο Jurczko χρησιμοποίησε συσχέτιση Pearson για να εξετάσει τη στατιστική σημαντικότητα. Τα αποτελέσματα ήταν μεικτά. Ο Jureczko έδειξε ότι υπάρχουν μετρικές που μπορούν να συσχετιστούν με την ύπαρξη λαθών, όπως φαίνεται στην παρακάτω εικόνα. Ταυτόχρονα επισήμανε ότι η μέθοδος της Λογιστικής Παλινδρόμησης δεν είναι κατά την άποψή του η καλύτερη δυνατή μέθοδος ανίχνευσης χρησιμότητας μετρικών. 70

71 Εικόνα 20 Αποτελέσματα Jureczko [61] Raed Shatnawi et al Οι Raed Shatnawi και Wei Li [62] στην έρευνά τους υποστηρίζουν ότι υπάρχουν αρκετές μελέτες που προσπαθούν να εντοπίσουν τα σφάλματα κατά τη διάρκεια της ανάπτυξης του λογισμικού, ταυτόχρονα θέτουν το ερώτημα αν οι μετρικές που χρησιμοποιούνται για την πρόβλεψη είναι ικανές να προβλέψουν πιθανά σφάλματα κώδικα αφού αυτός βγει στην παραγωγή. Η δουλειά τους μελετάει το έργο Eclipse και συμπεραίνει ότι παρότι οι μετρικές μπορούν να προβλέψουν τα σφάλματα η ακρίβεια της πρόβλεψης μειώνεται καθώς οι κυκλοφορίες του λογισμικού εξελίσσονται στο χρόνο. Το τελικό συμπέρασμα είναι ότι δεν μπορεί να φτιαχτεί ένα μοντέλο με ικανοποιητική ακρίβεια που να πραγματοποιεί το ζητούμενο Foutse Khomh et al Οι Foutse Khomh [63] και άλλοι μελέτησαν την ύπαρξη κακών πρακτικών anti-patterns στον κώδικα και κατά πόσο αυτό συσχετίζεται με την εμφάνιση λαθών. Τα anti-patterns αποτελούν ένα είδος μετρικής και αυτά που εξετάζουν οι συγγραφείς στο άρθρο τους είναι τα anti-singleton, Blob, Class Data Should Be Private, Complex Class, Large Class, Lazy Class, Long Method, Long Parameter List, Message Chain, Reduced Parent Request, Spaghetti Code, SG, Swiss Army Knife. 71

72 Τα ερωτήματα της έρευνας είναι: Ποια είναι η σχέση μεταξύ της ύπαρξης anti-patterns και πιθανότητα μελλοντικής αλλαγής στον κώδικα. 2. Ποια είναι σχέση μεταξύ συγκεκριμένων anti-pattern και πιθανότητας μελλοντικής αλλαγής στον κώδικα. 3. Ποια είναι η σχέση μεταξύ της ύπαρξης anti-patterns και πιθανότητας εμφάνισης λάθους στον κώδικα. 4. Ποια είναι σχέση μεταξύ συγκεκριμένων anti-pattern και πιθανότητα εμφάνισης λάθους στον κώδικα. 5. Αν η ύπαρξη των anti-pattern σχετίζεται με το μέγεθος των κλάσεων. 6. Τι τύπου αλλαγές γίνονται στις κλάσεις που έχουν anti-patterns και τι αλλαγές γίνονται σε αυτές που δεν συμμετέχουν Οι εξαρτημένες μεταβλητές για τα ερωτήματα ένα και δύο ήταν αν μία κλάση μεταξύ κυκλοφοριών έχει υποπέσει σε τουλάχιστον μία αλλαγή. Το ίδιο ισχύει και τα ερωτήματα τρία και τέσσερα αλλά αφορά το αν μία κλάση έχει εμφανίσει σφάλμα. Για το ερώτημα πέντε, ως μεταβλητή χρησιμοποιείται η μετρική LOC και για το ερώτημα έξι μετρούνται οι δομικές και μη δομικές αλλαγές που συμβαίνουν σε κλάσεις που έχουν κάποιο anti-pattern και σε κλάσεις που δεν έχουν anti-pattern. Για την ανάλυση των ερωτημάτων ένα και τρία χρησιμοποιείται η μέθοδος Fischer Exact Test καθώς και η μέθοδος odds ration που υπολογίζεται ως: OR = p/(1 p) q(1 q) Όπου p είναι η πιθανότητα ενός γεγονότος να συμβαίνει σε ένα δείγμα και q η πιθανότητα να συμβαίνει σε άλλο δείγμα. Πχ p θα μπορούσε να είναι η πιθανότητα ενός συνόλου από κλάσεις να συμμετέχουν σε anti-pattern και q θα ήταν η πιθανότητα να μη συμμετέχουν. Τιμές κοντά στο 1 δείχνουν ότι η αλλαγή ή η ύπαρξη σφάλματος είναι ισοπίθανα και στα δύο δείγματα. Τιμές μεγαλύτερες του 1 δίνουν μεγαλύτερες πιθανότητες να συμβαίνει η πιθανότητα p και μικρότερες του 1 η q. Για τα ερωτήματα δύο και τέσσερα χρησιμοποιείται Λογιστική Παλινδρόμηση.

73 Για το ερώτημα πέντε χρησιμοποιείται ένας συνδυασμός του Mann-Whitney test, Fischer Exact Test, Cohen d καθώς και της μεθόδου Odds Ratio που αναφέραμε παραπάνω. Τέλος στο έκτος ερώτημα χρησιμοποιείται πάλι Fischer Exact Test. Τα αποτελέσματα της έρευνας έδειξαν ότι όσον αφορά τα ερωτήματα ένα έως τέσσερα, οι κλάσεις που συμμετέχουν σε anti-patterns είναι πολύ πιο πιθανό να αλλάξουν ή να παρουσιάσουν σφάλματα. Επίσης απαντώντας στο ερώτημα πέντε φάνηκε ότι δεν υπάρχει κάποια συσχέτιση του μεγέθους της κλάσης με τη συμμετοχή της σε anti-patterns και τέλος για το ερώτημα έξι παρατηρείται ότι δομικές αλλαγές είναι πιο πιθανό να υπάρξουν σε κλάσεις που έχουν antipatterns κάτι το οποίο βέβαια ισχύει μόνο για τα μισά έργα που εξετάστηκαν Fehmi Jaafar et al Οι Fehmi Jaafar [64] μελέτησαν και αυτοί τα anti-patterns και τη σχέση του με σφάλματα και έθεσαν τα παρακάτω ερωτήματα: Αν οι κλάσεις που έχουν σχέσεις με κλάσεις που έχουν anti-patterns είναι πιο πιθανό να εμφανίσουν λάθη Αν κλάσεις που αλλάζουν μαζί με κλάσεις που έχουν anti-patterns είναι πιο πιθανό να εμφανίσουν λάθη Αν οι κλάσεις που έχουν σχέσεις με κλάσεις που ανήκουν σε κάποιο μοτίβο σχεδίασης είναι πιο πιθανό να εμφανίσουν λάθη Αν κλάσεις που αλλάζουν μαζί με κλάσεις που ανήκουν σε κάποιο μοτίβο σχεδίασης είναι πιο πιθανό να εμφανίσουν λάθη Χρησιμοποιείται το πρόγραμμα DÉCOR για τον εντοπισμό των anti-patterns και το πρόγραμμα Macocha για την εξαγωγή πληροφορίας από τα αποθετήρια κώδικα (CVN/SVN). Χρησιμοποιήθηκε ακόμη και ο Bugzilla των υπό εξέταση έργων για την εξαγωγή της πληροφορίας σχετικά με την ύπαρξη ή μη λαθών. Χρησιμοποιείται και εδώ Fisher Exact Test και odds ratio και οι συγγραφείς καταλήγουν στα εξής αποτελέσματα: οι κλάσεις που έχουν σχέσεις με κλάσεις που έχουν anti-patterns είναι πιο πιθανό να εμφανίσουν λάθη 73

74 οι κλάσεις που αλλάζουν μαζί με κλάσεις που έχουν anti-patterns είναι πιο πιθανό να εμφανίσουν λάθη οι κλάσεις που έχουν σχέσεις με κλάσεις που ανήκουν σε κάποιο μοτίβο σχεδίασης δεν είναι πιο πιθανό να εμφανίσουν λάθη οι κλάσεις που αλλάζουν μαζί με κλάσεις που ανήκουν σε κάποιο μοτίβο σχεδίασης είναι πιο πιθανό να εμφανίσουν λάθη Seyyed Ehsan Salamati Taba et al Οι Seyyed Ehsan, Salamati Taba [65] και άλλοι μελέτησαν τη σχέση anti-patterns με την ύπαρξη λαθών και όρισαν κάποιες μετρικές. Οι μετρικές που όρισαν ήταν: η ANA (Average Number of Anti-patterns) που ορίζεται ως ο μέσος όρος των anti-patterns ανά αρχείο κώδικα. Τη μετρική ACM (Anti-pattern Complexity Metric) που ορίζεται ως η πολυπλοκότητα των αλλαγών που συμβαίνουν στα αρχεία κώδικα. Τη μετρική ARL (Anti-pattern Recurrence Length) που μετράει το για πόσες κυκλοφορίες το εκάστοτε anti-pattern διατηρήθηκε Τη μετρική ACPD (Anti-pattern Cumulative Pairwise Differences) που μετράει τη τάση να αυξάνονται τα anti-patterns σε ένα αρχείο κώδικα με το χρόνο. Χρησιμοποιείται το πρόγραμμα DÉCOR για τον εντοπισμό των anti-patterns και ένα φτιαγμένο από τους ερευνητές πρόγραμμα για την εξαγωγή πληροφορίας από τα αποθετήρια κώδικα (CVN/SVN) σε συνδυασμό με το σύστημα αναφοράς σφαλμάτων Bugzilla των υπό εξέταση έργων. Η ροή της πληροφορίας φαίνεται στη παρακάτω εικόνα: Εικόνα 21 Ροή πληροφορίας Seyyed Ehsan Salamati Taba et al [65] 74

75 Τα ερωτήματα που τέθηκαν ήταν: Αν η ύπαρξη anti-patterns επηρεάζει την πυκνότητα των σφαλμάτων στα αρχεία κώδικα. Αν οι μετρικές που προτείνουν, εξηγούν αναλυτικότερα το γιατί υπάρχουν λάθη σε σχέση με τις παραδοσιακές μετρικές. Αν μπορεί η πληροφορία για τα anti-patterns να συνδυαστεί με παραδοσιακές μετρικές για ακριβέστερη δυνατότητα πρόβλεψης των πιθανών σφαλμάτων. Τα αποτελέσματα όσον αφορά το πρώτο ερώτημα είναι ότι πράγματι, η ύπαρξη anti-patterns επηρεάζει την πυκνότητα των σφαλμάτων στα αρχεία κώδικα, όσον αφορά το δεύτερο ερώτημα βρέθηκε ότι μεταξύ των μετρικών ANA, ACM, ARL και ACPD που προτάθηκαν η ARL είχε τα καλυτέρα αποτελέσματα από τις παραδοσιακές μετρικές και τέλος για το τρίτο ερώτημα προκύπτει η ARL σε συνδυασμό με κάποιες από τις παραδοσιακές μετρικές αποδίδει μία καλή εικόνα για την πιθανή ύπαρξη σφαλμάτων Cristina Marinescu et al Οι Cristina Marinescu και Mihai Codoban [66] αφού όρισαν μία τη μετρική USED_DIT_MAX ως το πόσες φορές μία κλάση είναι πελάτης μία άλλης κλάσης που ανήκει σε μία ιεραρχία όπως χαρακτηριστικά φαίνεται στην παρακάτω εικόνα: Εικόνα 22 Cristina Marinescu και Mihai Codoban ορισμός κλάσης πελάτη [66] Η συλλογή δεδομένων έγινε με το λογισμικό iproblems και η ανάλυσή τους με το iplasma. Χρησιμοποιήθηκαν τα project ArgoUML, DrJava, FindBugs, FOP, FreeCol, JFreeChart και 75

76 JMeter στα οποία έγινε ανάλυση του κώδικα που βρίσκεται σε CVN/SVN και εύρεση/παρακολούθηση των σφαλμάτων από τις αντίστοιχες για το κάθε project εγκαταστάσεις του Bugzilla. Τα ερωτήματα που τέθηκαν ήταν τα παρακάτω: Αν οι κλάσεις με μεγάλο USED_DIT_MAX είναι πιο πιθανό να υποστούν αλλαγές σε σχέση με αυτές με μικρότερο USED_DIT_MAX Αν οι κλάσεις με μεγάλο USED_DIT_MAX είναι πιο πιθανό να εμφανίσουν σφάλματα σε σχέση με αυτές με μικρότερο USED_DIT_MAX Χρησιμοποιήθηκε το Chi-Square Test για να εξεταστεί η συσχέτιση μεταξύ USED_DIT_MAX και αλλαγών και σφαλμάτων, καθώς και το Odds Ratio για το δεύτερο ερώτημα. Όσον αφορά τα αποτελέσματα για το πρώτο ερώτημα προέκυψε ότι υπήρχε στατιστική σημαντικότητα μεταξύ της μετρικής και των αλλαγών και όσο μεγαλύτερη ήταν η τιμή της μετρικής τόσο αυξάνεται η πιθανότητα αλλαγής. Σχετικά με το δεύτερο ερώτημα προκύπτουν αντίστοιχα αποτελέσματα Śliwerski, Jacek et al Oι Śliwerski Jacek και άλλοι [50] προσπάθησαν να βρουν μοτίβα που προκαλούν λάθη στο λογισμικό (πέραν των μετρικών), μελέτησαν με διεξοδικό τρόπο δύο μεγάλα έργα ανοιχτού λογισμικού (Eclipse, Mozilla) και κατέληξαν σε ενδιαφέροντα συμπεράσματα όπως: Τα αρχεία που αλλάζουν στις καταχωρήσεις του αποθετηρίου (commits) είναι κατά περίπου τρεις φορές περισσότερα μετά την εύρεση κάποιου σφάλματος, σε σχέση με τις καταχωρήσεις που δεν αφορούν σφάλμα Η μέρα όπου κάποια αλλαγή στον κώδικα είναι πιο πιθανό να επιφέρει κάποιο σφάλμα είναι η Παρασκευή για το Eclipse και η Κυριακή για το Mozilla, όπως φαίνεται στις παρακάτω εικόνες: 76

77 Εικόνα 23 Αποτελέσματα Śliwerski [50] 4.3 Μετρικές κληρονομικότητας και συσχέτιση με λάθη Η μελέτη της συσχέτισης διαφόρων μετρικών με σφάλματα είναι μία διαδικασία που είναι συχνά αντικείμενο μελέτης. Στη βιβλιογραφία όπως γίνεται εμφανές και από την παράγραφο 4.2 μελετάται το κατά πόσο και ποιες μετρικές σχετίζονται με την παρουσία ή την πιθανότητα εμφάνισης σφαλμάτων. Γίνεται ακόμη εμφανές, το πως η μελέτη για τον τρόπο που η κληρονομικότητα επηρεάζει την εμφάνιση λαθών δεν είναι ένα αντικείμενο που εμφανίζεται συχνά στη βιβλιογραφία, τουλάχιστον όχι τόσο συχνά όσο θα περίμενε κανείς. Ακόμη οι μετρικές που έχουν μελετηθεί κατά κόρον όπως η μετρική DIT στις εμπειρικές μελέτες παρουσιάζουν καθόλου ή αδύναμη συσχέτιση [51] [55]. Αντικείμενο της παρούσας μελέτης είναι να εξετάσει αυτή τη συσχέτιση μεταξύ κληρονομικότητας και εμφάνισης λαθών. Συγκεκριμένα θα εξετάσει το πως χαρακτηριστικά που επιτρέπει η κληρονομικότητα όπως η αντικατάσταση μεθόδων με υλοποίηση από κλάσεις που 77

78 κληρονομούν - επαναορισμός υλοποίησης - είναι μία συνθήκη που αυξάνει την εμφάνιση σφαλμάτων στη διάρκεια ζωής ενός έργου. Αφορμή για το ερώτημα αυτό προκύπτει από το γεγονός ότι ο επαναορισμός υλοποίησης μπορεί να δημιουργήσει μία υποψία για πιθανή εμφάνιση λαθών [49]. Η υποψία αυτή προκύπτει από το γεγονός ότι ο επαναορισμός υλοποίησης παραβιάζει την Αρχή Υποκατάστασης της Liskov που έγινε γνωστή από τον Robert Martin [67] [68]. Η αρχή αυτή αναφέρει ότι οι υποτύποι πρέπει να μπορούν να αποτελούν αντικαταστάτες των υπερτύπων. Αν λοιπόν μία κλάση υποτύπος αντικαθιστά μία υλοποίηση μίας συνάρτησης της υπερκλάσης, τότε αυξάνεται η πιθανότητα χρησιμοποιώντας κάπου την υποκλάση να αλλάξουμε την αναμενόμενη συμπεριφορά του συστήματος. Ο επαναορισμός υλοποίησης λοιπόν αποτελεί συνήθως μία κακή πρακτική. Σκοπός της παρούσας εργασίας είναι να εξετάσει κατά πόσο αυτή η πρακτική επηρεάζει την εμφάνιση λαθών στον κώδικα. Στο επόμενο κεφάλαιο αρχικά θα οριστεί μία νέα μετρική που θα χαρακτηρίζει την ύπαρξη επαναορισμού υλοποιήσεων στις κλάσεις. Στη συνέχεια θα περιγραφεί η διαδικασία συλλογής δεδομένων καθώς και η προσπάθεια συσχέτισης με στατιστικά μοντέλα της ύπαρξης λαθών με την ύπαρξη επαναορισμού υλοποίησης στις κλάσεις του συστήματος. 78

79 5 Κληρονομικότητα, επαναορισμοί μεθόδων και σφάλματα λογισμικού Αυτό το κεφάλαιο αποτελεί την αναλυτική περιγραφή της προσπάθειας εντοπισμού για το πρόβλημα που περιγράφηκε στην ενότητα 4.3. Αρχικά θα γίνει μία περιγραφή της νέας μετρικής που σκοπό έχει να αντικατοπτρίσει την έκταση του φαινομένου των επαναορισμών υλοποίησης στα μονοπάτια κληρονομικότητας του συστήματος. Σε αντίθεση με τις παραδοσιακές προσεγγίσεις, όπου οι μετρικές εκτιμούν τη χρήση κληρονομικότητας μεμονωμένων κλάσεων, η προτεινόμενη μετρική αξιολογεί τη χρήση του επαναορισμού υλοποίησης σε σύνολα κλάσεων. Συγκεκριμένα, εστιάζει σε κλάσεις που ανήκουν σε μονοπάτια από τη ρίζα ως τα φύλλα ενός μονοπατιού κληρονομικότητας, τα οποία αναφέρονται ως μονοπάτια κληρονομικότητας (Inheritance Paths). Το πλήθος των μονοπατιών κληρονομικότητας ισούται με το πλήθος των concrete κλάσεων που αποτελούν φύλλα του μονοπατιού. Στη συνέχεια θα γίνει περιγραφή του συστήματος συλλογής και επεξεργασίας των δεδομένων καθώς και επισκόπηση όλης της διαδικασίας συλλογής. Τέλος θα αναλυθούν οι μέθοδοι στατιστικής ανάλυσης που χρησιμοποιήθηκαν και θα ακολουθήσουν τα συμπεράσματα. 5.1 Μετρική επαναορισμού υλοποίησης σε μονοπάτια κληρονομικότητας Για να μελετηθεί το γεγονός αν ο αριθμός των επαναορισμών υλοποίησης επηρεάζουν το αριθμό των σφαλμάτων στο λογισμικό δημιουργήθηκε μία νέα μετρική. Η μετρική ονομάζεται concrete overrides metric (COM) και αναπαριστά χαρακτηριστικά των μονοπατιών κληρονομικότητας του συστήματος. Ακόμη λαμβάνει υπόψιν το σύνολο των επαναορισμών υλοποίησης σε όλες τις κλάσεις ενός μονοπατιού κληρονομικότητας. Ως μονοπάτι κληρονομικότητας ορίζεται η αλυσίδα των κλάσεων του συστήματος που συνδέονται με σχέση κληρονομικότητας. Στην java λόγω της απουσίας πολλαπλής κληρονομικότητας σε επίπεδο κλάσεων ο υπολογισμός των μονοπατιών κληρονομικότητας είναι αρκετά εύκολος, αρκεί να βρεθεί η κλάση που η κάθε κλάση επεκτείνει (extend), και αν αυτή ανήκει μέσα στο σύστημα να συμπεριλαμβάνεται στο μονοπάτι. Δεδομένων των μονοπατιών για κάθε μία από αυτές ορίζονται τα εξής: Συνολικός αριθμός επαναορισμών υλοποίησης: είναι ο αριθμός των επαναορισμών υλοποίησης που υπάρχουν σε ένα μονοπάτι κληρονομικότητας. Κάθε φορά που μία μέθοδος μία κλάσης που έχει υλοποίηση αντικαθίσταται από μία άλλη υλοποίηση μίας υποκλάσης τότε έχουμε ένα επαναορισμό υλοποίησης. Το σύνολο των επαναορισμών 79

80 υλοποίησης που παρατηρούνται σε ένα μονοπάτι κληρονομικότητας είναι ο αριθμός των επαναορισμών υλοποίησης του μονοπατιού. Μέγιστος δυνατός αριθμός επαναορισμών υλοποίησης: είναι ο αριθμός των επαναορισμών που δύναται να έχει ένα μονοπάτι κληρονομικότητας. Η μετρική αυτή υπολογίζεται ξεκινώντας από την υπερκλάση κάθε μονοπατιού και υπολογίζοντας πόσες μεθόδους από το μονοπάτι θα μπορούσε να επαναορίσει η κάθε υποκλάση. Δηλαδή, είναι ίση με όλες τις μεθόδους που δεν είναι επαναορισμένες από όλες τις κλάσεις που βρίσκονται πάνω από την κλάση που εξετάζεται. Το άθροισμα των περιπτώσεων μας δίνει το δυνατό αριθμό επαναορισμών για ένα μονοπάτι. Για παράδειγμα σε ένα μονοπάτι κληρονομικότητας τριών κλάσεων με την υποκλάση να έχει τέσσερις μεθόδους και τις άλλες δύο κλάσεις του μονοπατιού από δύο μεθόδους που δεν είναι επαναορισμοί τότε ο αριθμός θα είναι 4+2=6. Αν η μεσαία κλάση αντί για δύο δικές της μεθόδους επαναόριζε και μία δική της μέθοδο τότε ο αριθμός θα ήταν πέντε. Αφού ορίστηκαν τα δύο μεγέθη ορίζεται η μετρική CΟΜ ως: COM = concrete overrides max possible overrides Να σημειωθεί ότι στα μονοπάτια κληρονομικότητας με μήκος ένα η τιμή της μετρικής ορίζεται να είναι Περιγραφή της διαδικασίας συλλογής δεδομένων Για τη συλλογή δεδομένων δημιουργήθηκε λογισμικό γραμμένο σε java. Περιληπτικά το λογισμικό εξετάζει αποθετήρια svn και αναλύει τα σχόλια της κάθε καταχώρησης. Από το σχόλιο εξάγεται η πληροφορία σχετικά με το αν η εξεταζόμενη καταχώρηση αφορά κάποια αναφορά σφάλματος. Στη συνέχεια εξετάζονται οι κυκλοφορίες του συστήματος μέσω της εξέτασης των jars της κάθε έκδοσης. Από τα jars προκύπτουν τα μονοπάτια κληρονομικότητας των κλάσεων. Επίσης υπολογίζονται οι μετρικές που προτάθηκαν για κάθε μονοπάτι κληρονομικότητας. Το τελικό βήμα είναι η συσχέτιση των δεδομένων από τα τις καταχωρήσεις του αποθετηρίου (commits) με αυτά των κυκλοφοριών. Όλα τα δεδομένα αποθηκεύονται σε μία H2 βάση, μιας και δεν υπήρχε απαίτηση για κάτι πιο εξελιγμένο. Ο κώδικας χρησιμοποιεί JPA για το επίπεδο των δεδομένων κάτι που σημαίνει ότι η βάση αλλάζει με ευκολία. 80

81 5.2.1 Συλλογή Σχολίων από αποθετήρια κώδικα (SVN) Η συλλογή δεδομένων ξεκινάει με τη συλλογή δεδομένων από ένα svn repository. Το Apache Subversion (SVN) είναι ένα αποθετήριο του οποίο η δουλειά του είναι να αποθηκεύει και να διαχωρίζει τις κυκλοφορίες του κώδικα ενός λογισμικού, μαζί με πληροφορίες σχετικά με αυτές. Κάθε έκδοση που καταχωρείται ονομάζεται καταχώρηση (commit). Η καταχώρηση περιέχει πληροφορίες σχετικά με τις αλλαγές που έγιναν στον κώδικα από την προηγούμενη καταχώρηση καθώς και άλλα μεταδεδομένα metadata. Συγκεκριμένα περιέχει πληροφορίες σχετικά με τα ονόματα των αρχείων που άλλαξαν, ποιος έκανε την αλλαγή, την ημερομηνία που έγινε η αλλαγή, τον αύξοντα αριθμό που συνοδεύει τη κάθε καταχώρηση καθώς και ένα σχόλιο. Εικόνα 24 Δέντρο SVN [69] Η κύρια ροή του SVN χρησιμοποιεί το λεγόμενο Trunk branch που περιέχει την κύρια δομή των αλλαγών. Υπάρχει ακόμα η δυνατότητα διακλάδωσης από αυτή τη κύρια ροή με τα λεγόμενα 81

82 κλαδιά (Branches). Ένα κλαδί αποτελεί μία μετάβαση από τη κύριας ροή η οποία αν είναι επιτυχημένη ενσωματώνεται (Merge) στην κύρια ροή. Ακόμη υπάρχουν τα λεγόμενα tags που αποτελούν στιγμιότυπα της κεντρικής ροής και συνηθίζεται να σηματοδοτούν κυκλοφορίες του λογισμικού (releases). Μία αναπαράσταση των ροών φαίνεται στο παρακάτω σχήμα: Εικόνα 25 Ροές στο SVN [69] Η συλλογή των σχολίων που έχουν υποβληθεί σε κάθε καταχώρηση γίνεται με τη βιβλιοθήκη svnkit [70]. Χρησιμοποιείται το trunk branch του SVN αποθετηρίου. Με το svnkit δίνεται πρόσβαση στις κλάσεις που συμμετείχαν στη καταχώρηση καθώς και metadata για την κάθε καταχώρηση (αριθμός - revision, ημερομηνία, όνομα χρήστη που έκανε την καταχώρηση) αλλά και το σχόλιο της κάθε καταχώρησης Εύρεση Λαθών από μηνύματα καταχωρήσεων Στόχος από την επεξεργασία της κύριας ροής του SVN είναι να εξαχθεί η πληροφορία σχετικά με το αν η εκάστοτε καταχώρηση αναφέρεται στη διόρθωση κάποιου σφάλματος που παρατηρήθηκε στο λογισμικό. Για αυτό το σκοπό εξετάζονται διαδοχικά όλες οι καταχωρήσεις της κύριας ροής. Ο μόνος τρόπος για να εξαχθεί μία τέτοια πληροφορία για τη καταχώρηση είναι μέσω της έξυπνης επεξεργασίας του σχολίου (comment) που συνοδεύει την κάθε καταχώρηση. Η κάθε καταχώρηση συνήθως περιέχει πληροφορία που είτε αφορά τη διόρθωση κάποιου σφάλματος είτε την ανάπτυξη καινούργιων λειτουργιών στο πρόγραμμα. Στη συγκεκριμένη υλοποίηση χρησιμοποιούνται δύο τρόποι για να βρεθεί αν η καταχώρηση αφορά τη διόρθωση κάποιου σφάλματος. Ο πρώτος τρόπος είναι ο έλεγχος για το αν το σχόλιο που εξετάζεται περιέχει κάποιο σύνδεσμο για το σύστημα αναφοράς σφαλμάτων Bugzilla. Το σύστημα αναφοράς σφαλμάτων είναι ένα πρόγραμμα όπου οι χρήστες του προγράμματος αναφέρουν σφάλματα σχετικά με αυτό. Αν λοιπόν 82

83 στα σχόλια της καταχώρησης υπάρχει κάποιος σύνδεσμος για το σύστημα αναφοράς σφαλμάτων τότε θεωρείται ότι σε εκείνη την καταχώρηση έγινε μερική ή ολική διόρθωση του σφάλματος αυτού. Είναι εύκολο κάποιος να εντοπίσει ένα τέτοιο σύνδεσμο μέσα στο σχόλιο μιας και ο κεντρικός σύνδεσμος προς το σύστημα αναφοράς είναι διαθέσιμος και αποκλειστικός για το κάθε έργο. Αν το σχόλιο σε κάποιο σημείο του περιέχει τον αρχικό (root) σύνδεσμο του συστήματος αναφοράς σφαλμάτων τότε θεωρείται ότι αποτελεί επιδιόρθωση. Ο δεύτερος τρόπος που χρησιμοποιείται βασίζεται στη συντακτική ανάλυση του μηνύματος. Η διαδικασία αυτή τεκμηριώνεται και περιγράφεται στο άρθρο των Sliwerski, Zimmermann και Zeller [50]. Αναλυτικά η ανάλυση βασίζεται στον εντοπισμό συγκεκριμένων προτύπων στο κείμενο ενός μηνύματος: Αριθμός Σφάλματος (bug number), ακολουθώντας ένα από τα regular expression : o bug[# \t]*[0-9]+ o pr[# \t]*[0-9]+ o show\_bug\.cgi\?id=[0-9]+ o \[[0-9]+\] Ένας αριθμός με regular expression [0-9]+ Λέξη κλειδί αν ακολουθεί τα ακόλουθα regular expressions: fix(e[ds])? bugs? defects? patch Απλή λέξη αν είναι ένα String με αλφαριθμητικούς χαρακτήρες Ξεκινώντας από βαθμολογία 0 αν στο σχόλιο της καταχώρησης βρεθούν λέξεις κλειδιά ή αριθμός σφάλματος τότε του απονέμεται ένας πόντος για το καθένα. Άρα η συντακτική βαθμολογία είναι ένας αριθμός που ανήκει στο σύνολο [0, 2]. Παραδείγματα: Fixed bug 53784:.class file missing from jar file export: Παίρνει βαθμολογία , 51529: παίρνει βαθμολογία 1 Updated copyrights to 2004: παίρνει βαθμολογία 0 Το άρθρο προτείνει και σημασιολογική ανάλυση των σχολίων αλλά μιας και τα σχόλια στα project που μελετώνται (Apache) έχουν συνδέσμους προς το αντίστοιχο σύστημα αναφοράς σφαλμάτων και όχι απλά αριθμούς σφαλμάτων η περίπτωση αυτή δεν μας αφορά. Επίσης κάποια από τα έργα δεν υποστηρίζονται από σύστημα αναφοράς σφαλμάτων οπότε σε αυτή την περίπτωση έγινε 83

84 αναγκαία η απαίτηση το σχόλιο της καταχώρησης να έχει βαθμολογία δύο για να θεωρηθεί σφάλμα. Αν λοιπόν ένα σχόλιο καλύπτει μία από τις δυο προϋποθέσεις τότε η αντίστοιχη καταχώρηση θεωρείται ότι αναφέρεται σε διόρθωση ενός σφάλματος Συλλογή και επεξεργασία SVN Tags Τα tags αφορούν τις κυκλοφορίες και η εξαγωγή τους από το αποθετήριο γίνεται και αυτή με το svnkit. Το κάθε tag περιέχει πληροφορία σχετικά με το όνομα του tag και τον αριθμό έκδοσης (revision) της καταχώρησης. Με αυτή τη διαδικασία δημιουργείται η πληροφορία που συνδέει τις κυκλοφορίες του λογισμικού που θα μελετηθούν και του αριθμού καταχώρησης (revision number) που υπάρχει στη ροή του αποθετηρίου. Στη συνέχεια γίνεται χειροκίνητο κατέβασμα των κυκλοφοριών του υπό εξέταση προγράμματος (jars). Υπάρχει πιθανότητα να μην υπάρχει ένα προς ένα αντιστοιχία μεταξύ των tags και των διαθέσιμων προς κατέβασμα κυκλοφοριών μιας και δύναται κάποιες κυκλοφορίες να μην είναι διαθέσιμες για κατέβασμα από το αρχείο. Συνήθως είναι διαθέσιμο ένα μεγάλο μέρος τους. Στην περίπτωση όπου η έκδοση αποτελείται από περισσότερα από ένα αρχεία (jars) τότε αυτά αντιμετωπίζονται ως ένα Ανάλυση jars και εξαγωγή πληροφοριών των κλάσεων Κάθε έκδοση αναλύεται με τη βοήθεια του apache bcel [71]. Το bcel δίνει τη δυνατότητα να γίνει ανάλυση του bytecode της java που υπάρχει σε κάθε release και να εξαχθούν οι κλάσεις και οι πληροφορίες σχετικά με αυτές όπως είναι οι μέθοδοί, οι κλάσεις που κληρονομούν κτλ. Όλες οι κλάσεις συλλέγονται σε μία δομή key-value pair (Map <classname, δομή του bcel για την κλάση>) και πάνω σε αυτή τη δομή γίνεται η ανάλυση των δεδομένων Εξαγωγή μονοπατιών κληρονομικότητας Χρησιμοποιώντας μία δομή δέντρου με ρίζα τον κόμβο root και κόμβους-κλαδιά που έχουν σαν χαρακτηριστικό το όνομα της κλάσης, δημιουργούνται τα μονοπάτια κληρονομικότητας των κλάσεων. Συνοπτικά η διαδικασία εξελίσσεται ακολουθώντας τα παρακάτω βήματα: 84

85 1. Για κάθε εισερχόμενη κλάση βρες αν κληρονομεί από κάποια κλάση 2. Αν ναι βρες αν υπάρχει ο πατέρας και τοποθέτησε την κλάση σαν κλαδί του πατέρα 3. Αν δεν υπάρχει ο πατέρας μην εκτελέσεις κάποια ενέργεια 4. Αν η κλάση δεν κληρονομεί από κάποια κλάση τότε τοποθετείται κάτω από τη ρίζα του δέντρου 5. Επανέλαβε τα βήματα 1-5 μέχρις ότου όλες οι κλάσεις έχουν τοποθετηθεί σαν κόμβοι στο δέντρο Η διαδικασία αυτή παράγει τα μονοπάτια κληρονομικότητας βασιζόμενη στο γεγονός ότι στην java δεν υπάρχει πολλαπλή κληρονομικότητα και με αυτόν τον τρόπο κάθε κόμβος του δέντρου έχει το πολύ ένα πατέρα. Με αυτό τον τρόπο δημιουργούνται τα μονοπάτια κληρονομικότητας των κλάσεων και στη συνέχεια αποθηκεύονται. Κατά τη διάρκεια της αποθήκευσης γίνεται και ο υπολογισμός των μετρικών για τους μέγιστους πιθανούς επαναορισμούς μεθόδων και τους επαναορισμούς του κάθε μονοπατιού που τελικά πραγματοποιούνται. Για το μέγιστο αριθμό επαναορισμών υλοποίησης χρησιμοποιείται ο κώδικας: private int calculatedistinctmethodnumberforhieararchy(list<jclass> hieararchy_classes){ return hieararchy_classes.stream().map(jclass->jclass.getmethods()).flatmap(methodlist->methodlist.stream()).filter(method ->!method.isabstract()).filter(method ->!method.isprivate()).filter(method ->!method.isfinal()).filter(method ->!method.getname().equalsignorecase("tostring")).filter(method ->!method.getname().equalsignorecase("equals")).filter(method ->!method.getname().equalsignorecase("hashcode")).map(method-> method.getname() + "&&" + method.getsignature()).collect(collectors.toset()).size(); } private int findmaxpossibleoverridesinternal(list<jclass> hierarchy_classes){ int count = 0; for (int i=1; i<hierarchy_classes.size(); i++){ count += calculatedistinctmethodnumberforhieararchy(hierarchy_classes.sublist(0, i)); } return count; } Ο παραπάνω κώδικας (findmaxpossibleoverridesinternal) για κάθε κλάση του μονοπατιού κληρονομικότητας υπολογίζει το σύνολο των μοναδικών μεθόδων που εμφανίζονται στις κλάσεις που αυτό κληρονομεί. Η διαδικασία αυτή γίνεται για κάθε στάδιο του μονοπατιού και στο τέλος 85

86 κάθε βήματος ο αριθμός που υπολογίζεται αποτελεί το συνολικό αριθμό των μεθόδων που μπορούν να επαναοριστούν. Για τους επαναορισμούς χρησιμοποιείται ο κώδικας: private int findoverridesinternal(list<jclass> hierarchy_classes){ Map<String, Long> map = hierarchy_classes.stream().map(jclass -> jclass.getmethods()).flatmap(methods -> methods.stream()).filter(method ->!method.isabstract()).filter(method ->!method.isprivate()).filter(method ->!method.isfinal()).filter(method ->!method.getname().equalsignorecase("tostring")).filter(method ->!method.getname().equalsignorecase("equals")).filter(method ->!method.getname().equalsignorecase("hashcode")).collect(collectors.groupingby(method-> method.getname() + "&&" + method.getsignature(), Collectors.counting())); } return map.values().stream().filter(val -> val > 1).map(val -> val - 1).collect(Collectors.summingLong(val -> val)).intvalue(); Ο παραπάνω κώδικας υπολογίζει για το σύνολο του μονοπατιού κληρονομικότητας πόσες φορές συναντώνται παραπάνω από μία φορά μέθοδοι, στις κλάσεις του μονοπατιού, που έχουν την ίδια υπογραφή. Η μετρική των μέγιστων πιθανών επαναορισμών (max possible overrides) αναπαριστά πόσες φορές δύναται μία μέθοδος να επαναοριστεί σε κάποια από τα μέλη του μονοπατιού. Η μετρική του αριθμού των επαναορισμών υλοποίησης (actual overrides) αναπαριστά πόσοι επαναορισμοί συμβαίνουν στην πράξη. Όπως φαίνεται και από τα παραπάνω κομμάτια κώδικα από τον υπολογισμό εξαιρούνται οι abstract, private και final μέθοδοι μιας και δεν μπορούν να αποτελέσουν επαναορισμούς υλοποίησης και οι μέθοδοι tostring, hashcode και equals γιατί δεν επιφέρουν αξία στους υπολογισμούς Συσχέτιση των δεδομένων των jars με τις κλάσεις της καταχώρησης Σε αυτό το στάδιο γίνεται η συσχέτιση μεταξύ των bugs και των χαρακτηριστικών κληρονομικότητας. 86

87 Εικόνα 26 Ιστορικό μεταξύ καταχωρήσεων Γνωρίζοντας τα tags, δηλαδή τις κυκλοφορίες του κώδικα, μπορούν να συσχετιστούν οι καταχωρήσεις που αφορούν σφάλματα με την έκδοση. Όπως φαίνεται στο παραπάνω σχήμα αρκεί για το κάθε tag (εκτός από το τελευταίο) να εντοπιστούν όλες οι καταχωρήσεις που περιέχουν bugs και ξεκινούν από την αρχή του tag μέχρι το επόμενο. Ο λόγος που γίνεται αυτό είναι γιατί το πρόγραμμα εντοπίζει τις διορθώσεις των σφαλμάτων, συνεπώς για να βρεθούν ποιες ήταν οι συνθήκες που οδήγησαν στο bug εξετάζονται τα μονοπάτια κληρονομικότητας της έκδοσης πριν τη διόρθωσή του. Στη συνέχεια πρέπει να εξακριβωθεί το αν οι κλάσεις αυτών των καταχωρήσεων που διορθώνουν σφάλματα είναι ίδιες με κάποια από τις κλάσεις που ανήκουν στα μονοπάτια κληρονομικότητας που έχουν εντοπιστεί σε προηγούμενα βήματα. Για να πραγματοποιηθεί η συσχέτιση αυτή, αρχικά μετριέται το πόσες φορές έχεις βρεθεί μία κλάση να συμμετέχει σε μία καταχώρηση που αφορά κάποιο σφάλμα. Αν η διαδικασία αυτή πραγματοποιηθεί για κάθε καταχώρηση τότε στο τελικό αποτέλεσμα συλλέγεται το σύνολο των κλάσεων που συμμετέχουν σε κάποιο σφάλμα και τον αριθμό των σφαλμάτων που αυτές συμμετέχουν. Όπως φαίνεται και στον κώδικα παρακάτω αυτή η πληροφορία αποθηκεύεται σε μία δομή key-value pair. 87

88 List<LogEntry> logentries = storagewrapper.getlogentryforrangerevision(revisionfrom, revisionto); Map<String, Long> revisionrangeclassnamebugcountmap = logentries.stream().filter(logentry::gethasbug).map(logentry::getclassnames).flatmap(classnamelist->classnamelist.stream()).map(logclassname::getname).collect(collectors.groupingby(function.identity(), Collectors.counting())); Στη συνέχεια εξετάζονται τα μονοπάτια κληρονομικότητας που αφορούν την έκδοση που εξετάζεται, και για κάθε μονοπάτι αν κάποια από της κλάσεις που την απαρτίζουν υπάρχει στη παραπάνω key-value pair δομή, ο αριθμός των λαθών της κλάσης που έχει υπολογιστεί παραπάνω προστίθεται στο σύνολο των σφαλμάτων που αφορούν το μονοπάτι. storagewrapper.getjclasshierarchiesbytag(jtagname).foreach(hierarcy -> { Long numberofhierarachybugs = hierarcy.gethierarchy_classes().stream().map(hierclass -> hierclass.getname()).filter(hierclassname -> revisionrangeclassnamebugcountmap.containskey(hierclassname)).map(hierclassname -> revisionrangeclassnamebugcountmap.get(hierclassname)).reduce(0l, (x0, x1)-> x0+x1); hierarcy.setbugcount(numberofhierarachybugs); Με αυτόν τον τρόπο εξάγεται η πληροφορία σχετικά με πόσα σφάλματα έχει το κάθε μονοπάτι κληρονομικότητας, γεγονός που σε συνδυασμό με τις μετρικές που έχουν υπολογιστεί σε προηγούμενο βήμα επιτρέπει το να εξεταστεί μία πιθανή συσχέτιση μεταξύ των δύο αυτών μεγεθών. Τέλος πρέπει να σημειωθεί ότι στα αποτελέσματα συμπεριελήφθησαν και τα μονοπάτια κληρονομικότητας μήκους ένα δηλαδή απλές κλάσεις σε μία προσπάθεια να υπάρχει πληρέστερη εικόνα στη στατιστική ανάλυση. 5.3 Περιγραφή στατιστικών μεθόδων Αφού τα στοιχεία των λαθών έχουν συσχετιστεί με τα μονοπάτια κληρονομικότητας άρα και με τις μετρικές, ακολουθεί στατιστική ανάλυση των στοιχειών που συλλέχτηκαν. Χρησιμοποιήθηκαν δύο μέθοδοι, η συσχέτιση Pearson και Logistic Regression (Λογιστική Παλινδρόμηση). Η συσχέτιση Pearson έγινε για να εξεταστεί αν υπάρχει γραμμική συσχέτιση μεταξύ ενός ή περισσότερων μεγεθών από τον συνολικό αριθμό των επαναορισμών, το μέγεθος του μονοπατιού και την μετρική CΟΜ με τον αριθμό των λαθών. Ενώ η Λογιστική Παλινδρόμηση έγινε στην προσπάθεια να δούμε αν μπορεί η μετρική του συνόλου των επαναορισμών και του μέγιστου 88

89 αριθμού επαναορισμών να προβλέψουν την ύπαρξη ή όχι λάθους. Τα στατιστικά αποτελέσματα παρήχθησαν με το εργαλείο SPSS της IBM, συγκεκριμένα την έκδοση Συσχέτιση Pearson Συνοπτικά, η συσχέτιση Ο συντελεστής συσχέτισης Pearson r είναι ο κατάλληλος (παραμετρικός) στατιστικός δείκτης προκειμένου να αξιολογηθεί αν υπάρχει συνάφεια μεταξύ δύο μεταβλητών. Οι προϋποθέσεις που πρέπει να καλύπτονται είναι: οι μεταβλητές πρέπει να είναι συνεχείς σε κλίμακα ίσων διαστημάτων και να κατανέμονται κανονικά να υπάρχει γραμμική σχέση μεταξύ των μεγεθών Ορίζεται ως το πηλίκο της διαίρεσης της συν-διακύμανσης των δύο μεταβλητών με το γινόμενο των τυπικών αποκλίσεων και ορίζεται ως: n ρ X,Y = 1 n 1 (X μ X)(Y μ Y ) σ X σ Y i=1 Όπου μ η μέση τιμή του x και του y, σ η τυπική απόκλιση του x και του y και n το μέγεθος του συνόλου. Οι τιμές της συσχέτισης Pearson κυμαίνονται στο διάστημα -1.0 με 1.0 περνώντας και από το 0. Θετικό πρόσημο σημαίνει θετική συσχέτιση δηλαδή οι τιμές μίας μεταβλητής αυξάνονται όσο αυξάνονται οι τιμές της άλλης και αρνητικό πρόσημο σημαίνει το αντίστροφο δηλαδή οι τιμές μίας μεταβλητής μειώνονται όσο αυξάνονται οι τιμές της άλλης [72] [73]. Τιμές στο διάστημα 0.1< r <0.3 θεωρείται αδύναμη συσχέτιση Τιμές στο διάστημα 0.3< r <0.5 θεωρείται μέτρια συσχέτιση Τιμές στο διάστημα 0.5< r <1.0 θεωρείται δυνατή συσχέτιση 89

90 Εικόνα 27 Με σειρά r=-0.9, r=0.0, r= Λογιστική παλινδρόμηση Η παλινδρόμηση είναι μια ευρέως χρησιμοποιούμενη στατιστική τεχνική μοντελοποίησης για την έρευνα της συσχέτισης μεταξύ μίας εξαρτώμενης μεταβλητής και μιας ή περισσότερων ανεξάρτητων κατηγορικών ή/και ποσοτικών μεταβλητών. Χρησιμοποιείται με σκοπό την εκχώρηση δεδομένων σε μία πραγματική μεταβλητή πρόβλεψης. Η λογιστική παλινδρόμηση χρησιμοποιείται όταν χρειάζεται να προβλεφθεί η απουσία ή η παρουσία ενός χαρακτηριστικού, στην περίπτωσή της παρούσας έρευνας το χαρακτηριστικό είναι η ύπαρξη ή όχι σφάλματος. Τα αποτελέσματα της Λογιστικής Παλινδρόμησης είναι ένα μοντέλο που μπορεί να προβλέψει ένα από τα δύο κατηγορικά ενδεχόμενα της εξαρτημένης μεταβλητής [72]. Για παράδειγμα στη παρούσα έρευνα το αποτέλεσμα είναι πόσες φορές το μοντέλο μπορεί να προβλέψει σωστά αν ένα μονοπάτι κληρονομικότητας έχει σφάλματα (και πότε δεν έχει), δεδομένων του αριθμού των επαναορισμών και του μέγιστου δυνατού αριθμού επαναορισμών ενός μονοπατιού. Ένα ενδεικτικό αποτέλεσμα που παράγει το SPSS φαίνεται στην παρακάτω εικόνα: Εικόνα 28 Παράδειγμα Λογιστικής Παλινδρόμησης από το SPSS Η εικόνα αναφέρει συνοπτικά ότι από τα μονοπάτια κληρονομικότητας μίας έκδοσης οι 331 δεν είχαν σφάλματα και οι 37 είχαν. Το μοντέλο κατάφερε να ταξινομήσει σωστά και τις