Wednesday 15 June 2011

Let's GAME [Graphics Aided Model Engineering] (maybe UML ?)

Updated reference of this article here: http://www.facebook.com/note.php?note_id=210549415650401

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

Ο άνθρωπος ως ζωντανό πλάσμα χαίρεται να απολαμβάνει τη ζωή μέσα από εικόνες. Ακόμα και όταν ακούει κάτι του αρέσει να οραματίζεται, να φαντάζεται δηλαδή οπτικές εικόνες.

Γι' αυτό όταν θέλουμε να αναπαραστήσουμε κάτι θα χρησιμοποιήσουμε γραφήματα και γενικότερα visualisation! Είναι κάτι που μας ευχαριστεί ιδιαίτερα καθώς από μια όμορφη δομημένη εικόνα μπορούμε να καταλάβουμε, να αντιληφθούμε, ακόμα και να νιώσουμε αυτό που θέλουν να μας πούνε.
Χρησιμοποιώντας λοιπόν απλούς μαθηματικούς τύπους ή πίνακες με μετρήσεις που έχουμε συλλέξει είναι αναγκαίο να φανταστούμε το τι συμβαίνει, δηλαδή δεν μπορούμε άμεσα να το δούμε.
Ακόμα και αν κάνουμε μια γραφική παράσταση, αυτό είναι κάτι το στατικό διότι για μια επόμενη γραφική παράσταση θα πρέπει να επαναλάβουμε όλες τις πράξεις από την αρχή.

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

Όταν τώρα παμε να γράψουμε διαδικασίες που επιθυμούμε να εκτελεί ο υπολογιστής, επιστρέφουμε στο "χαρτί". Δηλαδή γράφουμε μια γλώσσα προγραμματισμού η οποία έχει τα ίδια μειονεκτήματα με την ελληνική ή οποιαδήποτε άλλη γλώσσα γραπτού λόγου. Είναι βαρετή! και δεν μεταδίδει το μήνυμα όπως ακριβώς θα θέλαμε. Αν προσέξετε πολύ πιο δύσκολο μεταφέρονται σε εσάς τα νοήματα μέσα από αυτό το κείμενο παρά από το διάγραμμα που φαίνεται στην αρχή του άρθρου. Οκ, ο αντίλογος είναι πως η γλώσσα προγραμματισμού έχει μια συγκεκριμένη δομή, και έναν χρωματικό κώδικα για να είναι πιο ευανάγνωστη. Αλλά από την άλλη και εδώ στα ελληνικά θα μπορούσα να προσθέσω κάποιες τονισμένες λέξεις, ή κάποιες υπογραμμισμένες λέξεις και ακολουθούντας μια πιστή σύμβαση να βοηθήσω τον εκάστοτε skim reader να περάσει μία στα γρήγορα το κείμενο εξάγοντας την κεντρική ιδέα.

Βέβαια όταν μιλάμε για μοντελοποίηση θα πρέπει να ξεχωρίσουμε δύο(2) βασικές κατηγορίες. Μοντελοποίηση της Πραγματικότητας και Μοντελοποίηση της Πληροφορίας. Διότι όταν προσπαθούμε να μοντελοποιήσουμε ένα πραγματικό σύστημα τότε γνωρίζουμε, συνήθως, ακριβώς που θέλουμε να φτάσουμε τι να περιμένουμε ως τελική απάντηση. Εδώ το σύστημα είναι λίγο έως πολύ περίπλοκο και θέλουμε να απλοποιήσουμε με τις κατάλληλες παραδοχές. Η μοντελοποίηση όμως της πληροφορίας από την μία πλευρά φαίνεται απλή διότι η πληροφορία είναι ήδη σε ψηφιακή μορφή, είναι κάτι που βρίσκεται στον ψηφιακό κόσμο και δεν είναι δύσκολο να εφεύρουμε δομές που να αποθηκεύουν αυτή την πληροφορία. Αλλά πως ακριβώς θα θέλαμε να επεξεργαστούμε? Γενικώς η πληροφορία είναι κάτι που μπορούμε να εκμεταλλευτούμε με διάφορους πολύπλοκους τρόπους για να εξάγουμε ένα μεγάλο πλήθος συμπερασμάτων και εκεί είναι που γίνεται δαιδαλώδες το σύστημα, επεξεργασίας της πληροφορίας.

Επομένως είτε έτσι είτε αλλιώς το σύστημα μπορεί να προκύψει αρκετά περίπλοκο.
Δεν θα ήταν υπέροχο η μοντελοποίηση του συστήματος να έχει μια οπτική διασταση ?!

Πολλοί μηχανικοί για παράδειγμα έχουν χρησιμοποιήσει τα διαγράμματα πεπερασμένων καταστάσεων (FSMs - Finite State Machines). Τα FSMs δηλώνουν μια διαδικασία που έχει μια αρχή, ένα τέλος ή κάποιο ατέρμονο loop. Όπως και να έχει σίγουρα μπορούν να αναπαρασταθούν από κώδικα ηλεκτρονικού υπολογιστή.

Ο σύγχρονος προγραμματισμός όμως προστάζει κάτι περισσότερο αντικειμενοστραφές και μάλιστα δόμηση σε ιεραρχίες τριών ή περισσότέρων (δυνητικά Ν) επιπέδων [N-tier models]. Οπότε σίγουρα τα State Diagrams δεν επαρκούν για να περιγράψουν αυτή την κατάσταση. Εδώ λοιπόν είναι που έρχεται η UML για να (προσπαθήσει) να λύσει το θέμα. H UML ήταν η προσπάθεια οργάνωσης της αναρχίας των διαγραμμάτων που επικρατούμε παλιότερα, γι' αυτό και λέγεται Unified Modelling Language.

Έτσι η UML προτείνει ένα πλήθος από διαγραμμάτα τα οποία μπορούν να χρησιμοποιηθούν συνδυαστικά ή μεμονωμένα για να περιγράψουν ένα σύστημα είτε αναφερόμαστε στο χώρο των businessman είτε αναφερόμαστε στο χώρο του προγραμματισμού λαμβάνοντας υπόψη πως ένα project περιλαμβάνει τόσο ανθρώπους με τεχνική αλλά και όχι κατάρτιση.

Τα διαγράμματα της UML όπως για παράδειγμα τα use-case diagrams που προορίζονται να περιγράψουν τις διαδικασίες ενός προγράμματος από την πλευρά του χρήστη χωρίς όμως να έχουν την τυποποίηση που θα μπορούσε να εκμεταλλευτεί ένας Η/Υ για να τα αξιοποιήσει περαιτέρω δεν μας αφορούν! Το γιατί δεν μας αφορούν είναι απλώς το γεγονός ότι δεν συμμετέχουν στην μοντελοποίηση του συστήματος. Είναι σαν να λέγαμε ένα mind-mapping, σκεπτόμενοι διάφορες ιδέες πάνω στο χαρτί από την πλευρά του χρήστη χωρίς να μπαίνουμε σε μεγαλύτερη λεπτομέρεια.

Υπάρχουν όμως τα διαγράμματα όπως τα Class Diagrams, τα Sequence Diagrams, τα Collaboration Diagrams, τα Activity Diagrams, τα Package Diagrams και άλλα τα οποία μπορούν να τυποποιηθούν και να έχουν μια συγκεκριμένη δομή.
Για παράδειγμα έχετε ένα σωρό αντικείμενα, μιας και γράφετε αντικειμενοστραφή προγραμματισμό, και αυτά αντιστοιχούν κάποιες ιδιότητες και κάποιες μεθόδοι. Οπότε γράφετε στον κώδικα "class..."
Επίσης το ένα αντικείμενο σχετίζεται και συνεπώς χρησιμοποιεί το άλλο οπότε αυτοί είναι οι συσχετισμοί μεταξύ των αντικειμένων.
Άρα πολύ ωραία μπορεί κάποιος να αναπαραστάσει αυτές τις κλάσεις σε ένα Class Diagrams.
Yahooooo! Τώρα θα πρέπει να αισθάνεται πολύ ωραία που μπορεί να δει τον κώδικα του οργανωμένο σε ένα διάγραμμα.
Αλλά αυτό το διάγραμμα πόσο συντηρήσιμο θα είναι στο μέλλον? Αν αλλάξει κάτι στον κώδικα θα μπει στον κόπο να ενημερώσει το διάγραμμα? ή αν κάνει πολλές αλλαγές στο διάγραμμα, οι οποίες με τη σειρά τους μπορεί να έχουν επίπτωση σε πολλά μέρη στα διαφορετικά αρχεία του κώδικα θα θυμηθεί να κάνει αυτές τις αλλαγές?
Μιλάμε για άνθρωπο... ειναι αυτονόητο να κάνει λάθος κάποια στιγμή. Επίσης μιλάμε για άνθρωπο, πότε μάλλον θα βαρεθεί την διπλή δουλειά σε κάποιο σημείο, θα αφήσει το διάγραμμα και θα συνεχίσει απλά να γράφει κώδικα!
Και έτσι γίνονται πολλά από τα προγράμματα σήμερα. Συνήθως υπάρχουν 2 άνθρωποι, ένας ο προγραμματιστής στον κώδικα και ένας ο αναλυτής στο διάγραμμα. Αν είχαμε με έναν άνθρωπο πρόβλημα μην περιμένετε να διορθώσουμε την κατάσταση με δύο ανθρώπους, τουλάχιστον θα την επιβαρύνουμε εις διπλούν!
Τι θα θέλαμε?? Φυσικά να γίνεται ένας συγχρονισμός μεταξύ του Class Diagram και του κώδικα.
Τα καλά νέα είναι πως υπάρχουν αξιόλογες προσπάθειες από διάφορα εργαλεία για να προσφερθεί αυτή η δυνατότητα.

Μια αναλογία για να γίνει αντιληπτό το θέμα και σε λοιπούς μηχανικούς είναι η εξής: Φανταστείτε να σχεδιάζατε ένα διάγραμμα στο Autocad. Αυτό το διάγραμμα για να εξομοιώσετε θα πρέπει να γράψετε αρκετά μπελαλίδικο κώδικα στο spice. Από την άλλη προγράμματα όπως το Electronics Workbench ή το Simulink της Matlab θα σας ανάγκαζαν μεν να ξανασχεδιάσετε το ηλεκτρικό / ηλεκτρολογικό διάγραμμα στην αντίστοιχο εργαλείο αλλά θα μπορούσαν να το εξομοιώσουν ώστε να μην έχετε απλά ένα "νεκρό" διάγραμμα αλλά κάτι "ζωντανό" μπροστά στην οθόνη του υπολογιστή σας.
Επόμενο βήμα φυσικά θα ήταν μετά την επιτυχή εξομοίωση να ζητήσετε από ένα ρομποτ να τραβήξει τα καλώδια ή να χαράξει τις ηλεκτρικές διαδρομές πάνω στην πλακέτα αυτόματα χωρίς να χρειάζεται να μπείτε σε επιπλέον κόπο. Σίγουρα πιο δύσκολο να περάσει κανείς από τον ψηφιακό κόσμο στον πραγματικό (με χρήση ρομποτ) αλλά ευτυχώς στον κόσμο της πληροφορίας που είναι ήδη ψηφιακός δεν έχουμε τέτοοια προβλήματα. <-- αυτό θα πει πραγματική αυτοματοποίηση

Γυρίζοντας τώρα στα διαγράμματα της UML είναι ενδιαφέρον ότι έχουμε περιγράψει (με class diagrams) τι υπάρχει, τι μπορεί να κάνει και ποιοι είναι οι συσχετισμοί αλλά δεν έχουμε την δυναμική του συστήματος. Πως αυτά τα αντικείμενα ενεργούν δυναμικά στο χρόνο. Δηλαδή σκεφτείτε πως χρησιμοποιείτε ένα σύστημα. Εκτελείτε μια ενέργεια σε μια ιστοσελίδα (web application). Για να το κάνουμε τελείως απλοικό κάνετε κλικ σε ένα link. Με άλλα λόγια είστε ο user και ενεργείται με ένα user request. Γίνονται οι όποιες ενέργειες. Ποια αντικείμενα επηρεάστηκαν από αυτές? Μήπως αυτές οι ενέργειες έχουν κάποια αποτελέσματα που ΘΑ επηρεάσουν άλλα αντικείμενα ανάλογα με τις επόμενες επιλογές.
Δηλαδή όταν θα τελειώσει το κλικ που πατήσατε, ποιες θα είναι οι επόμενες δυνατότητες που θα έχετε? Τι θα μπορεί να σας δοθεί να κάνετε περαιτέρω κλικ? κάνοντας ένα νέο user request.

Για να δείτε μια πορεία που θα διαγραψετε αυτήν μπορεί να ακολουθήσει ο χρήστης μπορείτε κάλλιστα να απευθυνθείτε στον κώδικα. Δηλαδή να κάτσετε να ψάξετε μία-μία τις μεθόδους των αντικειμένων, ποια μέθοδος καλεί ποια μέθοδο, που υπάρχουν τα if για να δείτε τις διακλαδώσεις κτλ.
Όλα αυτά διαγράφουν μια αλληλουχία ενεργειών μέσα στο μυαλό σας. Επειδή έχετε γράψει πάρα πολύ κώδικα και θα θέλατε αυτές οι ενέργειες να φαίνονται σε ένα διάγραμμα κάθεστε και σχεδιάζετε ένα sequence diagram ή ένα collaboration diagram.
Για ακόμα μια φορά βρισκόμαστε στο ίδιο δίλημμα και η απάντηση είναι η ίδια. Θέλουμε τα διαγράμματα αυτά να είναι τυποποιημένα κατά τέτοιο τρόπο ώστε να μεταφράζονται απευθείας σε κώδικα. Μόνο αυτό το σύστημα είναι sustainable!

Δυστυχώς η έως τώρα εμπειρία μου με τα εργαλεία που μεταφράζουν UML σε κώδικα είναι απογοητευτική όσον αφορά τα τελευταία διαγράμματα.
Δεν γνωρίζω αν είναι οι ίδιες οι προδιαγραφές της UML που προσφέρουν πάρα πολλές, περισσότερες από όσες θα έπρεπε, δυνατότητες ή απλά είναι τα εργαλεία που δεν έχουν δομηθεί σωστά για να είναι φιλικά προς τον αγαπητό προγραμματιστή ο οποίος θέλει κάτι πιο abstract και πιο απτό, και πιο φανερό και πιο αντιληπτό όπως είναι ένα διάγραμμα να αντικαταστήσει ένα μεγάλο μέρος του κώδικα που γράφει. Όχι το σχεδιαστικό πρόγραμμα να γίνει ένα μεγάλο overhead, με long learning curve!

Προγραμματίζω σε γλώσσα προγραμματισμού PHP, δεν το κρύβω, και θα συνεχίσω να επιμένω σε αυτή τη γλώσσα διότι είναι η μόνη που γράφτηκε από προγραμματιστές για προγραμματιστές. H PHP νιώθει περισσότερο τον προγραμματιστή που θέλει απλά να πει στο καταραμένο το μηχάνημα (το γνωστό σε όλους PC) πως να εκτελέσει κάποια διαδικασία και όχι να εμπλακεί με τις λεπτομέρειες της υλοποίησης. Άλλες γλώσσες προγραμματισμού όπως η Java ήταν ισχυρές παλιότερα αλλά όπως φαίνεται πλέον η μία γλώσσα κλέβει ιδέες από την άλλη με αποτέλεσμα να ακολουθούν μια παράλληλη πορεία και να είναι πλέον "θρησκευτικό" το ζήτημα για το ποια ακριβώς θα ακολουθηθεί. Δεν αναφέρω καν τις γλώσσες όπως η C# ή η Visual Basic που ανήκουν στην Microsoft η οποία πασχίζει να κρατήσει το δικό της θεό (κάποτε τον έλεγαν Bill Gates, για σήμερα δεν είμαι σίγουρος).

Άρα το θέμα είναι να χρησιμοποιηθούν εργαλεία τα οποία να προσφέρουν μετατροπή των UML διαγραμμάτων σε PHP γλώσσα αλλά και αντίστροφα!
Ρίξτε μια ματιά σε αυτό το link: http://en.wikipedia.org/wiki/List_of_Unified_Modeling_Language_tools
Καταρχάς όσα εργαλεία έχουν να ανανεωθούν πολύ καιρό δεν θεωρούνται αξιόπιστα. Από την άλλη δεν υπάρχουν πολλά εργαλεία που να μπορούν να παράγουν PHP.

Το open-source Dia Diagram φαίνεται ενδιαφέρον αλλά αν χρησιμοποιήσει κανείς το εργαλείο θα δει πως δεν υπάρχει κανενός είδος τυποποίηση που να αποτρέπει τα λάθη. Και γενικώς δεν υπάρχει η αναμενόμενη οργάνωση, με packages κτλ, ώστε να χρησιμοποιηθεί για κάτι σοβαρό

Επόμενο υποψήφιο εργαλείο είναι το Software Ideas Modeller το οποίο όμως δεν φαίνεται να έχει κάποια υψηλή υποστήριξη, δηλαδή έχει μικρή κοινότητα χρηστών (μόνο 400 likes στο facebook πχ αυτή τη στιγμή) και το μικρό του μέγεθος (2ΜΒ setup.exe) σε σχέση με τις δυνατότητες που προσφέρει ενώ παράλληλα διαθέτει τόσα πολλά γραφικά προβληματίζει. Δεν φαίνεται να έχει δοκιμαστεί αρκετά ώστε να ξεχωρίσει.

Επιπλέον όμως θα θέλαμε τα εργαλεία μας να κάνουν και το reverse engineering. Δηλαδή να σχηματίζουν UML διαγράμματα από έτοιμο PHP κώδικα. Αυτό είναι μια πολύ σπουδαία δυνατότητα και επιπλέον είναι ένα ισχυρό σημείο βαρύτητας στη σύγκριση των εργαλείων διότι σημαίνει πως η γλώσσα PHP έχει δουλευτεί επαρκώς.
Με αυτές τις προδιαγραφές διακρίνονται δύο εργαλεία:

Το Bouml είναι το open source εργαλείο του γάλλου Bruno Pages. Το κυριότερο μειονέκτημα του εργαλείου είναι πως ο δημιουργός του, σταμάτησε να το αναπτύσσει επειδή δέχονταν επίθεση από άλλους (περισσότερα στην ιστοσελίδα του)
Αν και το Bouml βρίσκεται σε ένα πολύ καλό σημείο ανάπτυξης εντούτοις υπάρχει αρκετή δουλειά που θα μπορούσε να γίνει ακόμα στην αυτόματη μετατροπή του κώδικα. Από την άλλη ενώ υπάρχουν πολλές αναφορές στο internet για το εν λόγω project δεν υπάρχουν αρκετά tutorial για το πως θα μπορούσε να χρησιμοποιήσει κανείς τα υπόλοιπα διαγράμματα πέρα από τα class diagrams.
Ακόμα και ο ίδιος ο δημιουργός έχει δηλώσει email στην ιστοσελίδα του που δεν υπάρχει πλέον.
Άρα θα ήταν ένα μικρό ρίσκο να πει κανείς πως ασχολείται επαγγελματικά με το συγκεκριμένο εργαλείο εκτός και αν είχε φιλοδοξίες να γράφει C++ και να το εξελίξει παραπέρα.

Τέλος ερχόμαστε να αναφερθούμε σε ένα από τα προγράμματα που δεσπόζουν ως η ναυαρχίδα των UML προγραμμάτων. Το Visual Paradigm. Βέβαια ως ναυαρχίδα δεν είναι καθόλου open source απεναντίας είναι ένα πολύ ακριβό πρόγραμμα για έναν ιδιώτη, αλλά όχι τόσο ακριβό για μια εταιρεία.
Αν και οι δυνατότητες του προγράμματος είναι εμφανείς, ίσως εκεί είναι και το μειονέκτημά του. Οι δυνατότητες είναι πολύ εμφανείς! Φαίνονται όλες, πάνω στο ίδιο interface, υπάρχουν χιλιάδες επιλογές ακριβώς όπως το visual studio ή άλλα τέτοια windows IDEs τα οποία είναι εσκεμμένα δύσχρηστα.
Ο δόλος βρίσκεται στο γεγονός πως κρατώντας την learning curve long μπορούν να δικαιολογήσουν μαθήματα και σεμινάρια (ακόμα και ετήσιας διάρκειας!) με σκοπό την μεγιστοποίηση του κέρδους!
Οπότε και εδώ η χρήση των υπολοίπων διαγραμμάτων (πέρα των class diagrams) και πως μπορούν αυτά να αξιοποιηθούν για την αυτόματη παραγωγή, ενός μέρους έστω, του κώδικα σίγουρα ΔΕΝ είναι προφανής.
Από την άλλη ο PHP κώδικας που παράγεται από το Visual Paradigm φαίνεται να είναι ο καλύτερος σε σχέση με τα υπόλοιπα εργαλεία πράγμα που εδραιώνει την θέση του.

Τελικώς η πρώτη μου εμπερεία μου με την πρακτική εφαρμογή της UML είναι περισσότερο απογοητευτική παρά αποκοδιμιτική. Βέβαια όλα αυτά είναι απλώς τεχνικά θέματα που είναι ζήτημα χρόνου αλλά και βούλησης ώστε να επιλυθούν και να βγει στην επιφάνεια η πραγματική δύναμη της UML και πως η μοντελοποίηση μέσω visualisation μπορεί διευκολύνει και συνάμα να επιτυχάνει την ανάπτυξη πολύπλοκων, με τα σημερινά δεδομένα, μοντέλων.

Αν έχετε ασχοληθεί και επιθυμείτε μπορείτε να καταθέσετε την δική σας εμπειρία από την χρήση του BOUML, του Visual Paradigm ή κάποιου άλλου PHP <-> UML εργαλείου (:

Επιμέλεια: Γιώργος Πληγορόπουλος
 

Applied Ideas Copyright © 2010
George Pligor - Stergios