Αυτόματη παραγωγή γραφικών διεπαφών πελάτη από προδιαγραφές διαδικτυακών υπηρεσιών σε Swagger

ΑΡΙΣΤΟΤΕΛΕΙΟ ΠΑΝΕΠΙΣΤΗΜΙΟ ΘΕΣΣΑΛΟΝΙΚΗΣ ΠΟΛΥΤΕΧΝΙΚΗ ΣΧΟΛΗ Τμήμα Ηλεκτρολόγων Μηχανικών και Μηχανικών Υπολογιστών Εργαστήριο Επεξεργασίας Πληροφορίας και Υπολογισμών Διπλωματική εργασία Αυτόματη παραγωγή γραφικών διεπαφών πελάτη από προδιαγραφές διαδικτυακών υπηρεσιών σε Swagger Διπλωματική εργασία της Βασιλικής Σιδέρη-Λαμπρέτσα Αριθμός Ειδικού Μητρώου: 7525 Επιβλέπων Επίκουρος Καθηγητής Ανδρέας Λ.Συμεωνίδης Θεσσαλονίκη, Ιούνιος 2017

Ευχαριστίες Ευχαριστίες Αρχικά, θα ήθελα να ευχαριστήσω θερμά τον κ. Ανδρέα Συμεωνίδη για την βοήθεια και την καθοδήγηση του σε όλη τη διάρκεια της εκπόνησης της παρούσας διπλωματικής εργασίας. Επίσης ευχαριστώ τους γονείς μου και τον αδερφό μου, Έλλη, Σπύρο και Γιώργο γιατί μου δίνουν πάντα τη δύναμη να συνεχίζω. Τέλος, θα ήθελα να ευχαριστήσω ιδιαίτερα τη Μαρία, τη Ναταλία, τη Χριστίνα και την Αρήτη για τη στήριξη και την υπομονή τους, καθώς και όλους τους φίλους για τις όμορφες στιγμές, όλα αυτά τα χρόνια. 2 Σ ε λ ί δ α

Περίληψη Περίληψη Τα τελευταία χρόνια, με την επιστήμη της τεχνολογίας λογισμικού να εξελίσσεται συνεχώς, η επιδίωξη της βιομηχανίας λογισμικού και της ακαδημαϊκής κοινότητας είναι η επιτυχής και παράλληλα ποιοτική εκπλήρωση των απαιτήσεων κάθε ξεχωριστού πελάτη λογισμικού. Πιο συγκεκριμένα, στο πεδίο των διαδικτυακών εφαρμογών, έχει παρατηρηθεί τεράστια άνθιση μετά την εισαγωγή του αρχιτεκτονικού πρότυπου REST το 2000, με τη διδακτορική διατριβή του Roy Thomas Fielding. Η καινοτομία που εισήγαγε το αρχιτεκτονικό αυτό πρότυπο, ήταν η εισαγωγή περιορισμών που περιγράφουν όχι μόνο την αρχιτεκτονική των διαδικτυακών εφαρμογών, αλλά και του διαδικτύου σαν ολότητα. Επικράτησε, μεταξύ άλλων, λόγω της απλότητας και της δυνατότητας εύκολης επεξεργασίας και επέκτασης των εφαρμογών που βασίζονται σε αυτή. Η κυριάρχηση του αρχιτεκτονικού αυτού προτύπου, αλλά και η αυξανόμενη ανάγκη της αγοράς για RESTful διαδικτυακές υπηρεσίες, οδήγησε στην ανάπτυξη εργαλείων που επιτρέπουν την αυτοματοποιημένη παραγωγή εφαρμογών που καταναλώνουν ή παράγουν Web APIs, επιτρέποντας τη μείωση του χρόνου δημιουργίας και το κόστος παραγωγής τους. Η ανάπτυξη των παραπάνω εργαλείων όμως, οδήγησε αναπόφευκτα στην απαίτηση υλοποίησης ολοκληρωμένων γραφικών διεπαφών χρήστη, έτοιμων προς εκτέλεση, χωρίς την παρέμβαση προγραμματιστή, δίνοντας τη δυνατότητα γραφικής εποπτείας των APIs, αλλά και ελέγχου. Η παρούσα διπλωματική εργασία φιλοδοξεί να συνεισφέρει σε αυτόν τον τομέα, δηλαδή τον τομέα της αυτοματοποιημένης ανάπτυξης διαδικτυακών εφαρμογών πελάτη. Πιο συγκεκριμένα, μέσω της παρούσας εφαρμογής προτείνεται ένας end-to-end μηχανισμός, ο οποίος αποτελεί μια ολοκληρωμένη λύση για την αυτοματοποίηση της διαδικασίας ανάπτυξης γραφικών διεπαφών χρήστη, χωρίς να απαιτεί την παρέμβαση προγραμματιστή για την εγκατάσταση και τη λειτουργία του. Για την ανάπτυξη της εφαρμογής χρησιμοποιούνται αρχεία προδιαγραφών τύπου OpenAPI, που περιγράφουν την οντολογία του API, διαχωρίζοντας με αυτό τον τρόπο την εφαρμογή πελάτη από την ίδια τη διαδικτυακή υπηρεσία. Τέλος, ο μηχανισμός που αναπτύχθηκε είναι υλοποιημένος με το framework Angular2+ της JavaScript. Βασιλική Σιδέρη-Λαμπρέτσα vssideri@auth.gr 3 Σ ε λ ί δ α

Abstract Abstract Automatic user interface generation using Swagger specification Over the past years and while the science of software technology has been constantly evolving, the software industry and academic community alike attempt to successfully and qualitatively meet the requirements of every individual software client. More specifically in the web application domain, a significant growth has been observed since the introduction of the REST architectural model in 2000, by Roy Thomas Fielding. The novelty of this architectural model is the introduction of restrictions, which describe the architecture of not only web applications, but that of the internet as a whole. This model has prevailed, among other reasons, due to its simplicity and ability to easily process and expand the applications based on it. The dominance of this architectural model, along with the ever growing market demand for RESTful web applications, has led to the development of tools that allow the automated generation of applications that consume or produce Web services within a reduced timeframe and at a lower production cost. As a consequence, the development of such tools, has inevitably led to a demand for integrating ready to use graphical user interfaces that do not rely on the developer s intervention, but allow the graphical monitoring as well as control of the services and their data. This diploma thesis attempts to contribute in this field; that of automated client web application development. More specifically, given a web service, an end-to-end mechanism has been designed and developed that automates the graphical user interface development process. OpenAPI specification files are used for the definition of the application and the API internal structure, thus separating the client application from that of the web service. The mechanism developed in implemented under the JavaScript Angular2+ framework. Vasiliki Sideri-Lampretsa vssideri@auth.gr Thessaloniki, June 2017 4 Σ ε λ ί δ α

Περιεχόμενα Περιεχόμενα Διπλωματική εργασία... 1 Ευχαριστίες... 2 Περίληψη... 3 Abstract... 4 Περιεχόμενα... 5 Λίστα Εικόνων... 8 Λίστα Πινάκων... 10 1. Εισαγωγή... 11 1.1 Στόχος διπλωματικής εργασίας... 11 1.2 Διάρθρωση Κειμένου... 11 2. Θεωρητικό και τεχνολογικό υπόβαθρο... 13 2.1 Τεχνολογία Λογισμικού... 13 2.1.1 Γενικά... 13 2.1.2 Ορισμός... 13 2.1.3 Διαδικασία ανάπτυξης και κύκλος ζωής λογισμικού... 14 2.2 Διαδίκτυο... 16 2.2.1 Ιστορικά... 16 2.2.2 Παγκόσμιος Ιστός... 16 2.2.2.1 HTML... 18 2.2.2.2 Πόροι του Παγκόσμιου Ιστού... 19 2.2.2.3 URIs... 19 2.2.2.4 HTTP... 19 2.3 Web Services... 22 2.4 Service-Oriented Architecture (SOA)... 24 2.5 Web APIs... 26 2.6 REST και ROA... 27 5 Σ ε λ ί δ α

Περιεχόμενα 2.6.1 ΑΡΧΗ 1 Οτιδήποτε είναι πόρος και ταυτοποιέιται με ένα μοναδικό αναγνωριστικό (Addressability)... 28 2.6.2 ΑΡΧΗ 2 Η Ενιαία διεπαφή (The Uniform, Constrained Interface)... 29 2.6.3 ΑΡΧΗ 3 Οι πόροι μπορούν να έχουν πολλαπλές αναπαραστάσεις... 29 2.6.4 ΑΡΧΗ 4 Επικοινωνία χωρίς μνήμη (Communicate Statelessly)... 30 2.6.5 ΑΡΧΗ 5 HATEOAS (Hypermedia As The Engine Of Application State)... 30 2.7 Richardson Maturity Model... 31 2.8 Swagger... 32 2.9 OpenApi Specification... 35 2.9.1 Τεχνικά χαρακτηριστικά OpenAPI Specification... 36 2.9.1.1 Schema... 37 2.10 MVC (Model View Controller)... 41 2.10.1 Αρχιτεκτονικό πρότυπο Μοντέλο-Όψη-Ελεγκτής... 41 2.11 S-CASE... 42 2.12 Bootstrap... 43 2.13 JSON... 43 2.14 YAML... 43 2.15 Angular 2+... 44 2.16 TypeScript... 45 2.17 Node.js... 46 2.18 NPM... 46 3. Σχετική βιβλιογραφία... 48 3.1 Clients και σύγχρονες τεχνολογίες κατανάλωσης Web API... 48 3.1.1 Alchemy Rest Client Generator... 48 3.1.2 Fiware Rest Client Generator (eclipse plugin)... 48 3.1.3 Restlet Studio... 49 3.1.4 Auto Rest... 49 3.1.5 Ολοκληρωμένες γραφικές εφαρμογές για τον έλεγχο της λειτουργίας των APIs... 49 3.1.6 Ολοκληρωμένες εφαρμογές διεπαφής χρήστη... 50 3.2 Συμπεράσματα... 50 4. Μεθοδολογία... 51 4.1 Γενικά... 51 4.2 Δομή της εφαρμογής... 51 6 Σ ε λ ί δ α

Περιεχόμενα 4.3 YAML & JSON... 53 4.3.1 Περιορισμοί OpenAPI Specification αρχείου... 53 4.4 Swagger Code Generator... 56 4.5 Parser Ανάλυση JSON... 58 4.5.1 Model... 59 4.5.2 Path... 59 4.5.3 Function... 60 4.5.4 Λειτουργία JsonProcessingService... 60 4.6 Εφαρμογή Πελάτη... 66 4.6.1 AppComponent AppView... 67 4.6.2 NavigationComponent NavigationView... 67 4.6.3 MainComponent MainView... 68 4.6.4 ResourceComponent ResourceComponentView... 69 4.6.5 ResourceViewComponent ResourceViewComponentView... 70 4.6.6 ResourceEditComponent ResourceEditComponentView... 72 4.6.7 ViewController... 73 4.7 Υπηρεσίες που έχουν παραχθεί από το Swagger Code Generator... 76 4.8 Αρχικοποίηση εφαρμογής... 77 5. Πειράματα-Αποτελέσματα... 80 5.1 Κύρια οθόνη διεπαφής... 81 5.2 Οθόνη προβολής συλλογής πόρων... 81 5.3 Οθόνη δημιουργίας νέου πόρου... 83 5.4 Οθόνη προβολής λεπτομερειών πόρου... 84 5.5 Οθόνη προβολής συλλογής υποπόρων... 86 5.6 Οθόνη προβολής λεπτομερειών υποπόρου... 87 5.7 Οθόνη επεξεργασίας πόρου... 88 5.8 Οθόνη διαγραφής πόρου... 88 6. Συμπεράσματα και μελλοντική εργασία... 90 Βιβλιογραφία... 91 ΠΑΡΑΡΤΗΜΑ... 94 RestReviews... 94 7 Σ ε λ ί δ α

Λίστα Εικόνων Λίστα Εικόνων Εικόνα 1 Τεχνολογία Λογισμικού... 14 Εικόνα 2 Κύκλος ζωής Λογισμικού... 15 Εικόνα 3 Η αλήθεια γύρω από την Τεχνολογία Λογισμικού... 15 Εικόνα 4 Εξέλιξή του διαδικτύου... 17 Εικόνα 5 Παράδειγμα HTML σελίδας... 18 Εικόνα 6 Server - Client communication... 20 Εικόνα 7 Παράδειγμα αίτησης GET - POST... 21 Εικόνα 8 Αρχιτεκτονική προσανατολισμένη στον πόρο - ROA... 25 Εικόνα 9 Διαφορετικές αναπαραστάσεις ενός πόρου... 29 Εικόνα 10 HATEOAS... 31 Εικόνα 11 Επίπεδα ωριμότητας Richardson - RMM... 32 Εικόνα 12 Λογότυπο Swagger... 34 Εικόνα 13 Λογότυπο OpenAPI Initiative... 36 Εικόνα 14 Επιτρεπόμενοι τύποι δεδομένων στο OpenAPI πρότυπο... 37 Εικόνα 15 Ορισμοί σε αρχείο YAML... 40 Εικόνα 16 Αρχικά αντικείμενσα σε αρχείο JSON... 40 Εικόνα 17 Αντικείμενο Paths όπως αυτό ορίζεται σε YAML αρχείο... 41 Εικόνα 18 Το μοτίβο μοντέλο - όψη - ελεγκτής... 42 Εικόνα 19 Λογότυπο Angular... 44 Εικόνα 20 Αρχιτεκτονική Angular... 45 Εικόνα 21 Λογότυπο node.js... 47 Εικόνα 22 Αρχιτεκτονική εφαρμογής... 52 Εικόνα 23 Swagger 2 vs. OpenAPI 3... 54 Εικόνα 24 Ορισμοί γραμμένοι σε αρχείο YAML... 55 Εικόνα 25 Μορφή παραμέτρων γραμμένες σε αρχείο YAML... 55 Εικόνα 26 Αναφορά σε αντικείμενα στις απαντήσεις και παραμέτρους... 56 Εικόνα 27 Βασικά μοντέλα ανάλυσης από τον parser... 59 Εικόνα 28 Επισκόπηση αρχιτεκτονικής πελάτη... 79 Εικόνα 29 Οντολογία της RESTEventManage... 80 8 Σ ε λ ί δ α

Λίστα Εικόνων Εικόνα 30 Αρχική σελίδα... 81 Εικόνα 31 Home και αναπτυσσόμενο παράθυρο... 81 Εικόνα 32 Οθόνη κύριου πόρου... 82 Εικόνα 33 Επιλογές στην οθόνη βασικού πόρου... 83 Εικόνα 34 Οθόνη δημιουργίας νέου πόρου... 84 Εικόνα 35 Οθόνη προβολής λεπτομερειών πόρου... 85 Εικόνα 36 Λίστα με επιτρεπτές ενέργειες για λεπτομέρειες πόρου... 86 Εικόνα 37 Οθόνη προβολής υποπόρου venues... 86 Εικόνα 38 Λεπτομέρειες υποπόρου με ενσωμάτωση χάρτη... 87 Εικόνα 39 Οθόνη ενημέρωσης χαρακτηριστικών πόρου... 88 Εικόνα 40 Οθόνη με αναδυόμενο παράθυρο για τον έλεγχο της διαγραφής... 89 9 Σ ε λ ί δ α

Λίστα Πινάκων Λίστα Πινάκων Πίνακας 1 HTTP μέθοδοι... 21 Πίνακας 2 Κωδικοί HTTP απόκρισης... 22 Πίνακας 3 Τεχνολογίες WebServices... 24 Πίνακας 4 Περιγραφή URI... 28 Πίνακας 5 Βασικά αντικείμενα στο πρότυπο OpenAPI... 38 Πίνακας 6 Ονοματολογία συνάρτησης... 57 Πίνακας 7 Συναρτήσεις και περιγραφή αυτών της υπηρεσίας JsonProcessingService... 60 Πίνακας 8 Συνάρτηση buildpathfamily... 62 Πίνακας 9 Σχήμα 1... 63 Πίνακας 10 Σχήμα 2... 63 Πίνακας 11 Σχήμα 3... 64 Πίνακας 12 Σχήμα 4... 64 Πίνακας 13 Συνάρτηση findresourcessecodlevel... 65 Πίνακας 14 Συνάρτηση findresourcesrelations... 66 Πίνακας 15 Συνάρτηση initializeroutes... 68 Πίνακας 16 Συναρτήσεις του Resource Component και περιγραφή αυτών... 69 Πίνακας 17 Συνάρτηση defaultservice[functionname](...params)... 70 Πίνακας 18 Συναρτήσεις ResourceView Component και περιγραφή αυτών... 71 Πίνακας 19 Συνάρτηση displaymodelconstructor... 72 Πίνακας 20 Συναρτήσεις του ResourceEdit Component και περιγραφή αυτών... 73 Πίνακας 21Συναρτήσεις του ViewController και περιγραφή αυτών... 74 Πίνακας 22 Συνάρτηση getparameterarray... 75 Πίνακας 23 Συνάρτηση getfunctionname... 76 10 Σ ε λ ί δ α

Εισαγωγή 1. Εισαγωγή 1.1 Στόχος διπλωματικής εργασίας Την τελευταία δεκαετία, η ανάπτυξη διαδικτυακών εφαρμογών παρουσιάζει ραγδαία αύξηση, προσπαθώντας να καλύψει τις ολοένα και μεγαλύτερες ανάγκες και απαιτήσεις που δημιουργούνται. Λόγω αυτής της αύξησης της ανάπτυξης, δημιουργείται η ανάγκη για την αύξηση της παραγωγής πελατών που θα καταναλώνουν τις παραγόμενες διαδικτυακές υπηρεσίες, μειώνοντας ταυτόχρονα το κόστος και το χρόνο παραγωγής τους. Στην κατεύθυνση αυτή, η παρούσα διπλωματική εργασία αποσκοπεί στην ανάπτυξη ενός εργαλείου που θα προσπαθήσει να προτείνει μια ολοκληρωμένη λύση για την αυτοματοποίηση της διαδικασίας ανάπτυξης γραφικών διεπαφών χρήστη με τρόπο αφηρημένο, χωρίς δηλαδή η υλοποίηση να εξαρτάται από κάποια συγκεκριμένη διαδικτυακή υπηρεσία, αρκεί αυτή να συμφωνεί με το αρχιτεκτονικό πρότυπο REST. Για τη σχεδίαση και ανάπτυξη της παρούσας εφαρμογής, χρησιμοποιούνται αρχεία προδιαγραφών τύπου OpenAPI τα οποία περιγράφουν πλήρως τη δομή και λειτουργικότητα του API χωρίς να χρειάζεται να εξεταστεί περαιτέρω το ίδιο το API. Με βάση τα αρχεία αυτά και τη χρήση κώδικα που παράγει αυτόματα το εργαλείο Swagger Code Generator, σχηματίζονται με γενικό τρόπο οι γραφικές διεπαφές πελάτη και υλοποιείται επίσης η λειτουργικότητα τους. 1.2 Διάρθρωση Κειμένου Στην ενότητα αυτή παρουσιάζεται συνοπτικά το περιεχόμενο των επιμέρους κεφαλαίων του εγγράφου καθώς και το πώς αυτά διαρθρώνονται στην έκταση του. Στο τρέχον κεφάλαιο (κεφάλαιο 1) παρατίθεται ο στόχος της διπλωματικής και η διάρθρωση του εγγράφου. Στο κεφάλαιο 2 γίνεται αναλυτική περιγραφή του θεωρητικού και τεχνολογικού υπόβαθρου βάσει της τρέχουσας βιβλιογραφίας, αλλά και των αναγκών της διπλωματικής. Βασικές έννοιες που αναλύονται είναι αυτές της διαδικτυακής υπηρεσίας και της διαδικτυακής εφαρμογής, της Αρχιτεκτονικής REST, των 11 Σ ε λ ί δ α

Εισαγωγή προδιαγραφών και εργαλείων Swagger, αλλά και των εργαλείων που χρησιμοποιούνται για την ανάπτυξη της εφαρμογής πελάτη. Στο κεφάλαιο 3 γίνεται μία συνοπτική παρουσίαση των τεχνολογιών για την ανάπτυξη αυτοματοποιημένων διαδικτυακών εφαρμογών και ελέγχου των APIs που υπάρχουν σήμερα. Στο κεφάλαιο 4 αναλύεται η μεθοδολογία που ακολουθήθηκε για την ανάλυση των Swagger προδιαγραφών και την υλοποίηση των αυτόματων διεπαφών πελάτη, παραθέτοντας κομμάτια κώδικα όπου κρίνεται απαραίτητo. Στο κεφάλαιο 5 παρουσιάζονται παραδείγματα διαδικτυακών εφαρμογών που χρησιμοποιήθηκαν για τον έλεγχο της λειτουργίας της εφαρμογής και παρατίθενται σχήματα απεικόνισης των διεπαφών που δημιουργούνται. Στο κεφάλαιο 6 προτείνονται μελλοντικές επεκτάσεις και αναβαθμίσεις της εφαρμογής, ώστε αυτή να εξελιχθεί σε ένα πιο ολοκληρωμένο εργαλείο, καλύπτοντας περισσότερες ανάγκες. 12 Σ ε λ ί δ α

Θεωρητικό και τεχνολογικό υπόβαθρο 2. Θεωρητικό και τεχνολογικό υπόβαθρο 2.1 Τεχνολογία Λογισμικού 2.1.1 Γενικά Το λογισμικό διαποτίζει τον κόσμο μας σε τέτοιο βαθμό ώστε πολλές φορές να θεωρούμε απόλυτα φυσιολογικό το ρόλο που παίζει προκειμένου να γίνεται η ζωή μας πιο άνετη, αποτελεσματικότερη και παραγωγικότερη. Μπορεί κανείς να ψηλαφίσει την ύπαρξή του σε κάθε πτυχή της ζωής μας, συμπεριλαμβανομένων κρίσιμων συστημάτων που επηρεάζουν την υγεία και την ασφάλειά μας. Το λογισμικό προσφέρει το σημαντικότερο προϊόν στην εποχή μας, την πληροφόρηση. Μετατρέπει συλλεγόμενα στοιχεία σε πιο χρήσιμη μορφή, διαχειρίζεται επιχειρηματικές πληροφορίες, ενισχύει την ανταγωνιστικότητα, παρέχει μία πύλη στα παγκόσμια δίκτυα πληροφόρησης και τα μέσα για την απόκτηση πληροφοριών όλων των μορφών. Οι σημαντικές βελτιώσεις στις επιδόσεις του υλικού, οι αλλαγές στην αρχιτεκτονική των υπολογιστών και τεράστιες αναβαθμίσεις στη μνήμη και την αποθηκευτική ικανότητα σε συνδυασμό με την επιστήμη της τεχνολογίας λογισμικού, έχουν προσδώσει στο λογισμικό τις τεράστιες δυνατότητες που έχει σήμερα. 2.1.2 Ορισμός Σύμφωνα με το IEEE Standard 610.12, ως τεχνολογία λογισμικού ορίζεται «ο τομέας που πραγματεύεται τεχνικές, μεθοδολογίες, πρακτικές και εργαλεία για την συστηματική, μεθοδική και ποσοτικοποιημένη προδιαγραφή, σχεδίαση, υλοποίηση, έλεγχο, και συντήρηση συστημάτων λογισμικού υψηλής ποιότητας και εντός δεδομένου προϋπολογισμού και χρόνου εκτέλεσης» [1]. Με άλλα λόγια η Τεχνολογία λογισμικού αποτελεί μια διεπιστημονική περιοχή που εμπλέκει την επιστήμη των υπολογιστών, του υλικού (hardware), τεχνολογίες διαχείρισης (βάσεις δεδομένων, οργάνωση προσπέλασης και χρήση δεδομένων) και περιβάλλοντα διεπαφών χρήστη (user interfaces). 13 Σ ε λ ί δ α

Θεωρητικό και τεχνολογικό υπόβαθρο Επιπλέον τη διέπουν κανονισμοί, ενώ έχει και νομικές διαστάσεις [2]. Στις παρακάτω εικόνες μπορεί κανείς να διακρίνει τις πιθανές διαδρομές, αλλά και τον κύκλο ανάπτυξης λογισμικού. Εικόνα 1 Τεχνολογία Λογισμικού 2.1.3 Διαδικασία ανάπτυξης και κύκλος ζωής λογισμικού Διάφορες μεθοδολογίες έχουν αναπτυχθεί για να παρέχουν τις κατευθύνσεις για τις διεργασίες που εμπλέκονται στην ανάπτυξη λογισμικού. Γνωστά μοντέλα αποτελούν το μοντέλο καταρράκτη (waterfall), ταχείας προτυποποίησης (Rapid prototyping), ακραίου προγραμματισμού (Extreme programming and agile processes), συγχρονισμού και σταθερότητας (Synchronize and stabilize model), σπειροειδούς μοντέλου (Spiral). Συχνά τα μοντέλα συνδυάζονται και παρέχουν μία υβριδική προσέγγιση. Σε γενικές γραμμές όμως κάθε μοντέλο κύκλου ζωής ανάπτυξης λογισμικού ακολουθεί κάποια συγκεκριμένα βήματα [3]: Ανάλυση απαιτήσεων και καθορισμός προδιαγραφών Σχεδίαση λογισμικού Υλοποίηση λογισμικού Έλεγχος λειτουργικών μονάδων Παράδοση λογισμικού Συντήρηση λογισμικού 14 Σ ε λ ί δ α

Θεωρητικό και τεχνολογικό υπόβαθρο Εικόνα 2 Κύκλος ζωής Λογισμικού Εικόνα 3 Η αλήθεια γύρω από την Τεχνολογία Λογισμικού 15 Σ ε λ ί δ α

Θεωρητικό και τεχνολογικό υπόβαθρο 2.2 Διαδίκτυο 2.2.1 Ιστορικά Το διαδίκτυο είναι μία προέκταση της τεχνολογίας των δικτύων των υπολογιστών. Οι πρώτοι υπολογιστές λειτουργούσαν ανεξάρτητα μεταξύ τους. Η διασύνδεση των υπολογιστών μεταξύ οργανισμών ξεκίνησε τις δεκαετίες του 1960-1970. Ταυτόχρονα εκτελούνταν πειράματα που είχαν σαν στόχο τη σύνδεση ολόκληρων δικτύων μεταξύ τους για στρατιωτικές ή ερευνητικές εφαρμογές, όπως το ARPANET, NPL, Merit CYCLADES. Το ARPANET, συγκεκριμένα, αναπτύχθηκε το 1969 από την Υπηρεσία Προηγμένων Ερευνητικών Έργων (Advanced Research Projects Agency ARPA) του Υπουργείου άμυνας των Η.Π.Α. και ήταν το πρώτο επιχειρησιακό δίκτυο μεταγωγής πακέτων. Αξίζει να αναφέρουμε πως το ARPANET ξεκίνησε τη λειτουργία του σε 4 περιοχές, ενώ σήμερα το πλήθος των κόμβων ανέρχεται σε εκατοντάδες εκατομμύρια και το πλήθος των χρηστών σε δισεκατομμύρια [4]. 2.2.2 Παγκόσμιος Ιστός Ο παγκόσμιος Ιστός, ή αλλιώς World Wide Web (WWW), είναι μια αρχιτεκτονική για την προσπέλαση διασυνδεδεμένων εγγράφων τα οποία κατανέμονται σε εκατομμύρια μηχανήματα σε ολόκληρο το διαδίκτυο. Στις αρχές του 20 ου αιώνα ο παγκόσμιος ιστός έφτασε από το να είναι ένας τρόπος διανομής δεδομένων στην πιο δημοφιλή εφαρμογή του διαδικτύου. Σε αυτό οδήγησε η απλότητα του και ο πλούτος των πληροφοριών που περιέχει, κάτι που τον κατέστησε εύχρηστο και ιδιαίτερα χρήσιμο στους αρχάριους χρήστες καθώς δεν απαιτούσε ιδιαίτερη εκπαίδευση για τη χρήση του. Η κολοσσιαία δημοτικότητά του οδήγησε στην αντίληψη πως ο παγκόσμιος ιστός ταυτίζεται με το ίδιο το διαδίκτυο. Η αντίληψη αυτή, όπως μπορεί κανείς να αντιληφθεί είναι λανθασμένη καθώς το διαδίκτυο είναι ένα παγκόσμιο δίκτυο συνδεδεμένων υπολογιστών, ενώ ο παγκόσμιος ιστός είναι μια από τις πολλές υπηρεσίες του διαδικτύου και επιτρέπει τη τις συνδέσεις αρχείων κειμένου και διάφορων άλλων πόρων σε όλο τον κόσμο, συνδεδεμένων με υπερσυνδέσμους (hyperlinks) και URIs (Uniform Resource Identifiers) [5]. 16 Σ ε λ ί δ α

Θεωρητικό και τεχνολογικό υπόβαθρο Εικόνα 4 Εξέλιξή του διαδικτύου Η ιστορία του ξεκινάει το 1989 στο ευρωπαϊκό κέντρο πυρηνικής έρευνας CERN. Εμπνευστής του ήταν ένας φυσικός του CERN που φέρει το όνομα Tim Berners Lee, ο οποίος προσπάθησε να δώσει λύση στο πρόβλημα της ανταλλαγής και διαμοιρασμού δεδομένων και αποτελεσμάτων μεταξύ διαφορετικών ομάδων μέσα στο ερευνητικό κέντρο. Η καινοτομία του Tim Berners Lee ήταν ότι κατάφερε να παντρέψει το υπερκείμενο (hypertext) με το διαδίκτυο. Στο βιβλίο του Weaving The Web, εξηγεί ότι είχε επανειλημμένως προτείνει τη σύνδεση των δύο τεχνολογιών σε αμφότερες τις τεχνικές κοινότητες αλλά χωρίς να έχει ιδιαίτερη απήχηση και για αυτό το λόγο ανέλαβε να εκπονήσει αυτό το πρότζεκτ μόνος του. Για την επίτευξη αυτού του στόχου ανέπτυξε τρεις θεμελιώδεις τεχνολογίες, οι οποίες αποτελούν τη βάση του σημερινού Ιστού. Οι τεχνολογίες αυτές είναι: Την HyperText Markup Language (HTML) Το Hypertext Transfer Protocol (HTTP) Ένα σύστημα μοναδικών αναγνωριστικών για τους πόρους στον Ιστό, το Universal Document Identifier, το οποίο μετεξελίχθηκε στο Uniform Resource Locator και Uniform Resource Identifier 17 Σ ε λ ί δ α

Θεωρητικό και τεχνολογικό υπόβαθρο 2.2.2.1 HTML Η γλώσσα Σήμανσης Υπερκειμένου ή αλλιώς HTML (HyperText Markup Language) είναι μια γλώσσα που περιγράφει πώς πρέπει να μορφοποιούνται τα έγγραφα. Επιτρέπει στους χρήστες να δημιουργούν ιστοσελίδες που περιέχουν κείμενο, γραφικά, βίντεο καθώς και δείκτες προς άλλες ιστοσελίδες. Το βασικό της πλεονέκτημα είναι ότι διαχωρίζει το περιεχόμενο από τον τρόπο παρουσίασης του. Έτσι είναι εύκολη η συγγραφή ενός φυλλομετρητή (browser) για αυτήν, αφού ο φυλλομετρητής αρκεί να κατανοεί τις εντολές σήμανσης και να τις εφαρμόζει στο περιεχόμενο. Με την ενσωμάτωση όλων των εντολών σήμανσης σε κάθε αρχείο HTML και την τυποποίηση των εντολών αυτών, ο κάθε φυλλομετρητής Ιστού μπορεί να διαβάζει και να μορφοποιεί εκ νέου οποιαδήποτε ιστοσελίδα. Η HTML γράφεται υπό μορφή στοιχείων HTML τα οποία αποτελούνται από ετικέτες (tags), οι οποίες περικλείονται μέσα σε σύμβολα «μεγαλύτερο από» και «μικρότερο από» (για παράδειγμα <html>), μέσα στο περιεχόμενο της ιστοσελίδας. Οι ετικέτες HTML συνήθως λειτουργούν ανά ζεύγη (για παράδειγμα <h1> και </h1>), με την πρώτη να ονομάζεται ετικέτα έναρξης και τη δεύτερη ετικέτα λήξης. Ανάμεσα στις ετικέτες, οι σχεδιαστές ιστοσελίδων μπορούν να τοποθετήσουν κείμενο, πίνακες, εικόνες κλπ. Επιπλέον τα αλφαριθμητικά μέσα στις ετικέτες ονομάζονται οδηγίες (directives) [5]. Στην παρακάτω εικόνα μπορεί κανείς να δει τη βασική μορφή μιας ιστοσελίδας γραμμένης σε γλώσσα HTML και το αποτέλεσμα που έχει αυτή η γλώσσα αφού διαβαστεί από το φυλλομετρητή. Εικόνα 5 Παράδειγμα HTML σελίδας 18 Σ ε λ ί δ α

Θεωρητικό και τεχνολογικό υπόβαθρο 2.2.2.2 Πόροι του Παγκόσμιου Ιστού Οι πόροι ή αλλιώς resources, αποτελούν τα βασικά δομικά συστατικά των διαδικτυακών συστημάτων. Η σημασία του είναι τέτοια ώστε πολλές φορές τα ίδια τα συστήματα αποκαλούνται προσανατολισμένα στους πόρους, (resource-oriented). Πιο συγκεκριμένα, πόρο ονομάζουμε οτιδήποτε μπορεί να εκτεθεί στο διαδίκτυο, από ένα αρχείο κειμένου ή ένα βίντεο, ως μια επιχειρηματική διεργασία ή κίνηση ή μια συσκευή. Από την πλευρά του πελάτη, πόρος είναι οτιδήποτε μπορεί να αλληλεπιδράσει με τον ίδιο κατά τη διαδικασία επίτευξης ενός στόχου [6]. (Rest in practice 4) 2.2.2.3 URIs Τα Ομοιόμορφα αναγνωριστικά Πόρων ή Uniform Resource Identifiers (URIs) δίνουν τη δυνατότητα εντοπισμού και ταυτοποίησης του πόρου ώστε να μπορεί αυτός να χρησιμοποιηθεί. Ένα URI προσδίδει ουσιαστικά μία διεύθυνση σε κάποιον πόρο, ώστε να μπορεί αυτός να διαχωριστεί από οποιονδήποτε άλλο και να είναι διαχειρίσιμος από κάποιο πρωτόκολλο, όπως για παράδειγμα το HTTP. Να σημειώσουμε στο σημείο αυτό πως η σχέση μεταξύ πόρου και URI είναι ένα προς πολλά. Αυτό πιο πρακτικά σημαίνει ότι ένας πόρος μπορεί να προσδιορίζεται από πολλά URIs, ενώ ένα URI περιγράφει μόνο έναν πόρο. Μαζί με το URI υπάρχουν και άλλοι όροι που περιγράφουν ένα πόρο, όπως το URN (Uniform Resource Name), Ομοιόμορφο Όνομα Πόρου, που περιγράφει το όνομα του πόρου χωρίς να περιγράφει που εντοπίζεται αυτός και το URL (Uniform Resource Locator), Ενιαίος Εντοπιστής Πόρων, ο οποίος περιγράφει ουσιαστικά το πού βρίσκεται ο πόρος [7]. 2.2.2.4 HTTP Το HTTP (Hypertext Transfer Protocol), Πρωτόκολλο Μεταφοράς Υπερκειμένου είναι το πρωτόκολλο που καθορίζει τον τρόπο με τον οποίο μπορούν να μεταφερθούν οι πληροφορίες μεταξύ των διακομιστών του ιστού (servers) και των πελατών (clients). Είναι ένα απλό πρωτόκολλο αίτησης-απάντησης που λειτουργεί κανονικά μέσω του TCP 1. Το HTTP βασίζεται στο μοντέλο πελάτη - εξυπηρετητή (server client) και προσδιορίζει τα μηνύματα που μπορούν να στείλουν οι πελάτες στους διακομιστές και ποια μηνύματα μπορούν να λάβουν σαν απάντηση [5]. 1 Το TCP (Transmission Control Protocol - Πρωτόκολλο Ελέγχου Μεταφοράς) έχει σαν στόχο την επιβεβαίωση της αξιόπιστης αποστολής και λήψης δεδομένων, επίσης τη μεταφορά των δεδομένων χωρίς λάθη μεταξύ του στρώματος δικτύου (network layer) 19 Σ ε λ ί δ α

Θεωρητικό και τεχνολογικό υπόβαθρο Πριν μπούμε σε περαιτέρω λεπτομέρειες για το HTTP να σημειώσουμε πως το πρωτόκολλο αυτό δεν είναι μόνο ένα πρωτόκολλο μεταφοράς υπερκειμένου, αλλά ένα πρωτόκολλο μεταφοράς πληροφοριών το οποίο εξελίσσεται συνεχώς και παρέχει στις διεργασίες έναν τρόπο για μετάδοση περιεχομένου πέρα από τα όρια διαφορετικών δικτύων. Οι διεργασίες αυτές δε χρειάζεται να είναι ένας φυλλομετρητής και ένας διακομιστής, αλλά θα μπορούσε για παράδειγμα να είναι ένα πρόγραμμα αναπαραγωγής πολυμέσων που συνομιλεί με έναν διακομιστή για να ζητήσει πληροφορίες για δίσκους. Προκειμένου να επιτυγχάνει χαμηλό χρόνο απόκρισης, το HTTP σχεδιάστηκε ως ένα πρωτόκολλο χωρίς μνήμη (stateless), δηλαδή κάθε συναλλαγή (session) αντιμετωπίζεται ξεχωριστά και δεν διατηρείται καμιά πληροφορία για αυτή μετά το πέρας της. Επομένως μια τυπική υλοποίηση θα δημιουργεί μια νέα σύνδεση ανάμεσα στον πελάτη και τον εξυπηρετητή για κάθε νέα συναλλαγή [4]. Κατά τη βασική λειτουργία του, ο πελάτης (client) δημιουργεί μια σύνδεση (session) με τον εξυπηρετητή (Server) και στη συνέχεια του αποστέλλει μια αίτηση. Η αίτηση περιέχει τη ζητούμενη μέθοδο, ένα ομοιόμορφο αναγνωριστικό πόρου (Universal Resource Identifier -URI) που περιγράφει τον πόρο στον οποίο θα εφαρμοστεί η παραπάνω μέθοδος, την έκδοση του χρησιμοποιούμενου πρωτοκόλλου και ένα μήνυμα, σε μορφή Multipurpose Internet Mail Extensions (MIME), που περιλαμβάνει πληροφορίες σχετικά με τον client. Εικόνα 6 Server - Client communication και του στρώματος εφαρμογής (application layer) και, φτάνοντας στο πρόγραμμα του στρώματος εφαρμογής, τη διατήρηση της σωστής τους σειράς. 20 Σ ε λ ί δ α

Θεωρητικό και τεχνολογικό υπόβαθρο Στον παρακάτω πίνακα φαίνονται οι μέθοδοι, ρήματα HTTP (HTTP Verbs), που ορίζουν την επιθυμητή ενέργεια από τον πελάτη στο διακομιστή και παρατίθεται ο βασικός σκοπός της κάθε μεθόδου [8]. Πίνακας 1 HTTP μέθοδοι Μέθοδος GET POST PUT DELETE HEAD TRACE CONNECT OPTIONS Safe Idempotent non-safe non-idempotent non-safe Idempotent non-safe Idempotent Περιγραφή Αίτηση ανάγνωσης μιας ιστοσελίδας Προσάρτηση σε μια ιστοσελίδα Αποθήκευση μιας ιστοσελίδας Διαγραφή μιας ιστοσελίδας Αίτηση ανάγνωσης της κεφαλίδας μιας ιστοσελίδας Ανάκτηση του τελικού αποδέκτη της αίτησης Σύνδεση μέσω πληρεξούσιου (proxy) Επιλογές ερωτήματος για μια ιστοσελίδα Εικόνα 7 Παράδειγμα αίτησης GET - POST 21 Σ ε λ ί δ α

Θεωρητικό και τεχνολογικό υπόβαθρο Όπως φαίνεται στην παραπάνω εικόνα, ο πελάτης αποστέλλει ένα μήνυμα στον εξυπηρετητή που αποτελείται από το ρήμα που περιγράφει το σκοπό του αιτήματος, το επιθυμητό URI που περιγράφει τον πόρο στον οποίο ζητάει να εφαρμοστεί το αίτημα του και την έκδοση του χρησιμοποιούμενου πρωτοκόλλου. Από την άλλη, ο εξυπηρετητής, αποκρίνεται με ένα μήνυμα σε μορφή MIME που περιλαμβάνει τον κωδικό απόκρισης κατάστασης και το σώμα (body) του μηνύματος. Οι κωδικοί απόκρισης χρησιμοποιούνται από το διακομιστή για να ενημερωθεί ο πελάτης για το αποτέλεσμα του αιτήματος του. Η μορφή τους είναι ένας τριψήφιος ακέραιος στον οποίο το πρώτο ψηφίο του κώδικα κατάστασης ορίζει την κλάση απόκρισης και τα δύο τελευταία ψηφία δεν έχουν κανένα ρόλο κατηγοριοποίησης. Λόγω του γεγονότος ότι υπάρχει μεγάλο πλήθος κωδικών κατάστασης, αυτοί μπορούν να κατηγοριοποιηθούν ως προς το πρώτο τους ψηφίο σύμφωνα με τον παρακάτω πίνακα [9] [10]. Πίνακας 2 Κωδικοί HTTP απόκρισης Κωδικός 1xx 2xx 3xx 4xx 5xx Σημασία Πληροφορίες Επιτυχία Ανακατεύθυνση Σφάλμα πελάτη Σφάλμα διακομιστή 2.3 Web Services Ο παγκόσμιος ιστός, όπως αναφέραμε και παραπάνω, στρέφεται ολοένα στην πιο αυτοματοποιημένη επικοινωνία μεταξύ εφαρμογών. Η επικοινωνία αυτή παρέχεται από εφαρμογές λογισμικού οι οποίες αναφέρονται στη βιβλιογραφία σαν Υπηρεσίες Διαδικτύου ή Web Services. Εύλογα στο σημείο αυτό γεννάται η απορία, τι είναι μια Υπηρεσία Διαδικτύου και ποια λειτουργία επιτελεί. Η απάντηση στα παραπάνω ερωτήματα δεν είναι μονοσήμαντη, αλλά εξαρτάται από το πλαίσιο που θέλουμε να εφαρμοστεί και την εταιρία πληροφορικής που την έχει ορίσει. Σύμφωνα με την W3C [11], «Web Service είναι ένα σύστημα λογισμικού σχεδιασμένο με τέτοιο τρόπο ώστε να υποστηρίζει τη διαλειτουργική αλληλεπίδραση μεταξύ μηχανών, μέσω ενός δικτύου. Παρέχει 22 Σ ε λ ί δ α

Θεωρητικό και τεχνολογικό υπόβαθρο μια διεπαφή η οποία περιγράφεται σε μια μορφή αντιληπτή από μηχανές (συγκεκριμένα στην μορφή WSDL και WADL για REST εφαρμογές). Άλλα συστήματα αλληλεπιδρούν με την διαδικτυακή υπηρεσία με τρόπο που καθορίζεται από την περιγραφή της διεπαφής χρησιμοποιώντας μηνύματα SOAP, τα οποία τυπικά μεταφέρονται χρησιμοποιώντας το πρωτόκολλο HTTP και γραμμένα σε XML, και σε συνδυασμό με άλλα πρότυπα που αφορούν το διαδίκτυο.» Η IBM επίσης δίνει το δικό της ορισμό για τα Web Services [12]: «Τα web services είναι μια τεχνολογία που επιτρέπει στις εφαρμογές να επικοινωνούν μεταξύ τους ανεξαρτήτως πλατφόρμας και γλώσσας προγραμματισμού. Ένα web service είναι μια διεπαφή λογισμικού (software interface) που περιγράφει μια συλλογή από λειτουργίες οι οποίες μπορούν να προσεγγιστούν από το δίκτυο μέσω πρότυπων μηνυμάτων XML. Χρησιμοποιεί πρότυπα βασισμένα στη γλώσσα XML για να περιγράψει μία λειτουργία (operation) προς εκτέλεση και τα δεδομένα προς ανταλλαγή με κάποια άλλη εφαρμογή. Μια ομάδα από web services οι οποίες αλληλεπιδρούν μεταξύ τους καθορίζει μια εφαρμογή web services.» H Microsoft μέσα από το MSDN 2 της καταλήγει ότι όλα τα web services έχουν τρία κοινά χαρακτηριστικά [13]: Τα Web Services εκθέτουν χρήσιμη λειτουργικότητα σε χρήστες του διαδικτύου μέσα από ένα πρότυπο δικτυακό πρωτόκολλο. Στις περισσότερες περιπτώσεις αυτό το πρωτόκολλο είναι το SOAP (Simple Object Access Protocol). Τα Web Services παρέχουν ένα τρόπο περιγραφής των διεπαφών τους με αρκετή λεπτομέρεια ώστε να επιτρέψουν στο χρήστη να κατασκευάσει μια εφαρμογή πελάτη με την οποία μπορούν να επικοινωνούν. Η περιγραφή συνήθως παρέχεται σε ένα έγγραφο XML το οποίο ονομάζεται έγγραφο WSDL (Web Services Description Language). Τα web services καταχωρούνται ώστε οι δυνητικοί χρήστες να μπορούν να τα βρουν εύκολα. Αυτό γίνεται με το UDDI (Universal Discovery Description and Integration). Οι βασικότερες τεχνολογίες στις οποίες βασίζονται τα web services, αλλά και η αρχιτεκτονική SOA παρατίθενται στον παρακάτω πίνακα. 2 Microsoft Developer Network: είναι το τμήμα της Microsoft που είναι υπεύθυνο για τη διαχείριση των σχέσεων της επιχείρησης με τους προγραμματιστές και τους δοκιμαστές 23 Σ ε λ ί δ α

Θεωρητικό και τεχνολογικό υπόβαθρο Πίνακας 3 Τεχνολογίες WebServices Επίπεδο Τεχνολογία Περιγραφή Ομοιόμορφος ορισμός και ανταλλαγή δεδομένων Πρότυπο κανάλι επικοινωνίας Πρότυπη περιγραφική γλώσσα για την περιγραφή των παρεχόμενων υπηρεσιών Καταχώρηση και εντοπισμός των παρεχόμενων υπηρεσιών XML SOAP WSDL UDDI Η Extended Markup Language (XML) είναι μια μεταγλώσσα (περιγραφική γλώσσα) η οποία έχει καλή καθορισμένη σύνταξη και σημασιολογία και μπορεί να υποστηρίξει επικοινωνία μεταξύ διαφορετικών γλωσσών και πλατφορμών Το Simple Object Access Protocol (SOAP) είναι το πρωτόκολλο επικοινωνίας για XML Web Services Γλώσσα περιγραφής των Web Services. Τα μηνύματα που ανταλλάσσονται μεταξύ πελατών και διακομιστών περιγράφονται αφηρημένα και στη συνέχεια συνδέονται με συγκεκριμένο πρωτόκολλο δικτύου και μορφή μηνύματος. Ο «χρυσός οδηγός» των web services είναι το Universal Description Discovery and Integration (UDDI). Οι εφαρμογές που παρέχουν web services παρατίθενται σε ένα κατάλογο από παρόχους υπηρεσιών χρησιμοποιώντας το UDDI. 2.4 Service-Oriented Architecture (SOA) Η Αρχιτεκτονική Ελεγχόμενη από Υπηρεσίες αποτελεί ένα αρχιτεκτονικό πρότυπο που χρησιμοποιεί υπηρεσίες διαθέσιμες στο διαδίκτυο. Τα συστήματα που σχεδιάζονται με αυτή την αρχιτεκτονική επιτυγχάνουν την αυξημένη διαθεσιμότητα, διαλειτουργικότητα, διατηρησιμότητα και αξιοπιστία των εφαρμογών τους. Τα πλεονεκτήματα αυτά οφείλονται στη διάσπαση των εφαρμογών ενός συστήματος σε οντότητες (modules) με σαφώς ορισμένο συμβόλαιο διεπαφών ( interface contract ), που συμβάλλει σε χαλαρές σχέσεις εφαρμογών και υπηρεσιών. Οι χαλαρές αυτές σχέσεις (loose coupling) ανάμεσα στον πελάτη και τον εξυπηρετητή ευνοούν τον πελάτη, καθώς οι εφαρμογές πελάτη προστατεύονται από αλλαγές στις υλοποιήσεις εξυπηρετητή, ενώ ταυτόχρονα δίνεται η δυνατότητα στον πελάτη να μπορεί να επιλέξει ανάμεσα σε διάφορους παρόχους υπηρεσιών. Ακόμη, ευνοείται ο πάροχος, καθώς με την αρχιτεκτονική αυτή προκύπτουν εφαρμογές που αντιστοιχούν σε επιχειρησιακές διαδικασίες. Η αρχιτεκτονική αυτή ευνοεί την επίτευξη αλλαγών πάνω σε εφαρμογές (modifiability), χωρίς να επηρεάζεται το συνολικό πληροφοριακό σύστημα. Στην ακόλουθη εικόνα παρουσιάζεται η βασική φιλοσοφία της αρχιτεκτονικής SOA [14]. 24 Σ ε λ ί δ α

Θεωρητικό και τεχνολογικό υπόβαθρο Εικόνα 8 Αρχιτεκτονική προσανατολισμένη στον πόρο - ROA Επομένως, τα βασικά πλεονεκτήματα των SOA συνοψίζονται στα παρακάτω σημεία [15]: Τμηματοποίηση (modularization) σύνθετων συστημάτων Χαλαρή ζεύξη (loose coupling) Βελτίωση της ευελιξίας (flexibility) και της επεκτασιμότητας (scalability) Αύξηση αποδοτικότητας λόγω επαναχρησιμοποίησης (increase efficiency through reuse) Μείωση κόστους ανάπτυξης (cost reduction) Διαλειτουργικότητα (interoperability) Ανεξαρτησία από την τοποθεσία (location Independence) κατανεμημένα συστήματα (distributed) Σταδιακή προσέγγιση (incremental approach) Εκτός όμως από τα πλεονεκτήματα, η παραπάνω αρχιτεκτονική παρουσίασε και πολλά προβλήματα όσο αυξανόταν η πολυπλοκότητα των συστημάτων προς υλοποίηση και δέχτηκε και αρνητικές κριτικές από την επιστημονική κοινότητα. Μερικά από τα μειονεκτήματα της εν λόγω αρχιτεκτονικής παρατίθενται στα ακόλουθα σημεία: To HTTP πρωτόκολλο δεν χρησιμοποιείται όπως προοριζόταν κατά την σύλληψη του Αύξηση πολυπλοκότητας λόγω απαίτησης για τη μετατροπή από και προς XML - SOAP αρχεία για τα ερωτήματα και τις απαντήσεις Ο κώδικας που απαιτείται για την δημιουργία τους όσο αυξάνεται η πολυπλοκότητα καταλήγει να δυσχεραίνει το έργο των προγραμματιστών, τόσο στην συγγραφή των 25 Σ ε λ ί δ α

Θεωρητικό και τεχνολογικό υπόβαθρο εφαρμογών στην πλευρά του διακομιστή (server), όσο και στις εφαρμογές που καλούν την υπηρεσία (clients) Το γεγονός πως μία υπηρεσία είναι διαθέσιμη σε έναν και μόνο σύνδεσμο, καθιστά δύσκολη την πλοήγηση μεταξύ των διαφόρων μεθόδων που διαθέτει 2.5 Web APIs Αν και δεν υπάρχει ακριβής ορισμός για τις διαδικτυακές διεπαφές προγραμματισμού εφαρμογών (Web APIs), θα μπορούσαν να θεωρηθούν ως ένα σύστημα λογισμικού αποτελούμενο από ένα ή περισσότερα διαδικτυακά σημεία πρόσβασης δεδομένων ή διεργασιών, που λειτουργεί με ένα ορισμένο σύστημα ανταλλαγής μηνυμάτων αιτήματος-απόκρισης [16]. Για να αποσαφηνιστεί καλύτερα η έννοια του Web API μπορούμε να εξετάσουμε το παρακάτω παράδειγμα. Σε ένα αυτοκίνητο, ο κατασκευαστής παρέχει στον οδηγό τιμόνι, κιβώτιο ταχυτήτων, πεντάλ, κουμπιά, καντράν. Μέσω του τιμονιού ο οδηγός στέλνει οδηγίες στους τροχούς, ενώ το καντράν λαμβάνει σήματα από την μηχανή. Αντίστοιχα τα διάφορα κουμπιά στέλνουν εντολές στο ηλεκτρονικό σύστημα του αυτοκινήτου. Σίγουρα κάποιος δεν μπορεί να χρησιμοποιήσει όλα αυτά τα χαρακτηριστικά αν δεν έχει δίπλωμα οδήγησης. Δεν χρειάζεται όμως να είναι μηχανικός αυτοκινήτων για να οδηγήσει το αυτοκίνητο. Αυτό διότι ο κατασκευαστής έχει φροντίσει να παρέχει στον οδηγό μία αφαιρετική αναπαράσταση των εσωτερικών συστημάτων του αυτοκινήτου. Η αναπαράσταση είναι το τιμόνι, τα πεντάλ, το κιβώτιο ταχυτήτων, το καντράν, τα κουμπιά, τα χερούλια. Έτσι ο οδηγός αρκεί μόνο να γνωρίζει, πώς να χειρίζεται (μέσω διπλώματος και manuals) αυτή την αναπαράσταση. Αυτή η αφαιρετική αναπαράσταση στον προγραμματισμό είναι το Application Programming Interface. Τα APIs αφορούν υπολογιστικά συστήματα. Δεδομένου ενός συστήματος, το API αποτελεί μία εργαλειοθήκη του. Η εργαλειοθήκη αυτή έχει δυνατότητα να χρησιμοποιεί κάποιες από τις λειτουργίες του συστήματος. Μάλιστα έχει σχεδιαστεί με τέτοιο τρόπο, ώστε να είναι εύχρηστη και εξυπηρετεί ένα συγκεκριμένο πεδίο εφαρμογής του συστήματος. Ένας προγραμματιστής μπορεί να αναπτύξει εφαρμογές λογισμικού αξιοποιώντας το API. Όπως ο οδηγός αυτοκινήτου δεν χρειάζεται να ξέρει να τις τεχνικές λεπτομέρειες του αυτοκινήτου, έτσι και ο προγραμματιστής δεν χρειάζεται να ξέρει τις τεχνικές λεπτομέρειες του συστήματος. Αν δεν υπήρχε το API, τότε θα έπρεπε ο προγραμματιστής να το αναπτύξει μόνος του, αφού πρώτα μελετούσε προσεκτικά το σύστημα. 26 Σ ε λ ί δ α

Θεωρητικό και τεχνολογικό υπόβαθρο Παρόλο που τα Web APIs πολλές φορές συγχέονται με τα web services, οι μοντέρνες διαδικτυακές εφαρμογές έχουν αποστραφεί από τα SOAP web services λόγω των προαναφερθέντων μειονεκτημάτων τους. Έτσι τα web APIs διακρίνονται από τα web services καθώς έχουν στραφεί πλέον στην αποκαλούμενη RESTful αρχιτεκτονική. 2.6 REST και ROA Η λογική REST που βρίσκεται πίσω από τη λογική του διαδικτύου, μπορεί να περιγραφεί σαν ένα αρχιτεκτονικό στυλ που ανήκει στο πεδίο της κατανεμημένης υπολογιστικής (distributed computing) και βασίζεται πάνω σε ένα σετ περιορισμών (set of constraints). Περιγράφηκε για πρώτη φορά από τον Roy T. Fielding το 2000 κατά την εκπόνηση της διδακτορικής του διατριβής. Ο Fielding προσπάθησε να γενικεύσει τις αρχιτεκτονικές αρχές του διαδικτύου παραθέτοντας μια σειρά περιορισμών που περιγράφουν το διαδίκτυο. Μέσα από αυτό το πλαίσιο ο Fielding περιέγραψε τη δομή και λειτουργία των κατανεμημένων πληροφοριακών συστημάτων, πώς αλληλεπιδρούν μεταξύ τους οι πόροι και τον ρόλο των διακριτών αναγνωριστικών σε τέτοια συστήματα. Επίσης, τόνισε τη σημασία της χρήσης περιορισμένων συνόλων λειτουργιών με ενιαία σημασιολογία για την κατασκευή μιας καθολικής υποδομής, που θα μπορεί να υποστηρίξει οποιαδήποτε εφαρμογή. Ο Fielding αναφερόταν σε αυτό το αρχιτεκτονικό στυλ ως μεταφορά αναπαράστασης κατάστασης (Representational State Transfer) [17]. Συνοπτικά, το REST αρχιτεκτονικό στυλ είναι ένα σύνολο από περιορισμούς, που όταν εφαρμόζεται στη σχεδίαση κατανεμημένων συστημάτων δίνει επιθυμητά χαρακτηριστικά, όπως μεταξύ άλλων, προσαρμοστικότητα στην κλιμάκωση (scalability), ομοιομορφία (uniformity), απλότητα (simplicity), επίδοση (performance), παρατηρησιμότητα (visibility) και ενθυλάκωση (encapsulation) παλαιών συστημάτων (legacy systems) [6]. Οι βασικές αρχές του REST που αναλύονται παρακάτω, συνοψίζονται στα ακόλουθα [18]: Οτιδήποτε μπορεί να είναι πόρος Κάθε πόρος είναι αναγνωρίσιμος από ένα μοναδικό URI Χρήση βασικών HTTP μεθόδων 27 Σ ε λ ί δ α

Θεωρητικό και τεχνολογικό υπόβαθρο Οι πόροι μπορούν να έχουν διάφορες αναπαραστάσεις Επικοινωνία «χωρίς μνήμη» ή με «έλλειψη κατάστασης» 2.6.1 ΑΡΧΗ 1 Οτιδήποτε είναι πόρος και ταυτοποιέιται με ένα μοναδικό αναγνωριστικό (Addressability) Ο πόρος αποτελεί το βασικό δομικό συστατικό του αρχιτεκτονικού στυλ REST. Είναι ουσιαστικά μια αφαίρεση (abstraction) στην αναπαράσταση της πληροφορίας. Κάθε πόρος είναι προσπελάσιμος μέσω ενός URI (addressable via a URI) κάτι που διευκολύνει την αναφορά σε αυτόν [19]. Μιας και το διαδίκτυο περιέχει τόσο πολλούς και διαφορετικούς πόρους, αυτοί πρέπει να είναι προσβάσιμοι μέσω ενός μοναδικού αναγνωριστικού, του URI. Αυτό επιτυγχάνεται με χρήση των URIs (Uniform Resource Identifiers) τα οποία συνδέουν τους πληροφοριακούς πόρους μιας διαδικτυακής εφαρμογής με ένα URI της μορφής: scheme://host:port/path?querystring#fragment Πίνακας 4 Περιγραφή URI scheme://host:port/path?querystring#fragment scheme host port path querystring fragment πρωτόκολλο που χρησιμοποιείται για την επικοινωνία, συνήθως είναι http ή https όνομα DNS ή μια IP διεύθυνση θύρα μέσω της οποίας πραγματοποιείται η επικοινωνία η διαδρομή από τον κεντρικό φάκελο έως την τοποθεσία που βρίσκεται η ζητούμενη πληροφορία παράμετρος ακολουθεί τον χαρακτήρα # και χρησιμοποιείται για να καθορίσει το ακριβές σημείο του εγγράφου αναφοράς του ερωτήματος 28 Σ ε λ ί δ α

Θεωρητικό και τεχνολογικό υπόβαθρο 2.6.2 ΑΡΧΗ 2 Η Ενιαία διεπαφή (The Uniform, Constrained Interface) Βασίζεται στην ιδέα χρήσης των επιτρεπόμενων, καλά ορισμένων HTTP μεθόδων (GET, POST, PUT, DELETE, HEAD, OPTIONS). Η σχεδιαστική αυτή αρχή είναι πολύ χρήσιμη καθώς παρουσιάζει το πλεονέκτημα ευκολίας στη χρήση ενός μικρού αριθμού μεθόδων για την επικοινωνία με πόρους και υπηρεσίες [6]. Οι μέθοδοι αυτοί έχουν περιγραφεί αναλυτικότερα στο κεφάλαιο για το HTTP πρωτόκολλο παραπάνω. 2.6.3 ΑΡΧΗ 3 Οι πόροι μπορούν να έχουν πολλαπλές αναπαραστάσεις Μια σημαντική ιδιότητα του πόρου είναι ότι μπορεί να αναπαρασταθεί με διαφορετική μορφή από αυτή στην οποία είναι αποθηκευμένος. Για το λόγο αυτό, ο πελάτης μπορεί να τον αιτηθεί και να τον τροποποιήσει χρησιμοποιώντας διαφορετικές αναπαραστάσεις, αρκεί αυτές να υποστηρίζονται από το REST. Να σημειώσουμε εδώ πως η πρόσβαση σε κάθε URI δεν θα αποδώσει ποτέ τον ίδιο τον πόρο, παρά μόνο μια αναπαράσταση του, η οποία αντανακλά στην τρέχουσα κατάστασή του. Με αυτή την έννοια οι αναπαραστάσεις των πόρων είναι απλά στιγμιότυπα στο χρόνο. Επιπρόσθετα, οι πόροι μπορούν να έχουν διάφορες αναπαραστάσεις, μεταξύ των οποίων οι πιο διαδεδομένες στο διαδίκτυο είναι η XML και JSON, χωρίς αυτό να σημαίνει πως η κωδικοποίηση των αναπαραστάσεων περιορίζεται μόνο σε αυτές τις δύο [20]. Εικόνα 9 Διαφορετικές αναπαραστάσεις ενός πόρου 29 Σ ε λ ί δ α

Θεωρητικό και τεχνολογικό υπόβαθρο 2.6.4 ΑΡΧΗ 4 Επικοινωνία χωρίς μνήμη (Communicate Statelessly) Η Πέμπτη σχεδιαστική αρχή υπαγορεύει την απαίτηση να μην αποθηκεύεται κανένα πλαίσιο του πελάτη στον διακομιστή ανάμεσα στα αιτήματα. Με άλλα λόγια, κάθε επικοινωνία μεταξύ ενός πελάτη με έναν εξυπηρετητή απαιτεί απομόνωση. Όταν ο πελάτης κάνει μία HTTP κλήση εσωκλείει και όλες τις απαραίτητες πληροφορίες ώστε ο διακομιστής να ικανοποιήσει το αίτημά του. Με αυτόν τον τρόπο ο εξυπηρετητής δεν στηρίζεται ποτέ σε πληροφορίες από προηγούμενες κλήσεις, αλλά διαθέτει μόνο την πληροφορία της κατάστασης για του πόρους που διαθέτει [19]. Η επικοινωνία χωρίς μνήμη απομονώνει τον πελάτη από την εξυπηρετητή, προστατεύοντας τον ταυτόχρονα από πιθανές αλλαγές από την πλευρά του διακομιστή. Ο πελάτης δεν προβλέπεται να επικοινωνεί με τον διακομιστή μέσα από συνεχόμενες κλήσεις. Αυτό επιτρέπει την εύκολη εφαρμογή αλλαγών εντός της υποδομής του εξυπηρετητή, όπως η πρόσθεση ή αφαίρεση κόμβων, χωρίς το παραμικρό αντίκτυπο στον πελάτη [18]. 2.6.5 ΑΡΧΗ 5 HATEOAS (Hypermedia As The Engine Of Application State) H τελευταία σχεδιαστική αρχή υπαγορεύει ότι ο πελάτης είναι υπεύθυνος για τη διατήρηση της κατάστασης της εφαρμογής και για τη διέλευση μεταξύ των πιθανών καταστάσεων και ονομάζεται από τον Roy Fielding στην εφαρμογή του «HATEOAS (Hypertext As The Engine Of Application State)». Η αρχή αυτή δίνει μια νέα προοπτική στη χρήση του διαδικτύου πέρα από την κλασική αποθήκευση και ανάκτηση δεδομένων [6]. Η βασική ιδέα είναι πολύ ισχυρή, αν και απλή. Μια διανεμημένη εφαρμογή μπορεί να προχωράει κινούμενη από μία κατάσταση σε μία άλλη, ακριβώς σαν μία μηχανή καταστάσεων. Η βασική διαφορά με την μηχανή καταστάσεων έγκειται στο γεγονός πως ότι οι πιθανές καταστάσεις στις οποίες μπορεί να μεταβεί η εφαρμογή δεν είναι γνωστές εκ των προτέρων. Αντ αυτού, η εφαρμογή ανακαλύπτει τις νέες πιθανές καταστάσεις στις οποίες μπορεί να μεταβεί κάθε φορά που φτάνει σε μία κατάσταση. Σε ένα σύστημα υπερσυνδέσμων, οι πιθανές καταστάσεις στις οποίες μπορεί να μεταβεί η εφαρμογή επικοινωνούνται μέσω αναπαραστάσεων των μοναδικών αναγνωριστικών των πόρων (URIs). Τα αναγνωριστικά αυτά ενσωματώνονται μέσα στην αναπαράσταση της τρέχουσας κατάστασης στην οποία βρίσκεται ο πόρος σαν υπερσύνδεσμοι (links). 30 Σ ε λ ί δ α

Θεωρητικό και τεχνολογικό υπόβαθρο Εικόνα 10 HATEOAS 2.7 Richardson Maturity Model Αφού μελετήσαμε τις σχεδιαστικές αρχές του REST προκύπτει εύλογα το ερώτημα για το πότε ένα Web API θεωρείται RESTful και το αν χρειάζεται να ικανοποιεί όλες τις σχεδιαστικές απαιτήσεις. Απαντήσεις στα ερωτήματα αυτά επιχείρησε να δώσει ο Leonard Richardson με το μοντέλο ωριμότητας που κατασκεύασε (Richardson Maturity Model RMM) [6]. Το μοντέλο αυτό, χωρίζει τις εφαρμογές σε κατηγορίες ανάλογα με το αν αυτές μπορούν να υποστηρίξουν URIs, HTTP μεθόδους, υπερσυνδέσμους ή και τίποτα από τα παραπάνω. Σύμφωνα λοιπόν με τον Richardson, μια εφαρμογή είναι εντελώς RESTful αν συμφωνεί με τους ακόλουθους περιορισμούς [21]: Οι πόροι που αποτελούν το service θα πρέπει να αναγνωρίζονται από μοναδικά URIs. Αυτό σημαίνει ότι κάθε διακριτός πόρος θα έχει διαφορετικά URIs Κάθε URI θα είναι προσβάσιμο από τις βασικές HTTP μεθόδους οι οποίες μάλιστα πρέπει να εκτελούνται με τον ορθό καθορισμένο τρόπο 31 Σ ε λ ί δ α

Θεωρητικό και τεχνολογικό υπόβαθρο Οι πόροι του service θα πρέπει να είναι διασυνδεδεμένοι με hypermedia links (συνδέσμους υπερμέσων), οι οποίοι θα παρέχουν στον καταναλωτή (consumer) του service τις επόμενες δυνατές κινήσεις μετά την αλληλεπίδραση με τον συγκεκριμένο πόρο. Αυτό σημαίνει ότι μετά από κάθε αίτημα σε ένα RESTful service, εκτός από την απαιτούμενη απόκριση ο καταναλωτής θα λαμβάνει και μια λίστα με συνδέσμους που θα τους υποδεικνύουν τις παραπέρα επιλογές του, χωρίς να χρειάζεται να έχει γνώση αυτών εκ των προτέρων. Εικόνα 11 Επίπεδα ωριμότητας Richardson - RMM 2.8 Swagger Το Swagger θεωρείται ένα από τα πιο δημοφιλή πλαίσια για την υλοποίηση εφαρμογών σήμερα. Είναι ένα σύνολο κανονισμών και ένα ολοκληρωμένο πλαίσιο εφαρμογής για την περιγραφή, παραγωγή, κατανάλωση και απεικόνιση των RESTful διαδικτυακών υπηρεσιών. Αναπτύχθηκε από την Wordnik με σκοπό την ιδιωτική του χρήση για τη δημιουργία του developer.wordnik.com. Η υλοποίηση του Swagger ξεκίνησε στις αρχές του 2010 και το πλαίσιο το οποίο κυκλοφόρησε αρχικά είναι αυτό που χρησιμοποιείται μέχρι σήμερα από τα APIs της Wordnik και προσέλκυσε εσωτερικούς και εξωτερικούς API clients. Το 2015 η SmartBear αγόρασε το open source Swagger API specification από τη Reverb Technologies (γνωστή παλαιότερα σαν Wordnik) [22] και τον ίδιο χρόνο ανακοίνωσε τη δημιουργία της πρωτοβουλίας OpenAPI [23], ενός οργανισμού υπό τη χορηγία του Ιδρύματος Linux με ιδρυτικά μέλη 32 Σ ε λ ί δ α

Θεωρητικό και τεχνολογικό υπόβαθρο εταιρίες όπως οι Google, IBM, Intuit, Microsoft και PayPal [24]. Τέλος, το 2016 οι προδιαγραφές Swagger μετονομάστηκαν σε προδιαγραφές OpenAPI, παρόλα αυτά η SmartBear συνέχισε την ανάπτυξη εργαλείων υποστήριξης των OpenAPI προδιαγραφών κάτω από την επωνυμία Swagger. Ο πρωταρχικός στόχος του Swagger είναι να δώσει την δυνατότητα στους πελάτες και στο σύστημα τεκμηρίωσης να ανανεώνεται με τον ίδιο ρυθμό με αυτόν του εξυπηρετητή. Η τεκμηρίωση των μεθόδων, των παραμέτρων και των μοντέλων είναι ενσωματωμένη στον κώδικα του server, επιτρέποντας στα APIs να είναι πάντα ενημερωμένα και συγχρονισμένα. Επιπλέον ορίζει ένα πρότυπο διεπαφής ανεξάρτητο από την γλώσσα προγραμματισμού για τα REST APIs (language agnostic) και μπορεί να υποστηρίξει νέες τεχνολογίες και πρωτόκολλα πέρα από το HTTP. Αυτό επιτρέπει στους ανθρώπους και τους υπολογιστές να ανακαλύψουν και να κατανοήσουν τις δυνατότητες της υπηρεσίας χωρίς να έχουν πρόσβαση στον πηγαίο κώδικα του server, την τεκμηρίωση κώδικα και χωρίς να αναλύουν τι γίνεται στο δίκτυο. Η χρήση διεπαφών API σε γλώσσα αναγνωρίσιμη από μηχανή, περιλαμβάνει την διαδραστική τεκμηρίωση, την δημιουργία κώδικα για τεκμηρίωση, πελάτες, εξυπηρετητές, όπως και αυτοματοποιημένες δοκιμαστικές εφαρμογές. Τα APIs που βασίζονται σε Swagger δίνουν αρχεία JSON που ακολουθούν πιστά τους ορισμούς του Swagger, όπως θα αναλυθούν στη συνέχεια. Αυτά τα αρχεία μπορούν είτε να δημιουργηθούν και να δίνονται στατικά, είτε να παράγονται δυναμικά από κάθε εφαρμογή. Το Swagger δεν απαιτεί το να ξαναγράψει κανείς το ήδη υπάρχον API του, ούτε απαιτεί να συνδεθεί κάποιο πρόγραμμα στην υπηρεσία του. Απαιτεί, όμως, οι δυνατότητες της υπηρεσίας να μπορούν να περιγραφούν σύμφωνα με την δομή των κανονισμών Swagger ( OpenAPI Specification ). Όπως είναι φυσικό και αναμενόμενο, δεν μπορούν όλες οι υπηρεσίες να περιγραφούν σύμφωνα με αυτό το πρότυπο. Άλλωστε αυτοί οι κανονισμοί δεν έχουν σκοπό να καλύψουν όλες τις πιθανές εφαρμογές ενός RESTful API. Επίσης δεν ορίζει μια συγκεκριμένη διαδικασία ανάπτυξης εφαρμογών, όπως για παράδειγμα να γίνεται πρώτα ο σχεδιασμός ή πρώτα ο κώδικας. Διευκολύνει, όμως και τις δύο τεχνικές καθιερώνοντας συγκεκριμένες διαδικασίες για ένα REST API. Τέλος, το πρότυπο βρίσκεται αυτή τη στιγμή στην έκδοση 2.0, ενώ αναμένεται η έκδοση 3.0 μέσα στο 2017. Να σημειωθεί εδώ, πως το Swagger δεν είναι το πρώτο εργαλείο που προσπάθησε να αναπτύξει ένα πρότυπο περιγραφής των Web APIs. Χωρίς να αναλύσουμε την ιστορία των διεπαφών των διαδικτυακών υπηρεσιών, ενδεικτικά μπορούμε να πάρουμε πληροφορίες από το CORBA, το WSDL και το WADL. 33 Σ ε λ ί δ α

Θεωρητικό και τεχνολογικό υπόβαθρο Οι προσπάθειες αυτές αν και πολλά υποσχόμενες δεν κατάφεραν να επιτύχουν το σκοπό τους, διότι περιορίστηκαν σε πολύ συγκεκριμένες εφαρμογές. Η σύνδεση τους με μία συγκεκριμένη γλώσσα προγραμματισμού τις απέτρεψε από το να αποκτήσουν μεγάλο κοινό και να τραβήξουν την προσοχή των προγραμματιστών [25] [26]. Το swagger αποτελείται από τρία μέλη [27]: Server: Φιλοξενεί την περιγραφή των Web Apis που ο προγραμματιστής θέλει να χρησιμοποιήσει Client: χρησιμοποιεί την περιγραφή των Web APIs που παρέχεται από το server UI: διαβάζει την περιγραφή των APIs από το server και σχηματίζει την αντίστοιχη ιστοσελίδα, στην οποία ο χρήστης μπορεί να δοκιμάσει και να ελέγξει τις λειτουργίες του API. Εικόνα 12 Λογότυπο Swagger Για τον σχηματισμό, τον έλεγχο και την οπτικοποίηση των OpenAPI Specifications μπορούν να χρησιμοποιηθούν τα ακόλουθα εργαλεία ανοικτού κώδικα: Swagger Editor Με το εργαλείο αυτό μπορεί κανείς να σχεδιάσει, περιγράψει και τελικά να τεκμηριώσει το API του. Είναι ένα εργαλείο σύνταξης, όπου ο χρήστης μπορεί να αποτυπώσει το API του σε μορφή YAML ή JSON και να διορθώσει πιθανά λάθη στη σύνταξη. Παράλληλα υποστηρίζεται η παραγωγή της δομής του server χωρίς τη λειτουργικότητα και βιβλιοθηκών του client σε μια σειρά από γλώσσες και τεχνολογίες. Τέλος μέσω της παραγωγής γραφικού περιβάλλοντος σε πραγματικό χρόνο μπορεί κανείς να δοκιμάσει άμεσα τη λειτουργικότητα του API του [28]. Swagger Codegen Το εργαλείο αυτό, καταναλώνοντας ένα αρχείο σε μορφή YAML ή JSON γραμμένο με τους κανόνες που προβλέπει το OpenAPI πρότυπο, παράγει το σκελετό (συναρτήσεις και μορφή) του 34 Σ ε λ ί δ α

Θεωρητικό και τεχνολογικό υπόβαθρο server, χωρίς τη λειτουργικότητα σε 20 διαφορετικές γλώσσες προγραμματισμού. Επιπλέον υποστηρίζει την παραγωγή βιβλιοθηκών ανάπτυξης λογισμικού στο επίπεδο client σε 40 διαφορετικές γλώσσες προγραμματισμού μέχρι τώρα [29]. Swagger UI Με το Swagger UI παρέχεται στον τελικό χρήστη ή την ομάδα ανάπτυξης ένα διαδραστικό γραφικό περιβάλλον το οποίο αλληλεπιδρά με τους πόρους του API χωρίς να έχει πρόσβαση στη λογική υλοποίησης του ίδιου του API. Το γραφικό αυτό περιβάλλον δημιουργείται δυναμικά χρησιμοποιώντας OpenAPI Specification, παρέχοντας έτσι έναν εύκολο τρόπο υλοποίησης του back end και ταυτόχρονα κατανάλωσης client side [30]. SwaggerHub Το SwaggerHub αποτελεί μια πλατφόρμα ανάπτυξης API βασισμένη στο cloud. Ενώ δεν αποτελεί εργαλείο ανοικτού κώδικα, συνδυάζει σε μία ολοκληρωμένη πλατφόρμα όλα τα παραπάνω εργαλεία δίνοντας τη δυνατότητα σε ομάδες ανάπτυξης να μπορούν ευκολότερα να κατασκευάζουν και να τεκμηριώνουν τα API τους [31]. 2.9 OpenApi Specification Όπως αναφέρθηκε και παραπάνω, για να γραφούν τα λογισμικά του πελάτη και του εξυπηρετητή ενός RESTful Web API χρειάζεται ταυτόχρονα η σύνταξη ενός αρχείου τεκμηρίωσης κώδικα, το λεγόμενο documentation. Το API documentation περιγράφει την λειτουργία του API με κατανοητό προς τον άνθρωπο τρόπο. Δηλαδή περιγράφονται η δομή και οι πόροι του API, οι πιθανές παράμετροι ενός http αιτήματος, η αναμενόμενη απάντηση, ο σκοπός της αλληλεπίδρασης και άλλες τεχνικές λεπτομέρειες που εξαρτώνται από το εκάστοτε API. Οι τεχνικές αυτές πληροφορίες είναι απαραίτητες για την αξιοποίηση του API στον κώδικα του πελάτη. Καταλαβαίνουμε σαφώς πως κάθε πιθανή αλλαγή στο API πρέπει να ακολουθείται από την αντίστοιχη αλλαγή του αρχείου τεκμηρίωσης, κάτι ιδιαίτερα απαιτητικό σε κόστος και χρόνο, μιας και η διαδικασία που πρέπει να ακολουθήσουν οι μηχανικοί είναι να διαβάσουν εκ νέου το καινούριο documentation, να εντοπίσουν τις πιθανές αλλαγές και έπειτα να προχωρήσουν στις απαραίτητες αλλαγές. Η ραγδαία εξέλιξη των APIs τα τελευταία χρόνια έχει οδηγήσει αναπόφευκτα στην τακτική ενημέρωση του 35 Σ ε λ ί δ α

Θεωρητικό και τεχνολογικό υπόβαθρο documentation, κάτι που αν δεν συμβαίνει, καθιστά τις εφαρμογές μη ανταγωνιστικές ή ακόμη και μη λειτουργικές. Οι κίνδυνοι που έχουν προκύψει από την ανάγκη για συνεχή ενημέρωση του λογισμικού οδήγησαν στην απλοποίηση και μοντελοποίηση της διαδικασίας ανάπτυξης API. Συγκεκριμένα παρατηρήθηκε πως: Υπάρχουν τεχνικά χαρακτηριστικά που μοιράζονται από όλα τα RESTful Web APIs λόγω των βασικών αρχών του Παγκόσμιου Ιστού και του και του πρωτοκόλλου HTTP που χρησιμοποιούν. Η ανάπτυξη, εξέλιξη και συντήρηση των APIs εμπλέκει διάφορες τεχνικές ομάδες, η επικοινωνία των οποίων είναι εξαιρετικά περίπλοκη διαδικασία η οποία επηρεάζει το κόστος και την ποιότητα των παρεχόμενων υπηρεσιών. Οι παραπάνω παρατηρήσεις οδήγησαν στην εμφάνιση τυποποιήσεων των RESTful Web APIs, δηλαδή εγγράφου ή εγγράφων που περιγράφουν πλήρως και με απλό τρόπο τη λειτουργία και τα τεχνικά χαρακτηριστικά του. Η πιο δημοφιλής τυποποίηση σήμερα είναι το OpenAPI Specification. Εικόνα 13 Λογότυπο OpenAPI Initiative 2.9.1 Τεχνικά χαρακτηριστικά OpenAPI Specification Στην υποενότητα αυτή θα περιγραφούν συνοπτικά τα τεχνικά χαρακτηριστικά του OpenAPI Specification. Επισημαίνουμε ότι την στιγμή συγγραφής της διπλωματικής βρισκόμαστε στην έκδοση 2.0, ενώ μέσα στο 2017 αναμένεται η έκδοση 3.0 [26] [25]. Μορφή Τα αρχεία που περιγράφουν τα RESTful APIs και είναι σε συμφωνία με την τεκμηρίωση του Swagger και αντιπροσωπεύονται ως αντικείμενα JSON και τηρούν τα πρότυπα του JSON. Επίσης τα YAML αρχεία 36 Σ ε λ ί δ α

Θεωρητικό και τεχνολογικό υπόβαθρο μπορούν επίσης να χρησιμοποιηθούν, καθώς το YAML αποτελεί ένα υπερσύνολο του JSON. Εδώ πρέπει να σημειωθεί πως αν το API περιγράφεται χρησιμοποιώντας JSON, αυτό δε σημαίνει πως η έξοδος του δεν μπορεί να είναι σε XML,YAML απλό κείμενο ή οποιοδήποτε άλλη μορφή επιλέξει κανείς να χρησιμοποιήσει στο API του. Δομή αρχείου Η αναπαράσταση OpenAPI Specification αποτελείται από ένα και μοναδικό αρχείο, το οποίο ονομάζεται swagger.json. Παρόλα αυτά, κομμάτια που αναφέρονται στους ορισμούς (definitions) μπορούν να διαχωριστούν σε διαφορετικά αρχεία αρκεί να αναφέρονται στο αρχικό αρχείο με τη χρήση του $ref. Τύποι δεδομένων Στην παρακάτω εικόνα βλέπουμε αναλυτικά ποιοι είναι οι επιτρεπόμενοι τύποι δεδομένων. Εικόνα 14 Επιτρεπόμενοι τύποι δεδομένων στο OpenAPI πρότυπο 2.9.1.1 Schema Το Schema αποτελεί το βασικότερο κομμάτι της τυποποίησης. Εκεί ορίζονται τα βασικά αντικείμενα (Objects). 37 Σ ε λ ί δ α

Θεωρητικό και τεχνολογικό υπόβαθρο Πίνακας 5 Βασικά αντικείμενα στο πρότυπο OpenAPI Objects Swagger Info Object Contact Object License Object Paths Object Path Item Object Operation Object External Documentation Object Parameter Object Items Object Responses Object Response Object Headers Object Example Object Header Object Tag Object Reference Object Schema Object XML Object Definitions Object Parameters Definitions Object Περιγραφή Βασικό object Παρέχει metadata για το API για να τα χρησιμοποιήσει ο πελάτης ή το swagger UI Πληροφορίες επικοινωνίας για το δεδομένο API Πληροφορίες άδειας για το δεδομένο API Περιέχει τα σχετικά path των τελικών σημείων. Κάθε σχετικό path προστίθεται στο basepath για την κατασκευή του URL. Περιγράφει τις διαθέσιμες λειτουργίες ενός path Περιγράφει μία διαθέσιμη λειτουργία ενός path Επιτρέπει την αναφορά σε εξωτερικό πόρο Περιγράφει την παράμετρο μιας λειτουργίας Χρησιμοποιείται από τους ορισμούς παραμέτρων που δε βρίσκονται στο body Περιέχει τις αναμενόμενες απαντήσεις μιας λειτουργίας Περιγράφει μια και μόνο απάντηση μιας λειτουργίας Περιλαμβάνει μια λίστα από headers που μπορούν να σταλούν σαν κομμάτι μιας απάντησης Επιτρέπει το διαμοιρασμό παραδειγμάτων για απαντήσεις μιας λειτουργίας Περιέχει ένα και μόνο header Επιτρέπει την εισαγωγή metadata σε ένα tag που χρησιμοποιείται από το Operation Object Απλό Object που επιτρέπει την αναφορά σε άλλους ορισμούς στο αρχείο (παράμετροι, απαντήσεις) Επιτρέπει τον ορισμό τύπων δεδομένων εισόδου και εξόδου Ένα object metadata που επιτρέπει ορισμούς XML μοντέλων Περιέχει τύπους δεδομένων που μπορούν να παραχθούν και να καταναλωθούν από τις λειτουργίες Object που περιέχει τις παραμέτρους, ώστε να επαναχρησιμοποιούνται από τις διάφορες λειτουργίες 38 Σ ε λ ί δ α

Θεωρητικό και τεχνολογικό υπόβαθρο Responses Definitions Object Security Definitions Object Security Scheme Object Scopes Object Security Requirement Object Object που περιέχει τις απαντήσεις, ώστε να επαναχρησιμοποιούνται από τις διάφορες λειτουργίες Ορισμός των σχημάτων ασφαλείας που διατίθενται προς χρήση Ορισμός του σχήματος ασφαλείας που μπορεί να χρησιμοποιηθεί από τις λειτουργίες Λίστα διαθέσιμων scopes για OAuth2 σχήμα ασφάλειας Λίστα με τα απαραίτητα σχήματα ασφαλείας που είναι απαραίτητα για την εκτέλεση μιας λειτουργίας Για εύρεση αναλυτικότερης περιγραφή, περιεχόμενου και ιδιοτήτων κάθε επιμέρους αντικειμένου προτείνεται στον αναγνώστη να ανατρέξει στην ιστοσελίδα του OpenAPI Specification στο Github: https://github.com/oai/openapi-specification/blob/master/versions/2.0.md. Πολλά από τα παραπάνω αντικείμενα σχετίζονται μεταξύ τους ιεραρχικά. Ενδεικτικά μπορούμε να συνοψίσουμε τη βασική δομή ενός OpenAPI Specification στα παρακάτω μέρη: Στην αρχή του αρχείου παρατίθενται όλες οι πληροφορίες που σχετίζονται με το API καθώς και την υπηρεσία που το σχεδιάζει στα Info, Contact και Licence Objects Ακολουθεί το basepath, το host και τα schemes, μέλη του Swagger Object Έπειτα γίνεται καταγραφή όλων των path του API στο Path Object Κάθε Path Object περιέχει τις διαθέσιμες λειτουργίες που μπορούν να εκτελεστούν με τα http ρήματα GET, POST, PUT, DELETE Κάθε operation του ομώνυμου Object περιέχει το http αίτημα, την απάντηση του και την πιθανή ασφάλεια καθώς και τα επιμέρους τεχνικά τους χαρακτηριστικά Σε κάθε http αίτημα και απάντηση περιέχονται επίσης οι παράμετροί τους, η τοποθεσία τους (path, body, header), ο τύπος (π.χ. string) και η μορφή τους. Έπειτα μπορεί να υπάρχει αναφορά στον Parameter Definitions Object όπου ορίζονται κάποιες από τις παραμέτρους ώστε να μπορούν να χρησιμοποιηθούν από διάφορες λειτουργίες χωρίς να χρειάζεται ο επαναλαμβανόμενος ορισμός σε αυτές, παρά μόνο η αναφορά Στο τέλος του βασικού αρχείου ή σε άλλα επιμέρους αρχεία υπάρχει προαιρετικά το αντικείμενο ορισμός ή αλλιώς Definitions Object. Εκεί συγκεντρώνονται και οργανώνονται τα μοντέλα με τις 39 Σ ε λ ί δ α

Θεωρητικό και τεχνολογικό υπόβαθρο μεταβλητές τους. Αυτό το κομμάτι βοηθάει κυρίως στη μείωση του μεγέθους του αρχείου καθώς αποτρέπει τις επαναλήψεις των ορισμών των δομών που έχουν ήδη οριστεί νωρίτερα. Παρακάτω παρατίθεται ενδεικτικά ένα παράδειγμα OpenAPI Specification σε μορφή YAML και JSON, ώστε να γίνουν πιο εύκολα αντιληπτές οι ομοιότητες και οι διαφορές τους καθώς και να σχηματοποιηθούν όσα αναφέραμε στο παρόν κεφάλαιο. Εικόνα 15 Ορισμοί σε αρχείο YAML Εικόνα 16 Αρχικά αντικείμενσα σε αρχείο JSON 40 Σ ε λ ί δ α

Θεωρητικό και τεχνολογικό υπόβαθρο Εικόνα 17 Αντικείμενο Paths όπως αυτό ορίζεται σε YAML αρχείο 2.10 MVC (Model View Controller) 2.10.1 Αρχιτεκτονικό πρότυπο Μοντέλο-Όψη-Ελεγκτής Το αρχιτεκτονικό πρότυπο Μοντέλο-Όψη-Ελεγκτής (Model View Controller MVC) αποτελεί τη βασική αρχή στην οποία στηρίζεται κάθε γραφική διεπαφή χρήστη. Επινοήθηκε τη δεκαετία του 1970 στο XEROX Parc. Η βασική λογική πίσω από αυτό το αρχιτεκτονικό πρότυπο, είναι πως διαιρεί μια εφαρμογή σε τρία συνδεδεμένα υποσυστήματα ώστε να ξεχωρίσει τις εσωτερικές αναπαραστάσεις πληροφοριών από τους τρόπους με τους οποίους οι πληροφορίες παρουσιάζονται και γίνονται δεκτές από το χρήστη. Τα τρία αυτά υποσυστήματα αποτελούν το Μοντέλο (Model), την Όψη (View) και τον ελεγκτή (Controller) [32]. Model Το μοντέλο διαχειρίζεται όλη τη συμπεριφορά και τα δεδομένα του συστήματος. Απαντάει σε αιτήσεις κυρίως της Όψης για πληροφορίες σχετικά με την κατάσταση στην οποία βρίσκεται και δέχεται εντολές από τον ελεγκτή ώστε να αλλάξει την κατάστασή του. View 41 Σ ε λ ί δ α

Θεωρητικό και τεχνολογικό υπόβαθρο Η όψη αποτελεί τον τρόπο παρουσίασης των δεδομένων της εφαρμογής και είναι αυτή με την οποία αλληλεπιδρά ο χρήστης. Η όψη που θα εμφανιστεί κάθε φορά, εξαρτάται από την ενέργεια που θα εκτελέσει ο ελεγκτής και την επιλογή του χρήστη. Η όψη προβάλλεται στο χρήστη με τη μορφή HTML σελίδας στον browser που χρησιμοποιεί. Controller Αποτελεί την καρδιά του συστήματος. Είναι υπεύθυνος για τη διαχείριση του μοντέλου και της όψης. Πιο συγκεκριμένα ο ρόλος του είναι να επικοινωνεί με το μοντέλο στέλνοντας αιτήματα, για τις επιλογές ή τις εισόδους του χρήστη και με την όψη για να επιστρέφει τις αποκρίσεις του μοντέλου. Εικόνα 18 Το μοτίβο μοντέλο - όψη - ελεγκτής 2.11 S-CASE Το ευρωπαϊκό έργο S CASE, (ICT-FP7-610717), ένα τριετές ερευνητικό έργο που άρχισε το Νοέμβριο του 2013, φιλοδοξεί να παρέχει στους μηχανικούς λογισμικού μία σειρά από υπηρεσίες και εργαλεία, προκειμένου να αναπτύσσουν γρήγορα υπηρεσίες λογισμικού υψηλής ποιότητας. Μέσα από τις καινοτομίες που εισάγει, το έργο S-CASE αναμένεται να μειώσει το χρόνο που απαιτείται μεταξύ της σύλληψης μιας ιδέας και της τελικής υλοποίησης μιας υπηρεσίας λογισμικού, οδηγώντας έτσι σε φθηνότερες υπηρεσίες. 42 Σ ε λ ί δ α

Θεωρητικό και τεχνολογικό υπόβαθρο Το έργο S-CASE αφορά την αυτόματη δημιουργία RESTful διαδικτυακών υπηρεσιών μέσω πολυτροπικών (multi modal) απαιτήσεων με τη χρήση μιας μεθοδολογίας μηχανισμού οδηγούμενης από μοντέλα (MDE Model Driven Engineering). Ο κόσμος των υπηρεσιών διαδικτύου κινείται προς την κατεύθυνση του REST, και η πλατφόρμα του S-CASE στοχεύει στη διευκόλυνση των προγραμματιστών να υλοποιήσουν τέτοιες υπηρεσίες διαδικτύου, εστιάζοντας κυρίως στην τεχνολογία απαιτήσεων. Επομένως, το S-CASE, μέσα από μία αυτοματοποιημένη διαδικασία, καθορίζει όλες τις προδιαγραφές, τις λειτουργικές απαιτήσεις και τα σενάρια χρήσης που χρειάζεται η προς ανάπτυξη διαδικτυακή υπηρεσία [33]. 2.12 Bootstrap Το Bootstrap αποτελεί το δημοφιλέστερο HTML, CSS και JavaScript framework για την ανάπτυξη ιστοσελίδων με απόκριση. Παρέχει μια μεγάλη ποικιλία διαθέσιμων υλοποιημένων χαρακτηριστικών και προτύπων ιστοσελίδων. Το bootstrap είναι συμβατό με όλους τους browsers και κλιμακώνει αποτελεσματικά το μέγεθος και τη δομή της ιστοσελίδας στην οποία εφαρμόζεται και έτσι καθίσταται εφικτή η χρήση της από κάθε είδους συσκευή [34]. 2.13 JSON Το JSON ή αλλιώς JavaScript Object Notation είναι μια ελαφριά μορφή ανταλλαγής δεδομένων. Είναι εύκολη στους ανθρώπους να τη διαβάσουν και να τη γράψουν και αντίστοιχα εύκολο για τις μηχανές να το αναλύσουν και να το δημιουργήσουν. Είναι βασισμένο σε ένα υποσύνολο της γλώσσας προγραμματισμού JavaScript. Τέλος, είναι εντελώς ανεξάρτητο από τις γλώσσες προγραμματισμού, αλλά χρησιμοποιεί συμβάσεις γνωστές στους προγραμματιστές. Το πρότυπο είναι βασισμένο σε μια συλλογή ζευγών ονόματος/τιμής, κάτι που στις περισσότερες γλώσσες θεωρείται αντικείμενο και σε μια διατεταγμένη λίστα τιμών κάτι που αντίστοιχα θεωρείται πίνακας [35]. 2.14 YAML Η YAML προέρχεται από το αρκτικόλεξο YAML Ain't Markup Language και είναι μια γλώσσα επισκόπησης των δομών μιας εφαρμογής. Αποτελεί πρότυπο εύκολα κατανοητό από τον άνθρωπο και είναι συμβατή με όλες τις γλώσσες προγραμματισμού. Αποτελεί επίσης υπερσύνολο του JSON [36]. 43 Σ ε λ ί δ α

Θεωρητικό και τεχνολογικό υπόβαθρο Εικόνα 19 Λογότυπο Angular 2.15 Angular 2+ Η Angular (Angular 2 ή Angular 2+) είναι ένα πολύ δημοφιλές framework ανοικτού κώδικα διανομής της Google, βασισμένο στην Typescript. Ακολουθεί την MVC (Model-View-Controller) αρχιτεκτονική και χρησιμοποιείται για την ανάπτυξη διαδικτυακών εφαρμογών και εφαρμογών κινητών τηλεφώνων με HTML και JavaScript ή Typescript η οποία μεταγλωττίζεται σε JavaScript. H Angular ξαναγράφτηκε από την αρχή από την ίδια ομάδα που είχε αναπτύξει την Angular JS, ώστε να βελτιώσει και να λύσει τα προβλήματα της τελευταίας. Κάποια βασικά χαρακτηριστικά της αρχιτεκτονικής της είναι [37]: Βαθμίδες (Modules), δηλαδή κομμάτια κώδικα που χρησιμοποιούνται για να εκτελέσουν μια συγκεκριμένη εργασία Συστατικά (Components), ή αλλιώς κλάσεις ελεγκτών (controllers) που είναι υπεύθυνοι για την παρουσίαση των όψεων και την υλοποίηση της λογικής πίσω από αυτές Πρότυπα (Templates), που αποτελούν τις όψεις και λένε στην angular πώς να απεικονίσει τα components Μεταδεδομένα (Metadata), τα οποία δείχνουν τον τρόπο με τον οποίο πρέπει να προσεγγιστεί μία κλάση. Επισυνάπτονται στην TypeScript σαν διακοσμητές (decorators) «Δέσιμο Δεδομένων» (Data binding), αποτελούν τον τρόπο με τον οποίο μια διεργασία συντονίζει τις τιμές των δεδομένων εφαρμογής μεταξύ πηγών (sources) και στόχου (target) HTML στοιχείων 44 Σ ε λ ί δ α

Θεωρητικό και τεχνολογικό υπόβαθρο Υπηρεσία (Service), συναρτήσεις της JavaScript που επιτελούν μία και μοναδική εργασία, εισάγονται χρησιμοποιώντας τον μηχανισμό ένεσης εξάρτησης (Dependency Injection) Οδηγίες (Directives), κλάσεις που αναπαριστούν τα μεταδεδομένα Ένεσης εξάρτησης (Dependency Injection), σχεδιαστικό πρότυπο που περνάει μια υπηρεσία σαν εξάρτηση σε διαφορετικά components Εικόνα 20 Αρχιτεκτονική Angular 2.16 TypeScript Η TypeScript είναι μια ελεύθερη και ανοικτού κώδικα γλώσσα προγραμματισμού η οποία αναπτύχθηκε και συντηρείται από τη Microsoft από το 2012. Είναι σχεδιασμένη για την ανάπτυξη εφαρμογών μεγάλης κλίμακας, αποτελεί υπερσύνολο της ECMAScript 6 και είναι συμβατή προς τα πίσω με την ECMAScript 5 (JavaScript). Είναι, δηλαδή, ένα αυστηρό συντακτικό υπερσύνολο της JavaScript, την οποία και επεκτείνει προσθέτοντας στοιχεία αντικειμενοστρέφειας σε αυτή. Η TypeScript εισάγει έννοιες όπως αυτή του αντικειμενοστραφούς προγραμματισμού βασισμένου σε κλάσεις, τους στατικούς τύπους και το γενικό προγραμματισμό. Τέλος ο μεταγλωττιστής της TypeScript είναι γραμμένος στην ίδια τη γλώσσα και μετασχηματίζει σε JavaScript [38]. 45 Σ ε λ ί δ α

Θεωρητικό και τεχνολογικό υπόβαθρο 2.17 Node.js Το Node.js είναι μια πλατφόρμα που μας επιτρέπει να γράψουμε και να εκτελέσουμε JavaScript προγράμματα χωρίς την ανάγκη ενός φυλλομετρητή ιστού (web browser). Για να το πετύχει αυτό, μεταγλωττίζει σε γλώσσα μηχανής και «τρέχει» τα προγράμματα, κάνοντας χρήση της V8 3, μιας εικονικής μηχανής που αναπτύχθηκε από τη Google για τις ανάγκες του Chrome και στη συνέχεια εκδόθηκε ανεξάρτητα. Βασική φιλοσοφία του Node.js είναι ότι ο κώδικας που δεν πραγματοποιεί Είσοδο/Έξοδο (Ι/Ο) δεδομένων εκτελείται ταχύτατα και σύγχρονα, ωστόσο η Είσοδος/Έξοδος εκτελείται ασύγχρονα. Κάθε φορά δηλαδή που το πρόγραμμά μας προσπαθεί να «διαβάσει» κάτι από κάποιο αρχείο ή πηγή στο διαδίκτυο, η εφαρμογή δεν παγώνει περιμένοντας, αλλά θέτει μία συνάρτηση που θα εκτελεστεί όταν η είσοδος διαβαστεί και συνεχίζει κανονικά την εκτέλεσή του χωρίς να σταματά [18] [39]. Ένα από τα δυνατά σημεία του Node.js είναι, εκτός των άλλων, η τεράστια κοινότητα ανοικτού λογισμικού που το υποστηρίζει. Τα εργαλεία, οι επεκτάσεις και οι βιβλιοθήκες του δημοσιεύονται σε μία αποθήκη πακέτων Node στο διαδίκτυο, και μπορούν να εγκατασταθούν πολύ εύκολα σε μία εφαρμογή με χρήση του διαχειριστή πακέτων Node.js, NPM (Node Package Manager). 2.18 NPM To Node Package Manager (NPM), όπως αναφέρθηκε στην προηγούμενη ενότητα, είναι ένα εργαλείο διαχείρισης των πακέτων του Node.js. Η λειτουργία του είναι διττή. Αφενός επιτρέπει στους προγραμματιστές να δημοσιεύουν τον κώδικά τους στην απομακρυσμένη αποθήκη πακέτων του Node.js και αφετέρου επιτρέπει την εγκατάσταση βιβλιοθηκών που έχουν δημοσιευτεί στην αποθήκη αυτή για να χρησιμοποιηθούν από το πρόγραμμα. Η περιγραφή των απαιτήσεων στο NPM γίνεται με ένα JSON αρχείο που πρέπει να φέρει το όνομα «package.json». Το αρχείο αυτό, ορίζει δύο ήδη εξαρτήσεων: (1) εκείνες οι οποίες αποτελούν κομμάτι της εφαρμογής όταν αυτή δημοσιεύεται (dependencies) και (2) εκείνες οι οποίες χρησιμεύουν μόνο κατά την ανάπτυξη της εφαρμογής (devdependencies) [40]. 3 Για περισσότερες πληροφορίες σχετικά με το V8 https://developers.google.com/v8/ 46 Σ ε λ ί δ α

Θεωρητικό και τεχνολογικό υπόβαθρο Αφού αναλύσαμε λοιπόν τα πλεονεκτήματα του Node.js και του npm γίνεται φανερό για ποιο λόγο επιλέχθηκε η τεχνολογία αυτή κατά την εκπόνηση της παρούσας διπλωματικής εργασίας. Το βασικό, όμως πλεονέκτημα που παρέχει ο Node.js εξυπηρετητής είναι ότι φιλοξενεί τον πελάτη σε διαφορετικό χώρο από αυτόν που φιλοξενείται η υπηρεσία. Δηλαδή, παρέχει ανεξαρτησία του γραφικού περιβάλλοντος χρήστη από την υπηρεσία. Με αυτό τον τρόπο έχουμε τη δυνατότητα να πραγματοποιούμε αλλαγές σε καθένα από αυτά τα συστατικά, ανεξάρτητα από το άλλο, με μόνη προϋπόθεση να διατηρούμε το «συμβόλαιο» επικοινωνίας των δύο. Αυτό μας προσφέρει ευελιξία κατά την ανάπτυξη. Εικόνα 21 Λογότυπο node.js 47 Σ ε λ ί δ α

Σχετική βιβλιογραφία 3. Σχετική βιβλιογραφία 3.1 Clients και σύγχρονες τεχνολογίες κατανάλωσης Web API Η αυξανόμενη ανάγκη για ανάπτυξη διαδικτυακών APIs και η απαίτηση για την ελαχιστοποίηση του κόστους παραγωγής τους, έχει οδηγήσει στην προσπάθεια για την αυτοματοποίησης της διαδικασίας παραγωγής και ελέγχου των εφαρμογών πελάτη. Στην κατεύθυνση αυτή έχουν αναπτυχθεί διάφορα εργαλεία τα οποία εστιάζουν σε διαφορετικά σημεία της παραγωγής και η επιλογή τους εξαρτάται από το αποτέλεσμα που επιθυμεί να επιτύχει ο προγραμματιστής. Στην ενότητα αυτή θα αναφέρουμε κάποιες από τις λύσεις που έχουν προταθεί μέχρι σήμερα πέραν του Swagger Codegen που έχει περιγραφεί στο κεφάλαιο 2. 3.1.1 Alchemy Rest Client Generator Η τεχνολογία αυτή παράγει αυτόματα πελάτες σε γλώσσα java με υποκατάστατο (proxy) κώδικα που προσομοιώνει τις υπηρεσίες του διαδικτύου. Πιο συγκεκριμένα, παράγει ένα υποκατάστατο διακομιστή για RESTful κλάσεις διαδικτυακών υπηρεσιών κατάλληλες για δοκιμές (testing). Επιπλέον, παρέχει τη δυνατότητα αυτόματης παραγωγής νέου πελάτη κάθε φορά που αλλάζει ο κώδικας της διαδικτυακής υπηρεσίας. Τέλος, μετασχηματίζει τις εξαιρέσεις (exceptions) που παράγουν οι διαδικτυακές υπηρεσίες με τέτοιο τόπο ώστε να είναι αναγνωρίσιμες από τον πελάτη σαν εξαιρέσεις τοπικών συναρτήσεων [41]. 3.1.2 Fiware Rest Client Generator (eclipse plugin) To εργαλείο αυτό, επιτρέπει την αυτόματη παραγωγή ενός πελάτη σε Java για μια δεδομένη RESTful διαδικτυακή υπηρεσία. Ο κύριος στόχος αυτού του συστατικού (component) είναι να απλοποιήσει την ενσωμάτωση GE (Generic Enablers) στιγμιότυπων σε μελλοντικές διαδικτυακές εφαρμογές γραμμένες σε java. Όλες οι υπηρεσίες με RESTful διεπαφή, που παράγουν επίσημη περιγραφή της υπηρεσίας χρησιμοποιώντας ένα WADL αρχείο, υποστηρίζονται άμεσα από το εργαλείο αυτό [42]. 48 Σ ε λ ί δ α

Σχετική βιβλιογραφία 3.1.3 Restlet Studio To Restlet Studio αποτελεί μια πλατφόρμα που δίνει τη δυνατότητα στο χρήστη να ορίζει κάθε πτυχή του επιθυμητού API με χρήση γραφικού περιβάλλοντος. Έπειτα, επιτρέπει την αυτόματη ή χειροκίνητη παραγωγή ενός αρχείου τεκμηρίωσης με αναφορές, το οποίο μπορεί κανείς να τροποποιήσει με ευκολία χρησιμοποιώντας OpenApi ή RAML προδιαγραφές. Επιτρέπει επίσης, την παραγωγή σκελετών διακομιστή και βιβλιοθηκών πελάτη. Το Restlet Studio τρέχει εξολοκλήρου μέσα σε ένα μοντέρνο φυλλομετρητή και με αυτόν τον τρόπο επιτρέπει την επεξεργασία των API από οπουδήποτε. Το βασικό μειονέκτημα και αυτής της τεχνολογίας είναι πως δεν παρέχει μια ολοκληρωμένη λύση για τον μέσο χρήστη, καθώς δεν παράγει κανένα αρχείο για την γραφική αναπαράσταση των δεδομένων και των δυνατών ενεργειών, που παρέχει μια REST υπηρεσία [43]. 3.1.4 Auto Rest Το εργαλείο AutoRest είναι ακόμα μια προσπάθεια δημιουργίας βιβλιοθηκών πελάτη για την πρόσβαση σε διαδικτυακές υπηρεσίες τύπου REST. Η γεννήτρια δέχεται ως είσοδο ένα αρχείο προδιαγραφών που περιγράφει πλήρως το RESTful API χρησιμοποιώντας και αυτό τη μορφή Open API [44]. 3.1.5 Ολοκληρωμένες γραφικές εφαρμογές για τον έλεγχο της λειτουργίας των APIs Σε αυτή την κατηγορία ανήκουν πλατφόρμες που δέχονται σαν είσοδο τα URIs των πόρων του API και εκτελούν HTTP αιτήματα σε αυτό, εφόσον το τελευταίο το επιτρέπει, και εμφανίζουν τις αντίστοιχες αποκρίσεις. Χρησιμοποιώντας ένα απλό γραφικό περιβάλλον δίνουν τη δυνατότητα στο χρήστη να τροποποιήσει τα αιτήματα, τις κεφαλίδες (headers), καθώς και να προσθέσει η να αφαιρέσει πιστοποίηση ταυτότητας (authentication). Παραδείγματα της εν λόγω κατηγορίας αποτελούν πλατφόρμες όπως Postman [45], Advanced REST Client 4 τα οποία είναι ενσωματωμένα σε 4 https://advancedrestclient.com/ 49 Σ ε λ ί δ α

Σχετική βιβλιογραφία φυλλομετρητές, αλλά διατίθενται και για κατέβασμα, αλλά και paw 5 για (MAC OS X), vrest 6 (online) και TestingWhiz 7. 3.1.6 Ολοκληρωμένες εφαρμογές διεπαφής χρήστη Εκτός των παραπάνω εργαλείων και κατηγοριών, υπάρχει μία μικρότερη κατηγορία στην οποία ανήκουν εφαρμογές που δέχονται σαν είσοδο την οντολογία του API και δίνουν στην έξοδό τους μια ολοκληρωμένη εφαρμογή κατάλληλη για χρήση και έλεγχο του API. Παραδείγματα εφαρμογών αυτής της κατηγορίας είναι το ngadmin [46] και LightAdmin [47]. 3.2 Συμπεράσματα Ερευνώντας γύρω από τις σύγχρονες τάσεις και τεχνολογίες για τον έλεγχο, την παραγωγή βιβλιοθηκών REST πελάτη, αλλά και την παραγωγή ολοκληρωμένων εφαρμογών πελάτη έτοιμων προς κατανάλωση, γίνεται φανερό πως η τελευταία κατηγορία δεν έχει αναπτυχθεί τόσο όσο οι υπόλοιπες. Αυτό συμβαίνει για πολλούς λόγους, όπως ότι η δομή του πελάτη εξαρτάται σε μεγάλο βαθμό από τη δομή της υπηρεσίας (service). Με άλλα λόγια, η εφαρμογή του πελάτη εξαρτάται σε μεγάλο βαθμό από τα μοντέλα-πόρους, αλλά και από τα αναγνωριστικά των πόρων και τη δομή τους, κάτι που καθιστά τη διαδικασία της αφαίρεσης (abstraction) και γενίκευσης εξαιρετικά δύσκολη. Από την άλλη, η κατανόηση για τον τρόπο λειτουργίας του API, αλλά και του ίδιου του REST παίζει πολύ σημαντικό ρόλο στην ανάπτυξη πελατών. Επιπλέον, για τον έλεγχο των αυτόματα παραγόμενων πελατών πρέπει να υπάρχει πάντα μια υπηρεσία η οποία θα τρέχει πάνω σε έναν εξυπηρετητή κάτι που σε πολλές περιπτώσεις δεν είναι ούτε επιθυμητό ούτε εφικτό. Το ίδιο πρόβλημα παρουσιάζεται και κατά τον έλεγχο των APIs χωρίς τη χρήση γραφικού περιβάλλοντος πελάτη. 5 https://paw.cloud/ 6 https://vrest.io/ 7 http://www.testing-whiz.com/ 50 Σ ε λ ί δ α

Μεθοδολογία 4. Μεθοδολογία 4.1 Γενικά Όπως αναφέρθηκε και παραπάνω, η διαδικασία αυτόματης παραγωγής πελατών που θα καταναλώνουν διαδικτυακά APIs είναι σε πρώιμο ακόμη στάδιο. Η παρούσα διπλωματική αποσκοπεί στη δημιουργία ενός εργαλείου αυτόματης παραγωγής γραφικών διεπαφών περιβάλλοντος χρήστη, πλήρως προσαρμόσιμων στη δομή ενός RESTful web API, δηλαδή μιας διαδικτυακής υπηρεσίας που υπακούει στην αρχιτεκτονική REST. Η αυτόματη παραγωγή πραγματοποιείται χρησιμοποιώντας σαν βάση ένα αρχείο προδιαγραφών διαδικτυακών υπηρεσιών σε Open Api. Για την υλοποίηση του πελάτη χρησιμοποιείται η Angular2+ που αποτελεί framework της JavaScript. Η εφαρμογή δομήθηκε με τέτοιο τρόπο ώστε η χρήση της να μην χρειάζεται καμιά γνώση ανάπτυξης γραφικού περιβάλλοντος χρήστη και δεν απαιτεί καμία παρέμβαση από προγραμματιστή για τη λειτουργία της. Μοναδική απαίτηση της εφαρμογής, είναι η σύνταξη ενός αρχείου που θα περιέχει την οντολογία του API σε Open Api με τον τρόπο που περιγράφεται παρακάτω. Η προτεινόμενη εφαρμογή μπορεί να χρησιμοποιηθεί για τον έλεγχο της λειτουργίας ενός API (testing), αλλά και σαν μια πρότυπη εφαρμογή για την παρουσίαση του API και της λειτουργικότητας του. 4.2 Δομή της εφαρμογής Ξεκινώντας, κρίνεται σκόπιμο, να γίνει μια παρουσίαση της αρχιτεκτονικής της εφαρμογής ώστε να γίνεται πιο ξεκάθαρος στον αναγνώστη ο στόχος του κάθε επιμέρους σταδίου, αλλά και οι διάφορες αλληλοεξαρτήσεις των σταδίων μεταξύ τους. Συνοπτικά, η διαδικασία αρχίζει με τη σύνταξη ενός αρχείου προδιαγραφών Open API σε μορφή YAML ή JSON οι οποίες αποτελούν ουσιαστικά την οντολογία του API. Το JSON αρχείο που προκύπτει έχει διττό ρόλο. Από τη μία χρησιμοποιείται για την παραγωγή βιβλιοθηκών πελάτη που εισάγονται στην εφαρμογή χωρίς περαιτέρω επεξεργασία και από την άλλη εισάγεται στον Parser όπου και αναλύεται με σκοπό τη δημιουργία ενός μοντέλου που περιέχει όλη την πληροφορία για τους περιγραφόμενους 51 Σ ε λ ί δ α

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

Μεθοδολογία 4.3 YAML & JSON Όπως φαίνεται στο παραπάνω σχήμα, αρχικά σχηματίζουμε ένα αρχείο προδιαγραφών τύπου YAML γραμμένο σε OpenAPI. Το αρχείο αυτό μπορούμε να το συντάξουμε σε οποιοδήποτε συντάκτη κειμένου, αλλά μιας και η μορφή του είναι αυστηρή, στη διπλωματική αυτή χρησιμοποιήθηκε το Swagger Editor. Το Swagger Editor είναι ένας συντάκτης κειμένου ο οποίος ενημερώνει το χρήστη για πιθανά λάθη στη σύνταξη του αρχείου και το σημείο στο οποίο υπάρχει το λάθος. Επιπλέον, δημιουργεί αυτόματα ένα υποτυπώδες γραφικό περιβάλλον, δίνοντας έτσι έναν εύκολο τρόπο στο χρήστη να ελέγχει τη δομή του API. Μέσω του περιβάλλοντος αυτού ο χρήστης δεν χρειάζεται να ανατρέχει κάθε στιγμή στο αρχείο με τις προδιαγραφές, εργασία επίπονη και απαιτητική, ιδιαίτερα όταν ο αριθμός των γραμμών του αρχείου προδιαγραφών είναι μεγάλος. Από το Swagger Editor εξάγουμε το JSON, αρχείο με το οποίο θα τροφοδοτήσουμε τις επόμενες διαδικασίες. Στο σημείο αυτό να σημειωθεί πως δεν είναι η αναγκαία η σύνταξη του αρχείου προδιαγραφών σε μορφή YAML και έπειτα η εξαγωγή του αντίστοιχου JSON. Παρόλο που θα μπορούσε κανείς από την αρχή να συντάξει το JSON αρχείο σύμφωνα με το πρότυπο Open API και να παραλείψει τα παραπάνω βήματα, η παραπάνω διαδικασία ενθαρρύνεται καθώς η μορφή YAML είναι ευκολότερα αναγνώσιμη από τους ανθρώπους και το γραφικό περιβάλλον του Swagger Editor βοηθάει στην καλύτερη εποπτεία του API. 4.3.1 Περιορισμοί OpenAPI Specification αρχείου Όπως είναι φυσικό, η παρούσα διπλωματική καλύπτει ένα μέρος μόνο των δυνατοτήτων που παρέχει το πρότυπο OpenAPI. Οι παραδοχές που χρησιμοποιήθηκαν, έγιναν για σχεδιαστικούς λόγους στην προσπάθεια να ξεπεραστούν κάποιες δυσκολίες που προέκυπταν από τον τρόπο δομής του ίδιου του OpenAPI καλύπτοντας όσο το δυνατόν μεγαλύτερο εύρος περιπτώσεων. Μια πρόκληση, για παράδειγμα ήταν ο τρόπος σχεδίασης ενός πίνακα με υπερσυνδέσμους που υποδεικνύουν τις επιτρεπτές καταστάσεις στις οποίες μπορεί να γίνει μετάβαση με αναφορά στο τρίτο επίπεδο ωριμότητας του Richardson. Ο πίνακας αυτός με τους υπερσυνδέσμους έπρεπε να σχεδιαστεί και να υλοποιηθεί από την αρχή καθώς το πρότυπο Swagger 2 δεν υποστηρίζει την ύπαρξη του. Λόγω της σημασίας του, σχεδιάζεται η ενσωμάτωσή του στην κυκλοφορία του OpenAPI 3. Με τη σύγκριση των παρακάτω εικόνων μπορεί κανείς να εντοπίσει τις βασικές διαφορές ανάμεσα στις δύο αυτές κυκλοφορίες (releases). 53 Σ ε λ ί δ α

Μεθοδολογία Ιδιαίτερη μέριμνα δόθηκε στο γεγονός της επεκτασιμότητας και για το λόγο αυτό η σχεδίαση πραγματοποιήθηκε με τέτοιο τόπο, ώστε στο μέλλον να συμπεριληφθούν και οι ειδικές περιπτώσεις ή εντελώς καινούρια χαρακτηριστικά. Εικόνα 23 Swagger 2 vs. OpenAPI 3 Περιορισμοί Για να μπορεί ο Parser να αναλύσει σωστά το αρχείο και να δημιουργήσει τον πίνακα με την «οικογένεια» υπερσυνδέσμων, το αρχείο YAML ή JSON πρέπει να ακολουθεί τους παρακάτω περιορισμούς: 1. Τα ονόματα των πόρων μαζί με τα χαρακτηριστικά τους, σύμφωνα με το API στο οποίο αναφέρονται, πρέπει να ορίζονται σαν μοντέλα στην κατηγορία definitions. Το όνομα του πόρου πρέπει να ξεκινάει με κεφαλαίο και να είναι στον ενικό αριθμό. Η συλλογή πόρων αντίθετα πρέπει να ξεκινάει με κεφαλαίο, να είναι στον πληθυντικό αριθμό και να αποτελεί έναν πίνακα με αναφορά στον πόρο. 54 Σ ε λ ί δ α

Μεθοδολογία Εικόνα 24 Ορισμοί γραμμένοι σε αρχείο YAML 2. Οι παράμετροι που χρησιμοποιούνται από όλες τις μεθόδους ενός συγκεκριμένου μονοπατιού (path), πρέπει να δηλώνονται γενικά μετά το όνομα του path και πριν από τα HTTP ρήματα. Οι αναφορές πρέπει να ορίζονται σύμφωνα με τη σειρά που έχουν μέσα στο μονοπάτι ξεκινώντας από αριστερά προς τα δεξιά. Συστήνεται επίσης η χρήση αναφορών στο σημείο αυτό και η επεξήγηση των παραμέτρων στην κατηγορία παράμετροι (parameters), ώστε να αποφεύγεται η επανάληψη. Εικόνα 25 Μορφή παραμέτρων γραμμένες σε αρχείο YAML 3. Τα μονοπάτια (paths) πρέπει να είναι στη μορφή /resource/{resourceid}, με όσο βάθος εξυπηρετεί. Ο κάθε πόρος πρέπει να γράφεται στον ενικό με μικρά γράμματα, συμφωνώντας γραμματικά με το αντίστοιχο μοντέλο που ορίστηκε νωρίτερα. Αυτός ο περιορισμός εξυπηρετεί το διαχωρισμό των πόρων (resources) και υπο-πόρων (sub-resources) από τα υπόλοιπα μοντέλα που περιγράφονται στους ορισμούς (definitions). 55 Σ ε λ ί δ α

Μεθοδολογία 4. Η απαντήσεις μιας επιτυχούς HTTP κλήσης, αν χρειάζεται να επιστρέφουν μοντέλο, πρέπει να γράφονται με αναφορά στο μοντέλο, ή στη συλλογή αυτών. Η ίδια στρατηγική ενθαρρύνεται και στην περίπτωση των παραμέτρων σώματος (body parameters), χωρίς όμως εκεί να είναι απαραίτητο. Εικόνα 26 Αναφορά σε αντικείμενα στις απαντήσεις και παραμέτρους Κλείνοντας τους περιορισμούς που πρέπει να διέπουν το YAML ή JSON αρχείο να τονίσουμε πως δεν υπάρχει κανένα πρόβλημα στον ορισμό των ιδιοτήτων των μοντέλων, καθώς πέρα από τους βασικούς τύπους υποστηρίζονται και οι τύποι Αντικείμενο (Object), Πίνακας (Array), Αναφορά (Reference) καθώς και συνδυασμοί αυτών. 4.4 Swagger Code Generator Για την αυτόματη παραγωγή βιβλιοθηκών πελάτη σε Angular2+ με TypeScript χρησιμοποιήθηκε JSON αρχείο το οποίο δόθηκε σαν είσοδος στο Swagger CodeGen έκδοση 2.3.0 8. Η έκδοση αυτή δεν ήταν ακόμα η σταθερή (stable) όταν χρησιμοποιήθηκε στα πλαίσια της διπλωματικής αυτής. Επιλέχθηκε μετά από επικοινωνία με την κοινότητα του swagger μέσω του forum που διαθέτει, διότι σε αυτή είχε ενσωματωθεί πιο εύρωστος κώδικας, όσον αφορά την Angular2 με TypeScritpt. Η αλλαγή αυτή 8 https://github.com/swagger-api/swagger-codegen/tree/2.3.0 56 Σ ε λ ί δ α

Μεθοδολογία πραγματοποιήθηκε προς το τέλος της διπλωματικής και κατάφερνε να αξιοποιεί καλύτερα τις ιδιότητες της Angular4, η οποία επεκτείνει την Angular2 και κυκλοφόρησε τον Μάρτιο του 2017. Από το Swagger CodeGen εξάγονται κάποιοι φάκελοι που περιέχουν τα μοντέλα, τις συναρτήσεις που κάνουν κλήσεις στη διαδικτυακή υπηρεσία καθώς και κάποια αρχεία ρυθμίσεων. Εάν στο αρχείο JSON που έχουμε συντάξει δεν υπάρχουν ετικέτες (tags), τότε όλες οι συναρτήσεις συμπεριλαμβάνονται σε ένα αρχείο που ονομάζεται defaultservice.ts. Ειδάλλως, κάθε συνάρτηση κατηγοριοποιείται σε διαφορετικό αρχείο ανάλογα με την ετικέτα που φέρει (π.χ. petapi.ts για ετικέτα pet). Οι υπηρεσίες αυτές δίνονται σαν είσοδος στον πελάτη ώστε να χρησιμοποιηθούν χωρίς καμία τροποποίηση χρησιμοποιώντας την υπηρεσία Dependency Injection της Angular που έχει αναλυθεί εκτενέστερα στο κεφάλαιο 2. Σημείωση Χρήσιμο είναι στο σημείο αυτό να καταλάβουμε τον τρόπο με το οποίο ονοματίζονται οι συναρτήσεις από την αυτόματη παραγωγή βιβλιοθηκών. Από τη μία, εάν μέσα στο μονοπάτι και στο HTTP ρήμα υπάρχει η μεταβλητή που ονομάζεται «operationid», τότε η τιμή της μεταβλητής αποτελεί το όνομα της αντίστοιχης συνάρτησης. Αν ο συντάκτης του αρχείου προδιαγραφών επιλέξει να μην συμπεριλάβει την εν λόγω μεταβλητή, τότε η ονοματολογία εφορμά από τον συνδυασμό του μονοπατιού και του HTTP ρήματος. Για να γίνει πιο κατανοητή η τελευταία διαδικασία θα προσπαθήσουμε να την αποσαφηνίσουμε με ένα παράδειγμα. Πίνακας 6 Ονοματολογία συνάρτησης Path Verb Function /product/{productid}/purchase/{purchase-id} delete productproductidpurchasepurchaseiddelete Με λίγα λόγια, το όνομα ξεκινάει με μικρό και έπειτα από κάθε χαρακτήρα «/» το πρώτο γράμμα γίνεται κεφαλαίο, όπως και το πρώτο γράμμα του ρήματος. Το ίδιο συμβαίνει και στην περίπτωση του χαρακτήρα «-», ο οποίος απαλείφεται και το επόμενο γράμμα του γίνεται κεφαλαίο. Ο τόπος ονοματολογίας είναι ιδιαίτερα σημαντικός στην αυτοματοποίηση, καθώς χρησιμοποιείται στο σχηματισμό ενός πίνακα με τις διαθέσιμες συναρτήσεις ανά μονοπάτι στον parser. 57 Σ ε λ ί δ α

Μεθοδολογία 4.5 Parser Ανάλυση JSON Η διαδικασία ανάλυσης του αρχείου JSON στα συστατικά του, ή αλλιώς Parser, υλοποιείται με την υπηρεσία JsonProcessingService, η οποία εκτελείται μία φορά κατά την αρχικοποίηση της εφαρμογής πελάτη ώστε να παράγει τα κατάλληλα μοντέλα που χρειάζονται για την αυτοματοποίηση των γραφικών διεπαφών. Η υπηρεσία αυτή εισάγεται με Dependency Injection στο κατάλληλο σημείο του πελάτη, καλείται μέσω της συνάρτησης getjson() και επιστρέφει έναν πίνακα από αντικείμενα τύπου Model. Πριν όμως περάσουμε στην ανάλυση της δομής της υπηρεσίας, θα κάνουμε μερικές βοηθητικές παρατηρήσεις που θα συνεισφέρουν στην κατανόηση των επιλογών που έγιναν στο πλαίσιο της δόμησης της υπηρεσίας αυτής. Αρχικά, δεν είναι δύσκολο να παρατηρήσει κανείς πως το αρχείο χρησιμοποιεί μια ιεραρχική δομή για την υλοποίησή του, η οποία αποτελείται από κάποια βασικά αντικείμενα τα οποία περιέχουν στο εσωτερικό τους εμφωλευμένα αντικείμενα και πως το μοτίβο αυτό εξελίσσεται σε βάθος πολλών επιπέδων. Με βάση την παρατήρηση αυτή χρησιμοποιήθηκε μια αναδρομική διαδικασία για την ανάλυση. Έπειτα, προκειμένου οι παραγόμενες εφαρμογές πελάτη να είναι σύμφωνες με το REST αρχιτεκτονικό πρότυπο και να επιτευχθεί το τρίτο επίπεδο του Richardson Maturity Model, σχηματίζονται τρία βασικά αντικείμενα, τα οποία τελικά συντίθενται σε ένα, το οποίο περιέχει όλη την απαιτούμενη πληροφορία που χρειάζεται η εφαρμογή πελάτη. Τα αντικείμενα αυτά για την εξαγωγή τους χρησιμοποιούν μια αναδρομική διαδικασία το καθένα, και δεν εξάγονται όλα από μια και μόνο αναδρομική διαδικασία. Αυτό συμβαίνει λόγω των αλληλοεξαρτήσεων μεταξύ τους που απαιτούν πρώτα να αρχικοποιείται το ένα και έπειτα το άλλο. Τα τρία βασικά αντικείμενα με τις ιδιότητες τους φαίνονται στο παρακάτω σχήμα. 58 Σ ε λ ί δ α

Μεθοδολογία Model name (string) properties (Object []) name (string) type (string) ref (string) object (Model) relatedresource (string [ ]) pathlist (Path [ ]) issubresource (number) Path name(string) child (Path [ ]) parent (Path [ ]) method (Object [ ]) name (string) functionname (string) functions (Function) Function name (string) path (string) parameters (Object [ ]) name (string) type (string) object (Model) response(object) name (string) model (Model) type (string) Εικόνα 27 Βασικά μοντέλα ανάλυσης από τον parser 4.5.1 Model Το μοντέλο αποτελεί τη βάση πάνω στην οποία στηρίζονται οι εφαρμογές πελάτη που προτείνονται στην παρούσα διπλωματική. Είναι το δομικό συστατικό όλης της εφαρμογής και μετά την εκτέλεση της υπηρεσίας JsonProcessingService, περιέχει όλη την απαραίτητη πληροφορία για τη δημιουργία των γραφικών διεπαφών χρήστη. Το μοντέλο έχει ένα όνομα το οποίο ταυτίζεται με το όνομα (name) του κάθε πόρου, έναν πίνακα που περιέχει τις ιδιότητες (properties) του πόρου, έναν πίνακα relatedresource που περιέχει τα ονόματα των πόρων που σχετίζονται με αυτόν, έναν πίνακα από αντικείμενα τύπου Path, ο οποίος διαχειρίζεται όλη την πληροφορία για τις επιτρεπόμενες καταστάσεις μετάβασης και τέλος μία μεταβλητή που φέρει το όνομα issubresource, η οποία ελέγχει αν το μοντέλο αποτελεί πόρο (resource), υπό-πόρο (subresource) ή τίποτα από τα προηγούμενα. Όπως αναφέρθηκε και παραπάνω, σαν ιδιότητες μπορεί εκτός των βασικών τύπων να αναγνωριστούν και να αναλυθούν πίνακες, αντικείμενα, αναφορές σε αντικείμενα ή και συνδυασμός αυτών. 4.5.2 Path Το μοντέλο αυτό αποτελεί το χρησιμότερο εργαλείο στην κατασκευή της οικογένειας των μονοπατιών, δηλαδή των επιτρεπόμενων καταστάσεων μετάβασης όπως προβλέπει ο Richardson. Ιδιότητές του είναι: το όνομά του (name), ένας πίνακας από Path που υποδεικνύει τα παιδιά του, δηλαδή σε ποιες καταστάσεις μπορεί να μεταβεί προς τα μπρος, ένας πίνακας από Path που υποδεικνύει τους γονείς του, δηλαδή σε ποιες καταστάσεις μπορεί να μεταβεί προς τα πίσω από πού μπορεί να έχουμε μεταβεί σε αυτό και τέλος ένα αντικείμενο που περιέχει τις επιτρεπτές ενέργειες συναρτήσεις ανάλογα με το HTTP 59 Σ ε λ ί δ α

Μεθοδολογία ρήμα. Το αντικείμενο αυτό έχει ένα όνομα (name) που δείχνει το HTTP ρήμα, το όνομα της αντίστοιχης συνάρτησης για το συγκεκριμένο μονοπάτι και ρήμα και τέλος την οντότητα της συνάρτησης τύπου Function. 4.5.3 Function Μοντέλο υπεύθυνο για τη διαχείριση των επιτρεπτών συναρτήσεων για κάθε μέθοδο κάθε μονοπατιού. Αποτελείται από το όνομά της, το οποίο σχηματίζεται σύμφωνα με τους τρόπους που περιγράφηκαν στην ενότητα Swagger Codegen. Έπειτα ακολουθεί η παράμετρος στην οποία αποθηκεύεται το όνομα του μονοπατιού (path) στο οποίο αντιστοιχεί η εν λόγω συνάρτηση και ένας πίνακας στον οποίο περιέχονται οι παράμετροι τις οποίες χρειάζεται η συνάρτηση για να καλεστεί. Τέλος, υπάρχει μία ιδιότητα στο μοντέλο αυτό, η οποία απεικονίζει τη θετική απόκριση, εάν και εφόσον αυτή υπάρχει. Η απόκριση αυτή αποτελείται από το όνομα του Model και το ίδιο το Model. 4.5.4 Λειτουργία JsonProcessingService Αφού δόθηκε μια σαφής περιγραφή των μοντέλων τα οποία σχηματίζονται μέσα από τη διαδικασία της υπηρεσίας JsonProcessingService, μπορούμε στο σημείο αυτό να εξηγήσουμε λεπτομερέστερα τη λειτουργία της υπηρεσίας μέσω των συναρτήσεών της. Στον παρακάτω πίνακα παρουσιάζονται οι συναρτήσεις με τη σειρά που καλούνται και δίνεται μια σύντομη περιγραφή της καθεμιάς, έπειτα παρουσιάζονται αναλυτικότερα κάποιες από τις συναρτήσεις που επιτελούν τις πιο σημαντικές λειτουργίες ώστε να σχηματιστεί το τελικό Model που χρησιμοποιείται εκ των υστέρων στη δημιουργία αφαιρετικών διεπαφών στην εφαρμογή χρήστη. Πίνακας 7 Συναρτήσεις και περιγραφή αυτών της υπηρεσίας JsonProcessingService Όνομα Συνάρτησης getjson ParseCases Περιγραφή Διαβάζει το αρχείο JSON και επιστρέφει τον Πίνακα των μοντέλων ή undefined σε περίπτωση αποτυχίας Καλεί κάθε μία από τις συναρτήσεις για το σχηματισμό των μοντέλων καθώς και αυτές που τα συσχετίζουν μετά τον ορισμό τους 60 Σ ε λ ί δ α

Μεθοδολογία Αναλύει τα definitions και αναθέτει στα μοντέλα ParseDefinitions recursion ParsePaths buildpathfamily findsubresouressecondlevel ParseParameters assignobjtorefs ParseResponse FunctionToPath FindResourceRelations τις τιμές name και properties, καθώς και διαβάζει το όνομα του API Ελέγχει το βάθος του δέντρου με τα Αντικείμενα και ανάλογα από ποια συνάρτηση καλείται εκτελεί την κατάλληλη αναδρομή Αναλύει τα paths και αναθέτει σε αυτά τις τιμές name και τα αντικείμενα method Χτίζει τον πίνακα με child και parent κάθε μονοπατιού Χτίζει τον πίνακα με child και parent κάθε μονοπατιού υποστηρίζοντας διαφορετική μορφή υποπόρων Αναθέτει τιμές στον πίνακα parameters του μοντέλου Function Χειρίζεται τις αναφορές του πίνακα parameters του μοντέλου Function και αναθέτει σε αυτές τα αντίστοιχα μοντέλα τύπου Model Δίνει τιμές στην παράμετρο response του μοντέλου Function Αναθέτει τις αντίστοιχες συναρτήσεις στα μοντέλα τύπου Path ελέγχοντας το όνομα της κάθε συνάρτησης Βρίσκει τη συγγένεια μεταξύ των πόρων και κατασκευάζει το pathlist κάθε Model. Ελέγχει επίσης αν το συγκερκιμένο μοντέλο αποτελεί πόρο/ υπό-πόρο ή τίποτα από τα δύο 61 Σ ε λ ί δ α

Μεθοδολογία Συνάρτηση buildpathfamily Πίνακας 8 Συνάρτηση buildpathfamily Στη συνάρτηση αυτή ελέγχεται κάθε μονοπάτι με όλα τα άλλα αφού πρώτα τα ονόματα των μονοπατιών σχηματίσουν πίνακες αφαιρώντας το χαρακτήρα «/» από αυτά. Εάν οι δύο αυτοί πίνακες διαφέρουν κατά 1 σε μέγεθος και τα στοιχεία τους από το πρώτο μέχρι το προτελευταίο του μεγαλύτερου είναι ίδια, τότε τα δύο μονοπάτια σχετίζονται μεταξύ τους με το μεγαλύτερο να αποτελεί παιδί του μικρότερου, ενώ το μικρότερο γονέας του μεγαλύτερου. Μέσα από αυτή τη συνάρτηση καλείται η findsubresouressecondlevel ώστε να καλύψει ένα ακόμη σχήμα της σχέσης πόρου υπό-πόρου. Η παραπάνω συνάρτηση μπορεί να σχηματίσει άρτια τα οικογενειακά δέντρα μονοπατιών σύμφωνα με τα ακόλουθα σχήματα. 62 Σ ε λ ί δ α

Μεθοδολογία Πίνακας 9 Σχήμα 1 Παράδειγμα /πόρος/υποπόρος1/ /υποπόροςν Πίνακας 10 Σχήμα 2 Παράδειγμα /πόρος/υποπόρος1 /πόρος/υποπόρος2 /πόρος/υποπόροςν 63 Σ ε λ ί δ α

Μεθοδολογία Πίνακας 11 Σχήμα 3 Παράδειγμα /πόρος1/υποπόρος /πόρος2/υποπόρος Τα σχήματα αυτά μπορεί να υποστηρίζουν διαφορετικές μορφές URIs, ανάλογα με τη δομή της διαδικτυακής υπηρεσίας. Στο πλαίσιο αυτής της διπλωματικής προσπάθησαν να ικανοποιηθούν κάποια γενικά σχήματα, χωρίς όμως αυτό να σημαίνει μπορούν να υποστηριχθούν τα σχήματα αυτά σε κάθε διαδικτυακή υπηρεσία λόγω της εξάρτησης των URIs από αυτή. Για τον παραπάνω λόγο έγινε μια προσπάθεια να υποστηριχθεί το παρακάτω σχήμα ως επέκταση της σχέσης ενός βασικού πόρου με τους υποπόρους του. Παρόλο, όμως που το σχήμα αυτό αναλύθηκε επιτυχώς από τον Parser και σχηματίστηκε άρτια το οικογενειακό δέντρο των πόρων με τις πιθανές καταστάσεις μετάβασης, λόγω χρόνου δεν υποστηρίζεται από την εφαρμογή πελάτη. Για το λόγο αυτό προτείνεται για ενσωμάτωση σε μια μελλοντική έκδοση. Πίνακας 12 Σχήμα 4 64 Σ ε λ ί δ α

Μεθοδολογία Παράδειγμα /πόρος/υποπόρος1 /υποπόρος1/υποπόρος2 Συνάρτηση findresourcessecondlevel Πίνακας 13 Συνάρτηση findresourcessecodlevel Η παραπάνω συνάρτηση δημιουργεί το οικογενειακό δέντρο του παραπάνω σχήματος, χρησιμοποιώντας τα αποτελέσματα της συνάρτησης buildpathfamily. Τα αποτελέσματα αυτά δημιουργούν σωστά το οικογενειακό δέντρο, εκτός από την περίπτωση Παιδί του πρώτου υποπόρου και Γονέας του δεύτερου υποπόρου. Για το χειρισμό αυτών των περιπτώσεων ελέγχονται και πάλι όλα τα μονοπάτια μεταξύ τους, σχηματίζονται δύο πίνακες και πάλι κατά αντιστοιχία με αυτούς της συνάρτησης buildpathfamily και ελέγχεται μια συνθήκη. Αν οι θέσεις 1, 2 του ενός μονοπατιού είναι ίδιες με τις δύο τελευταίες θέσεις του άλλου και αν το μέγεθος είναι μεγαλύτερο από 2 (δηλ. δεν είναι πόρος) και το μέγεθός τους διαφέρει κατά ένα, τότε αν δεν υπάρχει στον πίνακα με τα παιδιά ή τους γονείς αντίστοιχα για κάθε μονοπάτι, ανατίθεται η τιμή του στους πίνακες αυτούς. 65 Σ ε λ ί δ α

Μεθοδολογία Συνάρτηση findresourcesrelations Πίνακας 14 Συνάρτηση findresourcesrelations Με τη συνάρτηση αυτή, σχηματίζεται το τελικό pathlist (οικογενειακό δέντρο) του κάθε μοντέλου ελέγχοντας τη σχέση ανάμεσα στο μονοπάτι και το όνομα του μοντέλου είτε το μοντέλο αποτελεί πόρο ή υποπόρο. Μεριμνάται η περίπτωση που το μονοπάτι δείχνει σε ένα συγκεκριμένο πόρο ή υποπόρο και ανατίθεται έπειτα στο κατάλληλο μοντέλο. Τέλος ανατίθεται τιμή στην ιδιότητα issubresource ώστε να ξεχωρίζουν οι πόροι. 4.6 Εφαρμογή Πελάτη Αφού αναλυθεί το JSON αρχείο και εξαχθεί ο πίνακας με τα μοντέλα που περιέχουν όλη την απαραίτητη πληροφορία για την αυτοματοποίηση των γραφικών διεπαφών του πελάτη, αλλά και αφού παράγουμε τις βιβλιοθήκες του πελάτη μέσω του Swagger Code Generator, θα δώσουμε αυτά τα 2 προϊόντα της 66 Σ ε λ ί δ α

Μεθοδολογία επεξεργασίας μας στον πελάτη ώστε να δημιουργήσει τις κατάλληλες γραφικές διεπαφές, αλλά και να υλοποιήσει την απαραίτητη λειτουργικότητα. Η εφαρμογή του πελάτη, λοιπόν, αποτελείται από τα παρακάτω συστατικά: 6 όψεις υλοποιημένες σε HTML και μορφοποιημένες με το Bootstrap, τις App, NavigationView, Main, Resource, ResourceView και ResourceEdit 6 αντίστοιχα συστατικά (components) που χειρίζοντα τις όψεις, γραμμένα σε Angular4, τα AppComponent, NavigationComponent, MainComponent, ResourceViewComponent, ResourceComponent και ResourceEditComponent 2 services, την JsonProcessingService που περιγράφηκε παραπάνω και την ViewController Τις υπηρεσίες που έχουν παραχθεί από το Swagger Code Generator 4.6.1 AppComponent AppView Το συστατικό app (AppComponent) είναι υπεύθυνο για τη αρχικοποίηση της εφαρμογής. Μέσω της όψης του και πιο συγκεκριμένα, μέσα από την οδηγία (directive) navigationbar εμφανίζεται σε όλη την εφαρμογή μια μπάρα πλοήγησης που επιτρέπει την επιλογή των πόρων και την επιστροφή στην αρχική σελίδα. Μέσω της οδηγίας αυτής επίσης εκκινεί το NavigationComponent, του οποίου η λειτουργικότητα περιγράφεται αναλυτικά παρακάτω. Να τονίσουμε εδώ, πως η μπάρα πλοήγησης είναι ορατή σε όλες τις άλλες όψεις εφόσον αρχικοποιείται στο AppView, λόγω ιδιότητας της Angular. 4.6.2 NavigationComponent NavigationView Το συστατικό Navigation (NavigationComponent) είναι αυτό στο οποίο εισάγεται με Dependency Injection (DI) η υπηρεσία JsonProcessingService. Μέσω αυτής καλείται η συνάρτηση jsonparse που επιστρέφει τον πίνακα των μοντέλων και έτσι πια, αυτά μπορούν να προσπελαστούν από την εφαρμογή του πελάτη. Την όψη, όπως περιγράφηκε και παραπάνω, αποτελεί μια μπάρα πλοήγησης που επιτρέπει την πλοήγηση στην αρχική σελίδα και την επιλογή ενός από τους κύριους πόρους. Το συστατικό αντίστοιχα, ανάλογα με την επιλογή του πόρου επεξεργάζεται το όνομά του ώστε να επιτρέψει στην εφαρμογή να πλοηγηθεί στην κατάλληλη σελίδα. 67 Σ ε λ ί δ α

Μεθοδολογία Η πιο σημαντική λειτουργία, όμως, που επιτελεί το συστατικό αυτό είναι η δυναμική δημιουργία του πίνακα των μονοπατιών της εφαρμογής του πελάτη. Ο κώδικας της συνάρτησης αυτής με την εξήγησή του φαίνονται παρακάτω. Συνάρτηση initializeroutes Πίνακας 15 Συνάρτηση initializeroutes Η συνάρτηση αυτή χρησιμοποιεί τα μοντέλα Path που έχουν διαβαστεί από τον parser και με την κατάλληλη επεξεργασία τα εισάγει στον πίνακα με τις διαδρομές και τον αρχικοποιεί εκ νέου. 4.6.3 MainComponent MainView Η όψη αυτού του συστατικού έχει προεπιλεγεί να εμφανίζεται σαν αρχική σελίδα της εφαρμογής πελάτη. Μέσα από αυτή ο χρήστης έχει τη δυνατότητα να επιλέξει έναν από τους διαθέσιμους κύριους πόρους του API και να μεταβεί στη σελίδα που φαίνεται η συλλογή αυτών. Για τα ονόματα των πόρων που εμφανίζονται, χρησιμοποιείται ο πίνακας των Models που δίνει σαν έξοδο το parser. 68 Σ ε λ ί δ α

Μεθοδολογία Το συστατικό είναι υπεύθυνο για να εμφανίζει το όνομα του API και να επιτρέπει την πλοήγηση ανάλογα με την επιλογή του χρήστη. 4.6.4 ResourceComponent ResourceComponentView Το συστατικό αυτό και η αντίστοιχη όψη είναι υπεύθυνοι για την εμφάνιση της συλλογής των πόρων και αργότερα των υποπόρων. Μαζί με το όνομα των πόρων εμφανίζει και την εικόνα αν αυτοί έχουν τέτοια ιδιότητα. Η όψη διαθέτει μια μπάρα η οποία πραγματοποιεί αναζήτηση μέσα στη συλλογή των πόρων για την εύρεση αυτών που το όνομά τους περιέχει τα γράμματα που έχουν πληκτρολογηθεί από το χρήστη. Όσον αφορά τη λειτουργικότητα αυτού του συστατικού αυτού, συνοψίζεται στον παρακάτω πίνακα: Πίνακας 16 Συναρτήσεις του Resource Component και περιγραφή αυτών Συνάρτηση getresourcename ViewController.selectedFunction ViewController.getParameterArray defaultservice[functionname](...params) onclickdetail onclicknavigate Περιγραφή Χρησιμοποιεί το τρέχον URL και τον πίνακα των Models και βρίσκει έτσι το όνομα του τρέχοντος πόρου Βρίσκεται το όνομα της συνάρτησης που θα χρησιμοποιήσουμε για την HTTP κλήση στη διαδικτυακή μας υπηρεσία Σχηματίζεται ο πίνακας με τις παραμέτρους που χρειάζεται η συνάρτηση για να εκτελεστεί HTTP κλήση μέσω της υπηρεσίας που παρήγαγε το Swagger Code Generator. Εδώ επιστρέφει συλλογή πόρων Αφού θέσει τιμή στον τρέχοντα πόρο και το δώσει το URL του σαν URL γονιού μεταβαίνει στην όψη λεπτομερειών πόρου Ανάλογα με το pathlist του τρέχοντος πόρου, εμφανίζονται οι διαθέσιμες επιλογές στη συρόμενη μπάρα 69 Σ ε λ ί δ α

Μεθοδολογία Δημιουργεί έναν πίνακα με τις εικόνες των getimages πόρων, αν αυτές υπάρχουν ώστε να εμφανιστούν στην τρέχουσα όψη Ας εξετάσουμε λίγο αναλυτικότερα τη μορφή της συνάρτηση defaultservice[functionname](...params) που φαίνεται αναλυτικότερα στον παρακάτω κώδικα. Συνάρτηση defaultservice[functionname](...params) Πίνακας 17 Συνάρτηση defaultservice[functionname](...params) Παρατηρούμε πως μέσω της υπηρεσίας defaultservice, η οποία έχει παραχθεί από το Swagger Code Generator καλείται η κατάλληλη συνάρτηση. Το όνομα της συνάρτησης δίνεται μέσω της μεταβλητής functionname και οι παράμετροι της συνάρτησης μέσω του πίνακα παραμέτρων params. Με τον τρόπο που δίνουμε τον πίνακα παραμέτρων σαν όρισμα δεν χρειάζεται εκ των προτέρων να γνωρίζουμε τον αριθμό και τα ονόματα των παραμέτρων κάτι που προσφέρει ευελιξία στο να μπορούμε να καλούμε αφαιρετικά όποια συνάρτηση θέλουμε με τις κατάλληλες παραμέτρους. 4.6.5 ResourceViewComponent ResourceViewComponentView Αυτό το ζεύγος component view είναι υπεύθυνο για την παρουσίαση των λεπτομερειών των πόρων και υποπόρων. Αποτελείται από ένα πίνακα που στην αριστερή του στήλη εμφανίζει τα ονόματα των παραμέτρων, ενώ στην αριστερή τις τιμές τους. Στα αριστερά του πίνακα αυτού εμφανίζεται ενσωματωμένη φωτογραφία, αν αυτή υπάρχει, ενώ στα δεξιά του εμφανίζονται, αν πατηθούν τα αντίστοιχα κουμπιά, ένας ενσωματωμένος χάρτης με την τοποθεσία και ένα ενσωματωμένο βίντεο. 70 Σ ε λ ί δ α

Μεθοδολογία Αντίστοιχα με τα το προηγούμενο συστατικό όψη, θα σχηματίσουμε και εδώ έναν βοηθητικό πίνακα που να επεξηγεί τις επιμέρους συναρτήσεις, ώστε αυτές να γίνουν κατανοητές από τον αναγνώστη. Πίνακας 18 Συναρτήσεις ResourceView Component και περιγραφή αυτών Συνάρτηση getresourcename ViewController.selectedFunction ViewController.getParameterArray defaultservice[functionname](...params) checkembedded displaymodelconstructor shownotification onclicknavigate onclickdelete Περιγραφή Χρησιμοποιεί το τρέχον URL και τον πίνακα των Models και βρίσκει έτσι το όνομα του τρέχοντος πόρου Βρίσκεται το όνομα της συνάρτησης που θα χρησιμοποιήσουμε για την HTTP κλήση στη διαδικτυακή μας υπηρεσία Σχηματίζεται ο πίνακας με τις παραμέτρους που χρειάζεται η συνάρτηση για να εκτελεστεί HTTP κλήση μέσω της υπηρεσίας που παρήγαγε το Swagger Code Generator. Εδώ επιστρέφει έναν πόρο Ελέγχει για αντικείμενα που πρέπει να ενσωματωθούν (χάρτης, βίντεο) και εξυγιαίνει το URL τους ώστε να μπορούν να εμφανιστούν στην όψη Σχηματίζει ένα αντικείμενο με ιδιότητες τα ονόματα των ιδιοτήτων του πόρου για να εμφανίζονται στην όψη Εμφανίζει ειδοποίηση σε περίπτωση διαγραφής Ανάλογα με την ενέργεια που θα επιλέξει ο χρήστης από την αναδυόμενη μπάρα, σχηματίζει το μονοπάτι μετάβασης και εκτελεί την μετάβαση ή ενέργεια Διαγράφει τον τρέχοντα πόρο εφόσον ο χρήστης το επιλέξει. Σε περίπτωση επιτυχίας ή αποτυχίας εμφανίζεται το αντίστοιχο μήνυμα 71 Σ ε λ ί δ α

Μεθοδολογία Συνάρτηση displaymodelconstructor Πίνακας 19 Συνάρτηση displaymodelconstructor Η συνάρτηση αυτή βρίσκει το μοντέλο με όνομα αυτό του τρέχοντος πόρου και σχηματίζει ένα νέο αντικείμενο που θα έχει σαν παραμέτρους τα ονόματα των ιδιοτήτων του συγκεκριμένου μοντέλου. Με αυτόν τον τρόπο, μπορούμε να εμφανίσουμε στην οθόνη τα ονόματα των ιδιοτήτων του πόρου ακόμη και αν οι τιμές τους δεν έχουν οριστεί. Χρησιμοποιούμε δηλαδή το Model για τα ονόματα των ιδιοτήτων και τον πόρο που επιστρέφει η διαδικτυακή υπηρεσία για τις τιμές τους. 4.6.6 ResourceEditComponent ResourceEditComponentView Με αυτή την όψη και το component που την ελέγχει, υλοποιούντα δύο λειτουργίες ανάλογα με τις επιλογές του χρήστη και τη διαδρομή που αυτός έχει ακολουθήσει. Οι λειτουργίες αυτές είναι: η δημιουργία καινούριου πόρου ή η ενημέρωση του επιλεγμένου πόρου. Η όψη αποτελείται από μια σειρά ετικετών με χώρο για εισαγωγή τιμής στην κάθε ιδιότητα (στην περίπτωση της δημιουργίας) και εμφάνιση των τιμών για επεξεργασία (στην περίπτωση της ενημέρωσης). Σε περίπτωση επιτυχίας της απόπειρας ή και αποτυχίας εμφανίζεται αντίστοιχο μήνυμα. 72 Σ ε λ ί δ α

Μεθοδολογία Πίνακας 20 Συναρτήσεις του ResourceEdit Component και περιγραφή αυτών Συνάρτηση getresourcename ViewController.selectedFunction viewcontroller.getchildrennames ViewController.getParameterArray defaultservice[functionname](...params) actiondesision whichparams shownotification onclickupdate Περιγραφή Χρησιμοποιεί το τρέχον URL και τον πίνακα των Models και βρίσκει έτσι το όνομα του τρέχοντος πόρου Βρίσκεται το όνομα της συνάρτησης που θα χρησιμοποιήσουμε για την HTTP κλήση στη διαδικτυακή μας υπηρεσία Επιστρέφει τα paths των παιδιών του επιλεγμένου πόρου Σχηματίζεται ο πίνακας με τις παραμέτρους που χρειάζεται η συνάρτηση για να εκτελεστεί HTTP κλήση μέσω της υπηρεσίας που παρήγαγε το Swagger Code Generator ανάλογα με το όνομα functionname Επιλογή ενέργειας. Δημιουργία (Create) ή Ενημέρωση (Update) Σχηματίζει ένα αντικείμενο με ιδιότητες τα ονόματα των ιδιοτήτων του πόρου για να εμφανίζονται στην όψη Εμφανίζει ειδοποίηση σε περίπτωση διαγραφής Ανάλογα με την ενέργεια που θα επιλέξει ο χρήστης (Δημιουργία ή Ενημέρωση), εκτελείται το αντίστοιχο http αίτημα 4.6.7 ViewController Η υπηρεσία αυτή είναι υπεύθυνη για λειτουργικότητα και δεδομένα που πρέπει να μοιράζονται τα επιμέρους components. Εισάγεται μέσω dependency injection (DI) σε όλα τα παραπάνω components και τα τροφοδοτεί με την απαραίτητη λειτουργικότητα ή δεδομένα που μπορεί να χρειάζονται και που να παράχθηκαν από κάποιο άλλο component. Είναι πολύ σημαντικός παράγοντας στην υλοποίηση της αφαίρεσης και στη γενίκευση που προσπαθούμε να επιτύχουμε στην παρούσα διπλωματική. 73 Σ ε λ ί δ α

Μεθοδολογία Αρχικά η υπηρεσία αυτή έχει πολλές συναρτήσεις ανάθεσης και επιστροφής τιμής (setters getters) για να ανατίθενται τιμές στις εσωτερικές μεταβλητές της και έπειτα να επιστρέφονται στο component το οποίο τις απαιτεί. Λόγω του προφανούς της λειτουργίας τους, αλλά και των περιγραφικών ονομάτων που διαθέτουν δεν κρίνεται σκόπιμο να αναλυθούν περισσότερο στο παρόν σημείο. Οι υπόλοιπες συναρτήσεις περιγράφονται συνοπτικά στον παρακάτω πίνακα και έπειτα αναλύονται κάποιες των οποίων η λειτουργικότητα θεωρείται ιδιαίτερα σημαντική για την επιτυχία γενικών γραφικών διεπαφών και λειτουργικότητας χρήστη. Πίνακας 21Συναρτήσεις του ViewController και περιγραφή αυτών Συνάρτηση goback UrlParse getparameterarray getfunctionname Περιγραφή Υλοποιεί την κίνηση προς τα πίσω για όλα τα components, εκτός του ResourceEditComponent Σχηματίζει έναν πίνακα από το URL που δέχεται σαν όρισμα και επιστρέφει έναν πίνακα από string που περιέχει τα συστατικά του προηγούμενου πίνακα, αρχίζοντας καθένα με κεφαλαίο γράμμα Ανάλογα με το τρέχον URL και την επιλεγμένη συνάρτηση, αναθέτονται τιμές στις παραμέτρους Ανάλογα με το Model, το τρέχον URL και το HTTP ρήμα, επιστρέφεται η κατάλληλη συνάρτηση 74 Σ ε λ ί δ α

Μεθοδολογία Συνάρτηση getparameterarray Πίνακας 22 Συνάρτηση getparameterarray Η συνάρτηση αυτή χρησιμοποιεί την UrlParse για να πάρει το όνομα του μονοπατιού της συνάρτησης σε πίνακα. Έπειτα ελέγχεται το URL και όταν το όνομα της παραμέτρου είναι ίδιο με αυτό του πίνακα URL, τότε σχηματίζεται ο πίνακας των παραμέτρων με επεξεργασία του τρέχοντος URL. 75 Σ ε λ ί δ α

Μεθοδολογία Συνάρτηση getfunctionname Πίνακας 23 Συνάρτηση getfunctionname Μέσω της συνάρτησης αυτής βρίσκεται η επιλεγμένη συνάρτηση, αλλά δίνονται και τιμές στους πίνακες με τα παιδιά-μονοπάτια του πόρου (childname), αλλά και την τρέχουσα λίστα με τα μονοπάτια (pathlist). Αρχικά, για όλα τα ονόματα των μονοπατιών στην pathlist του Model σχηματίζεται ο αντίστοιχος πίνακας μετά την αφαίρεση του χαρακτήρα «/». Το μέγεθος κάθε πίνακα από αυτούς, συγκρίνεται με το μέγεθος του πίνακα του τρέχοντος URL. Αν τα μεγέθη είναι ίσα, τότε περνάμε τον πίνακα method κάθε στοιχείου της pathlist από ένα φίλτρο ώστε να μείνει μόνο το στοιχείο που έχει σαν όνομα το ίδιο με το httpverb. Η συνάρτηση που αντιστοιχεί στο ρήμα αυτό είναι και η ζητούμενη. 4.7 Υπηρεσίες που έχουν παραχθεί από το Swagger Code Generator Στην παρούσα υλοποίηση, χρησιμοποιείται μία μόνο υπηρεσία με όνομα defaultservice. Η υπηρεσία αυτή περιέχει όλες τις επιτρεπτές συναρτήσεις που εκτελούν HTTP κλήσεις στο API. Τα ονόματα των συναρτήσεων, καθώς και η περίπτωση να έχουμε περισσότερες από μία υπηρεσίες λόγω των ετικετών 76 Σ ε λ ί δ α

Μεθοδολογία που έχουν προσαρτηθεί στο αρχείο αναφορών έχουν αναλυθεί εκτενώς στην ενότητα Swagger Code Generator. 4.8 Αρχικοποίηση εφαρμογής Στο κεφάλαιο αυτό θα παρουσιαστούν με σαφήνεια τα βήματα που απαιτούνται για την λειτουργία της εφαρμογής, για να βοηθήσει τους χρήστες που δεν έχουν καμία προηγούμενη εμπειρία στη χρήσης αυτής. Αρχικά επιλέγεται ο server, ο οποίος θα φιλοξενήσει το υλοποιημένο API μας. Στη συγκεκριμένη περίπτωση χρησιμοποιήθηκε ο Apache Tomcat 9 [48]. Καταθέτουμε το.war αρχείο στο server, είτε μεταφέροντάς το στο φάκελο webapps του server, είτε μέσω φυλλομετρητή στη διεύθυνση localhost:8085. Στη δεύτερη περίπτωση, επιλέγουμε deploy war file to server αφότου έχουμε επιλέξει Manager Apps. Με αυτό τον τρόπο πραγματοποιείται αποσυμπίεση του αρχείου και αυτόματη εκτέλεση. Μιας και το API είναι πια σε λειτουργία, το επόμενο βήμα είναι να εκτελεστούν οι ενέργειες που περιγράφηκαν παραπάνω, ώστε η εφαρμογή να προσαρμόζεται στις ανάγκες του κάθε API. Πιο συγκεκριμένα, η σειρά των ενεργειών που πρέπει να εκτελεσθούν είναι: Σύνταξη του YAML αρχείου που περιγράφει την οντολογία του API Εξαγωγή/μετατροπή του YAML αρχείου σε JSON και τοποθέτηση αυτού στο φάκελο json της εφαρμογής Αλλαγή του ονόματος της μεταβλητής JsonPath της υπηρεσίας JsonProcessingService που βρίσκεται στο φάκελο services ώστε να φέρει το όνομα του επιθυμητού JSON αρχείου Παραγωγή των βιβλιοθηκών πελάτη με το Swagger Code Generator σε γλώσσα Angular2 με Typescript. Τοποθέτηση των περιεχομένων του παραγόμενου φακέλου στο φάκελο swagger της εφαρμογής Μετάβαση μέσω τερματικού (terminal) στο φάκελο της εφαρμογής και εκτέλεση των εντολών npm install, για εγκατάσταση των προϋποθέσεων (dependencies) για να τρέξει η εφαρμογή και npm start ώστε να τρέξει η εφαρμογή. Η εφαρμογή πελάτη είναι διαθέσιμη στη διέυθυνση localhost:3000 77 Σ ε λ ί δ α

Μεθοδολογία Τροποποίηση του web.xml αρχείου του API που βρίσκεται στο φάκελο webapps του tomcat, ώστε να επιτρέπεται το CORS (Cross Origin Resource Sharing), ώστε το API να δέχεται κλήσεις από το localhost:3000. Η διαδικασία αυτή διαφέρει από server σε server 9. Στο σημείο αυτό, η εφαρμογή έχει οριστεί πλήρως, και είναι έτοιμη να τεθεί σε λειτουργία και να παρέχει μια πλήρως λειτουργική διεπαφή χρήστη για το API που περιγράφεται από τα αρχεία προδιαγραφών. Για εποπτεία του της αρχιτεκτονικής της εφαρμογής πελάτη, μπορεί κανείς να ανατρέξει στο ακόλουθο σχήμα της επόμενης σελίδας. 9 Για τον tomcat συγκεκριμένα μπορεί κανείς να ανατρέξει στον ακόλουθο σύνδεσμο https://tomcat.apache.org/tomcat-9.0-doc/config/filter.html#cors_filter 78 Σ ε λ ί δ α

Εφαρμογή πελάτη Μεθοδολογία main.component.ts nav.component.ts /components resource.component.ts /css rsource-edit.component.ts /json rsource-view.component.ts /models jsonprocessing.service.ts /services index.html ViewController.ts src /swagger app app.component.html main.component.html nav.component.html /views resource.component.html app.component.ts app.module.ts app-routing.module.ts rsourceedit.component.html rsourceview.component.html Εικόνα 28 Επισκόπηση αρχιτεκτονικής πελάτη 79 Σ ε λ ί δ α

Πειράματα-Αποτελέσματα 5. Πειράματα-Αποτελέσματα Αφού παρουσιάστηκε λεπτομερώς η μεθοδολογία που ακολουθήθηκε για την ανάπτυξη των αυτόματων διεπαφών πελάτη, στο παρόν κεφάλαιο θα αναλυθεί λεπτομερώς η λειτουργικότητά του χρησιμοποιώντας τις κατάλληλες εικόνες για την προβολή των όψεων. Κατ αρχάς, για τον έλεγχο λειτουργείας της εφαρμογής δοκιμάστηκαν διάφορα APIs που έχουν αναπτυχθεί από το S-CASE, όπως το RestMarks, RestReviews καθώς και μία εφαρμογή πιο σύνθετη από αυτές. Η εφαρμογή αυτή ονομάζεται RESTEventManager και θα χρησιμοποιηθεί για την παρουσίαση των λειτουργιών των διεπαφών πελάτη. Το RESTEventManager πρόκειται για μια εφαρμογή που αποτελείται από μία βάση χρηστών και μια βάση εκδηλώσεων. Η εφαρμογή δίνει τη δυνατότητα στο χρήστη να περιηγηθεί ανάμεσα στις διαφορετικές εκδηλώσεις και να δει τα πιθανά εισιτήρια, τοποθεσίες και τους υπεύθυνους για να φέρους εις πέρας την εκδήλωση. Αναλυτικά η οντολογία του RESTEventManager φαίνεται στο παρακάτω σχήμα. User Event Organizer Ticket Performer Venue Εικόνα 29 Οντολογία της RESTEventManage 80 Σ ε λ ί δ α

Πειράματα-Αποτελέσματα 5.1 Κύρια οθόνη διεπαφής Η κύρια οθόνη είναι η πρώτη οθόνη που αντικρίζει ο χρήστης κατά την είσοδό του στην εφαρμογή και αυτή που φέρει και το όνομα του API. Αποτελείται από όλους τους πιθανούς πόρους, στους οποίους μπορεί να μεταβεί ο χρήστης, καθώς και από μια μπάρα πλοήγησης που επιτρέπει στο χρήστη να μεταβεί ξανά στην αρχική σελίδα πατώντας το κουμπί Home. Πάνω στην ίδια μπάρα υπάρχει ένα κουμπί το οποίο εμφανίζει ένα αναπτυσσόμενο παράθυρο που περιέχει μια λίστα με όλους τους κύριους πόρους, επιτρέποντας την καλύτερη διαχείριση της πλοήγησης. Στις δύο εικόνες που ακολουθούν παρουσιάζεται ολόκληρη η αρχική οθόνη και το αναπτυσσόμενο παράθυρο (dropdown box). Εικόνα 30 Αρχική σελίδα Εικόνα 31 Home και αναπτυσσόμενο παράθυρο 5.2 Οθόνη προβολής συλλογής πόρων Στην οθόνη αυτή μπορεί κανείς να φτάσει αφού επιλέξει κάποιον από τους πόρους της αρχικής σελίδας ή μέσω του αναπτυσσόμενου παραθύρου της μπάρας πλοήγησης. Φέρει σαν τίτλο το όνομα του πόρου 81 Σ ε λ ί δ α

Πειράματα-Αποτελέσματα στον πληθυντικό αριθμό, μια μπάρα που χρησιμεύει για την αναζήτηση μέσα στη συλλογή των πόρων και όλα τα διαθέσιμα αντικείμενα. Αν τα αντικείμενα αυτά διαθέτουν εικόνα σαν ιδιότητα, τότε αυτή παρουσιάζεται και σε αυτή τη σελίδα πριν το όνομά τους. Εικόνα 32 Οθόνη κύριου πόρου Μέσω του πορτοκαλί κουμπιού View Details μπορεί κανείς να μεταβεί στην οθόνη που παρουσιάζει τις ιδιότητες του εκάστοτε πόρου λεπτομερώς, ενώ μέσα από τη χρήση του κουμπιού Back ο χρήστης επιστρέφει στη σελίδα από την οποία πραγματοποίησε μετάβαση στην τρέχουσα. Ιδιαίτερη προσοχή αξίζει να δώσει κανείς στη λειτουργία του πράσινου κουμπιού Options που βρίσκεται στην κάτω δεξιά πλευρά της σελίδας. 82 Σ ε λ ί δ α

Πειράματα-Αποτελέσματα Εικόνα 33 Επιλογές στην οθόνη βασικού πόρου Πάνω σε αυτή την αναδυόμενη από τα αριστερά μπάρα, εμφανίζεται μία λίστα δυνατών ενεργειών ανάλογα με τον πόρο στον οποίο βρίσκεται ο χρήστης κάθε φορά και το αντίστοιχο URL. Όπως είναι σαφές χρησιμοποιείται χρωματικός κώδικας για την ευκολότερη διάκριση των ενεργειών. Στη συγκεκριμένη περίπτωση ο χρήστης μπορεί να δημιουργήσει μια καινούρια εκδήλωση (πράσινο) ή να επιστρέψει στη σελίδα στην οποία είναι ορατά όλα τα στιγμιότυπα του πόρου (μπλε). 5.3 Οθόνη δημιουργίας νέου πόρου Μέσω της αναδυόμενης μπάρας, ο χρήστης έχει επιλέξει τη δημιουργία νέου πόρου, οπότε και μεταβαίνει στην παρακάτω οθόνη. Μέσω τις οθόνης αυτής ο χρήστης πληκτρολογεί τα επιθυμητά στοιχεία και μέσω του πράσινου κουμπιού Create αποστέλλει την αίτηση του για αποθήκευση ενός νέου αντικειμένου στο API, και μέσω αυτού τελικά στη βάση δεδομένων. Αν ο χρήστης μετανιώσει για την 83 Σ ε λ ί δ α

Πειράματα-Αποτελέσματα επιλογή του, πατώντας το κουμπί Back μεταβαίνει στην οθόνη από την οποία ήρθε. Η γραφική διεπαφή ενημερώνει το χρήστη για επιτυχία με πράσινη αναδυόμενη ειδοποίηση, ενώ σε περίπτωση αποτυχίας η ειδοποίηση αυτή είναι κόκκινη και φέρει μήνυμα σφάλματος. Εικόνα 34 Οθόνη δημιουργίας νέου πόρου 5.4 Οθόνη προβολής λεπτομερειών πόρου Στο σενάριο χρήσης που εξετάζουμε, αν ο χρήστης πιέσει το πορτοκαλί πλήκτρο View Details της οθόνης που προβάλλει τη συλλογή πόρων, τότε μεταβαίνει σε αυτή την οθόνη. Εδώ σχηματίζεται ένας πίνακας στην πρώτη στήλη του οποίου εμφανίζονται τα ονόματα των χαρακτηριστικών του εκάστοτε πόρου, ενώ στη δεύτερη οι τιμές τους. Στα αριστερά του πίνακα προβάλλεται η εικόνα, αν αυτή υπάρχει σαν ιδιότητα, ενώ στα δεξιά εμφανίζονται τα βίντεο και χάρτες, εφόσον ο χρήστης πιέσει το αντίστοιχο κουμπί μέσα στον πίνακα. 84 Σ ε λ ί δ α

Πειράματα-Αποτελέσματα Εικόνα 35 Οθόνη προβολής λεπτομερειών πόρου Όπως και στην περίπτωση της συλλογής αντικειμένων πόρου, έτσι και εδώ, με το πάτημα του Options αναδύεται η μπάρα με τις διαθέσιμες επιλογές. Στη συγκεκριμένη περίπτωση θα παρατηρήσουμε ότι με αυτό τον τρόπο μπορεί κανείς να μεταβεί ή να δημιουργήσει υποπόρους, να διαγράψει τον επιλεγμένο πόρο ή να ενημερώσει τις τιμές του. Με την ίδια λογική ακολουθείται και εδώ ένας χρωματικός κώδικας. Συμβολίζονται με μπλε η επιστροφή στις λεπτομέρειες του πόρου ή η μετάβαση στη συλλογή των υποπόρων, με πράσινο η δημιουργία καινούριου υποπόρου, με κίτρινο η ενημέρωση, ενώ με κόκκινο η διαγραφή. Μαζί με τον χρωματικό κώδικα χρησιμοποιούνται και σύμβολα που περιγράφουν την κάθε ενέργεια. 85 Σ ε λ ί δ α

Πειράματα-Αποτελέσματα Εικόνα 36 Λίστα με επιτρεπτές ενέργειες για λεπτομέρειες πόρου 5.5 Οθόνη προβολής συλλογής υποπόρων Ο χρήστης μεταβαίνει στη σελίδα αυτή μέσω της αναδυόμενης από τα αριστερά λίστας με επιλογές στην οθόνη των λεπτομερειών του πόρου. Θα παρουσιάσουμε εδώ έναν πόρο που δεν έχει εικόνα σαν ιδιότητα, τον υποπόρο για τις τοποθεσίες (venues). Η επιλογές και η λειτουργικότητα στην παρούσα φάση είναι ίδιες με αυτές που αναφέρθηκαν προηγουμένως στην οθόνη προβολής λεπτομερειών αλλά η παρουσίαση της εξυπηρετεί την ακολουθία του σεναρίου χρήσης. Εικόνα 37 Οθόνη προβολής υποπόρου venues 86 Σ ε λ ί δ α

Πειράματα-Αποτελέσματα 5.6 Οθόνη προβολής λεπτομερειών υποπόρου Η οθόνη αυτή είναι εντελώς παρόμοια με την αντίστοιχη για τον πόρο που παρουσιάστηκε παραπάνω. Ο λόγος που την αναφέρουμε ξεχωριστά είναι για να επιδείξουμε τη δυνατή ενσωμάτωση χάρτη. Εικόνα 38 Λεπτομέρειες υποπόρου με ενσωμάτωση χάρτη 87 Σ ε λ ί δ α

Πειράματα-Αποτελέσματα 5.7 Οθόνη επεξεργασίας πόρου Η οθόνη αυτή εμφανίζεται όταν ο χρήστης επιλέξει να πραγματοποιήσει κάποια ενημέρωση στον επιλεγμένο πόρο/υποπόρο. Η οθόνη αυτή είναι ίδια με την οθόνη για τη δημιουργία καινούριου πόρου, μόνο που σε αυτή την περίπτωση οι τιμές των χαρακτηριστικών υπάρχουν συμπληρωμένες μέσα στη φόρμα δίνοντας τη δυνατότητα στο χρήστη να τις τροποποιήσει επιτόπου. Επιπλέον, με το πάτημα του πράσινου κουμπιού, που στη συγκεκριμένη περίπτωση λέγεται Update, πραγματοποιείται κλήση στη διαδικτυακή υπηρεσία για τροποποίηση των δεδομένων του τρέχοντος πόρου. Η εφαρμογή πελάτη είναι υπεύθυνη για την ενημέρωση σε περίπτωση επιτυχούς τροποποίησης με πορτοκαλί αναδυόμενο μήνυμα, ή με κόκκινο σε περίπτωση αποτυχίας. Εικόνα 39 Οθόνη ενημέρωσης χαρακτηριστικών πόρου 5.8 Οθόνη διαγραφής πόρου Η δυνατότητα διαγραφής ενός πόρου δίνεται στο χρήστη μόνο από την οθόνη προβολής των λεπτομερειών χρήστη μέσω της αναδυόμενης μπάρας με τις επιλογές, πατώντας την κόκκινη επιλογή. Στην περίπτωση που ο χρήστης αιτηθεί αυτή την ενέργεια, η αναδυόμενη μπάρα βυθίζεται ξανά στα αριστερά, δίνοντας τη θέση της σε ένα άλλο αναδυόμενο παράθυρο που ζητάει επιβεβαίωση για να προχωρήσει στην αποστολή αιτήματος διαγραφής ή όχι. Ο χρήστης μπορεί να ακυρώσει την ενεργεια μέσω το κόκκινου κουμπιού No και του κουμπιού Cancel, ενώ αντίθετα η επιβεβαίωση δίνεται πιέζοντας 88 Σ ε λ ί δ α

Πειράματα-Αποτελέσματα το πράσινο κουμπί Yes. Αν τελικά ο χρήστης επιβεβαιώσει την ενέργεια μπορεί να ενημερωθεί για την πορεία του με τα γνωστά πλέον αναδυόμενα μηνύματα. (Πράσινο για επιτυχία και κόκκινο για σφάλμα). Εικόνα 40 Οθόνη με αναδυόμενο παράθυρο για τον έλεγχο της διαγραφής 89 Σ ε λ ί δ α

Συμπεράσματα και μελλοντική εργασία 6. Συμπεράσματα και μελλοντική εργασία Εν κατακλείδι, με βάση όλα αυτά που έχουν παρατεθεί και αναλυθεί στην παρούσα διπλωματική εργασία, γίνεται σαφές πως η εφαρμογή που σχεδιάστηκε καταφέρνει να καλύψει την ανάγκη ανάπτυξης ποιοτικών και πλήρως λειτουργικών εφαρμογών πελάτη για την κατανάλωση διαδικτυακών υπηρεσιών αρχιτεκτονικής REST που έχουν περιγραφεί πλήρως από ένα αρχείο προδιαγραφών τύπου OpenAPI. Αν και εξυπηρετεί το σκοπό της για τον έλεγχο των APIs, αλλά την παρουσίαση των δυνατοτήτων του, μειώνοντας σημαντικά το χρόνο και το κόστος συγγραφής κώδικα front end, εντούτοις θα μπορούσε να επεκταθεί η λειτουργικότητά της ώστε να καλύπτει περισσότερες ανάγκες. Σε αυτή την κατεύθυνση προτείνονται κάποιες τροποποιήσεις και επεκτάσεις που θα μπορούσαν να ερευνηθούν και να υλοποιηθούν στο μέλλον. Αρχικά, προτείνεται η προσθήκη υπηρεσίας ταυτοποίησης του χρήστη (Authentication), ώστε να αποτρέπεται η μη εξουσιοδοτημένη προσπέλαση και τροποποίηση τμημάτων ή και ολόκληρης της εφαρμογής. Επιπλέον, ενθαρρύνεται η περαιτέρω ανάπτυξη της λειτουργίας του parser, ώστε να σχηματίζονται με επιτυχία τα οικογενειακά δέντρα (pathlist) των βασικών σχημάτων εξυπηρετώντας περισσότερες διαδικτυακές εφαρμογές, καθιστώντας τη διαδικασία ακόμη πιο αφαιρετική. Χρήσιμη θα ήταν η ενσωμάτωση των ετικετών (tags) όπως προτάθηκε και πιο πάνω, η τροποποίηση του πελάτη ώστε να μπορεί να εκτελέσει κλήσεις με χρήση URI που περιέχουν παραμέτρους ερωτημάτων (query parameters), ώστε να καθίσταται δυνατή η απευθείας αναζήτηση μέσα στη βάση δεδομένων που είναι συνδεδεμένη με τη διαδικτυακή υπηρεσία, απλών και σύνθετων ερωτημάτων. Σαν συνέχεια της σκέψης αυτής, θα μπορούσαν να υλοποιηθούν τροποποιήσεις ώστε η δεδομένη εφαρμογή να κατορθώσει να καταναλώνει εξωτερικές διαδικτυακές υπηρεσίες. Κλείνοντας, αξιοποιώντας τη δυνατότητα που δίνει το Swagger Code Generator για παραγωγή βιβλιοθηκών πελατών σε 40 γλώσσες, προτείνεται η επέκταση ώστε να συμπεριλαμβάνονται και να ενσωματώνονται στην εφαρμογή και κάποιες ακόμη από τις διαθέσιμες γλώσσες. 90 Σ ε λ ί δ α

Βιβλιογραφία Βιβλιογραφία [1] J. A. G. a. F. K. Radatz, «IEEE standard glossary of software engineering terminology,» IEEE Std 610121990.121990, 1990. [2] S. L. a. J. M. A. Pfleeger, Software engineering: theory and practice, Pearson Education India, 1998. [3] R. S. Pressman, Software engineering: a practitioner's approach, Palgrave Macmillan, 2005. [4] W. Stallings, Επικοινωνίες υπολογιστών και δεδομένων, Εκδόσεις Τζιόλα, 2011. [5] A. S. Tanenbaum, Δίκτυα Υπολογιστών, Κλειδάριθμος, 2013. [6] S. P. a. I. R. Jim Webber, REST in Practice, 1005 Gravenstein Highway North, Sebastopol, CA 95472: O Reilly Media, Inc., 2010. [7] World Wide Web Consortium (W3C), «Naming and Addressing: URIs, URLs,...,» 27 02 2006. [Ηλεκτρονικό]. Available: https://www.w3.org/addressing/. [8] World Wide Web Consortium (W3C), «W3C,» World Wide Web Consortium (W3C), [Ηλεκτρονικό]. Available: https://www.w3.org/protocols/rfc2616/rfc2616-sec9.html. [Πρόσβαση 28 06 2017]. [9] World Wide Web Consortium (W3C), «W3C Architecture domain,» World Wide Web Consortium (W3C), 11 06 2014. [Ηλεκτρονικό]. Available: https://www.w3.org/protocols/. [Πρόσβαση 28 06 2017]. [10] World Wide Web Consortium (W3C), «W3C,» World Wide Web Consortium (W3C), [Ηλεκτρονικό]. Available: https://www.w3.org/protocols/rfc2616/rfc2616-sec10.html. [Πρόσβαση 28 06 2017]. [11] H. H. F. M. E. N. M. C. C. F. D. O. David Booth, «Web Services Architecture,» σε W3C Working Group Note 11 February 2004, 2004. [12] IBM, «IBM developerworks,» IBM, [Ηλεκτρονικό]. Available: https://www.ibm.com/developerworks/webservices/tutorials/ws-understand-web-services1/wsunderstand-web-services1.html. [Πρόσβαση 28 06 2017]. [13] Microsoft, «Microsoft Developer Network,» Microsoft. [Ηλεκτρονικό]. [Πρόσβαση 2017 04 17]. [14] Π. Φιτσιλής, Σύγχρονα πληροφοριακά συστήματα επιχειρήσεων, Αθήνα: Σύνδεσμος Ελληνικών Ακαδημαϊκών Βιβλιοθηκών, 2015. [15] Qusay H. Mahmoud - Oracle, «Oracle,» Oracle, 2005. [Ηλεκτρονικό]. Available: http://www.oracle.com/technetwork/articles/javase/soa-142870.html. [Πρόσβαση 02 05 2017]. 91 Σ ε λ ί δ α

Βιβλιογραφία [16] D. S. D. a. A. S. Benslimane, «Services mashups: The new generation of web applications.,» IEEE Internet Computing 12.5, 2008. [17] R. T. Fielding, Architectural styles and the design of network-based software architectures. Diss., Irvine: University of California, 2000. [18] V. Bojinov, RESTful Web API Design with Node. js, Packt Publishing Ltd, 2015.. [19] L. a. S. R. Richardson, RESTful web services, O'Reilly Media, Inc., 2008. [20] E. Wilde, Putting Things to REST, Berkeley,: UC Berkeley School of Information, 2007. [21] M. Fowler, «Richardson Maturity Model,» [Ηλεκτρονικό]. Available: http://martinfowler.com/articles/richardsonmaturitymodel.html. [Πρόσβαση 18 02 2017]. [22] Smart Bear, «SMARTBEAR,» Smart Bear, 25 03 2015. [Ηλεκτρονικό]. Available: https://smartbear.com/news/news-releases/sponsorship-of-swagger/. [Πρόσβαση 28 02 2017]. [23] O. Initiative, «OpenAPI,» OpenApi Initiative, [Ηλεκτρονικό]. Available: https://www.openapis.org/participate/how-to-contribute/governance. [Πρόσβαση 04 03 2017]. [24] T. Tam, «Swagger,» Swagger, 05 11 2015. [Ηλεκτρονικό]. Available: http://swagger.io/introducingthe-open-api-initiative/. [Πρόσβαση 02 03 2017]. [25] OpenAPI, «OAI/OpenAPI-Specification,» OpenApi Initiative, [Ηλεκτρονικό]. Available: https://github.com/oai/openapi-specification. [Πρόσβαση 03 03 2017]. [26] Swagger, «Swagger Specification,» Swagger, [Ηλεκτρονικό]. Available: http://swagger.io/specification/. [Πρόσβαση 04 03 2017]. [27] Swagger, «Swagger,» Swagger, [Ηλεκτρονικό]. Available: http://swagger.io/. [Πρόσβαση 19 02 2017]. [28] Swagger, «Swagger Editor,» Swagger, [Ηλεκτρονικό]. Available: http://swagger.io/swagger-editor/. [Πρόσβαση 20 02 2017]. [29] Swagger, «Swagger CodeGen,» SwGGER, [Ηλεκτρονικό]. Available: http://swagger.io/swaggercodegen/. [Πρόσβαση 20 02 2017]. [30] Swagger, «Swagger-UI,» Swagger, [Ηλεκτρονικό]. Available: http://swagger.io/swagger-ui/. [Πρόσβαση 25 02 2017]. [31] Swagger, «Swagger Hub,» Swagger, [Ηλεκτρονικό]. Available: https://swaggerhub.com/swaggeropen-source-comparison/?sr=cta&md=hp. [Πρόσβαση 28 02 2017]. [32] Microsoft, «Microsoft Developer Network,» Microsoft, [Ηλεκτρονικό]. Available: https://msdn.microsoft.com/en-us/library/ff649643.aspx. [Πρόσβαση 09 05 2017]. 92 Σ ε λ ί δ α

Βιβλιογραφία [33] S-CASE, «S-CASE,» [Ηλεκτρονικό]. Available: http://www.scasefp7.eu/deliverables/. [Πρόσβαση 04 04 2017]. [34] Bootstrap, «Bootstrap,» Bootstrap, [Ηλεκτρονικό]. Available: http://getbootstrap.com/. [Πρόσβαση 18 06 2017]. [35] JSON, «Introducing JSON,» [Ηλεκτρονικό]. Available: http://www.json.org/. [Πρόσβαση 23 06 2017]. [36] «YAML,» [Ηλεκτρονικό]. Available: http://yaml.org/. [Πρόσβαση 23 06 2017]. [37] Angular, «Angular - One framework Mobile & desktop,» [Ηλεκτρονικό]. Available: https://angular.io/. [Πρόσβαση 22 04 2017]. [38] TypeScript, «TypeScript Documentation,» [Ηλεκτρονικό]. Available: https://www.typescriptlang.org/docs/index.html. [Πρόσβαση 22 04 2017]. [39] node, «nodejs/node-v8,» [Ηλεκτρονικό]. Available: https://github.com/nodejs/node-v8. [Πρόσβαση 13 05 2017]. [40] npm, «npm - What is npm?,» [Ηλεκτρονικό]. Available: https://docs.npmjs.com/gettingstarted/what-is-npm. [Πρόσβαση 03 05 2017]. [41] strandls, «strandls/alchemy-rest-client-generator,» [Ηλεκτρονικό]. Available: https://github.com/strandls/alchemy-rest-client-generator. [Πρόσβαση 25 06 2017]. [42] FIWARE, «FIWARE Catalogue,» FIWARE, [Ηλεκτρονικό]. Available: https://catalogue.fiware.org/enablers/rest-client-generator/documentation. [Πρόσβαση 21 06 2017]. [43] Restlet, «Studio - Design & Document your REST APIs,» [Ηλεκτρονικό]. Available: https://restlet.com/modules/studio/. [Πρόσβαση 24 06 2017]. [44] Azure, «Azure/autorest,» [Ηλεκτρονικό]. Available: https://github.com/azure/autorest. [Πρόσβαση 18 06 2017]. [45] POSTMAN, «POSTMAN,» POSTMAN, [Ηλεκτρονικό]. Available: https://www.getpostman.com/. [46] ngadmin, «ngadmin,» [Ηλεκτρονικό]. Available: https://ng-admin-book.marmelab.com/. [47] LightAdmin, «LightAdmin,» [Ηλεκτρονικό]. Available: http://lightadmin.org/. [48] A. T. 9, «Apache Tomcat 9,» Apache Tomcat 9, 21 06 2017. [Ηλεκτρονικό]. Available: http://tomcat.apache.org/tomcat-9.0-doc/. [Πρόσβαση 25 06 2017]. 93 Σ ε λ ί δ α

ΠΑΡΑΡΤΗΜΑ ΠΑΡΑΡΤΗΜΑ Στο παράρτημα παραθέτουμε ένα ενδεικτικό παράδειγμα ενός YAML αρχείου που δημιουργήθηκε με το πρότυπο OpenAPI, ώστε να γίνει πιο κατανοητός ο τρόπος γραφής και οι περιορισμού που έχουν περιγραφεί. RestReviews 94 Σ ε λ ί δ α

ΠΑΡΑΡΤΗΜΑ 95 Σ ε λ ί δ α

ΠΑΡΑΡΤΗΜΑ 96 Σ ε λ ί δ α