ΠΑΝΕΠΙΣΤΗΜΙΟ ΠΑΤΡΩΝ ΠΟΛΥΤΕΧΝΙΚΗ ΣΧΟΛΗ ΤΜΗΜΑ ΜΗΧΑΝΙΚΩΝ Η/Υ & ΠΛΗΡΟΦΟΡΙΚΗΣ ΜΕΤΑΠΤΥΧΙΑΚΟ ΙΠΛΩΜΑ ΕΙ ΙΚΕΥΣΗΣ «ΕΠΙΣΤΗΜΗ & ΤΕΧΝΟΛΟΓΙΑ ΥΠΟΛΟΓΙΣΤΩΝ»

Transcript

1 ΠΑΝΕΠΙΣΤΗΜΙΟ ΠΑΤΡΩΝ ΠΟΛΥΤΕΧΝΙΚΗ ΣΧΟΛΗ ΤΜΗΜΑ ΜΗΧΑΝΙΚΩΝ Η/Υ & ΠΛΗΡΟΦΟΡΙΚΗΣ ΜΕΤΑΠΤΥΧΙΑΚΟ ΙΠΛΩΜΑ ΕΙ ΙΚΕΥΣΗΣ «ΕΠΙΣΤΗΜΗ & ΤΕΧΝΟΛΟΓΙΑ ΥΠΟΛΟΓΙΣΤΩΝ» ιπλωµατική Εργασία ιεξαγωγή µετρήσεων ποιότητας µε στόχο τη βελτίωση της συντηρησιµότητας σε λογισµικό αλληλεπίδρασης µε Βάση εδοµένων Πέρδικα Πολυτίµη Α.Μ. 389 ΕΠΙΒΛΕΠΩΝ ΤΡΙΜΕΛΗΣ ΕΠΙΤΡΟΠΗ Χριστοδουλάκης ηµήτριος, καθηγητής Χριστοδουλάκης ηµήτριος, καθηγητής Μπούρας Χρήστος, αναπληρωτής καθηγητής Ξένος Μιχάλης, επίκουρος καθηγητής Πάτρα, Νοέµβριος 2005

2 Εισαγωγή Περίληψη Η ποιότητα του λογισµικού είναι µία πολυσυζητηµένη έννοια στις µέρες µας. Παρόλο που δεν υπάρχει ένας και µόνο ορισµός που να την περιγράφει, όλοι αντιλαµβάνονται την έννοια της ποιότητας λογισµικού, ιδιαίτερα µέσω της απουσίας της. Η διασφάλιση της ποιότητας του λογισµικού συνδέεται άµεσα µε την έννοια της µετρικής, που είναι µία διαδικασία απαραίτητη για τη εκτίµηση της κατάστασης των προϊόντων, των διαδικασιών και των πόρων παραγωγής λογισµικού. Με την εφαρµογή των µετρικών σε ένα λογισµικό, µετρώνται εκείνα τα χαρακτηριστικά του που συµβάλλουν σηµαντικά στην ποιότητά του. Έτσι, είναι δυνατό να εξαχθούν συµπεράσµατα για το κατά πόσο το λογισµικό πληροί τα κριτήρια ποιότητας. Αντικείµενο της παρούσας διπλωµατικής εργασίας είναι η παρουσίαση µεθοδολογίας διεξαγωγής µετρήσεων ποιότητας σε λογισµικό αντικειµενοστραφούς προγραµµατισµού που υλοποιεί την αλληλεπίδραση µε µία Βάση εδοµένων, ώστε να εξαχθούν συµπεράσµατα κυρίως για τη συντηρησιµότητά του και κατ επέκταση για τη δυνατότητα επαναχρησιµοποίησής του. Abstract Although there is not a unique definition for software quality, its value is clearly understood, especially through its absence. Software quality reassurance is related with the concept of metrics. Metrics are considered essential to estimate the state of the product, the procedures and the resources for the software production. Through the application of metrics to a software product, the characteristics that contribute to its quality can be measured. In this way, conclusions can be drawn regarding the degree of fulfillment for the criteria of quality. This thesis presents a methodology of applying metrics to an object-oriented software, which is responsible for interacting with a database. The results of measuring the most important characteristics of the software lead to conclusions about the software s maintainability and reusability. Λέξεις - Κλειδιά λογισµικό, ποιότητα λογισµικού, µετρικές λογισµικού software, software quality, software metrics Keywords 1

3 Εισαγωγή Περιεχόµενα Κεφάλαιο 1 Εισαγωγή... 4 Κεφάλαιο 2 Ποιότητα Λογισµικού... 5 Ποιότητα... 5 Κρίση Λογισµικού... 7 Μοντέλα Ποιότητας και Πρότυπα... 8 Μοντέλο του McCall ή µοντέλο FCM... 9 Μοντέλο του Boehm Πρότυπο ISO Κεφάλαιο 3 Μετρικές Ποιότητας Λογισµικού Μετρήσεις και Μετρικές Στόχοι των Μετρικών Μετρικές Λογισµικού Μετρικές Λογισµικού Μεταµετρικές Λογισµικού Μετρικές Αντικειµενοστραφούς Λογισµικού Αρχές Αντικειµενοστραφούς Προγραµµατισµού Μετρικές Αντικειµενοστραφούς Λογισµικού Μεταµετρικές Αντικειµενοστραφούς Λογισµικού ιασφάλιση Ποιότητας Λογισµικού Μέθοδοι ιεξαγωγής Μετρήσεων Ποιότητας Λογισµικού Κεφάλαιο 4 Μετρήσεις σε Λογισµικό Αλληλεπίδρασης µε Βάση εδοµένων.34 Περιγραφή Λογισµικού Αλληλεπίδρασης µε Βάση εδοµένων Το Πληροφοριακό Σύστηµα Το Επίπεδο Backend Κλάσεις Υποδοµής Εκτέλεσης των Actions Άλλες Κλάσεις Εκτέλεσης των Actions DAO µέθοδοι και TO αντικείµενα Σύνδεση µε τη Βάση εδοµένων Logging των Χρηστών Απάντηση στο Επίπεδο frontend Στόχοι των Μετρήσεων Εργαλείο Πραγµατοποίησης των Μετρήσεων Μετρικές του Εργαλείου Εµφάνιση των Αποτελεσµάτων

4 Εισαγωγή Κεφάλαιο 5 ιεξαγωγή Μετρήσεων Λογισµικού Σενάριο ιεξαγωγής των Μετρήσεων Προδιαγραφές και Περιορισµοί των Μετρήσεων Λίγα Λόγια για την Ανάπτυξη του Backend Προδιαγραφές και Περιορισµοί των Μετρήσεων Σενάριο Μετρήσεων ιεξαγωγή των Μετρήσεων Μέγεθος του Πηγαίου Κώδικα οµή του Πηγαίου Κώδικα Μετρήσεις του Πηγαίου Κώδικα Μετρήσεις Οµάδας Α Μετρήσεις Οµάδας Β Κεφάλαιο 6 Αποτελέσµατα Ανάλυσης και Συµπεράσµατα των Μετρήσεων.. 63 Συσχετίσεις Μετρικών και Αποτελεσµάτων Αριθµός Συνολικών Χαρακτήρων Ποσοστό Σχολίων και Καθαρού Κώδικα 64 Ποσοστό Σχολίων Weighted McCabe Αριθµός Χαρακτήρων Καθαρού Κώδικα Weighted McCabe Αριθµός Χαρακτήρων Καθαρού Κώδικα Max McCabe Αριθµός Χαρακτήρων Καθαρού Κώδικα Average McCabe Αριθµός Χαρακτήρων Καθαρού Κώδικα Μέσο Μέγεθος Μεθόδου Μέσο Μέγεθος Μεθόδου Weighted McCabe Κεφάλαιο 7 Συµπεράσµατα Κεφάλαιο 8 Βιβλιογραφία Αναφορές Κεφάλαιο 9 Παράρτηµα Α Οµάδα Α Οµάδα Β Κεφάλαιο 10 Παράρτηµα Β

5 Εισαγωγή Κεφάλαιο 1 Εισαγωγή Αντικείµενο της παρούσας διπλωµατικής εργασίας είναι η παρουσίαση µεθοδολογίας διεξαγωγής µετρήσεων ποιότητας σε λογισµικό αντικειµενοστραφούς προγραµµατισµού που υλοποιεί την αλληλεπίδραση µε µία Βάση εδοµένων, ώστε να εξαχθούν συµπεράσµατα για τη συντηρησιµότητά του και κατ επέκταση τη δυνατότητα επαναχρησιµοποίησής του. Η παρουσίαση της µεθοδολογίας διεξαγωγής των µετρήσεων και των συµπερασµάτων που προέκυψαν οργανώνεται σε έξι συνολικά κεφάλαια: Στο Κεφάλαιο 2 γίνεται µία σύντοµη αναφορά στην έννοια της ποιότητας του λογισµικού. Αναλύεται, επίσης, ο πολυσυζητηµένος όρος της κρίσης του λογισµικού και παρουσιάζονται τα βασικότερα µοντέλα ποιότητα και πρότυπα βάσει των οποίων µπορεί να αναπτυχθεί ποιοτικό λογισµικό. Στο Κεφάλαιο 3 αναλύεται η έννοια της µετρικής, και γίνεται ο διαχωρισµός της µε τον όρο µέτρηση, πώς αυτή συνδέεται µε την ποιότητα και πώς µέσω αυτής µπορεί να διασφαλιστεί η ποιότητα του λογισµικού. Περιγράφονται ακόµη οι σηµαντικότερες µετρικές λογισµικού συναρτησιακού και αντικειµενοστραφούς που υπάρχουν στη βιβλιογραφία. Στο Κεφάλαιο 4 περιγράφεται το λογισµικό στο οποίο πραγµατοποιούνται οι µετρήσεις. Καθορίζονται οι στόχοι για την πραγµατοποίηση των µετρήσεων, που σχετίζονται κατά κύριο λόγο µε τη συντηρησιµότητα και έπειτα µε την επαναχρησιµοποιησιµότητα του λογισµικού. Επίσης, παρουσιάζεται το εργαλείο µε το οποίο θα διεξαχθούν οι µετρήσεις, είναι το Metrics v2.0 που αναπτύχθηκε στα πλαίσια διπλωµατικών εργασιών του τµήµατος Μηχανικών Η/Υ & Πληροφορικής και αναφέρονται οι λόγοι για τους οποίους το εργαλείο αυτό είναι κατάλληλο, βάσει των στόχων που έχουν τεθεί. Στο Κεφάλαιο 5 περιγράφεται το σενάριο διεξαγωγής των µετρήσεων στο λογισµικό, το οποίο σχεδιάστηκε µε βάση τους στόχους που τέθηκαν στο προηγούµενο κεφάλαιο. Αναλύεται, επίσης, η µεθοδολογία που ακολουθείται για την επιτυχή διεκπεραίωση των µετρήσεων, ώστε από τα αποτελέσµατα να εξαχθούν σαφή συµπεράσµατα για τη συντηρησιµότητα και την επαναχρησιµοποιησιµότητα του λογισµικού. Στη συνέχεια, επισυνάπτονται τα αποτελέσµατα, όπως αυτά προέκυψαν κατά την πραγµατοποίηση των µετρήσεων στο εργαλείο Metrics. Στο Κεφάλαιο 6 γίνεται η ανάλυση των αποτελεσµάτων που παρατίθενται στο προηγούµενο κεφάλαιο και βάσει αυτής εξάγονται συµπεράσµατα για το λογισµικό όσον αφορά κατά πρώτον στη συντηρησιµότητα και ακολούθως την επαναχρησιµοποιησιµότητά του. Τα συµπεράσµατα που προέκυψαν από όλη τη διαδικασία µελέτης και πραγµατοποίησης της µεθοδολογίας διεξαγωγής των µετρήσεων καταγράφονται στο Κεφάλαιο 7.

6 Ποιότητα Λογισµικού Κεφάλαιο 2 Ποιότητα Λογισµικού Στο κεφάλαιο αυτό γίνεται µία σύντοµη αναφορά στην έννοια της ποιότητας του λογισµικού. Αναλύεται, επίσης, ο πολυσυζητηµένος όρος της κρίσης του λογισµικού και παρουσιάζονται τα βασικότερα µοντέλα ποιότητα και πρότυπα βάσει των οποίων µπορεί να αναπτυχθεί ποιοτικό λογισµικό. Ποιότητα Αν και η ποιότητα ως έννοια χρονολογείται πολλούς αιώνες πριν, δεν υπάρχει ένας σαφής ορισµός που να την περιγράφει. Κάποιοι υποστηρίζουν ότι η ποιότητα ενός προϊόντος γίνεται αντιληπτή µέσω της έλλειψής της, κάτι που από τη µία, δεν ορίζει την ποιότητα και από την άλλη, δεν καθορίζει τα χαρακτηριστικά ενός ποιοτικού προϊόντος. Ο ορισµός της ποιότητα που έχει υιοθετηθεί από τον Ελληνικό Οργανισµό Τυποποίησης (ΕΛ.Ο.Τ.) και δίνεται στο πρότυπο ISO 8402 είναι Ποιότητα είναι το σύνολο των χαρακτηριστικών µίας οντότητας που της αποδίδουν την ικανότητα να ικανοποιεί εκφρασµένες και συνεπαγόµενες ανάγκες. Ωστόσο, πολλοί άλλοι ορισµοί έχουν δοθεί για να περιγράψουν αυτό που γίνεται αντιληπτό ως ποιότητα. Ένας από τους πρώτους διατυπώθηκε από την American Society for Quality Control (ASQC) που αργότερα µετονοµάστηκε σε ASQ και είναι Ποιότητα είναι η συλλογή των χαρακτηριστικών και ιδιοτήτων του προϊόντος που σχετίζονται µε τη δυνατότητά του να εκπληρώνει τις ζητούµενες ανάγκες των πελατών [AME78]. Επίσης, ο Phillip Crosby όρισε ως ποιότητα τη συµµόρφωση µε τις απαιτήσεις των χρηστών [CRO79], ενώ ο Joseph Juran την καταλληλότητα προς χρήση [JUR80]. Ο Roger Pressman παραθέτει τον ορισµό του American Heritage Dictionary που περιγράφει την ποιότητα ως ένα χαρακτηριστικό ή µία ιδιότητα, ενώ τη διαχωρίζει σε ποιότητα σχεδίασης (quality of design) και ποιότητα συµµόρφωσης (quality of conformance). Η ποιότητα σχεδίασης αναφέρεται στα χαρακτηριστικά που οι σχεδιαστές αποδίδουν σε ένα αντικείµενο (item) προκείµενου να κατασκευαστεί και η ποιότητα συµµόρφωσης αντιστοιχεί στο βαθµό που οι προδιαγραφές σχεδίασης ακολουθούνται κατά την κατασκευή. [PRE97] Για την περίπτωση του λογισµικού έχει γίνει προσπάθεια ώστε να αναπτυχθούν µέθοδοι διασφάλισης της ποιότητάς του. Ο David Garvin σε ένα άρθρο του που µελετά την ποιότητα συµπεραίνει ότι η ποιότητα είναι µία πολύπλοκη και πολυπρόσωπη ιδέα και µπορεί να περιγραφεί από πέντε διαφορετικές πλευρές [GAR84]: Υπερβατική θεώρηση (transcendental view) η ποιότητα είναι κάτι που µπορεί να αναγνωριστεί, αλλά όχι να οριστεί ή να επιτευχθεί πλήρως. 5

7 Ποιότητα Λογισµικού Θεώρηση από την πλευρά του χρήστη (user view) η ποιότητα ορίζεται ως καταλληλότητα για χρήση. Κατασκευαστική θεώρηση (manufacturing view) η ποιότητα αντιµετωπίζεται ως η ικανοποίηση των απαιτήσεων και των ιδιαιτεροτήτων του χρήστη. Θεώρηση από την πλευρά του προϊόντος (product view) η ποιότητα ταυτίζεται µε τα εσωτερικά χαρακτηριστικά του προϊόντος. Θεώρηση βάσει της αξίας (value-based view) η ποιότητα εξαρτάται από την αξία που κοστολογείται το προϊόν, δηλαδή από το ποσό που διατίθεται να πληρώσει ο χρήστης. Έχει αποδειχθεί ότι οι πιο διαδεδοµένες αντιλήψεις για την ποιότητα είναι η κατασκευαστική και η θεώρηση από την πλευρά του χρήστη, κάτι που αποδεικνύει ότι βασικός παράγοντας για τον καθορισµό της ποιότητας ενός προϊόντος είναι ο ίδιος ο χρήστης. Επίσης, η ποιότητα καθορίζεται από την κοινωνία υπάρχουσες πολιτισµικές παραδοχές και από τον κατασκευαστή [ΞΕΝ96]. Η συστηµατοποίηση των παραπάνω αντιλήψεων οδήγησε στη δηµιουργία των µοντέλων ποιότητας, στα οποία η ποιότητα του προϊόντος διασπάται σε ποιοτικά χαρακτηριστικά που µπορούν άµεσα ή έµµεσα να µετρηθούν µε τις κατάλληλες µετρικές. 6

8 Ποιότητα Λογισµικού Κρίση Λογισµικού Η ποιότητα υλικών προϊόντων και λογισµικού αποτελεί µία πολυσυζητηµένη έννοια για την οποία έχουν δοθεί πολλοί διαφορετικοί ορισµοί. Όλοι όµως συντείνουν στο ότι η ποιότητα ενός προϊόντος είναι η ικανοποίηση των απαιτήσεων του πελάτη χρήστη. Αν και οι βασικές αρχές της ποιότητας λογισµικού και υλικών προϊόντων είναι κοινές, υπάρχουν ουσιαστικές διαφορές στον τρόπο προσέγγισής τους. Στην παραγωγή υλικών προϊόντων απλώς εντοπίζονται και απορρίπτονται τα κοµµάτια που δεν ακολουθούν τις προδιαγραφές, ενώ στο λογισµικό απαιτείται η διασφάλιση της ποιότητας του µοναδικού προϊόντος που θα παραχθεί. Βασικότερο πρόβληµα στη διασφάλιση ποιότητας του λογισµικού είναι η έλλειψη καθορισµού µετρήσιµων στόχων και διαδικασιών µέτρησης του ενδιάµεσου ή/και τελικού προϊόντος λογισµικού. Ο όρος κρίση λογισµικού παρουσιάστηκε από την αρχή της δηµιουργίας της Τεχνολογίας Λογισµικού (Software Engineering) και χρησιµοποιήθηκε για να περιγράψει την αντίθεση µεταξύ της ραγδαίας ανάπτυξης των υπολογιστικών συστηµάτων και της αδυναµίας συγγραφής προγραµµάτων που να εκµεταλλεύονται στο έπακρο την υπολογιστική αυτή δύναµη. Ο Edsger Dijkstra's [DIJ72] αναφέρει ότι: [Η κύρια αιτία της κρίσης λογισµικού είναι ότι] οι µηχανές έχουν γίνει αρκετές τάξεις µεγέθους ισχυρότερες. Για να το θέσω ευθέως: όσο δεν υπήρχαν καθόλου µηχανές, ο προγραµµατισµός δεν αποτελούσε καθόλου πρόβληµα. Όταν είχαµε µερικούς αδύναµους υπολογιστές, ο προγραµµατισµός ήταν ένα πρόβληµα µέτριας σηµασίας και τώρα που έχουµε γιγαντιαίους υπολογιστές, ο προγραµµατισµός έχει γίνει επίσης ένα γιγάντιο πρόβληµα. Ένας ακόµη λόγος που οδήγησε στην κρίση του λογισµικού είναι οι αντικρουόµενες απαιτήσεις των χρηστών. Πιο συγκεκριµένα, οι χρήστες απαιτούν από το λογισµικό, εκτός από εύχρηστο, να παρέχει πλήθος λειτουργιών και δυνατοτήτων, να υλοποιηθεί σε πολύ µικρό χρονικό διάστηµα και να έχει πολύ χαµηλό κόστος. Έτσι, στην παραγωγή λογισµικού συναντώνται έργα που ξεπερνούν πολλές φορές κατά πολύ τον αρχικό τους προϋπολογισµό ή/και τον καθορισµένο χρόνο παράδοσης. Επίσης, σε έργα που υλοποιήθηκαν έτσι ώστε να τηρηθεί το αρχικό χρονοδιάγραµµα και το κόστος να κρατηθεί σε προσυµφωνηµένα επίπεδα, το παραγόµενο λογισµικό είναι χαµηλής ποιότητας και σε ορισµένα σηµεία δεν ανταποκρίνεται στις απαιτήσεις των χρηστών, ενώ η συντήρησή του αποτελεί επίπονη διαδικασία. Η κρίση του λογισµικού, το µεγάλο ποσοστό των αποτυχηµένων έργων και η ανικανότητα συντήρησης όσων επιτυχώς ολοκληρώθηκαν έκαναν επιτακτική την ανάγκη για µια µεθοδολογία διασφάλισης ποιότητας λογισµικού και διεθνών προτύπων τα οποία καθορίζουν πώς πρέπει να εφαρµοστεί ένα πρόγραµµα διασφάλισης ποιότητας στη διαδικασία παραγωγής λογισµικού. 7

9 Ποιότητα Λογισµικού Μοντέλα Ποιότητας και Πρότυπα Μοντέλο Ποιότητας είναι ένα σχήµα που βοηθά την πιο άµεση κατανόηση της ποιότητας του λογισµικού. Τα µοντέλα ποιότητας διασπούν την ποιότητα σε επιµέρους παράγοντες οι οποίοι και τη συνθέτουν ώστε αυτή να γίνεται άµεσα αντιληπτή και εύκολα µετρήσιµη. Τα µοντέλα ποιότητας, εφόσον ορίζουν παράγοντες υψηλού επιπέδου, δίνουν τη δυνατότητα στους µηχανικούς ανάπτυξης λογισµικού να προβλέψουν καλύτερα τη συντήρησή του και στους προγραµµατιστές να συνδυάσουν τα εσωτερικά και εξωτερικά χαρακτηριστικά του, ώστε να παράγουν ποιοτικό λογισµικό. Οι παράγοντες ποιότητας ή ποιοτικά χαρακτηριστικά, όπως ονοµάζονται διαφορετικά κατηγοριοποιούνται ως προς: Τον τελικό χρήστη: α) λειτουργικότητα (functionality) είναι η δυνατότητα του λογισµικού να παρέχει λειτουργίες που ικανοποιούν δηλωµένες ή/και συνεπαγόµενες ανάγκες υπό συγκεκριµένες συνθήκες. β) ευχρηστία (usability) είναι η δυνατότητα του λογισµικού να λειτουργεί αποτελεσµατικά και αποδοτικά παρέχοντας ικανοποίηση στους τελικούς χρήστες. Την οµάδα ανάπτυξης: α) συντηρησιµότητα (maintainability) είναι το σύνολο των χαρακτηριστικών που σχετίζονται µε την προσπάθεια που απαιτείται για να ενσωµατωθούν τροποποιήσεις στις απαιτήσεις και να υλοποιηθούν αλλαγές στο λογισµικό. β) ελεγξιµότητα (testability) είναι το σύνολο των χαρακτηριστικών που σχετίζονται µε την προσπάθεια που απαιτείται για τον έλεγχο του βαθµού στον οποίο το λογισµικό ικανοποιεί τις προδιαγραφές χρήσης και λειτουργίας χωρίς λάθη ή απώλειες. γ) επαναχρησιµοποιησιµότητα (reusability) είναι το σύνολο των χαρακτηριστικών που σχετίζονται µε την απαιτούµενη προσπάθεια για επαναχρησιµοποίηση είτε ενός τµήµατος είτε όλου του λογισµικού. δ) µεταφερσιµότητα (portability) είναι το σύνολο των χαρακτηριστικών που σχετίζονται µε τη δυνατότητα του λογισµικού να µεταφέρεται από ένα περιβάλλον σε άλλο. Την κοινότητα των χρηστών: α) αξιοπιστία (reliability) το σύνολο των χαρακτηριστικών που δίνουν στο λογισµικό τη δυνατότητα να διατηρεί το υψηλό επίπεδο απόδοσής του υπό καθορισµένες συνθήκες και για συγκεκριµένη χρονική περίοδο. β) αποδοτικότητα (efficiency) είναι το σύνολο των χαρακτηριστικών που επηρεάζουν την επίδοση του λογισµικού και τους πόρους που χρησιµοποιούνται υπό καθορισµένες συνθήκες. 8

10 Ποιότητα Λογισµικού Τα µοντέλα ποιότητας µπορεί να είναι δύο κατευθύνσεων: µε προσέγγιση από πάνω προς τα κάτω (top-down approach): ξεκινά µε σκοπούς και ανάγκες υψηλού επιπέδου και παράγει τις µετρήσεις που χρειάζονται για την υποστήριξή τους. (Εικόνα 2.1) µε προσέγγιση από κάτω προς τα πάνω (bottom-up approach): ξεκινά µε µετρήσιµες παρατηρήσεις από όπου προκύπτουν και οι στόχοι. (Εικόνα 2.2) Εικόνα 2.1 προσέγγιση από πάνω προς τα κάτω Εικόνα 2.2 προσέγγιση από κάτω προς τα πάνω Στη συνέχεια περιγράφονται ορισµένα από τα πιο γνωστά µοντέλα ποιότητας και πρότυπα. Μοντέλο του McCall ή µοντέλο FCM Το µοντέλο του McCall αναπτύχθηκε για την US Air Force Rome Air Development Center από το Jim McCall και τους συνεργάτες του. Το µοντέλο αυτό εστιάζει στο τελικό προϊόν (εκτελέσιµο κώδικα) και αναγνωρίζει βασικά γνωρίσµατα που ονοµάζονται παράγοντες ποιότητας (quality factors) από την πλευρά του χρήστη. [MCC77] Οι παράγοντες ποιότητας που προτείνει ο McCall είναι οι εξής έντεκα: Χρησιµότητα (Usability) Ακεραιότητα (Integrity) Αποδοτικότητα (Efficiency) Ορθότητα (Correctness) Αξιοπιστία (Reliability) Συντηρησιµότητα (Maintainability) Ελεγξιµότητα (Testability) Ευελιξία (Flexibility) 9

11 Ποιότητα Λογισµικού Επαναχρησιµοποιησιµότητα (Reusability) Μεταφερσιµότητα (Portability) ιαλειτουργικότητα (Interoperability) Οι παράγοντες αυτοί περιγράφουν τη συµπεριφορά του συστήµατος, αλλά είναι πολύ υψηλού επιπέδου για να µετρηθούν άµεσα. Για το λόγο αυτό διασπώνται σε χαµηλότερου επιπέδου χαρακτηριστικά που ονοµάζονται κριτήρια ποιότητας (quality criteria) και σχετίζονται περισσότερο µε την παραγωγή και το σχεδιασµό λογισµικού. Τα κριτήρια ποιότητας περιγράφουν εσωτερικά χαρακτηριστικά του προϊόντος, µιας και αυτά είναι που επηρεάζουν τα εξωτερικά του χαρακτηριστικά. Απαιτείται όµως και ένα επιπλέον στάδιο εκλέπτυνσης στο οποίο ένας αριθµός από χαµηλού επιπέδου µετρήσεις αντιστοιχίζεται σε κάθε κριτήριο ποιότητας και ονοµάζονται µετρικές (metrics). Τα συστατικά αυτά δίνουν στο µοντέλο του McCall το όνοµα FCM (Factors Criteria - Metrics). Για παράδειγµα, για να βρεθεί ο βαθµός ικανοποίησης του παράγοντα µεταφερσιµότητα (portability), αρκεί να µετρήσει κανείς τα κριτήρια ποιότητας αυτοπεριγραφικότητα (self-descriptiveness), ανεξαρτησία από τη µηχανή (machine independence) και ανεξαρτησία από το λογισµικό του συστήµατος (S/W system independence). Η σύνδεση παραγόντων και κριτηρίων ποιότητας φαίνεται στην Εικόνα

12 Ποιότητα Λογισµικού Εικόνα 2.3 Το µοντέλο FCM Μοντέλο του Boehm Το µοντέλο του Boehm [FEN94] ακολουθεί παρόµοια ιεραρχική δοµή µε αυτή του µοντέλου του McCall. Στο µοντέλο του Boehm η ποιότητα της εφαρµογής διασπάται σε πρωταρχικές χρήσεις (primary uses) και κάθε µία από αυτές σε ενδιάµεσες κατασκευές (intermediate constructs) ανάλογες µε τους παράγοντες και τα κριτήρια ποιότητας του µοντέλου του McCall. Κάθε µία από τις ενδιάµεσες κατασκευές διασπάται περαιτέρω σε πρωτογενείς κατασκευές (primitive constructs) που µετρούνται άµεσα µε µετρικές (metrics). 11

13 Ποιότητα Λογισµικού Εικόνα 2.4 Το µοντέλο Boehm Το µοντέλο του Boehm ακολουθεί τη λογική της εκλέπτυνσης της ποιότητας σε χαρακτηριστικά τα οποία είναι άµεσα µετρήσιµα µε την κατάλληλη µετρική όµοια µε το µοντέλο του McCall (Εικόνα 2.4). εν είναι όµως τόσο καλά δοµηµένο όσο αυτό του McCall. Για παράδειγµα, η γενικευµένη εφαρµογή διασπάται στην πρωταρχική χρήση της συντηρησιµότητας (maintainability) και στην ενδιάµεση κατασκευή της µεταφερσιµότητας (portability). Πρότυπο ISO 9126 Το πρότυπο ISO 9126 είναι το αποτέλεσµα µίας διεθνούς προσπάθειας να αναπτυχθεί ένα πρότυπο για τη µέτρηση της ποιότητας λογισµικού [KIT96] και βάση του αποτελεί το µοντέλο του McCall. Η αρχική του ονοµασία ήταν Software Product Evaluation: Quality Characteristics and Guidelines for their Use [FEN94]. Σύµφωνα µε το πρότυπο αυτό η ποιότητα ορίζεται ως το σύνολο των στοιχείων και των χαρακτηριστικών ενός προϊόντος λογισµικού που επιδρούν στην ικανότητά του να ανταπεξέρχεται και να ικανοποιεί είτε δεδηλωµένες είτε υπονοούµενες ανάγκες [FEN94] και αποτελείται από έξι ποιοτικά χαρακτηριστικά: 12

14 Ποιότητα Λογισµικού λειτουργικότητα (functionality): σύνολο χαρακτηριστικών που αναφέρονται σε ένα σύνολο λειτουργιών και τις ιδιότητές τους που ικανοποιούν δηλωµένες ή υπονοούµενες ανάγκες. αξιοπιστία (reliability): σύνολο χαρακτηριστικών που αναφέρονται στην ικανότητα του λογισµικού να έχει υψηλή απόδοση υπό ορισµένες συνθήκες και για συγκεκριµένο χρονικό διάστηµα. χρησιµότητα (usability): σύνολο χαρακτηριστικών που αναφέρονται στην προσπάθεια που απαιτείται από το χρήστη να µάθει και να χρησιµοποιήσει το λογισµικό. αποδοτικότητα (efficiency): σύνολο χαρακτηριστικών που αναφέρονται στη σχέση µεταξύ της απόδοσης του λογισµικού και του µεγέθους των πόρων που χρησιµοποιεί υπό συγκεκριµένες συνθήκες. συντηρησιµότητα (maintainability): σύνολο χαρακτηριστικών που αναφέρονται στην προσπάθεια που απαιτείται ώστε να ενσωµατωθούν στο λογισµικό συγκεκριµένες τροποποιήσεις. µεταφερσιµότητα (portability): σύνολο χαρακτηριστικών που αναφέρονται στην ικανότητα του συστήµατος να µεταφερθεί από το ένα περιβάλλον στο άλλο. Το πρότυπο περιέχει και ένα δείγµα διαχωρισµού των ποιοτικών χαρακτηριστικών σε ένα σύνολο από υπο-χαρακτηριστικά (Εικόνα 2.5) [BAC94, KIT96, ΞΕΝ96]. Η ανάλυση αυτή δεν είναι δεσµευτική, αλλά δηλώνει τη σηµασία που αποδίδει το πρότυπο στον περαιτέρω διαχωρισµό των ποιοτικών χαρακτηριστικών προκειµένου να µετρηθεί η ποιότητα [BAC94]. Τα υπο-χαρακτηριστικά αυτά µπορούν να µετρηθούν από ενδείκτες (indicators), οι οποίοι κατασκευάζονται από στοιχεία δεδοµένων (data elements). Η ασάφεια στο διαχωρισµό των χαρακτηριστικών και το γεγονός ότι δεν ορίζεται ο τρόπος µε τον οποίο µπορούν να µετρηθούν τα υπο-χαρακτηριστικά αποτελεί ένα µειονέκτηµα του προτύπου [KIT96]. Η διαφορά του προτύπου ISO 9126 από το µοντέλο του McCall βρίσκεται στην ορολογία που χρησιµοποιείται και στη δοµή. Το πρότυπο ISO 9126 είναι πλήρως ιεραρχικό, κάθε υπο-χαρακτηριστικό ανήκει αυστηρά σε ένα χαρακτηριστικό, αποτελεί εξωτερικό χαρακτηριστικό του προϊόντος και πλήρως ορατό από το χρήστη. Επίσης, το πρότυπο ISO 9126 αντιµετωπίζει την ποιότητα του λογισµικού από την πλευρά του χρήστη, ενώ το µοντέλο του McCall από την πλευρά του προϊόντος [KIT96]. 13

15 Ποιότητα Λογισµικού Εικόνα 2.5 ιαχωρισµός των ποιοτικών χαρακτηριστικών σύµφωνα µε το πρότυπο ISO

16 Μετρικές Ποιότητας Λογισµικού Κεφάλαιο 3 Μετρικές Ποιότητας Λογισµικού Στο κεφάλαιο αυτό γίνεται αναφορά στην έννοια της µέτρησης και της µετρικής, πώς αυτές συνδέονται µε την ποιότητα και πώς µέσω αυτών µπορεί να διασφαλιστεί η ποιότητα του λογισµικού. Παρουσιάζονται, ακόµη, οι βασικότερες µετρικές λογισµικού συναρτησιακού και αντικειµενοστραφούς προγραµµατισµού. Μετρήσεις και Μετρικές Ο Lord Kelvin αναφέρει: Όταν µπορείς να µετρήσεις αυτό για το οποίο µιλάς και να το εκφράσεις σε αριθµούς, τότε ξέρεις κάτι σχετικά µε αυτό. Όταν δε µπορείς να το µετρήσεις και να το εκφράσεις σε αριθµούς, η γνώση σου για αυτό είναι φτωχή και µη ικανοποιητική. Τα λόγια του Kelvin ισχύουν και στην περίπτωση της ποιότητας του λογισµικού [PRE97] και αναφέρονται στη µέτρηση των χαρακτηριστικών που περιγράφουν τα κατώτερα επίπεδα αφαίρεσης των µοντέλων ποιότητας. Στην Τεχνολογία Λογισµικού οι όροι µέτρηση (measure) και µετρική (metric) χρησιµοποιούνται πολλές φορές ως συνώνυµες. Μέτρηση (measure) είναι η αντιστοίχιση ενός µεγέθους µε µία τιµή, ενώ µετρική (metric) είναι ποσοτική µέτρηση του βαθµού στον οποίο ένα σύστηµα ή τµήµα αυτού έχει ένα χαρακτηριστικό. [IEE93] Με µία συλλογή µετρήσεων σχεδιάζονται και αναπτύσσονται οι µετρικές. Ένα σύνολο µετρικών που παρέχουν γνώση για το λογισµικό αποτελεί έναν ενδείκτη (indicator) [RAG95]. Ο Fenton [FEN94] ορίζει τη µετρική ως µία εµπειρική και αντικειµενική αντιστοίχιση ενός αριθµού ή συµβόλου σε µία οντότητα µε σκοπό να χαρακτηρίσει ένα συγκεκριµένο χαρακτηριστικό της. Ο Edward Berard [BER] ορίζει τη µετρική ως µία µονάδα µέτρησης και αναφέρει ότι ο όρος χρησιµοποιείται για να δηλώσει ένα σύνολο µετρήσεων που πραγµατοποιούνται πάνω σε συγκεκριµένο αντικείµενο ή διαδικασία. Προκύπτει, λοιπόν, το συµπέρασµα ότι µετρική είναι µία µεθοδολογία µέτρησης που αντιστοιχεί µία τιµή σε κάποια προϋπάρχουσα ιδιότητα του αντικειµένου. Για κάθε µετρική υπάρχουν πέντε βαθµίδες µέτρησης: α) η ονοµαστική (nominal), στην οποία η µόνη ιδιότητα µεταξύ των δεδοµένων είναι η ισότητα, β) η τακτική (ordinal), στην οποία η ιδιότητα µεταξύ των δεδοµένων είναι η ισότητα και η διάταξη, γ) η διαστήµατος (interval), όπου οι αποστάσεις µεταξύ των δεδοµένων αποτελούν πληροφορία, δ) η αναλογική (ratio), στην οποία έχουν νόηµα και οι αναλογίες µεταξύ των δεδοµένων και ε) η απόλυτη (absolute), στην οποία επιτρέπεται και η αρίθµηση των δεδοµένων. 15

17 Μετρικές Ποιότητας Λογισµικού Οι µετρικές χωρίζονται σε [PRE97]: µετρικές προϊόντος (product metrics) µετρικές έργου (project metrics) µετρικές διαδικασίας (process metrics) Οι µετρικές προϊόντος σχετίζονται µε το προϊόν, για παράδειγµα τον πηγαίο κώδικα ή τις δηλώσεις ελέγχου. Χωρίζονται σε δύο επιπλέον κατηγορίες: α) τις εσωτερικές αριθµός γραµµών (LOC), χρόνος εκτέλεσης, λάθη του κώδικα και β) τις εξωτερικές λειτουργικότητα (functionality), ποιότητα (quality), πολυπλοκότητα (complexity), αποτελεσµατικότητα (efficiency), αξιοπιστία (reliability), συντηρησιµότητα (maintainability). Ενδιαφέρον παρουσιάζει η σχέση µεταξύ των εσωτερικών και των εξωτερικών µετρικών και πιο συγκεκριµένα, πώς οι εσωτερικές µετρικές ερµηνεύονται σε εξωτερικές, ώστε να είναι άµεσα µετρήσιµες. Επίσης, οι εσωτερικές µετρικές είναι πιο εύκολα αυτοµατοποιήσιµες από τις εξωτερικές µετρικές και εποµένως πιο οικονοµικές µιας και το να µετρώνται οι γραµµές του κώδικα είναι πολύ εύκολο σε σχέση µε το να µετράται το πόσο ευχαριστηµένος είναι ο χρήστης από τις υπηρεσίες που προσφέρει το λογισµικό. Ένα ακόµη πλεονέκτηµα των εσωτερικών µετρικών είναι ότι έχουν µικρότερη συχνότητα λαθών, γιατί µετρούν πολύ καθορισµένα χαρακτηριστικά του λογισµικού, για παράδειγµα τον αριθµό των γραµµών. Αντίθετα, οι εξωτερικές µετρικές είναι υψηλού επιπέδου, και έτσι βρίσκονται πιο κοντά στην έννοια της ποιότητας. Επιπλέον, τα αποτελέσµατά τους είναι άµεσα ερµηνεύσιµα. Οι µετρικές έργου χρησιµοποιούνται για τον καθορισµό στρατηγικής, σχετίζονται µε την τακτική εκτέλεσης του έργου και καθορίζουν τη ροή του και τις τεχνικές που θα ακολουθηθούν [PRE97]. Οι µετρικές διαδικασίας µετρούν τη διαδικασία κατασκευής ενός προϊόντος, για παράδειγµα το σχεδιασµό, τη συγγραφή κώδικα, τους απαιτούµενους πόρους. Έστω ότι γίνεται αναφορά σε µία εταιρία. Οι µετρικές προϊόντος καθορίζονται από ένα άτοµο. Ο συνδυασµός τους αποτελεί τις µετρικές του έργου που κοινοποιούνται στην οµάδα του έργου. Ο συνδυασµός των τελευταίων αναπτύσσει τις µετρικές διαδικασίας που αποτελούν κτήµα όλης της εταιρίας. Το θέµα είναι πώς µία εταιρία µπορεί να συνδυάσει τις µετρικές από διαφορετικά άτοµα-εργαζόµενους ή/και διαφορετικά έργα, ώστε να παράγει τις µετρικές διαδικασίας; Για παράδειγµα, εργαζόµενοι από δύο διαφορετικές οµάδες καταγράφουν και κατηγοριοποιούν όλα τα λάθη που προκύπτουν κατά τη διάρκεια µίας διαδικασίας. Οι µετρήσεις αυτές συνδυάζονται για να προκύψουν τα αποτελέσµατα: η οµάδα Α βρήκε 342 λάθη κατά τη διαδικασία, ενώ η οµάδα Β 184. Για να βγει συµπέρασµα για το ποια οµάδα είναι πιο αποτελεσµατική, θα πρέπει να ληφθούν υπόψη και άλλες παράµετροι, όπως το µέγεθος ή η πολυπλοκότητα των έργων και οι µετρήσεις αυτές να κανονικοποιηθούν. 16

18 Μετρικές Ποιότητας Λογισµικού Στόχοι των Μετρικών Ο βασικότερος στόχος όλων των µετρικών που διεξάγονται σε ένα λογισµικό είναι η διασφάλιση της ποιότητάς του. Για να επιτευχθεί αυτό, όµως, θα πρέπει να υπάρχει ένα πλάνο ποιότητας συνολικά σε ολόκληρο το έργο ή ακόµη καλύτερα σε ολόκληρη την εταιρεία. Έτσι, η διασφάλιση της ποιότητας, σε συνδυασµό µε τις µετρικές που χρησιµοποιούνται, µπορεί να τεθεί από διαφορετικές πλευρές: διασφάλιση ποιότητας προϊόντος (product quality assurance): στόχος είναι η ποιότητα του προϊόντος και κατ επέκταση η ικανοποίηση του χρήστη. διασφάλιση ποιότητας έργου (project quality assurance): που στοχεύει α) στην αποτίµηση της κατάστασης του έργου, β) την επίλυση προβληµάτων πριν αυτά γίνουν κρίσιµα και επηρεάσουν την πορεία του έργου γ) τη ρύθµιση και το διαχωρισµό των εργασιών και δ) την εκτίµηση της ικανότητας των οµάδων να παράγουν ποιοτικό λογισµικό. διασφάλιση ποιότητας διαδικασιών (process quality assurance): που βοηθά την εταιρεία να έχει γνώση για την αποτελεσµατικότητα των διαδικασιών. Πιο συγκεκριµένα, η µέτρηση κάποιων χαρακτηριστικών του λογισµικού είναι µια διαδικασία απαραίτητη για την εκτίµηση της κατάστασης των έργων, των προϊόντων, των διαδικασιών και των πόρων παραγωγής λογισµικού. Κάθε µέτρηση, όµως, πρέπει να εξυπηρετεί µια συγκεκριµένη ανάγκη, η οποία έχει σαφώς κατανοηθεί και καθοριστεί. Έτσι, µε τις µετρήσεις µπορούν να απαντηθούν ερωτήµατα που τίθενται από το διαχειριστή του έργου: Ποιο είναι το κόστος (υλικό και προσπάθεια) σε κάθε φάση ανάπτυξης του λογισµικού; Πόσο παραγωγικό είναι το προσωπικό; Πόσο καλά έχει συγγραφεί ο πηγαίος κώδικας; Πόσο εφικτό είναι να επαναχρησιµοποιηθεί ο πηγαίος κώδικας σε άλλα έργα παραγωγής λογισµικού (reusability); Πόσο συντηρήσιµος είναι ο πηγαίος κώδικας (maintainability); Ποιες βελτιώσεις είναι εφικτές σε σχέση µε την ποιότητα και την παραγωγικότητα; και από το µηχανικό λογισµικού: Ποιες απαιτήσεις που έχουν τεθεί µπορούν να ελεγχθούν, δηλαδή να µετρηθούν µε αντικειµενικό τρόπο; Πόσα είναι τα λάθη που εντοπίστηκαν κατά τη σχεδίαση, την ανάπτυξη και τον έλεγχο του λογισµικού; 17

19 Μετρικές Ποιότητας Λογισµικού Τι προβλέψεις µπορούν να διεξαχθούν για µελλοντικά προϊόντα µέσω µετρήσεων χαρακτηριστικών των υπαρχόντων προϊόντων; Με βάση τους στόχους για τους οποίους έχουν αναπτυχθεί οι µετρικές µπορούν να διαχωριστούν στις ακόλουθες κατηγορίες: λειτουργικές µετρικές (functional metrics) που αποτελούνται από µετρικές καταλληλότητας (suitability), ακρίβειας (accuracy), διαλειτουργικότητας (interoperability), ελαστικότητας (compliance) και ασφάλειας (security) του λογισµικού. µετρικές αξιοπιστίας (reliability metrics) που αποτελούνται από µετρικές ωριµότητας (maturity), ανοχής λαθών (fault tolerance), ικανότητας ανάκτησης (recoverability). µετρικές χρησιµότητας (usability metrics) που αποτελούνται από µετρικές κατανοησιµότητας (understandability), ικανότητας µάθησης (learn ability) και λειτουργικότητας (operability) του λογισµικού. µετρικές αποδοτικότητας (efficiency metrics) που αποτελούνται από µετρικές συµπεριφοράς του συστήµατος στο χρόνο (system behavior over time) και χρήσης των πόρων (usage of resources). µετρικές συντηρησιµότητας (maintainability metrics) που αποτελούνται από µετρικές ικανότητας ανάλυσης (analysis ability), τροποποιησιµότητας (changeability), σταθερότητας (stability) και ικανότητας ελέγχου (testability). µετρικές µεταφερσιµότητας (portability metrics) που αποτελούνται από µετρικές προσαρµοστικότητας (adaptability), ικανότητας εγκατάστασης (install ability), συµµόρφωσης (conformance) και ικανότητας αντικατάστασης (replace ability). 18

20 Μετρικές Ποιότητας Λογισµικού Μετρικές Λογισµικού Οι µετρικές λογισµικού που παρουσιάζονται στην ενότητα αυτή αφορούν µηαντικειµενοστραφές λογισµικό χωρίς αυτό να σηµαίνει ότι κάποιες από αυτές δε µπορούν να χρησιµοποιηθούν και σε κώδικα γραµµένο σε αντικειµενοστραφή γλώσσα προγραµµατισµού. Κατατάσσονται στις εσωτερικές µετρικές του τελικού προϊόντος και, εποµένως, εστιάζουν σε αυτοµατοποιήσιµες µετρήσεις του πηγαίου κώδικα. Μετρικές Λογισµικού Ο Roger Pressman [PRE97] χωρίζει τις µετρικές λογισµικού σε κατηγορίες, ανάλογα µε τη φάση ανάπτυξης του λογισµικού που εφαρµόζονται: Μετρικές για το µοντέλο της ανάλυσης απαιτήσεων, που εξετάζουν την ορθότητα και την πληρότητα της ανάλυσης των απαιτήσεων, προκειµένου να γίνει ο σχεδιασµός του τελικού συστήµατος. Τέτοιες µετρικές αριθµούνται ελάχιστες στη βιβλιογραφία. Μετρικές για το µοντέλο του σχεδιασµού, που αναπτύσσονται για τον έλεγχο του σχεδιασµού του τελικού συστήµατος. Εστιάζουν τόσο στο τµήµατα (components) του συστήµατος, όσο και στη διεπαφή (interface). Μετρικές για τον πηγαίο κώδικα, που αφορούν µετρήσεις πάνω στον κώδικα και αναλύονται στη συνέχεια της ενότητας. Μετρικές για τον έλεγχο (testing), που αφορούν στον έλεγχο του λογισµικού. Οι περισσότερες µετρικές εστιάζουν στη διαδικασία του ελέγχου και όχι στα τεχνικά χαρακτηριστικά. Οι µετρικές του ελέγχου προκύπτουν ουσιαστικά από τις µετρικές των τριών προηγούµενων φάσεων. Μετρικές για τη συντήρηση, που µετρούν το βαθµό στον οποίο είναι συντηρήσιµο το λογισµικό. Ακολούθως παρουσιάζονται ορισµένες από τις πιο γνωστές µετρικές προϊόντος που εφαρµόζονται στον τελικό κώδικα του λογισµικού. Average Module Length [FEN94] Πρόκειται για µία µετρική της τµηµατοποίησης ενός προγράµµατος. Ορίζεται ως το µέσο µήκος των τµηµάτων (modules) του. Chen Metric [FEN94] Εξετάζει την εντροπία ενός προγράµµατος. 19

21 Μετρικές Ποιότητας Λογισµικού Decision Count [FEN94], [CON86], [SHE93] Μετρά τη λογική δοµή ενός προγράµµατος. Ορίζεται από τον αριθµό των δηλώσεων ελέγχου (υπό-συνθήκη δηλώσεις και ανακυκλώσεις). Executable Statements [FEN94] Μετρική µεγέθους. Ορίζεται ως τον αριθµό των εκτελέσιµων εντολών (executable statements) ενός προγράµµατος. Μετρά τις διαφορετικές εντολές στην ίδια γραµµή ως διαφορετικές και αγνοεί τα σχόλια, τις δηλώσεις δεδοµένων και τα headings. Extent Of Reuse [FEN94] Μετρά το ποσοστό επαναχρησιµοποίησης κώδικα σε ένα υπάρχον πρόγραµµα. Ορίζονται τέσσερα διαφορετικά επίπεδα: reused verbatim (κώδικας που επαναχρησιµοποιήθηκε χωρίς καµία αλλαγή), slightly modified (λιγότερο από 25% κώδικα έχει αλλαχθεί), extensively modified (25% και περισσότερο των γραµµών του κώδικα έχει αλλαχθεί) και new (εντελώς νέος κώδικας). Με τον τρόπο αυτό, για ένα συγκεκριµένο πρόγραµµα ορίζεται το µέγεθος (size) που τροποποιήθηκε σε σχέση µε το συνολικό και, εποµένως, το ποσοστό επαναχρησιµοποίησης στα τέσσερα επίπεδα. Function Count [CON86], [LOR94] Ορίζεται από τον αριθµό των συναρτήσεων (functions) ενός προγράµµατος. Συνάρτηση θεωρείται µια συλλογή εκτελέσιµων εντολών που πραγµατοποιούν µια συγκεκριµένη εργασία και οι δηλώσεις των παραµέτρων που διαχειρίζονται οι εντολές αυτές. Hausen Metric On Modularity [FEN94] Μετρική της τµηµατοποίησης ενός προγράµµατος που περιγράφει την ολική τµηµατοποίηση σε σχέση µε ειδικές της θεωρήσεις. Για παράδειγµα: Μ1=modules/procedures, M2=modules/variables. Live Variables [CON86] Στόχος της µετρικής αυτής είναι να χαρακτηρίσει τη ροή των δεδοµένων µέσα σε ένα τµήµα (module). Τα δεδοµένα (data items) κάθε εντολής ενός προγράµµατος ονοµάζονται ζωντανές µεταβλητές (live variables). H µετρική µετρά για κάθε γραµµή κώδικα πόσες µεταβλητές βρίσκονται σε χρήση και ορίζει 20

22 Μετρικές Ποιότητας Λογισµικού LV = (αριθµός live variables) / (αριθµός εντολών) για κάθε διαδικασία. Lines Of Code [FEN94], [CON86], [SHE93], [LOR94] Μετρά τον αριθµό των γραµµών κώδικα. Παραλλαγές της είναι οι µετρικές που µετράνε τον αριθµό των κενών γραµµών, του εκτελέσιµου κώδικα, των γραµµών του πηγαίου κώδικα, το ποσοστό σχολίων κλπ. McCabe s Essential Complexity Measure [FEN94] Μετράται το ποσό της δοµής σε ένα πρόγραµµα. Για ένα πρόγραµµα µε γράφο ροής G, η βασική πολυπλοκότητα ορίζεται ως ev(g) = v(g) - m, όπου v(g) = e n + 2 η κυκλωµατική πολυπλοκότητα του γράφου ροής G και m o αριθµός των υπογράφων ροής του γράφου G που είναι D-structured primes (είναι δηλαδή οι εντελώς στοιχειώδεις δοµές D 0, D 1, D 2 ή D 3 ). Μετρά πόσο πρέπει να µειωθεί o γράφος ροής, δηλαδή να αποσυντεθεί σε στοιχειώδεις δοµές που είναι D-primes. Με άλλα λόγια, το ev µετρά την κυκλωµατική πολυπλοκότητα αυτού που αποµένει µετά την αποσύνθεση όλων των δοµηµένων υπογράφων ροής. Reach Ability [CON86], [SHE93] Μετρά τη λογική δοµή του προγράµµατος. Ορίζει την reachability ως R = πλήθος διαφορετικών τρόπων για να φτάσει κάποιος ένα κόµβο και R = (συνολικό πλήθος µονοπατιών) / (αριθµός κόµβων) Η µετρική αυτή σχετίζεται µε τον αριθµό των λαθών και τον χρόνο εντοπισµού τους. Tree Impurity [FEN94] Η µετρική αυτή ορίζει τον αριθµό m(g) από το γράφο G του συστήµατος. Ο m(g) ισούται µε το πόσο απέχει από ένα δένδρο o γράφος αυτός. Όσο το m τείνει στο µηδέν, τόσο καλύτερος είναι o σχεδιασµός του συστήµατος. 21

23 Μετρικές Ποιότητας Λογισµικού Μεταµετρικές Λογισµικού Ως µεταµετρικές ορίζονται τα κριτήρια αξιολόγησης των µετρικών. Στην προκειµένη περίπτωση, όµως, οι µετρικές δεν κατατάσσονται σε καλές ή κακές αλλά σε καταλληλότερες ή λιγότερο κατάλληλες. Μία πρώτη προσπάθεια καθορισµού µεταµετρικών έγινε από τους Conte, Dunsimore και Shen [CON86]. Οι µεταµετρικές που τελικά προτάθηκαν ήταν οι ακόλουθες: απλότητα (simplicity): µετράται το κατά πόσο τα αποτελέσµατα µίας µετρικής είναι ερµηνεύσιµα. εγκυρότητα (validity): µετράται το αν και κατά πόσο µία µετρική µετρά αυτό για το οποίο έχει αναπτυχθεί. ανθεκτικότητα (robustness): εξετάζεται εάν µία µετρική είναι ευαίσθητη σε αλλαγές παραγόντων που δεν επηρεάζουν την απόδοση του λογισµικού για παράδειγµα την αναδιάταξη του πηγαίου κώδικα. καθοδηγησιµότητα (prescriptiveness): εξετάζει εάν το αποτέλεσµα κάποιας µετρικής µπορεί να χρησιµοποιηθεί στην ανάπτυξη ή τη συντήρηση του λογισµικού. αναλυτικότητα (analysability): µετράται κατά πόσο µπορεί να αναλυθεί στατιστικά το αποτέλεσµα κάποιας µετρικής. Βέβαια, κάποιες από τις παραπάνω µεταµετρικές µπορούν να υπολογιστούν µόνο υποκειµενικά, κάτι το οποίο δεν είναι επιθυµητό, µιας και έτσι δεν µπορούν να χρησιµεύσουν σε συγκρίσεις προγραµµάτων λογισµικού που έχουν αξιολογηθεί από διαφορετικούς ερευνητές(-εργαζόµενους-µηχανικούς λογισµικού). Το 1988 η Elaine Weyuker [WEY88] περιέγραψε κάποιες πιο αφηρηµένες ιδιότητες των καλών µετρικών, οι οποίες και χρησιµοποιούνται κατά κόρον [ ΤΠ06]: η διακριτικότητα (non-coarseness) η µη µοναδικότητα (non-uniqueness) η αναδιάταξη είναι σηµαντική (permutation is important) η υλοποίηση είναι σηµαντική (implementation is important) η µονοτονία (monotonicity) η µη ισοδυναµία στην αλληλεπίδραση (non-equivalence of interaction) η αλληλεπίδραση αυξάνει την πολυπλοκότητα (interaction increases copmlexity) η µη απειρία των προγραµµάτων (finiteness) αρχή του ρόδου (rose principle) 22

24 Μετρικές Ποιότητας Λογισµικού Μετρικές Αντικειµενοστραφούς Λογισµικού Λόγω του ότι οι αρχές του αντικειµενοστραφούς προγραµµατισµού είναι διαφορετικές σε σχέση µε αυτές του συναρτησιακού, οι µετρικές που ασχολούνται µε το αντικειµενοστραφές λογισµικό θα πρέπει να ακολουθούν τις αρχές αυτές, αν και ορισµένες από τις αντικειµενοστραφείς µετρικές αποτελούν µία παραλλαγή των µηαντικειµενοστραφών. Οι αντικειµενοστραφείς µετρικές εστιάζουν στα σηµεία εκείνα του πηγαίου κώδικα που ακολουθούν τις αρχές του αντικειµενοστραφούς προγραµµατισµού. Αρχές Αντικειµενοστραφούς Προγραµµατισµού Στον αντικειµενοστραφή προγραµµατισµό τον κύριο ρόλο έχουν οι κλάσεις και τα αντικείµενα. Κάθε αντικείµενο έχει µια συµπεριφορά, η οποία καθορίζεται από τις µεθόδους (συναρτήσεις) που αυτό διαθέτει. Μεταξύ των αντικειµένων και των κλάσεων δεν υπάρχουν απλώς σχέσεις καλούντος-καλούµενου, αλλά πλήθος άλλων σχέσεων, όπως ιεραρχίας, συνδέσµου κλπ. Συνεπώς, o αντικειµενοστραφής προγραµµατισµός έχει τα δικά του χαρακτηριστικά που επηρεάζουν την ποιότητα του λογισµικού. ηλαδή, χρησιµοποιώντας την ορολογία του µοντέλου του McCall, η ποιότητα διασπάται στους ποιοτικούς παράγοντες και αυτοί στα κριτήρια ποιότητας, τα οποία όµως εξαρτώνται κυρίως από την ύπαρξη ή όχι κάποιων χαρακτηριστικών αντικειµενοστραφούς προγραµµατισµού. Αντίστροφα, οι µετρικές που χρησιµοποιούνται πρέπει να µετρούν κατά πόσο υπάρχουν τα χαρακτηριστικά αυτά, τα οποία και βελτιώνουν την ποιότητα των αντικειµενοστραφών προγραµµάτων. Η σηµασία των χαρακτηριστικών του αντικειµενοστραφούς προγραµµατισµού και o τρόπος που επιδρούν στην ποιότητα (ή καλύτερα στα κριτήρια ποιότητας του µοντέλου του McCall) [ZHK00] αναλύονται ακολούθως. Τοπικότητα-Τµηµατοποίηση (localization-modularity) Πρόκειται για την ιδιότητα των αντικειµενοστραφών προγραµµάτων να οργανώνονται γύρω από τα αντικείµενα [BOO02], [ ΤΠ01]. Οι αντικειµενοστραφείς µετρικές αναγνωρίζουν το αντικείµενο ως δοµική µονάδα των προγραµµάτων παρόλο που και το ίδιο έχει κάποια λειτουργικότητα και λαµβάνουν υπόψη τη σχέση µεταξύ των αντικειµένων. Στον αντικειµενοστραφή προγραµµατισµό ένα αντικείµενο µπορεί να έχει πολλές συναρτήσεις και µια συνάρτηση να αναφέρεται σε πολλά αντικείµενα [ ΤΠ01]. Οι Lorenz & Kidd [LOR94] αναφέρουν ότι µια τυπική µέθοδος ενός αντικειµένου δεν πρέπει να ξεπερνά τις 25 γραµµές, συνεπώς δεν είναι η πολυπλοκότητα της µεθόδου τόσο καθοριστικός παράγοντας στην ποιότητα, όσο το σύνολο της πολυπλοκότητας των µεθόδων της κλάσης, εποµένως, o αριθµός των µεθόδων αυτών. Συγκεκριµένα, όσο περισσότερες µεθόδους και ιδιότητες έχει ένα αντικείµενο, τόσο πιο πολύπλοκο είναι, τόσο πιο δύσκολος είναι o έλεγχος του αντικειµένου και του προγράµµατος και τόσο περισσότερο χώρο στη µνήµη απαιτεί. Ακόµα, o υπερβολικός αριθµός µεθόδων µιας 23

25 Μετρικές Ποιότητας Λογισµικού κλάσης επιβαρύνει τα παιδιά της [ ΤΠ02] και µπορεί να σηµαίνει ότι η κλάση είναι αρκετά βαθιά στην ιεραρχία, άρα και το αντικείµενο είναι εξαιρετικά εξειδικευµένο και µε µικρή δυνατότητα επέκτασης. Γενικά, η τοπικότητα όσον αφορά τα κριτήρια ποιότητας επηρεάζει την απόδοση του προγράµµατος όσον αφορά στην α) αποθήκευση (storage efficiency), β) ανιχνευσιµότητα (traceability), γ) απλότητα (simplicity), δ) συνέπεια (consistency) ε) ακρίβεια (conciseness), στ) επεκτασιµότητα (expandability), ζ) γενικότητα (generality), η) αυτοπεριγραφικότητα (self-descriptiveness) και θ) τµηµατοποίηση (modularity). Εποµένως, επηρεάζονται οι ποιοτικοί παράγοντες της ευχρηστίας (usability), της αξιοπιστίας (reliability), της συντηρησιµότητας (maintainability) και της ευκολίας ελέγχου (testability) του λογισµικού. Συνοχή (cohesion) Συνοχή είναι η ιδιότητα ενός αντικειµένου να αποτελεί µια αυτόνοµη οντότητα και είναι χαρακτηριστικό της καλής υποδιαίρεσης των κλάσεων (class subdivision) [ ΤΠ03]. Ακόµη, µπορεί να οριστεί ως o βαθµός στον οποίον οι µέθοδοι µιας κλάσης συνεργάζονται αποτελεσµατικά προκειµένου να παρέχουν µια καλά ορισµένη συµπεριφορά στο αντικείµενο [ ΤΠ04]. Η συνοχή σχετίζεται µε την ενθυλάκωση και την απόκρυψη δεδοµένων, καθώς όσο µεγαλύτερη συνοχή έχει µια κλάση σε τόσο µεγαλύτερο βαθµό υπάρχει η αρχή αυτή και τόσο πιο καλά έχει υλοποιηθεί το εσωτερικό της κλάσης [ ΤΠ02]. Έλλειψη συνοχής ή χαµηλή συνοχή στην κλάση σηµαίνει αύξηση της πολυπλοκότητας [ ΤΠ02] και, άρα, της πιθανότητας σφαλµάτων κατά τη διαδικασία της ανάπτυξης [ ΤΠ03] και υποδεικνύει ότι η κλάση θα µπορούσε να διαιρεθεί σε δύο υποκλάσεις µε µεγαλύτερη συνοχή [ ΤΠ02], [ ΤΠ03]. Αντίθετα, υψηλή συνοχή σηµαίνει καλή υποδιαίρεση της κλάσης και αυτονοµία στη συµπεριφορά του αντικειµένου. Συνεπώς, η συνοχή επιδρά πάνω στην ανιχνευσιµότητα (traceability), στην τάση για λάθη (error proneness), στην πληρότητα (completeness), στη συνέπεια (consistency) και την αυτοπεριγραφικότητα (self-descriptiveness), την τµηµατικότητα (modularity) και την απλότητα (simplicity). Εποµένως, επηρεάζει τους ποιοτικούς παράγοντες υψηλότερου επιπέδου την αξιοπιστία (reliability), τη συντηρησιµότητα (maintainability) και την επαναχρησιµοποιησιµότητα (reusability). Συνδεσιµότητα (coupling) Αποτελεί ένα µέτρο του συνδέσµου ανάµεσα σε δύο οντότητες (κλάσεις) [ ΤΠ03]. Υπάρχουν τρεις τρόποι σύνδεσης µεταξύ κλάσεων: α) µέσω της ανταλλαγής µηνυµάτων, β) όταν µέθοδοι που δηλώνονται στη µια κλάση χρησιµοποιούν µεθόδους ή ιδιότητες της άλλης και γ) µέσω της κληρονοµικότητας, ιδιότητας που εισάγει ισχυρότατη σύνδεση [ ΤΠ04], [ ΤΠ05]. Η ύπαρξη ισχυρής σύνδεσης (coupling) ανάµεσα σε κλάσεις επιβαρύνει τον τµηµατοποιηµένο (modular) προγραµµατισµό και εµποδίζει την κλάση από το να 24

26 Μετρικές Ποιότητας Λογισµικού µπορεί να επαναχρησιµοποιηθεί [ ΤΠ03]. Μια ακόµα συνέπεια είναι η δυσκολία στην πραγµατοποίηση αλλαγών στο πρόγραµµα, καθώς οι αλληλεξαρτήσεις µεταξύ των κλάσεων δυσχεραίνουν τον εντοπισµό των κλάσεων που επηρεάζονται από τις αλλαγές και τον έλεγχο του τελικού κώδικα [ ΤΠ02]. Άρα, τα κριτήρια ποιότητας που επηρεάζονται από την σύνδεση µεταξύ κλάσεων (class coupling) είναι η ανιχνευσιµότητα (traceability), η συνέπεια (consistency), η ακρίβεια (consciseness), η απλότητα (simplicity), η τµηµατοποίηση (modularity) και η επεκτασιµότητα (expandability). Αυτά επιδρούν µε τη σειρά τους στην αξιοπιστία (reliability), στην ευκολία ελέγχου (testability) και στην επαναχρησιµοποιησιµότητα (reusability) του λογισµικού. Encapsulation Απόκρυψη Πληροφορίας (information hiding) Πρόκειται για την ιδιότητα των κλάσεων να αποκρύπτουν τις λεπτοµέρειες που υλοποιούν τη συµπεριφορά τους [ ΤΠ01]. Όσο περισσότερες µεθόδους διαθέτει η κλάση στις άλλες κλάσεις, δηλαδή όσο µικρότερη ενθυλάκωση υπάρχει, τόσο ισχυρότερη µπορεί να είναι η σύνδεση της κλάσης µε τις άλλες. Επιπλέον, η µικρή ενθυλάκωση υπονοεί µικρή συνοχή ανάµεσα στις µεθόδους της κλάσης. Ιεραρχία (hierarchy) Κληρονοµικότητα (inheritance) Είναι o µηχανισµός µε τον οποίο µια υποκλάση (subclass) κληρονοµεί µία ή περισσότερες υπερκλάσεις της (superclass) [ ΤΠ01]. Είναι, επίσης, ένας τρόπος επαναχρησιµοποίησης υπαρχόντων κλάσεων [ ΤΠ03], [ ΤΠ04]. Όσο χαµηλότερα στην ιεραρχία βρίσκεται µια κλάση τόσο µεγαλύτερο αριθµό µεθόδων κινδυνεύει να κληρονοµήσει, γεγονός που την καθιστά πιο πολύπλοκη [ ΤΠ03]. Γενικά, δέντρα µε µεγάλο βάθος δηλώνουν προβλήµατα στο σχεδιασµό του συστήµατος, αν και ταυτόχρονα σηµαίνουν ότι έχει γίνει επαναχρησιµοποίηση µεθόδων και ιδιοτήτων, πράγµα επιθυµητό. Ακόµη, οι κλάσεις µε µεγάλο αριθµό παιδιών απαιτούν περισσότερο χρόνο για να ελεγχθούν. Γενικά, µεγαλύτερο βάθος είναι πιο επιθυµητό από µεγαλύτερο πλάτος στο δένδρου, µιας και έτσι µπορεί να επιτευχθεί o επιθυµητός βαθµός επαναχρησιµοποιησιµότητας [ ΤΠ06]. Επίσης, οι κλάσεις δεν πρέπει να έχουν τον ίδιο αριθµό υποκλάσεων, ενώ οι κλάσεις που βρίσκονται υψηλότερα στην ιεραρχία πρέπει να έχουν περισσότερες υποκλάσεις από αυτές που βρίσκονται χαµηλότερα [ ΤΠ06]. Οι τελευταίες είναι πιο εξειδικευµένες και µε µικρή ευκολία επέκτασης. Τέλος, πολλαπλή κληρονοµικότητα επιδρά αρνητικά στο σχεδιασµό ενός συστήµατος [ ΤΠ07]. Συµπερασµατικά, η κληρονοµικότητα (inheritance) µπορεί να επιδράσει στην ανιχνευσιµότητα (traceability), την πληρότητα (completeness), την απλότητα (simplicity), την επεκτασιµότητα (expandability), την αυτοπεριγραφικότητα (selfdescriptiveness), τη συντηρησιµότητα (maintainability), την ευκολία ελέγχου (testability) και την επαναχρησιµοποιησιµότητα (reusability) του αντικειµενοστραφούς λογισµικού. 25

27 Μετρικές Ποιότητας Λογισµικού Αφαιρετκότητα (abstraction) Μηχανισµός που επιτρέπει στο σχεδιαστή λογισµικού να εστιάζει στις απαραίτητες λεπτοµέρειες ενός τµήµατος του λογισµικού (component) και να µην απασχολείται µε λεπτοµέρειες χαµηλού επιπέδου. Μετρικές Αντικειµενοστραφούς Λογισµικού Όπως και για τις µη-αντικειµενοστραφείς µετρικές, έτσι και για τις αντικειµενοστραφείς ο Roger Pressman [PRE97] χωρίζει τις µετρικές λογισµικού σε κατηγορίες, ανάλογα µε τη φάση ανάπτυξης του λογισµικού που εφαρµόζονται: στη φάση της ανάλυσης απαιτήσεων, του σχεδιασµού, της ανάπτυξης (µετρικές για τον πηγαίο κώδικα), του ελέγχου και της συντήρησης. Παράλληλα, όµως, οι µετρικές χωρίζονται σε: Μετρικές κλάσης (class-oriented metrics) Οι µετρικές της κατηγορίας αυτής ασχολούνται µε τις λειτουργίες (operations) και τα γνωρίσµατα (attributes) µίας κλάσης, τις σχέσεις της κλάσης µε τις υποκλάσεις και την κληρονοµικότητα, τις σχέσεις της κλάσης µε άλλες κλάσεις. Οι γνωστότερες µετρικές της κατηγορίας αυτής είναι: o o CK Metrics Suite [CHI94]: αποτελείται από έξι µετρικές: α) Weighted Methods per Class, β) Depth of the Inheritance Tree, γ) Number of Children, δ) Coupling between Object Classes, ε) Response for a Class και στ) Lack of Cohesion in Methods. Οι µέθοδοι αυτές αναλύονται στη συνέχεια. Metrics by Lorenz and Kidd [LOR94]: είναι ένα σύνολο µετρικών που προτάθηκαν από τους Lorenz και Kidd. Οι σηµαντικότερες από αυτές αναλύονται στη συνέχεια. Μετρικές λειτουργίας (operation-oriented metrics) Οι σηµαντικότερες µετρικές της κατηγορίας αυτής είναι [LOR94]: α) Average Operation Size, β) Operation Complexity και γ) Average Number of Parameter per operation. Ανάλυση αυτών ακολουθεί. Στη συνέχεια παρουσιάζονται ορισµένες µετρικές αντικειµενοστραφούς λογισµικού. Average Method Size [LOR94] Υπολογίζει το µέσο µήκος των µεθόδων ενός συστήµατος. Class Size [LOR94] Μετρά το µέγεθος µίας κλάσης. 26

28 Μετρικές Ποιότητας Λογισµικού Ορίζεται ως ο συνολικός αριθµός των λειτουργιών (total number of operations) ή ο συνολικός αριθµός των γνωρισµάτων (number of attributes). Class Cohesion [LOR94] Μετρά τη συνοχή µιας κλάσης, κάτι που καθορίζεται από τις σχέσεις µεταξύ των µεθόδων της. Class Coupling [LOR94], [CHI94] Μετρά τον αριθµό των κλάσεων που συνδέονται και το ποσό της σύνδεσης µιας κλάσης µε τις άλλες. Direct Class Coupling Μετρά το πλήθος των κλάσεων µε τις οποίες µια κλάση είναι συνδεδεµένη, συµπεριλαµβανοµένων και των κλάσεων που συνδέονται άµεσα µε δηλώσεις κοινών µεταβλητών και µεταβίβαση µηνυµάτων. Depth of the Inheritance Tree [CHI94] Ορίζεται ως το µέγιστο µήκος από τη ρίζα σε ένα κόµβο του δένδρου. Όσο µεγαλύτερο είναι το νούµερο αυτό, τόσο µεγαλύτερη είναι και η πολυπλοκότητα του συστήµατος. System Size in Classes Μετρά το συνολικό αριθµό των κλάσεων στο σύστηµα. Internal Privacy Αναφέρεται στη χρήση συναρτήσεων που ενεργούν πάνω στα στιγµιότυπα µιας κλάσης. Lack of Cohesion in Methods [FEN94], [CHI94] Η συνοχή µιας κλάσης ορίζεται από το πόσο στενά σχετίζονται οι τοπικές µέθοδοι της κλάσης µε τα τοπικά στιγµιότυπα των ιδιοτήτων της. Για µια κλάση η µετρική αυτή ορίζεται ως το πλήθος των µη επικαλυπτόµενων τοπικών µεθόδων της κλάσης. 27

29 Μετρικές Ποιότητας Λογισµικού Length of OO Program [FEN94] Η µέτρηση του µήκους του προγράµµατος βασίζεται στον αριθµός των κλάσεων και των µεθόδων που αυτό διαθέτει. Number of Independent Classes Μετρά τον αριθµό των κλάσεων που δεν ανήκουν σε κάποια ιεραρχία και δε κληρονοµούνται από καµία κλάση στο σύστηµα. Number of Multiple Inheritance Μετρά τον αριθµό των στιγµιότυπων που υπάρχει πολλαπλή κληρονοµικότητα. Number of Ancestors Μετρά τον αριθµό των διακριτών κλάσεων τις οποίες µια κλάση κληρονοµεί. Number of Children [CHI94] Ορίζεται ως ο αριθµός των υποκλάσεων από τις οποίες αποτελείται µία κλάση. Όσο µεγαλύτερος είναι ο αριθµός αυτός, τόσο εξασθενεί η αφαιρετικότητα της κλάσης-γονέα, ενώ αποδεικνύει ότι κάποιες υποκλάσεις δε θα πρέπει να θεωρούνται παιδιά της συγκεκριµένης κλάσης-γονέα. Number of Hierarchies Μετρά τον αριθµό των διακριτών ιεραρχιών κλάσεων στο σύστηµα. Number of Inline Methods Μετρά τον αριθµό των inline µεθόδων µιας κλάσης. A Class Total Number of All Methods Μετρά το συνολικό αριθµό µεθόδων σε µια κλάση. Percent of Potential Method uses actually reused Ορίζεται ως PP = (αριθµός πραγµατικών συνολικών χρήσεων µεθόδου) / (αριθµός πιθανών χρήσεων της µεθόδου) 28

30 Μετρικές Ποιότητας Λογισµικού Ratio of Methods per Class Μετρά τον αριθµό των µεθόδων ανά κλάση. Total Method Size Μετρά το συνολικό µέγεθος µιας κλάσης, αθροίζοντας το µέγεθος των µεθόδων της. Weighted Class Size Ορίζεται ως weighted class size = Number Of Ancestors + Total Method Size Weighted Methods per Class [CHI94] Ορίζεται ως το άθροισµα της πολυπλοκότητας των µεθόδων µίας κλάσης και υπολογίζεται από τον τύπο: WMC = Σ c i όπου c i η πολυπλοκότητα της µεθόδου i. Response for a Class [CHI94] Ορίζεται ως ο αριθµός των µεθόδων σε ένα response set, το οποίο είναι το σύνολο των µεθόδων που µπορεί να εκτελεστεί σε απάντηση ενός µηνύµατος που έχει σταλεί από ένα αντικείµενο της κλάσης. Όσο αυξάνει ο αριθµός των µεθόδων σε ένα response set, τόσο αυξάνεται και η πολυπλοκότητα της κλάσης. Average Operation Size [LOR94] Ορίζονται ως ο αριθµός των µηνυµάτων που στέλνονται από µία λειτουργία. Όταν ο αριθµός αυτός αυξάνεται, σηµαίνει ότι δεν έχει γίνει καλή κατανοµή των υποχρεώσεων εσωτερικά στην κλάση. Operation Complexity [LOR94] Μετρά την πολυπλοκότητα µία λειτουργίας το νούµερο αυτό πρέπει να κρατάται χαµηλό. 29

31 Μετρικές Ποιότητας Λογισµικού Average Number of Parameters per Operation [LOR94] Ορίζεται ως ο αριθµός των παραµέτρων για µία λειτουργία. Για να µην υπάρχει µεγάλη πολυπλοκότητα µεταξύ των αντικειµένων (objects), θα πρέπει ο αριθµός αυτός να είναι µικρός. Μεταµετρικές Αντικειµενοστραφούς Λογισµικού Για την επιλογή των µεταµετρικών αξιολόγησης των µετρικών αντικειµενοστραφούς λογισµικού χρησιµοποιούνται ιδιότητες που αναφέρονται σε µη-αντικειµενοστραφές λογισµικό και έχουν περιγραφεί στην παράγραφο Μεταµετρικές Λογισµικού αλλά και κάποιες που σχετίζονται µε την αντικειµενοστράφεια. Οι σηµαντικότερες µεταµετρικές συνοψίζονται στις εξής: κλίµακα µέτρησης ασφάλεια στην ανάθεση τιµών της µετρικής αυτοµατοποιησιµότητα σηµασία της υλοποίησης µονοτονία απλότητα ακρίβεια 30

32 Μετρικές Ποιότητας Λογισµικού ιασφάλιση Ποιότητας Λογισµικού Η ποιότητα, τα µοντέλα ποιότητας και οι µετρικές δε θα είχαν γίνει αποδεκτά, εάν δεν µπορούσαν να χρησιµοποιηθούν στην πράξη, κατά την ανάπτυξη ενός προϊόντος λογισµικού. Το ρόλο της επιλογής των εξωτερικών ποιοτικών χαρακτηριστικών του προϊόντος και την ανάπτυξη των κατάλληλων µετρικών για τον έλεγχό τους αναλαµβάνει το πρόγραµµα διασφάλισης ποιότητας. Ένα πρόγραµµα διασφάλισης ποιότητας καθορίζεται βάσει κάποιου γενικού προτύπου (standard) και παρέχει οδηγίες για την εφαρµογή του. Τέτοια πρότυπα είναι το ISO 9000 [KIM89], τα IEEE standards, τα βραβεία Baldridge και το Capability Maturity Model (CMM) [ΞΕΝ96], τα οποία από τη µία ενθαρρύνουν την εφαρµογή µετρήσεων (ανάπτυξη µετρικών) πάνω σε ορισµένα χαρακτηριστικά του λογισµικού, από την άλλη, όµως, δεν προτείνουν συγκεκριµένες λύσεις για τον τρόπο διεξαγωγής των µετρήσεων αυτών. Στόχος ενός προγράµµατος διασφάλισης ποιότητας είναι η διασφάλιση: α) της ποιότητας των διαδικασιών, β) της ποιότητας του έργου και γ) της ποιότητας του τελικού προϊόντος. Η τελευταία, µάλιστα, αποτελεί και τον κύριο στόχο ενός προγράµµατος διασφάλισης ποιότητας, µιας και µέσω αυτής ικανοποιούνται έµµεσα και οι άλλοι δύο. Ένα πρόγραµµα διασφάλισης ποιότητας εξειδικεύει τις δοµές, τις δραστηριότητες, τις αρµοδιότητες, τις διαδικασίες, τους πόρους, τις µετρικές και τα εργαλεία µέτρησης που θα χρησιµοποιηθούν από µία εταιρία παραγωγής λογισµικού και µε βάση το αποτέλεσµα αυτών συντάσσεται το εγχειρίδιο ποιότητας. Τα ειδικά ποιοτικά χαρακτηριστικά που ενδιαφέρουν κάθε έργο και οι αντίστοιχες µετρικές περιγράφονται στο πλάνο διασφάλισης ποιότητας, το οποίο είναι χωριστό για κάθε έργο λογισµικού και αναφέρεται στις ιδιαιτερότητες του έργου αυτού. Στο πλάνο διασφάλισης ποιότητας ορίζεται για κάθε έργο και η ελάχιστη αποδεκτή ποιότητα, ως το σύνολο των ποιοτικών χαρακτηριστικών που θα πρέπει να βρίσκονται οπωσδήποτε πάνω από κάποια όρια, ανεξάρτητα από τα υπόλοιπα χαρακτηριστικά στα οποία δίνεται έµφαση [ΞΕΝ96]. Η διασφάλιση ποιότητας είναι µία διαδικασία που αφορά σε όλη την εταιρία παραγωγής λογισµικού από τον υπεύθυνο έργου (project manager) που θα ασχοληθεί µε τον καθορισµό των ποιοτικών χαρακτηριστικών του προϊόντος, µέχρι και τον προγραµµατιστή που θα πρέπει να εισάγει σαφή σχόλια στον κώδικά του [INC95]. Μέχρι πριν κάποιες δεκαετίες η διαδικασία διασφάλιση ποιότητας του λογισµικού ήταν άγνωστη. Σήµερα, κυρίως λόγο της κρίσης του λογισµικού και του µεγάλου ανταγωνισµού µεταξύ των εταιριών παραγωγής του, η διαδικασία αυτή εισάγεται σε όλες εταιρίες, παρά το γεγονός ότι αντιµετωπίζεται ως κουραστική και χωρίς νόηµα. Στην πραγµατικότητα όµως [INC95], [SCH95], [BAC94], τα πλεονεκτήµατα φαίνονται όχι µόνο µακροπρόθεσµα, αλλά και βραχυπρόθεσµα τόσο για την εταιρία όσο και για τους εργαζόµενους. 31

33 Μετρικές Ποιότητας Λογισµικού Μέθοδοι ιεξαγωγής Μετρήσεων Ποιότητας Λογισµικού Βασικότερος στόχος µίας εταιρίας ανάπτυξης λογισµικού είναι να εξασφαλιστεί η ποιότητα του τελικού προϊόντος που, εκτός του ότι προσφέρει ικανοποίηση του χρήστη ως προς το προϊόν αυτό, έµµεσα εξασφαλίζει την ποιότητα του έργου και των διαδικασιών. Προκειµένου, όµως, να εξασφαλιστεί η ποιότητα του τελικού προϊόντος πρέπει οι µετρικές που θα επιλεχθούν να αφορούν σε αυτό. Όπως αναφέρθηκε και στην αντίστοιχη ενότητα (Μετρήσεις και Μετρικές), οι µετρικές που θα πρέπει να αναπτυχθούν είναι δύο κατηγοριών: εσωτερικές και εξωτερικές. Οι εσωτερικές µετρικές που αφορούν στον αριθµό γραµµών του κώδικα, το χρόνο εκτέλεσής του, τα λάθη του κλπ είναι άµεσα αυτοµατοποιήσιµες και εποµένως µπορούν να υλοποιηθούν, ώστε να δώσουν αντικειµενικά αποτελέσµατα για καθορισµένα χαρακτηριστικά του λογισµικού. Ορισµένες µέθοδοι διεξαγωγής µετρήσεων ποιότητας χρησιµοποιώντας τις εσωτερικές µετρικές είναι: Μετρικές λογισµικού του Halstead, που µετρούν αριθµήσιµα στοιχεία του λογισµικού και σχετίζονται µε το µέγεθος του πηγαίου κώδικα αριθµός γραµµών, αριθµός τελεστών, αριθµός εντέλων [HAL75]. Μετρική κυκλωµατική πολυπλοκότητας, που εξετάζει το γράφο ροής του προγράµµατος [MCB76]. Μετρική πολυπλοκότητας δοµών δεδοµένων του Tsai, που εφαρµόζεται στα δεδοµένα του προγράµµατος πριν την τελική έκδοση του πηγαίου κώδικα [TSA86]. Μετρικές που υπολογίζουν το ποσοστό των σχολίων του πηγαίου κώδικα, εξάγοντας έτσι συµπεράσµατα για το εάν ο κώδικας είναι επαρκώς σχολιασµένος, ποιες µέθοδοι-συναρτήσεις είναι πιο πολύπλοκες κλπ. Μετρικές McCabe, χρησιµοποιώντας τα αποτελέσµατα για εξαγωγή συµπερασµάτων για το ποιες συναρτήσεις είναι πιο πολύπλοκες και εάν αυτές µπορούν να διαιρεθούν για να γίνουν πιο απλές κλπ. Συνδυασµό των ανωτέρω µετρικών, για παράδειγµα, συναρτήσεις που παρουσιάζουν υψηλό McCabe και για κάποιο λόγο δε µπορούν να διαιρεθούν, θα πρέπει να έχουν επαρκές ποσοστό σχολίων. Οι εξωτερικές µετρικές που αφορούν στη λειτουργικότητα, την πολυπλοκότητα, την αποτελεσµατικότητα, την αξιοπιστία και τη συντηρησιµότητα του λογισµικού είναι, βέβαια, πιο κοντά στην έννοια της ποιότητας και µετρούν το βαθµό στον οποίο ο χρήστης είναι ευχαριστηµένος από το προϊόν, αλλά δεν είναι αυτοµατοποιήσιµες ούτε προσφέρουν αντικειµενικά κριτήρια ώστε τα αποτελέσµατά τους να είναι άµεσα ερµηνεύσιµα. 32

34 Μετρικές Ποιότητας Λογισµικού Οι µέθοδοι διεξαγωγής µετρήσεων ποιότητας βάσει των εξωτερικών µετρικών χωρίζονται σε τρεις κατηγορίες [ABO00]: Αναλυτικές µέθοδοι (analytic methods) Οι αναλυτικές µέθοδοι εκτελούνται στο εργαστήριο χωρίς τη συµµετοχή χρηστών. Στηρίζονται είτε σε θεωρητικά µοντέλα προσοµοίωσης της συµπεριφοράς των χρηστών είτε σε πρότυπα και κανόνες. Γνωστότερες είναι: α) γνωσιακό περιδιάβασµα (cognitive walkthroughs), β) πολλαπλό περιδιάβασµα (pluralistic walkthrough), γ) ευριστική αξιολόγηση (heuristic evaluation), δ) επιθεώρηση συνέπειας (consistency inspection), ε) επιθεώρηση προτύπων-τυποποίησης (standards inspection), στ) επίσηµη επιθεώρηση ευχρηστίας (formal usability inspections), ζ) λίστες ελέγχου µέσω οδηγών (guideline checklists). Πειραµατικές µέθοδοι (experimental methods) Με τις πειραµατικές µεθόδους οι µετρήσεις διεξάγονται µέσα στο εργαστήριο µε τη συµµετοχή των τελικών χρηστών και αξιολογητών που παρακολουθούν και σηµειώνουν τις ενέργειες των χρηστών. Βασικότερες είναι: α) µέτρηση απόδοσης (performance measurement), β) πρωτόκολλα οµιλούντων υποκειµένων-χρηστών (thinking aloud protocol) και γ) µέθοδοι καταγραφής ενεργειών υποκειµένωνχρηστών. ιερευνητικές µέθοδοι (inquiry methods) Οι διερευνητικές µέθοδοι πραγµατοποιούνται εκτός εργαστηρίου µε τη συµµετοχή των τελικών χρηστών. Αυτές είναι: α) συνεντεύξεις υποκειµένων-χρηστών (user interviews), β) οµαδική αξιολόγηση (focus groups), γ) συµπλήρωση ερωτηµατολογίων (questionnaires), δ) αυτόµατη καταγραφή συνεδρίας (journal session), ε) παρατήρηση πεδίου (field observation), στ) έρευνα προσανατολισµένη στο περιεχόµενο (contextual inquiry) και ζ) καταγραφή προσωπικών ενεργειών σε αρχείο από τον ίδιο το χρήστη (self reporting logs). 33

35 Μετρήσεις σε Λογισµικό Αλληλεπίδρασης µε Βάση εδοµένων Κεφάλαιο 4 Μετρήσεις σε Λογισµικό Αλληλεπίδρασης µε Βάση εδοµένων Στο κεφάλαιο αυτό περιγράφεται ο πηγαίος κώδικας που θα µετρηθεί. Αναλύονται οι στόχοι για την πραγµατοποίηση των µετρήσεων, που σχετίζονται µε τη επαναχρησιµοποιησιµότητα και τη συντηρησιµότητα του λογισµικού. Τέλος, γίνεται µία αναφορά στο εργαλείο µετρήσεων που θα χρησιµοποιηθεί και στους λόγους για τους οποίους το εργαλείο αυτό είναι κατάλληλο, βάσει των στόχων που έχουν τεθεί. Περιγραφή Λογισµικού Αλληλεπίδρασης µε Βάση εδοµένων Το λογισµικό αλληλεπίδρασης µε τη Βάση εδοµένων αποτελεί ένα τµήµα ενός πληροφοριακού συστήµατος. Το Πληροφοριακό Σύστηµα Το σύστηµα αποτελεί µία multi-tier εφαρµογή και χωρίζεται σε τρία βασικά τµήµαταεπίπεδα: Βάση εδοµένων (Β ) Επίπεδο αριθµητικών και λογικών πράξεων και ελέγχων και αλληλεπίδρασης µε τη Β (backend) Επίπεδο διεπαφής µε το χρήστη και αρχικού ελέγχου συσχετίσεων δεδοµένων (frontend) Κάθε ένα από τα επίπεδα αυτά είναι καλά δοµηµένο και έχει αυστηρά καθορισµένες και διακριτές λειτουργίες, ώστε να διευκολύνεται η ανάπτυξή του µε την ανάλυσή του σε επιµέρους διακριτές εργασίες. Σε κάθε ένα από τα τρία επίπεδα είναι απαραίτητο ένα υπο-επίπεδο (layer) που αφορά στην µεταξύ τους επικοινωνία, δίνοντας τη δυνατότητα στον προγραµµατιστή να θεωρεί τα υπόλοιπα επίπεδα ως µαύρα κουτιά. Στην Εικόνα 4.1 φαίνονται τα διαφορετικά επίπεδα του συστήµατος και η επικοινωνία µεταξύ τους. 34

36 Μετρήσεις σε Λογισµικό Αλληλεπίδρασης µε Βάση εδοµένων Εικόνα 4.1 Τα επίπεδα του πληροφοριακού συστήµατος Οι χρήστες µέσω ενός φυλλοµετρητή (web browser) και χρησιµοποιώντας το πρωτόκολλο για ασφαλή διαδικτυακή επικοινωνία, το https είναι ουσιαστικά το http που χρησιµοποιεί τεχνολογίες κρυπτογράφησης και πιστοποίησης (SSL Secure Socket Layer) συνδέονται στο επίπεδο του συστήµατος που ευθύνεται για την παρουσίαση και τη λήψη της πληροφορίας, το frontend. Το frontend επεξεργάζεται και ελέγχει την πληροφορία και την παραδίδει στο επίπεδο που είναι υπεύθυνο για την περαιτέρω επεξεργασία, τις αριθµητικές και λογικές πράξεις και ελέγχους, και την καταγραφή της στη Β, που είναι και το τρίτο επίπεδο του συστήµατος. Για τη Β έχει χρησιµοποιηθεί Oracle, ενώ οι διαφορετικές Β έχουν υλοποιηθεί ως διαφορετικά σχήµατα (schemas) στην ίδια Β. Αφού το backend αλληλεπιδράσει µε τη Β, επιστρέφει την απάντηση-πληροφορία στο frontend. Η επικοινωνία frontend-backend γίνεται µε ανταλλαγή εγγράφων XML χρησιµοποιώντας το πρωτόκολλο http. Το Επίπεδο Backend Το backend, λοιπόν, είναι ένα υποσύστηµα χωρίς µνήµη που προσφέρει ένα σύνολο υπηρεσιών έχουν ονοµαστεί actions. Το backend έχει αναπτυχθεί σε γλώσσα αντικειµενοστραφούς προγραµµατισµού Java [ ΤΠ08.1] και χρησιµοποιεί τεχνολογία servlet [ ΤΠ08.2]. Ο servlet container που χρησιµοποιείται όταν το σύστηµα βρίσκεται σε κανονική λειτουργία είναι ο Tomcat [ ΤΠ08.3], ενώ για την ανάπτυξη χρησιµοποιείται ο Jetty [ ΤΠ08.4]. Για τη 35

37 Μετρήσεις σε Λογισµικό Αλληλεπίδρασης µε Βάση εδοµένων µεταγλώττιση του πηγαίου κώδικα χρησιµοποιείται το Java Development Kit [ ΤΠ08.5] και το εργαλείο Ant [ ΤΠ08.6]. Για το backend έχει υλοποιηθεί η βασική υποδοµή, ώστε να είναι εύκολη η δηµιουργία ενός νέου action, ακόµη και µε τρόπο που δε χρειάζεται προγραµµατισµός σε Java. Τα actions περιγράφονται µε XML έγγραφα [ ΤΠ08.7] που ονοµάζονται pages. Σε αυτά δηλώνεται το όνοµα του action, οι παράµετροι που δέχεται ως είσοδο από το frontend, οι λειτουργίες που θα εκτελέσει και το template αρχείο που θα χρησιµοποιηθεί για την κατάλληλη διαµόρφωση της απάντησης προς το frontend. Το κείµενο της απάντησης που είναι και αυτό ένα XML έγγραφο διαµορφώνεται µε µία µηχανή template, τη Velocity [ ΤΠ08.8]. Για λόγους αναγνωσιµότητας και συντηρησιµότητας τα pages βρίσκονται σε φακέλους µε όνοµα αντιπροσωπευτικό για τη λειτουργία που εκτελούν. Για την καλύτερη κατανόηση της λειτουργίας των κλάσεων που εκτελούν τα actions, δίνεται ένα παράδειγµα που στέλνεται για την εισαγωγή των χρηστών στο σύστηµα. <?xml version="1.0" encoding="iso "?> <page name="main.select_user.select" template="users/main.select_user.select.vm" classname="hercules.core.service.simpleservice"> <action name ="request" classname="hercules.core.providers.web.requestaction"> <xpath> <xparam param="login" xquery="//singlefield[@id='user_name']/value/@data"/> <xparam param="typestring" xquery="//singlefield[@id='epipedo_search']/value/@data"/> </xpath> </action> <action name="select" classname="ypepth.users.actions.selectusers"/> </page> Στο root element της XML δηλώνεται το όνοµα, στο tag name, της λειτουργίας, στην περίπτωση του παραδείγµατος είναι main.select_user.select, που την προσδιορίζει µοναδικά. Το template attribute καθορίζει το template που θα χρησιµοποιηθεί για τη διαµόρφωση της απάντησης στο frontend. Στο classname attribute του XML εγγράφου δηλώνεται η κλάση στο παράδειγµα αυτό έχει δηλωθεί η hercules.core.service.simpleservice, ενώ υπάρχει και η hercules.core.service.proxyservice που χρησιµεύει για να δηλωθεί το action ως proxy σε ένα άλλο που ουσιαστικά επιτελεί την εκτέλεσή του που θα αναλάβει να διεκπεραιώσει το συγκεκριµένο service, δηλαδή ό,τι περιέχεται στα action elements του XML εγγράφου. Οι κλάσεις που ορίζονται στο classname element του action tag είναι δύο ειδών: α) κλάσεις υποδοµής. β) κλάσεις που δηµιουργούνται εξ ολοκλήρου σε Java για να εξυπηρετήσουν συγκεκριµένους σκοπούς. 36

38 Μετρήσεις σε Λογισµικό Αλληλεπίδρασης µε Βάση εδοµένων Κλάσεις Υποδοµής Εκτέλεσης των Actions Οι κλάσεις υποδοµής είναι ήδη υλοποιηµένες και παρέχουν γενικού τύπου υπηρεσίες και ενέργειες. Οι κλάσεις αυτές δηλώνονται στο XML έγγραφο στο tag του action και αναλαµβάνουν να αναλύσουν τις τιµές που στέλνονται από το frontend και να τις εισάγουν στο context χρησιµοποιώντας το xpath [ ΤΠ08.9]. Στο παράδειγµα έχει δηλωθεί η hercules.core.providers.web.requestaction κλάση. Άλλες Κλάσεις Εκτέλεσης των Actions Εκτός από τις κλάσεις υποδοµής, µπορεί ο προγραµµατιστής να ορίζει και να υλοποιήσει επιπλέον κλάσεις για τη διαχείριση των XML εγγράφων που στέλνονται από το frontend. Το µοντέλο που έχει ακολουθηθεί είναι δύο επιπέδων: α) τα αντικείµεναactions που επεξεργάζονται τα εισερχόµενα δεδοµένα και που σχηµατίζουν την τελική απάντηση που αποστέλλεται στο frontend και β) τα αντικείµενα που παρέχουν µία σειρά από υπηρεσίες, µε τη µορφή µεθόδων, στα actions του πρώτου επιπέδου. Τα αντικείµενα του δευτέρου επιπέδου ονοµάζονται Data Access Object (DAO). Για κάθε υπηρεσία του συστήµατος δηµιουργείται µια DAO κλάση που περιέχει όλες τις απαραίτητες µεθόδους για την υπηρεσία. Το DAO αντικείµενο είναι αυτό που επικοινωνεί µε τη Β, εκτελεί τα ερωτήµατα ή τις συναρτήσεις που έχουν υλοποιηθεί στη Β της Oracle και επιστρέφει τα αποτελέσµατα. Το DAO αντικείµενο γνωρίζει τους πίνακες και τα sql ερωτήµατα που πρέπει να εκτελεστούν στη Β, κάτι που είναι άγνωστο και δε χρειάζεται να γνωρίζει το πρώτο επίπεδο. Με τον τρόπο αυτό, οποιαδήποτε αλλαγή σε κάποιο σχήµα της Β, αφήνει ανέπαφες τις κλάσεις των actions και επηρεάζει µόνο τις κλάσεις DAO. DAO µέθοδοι και TO αντικείµενα Οι µέθοδοι που βρίσκονται σε µία DAO κλάση εκτελούν α) τα sql ερωτήµατα και β) τις συναρτήσεις στη Β. Το παράδειγµα που ακολουθεί είναι το sql ερώτηµα για τον έλεγχο του ονόµατος χρήστη και του κωδικού πρόσβασης το ερώτηµα αυτό εκτελείται µε βάση τα δεδοµένα που στέλνονται από το frontend µε το XML έγγραφο του προηγούµενου παραδείγµατος. public Vector selectusers(string type) throws Exception { Vector params = new Vector(); String query = "select u.id_user as iduser, u.login, u.password,"+ "u.kodikos,u.counter, t.type as typestring" + "from lu_user u,lu_type t where u.type<>6 and t.type=? and t.id_type=u.type"; params.addelement(type); return service.executequery( 37

39 Μετρήσεις σε Λογισµικό Αλληλεπίδρασης µε Βάση εδοµένων } query,params,new BeanRsHandler("ypepth.users.data.UserTO")); Η µέθοδος executequery εκτελεί το ερώτηµα στη Β και δέχεται ως όρισµα το string query, το sql ερώτηµα, ένα Vector µε τις παραµέτρους για να εκτελεστεί το ερώτηµα στη Β, στο sql ερώτηµα φαίνονται ως ερωτηµατικά?, και ένα BeanRsHandler, αντικείµενο που δηµιουργείται για ένα TO αντικείµενο. Η µέθοδος αυτή επιστρέφει ένα Vector µε TO αντικείµενα µε τα πεδία τους συµπληρωµένα µε τις τιµές που έχουν επιστραφεί από το sql ερώτηµα που εκτελέστηκε στη Β. Για την εκτέλεση των συναρτήσεων της Β, χρησιµοποιούνται DAO µέθοδοι, όπως αυτή του παρακάτω παραδείγµατος: public int insertuser(userto user,string login) throws Exception { String function = "{?=call F_INS_USER(?,?,?)}"; Vector params = new Vector(); params.addelement(user.getkodikos()); params.addelement(user.gettypestring()); params.addelement(login); int result = service.executefunction(function,params); if (result==-1) { throw new Exception(function+" returned -1"); } return result; } Για να εκτελεστεί η συνάρτηση F_INS_USER (συνάρτηση υλοποιηµένη στην Β Oracle), που ορίζεται στο string function, χρησιµοποιείται η µέθοδος executefunction και οι παράµετροι που ορίζονται στα params. Οι µέθοδοι των DAO αντικειµένων δεν κάνουν διαχείριση των εξαιρέσεων (exceptions). Αν προκύψει, την επιστρέφουν στο action που κάλεσε τη µέθοδο και αυτό αναλαµβάνει είτε να καταγράψει το λάθος σε ένα logfile είτε να στείλει στο frontend ένα µήνυµα λάθους για να προβληθεί στο χρήστη είτε να ακυρώσει την ενέργεια (transaction) µε τη Β εκτελείται µία εντολή rollback στην Oracle. Ένα άλλο σηµείο αφαίρεσης είναι η χρήση των Table Objects (TO). Τα αντικείµενα αυτά έχουν µεταβλητές και µεθόδους πρόσβασης που θέτουν και λαµβάνουν τις τιµές των µεταβλητών, getters και setters. TO αντικείµενα χρησιµοποιούνται στο προηγούµενο παράδειγµα (getkodikos()και gettypestring()). 38

40 Μετρήσεις σε Λογισµικό Αλληλεπίδρασης µε Βάση εδοµένων Σύνδεση µε τη Βάση εδοµένων Για τη σύνδεση του backend µε τη Β, υπάρχει ένα XML έγγραφο στο οποίο ορίζονται όλες οι συνδέσεις µε τα διάφορα σχήµατα της Β. Έτσι, οποιαδήποτε αλλαγή σε σχήµα της Β ή στην υλοποίηση, απαιτεί τροποποίηση µόνο του συγκεκριµένου XML εγγράφου. Logging των Χρηστών Για το logging των χρηστών στο σύστηµα χρησιµοποιούνται οι κλάσεις του Jakarta project του Apache Foundation [ ΤΠ08.10]: import org.apache.commons.logging.log; import org.apache.commons.logging.logfactory; Με τον τρόπο αυτό, υπάρχει η δυνατότητα καταγραφής σε logfile είτε σε επίπεδο debug χρησιµοποιείται κατά την ανάπτυξη είτε σε επίπεδο απλής καταγραφής λαθών (errors) χρησιµοποιείται κατά την κανονική λειτουργία. Απάντηση στο Επίπεδο frontend Για να επιστραφεί η πληροφορία στο frontend πρέπει να σχηµατιστεί η απάντηση σε κατάλληλη µορφή, κάτι που γίνεται µε τη Velocity. Με την ολοκλήρωση όλων των actions, η Velocity βρίσκει το template που έχει δηλωθεί στο page που εκτελέστηκε, γεµίζει τις τιµές των πεδίων µε αυτές που υπάρχουν στο context και σχηµατίζει την τελική απάντηση, ένα XML έγγραφο, που αποστέλλεται στο frontend. Τα templates είναι γραµµένα σε macros της Velocity Template γλώσσας. 39

41 Μετρήσεις σε Λογισµικό Αλληλεπίδρασης µε Βάση εδοµένων Στόχοι των Μετρήσεων Οι µετρήσεις πραγµατοποιούνται στο τµήµα του backend, το επίπεδο αριθµητικών και λογικών πράξεων και ελέγχων και αλληλεπίδρασης µε τη Β, που περιγράφηκε στην αντίστοιχη ενότητα (Περιγραφή Λογισµικού Αλληλεπίδρασης µε Βάση εδοµένων). Επειδή το backend αποτελείται από ένα πυρήνα που υλοποιεί τη λογική του επιπέδου και ως προς τις πράξεις και τους ελέγχους και ως προς τη σύνδεση µε τη Β και από επιπλέον αρχεία πηγαίου κώδικα που υλοποιούν τους περιορισµούς και την εκτέλεση των ερωτηµάτων και των συναρτήσεων µε τη Β για το συγκεκριµένο σύστηµα για το οποίο υλοποιήθηκε ενδιαφέρον παρουσιάζει ο βαθµός στον οποίο το σύστηµα είναι συντηρήσιµο και επαναχρησιµοποιήσιµο. Αυτός είναι και ο στόχος των µετρήσεων που διεξάγονται στο λογισµικό αυτό. Πιο συγκεκριµένα, τα αναµενόµενα συµπεράσµατα που πρόκειται να εξαχθούν από την ανάλυση των µετρήσεων πρέπει να απαντούν σε ερωτήσεις όπως: Πόσο είναι το µέγεθος όλου του πηγαίου κώδικα; Πόσο από αυτό αντιστοιχεί σε σχόλια και πόσο είναι καθαρός κώδικας; Πόσο είναι το ποσοστό των σχολίων στα αρχεία του πηγαίου κώδικα; Πόσο είναι το ποσοστό των σχολίων σε αρχεία που έχουν µεγάλο µέγεθος; Ποια η µορφή των σχολίων; Σε τι ποσοστό ο πηγαίο κώδικας χρησιµοποιεί αντικειµενοστραφή χαρακτηριστικά; Πόσες είναι η συναρτήσεις που έχουν τα αρχεία του πηγαίου κώδικα; Πόσες είναι οι κλάσεις και οι µέθοδοι; Πόσες είναι οι µέθοδοι που υλοποιούνται στις κλάσεις; Ποιο το µέγεθος σε χαρακτήρες των συναρτήσεων, κλάσεων και µεθόδων; Ποιο είναι το αποτέλεσµα της µετρικής του McCabe σε αρχεία του πηγαίου κώδικα και σε συναρτήσεις, κλάσεις, µεθόδους των αρχείων; Ποιο είναι το ποσοστό των σχολίων σε αρχεία που η µετρική του McCabe έχει υψηλό αποτέλεσµα, δηλαδή η πολυπλοκότητα του πηγαίου κώδικα είναι µεγάλη, και σε αρχεία που έχει χαµηλό αποτέλεσµα, η πολυπλοκότητα δηλαδή είναι µικρή; Πόσο είναι το µέγεθος των συναρτήσεων, κλάσεων, µεθόδων που εµφανίζουν υψηλή τιµή στη µετρική McCabe; Πόσο είναι το µέγεθος των αρχείων και το ποσοστό των σχολίων όταν υπάρχουν τέτοιες συναρτήσεις, κλάσεις, µέθοδοι; Από τα αποτελέσµατα των µετρήσεων που διεξάγονται για την απάντηση των παραπάνω ερωτήσεων, αλλά και µε το συνδυασµό των αποτελεσµάτων αυτών φαίνεται α) κατά πόσο το επίπεδο backend µπορεί να ενσωµατωθεί σε άλλο πληροφοριακό σύστηµα που συνδέεται µε Β και σε τι βαθµό πρέπει να γίνουν τροποποιήσεις στον πηγαίο κώδικα, ώστε κάτι τέτοιο να µπορεί να γίνει άµεσα και β) κατά πόσο το επίπεδο backend είναι εύκολα συντηρήσιµο στο υπάρχον πληροφοριακό σύστηµα. 40

42 Μετρήσεις σε Λογισµικό Αλληλεπίδρασης µε Βάση εδοµένων Εργαλείο Πραγµατοποίησης των Μετρήσεων Το εργαλείο πραγµατοποίησης των µετρήσεων είναι το Metrics v2.0, που αναπτύχθηκε στα πλαίσια διπλωµατικών προπτυχιακών και µεταπτυχιακών του τµήµατος Μηχανικών Η/Υ & Πληροφορικής [ΛΙΑ02], [ΠΑΠ02], [ΓΕΩ05]. Το εργαλείο αυτό επιλέχθηκε, γιατί δίνει τη δυνατότητα µετρήσεων που αφορούν στον πηγαίο κώδικα, άρα είναι άµεσα αυτοµατοποιήσιµες και παρέχουν αποτελέσµατα που µπορούν να αναλυθούν µε αντικειµενικά κριτήρια. Οι µετρικές που έχουν ενσωµατωθεί στο εργαλείο και χρησιµοποιούνται στις µετρήσεις είναι α) size and complexity και β) object-oriented. Μιας και το λογισµικό είναι γραµµένο εξ ολοκλήρου σε Java, το εργαλείο αυτό µπορεί να µετρήσει και χαρακτηριστικά που αφορούν γενικά τη συγγραφή κώδικα, µε τις size and complexity µετρικές, αλλά και χαρακτηριστικά αντικειµενοστραφούς προγραµµατισµού, µε τις object-oriented µετρικές. Το εργαλείο έχει φιλική διεπαφή µε το χρήστη, µπορεί να εξάγει αποτελέσµατα σε πολλά αρχεία ταυτόχρονα και δίνεται η δυνατότητα επιλογής εξαγωγής µετρήσεων βάσει ενός υποσυνόλου ή όλου του συνόλου των µετρικών (Εικόνα 4.2). Εικόνα 4.2 Το εργαλείο πραγµατοποίησης των µετρήσεων, Metrics v2.0 41

43 Μετρήσεις σε Λογισµικό Αλληλεπίδρασης µε Βάση εδοµένων Με το κουµπί προσθήκης αρχείου µπορούν να προστεθούν αρχεία συγκεκριµένου τύπου στην περίπτωση αυτή είναι αρχεία.java αλλά και να αφαιρεθούν από το αντίστοιχο κουµπί αφαίρεσης αρχείων. Μετρικές του Εργαλείου Για µετρήσεις πάνω στον πηγαίο κώδικα επιλέγεται ένα µέρος ή όλες οι µετρικές της κατηγορίας size and complexity, ενώ για µετρήσεις που σχετίζονται καθαρά µε αρχές αντικειµενοστραφούς προγραµµατισµού επιλέγεται ένα µέρος ή όλες οι µετρικές της κατηγορίας object-oriented. Οι µετρικές που χρησιµοποιούνται για τις µετρήσεις στο λογισµικό αλληλεπίδρασης µε τη Β είναι: size and complexity metrics code characters Μετρά τον αριθµό των χαρακτήρων του καθαρού κώδικα. comment characters Μετρά τον αριθµό των χαρακτήρων των σχολίων στον πηγαίο κώδικα. total characters Μετρά τον αριθµό των συνολικών χαρακτήρων του αρχείου καθαρός κώδικας και σχόλια. code % Υπολογίζει το ποσοστό του καθαρού κώδικα στο αρχείο. comments % Υπολογίζει το ποσοστό των σχολίων στο αρχείο. function count Μετρά τον αριθµό των συναρτήσεων στο αρχείο. Οι συναρτήσεις είναι αυτές που έχει δηµιουργήσει ο ίδιος ο προγραµµατιστής και το σώµα τους βρίσκεται στο αρχείο που γίνεται η µέτρηση. average module length Μετρά το µέσο µήκος των τµηµάτων (modules) σε ένα αρχείο. Ως modules ορίζονται τα τµήµατα που θεωρούνται ανεξάρτητα από το υπόλοιπο πρόγραµµα του αρχείου, δηλαδή εκτελούν εργασία που δε σχετίζεται µε το περιβάλλον της, το υπόλοιπο πρόγραµµα του αρχείου. Επειδή αυτό επιτελεί και η συνάρτηση, η συγκεκριµένη µετρική µετρά το µέσο µήκος των συναρτήσεων στο αρχείο. McCabe total Υπολογίζει τη McCabe συνολικά για όλο το αρχείο. 42

44 Μετρήσεις σε Λογισµικό Αλληλεπίδρασης µε Βάση εδοµένων McCabe detailed Υπολογίζει τη McCabe για κάθε συνάρτηση του αρχείου. object-oriented metrics methods per class Μετρά τον αριθµό των µεθόδων σε κάθε κλάση. number of classes Μετρά τον αριθµό των κλάσεων. method size Μετρά το µέγεθος µίας µεθόδου. class size Μετρά το µέγεθος µίας κλάσης. number of methods Μετρά τον αριθµό των µεθόδων. average method size Υπολογίζει το µέσο µέγεθος των µεθόδων ενός προγράµµατος. Μετρά το πλήθος των χαρακτήρων όλων των συναρτήσεων-µελών και βρίσκει κάποιο µέσο όρο ενδεικτικό του µεγέθους των µεθόδων. length of OO program Μετρά το µήκος ενός προγράµµατος βασιζόµενη στον αριθµό των κλάσεων και των µεθόδων που αυτό διαθέτει. Βρίσκει, δηλαδή, το λόγο των χαρακτήρων των κλάσεων προς τους χαρακτήρες του προγράµµατος. Το αποτέλεσµα που προκύπτει δείχνει τι ποσοστό του προγράµµατος έχει αντικειµενοστραφή χαρακτηριστικά (κλάσεις). Εµφάνιση των Αποτελεσµάτων Τα αποτελέσµατα των µετρήσεων προβάλλονται στη διεπαφή του εργαλείου, δίνεται όµως και η δυνατότητα αποθήκευσής τους σε.txt αρχείο για περεταίρω επεξεργασία. Η µορφή που αποθηκεύονται τα αποτελέσµατα είναι παρόµοια µε τα τη µορφή που παρουσιάζονται στο εργαλείο. Εκτελώντας όλες τις µετρικές size and complexity και object-oriented, τα αποτελέσµατα εµφανίζονται στη διεπαφή του εργαλείου σε διαφορετικές ετικέτες (tabs). Στο πρώτο tab (Εικόνα 4.3) εµφανίζονται τα αποτελέσµατα των size and complexity µετρικών για κάθε αρχείο για το οποίο εκτελέστηκαν οι µετρικές. 43

45 Μετρήσεις σε Λογισµικό Αλληλεπίδρασης µε Βάση εδοµένων Εικόνα 4.3 Προβολή αποτελεσµάτων για τις µετρικές size and complexity. Το δεύτερο tab (Εικόνα 4.4) αποτελείται από µία λίστα tabs, ένα για κάθε αρχείο για το οποίο εκτελέστηκαν µετρήσεις. Για κάθε ένα, δίνονται τα αποτελέσµατα των µετρικών McCabe όλων των συναρτήσεων του αρχείου, καθώς και λεπτοµέρειες για τον υπολογισµό (αριθµό if, while, switch, for, goto). Εικόνα 4.4 Προβολή αποτελεσµάτων για τη µετρική McCabe. Στο τρίτο tab (Εικόνα 4.5), που και αυτό αποτελείται από τόσα tabs όσα και τα αρχεία για τα οποία εκτελέστηκαν µετρήσεις, δίνονται λεπτοµέρειες για κάθε αρχείο για όλες τις κλάσεις (αριθµός χαρακτήρων, αριθµός µεθόδων και αριθµός χαρακτήρων των µεθόδων) και τις µεθόδους (αριθµός χαρακτήρων) που υλοποιούνται, το σώµα τους δηλαδή βρίσκεται στην κλάση του αρχείου. 44

46 Μετρήσεις σε Λογισµικό Αλληλεπίδρασης µε Βάση εδοµένων Εικόνα 4.5 Προβολή αποτελεσµάτων object-oriented µετρικών για κάθε κλάση και µέθοδο. Στο τέταρτο και τελευταίο tab (Εικόνα 4.6) δίνονται συγκεντρωτικά αποτελέσµατα των object-oriented µετρικών για κάθε αρχείο. Υπολογίζονται ο αριθµός των κλάσεων και των µεθόδων που υλοποιούνται στο αρχείο, το µέσο µέγεθος των µεθόδων και το ποσοστό του κώδικα που έχει object-oriented χαρακτηριστικά. Εικόνα 4.6 Προβολή αποτελεσµάτων object-oriented µετρικών για κάθε αρχείο. Τα αποτελέσµατα που παράγει η εκτέλεση των µετρικών µπορούν να χρησιµοποιηθούν, ώστε να εξαχθούν συµπεράσµατα για τον τρόπο γραφής του λογισµικού και κατά πόσο αυτό είναι εύκολα συντηρήσιµο. 45

47 ιεξαγωγή Μετρήσεων Λογισµικού Κεφάλαιο 5 ιεξαγωγή Μετρήσεων Λογισµικού Στο κεφάλαιο αυτό περιγράφεται το σενάριο διεξαγωγής των µετρήσεων στο λογισµικό αλληλεπίδρασης µε τη Β, το οποίο σχεδιάστηκε µε βάση τους στόχους που τέθηκαν στο προηγούµενο κεφάλαιο. Αναλύεται, επίσης, η µεθοδολογία που ακολουθείται για την επιτυχή διεκπεραίωση των µετρήσεων, ώστε από τα αποτελέσµατα να εξαχθούν σαφή συµπεράσµατα για τη συντηρησιµότητα και την επαναχρησιµοποιησιµότητα του λογισµικού. Σενάριο ιεξαγωγής των Μετρήσεων Πριν καθοριστεί το σενάριο πραγµατοποίησης των µετρήσεων στο λογισµικό, θα πρέπει να περιγραφούν οι προδιαγραφές και οι περιορισµοί, ώστε το σενάριο να καλύπτει τους στόχους που έχουν τεθεί στην αντίστοιχη ενότητα (Κεφάλαιο 4, Στόχοι των Μετρήσεων). Προδιαγραφές και Περιορισµοί των Μετρήσεων Όπως αναφέρθηκε, το λογισµικό αναπτύχθηκε ως ένα από τα τρία επίπεδα ενός πληροφοριακού συστήµατος. Εάν το λογισµκό αυτό, πρόκειται να ενσωµατωθεί σε άλλο πληροφοριακό σύστηµα που να συνδέεται µε Β και συγκεκριµένα Oracle τι θα χρειαστεί να τροποποιηθεί, ώστε ο µηχανικός Η/Υ ή/και ο προγραµµατιστής να µπορέσουν να το ενσωµατώσουν και τι θα πρέπει να προσεχθεί, ώστε το επίπεδο αυτό να είναι εύκολα συντηρήσιµο είτε στο ίδιο είτε σε άλλο πληροφοριακό σύστηµα; Λίγα Λόγια για την Ανάπτυξη του Backend Ο πηγαίος κώδικας του backend συνεχίζει να αναπτύσσεται και πέρα από τη χρονική στιγµή πραγµατοποίησης των µετρήσεων. Για το λόγο αυτό, όλες οι µετρήσεις πραγµατοποιούνται σε ένα στιγµιότυπο αυτού. Η ανάπτυξη ολόκληρου του επιπέδου έχει γίνει από αρκετούς διαφορετικούς µηχανικούς Η/Υ. Το τµήµα του πυρήνα έχει υλοποιηθεί εξ ολοκλήρου από έναν µηχανικό Η/Υ που σηµαίνει ότι ο τρόπος συγγραφής, σχολιασµού, τεκµηρίωσης κλπ. είναι ενιαίος. Τα επιπλέον αρχεία πηγαίου κώδικα, από την άλλη, αποτελούν ένα ανοµοιογενές µείγµα διαφορετικών τρόπων γραφής, πάντα όµως, βάσει του γενικότερου σχεδιασµού του επιπέδου. 46

48 ιεξαγωγή Μετρήσεων Λογισµικού Ο χρόνος υλοποίησης των υπηρεσιών του συστήµατος, actions, δεν είναι ποτέ αρκετός, ώστε ο µηχανικός Η/Υ ή/και ο προγραµµατιστής να µπορέσει να σχολιάσει και να τεκµηριώσει επαρκώς τον πηγαίο κώδικα. Επίσης, οι απαιτήσεις είναι πάντα πολλές και συνήθως µη σαφώς ορισµένες, µε αποτέλεσµα να πραγµατοποιούνται διαρκώς τροποποιήσεις στον κώδικα. Οι τροποποιήσεις αυτές οδηγούν είτε σε αλλαγή του υπάρχοντος κώδικα κάτι που αυξάνει την πολυπλοκότητά του, µε την προσθήκη κυρίως επιπλέον ελέγχων είτε σε αφαίρεση ολόκληρου τµήµατος του κώδικα που κατά κανόνα µπαίνει εντός σχολίων για την περίπτωση νέας τροποποίησης των απαιτήσεων κατά την οποία θα απαιτηθεί η προηγούµενη υλοποίηση είτε σε προσθήκη εντελώς νέου που σηµαίνει προσθήκη επιπλέον ελέγχων, άρα και αύξηση της πολυπλοκότητας του πηγαίου κώδικα που παράγεται. Ένα ακόµη σηµείο που πρέπει να αναφερθεί είναι ότι η υλοποίηση του πυρήνα θεωρείται ολοκληρωµένη και µόνο για περιπτώσεις που δεν έχουν προβλεφθεί στον αρχικό σχεδιασµό του ενδέχεται να τροποποιηθεί. Οι τροποποιήσεις αφορούν σε προσθήκη νέων κλάσεων και µεθόδων σε ανεξάρτητα µε τα υπάρχοντα αρχεία και κατά συνέπεια, δεν επηρεάζουν σηµαντικά την πολυπλοκότητα του τµήµατος αυτού. Για την υλοποίηση των περισσότερων υπηρεσιών-actions, όµως, τα πράγµατα είναι διαφορετικά. Για κάθε υπηρεσία υπάρχουν πολλές διαφορετικές περιπτώσεις και υποπεριπτώσεις που πρέπει να ληφθούν υπόψη και απαιτούν πολλές φορές µεγάλη διαφοροποίηση από τη γενική περίπτωση. Αυτό σηµαίνει θεωρητικά, απλώς την προσθήκη κάποιων επιπλέον µεθόδων που υλοποιούν τις διαφορετικές περιπτώσεις, στην πραγµατικότητα όµως η επιλογή της µεθόδου που θα εκτελεστεί είναι το αποτέλεσµα πολλαπλών συνθηκών και ελέγχων. Ως εκ τούτου, η πολυπλοκότητα τέτοιου είδους υπηρεσιών είναι πολύ µεγάλη. Το τελικό παραδοτέο του συστήµατος δίνει περισσότερο σηµασία στο αποτέλεσµα, που είναι η διαχείριση και εξαγωγή της απαιτούµενης πληροφορίας σε ικανοποιητικό χρόνο, παρά στο τρόπο γραφής και στην επαρκή τεκµηρίωση του πηγαίου κώδικα. Αυτό σε συνδυασµό µε τους χρονικούς περιορισµούς σηµαίνει ότι η υλοποίηση του κώδικα στο τελικό παραδοτέο δεν αλλάζει, µιας και η σιωπηλή σύµβαση είναι: Αυτό που τρέχει, όπως και αν είναι υλοποιηµένο, δεν το πειράζουµε. Εξάλλου, η τροποποίηση έστω και µικρού µέρους του πηγαίου κώδικα αλλαγή πυρήνα ή/και υπηρεσιών σηµαίνει ανάπτυξη και εργαλείων ελέγχου της ορθότητας αυτού, και ως προς την ορθότητα του τελικού αποτελέσµατος και ως προς την ικανοποίηση των απαιτήσεων της κάθε υπηρεσίας. Κάτι τέτοιο, για το µεγάλο όγκο της πληροφορίας του συστήµατος και για όλες τις διαφορετικές περιπτώσεις που περιλαµβάνονται στην κάθε ενέργεια είναι εξαιρετικά χρονοβόρο. Εάν το επίπεδο backend αντιµετωπιστεί ανεξάρτητα από το πληροφοριακό σύστηµα µέσα στο οποίο υλοποιήθηκε, τότε αυτό που τελικά θα πρέπει να αξιοποιηθεί είναι ο πυρήνας του επιπέδου αυτού, πάνω στο οποίο θα πρέπει να χτιστούν οι υπηρεσίες του νέου συστήµατος. Εποµένως, από άποψη επαναχρησιµοποιησιµότητας και συντηρησιµότητας, βάρος θα πρέπει να δοθεί στο τµήµα αυτό. Για τη συντήρηση του υπάρχοντος επιπέδου στο πληροφοριακό σύστηµα που έχει υλοποιηθεί, σηµασία πρέπει να δοθεί και στις υλοποιηµένες υπηρεσίες του. Άρα, η συντηρησιµότητα κάθε τµήµατος του επιπέδου αυτού χρήζει προσοχή. 47

49 ιεξαγωγή Μετρήσεων Λογισµικού Προδιαγραφές και Περιορισµοί των Μετρήσεων Οι µετρήσεις, λοιπόν, πραγµατοποιούνται σε ένα λογισµικό που εκ των πραγµάτων δεν έχει υλοποιηθεί µε βιοµηχανικό πηγαίο κώδικα. Η συνισταµένη όλων των παραµέτρων πηγαίος κώδικας µε ελλιπή σχολιασµό και πολλές φορές µεγάλη πολυπλοκότητα, πηγαίος κώδικας που δεν πρόκειται να τροποποιηθεί για το τελικό παραδοτέο και σφικτοί χρονικοί περιορισµοί θέτουν τις προδιαγραφές και τους περιορισµούς των µετρήσεων. Επειδή η ανάπτυξη του επιπέδου συνεχίζεται καθ όλη τη διάρκεια των µετρήσεων, οι µετρήσεις θα αφορούν στον πυρήνα και το µεγαλύτερο µέρος του υπηρεσιών και όχι στο τελικό λογισµικό. Λόγω του ότι η ταχύτητα ανάπτυξης είναι µεγάλη, οι δεδοµένες απαιτήσεις είναι πολλές και η οµάδα υλοποίησης παραµένει η ίδια, όµοιος θα είναι και ο τρόπος ανάπτυξης του υπολοίπων υπηρεσιών. Οπότε, οι µετρήσεις είναι αντιπροσωπευτικές για το όλο το λογισµικό (πυρήνας και υπηρεσίες). Ο πηγαίος κώδικας του στιγµιότυπου που θα µετρηθεί δεν πρέπει να τροποποιηθεί µε τρόπο ώστε τα αποτελέσµατα των µετρήσεων να εξασφαλίζουν σε µεγαλύτερο βαθµό δυνατότητα επαναχρησιµοποιησιµότητας και συντηρησιµότητας. Μέσω των αποτελεσµάτων των µετρήσεων εξάγονται σηµαντικές πληροφορίες και συµβουλές για την τροποποίηση του πηγαίου κώδικα, ώστε αυτός να θεωρηθεί άµεσα επαναχρησιµοποιήσιµος και εύκολα συντηρήσιµος. Επειδή υπάρχει κώδικας σε σχόλια, οι µετρήσεις για το ποσοστό των σχολίων σε κάθε αρχείο θα είναι λανθασµένες και, άρα, παραπλανητικές. Εποµένως, µεγάλη σηµασία για την ορθή πραγµατοποίηση των µετρήσεων έχει το να γίνουν οι απαραίτητες τροποποιήσεις, ώστε ο κώδικας εντός σχολίων να µη θεωρείται ως σχόλια επεξήγησης και τεκµηρίωσης. Σενάριο Μετρήσεων Για την πραγµατοποίηση µετρήσεων από τις οποίες προκύπτει χρήσιµη πληροφορία για την εξαγωγή συµπερασµάτων όσον αφορά στη συντηρησιµότητα και την επαναχρησιµοποιησιµότητα του λογισµικού, ακολουθείται το σενάριο που περιγράφεται παρακάτω και αποτελείται από τα βήµατα: Βήµα 1 Στο βήµα αυτό µετράται το µεγέθους του συνόλου του πηγαίου κώδικα στον οποίο πραγµατοποιούνται οι µετρήσεις. Για το σκοπό αυτό χρησιµοποιείται ένα µέρος των size and complexity µετρικών του εργαλείου Metrics v2.0 που περιγράφηκε στην αντίστοιχη ενότητα (Κεφάλαιο 4, Εργαλείο Πραγµατοποίησης των Μετρήσεων). 48

50 ιεξαγωγή Μετρήσεων Λογισµικού Πιο συγκεκριµένα, το µέγεθος του πηγαίου κώδικα µετράται όχι µόνο σε ΜΒ, αλλά και σε αριθµό χαρακτήρων µε τη µετρική total characters. Από το σύνολο του πηγαίου κώδικα, προκύπτει το µέγεθος του καθαρού κώδικα και των σχολίων για το κάθε αρχείο, µε τις µετρικές code characters και comment characters καθώς και το ποσοστό τους στο σύνολο του πηγαίου κώδικα, µε τις µετρικές code % και comments %. Το αποτέλεσµα του βήµατος αυτού είναι α) το µέγεθος του πηγαίου κώδικα στον οποίο διεξάγονται οι µετρήσεις, β) το ποσοστό του καθαρού κώδικα σε κάθε αρχείο και γ) το ποσοστό των σχολίων σε κάθε αρχείο. Βήµα 2 Για το βήµα 2 ως είσοδος χρησιµοποιείται το αποτέλεσµα του βήµατος 1, έχοντας υπόψη το γεγονός ότι το ποσοστό των σχολίων σε ορισµένα αρχεία δεν αντιστοιχεί εξ ολοκλήρου σε σχόλια επεξήγησης και τεκµηρίωσης, όπως αναφέρθηκε στην ενότητα Προδιαγραφές και Περιορισµοί των Μετρήσεων. Πιο συγκεκριµένα, στα αρχεία που εµφανίζεται µεγάλο ποσοστό πρέπει να εξεταστεί η µορφή των σχολίων και στην περίπτωση που τα σχόλια είναι κώδικας, αυτός είτε να αφαιρεθεί εντελώς είτε να µπει στο σώµα µίας νέας µεθόδου, ή ακόµη και κλάσης, µε επαρκή σχόλια τεκµηρίωσης. Βέβαια, αυτή η µέτρηση δεν εξασφαλίζει ότι όλα τα τµήµατα του πηγαίου κώδικα που βρίσκονται εντός σχολίων µπορούν να εντοπιστούν, µιας και κώδικας µίας ή δύο γραµµών είναι δύσκολο να βρεθεί µε τον τρόπο αυτό. Για ολοκληρωµένη επίλυση, θα πρέπει να εξεταστεί όλος ο πηγαίος κώδικας, κάτι που είναι εξαιρετικά δύσκολο και χρονοβόρο. Μετά την ολοκλήρωση του βήµατος 2, το αποτέλεσµα είναι η τροποποίηση του κώδικα, ώστε τα σχόλια που υπάρχουν σε αυτόν να είναι µόνο σχόλια επεξήγησης και τεκµηρίωσης, και όχι κώδικας. Τα βήµατα 1 και 2 είναι έξω από τη µεθοδολογία των µετρήσεων ποιότητας που περιγράφονται και για το λόγο αυτό πραγµατοποιούνται επιπρόσθετα, αποκλειστικά και µόνο για τη διαµόρφωση των σχολίων και την ορθή εξαγωγή αποτελεσµάτων και συµπερασµάτων. Τα βήµατα αυτά δεν περιγράφονται στη διεξαγωγή των µετρήσεων, µιας και είναι προαπαιτούµενα για αυτήν. Βήµα 3 Ο πηγαίος κώδικας που προκύπτει µετά την ολοκλήρωση του βήµατος 2 είναι κώδικας στον οποίο µπορούν εφαρµοστούν µετρικές της κατηγορίας size and complexity και µετρικές της κατηγορίας object-oriented, ώστε τα αποτελέσµατα να δώσουν σαφή εικόνα για το λογισµικό. 49

51 ιεξαγωγή Μετρήσεων Λογισµικού Πιο συγκεκριµένα, οι µετρικές που εκτελούνται και ο σκοπός για τον οποίο εκτελούνται είναι: µετρικές της κατηγορίας size and complexity total characters, code characters και comment characters, ώστε να µετρηθεί το µέγεθος του πηγαίου κώδικα, το µέγεθος των σχολίων και του καθαρού κώδικα. code % και comments %, που προκύπτει από τις παραπάνω µετρήσεις, ώστε να προσδιοριστεί το ποσοστό του καθαρού κώδικα και των σχολίων στον πηγαίο κώδικα. Από αυτό θα προκύψει συµπέρασµα, για το κατά πόσο τεκµηριωµένος είναι ο πηγαίος κώδικας, κάτι που παρέχει ενδείξεις για το εάν είναι και εύκολα συντηρήσιµος. McCabe total και McCabe detailed, ώστε να βρεθεί η πολυπλοκότητα του πηγαίου κώδικα. Με τις µετρικές αυτές, προκύπτει συµπέρασµα για το ποιες συναρτήσεις, µέθοδοι και κλάσεις είναι πολύπλοκες. Προφανώς, συναρτήσεις, µέθοδοι και κλάσεις µε µεγάλη πολυπλοκότητα δεν είναι αποδεκτές στον πηγαίο κώδικα, µιας και κάτι τέτοιο τις κάνει δυσνόητες και, εποµένως, δύσκολα συντηρήσιµες. Η µετρική McCabe total εξετάζει την τιµή της McCabe συνολικά σε ένα αρχείο, ενώ η McCabe detailed εξετάζει την τιµή της µετρικής σε κάθε αρχείο χωριστά, για κάθε µέθοδο αυτού. µετρικές της κατηγορίας object-oriented number of classes, number of methods και methods per class, ώστε να υπάρχει µια εικόνα για το µέγεθος του πηγαίου κώδικα εκφρασµένη σε αριθµό κλάσεων και µεθόδων καθώς και µία ενδεικτική εκτίµηση της πολυπλοκότητας. Όσο περισσότερες µέθοδοι έχουν υλοποιηθεί, τόσο µικρότερη πολυπλοκότητα υπάρχει στις µεθόδους. Οµοίως και όταν µία κλάση έχει πολλές µεθόδους στο σώµα της. method size, class size και average method size, ώστε να υπάρχει εκτίµηση για το µέγεθος των κλάσεων και των µεθόδων. Αυτό είναι µία ένδειξη για το πόσο πολύπλοκη είναι µία κλάση και µέθοδος. Στην περίπτωση που το µέγεθός τους είναι µεγάλο, θα µπορούσαν να σπάσουν σε µικρότερες. length of OO program, ώστε να γίνει εκτίµηση κατά πόσο τα χαρακτηριστικά του αντικειµενοστραφούς προγραµµατισµού χρησιµοποιούνται στον πηγαίο κώδικα. Εκτός, όµως, από τις µετρήσεις µε µεµονωµένες µετρικές, µπορεί να γίνει και συνδυασµός των αποτελεσµάτων δύο ή περισσότερων µετρικών, ώστε να προκύψουν ολοκληρωµένα συµπεράσµατα για το λογισµικό. Επειδή ο πηγαίος κώδικας είναι υλοποιηµένος σε γλώσσα αντικειµενοστραφούς προγραµµατισµού, µεγάλο ενδιαφέρον παρουσιάζουν οι αντικειµενοστραφείς µετρικές. Ενδεικτικά αναφέρονται κάποιοι συνδυασµοί µετρικών: 50

52 ιεξαγωγή Μετρήσεων Λογισµικού total characters, comment characters και comments %, ώστε να υπάρχει σαφής εικόνα του ποσοστού των σχολίων σε σχέση µε το σύνολο των χαρακτήρων στο αρχείο. Ανάλογα µε την τιµή αυτή θα φανεί το κατά πόσο είναι επαρκώς σχολιασµένος ο πηγαίος κώδικας. code % και comments % σε συνδυασµό µε τη µετρική McCabe, ώστε να υπάρχουν αποτελέσµατα για το κατά πόσο καλά τεκµηριωµένος είναι ο πηγαίος κώδικας σε σχέση µε την πολυπλοκότητά του. Προφανώς, συναρτήσεις, µέθοδοι και κλάσεις που παρουσιάζουν υψηλή τιµή στη µετρική του McCabe, άρα είναι και πολύπλοκες, πρέπει να είναι επαρκώς σχολιασµένες. code characters και average method size, ώστε να προκύψουν συµπεράσµατα του συνδυασµού των δύο µετρικών. Όσο αυξάνεται ο αριθµός των χαρακτήρων του καθαρού κώδικα, θα πρέπει να αυξάνεται και το µέσο µέγεθος των µεθόδων στα αρχεία, διαφορετικά ο διαµοιρασµός των εργασιών στις µεθόδους δεν είναι σωστός. average method size και η µετρική McCabe, ώστε να υπάρχει εκτίµηση για το ποιες συναρτήσεις, µέθοδοι και κλάσεις που έχουν µεγάλο µέγεθος και είναι πολύπλοκες, µπορούν να σπάσουν σε περισσότερες µε σκοπό να µειωθεί η πολυπλοκότητά τους. Βήµα 4 Αφού ολοκληρωθούν οι µετρήσεις που περιγράφονται στο βήµα 3, στο βήµα αυτό γίνεται µία στατιστική ανάλυση των αποτελεσµάτων, χρησιµοποιώντας το SPSS (version 10). Βήµα 5 Στο τελευταίο βήµα µελετούνται τα αποτελέσµατα που προέκυψαν από τη στατιστική ανάλυση του βήµατος 4 και καταγράφονται τα συµπεράσµατα ως προς τη συντηρησιµότητα και την επαναχρησιµοποιησιµότητά του. 51

53 ιεξαγωγή Μετρήσεων Λογισµικού ιεξαγωγή των Μετρήσεων Το λογισµικό, επίπεδο backend του πληροφοριακού συστήµατος, στο οποίο πραγµατοποιούνται οι µετρήσεις είναι εγκατεστηµένο σε έναν από τους εξυπηρετητές που φιλοξενείται το σύστηµα και αποτελείται από τον πηγαίο κώδικα, τις βιβλιοθήκες που απαιτούνται για τη λειτουργία του και άλλα αρχεία που δηλώνουν τις ρυθµίσεις του εξυπηρετητή και την επικοινωνία του backend µε τη Β. Οι µετρήσεις πραγµατοποιούνται αποκλειστικά και µόνο στον πηγαίο κώδικα. Μέγεθος του Πηγαίου Κώδικα Ο πηγαίος κώδικας του επιπέδου backend είναι µεγέθους συνολικά περίπου 5MB. Αποτελείται από 731 αρχεία.java µεγέθους από 5KB έως και 40KB το κάθε ένα. Είναι κατανεµηµένα σε 184 φακέλους, κάθε ένας από τους οποίους έχει χαρακτηριστικό όνοµα για την υπηρεσία που εκτελεί. οµή του Πηγαίου Κώδικα Η δοµή του πηγαίου κώδικα του λογισµικού η λειτουργία του και η δοµή υλοποίησής του περιγράφηκε στην ενότητα Κεφάλαιο 4, Επίπεδο Backend που πραγµατοποιούνται οι µετρήσεις είναι η εξής: Εικόνα 5.1 οµή πηγαίου κώδικα λογισµικού Στους φακέλους folder-core και folder-core2 είναι υλοποιηµένες δύο διαφορετικές εκδόσεις του πυρήνα του backend. Στη δηµιουργία των υπηρεσιών χρησιµοποιούνται εναλλακτικά και οι δύο εκδόσεις του πυρήνα, ανάλογα µε τον τρόπο υλοποίησης. Στα αρχεία αυτά καθορίζονται όλες οι λεπτοµέρειες για: την επικοινωνία του λογισµικού µε τη Β, την εκτέλεση των ερωτηµάτων σε αυτήν και την εκτέλεση των συναρτήσεων (stored functions) που έχουν υλοποιηθεί στη Β Oracle. 52

54 ιεξαγωγή Μετρήσεων Λογισµικού την επικοινωνία µε το επίπεδο frontend, τον τρόπο που παίρνει τα δεδοµένα και δίνει την πληροφορία. Σε κάθε ένα από τους υπόλοιπους φακέλους είναι υλοποιηµένες οι υπηρεσίες του συστήµατος. Κάθε action υλοποιείται σε ένα αρχείο πηγαίου κώδικα σε Java και είναι κλάσεις DAO, που ανήκει σε φάκελο µε όνοµα χαρακτηριστικό για την υπηρεσία που πραγµατοποιεί. Σε κάθε τέτοιο φάκελο υπάρχουν άλλοι δύο φάκελοι όπου απαιτείται που υλοποιούν τις κλάσεις TO (φάκελος data) και τις κλάσεις εκτέλεσης αριθµητικών και λογικών πράξεων και ελέγχων (φάκελος actions). Για τις µετρήσεις που ακολουθούν έχουν επιλεγεί δύο οµάδες αρχείων. Η πρώτη οµάδα (Οµάδα Α) είναι ο πηγαίος κώδικας του πυρήνα που υλοποιεί τη διασύνδεση του backend µε τη Β και η δεύτερη οµάδα (Οµάδα Β) είναι αρχεία από τον πυρήνα και τις υπηρεσίες-actions του λογισµικού επιλεγµένα ώστε να αποτελούν αντιπροσωπευτικά παραδείγµατα για όλο το λογισµικό ουσιαστικά το µέγεθος και η πολυπλοκότητά τους ποικίλει για να καλύπτει όσο το δυνατό περισσότερες περιπτώσεις διαφορετικών αρχείων. Εκτός από την οµάδα Α, που θα διεξαχθούν µετρήσεις στο τµήµα του λογισµικού όπως αυτό έχει υλοποιηθεί, για την οµάδα Β, κρίνεται απαραίτητη η επιλογή των αρχείων για τις µετρήσεις που ακολουθούν λόγω του µεγάλου όγκου του πηγαίου κώδικα και της οµοιοµορφίας αυτού σε αρκετά σηµεία. Μετρήσεις και συµπεράσµατα και για τα 731 αρχεία του πηγαίου κώδικα είναι έξω από το σκοπό της παρούσας διπλωµατικής. Στο Παράρτηµα Α, παρουσιάζονται αναλυτικότερα οι δύο οµάδες των αρχείων που έχουν επιλεγεί για την πραγµατοποίηση των µετρήσεων που ακολουθούν στην επόµενη ενότητα. Μετρήσεις του Πηγαίου Κώδικα Οι µετρήσεις του πηγαίου κώδικα πραγµατοποιήθηκαν µε το εργαλείο που περιγράφηκε στην ενότητα Κεφάλαιο 4, Εργαλείο Πραγµατοποίησης των Μετρήσεων και εκτελέστηκαν σε δύο φάσεις, µία για κάθε οµάδα. Μετρήσεις Οµάδας Α Στο εργαλείο Metrics v2.0 επιλέγονται τα αρχεία της οµάδας Α και οι µετρικές που θα εκτελεστούν. Στην περίπτωση αυτή, επιλέγονται όλες οι µετρικές της κατηγορίας size and complexity και της κατηγορίας των αντικειµενοστραφών µετρικών. Τα αποτελέσµατα των µετρήσεων παρουσιάζονται στο εργαλείο και µπορούν να εξαχθούν σε αρχείο. 53

55 ιεξαγωγή Μετρήσεων Λογισµικού Εικόνα 5.2 Μετρήσεις στα αρχεία του πηγαίου κώδικα της οµάδας Α 1. Μετρήσεις ποσοστού σχολίων και καθαρού κώδικα FileName CodeChar. CommentChar. TotalChar. Code% Comment% DatabaseService.java ,91 2,09 DatabaseUtils.java DbDColumn.java DbResult.java DbResultHandler.java DbRow.java BeanPersistence.java BaseObjectHandler.java BeanRsHandler.java ,1 4,9 SObjectRsHandler.java DatabaseMetaData.java DbColumn.java DbIndex.java DbMdBuilder.java ,08 3,92 54

56 ιεξαγωγή Μετρήσεων Λογισµικού DbReference.java DbTable.java Συνδυάζοντας τα αποτελέσµατα των µετρικών code characters, code% και comment% φαίνεται ότι ο κώδικας δεν είναι επαρκώς σχολιασµένος, ανεξάρτητα από το µέγεθος του αρχείου σε γραµµές κώδικα είναι αναµενόµενο ότι όσο µεγαλύτερο είναι το αρχείο, τόσο περισσότερα σχόλια εισάγονται. Στην περίπτωση των αρχείων αυτών, ποσοστό σχολίων σε αρχείο 317 γραµµών κώδικα είναι 0%, όπως το ίδιο είναι και στην περίπτωση αρχείου µεγέθους 4006 γραµµών κώδικα. 2. Μετρική McCabe FileName McCabe MaxMcCabe Σ(Mci)/R DatabaseService.java 4, DatabaseUtils.java 1,28 2 1,57 DbDColumn.java DbResult.java DbResultHandler.java DbRow.java BeanPersistence.java 4,87 8 2,89 BaseObjectHandler.java 14, ,5 BeanRsHandler.java 6, ,5 SObjectRsHandler.java DatabaseMetaData.java DbColumn.java DbIndex.java DbMdBuilder.java 4,81 7 3,83 DbReference.java DbTable.java 10, Η µέση τιµή της µετρικής McCabe είναι χαµηλή σχεδόν σε όλα τα αρχεία. Στο Παράρτηµα Β επισυνάπτονται τα αποτελέσµατα της µετρικής McCabe αναλυτικά για κάθε αρχείο. 3. Αντικειµενοστραφείς Μετρικές FileName #classes #methods AMS oo length DatabaseService.java % DatabaseUtils.java % 55

57 ιεξαγωγή Μετρήσεων Λογισµικού DbDColumn.java % DbResult.java % DbResultHandler.java % DbRow.java % BeanPersistence.java % BaseObjectHandler.java % BeanRsHandler.java % SObjectRsHandler.java % DatabaseMetaData.java % DbColumn.java % DbIndex.java % DbMdBuilder.java % DbReference.java % DbTable.java % Ως AMS ορίζεται το Average Method Size και ως oo length, η µετρική length of OO program. Τα αποτελέσµατα των µετρήσεων αυτών, έχουν νόηµα σε συνδυασµό µε τις προηγούµενες µετρήσεις. Μετρήσεις Οµάδας Β Όπως και για την οµάδα Α, στο εργαλείο Metrics v2.0 επιλέγονται τα αρχεία της οµάδας αυτής και οι µετρικές που θα εκτελεστούν, δηλαδή επιλέγονται όλες οι µετρικές της κατηγορίας size and complexity και της κατηγορίας των αντικειµενοστραφών µετρικών. Τα αποτελέσµατα των µετρήσεων παρουσιάζονται στο εργαλείο, µπορούν όµως να εξαχθούν και σε αρχείο για επεξεργασία. 56

58 ιεξαγωγή Μετρήσεων Λογισµικού Εικόνα 5.3 Μετρήσεις στα αρχεία του πηγαίου κώδικα της οµάδας Β 1. Μετρήσεις ποσοστού σχολίων και καθαρού κώδικα FileName CodeChar. CommentChar. TotalChar. Code% Comment% AbstractSingleValidator.java ,43 50,57 ActionInsert.java ,87 12,13 ActionOnline.java ,34 14,66 ActionProipiresiaCalculate.java ,41 20,59 ActionSelect.java ,79 13,21 AfmValidator.java ,01 31,99 AndValidator.java ,12 37,88 BooleanValidator.java ,82 40,18 Calculator2005.java ,4 1,6 ChangeLoginPassword.java ,1 3,9 DbActionSelectSimpleMul.java ,12 21,88 DbUtils.java DynamicDbIO.java epilogikladondao.java ,94 21,06 57