Διπλωματική εργασία. Σχεδίαση και ανάπτυξη διαδικτυακών εφαρμογών πελάτη (web client) για διαδικτυακές υπηρεσίες τύπου REST (RESTful Web Services)

Transcript

1 ΑΡΙΣΤΟΤΕΛΕΙΟ ΠΑΝΕΠΙΣΤΗΜΙΟ ΘΕΣΣΑΛΟΝΙΚΗΣ ΠΟΛΥΤΕΧΝΙΚΗ ΣΧΟΛΗ Τμήμα Ηλεκτρολόγων Μηχανικών και Μηχανικών Υπολογιστών Εργαστήριο Επεξεργασίας Πληροφορίας και Υπολογισμών Διπλωματική εργασία Σχεδίαση και ανάπτυξη διαδικτυακών εφαρμογών πελάτη (web client) για διαδικτυακές υπηρεσίες τύπου REST (RESTful Web Services) Μιχαηλίδου Ναταλία Δήμητρα Α.Ε.Μ.: 6863 Επιβλέπων: Επίκουρος Καθηγητής Ανδρέας Λ. Συμεωνίδης Συνεπιβλέπων: Υποψήφιος Διδάκτωρ Χριστόφορος Ζολώτας

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

3 Περίληψη Το REST αρχιτεκτονικό στυλ περιγράφηκε για πρώτη φορά από τον Roy T. Fielding το 2000 σε μια προσπάθεια γενίκευσης των βασικών αρχών αρχιτεκτονικής του διαδικτύου και παρουσίασής τους ως ένα συγκεκριμένο πλαίσιο περιορισμών. Έκτοτε, το REST αρχιτεκτονικό στυλ γνώρισε τεράστια απήχηση στην ανάπτυξη διαδικτυακών υπηρεσιών και πλέον αποτελεί το κυρίαρχο πρότυπο για την ανάπτυξή τους. Παρά ταύτα, η ανάπτυξη εφαρμογών πελάτη που θα καταναλώνουν RESTful διαδικτυακές υπηρεσίες περιορίζεται στη δημιουργία βιβλιοθηκών πελάτη, οι οποίες απαιτούν την παρέμβαση προγραμματιστή για να καταστούν πλήρως λειτουργικές. Η συγκεκριμένη διπλωματική εργασία φιλοδοξεί να θέσει τα πρώτα βήματα προς την κατέυθυνση αυτοματοποίησης της διαδικασίας ανάπτυξης διαδικτυακών εφαρμογών πελάτη. Για την αυτοματοποίηση της διαδικασίας ανάπτυξης εφαρμογών πελάτη αξιοποιείται η θεωρία της τεχνολογίας λογισμικού και εξετάζεται η προσέγγιση της MDA αρχιτεκτονικής, που εισήχθηκε από τον όμιλο OMG. Η συγκεκριμένη αρχιτεκτονική υποστηρίζει τον ορισμό μοντέλων σε διάφορα επίπεδα αφαίρεσης και επιτρέπει την ανάπτυξη λογισμικού με βάση σχεδιαστικούς στόχους που σχετίζονται με το αντικείμενο του προβλήματος, και όχι με βάση το υποκείμενο υπολογιστικό περιβάλλον. Με αυτό τον τρόπο επιδιώκεται η επιτάχυνση της διαδικασίας ανάπτυξης λογισμικού και η παραγωγή λογισμικού με μεγαλύτερη αξιοπιστία, επεκτασιμότητα και διαλειτουργικότητα. Στην παρούσα διπλωματική εργασία η μηχανή παραγωγής εφαρμογών πελάτη Automated Client Engine παράγει διαδικτυακές εφαρμογές πελάτη που καταναλώνουν RESTful διαδικτυακές υπηρεσίες (με συγκεκριμένα χαρακτηριστικά, όπως παράγονται από την πλατφόρμα S-CASE Οι παραγόμενες εφαρμογές πελάτη διαχειρίζονται την αποστολή CRUD (create, read, update και delete) αιτημάτων και λαμβάνουν, επεξεργάζονται και παρουσιάζουν τις αποκρίσεις του εξυπηρετητή. Έχουν τη δυνατότητα ταυτοποίησης των χρηστών και των αιτημάτων τους, χρησιμοποιούν στοιχεία UI/UX σχεδιασμού και ενσωματώνουν CSS μορφοποίηση. Η υλοποίησή τους έγινε σε Angular JS και HTML γλώσσα προγραμματισμού και είναι έτοιμες προς εκτέλεση (ready to deploy). 2

4 Σχεδίαση και ανάπτυξη διαδικτυακής εφαρμογής πελάτη για διαδικτυακές υπηρεσίες τύπου REST Abstract Design and development of web client applications for RESTful Web Services The REST architectural style was introduced for the first time by Roy T. Fielding in 2000 in an attempt to generalize the fundamental principles of the web s architecture and to present them as a specific set of restrictions. Since then, the REST architectural style has become extremely popular for web serviceoriented development and is practically dominant as far as web service development is concerned. The development of web client applications that must consume RESTful web services, is however limited to web client libraries, and involve heavy front-end developer effort to become fully functional. The current thesis aspires to set the first steps for automating the process of developing the front-end of web client applications. In order to automate the process of generating web clients, MDA principles are applied (introduced by the OMG group). This MDA approach supports the definition of models in different levels of abstraction and thus permits software development based on the design objectives related to the problem and not the underlying computing environment. This way acceleration of the software development process and software production with higher credibility, extensibility and interoperability is pursued. Within the context of this thesis the Automated Client Engine is designed and developed. It produces web client applications that consume RESTful web services, as generated by S-CASE ( These web client applications manage CRUD (create, read, update and delete) requests as defined at the RESTful service level. In addition, the generated web clients provide authentication features, and embed UI/UX elements and CSS format styling. They are developed in Angular JS and HTML and are ready to deploy. Michaelidou Natalia Dimitra nataliam@auth.gr Electrical and Computer Engineering Department Aristotle University of Thessaloniki 3

5 Πίνακας Περιεχομένων Περίληψη... 2 Abstract... 3 Πίνακας Περιεχομένων... 4 Ευρετήριο Εικόνων... 8 Ευρετήριο Πινάκων Ευρετήριο Αλγορίθμων Συντομογραφίες Εισαγωγή Στόχος διπλωματικής εργασίας Διάρθρωση εγγράφου Θεωρητικό και τεχνολογικό υπόβαθρο Τεχνολογία λογισμικού Διαδικτυακές εφαρμογές, διαδικτυακές υπηρεσίες και Web API Hypertext Transfer Protocol (HTTP) Universal Resource Identifier (URI) HTTP Method Request/ Response Header Message Body Response Status Code Διαδικτυακές υπηρεσίες Διαδικτυακές διεπαφές προγραμματισμού εφαρμογών (Web APIs) Πρωτόκολλο πρόσβασης απλού αντικειμένου (Simple Object Access Protocol, SOAP) Μεταφορά αναπαράστασης κατάστασης (REpresentational State Transfer, REST) και αρχιτεκτονική προσανατολισμένη προς τον πόρο (Resource-Oriented Architecture, ROA) Σύνδεσμοι υπερμέσων (Hypermedia Links)

6 Σχεδίαση και ανάπτυξη διαδικτυακής εφαρμογής πελάτη για διαδικτυακές υπηρεσίες τύπου REST Πόρος (Resource) Ομοιόμορφα αναγνωριστικά πόρων (Uniform Resource Identifiers, URIs) Αναπαράσταση του πόρου (Resource Representation) Χαρακτηριστικά της προσανατολισμένης στον πόρο αρχιτεκτονικής Η αυξανόμενη ζήτηση για web APIs Τεχνολογία λογισμικού οδηγούμενη από μοντέλα (Model Driven Engineering) Αρχιτεκτονική οδηγούμενη από μοντέλα (Model Driven Architecture, MDA) Μοντέλα, μεταμοντέλα και μετα-μεταμοντέλα Meta-Object Facility (MOF) Μετασχηματισμός μοντέλου Εργαλεία MDE XML Metadata Interchange (XMI) πρότυπο Ecore Modeling Framework (EMF) Atlas Transformation Language Acceleo Model-to-Text transformation language Ανάπτυξη διαδικτυκής εφαρμογής πελάτη για διαδικτυακές υπηρεσίες τύπου REST μέσω MDA αρχιτεκτονικής Το μοτίβο Μοντέλο-Όψη-Ελεγκτής (Model-View-Controller, MVC) Εφαρμογή μοναδικής σελίδας (Single Page Application, SPA) Κριτήρια αξιολόγησης ενός διαδικτυακού API Υπάρχουσες Τεχνολογίες Υπάρχουσες τεχνολογίες για την αυτοματοποιημένη παραγωγή διαδικτυακών υπηρεσιών τύπου REST Ruby on Rails EMF-Rest Django REST Framework

7 3.1.4 Η S-CASE MDE μηχανή σε σχέση με τις τελευταίες τεχνολογίες Υπάρχουσες τεχνολογίες για αυτοματοποιημένη παραγωγή εφαρμογής πελάτη APIMATIC DX Kits Restlet Studio Swagger Code Generator Συμπεράσματα Η χρήση του πλαισίου AngularJS για την ανάπτυξη εφαρμογών πελάτη Μεθοδολογία Η προσέγγιση του S-CASE στη δημιουργία διαδικτυακών εφαρμογών Σχεδιαστικοί στόχοι και απαιτήσεις Η αρχιτεκτονική των παραγόμενων εφαρμογών πελάτη PSM μεταμοντέλο Απαιτούμενη πληροφορία Στοιχεία PSM μεταμοντέλου Acceleo μετασχηματισμός PSM μοντέλου σε κώδικα Συστατικά στοιχεία ενός έργου Acceleo Στοιχεία του Acceleo μετασχηματισμού Παραγόμενες εφαρμογές πελάτη Εκτέλεση της Automated Client Engine μηχανής Χρήση των παραγόμενων εφαρμογών πελάτη Παράδειγματα εφαρμογής Παράδειγμα εφαρμογής ebucks API Παράδειγμα εφαρμογής WapoAdminTool API Συμπεράσματα και μελλοντικές προτάσεις Βιβλιογραφία

8 Σχεδίαση και ανάπτυξη διαδικτυακής εφαρμογής πελάτη για διαδικτυακές υπηρεσίες τύπου REST 7

9 Ευρετήριο Εικόνων Εικόνα 1: Κριτήρια λογισμικού [2] Εικόνα 2: Ο κύκλος ανάπτυξης λογισμικού [4] Εικόνα 3: Δομή ενός SOAP μηνύματος [11] Εικόνα 4: Παράδειγμα ενός SOAP αιτήματος και της απόκρισης του διακομιστή [10] Εικόνα 5: Δομή των μηνυμάτων αιτήματος και απόκρισης τύπου REST Εικόνα 6: Παράδειγμα ενός αιτήματος και της αντίστοιχης απόκρισης τύπου REST [14] Εικόνα 7: Οι χρησιμοποιούμενες τεχνολογίες για την ανάπτυξη διαδικτυακών APIs [18] Εικόνα 8: Εκτιμήσεις και πραγματικός αριθμός διαδικτυακών APIs για το ευρετήριο programmable web [18] Εικόνα 9: Συγκριτική αύξηση του πλήθους εφαρμογών σε σχέση με το πλήθος προγραμματιστών [20] 30 Εικόνα 10: Θετικές και αρνητικές επιδράσεις της τεχνολογίας MDE Εικόνα 11: Αδυναμίες της MDE τεχνολογίας Εικόνα 12: Σχέσεις ανάμεσα στα MDA μοντέλα [26] Εικόνα 13: Η δομή του MOF πρότυπου [28] Εικόνα 14: Παραδείγματα μετασχηματισμών μοντέλων [29] Εικόνα 15: Ιεραρχία του Ecore μετα-μεταμοντέλου [32] Εικόνα 16: Σχέση της μοντελοποιημένης εφαρμογής και της εφαρμογής σε OCL [34] Εικόνα 17: Acceleo Model To Text μετασχματισμός Εικόνα 18: Οι διασυνδέσεις μεταξύ των επιπέδων του μοτίβου MVC και του χρήστη [37] Εικόνα 19: Ο κύκλος ζωής μιας παραδοσιακής ιστοσελίδας και μιας εφαρμογής μοναδικής σελίδας [39] Εικόνα 20: Τα επίπεδα του μοντέλου ωριμότητας Richardson [20] Εικόνα 21: Η βασική δομή μίας υπηρεσίας Rails [41] Εικόνα 22: Επισκόπηση του EMF-Rest [43] Εικόνα 23 Αριστερά: Παράδειγμα JSON απόκρισης Δεξιά: Παράδειγμα API τύπου REST [42] Εικόνα 24: Django REST Framework serializer [44] Εικόνα 25: Απόκριση μίας υπηρεσίας παραγμένης από το Django REST Framework [44] Εικόνα 26: Η S-CASE μηχανή σε επίπεδο συστατικών στοιχείων [45] Εικόνα 27: APIMATIC DX Kits υποστηριζόμενες λειτουργίες και γλώσσες προγραμματισμού Εικόνα 28: Τα τέσσερα στάδια της τεχνολογίας λογισμικού οδηγούμενης από μοντέλα [45]

10 Σχεδίαση και ανάπτυξη διαδικτυακής εφαρμογής πελάτη για διαδικτυακές υπηρεσίες τύπου REST Εικόνα 29: Υλοποίηση αυτοματοποιημένης παραγωγής εφαρμογής πελάτη και η σχέση του με το S-CASE Εικόνα 30 Παράδειγμα εφαρμογής Εικόνα 32: Περιεχόμενα φάκελου dev για την εφαρμογή wapoadmintoolapi Εικόνα 31: Περιεχόμενα αρχείου AccountsSearch, που βρίσκεται στο φάκελο dev Εικόνα 33: Απλοποιημένο διάγραμμα του PSM μεταμοντέλου: Το στοιχείο ServicePSM Εικόνα 34: Γενική δομή των παραγόμενων εφαρμογών πελάτη Εικόνα 35: Η διεπαφή του Eclipse-Plugin Εικόνα 36: Σχεδιάγραμα του ebucks API Εικόνα 37: Δομή των παραγόμενων αρχείων για το ebucks API Client Εικόνα 38: Αρχική σελίδα του ebucks API Client Εικόνα 39: Εμφάνιση της απόκρισης για το αίτημα ανάκτησης λίστας Order Εικόνα 40: Εμφάνιση της απόκρισης για την ανάκτηση συγκεκριμένου Order Εικόνα 41: Φόρμα ανανέωσης ενός Order Εικόνα 42: Φόρμα δημιουργίας νέου Order Εικόνα 43 Μετάβαση στη σελίδα Product Εικόνα 44: Οι πόροι και οι επιτρεπτές HTTP μέθοδοι για το WapoAdminTool APi Εικόνα 45: Δομή των παραγόμενων φακέλων για το WapoAdminTool API Client Εικόνα 46: Σελίδα για την υλοποίηση του authentication Εικόνα 47: Φόρμα δημιουργίας account Εικόνα 48: Φόρμα δημιουργίας νέου user Εικόνα 49: Μήνυμα αποτυχίας ταυτοποίησης Εικόνα 50: Αρχική σελίδα του WapoAdminTool API Client Εικόνα 51: Λίστα αντικειμένων Currencies Εικόνα 52: Ανάκτηση συγκεκριμένου στιγμιότυπου του πόρου currencies Εικόνα 53: Φόρμα για τη δημιουργία νέου currency Εικόνα 54: Διαγραφή ενός account

11 Ευρετήριο Πινάκων Πίνακας 1: Αποτελέσματα επίδοσης διαδικτυακών υπηρεσιών τύπου SOAP και REST σε κινητό [16] Πίνακας 2: Αποτελέσματα επίδοσης διαδικτυακών διεπαφών τύπου SOAP και REST σε πολυμεσικές τηλεδιασκέψεις [16] Πίνακας 3: Επιδράσεις της χρήσης της MDE τεχνολογίας λογισμικού Πίνακας 4: Υποστηριζόμενοι τύποι μέσων Πίνακας 5: Τύποι HTTPVerb Πίνακας 6: Τύποι LinkType Πίνακας 7: Ιδιότητες του στοιχείου ServicePSM Πίνακας 8: Σχέσεις του ServicePSM Πίνακας 9: Επισκόπηση των modules του μετασχηματισμού, των εισόδων τους και των τύπων των παραγόμενων αρχείων

12 Ευρετήριο Αλγορίθμων Σχεδίαση και ανάπτυξη διαδικτυακής εφαρμογής πελάτη για διαδικτυακές υπηρεσίες τύπου REST Αλγόριθμος 1: Σύνταξη ενός απλού acceleo template Αλγόριθμος 2: Έλεγχος πλήθους πόρων για την αρχική σελιδα και επαναληπτική διαδικασία Αλγόριθμος 3: Επαναληπτική διαδικασία για την ανάκτηση πόρων προς εμφάνιση στην αρχική σελίδα Αλγόριθμος 4: Ανάκτηση πόρων στους οποίους επιτρέπεται η PUT μέθοδος Αλγόριθμος 5: Επαναληπτική διαδικασία για την ανάκτηση πόρων σχετικών από πόρο Αλγόριθμος 6: Επαναληπτική διαδικασία για την ανάκτηση ιδιοτήτων του πόρου Αλγόριθμος 7: Έλεγχος για την κατάλληλη μορφοποίηση στην περίπτωση εισαγωγής κωδικού ή κειμένου Αλγόριθμος 8: Έλεγχος για την εισαγωγή CSS μορφοποίησης Αλγόριθμος 9: Ανάκτηση πόρων για την δημιουργία όψεων Αλγόριθμος 10: Ανάκτηση πόρων σχετικών με πόρο για τη δημιουργία του κουμπιού Back Αλγόριθμος 11: Ανάκτηση πόρων για την δημιουργία HTTP αιτημάτων Αλγόριθμος 12: Ανάκτηση πόρων σχετικών με τον πόρο για δημιουργία δρομολόγησης στον ελεγκτή. 84 Αλγόριθμος 13: Ανάκτηση πόρων για τη δημιουργία angular services Αλγόριθμος 14: Ανάκτηση πόρων για τη δημιουργία CRUD αιτημάτων Αλγόριθμος 15: Δημιουργία πλαισίων διαλόγου Αλγόριθμος 16: Ανάκτηση πόρων για τη δημιουργία δρομολόγησης στο app.js Αλγόριθμος 17: Έλεγχος για την ύπαρξη όψης SignIn και δρομολόγησή της Αλγόριθμος 18: Έλεγχος για τη δημιουργία όψης και ελεγκτή ταυτοποίησης Αλγόριθμος 19: Επαναληπτική διαδικασία για την ανάκτηση πόρων για τη δημιουργία φόρμας εισαγωγής στοιχείων ταυτοποίησης Αλγόριθμος 20: Ανάκτηση πόρων για τη δημιουργία νέου λογαρισμού Αλγόριθμος 21: Ανάκτηση πόρων για την παραμετροποίηση του ελεγκτή LoginCtrl Αλγόριθμος 22: Ανάκτηση πόρων για την αποστολή αιτήματος ταυτοποίησης στοιχείων Αλγόριθμος 23: Επαναληπτική διαδικασία για τη δημιουργία κενών αρχείων Αλγόριθμος 24: Query firstonly Αλγόριθμος 25: Query otherlayer Αλγόριθμος 26: Query toplayer Αλγόριθμος 27: Query relatedresource Αλγόριθμος 28: Query ifresult

13 Αλγόριθμος 29: Query getfirstresource Αλγόριθμος 30: Query getauthenticationperformer Αλγόριθμος 31: App.js για το ebucks service Αλγόριθμος 32: Μέρος του ελεγκτή orderctrl.js για το ebucks service Αλγόριθμος 33: Μέρος της όψης order.html για το ebucks service Αλγόριθμος 34: Services.js για το ebucks service

14 Συντομογραφίες Σχεδίαση και ανάπτυξη διαδικτυακής εφαρμογής πελάτη για διαδικτυακές υπηρεσίες τύπου REST 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 SOAP: Simple Object Access Protocol SPA: Single Page Application URI: Uniform Resource Identifier XMI: XML Metadata Interchange XML: Extensible Markup Language 13

15 1 Εισαγωγή 1.1 Στόχος διπλωματικής εργασίας Στόχος της παρούσας διπλωματικής εργασίας είναι η ανάπτυξη μίας μηχανής αυτοματοποιήσης της παραγωγής εφαρμογών πελάτη που θα καταναλώνουν REST διαδικτυακές υπηρεσίες. Για το σκοπό αυτό αξιοποιήθηκε η θεωρία της τεχνολογίας λογισμικού και μία από τις πιο διαδεδομένες μορφές του Model Driven Engineering, η Model Driven Architecture [1]. Η ανάπτυξη της μηχανής αυτοματοποίησης παραγωγής εφαρμογών πελάτη βασίζεται στην παραγωγή μίας σειράς μετασχηματισμών στο μοντέλο PSM, που παράγεται από το S-CASE και τη μετατροπή του σε πηγαίο κώδκα. Οι παραγόμενες εφαρμογές πελάτη θα πρέπει να είναι έτοιμες προς εκτέλεση και θα πρέπει να υποστηρίζουν CRUD αιτήματα και αποκρίσεις, ταυτοποίηση (authentication), διαδραστική διεπαφή με τον χρήστη, εμφάνιση πολλαπλών πόρων στην αρχική σελίδα και πολλαπλή δρομολόγηση προς πόρους. 1.2 Διάρθρωση εγγράφου Σε αυτή την ενότητα παρουσιάζεται συνοπτικά το αντικείμενο της παρούσας διπλωματικής εργασίας και το περιεχόμενο του εγγράφου. Στη συνέχεια, ακολουθεί το δεύτερο κεφάλαιο, όπου παρουσιάζονται οι βασικές θεωρητικές έννοιες, που χρησιμοποιήθηκαν για τη στοιχειοθέτηση και υλοποίηση της παρούσας διπλωματικής εργασίας. Σε αυτό το κεφάλαιο αναλύεται συνοπτικά η θεωρία της τεχνολογίας λογισμικού, δίνονται βασικοί ορισμοί των διαδικτυακών υπηρεσιών και APIs και αναλύονται οι υπάρχουσες αρχιτεκτονικές για την ανάπτυξη μίας διαδικτυακής υπηρεσίας. Στη συνέχεια του δεύτερου κεφαλαίου, αναδεικνύεται η συνεχής αύξηση της ζήτησης για REST web APIs και η προσπάθεια εξυπηρέτησης αυτής της ζήτησης με τη χρήση των MDE και MDA τεχνολογιών. Τέλος, ακολουθεί η παρουσίαση των βασικών προτύπων, που θα πρέπει να ακολουθεί μία διαδικτυακή ερφαρμογή πελάτη. Στο τρίτο κεφάλαιο, παρουσιάζονται οι υπάρχουσες τεχνολογίες για την ανάπτυξη διαδικτυακών υπηρεσιών, που ακουλουθούν το REST αρχιτεκτονικό στυλ, και διαδικτυακών εφαρμογών πελάτη. Στο τέταρτο κεφάλαιο, περιγράφεται συνοπτικά το S-CASE έργο, πάνω στο οποίο βασίζεται η μηχανή Automated Client Engine, που αποτελεί το αποτέλεσμα της συγκεκριμένης διπλωματικής εργασίας, και οι σχεδιαστικοί στόχοι και απαιτήσεις, που θα πρέπει να πληρούν οι παραγόμενες εφαρμογές πελάτη. Ακολούθως, παρουσιάζονται το PSM μεταμοντέλο από το οποίο παράγεται ο επιθυμητός κώδικας, η 14

16 Σχεδίαση και ανάπτυξη διαδικτυακής εφαρμογής πελάτη για διαδικτυακές υπηρεσίες τύπου REST διαδικασία μετασχηματισμού του σε λειτουργικές εφαρμογές πελάτη, η δομή των παραγόμενων εφαρμογών και ο τρόπος εγκατάστασής τους. Στο πέμπτο κεφάλαιο, παρατίθενται παραδείγματα από εφαρμογές πελάτη, που παράχθηκαν από την ACE. Τέλος, στο έκτο κεφάλαιο εκτιμώνται τα αποτελέσματα της παρούσας διπλωματικής εργασίας καθώς και προτάσεις για περαιτέρω επεκτάσεις στο μέλλον. 15

17 2 Θεωρητικό και τεχνολογικό υπόβαθρο 2.1 Τεχνολογία λογισμικού Είναι αδιαμφισβήτητο πλέον πως η τεχνολογική ανάπτυξη και καινοτομία διαδραματίζει τεράστιο ρόλο στα πλαίσια της σύγχρονης κοινωνίας. Από το επίπεδο της παραγωγής έως το επίπεδο της καθημερινότητας του ατόμου παρατηρείται η ολοένα και μεγαλύτερη εξάρτηση από την τεχνολογία. Ειδικά στον τομέα της πληροφορίας, η εμφάνιση, η διευρυμένη χρήση και η συνεχής εξέλιξη σε επίπεδο υλικού του ηλεκτρονικού υπολογιστή και του διαδικτύου εκτίναξε τις δυνατότητες δημιουργίας, διάδοσης και αποθήκευσης της πληροφορίας. Κατ επέκταση, το λογισμικό και η ανάπτυξη του δε θα μπορούσαν παρά να ακολουθήσουν αυτή την πρόοδο, ειδικά κατά την περίοδο διάδοσης του διαδικτύου και έπειτα. Η τεχνολογία λογισμικού ήταν εκείνη που καθιέρωσε συγκεκριμένες μεθοδολογίες και σωστές πρακτικές για την ανάπτυξη λογισμικού και πολύ περισσότερο σήμερα αποτελεί καθοριστικό κομμάτι της διαδικασίας ανάπτυξης λογισμικών. Η τεχνολογία λογισμικού ορίζεται ως η συστηματική προσέγγιση της ανάλυσης, σχεδιασμού, εκτίμησης, εκτέλεσης, δοκιμής και συντήρησης του λογισμικού με σκοπό την ταχύτερη, φθηνότερη και πιο αξιόπιστη ανάπτυξή του [2]. Για να αντιληφθούμε τη σημασία και τη δυσκολία της επιστήμης της τεχνολογίας λογισμικού θα πρέπει να έχουμε κατά νου ότι το λογισμικό δεν είναι απλώς προγράμματα. Το λογισμικό είναι «το σύνολο των προγραμμάτων, διαδικασιών, κανόνων, δεδομένων και της αντίστοιχης τεκμηρίωσης» [3]. Με δεδομένους αυτούς τους ορισμούς, μπορούμε να προσδιορίσουμε και τα θεμελίωση προβλήματα που από τη φύση του αντικειμένου της αντιμετωπίζει η τεχνολογία λογισμικού. Επεκτασιμότητα: Οι μέθοδοι ανάπτυξης λογισμικού αποκλίνουν σε μεγάλο βαθμό ανάλογα με το μέγεθος του συστήματος. Οι τεχνολογικές απαιτήσεις καθώς και οι ανάγκες διεύθυνσης είναι πολύ χαμηλότερες για τη δημιουργία ενός μικρού λογισμικού, που πιθανόν να δημιουργούνταν από πολύ μικρό αριθμό προγραμματιστών, σε σχέση με ένα μεγάλο έργο λογισμικού, στο οποίο θα συμμετέχει ένας μεγάλος αριθμός εργαζομένων και άρα θα απαιτείται πολύ μεγαλύτερος βαθμός οργάνωσης και ανάθεσης των διάφορων κομματιών του λογισμικού. Κόστος, Χρονικός Προγραμματισμός και Ποιότητα: Όσον αφορά στο κόστος, αυτό συνίσταται στο ανθρώπινο δυναμικό, στον εξοπλισμό, στο λογισμικό, που απαιτείται για την υλοποίηση του έργου και λοιπούς απαιτούμενους πόρους. Θα πρέπει να σημειωθεί ότι συνήθως το μεγαλύτερο κόστος για την ανάπτυξη ενός λογισμικού είναι αυτό του ανθρώπινου δυναμικού, καθώς βασίζεται στην δυνατότητα επινοητικότητας και αφαίρεσης του ανθρώπινου νου. Παράλληλα, ο χρονικός προγραμματισμός 16

18 Σχεδίαση και ανάπτυξη διαδικτυακής εφαρμογής πελάτη για διαδικτυακές υπηρεσίες τύπου REST συμβάλλει τόσο στον υπολογισμό του κόστους (και αντίστροφα ένα συγκεκριμένο χρηματικό πλαφόν μπορεί να καθορίσει τον χρονικό προγραμματισμό), όσο και στην δυνατότητα καθορισμού και περιορισμού του χρονικού διαστήματος από τη σύλληψη μιας ιδέας έως την υλοποίηση της. Τέλος, η ποιότητα αποτελεί θεμελιώδη στόχο κάθε έργου και θα μπορούσε να περιγραφεί με βάση το σχήμα της Εικόνας 1 και με προεξάρχον κριτήριο την αξιοπιστία του λογισμικού. Εικόνα 1: Κριτήρια λογισμικού [3] Συνοχή: Όπως σε κάθε έργο, έτσι και στην ανάπτυξη λογισμικού θα πρέπει να βρεθεί η χρυσή τομή ανάμεσα στα παραπάνω βασικά κριτήρια του μηχανικού. Η επίτευξη αυτής της χρυσής τομής επιτρέπει την εκτίμηση του αποτελέσματος με ακρίβεια και την εξέλιξη των διαδικασιών για την παραγωγή καλύτερης ποιότητας λογισμικού. Κατά τη μακρά πορεία εξέλιξης της τεχνολογίας λογισμικού δημιουργήθηκαν και δοκιμάστηκαν πολλά μοντέλα ανάπτυξης λογισμικού. Βασικό στοιχείο των περισσότερων μοντέλων, που αναπτύχθηκαν, είναι η λογική της διαδικασίας ανάπτυξης σε στάδια, σε κάθε στάδιο της οποίας πρέπει να υπάρχει δεδομένη είσοδος και έξοδος. Αυτά τα διακριτά στάδια συνιστούν τις δραστηριότητες του κύκλου ζωής ενός λογισμικού [4]. Συνοπτικά αυτές είναι: Ανάλυση απαιτήσεων και καθορισμός προδιαγραφών: Κάθε προτεινόμνο μοντέλο της διεργασίας ανάπτυξης λογισμικού περιλαμβάνει δραστηριότητες που ενέχουν την εξαγωγή απαιτήσεων. Πρόκειται ουσιαστικά για την κατανόηση των στοιχείων που περιμένουν από το σύστημα οι πελάτες και οι χρήστες. Τα στοιχεία αυτά χωρίζονται σε λειτουργικές και μη λειτουργικές απαιτήσεις και καταλήγουν στον καθορισμό των προδιαγραφών που θα πρέπει να πληροί το σύστημα. 17

19 Σχεδίαση συστήματος ή αρχιτεκτονική: Η σχεδίαση του συστήματος είναι η δημιουργική διεργασία μετατροπής του προβλήματος, που περγράφεται από τις προδιαγραφές του συστήματος, σε λύση. Σχεδίαση λογισμικού: Η σχεδίαση του λογισμικού συνίσταται στην παραγωγή του τεχνικού σχεδίου, το οποίο επιτρέπει στους κατασκευαστές του συστήματος να κατανοήσουν το είδος του τελικού υλικού και λογισμικού, που χρειάζεται για να λυθεί το πρόβλημα. Υλοποίηση λογισμικού: Σε αυτό το στάδιο συγγράφονται τα προγράμματα, που υλοποιούν το τεχνικό σχέδιο. Η συγγραφή των προγραμμάτων είναι απαραίτητο να συμμορφώνονται με συγκεκριμένα πρότυπα, προκειμένου να αποφευχθούν λάθη κατά την ανάπτυξη των προγραμμάτων και την διευκόλυνση μετέπειτα τροποποιήσεων και συντήρησης. Έλεγχος της υλοποίησης: Στο στάδιο ελέγχου της υλοποίησης περιλαμβάνεται ο έλεγχος του κώδικα κάθε προγράμματος καθώς και συνολικοί έλεγχοι που έχουν να κάνουν με τον έλεγχο λειτουργίας, επίδοσης, αποδοχής και εγκατάστασης. Παράδοση συστήματος: Η παράδοση του συστήματος περιλαμβάνει την εκπαίδευση του χρήστη στο σύστημα και την έγγραφη τεκμηρίωση του συστήματος. Συντήρηση: Ως συντήρηση θεωρείται κάθε εργασία γίνει για την αλλαγή του συστήματος αφότου καταστεί λειτουργικός. Η σχηματοποίηση αυτής της διαδικασίας παρουσιάζεται στην Εικόνα 2. Εικόνα 2: Ο κύκλος ανάπτυξης λογισμικού [5] 18

20 Σχεδίαση και ανάπτυξη διαδικτυακής εφαρμογής πελάτη για διαδικτυακές υπηρεσίες τύπου REST Είναι σαφές, πως η εξέλιξη της επιστήμης της τεχνολογίας λογισμικού εξαρτάται σε μεγάλο βαθμό από την εφαρμογή των διάφορων μεθοδολογιών της στην πραγματική διαδικασία ανάπτυξης λογισμικού, τροφοδοτεί και αλληλοτροφοδοτείται. Η ορθή εφαρμογή των μοντέλων πάνω στη διαδικασία παραγωγής λογισμικού αποτελεί προαπαιτούμενο για την αποφυγή σημαντικών προβλημάτων, όπως η αυξημένη πολυπλοκότητα, η αλληλεξάρτηση σταδίων και η αύξηση του κόστους. Τέλος, η συνεχής εμφάνιση νέων και πιο σύνθετων αναγκών σε συνδυασμό με τις εξελίξεις στο επίπεδο του υλικού του ηλεκτρονικού υπολογιστή καθιστούν αναγκαία και την εξέλιξη και την ανάπτυξη νέων μοντέλων ανάπτυξης λογισμικού. 2.2 Διαδικτυακές εφαρμογές, διαδικτυακές υπηρεσίες και Web API Με την εμφάνιση του διαδικτύου, μόλις λίγες δεκαετίες πριν, κατέστη δυνατή η διάθεση της πληροφορίας σε ένα ευρύ φάσμα ανθρώπων. Η πληροφορία αυτή, συνήθως, εμφανιζόταν σε απλούς ιστότοπους με αρχεία κειμένου διασυνδεδεμένα με υπερσυνδέσμους [6]. Έκτοτε, διανύθηκε μεγάλη απόσταση στην εξέλιξη αυτού του τομέα. Σήμερα, το διαδίκτυο αξιοποιείται για την λειτουργία μεγάλης κλίμακας εφαρμογών για τη διάδοση πληροφορίας, επικοινωνία, διασκέδαση και δεκάδες άλλες δραστηριότητες. Είναι προφανές, πως είναι εξαιρετικά δύσκολο να παρακολουθήσει κανείς τη συνεχή πρόοδο και τις νέες τεχνολογίες, που εμφανίζονται, στον συγκεκριμένο τομέα. Ωστόσο, είναι σημαντικό να προσδιοριστούν κάποια βασικά στοιχεία, που αφορούν το πρωτόκολλο επικοινωνίας HTTP του διαδικτύου, τις διαδικτυακές εφαρμογές, υπηρεσίες και web APIs καθώς και τις βασικές αρχιτεκτονικές λογισμικού για το διαδίκτυο Hypertext Transfer Protocol (HTTP) Βασικό πρωτόκολλο επικοινωνίας δεδομένων του διαδικτύου είναι το πρωτόκολλο μεταφοράς υπερκειμένου (HyperText Transfer Protocol, HTTP). Ρόλος του HTTP είναι ο ορισμός της μορφής και του τρόπου αποστολής ενός ερωτήματος από τον περιηγητή διαδικτύου προς τον διακομιστή και της απάντησης από την πλευρά του διακομιστή προς τον περιηγητή. Ως υπερκείμενο ορίζεται το κείμενο, που προβάλλεται σε ψηφιακή μορφή και περιέχει συνδέσμους μέσω των οποίων μπορούν να αποκτήσουν πρόσβαση σε άλλα κείμενα [7]. Τα ερωτήματα και οι αποκρίσεις με βάση το πρωτόκολλο HTTP αποτελούνται από τη μέθοδο του αιτήματος (request method), το ομοιόμορφο αναγνωριστικό πόρου (Uniform Resource Identifiers, URIs), την επικεφαλίδα (Request Header), το σώμα του μηνύματος και οι κωδικοί απόκρισης από την πλευρά του διακομιστή. Παρακάτω θα περιγραφούν τα συστατικά στοιχεία των ερωτημάτων/ αποκρίσεων (request/response) με βάση το πρωτόκολλο HTTP. 19

21 2.2.2 Universal Resource Identifier (URI) Το ομοιόμορφο αναγνωριστικό πόρου (URI) είναι μια ακολουθία χαρακτήρων, η οποία αναγνωρίζει ένα λογικό ή φυσικό πόρο. Το ομοιόμορφο αναγνωριστικό πόρου συνήθως περιγράφει το μηχανισμό, που θα χρησιμοποιηθεί για να αποκτηθεί πρόσβαση στον πόρο, ουσιαστικά αποτελεί μια διεύθυνση πάνω στην οποία θα υλοποιηθεί μια ενέργεια [8] HTTP Method Το πρωτόκολλο HTTP διαθέτει μια σειρά από μεθόδους, οι οποίες ορίζουν την επιθυμητή από τον πελάτη ενέργεια προς τον διακομιστή. Οι μέθοδοι δεν ορίζουν σαφή διαδικασία, αλλά περιγράφουν με ένα γενικό τρόπο τον σκοπό της κάθε μεθόδου. Οι μέθοδοι, οι οποίες αφορούν τη συγκεκριμένη διπλωματική εργασίας είναι οι εξής [9]: GET: Αυτή η μέθοδος ανακτά την πληροφορία από την τοποθεσία, που ορίζει το ομοιόμορφο αναγνωριστικό πόρου (URI), στη μορφή μιας οντότητας. POST: Η μέθοδος POST χρησιμοποιείται για να αιτηθεί την αποδοχή της οντότητας, που περικλείεται στο μήνυμα, ως παιδί του συγκεκριμένου πόρου που ορίζεται στο ομοιόμορφο αναγνωριστικό πόρου (URI). PUT: Η συγκεκριμένη μέθοδος ζητά την αποθήκευση της οντότητας, που περικλείεται στο μήνυμα, στην διεύθυνση, που ορίζεται από το ομοιόμορφο αναγνωριστικό πόρου (URI). DELETE: Η μέθοδος DELETE αιτείται τη διαγραφή του πόρου, που ορίζεται από το ομοιόμορφο αναγνωριστικό πόρου (URI) Request/ Response Header Ένας πελάτης χρησιμοποιεί την επικεφαλίδα του αιτήματος για να αποστείλει περισσότερες πληροφορίες σχετικά με το αίτημα, που υποβάλλει στον διακομιστή. Μπορούμε να παρομοιάσουμε την επικεφαλίδα αιτήματος με τις παραμέτρους κλήσης της μεθόδου ενός προγράμματος. Αντίστοιχα, η επικεφαλίδα απόκρισης επιτρέπει στον διακομιστή να μεταφέρει επιπρόσθετες πληροφορίες σχετικά με την απάντηση, που επιστρέφει έπειτα από το αίτημα που τέθηκε από πλευράς πελάτη Message Body Το σώμα μηνύματος περιέχει όλη τη χρήσιμη πληροφορία ενός αιτήματος ή μιας απόκρισης. Το σώμα μηνύματος μπορεί και να μην υπάρχει σε ένα αίτημα ή μια απόκριση. 20

22 Σχεδίαση και ανάπτυξη διαδικτυακής εφαρμογής πελάτη για διαδικτυακές υπηρεσίες τύπου REST Response Status Code Οι κωδικοί απόκρισης κατάστασης χρησιμοποιούνται για να ενημερώσουν τον πελάτη για το αποτέλεσμα του αιτήματός του. Σύμφωνα με το πρότυπο IEFT ο κωδικός απόκρισης κατάστασης αποτελείται από τρεις μονοψήφιους αριθμούς και ο πρώτος αριθμός υποδεικνύει την κλάση της απόκρισης [9], οι οποίες είναι οι εξής: 1xx: Πληροφοριακή, το αίτημα παραλήφθηκε. 2xx: Επιτυχής, το αίτημα παραλήφθηκε με επιτυχία και έγινε αποδεκτό. 3xx: Ανακατεύθυνση, χρειάζονται περαιτέρω διαδικασίες για να ολοκληρωθεί το αίτημα. 4xx: Λάθος πελάτη, το αίτημα περιέχει συντακτικά λάθη ή δεν μπορεί να ικανοποιηθεί. 5xx: Λάθος διακομιστή, ο διακομιστής δεν κατάφερε να ικανοποιήσει ένα ορθό συντακτικά αίτημα. Όσον αφορά στα υπόλοιπα ψηφία μπορούν να λάβουν οποιοδήποτε ακέραιο μονοψήφιο αριθμό και δεν είναι απαραίτητη, αν και επιθυμητή, η κατανόηση τους από πλευράς πελάτη Διαδικτυακές υπηρεσίες Η διαδικτυακή υπηρεσία είναι μια υπηρεσία, που προσφέρεται από μία ηλεκτρονική συσκευή σε μία άλλη, μέσω της μεταξύ τους επικοινωνίας διαμέσω του διαδικτύου. Πιο συγκεκριμένα και με βάση το World Web Wide Consortium η διαδικτυακή υπηρεσία ορίζεται ως ένα σύστημα λογισμικού σχεδιασμένο με στόχο την υποστήριξη διαλειτουργικής αλληλεπίδρασης μεταξύ μηχανών μέσω ενός δικτύου. Διαθέτει μια διεπαφή, που περιγράφεται σε μορφή αντιληπτή από μηχανές (συγκεκριμένα WSDL και WADL για REST εφαρμογές). Άλλα συστήματα αλληλεπιδρούν με τη διαδικτυακή υπηρεσία, με τρόπο προκαθορισμένο από την περιγραφή της διεπαφής, χρησιμοποιώντας SOAP μηνύματα, τα οποία τυπικά μεταδίδονται με τη χρήση του πρωτόκολλου HTTP και αποδοσμένα σε XML σε συνδυασμό με άλλα πρότυπα, σχετικά με το διαδίκτυο [10]. Πρακτικά, μια διαδικτυακή υπηρεσία παρέχει μια αντικειμενοστραφή διεπαφή, βασισμένη στο διαδίκτυο, σε ένα διακομιστή βάσης δεδομένων, ο οποίος χρησιμοποιείται από έναν άλλο διακομιστή διαδικτύου, ή από μία εφαρμογή κινητού, που παρέχει στον τελικό χρήστη μία διεπαφή χρήστη. Μία άλλη κοινή εφαρμογή για τον τελικό χρήστη είναι η mashup εφαρμογή, όπου ο διακομιστής διαδικτύου καταναλώνει διαφορετικές διαδικτυακές υπηρεσίες σε διαφορετικές μηχανές και συνδυάζει το περιεχόμενο σε μία διεπαφή χρήστη. Ωστόσο, οι συγκεκριμένες εφαρμογές ξεφεύγουν από το αντικείμενο αυτής της διπλωματικής εργασίες και γι αυτό δεν θα αναλυθούν περαιτέρω. 21

23 2.2.8 Διαδικτυακές διεπαφές προγραμματισμού εφαρμογών (Web APIs) Μια γενική διατύπωση του ρόλου των διαδικτυακών επαφών προγραμματισμού εφαρμογών από την πλευρά του διακομιστή είναι πως αποτελούν μια διεπαφή προγραμματισμού εφαρμογής, που αποτελείται από ένα ή περισσότερα εκτεθειμένα σημεία πρόσβασης (endpoints) σε ένα ορισμένο σύστημα μηνυμάτων αιτήματος-απόκρισης, το οποίο συνήθως εκφράζεται σε JSON ή XML, και το οποίο μεταδίδεται μέσω του διαδικτύου με βάση το HTTP πρωτόκολλο. Τα σημεία πρόσβασης αποτελούν βασικό μέρος της αλληλεπίδρασης με τις διαδικτυακές διεπαφές προγραμματισμού εφαρμογών από την πλευρά του διακομιστή, καθώς καθορίζουν την τοποθεσία των πόρων, που είναι προσπελάσιμοι από άλλα λογισμικά. Ως επί το πλείστον η πρόσβαση γίνεται μέσω ομοιόμορφου αναγνωριστικό πόρου (URI), στο οποίο τίθενται τα αιτήματα με βάση το HTTP πρωτόκολλο και από το οποίο αναμένεται η απόκριση. Βασικό προαπαιτούμενο για τη διασφάλιση της ορθής λειτουργίας του λογισμικού είναι τα σημεία πρόσβασης να είναι στατικά, διαφορετικά υπάρχει σοβαρός κίνδυνος στην περίπτωση που η τοποθεσία ενός πόρου αλλάξει (και άρα και το σημείο πρόσβασης) να μην είναι δυνατός ο εντοπισμός του από λογισμικό, το οποίο έχει γραφτεί πριν την αλλαγή της τοποθεσίας. Από τα παραπάνω φαίνεται να ταυτίζονται και να συγχέονται οι έννοιες της διαδικτυακής υπηρεσίας και της διαδικτυακής διεπαφής προγραμματισμού εφαρμογής. Η βασική διαφοροποίηση, που μπορεί να εντοπιστεί, έγκειται στην μορφή των μηνυμάτων, που χρησιμοποιούνται για την επικοινωνία μέσω του διαδικτύου. Οι διαδικτυακές υπηρεσίες βασίζονται στην χρήση SOAP μηνυμάτων, ενώ οι διαδικτυακές διεπαφές προγραμματισμού εφαρμογών χρησιμοποιούν την REST αρχιτεκτονική. Θα πρέπει να σημειωθεί ότι στα πλαίσια της συγκεκριμένης διπλωματικής εργασίας λαμβάνεται ως δεδομένο ότι και οι δύο εφαρμογές χρησιμοποιούν το HTTP πρωτόκολλο, διότι αποτελεί το πλέον διαδεδομένο πρωτόκολλο έναντι άλλων όπως το SMTP και MQSeries. Η έννοια και η μορφή των SOAP μηνυμάτων και της REST αρχιτεκτονικής θα περιγραφούν στην επόμενη ενότητα. 2.3 Πρωτόκολλο πρόσβασης απλού αντικειμένου (Simple Object Access Protocol, SOAP) Το πρωτόκολλο πρόσβασης απλού αντικειμένου είναι ένα πρωτόκολλο βασισμένο στην XML για την ανταλλαγή μηνυμάτων και στην αρχιτεκτονική των κλήσεων απομακρυσμένης διαδικασίας (Remote Procedure Calls, RPCs). Στον πυρήνα του, ένα SOAP μήνυμα έχει μία πολύ απλή δομή: ένα XML στοιχείο με δύο στοιχεία απογόνους, το ένα εκ των οποίων περιέχει την επικεφαλίδα και το άλλο το σώμα του μηνύματος. Συμπληρωματικά με τη δομή ενός βασικού μηνύματος, ο SOAP προσδιορισμός ορίζει και το 22

24 Σχεδίαση και ανάπτυξη διαδικτυακής εφαρμογής πελάτη για διαδικτυακές υπηρεσίες τύπου REST μοντέλο, που υποδεικνύει πως οι παραλήπτες θα πρέπει να επεξεργαστούν το SOAP μήνυμα [11]. Η τυπική δομή ενός SOAP μηνύματος φαίνεται στις Εικόνες 3 και 4. Εικόνα 3: Δομή ενός SOAP μηνύματος [12] Εικόνα 4: Παράδειγμα ενός SOAP αιτήματος και της απόκρισης του διακομιστή [11] 23

25 Η επί μακρόν χρήση της συγκεκριμένης αρχιτεκτονικής παρουσίασε συγκεκριμένες προβληματικές όσο αυξανόταν η πολυπλοκότητα των προς υλοποίηση εφαρμογών. Συγκεκριμένα οι προβληματικές εντοπίζονται στις εξής: Κατά τη χρήση τυπικών εφαρμογών και προεπιλεγμένη SOAP/HTTP διασύνδεση, το σύνολο των XML πληροφοριών σειριοποιείται σαν XML. Όταν χρησιμοποιείται το HTTP πρωτόκολλο οι ρόλοι των αλληλεπιδρώμενων μερών είναι συγκεκριμένοι. Μόνο το ένα μέρος (ο πελάτης) μπορεί να χρησιμοποιήσει τις υπηρεσίες του άλλου. Η «φλυαρία» του συγκεκριμένου πρωτόκολλου, σε συνδυασμό με την αργή ταχύτητα ανάλυσης και την έλλειψη τυποποιημένου μοντέλου αλληλεπίδρασης το καθιστά με την πάροδο του χρόνου ξεπερασμένο και νέες αρχιτεκτονικές παίρνουν τη θέση του. 2.4 Μεταφορά αναπαράστασης κατάστασης (REpresentational State Transfer, REST) και αρχιτεκτονική προσανατολισμένη προς τον πόρο (Resource-Oriented Architecture, ROA) Το REST αρχιτεκτονικό στυλ περιγράφηκε για πρώτη φορά από τον Roy T. Fielding το 2000 σε μια προσπάθεια γενίκευσης των βασικών αρχών αρχιτεκτονικής του διαδικτύου και παρουσίασης τους ως ένα συγκεκριμένο πλαίσιο περιορισμών. Μέσα από αυτό το πλαίσιο ο Fielding περιέγραψε πως είναι κατασκευασμένα και λειτουργούν τα διανεμημένα πληροφοριακά συστήματα, όπως το διαδίκτυο, πως αλληλεπιδρούν μεταξύ τους οι πόροι και τον ρόλο των διακριτών αναγνωριστικών σε τέτοια συστήματα. Επίσης, τόνισε τη σημασία της χρήσης περιορισμένων συνόλων λειτουργιών με ενιαία σημασιολογία για την κατασκευή μιας καθολικής υποδομής, που θα μπορεί να υποστηρίξει οποιαδήποτε εφαρμογή. Ο Fielding αναφερόταν σε αυτό το αρχιτεκτονικό στυλ ως μεταφορά αναπαράστασης κατάστασης (Representational State Transfer) [13]. Συνοπτικά, το REST αρχιτεκτονικό στυλ περιγράφει το διαδίκτυο ως μία διανεμημένη εφαρμογή υπερμέσων, της οποίας οι διασυνδεδεμένοι πόροι επικοινωνούν ανταλλάσσοντας αναπαραστάσεις της κατάστασης των πόρων. Οι αρχές αυτού του αρχιτεκτονικού στυλ συμπεριλαμβάνουν πως διευθυνσιοδοτούνται και μεταφέρονται οι καταστάσεις των πόρων μέσω του HTTP πρωτόκολλου από ένα μεγάλο εύρος πελατών, που είναι γραμμένοι σε διαφορετικές γλώσσες. 24

26 Σχεδίαση και ανάπτυξη διαδικτυακής εφαρμογής πελάτη για διαδικτυακές υπηρεσίες τύπου REST Εικόνα 5: Δομή των μηνυμάτων αιτήματος και απόκρισης τύπου REST Σύνδεσμοι υπερμέσων (Hypermedia Links) Τα υπερμέσα αποτελούν μια προέκταση της έννοιας του υπερκειμένου, όπως αυτό περιγράφηκε σε προηγούμενη ενότητα, μόνο που σε αυτήν την περίπτωση η πληροφορία μπορεί να έχει οποιαδήποτε μορφή (εικόνα, βίντεο, ήχος, απλό κείμενο) και μια αναπαράσταση πόρου μπορεί πολλές φορές να έχει τη μορφή ενός υπερμέσου, το οποίο περιέχει ένα σύνδεσμο για να κατευθυνθεί σε άλλο πόρο Πόρος (Resource) Ακρογωνιαίος λίθος του REST αρχιτεκτονικού στυλ είναι ο πόρος. Πόρος μπορεί να είναι ένα οποιοδήποτε αντικείμενο με συγκεκριμένο τύπο, σχετικά δεδομένα, συσχετίσεις με άλλους πόρους και ένα σύνολο μεθόδων, που εφαρμόζονται σε αυτόν. Θα μπορούσε να τον παρομοιάσει κανείς με το στιγμιότυπο ενός αντικειμένου σε μια αντικειμενοστραφή γλώσσα προγραμματισμού, με βασική διαφορά ότι για τον πόρο ορίζονται μόνο μερικές πρότυπες μέθοδοι, σε αντίθεση με το στιγμιότυπο του αντικειμένου που μπορεί να έχει πολλές περισσότερες μεθόδους Ομοιόμορφα αναγνωριστικά πόρων (Uniform Resource Identifiers, URIs) Κάθε πόρος προσδιορίζεται από ένα ή περισσότερα ομοιόμορφα αναγνωριστικά πόρων (URIs). Για να αποκτήσει πρόσβαση μια εφαρμογή σε ένα πόρο καλεί μια HTTP μέθοδο σε ένα από τα ομοιόμορφα αναγνωριστικά του πόρου. Θα πρέπει να σημειωθεί πως αν κάποια πληροφορία δεν προσδιορίζεται από 25

27 ένα ομοιόμορφο αναγνωριστικό πόρου, τότε δεν είναι πόρος και δεν υπάρχει δυνατότητα πρόσβασης σε αυτή την πληροφορία μέσω του διαδικτύου Αναπαράσταση του πόρου (Resource Representation) Ο πόρος είναι μία αφαιρετική έννοια στην οποία ανατίθεται ένα ή περισσότερα URIs κι έπειτα μπορεί να χρησιμοποιηθεί από το διαδίκτυο. Η πρόσβαση όμως σε αυτό το URI δεν θα αποδώσει ποτέ τον ίδιο τον πόρο, παρά μόνο μια αναπαράσταση αυτού [14]. Ουσιαστικά, η αναπαράσταση του πόρου αντανακλά την τρέχουσα κατάσταση ενός πόρου, και των χαρακτηριστικών του, την στιγμή που ο πελάτης το ζητήσει. Με αυτή την έννοια οι αναπαραστάσεις των πόρων είναι απλά στιγμιότυπα στο χρόνο. Επιπρόσθετα, οι πόροι μπορούν να έχουν διάφορες αναπαραστάσεις, μεταξύ των οποίων οι πιο διαδεδομένες στο διαδίκτυο είναι η XML και JSON, χωρίς αυτό να σημαίνει πως η κωδικοποίηση των αναπαραστάσεων περιορίζεται μόνο σε αυτές τις δύο. Η κωδικοποίηση των αναπαραστάσεων επιλέγεται πάντοτε με κριτήριο την χρήση για την οποία προορίζονται οι αναπαραστάσεις, γι αυτό θα μπορούσαν κάλλιστα να είναι κι ένα ελεύθερο κείμενο ή οποιαδήποτε άλλης κωδικοποίηση. Εικόνα 6: Παράδειγμα ενός αιτήματος και της αντίστοιχης απόκρισης τύπου REST [15] Χαρακτηριστικά της προσανατολισμένης στον πόρο αρχιτεκτονικής Για να χαρακτηριστεί μια εφαρμογή ως RESTful, χρειάζεται να πληροί τις εξής προϋποθέσεις [16]: Stateless: Η επικοινωνία πελάτη-διακομιστή περιορίζεται από την απαίτηση να μην αποθηκεύεται κανένα πλαίσιο του πελάτη στον διακομιστή ανάμεσα στα αιτήματα. Κάθε αίτημα από οποιονδήποτε πελάτη περιέχει όλη την απαραίτητη πληροφορία για να εξυπηρετηθεί το αίτημα και η κατάσταση της συνεδρίας κρατείται στον πελάτη. Η κατάσταση της συνεδρίας 26

28 Σχεδίαση και ανάπτυξη διαδικτυακής εφαρμογής πελάτη για διαδικτυακές υπηρεσίες τύπου REST μπορεί να μεταφερθεί από τον διακομιστή σε κάποια άλλη υπηρεσία, όπως μια βάση δεδομένων για τη διατήρηση μιας συγκεκριμένης κατάστασης για μια περίοδο και να επιτραπεί η πιστοποίηση. Ο πελάτης ξεκινά στέλνοντας αιτήματα όταν είναι έτοιμος να μεταβεί στη νέα κατάσταση. Όσο ένα ή περισσότερα αιτήματα εκκρεμούν, ο πελάτης θεωρείται πως βρίσκεται σε μεταβατική κατάσταση. Η αναπαράσταση κάθε κατάστασης εφαρμογής περιέχει συνδέσμους, οι οποίοι μπορούν να χρησιμοποιηθούν την επόμενη φορά, που ο πελάτης επιλέξει να ξεκινήσει μια νέα κατάσταση-μετάβαση. Κάθε αίτημα πρέπει να είναι ανεξάρτητο από όλα τα άλλα. Διευθυνσιοδότηση (Addressability): Βασική απαίτηση για κάθε RESTful διαδικτυακή εφαρμογή είναι ο ορισμός ενός ή περισσότερων URI για κάθε πόρο. Το κάθε URI, που αντιστοιχίζεται σε κάθε πόρο, πρέπει είναι μοναδικό. Ενιαία διεπαφή (Uniform Interface): Η ενιαία διεπαφή αξιοποιεί για την επικοινωνία πελάτηδιακομιστή το πρωτόκολλο HTTP, υιοθετώντας έτσι ενιαίες μεθόδους. Οι μέθοδοι αυτές είναι τα CRUD verbs του ΗΤΤP πρωτόκολλου (Create, Read, Update, Delete). Συνεκτικότητα (Connectedness): Η συνεκτικότητα βασίζεται σε μεγάλο βαθμό στην διευθυνσιοδότηση. Η διαχείριση κάθε πόρου γίνεται μέσα από την πρόσβαση σε αναπαραστάσεις του μέσω URI. Ο διακομιστής μπορεί να καθοδηγήσει την μεταφορά των καταστάσεων της εφαρμογής μέσω συνδέσμων, που δίνονται στις αναπαραστάσεις. Αυτό σημαίνει, πως κάθε αναπαράσταση πόρου θα πρέπει να περιέχει όλους τους απαραίτητους συνδέσμους προς τους σχετικούς με αυτόν πόρους, ώστε να διασφαλίζεται η ομαλή πλοήγηση των πελατών μέσα στην εφαρμογή ακολουθώντας απλά τους συνδέσμους. Όπως φαίνεται από τα παραπάνω, η RESΤ προσέγγιση περιστρέφεται γύρω από την έννοια των πόρων και στοχεύει στην μοντελοποίηση όλων των αλληλεπιδράσεων πελάτη/διακομιστή ως ανταλλαγή αναπαραστάσεων πόρων. Η σχετικά νέα αυτή προσέγγιση κερδίζει ολοένα και περισσότερο έδαφος σε σχέση με το SOAP πρωτόκολλο, καθώς είναι πολύ πιο γρήγορη και απλή. Ενδεικτικά παρατίθενται τα συγκριτικά αποτελέσματα επίδοσης των SOAP και REST υπηρεσιών σε κινητά και διεπαφών σε πολυμεσικές διασκέψεις στους Πίνακες 1 και 2 [17]. 27

29 Πίνακας 1: Αποτελέσματα επίδοσης διαδικτυακών υπηρεσιών τύπου SOAP και REST σε κινητό [17] Message Size (byte) Time (Milliseconds) Number of array elements SOAP/HTTP REST (HTTP) SOAP/HTTP REST (HTTP) String Concatenation Float Numbers Addition String Concatenation Float Numbers Addition String Concatenation Float Numbers Addition String Concatenation Float Numbers Addition Πίνακας 2: Αποτελέσματα επίδοσης διαδικτυακών διεπαφών τύπου SOAP και REST σε πολυμεσικές τηλεδιασκέψεις [17] SOAP-based REST-based Multimedia Conferencing API Delay in a distributed environment (ms) Delay on the same machine (ms) Network load (bytes) Delay in a distributed environment (ms) Delay on the same machine (ms) Network load (bytes) Create conference Get conference information Add participant Remove participant Get participants Get participant information End conference

30 Σχεδίαση και ανάπτυξη διαδικτυακής εφαρμογής πελάτη για διαδικτυακές υπηρεσίες τύπου REST Τέλος, στην Εικόνα 7 παρουσιάζεται το μερίδιο [18], που μοιράζονται τα διαδικτυακά APIs, ανά τεχνολογία τον Μάιο του 2014 με βάση τα στοιχεία, που αντλήθηκαν από τον ιστότοπο Εικόνα 7: Οι χρησιμοποιούμενες τεχνολογίες για την ανάπτυξη διαδικτυακών APIs [19] 2.5 Η αυξανόμενη ζήτηση για web APIs Αν και είναι δύσκολο να υπολογιστούν τα υπάρχοντα διαδικτυακά APIs, διότι πολλά από αυτά είναι ιδιωτικά και κατ επέκταση δεν υπάρχει πρόσβαση σε αυτά για να μπορούν να καταμετρηθούν, μία από τις πιο γνωστές ιστοσελίδες-ευρετήρια APIs το έχει φτάσει να φιλοξενεί πάνω από APIs στο διάστημα [20] (Εικόνα 8). Εικόνα 8: Εκτιμήσεις και πραγματικός αριθμός διαδικτυακών APIs για το ευρετήριο programmable web [19] 29

31 Παράλληλα, άλλες καινούριες ιστοσελίδες- ευρετήρια υπολογίζεται πως φιλοξενούν πάνω από APIs. Από τους αριθμούς αυτούς διαφαίνεται μια σαφής στροφή προς τις διαδικτυακές εφαρμογές και ευρύτερα λογισμικών, που αξιοποιούν το διαδίκτυο. Η ολοένα και αυξανόμενη αυτή διάδοση και ζήτηση των διαδικτυακών APIs και πολύ περισσότερο των REST APIs καθιστά αναγκαία την εύρεση νέων εργαλείων ανάπτυξης υπηρεσιών, που να βασίζονται στο REST αρχιτεκτονικό στυλ. Ωστόσο, είναι πολύ λίγες οι προσπάθειες για την ανάπτυξη εργαλείων αυτοματοποιημένης παραγωγής διαδικτυακών εφαρμογών πελάτη. Επιπροσθέτως, αν λάβει κανείς υπόψη του το διάγραμμα της Εικόνας 9, όπου όπως φαίνεται η αύξηση των εφαρμογών είναι εκθετική σε σχέση με τη γραμμική αύξηση του αριθμού των προγραμματιστών, η εύρεση νέων μεθοδολογιών και εργαλείων ανάπτυξης λογισμικού, αλλά και ειδικά APIs και συμπληρωματικά διαδικτυακών εφαρμογών πελάτη είναι απαραίτητη για μπορέσει να αντιμετωπιστεί αυτή η τεράστια αύξηση σε ζήτηση εφαρμογών. Εικόνα 9: Συγκριτική αύξηση του πλήθους εφαρμογών σε σχέση με το πλήθος προγραμματιστών [21] 2.6 Τεχνολογία λογισμικού οδηγούμενη από μοντέλα (Model Driven Engineering) Μέσα στις τελευταίες πέντε δεκαετίες, οι ερευνητές λογισμικού και οι προγραμματιστές δημιουργούν γενικεύσεις, οι οποίες τους βοηθούν να αναπτύξουν προγράμματα με βάση τους σχεδιαστικούς τους στόχους και όχι με βάση το υποκείμενο υπολογιστικό περιβάλλον (CPU, μνήμα κ.α.), αποκρύπτοντας τους έτσι από τις πολυσύνθετες λεπτομέρειες αυτών των συστημάτων. Πρωτόλυες προσπάθειες γενίκευσης ήταν οι πρώτες γλώσσες προγραμματισμού (Assembly, FORTRAN) και τα πρώτα λειτουργικά συστήματα υπολογιστών (OS/360, Unix), όπου προστάτευε του προγραμματιστές από τον προγραμματισμό σε 30

32 Σχεδίαση και ανάπτυξη διαδικτυακής εφαρμογής πελάτη για διαδικτυακές υπηρεσίες τύπου REST κώδικα μηχανής ή και απευθείας πάνω στο υλικό. Παρόλο όμως που αυτές οι προσπάθειες ανέβασαν το επίπεδο της αφαίρεσης, συνέχιζαν να έχουν μία οπτική προσανατολισμένη στην υπολογιστική διαδικασία. Πιο συγκεκριμένα, οι αφαιρέσεις λειτουργούσαν στη σφαίρα της επίλυσης, δηλαδή στον τομέα της τεχνολογίας υπολογιστών, παρά στη σφαίρα του προβλήματος, πράγμα που θα σήμαινε σχεδίαση με βάση τους τομείς εφαρμογής, π.χ. τηλεπικοινωνίες, αερομηχανική, βιολογία κ.α.. Οι παρούσες τεχνολογίες, παρόλο που κατάφεραν να ξεφύγουν από τους περισσότερους περιορισμούς του παρελθόντος, υπάρχουν ακόμη σημαντικά προβλήματα, τα οποία δυσχεραίνουν την αποτελεσματική ανάπτυξη λογισμικού, που να ανταποκρίνεται στις απαιτήσεις των τεχνολογιών επόμενης γενιάς, όπως διαδικτυακές υπηρεσίες και αρχιτεκτονικές «γραμμής παραγωγής». Ωστόσο, υπάρχει μία πολλά υποσχόμενη προσέγγιση για τη διευθέτηση της πολυπλοκότητας των πλατφορμώνκαι την αδυναμία των γλωσσών προγραμματισμού τρίτης γενιάς να απλοποιήσουν αυτή την πολυπλοκότητα. Αυτή είναι η τεχνολογία λογισμικού οδηγούμενη από μοντέλα, και το πιο σημαντικό παράδειγμά της η αρχιτεκτονική οδηγούμενη από μοντέλα (Model Driven Architecture, MDA), και συνδυάζει τα εξής χαρακτηριστικά [22]: Γλώσσες μοντελοποίησης συγκεκριμένων τομέων (Domain-Specific Modeling Languages, DSMLs), των οποίων τα συστήματα τύπου ορίζουν τη δομή της εφαρμογής, τη συμπεριφορά και τις λειτουργικές απαιτήσεις για συγκεκριμένους τομείς εφαρμογής, όπως διαδικτυακές χρηματιστηριακές υπηρεσίες ή διαχείριση μιας αποθήκης. Αυτές οι γλώσσες περιγράφουν μεταμοντέλα, τα οποία ορίζουν και περιγράφουν τις σχέσεις μεταξύ εννοιών του τομέα εφαρμογής και προσδιορίζουν επακριβώς την κομβική σημασιολογία και τους σχετικούς περιορισμούς. Μηχανές μετασχηματισμού και γεννήτριες, οι οποίες αναλύουν συγκεκριμένες πλευρές αυτών των μοντέλων και στη συνέχεια συνθέτουν διαφόρων τύπων αντικείμενα, όπως πηγαίο κώδικα, εισόδους προσομοίωσης ή διαφορετικές αναπαραστάσεις μοντέλου. Η ικανότητα να συντίθεται αντικείμενα από τα μοντέλα βοηθά στη διασφάλιση της συνεκτικότητας μεταξύ της υλοποίησης της εφαρμογής και της ανάλυσης της πληροφορίας, που σχετίζεται με τις λειτουργικές απαιτήσεις και απαιτήσεις ποιότητας υπηρεσίας (περιγεγραμμένων από μοντέλα). Οι διαδικασίες μετασχηματισμού χωρίζονται σε δύο βασικές κατηγορίες τον μετασχηματισμό μοντέλου σε μοντέλο(model To Model Transformation) και το μετασχηματισμό μοντέλου σε κώδικα(model To Text Transformation). Οι μετασχηματισμοί αυτοί υλοποιούνται σύμφωνα με κανόνες μετασχηματισμού, οι οποίοι συντάσσονται με διαφορετικό τρόπο για την κάθε 31

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

34 Σχεδίαση και ανάπτυξη διαδικτυακής εφαρμογής πελάτη για διαδικτυακές υπηρεσίες τύπου REST και μειώνει το ρίσκο αποτυχίας, εφόσον όλα τα αρχιτεκτονικά ή τεχνικά προβλήματα έχουν ήδη αντιμετωπιστεί. Βελτιωμένη επικοινωνία στη διαδικασία της σχεδίασης: Τα μοντέλα βοηθούν στην κατανόηση των ζητούμενων συστημάτων στο επίπεδο της σχεδίασης και διευκολύνουν τη συζήτηση και την επικοινωνία γύρω από το ζητούμενο σύστημα, επειδή τα μοντέλα είναι μέρος του ορισμού του συστήματος και όχι της τεκμηρίωσης είναι πάντα αξιόπιστα και ενημερωμένα. Δυνατότητα καθυστέρησης των τεχνικών αποφάσεων: Τα αρχικά στάδια ανάπτυξης μιας εφαρμογής επικεντρώνονται στα λογικά προβλήματα. Η δυνατότητα καθυστέρησης της επιλογής συγκεκριμένων τεχνολογιών ή πλατφορμών μέχρι να συλλεχθούν οι απαραίτητες πληροφορίες είναι βασική, ειδικά, σε τομείς με πολύ μεγάλο κύκλο ανάπτυξης λογισμικού, όπου θα μπορούσαν οι επιλεγμένες τεχνολογίες να καταστούν ξεπερασμένες μέχρι το τέλος του κύκλου [1]. Από την άλλη πλευρά έχει αναπτυχθεί και πολύ μεγάλη κριτική απέναντι στην τεχνολογία λογισμικού οδηγούμενη από μοντέλα. Το πιο βασικό στοιχείο αυτής της κριτικής περιστρέφεται γύρω από τη δυσκολία εύρεσης ισορροπίας ανάμεσα στην απλοποίηση, μέσω της αύξησης του επιπέδου αφαίρεσης, και στην υπεραπλούστευση, όπου χάνονται οι λεπτομέρειες για οποιοδήποτε χρήσιμο μετασχηματισμό. Μία ακόμη προβληματική είναι η ανεπάρκεια ή και η έλλειψη εργαλείων, που να υλοποιούν τη συγκεκριμένη τεχνολογία, η περιορισμένη διάδοση της MDE τεχνολογίας καθώς και η δυσκολία εκμάθησής της σε σύγκριση με τα προσκομιζόμενα οφέλη [1]. Στον Πίνακα 3 παρουσιάζονται οι επιδράσεις της MDE τεχνολογίας λογισμικού στη διαδιακασία παραγωγής λογισμικού και οι διαφορετικές απόψεις σχετικά με τα αποτελέσματα, που επιφέρει [23]. 33

35 Πίνακας 3: Επιδράσεις της χρήσης της MDE τεχνολογίας λογισμικού Παράγοντας επίδρασης Θετικές επιδράσεις Αρνητικές επιδράσεις Χρόνος συγγραφής κώδικα Αυτοματοποιημένη παραγωγή κώδικα. Ο χρόνος που απαιτείται για την ανάπτυξη κατάλληλων μοντέλων και μετασχηματισμών. Παραγωγικότητα Χρόνος δοκιμής κώδικα Απόδοση επένδυσης Λιγότερα σφάλματα στον παραγόμενο κώδικα. Μέθοδοι δοκιμώνμε βάση μοντέλα. Πιο δημιουργικές λύσεις. Οι προγραμματιστές ασχολούνται με την ουσία του προβλήματος. Η προσπάθεια που απαιτείται για την δοκιμή των μετασχηματισμών και της ακεραιότητας των μοντέλων. Το φαινόμενο «model paralysis». Φορητότητα Χρόνος μεταφοράς σε νέα πλατφόρμα Απλή εφαρμογή διαφορετικών μετασχηματισμών. Η προσπάθεια που απαιτείται για την ανάπτυξη νέων μετασχηματισμών. Συντήρηση Χρόνος κατανόησης Χρόνος συντήρησης Ευκολία κατανόησης από καινούριο προσώπικο. Ο κώδικας «αυτοτεκμηριώνεται». Η συντήρηση πραγματοποιείται στο στάδιο της μοντελοποίησης. Ο παραγόμενος κώδικας ενδέχεται να είναι δυσνόητος. Η απαίτηση συγχρονισμού μεταξύ των μοντέλων και του κώδικα. Από τα παραπάνω είναι σαφές ότι δε μπορεί να εξαχθεί εύκολα κάποιο οριστικό συμπέρασμα γύρω από την επίδραση της MDE τεχνολογίας. Παρ όλα αυτά, υπάρχουν έρευνες, που έχουν πραγματοποιηθεί σε πραγματικές εφαρμογές, που υλοποιήθηκαν με βάση την MDE τεχνολογία και από τα αποτελέσματά τους μπορούν να εξαχθούν κάποια ενδεικτικά συμπεράσματα, που επιβεβαιώνουν τις παραπάνω θετικές επιδράσεις, χωρίς όμως να είναι καταληκτικά. Τα αποτελέσματα αυτά παρατίθενται στα διαγράμματα των Εικόνων 10 και 11 [24]. 34

36 Σχεδίαση και ανάπτυξη διαδικτυακής εφαρμογής πελάτη για διαδικτυακές υπηρεσίες τύπου REST Εικόνα 10: Θετικές και αρνητικές επιδράσεις της τεχνολογίας MDE Εικόνα 11: Αδυναμίες της MDE τεχνολογίας 35

37 2.7 Αρχιτεκτονική οδηγούμενη από μοντέλα (Model Driven Architecture, MDA) Μία από τις πιο διαδεδομένες μορφές της τεχνολογίας λογισμικού οδηγούμενης από μοντέλα είναι η αρχιτεκτονική οδηγούμενη από μοντέλα. Η αρχιτεκτονική οδηγούμενη από μοντέλα είναι η Model Driven προσέγγιση, που προτείνεται από το Object Management Group, είναι διαθέσιμη από τις αρχές του 2000 και εστιάζει κυρίως στον ορισμό μοντέλων και των μετασχηματισμών τους. Η συγκεκριμένη αρχιτεκτονική υποστηρίζει τον ορισμό μοντέλων σε διάφορα επίπεδα αφαίρεσης, ήτοι τα Υπολογιστικά Ανεξάρτητα μοντέλα (Computational Independent Models, CIM), τα Ανεξάρτητα Πλατφόρμας μοντέλα (Platform Independent Models, PIM) και τα Εξειδικευμένα σε Πλατφόρμα μοντέλα (Platform Specific Models, PSM). Οι υπολογιστικές πλατφόρμες αντιστοιχούν σε συμπαγείς υλοποιήσεις εφαρμογών διακομιστών, βάσεων δεδομένων διακομιστών, frameworks και αρχιτεκτονικών λογισμικού. Αυτές οι πλατφόρμες μπορούν να περιγραφούν μέσα από Περιγραφικά Μοντέλα Πλατφορμών (Platform Description Models, PDM). Επίσης, η αρχιτεκτονική οδηγούμενη από μοντέλα εξετάζει διαφορετικούς τύπους μετασχηματισμών μοντέλου-σε-μοντέλο, οι οποίοι είναι CIM-CIM,CIM-PIM,PIM-PIM,PIM-PSM και PSM-PSM. Συμπληρωματικά, μελετά τον μετασχηματισμό του Εξειδικευμένου σε Πλατφόρμα μοντέλου σε πηγαίο κώδικα ή και σε διαφορετικού τύπου κειμένου αντικείμενα. Θεωρητικά, μία εφαρμογή, που αναπτύσσεται με βάση την αρχιτεκτονική οδηγούμενη από μοντέλα, είναι ανεξάρτητη πλατφόρμας. Το χαρακτηριστικό αυτό της επιτρέπει να εγκαθίσταται σε διαφορετικές υπολογιστικές πλατφόρμες και υποστηρίζει κατάλληλα διαφορετικές τεχνολογίες χάρη στην ύπαρξη αυτών των μετασχηματισμών, ιδιαίτερα των PIM-PSM, PSM-PSM και PSM-Text μετασχηματισμών [25]. Βασικοί προσδιορισμοί της αρχιτεκτονικής οδηγούμενης από μοντέλα, σύμφωνα με το Object Management Group, είναι η χρήση του Meta-Object Facility (MOF) ως πυρήνα της αρχιτεκτονικής μεταμοντέλων και η χρήση των UML Profiles, ως ενός απλού αλλά πρακτικού τρόπου να οριστούν γραφικά οι γλώσσες μοντελοποίησης συγκεκριμένων τομέων. Στη συνέχεια, θα παρουσιαστούν ορισμένες βασικές έννοιες της αρχιτεκτονικής οδηγούμενης από μοντέλα και οι διαδικασίες μετασχηματισμού ενός μοντέλου Μοντέλα, μεταμοντέλα και μετα-μεταμοντέλα Το μοντέλο είναι μία μορφή αφαίρεσης του υπό εξέταση συστήματος, το οποίο μπορεί να υπάρχει ήδη ή θα υπάρξει στο μέλλον. Ως σύστημα στην τεχνολογία λογισμικού οδηγούμενη από μοντέλα νοείται η γενική ιδέα για τη σχεδίαση μιας εφαρμογής, πλατφόρμας λογισμικού ή οποιουδήποτε αντικειμένου λογισμικού. Το μοντέλο, επομένως, μπορεί να οριστεί ως ένα σύστημα, το οποίο βοηθάει στον ορισμό 36

38 Σχεδίαση και ανάπτυξη διαδικτυακής εφαρμογής πελάτη για διαδικτυακές υπηρεσίες τύπου REST του υπό εξέταση συστήματος και την απάντηση ερωτήσεων γύρω από αυτό χωρίς να είναι απαραίτητη η απευθείας μελέτη του [25]. Το μεταμοντέλο, με τη σειρά του, είναι ένα μοντέλο των μοντέλων, δηλαδή είναι ένα μοντέλο που ορίζει τη δομή μιας γλώσσας μοντελοποίησης. Ουσιαστικά, περιγράφει όλους τους περιορισμούς και τις προδιαγραφές που θα πρέπει να πληρούν τα μοντέλα, που χρησιμοποιούν το συγκεκριμένο μεταμοντέλο για να περιγραφούν. Το μετα-μεταμοντέλο ορίζει τη γλώσσα με την οποία περιγράφονται τα μεταμοντέλα. Ένα μεταμεταμοντέλο περιγράφει με τη σειρά του όλους τους περιορισμούς και τις προδιαγραφές που θα πρέπει να πληρούν τα μεταμοντέλα, με τη μόνη διαφοροποίηση ότι το μετα-μεταμοντέλο περιγράφει και τον εαυτό του. Μία πλατφόρμα είναι το σύνολο των υποσυστημάτων και τεχνολογιών, το οποίο παρέχει συνεκτική λειτουργικότητα μέσα από διεπαφές και χρήση προτύπων. Οι πελάτες της πλατφόρμας κάνουν χρήση της χωρίς την ανάγκη γνώσης των λεπτομερειών της. Η ανεξαρτησία πλατφόρμας αποτελεί ένα ποιοτικό όρο, τον οποίο μπορεί να παρουσιάζει ένα μοντέλο όταν εκφράζεται ανεξάρτητα από τα χαρακτηριστικά κάποιας πλατφόρμας. Ανεξαρτησία είναι ένας σχετικός δείκτης μέτρησης του βαθμού αφαίρεσης. Ένα μοντέλο πλατφόρμας περιγράφει ένα σύνολο τεχνικών σχεδίων που αντιπροσωπεύουν τα συστατικά του στοιχεία και τις υπηρεσίες που παρέχει. Επίσης, εξειδικεύει τους περιορισμούς χρήσης αυτών των στοιχείων και υπηρεσιών από άλλα μέρη του συστήματος. Στην αρχή αυτής της ενότητας αναφέρθηκε πως η αρχιτεκτονική οδηγούμενη από μοντέλα υποστηρίζει και διάφορα επίπεδα αφαίρεσης, που εκφράζονται και από διαφορετικούς τύπους μοντέλων. Αυτά τα μοντέλα θα μπορούσαν να περιγραφούν καλύτερα ως στρώματα αφαίρεσης, επειδή ένα σύνολο μοντέλων μπορεί να κατασκευαστεί μέσα σε οποιοδήποτε από αυτά τα τρία στρώματα, όπως φαίνονται και στην Εικόνα 12. Μοντέλο ανεξάρτητο υπολογισμού (Computation Independent Model, CIM) είναι ένα μοντέλο του συστήματος που χρησιμοποίει λεξιλόγιο πολύ κοντινό με αυτό του τομέα, για το οποίο σχεδιάζεται το σύστημα. Παρουσιάζει με ακρίβεια τι θα πρέπει να κάνει το σύστημα, αλλά υποκρύπτει όλες τις πληροφορίες σχετικά με τις τεχνολογίες, που θα χρησιμοποιηθούν για την υλοποίησή του. Το CIM μοντέλο παίζει σημαντικό ρόλο στην επικοινωνία μεταξύ των ειδικών του τομέα και του σχεδιαστή. 37

39 Το μοντέλο ανεξάρτητο πλατφόρμας (Platform Independent Model, PIM) θα πρέπει να έχει έναν επαρκή βαθμό ανεξαρτησίας για να επιτρέπει τη χαρτογράφησή του σε μία ή περισσότερες πλατφόρμες. Αυτό επιτυγχάνεται συνήθως ορίζοντας ένα σύνολο υπηρεσιών με τρόπο τέτοιο, που να παραλείπονται οι τεχνικές λεπτομέρειες. Το μοντέλο εξειδικευμένης πλατφόρμας (Platform Specific Model, PSM) συνδυάζει τις προδιαγραφές του PIM μοντέλου με τις απαιτούμενες λεπτομέρειες για τον ορισμό του τρόπου με τον οποίο το σύστημα θα χρησιμοποιήσει ένα συγκεκριμένο τύπο πλατφόρμας. Αν το μοντέλο εξειδικευμένης πλατφόρμας δεν περιλαμβάνει όλες τις λεπτομέρειες, που είναι απαραίτητες για την υλοποίηση αυτής της πλατφόρμας, τότε το μοντέλο αυτό θεωρείται αφηρημένο. Εικόνα 12: Σχέσεις ανάμεσα στα MDA μοντέλα Meta-Object Facility (MOF) Ασύμβατα μεταδεδομένα ανάμεσα σε διαφορετικά συστήματα είναι ένας βασικός περιορισμός στην ανταλλαγή δεδομένων και την ενσωμάτωση εφαρμογών. Ως μεταδεδομένα ορίζονται τα δεδομένα, που χρησιμοποιούνται από εργαλεία, βάσεις δεδομένων κτλ., για να περιγράψουν τη δομή και το νόημα των δεδομένων. Το Meta-Object Facility είναι ένα πρότυπο, που δημιουργήθηκε από το Object Management Group, και παρέχει ένα ανοιχτό και ανεξάρτητο πλατφόρμας πλαίσιο για τη διαχείριση μεταδεδομένων 38

40 Σχεδίαση και ανάπτυξη διαδικτυακής εφαρμογής πελάτη για διαδικτυακές υπηρεσίες τύπου REST και ένα σύνολο συναφών υπηρεσιών μεταδεδομένων, που καθιστά δυνατή την ανάπτυξη και διαλειτουργικότητα συστημάτων οδηγούμενων από μοντέλα [26]. Το MOF πρότυπο είναι σχεδιασμένο ως μία δομή τεσσάρων επιπέδων. Παρέχει ένα μετα-μεταμοντέλο στο πρώτο επίπεδο, το οποίο λέγεται Μ3 επίπεδο. Αυτό το Μ3-μοντέλο είναι η γλώσσα, που χρησιμοποιείται από το MOF πρότυπο για την κατασκευή μετα-μοντέλων, που ονομάζονται Μ2-μοντέλα. Το πιο διαδεδομένο παράδειγμα ενός δεύτερου επιπέδου με βάση το MOF πρότυπο είναι το UML μεταμοντέλο (Unified Modeling Language). Τα Μ2 μοντέλα περιγράφουν στοιχεία του Μ1 επιπέδου, κι άρα Μ1-μοντέλα. Τέτοια είναι για παράδειγμα μοντέλα γραμμένα στη UML. Το τελευταίο επίπεδο είναι το Μ0 επίπεδο ή διαφορετικά το επίπεδο δεδομένων. Αυτό το επίπεδο χρησιμοποιείται για να περιγράψει πραγματικά αντικείμενα. Η δομή του MOF προτύπου φαίνεται στην Εικόνα 13. Εικόνα 13: Η δομή του MOF πρότυπου [27] Μετασχηματισμός μοντέλου Μετασχηματισμός μοντέλου: Ο μετασχηματισμός μοντέλου είναι η διαδικασία μετατροπής ενός μοντέλου σε ένα άλλο μέσα στο ίδιο σύστημα. 39

41 Για την παραγωγή ενός αντικείμενου λογισμικού με χρήση της MDA αρχιτεκτονικής είναι απαραίτητο να ακολουθηθεί η διαδικασία όπως εμφανίζεται στην Εικόνα 14. Θα πρέπει, δηλαδή, να εφαρμοστούν μια σειρά από μετασχηματισμούς ξεκινώντας από το CIM μοντέλο, ακολούθως το PIM μοντέλο, στη συνέχεια το PSM μοντέλο για να καταλήξει στον πηγαίο κώδικα για την επιλεγμένη πλατφόρμα και όλα τα άλλα απαραίτητα αρχεία για την δημιουργία ενός λειτουργικού λογισμικού. Αυτή η διαδικασία ακολουθεί μια καθετοποιημένη διαδρομή και για το λόγο αυτό ο μετασχηματισμός αυτός είναι κάθετος. Στην εικόνα, που ακολουθεί, φαίνονται ενδεικτικά κάποιες κατηγοριοποιήσεις μετασχηματισμών, χωρίς να είναι οι μόνες. Άλλη κατηγοριοποίηση είναι με βάση τη γλώσσα που χρησιμοποιείται από το μοντέλο εισόδου και εξόδου και χωρίζεται σε ενδογενή μετασχηματισμό, όπου το μοντέλο εισόδου και το μοντέλο εξόδου χρησιμοποιούν την ίδια γλώσσα, και σε εξωγενή μετασχηματισμό, όπου χρησιμοποιείται διαφορετική γλώσσα για την έκφραση των μοντέλων [28]. 2.8 Εργαλεία MDE Εικόνα 14: Παραδείγματα μετασχηματισμών μοντέλων [28] Στην ενότητα αυτή παρουσιάζονται τα εργαλεία, τα οποία χρησιμοποιήθηκαν στα πλαίσια της συγκεκριμένης διπλωματικής εργασίας, καθώς και τα πρότυπα της MDA αρχιτεκτονικής XML Metadata Interchange (XMI) πρότυπο Το XML Metadata Interchange (XMI) πρότυπο, προτάθηκε από το Object Management Group, για την ανταλλαγή πληροφορίας μεταδεδομένων μέσω της XML γλώσσας (Extensible Markup Language). Μπορεί να χρησιμοποιηθεί για οποιαδήποτε μεταδεδομένα, το μεταμοντέλο των οποίων περιγράφεται με βάση το MOF πρότυπο. Η συνηθέστερη χρήση του XMI προτύπου είναι η ανταλλαγή μορφοποίησης για UML 40

42 Σχεδίαση και ανάπτυξη διαδικτυακής εφαρμογής πελάτη για διαδικτυακές υπηρεσίες τύπου REST μοντέλα, αν και μπορεί να χρησιμοποιηθεί και για την σειριοποίηση μοντέλων σε άλλες γλώσσες μεταμοντέλων [29] Ecore Modeling Framework (EMF) Το EMF πλαίσιο είναι ένα μοντελοποίησης και παραγωγής κώδικα για την κατασκευή εργαλείων και άλλων εφαρμογών βασισμένων σε δομημένα μοντέλα δεδομένων. Από τις προδιαγραφές μοντέλων, περιγεγραμμένες σε XMI, το EMF πλαίσιο παρέχει εργαλεία για την παραγωγή κλάσεων για το μοντέλο, μαζί με ένα σύνολο κλάσεων προσαρμογής, οι οποίες καθιστούν δυνατή την προβολή και επεξεργασία μέσω εντολών του μοντέλου [30]. Εικόνα 15: Ιεραρχία του Ecore μετα-μεταμοντέλου [31] Το EMF πλαίσιο χρησιμοποιεί το Ecore μετα-μεταμοντέλο, το οποίο περιγράφει τον εαυτό του και αποτελεί τη βάση για την περιγραφή μετα-μοντέλων συμμορφωμένων με το MOF πρότυπο Object Constraint Language (OCL) Η OCL είναι μία τυπική γλώσσα γενικού σκοπού, που υιοθετήθηκε από το Object Management Group, και χρησιμοποιείται για να ορίσει διάφορα είδη εκφράσεων, που λειτουργούν συμπληρωματικά στις 41

43 πληροφορίες των UML μοντέλων. Η OCL γλώσσα είναι μία γλώσσα δηλωτική, με τύπους και χωρίς παρενέργειες προδιαγραφών. Η περιγραφή της OCL γλώσσας ως μίας γλώσσας με τύπους σημαίνει πως κάθε OCL έκφραση αντιστοιχίζεται σε ένα τύπο (είτε σε κάποιον από τους προκαθορισμένους OCL τύπους είτε σε ένα τύπο, που ορίζεται μέσα στο μοντέλο στο οποίο η OCL έκφραση χρησιμοποιείται) και πρέπει να συμμορφώνεται με τους κανόνες και τις λειτουργίες αυτού του τύπου. Χωρίς παρενέργειες συνεπάγεται ότι οι OCL εκφράσεις μπορούν να ρωτήσουν ή να περιορίσουν την κατάσταση ενός συστήματος αλλά δε μπορούν να το τροποποιήσουν. Δηλωτική σημαίνει ότι η OCL γλώσσα δεν περιλαμβάνει «προστακτικές κατασκευές» όπως για παράδειγμα αναθέσεις. Και τέλος, οι προδιαγραφές αναφέρονται στο γεγονός ότι ο ορισμός της γλώσσας δεν περιλαμβάνει οποιεσδήποτε λεπτομέρειες της υλοποίησης ή κατευθυντήριες γύρω από την υλοποίηση [32]. Εικόνα 16: Σχέση της μοντελοποιημένης εφαρμογής και της εφαρμογής σε OCL [33] Ανάμεσα στις πολλές εφαρμογές της OCL γλώσσας, μπορεί να χρησιμοποιηθεί για να ορίσει τα ακόλουθα είδη εκφράσεων: Σταθερές για τη δήλωση όλων των απαραίτητων συνθηκών, που πρέπει να ικανοποιούνται σε κάθε δυνατό στιγμιότυπο του μοντέλου. Αρχικοποίηση των ιδιοτήτων των κλάσεων. Κανόνες παραγωγής, που περιγράφουν τον τρόπο υπολογισμού της τιμής των παράγωγων στοιχείων του μοντέλου. Δραστηριότητες ερωτημάτων. Συμβάσεις δραστηριοτήτων (για παράδειγμα προ και μετά συνθηκών) Atlas Transformation Language Η ATL γλώσσα είναι μια γλώσσα μετασχηματισμού μοντέλων, που αναπτύχθηκε από την OBEO, και ορίζεται ως μεταμοντέλο και παράλληλα ως συμπαγές συντακτικό κειμένου. Είναι μία γλώσσα δηλωτική και προστακτική. Η προτιμώμενη χρήση του μετασχηματισμού είναι η δηλωτική, πράγμα που σημαίνει 42

44 Σχεδίαση και ανάπτυξη διαδικτυακής εφαρμογής πελάτη για διαδικτυακές υπηρεσίες τύπου REST πως μπορούν να χρησιμοποιηθούν απλές αντιστοιχίσεις. Ωστόσο, το γεγονός ότι αποτελεί και γλώσσα προστακτική σημαίνει ότι πολύ περίπλοκες αντιστοιχίσεις μπορούν να υλοποιηθούν μέσω κατασκευών. Ένα πρόγραμμα ATL μετασχηματισμού συντίθεται από κανόνες, που ορίζουν πως τα στοιχεία ενός μοντέλου εισόδου συνδυάζονται και κατευθύνονται για τη δημιουργία και την αρχικοποίηση των στοιχείων των μοντέλων εξόδου [34]. Στην σύνταξη της ATL γλώσσας υπάρχουν κάποιοι βασικοί κανόνες, που διαφοροποιούνται με βάση τον τρόπο με τον οποίο ενεργοποιούνται: Οι κανόνες προτύπου (matched rules), οι οποίοι εφαρμόζονται μόνο μία φορά για κάθε αντιστοιχία, που εντοπίζεται στα μοντέλα εισόδου. Οι χαλαροί κανόνες (lazy rules), που ενεργοποιούνται από άλλους κανόνες. Οι κανόνες αυτοί, εφαρμόζονται σε μία μόνο αντιστοιχία όσες φορές αναφέρεται στους άλλους κανόνες και κάθε φορά παράγουν ένα νέο σύνολο στοιχείων εξόδου. Οι μοναδικοί χαλαροί κανόνες (unique lazy rules), οι οποίοι,επίσης, ενεργοποιούνται από άλλους κανόνες. Εφαρμόζονται μόνο μία φορά για κάθε δοσμένη αντιστοιχία. Στην περίπτωση που ένας μοναδικός χαλαρός κανόνας ενεργοποιείται αργότερα για την ίδια αντιστοιχία επιστρέφει το ίδιο μετασχηματισμένο στοιχείο, που προέκυψε την πρώτη φορά της ενεργοποίησης Acceleo Model-to-Text transformation language Η Acceleo γλώσσα αποτελεί μία ρεαλιστική υλοποίηση του MOF Model to Text προτύπου από την Object Management Group. Η συγκεκριμένη γλώσσα χρησιμοποιείται για τον μετασχηματισμό μοντέλων σε αντικείμενα κειμένου και θα χρησιμοποιηθεί στην παρούσα διπλωματική εργασία για την αυτοματοποιημένη παραγωγή της διαδικτυακής εφαρμογής πελάτη με βάση τη REST αρχιτεκτονική [35]. Εικόνα 17: Acceleo Model To Text μετασχματισμός 43

45 Η Acceleo συνδυάζει το PSM μεταμοντέλο στην Ecore και XMI μορφή του για να παράξει μέσω προτύπων κειμένου (templates) τον πηγαίο κώδικα. Μέσα σε αυτά τα πρότυπα κειμένου περιέχονται στατικά στοιχεία, τα οποία αναπαράγονται ως έχουν, και δυναμικά στοιχεία, τα οποία προκύπτουν μέσα από την εφαρμογή εκφράσεων και ερωτημάτων διατυπωμένων στην OCL γλώσσα. Σε επόμενη ενότητα θα αναλυθεί περαιτέρω η Acceleo γλώσσα προγραμματισμού. 2.9 Ανάπτυξη διαδικτυκής εφαρμογής πελάτη για διαδικτυακές υπηρεσίες τύπου REST μέσω MDA αρχιτεκτονικής Τα τελευταία χρόνια οι διαδικτυακές υπηρεσίες τύπου REST εμφανίζουν εκθετικούς ρυθμούς ανάπτυξης, ενώ η διεύρυνση των δυνατοτήτων της τεχνολογίας λογισμικού οδηγούμενης από μοντέλα προμηνύει ενδιαφέρουσες εξελίξεις στον τομέα σχεδίασης διαδικτυακών εφαρμογών, αποκομίζοντας πολλαπλά οφέλη, που έχουν να κάνουν με την αξιοπιστία και την ποιότητα της τελικής εφαρμογής. Παράλληλα, η έκρηξη της ζήτησης REST διαδικτυακών υπηρεσιών οδηγεί και στην αύξηση των αναγκών για διαδικτυακές εφαρμογές πελάτη, που θα καταναλώνουν τις υπηρεσίες αυτές. Η ζήτηση αυτή οδήγησε στην ικανοποιητική, ως ένα βαθμό, υλοποίηση διαδικτυακών υπηρεσιών τύπου REST μέσω της MDA αρχιτεκτονικής και μας ωθεί στην διερεύνηση της δυνατότητας αυτοματοποίησης και της διαδικασίας παραγωγής διαδικτυακών εφαρμογών πελάτη με βάση την MDA αρχιτεκτονική. Στη συνέχεια, θα περιγραφούν τα πρότυπα με βάση τα οποία θα αναπτυχθεί η διαδικτυακή εφαρμογή πελάτη Το μοτίβο Μοντέλο-Όψη-Ελεγκτής (Model-View-Controller, MVC) Το μοτίβο μοντέλο-όψη-ελεγκτής αποτελεί ένα από τα παλαιότερα και πιο διαδεδομένα πρότυπα αρχιτεκτονικής για γραφικά περιβάλλοντα και διεπαφές χρηστών. Η χρήση του, αν και δεν περιορίζεται στην ανάπτυξη διαδικτυακών εφαρμογών πελάτη, προσφέρει ιδιαίτερα πλεονεκτήματα στις συγκεκριμένες εφαρμογές καθώς απλοποιεί σε μεγάλο βαθμό την ανάπτυξη και συντήρησή τους. Το MVC μοτίβο βασίζεται στον διαχωρισμό της εφαρμογής σε τρία διαφορετικά επίπεδα, που είναι διασυνδεδεμένα μεταξύ τους. Βασικό στοιχείο του μοτίβου είναι το μοντέλο, το οποίο είναι υπεύθυνο για την ανάκτηση/αποθήκευση δεδομένων στο σύστημα. Η όψη χρησιμοποιείται για την γραφική αναπαράσταση των πληροφοριών, που περιέχει το μοντέλο, και ο ελεγκτής διαχειρίζεται τις εντολές για τη λειτουργία του μοντέλου και της όψης. Στην Εικόνα 18 φαίνεται η σχέση μεταξύ των τριών επιπέδων. 44

46 Σχεδίαση και ανάπτυξη διαδικτυακής εφαρμογής πελάτη για διαδικτυακές υπηρεσίες τύπου REST Εικόνα 18: Οι διασυνδέσεις μεταξύ των επιπέδων του μοτίβου MVC και του χρήστη [36] Εφαρμογή μοναδικής σελίδας (Single Page Application, SPA) Η εφαρμογή μοναδικής σελίδας είναι μία διαδικτυακή εφαρμογή, που προσαρμόζεται σε μία ιστοσελίδα, με στόχο την παροχή μίας πιο συνεκτικής εμπειρίας χρήστη. Μία παραδοσιακή ιστοσελίδα έχει ένα πολύ περιορισμένο κύκλο ζωής, καθώς με κάθε νέο αίτημα του πελάτη προς τον διακομιστή αποστέλλεται και φορτώνεται εκ νέου το αρχείο HTML, που προβάλλει τα δεδομένα της απόκρισης. Η βασική διαφοροποίηση της εφαρμογής μοναδικής σελίδας έγκειται στο γεγονός ότι η HTML σελίδα λαμβάνεται και φορτώνεται μόνο μία φορά και στη συνέχεια τα δεδομένα ανανεώνονται δυναμικά, όταν ο χρήστης αλληλεπιδρά με την διαδικτυακή υπηρεσία [37]. Στην Εικόνα 19 παρουσιάζεται σχηματικά αυτή η διαφοροποίηση. Εικόνα 19: Ο κύκλος ζωής μιας παραδοσιακής ιστοσελίδας και μιας εφαρμογής μοναδικής σελίδας [38] 45

47 2.9.3 Κριτήρια αξιολόγησης ενός διαδικτυακού API Για την αξιολόγηση ενός διαδικτυακού REST API έχει καθιερωθεί η χρήση του μοντέλου ωριμότητας Richardson (Richardson Maturity Model, RMM). Αυτό το μοντέλο διαθέτει τέσσερις κλίμακες (0-3) και όσο περισσότερο συμμορφώνεται ένα API στο REST αρχιτεκτονικό στυλ τόσο μεγαλύτερο σκορ πετυχαίνει με την κλίμακα 3, να σηματοδοτεί ένα αληθινό REST API. Εικόνα 20: Τα επίπεδα του μοντέλου ωριμότητας Richardson [21] Επίπεδο 0: Swamp of POX Το API επιπέδου 0 χρησιμοποιούν το πρωτόκολλο της εφαρμογής ως πρωτόκολλο μεταφοράς. Αυτό σημαίνει ότι μεταδίδει και λαμβάνει αίτηματα και αποκρίσεις μέσα από το δικό της πρωτόκολλο, χωρίς να χρησιμοποιεί το πρωτόκολλο για την υπόδειξη της κατάστασης της εφαρμογής. Χρησιμοποιεί μόνο ένα URI και μόνο μία μέθοδο, συνήθως στο HTTP πρωτόκολλο χρησιμοποιείται η POST μέθοδος. Παραδείγματα τέτοιων API είναι τα SOAP και XML-RPC APIs. Επίπεδο 1: Πόροι Όταν ένα API μπορεί να διαχωρίσει δύο διαφορετικούς πόρους, μπορεί να είναι επιπέδου 1. Σε αυτό το επίπεδο χρησιμοποιούνται πολλαπλά URIs, όπου κάθε URI είναι το σημείο πρόσβασης σε ένα συγκεκριμένο πόρο. Και σε αυτό το επίπεδο χρησιμοποιείται μόνο μία μέθοδος όπως η POST. 46

48 Σχεδίαση και ανάπτυξη διαδικτυακής εφαρμογής πελάτη για διαδικτυακές υπηρεσίες τύπου REST Επίπεδο 2: Μέθοδοι HTTP Τα APIs του δεύτερου επιπέδου χρησιμοποιούν πόρους διευθυνσιοδοτημένους από URIs και μπορούν να υποστηρίξουν πολλές HTTP μεθόδους για κάθε πόρο. Επίπεδο 3: Έλεγχοι υπερμέσων Τα APIs του ανώτατου επιπέδου χρησιμοποιούν HATEOAS (Hypertext As The Engine Of Application State). Αυτά είναι, ουσιαστικά, αναπαραστάσεις που περιέχουν URI συνδέσμους προς άλλους πόρους, που θα ενδιέφεραν τον καταναλωτή της υπηρεσίας. Μέσω αυτών των ελέγχων τα APIs καθοδηγούν μέσα από ένα μονοπάτι πόρων, δίνοντας οδηγίες για τις δυνατές ενέργειες και διαδρομές σε κάθε πόρο. Στις επόμενες ενότητες θα παρουσιαστεί η μεθοδολογία και η προσπάθεια υλοποίησης της αυτοματοποίησης της διαδικασίας ανάπτυξης διαδικτυακών εφαρμογών πελάτη, που καταναλώνουν διαδικτυακές υπηρεσίες τύπου REST. 47

49 3 Υπάρχουσες Τεχνολογίες 3.1 Υπάρχουσες τεχνολογίες για την αυτοματοποιημένη παραγωγή διαδικτυακών υπηρεσιών τύπου REST Σε αυτή την ενότητα θα παρουσιαστούν τα σχετικά έργα και πλαίσια, που υπάρχουν, για την ανάπτυξη διαδικτυακών υπηρεσιών τύπου REST. Στο τέλος της ενότητας παρέχεται μία επισκόπηση των τρόπων, που σχετίζεται, το S-CASE έργο με τα υπόλοιπα πλαίσια και τα συγκριτικά πλεονεκτήματα, που αυτό διαθέτει Ruby on Rails Το Ruby on Rails είναι ένα πλαίσιο ανοιχτού κώδικα για την ανάπτυξη διαδικτυακών εφαρμογών με βάση τη γλώσσα προγραμματισμού Ruby και κυκλοφόρησε για πρώτη φορά το 2005 [39]. Έκτοτε, έχει εξελιχθεί αρκετά και έχει αποκτήσει μεγάλη δημοτικότητα. Κάποια βασικά πλεονεκτήματα του είναι: Η απλή φύση της γλώσσας Ruby, και κατ επέκταση η ευκολία εκμάθησής της. Η ενσωμάτωση γνωστών προτύπων/ μοτίβων της τεχνολογίας λογισμικού, όπως το MVC πρότυπο. Η υιοθέτηση της νοοτροπίας ανοιχτού κώδικα. Η ταχύτητα και ευελιξία, που προσφέρει μειώνοντας έτσι το απαιτούμενο κόστος και χρόνο για την κατασκευή διαδικτυακών υπηρεσιών. Όπως φαίνεται και στην παραπάνω εικόνα, ο πυρήνας της υπηρεσίας Rails βασίζεται στο Model-View- Controller μοτίβο. Τα μοντέλα αποθηκεύουν δεδομένα και χαρτογραφούνται σε πίνακες της βάσης δεδομένων της υπηρεσίας. Οι ελεγκτές λαμβάνουν και αποκρίνονται σε εξωτερικά αιτήματα παρέχοντας ένα σύνολο ενεργειών. Οι όψεις είναι αρχεία, που συντάσσονται σε HTML. Τέλος, θα πρέπει να σημειωθεί ότι αν και δεν είναι υποχρεωτικό, προτείνεται η χρήση των ενεργειών τύπου REST, καθώς οι ελεγκτές αποκρίνονται κατά προτίμηση στα create/new, edit/update, destroy, show/index, στο βαθμό που το Ruby on Rails δίνει έμφαση σε αυτές τις ενέργειες. 48

50 Σχεδίαση και ανάπτυξη διαδικτυακής εφαρμογής πελάτη για διαδικτυακές υπηρεσίες τύπου REST Εικόνα 21: Η βασική δομή μίας υπηρεσίας Rails [40] Το Ruby on Rails πλαίσιο έχει γίνει αποδέκτης κριτικής κυρίως σε σχέση τις δυνατότητες επίδοσης και επεκτασιμότητας. Παρόλα αυτά, συνεχίζει να κατέχει υψηλή θέση ανάμεσα στα διάφορα πλαίσια ανάπτυξης εφαρμογών τύπου REST και κάποιες γνωστές υπηρεσίες, όπως το Twitter, το Groupon και το Scribd, το χρησιμοποιούν EMF-Rest EMF-Rest είναι ένα πλαίσιο βασισμένο στην Eclipse πλατφόρμα, που επιτρέπει την ανάπτυξη διαδικτυακών υπηρεσιών χρησιμοποιώντας Ecore μεταμοντέλα. Όπως παρουσιάζεται στην εικόνα, η ανάπτυξη μιας διαδικτυακής υπηρεσίας με το EMF-Rest εκκινά με την μοντελοποίηση της επιθυμητής υπηρεσίας με τη χρήση Ecore μεταμοντέλων, στη μορφή διαγραμμάτων κλάσεων. Έπειτα, το EMF-Rest πλαίσιο παράγει την αντίστοιχη υπηρεσία και παρέχει ένα APΙ τύπου REST μέσω JAX-RS, JSON serializers και Javascript API [41]. 49

51 Εικόνα 22: Επισκόπηση του EMF-Rest [42] Η Εικόνα 23 δείχνει ένα API τύπου REST, που παράχθηκε από ένα παράδειγμα της οικογένειας μεταμοντέλων Ecore, ενώ στα αριστερά, φαίνεται μία απόκριση σε JSON, όπως παράχθηκε από την υπηρεσία. Όπως παρατηρείται, η απόκριση δεν παράγει ρυθμίσεις υπερμέσων (Hypermedia Controls) και για το λόγο αυτό το συγκεκριμένο πλαίσιο δεν επιτυγχάνει τη μέγιστη φιλικότητα διαδικτύου, όπως αυτή περιγράφεται στο Μοντέλο Ωριμότητας Ριτσαρντσον (Richardson Maturity Model, RMM). 50

52 Σχεδίαση και ανάπτυξη διαδικτυακής εφαρμογής πελάτη για διαδικτυακές υπηρεσίες τύπου REST Εικόνα 23 Αριστερά: Παράδειγμα JSON απόκρισης Δεξιά: Παράδειγμα API τύπου REST [41] Django REST Framework Το Django REST Framework είναι είναι ένα ακόμη πλαίσιο για την παραγωγή διαδικτυακών υπηρεσιών τύπου REST, το οποίο βασίζεται στη γλώσσα python. Η διαδικασία ανάπτυξης ενός API τύπου REST περνάει,αρχικά, μέσα από τον ορισμό ενός μοντέλου, που θα αναπαριστά τα δεδομένα με τα οποία η διεπαφή τύπου REST θα αλληλεπιδρά. Στη συνέχεια, δημιουργούνται κάποιοι σειριακοί μετατροπείς (serializers). Έπειτα, ο προγραμματιστής θα πρέπει να ορίσει τις όψεις. Τέλος, προκειμένου να συμπεριληφθεί η λειτουργία υπερσυνδέσμων, θα πρέπει να στηθεί ένα python αρχείο με URL templates. Εικόνα 24: Django REST Framework serializer [43] Η Εικόνα 25 παρουσιάζει την απόκριση σε ένα GET αίτημα. Βασικό μειονέκτημα και του Django REST Framework είναι η αδυναμία αυτόματης παραγωγής Ρυθμίσεων Υπερμέσων (Hypermedia Controls). 51

53 Εικόνα 25: Απόκριση μίας υπηρεσίας παραγμένης από το Django REST Framework [43] Η S-CASE MDE μηχανή σε σχέση με τις τελευταίες τεχνολογίες Στις προηγούμενες υποενότητες παρουσιάστηκε μια σύντομη επισκόπηση των πιο σύγχρονων τεχνολογιών στον τομέα αυτοματοποιημένης ανάπτυξης διαδικτυακών APIs τύπου REST. Όπως έχει ήδη περιγραφεί καταβάλλεται μία μεγάλη προσπάθεια για να επιτευχθούν ανώτερα επίπεδα αυτοματοποίησης και φιλικότητας διαδικτύου με βάση το μοντέλο RMM. Ωστόσο, δεν έχει υπάρξει μέχρι τώρα κάποια τεχνολογία, που να καταφέρνει την διασύνδεση των πόρων με ρυθμίσεις υπερμέσων και ως εκ τούτου να επιτευχθεί και το ανώτερο επίπεδο φιλικότητας διαδικτύου. Η βέλτιστη εκδοχή, που έχει παρουσιαστεί ως τώρα, επιτυγχάνει την χρήση συνδέσμων υπερμέσων είτε πολύ περιορισμένα είτε με την παρέμβαση προγραμματιστών. Σε αντίθεση με τις υπάρχουσες τεχνολογίες, η S-CASE MDE μηχανή έχει ως στόχο την αυτοματοποίηση της διαδικασίας ανάπτυξης διαδικτυακών APIs τύπου REST στο μέγιστο βαθμό και για αυτό το λόγο καταβάλλεται μεγάλη προσπάθεια οι παραγόμενες υπηρεσίες να ανήκουν στο τρίτο επίπεδο του RMM μοντέλου [44]. 52

54 Σχεδίαση και ανάπτυξη διαδικτυακής εφαρμογής πελάτη για διαδικτυακές υπηρεσίες τύπου REST Εικόνα 26: Η S-CASE μηχανή σε επίπεδο συστατικών στοιχείων [44] Με αυτά τα δεδομένα, τα πλεονεκτήματα της S-CASE MDE μηχανής σε σχέση με τις υπάρχουσες τεχνολογίες είναι τα εξής: Την πλήρη ενσωμάτωση του REST αρχιτεκτονικού τύπου στις παραγόμενες διαδικτυακές υπηρεσίες. Οι παραγόμενοι πόροι είναι σημασιολογικά συνυφασμένοι μεταξύ τους μέσω ελέγχων με υπερμέσα. Έτσι, όποτε οι πελάτες αλληλεπιδρούν με τους πόρους, λαμβάνουν μαζί με την αναμενόμενη HTTP απόκριση και μία ολοκληρωμένη λίστα με συνδέσμους υπερμέσων, με όλες τις δυνατές ενέργειες, που μπορεί να επιλέξει ο πελάτης. Επίσης, στην απόκριση συμπεριλαμβάνονται τα URI κάθε πόρου, τα HTTP verbs, που μπορούν να χρησιμοποιηθούν, για να αλληλεπιδράσουν με τον πόρο και τη σχέση, που έχει κάθε πόρος με την ενέργεια, που πραγματοποιήθηκε. Το S-CASE έργο εμπεριέχει το σύνολο των χαρακτηριστικών της τεχνολογίας οδηγούμενης από μοντέλα και ενσωματώνει όλα τα συνακόλουθα πλεονεκτήματα αυτής της τεχνολογίας. Αυτό σημαίνει ότι παρέχεται ένας ολοκληρωμένος μηχανισμός, που είναι επεκτάσιμος για να υποστηρίζει πολλαπλές πλατφόρμες σε αντίθεση με τα περισσότερα άλλα πλαίσια, που υποστηρίζουν έναν απλό συνδυασμό κάποιων γλωσσών προγραμματισμού και δύο ή τρία πλαίσια τρίτων. Η κατασκευή διάφανων μετασχηματισμών μέσα στα στάδια του MDE χρησιμοποιώντας δηλωτικά προγραμματιστικά παραδείγματα με ATL οδηγεί στην αυξημένη ορατότητα και ανιχνευσιμότητα ολόκληρης της διαδικασίας μετασχηματισμού. Τα παραγόμενα μεταμοντέλα για τα PIM και PSM μοντέλα ενσωματώνουν ένα τυποποιημένο σύνολο περιορισμών OCL, το οποίο παρέχει τη δυνατότητα επικύρωσης κάθε παραγόμενης διαδικτυακής υπηρεσίας από την πλατφόρμα S-CASE με βάση τη συμμόρφωσή τους στο REST 53

55 αρχιτεκτονικό στυλ, καθώς και δομική συνοχή και συνοχή συμπεριφοράς για όλα τα ενδιάμεσα και τελικά αντικείμενα. Η παραγωγή, λοιπόν, διαδικτυακών υπηρεσιών, που πληρούν το REST αρχιτεκτονικό στυλ και επιτυγχάνουν το ανώτερο επίπεδο φιλικότητας διαδικτύου με βάση το RMM μοντέλο, είναι ένας από τους βασικούς λόγους, που επιλέχθηκε η S-CASE πλατφόρμα για την παρούσα διπλωματική εργασία. Με αυτό τον τρόπο διασφαλίζεται πως η διαδικτυακή υπηρεσία για την οποία θα σχεδιαστεί και θα αναπτυχθεί η διαδικτυακή εφαρμογή πελάτη, θα ανταποκρίνεται στις βασικές αρχές του REST αρχιτεκτονικού στυλ και θα εκμεταλλευτεί όλα τα πλεονεκτήματα, που αυτό προσφέρει. 3.2 Υπάρχουσες τεχνολογίες για αυτοματοποιημένη παραγωγή εφαρμογής πελάτη Η αυξανόμενη ανάγκη για την ανάπτυξη νέων διαδικτυακών APIs και η υιοθέτηση, ως ένα βαθμό, εργαλείων για την αυτοματοποιημένη παραγωγή διαδικτυακών υπηρεσιών, όπως οι τεχνολογίες που περιγράφηκαν παραπάνω, ωθούν και στην ανάπτυξη εργαλείων για την αυτοματοποιημένη παραγωγή ερφαρμογών πελάτη, που θα καταναλώνουν αυτές τις υπηρεσίες. Σε αυτή την ενότητα, θα παρουσιαστούν κάποιες από τις πιο ολοκληρωμένες λύσεις, που έχουν εμφανιστεί έως τώρα APIMATIC DX Kits Το εργαλείο APIMATIC DX Kits δημιουργήθηκε για την ανάπτυξη SDK πλατφόρμων και βιβλιοθηκών πελάτη (client libraries). Ως είσοδο δέχεται τον ορισμό του API και στη συνέχεια παράγει μέρη κώδικα στην επιλεγμένη γλώσσα προγραμματισμού. Οι βασικές υποστηριζόμενες μορφές για τον ορισμό του API είναι σε Swagger 2.0 JSON, Swagger 2.0 YAML, RAML 0.8 και WADL. Έπειτα από την επικύρωση του API, επιλέγεται η επιθυμητή γλώσσα προγραμματισμού για την παραγωγή του κώδικα. Παράλληλα, το APIMATIC DX Kits παρέχει και τη δυνατότητα παραγωγής κώδικα δοκιμής για APIs. Εικόνα 27: APIMATIC DX Kits υποστηριζόμενες λειτουργίες και γλώσσες προγραμματισμού 54

56 Σχεδίαση και ανάπτυξη διαδικτυακής εφαρμογής πελάτη για διαδικτυακές υπηρεσίες τύπου REST Βασικά μειονεκτήματα του συγκεκριμένου εργαλείου είναι τα εξής: Δεν παρέχει ολοκληρωμένη εφαρμογή πελάτη, αλλά βιβλιοθήκες πελάτη. Πράγμα, που σημαίνει ότι το παραγόμενο σύστημα είναι μη φιλικό προς το μέσο χρήστη και απευθύνεται αυστηρά σε προγραμματιστές, που θέλουν να επιβλέψουν την λειτουργία των HTTP μεθόδων μέσα από τα μηνύματα, που αναγράφονται στην κονσόλα. Δεν είναι ανοικτού κώδικα και η πρόσβαση στο συγκεκριμένο εργαλείο απαιτεί μηνιαία συνδρομή Restlet Studio Η πλατφόρμα Restlet Studio αποτελεί μία online πλατφόρμα, που παρέχει τη δυνατότητα επεξεργασίας ενός REST API και την παραγωγή σκελετών διακομιστή και βιβλιοθηκών πελατών. Η επεξεργασία του API γίνεται μέσα από το γραφικό περιβάλλον, που διαθέτει η πλατφόρμα, και τα υποστηριζόμενα αρχείο εισόδου είναι σε μορφή Swagger 2.0, Swagger 1.2, RAML 0.8, RAML 1.0. Μετά την εισαγωγή του API στην πλατφόρμα για την παραγωγή της βιβλιοθήκης πελάτη απαιτείται από την χρήστη να επιλέξει τη γλώσσα προγραμματισμού στην οποία θα παραχθεί ο κώδικας για το επιθυμητό API. Το αποτέλεσμα αυτής της διαδικασίας είναι ένα zip αρχείο, που περιέχει τον κώδικα για την υλοποίηση των HTTP μεθόδων για κάθε πόρο, που περιγράφει το API, και ένα README αρχείο, όπου περιγράφει το περιεχόμενο του κώδικα. Οι δυνατές επιλογές γλώσσας προγραμματισμού για την παραγωγή βιβλιοθήκης πελάτη είναι οι Android, Java, Objective-C, Angular JS και Node Js. Το βασικό μειονέκτημα και αυτής της τεχνολογίας είναι πως δεν παρέχει μια ολοκληρωμένη λύση για τον μέσο χρήστη, καθώς δεν παράγει κανένα αρχείο για την γραφική αναπαράσταση των δεδομένων και των δυνατών ενεργειών, που παρέχει μια REST υπηρεσία Swagger Code Generator Το Swagger Code Generator αποτελεί ίσως μία από τις πιο ολοκληρωμένες λύσεις για την αυτοματοποιημένη παραγωγή βιβλιοθηκών πελάτη. Το swagger code generator είναι μία online πλατφόρμα,όπου δέχεται ως είσοδο ένα αρχείο OpenAPI Spec, σε μορφή YAML ή JSON. Για την λήψη της παραγόμενης βιβλιοθήκης πελάτη χρειάζεται η αποστολή ενός αιτήματος POST, όπου στην απόκριση του περιλαμβάνεται ένα URI από όπου μπορεί να γίνει η λήψη της. Τα πλεονεκτήματα του swagger code generator είναι η παραγωγή της βιβλιοθήκης για το σύνολο του API, χωρίς να χρειάζεται η αποστολή αιτημάτων ξεχωριστά για κάθε πόρο, και η δυνατότητα παραγωγής κώδικα σε 34 διαφορετικές γλώσσες προγραμματισμού. Ωστόσο και πάλι η αυτοματοποίηση περιορίζεται μόνο σε βιβλιοθήκες πελάτη και όχι στην ανάπτυξη μιας συνολικής εφαρμογής πελάτη. 55

57 3.2.4 Συμπεράσματα Από την περιγραφή των παραπάνω τεχνολογιών φαίνεται πως αυτή τη στιγμή δεν υπάρχουν τεχνολογίες, που να μπορούν να παράξουν εφαρμογές πελάτη έτοιμες προς κατανάλωση. Πολλώ δε μάλλον, εφαρμογές πελάτη που να παράγονται απευθείας από το μοντέλο της επιθυμητής προς κατανάλωση υπηρεσίας. Για αυτό το λόγο θα επιδιωχθεί μέσα από την παρούσα διπλωματική εργασία η ανάπτυξη μιας αυτοματοποιημένης διαδικασίας παραγωγής εφαρμογής πελάτη χρησιμοποιώντας έναν acceleo μετασχηματισμό από το PSM μοντέλο σε κώδικα Η χρήση του πλαισίου AngularJS για την ανάπτυξη εφαρμογών πελάτη Για την υλοποίηση της διαδικτυακής εφαρμογής πελάτη θα χρησιμοποιηθεί το πλαίσιο Angular JS. Η Angular JS αποτελεί ένα δυναμικό πλαίσιο για την ανάπτυξη δυναμικών διαδικτυακών εφαρμογών, που συντηρείται κυρίως από την Google και μια κοινότητα προγραμματιστών και εταιριών [45]. Η λογική, που ακολουθεί το Angular JS, διαφέρει εντελώς με τις συνήθεις προσπάθειες υλοποίησης διαδικτυακών εφαρμογών, που απλώς προσθέτουν βιβλιοθήκες ή πλαίσια, που αποτελούν μια συγκεκριμένη υλοποίηση μιας διαδικτυακής εφαρμογής. Η λογική του Angular JS πλαισίου βασίζεται στην ελαχιστοποίηση της αναντιστοιχίας ανάμεσα σε αρχεία με κέντρο την HTML και στις ανάγκες της διαδικτυακής εφαρμογής μέσω της δημιουργίας νέων HTML κατασκευών. Ουσιαστικά, το Angular JS πλαίσιο «διδάσκει» στον περιηγητή νέο συντακτικό μέσα από τις κατασκευές αυτές, που ονομάζονται directives. Τέλος, το πλαίσιο αυτό απλοποιεί την διαδικασία ανάπτυξης εφαρμογών παρέχοντας ένα μεγαλύτερο επίπεδο αφαίρεσης στον προγραμματιστή και έχει δομηθεί για την εξυπηρέτηση CRUD εφαρμογών (CREATE, READ, UPDATE, DELETE) [46]. Γεγονός που το καθιστά ιδανικό για την υλοποίηση της συγκεκριμένης διπλωματικής. 56

58 Σχεδίαση και ανάπτυξη διαδικτυακής εφαρμογής πελάτη για διαδικτυακές υπηρεσίες τύπου REST 4 Μεθοδολογία 4.1 Η προσέγγιση του S-CASE στη δημιουργία διαδικτυακών εφαρμογών Όπως αναφέρθηκε και στην προηγούμενη ενότητα, η παρούσα διπλωματική εργασία βασίζεται στην ανάπτυξη διαδικτυακών εφαρμογών πελάτη, που θα καταναλώνουν διαδικτυακές υπηρεσίες τύπου REST παραγόμενες από την πλατφόρμα S-CASE. H πλατφόρμα S-CASE ξεκίνησε ως ένα ερευνητικό πρόγραμμα με τη συμμετοχή του Τμήματος Ηλεκτρολόγων Μηχανικών και Μηχανικών Υπολογιστών του Αριστοτέλειου Πανεπιστήμιου Θεσσαλονίκης το Νοέμβριο του Σκοπός του συγκεκριμένου προγράμματος είναι η παραγωγή ενός συνόλου εργαλείων και υπηρεσιών για την γρήγορη και αποτελεσματική ανάπτυξη διαδικτυακών υπηρεσιών τύπου REST υψηλής ποιότητας [47]. Για την υλοποίηση του S-CASE έργου αξιοποιήθηκαν οι βασικές αρχές της τεχνολογίας λογισμικού οδηγούμενης από μοντέλα και αποτελείται από τέσσερα ξεχωριστά στοιχεία, κάθε ένα από τα οποία αντιστοιχεί και σε κάθε φάση της τεχνολογίας λογισμικού. Τα στοιχεία αυτά είναι το CIM μοντέλο, το PIM μοντέλο, το PSM μοντέλο και ο τελικός παραγόμενος κώδικας. Αυτά τα στοιχεία και οι σχέσεις μεταξύ τους φαίνονται στην Εικόνα 28. Εικόνα 28: Τα τέσσερα στάδια της τεχνολογίας λογισμικού οδηγούμενης από μοντέλα [44] Η γεννήτρια CIM του S-CASE διαβάζει ως είσοδο την S-CASE οντολογία και παράγει το CIM μοντέλο, που ανταποκρίνεται στο επιθυμητό προς ανάπτυξη σύστημα, σε XMI μορφή. Στη συνέχεια, το CIM μεταμοντέλο δίνεται ως είσοδος στη γεννήτρια PIM. Η κύρια εργασία της συγκεκριμένης γεννήτριας είναι η εφαρμογή των βασικών αρχών του REST αρχιτεκτονικού στυλ στο CIM μεταμοντέλο και να εξειδικεύσει τις σχεδιαστικές αοριστίες σύμφωνα με τις REST αρχές. Η έξοδος της γεννήτριας είναι ένα PIM μοντέλο του επιθυμητού συστήματος, που συμμορφώνεται στο PIM μεταμοντέλο, και έχει XMI μορφή. Έπειτα, η 57

59 PSM γεννήτρια αναλύει το παραγόμενο PIM μοντέλο και καθορίζει τον γενικό σχεδιασμό του. Αυτό σημαίνει ότι για κάθε γενικό στοιχείο του PIM μοντέλου η PSM γεννήτρια παράγει ένα PSM στοιχείο σημασιολογικά αντίστοιχο με αυτό του PIM μοντέλου, αλλά με καθορισμένες τεχνολογίες, και συμμορφωμένο με το PSM μεταμοντέλο. Το παραγόμενο PSM μοντέλο είναι σε μορφή XMI και περιέχει όλη την απαιτούμενη πληροφορία για την αυτοματοποιημένη παραγωγή κώδικα. Η περιγραφή των CIM και PIM μεταμοντέλων, που χρησιμοποιεί η S-CASE πλατφόρμα, παραλείπεται στην παρούσα διπλωματική, καθώς για την υλοποίηση χρησιμοποιείται μόνο το PSM μεταμοντέλο. Περισσότερες πληροφορίες γύρω από τα CIM και PIM μεταμοντέλα παρέχονται στα παραδοτέα του S-CASE [47]. Στην παρούσα διπλωματική επιδιώκεται μέσω ενός Model to Text μετασχηματισμού, που θα δέχεται ως είσοδο το PSM μοντέλο της επιθυμητής διαδικτυακής υπηρεσίας τύπου REST, η αυτοματοποίηση της παραγωγής διαδικτυακών εφαρμογών πελάτη. Σκοπός αυτής της διπλωματικής εργασίας είναι η επέκταση των συμβατών με την S-CASE πλατφόρμα εργαλείων και η μείωση του χρόνου και του κόστους, που καταναλώνεται για την ανάπτυξη φιλικών προς των χρήστη διαδικτυακών εφαρμογών πελάτη για την κατανάλωση διαδικτυακών υπηρεσιών, εκμεταλλευόμενοι τα πλεονεκτήματα, που προσφέρει το REST αρχιτεκτονικό στυλ. Στη συνέχεια αυτής της ενότητας θα ακολουθήσει μια σύντομη περιγραφή του PSM μεταμοντέλου, που χρησιμοποιήθηκε, καθώς και η υλοποίηση της αυτοματοποίησης της διαδικασίας ανάπτυξης της διαδικτυακής εφαρμογής πελάτη. Τέλος, στην Εικόνα 29 παρουσιάζεται η επισκόπηση της S-CASE MDE μηχανής και η σχέση της με την υλοποίηση της παρούσας διπλωματικής. Εικόνα 29: Υλοποίηση αυτοματοποιημένης παραγωγής εφαρμογής πελάτη και η σχέση του με το S-CASE 58

60 Σχεδίαση και ανάπτυξη διαδικτυακής εφαρμογής πελάτη για διαδικτυακές υπηρεσίες τύπου REST 4.2 Σχεδιαστικοί στόχοι και απαιτήσεις Για την παραγωγή μιας εφαρμογής πελάτη, η οποία να είναι λειτουργική και φιλική προς το χρήστη, θα πρέπει να πληρούνται κάποιες προϋποθέσεις. Οι λειτουργικές απαιτήσεις, που θα πρέπει να πληροί η παραγόμενη διαδικτυακή εφαρμογή πελάτη είναι οι εξής: 1. Η παραγόμενη εφαρμογή πελάτη πρέπει να συμμορφώνεται με το REST αρχιτεκτονικό στυλ. 2. Η παραγόμενη εφαρμογή πελάτη πρέπει να βασίζεται στο πρότυπο MVC. 3. Η παραγόμενη εφαρμογή πελάτη πρέπει να χρησιμοποιεί το πρωτόκολλο επικοινωνίας HTTP, δηλαδή να χρησιμοποιεί τις μεθόδους CRUD verbs του πρωτόκολλου HTTP. 4. Η παραγόμενη εφαρμογή πελάτη πρέπει να υλοποιεί για κάθε πόρο μόνο τις μεθόδους, που περιγράφει το PSM μοντέλο για το συγκεκριμένο πόρο. 5. Η παραγόμενη εφαρμογή πρέπει να υποστηρίζει υπηρεσίες, που απαιτούν την εμφάνιση πολλαπλών πόρων στην αρχική σελίδα. 6. Η παραγόμενη εφαρμογή πελάτη πρέπει να υποστηρίζει λειτουργίες ταυτοποίησης (authentication). 7. Η παραγόμενη εφαρμογή πελάτη πρέπει να περιέχει στοιχεία UI/UX για καλύτερη αλληλεπίδραση με τον χρήστη. 8. Ο κώδικας της παραγόμενης εφαρμογής πελάτη πρέπει να συνοδεύεται από την βασικές πληροφορίες σχετικά με τις μεθόδους του. 9. Η παραγόμενη εφαρμογή πελάτη πρέπει να περιέχει όλες τις απαραίτητες βιβλιοθήκες για τη λειτουργία της. Η κάλυψη των παραπάνω απαιτήσεων αποτελούν βασική προϋπόθεση για την ορθή λειτουργία της παραγόμενης εφαρμογής πελάτη και βοηθούν στην ανάπτυξη μιας εφαρμογής εύληπτης και εύκολα συντηρήσιμης. 4.3 Η αρχιτεκτονική των παραγόμενων εφαρμογών πελάτη Όπως θα φανεί και στα παρακάτω παραδείγματα εφαρμογής οι παραγόμενες εφαρμογές πελάτη έχουν τη δυνατότητα να εξυπηρετήσουν πολλές και διαφορετικές RESTful υπηρεσίες. Η αρχιτεκτονική της εφαρμογής πελάτη αποτελείται από μία αρχική σελίδα και ξεχωριστές σελίδες για κάθε πόρο. Στην αρχική σελίδα εμφανίζεται μία λίστα στιγμιότυπων του αρχικού πόρου, που δεν είναι σχετικός από άλλους, οι επιτρεπτές ενέργειες για τον πόρο και η δυνατότητα επιλογής και εμφάνισης συγκεκριμένου στιγμιότυπου του πόρου και των ιδιοτήτητων του (Εικόνα 30). Παράλληλα, ακολουθώντας το REST στυλ 59

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

62 Σχεδίαση και ανάπτυξη διαδικτυακής εφαρμογής πελάτη για διαδικτυακές υπηρεσίες τύπου REST Πέρα από τη γενική αρχιτεκτονική, που παρουσιάστηκε παραπάνω, οι παραγόμενες εφαρμογές πελάτη διαθέτουν και μια σειρά από άλλα χαρακτηριστικά για εύκολη πλοήγηση ανάμεσα στις σελίδες, αισθητική μορφοποίηση, αλληλεπίδραση με τον χρήστη και σχεδίαση που να καλύπτει βασικές ανάγκες για άτομα με προβλήματα όρασης. Αρχικά, όλες οι σελίδες εκτός της αρχικής περιέχουν κουμπί Back, που οδηγεί στην Εικόνα 31: Περιεχόμενα φάκελου dev για την εφαρμογή wapoadmintoolapi 4.4 PSM μεταμοντέλο Εικόνα 32: Περιεχόμενα αρχείου AccountsSearch, που βρίσκεται στο φάκελο dev προηγούμενη σελίδα, δηλαδή στον πόρο από τον οποίο ήταν σχετικός ο πόρος, που επιλέχθηκε το κουμπί Back. Επίσης, στο επάνω μέρος κάθε σελίδας εμφανίζεται το όνομα της υπηρεσίας, την οποία καταναλώνει η εφαρμογή πελάτη, και σε όλες τις σελίδες εκτός της αρχικής το όνομα αυτό είναι υπερσύνδεσμος, που οδηγεί στην αρχική σελίδα. Για την ενίσχυση της εμπειρίας και αλληλεπίδρασης του χρήστη με την εφαρμογή πελάτη, διατίθενται πλαίσια διαλόγου για την επιβεβαίωση ενεργειών, που οριστικοποιούν αλλαγές στη βάση δεδομένων π.χ. DELETE, PUT, ή σφάλματα ταυτοποίησης. Για την αισθητική μορφοποίηση της εφαρμογής χρησιμοποιείται CSS μορφοποίηση. Στην δεύτερη επιλογή η CSS μορφοποίηση συνίσταται στη σχεδίαση με έντονο κοντράστ και συγκεκριμένη επιλογή χρωμάτων για την υποβοήθηση ατόμων με προβλήματα όρασης σύμφωνα με το πρότυπο WVAG 2.0, του World Wide Web Consortium. Τέλος, στην περίπτωση, που απαιτείται η δημιουργία κενών αρχείων, για μετέπειτα παρέμβαση προγραμματιστή, παρέχονται κενά αρχεία, τα οποία αποθηκεύονται στο φάκελο dev και φαίνονται στην Εικόνα 32. Για την υλοποίηση της αυτοματοποίησης της διαδικασίας παραγωγής κώδικα απαιτούνται συγκεκριμένες πληροφορίες σχετικά με τη δομή και τα στοιχεία της ζητούμενης προς κατανάλωση υπηρεσίας. Για την εφαρμογή των κανόνων της MDA αρχιτεκτονικής σε αυτή τη διαδικασία απαιτείται το σύνολο αυτής πληροφορίας να δοθεί σε συγκεκριμένη μορφοποίηση. Η μορφοποίηση, που χρησιμοποιείται σε αυτή τη διπλωματική εργασία, είναι το PSM μεταμοντέλο. Παράλληλα η γεννήτρια 61

63 θα πρέπει να παράγει εφαργμογές πελάτη σύμφωνες με το MVC πρότυπο. Για την επίτευξη αυτού του στόχου οι παραγόμενες εφαρμογές πελάτη απαρτίζονται από όψεις και ελεγκτές σε html και js γλώσσα προγραμματισμού αντίστοιχα. Σε αυτή την ενότητα θα γίνει μια σύντομη επισκόπηση της απαιτούμενης πληροφορίας για την πλήρη αυτοματοποίηση της διαδικασίας παραγωγής εφαρμογής πελάτη και του PSM μεταμοντέλου, που χρησιμοποιείται ως είσοδος στο Model to Text μετασχηματισμό, και των σχεδιαστικών απαιτήσεων και στόχων, που τίθενται από το S-CASE Απαιτούμενη πληροφορία Σε αυτή την ενότητα περιγράφονται όλα τα απαραίτητα στοιχεία, που θα πρέπει να παρέχει, το PSM μεταμοντέλο της υπηρεσίας, που παράχθηκε από το S-CASE. AnnotationStack Tο AnnotationStack στοιχείο συγκεντρώνει στο εσωτερικό του όλα τα διαφορετικά PSM μεταμοντέλα, που απαιτούνται για την παραγωγή του πελάτη. ServicePSM Το ServicePSM στοιχείο παρέχει την ονομασία της διαδικτυακής υπηρεσίας (name) καθώς και πλροφορίες για την παραμετροποίηση του διακομιστή. JavaResourceModel Το JavaResourceModel στοιχείο παρέχει την ονομασία του πόρου (parentname), τις ιδιότητες του πόρου (PSMComponentProperty) και ορίζει τους σχετικούς με αυτόν πόρους (hasrelatedjavarmmanager). JavaResourceController Το JavaResourceController στοιχείο παρέχει την ονομασία του πόρου (parentname), το URI για την ανάκτηση συγκεκριμένου στιγμιότυπου του πόρου (controlleruri) και πληροφορίες σχετικά με τις μεθόδους GET, PUT και DELETE του HTTP πρωτοκόλλου. JavaResourceControllerManager Το JavaResourceControllerManager στοιχείο παρέχει την ονομασία του πόρου (parentname), το URI για την ανάκτηση λίστας στιγμιότυπων του πόρου (controlleruri) και πληροφορίες σχετικά με τις HTTP μεθόδους Get και POST. JavaResourceModelManager 62

64 Σχεδίαση και ανάπτυξη διαδικτυακής εφαρμογής πελάτη για διαδικτυακές υπηρεσίες τύπου REST Το JavaResourceModelManager στοιχείο παρέχει την ονομασία του πόρου (parentname) και την ονομασία του στοιχείου για τη διερεύνηση της σχέσης του με άλλους πόρους (hasrelatedjavarmodel). PSMComponentProperty Το PSMComponentProperty στοιχείο περιέχεται στο JavaResouceModel και παρέχει την ονομασία της ιδιότητας του πόρου και τον τύπο της ιδιότητας. HTTPActivity Το HTTPActivity στοιχείο περιλαμβάνεται σε δύο κύρια στοιχεία το JavaResourceController και το JavaResourceControllerManager. Περιέχει πληροφορίες για τις επιτρεπτές HTTP μεθόδους για κάθε πόρο. Στην πρώτη περίπτωση περιγράφονται οι μέθοδοι GET, PUT και DELETE και στη δεύτερη περίπτωση περιγράφονται οι μέθοδοι GET και POST. Οι HTTP μέθοδοι σε κάθε περίπτωση ορίζονται σαν ιδιότητες του HTTPActivity με το στοιχείο HTTPActivityVerb. AuthenticationLayerPSM To AuthenticationLayerPSM στοιχείο περιέχει όλη την πληροφορία που απαιτείται για την ανάπτυξη μεθόδων ταυτοποίησης. AuthenticationPerformer To AuthenticationPerformer στοιχείο ορίζει τον πόρο, που θα χρησιμοποιηθεί για την ταυτοποίηση Στοιχεία PSM μεταμοντέλου PSM meta-model custom data types Σε αυτή την ενότητα θα περιγραφούν οι τύποι δεδομένων, που χρησιμοποιούν τα στοιχεία του PSM μεταμοντέλου. MediaType Ο τύπος δεδομένων MediaType είναι όλοι οι δυνατοί τύποι εισόδου και εξόδου, που υποστηρίζονται από το S-CASE. 63

65 Πίνακας 4: Υποστηριζόμενοι τύποι μέσων Media Type Relative HTTP Header value Προεπιλεγμένη τιμή JSON application/json Ναι XML Application/XML Όχι Επεξήγηση Όταν επιλέγεται ο JSON τύπος μέσου για έναν πόρο τότε το σχετικό διαδικτυακό API αναμένει ότι τα δεδομένα εισόδου και εξόδου θα είναι στη μορφή application/json Όταν επιλέγεται ο XML τύπος μέσου για έναν πόρο τότε το σχετικό διαδικτυακό API αναμένει ότι τα δεδομένα εισόδου και εξόδου θα είναι στη μορφή application/xml HTTPVerb Ο τύπος HTTPVerb μοντελοποιεί τις τέσσερις HTTP μεθόδους Post, Put, Get και Delete. Πίνακας 5: Τύποι HTTPVerb HTTP Verb Προεπιλεγμένη τιμή Επεξήγηση POST PUT GET DELETE Ναι Όχι Ναι Όχι Το POST verb μοντελοποιεί την μέθοδο POST του HTTP πρωτοκόλλου. Οπουδήποτε χρησιμοποιείται σέβεται το REST αρχιτεκτονικό στυλ και αναπαριστά τη διαδικασία δημιουργίας ενός πόρου. Το PUT verb μοντελοποιεί την μέθοδο PUT του HTTP πρωτοκόλλου. Οπουδήποτε χρησιμοποιείται σέβεται το REST αρχιτεκτονικό στυλ και αναπαριστά τη διαδικασία ανανέωσης ενός υπάρχοντος πόρου. Στην περίπτωση του S-CASE συστήματος το PUT verb δε χρησιμοποιείται για την δημιουργία πόρων. Το GET verb μοντελοποιεί την μέθοδο GET του HTTP πρωτοκόλλου. Οπουδήποτε χρησιμοποιείται σέβεται το REST αρχιτεκτονικό στυλ και αναπαριστά τη διαδικασία ανάκτησης ενός υπάρχοντος πόρου ή μιας λίστας υπαρχόντων πόρων. Το DELETE verb μοντελοποιεί την μέθοδο DELETE του HTTP πρωτοκόλλου. Οπουδήποτε χρησιμοποιείται σέβεται το REST αρχιτεκτονικό στυλ και αναπαριστά τη διαδικασία διαγραφής ενός συγκεκριμένου υπάρχοντος πόρου, όπως και των σχετικών απογόνων του πόρου. LinkType 64

66 Σχεδίαση και ανάπτυξη διαδικτυακής εφαρμογής πελάτη για διαδικτυακές υπηρεσίες τύπου REST Ο τύπος LinkType μοντελοποιεί τους τρεις τύπους συνδέσμων υπερμέσων, που υποστηρίζει το σύστημα S-CASE. Πίνακας 6: Τύποι LinkType Link Type Προεπιλεγμένη τιμή Επεξήγηση Parent Sibling Child Ναι Όχι Όχι Όταν ένα στοιχείο υπερμέσων έχει μια ιδιότητα με τον τύπο Parent μοντελοποιεί ένα σύνδεσμο από ένα πόρο Α σε έναν άλλο πόρο, ο οποίος έχει σαν σχετικό τον πόρο Α (related). Όταν ένα στοιχείο υπερμέσων έχει μια ιδιότητα με τον τύπο Sibling μοντελοποιεί ένα σύνδεσμο ενός πόρου με όλες τις δυνατές ενέργειες πάνω σε αυτόν τον πόρο. Όταν ένα στοιχείο υπερμέσων έχει μια ιδιότητα με τον τύπο Child μοντελοποιεί ένα σύνδεσμο από έναν πόρο Α σε έναν άλλο πόρο σχετικό (related) με τον πόρο Α Το ServicePSM στοιχείο Το στοιχείο ServicePSM αποτελεί το γονικό στοιχείο ενός PSM μεταμοντέλου και γι αυτό το λόγο θα πρέπει να υπάρχει αυστηρά ένα τέτοιο στοιχείο σε κάθε PSM μοντέλο, που παράγεται από το S-CASE. Περιλαμβάνει την εξειδικευμένη τεχνολογική μορφή όλων των στοιχείων, που συνθέτουν μία υπηρεσία τύπου REST, και σχετίζεται με αυτά τα στοιχεία μέσα από μία σύνθεση σχέσεων. Πιο συγκεκριμένα, κάθε στοιχείο του PSM μοντέλου θα πρέπει να περιέχεται σε αυτό το γονικό στοιχείο. Στη συνέχεια, θα περιγραφούν συνοπτικά οι ιδιότητες, οι σχέσεις αυτού του στοιχείου και κάποιους από τους περιορισμούς, που ορίζονται για αυτό το στοιχείο. Η εικόνα 30 παρουσιάζει ένα απλοποιημένο διάγραμμα του στοιχείου ServicePSM. 65

67 Εικόνα 33: Απλοποιημένο διάγραμμα του PSM μεταμοντέλου: Το στοιχείο ServicePSM Ιδιότητες Πίνακας 7: Ιδιότητες του στοιχείου ServicePSM Όνομα Τύπος Πολλαπλότητα Περιγραφή Name EString 1 Σχέσεις Αυτό είναι το όνομα, που παρέχεται από τον προγραμματιστή, για την υπηρεσία. Μεταξύ άλλων, χρησιμοποιείται για την ονομασία των φακέλων, που θα περιέχουν τα παραγόμενα αρχεία. Πίνακας 8: Σχέσεις του ServicePSM Σχέση με το PIM στοιχείο Τύπος Πολλαπλότητα Δομικοί Περιορισμοί JavaResourceModel σύνθεση 0..* Το ServicePSM μπορεί να περιέχει μηδέν ή και περισσότερα JavaResourceModels. Οποιοδήποτε JavaResourceModel υπάρχει 66

68 Σχεδίαση και ανάπτυξη διαδικτυακής εφαρμογής πελάτη για διαδικτυακές υπηρεσίες τύπου REST JavaResourceController σύνθεση 0..* JavaResourceModelManager σύνθεση 0..* JavaResourceControllerManager σύνθεση 0..* JavaAlgoResourceModel σύνθεση 0..* JavaAlgoController σύνθεση 0..* JPAController σύνθεση 1 στο PSM ανήκει στη λίστα των σχετιζόμενων JavaResourceModels του στοιχείου ServicePSM. Το ServicePSM μπορεί να περιέχει μηδέν ή και περισσότερα JavaResourceControllers. Οποιοδήποτε JavaResourceController υπάρχει στο PSM ανήκει στη λίστα των σχετιζόμενων JavaResourceControllers του στοιχείου ServicePSM. Το ServicePSM μπορεί να περιέχει μηδέν ή και περισσότερα JavaResourceModelManagers. Οποιοδήποτε JavaResourceModelManager υπάρχει στο PSM ανήκει στη λίστα των σχετιζόμενων JavaResourceModelManagers του στοιχείου ServicePSM. Το ServicePSM μπορεί να περιέχει μηδέν ή και περισσότερα JavaResourceControllerManagers. Οποιοδήποτε JavaResourceControllerManager υπάρχει στο PSM ανήκει στη λίστα των σχετιζόμενων JavaResourceControllerManagers του στοιχείου ServicePSM. Το ServicePSM μπορεί να περιέχει μηδέν ή και περισσότερα JavaAlgoResourceModels. Οποιοδήποτε JavaAlgoResourceModel υπάρχει στο PSM ανήκει στη λίστα των σχετιζόμενων JavaAlgoResourceModels του στοιχείου ServicePSM. Το ServicePSM μπορεί να περιέχει μηδέν ή και περισσότερα JavaAlgoControllers. Οποιοδήποτε JavaAlgoController υπάρχει στο PSM ανήκει στη λίστα των σχετιζόμενων JavaAlgoControllers του στοιχείου ServicePSM. Το στοιχείο ServicePSM θα πρέπει να περιέχει ακριβώς ένα στοιχείο JPAController. Περιορισμοί συμπεριφοράς Όσον αφορά στους περιορισμούς συμπεριφοράς θα αναφερθούν οι περιορισμοί εκείνοι, που θεωρήθηκαν απαραίτητοι για την υλοποίηση της παρούσας διπλωματικής. 67

69 allmodelshaverresourcepropertieswithproperjpaannotations: Για την ορθή αναπαραγωγή του σχεσιακού σχήματος απαιτείται η εισαγωγή ενός OCL περιορισμού. Αυτός ο περιορισμός διασφαλίζει ότι κάθε JavaResourceModel στοιχείο, που υπάρχει στο PSM μοντέλο, διαθέτει όλες τις απαιτούμενες ιδιότητες Java, που απαιτούνται από το JPA πρότυπο. Επίσης, διασφαλίζει ότι αυτές οι ιδιότητες διαθέτουν τα κατάλληλα JPA allmodelshavepresourcepropertieswithproperjpaannotations: Για την ορθή αναπαραγωγή του σχεσιακού σχήματος απαιτείται η εισαγωγή ενός OCL περιορισμού. Αυτός ο περιορισμός διασφαλίζει ότι κάθε JavaResourceModel στοιχείο, που υπάρχει στο PSM μοντέλο, διαθέτει όλες τις απαιτούμενες ιδιότητες Java, που απαιτούνται από το JPA πρότυπο. Επίσης, διασφαλίζει ότι αυτές οι ιδιότητες διαθέτουν τα κατάλληλα JPA RControllerUniqueHTTPVerbsPerParent: Ο συγκεκριμένος OCL περιορισμός διασφαλίζει ότι οποιοδήποτε JavaResourceController στοιχείο έχει το πολύ ένα HTTPActivity για κάθε επιτρεπτό HTTPVerb (GET, PUT, DELETE) ανά πόρο με τον οποίο σχετίζεται. RCManagerHasUniqueHTTPVerbsPerParent: Ο συγκεκριμένος OCL περιορισμός διασφαλίζει ότι οποιοδήποτε JavaResourceController στοιχείο έχει το πολύ ένα HTTPActivity για κάθε επιτρεπτό HTTPVerb (GET, POST) ανά πόρο με τον οποίο σχετίζεται. Περισσότερες πληροφορίες σχετικά με το PSM μεταμοντέλο παρέχονται στο παραδοτέο του S-CASE «D2.2 Definition of Platform Independent and Platform Specific Service Models». 4.5 Acceleo μετασχηματισμός PSM μοντέλου σε κώδικα Σε αυτή την ενότητα θα παρουσιαστεί ο Acceleo μετασχηματισμός του PSM μοντέλου, που παρήχθηκε από την S-CASE πλατφόρμα, σε κώδικα για την ανάπτυξη διαδικτυακής εφαρμογής πελάτη, που καταναλώνει διαδικτυακές υπηρεσίες τύπου REST Συστατικά στοιχεία ενός έργου Acceleo Ένα έργο Acceleo είναι ένα Java έργο και Eclipse plug-in. Τα αρχεία, που χρησιμοποιούνται για την παραγωγή, ονομάζονται modules και θα πρέπει να τοποθετούνται μέσα σε πακέτα Java, όπως ακριβώς συμβαίνει με τις κλάσεις Java. Module Μία γεννήτρια Acceleo συντίθεται από πολλά modules. Ένα module παραμετροποιείται από τα URIs των μετα-μεταμοντέλων, δημιουργώντας στιγμιότυπα των μοντέλων από τα οποία θα παραχθεί κώδικας. 68

70 Σχεδίαση και ανάπτυξη διαδικτυακής εφαρμογής πελάτη για διαδικτυακές υπηρεσίες τύπου REST Templates Τα templates αποτελούν την πιο σύνηθη δομή, που χρησιμοποιείται στο Acceleo, για την άμεση παραγωγή κώδικα. Ο Αλγόριθμος 1 παρουσιάζει ένα απλό παράδειγμα ενός template. Αλγόριθμος 1: Σύνταξη ενός απλού acceleo template [module modulename(' [template public genmytemplate(aparam: EClass)] this is a static piece of code [aparam.name/] [/template] Όπως φαίνεται και στο παραπάνω παράδειγμα, τα templates διαθέτουν προσδιορισμούς (public, protected, private) για την προσβασιμότητά τους, όπως ακριβώς οι αντικειμενοστραφείς γλώσσες προγραμματισμού. Στη συνέχεια φαίνεται το όνομα του template και οι παράμετροι του. Οι επιτρεπτοί τύποι παραμέτρων είναι τύποι μεταμοντέλων και προεπιλεγμένοι τύποι της OCL γλώσσας προγραμματισμού (String, Boolean, Integer κ.α.). Για την παραγωγή κώδικα διατίθενται δύο είδη σύνταξης. Το πρώτο είδος είναι οι στατικές εκφράσεις, οι οποίες απλώς αναπαράγονται χωρίς να περάσουν από κάποιο μετασχηματισμό. Το δεύτερο είδος είναι οι εκφράσεις Acceleo, οι οποίες χρησιμοποιούν τα στοιχεία των μοντέλων για να υπολογιστεί το παραγόμενο κείμενο. Κύριο template Το κύριο template είναι το σημείο εισόδου της γεννήτριας και διαθέτει το αναγνωριστικό σχόλιο «@main» στο εσωτερικό του. Μέσα από αυτό το template καλούνται όλα τα υπόλοιπα templates για την συνολική υλοποίηση του μετασχηματισμού. File block Οι μετασχηματισμοί και ο κώδικας, που χρειάζονται να καταγραφούν σε ένα αρχείο, περιγράφονται μέσα σε file blocks. Τα file blocks περιέχουν τρεις παραμέτρους: Μία έκφραση που επιστρέφει ένα string για το όνομα του παραγόμενου αρχείου. 69

71 Μία Boolean παράμετρο, που υποδεικνύει εάν τα υπάρχοντα αρχεία πρέπει να αντικατασταθούν από τα νέα, που θα παραχθούν ή αν θα πρέπει να συνεχίσουν από το τέλος των υπάρχοντων αρχείων. Την κωδικοποίηση των αρχείων. Δομές Το Acceleo διαθέτει μια σειρά από εκφράσεις για τη διαχείρηση των στοιχείων των μοντέλων. If block Το template μπορεί να χρησιμοποιεί if μπλοκ για να ορίσει κομμάτια κώδικα, τα οποία θα πρέπει να υλοποιηθούν μόνο όταν επαληθεύεται η δοσμένη συνθήκη. For block Ένα for μπλοκ χρησιμοποιείται για την διαδοχική προσέγγιση συλλογών στοιχείων. Let block Ένα let μπλοκ επιτρέπει τον ορισμό μίας μεταβλητής στο εσωτερικό του μπλοκ. Query Τα queries χρησιμοποιούνται για να ορίσουν σύνθετες εκφράσεις, οι οποίες μπορούν να χρησιμοποιηθούν σε διάφορα σημεία μέσα στη γεννήτρια. 70

72 Σχεδίαση και ανάπτυξη διαδικτυακής εφαρμογής πελάτη για διαδικτυακές υπηρεσίες τύπου REST Στοιχεία του Acceleo μετασχηματισμού Για την παραγωγή της διαδικτυακής εφαρμογής πελάτη απαιτείται η παραγωγή μιας σειράς αρχείων με είσοδο στοιχεία του PSM μοντέλου, που κάθε φορά επιθυμεί ο προγραμματιστής/χρήστης. Τα επιθυμητά αρχεία προέρχονται από αρχεία μετασχηματισμού, τα οποία ονομάζονται modules. Στη συνέχεια, θα περιγραφούν όλα τα modules, τα οποία αναπτύχθηκαν στα πλαίσια αυτής της διπλωματικής εργασίας, οι είσοδοι και οι έξοδοι του κάθε module και οι συναρτήσεις, που χρησιμοποιήθηκαν μέσα στα modules. Στον πίνακα 9 παρατίθενται συνοπτικά, όλα τα modules, οι είσοδοι και οι έξοδοί τους, ενώ στο σχήμα 31 περιγράφεται η γενική δομή της εξόδου της γεννήτριας. Όπως φαίνεται και στο σχεδιάγραμμα 31, τα παραγόμενα αρχεία αποθηκεύονται μέσα στο Main Folder, ο οποίος παίρνει την εκάστοτε ονομασία της υπηρεσίας για την οποία παράγεται η εφαρμογή συνοδευόμενη από τη λέξη Client. Ο κύριος φάκελος περιέχει τον φάκελο js, views και το αρχείο index.html. Υποφάκελος js Ο υποφάκελος js περιέχει όλα τα αρχεία, που είναι γραμμένα σε Javascript. Πιο συγκεκριμένα, ο υποφάκελος js περιέχει τους ελεγκτές Εικόνα 34: Γενική δομή των παραγόμενων εφαρμογών πελάτη της διαδικτυακής εφαρμογής πελάτη (π.χ. ResourceCtrl.js), το αρχείο services.js και το αρχείο app.js. Στην απλούστερη εκδοχή της εφαρμογής δημιουργείται ένας ελεγκτής ανά πόρο. Στην περίπτωση που η αρχική σελίδα πρέπει να εμφανίζει περισσότερους από έναν πόρους, που δεν είναι σχετικοί από άλλους, δημιουργείται το αρχείο frontctrl.js. Το συγκεκριμένο αρχείο περιέχει όλο τον απαραίτητο κώδικα για την λειτουργία των στοιχείων του front.html αρχείου και για την αποστολή αιτημάτων και την επεξεργασία της απόκρισης του διακομιστή για κάθε πόρο, που πρέπει να εμφανίζεται. Σε αυτή την περίπτωση θα πρέπει να σημειωθεί ότι η διαδικασία παραγωγής ελεγκτών για τους πόρους, που περιέχονται στην αρχική σελίδα, παρακάμπτεται, αφού αυτοί εξυπηρετούνται από τον γενικό ελεγκτή frontctrl.js. Τέλος, στην περίπτωση που η επιθυμητή εφαρμογή πελάτη χρειάζεται και διαδικασίες ταυτοποίησης παράγεται ένας ελεγκτής με την ονομασία LoginCtrl.js. 71

73 Υποφάκελος views Ο υποφάκελος views περιέχει αρχεία HTML, τα οποία είναι οι όψεις, τις οποίες επιλέγει να εμφανίσει το index.html ανάλογα με τις κατευθύνσεις, που δίνει το app.js. Όπως περιγράφηκε και παραπάνω για την εξυπηρέτηση των περιπτώσεων, όπου στην αρχική σελίδα πρέπει να εμφανίζονται πολλαπλοί πόροι, δημιουργείται και σε αυτό τον υποφάκελο η αντίστοιχη όψη με την ονομασία front.html. Αντίστοιχα, η παραγωγή όψεων για τους πόρους, που εντάσσονται στο αρχείο front.html, παραλείπεται. Στην περίπτωση, όπου απαιτείται ταυτοποίηση, παράγεται και το αρχείο SignIn.hmlt, το οποίο περιέχει την όψη για την εισαγωγή των στοιχείων ταυτοποίησης. Index.html Το αρχείο index.html περιέχει τη CSS μορφοποίηση της εφαρμογής πελάτη και την τοποθεσία των απαραίτητων για τη λειτουργία της εφαρμογής πελάτη βιβλιοθηκών. Πίνακας 9: Επισκόπηση των modules του μετασχηματισμού, των εισόδων τους και των τύπων των παραγόμενων αρχείων Όνομα generate Index Είσοδος AnnotationStack AnnotationStack Τύπος αρχείου εξόδου Δεν παράγεται αρχείο HTML αρχείο Πολλαπλότητα Εξόδου Views AnnotationStack HTML αρχείο 1..* Ctrls AnnotationStack JS αρχείο 1..* Services AnnotationStack JS αρχείο 1 App AnnotationStack JS αρχείο 1 Auth AnnotationStack JS και HTML αρχείο 2 Dev AnnotationStack HTML 0..* Module generate Το module generate δέχεται ως είσοδο το στοιχείο ServicePSM. Αποτελεί τη main κλάση του μετασχηματισμού και δεν παράγει καμία έξοδο. Ρόλος αυτού του module είναι η κλήση των επιμέρους modules, για την παραγωγή των απαιτούμενων αρχείων. Module Index 72

74 Σχεδίαση και ανάπτυξη διαδικτυακής εφαρμογής πελάτη για διαδικτυακές υπηρεσίες τύπου REST Το module Index δέχεται ως είσοδο το στοιχείο AnnotationStack και παράγει ένα HTML αρχείο. Το παραγόμενο αρχείο περιέχει τις διευθύνσεις για όλες τις βιβλιοθήκες, που χρειάζεται η διαδικτυακή εφαρμογή πελάτη για να λειτουργήσει και ονομάζεται index.html. Επίσης, σε αυτό το αρχείο ορίζονται όλα τα στοιχεία CSS, που χρησιμοποιούνται για την μορφοποίηση της εφαρμογής. Παράλληλα, περιέχεται η κύρια διάταξη της εφαρμογής και ο ρόλος του είναι εμφανίζει το κατάλληλο template/όψη σύμφωνα με τις ρυθμίσεις του $route service [48]. Ως αρχικό template/όψη, ορίζεται το template/όψη του πόρου εκείνου, που δεν είναι σχετικός από άλλους πόρους. Στην περίπτωση, που η συνθήκη αυτή ισχύει για περισσότερους από έναν πόρους παράγεται και ένα δεύτερο HTML αρχείο, που ορίζεται ως το αρχικό template που θα εμφανίζει το index.html. Το δεύτερο αυτό αρχείο ονομάζεται front.html και η διαφοροποίηση του έγκειται στη διαφορετική μορφοποίηση για την εμφάνιση όλων των πόρων, που χρειάζεται να εμφανίζονται στην αρχική σελίδα. Πιο αναλυτικά, θα παρουσιαστούν όλες οι Acceleo εκφράσεις, που χρησιμοποιήθηκαν για την ανάκτηση πόρων από το PSM μεταμοντέλο για την παραγωγή του επιθυμητού κώδικα. Ανάκτηση πλήθους πόρων προς εμφάνιση στην αρχική σελίδα Το module Index περιέχει τον έλεγχο για τον αριθμό των πόρων, που πρέπει να εμφανίζονται στην αρχική σελίδα. Ο έλεγχος αυτός πραγματοποιείται με τη χρήση ενός if μπλοκ με τη συνθήκη anannotationstack.toplayer()->size()>1. Το TopLayer στοιχείο αποτελεί ένα query και η λειτουργία του θα περιγραφεί στο τέλος της ενότητας. Εάν στην αρχική σελίδα εμφανίζεαται μόνο ένας πόρος, τότε η συνθήκη δεν επαληθεύεται και παράγεται μόνο το αρχείο index.html. Εάν η συνθήκη επαληθεύεται, τότε δημιουργείται το αρχείο front.html και το αρχείο index.html. Παράλληλα, ο έλεγχος αυτός υλοποιείται και για την εγγραφή του αντίστοιχου frontctr.js στη λίστα των scripts, που πρέπει να εμφανίζονται στο index μιας εφαρμογής πελάτη. Επίσης, μια επαναληπτική διαδικασία για την εγγραφή και όλων των υπόλοιπων ελεγκτών των πόρων στη λίστα των scripts. Στον Αλγόριθμο 2 φαίνεται η σύνταξη του if και for μπλοκ. Συγκεκριμένα, το for μπλοκ προσεγγίζει διαδοχικά τον κάθε πόρο του οργανωμένου σετ τύπου JavaResourceModelManager, που προέκυψε από το query otherlayer, και το p είναι η μεταβλητή, στην οποία καταχωρείται ο πόρος του συγκεκριμένου κύκλου επανάληψης. Με την έκφραση [p.parentname/] ορίζει ότι πρέπει να αντικατασταθεί με την ιδιότητα parentname του p. Αλγόριθμος 2: Έλεγχος πλήθους πόρων για την αρχική σελιδα και επαναληπτική διαδικασία [for (p: JavaResourceModelManager anannotationstack.otherlayer())] <script src="js/[p.parentname/]ctrl.js"></script> 73

75 [/for] [if (anannotationstack.toplayer()->size()>1)] <script src="js/frontctrl.js"></script>[else] <script src="js/[anannotationstack.toplayer().parentname/]ctrl.js"></script>[/if] Για κάθε anannotationstack.otherlayer() του τύπου JavaResourceModelManager ανάκτησε το parentname του. Στη συνέχεια, αν τα στοιχεία του anannotationstack.otherlayer() είναι περισσότερα από ένα εισήγαγε το string <script src="js/frontctrl.js"></script>, αλλιώς ανάκτησε το parentname του anannotationstack.otherlayer(). Ανάκτηση ιδιοτήτων πόρων για εμφάνιση στην αρχική σελίδα Για την παραγωγή ορθού λογικά και συντακτικά κώδικα απαιτείται η αναπαραγωγή συγκεκριμένων κομματιών στατικού κειμένου και Acceleo εκφράσεων για την αναραγωγή κωδικα για κάθε απαιτούμενο πόρο μέσα στο ίδιο αρχείο. Στο συγκεκριμένο module μία από αυτές τις επαναληπτικές διαδικασίες, που συντάχθηκαν, είναι αυτή, που φαίνεται στον Αλγόριθμο 3. Αλγόριθμος 3: Επαναληπτική διαδικασία για την ανάκτηση πόρων προς εμφάνιση στην αρχική σελίδα [for (layer: JavaResourceModelManager anannotationstack.toplayer())][for (p: JavaResourceModel anannotationstack.hascorepsm.hasjavarmodel- >asorderedset())][if (p.parentname=layer.parentname)] <div class="w3-third"> <div class="w3-card-2 w3-padding-top" style="min-height:120px"> <h4>[p.parentname.toupperfirst()/]</h4><br> <i class="fa fa-desktop w3-margin-bottom w3-text-theme" style="fontsize:120px"></i> </div> <button class="w3-btn-block w3-dark-grey" ngclick="chosen[p.parentname.toupperfirst()/]=true">see More</button> </div> [/if][/for][/for] Για κάθε anannotationstack.toplayer() του τύπου JavaResourceModelManager, που θα έχει την ονομασία layer, και για κάθε anannotationstack.hasecorepsm.hasjavarmodel του τύπου JavaResourceModel, που θα δομηθεί σαν OrderedSet, αν το p.parentname ταυτίζεται με το layer.parentname τότε εισήγαγε το παρακάτω. 74

76 Σχεδίαση και ανάπτυξη διαδικτυακής εφαρμογής πελάτη για διαδικτυακές υπηρεσίες τύπου REST Το for μπλοκ [for (layer: JavaResourceModelManager anannotationstack.toplayer())][/for] είναι αντίστοιχης λογικής με αυτό, που περιγράφηκε παραπάνω χρησιμοποιώντας διαφορετικό όνομα μεταβλητής (layer αντί για p) και άλλο query (toplayer αντί για otherlayer). Τα αντίστοιχα ισχύουν και για την εμφωλευμένη επαναληπτική διαδικασία. Στόχος αυτού του κώδικα είναι να μπορέσει να εντοπίσει τα JavaResouceModels των πόρων εκείνων, που πρέπει να εμφανίζονται στην αρχική σελίδα. Ανάκτηση πόρων για μεθόδους PUT και DELETE Συνήθως, η χρήση ή μη των μεθόδων PUT και DELETE διαφέρει από πόρο σε πόρο σε μία υπηρεσία. Επομένως πρέπει να υπάρχει ο αντίστοιχος έλεγχος για την παραγωγής ή όχι κώδικα για τις μεθόδους αυτές για κάθε πόρο ξεχωριστά. Ένα παράδειγμα ελέγχου φαίνεται στον Αλγόριθμο 4. Για τον έλεγχο χρησιμοποιείται ένα let μπλοκ, το οποίο καταχωρεί στη μεταβλητή e το string PUT για τον αντίστοιχο έλεγχο για την μέθοδο DELETE καταχωρείται το string DELETE. Οι επαναληπτικές διαδικασίες, που χρησιμοποιούνται, έχουν στόχο τον εντοπισμό του αντίστοιχου στοιχείου JavaResourceController των πόρων, που πρέπει να εμφανίζονται στην πρώτη σελίδα. Μέσα σε κάθε στοιχείο τύπου JavaResourceController πρέπει να εντοπιστούν τα HTTPActivityVerbs, που διαθέτει. Αυτό γίνεται με την εμφωλευμένη επαναληπτική διαδικασία. Τέλος, θα πρέπει να πραγματοποιηθεί ένας έλεγχος if ώστε ο κώδικας να παραχθεί έως και μόνο μία φορά, ανεξαρτήτως εάν υπάρχουν πολλαπλές PUT ή πολλαπλές DELETE μέθοδοι για τον υπό εξέταση πόρο. Η συνθήκη επαληθεύεται μόνο εάν το HTTPActivityVerb ταυτίζεται με το string e, το parentname του c ταυτίζεται με το parentname του p και το name του HTTPActivity αυτού του κύκλου επανάληψης ταυτίζεται με το name του πρώτου στοιχείου της λίστας των HTTPActivities, που έχουν την ίδια μέθοδο και ανήκουν στο ίδιο JavaResourceController στοιχείο. Η τελευταία συνθήκη ελέγχεται με τη βοήθεια του query firstonly, το οποίο θα αναλυθεί στο τέλος της ενότητας. Αλγόριθμος 4: Ανάκτηση πόρων στους οποίους επιτρέπεται η PUT μέθοδος [let e: String = 'PUT'] [for (c: JavaResourceController aservicepsm.hasjavarcontroller )] [for (d: HTTPActivity c.javarcontrollerhashttpactivity)] [if (d.activityhttpverb.tostring()=e and c.parentname = p.parentname and self.name=c.firstonly(d.activityhttpverb.tostring()))] <td><input type="button" class="button" ngclick="edit[p.parentname.toupperfirst()/]([p.parentname/].idtype)" value="edit"></td> [/if] [/for] [/for] 75

77 [/let] Όρισε το στοιχείο e, που είναι τύπου String, το PUT. Στη συνέχεια για κάθε aservicepsm.hasjavarcontroller του τύπου JavaResourceController και για κάθε c.javarcontrollerhashttpactivity του τύπου HTTPActivity αν το d.activityhttpverb, μετασχηματισμένο σε string, ταυτίζεται με το e και το c.parentname ταυτίζεται με το p.parentname και το self.name ταυτίζεται με το αποτέλεσμα του query firstonly, με παράμετρους c και d.activityhttpverb.tostring(). Ανάκτηση πόρων σχετικών από πόρο Για να καταστεί δυνατή η πλοήγηση μέσα στην εφαρμογή πελάτη, θα πρέπει να υπάρχουν τα στοιχεία εκείνα που οδηγούν τον χρήστη από πόρο σε σχετικό πόρο. Επομένως, για κάθε πόρο, που έχει σχετικούς από αυτόν πόρους, πρέπει να εμφανίζεται στη σελίδα του ένα κουμπί με την επιλογή μετάβασης στον σχετικό από αυτόν πόρο. Ένα παράδειγμα αυτής της διαδικασίας εμφανίζεται στον αλγόριθμο 5. Μια επαναληπτική διαδικασία υλοποιείται για την διαδοχική προσέγγιση των πόρων, που είναι σχετικοί από τον υπό επεξεργασία πόρο. Το πλήθος και τα στοιχεία των σχετικών πόρων δίνονται από το query setofintesection σε μορφή δομημένου συνόλου (asorderedset), το οποίο θα αναλυθεί στο τέλος της ενότητας. Είναι προφανές ότι στην περίπτωση που δεν υπάρχουν σχετικοί πόροι η αναπαραγωγή του κώδικα στο εσωτερικό του for μπλοκ παραλείπεται. Αλγόριθμος 5: Επαναληπτική διαδικασία για την ανάκτηση πόρων σχετικών από πόρο [for (c: JavaResourceModelManager anannotationstack.relatedresource(p))] <td><input type="button" class="button" ngclick="choose[c.anannotationstack.relatedresource(p).parentname.toupperfirst()/]([ p.parentname/].idtype)" value="[c.anannotationstack.relatedresource(p).parentname.toupperfirst()/]"></td> [/for] Για κάθε anannotationstack.relatedresource(p) τύπου JavaResourceModelManager εισήγαγε το παρακάτω κείμενο και εισήγαγε το c.anannotationstack.relatedresource(p) με κεφαλαίο το αρχικό γράμμα. 76

78 Σχεδίαση και ανάπτυξη διαδικτυακής εφαρμογής πελάτη για διαδικτυακές υπηρεσίες τύπου REST 77

79 Ανάκτηση ιδιοτήτων πόρου Για την εμφάνιση μίας αναλυτικής λίστας με τα στοιχεία ενός πόρου απαιτείται η ανάκτηση των ιδιοτήτων του. Η πληροφορία αυτή περιέχεται στα PSMComponentProperties του κάθε JavaResourceModel στοιχείου. Ένα τέτοιο παράδειγμα φαίνεται στον Αλγόριθμο 6, όπου το αποτέλεσμα είναι να εμφανίζονται διαδοχικά όλα τα name των PSMComponentProperties, που έχουν τύπο String, του p στοιχείου τύπου JavaResourceModel. Αλγόριθμος 6: Επαναληπτική διαδικασία για την ανάκτηση ιδιοτήτων του πόρου [for (c: PSMComponentProperty p.javarmodelhasproperty)][if (c.type='string')] <tr> <td><h5>[c.name.toupperfirst()/]</h5></td><td><h5>{{[p.parentname/].[c.name/]}}</h 5></td> </tr> [/if][/for] Για κάθε p.javarmodelhasproperty τύπου PSMComponentProperty αν το c.type ταυτίζεται με το String τότε εισήγαγε το παρακάτω. Ανάκτηση τύπου PSMComponentProperty Συχνά υπάρχουν περιπτώσεις, όπου ο χρήστης θα πρέπει να συμπληρώσει κωδικούς σε φόρμες, είτε για τη δημιουργία/τροποποίηση λογαρισμού είτε για την ταυτοποίηση των στοιχείων του. Η γεννήτρια παραγωγής εφαρμογών πελάτη έχει τη δυνατότητα να αναγνωρίζει τις περιπτώσεις, όπου πρέπει να εισαχθεί κωδικός, και αποκρύπτει τα στοιχεία του κωδικού κατά την εισαγωγή του με κουκίδες. Στη συνέχεια ακολουθεί ένα παράδειγμα, που υλοποιεί αυτή τη λειτουργία. Αλγόριθμος 7: Έλεγχος για την κατάλληλη μορφοποίηση στην περίπτωση εισαγωγής κωδικού ή κειμένου <input type="[if (c.name='password')]password[else]text[/if]" Αν το c.name ταυτίζεται με το password τότε εισήγαγε password αλλιώς text. 78

80 Σχεδίαση και ανάπτυξη διαδικτυακής εφαρμογής πελάτη για διαδικτυακές υπηρεσίες τύπου REST Ανάκτηση πόρων για την επιλογή CSS μορφοποίησης Για την ευκολότερη πλοήγηση μέσα σε μία εφαρμογή πελάτη και την όσο το δυνατόν πιο κατανοητή παρουσίαση των στοιχείων της απαιτείται και η κατάλληλη μορφοποίηση της εφαρμογής. Στη συγκεκριμένη εφαρμογή δίνονται δύο επιλογές μορφοποίησης, όπου μία είναι η Default μορφοποίηση και η άλλη μία μορφοποίηση πιο φιλική σε χρήστες με προβλήματα όρασης με την ονομασία Vision Impaired. Παρακάτω φαίνεται ο τρόπος επιλογής. Αλγόριθμος 8: Έλεγχος για την εισαγωγή CSS μορφοποίησης [if (anannotationstack.cssselection='default')].button{ background-color: #00cc99; border: none; color: white; border-radius: 4px; text-align: center; text-decoration: none; display: inline-block; font-size: 16px;} [else] button =.button{ background-color: #374c59; border: none; color: #fcc7ad; border-radius: 4px; text-align: center; text-decoration: none; display: inline-block; font-size: 20px; }[/if] Αν το CSSSelection του anannotationstack είναι ίσο με το Default τότε εισήγαγε το sting, που ακολουθεί, αλλιώς εισήγαγε το άλλο string. Module Views Το module Views δέχεται ως είσοδο το στοιχείο AnnotationStack και παράγει ένα HTML αρχείο για κάθε JavaResourceModel στοιχείο, που περιγράφεται στο προς μετασχηματισμό PSM μοντέλο. Τα παραγόμενα αρχεία είναι τα templates/όψεις, τα οποία εμφανίζει το index αρχείο ανάλογα με τις επιλογές πλοήγησης του χρήστη, και περιγράφουν τον τρόπο με τον οποίο θα παρουσιάζονται τα δεδομένα της διαδικτυακής υπηρεσίας, που καταναλώνεται από τον πελάτη. Όταν υπάρχουν 79

81 περισσότεροι από ένας πόροι, που θα πρέπει να εμφανίζονται στην αρχική σελίδα, τότε το module Views δεν παράγει για τους συγκεκριμένους πόρους όψεις. Ενώ, όταν απαιτείται ταυτοποίηση θα εμφανίζεται αρχικά μία όψη για την εισαγωγή των στοιχείων ταυτοποίησης και για τη δημιουργία νέου λογαριασμού, εάν δε διατίθενται στοιχεία ταυτοποίησης. Στη συνέχεια θα παρουσιαστούν οι Acceleo εκφράσεις, που χρησιμοποιήθηκαν για την ανάκτηση πόρων από το PSM μεταμοντέλο. Ανάκτηση πόρων για τη δημιουργία όψεων Για τη δημιουργία όψεων για κάθε πόρο απαιτείται η ανάκτηση πληροφοριών για τον πόρο, οι οποίες περιέχονται στα στοιχεία τύπου JavaResourceModel. Επίσης, όπως αναφέρθηκε παραπάνω υπάρχει η περίπτωση κάποιοι πόροι να περιγράφονται από την όψη front.html, σε αυτή την περίπτωση θα πρέπει να υπάρχει συγκεκριμένη μνεία από τη γεννήτρια για την αποφυγή επικαλυπτόμενων όψεων. Αυτό επιτυγχάνεται μέσω της παρακάτω έκφρασης, όπου τα parentname των στοιχείων p τύπου JavaResourceModel οργανώνονται ως δομημένη λίστα και συγκρίνονται διαδοχικά με το parentname των στοιχείων layer τύπου JavaResourceModelManager. Τα στοιχεία p οργανώνονται ως δομημένη λίστα για να είναι δυνατή η σύγκριση, διότι η έξοδος του query otherlayer είναι μία δομημένη λίστα. Όταν η συνθήκη επαληθεύεται δημιουργείται μία όψη για τον υπό επεξεργασία πόρο. Παράλληλα, χρησιμοποιώντας το λογικό or ελέγχεται εάν υπάρχει μόνο ένας πόρος, που πρέπει να εμφανίζεται στην αρχική σελίδα, τότε παράγεται κανονικά η όψη του. Αλγόριθμος 9: Ανάκτηση πόρων για την δημιουργία όψεων [for (p: JavaResourceModel anannotationstack.hascorepsm.hasjavarmodel- >asorderedset)] [if (anannotationstack.otherlayer()->collectnested(parentname)->flatten()- >includes(p.parentname) or (anannotationstack.toplayer()->size()=1 and anannotationstack.toplayer()->at(1).parentname=p.parentname))] [file ('/' + anannotationstack.hascorepsm.name + 'Client/views/' + p.parentname + '.html', false, 'UTF-8')]... [/file] [/if] [/for] Για κάθε anannotationstack.hascorepsm.hasjavarmodel του τύπου JavaResourceModel, που θα δομηθεί ως OrderedSet, αν οι γόνοι parentname του anannotationstack.otherlayer() περιέχουν το 80

82 Σχεδίαση και ανάπτυξη διαδικτυακής εφαρμογής πελάτη για διαδικτυακές υπηρεσίες τύπου REST p.parentname ή το anannotationstack.toplayer() περιέχει μόνο ένα στοιχείο και το parentname του anannotationstack.toplayer() ταυτίζεται με το p.parenname, τότε δημιούργησε το αρχείο html με το όνομα p.parentname στη διαδρομή /anannotationstack.hascorepsm.name Client/ views/. Ανάκτηση πόρων για μεθόδους PUT και DELETE Η διαδικασία είναι πανομοιότυπη με την αντίστοιχη του module Index και για το λόγο αυτό δε θα αναλυθεί περαιτέρω. Ανάκτηση πόρων σχετικών με τον πόρο Για την παροχή της δυνατότητας σε ένα χρήστη να επιστρέφει στον προηγούμενο πόρο, δηλαδή στην προηγούμενη σελίδα, απαιτείται η ανάκτηση των πόρων, που είναι σχετικοί με τον πόρο. Ένα παράδειγμα φαίνεται στον παρακάτω αλγόριθμο, όπου πραγματοποιείται ένας έλεγχος για κάθε στοιχείο JavaresourceControllerManager εάν η ιδιότητα του hasassociatedrmmanager υπάρχει στη λίστα των στοιχείων hasrelatedjavarmmanager του hasjavarmodel και εάν το parentname του c ταυτίζεται με το parentname του p. Όταν η συνθήκη επαληθεύεται προστίθεται στην όψη ένα κουμπί Back, που ενεργοποιεί τη συνάρτηση Back(). Αλγόριθμος 10: Ανάκτηση πόρων σχετικών με πόρο για τη δημιουργία του κουμπιού Back [for (c: JavaResourceControllerManager anannotationstack.hascorepsm.hasjavarcmanager)][if (anannotationstack.hascorepsm.hasjavarmodel.hasrelatedjavarmmanager- >includes(c.hasassociatedrmmanager) and c.parentname=p.parentname)]<input type="button" class="button" value="back" ng-click="back()">[/if][/for] Για κάθε anannotationstack.hascorepsm.hasjavarcmanager τύπου JavaResourceControllerManager αν στη λίστα anannotationstack.hascorepsm.hasjavarmodel.hasrelatedjavarmmanager περιέχεται το c.hasassociatedrmmanager και το c.parentname ταυτίζεται με το p.parentname τότε εισήγαγε το ακόλουθο κείμενο. Ανάκτηση πόρων σχετικών με τον πόρο Η διαδικασία είναι πανομοιότυπη με την αντίστοιχη του module Index και για το λόγο αυτό δε θα αναλυθεί περαιτέρω. 81

83 Ανάκτηση ιδιοτήτων πόρου Η διαδικασία είναι πανομοιότυπη με την αντίστοιχη του module ndex και για το λόγο αυτό δε θα αναλυθεί περαιτέρω. Ανάκτηση τύπου PSMComponentProperty Η διαδικασία είναι πανομοιότυπη με την αντίστοιχη του module Index και για το λόγο αυτό δε θα αναλυθεί περαιτέρω. Module Ctrls Το module Ctrls δέχεται ως είσοδο το στοιχείο AnnotationStack και παράγει ένα JS αρχείο για κάθε JavaResourceControllerManager στοιχείο, που περιγράφεται στο προς μετασχηματισμό PSM μοντέλο. Τα παραγόμενα αρχεία αποτελούν τους ελεγκτές του κάθε αντίστοιχου template/όψης και διαχειρίζονται όλες τις απαραίτητες ενέργειες για τη λειτουργία της διαδικτυακής εφαρμογής πελάτη. Οι ελεγκτές είναι αρμόδιοι για την αποστολή των αιτημάτων και την διαχείριση των αποκρίσεων του διακομιστή. Αντίστοιχα με το module Views, όταν υπάρχουν περισσότεροι του ενός πόροι, που θα πρέπει να εμφανίζονται στην αρχική σελίδα, τότε το module Ctrls παραλείπει την παραγωγή ελεγκτών για τους συγκεκριμένους πόρους, αλλά παράγει έναν συνολικό ελεγκτή με το όνομα frontctrl.js, ο οποίος διαχειρίζεται τους πόρους του front.html αρχείου. Ανάκτηση πόρων για τη δημιουργία ελεγκτών Η διαδικασία είναι πανομοιότυπη με την αντίστοιχη διαδικασία για την ανάκτηση πόρων για τη δημιουργία όψεων του module Views και για το λόγο αυτό δε θα αναλυθεί περαιτέρω. Ανάκτηση πόρων για τη δημιουργία HTTP αιτημάτων Σε αυτήν την περίπτωση υπάρχουν αρκετές παράμετροι, που πρέπει να ληφθούν υπόψιν, για την ορθή παραγωγή αιτημάτων. Αυτές οι παράμετροι έχουν να κάνουν με την πολλαπλότητα των URIs, που οδηγούν σε έναν πόρο, τη διαφορετική σύνταξη κάποιων URIs και των παραμέτρων, που θα πρέπει ανά περίπτωση να συμπεριλαμβάνονται στα αίτηματα. Όσον αφορά την περίπτωση, όπου στον πόρο οδηγούν διαφορετικά Uris πρέπει να αναπαράγεται μια switch συνθήκη, που θα κατευθύνει στο κατάλληλο URI. Αυτό υλοποιείται, όπως φαίνεται και στον Aλγόριθμο 11, μέσω της συνθήκης p.setids(anannotationstack)->size()>2, όπου ελέγχεται εάν το μέγεθος του p.setids(anannotationstack) είναι μεγαλύτερο του 2. Το query p.setids θα περιγραφεί στο τέλος της ενότητας. Στη συνέχεια, για την αποφυγή επαναλήψεων του παραγόμενου κώδικα ορίζεται μία ακόμη 82

84 Σχεδίαση και ανάπτυξη διαδικτυακής εφαρμογής πελάτη για διαδικτυακές υπηρεσίες τύπου REST συνθήκη if, όπου ελέγχεται αν το τρέχον p.parentname περιλαμβάνεται στα στοιχεία του anannotationstack.toplayer ή αν το τρέχον c ταυτίζεται με το p.parentname. Αν κάποια από τις δύο συνθήκες επαληθεύεται, τότε παράγεται ο κώδικας, που υπάρχει στο εσωτερικό του μπλοκ if. Συμπληρωματικά, στο εσωτερικό του προαναφερθέντος μπλοκ if επαναλαμβάνεται η συνθήκη p.setids(anannotationstack)->size()>2 για την ορθή παραγωγή του επιθυμητού κώδικα. Τέλος, περιλαμβάνεται και ένας ακόμη έλεγχος με τη συνθήκη c=p.parentname για τη διασφάλιση της αποστολής των απαιτούμενων στοιχείων για την HTTP μέθοδο. Αλγόριθμος 11: Ανάκτηση πόρων για την δημιουργία HTTP αιτημάτων [if (p.setids(anannotationstack)->size()>2 )] switch(true){ [/if] [for (c: String p.setids(anannotationstack))] [if (anannotationstack.toplayer().parentname->includes(p.parentname) or not(c=p.parentname))] [if (p.setids(anannotationstack)->size()>2)] case compare("[c/]"): [/if] $scope.[p.parentname/] = [p.parentname/]factory [if (anannotationstack.bhasauthenticationannotation)]($scope.credentials) [/if].[c/].get[if (p.setids(anannotationstack)->size()>2)]list[/if]({[if (not(c=p.parentname))][c/]id: $routeparams.[c/]id,[/if][p.parentname/]id: $routeparams.[p.parentname/]id}); [if (p.setids(anannotationstack)->size()>2)]break;[/if] [/if] [/for] [if (p.setids(anannotationstack)->size()>2)]}[/if] Αν τα στοιχεία του p.setids(anannotationstack) είναι περισσότερα από δύο τότε εισήγαγε το ακόλουθο κείμενο. Στη συνέχεια, για κάθε στοιχείο του p.setids(anannotationstack) τύπου String αν το p.parentname περιέχεται στη λίστα anannotationstack.toplayer().parentname ή το c δεν ταυτίζεται με το p.parentname τότε συνέχισε. Αν τα στοιχεία του p.setids(anannotationstack) είναι περισσότερα από δύο τότε εισήγαγε τα ακόλουθα. Αν το anannotationstack.bhasauthenticationannotation είναι αληθές τότε εισήγαγε το ($scope.credentials). Στη συνέχεια, αν τα στοιχεία του p.setids(anannotationstack) είναι περισσότερα από δύο εισήγαγε τα ακόλουθα. Αν το c δεν ταυτίζεται με το p.parentname, τότε εισήγαγε τα ακόλουθα. Αν τα στοιχεία του p.setids(anannotationstack) είναι περισσότερα από δύο, τότε εισήγαγε τα ακόλουθα. 83

85 Ανάκτηση πόρων σχετικών με πόρο Η ανάκτηση πόρων σχετικών από πόρο απαιτείται για την υλοποίηση του κουμπιού Back, που εμφανίζεται στις όψεις. Η διαδικασία είναι πανομοιότυπη με την αντίστοιχη του module Views και για το λόγο αυτό δε θα αναλυθεί περαιτέρω. Ανάκτηση πόρων για τις μεθόδους PUT και DELETE Η συγκεκριμένη διαδικασία αποτελεί ένα συνδυασμό της μεθόδου ανάκτησης πόρων για τη δημιουργία HTTP αιτημάτων, που περιγράφηκε παραπάνω, και της μεθόδου ανάκτησης πόρων για τις μεθόδους PUT και DELETE του module Index. Αρχικά, πραγματοποείται έλεγχος για την υποστήριξη των μεθόδων PUT και DELETE για το συγκεκριμένο πόρο και στη συνέχεια υλοποιείται μία αντίστοιχη διαδικασία με τη γενική διαδικασία ανάκτησης πόρων για τη δημιουργία HTTP αιτημάτων. Ανάκτηση πόρων σχετικών με τον πόρο Για την υλοποίηση της πλοήγησης ανάμεσα στους σχετικούς πόρους απαιτείται η ανάκτηση των σχετικών με τον πόρο πόρους για τη σύνταξη των δρομολογήσεων μέσα στους ελεγκτές. Ο Αλγόριθμος 12 υλοποιεί τη συγκεκριμένη απαίτηση, όπου πραγματοποιείται μία διαδοχική προσέγγιση των στοιχείων hasrelatedjavarmmanager του JavaResourceModelManager και παράγεται ο κώδικας για τυ συνάρτηση choose[c.parentname.toupperfirst()/]. Αλγόριθμος 12: Ανάκτηση πόρων σχετικών με τον πόρο για δημιουργία δρομολόγησης στον ελεγκτή //Routing methods [for (c: JavaResourceModelManager p.hasassociatedrmmanager.hasrelatedjavarmodel.hasrelatedjavarmmanager)] //callback for ng-click "[c.parentname/]": $scope.choose[c.parentname.toupperfirst()/] = function([p.parentname/]id){ $location.path('/[p.parentname/]/' + [p.parentname/]id + '/[c.parentname/]' ); }; [/for] //End of routing methods Για κάθε p.hasassociatedrmmanager.hasrelatedjavarmodel.hasrelatedjavarmmanager τύπου JavaResourceModelManager επανέλαβε τα ακόλουθα. 84

86 Σχεδίαση και ανάπτυξη διαδικτυακής εφαρμογής πελάτη για διαδικτυακές υπηρεσίες τύπου REST Ανάκτηση πλήθους πόρων προς εμφάνιση στην αρχική σελίδα Για την αναπαραγωγή του αρχείου frontctrl.js, απαιτείται ο έλεγχος του αριθμού των πόρων, που πρέπει να εμφανίζονται στην πρώτη σελίδα. Η διαδικασία, που ακολουθείται είναι πανομοιότυπη με αυτή που περιγράφεται για την ανάκτηση πλήθους πόρων προς εμφάνιση στην αρχική σελίδα. Module Services Το module Services δέχεται ως είσοδο το στοιχείο AnnotationStack και παράγει ένα JS αρχείο με την ονομασία services.js. Το συγκεκριμένο αρχείο περιέχει τις μεθόδους για την υλοποίηση των PUT και DELETE μεθόδων για κάθε πόρο, όπου το αντίστοιχο στοιχείο JavaResourceControllerManager το επιτρέπει. Επίσης, περιλαμβάνει και την περίπτωση όπου η επεξεργασία των στοιχείων ενός πόρου μπορεί να γίνει μέσω περισσότερων του ενός URIs. Τέλος, περιλαμβάνει το service SignIn, στην περίπτωση που απαιτείται ταυτοποίηση, για την υποβοήθηση της μεταφοράς των στοιχείων ταυτοποίησης από ελεγκτή σε ελεγκτή. Ανάκτηση πόρων για την δημιουργία angular services Για τη χρήση συγκεκριμένων εργαλείων, που παρέχει η γλώσσα προγραμματισμού Angular JS, απαιτείται η δημιουργία services αντικειμένων. Για την υλοποίηση αυτών των services, καθώς και για την κάλυψη των περιπτώσεων, όπου ένας πόρος είναι προσβάσιμος από πολλαπλά URIs χρησιμοποιήθηκε ο Αλγόριθμος 13. Αρχικά, υλοποιείται μία επαναληπτική διαδικασία για τη διαδοχική προσέγγιση των στοιχείων τύπου JavaResourceControllerManager, για κάθε τέτοιο στοιχείο παράγεται και ένα service, που φέρει το όνομά του. Στην περίπτωση, που η επιθυμητή εφαρμογή πελάτη απαιτεί authentication χρησιμοποιείται μία συνθήκη if για την εισαγωγή των απαραίτητων στοιχείων μέσα στον κώδικα. Αλγόριθμος 13: Ανάκτηση πόρων για τη δημιουργία angular services [for (p: JavaResourceControllerManager anannotationstack.hascorepsm.hasjavarcmanager)] services.factory('[p.parentname/]factory', function ($resource) { [if (anannotationstack.bhasauthenticationannotation)]return function(credentials){[/if] [/for] 85

87 Για κάθε anannotationstack.hascorepsm.hasjavarcmanager τύπου JavaResourceControllerManager επανάλαβε τα παρακάτω. Αν το anannotationstack.bhasauthenticationannotation είναι αληθές τότε εισήγαγε τα ακόλουθα. Ανάκτηση πόρων για τα CRUD αιτήματα Για την δημιουργία CRUD αιτημάτων απαιτείται η διεύθυνση στην οποία θα αποστέλλονται, η παραμετροί της καθώς και η δημιουργία headers και body, όπου αυτό απαιτείται. Για την υλοποιήση των συγκεκριμένων απαιτήσεων χρησιμοποιήθηκε ο Αλγόριθμος 14. Αλγόριθμος 14: Ανάκτηση πόρων για τη δημιουργία CRUD αιτημάτων return { [for (c: String p.setids(anannotationstack))] [if (not(c=p.parentname) or anannotationstack.toplayer().parentname- >includes(p.parentname))] [c/]: $resource(' lleruri.substituteall('{', ':').substituteall('}','').substitute('manager','')/] [if (p.setids(anannotationstack)->size()>2)]/[c/]/:[c/]id/[p.parentname/] [/if]/:[p.parentname/]id', { [if (p.setids(anannotationstack)->size()>1)][c/]id: '@[c/]id', [/if][p.parentname/]id: '@[p.parentname/]id'},{ get: { method: 'GET' [if (anannotationstack.bhasauthenticationannotation)], headers: { 'Authorization': 'Basic ' + credentials} [/if]} [/if][/for] Για κάθε p.setids(anannotationstack) τύπου String επανάλαβε τα ακόλουθα. Αν το c δεν ταυτίζεται με το p.parentname ή το p.parentname περιέχεται στη λίστα anannotationstack.toplayer().parentname τότε εισήγαγε τα ακόλουθα. Αν τα στοιχεία του p.setids(anannotationstack) είναι περισσότερα από δύο, τότε εισήγαγε τα ακόλουθα. Αν τα στοιχεία του p.setids(anannotationstack) είναι περισσότερα από ένα τότε εισήγαγε τα ακόλουθα. Αν το anannotationstack.bhasauthenticationannotation είναι αληθές, τότε εισήγαγε τα ακόλουθα. Εισαγωγή πλαισίων διαλόγου 86

88 Σχεδίαση και ανάπτυξη διαδικτυακής εφαρμογής πελάτη για διαδικτυακές υπηρεσίες τύπου REST Στις περιπτώσεις, όπου ο χρήστης ζητά από την διαδικτυακή υπηρεσία την οριστικοποίηση κάποιας ενέργειας ή απαιτείται η ταυτοποίηση των στοιχείων του, χρειάζεται η εφαρμογή πελάτη να διαθέτει ένα πλαίσιο διαλόγου, όπου θα ενημερώνει τη χρήστη για το αντίκτυπο ή το αποτέλεσμα των ενεργείων του. Για την υλοποίηση αυτής της απαίτησης, έχει χρησιμοποιηθεί ο Αλγόριθμος 15. Πιο συγκεκριμένα, παράγεται ένα PopUp παράθυρο, το οποίο θα καλείται από τους ελεγκτές της εφαρμογής στις περιπτώσεις, που ορίζονται στον κάθε ελεγκτή. Αλγόριθμος 15: Δημιουργία πλαισίων διαλόγου [anannotationstack.hascorepsm.name/].service('popupservice',function($window){ this.showpopup=function(message){ return $window.confirm(message); } }); Εισήγαγε το anannotationstack.hascorepsm.name και το κείμενο που ακολουθεί. Module App Το module App δέχεται ως είσοδο το στοιχείο anannotationstack και παράγει ένα JS αρχείο με την ονομασία app.js. Το αρχείο αυτό είναι υπεύθυνο για την περιγραφή των δυνατών διαδρομών, που μπορεί πλοηγηθεί ένας χρήστης μέσω της διαδικτυακής εφαρμογής πελάτη. Παράλληλα, δίνει στοιχεία για την σύνδεση κάθε template/όψης με τον αντίστοιχο ελεγκτή και την φυσική τοποθεσία της κάθε όψης μέσα στο φάκελο main. Ανάκτηση πόρων για τη δημιουργία του αρχείου app.js Όπως έχει ήδη αναλυθεί προκειμένου οι παραγόμενες εφαρμογές πελάτη να είναι σύμφωνες με το REST αρχιτεκτονικό στυλ και να επιτευχθεί το τρίτο επίπεδο του Richardson Maturity Model θα πρέπει να υλοποιηθεί η κατάλληλη χαρτογράφηση της εφαρμογής πελάτη. Αυτό σημαίνει ότι στο αρχείο app.js πρέπει να συμπεριλαμβάνονται μόνο οι περιγραφόμενες από την υπηρεσία δρομολογήσεις των πόρων. Ο Αλγόριθμος 16 περιγράφει την υλοποίηση αυτής της διαδικασίας. Αρχικά, εισάγεται μία επαναληπτική διαδικασία για τη διαδοχική προσέγγιση των στοιχείων JavaResourceControllerManager και μέσα σε αυτή τη διαδικασίας ενσωματώνεται όλος ο κώδικας, που θα πρέπει να αναπαραχθεί καθώς και κάποιες συνθήκες για την ορθή υλοποίηση του app.js και την αποφυγή επαναλήψεων. Η περίπτωση της δρομολόγησης της αρχικής σελίδας εξετάζεται μέσω της συνθήκης 87

89 anannotationstack.toplayer().parentname->includes(p.parentname) και στη συνέχεια της ανατίθεται η αντίστοιχη όψη και ελεγκτής. Η διαδικασία αυτή, υλοποιείται μέσω της συνθήκης AnnotationStack.topLayer()->size()<>1, όπου εάν επαληθεύεται της αντίθεται η όψη front.html και ο ελεγκτής frontctrl.js ενώ στην αντίθετη περίπτωση η όψη και ο ελεγκτής παίρνουν την ονομασία του πόρου. Στη συνέχεια, δρομολογούνται οι πόροι, οι οποίοι έχουν πρόσβαση από ένα και μοναδικό URI, μέσω της συνθήκης if p.setids(anannotationstack)->size()=2 and anannotationstack.toplayer(). parentname->excludes(p.parentname). Τέλος, δρομολογούνται οι πόροι, που είναι προσβάσιμοι από πολλαπλά URIs, μέσω της επαναληπτικής διαδικασίας c: String p.setids(anannotationstack) και της συνθήκης c=p.parentname and p.setids(anannotationstack)->size()>2, οι οποίες έχουν αναλυθεί σε προηγούμενες ενότητες. Αλγόριθμος 16: Ανάκτηση πόρων για τη δημιουργία δρομολόγησης στο app.js [for (p: JavaResourceControllerManager anannotationstack.hascorepsm.hasjavarcmanager)][if (anannotationstack.toplayer().parentname->includes(p.parentname))] $routeprovider.when('/[p.parentname.tolower()/]',[if (anannotationstack.toplayer()->size()<>1)] {templateurl: 'views/front.html', controller: 'frontctrl', caseinsensitivematch: true});[else]{templateurl: 'views/[p.parentname/].html', controller: '[p.parentname/]ctrl', caseinsensitivematch: true });[/if] $routeprovider.when('/[p.parentname.tolower()/]/:[p.parentname/]id',[if (anannotationstack.toplayer()->size()<>1)] {templateurl: 'views/front.html', controller: 'frontctrl', caseinsensitivematch: true});[else]{templateurl: 'views/[p.parentname/].html', controller: '[p.parentname/]ctrl', caseinsensitivematch: true });[/if] [/if] [if (p.setids(anannotationstack)->size()=2 and anannotationstack.toplayer().parentname->excludes(p.parentname))] $routeprovider.when('[p.controlleruri.substituteall('{', ':').substituteall('}','')/]', {templateurl: 'views/[p.parentname/].html', controller: '[p.parentname/]ctrl', caseinsensitivematch: true }); $routeprovider.when('[p.controlleruri.substituteall('{', ':').substituteall('}','')/]/:[p.parentname/]id',{templateurl: 'views/[p.parentname/].html', controller: '[p.parentname/]ctrl', caseinsensitivematch: true }); [/if] [for (c: String p.setids(anannotationstack))][if (not(c=p.parentname) and p.setids(anannotationstack)->size()>2)] $routeprovider.when('/[c/]/:[c/]id/[p.parentname/]', {templateurl: 'views/[p.parentname/].html', controller: '[p.parentname/]ctrl', caseinsensitivematch: true }); 88

90 Σχεδίαση και ανάπτυξη διαδικτυακής εφαρμογής πελάτη για διαδικτυακές υπηρεσίες τύπου REST $routeprovider.when('/[c/]/:[c/]id/[p.parentname/]/:[p.parentname/]id', {templateurl: 'views/[p.parentname/].html', controller: '[p.parentname/]ctrl', caseinsensitivematch: true }); [/if][/for] [/for] [if (anannotationstack.bhasauthenticationannotation=true)]$routeprovider.when('/signin ', {templateurl: 'views/signin.html', controller: 'LoginCtrl', caseinsensitivematch: true });[/if] Για κάθε anannotationstack.hascorepsm.hasjavarcmanager επανάλαβε τα ακόλουθα. Αν το p.parentname περιέχεται στη λίστα anannotationstack.toplayer().parentname, τότε εισήγαγε τα ακόλουθα. Στη συνέχεια, αν το anannotationstack.toplayer()->size() είναι διάφορο του ένα, τότε εισήγαγε τα ακόλουθα, διαφορετικά εισήγαγε τα ακόλουθα. Αν τα στοιχεία του anannotationstack.toplayer()->size() είναι περισσότερα από δύο και το p.parentname δεν περιέχεται στη λίστα anannotationstack.toplayer().parentname, τότε εισήγαγε τα ακόλουθα. Στη συνέχεια, για κάθε στοιχείο του p.setids(anannotationstack) τύπου String επανάλαβε τα ακόλουθα. Αν το c δεν ταυτίζεται με το p.parentname και τα στοιχεία του p.setids(anannotationstack)->size() είναι περισσότερα από δύο, τότε εισήγαγε τα ακόλουθα. Ανάκτηση πόρων για τη δρομολόγηση της αρχικής σελίδας και της σελίδας SignIn Για την δρομολόγηση της αρχικής σελίδας εξετάζεται εάν υπάρχουν πολλαπλοί πόροι, που θα πρέπει να εμφανίζονται στην αρχική σελίδα μέσω της συνθήκης anannotationstack.toplayer(aservicepsm)- >size()>1. Στην περίπτωση που η συνθήκη επαληθεύεται ως αρχική σελίδα ορίζεται η όψη front.html, σε διαφορετική περίπτωση ως αρχική σελίδα ορίζεται το ένα και μοναδικό αντικείμενο, που ορίζεται από το query toplayer. Αλγόριθμος 17: Έλεγχος για την ύπαρξη όψης SignIn και δρομολόγησή της [if (anannotationstack.bhasauthenticationannotation)]$routeprovider.when('/signin', {templateurl: 'views/signin.html', controller: 'LoginCtrl', caseinsensitivematch: true });[/if] [if (anannotationstack.toplayer(anannotationstack)->size()>1)] $routeprovider.when('/front', {templateurl: 'views/front.html', controller: 'frontctrl'}); [/if] 89

91 $routeprovider.otherwise({redirectto: '/[if (anannotationstack.bhasauthenticationannotation)]signin[else][if (anannotationstack.toplayer()- >size()>1)]front[else][anannotationstack.toplayer().parentname/][/if][/if]', caseinsensitivematch: true }); Αν το anannotationstack.bhasauthenticationannotation είναι αληθές, τότε εισήγαγε τα παρακάτω. Αν το anannotationstack.toplayer(anannotationstack)->size() είναι μεγαλύτερο από ένα, τότε εισήγαγε τα παρακάτω. Αν anannotationstack.bhasauthenticationannotation είναι αληθές τότε εισήγαγε το κείμενο SignIn, αλλιώς αν το anannotationstack.toplayer()->size() είναι μεγαλύτερο από ένα, τότε εισήγαγε το κείμενο front αλλιώς εισήγαγε το στοιχείο.toplayer().parentname. anannotationstack Module Auth Σε πολλές περιπτώσεις για την απόκτηση πρόσβασης σε κάποια συγκεκριμένη πληροφορία απαιτείται η ταυτοποίηση των στοιχείων του χρήστη. Για την υλοποίηση αυτής της διαδικασίας εισάγονται συνήθως ένα username και ένας κωδικός, κωδικοποιούνται στην πλευρά της εφαρμογής πελάτη και αποστέλλονται στον εξυπηρετητή για την επαλήθευση των στοιχείων. Στη συνέχεια, ο εξυπηρετητής στέλνει μία απόκριση επαλήθευσης ή μη των στοιχείων του χρήστη και ολοκληρώνεται η διαδικασία ταυτοποίησης. Για την υλοποίηση της παραπάνω διαδικασίας αναπτύχθηκε ο κώδικας του Αλγόριθμου 18, όπου αναπαράγει μία όψη για την εισαγωγή των στοιχείων ή την δημιουργία νέου λογαριασμού, στην περίπτωση που δεν υπάρχει, και ένας ελεγκτής, που διαχειρίζεται τη συγκεκριμένη όψη. Ανάκτηση πόρου για τον έλεγχο δημιουργίας αρχείων ταυτοποίησης Αλγόριθμος 18: Έλεγχος για τη δημιουργία όψης και ελεγκτή ταυτοποίησης [if (anannotationstack.bhasauthenticationannotation)] [file ('/' + anannotationstack.hascorepsm.name + 'Client/views/SignIn.html', false, 'UTF-8')] Αν το anannotationstack.bhasauthenticationannotation είναι αληθές, τότε δημιούργησε το αρχείο SignIn.hml στη διαδρομή '/' + anannotationstack.hascorepsm.name + 'Client/views/. 90

92 Σχεδίαση και ανάπτυξη διαδικτυακής εφαρμογής πελάτη για διαδικτυακές υπηρεσίες τύπου REST Ανακτηση πόρων για την εισαγωγή των στοιχείων ταυτοποίησης Για την εισαγωγή των στοιχείων ταυτοποίησης χρησιμοποιείται μία φόρμα, που αποστέλει τα στοιχεία στον ελεγκτή για την περαιτέρω διαχείρησή τους. Αλγόριθμος 19: Επαναληπτική διαδικασία για την ανάκτηση πόρων για τη δημιουργία φόρμας εισαγωγής στοιχείων ταυτοποίησης [for (p: String anannotationstack.getauthenticationperformer().hasauthenticationtoken.name)] <label>[p.toupperfirst()/]<input type="[if (p='password')]password[else]text[/if]" name="input[p.toupperfirst()/]" ngmodel="[anannotationstack.getauthenticationperformer().authenticationmodelparentna me/].[p/]"></label> [/for] [for (p: JavaResourceControllerManager anannotationstack.hascorepsm.hasjavarcmanager)][if (anannotationstack.ifresult(p) and not(p.controlleruri='/' + anannotationstack.getauthenticationperformer().authenticationmodelparentname))] <label>[p.controlleruri.getfirstresourceuri()/]id<input type="text" name="input[p.controlleruri.getfirstresourceuri()/]" ngmodel="[p.controlleruri.getfirstresourceuri()/]id"></label> [/if][/for] Για κάθε anannotationstack.getauthenticationperformer().hasauthenticationtoken.name τύπου String επανάλαβε τα ακόλουθα. Αν το στοιχείο p ταυτίζεται με το password εισήγαγε password αλλιώς text. Τέλος επανάληψης. Για κάθε anannotationstack.hascorepsm.hasjavarcmanager τύπου JavaResourceControllerManager επανάλαβε τα ακόλουθα. Αν το anannotationstack.ifresult(p) είναι αληθές και το p.controlleruri δεν ταυτίζεται με το anannotationstack.getauthenticationperformer().authenticationmodelparentname εισήγαγε τα ακόλουθα. Ανάκτηση πορων για τη δημιουργία νέου λογαριασμού Στην περίπτωση, που ο χρήστης δεν διαθέτει κάποιο λογαριασμό, δίνεται η δυνατότητα να δημιουργήσει ένα καινούριο και στη συνέχεια να εισάγει τα στοιχεία του για να ταυτοποιηθεί. Στην περίπτωση, που τα στοιχεία ταυτοποίησης απαιτούν την εισαγωγή στοιχείων για επιπρόσθετους πόρους, δημιουργείται και μία επιπρόσθετη φόρμα για τη συμπλήρωση των απαιτούμενων στοιχείων. Για να υλοποιηθεί αυτή η διαδικασία χρησιμποιείται ο ακόλουθος κώδικας του Αλγόριθμου

93 Αλγόριθμος 20: Ανάκτηση πόρων για τη δημιουργία νέου λογαρισμού [for (p: JavaResourceModel anannotationstack.hascorepsm.hasjavarmodel)] [if (p.javarmodelhasproperty.type->includes('java' + anannotationstack.getauthenticationperformer().authenticationmodelparentname + 'Model'))] <div class="w3-container w3-grey"> <h3>new [p.parentname.toupperfirst()/] Form</h3> </div> [for (c: PSMComponentProperty p.javarmodelhasproperty)][if ((c.type.startswith('string')))] <label>[c.name.toupperfirst()/]<input type="[if (c.name='password')]password[else]text[/if]" name="input[c.name.toupperfirst()/]" ng-model="[p.parentname/].[c.name/]"></label>[lineseparator()/][/if][/for] [/if] [/for] [for (p: JavaResourceModel anannotationstack.hascorepsm.hasjavarmodel)][if (p.parentname=anannotationstack.getauthenticationperformer().authenticationmodelpa rentname)] <div class="w3-container w3-grey"> <h3>new [p.parentname.toupperfirst()/] Form</h3> </div> [for (c: PSMComponentProperty p.javarmodelhasproperty)][if ((c.type.startswith('string')))] <label>[c.name.toupperfirst()/]<input type="[if (c.name='password')]password[else]text[/if]" name="input[c.name.toupperfirst()/]" ng-model="[p.parentname/].[c.name/]"></label>[lineseparator()/][/if][/for] <input type="button" class="button" ng-click="signup()" value="sign Up"> <input type="button" class="button" ng-click="cancel()" value="cancel"> [/if][/for] Για κάθε anannotationstack.hascorepsm.hasjavarmodel τύπου JavaResourceModel επανάλαβε τα ακόλουθα. Αν το 'Java'+anAnnotationStack.getAuthenticationPerformer(). authenticationmodelparentname + 'Model' περιέχεται στη λίστα p.javarmodelhasproperty.type, τότε εισήγαγε τα ακόλουθα. Για κάθε p.javarmodelhasproperty τύπου PSMComponentProperty αν το c.type ταυτίζεται με το String τότε εισήγαγε το παρακάτω. Αν το c.name ταυτίζεται με το password τότε εισήγαγε password αλλιώς text. Τέλος επανάληψης. Για κάθε anannotationstack.hascorepsm.hasjavarmodel τύπου JavaResourceModel επανάλαβε τα ακόλουθα. Αν το p.parentname ταυτίζεται με το anannotationstack.getauthenticationperformer() 92

94 Σχεδίαση και ανάπτυξη διαδικτυακής εφαρμογής πελάτη για διαδικτυακές υπηρεσίες τύπου REST.authenticationModelParentName, τότε επανάλαβε τα ακόλουθα.. Για κάθε p.javarmodelhasproperty τύπου PSMComponentProperty αν το c.type ταυτίζεται με το String τότε εισήγαγε το παρακάτω. Αν το c.name ταυτίζεται με το password τότε εισήγαγε password αλλιώς text. Τέλος επανάληψης. Ανάκτηση πόρων για την απαιτούμενη παραμετροποίηση του ελεγκτή LoginCtrl Για την ομαλή επικοινωνία του ελεγκτή με τα services του αντίστοιχου πόρου θα πρέπει να εισάγεται ως παράμετρος στον ορισμό του ελεγκτή. Αυτό υλοποιείται με τον ακόλουθο κώδικα του Αλγόριθμου 21. Αλγόριθμος 21: Ανάκτηση πόρων για την παραμετροποίηση του ελεγκτή LoginCtrl [for (p: JavaResourceControllerManager anannotationstack.hascorepsm.hasjavarcmanager)][if (anannotationstack.ifresult(p) and not(p.controlleruri='/' + anannotationstack.getauthenticationperformer().authenticationmodelparentname))]'[p.controlleruri.getfirstresourceuri()/]factory',[/if][/for] Για κάθε anannotationstack.hascorepsm.hasjavarcmanager τύπου JavaResourceControllerManager επανάλαβε τα παρακάτω. Αν το anannotationstack.ifresult(p) είναι αληθές και το p.controlleruri δεν ταυτίζεται με το «'/' + anannotationstack.getauthenticationperformer().authenticationmodelparentname», τότε εισήγαγε τα ακόλουθα. Ανάκτηση πόρων για την αποστολή αιτήματος ταυτοποίησης στοιχείων Για την αποστολή αιτήματος ταυτοποίησης στοιχείων ο ελεγκτής θα πρέπει να κωδικοποίησει τα στοιχεία ταυτοποίησης και να αποστείλει ένα GET αίτημα με header τα στοιχεία ταυτοποίησης σε κωδικοποιημένη μορφή. Στην περίπτωση, που ο πόρος, που περιέχει τα στοιχεία τα ταυτοποίησης είναι σχετικός από άλλο πόρο τότε, αποστέλλονται και τα απαιτούμενα στοιχεία του άλλου πόρου. Τα απαιτούμενα στοιχεία για την διαδικασία αυτή ανακτώνται με τον Αλγόριθμο 22. Αλγόριθμος 22: Ανάκτηση πόρων για την αποστολή αιτήματος ταυτοποίησης στοιχείων [for (p: JavaResourceControllerManager anannotationstack.hascorepsm.hasjavarcmanager)] [if (anannotationstack.ifresult(p))] 93

95 [if (p.controlleruri='/' + anannotationstack.getauthenticationperformer().authenticationmodelparentname)] [anannotationstack.getauthenticationperformer().authenticationmodelparentnam e/]factory($scope.credentials).[anannotationstack.getauthenticationperformer().aut henticationmodelparentname/].get().$promise [else] [anannotationstack.getauthenticationperformer().authenticationmodelparentnam e/]factory($scope.credentials).[p.controlleruri.getfirstresourceuri()/].get({'[p.c ontrolleruri.getfirstresourceuri()/]id': $scope.[p.controlleruri.getfirstresourceuri()/]id}).$promise [/if][/if][/for] Για κάθε anannotationstack.hascorepsm.hasjavarcmanager τύπου JavaResourceControllerManage επανάλαβε τα ακόλουθα. Αν το anannotationstack.ifresult(p) είναι αληθές, τότε αν το '/' + anannotationstack.getauthenticationperformer().authenticationmodelparentname ταυτίζεται με το p.controlleruri εισήγαγε τα ακόλουθα, αλλιώς εισήγαγε τα ακόλουθα. Τέλος επανάληψης. Ανάκητηση πόρων για τη δημιουργία νέου λογαριασμού Για την αποστολή αιτήματος νέου λογαριασμού χρησιμοποιείται αυτούσιος ο Αλγόριθμος 22 με διαφορετικό CRUD verb. Module Dev Στις περιπτώσεις, που κάποιος πόρος δε μπορεί να ενταχθεί στο αφαιρετικό επίπεδο, που περιγράφεται από την MDA αρχιτεκτονική ή ο προγραμματιστής επιθυμεί κάποια διαφορετική υλοποίηση, δίνεται η δυνατότητα να παραχθεί ένα κενό αρχείο, το οποίο θα συμπληρώσει ο προγραμματιστής. Τα αρχεία αυτά αποθηκεύονται στο φάκελο dev. Αλγόριθμος 23: Επαναληπτική διαδικασία για τη δημιουργία κενών αρχείων [for (p: JavaAlgoResourceModel anannotationstack.hascorepsm.hasjavaalgomodel)] [file ('/' + anannotationstack.hascorepsm.name + 'Client/dev/' + p.parentname + '.html', false, 'UTF-8')] <!-- You can add code here --> [/file] [/for] 94

96 Σχεδίαση και ανάπτυξη διαδικτυακής εφαρμογής πελάτη για διαδικτυακές υπηρεσίες τύπου REST Για κάθε anannotationstack.hascorepsm.hasjavaalgomodel τύπου JavaAlgoResourceModel δημιούργησε ένα αρχείο με το όνομα p.parentname στη διαδρομή '/' + anannotationstack.hascorepsm.name + 'Client/dev/'. Τέλος επανάληψης. Queries Πολλές φορές προκειμένου να ανακτηθεί μία συγκεκριμένη πληροφορία απαιτείται η χρήση πολυσύνθετων εκφράσεων, οι οποίες αυξάνουν το χρόνο λειτουργίας και δυσκολεύουν την κατανόηση του κώδικα. Για το λόγο αυτό, συνηθίζεται αυτές οι εκφράσεις να καταχωρούνται ως queries, τα οποία λειτουργούν αντίστοιχα με τις κλήσεις εξωτερικών συναρτλησεων σε γλώσσες υψυλού επιπέδου. Query firstonly Σε προηγούμενη ενότητα αναφέρθηκε πως η OCL γλώσσα προγραμματισμού είναι μία δηλωτική γλώσσα προγραμματισμού. Το γεγονός αυτό παράγει κάποιους περιορισμούς στον τρόπο διαχείρισης της πληροφορίας των στοιχείων. Για παράδειγμα, υπάρχουν περιπτώσεις, όπου Acceleo εκφράσεις πρέπει να αναπαραχθούν μόνο την πρώτη φορά, που ικανοποιείται μία συνθήκη. Μία τέτοια περίπτωση θα μπορούσε να υλοποιηθεί εύκολα σε μία γλώσσα προστακτική με τη χρήση ενός flag. Οι τιμές των μεταβλητές, όμως, που χρησιμοποιούνται στο Acceleo δεν μεταβάλλονται μετά από την αρχικοποίησή τους κατά τη διάρκεια εκτέλεσης του προγράμματος. Στην περίπτωση του query firstonly, πρέπει να εντοπιστεί η ονομασία του του πρώτου στοιχείου c τύπου JavaResourceController, του οποίου το HTTPActivityVerb ταυτίζεται με το δοσμένο string e. Αλγόριθμος 24: Query firstonly [query public firstonly(c: JavaResourceController,e: String): String = c.javarcontrollerhashttpactivity->select(s: HTTPActivity s.activityhttpverb.tostring()=e)->assequence()->first().name/] Για το στοιχείο c.javarcontrollerhashttpactivity επέλεξε τα s.activityhttpactivityverb τύπου HTTPActivity αν ταυτίζονται με το String e, αφού πρώτα μετατραπούν σε String. Δόμησε τα σε OrderedSet κι από αυτά επέστρεψε το name του πρώτου στοιχείου. Query otherlayer 95

97 Όπως έχει αναφερθεί για κάποια μέρη του κώδικα, που θα παράγει τις εφαρμογές πελάτη, απαιτείται η ανάκτηση των πόρων, που δεν ανήκουν στην αρχική σελίδα. Η ανάκτηση αυτή γίνεται με τη χρήση του query otherlayer μέσω της τομής του συνόλου των στοιχείων hasjavarmmanager του anannotationstack και των στοιχείων hasrelatedjavarmmanager των hasjavarmodel του anannotationstack.hascorepsm. Η έξοδος του query οργανώνεται σε δομημένη λίστα. Αλγόριθμος 25: Query otherlayer [query public otherlayer(anannotationstack: AnnotationStack): OrderedSet(JavaResourceModelManager) = (anannotationstack.hascorepsm.hasjavarmmanager- >intersection(anannotationstack.hascorepsm.hasjavarmodel.hasrelatedjavarmmanager- >asorderedset()))->asorderedset()/] Επέστρεψε δομημένα σε OrderedSet τα στοιχεία τύπου JavaResourceModelManager της τομής των στοιχείων anannotationstack.hascorepsm.hasjavarmmanager και anannotationstack.hascorepsm.hasjavarmodel.hasrelatedjavarmmanager. Query toplayer Το query toplayer υλοποιεί την αντίθετη διαδικασία από το query otherlayer, εντοπίζει, δηλαδή, τους πόρους που πρέπει να εμφανίζονται στην αρχική σελίδα. Η ανάκτηση των συγκεκριμένων πόρων γίνεται μέσω της αφαίρεσης του συνόλου της τομής του συνόλου των στοιχείων hasjavarmmanager του anannotationstack.hascorepsm και των στοιχείων hasrelatedjavarmmanager των hasjavarmodel του aservicepsm από το σύνολο hasjavarmmanager του anannotationstack.hascorepsm. Αλγόριθμος 26: Query toplayer [query public toplayer(anannotationstack: AnnotationStack): OrderedSet(JavaResourceModelManager) = (anannotationstack.hascorepsm.hasjavarmmanager- anannotationstack.hascorepsm.hasjavarmmanager- >intersection(anannotationstack.hascorepsm.hasjavarmodel.hasrelatedjavarmmanager- >asorderedset()))->asorderedset()/] Επέστρεψε δομημένα σε OrderedSet τα στοιχεία τύπου JavaResourceModelManager, που είναι αποτέλεσμα της αφαίρεσης από τα στοιχεία anannotationstack.hascorepsm.hasjavarmmanager της 96

98 Σχεδίαση και ανάπτυξη διαδικτυακής εφαρμογής πελάτη για διαδικτυακές υπηρεσίες τύπου REST τομής των στοιχείων anannotationstack.hascorepsm.hasjavarmmanager και των στοιχείων anannotationstack.hascorepsm.hasjavarmodel.hasrelatedjavarmmanager. Query relatedresource Πολλές φορές απαιτείται η ανάκτηση των πόρων, που είναι σχετικοί από άλλους πόρους. Η ανάκτηση αυτών των πόρων γίνεται μέσω του query relatedresource, όπου η έξοδος του προκύπτει από την τομή της δομημένης λίστας των στοιχείων hasassociatedrmmanager του hasjavarcmanager του anannotationstack.hascorepsm και του στοιχείου hasrelatedjavarmmanager του τρέχοντος p. Αλγόριθμος 27: Query relatedresource [query public relatedresource(anannotationstack : AnnotationStack, p: JavaResourceModel ) : OrderedSet(JavaResourceModelManager) = anannotationstack.hascorepsm.hasjavarcmanager.hasassociatedrmmanager- >asorderedset()->intersection(p.hasrelatedjavarmmanager)->asorderedset()/] Για τα στοιχεία hasassociatedmanager του anannotationstack.hascorepsm.hasjavarcmanager, δομημένου ως OrderedSet, επέστρεψε ως OrderedSet την τομή του με το στοιχείο p.hasrelatedjavarmmanager. Query ifresult Για την επιτάχυνση της διαδικασίας μετασχηματισμού συνηθίζεται συγκρίσεις, που χρησιμοποιούνται συχνά να συντάσσονται μέσα σε query, ώστε να υπολογίζονται μόνο μία φορά. Το query ifresult συγκρίνει το p.parentname με το anannotationstack.getauthenticationperformer.authenticationmodelparentname και η έξοδος του είναι ένα Boolean στοιχείο. Αλγόριθμος 28: Query ifresult [query public ifresult(anannotationstack: AnnotationStack, p: JavaResourceControllerManager) : Boolean = p.parentname=anannotationstack.getauthenticationperformer().authenticationmodelpar entname/] 97

99 Αν p.parentname ταυτίζεται με το anannotationstack.getauthenticationperformer().authenticationmodelparentname τότε αληθές, αλλιώς ψευδές. Query getfirstresource Στην περίπτωση, που ο πόρος ταυτοποιήσης είναι σχετικός από άλλο, απαιτείται η ανάκτηση του σχετικού πόρου. Αυτό καθίσταται εφικτό από την επεξεργασία του URI, που οδηγεί στον πόρο ταυτοποίησης. Αλγόριθμος 29: Query getfirstresource [query public getfirstresourceuri(p: String) : String = p.substring(p.index('{'), p.index('}')).substituteall('{', '').substituteall('id}', '')/] Για το p τύπου String δημιούργησε το subtring από το σημείο εμφάνισης του { έως το σημείο εμφάνισης του } και στη συνέχεια αντικατέστησε το { και το Id με κενό. Query getauthenticationperformer Για τον ορισμό του πόρου ταυτοποίησης χρησιμοποιείται το στοιχείο AuthenticationPerformer τύπου Annotation. Για την ανάκτηση του συγκεκριμένου στοιχείου χρησιμοποιείται το query του Αλγόριθμου 30. Αλγόριθμος 30: Query getauthenticationperformer [query public getauthenticationperformer(anannotationstack : AnnotationStack) : AuthenticationPerformer = anannotationstack.hasauthenticationlayer.hasannotation- >select(annotation annotation.oclistypeof(authenticationperformer))->at(1)/] Από τη λίστα των στοιχείων has Annotation του hasauthenticationlayer του anannotationstack επέλεξε το πρώτο στοιχείο του τύπου AuthenticationPerformer. 98

100 Σχεδίαση και ανάπτυξη διαδικτυακής εφαρμογής πελάτη για διαδικτυακές υπηρεσίες τύπου REST 4.6 Παραγόμενες εφαρμογές πελάτη Εκτέλεση της Automated Client Engine μηχανής Για την εκτέλεση της ACE και την δημιουργία της επιθυμητής εφαρμογής πελάτη χρησιμοποιείται ένα eclipse plugin, η διεπαφή του οποίου φαίνεται στην Εικόνα 35. Οι είσοδοι, που δέχεται, είναι η διεύθυνση του μοντέλου της υπηρεσίας, που θα χρησιμοποιηθεί, ο φάκελος, όπου θα αποθηκευτούν τα αρχεία, που θα παραχθούν, το όνομα του μοντέλου και η επιλογή της CSS μορφοποίησης, όπου επιλέγεται μία από τις δύο επιλογές. Για την εκτέλεση του μετασχηματισμού δίνεται εντολή από το κουμπί Generate Code. Εικόνα 35: Η διεπαφή του Eclipse-Plugin Χρήση των παραγόμενων εφαρμογών πελάτη Η παραγόμενη εφαρμογή πελάτη είναι έτοιμη προς κατανάλωση από τη στιγμή που θα παραχθεί από τη γεννήτρια. Για τη χρήση της απαιτείται ένας οποιοσδήποτε εξυπηρετητής και μία βάση δεδομέων (PostgreSQL ή MySQL). Αρχικά, ο κύριος φάκελος της παραγόμενης εφαρμογής πρέπει να αντιγραφεί στον φάκελο webapps του εξυπηρετητή. Στη συνέχεια, απαιτείται η ρύθμιση της θύρας του Connector του εξυπηρετητή για τον ορισμό του σημείου πρόσβασης (endpoint) για τη λήψη των αιτημάτων και την επιστροφή των αποκρίσων προς την εφαρμογή πελάτη. Το προεπιλεγμένο σημείο πρόσβασης των παραγόμενων εφαργμογών πελάτη είναι η θύρα Ακολούθως, πρέπει να δημιουργηθεί μία βάση δεδομένων με τα στοιχεία, που παρέχονται στο στοιχείο ServicePSM (θύρα επικοινωνίας βάσης 99

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

102 5 Παράδειγματα εφαρμογής Σχεδίαση και ανάπτυξη διαδικτυακής εφαρμογής πελάτη για διαδικτυακές υπηρεσίες τύπου REST Ως παραδείγματα εφαρμογής θα χρησιμοποιηθούν δύο διαδικτυακές υπηρεσίες τύπου REST, που παρήχθηκαν από την πλατφόρμα S-CASE. Αρχικά, θα παρουσιαστεί η πιο απλή εφαρμογή το ebucks API, που περιλαμβάνονται πολύ βασικές λειτουργίες, και στη συνέχεια θα παρουσιαστεί μια πιο σύνθετη εφαρμογή το WapoAdminTool API, ώστε να αναδειχθούν οι πολύπλευρες δυνατότητες της εφαρμογής. 5.1 Παράδειγμα εφαρμογής ebucks API Για την παρουσίαση της εφαρμογής επιλέχθηκε η απλή υπηρεσία ebucks API, η οποία διαθέτει δύο πόρους. Ως αρχική σελίδα εμφανίζεται η σελίδα με πληροφορίες σχετικά με τις παραγγελίες και στην συνέχεια ο χρήστης μπορεί να επιλέξει ανάμεσα στα εγγεγραμένα προϊόντα. Για την καλύτερη κατανόηση της υλοποίησης παρατίθενται κάποια στιγμιότυπα από το γραφικό περιβάλλον της εφαρμογής πελάτη καθώς και τα αιτήματα και οι αποκρίσεις ανάμεσα στον πελάτη και τον διακομιστή. Στην Εικόνα 36 φαίνεται το σχεδιάγραμμα του ebucks API, των σχέσεων μεταξύ των πόρων και οι επιτρεπτές HTTP μέθοδοι. Ο πόρος με το πιο έντονο περίγραμμα είναι ο πόρος που εμφανίζεται στην πρώτη σελίδα. Θα πρέπει να σημειωθεί ότι η ιδιαιτερότητα της συγκεκριμένης εφαρμογής έγκειται στο γεγονός ότι η υπηρεσία ebucks δεν επιτρέπει όλες τις HTTP μεθόδους και όπως θα φανεί παρακάτω η γεννήτρια, που δημιουργήθηκε στα πλαίσια αυτής της διπλωματικής εργασίας, Εικόνα 37: Δομή των παραγόμενων αρχείων για το ebucks API Client Εικόνα 36: Σχεδιάγραμα του ebucks API εξυπηρετεί τη συγκεκριμένη απαίτηση. Παράλληλα, έχει επιλεχθεί η επιλογή Vision Impaired μορφοποίησης, η οποία διαθέτει επιλογή χρωμάτων με μεγάλη αντίθεση για τη διευκόλυνση ατόμων με προβλήματα όρασης. Για την υλοποίηση του μετασχηματισμού ο χρήστης πρέπει να επιλέξει το xmi αρχείο, που περιγράφει το PSM μοντέλο του ebucks και το φάκελο στον οποίο θα αποθηκευτούν τα αρχεία του παραγόμενου κώδικα. Όπως φαίνεται και στην Εικόνα 37, ο μετασχηματισμός παράγει τέσσερις φακέλους μέσα στον προεπιλεγμένο φάκελο. Οι φάκελοι αυτοί είναι ο φάκελος ebucksclient, και οι υποφάκελοι js, views και dev. Ο υποφάκελος dev περιέχει όλα τα αρχεία, που απαιτούν την παρέμβαση προγραμματιστή. Ο υποφάκελος js περιέχει όλα τα αρχεία, που είναι γραμμένα σε Javascript. Πιο συγκεκριμένα, ο 101

103 υποφάκελος js περιέχει τους ελεγκτές της διαδικτυακής εφαρμογής πελάτη, το αρχείο services.js και το αρχείο app.js. Ο υποφάκελος views περιέχει αρχεία HTML, τα οποία είναι οι όψεις, τις οποίες επιλέγει να εμφανίσει το index.html ανάλογα με τις κατευθύνσεις, που δίνει το app.js. Οι επιτρεπτές κατευθύνσεις μέσα στην εφαρμογή φαίνονται στον Αλγόριθμο 31. Αλγόριθμος 31: App.js για το ebucks service angular.module('ebucks', ['ngresource','ngroute', 'ebucks.controllers','ebucks.services']); ebucks.config(['$routeprovider', function ($routeprovider) { $routeprovider.when('/order',{templateurl: 'views/order.html', controller: 'OrderCtrl', caseinsensitivematch: true }); $routeprovider.when('/order/:orderid',{templateurl: 'views/order.html', controller: 'OrderCtrl', caseinsensitivematch: true }); $routeprovider.when('/order/:orderid/product', {templateurl: 'views/product.html', controller: 'ProductCtrl', caseinsensitivematch: true }); $routeprovider.when('/order/:orderid/product/:productid',{templateurl: 'views/product.html', controller: 'ProductCtrl', caseinsensitivematch: true }); $routeprovider.otherwise({redirectto: '/Order', caseinsensitivematch: true }); }]) Η εφαρμογή πελάτη είναι έτοιμη προς κατανάλωση αντιγράφοντας απλώς τον φάκελο ebucks και την αντίστοιχη υπηρεσία στο φάκελο webapps ενός εξυπηρετητή και ρυθμίζοντας κατάλληλα τη βάση δεδομένων. Για την δοκιμή της χρησιμοποιήθηκε ένας Tomcat Server και εκτελέστηκε τοπικά στην προεπιλεγμένη διεύθυνση Η αρχική σελίδα φαίνεται στην Εικόνα 38. Εικόνα 38: Αρχική σελίδα του ebucks API Client Αλγόριθμος 32: Μέρος του ελεγκτή orderctrl.js για το ebucks service var ebucks = angular.module('ebucks.controllers',[]); 102

104 Σχεδίαση και ανάπτυξη διαδικτυακής εφαρμογής πελάτη για διαδικτυακές υπηρεσίες τύπου REST ebucks.controller('orderctrl',['$scope','$resource','$location','$route','$routepa rams','popupservice', 'OrderFactory', function($scope,$resource, $location, $route,$routeparams,popupservice, OrderFactory, $window) { $scope.$location = {}; var result = $location.url(); $scope.list = true; //Detail methods If ($routeparams.orderid!= null){ $scope.detail = true; $scope.list = false; } // callback for ng-click 'details' : $scope.details = function (OrderId) { $scope.detail = true; $scope.list = false; if($routeparams.orderid == null){ $scope.order = OrderFactory.Order.get({OrderId: OrderId}); } }; // callback for ng-click 'hidedetails' : $scope.hidedetails = function () { $scope.detail = false; $scope.list = true; if ($routeparams.orderid!= null) { var temp = location.href.lastindexof("/"); location.replace(location.href.slice(0,temp));} else { $scope.order = OrderFactory.Order.get({OrderId: $routeparams.orderid}); } }; //End of detail methods 103

105 Αλγόριθμος 33: Μέρος της όψης order.html για το ebucks service <div ng-controller="orderctrl"> <!-- Header --> <div style="background-color: #fcc7ad" class="w3-container w3-center w3- padding-100px"><a href="#" style="text-decoration: none"> <h1 style="color: #425e6c" class="w3-margin w3-jumbo">ebucks</h1></a> </div> <div class="w3-container w3-grey w3-center"> <h3>list of Orders</h3> </div> <div ng-show="list" class="w3-container w3-center w3-padding-100px w3- responsive"> <table class="w3-table w3-striped w3-bordered w3-border w3-hoverable w3- white"> <thead> <tr> <td><h5>orderid</h5></td> <td><h5>order Name</h5></td> <td><h5> </h5></td> <td><h5> </h5></td> <td><h5> </h5></td> </tr> </thead> <tbody ng-repeat="order in order.linklist ng-if="order.idtype!= 0"> <tr> <td><h5>{{order.idtype}}</h5></td> <td><h5>{{order.linkrel}}</h5></td> <td><input type="button" class="button" ngclick="editorder(order.idtype)" value="edit"></td> <td><input type="button" class="button" ngclick="details(order.idtype)" value="details"></td> <td><input type="button" class="button" ngclick="chooseproduct(order.idtype)" value="product"></td> </tr> </tbody> </table> </div> 104

106 Σχεδίαση και ανάπτυξη διαδικτυακής εφαρμογής πελάτη για διαδικτυακές υπηρεσίες τύπου REST Αλγόριθμος 34: Services.js για το ebucks service var services = angular.module('ebucks.services', ['ngresource','ngroute']); services.factory('orderfactory', function ($resource) { return { Order: $resource(' {OrderId: '@OrderId'},{ get: { method: 'GET'}, create: { method: 'POST'}, update: { method: 'PUT' }, delete: { method: 'DELETE'} })}; }); services.factory('productfactory', function ($resource) { return { Order: $resource(' {OrderId: '@OrderId',ProductId: '@ProductId'},{ get: { method: 'GET'}, create: { method: 'POST'}, update: { method: 'PUT' }, delete: { method: 'DELETE'} })}; }); ebucks.service('popupservice',function($window){ this.showpopup=function(message){ return $window.confirm(message); } }); Ανάκτηση λίστας Orders Αίτημα GET /ebucks/api/order HTTP/1.1 Host: localhost:8085 Accept: application/json, text/plain, */* 105

107 Απόκριση Εικόνα 39: Εμφάνιση της απόκρισης για το αίτημα ανάκτησης λίστας Order Ανάκτηση ενός Order Αίτημα GET /ebucks/api/order/1 HTTP/1.1 Host: localhost:8085 Accept: application/json, text/plain, */* Απόκριση Εικόνα 40: Εμφάνιση της απόκρισης για την ανάκτηση συγκεκριμένου Order 106

108 Σχεδίαση και ανάπτυξη διαδικτυακής εφαρμογής πελάτη για διαδικτυακές υπηρεσίες τύπου REST Ανανέωση ενός Order Αίτημα PUT /ebucks/api/order/1 HTTP/1.1 Host: localhost: Content-Length: 901 Accept: application/json, text/plain, */* inklist: [{idtype: "0", linkrel: "Get the order", linktype: "Sibling", }, ], orderid: "3", } linklist:[{idtype: "0", linkrel: "Get the order", linktype: "Sibling", }, ] 0:{idType: "0", linkrel: "Get the order", linktype: "Sibling", } 1:{idType: "0", linkrel: "Update the order", linktype: "Sibling", } 2:{idType: "0", linkrel: "Get all the products of this order", linktype: "Child", } 3:{idType: "0", linkrel: "Create a new product for this order", linktype: "Child", } 4:{idType: "0", linkrel: "Create a new order", linktype: "Parent", } 5:{idType: "0", linkrel: "Get all orders", linktype: "Parent", } orderid:"3" orderstatus:"order3" paymentmethod:"cash" Απόκριση Εικόνα 41: Φόρμα ανανέωσης ενός Order 107

109 Δημιουργία ενός Order Αίτημα POST /ebucks/api/order HTTP/1.1 Host: localhost:8085 Content-Length: 45 {"orderstatus":"test","paymentmethod":"cash"} Απόκριση Εικόνα 42: Φόρμα δημιουργίας νέου Order 108

110 Σχεδίαση και ανάπτυξη διαδικτυακής εφαρμογής πελάτη για διαδικτυακές υπηρεσίες τύπου REST Μετάβαση στη σελίδα Product Αίτημα GET /ebucks/api/order/1/product HTTP/1.1 Host: localhost:8085 Connection: keep-alive Accept: application/json, text/plain, */* Απόκριση Εικόνα 43 Μετάβαση στη σελίδα Product 5.2 Παράδειγμα εφαρμογής WapoAdminTool API Για το συγκεκριμένο παράδειγμα, θα χρησιμοποιηθεί το PSM μοντέλο που αναπαριστά το WapoAdminTool API. Το WapoAdminTool API είναι ένα από τα πιλοτικά έργα του S-CASE και λόγω της περιπλοκότητας του, χρησιμοποιείται ως υπόθεση ελέγχου της γεννήτριας, που αναπτύχθηκε στα πλαίσια της παρούσας διπλωματικής. Το WapoAdminTool API υλοποιεί μια εφαρμογή, που δίνει τη δυνατότητα στους χρήστες να δημιουργούν λογαρισμούς, να καταγράφουν τοποθεσίες χωρών, να βλέπουν ισοτιμίες για τις καταγεγραμμένες χώρες και να καταγράφουν εξοπλισμό. Στην εικόνα 44 φαίνεται το σχεδιάγραμμα του API, τους πόρους που διαθέτει, τις σχέσεις μεταξύ τους, καθώς και τις 109

111 επιτρεπόμενες HTTP μεθόδους για κάθε πόρο. Οι πόροι με το πιο έντονο πλαίσιο είναι αυτοί, που πρέπει να εμφανίζονται στην αρχική σελίδα. Η συγκεκριμένη υπηρεσία απαιτεί την ταυτοποίηση του χρήστη για την απόκτηση πρόσβασης στους πόρους και αφότου ολοκληρωθεί ο χρήστης οδηγείται στην αρχκή σελίδα της εφαρμογής. Οπως φαίνεται από το σχεδιάγραμμα της εφαρμογής, η δομή της υπηρεσίας είναι αρκετά περίπλοκη σε σχέση με το προηγούμενο παράδειγμα, αφού έχει περισσότερους από έναν πόρους, που πρέπει να εμφανίζει στην πρώτη σελίδα και πόρους, που είναι προσβάσιμοι από περισσότερους από έναν πόρους και συνοδεύεται από διαδικασίες authentication. Η γεννήτρια, που κατασκευάστηκε, μπορεί να καλύψει τις απαιτήσεις και αυτής της υπηρεσίας και να παράξει την αντίστοιχη εφαρμογή πελάτη μέσα σε λίγα μόλις δευτερόλεπτα και χωρίς καμία τροποποίηση. Εικόνα 44: Οι πόροι και οι επιτρεπτές HTTP μέθοδοι για το WapoAdminTool APi Όπως στο προηγούμενο παράδειγμα, ο χρήστης πρέπει να επιλέξει το xmi αρχείο, που περιγράφει το PSM μοντέλο του WapoAdminTool API και το φάκελο στον οποίο θα αποθηκευτούν τα αρχεία του παραγόμενου κώδικα. Όπως φαίνεται και στην Εικόνα 45, ο μετασχηματισμός παράγει τρεις φακέλους μέσα στον προεπιλεγμένο φάκελο. Οι φάκελοι αυτοί είναι οι υποφάκελοι js, views και dev. Ο υποφάκελος js περιέχει όλα τα αρχεία, που είναι γραμμένα σε Javascript. Πιο συγκεκριμένα, ο υποφάκελος js περιέχει 110

112 Σχεδίαση και ανάπτυξη διαδικτυακής εφαρμογής πελάτη για διαδικτυακές υπηρεσίες τύπου REST τους ελεγκτές της διαδικτυακής εφαρμογής πελάτη, το αρχείο services.js και το αρχείο app.js. Ο υποφάκελος views περιέχει αρχεία HTML, τα οποία είναι οι όψεις, τις οποίες επιλέγει να εμφανίσει το index.html ανάλογα με τις κατευθύνσεις, που δίνει το app.js. Ο υποφάκελος dev περιέχει όλα τα αρχεία, που απαιτούν την παρέμβαση προγραμματιστή. Εικόνα 45: Δομή των παραγόμενων φακέλων για το WapoAdminTool API Client Η εφαρμογή πελάτη είναι έτοιμη προς κατανάλωση αντιγράφοντας απλώς τον φάκελο WapoAdminToolAPIClient και την αντίστοιχη υπηρεσία στο φάκελο webapps ενός εξυπηρετητή και ρυθμίζοντας κατάλληλα τη βάση δεδομένων. Για την δοκιμή της χρησιμοποιήθηκε ένας Tomcat Server και εκτελέστηκε τοπικά στην προεπιλεγμένη διεύθυνση Στη συνέχεια θα παρουσιαστεί το γραφικό περιβάλλον της εφαρμογής πελάτη και κάποια δοκιμαστικά αιτήματα και οι αποκρίσεις του διακομιστή. Για την απόκτηση πρόσβασης εμφανίζεται αρχικά η σελίδα για την εισαγωγή των στοιχείων ταυτοποίησης (Εικόνα 46). Εικόνα 46: Σελίδα για την υλοποίηση του authentication Δημιουργία νέου λογαριασμού Στην περίπτωση, που δεν διατίθεται λογαριασμός για ταυτοποίηση δίνεται η δυνατότητα δημιουργίας ενός νέου λογαριασμού. Επειδή, ο πόρος Users, που χρησιμοποιείται για την ταυτοποίηση είναι σχετικός από τον πόρο accounts, δημιουργείται και ένα στιγμιότυπο για τον πόρο accounts. Τα αίτηματα POST, που πραγματοποιούνται στέλνονται με την ταυτότητα guest για να γίνουν αποδεκτά από την υπηρεσία. 111

113 Αίτημα POST account POST /wapoadmintoolapi/api/accounts HTTP/1.1 Host: localhost:8085 Connection: keep-alive Content-Length: 116 Accept: application/json, text/plain, */* {state: "Greece", name: "Name", postalcode: "14377", city: "Thessasoniki", phone: "2310", } address:"ag. Dimitriou" city:"thessasoniki" name:"name" phone:"2310" postalcode:"14377" state:"greece" Αίτημα POST User POST /wapoadmintoolapi/api/accounts/1/users HTTP/1.1 Host: localhost:8085 Connection: keep-alive Content-Length: 176 Accept: application/json, text/plain, */* { " @auth.com", accesstoken: "1234", mobile: "6987", lastname: "Lastname", password: "1234", } accesstoken:"1234" " @auth.com" firstname:"firstname" lastname:"lastname" mobile:"6987" password:"1234" role:"role" title:"title1" username:"user" 112

114 Σχεδίαση και ανάπτυξη διαδικτυακής εφαρμογής πελάτη για διαδικτυακές υπηρεσίες τύπου REST Φόρμα για τη δημιουργία λογαριασμού Εικόνα 47: Φόρμα δημιουργίας account 113

115 Αποστολή αιτήματος για authentication Αίτημα Εικόνα 48: Φόρμα δημιουργίας νέου user Accept: application/json, text/plain, */* Accept-Encoding: gzip, deflate, sdch, br Accept-Language: el-gr,el;q=0.8 Authorization: Basic MTY2NzA6MTY2Njc= Connection: keep-alive Host: localhost:8085 Referer: Αν ολοκληρωθεί με επιτυχία η ταυτοποίηση, ο χρήστης μεταφέρεται στην αρχική σελίδα. Στην αντίθετη περίπτωση εμφανίζεται ένα μήνυμα αποτυχίας (Εικόνα 49). 114

116 Σχεδίαση και ανάπτυξη διαδικτυακής εφαρμογής πελάτη για διαδικτυακές υπηρεσίες τύπου REST Εικόνα 49: Μήνυμα αποτυχίας ταυτοποίησης Εικόνα 50: Αρχική σελίδα του WapoAdminTool API Client Όπως φαίνεται στην Εικόνα 50, στην αρχική σελίδα εμφανίζονται οι πόροι, που δεν είναι σχετικοί από άλλους πόρους κι επιλέγοντας ένα από τα κουμπιά See More, παρουσιάζεται η λίστα περιεχόμενων των αντίστοιχων πόρων, όπως φαίνεται και στην παρακάτω εικόνα, και η δυνατότητα δημιουργίας νέων αντικειμένων. Για την εμφάνιση αυτής της λίστας στάλθηκε ένα αίτημα προς τον διακομιστή και η απόκριση του παρουσιάστηκε, όπως φαίνεται παραπάνω (Εικόνα 51). 115

117 Ανάκτηση λίστας Currencies Αίτημα GET /wapoadmintoolapi/api/currencies HTTP/1.1 Host: localhost:8085 Accept: application/json, text/plain, */* Authorization: Basic MTY2NzA6MTY2Njc= Απόκριση Εικόνα 51: Λίστα αντικειμένων Currencies Ανάκτηση συγκεκριμένου αντικειμένου του πόρου Currencies Αίτημα GET /wapoadmintoolapi/api/currencies/3 HTTP/1.1 Host: localhost:8085 Accept: application/json, text/plain, */* Authorization: Basic MTY2NzA6MTY2Njc= 116

118 Σχεδίαση και ανάπτυξη διαδικτυακής εφαρμογής πελάτη για διαδικτυακές υπηρεσίες τύπου REST Απόκριση Δημιουργία ενός Currency Αίτημα Εικόνα 52: Ανάκτηση συγκεκριμένου στιγμιότυπου του πόρου currencies POST /wapoadmintoolapi/api/currencies HTTP/1.1 Host: localhost:8085 Content-Length: 778 Accept: application/json, text/plain, */* Authorization: Basic MTY2NzA6MTY2Njc= {linklist: [{idtype: "0", linkrel: "Get all currenciess", linktype: "Sibling", }, ], } abbreviation:"currency" linklist:[{idtype: "0", linkrel: "Get all currenciess", linktype: "Sibling", }, ] 0:{idType: "0", linkrel: "Get all currenciess", linktype: "Sibling", } idtype:"0" linkrel:"get all currenciess" linktype:"sibling" linkuri:" linkverb:"get" 1:{idType: "0", linkrel: "Create a new currencies", linktype: "Sibling", } 117

119 idtype:"0" linkrel:"create a new currencies" linktype:"sibling" linkuri:" linkverb:"post" 2:{idType: "3", linkrel: " SymbolName", linktype: "Child", } idtype:"3" linkrel:"symbolname" linktype:"child" linkuri:" linkverb:"get" name:"currency" symbol:"currency" Φόρμα δημιουργίας νέου currency Εικόνα 53: Φόρμα για τη δημιουργία νέου currency 118

120 Σχεδίαση και ανάπτυξη διαδικτυακής εφαρμογής πελάτη για διαδικτυακές υπηρεσίες τύπου REST Διαγραφή ενός account Αίτημα Εικόνα 54: Διαγραφή ενός account DELETE /wapoadmintoolapi/api/accounts/1 HTTP/1.1 Host: localhost:8085 Accept: application/json, text/plain, */* Authorization: Basic MTY2NzA6MTY2Njc= Απόκριση Content-Type: application/json Date: Tue, 25 Oct :04:08 GMT Server: Apache-Coyote/1.1 Transfer-Encoding: chunked {accountsid: "1", address: "Ag. Dimitriou", city: "Thessasoniki", } 1. accountsid:"1" 2. address:"ag. Dimitriou" 3. city:"thessasoniki" 4. linklist:[{idtype: "0", linkrel: "Create a new accounts", linktype: "Parent", }, ] 1. 0:{idType: "0", linkrel: "Create a new accounts", linktype: "Parent", } 119