Μοντελοκεντρική Ανάπτυξη Ενσωματωμένων Συστημάτων

Μοντελοκεντρική Ανάπτυξη Ενσωματωμένων Συστημάτων ΔΟΥΜΠΙΩΤΟΥ ΣΤΥΛΙΑΝΗ ΚΑΝΔΑΛΗΣ ΣΤΑΜΑΤΗΣ Επιβλέπων καθηγητής: Γεώργιος Χασάπης ΘΕΣΣΑΛΟΝΙΚΗ 2013

2

ΠΕΡΙΛΗΨΗ Αντικείμενο της διπλωματικής αυτής είναι η μοντελοποίηση ενσωματωμένων συστημάτων ενός αυτοκινήτου που χαρακτηρίζεται ως αυτοκίνητο του μέλλοντος λόγω των πρωτότυπων και έξυπνων εφαρμογών που αυτά τα συστήματα υλοποιούν. Η παρουσίαση των μοντελοποιημένων συστημάτων γίνεται μέσω του eclipse και πιο συγκεκριμένα του Papyrus plug-in που κρίνεται ως το καταλληλότερο μετά από έρευνα, το οποίο τελικά προστίθεται πάνω στο eclipse για να εξυπηρετήσει τον σκοπό του. Η γλώσσα που χρησιμοποιεί το plug-in αυτό είναι η SysML, βασισμένη στο πρότυπο της UML και εξειδικευμένη για τέτοια ηλεκτρονικά συστήματα. Παρουσιάζεται η γλώσσα αυτή με έναν σύντομο οδηγό χρήσης, ώστε να γίνει κατανοητή και από άτομα που δεν την έχουν χρησιμοποιήσει ξανά. Το κυρίως παράδειγμα δείχνει συστήματα του αμαξιού, όπως οι έξυπνοι υαλοκαθαριστήρες ή το σύστημα ελέγχου ταχύτητας, τα οποία παρουσιάζονται με τα κατάλληλα διαγράμματα που τα ορίζουν από όλες τις πλευρές. Ειδομένα μέσα από αυτή τη μοντελοποίηση και μέσω κάποιων σεναρίων αποδεικνύεται η ορθότητά τους και γίνονται η αφετηρία για κάποια τελικά συμπεράσματα. Η διπλωματική αυτή εργασία χωρίζεται σε πέντε κεφάλαια. Στο πρώτο κεφάλαιο υπάρχει η εισαγωγή όπου θέτονται οι στόχοι και ορίζονται οι πρωταρχικές βασικές έννοιες. Το δεύτερο κεφάλαιο παρουσιάζει όσα βασικά εργαλεία προέκυψαν από την έρευνα για να επιλεγεί το κατάλληλο plug-in και καταλήγει σε εκείνο που επιλέγεται τελικά. Έπειτα στο τρίτο κεφάλαιο δίνεται ένα σύντομο εγχειρίδιο χρήσης της γλώσσας SysML, η οποία και θα χρησιμοποιηθεί στη μοντελοποίηση. Το κυρίως παράδειγμα υπάρχει στο τέταρτο κεφάλαιο μαζί με όλα τα διαγράμματα που δομούν και μοντελοποιούν τα όποια συστήματα υπάρχουν, καθώς και κάποια σενάρια χρήσης. Τέλος, στο πέμπτο κεφάλαιο υπάρχουν τα γενικά συμπεράσματα που προκύπτουν απ όλη αυτή τη διαδικασία. 3

Περιεχόμενα 1. Εισαγωγή -6-1.1 Ενσωματωμένα Συστήματα: Βασικές έννοιες -7-1.2 Μοντελοποίηση και UML -9-1.2.1 Ιστορία -10-1.2.2 Διαγράμματα UML -11-2. Η βασική έρευνα -14-2.1 BPMN2 Modeler -17-2.1.1Service-Oriented Architecture (SOA) -17-2.1.2 Ανάλυση του BPMN2 Modeler -20-2.2 SDO / CDO -23-2.3 MDT/UML2-25- 2.4 Papyrus -26-2.4.1 EMF (Eclipse Modeling Framework) -26-3. Εισαγωγή στη SysML -28-3.1 Ιστορική Αναδρομή -28-3.2 Δομή της SysML και σύγκριση με τη UML -30-4

3.2.1 Διάγραμμα Απαιτήσεων -33-3.2.2 Διάγραμμα Καθορισμού Τμημάτων -35-3.2.3 Διάγραμμα Εσωτερικών τμημάτων -37-3.2.4 Διάγραμμα Παραμέτρων -37-3.2.5 Διάγραμμα Δραστηριοτήτων -38-3.2.6 Διάγραμμα Περιπτώσεων Χρήσης -40-3.2.7 Διάγραμμα Ακολουθίας -41-3.2.8 Διάγραμμα Κατάστασης / Διάγραμμα Πακέτων -43-3.2.9 Διαφορές SysML και UML -43-3.3 Συμπεράσματα SysML -44-4. Το κυρίως παράδειγμα -45-4.1 Σύστημα μείωσης ταχύτητας σε περίπτωση που το οδόστρωμα είναι βρεγμένο -50-4.2 Σύστημα επιβολής ορίου ταχύτητας -54-4.3 Σύστημα δεδομένων κυκλοφορίας -59-4.4 Υποθετικά σενάρια -63-5. Συμπεράσματα -67-5

1.Εισαγωγή Στόχος της παρούσας διατριβής αποτελεί η μοντελοποίηση ενσωματωμένων συστημάτων, τα οποία είναι υπεύθυνα για κάποιες έξυπνες λειτουργίες, όπως για παράδειγμα θα υπήρχαν αυτές σε ένα αυτοκίνητου του μέλλοντος. Για να γίνει όμως αυτή η μοντελοποίηση θα πρέπει να προηγηθεί μια σχετική έρευνα για το πιο πρόγραμμα θα μπορούσε να το κάνει αυτό. Συγκεκριμένα αποφασίστηκε να χρησιμοποιηθεί το πρόγραμμα του eclipse που είναι επεκτάσιμο με διάφορους τρόπους. Άρα έμενε να ερευνηθούν κάποια από τα plug-ins του για να φανεί πιο είναι κατάλληλο για την δουλεία που έχει τεθεί ως στόχος, δηλαδή να μην προσφέρει απλά μοντελοποίηση, αλλά να προσφέρει μοντελοποίηση ηλεκτρονικών τμημάτων και πιο συγκεκριμένα ενσωματωμένων συστημάτων. Εφόσον επιλεχθεί και γίνει σαφές μέσω των βασικών του στοιχείων το plug-in που θα χρησιμοποιηθεί, το επόμενο βήμα είναι η μοντελοποίηση αυτών των στοιχείων που εμπεριέχονται στα «έξυπνα» αυτά ενσωματωμένα συστήματα με ένα σύνολο διαγραμμάτων. Το σύνολο αυτό θα τα ορίζει πλήρως και θα κάνει κατανοητή τη δομή τους και τις αλληλοσυνδέσεις τους σε κάποιον που τις βλέπει με κάποιες τεχνικές γνώσεις πάνω στο κομμάτι αυτό. Τέλος, θα δοθούν κάποια σενάρια χρήσης γενικότερα που περιέχουν λίγο από όλα αυτά τα έξυπνα συστήματα, δηλαδή το αμάξι σαν σύνολο με έμφαση σε αυτά τα χαρακτηριστικά που μοντελοποιήθηκαν ώστε να φανεί πως μπορεί να ερμηνευτεί η συμπεριφορά του αμαξιού μέσω των διαγραμμάτων. Έτσι θα γίνει ξεκάθαρη η ορθότητα των υποσυστημάτων αλλά και γενικότερα του αυτοκινήτου του μέλλοντος σαν ιδέα και επιπλέον θα οδηγηθούμε με μια φυσική ροή στα συμπεράσματα στο τέλος της διατριβής. Πριν όμως ξεκινήσουμε με όλα αυτά θα ήταν χρήσιμο να ορίσουμε τις δύο βασικές έννοιες που υπάρχουν στον τίτλο της παρούσας διατριβής και τις οποίες ήδη αναφέρθηκαν στην παραπάνω εισαγωγή και θα αναφέρονται συχνά πυκνά σε όλες τις ενότητες που ακολουθούν. Οι έννοιες αυτές είναι η έννοια των ενσωματωμένων συστημάτων αλλά και η έννοια της μοντελοποίησης. 6

1.1 Ενσωματωμένα Συστήματα: Βασικές έννοιες Ενσωματωμένα συστήματα ονομάζουμε τα ηλεκτρονικά συστήματα τα οποία ελέγχονται από έναν ή περισσότερους μικροεπεξεργαστές ή επεξεργαστές ψηφιακού σήματος και συνήθως ενσωματώνονται ηλεκτρονικά και μηχανικά μέρη σε μια συσκευή. Βασικό τους χαρακτηριστικό είναι ότι χειρίζονται αποκλειστικά μια συγκεκριμένη εργασία, σε αντίθεση με τους υπολογιστές γενικού σκοπού που ικανοποιούν μια μεγάλη ποικιλία αναγκών του χρήστη. Πολύ συχνά αποτελούν μέρος ενός μεγαλύτερου συστήματος, όπως για παράδειγμα σε ένα αυτοκίνητο τα υποσυστήματα ABS, ελέγχου κατανάλωσης και διάφορα άλλα μέρη του. Ουσιαστικά σχεδόν όλες οι ηλεκτρονικές συσκευές που κατασκευάζονται σήμερα είναι ενσωματωμένα συστήματα, από ψηφιακά ρολόγια μέχρι συστήματα ελέγχου εργοστασίων. Υπολογίζεται ότι το 2008 κατασκευάστηκαν περίπου 10 δις. επεξεργαστές και το 98% χρησιμοποιήθηκε για ενσωματωμένα συστήματα. Οι επεξεργαστές των ενσωματωμένων συστημάτων και οι αρχιτεκτονικές ποικίλουν, από 4-bit επεξεργαστές σε 128-bit εξειδικευμένους επεξεργαστές ψηφιακών σημάτων. Οι συσκευές αυτές μπορεί να τρέχουν από ένα μικρό πρόγραμμα σε γλώσσα μηχανής από μια ROM χωρίς λειτουργικό σύστημα (γνωστό ως firmware) έως και ένα λειτουργικό σύστημα πραγματικού χρόνου σε διάφορες εκδόσεις των Windows ή Linux. Γενικά υπάρχει μια μεγάλη ποικιλία και κάποια δυσκολία στον αυστηρό ορισμό των ενσωματωμένων συστημάτων, καθώς υπάρχουν συστήματα αυξημένης πολυπλοκότητας που περιλαμβάνουν πολλαπλές μονάδες, περιφερειακά ή και δίκτυα. Τέλος, είναι βασικό να σημειωθεί πως επειδή τα ενσωματωμένα συστήματα είναι ειδικού σκοπού και απαιτούν λίγους υπολογιστικούς πόρους, βελτιστοποιούνται ώστε να μειωθεί το μέγεθος και το κόστος και να αυξηθεί η αξιοπιστία τους και η απόδοση. Η διεπαφή με το χρήστη ποικίλει: πολλές φορές δεν είναι καθόλου απαραίτητη, άλλοτε περιορίζεται σε μερικά κουμπιά, λυχνίες LED και LCD οθόνες ή μερικές φορές έχουν γραφική διεπαφή που θυμίζει προσωπικούς υπολογιστές. Για να γίνει πιο εύκολη αντιληπτή η εικόνα ενός ενσωματωμένου συστήματος μπορούμε να περιγράψουμε μία συνηθισμένη δομή, το λεγόμενο SoC (system on a chip) σύστημα, όπου όλα τα στοιχεία του συστήματος ολοκληρώνονται σε ένα και μόνο chip. Ένα SoC εμπεριέχει τόσο το απαιτούμενο για την εφαρμογή hardware όσο 7

και το software που ελέγχει τον μικροεπεξεργαστή, τα περιφερειακά και τα διάφορα interfaces. Το απαιτούμενο αυτό hardware πιο αναλυτικά περιλαμβάνει έναν τουλάχιστον μικροελεγκτή, διάφορα blocks μνήμης, κάποιες περιφερειακές μονάδες, στοιχεία για χρονισμό του κυκλώματος, buses για τη διασύνδεση των παραπάνω στοιχείων καθώς και διάφορα εξωτερικά interfaces όπως τα πρότυπα USB ή UART. Με τον κατάλληλο προγραμματισμό μπορεί να γίνει έλεγχος σωστής λειτουργίας και debugging τόσο για το hardware όσο και για το software και μάλιστα πολύ κοντά στην πραγματική ταχύτητα λειτουργίας του συστήματος. Γενικά πάντως ο σχεδιασμός ενός SoC έχει ως στόχο την παράλληλη ανάπτυξη του υλικού και του λογισμικού. Ένα βασικό στοιχείο της διαδικασίας σχεδίασης ενός SoC είναι η προσομοίωσή του μέσω της οποίας ελέγχεται η σωστή και απρόσκοπτη λειτουργία του συστήματος. Για να συμβεί αυτό, το hardware «χαρτογραφείται» πάνω σε μία πλατφόρμα προσομοίωσης η οποία βασίζεται στη φιλοσοφία των FPGA (Field Programmable Gate Array) ενώ το software φορτώνεται στα blocks μνήμης που υπάρχουν στην εν λόγω πλατφόρμα. Παρακάτω ακολουθεί μια εικόνα ενός ενσωματωμένου συστήματος και της λογικής του. Εικόνα 1: FPGA ενσωματωμένο σύστημα σε μια γενική ματιά για το πώς είναι ένα βασικό ενσωματωμένο σύστημα 8

1.2 Μοντελοποίηση και UML Μοντελοποίηση ονομάζεται γενικά η διαδικασία κατά την οποία γίνεται δημιουργία αντικειμένων τα οποία συλλαμβάνουν τη συμπεριφορά συστημάτων. Ένα μοντέλο επιτρέπει τη διεξαγωγή συμπερασμάτων για τη συμπεριφορά του συστήματος στο οποίο αντιστοιχεί και μας δίνει όλα τα απαραίτητα στοιχεία που περιέχει το σύστημα σε μία πιο εύκολη και πιο απλουστευμένη ματιά. Η μοντελοποίηση συστημάτων συνήθως συνεπάγεται τη διαδικασία της απόσπασης (abstraction), δηλαδή, της απλοποίησης της περιγραφής ενός συστήματος διατηρώντας μόνο ένα περιορισμένο αριθμό από τις αρχικές λεπτομέρειες. Η απόσπαση (abstraction) μπορεί να καταστεί αναγκαία λόγω είτε της πολυπλοκότητας των διαφόρων συστημάτων που επιλέγουμε προς μοντελοποίηση, είτε γιατί οι αυστηρές μέθοδοι δεν μπορούν να εφαρμοστούν σε φυσικές οντότητες (π.χ. μνήμη του υπολογιστή) και έτσι οι σχετικές ιδιότητές τους πρέπει να αποσπαστούν μαθηματικά. Με άλλα λόγια ένα μοντέλο είναι µια απλοποίηση της πραγματικότητας και επιτυγχάνονται τα εξής: Η οπτικοποίηση του συστήματος όπως είναι ή όπως θα θέλαμε να είναι. Ο καθορισμός της δομής και της συμπεριφοράς του συστήματος. Η δημιουργία ενός προτύπου που µας καθοδηγεί στην κατασκευή του συστήματος. Τονίζεται επιπλέον ότι το μοντέλο ενός συστήματος μπορεί να κατασκευαστεί και να μελετηθεί πριν ή παράλληλα με τον σχεδιασμό και την υλοποίησή του και γίνεται εμφανές ότι με το κατάλληλο λογισμικό μπορεί να γίνει και η αντίστοιχη μοντελοποίηση διαφόρων ενσωματωμένων υπολογιστικών και μη συστημάτων. Στο γνωστικό πεδίο της μηχανικής λογισμικού γλώσσες μοντελοποίησης λογισμικού ονομάζονταιτυποποιημένες γλώσσες οπτικής συμβολικής αναπαράστασης με τις οποίες κατασκευάζονται αφαιρετικά μοντέλα της δομής και της λειτουργίας ενός συστήματος λογισμικού. Η ευρύτερα διαδεδομένη τέτοια γλώσσα είναι η Unified Modeling Language.H Unified Modeling Language (UML) είναι μια γλώσσα που χρησιμοποιείται για προδιαγραφές, αναπαράσταση με οπτικό τρόπο 9

(visualizing), δημιουργία και τεκμηρίωση των τμημάτων των συστημάτων λογισμικού, καθώς και για μοντελοποίηση εταιρικών και άλλων συστημάτων που δεν αφορούν λογισμικό. Επίσης, η UML αποτελεί στην ουσία έναν συνδυασμό των καλύτερων πρακτικών, οι οποίες ήδη έχουν αποδείξει πόσο επιτυχημένες ήταν στη μοντελοποίηση μεγάλων και σύνθετων συστημάτων. Βασικό χαρακτηριστικό της είναι ότι αποτελεί μια γλώσσα μοντελοποίησης ανεξάρτητη από τις μεθοδολογίες που χρησιμοποιούνται κατά την ανάπτυξη συστημάτων λογισμικού. Επιπλέον, δεν πρόκειται μόνο για μια τυποποίηση και ανακάλυψη μιας κοινής σημειολογίας. Περιέχει νέες και ενδιαφέρουσες έννοιες που δεν υπάρχουν εν γένει στο πεδίο της αντικειμενοστραφούς ανάπτυξης, όπως για παράδειγμα η περιγραφή και χρησιμοποίηση προτύπων (patterns) σε μια γλώσσα μοντελοποίησης. Συνεπώς, η κατανόηση της UML δεν περιορίζεται στην εκμάθηση των συμβόλων και της σημασίας τους, αλλά εκτείνεται σε ευρύτερο πλαίσιο στη μάθηση της αντικειμενοστραφούς μοντελοποίησης. Η UML χρησιμοποιείται για τη μοντελοποίηση μεγάλου εύρους συστημάτων και ο βασικός στόχος της UML, όπως προκύπτει και από τα παραπάνω είναι να περιγράφει κάθε τύπο συστήματος, μέσα από αντικειμενοστραφή διαγράμματα. 1.2.1 Ιστορία Μεθοδολογίες ανάπτυξης λογισμικού για συμβατικές διαδικαστικές γλώσσες, όπως η Fortran, η Pascal και η C, εμφανίστηκαν τη δεκαετία του 1970 με σκοπό να αντιμετωπίσουν τη λεγόμενη «κρίση λογισμικού» (software crisis). Η πιο ευρέως διαδεδομένη μεθοδολογία ήταν η Δομημένη Ανάλυση και Σχεδίαση (Structured Analysis and Design) και αργότερα η Σύγχρονη Δομημένη Ανάλυση. Ως πρώτη αντικειμενοστραφής γλώσσα προγραμματισμού αναγνωρίζεται η Simula (1967), αλλά η ευρεία διάδοση της αντικειμενοστραφούς ανάπτυξης λογισμικού άρχισε στις αρχές της δεκαετίας του 1980 με γλώσσες όπως η Smalltalk, C++ και στη συνέχεια με τη Java. Στη συνέχεια δημοσιεύτηκαν και οι πρώτες μεθοδολογίες ανάπτυξης λογισμικού βασισμένες στο αντικειμενοστραφές μοντέλο, καταλήγοντας στις αρχές της δεκαετίας του 90 σε μια πληθώρα τεχνικών, ορισμών, συμβολισμών και ορολογίας. 10

Η πρώτη επιτυχής προσπάθεια ενοποίησης των διαφόρων μεθοδολογιών ξεκίνησε από την Rational Software Corporation το 1994 με επικεφαλής τους Grady Booch και James Rumbaugh. Στόχος τους ήταν η δημιουρία μιας νέας μεθόδου, της «Ενοποιημένης Μεθόδου», η οποία θα ένωνε τη μέθοδο του Booch και την ΟΜΤ-2 μέθοδο στην ανάπτυξη της οποίας επικεφαλής ήταν ο James Rumbaugh. Το 1995 ο Ivar Jacobson, ο άνθρωπος πίσω από τις μεθόδους OOSE και Objectory προστέθηκε στην ομάδα. Οι μελλοντικοί σχεδιαστές της UML συνειδητοποίησαν ότι η δουλειά τους δε στόχευε στη δημιουργία μιας πρότυπης μεθόδου, αλλά μιας πρότυπης γλώσσας μοντελοποίησης και μετονόμασαν τη δουλειά τους σε «Unified Modeling Language». Οι στόχοι της UML, όπως τέθηκαν από τους σχεδιαστές είναι οι εξής: Η μοντελοποίηση συστημάτων (όχι μόνο λογισμικού) χρησιμοποιώντας αντικειμενοστραφείς έννοιες. Η καθιέρωση μιας ρητής σύνδεσης σε εννοιολογικά καθώς και εκτελέσιμα κατασκευάσματα (artifacts). Η αντιμετώπιση θεμάτων κλίμακας, τα οποία είναι εγγενή σε σύνθετα, κρίσιμα συστήματα. Και τέλος, η δημιουργία μιας γλώσσας μοντελοποίησης χρησιμοποιήσιμης τόσο από ανθρώπους, όσο και από υπολογιστικές μηχανές. Το πρώτο πρότυπο της 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. 1.2.2 Διαγράμματα UML Η UML ορίζει τα παρακάτω διαγράμματα: Διάγραμμα περιπτώσεων χρήσης (use case diagram) Διαγράμματα δομής o o Διάγραμμα κλάσεων (class diagram) Διάγραμμα αντικειμένων (object diagram) Διαγράμματα συμπεριφοράς o Διάγραμμα καταστάσεων (statechart diagram) 11

o o Διάγραμμα δραστηριοτήτων (activity diagram) Διαγράμματα αλληλεπίδρασης Διάγραμμα ακολουθίας (sequence diagram) Διάγραμμα συνεργασίας (collaboration diagram) Διαγράμματα δομής υλοποίησης o o Διάγραμμα εξαρτημάτων (component diagram) Διάγραμμα ανάπτυξης (deployment diagram). Επιπλέον, να αναφερθεί ότι υπάρχουν διαφόρων ειδών συσχετίσεις μεταξύ των οντοτήτων, οι οποίες βέβαια χρησιμοποιούνται σε όλα τα ήδη διαγραμμάτων και θα τις αναφέρομαι τώρα καθώς είναι απαραίτητες για την πορεία και την παρουσίαση του βασικού μας παραδείγματος. Χρησιμοποιώντας αυτές τις συσχετίσεις ή αλλιώς εξαρτήσεις εκφράζουμε σημασιολογικές (semantic) σχέσεις ανάμεσα σε στοιχεία του μοντέλου. Σε τέτοιες περιπτώσεις μια αλλαγή σε ένα στοιχείο της εξάρτησης μπορεί να έχει επίπτωση στο άλλο. Διακρίνουμε τα παρακάτω είδη εξάρτησης: πρόσβαση (access): 'Άδεια σε κάποια στοιχεία από ένα τμήμα να έχουν πρόσβαση σε στοιχεία από άλλο τμήμα (access). σύνδεση (binding): Παροχή τιμών σε ένα πρότυπο για να δημιουργήσει ένα νέο στοιχείο (bind). κλήση (call): Μια μέθοδος καλεί μια άλλη (call). απόρροια (derivation): Ένα στοιχείο που μπορεί να υπολογιστεί από κάποιο άλλο. friend: Ένα στοιχείο μπορεί να έχει πρόσβαση σε στοιχεία άλλης κλάσης παρά τους όποιους περιορισμούς (friend). εισαγωγή (import): 'Αδεια σε ένα τμήμα να εισάγει και να χρησιμοποιήσει τα στοιχεία ενός άλλου τμήματος (import). δημιουργία (instantiation): Μια μέθοδος μιας κλάσης δημιουργεί αντικείμενα μιας άλλης κλάσης (instantiate). παράμετρος (parameter): Σχέση ανάμεσα σε μια λειτουργία και τις παραμέτρους της (parameter). 12

δημιουργία (realization): Σχέση ανάμεσα σε μια προδιαγραφή και την υλοποίησή της (realize). εκλέπτυνση (refinement): Δήλωση για την ύπαρξη απεικόνισης ανάμεσα σε δύο σημασιολογικά επίπεδα (refine). αποστολή (send): Σχέση ανάμεσα στον αποστολέα και τον παραλήπτη ενός μηνύματος (send). ίχνος (trace): Σχέση ανάμεσα σε δύο στοιχεία δύο διαφορετικών μοντέλων που δεν αποτελεί όμως απεικόνιση (trace). χρήση (usage): Ένα στοιχείο απαιτεί την ύπαρξη ενός άλλου στοιχείο για τη λειτουργία του (π.χ. call, instantiate, parameter, send). Τέλος, παρακάτω υπάρχει ένα παράδειγμα διαγράμματος περιπτώσεων χρήσης που είναι και πιο ευρέως χρησιμοποιούμενο και ειδικά στη συγκεκριμένη περίπτωση μοντελοποιείται ο έλεγχος ενός αεροδρομίου. Εικόνα 2: UML παράδειγμα use case για τον έλεγχο σε αεροδρόμιο 13

2. Η βασική έρευνα Όπως αναφέρθηκε και στην εισαγωγή ως βασική πλατφόρμα ορίστηκε αυτή του Eclipse και πάνω σε αυτήν άρχισε η αναζήτηση για το κατάλληλο plug-in που θα επέτρεπε την ορθότερη μοντελοποίηση των ενσωματωμένων συστημάτων που τέθηκαν ως στόχος. Το Eclipse είναι ένα από τα δημοφιλέστερα IDE (Integrated Development Environment ή στα ελληνικά: Ολοκληρωμένο Περιβάλλον Ανάπτυξης) που χρησιμοποιείται από χιλιάδες προγραμματιστές παγκοσμίως για τη συγγραφή και εκτέλεση κώδικα. Η επιτυχία του οφείλεται σε τρεις παράγοντες που παραθέτονται παρακάτω: στο λιτό του περιβάλλον το οποίο είναι φιλικό ακόμα και στον αρχάριο προγραμματιστή, επίσης επειδή είναι σχεδιασμένο να λειτουργεί σε πολλά λειτουργικά συστήματα (Linux, Mac, Windows), αλλά κυρίως επειδή υποστηρίζει πολλές γλώσσες προγραμματισμού, από Java μέχρι C, C++, Perl, PHP, Python δίνοντας έτσι στο προγραμματιστή το ίδιο περιβάλλον εργασίας για τελείως διαφορετικούς κόσμους. Η πλατφόρμα Eclipse είναι ένα ολοκληρωμένο περιβάλλον ανάπτυξης λογισμικού. Βασικό χαρακτηριστικό της είναι το γεγονός ότι είναι χτισμένη πάνω σε ένα μηχανισμό ο οποίος επιτρέπει την εύρεση, την ανάπτυξη και την εκτέλεση μονάδων λογισμικού οι οποίες ονομάζονται πρόσθετα (plug-ins). Εκτός από ένα μικρό πυρήνα (Platform Runtime) όλη η λειτουργικότητα της Eclipse πλατφόρμας βρίσκεται σε plug-ins τα οποία έχουν εγκατασταθεί σε αυτήν. Με άλλα λόγια, τόσο η ίδια η πλατφόρμα του Eclipse όσο και τα εργαλεία που την επεκτείνουν απαρτίζονται από πρόσθετα. Κάθε πρόσθετο προσφέρει λειτουργικότητα η οποία μπορεί να αξιοποιηθεί με δύο τρόπους. Ο πρώτος είναι να κληθεί από τον χρήστη και ο δεύτερος να επαναχρησιμοποιηθεί και να επεκταθεί από άλλα πρόσθετα. Κατά την εκκίνηση της πλατφόρμας Eclipse, ο πυρήνας της (Platform Runtime) ανακαλύπτει το σύνολο των διαθέσιμων plug-ins. Ένα plug-in ενεργοποιείται μόνο όταν υπάρχει ανάγκη να τρέξει ο κώδικας του. 14

Τα βασικά χαρακτηριστικά της πλατφόρμας είναι τα ακόλουθα : Workbench: η επιφάνεια εργασίας της πλατφόρμας, δηλαδή το σύνολο των γραφικών στοιχείων της πλατφόρμας με τα οποία έρχεται σε επαφή ο χρήστη κατά τη διάρκεια της εργασίας του με την πλατφόρμα. Workspace: χώρος εργασίας στο τοπικό σύστημα αρχείων, στον οποίο αποθηκεύονται πληροφορίες. SWT : (Standard Widget Toolkit): σύνολο από γραφικά δομικά στοιχεία υλοποιημένα με τέτοιο τρόπο ώστε να επιτρέπεται η ενσωμάτωσή τους με το τοπικό λειτουργικό σύστημα. JFace: σύνολο γραφικών διεπαφών εμπλουτισμένα με κάποιες βασικές λειτουργίες, τις οποίες μπορεί εύκολα ο χρήστης να χρησιμοποιήσει, όπως δεντρικές αναπαραστάσεις, πίνακες, editors, παράθυρα ιδιοτήτων, κ.α. Help: μηχανισμός βοήθειας της πλατφόρμας που επιτρέπει παράλληλα τον εμπλουτισμό της με νέα εγχειρίδια. Team: δυνατότητα διαχείρισης / ανάπτυξης μίας εργασίας από πολλούς χρήστες ταυτόχρονα μέσω της χρήσης κατάλληλων μηχανισμών αποθήκευσης διαμοιραζόμενων πόρων. Η αρχιτεκτονική του Eclipse παρουσιάζεται στην παρακάτω εικόνα: 15

Εικόνα 3: Γενική αρχιτεκτονική του Eclipse. Πάνω στο μικρό πυρήνα (Platform Runtime) του Eclipse προστίθενται plug-ins που εμπλουτίζουν τη λειτουργικότητά του Το Eclipse βασίζεται σε μία πλατφόρμα εκτέλεσης που ονομάζεται Equinox. Αυτή είναι υπεύθυνη για τον εντοπισμό των πρόσθετων και την εκτέλεσή τους καθώς και για τη διαχείριση του κύκλου ζωής τους. Επίσης πρέπει να αναφερθεί ότι, διαχειρίζεται τις αλληλεξαρτήσεις ανάμεσα στα πρόσθετα, ενώ μπορεί να φορτώνει ταυτόχρονα διαφορετικές εκδόσεις του ίδιου πρόσθετου. Εδώ πρέπει να σημειωθεί ότι παρόλο που το Equinox αποτελεί το θεμελιώδες λίθο του Eclipse, γιατί όπως προαναφέρθηκε είναι η πλατφόρμα εκτέλεσης στην οποία και βασίζεται, ουσιαστικά όμως πρόκειται για µια πλήρως αυτόνομη υλοποίηση της προδιαγραφής OSGi R4. Εδώ λοιπόν θα πρέπει να γίνει και μία σύντομη αναφορά στο μοντέλο της προδιαγραφής OSGi. Το μοντέλο αυτό καθιστά δυνατή την ενεργοποίηση, την 16

απενεργοποίηση, την ενημέρωση και την απεγκατάσταση υπαρχόντων συστατικών και υπηρεσιών καθώς και την εγκατάσταση νέων συστατικών / υπηρεσιών δυναμικά (χωρίς να απαιτείται η επανεκκίνηση της εφαρμογής). Η μικρότερη αυτοτελής μονάδα στο OSGi είναι το bundle. Στο σημείο αυτό πρέπει να σημειωθεί ότι οι όροι plugin και bundle είναι σχεδόν εναλλάξιμοι. Το Equinox επεκτείνει την έννοια των bundles εισάγοντας την έννοια των σημείων επέκτασης (extension points). Στο σημεία αυτό ορίζεται ως RCP (Eclipse Rich Client Platform) το ελάχιστο σύνολο από πρόσθετα που απαιτούνται για τη δημιουργία μιας εφαρμογής πελάτη. Αν πάρουμε ως δεδομένο ότι η υποδομή του Eclipse χρησιμοποιείται πλέον για τη δημιουργία εφαρμογών τόσο στην πλευρά του πελάτη όσο και στην πλευρά του εξυπηρετητή, αυτή χαρακτηρίζεται επίσης µε τον όρο Eclipse Application Framework (EAF). Αφού έγινε η αρχική διερεύνηση και παράλληλα η εξοικείωση με την πλατφόρμα του Eclipse, σειρά είχαν τα πρόσθετα (plug-ins). Στα πλαίσια της έρευνας που έγινε με σκοπό το τελικό πλάνο της εργασίας, πειραματιστήκαμε με μία σειρά από plug-ins του προγράμματος eclipse ώστε να εντοπίσουμε τα πλεονεκτήματα και τα μειονεκτήματά τους, τις δυνατότητες και τις αδυναμίες τους. Με την ολοκλήρωση αυτής της έρευνας θα μπορέσουμε να καταλήξουμε στο πρόσθετο (plug-in) που θα χρησιμοποιήσουμε στο δικό μας παράδειγμα. Παρακάτω ακολουθεί μία σύντομη ανάλυση αυτών των εργαλείων. 2.1 BPMN2 Modeler 2.1.1Service-Oriented Architecture (SOA) Πριν ξεκινήσει η βαθύτερη ανάλυση του BPMN σαν εργαλείο θα πρέπει να ορισθεί και να επεξηγηθεί ένας όρος άμεσα συνδεδεμένος με αυτό και γενικά με τα εργαλεία που ακολουθούν και που ερευνήσαμε, το Oriented Architecture (SOA), για 17

το οποίο στη βιομηχανία υπάρχει μια αυξανόμενη τάση προς την αναδυόμενη τεχνολογία που αντιπροσωπεύει. Στις μέρες μας όταν γίνεται αναφορά σε αυτήν την τεχνολογία, συνεπάγεται και η εφαρμογή συστημάτων με τη χρήση τεχνολογιώνυπηρεσιών web. Το SOA είναι μια πρότυπη-προσέγγιση, για την δημιουργία συστατικών που μπορούν να επαναχρησιμοποιηθούν όντας διαθέσιμα και προσβάσιμα μέσω του web και μπορεί να θεωρηθεί ως μια επαναλαμβανόμενη επιχειρηματική εργασία. Το SOA δεν είναι προϊόν και ορίζεται ως οι πολιτικές, οι πρακτικές, τα πλαίσια που επιτρέπουν τη λειτουργία της εφαρμογής που πρέπει να παρέχονται, και να καταναλώνονται σαν σύνολα υπηρεσιών που δημοσιεύονται σε μια υποδιαίρεση σχετική με την υπηρεσία του καταναλωτή. Οι υπηρεσίες πρέπει να μπορούν να επικαλούνται, να δημοσιεύονται και να ανακαλύπτονται και να έχουν αντληθεί από την εφαρμογή χρησιμοποιώντας μια ενιαία με βάση τα πρότυπα της μορφής της διεπαφής. Οι υπηρεσίες δικτύου είναι τυπικά ο τρόπος με τον οποίο μια επιχειρηματική διεργασία υλοποιείται. Το BPM έχει να κάνει με την παροχή ενός επιπέδου ροής εργασίας για να ενορχηστρώσει τις υπηρεσίες δικτύου. Παρέχει το πλαίσιο της SOA για τη διαχείριση της δυναμικής εκτέλεσης των υπηρεσιών και επιτρέπει στους επιχειρηματικούς χρήστες να αλληλεπιδρούν μαζί τους ανάλογα με την περίπτωση. Η SOA μπορεί να θεωρηθεί σαν ένα στιλ αρχιτεκτονικής που τυπικά ξεχωρίζει υπηρεσίες (η επιχειρηματική λειτουργία) από τους καταναλωτές (άλλα επιχειρηματικά συστήματα). Ο διαχωρισμός επιτυγχάνεται μέσω μιας υπηρεσίας σύμβασης μεταξύ του καταναλωτή και του παραγωγού της υπηρεσίας. Αυτή η σύμβαση θα πρέπει να αντιμετωπίζει τα ζητήματα όπως η διαθεσιμότητα, ο έλεγχος έκδοσης, ασφάλεια, επίδοση. Πολλές υπηρεσίες δικτύου είναι ελεύθερες στο διαδίκτυο αλλά η χρήση αυτών αποτελεί ρίσκο χωρίς ένα επίπεδο συμφωνίας υπηρεσίας (SERVICE LEVEL AGREEMENT SLA) επειδή ίσως αυτές να μην υπάρχουν στο μέλλον, παρόλα αυτά, αυτό μπορεί να μην αποτελεί ζήτημα αν παρόμοιες εναλλακτικές υπηρεσίες δικτύου είναι διαθέσιμες για χρήση. Επιπλέον για μια σύμβαση υπηρεσίας, πρέπει να υπάρχει ένας τρόπος για τους παρόχους να δημοσιεύουν τις συμβάσεις υπηρεσίας και για τους καταναλωτές να μπορούν να τις εντοπίζουν. Αυτό τυπικά μπορεί να συμβεί μέσω προτύπων όπως η Universal Description,Discovery and Integration που είναι βασισμένη σε XML γλώσσα από το 18

W3C που επιτρέπει στις επιχειρήσεις να δημοσιεύουν λεπτομέρειες για τις υπηρεσίες που είναι διαθέσιμες στο διαδίκτυο. Η Web Service Description Language (WSDL 2007) παρέχει ένα τρόπο περιγραφής υπηρεσιών δικτύου με XML μορφή. Σημειώνεται ότι το σου λέει πώς να αλληλεπιδράς με την υπηρεσία δικτύου αλλά δεν λέει τίποτα σχετικά με το πώς πραγματικά αυτό δουλεύει πίσω από την διεπαφή. Το πρότυπο για επικοινωνία είναι μέσω SOAP (Simple Object Access Protocol) που είναι μια προδιαγραφή για ανταλλαγή πληροφοριών στον τομέα των υπηρεσιών δικτύου. Τον τελευταίο καιρό υπάρχει μια σύγκλιση μεταξύ της ενσωμάτωσης διάφορων προσεγγίσεων όπως τη SOA με Saas (Software as a Service) και με το δίκτυο και έτσι να γίνεται λόγος για web oriented architectures (WOA). Αυτή η προσέγγιση εκτείνει τη SOA σε εφαρμογές βασισμένες στο web προκειμένου να επιτρέψει στις επιχειρήσεις να ανοίξουν τα σχετικά μέρη των πληροφοριακών συστημάτων τους στους πελάτες, προμηθευτές κτλ ανάλογα με την περίπτωση. Αυτό έχει γίνει πλέον αναγκαίο προκειμένου να αποκτήσει η επιχείρηση ανταγωνιστικό πλεονέκτημα. Το WOA συχνά αντιμετωπίζεται ως μια ελαφριά έκδοση του SOA. Προκειμένου να διευθύνεις το κύκλο ζωής των επιχειρηματικών διεργασιών, απαιτείται λογισμικό που θα σου επιτρέψει για παράδειγμα: να εκθέσεις τις υπηρεσίες χωρίς την ανάγκη προγραμματισμού, την ανάπτυξη υπηρεσιών σε οποιαδήποτε πλατφόρμα, την διατήρηση της ασφάλειας και των πολιτικών χρήσης, και την ενορχήστρωση των υπηρεσιών. Γα παράδειγμα ο κεντρικός συντονισμός όλων των πολλαπλών υπηρεσιών δικτύου, η παροχή εργαλείου σχεδίασης γραφικών, η διανεμητέα runtime μηχανή και η δυνατότητα παρακολούθησης της υπηρεσίας, έχουν τη δυνατότητα να σχεδιάσουν μετατροπές προς και από μη XML μορφές. Αυτές είναι τυπικές λειτουργίες που παρέχονται από το middleware του SOA μαζί με ένα runtime περιβάλλον το οποίο πρέπει να περιλαμβάνει π.χ ανίχνευση γεγονότων, υπηρεσία φιλοξενίας (hosting), έξυπνη δρομολόγηση, επεξεργασία μετατροπής μηνυμάτων, δυνατότητες ασφάλειας, σύγχρονη και ασύγχρονη παράδοση μηνυμάτων. 19

2.1.2 Ανάλυση του BPMN2 Modeler Όπως αναφέρεται και παραπάνω, η αποστολή του SOA (Service-Oriented Architecture) Project είναι να δημιουργήσει επεκτάσιμα εργαλεία που να επιτρέπουν το σχεδιασμό, τη διαμόρφωση, τη σύνθεση, την ανάπτυξη, την παρακολούθηση και τη διαχείριση λογισμικού σχεδιασμένου σύμφωνα με μία Service Oriented αρχιτεκτονική. Το project αυτό είναι καθοδηγούμενο από τις αξίες της διαφάνειας, της επεκτασιμότητας, της ουδετερότητας, της συλλογικής συνεργασίας, της έξυπνης ανάπτυξης και της σταθερής καινοτομίας. Όλο αυτό έχει οδηγήσει στην ανάγκη για τον προσδιορισμό τον προσδιορισμό του BPMN 2.0, το οποίο είναι και το πρώτο πρόσθετο (plug-in) που εξετάσαμε στην έρευνά μας. Με λίγα λόγια το BPMN 2.0 φαίνεται πως είναι αυτό που θα υποστηρίζει τη μοντελοποίηση των επιχειρηματικών διαδικασιών και θα γίνει το βασικό εργαλείο της. Πιο συγκεκριμένα λοιπόν, η Σημειογραφική Μοντελοποίηση Επιχειρηματικών Διαδικασιών (Business Process Modeling Notation/BPMN εφεξής BPMN) αποτελεί μια γραφική απεικόνιση για τον προσδιορισμό των επιχειρηματικών διαδικασιών στη ροή εργασιών [BPMN, 2004]. Η BPMN αναπτύχθηκε από το BPMI, και πλέον διατηρείται από την Ομάδα Διαχείρισης Αντικειμένων (Object Management Group/OMG εφεξής OMG) αφού οι δύο οργανισμοί συγχωνεύτηκαν το 2005. Η BPMN είναι ένα πρότυπο μοντελοποίησης επιχειρηματικών διαδικασιών, και παρέχει ένα γραφικό συμβολισμό για τον προσδιορισμό των επιχειρηματικών διαδικασιών σε ένα διάγραμμα επιχειρηματικών διαδικασιών, βασισμένο στην τεχνική της απεικόνισης των ροών σε διαγράμματα, παρόμοια με τα διαγράμματα δραστηριοτήτων της ενοποιημένης γλώσσας μοντελοποίησης (unified modeling language/uml). Ο σκοπός της BPMN είναι η υποστήριξη της διαχείρισης επιχειρηματικών διαδικασιών τόσο για τεχνικούς χρήστες όσο και για εταιρικούς χρήστες, παρέχοντας ένα συμβολισμό που είναι διαισθητικός στους εταιρικούς χρήστες, ωστόσο ικανός να παρουσιάσει σημασιολογίες (semantics) πολύπλοκων διαδικασιών. Η προδιαγραφή της BPMN παρέχει, επίσης, μια χαρτογράφηση μεταξύ 20

των γραφικών του συμβολισμού με τις δομές των γλωσσών εκτέλεσης, κυρίως της BPEL. Η BPMN έχει περιοριστεί ώστε να υποστηρίζει μόνο τις έννοιες της μοντελοποίησης που είναι εφαρμόσιμες στις επιχειρηματικές διαδικασίες. Αυτό σημαίνει ότι οι άλλοι τύποι μοντελοποίησης που γίνονται από οργανισμούς για μηεπιχειρηματικούς σκοπούς είναι εκτός του πεδίου της. Για παράδειγμα, η μοντελοποίηση των οργανωτικών δομών, λειτουργικών διακοπών, μοντέλων δεδομένων, στρατηγικής και επιχειρηματικών κανόνων δεν αποτελεί μέρος της BPMN. Επίσης, δεν προβλέπεται εν τέλει η σωστή μοντελοποίηση των ενσωματωμένων συστημάτων με αυτό το εργαλείο -κάτι που προφανώς αποτελεί βασικό κριτήριο για να απορριφθεί εν τέλει αυτό το εργαλείο- αλλά θα ήταν χρήσιμο να μελετηθούν κάποια ενδιαφέροντα ακόμα στοιχεία της αρχιτεκτονικής του που συνδέονται άμεσα με τη λογική της μοντελοποίησης. Η μοντελοποίηση στην BPMN γίνεται από απλά διαγράμματα με μικρές ομάδες γραφικών συστατικών. Θα πρέπει να είναι εύκολο τόσο για τους εταιρικούς χρήστες όσο και για τους προγραμματιστές να αντιλαμβάνονται τη ροή και τη διαδικασία. Οι τέσσερεις βασικές κατηγορίες συστατικών είναι οι εξής: Αντικείμενα ροής και συνδετικά αντικείμενα. Τα αντικείμενα ροής είναι τα βασικά συστατικά περιγραφής στη BPMN, και αποτελούνται από τρία βασικά συστατικά, γεγονότα (events), δραστηριότητες (activities), και πύλες (gateways). Τα αντικείμενα ροής συνδέονται μεταξύ τους χρησιμοποιώντας τα συνδετικά αντικείμενα, τα οποίa αποτελούνται από τρεις τύπους ακολουθίες (sequences), μηνύματα (messages), και συσχετίσεις (associations). Οι λωρίδες (swim lanes) είναι ένας οπτικός μηχανισμός οργάνωσης και κατηγοριοποίησης δραστηριοτήτων, βασισμένος στη δια-λειτουργική απεικόνιση των ροών μέσω διαγραμμάτων, και αποτελούνται από δυο τύπους, δεξαμενές και λωρίδες (pools and lanes). Τα τεχνήματα (artifacts) επιτρέπουν στους προγραμματιστές να φέρουν περισσότερες πληροφορίες μέσα στο μοντέλο/διάγραμμα. Με αυτό τον τρόπο το μοντέλο/διάγραμμα γίνεται πιο εύκολα αναγνώσιμο. Υπάρχουν τρία (3) 21

προ-καθορισμένα τεχνήματα τα οποία είναι αντικείμενα δεδομένων, ομάδες και σχολιασμοί. Υπάρχουν τρεις βασικοί τύποι (υπό-)μοντέλων μέσα σε ένα ολοκληρωμένο μοντέλο: οι ιδιωτικές (εσωτερικές) επιχειρηματικές διαδικασίες, οι αφηρημένες (δημόσιες) διαδικασίες, και οι διαδικασίες συνεργασίας. Οι ιδιωτικές επιχειρηματικές διαδικασίες είναι αυτές που είναι εσωτερικές σε συγκεκριμένο οργανισμό και είναι οι τύποι διαδικασιών που ονομάζονται γενικά ροή εργασιών ή διαδικασίες διαχείρισης. Αν χρησιμοποιούνται λωρίδες (swim lanes) τότε μία ιδιωτική επιχειρηματική διαδικασία θα περιέχεται μέσα σε ένα πλαίσιο. Έτσι η σειριακή ροή της διαδικασίας δεν μπορεί να περάσει τα σύνορα της. Η ροή μηνυμάτων μπορεί να περάσει τα σύνορά της ώστε να δείξει τις αλληλεπιδράσεις μεταξύ διαφορετικών ιδιωτικών επιχειρηματικών διαδικασιών. Αφηρημένες διαδικασίες οι οποίες παρουσιάζουν τις αλληλεπιδράσεις μεταξύ μιας ιδιωτικής επιχειρηματικής διαδικασίας και μιας άλλης διαδικασίας ή ενός συμμετέχοντος. Μόνο οι δραστηριότητες που επικοινωνούν εξωτερικά των ιδιωτικών επιχειρηματικών διαδικασιών περιλαμβάνονται στην αφηρημένη διαδικασία. Όλες οι υπόλοιπες εσωτερικές δραστηριότητες των ιδιωτικών επιχειρηματικών διαδικασιών δε φαίνονται στην αφηρημένη διαδικασία. Συνεπώς, η αφηρημένη διαδικασία δείχνει στον έξω κόσμο την ακολουθία των μηνυμάτων που απαιτείται να αλληλεπιδράσουν με εκείνη την επιχειρηματική διαδικασία. Αν η αφηρημένη διαδικασία βρίσκεται στο ίδιο διάγραμμα με τις ανταποκρινόμενες ιδιωτικές επιχειρηματικές διαδικασίες της, τότε οι δραστηριότητες που είναι κοινές και στις δύο διαδικασίες μπορούν να συσχετιστούν. Διαδικασίες συνεργασίας που απεικονίζουν τις αλληλεπιδράσεις μεταξύ δύο ή περισσοτέρων οντοτήτων. Αυτές οι αλληλεπιδράσεις καθορίζονται ως μια ακολουθία δραστηριοτήτων που παρουσιάζουν τα πρότυπα ανταλλαγής μηνυμάτων μεταξύ των εμπλεκομένων οντοτήτων. Οι διαδικασίες συνεργασίας μπορεί να περιέχονται μέσα σε ένα πλαίσιο (pool) και οι διάφορες επιχειρηματικές αλληλεπιδράσεις μεταξύ των συμμετεχόντων να 22

παρουσιάζονται ως λωρίδες (lanes). Σε αυτή τη περίπτωση, κάθε λωρίδα θα παρουσιάζει δυο συμμετέχοντες και την κατεύθυνση του μεταξύ τους ταξιδιού. Μπορεί επίσης να παρουσιαστούν ως δυο ή περισσότερες αφηρημένες διαδικασίες που αλληλεπιδρούν μέσα από τη ροή μηνυμάτων (όπως περιγράφηκε παραπάνω). Αυτές οι διαδικασίες μπορούν να μοντελοποιηθούν ξεχωριστά ή μέσα σε ένα μεγάλο διάγραμμα, ώστε να δείχνουν τις συσχετίσεις μεταξύ των διαδικασιών συνεργασίας και άλλων οντοτήτων. Αν η διαδικασία συνεργασίας είναι στο ίδιο διάγραμμα με μια ανταποκρινόμενη ιδιωτική επιχειρηματική διαδικασία της, τότε οι δραστηριότητες που είναι κοινές και στις δυο διαδικασίες μπορούν να συσχετιστούν. Στο σημείο αυτό πρέπει να σημειωθεί ότι η BPMN είναι σε σημαντικό βαθμό διαφορετικό με άλλα κοινά πρότυπα για την παροχή απεικόνισης ενός συστήματος όπως είναι η UML. Ενώ και οι δύο παρέχουν τη γραφική σημείωση των επιχειρηματικών διεργασιών σε κάποια μορφή, το UML παίρνει μια προσανατολισμένη στα αντικείμενα άποψη του συστήματος και δεν είναι εύκολα κατανοητή από τους επιχειρηματικούς χρήστες ενώ η BPMN παίρνει μια προσανατολισμένη στις διεργασίες άποψη του συστήματος και είναι πιο εύκολα κατανοητή χωρίς τυπική εκπαίδευση. Οι δύο αυτές προσεγγίσεις δεν είναι ανταγωνιστικές, εξυπηρετούν όμως διαφορετικούς σκοπούς ενώ παράλληλα παρέχουν διαφορετικές όψεις των διεργασιών του συστήματος και είναι συμπληρωματικές. 2.2 SDO / CDO Το Service Data Object συμπληρώνει την Service Component αρχιτεκτονική (SCA). Η αρχιτεκτονική αυτή, καθορίζει τις υπηρεσίες σαν ξεχωριστές συνιστώσες και τη συνδεσιμότητα μεταξύ τους. Μία ακόμη επιπλέον λειτουργία της είναι καθορίζει τη ροή δεδομένων μεταξύ των συνιστωσών αυτών. 23

Κάθε συνιστώσα στέλνει πληροφορίες ως είσοδο και έξοδο. Όταν καλείται κάποια υπηρεσία, αντικείμενα μνήμης στέλνονται ως XML αρχεία κωδικοποιημένα. Τα αντικείμενα αυτά θεωρούνται για τη Service Component αρχιτεκτονική η καλύτερη μορφή δεδομένων. Στο παρακάτω παράδειγμα φαίνεται η ροή δεδομένων σε ένα παράδειγμα εισαγωγών-εξαγωγών. Εικόνα 4: Ροή δεδομένων SDO Το CDO (Connected Data Objects) μοντέλο αποθήκευσης, είναι ένα κατανεμημένο μοντέλο για EMF μοντέλα και μεταμοντέλα. Επίσης θεωρείται ιδανικό και για runtime περιβάλλον. Το CDO αποτελείται από μία αρχιτεκτονική τριών επιπέδων υποστηριζόμενο από EMF εφαρμογές, το οποίο έχει ένα κεντρικό αποθηκευτικό server και αξιοποιεί διαφορετικούς τύπους συνδεόμενης αποθήκευσης, όπως σχεσιακές βάσεις 24

δεδομένων, βάσεις δεδομένων αντικειμένου και συστήματα αρχείων. Η προεπιλογή client/server από το πρωτόκολλο υλοποιείται με την πλατφόρμα σηματοδότησης Net4j. Πιο συγκεκριμένα, οι προγραμματιστές μπορούν πλέον εύκολα να ενισχύσουν τα υπάρχοντα μοντέλα EMF με τέτοιο τρόπο ώστε να μπορούν να αποθηκευθούν και ακολούθως να διατηρηθούν σε μία κεντρική αποθήκη. Για τα μοντέλα SDO και CDO δεν κατέστει εφικτό να συγκεντρωθούν αρκετές πληροφορίες και ούτε μοντέλα που να έχουν δημιουργηθεί μέσω αυτών, οπότε αποφασίστηκε να μην προχωρήσουμε σε βάθος σε ότι αφορά αυτά τα εργαλεία. 2.3 MDT/UML2 Η UML2 είναι μία EMF εφαρμογή του Unified Modeling Language (UML) 2.x OMG μεταμοντέλου για το Eclipse. Τα βασικά σημεία που παρέχονται από τη UML2 παραθέτονται παρακάτω: Μία χρήσιμη εφαρμογή του UML μεταμοντέλου για να στηρίξει την ανάπτυξη των εργαλείων μοντελοποίησης. Ένα κοινό σχήμα XMI για να διευκολυνθεί η ανταλλαγή των σημασιολογικών μοντέλων. Περιπτώσεις δοκιμής ως μέσο επικύρωσης της προδιαγραφής. Κανόνες επικύρωσης ως μέσο για τον καθορισμό και την επιβολή των επιπέδων συμμόρφωσης. Παρόλο που η MDT/UML2 παρέχει το μεταμοντέλο, δεν παρέχονται UML εργαλεία μοντελοποίησης από μόνα τους, κάτι που αποτελεί σοβαρό λόγο για να απορριφθεί και αυτό το εργαλείο, καθώς δεν κρίνεται κατάλληλο για όλα αυτά που ορίστηκαν παραπάνω ως στόχοι μοντελοποίησης. Μια τέτοια εφαρμογή είναι το MDT/Papyrus ενώ μία παλαιότερη μη υποστηριζόμενη εφαρμογή είναι το MDT- UML2 Tools. 25

2.4 Papyrus Το Papyrus plug-in έχει ως σκοπό την παροχή ολοκληρωμένου περιβάλλοντος για την επεξεργασία οποιουδήποτε είδους EMF μοντέλου και ειδικότερα υποστηρίζει UML και άλλες σχετικές γλώσσες μοντελοποίησης όπως για παράδειγμα η Sysml και η MARTE. Επίσης παρέχει diagram editors για EMF-based γλώσσες μοντελοποίησης μεταξύ των οποίων είναι η UML2 και η Sysml και τη σύνδεση που χρειάζεται για την ενσωμάτωση αυτών με άλλα MBD και MDSD εργαλεία. Το Papyrus προσφέρει επίσης προηγμένη υποστήριξη των UML profiles, κάτι που επιτρέπει στους χρήστες να καθορίσουν editors για άδειες DSL με βάση το πρότυπο UML2. Το κύριο χαρακτηριστικό του Papyrus σχετικά με το τελευταίο σημείο είναι ένα σύνολο πολύ ισχυρών μηχανισμών προσαρμογής που μπορεί να αξιοποιηθούν για να δημιουργηθούν προοπτικές καθορισμένες από το χρήστη και να του δώσουν την ίδια εμφάνιση και αίσθηση σαν έναν «αγνό» (pure) DSL editor. Η κατάληξη λοιπόν της παραπάνω έρευνας ήτανε πως το plug-in που θα χρησιμοποιηθεί και ταιριάζει στους στόχους είναι το Papyrus και η γλώσσα μοντελοποίησης θα είναι η SysML, η οποία με τη σειρά της αναλύεται και εκτενέστερα στη συνέχεια. Φάνηκε απ τις πρώτες δοκιμές χρήσης του ότι είναι ένα εργαλείο το οποίο μπορεί να παρέχει ακριβώς ότι απαιτείται για μια σωστή και ορθή μοντελοποίηση διαφόρων ενσωματωμένων ηλεκτρονικών συστημάτων. 2.4.1 EMF (Eclipse Modeling Framework) Πριν κλείσει το κεφάλαιο αυτό της έρευνας θα ήτανε καλό να γίνει μια αναφορά και σε κάποια σημεία που αφορούν το πλαίσιο του EMF, το οποίο είναι άμεσα συνδεδεμένο με τη λογική του papyrus και της γλώσσας SysML. Το EMF μπορεί να χρησιμοποιηθεί με στόχο την κατασκευή ενός μοντέλου, το οποίο στη 26

συνέχεια είναι δυνατό να αποτελέσει τη βάση για την ανάπτυξη οποιασδήποτε εφαρμογής Java. Ειδικότερα, τo EMF ενοποιεί τις τεχνολογίες Java, XML και UML, καθώς επιτρέπει τον ορισμό ενός μοντέλου σε οποιαδήποτε από τις παραπάνω μορφές, από την οποία είναι δυνατή στη συνέχεια η παραγωγή των υπολοίπων καθώς και των αντίστοιχων κλάσεων υλοποίησης. Πέρα από την ενίσχυση της παραγωγικότητας και της ποιότητας ως αποτέλεσμα της αυτόματης παραγωγής κώδικα, η δημιουργία μιας εφαρμογής με τη χρήση του EMF προσφέρει και άλλα οφέλη, όπως ένα μηχανισμό ειδοποιήσεων αναφορικά με μεταβολές του μοντέλου, δυνατότητα αποθήκευσης στιγμιότυπων του μοντέλου και ένα αποδοτικό API (Application Programming Interface) για τον χειρισμό αντικειμένων EMF με γενικό τρόπο. Και το σημαντικότερο είναι ότι το EMF παρέχει την υποδομή για διαλειτουργικότητα με άλλα (βασισμένα στο EMF) εργαλεία και εφαρμογές. Τέλος, σχετικά με το EMF θα ήτανε καλό να αναφερθεί ότι αποτελεί λογισμικό ανοιχτού κώδικα και είναι διαθέσιμο στη διεύθυνση http://www.eclipse.org/emf. Η τρέχουσα έκδοση του είναι η v2.6.1, ενώ απαραίτητη προϋπόθεση για την εγκατάσταση και χρήση του EMF αποτελεί η εγκατάσταση κατάλληλης έκδοσης της Java και του Eclipse. 27

3. Εισαγωγή στη SysML Στο κεφάλαιο αυτό παρουσιάζεται η γλώσσα μοντελοποίησης SysML (System Modeling Language) και παράλληλα στην ουσία έγινε μια προσπάθεια να παρουσιαστεί ένα σύντομο εγχειρίδιο χρήσης για τη γλώσσα αυτή. Οι ενότητες που ακολουθούν περιλαμβάνουν μία ιστορική αναδρομή της SysML, τη δομή της μαζί με τα βασικά συστατικά της και τη σύγκρισή της με τη UML. 3.1 Ιστορική Αναδρομή Στην ενότητα αυτή γίνεται μία ιστορική αναδρομή της SysML (System Modeling Language). Η UML καθιερώθηκε ως γλώσσα μοντελοποίησης στον τομέα της ανάπτυξης λογισμικού. Η προσαρμογή της UML στον τομέα του system engineering ονομάζεται SysML (System Modeling Engineering). Το system engineering, με λίγα λόγια, επικεντρώνεται στον καθορισμό και την τεκμηρίωση των απαιτήσεων του συστήματος στη φάση της ανάπτυξης κατά την οποία γίνεται η ανάλυση, ο σχεδιασμός και η επιβεβαίωση με βάση τις απαιτήσεις του συστήματος. Η ανάγκη για την ύπαρξη μιας γλώσσας μοντελοποίησης για το system engineering έδωσε την ώθηση για τη δημιουργία της SysML. Το 2001 ο παγκόσμιος οργανισμός International Council of System Engineering (INCOSE) σε συνεργασία με την εταιρεία Object Management Group ίδρυσαν το System Engineering Domain Special Interest Group (SE DSIG) που είχε στόχο την ανάπτυξη μιας επέκτασης της UML, η οποία θα χρησιμοποιείται για τη σχεδίαση, ανάλυση και επιβεβαίωση πολύπλοκων συστημάτων. Το 2003 μία ομάδα με το όνομα SysML Partners που εργαζόταν στο έργο, πρότεινε ως επέκταση τη SysML (System Modeling Engineering). Έπειτα από λίγους μήνες το πρώτο προσχέδιο της SysML είχε υλοποιηθεί και τον Απρίλιο του 2006 στο St.Louis καθιερώθηκε η SysML ως 28

πρότυπο. Η πρώτη έκδοση SysML v1.0 βγήκε στην αγορά το Σεπτέμβριο του 2007, ωστόσο είχε κάποια λάθη και παραλείψεις. Το Νοέμβριο του 2008 ήταν διαθέσιμη η δεύτερη έκδοση SysML v1.1, η οποία είχε ως στόχο να διορθώσει τα λάθη της προηγούμενη. Η Τρίτη έκδοση SysML v1.2 κυκλοφόρησε στις 16 Ιουνίου του 2010 και τέλος στις 8 Ιουνίου 2012 έχει ήδη κυκλοφορήσει η τέταρτη έκδοση SysML v1.3 ως επίσημη προδιαγραφή του OMG. Εικόνα 5: Σχέση UML με SysML 29

3.2 Δομή της SysML και σύγκριση με τη UML Στην ενότητα αυτή παρουσιάζεται η δομή της SysML και η σύγκρισή της με τη UML. Η SysML υποστηρίζει τον προσδιορισμό, την ανάλυση, το σχεδιασμό, την επιβεβαίωση και την επισημοποίηση συστημάτων, τα οποία περιλαμβάνουν hardware, software, δεδομένα, προσωπικό και διαδικασίες. Τα διαγράμματα της SysML χωρίζονται σε τρεις κατηγορίες: τα διαγράμματα δομής (structure diagrams), συμπεριφοράς (behaviour diagrams) και απαιτήσεων (requirement diagrams). Τα διαγράμματα δομής περιλαμβάνουν: Το διάγραμμα καθορισμού τμημάτων (block definition diagram). Το διάγραμμα εσωτερικών τμημάτων (internal block diagram). Το διάγραμμα παραμέτρων (parametric diagram). Το διάγραμμα πακέτων (package diagram). Τα διαγράμματα συμπεριφοράς περιλαμβάνουν: Τα διαγράμματα δραστηριοτήτων (activity diagram). Τα διαγράμματα ακολουθίας (sequence diagram). Τα διαγράμματα κατάστασης (state machine diagram). Το διάγραμμα περιπτώσεων χρήσης (use case diagram). 30

Εικόνα 6: Διαγράμματα της SysML και κατηγοριοποίηση τους Κάθε διάγραμμα πρέπει να έχει ένα πλαίσιο (diagram frame), το οποίο αποτελείται από την επικεφαλίδα (header), την περιγραφή του διαγράμματος (diagram description) και το περιεχόμενο (content). Η επικεφαλίδα αποτελείται από τα εξής μέρη: Το είδος του διαγράμματος (diagram kind). Τον τύπο του στοιχείου του μοντέλου (model element type). Το όνομα του στοιχείου του μοντέλου (model element name). Το όνομα του διαγράμματος (diagram name). Τη χρήση του διαγράμματος (diagram usage) 31

Η περιγραφή του διαγράμματος αποτελείται από: Την έκδοση (version). Την περιγραφή (description). Την κατάσταση ολοκλήρωσης (completion status). Την αναφορά (reference). Τα πεδία που καθορίζονται από το χρήστη (user-defined fields). Το περιεχόμενο του διαγράμματος αποτελείται από: Ιδιότητες (properties). Λέξεις κλειδιά (keywords) Κόμβους (node symbols). Μονοπάτια (path symbols). Εικόνες (icon symbols). Σημειώσεις (note symbols). Εικόνα 7: Δομή διαγραμμάτων της SysML 32

Εκτός από τα παραπάνω, η SysML υποστηρίζει και πίνακες, μήτρες και δέντρα. Παρακάτω θα αναλυθούν τα διαγράμματα της SysML και ιδιαίτερα αυτά που διαφέρουν με την UML. 3.2.1 Διάγραμμα Απαιτήσεων Το διάγραμμα απαιτήσεων παρουσιάζει τις απαιτήσεις του έργου και τη σχέση τους με άλλες απαιτήσεις, στοιχεία του σχεδιασμού και περιπτώσεις ελέγχου, οι οποίες υποστηρίζουν ανίχνευση απαιτήσεων. Απαίτηση είναι η ιδιότητα ή συμπεριφορά ενός συστήματος, η οποία θα πρέπει πάντα να ικανοποιείται. Τα βασικά στοιχεία από τα οποία αποτελείται ένα διάγραμμα απαιτήσεων είναι η μοναδική ταυτότητα που θα πρέπει να έχει (ID) και το κείμενο που θα την περιγράφει (text). Οι σχέσεις (relationships) μεταξύ δύο απαιτήσεων παρουσιάζονται στον παρακάτω πίνακα: Requirement (Απαίτηση) Derive relationship, η οποία περιγράφει μια απαίτηση η οποία προέρχεται από μια άλλη απαίτηση. Namespace containment, η οποία περιγράφει μια απαίτηση η οποία περιέχεται σε μια άλλη απαίτηση. Satisfy relationship, η οποία περιγράφει ένα στοιχείο του σχεδιασμού το οποίο ικανοποιεί μια απαίτηση. 33

Copy relationship, η οποία περιγράφει μια απαίτηση η οποία είναι αντίγραφο μια άλλης απαίτησης. Verify relationship, η οποία συνδέει μια περίπτωση ελέγχου με μια απαίτηση η οποία επαληθεύεται από την περίπτωση ελέγχου. Test case είναι μια ροή που ελέγχει εάν το σύστημα ικανοποιεί μια απαίτηση Refine relationship, η οποία καθορίζει το στοιχείο του συστήματος που περιγράφει τις ιδιότητες μιας απαίτησης με περισσότερες λεπτομέρειες. Trace relationship είναι η σχέση μεταξύ μιας απαίτησης και ενός αυθαίρετου στοιχείου του συστήματος. Allocation relationship είναι μια γενική σχέση μεταξύ στοιχείων διαφορετικού τύπου ή διαφορετικών επιπέδων. Πίνακας 1: Σύνταξη διαγράμματος απαιτήσεων Παρακάτω ακολουθεί ένα παράδειγμα διαγράμματος απαιτήσεων. 34

Εικόνα 8: Γενικό παράδειγμα διαγράμματος απαιτήσεων 3.2.2 Διάγραμμα Καθορισμού Τμημάτων Το διάγραμμα καθορισμού τμημάτων (block definition diagram) παρουσιάζει τη σύνθεση και κατάταξη δομικών στοιχείων τα οποία ονομάζονται blocks. Το block αποτελείται από τις τιμές (values), τις λειτουργίες (operations), τους περιορισμούς (constraints), τα τμήματα (parts) και τις αναφορές (references). Άλλα στοιχεία που συμπεριλαμβάνονται σε ένα block είναι η διανομή των ορισμών (distribution definition) που περιγράφει πως οι τιμές διανέμονται σε ένα εύρος τιμών, ο τύπος της τιμής (value type), η μονάδα (unit) που περιγράφει τη δομή μιας φυσικής μονάδας και η διάσταση (dimension) που περιγράφει την ποσότητα μιας μονάδας. Όσον αφορά τις θύρες (ports) και τις ροές υπάρχει η θύρα ροής (flow port), η οποία περιγράφει ένα σημείο αλληλεπίδρασης ενός block και η ροή αντικειμένου (item flow), η οποία περιγράφει τη σύνδεση συγκεκριμένων αντικειμένων. 35

Block Association είναι η σχέση μεταξύ δύο blocks. Generalization είναι η ταξινομική σχέση μεταξύ του ειδικού και του γενικού block. Dependency είναι η σχέση μεταξύ δύο στοιχείων, η οποία περιγράφει τι χρειάζεται το ένα στοιχείο από το άλλο για την υλοποίηση του. Πίνακας 2: Σύνταξη διαγράμματος απαιτήσεων Παρακάτω ακολουθεί ένα παράδειγμα διαγράμματος καθορισμού τμημάτων. 36

Εικόνα 9: Γενικό παράδειγμα διαγράμματος καθορισμού τμημάτων 3.2.3 Διάγραμμα Εσωτερικών τμημάτων Το διάγραμμα εσωτερικών τμημάτων (internal block diagram) περιγράφει την εσωτερική δομή των τμημάτων (blocks) σε επίπεδο ρόλων. Η δομή και η σύνταξη του διαγράμματος εσωτερικών τμημάτων είναι ίδια με του διαγράμματος καθορισμού τμημάτων. 3.2.4 Διάγραμμα Παραμέτρων Το διάγραμμα παραμέτρων (parametric diagram), ενδεικτικά παρουσιάζει τις παραμετρικές σχέσεις, εάν τυχόν υπάρχουν, ανάμεσα στα blocks. 37

3.2.5 Διάγραμμα Δραστηριοτήτων Το διάγραμμα δραστηριοτήτων (activity diagram) παρουσιάζει τη συμπεριφορά σε χρονική σειρά των ενεργειών οι οποίες βασίζονται στη διαθεσιμότητα εισροών, εκροών, ελέγχου και πως οι ενέργειες μετατρέπονται σε εισροές και εκροές. Η διαφορά μεταξύ του διαγράμματος δραστηριοτήτων της SysML και της UML είναι ο εκτεταμένος έλεγχος ροής με περισσότερες πληροφορίες για τη διακοπή ενεργειών, η υποστήριξη μοντελοποίησης συνεχόμενων συστημάτων, η υποστήριξη πιθανοτήτων στις ροές και η μοντελοποίηση κανόνων για δραστηριότητες στο διάγραμμα καθορισμού τμημάτων. Τα στοιχεία που περιλαμβάνονται σε ένα διάγραμμα δραστηριοτήτων είναι ο διαχειριστής ελέγχου (control operator) που καθορίζει εάν μια συμπεριφορά καθίσταται ικανή ή όχι από μια ενέργεια και αυτό γίνεται μέσω μιας τιμής, η οποία ονομάζεται τιμή ελέγχου (control value), η εκτίμηση (rate) που περιγράφει τη συχνότητα με την οποία εμφανίζονται τα στοιχεία σε μια δραστηριότητα ή ροή και η πιθανότητα (probability), η οποία περιγράφει πόσο πιθανό είναι να χρησιμοποιηθεί μια εξερχόμενη ροή. Action και Activity απεικονίζουν μια συμπεριφορά ή μια ενέργεια. Control flow δείχνει τη σειρά με την οποία εκτελούνται τα γεγονότα. Object flow δείχνει τη ροή ενός αντικειμένου από τη μια δραστηριότητα στην άλλη. Rate 38

Probability Initial node απεικονίζει την έναρξη των γεγονότων. Final-activity node απεικονίζει τη λήξη των γεγονότων. Final-flow node χρησιμοποιείται για να σταματήσει το control flow ή το object flow. Decision node χρησιμοποιείται για να αναπαραστήσει μια συνθήκη και για να εξασφαλίσει ότι η ροή θα ακολουθήσει ένα μόνο μονοπάτι. Merge node χρησιμοποιείται για να επαναφέρει διαφορετικά μονοπάτια σε ένα decision node. Πίνακας 3: Σύνταξη διαγράμματος δραστηριοτήτων Παρακάτω ακολουθεί ένα παράδειγμα διαγράμματος δραστηριοτήτων. 39

Εικόνα 10: Γενικό παράδειγμα διαγράμματος δραστηριοτήτων 3.2.6 Διάγραμμα Περιπτώσεων Χρήσης Το διάγραμμα περιπτώσεων χρήσης (use case diagram) παρουσιάζει τη λειτουργικότητα ενός συστήματος και πως ένα σύστημα ή μια οντότητα χρησιμοποιείται από εξωτερικές οντότητες (χρήστες) για να επιτευχθεί ένας στόχος. 40

Εικόνα 11: Γενικό παράδειγμα διαγράμματος Περιπτώσεων Χρήσης 3.2.7 Διάγραμμα Ακολουθίας Το διάγραμμα ακολουθίας (sequence diagram) παρουσιάζει τη συμπεριφορά των μηνυμάτων που ανταλλάσσονται ανάμεσα στα μέρη του συστήματος. Lifeline δηλώνει τη ζωή ενός αντικειμένου κατά τη διάρκεια της ακολουθίας. Execution δηλώνει την αποστολή η παραλαβή μηνύματος από ένα αντικείμενο. 41

Call Message μεταφέρει μηνύματα από το ένα αντικείμενο στο άλλο. Reply Message μεταφέρει την απάντηση σε αποσταλμένο μήνυμα. Delete Message είναι η παύση ενός αντικειμένου. Πίνακας 4: Σύνταξη διαγράμματος ακολουθίας Παρακάτω ακολουθεί ένα παράδειγμα διαγράμματος ακολουθίας. Εικόνα 12: Γενικό παράδειγμα διαγράμματος ακολουθίας 42

3.2.8 Διάγραμμα Κατάστασης / Διάγραμμα Πακέτων Το διάγραμμα κατάστασης (state machine diagram) παρουσιάζει τη συμπεριφορά μιας οντότητας μέσα από καταστάσεις, οι οποίες προκαλούνται από γεγονότα. Το διάγραμμα πακέτων (package diagram) παρουσιάζει τη δομή και οργάνωση του μοντέλου σε πακέτα τα οποία περιέχουν στοιχεία του συστήματος. 3.2.9 Διαφορές SysML και UML Η SysML και η UML είναι στενά συνδεδεμένες, καθώς η SysML είναι επέκταση της UML. Οι επιπλέον λειτουργίες ή αλλαγές της SysML σε σχέση με τη UML είναι: Προσθήκη νέων διαγραμμάτων: requirement diagram και parametric diagram. Οι κλάσεις ονομάζονται blocks και το αντίστοιχο διάγραμμα ονομάζεται block definition diagram αντί για class diagram. To διάγραμμα της UML composite structure diagram ονομάζεται στη SysML internal block diagram. Οι item flows μεταξύ των στοιχείων σε ένα internal block diagram μπορούν να μοντελοποιηθούν. Συνεχόμενες λειτουργίες μπορούν να υποστηριχθούν από action και object nodes στα activity diagrams και στα enhanced functional block diagrams. H προσθήκη της ISO AP-233 τυποποίησης δεδομένων για την υποστήριξη ανταλλαγής δεδομένων μεταξύ των εργαλείων. Παράληψη στοιχείων της UML που δεν χρειάζονται στον τομέα του system engineering. Εκτός από τις επιπλέον λειτουργίες και αλλαγές της SysML σε σχέση με τη UML, o πυρήνας της UML που είναι o object orientation (κλάσεις, αντικείμενα κ.τ.λ.) δεν αποτελεί βασικό στοιχείο της SysML με αποτέλεσμα κάποιος να μην χρειάζεται να έχει γνώσεις object orientation για να χρησιμοποιήσει τη SysML. 43

3.3 Συμπεράσματα SysML Στο παρόν κεφάλαιο μελετήθηκε η SysML, η οποία έχει καθιερωθεί ως γλώσσα μοντελοποίησης του system engineering. Η SysML έχει μόλις έξι χρόνια που είναι διαθέσιμη, καθώς η πρώτη έκδοση της κυκλοφόρησε το 2007. Η δομή της SysML είναι παρόμοια με της UML, ωστόσο υπάρχουν κάποιες αλλαγές και κάποια επιπλέον διαγράμματα με κυριότερο από αυτά το διάγραμμα απαιτήσεων που αποτελεί και το κύριο λόγο ύπαρξης της SysML. 44

4. Το κυρίως παράδειγμα Το project που θα υλοποιηθεί θα μοντελοποιεί ένα αυτοκίνητο του μέλλοντος και πιο συγκεκριμένα τα επιμέρους στοιχεία ασφάλειας τα οποία το διαφοροποιούν από τα σημερινά. Το project αυτό είναι απόρροια της εξήγησης της SysML από τον Balmelli, στέλεχος της IBM, η οποία αποτέλεσε πρωτοπόρο στη διάδοση της γλώσσας. Ο Balmelli εξηγεί τα βασικά βήματα της μοντελοποίησης με SysML χρησιμοποιώντας ένα παράδειγμα από την πραγματικότητα, αυτό των υαλοκαθαριστήρων οι οποίοι ενεργοποιούνται αυτόματα όταν ανιχνεύσουν νερό στο παρμπρίζ του αυτοκινήτου. Τα τρία βασικά διαγράμματα που είναι αρκετά για να οριστεί αυτή η περίπτωση -και κατ επέκταση και οι υπόλοιπες- είναι το διάγραμμα block definition, το διάγραμμα requirement και το διάγραμμα use case. Έχοντας αυτό ως αφετηρία, θα μπορούσε να φανταστεί κανείς διάφορα άλλα τέτοια συστήματα τα οποία θα μπορούσαν να έχουν τη θέση τους σε ένα αυτοκίνητο του μέλλοντος (future car). Η μοντελοποίηση των πιο τετριμμένων μερών ενός αυτοκινήτου (μηχανή, απλή λειτουργία φρένων, διαφορικό) δε θα μελετηθεί. Παρακάτω περιγράφεται τη δημιουργία του πρώτου κομματιού του παραδείγματος το οποίο όμως δίνεται ήδη από τον Balmeli, οπότε εστιάζουμε κυρίως στο πώς έγινε σε γενικές γραμμές η μεταφορά του στο papyrus. Περιγράφεται, δηλαδή, ο τρόπος με τον οποίο χρησιμοποιήθηκαν τα εργαλεία της Sysml για τη δημιουργία των διαγραμμάτων και την υλοποίηση των απαραίτητων μοντέλων σε όλες τις παρακάτω περιπτώσεις, καθώς είναι εμφανές ότι η τεχνική δεν αλλάζει και άρα και τα βήματα για τη δημιουργία από τεχνικής πλευράς και μέσω του workspace είναι παρόμοια. Στο Papyrus αρχικά δημιουργήθηκε ένα νέο block definition διάγραμμα το οποίο περιγράφει τα στοιχεία του συστήματος (αριστερό κλικ στο μοντέλο μας και επιλογή του block definition). Σε αυτό το διάγραμμα έχουν τεθεί οι actors (οδηγός, συντήρηση συστήματος και το ηλεκτρικό σύστημα του αυτοκινήτου), το κεντρικό σύστημα του υαλοκαθαριστήρα και τρία εξωτερικά blocks τα οποία στέλνουν δεδομένα στο κεντρικό σύστημα. Αυτό γίνεται από το δεξί μενού, το οποίο παρέχει όλα τα στοιχεία του διαγράμματος, από εκεί προσθέτονται δηλαδή και τα εκάστοτε στοιχεία. Οι actors, εν ολίγοις, είναι όλοι αυτοί που εισάγουν ή 45

εξάγουν δεδομένα προς και από το σύστημα. Χρησιμοποιείται λοιπόν το context diagram ως ένα διάγραμμα ανωτάτου επιπέδου, το οποίο απεικονίζει μόνο ποιοι χρησιμοποιούν το σύστημα, χωρίς άλλες λεπτομέρειες (το σύστημα το αντιμετωπίζουμε σαν μαύρο κουτί, δηλαδή δε υπάρχει κανένα ενδιαφέρον για το πώς λειτουργεί, μόνο το ότι λειτουργεί). Ακολούθως, ξεκινάει η δημιουργία του διαγράμματος απαιτήσεων, με τον ίδιο τρόπο με προηγουμένως, απλά αντί για block definition, επιλέγεται το requirements. Σε αυτό ορίζονται οι απαιτήσεις και οι σχέσεις των επιμέρους στοιχείων. Κάθε ένα requirement είναι μία επιλογή από τα δεξιά (requirement). Τα υψηλότερα και λιγότερο περιγραφικά επίπεδα αποσυντίθενται με links decompose σε απλούστερες μεθόδους, μέχρι να φτάσουμε στην απλούστερη απαίτηση. Το διάγραμμα απαιτήσεων ουσιαστικά μας δίνει την ακριβή λειτουργία του συστήματος σε επίπεδα. Ξεκινάμε από το υψηλότερο των επιπέδων (όσο υψηλότερο το επίπεδο τόσο λιγότερες λεπτομέρειες για τη λειτουργία του). Όσο αναγνωρίζουμε επιμέρους λειτουργίες σε κάθε ένα συστατικό, το αποσυνθέτουμε στις λειτουργίες αυτές. Τελικά φτάνουμε σε ένα διάγραμμα λεπτομερές, το οποίο μας δίνει ακριβώς τη λειτουργία του συστήματος. Τέλος, δημιουργείται ένα διάγραμμα Use Case. Εδώ θα περιγραφούν οι αλληλεπιδράσεις των actors με τα επιμέρους συστήματα. Όπως δηλώνει και το όνομα, αυτό το διάγραμμα δείχνει ποιες λειτουργίες του συστήματος χρειάζεται ο κάθε actor από το πρώτο διάγραμμα. Γι αυτό και χωρίζουμε το σύστημα (πάντα ο κεντρικός κύκλος που οδηγεί σε όλους τους άλλους) στα επιμέρους συστατικά του (πάλι όμως υψηλού επιπέδου, δε μας ενδιαφέρει να δείξουμε πώς λειτουργεί, απλά ποιες λειτουργίες του χρειάζεται ο κάθε actor). Όλες οι παραπάνω πράξεις γίνονται από το αριστερό μενού ονόματι Model Explorer. Με δεξί click προσθέτουμε το διάγραμμα που θέλουμε. Μόλις γίνει αυτό και ανοίξει το tab, στα δεξιά εμφανίζονται τα στοιχεία του διαγράμματος, ώστε να επιλέξουμε αυτά που θέλουμε και χρειαζόμαστε. Τα διαγράμματα τα οποία παρουσιάζει στην ουσία ο ίδιος ο Balmeli μεταφέρονται σχεδιαστικά όπως φαίνεται παρακάτω στο papyrus plug-in του eclipse. 46

Εικόνα13 : Block definition διάγραμμα μαζί με το workbench του συστήματος υαλοκαθαριστήρων 47

Εικόνα 14: Requirement diagram του συστήματος υαλοκαθαριστήρων 48

Εικόνα 15: Use case diagram μαζί με το workbench του συστήματος των υαλοκαθαριστήρων Εκτός από το σύστημα του αυτόματου υαλοκαθαριστήρα, θα υπάρξουν και άλλα τρία συστήματα τα οποία μοντελοποιούνται με τον ίδιο τρόπο. Ακολουθεί η περιγραφή τους και η μοντελοποίηση τους και τονίζεται πως η λειτουργία των συστημάτων φαίνεται ξεκάθαρα κυρίως στα διαγράμματα απαιτήσεων (requirement diagrams). 49