Μεθοδολογία επαναχρησιμοποίησης κώδικα βασισμένη σε πρότυπα σχεδίασης

ΑΡΙΣΤΟΤΕΛΕΙΟ ΠΑΝΕΠΙΣΤΗΜΙΟ ΘΕΣΣΑΛΟΝΙΚΗΣ Τμήμα Πληροφορικής Πρόγραμμα Μεταπτυχιακών Σπουδών του τμήματος Πληροφορικής Κατεύθυνση "Πληροφοριακά Συστήματα Μεθοδολογία επαναχρησιμοποίησης κώδικα βασισμένη σε πρότυπα σχεδίασης Μίχου Όλγα Επιβλέπων καθηγητής: Ιωάννης Σταμέλος Θεσσαλονίκη 2009

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

Abstract Software quality, regarding software maintenance and consequently the possibility of its reuse, is well known and discussed. Although there is not only one definition available to describe software quality, everybody can comprehend this concept, especially by the means of its absence. Achieving software quality is strongly connected to the concept of software metric, which is an essential procedure for the estimation the products state, procedures and resources. By applying metrics at a software, one can count those characteristics that contribute to its quality. As a result, it can be possible to draw conclusions for how much the software satisfies the quality criteria. The objective of this master thesis is the presentation of a methodology for object oriented code reuse, based on design patterns, and its validations through a case study, so as to draw conclusions mainly for its maintainability and consequently for its possibility to be reused. 3

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

Περιεχόμενα Περιεχόμενα 1 Εισαγωγή Βασικές Έννοιες... 7 1.1 Εμπειρική τεχνολογία λογισμικού Πειραματικές μέθοδοι 7 1.1.1 Έρευνα πεδίου Survey...9 1.1.2 Μελέτη περίπτωσης Case study..10 1.1.3 Τυπικό ή Ελεγχόμενο Πείραμα Formal Experiment 11 1.2 Αρχές Αντικειμενοστραφούς Σχεδίασης Design Principles.13 1.3 Πρότυπα σχεδίασης Design Patterns..15 1.3.1 Προσαρμογέας (Adapter)...19 1.3.1.1 Γενικά.19 1.3.1.2 Γενική Δομή..20 1.3.1.3 Εφαρμογή..20 1.3.2 Σύνθετο (Composite).... 20 1.3.2.1 Γενικά.20 1.3.2.2 Γενική Δομή..21 1.3.2.3 Εφαρμογή..21 1.3.3 Μοναδιαίο (Singleton)..21 1.3.3.1 Γενικά.22 1.3.3.2 Γενική Δομή..23 1.3.3.3 Εφαρμογή..23 1.3.4 Γέφυρα (Bridge). 23 1.3.4.1 Γενικά.23 5

1.3.4.2 Γενική Δομή..23 1.3.4.3 Εφαρμογή..24 1.3.5 Παρατηρητής (Observer). 24 1.3.5.1 Γενικά.25 1.3.5.2 Γενική Δομή..26 1.3.5.3 Εφαρμογή..26 1.3.6 Επισκέπτης (Visitor)....26 1.3.6.1 Γενικά.26 1.3.6.2 Γενική Δομή..27 1.3.6.3 Εφαρμογή..28 1.3.7 Αφηρημένο Εργοστάσιο (Abstract Factory)......28 1.3.7.1 Γενικά.28 1.3.7.2 Γενική Δομή..29 1.3.7.3 Εφαρμογή..29 1.3.8 Στρατηγική (Strategy)....29 1.3.8.1 Γενικά.30 1.3.8.2 Γενική Δομή..30 1.3.8.3 Εφαρμογή..30 1.3.9 Μέθοδος Υπόδειγμα (Template Method)...30 1.3.9.1 Γενικά.30 1.3.9.2 Γενική Δομή..31 1.3.9.3 Εφαρμογή..31 1.4 Μετρικές Λογισμικού Software Metrics 31 6

1.4.1 Μετρικές σε επίπεδο κλάσης 31 1.4.1.1 Μέθοδοι ανά κλάση (WMC)....31 1.4.1.2 Αριθμός απογόνων (NOC)..32 1.4.1.3 Βαθμός συνεκτικότητας των μεθόδων (LCOM)..33 1.4.1.4 Σύζευξη μεταξύ κλάσεων (CBO)....34 1.4.1.5 Απόκλιση μιας κλάσης (RFC). 34 1.4.1.6 Βάθος δέντρου κληρονομικότητας (DIT)..34 1.4.1.7 Παράγοντας Σύζευξης (CF)....35 1.4.1.8 Αναλογία Σχολίων (CR)...35 1.4.1.9 Γραμμές Κώδικα (LOC). 35 1.4.1.10 Έλλειψη συνεκτικότητας 2 (LCOM2 ). 36 1.4.1.11 Έλλειψη συνεκτικότητας 3 (LCOM3)....36 1.4.1.12 Fan out (FO)..37 1.5 Επαναχρησιμοποίηση Λογισμικού...37 1.5.1 Τύποι επαναχρησιμοποίησης 38 1.5.2 Μέτρηση επαναχρησιμοποίησης.. 43 1.6 Επίδραση Προτύπων Σχεδίασης σε Μετρικές Λογισμικού... 44 2 Μεθοδολογία........46 2.1.1 Αξιολόγηση 46 2.1.2 Καθορισμός των υποθέσεων.46 2.1.3 Επιλογή του Πιλοτικού Έργου..... 47 2.1.3.1 Χρησιμοποιούμενα εργαλεία..... 48 2.1.3 Εύρεση της συγκριτικής μεθόδου....49 7

2.1.4 Ελαχιστοποίηση της επίδρασης των συγκεχυόμενων παραγόντων confounding factors.. 50 2.1.5 Σχεδιασμός της μελέτης περίπτωσης..51 3 Αποτελέσματα.........53 3.1 Περιγραφική στατιστική...53 3.1.1 Γραφήματα ανά μετρική....54 3.2 Έλεγχος υποθέσεων 57 3.3 Ποιοτική Αξιολόγηση της Επίδρασης των Προτύπων Σχεδίασης. 59 3.4 Αξιολόγηση με βάση μετρικές πακέτων.71 4 Συμπεράσματα........77 Βιβλιογραφία..78 8

1 Εισαγωγή - Βασικές Έννοιες Στο κεφάλαιο αυτό παρουσιάζονται έννοιες που αφορούν το γνωστικό υπόβαθρο για την ανάγνωση και κατανόηση της παρούσης μεταπτυχιακής εργασίας. Αρχικά παρουσιάζονται έννοιες που αφορούν την εμπειρική τεχνολογία λογισμικού και τις πειραματικές μεθόδους που χρησιμοποιεί. Στη συνέχεια ακολουθεί η διατύπωση των αρχών αντικειμενοστραφούς σχεδίασης, ο ορισμός και περιγραφή των προτύπων σχεδίασης που μελετήθηκαν και των μετρικών που χρησιμοποιήθηκαν. Τέλος, παρουσιάζεται η έννοια της επαναχρησιμοποίησης λογισμικού και οι διάφοροι τύποι της. 1.1 Εμπειρική τεχνολογία λογισμικού Πειραματικές μέθοδοι Τεχνολογία λογισμικού (software engineering), σύμφωνα με τον ορισμό του οργανισμού IEEE (Institute of Electrical an Electronics Engineers, Inc.), είναι η εφαρμογή μιας συστηματικής, πειθαρχημένης και ποσοτικά μετρούμενης προσέγγισης κατά την ανάπτυξη, λειτουργία και συντήρηση του λογισμικού. Τα τρία σημεία του παραπάνω ορισμού είναι πολύ σημαντικά. Πρώτον, μία διαδικασία λογισμικού εξελίσσεται μέσα από διαφορετικές φάσεις του κύκλου ζωής. Δεύτερον, τονίζεται η ανάγκη μιας συστηματικής προσέγγισης και τρίτον δίνεται έμφαση στην ποσοτικοποίηση. Η επιστημονική έρευνα στην τεχνολογία λογισμικού περιλαμβάνει διαφορετικού τύπου ερευνητικές μεθόδους, ανάλογα με το τι πρόκειται να ερευνηθεί. Οι μέθοδοι αυτοί είναι η επιστημονική (scientific method), η μηχανική (engineering method), η εμπειρική (empirical method) και η αναλυτική (analytical method) [19, 20]. 9

Στην επιστημονική μέθοδο παρατηρείται το περιβάλλον και δημιουργείται ένα μοντέλο βασισμένο στην παρατήρηση, όπως για παράδειγμα το μοντέλο της προσομοίωσης. Στη μηχανική μέθοδο οι υπάρχουσες λύσεις μελετώνται και προτείνονται αλλαγές, οι οποίες στη συνέχεια αξιολογούνται. Στην εμπειρική μέθοδο προτείνεται ένα μοντέλο, που αξιολογείται μέσα από εμπειρικές μελέτες, όπως μελέτες περιπτώσεων ή πειράματα. Τέλος, στην αναλυτική μέθοδο προτείνεται μία επίσημη θεωρία κι έπειτα συλλέγονται εμπειρικές παρατηρήσεις, με τις οποίες συγκρίνεται η προς διερεύνηση θεωρία. Η μηχανική και η εμπειρική μέθοδος μπορεί να θεωρηθούν ως παραλλαγές της επιστημονικής μεθόδου. Κάθε μία από αυτές τις μεθόδους κρίνεται ως καταλληλότερη και εφαρμόζεται σε κάποιο συγκεκριμένο τομέα. Η εμπειρική τεχνολογία λογισμικού (empirical software engineering) είναι ο κλάδος που ερευνά θέματα της τεχνολογίας λογισμικού με τη χρήση εμπειρικών μεθόδων [19]. Η διεξαγωγή εμπειρικών μελετών αποσκοπεί στην απόκτηση αντικειμενικών και στατιστικά τεκμηριωμένων αποτελεσμάτων, όσον αφορά την κατανόηση, τον έλεγχο, την πρόβλεψη και τη βελτίωση της ανάπτυξης λογισμικού. Στις εμπειρικές μελέτες υπάρχουν δύο τύποι παραδειγμάτων ερευνών που ακολουθούν διαφορετικές προσεγγίσεις: οι ποιοτικές έρευνες (qualitative research) και οι ποσοτικές (quantitative research). Η ποιοτική έρευνα σχετίζεται με τη μελέτη αντικειμένων στις φυσικές τους συνθήκες. Ένας ποιοτικός ερευνητής προσπαθεί να ερμηνεύσει ένα φαινόμενο βασισμένος στις ερμηνείες που δίνουν οι άνθρωποι. Η ποσοτική έρευνα σχετίζεται με την ποσοτικοποίηση μιας σχέσης ή με τη σύγκριση δύο ή περισσότερων συνόλων. Σκοπός της είναι η δόμηση μιας σχέσης αιτίου αποτελέσματος. Μια ποσοτική έρευνα διεξάγεται μέσα από ελεγχόμενα πειράματα ή συλλογή δεδομένων από μελέτες περιπτώσεων και είναι κατάλληλη όταν ελέγχονται τα αποτελέσματα μιας δραστηριότητας ή ενός χειρισμού. Ένα πλεονέκτημά της είναι ότι τα ποσοτικά δεδομένα επιτρέπουν τις συγκρίσεις των αποτελεσμάτων και τη στατιστική ανάλυση. Οι ερευνητικές μέθοδοι που χρησιμοποιούνται στις εμπειρικές μελέτες είναι οι εξής [19, 20, 21]: ανάλυση χαρακτηριστικών (feature analysis) έρευνα πεδίου (survey) 10

μελέτη περίπτωσης (case study) τυπικό ή ελεγχόμενο πείραμα (formal experiment) Ο απλούστερος τύπος αξιολόγησης είναι η ανάλυση χαρακτηριστικών, που χρησιμοποιείται για τη βαθμολόγηση και την κατάταξη των χαρακτηριστικών προϊόντων ή μεθόδων. Στη συνέχεια αναλύονται η έρευνα πεδίου, η μελέτη περίπτωσης και το τυπικό πείραμα. 1.1.1 Έρευνα πεδίου- Survey H έρευνα πεδίου είναι μια μελέτη ανασκόπησης με σκοπό την τεκμηρίωση των σχέσεων και αποτελεσμάτων μιας συγκεκριμένης κατάστασης. Μία έρευνα πεδίου μπορεί να χαρακτηριστεί ως: Περιγραφική (descriptive), όταν στοχεύει σε αξιολογήσεις του πληθυσμού. Επεξηγηματική (explanatory), όταν στοχεύει σε επεξηγήσεις σχετικά με τον πληθυσμό. Εξερευνητική (explorative), όταν χρησιμοποιείται σαν μια προκαταρκτική μελέτη με σκοπό τη διεξαγωγή μιας πιο λεπτομερούς έρευνας. Στις έρευνες πεδίου καταγράφονται δεδομένα, από τα οποία θα καθοριστεί ο τρόπος που αντέδρασαν οι συμμετέχοντες ενός έργου ανάπτυξης σε κάποια συγκεκριμένη μέθοδο, εργαλείο ή τεχνική, ή θα καθοριστούν οι τάσεις και οι σχέσεις. Επίσης, μπορούν να καθοριστούν πληροφορίες που αφορούν τα προϊόντα ή έργα ανάπτυξης, τον αριθμό των σφαλμάτων ή της προσπάθειας που καταβλήθηκε. Τα κύρια μέσα για τη συλλογή των ποιοτικών ή ποσοτικών δεδομένων είναι τα ερωτηματολόγια ή οι συνεντεύξεις που εφαρμόζονται σε ένα αντιπροσωπευτικό δείγμα του προς διερεύνηση πληθυσμού. Οι ερωτήσεις των ερωτηματολογίων και των συνεντεύξεων πρέπει να σχεδιαστούν με ιδιαίτερη προσοχή ώστε τα συλλεγόμενα δεδομένα να είναι τα πλέον αντιπροσωπευτικά της διερευνώμενης κατάστασης. Στη συνέχεια τα δεδομένα αναλύονται ώστε να εξαχθούν περιγραφικά και επεξηγηματικά συμπεράσματα. Στις έρευνες πεδίου συνήθως δεν έχουμε τον έλεγχο των μεταβλητών 11

της κατάστασης που εξετάζουμε. Έτσι τα συμπεράσματα αυτών των ερευνών συγκρίνονται με τα συμπεράσματα ερευνών παρομοίων καταστάσεων. 1.1.2 Μελέτη περίπτωσης - Case study Η μελέτη περίπτωσης είναι μια παρατηρητική μελέτη ελέγχου έργων ή δραστηριοτήτων. Διεξάγεται με σκοπό να ερευνηθεί μια συγκεκριμένη οντότητα ή ένα φαινόμενο σε ένα συγκεκριμένο χρονικό διάστημα. Σε μια μελέτη περίπτωσης, πρώτα εντοπίζονται οι κύριοι παράγοντες, όπως είσοδοι, περιορισμοί, πόροι και έξοδοι, που μπορούν να επηρεάσουν το αποτέλεσμα κάποιας δραστηριότητας, και στη συνέχεια τεκμηριώνεται ο καθένας από αυτούς ξεχωριστά. Ο σκοπός μιας μελέτης περίπτωσης είναι η σύγκριση μιας κατάστασης με κάποια άλλη παρόμοια, όπως για παράδειγμα η σύγκριση των αποτελεσμάτων που προκύπτουν από τη χρήση μεθόδων ή εργαλείων. Αποφασίζεται εκ των προτέρων τι ακριβώς θα ερευνηθεί κι έπειτα εντοπίζονται οι προς έλεγχο παράγοντες και οργανώνεται ο τρόπος συλλογής των δεδομένων. Για την αποφυγή λαθών και τη διασφάλιση ότι ελέγχεται η σχέση για την οποία ετέθησαν οι υποθέσεις της έρευνας, οργανώνεται η μελέτη σύμφωνα με το αδελφικό έργο ανάπτυξης (sister project) ή τη γραμμή βάσης (baseline) ή την τυχαία επιλογή (random selection). Αδελφικά έργα είναι αυτά που έχουν παρόμοιο πεδίο εφαρμογής, γλώσσα υλοποίησης, τεχνική ορισμού προδιαγραφών και μέθοδο σχεδίασης. Συνήθως εκτελούνται επισκοπήσεις ως προς την κατάσταση που διερευνάται στο ένα έργο με την τρέχουσα κατάσταση που διερευνάται στο ένα έργο με την τρέχουσα κατάσταση στο αδελφικό έργο και κατόπιν συγκρίνονται τα αποτελέσματα. Τα έργα ανάπτυξης που επιλέγονται πρέπει να είναι όσο το δυνατόν παρόμοια και πρέπει να ελέγχονται όσο το δυνατόν περισσότεροι παράμετροι. Όταν δεν μπορούν να βρεθούν δύο παρόμοια (αδελφικά) έργα, τότε η επισκόπηση μπορεί να γίνει με μία γραμμή βάσης, δηλαδή να συλλεχθούν τα δεδομένα από διάφορα έργα που υλοποιεί η εταιρία, ανεξάρτητα από τις διαφορές που παρουσιάζουν. Από τα δεδομένα των μετρήσεων που είναι περιγραφικού τύπου, μπορεί να υπολογισθεί η κεντρική ροπή και η διασπορά των δεδομένων, παρέχοντας μια εικόνα για τη μέση κατάσταση των έργων. Όταν δεν υπάρχει η δυνατότητα επισκόπησης σε δύο ή περισσότερα έργα, τότε μπορεί να επιλεγεί η τυχαία επιλογή, δηλαδή να διαχωριστεί ένα έργο σε μέρη, όπου σε κάποιο από αυτά εφαρμόζεται η προς διερεύνηση 12

κατάσταση. Η τυχαία επιλογή και η επαναληπτική ανάλυση των δεδομένων βοηθούν στον καλύτερο έλεγχο και στη μείωση του πειραματικού σφάλματος. Οι μελέτες περίπτωσης έχουν πλεονεκτήματα και μειονεκτήματα. Είναι ιδιαίτερα σημαντικές, γιατί ενσωματώνουν χαρακτηριστικά, όπως η κλιμάκωση, η πολυπλοκότητα και ο δυναμισμός, που δεν μπορούν να απεικονιστούν με τις άλλες μεθόδους. Το μεγαλύτερο μειονέκτημα της μεθόδου είναι η έλλειψη ελέγχου της κατάστασης που διερευνάται, με συνέπεια τα αποτελέσματα να μη γίνονται αποδεκτά με βεβαιότητα. Επίσης, οι μικρές ή απλοποιημένες μελέτες περίπτωσης σπάνια αποτελούν ένα καλό όργανο για την ανακάλυψη αρχών και τεχνικών που αφορούν την τεχνολογία λογισμικού. 1.1.3 Τυπικό ή Ελεγχόμενο Πείραμα - Formal Experiment Το τυπικό πείραμα πραγματοποιείται, όταν απαιτείται ο πλήρης έλεγχος μιας κατάστασης καθώς και ο ακριβής και ο άμεσος χειρισμός της [20, 22]. Το τυπικό πείραμα είναι η κατάλληλη μέθοδος όταν ερευνώνται θέματα όπως: Επιβεβαίωση θεωριών Επιβεβαίωση συμβατικής γνώσης Έρευνα συσχετίσεων Αξιολόγηση της ακρίβειας των μοντέλων\επαλήθευση μετρήσεων Για την οργάνωση και εκτέλεση ενός τυπικού πειράματος απαιτείται μία ξεκάθαρα δηλωμένη υπόθεση (hypothesis) που διατυπώνει μία σχέση αιτίουαποτελέσματος (cause-effect). Στη σχεδίασης του πειράματος ορίζεται πρώτα το αντικείμενο της μελέτης, δηλαδή η οντότητα που θα μελετηθεί στο πείραμα, για παράδειγμα ένα προϊόν, μια διαδικασία, μία πηγή ή μέσο, ένα μοντέλο, ένα σύστημα μετρικών ή τέλος μια θεωρία. Έπειτα, καθορίζονται τα διάφορα αντικείμενα πειραματισμού (treatments), δηλαδή οι διάφορες καταστάσεις που θα συγκριθούν ή αξιολογηθούν όπως δραστηριότητες, μέθοδοι ή εργαλεία. Σε ένα πείραμα η ανάθεση στα συμμετέχοντα άτομα υποκείμενα (subjects) ενός αντικειμένου πειραματισμού γίνεται με τυχαία κατανομή (random sampling) σε μία ξεχωριστή δοκιμαστική 13

εκτέλεση που ονομάζεται δοκιμασία (trial). Στη συνέχεια ορίζονται οι ανεξάρτητες (independent variables) και οι εξαρτημένες μεταβλητές (dependent variables) του πειράματος. Οι ανεξάρτητες μεταβλητές είναι μεταβλητές εισόδου, δηλαδή οι παράγοντες που θα πάρουν διαφορετικές τιμές, ώστε να μελετηθεί η επίδραση των αλλαγών στις ανεξάρτητες μεταβλητές. Πολλά είναι τα πλεονεκτήματα από τη διεξαγωγή ενός τυπικού πειράματος αντί μιας μελέτης περίπτωσης [23]. Το πιο σημαντικό είναι ότι τα αποτελέσματα ενός πειράματος μπορούν ευκολότερα να γενικευτούν από αυτά της μελέτης περίπτωσης. Ένα άλλο πλεονέκτημα είναι ότι διασφαλίζει τον ερευνητή με ένα μεγαλύτερο βαθμό ελέγχου από ότι στις μελέτες περίπτωσης. Όμως θα πρέπει να λάβουμε υπόψη ότι πραγματοποιούνται σε εργαστηριακό περιβάλλον και ότι είναι μελέτες που αφορούν έρευνες μικρής έκτασης. Πολλά από τα πλεονεκτήματα που προκύπτουν από τη διεξαγωγή ενός τυπικού πειράματος αντί μιας μελέτης περίπτωσης [23]. Το πιο σημαντικό είναι ότι τα αποτελέσματα ενός πειράματος μπορούν ευκολότερα να γενικευθούν από αυτά της μελέτης περίπτωσης. Ένα άλλο πλεονέκτημα είναι ότι διασφαλίζει τον ερευνητή με ένα μεγαλύτερο βαθμό ελέγχου από ότι στις μελέτες περίπτωσης. Όμως θα πρέπει να λάβουμε υπόψη ότι πραγματοποιούνται σε εργαστηριακό περιβάλλον και ότι είναι μελέτες που αφορούν έρευνες μικρής έκτασης. Η διεξαγωγή ενός πειράματος απαιτεί μια διαδικασία πέντε βημάτων [20]: Τον ορισμό (definition), όπου καθορίζεται το ερευνητικό αντικείμενο. Το σχεδιασμό (planning), όπου καθορίζεται το σχέδιο του πειράματος και εντοπίζονται οι πιθανές απειλές. Την εκτέλεση (operation), όπου εκτελείται το πείραμα σύμφωνα με τον σχεδιασμό. Την ανάλυση και ερμηνεία (analysis and interpretation) των μετρήσεων, όπου οι μετρήσεις θα αναλυθούν και θα εκτιμηθούν. Την συγκέντρωση και παρουσίαση (package and presentation) των αποτελεσμάτων, όπου τα αποτελέσματα θα συγκεντρωθούν, μορφοποιηθούν και παρουσιαστούν 14

1.2 Αρχές Αντικειμενοστραφούς Σχεδίασης - Design Principles Κατά τη διάρκεια της σχεδίασης οποιουδήποτε τεχνικού έργου, επιδιώκεται η αποσύνθεση του συστήματος σε τμήματα, η ανάθεση αρμοδιοτήτων σε κάθε τμήμα και η επικύρωση ότι όλα τα τμήματα μαζί επιτυγχάνουν τους σκοπούς του συστήματος. στα πλαίσια του λογισμικού, η σχεδίαση είναι μία διαδικασία επίλυσης, της οποίας στόχος είναι η περιγραφή του τρόπου υλοποίησης των λειτουργικών απαιτήσεων, υπό τους περιορισμούς που θέτουν οι μη λειτουργικές απαιτήσεις και η οποία συμμορφώνεται με συγκεκριμένες αρχές καλής ποιότητας. Παρόλο που είναι σχετικά δύσκολο να οριστεί τι συνιστά καλή αντικειμενοστραφή σχεδίαση (χρησιμοποιώντας πρότυπα όπως το ISO 9001 και ISO 9126), είναι αρκετά ευκολότερο να διατυπωθούν τα συμπτώματα μιας σχεδίασης κακής ποιότητας, τα συμπτώματα μπορούν να παρουσιαστούν είτε κατά την αρχική ανάπτυξη του λογισμικού, είτε πολύ περισσότερο κατά την εξέλιξη που υφίσταται στη διάρκεια της ζωής του είναι τα εξής (Martin 2003):δυσκαμψία (rigidity), ευθραυστότητα (fragility), ακινησία (immobility), έλλειψη ρευστότητας (viscosity), περιττή πολυπλοκότητα (needless comlexity), περιττή επανάληψη (needless repetition), αδιαφάνεια (opacity). Στη συνέχεια αναλύονται οι αρχές (principles) που πρέπει να διέπουν την αντικειμενοστραφή σχεδίαση ενός συστήματος λογισμικού. Η παραβίαση μίας ή περισσότερων από αυτές τις αρχές οδηγεί σχεδόν με βεβαιότητα σε περισσότερα από ένα από τα παραπάνω συμπτώματα. Οι αρχές αυτές είναι: 1. Αρχή της ανοιχτής κλειστής σχεδίασης : Οι οντότητες λογισμικού (κλάσεις, συναρτήσεις, μονάδες) θα πρέπει να είναι ανοιχτές για επέκταση αλλά κλειστές για τροποποίηση. Η ιδιότητα ανοιχτές για επέκταση σημαίνει ότι η συμπεριφορά της μονάδας μπορεί να επεκταθεί, προσθέτοντας νέες λειτουργίες που ικανοποιούν τις καινούργιες απαιτήσεις, ενώ με την ιδιότητα κλειστές για τροποποίηση νοείται ότι η επέκταση της συμπεριφοράς δεν οδηγεί σε αλλαγές στον πηγαίο κώδικα. Με άλλα λόγια, προστίθεται νέα λειτουργικότητα χωρίς να τροποποιηθεί η εκτελέσιμη εκδοχή της μονάδας. 15

2. Αρχή της ενσωμάτωσης : Η εσωτερική κατάσταση ενός αντικειμένου πρέπει να είναι τροποποιήσιμη μόνο μέσω της δημόσιας διασύνδεσής του. Σύμφωνα με αυτή την αρχή, οι ιδιότητες των κλάσεων πρέπει να μην είναι προσπελάσιμες εκτός της κλάσης, δηλαδή η τροποποίηση των ιδιοτήτων θα πρέπει να επιδιώκεται μόνο μέσω της πρόσβασης που παρέχουν οι δημόσια διαθέσιμες μέθοδοι. το πλεονέκτημα που προκύπτει από την εφαρμογή αυτής της αρχής σχετίζεται με τη δυνατότητα διατήρησης της εγκυρότητας και συνέπειας της κατάστασης ενός αντικειμένου. 3. Αρχή της χαμηλής σύζευξης : Σε ένα σχέδιο λογισμικού πρέπει να επιδιώκεται η επίτευξη της μικρότερης δυνατής σύζευξης μεταξύ των συστατικών του. Η επιδίωξη της δυνατότερης χαμηλής σύζευξης, κυρίως χρησιμοποιώντας της τεχνικές της αφαίρεσης και της απόκρυψης πληροφορίας, εξασφαλίζει ανεξαρτησία μεταξύ των συστατικών του σχεδίου. Με αυτό τον τρόπο γίνεται ευκολότερη η υλοποίηση, ο έλεγχος και η συντήρηση του λογισμικού. 4. Αρχή της μοναδικής αρμοδιότητας : Μία κλάση πρέπει να έχει μόνο ένα λόγο να αλλάξει. Η αρχή αυτή ουσιαστικά εξασφαλίζει υψηλή συνεκτικότητα για τα συστατικά ενός συστήματος λογισμικού. 5. Αρχή της υποκατάστασης της Liskov : Οι παράγωγοι τύποι θα πρέπει να μπορούν να υποκαθιστούν τους βασικούς τύπους. Σύμφωνα με την Liskov «Αυτό που είναι επιθυμητό στον αντικειμενοστραφή προγραμματισμό είναι κάτι σαν την ακόλουθη ιδιότητα υποκατάστασης: Αν για κάθε αντικείμενο ο1 του τύπου S υπάρχει ένα αντικείμενο ο2 του τύπου T τέτοιο ώστε για όλα τα προγράμματα P που ορίζονται υπό τους όρους του T, η συμπεριφορά του P παραμένει αναλλοίωτη όταν το ο1 υποκαταστήσει το ο2 τότε ο S είναι παράγωγος τύπος (υποκατηγορία) του T». 6. Αρχή της αντιστροφής των εξαρτήσεων : Οι μονάδες υψηλού επιπέδου δεν θα πρέπει να εξαρτώνται από μονάδες χαμηλού επιπέδου, και οι αφαιρέσεις δεν θα πρέπει να εξαρτώνται από λεπτομέρειες, αλλά οι λεπτομέρειες θα πρέπει να εξαρτώνται από αφαιρέσεις. Στόχος της αρχή αυτής είναι να αντιστρέφει πλήρως τη δομή ενός συστήματος λογισμικού, έτσι ώστε οι μονάδες υψηλού επιπέδου να μην εξαρτώνται αλλά να καθορίζουν τους 16

κανόνες για τις μονάδες χαμηλού επιπέδου. Ένας έμπειρος σχεδιαστής θα πρέπει να μπορεί να διαπιστώσει εύκολα αν η δομή ενός συστήματος είναι πράγματι «αντεστραμμένη». 7. Αρχή του διαχωρισμού των διασυνδέσεων : πολλές εξειδικευμένες διασυνδέσεις είναι προτιμότερες από μία γενική διασύνδεση και οι πελάτες δεν θα πρέπει να εξαναγκάζονται σε εξάρτηση από μεθόδους που δεν χρησιμοποιούν. Η αρχή του διαχωρισμού των διασυνδέσεων διαπραγματεύεται τα μειονεκτήματα των ογκωδών διασυνδέσεων. Οι κλάσεις που έχουν μεγάλο αριθμό δημόσιων μεθόδων είναι κλάσεις των οποίων η διασύνδεση δεν είναι συνεκτική και οι μέθοδοι κατά πάσα πιθανότητα μπορούν να διαχωριστούν σε ένα σύνολο διασυνδέσεων. κάθε σύνολο εξυπηρετεί μία διαφορετική ομάδα από πελάτες και παρουσιάζει ψηλότερη συνεκτικότητα από την αρχική διασύνδεση. 1.3 Πρότυπα σχεδίασης Design Patterns Τα σχεδιαστικά πρότυπα (design patterns), χρησιμοποιούνται ευρέως στον αντικειμενοστραφή προγραμματισμό, καθώς παρέχουν τη δυνατότητα επαναχρησιμοποίησης της σχεδίασης, τη δυνατότητα δηλαδή τυποποίησης και τεκμηρίωσης μιας μεθόδου, για την επίλυση ενός συγκεκριμένου προβλήματος, με τρόπο που να επιτρέπει την επιτυχή εφαρμογή της σε παρόμοιες κλάσεις προβλημάτων. Για να δοθεί υπόσταση ή μορφή στη μέθοδο, η οποία υφίσταται επαναχρησιμοποίηση, θα πρέπει να εντοπιστούν δομικές, συμπεριφορολογικές και λειτουργικές ομοιότητες σε παρόμοιες αλλά διαφορετικές περιπτώσεις προβλημάτων, για τη συνέχισή τυποποίηση της επαναλαμβανόμενης σχεδιαστικής λογικής. Όταν τα πρότυπα τυποποιούνται ή παρέχουν όλη την απαραίτητη πληροφορία για την εφαρμογή του προτύπου, τότε γίνονται τεκμηριωμένα σχεδιαστικά πρότυπα. Στη συνέχεια παρατίθενται κάποιοι ορισμοί της έννοιας του προτύπου. Σύμφωνα με τον Alexander [24] κ.λπ. «κάθε πρότυπο περιγράφει ένα πρόβλημα που εμφανίζεται ξανά και ξανά στο περιβάλλον μας και στη συνέχεια περιγράφει την καρδία της λύσης σε αυτό το πρόβλημα, με τέτοιο τρόπο ώστε κάποιος να μπορεί να 17

χρησιμοποιήσει αυτή τη λύση ξανά ένα εκατομμύριο φορές, χωρίς ποτέ να τη χρησιμοποιήσει με τον ίδιο τρόπο δύο φορές» Σύμφωνα με τον Larman [25] «το πρότυπο είναι ένα ονομαζόμενο ζευγάρι προβλήματος/λύσης που μπορεί να εφαρμοστεί σε νέα πλαίσια, με συμβουλές για το πώς πρέπει να εφαρμοστεί αυτό σε καινοφανείς καταστάσεις». Στην τεχνολογία λογισμικού, ένα σχεδιαστικό πρότυπο είναι μία γενική επαναλαμβανόμενη λύση για ένα εμφανιζόμενο πρόβλημα σε κάποια σχεδίαση λογισμικού (software design). Ένα σχεδιαστικό πρότυπο δεν είναι κάποια ολοκληρωμένη σχεδίαση η οποία μπορεί να μετασχηματιστεί άμεσα σε έναν κώδικα. Αποτελεί μία περιγραφή ή ένα πρότυπο για το πώς μπορεί να λυθεί ένα πρόβλημα, το οποίο μπορεί να χρησιμοποιηθεί σε πολλές διαφορετικές καταστάσεις. Τα αντικειμενοστραφή πρότυπα σχεδίασης παρουσιάζουν τις σχέσεις και τις αλληλεπιδράσεις μεταξύ των κλάσεων και των αντικειμένων, χωρίς όμως να προσδιορίζονται οι τελικές κλάσεις και τα αντικείμενα που συμπεριλαμβάνονται. Στο σημείο αυτό αξίζει να αναφέρουμε ότι η χρησιμοποίηση των προτύπων στην ανάπτυξη λογισμικού έχει τις ρίζες της στη δουλειά του Christopher Alexander, ενός αρχιτέκτονα. Ο Alexander ανέπτυξε μια γλώσσα προτύπων για το σχεδιασμό πόλεων και το σχεδιασμό των κτιρίων μέσα σε αυτές [24]. Μια γλώσσα προτύπων είναι μια συλλογή από πρότυπα που μπορούν να συνδυαστούν, ώστε να λύσουν μια σειρά από προβλήματα σε ένα συγκεκριμένο πεδίο εφαρμογής, όπως η αρχιτεκτονική ή η ανάπτυξη λογισμικού. Η δουλειά του Alexander κωδικοποίησε μεγάλο μέρος από ότι υπονοούνταν, μέχρι τότε, στον τομέα της αρχιτεκτονικής και τα οποία απαιτούσαν χρόνια εμπειρίας από κάποιον για να τα μάθει και έδωσε τις βάσεις για την ανάπτυξη των προτύπων. Τα πρότυπα σχεδίασης επιταχύνουν την διαδικασία ανάπτυξης, παρέχοντας δοκιμασμένα και αποδεδειγμένα παραδείγματα ανάπτυξης. Η επαναχρησιμοποίηση των πρότυπων σχεδίασης βοηθά στην αποτροπή λεπτών ζητημάτων, που όμως μπορούν να προκαλέσουν σοβαρά προβλήματα, ενώ παράλληλα βελτιώνουν την αναγνωσιμότητα του κώδικα. Τα πρότυπα σχεδίασης αποτελούνται από πολλά τμήματα. Τα πιο ενδιαφέροντα από αυτά είναι η δομή, οι συμμετέχοντες, και τα τμήματα συνεργασίας. Τα τμήματα αυτά περιγράφουν ένα μοτίβο σχεδίου, μια πρωτότυπη μικροαρχιτεκτονική που οι προγραμματιστές αντιγράφουν και την 18

προσαρμόζουν στο εκάστοτε σχέδιο που αναπτύσσουν. Μια μικροαρχιτεκτονική είναι ένα σύνολο των συστατικών του προγράμματος και των σχέσεων μεταξύ τους. Οι προγραμματιστές χρησιμοποιούν τα πρότυπα σχεδίασης, εισάγοντας στα σχέδιά τους αυτή τη πρωτότυπη μικροαρχιτεκτονική, κάτι που σημαίνει ότι τα σχέδια τους θα έχουν δομή ή οργάνωση παρόμοια με αυτή του επιλεγμένου μοτίβου. Επιπλέον τα design patterns επιτρέπουν στους προγραμματιστές να επικοινωνήσουν χρησιμοποιώντας γνωστά και κατανοητά ονόματα για τις αλληλεπιδράσεις λογισμικού. Ένα πρότυπο σχεδίασης προσδιορίζει τις βασικές πτυχές μιας κοινής σχεδίασης, γεγονός που το καθιστά χρήσιμο για τη δημιουργία ενός επαναχρησιμοποιημένου αντικειμενοστραφούς σχεδίου. To πρότυπο σχεδίασης προσδιορίζει τις συμμετέχουσες κλάσεις, τους ρόλους τους, τον τρόπο συνεργασίας τους και την κατανομή των ρόλων. Κάθε πρότυπα σχεδίασης εστιάζει σε ένα συγκεκριμένο αντικειμενοστραφές πρόβλημα, περιγράφοντας πότε ισχύει, εάν μπορεί ή όχι να εφαρμοστεί λαμβάνοντας υπόψη άλλους περιορισμούς σχεδίασης, καθώς και τις συνέπειες χρήσης τους.. δεδομένου ότι ο βασικός στόχος είναι να εφαρμοστεί το σχέδιο, ένα deign pattern παρέχει επίσης και δείγματα κώδικα που εξηγούν την εκάστοτε εφαρμογή. Τα πρότυπα σχεδίασης περιγράφουν αντικειμενοστραφή σχέδια, βασισμένα σε πρακτικές λύσεις και εφαρμόζονται σε πολλές γλώσσες αντικειμενοστραφούς προγραμματισμού. Μια ταξινόμηση των προτύπων σχεδίασης βασιζόμενη στον τύπο του προβλήματος που επιλύουν, περιλαμβάνει τα fundamental patterns, τα creational patterns, τα structural patterns, τα behavioral patterns και τα concurrency patterns. Τα creational είναι πρότυπα σχεδίασης, που σχετίζονται με μηχανισμούς δημιουργίας αντικειμένων, προσπαθώντας να δημιουργήσουν αντικείμενα, με τέτοιο τρόπο, που να ταιριάζουν στην εκάστοτε κατάσταση. Η βασική φόρμα δημιουργίας αντικειμένων μπορεί να οδηγήσει σε προβλήματα σχεδίασης, ή να αυξήσει την πολυπλοκότητα του σχεδίου. Τα Creational πρότυπα σχεδίασης επιλύουν αυτό το πρόβλημα, ελέγχοντας κατά κάποιο τρόπο τη διαδικασία δημιουργίας αντικειμένων. Σε ό,τι αφορά στα structural πρότυπα σχεδίασης, αυτά αποτελούν πρότυπα σχεδίασης που διευκολύνουν τη σχεδίαση προσδιορίζοντας ένα απλό τρόπο για την πραγματοποίηση των επιθυμητών σχέσεων μεταξύ των οντοτήτων. Τέλος, σχετικά με τα behavioral πρότυπα, είναι πρότυπα σχεδίασης που προσδιορίζουν τα κοινά σχέδια επικοινωνίας (communication patterns), μεταξύ των αντικειμένων και πραγματοποιούν την 19

επικοινωνία αυτή. Με τον τρόπο αυτό, τα συγκεκριμένα πρότυπα αυξάνουν την ευελιξία πραγματοποίησης της επικοινωνίας. Ένα καλά ορισμένο πρότυπο σχεδίασης θα πρέπει να περιέχει και λεπτομερή περιγραφή ορισμένων επιθυμητών ιδιοτήτων. Στις ιδιότητες αυτές συγκαταλέγονται η ενθυλάκωση (encapsulation) και η αφαίρεση (abstraction). Σύμφωνα με αυτές, κάθε σχέδιο που τοποθετεί ένα καλά ορισμένο πρόβλημα, και τη λύση του σε μια περιοχή, θα πρέπει να παρέχει σαφή όρια τόσο της έκτασης του προβλήματος όσο και της λύσης του. Μια άλλη ιδιότητα αποτελεί η λεγόμενη διαθεσιμότητα ή μεταβλητότητα (openness ή variability). Κάθε πρότυπο θα πρέπει να είναι διαθέσιμο για επέκταση ή παραμετροποίηση από άλλα πρότυπα, έτσι ώστε αν χρειαστεί να λειτουργήσουν μαζί για να λυθεί ένα μεγαλύτερο πρόβλημα. Μια λύση επίσης, θα πρέπει να μπορεί να πραγματοποιηθεί από μια μεγάλη ποικιλία εφαρμογών, είτε μεμονωμένα, είτε σε συνδυασμό με άλλα πρότυπα σχεδίασης. Ακόμα μια ιδιότητα είναι η λεγόμενη Generativity και Composability. Κάθε πρότυπο σχεδίασης, μόλις εφαρμοστεί παράγει ένα πλαίσιο που ταιριάζει με το αρχικό ενός ή περισσοτέρων προτύπων. Αυτά τα μεταγενέστερα πρότυπα, μπορούν να εφαρμοστούν για να προχωρήσουμε περαιτέρω προς τον τελικό στόχο, τη δημιουργία δηλαδή μιας ολοκληρωμένης γενικής λύσης. Η εφαρμογή ενός προτύπου παρέχει ένα πλαίσιο για την εφαρμογή ενός επόμενου προτύπου. Η τελευταία ιδιότητα που θα αναφερθεί, είναι η ισορροπία (equilibrium). Κάθε design pattern πρέπει να διατηρήσει μια ισορροπία μεταξύ των δυνατοτήτων και των περιορισμών του. Με την περιγραφή των παραπάνω δυνατοτήτων τα στοιχεία ενός design pattern μπορούν να συνεργαστούν για να ικανοποιήσουν τελικά τις ποικίλες απαιτήσεις. Στο [5], ο Gamma κ.λπ. ορίζουν τέσσερα θεμελιώδη στοιχεία για τα πρότυπα. Τα αναφέρουμε στη συνέχεια για να τα συγκρίνουμε αργότερα με τα στοιχεία των αντιπροτύπων: Όνομα το όνομα του προτύπου ορίζει το πρότυπο σύμφωνα με έναν κατανοητό και ξεκάθαρο όρο. Το προσεγμένο όνομα επιτρέπει τους ανθρώπους να εφαρμόσουν κοινό λεξιλόγιο για την περιγραφή. Πρόβλημα η περιγραφή και το πλαίσιο του προβλήματος για το οποίο το δοθέν πρότυπο παρέχει μια λύση. 20

Λύση τα χαρακτηριστικά και η αφηρημένη περιγραφή της λύσης και των περιορισμών στους οποίους είναι έγκυρη. Συνέπειες τα (θετικά) αποτελέσματα και οι ισορροπίες που θα αποτελέσουν τις συνέπειες από την εφαρμογή του προτύπου. Τα πρότυπα λογισμικού αναπαριστούν τη γνώση για επιτυχημένες λύσεις σε επαναλαμβανόμενα προβλήματα με περιορισμούς που βασίζονται στα συμφραζόμενα [5], [24]. Η χρήση των προτύπων αυξάνεται ολοένα και περισσότερο, όχι μόνο για να συλλάβουν και να διαδώσουν τις καλές πρακτικές αλλά και για να μετατρέψουν τα πρότυπα σε ένα διαμοιραζόμενο λεξιλόγιο για την έκφραση και τη διάδοση της τεχνικής γνώσης [26], [27]. Ωστόσο, οι πολύπλοκες διασυνδέσεις και ο αριθμός των συλλογών των προτύπων γίνονται σταδιακά ένα εμπόδιο για την ταυτοποίηση σχετικών προτύπων και συνδυασμών προτύπων για ένα πλαίσιο σχεδιασμού που δίνεται [28]. 1.3.1 Προσαρμογέας (Adapter) Το πρότυπο σχεδίασης Προσαρμογέας (Adapter) έχει ως στόχο την μετατροπή της διασύνδεσης μιας κλάσης σε μια άλλη που αναμένει το πρόγραμμα πελάτης. Ο προσαρμογέας επιτρέπει τη συνεργασία κλάσεων, η οποία σε διαφορετική περίπτωση θα ήταν αδύνατη λόγω ασύμβατων διασυνδέσεων 1.3.1.1 Γενικά Συχνά, ο κώδικας μιας κλάσης προσφέρεται για επαναχρησιμοποίηση, αλλά αυτή δεν είναι δυνατή λόγω του ότι τα προγράμματα που επιθυμούν να χρησιμοποιήσουν τις λειτουργίες της, αναμένουν διαφορετική διασύνδεση. Στη συνήθη περίπτωση, όπου τα προγράμματα πελάτες δεν είναι δυνατόν να τροποποιηθούν ( καθώς βρίσκονται ήδη εγκατεστημένα σε διάφορα πεδία εφαρμογών), ενώ και η κλάση Σχεδίασης είναι επιθυμητό να χρησιμοποιηθεί χωρίς τροποποίηση (καθώς οποιαδήποτε επέμβαση στον κώδικα μιας μεθόδου είναι δυνατόν να προκαλέσει σφάλματα στις υπόλοιπες μεθόδους), βρίσκει εφαρμογή το πρότυπο Προσαρμογέας. 21

1.3.1.2 Γενική Δομή 1.3.1.3 Εφαρμογή Ένας προσαρμογέας χρησιμοποιείται όταν : Θέλετε να χρησιμοποιήσετε μια υπάρχουσα κλάση, αλλά η διασύνδεσή της δεν συμβαδίζει με τις ανάγκες σας. 1.3.2 Σύνθετο (Composite) Το πρότυπο σχεδίασης Σύνθετο (Composite) επιτρέπει τη σύνθεση των αντικειμένων σε δενδροειδείς δομές για την αναπαράσταση ιεραρχιών τμήματοςόλου. Το πρότυπο σχεδίασης Σύνθετο Επιτρέπει στο προγράμματα πελάτες να διαχειρίζονται με ενιαίο τρόπο τόσο τα ανεξάρτητα αντικείμενα, όσο και συνθέσεις αντικειμένων. 1.3.2.1 Γενικά Πολύ συχνά, σε μια εφαρμογή, εκτός από μεμονωμένα αντικείμενα (π.χ. Τροχός, Μηχανή, Κάθισμα), υφίστανται και σύνθετα αντικείμενα που περιέχουν ή περιλαμβάνουν άλλα αντικείμενα (π.χ. Αυτοκίνητο). Η σχέση περιεκτικότητας μπορεί να είναι ασθενούς μορφής (συσσωμάτωση) είτε ισχυρής μορφής (σύνθεση). Η συνήθης αντιμετώπιση μιας τέτοιας περίπτωσης με τη χρήση μιας σχέσης περιεκτικότητας μεταξύ της κλάσης που αντιπροσωπεύει το όλον (περικλείουσα κλάση) και των κλάσεων που αντιπροσωπεύουν τα τμήματα, έχει το μειονέκτημα ότι δεν επιτρέπει τον ομοιόμορφο χειρισμό των αντικειμένων από ένα πρόγραμμα 22

πελάτη. Για παράδειγμα, μια άλλη εφαρμογή, θα πρέπει να διατηρεί δείκτες και προς αντικείμενα τύπου Τροχός, Μηχανή, Κάθισμα, αλλά και δείκτες προς αντικείμενα τύπου Αυτοκίνητο. Λαμβάνοντας υπόψη τους πρωταρχικούς στόχους του αντικειμενοστραφούς προγραμματισμού, αν προστεθεί στο σύστημα μια νέα σύνθετη κλάση (π.χ. Λεωφορείο), τότε ο κώδικας του προγράμματος πελάτη, θα πρέπει να τροποποιηθεί για να είναι δυνατός ο χειρισμός των νέων αντικειμένων τύπου Λεωφορείο. Η αντιμετώπιση αυτού του προβλήματος, επιτυγχάνεται με κομψό τρόπο με το πρότυπο σχεδίασης Σύνθετο. 1.3.2.2 Γενική Δομή 1.3.2.3 Εφαρμογή Το πρότυπο σχεδίασης Σύνθετο χρησιμοποιείται όταν : Θέλετε τα προγράμματα πελάτες να μπορούν να χειρίζονται μεμονωμένα αντικείμενα και σύνθετα αντικείμενα (συλλογές από άλλα αντικείμενα )με τον ίδιο τρόπο. 1.3.3 Μοναδιαίο (Singleton) Το πρότυπο σχεδίασης Σύνθετο (Singleton) εξασφαλίζει ότι μία κλάση θα έχει ένα μόνο στιγμιότυπο και παρέχει ένα καθολικό σημείο πρόσβασης σε αυτό. 23

1.3.3.1 Γενικά Συνήθως μεταξύ των κλάσεων και των στιγμιότυπων τους υπάρχει μια σχέση ένα-προς-πολλά. Κατά τη διαδικασία της ανάλυσης, η ύπαρξη πολλών στιγμιότυπων της ίδιας έννοιας στο σύστημα, υποδηλώνει την αναγκαιότητα μιας κλάσης. Τα αντικείμενα δημιουργούνται δεσμεύοντας χώρο στη μνήμη οπότε κρίνεται σκόπιμο και διαγράφονται από τη μνήμη όταν τερματιστεί η χρήση τους. Ορισμένες όμως φορές, απαιτείται η ύπαρξη κλάσεων από τις οποίες παράγεται ένα μόνο αντικείμενο. Πολύ συχνά, το αντικείμενο αυτό δημιουργείται κατά την έναρξη της εφαρμογής και διαγράφεται με το πέρας της. Ο ρόλος του μοναδικού αυτού αντικειμένου, είναι η διαχείριση των υπολοίπων αντικειμένων της εφαρμογής και για τον λόγο αυτό, αποτελεί λογικό σφάλμα να δημιουργηθούν περισσότερα του ενός αντικείμενα-διαχειριστές (managers ή controllers). Σε μια τέτοια περίπτωση, η εφαρμογή θα έχει περισσότερα του ενός σημεία εκκίνησης, και ο υποθετικός χρήστης, ανάλογα με το σημείο εκκίνησης, μπορεί να καταλήξει να χρησιμοποιεί ένα υποσύνολο των αντικειμένων του συστήματος. Επιπλέον, αν υπάρχουν περισσότεροι του ενός διαχειριστές, ενώ ο επιθυμητός στόχος είναι η ακολουθιακή εκτέλεση δραστηριοτήτων, πολλές δραστηριότητες θα εκτελούνται παράλληλα. Το πρότυπο σχεδίασης Μοναδιαίο, εξασφαλίζει τη δημιουργία ενός και μόνο αντικειμένου, περιλαμβάνοντας μια ειδική μέθοδο κατασκευής στιγμιότυπων: Όταν καλείται αυτή η μέθοδος, ελέγχει αν κάποιο αντικείμενο έχει ήδη δημιουργηθεί. Αν ναι, η μέθοδος επιστρέφει απλώς έναν δείκτη προς το υπάρχον αντικείμενο. Αν όχι, η μέθοδος δημιουργεί ένα νέο αντικείμενο και επιστρέφει δείκτη προς αυτό Για να εξασφαλισθεί ότι αυτός είναι ο μοναδικός τρόπος δημιουργίας αντικειμένων από αυτή την κλάση, ο κατασκευαστής της κλάσης δηλώνεται ως προστατευόμενος (protected) ή ιδιωτικός (private) με τον τρόπο αυτό, δεν είναι δυνατόν να δημιουργηθεί ένα αντικείμενο παρακάμπτοντας την παραπάνω ειδική μέθοδο 24

1.3.3.2 Γενική Δομή 1.3.3.3 Εφαρμογή Το πρότυπο σχεδίασης μοναδιαίο (Singleton) χρησιμοποιείται όταν: Σε κάποιο σύστημα λογισμικού υπάρχει η απαίτηση από μία κλάση να δημιουργείται ένα και μόνο αντικείμενο. 1.3.4 Γέφυρα (Bridge) Το πρότυπο σχεδίασης Γέφυρα ( Bridge ) έχει ως στόχο την αποσύνδεση μίας αφαίρεσης από την υλοποίηση της, ώστε να μπορούν να μεταβάλλονται ανεξάρτητα. 1.3.4.1 Γενικά Όταν η αφαίρεση μπορεί να έχει περισσότερες από μία υλοποιήσεις, ο συνήθης τρόπος οργάνωσης είναι με τη χρήση της κληρονομικότητας. Με τον όρο αφαίρεση νοείται μια αφηρημένη κλάση που ορίζει μια διασύνδεση (ένα σύνολο υπογραφών), ενώ υλοποιήσεις είναι οι συγκεκριμένες παράγωγες κλάσεις οι οποίες υλοποιούν τις μεθόδους της αφηρημένης κλάσης. Η προσέγγιση αυτή ωστόσο, συνδέει με μόνιμο τρόπο την αφαίρεση και τις υλοποιήσεις, καθιστώντας δύσκολη την επέκταση, τροποποίηση και επαναχρησιμοποίηση αφαιρέσεων και υλοποιήσεων ανεξάρτητα. Το πρότυπο Γέφυρα είναι σχετικά δύσκολο στην κατανόηση του Χρησιμοποιείται ωστόσο σε πληθώρα περιπτώσεων όπου εντοπίζονται: μεταβολές στην αφαίρεση μιας έννοιας Μεταβολές στον τρόπο υλοποίησης της έννοιας αυτής 25

Η γέφυρα αντίκειται στη συνήθη τάση χειρισμού αντίστοιχων καταστάσεων μόνο με κληρονομικότητα. Ικανοποιεί όμως δύο από ους βασικούς κανόνες της αντικειμενοστραφούς κοινότητας: Εντόπισε αυτό που μεταβάλλεται και αντιμετώπισέ το, και προτιμήστε τη σύνθεση αντικειμένων από την κληρονομικότητα κλάσεων. 1.3.4.2 Γενική Δομή 1.3.4.3 Εφαρμογή Μια Γέφυρα χρησιμοποιείται όταν : Μια έννοια (αφαίρεση) μπορεί να σχετίζεται με διάφορες υλοποιήσεις οι οποίες μπορεί να τροποποιούνται κατά τη διάρκεια εκτέλεσης. Οι αφαιρέσεις και οι υλοποιήσεις τους θα πρέπει να είναι επεκτάσιμες μέσω κληρονομικότητας. Σε αυτή την περίπτωση, το πρότυπο Γέφυρα σας επιτρέπει να συνδυάσετε τις διαφορές αφαίρεσης και υλοποιήσεις και να τις επεκτείνετε ανεξάρτητα. 1.3.5 Παρατηρητής (Observer) Το πρότυπο σχεδίασης Παρατηρητής (Observer) είναι επίσης γνωστό ως πρότυπο Δημοσίευση - Εγγραφή (Publish-Subscribe). Ορίζει μα σχέση εξάρτησης ένα-προς-πολλά μεταξύ αντικειμένων έτσι ώστε όταν μεταβάλλεται η κατάσταση ενός αντικειμένου, όλα τα εξαρτώμενα αντικείμενα να ενημερώνονται και τροποποιούνται αυτόματα. 26

1.3.5.1 Γενικά Καθώς ο στόχος της αντικειμενοστραφούς σχεδίασης είναι η δημιουργία ενός συνόλου αλληλεπιδρώντων αντικειμένων, ένα από τα συχνά προβλήματα είναι η αναγκαιότητα συνεργασίας μεταξύ κλάσεων, γεγονός που οδηγεί σε υψηλή σύζευξη. Ορισμένα από τα πρότυπα σχεδίασης, με χαρακτηριστικότερο το πρότυπο Παρατηρητής, επιδιώκουν να μειώσουν τη σύζευξη μεταξύ των αντικειμένων, παρέχοντας αυξημένη δυνατότητα επαναχρησιμοποίησης και τροποποίησης του συστήματος. Το συγκεκριμένο πρότυπο, επιτρέπει την αυτόματη ειδοποίηση και ενημέρωση ενός συνόλου αντικειμένων, τα οποία αναμένουν ένα γεγονός, που εκδηλώνεται ως αλλαγή στην κατάσταση ενός αντικειμένου. Ο στόχος είναι η απόσύζευξη των παρατηρητών από το παρακολουθούμενο αντικείμενο (υποκείμενο), έτσι ώστε κάθε φορά να προστίθεται ένας νέος παρατηρητής ( με διαφορετική διασύνδεση ενδεχομένως), να μην απαιτούνται αλλαγές στο παρακολουθούμενο αντικείμενο. Το συγκεκριμένο πρότυπο είναι από τα πλέον ευρέως χρησιμοποιούμενα και υλοποιείται με σχετική ευκολία σε διάφορες γλώσσες προγραμματισμού. Η εφαρμογή προϋποθέτει τον εντοπισμό των εξής δύο τμημάτων :ενός υποκειμένου και του παρατηρητή. Μεταξύ των δύο υφίσταται μια σχέση ένα-προς-πολλά. Το υποκείμενο θεωρείται ότι διατηρεί το μοντέλο των δεδομένων και η λειτουργικότητα που αφορά την παρατήρηση των δεδομένων κατανέμεται σε διακριτά αντικείμενα παρατηρητές. Οι παρατηρητές καταχωρούνται στο υποκείμενο κατά τη δημιουργία τους. Οποτεδήποτε υο υποκείμενο αλλάζει ανακοινώνει προς όλους τους καταχωρημένους παρατηρητές το γεγονός της αλλαγής, και κάθε παρατηρητής ερωτά το υποκείμενο για το υποσύνολο της κατάστασης του υποκειμένου που το ενδιαφέρει. Στο ανώτερο πρωτόκολλο επικοινωνίας η πληροφορία αντλείται, αντί να αποστέλλεται στους παρατηρητές. Το πρότυπο Παρατηρητής εφαρμόζεται για χρόνια στην ευρέως γνωστή αρχιτεκτονική Μοντέλου-Όψης-Ελεγκτή (Model-View- Controller). 27

1.3.5.2 Γενική Δομή 1.3.5.3 Εφαρμογή Το πρότυπο Παρατηρητής χρησιμοποιείται όταν : Η αλλαγή της κατάστασης ενός αντικειμένου (υποκειμένου) απαιτεί την ειδοποίηση άλλων αντικειμένων (παρατηρητών) αλλά το υποκείμενο δεν θα πρέπει να κάνει καμιά υπόθεση για το ποια είναι αυτά τα αντικείμενα. Η λίστα των παρατηρητών μπορεί να αλλάζει κατά τη διάρκεια εκτέλεσης του προγράμματος. 1.3.6 Επισκέπτης ( Visitor ) Το πρότυπο σχεδίασης επισκέπτης (Visitor) έχει ως στόχο την αναπαράσταση μιας λειτουργίας που πρόκειται να πραγματοποιηθεί στα στοιχεία μιας δομής αντικειμένων. Το πρότυπο επιτρέπει τον ορισμό μιας νέας λειτουργίας χωρίς την τροποποίηση των κλάσεων των στοιχείων στα οποία επιδρά. 1.3.6.1 Γενικά Πολύ συχνά απαιτείται η προσθήκη μιας νέας μεθόδους σε μια υπάρχουσα ιεραρχία κλάσεων αλλά είναι εξαιρετικά δύσκολο να τροποποιηθούν οι ίδιες οι κλάσεις της ιεραρχίας. Η προσέγγιση αυτή ενθαρρύνει την σχεδίαση ιεραρχιών από στοιχεία ελαφρού τύπου καθώς οι αντίστοιχες κλάσεις έχουν περιορισμένες αρμοδιότητες. Νέα λειτουργικότητα μπορεί εύκολα να προστεθεί στη αρχική 28

ιεραρχία, χωρίς την τροποποίηση των ίδιων των κλάσεων, μόνο με τη δημιουργία μιας νέας υποκλάσης στο πρότυπο Επισκέπτης. Το πρότυπο Επισκέπτης έχει αρκετά μεγάλη πολυπλοκότητα στη λειτουργία του καθώς υλοποιεί τη λεγόμενη διπλή αποστολή (double dispatch ή dual dispatch). Τα μηνύματα στον αντικειμενοστραφή προγραμματισμό κατά κανόνα επιδεικνύουν συμπεριφορά που αντιστοιχεί στην απλή αποστολή - η λειτουργία που εκτελείται εξαρτάται από το όνομα της αίτησης και τον τύπο του (μοναδικού) αποδέκτη. Στη διπλή αποστολή η λειτουργία που εκτελείται εξαρτάται από το όνομα της αίτησης και τον τύπο δύο αποδεκτών ( στο συγκεκριμένο πρότυπο από τον τύπο του Επισκέπτη και τον τύπο του στοιχείου που επισκέπτεται). 1.3.6.2 Γενική Δομή 29

1.3.6.2 Εφαρμογή Το πρότυπο Επισκέπτης χρησιμοποιείται όταν : Θέλετε να προσθέσετε λειτουργίες στα αντικείμενα μιας ιεραρχίας αντικειμένων χωρίς να μολύνετε τις κλάσεις τους με αυτές τις λειτουργίες. Το πρότυπο Επισκέπτης σας επιτρέπει να διατηρείτε σχετιζόμενες λειτουργίες σε ένα μέρος ορίζοντας αυτές σε μια ξεχωριστή κλάση. 1.3.7 Αφηρημένο εργοστάσιο (Abstract Factory) Ο σκοπός του προτύπου σχεδίασης Αφηρημένο Εργοστάσιο (Abstract Factory) είναι η παροχή μιας διασύνδεσης για τη δημιουργία οικογενειών συσχετιζόμενων ή εξαρτημένων αντικειμένων χωρίς να προσδιορίζεται η συγκεκριμένη κλάση τους. 1.3.7.1 Γενικά Όλες οι αντικειμενοστραφείς γλώσσες προγραμματισμού έχουν κάποιο προγραμματιστικό ιδίωμα για τη δημιουργία νέων αντικειμένων (π.χ. τον τελεστή new). Τα πρότυπα σχεδίασης που ανήκουν στην κατηγορία των κατασκευαστικών προτύπων (Creational Patterns) επιτρέπουν τη συγγραφή μεθόδων που δημιουργούν νέα αντικείμενα, χωρίς την άμεση χρήση των συγκεκριμένων ιδιωμάτων. Το γεγονός αυτό επιτρέπει να αναπτυχθούν μέθοδοι κλάσεων που παράγουν ομάδες διαφορετικών αντικειμένων καθώς και την επέκτασή τους για νέα αντικείμενα, χωρίς την τροποποίηση του κώδικα των μεθόδων! Σε αντίθετη περίπτωση, η δημιουργία ενός διαφορετικού αντικειμένου για κάθε περίπτωση, θα απαιτούσε τη χρήση ελέγχων if/else ή εντολών switch, στοιχεία που υποδηλώνουν κακή εφαρμογή των αρχών του αντικειμενοστραφούς προγραμματισμού, καθώς δυσχεραίνουν την συντήρηση του λογισμικού. 30

1.3.7.2 Γενική Δομή 1.3.7.3 Εφαρμογή Το πρότυπο Αφηρημένο Εργοστάσιο χρησιμοποιείται : Για την αποφυγή εξάρτησης από συγκεκριμένες κλάσεις όταν απαιτείται η δημιουργία αντικειμένων. Για την ομαδοποίηση μεθόδων που δημιουργούν συσχετιζόμενα αντικείμενα σε μια αφηρημένη κλάση. 1.3.8 Στρατηγική (Strategy) Το πρότυπο σχεδίασης Στρατηγική (Strategy) ορίζει μια οικογένεια αλγορίθμων, τους ενσωματώνει και επιτρέπει την εναλλαγή μεταξύ αυτών. Το πρότυπο δίνει τη δυνατότητα μεταβολής των αλγορίθμων, ανεξάρτητα από τους πελάτες που τους χρησιμοποιούν. 1.3.8.1 Γενικά Το συγκεκριμένο πρότυπο σχετίζεται άμεσα με την αναγκαιότητα συχνής τροποποίησης του λογισμικού και είναι ίσως το πλέον ευρέως χρησιμοποιούμενο, ανεξαρτήτως του αν η εφαρμογή του γίνεται αντιληπτή από τον σχεδιαστή. Αναγνωρίζει ότι σε πολλές εφαρμογές, υπάρχει μία γενική φιλοσοφία στρατηγική που είναι κοινή σε πολλές περιπτώσεις, η συγκεκριμένη υλοποίηση όμως κάθε περίπτωσης είναι διαφορετική. Ουσιαστικά, υπάρχει ένας κοινός γενικός αλγόριθμος 31

(π.χ. εύρεση ελάχιστου, μέγιστου και διάμεσου με ταξινόμηση), η λεπτομερής όμως υλοποίηση του είναι διαφορετική σε κάθε περίπτωση (π.χ. χρήση ταξινόμησης φυσαλίδας ή ταξινόμησης με επιλογή). Στον αντικειμενοστρεφή προγραμματισμό, τα ανωτέρω χαρακτηριστικά παραπέμπουν συνήθως στην κληρονομικότητα. Το πρότυπο Στρατηγική αποτελεί την αντιμετώπιση του προβλήματος στηριζόμενο όχι μόνο στην κληρονομικότητα, αλλά και στην σύνθεση αντικειμένων. 1.3.8.2 Γενική Δομή 1.3.8.2 Εφαρμογή Το πρότυπο Στρατηγική χρησιμοποιείται : όταν ένας αλγόριθμος αναμένεται να έχει πολλές εναλλακτικές υλοποιήσεις. 1.3.9 Μέθοδος Υπόδειγμα ( Template Method) Το πρότυπο σχεδίασης Μέθοδος Υπόδειγμα (Template Method) ορίζει το περίγραμμα ενός αλγορίθμου σε μια λειτουργία, αφήνοντας ορισμένα βήματα στις παράγωγες κλάσεις. Το πρότυπο επιτρέπει στις παράγωγες κλάσεις να επαναορίσουν ορισμένα βήματα του αλγορίθμου χωρίς να αλλάξουν τη δομή του. 1.3.9.1 Γενικά Το πρότυπο επιλύει ένα παρόμοιο πρόβλημα με αυτό που συζητήθηκε στο πρότυπο Στρατηγική. Στόχος είναι ο διαχωρισμός ενός γενικού αλγορίθμου από συγκεκριμένες υλοποιήσεις. Ωστόσο, ενώ το πρότυπο Στρατηγική αξιοποιεί τη δυνατότητα μεταφοράς μίας αρμοδιότητας σε ένα άλλο αντικείμενο μέσω της διαβίβασης μηνυμάτων (delegation), το πρότυπο Μέθοδος Υπόδειγμα εκμεταλλεύεται το μηχανισμό της κληρονομικότητας. Σημειώνεται ότι και αυτό το 32

πρότυπο εφαρμόζεται πολύ συχνά από τους σχεδιαστές αντικειμενοστραφές λογισμικού, ακόμα και αν δε γίνεται αντιληπτό ως ξεχωριστή τεχνική. 1.3.9.2 Γενική Δομή 1.3.9.3 Εφαρμογή Το πρότυπο Μέθοδος υπόδειγμα χρησιμοποιείται : Για τον ορισμό των αμετάβλητων τμημάτων ενός αλγορίθμου σε μια λειτουργία μιας κλάσης και τη μετάθεση της υλοποίησης των μεταβλητών τμημάτων του αλγορίθμου σε παράγωγες κλάσεις. 1.4 Μετρικές Λογισμικού Software Metrics Ο σκοπός των μετρήσεων είναι η ανάθεση αριθμητικών τιμών ή συμβόλων σε χαρακτηριστικά οντοτήτων που υπάρχουν στην πραγματικότητα. Για την πραγματοποίηση των μετρήσεων απαιτείται η ύπαρξη ενός μοντέλου το οποίο να καθορίζει τους κανόνες με βάση τους οποίους με βάση τους οποίους πρέπει να εκτελούνται οι μετρήσεις και να ερμηνεύονται τα αποτελέσματά τους. Σε ένα έργο λογισμικού, όπως και σε οποιoδήποτε τεχνικό έλεγχο, οι μετρήσεις χαρακτηριστικών του λογισμικού, επιτρέπουν την καλύτερη διαχείριση και παρακολούθηση του έργου, μελέτη των ποιοτικών χαρακτηριστικών του και εντοπισμό των σφαλμάτων [29,30]. Ο όρος μετρική αναφέρεται στη ποσοτική εκτίμηση του βαθμού κατά τον οποίο ένα σύστημα ή μια διαδικασία κατέχει ένα συγκεκριμένο χαρακτηριστικό. Μια 33

μετρική λογισμικού συσχετίζει τα λάθη που καταμετρώνται (μέτρα) με κάποιο χαρακτηριστικό του λογισμικού, για παράδειγμα την ποιότητα [29]. 1.4.1 Μετρικές σε επίπεδο κλάσης Η κλάση είναι το συστατικό ενός αντικειμενοστραφούς συστήματος. Ένα σύνολο 6 μετρικών λογισμικού για αντικειμενοστραφή προγράμματα που αναφέρεται ως μετρικές CK είναι το εξής: 1.4.1.1 Μέθοδοι ανά κλάση (WMC) Θεωρούμε ότι μια κλάση C περιλαμβάνει n μεθόδους πολυπλοκότητας c1,c2,c3,...cn αντίστοιχα. Η συγκεκριμένη μετρική που θα επιλεγεί για τον καθορισμό της πολυπλοκότητας (π.χ. κυκλωματική πολυπλοκότητα) θα πρέπει να είναι κανονικοποιημένη ώστε η ονομαστική πολυπλοκότητα μιας μεθόδου να λαμβάνει την τιμή 1.0. η μετρική MWC ορίζεται ως: WMC = n c i i = 1 Ο αριθμός των μεθόδων και η πολυπλοκότητά τους είναι ένας λογικός δείκτης της προσπάθειας που απαιτείται για την υλοποίηση και τον έλεγχο μιας κλάσης. Επιπλέον, όσο αυξάνει ο αριθμός των μεθόδων μιας κλάσης, τόσο πιο πολύπλοκο γίνεται το δένδρο κληρονομικότητας. Και τόσο αυξάνει η συσχέτιση μιας κλάσης με μια συγκεκριμένη εφαρμογή, με συνέπεια να περιορίζεται η δυνατότητα επαναχρησιμοποίησης της κλάσης. για τους λόγους αυτούς, η τιμή της μετρικής WMC θα πρέπει να παραμένει κατά το δυνατόν χαμηλή. 1.4.1.2 Αριθμός απογόνων (NOC) Οι κλάσεις που κληρονομούν μια άλλη κλάση είναι οι απόγονοί της. Όσο αυξάνει ο αριθμός των απογόνων αυξάνει ο βαθμός επαναχρησιμοποίησης, αλλά ταυτόχρονα αυξάνεται η προσπάθεια που απαιτείται για τον έλεγχο του συστήματος. 34

1.4.1.3 Βαθμός συνεκτικότητας των μεθόδων (LCOM) Κάθε μέθοδος σε μια κλάση προσπελαύνει ένα ή περισσότερα μέλη δεδομένων. Η μετρική LCOM αναφέρεται στον αριθμό των μεθόδων που πραγματοποιούν προσπελάσεις σε ένα ή περισσότερα κοινά μέλη δεδομένων. Δύο μέθοδοι είναι συνεκτικές εάν τα σύνολα των μελών δεδομένων που χρησιμοποιούν έχουν κοινά στοιχεία. Συμβολίζουμε με {I,j} το σύνολο των μελών των δεδομένων που χρησιμοποιείται από τη μέθοδο ΜI της κλάσης. Καθώς κάθε κλάση C1 περιλαμβάνει n μεθόδους (Μ1,M2,,Μn), σχηματίζονται δύο σύνολα από ζεύγη μεθόδων σε κάθε κλάση: Όπου P το σύνολο των μη συνεκτικών ζευγών μεθόδων, και Q το σύνολο των συνεκτικών ζευγών μεθόδων. Ο τύπος της είναι ο εξής: Όσο περισσότερες είναι οι συνεκτικές μέθοδοι, τόσο μεγαλύτερη η συνεκτικότητα της κλάσης και τόσο χαμηλότερη είναι η τιμή LCOM, γεγονός που ενδεχομένως να αυξάνει την πολυπλοκότητα. Στην περίπτωση που τιμή LCOM είναι υψηλή, η συνεκτικότητα είναι χαμηλή και ενδεχομένως η κλάση να μπορεί να σχεδιαστεί καλύτερα με διάσπαση σε δύο ή περισσότερες ανεξάρτητες κλάσεις. Η χαμηλή τιμή της μετρικής LCOM υποδηλώνει υψηλή συνεκτικότητα, γεγονός που είναι προφανές αφού τα μέλη δεδομένων x,y χρησιμοποιούνται από όλες σχεδόν τις μεθόδους της κλάσης. 35

1.4.1.4 Σύζευξη μεταξύ κλάσεων (CBO) Η μετρική αυτή αναφέρεται στον αριθμό των κλάσεων που παρέχουν σε μια κλάση Α τις απαραίτητες πληροφορίες (δεδομένα ή λειτουργίες) ώστε να ολοκληρώνεται οι μέθοδοί της. Η τιμή CBO σχετίζεται με τη δυνατότητα επαναχρησιμοποίησης της κλάσης, τροποποίησης και ελέγχου της. Η απαίτηση να είναι η σύζευξη μεταξύ κλάσεων χαμηλή είναι παρόμοια με την απαίτηση για χαμηλή σύζευξη στα συμβατικά προγράμματα. 1.4.1.5 Απόκλιση μιας κλάσης (RFC) Ως απόκλιση μίας κλάσης νοείται το σύνολο των μεθόδων που είναι δυνατόν να ενεργοποιηθούν ως απάντηση σε ένα μήνυμα που λαμβάνεται από ένα αντικείμενο της κλάσης C. Συμπεριλαμβάνονται όλες οι μέθοδοι της κλάσης καθώς και οι μέθοδοι άλλων κλάσεων που καλούνται από τις μεθόδους της C. Η μετρική αυτή είναι ενδεικτική της πολυπλοκότητας της κλάσης και του βαθμού συσχέτισης της με άλλες κλάσεις. Από πειραματικά δεδομένα, έχει προκύψει ότι όσο μεγαλύτερη είναι η τιμή RCF τόσο μεγαλύτερη είναι η πιθανότητα η εν λόγω κλάση να παρουσιάσει λάθη. 1.4.1.6 Βάθος δέντρου κληρονομικότητας (DIT) Η μετρική αυτή ορίζεται ως το μέγιστο μήκος από την ρίζα του δένδρου προς οποιοδήποτε κόμβο του. Όσο αυξάνει το βάθος του δένδρου, οι κλάσεις χαμηλών επιπέδων κληρονομούν περισσότερες μεθόδους, γεγονός που αυξάνει την πολυπλοκότητα και περιορίζει τη δυνατότητα πρόβλεψης της συμπεριφοράς μίας κλάσης. Στη συνέχεια ακολουθούν οι μετρικές οι οποίες χρησιμοποιήθηκαν στη μεθοδολογία που παρουσιάζεται στην παρούσα μεταπτυχιακή εργασία και δεν έχουν αναφερθεί στην προηγούμενη κατηγοριοποίηση. 36

1.4.1.7 Παράγοντας Σύζευξης (CF) Η μετρική παράγοντας Σύζευξης είναι από το σύνολο των μετρικών για την αντικειμενοστρεφή ανάπτυξη MOOD (Metrics for Object-Oriented Development). Υπολογίζεται ως κλάσμα. Ο αριθμητής αντιπροσωπεύει τον αριθμό μηκληρονομικών συζεύξεων, ενώ ο παρονομαστής είναι ο μέγιστος πιθανός αριθμός συζεύξεων σε ένα σύστημα. Η μετρική υπολογίζεται για το πρόγραμμα συνολικά, και είναι ενδιαφέρον για την ανάλυση των αλλαγών προγράμματος και τη σύγκριση των προγραμμάτων. Στόχος των σχεδιαστών είναι χαμηλότερη πιθανή τιμή για αυτή τη μετρική (όπως κοντά σε 0% όπως πιθανό). 1.4.1.8 Αναλογία Σχολίων (CR) Η μετρική αυτή υπολογίζει το ποσοστό των σχολίων στο αρχείο. Φανερώνει το κατά ποσό ο συντάκτης του κώδικα θέλει να σχολιάσει τη μεθοδολογία που ακολουθεί στην συγγραφή του. Ο κατάλληλος αριθμός σχολίων εξαρτάται από την πολιτική του προγραμματιστή που συντάσσει τον κώδικα. Τα σχόλια βελτιώνουν την αναγνωσιμότητα του προγράμματος και απλοποιούν τις αλλαγές. Συστήνεται να παρέχονται τουλάχιστον 5% σχόλια σχετικά με το συνολικό ποσό των γραμμών κώδικα και σχολίου. Η ανώτερη τιμή δεν δέχεται περιορισμό. 1.4.1.9 Γραμμές Κώδικα (LOC) Η μετρική υπολογίζει το μέγεθος ενός προγράμματος λογισμικού μετρώντας τις γραμμές του κώδικα χρησιμοποιούνται στον πηγαίο κώδικα του προγράμματος (SLOC-source lines of code). Χρησιμοποιείται για να προβλέψει το ποσό προσπάθειας που θα απαιτηθεί για να αναπτυχθεί ένα πρόγραμμα, καθώς επίσης και για να υπολογίσει την παραγωγικότητα προγραμματισμού ή της προσπάθειας αφού παραχθεί το λογισμικό. Ένα αποδοτικό σχέδιο παρέχει λειτουργικότητα με τη χαμηλότερη προσπάθεια 37

εφαρμογής και λιγότερα τα LOCs. Αποκλίσεις ενός μεγέθους μπορεί να είναι σαφείς δείκτες της πολυπλοκότητας λογισμικού ή των ανθρωποωρών. 1.4.1.10 Έλλειψη συνεκτικότητας 2 (LCOM2) Μετρά το ποσοστό των μεθόδων που δεν έχουν πρόσβαση σε ένα συγκεκριμένο χαρακτηριστικό εξάγοντας το μέσο όρο όλων των χαρακτηριστικών στην κλάση. Η υψηλή αξία της συνοχής (μια χαμηλή έλλειψη συνοχής) υπονοεί ότι η κλάση σχεδιάστηκε καλά. Μια συνεκτική κλάση θα τείνει να παρέχει έναν υψηλό βαθμό ενθυλάκωσης, ενώ μια έλλειψη συνοχής μειώνει την ενθυλάκωση και αυξάνει την πολυπλοκότητα. Αναλύονται μόνο εκείνες οι κλάσεις για τις οποίες υφίσταται αυτή η μετρική. Αποφεύγονται οι κλάσεις που έχουν μια τιμή λιγότερο από 30%. Μια χαμηλή τιμή προτείνει μια φτωχή σχεδίαση κλάσης, το οποίο απαιτεί την αυξανόμενη προσπάθεια για τη δοκιμή ή την τροποποίηση της κλάσης. Για να αυξήσει την τιμή, συστήνεται να ξανασχεδιαστεί η κλάση. 1.4.1.11 Έλλειψη συνεκτικότητας 3 (LCOM3) Ο καθορισμός αυτού της μετρικής προτάθηκε από Henderson-Sellers το 1995. Η χαμηλή αξία δείχνει την καλή υποδιαίρεση κλάσης που υπονοεί την απλότητα και την υψηλή ικανότητα επαναχρησιμοποίησης. Η υψηλή έλλειψη συνοχής αυξάνει την πολυπλοκότητα, αυξάνοντας την πιθανότητα των λαθών κατά τη διάρκεια της διαδικασίας ανάπτυξης. Ακολουθεί ανάλυση του τύπου LCOM3. Έστω ότι εξετάζεται ένα σύνολο m μεθόδων M1, M2,..., Mm. Οι μέθοδοι έχουν πρόσβαση σε a χαρακτηριστικά, A1, A2,..., Aa. Έστω a(mk) = αριθμός χαρακτηριστικών που προσεγγίζονται με τη μέθοδο MK και m(ak) = αριθμός μεθόδων που έχουν πρόσβαση στα στοιχεία Ak. Τότε: LOCOM 1/ a = a i= 1 3 m( Ai ) m 100 1 m 38

Αναλύονται μόνο εκείνες οι κλάσεις για τις οποίες υφίσταται αυτή η μετρική. Αποφεύγονται οι κλάσεις που έχουν μια τιμή λιγότερο από 30%. Μια υψηλή τιμή προτείνει μια φτωχή σχεδίαση κλάσης, το οποίο απαιτεί την αυξανόμενη προσπάθεια για τη δοκιμή ή την τροποποίηση της κλάσης. Για να μειωθεί η τιμή, συστήνεται να ξανασχεδιαστεί η κλάση. 1.4.1.12 Fan-out (FO) Η μετρική Fan-out εκτιμάει την πολυπλοκότητα συντήρησης του λογισμικού. Υποδηλώνει τον αριθμό των συναρτήσεων που καλεί μια συνάρτηση. Η τροποποίηση μιας συνάρτησης μπορεί να έχει αποτελέσματα στις συναρτήσεις που καλούνται από την τροποποιημένη συνάρτηση. Ο συντηρητής της μονάδας πρέπει να καταλάβει όλες τις συναρτήσεις που καθιστούν τη συντήρηση σκληρότερη και χρονοβόρα. Επομένως, λειτουργίες με μεγάλο fan-out απαιτούν μεγάλο κόστος για συντήρηση. Επίσης, μετρά τον αριθμό των τύπων αναφορών που χρησιμοποιούνται στις δηλώσεις ιδιοτήτων, επίσημες παράμετροι, τύποι επιστροφής, ρίχνει τις δηλώσεις και τις τοπικές μεταβλητές. 1.5 Επαναχρησιμοποίηση Λογισμικού Η επαναχρησιμοποίηση απαιτεί την αξιολόγηση προϊόντων από σύγχρονα και παλαιότερα έργα ανάπτυξης, για να καθοριστεί αν διαθέτουν τον τύπο και την ποιότητα που θα θέλαμε για το επόμενο σύστημα που θα κατασκευάσουμε. Συνεπώς, εξετάζουμε μερικά από τα θέματα επαναχρησιμοποίησης που μπορεί να επηρεάσουν την αξιολόγησή μας. Πολλά από τα συστήματα λογισμικού που κατασκευάζονται είναι παρόμοια το ένα με το άλλο. Κάθε εταιρία με μεγάλη πιθανότητα διαθέτει ένα λογιστικό σύστημα, ένα σύστημα προσωπικού, και ίσως ένα σύστημα τιμολόγησης για παράδειγμα. Υπάρχουν κοινά σημεία ανάμεσα σε συστήματα με παρόμοιους σκοπούς. Για παράδειγμα, κάθε σύστημα προσωπικού περιλαμβάνει δεδομένα και 39

λειτουργίες που σχετίζονται με τους υπαλλήλους της εταιρίας. Αντί να δημιουργούμε κάθε σύστημα από την αρχή, μπορούμε να εξετάζουμε προηγούμενα συστήματα, να αξιολογούμε τα συστατικά τους, και να καθορίζουμε κατά πόσο μπορούν να προσαρμοστούν ή ακόμα να επαναχρησιμοποιηθούν πλήρως στο επόμενο σύστημα που θα κατασκευάσουμε. Ακόμα και όταν οι εφαρμογές είναι πολύ διαφορετικές, θα πρέπει να εξετάζουμε αν είναι απαραίτητο να γράψουμε μία μικρή ρουτίνα, ένα συστατικό που εκτελεί μία αναζήτηση, ή ένα πρόγραμμα για μία φόρμα εισόδου δεδομένων. Οι ερευνητές λογισμικού πιστεύουν ότι η επαναχρησιμοποίηση έχει μεγάλη δυναμική στην αύξηση της παραγωγικότητας και τη μείωση του κόστους, και μερικές προσπάθειες εφαρμογής της τεχνολογίας επαναχρησιμοποίησης επιβεβαιώνουν αυτή την υπόθεση. 1.5.1 Τύποι επαναχρησιμοποίησης Με τον όρο επαναχρησιμοποίηση λογισμικού (software reuse), εννοούμε την επαναλαμβανόμενη χρήση οποιουδήποτε μέρους ενός συστήματος λογισμικού: την τεκμηρίωση, τον κώδικα, το σχέδιο, τις απαιτήσεις, τις περιπτώσει ελέγχου, τα δεδομένα ελέγχου και άλλα. Ο Basili (1990) μας ενθαρρύνει να λαμβάνουμε τη συντήρηση ως επαναχρησιμοποίηση. Παίρνουμε δηλαδή ένα υπάρχον σύστημα και επαναχρησιμοποιούμε μέρη αυτού για να κατασκευάσουμε την επόμενη έκδοση. Παρομοίως, προτείνει και οι διεργασίες και η εμπειρία να επαναχρησιμοποιούνται, όπως επίσης και κάθε χειροπιαστό ή μη προϊόν ανάπτυξης. Υπάρχουν δύο τύποι επαναχρησιμοποίησης που καθορίζονται από την πλευρά αυτού που κάνει την επαναχρησιμοποίηση. Η επαναχρησιμοποίηση δημιουργού (producer reuse), δημιουργεί επαναχρησιμοποιήσιμα συστατικά, και η επαναχρησιμοποίηση καταναλωτή (consumer reuse), τα χρησιμοποιεί σε επόμενα συστήματα (Bollinger και Pfleeger 1990). Ως καταναλωτές μπορούμε είτε να χρησιμοποιήσουμε το σύνολο ενός προϊόντος χωρίς τροποποιήσεις (που καλείται επαναχρησιμοποίηση μαύρου κουτιού (black-box reuse)), ή να το τροποποιήσουμε ώστε να ταιριάζει με τις ιδιαίτερες ανάγκες μας (που καλείται επαναχρησιμοποίηση διαφανούς κουτιού (clear-box reuse)). Πραγματοποιούμε επαναχρησιμοποίηση μαύρου κουτιού συχνά, όταν χρησιμοποιούμε ρουτίνες από μαθηματικές βιβλιοθήκες ή κατασκευάζουμε γραφικές διασυνδέσεις από ένα προκαθορισμένο σύνολο συστατικών. Ένα σημαντικό θέμα στην επαναχρησιμοποίηση μαύρου κουτιού είναι η 40

ικανότητά μας να επαληθεύσουμε ότι ένα επαναχρησιμοποιήσιμο συστατικό εκτελεί τις απαιτούμενες λειτουργίες με αποδεκτό τρόπο. Αν το συστατικό είναι κώδικας, θέλουμε να είμαστε βέβαιοι ότι δε θα παρουσιάσει δυσλειτουργίες. Για παράδειγμα αν είναι ένα σύνολο ελέγχου, θέλουμε να είμαστε βέβαιοι ότι επιτελεί λεπτομερώς τη λειτουργία για την οποία σχεδιάστηκε. Η επαναχρησιμοποίηση διαφανούς κουτιού (που μερικές φορές καλείται και επαναχρησιμοποίηση λευκού κουτιού (white-box reuse)) είναι πιο συνήθης αλλά ακόμα αμφιλεγόμενη, επειδή η προσπάθεια κατανόησης και τροποποίησης ενός συστατικού θα πρέπει να είναι μικρότερη από την προσπάθεια κατασκευής ενός ισοδύναμου συστατικού. Για την αντιμετώπιση αυτού του προβλήματος, πολλά επαναχρησιμοποιήσιμα συστατικά κατασκευάζονται με πολλές παραμέτρους, οι οποίες τα κάνουν πιο εύκολα στη συγγραφή απαιτώντας μόνο μία εξωτερική ματιά, αντί να ασκείται πίεση στους δημιουργούς να καταλάβουν τα εσωτερικά στοιχεία ενός συστατικού. Πολλές πρόσφατες ανακαλύψεις στην τεχνολογία λογισμικού κάνουν την επαναχρησιμοποίηση περισσότερο εφαρμόσιμη. Μία τέτοια είναι και η προσπάθεια υιοθέτησης της Αντικειμενοστραφούς Ανάπτυξης (Object-Oriented Development - OOD). Επειδή η OOD ενθαρρύνει τους μηχανικούς λογισμικού να κατασκευάζουν ένα σχέδιο γύρω από αμετάβλητα συστατικά, πολλά μέρη του σχεδίου και του κώδικα μπορούν να εφαρμοστούν σε πολλαπλά συστήματα. Μία άλλη ανακάλυψη που ενθαρρύνει την επαναχρησιμοποίηση είναι η αυξανόμενη επιτήδευση των εργαλείων, των οποίων η επίδραση εκτείνεται κατά μήκος όλου του κύκλου ζωής της φάσης ανάπτυξης των προϊόντων. Τα εργαλεία που περιλαμβάνουν χώρο αποθήκευσης για τα συστατικά που αναπτύσσονται για ένα σύστημα μπορούν να ενθαρρύνουν την επαναχρησιμοποίηση αυτών των συστατικών σε ένα επόμενο σύστημα. Τέλος, η σχεδίαση μιας γλώσσας μπορεί να ενθαρρύνει την επαναχρησιμοποίηση συστατικών. Για παράδειγμα η Ada παρέχει ένα μηχανισμό επαναδόμησης του λογισμικού που υποστηρίζει τη δημιουργία πακέτων (packaging), και οι τεχνικές παραμετροποίησης της Ada μπορούν να βοηθήσουν ώστε να γίνει το συστατικό πιο γενικό. Οι προσεγγίσεις επαναχρησιμοποίησης είναι είτε συνθετικές είτε γεννητικές. Η συνθετική επαναχρησιμοποίηση (compositional reuse) βλέπει τα επαναχρησιμοποιήσιμα συστατικά ως ένα σύνολο δομικών στοιχείων, ενώ η 41

ανάπτυξη γίνεται από κάτω προς τα πάνω, κατασκευάζοντας το υπόλοιπο σύστημα γύρω από τα επαναχρησιμοποιήσιμα συστατικά. Για αυτό το είδος επαναχρησιμοποίησης, τα συστατικά αποθηκεύονται σε μία βιβλιοθήκη (που συχνά καλείται αποθήκη επαναχρησιμοποίησης (reuse repository)). Τα συστατικά θα πρέπει να ταξινομηθούν ή να κατηγοριοποιηθούν, και ένα σύστημα ανάκτησης θα πρέπει να χρησιμοποιηθεί για τη σάρωση και την επιλογή συστατικών που θα χρησιμοποιηθούν στο νέο σύστημα. Για παράδειγμα, ο χώρος αποθήκευσης μπορεί να περιλαμβάνει μία ρουτίνα για τη μετατροπή της ώρας από 12ωρη αναπαράσταση σε 24ωρη αναπαράσταση. Παρομοίως, η γεννήτρια του συστήματος διαχείρισης βάσης Genesis περιλαμβάνει δομικά στοιχεία που μας επιτρέπουν να κατασκευάσουμε ένα DBMS κομμένο και ραμμένο στις ανάγκες μας (Prieto-Diaz 1993). Από την άλλη μεριά, η γεννητική επαναχρησιμοποίηση (generative reuse) αφορά ένα ιδιαίτερο πεδίο εφαρμογής. Αυτό σημαίνει ότι τα συστατικά σχεδιάζονται με ειδικό τρόπο ώστε να αντιμετωπίσουν τις ανάγκες μιας ιδιαίτερης εφαρμογής και να επαναχρησιμοποιηθούν σε παρόμοια εφαρμογή που θα προκύψει κάποια άλλη στιγμή. Για παράδειγμα, η NASA έχει υλοποιήσει ένα μεγάλο μέρος λογισμικού για να παρακολουθήσει την τροχιά των δορυφόρων. Τα συστατικά για την ανάλυση δεδομένων τροχιάς μπορούν να σχεδιαστούν ώστε να μπορέσουν να επαναχρησιμοποιηθούν από άλλα συστήματα της NASA. Ωστόσο, αυτές οι διαδικασίες δεν είναι καλοί υποψήφιοι για ένα χώρο αποθήκευσης γενικής επαναχρησιμοποίησης, επειδή είναι πιθανό να μην χρειάζονται άλλα πεδια. Η γεννητική επαναχρησιμοποίηση υπόσχεται υψηλή αποδοτικότητα και εφαρμόσθηκε στην πράξη σε γεννητριες εφαρμογών συγκεκριμένου πεδίου. Μερικές από τις πιο γνωστές γεννήτριες είναι τα προγράμματα Lex και Yacc, τα οποία έχουν σχεδιαστεί να μας βοηθούν να δημιουργούμε λεκτικούς και συντακτικούς αναλυτές. Μία κύρια δραστηριότητα και των δύο ειδών επαναχρησιμοποίησης είναι η ανάλυση πεδίου (domain analysis), η διαδικασία ανάλυσης ενός πεδίου εφαρμογής για τον εντοπισμού κοινών περιοχών και τρόπων περιγραφής τους (Prieto-Diaz 1987). Η συνθετική επαναχρησιμοποίηση βασίζεται στην ανάλυση πεδίου για τον εντοπισμό κοινών λειτουργιών χαμηλότερου επιπέδου ανάμεσα σε μια ευρεία ομάδα συστημάτων. Μια γεννητική προσέγγιση επαναχρησιμοποίησης απαιτεί περισσότερες δραστηριότητες ανάλυσης ο αναλυτής πεδίου ψάχνει για να ορίσει μια γενική 42

αρχιτεκτονική πεδίου και να καθορίσει τα πρότυπα διασύνδεσης ανάμεσα στα συστατικά αρχιτεκτονικής. Αυτές οι ιδέες οδηγούν στις έννοιες της οριζόντιας και κάθετης επαναχρησιμοποίησης. Η κάθετη επαναχρησιμοποίηση (vertical reuse) περιλαμβάνει την ίδια περιοχή ή το ίδιο πεδίο εφαρμογής, ενώ η οριζόντια επαναχρησιμοποίηση (horizontal reuse) εισέρχεται σε διάφορα πεδία. Η επαναχρησιμοποίηση των ρουτινών δεδομένων της τροχιάς της NASA είναι κάθετη επαναχρησιμοποίηση, ενώ η επαναχρησιμοποίηση ενός μικρού προγράμματος ταξινόμησης από ένα σύστημα βάσης δεδομένων σε ένα πακέτο γραφικών είναι οριζόντια επαναχρησιμοποίηση. Τεχνολογία επαναχρησιμοποίησης και ανάκτηση συστατικών. Ένα από τα μεγαλύτερα εμπόδια στην επαναχρησιμοποίηση είναι η ανάγκη αναζήτησης ανάμεσα σε ένα μεγάλο σύνολο προϊόντων λογισμικού για την εύρεση του καλύτερου για κάποια συγκεκριμένη ανάγκη. Αυτή η εργασία είναι συναφής με την αναζήτηση βιβλίων σε παλαιοπωλείο αντί της επίσκεψης σε κάποια βιβλιοθήκη. Η λύση είναι η ταξινόμηση συστατικών (component classification), όπου συλλογές επαναχρησιμοποιήσιμων συστατικών οργανώνονται και ταξινομούνται με βάση ένα σχήμα ταξινόμησης. Τα συστατικά μπορούν να ταξινομηθούν με βάση ένα ιεραρχικό σχήμα, όπως περίπου οργανώνονται τα βιβλία σε μία βιβλιοθήκη. Μία κατηγορία υψηλού επιπέδου χωρίζεται σε υποκατηγορίες, οι οποίες με τη σειρά τους χωρίζονται να προστεθούν και αυτές σε υποκατηγορίες και τα λοιπά. Εντούτοις, αυτή η προσέγγιση δεν είναι ευέλικτη και νέα θέματα μπορούν να προστεθούν εύκολα μόνο στο χαμηλότερο επίπεδο. Επιπλέον, οι εκτεταμένες παραπομπές είναι απαραίτητες, αφού θα πρέπει να βρούμε μία ρουτίνα διαχείρισης κειμένου στην υποκατηγορία των αναφορών όπως επίσης και στην υποκατηγορία της επεξεργασίας κειμένου, για παράδειγμα. Μία λύση σε αυτό το πρόβλημα είναι το σχήμα των Prieto-Diaz που καλείται κατηγοριοποίηση χαρακτηριστικών (faceted classification) (Prieto-Diaz και Freeman 1987). Αντί να χρησιμοποιείται κάποια ιεραρχία, κάθε συστατικό περιγράφεται από μία ταξινομημένη λίστα χαρακτηριστικών τα οποία καλούνται όψεις. Μία όψη (facet) είναι ένα είδος περιγραφέα που βοηθάει στην αναγνώριση ενός συστατικού, ενώ μία ομάδα όψεων επιτρέπει την αναγνώριση πολλών χαρακτηριστικών με τη μία. Για παράδειγμα, οι όψεις του επαναχρησιμοποιήσιμου κώδικα μπορεί να είναι: 43

ένα πεδίο εφαρμογής μία λειτουργία ένα αντικείμενο μία γλώσσα προγραμματισμού ένα λειτουργικό σύστημα Το σύστημα κατηγοριοποίησης υποστηρίζεται από ένα σύστημα ανάκτησης (retrieval system) ή χώρο αποθήκευσης (repository), μία αυτοματοποιημένη βιβλιοθήκη όπου μπορεί να γίνει αναζήτηση και ανάκτηση ενός συστατικού με βάση την περιγραφή που δίνει κάποιος χρήστης. Ο χώρος αποθήκευσης συχνά περιέχει ένα λεξικό συνωνύμων για να μας βοηθήσει να κατανοήσουμε την ορολογία που χρησιμοποιείται στην κατηγοριοποίηση. Για παράδειγμα, το λεξικό μπορεί να μας πει να χρησιμοποιήσουμε τη λέξη ψάξε ως συνώνυμο της λέξης αναζήτησε. Επιπρόσθετα, ένας χώρος αποθήκευσης θα πρέπει να αντιμετωπίζει το πρόβλημα της εννοιολογικής εγγύτητας (conceptual closeness) για την ανάκτηση των τιμών των διαφόρων όψεων που είναι παρόμοιες αλλά όχι ακριβώς οι ίδιες όπως το επιθυμητό συστατικό. Για παράδειγμα, αν δε βρεθεί κανένα συστατικό τροποποίηση, μπορεί να καθοδηγηθούμε στα συστατικά προσθήκη και διαγραφή τα οποία είναι παρόμοια. Το σύστημα ανάκτησης μπορεί επίσης να καταγράφει πληροφορίες σχετικά με τις αιτήσεις των χρηστών. Ένας αριθμός αιτήσεων συγκεκριμένου τύπου που δεν ικανοποιήθηκαν μπορεί να κινήσουν το ενδιαφέρουν του βιβλιοθηκονόμου, ώστε να προτείνει να γραφεί το συστατικό του συγκεκριμένου τύπου που αναζητείται. Για παράδειγμα, αν πολλοί χρήστες ζητήσουν ένα συστατικό που να αλλάζει την ημερομηνία από τη μορφή που χρησιμοποιείται στις Ηνωμένες Πολιτείες (04/08/09, ή Απριλίου 8, 2009) στη μορφή που χρησιμοποιείται στην Ευρώπη (08/04/09, ή 8 Απριλίου 2009) και δεν υπάρχει αυτό το συστατικό, ο βιβλιοθηκονόμος μπορεί να διασφαλίσει ότι αυτό θα κατασκευασθεί. Παρομοίως, αν πολλοί δημιουργοί λογισμικού ψάχνουν για συστατικά σχεδίασης γεωμετρικών σχημάτων αλλά δεν υπάρχει κανένα, ο βιβλιοθηκονόμος μπορεί να εντοπίσει καλά παρόμοια υποψήφια συστατικά και να τα τοποθετήσει στη βιβλιοθήκη. 44

Τέλος, το σύστημα ανάκτησης μπορεί να διατηρεί περιγραφικές πληροφορίες για κάθε συστατικό που να μας βοηθάνε να αποφασίσουμε ποιο συστατικό να επιλέξουμε. Πληροφορίες σχετικά με την πηγή του συστατικού (π.χ. που αγοράστηκε ή από ποιο έργο ανάπτυξης προήλθε), την αξιοπιστία του (τον αριθμό των σφαλμάτων που εντοπίσθηκαν ή τον αριθμό των ωρών που έχει λειτουργήσει χωρίς να παρουσιάσει κάποια δυσλειτουργία), ή την προηγούμενη χρήση του, μπορούν να μας πείσουν να επιλέξουμε κάποιο συστατικό αντί για κάποιο άλλο. 1.5.2 Μέτρηση επαναχρησιμοποίησης Πολλοί διοικητές λογισμικού θα ήθελαν ένα απλό σύνολο από μετρικές, οι οποίες όταν εφαρμόζονται σε ένα συστατικό, θα οριοθετούν τη δυνατότητα επαναχρησιμοποίησης του ή την έλλειψη αυτής της δυνατότητας. Ωστόσο, η εύρεση του σωστού συνόλου δεν είναι τόσο εύκολη διαδικασία όσο ακούγεται. Οι μετρικές θα πρέπει να επιδιώκουν κάποιο στόχο, που θα σχετίζεται συνήθως με την ποιότητα, την παραγωγικότητα ή το χρόνο μέχρι τη διανομή στην αγορά (time to market). Επίσης θα πρέπει να εκφράζουν την προοπτική του ατόμου που υποβάλλει την ερώτηση γιατί οι τεχνολόγοι λογισμικού έχουν διαφορετική οπτική γωνία για το προϊόν από ότι τα υψηλόβαθμα στελέχη. Η Pfleeger περιγράφει πως η απλή ερώτηση σχετικά με το τι πρέπει να μετρούμε οδήγησε στη γέννηση περισσότερων από 100 δυνατές μετρικές- που οδηγεί σαφώς σε έναν μη αποδεκτό αριθμό μετρήσεων που θα πρέπει να γίνονται. Όμως, ακόμα και αν είχαμε μία καλή λίστα μετρικών, πώς θα ξέραμε ποια όρια θα έπρεπε να θέσουμε σε καθεμία από αυτές τις μετρικές; Ένα μικρό συστατικό είναι πιο εύκολα επαναχρησιμοποιήσιμο από ένα μεγάλο; Είναι καλύτερο να επαναχρησιμοποιούμε πολύπλοκο κώδικα από ότι απλό; Αυτές οι ερευνητικές ερωτήσεις εξετάζονται με πολλούς διαφορετικούς τρόπους. Μερικοί οργανισμοί ερευνούν έργα που έχουν ολοκληρωθεί για να καθορίσουν τα χαρακτηριστικά των πιο επαναχρησιμοποιήσιμων συστατικών. Μερικοί άλλοι επιλέγουν μετρικές που βασίζονται στην κρίση του μηχανικού. Η πιο πολλά υποσχόμενη προσέγγιση χρησιμοποιήθηκε από το Contel Technology Center, όπου οργανώθηκε ένας αυτόματος χώρος αποθήκευσης χρησιμοποιώντας κατηγοριοποίηση 45

χαρακτηριστικών. Στο χώρο της αποθήκευσης καταγράφονται πληροφορίες σχετικά με τις αιτήσεις χρηστών, όπως π.χ. ποιοι περιγραφείς χρησιμοποιούνται πιο συχνά. Επίσης γινόταν καταγραφή της επιλογής ενός συστατικού(χωρίς να χρησιμοποιηθεί ), και όταν γινόταν κάποια αίτηση που δεν διεκπεραιωνόταν. Στη συνέχεια ο διαχειριστής του χώρου αποθήκευσης μιλούσε με τους χρήστες για να καταλάβει για ποιον λόγο μερικά συστατικά δεν χρησιμοποιούνταν, και γιατί κάποια άλλα συστατικά χρησιμοποιούνταν πάρα πολύ συχνά. Οι μετρικές, σε συνδυασμό με προσωπική επαφή επέτρεπαν στο διαχειριστή να προσθέτει νέα συνώνυμα στη κατηγοριοποίηση συστατικών, να τροποποιεί συστατικά ώστε να γίνονται πιο επαναχρησιμοποιήσιμα, να διαγράφει τα συστατικά τα οποία δεν ήταν χρήσιμα στους διαφόρους χρήστες (με ταυτόχρονη μείωση και του χρόνου αναζήτησης) και να βρίσκει και νέα συστατικά τα οποία ζητούσαν οι χρήστες αλλά δεν ήταν διαθέσιμα από το χώρο αποθήκευσης συστατικών. 1.6 Επίδραση Προτύπων Σχεδίασης σε Μετρικές Λογισμικού Σε αυτή την ενότητα παρουσιάζονται πληροφορίες σχετικά με προηγούμενες εργασίες που αφορούν την εφαρμογή προτύπων σχεδίασης σε συνδυασμό με τις τιμές αντικειμενοστραφών μετρικών. Στο άρθρο [6] ο συγγραφέας έχει ποσοτικά αξιολογήσει την επίδραση των προτύπων στις τιμές των μετρικών τριών κατηγοριών. Οι μετρικές αυτές είναι η σύζευξη, η κληρονομικότητα και το μέγεθος. Η μεθοδολογία της μελέτης στο άρθρο αυτό είναι ακέραια. Ωστόσο, μελετήθηκε μόνο ένας περιορισμένος αριθμός προτύπων και σε σχέση μόνο με μία κατηγορία μετρικών. Στο [1] οι συγγραφείς διεξήγαγαν μία μελέτη περίπτωσης με αποτελέσματα τόσο ποσοτικά, όσο και ποιοτικά. Ο τομέας εφαρμογής περιορίστηκε μόνο στα παιχνίδια. Στο [7] οι συγγραφείς πραγματοποίησαν μία έρευνα στα πρότυπα σχεδίασης και στην ποιότητα λογισμικού, με επαγγελματίες τεχνολόγους λογισμικού ως υποκείμενα. Τα αποτελέσματα της εμπειρικής αυτής μελέτης έδειξαν ότι η χρήση των προτύπων δεν είναι πάντα ευδόκιμη, όσον αφορά την ποιότητα, τη δυνατότητα εκμάθησης και την ευκολία κατανόησης. 46

Επιπροσθέτως, οι Prechelt et al. and Vokac et al. [10 and 13] έχουν χρησιμοποιήσει παρόμοια γκρουπ υποκειμένων και προτύπων σε ελεγχόμενα πειράματα που αφορούν τη διατηρησιμότητα του λογισμικού. Τα αποτελέσματα των μελετών έδειξαν ότι η χρήση των προτύπων είναι χρήσιμη μόνο όταν εμπλέκονται σωστά στη σχεδίαση [10]. Επιπλέον, σύμφωνα με το [13], τα πρότυπα σχεδίασης δε μπορούν να χαρακτηριστούν γενικώς ως ωφέλιμα ή επιβλαβή, εξαιτίας της ιδιαιτερότητας και εξειδίκευσης του κάθε προτύπου. Σε αυτό το σημείο κρίνεται σκόπιμο να αναφερθεί ότι η ανάπτυξη παιχνιδιών φαίνεται να είναι ένας ιδιαίτερα ενδιαφέρον τομέας σχετικά με την εφαρμογή προτύπων σχεδίασης, καθώς αρκετά άρθρα και μελέτες προσπαθούν να αξιολογήσουν την επίδρασή τους στην ποιότητα λογισμικού [1 και 9]. Πιο συγκεκριμένα, οι προαναφερθείσες μελέτες έδειξαν ότι η εφαρμογή των προτύπων σχεδίασης ελαττώνει την πολυπλοκότητα και τη σύζευξη του λογισμικού και αυξάνει τη συνεκτικότητα. Από την άλλη όμως έχει ως επακόλουθο την αύξηση του μεγέθους του κώδικα. 47

2 Μεθοδολογία Στο κεφάλαιο αυτό παρουσιάζεται η μεθοδολογία επαναχρησιμοποίησης κώδικα αντικειμενοστραφούς προγραμματισμού με βάση πρότυπα σχεδίασης που προτάσσεται από την παρούσα μεταπτυχιακή εργασία. 2.1.1 Αξιολόγηση Η μελέτη περίπτωσης διεξήχθη σύμφωνα με τις οδηγίες που περιγράφονται στο [8]. Πιο συγκεκριμένα, τα προτεινόμενα βήματα παρουσιάζονται παρακάτω: Καθορισμός των υποθέσεων Επιλογή του πιλοτικού έργου Εύρεση της συγκριτικής μεθόδου Ελαχιστοποίηση της επίδρασης των confounding παραγόντων Σχεδιασμός της μελέτης περίπτωσης Παρακολούθηση της μελέτης περίπτωσης σύμφωνα με το σχεδιασμό Ανάλυση και αναφορά των αποτελεσμάτων 2.1.2 Καθορισμός των υποθέσεων Η διεξαγωγή της μελέτης περίπτωσης αναμένεται να ερευνήσει τις επιδράσεις της εφαρμογής των προτύπων σχεδίασης όπως περιγράφεται με τις ακόλουθες προσυνθήκες και υποθέσεις που ακολουθούν. Προσυνθήκεs: Ας θεωρήσουμε ως V np μία έκδοση παιχνιδιού που δεν χρησιμοποιεί ένα πρότυπο σχεδίασης για μία συγκεκριμένη λειτουργία F Ας θεωρήσουμε ως Vp μία έκδοση παιχνιδιού που χρησιμοποιεί ένα πρότυπο σχεδίασης για ίδια λειτουργία F 48

Για κάθε μετρική i θεωρούμε ως diff_metric (i) το αποτέλεσμα της διαφοράς της τιμής (i) της μετρικής στην έκδοση V p από την τιμή (i) της μετρικής στην έκδοση V np Υποθέσεις: H 0(1,i) : Για κάθε μετρική i, η εφαρμογή ενός προτύπου σχεδίασης δεν επηρεάζει την τιμή της μετρικής i, στα παιχνίδια 2.1.3 Επιλογή του Πιλοτικού Έργου Στη μελέτη περίπτωσης της έρευνας επιλέχθηκε να διερευνηθεί ως έργο λογισμικού ένα παιχνίδι για ηλεκτρονικό υπολογιστή (Computer Game - CG). Από το έργο αυτό επιλέχθηκαν 5 διαδοχικές εκδόσεις. Το επιλεγμένο έργο και οι εκδόσεις του φαίνονται παρακάτω: Basketball Simulation, Έκδοση 2.0 (CG-1) Basketball Simulation, Έκδοση 3.0 (CG-2) Basketball Simulation, Έκδοση 4.0 (CG-3) Basketball Simulation, Έκδοση 5.0 (CG-4) Basketball Simulation, Έκδοση 5.1 (CG-5) Η μελέτη περίπτωσης του CG αναπτύχθηκε ως προπτυχιακή εργασία και είχε ως σκοπό την αξιολόγηση των οφελών του αναδόμησης (refactoring) σε ήδη υπάρχον κώδικα, μέσω προτύπων σχεδίασης. Με αυτή την έννοια 5 διαδοχικές εκδόσεις προσέφεραν παρόμοια λειτουργικότητα και συνεπώς το έργο κρίθηκε κατάλληλο για την έρευνα. Το έργο CG αναπτύχθηκε σε Java, καθώς το εργαλείο εξόρυξης σχεδιαστικών προτύπων που χρησιμοποιήθηκε, μπορούσε να χρησιμοποιήσει μόνο αρχεία τύπου jar [12]. Επιπλέον, ακολούθησε επικύρωση των αποτελεσμάτων του εργαλείου μέσω παρατήρησης του κώδικα από τα διαγράμματα κλάσεων (manual inspection). Με αυτόν τον τρόπο έγινε και η εξόρυξη των κλάσεων που πραγματοποιούν μία συγκεκριμένη λειτουργικότητα στις εκδόσεις που δεν είχαν χρησιμοποιηθεί πρότυπα σχεδίασης. Γι αυτό το λόγο το μέγεθος, δηλαδή η μετρική NOC της υποκείμενης μελέτης περίπτωσης ήταν χαμηλή. Για την εξόρυξη των διαγραμμάτων κλάσεων χρησιμοποιήθηκε το εργαλείο [32]. 49

2.1.3.1 Χρησιμοποιούμενα εργαλεία Tο εργαλείο Design Pattern Detection Tool [31] ελέγχει την ύπαρξη σχεδιαστικών προτύπων σε γλώσσα προγραμματισμού Java. Το εργαλείο αυτό απαιτεί την εγκατάσταση του πακέτου Java 2 Runtime Environment, Standard Edition 1.5.0 και εξετάζει πακέτα Java bytecode όπως προαναφέρθηκε. Στιγμιότυπο του εργαλείου απεικονίζεται στην εικόνα που ακολουθεί.. Ο εντοπισμός σχεδιαστικών προτύπων σε ένα σύστημα λογισμικού, που είναι μία από τις σημαντικότερες εργασίες στη διαδικασία του επανασχεδιασμού (reengineering process) χρησιμοποιώντας μόνο διαγράμματα UML και την εμπειρία του σχεδιαστή είναι μία δύσκολη υπόθεση χωρίς τη χρήση αυτόματων βοηθητικών εργαλείων. Η μεθοδολογία αυτής της έρευνας, αυτοματοποιεί πλήρως την ανίχνευση προτύπων εξάγοντας τα πραγματικά στιγμιότυπα σε ένα σύστημα για τα πρότυπα που ενδιαφέρουν τον χρήστη. Η βασική συνεισφορά αυτής της προσέγγισης είναι η χρήση του αλγορίθμου παρομοίωσης (similarity algorithm), ο οποίος έχει το πλεονέκτημα να ανιχνεύει πρότυπα τα οποία είναι σε τέτοια μορφή τα οποία παρεκκλίνουν από τη συνηθισμένη αναπαράστασή τους. Η μεθοδολογία που μόλις περιγράφηκε, εφαρμόσθηκε σε τρία συστήματα ανοιχτού κώδικα (open-source systems)και τα αποτελέσματα έδειξαν την ακρίβεια και λεπτομέρεια της όλης προσέγγισης. Εικόνα 2.1 Γραφικό Περιβάλλον του Design Pattern Detection Tool Οι μετρήσεις της ποιότητας του πιλοτικού έργου στην εξέλιξη του, έγινε με την χρήση της εφαρμογής Borland Together 6.1 Control Center [32]. Το λογισμικό αυτό περιλαμβάνει όλα τα τυποποιημένα διαγράμματα UML, συν πρόσθετα 50

διαγράμματα για άλλους ειδικούς τύπους διαμορφώσεων. Διαγράμματα κλάσης και ακολουθίας μπορούν να παράγουν τον πηγαίο κώδικα αυτόματα. Το Together 6.1 επιτρέπει σε μια ολόκληρη ομάδα ανάπτυξης να συνεργαστεί χρησιμοποιώντας κοινή γλώσσα, διαγράμματα, και λογισμικό σε μια ενιαία πλατφόρμα με έναν συνεπή αλλά εξατομικεύσιμη διεπαφή με τον χρήστη για όλη την εργασία τους σε όλο το κύκλο ανάπτυξης λογισμικού. Στιγμιότυπο του εργαλείου φαίνεται στην εικόνα 2.2 Εικόνα 2.2 Γραφικό Περιβάλλον του Borland Together 2.1.3 Εύρεση της συγκριτικής μεθόδου Το εμπειρικό δείγμα δεδομένων που χρησιμοποιήθηκε στην έρευνα αποτελείται από γραμμές, μία για κάθε πρότυπο που προστέθηκε σε μία έκδοση του παιχνιδιού. Όλες οι κλάσεις που συμμετέχουν σε κάποιο πρότυπο σχεδίασης θεωρούνται ως πακέτο, P later Στην προηγούμενη έκδοση που δεν υπήρχε το πρότυπο σχεδίασης, το σύνολο των κλάσεων που παρείχαν παρόμοια λειτουργικότητα θεωρούνται ως πακέτο P prior Και στα δύο πακέτα, οι τιμές των μετρικών έχουν υπολογιστεί ως ο μέσος όρος τιμών (εικόνα 2.3) και η μέγιστη τιμή (εικόνα 2.4) των τιμών των μετρικών των κλάσεων του πακέτου. Η χρήση της μέσης τιμής ως μαθηματική συνάρτηση για τον υπολογισμό των μετρικών πακέτου έχει νόημα με την έννοια ότι όταν ένα σύνολο κλάσεων συνεργάζεται για την εκτέλεση μιας 51

λειτουργίας, ως απόδοση του συστήματος νοείται η απόδοση του χειρότερου (στην περίπτωση μας του μεγαλύτερου), όπως π.χ. χαρακτηριστικά συμβαίνει στα δίκτυα περίπτωσης bottleneck. MS P = i= 1 j k = i NOC ( MSjCi) NOC NOC : Συνολικός αριθμός των κλάσεων ενός πακέτου MS j C i : Τιμή της μετρικής j της κλάσης i MS j P k : Τιμή της μετρικής j του πακέτου k Εικόνα 2.3 Τύπος υπολογισμού της μετρικής j (Μέση Τιμή) MSjPk = max i= NOC ( MSjCi) NOC : Συνολικός αριθμός των κλάσεων ενός πακέτου MS j C i : Τιμή της μετρικής j της κλάσης i MS j P k : Τιμή της μετρικής j του πακέτου k Εικόνα 2.4 Τύπος υπολογισμού της μετρικής j (Μέγιστη Τιμή) i= 1 Για την εξέταση της υπόθεσης που περιγράφηκε παραπάνω, πραγματοποιήθηκαν t-tests. Πιο συγκεκριμένα, η υπόθεση h0 εγκυροποιήθηκε από paired sample t-tests που διερεύνησαν την ύπαρξη στατιστικά σημαντικής διαφοράς ανάμεσα στις μέσες τιμές δύο μεταβλητών, δηλαδή των MS j P prior, MS j P later,, γία κάθε ομάδα κλάσεων, δηλαδή για κάθε πακέτο κλάσεων που παρέχουν συγκεκριμένη λειτουργικότητα. 2.1.4 Ελαχιστοποίηση της επίδρασης των συγκεχυόμενων παραγόντων - confounding factors Στις μελέτες περίπτωσης, οι παράγοντες που επηρεάζουν την τιμή των εξαρτημένων μεταβλητών, εκτός των ανεξάρτητων μεταβλητών, θεωρούνται ως συγκεχυόμενοι παράγοντες. Στην περίπτωση της διαφοράς μεταξύ των τιμών των 52

μετρικών ποιότητας δύο εκδόσεων λογισμικού, αρκετοί παράγοντες θεωρείται ότι μπορούν να έχουν επηρεάσει. Ένας τέτοιος παράγοντας μπορεί είναι η πιθανή προσθήκη λειτουργικότητας. Σε αυτή τη μελέτη περίπτωσης, τα επιλεγμένα σύνολα κλάσεων αναμένεται να έχουν την ελάχιστη δυνατή προσθήκη λειτουργικότητας ανάμεσα σε δύο εκδόσεις. Πιο συγκεκριμένα, οι περισσότερες προσθήκες προτύπων σχεδίασης συνδυάστηκαν με ελάχιστη προσθήκη λειτουργικότητας, ενώ σε αρκετές έγινε μόνο αναδόμηση κώδικα (refactoring - δηλαδή καμία προσθήκη λειτουργικότητας). 2.1.5 Σχεδιασμός της μελέτης περίπτωσης Σύμφωνα με τους [2], μία μεθοδολογία εμπειρικής μελέτης για να θεωρείται ακέραια πρέπει ο σχεδιασμός της μελέτης περίπτωσης να έχει γίνει με λεπτομέρεια. Ο σχεδιασμός της μελέτης περίπτωσης περιλαμβάνει τον καθορισμός των υποθέσεων, την επιλογή του πιλοτικού έργου και την εύρεση της συγκριτικής μεθόδου όπως περιγράφηκαν προηγουμένως. Τα πρότυπα σχεδίασης που χρησιμοποιήθηκαν στην έρευνα είναι τα εξής: Κατάσταση (State) Γέφυρα (Bridge) Επισκέπτης (Visitor) Προσαρμογέας (Adapter) Σύνθετο (Composite) Οι αντικειμενοστραφείς μετρικές που υπολογίστηκαν είναι οι εξής: Γραμμές κώδικα (LOC) Αριθμός κλάσεων (NOC) Μέθοδοι ανά κλάση (WMPC) Κυκλωματική πολυπλοκότητα (CC) Fan Out (FO) Σύζευξη μεταξύ κλάσεων (CBO) Έλλειψη συνεκτικότητας μεταξύ μεθόδων (LCOM) Μετρικές των ίδιων κατηγοριών έχουν εφαρμοστεί σε επεξηγηματική έρευνα (explanatory research) [1,3,6], και γι αυτό λόγο θεωρούνται κατάλληλες για 53

ποσοτική αξιολόγηση. Το βήμα «παρακολούθηση της μελέτης περίπτωσης σύμφωνα με το σχεδιασμό» αναλύεται στην ενότητα «Περιορισμοί», ενώ το βήμα «Ανάλυση και αναφορά των αποτελεσμάτων» αναλύεται στην ενότητα «Αποτελέσματα». 54

Αποτελέσματα 3 Σε αυτή την ενότητα παρουσιάζονται τα αποτελέσματα που προέκυψαν από τη μελέτη περίπτωσης του παιχνιδιού. Πιο συγκεκριμένα, αρχικά παρατίθενται αποτελέσματα περιγραφικής στατιστικής, και στη συνέχεια ακολουθούν αποτελέσματα από τα t-tests που διεξήχθησαν. 3.1.5.1 Περιγραφική στατιστική Οι στατιστικοί πίνακες και οι γραφικές παραστάσεις αποτελούν χρήσιμα μέσα για την παρουσίαση των δεδομένων με συντομία και σαφήνεια. Ο πίνακας που ακολουθεί παρουσιάζει τον αριθμό των προτύπων σχεδίασης κάθε έκδοσης του λογισμικού που μελετήθηκε. Η ανίχνευση προτύπων πραγματοποιήθηκε όπως περιγράφηκε νωρίτερα. Έκδοση Factory Prototype Singleton Adapter Composite Decorator Observer State Template Visitor CG-1 0 0 1 0 0 0 0 1 0 0 CG-2 0 0 1 0 0 0 0 1 0 1 CG-3 0 0 1 6 1 0 0 2 0 1 CG-4 0 0 1 6 1 0 0 2 0 1 CG-5 0 0 1 6 1 0 0 2 0 1 Πίνακας 3.1 Στιγμιότυπα προτύπων σχεδίασης Στον επόμενο πίνακα παρουσιάζεται το μέγεθος κάθε έκδοσης του παιχνιδιού μέσων των μετρικών LOC και NOC. 55

Έκδοση LOC NOC 2.0 1239 20 3.0 1882 33 4.0 1955 41 5.0 1986 44 5.1 2006 80 Πίνακας 3.2 Μέγεθος του λογισμικού (LOC - NOC) 3.1.5.2 Γραφήματα ανά μετρική Τα γραφήματα που ακολουθούν παρουσιάζουν τις τιμές των μετρικών για κάθε σύνολο κλάσεων που συμμετέχουν σε κάποιο πρότυπο. Οι τιμές των μετρικών των προτύπων σχεδίασης έχουν υπολογιστεί με τον τρόπο που περιγράφηκε στο κεφάλαιο που παρουσιάζεται η μεθοδολογία που χρησιμοποιήθηκε. Στον κάθετο άξονα η κάθε περίπτωση αναφέρεται σε ένα πρότυπο, όπως αυτά δίνονται: κατάσταση, γέφυρα, γέφυρα, επισκέπτης, επισκέπτης, προσαρμογέας, σύνθετο. Σχήμα 3.1 LOC Average Σχήμα 3.2 LOC Max 56

Σχήμα 3.3 CBO Average Σχήμα 3.4 CBO Max Σχήμα 3.5 CC Average Σχήμα 3.6 CC Max Σχήμα 3.7 CR Average Σχήμα 3.8 CR Max 57

Σχήμα 3.9 FO Average Σχήμα 3.10 FO Max Σχήμα 3.11 LOCOM2 Average Σχήμα 3.12 LOCOM2 Max Σχήμα 3.13 WMPC1 Average Σχήμα 3.14 WMPC1 Max 58