Σχεδίαση και υλοποίηση εργαλείου αυτόματης ανάπτυξης προσαρμόσιμων διεπαφών χρήστη για RESTful web APIs

Transcript

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

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

3 Περίληψη Περίληψη Την τελευταία δεκαετία, η τάση για ανάπτυξη διαδικτυακών εφαρμογών παρουσιάζει ραγδαία ανάπτυξη κα καλύπτει ολοένα και περισσότερες ανάγκες λογισμικού. Σημαντικό ρόλο στην ανάπτυξη των εν λόγω εφαρμογών παίζουν οι διαδικτυακές υπηρεσίες, που εξυπηρετούν την επικοινωνία μεταξύ των υπολογιστών και την ανταλλαγή δεδομένων μέσω του πρωτοκόλλου HTTP. Την επικρατέστερη επιλογή σήμερα για τις διαδικτυακές υπηρεσίες αποτελούν τα RESTful web APIs, δηλαδή οι διαδικτυακές διεπαφές προγραμματισμού εφαρμογών που υπακούν στην αρχιτεκτονική σχεδιασμού Representational state transfer (REST). Η REST αρχιτεκτονική επικράτησε, μεταξύ άλλων, λόγω της απλότητας και της δυνατότητας εύκολης επεξεργασίας και επέκτασης των εφαρμογών που βασίζονται σε αυτήν. Την ολοένα αυξανόμενη ζήτηση και χρήση REST APIs συνοδεύει και η τάση στην εξέλιξη των τεχνικών και εργαλείων δημιουργίας τους, καθώς και αυτών για την κατανάλωσή τους. Τα εργαλεία αυτά επικεντρώνονται στην ελαχιστοποίηση του χρόνου και του κόστους που απαιτείται για την ανάπτυξη μιας εφαρμογής ιστού και της υλοποίησης μιας ολοκληρωμένης διεπαφής που θα εξυπηρετεί αποτελεσματικά την λειτουργία της εφαρμογής από το χρήστη. Όπως κάθε προϊόν λογισμικού, έτσι και ένα REST API, για να είναι επιτυχημένο θα πρέπει να χαρακτηρίζεται από μία εύλογη ευχρηστία με την οποία ο άνθρωπος θα μπορεί να χρησιμοποιεί τις λειτουργίες και τα χαρακτηριστικά του προϊόντος, αποτελεσματικά. Η παρούσα διπλωματική εργασία πραγματεύεται την υλοποίηση ενός εργαλείου ανάπτυξης γραφικών διεπαφών χρήστη πλήρως προσαρμόσιμου στην δομή ενός δοσμένου API. Ουσιαστικά πρόκειται για μία ολοκληρωμένη διεπαφή χρήστη που η χρήση της δεν απαιτεί κάποια γνώση για υλοποίηση front-end client, ενώ παράλληλα παρέχει στον προγραμματιστή τη δυνατότητα τροποποίησης που επιθυμεί, αλλαγή του περιεχομένου ή της συμπεριφοράς της εφαρμογής. Το εργαλείο αυτό σχεδιάστηκε ώστε να είναι συμβατό με το S-CASE ( μια πλατφόρμα λογισμικού η οποία εμπεριέχει, μεταξύ άλλων, μια μηχανή παραγωγής κώδικα που υλοποιεί την παραγωγή RESTful Web APIs σε Java πλατφόρμα. Ο μηχανισμός που αναπτύχθηκε είναι υλοποιημένος στο JavaScript framework Angular Js. Μπορεί να χρησιμοποιηθεί για τον έλεγχο λειτουργίας ενός REST API, σαν ολοκληρωμένη ιστοσελίδα ή σαν μια πρότυπη έκδοση εφαρμογής για παρουσίαση της λειτουργικότητας του API σε κάποιον ενδιαφερόμενο

4 Abstract Abstract INTERACT - An Intelligent RESTful Adaptive Client Tool Design and development of a tool that generates adaptive user interfaces for RESTful web APIS In the last decade, web application development has gained increased popularity. Web services support computer interaction and data exchange via HTTP, and play an important role in the development of this applications. The predominant choice for web services are RESTful web APIs. These are application programming interfaces that follow the Representational state transfer (REST) architectural style. REST architecture became popular because of its simplicity and ease of processing and expansion of the application based on it. The increasing demand and use of REST APIs is followed by the trend for developing new tools and techniques for their generation and consumption. These tools focus on minimization of the time and cost that is required for the development of a web application and/or the implementation of interfaces that effectively serve the functionality of the application. In order to be consider successful, REST APIs - like any other software product - have to be characterized by a reasonable ease of use that allows people to handle the functionality of the application effectively. Based on the above, current thesis deals with the design and development of Interact, a graphical user interface tool that is fully adaptable to the structure of a given REST API. Practically it produces a complete user interface that does not require any knowledge about front-end development. Interact is compatible with S-CASE ( a software platform that includes, among other things, an automated code generation engine (employing MDA primitives) that generates RESTful Web APIs. Interact is developed in Angular JS. It can be used for testing a REST API, as a website or as a prototype presentation of the API s operations. Angelis Sotiris sotiris-a@hotmail.com Electrical & Computer Engineering Department Aristotle University of Thessaloniki, Greece October

5 Περιεχόμενα Περιεχόμενα Ευχαριστίες Περίληψη Abstract Περιεχόμενα Λίστα Εικόνων Λίστα Πινάκων Εισαγωγή Σκοπός Διπλωματικής Εργασίας Οργάνωση Κεφαλαίων Θεωρητικό και τεχνολογικό υπόβαθρο Τεχνολογία λογισμικού Διαδικασία ανάπτυξης και κύκλος ζωής λογισμικού Διεπαφή Χρήστη Παγκόσμιος Ιστός HTML HTTP URIs Resources ή Πόροι Διαδικτυακή Υπηρεσία Web Service και Service Web APIs και Restful Αρχιτεκτονική Richardson s Maturity Model (RMM) Τάση στην ανάπτυξη των Web APIs Επισκόπηση MDE Η πλατφόρμα S-CASE Clients και σύγχρονες τεχνολογίες κατανάλωσης Web API Διαφορά προτεινόμενης εφαρμογής από τις υπάρχουσες τεχνολογίες Επισκόπηση Εφαρμογής MVC S-CASE Angular JS Bootstrap

6 Περιεχόμενα 3.5. Yaml Δομή εφαρμογής Ανάλυση και επεξεργασία εισόδων στην εφαρμογή YamlParse service Έλεγχοι εισόδων Λειτουργεία ελεγκτών Αρχικοποίηση εφαρμογής Σενάριο χρήσης εφαρμογής και ανάλυση όψεων Κύρια οθόνη διεπαφής Οθόνη σύνδεσης Περισσότερες επιλογές στην αρχική οθόνη Δημιουργία νέου πόρου Οθόνη προβολής λεπτομερειών πόρου Λίστα επιλογών στην οθόνη προβολής Οθόνη προβολής ομάδας πόρων Οθόνη προβολής λεπτομερειών παιδιού Οθόνη επεξερασίας πόρου Διαγραφή Πόρου Παρουσίαση Ενναλακτικών Όψεων Εναλλακτική κύρια οθόνη Εναλλακτική οθόνη προβολής λεπτομερειών Μελλοντικές Επεκτάσεις ΒΙΒΛΙΟΓΡΑΦΙΑ ΠΑΡΑΡΤΗΜΑ Developer s manual Ανάλυση Δομικών στοιχείων της εφαρμογή Τροποποίηση όψεων για συγκεκριμένους πόρους Επιλογή προτύπου όψης

7 Λίστα Εικόνων Λίστα Εικόνων Εικόνα 1 Ο κύκλος ανάπτυξης λογισμικού Εικόνα 2 Ο ιστός Εικόνα 3 Richardson's Maturity Model Εικόνα 4 Αναπαράσταση της αύξησης του αριθμού των Web APIs Εικόνα 5 Επισκόπηση της αρχιτεκτονικής του συστήματος αυτόματης παραγωγής κώδικα του S-CASE Εικόνα 6 Model-View-Controller Εικόνα 7 Δομή Εφαρμογής Εικόνα 8 Προετοιμασία εφαρμογής Εικόνα 9 Αρχική οθόνη εφαρμογής Εικόνα 10 Οθόνη Σύνδεσης Εικόνα 11 Περισσότερες επιλογές αρχική οθόνη Εικόνα 12 Δημιουργία νέου πόρου Εικόνα 13 Οθόνη προβολής λεπτομερειών πόρου Εικόνα 14 Επιλογές στη οθόνη προβολής λεπτομερειών Εικόνα 15 Προβολή ομάδας πόρων Εικόνα 16 Οθόνη προβολής λεπτομερειών παιδιού Εικόνα 17 Οθόνη επεξεργασίας πόρου Εικόνα 18 Επιτυχής ανανέωση Πόρου Εικόνα 19 Διαγραφή Πόρου Εικόνα 20 Οθόνη Προβολής Πόρου Νο Εικόνα 21 Εναλλακτική κύρια οθόνη Εικόνα 22 Εναλλακτική οθόνη προβολής λεπτομερειών Εικόνα 23 Εναλλακτική οθόνη προβολής λεπτομερειών με ενσωμάτωση χάρτη

8 Λίστα Πινάκων Λίστα Πινάκων Πίνακας 1 Περιεχόμενα Απόκρισης API Πίνακας 2 Περιεχόμενα Λίστας Επιλογών Πίνακας 3 Περιεχόμενα αρχείου YAML Πίνακας 4 Χαρακτηριστικά Πόρου στο αρχείο YAML Πίνακας 5 Χρησιμοποιούμενα Angular Directives Πίνακας 6 Συναρτήσεις που εισάγονται με Dependency Injection

9 Εισαγωγή 1. Εισαγωγή 1.1. Σκοπός Διπλωματικής Εργασίας Σκοπός της παρούσας διπλωματικής εργασίας είναι η επιτάχυνση και μείωση του κόστους για την ανάπτυξη γραφικού περιβάλλοντος χρήστη και τον έλεγχο διαδικτυακών υπηρεσιών. Για το λόγο αυτό πραγματοποιήθηκε μελέτη της εξέλιξης των διαδικτυακών υπηρεσιών και της ανάπτυξης διεπαφών χρήστη που οδήγησε στην σχεδίαση και υλοποίηση του INTERACT. Ενός εργαλείου που θα παρέχει αυτόματα γραφικές διεπαφές πλήρως προσαρμόσιμες στη δομή ενός δοσμένου RESTful web API, δηλαδή μιας διαδικτυακής υπηρεσίας που υπακούει στην αρχιτεκτονική REST, καθώς αυτή αποτελεί σήμερα την επικρατέστερη επιλογή σχεδίασης. Το INTERACT σχεδιάστηκε ώστε να είναι συμβατό με τις υπηρεσίες που παράγονται από την πλατφόρμα του S-CASE. Ενός έργου λογισμικού που παρέχει μια πληθώρα υπηρεσιών και εργαλείων που αποσκοπούν στην επιτάχυνση της διαδικασίας ανάπτυξης RESTful Web APIs, από το στάδιο της σύλληψης της αρχικής ιδέας και του προσδιορισμού των απαιτήσεων του, μέχρι την τελική παράδοση του τελικού προγράμματος. Το INTERACT αναπτύχθηκε ώστε να είναι πλήρως λειτουργικό με μοναδικές εισόδους τις αποκρίσεις των API και ένα αρχείο που περιγράφει την οντολογία τους. Αποτελεί μια ολοκληρωμένη εφαρμογή αλλά παράλληλα παρέχει ευελιξία στον προγραμματιστή και την δυνατότητα επεξεργασίας κάθε στοιχείου για την πλήρη προσαρμογή της διεπαφής στις ανάγκες του API Οργάνωση Κεφαλαίων Στο κεφάλαιο 2 γίνεται περιγραφή του τεχνολογικού και θεωρητικού υπόβαθρου βάσει της τρέχουσας βιβλιογραφίας. Αναλύονται αρχικά οι έννοιες που αφορούν την ανάπτυξη λογισμικού και μίας ολοκληρωμένης διεπαφής, και έπειτα αυτές που αφορούν τις διαδικτυακές εφαρμογές και υπηρεσίες. Περιγράφεται η αρχιτεκτονική σχεδίασης REST και η τάση στην ανάπτυξη εφαρμογών που βασίζονται σε αυτήν. Το κεφάλαιο αυτό ολοκληρώνεται με την αναφορά των υπαρχουσών τεχνολογιών που καλύπτουν την ανάγκη σχεδίασης πελατών και διεπαφών χρήστη για τα REST web APIs

10 Εισαγωγή Στο κεφάλαιο 3 γίνεται επισκόπηση της προτεινόμενης εφαρμογής. Αναλύεται το μοντέλο MVC στο οποίο βασίστηκε η σχεδίαση της εφαρμογής και περιγράφονται τα εργαλεία που χρησιμοποιήθηκαν για την υλοποίηση. Στη συνέχεια γίνεται ανάλυση των εισόδων που δέχεται η εφαρμογή από το REST API και από το αρχείο YAML που ορίζει την οντολογία του. Περιγράφονται οι ελεγκτές που δομούν την εφαρμογή και οι έλεγχοι που εκτελούν για κάθε είσοδο. Το κεφάλαιο ολοκληρώνεται με την περιγραφή των βημάτων για την παραμετροποίηση και εκκίνηση της εφαρμογής. Στο κεφάλαιο 4 γίνεται η παρουσίαση του Interact μέσα από ένα σενάριο χρήσης. Στην ουσία παρατίθενται οι οθόνες που θα παρουσιάζονται στο χρήστη σε κάθε στάδιο της εφαρμογής και ακολουθεί επεξηγηματική ανάλυση για κάθε μία από αυτές. Στο κεφάλαιο 5 αναφέρονται οι μελλοντικές επεκτάσεις και βελτιώσεις που προτείνονται για την εφαρμογή. Τέλος στο παράρτημα γίνεται επεξήγηση του κώδικα που αναπτύχθηκε και παρέχεται μεθοδολογία για την επέμβαση σε αυτόν για την περεταίρω εξατομίκευση της εφαρμογής. Ο κώδικας της εφαρμογής μπορεί να βρεθεί στο ηλεκτρονικό αποθετήριο Github στη διεύθυνση:

11 Θεωρητικό και τεχνολογικό υπόβαθρο 2. Θεωρητικό και τεχνολογικό υπόβαθρο 2.1. Τεχνολογία λογισμικού Σήμερα το λογισμικό κατέχει διπλό ρόλο, είναι προϊόν και την ίδια στιγμή είναι το μέσο για την επιτυχία ενός προϊόντος. Ως προϊόν, παρέχει την υπολογιστική δυνατότητα που είναι ενσωματωμένη στο υλικό ή ευρύτερα σε ένα δίκτυο υπολογιστών που είναι προσβάσιμοι από τοπικό υλικό. Είτε βρίσκεται σε κινητό τηλέφωνο είτε σε έναν κεντρικό υπολογιστή, το λογισμικό είναι ένας μετασχηματιστής πληροφορίας. Παράγει, διαχειρίζεται, τροποποιεί και διαβιβάζει πληροφορίες που μπορεί να είναι τόσο απλές όσο ένα δυαδικό ψηφίο ή τόσο σύνθετες όσο μια παρουσίαση που προέρχεται από δεδομένα που αποκτούνται από δεκάδες ανεξάρτητές πηγές. Το λογισμικό ενεργεί ως βάση για τον έλεγχο του υπολογιστή ως λειτουργικό σύστημα, τη διαβίβαση της πληροφορίας μέσω δικτύων ή τον έλεγχο και δημιουργία άλλων προγραμμάτων ως εργαλείο λογισμικού ή περιβάλλον χρήστη. Το λογισμικό προσφέρει το σημαντικότερο προϊόν στην εποχή μας, την πληροφόρηση. Μετατρέπει συλλεγόμενα στοιχεία σε πιο χρήσιμη μορφή, διαχειρίζεται επιχειρηματικές πληροφορίες, ενισχύει την ανταγωνιστικότητα, παρέχει μία πύλη στα παγκόσμια δίκτυα πληροφόρησης και τα μέσα για την απόκτηση πληροφοριών όλων των μορφών. Οι σημαντικές βελτιώσεις στις επιδόσεις του υλικού, οι αλλαγές στην αρχιτεκτονική των υπολογιστών και τεράστιες αναβαθμίσεις στη μνήμη και την αποθηκευτική ικανότητα σε συνδυασμό με την επιστήμη της τεχνολογίας λογισμικού, έχουν προσδώσει στο λογισμικό τις τεράστιες δυνατότητες που έχει σήμερα. Στο Ινστιτούτο Ηλεκτρολόγων και Ηλεκτρονικών Μηχανικών - IEEE ορίζεται ως τεχνολογία λογισμικού η μελέτη των προσεγγίσεων και η εφαρμογή μιας συστηματικής, πειθαρχημένης και υπολογίσιμης προσέγγισης για την ανάπτυξη, λειτουργία και συντήρηση λογισμικού [1]. Η τεχνολογία λογισμικού είναι πολύ-επίπεδη και μέθοδοι της καλύπτουν ένα ευρύ φάσμα εργασιών για να παρέχουν την τεχνική για την ορθή ανάπτυξη λογισμικού. Περιλαμβάνουν την επικοινωνία, ανάλυση απαιτήσεων, σχεδιασμό μοντέλων, την ανάπτυξη του προγράμματος, τον

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

13 Θεωρητικό και τεχνολογικό υπόβαθρο 2.3. Διεπαφή Χρήστη Καλώς ή κακώς κάθε προϊόν λογισμικού, από τα λογισμικά βιομηχανικού εξοπλισμού έως τα λογισμικά ενός προσωπικού υπολογιστή και της διαδικτυακές εφαρμογές απαιτούν ακόμη την ανθρώπινη παρέμβαση. Έτσι για να είναι ένα προϊόν επιτυχημένο θα πρέπει να χαρακτηρίζεται από μία εύλογη ευχρηστία με την οποία ο άνθρωπος θα μπορεί να χρησιμοποιεί τις λειτουργίες και τα χαρακτηριστικά του προϊόντος, αποτελεσματικά. Η διαδικασία ανάπτυξης διεπαφής ακολουθεί βήματα παρόμοια με τον κύκλο ανάπτυξης του λογισμικού. Αρχικά γίνεται ανάλυση και μοντελοποίηση της διεπαφής που επικεντρώνεται στο προφίλ των χρηστών που θα αλληλεπιδρούν με το σύστημα. Ακολουθεί η σχεδίαση της διεπαφής όπου ορίζεται το σύνολο των αντικειμένων και δράσεων που επιτρέπουν στο χρήστη να εκτελεί με ευκολία τις εργασίες που του επιτρέπει η εφαρμογή. Στη συνέχεια, μέσω μιας επαναληπτικής διαδικασίας σχεδίασης κατασκευάζεται η τελική διεπαφή. Τέλος, γίνεται η επικύρωση της διεπαφής, η οποία εστιάζεται στην ικανότητα να εκτελούνται όλες οι παραλλαγές των εργασιών σωστά και παράλληλα να καλύπτονται οι γενικές απαιτήσεις των χρηστών. Ο Ben Shneiderman στο βιβλίο του περί σχεδίασης διεπαφών χρήστη αναφέρει τους 8 κανόνες για τη σχεδίαση μιας διεπαφής, που έχουν προκύψει από την έρευνά του πάνω στην αλληλεπίδραση ανθρώπου υπολογιστή[4[4]. 1. Προσπάθεια για συνοχή Ίδιες ή παρόμοιες ακολουθίες ενεργειών θα πρέπει να απαιτούνται από το χρήστη για παρόμοιες καταστάσεις και προβλήματα. Ταυτόσημη ορολογία θα πρέπει να χρησιμοποιείται στα μηνύματα, στα μενού και στις βοηθητικές οθόνες και συγκεκριμένες εντολές θα πρέπει να χρησιμοποιούνται καθόλη την διάρκεια. 2. Διευκόλυνση των τακτικών χρηστών για χρήση συντομεύσεων Καθώς η συχνότητα της χρήσης αυξάνεται, αυξάνεται και η επιθυμία του χρήστη για μείωση της αλληλεπίδρασης και αύξηση του ρυθμού του. Συντομογραφίες, πλήκτρα λειτουργιών, κρυφές εντολές, και μακροεντολές είναι πολύ χρήσιμες για έναν έμπειρο χρήστη. 3. Παροχή ενημερωτικής ανάδρασης

14 Θεωρητικό και τεχνολογικό υπόβαθρο Για κάθε δράση του χρήστη θα πρέπει να υπάρχει κάποια απόκριση από το σύστημα. Για συχνές και ελάχιστες δράσεις η απόκριση μπορεί να είναι μετριασμένη, για σπάνιες και σημαντικές δράσεις όμως, η αντίδραση οφείλει να είναι πιο ουσιαστική. 4. Ενημέρωση του χρήστη για ολοκλήρωση διεργασίας Οι ακολουθίες των πράξεων θα πρέπει να είναι οργανωμένες σε ομάδες με αρχή, μέση και τέλος. Τα ενημερωτικά σχόλια κατά την ολοκλήρωση μιας ομάδας δράσεων, δίνουν στους χρήστες την ικανοποίηση της ολοκλήρωσης, μια αίσθηση ανακούφισης και μία ένδειξη ότι ο δρόμος είναι σαφής προκειμένου να προετοιμαστούν για την επόμενη ομάδα δράσεων. 5. Εύκολος χειρισμός σφαλμάτων. Το σύστημα πρέπει να σχεδιάζεται με τέτοιο τρόπο, ώστε να μην επιτρέπει στο χρήστη να υποπέσει σε κάποιο σοβαρό σφάλμα. Σε περίπτωση σφάλματος το σύστημα θα πρέπει να είναι έτοιμο να το εντοπίσει και να προσφέρει απλούς και κατανοητούς μηχανισμούς για την αντιμετώπιση του. 6. Να επιτρέπεται η εύκολη αναίρεση δράσεων Οι δράσεις του χρήστη πρέπει να είναι αναστρέψιμες. Το χαρακτηριστικό αυτό ανακουφίζει από το άγχος, καθότι ο χρήστης γνωρίζει ότι τα λάθη ανατρέπονται και έτσι ενθαρρύνεται να ανακαλύψει όλες τις παρεχόμενες επιλογές. Το δικαίωμα ακύρωσης και επιστροφής μπορεί να παρέχεται για μία μοναδική εντολή ή εισαγωγή δεδομένων ή για μία ολόκληρη ακολουθία δράσεων. 7. Παραχώρηση ελέγχου συστήματος Οι έμπειροι χρήστες επιθυμούν πολύ έντονα την αίσθηση ότι είναι κύριοι του συστήματος και ότι αυτό αντιδρά στις πράξεις τους. Ο σχεδιασμός πρέπει να δίνει την εντύπωση στο χρήστη ότι είναι κύριος του συστήματος και ορίζει τις δράσεις και όχι ότι ακολουθεί τις αποκρίσεις. 8. Αποφυγή επιβάρυνσης της μνήμης του χρήστη Ο περιορισμός της ανθρώπινης δυνατότητας συγκράτησης και επεξεργασίας πληροφοριών στη μνήμη του, απαιτεί οι διεπαφές να παραμένουν απλές, οι πολλαπλές σελίδες να ενοποιούνται, η ρυθμός κίνησης του της οθόνης να μειώνεται, και να παρέχεται επαρκής χρόνος για την κατανόηση περιεχομένου και ακολουθιών ενεργειών

15 Θεωρητικό και τεχνολογικό υπόβαθρο 2.4. Παγκόσμιος Ιστός Ο παγκόσμιος ιστός (World Wide Web) έγινε όσο δημοφιλής γιατί απλοί άνθρωποι μπορούν να πραγματικά χρήσιμα πράγματα με ελάχιστη εκπαίδευση. Στην πραγματικότητα όμως πρόκειται για μια πανίσχυρη πλατφόρμα εξυπηρέτησης δικτύων κατανεμημένων υπολογιστικών συστημάτων, δηλαδή του διαδικτύου. Οι όροι διαδίκτυο (Internet) και Παγκόσμιος Ιστός (World wide web) χρησιμοποιούνται δίχως ιδιαίτερη διάκριση λόγω της σχέσης μεταξύ τους. Το διαδίκτυο είναι ένα παγκόσμιο δίκτυο συνδεδεμένων υπολογιστών, ενώ ο παγκόσμιος ιστός είναι μια τεράστια συλλογή αρχείων κειμένου και διάφορων άλλων πόρων, συνδεδεμένων με υπερσυνδέσμους (hyperlinks) και URIs (Uniform Resource Identifiers). Οι πόροι του παγκόσμιου ιστού (web resources) είναι συνήθως προσπελάσιμοι μέσω του Πρωτόκολλο Μεταφοράς Υπερκειμένου (HyperText Transfer Protocol, HTTP), το οποίο είναι ένα από τα πολλά πρωτόκολλά επικοινωνίας στο διαδίκτυο. Η καινοτομία του Τιμ Μπέρνερς Λι ήταν να παντρέψει το υπερκείμενο (hypertext) με το διαδίκτυο. Στο βιβλίο του Weaving The Web, εξηγεί ότι είχε επανειλημμένως προτείνει τη σύνδεση των δύο τεχνολογιών σε αμφότερες τις τεχνικές κοινότητες αλλά χωρίς να έχει κάποια απήχηση, έτσι τελικά ανέλαβε να εκπονήσει αυτό το πρότζεκτ μόνος του. Για την επίτευξη αυτού του στόχου ανέπτυξε τρεις τεχνολογίες: Την γλώσσα HyperText Markup Language (HTML) Το Hypertext Transfer Protocol (HTTP). Ένα σύστημα μοναδικών αναγνωριστικών για τους πόρους στον Ιστό, το universal document identifier (UDI), το οποίο μετεξελίχθηκε στα γνωστά uniform resource locator (URL) και uniform resource identifier (URI)

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

17 Θεωρητικό και τεχνολογικό υπόβαθρο υπερκειμένου, αλλά μεταφοράς πληροφοριών με την απαιτούμενη αποτελεσματικότητα, ώστε να επιτυγχάνονται οι μεταβάσεις των υπερσυνδέσμων. Η πιο τυπική χρήση του είναι κατά την συναλλαγή ανάμεσα σε ένα πρόγραμμα πλοήγησης στον ιστό και σε ένα εξυπηρετητή. Τα δεδομένα που μεταφέρονται λόγω των διαδικασιών του HTTP μπορούν να είναι απλό κείμενο, υπερκείμενο, ήχος, εικόνες, ή οποιαδήποτε άλλη πληροφορία που είναι προσπελάσιμη στο διαδίκτυο. Ένα ακόμη χαρακτηριστικό του HTTP είναι ότι δεν έχει μνήμη, δηλαδή κάθε συναλλαγή αντιμετωπίζεται ξεχωριστά. Επομένως μια τυπική υλοποίηση θα δημιουργεί μια νέα σύνδεση ανάμεσα στον πελάτη και τον εξυπηρετητή για κάθε νέα συναλλαγή[5]. Κάθε συναλλαγή εμπεριέχει το αίτημα που προέρχεται από τον πελάτη και χαρακτηρίζεται από την παράμετρο μεθόδου, τον υπερσύνδεσμο (URL) της αιτηθείσας πηγής, και την απόκριση του εξυπηρετητή στο αίτημα αυτό. Οι κυριότερες μέθοδοι του HTTP είναι : GET : αίτηση ανάκτησης πληροφοριών που προσδιορίζονται στο URL και επιστροφής αυτών σε ένα σώμα οντότητας. POST: αίτηση αποδοχής για εγγραφή της επισυναπτόμενης οντότητας στον καθορισμένο πόρο που υποδείχνει ο URL, δημιουργώντας μια νέα. PUT: αίτηση αποδοχής της επισυναπτόμενης οντότητας και αποθήκευσή της στον πόρο που υποδεικνύει ο URL, ανανεώνοντας το περιεχόμενο του. DELETE: αίτηση διαγραφής του πόρου που προσδιορίζεται από τον URL Άλλες μέθοδοι του πρωτοκόλλου είναι οι OPTION HEAD PATCH COPY MOVE LINK UNLINK

18 Θεωρητικό και τεχνολογικό υπόβαθρο TRACE WRAPPED Τα μηνύματα απόκρισης από τον εξυπηρετητή περιλαμβάνουν τον κωδικό κατάστασης ( statuscode) που είναι ένας τριψήφιος ακέραιος και την φράση αιτίας (reason phrase) που περιέχει μια σύντομη φραστική εξήγηση του κωδικού κατάστασης. Καθώς το πρωτόκολλο περιλαμβάνει μεγάλο πλήθος κωδικών κατάστασης, αυτοί μπορούν να κατηγοριοποιηθούν ως εξής : Πληροφοριακοί, της μορφής 1xx Επιτυχείς, της μορφής 2xx Ανακατεύθυνσης, της μορφής 3xx Σφάλματος Πελάτη, της μορφής 4xx Σφάλμα διακομιστή, της μορφής 5xx URIs Για να χρησιμοποιηθεί ένας πόρος στον παγκόσμιο ιστό πρέπει πρώτον να είμαστε σε θέση να τον εντοπίσουμε και δεύτερον να υπάρχουν μέσα ώστε να μπορούμε να τον διαχειριστούμε. Για αυτό το σκοπό ο ιστός παρέχει τα URIs (Uniform Resource Identifiers). Ένα URI ταυτοποιεί έναν πόρο και ταυτόχρονα τον διευθυνσιοδοτεί ώστε να είναι δυνατόν να προσπελαστεί και διαχειριστεί από κάποιο πρωτόκολλο όπως το HTTP. Το URI ενός πόρου τον διαχωρίζει από οποιονδήποτε άλλον και μέσω αυτού καθίστανται δυνατές όλες οι αλληλεπιδράσεις μαζί του. Οι σχέση μεταξύ URI και πόρων είναι πολλά προς έναν. Αυτό σημαίνει ότι ένα URI μπορεί να καταδεικνύει μόνο έναν πόρο, αλλά ένας πόρος μπορεί να αναγνωρίζεται από διαφορετικά URIs

19 Θεωρητικό και τεχνολογικό υπόβαθρο Εικόνα 2 Ο ιστός [10] Η παραπάνω εικόνα δείχνει τον κύριο ρόλο των πόρων και των URIs, υποστηριζόμενο από την προσηνή αποθήκευση (web caches), στην επεκτασιμότητα του ιστού. Παράλληλα τα όρια των services παρέχουν την απαραίτητη απομόνωση και την ανεξάρτητη εξέλιξη των εφαρμογών Resources ή Πόροι Οι πόροι είναι οι ακρογωνιαίοι λίθοι όλων των συστημάτων που λειτουργούν στο διαδίκτυο. Πόρος είναι οτιδήποτε μπορεί να εκτεθεί ή να χρησιμοποιηθεί στο διαδίκτυο, από ένα αρχείο, ένα βίντεο, μια επιχειρηματική διεργασία ή κίνηση ή μια συσκευή και γενικά με ό,τι μπορούμε να αλληλοεπιδράσουμε

20 Θεωρητικό και τεχνολογικό υπόβαθρο 2.5. Διαδικτυακή Υπηρεσία Web Service και Service Ο παγκόσμιος ιστός καθόλη την εξέλιξη του στρέφεται ολοένα και περισσότερο στην επικοινωνία μεταξύ εφαρμογών, πέρα από τα όρια της ανθρώπινης αλληλεπίδρασης. Οι προγραμματισμένες διεπαφές που καλύπτουν αυτήν την ανάγκη, αναφέρονται σαν Διαδικτυακές Υπηρεσίες ή Web Services. Σύμφωνα με τον W3C, μια διαδικτυακή υπηρεσία (Web Service) ορίζεται ως [6]: Ένα σύστημα λογισμικού σχεδιασμένο ώστε να υποστηρίζει διαλειτουργική αλληλεπίδραση μεταξύ μηχανών μέσω ενός δικτύου. Παρέχει μια διεπαφή η οποία περιγράφεται σε μια μορφή επεξεργάσιμη από μηχανές (συγκεκριμένα στην μορφή WSDL). Άλλα συστήματα αλληλοεπιδρούν με την διαδικτυακή υπηρεσία με τρόπο που καθορίζεται από την περιγραφή της διεπαφής χρησιμοποιώντας μηνύματα SOAP, τα οποία τυπικά μεταφέρονται χρησιμοποιώντας το πρωτόκολλο HTTP και γραμμένα σε XML, και σε συνδυασμό με άλλα πρότυπα που αφορούν το διαδίκτυο. Το SOAP (Simple Object Access Protocol) είναι μια XML γλώσσα που καθορίζει την αρχιτεκτονική δομή και το είδος των μηνυμάτων που ανταλλάσσονται μεταξύ του καταναλωτή ( αιτών ή πελάτη ) και του πάροχου ενός Web Service, παρέχοντας ένα στοιχειώδες πρωτόκολλο επεξεργασίας τους. Κάθε SOAP έγγραφο καθορίζεται από έναν XML «φάκελο» που αποτελείται από μια κεφαλίδα με πληροφορίες και το κυρίως μέρος καλούμενο ως «σώμα», το οποίο περιέχει στην ουσία το μήνυμα. Ένα XML αρχείο περιλαμβάνει τις απαραίτητες πληροφορίες ώστε να είναι εφικτή η αναγνώριση των περιεχομένων του μηνύματος διαχείρισή του[7][14]. και η μετέπειτα Η παραπάνω αρχιτεκτονική παρουσίασε σημαντικά προβλήματα όσο αυξανόταν η πολυπλοκότητα των συστημάτων προς υλοποίηση, και δέχτηκε αρνητική κριτική. Μερικά αρνητικά σημεία είναι τα εξής: To HTTP πρωτόκολλο δεν χρησιμοποιείται όπως προοριζόταν κατά την σύλληψη του

21 Θεωρητικό και τεχνολογικό υπόβαθρο Επιπλέον επίπεδο πολυπλοκότητας, καθώς τόσο για τα αιτήματα, όσο και για τις απαντήσεις, απαιτείται η μετατροπή από και προς XML - SOAP αρχεία. Ο κώδικας που απαιτείται για την δημιουργία τους όσο αυξάνετα η πολυπλοκότητα καταλήγει να δυσχεραίνει το έργο των προγραμματιστών, τόσο στην συγγραφή των εφαρμογών στην πλευρά του διακομιστή (server), όσο και στις εφαρμογές που καλούν την υπηρεσία (clients). Το γεγονός πως μία υπηρεσία είναι διαθέσιμη από έναν και μόνο σύνδεσμο καθιστά δύσκολη την διάσχιση μεταξύ των διαφόρων μεθόδων που διαθέτει Web APIs και Restful Αρχιτεκτονική. Αν και δεν υπάρχει ακριβής ορισμός για τις διαδικτυακές διεπαφές προγραμματισμού εφαρμογών (web APIs), θα μπορούσαν να θεωρηθούν ως ένα σύστημα λογισμικού αποτελούμενο από ένα ή περισσότερα διαδικτυακά σημεία πρόσβασης δεδομένων ή διεργασιών, που λειτουργεί με ένα ορισμένο σύστημα ανταλλαγής μηνυμάτων αιτήματοςαπόκρισης. Τα μηνύματα αυτά είναι συνήθως εκφρασμένα σε μορφή JSON και ανταλλάσσονται από διακομιστές που εξυπηρετούν HTTP μεθόδους [13]. Παρόλο που τα Web APIs πολλές φορές συγχέονται με τα web services, οι μοντέρνες διαδικτυακές εφαρμογές έχουν αποστραφεί από τα SOAP web services λόγω των προαναφερθέντων μειονεκτημάτων τους. Έτσι τα web APIs διακρίνονται από τα web services καθώς έχουν στραφεί πλέον στην αποκαλούμενη RESTful αρχιτεκτονική. Το REST (Representational State Transfer) αποτελεί ένα σύνολο από αρχές σχεδίασης μιας δικτυακής υπηρεσίας που επικεντρώνει στους πόρους ενός συστήματος. Η μεταβολή της κατάστασης των πόρων του συστήματος περιγράφεται και μεταφέρεται στο σύστημα μέσω του πρωτοκόλλου HTTP από διάφορους clients. Aξίζει σημειωθεί ότι το REST πρωτοεμφανίστηκε το 2000 από τον Roy Fielding στην ακαδημαϊκή του διατριβή με τίτλο «Architectural Styles and the Design of Network-based Software Architectures»[8]

22 Θεωρητικό και τεχνολογικό υπόβαθρο Όπως απλοϊκά το έχει θέσει ο Roy Fielding σε ομιλία του το 2013 [9] «Ένα REST API είναι απλώς ένας ιστότοπος για χρήστες με περιορισμένο λεξιλόγιο» (με την έννοια της αλληλεπίδρασης μεταξύ μηχανών) Βασικά αξιώματα του REST είναι [10]: Οτιδήποτε μπορεί να είναι πόρος Κάθε πόρος είναι αναγνωρίσιμος από ένα μοναδικό URI Χρήση βασικών HTTP μεθόδων Οι πόροι μπορούν να έχουν διάφορες αναπαραστάσεις Επικοινωνία «χωρίς μνήμη» ή με «έλλειψη κατάστασης» Οι στόχοι χρήσης της αρχιτεκτονικής REST είναι [12] [14]: Διαχωρισμός πόρου και αναπαράστασης Ορατότητα (Visibility) της επικοινωνίας μεταξύ των service μέσω των βασικών μεθόδων HTTP Απλότητα διεπαφής Δυνατότητα τροποποίησης και φορητότητα των επιμέρους στοιχείων του service ακόμη και όταν είναι σε λειτουργία Αξιοπιστία εφαρμογής Επεκτασιμότητα Αυξημένη απόδοση Στη συνέχεια επισημαίνονται οι σημαντικότερες αρχές που ακολουθεί η αρχιτεκτονική του μοντέλου REST [10] [16]: Addressability Περιγράφει την απαίτηση των διευθυνσιοδοτούμενων δεδομένων, δηλαδή το γεγονός ότι κάθε αντικείμενο θα πρέπει να είναι προσβάσιμο μέσα από ένα μοναδικό αναγνωριστικό. Αυτό επιτυγχάνεται με χρήση των URIs (Uniform Resource Identifiers) τα οποία συνδέουν τους πληροφοριακούς πόρους μιας διαδικτυακής εφαρμογής με ένα URI της μορφής: scheme://host:port/path?querystring#fragment

23 Θεωρητικό και τεχνολογικό υπόβαθρο Στην παραπάνω διεύθυνση, scheme είναι το πρωτόκολλο που χρησιμοποιείται για την επικοινωνία, συνήθως είναι http ή https. Host είναι ένα όνομα DNS ή μια IP διεύθυνση, και ακολουθείται από την θύρα (port) μέσω της οποίας γίνεται η επικοινωνία. Στη συνέχεια υπάρχει το path, δηλαδή η διαδρομή από τον κεντρικό φάκελο έως την τοποθεσία που βρίσκεται η ζητούμενη πληροφορία, ενώ μετά τον χαρακτήρα? ακολουθούν διάφορες μορφές παραμέτρων, οι οποίες χωρίζονται με τον χαρακτήρα &. Τέλος, το τμήμα fragment που ακολουθεί τον χαρακτήρα # συνήθως χρησιμοποιείται για να καθορίσει το ακριβές σημείο του εγγράφου αναφοράς του ερωτήματος. The Uniform, Constrained Interface Βασίζεται στην ιδέα της χρήσης του πεπερασμένου συνόλου των μεθόδων που προσφέρει το εκάστοτε πρωτόκολλο (συνήθως HTTP) με τον απλούστερο δυνατό τρόπο, και για τη λειτουργία που αυτές έχουν ορισθεί. Κάθε μέθοδος έχει το σκοπό και τη σημασία της: GET Είναι μέθοδος read-only και χρησιμοποιείται για την ανάκτηση πληροφοριών από τον server. Χαρακτηρίζεται ως λειτουργία idempotent και safe. Αυτό σημαίνει ότι όσες φορές και να επαναληφθεί η εντολή για τον ίδιο πληροφοριακό πόρο, το αποτέλεσμα είναι πάντα το ίδιο (idempotency), ενώ παράλληλα η εντολή δεν τροποποιεί το περιεχόμενο του πόρου (safety). PUT Η μέθοδος PUT αιτείται στον server να αποθηκεύσει την πληροφορία που αποστέλλεται στο κυρίως σώμα (body message) του αιτήματος, και χαρακτηρίζεται επίσης ως idempotent λειτουργία, διότι όσες φορές και να επαναληφθεί, το αποτέλεσμα θα είναι το ίδιο, δηλαδή η αποθήκευση συγκεκριμένης πληροφορίας στον server. DELETE Η μέθοδος DELETE χρησιμοποιείται για τη διαγραφή πόρων και χαρακτηρίζεται επίσης ως idempotent. POST Η μέθοδος POST χρησιμοποιείται για τη δημιουργία νέας πληροφορίας στον server και είναι η μοναδική non-idempotent και non-safe λειτουργία του πρωτοκόλλου HTTP. Κι αυτό γιατί κάθε εντολή POST έχει τη δυνατότητα να μεταβάλλει τον πληροφοριακό πόρο στον οποίο απευθύνεται με οποιονδήποτε τρόπο

24 Θεωρητικό και τεχνολογικό υπόβαθρο HEAD Η μέθοδος αυτή είναι πανομοιότυπη με την μέθοδο GET, εκτός στο ότι επιστρέφει μόνο τον κωδικό απόκρισης και τις επικεφαλίδες, αν υπάρχουν. OPTIONS Η μέθοδος OPTIONS χρησιμοποιείται για την ανάκτηση πληροφοριών σχετικών με τις επιλογές επικοινωνίας, με τις οποίες σχετίζεται ο πληροφοριακός πόρος. Η συγκεκριμένη αρχιτεκτονική αρχή είναι πολύ σημαντική, διότι προσφέρει αρκετά πλεονεκτήματα. Επιγραμματικά αναφέρεται η ευκολία χρήσης ενός μικρού αριθμού μεθόδων για την επικοινωνία με οποιασδήποτε μορφής πληροφοριακούς πόρους και υπηρεσίες, η ευκολία στη χρήση των μεθόδων μέσω clients σε ένα μεγάλο σύνολο γλωσσών προγραμματισμού, και η προβλεψιμότητα και η δυνατότητα επέκτασης ενός συνόλου υφιστάμενων υπηρεσιών. Representation Oriented Η τρίτη αρχή του μοντέλου REST έγκειται στην μορφή αναπαράστασης των πληροφοριακών πόρων, που ανταλλάσσονται μεταξύ πελάτη και εξυπηρετητή. Η αναπαράσταση μπορεί να είναι μία εκ των XML, JSON, YAML, αλλά και οποιαδήποτε άλλη αναπαράσταση δεδομένων συμφωνηθεί. Στα πλαίσια της υλοποίησης, χρησιμοποιείται η αναπαράσταση JSON, που είναι συμβατή με όλες τις υπόλοιπες τεχνολογίες. Communicate Statelessly Η τέταρτη αρχιτεκτονική αρχή έχει να κάνει με την παντελή έλλειψη πληροφοριών από προηγούμενη επικοινωνία ενός πελάτη και μιας υπηρεσίας. Με άλλα λόγια, ο εξυπηρετητής διαθέτει μόνο την πληροφορία κατάστασης για τους πληροφοριακούς πόρους που διαθέτει. Αυτό μειώνει την πολυπλοκότητα και τον όγκο των δεδομένων από πλευράς εξυπηρετητή, και παράλληλα συμβάλλει στην εύκολη επέκταση των υφιστάμενων υπηρεσιών. HATEOAS Η τελευταία προκύπτει από τη φράση Hypermedia As The Engine of Application State. Η λογική αυτής της αρχής βασίζεται στην ενσωμάτωση συνδέσμων σε πληροφοριακούς πόρους, με

25 Θεωρητικό και τεχνολογικό υπόβαθρο σκοπό την παροχή εύκολης προσβασιμότητας σε αυτούς. Η λογική αυτή συμβάλλει στην σωστή δόμηση πληροφοριακών πόρων, που αναφέρονται σε άλλους, και στην μείωση των απαιτούμενων αιτημάτων από πλευράς client Richardson s Maturity Model (RMM) Το Richardson s Maturity Model ( μοντέλο ωριμότητας του Richardson) ορίζει τα χαρακτηριστικά που θα πρέπει να διέπουν ένα web service ώστε να χαρακτηρίζεται ως RESTful. Σύμφωνα με αυτό θα πρέπει [17]: Οι πόροι που αποτελούν το service θα πρέπει να αναγνωρίζονται από μοναδικά URIs. Αυτό σημαίνει ότι κάθε διακριτός πόρος θα έχει διαφορετικά URIs. Κάθε URI θα είναι προσβάσιμο με τις βασικές HTTP μεθόδους οι οποίες μάλιστα πρέπει να εκτελούνται με τον ορθό καθορισμένο τρόπο. Οι πόροι του service θα πρέπει να είναι διασυνδεδεμένοι με hypermedia links ( συνδέσμους υπερμέσων), οι οποίοι θα παρέχουν στο καταναλωτή ( consumer) του service τις επόμενες δυνατές κινήσεις μετά την αλληλεπίδραση με τον συγκεκριμένο πόρο. Αυτό σημαίνει ότι μετά από κάθε αίτημα σε ένα RESTful service, εκτός από την απαιτούμενη απόκριση ο καταναλωτής θα λαμβάνει και μια λίστα με συνδέσμους που θα τους υποδεικνύουν τις παραπέρα επιλογές του, χωρίς να χρειάζεται να έχει γνώση αυτών εκ των προτέρων

26 Θεωρητικό και τεχνολογικό υπόβαθρο Εικόνα 3 Richardson's Maturity Model[22] 2.8. Τάση στην ανάπτυξη των Web APIs Τα Web APΙs δεν αποτελούν μια καινούρια τεχνολογία, λειτουργούν στο διαδύκτιο ήδη από τις αρχές τους 21 ου αιώνα, με πρώτα να κυκλοφορούν αυτά των ιστότοπων Salesforce.com και Ebay. Τα τελευταία όμως χρόνια είναι που υπήρξε ραγδαία ανάπτυξη στον τομέα, όχι μονο σε αριθμό ή στην αύξηση των χρηστών αλλά και σε επίπεδο πολυπλοκότητας και λειτουργιών που καλύπτουν. Ο ιστότοπος programmableweb.com ιδρύθηκε το 2005 και από τότε καταγράφει την εξέλιξη της «οικονομίας των Web APIs» παρέχοντας πληροφορίες, στατιστικές και αρθρογραφία σχετικά με το αντικείμενο. Στο παρακάτω διάγραμμα μπορούμε να δούμε την ραγδαία αύξηση των Web APIs στο χρονικό διάστημα 2005 με 2013 [18]

27 Θεωρητικό και τεχνολογικό υπόβαθρο Εικόνα 4 Αναπαράσταση της αύξησης του αριθμού των Web APIs Ο ίδιος ιστότοπος αναφέρει πως μόνο το 2015 καταχωρήθηκαν στην βάση του πάνω από 2000 νέα APIs και αυτή τη στιγμή ξεπερνούν τις Παράλληλα ο ιστότοπος apihound.com που ασχολείται με το ίδιο αντικείμενο, ισχυρίζεται πως έχει την πλέον σύγχρονη μηχανή αναζήτησης για Web APIs και αναφέρει πως έχει καταγράψει πάνω από Σημαντικό είναι επίσης να τονιστεί πως αυτά τα νούμερα που παρουσιάζονται αφορούν μόνο τα δημόσια APIs που είναι προσβάσιμα μέσω διαδικτύου και όχι αυτών που προορίζονται για ιδιωτική ή επιχειρηματική χρήση [18][19]. Μια άλλη στατιστική που παρουσίασε το programmableweb.com αναφέρει τα ποσοστά που κατέχουν οι διάφορες προσεγγίσεις στην ανάπτυξη API, και τον κυρίαρχο ρόλο που παίζουν αυτή τη στιγμή τα RESTful APIs στις διαδικτυακές εφαρμογές. Τα αποτελούνται από : καταχωρημένα API 69% RESTful APIs 22% SOAP 5% JavaScript

28 Θεωρητικό και τεχνολογικό υπόβαθρο 2% XML-RPC Την ολοένα αυξανόμενη ζήτηση και χρήση REST APIs είναι λογικό να συνοδεύει και η τάση στην εξέλιξη των τεχνικών και εργαλείων δημιουργίας τους, καθώς και αυτά για την κατανάλωση τους Επισκόπηση MDE Τα τελευταία χρόνια, διάφορα πλαίσια ανάπτυξης εφαρμογών έχουν συμπεριλάβει εργαλεία για την διευκόλυνση της ανάπτυξης RESTful εφαρμογών, είτε μέσω έτοιμων βιβλιοθηκών υψηλού επιπέδου, είτε με την χρήση κάποιον μεθοδολογιών για την αυτοματοποιημένη παραγωγή κώδικα. Όσων αφορά την δεύτερη περίπτωση, πολλά εργαλεία στοχεύουν στην γρήγορη δημιουργία ενός «σκελετού» κώδικα στον οποίο ο προγραμματιστής καλείται να εφαρμόσει την δική του υλοποίηση, ή στην αυτοματοποιημένη παραγωγή μερικώς ολοκληρωμένων υλοποιήσεων. Το Object Management Group (OMG) [20] παρουσίασε για πρώτη φορά την μηχανική οδηγούμενη από μοντέλα ή Model Driven Engineering (MDE), η οποία φιλοδοξεί να αλλάξει την σχεδίαση και τα πρότυπα κατασκευής λογισμικού. Η κύρια αρχή που διέπει την MDE είναι η μετάβαση της φύσης της μηχανικής λογισμικού από την προσήλωση στον κώδικα σε μία που θα βασίζεται σε μοντέλα, με σκοπό να επιτυγχάνεται μεγαλύτερη συνοχή και αυξημένα επίπεδα αυτοματοποίησης και παραγωγικότητας. Με λίγα λόγια, αποσκοπεί στην μείωση των απαιτήσεων σε χρόνο και κόστος της παράδοση ενός έργου λογισμικού [22]. Η MDE αποτελείται από τέσσερεις φάσεις. Κατά την πρώτη διαμορφώνεται το Computational Independent Model (CIM) ή αλλιώς ανεξάρτητο υπολογιστικό μοντέλο. Αυτό αποτελεί στην ουσία μια αφηρημένη όψη του βασικού συστήματος. Περιλαμβάνει τους τομείς των εννοιών, ιδιοτήτων και οντοτήτων της εφαρμογής. Κατά τη διάρκεια αυτής της φάσης, οι λεπτομέρειες σχεδιασμού αρχιτεκτονικής και εκτέλεσης είναι ασυσχέτιστες. Ο προγραμματιστής πρέπει να μοντελοποιήσει το σύστημα που πρόκειται να χτιστεί όπως ορίζεται στα αφηρημένα πεδία των εννοιών και των συσχετίσεων τους

29 Θεωρητικό και τεχνολογικό υπόβαθρο Όταν το CIM έχει μορφοποιηθεί, μια διαδικασία «model to model» λαμβάνει χώρα και μετατρέπει το CIM στο αντίστοιχο μοντέλο ανεξάρτητου πλατφόρμας ή Platform Independent Model (PIM). Το PIM παρουσιάζει τον αποδομημένο σχεδιασμό του συστήματος δίχως τις λεπτομέρειες εκτέλεσης. Παρόλα αυτά, κατά τη διάρκεια της μετατροπής του CIM στο αντίστοιχο PIM, η σχεδιασμένη αρχιτεκτονική εφαρμόζεται στο σε κάθε πεδίο του CIM με σκοπό να σχηματιστεί ο ολοκληρωμένος σχεδιασμός που πληροί τις απαιτήσεις συστήματος. Η τρίτη φάση περιλαμβάνει την μετατροπή του PIM στα πιθανά μοντέλα συγκεκριμένης πλατφόρμας ή Platform Specific Models ( PSM). Τα PSM ικανοποιούν το σχεδιασμό που ορίζεται στο PIM αλλά συγκεκριμενοποιούν τον τρόπο που θα γίνει υλοποίηση, θεσπίζοντας τις λεπτομέρειες για την γλώσσα προγραμματισμού, τα διάφορα frameworks, βιβλιοθήκες που θα χρησιμοποιηθούν και τα πρότυπα σχεδίασης που εφαρμόζονται. Έτσι, ορίζονται οι διάφορες τεχνολογίες που θα χρησιμοποιηθούν σε κάθε μετατροπή PIM σε PSM. Θα πρέπει να σημειωθεί ότι υπάρχει σχέση ένα-προς-πολλά ανάμεσα στο PIM και τα συμβατά PSM. Δηλαδή, κάθε σχέδιο συστήματος που ορίζεται στο PIM μπορεί να υλοποιηθεί με διάφορους διακριτούς συνδυασμούς των προαναφερθέντων τεχνολογιών και να δομηθούν διαφορετικά PSM. Τέλος, η MDE μηχανή παράγει τον κώδικα συμπληρώνοντας τα πρότυπα με τα μετα-δεδομένα που παρέχονται από το PSM. Ορισμένα, τμήματα του παραδοτέου κώδικα είναι πλήρης ενώ άλλα ίσως χρειάζονται περεταίρω παρέμβαση από τον προγραμματιστή για να ολοκληρωθούν Η πλατφόρμα S-CASE Η παρούσα διπλωματική εργασία στηρίζεται στο S-CASE έργο λογισμικού [23]. Το S-CASE αποτελεί ένα ερευνητικό έργο το οποίο έλαβε μορφή τον Νοέμβριο του 2013, και φιλοδοξεί να παρέχει στους μηχανικούς λογισμικού μία σειρά από υπηρεσίες και εργαλεία, προκειμένου να αναπτύσσουν γρήγορα υπηρεσίες λογισμικού υψηλής ποιότητας. Μέσα από τις καινοτομίες που εισάγει, το έργο S-CASE αναμένεται να μειώσει το χρόνο που απαιτείται μεταξύ της σύλληψης μιας ιδέας και της τελικής υλοποίησης μιας υπηρεσίας λογισμικού, οδηγώντας έτσι σε

30 Θεωρητικό και τεχνολογικό υπόβαθρο φθηνότερες υπηρεσίες. Το S-CASE χρηματοδοτήθηκε από την Ευρωπαϊκή Ένωση, και συγκεκριμένα από το πρόγραμμα FP7 (7th Framework Programme for Research and Technological Development) [24]. Πιο συγκεκριμένα, το S-CASE παρέχει μια πληθώρα υπηρεσιών και εργαλείων που αποσκοπούν στην επιτάχυνση της διαδικασίας ανάπτυξης RESTful Web APIs, από το στάδιο της σύλληψης της αρχικής ιδέας και του προσδιορισμού των απαιτήσεων του, μέχρι την τελική παράδοση του τελικού προγράμματος. Μεταξύ άλλων, το S-CASE περιλαμβάνει ένα σύστημα το οποίο αρχικά δίνει την δυνατότητα στον προγραμματιστή να ορίσει και να επεξεργαστεί τις λειτουργικές απαιτήσεις και τα σενάρια χρήσης του ζητούμενου RESTful Web API και στην συνέχεια γίνεται μια σειρά αυτοματοποιημένων διαδικασιών με σκοπό την παραγωγή του προγράμματος. Η γενική αρχιτεκτονική που ακολουθεί το σύστημα που υλοποιεί το S-CASE για αυτόν τον σκοπό παρουσιάζεται στην παρακάτω εικόνα. Εικόνα 5 Επισκόπηση της αρχιτεκτονικής του συστήματος αυτόματης παραγωγής κώδικα του S-CASE Το σύστημα αυτό αποτελείται από δύο επιμέρους στοιχεία, το Reqs2Specs και το MDE Engine. Τα δύο αυτά στοιχεία προορίζονται για χρήση από τον Eclipse IDE, και είναι υλοποιημένα ως Eclipse Plugins. Το Reqs2Specs περιλαμβάνει ένα σύνολο εργαλείων για τον προγραμματιστή για την εισαγωγή των λειτουργικών απαιτήσεων και των σεναρίων χρήσης του ζητούμενου συστήματος, καθώς και μια μεθοδολογία για τον μετασχηματισμό των παραπάνω απεικονίσεων σε μοντέλα. Το κομμάτι του MDE Engine εκτελεί μια σειρά από μετασχηματισμούς μοντέλων,

31 Θεωρητικό και τεχνολογικό υπόβαθρο ενώ παράλληλα επιτρέπει στον προγραμματιστή περεταίρω διαχείριση αυτών των μετασχηματισμών, έτσι ώστε να παραχθεί ο πηγαίος κώδικας του ζητούμενου Web API [21] Clients και σύγχρονες τεχνολογίες κατανάλωσης Web API Διάφορες τεχνολογίες έχουν αναπτυχθεί για την διευκόλυνση της δημιουργίας εφαρμογών τόσο για την κατανάλωση και τον ελέγχου των REST APIs, όσο και για την δημιουργία γραφικών διεπαφών χρήστη για την αξιοποίηση ενός API και την προβολή της λειτουργικότητας του. Κάθε μια παρέχει τα δικά της πλεονεκτήματα και η επιλογή έγκειται στο αποτέλεσμα που επιθυμεί να έχει ο προγραμματιστής του API, τα εργαλεία που έχει επιλέξει για την υλοποίηση του και τον βαθμό εξοικείωσης με την κάθε μία από αυτές. Θα αναφερθούν επιγραμματικά οι πιο διαδεδομένες για τις παρακάτω κατηγορίες. Εργαλεία και πλαίσια για την δημιουργία πελάτες σε Java. Είναι εργαλεία που αναλύουν το ΑPI και παράγουν κώδικα για την κατανάλωση του από χρήστες ή εξωτερικά services, συνήθως δέχονται και σαν είσοδο την οντολογία του και το URI του βασικού πόρου. Χαρακτηριστικά παραδείγματα αποτελούν τα : Swagger Code Generator[25] Alchemy Rest Client Generator [26] Firware Rest Client Generator (eclipse plugin)[27] Ολοκληρωμένες γραφικές εφαρμογές για API functionality testing. Πρόκειται για πλατφόρμες που δέχονται σαν είσοδο τα URI των πόρων του API, εκτελούν βασικά αιτήματα σε αυτό και εμφανίζουν τις αποκρίσεις. Ο χρήστης τους έχει την επιλογή να τροποποιήσει τα αιτήματα διαμορφώνοντας τις κεφαλίδες και τα δεδομένα που αποστέλλονται. Χαρακτηριστικά παραδείγματα είναι τα: POSTMAN[28] Advanced Rest Client [29]

32 Θεωρητικό και τεχνολογικό υπόβαθρο JavaScript frameworks και generators. Όσο οι δυνατότητες των browsers διευρύνονται, αναπτύσσεται και η τάση της μεταφοράς λειτουργικότητας στον client. Έτσι αναπτύσσονται συνεχώς νέα πλαίσια που καλύπτουν όλο και περισσότερο τις ανάγκες για κατανάλωση API και δημιουργία Model View Controller (MVC) ή Model-View-View-Model (MVVM) εφαρμογών που θα αποτελούν το front-end κομμάτι του API, παρέχοντας μεγάλο εύρος υλοποιημένων συναρτήσεων και άλλων λειτουργιών. Χαρακτηριστικά παραδείγματα που διευκολύνουν την δημιουργία τέτοιων εφαρμογών είναι τα πλαίσια: Angular.js[30] Ember.js[31] Backbone.js[32] Knockout.js [33] Ένα άλλο σημαντικό κομμάτι αυτής της κατηγορίας αποτελούν οι generators που βοηθούν στην δημιουργία του σκελετού μιας εφαρμογής βασισμένης σε κάποιο από τα προαναφερθέντα πλαίσια παρέχοντας έτοιμη δομή της εφαρμογής και κομμάτια πολυχρησιμοποιούμενου (boilerplate) κώδικα. Μεγάλο φάσμα generators μπορεί να βρεθεί μέσω των εργαλείων : Yeoman [34] Slush [35] Ολοκληρωμένες εφαρμογές διεπαφής χρήστη για την κατανάλωση και αξιοποίηση REST API. Σε αυτήν την κατηγορία ανήκουν οι εφαρμογές που δέχονται σαν είσοδο την οντολογία του API και εφαρμόζοντας την στον ήδη υλοποιημένο κώδικα, γραμμένο σε java ή JavaScript, παρέχουν μια εφαρμογή έτοιμη για χρήση ή έλεγχο του API. Παραδείγματα τέτοιων εφαρμογών είναι: ngadmin [36] LightAdmin [37] Η προτεινόμενη εφαρμογή από την παρούσα διπλωματική εργασία

33 Θεωρητικό και τεχνολογικό υπόβαθρο Διαφορά προτεινόμενης εφαρμογής από τις υπάρχουσες τεχνολογίες Η εφαρμογή που προτείνεται στην παρούσα διπλωματική ανήκει μεν στη τελευταία κατηγορία, έχει όμως κάποιες διαφοροποιήσεις που την καθιστούν πιο ευέλικτη στη χρήση, καθώς συνδυάζει στοιχεία και από άλλες κατηγορίες. Αρχικά είναι υλοποιημένη σε ένα JavaScript framework, συγκεκριμένα σε Angular Js, και είναι εύκολα διαμορφώσιμη, παρέχοντας στον προγραμματιστή όλες τις δυνατότητες που προσφέρει η Angular Js. Παρόλα αυτά είναι δομημένη με τέτοιο τρόπο που μπορεί να λειτουργήσει πλήρως, δίχως καμία παρέμβαση στον κώδικα με μοναδική απαίτηση την δημιουργία ενός αρχείου που περιέχει την οντολογία του REST API, εύκολα κατανοητού και εύκολα συντάξιμου. Η προτεινόμενη εφαρμογή αποτελεί μια ολοκληρωμένη διεπαφή χρήστη και η χρήση της δεν απαιτεί κάποια γνώση για υλοποίηση frontend client. Μπορεί να χρησιμοποιηθεί για τον έλεγχο λειτουργίας ενός REST API, σαν έτοιμη ιστοσελίδα λόγω της μορφής της ή σαν μια πρότυπη έκδοση εφαρμογής για παρουσίαση της λειτουργικότητας του API σε κάποιον ενδιαφερόμενο

34 Επισκόπηση Εφαρμογής 3. Επισκόπηση Εφαρμογής Η παρούσα διπλωματική εργασία αποσκοπεί στο να δημιουργήσει ένα εργαλείο αυτόματης παραγωγής ενός front-end περιβάλλοντος χρήστη για οποιαδήποτε service παράγεται από τον μηχανισμό του S-CASE ή άλλο service που βρίσκεται στο τρίτο επίπεδο ωριμότητας σύμφωνα με το Maturity Model του Richardson που έχει αναλυθεί στο θεωρητικό υπόβαθρο, με τις απαιτούμενες βέβαια, προσαρμογές στον κώδικα. Στο κεφάλαιο αυτό θα γίνει αναλυτική περιγραφή της δομής της εργασίας και της λογικής που ακολουθήθηκε για την επίτευξη του σκοπού που καλείται να φέρει εις πέρας, καθώς και των τεχνολογιών και πλαισίων που χρησιμοποιήθηκαν MVC Το πρότυπο σχεδίασης Μοντέλο - Όψη Ελεγκτής (MVC) Η αρχιτεκτονική που ακολουθεί η εφαρμογή είναι το MVC μοντέλο σχεδίασης. Κύριο χαρακτηριστικό του συγκεκριμένου μοντέλου, είναι ότι χωρίζεται η εφαρμογή σε τρία διαφορετικά υποσυστήματα. Το Μοντέλο, την Όψη και τον Ελεγκτή. Κάθε ένα από αυτά, λειτουργεί αυτόνομα αλλά επικοινωνεί με τα υπόλοιπα δυο υποσυστήματα. Το Μοντέλο (Model) Το Μοντέλο είναι υπεύθυνο για τη συσχέτιση της εφαρμογής με τη βάση δεδομένων, για τις επικυρώσεις (validations) των πεδίων που επικοινωνούν με τη βάση και γενικά εμπεριέχει όλη τη λογική διαχείρισης των δεδομένων του συστήματος. Το Μοντέλο για την εφαρμογή σχετίζεται με το Restful Web API που παράγεται από το μηχανισμό του S-CASE. Η Όψη (View) Η όψη αποτελεί τον τρόπο παρουσίασης των δεδομένων της εφαρμογής και είναι αυτή που αλληλοεπιδρά με το χρήστη. Η όψη που θα εμφανιστεί κάθε φορά, εξαρτάται από την ενέργεια

35 Επισκόπηση Εφαρμογής που θα εκτελέσει ο ελεγκτής και την επιλογή του χρήστη. Η όψη προβάλλεται στο χρήστη με τη μορφή HTML σελίδας στον browser που χρησιμοποιεί. Ο Ελεγκτής (Controller) Ο ελεγκτής αποτελεί την καρδιά του συστήματος, αυτός που καθορίζει όλη τη λειτουργικότητα της εφαρμογής. Ρόλος του είναι να επικοινωνεί με το μοντέλο στέλνοντας αιτήματα, για τις επιλογές ή τις εισόδους του χρήστη και με την όψη για να επιστρέφει τις αποκρίσεις του μοντέλου. Επίσης είναι υπεύθυνος για την οργάνωση των δεδομένων όπως αναζήτηση, κατηγοριοποίηση, σε μορφή τέτοια ώστε να ταιριάζει στις ανάγκες της προβολής. Το διάγραμμα παρουσιάζει την αρχιτεκτονική της εφαρμογής και τη σχέση των δομικών στοιχείων του MVC. Μόλις εκτελεστεί η εφαρμογή, οι ελεγκτές και όλα τα HTML αρχεία της όψης φορτώνονται στην συσκευή του χρήστη και τρέχουν αποκλειστικά σε αυτήν μειώνοντας έτσι αισθητά την ταχύτητα απόκρισης. Όλα τα αιτήματα έπειτα στέλνονται στο backend Rest Service το οποίο βρίσκεται στο server που εξυπηρετεί την εφαρμογή και τη βάση δεδομένων. Εικόνα 6 Model-View-Controller[38]

36 Επισκόπηση Εφαρμογής 3.2. S-CASE Το S-CASE παρέχει τα Web APIs που χρησιμοποιούνται σαν είσοδος στην εφαρμογή. Ο προγραμματιστής που χρησιμοποιεί την πλατφόρμα του S-CASE έχει τη δυνατότητα αυτόματης παραγωγής πηγαίου κώδικα, από φυσική γλώσσα και UML διαγράμματα, ενός έτοιμου για χρήση Restful API τρίτου επιπέδου σύμφωνα με το Richardson Maturity Model. Το API αυτό υποστηρίζει HATEOAS (Hypermedia As The Engine of Application State), δηλαδή ικανοποιεί την αρχή της Rest αρχιτεκτονικής που υπαγορεύει ότι κάθε client πρέπει να αλληλοεπιδρά με την web εφαρμογή, αποκλειστικά μέσω hypermedia που παρέχονται δυναμικά από το API του server. Παράλληλα με το API παράγεται και το σχήμα για τη βάση δεδομένων που επιλέγει ο προγραμματιστής. Ακόμη υπάρχει δυνατότητα ενσωμάτωσης ελέγχου πιστοποίησης χρηστών, εξουσιοδότησης για την χρήση συγκεκριμένων πόρων και αναζήτησης στη βάση δεδομένων [39]. Στα παρακάτω μπλόκ κώδικα μπορούμε να δούμε δύο τυπικά παραδείγματα αιτήσεων και αποκρίσεων ενός service που έχει παραχθεί από το S-CASE, συγκεκριμένα του RestReviews. Οι αποκρίσεις αυτές επιστράφηκαν έπειτα από ένα αίτημα εγγραφής (POST) ενός νέου πόρου στη βάση και ενός αιτήματος ανάκτησης (GET). Αίτημα δημιουργίας πόρου review αποστέλλοντας δεδομένα τύπου application/json στο URI: /reviews/api/product/45/review, με χρήση HTTP/1.1. POST /reviews/api/product/45/review HTTP/1.1 Host: :8080 Connection: keep-alive Content-Length: 53 Accept: application/json, text/plain, */* Origin: User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/ (KHTML, like Gecko) Chrome/ Safari/ Authorization: Basic dgvzddeyojeymzq= Content-Type: application/json;charset=utf-8 Referer:

37 Επισκόπηση Εφαρμογής Κεφαλίδα απόκρισης που περιλαμβάνει αποδοχή αιτήματος, τύπο περιεχομένου και τύπο εξυπηρετητή. HTTP/ OK Content-Type: application/json Transfer-Encoding: chunked Server: Jetty( v ) Αίτημα ανάκτησης πόρου product με δεδομένα τύπου application/json από το URI: /reviews/api/product/29, με χρήση HTTP/1.1. GET /reviews/api/product/29 HTTP/1.1 Host: :8080 Connection: keep-alive Accept: application/json, text/plain, */* User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/ (KHTML, like Gecko) Chrome/ Safari/ DNT: 1 Referer: Κεφαλίδα απόκρισης που περιλαμβάνει αποδοχή αιτήματος, τύπο περιεχομένου και τύπο εξυπηρετητή. HTTP/ OK Content-Type: application/json Transfer-Encoding: chunked Server: Jetty( v Παρακάτω εμφανίζονται τα περιεχόμενα των αποκρίσεων του εξυπηρετητή για τα δύο αιτήματα δημιουργίας και ανάκτησης, σε μορφή json αντικειμένου, που περιλαμβάνουν τα χαρακτηριστικά του πόρου και την λίστα με τις επιτρεπόμενες μελλοντικές επιλογές του χρήστη, που παρέχονται από το RESTful API

38 Επισκόπηση Εφαρμογής {"linklist":[ { "idtype":"0", "linkrel":"get all reviews of this product", "linktype":"sibling","linkuri":" "linkverb":"get" }, { "idtype":"0", "linkrel":"create a new review", "linktype":"sibling", "linkuri":" "linkverb":"post" }, {"idtype":"47","linkrel":"nice One!", "linktype":"child", "linkuri":" "linkverb":"get" }, {"idtype":"47", "linkrel":"nice One!", "linktype":"child", "linkuri":" "linkverb":"put" }, { "idtype":"47", "linkrel":"nice One!", "linktype":"child", "linkuri":" "linkverb":"delete" }, { "idtype":"0", "linkrel":"delete the parent JavaproductModel", "linktype":"parent", "linkuri":" "linkverb":"delete" }, { "idtype":"0", "linkrel":"get the parent JavaproductModel", "linktype":"parent", "linkuri":" "linkverb":"get" }, { "idtype":"0", "linkrel":"update the JavaproductModel", "linktype":"parent", "linkuri":" "linkverb":"put" }], "rating":"5", "review":"good work", "reviewid":"47", "title":"nice One!" }

39 Επισκόπηση Εφαρμογής { } "category": "Software", "description": "A kick-ass announcement notification software", "imageurl": " "linklist": [{ "idtype": "0", "linkrel": "Get the product", "linktype": "Sibling", "linkuri": " "linkverb": "GET" }, { "idtype": "0", "linkrel": "Update the product", "linktype": "Sibling", "linkuri": " "linkverb": "PUT" }, { "idtype": "0", "linkrel": "Delete the product", "linktype": "Sibling", "linkuri": " "linkverb": "DELETE" }, { "idtype": "0", "linkrel": "Get all the reviews of this product", "linktype": "Child", "linkuri": " "linkverb": "GET" }, { "idtype": "0", "linkrel": "Create a new review for this product", "linktype": "Child", "linkuri": " "linkverb": "POST" }, { "idtype": "0", "linkrel": "Create a new product", "linktype": "Parent", "linkuri": " "linkverb": "POST" }, { "idtype": "0", "linkrel": "Get all products", "linktype": "Parent", "linkuri": " "linkverb": "GET" } ], "price": "0.0", "productid": "29", "title": "Suriken"

40 Επισκόπηση Εφαρμογής Μπορεί εύκολα να παρατηρηθεί ότι οι αποκρίσεις του API ακολουθούν ένα μοτίβο. Το μοτίβο αυτό θα αναλυθεί στη συνέχεια σε μορφή πινάκων. Βάση αυτού έχει γίνει η υλοποίηση της εφαρμογής για την αυτόματη παραγωγή του γραφικού περιβάλλοντος. Περιεχόμενα απόκρισης: Περιεχόμενα Απόκρισης Χαρακτηριστικά Πόρου Υποχρεωτικό Όχι. Παρέχεται στην περίπτωση που η απόκριση αφορά συγκεκριμένο πόρο με μοναδικό ID και όχι κάποιο σύνολο αυτών. Περιγραφή Περιέχει στοιχεία του πόρου όπως όνομα, περιγραφή κ.α. ανάλογα με το είδος του πόρου και τι έχει οριστεί από το εξυπηρετούμενο service. ID πόρου Όχι. Παρέχεται στην περίπτωση που η απόκριση αφορά συγκεκριμένο πόρο με μοναδικό ID και όχι κάποιο σύνολο αυτών. Αποτελεί το αναγνωριστικό του πόρου για το service. LinkList Ναι Περιέχει τη λίστα με τις επιτρεπόμενες μελλοντικές ενέργειες του χρήστη, από την τρέχουσα κατάσταση για την περαιτέρω περιήγηση στην εφαρμογή. Πίνακας 1 Περιεχόμενα Απόκρισης API

41 Επισκόπηση Εφαρμογής Ανάλυση αντικειμένων που περιλαμβάνονται στη λίστα επιτρεπόμενων ενεργειών: Ιδιότητες του προς επιλογή αντικειμένου ID Type Περιγραφή Αποτελεί το αναγνωριστικό του πόρου για το service. Εκλαμβανόμενες τιμές ιδιότητας 0: αν πρόκειται για επιλογή συνόλου πόρων (πχ get all children of this resource) ID number : αν πρόκειται για συγκεκριμένο πόρο linkrel Περιγραφή σε φυσική γλώσσα της επιλεγόμενης ενέργειας Για παράδειγμα : Get all children of this resource/ Create a new resource / Update / Delete this resource linktype Σχέση του επιλεγόμενου πόρου με τον τρέχοντα στο service Λαμβάνει τις τιμές : Parent/ Sibling / Child linkuri Περιέχει το URI του προς επιλογή πόρου Τα URI είναι της μορφής : <servername> / <apiname> / <resourcename> / <resourceid> / <childname> / <childid> / linkverb Περιέχει το είδος της HTTP μεθόδου Λαμβάνει τις τιμές : GET/PUT/POST/DELETE Πίνακας 2 Περιεχόμενα Λίστας Επιλογών

42 Επισκόπηση Εφαρμογής 3.3. Angular JS Η Angular JS είναι ένα framework διανομής της Google, υλοποιημένο αποκλειστικά σε JavaScript, που ακολουθεί την MVC αρχιτεκτονική για την ανάπτυξη διαδικτυακών εφαρμογών και εφαρμογών κινητών τηλεφώνων. Ανήκει στην κατηγορία των client-side JavaScript frameworks, που σημαίνει ότι το φόρτο εργασίας μεταφέρεται στον καταναλωτή και εκτελείται από το υλισμικό του, ελαφρύνοντας έτσι την τον κύκλο εργασιών του εξυπηρετητή και κάνοντας τις διαδικτυακές εφαρμογές ταχύτερες και ευκολότερα επεκτάσιμες. Χαρακτηρίζεται για την απλότητα της και τις δυνατότητες που παρέχει, σε συνδυασμό με την jquery και το Bootstrap προσφέρει όλα τα εργαλεία για την ανάπτυξη front-end εφαρμογών που χρησιμοποιούν REST web services σαν back-end. Επίσης διακρίνεται για την αρκετά μεγάλη κοινότητα χρηστών που διαθέτει και τα λεπτομερή εγχειρίδια χρήσης, διευκολύνοντας έτσι τον προγραμματιστή. Τα πλεονεκτήματα του Angular Js framework [40], συνοψίζονται παρακάτω: Η Angular Js παρέχει έτοιμες βιβλιοθήκες και μεθόδους, οι οποίες ενσωματώνουν πολύπλοκες λειτουργίες, τις οποίες, σε διαφορετική περίπτωση, θα έπρεπε να κατασκευάσει ο προγραμματιστής. Μια εφαρμογή σε Angular Js χρειάζεται λιγότερες γραμμές κώδικα σε σχέση με την αντίστοιχη υλοποίηση με απλή javascript που κάνει χρήση άλλων βιβλιοθηκών. 'Ενα μεγάλο ποσοστό της λογικής ελέγχου, μπορεί πλέον να απεμπλακεί από τον υπόλοιπο κώδικα και να ενσωματωθεί σε ανεξάρτητες, επαναχρησιμοποιήσιμες οντότητες κώδικα (reusable components). Το Angular Js framework δίνει τη δυνατότητα δημιουργίας νέων αντικειμένων HTML elements με τη χρήση των directives. Η χρήση της Angular Js δεν είναι δεσμευτική και μπορεί κάλλιστα να συνυπάρξει με άλλες βιβλιοθήκες και τεχνολογίες

43 Επισκόπηση Εφαρμογής Χαρακτηριστικά της Angular Js Single-Page Εφαρμογές [41] [42]Η Angular Js χρησιμοποιείται κυρίως για την ανάπτυξη εφαρμογών μια σελίδας (Single- Page). Οι εφαρμογές μιας σελίδας έχουν μία μόνο HTML σελίδα πρόσβασης και όλο το περιεχόμενο της εφαρμογής φορτώνεται και αφαιρείται δυναμικά, όπου υπάρχει η ετικέτα ngview στον κώδικα. Καθώς ο χρήστης επιλέγει να ακολουθήσει συνδέσμους μέσα στην εφαρμογή το προβαλλόμενο περιεχόμενο αφαιρείται και το νέο επισυνάπτεται δυναμικά στην ετικέτα καταλαμβάνοντας την θέση του προηγούμενου, χωρίς να χρειάζεται να φορτωθεί εκ νέου μια άλλη HTML σελίδα. Angular Routes και Templates Οι διαδρομές (routes) προσφέρονται από το ngroute τμήμα της Angular Js και εξυπηρετούν την ανάγκη αλλαγής όψεων της εφαρμογής. Φορτώνονται με την εκκίνηση της εφαρμογής και συνδέονται με υπερσυνδέσμους για προβάλουν το περιεχόμενο που επισυνάπτεται στην ngview ετικέτα. Κάθε διαδρομή αναπαρίσταται από την επέκταση που προστίθεται στο URL της εφαρμογής, για παράδειγμα το URL: θα εμφάνιζε την κύρια σελίδα της εφαρμογής ενώ το θα εμφάνιζε το περιεχόμενο της σελίδας που αφορά την προβολή ενός πόρου. Επίσης κάθε διαδρομή είναι συνδεδεμένη με ένα Template δηλαδή μια σελίδα που περιέχει το HTML περιεχόμενο που πρόκειται να εμφανιστεί και έναν ελεγκτή. Στο παρακάτω παράδειγμα κώδικα μπορούμε να δούμε πως ορίζονται οι διαδρομές για μια υποθετική εφαρμογή. Angular Controllers Οι ελεγκτές στην Angular Js είναι το επίπεδο αναπαράστασης της λογικής του συστήματος, το οποίο εκτελεί τις λειτουργίες, που τροποποιούν το μοντέλο δεδομένων και το συνδέουν με το γραφικό περιβάλλον. Είναι υπεύθυνοι για όλη την λειτουργικότητα της εφαρμογής που συνδέεται με τις όψεις και δεν μπορεί να ολοκληρωθεί στο back-end REST service. Ο χρήστης αλληλεπιδρά με το γραφικό περιβάλλον της διεπαφής, και έμμεσα καλεί μεθόδους του controller, ο οποίος με τη σειρά του τροποποιεί το μοντέλο και ανανεώνει τα περιεχόμενα του view σε σχέση με τις αλλαγές

44 Επισκόπηση Εφαρμογής myapp.config(['$routeprovider', '$locationprovider', function($routeprovider, $locationprovider){ $routeprovider. when('/', { templateurl: 'partials/main.html', controller: 'MainCtrl' }). when('/show', { templateurl: 'partials/view.html', controller: 'ViewCtrl' }); 3.4. Bootstrap Το Bootstrap αποτελεί το δημοφιλέστερο HTML, CSS και JavaScript framework για την ανάπτυξη αποκρίσιμων ιστοσελίδων. Παρέχει μια μεγάλη ποικιλία διαθέσιμων υλοποιημένων χαρακτηριστικών και προτύπων ιστοσελίδων. Το bootstrap είναι συμβατό με όλους τους browsers και κλιμακώνει αποτελεσματικά το μέγεθος και τη δομή της ιστοσελίδας στην οποία εφαρμόζεται και έτσι καθίσταται εφικτή η χρήση της από κάθε είδους συσκευή[43] Yaml Η Yaml είναι μια γλώσσα επισκόπησης δομών δεδομένων μίας εφαρμογής. Αποτελεί ένα πρότυπο παρουσίασης δεδομένων εύκολα κατανοητό από τον άνθρωπο και συμβατό με τις περισσότερες γλώσσες προγραμματισμού[44]. Έχει επιλεγεί στην παρούσα διπλωματική για τον ορισμό των αρχείων που θα παρέχουν πληροφορίες στην εφαρμογή για τα χαρακτηριστικά των πόρων του εκτελούμενου service. Ένα αρχείο Yaml μπορεί εύκολα να συνταχθεί από τον προγραμματιστή που υλοποιεί το Web service ή να παραχθεί αυτόματα από την πλατφόρμα που χρησιμοποιεί. Σκοπός των αρχείων αυτών στην διπλωματική εργασία είναι να καλύψουν την ανάγκη για γνώση των χαρακτηριστικών και των ιδιοτήτων των πόρων του εκάστοτε service εκ των προτέρων. Οι πληροφορίες αυτές είναι απαραίτητες ώστε η εφαρμογή να είναι ικανή να παραγάγει αυτόματα

45 Επισκόπηση Εφαρμογής το γραφικό περιβάλλον διεπαφής χρήστη, χωρίς να απαιτείται ο χρήστης ή ο προγραμματιστής να επέμβει και να διαμορφώσει καθόλου στον κώδικα. Τα χαρακτηριστικά που πρέπει να περιέχει, μεταξύ άλλων, το αντικείμενο που περιγράφει κάθε πόρο του service στο Yaml αρχείο είναι: Πεδία Αντικειμένου Περιγραφής Πόρου Το αναγνωριστικό του service που διαχωρίζει τους πόρους μεταξύ τους Επιτρεπόμενες Τιμές Αποτελεί την γραμμή στα πεδία περιγραφής του πόρου και μπορεί να έχει τη μορφή : -!!eu.fp7.scase.inputparser.yamlresource ή -!!service.name Resource Name Το όνομα του πόρου CRUDActivities Περιλαμβάνει συνδυασμό των Create, Read, Update, Delete HasEmbeddedObjects Λαμβάνει τις τιμές true ή false. Ενημερώνει την εφαρμογή εάν υπάρχει κάποιο χαρακτηριστικό του πόρου που δεν αποτελεί κάποιον βασικό τύπο όπως κείμενο, αριθμό, ημερομηνία ή και για να ενσωματωθεί το περιεχόμενο στην προβολή του πόρου απαιτείται κάποια συγκεκριμένη ενέργεια. EmbeddedType Εάν η τιμή του HasEmbeddedObjects είναι false τότε δεν εκχωρείται τιμή. Στην αντίθετη περίπτωση λαμβάνει μια τιμή εκ των : image, video, map, code εάν πρόκειται για εικόνα, βίντεο, σημείο στο χάρτη ή κάποιο αρχείο κώδικα αντίστοιχα. EmbeddedProperty Εάν η τιμή του HasEmbeddedObjects είναι false τότε δεν εκχωρείται τιμή. Στην αντίθετη περίπτωση η τιμή του αντιστοιχεί στο χαρακτηριστικό για το οποίο απαιτείται η ενσωμάτωση της προβολής του

46 Επισκόπηση Εφαρμογής Properties Αποτελεί τον πίνακα των χαρακτηριστικών του πόρου και των ιδιοτήτων τους. Κάθε χαρακτηριστικό διαχωρίζεται από τα άλλα με μια παύλα ( - ) πριν το όνομά του. RelatedResources Περιέχει τη λίστα με τους πόρους με τους οποίους υπάρχει συσχέτιση. Πίνακας 3 Περιεχόμενα αρχείου YAML Τα πεδία που ορίζουν κάθε χαρακτηριστικό του πόρου είναι : Πεδία ιδιοτήτων Χαρακτηριστικού Name Επιτρεπόμενες τιμές Όνομα του χαρακτηριστικού του πόρου Type Τύπος του χαρακτηριστικού. Μπορεί να λάβει σαν τιμή οποιονδήποτε βασικό τύπο όπως string, textarea, number, , date. Αν πρόκειται για κάποιον από τους ιδιαίτερους τύπους που αναφέρθηκαν παραπάνω τότε ο τύπος την τιμή string καθώς η τιμή του χαρακτηριστικού είναι στην ουσία ο σύνδεσμος για το που είναι αποθηκευμένο το αρχείο. Required Λαμβάνει τις τιμές true ή false ανάλογα με το αν το χαρακτηριστικό είναι απαιτούμενο για να δημιουργηθεί ο πόρος. Unique NamingProperty Λαμβάνει τις τιμές true ή false ανάλογα με το αν επιτρέπεται από το service να υπάρχουν περισσότεροι του ενός πόροι που μπορούν να έχουν το ίδιο χαρακτηριστικό. Για παράδειγμα θα λαμβάνει την τιμή true εάν πρόκειται για το username ενός χρήστη του συστήματος ενώ false για τον κωδικό πρόσβασης του. Λαμβάνει τις τιμές true ή false ανάλογα με το αν το χαρακτηριστικό αυτό αποτελεί και το όνομα του πόρου

47 Επισκόπηση Εφαρμογής Πίνακας 4 Χαρακτηριστικά Πόρου στο αρχείο YAML -!!eu.fp7.scase.inputparser.yamlresource Name: Resource Name IsAlgorithmic: false CRUDActivities: [Create, Read, Update, Delete] HasEmbeddedObjects: true EmbeddedType: image EmbeddedProperty: Property_2 Properties: - Name: Property_1 Type: String Required: true Unique: true NamingProperty: true - Name: Property_2 Type: String Required: true Unique: false NamingProperty: false - Name: Property_3 Type: String Required: false Unique: false NamingProperty: false - Name: Property_4 Type: String Required: false Unique: false NamingProperty: false RelatedResources: [Other resources] -!!eu.fp7.scase.inputparser.yamlresource Name: Other Resource Name IsAlgorithmic: false CRUDActivities: [Create, Read, Update, Delete] HasEmbeddedObjects: false EmbeddedType: EmbeddedProperty: Properties: - Name:Other Property_1 Type: String Required: true Unique: true NamingProperty: true - Name: Other Property_2 Type: Number Unique: false NamingProperty: false - Name: Other Property_3 Type: Date Unique: false NamingProperty: false - Name: Other Property_4 Type: Unique: false NamingProperty: false RelatedResources: [ ] Παρατίθεται ένα πρότυπο αρχείου yaml που έχει σχεδιαστεί για να πληροί τις ανάγκες της εφαρμογής. Στο πρότυπο βλέπουμε παραδείγματα περιγραφής δύο υποθετικών πόρων ενός API

48 Επισκόπηση Εφαρμογής 3.6. Δομή εφαρμογής Στη συνέχεια, αφού αναλύσαμε τις εισόδους και τη μορφή του, την αρχιτεκτονική που ακολουθήθηκε και τα εργαλεία που χρησιμοποιήθηκαν, θα εξετάσουμε τμηματικά πως σχεδιάστηκε και αναπτύχθηκε η εφαρμογή που προτείνεται στην παρούσα διπλωματική. Η εφαρμογή αποτελείται από 4 όψεις υλοποιημένες σε HTML και μορφοποιημένες με το Bootstrap, τις Main, View, Edit και SignIn 4 ελεγκτές (Angular Controllers) γραμμένους σε Angular Js και plain JavaScript, τους MainCtrl, ViewCtrl, EditCtrl και SignInCtrl που θα αναλυθούν στη συνέχεια 2 υπηρεσίες (services) για τον διαμοιρασμό πληροφοριών και δεδομένων ανάμεσα στους ελεγκτές, την CurrentObject που περιέχει τις πληροφορίες για τον τρέχοντα πόρο και την SignIn που περιέχει τα τεκμήρια εισόδου του χρήστη και δημιουργεί τις κεφαλίδες που στέλνονται μαζί με τα αιτήματα 1 υπηρεσία για την ανάγνωση και επεξεργασία των πληροφοριών για τους πόρους του RESTful API από τα yaml αρχεία τη YamlParse που αναλύεται παρακάτω 1 αρχείο για την αρχικοποίηση της εφαρμογής το conf.js που περιέχει τις σταθερές της εφαρμογής όπως αυτές ορίζονται από τον προγραμματιστή που την χρησιμοποιεί Ανάλυση και επεξεργασία εισόδων στην εφαρμογή. Όπως έχει ήδη αναφερθεί η εφαρμογή δέχεται δύο εισόδους, το αρχείο yaml και το επιστρεφόμενο json αντικείμενο από τις αποκρίσεις του RESTful API στα HTTP αιτήματα YamlParse service Για την ανάλυση του αρχείου yaml έχει αναπτυχθεί μια υπηρεσία με τρεις μεθόδους που επεξεργάζονται την πληροφορία και την καθίσουν αναγνώσιμη για την υπόλοιπη εφαρμογή. Η διαδικασία της ανάλυσης εκτελείται πρώτη με την εκκίνηση της εφαρμογής αφού φορτωθούν

49 Επισκόπηση Εφαρμογής οι βιβλιοθήκες και γίνει ο αυτόματος έλεγχος από την Angular για την ορθή λειτουργία. Βασίζεται στο μοτίβο που αναφέρθηκε στην προηγούμενη ενότητα και είναι η εξής : Αρχικά λαμβάνεται όλο το περιεχόμενο σαν μια ακολουθία χαρακτήρων. Κάθε φορά που συναντάται η χαρακτηριστική φράση που δηλώνει την αρχή της περιγραφής νέου πόρου, δημιουργείται ένα αντικείμενο που περιέχει τις πληροφορίες για τα χαρακτηριστικά του πόρου και τις ιδιότητες τους βάση της δομής που έχει ήδη αναλυθεί. Κάθε αντικείμενο αποθηκεύεται σε ένα πίνακα μαζί με τα υπόλοιπα, ο οποίος αφού ολοκληρωθεί η διαδικασία μετατρέπεται σε μορφή json με χρήση της συνάρτησης JSON.parse(). Σε αυτόν τον πίνακα ανατρέχει κάθε ελεγκτής της εφαρμογής όταν γνωρίζει τον τρέχοντα πόρο και χρειάζεται να εμφανίσει ή να επεξεργαστεί τα χαρακτηριστικά του. Είναι απαραίτητος για την δημιουργία των πινάκων που περιέχουν τα χαρακτηριστικά του πόρου στις όψεις και για τη δημιουργία των φορμών εγγραφής ή ανανέωσης ενός πόρου Έλεγχοι εισόδων Η εφαρμογή αναπτύσσεται στο υπολογιστικό σύστημα του χρήστη με πλήρως δυναμικό τρόπο. Αυτό σημαίνει ότι όλα τα δεδομένα, εκτός από τα στοιχεία ταυτοποίησης του χρήστη, χρησιμοποιούνται προσωρινά και έπειτα διαγράφονται από τη μνήμη για να δώσουν την θέση τους στα επόμενα. Έτσι σε κάθε βήμα πραγματοποιείται ένας έλεγχος για να αποφασιστεί σε ποιον ελεγκτή θα ανατρέξει η εφαρμογή και στη συνέχεια ο ελεγκτής πραγματοποιεί τους απαραίτητους ελέγχους για να δημιουργήσει τις δομές των δεδομένων που θα εμφανιστούν στις όψεις. Ο κάθε επιλεγόμενος πόρος αποθηκεύεται ως τρέχοντας σαν γενική μεταβλητή του συστήματος μέσω της αντίστοιχης υπηρεσίας που έχει αναπτυχθεί ώστε να είναι προσπελάσιμος από όλους τους ελεγκτές. Όπως έχει προαναφερθεί κάθε δυνατή επιλογή που έχει ο χρήστης συνοδεύεται από κάποια χαρακτηριστικά που χρησιμοποιούνται για τους απαραίτητους ελέγχους. Τα χαρακτηριστικά αυτά είναι το URI του πόρου, το HTTP Verb και αφού επιλεγεί υπάρχει η λίστα με τις μελλοντικές

50 Επισκόπηση Εφαρμογής επιτρεπόμενες ενέργειες από το παρόν στάδιο. Θα αναφερθούν οι έλεγχοι των εισόδων και στη συνέχεια θα αντιστοιχηθούν με τους ελεγκτές που τους εκτελούν. Επιλογή ελεγκτή. Ο έλεγχος επιλογής ελεγκτή καλείται με την επιλογή του πόρου από το χρήστη και βασίζεται στην HTTP μέθοδο που συνοδεύει την επιλογή. Αν η μέθοδος είναι GET τότε ελέγχεται μέσω του παρεχόμενου URI αν πρόκειται για έναν συγκεκριμένο πόρο ή για σύνολο και επιλέγεται ο ελεγκτής ViewCtrl που αφορά την παρουσίαση των χαρακτηριστικών του πόρου ή ο ελεγκτής MainCtrl που αφορά την παρουσίαση του συνόλου, αντίστοιχα. Εάν η μέθοδος είναι PUT ή POST επιλέγεται ο ελεγκτής editctrl που είναι υπεύθυνος για την δημιουργία φορμών και εκτέλεση αντίστοιχων αιτημάτων. Τέλος για τη μέθοδο DELETE δεν απαιτείται αλλαγή ελεγκτή αλλά ο ελεγκτής που εξυπηρετεί εκείνη τη στιγμή την εφαρμογή εμφανίζει ένα μήνυμα επιβεβαίωσης διαγραφής και έπειτα εκτελεί το αίτημα. Εύρεση χαρακτηριστικών πόρου Ο έλεγχος εύρεσης χαρακτηριστικών πόρου βασίζεται στο μοτίβο του URI που υποδεικνύει το να υπάρχει το όνομα και τα ID του πόρου στο τέλος της ακολουθίας χαρακτήρων που το απαρτίζουν. Έτσι εφόσον βρεθεί το όνομα του πόρου πραγματοποιείται μια προσπέλαση και αναζήτηση του ομώνυμου αντικειμένου στον πίνακα που έχει προκύψει από την υπηρεσία YamlParse, τα περιεχόμενα του οποίου αντιγράφονται στον ελεγκτή. Αναζήτηση χαρακτηριστικού που απαιτεί ενσωμάτωση Ο έλεγχος για ενσωμάτωση προβολής αντικειμένου εκτελείται με παρόμοιο τρόπο με αυτόν για την εύρεση χαρακτηριστικών. Δηλαδή γίνεται αναζήτηση στον πίνακα από τη YamlParse για ομώνυμο αντικείμενο και όταν βρεθεί ελέγχονται οι ιδιότητες HasΕmbeddedObjects, ΕmbeddedType και ΕmbeddedProperty οι τιμές τους εκχωρούνται σε κατάλληλες μεταβλητές στον ελεγκτή

51 Επισκόπηση Εφαρμογής Λίστα επιλογών Ο έλεγχος για τη λίστα επιτρεπόμενων επιλογών γίνεται μετά το κάθε αίτημα προς το API. Στο αντικείμενο που επιστρέφεται συμπεριλαμβάνεται το χαρακτηριστικό linklist που εκχωρείται σε κατάλληλη μεταβλητή στον εκάστοτε ελεγκτή. Εύρεση παιδιών πόρου Από τη λίστα που επιστρέφεται αναζητούνται όλες οι επιλογές που στο χαρακτηριστικό linktype έχουν την τιμή child και εκχωρούνται σε κατάλληλο πίνακα στον ελεγκτή. Εύρεση προηγούμενης κατάστασης Πραγματοποιείται έλεγχος στην λίστα του επιστρεφόμενου αντικειμένου για τον άμεσο γονέα του πόρου ή εάν δεν εφικτό ο ελεγκτής ανατρέχει στο αντικείμενο που στο οποίο έχει εκχωρηθεί ο αμέσως προηγούμενος πόρος. Αυτή η διαδικασία συμβαίνει για να καλύπτεται η περίπτωση που ο χρήστης δεν επιλέξει μία από τις επιλογές που υπάρχουν στη λίστα περισσότερων επιλογών ή θέλει να ακυρώσει την τροποποίηση ή δημιουργία πόρου και επιθυμεί να επιστρέψει στην προηγούμενη κατάσταση Λειτουργεία ελεγκτών Main Controller Ο ελεγκτής αυτός έχει επιλεγεί να είναι ο πρώτος που εκτελείται όταν φορτώνεται το σύστημα. Είναι υπεύθυνος για την εμφάνιση των επιλογών του χρήστη χωρισμένες σε δύο κατηγορίες και την εκτέλεση των αιτημάτων που επιλέγει στο API. Η πρώτη κατηγορία είναι η λίστα των παιδιών του κύριου πόρου του API, ή σε οποιαδήποτε άλλη περίπτωση χρειάζεται να εμφανιστεί στο χρήστη ένα σύνολο πόρων για να επιλέξει. Σε αυτήν την περίπτωση εκτελεί τον έλεγχο εύρεσης παιδιών. Η δεύτερη είναι η επίδειξη του συνόλου της λειτουργικότητας του API στο χρήστη στο τρέχον στάδιο της εφαρμογής, μέσα από τη λίστα περισσότερων επιλογών. Σε αυτήν την περίπτωση εκτελεί τους ελέγχους λίστας επιλογών και εύρεσης επόμενου ελεγκτή. Ο συγκεκριμένος ελεγκτής εξυπηρετεί την όψη Main

52 Επισκόπηση Εφαρμογής View Controller Πρόκειται για τον ελεγκτή που είναι υπεύθυνος για την προβολή των λεπτομερειών του τρέχοντος πόρου και την εκτέλεση των αιτημάτων που επιλέγει ο χρήστης στο API. Εκτελεί τους ελέγχους εύρεσης χαρακτηριστικών πόρου και αναζήτησης χαρακτηριστικού που απαιτεί ενσωμάτωση, συγκρίνει τα αποτελέσματα με την απόκριση του API και δημιουργεί τα αντικείμενα προς προβολή. Στη συνέχεια αναλαμβάνει μέσω του ελέγχου εύρεσης παιδιών να δημιουργήσει τις λίστες των παιδιών και αν υπάρχουν περισσότερες από μία κατηγορίες παιδιών, να τα χωρίσει ανάλογα με το είδος τους. Και αυτός ο ελεγκτής έχει αρμοδιότητα για την επίδειξη του συνόλου της λειτουργικότητας του API στο χρήστη στο τρέχον στάδιο της εφαρμογής, κάτι που επιτυγχάνεται μέσα από τη λίστα περισσότερων επιλογών. Για αυτό το σκοπό εκτελεί τους ελέγχους λίστας επιλογών και εύρεσης επόμενου ελεγκτή. Για να δίνει την δυνατότητα επιστροφής στο χρήστη εκτελεί τον έλεγχο εύρεσης προηγούμενης κατάστασης. Ο συγκεκριμένος ελεγκτής εξυπηρετεί την όψη View. Edit Controller Πρόκειται για τον ελεγκτή που είναι υπεύθυνος για την δημιουργία νέων πόρων ή την τροποποίηση υπάρχοντων. Ο ελεγκτής αναλαμβάνει να δημιουργήσει τις φόρμες που απαιτούνται για την κάθε ενέργεια, εκτελεί τον έλεγχο εύρεσης χαρακτηριστικών πόρου συγκρίνει τα αποτελέσματα με την απόκριση του API και δημιουργεί τα αντικείμενα προς προβολή, δηλαδή τα πεδία της φόρμας, και επιλέγει τον είδος του αιτήματος που θα αποσταλεί και στο οποίο θα ενσωματωθεί η φόρμα. Επίσης εκτελεί τον έλεγχο αναζήτησης χαρακτηριστικού που απαιτεί ενσωμάτωση, για να εμφανίσει το απαραίτητο μήνυμα με τις οδηγίες συμπλήρωσης του πεδίο στη φόρμα, για το χαρακτηριστικό αυτό. Για να δώσει στο χρήστη την δυνατότητα ακύρωσης υποβολής και επιστροφής, εκτελεί τον έλεγχο εύρεσης προηγούμενης κατάστασης. Ο συγκεκριμένος ελεγκτής εξυπηρετεί την όψη Edit. SignIn Controller Ο συγκεκριμένος ελεγκτής αναλαμβάνει να ταυτοποίησει τον χρήστη της εφαρμογής και κατ επέκταση του API στέλνοντας το κατάλληλο αίτημα σε αυτό. Αν ο χρήστης δεν είναι ήδη

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

54 Επισκόπηση Εφαρμογής 3.7. Αρχικοποίηση εφαρμογής Σε αυτήν την παράγραφο θα παρουσιαστούν τα βήματα που απαιτούνται για να τεθεί σε λειτουργία η εφαρμογή. Για τον έλεγχο λειτουργείας της εφαρμογής δοκιμάστηκαν διάφορα APIs που έχουν αναπτυχθεί από το S-CASE, όπως το RestMarks, RestReviews, e-bucks, μερικά από τα Web APIs που υλοποιήθηκαν σε hackathon για το S-CASE, το wapoadmintollapi που αποτελεί ένα δοκιμαστικό service της πλατφόρμας wapo.io. Οι βάσεις δεδομένων που χρησιμοποιήθηκαν ήταν η PostgreSql και η MySQL και η επιλογή τους εξαρτιόταν από το πώς είχε υλοποιηθεί το API. Ακόμη για την εξυπηρέτηση των APIs και της εφαρμογής χρησιμοποιήθηκαν διάφοροι server, όπως Apache Tomcat, npm http-server και ο Wamp Apache server τοπικά, ενώ απομακρυσμένα μέσω σύνδεση στο διαδίκτυο ο Jetty server του εργαστηρίου που φιλοξενούσε διάφορα APIs που δοκιμάστηκαν στα πλαίσια της εκπόνησης της διπλωματικής. Ο προγραμματιστής που υλοποιεί το Web API μπορεί να επιλέξει όποιον server ή βάση δεδομένων τον εξυπηρετεί ή είναι εξοικειωμένος καλύτερα και να ενσωματώσει σε αυτά την εφαρμογή για να την θέσει σε λειτουργία. Συνεχίζοντας θα αναφερθούν τα βήματα που απαιτούνται για να τεθεί σε λειτουργία η εφαρμογή. Αρχικά επιλέγεται ο server, έστω ότι το API θα τρέχει τοπικά σε έναν Apache Tomcat. Έπειτα πρέπει το.war αρχείο που περιέχει το υλοποιημένο API να κατατεθεί στον server. Για να επιτευχθεί αυτό είτε τοποθετείται το αρχείο στον φάκελο webapps του Tomcat και η διαδικασία της αποσυμπίεσης του αρχείου και η εκτέλεση του γίνεται αυτόματα, είτε από τον browser μεταβαίνοντας στη διεύθυνση localhost:8080 επιλέγουμε Manager Apps και στην επιλογή deploy war file to server επιλέγουμε το αρχείο. Το υλοποιημένο API στον server έχει σχεδιαστεί για να επικοινωνεί με μια συγκεκριμένη βάση δεδομένων και έστω ότι υλοποιείται σε PostgreSQL. Για να αποκτήσει το API πρόσβαση στη βάση δεδομένων και να μπορεί να αποστέλλει τα αιτήματα, προφανώς η βάση πρέπει να τεθεί σε λειτουργία στην ίδια πόρτα που θα αναζητήσει το API και τα στοιχεία πρόσβασης στην βάση πρέπει να καταγραφούν στο αρχείο hibernate.cfg.xml που βρίσκεται στο φάκελο WEB-INF\classes του API στο server

55 Επισκόπηση Εφαρμογής Το API είναι πλέον σε λειτουργεία, το επόμενο βήμα της διαδικασίας είναι να τοποθετηθεί ο κώδικας της εφαρμογής στον server και να παραμετροποιηθεί για τις ανάγκες του API. Η διαδικασία περιλαμβάνει πρώτον την σύνταξη του αρχείου Yaml με τον τρόπο που ορίστηκε σε προηγούμενο κεφάλαιο και την τοποθέτηση του στο φάκελο yaml που περιέχεται στη δομή της εφαρμογής. Στη συνέχεια πρέπει να συμπληρωθεί το αρχείο conf.js που περιέχει τις σταθερές που διαμορφώνουν την εφαρμογή. Συγκεκριμένα στο αρχείο πρέπει να συμπληρωθούν τα baseurl: η σταθερά συμπληρώνεται με το URI του βασικού πόρου του API. signinurl: η σταθερά συμπληρώνεται με το URI στο οποίο αποστέλλεται το αίτημα εισόδου στο σύστημα ή εγγραφής νέου χρήστη. Αν το API δεν περιλαμβάνει διαδικασία ταυτοποίησης και εξουσιοδότησης χρηστών, μπορεί να παραληφθεί. yamlpath: η σταθερά προσδιορίζει τη θέση του αρχείου yaml. servicename: η σταθερά συμπληρώνεται με το όνομα του service. Η εφαρμογή πλέον έχει οριστεί πλήρως, είναι έτοιμη να τεθεί σε λειτουργία και να παρέχει μια πλήρως λειτουργική διεπαφή χρήστη για το API. Start Server Deploy API to server Start Database Place yaml file to yaml folder Create Yaml file Give the API access to database Fill in the conf.js file The application is ready to use Εικόνα 8 Προετοιμασία εφαρμογής

56 Σενάριο χρήσης εφαρμογής και ανάλυση όψεων 4. Σενάριο χρήσης εφαρμογής και ανάλυση όψεων Σε αυτήν την παράγραφο θα παρουσιαστεί ένα τυπικό σενάριο χρήσης της εφαρμογής για να παρουσιαστεί η διαθέσιμη λειτουργικότητα. Παράλληλα θα αναλύεται κάθε όψη που θα προβληθεί. Για την προβολή και επεξεργασία των δεδομένων από το χρήστη έχουν σχεδιαστεί δύο είδη προτύπων όψεων ώστε να υπάρχει δυνατότητα επιλογής από τον προγραμματιστή αυτού που ταιριάζει περισσότερο στις ανάγκες του web API. Επίσης με αυτόν τον τρόπο φαίνεται η διακριτή φύση των στοιχείων της εφαρμογής, δηλαδή ότι οι ελεγκτές λειτουργούν αυτόνομα από τις όψεις και ότι υπάρχει δυνατότητα παρέμβασης στο σύνολο τους ή σε μέρος αυτού. Το πρώτο πρότυπο μοιάζει περισσότερο με ιστοσελίδα, ενώ το δεύτερο με πίνακα διαχείρισης. Για την επίδειξη της λειτουργικότητας της εφαρμογής θα χρησιμοποιηθεί το πρώτο πρότυπο και το REST API RestReviews που έχει παραχθεί από την πλατφόρμα του S-CASE, ενώ το δεύτερο πρότυπο θα παρουσιαστεί συνοπτικά καθώς οι λειτουργίες που ενσωματώνει είναι πανομοιότυπες με αυτές του πρώτου. Το RestReviews πρόκειται για μια εφαρμογή που αποτελείται από μια βάση χρηστών και μία βάση προϊόντων. Όποιος έχει πρόσβαση στο RestReviews έχει το δικαίωμα να περιηγηθεί στην εφαρμογή, να επιλέξει κάποιο προϊόν για να δει τα χαρακτηριστικά του και τις κριτικές που έχει λάβει, ή να δημιουργήσει ένα λογαριασμό χρήστη και έχει τη δυνατότητα να προσθήκης ή τροποποίησης προϊόντων και κριτικών Κύρια οθόνη διεπαφής Η κύρια οθόνη είναι αυτή που παρουσιάζεται στο χρήστη όταν μεταβεί στην εφαρμογή. Αντιστοιχεί στον κύριο πόρο του API και προβάλει την λίστα των παιδιών του, εμφανίζοντας τις φωτογραφίες τους αν υπάρχουν και δίνοντας στο χρήστη τη δυνατότητα να επιλέξει ένα από αυτά για να δει τις λεπτομέρειες του. Στην κύρια μπάρα στο πάνω μέρος υπάρχουν τρία κουμπιά-σύνδεσμοι που αντιστοιχούν από αριστερά προς τα δεξιά, το πρώτο για επιστροφή στην αρχική οθόνη, το δεύτερο για εμφάνιση των υπόλοιπων επιτρεπόμενων επιλογών του χρήστη και το τρίτο για σύνδεση ή εγγραφή στο σύστημα

57 Σενάριο χρήσης εφαρμογής και ανάλυση όψεων Εικόνα 9 Αρχική οθόνη εφαρμογής 4.2. Οθόνη σύνδεσης Όταν ο χρήστης επιλέξει να συνδεθεί μεταφέρεται σε αυτή τη σελίδα και έχει την επιλογή να συμπληρώσει τα στοιχεία της φόρμας εισόδου για να γίνει η ταυτοποίηση ή να συμπληρώσει τη φόρμα εγγραφής για τη δημιουργία νέου λογαριασμού χρήστη. Στην φόρμα εγγραφής τονίζονται τα στοιχεία που είναι απαραίτητα στο σύστημα για την δημιουργία ενός νέου πόρου χρήστη, τα οποία φέρουν την ιδιότητα required στην περιγραφή τους στο αρχείο Yaml

58 Σενάριο χρήσης εφαρμογής και ανάλυση όψεων Εικόνα 10 Οθόνη Σύνδεσης 4.3. Περισσότερες επιλογές στην αρχική οθόνη Εικόνα 11 Περισσότερες επιλογές αρχική οθόνη