Αυτόματη παραγωγή διεπαφών χρήστη (user interfaces) για διαδικτυακές υπηρεσίες τύπου REST (RESTful web services)

Transcript

1 ΑΡΙΣΤΟΤΕΛΕΙΟ ΠΑΝΕΠΙΣΤΗΜΙΟ ΘΕΣΣΑΛΟΝΙΚΗΣ ΠΟΛΥΤΕΧΝΙΚΗ ΣΧΟΛΗ Τμήμα Ηλεκτρολόγων Μηχανικών και Μηχανικών Υπολογιστών Εργαστήριο Επεξεργασίας Πληροφορίας και Υπολογισμών Διπλωματική Εργασία Αυτόματη παραγωγή διεπαφών χρήστη (user interfaces) για διαδικτυακές υπηρεσίες τύπου REST (RESTful web services) Client for RESTful API automated Engine Διπλωματική Εργασία της: Κουιρουκίδου Μαρία Αριθμός Ειδικού Μητρώου: 7557 Επιβλέποντες Επίκουρος Καθηγητής Ανδρέας Λ.Συμεωνίδης Υποψήφιος Διδάκτωρ Χριστόφορος Ζολώτας Θεσσαλονίκη, Ιούνιος 2017

2 Αυτόματη παραγωγή διεπαφών χρήστη για διαδικτυακές υπηρεσίες τύπου REST Ευχαριστίες Θα ήθελα να ευχαριστήσω αρχικά τον κ. Ανδρέα Λ. Συμεωνίδη για την εμπιστοσύνη που μου έδειξε αναθέτοντας μου την διπλωματική εργασία. Έπειτα, τον υποψήφιο διδάκτορα Χριστόφορο Ζολώτα για την βοήθεια του και την καθοδήγησή του. Τέλος, θα ήθελα να ευχαριστήσω όλους τους ανθρώπους, οικογένεια και φίλους, που με στήριξαν όλα αυτά τα χρόνια. [2]

3 Περίληψη Περίληψη Την τελευταία δεκαετία, το αρχιτεκτονικό στυλ που έχει επικρατήσει για την ανάπτυξη διαδικτυακών εφαρμογών είναι αυτό που πρωτοεμφανίστηκε στην επιστημονική διατριβή του Roy Fielding το 2000, το REST αρχιτεκτονικό στυλ. Έκτοτε, χάρη στην απλότητα και την ισχύ του, το REST αρχιτεκτονικό στυλ, έχει κατακτήσει τον χώρο των διαδικτυακών εφαρμογών και αποτελεί το κυρίαρχο πρότυπο για την ανάπτυξή τους. Για τον λόγο αυτό, η ολοένα αυξανόμενη ζήτηση και χρήση REST APIs συνοδεύεται και από την τάση για δημιουργία αυτοματοποιημένων διαδικασιών που θα μπορούν να παράγουν μία εφαρμογή που θα καταναλώνει RESTful διαδικτυακές υπηρεσίες, οδηγώντας στην ελαχιστοποίηση του χρόνου και του κόστους που απαιτείται για την ανάπτυξή τους. Πολλά εργαλεία αυτοματοποίησης έχουν δημιουργηθεί τα τελευταία χρόνια, ωστόσο, πολλά από αυτά δεν έχουν τη δυνατότητα να παράγουν εφαρμογές έτοιμες για εκτέλεση, απαιτώντας εκ νέου την παρέμβαση του προγραμματιστή και την επιπλέον συγγραφή κώδικα. Η συγκεκριμένη διπλωματική εργασία φιλοδοξεί να θέσει τα πρώτα βήματα προς την κατεύθυνση της αυτοματοποίησης της διαδικασίας ανάπτυξης διαδικτυακών εφαρμογών πελάτη, πλήρως λειτουργικών και έτοιμων προς εκτέλεση. Για την αυτοματοποίηση της διαδικασίας ανάπτυξης εφαρμογών πελάτη, στην παρούσα διπλωματική εργασία, αξιοποιείται η αρχιτεκτονική MDA (Model Driven Architecture), η οποία εντάσσεται στο γενικότερο σύνολο της Μοντελοκεντρικής Μηχανικής (MDE-Model Driven Engineering). Στα πλαίσια της MDA αρχιτεκτονικής, ορίζεται ένα σύνολο από σαφώς ορισμένα πρότυπα και εργαλεία και περιγράφεται μια διαδικασία ανάπτυξης, κατά την οποία, αφού οριστεί ένα αρχικό αφαιρετικό μοντέλο, πραγματοποιείται μια σειρά από μετασχηματισμούς, με τελικό αποτέλεσμα μια πλήρως λειτουργική εφαρμογή. Με αυτό τον τρόπο, επιδιώκεται η επιτάχυνση της διαδικασίας ανάπτυξης λογισμικού και η παραγωγή λογισμικού με μεγαλύτερη αξιοπιστία. Στην παρούσα διπλωματική εργασία, η μηχανή παραγωγής εφαρμογών πελάτη CREATE (Client for RESTful Api Automated Engine) πραγματεύεται την υλοποίηση ενός εργαλείου αυτόματης ανάπτυξης γραφικών διεπαφών χρήστη. Οι διαδικτυακές εφαρμογές πελάτη, που παράγονται αυτόματα από την γεννήτρια, καταναλώνουν RESTful διαδικτυακές υπηρεσίες, οι οποίες έχουν παραχθεί μέσω της πλατφόρμας του S-CASE, διαχειρίζονται την αποστολή CRUD (Create, Read, Update και Delete) αιτημάτων και λαμβάνουν, επεξεργάζονται και παρουσιάζουν τις αποκρίσεις του εξυπηρετητή. Έχουν, επίσης, τη δυνατότητα ταυτοποίησης των χρηστών, αναζήτησης στη βάση δεδομένων και επικοινωνίας με εξωτερικές διαδικτυακές υπηρεσίες. Επίσης, παρέχονται ποιοτικά χαρακτηριστικά γραφικών διεπαφών, όπως αναδυόμενα παράθυρα για την επιβεβαίωση ή ενημέρωση των κινήσεων του χρήστη, μενού πλοήγησης, ενσωμάτωση εικόνων κ.α. Τέλος, παράγονται και αρχεία τεκμηρίωσης του κώδικα για την καλύτερη επεξήγηση του. Ο μηχανισμός που αναπτύχθηκε είναι υλοποιημένος στο JavaScript framework AngularJS. [3]

4 Αυτόματη παραγωγή διεπαφών χρήστη για διαδικτυακές υπηρεσίες τύπου REST Abstract Automatic generation of user interfaces for RESTful web services Over the last decade, the architectural style that has prevailed for the development of web applications is the one introduced in Roy Fielding's Thesis in 2000, the REST architectural style. Since then, thanks to its simplicity and power, the REST architectural style has conquered the field of web applications and is practically dominant as far as web service development is concerned. For this reason, the growing demand and use of REST APIs is accompanied by the tendency to create automated processes that can produce an application that consumes RESTful web services, minimizing the time and cost needed for their development. Many automation tools have been created in recent years, however, many of them are unable to produce ready-to-run applications, and require software developer intervention. This diploma thesis aspires to make the first steps towards the process of automating the development of fully functional and ready-to-run web client applications. In order to automate the process of generating web client applications, in this diploma thesis, MDA architecture (Model Driven Architecture) is employed. MDA defines a set of clearly defined templates and tools, and describes a development process where, once an initial abstract model has been defined, a series of transformations take place, resulting in a fully functional application. This is intended to speed up the process of software development and to generate more reliable software. My diploma thesis, CREATE (Client for RESTful Api Automated Engine), implements an automated graphical user interface development tool. It automatically produces web client applications that consume RESTful web services as generated by the S-CASE, manage CRUD (Create, Read, Update, and Delete) requests and receive, process, and present their responses. These web client applications provide features such as database search, user authentication and communication with external services. Also, graphical interface features are provided such as pop-ups for confirming or updating user movements, navigation menus, image integration, etc. Finally, documentation is produced to better explain the code. The application CREATE is implemented using the AngularJS framework. Maria Kouiroukidou kouirouk@auth.gr Electrical & Computer Engineering Department Aristotle University of Thessaloniki, Greece June 2017 [4]

5 Abstract Πίνακας Περιεχομένων ΕΥΧΑΡΙΣΤΙΕΣ... 2 ΠΕΡΙΛΗΨΗ... 3 ABSTRACT... 4 ΛΙΣΤΑ ΣΧΗΜΑΤΩΝ... 7 ΛΙΣΤΑ ΠΙΝΑΚΩΝ... 9 ΛΙΣΤΑ ΑΛΓΟΡΙΘΜΩΝ... 9 ΛΙΣΤΑ ΕΡΩΤΗΜΑΤΩΝ ΣΥΝΤΟΜΟΓΡΑΦΙΕΣ ΕΙΣΑΓΩΓΗ ΚΙΝΗΤΡΟ ΠΕΡΙΓΡΑΦΗ ΠΡΟΒΛΗΜΑΤΟΣ ΣΤΟΧΟΣ ΤΗΣ ΔΙΠΛΩΜΑΤΙΚΗΣ ΕΡΓΑΣΙΑΣ ΔΙΑΡΘΡΩΣΗ ΚΕΙΜΕΝΟΥ ΘΕΩΡΗΤΙΚΟ ΚΑΙ ΤΕΧΝΟΛΟΓΙΚΟ ΥΠΌΒΑΘΡΟ ΘΕΩΡΗΤΙΚΟ ΥΠΟΒΑΘΡΟ Τεχνολογία Λογισμικού Διαδικτυακές εφαρμογές, διαδικτυακές υπηρεσίες και Web APIs Πρωτόκολλο επικοινωνίας HTTP (Hypertext Transfer Protocol) Διαδικτυακές υπηρεσίες - Web Services Διαδικτυακή Διεπαφή Προγραμματισμού Εφαρμογών - Web Application Programming Interface (API) Representational state transfer (REST) - Richardson s Maturity Model (RΜΜ) Representational state transfer (REST) - Resource-Oriented Architecture (ROA) Richardson s Maturity Model (RMM) Model Driven Engineering Μοντέλα και Μετά-Μοντέλα Meta Object Facility (MOF) Μετασχημτισμοί Model Driven Architecture Επίπεδα MDA Πλεονεκτήματα και μειονεκτήματα της μεθόδου MDE ΤΕΧΝΟΛΟΓΙΚΟ ΥΠΟΒΑΘΡΟ Ecore meta-model Eclipse Modelling Framework (EMF) Object Constraint Language (OCL) Atlas Transformation Language (ATL) Acceleo Model-to-Text transformation language Η πλατφόρμα S-CASE (Scaffolding Scalable Software Services) MVC - Model-View-Controller AngulasJS Semantic UI ΥΠΑΡΧΟΥΣΕΣ ΤΕΧΝΟΛΟΓΙΕΣ ΥΠΑΡΧΟΥΣΕΣ ΤΕΧΝΟΛΟΓΙΕΣ ΓΙΑ ΤΗΝ ΑΥΤΟΜΑΤΟΠΟΙΗΜΕΝΗ ΠΑΡΑΓΩΓΗ ΔΙΑΔΙΚΤΥΑΚΩΝ ΥΠΗΡΕΣΙΩΝ ΤΥΠΟΥ REST...42 [5]

6 Αυτόματη παραγωγή διεπαφών χρήστη για διαδικτυακές υπηρεσίες τύπου REST Ruby on Rails EMF-Rest Django-REST-Framework Laravel PHP Framework REST United APIMATIC ΥΠΑΡΧΟΥΣΕΣ ΤΕΧΝΟΛΟΓΙΕΣ ΓΙΑ ΑΥΤΟΜΑΤΟΠΟΙΗΜΕΝΗ ΠΑΡΑΓΩΓΗ ΕΦΑΡΜΟΓΗΣ ΠΕΛΑΤΗ Swagger Code Generator REST Client Generator AutoRest ΜΕΘΟΔΟΛΟΓΙΑ S-CASE ΓΕΝΙΚΑ ACCELEO ΜΕΤΑΣΧΗΜΑΤΙΣΜΟΣ PSM ΜΟΝΤΕΛΟΥ ΣΕ ΚΩΔΙΚΑ PSM Μοντέλο εισόδου στο σύστημα Στοιχεία PSM Μεταμοντέλου Acceleo Project ΠΑΡΑΓΟΜΕΝΕΣ ΕΦΑΡΜΟΓΕΣ ΠΕΛΑΤΗ Εκτέλεση της μηχανής Επισκόπηση δομής εξόδου και αρχικοποίηση εφαρμογής ΠΑΡΑΔΕΙΓΜΑΤΑ ΕΦΑΡΜΟΓΗΣ ΠΑΡΑΔΕΙΓΜΑ ΕΦΑΡΜΟΓΗΣ RESTBOOKS ΠΑΡΑΔΕΙΓΜΑ ΕΦΑΡΜΟΓΗΣ YUMMY ΣΥΜΠΕΡΑΣΜΑΤΑ ΚΑΙ ΜΕΛΛΟΝΤΙΚΕΣ ΠΡΟΤΑΣΕΙΣ ΒΙΒΛΙΟΓΡΑΦΙΑ ΠΑΡΑΡΤΗΜΑ (Α) ΠΑΡΑΡΤΗΜΑ (Β) [6]

7 Λίστα Σχημάτων Λίστα Σχημάτων Σχήμα 1: Ραγδαία αύξηση του αριθμού των διαδικτυακών API's Σχήμα 2: Οι χρησιμοποιούμενες τεχνολογίες για την ανάπτυξη διαδικτυακών APIs [4] Σχήμα 3: Διαδικτυακή υπηρεσία REST σύμφωνα με το RMM Σχήμα 4: Ο ορισμός του συστήματος Σχήμα 5: Ο ορισμός του μοντέλου. Σχέση μεταξύ συστήματος και μοντέλου Σχήμα 6: Η αρχιτεκτονική MOF Σχήμα 7: Μετασχηματισμός μοντέλου Σχήμα 8: Επίπεδα MDA Σχήμα 9: Αδυναμίες της MDE τεχνολογίας Σχήμα 10: Θετικές και αρνητικές επιδράσεις της τεχνολογίας MDE Σχήμα 11: Ecore Μετά-μοντέλο Σχήμα 12: Το EMF ενοποιεί UML, XML και Java Σχήμα 13: Μετασχηματισμός μοντέλου σε ATL Σχήμα 14: Acceleo Model To Text μετασχματισμός Σχήμα 15:Παράδειγμα πρότυπου Acceleo Σχήμα 16: Παράδειγμα δομής ενός acceleo project Σχήμα 17: Οι διασυνδέσεις μεταξύ των επιπέδων του μοτίβου MVC και του χρήστη Σχήμα 18: Βασική αρχιτεκτονική Rails Σχήμα 19: EMF-Rest επισκόπηση Σχήμα 20: Αριστερά: Παράδειγμα απόκρισης σε JSON Σχήμα 21: Αριστερά: Django-REST-Framework serializers Σχήμα 22: Μια τυπική διαδικτυακή εφαρμογή Laravel: Σχήμα 23: Οι 4 φάσεις της δισδιάστατης μοντελοστραφούς σχεδίασης Σχήμα 24: Υλοποίηση αυτοματοποιημένης παραγωγής εφαρμογής πελάτη και η σχέση του με το S-CASE Σχήμα 25: RESTfulServicePSM Σχήμα 26: Authentication PSM Σχήμα 27: Database Searching PSM Σχήμα 28: External Service Composition PSM Σχήμα 29: GUI Eclipse Plugin Σχήμα 30: Δομή παραγόμενης εφαρμογής πελάτη [7]

8 Αυτόματη παραγωγή διεπαφών χρήστη για διαδικτυακές υπηρεσίες τύπου REST Σχήμα 31: Σχεδιάγραμμα του RESTBooks API Σχήμα 32: Αρχική σελίδα RESTBooks Σχήμα 33: Δημιουργία νέου στιγμιότυπου book Σχήμα 34: Εμφάνιση των πόρων που είναι σχετικοί από πόρο και των λεπτομερειών Σχήμα 35: Μήνυμα επιβεβαίωσης για την διαγραφή Σχήμα 36: Εμφάνιση αποτελεσμάτων αναζήτησης Σχήμα 37: Επεξήγηση διαγραμμάτων που αφορούν την αναπαράσταση των πόρων της εφαρμογής Σχήμα 38: Οι πόροι και οι επιτρεπτές HTTP μέθοδοι για το Yummy APi Σχήμα 39: Πόροι του Yummy API υπεύθυνοι για την αναζήτηση στην βάση δεδομένων και την επικοινωνία με εξωτερικές υπηρεσίες Σχήμα 40: Αρχική σελίδα Σχήμα 41:Εμφάνιση της απόκρισης για το αίτημα GET Σχήμα 42: Εμφάνιση της απόκρισης για το αίτημα GET - recipe. Ο χρήστης έχει κάνει login Σχήμα 43: Φόρμα δημιουργίας νέου στιγμιότυπου - POST Σχήμα 44: Μήνυμα επιβεβαίωσης διαγραφής στιγμιότυπου Σχήμα 45: Φόρμα δημιουργίας user POST Σχήμα 46: Φόρμα για την υλοποίηση του authentication Σχήμα 47: Μήνυμα αποτυχίας ταυτοποίησης Σχήμα 48: Αποτελέσματα αναζήτησης με μία επιλογή Σχήμα 49: Λίστα αποτελεσμάτων αναζήτησης με πολλαπλές επιλογές Σχήμα 50: Εμφάνιση αποτελεσμάτων από την κλίση στην εξωτερική υπηρεσία BigMaps Σχήμα 51: Εμφάνιση αποτελεσμάτων από την κλίση στην εξωτερική υπηρεσία currencylayer Σχήμα 52: Εκτίμηση αποτελεσμάτων Σχήμα 53: Τμήμα παραγόμενου κώδικα του ελεγκτή SigninController Σχήμα 54: Τμήμα του κώδικα της συνάρτηση searchfn του ελεγκτή SearchRecipeController Σχήμα 55: Τμήμα κώδικα του mapgeocoding.controller..js για την επικοινωνία με την εφαρμογή BigMaps 120 Σχήμα 56: Τμήμα του currencyconverter για την ανάκτηση της απόκρισης από την εξωτερική υπηρεσία currencylyaer Σχήμα 57: Τμήμα του searchrecipe.html για εμφάνιση επιλογών αναζήτησης - checkboxes - και εμφάνιση λίστας αποτελεσμάτων [8]

9 Λίστα Πινάκων Λίστα Πινάκων Πίνακας 1 Μέθοδοι HTTP Πίνακας 2: Βασικές Τεχνολογίες των Web Services Πίνακας 3: Υποστηριζόμενα Media Types Πίνακας 4: Τύποι HTTPVerb Πίνακας 5: Ιδιότητες RESTfulServicePSM στοιχείου Πίνακας 6: Σχέσεις του RESTfulServicePSM Πίνακας 7: Περιγραφή Αλγορίθμου Πίνακας 8: Περιγραφή Αλγορίθμου Πίνακας 9: Περιγραφή Αλγορίθμου Πίνακας 10: Περιγραφή Αλγορίθμου Πίνακας 11: Περιγραφή Αλγορίθμου Πίνακας 12: Περιγραφή Αλγορίθμου Πίνακας 13: Ερωτήματα που χρησιμοποιούνται στο module views Πίνακας 14: Περιγραφή Αλγορίθμου Πίνακας 15: Περιγραφή Αλγορίθμου Πίνακας 16: Ερωτήματα που χρησιμοποιούνται στο module controllers Πίνακας 17: Ερωτήματα που χρησιμοποιούνται στο module services Πίνακας 18: Περιγραφή Αλγορίθμου Πίνακας 19: Περιγραφή Αλγορίθμου Πίνακας 20: Ερωτήματα που χρησιμοποιούνται στο module Auth Πίνακας 21: Περιγραφή Αλγορίθμου Πίνακας 22: Περιγραφή Αλγορίθμου Πίνακας 23: Περιγραφή Αλγορίθμου Πίνακας 24: Ερωτήματα που χρησιμοποιούνται στο module Search Πίνακας 25: Περιγραφή Αλγορίθμου Πίνακας 26: Περιγραφή Αλγορίθμου Πίνακας 27: Ερωτήματα που χρησιμοποιούνται στο module ExternalService Πίνακας 28: Αίτημα GET για ανάκτηση λίστας πόρους και των ιδιοτήτων Πίνακας 29: Αίτημα POST στον πόρο book - σχετικό του library [9]

10 Αυτόματη παραγωγή διεπαφών χρήστη για διαδικτυακές υπηρεσίες τύπου REST Πίνακας 30: Ανάκτηση στιγμιότυπων του πόρου που είναι σχετικό από άλλο πόρο και εμφάνιση των ιδιοτήτων του Πίνακας 31: Αίτημα διαγραφής ενός στιγμιότυπου του πόρου Πίνακας 32: Αίτημα GET για αναζήτηση στην βάση δεδομένων Πίνακας 33: Αίτημα GET στον πόρο με ή χωρίς ταυτοποίηση Πίνακας 34: Αίτημα GET σε στιγμιότυπο πόρου Πίνακας 35: Αίτημα POST σε πόρο Πίνακας 36: Αίτημα DELETE Πίνακας 37: Αίτημα POST Πίνακας 38: Αίτημα GET με authentication Πίνακας 39: Αίτημα GET με query parameters για αναζήτηση στην βάση δεδομένων (1) Πίνακας 40: Αίτημα GET με query parameters για αναζήτηση στην βάση δεδομένων (2) Πίνακας 41: Αίτημα GET για την επικοινωνία με την εξωτερική υπηρεσία BigMaps Πίνακας 42: Αίτημα GET για την επικοινωνία με την εξωτερική υπηρεσία currencylayer [10]

11 Λίστα Αλγορίθμων Λίστα Αλγορίθμων Αλγόριθμος 1: Έλεγχος πλήθους πόρων για τον ορισμό των ελεγκτών στην λίστα των scripts Αλγόριθμος 2: Έλεγχος για την ύπαρξη ή όχι ταυτοποίησης χρήστη Αλγόριθμος 3: Δημιουργία dropdown menu για την λειτουργία της αναζήτησης Αλγόριθμος 4: Αναπαράσταση ιδιοτήτων πόρου - εμφάνιση ιδιότητας image Αλγόριθμος 5: Αναπαράσταση ιδιοτήτων πόρου για κάθε πιθανό τύπο Αλγόριθμος 6: Έλεγχος του τύπου ιδιότητας του πόρου για ορθή εισαγωγή στοιχείων στην φόρμα Αλγόριθμος 7: Έλεγχος ύπαρξης αιτήματος DELETE στον πόρο και εμφάνιση αντίστοιχης μορφοποίησης Αλγόριθμος 8: Ανάκτηση πόρων για την δημιουργία HTTP αιτημάτων - GET Αλγόριθμος 9: Ανάκτηση πόρων για την δημιουργία HTTP αιτημάτων - DELETE Αλγόριθμος 10: Ανάκτηση πόρων σχετικών από τον πόρο Αλγόριθμος 11: 'Έλεγχος ύπαρξης δυνατότητας authentication και υλοποίηση CRUD αιτημάτων Αλγόριθμος 12: Ανάθεση URI στις αντίστοιχες σταθερές Αλγόριθμος 13: Ανάκτηση ιδιοτήτων υπεύθυνων για ταυτοποίηση χρήστη Αλγόριθμος 14: Ανάκτηση πόρων βάση των οποίων γίνεται αναζήτηση κι ιδιοτήτων αυτών Αλγόριθμος 15: Ανάκτηση πόρων προς εμφάνιση αποτελεσμάτων Αλγόριθμος 16:: Εμφάνιση των λεπτομερειών των πόρων που αναζητήθηκαν με βάση μία ιδιότητα Αλγόριθμος 17: Επικοινωνία με εξωτερική υπηρεσία - αίτημα GET - με παραμέτρους Αλγόριθμος 18: Ανάκτηση ιδιοτήτων από την απόκριση ενός αιτήματος σε μια εξωτερική υπηρεσία [11]

12 Αυτόματη παραγωγή διεπαφών χρήστη για διαδικτυακές υπηρεσίες τύπου REST Λίστα Ερωτημάτων Ερώτημα 1: getmainresources Ερώτημα 2: relatedresource Ερώτημα 3: getauthenticationperfomer Ερώτημα 4: hasbothmodeauthentication Ερώτημα 5: getauthenticationlayerbothmodeannotations Ερώτημα 6: getsearchcontrollerannotations Ερώτημα 7: getsearchableresources Ερώτημα 8: getsearchhttphandler Ερώτημα 9: getsearchhttphandlerannotations Ερώτημα 10: getjavarestclientcontrollerannotations Ερώτημα 11: getqueryparams Ερώτημα 12: getjavarestclienthttpactivity [12]

13 Συντομογραφίες Συντομογραφίες HTTP: Hypertext Transfer Protocol JSON: JavaScript Object Notation (Τύπος media format) API: Application Programming Interface ATL: Atlas Transformation Language (a declarative M2M transformation language) CIM: Computational Independent Model CSS: Cascading Styling Sheets EMF: Eclipse Modelling Framework HTTP: Hypertext Transfer Protocol M2M: Model to Model transformation MDA: Model Driven Architecture MDE: Model Driven Engineering MOF: Meta-Object Facility MVC: Model-View-Controller design pattern OCL: Object Constraint Language OMG: Object Management Group PIM: Platform Independent Model PSM: Platform Specific Model REST: Representational State Transfer RMM: Richardson Maturity Model URI: Uniform Resource Identifier URL: Uniform Resource Locator XMI: XML Metadata Interchange XML: Extensible Markup Language [13]

14 Αυτόματη παραγωγή διεπαφών χρήστη για διαδικτυακές υπηρεσίες τύπου REST 1 Εισαγωγή 1.1 Κίνητρο Με την εμφάνιση οποιουδήποτε νέου μέσου επικοινωνίας, η κοινωνία και οι δομές της, αναμφισβήτητα, επηρεάζονται. Η επίδραση αυτή πηγάζει κυρίως από την τεχνολογία του νέου μέσου. Είναι πλέον εμφανές πως το διαδίκτυο, ως ένα από τα πλέον πιο σημαντικά μέσα επικοινωνίας στον σύγχρονο κόσμο, έχει διεισδύσει σε κάθε γωνιά της υφηλίου. Η τεχνολογία λογισμικού από την άλλη, ως γνωστό αντικείμενο, έχει ως στόχο τη βέλτιστη ανάπτυξη συστημάτων λογισμικού και έχει ως βασικό χαρακτηριστικό ότι συνδυάζει αρχές και γνώσεις από άλλα γνωστικά αντικείμενα. Λίγοι θα διαφωνήσουν με τη θέση ότι το λογισμικό αποτέλεσε ένα από τα σημαντικότερα εργαλεία, που ο άνθρωπος κατασκεύασε τον αιώνα που πέρασε, χάρη στο οποίο έγινε δυνατή η επανάσταση της πληροφορικής και των επικοινωνιών, την οποία ακόμη βιώνουμε. Είναι αλήθεια ότι πολλοί άνθρωποι έχουν έρθει εκούσια ή ακούσια στη θέση του χρήστη μίας ή περισσότερων εφαρμογών λογισμικού, ωστόσο δεν είναι αυτονόητο ότι όλοι αντιλαμβάνονται το λογισμικό ως ένα μοναδικό τεχνικό κατασκεύασμα. Ο αυτοματισμός είναι µία σπουδαία πτυχή της ανάπτυξης λογισμικού. Η Οδηγούμενη από Μοντέλα Μηχανική είναι ένα νέο παράδειγμα ανάπτυξης λογισμικού, που προτείνει μία διαδικασία ανάπτυξης λογισμικού βασισμένη σε µετασχηµατισµούς μοντέλων μεταξύ των διαφορετικών φάσεων ανάπτυξης. Η αυξανόμενη ανάγκη για την ανάπτυξη νέων διαδικτυακών APIs και η υιοθέτηση, ως ένα βαθμό, εργαλείων για την αυτοματοποιημένη παραγωγή διαδικτυακών υπηρεσιών, ωθούν και στην ανάπτυξη εργαλείων για την αυτοματοποιημένη παραγωγή εφαρμογών πελάτη, που θα καταναλώνουν αυτές τις υπηρεσίες. Ωστόσο, αυτή τη στιγμή δεν υπάρχουν τεχνολογίες, που να μπορούν να παράξουν εφαρμογές πελάτη, έτοιμες προς κατανάλωση, πόσο μάλλον, εφαρμογές πελάτη, που να παράγονται απευθείας από το μοντέλο της επιθυμητής προς κατανάλωση υπηρεσίας. 1.2 Περιγραφή Προβλήματος Τα διαδικτυκά APΙs δεν αποτελούν μια καινούρια τεχνολογία, αλλά λειτουργούν στο διαδίκτυο πάνω από μια δεκαετία. Τα τελευταία όμως χρόνια είναι που υπήρξε ραγδαία ανάπτυξη στον τομέα, όχι μόνο σε αριθμό ή στην αύξηση των χρηστών, αλλά και σε επίπεδο πολυπλοκότητας και λειτουργιών που καλύπτουν. [14]

15 Εισαγωγή Το Forrester 1 καλεί το API την ψηφιακή κόλλα που κρατά τον κόσμο μας ενωμένο. Το Forbes λέει ότι είναι το κλειδί για την απελευθέρωση της ψηφιακής οικονομίας [1], ενώ το TechCrunch προβλέπει ότι θα ξεκλειδώσει την οικονομία των δεδομένων [2]. Ο ιστότοπος programmableweb.com ιδρύθηκε το 2005 και από τότε καταγράφει την εξέλιξη της «οικονομίας των Web APIs», παρέχοντας πληροφορίες, στατιστικές και αρθρογραφία σχετικά με το αντικείμενο. Ο ίδιος αναφέρει πως μόνο το 2015 καταχωρήθηκαν στην βάση του πάνω από 2000 νέα APIs και αυτή τη στιγμή ξεπερνούν τις Στο παρακάτω διάγραμμα μπορούμε να δούμε την ραγδαία αύξηση των διαδικτυακών APIs στο χρονικό διάστημα 2006 με 2016 [3] Σχήμα 1: Ραγδαία αύξηση του αριθμού των διαδικτυακών API's Μια άλλη στατιστική που παρουσιάστηκε αναφέρει τα ποσοστά που κατέχουν οι διάφορες προσεγγίσεις στην ανάπτυξη API και τον κυρίαρχο ρόλο που παίζουν αυτή τη στιγμή τα RESTful APIs στις διαδικτυακές εφαρμογές [4]. 1 Η Forrester είναι μια αμερικανική ερευνητική εταιρεία που παρέχει συμβουλές σχετικά με τις υπάρχουσες και τις πιθανές επιπτώσεις της τεχνολογίας, στους πελάτες της και το κοινό. [15]

16 Αυτόματη παραγωγή διεπαφών χρήστη για διαδικτυακές υπηρεσίες τύπου REST Τεχνολογία REST SOAP Other 10% 6% 84% Σχήμα 2: Οι χρησιμοποιούμενες τεχνολογίες για την ανάπτυξη διαδικτυακών APIs Οι ολοένα και αυξανόμενες ανάγκες της σύγχρονης εποχής, τόσο όσον αφορά στην πολυπλοκότητα των προβλημάτων που καλούμαστε να λύσουμε, όσο και στο μέγεθος των εφαρμογών, αποτελούν επιτακτική ανάγκη για την συνεχή ανάπτυξη νέων εργαλείων που να καθιστούν την ανάπτυξη λογισμικού αποδοτικότερη ως προς τον χρόνο, το κόστος και την δυνατότητα κατανόησης, συντήρησης και επαναχρησιμοποίησης του προγράμματος. 1.3 Στόχος της διπλωματικής Εργασίας Στόχος της παρούσας διπλωματικής εργασίας είναι η δημιουργία ενός εργαλείου που θα παρέχει αυτόματα γραφικές διεπαφές πλήρως προσαρμόσιμες στη δομή ενός RESTful API, το οποίο έχει παραχθεί μέσω της πλατφόρμας του S-CASE, δηλαδή μιας διαδικτυακής υπηρεσίας που υπακούει στην αρχιτεκτονική REST, καθώς αυτή αποτελεί σήμερα την επικρατέστερη επιλογή σχεδίασης. Για τον σκοπό αυτό, αξιοποιήθηκε η θεωρία της τεχνολογίας λογισμικού και συγκεκριμένα η αρχιτεκτονική MDA (Model Driven Architecture). Η παραγόμενη εφαρμογή πελάτη σχεδιάστηκε με τρόπο ώστε να πληροί συγκεκριμένες ενέργειες και δυνατότητες. Συνοπτικά, οι παραγόμενες εφαρμογές πελάτη θα πρέπει να είναι έτοιμες προς εκτέλεση και θα πρέπει να υποστηρίζουν CRUD αιτήματα και αποκρίσεις, ταυτοποίηση (authentication), αναζήτηση στη βάση δεδομένων (Database Searching) και επικοινωνία της διαδικτυακής εφαρμογής με άλλες, εξωτερικές, εφαρμογές (External Compositions). [16]

17 Εισαγωγή 1.4 Διάρθρωση Κειμένου Στο κεφάλαιο 2 γίνεται περιγραφή του θεωρητικού και τεχνολογικού υποβάθρου βάσει της τρέχουσας βιβλιογραφίας. Συγκεκριμένα, αναλύονται οι έννοιες της διαδικτυακής υπηρεσίας και της διαδικτυακής εφαρμογής και περιγράφεται λεπτομερώς η αρχιτεκτονική σχεδίασης τύπου REST και το πρότυπο ωρίμανσης RMM. Στην πορεία του κεφαλαίου περιγράφεται η MDA αρχιτεκτονική και η Οδηγούμενη από Μοντέλα Μηχανική (MDE). Στο κεφάλαιο 3 γίνεται μία συνοπτική παρουσίαση των υπαρχουσών τεχνολογιών για την ανάπτυξη αυτοματοποιημένων διαδικασιών για την παραγωγή διαδικτυακών υπηρεσιών που βασίζονται στο REST αρχιτεκτονικό στυλ και διαδικτυακών εφαρμογών. Στο κεφάλαιο 4 γίνεται μία συνοπτική περιγραφή της λειτουργίας της πλατφόρμας του S-CASE, πάνω στην οποία στηρίχτηκε η παρούσα διπλωματική εργασία. Ακολούθως, παρουσιάζονται τα PSM μεταμοντέλα, που αποτελούν την είσοδο στο σύστημα μας, καθώς και η διεργασία για την παραγωγή του κώδικα της διαδικτυακής εφαρμογής, μέσω του μετασχηματισμού M2T και τη χρήση της Acceleo. Τέλος, γίνεται περιγραφή του αποτελέσματος της αυτόματης παραγωγής, της δομής του και του τρόπου εγκατάστασης του. Στο κεφάλαιο 5 παρουσιάζονται δύο παραδείγματα διαδικτυακών εφαρμογών που παρήχθησαν από την μηχανή και παρατίθενται σχήματα απεικόνισης των διεπαφών που δημιουργούνται. Στο κεφάλαιο 6 παρουσιάζονται τα στατιστικά αποτελέσματα και τα συμπεράσματα της παρούσας διπλωματικής εργασίας. Στο Παράρτημα Α παρουσιάζονται και επεξηγούνται όλα τα ερωτήματα, τμήματα κώδικα, που αναπτύχθηκαν στο μοντέλο εισόδου για τον σκοπό της παρούσας διπλωματικής εργασίας. Στο Παράρτημα Β παρουσιάζονται ενδεικτικά τμήματα του παραγόμενου κώδικα της αυτόματης διαδικασίας παραγωγής της διαδικτυακής εφαρμογής. [17]

18 Αυτόματη παραγωγή διεπαφών χρήστη για διαδικτυακές υπηρεσίες τύπου REST 2 Θεωρητικό και Τεχνολογικό Υπόβαθρο Στο κεφάλαιο αυτό, θα γίνει αναφορά σε όλο το θεωρητικό και τεχνολογικό υπόβαθρο που χρειάζεται κανείς για να συνεχίσει την ανάγνωση της παρούσας διπλωματικής εργασίας. Θα αναλυθούν, τόσο θεωρητικά στοιχεία, όσο και τεχνολογίες που χρησιμοποιήθηκαν, ώστε να καταστεί ευκολότερη η κατανόηση του κειμένου από τον αναγνώστη. 2.1 Θεωρητικό Υπόβαθρο Τεχνολογία Λογισμικού Το λογισμικό είναι ένα σύνθετο τεχνικό κατασκεύασμα που προορίζεται στο να συμβάλλει στην αυτοματοποίηση επίπονων και επιρρεπών σε σφάλματα ανθρώπινων εργασιών µε τη βοήθεια ηλεκτρονικού υπολογιστή. Ως λογισμικό δεν νοείται µόνο ο εκτελέσιμος κώδικας, αλλά και ένα σύνολο ενδιάμεσων προϊόντων, όπως προδιαγραφές, σχέδια, πηγαίος κώδικας, εκθέσεις ελέγχου κ.ά. Όλα αυτά αποτελούν παράγωγα προϊόντα του κύκλου ζωής του λογισμικού, ο οποίος περιλαμβάνει όλες τις φάσεις, από τη σύλληψη της ιδέας, μέχρι και την απόσυρση μιας εφαρμογής λογισμικού από τη χρήση. Παρά τη σημαντική πρόοδο που έχει επιτευχθεί στον τομέα του υλικού των υπολογιστών, η κατασκευή του λογισμικού παρουσιάζει ορισμένα χρόνια σημαντικά προβλήματα, που σχετίζονται µε την ποιότητα, το κόστος και τη γενική επάρκεια του τρόπου µε τον οποίο αυτή γίνεται. Τα προβλήματα αυτά αναφέρονται γενικά ως κρίση λογισμικού (Software crisis). Η Τεχνολογία Λογισμικού είναι η περιοχή εκείνη της επιστήμης της μηχανικής που ασχολείται µε την εύρεση και θεμελίωση μεθόδων για να περιγράφεται, να κατασκευάζεται και να συντηρείται λογισμικό καλής ποιότητας µε τη μεγαλύτερη δυνατή αυτοματοποίηση και παραγωγικότητα και το ελάχιστο δυνατό κόστος. Η Τεχνολογία Λογισμικού δεν είναι μία θεωρητική επιστήμη, αλλά στοχεύει στην υποστήριξη των κατασκευαστών να παραγάγουν καλά προϊόντα λογισμικού. Τα προϊόντα αυτά αντιμετωπίζονται ως αναπόσπαστα τμήματα του ειδικότερου και ευρύτερου πεδίου χρήσης αυτών, από το οποίο επηρεάζονται και το οποίο επηρεάζουν. [18]

19 Θεωρητικό και Τεχνολογικό Υπόβαθρο Διαδικτυακές εφαρμογές, διαδικτυακές υπηρεσίες και Web APIs Μια από τις σημαντικότερες τεχνολογίες που άλλαξαν ριζικά το τοπίο στην ανάπτυξη λογισμικού τις τελευταίες δύο δεκαετίες αποτελεί το διαδίκτυο (Internet). Τα θεμέλια για το διαδίκτυο και τον παγκόσμιο ιστό, όπως τον γνωρίζουμε σήμερα, σχεδιάστηκαν και υλοποιήθηκαν από τον Tim Berners-Lee την δεκαετία του 90, όπου εργάζονταν ως ερευνητής στο CERN. Βασικό κίνητρο αποτέλεσε η δημιουργία ενός εύχρηστου διανεμημένου συστήματος για τη διανομή εγγράφων. Σήμερα τo διαδίκτυο είναι ένα παγκόσμιο δίκτυο, που συνενώνει πολλά ετερογενή δίκτυα, καλύπτει σχεδόν το σύνολο του παγκόσμιου χάρτη, διασυνδέοντας σε φυσικό επίπεδο και παρέχοντας τις υπηρεσίες του σε έναν τεράστιο αριθμό χρηστών. Είναι προφανές πως είναι δύσκολο να παρακολουθήσει κανείς τις νέες τεχνολογίες που εμφανίζονται συνεχώς. Παρόλα αυτά είναι σημαντικό να προσδιοριστούν ορισμένα βασικά στοιχεία που αφορούν το πρωτόκολλο επικοινωνίας HTTP του διαδικτύου, τις διαδικτυακές υπηρεσίες και εφαρμογές, καθώς και τις βασικές αρχιτεκτονικές που χρησιμοποιούνται Πρωτόκολλο επικοινωνίας HTTP (Hypertext Transfer Protocol) Το Πρωτόκολλο Μεταφοράς Υπερκειμένου (Hyper Τext Transfer Protocol / HTTP) είναι το βασικό πρωτόκολλο για την ανταλλαγή πληροφορίας μέσω του παγκόσμιου ιστού. Το HTTP υποστηρίζει τη μεταφορά αρχείων αποθηκεμένων σε διακομιστές διαδικτύου (Web Server) προς το φυλλομετρητή (Web Browser) που χρησιμοποιεί ένας χρήστης. Τα αρχεία αυτά έχουν κωδικοποιηθεί με τη Γλώσσα Σημείωσης Υπερκειμένου (HTML). Το HTTP είναι ένα πρωτόκολλο που εξελίσσεται συνεχώς και μπορεί να μεταδώσει πολλών ειδών δεδομένα, όπως απλό κείμενο, εικόνες, υπερκείμενο κτλ. Προκειμένου να επιτυγχάνει χαμηλό χρόνο απόκρισης, σχεδιάστηκε ως ένα πρωτόκολλο χωρίς μνήμη (Stateless Protocol), δηλαδή δεν διατηρεί καμία πληροφορία για μια σύνδεση (Session) μετά τη διεκπεραίωση της σχετικής αίτησης (Request). Βασική λειτουργία του HTTP είναι η χρήση του μοντέλου πελάτη-εξυπηρετητή (Client-Server), σύμφωνα με το οποίο ο πελάτης (client) δημιουργεί μια σύνδεση με τον εξυπηρετητή (Server) και στη συνέχεια του αποστέλλει μια αίτηση, η οποία περιέχει τη μέθοδο που επιθυμεί να εφαρμοστεί, οι οποίες αναφέρονται στον Πίνακας 1, ένα ομοιόμορφο αναγνωριστικό πόρου( Universal Resource Identifier -URI), που περιγράφει τον πόρο στον οποίο θα εφαρμοστεί η παραπάνω μέθοδος, την έκδοση του χρησιμοποιούμενου πρωτοκόλλου και ένα μήνυμα σε μορφή Multipurpose Internet Mail Extensions (MIME), που περιλαμβάνει πληροφορίες σχετικά με τον client. [19]

20 Αυτόματη παραγωγή διεπαφών χρήστη για διαδικτυακές υπηρεσίες τύπου REST Πίνακας 1 Μέθοδοι HTTP Μέθοδος GET PUT POST DELETE Περιγραφή μεθόδου Ορίζει την ανάκτηση των πληροφοριών που αναφέρονται στο URI της αίτησης. Εάν αυτό υποδεικνύει επεξεργασία δεδομένων, τότε επιστρέφονται και τα δεδομένα που προέκυψαν από τη σχετική διαδικασία Αίτηση αποθήκευσης μιας ιστοσελίδας Προσάρτηση σε αναφερθέντα πόρο: Υποδεικνύει στον server να δεχτεί την οντότητα που μεταφέρεται στην αίτηση σαν ένα νέο στιγμιότυπο (εγγραφή, καταχώρηση) του πόρου που προσδιορίζεται από το URI Διαγραφή του πόρου, που ορίζεται από το ομοιόμορφο αναγνωριστικό πόρου (URI) Ο Server από την άλλη απαντά με ένα μήνυμα, το οποίο περιέχει μια γραμμή κατάστασης με την έκδοση του πρωτοκόλλου και κωδικό επιτυχίας ή αποτυχίας, ένα μήνυμα σε μορφή MIME, που περιλαμβάνει πληροφορίες για τον Server και, πιθανώς, το σώμα του μηνύματος. Οι κωδικοί απόκρισης κατάστασης χρησιμοποιούνται για να ενημερώσουν τον πελάτη για το αποτέλεσμα του αιτήματός του. Είναι ένας τριψήφιος ακέραιος, στον οποίο το πρώτο ψηφίο του κώδικα κατάστασης ορίζει την κλάση απόκρισης και τα δύο τελευταία ψηφία δεν έχουν κανένα ρόλο κατηγοριοποίησης. Υπάρχουν 5 τιμές για το πρώτο ψηφίο: 1xx: Πληροφοριακό: Αυτό σημαίνει ότι το αίτημα έχει παραληφθεί και η διαδικασία συνεχίζεται. 2xx: Επιτυχία: Σημαίνει ότι η δράση λήφθηκε με επιτυχία, έγινε κατανοητή και έγινε αποδεκτή. 3xx: Ανακατεύθυνση: Σημαίνει ότι πρέπει να ληφθούν περαιτέρω μέτρα για την ολοκλήρωση της αίτησης. 4xx: Σφάλμα πελάτη: Αυτό σημαίνει ότι το αίτημα περιέχει λανθασμένη σύνταξη ή δεν μπορεί να ικανοποιηθεί. 5xx: Σφάλμα διακομιστή: Σημαίνει ότι ο διακομιστής δεν κατάφερε να εκπληρώσει ένα προφανώς έγκυρο αίτημα [5] Διαδικτυακές υπηρεσίες - Web Services Η επόμενη γενιά των κατανεμημένων συστημάτων πληροφορικής έχει φτάσει. Μια διαδικτυακή υπηρεσία (web service) μπορούμε να πούμε ότι είναι, σε γενικές γραμμές, μια μονάδα του διαχειριζόμενου κώδικα, που [20]

21 Θεωρητικό και Τεχνολογικό Υπόβαθρο μπορεί να επικαλεστεί από απόσταση χρησιμοποιώντας HTTP, δηλαδή, μπορεί να ενεργοποιηθεί με τη χρήση αιτημάτων HTTP. Υπάρχουν πολλοί ορισμοί για το τι είναι διαδικτυακή υπηρεσία, όσοι περίπου και οι εταιρίες πληροφορικής, που αναπτύσσουν εργαλεία για τα Web Services. Ένας πολύ καλός ορισμός έρχεται από την IBM: «Τα Web Services είναι μια τεχνολογία που επιτρέπει στις εφαρμογές να επικοινωνούν μεταξύ τους ανεξαρτήτως πλατφόρμας και γλώσσας προγραμματισμού. Ένα Web Service είναι μια διεπαφή λογισμικού (Software interface) που περιγράφει μια συλλογή από λειτουργίες οι οποίες μπορούν να προσεγγιστούν από το δίκτυο μέσω πρότυπων μηνυμάτων XML. Χρησιμοποιεί πρότυπα βασισμένα στη γλώσσα XML, για να περιγράψει μία λειτουργία (operation) προς εκτέλεση και τα δεδομένα προς ανταλλαγή, με κάποια άλλη εφαρμογή. Μια ομάδα από Web Services, οι οποίες αλληλοεπιδρούν μεταξύ τους, καθορίζει μια εφαρμογή Web Services.» H Microsoft μέσα από το MSDN 2 της καταλήγει ότι όλα τα Web Services έχουν τρία κοινά χαρακτηριστικά: I. Τα Web Services εκθέτουν χρήσιμη λειτουργικότητα σε χρήστες του διαδικτύου μέσα από ένα πρότυπο δικτυακό πρωτόκολλο. Στις περισσότερες περιπτώσεις αυτό το πρωτόκολλο είναι το SOAP II. III. (Simple Object Access Protocol). Τα Web Services παρέχουν έναν τρόπο να περιγράψουν τις διεπαφές τους, με αρκετή λεπτομέρεια, ώστε να επιτρέψουν στο χρήστη τους να χτίσει μια εφαρμογή πελάτη, η οποία να επικοινωνήσει μαζί τους. Η περιγραφή συνήθως παρέχεται σε ένα έγγραφο XML, το οποίο ονομάζεται έγγραφο WSDL (Web Services Description Language). Τα Web Services καταχωρούνται, ώστε οι δυνητικοί χρήστες να μπορούν να τα βρουν εύκολα. Αυτό γίνεται με το UDDI (Universal Discovery Description and Integration). Οι βασικές τεχνολογίες στις οποίες βασίζονται τα web services συνοψίζονται στον παρακάτω πίνακα: Πίνακας 2: Βασικές Τεχνολογίες των Web Services Επίπεδο Τεχνολογία Περιγραφή Ομοιόμορφος ορισμός και ανταλλαγή δεδομένων XML Η Extended Markup Language (XML) είναι μια μέτα-γλώσσα (περιγραφική γλώσσα) η οποία έχει καλή καθορισμένη σύνταξη και σημασιολογία. 2 Microsoft Developer Network: είναι το τμήμα της Microsoft που είναι υπεύθυνο για τη διαχείριση των σχέσεων της επιχείρησης με τους προγραμματιστές και τους δοκιμαστές. [21]

22 Αυτόματη παραγωγή διεπαφών χρήστη για διαδικτυακές υπηρεσίες τύπου REST Πρότυπο κανάλι επικοινωνίας SOAP Το Simple Object Access Protocol (SOAP) είναι το κανάλι που χρησιμοποιείται για επικοινωνία μεταξύ μιας εφαρμογής - προμηθευτή web services και μιας εφαρμογής-πελάτη. Η απλότητα του SOAP είναι το ότι δεν καθορίζει κανένα νέο πρωτόκολλο μεταφοράς. Πρότυπη περιγραφική γλώσσα για την περιγραφή των παρεχόμενων υπηρεσιών WSDL Οι εφαρμογές που παρέχουν web services διαφημίζουν τις διάφορες υπηρεσίες που παρέχουν χρησιμοποιώντας μια πρότυπη περιγραφική γλώσσα που ονομάζεται Web Services Description Language (WSDL). Καταχώρηση και εντοπισμός των παρεχόμενων υπηρεσιών UDDI Ο «χρυσός οδηγός» των web services είναι το Universal Description Discovery and Integration (UDDI). Οι εφαρμογές που παρέχουν web services παρατίθενται σε ένα κατάλογο από πάροχους υπηρεσιών χρησιμοποιώντας το UDDI. Η παραπάνω τεχνολογία παρουσίασε σημαντικά προβλήματα όσο αυξανόταν η πολυπλοκότητα των συστημάτων προς υλοποίηση και δέχτηκε αρνητική κριτική. Για τον λόγο αυτό, ξεκίνησε η εξάπλωση των Web APIs, που σε συνδυασμό με την εισαγωγή του REST αρχιτεκτονικού στυλ, το οποίο θα εξεταστεί στην συνέχεια, αποτελούν μια πιο δομημένη, απλή και κατανοητή, αλλά ταυτόχρονα ισχυρή προσέγγιση στην ανάπτυξη διαδικτυακών εφαρμογών Διαδικτυακή Διεπαφή Προγραμματισμού Εφαρμογών - Web Application Programming Interface (API) Μια γενική διατύπωση του ρόλου των διαδικτυακών επαφών προγραμματισμού εφαρμογών, από την πλευρά του διακομιστή, είναι πως αποτελούν μια διεπαφή προγραμματισμού εφαρμογής, που αποτελείται από ένα ή περισσότερα εκτεθειμένα σημεία πρόσβασης (endpoints) σε ένα ορισμένο σύστημα μηνυμάτων αιτήματοςαπόκρισης, το οποίο συνήθως εκφράζεται σε JSON ή XML και το οποίο μεταδίδεται μέσω του διαδικτύου με βάση το HTTP πρωτόκολλο. Τα σημεία πρόσβασης αποτελούν βασικό μέρος της αλληλεπίδρασης με τις διαδικτυακές διεπαφές προγραμματισμού εφαρμογών, από την πλευρά του διακομιστή, καθώς καθορίζουν την τοποθεσία των πόρων, που είναι προσπελάσιμοι από άλλα λογισμικά. Ως επί το πλείστον, η πρόσβαση [22]

23 Θεωρητικό και Τεχνολογικό Υπόβαθρο γίνεται μέσω ομοιόμορφου αναγνωριστικό πόρου (URI), στο οποίο τίθενται τα αιτήματα με βάση το HTTP πρωτόκολλο και από το οποίο αναμένεται η απόκριση. Πολλές φορές βλέπουμε να ταυτίζονται και να συγχέονται οι έννοιες διαδικτυακή υπηρεσία και διαδικτυακή διεπαφή. Η βασική διαφοροποίηση, που μπορεί να εντοπιστεί, έγκειται στην μορφή των μηνυμάτων, που χρησιμοποιούνται για την επικοινωνία μέσω του διαδικτύου. Οι μοντέρνες διαδικτυακές εφαρμογές έχουν αποστραφεί από τα SOAP web services και έτσι η REST αρχιτεκτονική που χρησιμοποιείται από τις διαδικτυακές εφαρμογές τις καθιστά ευρέως διαδεδομένες [6] Representational state transfer (REST) - Richardson s Maturity Model (RΜΜ) Ο όρος Representational State Transfer (REST) πρωτοεμφανίστηκε το 2000 από τον Roy Fielding, στην διδακτορική διατριβή του στο Πανεπιστήμιο της Καλιφόρνια- University of California, Irvine, o οποίος περιέγραψε πώς τα διανεμημένα συστήματα πληροφορίας, όπως το διαδίκτυο, χτίζονται και λειτουργούν [7]. Το REST είναι ένα αρχιτεκτονικό στυλ που χρησιμοποιείται για την σχεδίαση διαδικτυακών εφαρμογών. Η εφαρμογή ενός αρχιτεκτονικού στυλ REST στην ανάπτυξη διαδικτυακών εφαρμογών προϋποθέτει τη χρήση ενός συνόλου από σχεδιαστικά κριτήρια, αρχές και περιορισμούς. H αρχιτεκτονική Resource-Oriented Architecture (ROA), καθορίζει τον τρόπο με τον οποίο τα κριτήρια αυτά θα πληρούνται σε μία διαδικτυακή εφαρμογή [8]. Στο κεφάλαιο αυτό θα παρουσιαστούν οι βασικές ιδιότητες της αρχιτεκτονικής ROA, καθώς και τα βασικά χαρακτηριστικά του REST με βάση το RMM (Richardson Maturity Model) Representational state transfer (REST) - Resource-Oriented Architecture (ROA) Στην αρχή αυτής της ενότητας θα παρουσιαστούν οι βασικές έννοιες της ROA. Οι έννοιες που χρησιμοποιούνται για να καθορίσουν το αρχιτεκτονικό στυλ REST περιλαμβάνουν: τον πόρο (Resource), την ταυτότητα του πόρου (URI), την αναπαράστασή του (Resource Representation) και τους συνδέσμους υπερμέσων (Hypermedia Links) [9]. Πόρος - Resource Πόρος είναι οποιαδήποτε πληροφορία μπορεί να ονομαστεί, όπως ένα έγγραφο, μία εικόνα, μια υπηρεσία όπως μια αναζήτηση μέσα σε μία συλλογή εγγράφων, μια σειρά σε μια βάση δεδομένων ή το αποτέλεσμα της λειτουργίας ενός αλγορίθμου. Με άλλα λόγια, οποιαδήποτε έννοια στην οποία μπορεί να παραπέμπει ένας σύνδεσμος υπερκειμένου μπορεί να είναι ένας πόρος [8]. [23]

24 Αυτόματη παραγωγή διεπαφών χρήστη για διαδικτυακές υπηρεσίες τύπου REST URI s Ένα URI (Uniform Resource Identifier) είναι η «ταυτότητα» ενός πόρου, η διεύθυνση και το όνομα του. Ένας πόρος μπορεί να έχει ένα URI, αλλά ένα κομμάτι πληροφορίας που δεν αντιστοιχίζεται σε κάποιο URI δεν μπορεί να θεωρηθεί πόρος και δεν βρίσκεται στο διαδίκτυο [8]. Αναπαράσταση πόρου - Resource Representation Η αναπαράσταση ενός πόρου ορίζεται ως μία ακολουθία από bytes καθώς και από ένα σύνολο μεταδεδομένων που περιγράφουν αυτή την ακολουθία. Καθώς ο πόρος είναι μία αφηρημένη έννοια, προτού να μπορέσει να κοινοποιηθεί στον πελάτη (client), πρέπει να γίνει μία αναπαράσταση αυτού. Συγκεκριμένα, ο πελάτης λαμβάνει μία αναπαράσταση όταν ζητάει έναν πόρο ή στέλνει μία όταν επιθυμεί να ενημερώσει έναν πόρο [8]. Σύνδεσμοι Υπερμέσων - Hypermedia Links Η τελευταία έννοια είναι αυτό που ονομάζουμε HATEOAS (Hypertext As The Engine Of Application State). Αυτό σημαίνει ότι ο πελάτης είναι υπεύθυνος για τη διατήρηση της κατάστασης της εφαρμογής και για τη διέλευση μεταξύ των πιθανών καταστάσεων. Η αναπαράσταση των πόρων θα πρέπει να έχει υπερσυνδέσμους, υποδεικνύοντας επόμενες καταστάσεις, έτσι ώστε να έχουμε μεταβίβαση καταστάσεων [8] [9]. Στην συνέχεια θα παρουσιάσουμε τις ιδιότητες του Resource-Oriented αρχιτεκτονικού μοντέλου. Για να χαρακτηριστεί μια εφαρμογή ως RESTful, χρειάζεται να πληροί τις εξής προϋποθέσεις: Διευθυνσιοδότηση - Addressability Η διευθυνσιοδότηση είναι η πιο σημαντική πτυχή σε μια διαδικτυακή εφαρμογή ή ιστοσελίδα. Αναφέρεται στο γεγονός ότι κάθε δυνατή πληροφορία που αποτελεί ένα πόρο μπορεί μέσο του URI του να διευθυνσιοδοτηθεί. Κάθε ενδιαφέρον κομμάτι των πληροφοριών που ο διακομιστής (Server) μπορεί να παρέχει πρέπει να εκτεθεί ως πόρος και να αντιστοιχηθεί σε αυτό ένα URI. Ένα URI πρέπει να αντιστοιχεί σε έναν μόνο πόρο, ενώ ένας πόρος όπως αναφέρθηκε μπορεί να έχει περισσότερα του ενός URIs [8]. Έλειψη Κατάστασης - Statelessness Με τον όρο statelessness εννοούμε ότι δεν υπάρχει αρχείο προηγούμενων αλληλεπιδράσεων και κάθε αίτημα αλληλεπίδρασης συμβαίνει σε πλήρη απομόνωση, δηλαδή πρέπει να στέλνονται όλα τα δεδομένα και οι απαραίτητες πληροφορίες που χρειάζονται για την εκτέλεση του. Επίσης αναφέρεται στο γεγονός ότι κάθε πιθανή κατάσταση είναι επίσης ένας πόρος και πρέπει να αντιστοιχίζεται και σε αυτή ένα URI [8]. [24]

25 Θεωρητικό και Τεχνολογικό Υπόβαθρο Συνδετικότητα - Connectedness Κάθε αναπαράσταση ενός πόρου πρέπει να περιέχει συνδέσμους που να περιέχουν τα URIs προς όλους τους επόμενους πιθανούς πόρους. Όπως περιγράψαμε και προηγουμένως είναι αυτή η ικανότητα της διασύνδεσης μεταξύ των πόρων. Ενιαία διεπαφή - Uniform Interface Το βασικό χαρακτηριστικό μιας REST διαδικτυακής υπηρεσίας είναι η ενιαία διεπαφή, η οποία εξασφαλίζεται με την χρήση του πρωτόκολλου επικοινωνίας HTTP. Υπάρχουν μόνο κάποια βασικά πράγματα που κάποιος μπορεί να κάνει σε έναν πόρο. Το πρωτόκολλο HTTP, λοιπόν, παρέχει τέσσερες μεθόδους για τις τέσσερις πιο κοινές λειτουργίες. Αυτές οι μέθοδοι είναι: ένα POST αίτημα, το οποίο χρησιμοποιείται για την δημιουργία ενός καινούργιου πόρου ένα GET αίτημα, το οποίο χρησιμοποιείται για την ανάκτηση ενός πόρου ένα PUT αίτημα για την δημιουργία ή τροποποίηση ενός πόρου ένα DELETE αίτημα για την διαγραφή ενός πόρου [8] Αυτές οι παραπάνω ιδιότητες, εκτός από το ότι καλύπτουν τα μειονεκτήματα των SOA διαδικτυακών υπηρεσιών, παρουσιάζουν κάποια επιπλέον πολύ σημαντικά πρακτικά πλεονεκτήματα και για τον λόγο αυτό η REST προσέγγιση κερδίζει ολοένα και περισσότερο έδαφος σε σχέση με το SOAP πρωτόκολλο, καθώς είναι πολύ πιο γρήγορη και απλή. Ίσως την πιο σημαντική ιδιότητα αποτελεί η ιδιότητα του Statelessness. Εφόσον ο διακομιστής δεν χρειάζεται να γνωρίζει τίποτα για την κατάσταση του client την στιγμή που αποστέλλει ένα αίτημα, τα RESTful Web APIs αποτελούν ιδανική υλοποίηση διανεμημένων συστημάτων, καθώς δεν απαιτείται συγχρονισμός μεταξύ των διακομιστών, όσον αφορά την κατάσταση του client Richardson s Maturity Model (RMM) Το πιο ευρέως διαδεδομένο μοντέλο που ακολουθείται για την ανάπτυξη ενός συστήματος REST είναι το μοντέλο ωρίμανσης του Leonard Richardson (RMM). Το μοντέλο αυτό καθορίζει στην ουσία τα επίπεδα τα οποία πρέπει να ακολουθήσει κανείς για να χτίσει μια RESTful υπηρεσία, προσθέτοντας κάθε φορά ένα επίπεδο το οποίο καλύπτει κάποιους από τους περιορισμούς. Σύμφωνα με το RMM μία διαδικτυακή εφαρμογή είναι RESTful, εάν πληροί τα ακόλουθα: [25]

26 Αυτόματη παραγωγή διεπαφών χρήστη για διαδικτυακές υπηρεσίες τύπου REST Περιλαμβάνει πόρους καθένας από τους οποίους ταυτοποιείται με ένα μοναδικό URI. Αυτό σημαίνει ότι δύο διαφορετικοί πόροι πρέπει να έχουν διαφορετικά URIs. Αυτός ο περιορισμός αναφέρεται στο πρώτο επίπεδου του RMM. Σε κάθε ένα από αυτά τα URI έχουμε πρόσβαση με την χρήση HTTP verbs, τα οποία χρησιμοποιούνται για τον σκοπό που προορίζονταν. Αυτό σημαίνει ότι μία POST εντολή χρησιμοποιείται για την δημιουργία ενός πόρου, μια GET εντολή για την ανάκτηση ενός πόρου, μία PUT εντολή για την δημιουργία ή ανανέωση ενός πόρου και η DELETE για την διαγραφή. Αυτός ο περιορισμός αναφέρεται στο δεύτερο επίπεδο του RMM. Level 0: The Swamp of POX Level 1: Resources Level 2: HTTP Verbs Level 3: Hypermedia Controls Glory of REST Σχήμα 3: Διαδικτυακή υπηρεσία REST σύμφωνα με το RMM Τέλος, κάθε πόρος συνδέεται με άλλους πόρους μέσω συνδέσμων υπερμέσων, οι οποίοι παρέχουν στους πελάτες τις επόμενες πιθανές καταστάσεις. Για παράδειγμα, ο πελάτης στέλνει ένα αίτημα σε μια RESTful διαδικτυακή υπηρεσία και, μαζί με την αντίστοιχη απάντηση, λαμβάνει και μία λίστα με υπερσυνδέσμους. Με αυτό τον τρόπο του δίνεται η δυνατότητα να κάνει τις επόμενες κινήσεις-μεταβάσεις στην διαδικτυακή υπηρεσία του, χωρίς προηγουμένως να τις είχε σκεφτεί. Στο σχήμα που ακολουθεί μπορούμε να δούμε και τα επίπεδα του RMM μοντέλου [9] Model Driven Engineering H αρχή της Μοντελοκεντρικής Μηχανικής (Model Driven Engineering - MDE) βασίζεται στην μετάβαση από την κωδικό-κεντρική μηχανική λογισμικού στην μοντελό-κεντρική με σκοπό την αύξηση του επιπέδου της αυτοματοποίησης και της παραγωγικότητας. Η Μοντελοκεντρική Μηχανική είναι η συστηματική χρήση των μοντέλων ως πρωταρχικά εργαλεία καθ όλο τον κύκλο ζωής του έργου λογισμικού. Βασίζεται στις παραδοχές [26]

27 Θεωρητικό και Τεχνολογικό Υπόβαθρο πως κάθε σύστημα μπορεί να αναπαρασταθεί από μοντέλα και πως κάθε μοντέλο υπακούει συντακτικά σε κάποιο μετά-μοντέλο [10]. Η MDE μεθοδολογία ευελπιστεί στην αύξηση της παραγωγικότητας, κατά την ανάπτυξη λογισμικού μεγιστοποιώντας την συμβατότητα μεταξύ διαφορετικών συστημάτων. Το βασικότερο χαρακτηριστικό που διαφοροποιεί την MDE από τις υπόλοιπες μεθοδολογίες ανάπτυξης λογισμικού είναι η συστηματική χρήση αφαιρετικών μοντέλων λογισμικού ως ενεργά στοιχεία κατά την διαδικασία ανάπτυξης λογισμικού, επιτυγχάνοντας υψηλό βαθμό αυτοματοποίησης της διαδικασίας παραγωγής λογισμικού. Στην συνέχεια αυτής της ενότητας θα γίνει αναφορά σε έννοιες όπως μοντέλο και μετασχηματισμός μοντέλων, καθώς και στην βασικές αρχές της Μοντελοκεντρικής Αρχιτεκτονικής Μοντέλα και Μετά-Μοντέλα Στο πλαίσιο της MDE, ορίζουμε ως σύστημα μια γενική ιδέα για τον χαρακτηρισμό μιας εφαρμογής λογισμικού, πλατφόρμα λογισμικού ή οποιοδήποτε άλλο λογισμικό τεχνούργημα. Επιπλέον, όπως υποδεικνύεται στο Σχήμα 4, ένα σύστημα μπορεί να αποτελείται από άλλα υποσυστήματα και ένα σύστημα μπορεί να έχει σχέσεις με άλλα συστήματα. Σχήμα 4: Ο ορισμός του συστήματος Ένα μοντέλο είναι μια αφαίρεση ενός συστήματος που συχνά χρησιμοποιείται για να αντικαταστήσει το υπό μελέτη σύστημα. Σε γενικές γραμμές, ένα μοντέλο αντιπροσωπεύει μια μερική και απλοποιημένη όψη ενός συστήματος, επομένως, η δημιουργία πολλαπλών μοντέλων είναι συνήθως απαραίτητη για να αντιπροσωπεύσει καλύτερα και να κατανοηθεί το υπό μελέτη σύστημα. Στην τεχνολογία λογισμικού, ο όρος μοντέλο χρησιμοποιείται συχνά για να γίνει αναφορά σε αφηρημένες έννοιες πάνω από τον κώδικα του προγράμματος, όπως απαιτήσεις και προδιαγραφές σχεδιασμού. Ωστόσο, ένα μοντέλο είναι και το ίδιο ένα σύστημα, με τη δική του ταυτότητα, την πολυπλοκότητα, τα Σχήμα 5: Ο ορισμός του μοντέλου. Σχέση μεταξύ συστήματος και μοντέλου στοιχεία, τις σχέσεις, κλπ. Συνοψίζοντας, και όπως προτείνεται στο Σχήμα 5 ορίζουμε ως μοντέλο μία [27]

28 Αυτόματη παραγωγή διεπαφών χρήστη για διαδικτυακές υπηρεσίες τύπου REST αναπαράσταση ενός συστήματος, της οποίας η μορφή και το περιεχόμενο επιλέγονται με βάση την επίτευξη κάποιου σκοπού [11]. Ένα μετά-μοντέλο έχει οριστεί με πολλούς τρόπους και πολλοί από τους ορισμούς που έχουν δοθεί είναι ασαφείς ή πολύ αδύναμοι, όπως ο ορισμός του OMG, που αναφέρει απλώς ότι: «ένα μετά-μοντέλο είναι ένα μοντέλο των μοντέλων». Ωστόσο, ορισμένοι συγγραφείς έχουν δώσει τους ακόλουθους ορισμούς: I. «ένα μετά-μοντέλο είναι ένα μοντέλο που καθορίζει τη γλώσσα για την έκφραση ενός μοντέλου» II. «ένα μετά-μοντέλο είναι ένα μοντέλο μιας γλώσσας των μοντέλων» Στην ουσία, προσδιορίζει την αφηρημένη σύνταξη μιας γλώσσας περιγραφής μοντέλων (modeling language), δηλαδή αποτελεί τις προδιαγραφές του συνόλου όλων των πιθανών μοντέλων που μπορούν να εκφραστούν σε αυτή τη γλώσσα. Κάθε μοντέλο θα πρέπει να συμμορφώνεται (conforms) στο μετά-μοντέλο στο οποίο ανήκει [11]. Ένα πολύ γνωστό και επαναλαμβανόμενο πρόβλημα είναι πώς να αρχικοποιήσεις το μετά-μοντέλο. Εάν ένα μετά-μοντέλο είναι ένα μοντέλο της γλώσσας περιγραφής μοντέλων, πρέπει να υπάρχει ένα μετά-μετάμοντέλο το οποίο θα περιγράφει αυτή την γλώσσα μοντελοποίησης. Η κοινή λύση για να ξεπεραστεί αυτό το πρόβλημα είναι η χρήση μιας γλώσσας, που, σε ένα συγκεκριμένο επίπεδο της ιεραρχίας, περιγράφει τον εαυτό της στη δική της γλώσσα. Για τον σκοπό αυτό, υπάρχει και ένα τρίτο επίπεδο, τα μετά-μετά-μοντέλα, τα οποία στοχεύουν στην εισαγωγή των απαραίτητων σημασιολογικών εννοιών που απαιτούνται για την περιγραφή μετά-μοντέλων, και άρα τα μετά-μοντέλα συμμορφώνονται στο μετά-μετά-μοντέλο. Τέλος, η γλώσσα μοντελοποίησης που πρότεινε ο OMG βασίζεται σε μία αρχιτεκτονική τεσσάρων στρωμάτων και άμεσα υποστηρίζεται μέσω του Meta Object Facility (MOF) [11]. [28]

29 Θεωρητικό και Τεχνολογικό Υπόβαθρο Meta Object Facility (MOF) Το MOF αποτελεί μια προσπάθεια να συστηματοποιηθεί ο τρόπος μοντελοποίησης των συστημάτων λογισμικού. Σύμφωνα με την Μοντελοκεντρική Αρχιτεκτονική που προτείνει ο OMG, κάθε μοντέλο πρέπει να υπακούει σε κάποιο μετά-μοντέλο. Η προσέγγιση του MOF στοχεύει στην επεκτασιμότητα των δυνατοτήτων των μοντέλων των λογισμικών συστημάτων. Ο σκοπός, δηλαδή, είναι να παρέχει ένα πλαίσιο το οποίο να υποστηρίζει κάθε είδος μεταδεδομένων και να επιτρέπει νέα είδη μεταδεδομένων να προστίθενται όποτε αυτό είναι αναγκαίο. Για να επιτευχθεί αυτός σκοπός, το MOF βασίζεται σε μια διαστρωματωμένη αρχιτεκτονική 4 επιπέδων, όπως φαίνεται και στο Σχήμα 6. Σχήμα 6: Η αρχιτεκτονική MOF Στη βάση της ιεραρχίας των 4 επιπέδων βρίσκεται το επίπεδο των πληροφοριών ή επίπεδο Μ0. Αποτελείται δηλαδή από τις πληροφορίες που θέλουμε να περιγράψουμε. Το αμέσως ανώτερο επίπεδο είναι το επίπεδο του μοντέλου ή Μ1. Το επίπεδο αυτό αποτελείται από τα μεταδεδομένα τα οποία περιγράφουν τα δεδομένα του επιπέδου πληροφοριών. Το τρίτο επίπεδο είναι το επίπεδο του μετά-μοντέλου ή Μ2. Το επίπεδο αυτό αποτελείται από την περιγραφή της δομής και της σημασιολογίας των μεταδεδομένων. Πρόκειται δηλαδή για μια συλλογή μέτα-μεταδεδομένων. Η συλλογή αυτή των μέτα-μεταδεδομένων αποτελεί ένα μετά-μοντέλο. Στην κορυφή της ιεραρχίας είναι το επίπεδο του μέτα-μετά-μοντέλου ή M3. Αποτελείται από την περιγραφή της δομής και της σημασιολογίας των μέτα-μεταδεδομένων. Με άλλα λόγια, είναι μια αφηρημένη γλώσσα ορισμού διαφορετικών ειδών μεταδεδομένων Μετασχημτισμοί Ένας μετασχηματισμός είναι ένα σύνολο από κανόνες που μετατρέπουν τα στοιχεία του μοντέλου εισόδου σε στοιχεία του μοντέλου εξόδου. Ο κανόνας μετασχηματισμού είναι η περιγραφή του πώς μία ή περισσότερες δομές στην αρχική γλώσσα μπορούν να μετατραπούν σε δομές αντίστοιχα της τελικής γλώσσας. Υπάρχουν δύο είδη μετασχηματισμών, ο μετασχηματισμός από μοντέλο σε μοντέλο (Model to model transformation M2M) και ο μετασχηματισμός από μοντέλο σε κώδικα (Model to text transformation M2T). Ένας μετασχηματισμός από μοντέλο σε μοντέλο αποτελείται από όσους κανόνες μετασχηματισμού χρειάζονται ώστε κάθε όρος του μοντέλου εισόδου να μετασχηματίζεται κατάλληλα σε ένα σύνολο όρων του μοντέλου εξόδου. Ένας μετασχηματισμός από μοντέλο σε κώδικα αποτελείται από ένα σύνολο προτύπων [29]

30 Αυτόματη παραγωγή διεπαφών χρήστη για διαδικτυακές υπηρεσίες τύπου REST κώδικα, τα οποία ο M2T μετασχηματισμός «συμπληρώνει», χρησιμοποιώντας τις πληροφορίες από το μοντέλο εισόδου [12] Model Driven Architecture Σχήμα 7: Μετασχηματισμός μοντέλου Ο όμιλος Object Management Group (OMG) 3 εισήγαγε την έννοια της Μοντελοκεντρικής Αρχιτεκτονικής (Model-Driven Architecture - MDA) το 2000, η οποία αποτελεί μια συγκεκριμένη προσέγγιση πάνω στην υλοποίηση της MDE μεθόδου και έκτοτε φιλοδοξεί να αλλάξει τον τρόπο στη σχεδίαση λογισμικού και τα κατασκευαστικά πρότυπα. H αρχιτεκτονική οδηγούμενη από μοντέλα μπορεί να οριστεί ως η υλοποίηση των αρχών της MDE μεθόδου, γύρω από ένα σύνολο προτύπων OMG, όπως το MOF (Meta Object Facility), XMI (XML Metadata Interchange), OCL (Object Constraint Language), UML (Unified Modeling Language) κ.α. ορισμένα από τα οποία θα περιγράψουμε και στην συνέχεια. Παρόμοια με τη βασική αρχή «τα πάντα είναι ένα αντικείμενο», που ήταν σημαντική τη δεκαετία του '80 για τη δημιουργία της αντικειμενοστραφής τεχνολογίας, εδώ, στην Μοντελοκεντρική μέθοδο, η βασική αρχή ότι «όλα είναι ένα μοντέλο" μπορεί να είναι το κλειδί για τον προσδιορισμό των βασικών χαρακτηριστικών αυτής της νέας τάσης. [13] 3 Object Management Group (OMG). Αρχικά είχε στόχο την τυποποίηση των κατανεμημένων συστημάτων, πλέον η εταιρεία επικεντρώνεται στην μοντελοποίηση (προγράμματα, συστήματα, επιχειρηματικές διαδικασίες) και τα πρότυπα βάσει μοντέλων. [30]

31 Θεωρητικό και Τεχνολογικό Υπόβαθρο Επίπεδα MDA H MDA περιλαμβάνει τρία προεπιλεγμένα μοντέλα ενός συστήματος. Αυτά τα μοντέλα περιγράφονται επακριβώς ως επίπεδα αφαίρεσης, καθώς σε κάθε ένα από αυτά τα επίπεδα ένα σύνολο μοντέλων μπορεί να κατασκευαστεί, όπου το καθένα αντιστοιχεί σε μία πιο εστιασμένη άποψη του συστήματος. Τα τρία αυτά επίπεδα περιγράφονται παρακάτω. Computation Independent Model (CIM) Το μοντέλο αυτό περιγράφει πλήρως τις απαιτήσεις και τις προδιαγραφές ενός συστήματος υπό ανάπτυξη. Παρουσιάζει ακριβώς τι αναμένεται από το σύστημα να κάνει αλλά κρύβει όλες τις τεχνολογικές πληροφορίες ώστε να είναι ανεξάρτητο από το πώς το σύστημα θα είναι υλοποιημένο. Το CIM διαδραματίζει σημαντικό ρόλο στη γεφύρωση του χάσματος που υπάρχει συνήθως μεταξύ των εμπειρογνωμόνων σε έναν τομέα και των σχεδιαστών λογισμικού που είναι υπεύθυνοι για την εφαρμογή του συστήματος. Σχήμα 8: Επίπεδα MDA Platform Independent Model (PIM) Ένα PIM επιδεικνύει επαρκή βαθμό ανεξαρτησίας, έτσι ώστε να επιτρέπει την αντιστοίχηση του σε μία ή περισσότερες πλατφόρμες. Αυτό επιτυγχάνεται με τον καθορισμό ενός συνόλου υπηρεσιών αφήνοντας έξω τις τεχνικές λεπτομέρειες. Άλλα μοντέλα στην συνέχεια καθορίζουν μία υλοποίηση των υπηρεσιών αυτών με συγκεκριμένο τρόπο για συγκεκριμένη πλατφόρμα. Platform Specific Model (PSM) Ένα PSM συνδυάζει τις προδιαγραφές του PIM με τις λεπτομέρειες που απαιτούνται για να ορίσει το πώς ένα σύστημα χρησιμοποιεί ένα συγκεκριμένο τύπο πλατφόρμας. Εάν το PSM δεν περιλαμβάνει όλες τις λεπτομέρειες που απαιτούνται για την παραγωγή της εφαρμογής της εν λόγω πλατφόρμας θεωρείται αφηρημένο, που σημαίνει ότι στηρίζεται σε άλλα μοντέλα που περιέχουν τις απαραίτητες λεπτομέρειες. Τέλος, ο εκτελέσιμος κώδικας του συστήματος για την επιλεγμένη πλατφόρμα, καθώς και αρχεία ρυθμίσεων και αρχεία κειμένου που περιγράφουν το παραγόμενό σύστημα (αρχεία documentation) λαμβάνονται από τον μετασχηματισμό του PSM [14]. [31]

32 Αυτόματη παραγωγή διεπαφών χρήστη για διαδικτυακές υπηρεσίες τύπου REST Πλεονεκτήματα και μειονεκτήματα της μεθόδου MDE Η πολυπλοκότητα και η διεισδυτικότητα του λογισμικού στην κοινωνία αυξάνεται εκθετικά. Είναι γενικά αποδεκτό ότι ο μόνος ρεαλιστικός τρόπος για τη διαχείριση αυτής της πολυπλοκότητας είναι η ανάπτυξη λογισμικού χρησιμοποιώντας τις κατάλληλες μεθόδους αφαιρετικότητας (methods of abstraction) 4. Στις μέρες μας, το κυριότερο ρόλο στην αφαιρετικότητα ενός λογισμικού παίζει το μοντέλο με γνώμονα την μηχανική (MDE) - δηλαδή, η συστηματική χρήση των προτύπων ως κύρια αντικείμενα κατά τη διάρκεια μιας διαδικασίας λογισμικού. Η MDE έχει γίνει πρόσφατα δημοφιλής, τόσο στον τομέα της βιομηχανίας, όσο και στον ακαδημαϊκό και από πολλούς, θεωρείται ως το επόμενο βήμα στην αύξηση του επιπέδου της αφαιρετικότητας. Το αν ή όχι η τρέχουσα εφαρμογή των εργαλείων του MDE επιτύχει, η έννοια των αφηρημένων μοντέλων είναι ζωτικής σημασία για το μέλλον του λογισμικού. Σύμφωνα με έρευνες, που έχουν πραγματοποιηθεί σε πραγματικές εφαρμογές, που υλοποιήθηκαν με βάση την MDE τεχνολογία και από τα αποτελέσματά τους μπορούν να εξαχθούν κάποια ενδεικτικά συμπεράσματα, που επιβεβαιώνουν τις θετικές επιδράσεις, χωρίς όμως να είναι καταληκτικά. Τα αποτελέσματα αυτά παρατίθενται στα παρακάτω διαγράμματα. Σχήμα 9: Αδυναμίες της MDE τεχνολογίας 4 Στη μηχανική λογισμικού και την επιστήμη των υπολογιστών, η αφαιρετικότητα είναι μια τεχνική για την οργάνωση της πολυπλοκότητας των συστημάτων πληροφορικής. Λειτουργεί με την καθιέρωση βαθμού πολυπλοκότητας στο οποίο ένα άτομο αλληλοεπιδρά με το σύστημα, καταστέλλοντας τις πιο περίπλοκες λεπτομέρειες κάτω από το τρέχον επίπεδο. [32]

33 Θεωρητικό και Τεχνολογικό Υπόβαθρο Σχήμα 10: Θετικές και αρνητικές επιδράσεις της τεχνολογίας MDE Στην συνέχεια αυτής της ενότητας θα αναφέρουμε ορισμένα πλεονεκτήματα που εισάγει η MDE μέθοδος, καθώς υπόσχεται να βελτιώσει σημαντικά τις τρέχουσες πρακτικές στην ανάπτυξη λογισμικού. Αύξηση της παραγωγικότητας, επιτρέποντας στους προγραμματιστές, σχεδιαστές και διαχειριστές του συστήματος να χρησιμοποιούν τις γλώσσες και τις έννοιες με τις οποίες είναι εξοικειωμένοι, ενώ επιτρέπει την απρόσκοπτη επικοινωνία και την ενσωμάτωση σε ομάδες. Συντήρηση και φορητότητα: Τα μοντέλα υψηλού επιπέδου διατηρούνται απαλλαγμένα από λεπτομέρειες καθιστώντας εύκολη την κατανόηση τους από καινούριο προσωπικό, καθώς και την διαχείριση των αλλαγών τους σε διαφορετικές πλατφόρμες. Όλα αυτά οδηγούν σε μείωση τους κόστους, καθ όλη τη διάρκεια του κύκλου ζωής της εφαρμογής, μείωση του χρόνου ανάπτυξης για νέες εφαρμογές, βελτίωση της ποιότητας της εφαρμογής, αυξημένη απόδοση των επενδύσεων τεχνολογίας και ταχεία ενσωμάτωση των αναδυόμενων πλεονεκτημάτων της τεχνολογίας στα υπάρχοντα συστήματά τους. Πέρα όμως από τα θετικά που έχουμε αναφέρει, υπάρχει και η αρνητική πλευρά της χρήσης της MDE μεθόδου. Στην παραγωγικότητα, το αρνητικό χαρακτηριστικό είναι ο χρόνος που απαιτείται για την ανάπτυξη των κατάλληλων μοντέλων που απαιτούνται και των κατάλληλων μετασχηματισμών. Το προσωπικό πρέπει να είναι εκπαιδευμένο και ειδικευμένο στην μέθοδο αυτή, ώστε να μπορεί να κατανοήσει γρήγορα ενδεικτικούς μετασχηματισμούς, που μπορεί να είναι περίπλοκοι. Επίσης, η MDE δεν προσφέρει ένα επίσημο [33]

34 Αυτόματη παραγωγή διεπαφών χρήστη για διαδικτυακές υπηρεσίες τύπου REST τυποποιημένο σύνολο γλωσσών που χρησιμοποιούνται για την μοντελοποίηση, μόνο προτάσεις. Αυτό μειώνει την δια λειτουργικότητα μεταξύ των εργαλείων γιατί διαφορετικοί κατασκευαστές χρησιμοποιούν διαφορετικές εφαρμογές [15] [16]. Τα πλεονεκτήματα και τα μειονεκτήματα της MDE μεθόδου δεν είναι προφανή με αποτέλεσμα να μην μπορούμε να πούμε με ακρίβεια αν η MDE μέθοδος θα πετύχει ή όχι [15]. 2.2 Τεχνολογικό Υπόβαθρο Αυτή η ενότητα παρουσιάζει εν συντομία τις τεχνολογίες που χρησιμοποιήθηκαν στα πλαίσια της συγκεκριμένης διπλωματικής εργασίας καθώς και τα πρότυπα της MDA αρχιτεκτονικής Ecore meta-model Το Ecore αποτελεί την υλοποίηση ενός μετά-μετά-μοντέλου και συμμορφώνεται στο πρότυπο MOF (και συγκεκριμένα στο Essential MOF - E MOF), καθιστώντας την γλώσσα αυτή κατάλληλη για τον ορισμό μοντέλων και κυρίως μετά-μοντέλων στα πλαίσια της MDA. Στην παρακάτω εικόνα φαίνεται ένα απλοποιημένο υποσύνολο ενός ecore μετά-μοντέλου. Ένα μοντέλο συντίθεται από στιγμιότυπα του τύπου EClass και μπορεί να έχει ένα ή περισσότερα στιγμιότυπα του τύπου EAttribute ή αναφορά σε στιγμιότυπα άλλης κλάσης μέσω του EReference. Τέλος, τα EAattributes μπορούν να είναι ποικίλα EDataType στιγμιότυπα, δηλαδή ακέραιοι, πραγματικοί αριθμοί κτλ. Σχήμα 11: Ecore Μετά-μοντέλο [34]

35 Θεωρητικό και Τεχνολογικό Υπόβαθρο Eclipse Modelling Framework (EMF) Το Eclipse Modelling Framework (EMF) είναι το κυριότερο πρότυπο σχεδίασης του Eclipse για την διαδικασία μετασχηματισμού μοντέλων. Tο EMF ενοποιεί Java, XML και UML τεχνολογίες, επιτρέποντας στον σχεδιαστή να εναλλάσσεται μεταξύ τους, καθώς παράγουν την ίδια πληροφορία σε διαφορετική παρουσίαση. Αυτό σημαίνει ότι στιγμιότυπα από οποιαδήποτε από τις τρεις γλώσσες μπορούν να ερμηνευτούν με διαφάνεια προσφέροντας με αυτόν τον τρόπο εύρωστη και αξιόπιστη σύνδεση μεταξύ των διαφορετικών αναπαραστάσεων του ίδιου μοντέλου. Με αυτόν τον τρόπο, για παράδειγμα, ένας χρήστης του Eclipse EMF δεν χρειάζεται να μετατρέψει χειροκίνητα ένα στιγμιότυπο τη γλώσσας UML σε Java. Στην παρακάτω εικόνα φαίνεται πως το EMF ενοποιεί αυτές τις τρεις τεχνολογίες [17]. Σχήμα 12: Το EMF ενοποιεί UML, XML και Java Object Constraint Language (OCL) Η γλώσσα Object Constraint Language (OCL) εμφανίστηκε αρχικά ως μία προσπάθεια να ξεπεραστούν οι περιορισμοί που είχε η UML, όταν πρόκειται για τον ακριβή προσδιορισμό των λεπτομερειών της σχεδίασης ενός συστήματος. Στην πορεία όμως γρήγορα εξαπλώθηκε στο πεδίο εφαρμογής της και έχει γίνει το κλειδί σε οποιαδήποτε MDE τεχνική. Η OCL αρχικά αναπτύχθηκε το 1995 από την IBM και έχει τις ρίζες της σε μία μέθοδο που καλείται Syntropy method [18]. Η OCL είναι μία τυπική γλώσσα (formal language) για την προδιαγραφή περιορισμών (constraints), είναι δηλωτική και είναι μια γλώσσα με τύπους. Με την περιγραφή της OCL ως μιας γλώσσας με τύπους αναφερόμαστε στο γεγονός ότι κάθε έκφραση σε OCL αποτιμάται σε έναν τύπο (είτε σε έναν προκαθορισμένο τύπο OCL, είτε σε έναν τύπο στο μοντέλο στο οποίο η έκφραση σε OCL χρησιμοποιείται) και πρέπει να [35]

36 Αυτόματη παραγωγή διεπαφών χρήστη για διαδικτυακές υπηρεσίες τύπου REST συμμορφώνεται στους κανόνες και στις λειτουργίες αυτού του τύπου. Οι κυριότεροι τύποι περιορισμών της OCL είναι: Αναλλοίωτες συνθήκες στις κλάσεις (Invariants on classes), δηλαδή συνθήκες που πρέπει να ικανοποιούνται από όλα τα στιγμιότυπα μιας κλάσης. Προ-συνθήκες στις λειτουργίες (pre-conditions on operations), δηλαδή συνθήκες που πρέπει να ικανοποιούνται πριν την εκτέλεση μιας λειτουργίας. Μετά-συνθήκες στις λειτουργίες (post-conditions on operations ), δηλαδή συνθήκες που πρέπει να ικανοποιούνται μετά την εκτέλεση μιας λειτουργίας [19] Atlas Transformation Language (ATL) H Atlas Transformation Language (ATL) είναι μία υβριδική γλώσσα (ένας συνδυασμός δηλωτικού 5 και προστακτικού 6 προγραμματισμού) που χρησιμοποιείται για τον μετασχηματισμό από μοντέλο σε μοντέλο, Μ2Μ, που έχουμε ήδη αναφέρει. Στο πλαίσιο του MDE, η ATL παρέχει στους προγραμματιστές τα μέσα/κανόνες ώστε να καθοριστεί ο τρόπος με τον οποίο τα στοιχεία των αρχικών μοντέλων συνδυάζονται και χρησιμοποιούνται για την αρχικοποίηση και παραγωγή των στοιχείων των τελικών μοντέλων. Η ATL βασίζεται πάνω στην πλατφόρμα του Eclipse και προσφέρει μια μεγάλη ποικιλία εργαλείων για τον σχεδιασμό και την υλοποίηση των κανόνων μετασχηματισμού. Η επόμενη εικόνα παρουσιάζει τον τρόπο με τον οποίο η ATL χρησιμοποιείται στον μετασχηματισμό από μοντέλο σε μοντέλο. Σχήμα 13: Μετασχηματισμός μοντέλου σε ATL 5 Στην επιστήμη υπολογιστών δηλωτικός προγραμματισμός είναι ένα προγραμματιστικό υπόδειγμα όπου το ζητούμενο αποτέλεσμα υπολογίζεται περιγράφοντας απλώς τις επιθυμητές ιδιότητες του. 6 Στην πληροφορική καλούμε προστακτικό προγραμματισμό ένα προγραμματιστικό υπόδειγμα όπου το ζητούμενο κατασκευάζεται / υπολογίζεται αλλάζοντας την κατάσταση του υπολογιστή μέσω εντολών. Η ιδέα είναι ότι έχουμε εντολές/statements που συνήθως μοιράζονται κοινές μεταβλητές [36]

37 Θεωρητικό και Τεχνολογικό Υπόβαθρο Η ATL συμμορφώνεται στο μετά-μετά-μοντέλο MOF και εκτελεί μετασχηματισμούς ανάμεσα στα μοντέλα που είναι στιγμιότυπα των μετά-μοντέλων που με τη σειρά τους συμμορφώνονται και αυτά στο μετά-μετάμοντέλο MOF. Για παράδειγμα, μετά από ένα σύνολο κανόνων ATL, ένα αρχικό μοντέλο Ma, το οποίο συμμορφώνεται στο μετά-μοντέλο MMa, μετασχηματίζεται στο τελικό μοντέλο Mb το οποίο συμμορφώνεται στο μετά-μοντέλο MMb. Το βασικό στοιχείο ενός προγράμματος μετασχηματισμού γραμμένο σε ATL είναι οι κανόνες (rules). Υπάρχουν τρεις βασικοί τύποι κανόνων: Matched Rules: Είναι δηλωτικοί κανόνες. Οι κανόνες αυτοί επιτρέπουν αντιστοιχία σε ορισμένα στοιχεία από το αρχικό μοντέλο και δημιουργούν μια σειρά από διακριτά στοιχεία του τελικού μοντέλου. Προκειμένου να παρέχει κάποιο έλεγχο στην σειρά εκτέλεσης, η ATL παρέχει επίσης μια υποκατηγορία των κανόνων αυτών, τους Lazy κανόνες. Αυτοί είναι επίσης δηλωτικοί κανόνες, αλλά καλούνται μόνο από άλλους κανόνες ρητά. Called Rules: Σε αντίθεση με του Matched κανόνες αυτοί είναι προστακτικοί κανόνες. Αυτοί οι κανόνες επικαλούνται από άλλους κανόνες και δεν έχουν ως είσοδο κάποιο στοιχείο του μοντέλου εισόδου [17] Acceleo Model-to-Text transformation language Η Acceleo γλώσσα αποτελεί μία ρεαλιστική υλοποίηση του MOF Model to Text προτύπου από την Object Management Group. Η συγκεκριμένη γλώσσα χρησιμοποιείται για τον μετασχηματισμό μοντέλων σε αντικείμενα κειμένου και θα χρησιμοποιηθεί στην παρούσα διπλωματική εργασία για την αυτοματοποιημένη παραγωγή της διαδικτυακής εφαρμογής πελάτη με βάση τη REST αρχιτεκτονική. Πιο συγκεκριμένα, είναι ένα πρότυπο γλώσσας βασισμένο στο υπερσύνολο της OCL, το οποίο επιτρέπει στον προγραμματιστή Σχήμα 14: Acceleo Model To Text μετασχματισμός την παραγωγή γενικών προτύπων κώδικα. Αυτά τα πρότυπα, δέχονται ως είσοδο ένα ή περισσότερα μοντέλα, τα οποία συμμορφώνονται σε ένα ή περισσότερα μετάμοντέλα και έχουν όλες τις απαραίτητες πληροφορίες για να καλύψουν τα πρότυπα αυτά. Η Acceleo βασίζεται στη χρήση προτύπων κειμένου (templates). Ένα αρχείο μετασχηματισμού πρακτικά χωρίζεται σε δύο μέρη. Το πρώτο είναι στατικό, που σημαίνει πως κατά την παραγωγή του αρχείου το στατικό μέρος θα εκτυπωθεί ως έχει. Το δεύτερο μέρος αποτελεί το δυναμικό κομμάτι και το τελικό εκτυπωμένο [37]

38 Αυτόματη παραγωγή διεπαφών χρήστη για διαδικτυακές υπηρεσίες τύπου REST κείμενο αυτού του μέλους προκύπτει από την εφαρμογή εκφράσεων και την εκτέλεση ερωτημάτων (queries) πάνω στα μοντέλα εισόδου. Οι εκφράσεις και τα ερωτήματα αυτά είναι γραμμένα στην γλώσσα OCL. Ένα τυπικό παράδειγμα είναι το παρακάτω: Σχήμα 15:Παράδειγμα πρότυπου Acceleo Στο σημείο αυτό θα γίνει μία σύντομη αναφορά στα συστατικά στοιχεία ενός έργου Acceleo, ώστε να καταστεί δυνατή η ανάγνωση του κεφαλαίου 4. Ένα module είναι ένα αρχείο με κατάληψη.mtl, το οποίο περιέχει templates για τη δημιουργία κώδικα ή/και ερωτήματα για την εξαγωγή πληροφοριών από τα μοντέλα. Ένα module παραμετροποιείται από τα URIs των μετα-μεταμοντέλων, δημιουργώντας στιγμιότυπα των μοντέλων από τα οποία θα παραχθεί κώδικας. Τα templates σύνολα των δηλώσεων Acceleo χρησιμοποιούνται για τη δημιουργία κειμένου. Αυτά οριοθετούνται από τις ετικέτες [template]... [/ template]. Τα main templates είναι templates που σηματοδοτούν τα σημεία εισόδου στην γεννήτρια, δηλαδή templates που χρησιμοποιούνται για να περιγράψουν, με κάποιο τρόπο, τη ροή εργασιών παραγωγής. Τέτοια templates μπορούν να δημιουργηθούν απλώς προσθέτοντας τον σχολιασμό Τα file blocks είναι το κύριο τμήμα καθώς περιλαμβάνει τους μετασχηματισμούς και τον κώδικα που χρειάζεται να καταγραφούν σε ένα αρχείο. Ένα file block περιέχει τρεις παραμέτρους: i. μια έκφραση που επιστρέφει μια συμβολοσειρά για το όνομα του αρχείου ii. μια boolean παράμετρο που δηλώνει εάν τα υπάρχοντα αρχεία θα πρέπει να αντικατασταθούν ή αν το πρόσφατα δημιουργημένο περιεχόμενο πρέπει να επισυναφθεί στο τέλος του υπάρχοντος αρχείου iii. την κωδικοποίηση του αρχείου Τα queries - ερωτήματα χρησιμοποιούνται για την εξαγωγή πληροφοριών από το μοντέλο. Τα ερωτήματα επιστρέφουν τιμές ή συλλογές τιμών. Χρησιμοποιούν OCL εκφράσεις, που περικλείονται σε μια ετικέτα [38]

39 Θεωρητικό και Τεχνολογικό Υπόβαθρο [query... /]. Τα ερωτήματα καθορίζονται για να επιστρέφουν πάντα την ίδια τιμή κάθε φορά που καλούνται με τα ίδια ορίσματα [20]. Σχήμα 16: Παράδειγμα δομής ενός acceleo project Η πλατφόρμα S-CASE (Scaffolding Scalable Software Services) Η παρούσα διπλωματική εργασία στηρίχτηκε στο S-CASE, ένα έργο λογισμικού το οποίο έλαβε μορφή τον Νοέμβριο του 2013 και στόχος του είναι να παρέχει στους μηχανικούς λογισμικού μία σειρά από εργαλεία και υπηρεσίες, προκειμένου να παραχθούν υπηρεσίας λογισμικού υψηλής ποιότητας σε λιγότερο χρόνο, αυξάνοντας την παραγωγικότητα και απλοποιώντας την διαδικασία της ανάπτυξης λογισμικού. Το S-CASE χρηματοδοτήθηκε από την Ευρωπαϊκή Ένωση και συγκεκριμένα από το πρόγραμμα FP7 (7th Framework Programme for Research and Technological Development). Πιο συγκεκριμένα, το S-CASE παρέχει εργαλεία έτσι ώστε να μειωθεί ο χρόνος από την στιγμή της σύλληψης μία ιδέας και του προσδιορισμού των απαιτήσεων του συστήματος, μέχρι το τελικό αποτέλεσμα. Μέσα από μία αυτοματοποιημένη διαδικασία παράγεται το τελικό πρόγραμμα, αφού έχουν καθοριστεί και οριστεί οι λειτουργικές απαιτήσεις και τα σενάρια χρήσης του ζητουμένου RESTful Web API. Στην πορεία του εγγράφου θα αναλυθεί περισσότερο η πλατφόρμα του S-CASE. [39]

40 Αυτόματη παραγωγή διεπαφών χρήστη για διαδικτυακές υπηρεσίες τύπου REST MVC - Model-View-Controller Η αρχιτεκτονική που ακολουθεί η παραγόμενη εφαρμογή πελάτη είναι αυτή του προτύπου μοντέλου εκλεκτή όψη. Είναι ένα μοντέλο αρχιτεκτονικής λογισμικού, το οποίο χρησιμοποιείται για την δημιουργία περιβαλλόντων αλληλεπίδρασης χρήστη. Κύριο χαρακτηριστικό του συγκεκριμένου μοντέλου, όπως μπορούμε να καταλάβουμε από το όνομά του, είναι ότι χωρίζεται η εφαρμογή σε τρία διαφορετικά υποσυστήματα. Το Μοντέλο, την Όψη και τον Ελεγκτή. Κάθε ένα από αυτά, λειτουργεί αυτόνομα αλλά επικοινωνεί με τα υπόλοιπα δυο υποσυστήματα. Συγκεκριμένα, το μοντέλο αναπαριστά τις πληροφορίες (τα δεδομένα) της εφαρμογής και τους κανόνες που χρησιμοποιούνται για τον χειρισμό των δεδομένων. Η όψη αντιστοιχεί στα στοιχεία εκείνα που είναι υπεύθυνα για το γραφικό περιβάλλον, αυτό που «βλέπει» ο χρήστης της εφαρμογής. Τέλος, ο ελεγκτής είναι υπεύθυνος για την διαχείριση των δεδομένων όπως αναζήτηση, κατηγοριοποίηση, σε μορφή τέτοια ώστε να ταιριάζει στις ανάγκες της προβολής. Ρόλος του είναι να επικοινωνεί με το μοντέλο στέλνοντας αιτήματα, για τις επιλογές ή τις εισόδους του χρήστη και με την όψη για να επιστρέφει τις αποκρίσεις του μοντέλου AngulasJS Σχήμα 17: Οι διασυνδέσεις μεταξύ των επιπέδων του μοτίβου MVC και του χρήστη Το AngularJS είναι ένα πλαίσιο ανάπτυξης διαδικτυακών εφαρμογών ανοιχτού πηγαίου κώδικα δημιουργημένο με τη γλώσσα προγραμματισμού Javascript και σχεδιασμένο για την ανάπτυξη διαδραστικών εφαρμογών διαδικτύου. Αναπτύχθηκε το 2009 από τους Miško Hevery και Adam Abrons στην εταιρία Brat Tech LLC, ως ιδιόκτητο λογισμικό και αργότερα κυκλοφόρησε ως βιβλιοθήκη ανοιχτού πηγαίου κώδικα. Είναι ένα από τα πλαίσια ανάπτυξης διαδικτυακών εφαρμογών με τη μεγαλύτερη επιρροή και συντηρείται από την κοινότητα, αλλά και από μεγάλες εταιρίες του χώρου, όπως η Google. Το AngularJS είναι σχεδιασμένο με έμφαση στη δημιουργία διαδικτυακών εφαρμογών μιας σελίδας, ακολουθώντας αρχιτεκτονική τύπου MVC. Έχει υιοθετήσει φιλοσοφία που παροτρύνει τον διαχωρισμό της ανάπτυξης των διεπαφών χρήστη με τη λογική της εφαρμογής, με κύρια μέθοδο την προσαρμογή και επέκταση της γλώσσας σήμανσης HTML έτσι ώστε να διευκολύνει τη κατασκευή διαδραστικών και σύγχρονων διαδικτυακών εφαρμογών. Ένα από τα πιο σημαντικά χαρακτηριστικά του AngularJS είναι η δυνατότητα αυτόματου συγχρονισμού μεταξύ των μοντέλων και της προβολής [40]

41 Θεωρητικό και Τεχνολογικό Υπόβαθρο Το AngularJS επεκτείνει και προσαρμόζει τα στοιχεία της γλώσσας HTML. Στο AngularJS τα αρχεία που περιέχουν κώδικα HTML ονομάζονται templates και αποτελούν το επίπεδο προβολής των εφαρμογών. Τα templates επεξεργάζονται κατά την εκκίνηση και λειτουργία της εφαρμογής από τον ειδικό τον μεταφραστή του AngularJS, και το προϊόν του είναι το τελικό αποτέλεσμα που εμφανίζεται στον φυλλομετρητή. Οι επιπρόσθετες λειτουργίες των templates υλοποιούνται με ένα σύστημα ειδικής σήμανσης, τις οδηγίες και τις εκφράσεις. Οι οδηγίες είναι προσαρμοσμένα στοιχεία όπως ονόματα στοιχείων, ιδιότητες, σχόλια ή κλάσεις της γλώσσας CSS που οδηγούν τον ειδικό μεταφραστή του AngularJS, έτσι ώστε να επισυνάψει μια συγκεκριμένη συμπεριφορά σε αυτό το στοιχείο, ή ακόμα και να μετατρέψει το στοιχείο και τα παιδιά του σε διαφορετική μορφή. Οι εκφράσεις, ένας ειδικός τύπος σήμανσης, αξιολογούνται από τον μεταφραστή κατά την εκτέλεση της εφαρμογής, και παίρνει την θέση τους το αποτέλεσμα της αξιολόγησης της έκφρασης. Οι εκφράσεις αποτελούν τον μηχανισμό που επιτρέπει στο AngularJS πρόσβαση σε μεταβλητές στο επίπεδο της προβολής. Τέλος, οι ελεγκτές στο AngularJS δημιουργούν και ορίζουν την αρχική κατάσταση και επιθυμητή συμπεριφορά σε ειδικά αντικείμενα scope, που δρουν ως συνδετικοί κρίκοι μεταξύ της προβολής και της λογικής της εφαρμογής. Με τη χρήση των παραπάνω χαρακτηριστικών, εφαρμόζεται η λειτουργία του αυτόματου συγχρονισμού μεταξύ των μοντέλων και των προβολών του AngularJS [21] [22] Semantic UI Το Semantic UI αποτελεί ένα από τα δημοφιλέστερα HTML, CSS και JavaScript frameworks για την ανάπτυξη αποκρίσιμων ιστοσελίδων. Eίναι ένα σύγχρονο πλαίσιο ανάπτυξης του front-end, το οποίο τροφοδοτείται από το LESS και το jquery. Σύμφωνα με τον ιστότοπο του Semantic UI, ο στόχος του πλαισίου είναι να δώσει κίνητρο τους σχεδιαστές και τους προγραμματιστές «δημιουργώντας μια γλώσσα για την κοινή χρήση του UI», αξιοποιώντας μια σημασιολογική, περιγραφική γλώσσα για τις τάξεις και τις συμβάσεις ονομάτων. Αντί να χρησιμοποιούνται συντομογραφίες, όπως κάνουν άλλα πλαίσια, χρησιμοποιούνται πραγματικές. Το Semantic UI βασίζεται στην πεποίθηση ότι το εννοιολογικό δομικό στοιχείο των ιστοτόπων δεν είναι μεμονωμένες ετικέτες HTML, αλλά μεμονωμένα στοιχεία διεπαφής. Τα στοιχεία διεπαφής είναι στοιχεία όπως τα κουμπιά, τα αναπτυσσόμενα μενού και τα modals, στοιχεία που δομούν και συνθέτουν το περιεχόμενο ενός ιστότοπου. Τοποθετημένα μαζί σε μια σελίδα δημιουργούν οπτική ροή την οποία την αντιλαμβανόμαστε ως ιστοσελίδα [23]. [41]

42 Αυτόματη παραγωγή διεπαφών χρήστη για διαδικτυακές υπηρεσίες τύπου REST 3 Υπάρχουσες Τεχνολογίες 3.1 Υπάρχουσες τεχνολογίες για την αυτοματοποιημένη παραγωγή διαδικτυακών υπηρεσιών τύπου REST Σε αυτή την ενότητα θα παρουσιαστούν τα σχετικά έργα και πλαίσια, που υπάρχουν, για την ανάπτυξη διαδικτυακών υπηρεσιών τύπου REST Ruby on Rails Το Ruby on Rails, συχνά Rails ή RoR, είναι ένα πλαίσιο ανάπτυξης διαδικτυακού λογισμικού ανοιχτού κώδικα με χρήση της γλώσσας προγραμματισμού Ruby. Προορίζεται για χρήση σε συνδυασμό με ευέλικτες μεθοδολογίες ανάπτυξης (agile development methodologies), οι οποίες χρησιμοποιούνται από τους προγραμματιστές διαδικτυακών εφαρμογών για ταχεία ανάπτυξη λογισμικού (rapid application development). Είναι δημιούργημα του David Heinemeier Hansson. Ο David Hansson αρχικά κυκλοφόρησε το Σχήμα 18: Βασική αρχιτεκτονική Rails [42]

43 Υπάρχουσες Τεχνολογίες Rails σαν ανοιχτό κώδικα τον Ιούλιο του 2004 αλλά δεν επέτρεπε σε άλλους προγραμματιστές να συνεισφέρουν κώδικα στο εγχείρημα μέχρι το Φεβρουάριο του Τον Αύγουστο του 2006 υπήρξε κομβικό σημείο για το Rails, όταν η Apple ανακοίνωσε ότι θα κυκλοφορούσε το Ruby on Rails μαζί με το Mac OS X v10.5 "Leopard". Το τοπίο στην αγορά εργαλείων για κατασκευή ιστοσελίδων άλλαξε με την εμφάνιση πολλών άλλων εργαλείων που προσπάθησαν να το αντιγράψουν, συχνά ανεπιτυχώς, μιας και οι γλώσσες που χρησιμοποίησαν δεν έχουν την ευελιξία και την εκφραστικότητα της γλώσσας Ruby. Πολλλές γνωστές ιστοσελίδες έχουν βασιστεί στο μεγαλύτερο μέρος τους σε Ruby on Rails (Ενδεικτικά github, twitter, slideshare κ.α.) [24]. Όπως πολλά πλαίσια διαδικτυακών εφαρμογών, το Rails χρησιμοποιεί αρχιτεκτονική Model-View-Controller (MVC) για να οργανώσει τον προγραμματισμό των εφαρμογών. Μερικά από τα βασικά στοιχεία του είναι λοιπόν τα Models, Controllers, Views. Τα models αποθηκεύουν δεδομένα και αντιστοιχούν σε πίνακες της βάσης δεδομένων. Οι controllers λαμβάνουν και αποκρίνονται σε εξωτερικά αιτήματα παρέχοντας ένα σύνολο από actions. Αν και δεν είναι υποχρεωτικό, το Rails δίνει έμφαση σε RESTful actions, το οποίο σημαίνει ότι οι controllers ανταποκρίνονται σε create/new,edit/update, destroy, show/index αιτήματα. Τέλος, τα views είναι αρχεία που παράγουν HTML. Το Ruby on Rails έχει επίσης λάβει κάποια κριτική, κυρίως όσον αφορά τις επιδόσεις και την επεκτασιμότητα, η οποία έχει κάνει ορισμένες εταιρείες να προτιμήσουν άλλα πλαίσια και λύσεις από το Rails [17] EMF-Rest Το EMF-Rest είναι ένα πλαίσιο βασισμένο στον Eclipse που επιτρέπει την ανάπτυξη διαδικτυακων εφαρμογών χρησιμοποιώντας Ecore μεταμοντέλα. Όπως δείχνει και η παρακάτω εικόνα, ο προγραμματιστής ξεκινάει την μοντελοποίηση της διαδικτυακής εφαρμογής χρησιμοποιώντας Ecore μεταμοντέλα με την μορφή διαγραμμάτων κλάσεων (class diagram). Με την ολοκλήρωση αυτής της διαδικασίας, το EMF-Rest πλαίσιο δημιουργεί τα θεμέλια της αντίστοιχης διαδικτυακής υπηρεσίας και παρέχει ένα RESTful Web API, JSON serializers και javascript API. [43]

44 Αυτόματη παραγωγή διεπαφών χρήστη για διαδικτυακές υπηρεσίες τύπου REST Σχήμα 19: EMF-Rest επισκόπηση Στο παρακάτω σχήμα φαίνεται ένα παράδειγμα ενός RESTful API ενώ στα αριστερά μία απόκριση αυτού σε JSON. Όπως μπορούμε να παρατηρήσουμε στην απόκριση αυτή του παραδείγματος δεν υπάρχει έλεγχος υπερμέσων και με αυτό τον τρόπο δεν ακολουθεί τις αρχές του RMM μοντέλου που περιγράψαμε στις αρχές του κεφαλαίου [17]. Σχήμα 20: Αριστερά: Παράδειγμα απόκρισης σε JSON Δεξιά: Παράδειγμα ενός RESTful API [44]

45 Υπάρχουσες Τεχνολογίες Django-REST-Framework Το Django rest framework είναι ένα ακόμη πλαίσιο που χρησιμοποιείται για την αυτόματη παραγωγή RESTful API, το οποίο χρησιμοποιεί τη γλώσσα Python και ακολουθεί το αρχιτεκτονικό πρότυπο Model-View-Template (MVT). Πρωταρχικός σκοπός είναι να διευκολύνει την δημιουργία πολύπλοκων, database-driven διαδικτυακών εφαρμογών. Πολλές γνωστές ιστοσελίδες ακολουθούν το πρότυπο αυτό μερικές από τις οποίες είναι το Instagram, Mozilla, Pinterest κ.α. Γεννήθηκε το φθινόπωρο του 2003, όταν οι προγραμματιστές στην εφημερίδα Lawrence Journal-World, Adrian Holovaty και Simon Willison, άρχισαν να χρησιμοποιούν Python για να δημιουργήσουν εφαρμογές [25]. Τα κυριότερα στοιχεία του που χρησιμοποιούνται για την δημιουργία RESTful APIs είναι τα Models, Serializers, Views και URLs. Αρχικά, ο προγραμματιστής πρέπει να ορίσει ένα μοντέλο το οποίο αναπαριστά τα δεδομένα με τα οποία θα αλληλοεπιδρά το REST API και στην συνέχεια δημιουργεί ένα σύνολο από serializers. Στην συνέχεια ο προγραμματιστής πρέπει να ορίσει τα views, τα οποία ορίζουν τον τρόπο με τον οποίο οι clients αλληλοεπιδρούν με το API. Το τελευταίο βήμα αποτελεί το στήσιμο ενός αρχείου python με URL templates τα οποία θα χρησιμοποιηθούν. Επίσης στο πλαίσιο αυτό δεν υποστηρίζεται η αυτοματοποιημένη παραγωγή Hypermedia Links [17]. Σχήμα 21: Αριστερά: Django-REST-Framework serializers Δεξιά: Απόκριση ενός HTTP GET αιτήματος [45]

46 Αυτόματη παραγωγή διεπαφών χρήστη για διαδικτυακές υπηρεσίες τύπου REST Laravel PHP Framework Το Laravel PHP Framework είναι ένα πλαίσιο διαδικτυακών εφαρμογών το οποίο δημιουργήθηκε από τον Taylor Otwell το 2011 και προορίζεται για την ανάπτυξη διαδικτυακών εφαρμογών ακολουθώντας το αρχιτεκτονικό πρότυπο Model View Controller (MVC). Όπως περιγράφει και η επόμενη εικόνα κατά την αλληλεπίδραση με μια εφαρμογή Laravel, ένα πρόγραμμα περιήγησης στέλνει ένα αίτημα, το οποίο λαμβάνεται από ένα web server και μεταβιβάζεται στη μηχανή δρομολόγησης του Laravel. Ο δρομολογητής Laravel λαμβάνει την αίτηση και ανακατευθύνει στην κατάλληλη μέθοδο ελέγχου με βάση το μοτίβο URL δρομολόγησης. Στην συνέχεια, ο εκλεκτής (controller) έχει την εποπτεία. Σε ορισμένες περιπτώσεις, ο ελεγκτής θα καταστήσει αμέσως ένα view, το οποίο είναι ένα πρότυπο που μετατρέπεται σε HTML και στέλνεται πίσω στον browser. Συνηθέστερα, ο ελεγκτής αλληλεπιδρά με ένα μοντέλο, το οποίο είναι ένα αντικείμενο PHP που αντιπροσωπεύει ένα στοιχείο της αίτησης. Μετά την επίκληση του μοντέλου, ο ελεγκτής αποδίδει στη συνέχεια το τελικό view (HTML, CSS, και εικόνες) και επιστρέφει την πλήρη ιστοσελίδα στο πρόγραμμα περιήγησης του χρήστη. Σχήμα 22: Μια τυπική διαδικτυακή εφαρμογή Laravel: [46]

47 Υπάρχουσες Τεχνολογίες REST United Το REST United είναι μια σχετικά νέα online εφαρμογή για αυτόματη δημιουργία SDK για REST APIs. Το REST United διαθέτει μια εύχρηστη διασύνδεση που επιτρέπει στους χρήστες να δημιουργούν αυτόματα παραγόμενα SDKs (βιβλιοθήκες REST API) με προσαρμοσμένα δείγματα τεκμηρίωσης και κώδικα. Το REST United διαθέτει ένα εργαλείο Import REST API που επιτρέπει στους χρήστες να δημιουργούν SDKs εισάγοντας αρχεία περιγραφής API. Αυτή την στιγμή, το REST United υποστηρίζει Postman, Alpaca, Swagger (v1.2, v2.0), 3scale, I / O Docs και Blueprint. Yποστηρίζει την εισαγωγή και εξαγωγή αρχείων συλλογής Postman, κάτι το οποίο αποτελεί βασικό χαρακτηριστικό του, καθώς επιτρέπει στους χρήστες να χρησιμοποιούν το Postman εύκολα για τη δοκιμή και την αποσφαλμάτωση των API τους. Τέλος, επιτρέπει στους χρήστες να δημιουργούν αυτόματα API Documantation, το οποίο περιλαμβάνει πληροφορίες εγκατάστασης των SDKs, δείγματα κώδικα, συνδέσμους προς τα SDKs, σημειώσεις έκδοσης και άλλες πληροφορίες για το API. Είναι ικανό να δημιουργεί αυτόματα SDKs στις προγραμματιστικές γλώσσες Android, C #, ActionScript, Java, Objective-C, PHP, Python v2, Ruby και Scala, JavaScript και Node.js APIMATIC Το APIMATIC είναι μια αυτόματη γεννήτρια κώδικα για RESTful API. Ως είσοδο δέχεται τον ορισμό του API και στη συνέχεια παράγει μέρη κώδικα στην επιλεγμένη γλώσσα προγραμματισμού. Προς το παρόν οι υποστηριζόμενες μορφές για την περιγραφή του API είναι οι εξής: API Blueprint, RAML, Google API Discovery, IODocs, WADL και Swagger. Ωστόσο, δεν είναι όλες οι αποκρίσεις API γραμμένες αρκετά καλά για την αυτόματη δημιουργία κώδικα και μπορεί να αποτύχουν στη διαδικασία δημιουργίας κώδικα. Επίσης, όπως και οι υπόλοιπες πλατφόρμες, δεν παρέχει μία ολοκληρωμένη εφαρμογή έτοιμη προς κατανάλωση από τον χρήστη, αλλά βιβλιοθήκες οι οποίες μπορούν να χρησιμοποιηθούν από τους προγραμματιστές για την επίτευξη του τελικού αποτελέσματος. [47]

48 Αυτόματη παραγωγή διεπαφών χρήστη για διαδικτυακές υπηρεσίες τύπου REST 3.2 Υπάρχουσες τεχνολογίες για αυτοματοποιημένη παραγωγή εφαρμογής πελάτη Swagger Code Generator Το Swagger Code Generator είναι ίσως η πιο δημοφιλής πλατφόρμα αυτή την στιγμή που χρησιμοποιείται για την περιγραφή και τεκμηρίωση RESTful API. Το Swagger ορίζει ένα σύνολο αρχείων που απαιτούνται για την περιγραφή ενός API βασισμένο στην αρχιτεκτονική REST. Αυτά τα αρχεία μπορούν στη συνέχεια να χρησιμοποιηθούν από την πλατφόρμα του Swagger-UI για να εμφανίσουν το API και το Swagger-Codegen για να δημιουργήσουν πελάτες σε διάφορες γλώσσες. Αυτή την στιγμή παράγει διαδικτυακές εφαρμογές πελάτη σε 38 διαφορετικές γλώσσες προγραμματισμού. Επιπλέον βοηθητικά προγράμματα μπορούν επίσης να επωφεληθούν από τα αρχεία που προκύπτουν, όπως είναι τα εργαλεία ελέγχου. Το Swagger λειτουργεί ζητώντας ένα αρχείο YAML ή JSON που περιέχει μια λεπτομερή περιγραφή ολόκληρου του API. Αυτό το αρχείο είναι ουσιαστικά ένας κατάλογος πόρων του API που ακολουθεί την προδιαγραφή OpenAPI. Η προδιαγραφή σας ζητά να συμπεριλάβετε πληροφορίες όπως: τις λειτουργίες που υποστηρίζει το API τις παραμέτρους του API και τι αυτό επιστρέφει την ύπαρξη ή όχι ταυτοποίησης συμπληρωματικές λειτουργίες όπως πληροφορίες επικοινωνίας και άδεια χρήσης του API Ωστόσο, η αυτοματοποίηση της εφαρμογής πελάτη περιορίζεται στην παραγωγή βιβλιοθηκών και συναρτήσεων και δεν αποτελεί ένα ολοκληρωμένο εργαλείο παραγωγή διαδικτυακών διεπαφών έτοιμο για χρήση. [26] REST Client Generator Το REST Client Generator είναι ένα plugin του Eclipse που ξεκινάει από το αρχείο WADL (επίσημη περιγραφή των υπηρεσιών RESTful) και είναι σε θέση να δημιουργήσει τον πηγαίο κώδικα Java που καλύπτει την αλληλεπίδραση μεταξύ της εφαρμογής και των απομακρυσμένων υπηρεσιών [27]. [48]

49 Υπάρχουσες Τεχνολογίες AutoRest Το εργαλείο AutoRest είναι ακόμα μια προσπάθεια δημιουργίας βιβλιοθηκών πελάτη για την πρόσβαση σε διαδικτυακές υπηρεσίες τύπου REST. Η γεννήτρια δέχεται ως είσοδο ένα αρχείο προδιαγραφών που περιγράφει πλήρως το RESTful API χρησιμοποιώντας τη μορφή Open API Initiative. [49]

50 Αυτόματη παραγωγή διεπαφών χρήστη για διαδικτυακές υπηρεσίες τύπου REST 4 Μεθοδολογία Στο κεφάλαιο αυτό θα γινεί αναφορά στην μεθοδολογία που ακολουθήθηκε για τους σκοπούς της συγκεκριμένης διπλωματικής εργασίας. Όπως αναφέρθηκε και σε προηγούμενη ενότητα, η παρούσα διπλωματική εργασία στηρίζεται στην ανάπτυξη διαδικτυακών επαφών πελάτη, που θα καταναλώνουν διαδικτυακές υπηρεσίες τύπου REST, οι οποίες έχουν παραχθεί μέσω της πλατφόρμας του S-CASE. Για τον λόγο αυτό θα γίνει μία πιο λεπτομερής αναφορά στις λειτουργίες του S-CASE. 4.1 S-CASE Για την υλοποίηση του S-CASE έργου αξιοποιήθηκαν οι βασικές αρχές της τεχνολογίας λογισμικού οδηγούμενης από μοντέλα. To S-CASE MDE περιλαμβάνει τέσσερα ξεχωριστά συστατικά, καθένα από τα οποία αντιστοιχεί σε κάθε φάση MDE. Επομένως, υπάρχουν τέσσερα στοιχεία, ένα για τη διατύπωση CIM, ένα για το PIM, ένα για το PSM και ένα που δημιουργεί τον πραγματικό κωδικό της οραματισμένης υπηρεσίας RESTful του συστήματος όπως φαίνεται και στο Σχήμα 23. Σχήμα 23: Οι 4 φάσεις της δισδιάστατης μοντελοστραφούς σχεδίασης Η γεννήτρια CIM διαβάζει ως είσοδο την οντολογία του S-CASE και παράγει το CIM μοντέλο του επιθυμητού συστήματος. Το CIM μοντέλο, είναι σε XMI μορφή, και συμμορφώνεται στο CIM μεταμοντέλο. Το CIM μοντέλο, με την σειρά του, γίνεται είσοδος στην γεννήτρια PIM. Η κύρια δραστηριότητα αυτής της γεννήτριας είναι να διαβάσει το μοντέλο CIM του οραματισμένου συστήματος και να καθορίσει πλήρως τον αφηρημένο σχεδιασμό του, εφαρμόζοντας σε αυτό το αρχιτεκτονικό στυλ REST. Το αποτέλεσμα αυτής της διαδικασίας είναι το μοντέλο PIM του συστήματος, το οποίο είναι σύμφωνο με το μετά-μοντέλο PIM. Η γεννήτρια PSM [50]

51 Μεθοδολογία αναλύει το παραγόμενο μοντέλο PIM και στη συνέχεια καθορίζει τον αφηρημένο σχεδιασμό του. Δηλαδή, για κάθε αφηρημένο στοιχείο του μοντέλου PIM, η γεννήτρια PSM εισάγει ένα PSM που είναι σημασιολογικά ισοδύναμο, αλλά ορίζεται με συγκεκριμένες τεχνολογίες, όπως μια συγκεκριμένη γλώσσα προγραμματισμού, και συμμορφώνεται με το μεταμοντέλο PSM. Το παραγόμενο PSM μοντέλο είναι σε μορφή XMI και περιέχει όλη την απαιτούμενη πληροφορία για την αυτοματοποιημένη παραγωγή κώδικα. Η περιγραφή των CIM και PIM μεταμοντέλων, που χρησιμοποιεί η S-CASE πλατφόρμα, παραλείπεται στην παρούσα διπλωματική, καθώς για την υλοποίηση χρησιμοποιείται μόνο το PSM μεταμοντέλο [17]. 4.2 Γενικά Η παρούσα έχει ως στόχο την αυτοματοποίηση της παραγωγής διαδικτυακών εφαρμογών πελάτη, μέσω μίας μηχανής η οποία δέχεται ως είσοδο το PSM μοντέλο της επιθυμητής διαδικτυακής υπηρεσίας και μέσω ενός Model to Text μετασχηματισμού, παράγει τον επιθυμητό κώδικα για την λειτουργία της εφαρμογής. Στο Σχήμα 24 παρουσιάζεται η επισκόπηση της S-CASE MDE μηχανής και η σχέση της με την υλοποίηση της παρούσας. Σκοπός της είναι, η δημιουργία ενός εργαλείου που θα παρέχει αυτόματα γραφικές διεπαφές, πλήρως προσαρμόσιμες στη δομή ενός RESTful web API, δηλαδή μιας διαδικτυακής υπηρεσίας που υπακούει στην αρχιτεκτονική REST, καθώς αυτή αποτελεί σήμερα την επικρατέστερη επιλογή σχεδίασης. Η παραγόμενη εφαρμογή πελάτη σχεδιάστηκε με τρόπο ώστε να πληροί συγκεκριμένες ενέργειες και δυνατότητες. Πέραν των βασικών λειτουργιών μιας διαδικτυακής εφαρμογής αναπτύχθηκαν δυνατότητες και λειτουργίες που αφορούν την ταυτοποίηση χρήστη στην εφαρμογή (authentication), την αναζήτηση στη βάση δεδομένων (Database Searching) και την επικοινωνία της διαδικτυακής εφαρμογής με άλλες, εξωτερικές, εφαρμογές (External Compositions). Επίσης, παρέχει ποιοτικά χαρακτηριστικά γραφικών διεπαφών, όπως αναδυόμενα παράθυρα για την επιβεβαίωση ή ενημέρωση των κινήσεων του χρήστη, μενού πλοήγησης, ενσωμάτωση εικόνων κ.α. Τέλος, παράγονται και αρχεία τεκμηρίωσης του κώδικα για την καλύτερη επεξήγηση του. Αποτελεί, λοιπόν, μια ολοκληρωμένη εφαρμογή, αλλά, παράλληλα, παρέχει ευελιξία στον προγραμματιστή και την δυνατότητα επεξεργασίας κάθε στοιχείου για την πλήρη προσαρμογή της διεπαφής στις ανάγκες του. [51]

52 Αυτόματη παραγωγή διεπαφών χρήστη για διαδικτυακές υπηρεσίες τύπου REST Σχήμα 24: Υλοποίηση αυτοματοποιημένης παραγωγής εφαρμογής πελάτη και η σχέση του με το S-CASE 4.3 Acceleo μετασχηματισμός PSM μοντέλου σε κώδικα Σε αυτή την ενότητα θα γίνει μια σύντομη επισκόπηση της απαιτούμενης πληροφορίας, για την πλήρη αυτοματοποίηση της διαδικασίας παραγωγής εφαρμογής πελάτη και του PSM μεταμοντέλου, που χρησιμοποιείται ως είσοδος στο Model to Text μετασχηματισμό PSM Μοντέλο εισόδου στο σύστημα Στην παράγραφο αυτή θα αναλυθούν συνοπτικά τα στοιχεία των PSM μεταμοντέλων που χρησιμοποιήθηκαν από το σύστημα. Για πιο λεπτομερή αναφορά ο αναγνώστης μπορεί να ανατρέξει εδώ [28]. [52]

53 Μεθοδολογία Στοιχεία PSM Μεταμοντέλου MediaType Ο τύπος δεδομένων MediaType είναι μια απαρίθμηση, η οποία μοντελοποιεί όλους τους τύπους μέσων εισόδου και εξόδου που υποστηρίζονται σε κάθε περίπτωση από το S-CASE. Αυτές μπορούν να βρεθούν στον ακόλουθο πίνακα: Πίνακας 3: Υποστηριζόμενα Media Types Media Κεφαλίδα HTTP Προεπιλεγμένη Επεξήγηση Type Τιμή JSON application/json Ναι Εάν η τιμή XML είναι επιλεγμένη για την αναπαράσταση κάποιου πόρου, το Web API θα δέχεται δεδομένα σε αιτήματα ή απαντήσεις, σε μορφή application/xml. XML application/xml Οχι Εάν η τιμή JSON είναι επιλεγμένη για την αναπαράσταση κάποιου πόρου, το Web API θα δέχεται δεδομένα σε αιτήματα ή απαντήσεις, σε μορφή application/json CRUDVerb Ο τύπος δεδομένων HTTPVerb μοντελοποιεί τα τέσσερα ρήματα HTTP, POST, GET, PUT, DELETE. Ορίζονται στον ακόλουθο πίνακα: Πίνακας 4: Τύποι HTTPVerb HTTPVerb POST GET PUT Προεπιλεγμένη Τιμή Ναι Όχι Όχι Επεξήγηση Χρησιμοποιείται για τη μοντελοποίηση του ρήματος HTTP POST μέσα στο PSM μετά-μοντέλο. Όπου και αν χρησιμοποιείται, σέβεται το αρχιτεκτονικό στυλ REST και αναπαριστά τη λειτουργία δημιουργίας ενός νέου πόρου Χρησιμοποιείται για να μοντελοποιήσει το ρήμα HTTP GET μέσα στο PSM μετά-μοντέλο. Όπου και αν χρησιμοποιείται, σέβεται το αρχιτεκτονικό στυλ REST και έτσι υποδηλώνει τη δράση ανάκτησης είτε ενός συγκεκριμένου υπάρχοντος πόρου είτε μιας λίστας με υπάρχοντες πόρους Χρησιμοποιείται για να μοντελοποιήσει το ρήμα HTTP PUT μέσα στο PSM μετά-μοντέλο. Όπου και αν χρησιμοποιείται, σέβεται το αρχιτεκτονικό στυλ REST και έτσι υποδηλώνει τη δράση της ενημέρωσης ενός συγκεκριμένου υπάρχοντος πόρου. Επιπλέον, επειδή το SCASE παράγει διαδικτυακές [53]

54 Αυτόματη παραγωγή διεπαφών χρήστη για διαδικτυακές υπηρεσίες τύπου REST DELETE Όχι υπηρεσίες που δημιουργούν αυτόματα αναγνωριστικά πόρων, το ρήμα PUT δεν χρησιμοποιείται για τη δημιουργία πόρων Χρησιμοποιείται για τη μοντελοποίηση του ρήματος HTTP DELETE μέσα στο PSM μετά-μοντέλο. Όπου και αν χρησιμοποιείται, σέβεται το αρχιτεκτονικό στυλ REST και έτσι υποδηλώνει τη δράση της διαγραφής ενός συγκεκριμένου υπάρχοντος πόρου, καθώς και όλων των πόρων που σχετίζονται με αυτό LinkType Ο τύπος δεδομένων LinkType είναι μια απαρίθμηση, η οποία διαμορφώνει τους τρεις πιθανούς τύπους συνδέσμων υπερμέσων που υποστηρίζει το S-CASE. Αυτοί ορίζονται στον ακόλουθο πίνακα: LinkType PARENT SIBLING CHILD Προεπιλεγμένη Τιμή Ναι Όχι Όχι Επεξήγηση Κάθε φορά που ένα στοιχείο έχει μια ιδιότητα με τον τύπο PAREN, μοντελοποιεί έναν σύνδεσμο που συνδέει έναν συγκεκριμένο πόρο Α με μια πιθανή ενέργεια σε έναν από τους πόρους της υπηρεσίας που έχει ως σχετικό τον πόρο Α Κάθε φορά που ένα στοιχείο έχει μια ιδιότητα με τον τύπο SIBLING μοντελοποιεί έναν σύνδεσμο που συνδέει έναν συγκεκριμένο πόρο με μια πιθανή ενέργεια του εαυτού του Κάθε φορά που ένα στοιχείο έχει μια ιδιότητα με τον τύπο CHILD μοντελοποιεί έναν σύνδεσμο που συνδέει έναν συγκεκριμένο πόρο Α με μια πιθανή ενέργεια ενός από τους σχετικούς πόρους του Α RESTfulServicePSM Το RESTfulServicePSM είναι το βασικό στοιχείο του PSM μετά-μοντέλου. Μπορεί να υπάρχει ακριβώς ένα στοιχείο RESTfulServicePSM σε οποιοδήποτε PSM που παράγεται από το S-CASE. Περιλαμβάνει την τεχνολογικά εξειδικευμένη μορφή όλων των στοιχείων που αποτελούν μια υπηρεσία RESTful και σχετίζεται με αυτά τα στοιχεία μέσα από μία σύνθεση σχέσεων. Αυτό υποδηλώνει ότι οποιοδήποτε άλλο στοιχείο του PSM πρέπει να περιέχεται από αυτό το συγκεκριμένο ριζικό στοιχείο. [54]

55 Μεθοδολογία Σχήμα 25: RESTfulServicePSM Πίνακας 5: Ιδιότητες RESTfulServicePSM στοιχείου Όνομα Τύπος Πολλαπλότητα Περιγραφή Name EString 1 Αυτό είναι το όνομα, που παρέχεται από τον προγραμματιστή, για την υπηρεσία. Μεταξύ άλλων, χρησιμοποιείται για την ονομασία των φακέλων, που θα περιέχουν τα παραγόμενα αρχεία. [55]

56 Αυτόματη παραγωγή διεπαφών χρήστη για διαδικτυακές υπηρεσίες τύπου REST Πίνακας 6: Σχέσεις του RESTfulServicePSM Σχέση με το PIM στοιχείο Τύπος Πολλαπλότητα Δομικοί Περιορισμοί JavaResourceModel σύνθεση 0..* JavaResourceController σύνθεση 0..* JavaResourceModelManager σύνθεση 0..* JavaResourceControllerManager σύνθεση 0..* JavaAlgoResourceModel σύνθεση 0..* JavaAlgoResourceController σύνθεση 0..* Το RESTfulServicePSM μπορεί να περιέχει μηδέν ή περισσότερα JavaResourceModels. Οποιοδήποτε JavaResourceModel που υπάρχει στο PSM ανήκει στη λίστα των σχετικών JavaResourceModels του στοιχείου RESTfulServicePSM. Το RESTfulServicePSM μπορεί να περιέχει μηδέν ή περισσότερα στοιχεία JavaResourceController. Οποιοδήποτε JavaResourceController που υπάρχει στο PSM ανήκει στη λίστα των σχετικών JavaResourceControllers του στοιχείου RESTfulServicePSM. Το στοιχείο RESTfulServicePSM μπορεί να περιέχει μηδέν ή περισσότερα στοιχεία JavaResourceModelManager. Οποιοδήποτε JavaResourceModelManager που υπάρχει στο PSM ανήκει στη λίστα των σχετικών JavaResourceModelManagers του στοιχείου RESTfulServicePSM Το στοιχείο RESTfulServicePSM μπορεί να περιέχει μηδέν ή περισσότερα στοιχεία JavaResourceControllerManager. Κάθε JavaResourceControllerManager που υπάρχει στο PSM ανήκει στη λίστα των σχετικών JavaResourceControllerManagers του στοιχείου RESTfulServicePSM. Το στοιχείο RESTfulServicePSM μπορεί να περιέχει μηδέν ή περισσότερα JavaAlgoResourceModel στοιχεία. Οποιοδήποτε JavaAlgoResourceModel που υπάρχει στο PSM ανήκει στη λίστα των σχετικών JavaAlgoResourceModels του στοιχείου RESTfulServicePSM. Το στοιχείο RESTfulServicePSM μπορεί να περιέχει μηδενικά ή περισσότερα στοιχεία JavaAlgoResourceController. Οποιοδήποτε JavaAlgoResource Controller που υπάρχει στο PSM ανήκει στη λίστα των σχετικών [56]

57 Μεθοδολογία JPAController σύνθεση 1 JavaAlgoControllers του στοιχείου RESTfulServicePSM Το RESTfulServicePSM πρέπει να περιέχει ακριβώς ένα στοιχείο JPAController. Σε αυτό το σημείο θα αναφέρουμε συνοπτικά τις ιδιότητες και τις σχέσεις των στοιχείων του ServicePSM μεταμοντέλου που έχουν χρησιμοποιηθεί στην παραγωγή του κώδικα που θα παραθέσουμε στην επόμενη παράγραφο. JavaResourceModel: Το στοιχείο JavaResourceModel μοντελοποιεί τα δεδομένα ενός πόρου. Παρέχει την ονομασία του πόρου (parentname), τις ιδιότητες του πόρου μέσω της σχέσης PSMComponentProperty, και τους σχετικούς με αυτόν πόρους μέσω της σχέσης JavaResourceModelManager. PSMComponentProperty: Το στοιχείο PSMComponentProperty μοντελοποιεί τα χαρακτηριστικά των στιγμιοτύπων. Παρέχει το όνομα της ιδιότητας (name) και τον τύπο της ιδιότητας (type). JavaResourceController: Το στοιχείο JavaResourceController μοντελοποιεί τη διαδικτυακή διεπαφή ενός πόρου. Αυτό συμβαίνει σύμφωνα με το αρχιτεκτονικό στυλ REST, που σημαίνει ότι κάθε JavaResourceController έχει εκχωρηθεί ένα μοναδικό URI και τα HTTPVerbs χρησιμοποιούνται όπως προνοείται κατά την πρόσβαση σε αυτό το URI. Παρέχει την ονομασία του πόρου (parentname), το URI για την ανάκτηση συγκεκριμένου στιγμιότυπου του πόρου (controlleruri) και πληροφορίες σχετικά με τις μεθόδους GET, PUT και DELETE (HTTPActivity). HTTPActivity: Περιέχει πληροφορίες για τις επιτρεπτές HTTP μεθόδους για κάθε πόρο (ActivityHTTPVerb), HTTPActivityHandler: Το στοιχείο HTTPActivityHandler μοντελοποιεί την πραγματική υλοποίηση των απαιτούμενων ενεργειών που πρέπει να ληφθούν για να εξυπηρετήσει ένα αίτημα πελάτη που του διαβιβάζεται από την το HTTPActivity JavaResourceModelManager: Το στοιχείο JavaResourceModelManager συνδυάζεται πάντοτε με ένα JavaResourceModel. Έχει την ευθύνη να δημιουργήσει νέα στιγμιότυπα του σχετικού JavaResourceModel. Παρέχει επίσης την ονομασία του πόρου (parentname). JavaResourceControllerManager: Το στοιχείο JavaResourceControllerManager μοντελοποιεί τη διαδικτυακή διεπαφή ενός JavaResourceControllerManager. Παρέχει, επίσης, το όνομα του πόρου (parentname), το URI για την ανάκτηση της λίστας των στιγμιότυπων του πόρου (controlleruri) και πληροφορίες σχετικά με τις μεθόδους GET και POST. [57]

58 Αυτόματη παραγωγή διεπαφών χρήστη για διαδικτυακές υπηρεσίες τύπου REST JavaAlgoResourceModel: Τα στοιχεία JavaAlgoResourceModel μοντελοποιούν κάθε πόρο που δεν εμπίπτει στην κατηγορία εκείνων που σχεδιάστηκαν από το JavaResourceModels. Τέτοιοι πόροι ενσωματώνουν κάποιο είδος αλγορίθμου αντί για καθαρή μοντελοποίηση δεδομένων, όπως κάνουν τα JavaResourceModels. Ουσιαστικά πρόκειται για τους πόρους εκείνους που είναι υπεύθυνοι για την αναζήτηση στην βάση δεδομένων και την επικοινωνία με εξωτερική διαδικτυακή εφαρμογή. Παρέχουν το όνομα του πόρου (parentname). PSM Authentication Το στοιχείο περιέχει όλη την πληροφορία που απαιτείται για την ανάπτυξη μεθόδων ταυτοποίησης. Σχήμα 26: Authentication PSM AuthenticationPerformer: Παρέχει το όνομα του γονέα του μοντέλου ελέγχου ταυτότητας που χρησιμοποιείται για τον έλεγχο ταυτοποίησης χρήστη (authenticationmodelparentname) AuthenticationToken: Το AuthenticationPerformer στοιχείο πρέπει να έχει ακριβώς δύο AuthenticationTokens, ως διαπιστευτήρια, δηλαδή έναν κωδικό πρόσβασης και ένα όνομα χρήστη. Έχει ιδιότητες το όνομα του AuthenticationToken (name) και τον τύπο (type). Αν το όνομα είναι τύπου Password τότε το συγκεκριμένο AuthenticationToken θα πρέπει να αντιμετωπίζεται ως κωδικός πρόσβασης. [58]

59 Μεθοδολογία AuthenticationMode: Με αυτόν το στοιχείο, το HTTPActivity ή το HTTPActivityHandler θα είναι προσβάσιμο μόνο σε χρήστες που έχουν πιστοποιηθεί, σε επισκέπτες ή σε οποιονδήποτε από τους δύο, ανάλογα με τον τύπο του AuthenticationMode. PSM Database Searching Είναι στοιχείο των επεκτάσεων του PSM μεταμοντέλου με το οποίο γίνεται εφικτή η αναζήτηση στην βάση δεδομένων. Σχήμα 27: Database Searching PSM SearchController: Το στοιχείο SearchController χειρίζεται ένα υπάρχον JavaAlgoController, του Core PSM μεταμοντέλου, το οποίο θα ενσωματώσει την απαιτούμενη λειτουργικότητα για να χειριστεί τα εισερχόμενα αιτήματα για την αναζήτηση στη βάση δεδομένων. SearchHTTPActivity: Το στοιχείο SearchHTTPActivity χειρίζεται ένα HTTPActivity, του Core PSM μεταμοντέλου, το οποίο θα ενσωματώσει τον απαραίτητο κώδικα για να δεχτεί και να προωθήσει τις εισερχόμενες αιτήσεις αναζήτησης στη βάση δεδομένων (AnnHTTPActivity). SearchableJavaResourceModel:Το στοιχείο SearchableJavaResourceModel χειρίζεται ένα JavaResourceModel, του Core PSM μεταμοντέλου, το οποίο ευρετηριάζεται κατάλληλα με τους δείκτες [59]

60 Αυτόματη παραγωγή διεπαφών χρήστη για διαδικτυακές υπηρεσίες τύπου REST Lucene έτσι ώστε να μπορεί να αναζητηθεί. Έχει μία ή περισσότερες ιδιότητες αναζήτησης (SearchableProperty). PSM External Service Composition Είναι στοιχείο των επεκτάσεων του PSM μεταμοντέλου με το οποίο γίνεται εφικτή η επικοινωνία με εξωτερική διαδικτυακή υπηρεσία. Σχήμα 28: External Service Composition PSM JavaRESTClientController: Το στοιχείο JavaRESTClientController χειρίζεται ένα JavaAlgoController, του Core PSM μεταμοντέλου, το οποίο θα ενσωματώσει την απαιτούμενη λειτουργικότητα για να δεχτεί τα αιτήματα που θα προωθούνται για χειρισμό σε μια εξωτερική υπηρεσία (AnnJavaAlgoController). JavaRESTClientHTTPActivity: Το στοιχείο JavaRESTClientHTTPActivity χειρίζεται ένα HTTPActivity το οποίο θα ενσωματώσει το απαιτούμενο web API για να είναι σε θέση να δεχτεί αιτήματα που θα προωθηθούν και θα διαχειριστούν από μια εξωτερική υπηρεσία. [60]

61 Μεθοδολογία QueryParam: Το στοιχείο QueryParam μοντελοποιεί μια παράμετρο ερωτήματος που μπορεί να χρειαστεί να χρησιμοποιηθεί από το σύστημα όταν αλληλεπιδρά με την εξωτερική υπηρεσία. Έχει τις ιδιότητες όνομα (name) και τύπο (type). JavaOutputDataModel: Το στοιχείο JavaOutputDataModel μοντελοποιεί τη μορφή δεδομένων εξόδου μιας εξωτερικής υπηρεσίας (Property) Acceleo Project Στη συνέχεια, αφού αναλύσαμε τις εισόδους, την αρχιτεκτονική που ακολουθήθηκε και τα εργαλεία που χρησιμοποιήθηκαν, θα εξετάσουμε τμηματικά πώς σχεδιάστηκε και αναπτύχθηκε ο κώδικας που παρουσιάζεται στην παρούσα διπλωματική εργασία. Ο κώδικας αποτελείται από modules, καθένα από τα οποία δέχεται μία είσοδο και παράγει (ή όχι) ένα ή περισσότερα αρχεία. Στον πίνακα που ακολουθεί παρουσιάζονται συνοπτικά τα modules που αναπτύχθηκαν, η είσοδος αυτών, η έξοδος και μία συνοπτική περιγραφή. Στην συνέχεια θα γίνει μία λεπτομερής ανάπτυξη σε κάθε ένα από αυτά και θα παραθέσουμε τμήματα του κώδικα που υλοποιήθηκε. Όνομα Είσοδος Έξοδος Πίνακας 7: Επισκόπηση των modules του μετασχηματισμού Πολλαπλότητα Εξόδου Περιγραφή Generate AnnotationStack Όχι 0 Είναι το main module του μετασχηματισμού. Είναι υπεύθυνο για την κλήση των επιμέρους Modules Υπεύθυνο για την παραγωγή του Index AnnotationStack HTML 2..3 index.html αρχείου αλλά και του navbar.html που απαιτούνται για την ορθή λειτουργία της εφαρμογής Υπεύθυνο για την παραγωγή όλων των JS Controllers AnnotationStack JS 1..* αρχείων που απαιτούνται για την ορθή λειτουργία της εφαρμογής Views AnnotationStack HTML 1..* Υπεύθυνο για την παραγωγή όλων των HTML αρχείων που απαιτούνται για την ορθή λειτουργία της εφαρμογής Services AnnotationStack JS 1..2 Υπεύθυνο για την παραγωγή JS αρχείου που αφορά τις HTTP κλήσεις της εφαρμογής App AnnotationStack JS 1 Υπεύθυνο για την παραγωγή JS αρχείου απαραίτητου για την πλοήγηση και την αρχικοποίηση της εφαρμογής [61]

62 Αυτόματη παραγωγή διεπαφών χρήστη για διαδικτυακές υπηρεσίες τύπου REST Auth AnnotationStack JS HTML Search AnnotationStack JS HTML ExternalService AnnotationStack JS HTML 2 Υπεύθυνο για την παραγωγή ενός HTML και ενός JS αρχείου απαραίτητα για την λειτουργία της ταυτοποίησης χρήστη 2..* Υπεύθυνο για την παραγωγή ενός HTML και ενός JS αρχείου απαραίτητα για την λειτουργία της αναζήτησης στην βάση δεδομένων 2..* Υπεύθυνο για την παραγωγή ενός HTML και ενός JS αρχείου απαραίτητα για την λειτουργία της επικοινωνίας με την εξωτερική διαδικτυακή εφαρμογή Πιο αναλυτικά, θα παρουσιαστούν όλες οι Acceleo εκφράσεις, που χρησιμοποιήθηκαν για την ανάκτηση πόρων από το PSM μεταμοντέλο για την παραγωγή του επιθυμητού κώδικα. Στην αρχή, θα παρουσιαστούν τα τμήματα κώδικα που είναι υπεύθυνα για την βασική λειτουργία της διαδικτυακής εφαρμογής και στην συνέχεια εκείνα που είναι υπεύθυνα για τις επιπλέον λειτουργικότητες που αφορούν την ταυτοποίηση χρήστη, την αναζήτηση στη βάση δεδομένων και την επικοινωνία με εξωτερική διαδικτυακή εφαρμογή. Στο σημείο αυτό να αναφέρω πως για διευκόλυνση του αναγνώστη έχουν τροποποιηθεί ορισμένα κομμάτια του κώδικα ώστε να γίνει ευανάγνωστος, χωρίς να επηρεαστεί η λειτουργικότητα. Module generate Το module generate δέχεται ως είσοδο το στοιχείο AnnotationStack. Αποτελεί τη main κλάση του μετασχηματισμού και δεν παράγει καμία έξοδο. Ρόλος αυτού του module είναι η κλήση των επιμέρους modules, για την παραγωγή των απαιτούμενων αρχείων. Module Index Στο Module αυτό παράγονται σε κάθε εφαρμογή τουλάχιστον δύο αρχεία HTML και συγκεκριμένα το Index.html και το navbar.html. Το παραγόμενο αρχείο index.html είναι το αρχείο το οποίο είναι απαραίτητο για την λειτουργία της διαδικτυακής εφαρμογής καθώς σε αυτό περιέχονται όλες οι διευθύνσεις για όλες τις βιβλιοθήκες που χρειάζονται. Παράλληλα, περιέχεται η κύρια διάταξη της εφαρμογής και ο ρόλος του είναι εμφανίζει το κατάλληλο template/όψη σύμφωνα με τις ρυθμίσεις του $route service της AngulaJS. Το δεύτερο αρχείο navbar.html είναι υπεύθυνο για την δημιουργία ενός navigation bar ώστε να καταστεί δυνατή η πλοήγηση του χρήστη στην διαδικτυακή εφαρμογή. Στο module αυτό υπάρχει επίσης το ενδεχόμενο παραγωγής ενός τρίτου αρχείου του main.html το οποίο είναι υπεύθυνο για την αρχική σελίδα της διαδικτυακής εφαρμογής. Πιο αναλυτικά ελέγχεται ο αριθμός των πόρων οι οποίοι δεν είναι σχετικοί από [62]

63 Μεθοδολογία άλλους πόρους. Αν ο αριθμός αυτός είναι μεγαλύτερος της μονάδας τότε δημιουργείται το αρχείο αυτό για να μπορέσει να επιλέξει ο χρήστης τον πόρο στον οποίο θέλει να πλοηγηθεί. Σε αντίθετη περίπτωση αν ο αριθμός είναι μονάδα τότε δεν παράγεται το αρχείο αυτό και η αρχική σελίδα του χρήστη είναι το σύνολο των στιγμιότυπων του κυρίαρχου πόρου. Για την παραγωγή του αρχείου index.html χρησιμοποιούνται τα ερωτήματα Ερώτημα 1: getmainresources και Ερώτημα 2: relatedresource ώστε να ορισθούν σαφώς οι αντίστοιχοι ελεγκτές controllers στην λίστα των scripts. Επίσης γίνονται και οι αντίστοιχοι έλεγχοι που έχουν να κάνουν με το εάν η διαδικτυακή εφαρμογή έχει την δυνατότητα ταυτοποίησης χρήστη, αναζήτησης στη βάση δεδομένων και επικοινωνίας με εξωτερική διαδικτυακή υπηρεσία στους οποίους θα αναφερθούμε στην πορεία. Θα παραθέσουμε ενδεικτικά δύο τμήματα της διαδικασίας. Αλγόριθμος 1: Έλεγχος πλήθους πόρων για τον ορισμό των ελεγκτών στην λίστα των scripts [if (anannotationstack.getmainresources()->size()>1)] [for (p : JavaResourceModelManager anannotationstack.getmainresources())] <script src="./js/controllers/[p.parentname/].controller.js"></script> [/for] [else] <script src="./js/controllers/[anannotationstack.getmainresources()->at(1).parentname/].controller.js"> </script> [/if] [63]

64 Αυτόματη παραγωγή διεπαφών χρήστη για διαδικτυακές υπηρεσίες τύπου REST Πίνακας 8: Περιγραφή Αλγορίθμου 1 Βήματα Περιγραφή 1. Έλεγξε αν το μέγεθος του οργανωμένου συνόλου τύπου JavaResourceModelManager που επιστρέφει το query getmainresources είναι μεγαλύτερο της μονάδας 2. Αν το βήμα 1 είναι αληθές για κάθε στοιχείο anannotationstack.getmainresources() του τύπου JavaResourceModelManager ανέθεσε τον controller στην λίστα των scripts χρησιμοποιώντας την ιδιότητα του parentname του 3. Διαφορετικά ανέκτησε το parentname του AnnotationStack.getMainResources()->at(1) Ερωτήματα που χρησιμοποιούνται: Ερώτημα 1: getmainresources 1. Έλεγξε αν το πλήθος των πόρων που δεν είναι σχετικοί από άλλους πόρους είναι μεγαλύτερο της μονάδας 2. Αν ισχύει το 1 τότε ενέθεσε στην λίστα των scripts έναν αρχείο που αντιστοιχεί στον ελεγκτή για κάθε «κύριο» πόρο με την ονομασία του αρχείου να περιλαμβάνει το όνομα του πόρου 3. Διαφορετικά ανέθεσε ένα μόνο αρχείο ελεγκτή, καθώς έχουμε έναν κύριο πόρο, με την ονομασία να περιλαμβάνει και πάλι το όνομα του πόρου Αλγόριθμος 2: Έλεγχος για την ύπαρξη ή όχι ταυτοποίησης χρήστη [if (anannotationstack.bhasauthenticationannotation)] <script src="./js/controllers/signin.controller.js"></script> <script src="./js/services/authentication.service.js"></script> [/if] Πίνακας 9: Περιγραφή Αλγορίθμου 2 Βήματα 1. Έλεγξε αν anannotationstack.bhasauthenticationannotation 2. Αν το 1 είναι αληθές εισήγαγε στην λίστα των scripts τα αρχεία signin.controller.js, authentication.service.js Ερωτήματα που χρησιμοποιούνται: - Περιγραφή 1. Έλεγξε αν η διαδικτυακή υπηρεσία έχει ταυτοποίηση χρήστη 2. Αν το 1 ισχύει τότε στην λίστα των scripts πρέπει να προστεθούν οι ελεγκτές που είναι υπεύθυνοι για την ταυτοποίηση Για την δημιουργία του αρχείου navbar.html ακολουθήθηκε η ίδια λογική. Στο σημείο αυτό απλά να αναφέρουμε ότι η μπάρα πλοήγησης έχει δημιουργηθεί έτσι ώστε όταν η διαδικτυακή εφαρμογή έχει τις λειτουργίες της ταυτοποίησης, της αναζήτησης και της εξωτερικής διαδικτυακής εφαρμογής να δημιουργούνται και τα αντίστοιχα (dropdown) μενού. Επίσης, όσον αφορά την ταυτοποίηση έχουν [64]

65 Μεθοδολογία δημιουργηθεί τρεις επιπλέον επιλογές: η δυνατότητα να κάνει ο χρήστης εγγραφή (signup) στην εφαρμογή, να κάνει σύνδεση (login) και αποσύνδεση (logout) αντίστοιχα από αυτήν. Αλγόριθμος 3: Δημιουργία dropdown menu για την λειτουργία της αναζήτησης [if (anannotationstack.bhassearchlayer)] <div class="ui simple dropdown item" ><i class="search icon"></i>search<i class="dropdown icon"></i> <div class="menu"> [for (asearchcontroler : SearchController anannotationstack. getsearchcontrollerannotations())] <a class="item" href="#![asearchcontroler.issearchcontroller.annotatesjavaalgocontroller. parentname/]">[asearchcontroler.issearchcontroller.annotatesjavaalgocontr oller.parentname/] </a> [/for] </div> </div> [/if] Πίνακας 10: Περιγραφή Αλγορίθμου 3 Βήματα Περιγραφή 1. Έλεγξε αν anannotationstack.bhassearchlayer 2. Αν το 1 αληθές για κάθε στοιχείο anannotationstack.getsearchcontrollerannotations() του τύπου SearchController ανέκτησε το στοιχείο annotatesjavaalgocontroller.parentname για την δρομολόγηση του χρήστη στους πόρους που είναι υπεύθυνοι για την αναζήτηση 1 2 Έλεγξε αν η διαδικτυακή υπηρεσία έχει αναζήτηση στην βάση δεδομένων Αν το 1 ισχύει τότε δημιουργείται ένα dropdown menu με επιλογές τα ονόματα των πόρων που είναι υπεύθυνοι για την αναζήτηση στην βάση Ερωτήματα που χρησιμοποιούνται: Ερώτημα 6: getsearchcontrollerannotations Module Views Το module αυτό είναι υπεύθυνο για την παραγωγή όλων των αρχείων HTML που αποτελούν τις όψεις της διαδικτυακής εφαρμογής. Ανάλογα με την πλοήγηση του χρήστη εμφανίζεται και το αντίστοιχο αρχείο το οποίο περιγράφει τον τρόπο με τον οποίο θα παρουσιάζονται τα δεδομένα της διαδικτυακής υπηρεσίας. Πιο αναλυτικά δημιουργείται ένα HTML αρχείο για κάθε κύριο πόρο το οποίο εμφανίζει όλα τα στιγμιότυπα του πόρου μαζί με τις ιδιότητες του. Στην συνέχεια για τον εκάστοτε πόρο ελέγχεται αν έχει πόρους που σχετίζονται από αυτόν, και εάν αυτή η συνθήκη ικανοποιείται, παράγεται το αντίστοιχο HTML αρχείο για την εμφάνιση αντίστοιχα των σχετικών πόρων και των ιδιοτήτων του. Στο σημείο αυτό πρέπει να αναφερθεί ότι σε περίπτωση που ο πόρος προς εμφάνιση είναι αυτός που είναι υπεύθυνος και για την ταυτοποίηση του [65]

66 Αυτόματη παραγωγή διεπαφών χρήστη για διαδικτυακές υπηρεσίες τύπου REST χρήστη τότε ένα διαφορετικό αρχείο παράγεται. Τέλος για κάθε πόρο δημιουργείται και ένα αρχείο που περιλαμβάνει μία φόρμα για την εγγραφή ενός νέου στιγμιότυπου του πόρου. Παρακάτω θα δείξουμε ορισμένα τμήματα του κώδικα που υλοποιήθηκε. Ανάκτηση ιδιοτήτων πόρου Για την εμφάνιση μίας αναλυτικής λίστας με τα στοιχεία ενός πόρου απαιτείται η ανάκτηση των ιδιοτήτων του. Η πληροφορία αυτή περιέχεται στα PSMComponentProperties του κάθε JavaResourceModel στοιχείου και γίνονται έλεγχοι ώστε να αναπαρασταθεί σωστά η εκάστοτε ιδιότητα. Στον παρακάτω αλγόριθμο θα παρουσιαστούν τμήματα του κώδικα που είναι υπεύθυνα για αυτή την λειτουργία. Αλγόριθμος 4: Αναπαράσταση ιδιοτήτων πόρου - εμφάνιση ιδιότητας image [for (c : PSMComponentProperty p.hasrelatedjavarmodel.javarmodelhasproperty)] [if (c.type='string')] [if (c.name='image')] [/if] [/if] [/for] <img class="ui fluid image " ng-src="{{image}}" style="" /> Πίνακας 11: Περιγραφή Αλγορίθμου 4 Βήματα 1. Για κάθε p.hasrelatedjavarmodel.javarmodelhasproperty του τύπου PSMComponentProperty 2. Αν το type του c είναι string και αν το name του c είναι image πρόσθεσε την μορφοποίηση για την προβολή εικόνας Περιγραφή 1. Για κάθε ιδιότητα του πόρου 2. Έλεγξε αν ο τύπος της ιδιότητας είναι αλφαριθμητικό και εάν το όνομα της ιδιότητας είναι image. Ερωτήματα που χρησιμοποιούνται: - Στο σημείο αυτό πρέπει να αναφερθεί ότι η διαδικτυακή εφαρμογή που αναπτύσσεται, στα πλαίσια της παρούσας διπλωματική εργασίας, έχει λάβει υπόψιν την ύπαρξη μιας ιδιότητας που είναι αρμόδια για την αναπαράσταση εικόνων στον χρήστη. Για τον σκοπό αυτό αν κάποιος πόρος έχει μία ιδιότητα για την εμφάνιση εικόνων το όνομα αυτής πρέπει να είναι image. [66]

67 Μεθοδολογία Στο παρακάτω τμήμα κώδικα γίνεται έλεγχος για την αναπαράσταση οποιασδήποτε άλλης ιδιότητας που δεν είναι εικόνα, μέσα από μία επαναληπτική διαδικασία όλων των ιδιοτήτων του πόρου. [67]

68 Αυτόματη παραγωγή διεπαφών χρήστη για διαδικτυακές υπηρεσίες τύπου REST Αλγόριθμος 5: Αναπαράσταση ιδιοτήτων πόρου για κάθε πιθανό τύπο [for (c : PSMComponentProperty p.hasrelatedjavarmodel.javarmodelhasproperty)] [if (c.type='string')] [if not(c.name='image')] [if (c.bisnamingproperty)] <h3>{{model.[p.parentname/].[c.name/]}}</h3> [else] <p><b>[c.name.toupperfirst()/]: </b>{{model.[p.parentname/].[c.name/]}}</p> [/if] [/if] [elseif (c.type='date')] <p><b>[c.name.toupperfirst()/]: </b>{{model.[p.parentname/].[c.name/] {{model.[p.parentname/].[c.name/] date:'shorttime'}}</p> [elseif (c.type='int' or c.type = 'float')] [if not(c.bisprimaryidentifier)] <p><b>[c.name.toupperfirst()/]: </b>{{model.[p.parentname/].[c.name/]}}<p> [/if] [/if] [/for] Πίνακας 12: Περιγραφή Αλγορίθμου 5 Βήματα 1. Για κάθε p.hasrelatedjavarmodel.javarmodelhasproperty του τύπου PSMComponentProperty 2. Αν το type του c είναι string 2.1. και το name του δεν είναι image και αληθεύει η συνθήκη c.bisnamingproperty ανέκτησε την επικεφαλίδα. 2.2.Αν η συνθήκη c.bisnamingproperty δεν αληθεύει ανέκτησε τις υπόλοιπες ιδιότητες 3. Αν το type του c είναι date εμφάνισε την ημερομηνία στην σωστή μορφή 4. Αν το type του c είναι int ή float εισήγαγε την σωστή μορφή για αριθμό Περιγραφή 1. Για κάθε ιδιότητα του πόρου 2. Έλεγξε αν ο τύπος της ιδιότητας είναι αλφαριθμητικό 2.1 και εάν το όνομα της ιδιότητας δεν είναι image και έχει οριστεί ως naming property εισήγαγε σαν επικεφαλίδα την ιδιότητα αυτή 2.2 Διαφορετικά εμφάνησε με άλλη μορφοποίηση τις υπολοιπς ιδιότητες 3. Αν ο τύπος της ιδότητας είναι ημερομηνία εισήγαγε πεδίο με ημερολόγιο 4. Αν ο τύπος της ιδιότητας είναι αριθμός εισήγαγε κατάλληλο πεδίο για αριθμό Ερωτήματα που χρησιμοποιούνται: - Η ίδια διαδικασία εφαρμόζεται και στην περίπτωση της δημιουργίας του αρχείου που είναι υπεύθυνο για την φόρμα εγγραφής νέου στιγμιότυπου του πόρου. Στο παρακάτω τμήμα του κώδικα βλέπουμε ότι αλλάζει η δήλωση του type ανάλογα με τον τύπο της ιδιότητας. Αυτό είναι αναγκαίο, καθώς αν μία ιδιότητα είναι τύπου ακεραίου, ή γενικά αριθμός, το πλαίσιο το οποίο θα παραχθεί για την εισαγωγή των δεδομένων θα επιτρέπει στον χρήστη να εισάγει μόνο αριθμό και όχι αλφαριθμητικό. [68]

69 Μεθοδολογία Αλγόριθμος 6: Έλεγχος του τύπου ιδιότητας του πόρου για ορθή εισαγωγή στοιχείων στην φόρμα [if (c.type='int' or c.type = 'float')] [if not(c.bisprimaryidentifier)] <input type="number" name="[c.name/]" placeholder="[c.name.toupperfirst()/]" ngmodel="model.[c.name/]"> [/if] [elseif (c.type='date')] <input type="datetime-local" name="[c.name/]" ng-model="model.[c.name/]"> [/if] Η λογική του Αλγόριθμος 6 είναι αντίστοιχη της παραπάνω και δεν θα δοθεί περιγραφή. Ανάκτηση πόρων για μεθόδους PUT και DELETE Συνήθως, η χρήση ή μη των μεθόδων PUT και DELETE διαφέρει από πόρο σε πόρο σε μία υπηρεσία. Επομένως πρέπει να υπάρχει ο αντίστοιχος έλεγχος για την παραγωγής ή όχι κώδικα για τις μεθόδους αυτές για κάθε πόρο ξεχωριστά. Επομένως για να δίνεται η δυνατότητα στο χρήστη να μπορεί να διαγράψει ένα στιγμιότυπο (DELETE) ή να τον τροποποιήσει (PUT) πρέπει να ελεγχθεί αρχικά αν ο πόρος διαθέτει αυτή την δυνατότητα και στην συνέχεια, σε περίπτωση που υπάρχει ταυτοποίηση χρήστη στην διαδικτυακή εφαρμογή, να γίνει και ο αντίστοιχος έλεγχος εάν ο χρήστης έχει εισάγει τα διαπιστευτήρια του. Στον αλγόριθμο που ακολουθεί παρουσιάζεται η περίπτωση ενός αιτήματος DELETE, ωστόσο η λογική είναι πανομοιότυπα και για το αίτημα PUT. Αλγόριθμος 7: Έλεγχος ύπαρξης αιτήματος DELETE στον πόρο και εμφάνιση αντίστοιχης μορφοποίησης [for (ajavaresourcecontroller : JavaResourceController anannotationstack.hascorepsm.hasjavarcontroller)] [for (httpactivity : HTTPActivity ajavaresourcecontroller.javarcontrollerhashttpactivity)] [if (httpactivity.activityhttpverb.tostring() = 'DELETE' and ajavaresourcecontroller.parentname = p.parentname)] <div class="ui vertical animated negative button" tabindex="0" [if (anannotationstack.bhasauthenticationannotation)]ng-if="islogedin"[/if] ngcontroller="[p.parentname.toupperfirst()/]controller" ngclick="delete[p.parentname.toupperfirst()/]([p.parentname/].linkuri)"> <div class="hidden content">delete</div> <div class="visible content">i class="trash icon"></i></div> </div> [/if][/for][/for] [69]

70 Αυτόματη παραγωγή διεπαφών χρήστη για διαδικτυακές υπηρεσίες τύπου REST Πίνακας 13: Περιγραφή Αλγορίθμου 7 Βήματα 1. Για κάθε anannotationstack.hascorepsm.hasjavarcontroller του τύπου JavaResourceController 2. Για κάθε ajavaresourcecontroller.javarcontrollerhashttpactivity του τύπου HTTPActivity 3. Έλεγξε αν το ActivityHTTPVerb είναι DELETE και αν το parentname του ajavaresourcecontroller ισούται με το parentname του τρέχοντος JavaResourceModelManager Περιγραφή 1. Για κάθε πόρο της διαδικτυακής εφαρμογής 2. Για κάθε CRUD αίτημα που έχει ορισθεί σε αυτόν 3. Έλεγξε αν το CRUD verb μετασχηματισμένο σε string ταυτίζεται με το DELETE και εμφάνισε αντίστοιχο κουμπί που επιτρέπει την διαγραφή στιγμιότυπου πόρου Ερωτήματα που χρησιμοποιούνται: - Πίνακας 14: Ερωτήματα που χρησιμοποιούνται στο module views Queries Ερώτημα 1: getmainresources Ερώτημα 2: relatedresource Ερώτημα 3: getauthenticationperfomer Module Controllers Το module αυτό παράγει ένα JS αρχείο για κάθε κύριο πόρο που περιγράφεται στο PSM μεταμοντέλο. Κάθε αρχείο που παράγεται είναι υπεύθυνο για την ορθή λειτουργία της εφαρμογής όσον αφορά την αποστολή αιτημάτων και την επεξεργασία της αντίστοιχης απόκρισης των αιτημάτων αυτών. Εκτός από τους controllers που αντιστοιχούν σε κάθε πόρο δημιουργούνται και κάποιοι controllers που είναι υπεύθυνοι για τη σωστή λειτουργία της εφαρμογής και την εμφάνιση των αντίστοιχων αποτελεσμάτων στις όψεις. Στο σημείο αυτό θα αναφερθούμε σε τμήματα αυτοματισμού μερικών βασικών λειτουργιών. CRUD αιτήματα Για κάθε πόρο δημιουργούνται οι αντίστοιχες συναρτήσεις που είναι αρμόδιες για την αποστολή αιτημάτων στον διακομιστή, δηλαδή για τα αιτήματα GET, PUT, POST και DELETE. Για την ορθή λειτουργία, στο σημείο αυτό, πρέπει να γίνει ο έλεγχος αν ο αντίστοιχος πόρος έχει την δυνατότητα να εκτελέσει το αντίστοιχο αίτημα. Επίσης γίνεται ένας ακόμα έλεγχος στην περίπτωση που η εφαρμογή έχει τη δυνατότητα ταυτοποίησης χρήστη για να διευκρινιστεί εάν ο πόρος έχει τη δυνατότητα να κάνει το συγκεκριμένο αίτημα μόνο αν έχουν ταυτοποιηθεί τα στοιχεία του, δηλαδή αν έχει κάνει login στην εφαρμογή. Περισσότερες [70]

71 Μεθοδολογία λεπτομέρειες όσον αφορά την ταυτοποίηση χρήστη και τις συνθήκες που έχουν ληφθεί υπόψιν θα αναλυθούν στη συνέχεια του κεφαλαίου. Στον Αλγόριθμος 8 φαίνεται μία κλήση GET για κάθε πόρο του συστήματος. Αλγόριθμος 8: Ανάκτηση πόρων για την δημιουργία HTTP αιτημάτων - GET [for (ajavaresourcecontroller : JavaResourceController anannotationstack.hascorepsm.hasjavarcontroller)] [for (httpactivity : HTTPActivity ajavaresourcecontroller.javarcontrollerhashttpactivity)] [if (httpactivity.activityhttpverb.tostring() = 'GET' and ajavaresourcecontroller.parentname = p.parentname)] $scope.getall[p.parentname.toupperfirst()/]s = function() { $scope.[p.parentname.toupperfirst()/]s = dataservice. [if (anannotationstack.bhasauthenticationannotation)] [if (httpactivity.hasbothmodeauthentication(anannotationstack))] data[else]dataauth[/if][else]data[/if](config.[p.parentname/]url).getall() }; [/if] [/for] [/for] Η περιγραφή του παραπάνω αλγορίθμου είναι παρόμοια με αυτή που περιεγράφηκε στον Πίνακας 13. Αντίστοιχη είναι και η διαδικασία για την υλοποίηση των αιτημάτων PUT, DELETE και POST. Στον παρακάτω αλγόριθμο φαίνεται το τμήμα που είναι υπεύθυνο για τη διαχείριση αιτημάτων DELETE. Όπως μπορεί να δει κανείς, όταν ο χρήστης επιλέγει να διαγράψει ένα στιγμιότυπο του πόρου γίνεται έλεγχος με ένα αναδυόμενο παράθυρο για την επιβεβαίωση της ενέργειάς του. Αφού γίνει και η επιβεβαίωση από τον χρήστη, εκτελείται το αίτημα διαγραφής και εμφανίζεται αντίστοιχο μήνυμα επιτυχίας ή αποτυχίας. [71]

72 Αυτόματη παραγωγή διεπαφών χρήστη για διαδικτυακές υπηρεσίες τύπου REST Αλγόριθμος 9: Ανάκτηση πόρων για την δημιουργία HTTP αιτημάτων - DELETE [for (ajavaresourcecontroller : JavaResourceController anannotationstack.hascorepsm.hasjavarcontroller)] [for (httpactivity : HTTPActivity ajavaresourcecontroller.javarcontrollerhashttpactivity)] [if (httpactivity.activityhttpverb.tostring() = 'DELETE' and ajavaresourcecontroller.parentname = p.parentname)] $scope.delete[p.parentname.toupperfirst()/] = function (uri){ if ($window.confirm("are you sure you want to delete this [p.parentname.toupperfirst()/]?")) { dataservice. [if (anannotationstack.bhasauthenticationannotation)] [if httpactivity.hasbothmodeauthentication(anannotationstack))] data[else]dataauth[/if][else]data[/if](uri).delete().$promise.then( //on success function () { Notification.success("The [p.parentname.toupperfirst()/] has been deleted successfully ") $route.reload(); }, //error function () { Notification.error("Error, Try again"); } )} }; [/if] [/for] [/for] Πίνακας 15: Περιγραφή Αλγορίθμου 9 Βήματα Περιγραφή 1. Για κάθε anannotationstack.hascorepsm.hasjavarcontroller τύπου JavaResourceController 2. Για κάθε ajavaresourcecontroller.javarcontrollerhashttpactiv ity τύπου HTTPActivity 3. Έλεγξε αν το ActivityHTTPVerb είναι DELETE και αν το parentname του ajavaresourcecontroller ισούται με το parentname του τρέχοντος JavaResourceModelManager και αν ναι εμφάνισε popup παράθυρο 4. Έλεγξε αν anannotationstack.bhasauthenticationannotation 5. Αν ισχύει το 4 έλεγξε αν httpactivity.hasbothmodeauthentication(anannotatio nstack) και στείλε το αντίστοιχο αίτημα delete Ερωτήματα που χρησιμοποιούνται: Ερώτημα 4: hasbothmodeauthentication 1. Για κάθε πόρο της διαδικτυακής εφαρμογής 2. Για κάθε CRUD αίτημα που έχει ορισθεί σε αυτόν 3. Έλεγξε αν το CRUD verb μετασχηματισμένο σε string ταυτίζεται με το DELETE και εμφάνισε αναδυόμενο παράθυρο επιβεβαίωσης 4. Έλεγξε αν υπάρχει ταυτοποίηση χρήστη στην υπηρεσία 5. Αν ισχύει το 4 τότε έλεγξε αν για την συγκεκριμένη ενέργεια (delete) ο χρήστης πρέπει να έχει εισάγει τα διαπιστευτήρια του για την εκτέλεση του αιτήματος ή όχι Στην συνέχεια θα παραθέσουμε την διαδικασία που ακολουθήθηκε για την εύρεση εκείνων των πόρων που είναι σχετικοί από άλλους πόρους. Για να υπάρχει η δυνατότητα στον χρήστη από τον πρωταρχικό πόρο να μεταφερθεί στους πόρους που είναι σχετικοί από αυτόν αλλά και να δει τις αντίστοιχες ιδιότητές τους [72]

73 Μεθοδολογία ακολουθήθηκε η παρακάτω διαδικασία. Καλείται μία συνάρτηση details() ή οποία ξεκινάει με την ανάκτηση ενός στιγμιότυπου του πόρου, αφού προηγηθεί ο έλεγχος που αναλύθηκε παραπάνω (το τμήμα αυτό δεν θα παρουσιαστεί ξανά για ευκολότερη ανάγνωση του κώδικα). Στην πορεία μέσα από μία επαναληπτική διαδικασία στην απόκριση που επιστρέφει ο διακομιστής αναζητούνται τα στοιχεία εκείνα που έχουν την ιδιότητα παιδί-child, σύμφωνα με τη δομή μίας απόκρισης όπως έχει οριστεί από το S-CASE, και που έχουν την ιδιότητα GET αιτήματος. Αυτή η επαναληπτική διαδικασία εκτελείται τόσες φορές όσες και ο αριθμός των σχετικών πόρων. Αλγόριθμος 10: Ανάκτηση πόρων σχετικών από τον πόρο Έχει προηγηθεί GET αίτημα [for (c : JavaResourceModelManager anannotationstack.relatedresource(p.hasrelatedjavarmodel))] if (link.linktype == 'Child' && link.linkverb == 'GET') { if (link.linkuri.substr(link.linkuri.lastindexof('/') + 1) == '[c.parentname/]') { [for (ajavaresourcecontroller : JavaResourceController anannotationstack.hascorepsm.hasjavarcontroller)] [for (httpactivity : HTTPActivity ajavaresourcecontroller.javarcontrollerhashttpactivity)] [if (httpactivity.activityhttpverb.tostring() = 'GET' and ajavaresourcecontroller.parentname = c.parentname and self.name=ajavaresourcecontroller.firstonly(httpactivity.activityhttpverb.tostring()))] dataservice. [if (anannotationstack.bhasauthenticationannotation)] [if(httpactivity.hasbothmodeauthentication(anannotationstack))] data[else]dataauth[/if][else]data[/if](link.linkuri).getall(function (callbackdata) { [/if][/for][/for] angular.foreach(callbackdata.linklist, function (link) { if (link.linktype == 'Child') { [c.parentname/]links.push(link.linkuri) } }) for (i = 0; i < [c.parentname/]links.length; i++) { get[c.parentname.toupperfirst()/]detail([c.parentname/]links['['/]i]) } }) } } [/for] [73]

74 Αυτόματη παραγωγή διεπαφών χρήστη για διαδικτυακές υπηρεσίες τύπου REST Πίνακας 16: Περιγραφή Αλγορίθμου 10 Βήματα Περιγραφή 1. Για κάθε anannotationstack.hascorepsm.hasjavarcontroller τύπου JavaResourceController 2. Για κάθε ajavaresourcecontroller.javarcontrollerhashttpactiv ity τύπου HTTPActivity 3. Έλεγξε αν το ActivityHTTPVerb είναι DELETE και αν το parentname του ajavaresourcecontroller ισούται με το parentname του τρέχοντος JavaResourceModelManager και αν ναι εμφάνισε popup παράθυρο 4. Έλεγξε αν anannotationstack.bhasauthenticationannotation 5. Αν ισχύει το 4 έλεγξε αν httpactivity.hasbothmodeauthentication(anannotatio nstack) και στείλε το αντίστοιχο αίτημα delete Ερωτήματα που χρησιμοποιούνται: Ερώτημα 4: hasbothmodeauthentication 1. Για κάθε πόρο της διαδικτυακής εφαρμογής 2. Για κάθε CRUD αίτημα που έχει ορισθεί σε αυτόν 3. Έλεγξε αν το CRUD verb μετασχηματισμένο σε string ταυτίζεται με το DELETE και εμφάνισε αναδυόμενο παράθυρο επιβεβαίωσης 4. Έλεγξε αν υπάρχει ταυτοποίηση χρήστη στην υπηρεσία 5. Αν ισχύει το 4 τότε έλεγξε αν για την συγκεκριμένη ενέργεια (delete) ο χρήστης πρέπει να έχει εισάγει τα διαπιστευτήρια του για την εκτέλεση του αιτήματος ή όχι Πίνακας 17: Ερωτήματα που χρησιμοποιούνται στο module controllers Queries Ερώτημα 1: getmainresources Ερώτημα 2: relatedresource Ερώτημα 3: getauthenticationperfomer Ερώτημα 4: hasbothmodeauthentication Ερώτημα 5: getauthenticationlayerbothmodeannotations Module Services Το module αυτό είναι υπεύθυνο για την παραγωγή των services της διαδικτυακής εφαρμογής. Παράγει τουλάχιστον ένα JS αρχείο το services.js το οποίο είναι υπεύθυνο για τις κλήσεις της διαδικτυακής εφαρμογής. Επίσης παράγεται και ένα δεύτερο αρχείο JS, στην περίπτωση που η εφαρμογή απαιτεί ταυτοποίηση, το authentication.service.js. Στο module αυτό δεν χρειάστηκε ιδιαίτερος έλεγχος καθώς υλοποιούνται δύο διαφορετικές συναρτήσεις ανάλογα με το αν υπάρχει ταυτοποίηση στην εφαρμογή ή όχι. Στην πρώτη περίπτωση, η διαφορά έγκειται στο γεγονός ότι μαζί με το αίτημα που αποστέλλεται κάθε φορά στέλνονται και τα headers για την ταυτοποίηση, δηλαδή μία κωδικοποίηση των ιδιοτήτων username και password που έχει θέσει ο χρήστης στην διαδικτυακή υπηρεσία. Στον παρακάτω αλγόριθμο θα δείξουμε τις κλήσεις που [74]

75 Μεθοδολογία γίνονται μαζί με την προαναφερθείσα ταυτοποίηση, στην αντίθετη περίπτωση απλά απουσιάζουν τα headers από τις παραμέτρους. Αλγόριθμος 11: 'Έλεγχος ύπαρξης δυνατότητας authentication και υλοποίηση CRUD αιτημάτων [if (anannotationstack.bhasauthenticationannotation)] function dataauth(uri) { return $resource(uri, {}, { getall: { method: 'GET', headers: headers }, save: { method: 'POST', headers: headers }, delete: { method: 'DELETE', headers: headers }, update: { method: 'PUT', headers: headers } }) }; [/if] Πίνακας 18: Ερωτήματα που χρησιμοποιούνται στο module services Ερώτημα 3: getauthenticationperfomer Queries Ερώτημα 4: hasbothmodeauthentication Ερώτημα 5: getauthenticationlayerbothmodeannotations Module App Το module App δέχεται ως είσοδο το στοιχείο anannotationstack και παράγει ένα JS αρχείο με την ονομασία app.js. Το αρχείο αυτό είναι υπεύθυνο για την περιγραφή των δυνατών διαδρομών, που μπορεί να επιλέξει ένας χρήστης μέσω της διαδικτυακής εφαρμογής πελάτη. Επίσης στο αρχείο αυτό υπάρχουν κάποιες σταθερές οι οποίες διαμορφώνουν την εφαρμογή καθώς σε κάθε μία ανατίθεται ένα αντίστοιχο URI. Τέλος χρησιμοποιείται η υπηρεσία ui-notification / Notification που είναι υπεύθυνη για την εμφάνιση μνημάτων στον χρήστη. [75]

76 Αυτόματη παραγωγή διεπαφών χρήστη για διαδικτυακές υπηρεσίες τύπου REST.constant('config', { Αλγόριθμος 12: Ανάθεση URI στις αντίστοιχες σταθερές [for (p : JavaResourceModelManager anannotationstack.getmainresources())] [p.parentname/]url: ' [/for] [if (anannotationstack.bhasauthenticationannotation)] [for (p : JavaResourceModelManager anannotationstack.getmainresources())] [if (p.parentname = anannotationstack.getauthenticationperformer().authenticationmodelparentname)] signinurl: ' mer().authenticationmodelparentname/]', [else] [for (arelatedresource : JavaResourceModelManager anannotationstack.relatedresource(p.hasrelatedjavarmodel))] [if (arelatedresource.parentname = anannotationstack.getauthenticationperformer().authenticationmodelparentname)] [p.parentname/]url: ' [/if][/for][/if][/for][/if] [if (anannotationstack.bhassearchlayer)] [for (a : SearchController anannotationstack.getsearchcontrollerannotations())] [a.issearchcontroller.annotatesjavaalgocontroller.parentname/]url: ' roller.controlleruri/]', [/for][/if] [if (anannotationstack.bhasexternalservicelayer)] [for (a : JavaRESTClientController anannotationstack.getjavarestclientcontrollerannotations())] [a.isjavarestclientcontroller.annotatesjavaalgocontroller.parentname/]url: ' AlgoController.controllerURI/]', [/for][/if] }) [76]

77 Μεθοδολογία Πίνακας 19: Περιγραφή Αλγορίθμου 12 Βήματα 1. Για κάθε anannotationstack.getmainresources τύπου JavaResourceModelManager ανέκτησε το parentname και δημιούργησε το url 2. Έλεγξε αν anannotationstack.bhasauthenticationannotation και εάν ισχύει για κάθε anannotationstack.getmainresources έλεγξε αν το parent name του p ισούται με το anannotationstack.getauthenticationperformer().auth enticationmodelparentname 3. Εάν ισχύει το 2 δημιούργησε ένα url signin. 4. Έλεγξε αν anannotationstack.bhassearchlayer και αν ισχύει για κάθε anannotationstack.getsearchcontrollerannotations() δημιούργησε τα αντίστοιχα url 5. Έλεγξε αν anannotationstack.bhasexternalservicelayer και αν ισχύει για κάθε anannotationstack.getjavarestclientcontrollerannot ations() δημιούργησε τα αντίστοιχα url Περιγραφή 1. Για κάθε κύριο πόρο δημιούργησε τα urls με τα οποία θα αρχικοποιείται η εφαρμογή 2. Έλεγξε αν η εφαρμογή έχει ταυτοποίηση χρήστη και για κάθε κύριο πόρο βρες αυτόν που είναι υπεύθυνος για την ταυτοποίηση 3. Εάν ισχύει το 2 δημιούργησε ένα url signin 4. Έλεγξε αν η εφαρμογή έχει αναζήτηση στην βάση δεδομένων και αν ανέκτησε τους πόρους εκείνους που είναι υπεύθυνοι για την αναζήτηση και δημιούργησε το url 5. Έλεγξε αν η εφαρμογή έχει επικοινωνία με κάποια εξωτερική διαδικτυακή υπηρεσία και αν ισχύει ανέκτησε τους πόρους που είναι υπεύθυνοι για αυτό και σχημάτισε τα αντίστοιχα url Ερωτήματα που χρησιμοποιούνται: Ερώτημα 1: getmainresources Ερώτημα 2: relatedresource Ερώτημα 3: getauthenticationperfomer Ερώτημα 6: getsearchcontrollerannotations Ερώτημα 10: getjavarestclientcontrollerannotations Στον παραπάνω αλγόριθμο βλέπουμε την διαδικασία που υλοποιείται για την ανάθεση στις σταθερές των URI που διαμορφώνουν την διαδικτυακή εφαρμογή. Αρχικά μέσα από μία επαναληπτική διαδικασία για όλους τους κύριους πόρους δημιουργείται η αντίστοιχη σταθερά που περιέχει το URI για την πρόσβαση στους αντίστοιχους πόρους. Στην συνέχεια, γίνεται έλεγχος για την εύρεση του πόρου ο οποίος είναι υπεύθυνος για την ταυτοποίηση του χρήστη, και ανατίθεται το URI του πόρου στην σταθερά signinurl. Ακολούθως, με την ίδια λογική, υπάρχουν ακόμα δύο επαναληπτικές διαδικασίες που αφορούν την πρόσβαση στους πόρους εκείνους που είναι υπεύθυνοι για την αναζήτηση και την επικοινωνία με εξωτερική υπηρεσία. Όπως έχει ήδη αναλυθεί προκειμένου οι παραγόμενες εφαρμογές πελάτη να είναι σύμφωνες με το REST αρχιτεκτονικό στυλ και να επιτευχθεί το τρίτο επίπεδο του Richardson Maturity Model θα πρέπει να υλοποιηθεί η κατάλληλη χαρτογράφηση της εφαρμογής πελάτη. Στο σημείο αυτό να αναφέρουμε ότι για την ορθή [77]

78 Αυτόματη παραγωγή διεπαφών χρήστη για διαδικτυακές υπηρεσίες τύπου REST παραγωγή του κώδικα πρέπει να γίνει έλεγχος στην περίπτωση που η εφαρμογή έχει ταυτοποίηση χρήστη και υπάρχει μόνο ένας κύριος πόρος και αυτός είναι και ο πόρος που είναι υπεύθυνος για την ταυτοποίηση. Σε αυτήν την περίπτωση με την έναρξη της διαδικτυακής εφαρμογής η σελίδα που εμφανίζεται αρχικά στον χρήστη είναι αυτή για την εισαγωγή των διαπιστευτηρίων του. Module Auth Μέσω της διαδικτυακής υπηρεσίας όπως έχουμε ήδη αναφέρει δίνεται η δυνατότητα στον χρήστη να χρησιμοποιήσει την διαδικασία της ταυτοποίησης, δηλαδή της απόκτησης πρόσβασης σε πόρους και υπηρεσίες εφόσον ο χρήστης εισάγει ένα συνθηματικό πελάτη (username) και έναν κωδικό πελάτη (password). Τα στοιχεία αυτά κωδικοποιούνται και στέλνονται μαζί με το εκάστοτε αίτημα. Στην συνέχεια ο εξυπηρετητής στέλνει μία απόκριση επαληθεύοντας ή όχι τα στοιχεία του χρήστη. Για την υλοποίηση της διαδικασίας που αναφέρθηκε δημιουργήθηκε το Module Auth το οποίο παράγει δύο αρχεία και συγκεκριμένα το αρχείο signin.js και signin.html, δηλαδή έναν ελεγκτή και μία όψη αντίστοιχα. Στην όψη, το html αρχείο, δημιουργούνται δύο φόρμες, η μία υπεύθυνη για την εγγραφή του χρήστη (signup) και ή άλλη για την εισαγωγή του χρήστη στο σύστημα (login). Τα τμήματα κώδικα που θα παρουσιαστούν παρακάτω επικεντρώνονται στα σημεία που διαφοροποιούνται από αυτά που έχουν αναφερθεί στα προηγούμενα παραδείγματα. Αλγόριθμος 13: Ανάκτηση ιδιοτήτων υπεύθυνων για ταυτοποίηση χρήστη [for (p: String anannotationstack.getauthenticationperformer().hasauthenticationtoken.name)] <div class="field"> <div class="ui left icon input"> [if (p='password')] <i class="lock icon"></i> <input type="password" name="[p/]" placeholder="[p.toupperfirst()/]" ng-model="[p/]"> [else] <i class="user icon"></i> <input type="text" name="[p/]" placeholder="[p.toupperfirst()/]" ng-model="[p/]"> [/if] </div> </div> [/for] [78]

79 Μεθοδολογία Πίνακας 20: Περιγραφή Αλγορίθμου 13 Βήματα Περιγραφή 1. Για κάθε anannotationstack.getauthenticationperformer().hasa uthenticationtoken.name τύπου string 2. Έλεγξε αν το p έχει την τιμή password και δημιούργησε το αντιστοιχο input Ερωτήματα που χρησιμοποιούνται: Ερώτημα 3: getauthenticationperfomer 1. Για το στοιχείο που είναι υπεύθυνο για την ταυτοποίηση 2. Έλεγξε το πεδίο password και δημιούργησε το αντίστοιχο Input πεδίο Πίνακας 21: Ερωτήματα που χρησιμοποιούνται στο module Auth Ερώτημα 1: getmainresources Queries Ερώτημα 2: relatedresource Ερώτημα 3: getauthenticationperfomer Ερώτημα 4: hasbothmodeauthentication Ερώτημα 5: getauthenticationlayerbothmodeannotations Module Search Η διαδικτυακή εφαρμογή παρέχει την δυνατότητα στο πελάτη να χρησιμοποιήσει την λειτουργία της αναζήτησης όπως αυτή έχει οριστεί στην διαδικτυακή υπηρεσία. Στο module Search δημιουργούνται τουλάχιστον δύο διαφορετικά αρχεία ένα υπεύθυνο για την δημιουργία της όψης και το άλλο υπεύθυνο για την δημιουργία του ελεγκτή. Γίνεται επομένως η ανάκτηση των πόρων που είναι αρμόδιοι για την λειτουργία αυτή και παράγεται ένα αρχείο HTML και ένα αρχείο JS. Η λογική που ακολουθήθηκε για την υλοποίηση της διαδικασίας της αναζήτησης είναι η εξής: Για κάθε πόρο ο οποίος είναι υπεύθυνος για την αναζήτηση ενός άλλου πόρου παράγεται όπως αναφέρθηκε παραπάνω ένας ζεύγος αρχείων. Στο αρχείο JS γίνεται αρχικά η ανάκτηση των πόρων βάση των οποίων θα γίνει και η αναζήτηση ( Ερώτημα 7: getsearchableresources) και στην συνέχεια γίνεται η ανάκτηση των ιδιοτήτων των πόρων αυτών που χρησιμοποιούνται για την αναζήτηση. [79]

80 Αυτόματη παραγωγή διεπαφών χρήστη για διαδικτυακές υπηρεσίες τύπου REST Αλγόριθμος 14: Ανάκτηση πόρων βάση των οποίων γίνεται αναζήτηση κι ιδιοτήτων αυτών $scope.checkboxes = ['['/] [for (jalgoresourcecontroller : JavaAlgoResourceController anannotationstack. hascorepsm. hasjavaalgocontroller)] [if (jalgoresourcecontroller.parentname = a.issearchcontroller.annotatesjavaalgocontroller.parentname)] [for (asearchablejavaresourcemodel : SearchableJavaResourceModel jalgoresourcecontroller.getsearchableresources(anannotationstack))] [for (c : SearchableProperty asearchablejavaresourcemodel.hassearchableproperty)] { checked: false, value: "[asearchablejavaresourcemodel.issearchablejavaresourcemodel.annotatesjavaresourcemodel. parentname.toupperfirst()/] [c.issearchableproperty.annotatespsmcomponentproperty.name.toupperfirst()/]", url_key: "search[asearchablejavaresourcemodel.issearchablejavaresourcemodel. annotatesjavaresourcemodel.parentname.toupperfirst()/][c.issearchableproperty. annotatespsmcomponentproperty.name.toupperfirst()/]" }, [/for] [/for] [/if] [/for] ]; Πίνακας 22: Περιγραφή Αλγορίθμου 14 Βήματα Περιγραφή 1. Για κάθε anannotationstack. hascorepsm. hasjavaalgocontroller τύπου JavaAlgoResourceController 2. Έλεγξε αν το parentname του a.issearchcontroller.annotatesjavaalgocontroller ισούται με το parentname του jalgoresourcecontroller 3. Για κάθε jalgoresourcecontroller.getsearchableresources(anannotat ionstack) τύπου SearchableJavaResourceModel 4. Για κάθε asearchablejavaresourcemodel.hassearchableproperty τύπου SearchableProperty δημιούργησε τα checkboxes για την λειτουργία της αναζήτησης Ερωτήματα που χρησιμοποιούνται: Ερώτημα 3: getauthenticationperfomer Ερώτημα 7: getsearchableresources 1-2. Αναζήτησε του πόρους που έχουν δημιουργηθεί για την αναζήτηση στην βάση δεδομένων 3. Για κάθε πόρο που με βάση τον οποίο θα γίνει η αναζήτηση 4. Για κάθε ιδιότητα του πόρου με βάση την οποία θα γίνει η αναζήτηση δημιουργούνται τα checkboxes για την λειτουργία της αναζήτησης. Στον Αλγόριθμος 14: Ανάκτηση πόρων βάση των οποίων γίνεται αναζήτηση κι ιδιοτήτων αυτών φαίνεται το τμήμα του κώδικα που είναι υπεύθυνο για την λειτουργία της αναζήτησης στην πλευρά του ελεγκτή. Κάθε [80]

81 Μεθοδολογία πόρος που έχει οριστεί να είναι πόρος για την λειτουργία της αναζήτησης έχει έναν ή περισσότερους πόρους και βάση των ιδιοτήτων αυτών γίνεται η αναζήτηση. Επομένως αρχικά ανακτάται από όλα τα πιθανά JavaAlgoResourceController αυτό που έχει οριστεί ως αρμόδιο για την αναζήτηση. Στην συνέχεια δημιουργείται ένα αντικείμενο που περιέχει μία μεταβλητή checked, που χρησιμοποιείται για τον έλεγχο της επιλογής ή μη μιας ιδιότητας του πόρου προς αναζήτηση, μία τιμή value που είναι το όνομα του πόρου και της ιδιότητας του βάση της οποίας ο χρήστης μπορεί να επιλέξει να κάνει αναζήτηση (θα φανεί στην πορεία που θα αναλυθεί το HTML αρχείο) και, τέλος, μίας τιμή url_key που είναι απαραίτητη καθώς έτσι διαμορφώνεται το uri που θα χρησιμοποιηθεί για να αποσταλεί το αίτημα με τις αντίστοιχες παραμέτρους στον διακομιστή. Για την αποστολή του αιτήματος και την λήψη της αντίστοιχης απόκρισης έχει δημιουργηθεί μία ακόμα συνάρτηση η οποία αφού εκτελέσει το αντίστοιχο αίτημα με τις αντίστοιχες παραμέτρους κάνει έναν έλεγχο αν βρεθούν αποτελέσματα να τα εμφανίσει κατηγοριοποιώντας τα ανάλογα με τον πόρο στον οποίο ανήκουν. Όσον αφορά το html αρχείο που παράγεται η διαδικτυακή εφαρμογή δίνει στον χρήστη την δυνατότητα να επιλέξει με βάση μία λέξη κλειδί keyword σε ποιους πόρους, και ανάλογα με ποια ιδιότητα θέλει να γίνει η αναζήτηση. Με αυτό τον τρόπο καθίσταται δυνατή η υλοποίηση μιας αναζήτησης αρκετά «αφηρημένης» ώστε να μπορέσει η διαδικτυακή εφαρμογή να προσεγγίσει όσο το δυνατόν περισσότερους τρόπους αναζήτησης και εμφάνισης αποτελεσμάτων. Αλγόριθμος 15: Ανάκτηση πόρων προς εμφάνιση αποτελεσμάτων [for (jalgoresourcecontroller : JavaAlgoResourceController anannotationstack.hascorepsm.hasjavaalgocontroller)] [if (jalgoresourcecontroller.parentname = a.issearchcontroller.annotatesjavaalgocontroller.parentname)] [for (asearchablejavaresourcemodel : SearchableJavaResourceModel jalgoresourcecontroller.getsearchableresources(anannotationstack))] <table class="ui compact celled definition table" ng-show="[asearchablejavaresourcemodel. issearchablejavaresourcemodel.annotatesjavaresourcemodel.parentname/]"> [81]

82 Αυτόματη παραγωγή διεπαφών χρήστη για διαδικτυακές υπηρεσίες τύπου REST Πίνακας 23: Περιγραφή Αλγορίθμου 15 Βήματα Περιγραφή 1. Για κάθε anannotationstack.hascorepsm.hasjavaalgocontroller τύπου JavaAlgoResourceController 2. Έλεγξε αν το parentname του asearchablejavaresourcemodel.issearchablejavaresour cemodel.annotatesjavaresourcemodel ισούται με το parentname του jalgoresourcecontroller 3. Για κάθε jalgoresourcecontroller.getsearchableresources(anann otationstack) τύπου SearchableJavaResourceModel εμφάνισε των πίνακα - ng-show Ερωτήματα που χρησιμοποιούνται: -Ερώτημα 3: getauthenticationperfomer 1-2.Για κάθε πόρο αναζήτησε αυτόν που ταυτίζεται με τον πόρο που είναι υπεύθυνος για την αναζήτηση 3. Για κάθε κάθε πόρο με βάση των οποίων έγινε η αναζήτηση (με βάση μιας ιδιότητας του) μέσω της συνθήκης ng-show θα εμφανιστούν και τα αντίστοιχα αποτελέσματα Αλγόριθμος 16:: Εμφάνιση των λεπτομερειών των πόρων που αναζητήθηκαν με βάση μία ιδιότητα <tbody ng-repeat="item in [asearchablejavaresourcemodel.issearchablejavaresourcemodel. annotatesjavaresourcemodel.parentname/]results" > <tr> [for (p : JavaResourceModel anannotationstack.hascorepsm.hasjavarmodel)] [if (p.parentname = asearchablejavaresourcemodel.issearchablejavaresourcemodel. annotatesjavaresourcemodel.parentname)] [for (c : PSMComponentProperty p.javarmodelhasproperty)] [if (c.type = 'String') or (c.type = 'float')] <td>{{item.[c.name/]}}</td> [/if] [/for] [/if] [/for] </tr> </tbody> [82]

83 Μεθοδολογία Πίνακας 24: Περιγραφή Αλγορίθμου 16 Βήματα Περιγραφή 1. Για κάθε anannotationstack.hascorepsm.hasjavarmodel τύπου JavaResourceModel 2. Έλεγξε αν το parentname του asearchablejavaresourcemodel.issearchablejavaresourcem odel.annotatesjavaresourcemodel ισούται με το parentname του p 3. Για κάθε p.javarmodelhasproperty τύπου PSMComponentProperty εμφάνισε τις ιδιότητες Ερωτήματα που χρησιμοποιούνται: -Ερώτημα 3: getauthenticationperfomer 1-2.Για κάθε πόρο αναζήτησε αυτόν που ταυτίζεται με τον πόρο του οποίου τις ιδιότητες θέλουμε να εμφανίσουμε 3. Για κάθε ιδιότητα του πόρου εμφάνισε την τιμή της Στο τμήμα του κώδικα που δείχνει ο Αλγόριθμος 15 ανάλογα με το αποτέλεσμα της αναζήτησης εμφανίζεται και στον χρήστη ο πόρος με τις αντίστοιχες ιδιότητες του. Αν η λέξη κλειδί που έχει επιλέξει ο χρήστης εντοπιστεί σε δύο διαφορετικούς πόρους τότε τα αποτελέσματα και των δύο ( με τα αντίστοιχα στιγμιότυπα που επαληθεύουν το αποτέλεσμα της αναζήτησης) θα εμφανιστούν. Στον Αλγόριθμος 16 από την άλλη ανακτώνται όλες οι ιδιότητες του εκάστοτε πόρου. Πίνακας 25: Ερωτήματα που χρησιμοποιούνται στο module Search Ερώτημα 6: getsearchcontrollerannotations Queries Ερώτημα 7: getsearchableresources Ερώτημα 8: getsearchhttphandler Ερώτημα 9: getsearchhttphandlerannotations Module ExternalService Η επικοινωνία μιας διαδικτυακής εφαρμογής με μία εξωτερική υπηρεσία είναι μία περίπλοκη διαδικασία και προφανώς διαφέρει τόσο ο τρόπος κλήσης της υπηρεσίας όσο και ο τρόπος εμφάνισης των αποτελεσμάτων. Στην παρούσα διπλωματική εργασία έγινε μια προσέγγιση ώστε να μπορεί να καλύπτει όλες τις πιθανές ενέργειες και τα αποτελέσματα εμφανίζονται με έναν πιο γενικό τρόπο, σαν δεδομένα. Από εκεί και πέρα είναι στην αρμοδιότητα του κάθε προγραμματιστή να διαχειριστεί τα δεδομένα αυτά σύμφωνα με τις δικές του απαιτήσεις και προδιαγραφές. Η ίδια λογική που παρουσιάστηκε παραπάνω, για την αναζήτηση στην βάση δεδομένων, εφαρμόζεται και στην περίπτωση που η διαδικτυακή εφαρμογή επικοινωνεί με κάποια εξωτερική διαδικτυακή υπηρεσία. Στο [83]

84 Αυτόματη παραγωγή διεπαφών χρήστη για διαδικτυακές υπηρεσίες τύπου REST module ExternalService δημιουργούνται αντίστοιχα τουλάχιστον δύο αρχεία, ένα HTML αρχείο και ένα JS, για κάθε πόρο που είναι υπεύθυνος για την επικοινωνία με την εξωτερική υπηρεσία. Αλγόριθμος 17: Επικοινωνία με εξωτερική υπηρεσία - αίτημα GET - με παραμέτρους $scope.submit = function (model) { dataservice.data(config.[a.isjavarestclientcontroller.annotatesjavaalgocontroller.parentname/]url ).getall({ [for (qparam : QueryParam a.isjavarestclientcontroller.annotatesjavaalgocontroller. JavaAlgoRControllerHasHTTPActivity.getQueryParams(anAnnotationStack))] [qparam.name/]: model.[qparam.name/], [/for] }, function (data) { response = data; }).$promise.then( function () { [if not(a.hasassociatedmodel.hasjavaoutputmodel.oclisundefined())] [for ( anoutputproperty : Property a.hasassociatedmodel. hasjavaoutputmodel.hasoutputproperty)] [if (anoutputproperty.type = 'Complex')] parseresponse(response.[anoutputproperty.name/]) [else] $scope.model.[anoutputproperty.name/] = response.[anoutputproperty.name/] [/if] [/for] [/if] }, function () { Notification.error("Wrong Query Parameters "); } ) }; Πίνακας 26: Περιγραφή Αλγορίθμου 17 Βήματα Περιγραφή 1. Για κάθε a.isjavarestclientcontroller.annotatesjavaalgocontroller. JavaAlgoRControllerHasHTTPActivity.getQueryParams(anA nnotationstack) τύπου QueryParam ανέκτησε το name του 2. Έλεγξε αν ισχύει δεν ισχύει (a.hasassociatedmodel.hasjavaoutputmodel.oclisundefin ed() 3. Αν το 2 είναι αληθές για κάθε a.hasassociatedmodel.hasjavaoutputmodel.hasoutputpro perty τύπου Property 4. Έλεγξε αν το type του anoutputproperty είναι τύπου complex 5. Αν ισχύει το 4 κάλεσε την συνάρτηση parseresponse Ερωτήματα που χρησιμοποιούνται: Ερώτημα 11: getqueryparamsερώτημα 3: getauthenticationperfomer 1. Σχημάτισε τις παραμέτρους που πρέπει να αποσταλούν μαζί με το αίτημα στην εξωτερική υπηρεσία 2. Έλεγξε την απόκριση να είναι ορισμένη 3. Για κάθε ιδιότητα που έχει οριστεί ως ιδιότητα της απόκρισης της εξωτερικής υπηρεσίας 4. Έλεγξε αν είναι τύπου complex 5. Αν ισχύει το 4 καλείται η συνάρτηση parseresponse. Στον Αλγόριθμος 17: Επικοινωνία με εξωτερική υπηρεσία - αίτημα GET - με παραμέτρους φαίνεται το τμήμα του κώδικα που είναι υπεύθυνο για την επικοινωνία με την εξωτερική υπηρεσία, τον καθορισμό των [84]

85 Μεθοδολογία παραμέτρων, σε περίπτωση που είναι απαραίτητες, και την κατάλληλη διαχείριση της απόκρισης. Για να μπορέσουμε να χρησιμοποιήσουμε ορθά την απόκριση από την εξωτερική εφαρμογή πρέπει να γίνουν ορισμένοι έλεγχοι που αφορούν την δομή της. Tο JSON response θα πρέπει να διερευνηθεί ώστε να πάρουμε τις παραμέτρους εκείνες που δεν είναι τύπου complex, επομένως για αρχή ελέγχεται η απόκριση που λάβαμε για το εάν κάποια από τις μεταβλητές που έχουν οριστεί ως outputproperty είναι τύπου complex, όπου και καλείται μία συνάρτηση για την διαχείριση τέτοιων περιπτώσεων (parseresponce), ή είναι απλές μεταβλητές (τύπου ακεραίου, αλφαριθμητικού κ.ο.κ.) οπότε και μπορούν να ανατεθούν κανονικά για να εμφανιστούν στον χρήστη. Αλγόριθμος 18: Ανάκτηση ιδιοτήτων από την απόκριση ενός αιτήματος σε μια εξωτερική υπηρεσία JSON.parse(JSON.stringify(response), function (key, value) { [for (acomplextype : ComplexType a.hascomplextypes)] [for (acomplextypeproperty : ComplexTypeProperty acomplextype.hascomplextypeproperties)] [if (acomplextypeproperty.hasprimitivetype)] if (key.substr(0, [acomplextypeproperty.name.size()/]) == '[acomplextypeproperty.name/]') { $scope.valuabledata['['/]key] = value; } [/if] [/for] [/for] return value; }); Πίνακας 27: Περιγραφή Αλγορίθμου 18 Βήματα Περιγραφή 1. Για κάθε a.hascomplextypes τύπου ComplexType ( όπου a 1. Για κάθε Complex στοιχείο τύπου JavaRESTClientController) 2. Παίρνουμε τις ιδιότητες του complex 2. Για κάθε acomplextype.hascomplextypeproperties τύπου στοιχείου ComplexTypeProperty 3. Αν για την ιδιότητα αυτή το 3. Έλεγξε αν ισχύει η συνθήκη acomplextypeproperty hasprimitivetype είναι αληθές.hasprimitivetype 4. Αναθέτουμε την ιδιότητα αυτή σε μία 4. Αν ισχύει το 3 ανέκτησε το name του μεταβλητή για να προβληθεί στον acomplextypeproperty χρήστη Ερωτήματα που χρησιμοποιούνται: -Ερώτημα 3: getauthenticationperfomer Αν σκεφτούμε την απόκριση που λαμβάνουμε σαν ένα γράφο του οποίου δεν γνωρίζουμε το βάθος, με αυτή την συνθήκη μπορούμε να αναγνωρίσουμε τους κόμβους εκείνους που δεν έχουν παιδιά (φύλλα). Με αυτό τον τρόπο λοιπόν μπορούμε να αντλήσουμε από την απόκριση μόνο τα δεδομένα που χρειαζόμαστε. [85]

86 Αυτόματη παραγωγή διεπαφών χρήστη για διαδικτυακές υπηρεσίες τύπου REST Στο HTML αρχείο για να εμφανιστούν τα δεδομένα τις απόκρισης από την κλήση στην εξωτερική υπηρεσία αρκεί να γίνει μία επαναληπτική διαδικασία στο valuabledata. Αυτό φαίνεται στον αλγόριθμο που ακολουθεί. Αλγόριθμος 19: Εμφάνιση αποτελεσμάτων της απόκρισης από την κλήση στην εξωτερική υπηρεσία Πίνακας 28: Ερωτήματα που χρησιμοποιούνται στο module ExternalService Queries Ερώτημα 10: getjavarestclientcontrollerannotations Ερώτημα 11: getqueryparams Ερώτημα 12: getjavarestclienthttpactivity 4.4 Παραγόμενες εφαρμογές πελάτη Στην ενότητα αυτή θα παρουσιαστεί ο τρόπος χρήσης της μηχανής που αναπτύχθηκε στα πλαίσια της διπλωματικής εργασίας καθώς επίσης και η δομή της εξόδου της μηχανής, δηλαδή η διαδικτυακή εφαρμογή. Τέλος, θα παρουσιαστούν συνοπτικά τα βήματα για τον τρόπο με τον οποίο μπορεί να χρησιμοποιηθεί η διαδικτυακή εφαρμογή μετά την παραγωγή της από την μηχανή Εκτέλεση της μηχανής Για την εκτέλεση την μηχανής και την δημιουργία της επιθυμητής εφαρμογής πελάτη έχει αναπτυχθεί ένα plugin στον Ecliplse το οποίο είναι παρόμοιο με αυτό για την δημιουργία της διαδικτυακής υπηρεσίας με την χρήση της πλατφόρμας του S-CASE. Στο Σχήμα 29 φαίνεται το γραφικό περιβάλλον από το plugin αυτό. Οι είσοδοι που δέχεται είναι η ονομασία της υπηρεσίας και ο φάκελος στον οποίο θα αποθηκευτούν τα αρχεία της διαδικτυακής εφαρμογής που θα παραχθεί. Θα πρέπει να προσέξουμε να δώσουμε τα σωστά στοιχεία για την επικοινωνία με την βάση μας ( PostgreSQL ή MySQL) όπως την θύρα, το username και το password. Τέλος θα πρέπει να είναι επιλεγμένη η επιλογή «Reload Previous Service models», ενώ ανάλογα με τις [86]

87 Μεθοδολογία λειτουργικότητες που έχει η υπηρεσία μας μαρκάρουμε και τις αντίστοιχες επιλογές ( authentication, database searching, external compositions). Σχήμα 29: GUI Eclipse Plugin Επισκόπηση δομής εξόδου και αρχικοποίηση εφαρμογής Μετά την ολοκλήρωση της διαδικασίας παραγωγής της διαδικτυακή υπηρεσίας η μορφή του φακέλου που θα έχει δημιουργηθεί είναι αυτή που φαίνεται στο Σχήμα 30. Δημιουργείται ο φάκελος js όπου μέσα βρίσκονται δύο υποφάκελοι, ο φάκελος controllers όπου περιέχονται όλοι οι ελεγκτές που χρειάζονται για την λειτουργεία της εφαρμογής και ο φάκελος services όπου περιέχεται το αρχείο service.js και στην περίπτωση που υπάρχει ταυτοποίηση χρήστη και το αρχείο authentication.js. Επίσης μέσα στον φάκελο js βρίσκεται και το αρχείο app.js το οποίο όπως έχουμε αναφέρει είναι υπεύθυνο για την δρομολόγηση στους πόρους ανάλογα με την πλοήγηση του χρήστη και για την αρχικοποίηση των URI που απαιτούνται για την λειτουργία της εφαρμογής. Στον φάκελο templates υπάρχουν όλα τα.html αρχεία που αποτελούν τις όψεις, τις σελίδες που βλέπει ο χρήστης. Τέλος το αρχείο index.html από το οποίο αρχικοποιείται η εφαρμογή. [87]

88 ServiceNameClient Αυτόματη παραγωγή διεπαφών χρήστη για διαδικτυακές υπηρεσίες τύπου REST resource.controller.js resourcedetail.controller.js controllers resourcesearch.controller.js index.html externalservice.controller.js js signin.controller.js authentication.service.js services service.js app.js main.html navbar.html resource.html resourcedetail.html templates newresource.html searchresource.html externalserviceresource.html signin.html Σχήμα 30: Δομή παραγόμενης εφαρμογής πελάτη [88]

89 Μεθοδολογία Σε αυτό το σημείο θα αναφερθούμε στα βήματα που απαιτούνται για να τεθεί σε λειτουργία η εφαρμογή. Αρχικά, πρέπει να γίνει επιλογή του server, τοπικά χρησιμοποιήθηκε ο Apache Tomcat. Έπειτα πρέπει το.war αρχείο που περιέχει το υλοποιημένο API να κατατεθεί στον server, είτε τοποθετώντας το αρχείο στον φάκελο webapps του tomcat, όπου η διαδικασία της αποσυμπίεσης του αρχείου και της εκτέλεσης του γίνονται αυτόματα, είτε μέσα από τον περιηγητή μεταβαίνοντας στην διεύθυνση localhost:8080 ( ή όποια θύρα έχουμε θέσει, η 8080 είναι η προεπιλεγόμενη του tomcat), και επιλέγουμε Manager Apps και στην επιλογή deploy war file to server επιλέγουμε το αρχείο. Για να αποκτήσει το API πρόσβαση στην βάση δεδομένων και να μπορεί να αποστέλλει τα αιτήματα η βάση πρέπει να τεθεί σε λειτουργία στην ίδια πόρτα που θα αναζητήσει και το API (στο παράδειγμα μας Σχήμα 29 η θύρα είναι 3306). Το επόμενο βήμα της διαδικασίας είναι να τοποθετηθεί στον φάκελο webapps ο φάκελος με τα αρχεία που παράγονται από την μηχανή. Σε αυτό το σημείο πρέπει να αναφέρουμε δυο σημαντικά βήματα. Πρώτον, θα πρέπει μέσα στον φάκελο της παραγόμενης εφαρμογής να προστεθεί ο φάκελος lib, με τις βιβλιοθήκες που χρησιμοποιεί η εφαρμογή αυτή, όπως angularjs, semanticui κ.α. Επίσης, στο αρχείο app.js, εκεί όπου έχουν οριστεί τα URI για την αρχικοποίηση της εφαρμογής, θα πρέπει να ελεγχθεί ότι η θύρα που χρησιμοποιείται από τον server μας είναι σωστά ορισμένη. [89]

90 Αυτόματη παραγωγή διεπαφών χρήστη για διαδικτυακές υπηρεσίες τύπου REST 5 Παραδείγματα εφαρμογής Σε αυτό το κεφάλαιο, θα παρουσιαστούν ενδεικτικά δύο παραδείγματα εφαρμογών πελάτη, που παράχθηκαν μέσω της μηχανής CREATE, και οι διαδικτυακές υπηρεσίες των οποίων δημιουργήθηκαν μέσω της πλατφόρμας του S-CASE. Αρχικά, θα παρουσιαστεί μία απλή περίπτωση εφαρμογής που περιλαμβάνει τις βασικές λειτουργίες και μία απλή περίπτωση αναζήτησης στην βάση δεδομένων. Στην συνέχεια, θα παρουσιαστεί μία πιο σύνθετη εφαρμογή η οποία εκτός των παραπάνω θα επιτυγχάνει μία πιο σύνθετη μορφή της αναζήτησης στην βάση δεδομένων καθώς και επικοινωνία με εξωτερική υπηρεσία. 5.1 Παράδειγμα εφαρμογής RESTBooks Στο πρώτο παράδειγμα θα παρουσιαστεί η απλή εφαρμογή RESTBooks, η οποία διαθέτει δύο πόρους. Ως αρχική σελίδα εμφανίζεται η λίστα με τα στιγμιότυπα του πόρου και οι λεπτομέρειες αυτών. Στο Σχήμα 31 φαίνεται το σχεδιάγραμμα του RESTBooks API, των σχέσεων μεταξύ των πόρων και οι επιτρεπτές HTTP μέθοδοι. Ο πόρος με το περίγραμμα είναι ο πόρος που εμφανίζεται στην πρώτη σελίδα. Θα πρέπει να σημειωθεί ότι η υπηρεσία RESTBooks δεν επιτρέπει όλες τις HTTP μεθόδους και όπως θα φανεί στα παρακάτω σχήματα η γεννήτρια, που δημιουργήθηκε στα πλαίσια αυτής της διπλωματικής εργασίας, εξυπηρετεί τη συγκεκριμένη απαίτηση. Σχήμα 31: Σχεδιάγραμμα του RESTBooks API Πίνακας 29: Αίτημα GET για ανάκτηση λίστας πόρους και των ιδιοτήτων Request Method Request URL GET rary GET rary/{libraryid} [90]

91 Παραδείγματα εφαρμογής Status Code 200 OK 200 OK Content-Type application/json application/json Headers - - Σχήμα 32: Αρχική σελίδα RESTBooks Request Method Πίνακας 30: Αίτημα POST στον πόρο book - σχετικό του library Request URL Status Code Content-Type POST rary/3/book 200 OK application/json Request Body { ISBN :" ", category :"Education", description :"It emphasizes the methods actually used by circuit designers--a combination of some basic laws, rules of thumb, and a large bag of tricks.", publisher :"Cambridge University Press", title :"The Art of Electronics", [91]

92 Αυτόματη παραγωγή διεπαφών χρήστη για διαδικτυακές υπηρεσίες τύπου REST image :"/9j/4AAQSkZJRgABA.. 2wBDA } Σχήμα 33: Δημιουργία νέου στιγμιότυπου book Πίνακας 31: Ανάκτηση στιγμιότυπων του πόρου που είναι σχετικό από άλλο πόρο και εμφάνιση των ιδιοτήτων του Request GET GET Method Request URL rary/3/book rary/3/book/{bookid} Status Code 200 OK 200 OK Content-Type application/json application/json [92]

93 Παραδείγματα εφαρμογής Σχήμα 34: Εμφάνιση των πόρων που είναι σχετικοί από πόρο και των λεπτομερειών Πίνακας 32: Αίτημα διαγραφής ενός στιγμιότυπου του πόρου Request Method Request URL Status Code Content-Type DELETE library/3/book/2 200 OK application/json [93]

94 Αυτόματη παραγωγή διεπαφών χρήστη για διαδικτυακές υπηρεσίες τύπου REST Σχήμα 35: Μήνυμα επιβεβαίωσης για την διαγραφή Πίνακας 33: Αίτημα GET για αναζήτηση στην βάση δεδομένων Request Method Request URL Status Code Content-Type Query Parameters GET searchbooktitle=true&searchkeyword=circuits 200 OK application/json searchbooktitle = true searchkeyword = Circuits [94]

95 Παραδείγματα εφαρμογής Σχήμα 36: Εμφάνιση αποτελεσμάτων αναζήτησης 5.2 Παράδειγμα εφαρμογής Yummy Για το συγκεκριμένο παράδειγμα, θα χρησιμοποιήσουμε το PSM μοντέλο που αναπαριστά το Yummy API, το οποίο αναπτύχθηκε μέσω της πλατφόρμας του S-CASE για τις ανάγκες τις παρούσας διπλωματικής εργασίας. Το Yummy API υλοποιεί μία εφαρμογή, που δίνει την δυνατότητα στον χρήστη να δημιουργήσει λογαριασμό, και μετέπειτα να κάνει είσοδο στην εφαρμογή, για να μπορέσει να χρησιμοποιήσει πλήρως όλες τις λειτουργίες. Επίσης, δίνει την δυνατότητα για αναζήτηση στην βάση δεδομένων, σύμφωνα με την λέξη κλειδί που θα δώσει, και την δυνατότητα της επικοινωνίας με δύο διαφορετικές εξωτερικές εφαρμογές. Το αντίστοιχο σχεδιάγραμμα του Yummy API καθώς και η επεξήγηση του διαγράμματος φαίνονται παρακάτω. [95]

96 Αυτόματη παραγωγή διεπαφών χρήστη για διαδικτυακές υπηρεσίες τύπου REST Σχήμα 37: Επεξήγηση διαγραμμάτων που αφορούν την αναπαράσταση των πόρων της εφαρμογής Σχήμα 38: Οι πόροι και οι επιτρεπτές HTTP μέθοδοι για το Yummy APi [96]

97 Παραδείγματα εφαρμογής Σχήμα 39: Πόροι του Yummy API υπεύθυνοι για την αναζήτηση στην βάση δεδομένων και την επικοινωνία με εξωτερικές υπηρεσίες Παρακάτω θα δοθούν ορισμένα παραδείγματα των λειτουργιών της διαδικτυακής εφαρμογής μαζί με τα αντίστοιχα αιτήματα που γίνονται στον διακομιστή. Όπως φαίνεται στην παρακάτω εικόνα, στην αρχική σελίδα εμφανίζονται οι πόροι εκείνοι που δεν είναι σχετικοί από άλλους πόρους. Επίσης, στην περίπτωση μας όπου η διαδικτυακή εφαρμογή χρησιμοποιεί ταυτοποίηση, ο πόρος που δεν είναι σχετικός από άλλους αλλά ταυτόχρονα χρησιμοποιείται για την ταυτοποίηση του χρήστη δεν εμφανίζεται στην αρχική σελίδα. Κι αυτό γιατί πρέπει να διαχειριστούμε διαφορετικά τον πόρο αυτό καθώς δεν πρέπει ο χρήστης να μπορεί να δει την λίστα με τα στιγμιότυπα του πόρου, αλλά μόνο το στιγμιότυπο εκείνο που αντιστοιχεί στα στοιχεία του χρήστη. [97]

98 Αυτόματη παραγωγή διεπαφών χρήστη για διαδικτυακές υπηρεσίες τύπου REST Σχήμα 40: Αρχική σελίδα Στα παρακάτω σχήματα βλέπουμε την σελίδα που εμφανίζει τα στοιχεία ενός κύριου πόρου. Στο πρώτο παράδειγμα ο χρήστης δεν έχει κάνει Login στην εφαρμογή, οπότε δεν του δίνεται η δυνατότητα να επεξεργαστεί, να διαγράψει ή να προσθέσει ένα στιγμιότυπο του πόρου, καθώς έτσι έχει οριστεί να λειτουργεί η διαδικτυακή υπηρεσία. Στο δεύτερο σχήμα παρατηρούμε ότι ο χρήστης, εφόσον έκανε είσοδο στην εφαρμογή, μπορεί τόσο να επεξεργαστεί και να διαγράψει ένα στιγμιότυπο, όσο και να προσθέσει ένα νέο καθώς από το navigation bar του δίνεται αυτή η επιλογή. Τέλος, εκτός από τα στιγμιότυπα του πόρου, εμφανίζονται και οι αντίστοιχες τιμές των ιδιοτήτων στην ίδια σελίδα. Πίνακας 34: Αίτημα GET στον πόρο με ή χωρίς ταυτοποίηση Request GET GET Method Request URL Status Code 200 OK 200 OK Content-Type application/json application/json Headers - Authorization: Basic bwfyawe6bwfyawe= [98]

99 Παραδείγματα εφαρμογής Πίνακας 35: Αίτημα GET σε στιγμιότυπο πόρου Request Method GET Request URL Status Code 200 OK Content-Type application/json Σχήμα 41:Εμφάνιση της απόκρισης για το αίτημα GET Σχήμα 42: Εμφάνιση της απόκρισης για το αίτημα GET - recipe. Ο χρήστης έχει κάνει login [99]

100 Αυτόματη παραγωγή διεπαφών χρήστη για διαδικτυακές υπηρεσίες τύπου REST Στο Σχήμα 43 φαίνεται η φόρμα για την δημιουργία ενός καινούριου στιγμιότυπου του πόρου. Η φόρμα αυτή είναι ίδια για την δημιουργία οποιουδήποτε πόρου, εκτός του πόρου που χρησιμοποιείται για την ταυτοποίηση, και παρέχει στον χρήστη την δυνατότητα ύπαρξης ενσωματωμένου αντικειμένου, στο παράδειγμα μας αντικείμενο εικόνα. Πίνακας 36: Αίτημα POST σε πόρο Request Method Request URL Status Code Content-Type Headers POST OK application/json Authorization: Basic bwfyawe6bwfyawe= Request Body { } "name":"fruity Breakfast Quinoa", "category":"breakfast-brunch", "image":"ivborw0kggoaaaansuheug.. " Σχήμα 43: Φόρμα δημιουργίας νέου στιγμιότυπου - POST [100]

101 Παραδείγματα εφαρμογής Όπως φαίνεται και στο Σχήμα 44 όταν ο χρήστης επιλέξει να διαγράψει ένα στιγμιότυπο του πόρου, εμφανίζεται μήνυμα επιβεβαίωσης της ενέργειας του, για την αποφυγή λανθασμένων επιλογών του χρήστη. Πίνακας 37: Αίτημα DELETE Request Method DELETE Request URL Status Code 200 OK Content-Type application/json Headers Authorization: Basic bwfyawe6bwfyawe= Request Body - Σχήμα 44: Μήνυμα επιβεβαίωσης διαγραφής στιγμιότυπου Στο Σχήμα 45 βλέπουμε την φόρμα για την δημιουργία ενός νέου στιγμιότυπου του πόρου που είναι υπεύθυνος για την ταυτοποίηση του χρήστη στην εφαρμογή. Στην περίπτωση ενός POST αιτήματος στέλνονται τα δεδομένα που εισάγει ο χρήστης όπως φαίνεται και στον Πίνακας 38. Πίνακας 38: Αίτημα POST Request Method POST Request URL [101]

102 Αυτόματη παραγωγή διεπαφών χρήστη για διαδικτυακές υπηρεσίες τύπου REST Status Code Content-Type 200 OK application/json Request Body { } "address":"egnatia" " ":"maria@mail.com" "name":"maria Kouiroukidou" "password":"maria" "username":"maria" Σχήμα 45: Φόρμα δημιουργίας user POST Πίνακας 39: Αίτημα GET με authentication Request Method Request URL Status Code Content-Type Headers GET OK application/json Authorization: Basic bwfyawe6bwfyawe= Request Body - [102]

103 Παραδείγματα εφαρμογής Σχήμα 46: Φόρμα για την υλοποίηση του authentication Σε περίπτωση που ο χρήστης συμπληρώσει λανθασμένα στοιχεία ταυτοποίησης του εμφανίζεται μήνυμα αποτυχίας όπως φαίνεται στο παρακάτω σχήμα. Σχήμα 47: Μήνυμα αποτυχίας ταυτοποίησης [103]

104 Αυτόματη παραγωγή διεπαφών χρήστη για διαδικτυακές υπηρεσίες τύπου REST Όσον αφορά την αναζήτηση στην βάση δεδομένων, ο χρήστης έχει την επιλογή να διαλέξει, μέσω των checkboxes, την ιδιότητα με την οποία θέλει να κάνει αναζήτηση. Σε περίπτωση που το πλήθος των ιδιοτήτων αυτών είναι μεγάλο, έχουν δημιουργηθεί δύο κουμπιά για την επιλογή ή όχι όλων των ιδιοτήτων με σκοπό την διευκόλυνση του χρήστη. Πίνακας 40: Αίτημα GET με query parameters για αναζήτηση στην βάση δεδομένων (1) Request Method Request URL Status Code Content-Type Request Body - Query Parameters GET searchglossaryname=true&searchkeyword=cinnamon 200 OK application/json searchglossaryname: true searchkeyword: cinnamon Σχήμα 48: Αποτελέσματα αναζήτησης με μία επιλογή [104]

105 Παραδείγματα εφαρμογής Πίνακας 41: Αίτημα GET με query parameters για αναζήτηση στην βάση δεδομένων (2) Request Method GET Request URL archrecipename=true&searchrecipecategory=true&searc hkeyword=breakfast Status Code 200 OK Content-Type application/json Request Body - Query Parameters searchrecipecategory: true searchrecipename: true searchkeyword: Breakfast Σχήμα 49: Λίστα αποτελεσμάτων αναζήτησης με πολλαπλές επιλογές Όπως μπορούμε να διακρίνουμε από τα δύο σχήματα που δείχνουν τα αποτελέσματα της αναζήτησης μπορούμε να διαλέξουμε μία ή περισσότερες ιδιότητες σύμφωνα με τις οποίες θα γίνει η αναζήτηση στην βάση. Ακόμα σε περίπτωση που η λίστα αποτελεσμάτων αποτελείται από στιγμιότυπα ενός πόρου ο οποίος [105]

106 Αυτόματη παραγωγή διεπαφών χρήστη για διαδικτυακές υπηρεσίες τύπου REST έχει πόρους που είναι σχετικοί από αυτόν, με το κουμπί Show More βέλος, μπορούμε να μεταβούμε στην σελίδα για την εμφάνιση των λεπτομερειών του πόρου, δηλαδή τους πόρους που είναι σχετικοί από αυτόν και τις ιδιότητες τους. Παρακάτω θα παρουσιάσουμε μερικά παραδείγματα επικοινωνίας με εξωτερική διαδικτυακή υπηρεσία. Όπως αναφέρθηκε και παραπάνω, έχει δημιουργηθεί μία σελίδα όπου εμφανίζονται τα αποτελέσματα εκείνα που έχουν οριστεί στην διαδικτυακή υπηρεσία ως τα δεδομένα που θέλουμε να ανακτήσουμε από την κλίση μας στην εξωτερική υπηρεσία. Από εκεί και πέρα, ο κάθε προγραμματιστής μπορεί να χρησιμοποιήσει τα δεδομένα αυτά για τους σκοπούς που θέλει κάθε φορά η διαδικτυακή εφαρμογή που αναπτύσσει. Στο παράδειγμά μας έχουν χρησιμοποιηθεί δύο διαφορετικές εξωτερικές υπηρεσίες η μια είναι το currencylayer για την αντιστοίχηση των τιμών σε όλα τα πιθανά νομίσματα. Η δεύτερη εξωτερική διαδικτυακή υπηρεσία που χρησιμοποιείται είναι η Big Maps και συγκεκριμένα η λειτουργία εύρεσης των συντεταγμένων ενός σημείου. Οι συντεταγμένες αυτές στην συνέχεια μπορούν να χρησιμοποιηθούν για την εμφάνιση του σημείου σε χάρτη. Request Method Request URL Status Code Content-Type Request Body - Query Parameters Πίνακας 42: Αίτημα GET για την επικοινωνία με την εξωτερική υπηρεσία BigMaps GET _TRWoy3Dzbsp9L4QoGtdQyi4Pd11GavWWWH0DADpBIa36StCu7VNiG&output=json&query=Egnatia+ 21,+Thessaloniki 200 OK application/json Key: An8plTVFN_TRWoy3Dzbsp9L4QoGt-dQyi4Pd11GavWW WH0DADpBIa36StCu7VNiG Output: json Query: Egnatia+21,+Thessaloniki [106]

107 Παραδείγματα εφαρμογής Σχήμα 50: Εμφάνιση αποτελεσμάτων από την κλίση στην εξωτερική υπηρεσία BigMaps Πίνακας 43: Αίτημα GET για την επικοινωνία με την εξωτερική υπηρεσία currencylayer Request Method GET Request URL Status Code Content-Type Request Body - Query Parameters ey=1c96665f60a eda OK application/json access_key: 1c96665f60a eda [107]

108 Αυτόματη παραγωγή διεπαφών χρήστη για διαδικτυακές υπηρεσίες τύπου REST Σχήμα 51: Εμφάνιση αποτελεσμάτων από την κλίση στην εξωτερική υπηρεσία currencylayer Στο ΠΑΡΑΡΤΗΜΑ (Β) μπορεί κανείς να δει ορισμένα τμήματα του παραγόμενου κώδικα. [108]

109 Συμπεράσματα και μελλοντικές προτάσεις 6 Συμπεράσματα και μελλοντικές προτάσεις Συμπερασματικά, η εφαρμογή καταφέρνει να καλύψει την ανάγκη για ένα front-end περιβάλλον για το υλοποιημένο REST API. Από τα παραδείγματα εφαρμογής που παρουσιάστηκαν στην προηγούμενη ενότητα μπορεί να γίνει αντιληπτό ότι η μηχανή που αναπτύχθηκε στα πλαίσια της παρούσας διπλωματικής εργασίας μπορεί να ανταπεξέλθει σε πολλά και διαφορετικά σενάρια. Είτε πρόκειται για μία περίπλοκη διαδικτυακή υπηρεσία είτε για μία απλή περίπτωση όπως αυτή που παρουσιάστηκε στο πρώτο παράδειγμα, η μείωση του χρόνου και κόπου συγγραφής κώδικα μειώνεται σημαντικά. Θα παραθέσουμε ενδεικτικά τα στατιστικά από τα παραπάνω παραδείγματα που παρουσιάστηκαν. Η γεννήτρια παρήγαγε 21 αρχεία JS και 21 αρχεία HTML για την εφαρμογή Yummy και 6 αρχεία JS και 6 αρχεία HTML αντίστοιχα για την εφαρμογή RESTBooks. Στο παρακάτω διάγραμμα είναι εμφανής η διαφορά του αριθμού παραγωγής τόσο γραμμών κώδικα όσο και σχολίων. Σχήμα 52: Εκτίμηση αποτελεσμάτων Ωστόσο, στο μέλλον η γεννήτρια θα μπορούσε να επεκταθεί περισσότερο ώστε να μπορεί να δίνει στον χρήστη την δυνατότητα επιλογής διαφορετικών template. Η δημιουργία περισσότερων template θα μπορούσε να δώσει στον προγραμματιστή την δυνατότητα να επιλέξει αυτό που ταιριάζει περισσότερο στις δικές του ανάγκες. Επίσης, θα μπορούσε να επεκταθεί ώστε να μπορεί να παράγει διαδικτυακές εφαρμογές και σε άλλες γλώσσες προγραμματισμού (Java, PHP, Angular2 κ.α) [109]

110 Αυτόματη παραγωγή διεπαφών χρήστη για διαδικτυακές υπηρεσίες τύπου REST Βιβλιογραφία [1] «Forbes,» [Ηλεκτρονικό]. Available: [Πρόσβαση ]. [2] A. Williams, «TechCrunch,» [Ηλεκτρονικό]. Available: [Πρόσβαση ]. [3] «ProgrammableWeb,» [Ηλεκτρονικό]. Available: [4] [Ηλεκτρονικό]. Available: [Πρόσβαση ]. [5] R. Fielding, J. Gettys, J. C. Mogul, H. F. Nielsen, L. Masinter, P. J. Leach και T. Berners-Lee, Hypertext Transfer Protocol HTTP/1.1, [6] D. Benslimane, S. Dustdar και A. Sheth, «Services Mashups - The New Generation of Web Applications,» [7] J. Webber, S. Parastatidis και I. Robinson, REST in Practice Hypermedia and Systems Architecture, 1st επιμ., O'Reilly, [8] L. Richardson και S. Ruby, RESTful Web Services, O Reilly, [9] M. Fowler, «Richardson Maturity Model,» 18 March [Ηλεκτρονικό]. Available: [10] M. D. Engineering, «On S- CASE automation engine, Model Driven Engineering and queen Victoria Era buildings ( Part 1 )!,» αρ. Part 1, pp. 2-5, [11] A. Rodrigues Da Silva, «Model-driven engineering: A survey supported by the unified conceptual model,» Computer Languages, Systems and Structures, τόμ. 43, pp , [12] T. Mens και P. Van Gorp, «A taxonomy of model transformation,» Electronic Notes in Theoretical Computer Science, τόμ. 152, αρ. 1-2, pp , [13] J. Bézivin, «In search of a basic principle for Model Driven Engineering,» Special Novatica Issue - UML and Model Engineering, τόμ. 5, αρ. 2, pp , [14] F. Truyen, «The Fast Guide to Model Driven Architecture The Basics of Model Driven Architecture,» Practice, p. 12, [110]

111 Βιβλιογραφία [15] J. Hutchinson, J. Whittle και M. Rouncefield, «Model-driven engineering practices in industry: Social, organizational and managerial factors that lead to success or failure,» Science of Computer Programming, τόμ. 89, αρ. PART B, pp , [16] I. Sacevski και J. Veseli, «Introduction to Model Driven Architecture ( MDA ),» Department of Computer Science, University of Salzburg, pp. 1-15, [17] C. Zolotas και K. Chatzidimitriou, «D2.2 Definition of Platform Independent and Platform Specific Service Models,» [18] I. JTC1, «Information technology - Object Management Group Object Constraint Language ( OCL ),» τόμ. 2012, αρ. April, p. 244, [19] J. Cabot και M. Gogolla, «Object constraint language (OCL): A definitive guide,» Lecture Notes in Computer Science, τόμ LNCS, pp , [20] Obeo, «Eclipse Acceleo,» [Ηλεκτρονικό]. Available: [Πρόσβαση ]. [21] S. Seshadri και B. Green, AngularJS: Up And Running, O Reilly Media, Inc., [22] «AngularJS,» [Ηλεκτρονικό]. Available: [Πρόσβαση ]. [23] «Semantic UI,» [Ηλεκτρονικό]. Available: [Πρόσβαση ]. [24] «Wikipedia, the free encyclopedia,» [Ηλεκτρονικό]. Available: [Πρόσβαση 5 September 2016]. [25] «Wikipedia, the free encyclopedia,» [Ηλεκτρονικό]. Available: [Πρόσβαση 5 September 2016]. [26] «Swagger,» [Ηλεκτρονικό]. Available: [Πρόσβαση ]. [27] «REST_Client_Generator,» [Ηλεκτρονικό]. Available: [Πρόσβαση ]. [28] «S-CASE,» [Ηλεκτρονικό]. Available: [29] K. Czarnecki και S. Helsen, «Feature-Based Survey of Model Transformation Approaches,» IBM Systems Journal, τόμ. 45, αρ. 3, pp , [30] C. Zolotas και T. Diamantopoulos, «D2.3.2 Ontology to MOF Models Transformation Mechanism,» [111]

112 Αυτόματη παραγωγή διεπαφών χρήστη για διαδικτυακές υπηρεσίες τύπου REST [31] «World Wide Web Consortium (W3C),» [Ηλεκτρονικό]. Available: [Πρόσβαση 20 October 2016]. [112]

113 ΠΑΡΑΡΤΗΜΑ (Α) ΠΑΡΑΡΤΗΜΑ (Α) Στο παράρτημα αυτό θα παρουσιαστούν και θα επεξηγηθούν όλα τα ερωτήματα που αναπτύχθηκαν στο μοντέλο εισόδου για τον σκοπό της παρούσας διπλωματικής εργασίας. Ερώτημα 1: getmainresources [query public getmainresources (anannotationstack: AnnotationStack): OrderedSet(JavaResourceModelManager) = (anannotationstack.hascorepsm.hasjavarmmanager-anannotationstack.hascorepsm.hasjavarmmanager ->intersection(anannotationstack.hascorepsm.hasjavarmodel.hasrelatedjavarmmanager ->asorderedset()))->asorderedset() /] Περιγραφή: Για την εύρεση των πόρων εκείνων οι οποίοι δεν είναι σχετικοί από άλλους πόρους συντάχθηκε το ερώτημα getmainresources το οποίο επιστρέφει δομημένα σε OrderedSet τα στοιχεία τύπου JavaResourceModelManager. Από όλα τα στοιχεία τύπου JavaResourceModelManager αφαίρεσε εκείνα που είναι αποτέλεσμα της τομής των στοιχείων JavaResourceModelManager και των στοιχείων JavaResourceModel που έχουν σχετικούς πόρους. Ερώτημα 2: relatedresource [query public relatedresource(anannotationstack : AnnotationStack, p: JavaResourceModel ) : OrderedSet(JavaResourceModelManager) = anannotationstack.hascorepsm.hasjavarcmanager.hasassociatedrmmanager->asorderedset()- >intersection(p.hasrelatedjavarmmanager)->asorderedset() /] Περιγραφή: Απαιτείται η ανάκτηση των πόρων που είναι σχετικοί από άλλους τόσο για την ορθή λειτουργία της εφαρμογής όσο και για την χρησιμοποίηση του ερωτήματος αυτού στο Ερώτημα 1: getmainresources. Το αποτέλεσμα προκύπτει από την τομή της δομημένης λίστας των στοιχείων JavaResourceModelManager του JavaResourceControllerManager (hasassociatedjavarmmanager) και του στοιχείου JavaTResourceModelManager του τρέχοντος JavaResourceModel. [113]

114 Αυτόματη παραγωγή διεπαφών χρήστη για διαδικτυακές υπηρεσίες τύπου REST Ερώτημα 3: getauthenticationperfomer [query private getauthenticationperformer(anannotationstack : AnnotationStack) : AuthenticationPerformer = anannotationstack.hasauthenticationlayer.hasannotation->select(annotation annotation.oclistypeof(authenticationperformer))->at(1) /] Περιγραφή: Στην περίπτωση που η διαδικτυακή εφαρμογή έχει την λειτουργία της ταυτοποίησης πρέπει να εντοπιστεί ο πόρος αυτός που είναι υπεύθυνος για την ταυτοποίηση. Το στοιχείο από το οποίο μπορούμε να αντλήσουμε αυτή την πληροφορία είναι το AuthenticationPerfomer. Επομένως από την λίστα των annotations του AnnotationModel επέλεξε αυτό που είναι τύπου AuthenticationPerfomer ( χρησιμοποιείται η OCL λειτουργία oclistypeof ). Ερώτημα 4: hasbothmodeauthentication [query private hasbothmodeauthentication(anhttpactivity : HTTPActivity, anannotationstack : AnnotationStack) : Boolean = getauthenticationlayerbothmodeannotations(anannotationstack)->exists(bothmodeannotation bothmodeannotation.httpactivityhasauthenticationmode->exists(annhttpactivity annhttpactivity.annotateshttpactivity.name = anhttpactivity.name)) /] Περιγραφή: Όταν η διαδικτυακή εφαρμογή έχει την δυνατότητα ταυτοποίησης αυτό δεν σημαίνει ότι για να αιτηθούμε έναν πόρο πρέπει να έχει γίνει ταυτοποίηση του χρήστη. Επομένως πρέπει να γίνεται έλεγχος αν το αίτημα έχει την δυνατότητα να χρησιμοποιηθεί μόνο από πιστοποιημένους χρήστες (AuthenticationOnlyMode), από χρήστες επισκέπτες (GuestMode) ή και από τους δύο (BothMode). Το ερώτημα αυτό επιστρέφει μια Boolean μεταβλητή η τιμή της οποίας είναι ένα σε περίπτωση που το HTTP Activity του εκάστοτε πόρου έχει κάποιο από τα annotations που εξάχθηκαν μέσω του Ερώτημα 5: getauthenticationlayerbothmodeannotations, σε διαφορετική περίπτωση επιστρέφει μηδέν. Ελέγχεται το όνομα του HTTPAvtivity του τρέχοντος πόρου με το όνομα του στοιχείου AnnHTTPActivity που βρίσκεται στο στοιχείο AuthenticationMode. [114]

115 ΠΑΡΑΡΤΗΜΑ (Α) Ερώτημα 5: getauthenticationlayerbothmodeannotations [query private getauthenticationlayerbothmodeannotations(anannotationstack : AnnotationStack) : Sequence(BothMode) = anannotationstack.hasauthenticationlayer.hasannotation->select( annotation annotation.oclistypeof(bothmode))->assequence() /] Περιγραφή: Με το ερώτημα αυτό εξάγονται ως ακολουθία τα στοιχεία τύπου BothMode. Επομένως από την λίστα των annotations του AnnotationModel επέλεξε αυτό που είναι τύπου BothMode. Ερώτημα 6: getsearchcontrollerannotations [query private getsearchcontrollerannotations(anannotationstack : AnnotationStack) : Sequence(SearchController) = anannotationstack.hassearchlayer.hasannotation->select(annotation annotation.oclistypeof(searchcontroller))->assequence() /] Περιγραφή: Στην περίπτωση που η διαδικτυακή υπηρεσία έχει την δυνατότητα της αναζήτησης τότε πρέπει να εντοπιστούν οι πόρου εκείνοι που έχουν ορισθεί ως πόρου υπεύθυνοι για την λειτουργία αυτή. Το αποτέλεσμα είναι μία ακολουθία στοιχείων τύπου SearchController. Στο SearchLayerPSM εντόπισε τα στοιχεία τύπου SearchController. Ερώτημα 7: getsearchableresources [query private getsearchableresources(jalgorc : JavaAlgoResourceController, anannotationstack : AnnotationStack) : Sequence(SearchableJavaResourceModel) = jalgorc.getsearchhttphandler(anannotationstack).searchesjavaresourcemodel->assequence() /] Περιγραφή: Για να μπορέσουμε να χρησιμοποιήσουμε σωστά την λειτουργία της αναζήτησης πρέπει να εξαχθούν και οι πόροι οι οποίο λαμβάνουν μέρος στην αναζήτηση, δηλαδή οι πόροι με βάση των οποίων γίνεται η αναζήτηση μίας ή περισσοτέρων των ιδιοτήτων του. Επομένως, το ερώτημα αυτό επιστρέφει μία [115]

116 Αυτόματη παραγωγή διεπαφών χρήστη για διαδικτυακές υπηρεσίες τύπου REST ακολουθία από SearchableJavaResourceModels, χρησιμοποιώντας και τα ερωτήματα που αναλύονται παρακάτω, Ερώτημα 8: getsearchhttphandler, Ερώτημα 9: getsearchhttphandlerannotations. Ερώτημα 8: getsearchhttphandler [query private getsearchhttphandler(jalgorc : JavaAlgoResourceController, anannotationstack : AnnotationStack) : SearchHTTPHandler = getsearchhttphandlerannotations(anannotationstack)->select(searchhttphandlerannotation jalgorc.javaalgorcontrollerhashttpactivity.hashttpactivityhandler- >includes(searchhttphandlerannotation.ishttpactivityhandler.annotateshttpactivityhandler))->at(1) Περιγραφή: Από την λίστα των στοιχείων SearchHTTPHandlerAnnotation του ερωτήματος επιστρέφει αυτό για το οποίο το JavaAlgoResourceController έχει HTTPActicityHandler που περιλαμβάνει ένα από τα στοιχεία της λίστας των SearchHTTHandlerAnnotations. Ερώτημα 9: getsearchhttphandlerannotations [query private getsearchhttphandlerannotations(anannotationstack : AnnotationStack) : Sequence(SearchHTTPHandler) = anannotationstack.hassearchlayer.hasannotation->select( annotation annotation.oclistypeof(searchhttphandler))->assequence() /] Περιγραφή: Το ερώτημα αυτό επιστρέφει ως μία ακολουθία τα στοιχεία τύπου SearchHTTPHandler από το SearchLayerPSM. Ερώτημα 10: getjavarestclientcontrollerannotations [query private getjavarestclientcontrollerannotations(anannotationstack : AnnotationStack) : Sequence(JavaRESTClientController) = anannotationstack.hasexternalservicelayer.hasannotation->select(annotation annotation.oclistypeof(javarestclientcontroller))->assequence() /] Περιγραφή: Αντίστοιχα, όπως και για την διαδικασία της αναζήτησης ανακτήθηκαν οι πόροι που ήταν αρμόδιοι, έτσι και για την περίπτωση της επικοινωνίας της διαδικτυακής υπηρεσίας με κάποια εξωτερική [116]

117 ΠΑΡΑΡΤΗΜΑ (Α) υπηρεσία πρέπει να ανακτηθούν και πάλι οι αντίστοιχοι πόροι. Με αυτό το ερώτημα λοιπόν επιστρέφουμε μία ακολουθία στοιχείων του τύπου JavaRESTClientController του ExternalServicePSM. Ερώτημα 11: getqueryparams [query private getqueryparams(httpactivity : HTTPActivity, anannotationstack : AnnotationStack) : Sequence(QueryParam) = anannotationstack.getjavarestclienthttpactivity(anannotationstack, httpactivity).hasqueryparam->assequence() /] Περιγραφή: Όταν υπάρχει επικοινωνία με την εξωτερική διαδικτυακή υπηρεσία είναι πολύ πιθανό μαζί με το αίτημα που κάνουμε στην υπηρεσία να χρειάζεται να στείλουμε και ορισμένες παραμέτρους. Για παράδειγμα, σε πολλές διαδικτυακές υπηρεσίες μία από αυτές τις παραμέτρους είναι ένα κλειδί για να μπορέσει ο χρήστης να χρησιμοποιεί την υπηρεσία. Με αυτό το ερώτημα λοιπόν γίνεται ανάκτηση, ως ακολουθία, των παραμέτρων για την λειτουργία της εξωτερικής υπηρεσίας. Ερώτημα 12: getjavarestclienthttpactivity [query private getjavarestclienthttpactivity(anannotationstack : AnnotationStack, httpactivity : HTTPActivity) : JavaRESTClientHTTPActivity = anannotationstack.getjavarestclientcontrollerannotations(anannotationstack). hasjavarestclienthttpactivity->select( javarestclienthttpactivity javarestclienthttpactivity.isjavarestclienthttpactivity.annotateshttpactivity ->includes(httpactivity))->at(1) /] [117]

118 Αυτόματη παραγωγή διεπαφών χρήστη για διαδικτυακές υπηρεσίες τύπου REST ΠΑΡΑΡΤΗΜΑ (Β) Σχήμα 53: Τμήμα παραγόμενου κώδικα του ελεγκτή SigninController [118]

119 ΠΑΡΑΡΤΗΜΑ (Β) Σχήμα 54: Τμήμα του κώδικα της συνάρτηση searchfn του ελεγκτή SearchRecipeController [119]

120 Αυτόματη παραγωγή διεπαφών χρήστη για διαδικτυακές υπηρεσίες τύπου REST Σχήμα 55: Τμήμα κώδικα του mapgeocoding.controller..js για την επικοινωνία με την εφαρμογή BigMaps [120]

121 ΠΑΡΑΡΤΗΜΑ (Β) Σχήμα 56: Τμήμα του currencyconverter για την ανάκτηση της απόκρισης από την εξωτερική υπηρεσία currencylyaer [121]