ΠΑΝΕΠΙΣΤΗΜΙΟ ΠΑΤΡΩΝ ΠΟΛΥΤΕΧΝΙΚΗ ΣΧΟΛΗ ΤΜΗΜΑ ΗΛΕΚΤΡΟΛΟΓΩΝ ΜΗΧΑΝΙΚΩΝ & ΤΕΧΝΟΛΟΓΙΑΣ ΥΠΟΛΟΓΙΣΤΩΝ ΤΟΜΕΑΣ: ΗΛΕΚΤΡΟΝΙΚΗΣ ΚΑΙ ΥΠΟΛΟΓΙΣΤΩΝ

ΔΙΠΛΩΜΑΤΙΚΗ ΕΡΓΑΣΙΑ

της φοιτήτριας του Τμήματος Ηλεκτρολόγων Μηχανικών και

Τεχνολογίας Υπολογιστών της Πολυτεχνικής σχολής του Πανεπιστημίου Πατρών:

Αρετάκ η Αι κατ ερ ί ν η

Αρι θμό ς Μ ητρ ώου: 55 91

Θέμα:

«Η UML στην ανάπτυξη ενσ ωματωμένων συστημάτων»

Επιβλέπων:

Κλεάνθης Θραμπουλίδης

ΠΑΤΡΑ, ΙΟΥΛΙΟΣ 2009

1

2

ΠΙΣΤΟΠΟΙΗΣΗ

Πιστοποιείται ότι η διπλωματική εργασία με θέμα:

«Η UML στην ανάπτυξη ενσ ωματωμένων συστημάτων»

της φοιτήτριας του τμήματος

Ηλεκτρολόγων Μηχανικών και Τεχνολογίας Υπολογιστών

Αρετάκη Αικατερίνη του Δημητρίου

(Α.Μ. 5591)

παρουσιάστηκε δημόσια και εξετάστηκε στο τμήμα

Ηλεκτρολόγων Μηχανικών και Τεχνολογίας Υπολογιστών στις

10/07/2009

Ο Επιβλέπων Ο Διευθυντής του

Τομέα

Κ. Θραμπουλίδης K. Γκούτης

Καθηγητής Kαθηγητής

3

4

Αριθμός Διπλωματικής Εργασίας:

Τί τλ ος :

Η UM L στην ανάπτυξη ενσωματωμένων συστημάτων Φ ο ιτητής : Αρετ άκη Αι κατ ερ ίν η Ε π ι βλέ πων : Κλεάν θ ης Θρ αμπο υλ ίδ ης

Περ ί λ η ψη

H Ενοποιημένη Γλώσσα Μοντελοποίησης (Unified Modeling Language) αποτελεί την πρότυπη και πλέον δημοφιλή γλώσσα για την οπτικοποίηση, προσδιορισμό, ανάπτυξη και τεκμηρίωση συστημάτων λογισμικού και όχι μόνο. Η πλούσια γραφική σημειολογία της UML σε συνδυασμό με τις δυνατότητες μοντελοποίησης που παρέχει, την καθιστούν ικανή να χρησιμοποιηθεί στην ανάπτυξη ενσωματωμένων συστημάτων. Ωστόσο, στα ενσωματωμένα συστήματα, αλλά και γενικότερα σε συστήματα συγκεκριμένου πεδίου υπάρχουν κάποιοι επιπλέον παράγοντες που πρέπει να ληφθούν υπόψη. Οι επεκτάσεις της UML δίνουν τη δυνατότητα αναπαράστασης των βασικών χαρακτηριστικών των ενσωματωμένων συστημάτων. Επιπλέον, παρέχουν νέες μεθόδους σχεδιασμού που επιτρέπουν τον διαμερισμό εφαρμογής και αρχιτεκτονικής, για ένα πιο αποδοτικό και επαναχρησιμοποιήσιμο σύστημα. Στην παρούσα εργασία μελετώνται τα βασικά στοιχεία της UML καθώς και η χρήση της στην ανάπτυξη ενσωματωμένων συστημάτων. Στη συνέχεια, χρησιμοποιώντας τη UML μοντελοποιείται και αναπτύσσεται η εφαρμογή ελέγχου ενός συστήματος γραμμής παραγωγής, του Festo MPS. Επιπλέον, αναπτύσσεται και υλοποιείται εφαρμογή εξομοίωσης του φυσικού συστήματος Festo MPS για την επιβεβαίωση της σωστής λειτουργίας της εφαρμογής ελέγχου.

5

6

Πίνακας περιεχομένων Εισαγωγή.........................................................................................10 Κεφάλαιο 1 Περιγραφή του Συστήματος FestoMPS.........12 1.1 Γενική περιγραφή.....................................................................12 1.2 Μονάδα διανομής.....................................................................13 1.3 Μονάδα ελέγχου.......................................................................15 1.4 Μονάδα επεξεργασίας..............................................................17 1.5 Μονάδα αποθήκευσης..............................................................20 Κεφάλαιο 2 Εισαγωγή στη UML........................................22 2.1 Εισαγωγή.................................................................................22 2.2 Ιστορία.....................................................................................23 2.3 Οι όψεις της UML...................................................................24 2.4 Τα διαγράμματα της UML......................................................25 2.5 Η UML στην ανάπτυξη ενσωματωμένων συστημάτων..........39 Κεφάλαιο 3 Ανάλυση και σχεδιασμός του

συστήματος......................................................44 3.1 Γενικά.....................................................................................44 3.2 Ανάλυση του συστήματος.......................................................45 3.2.1 Μοντέλο απαιτήσεων............................................................45 3.2.2 Μοντέλο ανάλυσης................................................................48 3.3 Σχεδιασμός του συστήματος...................................................52 3.3.1 Μοντελοποίηση της δυναμικής συμπεριφοράς .....................52 3.3.2 Μοντελοποίηση του υποσυστήματος επικοινωνίας της

εφαρμογής με τον εξομοιωτή του φυσικού συστήματος.......58 3.3.3 Μοντελοποίηση της αρχιτεκτονικής δομής...........................59

7

Κεφάλαιο 4 Υλοποίηση του συστήματος.........................62 4.1 Υλοποίηση της διεπαφής της εφαρμογής ελέγχου με

την εφαρμογή εξομοίωσης...................................................62 4.2 Υλοποίηση του υποσυστήματος ελέγχου της μονάδας

διανομής................................................................................66 4.3 Υλοποίηση του υποσυστήματος ελέγχου της μονάδας

ελέγχου..................................................................................70 4.4 Υλοποίηση του υποσυστήματος ελέγχου της μονάδας

επεξεργασίας.........................................................................74 4.5 Υλοποίηση του ελέγχου των υποσυστημάτων διανομής,

ελέγχου και επεξεργασίας.....................................................77

Κεφάλαιο 5 Εξομοίωση του συστήματος.........................80 Συμπεράσματα..............................................................................90 Αναφορές.......................................................................................92

8

Πρόλογος Η UML δεν πρόκειται μόνο για μια τυποποίηση και ανακάλυψη μιας κοινής σημειολογίας. Περιέχει νέες και ενδιαφέρουσες έννοιες που δεν υπάρχουν εν γένει στο πεδίο της αντικειμενοστρεφούς ανάπτυξης, όπως για παράδειγμα η περιγραφή και χρησιμοποίηση προτύπων (patterns) σε μια γλώσσα μοντελοποίησης, η χρησιμοποίηση της έννοιας του στερεοτύπου (stereotype) για την επέκταση της γλώσσας, καθώς και η παροχή πλήρους ιχνηλασιμότητας (traceability) από τα εννοιολογικά μοντέλα ενός συστήματος στα εκτελέσιμα συστατικά της φυσικής αρχιτεκτονικής.

Σε αυτό το σημείο, θα ήθελα να ευχαριστήσω θερμά τον κ. Κλεάνθη Θραμπουλίδη. Η συνεργασία μας ήταν άριστη και ιδιαίτερα εποικοδομητική και μέσα από αυτή κέρδισα πολύτιμες εμπειρίες που θα με συνοδεύσουν στη μελλοντική μου καριέρα ως μηχανικού λογισμικού.

9

10

Εισαγωγή

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

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

Στα πλαίσια αυτά, η Ενοποιημένη Γλώσσα Μοντελοποίησης (Unified Modeling Language), η οποία αποτελεί την πλέον δημοφιλή και πρότυπη γραφική γλώσσα μοντελοποίησης, χρησιμοποιείται για την απεικόνιση του σχεδιασμού και την τεκμηρίωση των συστατικών του συστήματος. Είναι ιδιαίτερα αποδοτική για την ανάπτυξη μεγάλων, πολύπλοκων συστημάτων. Βασικό χαρακτηριστικό της είναι ότι είναι ανεξάρτητη από οποιαδήποτε μεθοδολογία ή διαδικασία ανάπτυξης και μπορεί να προσδιορίσει το σύστημα με ένα τρόπο ανεξάρτητο της υλοποίησης. Η επικράτηση του λογισμικού στο σχεδιασμό ενσωματωμένων συστημάτων απαιτεί μια προσεκτική εξέταση των πιο σύγχρονων μεθόδων ανάλυσης και τεκμηρίωσης λογισμικού. Η πλούσια γραφική σημειολογία της UML σε συνδυασμό με τις δυνατότητες μοντελοποίησης που παρέχει, την καθιστούν ικανή να χρησιμοποιηθεί στην ανάπτυξη ενσωματωμένων συστημάτων για τη μοντελοποίηση και την τεκμηρίωσή τους. Επιπλέον, οι επεκτάσεις της UML δίνουν τη δυνατότητα μοντελοποίησης των βασικών χαρακτηριστικών των εφαρμογών συγκεκριμένου πεδίου και παρέχουν νέες μεθόδους σχεδιασμού για τον διαμερισμό της εφαρμογής από την αρχιτεκτονική.

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

11

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

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

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

Το Κεφάλαιο 3 περιλαμβάνει την περιγραφή των φάσεων της ανάλυσης και του σχεδιασμού του συστήματος Festo MPS με τη χρήση της UML. Στη φάση της ανάλυσης το σύστημα μοντελοποιείται μέσα από το μοντέλο απαιτήσεων και το μοντέλο ανάλυσης του συστήματος. Στη φάση του σχεδιασμού μοντελοποιείται η δυναμική συμπεριφορά του συστήματος, η αρχιτεκτονική δομή του και σχεδιάζεται το υποσύστημα επικοινωνίας της εφαρμογής ελέγχου με την εφαρμογή εξομοίωσης του φυσικού συστήματος Festo MPS.

Το Κεφάλαιο 4 περιλαμβάνει την υλοποίηση σε Java κώδικα της εφαρμογής ελέγχου του συστήματος Festo MPS. Η υλοποίηση διακρίνεται στα εξής μέρη: την υλοποίηση του υποσυστήματος ελέγχου της μονάδας διανομής, την υλοποίηση του υποσυστήματος ελέγχου της μονάδας ελέγχου, την υλοποίηση του υποσυστήματος ελέγχου της μονάδας επεξεργασίας και την υλοποίηση του ελέγχου των τριών υποσυστημάτων. Το Κεφάλαιο 5 περιλαμβάνει την εξομοίωση του φυσικού συστήματος Festo MPS. Η εφαρμογή εξομοίωσης του συστήματος Festo MPS κατασκευάστηκε για τον έλεγχο της ορθότητας της εφαρμογής ελέγχου. Για τη επικοινωνία της εφαρμογής εξομοίωσης με την εφαρμογή ελέγχου χρησιμοποιήθηκε η κατασκευή του Socket. Το κεφάλαιο αυτό περιλαμβάνει το σχεδιασμό και την υλοποίηση σε Java κώδικα της εφαρμογής εξομοίωσης.

12

Κεφάλαιο 1

Περιγραφή του Συστήματος Festo MPS

1.1 Γενική περιγραφή Το Festo MPS σύστημα (Modular Production System) είναι ένα σύστημα γραμμής παραγωγής που αναπτύχθηκε από την εταιρία Festo για εκπαιδευτικούς και ερευνητικούς σκοπούς (Σχήμα 1.1). Το σύστημα απαρτίζεται από τις ακόλουθες μονάδες:

• Μονάδα διανομής (Distribution station ) • Μονάδα ελέγχου (Test station) • Μονάδα επεξεργασίας (Processing station) • Μονάδα αποθήκευσης (Warehouse station)

Κυλινδρικά κομμάτια χρησιμοποιούνται σαν δείγματα (workpieces), τα οποία διαφέρουν στο χρώμα τους (κόκκινο, μαύρο, ασημί), στο υλικό τους (αλουμίνιο, πλαστικό) και στο ύψος τους. Το σύστημα περιλαμβάνει πνευματικές συσκευές παραγωγής ευθύγραμμης και περιστροφικής κίνησης όπως επίσης και ηλεκτρικές (actuators). Οι αισθητήρες (sensors) για τον έλεγχο ύπαρξης αντικειμένου, την αναγνώριση χρώματος, υλικού και τη μέτρηση ύψους βασίζονται σε μηχανικές, οπτικές, επαγωγικές και χωρητικές διαδικασίες μέτρησης.

13

Σχήμα 1.1 Το πραγματικό Festo Modular Production System Παρακάτω θα περιγράψουμε αναλυτικά την κάθε μονάδα του συστήματος [1].

1.2 Μονάδα διανομής Εδώ τα προϊόντα εξάγονται ξεχωριστά το καθένα από μία στοίβα. Αυτό γίνεται μέσω ενός πνευματικού κυλίνδρου (push out cylinder / feeder), ο οποίος με την εφαρμογή πεπιεσμένου αέρα προκαλεί την έκταση του εμβόλου του εκτοπίζοντας έτσι το κομμάτι από τη στοίβα. Στο τέλος αυτής της διαδικασίας η νέα θέση του προϊόντος (θέση Α) αναγνωρίζεται από έναν αισθητήρα. Το επόμενο βήμα είναι το προϊον αυτό να μεταφερθεί στη μονάδα ελέγχου με τη βοήθεια ενός μεταφορέα (Converter) . Στο Σχήμα 1.2 δίνεται η μονάδα διανομής με τη στοίβα και τον πνευματικό κύλινδρο.

14

Σχήμα 1.2 Μονάδα διανομής Ο Converter λειτουργεί με πεπιεσμένο αέρα χαμηλής πίεσης. Μόλις η πίεση φτάσει στο επιθυμητό επίπεδο ο Converter ανασηκώνει το κομμάτι και το μεταφέρει από τη μονάδα διανομής στη μονάδα ελέγχου (θέση Β). (Σχήμα 1.3)

Σχήμα 1.3 Ο μεταφορέας Converter Οι αισθητήρες και οι ενεργοποιητές (actuators) της μονάδας διανομής δίνονται αναλυτικά στον Πίνακα 1.1:

15

Πίνακας 1.1 Οι αισθητήρες και ενεργοποιητές της μονάδας διανομής 1.3 Μονάδα ελέγχου Η παρουσία ενός προϊόντος στη μονάδα ελέγχου καθώς επίσης το χρώμα και υλικό του γίνονται γνωστά μέσω οπτικών και επαγωγικών αισθητήρων. Με την άφιξη του προϊόντος σε αυτή τη νέα θέση (θέση Β) ελέγχονται οι ιδιότητές του (χρώμα, υλικό). Στην περίπτωση που είναι αποδεκτές η πλατφόρμα διακίνησης (Elevating platform) πάνω στην οποία βρίσκεται το προϊόν ανυψώνεται με τη βοήθεια κυλίνδρου (pneumatic cylinder for the elevator platform / Elevator) και ταυτόχρονα γίνεται η μέτρηση του ύψους του προϊόντος (Σχήμα 1.4). Όταν η πλατφόρμα διακίνησης αποκτήσει την ανώτερη θέση της, γίνεται ο έλεγχος του ύψους του προϊόντος. Αν το ύψος του προϊόντος είναι αποδεκτό τότε το κομμάτι μεταφέρεται πάνω σε μία κυλιόμενη ζώνη μεταφοράς (Transport belt) μέσω της έκτασης του εμβόλου ενός πνευματικού κυλίνδρου (Shift out cylinder).

16

Σχήμα 1.4 Μονάδα ελέγχου Η κυλιόμενη ζώνη μεταφοράς βοηθάει στη μετακίνηση του προϊόντος με τις αποδεκτές ιδιότητες και ύψος στη μονάδα επεξεργασίας. Στο Σχήμα 1.5 φαίνεται αυτή η κυλιόμενη ζώνη με τον περιστρεφόμενο δίσκο της μονάδας επεξεργασίας.

Σχήμα 1.5 Μεταφορά από τη μονάδα ελέγχου στη μονάδα επεξεργασίας

17

Το προϊόν που φέρει μη-αποδεκτές ιδιότητες (δηλαδή έχει μη αποδεκτό χρώμα ή μη-αποδεκτό υλικό ή και τα δύο) εκτοπίζεται από τη μονάδα ελέγχου με τη βοήθεια του Shift out cylinder. Στην περίπτωση που το προϊόν φέρει μη-αποδεκτό ύψος, τότε πραγματοποιείται η εξής διαδικασία : Η πλατφόρμα διακίνησης όπου βρίσκεται το κομμάτι κατέρχεται και όταν φτάσει στην κατώτερη θέση της ενεργοποιείται ο Shift out cylinder κύλινδρος και το απομακρύνει από τη μονάδα ελέγχου. Οι αισθητήρες και οι ενεργοποιητές (actuators) της μονάδας ελέγχου δίνονται αναλυτικά στον Πίνακα 1.2

Πίνακας 1.2 Οι αισθητήρες και ενεργοποιητές της μονάδας ελέγχου 1.4 Μονάδα επεξεργασίας Στη μονάδα επεξεργασίας υπάρχει ένας περιστρεφόμενος δίσκος τεσσάρων θέσεων. Το προϊόν καταφθάνει αρχικά στην θεση-1 του δίσκου και σταδιακά επισκέπτεται και τις υπόλοιπες θέσεις του ενώ ταυτόχρονα υφίσταται επεξεργασία διαφορετική για κάθε θέση. Στη θέση-1 το προϊόν δεν υφίσταται κάποια επεξεργασία. Με μία στροφή του δίσκου κατα 90° μεταφέρεται στη θεση-2 όπου υπάρχει ένα ηλεκτρικό τρυπάνι (Drilling machine) (Σχήμα 1.6). Η ύπαρξη του προϊόντος στη θέση-2 αναγνωρίζεται από αισθητήρα και αρχίζει η διαδικασία επεξεργασίας του. Το προϊόν αρχικά σταθεροποιείται στη θέση του μέσω ενός μηχανισμού (holder) που το συγκρατεί εκεί (brack in). Στη συνέχεια ενεργοποιείται το τρυπάνι και πραγματοποιεί μία οπή στο κέντρο κάθε κομματιού μεσω ενός κυλίνδρου (pneumatic lifting cylinder). Αφού τελειώσει η διαδικασία τρυπήματος του προϊόντος το τρυπάνι απενεργοποιείται όπως επίσης και ο μηχανισμός συγκράτησης του κομματιού (brack out). Έπειτα ακολουθεί μία στροφή του δίσκου κατα 90° και το προϊόν μεταφέρεται στη θεση-3 (Σχήμα 1.7).

18

Σχήμα 1.6 Διαδικασία τρυπήματος κομματιού Στη θέση-3 ελέγχεται αν έχει γίνει σωστά η οπή του προϊόντος μέσω του κατάλληλης συσκευής (Checking machine). Η συσκευή αυτή έχει έναν κύλινδρο (pneumatic testing cylinder) ο οποίος με την κατερχόμενη κίνηση του ελέγχει την ορθότητα της οπής. Έπειτα πραγματοποιείται περιστροφή του δίσκου κατα 90° και το προϊόν μεταφέρεται στη θεση-4.

Σχήμα 1.7 Έλεγχος της οπής του κομματιού

19

Όταν το προϊόν φτάσει στη θέση-4 με τη βοήθεια ενός πνευματικού κυλίνδρου (Warehouse Cylinder) απομακρύνεται από την τελική θέση του κυκλικού δίσκου και μεταφέρεται στη μονάδα αποθήκευσης. Οι αισθητήρες και οι ενεργοποιητές (actuators) της μονάδας ελέγχου δίνονται αναλυτικά στον Πίνακα 1.3.

Πίνακας 1.3 Οι αισθητήρες και ενεργοποιητές της μονάδας επεξεργασίας

20

1.5 Μονάδα αποθήκευσης Μετά την απομάκρυνση από τη μονάδα επεξεργασίας το προϊόν μεταφέρεται σε μία από τις τρεις στοίβες που υπάρχουν στη μονάδα αποθήκευσης ανάλογα με το χρώμα και το υλικό τους. Στο παρακάτω σχήμα φαίνεται η μονάδα αποθήκευσης. (Σχήμα 1.8)

Σχήμα 1.8 Μονάδα αποθήκευσης

21

22

Κεφάλαιο 2

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

2.1 Εισαγωγή Σύμφωνα με το επίσημο εγχειρίδιο αναφοράς, η Ενοποιημένη Γλώσσα Μοντελοποίησης (Unified Modeling Language ή UML) είναι μια γραφική γλώσσα γενικού σκοπού, η οποία χρησιμοποιείται για τον προσδιορισμό, οπτικοποίηση, ανάπτυξη και τεκμηρίωση των κατασκευασμάτων (artifacts) ενός συστήματος λογισμικού [2]. Η UML αποτελεί industry standard για τη μοντελοποίηση συστημάτων λογισμικού και χρησιμοποιείται στη μοντελοποίηση συστημάτων βασισμένων σε αντικείμενα (αντικειμενοστρεφή συστήματα). Βασικό χαρακτηριστικό της είναι ότι αποτελεί μια γλώσσα μοντελοποίησης ανεξάρτητη από τις μεθοδολογίες που χρησιμοποιούνται κατά την ανάπτυξη συστημάτων λογισμικού. Επιπλέον, δεν πρόκειται μόνο για μια τυποποίηση και ανακάλυψη μιας κοινής σημειολογίας. Περιέχει νέες και ενδιαφέρουσες έννοιες που δεν υπάρχουν εν γένει στο πεδίο της αντικειμενοστρεφούς ανάπτυξης, όπως για παράδειγμα η περιγραφή και χρησιμοποίηση προτύπων (patterns) σε μια γλώσσα μοντελοποίησης, η χρησιμοποίηση της έννοιας του στερεοτύπου (stereotype) για την επέκταση της γλώσσας, η παροχή πλήρους ιχνηλασιμότητας (traceability) από τα εννοιολογικά μοντέλα ενός συστήματος στα εκτελέσιμα συστατικά της φυσικής αρχιτεκτονικής. Συνεπώς, η κατανόηση της UML δεν περιορίζεται στην εκμάθηση των συμβόλων και της σημασίας τους, αλλά εκτείνεται σε ευρύτερο πλαίσιο στη μάθηση της αντικειμενοστρεφούς μοντελοποίησης.[3] Η UML χρησιμοποιείται για τη μοντελοποίηση μεγάλου εύρους συστημάτων. Ο στόχος της UML είναι να περιγράφει κάθε τύπο συστήματος, μέσα από αντικειμενοστρεφή διαγράμματα. Η πιο συνήθης χρήση της είναι η παραγωγή μοντέλων συστημάτων λογισμικού, πέρα απο αυτό όμως χρησιμοποιείται για την περιγραφή συστημάτων που δεν αφορούν λογισμικό, όπως για παράδειγμα μηχανικών συστημάτων. Οι κυριότερες κατηγορίες συστημάτων στα οποία χρησιμοποιείται η UML είναι οι εξής: πληροφοριακά συστήματα, τεχνολογικά συστήματα, συστήματα λογισμικού, ενσωματωμένα συστήματα πραγματικού χρόνου, κατανεμημένα συστήματα, καθώς και συστήματα επιχειρήσεων.

23

2.2 Ιστορία Μεθοδολογίες ανάπτυξης λογισμικού για συμβατικές διαδικαστικές γλώσσες, όπως η Fortran, η Pascal και η C, εμφανίστηκαν τη δεκαετία του 1970 με σκοπό να αντιμετωπίσουν τη λεγόμενη «κρίση λογισμικού» (software crisis). Η πιο ευρέως διαδεδομένη μεθοδολογία ήταν η Δομημένη Ανάλυση και Σχεδίαση (Structured Analysis and Design) και αργότερα η Σύγχρονη Δομημένη Ανάλυση. Ως πρώτη αντικειμενοστρεφής γλώσσα προγραμματισμού αναγνωρίζεται η Simula (1967), αλλά η ευρεία διάδοση της αντικειμενοστρεφούς ανάπτυξης λογισμικού άρχισε στις αρχές της δεκαετίας του 1980 με γλώσσες όπως η Smalltalk, C++ και στη συνέχεια με τη Java. Στη συνέχεια δημοσιεύτηκαν και οι πρώτες μεθοδολογίες ανάπτυξης λογισμικού βασισμένες στο αντικειμενοστρεφές μοντέλο, καταλήγοντας στις αρχές της δεκαετίας του ’90 σε μια πληθώρα τεχνικών, ορισμών, συμβολισμών και ορολογίας. [4] Η πρώτη επιτυχής προσπάθεια ενοποίησης των διαφόρων μεθοδολογιών ξεκίνησε από την Rational Software Corporation το 1994 με επικεφαλής τους Grady Booch και James Rumbaugh. Στόχος τους ήταν η δημιουρία μιας νέας μεθόδου, της «Ενοποιημένης Μεθόδου», η οποία θα ένωνε τη μέθοδο του Booch και την ΟΜΤ-2 μέθοδο στην ανάπτυξη της οποίας επικεφαλής ήταν ο James Rumbaugh. Το 1995 ο Ivar Jacobson, ο άνθρωπος πίσω από τις μεθόδους OOSE και Objectory προστέθηκε στην ομάδα. Οι μελλοντικοί σχεδιαστές της UML συνειδητοποίησαν ότι η δουλειά τους δε στόχευε στη δημιουργία μιας πρότυπης μεθόδου, αλλά μιας πρότυπης γλώσσας μοντελοποίησης και μετονόμασαν τη δουλειά τους σε «Unified Modeling Language». Οι στόχοι της UML, όπως τέθηκαν από τους σχεδιαστές είναι οι εξής: Η μοντελοποίηση συστημάτων (όχι μόνο λογισμικού) χρησιμοποιώντας αντικειμενοστρεφείς έννοιες. Η καθιέρωση μιας ρητής σύνδεσης σε εννοιολογικά καθώς και εκτελέσιμα κατασκευάσματα (artifacts). Η αντιμετώπιση θεμάτων κλίμακας , τα οποία είναι εγγενή σε σύνθετα, κρίσιμα συστήματα. Και τέλος, η δημιουργία μιας γλώσσας μοντελοποίησης χρησιμοποιήσιμης τόσο από ανθρώπους, όσο και από υπολογιστικές μηχανές. [3] Το πρώτο πρότυπο της UML (UML 1.1) δημοσιεύτηκε τον Ιανουάριο του 1997. Ακολούθησαν μερικές ήσσονος σημασίας εκδόσεις (UML 1.3, UML 1.4, UML 1.5), οι οποίες διόρθωσαν κάποιες ελλείψεις και σφάλματα της πρώτης έκδοσης. Στη συνέχεια ακολούθησε η κύρια αναθεώρηση με τη UML 2.0, η οποία υιοθετήθηκε και καθιερώθηκε ως πρότυπο από την OMG (Object Management Group) το 2005, ενώ η τελευταία έκδοση είναι η UML 2.2.

24

2.3 Οι όψεις της UML Ένα σύστημα αναπαρίσταται με τη βοήθεια των μοντέλων της UML. Το κάθε μοντέλο περιγράφει το σύστημα από μια ευδιάκριτα διαφορετική οπτική γωνία, ή αλλιώς όψη (view). Η όψη δεν αποτελεί γράφημα, αλλά μια αφαιρετική έννοια με την οποία συνδέεται ένας αριθμός διαγραμμάτων. Οι όψεις επίσης συνδέουν τη γλώσσα μοντελοποίησης με τη μέθοδο που επιλέγεται για την ανάπτυξη του συστήματος. Κάθε όψη περιγράφεται από έναν αριθμό διαγραμμάτων, τα οποία περιέχουν πληροφορία που αφορά σε συγκεκριμένη οπτική γωνία του συστήματος. Υπάρχει μια ελαφρά επικάλυψη, δηλαδή ένα διάγραμμα μπορεί να αποτελεί μέρος περισσοτέρων της μιάς όψης. Κοιτάζοντας το σύστημα με βάση τις διαφορετικές όψεις, μπορούμε να επικεντρωθούμε σε διαφορετική πτυχή του συστήματος κάθε φορά. Το διάγραμμα που εκφράζει μια συγκεκριμένη όψη πρέπει να είναι αρκετά απλό ώστε να γίνεται αντιληπτό και συνεκτικό (coherent) με τα υπόλοιπα διαγράμματα και όψεις έτσι ώστε από όλες τις όψεις συνολικά να περιγράφεται η συνολική εικόνα του συστήματος. Οι όψεις της UML είναι οι εξής (Σχήμα 2.1) :

Σχήμα 2.1 Οι όψεις της UML [5]

Η όψη περιπτώσεων χρήσης (Use case view) : Περιγράφει τη λειτουργικότητα του συστήματος, έτσι όπως αυτή γίνεται αντιληπτή από τους εξωτερικούς χειριστές (actors). Ο χειριστής ο οποίος αλληλεπιδρά με το σύστημα μπορεί να είναι ένας χρήστης ή ένα άλλο υποσύστημα. Η όψη περιπτώσεων χρήσης περιγράφεται μέσα από διαγράμματα περιπτώσεων χρήσης (use case diagrams) και ενίοτε από διαγράμματα δραστηριοτήτων (activity diagrams). Η επιθυμητή λειτουργικότητα του συστήματος περιγράφεται από έναν αριθμό περιπτώσεων χρήσης, όπου περίπτωση χρήσης είναι η περιγραφή μιας συγκεκριμένης λειτουργίας που απαιτείται από το σύστημα. Η όψη αυτή είναι σημαντική διότι επηρεάζει τις υπόλοιπες όψεις, μιας και ο τελικός στόχος είναι το σύστημα να παρέχει τη λειτουργικότητα που περιγράφεται σε αυτήν. Ένα επιπλέον χαρακτηριστικό της όψης αυτής είναι ότι μπορεί να ελεγχθεί εύκολα η ορθότητά της μέσω των πελατών και κατ’ επέκταση να επικυρωθεί το σύστημα.

25

Η Λογική όψη (Logical view) : Περιγράφει το πώς παρέχεται η λειτουργικότητα του συστήματος, από την άποψη της στατικής δομής και δυναμικής συμπεριφοράς του. Σε αντίθεση με την όψη περιπτώσεων χρήσης, επικεντρώνεται στο εσωτερικό του συστήματος. Η στατική δομή περιγράφεται μέσα από το διάγραμμα κλάσεων, ενώ η δυναμική συμπεριφορά μέσα από τα τα διαγράμματα καταστάσεων, ακολουθίας, συνεργασίας και δραστηριοτήτων.

Η όψη συστατικών (Component view) : Περιγράφει την οργάνωση και υλοποίηση των εκτελέσιμων συστατικών και των εξαρτήσεών τους. Περιγράφεται μέσα από το διάγραμμα συστατικών. Η όψη αυτή μπορεί να περιέχει επίσης επιπλέον πληροφορία σχετικά με τα συστατικά, όπως κατανομή των πόρων, ή διοικητική πληροφορία, όπως μια αναφορά προόδου της πορείας της εργασίας.

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

Η όψη ανάπτυξης (Deployment view) : Περιγράφει την ανάπτυξη του συστήματος σε φυσικό επίπεδο, δηλαδή τους κόμβους (υπολογιστές) στους οποίους τρέχουν τα συστατικά της εφαρμογής, καθώς και το πώς συνδέονται μεταξύ τους. Περιγράφεται από το διάγραμμα ανάπτυξης.

2.4 Τα διαγράμματα της UML Τα κυριότερα διαγράμματα της UML είναι τα εξής:

Διάγραμμα περιπτώσεων χρήσης (Use case diagram) Διάγραμμα κλάσεων (Class diagram) Διάγραμμα ακουλουθίας (Sequence diagram) Διάγραμμα συνεργασίας (Collaboration diagram) Διάγραμμα καταστάσεων (Statechart diagram) Διάγραμμα δραστηριότητας (Activity diagram) Διάγραμμα συστατικών (Component diagram) Διάγραμμα ανάπτυξης (Deployment diagram)

Παρακάτω περιγράφονται αναλυτικά τα παραπάνω διαγράμματα. [3][4][6]

26

Διάγραμμα περιπτώσεων χρήσης Το διάγραμμα περιπτώσεων χρήσης στη UML χρησιμοποείται για την μοντελοποίηση της λειτουργικότητας ενός συστήματος, όπως αυτή γίνεται αντιληπτή από τον εξωτερικό χρήστη. Τα διαγράμματα αυτά διαμερίζουν τη λειτουργικότητα του συστήματος σε συναλλαγές που έχουν νόημα για τους χρήστες του συστήματος ή αλλιώς χειριστές (actors). Τα επιμέρους τμήματα της λειτουργικότητας ονομάζονται περιπτώσεις χρήσης (use cases). Το σύνολο των περιπτώσεων χρήσης συνιστούν τη συμπεριφορά του συστήματος. Τα βασικά διαγραμματικά στοιχεία του διαγράμματος περιπτώσεων χρήσης είναι το σύστημα, ο χειριστής, η περίπτωση χρήσης και οι σχέσεις μεταξύ τους. Τα στοιχεία αυτά φαίνονται παρακάτω στο Σχήμα 2.2:

Σχήμα 2.2 Βασικά διαγραμματικά στοιχεία του διαγράμματος περιπτώσεων χρήσης Η αξία του διαγράμματος περιπτώσεων χρήσης είναι ιδιαίτερα σημαντική, διότι καθορίζει τις λειτουργικές απαιτήσεις, οι οποίες θα αποτελέσουν σημείο αναφοράς καθ’ όλη τη διάρκεια ανάπτυξης του συστήματος. Ο σημαντικότερος ρόλος του συγκεκριμένου διαγράμματος είναι ότι αποτελεί ένα μέσο επικοινωνίας μεταξύ πελατών και σχεδιαστών, όσον αφορά στη λειτουργικότητα του συστήματος. Η απλότητα των συμβολισμών το καθιστά ιδανικό για αυτό το σκοπό, παρέχοντας τη δυνατότητα εύκολης αντίληψης του συνόλου των λειτουργιών καθώς και εύκολης τροποποίησής τους. Ο χειριστής αντιπροσωπεύει μια εξωτερική οντότητα, άνθρωπο ή σύστημα, η οποία αλληλεπιδρά με το σύστημα. Ο χειριστής αναπαριστά ένα ρόλο, όχι έναν μεμονωμένο χρήστη του συστήματος, μιας και ο ίδιος χρήστης μπορεί να αλληλεπιδρά με το σύστημα με πολλαπλούς ρόλους. Οι χειριστές είναι κλάσεις με το στερεότυπο «actor», όπου το όνομα της κλάσης γενικά αναπαριστά το ρόλο του χειριστή. Το σύμβολο του χειριστή φαίνεται στο Σχήμα 2.2. Στο διάγραμμα περιπτώσεων χρήσης χρησιμοποιείται μόνο η σχέση γενίκευσης ανάμεσα σε χειριστές, προκειμένου να περιγραφεί η κοινή συμπεριφορά ανάμεσα τους, την οποία και κληρονομούν από μια πρόγονο κλάση χειριστή. Ο τυπικός ορισμός μιας περίπτωσης χρήσης είναι μια ακολουθία ενεργειών που πραγματοποιείται από το σύστημα για την παραγωγή μετρήσιμων αποτελεσμάτων που έχουν νόημα για τον χρήστη. Η περίπτωση χρήσης ορίζει ένα συγκεκριμένο τρόπο

Actor

UseCase

association

generalization

<<include>>

<<extend>>

27

χρησιμοποίησης του συστήματος, προσδιορίζοντας την αλληλεπίδραση ανάμεσα σε έναν ή περισσότερους χειριστές και το σύστημα. Το στιγμιότυπο μιας περίπτωσης χρήσης ονομάζεται σενάριο (scenario), και αναπαριστά ένα συγκεκριμένο μονοπάτι εκτέλεσης (execution path) μέσα στο σύστημα. Ο συμβολισμός φαίνεται στο Σχήμα 2.2. Η περίπτωση χρήσης έχει τα ακόλουθα χαρακτηριστικά: 1. Ξεκινάει πάντα από ένα χειριστή. 2. Πρέπει να επιστρέφει κάποιου είδους απτή πληροφορία στο χρήστη. 3. Μια περίπτωση χρήσης είναι πλήρης, με την έννοια ότι αποτελεί μια πλήρη περιγραφή. Μια περίπτωση χρήσης δε θεωρείται ότι έχει ολοκληρωθεί μέχρις ότου η τελική πληροφορία παραχθεί, ακόμη κι αν απαιτούνται γι’ αυτό πολλαπλές αλληλεπιδράσεις μεταξύ των αντικειμένων. Ένα σύνηθες λάθος είναι η διαίρεση μιάς περίπτωσης χρήσης σε μικρότερες, οι οποίες παράγουν ενδιάμεσα αποτελέσματα. Ανάμεσα στις περιπτώσεις χρήσης υπάρχουν τρία είδη σχέσεων: η επέκταση (extends), η συμπερίληψη (uses ή includes) και η ομαδοποίηση (grouping). Οι σχέσεις αυτές φαίνονται στο Σχήμα 2.2. Η σχέση της επέκτασης είναι μια σχέση γενίκευσης που χρησιμοποιείται στην περίπτωση όπου μια περίπτωση χρήσης συμπεριλαμβάνει ένα τμήμα, όχι απαραίτητα ολόκληρη, την συμπεριφορά της περίπτωσης χρήσης που επεκτείνει. Τέτοιου είδους περιπτώσεις χρήσης χρησιμοποιούνται στο χειρισμό εξαιρέσεων. Η σχέση της συμπερίληψης είναι και αυτή μια σχέση γενίκευσης που χρησιμοποιείται στην περίπτωση όπου μια περίπτωση χρήσης συμπεριλαμβάνει την πλήρη λειτουργικότητα μιας άλλης. Όταν ένα σύνολο περιπτώσεων χρήσης παρουσιάζουν σε κάποια τμήματα κοινή συμπεριφορά, η σχέση αυτή χρησιμοποιείται για τη μοντελοποίηση αυτής της κοινής συμπεριφοράς σε μια περίπτωση χρήσης που χρησιμοποιείται από τις υπόλοιπες. Τέλος με τη σχέση της ομαδοποίησης, περιπτώσεις χρήσης, οι οποίες διαθέτουν παρόμοια συμπεριφορά ή σχετίζονται με κάποιο τρόπο μεταξύ τους, οργανώνονται σε πακέτα. Ωστόσο, για λόγους απλότητας των διαγραμμάτων περιπτώσεων χρήσης η τελευταία σχέση συνήθως δε χρησιμοποιείται. Ακολουθεί ένα παράδειγμα διαγράμματος περιπτώσεων χρήσης για το σύστημα Festo MPS (Σχήμα 2.3):

28

Σχήμα 2.3 Διάγραμμα περιπτώσεων χρήσης για το σύστημα Festo MPS

29

Η περιγραφή των περιπτώσεων χρήσης γίνεται με τη μορφή κειμένου στην ορολογία του χρήστη και αποτελεί μια απλή και συνεπή τεκμηρίωση. Η τεκμηρίωση κάθε περίπτωσης χρήσης, για να είναι πλήρης, θα πρέπει να περιλαμβάνει μια ακολουθία γεγονότων που λαμβάνουν χώρα για την υλοποίηση της επιθυμητής συμπεριφοράς. Επικεντρώνεται στην εξωτερική συμπεριφορά του συστήματος, αγνοώντας τον τρόπο υλοποίησης και την εσωτερική δομή του. Μερικά σημεία τα οποία θα πρέπει να συμπεριλαμβάνονται στην περιγραφή είναι ο στόχος της περίπτωσης χρήσης, από ποιόν χειριστή ξεκινάει, η ακολουθία των μηνυμάτων μεταξύ χειριστή και συστήματος, εναλλακτική ροή γεγονότων σε περιπτώσεις εξαιρέσεων, και τέλος το πώς η περίπτωση χρήσης τερματίζεται επιστρέφοντας κάποια τιμή στο χειριστή. Διάγραμμα κλάσεων Το διάγραμμα κλάσεων είναι ο πρώτος τύπος διαγράμματος της UML που θα δούμε, και ο οποίος έχει άμεση σχέση με τα αντικειμενοστρεφή συστήματα. Τα διαγράμματα περιπτώσεων χρήσης που είδαμε προηγουμένως είναι διαγράμματα καταγραφής προδιαγραφών και είναι χρήσιμα για κάθε τύπο συστήματος. Σε ένα αντικειμενοστρεφές σύστημα τα δομικά στοιχεία του είναι οι κλάσεις και οι σχέσεις μεταξύ των κλάσεων, οι οποίες επιτρέπουν τη συνεργασία αντικειμένων που δημιουργούνται ως στιγμιότυπα των κλάσεων. Το διάγραμμα κλάσεων αποτελείται από τις κλάσεις του συστήματος και τις μεταξύ τους συσχετίσεις, περιγράφοντας με αυτό τον τρόπο τη στατική δομή του συστήματος. Το διάγραμμα κλάσεων μπορεί να χρησιμοποιηθεί σε διάφορες φάσεις της ανάπτυξης του συστήματος. Στο αρχικό στάδιο της ανάλυσης απαιτήσεων οι κατασκευαστές αρχίζουν να αποκτούν γνώση για το πεδίο του προβλήματος του συστήματος. Αυτή η αρχική κατανόηση των εννοιών του πεδίου του προβλήματος καταγράφεται σε ένα διάγραμμα κλάσεων, το οποίο ονομάζεται μοντέλο του πεδίου προβλήματος (problem domain model). Στο μοντέλο αυτό καταγράφονται ως κλάσεις οι έννοιες του πεδίου του προβλήματος και οι μεταξύ τους συσχετίσεις. Έπειτα, στο στάδιο της ανάλυσης, με οδηγό το μοντέλο του πεδίου προβλήματος, κατασκευάζεται ένα διάγραμμα κλάσεων, το οποίο αναπαριστά τη βασική αρχιτεκτονική δομή του συστήματος. Σε αυτό το στάδιο οι κλάσεις πρέπει να επιδιώκουν την αναπαράσταση του συστήματος που μοντελοποιείται με την ελάχιστη δυνατή πληροφορία, χωρίς να επιχειρείται αναφορά σε θέματα υλοποίησης. Στη συνέχεια, μεταβαίνοντας στο στάδιο της σχεδίασης, η περιγραφή των κλάσεων συμπληρώνεται με τις λειτουργίες που υλοποιούν τη συμπεριφορά των αντικειμένων και με επιπρόσθετες ιδιότητες ή συσχετίσεις, που επιβάλλονται από το περιβάλλον υλοποίησης. Τέλος, κατά την υλοποίηση του συστήματος, είναι δυνατόν να επέλθουν τροποποιήσεις στη δομή των κλάσεων λόγω απαιτήσεων που σχετίζονται με απόκρυψη πληροφορίας, ορατότητα και άλλες μη λειτουργικές απαιτήσεις, όπως π.χ. απόδοση και ασφάλεια. Σε μερικές περιπτώσεις, το διάγραμμα κλάσεων είναι το μόνο είδος διαγράμματος της UML που χρησιμοποιείται, λόγω των πληροφοριών που παρέχει σχετικά με τον πηγαίο κώδικα. Όπως θα αναφερθεί παρακάτω, υπάρχει η δυνατότητα αυτόματης παραγωγής τμημάτων κώδικα από το διάγραμμα κλάσεων, καθώς και η αυτόματη δημιουργία διαγραμμάτων κλάσεων λαμβάνοντας ως είσοδο τον πηγαίο κώδικα.

30

Για το λόγο αυτό, ο κάθε συμβολισμός είναι σημαντικός, ακόμα κι αν υποδηλώνεται με ένα στοιχειώδες σύμβολο στο διάγραμμα κλάσεων. Στη συνέχεια παρουσιάζονται τα βασικά διαγραμματικά στοιχεία ενός διαγράμματος κλάσεων. Οι κλάσεις αποτελούν τη βάση της κατασκευής οποιουδήποτε αντικειμενοστρεφούς συστήματος. Ενσωματώνουν δεδομένα, καθώς και τις λειτουργίες που επενεργούν στα δεδομένα αυτά. Ο συμβολισμός της κλάσης φαίνεται στο Σχήμα 2.4. Αν μια κλάση είναι αφηρημένη το όνομα της κλάσης σημειώνεται με πλάγιους χαρακτήρες. Στο παρακάτω σχήμα φαίνεται η κλάση που αναπαριστά το φυσικό αντικείμενο Feeder (Σχήμα 2.4):

Σχήμα 2.4 Η κλάση Feeder Το συντακτικό για τη δήλωση ιδιοτήτων στη UML είναι: ορατότητα όνομα : Τύπος = ΑρχικήΤιμή Ενώ το συντακτικό για τη δήλωση λειτουργιών είναι: ορατότητα όνομα (λίστα παραμέτρων): Επιστρεφόμενος τύπος Η ορατότητα απεικονίζεται με τα σύμβολα “-”, “+”, “#”,“~” τα οποία δηλώνουν ιδιωτική, δημόσια, προστατευμένη καθώς και πρόσβαση σε επίπεδο πακέτου αντίστοιχα. Μια στατική ιδιότητα ή λειτουργία, που ανήκει δηλαδή στην κλάση και όχι στα στιγμιότυπά της, υποδηλώνεται στη UML υπογραμμίζοντας το όνομα της ιδιότητας ή της μεθόδου αντίστοιχα. Μια συσχέτιση μεταξύ δύο κλάσεων απεικονίζει μια στατική σχέση μεταξύ τους. Αν η σχέση αυτή μεταξύ των κλάσεων υφίσταται σε μόνιμη βάση, τότε χρησιμοποιούμε τη συσχέτιση, ενώ αν η σχέση είναι παροδική (π.χ. όταν τα αντικείμενα μιας κλάσης είναι παράμετροι σε μια μέθοδο μιας άλλης κλάσης) χρησιμοποιούμε την εξάρτηση. Ενώ μια συσχέτιση στη UML συνδέει δύο κλάσεις ενός μοντέλου, ένα στιγμιότυπο μιας συσχέτισης συνδέει δύο συγκεκριμένα στιγμιότυπα κλάσεων και ονομάζεται σύνδεση (link). Προαιρετικά μπορούμε να έχουμε σε μία συσχέτιση τα εξής στοιχεία: Όνομα συσχέτισης, το οποίο θα πρέπει να υποδηλώνει με σαφήνεια το νόημα της συσχέτισης. Ονόματα άκρων συσχέτισης: τα οποία υποδηλώνουν το ρόλο αυτής της κλάσης στη συσχέτιση.

31

Πολλαπλότητα: Η πολλαπλότητα αφορά σε ένα άκρο μιας συσχέτισης και είναι το πλήθος των αντικειμένων που μπορεί να σχετίζονται με ένα αντικείμενο της άλλης κλάσης. Πλοϊμότητα: Συμβολίζεται με ένα βέλος στο πέρας της συσχέτισης και υποδηλώνει πλοϊμότητα μόνο προς τη φορά του βέλους. Αφορά στη δυνατότητα που έχουμε από μία κλάση να ανακτήσουμε αντικείμενα της άλλης σε μια συσχέτιση. Όταν δεν υπάρχει πλοϊμότητα υποννοείται πλοϊμότητα και προς τις δύο κατευθύνσεις. Στη συνέχεια αναφέρονται διάφοροι ειδικότεροι τύποι συσχετίσεων. Γενίκευση: Η γενίκευση είναι μια ειδική μορφή συσχέτισης, η οποία αποτελεί μια σχέση μεταξύ μιας γενικής περιγραφής και μιας ειδικότερης περιγραφής που την επεκτείνει. Η γενίκευση αξιοποιεί το μηχανισμό της κληρονομικότητας και επιτρέπει πολυμορφική συμπεριφορά. Συσσωμάτωση και σύνθεση: Η συσσωμάτωση είναι μια σχέση ειδικής μορφής που αναπαριστά μια σχέση συνόλου-τμήματος ή όλου-μέρους (whole-part). Η σύνθεση είναι μιας ισχυρότερης μορφής συσχέτιση στην οποία το σύνολο έχει την αποκλειστική ευθύνη διαχείρισης των τμημάτων , όπως τη δημιουργία και τη διαγραφή τους. Αν διαγραφεί για παράδειγμα η κλάση που αντιστοιχεί στο σύνολο, διαγράφονται και οι κλάσεις των τμημάτων. Στο Σχήμα 3.6 φαίνεται ένα παράδειγμα της σχέσης σύνθεσης από το FestoMPS.

Σχήμα 2.6 Παράδειγμα σχέσης σύνθεσης Εξάρτηση: Μια εξάρτηση υποδηλώνει σημασιολογική σχέση μεταξύ δύο ή περισσοτέρων στοιχείων ενός μοντέλου. Αν δυο κλάσεις Α και Β συνδέονται με μια σχέση εξάρτησης από την Α προς τη Β, υποδηλώνεται ότι, παρόλο που η κλάση Α δε δημιουργεί ούτε «έχει» τη Β, απαιτεί την ύπαρξη της Β για την αποστολή μηνυμάτων προς αυτή. Αν η κλάση Β τροποποιηθεί, ενδεχομένως να απαιτείται και η τροποποίηση της κλάσης Α. Διασύνδεση – σχέση πραγμάτωσης: Η διασύνδεση (interface) είναι ένας τύπος που παρέχει λειτουργίες που είναι στο σύνολό τους αφαιρετικές. Η κλάση η οποία πραγματώνει μια διασύνδεση συνδέεται μαζί της με τη σχέση πραγμάτωσης (realization). Στο παρακάτω σχήμα φαίνεται ένα παράδειγμα σχέσης πραγμάτωσης από το Festo MPS: (Σχήμα 2.7)

32

Σχήμα 2.7 Παράδειγμα σχέσης πραγμάτωσης Παρόλο που ένα μοντέλο στη UML αναπαρίσταται γραφικά, απαιτείται συχνά χρήση κειμένου για μέγιστη δυνατή διαφάνεια. Ένας περιορισμός είναι μια λογική συνθήκη (έκφραση Boole) που πρέπει να είναι αληθής για να λάβει χώρα μια ενέργεια ή για να υπάρξει μια συσχέτιση. Η UML επιτρέπει τον καθορισμό περιορισμών με οποιοδήποτε τρόπο, αρκεί η περιγραφή να βρίσκεται μέσα σε άγκιστρα {}. Ωστόσο, η UML περιλαμβάνει τον ορισμό μιας τυπικής γλώσσας περιορισμών (Object Constraint Language – OCL). Παρακάτω φαίνεται το διάγραμμα κλάσεων για το μηχανικό σύστημα Festo MPS (Σχήμα 2.8)

Σχήμα 2.8 Διάγραμμα κλάσεων για το μηχανικό σύστημα FestoMPS

33

Διάγραμμα ακολουθίας Το διάγραμμα ακολουθίας παρουσιάζει την αλληλεπίδραση μεταξύ αντικειμένων σε δύο διαστάσεις. Η κάθετη διάσταση αντιστοιχεί στην κλίμακα του χρόνου, ενώ στην οριζόντια διάσταση συμβολίζονται τα ανεξάρτητα αντικείμενα. Τα αντικείμενα συμβολίζονται με παραλληλόγραμμα μέσα στα οποία μπορεί να σημειωθεί το όνομα του στιγμιοτύπου του αντικειμένου που συμμετέχει στο σενάριο που απεικονίζεται και ακολουθεί μετά από άνω-κάτω τελεία το όνομα της κλάσης στην οποία ανήκει το αντικείμενο. Σε κάθε αντικείμενο αντιστοιχεί μια κάθετη γραμμή που ονομάζεται γραμμή ζωής (lifeline). Τα αντικείμενα ανταλλάσουν μηνύματα, τα οποία στην επίσημη ορολογία της UML ονομάζονται ερεθίσματα (stimuli). Ένα μήνυμα που αποστέλλεται μεταξύ των αντικειμένων συμβολίζεται ως ένα βέλος από τη γραμμή ζωής ενός αντικειμένου προς τη γραμμή ζωής ενός άλλου. Μήνυμα μπορεί να είναι οτιδήποτε από τα εξής: Κλήση μιας λειτουργίας: όταν ένα αντικείμενο καλεί μια λειτουργία ενός άλλου αντικειμένου. Πρόκειται για σύγχρονο μήνυμα, δηλαδή ο αποστολέας του μηνύματος θα πρέπει να περιμένει την ολοκλήρωση της λειτουργίας για να συνεχίσει.Η κεφαλή του βέλους είναι γεμισμένη με μαύρο χρώμα. Πάνω από το βέλος αναγράφεται το όνομα της λειτουργίας που καλείται, με τις ενδεχόμενες παραμέτρους σε παρενθέσεις. Ειδική περίπτωση κλήσης είναι η αυτοκλήση, η οποία ξεκινάει από το αντικείμενο και καταλήγει πάλι σε αυτό. Σήμα: όταν ένα αντικείμενο αποστέλλει ένα ασύγχρονο μήνυμα σε ένα άλλο αντικείμενο. Τυπικά ασύγχρονα μηνύματα συναντάμε σε πολυνηματικές εφαρμογές, όπου ένα μήνυμα τοποθετείται σε κάποια ουρά ενός νήματος εκτέλεσης ενώ το ενεργό αντικείμενο-παραλήπτης θα επεξεργαστεί το μήνυμα σε κάποια επόμενη χρονική στιγμή. Η διαφορά με την κλήση λειτουργίας στον συμβολισμό είναι πως η κατάληξη είναι ένα ανοιχτό βέλος. Επιστροφή κλήσης: είναι ένα διακεκομμένο βέλος το οποίο συμβολίζει την επιστροφή από μία κλήση λειτουργίας. Πάνω στο διακεκομμένο βέλος αναγράφεται συνήθως η τιμή επιστροφής, αν υπάρχει.. Μηνύματα υπό συνθήκη: Στα μηνύματα υπό συνθήκη τοποθετούνται αγκύλες μέσα στις οποίες αναγράφεται μία συνθήκη που μπορεί να είναι αληθής ή ψευδής. Η σημασία του συμβολισμού είναι ότι το μήνυμα θα αποσταλεί μόνο αν η συνθήκη είναι αληθής. Αν θέλουμε ταυτόχρονα να δείξουμε μια αποστολή εναλλακτικού μηνύματος στην περίπτωση που η συνθήκη είναι ψευδής, τότε δείχνουμε τα δύο αμοιβαία αποκλειόμενα μηνύματα σαν μηνύματα με το ίδιο σημείο εκκίνησης και γράφουμε στο πρώτο τη συνθήκη και στο δεύτερο τη φράση [else], όπως δείχνει το παρακάτω σχήμα. Σε ένα διάγραμμα ακολουθίας είναι δυνατόν να προστεθούν και περισσότεροι συμβολισμοί που υποδηλώνουν βρόχους επανάληψης, μηνύματα που αποστέλλονται πολλαπλές φορές, συγχρονισμό νημάτων κ.ο.κ. Ωστόσο, ο σκοπός των διαγραμμάτων ακολουθίας δεν είναι να αποτυπώσουν τις λεπτομέρειες ενός

34

αλγορίθμου αλλά να αναπαραστήσουν με απλό και κατανοητό τρόπο τα σενάρια συνεργασίας μεταξύ αντικειμένων. Στο Σχήμα 2.9 φαίνεται το διάγραμμα ακολουθίας για την περίπτωση χρήσης “Front position reached” με actor τον Feeder.

Σχήμα 2.9 Διάγραμμα ακολουθίας για την περίπτωση χρήσης “Front position reached” Διάγραμμα συνεργασίας Σε ένα διάγραμμα συνεργασίας απεικονίζονται τα συνεργαζόμενα αντικείμενα και οι συσχετίσεις μεταξύ τους. Ενώ τα διαγράμματα ακολουθίας απεικονίζουν κυρίως τη ροή των μηνυμάτων σε ένα σενάριο μιας περίπτωσης χρήσης, τα διαγράμματα συνεργασίας χρησιμοποιούνται για να παρουσιάσουν τις σχέσεις μεταξύ αντικειμένων. Πλησίον των συνδέσεων εμφανίζονται ως μικρότερες ακμές τα μηνύματα που αποστέλλονται. Για να απεικονιστεί η ακολουθία των μηνυμάτων που ανταλλάσσονται χρησιμοποιείται αρίθμηση των μηνυμάτων. Τα διαγράμμα ακολουθίας και συνεργασίας θεωρούνται συμπληρωματικά, καθώς περιέχουν την ίδια πληροφορία άλλα κάθε ένα δίνει μια διαφορετική οπτική γωνία (σε πολλά εργαλεία το ένα είδος διαγράμματος παράγεται αυτόματα από το άλλο). Το διάγραμμα συνεργασίας που αντιστοιχεί στο διάγραμμα ακολουθίας του Σχήματος 2.9 είναι αυτό που απεικονίζεται στο Σχήμα 2.10

35

Σχήμα 2.10 Διάγραμμα συνεργασίας Από ένα τέτοιο διάγραμμα είναι εύκολο να αντιληφθεί κανείς την ομάδα των συνεργαζόμενων αντικειμένων και την ύπαρξη των συνδέσεων μεταξύ τους αλλά είναι δυσκολότερο να οπτικοποιηθεί η ροή των μηνυμάτων, η οποία φαίνεται καλύτερα στο διάγραμμα ακολουθίας. Διάγραμμα καταστάσεων Το διάγραμμα καταστάσεων χρησιμοποιείται για την περιγραφή της ροής του ελέγχου σε ένα σύστημα εστιάζοντας στις αλλαγές κατάστασης που λαμβάνουν χώρα σε ένα αντικείμενο. Πολύ συχνά οι προδιαγραφές ενός συστήματος μπορούν να καθοριστούν βάσει μιας μηχανής πεπερασμένων καταστάσεων (finite state machine) ή απλά μηχανής καταστάσεων. Συνήθως, μια μηχανή καταστάσεων περιγράφεται ως ένας γράφος όπου οι κόμβοι αντιστοιχούν σε καταστάσεις και τα βέλη υποδηλώνουν τη μετάβαση από μια κατάσταση σε μια άλλη. Εν γένει, οι μηχανές πεπερασμένων καταστάσεων είναι κατάλληλες για την περιγραφή σύγχρονων συστημάτων. Συνήθως, ένα διάγραμμα καταστάσεων είναι προσαρτημένο σε μια κλάση και αποτελεί ένα μοντέλο όλων των δυνατών κύκλων ζωής ενός αντικειμένου της κλάσης. Κάθε αντικείμενο αντιμετωπίζεται ως ξεχωριστή οντότητα που επικοινωνεί με το περιβάλλον ανιχνεύοντας γεγονότα και αντιδρώντας σε αυτά. Όταν λαμβάνει χώρα ένα ανιχνέυσιμο γεγονός, το αντικείμενο αποκρίνεται με βάση την κατάσταση στην οποία βρίσκεται. Η εκτέλεση μιας ενέργειας μπορεί να οδηγήσει σε μετάβαση σε μια άλλη κατάσταση. Σε ένα διάγραμμα καταστάσεων της UML απεικονίζονται γεγονότα, καταστάσεις και μεταβάσεις:

36

Ένα γεγονός (event) έχει χωρική και χρονική θέση στο σύστημα αλλά δεν έχει διάρκεια. Ένα γεγονός συμβολίζεται σημειώνοντας το όνομα του στις μεταβάσεις τις οποίες προκαλεί. Στην περίπτωση που κάποια ενέργεια πραγματοποιείται ταυτόχρονα με την εμφάνιση ενός γεγονότος, σημειώνεται μετά το όνομα του γεγονότος διαχωρισμένη με κάθετο “/”. Μια κατάσταση (state) περιγράφει μια χρονική περίοδο κατά τη διάρκεια ζωής ενός αντικειμένου. Μπορεί να χαρακτηριστεί ως ένα σύνολο τιμών για τις ιδιότητες του αντικειμένου που είναι παρόμοιες από κάποια άποψη, ως μια περίοδος κατά την οποία ένα αντικείμενο αναμένει την εμφάνιση ενός γεγονότος, ή ως μία περίοδος κατά την οποία ένα αντικείμενο εκτελεί μια εργασία. Μια κατάσταση συμβολίζεται ως ένα ορθογώνιο με καμπύλες γωνίες. Ειδικά για το συμβολισμό της αρχικής κατάστασης ενός συστήματος χρησιμοποιείται ένας «γεμισμένος κύκλος». Μια μετάβαση καθορίζει την απόκριση ενός αντικειμένου που βρίσκεται σε μια κατάσταση όταν λάβει χώρα ένα γεγονός. Εν γένει, μια μετάβαση περιλαμβάνει το γεγονός που την ενεργοποιεί , προαιρετικά μια συνθήκη ελέγχου έτσι ώστε η μετάβαση να πραγματοποιείται μόνο όταν η συνθήκη είναι αληθής, μια ενέργεια και μια τελική κατάσταση. Ένα διάγραμμα καταστάσεων από το σύστημα Festo MPS για το φυσικό αντικείμενο Feeder φαίνεται στο Σχήμα 2.11 .

Σχήμα 2.11 Διάγραμμα καταστάσεων για το φυσικό αντικείμενο Feeder Διάγραμμα δραστηριότητας Ένας γράφος δραστηριότητας είναι μια ειδική μορφή μηχανής καταστάσεων που έχει ως στόχο τη μοντελοποίηση των υπολογισμών και της ροής της εργασίας. Οι καταστάσεις του γράφου δραστηριότητας αναπαριστούν τις καταστάσεις εκτέλεσης ενός υπολογισμού, όχι τις καταστάσεις των αντικειμένων που συμμετέχουν. Υπό κανονικές συνθήκες, ένας γράφος δραστηριότητας προϋποθέτει ότι οι υπολογισμοί πραγματοποιούνται χωρίς εξωτερικές γεγονοδηγούμενες διακοπές, αλλιώς είναι

37

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

Activity1

Δραστηριότητα Μετάβαση Απόφαση Συγχρονισμός Σχήμα 2.12 Διαγραμματικά στοιχεία του διαγράμματος δραστηριότητας Οι διακλαδώσεις συμβολίζονται είτε με συνθήκες φρουρούς επί των μεταβάσεων είτε με κόμβους απόφασης (ρόμβους) με πολλαπλές εξερχόμενες ακμές. Μια ένωση συμβολίζει συνένωση πολλών εισερχόμενων μεταβάσεων σε μία εξερχόμενη, ενώ μια διχάλα την ανάλυση μιας εισερχόμενης μετάβασης σε πολλές παράλληλες εξερχόμενες μεταβάσεις. Τα διαγράμματα δραστηριότητας είναι χρήσιμα για την ανάλυση μιας περίπτωσης χρήσης (συνοδεύοντας την τεκμηρίωση της) όταν πρέπει να γίνει κατανοητό ποιές ενέργειες πρέπει να πραγματοποιηθούν υπό διάφορες δυνατές συνθήκες. Επιπρόσθετα, τα διαγράμματα δραστηριότητας είναι χρήσιμα για την περιγραφή πολύπλοκων αλγορίθμων, οι οποίοι πρόκειται να υλοποιηθούν από μία ή και περισσότερες μεθόδους μιας κλάσης. Διάγραμμα συστατικών Ένα συστατικό (component) είναι μια φυσική μονάδα υλοποίησης κώδικα με σαφώς προσδιορισμένες διασυνδέσεις, η οποία αποτελεί επαναχρησιμοποιήσιμο τμήμα του συστήματος. Σε ένα αντικειμενοστρεφές σύστημα ένα συστατικό ενσωματώνει την υλοποίηση μίας ή περισσοτέρων κλάσεων. Καλά σχεδιασμένα συστατικά δε θα πρέπει να εξαρτώνται άμεσα από άλλα συστατικά αλλά μόνο από διασυνδέσεις. Οι εξαρτήσεις έχουν επίδραση στη συντήρηση ενός συστήματος λογισμικού. Αν κάποιο συστατικό Α εξαρτάται από κάποιο άλλο συστατικό Β, οποιαδήποτε αλλαγή στο Β μπορεί να επηρεάσει το Α. Υπό την ίδια έννοια, οι εξαρτήσεις καθορίζουν την ευκολία επαναχρησιμοποίησης ενός συστατικού. Στην περίπτωση όπου ένα συστατικό στο σύστημα μπορεί να

38

αντικατασταθεί από κάποιο άλλο, που υποστηρίζει τις ίδιες διασυνδέσεις, δεν επιφέρονται αλλαγές στο υπόλοιπο σύστημα. Ένα διάγραμμα συστατικών απεικονίζει το δίκτυο των εξαρτήσεων μεταξύ των συστατικών του συστήματος. Μια εξάρτηση μεταξύ δύο συστατικών υποδηλώνει ότι για την ορθή λειτουργία του ενός συστατικού απαιτείται η ύπαρξη ενός άλλου. Το συστατικό συμβολίζεται ως ένα ορθογώνιο ενώ οι εξαρτήσεις συμβολίζονται ως διακεκομμένες ακμές με κατεύθυνση από το εξαρτώμενο συστατικό προς αυτό που παρέχει τις λειτουργίες. Στα διαγράμματα συστατικών υπάρχει η δυνατότητα απεικόνισης λογικών τμημάτων ενός συστήματος με τη χρήση των πακέτων. Ένα πακέτο περιλαμβάνει ένα σύνολο από συστατικά τα οποία έχουν λειτουργική συνάφεια. Ο συμβολισμός ενός πακέτου στη UML επιτυγχάνεται με τη χρήση ενός φακέλου. Διάγραμμα ανάπτυξης Το διάγραμμα ανάπτυξης περιγράφει την οργάνωση των επεξεργαστικών πόρων (κόμβων) του συστήματος και την αντιστοίχιση των συστατικών λογισμικού στους κόμβους αυτούς. Κατά κύριο λόγο απεικονίζουν την τοπολογία του υλικού επί του οποίου εκτελείται το σύστημα λογισμικού. Ένας κόμβος (node) είναι ένα φυσικό αντικείμενο που αναπαριστά έναν υπολογιστικό πόρο , ο οποίος στη γενική περίπτωση έχει τουλάχιστον μνήμη και δυνατότητα επεξεργασίας. Οι κόμβοι μπορούν να αντιστοιχίζονται σε στερεότυπα ώστε να διακρίνονται διαφορετικά είδη πόρων, όπως Κεντρικές μονάδες επεξεργασίας, μνήμες, εξυπηρετητές για βάσεις δεδομένων και συσκευές διασύνδεσης με άλλα συστήματα. Ένας κόμβος συμβολίζεται ως ένας τρισδιάστατος κύβος με το όνομα του κόμβου και ενδεχομένως ένα στερεότυπο που εκφράζει την κατηγορία στην οποία ανήκει. Σε κάθε κόμβο μπορούν προαιρετικά να αναφερθούν (υπό μορφή σημειώσεων) και τα συστατικά τα οποία εκτελούνται σε αυτόν. Η τοπολογία του συστήματος απεικονίζεται συνδέοντας τους κόμβους με γραμμές συσχέτισης, οι οποίες μπορούν να υποδηλώνουν ρητά το πρωτόκολλο επικοινωνίας ή να χαρακτηρίζουν το σύστημα μεταφοράς δεδομένων με κάποιο τρόπο. Το διάγραμμα ανάπτυξης δεν προσφέρει σημαντική πληροφορία για μια αυτόνομη αντικειμενοστρεφή εφαρμογή που εκτελείται αποκλειστικά σε έναν υπολογιστή. Χρησιμοποιείται από μηχανικούς συστημάτων για τη μοντελοποίηση ενσωματωμένων συστημάτων, συστημάτων πελάτη/εξυπηρετητή, όπου υπάρχει σαφής διαχωρισμός μεταξύ των εφαρμογών που εκτελούνται στο σύστημα του πελάτη και των μονίμων δεδομένων που φιλοξενούνται στον εξυπηρετητή, καθώς και πλήρως κατανεμημένων συστημάτων που περιλαμβάνουν συνήθως πολλαπλά επίπεδα εξυπηρετητών και συνήθως φιλοξενούν πολλαπλές εκδόσεις των συστατικών λογισμικού στους κόμβους τους.

39

2.5 Η UML στην ανάπτυξη ενσωματωμένων συστημάτων

Η πλούσια γραφική σημειολογία της UML σε συνδυασμό με τις δυνατότητες μοντελοποίησης που παρέχει, επιτρέπει τον προσδιορισμό και την οπτικοποίηση της δομής και της συμπεριφοράς του συστήματος σε πολλαπλά επίπεδα αφαίρεσης. Τα στοιχεία αυτά την καθιστούν ικανή να χρησιμοποιηθεί στην ανάπτυξη ενσωματωμένων συστημάτων για τη μοντελοποίηση και την τεκμηρίωσή τους. H UML παρέχει ένα πλούσιο σύνολο στοιχείων μοντελοποίησης που δίνουν τη δυνατότητα να μοντελοποιηθούν τα πιο σημαντικά χαρακτηριστικά των κατανεμημένων συστημάτων πραγματικού χρόνου, όπως η απόδοση (χρησιμοποιώντας tagged attributes ή την OCL [7]), οι φυσικοί πόροι (χρησιμοποιώντας διαγράμματα ανάπτυξης) και ο χρόνος (χρησιμοποιώντας classifiers και tagged attributes). Ωστόσο, υπάρχουν οι εξής επιπλέον παράγοντες που πρέπει να ληφθούν υπόψη: Η μοντελοποίηση εφαρμογών συγκεκριμένου πεδίου είναι ευκολότερη αν χρησιμοποιείται μια πιο εξειδικευμένη (domain-specific) σημειολογία, η οποία αναπαριστά τα βασικά στοιχεία και πρότυπα (patterns) του συγκεριμένου πεδίου. Επιπλέον, απαιτείται μια σαφώς ορισμένη σημασιολογία για το συγκεκριμένο πεδίο, προκειμένου να αποφευχθεί η διαφορετική ερμηνεία ίδιων μοντέλων και να υποστηριχθούν τα εργαλεία ανάλυσης. Τέλος, πολλαπλά διαγράμματα μπορούν να χρησιμοποιηθούν για να περιγράψουν διαφορετικές όψεις του συστήματος. Η δυνατότητα περιγραφής του ίδιου αντικειμένου από διαφορετικές οπτικές γωνίες διευκολύνει μεν την τεκμηρίωση του συστήματος, αλλά μπορεί να καταλήξει σε ασυνέπειες μεταξύ των διαγραμμάτων, όταν η χρήση της UML δε συνδέεται με μια αυστηρώς ορισμένη μέθοδο σχεδιασμού. Για τους παραπάνω λόγους, για την ανάπτυξη εφαρμογών ενσωματωμένων συστημάτων, αλλά και γενικότερα εφαρμογών συγκεκριμένου πεδίου, απαιτείται [8]

μια γλώσσα συγκεκριμένου πεδίου, η οποία ονομάζεται profile και βασίζεται στη βασική υποδομή της UML και περιλαμβάνει domain-specific building blocks (που ορίζονται χρησιμοποιώντας την έννοια του στερεοτύπου)

μια μεθοδολογία, η οποία ορίζει το πώς και πότε η profile σημειολογία πρέπει να χρησιμοποιείται.

Ένα UML profile για τα ενσωματωμένα συστήματα πρέπει να περιλαμβάνει εξειδικευμένη σημειολογία για την αναπαράσταση της δομής και της συμπεριφοράς των platform resources και των υπηρεσιών που παρέχουν, με ιδιαίτερη έμφαση σε θέματα απόδοσης και κόστους. Πρέπει επίσης να παρέχει τη δυνατότητα οπτικοποίησης πολλαπλών εναλλακτικών υλοποιήσεων για να διευκολύνει τη γρήγορη σύγκρισή τους. [8] Το UML Platform profile είναι μια γραφική γλώσσα για την τεκμηρίωση των embedded system platforms. Περιλαμβάνει domain-specific classifiers και σχέσεις εξειδικευμένες με στερεότυπα, που συμπληρώνουν τη σημειολογία που είναι ορισμένη στη UML και στο UML Profile for Schedulability, Performance and Time

40

Specification (ή αλλιώς Real-Time UML Profile) [9]. Έτσι επιτυγχάνεται η μοντελοποίηση της δομής και της συμπεριφοράς των ενσωματωμένων συστημάτων και η αναπαράσταση της σχέσης μεταξύ των platforms σε διαφορετικά επίπεδα αφαίρεσης. Στη συνέχεια περιγράφεται μια προσέγγιση για την ανάπτυξη συστημάτων βασισμένη στα executable models [10], η οποία δείχνει το πώς η UML μπορεί να χρησιμοποιηθεί για την ανάπτυξη ενσωματωμένων συστημάτων. Στο Σχήμα 2.13 παρακάτω φαίνεται η διαδικασία ανάπυξης του συστήματος με βάση αυτή την προσέγγιση.

Σχήμα 2.13 Η συνολική διαδικασία ανάπτυξης [10] Το πρώτο βήμα της διαδικασίας ανάπτυξης (το οποίο φαίνεται στο Σχήμα 2.13 ως μια λάμπα) αναπαριστά το concept πίσω από την ανάπτυξη ενός ενσωματωμένου συστήματος. Το concept αυτό διαμορφώνεται με βάση την επιθυμητή λειτουργικότητα, η οποία εκφράζεται από τη συμμετοχή της αγοράς, και τη διαθεσιμότητα, η οποία εκφράζεται από τη συμμετοχή ειδικών υλικού και λογισμικού. Ο καθορισμός του concept πίσω από ένα προϊόν είναι συχνά ένας συμβιβασμός και μια αντιστάθμιση ανάμεσα σε πιθανά χαρακτηριστικά που είναι επιθυμητά από την αγορά και τις δυνατότητες που μπορούν να προσφερθούν από μια δεδομένη αρχιτεκτονική υλικού-λογισμικού. Σε αυτό το σημείο η διαδικασία ανάπτυξης χωρίζεται στoν τομέα της εφαρμογής και αυτόν της αρχιτεκτονικής. Πρώτα περιγράφεται ο τομέας της εφαρμογής. Τα application models είναι εκτελέσιμα και αποτελούνται από τρία πρωτεύοντα διαγράμματα, όπως φαίνεται στο Σχήμα 2.14 παρακάτω:

41

Σχήμα 2.14 Ένα παράδειγμα application model [10] Το πρώτο μέρος είναι η δήλωση των εννοιολογικών αντικειμένων του συγκεκριμένου συστήματος, η οποία γίνεται με τη βοήθεια του διαγράμματος κλάσεων της UML. Πρέπει να σημειωθεί ότι αυτή η χρήση του διαγράμματος κλάσεων δεν έχει καμία σχέση με τη δομή του λογισμικού. Σε ένα translatable model, ένα διάγραμμα κλάσεων αναπαριστά μόνο την εννοιολογική ομαδοποίηση πληροφορίας και συμπεριφοράς [10]. Στο δεύτερο μέρος του Σχήματος 2.13 αναπαριστάται η συμπεριφορά στο χρόνο, χρησιμοποιώντας ένα διάγραμμα καταστάσεων της UML. Διαγράμματα καταστάσεων μπορούν να κατασκευαστούν για τα στιγμιότυπα των κλάσεων μεμονωμένα, ή και συνολικά για ένα σύνολο στιγμιοτύπων. Έτσι, μέσα από τη μηχανή καταστάσεων μοντελοποιείται όλη η δυναμική συμπεριφορά του application model. Ένα εκτελέσιμο μοντέλο είναι ασήμαντο χωρίς την ύπαρξη κανόνων, οι οποίοι ορίζουν την εκτέλεση. Στην executable UML, κάθε μηχανή καταστάσεων εκτελείται ταυτόχρονα με όλες τις άλλες. Οι μηχανές αυτές επικοινωνούν στέλνοντας σήματα, τα οποία ορίζουν σχέσεις προτεραιότητας ανάμεσα σε ακολουθίες ενεργειών. Όπως και με τα διαγράμματα κλάσεων, το διάγραμμα καταστάσεων αυτό δεν έχει να κάνει με την υλοποίηση, μιας και τα σήματα μπορούν να υλοποιηθούν με οποιοδήποτε τρόπο ικανοποιεί την επιθυμητή προτεραιότητα των ενεργειών. Οι ενέργειες (actions) είναι το τελευταίο από τα πρωτεύοντα κατασκευάσματα της executable UML. Οι ενέργειες είναι επίσης ανεξάρτητες της υλοποίησης, με την έννοια ότι δεν υποδηλώνουν τη δόμηση του λογισμικού. Η αρχιτεκτονική είναι ένα σύνολο κανόνων που ορίζουν το πώς μπορεί να μετατραπεί μια εφαρμογή γραμμένη σε executable UML σε υλοποίηση. Ο ορισμός της αρχιτεκτονικής μπορεί να γίνει σε οποιοδήποτε χρόνο συγκριτικά με τον ορισμό της εφαρμογής. Ένα συνεπές σύνολο κανόνων που προορίζονται για μια αρχιτεκτονική καλείται model compiler. Όταν παράγεται ένα executable UML model, η σημασία του μοντέλου αποθηκεύεται σε μια βάση δεδομένων. Το διάγραμμα που φαίνεται στο Σχήμα 2.14 παραπάνω δημιουργεί στιγμιότυπα στη βάση δεδομένων όπως φαίνεται στο Σχήμα 2.15 παρακάτω.

42

Σχήμα 2.15 Μεταμοντέλο [10]

Η δομή της βάσης δεδομένων δημιουργείται από τα elements της executable UML. Έτσι, υπάρχει ένας πίνακας Class για την αποθήκευση της πληροφορίας σχετικά με τις κλάσεις, και ένας πίνακας State για την αποθήκευση πληροφορίας σχετικά με τις καταστάσεις. Η δομή αυτής της βάσης δεδομένων καλείται μεταμοντέλο (metamodel).

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

Αφού παραχθεί το κείμενο από τον model compiler μπορεί αν μεταφραστεί σε κάποια γλώσσα επιλογής C,C++ ή Assembly. Αυτό αναπαριστά τη μετάβαση από τις αφηρημένες model-driven αρχιτεκτονικές στο περιβάλλον ανάπτυξης λογισμικού ενσωματωμένων συστημάτων. Ένας open model compiler κάνει τη διαδικασία ελεγχόμενη. Ένας περαιτέρω έλεγχος του κώδικα που παρήχθη μπορεί να γίνει με τη χρήση ενός debugger. Με τη βοήθεια ενός prototyper μπορεί να γίνει η εξομοίωση του πλήρους συστήματος, προτού συγκεντρωθεί το απαραίτητο hardware.

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

43

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

44

Κεφάλαιο 3

Ανάλυση και σχεδιασμός του συστήματος 3.1 Γενικά Το εργαλείο που χρησιμοποιήθηκε για τη μοντελοποίηση του συστήματος είναι το open source CASE tool StarUML. Το StarUML χρησιμοποιείται για την ανάπτυξη μιας γρήγορης, ευέλικτης και επεκτάσιμης UML/MDA (Model Driven Architecture) πλατφόρμας, η οποία τρέχει πάνω σε Win32. Ο στόχος της ανάπτυξης του εργαλείου αυτού ήταν η παραγωγή ενός εργαλείου μοντελοποίησης λογισμικού και επίσης μιας πλατφόρμας για την αντικατάσταση των εμπορικών UML εργαλείων, όπως το Rational Rose. [11] Το StarUML υποστηρίζει τα περισσότερα διαγράμματα της UML 2.0, τα οποία είναι τα εξής: Διάγραμμα περιπτώσεων χρήσης, διάγραμμα κλάσεων, διάγραμμα ακολουθίας, διάγραμμα συνεργασίας, διάγραμμα δραστηριοτήτων, διάγραμμα καταστάσεων, διάγραμμα συστατικών, διάγραμμα ανάπτυξης, robustness diagram και composite structure diagram. Επιπλέον, το διάγραμμα αντικειμένων και το διάγραμμα πακέτων (package diagram) μπορούν να μοντελοποιηθούν μέσω του editor του διαγράμματος κλάσεων. To StarUML διαθέτει τα εξής πλεονεκτήματα / χαρακτηριστικά :

Παρέχει ένα πλούσιο σύνολο modeling features και επιλογών μορφοποίησης

Δίνει τη δυνατότητα παραγωγής κώδικα από UML διαγράμματα Υποστηρίζει τις γλώσσες C++, C# και Java Υποστηρίζει το Reverse engineering Υποστηρίζει την εξαγωγή διαγραμμάτων σε JPG/XMI format Έχει γρήγορο load/execution time συγκριτικά με τα υπόλοιπα UML

εργαλεία Δίνει τη δυνατότητα για verification του μοντέλου

45

Μειονεκτήματα:

Δεν υποστηρίζει την εξαγωγή διαγραμμάτων σε SVG format Τρέχει μόνο σε Win32 platform Παράγει stub code, χωρίς να ενσωματώνει στις μεθόδους τη

λειτουργικότητα που μοντελοποιείται από το διάγραμμα ακολουθίας, και δε δίνει τη δυνατότητα ενσωμάτωσης των σωμάτων των μεθόδων.

3.2 Ανάλυση του συστήματος Στόχος της φάσης ανάλυσης του συστήματος είναι η κατανόηση του συστήματος και καταγραφή της λειτουργικότητας την οποία θα πρέπει να παρέχει. Στα πλαίσια αυτής της φάσης κατασκευάστηκε το μοντέλο απαιτήσεων και το μοντέλο ανάλυσης. 3.2.1 Μοντέλο Απαιτήσεων

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

Αρχικά αναγνωρίστηκαν οι εξωτερικές οντότητες οι οποίες αλληλεπιδρούν με την εφαρμογή ελέγχου. Οι οντότητες αυτές είναι ο χειριστής και τα μηχανικά μέρη του συστήματος, δηλαδή ο Feeder, o Converter, ο Elevator, o Shift-out cylinder, τo Rotating disc, το Drilling machine, το Checking machine και o Warehouse cylinder. Στη συνέχεια εστιάσαμε στην επικοινωνία της εφαρμογής με το περιβάλλον της για την εύρεση των περιπτώσεων χρήσης του συστήματος. Η εφαρμογή επικοινωνεί με το πραγματικό σύστημα μέσα από τα μηνύματα των αισθητήρων και των ενεργοποιητών. Δέχεται μηνύματα από το πραγματικό σύστημα μέσω των αισθητήρων και σε απόκριση αυτών των μηνυμάτων στέλνει μηνύματα σε αυτό μέσω των ενεργοποιητών. Συνεπώς, σαν περιπτώσεις χρήσης του συστήματος από την πλευρά του πραγματικού συστήματος μπορούμε να θεωρήσουμε τα μηνύματα τα οποία στέλνουν οι αισθητήρες στην εφαρμογή μας. Η βασική λειτουργικότητα που πρέπει να παρέχει η εφαρμογή στον χειριστή του συστήματος είναι η δυνατότητα αρχικοποίησης, εκκίνησης και τερματισμού του συστήματος, καθώς και η ενημέρωση του χειριστή για την εκάστοτε κατάσταση του συστήματος. Τα μηνύματα αυτά αποτελούν τις περιπτώσεις χρήσης του συστήματος από την πλευρά του χειριστή. Συνεπώς, η λίστα των περιπτώσεων χρήσης του συστήματος είναι:

Front position reached (με actor τον Feeder) Back position reached (με actor τον Feeder) Workpiece in position A Workpiece sucked in Right stop reached

46

Left stop reached Workpiece in position B Front position reached (με actor τον Shift out cylinder) Back position reached (με actor τον Shift out cylinder) Elevator up Elevator down Workpiece in position 1 Workpiece in position 2 Workpiece in position 3 Workpiece in position 4 Rotation done Workpiece bracked-in Workpiece bracked-out Lifting cylinder up Lifting cylinder down Checking cylinder up Checking cylinder down Cylinder returned to disc Piece removed from table Vakuum has been started Initialize system Start Stop Urgent stop Get status

Ακολουθούν ενδεικτικές περιγραφές περιπτώσεων χρήσης: Use case: Εκκίνηση συστήματος Actor: Operator Description: Ο χρήστης στένει το μήνυμα εκκίνησης στο σύστημα. Το σύστημα στέλνει στον Feeder το μήνυμα να κινηθεί προς τα εμπρός. Το use case τερματίζεται. Use case: Front position reached. Actor: Feeder Description: O Feeder ενημερώνει το σύστημα ότι έφτασε στην μπροστινή θέση τερματισμού. Το σύστημα ενημερώνει την κατάσταση του και στέλνει στο Feeder το μήνυμα να σταματήσει. Κατόπιν του στέλνει το μήνυμα να κινηθεί προς τα πίσω και ενημερώνει πάλι την κατάσταση του. Το use case τερματίζεται. Use case: Elevator down. Actor: Elevator Description: O Elevator ενημερώνει το σύστημα ότι έφτασε στην κάτω θέση τερματισμού. Το σύστημα ενημερώνει την κατάσταση του και στέλνει στον Elevator το μήνυμα να σταματήσει. Στη συνέχεια, ελέγχει αν η θέση Β είναι ελεύθερη. Αν η θέση Β είναι κατειλημμένη το σύστημα στέλνει στον Shift out cylinder το μήνυμα να κινηθεί προς τα εμπρός. Το use case τερματίζεται. Στο σχήμα 3.1 φαίνεται το διάγραμμα περιπτώσεων χρήσης για το FestoMPS:

47

Σχήμα 3.1 Διάγραμμα περιπτώσεων χρήσης της εφαρμογής ελέγχου του Festo MPS

48

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

Σύμφωνα με αρκετές αντικειμενοστρεφείς μεθοδολογίες, στο μοντέλο ανάλυσης διακρίνουμε τρεις διαφορετικούς τύπους αντικειμένων: entity objects, interface ή boundary objects και control objects. Καθένα από αυτά τα αντικείμενα εκφράζει κυρίως μία από τις τρεις διαστάσεις του information space. Η διάσταση της πληροφορίας (information) προσδιορίζει την πληροφορία η οποία κρατείται στο σύστημα, τόσο βραχυχρόνια όσο και μακροχρόνια, περιγράφοντας με αυτόν τον τρόπο την εσωτερική κατάσταση τους συστήματος. Η διάσταση της συμπεριφοράς (behavior) προσδιορίζει τη συμπεριφορά την οποία θα υιοθετήσει το σύστημα. Εδώ ορίζεται το πώς και το πότε το σύστημα θα αλλάξει κατάσταση. Η διάσταση της παρουσίασης (presentation) παρέχει τις λεπτομέρειες για τη διεπαφή του συστήματος με το περιβάλλον του. Το μοντέλο ανάλυσης δομείται από αντικείμενα που ορίζονται πάνω σε αυτό το information space. Καθένα από αυτά τα αντικείμενα περιλαμβάνει τουλάχιστον δύο από τις τρεις διαστάσεις που αναφέρθηκαν, αλλά με σαφή κλίση προς μία από αυτές. [12]

Τα entity objects χρησιμοποιούνται για να μοντελοποιήσουν πληροφορία, η οποία θα πρέπει να κρατηθεί για το σύστημα. Τα αντικείμενα αυτά περιλαμβάνουν επίσης την συμπεριφορά που απαιτείται για το χειρισμό αυτής της πληροφορίας. Τα interface objects μοντελοποιούν τη συμπεριφορά και την πληροφορία εξαρτώμενη από τη διεπαφή του συστήματος. Τέλος, τα control objects μοντελοποιούν τη συμπεριφορά η οποία ουσιαστικά δεν ανήκει σε κάποιο entity ή interface object. Τα αντικείμενα αυτά διαθέτουν τη λογική ελέγχου ενός ή περισσοτέρων αντικειμένων. Ο συμβολισμός των τριών τύπων αντικειμένων φαίνεται στο Σχήμα 3.2.

Σχήμα 3.2 Οι τύποι των αντικειμένων Το πλεονέκτημα της χρησιμοποίησης αυτών των τριών τύπων αντικειμένων είναι ότι με αυτόν τον τρόπο εξασφαλίζεται τοπικότητα σε πιθανές μελλοντικές αλλαγές που θα συμβούν στο σύστημα. Για παράδειγμα, σε περίπτωση που υπάρξει κάποια αλλαγή η οποία θα αφορά στη διεπαφή του συστήματος, τα μόνα αντικείμενα που θα πρέπει να επηρεαστούν είναι τα interface objects. Τα κυριότερα διαγράμματα που συνήθως κατασκευάζονται σε αυτό το μοντέλο είναι είναι το διάγραμμα κλάσεων και το διάγραμμα ακολουθίας, ωστόσο αυτό εξαρτάται από τη μεθοδολογία (process) που ακολουθείται.

49

Προκειμένου να βρεθούν τα αντικείμενα από τα οποία αποτελείται η εφαρμογή ακολουθήθηκε η OOSE μεθοδολογία [12], με βάση την οποία, για κάθε περίπτωση χρήσης εντοπίστηκαν τα αντικείμενα που θα υποστηρίζουν το αντίστοιχο σενάριο, αντιστοιχίζοντας το κάθε αντικείμενο σε μια από τις τρεις κατηγορίες που αναφέρθηκαν. Στη συνέχεια δείχνουμε τον τρόπο με τον οποίο εντοπίστηκαν τα αντικείμενα της εφαρμογής χρησιμοποιώντας ενδεικτικά δύο περιπτώσεις χρήσης. Στην περίπτωση χρήσης “Front position reached” με actor τον Feeder, το σύστημα ενημερώνεται ότι ο Feeder έφτασε στη μπροστινή θέση τερματισμού και σε απάντηση, του στέλνει το μήνυμα να σταματήσει και κατόπιν να κινηθεί προς τα πίσω. Για την αναπαράσταση της διεπαφής του φυσικού αντικειμένου Feeder , με την οποία επικοινωνεί με την εφαρμογή ελέγχου, διακρίναμε ένα interface object, το Feeder. Επιπλέον, χρειαζόμαστε ένα entity object, το οποίο θα κρατάει και θα διαχειρίζεται πληροφορία σχετικά με την κατάσταση του Feeder. Για το λόγο αυτό διακρίναμε το entity object FeederSR (FeederSoftwareRepresentation). Στην περίπτωση που ο Feeder φτάνει στην μπροστινή θέση τερματισμού, το σύστημα του στέλνει απευθείας το μήνυμα να κινηθεί προς τα πίσω, χωρίς να χρειάζεται επικοινωνία με κάποια άλλη μονάδα. Για το λόγο αυτό, διακρίναμε ένα control object, το οποίο ενσωματώνει τη λογική ελέγχου για τα μηνύματα που αντιστοιχούν σε βρόχους που κλείνουν τοπικά με τον Feeder, το FeederController. (Σχήμα 3.3)

Σχήμα 3.3 Τύποι αντικειμένων για την περίπτωση χρήσης “Front position reached” και οι μεταξύ τους συσχετίσεις.

Στην περίπτωση χρήσης «Back position reached» με actor τον Feeder, το σύστημα ενημερώνεται ότι o Feeder έφτασε στην πίσω θέση τερματισμού και το σύστημα του στέλνει το μήνυμα να σταματήσει. Δεν μπορεί ωστόσο να του στείλει το μήνυμα να κινηθεί προς τα εμπρός γιατί τίθεται θέμα συγχρονισμού με τον Converter, πρέπει δηλαδή πρώτα να εξασφαλιστεί ότι είναι ελεύθερη η θέση Α (position A). Συνεπώς, θα πρέπει να υπάρχει ένα control object το οποίο θα χειρίζεται θέματα συγχρονισμού στο εσωτερικό της υπομονάδας διανομής (Distribution Unit), δηλαδή το συγχρονισμό του Feeder και του Converter. Έχοντας υιοθετήσει κεντρικοποιημένο έλεγχο για την ανάπτυξη της εφαρμογής, αναθέτουμε το έργο αυτό στο control object DistributionUnitController. (Σχήμα 3.4)

Σχήμα 3.4 Τύποι αντικειμένων για την περίπτωση χρήσης “Back position reached”

50

Για την αποθήκευση και διαχείριση πληροφορίας σχετικά με την κατάσταση των μηχανικών μερών του πραγματικού συστήματος, αναθέσαμε στην κάθε μονάδα ένα entity object. Έτσι, καταγράφηκαν τα εξής entity objects: FeederSR, ConverterSR, ElevatorSR, ShiftOutCylinderSR, RotatingDiscSR, DrillingMachineSR, CheckingMachineSR και WarehouseCylinderSR. Επιπλέον, καταγράφηκε σαν έννοια από το πεδίο του προβλήματος το entity object WorkPiece. Στη μονάδα DetectionModule, η οποία αντιπροσωπεύει τους αισθητήρες που παρέχουν πληροφορία για τις ιδιότητες (χρώμα, υλικό και ύψος) του piece δεν αναθέσαμε κάποιο entity object, αλλά ο χειρισμός των μηνυμάτων αυτών γίνεται απευθείας από το control object DetectionModuleController. Για τον τοπικό έλεγχο της κάθε μονάδας, δηλαδή για μηνύματα τα οποία μπορούν να εξυπηρετηθούν από τη συγκεκριμένη μονάδα χωρίς να χρειάζεται επικοινωνία με κάποια άλλη, αναθέσαμε σε κάθε μονάδα ένα control object. Έτσι, καταγράφηκαν τα εξής control objects: FeederController, ConverterController, ElevatorController, DetectionModuleController, ShiftOutCylinderController, RotatingDiscController, DrillingMachineController, CheckingMachineController και WarehouseCylinderController. Η εφαρμογή αναπτύχθηκε έτσι ώστε το φυσικό σύστημα να μπορεί να χειρίζεται περισσότερα από ένα workPieces ταυτόχρονα. Συνεπώς τίθεται θέμα συγχρονισμού μεταξύ των μηχανικών μερών. Αυτό σημαίνει ότι για τη μεταφορά του workPiece στη θέση Α πρέπει να έχει εξασφαλιστεί ότι η θέση Α είναι ελεύθερη. Αντίστοιχα, για τη μεταφορά του workPiece από τη μονάδα διανομής στη μονάδα ελέγχου (δηλαδή από τη θέση Α στη θέση Β) πρέπει η θέση Β να είναι ελεύθερη. Τέλος, για τη μεταφορά του workPiece από τη μονάδα ελέγχου στη μονάδα επεξεργασίας, πρέπει η θέση 0 του περιστρεφόμενου δίσκου να είναι ελεύθερη. Δεδομένου ότι έχουμε επιλέξει να αναπτύξουμε την εφαρμογή με κεντρικοποιημένο έλεγχο (centralized control), αναθέσαμε τον έλεγχο (control logic) των υπομονάδων σε κάθε υποσύστημα σε ένα control object. Έτσι, προστέθηκαν τα εξής control objects: DistributionUnitController, TestingUnitController και ProcessingUnitController. Επιπλέον, η λογική ελέγχου των τριών υποσυστημάτων ανατέθηκε σε ένα γενικό controller, τον FestoMPSController. Τέλος, αναπαριστούμε τη διεπαφή των διαφόρων μονάδων με την εφαρμογή μέσα από τα interface objects Feeder, Converter, Elevator, DetectionModule, ShiftOutCylinder, RotatingDisc, DrillingMachine, CheckingMachine και WarehouseCylinderMachine. Τα αντικείμενα αυτά δεν αποτελούν μέρος της προς ανάπτυξη εφαρμογής, αλλά τα αναπαριστούμε για να δείξουμε την επικοινωνία της εφαρμογής με το πραγματικό σύστημα. Επιπλέον, καταγράφουμε το interface object Operator για την επικοινωνία της εφαρμογής με το χειριστή του συστήματος. Με βάση τα παραπάνω κατασκευάστηκε το ακόλουθο διάγραμμα κλάσεων (Σχήμα 3.5):

51

Σχήμα 3.5 Διάγραμμα κλάσεων Στη φάση αυτή δεν ασχοληθήκαμε με την καταγραφή των λειτουργιών των αντικειμένων, αλλά αναπαραστήσαμε μια πιο αφαιρετική και σταθερή τη δομή του συστήματος.

52

3.3 Σχεδιασμός του συστήματος Η φάση του σχεδιασμού ενός συστήματος περιλαμβάνει τη δημιουργία οδηγιών για τη συγεκριμένη υλοποίηση των προδιαγραφών που ορίστηκαν στη φάση της ανάλυσης, στα πλαίσια του περιβάλλοντος υλοποίησης. Η φάση αυτή περιλαμβάνει προσδιορισμό των επιμέρους τμημάτων (module decomposition), ορισμό των δομών δεδομένων, ορισμό της δομής των αρχείων και περιγραφή των κυριοτέρων αλγορίθμων. Συνήθως διακρίνεται σε αρχιτεκτονικό σχεδιασμό (architectural design) και σε αναλυτικό σχεδιασμό (detail design). [13] Κατά τη φάση του σχεδιασμού της εφαρμογής ελέγχου, χρησιμοποιήσαμε ως είσοδο το μοντέλο απαιτήσεων και το μοντέλο ανάλυσης που κατασκευάσαμε στην προηγούμενη φάση προκειμένου να παραγάγουμε ένα μοντέλο σχεδιασμού, το οποίο θα ανταποκρίνεται στις λειτουργικές απαιτήσεις που ορίστηκαν στο μοντέλο απαιτήσεων, και το οποίο θα υλοποιεί στα πλαίσια του συγκεκεριμένου περιβάλλοντος υλοποίησης τη λογική δομή της εφαρμογής που ορίστηκε στο μοντέλο ανάλυσης. Στην παρούσα εργασία επειδή το πραγματικό σύστημα δεν είναι διαθέσιμο, η εφαρμογή ελέγχου επικοινωνεί με μια εφαρμογή εξομοίωσης του φυσικού συστήματος, η οποία περιγράφεται στη συνέχεια. Αρχικά, μελετήσαμε τη δυναμική συμπεριφορά του συστήματος, στη συνέχεια εξετάσαμε την επικοινωνία της εφαρμογής με τον εξομοιωτή του φυσικού συστήματος, και τέλος κατασκευάσαμε την λεπτομερή αρχιτεκτονική δομή της εφαρμογής.

3.3.1 Μοντελοποίηση της δυναμικής συμπεριφοράς Για τη μοντελοποίηση της δυναμικής συμπεριφοράς του συστήματος μελετήσαμε τον τρόπο με τον οποίο αλληλεπιδρούν τα αντικείμενα του συστήματος καθώς και τον τρόπο με τον οποίο συμπεριφέρεται το κάθε αντικείμενο ξεχωριστά. Προκειμένου να αναπαραστήσουμε τον τρόπο με τον οποίο αλληλεπιδρούν τα αντικείμενα μεταξύ τους, κατασκευάσαμε για κάθε περίπτωση χρήσης ένα διάγραμμα ακολουθίας. Το διάγραμμα ακολουθίας δείχνει την χρονική ακολουθία των μηνυμάτων που ανταλλάσσουν τα αντικείμενα στα πλαίσια μιας περίπτωσης χρήσης. Για να διερευνήσουμε τις αλληλεπιδράσεις μεταξύ των αντικειμένων θεωρήσαμε σαν αρχικό σχεδιασμό της δομής του συστήματος την απευθείας αντιστοίχιση κάθε αντικειμένου του μοντέλου ανάλυσης σε ένα αντικείμενο του μοντέλου σχεδιασμού. Η δομή αυτή τώρα εμπλουτίζεται με τις λειτουργίες των αντικειμένων οι οποίες εντοπίζονται κατά τη διερεύνηση των διαφόρων σεναρίων χρήσης. Στα διαγράμματα ακολουθίας περιγράφουμε την αλληλεπίδραση των στιγμιοτύπων των αντικειμένων στα σενάρια χρήσης. Για το λόγο αυτό, ακολουθείται η σημειολογία για τη δήλωση στιγμιοτύπου, η οποία είναι InstanceName : ClassName.

53

Στη συνέχεια ακολουθούν ενδεικτικά κάποια από τα διαγράμματα ακολουθίας που κατασκευάστηκαν. Στο Σχήμα 3.6 φαίνεται το διάγραμμα ακολουθίας για την περίπτωση χρήσης “Start system”. Ο χειριστής στέλνει το μήνυμα “start” στον FestoMPSController, ο οποίος το μεταβιβάζει στον DistributionUnitController. Ο DistributionUnitController με τη σειρά του το μεταβιβάζει στον FeederController, ο οποίος στέλνει το μήνυμα “moveForward” στο FeederSR, με αποτέλεσμα να σταλεί τελικά στον Feeder το μήνυμα να κινηθεί προς τα εμπρός.

Σχήμα 3.6 Διάγραμμα ακολουθίας για την περίπτωση χρήσης “Start System” Στο Σχήμα 3.7 παρακάτω φαίνεται το διάγραμμα ακολουθίας για την περίπτωση χρήσης “frontPositionReached”.

54

Σχήμα 3.7 Διάγραμμα ακολουθίας για την περίπτωση χρήσης “Front position reached” Στο Σχήμα 3.8 φαίνεται το διάγραμμα ακολουθίας για την περίπτωση χρήσης “backPositionReached”.

Σχήμα 3.8 Διάγραμμα ακολουθίας για την περίπτωση χρήσης “Back position reached”

55

Στο Σχήμα 3.9 φαίνεται το διάγραμμα ακολουθίας για την περίπτωση χρήσης “elevatorUp”. Όταν ο ElevatorSR λάβει το μήνυμα ότι ο Elevator έφτασε στην πάνω θέση τερματισμού, του στέλνει το μήνυμα να σταματήσει και ενημερώνει τον ElevatorController με το μήνυμα “elevatorUp”. O ElevatorController καλεί τη μέθοδο “checkHeight” για τον έλεχο του ύψους του piece και σε περίπτωση που δεν είναι αποδεκτό στέλνει στο ElevatorSR το μήνυμα “moveDown”, το οποίο θα στείλει στον Elevator το μήνυμα να κινηθεί προς τα κάτω. Αν το ύψος είναι αποδεκτό ενημερώνει τον TestingUnitController, o οποίος μεταβιβάζει το μήνυμα στον FestoMPSController. O FestoMPSController στέλνει το μήνυμα “movePiece” στον ProcessingUnitController, ο οποίος θα αναλάβει να μεταφέρει το piece στη μονάδα επεξεργασίας.

Σχήμα 3.9 Διάγραμμα ακολουθίας για την περίπτωση χρήσης “Elevator Up” Στο Σχήμα 3.10 φαίνεται το διάγραμμα ακολουθίας για την περίπτωση χρήσης “checkingCylinderDown”.

56

Σχήμα 3.10 Διάγραμμα ακολουθίας για την περίπτωση χρήσης “Checking cylinder down” Σημειώνεται ότι το μήνυμα “stop” προς τα διάφορα units, αν και κανονικά είναι αρμοδιότητα του control αντικειμένου το οποίο ελέγχει το κάθε unit να το στείλει, λόγω της κρισιμότητας του συγκεκριμένου μηνύματος, αποφασίσαμε να στέλνεται απευθείας από το αντίστοιχο SR (SoftwareRepresentation) αντικείμενο. Για τη μοντελοποίηση της δυναμικής συμπεριφοράς του αντικειμένου κατασκευάζονται επίσης διαγράμματα συνεργασίας και δραστηριότητας, ωστόσο στο συγκεκριμένο σύστημα δεν έχουν να προσθέσουν κάποια ιδιαίτερα σημαντική πληροφορία και δεν κρίθηκε σκόπιμο να κατασκευαστούν. Έχοντας καταγράψει τον τρόπο με τον οποίο αλληλεπιδρούν τα αντικείμενα μεταξύ τους, προχωρήσαμε με τη μελέτη της δυναμικής συμπεριφοράς των αντικειμένων μεμονωμένα. Για το σκοπό αυτό κατασκευάστηκαν διαγράμματα καταστάσεων των αντικειμένων. Το διάγραμμα καταστάσεων, όπως έχει αναφερθεί στο Κεφάλαιο 2 χρησιμοποιείται για την περιγραφή της ροής του ελέγχου σε ένα σύστημα εστιάζοντας στις αλλαγές κατάστασης που λαμβάνουν χώρα σε ένα αντικείμενο. Σκοπός του διαγράμματος είναι να απεικονίζει τα μηνύματα τα οποία μπορεί να δεχθεί ένα αντικείμενο και το πώς το αντικείμενο αποκρίνεται σε αυτά τα μηνύματα, βοηθώντας στην κατανόηση του αντικειμένου.

Στο Σχήμα 3.11 παρουσιάζεται το διαγράμματα καταστάσεων για τα αντικείμενο FeederSR. Η αρχική κατάσταση του FeederSR είναι η backPosition. Από την κατάσταση αυτή όταν δεχθεί το μήνυμα “moveForward” στέλνει στον Feeder το μήνυμα “moveForward” και μεταβαίνει στην κατάσταση MovingForward. Από την

57

κατάσταση αυτή φεύγει μόνο όταν δεχθεί το μήνυμα “frontPositionReached”, οπότε στέλνει στον FeederController το μήνυμα “ frontPositionReached ” και στον Feeder το μήνυμα “stop” και μεταβαίνει στην κατάσταση FrontPosition. Αντίστοιχα και για τις υπόλοιπες καταστάσεις.

Σχήμα 3.11 Διάγραμμα καταστάσεων για το αντικείμενο FeederSR

Στο Σχήμα 3.12 παρουσιάζεται το διαγράμματα καταστάσεων για τα αντικείμενο DrillingMachineSR. Τα δύο επάνω διαγράμματα δείχνουν τον τρόπο με τον οποίο μεταβάλλεται η κατάσταση της θέσης και η κατάσταση vakuumed του αντικειμένου αντίστοιχα. Κάτω φαίνεται το συνδυασμένο διάγραμμα καταστάσεων για την πλήρη περιγραφή της δυναμικής συμπεριφοράς του αντικειμένου. Για απλοποίηση, έχουν παραλειφθεί τα μηνύματα που στέλνει το αντικείμενο κατά την είσοδο του σε μια νέα κατάσταση.

58

Σχήμα 3.12 Διάγραμμα καταστάσεων για το αντικείμενο DrillingMachineSR

3.3.2 Μοντελοποίηση του υποσυστήματος επικοινωνίας της εφαρμογής με τον εξομοιωτή του φυσικού συστήματος

Η επικοινωνία της εφαρμογής με την εφαρμογή εξομοίωσης γίνεται μέσω δικτύου με τη χρήση των Java TCP Sockets. [14] Για την επικοινωνία της εφαρμογής με τους αισθητήρες χρησιμοποιήσαμε την κλάση SensorListener, η οποία διαβάζει από το socket τα μηνύματα που στέλνουν οι αισθητήρες και ενημερώνει το αντίστοιχο SR αντικείμενο στο οποίο απεθύνεται το μήνυμα. Για την επικοινωνία της εφαρμογής με τους ενεργοποιητές χρησιμοποιήσαμε την κλάση OutSocket, η οποία δέχεται τα μηνύματα που απευθύνονται στους ενεργοποιητές από τα SR αντικείμενα της εφαρμογής και τα γράφει σε ένα δεύτερο socket στο οποίο συνδέονται οι ενεργοποιητές. Στο παρακάτω σχήμα φαίνεται το διάγραμμα κλάσεων του υποσυστήματος επικοινωνίας με την εφαρμογή εξομοίωσης. (Σχήμα 3.13)

59

Σχήμα 3.13 Διάγραμμα κλάσεων του υποσυστήματος επικοινωνίας με την εφαρμογή εξομοίωσης

3.3.3 Μοντελοποίηση της αρχιτεκτονικής δομής Έχοντας καταγράψει τις βασικές λειτουργίες των αντικειμένων, όπως προέκυψαν από τη μελέτη της δυναμικής συμπεριφοράς του συστήματος, προχωρήσαμε σε μια πιο αναλυτική σχεδίαση της δομής του, λαμβάνοντας υπόψιν το περιβάλλον υλοποίησης. Σκοπός είναι να κατασκευάσουμε τη δομή με τέτοια λεπτομέρεια ώστε να είναι άμεσα υλοποιήσιμη σε κώδικα. Οι τροποποιήσεις στη λογική δομή του συστήματος που οφείλονται στο περιβάλλον υλοποίησης αφορούν πρώτον στη διεπαφή της εφαρμογής με το περιβάλλον εξομοίωσης και δεύτερον, στην ανάγκη συγχρονισμού μεταξύ των μηχανικών μερών του συστήματος. Η επιλογή των ενεργών (active) κλάσεων, έγινε έτσι ώστε να καλυφθούν όλες οι ανάγκες ταυτοχρονισμού στο σύστημα με το μικρότερο δυνατό αριθμό νημάτων, λόγω του overhead που αυτά θέτουν. Η κλάση SensorListener, η οποία διαβάζει συνεχώς τα μηνύματα των αισθητήρων είναι ενεργό αντικείμενο. Ενεργά

60

αντικείμενα είναι επιπλέον οι SR κλάσεις, όπου μέσα από το δικό τους νήμα εκτέλεσης τρέχουν οι μέθοδοι των αντίστοιχων Controllers. Η κλάση DetectionModuleController, δεδομένου ότι δεν έχουμε δημιουργήσει αντίστοιχο SR αντικείμενο, έχει το δικό της νήμα εκτέλεσης. Επιπλέον, ενεργές είναι οι κλάσεις των τριών Controllers, DistributionUnitController, TestingUnitController και ProcessingUnitController, οι οποίοι πρέπει να λειτουργούν ταυτόχρονα για να συγχρονίζουν τις μονάδες στα πλαίσια του κάθε υποσυστήματος, καθώς και ο FestoMPSController για τον συγχρονισμό των τριών υποσυστημάτων. Για τον συγχρονισμό μεταξύ των νημάτων χρησιμοποιήσαμε την κλάση Monitor, η οποία αναπαριστά ένα monitor αντικείμενο. Για την ενημέρωση των SR αντικειμένων για τα μηνύματα των αισθητήρων αναθέσαμε σε κάθε SR αντικείμενο ένα monitor αντικείμενο, από το οποίο θα διαβάζει τα μηνύματα τα οποία θα γράφει η κλάση SensorListener. Επιπλέον, οι DistributionUnitController, TestingUnitController και ProcessingUnitController λαμβάνουν τα μηνύματα που στέλνουν οι υφιστάμενοι Controllers μέσω ενός monitor που ανατέθηκε στον καθένα. Αντίστοιχα, ανατέθηκε ένα monitor στον FestoMPSController για να λαμβάνει τα μηνύματα που αφορούν στο συγχρονισμό των τριών υποσυστημάτων. Στην παρακάτω εικόνα φαίνεται το πλήρες διάγραμμα κλάσεων της εφαρμογής ελέγχου (Σχήμα 3.14).

61

Σχήμα 3.14 Πλήρες διάγραμμα κλάσεων της εφαρμογής ελέγχου

62

Κεφάλαιο 4

Υλοποίηση του συστήματος Στη φάση της υλοποίησης χρησιμοποιήσαμε σαν βάση το μοντέλο σχεδιασμού προκειμένου να παράγουμε τον κώδικα της εφαρμογής. Η εφαρμογή υλοποιήθηκε σε Java κώδικα στο περιβάλλον του Eclipse. Το εργαλείο StarUml που χρησιμοποιήσαμε, δέχεται ως είσοδο από το μοντέλο σχεδιασμού μόνο το διάγραμμα κλάσεων του μοντέλου και παράγει stub code, τον οποίο σε αυτή τη φάση εμπλουτίσαμε με τα σώματα των μεθόδων. Η υλοποίηση έγινε έτσι ώστε να συμβαδίζει με τη δυναμική συμπεριφορά του συστήματος, όπως αυτή ορίστηκε μέσα από τα διαγράμματα ακολουθίας και τα διαγράμματα καταστάσεων στο μοντέλο σχεδιασμού. 4.1 Υλοποίηση του υποσυστήματος επικοινωνίας της

εφαρμογής ελέγχου με την εφαρμογή εξομοίωσης Η επικοινωνία της εφαρμογής με τους αισθητήρες και τους ενεργοποιητές υλοποιήθηκε μέσω των κλάσεων SensorListener και OutSocket αντίστοιχα, χρησιμοποιώντας την κατασκευή του Socket. Το πακέτο java.net της Java platform περιλαμβάνει τις κλάσεις Socket και ServerSocket που παρέχουν την ανεξαρτήτως συστήματος υλοποίηση της πλευράς του πελάτη και του εξυπηρετητή αντίστοιχα. Στη συγκεκριμένη υλοποίηση θεωρούμε ότι όλοι οι αισθητήρες γράφουν πάνω στο ίδιο port, από το οποίο διαβάζει η κλάση SensorListener. Ομοίως, όλοι οι ενεργοποιητές ενημερώνονται από το ίδιο port, στο οποίο γράφει η κλάση OutSocket. Η κλάση SensorListener αναπαριστά το ρόλο του Server στην επικοινωνία της εφαρμογής με τους αισθητήρες. Η SensorListener, η οποία διαθέτει το δικό της νήμα εκτέλεσης, διαβάζει τα μηνύματα των αισθητήρων και ενημερώνει το αντίστοιχο αντικείμενο της εφαρμογής. Αρχικά καλεί τη μέθοδο “closeConnection” με την οποία κλείνει κάποια σύνδεση που ενδεχομένως είναι ανοιχτή από προηγούμενη φορά. Στη συνέχεια, η μέθοδος “startServer” δημιουργεί ένα αντικείμενο ServerSocket το οποίο συνδέεται πάνω στο port, το οποίο ορίστηκε ως παράμετρος στο δημιουργό της κλάσης. Έπειτα καλείται η μέθοδος “connect”, στην οποία η SensorListener περιμένει έως ότου δεχθεί κάποια αίτηση σύνδεσης. Μετά την επιτυχή αποκατάσταση της σύνδεσης η μέθοδος “accept” επιστρέφει ένα νέο αντικείμενο Socket, το clientSocket, πάνω από το οποίο γίνεται η επικοινωνία.

63

Επιλέον, ορίζεται το στιγμιότυπο inBR το οποίο δέχεται τα ορίσματα από τον Client, δηλαδή από τους αισθητήρες. Στη συνέχεια, ακολουθεί ένας επαναληπτικός βρόχος στον οποίο, κάθε φορά που γράφεται κάτι στο socket η SensorListener το διαβάζει με τη μέθοδο “readLine”, το συγκρίνει με όλα τα μηνύματα των αισθητήρων και στέλνει το μήνυμα στο Monitor του αντικειμένου στο οποίο απευθύνεται. Ακολουθεί η υλοποίηση της κλάσης SensorListener. public class SensorListener extends Thread { private static ServerSocket serverSocket = null; private static Socket clientSocket = null; private static BufferedReader inBR; private static InputStreamReader inISR; private static InputStream inIS; private static String inputLine; private static String outputLine; private Monitor feederM,converterM; private int port; public SensorListener(int port){ this.port=port; } public void run() { System.out.println("\nListening on port "+port+"...\n"); do { try { try {

closeConnection(); } catch(Exception e) { } StartServer(); Connect(); do { if((inputLine = inBR.readLine()) == null) { break; } if(inputLine.equals("feeder.backPos")) feederM.sendCommand("backPos"); if(inputLine.equals("feeder.frontPos")) feederM.sendCommand("frontPos"); if(inputLine.equals("converter.rightStop")) converterM.sendCommand("rightStop");

/**** ελέγχονται σειριακά όλα τα μηνύματα των αισθητήρων****/

if(inputLine.equals("die")) { System.exit(0); } } while(true); closeConnection();

64

} catch(Exception e) { System.out.println("Error:\n"+e.toString()); } } while(true); } private void StartServer() { try { serverSocket = new ServerSocket(port); } catch(IOException e) {

System.out.println("Could not listen on port: "+port+"\n"+e.toString());

System.exit(-1); } } private void Connect() { try { clientSocket = serverSocket.accept(); } catch(IOException e) { System.err.println("Accept failed."); System.exit(1); } try { inIS = clientSocket.getInputStream(); inISR = new InputStreamReader(inIS); inBR = new BufferedReader(inISR); } catch(IOException e) {

System.out.println("Connection failed.\n"+e.toString()); System.exit(1); } } public static void closeConnection() { try{

inBR.close(); clientSocket.close(); serverSocket.close(); } catch(IOException e){ System.out.println("CloseConnection failed.\n"); System.exit(1); } } }

65

Υλοποίηση της κλάσης SensorListener Για την επικοινωνία της κλάσης SensorListener με τα SR αντικείμενα έχουμε αναθέσει σε κάθε SR αντικείμενο ένα αντικείμενο monitor έτσι ώστε το κάθε νήμα της κλάσης SR να αφυπνίζεται όταν υπάρχει μήνυμα που απευθύνονται σε αυτό, αποφεύγοντας το busy waiting. Η υλοποίηση της κλάσης Monitor δίνεται παρακάτω: public class Monitor { private boolean empty=true; private String command; public synchronized String getCommand(){ while(empty){ try{wait();} catch(InterruptedException e){} } empty=true; return command; } public synchronized void sendCommand(String command){ this.command=command; empty=false; notify(); } } Υλοποίηση της κλάσης Monitor Η κλάση OutSocket αναπαριστά το ρόλο του Client στην επικοινωνία της εφαρμογής με τους ενεργοποιητές. Δέχεται τα μηνύματα που παράγονται από την εφαρμογή για τον έλεγχο του συστήματος και τα στέλνει στους ενεργοποιητές. H μέθοδος “connect” δημιουργεί ένα αντικείμενο Socket το οποίο κάνει μια αίτηση σύνδεσης στον ίδιο υπολογιστή (στον οποίο τρέχει η εφαρμογή εξομοίωσης) με το όνομα “localhost” στο port του αντικειμένου ServerSocket στο οποίο θα ακούει η αντίστοιχη κλάση της εφαρμογής εξομοίωσης. Μετά την επιτυχή αποκατάσταση της σύνδεσης δημιουργεί ένα στιγμιότυπο out, το οποίο στέλνει τα ορίσματα στον Server. Η εντολή γράφεται στο αντικείμενο out που συνδέεται στο socket με τη μέθοδο “sendCommand”. Παρακάτω δίνεται η υλοποίηση της κλάσης OutSocket: public class OutSocket{ Socket echoSocket; PrintWriter out; int port; public OutSocket(int port) { echoSocket = null; out = null; this.port = port;

66

connect(port); } void sendCommand(String command) { if(out != null) { out.print(command); out.flush();

System.out.println(command+" Sent to Port: "+Integer.toString(port));

} else {

System.out.println(command+" NOT sent to Port: "+Integer.toString(port));

} } void connect(int port) { try { echoSocket = new Socket("localhost", port); out = new PrintWriter(echoSocket.getOutputStream(), true);

System.out.println(Integer.toString(port)+" Connected!");

} catch(UnknownHostException e) {

System.out.println("Don't know about host: loopback"); } catch(IOException e){} } void disConnect() { try { out.close(); echoSocket.close(); } catch(Exception e) { } } } Υλοποίηση της κλάσης OutSocket 4.2 Υλοποίηση του υποσυστήματος ελέγχου της

μονάδας διανομής Στο υποσύστημα ελέγχου της μονάδας διανομής ανήκουν οι κλάσεις FeederSR, ConverterSR, FeederController, ConverterController και DistributionUnitController.

67

Το νήμα της κλάσης FeederSR ενημερώνεται μέσω του monitor feederM για τα μηνύματα των αισθητήρων του Feeder. Όταν λάβει το μήνυμα ότι ενεργοποιήθηκε κάποιος από τους αισθητήρες του Feeder για την μπροστινή ή την πίσω θέση τερματισμού στέλνει στο Feeder, μέσω του στιγμιοτύπου outSocket, το μήνυμα να σταματήσει. Κατόπιν, ενημερώνει την κατάσταση της και μεταβιβάζει το μήνυμα στον FeederController ώστε να το χειριστεί κατάλληλα. Επιπλέον, η κλάση FeederSR δέχεται από τον FeederController τα μηνύματα ελέγχου του Feeder, moveForward και moveBackward. Σε απόκριση στα μηνύματα αυτά, γράφει τα μηνύματα στο outSocket για την αποστολή τους στους ενεργοποιητές και ενημερώνει την κατάσταση της. Τέλος, με τη μέθοδο getStatus επιστρέφει την κατάσταση του αντικειμένου. Αντίστοιχα υλοποιείται και η κλάση ConverterSR. Η υλοποίηση της κλάσης FeederSR δίνεται παρακάτω: public class FeederSR extends Thread{ private boolean backPos,frontPos,movingBackward,

movingForward=false; private String command; public void run(){ while(true){ command=feederM.getCommand(); if(command.equals("frontPos")){ outSocket.sendCommand("feeder.stop\n"); frontPos=true; movingForward=false; feederController.frontPosReached(); } if(command.equals("backPos")){ outSocket.sendCommand("feeder.stop\n"); backPos=true; movingBackward=false; feederController.backPosReached(); } } } public void moveBackward(){ FestoControlApplic.outSocket.sendCommand("feeder.moveB\n"); movingBackward=true; frontPos=false; } public void moveForward(){ FestoControlApplic.outSocket.sendCommand("feeder.moveF\n"); movingForward=true; backPos=false; } public String getStatus(){ String status=new String("feeder status: "); if(backPos) status=status.concat("backPos"); if(frontPos)

68

status=status.concat("frontPos"); if(movingBackward) status=status.concat("movingBackward"); if(movingForward) status=status.concat("movingForward"); return status; } } Υλοποίηση της κλάσης FeederSR Η κλάση FeederController δέχεται από την κλάση FeederSR τα μηνύματα των αισθητήρων backPosReached και frontPosReached και από την DistUnitController το μήνυμα movePiece. Όταν ο FeederController λάβει το μήνυμα ότι ο Feeder έφτασε στην μπροστινή θέση τερματισμού, του στέλνει απευθείας το μήνυμα να κινηθεί προς τα πίσω, ενώ όταν λάβει το μήνυμα ότι έφτασε στην πίσω θέση ενημερώνει τον distUnitController γράφοντας το μήνυμα “feederAtBackPos” στο monitor distUnitControllerM. Ο distributionUnitController όταν πληρούνται οι κατάλληλες προϋποθέσεις θα αναλάβει να του στείλει το μήνυμα movePiece, με το οποίο αποστέλλεται στον Feeder το μήνυμα να κινηθεί εμπρός. Αντίστοιχα υλοποιείται η κλάση ConverterController. Παρακάτω δίνεται η υλοποίηση της κλάσης FeederController: public class FeederController { public void backPosReached(){

distUnitControllerM.sendCommand("feederAtBac kPos");

} public void movePiece(){ feederSR.moveForward(); } public void frontPosReached(){ feederSR.moveBackward(); } } Υλοποίηση της κλάσης FeederController Το νήμα της κλάσης DistUnitController διαβάζει από το monitor distUnitControllerM τα μηνύματα από τον FeederController και τον ConverterController που αφορούν στο συγχρονισμό των δύο units “feederAtBackPos” και “posAFree”αντίστοιχα. Όταν ο Feeder βρίσκεται στην πίσω θέση και ταυτόχρονα η θέση Α είναι ελεύθερη, στέλνει στο FeederController το μήνυμα movePiece, με το οποίο ο Feeder θα κινηθεί προς τα εμπρός. O DistUnitController δέχεται επιπλέον από τον ConverterController τα μηνύματα convAtLeftStop και pieceInPosA, τα οποία δε μπορεί να χειριστεί ο ίδιος γιατί αφορούν στο συγχρονισμό με τη μονάδα ελέγχου. Για το λόγο αυτό, τα μεταβιβάζει στον FestoController γράφοντάς τα στο monitor festoControllerM. Τέλος, ο DistUnitController δέχεται από το FestoController τα μηνύματα

69

“movePieceInPosB” και “startFeeder”. Η μέθοδος movePieceInPosB καλείται από τον FestoController όταν εξασφαλιστεί ότι πληρούνται οι προϋποθέσεις για τη μεταφορά του κομματιού από τη μονάδα διανομής στη μονάδα ελέγχου, οπότε και αποστέλλεται στον ConverterController το μήνυμα “movePiece”, με αποτέλεσμα ο Converter να κινηθεί προς τα δεξιά. Τέλος, η μέθοδος “startFeeder” καλείται από τον FestoController, όταν ο χρήστης στείλει το μήνυμα εκκίνησης του συστήματος, οπότε και αποστέλλεται στον FeederController το μήνυμα “movePiece”. Η υλοποίηση της κλάσης DistUnitController δίνεται παρακάτω: public class DistUnitController extends Thread{ boolean feederAtBackPos=false; boolean posAFree=false; String command; public void run(){ while(true){ command=distUnitControllerM.getCommand(); if(command.equals("feederAtBackPos")){ feederAtBackPos=true; } if(command.equals("posAFree")){ posAFree=true; } if(feederAtBackPos && posAFree){ feederController.movePiece(); feederAtBackPos=false; posAFree=false; } } } public void movePieceInPosB(){ converterController.movePiece(); } public void convAtLeftStop(){ festoControllerM.sendCommand("convAtLeftStop"); } public void pieceInPosA(){ festoControllerM.sendCommand("pieceInPosA"); } public void startFeeder(){ feederController.movePiece(); } } Υλοποίηση της κλάσης DistUnitController

70

4.3 Υλοποίηση του υποσυστήματος ελέγχου της

μονάδας ελέγχου Στο υποσύστημα ελέγχου της μονάδας ελέγχου ανήκουν οι κλάσεις ElevatorSR, SOC_UpSR, SOC_DownSR, DetectionModuleController, ElevatorController, SOC_UpController, SOC_DownController, και TestingUnitController. Το νήμα της κλάσης ElevatorSR διαβάζει τα μηνύματα των αισθητήρων του Elevator μέσω του monitor elevatorM “elevatorUp” και “elevatorDown”. Όταν λάβει κάποιο από αυτά τα μηνύματα στέλνει στον Elevator το μήνυμα να σταματήσει γράφοντας στο outSocket το αντίστοιχο μήνυμα. Στη συνέχεια ενημερώνει την κατάσταση του και μεταβιβάζει το μήνυμα στον ElevatorController. Επιπλέον, η κλάση ElevatorSR δέχεται τα μηνύματα moveUp και move Down από τον ElevatorController, σε απόκριση των οποίων ενημερώνει την κατάστασή του και τα γράφει στο outSocket για να σταλούν στους ενεργοποιητές. Αντίστοιχα υλοποιούνται οι κλάσεις SOC_UpSR και SOC_DownSR. Η υλοποίηση της κλάσης ElevatorSR φαίνεται παρακάτω: public class ElevatorSR extends Thread{ private boolean upStop,downStop,movingUp,movingDown=false; private String command; public void run(){ while(true){ command=elevatorM.getCommand(); if(command.equals("elevatorUp")){ outSocket.sendCommand("elevator.stop\n"); upStop=true; movingUp=false; elevatorController.elevatorUp(); } if(command.equals("elevatorDown")){ outSocket.sendCommand("elevator.stop\n"); downStop=true; movingDown=false; elevatorController.elevatorDown(); } } } public void moveUp(){ outSocket.sendCommand("elevator.moveUp\n"); movingUp=true; downStop=false; } public void moveDown(){ outSocket.sendCommand("elevator.moveDown\n"); movingDown=true; upStop=false; } } Υλοποίηση της κλάσης ElevatorSR

71

Η κλάση DetectionModuleController ενημερώνεται από τους αισθητήρες για το χρώμα, το ύψος και το υλικό του piece μέσα από τις μεθόδους setColor και setHeight, οι οποίες καλούνται απευθείας από την SensorListener. Το νήμα αυτής της κλάσης διαβάζει το μήνυμα για την ύπαρξη piece στο position B από το monitor detectionModuleM. Όταν έρθει piece στη θέση αυτή ελέγχει το χρώμα και το υλικό του με τις μεθόδους checkColor και checkMaterial. Για απλούστευση έχουμε θεωρήσει το υλικό να είναι πάντα αποδεκτό και μη αποδεκτό χρώμα να είναι μόνο το μαύρο. Στη συνέχεια ενημερώνει τον TestingUnitController για το αν είναι αποδεκτό το piece γράφοντας το κατάλληλο μήνυμα στο monitor testingUnitControllerM. Επιπλέον, δέχεται το μήνυμα getHeight από τον testingUnitController και επιστρέφει το ύψος του piece. Η υλοποίηση της κλάσης DetectionModuleController φαίνεται παρακάτω: public class DetectionModuleController extends Thread { private boolean pieceInPosB; private String command; public String color; public int height; public void run(){ while(true){ command=detectionModuleM.getCommand(); if(command.equals("pieceInPosB")){

if(checkMaterial() && checkColor()){ testingUnitControllerM.sendCommand("vali

dPiece"); }

else testingUnitControllerM.sendCommand("invalidPiece");

} } } public boolean checkMaterial(){ return true; } public int getHeight(){ return height; } public boolean checkColor(){ if(color.equals("java.awt.Color[r=0,g=0,b=0]")) return false; else return true; } public void setColor(String color){ this.color=color; }

72

public void setHeight(int height){ this.height=height; } } Υλοποίηση της κλάσης DetectionModuleController Η κλάση ElevatorController δέχεται από την ElevatorSR τα μηνύματα “elevatorUp” και “elevatorDown”. Όταν λάβει το μήνυμα ότι ο Elevator έφτασε στη πάνω θέση ενημερώνεται για το ύψος του piece από τον testingUnitController, το ελέγχει και αν είναι αποδεκτό ενημερώνει τον testingUnitController, διαφορετικά στέλνει στον Elevator το μήνυμα να κινηθεί προς τα κάτω. Όταν λάβει το μήνυμα ότι ο Elevator έφτασε στην κάτω θέση ελέγχει αν υπάρχει μη αποδεκτό piece και σε περίπτωση που υπάρχει ενημερώνει τον testingUnitController έτσι ώστε να το απομακρύνει από τη μονάδα ελέγχου, διαφορετικά του στέλνει το μήνυμα ότι θέση είναι ελεύθερη. Τέλος, δέχεται τα μηνύματα movePieceUp και moveElevatorDown από τον testingUnitController για να μετακινήσει τον Elevator προς τα πάνω και προς τα κάτω αντίστοιχα. Η υλοποίηση της κλάσης ElevatorController φαίνεται παρακάτω: public class ElevatorController { private boolean heightValid; private int height; public void elevatorUp(){ height=testingUnitController.getHeight(); if(heightValid=checkHeight()) testingUnitController.heightValid(); else elevatorSR.moveDown(); } public void elevatorDown(){ if(!heightValid){ testingUnitControllerM.sendCommand("invalidPiece"); heightValid=true; } else testingUnitController.posBFree(); } public void movePieceUp(){ elevatorSR.moveUp(); } public boolean checkHeight(){ if(height!=20) return false; else return true; }

73

public void moveElevatorDown(){ elevatorSR.moveDown(); } } Υλοποίηση της κλάσης ElevatorController Το νήμα της κλάσης TestingUnitController διαβάζει από το monitor testingUnitControllerM τα μηνύματα που αφορούν στο συγχρονισμό μεταξύ των units αυτού του υποσυστήματος. Επιπλέον, δέχεται τα μηνύματα heightValid και pos0Free, τα οποία απαιτούν συγχρονισμό με μονάδα επεξεργασίας και τα μεταβιβάζει στον FestoController. Επιπλέον, δέχεται το μήνυμα movePieceInPos0 από τον FestoController, οπότε και στέλνει το μήνυμα στον ShiftOutCylinder να κινηθεί προς τα εμπρός. Τέλος, δέχεται το μήνυμα getHeight από τον ElevatorController, οπότε και στέλνει το αντίστοιχο μήνυμα στον DetectionModuleController. Η υλοποίηση της κλάσης TestingUnitController φαίνεται παρακάτω: public class TestingUnitController extends Thread{ String command; public void run(){ while(true){ command=testingUnitControllerM.getCommand(); if(command.equals("validPiece")){ elevatorController.movePieceUp(); } if(command.equals("invalidPiece")){ socDownController.moveInvalidPiece(); } if(command.equals("socUpAtBackPos")){ elevatorController.moveElevatorDown(); } } } public void heightValid(){ festoControllerM.sendCommand("heightValid"); } public void posBFree(){ festoControllerM.sendCommand("posBFree"); } public void movePieceInPos0(){ socUpController.movePiece(); } public int getHeight(){ return detectionModuleController.getHeight(); } }

74

Υλοποίηση της κλάσης TestingUnitController 4.4 Υλοποίηση του υποσυστήματος ελέγχου της

μονάδας επεξεργασίας Στο υποσύστημα ελέγχου της μονάδας επεξεργασίας ανήκουν οι κλάσεις RotatingDiscSR, DrillingMachineSR, CheckingMachineSR, WarehouseCylinderSR, RotatingDiscController, DrillingMachineController, CheckingMachineController, WarehouseCylinderController, και ProcessingUnitController. Το νήμα της κλάσης RotatingDiscSR διαβάζει τα μηνύματα των αισθητήρων μέσω του αντίστοιχου monitor. Όταν λάβει το μήνυμα για την ύπαρξη piece σε κάποια θέση αλλάζει την κατάσταση του και ενημερώνει τον RotatingDiscController, ενώ όταν λάβει το μήνυμα ότι έγινε μια περιστροφή του στέλνει επιπλέον το μήνυμα να σταματήσει. Επιπλέον, η κλάση RotatingDiscSR δέχεται από τον RotatingDiscController το μήνυμα “rotate”, σε απόκριση στο οποίο αλλάζει την κατάσταση του και στέλνει το στον RotatingDisc το μήνυμα να περιστραφεί. Η υλοποίηση της κλάσης RotatingDiscSR φαίνεται παρακάτω: public class RotatingDiscSR extends Thread{ private boolean rotating=false;

private boolean pieceInPos0, pieceInPos1, pieceInPos2, pieceInPos3=false;

private String command; public void run(){ while(true){ command=rotatingDiscM.getCommand(); if(command.equals("pieceInPos0")){ rotatingDiscController.pieceInPos0(); pieceInPos0=true; }

// ομοίως ελέγχονται τα μηνύματα και για τις υπόλοιπες θέσεις

if(command.equals("rotationDone")){ outSocket.sendCommand("rotating

Disc.stop\n"); rotating=false; rotatingDiscController.rotationDone(); } } } public void rotate(){ outSocket.sendCommand("rotatingDisc.rotate\n"); rotating=true; pieceInPos0=false; pieceInPos1=false; pieceInPos2=false; pieceInPos3=false; } }

75

Υλοποίηση της κλάσης RotatingDiscSR Η κλάση RotatingDiscController δέχεται τα μηνύματα για την ύπαρξη piece στις διάφορες θέσεις και τα μεταβιβάζει στον ProcessingUnitController. Επιπλέον, δέχεται το μήνυμα “rotationDone” από το RotatingDiscSR, οπότε και ενημερώνει τον ProcessingUnitController ότι η θέση 0 του δίσκου είναι ελεύθερη. Τέλος, δέχεται το μήνυμα “rotateDisc” από τον ProcessingUnitController και μεταβιβάζει το μήνυμα στο RotatingDiscSR. Η υλοποίηση της κλάσης RotatingDiscController δίνεται παρακάτω: public class RotatingDiscController { public void pieceInPos0(){ processingUnitControllerM.sendCommand("pieceInPos0"); } // αντίστοιχα και για τα pieceInPos1,2,3 public void rotationDone(){ processingUnitController.pos0Free(); } public void rotateDisc(){ rotatingDiscSR.rotate(); } } Υλοποίηση της κλάσης RotatingDiscController Το νήμα της κλάσης ProcessingUnitController διαβάζει από αντίστοιχο το monitor τα μηνύματα που αφορούν στο συγχρονισμό μεταξύ του RotatingDisc και των DrillingMachine, CheckingMachine και WarehouseCylinder. Σε περίπτωση που του έρθει μήνυμα για την ύπαρξη piece σε κάποια από τις θέσεις 1,2,3 ενημερώνει την κατάσταση του και στέλνει μήνυμα στον αντίστοιχο Controller για να αρχίσει η επεξεργασία του piece. Όταν του έρθει μήνυμα για την ύπαρξη piece στη θέση 0 ελέγχει αν οι υπόλοιπες θέσεις είναι κενές, και αν είναι στέλνει το μήνυμα στον RotatingDisc να περιστραφεί. Επιπλέον, όταν του έρθει το μήνυμα ότι τελείωσε η επεξεργασία σε κάποια θέση ενημερώνει την κατάσταση του και αν δεν εκκρεμεί επεξεργασία σε κάποια άλλη θέση στέλνει στο RotatingDisc το μήνυμα να περιστραφεί. Τέλος, ο ProcessingUnitController δέχεται επίσης το μήνυμα ότι η θέση 0 είναι ελεύθερη από τον RotatingDiscController και το μεταβιβάζει στον FestoController. Η υλοποίηση της κλάσης ProcessingUnitController φαίνεται παρακάτω: public class ProcessingUnitController extends Thread{

private boolean pieceInPos0, pieceInPos1, pieceInPos2, pieceInPos3=false;

private boolean drilling,checking,removingPiece=false; private String command; public void run(){ while(true){ command=processingUnitControllerM.getCommand(); if(command.equals("pieceInPos3")){

76

pieceInPos3=true; warehouseCylinderController.remove

Piece(); removingPiece=true; } if(command.equals("pieceInPos2")){ pieceInPos2=true;

checking=true; checkingMachineController.moveChecking

MachineDown(); } if(command.equals("pieceInPos1")){ pieceInPos1=true; drilling=true; drillingMachineController.moveLifting

CylinderDown(); } if(command.equals("pieceInPos0")){ pieceInPos0=true; festoController.resetPos0();

if((!pieceInPos1) && (!pieceInPos2) && (!pieceInPos3)){ rotatingDiscController.rotate

Disc(); } } if(command.equals("drillingDone")){ drilling=false; if(!checking && !removingPiece){ rotate(); } } if(command.equals("checkingDone")){ checking=false; if(!drilling && !removingPiece){ rotate(); } } if(command.equals("pieceRemoved")){ removingPiece=false; if(!checking && !drilling){ rotate(); } } } } public void rotate(){ rotatingDiscController.rotateDisc(); pieceInPos3=false; pieceInPos2=false; pieceInPos1=false; } public void pos0Free(){ festoControllerM.sendCommand("pos0Free"); } } Υλοποίηση της κλάσης ProcessingUnitController

77

4.5 Υλοποίηση του ελέγχου των υποσυστημάτων

διανομής, ελέγχου και επεξεργασίας Ο συγχρονισμός των τριών υποσυστημάτων πραγματοποιείται από την κλάση FestoController. Προκειμένου να μεταφερθεί το piece στη μονάδα ελέγχου στη θέση Β θα πρέπει ο Converter να βρίσκεται στην αριστερή θέση, να υπάρχει piece στη θέση Α και η θέση Β να είναι κενή. Για το λόγο αυτό δέχεται τα μηνύματα “posBFree”, “converterAtLeftStop” και “pieceInPosA”. Όταν δεχθεί κάποιο από αυτά τα μηνύματα ενημερώνει την κατάσταση του και σε περίπτωση που ισχύουν και τα τρία στέλνει στον DistributionUnitController το μήνυμα “movePieceInPosB”. Για τη μεταφορά του piece από τη μονάδα ελέγχου στη μονάδα επεξεργασίας θα πρέπει το piece να έχει αποδεκτό ύψος και η θέση 0 του περιστρεφόμενου δίσκου να είναι ελεύθερη. Αντίστοιχα, ο συγχρονισμός επιτυγχάνεται με τα μηνύματα “heightValid” και “pos0Free”. Επιπλέον, ο FestoController δέχεται το μήνυμα “resetPos0” από τον ProcessingUnitController όταν έρθει piece στη θέση 0, προκειμένου να ενημερώσει την κατάσταση του. Τέλος, δέχεται το μήνυμα “startSystem” από το χρήστη, με το οποίο στέλνει στον DistributionUnitController το μήνυμα να μετακινήσει τον Feeder προς τα εμπρός. Η υλοποίηση της κλάσης FestoController φαίνεται παρακάτω: public class FestoController extends Thread{ private String command; boolean posBFree=true; boolean convAtLeftStop=true; boolean pieceInPosA=false; private boolean pos0Free=true; boolean heightValid=false; public void run(){ while(true){ command=festoControllerM.getCommand(); if(command.equals("heightValid")){ heightValid=true; if(pos0Free){ heightValid=false; pos0Free=false; testingUnitController.move

PieceInPos0(); } } if(command.equals("posBFree")){ posBFree=true; } if(command.equals("convAtLeftStop")){ convAtLeftStop=true; } if(command.equals("pieceInPosA")){ pieceInPosA=true; } if(command.equals("pos0Free")){ pos0Free=true; if(heightValid){

78

pos0Free=false; heightValid=false; testingUnitController.move

PieceInPos0(); } } if(posBFree && convAtLeftStop && pieceInPosA){ distUnitController.movePieceInPosB(); posBFree=false; convAtLeftStop=false; pieceInPosA=false; } } } public void startSystem(){ distUnitController.startFeeder(); } public void resetPos0(){ pos0Free=false; } } Υλοποίηση της κλάσης FestoController

79

80

Κεφάλαιο 5

Εξομοίωση του συστήματος Προκειμένου να ελεγθεί η ορθότητα της εφαρμογής ελέγχου που κατασκεύαστηκε, και δεδομένου ότι το πραγματικό σύστημα δεν είναι διαθέσιμο κατασκευάστηκε εφαρμογή για την εξομοίωση της λειτουργίας του μηχανικού συστήματος Festo MPS. (Σχήμα 5.1)

Σχήμα 5.1 Το σύστημα Festo MPS

81

Η εφαρμογή εξομοίωσης επικοινωνεί με την εφαρμογή ελέγχου πάνω από sockets. Συγκεκριμένα, δέχεται τα μηνύματα που απευθύνονται στους ενεργοποιητές στη θύρα 8258 και στέλνει τα μηνύματα που παράγουν οι αισθητήρες στη θύρα 8259. Η κατασκευή της γραφικής διεπαφής βασίστηκε στον Simulator του Festo MPS που αναπτύχθηκε από τον φοιτητή Νικόλαο Παπακωνσταντίνου [15]. Η γραφική διεπαφή του προγράμματος εξομοίωσης φαίνεται στο παρακάτω σχήμα (Σχήμα 5.2) :

Σχήμα 5.2 Ο Festo MPS Simulator Για την επικοινωνία της εφαρμογής με την εφαρμογή ελέγχου χρησιμοποιήθηκαν οι κλάσεις ActuatorListener και OutSocket. Η κλάση ActuatorListener έχει το ρόλο του Server στην επικοινωνία της εφαρμογής ελέγχου με τους ενεργοποιητές. Διαβάζει από το socket τα μηνύματα που στέλνει η εφαρμογή προς τους ενεργοποιητές και ενημερώνει το αντίστοιχο unit μέσω του monitor αντικειμένου UnitMonitor. Η υλοποίηση της ActuatorListener είναι αντίστοιχη με αυτή της κλάσης SensorListener της εφαρμογής ελέγχου. Η κλάση OutSocket, η οποία έχει το ρόλο του Client, γράφει τα μηνύματα των αισθητήρων στο socket στο οποίο συνδέεται η κλάση SensorListener της εφαρμογής ελέγχου. Η υλοποίηση της κλάσης OutSocket είναι αντίστοιχη με αυτή που χρησιμοποιήθηκε στην εφαρμογή ελέγχου. Για την αναπαράσταση των μηχανικών μερών του φυσικού συστήματος χρησιμοποιήθηκαν τα αντικείμενα Feeder, Converter, Elevator, SOC_Up, SOC_Down, Belt, RotatingDisc, DrillingMachine, CheckingMachine και WarehouseCylinder. Τα αντικείμενα αυτά ενημερώνονται από το αντίστοιχο monitor που έχει ανατεθεί στο καθένα για τα μηνύματα που στέλνει η εφαρμογή,

82

μεταβάλλουν την κατάσταση τους αντίστοιχα με το πραγματικό αντικείμενο και παράγουν τα μηνύματα των αισθητήρων, τα οποία στέλνουν στην κλάση OutSocket. Η κοινή λειτουργικότητα αυτών των αντικειμένων τοποθετήθηκε στην Interface κλάση Unit, την οποία και υλοποιούν. Το διάγραμμα κλάσεων της εφαρμογής εξομοίωσης φαίνεται στο παρακάτω σχήμα (Σχήμα 5.3):

83

Σχήμα 5.3 Το διάγραμμα κλάσεων της εφαρμογής εξομοίωσης

84

Η υλοποίηση της γραφικής διεπαφής έγινε με την κλάση SimGui, η οποία φαίνεται παρακάτω: public class SimGui extends Frame { Image offscreenImage; Graphics offscreenGraph; Dimension frameDim; Insets frameInsets; public SimGui(String title) { super(title); addWindowListener(new WindowAdapter() { public void windowClosing(WindowEvent evt){ dispose(); System.exit(0); } }); setSize(600, 400); setResizable(false);

DimensionscreenDim=Toolkit.getDefaultToolkit().getScreenSize(); frameDim = getSize();

setLocation((screenDim.width - frameDim.width) / 2, (screenDim.height - frameDim.height) / 2);

setVisible(true); } public void update(Graphics g){ offscreenGraph.setColor(getBackground());

offscreenGraph.fillRect(0, 0, frameDim.width, frameDim.height);

offscreenGraph.setColor(Color.black); ..... } catch(Exception e){ System.out.println("*"); } super.paint(g); g.drawImage(offscreenImage, 0, 0, this); } public void paint(Graphics g) { update(g); } public void addNotify() { super.addNotify();

offscreenImage = createImage(frameDim.width, frameDim.height);

85

offscreenGraph = offscreenImage.getGraphics(); frameInsets = getInsets(); } } Η κλάση SimGui Για την αναπαράσταση του κομματιού χρησιμοποιήσαμε την κλάση WorkPiece, η οποία είναι τύπου Component και γίνεται add στην SimGui. Για την αναπαράσταση της στοίβας των κομματιών χρησιμοποιήσαμε την κλάση PieceStack. Η κλάση αυτή αποτελείται από έναν πίνακα αντικειμένων τύπου WorkPiece με διαφορετικές ιδιότητες το καθένα. Διαθέτει τη μέθοδο nextPiece , η οποία παρέχει με κυκλική σειρά το επόμενο κομμάτι στο σύστημα. Οι κλάσεις PieceStack και WorkPiece φαίνονται παρακάτω. public class PieceStack { private WorkPiece pieces[]; private int i=-1; public PieceStack(){ pieces=new WorkPiece[10]; pieces[0]=new WorkPiece(Color.RED,0,0,20,20); pieces[1]=new WorkPiece(Color.BLUE,0,0,20,20); pieces[2]=new WorkPiece(Color.YELLOW,0,0,20,20); pieces[3]=new WorkPiece(Color.RED,0,0,20,20); pieces[4]=new WorkPiece(Color.ORANGE,0,0,20,20); pieces[5]=new WorkPiece(Color.RED,0,0,20,19); pieces[6]=new WorkPiece(Color.BLUE,0,0,20,20); pieces[7]=new WorkPiece(Color.YELLOW,0,0,20,20); pieces[8]=new WorkPiece(Color.BLACK,0,0,20,20); pieces[9]=new WorkPiece(Color.ORANGE,0,0,20,20); } public WorkPiece nextPiece(){ i++; i=i % 10; pieces[i].setVisible(true); return pieces[i]; } } Η κλάση PieceStack public class WorkPiece extends Component{ public int xCoord; public int yCoord; public int width; public int height; public Color color; public String name; public WorkPiece(Color color, int xCoord, int yCoord,

int width, int height){ super(); this.name=name; this.xCoord = xCoord;

86

this.yCoord = yCoord; this.width = width; this.height = height; this.color = color; this.setLocation(xCoord, yCoord); this.setSize(width, height); this.setForeground(color); this.setVisible(true); addNotify(); simGui.add(this); } public void paint(Graphics g){ simGui.offscreenGraph.setColor(color);

simGui.offscreenGraph.fillRect(xCoord, yCoord, width, height);

} } Η κλάση WorkPiece Για τη γραφική αναπαράσταση της κάθε μονάδας χρησιμοποιήθηκε η κλάση UnitGui, της οποίας η υλοποίηση φαίνεται παρακάτω. public class UnitGui extends Component { int xCoord; int yCoord; int width; int height; Color color; String shape;

public UnitGui(Color color, int xCoord, int yCoord, int width, int height, String shape){

super(); this.xCoord = xCoord; this.yCoord = yCoord; this.width = width; this.height = height; this.color = color; this.shape=shape; this.setLocation(xCoord, yCoord); this.setSize(width, height); this.setForeground(color); this.setVisible(true); addNotify(); simGui.add(this); } public void paint(Graphics g){ simGui.offscreenGraph.setColor(color);

if(shape.equals("Rect")) simGui.offscreenGraph.fillRect(xCoord, ξ yCoord,width,height);

if(shape.equals("Oval")) simGui.offscreenGraph.fillOval(xCoord, yCoord, width, height);

} } Η κλάση UnitGui

87

Το αντικείμενο Feeder αναπαριστά το αντίστοιχο φυσικό αντικείμενο. Διαθέτει τη μεταβλητή speed που αναπαριστά το χαρακτηριστικό του φυσικού αντικειμένου και τη μεταβλητή unitGui, που αναπαριστά τη γραφική διεπαφή του. Κατά τη δημιουργία του, το στιγμιότυπο της κλάσης Feeder υιοθετεί ένα piece από τη στοίβα με τη μέθοδο “setPiece”. Το νήμα της κλάσης Feeder διαβάζει από το monitor feederM τα μηνύματα που στέλνει η εφαρμογή. Όταν λάβει το μήνυμα “moveF” προχωράει τον Feeder μαζί με το piece του προς τα δεξιά και στέλνει το μήνυμα “set” στο monitor screenPainterM έτσι ώστε το αντικείμενο ScreenPainter να κάνει update τη γραφική διεπαφή. Με τη μέθοδο “runFrontPosSensor” ελέγχει αν έχει φτάσει στην μπροστινή θέση. Όταν φτάσει στην μπροστινή θέση γράφει στο outSocket το αντίστοιχο μήνυμα για την ενημέρωση της εφαρμογής ελέγχου. Επιπλέον, καλεί τη μέθοδο “setPiece” του Converter για να του δώσει το piece, ελευθερώνει το δικό του piece και στέλνει στο outSocket το μήνυμα για την ύπαρξη piece στη θέση Α. Το μήνυμα “stop”, λόγω της κρισιμότητας του δεν το διαβάζει από το monitor αλλά του το στέλνει απευθείας η κλάση ActuatorListener, η οποία αλλάζει την μεταβλητή command την οποία ελέγχει καθώς κινείται μποστά. public class Feeder extends Thread implements Unit{ String name; int speed; UnitGui unitGui; WorkPiece piece; private String command; public Feeder(String name, Color color, int xCoord, int yCoord, int width, int height, int speed){ this.name =name; this.speed = speed;

unitGui = new UnitGui(color, xCoord, yCoord, width, height,"Rect");

setPiece(pieceStack.nextPiece()); } public void run(){ while(true){ command=feederM.getCommand(); while(command.equals("moveF")){ if(piece!=null){ if(unitGui.xCoord!=90){ unitGui.xCoord++; piece.xCoord++; screenPainterM.set(); runFrontPosSensor(); try{ Thread.sleep(speed); }

catch(InterruptedException ie){ }

} else command="stop"; } }

88

while(command.equals("moveB")){ if(unitGui.xCoord!=10){ unitGui.xCoord--; screenPainterM.set(); runBackPosSensor(); try { Thread.sleep(speed); } catch(InterruptedException ie) { } } else command="stop"; } } } public void runFrontPosSensor(){ if(unitGui.xCoord==80){ outSocket.sendCommand("feeder.frontPos\n"); try{ for(int i = 1; i <= 10; i++){ piece.xCoord++; screenPainterM.set(); Thread.sleep(speed); }

converter.setPiece(piece); outSocket.sendCommand("converter. pieceInPosA\n");

piece=null; } catch(InterruptedException e) { } } } public void runBackPosSensor(){ if(unitGui.xCoord==20 ){ outSocket.sendCommand("feeder.backPos\n"); setPiece(pieceStack.nextPiece()); } } public void stopUnit(){ command="stop"; } public void setPiece(WorkPiece piece){ this.piece=piece; piece.xCoord=60; piece.yCoord=270; } } Η κλάση Feeder Αντίστοιχα υλοποιούνται και οι υπόλοιπες κλάσεις που αναπαριστούν τα μηχανικά μέρη του φυσικού συστήματος.

89

90

Συμπεράσματα Στην παρούσα εργασία χρησιμοποιήθηκε η UML για την ανάλυση και το σχεδιασμό της εφαρμογής ελέγχου του συστήματος Festo MPS. Η αφαιρετικότητα που παρέχει η μοντελοποίηση με τη UML βοήθησε σε μεγάλο βαθμό στη διαχείριση της πολυπλοκότητας του συγκεκριμένου συστήματος με δομημένο τρόπο. Το CASE tool StarUML που χρησιμοποιήθηκε για τη μοντελοποίηση του συστήματος δεν παρείχε μεγάλο ποσοστό αυτόματα παραγόμενου κώδικα. Το εργαλείο δεχόταν ως είσοδο μόνο το διάγραμμα κλάσεων του μοντέλου σχεδιασμού και παρήγαγε stub code χωρίς να ενσωματώνει σε αυτόν τη λειτουργικότητα που ορίσαμε στα διαγράμματα ακολουθίας και τα διαγράμματα καταστάεων. Για την υλοποίηση της εφαρμογής χρησιμοποιήθηκε το περιβάλλον του Eclipse, όπου με βάση το μοντέλο σχεδιασμού πραγματοποιήσαμε τη συγγραφή του σώματος των μεθόδων. Ωστόσο, επειδή το StarUML δεν υποστηρίζει τον συγχρονισμό μεταξύ μοντέλου και κώδικα, χρειάστηκε να τροποποιήσουμε εμείς το μοντέλο για οποιαδήποτε αλλαγή πραγματοποιήσαμε στη φάση της υλοποίησης. Οι δυσκολίες που αντιμετωπίστηκαν κατά την ανάπτυξη της εφαρμογής ελέγχου αφορούν στο συγχρονισμό ανάμεσα στα μηχανικά μέρη του φυσικού συστήματος, ιδιαίτερα στο εσωτερικό της μονάδας επεξεργασίας, όπου έπρεπε να ληφθούν αρκετοί παράγοντες υπόψιν για τη σωστή λειτουργία του συγκεκριμένου υποσυστήματος. Κατά την ανάπτυξη του συστήματος δε λήφθηκαν υπόψη ζητήματα πραγματικού χρόνου, τα οποία εισάγει το φυσικό σύστημα. Συνεπώς, παραπέρα δουλειά πάνω στο συγκεκριμένο σύστημα θα ήταν η ανάπτυξη του συστήματος χρησιμοποιώντας κάποιο UML profile, για την αναπαράσταση των χαρακτηριστικών και περιορισμών που έχουν να κάνουν με τα ζητήματα πραγματικού χρόνου, και συνέχεια η υλοποίηση της εφαρμογής ελέγχου σε real-time Java.

91

92

Αναφορές [1] Μπογιατζή Ε., “Using IEC61499 in control and automation: The FESTO

MPS case study” Διπλωματική εργασία, Απρίλιος 2006 [2] Booch G., Rumbaugh J. and Jacobson I., The Unified Modeling Language

User Guide, Addison Wesley, Boston, MA, 1999 [3] Eriksson Ε., Penker Μ., UML Toolkit, John Wiley. [4] Χατζηγεωργίου Α., Αντικειμενοστρεφής Σχεδίαση, Κλειδάριθμος 2005 [5] Wuyts R, UML: History and Overview

http://www.ulb.ac.be/di/rwuhttp://www.ulb.ac.be/di/rwuyts/INFO025_2 004/04-UML-Overview.pdfyts/INFO025_2004/

[6] Γερογιάννης Β., Κακαρόντζας Γ., Καμέας Α., Σταμέλος Γ., Φιτσιλής Π.,

Αντικειμενοστρεφής Ανάπτυξη Λογισμικού με τη UML, Κλειδάριθμος 2006

[7] J. Warmer, A. Kleppe, The Object Constraint Language: Precise Modeling

with UML, Object Technology Series, Addison-Wesley, 1999. [8] Chen R., Sgro1 M., Lavagno L., Martin G., Sangiovanni-Vincentelli A.,

Rabaey J., UML and Platform-based Design, IEEE Computer Society 2002

[9] B. Selic, “A Generic Framework for Modeling Resources with UML”, IEEE Computer, June 2000

[10] Mellor S. “From UML to embedded system: Is it possible?” http://www.eetimes.com/esc/showArticle.jhtml?articleID=184417422

[11] StarUML The Open Source UML/MDA platform

http://staruml.sourceforge.net/en/ [12] Ivar Jacobson, Object-Oriented Software Engineering: A Use Case Driven

Approach, Addison Wesley 1992 [13] Θραμπουλίδης Κ., Ανάλυση και Σχεδιασμός Συστημάτων Λογισμικού,

Εκδόσεις Πανεπιστημίου Πατρών 2007 [14] The Java Tutorials: All about sockets

http://java.sun.com/docs/books/tutorial/networking/sockets/ [15] Παπακωνσταντίνου Ν., “Η χρήση της Γλώσσας Προγραμματισμού Java

στην Ανάπτυξη Ενσωματωμένων Συστημάτων: Μελέτη Περίπτωσης στην Τσιμεντοβιομηχανία ΤΙΤΑΝ Α.Ε. ” Διπλωματική εργασία