2.2 Εισαγωγή στη UML

Η UML ή Unified Modelling Language (Ενοποιημένη Γλώσσα Μοντελοποίησης) είναι μια οπτικοποιημένη (visual) γλώσσα μοντελοποίησης η οποία σκοπό έχει τη δημιουργία, τον προσδιορισμό, την οπτικοποίηση και την τεκμηρίωση όλων των τεχνουργημάτων ενός συστήματος λογισμικού. Αναπτύχθηκε από τους Grady Booch, James Rumbaugh και Ivar Jacobson οι οποίοι ενοποίησαν τα μοντέλα τους (Booch method, Object Modeling Technique (OMT) και Object Oriented Software Engineering (OOSE) αντίστοιχα) για την παραγωγή μιας ενοποιημένης γλώσσας μοντελοποίησης. Αποτελείται από στοιχεία μοντελοποίησης, δηλ. αφαιρέσεις του συστήματος προς μοντελοποίηση. Είναι σημαντικό να σημειώσουμε ότι η UML δεν αποτελεί μια μεθοδολογία/διαδικασία ανάπτυξης λογισμικού, μπορεί όμως να χρησιμοποιηθεί από τέτοιες διαδικασίες όπως π.χ. η Rational Unified Process (RUP), Iconix, Agile κ.ά.

Εκδόσεις: 1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 2.0

Η έκδοση 2.0 προωθεί την Προσανατολισμένη στα Μοντέλα Αρχιτεκτονική (Model Driven Architecture - MDA), δηλ. την παραγωγή ‘εκτελέσιμων’ μοντέλων που θα μπορούν να χρησιμοποιηθούν κατάλληλα από διάφορα εργαλεία.

Η UML 2.0 αποτελείται από 13 τύπους διαγραμμάτων τα οποία κατηγοριοποιούνται σε δυο μεγάλες κατηγορίες: διαγράμματα δομής (structural diagrams) και διαγράμματα συμπεριφοράς (behavioural diagrams):

Διαγράμματα δομής (structural diagrams) ή Στατικά διαγράμματα

Διαγράμματα κλάσεων (class diagrams)
Διαγράμματα αντικειμένων (Object diagrams)
Διαγράμματα συνιστωσών/εξαρτημάτων (component diagrams)
Διαγράμματα σύνθετης δομής (Composite Structure diagrams)
Διαγράμματα βιβλιοθηκών (Package diagrams)
Διαγράμματα εγκατάστασης (Deployment diagrams)

Διαγράμματα συμπεριφοράς (behavioural diagrams) ή Δυναμικά διαγράμματα

Διαγράμματα σεναρίων (Use Case diagrams)
Διαγράμματα δραστηριότητας (Activity diagrams)
Διαγράμματα επικοινωνίας (Communication diagrams)
Διαγράμματα αλληλεπίδρασης (Interaction Overview diagrams)
Διαγράμματα ακολουθίας/αλληλουχίας (Sequence diagrams)
Διαγράμματα μετάβασης κατάστασης (State Machine diagrams)
Διαγράμματα χρονισμού (Timing diagrams)

Άλλη κατηγοριοποίηση είναι οι 4+1 όψεις (views) όπως φαίνεται στο ακόλουθο σχήμα:

Εικόνα 2.2.1 4+1 όψεις της UML

Λογική Όψη (Logical View) ή Όψη Σχεδίασης (Design View)

Αναπαριστά το πώς θα “χτιστεί” το σύστημα/πρόγραμμα δηλ. τις κλάσεις, διεπαφές και πρότυπα (patterns) που θα χρησιμοποιηθούν. Αποτελείται από:

Διαγράμματα κλάσεων (class diagrams)
Διαγράμματα αντικειμένων (Object diagrams)
Διαγράμματα σύνθετης δομής (Composite Structure diagrams)
Διαγράμματα δραστηριότητας (Activity diagrams)
Διαγράμματα ακολουθίας/αλληλουχίας (Sequence diagrams)

Όψη Συνιστωσών (Component View) ή Όψη Υλοποίησης (Implementation View)

Δίνει έμφαση στα αρθρώματα, βιβλιοθήκες, αρχεία, πόρους και εξαρτήσεις του συστήματος. Αποτελείται από:

Διαγράμματα συνιστωσών/εξαρτημάτων (component diagrams)
Διαγράμματα σύνθετης δομής (Composite Structure diagrams)
Διαγράμματα αλληλεπίδρασης (Interaction Overview diagrams)
Διαγράμματα μετάβασης κατάστασης (State Machine diagrams)

Όψη Εγκατάστασης (Deployment View)

Περιγράφει πώς εγκαθίσταται, διαμορφώνεται και εκτελείται ένα σύστημα. Περιγράφει το απαιτούμενο υλικό (hardware) για να εκτελεστεί και να επικοινωνήσει το σύστημα (π.χ. πλεονασμό - redundancy, τοπολογία δικτύου κλπ.). Αποτελείται από:

Διαγράμματα εγκατάστασης (Deployment diagrams)
Διαγράμματα συνιστωσών/εξαρτημάτων (component diagrams)
Διαγράμματα αλληλεπίδρασης (Interaction Overview diagrams)

Όψη Διαδικασιών (Process View)

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

Διαγράμματα αλληλεπίδρασης (Interaction Overview diagrams)
Διαγράμματα δραστηριότητας (Activity diagrams)
Διαγράμματα μετάβασης κατάστασης (State Machine diagrams)
Διαγράμματα ακολουθίας/αλληλουχίας (Sequence diagrams)

Όψη σεναρίων (Use Case view)

Περιγράφει τη λειτουργικότητα του συστήματος με βάση τις απαιτήσεις των χρηστών. Αποτελείται από:

Διαγράμματα σεναρίων (Use Case diagrams)
Διαγράμματα δραστηριότητας (Activity diagrams)
Διαγράμματα αλληλεπίδρασης (Interaction Overview diagrams)

Παρακάτω περιγράφουμε πιο αναλυτικά καθένα από τα 13 αυτά διαγράμματα.

1. Όψη σεναρίων (Use Case view)

Η όψη σεναρίων αποτελείται από τα (1) διαγράμματα σεναρίων (Use Case diagrams) τα οποία ανήκουν στα διαγράμματα συμπεριφοράς (behavioural). Χρησιμοποιούνται στο επίπεδο της ανάλυσης για να μετατρέψουν τις απαιτήσεις του συστήματος σε σενάρια χρήσης. Παρέχουν μια όψη του συστήματος ανεξάρτητη της υλοποίησης που δείχνει τι υποτίθεται ότι πρέπει να κάνει το σύστημα στοχεύοντας στο να κατανοήσει τις ανάγκες του χρήστη και όχι τις λεπτομέρειες της υλοποίησης.

Εικόνα 2.2.2 Συμβολολογία διαγράμματος σεναρίου

Ένας ρόλος (actor) είναι κάτι εκτός του συστήματος που έχουμε να αναπτύξουμε, π.χ. ένας χρήστης ή ακόμα κι ένα απομακρυσμένο σύστημα με το οποίο πρέπει να επικοινωνήσει το πρόγραμμά μας.

Ένα σενάριο (use case) περιγράφει μια συμπεριφορά του συστήματος, δηλ. μια ακολουθία από βήματα που πρέπει να διεκπεραιώσει ένας ρόλος για να πετύχει κάτι με το σύστημα.

Όπως φαίνεται στην Εικόνα 2.2.2, μπορούμε να ορίσουμε διάφορες σχέσεις σε ένα διάγραμμα σεναρίων:

Συσχέτιση (Relationship) μεταξύ σεναρίων και ρόλων δηλώνει ότι υπάρχει μια αλληλεπίδραση
Κληρονομικότητα (Generalization) μεταξύ ρόλων ή μεταξύ σεναρίων, σημαίνει ειδίκευση, δηλ. ότι εξειδικεύουμε τις λειτουργίες του γενικευμένου ρόλου ή σεναρίου μ’ έναν πιο ειδικευμένο ρόλο ή σενάριο. Π.χ. στο παράδειγμα της εικόνας 3 βλέπουμε ότι ο ρόλος Supervisor μπορεί κάνει όλες τις λειτουργίες του ρόλου SalesPerson αλλά έχει και πιο ειδικευμένες αρμοδιότητες
Περιλαμβάνει (Includes) χρησιμοποιείται όταν ένα σενάριο περιλαμβάνει ένα άλλο σενάριο (π.χ. ένα σενάριο περιλαμβάνει το σενάριο Login)
Επέκταση (Extends) χρησιμοποιείται όταν ένα σενάριο μπορεί να επεκταθεί με κάποιο άλλο σενάριο σε κάποια σημεία (extension points)

Στο παράδειγμα της εικόνας 3 βλέπουμε τι μπορεί ο ρόλος (actor) πελάτης (customer) (αλλά κι οι άλλοι ρόλοι: SalesPerson, Supervisor, ShippingClerk) να κάνει(-ουν) με το σύστημα. Π.χ. μπορεί να υποβάλλει μια παραγγελία (Σενάριο: Place order).

Εικόνα 2.2.3 Παράδειγμα διαγράμματος σεναρίου

Σε κάθε σενάριο επισυνάπτεται συνήθως μια λεπτομερής περιγραφή του ποια βήματα θα πρέπει ν’ ακολουθήσει ο ρόλος για να διεκπεραιώσει μ’ επιτυχία το σενάριο, λαμβάνοντας φυσικά υπόψιν και τις εξαιρέσεις (τι θα συμβεί αν κάτι πάει στραβά). Τα βήματα του σεναρίου μπορούν να περιγραφούν με διαγράμματα δραστηριότητας (activity diagrams).

2. Λογική Όψη (Logical View) ή Όψη Σχεδίασης (Design View)

Αποτελείται από τα παρακάτω στατικά διαγράμματα:

Διαγράμματα κλάσεων (Class diagrams)
Διαγράμματα αντικειμένων (Object diagrams)
Διαγράμματα βιβλιοθηκών (Package diagrams)

Διαγράμματα κλάσεων (Class diagrams)

Τα διαγράμματα κλάσεων αναπαριστούν τις κλάσεις/διεπαφές ενός συστήματος και τις σχέσεις μεταξύ τους. Σ’ αυτά τα διαγράμματα θα επικεντρωθούμε αυτή την εβδομάδα.

Μια κλάση αναπαριστά μια ομάδα ίδιων πραγμάτων που έχουν κοινή κατάσταση (state) και συμπεριφορά (behavior). Μια κλάση αναπαρίσταται στη UML ως ένα ορθογώνιο παραλληλογράμμο (βλ. Εικόνα 2.2.4) που αποτελείται από τρία μέρη: το όνομα της κλάσης, τα γνωρίσματά της και τις μεθόδους της.

Εικόνα 2.2.4 Συμβολολογία διαγράμματος κλάσεων

Μια abstract κλάση δηλώνεται με πλάγια γράμματα. Ένα στατικό πεδίο ή μια στατική μέθοδος φαίνεται υπογραμμισμένο(-η). Μπορούμε να κατηγοριοποιήσουμε τις κλάσεις χρησιμοποιώντας στερεότυπα (stereotypes), π.χ. <<interface>>.

Π.χ. η κλάση Car που είδαμε στο προηγούμενο μάθημα αναπαρίσταται ως εξής:

Εικόνα 2.2.5 Παράδειγμα διαγράμματος κλάσης στη UML

Τα γνωρίσματα μιας κλάσης μπορεί να είναι κάποιου από τους τύπους δεδομένων της Java (π.χ. int, String κλπ.) ή τύπος δεδομένων μιας άλλης κλάσης και στην περίπτωση αυτή λέμε ότι οι δυο αυτές κλάσεις σχετίζονται μεταξύ τους.

Στην Εικόνα 2.2.4 βλέπουμε επίσης τις διάφορες σχέσεις μεταξύ των κλάσεων:

συσχέτιση (association)
κληρονομικότητα (generalisation)
εξάρτηση (dependency)
συσσωμάτωση (aggregation)
σύνθετη συσσωμάτωση (composite aggregation ή composition)

Η σχέση της εξάρτησης είναι η πιο αφαιρετική από τις υπόλοιπες και σημαίνει ότι στο σώμα μιας μεθόδου της κλάσης χρησιμοποιείται μια άλλη κλάση. Πρόκειται δηλ. για μια προσωρινή σχέση που συνήθως δηλώνεται ως “χρησιμοποιεί (uses a)”.

Για τις υπόλοιπες σχέσεις θα μιλήσουμε στα επόμενα μαθήματα αυτής της εβδομάδας. Η Εικόνα 2.2.5 δείχνει ένα παράδειγμα σύνθετης συσσωμάτωσης (composition) μεταξύ των δυο κλάσεων.

Επίσης μπορούμε να προσθέσουμε την πολλαπλότητα (multiplicity) σε μια σχέση που δείχνει πόσα αντικείμενα μιας κλάσης σχετίζονται με μια άλλη. Στην Εικόνα 2.2.5 βλέπουμε ότι ένα αυτοκίνητο μπορεί να έχει μια μόνο μηχανή (αν και υπάρχουν αυτοκίνητα με 2 μηχανές, η μια από τις οποίες μπορεί να είναι ηλεκτρική). Αν η πολλαπλότητα σε μια σχέση είναι >1 τότε συνήθως αυτό σημαίνει ότι υλοποιείται μέσω μιας συλλογής ή πίνακα (π.χ. Engine[] engines = new Engine[2]).

Πέρα απ’ τον τύπο δεδομένων, ένα γνώρισμα ή μια μέθοδος διαθέτει και ορατότητα (visibility). Θα εξηγήσουμε τι σημαίνουν τα (+, -) και (#) στο επόμενο μάθημα. Τέλος, μπορούμε να προσθέσουμε και περιορισμούς (constraints) με {}, π.χ. -maxSpeed : int {[0..250]}. Η UML 2.0 διαθέτει μια ειδική γλώσσα, την Object Contraint Language (OCL) για τη συγγραφή περιορισμών η οποία διαθέτει μια γραμματική η οποία μπορεί να επικυρωθεί από εργαλεία μοντελοποίησης.

Τέλος, στην Εικόνα 2.2.5 βλέπουμε και το σύμβολο του σχολίου/σημειώματος (note) που μπορεί να χρησιμοποιηθεί σ’ όλα τα διαγράμματα.

Διαγράμματα αντικειμένων (Object diagrams)

Τα διαγράμματα αντικειμένων έχουν την ίδια συμβολολογία με τα διαγράμματα κλάσεων και δείχνουν τις σχέσεις των αντικειμένων των κλάσεων σε μια συγκεκριμένη χρονική στιγμή. Χρησιμοποιούνται για να εμφανίσετε στιγμιότυπα των σχέσεων μεταξύ των αντικειμένων κατά την εκτέλεση του προγράμματος.

Εικόνα 2.2.6 Παράδειγμα διαγράμματος αντικειμένων

Διαγράμματα βιβλιοθηκών (Package diagrams)

Χρησιμοποιούνται για να ομαδοποιούμε κλάσεις σε πακέτα ή βιβλιοθήκες. Αντιστοιχούν στις βιβλιοθήκες (packages) της γλώσσας.

Εικόνα 2.2.7 Παράδειγμα διαγράμματος βιβλιοθηκών

Μια βιβλιοθήκη (package) είναι ένας υποδοχέας (container) στοιχείων μοντελοποίησης, ένας μηχανισμός γενικού σκοπού οργάνωσης στοιχείων σε ομάδες. Τα διαγράμματα βιβλιοθηκών μπορούν να χρησιμοποιηθούν σε κάθε βήμα της UML. Μια βιβλιοθήκη μπορεί να είναι υποδοχέας σεναρίων, κλάσεων, συνιστωσών κλπ.

3. Όψη Συνιστωσών/Εξαρτημάτων (Component View)

Αποτελείται από τα παρακάτω διαγράμματα δομής:

Διαγράμματα συνιστωσών/εξαρτημάτων (Component diagrams)
Διαγράμματα σύνθετης δομής (Composite Structure diagrams)

Διαγράμματα συνιστωσών/εξαρτημάτων (Component diagrams)

Τα διαγράμματα συνιστωσών/εξαρτημάτων δείχνουν την οργάνωση και τις εξαρτήσεις μεταξύ των αρθρωμάτων ή των βιβλιοθηκών του συστήματος. Μπορούν να ομαδοποιήσουν μικρότερα στοιχεία, όπως κλάσεις, σε μεγαλύτερα, π.χ. βιβλιοθήκες εγκατάστασης (jar files (JAR: Java ARchive)).

Εικόνα 2.2.8 Συμβολολογία διαγράμματος συνιστωσών/εξαρτημάτων

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

Οι συνιστώσες του πηγαίου κώδικα (εξαρτήσεις μεταγλώττισης) απεικονίζουν τις εξαρτήσεις μεταγλώττισης μεταξύ των αρχείων πηγαίου κώδικα
Οι συνιστώσες εκτέλεσης (εξαρτήσεις κατά την εκτέλεση) δείχνουν την αντιστοιχία των κλάσεων σε βιβλιοθήκες (π.χ. αρχεία jar) καθώς και τις εξαρτήσεις με άλλες βιβλιοθήκες.

Υπάρχουν δυο τρόποι αναπαράστασης των εξαρτημάτων: διαφανής (white box) όπου φαίνεται η εσωτερική δομή των εξαρτημάτων και αδιαφανής (black box) που δε φαίνεται και φαίνονται μόνο οι δημόσιες διεπαφές του εξαρτήματος.

Εικόνα 2.2.9 Παράδειγμα διαγράμματος συνιστωσών/εξαρτημάτων

Διαγράμματα Σύνθετης Δομής (Composite Structure diagrams)

Τα διαγράμματα σύνθετης δομής εισήχθησαν στην έκδοση 2.0. Μας επιτρέπουν να μοντελοποιήσουμε σύνθετες σχέσεις/δομές (π.χ. πρότυπα σχεδίασης (design patterns) ή μοντέλα του πραγματικού κόσμου). Μας επιτρέπουν ακόμα να αποσυνθέσουμε μια σύνθετη δομή στα εσωτερικά του τμήματα και να απεικονίσουμε πώς αυτά επικοινωνούν μεταξύ τους. Έχει παρόμοιο ρόλο με ένα διάγραμμα κλάσεων αλλά σας επιτρέπει να απεικονίσετε την εσωτερική δομή πολλών κλάσεων και τις αλληλεπιδράσεις μεταξύ τους. Μπορείτε να αναπαριστήσετε γραφικά τα μέρη των κλάσεων και συσχετίσεις τόσο μεταξύ τους όσο και με άλλες κλάσεις.

Εικόνα 2.2.10 Συμβολολογία διαγράμματος σύνθετης δομής

Όπως φαίνεται στην Εικόνα 2.2.10, ένα διάγραμμα σύνθετης δομής αποτελείται από:

Δομή (structure): ένα σύνολο διασυνδεδεμένων στοιχείων που υπάρχουν κατά τη διάρκεια εκτέλεσης για να παρέχουν συλλογικά κάποια λειτουργία. Π.χ. υποσυστήματα/συνιστώσες/εξαρτήματα (components) ή βιβλιοθήκες (packages) ή ακόμα και κλάσεις είναι παραδείγματα δομών. Μια δομή αποτελείται από μέρη (parts) και συνδέσεις (connectors) μεταξύ τους. Τα μέρη μπορεί να είναι εσωτερικά (composition) ή εξωτερικά (aggregation) και μπορούμε να ορίσουμε πολλαπλότητα (multiplicity) και περιορισμούς (constraints) σ’ αυτά. Επίσης, μπορούμε να απεικονίσουμε γνωρίσματα (properties) για τα μέρη (parts).
Σύνδεση (Connector): αναπαριστούν κάποιου είδους επικοινωνία μεταξύ τμημάτων (parts) μιας εσωτερικής δομής ή μεταξύ δομών. Κάθε σύνδεση μπορεί να έχει προαιρετικά ένα όνομα και έναν τύπο (κλάση) με τη μορφή όνομα : κλάση. Μπορούμε ακόμα να ορίσουμε περιορισμούς (constraints) και πολλαπλότητα (multiplicity) σε μια σύνδεση.
Θύρα (Port): προσφέρει τη λειτουργικότητα μιας δομής χωρίς να εκθέτει λεπτομέρειες της εσωτερικής υλοποίησης αυτής της λειτουργίας. Οι θύρες μπορεί να ‘ναι εσωτερικές στη δομή ή δημόσιες και μπορούν να έχουν όνομα.
διεπαφή (interface): όπως και στα διαγράμματα κλάσεων, προσφέρονται δυο ειδών διεπαφές: προσφερόμενες (provided) και απαιτούμενες (required)
Συνεργασία (Collaborationα): αναπαριστούν πρότυπα μοντελοποίησης (π.χ. πρότυπα σχεδίασης (design patterns))

Ένα παράδειγμα διαγράμματος σύνθετης δομής φαίνεται στην Εικόνα 2.2.11.

Εικόνα 2.2.11 Παράδειγμα διαγράμματος σύνθετης δομής

Εδώ βλέπουμε την κλάση Car που είδαμε προηγούμε να αποτελείται από δυο κατηγορίες (εξωτερικών) τμημάτων: 2 μηχανές (υβριδικό) και ένα σύστημα κατεύθυνσης. Βλέπουμε τις διάφορες θύρες που παρέχονται καθώς και τις απαιτούμενες διεπαφές για να φορτιστεί (ή/και γεμίσει με καύσιμο) το αυτοκίνητο. Οι θύρες στα δεξιά διαθέτουν όνομα. Υπάρχουν 4 δημόσιες και 3 εσωτερικές (προστατευόμενες) θύρες που ενώνονται μεταξύ τους όπως φαίνεται στην εικόνα. Στην Εικόνα 2.2.βλέπουμε κι ένα παράδειγμα πολλαπλής σύνδεσης (multiple connector) που επιτρέπει στις δυο υποδοχές (gas, electric) να συνδέονται με τη μηχανή.

4. Όψη Εγκατάστασης (Deployment View)

Αποτελείται από το παρακάτω στατικό διάγραμμα:

Διαγράμματα εγκατάστασης (Deployment diagrams)

Τα διαγράμματα εγκατάστασης δείχνουν πώς εγκαθίσταται στο υλικό (σε διακομιστές, ΒΔ, συσκευές δικτύωσης κλπ.) και πώς εκτελείται πραγματικά το σύστημα/πρόγραμμα, δηλ. τους υπολογιστές, τις δικτυακές συσκευές κλπ. που απαιτούνται.

Αποτελείται από:

Κόμβους (Nodes): Μια υπολογιστική μονάδα που αντιπροσωπεύει έναν υπολογιστικό πόρο, που γενικά έχει τουλάχιστον μνήμη και επεξεργαστική ικανότητα. Υπάρχουν δυο κατηγορίες κόμβων: περιβάλλοντα εκτέλεσης (execution environments) (π.χ. ένας διακομιστής εφαρμογών - application server) και συσκευές (devices) (<<device>>).
Συνιστώσες/Εξαρτήματα (Components): όπως στα διαγράμματα συνιστωσών/εξαρτημάτων, τα οποία αντιπροσωπεύουν τεχνουργήματα λογισμικού όπως αρχεία, πλαίσια εργασίας (frameworks) κλπ
Συνδέσεις (Connections): υποδεικνύουν μια επικοινωνία μεταξύ δύο κόμβων.
Τεχνουργήματα (Artifacts): παρέχουν πληροφορίες για το σύστημα, π.χ. το εγχειρίδιο χρήσης

Εικόνα 2.2.12 Συμβολολογία διαγράμματος εγκατάστασης

Εικόνα 2.2.13 Παράδειγμα διαγράμματος εγκατάστασης

5. Όψη Διαδικασιών (Process View)

Η όψη διαδικασιών αποτελείται από τα παρακάτω δυναμικά διαγράμματα:

Διαγράμματα ακολουθίας/αλληλουχίας (Sequence diagrams)
Διαγράμματα επικοινωνίας (Communication diagrams)
Διαγράμματα μετάβασης κατάστασης (State Machine diagrams)
Διαγράμματα δραστηριότητας (Activity diagrams)
Διαγράμματα αλληλεπίδρασης (Interaction Overview diagrams)
Διαγράμματα χρονισμού (Timing diagrams)

Διαγράμματα ακολουθίας/αλληλουχίας (Sequence diagrams)

Τα διαγράμματα ακολουθίας ή αλληλουχίας είναι ένας τύπος διάγραμματος αλληλεπίδρασης (interaction) που απεικονίζει τον τύπο και τη χρονική σειρά των μηνυμάτων που ανταλλάσονται μεταξύ των αντικειμένων κατά την εκτέλεση του προγράμματος.

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

Εικόνα 2.2.14 Συμβολολογία διαγράμματος ακολουθίας

Ένα διάγραμμα αλληλουχίας αποτελείται από:

Αντικείμενα (objects) τα οποία παριστάνονται από κουτιά στην κορυφή μιας διακεκομμένης κάθετης γραμμής.
Οι διακεκομμένες κάθετες γραμμές ονομάζονται γραμμές ζωής (lifelines) και αντιπροσωπεύουν την ύπαρξη των αντικειμένων κατά τη διάρκεια της αλληλεπίδρασης (δηλ. από τη στιγμή δημιουργίας του μέχρι τη στιγμή καταστροφής του).
Συμβάντα (events) (ή μηνύματα (messages) ή αλληλεπιδράσεις αντικειμένων (interactions) ή ενέργειες (actions)) υποδεικνύονται από οριζόντια βέλη που κατευθύνονται από τη γραμμή ζωής που αντιπροσωπεύει το αντικείμενο πελάτη (client) στη γραμμή ζωής που αντιπροσωπεύει το αντικείμενο του προμηθευτή (supplier). Ένα αντικείμενο μπορεί να στείλει μήνυμα στον εαυτό της. Τα συμβάντα είναι στη ουσία κλήσεις μεθόδων. Μπορείτε να χρησιμοποιήσετε τα στερεότυπα <<create>>, <<destroy>> για δημιουργία, καταστροφή αντικειμένων αντίστοιχα (για την καταστροφή προσθέτουμε και ένα Χ στο τέλος του lifeline). Συνήθως τα συμβάντα είναι σύγχρονα (synchronous) δηλ. μπλοκάρουν τον καλούντα μέχρις ότου διεκπεραιωθούν.
Τα μηνύματα μπορούν να φέρουν ετικέτα με το όνομα συμβάντος (το όνομα και τις τιμές των παραμέτρων καθώς και τις τιμές επιστροφής)
Η χρονική σειρά των συμβάντων υποδεικνύεται με την κατακόρυφη θέση, με το πιο πρώιμο γεγονός να εμφανίζεται στην κορυφή.
Ένα μήνυμα επιστροφής απεικονίζει το αποτέλεσμα ενός μηνύματος, δηλ. το αποτέλεσμα της κλήσης μιας μεθόδου (αντιπροσωπεύεται από διακεκομμένα βέλη)· τα μηνύματα επιστροφής συνήθως σχεδιάζονται από τα δεξιά προς τα αριστερά.
Ένα ασύγχρονο μήνυμα απεικονίζεται με μισά βέλη. Με ένα ασύγχρονο μήνυμα ο καλών (client) μπορεί να συνεχίσει την επεξεργασία χωρίς να μπλοκάρεται μέχρι να λάβει απάντηση (μήνυμα επιστροφής) από τον κληθέντα (supplier). Ένα ασύγχρονο μήνυμα μπορεί: να δημιουργήσει ένα νέο νήμα (thread), να δημιουργήσει ένα νέο αντικείμενο ή να επικοινωνήσει με ένα ήδη τρέχον νήμα. Η UML 2.0 εισήγαγε ακόμα τις έννοιες των απολεσθέντων (lost) και αγνώστων (found) μηνυμάτων.
Ένα κουτί ενεργοποίησης (activation box) (εστίαση ελέγχου) δείχνει το χρονικό διάστημα κατά το οποίο ένα αντικείμενο εκτελεί μια ενέργεια είτε άμεσα είτε μέσω μιας υφιστάμενης διαδικασίας. Η κορυφή του είναι ευθυγραμμισμένη με τον χρόνο έναρξης και ο πυθμένας του με το χρόνο τερματισμού του.
Η διαγραφή αντικειμένου παρουσιάζεται με ένα μεγάλο X (τα αντικείμενα μπορούν να αυτοκαταστραφούν ή να καταστραφούν από άλλο μήνυμα)
Ένα συνδυαστικό τμήμα (combined fragment) επιτρέπει να απεικονίσουμε λογικές συνθήκης ή επανάληψης.

Ένα παράδειγμα διαγράμματος αλληλουχίας απεικονίζεται στην Εικόνα 2.2.15.

Εικόνα 2.2.15 Παράδειγμα διαγράμματος ακολουθίας

Διαγράμματα επικοινωνίας (Communication diagrams)

Μετονομάστηκαν έτσι από διαγράμματα συνεργασίας (collaboration diagrams) όπως ονομάζονταν στις προηγούμενες εκδόσεις. Πρόκειται για ένα τύπο διαγράμματος αλληλεπίδρασης ο οποίος εστιάζει στα στοιχεία που εμπλέκονται σε μια συγκεκριμένη συμπεριφορά και στα ανταλλασσόμενα μηνύματα αντί για τη χρονική ακολουθία αυτών. Τα στοιχεία αυτά μπορούν να είναι αντικείμενα κλάσεων, εξαρτήματα, σενάρια κλπ.

Εικόνα 2.2.16 Παράδειγμα διαγράμματος επικοινωνίας

Διαγράμματα μετάβασης κατάστασης (State Machine diagrams ή Statechart diagrams)

Μετονομάστηκαν έτσι από διαγράμματα μετάβασης κατάστασης (State Transition diagrams) στις προηγούμενες εκδόσεις. Δείχνουν τις διάφορες καταστάσεις μιας οντότητας (αντικειμένου, μεθόδου, εξαρτήματος κλπ.) κατά τη διάρκεια της ύπαρξής της στο σύστημα. Η UML ορίζει δυο τύπους τέτοιων μηχανών: Συμπεριφοράς (behavioural) και πρωτοκόλλου (protocol) (π.χ. HTTP, SMTP κλπ).

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

Εικόνα 2.2.17 Συμβολολογία διαγραμμάτων μετάβασης κατάστασης

Όπως φαίνεται στην Εικόνα 2.2.17, ένα διάγραμμα μετάβασης κατάστασης αποτελείται από:

Κατάσταση (State) κατά τη διάρκεια ζωής ενός αντικειμένου, η οποία ικανοποιεί κάποιες συνθήκες, εκτελεί κάποια δραστηριότητα, ή αναμένει κάποιο γεγονός, με άλλα λόγια είναι μια από τις πιθανές συνθήκες στις οποίες μπορεί να βρίσκεται το αντικείμενο. Ένα αντικείμενο έχει ένα πεπερασμένο αριθμό πιθανών καταστάσεων και μπορεί να βρίσκεται μόνο σε μία κατάσταση κάθε φορά.
Ενέργειες (State actions): πρόκειται για μια ατομική εκτέλεση που τερματίζεται χωρίς διακοπή
Δραστηριότητα (activity): είναι μια συμπεριφορά αντικειμένου το οποίο βρίσκεται σε μια καθορισμένη κατάσταση. Δεν εκτελείται ατομικά και επομένως μπορεί να διακοπεί από γεγονότα κι έτσι να τερματιστεί χωρίς επιτυχία.
Ενέργειες εισόδου (entry actions): εκτελούνται όταν το αντικείμενο εισάγεται σε μια κατάσταση.
Ενέργειες εκτέλεσης (do actions): εκτελούνται μετά από τις ενέργειες εισόδου και πριν τις ενέργειες εξόδου ή μέχρι πέρας των εργασιών τους
Ενέργειες εξόδου (exit actions): εκτελούνται όταν το αντικείμενο εξέρχεται από μια κατάσταση.
Ειδικές καταστάσεις (special states): κατάσταση εκκίνησης start state (υποχρεωτική, μόνο μία επιτρέπεται) και καταστάσεις τερματισμού (stop states) (προαιρετικά, μπορούν να υποδεικνύονται περισσότερες από μια).
Εμφωλιασμένες καταστάσεις (nested states).

Οι ενέργειες (actions) και οι δραστηριότητες (activities) υλοποιούνται το ίδιο, αλλά αντιμετωπίζονται διαφορετικά. Οι ενέργειες σχετίζονται με μεταβάσεις και θεωρούνται ότι συμβαίνουν ατομικά (άμεσα) και δεν μπορούν να διακοπούν, ενώ οι δραστηριότητες συνδέονται με καταστάσεις, μπορούν να διαρκέσουν περισσότερο και φυσικά μπορούν να διακοπούν από εξωτερικά γεγονότα.

Μια μετάβαση (transition) είναι μια αλλαγή από μια αρχική κατάσταση σε μια επόμενη κατάσταση ως αποτέλεσμα ενός ερεθίσματος (stimulus). Οι μεταβάσεις μπορεί να είναι αυτόματες (μπορεί να μην μπορούν να διακοπούν) και μπορεί να φέρουν ετικέτα με ένα γεγονός, μια συνθήκη ή/και μια ενέργεια. Η σύνταξη για μια ετικέτα μετάβασης έχει τρία μέρη, όλα προαιρετικά: event[guard condition]/action.
Ένα συμβάν/γεγονός (event) ενεργοποιεί μια μετάβαση κατάστασης. Υπάρχουν πολλών ειδών συμβάντα π.χ.:
Μια συνθήκη γίνεται αληθής (λέξη-κλειδί when, π.χ. when (speed > 50))
Μετάβαση ενός καθορισμένου χρονικού διαστήματος μετά από ένα καθορισμένο γεγονός (λέξη-κλειδί after, π.χ. after (10 minutes))
Η συνθήκη (guard condition) είναι μια λογική (boolean) έκφραση η οποία αν ικανοποιηθεί (true) τότε γίνεται η μετάβαση
Η ενέργεια (action) τέλος είναι αυτή που θα εκτελεστεί μετά τη μετάβαση
Σήματα (signals): χρησιμοποιούνται όταν η μετάβαση από μία κατάσταση σε μια άλλη μπορεί να προκαλέσει την αποστολή ή λήψη άλλων πληροφοριών προς/από το σύστημα σας.

Η Εικόνα 2.2.18 δείχνει ένα παράδειγμα διαγράμματος μετάβασης κατάστασης. Η κατάσταση μεταβαίνει από OK σε Overdrawn αν ικανοποιείται η συνθήκη φύλακας [balance < amount]. Οι μεταβάσεις που ξεκινούν και τερματίζονται στην ίδια κατάσταση καλούνται αυτο-μεταβάσεις (self-transitions).

Εικόνα 2.2.18 Παράδειγμα διαγράμματος μετάβασης κατάστασης

Τα διαγράμματα αυτά είναι χρήσιμα σε προγράμματα παράλληλης/ταυτόχρονης επεξεργασίας (concurrent) καθώς ένα αντικείμενο μπορεί να βρίσκεται σε πολλές καταστάσεις στα τμήματα ταυτόχρονης επεξεργασίας. Αυτό απεικονίζεται με τη βοήθεια:

σύνθετης κατάστασης (composite state) η οποία αποτελείται από πολλές εμφωλιασμένες καταστάσεις. Μια σύνθετη κατάσταση μπορεί να χωριστεί σε περιοχές (regions) οι οποίες εκτελούν καταστάσεις παράλληλα/ταυτόχρονα. Η σύνθετη κατάσταση παραμένει ενεργή μέχρις ότου τερματιστούν όλες οι περιοχές που περιλαμβάνει.

Διαγράμματα δραστηριότητας (Activity diagrams)

Τα διαγράμματα δραστηριότητας απεικονίζουν τη ροή από μια συμπεριφορά ή δραστηριότητα στην επόμενη. Είναι παρόμοια στην έννοια με τα κλασσικά διαγράμματα ροής, αλλά είναι πολύ πιο εκφραστικά.

Μια δραστηριότητα είναι μια ενέργεια που χρειάζεται κάποιο χρόνο για να ολοκληρωθεί και απεικονίζεται ως κατάσταση ενέργειας (action state) (βλ. Εικόνα 2.2.19). Οι διακλαδώσεις (branches) και οι συγχωνεύσεις (merges) δηλώνουν συνθήκες και απεικονίζονται με διαμάντι (βλ. Εικόνα 2.2.19). Μια διακλάδωση έχει μια μόνο εισερχόμενη μετάβαση και πολλές, αμοιβαία αποκλεισμένες, εξερχόμενες μεταβάσεις που διαχωρίζονται με βάση κάποια συνθήκη (guard). Μια συγχώνευση έχει πολλαπλές εισόδους και μια μόνο εξερχόμενη μετάβαση. Μια συγχώνευση σηματοδοτεί το τέλος μιας συνθήκης η οποία ξεκίνησε σε μια διακλάδωση.

Η παράλληλη συμπεριφορά απεικονίζεται από διακλαδώσεις (forks) και ενώσεις (joins) (βλ. Εικόνα 2.2.19). Μια διακλάδωση έχει μια εισερχόμενη μετάβαση και πολλές εξερχόμενες μεταβάσεις που συμβαίνουν παράλληλα. Μια ένωση έχει μία εξερχόμενη μετάβαση και αρκετές εισερχόμενες μεταβάσεις και τερματίζει μια διακλάδωση. Στην ένωση, η εξερχόμενη μετάβαση ενεργοποιείται μόνο όταν όλες οι καταστάσεις στις εισερχόμενες μεταβάσεις έχουν ολοκληρώσει τις δραστηριότητές τους.

Εικόνα 2.2.19 Συμβολολογία διαγράμματος δραστηριότητας

Ένα παράδειγμα διαγράμματος δραστηριότητας εμφανίζεται στην Εικόνα 2.2.20. Η Εικόνα 2.2.δείχνει μια διακλάδωση και μια ένωση, με τις δραστηριότητες ReadState, ExecuteControlLaws και OutputDemands να εμφανίζονται παράλληλα.

Εικόνα 2.2.20 Παράδειγμα διαγράμματος δραστηριότητας

Οι Ζώνες (Swimlanes) ή χωρίσματα (partitions), όπως μετονομάστηκαν στην έκδοση 2.0, κατανέμουν τις καταστάσεις ενεργειών στις κλάσεις ή οντότητες που είναι υπεύθυνες για αυτές. Για να χρησιμοποιήσετε τις ζώνες, πρέπει να οργανώσετε το διάγραμμα δραστηριότητας σε κάθετες ή οριζόντιες ζώνες χωρισμένες με γραμμές. Κάθε ζώνη αντιπροσωπεύει τη ζώνη ευθυνών μιας συγκεκριμένης κλάσης.

Τέλος, όπως και με τα διαγράμματα μετάβασης κατάστασης, τα διαγράμματα δραστηριότητας υποστηρίζουν σήματα (signals).

Διαγράμματα αλληλεπίδρασης (Interaction Overview diagrams)

Τα διαγράμματα αλληλεπίδρασης είναι ένας συνδυασμός διαγραμμάτων ακολουθίας (8) και δραστηριότητας (11). Βοηθούν με το ν’ απεικονίζουν τη συνολική ροή εκτέλεσης ενός συστήματος.

Εικόνα 2.2.21 Παράδειγμα διαγράμματος αλληλεπίδρασης

Διαγράμματα χρονισμού (Timing diagrams)

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

Εικόνα 2.2.22 Παράδειγμα διαγράμματος χρονισμού

Εργαλεία

Δωρεάν:

Online:

Εμπορικά:

NetBeans UML plugins

Μπορείτε να οπτικοποιήσετε τις κλάσεις σας απευθείας από το NetBeans. Υπάρχουν μερικά plugins για το NetBeans γι’ αυτό το σκοπό.

Εδώ θα περιγράψουμε συντόμως το easyUML plugin και στο κεφάλαιο για την τεκμηρίωση κώδικα το plantUML.

Για να εγκαταστήσετε το easyUML, αφού το κατεβάσετε και το αποσυμπιέσετε, επιλέξτε στο NetBeans το μενού Tools –> Plugins, καρτέλα Downloaded, κλικ στο κουμπί Add Plugins, πλοηγηθείτε στο φάκελο 1407020290_easyUml, επιλέξτε όλα τα *.nbm αρχεία και Open και στη συνέχεια Install. Ακολουθήστε τις οδηγίες του οδηγού για να το εγκαταστήσετε.

Από το μενού Window επιλέξτε UML Designer. Μπορείτε να σύρετε αντικείμενα όπως κλάση, διεπαφή, συσχέτιση από την παλέττα και να δημιουργήσετε διαγράμματα κλάσεων.

Περίληψη

Σ’ αυτό το μάθημα περιγράψαμε τα 13 διαγράμματα της UML 2.0. Η Unified Modeling Language είναι μια οπτική γλώσσα μοντελοποίησης που επιτρέπει να απεικονίσουμε όλες τις φάσεις ανάπτυξης ενός προγράμματος, από τις απαιτήσεις μέχρι την εγκατάσταση στους Η/Υ του πελάτη.

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

Πηγές

Ambler S.W. (2003), The Elements of UML 2.0 Style, Cambridge University Press.
Booch G., Rumbaugh J., Jacobson I. (2005), The Unified Modeling Language User Guide, 2nd Ed, Addison Wesley
Cockburn A. (1999), Surviving Object-Oriented Projects, Addison-Wesley.
Eriksson H.-E., Penker M. (1998), UML Toolkit, John Wiley & Sons, Inc.
Fowler M. (2004), UML Distilled, 3rd Edition, Addison-Wesley.
Gamma E., Helm R., Johnson R., Vlissides J. (1995), Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley.
Graham I., Wills A., UML Tutorial, MMI – Trireme International
Halbert P., O’ Brien (1997), Using Types and Inheritance in Object Oriented Programming, IEEE Software, September.
Jacobson I., Magnus C., Patrik J., Gunnar O. (1992), Object-Oriented Software Engineering: A Use Case Driven Approach, Addison-Wesley.
Kruchten P. (2000), The Rational Unified Process An Introduction, 2nd Edition, Addison-Wesley.
Kostaras I. (2009), UML Description and a methodology of use.
Martin R.C. (2002), UML for Java Programmers, Prentice-Hall
Pilone D. & Pitman N. (2005), UML 2.0 in a Nutshell, O’Reilly
Pilone D. (2006), UML 2.0 Pocket Reference, O’Reilly
Pressman R. S. (1997), Software Engineering - A practitioner’s approach, 4th edition, European adaptation, McGraw Hill.
Quatrani T. (1998), Visual Modeling with Rational Rose and UML, Addison-Wesley.
Rosenberg, D. (1999), Use Case Driven Object Modeling with UML – A practical approach, Addison-Wesley.
Rumbaugh J., Blaha M., Premerlani W., Eddy F., Lorensen W. (1991), Object-Oriented Modelling and Design, Prentice-Hall Int.
Schneider G., Winters J.P. (2001), Applying Use Cases – A practical guide, 2nd Ed., Addison-Wesley.
[SDM] Software Development Magazine (1998), Inside the UML, Rational Software Corporation.
UML Class Diagrams.

2.2 Εισαγωγή στη UML {#Java}

My books