Στο περασμένο συνέδριο JavaOne, παρακολούθησα μια συνεδρία στην οποία ο ομιλητής μίλησε για το σχέδιο της Sun για την εικονική μηχανή Java (JVM). Σε αυτήν την ομιλία, ο ομιλητής δήλωσε ότι η Sun σχεδίαζε, μεταξύ άλλων, να εξαλείψει τα τρέχοντα σημεία συμφόρησης στην εικονική μηχανή, όπως η βραδύτητα των συγχρονισμένων μεθόδων και το κόστος απόδοσης της συλλογής απορριμμάτων. Ο ομιλητής δήλωσε τον στόχο της Sun: Με τις βελτιώσεις στο JVM, οι προγραμματιστές δεν θα χρειαστεί να σκεφτούν για την αποφυγή συμφόρησης εικονικής μηχανής όταν σχεδίασαν τα προγράμματά τους. θα χρειαζόταν μόνο να σκεφτούν να δημιουργήσουν "καλά αντικειμενοστραφή, ασφαλή νήματα σχέδια".
Ο ομιλητής, ωστόσο, δεν ανέλυσε αυτό που πραγματικά αποτελεί ένα αντικειμενοστρεφή, ασφαλές νήμα. Αυτός είναι ο στόχος αυτής της νέας στήλης. Μέσα από τα άρθρα του Τεχνικές σχεδιασμού στήλη, ελπίζω να απαντήσω στην ερώτηση: Τι είναι ο καλός σχεδιασμός προγράμματος Java και πώς δημιουργείτε;
Η εστίαση της στήλης
Η εστίασή μου σε αυτήν τη στήλη θα είναι η παροχή πρακτικών τεχνικών σχεδιασμού που μπορείτε να χρησιμοποιήσετε στις καθημερινές σας εργασίες προγραμματισμού. Θα υποθέσω ότι είστε εξοικειωμένοι με τη γλώσσα Java και τα API. Σκοπεύω να συζητήσω τεχνικές, ιδέες και οδηγίες που θα σας βοηθήσουν να χρησιμοποιήσετε τη γλώσσα και τα API στα πραγματικά σας προγράμματα.
Για να σας δώσω μια ιδέα για το τι να περιμένετε σε αυτήν τη στήλη, ακολουθεί μια λίστα με τα είδη των θεμάτων που σκοπεύω να γράψω:
- Τρόποι βελτίωσης του σχεδιασμού των αντικειμένων σας
- Δημιουργία ιεραρχιών τάξης
- Σε τι χρησιμεύουν οι διεπαφές;
- Ποιο είναι το σημείο του πολυμορφισμού;
- Επιλογή μεταξύ σύνθεσης και κληρονομιάς
- Σχεδιασμός για ασφάλεια νήματος
- Σχεδιασμός για συνεργασία νήματος
- Η αρχιτεκτονική Model / Controller / View που χρησιμοποιείται από τις κλάσεις JFC
- Σχεδιαστικά πρότυπα
Μεγάλο μέρος του υλικού που έχει ήδη γραφτεί για τη σχεδίαση λογισμικού μπορεί να εφαρμοστεί στην Java. Υπάρχουν πολλές μεθοδολογίες σχεδιασμού πλήρους δυνατότητας και παχιά εγχειρίδια που τα περιγράφουν. Σε αυτήν τη στήλη δεν θα προωθήσω τη μεθοδολογία σε σχέση με την άλλη. Ούτε θα προωθήσω μια νέα μεθοδολογία της δικής μου εφεύρεσης. Αντίθετα, θα αντλήσω και θα συνδυάσω πληροφορίες που έχω αποκτήσει από διάφορες υπάρχουσες μεθοδολογίες και έχω διαπιστώσει ότι είναι χρήσιμες στη δική μου πρακτική προγραμματισμού.
Η προσέγγιση για το σχεδιασμό που θα προτείνω σε αυτά τα άρθρα προκύπτει από τις εμπειρίες μου με την πάροδο των ετών στο θάλαμο: σχεδιασμός νέου λογισμικού, βελτίωση παλαιού λογισμικού, συντήρηση λογισμικού που γράφτηκε από άλλους, συντήρηση λογισμικού που γράφτηκε από εμένα, εργασία με διάφορες γλώσσες, εργαλεία υπολογιστές και άλλα προγραμματιζόμενα μηχανήματα. Η φιλοσοφία του σχεδιασμού μου θα είναι πολύ «προσανατολισμένη σε καμπίνες»: βασισμένη σε, και προσανατολισμένη προς, πραγματικό εμπορικό προγραμματισμό.
Αυτόν τον μήνα: Η διαδικασία που περιγράφεται, ορίζεται "σχεδιασμός"
Σε αυτό το αρχικό άρθρο του Τεχνικές σχεδιασμού στήλη, θα παράσχω έναν λεπτομερή απολογισμό της έννοιας του σχεδιασμού λογισμικού βάσει της δικής μου εμπειρίας ως προγραμματιστή. Στο υπόλοιπο αυτού του άρθρου, θα συζητήσω τη διαδικασία ανάπτυξης λογισμικού και θα εξηγήσω τι εννοώ με τον όρο "σχεδιασμός".
Η διαδικασία ανάπτυξης λογισμικού
Σύμφωνα με την εμπειρία μου, η διαδικασία ανάπτυξης λογισμικού τείνει να είναι μάλλον χαοτική. Τα μέλη της ομάδας έρχονται και φεύγουν, αλλάζουν οι απαιτήσεις, αλλάζουν τα χρονοδιαγράμματα, ακυρώνονται ολόκληρα έργα, ολόκληρες εταιρείες βγαίνουν εκτός λειτουργίας κ.ο.κ. Η δουλειά του προγραμματιστή είναι να πλοηγηθεί με επιτυχία σε αυτό το χάος και στο τέλος να παράγει ένα προϊόν «ποιότητας» με «έγκαιρο» τρόπο.
Εκτός από το ότι είναι χαοτικό, η διαδικασία ανάπτυξης λογισμικού τείνει επίσης να είναι μάλλον επαναληπτική. Καθώς αναπτύσσεται ένα προϊόν λογισμικού, εξελίσσεται συνεχώς με βάση τα σχόλια πολλών μερών. Αυτή η επαναληπτική διαδικασία λειτουργεί από την κυκλοφορία στην κυκλοφορία (κάθε έκδοση είναι μία επανάληψη) και εντός του κύκλου ανάπτυξης μιας μεμονωμένης έκδοσης. Από την κυκλοφορία έως την κυκλοφορία, για παράδειγμα, τα σχόλια των πελατών με την τρέχουσα έκδοση υποδεικνύουν ποιες διορθώσεις σφαλμάτων και βελτιώσεις είναι πιο σημαντικές για να κάνουν στην επόμενη έκδοση. Μέσα στον κύκλο ανάπτυξης μιας μεμονωμένης έκδοσης, το όραμα του τελικού στόχου προσαρμόζεται συνεχώς από τις δυνάμεις της εταιρείας καθώς εξελίσσεται η ανάπτυξη.
Παρά το χάος και την επανάληψη, έχω διαπιστώσει ότι οι περισσότερες αναπτυξιακές ομάδες προσπαθούν να επιβάλουν κάποια δομή στις αναπτυξιακές τους προσπάθειες. Για τους σκοπούς αυτής της στήλης, θα χωρίσω χαλαρά τη διαδικασία ανάπτυξης λογισμικού ενός κύκλου κυκλοφορίας σε αυτές τις τέσσερις φάσεις:
- Προσδιορισμός
- Σχέδιο
- Εκτέλεση
- Ολοκλήρωση και δοκιμή
Με αυτές τις τέσσερις φάσεις σκοπεύω να καταγράψω μια δομή που έχω παρατηρήσει στα περισσότερα προγράμματα ανάπτυξης λογισμικού. Επειδή κάθε εταιρεία είναι διαφορετική, κάθε ομάδα είναι διαφορετική και κάθε έργο είναι διαφορετικό, αυτές οι τέσσερις φάσεις αποτελούν μόνο μια γενική περιγραφή ενός τυπικού κύκλου ανάπτυξης. Στην πράξη, ορισμένες φάσεις μπορεί να παραλειφθούν ή μπορεί να συμβούν με διαφορετική σειρά. Και επειδή ο επαναληπτικός χαρακτήρας της ανάπτυξης λογισμικού τείνει να φουσκώνει μέσω οποιασδήποτε επιβαλλόμενης δομής, αυτές οι φάσεις ενδέχεται σε κάποιο βαθμό να αλληλεπικαλύπτονται ή να αλληλοαναιρούνται.
Όταν μιλάω για το σχεδιασμό στο Τεχνικές σχεδιασμού στήλη, αναφέρομαι στις δραστηριότητες που πραγματοποιούνται κατά το δεύτερο βήμα της παραπάνω λίστας. Για να σας δώσω μια καλύτερη ιδέα για το τι εννοώ σε κάθε φάση, περιγράφω το καθένα ξεχωριστά στις επόμενες τέσσερις ενότητες.
Φάση 1: Καθορισμός του προβληματικού τομέα
ο φάση προδιαγραφής ενός έργου λογισμικού περιλαμβάνει τη συγκέντρωση όλων των ενδιαφερόμενων μερών για συζήτηση και καθορισμό του τελικού προϊόντος της διαδικασίας ανάπτυξης λογισμικού. Κατά τη διάρκεια των προδιαγραφών, ορίζετε "το όραμα" - τον στόχο που θα στοχεύσετε για το υπόλοιπο του έργου. Το παραδοτέο που πρέπει να βγει από τη φάση προδιαγραφών είναι ένα γραπτό έγγραφο που καθορίζει τις απαιτήσεις του συστήματος λογισμικού.
Η προδιαγραφή απαιτήσεων μοιάζει πολύ με μια σύμβαση. Είναι μια σύμβαση μεταξύ όλων των ενδιαφερομένων μερών, αλλά το πιο σημαντικό από την πλευρά του προγραμματιστή, είναι μια σύμβαση μεταξύ του προγραμματιστή και όποιο μέρος επιθυμεί το τελικό προϊόν πρώτα: ίσως πελάτης, πελάτης, διαχείριση ή τμήμα μάρκετινγκ . Όταν μια προδιαγραφή συμφωνείται με προφορικούς όρους αλλά δεν καταγράφεται, είναι βασικά προφορική σύμβαση. Αν και μια προφορική σύμβαση είναι νομικά δεσμευτική, σε πολλές περιπτώσεις το να μην γράφετε κάτι είναι συνταγή για προβλήματα. Διαφορετικοί άνθρωποι τείνουν να έχουν διαφορετικές αναμνήσεις προφορικών συμφωνιών, ειδικά όταν πρόκειται για λεπτομέρειες. Μια διαφωνία σχετικά με τις λεπτομέρειες είναι ακόμη πιο πιθανή εάν οι λεπτομέρειες δεν συζητήθηκαν ποτέ ως μέρος της προφορικής συμφωνίας, η οποία αποτελεί κοινό χαρακτηριστικό των προφορικών συμβάσεων.
Όταν όλα τα εμπλεκόμενα μέρη συγκεντρώνονται και προσπαθούν να γράψουν τις απαιτήσεις ενός έργου λογισμικού, αναγκάζει μια εξερεύνηση του προβληματικός τομέας. Ο προβληματικός τομέας είναι το τελικό προϊόν που περιγράφεται σε ανθρώπινη γλώσσα (όχι προγραμματισμός υπολογιστή). Το ίδιο τελικό προϊόν που εκφράζεται σε γλώσσα υπολογιστή είναι το τομέα λύσης. Κατά τη διάρκεια της εξερεύνησης του προβληματικού τομέα, πολλές αμφίσημες λεπτομέρειες μπορούν να εντοπιστούν και να συζητηθούν, και οι διαφωνίες μπορούν να επιλυθούν από την αρχή.
Μια καλή προδιαγραφή σας δίνει έναν σαφώς καθορισμένο στόχο για να στοχεύσετε καθώς αναπτύσσετε. Αλλά δεν εγγυάται ότι ο στόχος δεν θα κινηθεί. Ορισμένες προσαρμογές στο όραμα του τελικού προϊόντος είναι σχεδόν αναπόφευκτες κατά τη φάση σχεδιασμού και υλοποίησης. Ωστόσο, μια καλή προδιαγραφή μπορεί να βοηθήσει στη μείωση του μεγέθους αυτών των προσαρμογών. Η παράλειψη της φάσης προδιαγραφής ή η μη επαρκής κάλυψη των λεπτομερειών μπορεί να οδηγήσει σε παρόμοια παρεξήγηση μεταξύ των μερών που μπορεί να συμβεί με προφορική σύμβαση. Έτσι, η καλή προδιαγραφή βοηθά πρώτα να προχωρήσει η επόμενη φάση σχεδιασμού και υλοποίησης σε ένα επιτυχημένο συμπέρασμα.
Φάση 2: Σχεδιασμός του τομέα λύσης
Μόλις έχετε μια γραπτή προδιαγραφή στην οποία συμφωνούν όλοι οι εμπλεκόμενοι, είστε έτοιμοι για αυτό που αποκαλώ φάση σχεδιασμού - τη διαδικασία σχεδιασμού, και κατά κάποιο τρόπο τεκμηρίωσης, της αρχιτεκτονικής του τομέα της λύσης σας. Περιλαμβάνω πολλές δραστηριότητες με το όνομα "design", όπως:
Καθορισμός του συστήματος:
- Διαχωρισμός του συστήματος σε μεμονωμένα προγράμματα (και τεκμηρίωση του)
- Καθορισμός και τεκμηρίωση των διεπαφών μεταξύ των επιμέρους προγραμμάτων
- Αποφασίζοντας και τεκμηριώνοντας βιβλιοθήκες τρίτων (πακέτα Java) που θα χρησιμοποιήσουν τα προγράμματα Java
- Αποφασίζοντας και τεκμηριώνοντας νέες βιβλιοθήκες (πακέτα Java) θα δημιουργήσετε ότι θα μοιραστούν πολλά στοιχεία του συστήματός σας
Δημιουργία πρωτοτύπων διεπαφής χρήστη:
- Δημιουργία πρωτοτύπων διεπαφής χρήστη για εκείνα τα στοιχεία συστήματος που έχουν οποιοδήποτε περιβάλλον εργασίας χρήστη
Κάνοντας αντικειμενοστραφή σχεδίαση:
- Σχεδιασμός και τεκμηρίωση ιεραρχιών τάξης
- Σχεδιασμός και τεκμηρίωση των επιμέρους τάξεων και διεπαφών
Καθορισμός του συστήματος
Ως πρώτο βήμα στη φάση σχεδιασμού, πρέπει να διαχωρίσετε το σύστημά σας στα εξαρτήματα του. Για παράδειγμα, ενδέχεται να απαιτήσετε αρκετές διαδικασίες σε διάφορα σημεία ενός δικτύου. Μπορεί να έχετε μερικές μικροεφαρμογές και μερικές εφαρμογές. Ορισμένα στοιχεία του συστήματος ενδέχεται να προορίζονται για εγγραφή σε Java και άλλα όχι. Εάν θέλετε να χρησιμοποιήσετε το JDBC, ίσως χρειαστεί να επιλέξετε μια βιβλιοθήκη JDBC τρίτου μέρους που θα σας επιτρέψει να αποκτήσετε πρόσβαση στη βάση δεδομένων της επιλογής σας. Όλες αυτές οι αποφάσεις πρέπει να ληφθούν προτού μπορέσετε να ξεκινήσετε τυχόν αντικειμενοστραφή σχέδια των μεμονωμένων προγραμμάτων στο σύστημα.
Καθώς ορίζετε το σύστημα, πιθανότατα θα θελήσετε να τεκμηριώσετε την εργασία σας σε μία ή περισσότερες τεχνικές προδιαγραφές. Η τεκμηρίωση σας επιτρέπει να κοινοποιήσετε το σχέδιο σε άλλα ενδιαφερόμενα μέρη του οργανισμού και να λάβετε τα σχόλιά τους. Μπορείτε να διαγράψετε τις προδιαγραφές, να καλέσετε μια σύσκεψη αναθεώρησης σχεδιασμού και, στη συνέχεια, να παρουσιάσετε τη σχεδίαση του συστήματος στη σύσκεψη. Η ομάδα μπορεί να συζητήσει το σχέδιό σας και ελπίζουμε να βρει προβλήματα και να κάνει προτάσεις. Η λήψη σχολίων - και η προσαρμογή στη σχεδίαση του συστήματός σας ως αποτέλεσμα των σχολίων - είναι ένα παράδειγμα επανάληψης στη διαδικασία ανάπτυξης λογισμικού.
Δημιουργία πρωτοτύπων διεπαφής χρήστη
Η δημιουργία πρωτοτύπου διεπαφής χρήστη είναι συχνά μια πολύτιμη δραστηριότητα κατά τη φάση του σχεδιασμού. Μόλις ολοκληρωθεί το πρωτότυπο διεπαφής χρήστη, τα μέρη που συμφώνησαν στην προδιαγραφή μπορούν να συγκεντρωθούν ξανά για να ελέγξουν την έκδοση προεπισκόπησης. Έχοντας ένα πρωτότυπο δίνει στα μέρη μια άλλη ευκαιρία να οπτικοποιήσουν και να συζητήσουν τον τελικό στόχο. Απαιτώντας από όλους όσους συμφώνησαν στην προδιαγραφή να επανεξετάσουν και να αποσυνδεθούν από ένα πρωτότυπο διεπαφής χρήστη, διασφαλίζετε ότι όλα τα μέρη έχουν συμβατές προσδοκίες για το τελικό προϊόν. Με τα οπτικά εργαλεία που διατίθενται σήμερα για την ανάπτυξη διεπαφών χρήστη που βασίζονται σε Java, η ανάπτυξη ενός πρωτοτύπου διεπαφής χρήστη μπορεί να είναι πολύ γρήγορη και το τελικό αποτέλεσμα είναι ένα πλαίσιο κώδικα Java που μπορείτε στη συνέχεια να αποκτήσετε με λειτουργικότητα κατά τη φάση υλοποίησης.
Σημειώστε ότι η διαδικασία επίδειξης ενός πρωτοτύπου διεπαφής χρήστη είναι ένα πρωταρχικό παράδειγμα της επαναληπτικής φύσης της διαδικασίας ανάπτυξης. Όταν τα ενδιαφερόμενα μέρη (που έχουν όλοι συμφωνήσει σε μια γραπτή προδιαγραφή) βλέπουν πραγματικά πρωτότυπα διεπαφής χρήστη, συχνά έχουν νέες ιδέες, ή καλύτερη κατανόηση, ή μια πιο λεπτομερή κατανόηση - με άλλα λόγια, ένα σαφέστερο όραμα - του τέλους προϊόν. Κατά τη διάρκεια της επίδειξης, ενδέχεται να γίνουν ορισμένες προσαρμογές στις προδιαγραφές. Ωστόσο, μέχρι τώρα, ελπίζουμε ότι οι προσαρμογές θα είναι μικρές.
Κάνοντας αντικειμενοστρεφή σχεδίαση
Καθώς σχεδιάζετε ένα πρόγραμμα Java, πρέπει να σκεφτείτε όλες τις τεχνολογίες προγραμματισμού που προσφέρονται από τη γλώσσα Java, συμπεριλαμβανομένων των πολλαπλών νημάτων, της συλλογής απορριμμάτων, της διαχείρισης δομημένων σφαλμάτων και του αντικειμενικού προσανατολισμού. Ωστόσο, επειδή το κυρίαρχο αρχιτεκτονικό χαρακτηριστικό της γλώσσας προγραμματισμού Java είναι ο προσανατολισμός αντικειμένου, μια φάση σχεδιασμού προγράμματος Java είναι ουσιαστικά μια διαδικασία αντικειμενοστρεφής σχεδιασμού.
Η πραγματοποίηση αντικειμενοστραφής σχεδίασης περιλαμβάνει τη δημιουργία ιεραρχιών κληρονομιάς και το σχεδιασμό των πεδίων και των μεθόδων μεμονωμένων τάξεων και διεπαφών. Τρεις βασικές κατηγορίες τάξεων που θα βρείτε σε ένα σχέδιο είναι:
- Κατηγορίες διεπαφής χρήστη
- Πρόβλημα κλάσεων τομέα
- Κατηγορίες διαχείρισης δεδομένων
Κατηγορίες διεπαφής χρήστη είναι αυτές που συνθέτουν τη διεπαφή χρήστη του προγράμματος, όπως τάξεις που αντιπροσωπεύουν παράθυρα και διαλόγους. Πρόβλημα κλάσεων τομέα είναι εκείνα που αντιπροσωπεύουν αντικείμενα που προσδιορίσατε στον προβληματικό τομέα. Για παράδειγμα, εάν ο προβληματικός τομέας σας αφορούσε ανελκυστήρες, μπορεί να έχετε Ανελκυστήρας τάξη στον τομέα λύσεων. Κατηγορίες διαχείρισης δεδομένων είναι αυτά που δημιουργείτε για τη διαχείριση αντικειμένων ή δεδομένων. Ούτε οι κλάσεις διεπαφής χρήστη ούτε οι κλάσεις διαχείρισης δεδομένων έχουν αντίστοιχα αντικείμενα στον προβληματικό τομέα.
Φάση 3: Υλοποίηση
Η εφαρμογή κωδικοποιεί. Γράφοντας για βρόχους, εάν δηλώσεις, ρήτρες, μεταβλητές και σχόλια. σύνταξη? δοκιμή μονάδας διόρθωση σφαλμάτων - αυτή είναι η εφαρμογή: η πρωταρχική πράξη του προγραμματισμού.
Φάση 4: Ολοκλήρωση και δοκιμή
Κατά τη διάρκεια της φάσης ολοκλήρωσης και δοκιμής, τα μέλη της ομάδας του έργου, καθένα από τα οποία έχει αναλάβει να δημιουργήσει ένα συγκεκριμένο μέρος του συνόλου, συναντιέται και προσπαθεί να λειτουργήσει όλα τα κομμάτια του συστήματος λογισμικού. Κατά τη διάρκεια αυτής της φάσης τα μέλη της ομάδας ανακαλύπτουν πόσο καλά ορίστηκαν και επικοινωνήθηκαν οι διεπαφές μεταξύ των επιμέρους στοιχείων του συστήματος κατά τη φάση διαμέρισης του συστήματος. Η κωδικοποίηση που λαμβάνει χώρα κατά τη διάρκεια αυτής της φάσης πρέπει κατά κύριο λόγο να διορθώνει σφάλματα.
Τεκμηρίωση σχεδίων λογισμικού
Υπάρχουν πολλές προσεγγίσεις στη σχεδίαση λογισμικού. Οι επίσημες μεθοδολογίες προσπαθούν να σας καθοδηγήσουν στη διαδικασία μετατροπής ενός προβληματικού τομέα σε τομέα λύσης. Κατά το σχεδιασμό προγραμμάτων Java, μπορείτε να επιλέξετε να χρησιμοποιήσετε μια τυπική μεθοδολογία, να συνδυάσετε διάφορες επίσημες μεθοδολογίες ή να παραλείψετε την επίσημη μεθοδολογία και το σχεδιασμό από τη θέση του παντελονιού σας. Αλλά ανεξάρτητα από το πώς επιτεθείτε στη φάση σχεδιασμού του έργου λογισμικού σας, θα πρέπει κατά κάποιο τρόπο να τεκμηριώσετε το σχέδιό σας.
