Στον εμπορικό κόσμο, χρησιμοποιούμε Java 2 Enterprise Edition (J2EE) για την επίλυση επιχειρηματικών προβλημάτων, την ανάπτυξη εμπορικού λογισμικού ή για την παροχή συμβάσεων υπηρεσιών σε έργα άλλων επιχειρήσεων. Εάν μια εταιρεία θέλει να δημιουργήσει έναν ιστότοπο ηλεκτρονικού επιχειρείν χρησιμοποιώντας μια πολυεπίπεδη αρχιτεκτονική, συνήθως περιλαμβάνει διαχειριστές, αρχιτέκτονες, σχεδιαστές, προγραμματιστές, δοκιμαστές και εμπειρογνώμονες βάσεων δεδομένων καθ 'όλη τη διάρκεια του κύκλου ζωής της ανάπτυξης.
Για να δουλέψουν αποτελεσματικά και αποδοτικά τα διάφορα μέρη, χρειάζονται συχνά μια διαδικασία ανάπτυξης λογισμικού. Ορισμένες κλασικές διαδικασίες ανάπτυξης περιλαμβάνουν το μοντέλο καταρράκτη, ταχεία ανάπτυξη εφαρμογών (RAD) και ακραίο προγραμματισμό. Σε αυτό το άρθρο, θα επικεντρωθούμε σε μια δημοφιλή διαδικασία μηχανικής λογισμικού, την Rational Unified Process (RUP). Το RUP παρέχει μια πειθαρχημένη προσέγγιση για την ανάθεση καθηκόντων και ευθυνών σε διαφορετικούς ρόλους. Στόχος του είναι να παράγουμε υψηλής ποιότητας λογισμικό που να ανταποκρίνεται στις ανάγκες των χρηστών εντός ενός προβλέψιμου προγράμματος και προϋπολογισμού.
Μου αρέσει να χρησιμοποιώ το RUP για ανάπτυξη J2EE για τρεις λόγους. Πρώτον, το RUP είναι κεντρικό στην αρχιτεκτονική. Αναπτύσσει ένα εκτελέσιμο πρωτότυπο αρχιτεκτονικής πριν δεσμεύσει πόρους για πλήρη ανάπτυξη. Δεύτερον, το RUP είναι επαναληπτικό και βασίζεται σε στοιχεία. Η αρχική γραμμή αρχιτεκτονικής συχνά περιλαμβάνει ένα πλαίσιο ή υποδομή για τη διευκόλυνση της προσθήκης στοιχείων μέσω επαναλήψεων για την προσαρμογή και επέκταση της λειτουργικότητας ενός συστήματος χωρίς να επηρεάζεται το υπόλοιπο σύστημα. Τρίτον, το RUP χρησιμοποιεί μια βιομηχανική γλώσσα, UML, για να μοντελοποιήσει οπτικά την αρχιτεκτονική και τα στοιχεία ενός συστήματος. Το RUP έχει τέσσερις διαφορετικές φάσεις ανάπτυξης: έναρξη, επεξεργασία, κατασκευή και μετάβαση. Αυτό το άρθρο, ωστόσο, καλύπτει οκτώ βασικές δραστηριότητες που εμπλέκονται στην ανάπτυξη του J2EE από τεχνική άποψη με τρόπο που διατηρεί την αρχιτεκτονική εστίαση.
I. Ανάλυση απαιτήσεων
Η ανάλυση απαιτήσεων περιγράφει τι πρέπει ή δεν πρέπει να κάνει το σύστημα έτσι ώστε οι προγραμματιστές και οι πελάτες να μπορούν να δημιουργήσουν ένα αρχικό επιχειρηματικό συμβόλαιο. Μπορείτε να τεκμηριώσετε τις λειτουργικές απαιτήσεις σε επιχειρηματικές έννοιες, γλωσσάρια τομέα, περιπτώσεις χρήσης και mockup διεπαφής χρήστη (UI). Μη λειτουργικές απαιτήσεις, όπως απόδοση και συναλλαγές, καθορίζετε σε ένα συμπληρωματικό έγγραφο απαιτήσεων. Μπορείτε να δημιουργήσετε το πρότυπο UI υψηλού επιπέδου σε χαρτί ή σε HTML, ανάλογα με το πόσο βαθιά εμπλέκεστε στο έργο.
Το Σχήμα 1 δείχνει δύο δείγματα περιπτώσεων χρήσης ενός τυπικού συστήματος ηλεκτρονικού εμπορίου. ο viewOrder Η υπόθεση χρήσης μας λέει ότι ένας χρήστης συνδέεται σε ένα σύστημα μέσω μιας διεπαφής Ιστού, βλέπει μια λίστα παραγγελιών και κάνει κλικ σε έναν σύνδεσμο για να δει τις λεπτομέρειες παραγγελίας μιας συγκεκριμένης παραγγελίας αγοράς. ο addLineItems η υπόθεση χρήσης μας λέει ότι ο χρήστης περιηγείται σε έναν κατάλογο προϊόντων, επιλέγει ενδιαφέροντα προϊόντα και τα προσθέτει σε μια παραγγελία αγοράς.
ΙΙ. Αντικειμενοστραφής ανάλυση
Οι αναλυτές δημιουργούν προβληματικά μοντέλα τομέα: τάξεις, αντικείμενα και αλληλεπιδράσεις. Η ανάλυσή σας πρέπει να είναι απαλλαγμένη από οποιεσδήποτε τεχνικές λεπτομέρειες ή λεπτομέρειες εφαρμογής και πρέπει να περιέχει ένα ιδανικό μοντέλο. Η ανάλυση αντικειμένων σάς βοηθά να κατανοήσετε το πρόβλημα και να αποκτήσετε γνώσεις σχετικά με τον προβληματικό τομέα. Πρέπει να διατηρήσετε ένα καθαρό μοντέλο τομέα χωρίς τεχνικές λεπτομέρειες, επειδή μια επιχειρηματική διαδικασία αλλάζει πολύ πιο αργά από τις τεχνολογίες πληροφοριών.
Αυτά τα δύο πρώτα βήματα - ανάλυση απαιτήσεων και αντικειμενοστρεφή ανάλυση - δεν είναι ειδικά για το J2EE. Είναι αρκετά γενικές για πολλές αντικειμενοστρεφείς μεθοδολογίες. Το Σχήμα 2 δείχνει ένα μοντέλο ανάλυσης αντικειμένων υψηλού επιπέδου μιας εφαρμογής δείγματος κατοικίδιων ζώων. Απεικονίζει τις κύριες έννοιες που εντοπίσαμε από περιπτώσεις ανάλυσης απαιτήσεων. Διαμορφώνουμε αυτές τις έννοιες σε αντικείμενα και προσδιορίζουμε τις σχέσεις τους.
Το αποτέλεσμα των απαιτήσεων και των αναλύσεων αντικειμένων είναι το σημείο εισόδου για την ανάπτυξη αρχιτεκτονικής J2EE. Για να αναπτύξετε μια αρχιτεκτονική, επιλέγετε ένα κατακόρυφο κομμάτι - συχνά ένα κρίσιμο μέρος, όπως το μοντέλο αντικειμένου τομέα παραγγελίας - για σχεδιασμό αντικειμένων, υλοποίηση, δοκιμή και ανάπτυξη. (Ένα κάθετο κομμάτι, μια έννοια RUP, είναι ένα μικρό τμήμα ενός συστήματος. Το σημείο εκκίνησης είναι ένα υποσύνολο περιπτώσεων χρήσης, όπως φαίνεται στο Σχήμα 1, και μοντέλα ανάλυσης τομέα, όπως φαίνεται στο Σχήμα 3. Η εφαρμογή ενός κάθετου κομματιού έχει ως αποτέλεσμα ένα πλήρως λειτουργικό μίνι σύστημα, συμπεριλαμβανομένων όλων των επιπέδων, όπως σελίδες JavaServer UI-tier (JSPs), επιχειρηματικά αντικείμενα μεσαίου επιπέδου όπως Enterprise JavaBeans (EJBs), και συχνά βάσεις δεδομένων backend.) πρωτότυπο σε αντικείμενα τομέα και αφήστε αυτή τη γνώση να χρησιμεύσει ως κατευθυντήρια γραμμή σχεδιασμού για το στάδιο σχεδιασμού αντικειμένων.
