ΑΡΙΣΤΟΤΕΛΕΙΟ ΠΑΝΕΠΙΣΤΗΜΙΟ ΘΕΣΣΑΛΟΝΙΚΗΣ ΤΜΗΜΑ ΠΛΗΡΟΦΟΡΙΚΗΣ ΜΕΤΑΠΤΥΧΙΑΚΟ ΠΡΟΓΡΑΜΜΑ ΣΠΟΥΔΩΝ ΣΤΑ ΠΛΗΡΟΦΟΡΙΑΚΑ ΣΥΣΤΗΜΑΤΑ.

ΑΡΙΣΤΟΤΕΛΕΙΟ ΠΑΝΕΠΙΣΤΗΜΙΟ ΘΕΣΣΑΛΟΝΙΚΗΣ ΤΜΗΜΑ ΠΛΗΡΟΦΟΡΙΚΗΣ ΜΕΤΑΠΤΥΧΙΑΚΟ ΠΡΟΓΡΑΜΜΑ ΣΠΟΥΔΩΝ ΣΤΑ ΠΛΗΡΟΦΟΡΙΑΚΑ ΣΥΣΤΗΜΑΤΑ Πτυχιακή εργασία «ΕΠΙΔΡΑΣΗ ΠΡΟΤΥΠΩΝ ΣΧΕΔΙΑΣΗΣ ΣΤΗ ΠΟΙΟΤΗΤΑ ΤΟΥ ΛΟΓΙΣΜΙΚΟΥ ΜΕΣΩ ΑΝΑΛΥΤΙΚΗΣ ΜΕΘΟΔΟΛΟΓΙΑΣ» Της φοιτήτριας Αρβανίτου Ελβίρας-Μαρίας Αρ. Μητρώου: 419 Επιβλέπων Καθηγητής Σταμέλος Ιωάννης Θεσσαλονίκη, 2013 Σελίδα 1 από 84

Σελίδα 2 από 84

ΠΡΟΛΟΓΟΣ Στην εποχή της οικονομικής κρίσης, οι εταιρείες ανάπτυξης λογισμικού αγωνίζονται για την μείωση του λειτουργικού κόστους, χωρίς να επηρεάζουν τον χρόνο παράδοσης των προϊόντων τους στην αγορά καθώς κα την ποιότητα υποστήριξης των πελατών τους. Πολλές μικρές και μεσαίες επιχειρήσεις (SMEs) χάνουν πελάτες, επειδή δεν μπορούν να αντιμετωπίσουν την προσαρμογή των προγραμμάτων που ήδη έχουν κυκλοφορήσει, λόγω της προσπάθειας που δαπανάται για τις δραστηριότητες διόρθωσης σφαλμάτων που κυκλοφόρησαν σε προηγούμενη έκδοση του λογισμικού. Επιπλέον, υπάρχουν πολλοί τομείς του λογισμικού, όπως η βιομηχανία ηλεκτρονικών παιχνιδιών, η οποία εξαρτάται από τις αναβαθμίσεις και τις νέες εκδόσεις ενός προϊόν που παρουσιάζει μικρές μόνο αλλαγές με το προηγούμενο. Όλες οι παραπάνω δραστηριότητες αποτελούν τις πιο συνηθισμένες εργασίες συντήρησης λογισμικού που λαμβάνουν χώρα σε μια εταιρεία ανάπτυξης λογισμικού. Η προσπάθεια μιας τυπικής εταιρείας ανάπτυξης λογισμικού για τη συντήρηση είναι κοντά στο 50% της συνολικής προσπάθειας της εταιρείας. Έτσι, αναμένεται ότι αν οι εταιρείες λογισμικού παράγουν περισσότερο συντηρήσιμο λογισμικό, θα είναι σε θέση να περνούν περισσότερο χρόνο στην ανάπτυξη νέων προϊόντων, ενώ δεν χάνουν τα έσοδα από την υποστήριξη πελατών, τις αναβαθμίσεις και τις προσαρμοσμένες εκδόσεις λογισμικού. Ένας από τους σημαντικότερους παράγοντες που επηρεάζει το κόστος συντήρησης του λογισμικού φαίνεται να είναι η δομική ποιότητα του λογισμικού. Η δομική ποιότητα αντικατοπτρίζεται σε πολλά χαρακτηριστικά του λογισμικού, όπως η κατανόηση, η επεκτασιμότητα, η ευελιξία, τα οποία είναι πολύ σημαντικά κατά τη διάρκεια της συντήρησης ενός λογισμικού. Επιπλέον, τα πρότυπα σχεδίασης λογισμικού έχουν προταθεί από τους Gamma et al. το 1995 ως κοινές λύσεις σε κοινά προβλήματα σχεδιασμού και θεωρούνταιι ως τυποποιημένα στον τομέα του λογισμικού [10]. Η κατάσταση της έρευνας στην τεχνολογία των προτύπων σχεδίασης δείχνει ότι τα πρότυπα σχεδίασης δεν μπορούν να αξιολογηθούν παγκοσμίως σε σχέση με την επίδρασή τους στην δομική ποιότητα του λογισμικού. Η πλειοψηφία από τα άρθρα υποδεικνύουν ότι ο πιο Σελίδα 3 από 84

σημαντικός παράγοντας για το εάν η εφαρμογή των προτύπων σχεδίασης είναι ωφέλιμη ή όχι, είναι η εμπειρία του σχεδιαστή που εφαρμόζει τα πρότυπα και η διαίσθηση του/της σχετικά με το εάν τα πρότυπα σχεδίασης θα πρέπει να χρησιμοποιούνται ή όχι. Μια σύνοψη της κατάστασης της έρευνας της τεχνολογίας αποκαλύπτει ότι υπάρχουν αρκετές περιπτώσεις προτύπων σχεδίασης που παρουσιάζουν διαφορετική επίδραση του προτύπου, στο ίδιο ποιοτικό χαρακτηριστικό [3]. Για παράδειγμα, το πρότυπο σχεδίασης Visitor έχει αξιολογηθεί από δύο μελέτες που συσχετίζεται θετικά με τη συντηρησιμότητα και αρνητικά με συντηρησιμότητα από δύο άλλες μελέτες. Από τα παραπάνω γίνεται σαφές ότι υπάρχει μεγάλη δυσκολία για να απαντήσει κάποιος στην ερώτηση "Εάν υπάρχει κάποιος αντικειμενικός τρόπος για την χρησιμοποίησης ενός προτύπου σχεδίασης ή δεν υπάρχει;" Στο [4] οι συγγραφείς προτείνουν μια αναλυτική μεθοδολογία για να συγκρίνουν τα πρότυπα ισοδύναμης λειτουργικότητας και εφαρμόζουν την μεθοδολογία τους σε τρία πρότυπα σχεδίασης, δηλαδή στα Bridge, Abstract Factory και Visitor. Στην εργασία αυτή, χρησιμοποιούμε την ίδια μεθοδολογία για τρία επιπλέον πρότυπα, δηλαδή στο Decorator, Template Method και Strategy. Εκτός από αυτό, πραγματοποιούμε μια μελέτη περίπτωσης, προκειμένου να επικυρώσουμε τα αποτελέσματα της αναλυτικής μεθόδου μέσω εμπειρικών δεδομένων. Σελίδα 4 από 84

ΠΕΡΙΛΗΨΗ Η παρούσα διπλωματική εργασία χωρίζεται σε δύο μέρη και ασχολείται με την επίδραση των προτύπων σχεδίασης στη δομική ποιότητα του λογισμικού. Αρχικά, κάνοντας χρήση μιας ήδη δημοσιευμένης αναλυτικής μεθοδολογίας σύγκρισης σχεδίων λογισμικού, μπορέσαμε να εξάγουμε χρήσιμα συμπεράσματα σε ότι αφορά την ποιότητα των προτύπων σχεδίασης Decorator, Template Method και Strategy. Στη συνέχεια, για να επικυρώσουμε τα αποτελέσματα της αναλυτικής μεθοδολογίας, διενεργήσαμε μια μελέτη περίπτωσης σε πέντε παιχνίδια ανοιχτού λογισμικού γραμμένα σε java. Αναλυτικότερα, για κάθε παιχνίδι πήραμε δυο εκδόσεις του λογισμικού. Από αυτές, η μία έκδοση περιλαμβάνει ένα στιγμιότυπο ενός προτύπου σχεδίασης, ενώ η άλλη έκδοση περιλαμβάνει μια εναλλακτική σχεδιαστική λύση χωρίς πρότυπο. Τα αποτελέσματα της εμπειρικής μελέτης επιβεβαίωσαν τους κανόνες που εξάγονται μέσω της αναλυτικής μεθοδολογίας. Σελίδα 5 από 84

ABSTRACT This thesis is divided into two parts and investigates the effect of design patterns on structural software quality attributes. At first, using an already published analytical methodology for comparing software designs, we managed to export useful conclusions with regard to the quality of Decorator, Template Method and Strategy patterns. Then, to validate the results of the analytical methodology, we conducted a case study in five open source games written in java. More specifically, for each game we got two versions of the software. The one version includes an instance of a design pattern, whereas the other version includes an alternate design solution without pattern. The results of the empirical study confirmed the rules that have been extracted by the analytical methodology. Σελίδα 6 από 84

ΕΥΧΑΡΙΣΤΙΕΣ Η παρούσα εργασία αποτελεί διπλωματική εργασία στα πλαίσια του μεταπτυχιακού προγράμματος «Πληροφοριακά Συστήματα» του τμήματος Πληροφορικής. Πριν την παρουσίαση των αποτελεσμάτων της παρούσας διπλωματικής εργασίας, αισθάνομαι την υποχρέωση να ευχαριστήσω ορισμένους από τους ανθρώπους που γνώρισα, συνεργάστηκα μαζί τους και έπαιξαν πολύ σημαντικό ρόλο στην πραγματοποίησή της. Πρώτο από όλους θέλω να ευχαριστήσω τον επιβλέποντα καθηγητή της διπλωματικής εργασίας, τον Σταμέλο Ιωάννη ο οποίος μου εμπιστεύτηκε την ανάθεση αυτής της εργασίας και προσέφερε την πολύτιμη βοήθεια για την ολοκλήρωση της. Στη συνέχεια θα ήθελα να ευχαριστήσω τον διδάκτορα Αμπατζόγλου Απόστολο για την πολύτιμη καθοδήγηση του και την εμπιστοσύνη και εκτίμηση που μου έδειξε. Τέλος, θέλω να ευχαριστήσω τους γονείς μου Χρήστο και Δήμητρα, τον αδερφό μου Νίκο, καθώς και τον φίλο μου Άκη, που με υπομονή και κουράγιο πρόσφεραν την απαραίτητη ηθική συμπαράσταση για την ολοκλήρωση της μεταπτυχιακής μου εργασίας. Σελίδα 7 από 84

ΠΕΡΙΕΧΟΜΕΝΑ Περιεχόμενα ΠΡΟΛΟΓΟΣ... 3 ΠΕΡΙΛΗΨΗ... 5 ABSTRACT... 6 ΕΥΧΑΡΙΣΤΙΕΣ... 7 ΠΕΡΙΕΧΟΜΕΝΑ... 8 ΕΥΡΕΤΗΡΙΟ ΠΙΝΑΚΩΝ ΣΧΗΜΑΤΩΝ... 9 1. Εισαγωγή... 12 1.1 Ανοιχτό Λογισμικό... 12 1.2 Πρότυπα Σχεδίασης... 14 1.2.1 Πρότυπο Decorator... 16 1.2.2 Πρότυπο Template Method... 17 1.2.3 Πρότυπο Strategy... 18 1.3 Μετρικές Ποιότητας Λογισμικού σε Επίπεδο Σχεδίασης... 19 1.3.1 Ανάπτυξη Μοντέλων Ποιότητας... 20 1.3.1.1 Προσδιορισμός Χαρακτηριστικών Ποιότητας Σχεδιασμού... 21 1.3.1.2 Προσδιορισμός των ιδιοτήτων Αντικειμενοστρεφούς Σχεδιασμού... 23 1.4 Σκοπός Διπλωματικής... 34 1.5 Μεθοδολογία... 35 2. Εφαρμογή Μεθοδολογίας... 37 2.1 Πρότυπο Σχεδίασης «Decorator»... 39 2.1.1 Σχεδιαστικές Προσεγγίσεις... 39 2.1.2 Αποτελέσματα... 41 2.2 Πρότυπο Σχεδίασης «Template Method»... 47 2.2.1 Σχεδιαστικές Προσεγγίσεις... 48 2.2.2 Αποτελέσματα... 49 2.3 Πρότυπο Σχεδίασης «Strategy»... 55 2.3.1 Σχεδιαστικές Προσεγγίσεις... 55 2.2.2 Αποτελέσματα... 56 2.4 Συζήτηση... 61 2.4.1 Decorator... 62 2.4.2 Template Method... 64 2.4.3 Strategy... 67 3. Εμπειρική Μελέτη... 69 3.1 Μεθοδολογία... 70 3.1.1 Καθορισμός ερωτήσεων έρευνας... 70 3.1.2 Επιλογή project και αντικέιμενα... 71 3.1.3 Αναγνώριση μεθόδου σύγκρισης... 72 3.1.4 Ανάλυση και αναφορά των αποτελεσμάτων... 73 4 ΣΥΜΠΕΡΑΣΜΑΤΑ... 81 ΒΙΒΛΙΟΓΡΑΦΙΑ... 83 Σελίδα 8 από 84

ΕΥΡΕΤΗΡΙΟ ΠΙΝΑΚΩΝ ΣΧΗΜΑΤΩΝ Σχήμα 1: Διάγραμμα κλάσεων προτύπου Decorator...15 Σχήμα 2: Διάγραμμα κλάσεων προτύπου Template Method..16 Σχήμα 3: Διάγραμμα κλάσεων προτύπου Strategy...17 Σχήμα 4: Επίπεδα και σχέσεις στο QMOOD...19 Σχήμα 5: Διάγραμμα Κλάσεων Λύση «Πρότυπο Σχεδίασης».39 Σχήμα 6: Διάγραμμα Κλάσεων Λύση «Alternative Πρότυπο Σχεδίασης»...39 Σχήμα 7: Διάγραμμα Κλάσεων Λύση «Πρότυπο Σχεδίασης».47 Σχήμα 8: Διάγραμμα Κλάσεων Λύση «Alternative Πρότυπο Σχεδίασης»...48 Σχήμα 9: Διάγραμμα Κλάσεων Λύση «Πρότυπο Σχεδίασης».54 Σχήμα 10: Διάγραμμα Κλάσεων Λύση «Alternative Πρότυπο Σχεδίασης».55 Σχήμα 11: Πρότυπο Decorator.73 Σχήμα 12: Πρότυπο Template Method.74 Σχήμα 13: Πρότυπο Strategy 75 Πίνακας 1 : Ορισμοί Χαρακτηριστικών Ποιότητας...21 Πίνακας 2: Ορισμοί Ιδιοτήτων Σχεδιασμού.22 Πίνακας 3: Περιγραφή Μετρικών Σχεδιασμού...25 Πινακας 4 : Μετρικές Σχεδιασμού για τις Ιδιότητες Σχεδιασμού 29 Πίνακας 5: Σχέσεις Ιδιοτήτων Σχεδιασμού..31 Πίνακας 6 : Ορισμοί Χαρακτηριστικών Ποιότητας.32 Πίνακας 7: Μετρικές Συντηρησιμότητας για τις Σχεδιαστικές Επιλογές 45 Πίνακας 8: Μετρικές για τις Σχεδιαστικές Επιλογές 45 Πίνακας 9: Μετρικές για τις Σχεδιαστικές Επιλογές 46 Πίνακας 10: Μετρικές Συντηρησιμότητας για τις Σχεδιαστικές Επιλογές..52 Πίνακας 11: Μετρικές για τις Σχεδιαστικές Επιλογές..53 Πίνακας 12: Μετρικές για τις Σχεδιαστικές Επιλογές..53 Πίνακας 13: Μετρικές Συντηρησιμότητας για τις Σχεδιαστικές Επιλογές..59 Πίνακας 14: Μετρικές για τις Σχεδιαστικές Επιλογές..60 Πίνακας 15: Μετρικές για τις Σχεδιαστικές Επιλογές..60 Πίνακας 16: Διαγράμματα περιπτώσεων..62 Πίνακας 17: Διαγράμματα περιπτώσεων..64 Πίνακας 18: Διαγράμματα περιπτώσεων..67 Πίνακας 19: Έλεγχος υποθέσεων για το πρότυπο Decorator 76 Πίνακας 20: Έλεγχος υποθέσεων για το πρότυπο Template Method..78 Πίνακας 21: Έλεγχος υποθέσεων για το πρότυπο Strategy..80 Σελίδα 9 από 84

Σελίδα 10 από 84

Σελίδα 11 από 84

1. Εισαγωγή Σε αυτό το κεφάλαιο θα παρουσιαστούν οι εισαγωγικές έννοιες που μας απασχόλησαν σε αυτή την διπλωματική, το κίνητρο της εργασίας και η μεθοδολογία της. Έτσι πιο συγκεκριμένα, στην ενότητα 1.1 θα παρουσιαστεί μια εισαγωγή για το ανοιχτό λογισμικό, στην ενότητα 1.2 θα παρουσιάσουμε τα πρότυπα σχεδίασης που λάβαμε υπόψη, στην ενότητα 1.3 θα αναφέρουμε τις μετρικές που χρησιμοποιήσαμε στην μεθοδολογία μας, στην ενότητα 1.4 αναφέρουμε τον σκοπό της διπλωματικής και στην ενότητα 1.5 θα αναφέρουμε την μεθοδολογία που χρησιμοποιήσαμε. 1.1 Ανοιχτό Λογισμικό Στα πρωταρχικά χρόνια του προγραμματισμού, το λογισμικό διανέμονταν μαζί με το πηγαίο κώδικα. Ειδικότερα, το λογισμικό ήταν άμεσα συνδεδεμένο με το υλικό του κατασκευαστή. Εξαιτίας της πολυπλοκότητας και του κόστους ανάπτυξης (καθώς και της σχετικά περιορισμένης ισχύος που διέθεταν οι πρώτοι υπολογιστές), των επιχειρηματικών μοντέλων των κατασκευαστών (μοντέλα που βασίζονταν στην πώληση του υλικού), καθώς και άλλων παραγόντων, οι χρήστες ελεύθερα διαμοιράζονταν τον πηγαίο κώδικα των εφαρμογών με συνεργατικό τρόπο, κάτι που οδήγησε στη δημιουργία ομάδων χρηστών, μερικές από τις οποίες είναι ακόμα ενεργές. Με την αποσύνδεση του υλικού από το λογισμικό, στις αρχές της δεκαετίας του 1970, εμφανίστηκαν στην αγορά τα πρώτα προϊόντα λογισμικού με τη μορφή πακέτου. Σταδιακά, λοιπόν, η διάδοση του πηγαίου κώδικα σταμάτησε να γίνεται ευρύτατα, καθώς οι πωλητές λογισμικού άρχισαν σταδιακά να αποκρύβουν τον κώδικα. Η εμπορευματοποίηση του λογισμικού που επικρατούσε παρείχε στους χρήστες κάποια οφέλη αλλά δεν υπήρχε παραμετροποίηση του λογισμικού στις ανάγκες του καθενός. Αντιλαμβανόμενος ο Richard Stallman αυτόν τον ανασταλτικό παράγοντα στην ανάπτυξη του λογισμικού και στην πρόοδο της τεχνολογίας των υπολογιστών, ξεκίνησε το GNU project με σκοπό να παρέχει ελεύθερο UNIX. Στα χρόνια που προηγήθηκαν αυτού του βήματος, οι προγραμματιστές του GNU είχαν δημιουργήσει μια ποικιλία από καινοτόμα ανοιχτού κώδικα εργαλεία. Ο Richard Stallman ήταν και ο πρώτος που εισήγαγε τον όρο ελεύθερο λογισμικό (free software) και ίδρυσε το Ίδρυμα Ελεύθερου Λογισμικού (Free Software Foundation) το Σελίδα 12 από 84

1983 προκειμένου να βρεθεί ένας τρόπος διατήρησης της ελευθερίας των χρηστών να μελετούν, να κατανοούν και να τροποποιούν το λογισμικό, μέσα στο πλαίσιο του πνεύματος, που διέπει την κοινότητα των hackers και αφορά την απρόσκοπτη διάχυση των πληροφοριών. Αργότερα, ο οργανισμός Open Source Iniative πρότεινε τον όρο λογισμικό ανοιχτού κώδικα (open source software), πιθανότατα προκειμένου να αποφευχθεί η παρερμηνεία του αγγλικού όρου free, ο οποίος χρησιμοποιήθηκε από το FSF για την απόδοση της έννοιας της ελευθερίας και όχι της έννοιας δωρεάν. Η δημιουργία του Linux το 1991, ενός ελεύθερου, συμβατού με το UNIX, λειτουργικού συστήματος, άλλαξε πολύ την στάση των προγραμματιστών προς τον κώδικα ανοιχτού λογισμικού. Ο δημιουργός του πυρήνα Linux, Linus Torvalds, πέτυχε τις προσδοκίες του, δημιουργώντας μια ομάδα προγραμματιστών και ατόμων που συνεισέφεραν στην ανάπτυξη μέσω του Internet. Ο Linus έδινε σε κυκλοφορία νέες εκδόσεις του λειτουργικού συστήματος και οι υπόλοιποι προγραμματιστές έκαναν αποσφαλμάτωση και πρόσθεταν νέες λειτουργίες. Ο Eric Raymond, ένας ευαγγελιστής του ανοιχτού-κώδικα, ονόμασε αυτή την προσέγγιση μοντέλο Bazaar, υποδηλώνοντας έτσι τη χαοτική αλλά αποτελεσματική οργάνωση των προγραμματιστών στο Internet, σε αντίθεση με τη παραδοσιακή προσέγγιση Cathedral που επικρατούσε μέχρι τότε. Παράλληλα, εξηγεί ότι η σταθερότητα των προγραμμάτων ανοιχτού-κώδικα είναι αποτέλεσμα του μεγάλου αριθμού προγραμματιστών και δοκιμαστών, καθώς οποιοδήποτε μεγάλο σφάλμα, φαίνεται μικρό κάτω από το βλέμμα πολλών ματιών. Το κλειδί στο λογισμικό ανοιχτού-κώδικα είναι η διαθεσιμότητα του πηγαίου κώδικα, καθώς επιτρέπει στους χρήστες με ειδικές προγραμματιστικές ικανότητες να το προσαρμόσουν στις προσωπικές τους απαιτήσεις και να εξαλείψουν τα σφάλματα που εμφανίζονται στη χρήση. Η ευρέως διαδεδομένη χρήση της άδειας ελεύθερου λογισμικού, GNU General Public License, εγγυάται ότι ο καθένας μπορεί να τροποποιήσει και να αναδιανείμει προγράμματα, έχοντας ως προϋπόθεση ότι δεν εμποδίζει άλλους από το να πράξουν το ίδιο. Στις μέρες μας υπάρχουν αναρίθμητες εφαρμογές και προγράμματα ανοικτούκώδικα. Γνωστά παραδείγματα είναι το λειτουργικό σύστημα Linux, ο Apache Server, Σελίδα 13 από 84

η Perl, το Mozilla κ.α. Μερικά από τα προγράμματα αυτά βγάζουν εκτός συναγωνισμού εμπορικά προγράμματα αντίστοιχου είδους και πολλές εταιρίες όπως η Apple και η Sun Microsystems κάνουν χρήση των προγραμμάτων αυτών. Δίνοντας έναν ορισμό για το ανοιχτό λογισμικό, θα πρέπει να αναφέρουμε το σύνολο των συνθηκών στο οποίο βασίζεται: Ελεύθερη Αναδιανομή Πηγαίος Κώδικας: Το πρόγραμμα που διατίθεται πρέπει να περιλαμβάνει τον πηγαίο κώδικα, ενώ συγχρόνως πρέπει να επιτρέπεται η διάθεσή του είτε ως πηγαίος κώδικας είτε σε μεταγλωττισμένη μορφή. Παραγόμενα Έργα: Η άδεια χρήσης πρέπει να επιτρέπει τροποποιήσεις του προγράμματος, καθώς και πιθανά παραγόμενα έργα, τα οποία πρέπει να διανέμονται με τους ίδιους όρους που διέπουν το αρχικό λογισμικό. Ακεραιότητα του πηγαίου κώδικα του συγγραφέα Καμία διάκριση εναντίον ατόμων ή ομάδων ατόμων Καμία διάκριση εναντίον κάποιων τομέων δραστηριοποίησης: Για παράδειγμα, δεν μπορεί να περιορίζει τη χρήση του προγράμματος για την εξυπηρέτηση των αναγκών μιας επιχείρησης ή μιας ερευνητικής ομάδας που εξετάζει ζητήματα γενετικής. Διανομή της άδειας χρήσης Η άδεια χρήσης δεν πρέπει να αφορά μόνο ένα συγκεκριμένο προϊόν Η άδεια χρήσης δεν πρέπει να περιορίζει άλλα λογισμικά Η άδεια χρήσης πρέπει να είναι τεχνολογικά ουδέτερη: Κανένας όρος της άδειας χρήσης δεν πρέπει να επιβάλλει τη χρήση συγκεκριμένων τεχνολογιών ή διεπαφών. 1.2 Πρότυπα Σχεδίασης Στα τέλη της δεκαετίας του 1970 ένας αρχιτέκτονας ονόματι Christopher Alexander επιχείρησε να βρει και να καταγράψει αποδεδειγμένα ποιοτικούς σχεδιασμούς στον τομέα των κατασκευών. Έτσι μελέτησε πολλές διαφορετικές Σελίδα 14 από 84

κατασκευές που εξυπηρετούσαν τον ίδιο σκοπό και προσπάθησε να ανακαλύψει κοινά στοιχεία, τα οποία κατηγοριοποίησε σε σχεδιαστικά πρότυπα. Το 1987 ο Kent Beck και ο Ward Cunningham άρχισαν να πειραματίζονται με την ιδέα της εύρεσης σχεδιαστικών προτύπων, η οποία εφαρμόστηκε για πρώτη φορά στη μηχανική λογισμικού και μέχρι τα μέσα της δεκαετίας του '90 η εν λόγω έννοια είχε καθιερωθεί και εξαπλωθεί, προσανατολισμένη πλέον προς τον αντικειμενοστρεφή προγραμματισμό. Στο [10] καταγράφονται 23 πρότυπα που επιλύουν συνήθη προβλήματα στη σχεδίαση λογισμικού. Έχουν οριστεί διάφορες κατηγορίες προτύπων, για διαφορετικά προβλήματα και κάθε κατηγορία περιλαμβάνει πολλαπλά στοιχεία. Έτσι, τα σχεδιαστικά πρότυπα κατηγοριοποιούνται σε κατασκευαστικά, δομικά και συμπεριφορικά. Κατασκευαστικά πρότυπα (Creational Patterns): Τα κατασκευαστικά πρότυπα αφορούν τυποποιημένους τρόπους δυναμικής κατασκευής αντικειμένων κατά τον χρόνο εκτέλεσης. Απώτερος στόχος τους είναι η ανεξαρτητοποίηση του κώδικα που χρησιμοποιεί κάποια αντικείμενα από τις κλάσεις που ορίζουν τα αντικείμενα αυτά και τον τρόπο που κατασκευάζονται στη μνήμη, σύμφωνα με την αρχή ανοιχτής-κλειστής σχεδίασης για ορθή αντικειμενοστρεφή σχεδίαση. Τέτοια κατασκευαστικά πρότυπα είναι το Factory, το Singleton και το Prototype. Δομικά πρότυπα (Structural Patterns): Τα δομικά πρότυπα αφορούν τυποποιημένους τρόπους δυναμικής κατασκευής σύνθετων αντικειμένων τα οποία χρησιμοποιούν υπάρχουσες ιεραρχίες κλάσεων. Τέτοια δομικά πρότυπα είναι το Adapter και το Decorator. Συμπεριφορικά πρότυπα (Behavioural Patterns): Τα συμπεριφορικά πρότυπα αφορούν τον καταμερισμό αρμοδιοτήτων σε διάφορες κλάσεις και τον ορισμό του τρόπου επικοινωνίας μεταξύ των αντικειμένων τους κατά τον χρόνο εκτέλεσης. Σε αντίθεση με τα δομικά πρότυπα, τα συμπεριφορικά βρίσκουν εφαρμογή στον αρχικό σχεδιασμό μίας ιεραρχίας κλάσεων και όχι στην εκ των υστέρων επέκταση κάποιας υπάρχουσας ιεραρχίας. Τέτοια συμπεριφορικά πρότυπα είναι το Strategy, το State, το Observer, το Template και το Visitor. Σελίδα 15 από 84

1.2.1 Πρότυπο Decorator Το πρότυπο αυτό επιτρέπει την εύκολη και δυναμική επέκταση της λειτουργικότητας κάποιων υπαρχόντων κλάσεων Α, Β κλπ, οι οποίες υλοποιούν την ίδια διασύνδεση ή κληρονομούν την ίδια αφηρημένη κλάση (έστω Interface), σε χρόνο εκτέλεσης. Αυτό επιτυγχάνεται μέσω μίας νέας κλάσης Decorator, η οποία επίσης υλοποιεί την Interface αλλά περιέχει ως ιδιωτικό πεδίο και μία αναφορά σε ένα στιγμιότυπο του γενικού τύπου Interface (έστω το instance), η οποία τυπικά μεταβιβάζεται ως όρισμα στον κατασκευαστή της Decorator. Έτσι οι μέθοδοι της τελευταίας υλοποιούν εσωτερικά την καινούργια λειτουργικότητα αλλά για τις κοινές εργασίες καλούν τις αντίστοιχες μεθόδους του instance. Κατά τον χρόνο εκτέλεσης θα μπορούσε το αντικείμενο Decorator να κατασκευάζεται με όρισμα οποιοδήποτε στιγμιότυπο τύπου Interface (ακόμα και του ίδιου του Decorator, αν και αυτό δε θα είχε ιδιαίτερο νόημα) ώστε κατά περίπτωση το αντικείμενο να παρέχει τη λειτουργικότητα οποιασδήποτε κλάσης τύπου Interface, είτε της Α είτε κάποιας άλλης, επεκτεταμένης με ένα συγκεκριμένο σύνολο δυνατοτήτων. Με αυτόν τον τρόπο γίνεται εφικτός ένας δυναμικός συνδυασμός λειτουργιών από στοιχειώδεις δομικούς λίθους κατά τον χρόνο εκτέλεσης. Η εναλλακτική σχεδιαστική λύση, χωρίς χρήση κάποιου σχεδιαστικού προτύπου, θα ήταν η απλή κληρονομικότητα, με τον ορισμό κλάσεων οι οποίες επεκτείνουν τις Α, Β κλπ. και προσθέτουν τη νέα λειτουργικότητα. Ωστόσο η λύση αυτή δεν είναι εφικτή σε περίπτωση που οι Α, Β κλπ. δεν μπορούν να επεκταθούν με κληρονομικότητα (π.χ. αν δηλωθούν ως τελικές κλάσεις στην Java), ενώ σε άλλες περιπτώσεις δεν είναι καθόλου πρακτική, π.χ. αν έχουμε πολλαπλά διαφορετικά σύνολα νέων δυνατοτήτων τα οποία πρέπει να συνδυαστούν με τις Α, Β κλπ. Το πρόβλημα έγκειται στο ότι με την κληρονομικότητα όλοι οι πιθανοί συνδυασμοί δυνατοτήτων πρέπει να προβλεφθούν και να ληφθούν υπ όψιν κατά τη συγγραφή του προγράμματος. Αντιθέτως με την κλάση Decorator, η οποία δρα ως περίβλημα (wrapper) άλλων αντικειμένων τύπου Interface προς τα οποία περιέχει αναφορές / Σελίδα 16 από 84

δείκτες, η σύνθεση νέων αντικειμένων ουσιαστικά γίνεται δυναμικά ενώ το πρόγραμμα εκτελείται [10]. Γενική Δομή Σχήμα 1: Διάγραμμα κλάσεων προτύπου Decorator 1.2.2 Πρότυπο Template Method Το πρότυπο αυτό είναι εκλέπτυνση του Strategy για την περίπτωση που κάθε αλγόριθμος έχει πολλαπλές παραλλαγές οι οποίες διαφέρουν σε ορισμένα βήματα αλλά κάποια άλλα σημεία τους είναι κοινά. Τότε για κάθε αλγόριθμο μπορούμε να ορίσουμε ένα στοιχείο αφαίρεσης Β το οποίο υλοποιεί τη διασύνδεση Α και με τη σειρά του κληρονομείται από πολλές παραλλαγές του αλγορίθμου. Το κάθε Β περιέχει την υλοποίηση των αμετάβλητων βημάτων και, στα σημεία που οι παραλλαγές Σελίδα 17 από 84

διαφέρουν, καλεί αφηρημένες προστατευμένες μεθόδους. Οι μέθοδοι αυτές υλοποιούνται διαφορετικά σε κάθε παραλλαγή που κληρονομεί το Β. Το πρότυπο χρησιμοποιείται για τον ορισμό των αμετάβλητων τμημάτων και τη μετάθεση της υλοποίησης των μεταβλητών τμημάτων του αλγόριθμου σε παράγωγες κλάσεις [7]. Γενική Δομή Σχήμα 2: Διάγραμμα κλάσεων προτύπου Template Method 1.2.3 Πρότυπο Strategy Το πρότυπο αυτό ενθυλακώνει την κατάσταση ενός αντικειμένου, ώστε να μπορεί να αλλάξει τη συμπεριφορά του, όταν αλλάξει η εσωτερική κατάσταση του αντικειμένου [10]. Όταν είναι διαθέσιμοι πολλαπλοί τρόποι επίλυσης ενός προβλήματος (π.χ. διαφορετικοί αλγόριθμοι), είναι προτιμότερο ο καθένας από αυτούς να μην υλοποιείται μέσα στις κλάσεις-πελάτες που τον χρησιμοποιούν (π.χ. ως ιδιωτική μέθοδος), έτσι ώστε οι πελάτες να έχουν μικρότερη περιπλοκότητα και οι διάφοροι αλγόριθμοι να είναι επαναχρησιμοποιήσιμοι και προσπελάσιμοι από πολλαπλά εξωτερικά προγράμματα. Με το πρότυπο Strategy όλοι οι διαφορετικοί αλγόριθμοι ορίζονται ως ξεχωριστές κλάσεις που υλοποιούν μία κοινή διασύνδεση Α και οι πελάτες διατηρούν ως πεδίο μία αναφορά προς τον αφηρημένο τύπο Α. Στο πεδίο αυτό δίνεται τιμή μέσω του ορίσματος κάποιας μεθόδου του πελάτη (πιθανώς Σελίδα 18 από 84

του κατασκευαστή του), έτσι ώστε η ταυτότητα του εκάστοτε χρησιμοποιούμενου αλγορίθμου από όλους τους διαθέσιμους για την εκτέλεση της ζητούμενης εργασίας να είναι εύκολα παραμετροποιημένη, με μία απλή αλλαγή αυτού του ορίσματος κατά την κλήση της προαναφερθείσας μεθόδου. Γενική Δομή Σχήμα 3: Διάγραμμα κλάσεων προτύπου Strategy 1.3 Μετρικές Ποιότητας Λογισμικού σε Επίπεδο Σχεδίασης Σε αυτή την ενότητα γίνεται μια περιγραφή ενός βελτιωμένου ιεραρχικού μοντέλου για την αξιολόγηση των χαρακτηριστικών ποιότητας υψηλού επιπέδου στην αντικειμενοστρεφή σχεδίαση. Σ αυτό το μοντέλο, οι ιδιότητες σχεδιασμού των κλάσεων, των αντικειμένων και οι συσχετίσεις τους αξιολογούνται με τη χρήση μετρικών αντικειμενοστεφούς σχεδίασης. Αυτό το μοντέλο συσχετίζει ιδιότητες σχεδιασμού όπως είναι η ενθυλάκωση(encapsulation), η σύζευξη (coupling) και η συνοχή (cohesion) με χαρακτηριστικά ποιότητας υψηλού επιπέδου όπως η επαναχρησιμοποίηση(reusability), η ευελιξία(flexibility), και η πολυπλοκότητα (complexity) χρησιμοποιώντας πληροφορίες από άλλες εμπειρικές μελέτες. Σελίδα 19 από 84

1.3.1 Ανάπτυξη Μοντέλων Ποιότητας Τα πιο πρόσφατα μοντέλα ποιότητας αναπτύχθηκαν από τον Dromey. Εξετάζει μερικά προβλήματα των προηγούμενων μοντέλων ποιότητας όπως του McCall και του ISO 9126. Το πλαίσιο εργασίας είναι μια μεθοδολογία για την ανάπτυξη των μοντέλων ποιότητας «από κάτω προς τα πάνω», παρέχοντας μια προσέγγιση που εξασφαλίζει ότι οι λεπτομέρειες χαμηλού επιπέδου είναι καλά ορισμένες και υπολογίσιμες. Το πλαίσιο εργασίας του μοντέλου που προτείνει ο Dromey, όπως και τα προηγούμενα μοντέλα, βασίζεται στη διάσπαση των χαρακτηριστικών ποιότητας σε αντιληπτές ιδιότητες ποιότητας των τμημάτων ενός προϊόντος(απαιτήσεις, σχεδιασμός και υλοποίηση). Υπάρχουν τρία στοιχεία στο γενικό μοντέλο ποιότητας του Dromey: οι ιδιότητες προϊόντος που επηρεάζουν την ποιότητα, κάποια χαρακτηριστικά ποιότητας υψηλού επιπέδου και ένα μέσο διασύνδεσης τους. Αυτή η μεθοδολογία χρησιμοποιείται για την ανάπτυξη του Ιεραρχικού Μοντέλου για την Αξιολόγηση Ποιότητας Αντικειμενοστραφούς Σχεδιασμού (Quality Model for Object- Oriented Design, QMOOD) που επεκτείνει το γενικό μοντέλο ποιότητας του Dromey και περιλαμβάνει τα βήματα που φαίνονται στο Σχήμα 4 τα οποία και αναλύονται παρακάτω. Σχήμα 4: Επίπεδα και σχέσεις στο QMOOD Το σχήμα 1 δείχνει τα τέσσερα επίπεδα ( μέχρι ) και τις τρεις συσχετίσεις (,, ) που χρησιμοποιούνται για να συνδέσουν τα τέσσερα επίπεδα στο QMOOD. Μετά τον καθορισμό των επιπέδων πρέπει να προσδιοριστούν και τα ποιοτικά χαρακτηριστικά όπως είναι οι αντικειμενοστρεφείς σχεδιαστικές μετρικές, τα Σελίδα 20 από 84

αντικειμενοστρεφή σχεδιαστικά συστατικά και ο καθορισμός των συσχετίσεων, που απαιτεί την σύνδεση του χαμηλότερου επιπέδου με το αμέσως επόμενο υψηλότερο επίπεδο. 1.3.1.1 Προσδιορισμός Χαρακτηριστικών Ποιότητας Σχεδιασμού ( ) Τα χαρακτηριστικά ποιότητας που χρησιμοποιούνται στο Πρότυπο ISO 9126 (λειτουργικότητα (functionality), αξιοπιστία (reliability), αποδοτικότητα (efficiency), χρηστικότητα (usability), συντηρισιμότητα (maintainability) και μεταφερσιμότητα (portability)) επιλέχθηκαν ως το αρχικό σύνολο χαρακτηριστικών ποιότητας στο μοντέλο QMOOD, για να δούμε αν συμβάλουν στον καθορισμό της ποιότητας και αν το σύνολο τους είναι αρκετά ευρύ ώστε να περιλαμβάνει όλες τις πτυχές της ποιότητας σχεδιασμού. Τα χαρακτηριστικά αξιοπιστία (reliability) και χρηστικότητα (usability) εξαιρέθηκαν από το σύνολο γιατί βασίζονται κυρίως στην υλοποίηση και όχι στον σχεδιασμό. Ο όρος μεταφερσιμότητα (portability) είναι πιο κατάλληλος για το πλαίσιο της εφαρμογής της ποιότητας του λογισμικού και αντικαταστάθηκε από τον όρο επεκτασιμότητα (extendibility), που αντικατοπτρίζει καλύτερα τα χαρακτηριστικά σχεδίασης. Επίσης ο όρος συντηρισιμότητα (maintainability) προϋποθέτει την ύπαρξη ενός προϊόντος λογισμικού και αντικαταστάθηκε από τον όρο «κατανόηση» (understandability), διότι επικεντρώνεται καλύτερα στα χαρακτηριστικά της σχεδίασης. Ένας σημαντικός λόγος υιοθέτησης της αντικειμενοστρεφούς σχεδίασης ήταν η ικανότητα σχεδιασμού αξιόπιστων, προσαρμόσιμων και ευέλικτων συστημάτων λογισμικού, πολύ γρήγορα. Ένας τρόπος για την επίτευξη αυτού του στόχου ήταν η επαναχρησιμοποίηση σε όλα τα επίπεδα της σχεδίασης. Αυτό δικαιολογεί την ένταξη της «επαναχρησιμοποίησης» ως ένα πολύ σημαντικό χαρακτηριστικό ποιότητας στον αντικειμενοστρεφή σχεδιασμό. Η «ευελιξία» (flexibility) των συστημάτων λογισμικού αποτελεί επίσης ένα σημαντικό χαρακτηριστικό ανάπτυξης και τελικού-χρήστη. Για να μπορέσει το χαρακτηριστικό αυτό να αποτελεί μέρος των χαρακτηριστικών ποιότητας πρέπει να καθοριστεί στη φάση σχεδιασμού με την ενσωμάτωση των αρχιτεκτονικών λογισμικού. Αποφασίστηκε λοιπόν να συμπεριληφθεί το χαρακτηριστικό «ευελιξία» Σελίδα 21 από 84

ως ένα από τα χαρακτηριστικά ποιότητας στο μοντέλο του σχεδιασμού. Μ αυτόν τον τρόπο το αρχικό σύνολο των χαρακτηριστικών ποιότητας στο QMOOD διαμορφώνεται ως εξής : «λειτουργικότητα», «επεκτασιμότητα», «ικανότητα κατανόησης», «αποτελεσματικότητα», «επαναχρησιμοποίηση» και «ευελιξία». Προκύπτει ότι το σύνολο αυτών των χαρακτηριστικών είναι αρκετά ευρύ για να επιτρέπει τον προσδιορισμό των επιθυμητών χαρακτηριστικών αντικειμενοστρεφών συστημάτων. Tο σύνολο των χαρακτηριστικών δεν είναι απόλυτο μπορεί εύκολα να αλλάξει προκειμένου να αντιμετωπίσει διαφορετικούς στόχους και σκοπούς. Τα χαρακτηριστικά ποιότητας είναι αφηρημένες έννοιες και δεν είναι άμεσα παρατηρήσιμες, επίσης δεν υπάρχουν καθολικά αποδεκτοί ορισμοί για τα χαρακτηριστικά ποιότητας του QMOOD. Πίνακας 1 - Ορισμοί Χαρακτηριστικών Ποιότητας Χαρακτηριστικά Ποιότητας Ορισμός Reusability Αντανακλά την παρουσία αντικειμενοστραφών χαρακτηριστικών σχεδιασμού που επιτρέπουν σε ένα σχεδιασμό να επαναλαμβάνεται σε ένα νέο πρόβλημα χωρίς σημαντική προσπάθεια Flexibility Χαρακτηριστικά που επιτρέπουν την ενσωμάτωση αλλαγών σε ένα σχεδιασμό. Η ικανότητα ενός σχεδιασμού που πρέπει να προσαρμόζεται για να παρέχει λειτουργικά σχετικές ικανότητες. Understandability Οι ιδιότητες του σχεδιασμού που επιτρέπουν εύκολα να μάθουν και να κατανούν. Αυτό σχετίζεται άμεσα με την πολυπλοκότητα της δομής του σχεδιασμού. Functionality Οι ευθύνες αποδίδονται στις κλάσεις ενός σχεδιασμού, οι οποίες διατίθενται από τις κλάσεις μέσω των δημοσίων διασυνδέσεων τους. Extendibility Αναφέρεται στην παρουσία και τη χρήση των ιδιοτήτων σε έναν υπάρχοντα σχεδιασμό, που επιτρέπουν την ενσωμάτωση νέων απαιτήσεων στο σχεδιασμό. Effectiveness Αναφέρεται στην ικανότητα ενός σχεδιασμού να πετύχει την Σελίδα 22 από 84

επιθυμητή λειτουργικότητα και τη συμπεριφορά χρησιμοποιώντας αντικειμενοστραφή έννοιες και τεχνικές του σχεδιασμού. 1.3.1.2 Προσδιορισμός των ιδιοτήτων Αντικειμενοστρεφούς Σχεδιασμού ( ) Οι ιδιότητες σχεδιασμού είναι αντιληπτές και μπορούν άμεσα να αξιολογηθούν εξετάζοντας την εσωτερική και εξωτερική δομή, τις σχέσεις, την λειτουργικότητα των συστατικών σχεδιασμού, των χαρακτηριστικών, των μεθόδων και των κλάσεων. Η εκτίμηση του ορισμού κλάσης για τις εξωτερικές σχέσεις (τύπος κληρονομικότητας) με τις άλλες κλάσεις και η εξέταση των εσωτερικών συστατικών, χαρακτηριστικών και μεθόδων του, αποκαλύπτει σημαντικές πληροφορίες που αντικειμενικά περιγράφουν τα δομικά και λειτουργικά χαρακτηριστικά της κλάσης και των αντικειμένων της. Οι ιδιότητες σχεδιασμού της αφαίρεσης (abstraction), ενσωμάτωσης (encapsulation), σύζευξης (coupling), συνοχής (cohesion), πολυπλοκότητας (complexity), και του μεγέθους σχεδίου (design size) χρησιμοποιούνται ως ιδιότητες που αντιπροσωπεύουν τα χαρακτηριστικά ποιότητας σχεδιασμού σε δομημένο και αντικειμενοστρεφές περιβάλλον. Η μετάδοση των μηνυμάτων (messaging), η σύνθεση (aggregation), η κληρονομικότητα(inheritance), ο πολυμορφισμός (polymorphism) καθώς και οι ιεραρχίες των κλάσεων (hierarchies) αντιπροσωπεύουν νέες σχεδιαστικές έννοιες που παρουσιάζονται στο αντικειμενοστρεφές μοντέλο και είναι ζωτικής σημασίας για την ποιότητα και τον αντικειμενοστρεφή σχεδιασμό. Η αρχική έκδοση του QMOOD περιλαμβάνει και τα δύο σύνολα των ιδιοτήτων όπως ορίζονται στον Πίνακα 2. Πίνακας 2- Ορισμοί Ιδιοτήτων Σχεδιασμού Ιδιότητες Σχεδιασμού Design Size Ορισμός Ένα μέτρο για τον αριθμό των κλάσεων που συμμετέχουν στο σχεδιασμού. Σελίδα 23 από 84

Hierarchies Οι ιεραρχίες χρησιμοποιούνται για να αντιπροσωπεύουν διαφορετικές γενικευμένες - εξειδικευμένες έννοιες σε ένα σχεδιασμό. Είναι μία μέτρηση του αριθμού των μηκληρονομούντων κλάσεων που έχουν παιδιά σε ένα σχεδιασμό. Abstraction Ένα μέτρο για την γενικευμένη-εξειδικευμένη πτυχή του σχεδιασμού. Οι κλάσεις του σχεδιασμού που έχουν έναν ή περισσότερους απογόνους εμφανίζουν αυτή την ιδιότητα της αφαίρεσης. Encapsulation Oρίζεται ως η πλαστικοποιήση των δεδομένων και η συμπεριφορά σε ένα ενιαίο κατασκεύασμα.στον αντικειμενοστρεφή σχεδιασμό η ιδιότητα αναφέρεται συγκεκριμένα στο σχεδιασμό των κλάσεων που εμποδίζει την πρόσβαση στις δηλώσεις των χαρακτηριστικών ορίζοντας τους να είναι ιδιωτικά, προστατεύοντας έτσι την εσωτερική αναπαράσταση των αντικειμένων. Coupling Kαθορίζει την αλληλεξάρτηση ενός αντικειμένου με άλλα αντικείμενα σε ένα σχεδιασμό.είναι ένα μέτρο για τον αριθμό των άλλων αντικειμένων που θα πρέπει να είναι προσβάσιμα από ένα άλλο αντικείμενο προκειμένου το εν λόγω αντικείμενο να λειτουργήσει σωστά. Cohesion Αξιολογεί την συνάφεια των μεθόδων και των ιδιοτήτων σε μια κλάση. Ισχυρή επικάλυψη των παραμέτρων της μεθόδου και των τύπων του χαρακτηριστικού σε μια ένδειξη ισχυρής συνοχής. Composition Mετρά τις «μέρος-του", "έχει", "αποτελείται από", ή "μέρος-όλο» σχέσεις, οι οποίες είναι οι σχέσεις συνάθροισης σε ένα αντικειμενοστραφή σχεδιασμό. Inheritance Ένα μέτρο της "is a" σχέση μεταξύ των κλάσεων. Αυτή η σχέση σχετίζεται με το επίπεδο ένθεσης των κλάσεων σε μια ιεραρχία κληρονομικότητας. Polymorphism Η ικανότητα να αντικαταστήσει τα αντικείμενα των οποίων οι διασυνδέσεις τους ταιριάζουν σε ένα άλλο κατά το χρόνο εκτέλεσης. Είναι ένα μέτρο των υπηρεσιών που καθορίζεται δυναμικά κατά το χρόνο εκτέλεσης σε ένα αντικείμενο. Messaging Μία μέτρηση του αριθμού των δημόσιων μεθόδων που είναι Σελίδα 24 από 84

Complexity διαθέσιμες ως υπηρεσίες σε άλλες κλάσεις. Αυτό είναι ένα μέτρο των υπηρεσιών που παρέχει μία κλάση. Ένα μέτρο του βαθμού δυσκολίας στην κατανόηση της εσωτερικής και εξωτερικής δομής των κλάσεων και των σχέσεων. 1.3.1.3 Προσδιορισμός των Μετρικών Αντικειμενοστρεφούς Σχεδιασμού( ) Όλες οι ιδιότητες που προσδιορίζονται στο μοντέλο QMOOD αντιπροσωπεύουν μια ιδιότητα ή ένα χαρακτηριστικό σχεδιασμού που ορίζεται χρησιμοποιώντας καλά ορισμένες μετρικές κατά τη διάρκεια της φάσης σχεδίασης. Για τον αντικειμενοστρεφή σχεδιασμό, αυτή η πληροφορία θα πρέπει να περιλαμβάνει τον ορισμό των κλάσεων, τις ιεραρχίες των κλάσεων, και τις δηλώσεις των μελών των κλάσεων. Οι έρευνες για τις ήδη υπάρχουσες μετρικές αποκαλύπτουν ότι, υπάρχουν πολλές μετρικές που μπορούν να διαμορφωθούν και να χρησιμοποιηθούν στην αξιολόγηση μερικών ιδιοτήτων σχεδιασμού, όπως η αφαίρεση, η κληρονομικότητα και η ανταλλαγή μηνυμάτων. Ωστόσο, υπάρχουν πολλές άλλες ιδιότητες σχεδιασμού, όπως είναι η ενσωμάτωση και η σύνθεση, για τις οποίες δεν υπάρχουν αντικειμενοστρεφείς μετρικές. Ακόμη, ενώ οι μετρικές για την αξιολόγηση της πολυπλοκότητας, της συνοχής και της σύζευξης έχουν ήδη οριστεί, αυτές οι μετρικές απαιτούν σχεδόν ολοκληρωμένη υλοποίηση κλάσεων πριν μπορέσουν να υπολογιστούν, και γι αυτό δεν μπορούν να χρησιμοποιηθούν στο QMOOD. Αυτό οδηγεί στον προσδιορισμό πέντε νέων μετρικών, μετρική πρόσβασης δεδομένων (Data Access Metric (DAM)), Μετρική άμεσης σύζευξης (direct class coupling metric (DCC)), μετρική συνοχής μεταξύ μεθόδων μιας κλάσης (cohesion among methods of class metric (CAM)), μετρική μέτρησης της συσσώρευσης (measure of aggregation metric (MOA)), και η μετρική μέτρησης της λειτουργικής αφαίρεσης (measure of functional abstraction metric MFA), και μπορούν να υπολογιστούν από τις πληροφορίες σχεδιασμού μόνο. Το σύνολο αυτών των μετρικών που χρησιμοποιείται στο QMOOD περιγράφεται στον Πίνακα 3. Σελίδα 25 από 84

Πίνακας 3- Περιγραφή Μετρικών Σχεδιασμού Μετρικές Όνομα Περιγραφή DSC Design Size in Classes Είναι μια μετρική που μετράει τον συνολικό αριθμό των κλάσεων στον σχεδιασμό. NOH Number of Hierarchies Είναι μια μετρική που μετράει τον αριθμό των ιεραρχιών μιας κλάσης στον σχεδιασμό. ANA Average Number Αυτή η μετρική τιμή υποδηλώνει το μέσο αριθμό των of Ancestors κλάσεων από τις οποίες μια κλάση κληρονομεί πληροφορίες. Υπολογίζεται με τον προσδιορισμό του αριθμού των κλάσεων κατά μήκος όλων των διαδρομών από την κλάση(εις) ρίζα σε όλες τις κλάσεις, σε μια δομή κληρονομικότητας. DAM Data Access Αυτή η μετρική είναι ο λόγος του αριθμού των ιδιωτικών Metric (προστατευμένων) χαρακτηριστικών για το συνολικό αριθμό των χαρακτηριστικών που δηλώθηκαν στην κλάση. Μια υψηλή τιμή για DAM είναι επιθυμητή.(0,1) DCC Direct Class Coupling Είναι μια μετρική που μετράει τους διαφορετικούς αριθμούς των κλάσεων που είναι άμεσα συνδεδεμένη με μια κλάση. Περιλαμβάνει κλάσεις που σχετίζονται άμεσα με τις δηλώσεις των χαρακτηριστικών και περνώντας το μήνυμα στις μεθόδους. CAM Cohesion Among Η μετρική υπολογίζει την σχετικότητα μεταξύ των μεθόδων Methods of Class μιας κλάσης η οποία βασίζεται στον κατάλογο παραμέτρων των μεθόδων. Η μετρική υπολογίζεται χρησιμοποιώντας το άθροισμα της τομής των παραμέτρων μιας μεθόδου με το μέγιστο ανεξάρτητο σύνολο όλων των τύπων παραμέτρων στην κλάση. Μια μετρική τιμή προτιμάται κοντά στο 1. (0,1) MOA Measure of Aggregation Αυτή η μετρική μέτρα την έκταση της «part-whole» σχέσης, πραγματοποιώντας την με τη χρήση των ιδιοτήτων. Υπολογίζει τον αριθμό των δηλωμένων δεδομένων των οποίων οι τύποι τους που ορίζονται από τον χρήστη στις κλάσεις. Σελίδα 26 από 84

MFA NOP CIS NOM Measure of Functional Abstraction Number of Polymorphic Methods Class Interface Size Number of Methods Αυτή η μετρική είναι ο λόγος του αριθμού των μεθόδων που κληρονομούνται από μια κλάση με τον συνολικό αριθμό των μεθόδων ποτ είναι προσβάσιμες από μεθόδους μέλη της κλάσης.(0,1) Είναι μια μετρική που μετράει τον αριθμό των μεθόδων που μπορούν να παρουσιάζουν πολυμορφική συμπεριφορά. Τέτοιες μέθοδοι στην C++ λέγονται virtual. Αυτή η μετρική μετράει τον αριθμό των δημόσιων μεθόδων σε μια κλάση. Αυτή η μετρική μετράει όλες τις μεθόδους που υπάρχουν σε μια κλάση. 1.3.1.4 Προσδιορισμός Συστατικών Αντικειμενοστρεφούς Σχεδιασμού( ) Τα συστατικά σχεδιασμού που είναι αναγνωρίσιμα και προσδιορίζουν την αρχιτεκτονική της αντικειμενοστρεφής σχεδίασης είναι τα αντικείμενα, οι κλάσεις καθώς και οι σχέσεις που έχουν μεταξύ τους. Τα αντικείμενα ενσωματώνουν τις δομές δεδομένων που αντιπροσωπεύουν τις ιδιότητες της κλάσης. Ένα σύνολο από λειτουργίες (μέθοδοι) που ορίζονται στις κλάσεις μπορούν να διαχειριστούν τα δεδομένα που είναι ενσωματωμένα στο αντικείμενο. Η ποιότητα του αντικειμένου καθορίζεται από τα συστατικά του, δηλαδή ιδιότητες, μεθόδους, και άλλα αντικείμενα (σύνθεση). Άλλο συστατικό που μπορεί να προσδιοριστεί είναι οι γενικές-ειδικές δομές ή οι ιεραρχίες των κλάσεων που οργανώνουν τις κλάσεις που σχετίζονται. Επιπλέον ένα σύνολο συστατικών που μπορεί να βοηθήσει στην ανάλυση, υλοποίηση και αναπαράσταση ενός αντικειμενοστρεφούς σχεδιασμού πρέπει να περιλαμβάνει ιδιότητες, μεθόδους, αντικείμενα (κλάσεις), σχέσεις και ιεραρχίες κλάσεων. Γενικά, όλες οι γλώσσες αντικειμενοστρεφούς προγραμματισμού παρέχουν συντακτική δομή για τα θεμελιώδη συστατικά σχεδίασης. Από τη στιγμή που οι αντικειμενοστρεφείς γλώσσες προγραμματισμού (C++) χρησιμοποιούνται για την Σελίδα 27 από 84

σχεδίαστική αναπαράσταση, γι αυτό και η ποιότητα σχεδιασμού μπορεί εύκολα να πραγματοποιηθεί με την αξιολόγηση αυτών των αυτόματα ανιχνεύσιμων συστατικών. 1.3.1.4.1 Αναγνώριση Ιδιοτήτων Ποιότητας για κάθε Συστατικό Όταν φτάσουμε στο σύνολο των ιδιοτήτων ποιότητας για κάθε συστατικό σχεδίασης τότε αυτό θεωρείται ότι είναι μια εμπειρική διαδικασία. Η διαδικασία καθοδηγείται από ένα σύνολο ερωτήσεων, όπως: «Τι ρόλο παίζει το συστατικό στη σχεδίαση;», «Ποια είναι η σημασία των συστατικών στη σχεδίαση;», «Ποιες οι διαφορετικές μορφές που έχει το συστατικό;». Οι πληροφορίες αυτές είναι απαραίτητες για την αξιολόγηση των ιδιοτήτων και πρέπει να είναι διαθέσιμες κατά τη διάρκεια της φάσης σχεδιασμού. Επίσης πρέπει να υπάρχουν πολλές πληροφορίες στην αναπαράσταση των συστατικών για την αναγνώριση και την αξιολόγηση των ιδιοτήτων ποιότητας, με σαφή τρόπο. Τα χαρακτηριστικά είναι τα θεμελιώδη στοιχεία στον προσδιορισμό ενός αντικειμένου και η δήλωσή τους υποστηρίζεται άμεσα στις αντικειμενοστρεφείς γλώσσες προγραμματισμού. Το σύνολο των ιδιοτήτων επηρεάζουν άμεσα την ποιότητα ενός αντικειμένου, και επιπλέον την συνολική ποιότητα σχεδίασης και πρέπει να περιλαμβάνουν: όνομα, ενσωμάτωση, μέγεθος, τύπους, σχέσεις και δυνατότητα απαρίθμησης. Οι δηλώσεις μεθόδων επίσης υποστηρίζονται άμεσα στις γλώσσες προγραμματισμού. Οι ιδιότητες των μεθόδων επηρεάζουν την ποιότητα μιας κλάσης είτε άμεσα είτε έμμεσα, γι αυτό και οι δηλώσεις πρέπει να περιλαμβάνουν: όνομα, ενσωμάτωση, τύπους παραμέτρων, μηχανισμούς περάσματος παραμέτρων, αριθμό παραμέτρων και ανάλυση. Οι κλάσεις στις αντικειμενοστρεφείς γλώσσες περιγράφονται με τη συντακτική δομή για να είναι εύκολα αναγνωρίσιμες. Το σύνολο ιδιοτήτων που μπορεί να επηρεάσουν τη συνολική ποιότητα σχεδιασμού περιλαμβάνουν : όνομα, τύπους κληρονομικότητας και ενσωμάτωσης, αριθμός των γονέων, αριθμός των παιδιών, βάθος κληρονομικότητας, μέγεθος κλάσης, αριθμό μεθόδων και ιδιοτήτων, αριθμό εσωτερικών λειτουργιών, σύζευξη και συνοχή. Σελίδα 28 από 84

1.3.1.5 Σύνδεση των Ιδιοτήτων Ποιότητας με τις Ιδιότητες Σχεδιασμού ( ) Οι ιδιότητες ποιότητας αντικειμένων ταξινομούνται με βάση τις ιδιότητες σχεδιασμού που επηρεάζουν. Έτσι παρόλο που το σύνολο των ιδιοτήτων ποιότητας των θεμελιωδών συστατικών (ιδιότητες, μέθοδοι και κλάσεις) είναι μεγάλο, είναι και ιδιαίτερα επικαλυπτόμενο. Για παράδειγμα, οι ιδιότητες, οι μέθοδοι και τα συστατικά της κλάσης έχουν ένα όνομα που αναφέρονται στις ιδιότητες ποιότητας. Όταν το όνομα είναι αυτό-περιγραφικό βοηθά στην καλύτερη κατανόηση και κατά συνέπεια επηρεάζει και την πολυπλοκότητα του σχεδιασμού. Οι ιδιότητες ποιότητας όπως είναι η ενθυλάκωση, αναγνωρίζεται για τις ιδιότητες, μεθόδους, και κλάσεις, και είναι ίδια με την γενική ιδιότητα ενθυλάκωσης. Παρόμοια, οι υπόλοιπες ιδιότητες ποιότητας που έχουν μείνει και προσδιορίζονται για τις ιδιότητες, μεθόδους και κλάσεις μπορούν να ομαδοποιηθούν σε ένα μικρότερο σύνολο έντεκα θεμελιωδών ιδιοτήτων που περιγράφονται στον Πίνακα 2. 1.3.1.6 Εφαρμογή Μετρικών Σχεδιασμού στις Ιδιότητες Σχεδιασμού ( ) Οι μετρικές Design Size in Classes (DSC) και Number of Hierarchies (NOH) χρησιμοποιούνται για την αξιολόγηση των δύο ιδιοτήτων σχεδιασμού Design Size και Hierarchies στο QMOOD. Η αφαίρεση αναφέρεται στην γενική-ειδική δομή του σχεδιασμού και αξιολογείται από τη μετρική Average Number of Ancestors (ANA). Ο ορισμός της ιδιότητας ενθυλάκωσης στον Πίνακα 2 αναφέρει την πρόσβαση ελέγχου του χαρακτηριστικού των δηλώσεων στην κλάση η οποία αντικατοπτρίζεται στην περιγραφή της μετρικής Data Access Metric (DAM). Η μετρική Direct Class Coupling (DCC) είναι μια μέτρηση των κλάσεων που απευθείας σχετίζονται με την κλάση και επιπλέον χρησιμοποιείται για την αξιολόγηση της Σύζευξης μιας ιδιότητας σχεδιασμού. Oι μετρικές Cohesion among method of class (CAM), Measure of Aggregation (MOA), και Class Interface Size χρησιμοποιούνται για την μέτρηση των ιδιοτήτων Cohesion, Aggregation και Messaging. Η κληρονομικότητα αναφέρεται στον βαθμό της επαναχρησιμοποίησης της λειτουργικότητας (μπορεί να μετρηθεί από την μετρική Measure of Functional Abstraction, MFA ) και μπορεί να επιτευχθεί με την δημιουργία των υποκλάσεων της Σελίδα 29 από 84

υπάρχουσας κλάσης και κατά συνέπεια η μετρική MFA χρησιμοποιήθηκε για να μετρήσει την ιδιότητα της κληρονομικότητας στο QMOOD. Για τον αντικειμενοστρεφή σχεδιασμό που παρουσιάζεται στο συντακτικό της γλώσσας C++, η ιδιότητα σχεδιασμού Πολυμορφισμός είναι η μέτρηση των Εικονικών μεθόδων μιας κλάσης και αξιολογείται από την μετρική Number of Polymorphic Methods(NOP). Η μετρική Αριθμός των Μεθόδων (Number of Methods NOC) χρησιμοποιήθηκε για να μετρήσει την πολυπλοκότητα της κλάσης από τους Chidamber και Kemerer στην μετρική Weighted Methods Per Class (WMC). Όταν όλες οι μέθοδοι είναι εξίσου σταθμισμένες, η μετρική WMC έχει ίδια μέτρηση με την Number of Methods NOM στην κλάση. Ο Πίνακας 4 συνοψίζει τις μετρικές σχεδιασμού που χρησιμοποιούνται για να αξιολογήσουν τις έντεκα ιδιότητες σχεδιασμού του Πίνακα 3. Πινακας 4 - Μετρικές Σχεδιασμού για τις Ιδιότητες Σχεδιασμού Ιδιότητες Σχεδιασμού Design Size Hierarchies Abstraction Encapsulation Coupling Cohesion Composition Inheritance Polymorphism Messaging Complexity Μετρικές Σχεδιασμού Design Size in Classes (DSC) Number of Hierarchies (NOH) Average Number of Ancestors (ANA) Data Access Metric (DAM) Direct Class Coupling (DCC) Cohesion Among Methods of Class (CAM) Measure of Aggregation (MOA) Measure of Functional Abstraction (MFA) Number of Polymorphic Methods (NOP) Class Interface Size (CIS) Number of Methods (NOM) Σελίδα 30 από 84

1.3.1.7 Σύνδεση Ιδιοτήτων Σχεδιασμού με τα Χαρακτηριστικά Ποιότητας ( ) Υπάρχουν διάφορες απόψεις για το πως οι ιδιότητες σχεδιασμού μπορούν να επηρεάσουν την ποιότητα σχεδίασης γι αυτό το λόγο πραγματοποιήθηκε μια εκτενή ανασκόπηση δημοσιεύσεων και βιβλίων αντικειμενοστρεφούς ανάπτυξης. Οι πληροφορίες από αυτήν την ανασκόπηση δείχνουν ότι η ιδιότητα αφαίρεσης έχει σημαντική επιρροή στα παρακάτω χαρακτηριστικά ποιότητας σχεδιασμού: ευελιξία (flexibility), αποτελεσματικότητα (effectiveness), λειτουργικότητα (functionality), και επεκτασιμότητα (extendibility). Η ενθυλάκωση (encapsulation) θεωρήθηκε κατάλληλη για την ευελιξία (flexibility), την επαναχρησιμοποίηση (reusability) και την ικανότητα κατανόησης (understandability). Ενώ η χαμηλή σύζευξη (coupling) θεωρήθηκε κατάλληλη για την επεκτασιμότητα(extendibility), την ικανότητα κατανόησης (understandability) και την επαναχρησιμοποίηση (reusability). Οι υψηλότερες τιμές της σύζευξης επηρεάζουν αρνητικά αυτά τα ποιοτικά χαρακτηριστικά. Η συνοχή (Cohesion) βλέπουμε ότι έχει σημαντική επιρροή στην επαναχρησιμοποίηση και στην ικανότητα κατανόησης του σχεδιασμού. Τα αντικείμενα επικοινωνούν με την ανταλλαγή μηνυμάτων και επιπλέον η απευθείας μετάδοση μηνυμάτων επηρεάζει την λειτουργικότητα και την αποτελεσματικότητα και βοηθά στην προώθηση της επαναχρησιμοποίησης. Ενώ η χρήση της κληρονομικότητας προωθεί την εσωτερική επαναχρησιμοποίηση, την λειτουργικότητα, την επεκτασιμότητα και την αποτελεσματικότητα, έχει την δυνατότητα να επηρεάσει αρνητικά την ευελιξία και την ικανότητα κατανόησης. Ομοίως, ενώ η προσεκτική χρήση της σύνθεσης αντικειμένων μπορεί σημαντικά να αυξήσει την εσωτερική επαναχρησιμοποίηση, την λειτουργικότητα και την ευελιξία, η υπερβολική και η λανθασμένη χρήση της μπορεί να κάνει τον σχεδιασμό δύσκολο στην κατανόηση. Η χρήση της σύνθεση μπορεί επίσης να επηρεάσει την αποτελεσματικότητα και την επεκτασιμότητα. Ενώ η χρήση του πολυμορφισμού μπορεί να αυξήσει τις ιδιότητες σχεδιασμού όπως ευελιξία, επεκτασιμότητα, αποτελεσματικότητα και λειτουργικότητα, μπορεί επίσης να κάνει τον Σελίδα 31 από 84

σχεδιασμό δύσκολο στην κατανόηση. Η πολυπλοκότητα (complexity) είναι ένας δείκτης της κατανόησης του σχεδιασμού. Γενικά, όσο πιο πολύπλοκος είναι ο σχεδιασμός, τόσο πιο δύσκολη είναι η κατανόησή του. Ο Πίνακας 5 δείχνει την επιρροή της κάθε ιδιότητας σχεδιασμού στα χαρακτηριστικά της ποιότητας. Το βέλος προς τα πάνω ( ) δείχνει ότι η ιδιότητα σχεδιασμού έχει θετική επιρροή στα χαρακτηριστικά ποιότητας. Πίνακας 5- Σχέσεις Ιδιοτήτων Σχεδιασμού Reusability Flexibility Understandability Functionality Extendibility Effectiveness Design Size Hierarchies Abstraction Encapsulation Coupling Cohesion Composition Inheritance Polymorphism Messaging Complexity Απόδοση Βαρύτητας στη Συσχέτιση Σχεδιαστικών Ιδιοτήτων και Ποιότητας Η σημαντικότητα της συσχέτισης για τις μεμονωμένες ιδιότητες σχεδιασμού που επηρεάζουν τα χαρακτηριστικά ποιότητας (Πίνακας 5), σταθμίζεται αναλογικά έτσι ώστε οι υπολογίσιμες τιμές όλων των χαρακτηριστικών ποιότητας να έχουν το ίδιο εύρος. Το εύρος από το 0 μέχρι το ±1 επιλέχθηκε για να υπολογίσει τις τιμές των χαρακτηριστικών ποιότητας. Οι αρχικές τιμές ανάθεσης βαρών ήταν +1 ή +0.5 και χρησιμοποιήθηκαν για την θετικές επιρροές, ενώ η τιμή -1 ή -0.5 για τις αρνητικές Σελίδα 32 από 84

επιρροές. Όμως οι τιμές αυτές άλλαξαν για να εξασφαλιστεί ότι στο άθροισμα των νέων τιμών όλων των ιδιοτήτων σχεδιασμού που επηρεάζουν τα χαρακτηριστικά ποιότητας προστέθηκε το ±1. Τα αποτελέσματα φαίνονται στον Πίνακα 6. Επιλέχθηκε γιατί ήταν απλό και εύκολο στην εφαρμογή. Πίνακας 6 Ορισμοί Χαρακτηριστικών Ποιότητας Χαρακτηριστικά Ποιότητας Reusability Υπολογισμός Εξίσωσης -0.25 * Coupling + 0.25 * Cohesion + 0.5 * Messaging + 0.5 Design Size Flexibility 0.25 * Encapsulation 0.25 * Coupling + 0.5 * Composition + 0.5 * Polymorphism Understandability -0.33 * Abstraction + 0.33 * Encapsulation 0.33 * Coupling + 0.33 * Cohesion 0.33 * Polymorphism 0.33 * Complexity 0.33 * Design Size Functionality 0.12 * Cohesion + 0.22 * Polymorphism + 0.22 * Messaging + 0.22 * Design Size + 0.22 * Hierarchies Extendability 0.5 * Abstraction 0.5 * Coupling + 0.5 * Inheritance + 0.5 * Polymorphism Effectiveness 0.2 * Abstraction + 0.2 * Encapsulation + 0.2 * Composition + 0.2 * Inheritance + 0.2 * Polymorphism 1.3.1.8 Βελτίωση και Προσαρμογή του Μοντέλου Το μοντέλο ποιότητας QMOOD επιτρέπει να γίνονται εύκολα αλλαγές έτσι ώστε να προσαρμόζεται σε διαφορετικές αναθέσεις βαρών, καινούριους σκοπούς και στόχους. Στο χαμηλό επίπεδο, οι μετρικές που χρησιμοποιούνται για την αξιολόγηση των ιδιοτήτων σχεδιασμού μπορεί να αλλάξουν, ή ακόμη ένα σύνολο ιδιοτήτων σχεδιασμού μπορεί να χρησιμοποιηθεί για την αξιολόγηση χαρακτηριστικών ποιότητας, επίσης και το σύνολο των χαρακτηριστικών ποιότητας μπορεί επίσης να υποστεί αλλαγές. Οι σχέσεις επιρροής που υπάρχουν στις ιδιότητες σχεδιασμού και στα χαρακτηριστικά ποιότητας, καθώς και οι αναθέσεις βαρών ενδέχεται να αλλάξουν προκειμένου να ανταποκρίνονται στους στόχους και στην πολιτική του κάθε οργανισμού. Σελίδα 33 από 84

1.4 Σκοπός Διπλωματικής Στο [4] οι συγγραφείς πρότειναν μία μεθοδολογία η οποία είναι σε θέση να αποσπάσει κανόνες που μπορούν να χρησιμοποιηθούν σαν ενδείξεις όταν η εφαρμογή ενός προτύπου σχεδίασης είναι επωφελής όσον αφορά την ποιότητα του λογισμικού και όταν δεν είναι. Αρχικά, παρατηρείται ότι οι περιπτώσεις προτύπων σχεδίασης δεν μοιράζονται τα ίδια χαρακτηριστικά, π.χ. αριθμό προτύπων που συμμετέχουν στις κλάσεις, τόσο μεταξύ προτύπων όσο και το λογισμικό σε διάφορους τομείς [1]. Μελετώντας τη βιβλιογραφία, προτείνονται ότι υπάρχουν αρκετές σχεδιαστικές λύσεις που μπορούν να υποκαταστήσουν τη λειτουργικότητα που προσφέρει ένα πρότυπο σχεδίασης, το οποίο μπορεί να χρησιμοποιηθεί όταν τα πρότυπα σχεδίασης δεν είναι επωφελής σε σχέση με την δομική ποιότητα του λογισμικού. Εκτός από αυτό, οι συγγραφείς του [4] παρατήρησαν ότι υπάρχουν ορισμένα πρότυπα σχεδίασης με δομικά χαρακτηριστικά που συσχετίζονται με διάφορες ιδιότητες της ποιότητας. Για παράδειγμα, χρησιμοποιώντας το πρότυπο σχεδίασης Bridge, βελτιώνει την πολυμορφική συμπεριφορά ενός συστήματος, ενώ αυξάνει το μέγεθος του συστήματος [2]. Τέλος, σε ορισμένες περιπτώσεις, η έκταση του προαναφερθέντος αποτελέσματος σχετίζεται με τον αριθμό των κλάσεων που συμμετέχουν στο πρότυπο. Λαμβάνοντας υπόψη όλα τα παραπάνω, στο [4] οι συγγραφείς ήταν σε θέση να δημιουργήσουν μαθηματικές συναρτήσεις που υπολογίζουν τα αποτελέσματα των μετρικών λύσεων των προτύπων σχεδίασης και εναλλακτικές σχεδιαστικές λύσεις, όπως εξισώσεις του αριθμού των κλάσεων που συμμετέχουν σε ένα στιγμιότυπο πρότυπο σχεδίασης. Τα αποτελέσματα των τριών επεξηγηματικών παραδειγμάτων πρότειναν ότι ο αριθμός των κλάσεων που συμμετέχουν σε ένα στιγμιότυπο πρότυπο σχεδίασης είναι ένα αντικειμενικό κριτήριο που μπορεί να χρησιμοποιηθεί για την επιλογή μεταξύ της εφαρμογής ενός προτύπου σχεδίασης ή όχι. Στη συνέχεια, θα παρέχουμε τα αποτελέσματα από την εφαρμογή της προαναφερθείσας μεθοδολογίας σε τρία γνωστά πρότυπα σχεδίασης, δηλαδή στο Decorator, Template Method και Strategy. Η σουίτα των μετρικών που θα χρησιμοποιηθεί είναι η ίδια με αυτή που προτείνεται στο [4], δηλαδή QMOOD [5]. Στο [5], οι συγγραφείς προτείνουν ένα Σελίδα 34 από 84

ιεραρχικό μοντέλο ποιότητας που στοχεύει στην ποσοτικοποίηση έξι χαρακτηριστικά ποιότητας του σχεδιασμού από μετρήσεις σε object-oriented σχεδιασμό κατασκευαστικών στοιχείων. Τα χαρακτηριστικά ποιότητας του σχεδιασμού που εμπλέκονται στο μοντέλο είναι η επαναχρησιμοποίηση (reusability), η ευελιξία (flexibility), η κατανόηση (understandability), η λειτουργικότητα (functionality), η επεκτασιμότητα (extendibility) και η αποτελεσματικότητα (effectiveness). Οι ακριβείς ορισμοί των έξι ποιοτικών χαρακτηριστικών του σχεδιασμού μπορούν να βρεθούν στο [5]. Οι ιδιότητες του object-oriented σχεδιασμολυ που χρησιμοποιούνται στο μοντέλο είναι design size, hierarchies, abstractions, encapsulation, coupling, cohesion, composition, inheritance, polymorphism, messaging και complexity [5]. Για κάθε πρότυπο σχεδίασης, θα παρουσιάσουμε δύο λύσεις υπό σύγκριση, ένα με τον πρότυπο σχεδίασης και ένα χωρίς το πρότυπο, με τη μορφή ενός διαγράμματος κλάσεων και μια περιγραφή κειμένου. Θα παρουσιάσουμε τις εξισώσεις για κάθε αποτέλεσμα μετρικής και για τις δύο λύσεις και τελικά, κάποια διαγράμματα που παρουσιάζουν την πραγματική σύγκριση των λύσεων. Οι πλήρεις υπολογισμοί των μετρικών έχουν παραλειφθεί από το κείμενο αυτό, προκειμένου να βελτιωθεί η αναγνωσιμότητα του, αλλά ο ενδιαφερόμενος χρήστης μπορεί να έχει πρόσβαση σε απευθείας σύνδεση για τους. 1.5 Μεθοδολογία Η προτεινόμενη μεθοδολογία μπορεί να χρησιμοποιηθεί για τη σύγκριση προτύπων σχεδίασης και λειτουργικά ισοδύναμων σχεδιαστικών λύσεων, κατά την επέκταση του συστήματος. Η μέθοδος αναλύεται στα παρακάτω βήματα: Προϋπόθεση: Έστω ότι υπάρχει ένα σχεδιαστικό πρόβλημα που μπορεί να επιλυθεί με κάποιο πρότυπο. Καταγράψτε εναλλακτικές σχεδιαστικές λύσεις από τη βιβλιογραφία, το ανοιχτό λογισμικό και τις προσωπικές σας εμπειρίες Εντοπίστε τους κύριους άξονες αλλαγών του σχεδίου Επεκτείνετε το σχέδιο σε όλους τους άξονες. Για παράδειγμα, αν υπάρχουν δύο άξονες αλλαγών, επεκτείνετε ως προς τον πρώτο, προσθέτοντας (n) Σελίδα 35 από 84

λειτουργίες και ως προς τον δεύτερο προσθέτοντας (m) επιπρόσθετες λειτουργίες Επιλέξτε ένα μοντέλο ποιότητας λογισμικού που ταιριάζει στις ανάγκες σχεδίασης και στο πλαίσιο ανάπτυξης του λογισμικού. Εναλλακτικά μπορεί απλά να επιλεγεί και ένα σύνολο μετρικών Κατασκευάστε εξισώσεις για τα συστατικά του μοντέλου ποιότητας, ως συνάρτηση των λειτουργιών (n, m) που προστέθηκαν στο βήμα 3 Συγκρίνετε τις συναρτήσεις που προέκυψαν στο βήμα 5 σε ζευγάρια και εντοπίστε την πιο συμφέρουσα σχεδιαστική επιλογή ως προς κάθε χαρακτηριστικό ποιότητας που ορίστηκε στο βήμα 4, καθώς και τους περιορισμούς που προκύπτουν Τα βασικά σημεία υπεροχής της μεθόδου ως προς τις έως τώρα ερευνητικές προσεγγίσεις στην αξιολόγηση των προτύπων σχεδίασης είναι τα εξής: Η χρήση της αναλυτικής μεθόδου έναντι των εμπειρικών. Το κύριο όφελος είναι ότι για την εφαρμογή της μεθόδου δεν χρειάζονται πολλαπλές περιπτώσεις/στιγμιότυπα για κάθε πρότυπο, εφόσον τα ποιοτικά χαρακτηριστικά οποιουδήποτε στιγμιοτύπου μπορούν να υπολογιστούν μέσω των εξισώσεων Η συγκεκριμένη μεθοδολογία μπορεί να υπολογίσει διάφορα δομικά χαρακτηριστικά ποιότητας και να διαχειριστεί τις «συναλλαγές» μεταξύ των ποιοτικών χαρακτηριστικών Μελέτη της επίδρασης των προτύπων σχεδίασης σε μια πληθώρα χαρακτηριστικών και όχι μόνο ως προς ένα χαρακτηριστικό ποιότητας Η εύρεση των οριακών σημείων (όποτε αυτά υπάρχουν), τα οποία όταν ξεπεραστούν, το πρότυπο σχεδίασης ή η σχεδιαστική εναλλακτική γίνεται πιο συμφέρουσα επιλογή Τα (3) και (4), μπορούν να χρησιμοποιηθούν στη βασισμένη σε στόχους διοίκηση έργου λογισμικού (goal oriented software project management), δηλαδή ο σχεδιαστής μπορεί να επιλέξει μεταξύ προτύπου και εναλλακτικής με βάση τις απαιτήσεις του συστήματος καθώς και ως προς τα επιθυμητά χαρακτηριστικά ποιότητας Σελίδα 36 από 84

Μια εναλλακτική πρόταση για την επίτευξη του ίδιου στόχου, θα ήταν ο σχεδιαστής να δουλεύει την αξιολόγηση στο επίπεδο του στιγμιοτύπου και όχι του μοντέλου. Μια τέτοια προσέγγιση είναι αρκετά πιο εύκολη για τους κατασκευαστές λογισμικού, αλλά έχει αρκετά μειονεκτήματα ως προς την αναλυτική μεθοδολογία. Κάνοντας χρήση της αναλυτικής μεθοδολογίας και αξιολογώντας σε επίπεδο μοντέλου, οι υπό εξέταση σχεδιαστικές λύσεις μπορούν να συγκριθούν σε μεγαλύτερο πλήθος σεναρίων επέκτασης και οι σχεδιαστικές αποφάσεις μπορούν να ληφθούν με μεγαλύτερη ασφάλεια, σε πρώιμο στάδιο σχεδίασης. 2. Εφαρμογή Μεθοδολογίας Ως ενδεικτικά παραδείγματα χρήσης της μεθοδολογίας, διερευνήθηκαν τρια ερευνητικά ερωτήματα, σχετικά με την αξιολόγηση διαφόρων προτύπων σχεδίασης, ως προς διάφορα χαρακτηριστικά ποιότητας. Τα ερευνητικά ερωτήματα που μελετήθηκαν είναι: RQ1: Ποια είναι η επίδραση της χρήσης του προτύπου σχεδίασης Decorator στη ποιότητα σχεδίου ενός συστήματος; RQ2: Ποια είναι η επίδραση της χρήσης του προτύπου σχεδίασης Template Method στη ποιότητα σχεδίου ενός συστήματος; RQ3: Ποια είναι η επίδραση της χρήσης του προτύπου σχεδίασης Strategy στη ποιότητα σχεδίου ενός συστήματος; Τα πρότυπα σχεδίασης θα μελετηθούν στη γενική τους μορφή, ρόλοι κλάσεων αντί για ονόματα κλάσεων, έτσι ώστε να είναι εμφανές ότι τα αποτελέσματα είναι γενικεύσιμα σε οποιαδήποτε περίπτωση χρήσης του προτύπου σχεδίασης. Παρόμοια, έχουν ονομαστεί οι μέθοδοι και οι κλάσεις του εναλλακτικού σχεδίου, ώστε να υπάρχει εύκολη αντιστοίχηση με το πρότυπο. Το γεγονός ότι όλα τα παραδείγματα σχετίζονται με τα GoF πρότυπα σχεδίασης, δεν πρέπει να παρερμηνευθεί ως έλλειψη γενικότητας. Η μεθοδολογία μπορεί να εφαρμοστεί σε οποιαδήποτε μορφή προτύπου, όπως τα αρχιτεκτονικά πρότυπα (architectural patterns) [9]. Σελίδα 37 από 84

Τα πρότυπα που επελέγησαν για τα ενδεικτικά παραδείγματα, καλύπτουν όλες τις κατηγορίες προτύπων που παρουσιάζονται στο [10]. Τα πρότυπα εμφανίζονται στην τυπική τους μορφή. Στη βιβλιογραφία εμφανίζονται αρκετές παρεκκλίσεις από το αρχικό πρότυπο. Όμως, τέτοιες περιπτώσεις δεν έχουν μελετηθεί, διότι το πλήθος των εναλλακτικών σχεδίων είναι μεγάλο και η διερεύνηση όλων των πιθανών συνδυασμών είναι πρακτικά αδύνατη. Έτσι, αποφασίστηκε να εξαχθούν ισοδύναμες σχεδιαστικά λύσεις από κώδικα ανοιχτού λογισμικού, παρά να προστεθεί στη μελέτη μια ακόμη βιβλιογραφική λύση, ώστε να αυξηθεί ο ρεαλισμός της προσέγγισης. Σε αυτό το σημείο θα πρέπει να σημειωθεί ότι η ανάλυση και τα αποτελέσματα βασίζονται στις συγκεκριμένες εναλλακτικές σχεδιαστικές επιλογές και δεν μπορούν να γενικευθούν σε άλλες σχεδιαστικές λύσεις, είτε από τη βιβλιογραφία είτε από το ανοιχτό λογισμικό. Η επέκταση των συστημάτων έχει γίνει σύμφωνα με το [8] όπου οι συγγραφείς προτείνουν ότι υπάρχουν τρεις βασικοί άξονες αλλαγών στα πρότυπα σχεδίασης: (α) προσθήκη νέων κλάσεων ως υποκλάσεις (concrete participant), (β) τροποποίηση υπάρχουσας διασύνδεσης και (γ) προσθήκη νέου πελάτη (client). Στη μελέτη προτείνεται ότι ο πιο συχνός τρόπος συντήρησης ενός προτύπου είναι η προσθήκη υποκλάσεων, δηλαδή το (α). Έτσι, στα σενάρια επέκτασης της μεθοδολογίας προτιμήθηκε τα σχέδια λογισμικού να συντηρηθούν προσθέτοντας υποκλάσεις. Η επιλογή αξόνων αλλαγής από την πλευρά του προτύπου σχεδίασης προσφέρει ομοιόμορφη επιλογή στρατηγικής επέκτασης. Σε περίπτωση που ο άξονας αλλαγής επιλεγόταν από κάποια εναλλακτική σχεδίαση (είτε βιβλιογραφική, είτε ανοιχτού λογισμικού), δε θα ήταν δυνατή η δημιουργία κανόνων ως προς την ομοιόμορφη επέκταση σε όλα τα πρότυπα σχεδίασης. Σε περίπτωση που η μεθοδολογία εφαρμοστεί σε ήδη υπάρχουσες κλάσεις που επαναχρησιμοποιούνται ή συμπεριλαμβάνονται σε στιγμιότυπα προτύπων σχεδίασης, θεωρείται ότι η επίδραση τους στην ποιότητα θα είναι ομοιόμορφη σε όλες τις πιθανές σχεδιαστικές επιλογές. Επιπλέον, επιλέχθηκε να παρουσιαστούν διαχωρισμένα παραδείγματα για κάθε πρότυπο σχεδίασης και όχι ένα σύστημα που να περιλαμβάνει περισσότερα πρότυπα, λόγω των αδιευκρίνιστων συνεπειών της σύζευξης μεταξύ προτύπων σχεδίασης [13]. Η μέθοδος σύγκρισης δυο σχεδιαστικών Σελίδα 38 από 84

λύσεων είναι η επίλυση της ανίσωσης, που προκύπτει αφαιρώντας τις εξισώσεις που υπολογίζουν την τιμή μιας μετρικής για τις λύσεις αυτές με το μηδέν. Για την επίλυση των παραγόμενων ανισοτήτων, χρησιμοποιήθηκε το πακέτο Wolfram Mathematica που εφαρμόζει τον αλγόριθμο Reduce1 για την επίλυση ανισώσεων. Στο σημείο αυτό πρέπει να επισημανθεί ότι τα επιλεγμένα μοντέλα ποιότητας και τα σύνολα μετρικών είναι ενδεικτικά. Έτσι, κάθε ομάδα ανάπτυξης λογισμικού μπορεί να εφαρμόσει τη μέθοδο κάνοντας χρήση οποιουδήποτε μοντέλου ποιότητας ή συνόλου μετρικών. 2.1 Πρότυπο Σχεδίασης «Decorator» Στη συγκεκριμένη ενότητα διερευνάται η συντηρησιμότητα του προτύπου σχεδίασης Decorator. Η παράγραφος 2.1.1 παρουσιάζει τη δομή του προτύπου και των δύο εναλλακτικών σχεδιαστικών λύσεων. Η παράγραφος 2.1.2 παρουσιάζει τα αποτελέσματα της μεθοδολογίας. 2.1.1 Σχεδιαστικές Προσεγγίσεις Το διάγραμμα κλάσεων ττου προτύπου σχεδίασης παρουσιάζεται στο Σχήμα 5. Το διάγραμμα κλάσεων του alternative προτύπου σχεδίασης παρουσιάζεται στο Σχήμα 6. 1 Wolfram Mathematica, Reduce Wolfram Mathematica 7 Documentation, http://reference.wolfram.com/mathematica /ref/reduce.html Σελίδα 39 από 84

Σχήμα 5: Διάγραμμα Κλάσεων Λύση «Πρότυπο Σχεδίασης» Σχήμα 6: Διάγραμμα Κλάσεων Λύση «Alternative Πρότυπο Σχεδίασης» Σελίδα 40 από 84

Θεωρείται ότι το σύστημα στη γενική μορφή έχει (n) Leaf κλάσεις, (p) ConcreteDecoratorA1 κλάσεις, (q) ConcreteDecoratorB1 κλάσεις και κάθε κλάση (m) operation μεθοδους. Το σύστημα στην alternative μορφή έχει (n) Leaf κλάσεις, στην κλάση Decorator σε κάθε operation μέθοδο (p) if statements και κάθε κλάση (m) operation μεθοδους. Η διαφορά μεταξύ της κλάσης ConcreteDecoratorA1 με την ConcreteDecoratorB1 είναι ότι η ConcreteDecoratorB1 αποτελείται μόνο από operation μεθόδους ενώ η ConcreteDecoratorA1 εκτός από operation μεθόδους περιλαμβάνει και additionaloperationa1 μεθόδους. 2.1.2 Αποτελέσματα Λαμβάνοντας υπόψη τον ορισμό των δυο αξόνων επέκτασης και των μετρικών που θα μελετηθούν, δημιουργήθηκαν οι παρακάτω συναρτήσεις: Πρότυπο Σχεδίασης Οι κλάσεις Client, Decorator και Component έχουν την τιμή 1. Οι κλάσεις Leaf=1*n, τα ConcreDecoratorA1=1*p και τα ConcreDecoratorΒ1=1*q. Οι κλάσεις Component και Decorator έχουν την τιμή 1 (NOH=1) γιατί κληρονομούνται από άλλες κλάσεις. Οι κλάσεις Client, Leaf, ConcreDecoratorA1 και ConcreDecoratorΒ1 δεν κληρονομούνται από άλλες κλάσεις (NOH=0). Οι κλάσεις Client και Component δεν ορίζονται (MFA=Δ/Ο). Η κλάση Leaf κληρονομεί όλες τις μεθόδους από την κλάση Component, οπότε (MFA=0). Ομοίως και η κλάση Decorator (MFA=0). Η κλάση ConcreDecoratorA1 δεν κληρονομεί δύο μεθόδους από την κλάση Decorator, την addparts(c) και την removeparts(c) (MFA= ). Η κλάση ConcreDecoratorB1 δεν κληρονομεί δύο μεθόδους από την κλάση Decorator, την addparts(c) και την removeparts(c) (MFA= ). Σελίδα 41 από 84

Η κλάση Client έχει αντικείμενο τύπου Component, άρα (DCC=1). Η κλάση Component είναι abstract κλάση και δεν καλεί κανένα αντικείμενο άλλης κλάσης, άρα (DCC=0). Η κλάση Decorator έχει αντικείμενο τύπου Component, άρα (DCC=1). ). Η κλάση Leaf κληρονομεί την Component, άρα (DCC=1*n). Η κλάση ConcreDecoratorA1 κληρονομεί την Decorator, άρα (DCC=1*p) και η κλάση ConcreDecoratorB1 κληρονομεί την Decorator, άρα (DCC=1*q). Οι κλάσεις Client, Component, Leaf, ConcreDecoratorA1, ConcreDecoratorB1 δεν έχουν στις μεθόδους τους καμία παράμετρο (CAM=0). Η κλάση Decorator έχει στις μεθόδους addparts και removeparts από μια παράμετρο (CAM= ). Η κλάση Client έχει αντικείμενο τύπου Component, άρα (MOA=1). Οι κλάσεις Component, Leaf, ConcreDecoratorA1, ConcreDecoratorB1 δεν έχουν κανένα αντικείμενο άλλης κλάσης, άρα (MOA=0). Η κλάση Decorator έχει αντικείμενο τύπου Component, άρα (MOA=1). Οι κλάσεις Client, Leaf, ConcreDecoratorA1, ConcreDecoratorB1 δεν έχουν μεθόδους που έχουν πολυμορφική συμπεριφορά (NOP=0). Η κλάση Component έχει όλες τις operation μεθόδους ως abstract (NOP=m). Η κλάση Decorator έχει όλες τις operation μεθόδους ως abstract (NOP=m). Σελίδα 42 από 84

Η κλάση Client και Component δεν κληρονομούν πληροφορίες από καμία άλλη κλάση (ANA=0). Η κλάση Decorator κληρονομεί την Component (ANA=1). H κλάση Leaf κληρονομεί την Component (ANA=1*n). H κλάση ConcreDecoratorA1 κληρονομεί την Decorator (ANA=1*p). H κλάση ConcreDecoratorB1 κληρονομεί την Decorator (ANA=1*q). Οι κλάσεις Client, Decorator έχουν από μια private μεταβλητή (DAM=1). Οι κλάσεις Component, Leaf, ConcreDecoratorA1, ConcreDecoratorB1 δεν έχουν καμία private μεταβλητή (DAM=0). Οι κλάσεις Client, Component έχουν m μεθόδους (NOM=m). Η κλάση Decorator έχει m+2 μεθόδους (NOM=m+2). Η κλάση Leaf έχει m μεθόδους (NOM=m*n). Η κλάση ConcreDecoratorA1 έχει 2*m μεθόδους (NOM=2*m*p). Η κλάση ConcreDecoratorB1 έχει m μεθόδους (NOM=m*q). Οι κλάσεις Client, Component έχουν m public μεθόδους (CIS=m). Η κλάση Decorator έχει m+2 public μεθόδους (CIS=m+2). Η κλάση Leaf έχει m public μεθόδους (CIS=m*n). Η κλάση ConcreDecoratorA1 έχει 2*m public μεθόδους (CIS=2*m*p). Η κλάση ConcreDecoratorB1 έχει m public μεθόδους (CIS=m*q). Εναλλακτική σχεδιαστική λύση προτύπου σχεδίασης Σελίδα 43 από 84

Leaf=1*n. Οι κλάσεις Client, Decorator και Component έχουν την τιμή 1. Η κλάση Η κλάση Component έχει την τιμή 1 (NOH=1) γιατί κληρονομείται από άλλες κλάσεις. Οι κλάσεις Client, Decorator, Leaf, δεν κληρονομούνται από άλλες κλάσεις (NOH=0). Οι κλάσεις Client και Component δεν ορίζονται (MFA=Δ/Ο). Οι κλάσεις Decorator, Leaf κληρονομούν όλες τις μεθόδους από την κλάση Component, οπότε (MFA=0). Η κλάση Client έχει αντικείμενο τύπου Component, άρα (DCC=1). Η κλάση Component είναι abstract κλάση και δεν καλεί κανένα αντικείμενο άλλης κλάσης, άρα (DCC=0). Η κλάση Decorator έχει n αντικείμενα τύπου Leaf καθώς και κληρονομεί την κλάση Component, άρα (DCC=n+1). Η κλάση Client δεν έχει στις μεθόδους της καμία παράμετρο (CAM=0). Οι κλάσεις Component, Leaf δεν ορίζονται (CAM=Δ/0) Η κλάση Decorator έχει στις μεθόδους addleaf1και removeleaf1 από μια παράμετρο (CAM= ). Η κλάση Client έχει αντικείμενο τύπου Component, άρα (MOA=1). Οι κλάσεις Component, Leaf δεν έχουν κανένα αντικείμενο άλλης κλάσης, άρα (MOA=0). Η κλάση Decorator έχει n αντικείμενα τύπου Leaf, άρα (MOA=n). Σελίδα 44 από 84

Οι κλάσεις Client, Decorator, Leaf δεν έχουν μεθόδους που έχουν πολυμορφική συμπεριφορά (NOP=0). Η κλάση Component έχει όλες τις operation μεθόδους ως abstract (NOP=m). Η κλάση Client και Component δεν κληρονομούν πληροφορίες από καμία άλλη κλάση (ANA=0). Η κλάση Decorator κληρονομεί την Component (ANA=1). H κλάση Leaf κληρονομεί την Component (ANA=1*n). Η κλάση Client έχει μια private μεταβλητή (DAM=1). Η κλάση Decorator έχει n+1 private μεταβλητές (DAM= ). Οι κλάσεις Component, Leaf δεν έχουν καμία private μεταβλητή (DAM=0). Οι κλάσεις Client, Component έχουν m μεθόδους (NOM=m). Η κλάση Decorator έχει 2*n+m+p*m μεθόδους (NOM=2*n+m+p*m). Η κλάση Leaf έχει m μεθόδους (NOM=m*n). Οι κλάσεις Client, Component έχουν m public μεθόδους (CIS=m). Η κλάση Decorator έχει 2*n+m+p*m public μεθόδους (CIS=2*n+m+p*m). Η κλάση Leaf έχει m public μεθόδους (CIS=m*n). Σελίδα 45 από 84

Στον Πίνακα 7, συνοψίζονται οι εξισώσεις υπολογισμού μετρικών για κάθε λύση. Πίνακας 7: Μετρικές Συντηρησιμότητας για τις Σχεδιαστικές Επιλογές Μετρικές Πρότυπο Σχεδίασης Εναλλακτικό Πρότυπο Σχεδίασης DSC NOH MFA DCC CAM MOA NOP ANA DAM NOM CIS Πίνακας 8: Μετρικές για τις Σχεδιαστικές Επιλογές Χαρακτηριστικά Ποιότητας Reusability Πρότυπο Σχεδίασης Flexibility Σελίδα 46 από 84

Understandabilit y Functionality Extendibility Effectiveness Πίνακας 9: Μετρικές για τις Σχεδιαστικές Επιλογές Χαρακτηριστικά Ποιότητας Reusability Εναλλακτικό Πρότυπο Σχεδίασης Flexibility Understandability Functionality Extendibility Effectiveness 2.2 Πρότυπο Σχεδίασης «Template Method» Στη συγκεκριμένη ενότητα διερευνάται η συντηρησιμότητα του προτύπου σχεδίασης Template Method. Η παράγραφος 2.2.1 παρουσιάζει τη δομή του προτύπου και των δύο εναλλακτικών σχεδιαστικών λύσεων. Η παράγραφος 2.2.2 παρουσιάζει τα αποτελέσματα της μεθοδολογίας. Σελίδα 47 από 84

2.2.1 Σχεδιαστικές Προσεγγίσεις Το διάγραμμα κλάσεων ττου προτύπου σχεδίασης παρουσιάζεται στο Σχήμα 7. Το διάγραμμα κλάσεων του alternative προτύπου σχεδίασης παρουσιάζεται στο Σχήμα 8. Σχήμα 7: Διάγραμμα Κλάσεων Λύση «Πρότυπο Σχεδίασης» Σελίδα 48 από 84

Σχήμα 8: Διάγραμμα Κλάσεων Λύση «Alternative Πρότυπο Σχεδίασης» Θεωρείται ότι το σύστημα στη γενική μορφή έχει (n) ConcreteClass κλάσεις. Οι κλάσεις AbstractClass και ConcreteClass περιέχουν (p) primitiveoperation μεθόδους. Οι κλάσεις TemplatePattern και AbstractClass περιέχουν (m) tempaltemethod μεθόδους. Στην AbstractClass σε κάθε tempaltemethod μέθοδο, υπάρχουν (q) primitiveoperation μέθοδοι. Το σύστημα στην alternative μορφή έχει (n) ConcreteClass κλάσεις. Όλες οι κλάσεις περιέχουν (m) tempaltemethod μεθόδους. Στις ConcreteClass κλάσεις, σε κάθε tempaltemethod μέθοδο, υπάρχουν (q) primitiveoperation μέθοδοι. Επίσης, στις ConcreteClass κλάσειςυπάρχουν (p) primitiveoperation μέθοδοι. 2.2.2 Αποτελέσματα Λαμβάνοντας υπόψη τον ορισμό των δυο αξόνων επέκτασης και των μετρικών που θα μελετηθούν, δημιουργήθηκαν οι παρακάτω συναρτήσεις: Πρότυπο Σχεδίασης Σελίδα 49 από 84

Οι κλάσεις TemplatePattern και AbstractClass έχουν την τιμή 1. Η κλάση ConcreteClass=1*n. Η κλάση και AbstractClass έχει την τιμή 1 (NOH=1) γιατί κληρονομείται από άλλες κλάσεις. Οι κλάσεις TemplatePattern και ConcreteClass δεν κληρονομούνται από άλλες κλάσεις (NOH=0). Οι κλάσεις TemplatePattern και AbstractClass δεν ορίζονται (MFA=Δ/Ο). Η κλάση ConcreteClass κληρονομεί μόνο τις primitiveoperation μεθόδους από την κλάση AbstractClass, οπότε (MFA= ). Η κλάση TemplatePattern έχει n αντικείμενα τύπου AbstractClass, άρα (DCC=1+n). Η κλάση AbstractClass είναι abstract κλάση και δεν καλεί κανένα αντικείμενο άλλης κλάσης, άρα (DCC=0). Η κλάση ConcreteClass κληρονομεί την AbstractClass, άρα (DCC=1*n). (CAM=Δ/Ο). Οι κλάσεις TemplatePattern, AbstractClass και ConcreteClass δεν ορίζονται Η κλάση TemplatePattern έχει αντικείμενο τύπου AbstractClass, άρα (MOA=1). Οι κλάσεις AbstractClass και ConcreteClass δεν έχουν κανένα αντικείμενο άλλης κλάσης, άρα (MOA=0). Σελίδα 50 από 84

Οι κλάσεις TemplatePattern και ConcreteClass δεν έχουν μεθόδους που έχουν πολυμορφική συμπεριφορά (NOP=0). Η κλάση AbstractClass έχει όλες τις primitiveoperation μεθόδους ως abstract (NOP=p). Η κλάση TemplatePattern και AbstractClass δεν κληρονομούν πληροφορίες από καμία άλλη κλάση (ANA=0). Η κλάση ConcreteClass κληρονομεί την AbstractClass (ANA=1*n). Η κλάση TemplatePattern έχει μια private μεταβλητή (DAM=1). Οι κλάσεις AbstractClass και ConcreteClass δεν έχουν καμία private μεταβλητή (DAM=Δ/Ο). Η κλάση TemplatePattern έχει μια μέθοδο (NOM=1). Η κλάση AbstractClass έχει m+p μεθόδους (NOM=m+p). Η κλάση ConcreteClass έχει p μεθόδους (NOM=p*n). Η κλάση TemplatePattern έχει μια public μέθοδο (CIS=1). Η κλάση AbstractClass έχει m+p public μεθόδους (CIS=m+p). Η κλάση ConcreteClass έχει p public μεθόδους (CIS=p*n). Σελίδα 51 από 84

Εναλλακτική σχεδιαστική λύση προτύπου σχεδίασης Η κλάση TemplateAlternative έχει την τιμή 1. Η κλάση ConcreteClass=1*n. Οι κλάσεις TemplateAlternative και ConcreteClass δεν κληρονομούνται από άλλες κλάσεις (NOH=0). Οι κλάσεις TemplateAlternative και ConcreteClass δεν ορίζονται (MFA=Δ/Ο). Η κλάση TemplateAlternative έχει n αντικείμενα τύπου ConcreteClass, άρα (DCC=n). Η κλάση ConcreteClass δεν καλεί κανένα αντικείμενο άλλης κλάσης, άρα (DCC=0). Οι κλάσεις TemplateAlternative και ConcreteClass δεν ορίζονται (CAM=Δ/Ο). Η κλάση TemplateAlternative έχει n αντικείμενα τύπου ConcreteClass, άρα (MOA=n). Η κλάση ConcreteClass δεν έχει κανένα αντικείμενο άλλης κλάσης, άρα (MOA=0). Οι κλάσεις TemplateAlternative και ConcreteClass δεν έχουν μεθόδους που έχουν πολυμορφική συμπεριφορά (NOP=0). Η κλάση TemplateAlternative και ConcreteClass δεν κληρονομούν πληροφορίες από καμία άλλη κλάση (ANA=0). Σελίδα 52 από 84

Η κλάση TemplateAlternative έχει n private μεταβλητές (DAM= ). Η κλάση ConcreteClass δεν έχei καμία private μεταβλητή (DAM=Δ/Ο). Η κλάση TemplateAlternative έχει μια μέθοδο (NOM=1). Η κλάση ConcreteClass έχει (m+p) μεθόδους (NOM=(m+p)*n). Η κλάση TemplateAlternative έχει ConcreteClass έχει (m+p) public μεθόδους (CIS=(m+p) *n). μια public μέθοδο (CIS=1). Η κλάση Στον Πίνακα 10, συνοψίζονται οι εξισώσεις υπολογισμού μετρικών για κάθε λύση. Πίνακας 10: Μετρικές Συντηρησιμότητας για τις Σχεδιαστικές Επιλογές Μετρικές Πρότυπο Σχεδίασης Εναλλακτικό Πρότυπο Σχεδίασης DSC NOH MFA DCC CAM MOA Σελίδα 53 από 84

NOP ANA DAM NOM CIS Πίνακας 11: Μετρικές για τις Σχεδιαστικές Επιλογές Χαρακτηριστικά Ποιότητας Reusability Πρότυπο Σχεδίασης Flexibility Understandability Functionality Extendibility Effectiveness Πίνακας 12: Μετρικές για τις Σχεδιαστικές Επιλογές Χαρακτηριστικά Ποιότητας Reusability Εναλλακτικό Πρότυπο Σχεδίασης Flexibility Understandability Functionality Extendibility Effectiveness Σελίδα 54 από 84

2.3 Πρότυπο Σχεδίασης «Strategy» Στη συγκεκριμένη ενότητα διερευνάται η συντηρησιμότητα του προτύπου σχεδίασης Strategy. Η παράγραφος 2.3.1 παρουσιάζει τη δομή του προτύπου και των δύο εναλλακτικών σχεδιαστικών λύσεων. Η παράγραφος 2.3.2 παρουσιάζει τα αποτελέσματα της μεθοδολογίας. 2.3.1 Σχεδιαστικές Προσεγγίσεις Το διάγραμμα κλάσεων ττου προτύπου σχεδίασης παρουσιάζεται στο Σχήμα 9. Το διάγραμμα κλάσεων του alternative προτύπου σχεδίασης παρουσιάζεται στο Σχήμα 10. Σχήμα 9: Διάγραμμα Κλάσεων Λύση «Πρότυπο Σχεδίασης» Σελίδα 55 από 84

Σχήμα 10: Διάγραμμα Κλάσεων Λύση «Alternative Πρότυπο Σχεδίασης» Θεωρείται ότι το σύστημα στη γενική μορφή έχει (n) ConcreteStrategy κλάσεις. Όλες οι κλάσεις περιέχουν (m) dooperation μεθόδους. Οι κλάσεις StrategyPattern και Strategy περιέχουν (q) dooperationsame μεθόδους. Το σύστημα στην alternative μορφή έχει (n) ConcreteStrategy κλάσεις. Όλες οι κλάσεις περιέχουν (m) dooperation μεθόδους και (q) dooperationsame μεθόδους. Η μέθοδος dooperationsame είναι μία μέθοδος που παντού κάνει τα ίδια ακριβώς σε αντίθεση με την μέθοδο dooperation όπου κάθε μέθοδος κάνει κάτι διαφορετικό από την άλλη. 2.2.2 Αποτελέσματα Λαμβάνοντας υπόψη τον ορισμό των δυο αξόνων επέκτασης και των μετρικών που θα μελετηθούν, δημιουργήθηκαν οι παρακάτω συναρτήσεις: Πρότυπο Σχεδίασης Οι κλάσεις StrategyPattern και Strategy έχουν την τιμή 1. Η κλάση ConcreteStrategy=1*n. Σελίδα 56 από 84

Η κλάση και Strategy έχει την τιμή 1 (NOH=1) γιατί κληρονομείται από άλλες κλάσεις. Οι κλάσεις StrategyPattern και ConcreteStrategy δεν κληρονομούνται από άλλες κλάσεις (NOH=0). Οι κλάσεις StrategyPattern και Strategy δεν ορίζονται (MFA=Δ/Ο). Η κλάση ConcreteStrategy κληρονομεί μόνο τις dooperation μεθόδους από την κλάση Strategy, οπότε (MFA= ). Η κλάση StrategyPattern έχει n αντικείμενα τύπου Strategy, άρα (DCC=1+n). Η κλάση Strategy είναι abstract κλάση και δεν καλεί κανένα αντικείμενο άλλης κλάσης, άρα (DCC=0). Η κλάση ConcreteStrategy κληρονομεί την Strategy, άρα (DCC=1*n). (CAM=Δ/Ο). Οι κλάσεις StrategyPattern, Strategy και ConcreteStrategy δεν ορίζονται Η κλάση StrategyPattern έχει αντικείμενο τύπου Strategy, άρα (MOA=1). Οι κλάσεις Strategy και ConcreteStrategy δεν έχουν κανένα αντικείμενο άλλης κλάσης, άρα (MOA=0). Οι κλάσεις StrategyPattern και ConcreteStrategy δεν έχουν μεθόδους που έχουν πολυμορφική συμπεριφορά (NOP=0). Η κλάση Strategy έχει όλες τις dooperation μεθόδους ως abstract (NOP=m). Σελίδα 57 από 84

Η κλάση StrategyPattern και Strategy δεν κληρονομούν πληροφορίες από καμία άλλη κλάση (ANA=0). Η κλάση ConcreteStrategy κληρονομεί την Strategy (ANA=1*n). Η κλάση StrategyPattern έχει μια private μεταβλητή (DAM=1). Οι κλάσεις Strategy και ConcreteStrategy δεν έχουν καμία private μεταβλητή (DAM=Δ/Ο). Η κλάση StrategyPattern έχει μια μέθοδο (NOM=1). Η κλάση Strategy έχει m+q μεθόδους (NOM=m+q). Η κλάση ConcreteStrategy έχει m μεθόδους (NOM=m*n). Η κλάση StrategyPattern έχει μια public μέθοδο (CIS=1). Η κλάση Strategy έχει m+q public μεθόδους (CIS=m+q). Η κλάση ConcreteStrategy έχει m public μεθόδους (CIS=m*n). Εναλλακτική σχεδιαστική λύση προτύπου σχεδίασης Η κλάση StrategyAlternative έχει την τιμή 1. Η κλάση ConcreteStrategy =1*n. Οι κλάσεις StrategyAlternative και ConcreteStrategy δεν κληρονομούνται από άλλες κλάσεις (NOH=0). Σελίδα 58 από 84

Οι κλάσεις StrategyAlternative και ConcreteStrategy δεν ορίζονται (MFA=Δ/Ο). Η κλάση StrategyAlternative έχει n αντικείμενα τύπου ConcreteStrategy, άρα (DCC=n). Η κλάση ConcreteStrategy δεν καλεί κανένα αντικείμενο άλλης κλάσης, άρα (DCC=0). Οι κλάσεις StrategyAlternative και ConcreteStrategy δεν ορίζονται (CAM=Δ/Ο). Η κλάση StrategyAlternative έχει n αντικείμενα τύπου ConcreteStrategy, άρα (MOA=n). Η κλάση ConcreteStrategy δεν έχει κανένα αντικείμενο άλλης κλάσης, άρα (MOA=0). Οι κλάσεις StrategyAlternative και ConcreteStrategy δεν έχουν μεθόδους που έχουν πολυμορφική συμπεριφορά (NOP=0). Η κλάση StrategyAlternative και ConcreteStrategy δεν κληρονομούν πληροφορίες από καμία άλλη κλάση (ANA=0). Η κλάση StrategyAlternative έχει n private μεταβλητές (DAM= ). Η κλάση ConcreteStrategy δεν έχei καμία private μεταβλητή (DAM=Δ/Ο). Σελίδα 59 από 84

Η κλάση StrategyAlternative έχει μια μέθοδο (NOM=1). Η κλάση ConcreteStrategy έχει (m+q) μεθόδους (NOM=(m+q)*n). Η κλάση StrategyAlternative έχει μια public μέθοδο (CIS=1). Η κλάση ConcreteStrategy έχει (m+q) public μεθόδους (CIS=(m+q) *n). Στον Πίνακα 13, συνοψίζονται οι εξισώσεις υπολογισμού μετρικών για κάθε λύση. Πίνακας 13: Μετρικές Συντηρησιμότητας για τις Σχεδιαστικές Επιλογές Μετρικές Πρότυπο Σχεδίασης Εναλλακτικό Πρότυπο Σχεδίασης DSC NOH MFA DCC CAM MOA NOP ANA DAM NOM CIS Σελίδα 60 από 84

Πίνακας 14: Μετρικές για τις Σχεδιαστικές Επιλογές Χαρακτηριστικά Ποιότητας Reusability Πρότυπο Σχεδίασης Flexibility Understandability Functionality Extendibility Effectiveness Πίνακας 15: Μετρικές για τις Σχεδιαστικές Επιλογές Χαρακτηριστικά Ποιότητας Reusability Εναλλακτικό Πρότυπο Σχεδίασης Flexibility Understandability Functionality Extendibility Effectiveness 2.4 Συζήτηση Σε αυτό το κεφάλαιο παρουσιάζεται μια συζήτηση αναφορικά με το πώς θα μπορούσαν οι παραπάνω εξισώσεις να χρισιμοποιηθούν ώστε να παραχθούν κάποια χρήσιμα συμπεράσματα. Έτσι για κάθε διάγραμμα επιφανειών που αποδεικνύουν την ύπαρξη σημείων στα οποία η ποιότητα του προτύπου ισούται με την ποιότητα της εναλλακτικής σχεδιαστικά λύσης, με την φορά της ανίσωσης να αλλάζει εκατέρωθεν αυτών των σημείων. Σελίδα 61 από 84

2.4.1 Decorator Στην ενότητα 2.1.1 αναλύσαμε την έννοια της κάθε μεταβλητής (n, m, p, q) που συμμετέχει στις εξισώσεις υπολογισμού των μετρικών. Για να μπορέσουμε να παρουσιάσουμε τριδιαστατα/δισδιάστατα γραφήματα της καθε μετρικής συναρτήσει των μεταβλητών, υποχρεωθήκαμε να θέσαμε τιμές σε κάποιες μεταβλητές, ωστε στο διάγραμμα να αναπαριστώντε δύ ή τρεις μεταβλητές. Για την απεικόνιση των διαγραμμάτων, χρησιμοποιήθηκε το πακέτο Wolfram Mathematica και πιο συγκεκριμένα η συνάρτηση Plot3D/Plot2D για την δημιουργία διαγραμμάτων. 2.4.1.1 Περίπτωση p=q=1 Θεωρούμε ότι οι κλάσεις ConcreteDecoratorA1 και ConcreteDecoratorB1 εμφανίζονται μόνο μία φορά, αφού η μεταβλητή (p) δείχνει πόσες ConcreteDecoratorA1 κλάσεις έχει το σύστημα καθώς και η μεταβλητή (q) δείχνει πόσες ConcreteDecoratorB1 κλάσεις υπάρχουν στο σύστημα. 2.4.1.2 Περίπτωση p=m=1 Θεωρούμε ότι η ConcreteDecoratorA1 εμφανίζεται μόνο μία φορά, αφού η μεταβλητή (p) δείχνει πόσες ConcreteDecoratorA1 κλάσεις έχει το σύστημα. Καθώς και κάθε κλάση έχει μόνο μια μέθοδο operation, αφού η μεταβλητή (m) δείχνει πόσες operation μεθόδους έχουμε σε κάθε κλάση. 2.4.1.3 Περίπτωση p=1, n=9-q Θεωρούμε ότι η ConcreteDecoratorA1 εμφανίζεται μόνο μία φορά, αφού η μεταβλητή (p) δείχνει πόσες ConcreteDecoratorA1 κλάσεις έχει το σύστημα. Επίσης, σύμφωνα με το [1] ο συνολικός αριθμός των κλάσεων στο σύστημα είναι n+p+q=10. Επόμενως, ο αριθμός των Leaf κλάσεων είναι n=9-q, αφού η μεταβλητή (n) δείχνει πόσες Leaf κλάσεις υπάρχουν στο σύστημα. 2.4.1.4 Αποτελέσματα περιπτώσεων Σελίδα 62 από 84

Στον Πίνακα 16, παρουσιάζουμε τα διαγράμματα για κάθε περίπτωση. Το κόκκινο διάγραμμα αντιπροσωπεύει το πρότυπο σχεδίασης και το μπλέ διάγραμμα το εναλλακτικό πρότυπο σχεδίασης. Πίνακας 16: Διαγράμματα περιπτώσεων Χαρακτηριστικά Ποιότητας Reusability p=q=1 p=m=1 p=1, n=9-q Flexibility Understandability Functionality Σελίδα 63 από 84

Extendibility Effectiveness 2.4.2 Template Method Στην ενότητα 2.2.1 αναλύσαμε την έννοια της κάθε μεταβλητής (n, m, p, q) που συμμετέχει στις εξισώσεις υπολογισμού των μετρικών. Για να μπορέσουμε να παρουσιάσουμε τριδιαστατα/δισδιάστατα γραφήματα της καθε μετρικής συναρτήσει των μεταβλητών, υποχρεωθήκαμε να θέσαμε τιμές σε κάποιες μεταβλητές, ωστε στο διάγραμμα να αναπαριστώντε δύ ή τρεις μεταβλητές. Για την απεικόνιση των διαγραμμάτων, χρησιμοποιήθηκε το πακέτο Wolfram Mathematica και πιο συγκεκριμένα η συνάρτηση Plot3D/Plot2D για την δημιουργία διαγραμμάτων.. 2.4.2.1 Περίπτωση p=1 Θεωρούμε ότι η μέθοδος primitiveoperation εμφανίζεται μόνο μία φορά, αφού η μεταβλητή (p) δείχνει πόσες primitiveoperation μεθόδους υπάρχουν στο σύστημα. 2.4.2.2 Περίπτωση m=1 Θεωρούμε ότι η μέθοδος tempaltemethod εμφανίζεται μόνο μία φορά, αφού η μεταβλητή (m) δείχνει πόσες tempaltemethod μεθόδους υπάρχουν στο σύστημα. Σελίδα 64 από 84

2.4.2.3 Περίπτωση p=3 Θεωρούμε ότι η μέθοδος primitiveoperation εμφανίζεται τρεις φορές, αφού η μεταβλητή (p) δείχνει πόσες primitiveoperation μεθόδους υπάρχουν στο σύστημα. 2.4.2.4 Περίπτωση p=5 Θεωρούμε ότι η μέθοδος primitiveoperation εμφανίζεται πέντε φορές, αφού η μεταβλητή (p) δείχνει πόσες primitiveoperation μεθόδους υπάρχουν στο σύστημα. 2.4.2.5 Αποτελέσματα περιπτώσεων Στον Πίνακα 17, παρουσιάζουμε τα διαγράμματα για κάθε περίπτωση. Το κόκκινο διάγραμμα αντιπροσωπεύει το πρότυπο σχεδίασης και το μπλέ διάγραμμα το εναλλακτικό πρότυπο σχεδίασης. Πίνακας 17: Διαγράμματα περιπτώσεων Χαρακτηριστικά Ποιότητας Reusability p=1 m=1 p=3 p=5 Flexibility Σελίδα 65 από 84

Understandability Functionality Extendibility Effectiveness Σελίδα 66 από 84

2.4.3 Strategy Στην ενότητα 2.3.1 αναλύσαμε την έννοια της κάθε μεταβλητής (n, m, p, q) που συμμετέχει στις εξισώσεις υπολογισμού των μετρικών. Για να μπορέσουμε να παρουσιάσουμε τριδιαστατα/δισδιάστατα γραφήματα της καθε μετρικής συναρτήσει των μεταβλητών, υποχρεωθήκαμε να θέσαμε τιμές σε κάποιες μεταβλητές, ωστε στο διάγραμμα να αναπαριστώντε δύ ή τρεις μεταβλητές. Για την απεικόνιση των διαγραμμάτων, χρησιμοποιήθηκε το πακέτο Wolfram Mathematica και πιο συγκεκριμένα η συνάρτηση Plot3D/Plot2D για την δημιουργία διαγραμμάτων. 2.4.3.1 Περίπτωση m=1 Θεωρούμε ότι η μέθοδος dooperation εμφανίζεται μόνο μία φορά, αφού η μεταβλητή (m) δείχνει πόσες dooperation μεθόδους υπάρχουν στο σύστημα. 2.4.3.2 Περίπτωση n=5 Σύμφωνα με το [1], ο συνολικός αριθμός των κλάσεων στο σύστημα είναι n+2=7. Επόμενως, ο αριθμός των ConcreteStrategy κλάσεων είναι n=5, αφού η μεταβλητή (n) δείχνει πόσες ConcreteStrategy κλάσεις υπάρχουν στο σύστημα 2.4.3.3 Περίπτωση q=0 Θεωρούμε ότι η μέθοδος dooperationsame δεν εμφανίζεται καθόλου, αφού η μεταβλητή (q) δείχνει πόσες dooperationsame μεθόδους υπάρχουν στο σύστημα. 2.4.3.4 Περίπτωση m=5 Θεωρούμε ότι η μέθοδος dooperation εμφανίζεται πέντε φορές, αφού η μεταβλητή (m) δείχνει πόσες dooperation μεθόδους υπάρχουν στο σύστημα. Σελίδα 67 από 84

2.4.3.5 Αποτελέσματα περιπτώσεων Στον Πίνακα 18, παρουσιάζουμε τα διαγράμματα για κάθε περίπτωση. Το κόκκινο διάγραμμα αντιπροσωπεύει το πρότυπο σχεδίασης και το μπλέ διάγραμμα το εναλλακτικό πρότυπο σχεδίασης. Πίνακας 18: Διαγράμματα περιπτώσεων Χαρακτηριστικά Ποιότητας Reusability m=1 n=5 q=0 m=5 Flexibility Understandability Functionality Σελίδα 68 από 84

Extendibility Effectiveness 3. Εμπειρική Μελέτη H έρευνα στoν τομέα της τεχνολογίαs λογισμικού, αφορά στην κατανόηση των μεθόδων που έχουμε στη διάθεσή μας, τα όριά τους και πότε μπορούν να εφαρμοστούν. Σύμφωνα με το [11], υπάρχουν τέσσερις μέθοδοι έρευνας στον τομέα της μηχανικής λογισμικού. Οι μέθοδοι είναι οι εξής: 1)επιστημονική μέθοδος (scientific method) 2)μηχανική μέθοδος (engineering method) 3)εμπειρική μέθοδος (empirical method) 4)αναλυτική μέθοδος (analytical method) Στην επιστημονική μέθοδο παρατηρείται το περιβάλλον και δημιουργείται ένα μοντέλο με βάση την παρατήρηση, για παράδειγμα, ένα μοντέλο προσομοίωσης. Στην μηχανική μέθοδο οι υπάρχουσες λύσεις μελετώνται και προτείνονται οι αλλαγές, οι οποίες στη συνέχεια αξιολογούνται. Στην εμπειρική μέθοδο προτείνεται ένα μοντέλο και στη συνέχεια αξιολογείται με εμπειρικές μελέτες, όπως για παράδειγμα, μελέτες περιπτώσεων ή πειράματα. Τέλος, στην αναλυτική μέθοδο προτείνεται μια επίσημη θεωρία, συλλέγονται εμπειρικές παρατηρήσεις και στη συνέχεια με βάση τις παρατηρήσεις συγκρίνεται η προς διερεύνηση θεωρία. Σελίδα 69 από 84

Η μηχανική μέθοδος και η εμπειρική μέθοδος μπορούν να θεωρηθούν ως παραλλαγές της επιστημονικής μεθόδου [6]. Κάθε μία από αυτές τις μεθόδους κρίνεται ως καταλληλότερη και εφαρμόζεται σε κάποιο συγκεκριμένο τομέα. Υπάρχουν τρεις μεγάλες ερευνητικές μέθοδοι που χρησιμοποιούνται στις εμπειρικές μελέτες οι οποίες είναι οι εξής: μελέτη περίπτωσης (case study). έρευνα πεδίου(survey), τυπικό ή ελεγχόμενο πείραμα (formal experiment). Η ενότητα αυτή, στοχεύει στην διερεύνηση της χρήσης αντικειμενοστραφών προτύπων σχεδίασης στα σφάλματα και στην αποτελεσματικότητα της αποσφαλμάτωσης έργων ανοιχτού λογισμικού. 3.1 Μεθοδολογία Ο στόχος αυτής της ενότητας είναι να αξιολογηθεί η ύπαρξη του προτύπου σχεδίασης, μέσω στιγμιοτύπων του που εμφανίζονται σε λογισμικό ανοιχτού κώδικα. Για την επιβεβαίωση της αναλυτικής μεθοδολογίας, αναμένεται τα αποτελέσματα της εμπειρικής μελέτης να δείχνουν ότι η χρήση του προτύπου είναι μερικές φορές επωφελής όσον αφορά την δομική ποιότητα του λογισμικού και σε άλλες περιπτώσεις δεν είναι. Τα βήματα που θα διεξαχθούν κατά τη διάρκεια της μελέτης περίπτωσής, αναφέρονται παρακάτω [12]: Καθορισμός ερωτήσεων έρευνας Επιλογή project και αντικέιμενα Αναγνώριση μεθόδου σύγκρισης Ανάλυση και αναφορά των αποτελεσμάτων 3.1.1 Καθορισμός ερωτήσεων έρευνας Σελίδα 70 από 84

Η μελέτη περίπτωσης που πραγματοποιήθηκε, αναμένεται να διερευνήσει την επίδραση της εφαρμογής του προτύπου, όπως περιγράφεται από τις ακόλουθες προϋποθέσεις και τα ερωτήματα της έρευνας. Προϋποθέσεις: μια έκδοση λογισμικού που δεν χρησιμοποιεί ένα πρότυπο σχεδίασης (μηπρότυπο) μια έκδοση λογισμικού που χρησιμοποιεί ένα πρότυπο σχεδίασης. Για κάθε, η είναι η βαθμολογία της μετρικής Για κάθε, η είναι η βαθμολογία της μετρικής Για κάθε, είναι η σχεδιαστική λύση (με πρότυπο ή χωρίς πρότυπο) η οποία θα έχει την καλύτερη βαμθολογία της μεταξύ και. Ερωτήσεις έρευνας: : Για κάθε, ποια είναι η συχνότερη πιθανή λύση; : Για κάθε, υπάρχει στατιστικά σημαντική διαφορά μεταξύ των μετρικών και ; 3.1.2 Επιλογή project και αντικέιμενα Για αυτή την περίπτωση μελέτης της έρευνας μας επιλέξαμε να διερευνήσουμε πέντε (5) παιχνίδια ανοικτού κώδικα και μηχανές παιχνιδιών. Για κάθε project λογισμικού, επιλέξαμε δυο διαδοχικές εκδόσεις. Τα επιλεγόμενα λογισμικά και οι αντίστοιχες εκδόσεις αναφέρονται παρακάτω: Board Games (εκδόσεις 1.0 και 2.0) Gemp Animator (εκδόσεις 1.0 και 1.1) Diabolically Uncrashable (εκδόσεις 0.3.0 και 0.4.0) Oware/Reversi Midlet (εκδόσεις 0.1.0 και 0.1.4) Σελίδα 71 από 84

Mini Pauker (εκδόσεις 0.3 και 1.1) Η γλώσσα προγραμματισμού όλων των έργων είναι σε Java, λόγω των περιορισμών του εργαλείου ανίχνευσης προτύπου [14]. Επιπλέον, το εγχειρίδιο ελέγχου του πηγαίου κώδικα και το διάγραμμα κλάσεων έχουν πραγματοποιηθεί ούτως ώστε να εκχυλισθεί το σύνολο των κλάσεων που εκτελούν μια καθορισμένη λειτουργικότητα και να επικυρώνει την ύπαρξη των προτύπων υποδεικνύοντας το από το εργαλείο ανίχνευσης. Ως εκ τούτου, το μέγεθος, δηλαδή ο αριθμός των κλάσεων (NOC), που συμμετείχαν στη μελέτη περίπτωσης ήταν κατά προτίμηση μικρό. 3.1.3 Αναγνώριση μεθόδου σύγκρισης Το εμπειρικό σύνολο δεδομένων που έχει χρησιμοποιηθεί στην έρευνα αποτελείται από γραμμές για κάθε πρότυπο που έχει προστεθεί σε μια έκδοση λογισμικού. Όλες οι κλάσεις που συμμετέχουν σε ένα πρότυπο σχεδίασης θεωρούνται ως ένα πακέτο,. Στην προηγούμενη έκδοση του λογισμικού (χωρίς πρότυπο), το σύνολο των κλάσεων που παρέχουν παρόμοιες λειτουργικές δυνατότητες θεωρούνται ως ένα πακέτο,. Και στα δύο πακέτα, οι βαθμολογίες των μετρικών υπολογίζονται ως οι μέσες τιμές των βαθμολογιών των κλάσεων του πακέτου. MSjP i NOC i 1 k NOC MSjC i NOC : Συνολικός αριθμός των κλάσεων που υπάρχουν στο πακέτο MS j C i : Τιμή του βαθμού της μετρικής j από την κλάση i MS j P k : Τιμή του βαθμού της μετρικής j από το πακέτο k Τύπος Προτύπου Για να διερευνηθούν τα ερωτήματα της έρευνας, πραγματοποιούμε περιγραφική στατιστική και ο έλεγχος των υποθέσεων έχουν πραγματοποιηθεί με Wilcoxon. Πιο συγκεκριμένα, η υπόθεση έχει επικυρωθεί από τους πίνακες Σελίδα 72 από 84

συχνότητας και τα ιστογράμματα. Από την άλλη πλευρά, η υπόθεση έχει επικυρωθεί με δοκιμές Wilcoxon Rank Sum για ζεύγη δειγμάτων, που ερευνά την ύπαρξη στατιστικά σημαντικών διαφορών μεταξύ των μέσων τιμών των δύο μεταβλητών, δηλαδή για μια ομάδα, δηλαδή τα πακέτα που παρέχουν καθορισμένη λειτουργικότητα. 3.1.4 Ανάλυση και αναφορά των αποτελεσμάτων Στην ενότητα αυτή, παρουσιάζουμε τα αποτελέσματα της εμπειρικής μελέτης. Για την υπόθεση, δημιουργήσαμε 3 αρχεία τύπου excel ώστε να καταχωρήσουμε ομαδοποιημένα τα 3 πρότυπα που ερευνούμε (Decorator, Template Method, Strategy). H κάθε γραμμή αντιπροσωπεύει ένα πρότυπο που βρήσκεται σε κάποιο από τα πέντε έργα ανοιχτού λογισμικού. Η κάθε στήλη αντιπροσωπεύει τον μέσο όρο των μετρικών από όλες τις κλάσεις που υπάρχουν σε ένα πρότυπο. Χρησιμοποιώντας έναν έλεγχο στο αρχείο μας, διαπιστώσαμε ποια είναι η καλύτερη σχεδιαστική λύση (με πρότυπο ή χωρίς πρότυπο) στις μετρικές υψηλού επιπέδου ώστε να βρεθεί ο. 3.1.4.1 Περιγραφική Στατιστική Αναφορικά με το πρότυπο Decorator, το πλήθος των στιγμιοτύπων όπου η καλύτερη σχεδιαστική λύση είναι το πρότυπο ή και το πλήθος των στιγμιοτύπων όπου η λύση χωρίς πρότυπο είναι καλύτερη, σε ότι αφορά τις μετρικές υψηλού επιπέδου, φαίνεται στο Σχήμα 11. Σελίδα 73 από 84

9 8 7 6 5 4 3 2 1 0 Pattern Alternative Tie Σχήμα 11: Πρότυπο Decorator Από το σχήμα παρατηρείται ότι η σχεδιαστική λύση με πρότυπο(pattern) είναι συχνότερα καλύτερη στην μετρική Effectiveness σε σχέση με την σχεδιαστική λύση χωρίς πρότυπο(alternative). Στις μετρικές Extendibility και Flexibility φαίνεται πως συχνότερα καλύτερη σχεδιαστική λύση είναι αυτή χωρίς πρότυπο. Στις μετρικές Reusability, Functionality και Understandability φαίνεται πως δεν υπάρχει μεγάλη διαφορά μεταξύ των δύο σχεδιαστικών λύσεων. Αναφορικά με το πρότυπο Template Method, το πλήθος των στιγμιοτύπων όπου η καλύτερη σχεδιαστική λύση είναι το πρότυπο ή και το πλήθος των στιγμιοτύπων όπου η λύση χωρίς πρότυπο είναι καλύτερη, σε ότι αφορά τις μετρικές υψηλού επιπέδου, φαίνεται στο Σχήμα 12. Σελίδα 74 από 84

18 16 14 12 10 8 6 4 2 0 Pattern Alternative Tie Σχήμα 12: Πρότυπο Template Method Από το σχήμα παρατηρείται ότι η σχεδιαστική λύση με πρότυπο(pattern) είναι συχνότερα καλύτερη σε όλες τις μετρικές υψηλού επιπέδου σε σχέση με την σχεδιαστική λύση χωρίς πρότυπο(alternative). Αναφορικά με το πρότυπο Strategy, το πλήθος των στιγμιοτύπων όπου η καλύτερη σχεδιαστική λύση είναι το πρότυπο ή και το πλήθος των στιγμιοτύπων όπου η λύση χωρίς πρότυπο είναι καλύτερη, σε ότι αφορά τις μετρικές υψηλού επιπέδου, φαίνεται στο Σχήμα 13. Σελίδα 75 από 84

35 30 25 20 15 10 5 0 Pattern Alternative Tie Σχήμα 13: Πρότυπο Strategy Από το σχήμα παρατηρείται ότι η σχεδιαστική λύση με πρότυπο(pattern) είναι συχνότερα καλύτερη στην μετρική Effectiveness σε σχέση με την σχεδιαστική λύση χωρίς πρότυπο(alternative). Στις μετρικές Reusability και Understandability φαίνεται πως συχνότερα καλύτερη σχεδιαστική λύση είναι αυτή χωρίς πρότυπο. Στις μετρικές Functionality, Extendibility και Flexibility φαίνεται πως δεν υπάρχει μεγάλη διαφορά μεταξύ των δύο σχεδιαστικών λύσεων 3.1.4.2 Έλεγχος Υποθέσεων Για την υπόθεση χρησιμοποιήσαμε το στατιστικό πακέτο SPSS και πιο συγκεκριμένα κάναμε paired sample T-test για να συγκρίνουμε εάν οι μετρικές της σχεδιαστικής λύσης με πρότυπο έχει στατιστικά σημαντική διαφορά με τις μετρικές της σχεδιαστικής λύσης χωρίς πρότυπο. Σελίδα 76 από 84