Α ΡΙΣΤΟΤΕΛΕΙΟ Π ΑΝΕΠΙΣΤΗΜΙΟ Θ ΕΣΣΑΛΟΝΙΚΗΣ ΣΧΟΛΗ ΘΕΤΙΚΩΝ ΕΠΙΣΤΗΜΩΝ ΤΜΗΜΑ ΠΛΗΡΟΦΟΡΙΚΗΣ Π ΤΥΧΙΑΚΗ Ε ΡΓΑΣΙΑ «ΕΡΓΑΛΕΙΟ ΔΙΑΧΕΙΡΙΣΗΣ ΑΝΤΙΠΡΟΤΥΠΩΝ ΛΟΓΙΣΜΙΚΟΥ» «ΠΑΠΑΔΟΠΟΥΛΟΥ ΙΩΑΝΝΑ» ΕΠΙΒΛΕΠΩΝ ΚΑΘΗΓΗΤΗΣ: ΣΤΑΜΕΛΟΣ ΙΩΑΝΝΗΣ, ΕΠΙΚΟΥΡΟΣ ΚΑΘΗΓΗΤΗΣ ΘΕΣΣΑΛΟΝΙΚΗ 2010
ΠΕΡΙΛΗΨΗ Π ΕΡΙΛΗΨΗ Αντικείμενο της παρούσας εργασίας είναι η χρήση της τεχνικής DSM για την δημιουργία ενός πίνακα DSM αντιπροτύπων διοίκησης έργων λογισμικού και η ταξινόμησή τους με βάση την σειρά επίλυσης τους σε ένα έργο λογισμικού. Σκοπός της εργασίας αυτής είναι να δημιουργήσει έναν πίνακα DSM που να αποτελείται από αντιπρότυπα διοίκησης έργων λογισμικού (software project management antipatterns), ταξινομημένα σύμφωνα με την σειρά που θα πρέπει να επιλυθούν σε ένα έργο λογισμικού με βάση τα αποτελέσματα του ευφυούς συστήματος SPARSE. Το SPARSE δίνει την δυνατότητα να συσχετίζουμε αντιπρότυπα με βάση τα συμπτώματά τους, όπως αυτά προκύπτουν από την οντολογία την οποία χρησιμοποιούμε. Στη συνέχεια, τις συσχετίσεις αυτές τις μοντελοποιούμε σε έναν πίνακα σχεδίασης δομής (DSM), και τέλος με την τεχνική του Partitioning ταξινομούμε τα αντιπρότυπα με βάση την χρονολογική σειρά με την οποία θα κληθεί ένας μάνατζερ να τα επιλύσει. ΕΡΓΑΛΕΙΟ ΔΙΑΧΕΙΡΙΣΗΣ ΑΝΤΙΠΡΟΤΥΠΩΝ ΛΟΓΙΣΜΙΚΟΥ VII
ΠΕΡΙΕΧΟΜΕΝΑ Π ΕΡΙΕΧΟΜΕΝΑ ΠΕΡΙΛΗΨΗ... VII ΠΕΡΙΕΧΟΜΕΝΑ... IX ΛΙΣΤΑ ΣΧΗΜΑΤΩΝ... XI ΛΙΣΤΑ ΠΙΝΑΚΩΝ... XIII ΚΕΦΑΛΑΙΟ 1: ΕΙΣΑΓΩΓΗ... 15 ΚΕΦΑΛΑΙΟ 2: ΒΑΣΙΚΕΣ ΕΝΝΟΙΕΣ... 19 2.1 ΑΝΤΙΠΡΟΤΥΠΑ ΛΟΓΙΣΜΙΚΟΥ (SOFTWARE ANTIPATTERNS)... 22 2.1.1 ΟΡΙΣΜΟΣ... 22 2.1.2 ΚΑΤΗΓΟΡΙΕΣ ΑΝΤΙΠΡΟΤΥΠΩΝ... 23 2.1.3 ΔΟΜΗ ΑΝΤΙΠΡΟΤΥΠΩΝ... 24 2.1.4 ΧΑΡΑΚΤΗΡΙΣΤΙΚΑ ΑΝΤΙΠΡΟΤΥΠΩΝ... 25 2.1.5 ΠΡΟΒΛΗΜΑΤΑ ΜΕ ΤΑ ΑΝΤΙΠΡΟΤΥΠΑ... 26 2.2 ΟΝΤΟΛΟΓΙΕΣ (ONTOLOGIES)... 27 2.1.1 ΟΡΙΣΜΟΣ... 27 2.1.2 ΒΑΣΙΚΑ ΧΑΡΑΚΤΗΡΙΣΤΙΚΑ ΟΝΤΟΛΟΓΙΩΝ... 27 2.1.3 ΟΝΤΟΛΟΓΙΚΕΣ ΓΛΩΣΣΕΣ... 28 2.3 ΠΙΝΑΚΑΣ ΣΧΕΔΙΑΣΗΣ ΔΟΜΗΣ (DSM- DESIGN STRUCTURE MATRIX)... 29 ΚΕΦΑΛΑΙΟ 3: ΕΡΓΑΛΕΙΑ... 31 3.1 PROTEGE... 34 3.2 SPARSE... 37 3.3 PSM32... 41 ΚΕΦΑΛΑΙΟ 4: ΜΕΘΟΔΟΛΟΓΙΑ... 43 ΕΡΓΑΛΕΙΟ ΔΙΑΧΕΙΡΙΣΗΣ ΑΝΤΙΠΡΟΤΥΠΩΝ IX
ΠΑΠΑΔΟΠΟΥΛΟΥ ΙΩΑΝΝΑ 4.1 ΑΝΑΛΥΣΗ ΒΗΜΑΤΩΝ... 45 4.2 Η ΜΕΘΟΔΟΣ DSM... 51 4.3 Η ΤΕΧΝΙΚΗ ΤΟΥ ΔΙΑΧΩΡΙΣΜΟΥ (PARTITIONING)... 60 ΚΕΦΑΛΑΙΟ 5: ΑΠΟΤΕΛΕΣΜΑΤΑ... 63 5.1 ΕΦΑΡΜΟΓΗ ΜΕΘΟΔΟΛΟΓΙΑΣ... 66 5.1.1 WIKIPEDIA ANTIPATTERNS... 66 5.1.2 PATTERN COMMUNITY WIKI ANTIPATTERN CATALOGUE... 68 5.1.3 SOFTWARE PROJECT MANAGEMENT BLOGS... 70 5.2 ΕΠΙΛΟΓΟΣ... 72 ΠΑΡΑΡΤΗΜΑ Ι: ΑΝΑΦΟΡΕΣ... 75 X ΕΡΓΑΛΕΙΟ ΔΙΑΧΕΙΡΙΣΗΣ ΑΝΤΙΠΡΟΤΥΠΩΝ
ΛΙΣΤΑ ΣΧΗΜΑΤΩΝ Λ ΙΣΤΑ Σ ΧΗΜΑΤΩΝ Εικόνα 2.1.1: Σχέση προτύπων- αντιπροτύπων..32 Εικόνα 3.1.1: Στιγμιότυπο από το αρχικό περιβάλλον...35 Εικόνα 3.1.2 Παράδειγμα για συγκεκριμένο αντιπρότυπο. Το Protégé μας παρέχει μια σύντομη περιγραφή καθώς και τα συμπτώματα, τις αιτίες και τις συνέπειες του κάθε αντιπροτύπου...36 Εικόνα 3.2.1 Αρχικό περιβάλλον SPARSE...37 Εικόνα 3.2.2 Αποτελέσματα μετά το execute στο προηγούμενο παράθυρο. Οι δύο κατηγορίες αντιπροτύπων που επιστρέφονται...38 Εικόνα 3.2.3: Αλγόριθμος για Αντιπρότυπα που σχετίστηκαν με βάση τα συμπτώματα (Symptom Matched Antipatterns)...39 Εικόνα 3.2.4: Αλγόριθμος για Συσχετιζόμενα Αντιπρότυπα (Other Useful Antipatterns)...40 Εικόνα 3.2.5 Επεξηγηματικό παράθυρο...40 Εικόνα 3.3.1: Στιγμιότυπο από το περιβάλλον του PSM32, ένα απλό παράδειγμα...41 Εικόνα 4.1.1 Αρχικό περιβάλλον Protégé. Επιλέγουμε την εισαγωγή της οντολογιάς που θέλουμε...45 Εικόνα 4.1.2 Παράδειγμα για συγκεκριμένο αντιπρότυπο (Email is Dangerous). Στην τελευταία στήλη βλέπουμε τις αιτίες, τις συνέπειες και τα συμπτώματα που έχει το συγκεκριμένο αντιπρότυπο και στην συνέχεια μια σύντομη περιγραφή του...46 Εικόνα 4.2.1 Εισαγωγή οντολογίας...47 Εικόνα 4.2.2 Αρχικό περιβάλλον SPARSE. Η στήλη στα αριστερά περιέχει όλα τα συμπτώματα που υπάρχουν στην οντολογία...48 Εικόνα 4.2.3 Επεξηγηματικό παράθυρο για το «Gilding the lilly»...49 Πίνακας 4.3.1 Παράδειγμα πίνακα DSM για Wikipedia Antipatterns...50 Εικόνα 4.1 Ένα απλό παράδειγμα για πίνακα DSM...52 Εικόνα 4.2 Άνω Τριγωνικός πίνακας. Παρατηρούμε πως δεν υπάρχουν σημάδια πάνω από την κύρια διαγώνιο...52 Εικόνα 4.3: Γραφική αναπαράσταση Παράλληλης ή ταυτόχρονης σχέσης (parallel - concurrent)...54 Εικόνα 4.4: Γραφική αναπαράσταση Ακολουθιακής ή εξαρτημένης σχέσης (sequential dependent)...54 Εικόνα 4.5: Γραφική αναπαράσταση Σε ζευγάρια ή αλληλοεξαρτώμενης σχέσης (coupled - interdependent)...55 Εικόνα 4.6: DSM αναπαράσταση Παράλληλης ή ταυτόχρονης σχέσης (parallel - concurrent)...56 Εικόνα 4.7: DSM αναπαράσταση Ακολουθιακής ή εξαρτημένης σχέσης (sequential dependent)...56 Εικόνα 4.8: DSM αναπαράσταση Σε ζευγάρια ή αλληλοεξαρτώμενης σχέσης (coupled - interdependent)...56 ΕΡΓΑΛΕΙΟ ΔΙΑΧΕΙΡΙΣΗΣ ΑΝΤΙΠΡΟΤΥΠΩΝ ΛΟΓΙΣΜΙΚΟΥ XI
ΠΑΠΑΔΟΠΟΥΛΟΥ ΙΩΑΝΝΑ Εικόνα 4.9: Γράφος εξαρτήσεων...57 Εικόνα 4.10: Πίνακας DSM για την αναπαράσταση των εξαρτήσεων του γράφου στην εικόνα 4.9...58 Εικόνα 4.11: DSM αναπαράσταση ενός συστήματος μετά την εφαρμογή της τεχνικής του partitioning...58 XII ΔΙΚΤΥΑΚΑ ΕΙΚΟΝΙΚΑ ΕΚΠΑΙΔΕΥΤΙΚΑ ΠΕΡΙΒΑΛΛΟΝΤΑ: Η ΠΛΑΤΦΟΡΜΑ EVE
ΛΙΣΤΑ ΠΙΝΑΚΩΝ Λ ΙΣΤΑ Π ΙΝΑΚΩΝ Πίνακας 3.1: Πηγές αντιπροτύπων που χρησιμοποιήθηκαν στην OWL οντολογία...30 Πίνακας 5.1.1α : Εκτέλεση για τα Wikipedia Antipatterns (αρχικός πίνακας με συσχετίσεις κατα στήλες)...63 Πίνακας 5.1.1β : Εκτέλεση για τα Wikipedia Antipatterns μετά το partition...64 Πίνακας 5.1.2α : Εκτέλεση Pattern Community Wiki Antipattern Catalogue (αρχικός πίνακας με συσχετίσεις κατα στήλες)...65 Πίνακας 5.1.2β: Εκτέλεση για τα Pattern Community Wiki Antipattern Catalogue μετά το partition..66 Πίνακας 5.1.3α : Εκτέλεση για τα Software Project Management Blogs (αρχικός πίνακας με συσχετίσεις κατα στήλες)...67 Πίνακας 5.1.3β : Εκτέλεση για τα Software Project Management Blogs μετά το Partition...68 ΕΡΓΑΛΕΙΟ ΔΙΑΧΕΙΡΙΣΗΣ ΑΝΤΙΠΡΟΤΥΠΩΝ ΛΟΓΙΣΜΙΚΟΥ XIII
ΚΕΦΑΛΑΙΟ 1: Ε ΙΣΑΓΩΓΗ
ΚΕΦΑΛΑΙΟ 1: ΕΙΣΑΓΩΓΗ ΕΙΣΑΓΩΓΗ Η ανάπτυξη λογισμικού αποτελείται από ένα σύνολο ενεργειών που πρέπει να γίνουν με σωστό τρόπο ώστε να έχουμε τα επιθυμητά αποτελέσματα. Τις ενέργειες αυτές συνήθως αναλαμβάνει ο διοικητής του έργου (manager), ο οποίος είναι υπεύθυνος για την όλη διαδικασία. Οι ενέργειες που πρέπει να γίνουν είναι αρκετές και ο κατάλληλος προγραμματισμός τους είναι απαραίτητος. Υπάρχουν ορισμένοι περιορισμοί αλλά και ορισμένες προϋποθέσεις τις οποίες θα πρέπει να πληροί το λογισμικό που θα αναπτυχθεί. Οι περιορισμοί είναι συνήθως ως προς τον χρόνο, το κόστος, το ανθρώπινο δυναμικό που θα χρειαστεί και άλλα πολλά. Οι προϋποθέσεις είναι συνήθως ως προς τις απαραίτητες λειτουργίες τις οποίες θα πρέπει να εκτελεί και μάλιστα σωστά το λογισμικό. Μια σημαντική προϋπόθεση η οποία όμως πολλές φορές παραγκωνίζεται λόγω των αυστηρών χρονοδιαγραμμάτων είναι η δυνατότητα για επέκταση του προγράμματος αλλά και συντήρησή του. Λέγοντας επέκταση εννοούμε την προσθήκη λειτουργιών που ίσως παρουσιαστούν στο μέλλον, ή λειτουργιών που αποφασίσει ο πελάτης πως θέλει να ενσωματωθούν στο λογισμικό του. Είναι γενικά αποδεκτό πως η ποιότητα ενός λογισμικού κρίνεται και από την ικανότητά του για επέκταση και προσθήκη νέων λειτουργιών. Παρόλα αυτά όμως αυτό αποτελεί και ένα από τα συνηθέστερα προβλήματα τα οποία καλούνται να αντιμετωπίσουν οι διοικητές των έργων λογισμικού. Αντικείμενο της παρούσας εργασίας είναι να προσφέρει μια μεθοδολογία για τους διοικητές έργων λογισμικού ώστε να μπορούν να θέσουν σωστά χρονοδιαγράμματα για την επίλυση προβλημάτων που προκύπτουν στα διάφορα στάδια της ανάπτυξης λογισμικού. Συγκεκριμένα προτείνεται η χρήση των αντιπροτύπων λογισμικού (software antipatterns), με βάση μια μεθοδολογία η οποία θα προτείνει την κατάλληλη σειρά επίλυσης τους. Τα αντιπρότυπα λογισμικού, όπως θα δούμε και στην συνέχεια αναλυτικότερα, είναι ουσιαστικά προβληματικές καταστάσεις οι οποίες αντιμετωπίστηκαν στο παρελθόν, και με βάση την εμπειρία που αποκτήθηκε από αυτές τις καταστάσεις προτείνεται μια λύση στο συγκεκριμένο πρόβλημα. Τα αντιπρότυπα αυτά όμως, συνήθως δεν εμφανίζονται μεμονωμένα, δηλαδή είναι προβληματικές καταστάσεις που η μια προκαλεί την άλλη κτλ. Έτσι προκύπτει ένα μεγάλο πρόβλημα όσο αναφορά το πώς μπορεί να σχετίζονται τα αντιπρότυπα αυτά μεταξύ τους. Σκοπός λοιπόν της εργασίας αυτής είναι να δώσει μια λύση στα προβλήματα που προκύπτουν από τον αυξημένο αριθμό αντιπροτύπων που υπάρχουν αλλά και από τον αυξημένο αριθμό των συσχετίσεων που υφίστανται μεταξύ των αντιπροτύπων, γιατί όπως είπαμε τα αντιπρότυπα έργων λογισμικού σπάνια εμφανίζονται μεμονωμένα. Συνήθως εμφανίζονται αρκετά μαζί και μάλιστα συσχετίζονται μεταξύ τους. Η δυσκολία στην καταγραφή των αντιπροτύπων που υπάρχουν δημιουργεί αρκετά προβλήματα στους μάνατζερς και συνεπώς στις επιχειρήσεις που διοικούν. Η Τεχνολογία Λογισμικού έρχεται να δώσει λύσεις στα προβλήματα αυτά μέσω των εργαλείων και των ευφυών συστημάτων που παρέχει. Το κύριο πρόβλημα το οποίο ΕΡΓΑΛΕΙΟ ΔΙΑΧΕΙΡΙΣΗΣ ΑΝΤΙΠΡΟΤΥΠΩΝ ΛΟΓΙΣΜΙΚΟΥ 17
ΠΑΠΑΔΟΠΟΥΛΟΥ ΙΩΑΝΝΑ καλείται να αντιμετωπίσει ένας μάνατζερ που χρησιμοποιεί την μέθοδο των αντιπροτύπων είναι η δυσκολία να αποφασίσει την σειρά επίλυσης των αντιπροτύπων που υπάρχουν στο έργο που έχει να αναλάβει. Εδώ η μεθοδολογία DSM έρχεται να δώσει την λύσει με αλγορίθμους όπως το Partitioning που βοηθάνε στην λήψη των κατάλληλων αποφάσεων. Η εργασία δομείται σε κεφάλαια ως εξής: Στο Κεφάλαιο 2 παρουσιάζονται οι βασικές έννοιες που θα χρησιμοποιηθούν στο υπόλοιπο της εργασίας. Συγκεκριμένα δίνεται έμφαση σε τρεις έννοιες. Η πρώτη έννοια είναι τα αντιπρότυπα, όπου παρουσιάζεται μια σύντομη περιγραφή της έννοιας μαζί με ορισμούς για καλύτερη κατανόηση. Η δεύτερη έννοια είναι οι οντολογίες όπου και πάλι δίνονται περιγραφές και ορισμοί. Τέλος αναπτύσσεται η έννοια των πινάκων DSM καθώς και μια σύντομη αναφορά στην μεθοδολογία αυτή. Στο Κεφάλαιο 3, παρουσιάζονται τα εργαλεία τα οποία χρησιμοποιήθηκαν για την ανάπτυξη της εργασίας, συγκεκριμένα γίνεται μια σύντομη αναφορά στο Protégé, στο ευφυές σύστημα SPARSE και στο PSM32. Στο Κεφάλαιο 4, παρουσιάζεται η μεθοδολογία που ακολουθήθηκε, τα βήματα ένα ένα, καθώς και επεξηγήσεις για την διαδικασία με αναλυτικές λεπτομέρειες. Στο Κεφάλαιο 5, δίνονται τα αποτελέσματα της εργασίας και τα τελικά συμπεράσματα. Στο Παράρτημα I παρουσιάζονται η βιβλιογραφία και οι δικτυακοί τόποι που αναφέρονται στην εργασία. 18 ΕΡΓΑΛΕΙΟ ΔΙΑΧΕΙΡΙΣΗΣ ΑΝΤΙΠΡΟΤΥΠΩΝ ΛΟΓΙΣΜΙΚΟΥ
ΚΕΦΑΛΑΙΟ 2: Β ΑΣΙΚΕΣ Ε ΝΝΟΙΕΣ
ΒΑΣΙΚΕΣ ΕΝΝΟΙΕΣ Ο κυριότερος τρόπος που οι άνθρωποι προσεγγίζουμε τα προβλήματα που συναντάμε γενικότερα στην ζωή μας, επαγγελματική και προσωπική είναι συνήθως μέσα από τις εμπειρίες μας. Όσο και αν αυτό φαίνεται παράξενο εκεί ακριβώς στηρίζεται και όλη η θεωρία των προτύπων και συνεπώς και των αντιπροτύπων στην τεχνολογία λογισμικού. Για να κάνουμε τα πιο πάνω σαφέστερα θα δανειστούμε το παράδειγμα που χρησιμοποιούν οι P.A. Laplante και C.J.Neil στο βιβλίο τους. [1]. Ας σκεφτούμε την τελευταία φορά που κανονίσαμε να συναντήσουμε έναν φίλο μας κάπου. Παρόλο που δεν είχαμε προγραμματίσει από πριν την ακριβή απόσταση που θα χρειαστεί να διανύσουμε, δεν είχαμε υπολογίσει ακριβώς την κίνηση που θα συναντήσουμε εκείνη την ώρα και ούτε υπολογίσαμε με πολύπλοκες πράξεις την ακριβή ώρα που θα φτάναμε, με βάση την εμπειρία μας, υπολογίσαμε κατα προσέγγιση την ώρα που χρειαζόμαστε συνήθως να φτάσουμε στο συγκεκριμμένο προορισμό. Έτσι ξεκινώντας την ώρα που υπολογίσαμε και με βάση την εμπειρία μας, σίγουρα θα φτάναμε στον προορισμό μας με μία μικρή και μάλλον ασήμαντη απόκλιση από την ακριβή ώρα που είχαμε συμφωνήσει. Το συμπέρασμα λοιπόν από όλη αυτή την ιστορία είναι πως ο άνθρωπος με βάση τις εμπειρίες και τα βιώματά του και χωρίς πολύπλοκους υπολογισμούς, βρίσκει λύσεις στα προβλήματα που καλείται να αντιμετωπίσει. Ένα από τα σημαντικότερα ερωτήματα είναι σαφώς το τί γίνεται όταν κάποιος δεν έχει εμπειρία να λύσει ένα συγκεκριμένο πρόβλημα, αλλά αυτό είναι κάτι που θα εξετάσουμε αργότερα. Με αυτό το πολύ απλό παράδειγμα μπορούμε να εξηγήσουμε ολόκληρη την φιλοσοφία γύρω από την ανάπτυξη των προτύπων και των αντιπροτύπων λογισμικού. Ο άνθρωπος που έχει να υπολογίσει την ώρα που χρειάζεται για να φτάσει στον προορισμό του, που πρέπει να βρει δηλαδή μια λύση στο πρόβλημά του, μπορεί να παραλληλιστεί με τον μάνατζερ που αναλαμβάνει να λύσει ένα πρόβλημα που προέκυψε στην οργάνωση της επιχείρησης που έχει αναλάβει, ή να αναλάβει την διεκπαιρέωση μιας συγκεκριμένης εργασίας. Βλέπουμε έτσι πως με την χρήση των προτύπων αλλά και των αντιπροτύπων μπορούμε να δίνουμε λύσεις σε προβλήματα. Πιό συγκεκριμένα όμως στην περίπτωσή μας, αν αξιοποιήσουμε την τεχνολογία που έχει αναπτυχθεί γύρω από τα αντιπρότυπα λογισμικού, μπορούμε να έχουμε κέρδος ώς προς τον συνολικό χρόνο που θα χρησιμοποιήσουμε και ως προς το κόστος που θα χρειαστούμε. Αυτό γίνεται γιατί με βάση εμπειρίες από άλλους, οι οποίοι είχαν ορισμένες αποτυχίες κατα την διάρκεια της ανάπτυξης ή της εφαρμογής έργων λογισμικού, δημιουργήθηκαν τα αντιπρότυπα λογισμικού. Τα αντιπρότυπα λογισμικού ουσιαστικά βοηθούν στο να δούμε τι ακριβώς πήγε λάθος σε παρόμοιες περιπτώσεις, αλλά και τι λύση μπορεί να εφαρμοστεί, ώστε να μάθουμε από τα λάθη που έγιναν στο παρελθόν, να προλάβουμε την επανάληψή τους, αλλά και να ακολουθήσουμε μια σωστά εφαρμοσμένη λύση στο δικό μας πρόβλημα. Στη συνέχεια του κεφαλαίου θα αναλύσουμε τις έννοιες αντιπρότυπο, οντολογία και την έννοια του Πίνακα Σχεδίασης Δομής, καθώς αποτελούν τις έννοιες πάνω στις οποίες στηρίζεται η ανάπτυξη αυτής της εργασίας.
ΠΑΠΑΔΟΠΟΥΛΟΥ ΙΩΑΝΝΑ 2.1 ΑΝΤΙΠΡΟΤΥΠΑ ΛΟΓΙΣΜΙΚΟΥ (SOFTWARE ANTIPATTERNS) Τα αντιπρότυπα λογισμικού βοήθησαν στην εργασία αυτή καθώς στόχος μας ήταν να μοντελοποιηθεί η εμφάνιση των αντιπροτύπων σε ένα έργο λογισμικού και να προταθεί η σειρά με την οποία θα πρέπει να τα επιλύσει ένας μάνατζερ. Στη συνέχεια θα γίνει αναλυτικότερη περιγραφή της μεθοδολογίας που ακολουθήθηκε. 2.1.1 Ορισμός Στην τεχνολογία Λογισμικού όταν αναφερόμαστε σε Αντιπρότυπα Λογισμικού εννοούμε συνήθως πρότυπα τα οποία παρόλο που χρησιμοποιούνται ευρέως, όχι μόνο δεν είναι αποτελεσματικά αλλά συνήθως δημιουργούν και αρκετά προβλήματα. Πίο συγκεκριμένα ο όρος πρωτοεμφανίστηκε το 1955 από τον Andrew Koenig o οποίος βασίστηκε στην έννοια των προτύπων λογισμικού (Design Patterns) όπως έιχε χρησιμοποιηθεί στο βιβλίο Gang of Four s όπου αναπτύχθηκε για πρώτη φορά η έννοια των προτύπων λογισμικού [4]. Στην βιβλιογραφία ο όρος αντιπρότυπο συναντάται και ώς σκοτεινά πρότυπα (dark-patterns) ή παγίδες (pitfalls). Η σχέση των αντιπροτύπων με τα πρότυπα είναι μεγάλη (βλ είκόνα 2.1.1) [2]. Τα αντιπρότυπα προκύπτουν κυρίως λόγω λάθος επιλογών του μάνατζερ του έργου. Λάθος επιλογές μπορεί να είναι η ελλειπής γνώση που είχε για το θέμα ή ακόμα η εφαρμογή ενός προτύπου σε μια κατάσταση λανθασμένα. Η διαφορά προτύπων αντιπροτύπων είναι ο τρόπος με τον οποίο δημιουργούνται. Τα πρότυπα δημιουργούνται για να λύσουν ενα πρόβλημα που υπάρχει ρητά καταγεγγραμένο, ενώ τα αντιπρότυπα προκύπτουν από μια λανθασμένη λύση η οποία εφαρμόστηκε και προκύπτουν από κάποιες αιτίες. Σημαντική διαφορά είναι ακόμα και το γεγονός ότι τα αντπρότυπα λαμβάνουν υπόψην τα συμπτώματα των αντιπροτύπων. Αυτό είναι κυριώς που τα καθιστά καταλληλότερα σε εφαρμογές λογισμικού καθώς είναι φανερά πιο εύκολο να εντοπιστούν τα συμπτώματα σε ένα πρόγραμμα παρά τα προβλήματα που υπάρχουν σε αυτό. 22 ΕΡΓΑΛΕΙΟ ΔΙΑΧΕΙΡΙΣΗΣ ΑΝΤΙΠΡΟΤΥΠΩΝ ΛΟΓΙΣΜΙΚΟΥ
Εικόνα 2.1.1 Σχέση προτύπων- αντιπροτύπων. Η έννοια των αντιπροτύπων έχει αποκτήσει μεγάλη σημασία λόγω του ότι κάποιος μπορεί να αποφύγει ορισμένες «κακές» συμπεριφορές πρότυπα, τα οποία αντιμετώπισαν άλλοι και έχουν καταγραφεί ως αντιπρότυπα. Έτσι με την αναγνώριση των λανθασμένων πρακτικών που έχουν ακολουθηθεί κατα καιρούς, υπάρχει η δυνατότητα για αποφυγή των ίδιων λαθών ή ακόμα και επίλυσή με ήδη εφαρμοσμένους και αποδοτικούς τρόπους. Με βάση ορισμούς που έχουν δοθεί στα αντιπρότυπα ώστε να γίνεται η διάκριση από μια απλή κακή πρακτική είναι να ικανοποιεί δύο στοιχεία κλειδιά: πρώτον να είναι μια επαναλαμβανόμενη πράξη, δομή ή εργασία, η οποία αρχικά φαίνεται να έχει καλά αποτελέσματα, αλλά τελικά προκαλεί περισσότερα προβλήματα από ότι θετικές συνέπειες, και δεύτερον να υπάρχει μια λύση η οποία είναι ξεκάθαρα ορισμένη και αποτελεσματική και αυτό να έχει αποδειχθεί στην πράξη αρκετές φορές. Με τα αντιπρότυπα δηλαδή έχουμε μια αναπαράσταση μιας μη-λειτουργικής λύσης που εφαρμόστηκε σε μια προβληματική κατάσταση, και τις απαραίτητες διορθώσεις που θα πρέπει να γίνουν ώστε να διορθωθεί η κατάσταση αυτή. 2.1.2 Κατηγορίες Αντιπροτύπων Στην βιβλιογραφία [4],[2], αναφέρονται πολλές κατηγορίες αντιπροτύπων όπως, Αντιπρότυπα Ανάπτυξης Λογισμικού (Software Development Anti-patterns), τα οποία βασίζονται κυρίως στην δομή του προγράμματος, Αντιπρότυπα Αρχιτεκτονικής Λογισμικού (Software Architecture Anti-patterns), τα οποία στηρίζονται στην αρχιτεκτονική που ακολουθήθηκε για την ανάπτυξη του προγράμματος, Αντιπρότυπα Διοίκησης Έργων Λογισμικού (Software Project Management Anti-patterns), τα οποία επικεντρώνονται στην διοίκηση του λογισμικού όσο αναφορά τις αποφάσεις που καλείται να πάρει ο μάνατζερ του έργου (χρόνος, χρήμα, αρμοδιότητες, κτλ), Οργανωτικά Αντιπρότυπα (Organizational anti-patterns), Αντιπρότυπα Ανάλυσης (Analysis anti-patterns), Αντιπρότυπα Αντικειμενοστραφούς Σχεδίασης (Object-oriented design anti-patterns), Αντιπρότυπα ΕΡΓΑΛΕΙΟ ΔΙΑΧΕΙΡΙΣΗΣ ΑΝΤΙΠΡΟΤΥΠΩΝ ΛΟΓΙΣΜΙΚΟΥ 23
ΠΑΠΑΔΟΠΟΥΛΟΥ ΙΩΑΝΝΑ Προγραμματισμού (Programming anti-patterns), Μεθοδολογικά Αντιπρότυπα (Methodological anti-patterns), Αντιπρότυπα Διαμόρφωσης Διοίκησης (Configuration management anti-patterns) και Αντιπρότυπα Περιβάλλοντος (Environmental Antipatterns) τα οποία προκύπτουν κυρίως από μια προβληματική επικρατούσα κατάσταση όσο αναφορά το κοινωνικό και πολιτικό κομμάτι οργάνωσης του έργου [1]. Οι τρεις πρώτες [2] και η τελευταία θεωρούνται οι βασικότερες και αξίζει να τις δούμε αναλυτικότερα 1. Αντιπρότυπα Ανάπτυξης Λογισμικού (Software Development Anti-patterns): Αναφέρονται κυρίως στα αντιπρότυπα με βάση την δομή της ανάπτυξής τους. Για τα αντιπρότυπα Ανάπτυξης Λογισμικού η δομή έχει να κάνει κυρίως με αποφάσεις σχεδίασης της δομής του προγράμματος, ουσιαστικά του κώδικα. Προβλήματα που εντοπίζονται όσο αναφορά τη δομή κυρίως σε όχι καλά δομημένα προγράμματα οδηγούν σε δυσκολίες στη συντήρηση του λογισμικού σε βάθος χρόνου. Είναι γνωστό πως προγράμματα όχι καλά δομημένα, δημιουργούν προβλήματα ακόμα και για τις πιο μικρές αλλαγές. 2. Αντιπρότυπα Αρχιτεκτονικής Λογισμικού (Software Architecture Antipatterns): Αναφερόμαστε κυρίως σε θέματα αρχιτεκτονικής του έργου. Λάθη στην αρχιτεκτονική ενός έργου γίνονται από τα αρχικά κυρίως στάδια και στη συνέχεια προκαλούν προβλήματα που συνεχώς συσσωρεύονται με την πάροδο του χρόνου. Τέτοια λάθη όσο νωρίτερα εντοπιστούν τόσο καλύτερα είναι για την πρόοδο του έργου. 3. Αντιπρότυπα Διοίκησης Έργων Λογισμικού (Software Project Management Anti-patterns): Ίσως η σημαντικότερη κατηγορία που εξετάζουμε, η οποία αναφέρεται κυρίως στις αποφάσεις που καλείται να πάρει ο μάνατζερ του έργου ή η ομάδα ανάπτυξης του έργου. Οι αποφάσεις αυτές είναι κυρίως ως προς το κόστος της ανάπτυξης του έργου, ως προς τον χρόνο διεκπεραίωσης του, ως προς το προσωπικό που θα χρησιμοποιηθεί, ως προς τα μέσα που θα χρησιμοποιηθούν κτλ. Τα αντιπρότυπα που χρησιμοποιούμε στην συνέχεια είναι τα αντιπρότυπα αυτής της κατηγορίας. 4. Αντιπρότυπα Περιβάλλοντος (Environmental Anti-patterns): στην κατηγορία αυτή αναφερόμαστε σε αποφάσεις που έχουν να κάνουν με την εσωτερική διοίκηση του έργου καθώς και το επικρατές περιβάλλον, δηλαδή την στρατηγική της ομάδας, τις πολιτικοκοινωνικές αποφάσεις της και γενικά την οργανωτική αντίληψη που επικρατεί [1]. 2.1.3 Δομή Αντιπροτύπων Στα αντιπρότυπα σημαντικό ρόλο παίζει η δομή τους. Είναι η πρώτη εντύπωση που αποκτάει κανείς με το που διαβάζει για κάποιο συγκεκριμένο αντιπρότυπο. Όσο αναφορά την δομή των αντιπροτύπων έχουν προταθεί ορισμένα πρότυπα με επικρατέστερα αυτά των Brown[2] και Laplante- Νeil[1] τα οποία και θα αναλύσουμε στη συνέχεια. Γενικά σε όλα αυτά τα πρότυπα αντιπροτύπων επικρατούν τρεις κύριες ενότητες στην δομή τους: το όνομα, η σύγκρουση και η λύση. Η ενότητα όνομα ουσιαστικά προσδιορίζει τις «προθέσεις» του αντιπροτύπου 24 ΕΡΓΑΛΕΙΟ ΔΙΑΧΕΙΡΙΣΗΣ ΑΝΤΙΠΡΟΤΥΠΩΝ ΛΟΓΙΣΜΙΚΟΥ
και για αυτό τον λόγο το όνομα πρέπει να είναι σύντομο και εύστοχο. Επιπλέον αποτελεί το λεξιλόγιο της «γλώσσας» των αντιπροτύπων όπως πολύ εύστοχα αναφέρει ο Alexander στο βιβλίο του A Pattern Language [3]. Η ενότητα σύγκρουση (conflict) αποτελεί την κύρια περιγραφή του αντιπροτύπου μαζί με αναλυτικές λεπτομέρειες. Τέλος η ενότητα λύση περιλαμβάνει μια περιγραφή της λύσης που έχει δοθεί ή που προτείνεται, αλλά το σημαντικό εδώ είναι πως η λύση αυτή δεν είναι συγκεκριμένη, έτσι ώστε να υπάρχει η δυνατότητα να εφαρμοστεί σε μεγάλο εύρος προβλημάτων. Σύμφωνα με τον Brown [2] η δομή πρέπει να είναι η εξής: (1) Όνομα αντιπροτύπου (2) Λέξεις Κλειδιά (3) Υπόβαθρο (περιέχει παραδείγματα για το πότε εμφανίζεται κυρίως το συγκεκριμένο αντιπρότυπο- μη υποχρεωτικό πεδίο) (4) Ανεκδοτικά στοιχεία (εννοεί το υπόβαθρο που συνήθως είναι κωμικό για τον τρόπο που πήρε την ονομασία του το αντιπρότυπο- δεν είναι υποχρεωτικό πεδίο συμπλήρωσης). (5) Λύση (6) Συμπτώματα και Συνέπειες (7) Συνήθεις Αιτίες (8) Επανασχεδιασμένη Λύση (refactored solution) (9) Παραλλαγές του Αντιπροτύπου (10)Παραδείγματα (11)Σχετιζόμενες λύσεις (αναφέρονται αντιπρότυπα που σχετίζονται με το αντιπρότυπο που εξετάζει) Σύμφωνα με τους Laplante- Νeil [1] η δομή πρέπει να είναι η εξής : (1) Όνομα (2) Γενική Περιγραφή (3) Προβλήματα Λειτουργίας (προβλήματα συγκεκριμένης πρακτικής) (4) Επεξήγηση (αιτίες, συμπτώματα, συνέπειες) (5) Έκτακτη Λύση (Band Aid- μια σύντομη λύση για όσους δεν έχουν χρόνο για επαναπροσδιορισμό της λύσης από την αρχή) (6) Αυτό - επιδιόρθωση (ένα πρώτο βήμα για αντιπρότυπα που υφίστανται για μεγάλο χρονικό διάστημα) (7) Επαναπροσδιορισμός (περιγραφή των αναγκαίων αλλαγών) (8) Παρατηρήσεις (προαιρετικό γενικά σχόλια) (9) Προσδιορισμός (λίστα από ερωτήσεις για διάγνωση του αντιπροτύπου) 2.1.4 Χαρακτηριστικά Αντιπροτύπων Όπως εξηγήσαμε η δομή των αντιπροτύπων περιέχει και την ενότητα με τα χαρακτηριστικά τους. Συγκεκριμένα για κάθε αντιπρότυπο ορίζονται τρία βασικά ΕΡΓΑΛΕΙΟ ΔΙΑΧΕΙΡΙΣΗΣ ΑΝΤΙΠΡΟΤΥΠΩΝ ΛΟΓΙΣΜΙΚΟΥ 25
ΠΑΠΑΔΟΠΟΥΛΟΥ ΙΩΑΝΝΑ χαρακτηριστικά: οι αιτίες, οι συνέπειες και τα συμπτώματα [1], [2], [3]. Στον όρο αιτία (cause), συμπεριλαμβάνουμε μια λίστα από χαρακτηριστικά ή καταστάσεις τα οποία οδήγησαν στην εμφάνιση του συγκεκριμένου αντιπροτύπου. Με τον όρο συνέπεια (consequence) εννοούμε τα αρνητικά αποτελέσματα που έχει η εμφάνιση του συγκεκριμένου αντιπροτύπου. Τέλος με τον όρο σύμπτωμα (symptom), αναφερόμαστε στις ιδιότητες περιγραφές εκείνες που προσδιορίζουν την εμφάνιση του συγκεκριμένου αντιπροτύπου [22]. Η χρήση των χαρακτηριστικών αυτών είναι ιδιαίτερα χρήσιμη γιατί μας βοηθάει στο να εντοπίζουμε συσχετίσεις που πιθανόν να υπάρχουν μεταξύ αντιπροτύπων με βάση τα χαρακτηριστικά αυτά. Αυτή τη μέθοδο συσχέτισης χρησιμοποιούμε και στην συνέχεια για την εύρεση των συσχετιζόμενων αντιπροτύπων με την χρήση του ευφυούς συστήματος SPARSE με περισσότερες λεπτομέρειες στην ενότητα 4. 2.1.5 Προβλήματα με τα Αντιπρότυπα Ένα από τα κυριότερα προβλήματα που συναντάμε με τα αντιπρότυπα είναι ο μικρός αριθμός που εμφανίζονται καταγεγραμμένα. Τόσο στο διαδίκτυο όσο και στην βιβλιογραφία υπάρχει περιορισμένος αριθμός αντιπροτύπων. Αυτό προκύπτει κυρίως από τον αυξημένο αριθμό δομών που έχουν προταθεί για την καταγραφή των αντιπροτύπων (βλ. Brοwn, Laplante Neil κτλ). Λόγω λοιπόν αυτής της ποικιλίας τρόπων καταγραφής των αντιπροτύπων οι διοικητές των έργων δυσκολεύονται να αποφασίσουν ποιά μέθοδο θα ακολουθήσουν ώστε να καταγράψουν την προβληματική κατάσταση με την οποία ήρθαν αντιμέτωποι. Ένα άλλο πρόβλημα είναι πως τα ήδη καταγεγραμμένα αντιπρότυπα πολλές φορές δεν είναι σωστά διατυπωμένα. Αυτό δυσκολεύει την μεταξύ τους συσχέτιση και δημιουργεί ένα μπέρδεμα ως προς την σύγκριση τους. Τέλος το σημαντικότερο πρόβλημα που θα λέγαμε ότι υπάρχει είναι ο υψηλός βαθμός συσχέτισης μεταξύ των αντιπροτύπων. Αυτό πρακτικά σημαίνει πως η εμφάνιση ενός αντιπροτύπου σχετίζεται με αρκετά ακόμα αντιπρότυπα τα οποία θα πρέπει να επιλυθούν. Πολλές φορές όμως τα αντιπρότυπα έχουν μια συγκεκριμένη σειρά με την οποία θα έπρεπε να επιλυθούν. Αυτό συμβαίνει στις περιπτώσεις εκείνες που τα αντιπρότυπα σχετίζονται μεταξύ τους. Ορισμένα αντιπρότυπα για να επιλυθούν μπορεί να χρειάζονται πληροφορία από την επίλυση άλλων αντιπροτύπων, τα οποία όμως να μην έχουν ακόμα επιλυθεί και συνεπώς να μην είναι διαθέσιμη η πληροφορία την οποία ζητάνε. 26 ΕΡΓΑΛΕΙΟ ΔΙΑΧΕΙΡΙΣΗΣ ΑΝΤΙΠΡΟΤΥΠΩΝ ΛΟΓΙΣΜΙΚΟΥ
2.2 ΟΝΤΟΛΟΓΙΕΣ (ONTOLOGIES) Οι οντολογίες είχαν βασικό ρόλο στην εργασία αυτή, καθώς χρησιμοποιήθηκε μια συγκεκριμένη οντολογία ως βάση γνώσης και συγκεκριμένα χρησιμοποιήθηκε για τον εντοπισμό των συμπτωμάτων των αντιπροτύπων που θα αναλυθούν. Για αυτό τον λόγο είναι σημαντικό να δώσουμε ορισμένους ορισμούς και βασικές έννοιες γύρω από τις οντολογίες για να αποκτήσουμε ένα θεωρητικό υπόβαθρο. 2.1.1 Ορισμός Ο όρος οντολογία εμφανίστηκε στην δεκαετία του 90 με το άρθρο του Gruber «Αρχές για την Σχεδίαση Οντολογιών για Διαμοίραση Γνώσης» [12], αποκτώντας την έννοια του καθορισμού της εννοιολογικής σημασίας ενός τεχνικού όρου. Δηλαδή μια οντολογιά είναι ουσιαστικά μια περιγραφή ένας επίσημος προσδιορισμός των σεναρίων και των σχέσεων που μπορεί να υφίστανται μεταξύ των οντοτήτων του υπό εξέταση έργου. Σύμφωνα με τον συγγραφέα οι οντολογίες συχνά θεωρούνται λανθασμένα ίσες με ιεραρχίες κλάσεων και σχέσεων επειδή η έννοια της οντολογίας είναι στην ουσία πιο γενική, δεδομένου ότι απλώς βοηθάει στον προσδιορισμό του εννοιολογικού υπόβαθρου και δεν προσθέτει νέα γνώση. Αυτό πρακτικά σημαίνει πως κάποιος για να χρησιμοποιήσει αποδοτικά τις οντολογίες χρειάζεται να καθορίσει αξιώματα τα οποία προσδιορίζουν τις πιθανές συσχετίσεις μεταξύ των όρων που αναλύονται [13]. Η έννοια της οντολογίας στην επιστήμη των υπολογιστών, είναι μια επίσημη αναπαράσταση ενός συνόλου σεναρίων και των σχέσεων μεταξύ τους σε μια συγκεκριμένη περιοχή - θεματική ενότητα. Χρησιμοποιείται κυρίως για να προσδιορίσει την θεματική ενότητα αλλά και τις λεπτομέρειες που την αφορούν [8]. 2.1.2 Βασικά Χαρακτηριστικά Οντολογιών Τα κύρια συστατικά των οντολογιών είναι οι κλάσεις (classes), τα χαρακτηριστικά (attributes), οι περιπτώσεις (Instances) και οι σχέσεις (relations) [14]. Κλάσεις ή σενάρια (concepts) όπως συχνά χρησιμοποιείται ο όρος, ονομάζονται αφηρημένες κυρίως ομάδες, σύνολα και συλλογές αντικειμένων ή από μια άλλη οπτική γωνία, αφηρημένα αντικείμενα, τα οποία προσδιορίζονται από το γεγονός ότι λαμβάνουν μέρος σε μια κλάση ομάδα. Χαρακτηριστικά (attributes) είναι αντικείμενα που ανήκουν σε μια οντολογία και μπορεί να περιγραφούν συσχετίζοντάς τα με άλλα αντικείμενα, παρόλο που μπορεί να υπάρχουν και ως ανεξάρτητα χωρίς να είναι δηλαδή εξαρτημένα από την συσχέτισή τους αυτή με άλλα αντικείμενα. Το είδος του χαρακτηριστικού προσδιορίζει την σχέση που μπορεί να έχει με άλλα χαρακτηριστικά. Με τον όρο περιπτώσεις (instances) αναφερόμαστε κυρίως στα βασικά συστατικά μια οντολογίας, δηλαδή σε δομικά αντικείμενα όπως άτομα, πίνακες, κτλ ή ακόμα και σε λίγο πιο αφηρημένα συστατικά όπως είναι αριθμοί και λέξεις. Για την ΕΡΓΑΛΕΙΟ ΔΙΑΧΕΙΡΙΣΗΣ ΑΝΤΙΠΡΟΤΥΠΩΝ ΛΟΓΙΣΜΙΚΟΥ 27
ΠΑΠΑΔΟΠΟΥΛΟΥ ΙΩΑΝΝΑ κωδικοποίηση των χαρακτηριστικών αυτών χρησιμοποιούνται οι οντολογικές γλώσσες. Οι Σχέσεις (relationships ή relations) μεταξύ των αντικειμένων μιας οντολογίας προσδιορίζουν το πώς τα αντικείμενα σχετίζονται μεταξύ τους. Προσδιορίζουν δηλαδή το είδος της σχέσης που υπάρχει και την έννοια με την οποία εννοούμε τον όρο σχέση μεταξύ των αντικειμένων. 2.1.3 Οντολογικές Γλώσσες Μια έννοια η οποία σχετίζεται άμεσα με τις οντολογίες είναι οι οντολογικές γλώσσες (ontology languages) [9]. Οι οντολογικές γλώσσες είναι επίσημες γλώσσες οι οποίες χρησιμοποιούνται για να δημιουργήσουμε οντολογίες. Μας δίνουν την δυνατότητα να κωδικοποιήσουμε την γνώση ορισμένων θεματικών περιοχών και περιλαμβάνουν συνήθως συλλογιστικούς κανόνες που βασίζονται στην περιγραφική λογική (DL description logic) [11], [23]. Οι γλώσσες αυτές είναι συνήθως δηλωτικές, αποτελούν γενικεύσεις των γλωσσών πλαισίων (frame languages), και βασίζονται σε πρώτης τάξης λογική ή περιγραφική λογική [9]. Παραδείγματα οντολογικών γλωσσών είναι η OWL,η RACER, η RDF,η OKBC,η KM, η LOOM κτλ. Στην εργασία αυτή θα ασχοληθούμε με την OWL [10], μια δηλωτική οντολογική γλώσσα, με σημασιολογικά χαρακτηριστικά βασισμένα σε RDF και XML πρότυπα για τον Σημασιολογικό Ιστό (Semantic Web), η οποία επικυρώθηκε από το World Wide Web Consortium (W3C) και έχει αποκτήσει μεγάλο επιστημονικό ενδιαφέρον τα τελευταία χρόνια. Στα πλαίσια της εργασίας αυτής θα χρησιμοποιήσουμε την OWL(Web Ontology Language ) για να εκφράσουμε τις συσχετίσεις μεταξύ των αντιπροτύπων με βάση τα χαρακτηριστικά τους, δηλαδή τις αιτίες, τα συμπτώματα και τις συνέπειες 28 ΕΡΓΑΛΕΙΟ ΔΙΑΧΕΙΡΙΣΗΣ ΑΝΤΙΠΡΟΤΥΠΩΝ ΛΟΓΙΣΜΙΚΟΥ
2.3 ΠΙΝΑΚΑΣ ΣΧΕΔΙΑΣΗΣ ΔΟΜΗΣ (DSM- DESIGN STRUCTURE MATRIX) Οι ανάγκες των σημερινών συστημάτων, απαιτούν εργαλεία και τεχνικές για την σύνθεση και αποσύνθεση των συστημάτων αυτών. Ένας Πίνακας Σχεδίασης Δομής προσφέρει μια εύκολη, συμπαγή και οπτικοποιημένη αναπαράσταση πολύπλοκων συστημάτων και εξυπηρετεί την επίλυση προβλημάτων αποσύνθεσης και ολοκλήρωσης σε τέτοια συστημάτα. Η τεχνική του βασίζεται στην δημιουργία πινάκων Σχεδίασης Δομής και έχει διαδοθεί ευρέως τα τελευταία χρόνια αφου βρίσκει εφαρμογές σε αρκετούς τομείς ανάπτυξης. Τα συστήματα που βρίσκει εφαρμογή η μέθοδος αυτή είναι αρκετά, όπως για παράδειγμα η αρχιτεκτονική ενός προϊόντος ή η σχεδίαση μηχανολογικών διαδικασιών. Λόγω της μεγάλης ανάγκης για αναπαράσταση των εξαρτήσεων που υφίσταντια σε ένα σύστημα, δημιουργήθηκε η ανάγκη για την δημιουργία εργαλείων που θα κάνουν ουσιαστικά μια μοντελοποίηση των σχέσεων αυτών. Ο DSM είναι ένα τέτοιο εργαλείο μοντελοποίησης συστήματος το οποίο αναπαριστά τα στοιχεία του συστήματος και τις μεταξύ τους σχέσεις με ένα συμπαγή τρόπο και για αυτό τον λόγο έχει διαδοθεί ευρέως. Αυτό που ουσιαστικά κάνει η μέθοδος αυτή είναι να αναπαριστά τις ενότητες ή τα βήματα που εμφανίζονται σε ένα πρόβλημα ως στήλες και γραμμές του πίνακα (ο πίνακας που χρησιμοποιείται είναι τετραγωνικός, συνεπώς έχουμε ίσο αριθμό γραμμών και στηλών), και τις συσχετίσεις που υπάρχουν μεταξύ τους ως στοιχεία του πίνακα. Οι συσχετίσεις αυτές υποδηλώνονται με σημάδια στα στοιχεία του πίνακα. Λέγοντας σημάδια αναφερόμαστε κυρίως σε μηδενικά, X,, ανάλογα με το εργαλείο το οποίο χρησιμοποιείται. Στη συνέχεια γίνεται εφαρμογή ενός κατάλληλου αλγορίθμου ώστε να εξαλοιφθούν οι «προβληματικές» συσχετίσεις. Προβληματικές συσχετίσεις εννοούμε τις συσχετίσεις που δημιουργούν προβλήματα επανάληψης ή υποθέσεων. Περισσότερες λεπτομέρειες θα δωθούν στην ενότητα 4 με την μεθοδολογία που ακολουθήθηκε. Η μέθοδος που χρησιμοποιείται συνήθως είναι ο διαχωρισμός (Partitioning) η οποία βοηθάει στην ελαχιστοποίηση των εξαρτήσεων που υπάρχουν μεταξύ των αντιπροτύπων και στον καθορισμό μια σειρά επίλυσης των αντιπροτύπων με βάση τις συσχετίσεις τους. Περισσότερες λεπτομέρειες για τον αλγόριθμο αυτό θα δωθούν στην ενότητα 4. Ένας πίνακας σχεδίασης δομής (DSM) είναι ουσιαστικά ένας τετραγωνικός πίνακας, έχει δηλαδή ίσο αριθμό γραμμών και στηλών, ο οποίος δείχνει τις σχέσεις μεταξύ των στοιχείων που αλληλεπιδρούν σε ένα σύστημα. Στα σημερινά συστήματα όπως είπαμε, οι αλληλεπιδράσεις μεταξύ των στοιχείων είναι αναπόφευκτες καθιστώντας έτσι τον DSM όχι μονο χρήσιμο, αλλά θα λέγαμε και απαραίτητο. Έχουν αναπτυχθεί επίσης αρκετές ακόμη μεθόδοι που βασίζονται στην χρήση πινάκων και σχετίζονται με την μεθοδολογία των DSM, όπως είναι οι χάρτες εξάρτησης (dependency maps), οι πίνακες προτεραιότητας (precedence matrices), οι πίνακες συμβολής (contribution matrices) κτλ. Σήμερα πλέον έχουν αναπτυχθεί αρκετά εργαλεία υλοποίησης της μεθοδολογίας DSM, λόγω της μεγάλης αποτελεσματικότητας της μεθόδου. Στα ΕΡΓΑΛΕΙΟ ΔΙΑΧΕΙΡΙΣΗΣ ΑΝΤΙΠΡΟΤΥΠΩΝ ΛΟΓΙΣΜΙΚΟΥ 29
ΠΑΠΑΔΟΠΟΥΛΟΥ ΙΩΑΝΝΑ πλαίσια της εργαλείας αυτής χρησιμοποιήθηκε το PSM32 το οποίο θα δούμε αναλυτικότερα στην επόμενη ενότητα. 30 ΕΡΓΑΛΕΙΟ ΔΙΑΧΕΙΡΙΣΗΣ ΑΝΤΙΠΡΟΤΥΠΩΝ ΛΟΓΙΣΜΙΚΟΥ
ΚΕΦΑΛΑΙΟ 3: Ε ΡΓΑΛΕΙΑ ΕΡΓΑΛΕΙΟ ΔΙΑΧΕΙΡΙΣΗΣ ΑΝΤΙΠΡΟΤΥΠΩΝ ΛΟΓΙΣΜΙΚΟΥ 31
ΕΡΓΑΛΕΙΑ Στα πλαίσια της εργασίας αυτής χρησιμοποιήθηκαν τα εξής εργαλεία: Protégé, SPARSE, PSM32. Αρχικά το Protégé χρησιμοποιήθηκε ώστε να μπορέσουμε με βάση την OWL οντολογία που χρησιμοποιούμε να βρούμε για κάθε αντιπρότυπο διοίκησης έργων λογισμικού τα συμπτώματά του. Τα συμπτώματα αυτά χρειάζονται ώστε να μπορέσουμε να βρούμε στη συνέχεια τις συσχετίσεις μεταξύ των αντιπροτύπων που θα αναλύσουμε. Τα αντιπρότυπα που χρησιμοποιήσαμε ανήκουν σε τρεις βασικές ομάδες σύμφωνα με την προέλευσή τους (βλ. Πινακας 3.1) : (1) Wikipedia Antipatterns (2) Pattern Community Wiki Antipattern Catalogue (3) Software Project Management Blogs Πηγή Αντιπρότυπα Ποσότητα Wikipedia Antipatterns Pattern Community Wiki Antipattern Catalogue Software Project Management Blogs Death march, Groupthink, Smoke and Mirrors, Software Bloat Analysis Paralysis, Architecture by Implication, An Athena, Appointed Team, Architects Don t Code, Blowhard Jamboree, Corn Cob, Carbon Copy His Manager, Death By Planning, Decision By Arithmetic, Dry Waterhole, Egalitarian Compensation, Email Is Dangerous, Emperor s New Clothes, Fear Of Success, Glass Wall, Leading Request, Shoot The Messenger, Smoke And Mirrors, The BLOB, The Customers Are Idiots, Thrown Over The Wall, Train The Trainer, Untested But Finished, Yet Another Meeting Will Solve It Pardon my dust, Project Managers who write specs 4 25 2 Πίνακας 3.1 Πηγές αντιπροτύπων που χρησιμοποιήθηκαν στην OWL οντολογία. Αφού βρούμε για κάθε ομάδα χωριστά τα συμπτώματα κάθε αντιπροτύπου στη συνέχεια χρησιμοποιούμε το ευφυές σύστημα SPARSE ώστε να εντοπίσουμε τις συσχετίσεις μεταξύ των αντιπροτύπων της κάθε ομάδας. Για παράδειγμα στην πρώτη ομάδα με τα Wikipedia Antipatterns βρήκαμε με την βοήθεια του Protégé τα συμπτώματα των αντιπροτύπων Death March, Groupthink, Smoke and Mirrors και Software Bloat. Στην συνέχεια τα συμπτώματα αυτά που βρήκαμε στο πρώτο βήμα
με χρήση του Protégé, ερχόμαστε στο δεύτερο βήμα, με τη βοήθεια του SPARSE, να συσχετίσμουμε τα αντιπρότυπα στα οποία αντιστοιχούν. Το SPARSE, μας δίνει τις συσχετίσεις που υπάρχουν μεταξύ όλων των αντιπροτύπων της οντολογίας με βάση αυτά τα συμπτώματα. Τέλος χρησιμοποιήθηκε το εργαλείο PSM32 που αποτελεί και το κύριο εργαλείο αυτής της εργασίας, ώστε να φτιάξουμε τον DSM πίνακα των αντιπροτύπων διοίκησης έργων λογισμικού. Αυτό που υλοποιήθηκε ήταν η δημιουργία ενός πίνακα ο οποίος περιέχει τα αντιπρότυπα που βρήκε το ευφυές σύστημα SPARSE, και στη συνέχεια με την τεχνική διαχωρισμού (Partition), δόθηκε η χρονολογική σειρά με την οποία πρέπει να επιλυθούν τα συγκεκριμένα αντιπρότυπα σε ένα έργο λογισμικού. Στο υπόλοιπο του κεφαλαίου αυτού θα δούμε αναλυτικά την λειτουργία του κάθε εργαλείου. 3.1 PROTEGE Το Protégé είναι λογισμικό ανοιχτού κώδικα (http://protege.stanford.edu/) το οποίο βασίζεται σε JAVA και ουσιαστικά είναι ένας επεξεργαστής οντολογιών (Εικόνα 3.1.1). Είναι ένα πολύ χρήσιμο εργαλείο για την δημιουργία βασικών μοντέλων και εφαρμογών βασισμένων στην γνώση με την χρήση οντολογιών. Εσωτερικά στον πυρήνα του περιέχει ένα σύνολο από μοντελοποιημένες δομές γνώσης και ενέργειες που υποστηρίζουν την δημιουργία, οπτικοποίηση και τον χειρισμό οντολογιών. Υποστηρίζει δύο βασικούς τρόπους μοντελοποίησης των οντολογιών: Την μοντελοποίηση μέσω πλαισίων (Protégé-Frames) όπου δίνεται στον χρήστη η δυνατότητα να δημιουργήσει και να επεξεργαστεί οντολογίες οι οποίες είναι βασισμένες σε πλαίσια σύμφωνα με το Open Knowledge Base Connectivity protocol (OKBC) το οποίο είναι ένα application programming interface για πρόσβαση σε βάσεις γνώσης οι οποίες είναι αποθηκευμένες σε συστήματα αναπαράστασης γνώσης (knowledge representation systems- KRSs). To OKBC παρέχει ένα ενιαίο μοντέλο KRSs βασισμένο στο εννοιολογικό πλαίσιο των όρων κλάσεις, κληρονομικότητα, κτλ και έχει διαθέσιμες υλοποιήσεις σε Java, C, και Common Lisp.[5] Την μοντελοποίηση μέσω OWL (Protégé -OWL) όπου ο χρήστης έχει την δυνατότητα να δημιουργήσει και να επεξεργαστεί οντολογίες για τον Σημασιολογικό Ιστό (Semantic Web) και συγκεκριμένα για την Web Ontology Language (OWL) του W3C (World Wide Web Consortium). Μία τέτοια οντολογία μπορεί να περιέχει περιγραφές από κλάσεις, ιδιότητες και τα στιγμιότυπά τους. Έχοντας έτσι μια τέτοια οντολογία η σημασιολογική μορφή OWL υποδεικνυεί πώς να αντλήσεις τις λογικές της συνέπειες.[6] O Protégé-OWL επεξεργαστής δίνει δυνατότητες για φόρτωση και αποθήκευση οντολογιών τύπου OWL και RDF, επεξεργασία και οπτικοποίηση κλάσεων, ιδιοτήτων και κανόνων SWRL, ορισμό λογικών χαρακτηριστικών ώς
εκφράσεις τύπου OWL, εκτέλεση αιτιολογητών (reasoners) και ορισμένα άλλα χαρακτηριστικά. Το Protégé OWL έχει μια πολύ ευέλικτη αρχιτεκτονική και έτσι είναι ιδιαίτερα εύκολο να επεκταθεί σαν εργαλείο καθώς διαθέτει ένα ανοιχτού κώδικα Java API και μπορεί εύκολα να χρησιμοποιηθεί. Εικόνα 3.1.1 Στιγμιότυπο από το αρχικό περιβάλλον. Σημαντικό είναι να έχουμε μια σαφή ιδέα για την οντολογία που χρησιμοποιόυμε καθώς και για τις ιδιότητές της, καθώς είναι ουσιαστικά όλη η γνώση την οποία περιέχει το σύστημά μας και με βάση την οποία θα προχωρήσουμε στα επόμενα βήματα. Με το Protégé έχουμε την δυνατότητα να δημιουργούμε νέα πεδία και να εμπλουτίζουμε έτσι την οντολογία που χρησιμοποιούμε. Στα πλαίσια της συγκεκριμένης εργασίας ο εμπλουτισμός της οντολογίας δεν μας απασχόλησε. Θα πρέπει να λαμβάνουμε υπόψην μας κατα την επεξεργασία μιας οντολογίας ότι σημαντικό είναι να ακολουθούμε τους κανόνες και τα σενάρια της ήδη υπάρχουσας οντολογίας. Για παράδειγμα, ένας κανόνας στην περίπτωση των αντιπροτύπων είναι πως κάθε αντιπρότυπο, θα πρέπει να έχει τουλάχιστον μια αιτία, ένα σύμπτωμα και μια συνέπεια. Σε περίπτωση που δεν τηρούνται οι κανόνες που ήδη υπάρχουν θα προκληθούν προβλήματα ασυνέπειας στην οντολογία. Το Protégé στην εργασία αυτή χρησιμοποιήθηκε ώστε να βρούμε για κάθε αντιπρότυπο τα συμπτώματά του και δεν ασχοληθήκαμε με τον εμπλουτισμό της ήδη υπάρχουσας οντολογίας. Αυτό γίνεται με τη χρήση αυτής της οντολογίας την οποία εισάγουμε εμείς στο εργαλείο αρχικά όταν ξεκινάμε την εκτέλεσή του. Στην συνέχεια επιλέγοντας το αντιπρότυπο που μας ενδιαφέρει από την λίστα με τα διαθέσιμα αντιπρότυπα, μπορούμε να δούμε τα συμπτώματα, πρωτεύοντα και δευτερεύοντα, καθώς και αιτίες, συνέπειες αλλά και μια σύντομη περιγραφή του συγκεκριμένου αντιπροτύπου όπως φαίνεται στην Εικόνα 3.1.2. ΕΡΓΑΛΕΙΟ ΔΙΑΧΕΙΡΙΣΗΣ ΑΝΤΙΠΡΟΤΥΠΩΝ ΛΟΓΙΣΜΙΚΟΥ 35
Εικόνα 3.1.2 Παράδειγμα για συγκεκριμένο αντιπρότυπο. Το Protégé μας παρέχει μια σύντομη περιγραφή καθώς και τα συμπτώματα, τις αιτίες και τις συνέπειες του κάθε αντιπροτύπου.
3.2 SPARSE Το SPARSE (Symptom-based Antipattern Retrieval System Using Semantic Web Technologies) είναι ένα ευφυές σύστημα γνώσης το οποίο βασίζεται στις OWL οντολογίες, που σκοπό έχει να βοηθάει τους software project managers στην ανίχνευση αντιπροτύπων. Οι μάνατζερς γνωρίζοντας τα προβλήματα που εμφανίζονται στο project τους, που ουσιαστικά είναι τα συμπτώματα των αντιπροτύπων, χρησιμοποιούν την μεθοδολογία αυτή ώστε να εντοπίσουν τα αντιπρότυπα από τα οποία επηρεάζονται και να προχωρήσουν στις κατάλληλες λύσεις. Ένα από τα σημαντικότερα πλεονεκτήματα του SPARSE είναι πως μπορεί να εντοπίσει αντιπρότυπα τα οποία σχετίζονται άμεσα μετξύ τους, αλλά και αντιπρότυπα τα οποία συνδέονται σημασιολογικά μεταξύ τους. Αυτό γίνεται μέσω των οντολογιών στις οποίες βασίζεται όλη η ανάπτυξή του. Οι οντολογίες τις οποίες χρησιμοποιεί, ουσιαστικά περιέχουν τα αντιπρότυπα και τις μεταξύ τους σχέσεις μέσω συμπτωμάτων, συνεπειών και αιτιών. Οι συσχετίσεις αυτές μεταξύ των αντιπροτύπων διατυπώνονται μέσω ενός reasoner και στη συνέχεια μεταφράζονται στην COOL, την αντικειμενοστρεφή γλώσσα που χρησιμοποιείται στο CLIPS ( μηχανή παραγωγής κανόνων - production rule engine). Αυτό γίνεται για να γίνει εφικτή η συσχέτιση των αντιπροτύπων με βάση κάποια αρχικά συμπτώματά τους (σημασιολογικά). Το SPARSE δίνει την δυνατότητα στον χρήστη να επιλέγει από μια λίστα με τα διαθέσιμα αντιπρότυπα της οντολογίας αυτά τα οποία εμφανίζονται στο πρόγραμμά του και στην συνέχεια να βρίσκει τις συσχετίσεις που υφίστανται (βλ Εικόνα 3.2.1) Εικόνα 3.2.1 Αρχικό περιβάλλον SPARSE. ΕΡΓΑΛΕΙΟ ΔΙΑΧΕΙΡΙΣΗΣ ΑΝΤΙΠΡΟΤΥΠΩΝ ΛΟΓΙΣΜΙΚΟΥ 37
Στη συνέχεια το SPARSE επιστρέφει τις συσχετίσεις αυτές, διαχωρίζοντας τα αντιπρότυπα σε δύο κατηγορίες (Εικόνα 3.2.2) : τα Αντιπρότυπα που σχετίστικαν με βάση τα συμπτώματα (Symptom Matched Antipatterns) και τα Συσχετιζόμενα Αντιπρότυπα (Other Useful Antipatterns- relevant). Τα αντιπρότυπα της πρώτης κατηγορίας είναι αυτά τα οποία περιέχουν ένα ή περισσότερα από τα αντιπρότυπα τα οποία επέλεξε ο χρήστης, ενώ τα αντιπρότυπα της δεύτερης κατηγορίας είναι αυτά τα οποία προτείνει το SPARSE ως συσχετιζόμενα με βάση τον σημασιολογικό έλεγχο που κάνει, ουσιαστικά με βάση τις αιτίες και τις συνέπειες των αντιπροτύπων αυτών. Για να καταλήξει σε αυτές τις δυο κατηγορίες το SPARSE χρησιμοποιεί δύο αλγόριθμους οι οποίοι θα αναλυθούν στην συνέχεια. Εικόνα 3.2.2 Αποτελέσματα μετά το execute στο προηγούμενο παράθυρο. Οι δύο κατηγορίες αντιπροτύπων που επιστρέφονται. 1. Αντιπρότυπα που σχετίστηκαν με βάση τα συμπτώματα (Symptom Matched Antipatterns) Τα αντιπρότυπα αυτής της κατηγορίας είναι αυτά τα οποία περιέχουν τα συμπτώματα τα οποία επέλεξε ο χρήστης. Για να γίνει αυτή η συσχέτιση των αντιπροτύπων το SPARSE χρησιμοποιεί έναν αλγόριθμο ο οποίος με βάση κάποιους κανόνες παραγωγής οι οποίοι διασχίζουν τα αντικείμενα των αντιπροτύπων του COOL KB, επιλέγουν αυτά τα οποία αντιστοιχούν με τα συμπτώματα που επέλεξε ο χρήστης. Ο αλγόριθμος αυτός φαίνεται στην Εικόνα 3.2.3
Εικόνα 3.2.3 Αλγόριθμος για Αντιπρότυπα που σχετίστηκαν με βάση τα συμπτώματα (Symptom Matched Antipatterns) Ο αλγόριθμος αυτός για κάθε αντικείμενο αντιπροτύπου, έστω α, βρίσκει τα συμπτώματα (πρωτεύοντα, δευτερεύοντα, προτεινόμενα (implicit) και μηκατηγοριοποιημένα ) τα οποία υπάρχουν και στα συμπτώματα που επέλεξε αρχικά ο χρήστης. Στη συνέχεια για κάθε ένα από τα αντιπρότυπα που επιστρέφονται δημιουργείται και μια «βαθμολογία» (score) με βάση τον αριθμό των συμπτωμάτων που αντιστοιχίθηκαν και με βάση την οποία παρουσιάζονται τα αποτελέσματα σε φθίνουσα σειρά. 2. Συσχετιζόμενα Αντιπρότυπα (Other Useful Antipatterns) Tα αντιπρότυπα αυτής της κατηγορίας, είναι αντιπρότυπα τα οποία πιθανώς να είναι χρήσιμα αφού σχετίζονται με βάση αιτίες και συνέπειες. Ο αλγόριθμος που χρησιμοποιείται για την εύερση αυτών των αντιπροτύπων (Εικόνα 3.2.4) ουσιαστικά βρίσκει τα αντιπρότυπα τα οποία έχουν κοινές αιτίες ή συνέπειες με τα αντιπρότυπα που προέκυψαν με βάση τα συμπτώματα που εισήγαγε ο χρήστης. Σημαντικό είναι το γεγονός ότι δεν λαμβάνονται υπόψην οι διαφορετικές κατηγορίες που ανήκουν οι αιτίες και οι συνέπειες (πρωτεύοντα, δευτερέυοντα κτλ.) και θεωρούνται ίσες. Στο τέλος για την εμφάνιση των αποτελεσμάτων και πάλι λαμβάνεται υπόψην η βαθμολογία του κάθε αντιπροτύπου και παρουσιάζονται σε φθίνουσα σειρά. ΕΡΓΑΛΕΙΟ ΔΙΑΧΕΙΡΙΣΗΣ ΑΝΤΙΠΡΟΤΥΠΩΝ ΛΟΓΙΣΜΙΚΟΥ 39
Εικόνα 3.2.4 Αλγόριθμος για Συσχετιζόμενα Αντιπρότυπα (Other Useful Antipatterns). Το SPARSE στη συνέχεια παρέχει επεξηγήσεις (Εικόνα 3.2.5)για τον λόγο τον οποίο προτάθηκαν τα συγκεκριμένα αντιπρότυπα. Ουσιαστικά αναλύονται οι εξαρτήσεις-σχέσεις μεταξύ των αντιπροτύπων και το πώς κατέληξαν να προταθούν ως συσχετιζόμενα αντιπρότυπα. Εικόνα 3.2.5 Επεξηγηματικό παράθυρο
3.3 PSM32 To PSM32 (Εικόνα 3.3.1) είναι ένα εργαλείο το οποίο βασίζει την χρήση του στην μεθοδολογία των Πινάκων Σχεδίασης Δομής - DSM (Design Structure Matrix). Στην βιβλιογραφία συναντάται και ως Dependency Structure Matrix ή Problem Solving Matrix (PSM) ή ακόμα και Design Precedence Matrix. To PSM32 (http://www.problematics.com/default.asp), είναι ουσιαστικά ένα απλό εργαλείο το οποίο πραγματοποιεί την ανάλυση αλλά και την διαχείριση πολύπλοκων συστημάτων. Δίνει την δυνατότητα στους χρήστες να μοντελοποιήσουν, οπτικοποιήσουν και να αναλύσουν της εξαρτήσεις (dependencies) μεταξύ των οντοτήτων οποιουδήποτε συστήματος και να πάρουν αποφάσεις για την βελτίωση ή την αναδόμηση του συστήματος. Τα συστήματα που βρίσκει εφαρμογή η μέθοδος αυτή είναι αρκετά, όπως για παράδειγμα στην αρχιτεκτονική ενός προϊόντος ή στην σχεδίαση μηχανολογικών διαδικασιών. Από την μια μεριά, ως εργαλείο ανάλυσης συστημάτων παρέχει μια συμπαγή αναπαράσταση του συστήματος καθώς και μεθόδους για την αναπαράσταση των συσχετίσεων μεταξύ των στοιχείων του συστήματος. Από την άλλη, ως εργαλείο διαχείρισης δίνει την δυνατότητα για αναπαράσταση του συστήματος με μεθόδους που επιτρέπουν την ανάδραση και την κυκλική διεργασία των σχέσεων μεταξύ των οντοτήτων του συστήματος. Αυτό είναι και ένα από τα βασικά πλεονεκτήματά του, καθώς τα περισσότερα αντίστοιχα εργαλεία δεν προσφέρουν την δυνατότητα αυτή, η οποία όμως έχει καίρια σημασία για τα περισσότερα συστήματα. Εικόνα 3.3.1 Στιγμιότυπο από το περιβάλλον του PSM32, ένα απλό παράδειγμα Η μεθοδολογία DSM στην οποία στηρίζεται και η ανάπτυξη του εργαλείου αυτού, έχει στόχο να μοντελοποιήσει τις συσχετίσεις που υπάρχουν ανάμεσα στα στοιχεία που αλληλεπιδρούν σε μια διαδικασία. Στην περίπτωσή μας τα στοιχεία αυτά είναι τα αντιπρότυπα και η μεθοδολογία αυτή στοχεύει να παρουσιάσει τις ΕΡΓΑΛΕΙΟ ΔΙΑΧΕΙΡΙΣΗΣ ΑΝΤΙΠΡΟΤΥΠΩΝ ΛΟΓΙΣΜΙΚΟΥ 41
εξαρτήσεις που υπάρχουν μεταξύ των αντιπροτύπων καθώς και να βρει μια σειρά επίλυσής τους ώστε να μην δημιουργούν προβλήματα οι εξαρτήσεις αυτές. Περισσότερες λεπτομέρειες για την μεθοδολογία που χρησιμοποιεί ένα τέτοιο εργαλείο παρουσιάζονται στην επόμενη ενότητα με αναλυτικά παραδείγματα γύρω από την φιλοσοφία ανάπτυξης των εργαλείων αυτού του τύπου.
ΚΕΦΑΛΑΙΟ 4: Μ ΕΘΟΔΟΛΟΓΙΑ ΕΡΓΑΛΕΙΟ ΔΙΑΧΕΙΡΙΣΗΣ ΑΝΤΙΠΡΟΤΥΠΩΝ ΛΟΓΙΣΜΙΚΟΥ 43
ΚΕΦΑΛΑΙΟ 4: ΜΕΘΟΔΟΛΟΓΙΑ ΜΕΘΟΔΟΛΟΓΙΑ 4.1 ΑΝΑΛΥΣΗ ΒΗΜΑΤΩΝ Η διαδικασία που ακολουθήθηκε έγινε σε τρία βήματα, την ανάλυση των αντιπροτύπων, την συσχέτισή τους και την δημιουργία του πίνακα DSM. Βήμα 1 ο Ανάλυση αντιπροτύπων Στόχος του βήματος αυτού είναι να βρούμε τα συμπτώματα που αντιστοιχούν σε κάθε αντιπρότυπο, ώστε να μπορέσουμε στη συνέχεια να συσχετίσουμε τα αντιπρότυπα με βάση τα συμπτώματά τους. Για να γίνει αυτό, έγινε χρήση του εργαλείου Protégé. Λέγοντας ανάλυση των αντιπροτύπων στο βήμα αυτό, εννοούμε την εύρεση των συμπτωμάτων που χαρακτηρίζουν κάθε αντιπρότυπο της κάθε ομάδας από τις τρεις που αναλύουμε (βλ. Πίνακα 3.1). Με την χρήση του Protégé γίνεται μια πρώτη εξοικείωση με τα αντιπρότυπα που θα χρησιμοποιηθούν, παρατηρώντας την σύντομη περιγραφή που δίνει το εργαλείο αυτό και στην συνέχεια εξετάζοντας τα χαρακτηριστικά του κάθε αντιπροτύπου (αιτίες, συμπτώματα, συνέπειες). Στα πλαίσια της εργασίας αυτής βρίσκουμε για κάθε αντιπρότυπο, από κάθε ομάδα τα συμπτώματά του, με την χρήση του Protégé. Για να γίνει αυτό προηγήθηκε η εισαγωγή της οντολογίας που χρησιμοποιήσαμε στο εργαλείο αυτό κατά την εκκίνησή του (βλ. Εικόνα 4.1.1). Εικόνα 4.1.1 Αρχικό περιβάλλον Protégé. Επιλέγουμε την εισαγωγή της οντολογιάς που θέλουμε. ΕΡΓΑΛΕΙΟ ΔΙΑΧΕΙΡΙΣΗΣ ΑΝΤΙΠΡΟΤΥΠΩΝ ΛΟΓΙΣΜΙΚΟΥ 45
ΠΑΠΑΔΟΠΟΥΛΟΥ ΙΩΑΝΝΑ Έτσι στην συνέχεια επιλέγοντας από την λίστα με τα αντιπρότυπα που παρέχει το εργαλείο το αντιπρότυπο που θέλουμε να αναλύσουμε, βρίσκαμε τα συμπτώματα που του αντιστοιχούν και βλέπαμε μια σύντομη περιγραφή του αντιπροτύπου αυτού (βλ. Εικόνα 4.1.2). Για παράδειγμα για την πρώτη ομάδα αντιπροτύπων, δηλαδή τα Wikipedia Antipatterns, βρήκαμε για καθένα από τα αντιπρότυπα της ομάδας (Death march, Groupthink, Smoke and Mirrors και Software Bloat), τα συμπτώματα που του αντιστοιχούν. Εικόνα 4.1.2 Παράδειγμα για συγκεκριμένο αντιπρότυπο (Email is Dangerous). Στην τελευταία στήλη βλέπουμε τις αιτίες, τις συνέπειες και τα συμπτώματα που έχει το συγκεκριμένο αντιπρότυπο και στην συνέχεια μια σύντομη περιγραφή του.. Σημαντικό είναι να έχουμε μια σαφή ιδέα για τα αντιπρότυπα τα οποία υπάρχουν στην οντολογία μας καθώς και για τις ιδιότητές τους (συμπτώματα, αιτίες, συνέπειες). Με το Protégé έχουμε την δυνατότητα να δημιουργούμε νέα αντιπρότυπα και να εμπλουτίζουμε έτσι την οντολογία που χρησιμοποιούμε. Ορισμένες από τις ιδιότητες που μπορούμε να προσδιορίσουμε είναι ο τίτλος, η περιγραφή, causetocause, causetoconsequence, causetosymptom, symptomtocause, symptomtoconsequence,symptomtosymptom, consequencetoconsequence, hascause, hassymptom, hasconsequense. 46 ΕΡΓΑΛΕΙΟ ΔΙΑΧΕΙΡΙΣΗΣ ΑΝΤΙΠΡΟΤΥΠΩΝ ΛΟΓΙΣΜΙΚΟΥ
ΚΕΦΑΛΑΙΟ 4: ΜΕΘΟΔΟΛΟΓΙΑ Βήμα 2 ο Συσχέτιση αντιπροτύπων Στο δεύτερο βήμα έγινε η συσχέτιση των αντιπροτύπων με την χρήση του εργαλείου SPARSE [23]. Αυτό έγινε με την χρήση της ίδιας οντολογίας που χρησιμοποιήθηκε και στο προηγούμενο βήμα, την οποία πρέπει να κάνουμε εισαγωγή κατά την εκκίνηση του προγράμματος (βλ. Εικόνα 4.2.1). Εικόνα 4.2.1 Εισαγωγή οντολογίας. Το SPARSE στη συνέχεια, αφού φορτώσει την οντολογία που ζητήσαμε, μας δίνει μια λίστα με όλα τα συμπτώματα που υπάρχουν καταχωρημένα στην οντολογία, στην αριστερή στήλη του αρχικού περιβάλλοντος (βλ. Εικόνα 4.2.2). Εμείς στην συνέχεια επιλέξαμε τα συμπτώματα των αντιπροτύπων της κάθε ομάδας που βρήκαμε από το προηγούμενο βήμα. Έτσι το SPARSE μας επιστρέφει μια λίστα με τα συσχετιζόμενα αντιπρότυπα κατηγοριοποιημένα σε δύο ομάδες [24]. ΕΡΓΑΛΕΙΟ ΔΙΑΧΕΙΡΙΣΗΣ ΑΝΤΙΠΡΟΤΥΠΩΝ ΛΟΓΙΣΜΙΚΟΥ 47
ΠΑΠΑΔΟΠΟΥΛΟΥ ΙΩΑΝΝΑ Εικόνα 4.2.2 Αρχικό περιβάλλον SPARSE. Η στήλη στα αριστερά περιέχει όλα τα συμπτώματα που υπάρχουν στην οντολογία Τα αντιπρότυπα της πρώτης κατηγορίας είναι αυτά τα οποία περιέχουν ένα ή περισσότερα από τα αντιπρότυπα τα οποία επέλεξε ο χρήστης (αριστερή στήλη), ενώ τα αντιπρότυπα της δεύτερης κατηγορίας (δεξιά στήλη) είναι αυτά τα οποία προτείνει το SPARSE ως συσχετιζόμενα με βάση τον σημασιολογικό έλεγχο που κάνει, ουσιαστικά με βάση τις αιτίες και τις συνέπειες των αντιπροτύπων αυτών. Στην συνέχεια για το κάθε αντιπρότυπο που προτείνει το SPARSE εξετάζουμε τον λόγο που προτάθηκε χρησιμοποιώντας το επεξηγηματικό παράθυρο (βλ. Εικόνα 4.2.3) που εμφανίζει το SPARSE. Το επεξηγηματικό αυτό παράθυρο παρουσιάζει τις εξαρτήσεις - σχέσεις μεταξύ των αντιπροτύπων και γιατί αυτά προτάθηκαν ως συσχετιζόμενα αντιπρότυπα. Για παράδειγμα στην Εικόνα 4.2.3 μας εξηγεί πως το αντιπρότυπο Gilding the lilly συνδέεται με το αντιπρότυπο Death by Planning και το One size fits all μέσω των αιτιών και των συνεπειών τους. Αυτό σημαίνει πως το αντιπρότυπο Gilding the lilly προτάθηκε λόγω της συσχέτισης των αιτιών και των συνεπειών του με τις αιτίες και τα συμπτώματα που συναντήθηκαν και στα άλλα δυο αντιπρότυπα. 48 ΕΡΓΑΛΕΙΟ ΔΙΑΧΕΙΡΙΣΗΣ ΑΝΤΙΠΡΟΤΥΠΩΝ ΛΟΓΙΣΜΙΚΟΥ
ΚΕΦΑΛΑΙΟ 4: ΜΕΘΟΔΟΛΟΓΙΑ Εικόνα 4.2.3 Επεξηγηματικό παράθυρο για το «Gilding the lilly» Βήμα 3 ο Δημιουργία πίνακα DSM Στο τρίτο βήμα έγινε η δημιουργία των πινάκων με βάση την μεθοδολογία DSM (Εικόνα 4.3.1). Η μεθοδολογία αυτή εφαρμόστηκε με την βοήθεια του εργαλείου PSM32, για την δημιουργία και επεξεργασία των πινάκων. Στην μεθοδολογία DSM δημιουργούμε τον Πίνακα Σχεδίασης Δομής, όπου σε γραμμές και στήλες αντιστοιχούν τα ονόματα των συσχετιζόμενων αντιπροτύπων που πήραμε από το δεύτερο βήμα. Ο DSM όπως έχουμε ήδη αναφέρει είναι ένα εργαλείο μοντελοποίησης συστήματος το οποίο αναπαριστά τα στοιχεία του συστήματος και τις μεταξύ τους σχέσεις με ένα συμπαγή τρόπο και για αυτό τον λόγο έχει διαδοθεί ευρέως. Στην περίπτωσή μας μοντελοποιούμε τα αντιπρότυπα που εμφανίζονται σε ένα έργο, με βάση τις συσχετίσεις που υπάρχουν μεταξύ τους. Τα αντιπρότυπα αντιστοιχούν οιυσιαστικά στις γραμμές και στήλες του πίνακα και οι μεταξύ τους συσχετίσεις υποδηλώνονται με μηδενικά στα στοιχεία του πίνακα. Στη συνέχεια έγινε η συμπλήρωση των πινάκων, δηλαδή, τοποθετήθηκαν τα μηδενικά στα στοιχεία του πίνακα όπου υπήρχε συσχέτιση μεταξύ των αντιπροτύπων. Τέλος ακολουθήθηκε η τεχνική του Partitioning, η οποία μας βοηθάει να ελαχιστοποιήσουμε τις εξαρτήσεις που υπάρχουν μεταξύ των αντιπροτύπων ώστε να μπορέσουμε να δημιουργήσουμε την επιθυμητή σειρά επίλυσης των αντιπροτύπων. Τα αποτελέσματα της εφαρμογής της τεχνικής αυτής θα αναλυθούν στην Ενότητα 5. ΕΡΓΑΛΕΙΟ ΔΙΑΧΕΙΡΙΣΗΣ ΑΝΤΙΠΡΟΤΥΠΩΝ ΛΟΓΙΣΜΙΚΟΥ 49
ΠΑΠΑΔΟΠΟΥΛΟΥ ΙΩΑΝΝΑ Πίνακας 4.3.1 Παράδειγμα πίνακα DSM για Wikipedia Antipatterns. 50 ΕΡΓΑΛΕΙΟ ΔΙΑΧΕΙΡΙΣΗΣ ΑΝΤΙΠΡΟΤΥΠΩΝ ΛΟΓΙΣΜΙΚΟΥ
4.2 Η ΜΕΘΟΔΟΣ DSM Η μέθοδος αυτή αναπτύχθηκε για την μείωση των αλληλεξαρτήσεων μεταξύ των αντιπροτύπων. Όπως έχει ήδη αναφερθεί τα αντιπρότυπα λογισμικού τα οποία εμφανίζονται σε έργα λογισμικού συνήθως συσχετίζονται με άλλα αντιπρότυπα λογισμικού και σπάνια εμφανίζονται μεμονωμένα. Η συσχέτιση αυτή που υπάρχει ανάμεσα στα αντιπρότυπα δημιούργησε την ανάγκη να οπτικοποιηθούν αυτές οι εξαρτήσεις ώστε να μπορούν εύκολα να επιλυθούν [20]. Ένας μάνατζερ ο οποίος αναλαμβάνει ένα έργο λογισμικού, σίγουρα θα έρθει αντιμέτωπος με μια «οικογένεια» αντιπροτύπων, δηλαδή αντιπρότυπα τα οποία σχετίζονται μεταξύ τους, κυρίως με βάση τα συμπτώματα, και θα κληθεί να τα επιλύσει. Αναλύοντας όμως την συσχέτιση που επικρατεί μεταξύ των αντιπροτύπων και οπτικοποιώντας την σε έναν πίνακα δομής σχεδίασης, γίνεται φανερά πιο εύκολη η αντιμετώπιση αλλά και η επίλυση των αντιπροτύπων. Η τεχνική που θα ακολουθήσει στην συνέχεια, ο διαχωρισμός (Partition), ταξινομεί μάλιστα τα αντιπρότυπα με την χρονολογική σειρά την οποία θα πρέπει να επιλυθούν ώστε να μην υπάρχουν προβλήματα μεταξύ αντιπροτύπων που έπρεπε να επιλυθούν νωρίτερα αλλά δεν έχουν επιλυθεί ακόμα. Τα αντιπρότυπα τα οποία εξετάζονται είναι τα αντιπρότυπα διοίκησης έργων λογισμικού. Θεωρούμε πως τα αντιπρότυπα αυτά σχετίζονται μεταξύ τους με βάση τα συμπτώματα, τις αιτίες και τις συνέπειές τους. Η εφαρμογή της μεθοδολογίας DSM σε θέματα λογισμικού συναντήθηκε για πρώτη φορά στο κείμενο του Sullivan στο [15] για την αξιολόγηση προβλημάτων σχεδίασης και στην συνέχεια εφαρμόστηκε από τον Lopes στο [16] σε μια μελέτη που έκανε, ενώ εφαρμόστηκε πρακτικά στη συνέχεια, στην αρχιτεκτονική του Mozilla και του Linux από τον MacCormack στο [17]. Όπως έχει παρατηρηθεί, σε έργα λογισμικού όπου υπάρχουν υπερβολικές εξαρτήσεις μεταξύ των μελών τους προκύπτουν σοβαρά προβλήματα τόσο στον έλεγχο όσο και στην συντήρησή τους. Οι υπερβολικές αυτές εξαρτήσεις είναι ένδειξη κακού σχεδιασμού και συνεπώς θα υπάρχει εφαρμογή αντιπροτύπων διοίκησης έργων λογισμικού. Η μεθοδολογιά DSM έρχεται να δώσει μια λύση σε θέματα διοίκησης των έργων λογισμικού με αρκετές εξαρτήσεις μεταξύ των μελών τους. Με ένα εργαλείο (πχ Protégé) και με χρήση κατάλληλης οντολογίας, αντλούμε τις εξαρτήσεις μέσα από τον κώδικα και στην συνέχεια με κανόνες που εισάγουμε ξεχωρίζουμε τις εξαρτήσεις που επιτρέπονται, δηλαδή αυτές που δεν προκαλούν προβλήματα στη δομή και χρήση του συστήματος, από αυτές που ενδέχεται να προκαλέσουν πιθανά προβλήματα. Στη συνέχεια γίνεται ένας έλεγχος με βάση αυτές τις εξαρτήσεις για τυχόν παρεκκλίσεις από την επιτρεπτή δομή συναρτήσει του χρόνου. Αρχικά ο DSM σχεδιάστηκε για εφαρμογές που στόχευαν την βελτιστοποίηση της διαδικασίας ανάπτυξης προϊόντων. Στην διαδικασία αυτή μια σειρά από βήματα απαιτείται ώστε να ολοκληρωθεί. Τα βήματα αυτά είναι πιθανό να εξαρτώνται το ένα από το άλλο, είτε λόγω φυσικών αντικειμένων που πρέπει να μεταφερθούν από το ένα βήμα στο άλλο, είτε λόγω πληροφορίας που απαιτείται από ένα προηγούμενο βήμα σε ένα επόμενο ώστε να ολοκληρωθεί η διαδικασία. Η εξαρτήση αυτή των βημάτων, τονίζει την σημαντικότητα της διαδικασίας του DSM, καθώς αν τα βήματα αυτά εξαρτώνται το ένα από το άλλο, ενδέχεται να υπάρχουν πολλές κυκλικές εξαρτήσεις και τότε η ροή της πληροφορίας θα αντιμετώπιζε συνεχώς «ανεβοκατεβάσματα» και
ΠΑΠΑΔΟΠΟΥΛΟΥ ΙΩΑΝΝΑ άσκοπες επαναλήψεις των ίδιων βημάτων. Αναλύοντας τον DSM μπορούμε να οδηγηθούμε σε συντομότερα τόσο από άποψης χρόνου όσο και από άποψης κόπου έργα αφού αναπτύσσονται τεχνικές και στρατηγικές οι οποίες βασίζονται στην ροή πληροφορίας και στις απαιτήσεις-εξαρτήσεις που υπάρχουν. Πολλές φορές αναλύοντας τα τμήματα πληροφορίας που απαιτούνται για την ανάπτυξη ενός έργου, αλλά και τις εξαρτήσεις μεταξύ αυτών των τμημάτων οδηγούμαστε σε τμήματα κώδικα τα οποία εξαρτώνται το ένα από το άλλο χωρίς να ξέρουμε από ποιό να ξεκινήσουμε. Σε αυτό το σημείο μπορεί να προσφέρει σημαντική βοήθεια ο DSM. Με τον όρο DSM αναφερόμαστε τόσο στον πίνακα αναπαράστασης των εξαρτήσεων αλλά και στους αλγορίθμους αναδιοργάνωσης των εξαρτήσεων. Ας αναλύσουμε τον πίνακα DSM. Ο πίνακας αυτός είναι ένας απλός γειτονικός (adjacent) πίνακας με τα βήματα (tasks) να δίνουν ονόματα στους δύο άξονες, οριζόντιο και κατακόρυφο. Τα σημάδια στην i-οστή στήλη και την j-οστή γραμμή δείχνουν ότι το i-οστό βήμα εξαρτάται από το j-οστό βήμα. Δηλαδή για να προσδιοριστεί πλήρως το i-οστό βήμα χρειάζεται το j-οστό βήμα. Σε μερικές περιπτώσεις η ισχύς της εξάρτησης μεταξύ των βημάτων δίνεται με αριθμούς για σημάδια, στα πλαίσια όμως αυτής της εργασίας θα αναλυθούν μόνο δυαδικά σημάδια, δηλαδή 0 και 1. Σημαντικό είναι να τονίσουμε ότι δεν υπάρχουν εξαρτήσεις των βημάτων μεταξύ τους (i-οστό βήμα με i-οστό βήμα, δηλαδή στήλη i με γραμμή i) και συνεπώς η κύρια διαγώνιος δεν θα έχει ποτέ σημάδια. Στο παράδειγμα (Εικόνα 4.1) εξετάζοντας την στήλη1 βλέπουμε πως το βήμα 1 εξαρτάται από το βήμα 2. Εξετάζοντας την στήλη 2 βλέπουμε πως το βήμα 2 εξαρτάται από το βήμα 2 και από το βήμα 4. Εικόνα 4.1 Ένα απλό παράδειγμα για πίνακα DSM Για να αξιολογηθεί θετικά ο πίνακας DSM θα πρέπει να είναι άνω τριγωνικός, να έχει δηλαδή τα μηδενικά τοποθετημένα κάτω από την κύρια διαγώνιο (Εικόνα 4.2). Αυτό σημαίνει να μην υπάρχουν στοιχεία πάνω από την κύρια διαγώνιο. Με αυτό τον τρόπο διασφαλίζουμε ότι οι εξαρτήσεις που έχουμε είναι ακυκλικές. Για να διασφαλιστεί αυτό χρησιμοποιείται η τεχνική του διαχωρισμού (partition) που θα αναλύσουμε στην συνέχεια. Εικόνα 4.2 Άνω Τριγωνικός πίνακας. Παρατηρούμε πως δεν υπάρχουν σημάδια πάνω από την κύρια διαγώνιο. 52 ΕΡΓΑΛΕΙΟ ΔΙΑΧΕΙΡΙΣΗΣ ΑΝΤΙΠΡΟΤΥΠΩΝ ΛΟΓΙΣΜΙΚΟΥ
Στην τεχνολογία λογισμικού ο DSM βρίσκει μεγάλη εφαρμογή σε συστήματα με περίπλοκη αρχιτεκτονική και έτσι θα ασχοληθούμε με το πως εφαρμόζεται ο DSM όχι σε μια διαδικασία ανάπτυξης ενός προϊόντος αλλά σε ένα έργο λογισμικού. Έτσι στην περίπτωση του λογισμικού τον ρόλο των βημάτων(tasks) παίζουν οι ενότητες (modules) κώδικα. Μια σημαντική διαφοροποίηση έκανε ο Parnas στο [18] για την μείωση των κυκλικών εξαρτήσεων, όπου έθεσε τον όρο της επιπεδοποίησης (layering), εννοώντας ότι κάθε επίπεδο (layer), το οποίο αποτελείται από ενότητες (modules), οι ενότητες αυτές θα πρέπει να έχουν συσχετίσεις με άλλες ενότητες μόνο από το επίπεδο που ανήκουν και όχι με ενότητες άλλων επιπέδων. Με βάση τον όρο αυτό η τεχνική του διαχωρισμού εντοπίζει τα επίπεδα και βρίσκει τις κυκλικές εξαρτήσεις που υπάρχουν. Αυτό όμως στην πράξη δεν ακολουθείται πάντα γιατί δεν γίνεται όλα τα έργα λογισμικού να είναι κατασκευασμένα λαμβάνοντας υπόψην την επιπεδοποίηση, σίγουρα θα υπάρχουν λογισμικά που δεν είναι έτσι κατασκευασμένα. Αυτό δεν σημαίνει ότι για να εφαρμοστεί η τεχνική του DSM πρέπει όλα τα λογισμικά να είναι ακυκλικά. Η αξία της DSM προσέγγισης έγγυται στο ότι εντοπίζει τα σημεία όπου η αρχιτεκτονική του συστήματος παρεκκλίνει από αυτές τις κανονικοποιήσεις. Για να γίνει αυτός ο διαχωρισμός μεταξύ επιτρεπόμενων και μη επιτρεπόμενων παρεκκλίσεων χρησιμοποιούνται οι σχεδιαστικοί κανόνες (design rules). Οι κανόνες αυτοί εισάγωνται από τον χρήστη στο DSM και στη εφαρμόζονται ώστε να εντοπιστούν οι εξαρτήσεις οι οποίες δεν είναι επιτρεπτές. Στην περίπτωση του λογισμικού, κανόνες σχεδίασης μπορεί να είναι για παράδειγμα ότι μια βιβλιοθήκη ενός υποσυστήματος δεν έχει εξαρτήσεις με το υπόλοιπο της εφαρμογής, ή ένα άλλο παράδειγμα είναι ότι ορισμένα μόνο κομμάτια του πυρήνα ενός υποσυστήματος μπορούν να εξαρτώνται από ενότητες του GUI. Οι κανόνες αυτοί παίζουν σπουδαίο ρόλο καθώς ο συνεχής έλεγχός τους μπορεί να εντοπίσει παραβιάσεις που θα προκύψουν κατά την επέκταση ενός λογισμικού ή κατα την διαδικασία συντήρησής του. Έτσι οι παραβιάσεις εντοπίζονται την στιγμή που δημιουργούνται, γεγονός πολύ σημαντικό για την περαιτέρω ανάπτυξη του έργου. Για να εφαρμοστούν όλα αυτά στην πράξη σε ένα έργο διοίκησης λογισμικού, αρχικά χρειάζεται η δημιουργία του πίνακα DSM ο οποίος κάνει ρητή και κατανοητή την δομή της διαδικασίας. Για να επιτευχθεί αυτό χρειάζεται η δημιουργία του πίνακα να βασίζεται στην ανταλλαγή των πληροφοριών που απαιτούνται σε κάθε βήμα. Λαμβάνωντας υπόψην την πληροφορία που χρειάζομαι για να ολοκληρώσω την δουλειά μου δημιουργείται ο πίνακας γραμμή προς γραμμή. Στη συνέχεια με την πληροφορία πρέπει να παρέχω στους υπόλοιπους για να μπορούν να ολοκληρώσουν την δική τους δουλειά δημιουργείται ο πίνακας στήλη προς στήλη. Ακολουθώντας αυτά τα βήματα σύμφωνα με τον Stewart στο [19], οδηγούμαστε σε καλύτερα δομημένα projects, με καλύτερο διαμοιρασμό ευθυνών και σαφέστατα καλύτερα αποτελέσματα. ΕΡΓΑΛΕΙΟ ΔΙΑΧΕΙΡΙΣΗΣ ΑΝΤΙΠΡΟΤΥΠΩΝ ΛΟΓΙΣΜΙΚΟΥ 53
ΠΑΠΑΔΟΠΟΥΛΟΥ ΙΩΑΝΝΑ Ας δούμε αναλυτικά τους πίνακες DSM. Έστω ένα σύστημα το οποίο αποτελείται από δύο υποσυστήματα ή στοιχεία, το στοιχείο Α και το στοιχείο Β. Ένας γράφος (δίγραφος ή γράφος κατεύθυνσης) μπορεί να αναπτυχθεί για να αναπαραστήσουμε αυτό το σύστημα. Στον γράφο που χρησιμοποιούμε ένας κόμβος αναπαριστά ένα στοιχείο ενώ μια ακμή αντιπροσωπεύει την σχέση μεταξύ δύο κόμβων. Η φορά του βέλους της ακμής δείχνει την ροή πληροφορίας από το στοιχείο το οποίο ξεκινά, προς το στοιχείο που δείχνει το βέλος. Για την περιγραφή των σχέσεων μεταξύ των στοιχείων υπάρχουν τρεις βασικές κατηγορίες (Εικόνες 4.3, 4.4, 4.5), ο συνδυασμός των οποίων οδηγεί σε πιο πολύπλοκους γράφους [22]. Οι τρεις αυτές κατηγορίες είναι: η παράλληλη ή ταυτόχρονη (parallel - concurrent) η ακολουθιακή ή εξαρτημένη (sequential - dependent) και σε ζευγάρια ή αλληλοεξαρτώμενη (coupled - interdependent) Εικόνα 4.3 Γραφική αναπαράσταση Παράλληλης ή ταυτόχρονης σχέσης (parallel - concurrent) Στην παράλληλη συσχέτιση τα στοιχεία του συστήματος δεν αλληλεπιδρούν το ένα με το άλλο. Αυτό σημαίνει πως για να καταλάβουμε την συμπεριφορά του ενός δεν χρειάζεται να καταλάβουμε την συμπεριφορά του άλλου. Αν αναφερόμαστε σε ένα έργο λογισμικού τότε στην παράλληλη συσχέτιση το ένα στοιχείο δεν εξαρτάται από το άλλο, και συνεπώς δεν υπάρχει ανταλλαγή πληροφοριών μεταξύ τους. Αν αναφερόμαστε σε αντιπρότυπα, τότε το κάθε ένα από τα δύο αντιπρότυπα είναι ανεξάρτητο από το άλλο, δηλαδή δεν σχετίζονται με βάση τα συμπτώματά τους. Εικόνα 4.4 Γραφική αναπαράσταση Ακολουθιακής ή εξαρτημένης σχέσης (sequential dependent) Στην ακολουθιακή συσχέτιση το ένα στοιχείο επηρεάζει την συμπεριφορά του άλλου στοιχείου όμως μόνο μονόδρομα (uni- directional). Όπως φαίνεται και στην Εικόνα 4.4, οι παράμετροι που χρειάζεται το στοιχείο Β βασίζονται στις παραμέτρους που επιστρέφει το στοιχείο Α. Στην περίπτωση που αναφερόμαστε σε έργα λογισμικού αυτό σημαίνει πως θα πρέπει πρώτα να ολοκληρωθεί το στοιχείο Α ώστε να μπορέσει μετά να ξεκινήσει το στοιχείο Β. Στην περίπτωση των αντιπροτύπων 54 ΕΡΓΑΛΕΙΟ ΔΙΑΧΕΙΡΙΣΗΣ ΑΝΤΙΠΡΟΤΥΠΩΝ ΛΟΓΙΣΜΙΚΟΥ
αυτό σημαίνει πως θα πρέπει πρώτα να επιλυθεί το αντιπρότυπο Α ώστε να μπορέσει να επιλυθεί το αντιπρότυπο Β. Εικόνα 4.5 Γραφική αναπαράσταση Σε ζευγάρια ή αλληλοεξαρτώμενης σχέσης (coupled - interdependent) Τέλος στην σε ζευγάρια συσχέτιση η ροή της πληροφορίας είναι αμφίδρομη, δηλαδή το στοιχείο Α επηρεάζει την συμπεριφορά του στοιχείου Β, και το στοιχείο Β επηρεάζει την συμπεριφορά του στοιχείου Α. Αυτό μπορεί να συμβαίνει όταν για να προσδιορίσουμε πλήρως το στοιχείο Α, θα πρέπει πρώτα να γνωρίζουμε το στοιχείο Β, και αντίστροφα, για να προσδιορίσουμε πλήρως το στοιχείο Β θα πρέπει πρώτα να γνωρίζουμε πληροφορίες για το στοιχείο Α. Τέτοιου τύπου εξαρτήσεις καλούνται «Κυκλικές» ( Information Cycles ή Circuits ). Για την αναπαράσταση των γράφων αυτών με πίνακα θα χρησιμοποιήσουμε δυαδικούς τετραγωνικούς πίνακες ν x ν. Δυαδικός είναι ο πίνακας που τα στοιχεία τα οποία τον αποτελούν είναι 0 και 1, ενώ τετραγωνικός είναι ο πίνακας που έχει ίσο αριθμό γραμμών και στηλών. Οι πίνακες είναι ν x ν όπου ν ο αριθμός των γραμμών και ο αριθμός των στηλών (και ο αριθμός των κόμβων), και με μ μη μηδενικά στοιχεία (όπου μ ο αριθμός των ακμών που υπάρχουν στον γράφο). Η διαμόρφωση του γράφου γίνεται ως εξής: τα ονόματα των στοιχείων κόμβων τοποθετούνται στην αριστερή πλευρά του πίνακα ως ονόματα των γραμμών και στο πάνω μέρος του πίνακα ως ονόματα των στηλών. Μέσα στον πίνακα εάν υφίσταται σχέση μεταξύ του i-οστού στοιχείου και του j-οστού στοιχείου (δηλαδή εάν υπάρχει ακμή που συνδέει τους κόμβους i και j ) τότε στο τετράγωνο που αντιστοιχεί στο στοιχείο ij τοποθετείται ένα μηδενικό (σημάδι). Σε διαφορετική περίπτωση, όταν δεν υπάρχει συσχέτιση δηλαδή μεταξύ δύο στοιχείων το τετράγωνο αφήνεται κενό. Στην εργασία αυτή χρησιμοποιούμε το PSM32 το οποίο χρησιμοποιεί μηδενικά, σε άλλα εργαλεία όμως μπορεί να χρησιμοποιούνται άλλα σύμβολα όπως X ή. Στην αναπαράσταση που χρησιμοποιούμε η κύρια διαγώνιος αφήνεται κενή καθώς δεν υπάρχουν σχέσεις μεταξύ των ίδιων των στοιχείων. Στην συνέχεια (Εικόνες 4.6, 4.7, 4.8 ) δίνονται οι αναπαραστάσεις των σχέσεων των γράφων που είδαμε πιο πάνω με πίνακες όπως δημιουργήθηκαν στο PSM32. ΕΡΓΑΛΕΙΟ ΔΙΑΧΕΙΡΙΣΗΣ ΑΝΤΙΠΡΟΤΥΠΩΝ ΛΟΓΙΣΜΙΚΟΥ 55
ΠΑΠΑΔΟΠΟΥΛΟΥ ΙΩΑΝΝΑ Εικόνα 4.6 DSM αναπαράσταση Παράλληλης ή ταυτόχρονης σχέσης (parallel - concurrent) Στην παράλληλη αναπαράσταση τα βήματα μπορούν να εκτελεστούν ταυτόχρονα, χωρίς να περιμένουμε την ολοκλήρωση του ενός για να ξεκινήσει το άλλο. Εικόνα 4.7 DSM αναπαράσταση Ακολουθιακής ή εξαρτημένης σχέσης (sequential dependent) Στην ακολουθιακή αναπαράσταση τα βήματα εκτελούνται σειριακά. Για να ξεκινήσει δηλαδή η εκτέλεση του βήματος Β, πρέπει πρώτα να προηγηθεί η εκτέλεση του βήματος Α. Εικόνα 4.8 DSM αναπαράσταση Σε ζευγάρια ή αλληλοεξαρτώμενης σχέσης (coupled - interdependent) Όπως παρατηρούμε αν συγκρίνουμε την αναπαράσταση με γράφους και με πίνακες DSM, η αναπαράσταση με πίνακες είναι σαφέστερα πιο συμπαγής και παρέχει έναν συστηματικό τρόπο μοντελοποίησης των στοιχείων ενός συστήματος που μπορεί εύκολα να διαβαστεί ανεξάρτητα από το μέγεθος και την πολυπλοκότητα του συστήματος. Στο απλό αυτό παράδειγμα που αναλύσαμε η διαφορά αυτή δεν είναι τόσο μεγάλη. Συγκρίνοντας όμως τον γράφο της εικόνας 4.9 με τον πίνακα της εικόνας 4.10 η διαφορά είναι ξεκάθαρη. Σε πολύπλοκα συστήματα όπως είναι συνήθως τα συστήματα για έργα λογισμικού οι γράφοι δεν είναι καθόλου αποδοτικοί αφού ο αριθμός των κόμβων μπορεί να ξεπερνάει τις μερικές δεκάδες και οι εξαρτήσεις να είναι ανάλογα περισσότερες. Σε αντίθεση όμως με τους γράφους αναπαράστασης συσχετίσεων, οι πίνακες DSM δίνουν ξεκάθαρα την αναπαράσταση των σχέσεων που υπάρχουν στο συγκεκριμένο πρόγραμμα με εύκολο και κατανοητό τρόπο. 56 ΕΡΓΑΛΕΙΟ ΔΙΑΧΕΙΡΙΣΗΣ ΑΝΤΙΠΡΟΤΥΠΩΝ ΛΟΓΙΣΜΙΚΟΥ
Εικόνα 4.9 Γράφος εξαρτήσεων. Ας πάμε πάλι στο αρχικό μας πρόβλημα για την επίλυση των αντιπροτύπων διοίκησης σε έργα λογισμικού. Τη θέση των βημάτων τώρα παίρνουν τα αντιπρότυπα, και έτσι οι γραμμές και οι στήλες θα περιέχουν τα ονόματα των αντιπροτύπων που θα επιλύσουμε. Τα σημάδια (μηδενικά) θα αντιπροσωπεύουν τις εξαρτήσεις μεταξύ των αντιπροτύπων. Με αυτό τον τρόπο διαβάζοντας τον πίνακα κατα γραμμές, τα σημάδια που βρίσκονται στην πρώτη γραμμή, η οποία αντιπροσωπεύει το πρώτο αντιπρότυπο, εκπροσωπούν τα αντιπρότυπα τα οποία πρέπει να επιλυθούν πρώτα, ώστε να μπορεί να επιλυθεί στην συνέχεια το αντιπρότυπο της πρώτης γραμμής. Αντίστοιχα διαβάζοντας τον πίνακα κατά στήλες, τα σημάδια στην πρώτη στήλη αντιστοιχούν στο ποία αντιπρότυπα παίρνουν πληροφορίες από το αντιπρότυπο στην πρώτη στήλη, δηλαδή ποιά χρειάζονται την ολοκλήρωση του αντιπροτύπου αυτού ώστε να μπορέσουν να επιλυθούν. Έτσι σημάδια τα οποία βρίσκονται κάτω από την κύρια διαγώνιο, αντιπροσωπεύουν την κανονική ροή τροφοδότησης, δηλαδή πληροφορία η οποία μεταφέρεται «μπροστά» προς τα επόμενα στάδια (forward information), ενώ σημάδια πάνω από την κύρια διαγώνιο αντιπροσωπεύουν την ανατροφοδότηση δηλαδή πληροφορία η οποία πρέπει να μεταφερθεί προς προηγούμενα στάδια (feedback marks),και δείχνει πως ένα προηγούμενο στάδιο εξαρτάται από ένα επόμενο στάδιο (Εικόνα 4.11). ΕΡΓΑΛΕΙΟ ΔΙΑΧΕΙΡΙΣΗΣ ΑΝΤΙΠΡΟΤΥΠΩΝ ΛΟΓΙΣΜΙΚΟΥ 57
ΠΑΠΑΔΟΠΟΥΛΟΥ ΙΩΑΝΝΑ Εικόνα 4.10 Πίνακας DSM για την αναπαράσταση των εξαρτήσεων του γράφου στην εικόνα 4.9 Εικόνα 4.11 DSM αναπαράσταση ενός συστήματος μετά την εφαρμογή της τεχνικής του partitioning. 58 ΕΡΓΑΛΕΙΟ ΔΙΑΧΕΙΡΙΣΗΣ ΑΝΤΙΠΡΟΤΥΠΩΝ ΛΟΓΙΣΜΙΚΟΥ
Τα σημάδια που βρίσκονται πάνω από την κύρια διαγώνιο όπως είπαμε αντιπροσωπεύουν πληροφορία η οποία δεν είναι διαθέσιμη την στιγμή της εκτέλεσης του συγκεκριμένου βήματος, αυτό όμως σημαίνει πως για να ολοκληρωθεί το συγκεκριμένο βήμα θα γίνουν κάποιες υποθέσεις (assumptions) οι οποίες αφορούν την πληροφορία η οποία δεν είναι διαθέσιμη εκείνη την στιγμή. Έτσι στην συνέχεια όταν έρθει η νέα πληροφορία, με την εκτέλεση δηλαδή του βήματος που χρειαζόταν προηγουμένως, θα ξαναεκτελεστεί το βήμα με την απαραίτητη πληροφορία. Για να αποφευχθεί η επανάληψη αυτή χρησιμοποιούμε την τεχνική του Partition ώστε να μετατρέψουμε τον πίνακά μας σε άνω τριγωνικό. ΕΡΓΑΛΕΙΟ ΔΙΑΧΕΙΡΙΣΗΣ ΑΝΤΙΠΡΟΤΥΠΩΝ ΛΟΓΙΣΜΙΚΟΥ 59
ΠΑΠΑΔΟΠΟΥΛΟΥ ΙΩΑΝΝΑ 4.3 Η ΤΕΧΝΙΚΗ ΤΟΥ ΔΙΑΧΩΡΙΣΜΟΥ (PARTITIONING) Όπως έχουμε αναφέρει ήδη, τα αντιπρότυπα στην πράξη συνήθως εμφανίζονται συσχετισμένα με άλλα αντιπρότυπα και σπάνια μεμονωμένα. Οι συσχετίσεις με τις οποίες θα ασχοληθούμε είναι οι συσχετίσεις με βάση τα συμπτώματα. Σε έναν πίνακα Σχεδίασης Δομής (DSM), οι συσχετίσεις αυτές εμφανίζονται με σημάδια. Τα σημάδια αυτά στην περίπτωσή μας, όπου γίνεται χρήση του εργαλείου PSM32, είναι τα μηδενικά που εμφανίζονται μέσα στον πίνακα. Η τεχνική του Διαχωρισμού χρησιμοποιείται για να μειώσει ή να περιορίσει τα σημάδια που υπάρχουν πάνω από την κύρια διαγώνιο τα οποία είναι αυτά που ουσιαστικά μας δημιουργούν προβλήματα. Αξίζει να σημειωθεί και πάλι πως τα σημάδια που βρίσκονται πάνω από την κύρια διαγώνιο είναι ενδείξεις ανατροφοδότησης. Αυτό σημαίνει πως απαιτείται πληροφορία η οποία δεν είναι ακόμα διαθέσιμη. Στα αντιπρότυπα συγκεκριμένα, σημαίνει πως η επίλυση ενός αντιπροτύπου εξαρτάται από την επίλυση ενός δεύτερου αντιπροτύπου, το οποίο όμως δεν έχει επιλυθεί ακόμα. Ο πίνακας DSM είναι ενδεικτικός της σειράς με την οποία θα επιλυθούν τα αντιπρότυπα και έτσι πρακτικά αυτό σημαίνει πως το αντιπρότυπο από το οποίο χρειαζόμαστε πληροφορία είναι σε προηγούμενη γραμμή στον πίνακα DSM. Ουσιαστικά η τεχνική του Διαχωρισμού είναι η αναδιάταξη των γραμμών και των στηλών του DSM πίνακα ώστε να γίνει άνω τριγωνικός. Σε πολύπλοκα συστήματα αυτό δεν γίνεται απλά με την αναδιάταξη των γραμμών και των στηλών καθώς θα υπάρχουν συσχετίσεις παράλληλες ή σε ζευγάρια, και τέτοιες συσχετίσεις χρειάζονται την χρήση και ορισμένων άλλων τεχνικών [26]. Υπάρχουν αρκετοί αλγόριθμοι οι οποίοι εκτελούν την τεχνική του Διαχωρισμού με μικρές όμως διαφορές. Η κεντρική ιδέα βασίζεται στα ακόλουθα 4 βήματα: Βήμα 1 ο : Εντόπισε τα στοιχεία του πίνακα (στην περίπτωσή μας τα αντιπρότυπα), τα οποία για να επιλυθούν δεν χρειάζονται πληροφορία από κανένα άλλο στοιχείο (αντιπρότυπο). Τα στοιχεία αυτά μπορούν να εντοπιστούν εύκολα αφού είναι οι στήλες οι οποίες δεν έχουν κανένα σημάδι. Τοποθέτησε τα στοιχεία αυτά στο αριστερό μέρος του πίνακα (στις αριστερότερες στήλες). Κάθε αντιπρότυπο που μετακινείται σε άλλη στήλη, αφαίρεσέ το και από τον πίνακα. Επανέλαβε το βήμα αυτό για όλα τα στοιχεία του πίνακα. Βήμα 2 ο : Εντόπισε τα στοιχεία του πίνακα, τα οποία δεν μεταφέρουν πληροφορία σε άλλα στοιχεία. Τα στοιχεία αυτά μπορούν να εντοπιστούν με άδειες γραμμές. Τοποθέτησε τα στοιχεία αυτά στο δεξί μέρος του πίνακα. Κάθε στοιχείο που μετακινείται σε άλλη θέση, αφαίρεσέ το και από τον πίνακα. Επανέλαβε το βήμα αυτό για όλα τα στοιχεία του πίνακα. Βήμα 3 ο : Αν ο πίνακας δεν έχει άλλα στοιχεία τότε έχει διαχωριστεί επιτυχώς. Σε αντίθετη περίπτωση σημαίνει πως υπάρχουν κύκλοι στο σύστημα και πρέπει να ακολουθηθούν μέθοδοι για τον εντοπισμό τους. Στα πλαίσια της εργασίας αυτής δεν υπήρχαν συσχετίσεις σε ζευγάρια οπότε σταματάμε τον 60 ΕΡΓΑΛΕΙΟ ΔΙΑΧΕΙΡΙΣΗΣ ΑΝΤΙΠΡΟΤΥΠΩΝ ΛΟΓΙΣΜΙΚΟΥ
αλγόριθμο στο τρίτο βήμα χωρίς να προχωρήσουμε στον έλεγχο για τέτοιου είδους συσχετίσεις. Βήμα 4 ο : Εφαρμογή μεθόδων για εντοπισμό κύκλων. ΕΡΓΑΛΕΙΟ ΔΙΑΧΕΙΡΙΣΗΣ ΑΝΤΙΠΡΟΤΥΠΩΝ ΛΟΓΙΣΜΙΚΟΥ 61
ΠΑΠΑΔΟΠΟΥΛΟΥ ΙΩΑΝΝΑ 62 ΕΡΓΑΛΕΙΟ ΔΙΑΧΕΙΡΙΣΗΣ ΑΝΤΙΠΡΟΤΥΠΩΝ ΛΟΓΙΣΜΙΚΟΥ
Κ ΕΦΑΛΑΙΟ 5: Α ΠΟΤΕΛΕΣΜΑΤΑ ΕΡΓΑΛΕΙΟ ΔΙΑΧΕΙΡΙΣΗΣ ΑΝΤΙΠΡΟΤΥΠΩΝ ΛΟΓΙΣΜΙΚΟΥ 63
ΚΕΦΑΛΑΙΟ 5 ΑΠΟΤΕΛΕΣΜΑΤΑ ΕΡΓΑΛΕΙΟ ΔΙΑΧΕΙΡΙΣΗΣ ΑΝΤΙΠΡΟΤΥΠΩΝ ΛΟΓΙΣΜΙΚΟΥ 65
ΠΑΠΑΔΟΠΟΥΛΟΥ ΙΩΑΝΝΑ 5.1 ΕΦΑΡΜΟΓΗ ΜΕΘΟΔΟΛΟΓΙΑΣ Σε αυτή την ενότητα θα περιγράψω αναλυτικά τα αποτελέσματα που είχε η εφαρμογή της παραπάνω μεθοδολογίας στα αντιπρότυπα του Πίνακα 3.1. Σε κάθε μία από τις 3 πρώτες υποενότητες του κεφαλαίου αυτού θα περιγράφεται ο αρχικός πίνακας που δημιουργήθηκε με τις συσχετίσεις των αντιπροτύπων και στην συνέχεια ένας δεύτερος πίνακας θα μας δείχνει τα αποτελέσματα που είχε η εκτέλεση του Partition. 5.1.1 Wikipedia Antipatterns Η πρώτη ομάδα που ασχοληθήκαμε ήταν τα αντιπρότυπα που προέρχονται από την Wikipedia. Τα αντιπρότυπα αυτά είναι: Death march, Groupthink, Smoke and Mirrors και Software Bloat. Αρχικά χρησιμοποιήσαμε το Protégé ώστε να βρούμε για καθένα από αυτά τα αντιπρότυπα τα συμπτώματά του. Στη συνέχεια με βάση αυτά τα συμπτώματα βρήκαμε τις συσχετίσεις χρησιμοποιώντας το SPARSE και καταλήξαμε στα 39 αντιπρότυπα που φαίνονται στον πιο κάτω πίνακα (Πίνακας 5.1.1α). Πίνακας 5.1.1α Εκτέλεση για τα Wikipedia Antipatterns (αρχικός πίνακας με συσχετίσεις κατα στήλες) 66 ΕΡΓΑΛΕΙΟ ΔΙΑΧΕΙΡΙΣΗΣ ΑΝΤΙΠΡΟΤΥΠΩΝ ΛΟΓΙΣΜΙΚΟΥ
Τον πίνακα αυτό μπορούμε να τον διαβάσουμε κατά στήλες. Αυτό πρακτικά σημαίνει ότι για την δεύτερη στήλη, που αντιστοιχεί στο αντιπρότυπο The grand old duke of York υπάρχουν συσχετίσεις με τα αντιπρότυπα 3,4,5,6,7 και 8. Δηλαδή το αντιπρότυπο αυτό, με βάση τα αποτελέσματα του SPARSE σχετίζεται με τα αντιπρότυπα Smoke and Mirrors, Death by Planning, Pardon my Dust, Emperor s New Clothes, Software Bloat και Untested but finished. Την συσχέτιση αυτή την δείχνουν τα μηδενικά τα οποία έχουν τοποθετηθεί στα σημεία όπου ενώνεται η δεύτερη στήλη με τις γραμμές 3, 4, 5, 6, 7 και 8. Τα σημάδια αυτά αντιπροσωπεύουν την κανονική ροή τροφοδότησης, δηλαδή πληροφορία η οποία μεταφέρεται προς τα επόμενα στάδια (forward marks). Πηγαίνοντας όμως στην στήλη 10 με το αντιπρότυπο Architects don t code παρατηρούμε ότι υπάρχουν πάλι συσχετίσεις με τα αντιπρότυπα 3, 4, 5, 6, 7 και 8. Τώρα όμως τα μηδενικά που δείχνουν τις συσχετίσεις βρίσκονται πάνω από την κύρια διαγώνιο. Αυτό σημαίνει πως για να επιλυθούν τα αντιπρότυπα 3, 4, 5, 6, 7 και 8 χρειάζεται πρώτα να ολοκληρωθεί το αντιπρότυπο που βρίσκεται στην θέση 10, δηλαδή το Architects don t code, ώστε να μπορέσουν να επιλυθούν και αυτά στη συνέχεια. Έτσι τα σημάδια αυτά αντιπροσωπεύουν ανατροφοδότηση (feedback marks), δηλαδή πληροφορία η οποία πρέπει να μεταφερθεί προς προηγούμενα στάδια. Αυτό σημαίνει ότι τα αντιπρότυπα στις θέσεις 3, 4, 5, 6, 7 και 8 εξαρτώνται από το αντιπρότυπο στη θέση 10 [22], [25]. Αφού δημιουργήσαμε τον πιο πάνω πίνακα εφαρμόστηκε η τεχνική του Partitioning και τότε ο πίνακας πήρε την πιο κάτω μορφή (Πίνακας 5.1.1β). Πίνακας 5.1.1β Εκτέλεση για τα Wikipedia Antipatterns μετά το partition. ΕΡΓΑΛΕΙΟ ΔΙΑΧΕΙΡΙΣΗΣ ΑΝΤΙΠΡΟΤΥΠΩΝ ΛΟΓΙΣΜΙΚΟΥ 67
ΠΑΠΑΔΟΠΟΥΛΟΥ ΙΩΑΝΝΑ Στην μορφή αυτή τώρα του πίνακα παρατηρούμε ότι όλα τα μηδενικά μετά το Partition έχουν μεταφερθεί κάτω από την κύρια διαγώνιο και επίσης έχει αλλάξει η σειρά των γραμμών και των στηλών. Αν πάρατηρήσουμε πάλι το αντιπρότυπο Architects don t code παρατηρούμε ότι έχει μεταφερθεί στην 4 η στήλη με τα μηδενικά που του αντιστοιχούσαν να έχουν μεταφερθεί τώρα στο κάτω μέρος της κύριας διαγωνίου. Τώρα όμως βλέπουμε πως έτσι όπως έχει αλλάξει η μορφή του πίνακα το αντιπρότυπο Architects don t code έχει τοποθετηθεί πάνω από τα αντιπρότυπα στις θέσεις 3, 4, 5, 6, 7 και 8. Αυτό πρακτικά σημαίνει πως το αντιπρότυπο αυτό θα επιλυθεί πριν από τα αντιπρότυπα 3, 4, 5, 6, 7 και 8. Με αυτό τον τρόπο αποφεύγουμε την ανατροφοδότηση και τα προβλήματα που δημιουργεί. 5.1.2 Pattern Community Wiki Antipattern Catalogue Η δεύτερη ομάδα προέρχεται από το Pattern Community Wiki Antipattern Catalogue και περιλαμβάνει 25 αντιπρότυπα τα: Analysis Paralysis, Architecture by Implication, An Athena, Appointed Team, Architects Don t Code, Blowhard Jamboree, Corn Cob, Carbon Copy His Manager, Death By Planning, Decision By Arithmetic, Dry Waterhole, Egalitarian Compensation, Email Is Dangerous, Emperor s New Clothes, Fear Of Success, Glass Wall, Leading Request, Shoot The Messenger, Smoke And Mirrors, The BLOB, The Customers Are Idiots, Thrown Over The Wall, Train The Trainer, Untested But Finished και τέλος Yet Another Meeting Will Solve It. Με τον ίδιο ακριβώς τρόπο δημιουργήθηκε ο πίνακας 5.1.2α. Πίνακας 5.1.2α Εκτέλεση Pattern Community Wiki Antipattern Catalogue (αρχικός πίνακας με συσχετίσεις κατα στήλες) 68 ΕΡΓΑΛΕΙΟ ΔΙΑΧΕΙΡΙΣΗΣ ΑΝΤΙΠΡΟΤΥΠΩΝ ΛΟΓΙΣΜΙΚΟΥ
Στον πίνακα αυτό παρατηρούμε ότι υπάρχουν 27 σημάδια πάνω από την κύρια διαγώνιο. Αυτό σημαίνει πως έχουμε ανατροφοδότηση στα σημεία αυτά. Ας δούμε για παράδειγμα το αντιπρότυπο στην θέση 8, δηλαδή το Batteries not included. Παρατηρούμε πως το αντιπρότυπο αυτό συσχετίζεται με τα αντιπρότυπα Death by Planning και Architecture by implication. Τα δυό σημάδια στην στήλη 8 και στις γραμμές 2 και 3 ([2,8] και [3,8]) μεταφράζονται ως πληροφορία που απαιτείται από το αντιπρότυπο 8 ώστε να μπορέσουν να επιλυθούν τα αντιπρότυπα 2 και 3. Έχουμε δηλαδή πάλι ανατροφοδότηση. Ανατροφοδότηση έχουμε επίσης στις στήλες 4, 5, 6, 7, 9, 10, 11, 12, 13, 34 και 35. Για να επιλυθεί αυτό το πρόβλημα εφαρμόζουμε και πάλι Partitioning και παίρνουμε τον πίνακα 5.1.2β. Πίνακας 5.1.2β Εκτέλεση για τα Pattern Community Wiki Antipattern Catalogue μετά το partition Μετά το Partition βλέπουμε πως δεν υπάρχουν πλέον σημάδια πάνω από την κύρια διαγώνιο, γεγονός που σημαίνει πως δεν υπάρχει ανατροφοδότηση και συνεπώς αν τα αντιπρότυπα επιλυθούν με την σειρά που δείχνει ο πίνακας δεν θα έχουμε επαναλήψεις. Όταν δεν υπάρχουν σημάδια πάνω από την κύρια διαγώνιο, σημαίνει πως τα αντιπρότυπα μπορούν να επιλυθούν με την σειρά που τα βλέπουμε, χωρίς να εξαρτώνται από αντιπρότυπα που βρίσκονται σε επόμενες θέσεις του πίνακα. Εξετάζοντας το παράδειγμά μας με το αντιπρότυπο της θέσης 8, το Batteries not included, παρατηρούμε πως τώρα έχει μετακινηθεί σε πιο πάνω γραμμή, ΕΡΓΑΛΕΙΟ ΔΙΑΧΕΙΡΙΣΗΣ ΑΝΤΙΠΡΟΤΥΠΩΝ ΛΟΓΙΣΜΙΚΟΥ 69