Η παρουσίαση φορτώνεται. Παρακαλείστε να περιμένετε

Η παρουσίαση φορτώνεται. Παρακαλείστε να περιμένετε

2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης1 ΟΙΚΟΝΟΜΙΚΟ ΠΑΝΕΠΙΣΤΗΜΙΟ ΑΘΗΝΩΝ ΤΜΗΜΑ ΠΛΗΡΟΦΟΡΙΚΗΣ ΤΕΧΝΟΛΟΓΙΑ ΛΟΓΙΣΜΙΚΟΥ Αρχιτεκτονική Λογισμικού Μανόλης.

Παρόμοιες παρουσιάσεις


Παρουσίαση με θέμα: "2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης1 ΟΙΚΟΝΟΜΙΚΟ ΠΑΝΕΠΙΣΤΗΜΙΟ ΑΘΗΝΩΝ ΤΜΗΜΑ ΠΛΗΡΟΦΟΡΙΚΗΣ ΤΕΧΝΟΛΟΓΙΑ ΛΟΓΙΣΜΙΚΟΥ Αρχιτεκτονική Λογισμικού Μανόλης."— Μεταγράφημα παρουσίασης:

1 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης1 ΟΙΚΟΝΟΜΙΚΟ ΠΑΝΕΠΙΣΤΗΜΙΟ ΑΘΗΝΩΝ ΤΜΗΜΑ ΠΛΗΡΟΦΟΡΙΚΗΣ ΤΕΧΝΟΛΟΓΙΑ ΛΟΓΙΣΜΙΚΟΥ Αρχιτεκτονική Λογισμικού Μανόλης Γιακουμάκης αναπληρωτής καθηγητής ΟΠΑ

2 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης2 Σημερινή παρουσίαση Τι είναι η αρχιτεκτονική –Η σημασία της αρχιτεκτονικής –Αρχιτεκτονική και απαιτήσεις –Αρχιτεκτονική σχεδίαση Αρχιτεκτονική προσανατολισμένη στις λειτουργίες Αρχιτεκτονική προσανατολισμένη στα αντικείμενα Αρχιτεκτονικά πρότυπα –Διαστρωματωμένη αρχιτεκτονική –Μοντέλο-Όψη-Ελεγκτής Συστατικά και Πλατφόρμες –Συστατικά –Πλατφόρμες Τεκμηρίωση αρχιτεκτονικής Διαγράμματα πακέτων Διαγράμματα συστατικών Διαγράμματα παράταξης

3 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης3 Τι είναι η αρχιτεκτονική Η αρχιτεκτονική λογισμικού ενός συστήματος είναι η δομή του συστήματος, οι σχέσεις μεταξύ των δομικών στοιχείων της δομής, καθώς και οι ιδιότητες αυτών των στοιχείων. Εάν η σχεδίαση είναι το σύνολο των αποφάσεων που αφορούν τον τρόπο επίλυσης του προβλήματος, τότε η αρχιτεκτονική σχεδίαση είναι το σύνολο των αποφάσεων σχεδίασης που είναι δύσκολο να αλλάξουν

4 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης4 Η σημασία της αρχιτεκτονικής Η αρχιτεκτονική βοηθά στην κατανόηση του συστήματος. Η κατανόηση της αρχιτεκτονικής από όλους τους ενδιαφερομένους βοηθά και την επικοινωνία των ενδιαφερομένων σε σχέση με το σύστημα. Ο προσδιορισμός της αρχιτεκτονικής βοηθά στην οργάνωση του τρόπου ανάπτυξης του λογισμικού. ( Έχοντας προσδιορίσει τις δομικές μονάδες του λογισμικού με τις διεπαφές τους, η ανάπτυξη των δομικών μονάδων μπορεί να γίνει ως ένα βαθμό ανεξάρτητα από τις άλλες. Η υλοποίηση μίας μονάδας λογισμικού με καθορισμένες διεπαφές είναι δυνατόν να ανατεθεί σε μία ανεξάρτητη ομάδα μηχανικών λογισμικού που είναι δυνατόν να βρίσκεται σε μακρινή χώρα, π.χ. Ινδία (Η Ινδία έχει δραστηριότητες αυτής της μορφής που το οικονομικό τους μέγεθος προσεγγίζει το 4% του ΑΕΠ της Ινδίας). Η αρχιτεκτονική παρέχει μία σταθερή βάση πάνω στην οποία θα βασιστεί η συντήρηση του λογισμικού. Η αρχιτεκτονική βοηθά στην οργάνωση του έργου.

5 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης5 Αρχιτεκτονική και απαιτήσεις Η δημιουργία της αρχιτεκτονικής του λογισμικού δεν επηρεάζεται μόνο από τις λειτουργικές απαιτήσεις αλλά και από τις μη λειτουργικές απαιτήσεις και τους περιορισμούς σχεδίασης. Ανάλογα με τη φύση του λογισμικού οι απαιτήσεις που αφορούν κάποια χαρακτηριστικά έχουν μεγαλύτερη βαρύτητα από κάποιες άλλες. Οι λειτουργικές, οι μη λειτουργικές και οι επιχειρησιακές απαιτήσεις, οι οποίες έχουν τη μεγαλύτερη βαρύτητα και επηρεάζουν και την αρχιτεκτονική του λογισμικού, καλούνται και αρχιτεκτονικοί παράγοντες (architectural factors) ή αρχιτεκτονικοί οδηγοί (architectural drivers). Υπάρχει αλληλεπίδραση μεταξύ των ποιοτικών χαρακτηριστικών του λογισμικού

6 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης6 Αρχιτεκτονική σχεδίαση Για τη σχεδίαση της αρχιτεκτονικής του λογισμικού ο αρχιτέκτονας επανεξετάζει και αποσαφηνίζει τις μη λειτουργικές απαιτήσεις, όταν αυτές δεν είναι μετρήσιμες. Μία μέθοδος για τον καθορισμό μετρήσιμων μεγεθών για την αξιολόγηση των ποιοτικών χαρακτηριστικών είναι η δημιουργία σεναρίων ποιότητας (quality scenarios). Με τον ίδιο τρόπο που οι περιπτώσεις χρήσης μας παρέχουν τα σενάρια της λειτουργικότητας του λογισμικού, τα σενάρια ποιότητας καθορίζουν μετρήσιμα κριτήρια για την επίτευξη των κριτηρίων που θέτουν οι μη λειτουργικές απαιτήσεις.

7 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης7 Αρχιτεκτονική σχεδίαση Κάθε σενάριο ποιότητας αποτελείται από τα παρακάτω στοιχεία: Πηγή του ερεθίσματος. Μπορεί να είναι κάποιος χρήστης ή κάποιο εξωτερικό σύστημα που γεννά το ερέθισμα. Ερέθισμα. Η συνθήκη την οποία θα πρέπει να διαχειριστεί το σύστημα. Περιβάλλον. Το γενικό περιβάλλον κάτω από το οποίο γεννάται το ερέθισμα. Π.χ. το σύστημα είναι υπερφορτωμένο. Προϊόν (artifact). Το προϊόν του συστήματος μπορεί να είναι ένα τμήμα ή το σύνολο του συστήματος. Απόκριση. Αυτό που πρέπει να γίνει για τη διαχείριση του ερεθίσματος. Μέτρηση Απόκρισης. Η μέτρηση της απόκρισης μπορεί να αφορά χρόνους απόκρισης, κόστη κ.λπ.

8 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης8 Πρότυπο δημιουργίας σεναρίων ποιότητας για τη διαθεσιμότητα Πηγή ερεθίσματοςΕσωτερική στο σύστημα ή εξωτερική του συστήματος. ΕρέθισμαΠαράλειψη, κατάρρευση, χρονισμός, απόκριση. ΠεριβάλλονΚανονική λειτουργία, μειωμένων δυνατοτήτων. ΠροϊόνΕπεξεργαστές, κανάλια επικοινωνίας, συσκευές αποθήκευσης δεδομένων, διεργασίες. ΑπόκρισηΕγγραφή στο ημερολόγιο συμβάντων, ενημέρωση διαχειριστών και χρηστών, απενεργοποίηση των πηγών των γεγονότων που προκαλούν το σφάλμα, μη διαθεσιμότητα του συστήματος για κάποιο χρονικό διάστημα, συνέχιση της λειτουργίας σε κανονική λειτουργία ή λειτουργία μειωμένων δυνατοτήτων. Μέτρηση απόκρισηςΧρονικό διάστημα στο οποίο θα πρέπει το σύστημα να είναι διαθέσιμο, ποσοστό διαθεσιμότητας, χρονικό διάστημα λειτουργίας σε κατάσταση μειωμένων δυνατοτήτων, χρόνος επιδιόρθωσης.

9 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης9 Τα βήματα για την αρχιτεκτονική σχεδίαση (1/2) Επιλογή του δομικού στοιχείου προς αποσύνθεση. Όταν ξεκινάμε τη σχεδίαση, η μονάδα προς αποσύνθεση είναι το σύστημα ως ολότητα. Η προϋπόθεση της αποσύνθεσης είναι η ύπαρξη των λειτουργικών απαιτήσεων, των περιορισμών και των σεναρίων ποιότητας. Σε πρώτη φάση η αποσύνθεση θα έχει ως αποτέλεσμα τα βασικά υποσυστήματα του λογισμικού. Εκλέπτυνση του δομικού στοιχείου σύμφωνα με τα παρακάτω βήματα: – Επιλογή των αρχιτεκτονικών παραγόντων από τις λειτουργικές απαιτήσεις και τα σενάρια ποιότητας. Αυτό το βήμα καθορίζει τι είναι σημαντικό για την αποσύνθεση που θα επακολουθήσει. – Καθορισμός των αρχιτεκτονικών αποφάσεων σχεδίασης οι οποίες θα χρησιμοποιηθούν για την κάλυψη των αρχιτεκτονικών παραγόντων. Οι αρχιτεκτονικές αυτές αποφάσεις καθοδηγούνται από τους αρχιτεκτονικούς παράγοντες.

10 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης10 Τα βήματα για την αρχιτεκτονική σχεδίαση (2/2) – Ορισμός των δομικών μονάδων απογόνων και ο καθορισμός της λειτουργικότητας σε κάθε δομική μονάδα απόγονο. Τεκμηρίωση των δομικών μονάδων. – Καθορισμός των διεπαφών των δομικών μονάδων απογόνων. Η αποσύνθεση παρέχει μονάδες και περιορισμούς για τον τρόπο επικοινωνίας μεταξύ των μονάδων. Τεκμηρίωση των διεπαφών κάθε μονάδας. – Επαλήθευση και εκλέπτυνση των λειτουργικών απαιτήσεων και των σεναρίων ποιότητας και μετατροπή τους σε περιορισμούς των μονάδων-απογόνων. Αυτό το βήμα επαληθεύει ότι τίποτα το σημαντικό δεν έχει ξεχαστεί και προετοιμάζει τις μονάδες απογόνους για περαιτέρω αποσύνθεση ή υλοποίηση. Επανάληψη των παραπάνω βημάτων για κάθε δομική μονάδα που χρειάζεται αποσύνθεση.

11 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης11 Αρχιτεκτονική προσανατολισμένη στις λειτουργίες

12 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης12 Βιομηχανικό Σύστημα Ελέγχου (ΒΣΕ)

13 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης13 Εκλέπτυνση ΒΣΕ

14 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης14 Κέντρο Μετασχηματισμού

15 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης15 Κέντρο Μετασχηματισμού στα ΔΡΔ

16 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης16 Αντιστοίχιση ΔΡΔ σε Δομή Λογισμικού

17 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης17 Δομή Λογισμικού

18 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης18 Κέντρο Δοσοληψίας

19 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης19 Δομή Κέντρου Δοσοληψίας

20 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης20 Σύστημα δανεισμού βιβλιοθήκης

21 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης21 Απλοποίηση ΔΡΔ

22 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης22 Δομή Λογισμικού Συστήματος Δανεισμού

23 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης23 Αρχιτεκτονικά πρότυπα Διαστρωματωμένη αρχιτεκτονική Μοντέλο Όψη Ελεγκτή (MVC)

24 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης24 Διαστρωματωμένη αρχιτεκτονική

25 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης25 Χαλαρή Διαστρωμάτωση

26 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης26 Πλεονεκτήματα διαστωμάτωσης Αυξάνεται η συνεκτικότητα του λογισμικού. Κάθε στρώμα παρέχει ένα σύνολο συνεκτικών υπηρεσιών. Μπορούμε να κατανοήσουμε ένα επίπεδο, χωρίς να μας απασχολούν τα υπόλοιπα. Πολλές αλλαγές στο λογισμικό έχουν τοπικό χαρακτήρα. Μπορούμε να υποκαταστήσουμε τις υπηρεσίες ενός στρώματος με κάποια άλλη υλοποίηση. Παρέχονται περισσότερες ευκαιρίες μείωσης της σύζευξης. Διαφορετικές ευθύνες των στρωμάτων καθοδηγούν και τη διανομή της υλοποίησης στην ομάδα ανάπτυξης. Δίνονται περισσότερες ευκαιρίες διανομής των μονάδων λογισμικού σε διαφορετικούς κόμβους επεξεργασίας, υιοθετώντας κατανεμημένες αρχιτεκτονικές. Ένα (χαμηλού επιπέδου) στρώμα μπορεί να επαναχρησιμοποιηθεί σε πολλά διαφορετικά προϊόντα λογισμικού.

27 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης27 Προβλήματα διαστρωμάτωσης Η ενθυλάκωση μεταξύ στρωμάτων δεν είναι πάντα πλήρης. Αλλαγές σε χαμηλότερο επίπεδο μπορεί να επεκτείνονται έως και τα ανώτερα στρώματα. Η διαστρωμάτωση πιθανόν να μειώνει την απόδοση του λογισμικού. Ο αριθμός των στρωμάτων επηρεάζει κατά πολύ τη συνολική αρχιτεκτονική, αλλά σε πολύπλοκα συστήματα ο ακριβής προσδιορισμός των στρωμάτων είναι αρκετά δύσκολος.

28 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης28 Τα τρία στρώματα των πληροφοριακών συστημάτων ΣτρώμαΕυθύνες ΠαρουσίασηΥπηρεσίες που σχετίζονται με την παρουσίαση της πληροφορίας με τις διεπαφές χρήστη ΠεδίουΗ λογική του πεδίου όπου είναι ο κορμός της λειτουργικότητας του λογισμικού Πηγές ΔεδομένωνΕπικοινωνία με βάσεις δεδομένων ή άλλες πηγές δεδομένων

29 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης29 Μοντέλο Όψη ελεγκτή

30 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης30 Αρχές προτύπου Ο διαχωρισμός της αρμοδιότητας της παρουσίασης της πληροφορίας από την ίδια την πληροφορία. Η όψη εξαρτάται από το μοντέλο αλλά όχι το αντίστροφο. Είναι η σημαντικότερη αρχή του προτύπου και μία από τις σημαντικότερες αρχές στη σχεδίαση διεπαφών χρήστη. Ο διαχωρισμός της μετάφρασης των ενεργειών και των εντολών του τελικού χρήστη από την όψη σε διαφορετικό αντικείμενο που είναι ο ελεγκτής. Η αρχή αυτή είναι λιγότερο σημαντική. Σε ορισμένες περιπτώσεις τα αντικείμενα της διεπαφής χρήστη μπορεί να συμπεριλαμβάνουν και τη λογική των ελεγκτών.

31 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης31 Πλεονεκτήματα του προτύπου μοντέλο-όψη-ελεγκτής Η ίδια πληροφορία μπορεί να παρουσιαστεί με διαφορετικές μορφές. Διευκολύνονται οι αλλαγές στη διεπαφή χρήστη. Μπορεί να υπάρξουν εναλλάξιμες διεπαφές χρήσης. Τροποποίηση στη λογική του πεδίου ιδιαίτερα, όταν αυτή υλοποιεί επιχειρησιακούς κανόνες, δεν επηρεάζει τις όψεις και τους ελεγκτές. Ακόμα και όταν τους επηρεάζει, οι απαιτούμενες αλλαγές έχουν τοπικό χαρακτήρα και εντοπίζονται σχετικά εύκολα. Διευκολύνεται ο έλεγχος. Το μοντέλο ελέγχεται ανεξάρτητα από τους ελεγκτές και τις όψεις. Ο έλεγχος μίας συμπεριφοράς για κάποιο γεγονός μπορεί να γίνει μόνο με τη χρήση των ελεγκτών και του μοντέλου, χωρίς να χρησιμοποιηθεί η όψη.

32 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης32 Συστατικά και πλατφόρμες Ένας από τους παράγοντες επιτυχίας ενός έργου ανάπτυξης είναι η χρήση έτοιμων και ώριμων τεχνολογικών υποδομών. Η χρήση έτοιμων υποδομών μάς δίνει τη δυνατότητα να εστιάσουμε την προσπάθειά μας στην επίλυση του προβλήματος του πελάτη και των χρηστών, χωρίς να αναλωνόμαστε στη δημιουργία κώδικα για τεχνικές υπηρεσίες, οι οποίες αφενός είναι δύσκολες στην υλοποίησή τους αφετέρου επιρρεπείς σε σφάλματα. Θα εξετάσουμε δύο διαφορετικούς τρόπους με τους οποίους μπορούμε να επιλύσουμε ορισμένα από αυτά τα προβλήματα. Ο πρώτος τρόπος είναι η χρήση των συστατικών (components) με τα οποία γίνεται επαναχρησιμοποίηση του λογισμικού και ο δεύτερος είναι η χρήση των πλατφορμών (frameworks) με τις οποίες γίνεται επαναχρησιμοποίηση του λογισμικού αλλά και της σχεδίασης.

33 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης33 Συστατικά Θα θέλαμε να χρησιμοποιούμε έτοιμες μονάδες λογισμικού, οι οποίες έχουν κατασκευαστεί από τρίτους και να τις «συνδέουμε» με κάποιο τρόπο. Η σύνθεση των επιμέρους μονάδων θα παρείχε μία συνολικότερη υπηρεσία από αυτή των μονάδων. Αυτή είναι η επιδίωξη και των συστατικών (components). Ο στόχος των συστατικών είναι η δημιουργία και η χρήση ανεξάρτητων μονάδων λογισμικού, πιθανόν από διαφορετικούς κατασκευαστές, που όμως διασυνδέονται μεταξύ τους και παρέχουν κάποια συγκεκριμένη υπηρεσία. Τα πλεονεκτήματα χρήσης των συστατικών είναι εμφανή. Είναι έτοιμα τμήματα του λογισμικού τα οποία έχουν ήδη ελεγχθεί και διατίθενται προς χρήση.

34 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης34 Συστατικά Ένα απλό πακέτο δεν είναι συστατικό. Ένα πακέτο παρέχει μία λογική οργάνωση των κλάσεων χωρίς κάποια αναφορά στην φυσική του αντικατάσταση. Ένα πακέτο έχει κρυφά και μη κρυφά στοιχεία. Ένα συστατικό έχει μόνο δημόσιες διεπαφές και μάλιστα πολλές φορές απαιτεί την υλοποίηση κάποιων διεπαφών από τον κώδικα του πελάτη. Mία βιβλιοθήκη κλάσεων δεν είναι συστατικό. Οι κλάσεις σε μία βιβλιοθήκη μπορεί να είναι σχετικές μεταξύ τους, δεν εξυπηρετούν όμως ένα προδιαγεγραμμένο σκοπό. Κάθε συστατικό το συνοδεύει μία προδιαγραφή για το σκοπό του. 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης34

35 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης35 ιδιότητες των συστατικών Ένα συστατικό συμμορφώνεται με κάποιο στάνταρ, όπως το JavaBeans το Microsoft COM+ και το Enterprise JavaBeans. Ένα συστατικό έχει κάποια προδιαγραφή. Η προδιαγραφή ενός συστατικού είναι το σύνολο των διεπαφών του. Ένα συστατικό έχει κάποιες διεπαφές. Κάποιο συστατικό παρέχει τις υπηρεσίες του μέσω κάποιων διεπαφών, ενώ ταυτόχρονα μπορεί να απαιτεί την υλοποίηση κάποιων άλλων διεπαφών από τον κώδικα του πελάτη. Ένα συστατικό έχει μία υλοποίηση. Ένα συστατικό υλοποιεί τις διεπαφές του. Η υλοποίηση είναι κρυφή και ενθυλακωμένη πίσω από τις διεπαφές. 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης35

36 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης36 Διεπαφή – υλοποίηση συστατικού Βασικό χαρακτηριστικό των συστατικών είναι ότι είναι φυσικές μονάδες λογισμικού οι οποίες μπορεί να αντικαθίστανται. Νέες εκδόσεις ενός συστατικού μπορεί να διορθώνουν σφάλματα ή και να παρέχουν πρόσθετες υπηρεσίες. Η θεμελιώδης επομένως αρχή που διέπει τη δημιουργία των συστατικών είναι ο διαχωρισμός των διεπαφών από την υλοποίηση. Εξίσου θεμελιώδης αρχή είναι η σταθερότητα των διεπαφών αυτών. Χωρίς σταθερές διεπαφές ένα συστατικό δε θα μπορούσε χρησιμοποιηθεί. Με την ύπαρξη των συστατικών δημιουργούνται πλέον και νέες αγορές του λογισμικού που δεν αφορούν ολοκληρωμένες εφαρμογές αλλά συστατικά. Η ανάπτυξη των συστατικών έχει τις δικές της ιδιαιτερότητες διαμορφώνοντας ένα ξεχωριστό υποκλάδο της τεχνολογίας λογισμικού. 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης36

37 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης37 Πλατφόρμες Οι Πλατφόρμες (frameworks) είναι ένα σύνολο από κλάσεις που εκφράζουν μία αφηρημένη σχεδίαση για ένα σύνολο συσχετιζόμενων προβλημάτων και παρέχουν την επαναχρησιμότητα μονάδων λογισμικού σε ένα υψηλότερο επίπεδο από αυτό των κλάσεων. Οι πλατφόρμες αναλαμβάνουν κάποιες από τις ευθύνες του λογισμικού και παρέχουν κλάσεις και σχεδίαση στους μηχανικούς λογισμικού που τα χρησιμοποιούν. Το σημαντικό στοιχείο των πλατφορμών είναι ότι δεν περιορίζονται στην παροχή κάποιων βοηθητικών κλάσεων στην ομάδα ανάπτυξης, αλλά προσφέρουν και μία σχεδιαστική λύση για κάποιο συγκεκριμένο πρόβλημα. Δεν έχουμε δηλαδή μόνο την επαναχρησιμοποίηση σε επίπεδο κλάσεων αλλά επαναχρησιμότητα και σε επίπεδο σχεδίασης. 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης37

38 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης38 Τεκμηρίωση αρχιτεκτονικής Η καλή τεκμηρίωση της αρχιτεκτονικής του λογισμικού δεν μπορεί να αποδοθεί με έναν και μόνο τρόπο. Η κατανόηση της αρχιτεκτονικής βελτιώνεται, όταν αυτή τεκμηριώνεται με διαφορετικές όψεις. Ένας πρώτος διαχωρισμός των όψεων της αρχιτεκτονικής του λογισμικού είναι η λογική αρχιτεκτονική (logical architecture) και η φυσική αρχιτεκτονική (physical architecture). Η λογική αρχιτεκτονική αφορά στην περιγραφή των μονάδων λογισμικού και στις σχέσεις μεταξύ τους. Η φυσική αρχιτεκτονική αφορά στη διανομή των τμημάτων του λογισμικού, στο υλικό του συστήματος και στα πρωτόκολλα επικοινωνίας που υιοθετούνται. 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης38

39 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης392009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης39 Τεκμηρίωση αρχιτεκτονικής

40 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης40 Οι διαφορετικές όψεις του μοντέλου των 4+1 όψεων Λογική όψη (logical view). Περιλαμβάνει τις σημαντικότερες κλάσεις της σχεδίασης και την οργάνωσή του λογισμικού σε πακέτα και υποσυστήματα. Όψη διεργασιών (process view). Περιλαμβάνει την περιγραφή των διεργασιών, την επικοινωνία τους και τη διανομή των κλάσεων σε διεργασίες. Η όψη αυτή είναι απαραίτητη σε λογισμικό με υψηλό βαθμό παράλληλης επεξεργασίας. Όψη υλοποίησης (implementation view). Περιλαμβάνει μία επισκόπηση της οργάνωσης του μοντέλου υλοποίησης (implementation model), τη δομή και οργάνωση του κώδικα και την απεικόνιση στοιχείων του λογικού μοντέλου, όπως κλάσεις, πακέτα και συστατικά, στα στοιχεία του κώδικα που τις υλοποιούν. 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης40

41 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης41 Οι διαφορετικές όψεις του μοντέλου των 4+1 όψεων Όψη παράταξης (deployment view). Περιγράφει τις τυπικές καταστάσεις του φυσικού περιβάλλοντος στο οποίο θα εκτελείται το λογισμικό και τους κόμβους επεξεργασίας που εκτελούνται οι διεργασίες του λογισμικού. Όψη περιπτώσεων χρήσης (use case view). Περιλαμβάνει τις σημαντικότερες περιπτώσεις χρήσης οι οποίες επηρεάζουν την αρχιτεκτονική. 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης41

42 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης42 UML και τεκμηρίωση αρχιτεκτονικής Μοντέλα και διαγράμματα της UML χρησιμοποιούνται και για την τεκμηρίωση της αρχιτεκτονικής. Η λογική όψη περιλαμβάνει διαγράμματα κλάσεων, αντικειμένων, πακέτων και μηχανής καταστάσεων. Η όψη διεργασιών περιλαμβάνει διαγράμματα κλάσεων και αντικειμένων που περιλαμβάνουν πληροφορία των διεργασιών. Η όψη υλοποίησης περιλαμβάνει διαγράμματα συστατικών. Η όψη της παράταξης περιλαμβάνει διαγράμματα παράταξης. 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης42

43 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης43 UML και τεκμηρίωση αρχιτεκτονικής Η όψη περιπτώσεων χρήσης, διαγράμματα περιπτώσεων χρήσης και βασικά διαγράμματα επικοινωνίας ή ακολουθίας για την επίδειξη της συμπεριφοράς του λογισμικού για τις σημαντικές περιπτώσεις χρήσης. Η όψη των περιπτώσεων χρήσης περιέχει πλεονάζουσα πληροφορία αλλά είναι το σημείο της κοινής αναφοράς των υπόλοιπων όψεων. Είναι η όψη που θέτει τις υπόλοιπες στην υπηρεσία της ικανοποίησης των απαιτήσεων. 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης43

44 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης44 UML και τεκμηρίωση αρχιτεκτονικής Αν και η τεκμηρίωση των όψεων βασίζεται σε υφιστάμενα μοντέλα, δεν περιλαμβάνει όλα τα διαφορετικά μοντέλα με τις λεπτομέρειές τους. Μοντέλα σχεδίασης, όπως τα διαγράμματα κλάσεων και ακολουθίας, μπορεί να είναι λεπτομερή, όταν εξυπηρετούν τη λεπτομερή σχεδίαση. Όταν όμως τεκμηριώνεται η λογική όψη, χρησιμοποιούνται μόνο διαγράμματα κλάσεων με τις σημαντικότερες κλάσεις, ή διαγράμματα ακολουθίας με τη σημαντικότερη συμπεριφορά. Αντίστοιχα, το μοντέλο των περιπτώσεων χρήσης περιέχει ενδεχομένως αρκετές περιπτώσεις χρήσης. Η τεκμηρίωση της όψης των περιπτώσεων χρήσης όμως περιλαμβάνει μόνο τις σημαντικότερες, αυτές δηλαδή που επηρεάζουν σε μεγάλο βαθμό την αρχιτεκτονική. 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης44

45 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης45 Επεκτάσεις του μοντέλου των τεσσάρων όψεων Η όψη δεδομένων (data view) που αφορά τη σχεδίαση της βάσης δεδομένων και τους μηχανισμούς απεικόνισης των αντικειμένων σε πίνακες της βάσης δεδομένων. Η όψη δεδομένων είναι απαραίτητη, όταν το λογισμικό είναι μέρος ενός πληροφοριακού συστήματος. Η όψη της ασφάλειας (security view) που αφορά τους μηχανισμούς ασφάλειας που ακολουθούνται. Εισάγοντας διαφορετικές όψεις στην τεκμηρίωση της αρχιτεκτονικής, το μοντέλο των 4+1 όψεων γενικεύεται σε μοντέλο N+1 όψεων, οι οποίες ορίζονται ανάλογα με τη βαρύτητα κάθε όψης στη διαμόρφωση της αρχιτεκτονικής. Όλες οι διαφορετικές όψεις της αρχιτεκτονικής συγκεντρώνονται σε ένα έγγραφο το οποίο τεκμηριώνει την αρχιτεκτονική. Το έγγραφο αυτό καλείται Έγγραφο Αρχιτεκτονικής Λογισμικού (Software Architecture Document) το οποίο περιγράφει τις σημαντικές αρχιτεκτονικές αποφάσεις. 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης45

46 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης46 Διαγράμματα πακέτων Τα πακέτα της UML είναι ένας μηχανισμός γενικού σκοπού για την οργάνωση και ομαδοποίηση των στοιχείων μοντελοποίησης. Τα πακέτα της UML παραπέμπουν σε μεγάλο βαθμό στα πακέτα της Java και έχουν δύο χρήσεις: Η πρώτη χρήση είναι η οργάνωση των μοντέλων που δημιουργούνται με τη UML. Η δεύτερη χρήση είναι η απεικόνιση της οργάνωσης των κλάσεων του λογισμικού σε πακέτα λογισμικού του κώδικα. 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης46

47 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης472009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης47 Διαγράμματα πακέτων

48 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης48 Διαγράμματα πακέτων Τα περιεχόμενα ενός πακέτου μπορεί να είναι στοιχεία μοντελοποίησης όπως κλάσεις, μπορεί να είναι άλλα πακέτα, περιπτώσεις χρήσης και διαγράμματα της UML. Όταν χρησιμοποιούμε τα πακέτα της UML για την οργάνωση των μοντέλων, μπορούμε να οργανώσουμε τα μοντέλα βάσει των αρχιτεκτονικών όψεων. Μπορούμε να οργανώσουμε τα διαφορετικά μοντέλα βάσει των 4+1 όψεων. Η οργάνωση αυτή είναι χρήσιμη, όταν τα μοντέλα δημιουργούνται με τη χρήση εργαλείων CASE (Computer Aided Software Engineering). 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης48

49 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης49 Διαγράμματα πακέτων Όταν χρησιμοποιούμε τα πακέτα για την οργάνωση του κώδικα, τότε τα πακέτα είναι το αντίστοιχο στοιχείο μοντελοποίησης που μας οδηγεί στα πακέτα της Java. Τα διαγράμματα πακέτων χρησιμοποιούνται για την τεκμηρίωση της λογικής αρχιτεκτονικής του λογισμικού. 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης49

50 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης50 Διαγράμματα συστατικών Η UML παρέχει τα διαγράμματα συστατικών (component diagrams) για να επιδείξει την ύπαρξη και χρήση των συστατικών στο λογισμικό. Τα διαγράμματα συστατικών στη UML 2 δεν ασχολούνται με τη φυσική υπόσταση των συστατικών και δε δείχνουν το πώς εντάσσονται σε φυσικό επίπεδο. Η φυσική υπόσταση των συστατικών είναι τα προϊόντα (artifacts) τα οποία εμφανίζονται σε διαγράμματα παράταξης. Τα διαγράμματα συστατικών εμφανίζουν τη λογική τους υπόσταση ή την υπόσταση που παίρνουν στο χρόνο εκτέλεσης του λογισμικού. Τα διαγράμματα συστατικών δείχνουν παρεχόμενες και απαιτούμενες διεπαφές και την εσωτερική δομή των συστατικών. 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης50

51 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης512009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης51 Διαγράμματα συστατικών

52 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης52 Διαγράμματα συστατικών Στο σχήμα 7-18 το συστατικό OrderComponet αναπαριστά μία παραγγελία. Το συστατικό παρέχει τη διεπαφή OrderManagement στους πελάτες του και απαιτεί και την υλοποίηση της διεπαφής Discount από τον πελάτη για τον υπολογισμό της έκπτωσης της παραγγελίας. Με άλλα λόγια το συστατικό OrderComponent παρέχει την υλοποίηση μίας διεπαφής (OrderManagement στο σχήμα) και ταυτόχρονα ζητά από τον πελάτη την υλοποίηση κάποιας διεπαφής (Discount στο σχήμα), προκειμένου να ανταποκριθεί στις αρμοδιότητές του. Οι διεπαφές είναι το μέσο με το οποίο ένα συστατικό επικοινωνεί με τον περιβάλλον του. Η συνεργασία διαφορετικών συστατικών γίνεται διά μέσου των διεπαφών τους, όπως στο σχήμα ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης52

53 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης532009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης53 Συνεργασία συστατικών

54 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης54 Συνεργασία συστατικών Το σχήμα μας δείχνει τον τρόπο που συνεργάζονται τα συστατικά. Το συστατικό OrderComponent παρέχει τη διεπαφή OrderManagement. Τη διεπαφή αυτή χρησιμοποιεί το συστατικό Customer, προκειμένου να αξιοποιήσει τις υπηρεσίες του συστατικού OrderComponent. Ταυτόχρονα το συστατικό OrderComponent συνεργάζεται με το συστατικό DiscountCalculator. Το συστατικό DiscountCalculator παρέχει την υλοποίηση της διεπαφής Discount στο συστατικό OrderComponent. 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης54

55 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης552009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης55 Εσωτερική δομή συστατικού

56 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης56 Εσωτερική δομή συστατικού Σε ένα διάγραμμα συστατικών μπορεί να εμφανιστούν και τα τμήματα κάποιου συστατικού. Η εσωτερική (μη δημόσια) δομή του συστατικού της παραγγελίας εμφανίζεται στο σχήμα Το σχήμα 7-20 μας αποκαλύπτει το εσωτερικό του συστατικού της παραγγελίας. Το συστατικό υλοποιείται από τις κλάσεις Order και LineItem. Προφανώς αυτές τις κλάσεις δεν τις γνωρίζει ο πελάτης. 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης56

57 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης572009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης57 Θύρες και συνδετήρες στα διαγράμματα συστατικών

58 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης582009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης58 Διαγράμματα συστατικών

59 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης59 Διαγράμματα παράταξης Τα διαγράμματα πακέτων παρέχουν μία εικόνα της λογικής οργάνωσης σε μονάδες προγράμματος. Τα διαγράμματα παράταξης (deployment diagrams) παρουσιάζουν το πραγματικό περιβάλλον στο οποίο λειτουργεί το λογισμικό. Ένα διάγραμμα παράταξης παρουσιάζει συσκευές του υλικού και τις φυσικές μονάδες λογισμικού που διανέμονται στο υλικό. Τα διαγράμματα παράταξης είναι ένα μέσο για την τεκμηρίωση της φυσικής αρχιτεκτονικής του συστήματος. Το βασικό στοιχείο ενός διαγράμματος παράταξης είναι οι κόμβοι (nodes). 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης59

60 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης60 Διαγράμματα παράταξης Η πρώτη κατηγορία των κόμβων είναι οι συσκευές (devices) που αναπαριστούν φυσικές μονάδες επεξεργασίας που αντιστοιχούν στο υλικό. Οι συσκευές έχουν μνήμη και επεξεργαστική ικανότητα. Η δεύτερη κατηγορία των κόμβων είναι τα περιβάλλοντα εκτέλεσης (execution environments). Περιβάλλοντα εκτέλεσης είναι λογισμικό συστημάτων, όπως λειτουργικά συστήματα, συστήματα διαχείρισης βάσεων δεδομένων κ.ά. 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης60

61 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης61 Διαγράμματα παράταξης 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης61

62 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης622009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης62 Μονοπάτια επικοινωνίας στα διαγράμματα παράταξης

63 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης63 Μονοπάτια επικοινωνίας στα διαγράμματα παράταξης Οι κόμβοι επικοινωνούν μεταξύ τους μέσω μονοπατιών επικοινωνίας (communications paths) και απεικονίζουν διασύνδεση μέσω δικτύου. Τα μονοπάτια επικοινωνίας είναι εξειδίκευση των συσχετίσεων και συμβολίζονται με απλές γραμμές (σχήμα 7-23). Ένας κόμβος μπορεί να περιέχει ένα προϊόν (artifact) το οποίο είναι μία διακριτή φυσική οντότητα του λογισμικού και το οποίο είναι συνήθως ένα αρχείο. Ένα προϊόν μπορεί να είναι ένα εκτελέσιμο αρχείο, αρχείο ρυθμίσεων, σελίδες HTML κ.ά. Ένα προϊόν φέρει τη λέξη-κλειδί «artifact» ή ένα εικονίδιο που παρουσιάζεται στο σχήμα Οι κόμβοι περιέχουν προϊόντα (artifacts) που είναι οι φυσικές μονάδες λογισμικού, όπως εκτελέσιμα αρχεία, αρχεία jar, αρχεία ρυθμίσεων, σελίδες HTML κ.λπ. 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης63

64 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης642009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης64 Δύο συμβολισμοί για τα προϊόντα στα διαγράμματα παράταξης

65 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης652009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης65 Ένα συνολικό διάγραμμα παράταξης

66 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης662009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης66 Ένα συνολικό διάγραμμα παράταξης Το σχήμα 7-25 μας δίνει ένα συνολικό διάγραμμα παράταξης με κόμβους, μονοπάτια επικοινωνίας και προϊόντα. Είναι ένα τυπικό διάγραμμα διανομής τμημάτων του λογισμικού μίας διαδικτυακής εφαρμογής. Το διάγραμμα εμφανίζει μία αρχιτεκτονική τριών επιπέδων (3-tier architecture). Ένας διακομιστής φιλοξενεί τη βάση δεδομένων, ένας δεύτερος διακομιστής φιλοξενεί τη λογική του πεδίου, ενώ η διεπαφή χρήστη φιλοξενείται στον browser του χρήστη.

67 2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης672009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης67 Ένα συνολικό διάγραμμα παράταξης Υπάρχει βέβαια μία σημαντική διαφορά με τα τυπικά τρία στρώματα των διαστρωματωμένων αρχιτεκτονικών. Η λογική αρχιτεκτονική μπορεί να αποτελείται από τρία στρώματα, αλλά η φυσική της αρχιτεκτονική να είναι δύο επιπέδων. Θα μπορούσε για παράδειγμα το στρώμα της διεπαφής χρήστη να φιλοξενείται μαζί με τη λογική του. Συμπερασματικά τα στρώματα στις διαστρωματωμένες αρχιτεκτονικές ασχολούνται με τη λογική αρχιτεκτονική, δηλαδή με την οργάνωση των μονάδων λογισμικού, ενώ οι αρχιτεκτονικές πολλών επιπέδων (tiers) σχετίζονται με τον τρόπο διανομής διαφορετικών μονάδων σε κόμβους επεξεργασίας.


Κατέβασμα ppt "2009ΟΠΑ -Τεχνολογία Λογισμικού – Εμμ. Γιακουμάκης1 ΟΙΚΟΝΟΜΙΚΟ ΠΑΝΕΠΙΣΤΗΜΙΟ ΑΘΗΝΩΝ ΤΜΗΜΑ ΠΛΗΡΟΦΟΡΙΚΗΣ ΤΕΧΝΟΛΟΓΙΑ ΛΟΓΙΣΜΙΚΟΥ Αρχιτεκτονική Λογισμικού Μανόλης."

Παρόμοιες παρουσιάσεις


Διαφημίσεις Google