Ανάπτυξη RESTful APIs με τη χρήση της γλώσσας Gherkin και του OpenAPI Specification

Αριστοτέλειο Πανεπιστήμιο Θεσσαλονίκης Διπλωματική Εργασία Ανάπτυξη RESTful APIs με τη χρήση της γλώσσας Gherkin και του OpenAPI Specification Διπλωματικός Φοιτητής: Αναστάσιος Δημανίδης 7422 Επιβλέποντες: Επικ. Καθηγ. Ανδρέας Συμεωνίδης Μεταδιδακτορικός ερευνητής Κυριάκος Χατζηδημητρίου Η Διπλωματική Εργασία αποτελεί μέρος των υποχρεώσεων για την απόκτηση του Διπλώματος Ηλεκτρολόγου Μηχανικού και Μηχανικού Ηλεκτρονικών Υπολογιστών στο Intelligent Systems and Software Engineering Labgroup - ISSEL Τμήμα Ηλεκτρολόγων Μηχανικών και Μηχανικών Ηλεκτρονικών Υπολογιστών

Ευχαριστίες Κατ αρχήν, θα ήθελα να ευχαριστήσω τον Καθηγητή κ. Συμεωνίδη Ανδρέα, ως επιβλέποντα, για την εμπιστοσύνη που μου έδειξε με την ανάθεση της διπλωματικής εργασίας. Οι επισημάνσεις και οι παρατηρήσεις του τόσο επί της διπλωματικής συνολικά όσο και επί λογισμικού που αναπτύχθηκε ειδικά, ήταν για εμένα διδακτικές. Θα ήθελα επίσης να τον ευχαριστήσω και ως καθηγητή για τις ξεχωριστά ενδιαφέρουσες εργασίες που μας ανέθετε, για το ομαδικό κλίμα στο οποίο μας μύησε και για την διαθεσιμότητά του στο να ακούει τους προβληματισμούς μας. Θα ήθελα ακόμη να ευχαριστήσω τον Μεταδιδακτορικό Ερευνητή κ. Χατζηδημητρίου Κυριάκο, ως συνεπιβλέποντα, για την άμεση καθοδήγηση που παρείχε κατά την διάρκεια αυτής της εργασίας. Ήτανε πάντοτε σε ετοιμότητα για να συζητήσουμε τα όποια ζητήματα ανέκυπταν στην πορεία της διπλωματικής. Θα ήθελα επιπλέον να ευχαριστήσω το ISSEL Labgroup ως ομάδα. Οι τεχνολογίες που προωθούνται από το ISSEL είναι εξαιρετικά ενδιαφέρουσες και άμεσα συνδεδεμένες με την σημερινή αγορά εργασίας. Επιπρόσθετα, χάρη στο κοινό ενδιαφέρον της ομάδας για την επιστήμη των υπολογιστών και την τεχνολογία γενικότερα, καλλιεργείται ένα φιλικό προς την έρευνα κλίμα. Το χαρακτηριστικό αυτό αποτελεί σημαντικό κίνητρο για έναν νέο φοιτητή. Κλείνοντας θα ήθελα να ευχαριστήσω την μητέρα μου Σωτηρία, τον πατέρα μου Παναγιώτη και τα αδέρφια μου Χριστόφορο και Παύλο, που ήταν δίπλα μου κατά την διάρκεια αυτού του πτυχίου. Η υπομονή τους και η στήριξή τους ήταν απεριόριστη τόσο στα εύκολα όσο και στα δύσκολα. Η αμέριστη συμπαράστασή τους δύσκολα μπορεί να περιγραφεί με λέξεις. Ευχαριστώ και όλους τους συμφοιτητές και τις συμφοιτήτριες και όλους τους άλλους φίλους για τις εμπειρίες που έζησα μαζί τους στην διάρκεια αυτών των σπουδών. i

Αφιερωμένο στην γιαγιά μου την Ελένη και στους γονείς μου ii

Περίληψη Η επιτυχής και ποιοτική εκπλήρωση των εξειδικευμένων απαιτήσεων του εκάστοτε πελάτη λογισμικού, απασχολεί συνεχώς τόσο την βιομηχανία λογισμικού όσο και την ακαδημαϊκή κοινότητα. Ως εκ τούτου, εμφανίστηκαν και εμφανίζονται μεθοδολογίες σχεδιασμού και ανάπτυξης λογισμικού που επιλύουν αυτό το πρόβλημα, όπως το Behavior-Driven Development (BDD) και η Agile φιλοσοφία γενικότερα. Ταυτόχρονα ο Παγκόσμιος Ιστός περνάει από ένα στάδιο ωρίμανσης. Η έννοια «Ο Παγκόσμιος Ιστός ως Πλατφόρμα Εφαρμογών» κυριαρχεί. Αναπόφευκτα πυροδοτούνται συζητήσεις που αφορούν την αποτελεσματική σχεδίαση και ανάπτυξη λογισμικού και στον Παγκόσμιο Ιστό. Οι τρέχουσες τάσεις της αγοράς δείχνουν ότι τεχνολογίες όπως το REST μπορούν να δώσουν απαντήσεις σε αυτές τις συζητήσεις. Δεδομένου αυτού του πλαισίου, οι βασικοί στόχοι της διπλωματικής είναι δύο. Ο πρώτος στόχος είναι ο σχεδιασμός μίας μεθοδολογίας κατά την οποία οι λειτουργικές απαιτήσεις των RESTful Web APIs περιγράφονται σε φυσική γλώσσα, φιλική προς τον πελάτη. Ο δεύτερος στόχος είναι η ανάπτυξη ενός λογισμικού ικανού να μετατρέψει τις απαιτήσεις σε τεχνικές πληροφορίες. Προκειμένου να επιτευχθούν αυτοί οι στόχοι, υιοθετείται η γλώσσα συγγραφής απαιτήσεων Gherkin, η τυποποίηση REST υπηρεσιών OpenAPI Specification αλλά και μεθοδολογίες επεξεργασίας φυσικής γλώσσας. Αρχικά, κατά την υλοποίηση του συνολικού συστήματος διερευνήθηκε ο τρόπος απεικόνισης REST απαιτήσεων σε Gherkin. Για τον λόγο αυτό πραγματοποιήθηκαν επικοινωνίες με στελέχη εταιριών Agile και BDD, εξετάσθηκαν blog και σεμινάρια εταιριών API και μελετήθηκε διεξοδικά η βιβλιογραφία. Με βάση αυτή την έρευνα, στην παρούσα εργασία σχεδιάστηκε η μεθοδολογία Resource Driven Development (RDD). Κατά το RDD, αναθεωρείται η λογική συγγραφής των feature files της Gherkin. Πλέον οι απαιτήσεις λειτουργίας της Web εφαρμογής αφορούν αποκλειστικά την περιγραφή πόρων Παγκόσμιου Ιστού. Ακόμη, τα βήματα When και Then χρησιμοποιούνται πλέον για την μοντελοποίηση του πρωτοκόλλου HTTP. Επιπρόσθετα, τα σενάρια χρησιμοποιούνται για περιγραφή αλλαγής κατάστασης πόρου και εφαρμογής, με βάση την φιλοσοφία του REST. Τα ειδικότερα χαρακτηριστικά της μεθοδολογίας Gherkin αναλύονται διεξοδικά στην διπλωματική και παρουσιάζονται με συγκεκριμένα παραδείγματα. Στο επόμενο στάδιο της υλοποίησης του συνολικού συστήματος, αναπτύχθηκε σε python 3.5 το λογισμικό Gherkin2OAS, το οποίο μετατρέπει τις Gherkin απαιτήσεις σε OpenAPI Specification. Στην διπλωματική παρουσιάζεται αναλυτικά το μοντέλο λειτουργίας του λογισμικού, οι συναρτήσεις του και οι τεχνικές επεξεργασίας φυσικής γλώσσας που χρησιμοποιεί. Το λογισμικό είναι ικανό να εντοπίζει σε κείμενο φυσική γλώσσας HTTP ρήματα, ονόματα παραμέτρων, τύπους παραμέτρων (string, int, float, bool, array, file, date, password κ.α.) και ιδιότητες παραμέτρων (required, min/max, descriptions, formats), συνδέσεις πόρων με βάση το μοντέλο HATEOAS, ρόλους/χρήστες, HTTP status codes κ.α. Επίσης, έχει ξεχωριστή λειτουργία οργάνωσης αυτών των τεχνικών πληροφοριών σε OpenAPI Specification. Περαιτέρω προσπαθεί μέσω μηνυμάτων να καθοδηγήσει τον χρήστη στην συγγραφή των απαιτήσεων Gherkin, όπως ένας compiler. Τέλος, στην παρούσα εργασία και ως μέρος του Gherkin2OAS, αναπτύχθηκε υποσύστημα απεικόνισης του RESTful API με γράφους. Οι γράφοι μπορούν να συνεισφέρουν στην κατά REST αξιολόγηση του συστήματος, στην επιβεβαίωση της επιτυχούς σύλληψης του επιχειρησιακού πρωτοκόλλου του πελάτη, στην διόρθωση λαθών και στην εξαγωγή τεχνικών πληροφοριών. Η χρήση των γράφων παρουσιάζεται με συγκεκριμένα παραδείγματα. iii Δημανίδης Τάσος anasdima@ece.auth.gr

Abstract Employing the Gherkin language and the OpenAPI Specification for automated RESTful Web API Development The problem of the effective satisfaction of customer requirements in the typical software development lifecycle has been of major concern, not only to the software industry, but also to the academic world. Thus, new software development methodologies like Behavior-Driven Development and the Agile manifesto are introduced, dictating continuous and detailed communications between the software engineer and the customer. At the same time the World Wide Web is maturing. The concept The Web as an Application Platform is greatly adopted. Inevitably, Web developers and industry specialists are discussing methods of effectively designing and developing Web applications. The current state of the industry shows that technologies like REST, might be the answer to those discussions. This thesis sets two major goals: a) To design a methodology where RESTful Web API functional requirements are described in a customer friendly format and in natural language, b) To develop a software tool that will transform the described requirements to technical information. For these goals to be met we employ Gherkin -a user requirements language-, the OpenAPI Specification -a specification for REST Web APIs- and finally Natural Language Processing (NLP) mechanisms. At first, it was examined how would the REST specifications be mapped to Gherkin. For that reason, Agile and BDD company members were contacted, API company blogs and seminars were examined and the available bibliography was thoroughly studied. Based on this research, the methodology Resource Driven Development (RDD) was designed. Per RDD, the functional requirements of a Web application are organized in resources. Thus, the original way of writing Gherkin feature files was revised. The steps When and Then are now used to model the HTTP protocol. The scenarios are used to describe resource and application state changes, as implied by REST. The RDD methodology is described in detail with specific examples of Gherkin files. The next step was to develop a software tool, which was named Gherkin2OAS and which is responsible of converting Gherkin requirements to the OpenAPI Specification. The software is written in python 3.5. It s functionality, it s functions and the NLP mechanisms it uses are thoroughly described. Gherkin2OAS can detect in natural language text HTTP verbs, parameter names, types (like string, int, float, bool, array, file, date, password and more) and properties (like required, min/max, descriptions and formats), resource linking through the HATEOAS concept, roles/users, HTTP status codes and more. It also has a separate functionality, where it organizes those technical properties to an OpenAPI Specification document. Furthermore, Gherkin2OAS has built in messages that try to guide the user in writing Gherkin requirements, the way a programming language compiler would help programming software. Finally, a Gherkin2OAS subsystem was developed to visualize the created REST API with graphs. Those graphs can contribute in the REST evaluation of the system and in the successful realization of the client s domain application protocol. It can also help with error fixing and technical information extraction. The graphs usage is presented with specific examples. iv Dimanidis Tasos anasdima@ece.auth.gr

v Πίνακας Περιεχομένων Ευχαριστίες Περίληψη Abstract Λίστα Εικόνων Λίστα Πινάκων i iii iv viii xiii 1 Εισαγωγή 1 1.1 Κίνητρο....................................... 1 1.2 Περιγραφή προβλήματος............................. 1 1.3 Στόχοι διπλωματικής............................... 2 1.4 Διάρθρωση..................................... 2 2 Υπόβαθρο 3 2.1 Representational State Transfer........................ 3 2.1.1 Αναδρομή στο παρελθόν......................... 3 2.1.2 Βασικές έννοιες του σύγχρονου Παγκόσμιου Ιστού.......... 4 2.1.2.1 Πόροι Παγκόσμιου Ιστού ή (Resources)........... 5 2.1.2.2 Unique Resource Identifiers (URIs)............. 5 2.1.2.3 Resource Representations................... 7 2.1.2.4 Πρωτόκολλο HTTP....................... 8 2.1.3 Διδακτορική Διατριβή Roy Fielding................... 10 2.1.4 Ο Παγκόσμιος Ιστός ως πλατφόρμα εφαρμογών............ 14 2.1.4.1 Hypermedia as the engine of application state - HATEOAS 14 2.1.4.2 Ομοιόμορφη Διεπαφή - Uniform Interface στον Παγκόσμιο Ιστό................................ 17 2.1.5 RESTful Web APIs & OpenAPI Specification............. 18 2.1.5.1 APIs............................... 18 2.1.5.2 OpenAPI Specification..................... 20 2.1.5.3 Τεχνικά χαρακτηριστικά του OpenAPI Specification.... 22 2.2 Behavior-Driven Development.......................... 27 2.2.1 Σχεδιασμός και Ανάπτυξη Λογισμικού................. 27 2.2.1.1 Test Driven Development................... 29 2.2.1.2 Acceptance TDD και Behavior Driven Development.... 31 2.2.2 Gherkin................................... 37 2.3 Natural Language Processing.......................... 41 2.3.1 Information Extraction.......................... 41 2.3.1.1 Tokenization.......................... 42 2.3.1.2 POS Tagging.......................... 42 2.3.1.3 Text Chunking......................... 42 2.3.1.4 Named Entity Recognition.................. 43 2.3.1.5 Relation Extraction....................... 43 2.3.2 Άλλα εργαλεία NLP............................ 44 2.3.2.1 Κανονικές εκφράσεις (Regular Expressions)........ 44

vi 2.3.2.2 Λίστες λέξεων ή φράσεων.................... 44 2.3.2.3 nltk................................ 44 3 Σχετική Βιβλιογραφία & Εξειδίκευση του προβλήματος 46 3.1 Σχετική βιβλιογραφία............................... 46 3.1.1 Εφαρμογή μηχανισμών NLP σε κείμενο λειτουργικών απαιτήσεων για εξαγωγή τεχνικών χαρακτηριστικών................ 46 3.1.2 Web API Development με Gherkin................... 47 3.2 Εξειδίκευση του προβλήματος: Ανάπτυξη Web APIs με την Gherkin και το OpenAPI Specification.............................. 51 3.2.1 Agile RESTful API Development.................... 51 3.2.2 Λειτουργικές και μη, απαιτήσεις.................... 53 3.2.3 Απαιτήσεις συστήματος.......................... 53 4 Μεθοδολογία & Υλοποίηση συστήματος 55 4.1 Μεθοδολογία.................................... 55 4.1.1 Τεχνικό επίπεδο της Gherkin...................... 55 4.1.2 Απεικόνιση REST σε Gherkin...................... 56 4.1.3 Λογισμικό................................. 57 4.2 Υλοποίηση Συστήματος.............................. 59 4.2.1 Απεικόνιση λειτουργικών απαιτήσεων REST συστήματος σε Gherkin: Resource Driven Development................ 59 4.2.2 Gherkin2OAS............................... 67 4.2.3 Γράφοι καταστάσεων............................ 76 4.2.4 Gherkin2OAS Data Flows........................ 78 4.2.5 Gherkin2OAS Production Environment................ 78 5 Πειράματα & Αποτελέσματα 87 5.1 Ο μηχανισμός διασφάλισης της αξιοπιστίας του συστήματος......... 87 5.2 Ταχύτητα εκτέλεσης και POS Tagging..................... 89 5.3 Αναλυτικά Παραδείγματα, Πειράματα και αποτελέσματα........... 90 5.3.1 Mytop10 API................................ 90 5.3.2 Generic e-shop............................... 103 6 Συμπεράσματα & Μελλοντικές επεκτάσεις 119 6.1 Συμπεράσματα................................... 119 6.1.1 Σχεδιασμού................................. 119 6.1.2 Υλοποίησης................................. 119 6.2 Μελλοντικές επεκτάσεις............................. 121 6.2.1 Παράμετροι................................. 121 6.2.2 Βήμα Given και φυσικότητα γλώσσας Gherkin............ 121 6.2.3 Απεικόνιση μη λειτουργικών απαιτήσεων σε Gherkin........ 121 6.2.4 HATEOAS Graphs............................ 122 6.2.5 Τυποποίηση του NLP Model & IDE................... 122 6.2.6 OpenAPI Specification V3........................ 122 A Cucumber 124 A.1 Cucumber Business Facing........................... 125 A.2 Cucumber Technology Facing.......................... 127 A.3 Άλλα εργαλεία BDD/ΤDD/ATDD........................ 128 B Η τεχνολογία πριν το REST ή οι ανταγωνιστικές τεχνολογίες 131

vii B.1 URI Tunneling με URI Templates....................... 131 B.2 RPC και REST-RPC Hybrid........................... 132 B.3 WS-*........................................ 133 C Απαιτήσεις API κατά RDD & OpenAPI Specifications 136 C.1 Mytop10...................................... 136 C.2 Generic eshop................................... 160 D Gherkin Specifications Document 187 Βιβλιογραφία 189

viii Λίστα Εικόνων 2.1 Η εξέλιξη του Διαδικτύου............................. 4 2.2 Παραδείγματα URI................................ 6 2.3 Το μοντέλο πελάτη-εξυπηρετητή......................... 9 2.4 REST: Client-Server............................... 11 2.5 REST: Stateless.................................. 12 2.6 REST: Cache.................................... 12 2.7 REST: Uniform Interface............................. 13 2.8 REST: Layered System.............................. 13 2.9 REST........................................ 14 2.10 Το Richardson Maturity Model......................... 17 2.11 Οι εταιρείες του OpenAPI Initiative...................... 21 2.12 Διαδικτυακή κίνηση κλήσεων API της εταιρείας apigee........... 21 2.13 Περιπτώσης χρήσης των ηλεκτρονικών υπηρεσιών της apigee........ 22 2.14 Τα Data Types του OAI Specification...................... 23 2.15 OpenAPI Specification: Παράδειγμα Definitions............... 25 2.16 OpenAPI Specification: Παράδειγμα πληροφοριών του API......... 25 2.17 OpenAPI Specification: Παράδειγμα Paths Object.............. 26 2.18 Οι βασικές δραστηριότητες ανάπτυξης λογισμικού............... 29 2.19 Διαδεδομένα μοντέλα ανάπτυξης λογισμικού.................. 30 2.20 Διάγραμμα εξέλιξης διαδικασίας TDD...................... 31 2.21 Ο κύκλος ζωής της μεθοδολογίας TDD..................... 32 2.22 Διαδικασία συγγραφής acceptance test..................... 32 2.23 Συμμετοχή διαφόρων ομάδων στην συγγραφή δοκιμών κατά BDD, ATDD, TDD......................................... 37 2.24 Ένα Cucumber feature file............................ 38 2.25 Η λογική πύλη AND κατά Cucumber...................... 39 2.26 Το Abstract Syntax Tree του Gherkin Parser................. 40 2.27 Αποτέλεσμα εφαρμογής POS Tagging και Text Chunking σε μία πρόταση. 42 2.28 Παράδειγμα εφαρμογής Named Entity Recognition.............. 43 2.29 Η διαδικασία του Information Extraction................... 43 2.30 Αλφαβητική λίστα POS Tags του Penn Treebarnk project.......... 45 3.1 S-CASE: Επισήμανση απαιτήσεων........................ 48 3.2 S-CASE: Οντολογικό δέντρο εννοιολογικών κλάσεων............. 49 3.3 Πρόταση σημασμένη με post tags και chunks................. 50 3.4 Κείμενο σημασμένο με POS tags και structural dependencies........ 50 3.5 Τα επίπεδα σχεδιασμού ενός API........................ 52 4.1 Gherkin2OAS: Preprocessor model....................... 70 4.2 Gherkin2OAS: nlp model............................. 71 4.3 Gherkin2OAS: Παράδειγμα μοντέλου γράφου resource_state........ 72 4.4 Gherkin2OAS: Παράδειγμα μοντέλου γράφου state............. 73 4.5 Αντιστοιχία γνωστών φράσεων με status codes................. 74 4.6 Η αντιστοιχία ρημάτων αγγλικής γλώσσας με HTTP ρήματα/operations.. 74 4.7 Λίστες φράσεων μεγίστων και ελαχίστων.................... 75

ix 4.8 Gherkin2OAS: Εσωτερικό μοντέλο που χρησιμοποιείται στον formatter για επίλυση ιεραρχιών................................. 76 4.9 Γράφος μετάβασης καταστάσεων σε επίπεδο πόρων............... 77 4.10 Ο γράφος μεταβάσης καταστάσεων σε επίπεδο εφαρμογής, σε user friendly μορφή........................................ 79 4.11 Ο γράφος μεταβάσης καταστάσεων σε επίπεδο εφαρμογής, σε τεχνική μορφή 80 4.12 Gherkin2OAS: Data Flow............................ 81 4.13 Gherkin2OAS: Alternative Data Flow..................... 82 4.14 Gherkin2OAS: GUI................................ 82 4.15 Φάκελος με αρχεία resource........................... 82 4.16 Παράδειγμα αρχείου spec_config.ini....................... 83 4.17 Αρχεία εξόδου εκτέλεσης Gherkin2OAS.................... 83 4.18 Εποπτεία του API με τον swagger editor - Editor............... 84 4.19 Εποπτεία του API με τον swagger editor - API UI.............. 85 4.20 Δοκιμή του API με τον swagger editor..................... 86 5.1 Mytop10: User resource - paths......................... 92 5.2 Mytop10: User resource - models........................ 93 5.3 Mytop10: User resource - security....................... 94 5.4 Mytop10: User resource - GET user...................... 94 5.5 Mytop10: User resource - PUT user...................... 95 5.6 Mytop10: User resource - PUT user examples................. 95 5.7 Mytop10: User resource - DELETE user.................... 96 5.8 Mytop10: User resource - POST user...................... 97 5.9 Mytop10: List resource - paths......................... 97 5.10 Mytop10: List resource - GET.......................... 98 5.11 Mytop10: List resource - PUT.......................... 99 5.12 Mytop10: List resource - DELETE....................... 100 5.13 Mytop10: List resource - POST......................... 101 5.14 Mytop10: Admin resource - paths........................ 101 5.15 Mytop10: Admin resource - security...................... 102 5.16 Mytop10: Admin resource - GET........................ 103 5.17 Mytop10: Admin resource - POST........................ 104 5.18 Mytop10: Rate resource - paths......................... 104 5.19 Mytop10: Rate resource - POST......................... 105 5.20 Mytop10: Rate resource - required model................... 105 5.21 Mytop10: Search resource - GET........................ 106 5.22 Mytop10: Follow list resource - POST..................... 107 5.23 Mytop10: Comment resource - POST...................... 108 5.24 Mytop10: Follow list resource - required model................ 108 5.25 Mytop10: Comment resource - required model................ 109 5.26 Mytop10: Gherkin2OAS execution....................... 110 5.27 Generic eshop: paths (1/2)............................ 111 5.28 Generic eshop: paths (2/2)............................ 112 5.29 Generic eshop: product model.......................... 112 5.30 Generic eshop: basket post response...................... 113 5.31 Generic eshop: Γράφος με μεταβάσεις καταστάσεων σε επίπεδο πόρων... 114 5.32 Generic eshop: Γράφος με μεταβάσεις καταστάσεων σε επίπεδο κατάστασης εφαρμογής..................................... 115 5.33 Generic eshop: Νέος γράφος με μεταβάσεις καταστάσεων σε επίπεδο πόρων 116

x 5.34 Generic eshop: Νέος γράφος με μεταβάσεις καταστάσεων σε επίπεδο κατάστασης εφαρμογής.............................. 117 5.35 Generic eshop: Προτροπή διόρθωσης γράφου.................. 118 A.1 Τα βασικά επίπεδα του Cucumber........................ 124 A.2 Cucumber testing stack: Η μεθοδολογία BDD κατά Cucumber....... 125 A.3 Τα step definitions παίζουν τον ρόλο του μεταγλωττιστή........... 128 A.4 Πώς το Cucumber εκτελεί ένα σενάριο..................... 130

xi Λίστα Παραδειγμάτων 2.1 Παράδειγμα JSON αναπαράστασης....................... 7 2.2 Παράδειγμα XML αναπαράστασης........................ 7 2.3 HTTP αίτημα πελάτη σε εξυπηρετητή...................... 9 2.4 HTTP απάντηση εξυπηρετητή σε πελάτη.................... 9 2.5 Απάντηση εξυπηρετητή με Hypermedia Control................ 15 2.6 BDD User Story.................................. 35 2.7 ATDD Acceptance Test.............................. 35 4.1 Παράδειγμα περιγραφής API κατά Cucumber................. 55 4.2 RDD: Παράδειγμα βήματος με http ρήμα.................... 60 4.3 RDD: Παράδειγμα βήματος με περισσότερα το ενός http ρήματα....... 60 4.4 RDD: παράμετροι στο path............................ 61 4.5 RDD: παράμετροι σε query............................ 61 4.6 RDD: παράμετροι σε body............................. 62 4.7 RDD είδη πινάκων: Πίνακας με παραμέτρους στην πρώτη στήλη και παραδείγματα στην δεύτερη........................... 62 4.8 RDD είδη πινάκων: Πίνακας με παραμέτρους στην πρώτη γραμμή και παραδείγματα στην δεύτερη........................... 62 4.9 RDD είδη πινάκων: Πίνακας μόνο με ονόματα παραμέτρων......... 63 4.10 RDD είδη πινάκων: Πίνακας με μία παράμετρο................ 63 4.11 RDD είδη πινάκων: Πίνακας με μέγιστα και ελάχιστα............ 63 4.12 RDD: περιγραφή μοντέλου............................ 63 4.13 RDD: status code................................. 64 4.14 RDD: HATEOAS links.............................. 64 4.15 RDD: path hierarchies.............................. 65 4.16 RDD: roles..................................... 65 4.17 RDD: Ένα resource file.............................. 65 4.18 RDD: Πλήρες resource file............................ 66 4.19 Εκκίνηση Gherkin2OAS - τερματικό...................... 79 5.1 Mytop10 user resource.............................. 90 5.2 Mytop10 list resource............................... 93 5.3 Mytop10 admin resource............................. 96 5.4 Mytop10 rate resource.............................. 98 5.5 Mytop10 search resource............................. 99 5.6 Mytop10 search resource............................. 101 5.7 Generic eshop: all HATEOAS links....................... 103 5.8 Generic eshop: GET order - διπλή περιγραφή................. 109 5.9 Generic eshop: Δημιουργία resource pending deliveries........... 109 A.1 Πλεονάζοντα σενάρια Cucumber......................... 126 A.2 Cucumber Scenario Outline........................... 126 A.3 cucumber step definition............................. 127 B.1 Remote Procedure Call με XML......................... 132 B.2 POX μέσω HTTP.................................. 133 B.3 SOAP Envelope.................................. 133 B.4 Παράδειγμα WSDL αρχείου........................... 134 C.1 Mytop10 με RDD: user.resource......................... 136 C.2 Mytop10 με RDD: admin.resource....................... 137

C.3 Mytop10 με RDD: comment.resource...................... 138 C.4 Mytop10 με RDD: follow list.resource..................... 138 C.5 Mytop10 με RDD: list.resource......................... 138 C.6 Mytop10 με RDD: rate.resource......................... 139 C.7 Mytop10 με RDD: search.resource....................... 140 C.8 Mytop 10 με RDD: OpenAPI Specification................... 142 C.9 Eshop με RDD: product.resource........................ 161 C.10 Eshop με RDD: search.resource......................... 162 C.11 Eshop με RDD: basket.resource......................... 162 C.12 Eshop με RDD: order.resource.......................... 163 C.13 Eshop με RDD: payment.resource........................ 164 C.14 Eshop με RDD: pending deliveries.resource.................. 164 C.15 Eshop με RDD: OpenAPI Specification..................... 166 xii

xiii Λίστα Πινάκων 2.1 Safety & Idempotency των POST, GET, PUT, DELETE........... 18 2.2 Acceptance test με στόχο την επικύρωση ενός επιχειρησιακού κανόνα... 33 2.3 Acceptance test με στόχο την επικύρωση μέρους διεπαφής χρήστη..... 34

1 Κεφάλαιο 1 Εισαγωγή 1.1 Κίνητρο Το κίνητρο της διπλωματικής προέρχεται από το ερώτημα Ποια είναι η χρησιμότητα του λογισμικού στον άνθρωπο;. Η απάντηση σε αυτό το ερώτημα είναι ότι το λογισμικό συνεισφέρει στους γρήγορους υπολογισμούς και στην γρήγορη επικοινωνία των ανθρώπων 1. Οι ιδιότητες των γρήγορων υπολογισμών και της γρήγορης επικοινωνίας αξιοποιούνται στη συνέχεια σε αμέτρητες εμπορικές και ερευνητικές εφαρμογές. Όσο αυτές οι ιδιότητες του λογισμικού εκτιμούνται, τόσο το λογισμικό θα παραμένει επίκαιρο. Με δεδομένα τα πλεονεκτήματα του λογισμικού, το ερώτημα που πλέον απασχολεί είναι Πώς θα μεγιστοποιήσουμε την χρησιμότητα του λογισμικού στον άνθρωπο;. Πιο συγκεκριμένα, δεδομένου ενός τεχνολογικά καταρτισμένου και αιτούμενου λογισμικού ανθρώπου (άρα αποδεχόμενου τα πλεονεκτήματα του λογισμικού), πώς θα σχεδιάσουμε το ζητούμενο λογισμικό, ώστε να υπηρετεί κατά το δυνατόν καλύτερα τις απαιτήσεις του; Αλλά και ταυτόχρονα, πώς μπορεί η ίδια η διαδικασία ανάπτυξης λογισμικού να βελτιωθεί, διατηρώντας ταυτόχρονα την ποιότητά του; Τα πλεονεκτήματα του λογισμικού, τα δύο τελευταία ερωτήματα και το ερευνητικό ενδιαφέρον της επίλυσής τους αποτελούν το κίνητρο της διπλωματικής. 1.2 Περιγραφή προβλήματος Η ανάπτυξη των RESTful Web APIs εντάσσεται στην γενικότερη κατηγορία ανάπτυξης λογισμικού. Άρα κατ αρχήν για τα APIs ισχύει ό,τι ισχύει και για το λογισμικό. Ύστερα από αναζήτηση σε ιστοσελίδες, blog, και web seminars γνωστών εταιρειών του χώρου (Apigee, Apiary, SmartBear, 3Scale, apinf), φαίνεται ότι οι Agile μεθοδολογίες, άρα και το BDD, κυριαρχούν. Τα Web APIs πριν γίνουν διαθέσιμα, υπόκεινται σε μία σειρά από ελέγχους. Έτσι, μεθοδολογίες οι οποίες βασίζονται στην σχεδίαση λογισμικού ξεκινώντας από το τεστ, βρίσκουν εδώ εφαρμογή. Το πρόβλημα λοιπόν της διπλωματικής είναι, πώς θα σχεδιάσουμε ένα σύστημα που θα συμβάλλει στην ανάπτυξη RESTful Web APIs. Το σύστημα πρέπει να προβλέπει πώς οι απαιτήσεις των χρηστών θα γράφονται με την λογική του BDD. Επίσης ότι το τελικό του προϊόν δεν θα είναι το ίδιο το API, αλλά μία τυποποίηση για RESTful Web APIs, η OpenAPI Specification. Επισημαίνουμε τέλος ότι με βάση την έρευνα που έγινε 2, τέτοιο σύστημα δεν υπάρχει. Άρα η σχεδίαση του συστήματος δεν μπορεί να βασιστεί σε υπαρκτά παραδείγματα, 1 Η επιλογή της λέξης συνεισφορά δεν είναι τυχαία, διότι σε αυτά συνεισφέρει και το υλικό αλλά κυρίως η ανθρώπινη σκέψη. 2 Η έρευνα συμπεριελάμβανε και επικοινωνία με στέλεχος της Cucumber αλλά και agile mentor

Κεφάλαιο 1. Εισαγωγή 2 αλλά σε κάποιες βασικές αρχές. προβλήματος. Ο εντοπισμός των αρχών είναι και αυτός μέρος του 1.3 Στόχοι διπλωματικής Οι στόχοι της διπλωματικής είναι δύο: 1. Ο σχεδιασμός μίας απεικόνισης του OpenAPI Specification σε γλώσσα Gherkin, ικανή να διαβαστεί από τον πελάτη. Η απεικόνιση θα πρέπει να έχει μορφή λειτουργικών απαιτήσεων. 2. Η ανάπτυξη λογισμικού ικανού να μετατρέπει τις καταγραφόμενες σε Gherkin λειτουργικές απαιτήσεις, σε OpenAPI Specification με την χρήση μηχανισμών επεξεργασίας φυσικής γλώσσας 1.4 Διάρθρωση Η διπλωματική ξεκινάει με το θεωρητικό και πρακτικό υπόβαθρο το οποίο περιγράφεται στο Κεφάλαιο 2. Στην Ενότητα 2.1 περιγράφονται οι έννοιες του Παγκόσμιου Ιστού και των REST συστημάτων. Στην Ενότητα 2.2 περιγράφονται οι έννοιες της Τεχνολογίας Λογισμικού, των μεθοδολογιών Test Driven Development, Acceptance Test Driven Development και Behavioral Driven Development καθώς και η γλώσσα Gherkin. Στην Ενότητα 2.3 περιγράφονται έννοιες του Natural Language Processing, οι οποίες χρησιμοποιούνται στην μετατροπή από Gherkin σε OpenAPI Specification. Στην συνέχεια, στο Κεφάλαιο 3 γίνεται η επισκόπηση της σχετικής βιβλιογραφίας και εξειδικεύεται το πρόβλημα. Στο Κεφάλαιο 4 παρουσιάζεται η μεθοδολογία ανάπτυξης και η υλοποίηση του συστήματος. Στο Κεφάλαιο 5 παρουσιάζονται τα πειράματα και η αξιολόγησή τους. Στο Κεφάλαιο 6 καταλήγουμε στα συμπεράσματα και επισημαίνουμε μελλοντικές πτυχές του συστήματος. Τέλος στο Παράρτημα παρουσιάζεται σύντομα το εργαλείο Cucumber, οι ανταγωνιστικές τεχνολογίες του REST, παραδείγματα αρχείων γραμμένων με την γλώσσα του συστήματος και η τυποποίηση της γλώσσας Gherkin όπως ορίστηκε από το σύστημα. Στα Κεφάλαιο 2 η επισκόπηση των εννοιών είναι εκτενής, όχι τυχαία. Επειδή ακριβώς δεν υπάρχουν τα επιθυμητά παραδείγματα περιγραφής απαιτήσεων REST APIs σε Gherkin, έπρεπε οι έννοιες να κατανοηθούν κατά το δυνατόν περισσότερο. Δηλαδή οι έννοιες αυτές δεν επεξηγούνται μόνο για την κατανόηση του κειμένου, αλλά και επειδή οι ιδιότητές τους συνέβαλαν στην απεικόνιση του OpenAPI Specification σε Gherkin.

3 Κεφάλαιο 2 Υπόβαθρο Στο κεφάλαιο αυτό γίνεται μία εκτενής επισκόπηση των απαραίτητων θεωρητικών και πρακτικών εννοιών τις οποίες χρειάζεται να γνωρίζει ο αναγνώστης, ώστε να καταλάβει την λειτουργία του συστήματος που σχεδιάστηκε. Επισημαίνεται ότι οι έννοιες αυτές δεν επεξηγούνται μόνο διότι είναι απαραίτητη η κατανόησή τους, αλλά και γιατί βάσει αυτών σχεδιάστηκε η μεθοδολογία απεικόνισης λειτουργικών απαιτήσεων RESTful υπηρεσιών σε γλώσσα Gherkin. Ειδικότερα, τα βασικά δομικά στοιχεία σχεδίασης Web εφαρμογών που περιγράφονται στις Ενότητες 2.1.2, 2.1.4.1 και 2.1.4.2 αλλά και η γενικότερη φιλοσοφία ανάπτυξης λογισμικού που περιγράφεται στην Ενότητα 2.2, αποτελούν την σχεδιαστική βάση του συστήματος που αναπτύχθηκε. 2.1 Representational State Transfer 2.1.1 Αναδρομή στο παρελθόν Προκειμένου να μιλήσουμε για REST, πρέπει πρώτα να μιλήσουμε για τον Παγκόσμιο Ιστό και να αναφερθούμε στο Διαδίκτυο και στους ηλεκτρονικούς υπολογιστές. Από τους επεξεργαστές λοιπόν ο άνθρωπος αρχίζει να κατασκευάζει ηλεκτρονικούς υπολογιστές. Το επόμενο στάδιο είναι η επικοινωνία των ηλεκτρονικών υπολογιστών, δηλαδή τα δίκτυα ηλεκτρονικών υπολογιστών. Τα πρώτα δίκτυα είχαν στρατιωτικές (ARPANET) και ερευνητικές (NPL, Merit, CYCLADES) εφαρμογές [9]. Το ARPANET συγκεκριμένα ήταν αποτέλεσμα της έρευνας του Defense Advanced Research Projects Agency (DARPA) των Ηνωμένων Πολιτειών της Αμερικής (τέλη δεκαετίας 1960). Η πρόσβαση στο ARPANET, εντός των ΗΠΑ, διευρύνεται με την ίδρυση του CSNET (Computer Science Network). Το τελευταίο έχει, όπως φαίνεται και από το όνομά του, ερευνητικό σκοπό. Ήδη (1974, RFC-675 [26]) έχει εμφανιστεί η έννοια Internet ή Διαδίκτυο. Δηλαδή πολλά μικρά δίκτυα συνδεδεμένα εσωτερικά μεταξύ τους (inter-connected/inter-net). Η τυποποίηση RFC-675 ορίζει το πρωτόκολλο Transmission Control Protocol ή απλά TCP [30]. Το TCP είναι ένα πρωτόκολλο με στόχο, να διασφαλίζει την αξιόπιστη μετάδοση bits σε ένα δίκτυο υπολογιστών. Στην συνέχεια το DARPA εξελίσσει το TCP σε TCP/IP (συγκεκριμένα το TCP/IP v4). Πλέον συμπεριλαμβάνεται και το Internet Protocol ή απλά IP [12]. Το IP είναι πρωτόκολλο επικοινωνίας. Μαζί με το TCP αποτελούν το Internet Protocol Suite [13] ή απλά το TCP/IP. Η εφεύρεση του TCP/IP αποτελεί σημείο σταθμό στην εξέλιξη του Διαδικτύου. Το 1982 το TCP/IP χρησιμοποιείται για όλες τις στρατιωτικές επικοινωνίες του ARPANET. Η εφεύρεση του TCP/IP οδηγεί επίσης στην εξέλιξη του CSNET στο NSFNet (National Science Foundation Network). Δίκτυο δηλαδή που προσπαθεί να συνδέσει όλα τα επιστημονικά δίκτυα των ΗΠΑ. Η πρώτη συστηματική διατλαντική επικοινωνία μεταξύ του NSFNet και των ερευνητικών/πανεπιστημιακών δικτύων της

Κεφάλαιο 2. Υπόβαθρο 4 Εικόνα 2.1: Η εξέλιξη του Διαδικτύου 2 Ευρώπης καθιερώνεται το 1988 (δορυφορική επικοινωνία Princeton-Stockholm). Πλέον το Διαδίκτυο παίρνει παγκόσμιες διαστάσεις. Το 1990 το ARPANET με την στρατιωτική του χροιά, αποτελεί παρελθόν. Ήδη το δίκτυο των ΗΠΑ έχει πάρει εμπορική μορφή. Την ίδια χρονιά (Μάρτιος 1990) εγκαθίσταται ο πρώτος μεγάλου εύρους ζώνης (1.5 ΜΒit/s) σύνδεσμος μεταξύ του NSFNet (Πανεπιστήμιο Cornell) και του ερευνητικού κέντρου CERN. Έξι μήνες αργότερα ο Tim Berners-Lee ξεκινάει την συγγραφή του Παγκόσμιου Ιστού (World Wide Web). Οι Leonard Richardson και Sam Ruby στο βιβλίο τους RESTful Web Services, αποτυπώνουν αυτή την πορεία με τον δικό τους τόνο: The Internet and the Web did not have to exist. They come to us courtesy of misallocated defense money, skunkworks engineering projects, worse-is-better engineering practices, big science, naive liberal idealism, cranky libertarian politics, technofetishism, and the sweat and capital of programmers and investors who thought they d found an easy way to strike it rich. [20] Η εφεύρεση του Παγκόσμιου Ιστού από τον Tim Berners-Lee αποτελεί σημείο αναφοράς για την παγκοσμιοποίηση του Διαδικτύου. Κομμάτι αυτής της παγκοσμιοποίησης είναι και οι υπηρεσίες Παγκοσμίου Ιστού τύπου REST. Αλλά προκειμένου να κατανοήσει κάποιος τις εξελιγμένες τεχνολογίες του Παγκόσμιου Ιστού, πρέπει πρώτα να κατανοήσει τις βασικές έννοιες πάνω στις οποίες δημιουργήθηκε. 2.1.2 Βασικές έννοιες του σύγχρονου Παγκόσμιου Ιστού Ο Παγκόσμιος Ιστός σήμερα, είναι ένας ηλεκτρονικός χώρος πληροφοριών παγκόσμιας εμβέλειας. Η μεγάλη εμπορική αποδοχή του Διαδικτύου στα τέλη του 20 αιώνα συνετέλεσε στην καθιέρωση ιδιαίτερα απλών εννοιών, οι οποίες σήμερα θεμελιώνουν τον Παγκόσμιο 2

Κεφάλαιο 2. Υπόβαθρο 5 Ιστό 3. Οι βασικές αυτές έννοιες αφορούν τόσο τις διαθέσιμες πληροφορίες, όσο και την επικοινωνία των εφαρμογών που εκτελούνται στον Παγκόσμιο Ιστό. Έτσι η σύντομη επεξήγηση τους, κρίνεται σκόπιμη. 2.1.2.1 Πόροι Παγκόσμιου Ιστού ή (Resources) Ένας πόρος του Παγκόσμιου Ιστού είναι οτιδήποτε διαθέτουμε προς πρόσβαση στον Παγκόσμιο Ιστό. Όπως για παράδειγμα ένα έγγραφο, κάθε είδους πολυμέσα, μία επιχειρησιακή διαδικασία, μία συσκευή, ένα ολόκληρο σύστημα. Οι πόροι του Παγκόσμιου Ιστού αποτελούν μερικές αναπαραστάσεις πραγματικών πόρων. Με την έννοια ότι έχουμε διατηρήσει τόσο την χρήσιμη όσο και την ικανή να προβληθεί στον Παγκόσμιο Ιστό πληροφορία. Οι πόροι είναι η ουσία και ο λόγος ύπαρξης του Παγκόσμιου Ιστού. Ο ίδιος ο στόχος του Tim Berners-Lee ήταν να δημιουργήσει ένα σύστημα, ώστε η πρόσβαση σε πληροφορίες να καθίσταται απλή. Οποιαδήποτε συναναστροφή μας με τον Παγκόσμιο Ιστό, αναπόφευκτα έχει να κάνει με πόρους. Μέσω των πόρων φτάνουμε σε έναν τελικό σκοπό, όπως για παράδειγμα η παραγγελία ενός προϊόντος ή η προβολή ενός βίντεο. 2.1.2.2 Unique Resource Identifiers (URIs) Τους πόρους στον Παγκόσμιο Ιστό τους συναντάμε σε εξυπηρετητές (servers). Ας εξετάσουμε τώρα το εξής παράδειγμα: Η ιστοσελίδα, ή πολύ απλά το γνωστό σε όλους youtube, είναι μία υπηρεσία προβολής βίντεο. Ανάμεσα στο πολλά είδη πόρων που διαθέτει στους χρήστες της, ο πιο γνωστός είναι τα βίντεο. Το ερώτημα που τίθεται είναι, πώς θα ζητήσω ένα συγκεκριμένο video από την υπηρεσία youtube; Ή για να το γενικεύσουμε: Πώς μπορώ να απευθυνθώ σε έναν συγκεκριμένο πόρο ενός εξυπηρετητή; Και γενικότερα τι είναι αυτό που διακρίνει τον ένα πόρο από έναν άλλο, τόσο εντός ενός εξυπηρετητή όσο και γενικότερα εντός του Παγκόσμιου Ιστού? Την απάντηση σε αυτό το ερώτημα δίνει η αρχιτεκτονική του Παγκόσμιου Ιστού με τα Unique Resource Identifiers. Τα Unique Resource Identifiers, ή για συντομία URIs, προσδιορίζουν ένα resource στον Παγκόσμιο Ιστό. Μέσω των URIs καθίστανται τα resource προσβάσιμα. Ένα Unique Resource Identifier αντιστοιχεί σε έναν -και μόνο έναν- πόρο του Παγκόσμιου Ιστού. Αντίθετα σε ένα resource μπορούν να αντιστοιχούν παραπάνω από ένα URIs. Έτσι η σχέση URIs - Resources είναι πολλά προς ένα. Ένα παράδειγμα URI που προσδιορίζει ένα βίντεο στην υπηρεσία youtube είναι το ακόλουθο:. Η διεύθυνση του εξυπηρετητή στον οποίο βρίσκονται τα resources του youtube είναι το www.youtube.com. Αυτό το πρόθεμα διαχωρίζει τα resources του youtube από τα resources όλων των άλλων εξυπηρετητών του διαδικτύου. Εντός του εξυπηρετητή τώρα, το πρόθεμα /watch?v=zecueq-mo4m ξεχωρίζει το συγκεκριμένο βίντεο από όλα τα άλλα βίντεο του youtube αλλά και από όλες τις άλλες υπηρεσίες του (όπως για παράδειγμα το URI https://www.youtube.com/channel/ucegdi0xixxz-qjofpf4jskw που περιέχει τα βίντεο με τα sport). Το εκάστοτε εσωτερικό πρόθεμα προσδιορισμού resource ονομάζεται 3 Επισημαίνουμε εδώ ότι ο Παγκόσμιος Ιστός είναι υπηρεσία του Διαδικτύου και όχι το Διαδίκτυο. Είναι μάλιστα η πιο χρησιμοποιημένη υπηρεσία του Διαδικτύου. Γι αυτό πολλές φορές στην καθημερινότητά μας συγχέουμε τις δύο έννοιες. Άλλες υπηρεσίες του διαδικτύου είναι για παράδειγμα το ηλεκτρονικό ταχυδρομείο, η διαδικτυακή τηλεφωνία, τα δίκτυα peer-to-peer και το ευρέως γνωστό πλέον cloud [3] [4]

Κεφάλαιο 2. Υπόβαθρο 6 path. Γενικώς ένα URI αναλύεται ως εξής 4 : scheme:[//[user:password@]host[:port]][/]path[?query][#fragment] Το URI αποτελείται: Από το scheme το οποίο είναι μία ακολουθία χαρακτήρων που περιγράφει το πρωτόκολλο επικοινωνίας. Δημοφιλή πρωτόκολλα επικοινωνίας είναι τα http (Παγκόσμιος Ιστός), ftp, mailto, file, data και irc Από δύο πλάγιες καθέτους (//). Η ύπαρξη ή όχι πλάγιων καθέτων εξαρτάται από την τυποποίηση του scheme. Από το authority part το οποίο αποτελείται: Από ένα προαιρετικό κομμάτι αυθεντικοποίησης (authentication) με όνομα χρήση και κωδικό. Το όνομα χρήστη χωρίζεται από τον κωδικό με άνω κάτω τελεία (:). Στο τέλος του κομματιού αυθεντικοποίησης πρέπει να υπάρχει το σύμβολο at (@). Από την διεύθυνση του εξυπηρετητή (host) Από έναν προαιρετικό αριθμό πόρτας (port number), ο οποίος διαχωρίζεται από τον host με άνω κάτω τελεία (:). Από το path το οποίο περιέχει δεδομένα. Τα δεδομένα συνήθως αναπαρίστανται σε ιεραρχική μορφή σε κομμάτια που διαχωρίζονται από μονές πλάγιες καθέτους (/). Από ένα προαιρετικό query μετά το path. Το query περιέχει επίσης δεδομένα, μη ιεραρχικά δομημένα, συνήθως χωρισμένα με το σύμβολο και (&) ή το ελληνικό ερωτηματικό (;) Από ένα προαιρετικό fragment το οποίο εμφανίζεται μετά από το σύμβολο κάγκελο (#). Το fragment αναφέρεται σε δευτερεύον resource, όπως για παράδειγμα ένα υπό κεφάλαιο ενός κειμένου. Παράδειγμα URI φαίνεται στην Εικόνα 2.2. Εικόνα 2.2: Παραδείγματα URI 4 Συνεπώς από το URI μπορούμε να διαπιστώσουμε το πρωτόκολλο επικοινωνίας, να διακρίνουμε έναν εξυπηρετητή από έναν άλλον, αλλά και να διακρίνουμε 4

Κεφάλαιο 2. Υπόβαθρο 7 ένα συγκεκριμένο resource του εξυπηρετητή από τα υπόλοιπα resource του ίδιου εξυπηρετητή. Δηλαδή τα URIs περιέχουν ποιοτική και χρήσιμη πληροφορία. 2.1.2.3 Resource Representations Οι πόροι του Παγκόσμιου Ιστού εμφανίζονται με διάφορες μορφές. Έτσι για παράδειγμα συναντάμε μορφές όπως XHTML, Atom, XML, JSON, απλό κείμενο, comma-separated values (CSV), MP3, JPEG και πολλά άλλα. Ένας πόρος μπορεί να παρουσιάζεται με παραπάνω από μία μορφές. Οι μορφές παρουσίασης των πόρων ονομάζονται αναπαραστάσεις. Τέτοιες αναπαραστάσεις φαίνονται στα παραδείγματα 2.1 και 2.2. Παράδειγμα 2.1: Παράδειγμα JSON αναπαράστασης {"employees":[ {"firstname":"john", "lastname":"doe"}, {"firstname":"anna", "lastname":"smith"}, {"firstname":"peter", "lastname":"jones"} ]} Παράδειγμα 2.2: Παράδειγμα XML αναπαράστασης <employees > <employee > <firstname >John</firstName > <lastname >Doe</lastName > </employee > <employee > <firstname >Anna</firstName > <lastname >Smith </lastname > </employee > <employee > <firstname >Peter </firstname > <lastname >Jones </lastname > </employee > </employees > Στην πραγματικότητα, ποτέ δεν απευθυνόμαστε σε ένα πόρο απευθείας. Οι πόροι βρίσκονται αποθηκευμένοι σε βάσεις δεδομένων και μνήμες ηλεκτρονικών υπολογιστών. Όταν μία εφαρμογή επεξεργάζεται έναν πόρο, δεν επεξεργάζεται απευθείας την βάση δεδομένων στην οποία αυτός είναι αποθηκευμένος. Εδώ πρέπει να θυμηθούμε ότι ο Παγκόσμιος Ιστός είναι πρωτόκολλο εφαρμογών. Έτσι εξ ορισμού δεν υποστηρίζεται την πρόσβαση σε τόσο χαμηλού επιπέδου πληροφορίες. Κυρίως όμως δεν είναι ο σκοπός του Παγκόσμιου Ιστού η επικοινωνία τέτοιων δεδομένων. Αυτό το οποίο είναι διαθέσιμο από τους διάφορους εξυπηρετητές του Παγκόσμιου Ιστού είναι οι αναπαραστάσεις των πόρων. Εδώ κάποιος μπορεί να θέσει το ερώτημα: Το βίντεο το οποίο είναι αποθηκευμένο στην βάση δεδομένων του youtube δεν είναι ίδιο με την αναπαράστασή του? Η απορία είναι εύλογη, αλλά η απάντηση είναι αρνητική. Ο τρόπος και η μορφή που μπορεί να αποθηκευτεί μία πληροφορία σε έναν ηλεκτρονικό υπολογιστή ποικίλει. Αντί να εξετάσουμε πως αποθηκεύει το youtube τα βίντεο του στις βάσεις δεδομένων του, ας παρατηρήσουμε το εξής. Το ίδιο βίντεο του youtube μπορούμε να το δούμε και μέσω flash player αλλά και μέσω HTML5. Οι δύο αυτές μορφές αποτελούν διαφορετικές αναπαραστάσεις του ίδιου βίντεο. Αν το youtube χρησιμοποιούσε για κάθε αναπαράσταση ένα αντίγραφο στην βάση δεδομένων, τότε θα χρειαζόταν τόσο χώρο, όσο δύο φορές το μέγεθος των βίντεο του. Προφανώς κάτι τέτοιο δεν συμβαίνει. Ένα άλλο παράδειγμα πολλαπλών αναπαραστάσεων είναι το μενού ενός εστιατορίου. Το εστιατόριο μπορεί να παρουσιάζει τον πόρο μενού, στις διάφορες εφαρμογές

Κεφάλαιο 2. Υπόβαθρο 8 που το ζητάνε, με αναπαραστάσεις όπως HTML, XML, JSON, CSV ή απλό κείμενο. Πάντα θα παρουσιάζει το ίδιο μενού με τα ίδια προϊόντα. Απλώς κάθε φορά θα τα παρουσιάζει με διαφορετικό τρόπο. Είναι σα να διατηρεί καταλόγους διαφορετικού στυλ για λόγους αισθητικής. Με την διαφορά ότι στον Παγκόσμιο Ιστό το διακύβευμα δεν είναι η αισθητική, αλλά η συμβατότητα με τις εφαρμογές μέσω των διαφορετικών αναπαραστάσεων. Η τελευταία αυτή πρόταση μας δίνει το έρεισμα να ξανά αναφερθούμε στον Παγκόσμιο Ιστό ως πλατφόρμα εφαρμογών. Προκειμένου να βελτιωθεί ο Παγκόσμιος Ιστός ως πλατφόρμα εφαρμογών είναι απαραίτητο να είναι φιλικός στις εφαρμογές. Συνεπώς διαπιστώθηκε ότι πρέπει να γίνει προσεκτική επιλογή του είδους και του πλήθους αναπαραστάσεων. Η διαπίστωση αυτή συνδέεται με την χαοτική διάσταση του Παγκόσμιου Ιστού. Αν κάθε προγραμματιστής εφαρμογής δημιουργούσε τις δικές του αναπαραστάσεις, όπως του επιτρέπεται, τότε η επικοινωνία εφαρμογών διαφορετικών προγραμματιστών θα ήταν δύσκολη έως αδύνατη. Άρα αυτόματα εμφανίζεται ή ανάγκη καθιέρωσης κάποιων συγκερκιμένων αναπαραστάσεων κοινής αποδοχής (επιλογή πλήθους). Το αμέσως επόμενο ερώτημα είναι ποιες αναπαραστάσεις θα επιλεγούν (επιλογή είδους). Παραδείγματος χάρη, μία αναπαράσταση ευρείας αποδοχής σήμερα είναι η JSON. 2.1.2.4 Πρωτόκολλο HTTP Το πρωτόκολλο HTTP, είναι το πρωτόκολλο επικοινωνίας εφαρμογών στον Παγκόσμιο Ιστό. Ο σκοπός του HTTP είναι να μπορούν να επικοινωνούν εφαρμογές μεταξύ τους, όχι υπολογιστές. Την επικοινωνία των υπολογιστών την αναλαμβάνει το Διαδίκτυο. Το HTTP λειτουργεί ως πρωτόκολλο ερωταπαντήσεων και βασίζεται στο μοντέλο πελάτηεξυπηρετητή (client-server). Προκειμένου να γίνει κατανοητό αυτό, ας υποθέσουμε ότι θέλουμε να επικοινωνήσουν δύο εφαρμογές μεταξύ τους. Σε έναν υπολογιστή εκτελείται μία εφαρμογή την οποία ονομάζουμε πελάτη. Σε έναν άλλο υπολογιστή εκτελείται μία εφαρμογή που την ονομάζουμε εξυπηρετητή. Σχεδιάσαμε αυτές τις εφαρμογές έτσι, ώστε ο εξυπηρετητής να εξυπηρετεί τα αιτήματα του πελάτη. Αφού ο πελάτης αποφασίσει ποιες πληροφορίες χρειάζεται από τον εξυπηρετητή, χρησιμοποιεί το πρωτόκολλο HTTP, ώστε να του μεταδώσει αυτό το αίτημα (request). Ο εξυπηρετητής εξετάζει το αίτημα του πελάτη και του στέλνει σχετική απάντηση (response) πάλι μέσω του πρωτοκόλλου HTTP (εικόνα 2.3). Η διαδικασία αυτή εξηγεί την έννοια πρωτόκολλο ερωταπαντήσεων βασισμένο στο μοντέλο πελάτη-εξυπηρετητή. Η επικοινωνία μέσω HTTP περιορίζεται σε συγκεκριμένες μεθόδους ή αλλιώς ρήματα. Τα ρήματα αυτά αντιστοιχούν σε τύπους αιτημάτων του πελάτη προς τον εξυπηρετητή. Μέχρι σήμερα τα ρήματα αυτά είναι τα εξής [11]:

Κεφάλαιο 2. Υπόβαθρο 9 Εικόνα 2.3: Το μοντέλο πελάτη-εξυπηρετητή GET - Ανάκτηση resource POST - Δημιουργία καινούργιου resource PUT - Αντικατάσταση resource DELETE - Διαγραφή resource PATCH - Ενημέρωση resource OPTIONS - Ανάκτηση διαθέσιμων ρημάτων που υποστηρίζει ο εξυπηρετητής TRACE - Ανάκτηση του τελικού αποδέκτη του HTTP αιτήματος HEAD - Ανάκτηση μόνο του header μίας HTTP απάντησης CONNECT - Σύνδεση μέσω proxy εξυπηρετητή, ο οποίος μπορεί να παίξει τον ρόλο ενός tunnel Ένα αίτημα HTTP από έναν πελάτη σε έναν εξυπηρετητή έχει την παρακάτω μορφή: GET /home.html HTTP/1.1 Host: www.example.org Παράδειγμα 2.3: HTTP αίτημα πελάτη σε εξυπηρετητή Βλέπουμε ότι πρόκειται για ένα αίτημα τύπου GET. Κάθε αίτημα απευθύνεται σε έναν εξυπηρετητή. Στην προκειμένη περίπτωση ο εξυπηρετητής είναι ο www.example.org. Επίσης, εφόσον πρόκειται για αίτημα GET, προσδιορίζεται και το resource προς ανάκτηση μέσω του path /home.html. Το path μαζί με τον host και το http scheme (όπως προσδιορίζεται μετά το path στο αίτημα), συνθέτουν το URI του resource. Η απάντηση του εξυπηρετητή έχει την παρακάτω μορφή: Παράδειγμα 2.4: HTTP απάντηση εξυπηρετητή σε πελάτη HTTP/1.0 200 OK Content Type: text/html; charset=utf 8 <html>

Κεφάλαιο 2. Υπόβαθρο 10 <head> <title>example.org The World Wide Web</title> </head> <body> <p>the World Wide Web, abbreviated as WWW and commonly known...</p> </body> </html> Στην απάντηση ο εξυπηρετητής απαντάει με 200 OK, δηλώνοντας ότι το αίτημα διεκπεραιώθηκε επιτυχώς. Το κομμάτι πριν το κενό ονομάζεται header. Ο header περιλαμβάνει τις τεχνικές πληροφορίες της απάντησης. Το κομμάτι μετά το κενό ονομάζεται body. Στο body τοποθετείται η (πιθανή) αναπαράσταση του resource (στην προκειμένη, που ζητήθηκε μέσω GET). Το 200 OK ονομάζεται status code. Το status code αποδίδει συνοπτικά το αποτέλεσμα του αιτήματος. Αποτελείται από ένα νούμερο και ένα σύντομο μήνυμα. Γνωστά status codes είναι π.χ. το 200 OK, 404 Not Found και το 500 Internal Server Error. Τα status codes είναι προκαθορισμένα από την εκάστοτε τυποποίηση του HTTP [15], αλλά υποστηρίζονται και διαφορετικά είδη. Τα status codes είναι χρήσιμα για τους ανθρώπους. Ένας προγραμματιστής μπορεί να σχεδιάσει την Web εφαρμογή του έτσι ώστε αυτή να τα καταλαβαίνει και να δρα ανάλογα. Μέχρι στιγμής είδαμε πώς ο Παγκόσμιος Ιστός πήρε την σημερινή του μορφή και αναδείξαμε την προγραμματιστική του φύση. Αναλύσαμε επίσης τις αρχιτεκτονικές του αρχές οι οποίες έπαιξαν καθοριστικό ρόλο στην εξάπλωσή του. Όχι όμως μόνο στην εξάπλωσή του αλλά και στην καθιέρωσή του ως πλατφόρμα εφαρμογών. Οι τέσσερις αυτές αρχές (resources, resource representations, URIs και HTTP) αποτελούν ένα κατανοητό σετ εργαλείων, μία βάση, μία πλατφόρμα, πάνω στην οποία μπορούμε να αναπτύξουμε εφαρμογές Παγκόσμιου Ιστού. Με τις τέσσερις αυτές αρχιτεκτονικές στο μυαλό, μπορούμε να εξετάσουμε πως ο Παγκόσμιος Ιστός μπορεί να βελτιωθεί, ώστε να είναι πιο φιλικός στην ανάπτυξη εφαρμογών. 2.1.3 Διδακτορική Διατριβή Roy Fielding Το Representational State Transfer (REST) είναι ένα σετ κανόνων. Οι κανόνες αυτοί οριοθετούν και προσδιορίζουν το αρχιτεκτονικό στυλ σχεδιασμού ενός υπολογιστικού συστήματος το οποίο ανταλλάσσει πληροφορίες μέσω ενός δικτύου. Αν η αρχιτεκτονική του συστήματος ακολουθεί αυτούς τους κανόνες, τότε η αρχιτεκτονική θεωρείται RESTful, άρα πρόκειται για σύστημα REST. Η ιδέα των REST συστημάτων εμφανίζεται μόλις 6 χρόνια από την ίδρυση του Παγκόσμιου Ιστού. Εμπνευστής της ιδέας ήταν ο Roy Thomas Fielding. Ο Fielding σχεδίασε το REST την περίοδο 1996-1999 και παρουσίασε το τελικό του έργο το 2000 στην διδακτορική του διατριβή με τίτλο Architectural Styles and the Design of Network-based Software Architectures [7]. Όλη η διδακτορική διατριβή είναι ιδιαίτερα επηρεασμένη από την ραγδαία εξέλιξη του Παγκόσμιου Ιστού και την εμφάνιση των φυλλομετρητών την εποχή εκείνη. Αξιοσημείωτο είναι το γεγονός ότι ο Roy Fielding, ταυτόχρονα με το REST, συμμετείχε με κεντρικό ρόλο στην ανάπτυξη μιας τυποποιημένης εκδοχής του πρωτοκόλλου HTTP. Πρόκειται για τις εκδόσεις 1.0 και 1.1 του HTTP. Η μεγάλη αποδοχή του Παγκόσμιου Ιστού ανέδειξε την ανάγκη να υπάρχει ένα κοινό σχεδιαστικό σημείο αναφοράς, για όλους τους ανθρώπους που ανέπτυσσαν λογισμικό τον Παγκόσμιο Ιστό (και

Κεφάλαιο 2. Υπόβαθρο 11 άρα χρησιμοποιούσαν το πρωτόκολλο HTTP). Ο Roy Fielding προκειμένου να πετύχει αυτό το κοινό σημείο αναφοράς, χρησιμοποίησε το REST, ώστε να εντοπίσει τα προβλήματα στην υπάρχουσα έκδοση του HTTP. Αφού τα εντόπισε, σχεδίασε την νέα έκδοση του HTTP με τέτοιον τρόπο ώστε να συνάδει με την φιλοσοφία του REST. Υπό αυτή την έννοια το HTTP/1.1 είναι RESTful. Το REST όμως, παρά τον ισχυρό δεσμό του με το HTTP, δεν αφορά μόνο συστήματα Παγκόσμιου Ιστού. Τεχνικά μιλώντας, οι κανόνες REST μπορούν να αξιολογήσουν οποιοδήποτε σύστημα το οποίο ανταλλάσσει πληροφορίες μέσω ενώς δικτύου. Σήμερα, παρ όλο που έχουν περάσει πάνω από 15 χρόνια από την αρχική ιδέα, τα REST συστήματα έχουν επικρατήσει έναντι όλων των ανταγωνιστών τους. Η λογική REST παραμένει σύγχρονη και αξιοποιείται συστηματικά από την σημερινή βιομηχανία λογισμικού για τον σχεδιασμό υπηρεσιών Παγκόσμιου Ιστού. Στην συνέχεια παραθέτουμε τις παρακάτω προϋποθέσεις ή περιορισμούς που ορίζει ο Fielding στο κεφάλαιο 5 της διατριβής του και που ένα REST σύστημα πρέπει να ακολουθεί: Εξυπηρετητής - Πελάτης (Client - Server) Ένα σύστημα REST πρέπει να ακολουθεί το μοντέλο πελάτη-εξυπηρετητή. Ο διαχωρισμός του πελάτη από τον εξυπηρετητή σημαίνει διαχωρισμός της διεπαφής χρήστη από την αποθήκευση των δεδομένων. Έτσι μπορούμε να αναπτύξουμε αυτά τα δύο συστήματα ξεχωριστά: μπορούμε να κατασκευάσουμε την διεπαφή για διάφορες πλατφόρμες (portability) και να βελτιώσουμε την κλιμάκωση του συστήματος απλοποιώντας τα κομμάτια του εξυπηρετητή (scalability). Εικόνα 2.4: REST: Client-Server [7] Κατάσταση πελάτη ανεξάρτητη από τον εξυπηρετητή (Stateless) Ο πελάτης οφείλει να στέλνει στον εξυπηρετητή όλη την πληροφορία που απαιτείται ώστε να γίνει το αίτημά του κατανοητό. Δεν προβλέπεται ο εξυπηρετητής να αποθηκεύει δεδομένα για την κατάσταση του πελάτη. Ως εκ τούτου ο πελάτης δεν πρέπει να αναμένει τέτοια συμπεριφορά. Αυτό έχει το πλεονέκτημα ότι ελαφρύνει το φορτίο του εξυπηρετητή. Ταυτόχρονα όμως αυτό καθίσταται εφικτό με την επιπρόσθετη φόρτωση της δικτυακής κίνησης (λόγω του overhead που εισάγει ο περιορισμός). Περαιτέρω ο εξυπηρετητής δεν έχει έλεγχο της συμπεριφοράς του πελάτη. Δυνατότητα αξιοποίησης μηχανισμών γρήγορης ανάκτησης (Cache) Οι απαντήσεις ενός εξυπηρετητή πρέπει υποχρεωτικά να προσδιορίζουν αν είναι cachable ή non-cachable. Δηλαδή αν μπορούν να ανακτηθούν ξανά με γρήγορο τρόπο. Αν μπορούν, τότε ένα cache το οποίο έχει τοποθετηθεί στην μεριά του πελάτη, έχει το δικαίωμα να αποθηκεύσει τα δεδομένα της απάντησης και να τα στείλει στον πελάτη

Κεφάλαιο 2. Υπόβαθρο 12 Εικόνα 2.5: REST: Stateless [7] εφόσον αυτός τα ξαναζητήσει. Έτσι πετυχαίνουμε και γρηγορότερες απαντήσεις και αποσυμφόρηση φορτίου από τον εξυπηρετητή. Εικόνα 2.6: REST: Cache [7] Ομοιόμορφη Διεπαφή (Uniform Interface) Η ομοιόμορφη διεπαφή είναι ένα βασικό στοιχείο του REST. Η ομοιόμορφη διεπαφή ορίζει ότι όλα τα συστήματα σε ένα δίκτυο επικοινωνούν και συνεργάζονται με τον ίδιο τρόπο. Τα συστήματα μπορούν να βασίζονται στο γεγονός ότι η διεπαφή θα παραμείνει ως έχει, όντας ομοιόμορφη, και να αναπτύσσονται ανεξάρτητα το ένα από το άλλο. Έτσι και βελτιώνεται η απλότητα του συνολικού συστήματος και ενθαρρύνεται η εξέλιξη των επί μέρους συστημάτων. Το αντάλλαγμα είναι ότι μειώνεται οι αποδοτικότητα των εφαρμογών που έχουν ειδικές ανάγκες (μη καλυπτόμενες από την ομοιόμορφη διεπαφή). Προκειμένου να επιτευχθεί το Uniform Interface ο Fielding ορίζει τέσσερις επιπρόσθετους περιορισμούς στον σχεδιασμό της διεπαφής: 1. Δυνατότητα ταυτοποίησης/αναγνώρισης των resources 2. Επεξεργασία των resources μέσω resource represenations 3. Τα μηνύματα μεταξύ πελάτη-εξυπηρετητή πρέπει να περιγράφουν τα ίδια το νόημά τους 4. Hypermedia As The Engine Of Application State - HATEOAS

Κεφάλαιο 2. Υπόβαθρο 13 Εικόνα 2.7: REST: Uniform Interface (orb σημαίνει object request broker) [7] Σύστημα Πολλών Επιπέδων (Layered System) Ο περιορισμός αυτός ορίζει ότι το συνολικό σύστημα θα χωρίζεται σε επίπεδα. Τα επίπεδα αφορούν την πληροφορία που θα διατηρούν. Μέσω των επιπέδων μπορούν να διατηρούνται παλιότερες υπηρεσίες του συστήματος που αφορούν μόνο τους παλιότερους πελάτες. Επίσης μέσω της διαβάθμισης μοιράζεται τόσο το επεξεργαστικό όσο και το δικτυακό φορτίο. Η διαβάθμιση μπορεί να προκαλέσει θέματα απόκρισης και overhead. Για να αντιμετωπιστεί αυτό μπορεί να αξιοποιηθεί περαιτέρω ο περιορισμός που αφορά το caching. Εικόνα 2.8: REST: Layered System [7] Διάθεση κώδικα ύστερα από αίτημα (Code-on-Demand) - προεραιτικό Ο περιορισμός αυτός προβλέπει την δυνατότητα του πελάτη να κατεβάζει και να εκτελεί κώδικα από τον εξυπηρετητή. Με αυτό τον τρόπο μειώνεται το πλήθος των χαρακτηριστικών που πρέπει να σχεδιαστούν για τον πελάτη και άρα η συνολική του πολυπλοκότητα. Ο περιορισμός είναι προεραιτικός με την έννοια ότι σχεδιάζουμε με βάση αυτόν, αλλά ενδεχομένως να μην τον χρησιμοποιούμε σε κάποιες περιπτώσεις.

Κεφάλαιο 2. Υπόβαθρο 14 Εικόνα 2.9: REST [7] 2.1.4 Ο Παγκόσμιος Ιστός ως πλατφόρμα εφαρμογών Όπως συμβαίνει με όλα τα συστήματα ευρείας αποδοχής, έτσι και με τον Παγκόσμιο Ιστό: τα δομικά του στοιχεία συνεχώς απλοποιούνται. Η απλοποίηση αυτή στοχεύει στην εύρεση και την υλοποίηση χαρακτηριστικών, που αφορούν και εξυπηρετούν τους περισσότερους δυνατούς χρήστες του συστήματος. Στην περίπτωση του Παγκόσμιου Ιστού χρήστες είναι και οι προγραμματιστές εφαρμογών, έμμεσα. Έτσι η απλοποίηση των δομικών στοιχείων του Παγκόσμιου Ιστού στοχεύει και στην διευκόλυνση των προγραμματιστών εφαρμογών. Υπό αυτή την έννοια έχει διαμορφωθεί το εξής σχεδιαστικό μοντέλο στον Παγκόσμιο Ιστό: οι σχεδιαστές των διαφόρων πρωτοκόλλων και εννοιών στοχεύουν τους προγραμματιστές και οι τελευταίοι αναλαμβάνουν την κατά τον χρήστη σχεδίαση εφαρμογών. Άρα η σχεδίαση σε πρώτο επίπεδο (τεχνικό), αφορά όσους εμπλέκονται στον σχεδιασμό εφαρμογών (Web Applications) ή υπηρεσιών (Web Services) Παγκόσμιου Ιστού. Έτσι ο Tim Berners-Lee, ο Roy Fielding και πολύ άλλοι, σχεδίαζαν πάντα πρώτα για τον μηχανικό λογισμικού. Συνεπώς ο Παγκόσμιος Ιστός, το πρωτόκολλο HTTP και τα συστήματα REST έχουν σχεδιαστεί με βασικό μέλημα τον μηχανικό λογισμικού. Έχουμε ήδη αναλύσει τα URIs, τους πόρους, τις αναπαραστάσεις και το http. Δύο ακόμη βασικά στοιχεία που διέπουν τον Παγκόσμιο Ιστό σήμερα και συνεισφέρουν στην ανάπτυξη εφαρμογών είναι η έννοια HATEOAS και η έννοια της ομοιόμορφης διεπαφης. 2.1.4.1 Hypermedia as the engine of application state - HATEOAS Η έννοια hypermedia as the engine of the application state, είναι μία έννοια η οποία επίσης πρωτοεμφανίστηκε στην διδακτορική διατριβή το Roy Fielding. Πρόκειται για μία έννοια η οποία αποτελεί βασικό δόγμα του μοντέλου REST, παρ όλο που δεν αναφέρεται ρητά ως μία από τις 6 σχεδιαστικές αρχές του (βρίσκεται εντός του 4 ου περιορισμού Uniform Interface). Αποτελεί βασικό σημείο σύγχυσης των μηχανικών λογισμικού και ενδεχομένως την πιο πολύπλοκη ή αμφιλεγόμενη έννοια από μία κατά τα άλλα απλή φιλοσοφία. Καθώς πλοηγούμαστε στον Παγκόσμιο Ιστό, έχουμε συνηθίσει να επιλέγουμε

Κεφάλαιο 2. Υπόβαθρο 15 υπερσυνδέσμους και να συμπληρώνουμε φόρμες. Οι ενέργειες αυτές μας οδηγούν σε νέες επιλογές: νέους υπερσυνδέσμους ή/και νέες φόρμες προς συμπλήρωση. Αυτό που συμβαίνει στην πραγματικότητα είναι ότι ακολουθούμε ένα πρωτόκολλο, μία διαδικασία, ώστε να πετύχουμε έναν τελικό σκοπό. Ένα πολύ κλασσικό παράδειγμα πρωτοκόλλου είναι η παραγγελία ενός προϊόντος από ένα ηλεκτρονικό κατάστημα, όπως το Amazon 5. Το πρωτόκολλο είναι εμφανές: Βρίσκουμε ένα προϊόν, το προσθέτουμε στο καλάθι, επιλέγουμε checkout, προσθέτουμε στοιχεία αποστολής, επιλέγουμε τρόπο πληρωμής, πληρώνουμε και η παραγγελία μας επικυρώνεται. Το Amazon μας καθοδηγεί κατά την διαδικασία αυτή με υπερσυνδέσμους. Με την ίδια λογική το Facebook μας καθοδηγεί στην ανάρτηση ενός post, το Youtube στον σχολιασμό ενός βίντεο, η τοπική ηλεκτρονική εφημερίδα στην ανάγνωση ενός άρθρου και η πανεπιστημιακή πλατφόρμα στην υποβολή μιας εργασίας. Όλες αυτές οι διαδικασίες αποτελούνται από μία σειρά βημάτων. Η μετάβαση σε κάθε επόμενο βήμα πραγματοποιείται με την βοήθεια υπερσυνδέσμων. Κάθε επιλογή υπερσυνδέσμου οδηγεί σε νέα κατάσταση της εφαρμογής. Αυτό είναι η έννοια του υπερμέσου (hypermedia): Η μετάβαση από τον ένα υπερσύνδεσμο στον άλλο οδηγεί στην αλλαγή της κατάστασης της εφαρμογής (application state). Έτσι στην παραγγελία μεταβαίνουμε από την κατάσταση έχω γεμίσει το καλάθι αγορών στην πληρώνω τα προϊόντα που επέλεξα. Τα πρωτόκολλα των διάφορων διαδικασιών μπορεί να γίνουν περισσότερο πολύπλοκα: μπορούμε να προσθέσουμε κι άλλα προϊόντα αφού επιλέξουμε checkout, μπορούμε να ακυρώσουμε την παραγγελία, να επεξεργαστούμε το σχόλιο, να ανεβάσουμε νέα έκδοση της εργασίας κ.λ.π.. Η πολυπλοκότητα των πρωτοκόλλων οδήγησε στα Domain Application Protocols ή DAP. Δηλαδή πρωτόκολλα που αφορούν ένα συγκεκριμένο επιχειρησιακό αντικείμενο (domain). Αυτό σημαίνει ότι τα πρωτόκολλα των επιχειρήσεων, των φορέων και των οργανισμών είναι ειδικά (από τεχνικής άποψης). Έτσι πρέπει η καθοδήγηση του χρήστη να είναι σαφής και απλή. Η καθοδήγηση επιτυγχάνεται με το HATEOAS. Το HATEOAS είναι η τεχνική έκδοση του DAP. Κατά HATEOAS η εκάστοτε εφαρμογή παρέχει μόνο ένα endpoint, δηλαδή ένα σημείο εισαγωγής στο σύστημα. Η περαιτέρω πλοήγηση καθίσταται δυνατή μέσω των hypermedia. Το endpoint είναι το μόνο που χρειάζεται να ξέρει η εφαρμογή, ώστε να μπορέσει να πλοηγηθεί. Το endpoint δεν είναι άλλο από ένα αρχικό URI. Ας διευκρινίσουμε τι σημαίνει κατάσταση εφαρμογής. Αν εφαρμογή σημαίνει πρόγραμμα ηλεκτρονικού υπολογιστή με συγκεκριμένο στόχο, τότε πρωτόκολλο εφαρμογής είναι μία ακολουθία βημάτων που οδηγούν σε αυτό τον στόχο. Κατάσταση της εφαρμογής είναι ένα στιγμιότυπο αυτού του πρωτοκόλλου. Κατά HATEOAS, οι μεταβάσεις στην επόμενη κατάσταση διαφημίζονται στις απαντήσεις του εξυπηρετητή προς τον πελάτη (HTTP απαντήσεις). Έτσι ο πελάτης μπορεί να επιλέξει σε πια επόμενη κατάσταση θέλει να μεταβεί, αφού διαβάσει την απάντηση του εξυπηρετητή. Εδώ πρέπει να επισημάνουμε ότι οι υπερσύνδεσμοι που παρουσιάζονται στον πελάτη είναι τρέχουσες καταστάσεις πόρων και όχι εφαρμογής. Η κατάσταση εφαρμογής είναι το σύνολο των καταστάσεων των πόρων του παρουσιάζονται (πιθανόν και από παραπάνω από μία υπηρεσίες του ίδιου εξυπηρετητή). Ας το εξηγήσουμε αυτό με το παρακάτω παράδειγμα [31]: Παράδειγμα 2.5: Απάντηση εξυπηρετητή με Hypermedia Control HTTP/1.1 200 OK Content Length: 342 Content Type: application/xml Date: Sun, 21 Mar 2010 17:04:10 GMT 5

Κεφάλαιο 2. Υπόβαθρο 16 <payment xmlns =http://schemas.restbucks. com> <amount>2.0</amount> <cardholdername>michael Faraday</cardholderName> <cardnumber>11223344</cardnumber> <expirymonth>12</expirymonth> <expiryyear>12</expiryyear> <link rel= http://relations.restbucks.com/receipt href= http://restbucks.com/receipt/1234 /> <link rel= http://relations.restbucks.com/order href= http://restbucks.com/order/1234 /> </payment> Το παραπάνω αποτελεί κομμάτι της HTTP απάντησης μίας υποθετικής καφετέριας που λειτουργεί στον Παγκόσμιο Ιστό. Συγκεκριμένα είναι απάντηση η οποία στέλνεται στον πελάτη, αφού παραγγείλει και πληρώσει το προϊόν. Στην απάντηση εμφανίζονται δύο νέοι για τον πελάτη υπερσύνδεσμοι (μπλε χρώμα). Ένας που οδηγεί στην παρακολούθηση της εξέλιξης της παραγγελίας του και ένας που οδηγεί στην έκδοση απόδειξης. Οι πόροι εδώ είναι η παραγγελία και η απόδειξη. Οι σύνδεσμοι των πόρων αυτών αντιπροσωπεύουν την τρέχουσα κατάστασή τους (resource state). Το resource receipt μόλις δημιουργήθηκε και το resource order βρίσκεται στην κατάσταση διεκπεραίωσης. Οι δύο σύνδεσμοι μαζί αντιπροσωπεύουν την τρέχουσα κατάσταση της εφαρμογής (application state). Η εφαρμογή εδώ είναι η διαδικασία παραγγελίας της καφετέριας και βρίσκεται στην κατάσταση ολοκληρωμένης πληρωμής. Η καθοδήγηση του πελάτη (client) με hypermedia είναι η έννοια μηχανή ( engine ) του HATEOAS. Οι hypermedia μηχανές σχεδιάζονται τόσο για αξιοποίηση από εφαρμογές, όσο και από ανθρώπους. Όταν η καθοδήγηση αφορά εφαρμογές, τότε πρόκειται για αυτόνομες εφαρμογές. Δηλαδή εφαρμογές που μπορούν να πλοηγούνται σε υπηρεσίες του Παγκόσμιου Ιστού χωρίς την ανθρώπινη παρέμβαση. Τέτοιες εφαρμογές παραδείγματος χάρη αναπτύσσουν οι μηχανές αναζήτησης. Η σύγχυση που επικρατεί γύρω από την χρησιμότητα του HATEOAS, έχει να κάνει με το πώς αυτό υλοποιείται. Οι προγραμματιστές εφαρμογών Παγκόσμιου Ιστού προτιμούν να διαβάζουν το documentation της υπηρεσίας, το οποίο περιγράφει όλο το DAP. Έτσι γνωρίζουν εκ των προτέρων τις μεταβάσεις (hypermedia). Άρα δεν σχεδιάζουν εφαρμογές που τις ανακαλύπτουν καθώς πλοηγούνται στην υπηρεσία. Δηλαδή η καθοδήγηση δεν γίνεται από τα hypermedia αλλά από τον προγραμματιστή, σχεδιαστικά. Αντίθετα ο Roy Fielding προσδιορίζει ότι το μόνο που πρέπει να ξέρει ο πελάτης, είναι τα είδη των αναπαραστάσεων που χρησιμοποιεί η υπηρεσία για τους πόρους της. Επειδή όμως δεν περιγράφεται στην διδακτορική του διατριβή τι σημαίνει αυτό πρακτικά, η σωστή υλοποίηση REST συστημάτων αποτελεί σχεδιαστική πρόκληση. Στο σημείο αυτό πρέπει να αναφέρουμε και το Richardson Maturity Model [31]. Κατά το μοντέλο αυτό ο Richardson αξιολογεί τις διάφορες υπηρεσίες Παγκόσμιου Ιστού πόσο REST είναι. Το Richardson Maturity Model φαίνεται στην εικόνα 2.10. Σύμφωνα με το μοντέλο αυτό στο επίπεδο 0 είναι οι RPC-Style αρχιτεκτονικές, στο επίπεδο 1 οι αρχιτεκτονικές που εισάγουν resources, στο επίπεδο 2 αυτές που λειτουργούν και με Uniform Interface και τέλος REST αυτές που αξιοποιούν και το HATEOAS.

Κεφάλαιο 2. Υπόβαθρο 17 Εικόνα 2.10: Το Richardson Maturity Model 6 2.1.4.2 Ομοιόμορφη Διεπαφή - Uniform Interface στον Παγκόσμιο Ιστό Ομοιόμορφη Διεπαφή στον Παγκόσμιο Ιστό σημαίνει, όλες οι μέθοδοι της διεπαφής να έχουν κοινή ερμηνεία για τις εφαρμογές. Στον Παγκόσμιο Ιστό το πρωτόκολλο εφαρμογών είναι το HTTP. Έτσι οι μέθοδοι της διεπαφής είναι οι μέθοδοι του HTTP. Κατά την Ομοιόμορφη Διεπαφή, πρέπει οι HTTP μέθοδοι να έχουν κοινή ερμηνεία για όλους. Κατά REST δεν απαιτείται η ερμηνεία αυτή να είναι ας πούμε ο ορισμός των μεθόδων HTTP του Tim Berners-Lee. Η πραγματική απαίτηση είναι όλες οι υπηρεσίες Παγκόσμιου Ιστού να χρησιμοποιούν τις μεθόδους του HTTP με τον ίδιο τρόπο. Για παράδειγμα το ευρέως διαδεδομένο ρήμα GET, να σημαίνει για όλους ανάκτηση πόρου. Να μην εμφανίζονται δηλαδή αιτήματα του στυλ GET../method=flickr.photos.delete το οποίο διαγράφει το resource φωτογραφία. Ρήμα το οποίο έχει περισσότερο την ανάγκη συμβάσεως είναι το POST, το οποίο χρησιμοποιείται για αποστολή δεδομένων. Μία γνωστή σύμβαση για τα ρήματα POST, GET, PUT, DELETE είναι η Create Read Update Delete ή CRUD. Πρόκειται για μία σύμβαση που εμφανίστηκε στα συστήματα αρχειοθέτησης των λειτουργικών συστημάτων (file systems) και αφορά την δημιουργία, την ανάγνωση, την επεξεργασία και την διαγραφή αρχείων. Κατά την σύμβαση αυτή τα 4 ρήματα του Παγκόσμιου Ιστού παίρνουν την παρακάτω σημασία: POST: Δημιουργία resource GET: Ανάκτηση resource PUT: Ενημέρωση/Επεξεργασία resource DELETE: Διαγραφή resource Επιπρόσθετα Ομοιόμορφη Διεπαφή στο HTTP σημαίνει ότι και οι απαντήσεις θα είναι επεξηγηματικές για τον πελάτη. Δηλαδή τα status codes θα περιέχουν χρήσιμη 6

Κεφάλαιο 2. Υπόβαθρο 18 Verb Safe Idempotent POST GET PUT DELETE Πίνακας 2.1: Safety & Idempotency των POST, GET, PUT, DELETE πληροφορία, βάση της οποίας ο πελάτης θα αντιλαμβάνεται την κατάσταση του εξυπηρετητή και θα μπορεί να αποφασίσει τα επόμενα βήματά του. Τέλος κατά τον σχεδιασμό του REST συστήματος ο μηχανικός πρέπει να λαμβάνει υπ όψιν και τις ιδιότητές των HTPP verb ως προς την ασφάλεια (safety) και την δυνατότητα επανάληψης του αιτήματος χωρίς να προκληθεί περαιτέρω αλλαγή (idempotency). Το safety αφορά το πόσο επηρεάζει τον εξυπηρετητή το αίτημα του verb ενώ το idempotency το αν η επανάληψή του αιτήματος προκαλεί αλλαγές. Στον πίνακα 2.1 συνοψίζονται ποία από τα POST, GET, PUT, DELETE είναι safe ή idempotent. 2.1.5 RESTful Web APIs & OpenAPI Specification Η αποδοχή των RESTful υπηρεσιών στον Παγκόσμιο Ιστό σήμερα είναι μεγάλη. Η τεχνολογία REST επικράτησε και όλο και περισσότεροι πάροχοι υπηρεσιών Παγκόσμιου Ιστού την αξιοποιούν. Η διάθεση των υπηρεσιών προς το κοινό και τους προγραμματιστές εφαρμογών, γίνεται μέσω των RESTful Web APIs. 2.1.5.1 APIs API σημαίνει Application Programming Interface ή Διεπαφή Προγραμματισμού Εφαρμογών. Ας εξετάσουμε το εξής παράδειγμα για να συλλάβουμε αυτή την έννοια. Σε ένα αυτοκίνητο, ο κατασκευαστής παρέχει στον οδηγό τιμόνι, κιβώτιο ταχυτήτων, πεντάλ, κουμπιά, καντράν. Μέσω του τιμονιού ο οδηγός στέλνει οδηγίες στους τροχούς, ενώ το καντράν λαμβάνει σήματα από την μηχανή. Αντίστοιχα τα διάφορα κουμπιά στέλνουν εντολές στο ηλεκτρονικό σύστημα του αυτοκινήτου. Σίγουρα κάποιος δεν μπορεί να χρησιμοποιήσει όλα αυτά τα χαρακτηριστικά αν δεν έχει δίπλωμα οδήγησης. Δεν χρειάζεται όμως να είναι μηχανικός αυτοκινήτων για να οδηγήσει το αυτοκίνητο. Αυτό διότι ο κατασκευαστής έχει φροντίσει να παρέχει στον οδηγό μία αφαιρετική αναπαράσταση των εσωτερικών συστημάτων του αυτοκινήτου. Η αναπαράσταση είναι το τιμόνι, τα πεντάλ, το κιβώτιο ταχυτήτων, το καντράν, τα κουμπιά, τα χερούλια. Έτσι ο οδηγός αρκεί μόνο να γνωρίζει, πώς να χειρίζεται (μέσω διπλώματος και manuals) αυτή την αναπαράσταση. Αυτή η αφαιρετική αναπαράσταση στον προγραμματισμό είναι το Application Programming Interface. Τα APIs αφορούν υπολογιστικά συστήματα. Δεδομένου ενός συστήματος, το API αποτελεί μία εργαλειοθήκη του. Η εργαλειοθήκη αυτή έχει δυνατότητα να χρησιμοποιεί κάποιες από τις λειτουργίες του συστήματος. Μάλιστα έχει σχεδιαστεί με τέτοιο τρόπο, ώστε να είναι εύχρηστη και εξυπηρετεί ένα συγκεκριμένο πεδίο εφαρμογής του συστήματος. Ένας προγραμματιστής μπορεί να αναπτύξει εφαρμογές λογισμικού αξιοποιώντας το API. Όπως ο οδηγός αυτοκινήτου δεν χρειάζεται να ξέρει να τις τεχνικές λεπτομέρειες του αυτοκινήτου, έτσι και ο προγραμματιστής δεν χρειάζεται να ξέρει τις τεχνικές λεπτομέρειες του συστήματος. Αν δεν υπήρχε το API, τότε θα έπρεπε ο προγραμματιστής

Κεφάλαιο 2. Υπόβαθρο 19 να το αναπτύξει μόνος του, αφού πρώτα μελετούσε προσεκτικά το σύστημα. Ας εξετάσουμε και το παρακάτω παράδειγμα: Ένας σχεδιαστής λογισμικού σχεδιάζει ένα πολύ καλό και σύνθετο λογισμικό το οποίο μπορεί να πραγματοποιεί αγοραπωλησίες και άλλες ενέργειες σε διεθνή χρηματιστήρια. Ένας άλλος προγραμματιστής θέλει να αναπτύξει μία εφαρμογή που πραγματοποιεί στατιστική ανάλυση σε δεδομένα χρηματιστηρίων. Ένας τρίτος προγραμματιστής θέλει να σχεδιάσει έναν αυτόνομο πράκτορα που πραγματοποιεί μόνος του αγοραπωλησίες. Ένας τέταρτος θέλει να φτιάξει μία ιστοσελίδα που να δείχνει σε πραγματικό χρόνο όλους τους δείκτες των χρηματιστηρίων συγκεντρωμένους. Ας υποθέσουμε ότι οι τρεις τελευταίοι προγραμματιστές είναι μεγάλες εταιρείες. Όπως επίσης ότι υπάρχουν και πολλές άλλες εταιρείες με τις δικές τους ιδέες και συγκεκριμένες υλοποιήσεις. Όλα αυτά τα ενδιαφερόμενα μέρη (stakeholders), θα τα εξυπηρετούσε να μπορούν να αξιοποιήσουν το καλό λογισμικό του πρώτου προγραμματιστή λόγω κόστους, χρόνου και τεχνογνωσίας. Ο πρώτος προγραμματιστής αντιλαμβάνεται αυτό το ενδιαφέρον για το λογισμικό του και αποφασίζει να δώσει την δυνατότητα στους προγραμματιστές των εταιρειών να το χρησιμοποιήσουν. Επειδή όμως είναι καλός προγραμματιστής και γνωρίζει καλά της αρχές σχεδίασης λογισμικού, διαπιστώνει ότι θα είναι πολύ δύσκολο να αξιοποιήσουν οι άλλοι προγραμματιστές τον κώδικά του. Για παράδειγμα θα εξυπηρετούσε ιδιαίτερα τον προγραμματιστή του αυτόνομου πράκτορα αν υπήρχε μία συνάρτηση της μορφής buy('nasdaq', 'GOOGL', targetprice) αντί μία ακολουθία εντολών connecttoken = connectstockexchange('nasdaq') buyorder = createbuyorder(connecttoken, 'GOOGL', targetprice) placebuyorder(buyorder,connecttoken) διότι δεν τον ενδιαφέρει ο μηχανισμός σύνδεσης και αγοραπωλησίας αυτός καθαυτός. Παρόμοια παραδείγματα ισχύουν και για τις άλλες περιπτώσεις. Έτσι ο πρώτος προγραμματιστής αναπτύσσει διεπαφές, που ανταποκρίνονται στους συγκεκριμένους σκοπούς και ανάγκες του εκάστοτε ενδιαφερόμενου. Με λίγα λόγια αυτό που αποφασίζει να σχεδιάσει ο προγραμματιστής του λογισμικού χρηματιστηρίων, είναι ένα Application Programming Interface. Δηλαδή μία διεπαφή μέσω της οποίας μπορούν τα ενδιαφερόμενα μέρη να αξιοποιήσουν τον κώδικα του, χωρίς να χρειάζεται να ξέρουν τις λεπτομέρειες που δεν τους ενδιαφέρουν. Ακριβώς όπως ο οδηγός δεν ενδιαφέρεται για την λειτουργία της μηχανής αυτής καθαυτής. Στην περίπτωση του Παγκόσμιου Ιστού, τα APIs χρησιμοποιούνται για να εκθέσουν ένα συγκεκριμένο κομμάτι μιας υπηρεσίας (π.χ. YouTube). Συγκεκριμένα, ο πελάτης (client) της υπηρεσίας, μπορεί να στείλει HTTP αιτήματα μέσω του API στην εκάστοτε υπηρεσία. Ο εξυπηρετητής της υπηρεσίας (server), πάλι μέσω του API στέλνει στον πελάτη την HTTP απάντηση. Ο προγραμματιστής Web εφαρμογών, ενσωματώνει την λογική του API στην εφαρμογή του. Όταν το Web API σχεδιάζεται ακολουθώντας την φιλοσοφία του REST, τότε το API ονομάζεται RESTful Web API.

Κεφάλαιο 2. Υπόβαθρο 20 2.1.5.2 OpenAPI Specification Αφού συγγραφεί ένα RESTful Web API, το επόμενο βήμα είναι να γραφτούν τα λογισμικά του πελάτη και του εξυπηρετητή. Προκειμένου να γίνει αυτό, μαζί με το API συντάσσεται και το λεγόμενο documentation. Το API documentation περιγράφει την λειτουργία του API με κατανοητό προς τον άνθρωπο τρόπο. Δηλαδή περιγράφονται οι πιθανές παράμετροι ενός http αιτήματος, η αναμενόμενη απάντηση, ο σκοπός της αληλεπίδρασης και άλλες τεχνικές λεπτομέρειες που εξαρτώνται από το εκάστοτε API. Οι τεχνικές αυτές πληροφορίες είναι απαραίτητες για την αξιοποίηση του API στον κώδικα του πελάτη. Ταυτόχρονα όμως, όπως εξελίσσεται το λογισμικό έτσι εξελίσσονται και τα APIs. Διορθώνονται προβλήματα, ενσωματώνονται νέες λειτουργίες και αφαιρούνται παλιές. Οι αλλαγές αυτές συνεπάγονται απαραίτητες αλλαγές στο documentation, στην εφαρμογή και στην υπηρεσία. Οι μηχανικοί πρέπει να διαβάσουν το νέο documentation, να εντοπίσουν τις αλλαγές που τους αφορούν και να ενημερώσουν το λογισμικό τους. Η εξέλιξη των API οδηγεί στην ανάγκη τακτικής ενημέρωσης του documentation από τους μηχανικούς του συστήματος. Επιπλέον οι μηχανικοί της υπηρεσίας και της εφαρμογής πρέπει να παρακολουθούν τακτικά την εξέλιξη του API. Αν αυτό δεν γίνεται, τότε οι εφαρμογές που το χρησιμοποιούν είναι δυνατόν να καταστούν μη ανταγωνιστικές ή ακόμη και μη λειτουργικές. Μάλιστα δεδομένου αυτών των χαρακτηριστικών, οι μηχανικοί συστήματος ενδέχεται να ακολουθούν ένα μετριοπαθέστερο μοντέλο εξέλιξης του API. Επειδή όλες αυτές οι επιπλοκές μεταφράζονται σε κόστος, η συνεχώς εξελισσόμενη βιομηχανία λογισμικού επιχείρησε να απλοποιήσει την διαδικασία ανάπτυξης API. Οι διάφοροι μηχανικοί των RESTful Web APIs παρατήρησαν ότι Οι βασικές αρχές του Παγκόσμιου Ιστού, ο σχεδιασμός του πρωτοκόλλου HTTP και η τεχνολογία REST, προσδίδουν κοινά χαρακτηριστικά στα διάφορα RESTful Web APIs. Έτσι ανεξαρτήτως λειτουργίας όλα τα RESTful Web APIs χρησιμοποιούν HTTP αιτήματα και απαντήσεις, HTTP ρήματα, resources, URIs κ.λ.π.. Συνεπώς, εξ αρχής, υπάρχουν τεχνικά χαρακτηριστικά τα οποία δεν διαφέρουν από RESTful Web API σε RESTful Web API Η εξέλιξη των APIs απαιτεί τον συντονισμό διαφορετικών ομάδων λογισμικού. Δηλαδή της ομάδας ανάπτυξης του API και συγγραφής του documentation, την ομάδα ανάπτυξης της υπηρεσίας και την ομάδα ανάπτυξης της εφαρμογής. Η επικοινωνία αυτή είναι επαρκώς πολύπλοκη ώστε να επηρεάζει το κόστος και την ανταγωνιστικότητα των προϊόντων. Οι παρατηρήσεις αυτές οδήγησαν στην εμφάνιση τυποποιήσεων των RESTful Web APIs. Μία τυποποίηση ενός RESTful Web API, είναι ένα ή περισσότερα τεχνικά έγγραφα, τα οποία περιγράφουν λεπτομερώς την λειτουργία και τα τεχνικά χαρακτηριστικά του. Επίσης η τυποποίηση έχει τέτοια μορφή ώστε να μπορεί να διαβαστεί από λογισμικό (machine readable format). Η πιο δημοφιλής τυποποίηση σήμερα είναι το OpenAPI Specification. Το OpenAPI Specification (γνωστό και ως Swagger) [28] είναι μία κοινή πρωτοβουλία διαφόρων εταιρειών τεχνολογίας (εικόνα 2.11). Η πρωτοβουλία ονομάζεται OpenAPI Initiative 7. Στόχος της πρωτοβουλίας είναι η δημιουργία ενός κοινού σημείου αναφοράς για τους μηχανικούς RESTful API. Όλες αυτές οι εταιρείες, αλλά και πολλές άλλες που δεν εμπλέκονται άμεσα με την τυποποίηση, χρησιμοποιούν σε πολύ μεγάλο βαθμό RESTful APIs στην επιχειρηματική τους δραστηριότητα. Ενδεικτική είναι η ερευνά 7

Κεφάλαιο 2. Υπόβαθρο 21 της apigee (μία εκ των 18), πάνω στη χρήση των δικών της API για την περίοδο 2014-2015 8. Από αυτήν μας ενδιαφέρουν οι δύο πρώτες διαφάνειες (βλ. εικόνες 2.12, 2.13). Εικόνα 2.11: Οι εταιρείες του OpenAPI Initiative Εικόνα 2.12: Διαδικτυακή κίνηση κλήσεων API της εταιρείας apigee Στο πρώτο γράφημα βλέπουμε την συνεχώς αυξανόμενη κίνηση σε όλα τα επίπεδα. Στο δεύτερο προβάλλεται το ενδιαφέρον στοιχείο ότι το μεγαλύτερο κομμάτι της πίτας των ηλεκτρονικών υπηρεσιών αφορά λύσεις B2B (Business to business). Οι εταιρείες αυτές λοιπόν έχουν διαπιστώσει ότι υπάρχει μεγάλη ανάγκη για την καθιέρωση μίας τέτοιας τυποποίησης. Οι δε υπάρχουσες λύσεις δεν αντιμετωπίζουν το πρόβλημά τους, διότι δεν είναι λύσεις κοινής αποδοχής αλλά προϊόν συμβιβασμών μεταξύ κάποιων ενδιαφερόμενων παραγόντων. Αναφέρουμε προϋπάρχουσες τυποποιήσεις στο Παράρτημα B. Το OpenAPI Specification δίνει την δυνατότητα αυτόματης παραγωγής του documentation αλλά και του κώδικα της υπηρεσίας και της εφαρμογής. Προφανώς ο κώδικας που παράγεται αφορά μόνο το API και όχι την λειτουργία της εφαρμογής ή του συστήματος. Αξίζει να επισημάνουμε ότι το OpenAPI Specification είναι ανεξάρτητο από την γλώσσα προγραμματισμού στην οποία είναι γραμμένο το εκάστοτε λογισμικό. Επίσης με κατάλληλα εργαλεία δύναται να παραχθούν και τα απαραίτητα τεστ για την δοκιμή του API. Καθώς το API εξελίσσεται, εξελίσσεται και το OpenAPI Specification. Πλέον οι διεργασίες ενημέρωσης των εξαρτώμενων από το Specification συστημάτων, υποστηρίζονται από λογισμικό. Αυτό διότι, όπως είπαμε, το OpenAPI Specification έχει 8

Κεφάλαιο 2. Υπόβαθρο 22 Εικόνα 2.13: Περιπτώσης χρήσης των ηλεκτρονικών υπηρεσιών της apigee machine readable format. Σχολιάζουμε τέλος ότι η ιδέα της τυποποίησης των RESTful Web APIs, προωθεί ακόμα καλύτερα την ιδέα του Παγκόσμιου Ιστού ως πλατφόρμα εφαρμογών. 2.1.5.3 Τεχνικά χαρακτηριστικά του OpenAPI Specification Στην υποενότητα αυτή περιγράφουμε συνοπτικά τα τεχνικά χαρακτηριστικά του OpenAPI Specification[17]. Επισημαίνουμε ότι την στιγμή συγγραφής της διπλωματικής βρισκόμαστε στο version 2 ενώ ήδη γράφεται το version 3. Το OpenAPI Specification ορίζει ένα σετ αρχείων που περιγράφουν το RESTful API. Η τυποποίηση ορίζει Την γλώσσα των αρχείων: JSON ή YAML που είναι υπερσύνολο της JSON Την δομή των αρχείων, κυρίως ότι το βασικό αρχείο ονομάζεται swagger.json και στα υπόλοιπα γίνεται παραπομπή μέσω του keyword $ref Τα Data Types (εικόνα 2.14) Το Schema Το Schema αποτελεί το βασικότερο κομμάτι της τυποποίησης. Στο Schema ορίζονται τα Objects. Τα Objects του Schema είναι τα εξής: Swagger Object Info Object Contact Object License Object Paths Object Path Item Object Operation Object External Documentation Object Parameter Object

Κεφάλαιο 2. Υπόβαθρο 23 Εικόνα 2.14: Τα Data Types του OAI Specification 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 Responses Definitions Object Security Definitions Object Security Scheme Object Scopes Object Security Requirement Object Η περιγραφή και το περιεχόμενο του κάθε Object καταγράφεται αναλυτικά στην ιστοσελίδα του OpenAPI Specification στο Github:. Πολλά Object σχετίζονται μεταξύ τους ιεραρχικά. Σε ένα OpenAPI Specification αρχείο συναντάμε την παρακάτω κλασσική, ιεραρχική δομή:

Κεφάλαιο 2. Υπόβαθρο 24 Όλες οι πληροφορίες του API που σχετίζονται με την υπηρεσία που το σχεδιάζει αλλά και το ίδιο το API, καταγράφονται στα Info, Contact και License Object στην αρχή του αρχείου. Στην συνέχεια καταγράφονται όλα τα paths του API, στο Paths Object. Κάθε path (Path Object) περιέχει τα operation που μπορούν να πραγματοποιηθούν (http verbs όπως GET, POST, PUT, DELETE). Κάθε operation (Operation Object) με την σειρά του περιέχει τις τεχνικές λεπτομέρειές του. Τέτοιες είναι το http αίτημα και τα τεχνικά του χαρακτηριστικά, η http απάντηση και τα τεχνικά της χαρακτηριστικά, τα τεχνικά χαρακτηριστικά ασφάλειας κ.α.. Σε κάθε http αίτημα και απάντηση, περιγράφονται οι παράμετροί τους. Δηλαδή περιγράφεται η τοποθεσία των παραμέτρων (π.χ. path, header, body), ο τύπος και η μορφή τους (string, number, integer, csv, file, xml) και πολλές άλλες τεχνικές λεπτομέρειες. Οι περισσότερες από αυτές τις λεπτομέρειες προέρχονται από το JSON Schema 9. Στο τέλος του αρχείου (ή σε άλλα αρχεία) οι διάφορες παράμετροι που εμφανίστηκαν στο Paths Object, οργανώνονται προαιρετικά στο Definitions Object. Μιλώντας με όρους προγραμματισμού, το Definitions Object συγκεντρώνει τις μεταβλητές του προγράμματος ή απλά τα μοντέλα. Η ύπαρξη των definitions αποσκοπεί στο να μην υπάρχουν επαναλήψεις ίδιων ορισμών, αλλά και στην γενικότερη οργανωμένη, ευανάγνωστη, δομή των αρχείων. Παραδείγματα αρχείου OpenAPI Specification φαίνονται στις εικόνες 2.15, 2.16 και 2.17 9

Κεφάλαιο 2. Υπόβαθρο 25 Εικόνα 2.15: OpenAPI Specification: Παράδειγμα Definitions Εικόνα 2.16: OpenAPI Specification: Παράδειγμα πληροφοριών του API

Κεφάλαιο 2. Υπόβαθρο 26 Εικόνα 2.17: OpenAPI Specification: Παράδειγμα Paths Object

Κεφάλαιο 2. Υπόβαθρο 27 2.2 Behavior-Driven Development 2.2.1 Σχεδιασμός και Ανάπτυξη Λογισμικού Στην υποενότητα 2.1.1, έγινε μία σύντομη ιστορική αναδρομή στην τεχνολογική εξέλιξη του Παγκόσμιου Ιστού. Μιλήσαμε για τα διάφορα στάδια της επιστήμης και καταλήξαμε στα RESTful APIs υπηρεσιών Παγκόσμιου Ιστού. Ένα στάδιο (επιστημονικά) πριν τα RESTful APIs, είναι τα προγράμματα των υπολογιστών. Πρόγραμμα ηλεκτρονικού υπολογιστή είναι μία ακολουθία εντολών. Οι εντολές αυτές έχουν σκοπό να προγραμματίσουν τον υπολογιστή, έτσι ώστε να εκτελέσει μία επιθυμητή ενέργεια. Σήμερα οι επιθυμητές ενέργειες είναι ολόκληρες επιχειρησιακές διαδικασίες. Η διαδικασία συγγραφής προγραμμάτων λοιπόν έχει και αυτή εξελιχθεί δραματικά όλα αυτά τα χρόνια. Πλέον τα προγράμματα ονομάζονται λογισμικό (software) ο χώρος ονομάζεται Σχεδιασμός και Ανάπτυξη Λογισμικού ή Τεχνολογία Λογισμικού (Software Engineering). Περιλαμβάνει δε πλήθος διαδικασιών και κανόνων, που προσδιορίζουν με την μεγαλύτερη δυνατή σαφήνεια, το πώς σχεδιάζεται και αναπτύσσεται ένα λογισμικό. Το σύνολο αυτών των διαδικασιών και κανόνων ονομάζεται Διαδικασία Ανάπτυξης Λογισμικού [25]. Η σημερινή Διαδικασία Ανάπτυξης Λογισμικού, μπορεί να γενικευθεί στις εξής 7 βασικές δραστηριότητες: Καταγραφή Απαιτήσεων Ενδιαφερόμενων Μερών, Λογισμικού και Συστήματος (Requirements) Οι μηχανικοί λογισμικού έρχονται σε επικοινωνία με τους πελάτες. Οι πελάτες μπορεί να είναι ιδιωτικές επιχειρήσεις και εταιρείες, δημόσιοι φορείς και πάσης φύσεως οργανισμοί. Τις ομάδες αυτές τις ονομάζουμε και stakeholders ή ενδιαφερόμενα μέρη. Έτσι τα ενδιαφερόμενα μέρη περιγράφουν στους μηχανικούς το λογισμικό. Η περιγραφή μπορεί να περιλαμβάνει λειτουργικότητα, επιχειρισιακές διαδικασίες, αλληλεπιδράσεις με εξωτερικά περιβάλλοντα (π.χ. άλλα λογισμικά ή εταιρείες), αισθητικές προδιαγραφές και ότι άλλο κρίνει ο πελάτης ότι θέλει να ξέρει ο μηχανικός. Οι προδιαγραφές αυτές με όρους Τεχνολογίας Λογισμικού ονομάζονται Requirements ή Απαιτήσεις. Επίσης κατά την δραστηριότητα αυτή καταγράφονται και οι τεχνικές απαιτήσεις του λογισμικού και του συστήματος γενικότερα. Η καταγραφή αυτή γίνεται κυρίως από τους μηχανικούς και προκύπτει από τις απαιτήσεις των ενδιαφερόμενων μερών. Στο τέλος της καταγραφής όλων των απαιτήσεων οι μηχανικοί έχουν στα χέρια τους 3 έγγραφα: Απαιτήσεις χρηστών (User Requirements) Απαιτήσεις Λογισμικού (Software Requirements) Απαιτήσεις Συστήματος (System Requiremenrs) Με όρους αγοράς, η δραστηριότητα αυτή είναι κατά μία έννοια η παραγγελία. Τυποποίηση Απαιτήσεων και Αφαιρετικός Σχεδιασμός Λογισμικού (Design) Οι μηχανικοί λογισμικού κωδικοποιούν τις απαιτήσεις σε διαγράμματα σχέσεων μεταξύ οντοτήτων και ροής εργασιών. Επίσης το στάδιο αυτό περιλαμβάνει συνολική σχεδίαση λογισμικού με την σύνδεση των τριών εγγράφων. Η δραστηριότητα αυτή αντιστοιχεί παραδείγματος χάρη στα σχέδια (blueprints) κατασκευής ενός αυτοκινήτου.

Κεφάλαιο 2. Υπόβαθρο 28 Υλοποίηση Λογισμικού (Construction) Ο σχεδιασμός υλοποιείται. Συγγράφεται κώδικας που πραγματοποιεί όλες τις απαιτήσεις. Στο στάδιο αυτό κυριαρχούν οι προγραμματιστές. Είναι ο πυρήνας της ανάπτυξης λογισμικού. Μέσω της υλοποίησης γίνεται η ιδέα πράξη. Στο στάδιο αυτό ενδέχεται να αξιοποιούνται προσωρινά περιβάλλοντα στα οποία θα εκτελείται το λογισμικό. Αυτό διότι δεν ενδιαφέρει ακόμα η πλήρης λειτουργία του συστήματος που σχεδιάζεται Συνολική Δοκιμή Λογισμικού (Testing) Ο κώδικας δοκιμάζεται. Εκτελούνται τεστ που προσομοιώνουν την λειτουργία του λογισμικού και ελέγχεται Αν προκύπτουν προβλήματα λογισμικού λόγω συντακτικών ή λογικών λαθών κατά την συγγραφή του κώδικα. Αν όλα εκτελούνται όπως έχουν συμφωνηθεί στις απαιτήσεις. Συνολική Αποσφαλμάτωση Λογισμικού (Debugging) Η εμπειρία δείχνει ότι πάντα προκύπτουν προβλήματα κατά την δραστηριότητα των δοκιμών. Έτσι αναγκαστικά υπάρχει και οι δραστηριότητα της αποσφαλμάτωσης. Κατά την αποσφαλμάτωση οι μηχανικού λογισμικού εντοπίζουν και διορθώνουν τα λάθη που προέκυψαν από τις δοκιμές. Ανάπτυξη Λογισμικού (Deployment) Αφού το λογισμικό έχει υλοποιηθεί και λειτουργεί σωστά και όπως συμφωνήθηκε, οι μηχανικοί αναλαμβάνουν να το εγκαταστήσουν. Έτσι αφαιρούνται τα προσωρινά συστήματα και αντικαθιστώνται από πραγματικά. Δηλαδή από εξυπηρετητές (servers), βάσεις δεδομένων (databases) και δικτυακές συνδέσεις (network connections). Η δραστηριότητα αυτή ταυτίζεται με την διάθεση του λογισμικού, στους πελάτες και τους χρήστες τους. Για παράδειγμα όλες οι ιστοσελίδες που βλέπουμε στο διαδίκτυο, όλα τα λειτουργικά συστήματα που χρησιμοποιούμε σε όλες τις συσκευές μας και όλα τα προγράμματα που εκτελούνται σε αυτά, είναι αποτέλεσμα του Deployment. Τέλος κατά το Deployment καταστρώνονται και τα σχέδια συντήρησης και ανάπτυξης του λογισμικού. Συντήρηση Λογισμικού (Maintenance) Το λογισμικό εξελίσσεται συνεχώς. Προκύπτουν νέες ανάγκες και άρα νέες απαιτήσεις. Τέτοιες μπορεί να είναι η συνεχώς αυξανόμενη χρήση του λογισμικού, οι νέες απαιτήσεις ασφάλειας, οι νέες τεχνολογίες, η επέκταση των εταιρειών και άλλα πολλά. Ταυτόχρονα και οι τρέχουσες λειτουργίες πρέπει να προσαρμόζονται και αυτές στις εξελίξεις. Συνεπώς το λογισμικό πρέπει να συντηρείται. Έτσι η συντήρηση του λογισμικού αφορά την ενημέρωσή του (update) με κώδικα, συστήματα και λειτουργίες που ανταποκρίνονται στις εξελίξεις. Η παραπάνω δραστηριότητες και η ακολουθία εκτέλεσής τους φαίνεται στην εικόνα 2.18. Πίσω από κάθε δραστηριότητα κρύβεται ένα σύνολο διαδικασιών οι οποίες οδηγούν στην πραγματοποίησή της και ακολουθούνται από ομάδες λογισμικού. Οι διαδικασίες εντός

Κεφάλαιο 2. Υπόβαθρο 29 Εικόνα 2.18: Οι βασικές δραστηριότητες ανάπτυξης λογισμικού της δραστηριότητας αλλά και η ακολουθία των ίδιων των δραστηριοτήτων ποικίλουν από λογισμικό σε λογισμικό. Έτσι σήμερα στην βιομηχανία εμφανίζονται διάφορα μοντέλα ανάπτυξης λογισμικού όπως τα Waterfall, Spiral, Prototyping (εικόνα 2.19), RUP, Agile και DevOps. Εσωτερικά των μοντέλων τώρα έχουν αναπτυχθεί μεθοδολογίες ανάπτυξης λογισμικού, οι οποίες αφορούν τις ενέργειες της κάθε δραστηριότητας. Τέτοιες μεθοδολογίες είναι η Ανάπτυξη Λογισμικού Οδηγούμενη από Δοκιμές (Test Driven Development) και η Ανάπτυξη Λογισμικού Οδηγούμενη από Συμπεριφορές (Behavior Driven Development). Οι μεθοδολογίες αυτές εντάσσονται, γενικώς, στο Agile μοντέλο ανάπτυξης λογισμικού. Κατά το Agile μοντέλο, η Διαδικασία Ανάπτυξης Λογισμικού είναι ευέλικτη. Οι βασικές αρχές του Agile μοντέλου είναι η συνεχής συνεργασία μεταξύ πελατώνμηχανικών, και η συνεχής διαμόρφωση των απαιτήσεων και του λογισμικού ως αποτέλεσμα αυτής της συνεργασίας. Έτσι κατά την διαδικασία Agile δεν ακολουθούμε πιστά και με την σειρά τις 7 προαναφερθέντες δραστηριότητες, αλλά προσαρμοζόμαστε στις συνθήκες. Όπως θα δούμε στην συνέχεια το BDD ταιριάζει περισσότερο από το TDD στο Agile μοντέλο. 2.2.1.1 Test Driven Development Η ιδέα των πρώιμων δοκιμών κατά την ανάπτυξη λογισμικού, εμφανίστηκε από τον Kent Beck στην μεθοδολογία του extreme Programming (XP) το 1999 [6] [5]. Ο ίδιος ο Kent Beck, στην συνέχεια, καθιέρωσε την μεθοδολογία ανάπτυξης λογισμικού οδηγούμενη από δοκιμές. Δηλαδή καθιέρωσε το επονομαζόμενο Test Driven Development ή απλά TDD [27]. Στο Test Driven Development το λογισμικό ξεκινάει από το τεστ. Δηλαδή από την 4 η δραστηριότητα της εικόνας 2.18. Το τεστ αυτό αναφέρεται και ως unit test. Διαφέρει όμως από το unit test που συγγράφεται αφού έχει υλοποιηθεί το λογισμικό. Κατά την μεθοδολογία TDD, ο Kent Beck περιγράφει την παρακάτω ακολουθία βημάτων ανάπτυξης λογισμικού [2]: 1. Δημιουργία ενός νέου τεστ T Κατά το στάδιο αυτό δημιουργείται ένα νέο τεστ. Το τεστ προκύπτει από τις

Κεφάλαιο 2. Υπόβαθρο 30 Εικόνα 2.19: Διαδεδομένα μοντέλα ανάπτυξης λογισμικού [25] απαιτήσεις και τις συνθήκες εξαιρέσεων του συστήματος. Αυτές με την σειρά τους προκύπτουν από τα σενάρια χρήσης του συστήματος. 2. Εκτέλεση όλων τεστ και διαπίστωση αν αποτυγχάνει το T Το στάδιο αυτό έχει σκοπό να επιβεβαιώσει την χρησιμότητα του T. Αν το T περνάει (pass), τότε δεν έχει χρησιμότητα. Έχει νόημα να πάμε στο επόμενο στάδιο, μόνο το T αποτυγχάνει (fail). 3. Συγγραφή του κώδικα Αφού διαπιστώσουμε ότι το T αποτυγχάνει, γράφουμε τον κώδικα που θα το κάνει να περάσει. Εδώ δεν μας ενδιαφέρει η γενικότερη ποιότητα του κώδικα. Ο μόνος στόχος είναι να περάσει το T. 4. Εκτέλεση των τεστ Τρέχουμε για άλλη μία φορά τα τεστ ώστε να δούμε αν το T περνάει. Επίσης,

Κεφάλαιο 2. Υπόβαθρο 31 σε αυτό το στάδιο εξετάζουμε αν η εισαγωγή του κώδικα δεν προκάλεσε προβλήματα σε άλλα τεστ και στην λειτουργικότητα του λογισμικού γενικότερα. Μέχρι το λογισμικό να είναι λειτουργικό επιστρέφουμε στο βήμα (3) και διορθώνουμε τον κώδικα. 5. Διόρθωση του συνολικού κώδικα Είπαμε στο βήμα (3) ότι δεν μας ενδιαφέρει η ποιότητα του κώδικα. Σε αυτό το στάδιο όλα τα τεστ (και το T ), έχουν περάσει. Πλέον μπορούμε να κάνουμε τις απαραίτητες αλλαγές, ώστε ο νέος κώδικας να ενσωματωθεί ποιοτικά στον υπάρχων συνολικό. 6. Επανάληψη διαδικασίας από την αρχή Η παραπάνω διαδικασία αναπαρίσταται σχηματικά στην εικόνα 2.20 Εικόνα 2.20: Διάγραμμα εξέλιξης διαδικασίας συγγραφής λογισμικού κατά TDD 2 2.2.1.2 Acceptance TDD και Behavior Driven Development Η διαδικασία που περιγράψαμε πιο πάνω, προϋποθέτει ότι ο μηχανικός λογισμικού γνωρίζει καλά τα σενάρια χρήσης του συστήματος. Έτσι επικεντρώνεται στο να δοκιμάζει πώς το εκάστοτε σενάριο θα ενταχθεί στο σύστημα. Μία άλλη προσέγγιση είναι το Acceptance TDD ή ATDD. Σήμερα η δημιουργία λογισμικού αφορά εταιρείες, οργανώσεις, δημόσιους φορείς. Αυτές τις ομάδες τις ονομάζουμε ενδιαφερόμενα μέρη (stakeholders). Επιπλέον η βιομηχανία λογισμικού έχει εξελιχθεί αρκετά, ώστε τα ενδιαφερόμενα μέρη 2

Κεφάλαιο 2. Υπόβαθρο 32 να διαθέτουν σχετικό τεχνικό προσωπικό. Το προσωπικό αυτό έχει την τεχνική κατάρτιση να εκπροσωπήσει την εταιρεία στην διαδικασία συγγραφής λογισμικού, και άρα και στην διαδικασία δοκιμών. Όταν στην διαδικασία δοκιμών συμμετέχουν έμμεσα ή άμεσα και εκπρόσωποι εταιρειών, τότε η διαδικασία ονομάζεται ATDD. Παραδείγματα acceptance test βλέπουμε στους πίνακες 2.2 και 2.3 [1]. Εικόνα 2.21: Ο κύκλος ζωής της μεθοδολογίας TDD 3 Εικόνα 2.22: Διαδικασία συγγραφής acceptance test Η εξέλιξη του ATDD είναι το Behavior Driven Development ή BDD. Το BDD ονομάστηκε έτσι από τον Dan North το 2003. Βασίζεται στην λογική του TDD με την διαφορά ότι τα τεστ κατά BDD ονομάζονται Ιστορίες Χρηστών ή User Stories. Δηλαδή περιγραφές ή σενάρια χρήσης του λογισμικού και του συστήματος γενικότερα. Οι περιγραφές 3

Κεφάλαιο 2. Υπόβαθρο 33 Description Setup Instructions Checking accounts have an overdraft limit of $500. As long as there are sufficient funds (e.g. -$500 or greater) within a checking account after a withdrawal has been made the withdrawal will be allowed. 1. Create account 12345 with an initial balance of $50 2. Create account 67890 with an initial balance of $0 1. Withdraw $200 from account #12345 2. Withdraw $350 from account #67890 3. Deposit $100 into account #12345 4. Withdraw $200 from account #67890 5. Withdraw $150 from account #67890 6. Withdraw $200 from account #12345 7. Deposit $50 into account #67890 8. Withdraw $100 from account #67890 Expected Results Account #12345: Ending balance = -$250 $200 Withdrawal transaction posted against it $100 Deposit transaction posted against it $200 Withdrawal transaction posted against it Account #67890: Ending balance = -$500 $350 Withdrawal transaction posted against it $150 Withdrawal transaction posted against it $50 Deposit transaction posted against it Errors logged: Insufficient funds in Account #67890 (balance -$350) for $200 Withdrawal Insufficient funds in Account #67890 (balance -$450) for $100 Withdrawal Πίνακας 2.2: Acceptance test με στόχο την επικύρωση ενός επιχειρησιακού κανόνα

Κεφάλαιο 2. Υπόβαθρο 34 Description Setup Instructions Expected Results The customer search screen allows user to perform standard wildcard searches on first and last name. 1. Remove all customer records from the database. 2. Add the following customers: John Smith James Doe Robin Saunders Jim Saunders Sally Smith Scott Davidson Beverley Williams Bob Roberts Rob Williams Robert Smithers Bobby Snookerby Sandy Davington Janice Sinters Display the Customer search screen. In the First Name entry field, enter In the Last Name entry field, enter S* Press the search button. The following names should be displayed in the search result box: Robin Saunders Robert Smithers Bobby Snookerby Πίνακας 2.3: Acceptance test με στόχο την επικύρωση μέρους διεπαφής χρήστη

Κεφάλαιο 2. Υπόβαθρο 35 αυτές προκύπτουν από την συνεννόηση μεταξύ των stakeholders και των μηχανικών λογισμικού. Χαρακτηριστικό στοιχείο των User Stories και του BDD γενικότερα είναι η απλή, αφηγηματική γλώσσα. Το Νοέμβριο του 2007 ο Dan North έδωσε σε παρουσίαση του τον εξής ορισμό για το BDD: BDD is a second-generation, outside in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agile methodology. It describes a cycle of interactions with well-defined outputs, resulting in the delivery of working, tested software that matters. [10] Από τον ορισμό αυτό παρατηρούμε μεταξύ άλλων ότι και το BDD ξεκινάει από το τεστ. Η μέθοδος αυτή ονομάζεται outside-in. Πολλές φορές στην βιβλιογραφία το BDD παρουσιάζεται ώς εναλλακτική ή ακόμα και ίδιο με το ATDD. Στην πραγματικότητα το BDD διαφοροποιείται και από το ATDD (πέραν του TDD) έως ένα βαθμό. Είπαμε ότι κατά BDD τα τεστ ονομάζονται ιστορίες χρηστών και περιγράφονται σε απλή, αφηγηματική γλώσσα. Ας συγκρίνουμε τα παρακάτω παραδείγματα: Παράδειγμα 2.6: BDD User Story As a customer I want to withdraw cash from an ATM, so that I dont have to wait in line at the bank Παράδειγμα 2.7: ATDD Acceptance Test Verify that customer authentication works Verify that the customer is limited to 3 transactions an ATM session Verify that sufficient balance is in place to support the transaction Verify that the overall transaction workflow takes no longer than 5 minutes Verify that the transaction is immediately viewable in the customers online access Το παράδειγμα 2.6, είναι ένα σενάριο χρήσης κατά BDD, το οποίο περιγράφει μία επιχειρησιακή διαδικασία. Η διαδικασία αυτή δεν είναι άλλη από την ανάληψη χρημάτων από ένα ATM μιας τράπεζας. Στο παράδειγμα 2.7 βλέπουμε ακριβώς την ίδια επιχειρησιακή διαδικασία διατυπωμένη από την οπτική γωνία του ATDD. Παρατηρούμε ότι και τα δύο κείμενα είναι κατανοητά. Αυτό συμβαίνει διότι είναι αποτέλεσμα συννενόησης των εκπροσώπων με τους μηχανικούς λογισμικού. Η διαφορά τους όμως είναι εμφανής. Το acceptance Test περιέχει τεχνικές λεπτομέρεις που αφορούν την διαδικασία ανάληψης (όπως τα όρια στο πλήθος και στο χρόνο των συναλλαγών). Το BDD User Story δεν επικεντρώνεται σε τέτοιες τεχνικές λεπτομέρεις, αλλά στην ιστορία αυτή καθαυτή. Βασικό του χαρακτηριστικό είναι ότι απαντάει στο γιατί να υπάρχει η επιχειρησιακή διαδικασία ανάληψη από ATM και όχι στο πώς αυτή υλοποιείται. Αυτό όμως δεν σημαίνει ότι αυτές οι τεχνικές λεπτομέρειες δεν μας ενδιαφέρουν. Το λογισμικό κάποια στιγμή θα υλοποιηθεί (ας θυμηθούμε την εικόνα 2.18). Οι τεχνικές λεπτομέρειες θα εμφανιστούν σε μετέπειτα στάδιο της ανάπτυξης του λογισμικού και αφορούν περισσότερο τους testers και τους προγραμματιστές. Στην πραγματικότητα τα σημερινά User Stories περιγράφουν πλήρως και το επιχειρησιακό domain του πελάτη. Επιλέχθηκε όμως να γίνει η παραπάνω παρουσίαση ώστε να φανεί καθαρά η διαφορά μεταξύ αφήγησης και απλής παράθεσης τεχνικών πληροφοριών. Έτσι κατά BDD διακρίνουμε τα εξής βήματα ανάπτυξης λογισμικού:

Κεφάλαιο 2. Υπόβαθρο 36 1. Συγγραφή του User Story Οι πελάτες, οι testers και οι προγραμματιστές συμφωνούν στο τι θα κάνει το λογισμικό και γιατί. Αποτέλεσμα αυτής της διαδικασίας είναι το User Story. Το User Story περιγράφει ένα νέο χαρακτηριστικό του λογισμικού. 2. Δοκιμή του User Story από τους testers Η δοκιμή ακολουθεί πιστά το πρότυπο TDD του Kent Beck, το οποίο περιγράψαμε πιο πάνω. Κατά την δοκιμή ενδεχομένως συνεννοούνται με τους προγραμματιστές για τις διάφορες τεχνικές λεπτομέρειες. Σε αυτό το στάδιο ενδεχομένως ακολουθούν μεταξύ τους μία σύντομη διαδικασία συγγραφής Acceptance Test, το οποίο ουσιαστικά θα είναι η αποκωδικοποίηση των τεχνικών λεπτομερειών του User Story. 3. Επικοινωνία με τους πελάτες για την εξέλιξη της διαδικασίας Αν κατά το βήμα τρία προκύψουν επιπλοκές με τα άλλα υπάρχοντα User Stories, τότε πρέπει να γίνει ξανά συζήτηση με τους πελάτες. Στο σημείο αυτό οι μηχανικοί εξηγούν στους πελάτες τα διάφορα προβλήματα που προέκυψαν με τα υπόλοιπα User Stories. Να επισημάνουμε εδώ ότι δεν τους μεταφέρουν τα τεχνικά προβλήματα που προέκυψαν. Αυτά αφορούν τους μηχανικούς λογισμικού. Τα μόνα προβλήματα τα οποία είναι σχετικά με αυτή την συζήτηση είναι αυτά που αφορούν την λειτουργία του λογισμικού όπως αυτή περιγράφηκε στο βήμα (1). Η συζήτηση αυτή δεν βοηθάει μόνο τους πελάτες αλλά και τους μηχανικούς λογισμικού. 4. Επανάληψη από το βήμα (1) Το βήμα (1) ξεκινάει με την διόρθωση του User Story Αποτέλεσμα της διαδικασίας BDD είναι να έχουμε μία συνεχόμενη συμμετοχή όλων των πλευρών στην συγγραφή του λογισμικού. Μάλιστα λόγω των User Stories η συμμετοχή των εκπροσώπων του εκάστοτε πελάτη διευρύνεται. Πλέον στην συζήτηση μπορούν να συμμετάσχουν όλων των ειδών οι εκπρόσωποι της εταιρείας, του φορέα ή του οργανισμού. Αυτό γιατί το User Story είναι κάτι που όχι μόνο καταλαβαίνουν όλοι, αλλά μπορούν και να βοηθούν στην συγγραφή του. Το User Story μπορεί να περιέχει και τεχνικά χαρακτηριστικά που αφορούν τον χώρο της εταιρείας. Στην βιβλιογραφία η μέθοδος αυτή αναφέρεται και ως Domain Driven Design 4. Δηλαδή σχεδιασμός με βάση τα τεχνικά χαρακτηριστικά του χώρου, γύρω από τον οποίο αναπτύσσεται το λογισμικό. Τώρα όσο αφορά τις διαφορές των 3 μεθόδων, στην εικόνα 2.23 μπορούμε να δούμε την συνεισφορά των διαφόρων ομάδων κατά BDD, ATDD και TDD. Η συνεισφορά αφορά την συγγραφή του τεστ. Δηλαδή του απλού τεστ κατά TDD, του Acceptance Test κατά ATDD και του User Story κατά BDD. Βλέπουμε λοιπόν ότι στην δημιουργία του User Story, η εμπλοκή των ενδιαφερόμενων μερών είναι πολύ μεγαλύτερη από τις άλλες δύο περιπτώσεις. Έτσι αιτιολογείται ο τίτλος Behavior Driven Development. Δηλαδή η ανάπτυξη του λογισμικού, οδηγείται (driven) από το User Story. Άρα από την καθοριστική συνεισφορά των ενδιαφερόμενων μερών. Στο ATDD οι συνεισφορά είναι πιο ισορροπημένη. Οι εκπρόσωποι των πελατών είναι κυρίως τεχνικά στελέχη και άρα εκπροσωπούν έως ένα βαθμό τους πρώτους. Τέλος στο TDD η μόνη συνεισφορά του πελάτη είναι μία αρχική συζήτηση, στην οποία περιγράφει προφορικά τις απαιτήσεις λογισμικού. Ως τελικό σχόλιο αναφέρουμε ότι το BDD δεν εμφανίστηκε λόγω κάποιας επιστημονικής προσεγγίσεως που αναιρεί το ATDD. Περαιτέρω τόσο το TDD όσο και το ATDD συνεχίζουν να χρησιμοποιούνται από ομάδες λογισμικού. Το ATDD αποτελεί την γέφυρα ανάμεσα στις μεθοδολογίες BDD και TDD. Αυτό μπορούμε να το καταλάβουμε αν εξετάσουμε πάλι την εικόνα 2.23. Αν στο ATDD Test Discussion μετακινήσουμε το όριο μεταξύ 4

Κεφάλαιο 2. Υπόβαθρο 37 Εικόνα 2.23: Συμμετοχή διαφόρων ομάδων στην συγγραφή δοκιμών κατά BDD, ATDD, TDD Business Stakeholders και Testers προς τα αριστερά, τότε έχουμε το BDD. Αντίθετα αν το μετακινήσουμε προς τα δεξία τότε έχουμε το TDD. Έτσι οι διαφορές των τριών μεθοδολογιών είναι διακριτές, αλλά όχι σταθερές. Επισημαίνουμε έτσι ότι δεν υπάρχει σωστή μέθοδος, αλλά υπάρχουν ανάγκες τις αγοράς και τεχνολογικές εξελίξεις. 2.2.2 Gherkin Η γλώσσα Gherkin[8] είναι μία γλώσσα συγγραφής User Stories. Η Gherkin αποτελεί μέρος του BDD εργαλείου Cucumber, το οποίο σύντομα εξηγείται στο παράρτημα A. Η Gherkin ορίζει την οργάνωση των User Stories σε feature files ή aρχεία xαρακτηριστικών. Επίσης ορίζει ένα συντακτικό συγγραφής feature files. Το συντακτικό των feature files αποτελείται από τα εξής 3 δομικά στοιχεία: Τα χαρακτηριστικά (features) Τα σενάρια (scenarios) Τα βήματα (steps) Κάθε χαρακτηριστικό αποτελείται από ένα ή περισσότερα σενάρια. Επιπλέον κάθε σενάριο αποτελείται από μία σειρά βημάτων. Η κλασσική δομή ενός αρχείου χαρακτηριστικών φαίνεται στην εικόνα 2.24. Βλέπουμε ότι οι λέξεις κλειδιά (keywords) βρίσκονται στην αρχή των προτάσεων. Κάτω από τις λέξεις κλειδιά feature: και scenario: υπάρχουν οι περιγραφές τους. Αυτές είναι προαιρετικές και υπάρχουν μόνο για να βοηθούν την ομάδα ανάπτυξης λογισμικού στην κατανόηση, την συγγραφή και την οργάνωση των feature files. Η δομή του feature file είναι τέτοια ώστε να συμβάλλει στην συγγραφή του User Story. Τα features αντιστοιχούν στα χαρακτηριστικά του λογισμικού ή συστήματος το οποίο σχεδιάζουμε. Τα scenarios αφορούν τα διάφορα σενάρια χρήσης του λογισμικού. Τα

Κεφάλαιο 2. Υπόβαθρο 38 Εικόνα 2.24: Ένα Cucumber feature file steps είναι μια ακολουθία ενεργειών που περιγράφουν το εκάστοτε σενάριο χρήσης. Το ισχυρό χαρακτηριστικό της γλώσσας Gherkin και του Cucumber γενικότερα είναι ο τρόπος περιγραφής των βημάτων των σεναρίων. Συγκεκριμένα, το ισχυρο χαρακτηριστικό είναι η προδιαγραφή να περιγράφονται τα steps με την λογική Given - When - Then και την ενδεχόμενη προσθήκη των But και And. Η λογική αυτή μοιάζει με το if - and - then του προγραμματισμού. Δηλαδή το μοντέλο αιτία-αποτέλεσμα [29]. Στο σημείο αυτό πρέπει να σταθούμε. Το if - and - then αποτελεί βασικό δομικό στοιχείο του προγραμματισμού ως φιλοσοφία. Η ίδια η σχεδίαση των λογικών κυκλωμάτων βασίζεται στην λογική αν-τότε. Έτσι παραδείγματος χάρη μπορούμε πολύ εύκολα να περιγράψουμε με ένα feature file την λογική πύλη AND (εικόνα 2.25). Η λογική αν-τότε διέπει συνολικά την Επιστήμη των Υπολογιστών. Στην θεωρία των υπολογισμών π.χ., η λογική αυτή περιγράφεται από τις μηχανές καταστάσεων. Έτσι το Given - When - Then αντιστοιχεί και στην λογική: Δεδομένου (Given) ότι είμαι στην κατάσταση Α, Όταν/Και (When/And) ισχύουν κάποιες συνθήκες Χ, Τότε (Then) μεταβαίνω στην κατάσταση Β. Με βάση αυτή την διαπίστωση, η λογική Given - When - Then ενισχύει την επικοινωνία μεταξύ μηχανικών λογισμικού και ενδιαφερόμενων μερών. Αν και αυτές οι δύο ομάδες έχουν διαφορετικές οπτικές γωνείες, η Gherkin καθοδηγεί τον τρόπο σκέψης τους. Αυτή η ιδιότητα είναι δομικής σημασίας για την γεφύρωση του χάσματος. Όχι απλώς τα User Stories είναι απλά και κατανοητά, αλλά ακολουθούν ταυτόχρονα την λογική ενός αλγόριθμου. Επιπρόσθετα χάρη στα feature files και την δομή τους, τα User Stories μπορούν πολύ εύκολα να γραφτούν γύρω από ένα ubiquitous language. Δηλαδή γλώσσα σχετική με την δραστηριότητα του φορέα, της εταιρείας ή του οργανισμού (domain driven design). Εφόσον οι περιορισμοί των feature files είναι μόνο η απλή δομή και το λογικό συντακτικό των steps, υπάρχει μεγάλο περιθώριο ελευθερίας για την περιγραφή του User Story.

Κεφάλαιο 2. Υπόβαθρο 39 Εικόνα 2.25: Η λογική πύλη AND κατά Cucumber. Σημειώνεται ότι το And μπορεί κάλλιστα να αντικατασταθεί από το When Το περιθώριο αυτό διευρύνεται και από την δυνατότητα πρόσθεσης περιγραφής (description) στο εκάστοτε feature και scenario. Έτσι ο πελάτης μπορεί να δώσει στοχευμένα και συγκεκριμένα παραδείγματα των επιχειρησιακών διαδικασιών του χώρου του. Ταυτόχρονα τα feature files αποτελούν ένα κοινό σημείο αναφοράς για την ομάδα ανάπτυξης λογισμικού. Όλες οι απαιτήσεις είναι καταγεγραμμένες και ξεκάθαρες. Επιπρόσθετα τα feature files παρακολουθούν τις εξελίξης του λογισμικού και άρα ενημερώνονται συνεχώς. Έτσι οι απαιτήσεις του συστήματος παραμένουν επίκαιρες. Δηλαδή τα feature files μπορούν να παίξουν και τον ρόλο του documentation του συστήματος. Documentation μάλιστα που μπορούν να διαβάσουν όλοι οι συμμετέχοντες στην διαδικασία και που συνεχώς ενημερώνεται (living documentation). Στο βιβλίο The Cucumber Book [32] το κοινό αυτό σημείο συνάντησης αναφέρεται ως source of truth. Επισημαίνεται τέλος ότι στην σουίτα εργαλείων που παρέχει το Cucumber, συμπεριλαμβάνεται και ο Gherkin Parser 5. Ο Gherkin Parser δέχεται ως είσοδο 5

Κεφάλαιο 2. Υπόβαθρο 40 feature files και δίνει ως έξοδο ένα μοντέλο χαρακτηριστικών που αποκαλείται Abstract Syntax Tree (AST). Η δομή του AST φαίνεται στην εικόνα 2.26. Την λειτουργία αυτή του Gherkin Parser θα την αξιοποιήσουμε στο σύστημά μας. Εικόνα 2.26: Το Abstract Syntax Tree του Gherkin Parser

Κεφάλαιο 2. Υπόβαθρο 41 2.3 Natural Language Processing Το Natural Language Processing ή απλά NLP, είναι η επιστήμη που ασχολείται με τις αλληλεπιδράσεις μεταξύ των υπολογιστών και των φυσικών γλωσσών των ανθρώπων [16]. Το NLP έγινε γνωστό με το Turing Test 6 του Alan Turing. Κατά το Turing Test ένας άνθρωπος, ο δοκιμαστής, προσπαθεί να διακρίνει μία μηχανή από έναν άλλον άνθρωπο. Για να το πετύχει αυτό, του δίνεται η δυνατότητα να θέτει γραπτά ερωτήματα και στους δυο (και μόνο). Ο άνθρωπος και η μηχανή απαντάνε και ο δοκιμαστής, ανάλογα με τις απαντήσεις, αποφασίζει ποιος από τους δύο έδωσε ποια απάντηση. Στόχος του τεστ είναι προφανώς να πείσει η μηχανή τον δοκιμαστή ότι είναι άνθρωπος. Για να τον πείσει, καταστρατηγεί μεθόδους NLP τόσο κατά την ανάγνωση των ερωτημάτων όσο και κατά την διαμόρφωση των απαντήσεων. Η εξέλιξη του NLP στη δεκαετία του 80 ήταν ραγδαία για τρείς λόγους. Ο πρώτος είναι η συνεχόμενη αύξηση της υπολογιστικής ισχύος, ο δεύτερος οι συνεχώς βελτιωμένοι αλγόριθμοι υπολογισμών και ο τρίτος η εισαγωγή και η εξέλιξη της μηχανικής μάθησης. Ταυτόχρονα το μικρό κόστος διαχείρισης ψηφιακού κειμένου, σε αντίθεση με το χειρόγραφο, οδήγησε στο φαινόμενο της λεγόμενης μηχανογράφησης. Έτσι επιχειρήσεις, οργανισμοί και κράτη συνολικά, ανέλαβαν την ψηφιοποίηση πάσης φύσεως εγγράφων σχετικών με την λειτουργία τους. Φυσικά στην εξέλιξη του NLP συνέβαλε και η ραγδαία εξέλιξη του Παγκόσμιου Ιστού. Χαρακτηριστικό παράδειγμα είναι οι μηχανές αναζήτησης. Οι τελευταίες αξιοποιούν κατά το δυνατόν καλύτερα την επεξεργασία φυσικής γλώσσας για την στοχευμένη εύρεση πληροφορίας. Συμπερασματικά η γενικότερη τεχνολογική έκρηξη του 20ου αιώνα είναι άμεσα συνδεδεμένη με την εξέλιξη του NLP. Παρά τους πολλούς κλάδους του NLP, το πεδίο εφαρμογής της διπλωματικής είναι συγκεκριμένο. Την περίπτωσή μας αφορά η εξαγωγή τεχνικής πληροφορίας από κείμενο γραμμένο σε γλώσσα Gherkin. Μάλιστα το περιεχόμενο του κειμένου αφορά την περιγραφή ενός Web API. Έτσι αυτά που αναμένονται να εμφανιστούν εντός του κειμένου, οριοθετούνται από το συντακτικό της Gherkin και τα τεχνικά χαρακτηριστικά των Web APIs. Πρέπει να αναφέρουμε ακόμη ότι πρώτος στόχος της διπλωματικής είναι η απεικόνιση απαιτήσεων RESTful Web APIs σε Gherkin. Άρα, και σχεδιαστικά, μπορούμε να προβλέψουμε το πώς ο μηχανικός θα συντάσσει τις απαιτήσεις σε Gherkin. Με βάση αυτή την οριοθέτηση, τα εργαλεία που θα δανειστούμε από το NLP είναι το Tokenization, το POS Tagging, το Text chunking και το Relation Extraction. Επίσης αξιοποιούμε τα Regular Expressions αλλά και λίστες λέξεων ή φράσεων. Τα εργαλεία αυτά επεξηγούμε σύντομα παρακάτω. Θα πρέπει εδώ να επισημάνουμε ότι οι απαιτήσεις των Web APIs σε Gherkin θα γράφονται στην αγγλική γλώσσα. 2.3.1 Information Extraction Τα πρώτα τέσσερα εργαλεία, δηλαδή τα Tokenization, POS Tagging, Text chunking, Relation Extraction, συνθέτουν την διαδικασία Information Extraction (ΙΕ). Κατά την διαδικασία αυτή το κείμενο περνάει από διάφορα στάδια επεξεργασίας. Κάθε στάδιο εμπλουτίζει περισσότερο το σύνολο των πληροφοριών που σχετίζονται με το περιεχόμενό του. Το κάθε στάδιο αναλύεται παρακάτω. 6

Κεφάλαιο 2. Υπόβαθρο 42 2.3.1.1 Tokenization Κατά το Tokenization, οι προτάσεις του κειμένου διαχωρίζονται σε tokens. Δηλαδή στις μικρότερες δυνατές εννοιολογικές μονάδες. Έτσι για παράδειγμα στην πρόταση I ate breakfast τα tokens είναι τα I, ate και breakfast. Αντίστοιχα στην πρόταση When I request an order by it's id τα tags είναι τα When, I, request, an, order, by, it, s, id. 2.3.1.2 POS Tagging Το Part of Speech Tagging ή απλά POS Tagging είναι μία μεθοδολογία ετικετοποίησης λέξεων με βάση τα συντακτικά και γραμματικά τους χαρακτηριστικά. Δεδομένου ότι η γλώσσα που μας αφορά είναι η αγγλική, αναφερόμαστε πάντα στο συντακτικό και την γραμματική της αγγλικής γλώσσας. Γνωστά μέρη του λόγου της αγγλικής γλώσσας είναι τα noun, verb, adjective, adverb, pronoun, preposition, conjunction, interjection, numeral, article/determiner. Από αυτά τα μέρη του λόγου προκύπτουν οι λεγόμενες ετικέτες (tags). Επειδή μερικές λέξεις δεν έχουν ξεκάθαρη ετικετοποίηση, προκύπτουν διαφορετικά σετ ετικετών. Ενδεικτικά παραθέτουμε το γνωστό Penn Treebank στην εικόνα 2.30. Είσοδος του POS Tagging είναι ένα tokenized κείμενο. Αποτέλεσμα εφαρμογής του POS Tagging σε μία πρόταση είναι ένας πίνακας, ο οποίος στην μία του στήλη περιέχει τις λέξεις της πρότασης και στην άλλη τα αντίστοιχα tag τους. 2.3.1.3 Text Chunking Το POS Tagging βρίσκει τα μέρη του λόγου σε μία πρόταση. Μία άλλη ενδιαφέρουσα πληροφορία είναι οι ονοματικές προτάσεις (κύριες και δευτερεύουσες). Ο εντοπισμός αυτών μπορεί να γίνει με την μεθοδολογία Text Chunking. Το text chunking λαμβάνει ως είσοδο ετικετοποιημένο κείμενο κατά POS Tagging και έχει ως έξοδο ομάδες φράσεων. Οι φράσεις σηματοδοτούνται με την ακολουθία χαρακτήρων NP (Noun Phrase). Στην εικόνα 2.27 φαίνεται το αποτέλεσμα εφαρμογής POS Tagging και Chunking σε μία πρόταση. Εικόνα 2.27: Αποτέλεσμα εφαρμογής POS Tagging και Text Chunking σε μία πρόταση

Κεφάλαιο 2. Υπόβαθρο 43 2.3.1.4 Named Entity Recognition Tο Named Entity Recognition αφορά τον εντοπισμό ονοματικών φράσεων και ουσιαστικών και την ταξινόμησή τους σε κατηγορίες. Τέτοιες κατηγορίες μπορεί να είναι οργανισμοί, περιοχές, πρόσωπα, μονάδες μέτρησης, νομισματικές μονάδες κ.λ.π.. Ο εντοπισμός και η ταξινόμηση των entities μπορεί να γίνεται με βάση κάποιες λίστες εκφράσεων ή λέξεων. Παράδειγμα εφαρμογής του NER φαίνεται στην εικόνα 2.28 Εικόνα 2.28: Παράδειγμα εφαρμογής Named Entity Recognition 2.3.1.5 Relation Extraction Αφού εντοπισθούν τα Named Entities τότε πιθανώς να ενδιαφέρει και ο εντοπισμός των σχέσεων αυτών. Το πρόβλημα αυτό φιλοδοξεί να λύσει το Relation Extraction. Το Relation Extraction δέχεται ως είσοδο την έξοδο του NER. Κατά το Relation Extraction, ελέγχονται πλειάδες (Χ,α,Y), όπου Χ,Y named entities και α το κείμενο μεταξύ τους ή γύρω τους. Συγκεκριμένα ελέγχεται αν το α αποτελεί ή περιέχει σχέση μεταξύ των X,Y. Αποτέλεσμα εφαρμογής του Relation Extraction είναι οι εντοπισμένες σχέσεις μεταξύ των named entities όπως φαίνεται παρακάτω [ORG: 'DDB Needham'] 'in' [LOC: 'New York'] Η συνολική διαδικασία του IE συνοψίζεται στην εικόνα 2.29. Εικόνα 2.29: Η διαδικασία του Information Extraction

Κεφάλαιο 2. Υπόβαθρο 44 2.3.2 Άλλα εργαλεία NLP Πέρα από την διαδικασία του Information Extraction, υπάρχουν και άλλα εργαλεία που χρησιμοποιούμε στην διπλωματική και εξηγούμε σύντομα παρακάτω. 2.3.2.1 Κανονικές εκφράσεις (Regular Expressions) Οι κανονικές εκφράσεις είναι συμβολοσειρές που περιγράφουν μία γλώσσα. Προέρχονται από την επιστήμη της Θεωρίας των Υπολογισμών. Στις γλώσσες προγραμματισμού οι συμβολοσειρές οριοθετούνται από δύο πλάγιες καθέτους, /. Τα σύμβολά τους είναι χαρακτήρες. Οι δυνατοί χαρακτήρες ορίζονται από τυποποιήσεις όπως ASCII και Unicode. Κάποιοι χαρακτήρες έχουν συντακτικό ρόλο στην κανονική έκφραση. Παραδείγματος χάρη η πλάγια κάθετος οριοθετεί την έκφραση, ενώ ο χαρακτήρας * σημαίνει από 0 έως άπειροι χαρακτήρες. Παρακάτω παραθέτουμε μερικά ενδεικτικά παραδείγματα κανονικών εκφράσεων ( ε είναι το σύμβολο του κενού)[18]: /a b*/ το οποίο σημαίνει a ή από 0 έως άπειρες φορές το b και παράγει το σύνολο ε, a, b, bb, bbb, /(a b)*/ το οποίο σημαίνει συμβολοσειρές μόνο με a ή b, από 0 έως άπειρες φορές το καθένα και παράγει το σύνολο ε, a, b, aa, ab, ba, bb, aaa, /dog/ το οποίο σημαίνει απλά η συμβολοσειρά dog /Hello$/ το οποίο σημαίνει η πρόταση πρέπει να τελειώνει με την λέξη Hello Οι κανονικές εκφράσεις μας επιτρέπουν να ελέγξουμε, αν ένα σύνολο χαρακτήρων που περιγράφει η κανονική έκφραση, εμφανίζεται σε ένα κείμενο. 2.3.2.2 Λίστες λέξεων ή φράσεων Οι λίστες λέξεων ή φράσεων είναι απλές λίστες λέξεων ή φράσεων. Με τις λίστες λέξεων ή φράσεων μπορούμε να ελέγξουμε, αν μία λέξη ή μία φράση της λίστας εμφανίζεται σε ένα προς εξέταση κείμενο. Για απλές λίστες, η συγγραφή τους γίνεται από τον άνθρωπο με βάση την εμπειρία και τους στόχους του. Πιο πολύπλοκες λίστες μπορούν να δημιουργηθούν με την βοήθεια της μηχανικής μάθησης. 2.3.2.3 nltk Το λογισμικό της διπλωματικής είναι γραμμένο σε python version 3.5. Στην python η de facto βιβλιοθήκη για NLP είναι το nltk 7. Το nltk συγκεντρώνει πλήθος εργαλείων NLP, όπως για παράδειγμα όλη την διαδικασία του Information Extraction που αναλύθηκε στην ενότητα 4.1. Μεταξύ άλλων αξιοποιεί το έργο γνωστών ερευνητικών ομάδων και οργανισμών όπως το Stanford Language Processing Group 8 και το Wordnet 9. 7 8 9 10

Κεφάλαιο 2. Υπόβαθρο 45 Εικόνα 2.30: Αλφαβητική λίστα POS Tags του Penn Treebarnk project 10

46 Κεφάλαιο 3 Σχετική Βιβλιογραφία & Εξειδίκευση του προβλήματος 3.1 Σχετική βιβλιογραφία Όπως έχουμε πει, ο στόχος της διπλωματικής είναι να μετατρέψουμε απαιτήσεις για RESTful APIs σε OpenAPI Specification. Οι απαιτήσεις είναι γραμμένες σε Gherkin γλώσσα. Επειδή το τελικό προϊόν είναι το OpenAPI Specification (ειδικό), αναμενόμενο ήταν να μην υπάρχει άμεσα σχετική βιβλιογραφία. Μάλιστα το γεγονός αυτό εκτιμήθηκε ότι προσδίδει σχεδιαστικές ελευθερίες στην υλοποίηση. Σε κάθε περίπτωση διακρίνονται τα εξής βιβλιογραφικά αντικείμενα: 1. Εφαρμογή μηχανισμών NLP σε κείμενο λειτουργικών απαιτήσεων για εξαγωγή τεχνικών χαρακτηριστικών 2. Ανάπτυξη Web RESTful APIs με Gherkin 3.1.1 Εφαρμογή μηχανισμών NLP σε κείμενο λειτουργικών απαιτήσεων για εξαγωγή τεχνικών χαρακτηριστικών Όλα τα σχετικά κείμενα πάνω στο θέμα έχουν ένα κοινό χαρακτηριστικό: Τον διαχωρισμό των λέξεων και των φράσεων μιας πρότασης σε εννοιολογικές ομάδες. Οι εννοιολογικές ομάδες αποφασίζονται από τον σχεδιαστή. Η επιλογή τους εξαρτάται από τις εκάστοτε ανάγκες. S-CASE Το S-CASE[22] είναι ένα ευρωπαϊκό έργο στο οποίο συμμετέχει το ISSEL Lab Group (στο οποίο εκπονήθηκε η παρούσα διπλωματική εργασία). Αντικείμενο του έργου είναι η ανάπτυξη εργαλείων, τα οποία έχουν στόχο την μείωση του κόστους και του χρόνου υλοποίησης λογισμικού. Στο πλαίσιο του προγράμματος αναπτύχθηκαν μεθοδολογίες αξιοποίησης NLP μηχανισμών σε κείμενα απαιτήσεων. Η απαιτήσεις δεν είναι γραμμένες σε γλώσσα Gherkin αλλά έχουν την παρακάτω μορφή The operator must be able to print the invoice. Το κείμενο σηματοδοτείται χειροκίνητα από τον άνθρωπο, όπως φαίνεται στην Eικόνα 3.1. Η επισήμανση των απαιτήσεων βασίζεται σε εννοιολογικές ομάδες οι οποίες έχουν προαποφασιστεί. Οι ομάδες αυτές συνθέτουν ένα οντολογικό δέντρο όπως φαίνεται στην Eικόνα 3.2

Κεφάλαιο 3. Σχετική Βιβλιογραφία & Εξειδίκευση του προβλήματος 47 Το λογισμικό λαμβάνει ως είσοδο το σηματοδοτημένο κείμενο και με βάση την σηματοδότηση, εξάγει άμεσα ένα τεχνικό μοντέλο λογισμικού. NLP σε Gherkin Σχετικά με την εφαρμογή μηχανισμών NLP σε Gherkin κείμενο ενδεικτικά είναι τα [24] και [14]. Στις εργασίες αυτές αξιοποιούνται έτοιμα εργαλεία NLP όπως το Wordnet και ο Stanford Parser. Το κείμενο των λειτουργικών απαιτήσεων σηματοδοτείται με την τεχνική POS tagging. Σε πιο πολύπλοκο κείμενο εφαρμόζεται sentence chunking (εικόνα 3.3) ή/και εντοπίζονται τα dependencies (εικόνα 3.4) των λέξεων και φράσεων μεταξύ τους. Η έξοδος του NLP είναι τα pos tags,chunks και dependencies. Αυτά μαζί με το κείμενο αποτελούν το αρχικό μοντέλο, το οποίο δέχεται ως είσοδο ένα επόμενο λογισμικό. Το επόμενο λογισμικό αξιοποιεί τις πληροφορίες του NLP, προκειμένου να αποφασίσει την τεχνική φύση των λέξεων και των φράσεων. 3.1.2 Web API Development με Gherkin Στην Ενότητα 2.2 αναλύθηκε μεταξύ άλλων και η μεθοδολογία BDD. Είδαμε δηλαδή πώς καταγράφονται απαιτήσεις λογισμικού σε γλώσσα Gherkin και πώς στην συνέχεια μετατρέπονται οι απαιτήσεις σε λογισμικό. Η μετατροπή μπορεί να γίνει με το χέρι ή με την βοήθεια ενός εργαλείου, όπως το Cucumber. Στην δική μας περίπτωση δεν μας ενδιαφέρει η μετατροπή από απαιτήσεις σε λογισμικό άμεσα, αλλά η μετατροπή από απαιτήσεις σε τυποποίηση. Παρά την διαφορετική αυτή προσέγγιση όμως, μας ενδιαφέρει πως οι μηχανικοί αξιοποιούν τα εργαλεία αυτά για να αναπτύσσουν APIs. Δηλαδή η καθημερινότητα ενός Agile/BDD software engineer που χρησιμοποιεί Gherkin. Προκειμένου να αποκτηθεί μία γενική εικόνα για το θέμα, πραγματοποιήθηκαν διαδικτυακές επικοινωνίες με τον Co Owner της Cucumber, Seb Rose και τον agile team mentor J.B. Rainsberger. Το θέμα της συζήτησης ήταν Πώς ένας μηχανικός λογισμικού χρησιμοποιεί σήμερα το BDD, το Cucumber και την Gherkin για να αναπτύξει APIs και λογισμικό γενικότερα. Παρακάτω επισημαίνουμε τα βασικά συμπεράσματα που εξήχθησαν από τις συζητήσεις: Οι απαιτήσεις του πελάτη για το λογισμικό μπορεί να προκύψουν από συζήτηση με τον ίδιο ή τεχνικούς εκπρόσωπούς του. Κατά την συζήτηση δεν γίνεται τεχνική καταγραφή των απαιτήσεων. Δηλαδή δεν συντάσσεται κείμενο Gherkin μαζί με τον πελάτη. Το γεγονός όμως ότι θα γραφεί κείμενο Gherkin βοηθάει τον μηχανικό να προάγει έναν τρόπο σκέψης στην συζήτηση με τον πελάτη. Το Gherkin κείμενο δεν είναι τελικό. Υπάρχει συνεχόμενο feedback από και προς τον πελάτη, το οποίο αλλάζει διαρκώς τις απαιτήσεις. Η καταγραφή τον απαιτήσεων σε φυσική γλώσσα δεν βοηθάει μόνο την συζήτηση με τον πελάτη αλλά και τους μηχανικούς μεταξύ τους. Ένα εργαλείο, όπως αυτό που προτείνεται στην διπλωματική, θα ήταν χρήσιμο για έναν Agile μηχανικό λογισμικού. Ας επισημανθεί επίσης ότι ούτε οι Rose και Rainsberger είχαν στην διάθεσή τους παραδείγματα Gherkin γλώσσας για περιγραφή API απαιτήσεων. Επιβεβαίωσαν όμως ότι το BDD είναι μία από τις μεθοδολογίες η οποία αξιοποιείται για ανάπτυξη Web APIs.

Κεφάλαιο 3. Σχετική Βιβλιογραφία & Εξειδίκευση του προβλήματος 48 Εικόνα 3.1: S-CASE: Επισήμανση απαιτήσεων[22]

Κεφάλαιο 3. Σχετική Βιβλιογραφία & Εξειδίκευση του προβλήματος 49 Εικόνα 3.2: S-CASE: Οντολογικό δέντρο εννοιολογικών κλάσεων[22]

Κεφάλαιο 3. Σχετική Βιβλιογραφία & Εξειδίκευση του προβλήματος 50 Εικόνα 3.3: Πρόταση σημασμένη με POS tags και chunks[24] Εικόνα 3.4: Κείμενο σημασμένο με POS tags και structural dependencies[14]

Κεφάλαιο 3. Σχετική Βιβλιογραφία & Εξειδίκευση του προβλήματος 51 3.2 Εξειδίκευση του προβλήματος: Ανάπτυξη Web APIs με την Gherkin και το OpenAPI Specification Εξηγήσαμε τις βασικές έννοιες του REST, του Παγκόσμιου Ιστού, των REST APIs, των μεθοδολογιών ανάπτυξης λογισμικού και του Natural Language Processing. Είδαμε επίσης την υπάρχουσα έρευνα γύρω από το αντικείμενο της διπλωματικής. Πλέον μπορούμε να ορίσουμε το πλαίσιο σχεδίασης και να προτείνουμε ένα σύστημα που να απαντάει στο πρόβλημα που αντιμετωπίζουμε. Οι στόχοι της διπλωματικής είναι δύο: Η απεικόνιση λειτουργικών απαιτήσεων των RESTful API σε Gherkin Η συγγραφή βιβλιοθήκης ικανής να μετατρέπει κείμενο Gherkin σε OpenAPI Specification 3.2.1 Agile RESTful API Development Προκειμένου να πετύχουμε τον πρώτο στόχο, πρέπει να εξετάσουμε το πώς αναπτύσσονται τα Web APIs. Όπως έχουμε εξηγήσει, τα APIs αποτελούν μία χρήσιμη διεπαφή ενός συστήματος. Κατά την ανάπτυξη ενός API δεν είναι δεδομένο ότι αυτό το σύστημα υπάρχει. Έτσι διακρίνονται δύο περιπτώσεις σχεδίασης API. Αυτά τα οποία σχεδιάζονται με βάση ένα υπάρχων σύστημα και αυτά τα οποία σχεδιάζονται ταυτόχρονα με το σύστημα. Για παράδειγμα, μία υπάρχουσα ιατρική βάση δεδομένων με ασθένειες και φάρμακα μπορεί να αξιοποιηθεί περαιτέρω μέσω ενός API για τον σχεδιασμό εφαρμογών για γιατρούς. Από την άλλη ο σχεδιασμός μίας εφαρμογής κινητού τηλεφώνου για κλείσιμο ραντεβού με γιατρό σημαίνει το σχεδιασμό του API μαζί με το σύστημα. Διακρίνονται επίσης και δύο ακόμα κατηγορίες Web APIs: Τα APIs τα οποία απευθύνονται στους μηχανικούς του ίδιου του συστήματος (εσωτερική κατανάλωση) και τα APIs που απευθύνονται σε μηχανικούς εκτός του συστήματος (δημόσια APIs). Παράδειγμα της πρώτης κατηγορίας αποτελούν όλες οι υπηρεσίες του Παγκόσμιου Ιστού που συνοδεύονται από εφαρμογές επιτραπέζιου υπολογιστή ή κινητού. Για παράδειγμα το Dropbox 1 δίνει στους μηχανικους ένα API για να σχεδιάσουν την Desktop εφαρμογή. Από την άλλη γνωστά παράδειγμα της δεύτερης κατηγορίας, τα λεγόμενα Public API, αποτελούν τα δημόσια API των Google 2, Twitter 3, Facebook 4, YouTube 5, Microsoft 6, Amazon 7 και πάρα πολλών άλλων εταιριών. Την δική μας περίπτωση αφορούν τα APIs, τα οποία σχεδιάζονται μαζί με το σύστημα και έχουν στόχο την εσωτερική κατανάλωση. Δηλαδή μας ενδιαφέρει η περίπτωση σχεδιασμού ενός συστήματος/υπηρεσίας από την αρχή και η αξιοποίησή του με εφαρμογές λογισμικού. Ο τελικός χρήστης θα έχει πρόσβαση στο σύστημα μέσω αυτών των εφαρμογών. Υπό αυτή την έννοια, ο μηχανικός που σχεδιάζει το Web API έχει στο μυαλό του 3 επίπεδα αφαιρετικότητας (εικόνα 3.5): 1 2 3 4 5 6 7

Κεφάλαιο 3. Σχετική Βιβλιογραφία & Εξειδίκευση του προβλήματος 52 1. Το συνολικό σύστημα το οποίο βρίσκεται πίσω από το API 2. Το κομμάτι του συστήματος το οποίο εκτίθεται μέσα από το API και αφορά μηχανικούς λογισμικού 3. Την τελική εφαρμογή που προορίζεται για τον χρήστη Εικόνα 3.5: Τα επίπεδα σχεδιασμού ενός API 1 Συνεπώς αντί να σχεδιάζει για τον χρήστη, σχεδιάζει για τον μηχανικό λογισμικού εφαρμογής, έτσι ώστε ο δεύτερος να σχεδιάσει για τον χρήστη. Άρα έχουμε δύο κατηγορίες μηχανικών λογισμικού 1. Ο μηχανικός λογισμικού του συστήματος, τον οποίο αφορά το συνολικό σύστημα, συμπεριλαμβανομένων των όποιων API και τελικών χρηστών 2. Ο μηχανικός λογισμικού της εκάστοτε εφαρμογής, τον οποίο αφορά μόνο η συγκεκριμένη εφαρμογή, το API που αυτή χρησιμοποιεί και οι χρήστες της Οι μηχανικοί λογισμικού της 2ης κατηγορίας, είναι και αυτοί χρήστες του συστήματος. Η ιδιότητα αυτή προκύπτει από την φύση του Παγκόσμιου Ιστού ως πλατφόρμα εφαρμογών. Το εργαλείο που αναπτύσσουμε εμείς, αφορά τους μηχανικούς λογισμικού του συστήματος. Άρα πρέπει να ορίσουμε όσο γίνεται καλύτερα αυτό το πλαίσιο. Ένα άλλο σημείο προσοχής είναι το πώς αναπτύσσονται τα Web APIs ώστε να είναι RESTful. Όπως αναφέραμε στην Ενότητα 2.1.3, το REST είναι ένα σετ κανόνων. Ως σετ κανόνων, δεν προσδιορίζει τον τρόπο με τον οποίο μπορούν να ακολουθηθούν αυτοί οι κανόνες. Ιδίως όταν οι κανόνες αυτοί δεν έχουν γραφεί αποκλειστικά για τον Παγκόσμιο Ιστό. Το γεγονός αυτό έχει διαπιστωθεί από την ερευνητική κοινότητα. Έτσι για παράδειγμα στα βιβλία Rest in Practise [31], RESTful Web Services [20] και RESTful Web APIs [19], σκιαγραφείται μία αρχιτεκτονική σχεδιασμού RESTful Web APIs. Η αρχιτεκτονική αυτή συγκεντρώνει τις παρακάτω αρχές: Όλες οι πληροφορίες του συστήματος αντιμετωπίζονται ως πόροι Παγκόσμιου Ιστού Τα ειδικά χαρακτηριστικά των πληροφοριών συνοψίζονται σε αναπαραστάσεις πόρων Παγκόσμιου Ιστού Οι πόροι θα καθίστανται διαθέσιμοι προς αξιοποίηση μέσω URIs

Κεφάλαιο 3. Σχετική Βιβλιογραφία & Εξειδίκευση του προβλήματος 53 Το σύστημα είναι ανεξάρτητο των εφαρμογών. Δηλαδή οι εφαρμογές οφείλουν να συμπεριλαμβάνουν όλες τις απαραίτητες πληροφορίες για την διεκπεραίωση των αιτημάτων τους Το ρήματα HTTP πρέπει να έχουν απλή ερμηνεία, όπως αυτονόητα ορίζεται από την λέξη τους. Οι πόροι συνδέονται μεταξύ τους με hypermedia controls. Η πλοήγηση στο σύστημα διασφαλίζεται με το HATEOAS. Έτσι ισχύουν οι έννοιες Resource State και Application State Τα αιτήματα HTTP χαρακτηρίζονται από safety ή/και idempotency Έτσι ακολουθώντας αυτή την λογική, η οποία περιστρέφεται γύρω από την έννοια των πόρων, ο σχεδιασμός μίας υπηρεσίας Παγκόσμιου Ιστού κατά REST γίνεται πιο ξεκάθαρος. 3.2.2 Λειτουργικές και μη, απαιτήσεις Κατά την ανάπτυξη λογισμικού οι απαιτήσεις του συτήματος χωρίζονται σε λειτουργικές και μη. Οι λειτουργικές απαιτήσεις αφορούν την λειτουργία του συστήματος. Δηλαδή συνδέονται άμεσα με την κεντρική ιδέα του λογισμικού και προσπαθούν να την καταστήσουν ικανή να υλοποιηθεί. Έτσι στον σχεδιασμό π.χ. ενός e-shop, λειτουργικές απαιτήσεις αφορούν τους χρήστες, τα προϊόντα, τις παραγγελίες, τις πληρωμές κ.λ.π.. Οι λειτουργικές απαιτήσεις είναι αυτές που μπορούν κυρίως να συζητηθούν με τον πελάτη (customer domain). Από την άλλη, οι μη λειτουργικές απαιτήσεις αφορούν την λειτουργικότητα του συστήματος. Δηλαδή την δυνατότητά του να υποστηρίζει τις λειτουργίες του. Έτσι στο προηγούμενο παράδειγμα μη λειτουργικές απαιτήσεις είναι η ταχύτητα απόκρισης, η δυνατότητα να παραμένει το σύστημα ενεργό, η ασφάλεια, η προστασία των προσωπικών δεδομένων κ.λ.π.. Στο σύστημα της διπλωματικής, μας αφορά η καταγραφή των λειτουργικών απαιτήσεων. Μας ενδιαφέρει η συζήτηση με τον πελάτη, να είναι όσο το δυνατόν πιο κοντά στο τεχνικό του αντικείμενο. Οι λεπτομέρειες του συστήματος που δεν αφορούν την λειτουργία του, δεν πρέπει να φαίνονται στον πελάτη. 3.2.3 Απαιτήσεις συστήματος Με βάση τα παραπάνω, οι απαιτήσεις του συστήματος είναι οι ακόλουθες REST-aware: Η τελική τυποποίηση πρέπει να περιγράφει μία RESTful υπηρεσία Παγκόσμιου Ιστού Agile-friendly: Η διαδικασία ανάπτυξης λογισμικού με το εργαλείο πρέπει να υποστηρίζει το ευέλικτο μοντέλο ανάπτυξης λογισμικού OAS-aware: Το τελικό προϊόν είναι το OpenAPI Specification, άρα η διαδικασία μετατροπής πρέπει προφανώς να περιορίζεται από τους κανόνες του Η μετατροπή από Gherkin σε OpenAPI Specification πρέπει να γίνεται σε λογικά γρήγορο χρόνο. Δηλαδή αρκετά γρηγορότερα από το να γίνει χειροκίνητα

Κεφάλαιο 3. Σχετική Βιβλιογραφία & Εξειδίκευση του προβλήματος 54 Οι απαιτήσεις που θα καταγράφονται σε Gherkin πρέπει να είναι τύπου λειτουργικές Το σύστημα πρέπει να λαμβάνει υπ όψιν ότι χρήστης του API είναι ένας μηχανικός λογισμικού Possible to develop: Ο σχεδιασμός πρέπει να επιλύει τα προβλήματα που προκύπτουν από την μη τυποποίηση των εννοιών του Παγκόσμιου Ιστού και την πολυπλοκότητα του NLP Όσον αφορά την τελευταία απαίτηση, προκειμένου να εκπληρωθεί απαιτούνται κάποιοι συμβιβασμοί. Οι συμβιβασμοί αυτοί έχουν ως εξής και σχετίζονται με την έννοια Ομοιόμορφη Διεπαφή : 1. Τα resources διακρίνονται σε single resources, collections και functions. Τα collections και τα functions έχουν διαφορά μόνο νοηματική, το λογισμικό του συστήματος δεν τα διακρίνει. Τα single resources έχουν παραμετροποιημένο path ως εξής:. Αντίθετα τα collections και τα functions έχουν απλό path ώς εξής: ή. Ένα resource μπορεί να έχει και απλό και παραμετροποιημένο path 2. Η λογική, ιεραρχική σχέση των resources μεταξύ τους, μπορεί να εμφανίζεται στο path τους 3. Τα ρήματα GET και DELETE δεν παίρνουν body κατά το HTTP αίτημα και μπορούν να έχουν path παράμετρο ή/και query παράμετρο 4. Το ρήμα POST μπορεί να πάρει μόνο body. 5. Το ρήμα PUT μπορεί να έχει και body και path παράμετρο και query παράμετρο 6. Τα υπόλοιπα ρήματα του HTTP είναι τεχνικής φύσεως και δεν μπορούν να απεικονισθούν σε κείμενο λειτουργικών απαιτήσεων 7. Τα πιθανά status codes ορίζονται εκ σχεδιασμού και προς το παρών περιορίζονται στα 200,201,202,400,401,404. Τα status codes πρέπει να συνοδεύονται από μήνυμα περιγραφής Επιπρόσθετα, όπως θίξαμε σε προηγούμενη ενότητα, χρήστης του συστήματος είναι και ο μηχανικός λογισμικού που θα χρησιμοποιήσει το API. Άρα το σύστημά μας πρέπει να λαμβάνει υπ όψιν και τον μηχανικό που θα χρησιμοποιεί το API. Στην πράξη αυτό καλύπτεται, καταρχήν από το OpenAPI Specification, κατά δεύτερον από το REST και τις αρχές του Παγκόσμιου Ιστού και κατά τρίτον από τις λογικές συμβάσεις που αναφέραμε. 0

55 Κεφάλαιο 4 Μεθοδολογία & Υλοποίηση συστήματος 4.1 Μεθοδολογία Στις δύο πρώτες υποενότητες αυτής της ενότητας, εξετάζουμε την μεθοδολογία με βάση την οποία σχεδιάστηκε ο τρόπος απεικόνισης REST απαιτήσεων σε Gherkin. Επίσης, στην τρίτη υποενότητα παρουσιάζουμε την μεθοδολογία ανάπτυξης του λογισμικού που υλοποιήθηκε στο πλαίσιο της διπλωματικής. 4.1.1 Τεχνικό επίπεδο της Gherkin Το πρώτο πρόβλημα που αντιμετωπίσθηκε ήταν το θέμα της τεχνικής γλώσσας σε κείμενο Gherkin. Δηλαδή το ύφος της περιγραφής των απαιτήσεων του API. Παραδείγματος χάρη στο βιβλίο του Cucumber [32], Κεφάλαιο 12 1, προτείνεται η εξής περιγραφή ενός API σε Gherkin Παράδειγμα 4.1: Παράδειγμα περιγραφής API κατά Cucumber Feature: Fruit list In order to make a great smoothie I need some fruit. Scenario: List fruit Given the system knows about the following fruit: name color banana yellow strawberry red When the client requests GET /fruits Then the response should be JSON: """ [ {"name": "banana", "color": "yellow"}, {"name": "strawberry", "color": "red"} ] """ Βλέπουμε ότι γίνεται η επιλογή μίας τεχνικής γλώσσας, η οποία περιλαμβάνει HTTP ρήματα, paths και αναπαραστάσεις πόρων όπως η JSON. Το γεγονός αυτό σχολιάζεται στο blogpost που εξακολουθεί μέχρι σήμερα να εμφανίζεται πρώτο στις αναζητήσεις με tags REST, Cucumber, Gherkin. Στο post αυτό επισημαίνεται ότι μία γλώσσα όπως η Gherkin, ίσως να χάνει το νόημα της όταν γίνεται τόσο τεχνική. Αξίζει να σημειωθεί ότι ένας από τους συγγραφείς του βιβλίου, ο Aslak Hellesoy, είχε σχολιάσει το καλοκαίρι του 2016 πώς το θέμα που θίγεται στο blog 1 Το κεφάλαιο αυτό είναι το μόνο στο οποίο γίνεται αναφορά σε APIs και είναι σύντομο και ενδεικτικό

Κεφάλαιο 4. Μεθοδολογία & Υλοποίηση συστήματος 56 είναι σωστό και ότι το κεφάλαιο του βιβλίου θα επανεξετασθεί 1. Οι υπόλοιπες αναφορές στο διαδίκτυο πάνω στο θέμα, παραπέμπουν στο debate μεταξύ χρήσης τεχνικής ή όχι γλώσσας και είναι ελάχιστες. Πάντως στην περίπτωση περιγραφής API στο Cucumber, ύστερα από την Gherkin καταγράφονται τα step definitions, όπως περιγράφεται στο Παράρτημα A. Άρα δεν χρειάζεται κάποια ιδιαίτερη μεθοδολογία μετατροπής της φυσικής γλώσσας σε κώδικα. Αντίθετα στην δικιά μας περίπτωση είναι βασικός μας στόχος, να μπορούμε να μετατρέψουμε με λογισμικό την φυσική γλώσσα σε τεχνικά χαρακτηριστικά. Άρα το ύφος της Gherkin, πρέπει να αποσαφηνιστεί σχεδιαστικά. Με βάση την μέχρι τώρα θεωρητική και τεχνική ανάλυση, κρίθηκε ότι εξυπηρετεί ένα ύφος κοντινότερο στον πελάτη. Παρ όλο που ο πελάτης μπορεί να μην συμμετέχει άμεσα στην διαδικασία συγγραφής των απαιτήσεων σε Gherkin (ενότητα 3.1.2), η κοινή γλώσσα επικοινωνίας είναι δομικής σημασίας στο BDD και στην Agile φιλοσοφία γενικότερα. Περαιτέρω η υιοθέτηση τεχνικών όρων έχει τα εξής δύο μειονεκτήματα: Πρώτον, εφόσον το Gherkin κείμενο θα περιγράφει ακριβώς την τεχνική διαδικασία, η φυσική γλώσσα θα εμφανίζεται ως θόρυβος. Ένας μηχανικός που έχει την ικανότητα να περιγράψει όλες τις τεχνικές λεπτομέρειες του API σε Gherkin, θα μπορούσε κάλλιστα να συγγράψει κατευθείαν το OpenAPI Specification. Δεύτερον, οι απαιτήσεις του λογισμικού μετατροπής από Gherkin σε OpenAPI Specification, μειώνονται δραματικά διότι το βασικό μέλημα του λογισμικού θα είναι η απλή οργάνωση των τεχνικών χαρακτηριστικών στην τυποποίηση. Συνεπώς η χρήση τεχνικής γλώσσας απορρίφθηκε, διότι κρίθηκε ότι θέτει την διπλωματική εκτός στόχου. 4.1.2 Απεικόνιση REST σε Gherkin Η επιλογή ύφους κοντινότερου στον πελάτη καθιστά την απεικόνιση του OpenAPI Specification σε Gherkin πρόκληση για έναν βασικό λόγο. Δεδομένου ότι το τελικό προϊόν είναι το OpenAPI Specification, η ανάπτυξη του συστήματος που θα περιγράφεται στα feature files, θα ξεκινάει αναπόφευκτα από το API. Τα APIs γενικότερα και τα RESTful Web APIs ειδικότερα, είναι εξ ορισμού τεχνικές έννοιες. Έτσι αν και η ανάπτυξη λογισμικού οδηγούμενη από το API είναι μία θεμιτή μεθοδολογία, πρόβλημα αποτελεί η περιγραφή του API από τον πελάτη. Προκειμένου αυτό το πρόβλημα να αντιμετωπισθεί, αξιοποιήθηκε η βιβλιογραφία γύρω από το REST. Συγκεκριμένα οι βιβλιογραφικές παραπομπές [20], [31] και [19]. Όπως αναλύσαμε εκτενώς στην Ενότητα 2.1 τα δομικά στοιχεία του Παγκόσμιου Ιστού είναι τα resources, τα resource representations, τα URIs και το πρωτόκολλο HTTP. Επιπλέον επεξηγήσαμε την έννοια του Uniform Interface και του HATEOAS. Στις προαναφερθείσες βιβλιογραφικές παραμομπές τα παραπάνω αξιοποιούνται ώστε: 1. Να προταθεί μία μεθοδολογία ανάπτυξης RESTful Web APIs η οποία θα περιστρέφεται γύρω από τους πόρους 2. Η φιλοσοφία του HATEOAS να αντιστοιχιστεί σε πρωτόκολλα που ακολουθούν επιχειρίσεις και οργανισμοί 2.1.4.1 Οι ιδέες αυτές βασίζονται στην λογική Thinking in resources, η οποία επίσης προτείνεται στην βιβλιογραφία. Αν και αυτή η λογική ακολουθείται για να χτιστεί μία αρχιτεκτονική σχεδίασης REST υπηρεσιών, ή ίδια λογική μπορεί να χρησιμοποιηθεί και αλλιώς: Μπορεί επίσης να αποτελέσει έναν τρόπο σκέψης κατά την περιγραφή του API. Αυτό διότι η έννοια του πόρου είναι μία πολύ απλή έννοια, η οποία συνδέεται άμεσα 1 Το σχόλιο αυτό δεν εμφανίζεται πλέον στην ιστοσελίδα (Φεβρουάριος 2017)

Κεφάλαιο 4. Μεθοδολογία & Υλοποίηση συστήματος 57 με την έννοια της πληροφορίας και άρα καθίσταται γρήγορα κατανοητή. Η έννοια του πόρου είναι η απαραίτητη γέφυρα που χρειαζόμαστε για να πραγματοποιήσουμε την ομαλή απεικόνιση της φιλοσοφίας του REST σε Gherkin. Επιπρόσθετα του τρόπου σκέψης γύρω από τους πόρους, απευθείας μπορούμε να αξιοποιήσουμε την, παρουσιαζόμενη στην βιβλιογραφία, αντιστοίχιση του Hypermedia as the Engine of Application State στα Domain Application Protocols. Η επιτυχής σύλληψη της λογικής του επιχειρησιακού μοντέλου του πελάτη είναι ζωτικής σημασίας και άρα η ιδέα αυτή είναι ευπρόσδεκτη στο σύστημά μας. Τέλος όπως περιγράψαμε στην ενότητα 2.1.4.1, αποτέλεσμα μετάβασης στο DAP, είναι η αλλαγή του resource state και του application state. Επίσης στην ενότητα 2.2.2, αναδείξαμε πώς η λογική περιγραφής του User Story κατά Gherkin παρομοιάζεται με την λογική περιγραφή μία μηχανής καταστάσεων. Αυτή η φυσική σύνδεση μεταξύ Gherkin και HATEOAS, ολοκληρώνει την πλήρη απεικόνιση της φιλοσοφίας του REST σε Gherkin. Η τυποποίηση αυτής της απεικόνισης περιγράφεται αναλυτικά στην ενότητα 4.2.1. 4.1.3 Λογισμικό Κατά την ανάπτυξη του λογισμικού μετατροπής από Gherkin σε OpenAPI Specification ακολουθήθηκε η Agile φιλοσοφία σχεδίασης. Πριν την ανάπτυξη του λογισμικού ολοκληρώθηκε ο γενικός σχεδιασμός της απεικόνισης REST σε Gherkin. Στην συνέχεια μελετήθηκε διεξοδικά το OpenAPI Specification. Από την μελέτη διαπιστώθηκε ότι υπάρχουν χαρακτηριστικά της τυποποίησης τα οποία είναι βασικά. Τέτοια είναι παραδείγματος χάρη τα paths, οι παράμετροι, τα HTTP ρήματα και οι HTTP απαντήσεις. Προκειμένου να έχουμε ένα valid OpenAPI Specification, αυτά τα χαρακτηριστικά πρέπει απαραίτητα να υπάρχουν. Έτσι δημιουργήθηκε ένα αρχικό backlog χαρακτηριστικών προς υλοποίηση. Στην συνέχεια ακολουθήθηκε η παρακάτω λογική: 1. Εισαγωγή ενός νέου χαρακτηριστικού του OpenAPI Specification προς υλοποίηση 2. Αποσαφήνιση περιοχών εμφάνισης του χαρακτηριστικού στο Gherkin κείμενο 3. Συγγραφή Gherkin που περιγράφει το χαρακτηριστικό 4. Συγγραφή κώδικα που διαβάζει προτάσεις του Gherkin κειμένου, όπου το χαρακτηριστικό εμφανίζεται 5. Συγγραφή κώδικα μηχανισμών επεξεργασίας φυσικής γλώσσας ο οποίος εντοπίζει το χαρακτηριστικό στις προτάσεις 6. Συγγραφή κώδικα ο οποίος οργανώνει το χαρακτηριστικό στην μορφή του OpenAPI Specification 7. Επανάληψη από το βήμα (1) Αφού υλοποιήθηκαν επιτυχώς τα paths, οι παράμετροι των path, των query και των body, τα HTTP ρήματα και οι HTTP απαντήσεις, με την παραπάνω λογική, ο σκελετός του κώδικα είχε διαμορφωθεί. Κατά την διαδικασία συγγραφής του κώδικα, στόχος ήταν οι εσωτερικές του λειτουργίες να είναι κατά το δυνατόν ανεξάρτητες (Agile φιλοσοφία). Αυτή η αρχή ακολουθήθηκε τόσο κεντρικά στο λογισμικό, όσο και εσωτερικά των αρχείων. Με βάση λοιπόν τον διαμορφωμένο και ανεξάρτητα δομημένο κώδικα, άρχισαν να προστίθενται νέα χαρακτηριστικά. Έτσι προστέθηκαν οι τύποι δεδομένων, τα HA- TEOAS links, τα μηνύματα των status codes, η ιεραρχία των resources, οι ρόλοι, οι μη υποχρεωτικές παράμετροι και άλλες ιδιότητες παραμέτρων, η προαιρετική περιγραφή

Κεφάλαιο 4. Μεθοδολογία & Υλοποίηση συστήματος 58 των σεναρίων, η οργάνωση παραμέτρων σε μοντέλα, η οργάνωση των ρόλων σε μοντέλα κ.α.. Όλα αυτά τα χαρακτηριστικά υλοποιήθηκαν με βάση την προαναφερθείσα σειρά βημάτων. Αφού υλοποιήθηκε ένας μεγάλος αριθμός χαρακτηριστικών του OpenAPI Specification, το λογισμικό αντιμετωπίσθηκε συνολικά σαν σύστημα. Έτσι γράφτηκε ξεχωριστός κώδικας τερματικού και ξεχωριστός κώδικας γραφικής διεπαφής. Η γραφική διεπαφή αν και λειτουργική δεν προχώρησε περαιτέρω διότι δεν εξυπηρετούσε κάποιον σκοπό. Επίσης γράφτηκε δυνατότητα εκτέλεσης χωρίς Gherkin αρχεία, αλλά με μοντέλα χαρακτηριστικών προηγούμενων εκτελέσεων. Επιπλέον προστέθηκε το χαρακτηριστικό απεικόνισης του API από τα HATEOAS links τα οποία εντοπίζονται. Τα παραπάνω συνοψίζουν την μεθοδολογία ανάπτυξης του λογισμικού.

Κεφάλαιο 4. Μεθοδολογία & Υλοποίηση συστήματος 59 4.2 Υλοποίηση Συστήματος Στην ενότητα αυτή εξετάζουμε αρχικά με αναλυτικό τρόπο τον σχεδιασμό απεικόνισης λειτουργικών απαιτήσεων REST συστήματος σε Gherkin. Έπειτα παρουσιάζουμε το μοντέλο λειτουργίας του λογισμικού που αναπτύχθηκε στα πλαίσια τις διπλωματικής, τα χαρακτηριστικά του, τις συναρτήσεις του και τις τεχνικές επεξεργασίας φυσικής γλώσσας που αυτό χρησιμοποιεί. 4.2.1 Απεικόνιση λειτουργικών απαιτήσεων REST συστήματος σε Gherkin: Resource Driven Development Με βάση τις απαιτήσεις συστήματος και τους συμβιβασμούς, όπως ορίστηκαν στην ενότητα 3.2.3, αλλά και όσα περιγράφηκαν στις ενότητες 4.1.1 και 4.1.2, σχεδιάζεται και προτείνεται η μεθοδολογία Resource Driven Development (RDD) για την ανάπτυξη RESTful Web APIs. Κατά το Resource Driven Development, ο μηχανικός σκέφτεται με βάση τους πόρους που θα εκθέτει το σύστημά του μέσω ενός Web API. Η λογική αυτή σκέψης αφορά τόσο την οργάνωση της πληροφορίας όσο και την υλοποίηση του Domain Application Protocol. Τα δύο αυτά θέματα μπορούν να συζητηθούν με τον πελάτη και τον αφορούν άμεσα. Μάλιστα το DAP το γνωρίζει καλά μόνο ο πελάτης και άρα μόνο μέσω αυτού μπορεί να διαπιστωθεί αλλά και να επιβεβαιωθεί. Το DAP υλοποιείται μέσω του HATEOAS. Το Resource Driven Development ορίζει ότι: Οι λειτουργικές απαιτήσεις του API περιγράφονται σε γλώσσα Gherkin. Tα feature files ονομάζονται πλέον resource files και έχουν επέκταση.resource αντί.feature. Σε ένα resource file περιγράφεται ένα και μόνο ένα resource. Το resource που περιγράφεται στο resource file, δίνει και το όνομα στο αρχείο. Έτσι το book resource περιγράφεται στο αρχείο book.resource. Τα σενάρια εντός του resource file περιγράφουν τα HTTP αιτήματα προς το API και την HTTP απάντηση από το API. Συγκεκριμένα στο When βήμα περιγράφεται το αίτημα και στο Then βήμα περιγράφεται η απάντηση. Αποτέλεσμα πραγματοποίησης ενός σεναρίου είναι η πιθανή αλλαγή του resource state και του application state. Το application state είναι το σύνολο των δυνατών μεταβάσεων σε άλλα resources από το τρέχον resource. Οι μεταβάσεις αυτές διαφημίζονται στην απάντηση του API. Η διαφήμιση σε τεχνικό επίπεδο γίνεται με hypermedia controls και άρα με το HATEOAS. Έτσι στο Then βήμα μπορούν να περιγραφούν τέτοιες μεταβάσεις. Οι όποιες παράμετροι περιγράφονται είτε στο κείμενο των βημάτων των σεναρίων, είτε σε πίνακες των βημάτων των σεναρίων. Αν οι παράμετροι περιγράφονται σε πίνακα τότε μπορούν να προσδιορισθούν και οι τύποι τους, με παράδειγμα. Αν πρόκειται για αριθμούς, τότε μπορούν να περιγραφούν και οι μέγιστες και οι ελάχιστες τιμές τους. Η λογική, ιεραρχική, σχέση των resources μπορεί προαιρετικά να περιγραφεί στο Background. Ρόλοι/χρήστες του API και τα δικαιώματα αυτών, μπορούν να περιγραφούν μόνο σε Given βήματα είτε στο Background είτε στα σενάρια.

Κεφάλαιο 4. Μεθοδολογία & Υλοποίηση συστήματος 60 Στην συνέχεια θα εξετάσουμε αναλυτικά το RDD με παραδείγματα. Paths Τα paths στο RDD δεν περιγράφονται στο Gherkin κείμενο εξ ολοκλήρου. Επειδή ακολουθείται η λογική περιγραφής ανά πόρο, όλες οι βάσεις των path προκύπτουν από τα ονόματα των πόρων, άρα των αρχείων. Αυτό που χρειάζεται να περιγραφεί είναι οι ενδεχόμενες παράμετροι το path (βλ. πιο κάτω). Operations Τα operations, δηλαδή τα HTTP ρήματα, περιγράφονται στην πρόταση του σεναρίου που αρχίζει από When. Η περιγραφή τους γίνεται με το ρήμα της πρότασης. Το ρήμα αυτό αντιστοιχεί με λογικό τρόπο σε ένα operation. Για τον λόγο, αυτό ο χρήστης του RDD παροτρύνεται στην χρήση ρημάτων, τα οποία έχουν την σημασία της δημιουργίας ή της διαγραφής ή της προβολής ή της ενημέρωσης ενός πόρου. Έτσι, στο Παράδειγμα 4.2, το operation είναι το retrieve το οποίο αντιστοιχεί στο HTTP ρήμα GET. Παράδειγμα 4.2: RDD: Παράδειγμα βήματος με http ρήμα When I retrieve a product by it`s name Σε μία πρόταση μπορούν να επισημανθούν παραπάνω από ένα operations, όπως φαίνεται στο Παράδειγμα 4.3. Στην περίπτωση αυτή όλες οι παράμετροι και οι απαντήσεις του API που περιγράφονται, θα προστεθούν στα paths και των τριών ρημάτων, στις ανάλογες θέσεις τους (βλ. πιο κάτω) Παράδειγμα 4.3: RDD: Παράδειγμα βήματος με περισσότερα το ενός http ρήματα When I try to delete, retrieve or edit the product Parameters Οι παράμετροι μπορούν να προσδιοριστούν είτε εντός μίας πρότασης, με ουσιαστικό, είτε σε πίνακα ακριβώς κάτω από αυτήν. Για τις παραμέτρους μας ενδιαφέρουν τα εξής: Η θέση τους (path, query, body, form) Το όνομά τους Ο τύπος τους Το ενδεχόμενο format τους Το αν είναι απαραίτητες ή όχι Ο ενδεχόμενος περιορισμός τους ανάμεσα σε μέγιστα και ελάχιστα Προκειμένου να περιγραφεί η θέση των παραμέτρων, πρέπει να ληφθούν υπ όψιν οι συμβάσεις (1),(3),(4) και (5) της ενότητας 3.2.3 τις οποίες παραθέτουμε και εδώ για ευκολία: 1. Τα resources διακρίνονται σε single resources, collections και functions. Τα collections και τα functions έχουν διαφορά μόνο νοηματική, το σύστημα δεν τα διακρίνει. Τα single resources έχουν παραμετροποιημένο path ως εξής:. Αντίθετα τα collections και τα functions έχουν απλό path ώς εξής: ή. Ένα resource μπορεί να έχει και απλό και παραμετροποιημένο path

Κεφάλαιο 4. Μεθοδολογία & Υλοποίηση συστήματος 61 2. Τα ρήματα GET και DELETE δεν παίρνουν body κατά το HTTP αίτημα και μπορούν να έχουν path παράμετρο ή/και query παράμετρο 3. Το ρήμα POST μπορεί να πάρει μόνο body. 4. Το ρήμα PUT μπορεί να έχει και body και path παράμετρο και query παράμετρο Επισημαίνουμε ότι παράμετροι στο κείμενο, οι οποίες έχουν ακριβώς το ίδιο όνομα με έναν πόρο ή τον πληθυντικό αυτού, δεν αντιμετωπίζονται ως παράμετροι. Τέτοιες παράμετροι θα πρέπει να τοποθετούνται σε πίνακα. Η θέση των παραμέτρων προσδιορίζεται από την περιγραφή του When βήματος. Οι παράμετροι που θέλουμε να εμφανίζονται στο path, πρέπει να δηλώνονται μία και μόνο μία φορά στην πρώτη πρόταση του When βήματος ή στον πίνακα της πρώτης πρότασης του When βήματος. Και στις δύο περιπτώσεις δεν πρέπει να εμφανίζονται άλλες παράμετροι. Στο Παράδειγμα 4.4 βλέπουμε τρόπους περιγραφής path παραμέτρου. Παράδειγμα 4.4: RDD: παράμετροι στο path When I retrieve the basket by it`s id When I retrieve the basket by it`s id id 130 When I retrieve the basket id 120 Επισημαίνουμε ότι: Αν το ρήμα της πρότασης περιγράφει operation τύπου GET, PUT, DELETE Αν σε όλα τα βήματα του When δεν περιγράφονται άλλες παράμετροι Αν σε κανένα άλλο σημείο του resource file δεν περιγράφονται path παράμετροι τότε μία id path παράμετρος θα υποτεθεί. Επίσης υπενθυμίζουμε ότι το POST δεν παίρνει path. Αν οι παράμετροι των GET, DELETE είναι παραπάνω από μία, τότε αυτές μπορούν να τοποθετηθούν σε query. Παραδείγματα query φαίνονται στο Παράδειγμα 4.5. Παράδειγμα 4.5: RDD: παράμετροι σε query When I retrieve a product list by it`s id And I filter the results by name and category When search for a product by it`s date and it`s name date 12/04/2017 name `bike` When I search for a test And I specify a date range start date 12/04/2017 03:05 end date 12/04/2017 12:05 When I delete a registration client_names [`John`,`Nick`] maximum of 10 client_surnames [`Andrew `,`Rose`] maximum of 10

Κεφάλαιο 4. Μεθοδολογία & Υλοποίηση συστήματος 62 Στην περίπτωση του PUT, όταν θέλουμε να έχει και path και query και body parameters, τότε πρέπει υποχρεωτικά το query να περιγραφεί σε πίνακα και να αναγράφεται στην πρόταση του βήματος η λέξη query. Αν και η περίπτωση είναι εξαιρετική, υποστηρίζεται. Όταν περιγράφουμε POST ή PUT, τότε μπορούμε να περιγράψουμε body παραμέτρους. Στην περίπτωση του PUT, εφόσον οι περιγραφόμενες παράμετροι είναι περισσότερες από μία και δεν έχουν επισημανθεί ως query, αυτομάτως τοποθετούνται στο body. Αντίθετα στο POST, όλες οι παράμετροι τοποθετούνται πάντα στο body (με βάση τις συμβάσεις). Παράδειγμα body παραμέτρων φαίνεται στο Παράδειγμα 4.6. Παράδειγμα 4.6: RDD: παράμετροι σε body When I submit products to the basket name `Laptop` qt 5 maximum of 10 and minimum of 2 Όσον αφορά τους τύπους των παραμέτρων, οι παράμετροι που εντοπίζονται σε προτάσεις, αντιμετωπίζονται ως string. Εξαίρεση αποτελεί η λέξη id όπου εντοπίζεται ώς int32. Για να εντοπισθεί μία παράμετρος σε μία πρόταση πρέπει, όπως είπαμε, να είναι ουσιαστικό της πρότασης. Η περιγραφή τύπων των παραμέτρων μπορεί να γίνει σε έναν Gherkin πίνακα, όπως έχει φανεί στα έως τώρα παραδείγματα. Σε ένα τέτοιο πίνακα μπορεί να δοθεί ένα ενδεικτικό παράδειγμα τιμής της παραμέτρου, από το οποίο θα εξαχθεί ο τύπος δεδομένου. Ενδεικτικό παράδειγμα σημαίνει ότι για να εντοπισθεί π.χ. ότι η παράμετρος είναι δεκαδικό νούμερο, πρέπει το παράδειγμά της να είναι 10.1 και όχι 10. Από τύπους δεδομένων του OpenAPI Specification υποστηρίζονται: string, integer, number, file, date, date-time, boolean, password, array και file. Επίσης στον πίνακα μπορεί να περιγραφεί η μέγιστη και η ελάχιστη τιμή της παραμέτρου (μήκος αν είναι string, μέγεθος αν είναι πίνακας). Αν τα μεγέθη της παραμέτρου περιορίζονται από και μέγιστο και ελάχιστο, τότε αρκεί η επισήμανση, οπουδήποτε εντός του κελιού, των δύο αριθμητικών ορίων. Αντίθετα αν περιορίζονται από μόνο ένα όριο, τότε πρέπει να δίνεται μία ενδεικτική λέξη ή φράση που περιγράφει αν είναι μέγιστο ή ελάχιστο, π.χ. can t be greater than. Τέλος, στην παρούσα έκδοση του λογισμικού, ο πίνακας πρέπει να ακολουθεί μία λογική. Αυτή είναι ότι η πρώτη γραμμή/στήλη θα έχει τα ονόματα των παραμέτρων, η δεύτερη τα παραδείγματα και η τρίτη τα μέγιστα/ελάχιστα. Οι πίνακες παραμέτρων μπορούν να έχουν πολλές μορφές όπως φαίνεται στα παραδείγματα 4.7-4.11 Παράδειγμα 4.7: RDD είδη πινάκων: Πίνακας με παραμέτρους στην πρώτη στήλη και παραδείγματα στην δεύτερη name `bag` size 5 color `blue` on_sale true collection [1 2 3 4] Παράδειγμα 4.8: RDD είδη πινάκων: Πίνακας με παραμέτρους στην πρώτη γραμμή και παραδείγματα στην δεύτερη name description category `bag` `great bag` `sports`

Κεφάλαιο 4. Μεθοδολογία & Υλοποίηση συστήματος 63 name price Παράδειγμα 4.9: RDD είδη πινάκων: Πίνακας μόνο με ονόματα παραμέτρων order_document file Παράδειγμα 4.10: RDD είδη πινάκων: Πίνακας με μία παράμετρο Παράδειγμα 4.11: RDD είδη πινάκων: Πίνακας με μέγιστα και ελάχιστα name `Laptop` qt 4 maximum of 10 and minimum of 2 Εκτός των τύπων, το RDD δίνει την δυνατότητα οι body παράμετροι να οργανώνονται σε μοντέλα. Πέρα από τα μοντέλα που θα δημιουργήσει το σύστημα αυτόματα, ο χρήστης του RDD μπορεί να ονοματίσει ο ίδιος ένα πίνακα και έτσι να τον οργανώσει σε ένα μοντέλο. Προκειμένου ένα πίνακας που προορίζεται για body να οργανωθεί σε μοντέλο, πρέπει η πρόταση η οποία τον περιγράφει, να τελειώνει με άνω κάτω τελεία (:). Όταν η πρόταση τελειώνει με άνω κάτω τελεία, το σύστημα θα αναζητήσει ένα ουσιαστικό (ακόμη και με ίδιο όνομα με τα resources) στην πρόταση περιγραφής του πίνακα, και θα δώσει το όνομά του ως όνομα του μοντέλου. Με αυτόν τον διακριτικό τρόπο ο χρήστης του RDD μπορεί να κάνει χρήση μοντέλων χωρίς να επιβαρύνει τεχνικά το κείμενο. Παράδειγμα περιγραφής μοντέλου φαίνεται στο Παράδειγμα 4.12. Παράδειγμα 4.12: RDD: περιγραφή μοντέλου When I update the product: name `bag` description `great bag` category `sports` Τέλος οι παράμετροι μπορεί να είναι υποχρεωτικές ή όχι. Σε ένα API, οι παράμετροι είναι υποχρεωτικές όταν πρέπει όλες να συμμετέχουν είτε στο HTTP αίτημα είτε στην HTTP απάντηση. Το RDD δίνει την δυνατότητα να περιγράφεται ένα HTTP αίτημα και οι ενδεχόμενες HTTP απαντήσεις του παραπάνω από μία φορές. Έτσι οι παράμετροι που εμφανίζονται σε όλα τα ίδια HTTP αιτήματα και σε όλες τις ίδιες HTTP απαντήσεις, διαπιστώνονται ως required 1. Με αυτό τον τρόπο, ο χρήστης του RDD μπορεί να ξανά περιγράψει ένα σενάριο, μόνο για να δείξει ποιες μεταβλητές είναι υποχρεωτικές. Τέλος επισημαίνουμε ότι η διάκριση των HTTP απαντήσεων δεν γίνεται με βάση το εκάστοτε HTTP αίτημα που τις προκαλεί αλλά με βάση το status code (βλ. παρακάτω). Άρα υποχρεωτικές παράμετροι στην HTTP απάντηση είναι όσες εμφανίζονται στα ίδια operation με τα ίδια status code. Responses Η περιγραφή των HTTP απαντήσεων ξεκινάει από την πρόταση του βήματος Then και τις προτάσεις And που την ακολουθούν. Σε μία τέτοια πρόταση μπορούν να περιγραφούν παράμετροι, status codes και HATEOAS links. Για τις παραμέτρους ισχύει, ό,τι ισχύει και για τις body παραμέτρους των operation. Σχετικά με τα status code υπενθυμίζουμε την σύμβαση (7): 1 Επισημαίνεται ότι σε αυτή την περίπτωση τα body τύπου μοντέλα, αντιμετωπίζονται ως μία παράμετρος. Το αν οι παράμετροι του μοντέλου είναι υποχρεωτικές, δεν εξετάζεται

Κεφάλαιο 4. Μεθοδολογία & Υλοποίηση συστήματος 64 Τα πιθανά status codes ορίζονται εκ σχεδιασμού και προς το παρών περιορίζονται στα 200,201,202,400,401,404. Τα status codes πρέπει να συνοδεύονται από μήνυμα περιγραφής Έτσι ορίζουμε ότι, προκειμένου να εντοπισθεί ένα status code σε μία πρόταση, τότε πρέπει να αναγράφεται στην πρόταση ή λέξη message και η περιγραφή του να είναι εντός εισαγωγικών. Η περιγραφή αυτή πρέπει να είναι νοηματικά παραπλήσια με το code. Π.χ. success, ok, updated, deleted, retrieved, canceled για 200 και not found, doesn t exist, does not exist, unable to find, can t find για 404. Αν δεν εντοπισθεί status code σε κανένα βήμα, ανατίθεται το default, όπως επιτρέπει το OpenAPI Specification. Επισημαίνουμε ότι όλες οι παράμετροι και τα HATEOAS links που εντοπίζονται, θα αντιστοιχούν σε αυτό το status code. Παράδειγμα status code δίνεται στο Παράδειγμα 4.13. Στο παράδειγμα αυτό εντοπίζεται το status code Bad Request, 400. Παράδειγμα 4.13: RDD: status code When I submit a wrong payment for an order Then I should see a message saying `wrong amount ` Όσον αφορά τα HATEOAS links, αυτά περιγράφονται με επισήμανση του ρήματος μετάβασης και του πόρου μετάβασης. Έτσι στην πρόταση πρέπει να αναγράφεται και το ρήμα αλλά και ακριβώς το όνομα του πόρου μετάβασης. Σε τέτοιο ίδιου προτάσεις δεν αναζητούνται παράμετροι ή status codes. Η πρόταση δεν πρέπει να έχει πίνακα από κάτω. Παράδειγμα HATEOAS link φαίνεται στο Παράδειγμα 4.14. Τα links που εντοπίζονται είναι τα POST payment, GET order, DELETE order, PUT order. Παράδειγμα 4.14: RDD: HATEOAS links Scenario: submit new order # Given that I have a basket with products When I submit an order order_document file Then a new order is created "Successfully" And I should be prompted to submit a payment And I have the option to review the order And I have the option to cancel the order And I have the option to update the order Path hierarchies Η ιεραρχία εντός ενός path μπορεί να προσδιοριστεί στο Background του resource file σε βήμα Given. Εκεί πρέπει να αναφέρεται επακριβώς το όνομα ενός άλλου resource. Επίσης πρέπει να προσδιορίζεται και μία παράμετρος σύνδεσης (η οποία θα είναι path παράμετρος). Η παράμετρος αυτή πρέπει υποχρεωτικά να επισημαίνεται τουλάχιστον μία φορά ως path παράμετρος στο resource file του resource σύνδεσης (αν δεν επισημαίνεται στο resource file του resource σύνδεσης, τότε το αποτέλεσμα μπορεί να μην είναι το επιθυμητό). Το resource που θα εντοπισθεί στην πρόταση, θα προστεθεί ως μεγαλύτερο path hierarchy, από το resource στου οποίου το resource file περιγράφεται το Background. Μεγαλύτερη ιεραρχία σημαίνει αριστερά του τρέχοντος path. Αν θέλουμε να συμβαίνει το ανάποδο, τότε η ιεραρχία πρέπει να περιγραφεί στο άλλο resource file. Παράδειγμα περιγραφής ιεραρχίας φαίνεται στο Παράδειγμα 4.15. Στο παράδειγμα αυτό, δεδομένου ότι το resource file είναι το payment, το path προκύπτει /order/id/payment

Κεφάλαιο 4. Μεθοδολογία & Υλοποίηση συστήματος 65 Παράδειγμα 4.15: RDD: path hierarchies Background: Given the id of an unpaid order Roles Οι ρόλοι μπορούν να περιγραφούν στο Background του resource file, σε βήμα Given, ή σε βήμα Given ενός σεναρίου. Σε αυτές τις προτάσεις, ως ρόλοι αντιμετωπίζονται τα ουσιαστικά. Στην περίπτωση που οι ρόλοι αναφέρονται στο Background, τότε δεν πρέπει να περιγράφονται ονόματα resources στην πρόταση αναφοράς. Αν περιγράφονται, τότε η πρόταση μπορεί να αντιμετωπισθεί ως πρόταση με ιεραρχία. Ένας ρόλος που περιγράφεται σε Background, αφορά όλα τα σενάρια. Έτσι έχει δικαιώματα σε ό,τι περιγράφει το resource file. Αντίθετα ένας ρόλος που περιγράφεται σε σενάριο έχει δικαιώματα μόνο επί του σεναρίου. Παράδειγμα ρόλου φαίνεται στο Παράδειγμα 4.16. Παράδειγμα 4.16: RDD: roles Scenario: remove product from site Given I am logged in as administrator When I delete a product by it`s name Then I should see the deleted product name "bag" size 5 color "blue" on_sale true collection [1 2 3 4] Παρακάτω παρατίθενται και δύο συνολικά παραδείγματα του RDD. Feature: pay for order Παράδειγμα 4.17: RDD: Ένα resource file # POST /order/{order_id}/payment Background: Given an unpaid order`s id Scenario: pay for order When I submit a payment for an order amount 28.2 date 8/2/2017 12:32 Then I should be prompted to view the order Scenario: pay for order less or more money When I submit a wrong payment for an order Then I should see a message saying "wrong amount" And I should be prompted to submit a payment And I should be prompted to view the order Στο παράδειγμα αυτό περιγράφεται το resource payment ενός υποθετικού ηλεκτρονικού καταστήματος. Στο resource αυτό αποτυπώνεται η επιχειρηματική δραστηριότητα της πληρωμής. Περιγράφονται δύο σενάρια, αυτό της επιτυχούς και αυτό της εσφαλμένης πληρωμής. Στο σενάριο της επιτυχούς πληρωμής, παρατίθεται ένας πίνακας με τις ηλεκτρονικές πληροφορίες που ενδιαφέρουν την πληρωμή. Στον πίνακα αυτό

Κεφάλαιο 4. Μεθοδολογία & Υλοποίηση συστήματος 66 παρατίθενται και ενδεικτικά παραδείγματα. Συγκεκριμένα ότι η πληρωμή είναι ένας δεκαδικός αριθμός και ότι μας ενδιαφέρει η πλήρης ημερομηνία πληρωμής. Επιπλέον παρατηρούμε ότι τα δύο σενάρια περιγράφουν όμοια αιτήματα προς το API. Δηλαδή την αποστολή στοιχείων πληρωμής. Όμως αν και τα αιτήματα είναι σχεδόν ίδια, οι απαντήσεις από το API είναι διαφορετικές. Στην περίπτωση επιτυχούς πληρωμής, προτείνεται η προβολή της παραγγελίας. Αντίθετα στην περίπτωση λανθασμένης πληρωμής, εμφανίζεται σχετικό μήνυμα καθώς και δύο προτροπές: αποστολή νέας πληρωμής ή προβολή παραγγελίας. Οι προτροπές αντιστοιχούν στο Domain Application Protocol του καταστήματος το οποίο για το API σημαίνει hypermedia controls. Αντίστοιχα το λανθασμένο μήνυμα αντιστοιχεί σε αποτυχημένο status code. Στο παράδειγμα 4.18 φαίνεται ένα resource στο οποίο περιγράφονται και τα 4 δυνατά operations προς το API. Δηλαδή τα POST, PUT, GET, DELETE. Feature: order products Παράδειγμα 4.18: RDD: Πλήρες resource file # POST /order # GET, PUT, DELETE /order/{order_id} Scenario: submit new order # Given that I have a basket with products When I submit an order order_document file Then a new order is created "Successfully" And I should be prompted to submit a payment And I have the option to review the order And I have the option to cancel the order And I have the option to update the order Scenario: cancel submitted order # Given I have ordered When I cancel the order Then I should see a success message saying "Order canceled" And I should be prompted to search for more products Scenario: update unpaid order # Given I have ordered # And the order status is "unpaid" When I update the order with products name qt Then I should see a success message saying "Order updated" And I should be prompted to submit a payment And I have the option to review the order And I have the option to cancel the order And I have the option to update the order Scenario: view unpaid order # Given that I have ordered When I request an order by it`s id Then I can view the details of the order name qt And I should be prompted to submit a payment And I have the option to review the order And I have the option to cancel the order And I have the option to update the order

Κεφάλαιο 4. Μεθοδολογία & Υλοποίηση συστήματος 67 Scenario: view paid order # Given that I have ordered When I request an order by it`s id Then I can view the details of the order name qt And I have the option to review the order Scenario: order doesn`t exist # Given an order doesn`t exist When I request, delete or update that order Then I should see a message "That order doesn`t exist" Βλέπουμε ότι στα σενάρια γίνεται να επισημαίνονται παραπάνω από ένα operations (σενάριο order doesn t exist ). Επίσης παρατηρούμε ότι τα Given βήματα των σεναρίων παρατίθενται ως σχόλια. Τα συγκεκριμένα σχόλια δεν περιγράφουν ρόλους και άρα δεν έχουν νόημα για το RDD όπως έχει οριστεί. Προστέθηκαν όμως για να αναδείξουν το γεγονός ότι τα REST APIs είναι stateless. Παρά το γεγονός ότι το επιχειρησιακό πρωτόκολλο προϋποθέτει τα προϊόντα να βρίσκονται σε καλάθι, ο Roy Fielding μας λέει ότι αυτό δεν αφορά το API. Έτσι αν θέλουμε πρώτα να προστίθενται προϊόντα στο καλάθι και μετά να γίνεται η παραγγελία, πρέπει η μετάβαση στο resource order να καθίσταται δυνατή μόνο μέσω το resource basket. Προκειμένου να επιτευχθεί αναγνωσιμότητα, αυτή η προϋπόθεση δύναται να επισημανθεί και με σχόλιο στην περιγραφή του resource order. Τα resource files που συγγράφηκαν για την εκπόνηση της διπλωματικής παρατίθενται στο παράρτημα. Ο παραπάνω τρόπος συγγραφής απαιτήσεων κατά RDD τυποποιήθηκε και σε ένα έγγραφο στα αγγλικά. Το έγγραφο αυτό παρέχεται στους μηχανικούς για να μπορούν να χρησιμοποιήσουν το σύστημα της διπλωματικής. Το έγγραφο παρατίθεται στο παράρτημα D. 4.2.2 Gherkin2OAS Με δεδομένη την παραπάνω σχεδίαση των resource files μπορούμε πλέον να περιγράψουμε το λογισμικό, το οποίο αναλαμβάνει την μετατροπή σε OpenAPI Specification. Το λογισμικό αυτό θα το αποκαλούμε Gherkin2OAS. Το Gherkin2OAS είναι γραμμένο σε γλώσσα python 1 3.5. Προκειμένου να υλοποιηθεί και δεδομένου ότι δεν υπήρχαν έτοιμα gherkin feature files, σχεδιάστηκε με βάση την προηγούμενη ενότητα ένα ενδεικτικό eshop. Το eshop αποτελούταν από 5 resource files, τα product, payment, search, order, basket. Κατά την συγγραφή του Gherkin2OAS, οι δοκιμές γινόταν με βάση αυτά τα resource files. Το Gherkin2OAS αποτελείται από τρεις βασικές λογικές μονάδες: 1. Preprocessor Ο preprocessor αναλαμβάνει την ανάγνωση των Gherkin resource file που έχουν συγγραφεί και την προετοιμασία τους για NLP. Τα αρχεία αυτά πρέπει είναι οργανωμένα σε έναν φάκελο, η θέση του οποίου δίνεται ως είσοδος στον preprocessor. Εντός του preprocessor εμφανίζονται δύο διαδικασίες προ-επεξεργασίας: Στην πρώτη, χρησιμοποιείται ο έτοιμος Gherkin Parser 2. Στην συνέχεια γίνεται μία δεύτερη προ-επεξεργασία η οποία έχει στόχο την αφαίρεση της περιττής πληροφορίας 1 2

Κεφάλαιο 4. Μεθοδολογία & Υλοποίηση συστήματος 68 του Gherkin Parser και την προετοιμασία της πληροφορίας για NLP. Έξοδος του preprocessor είναι το preprocessed model. 2. NLP Engine Το NLP Engine είναι ο πυρήνας του λογισμικού. Είσοδός του είναι το preprocessed model. Στο NLP Engine πραγματοποιείται η εξαγωγή τεχνικών χαρακτηριστικών από το preprocessed model. Για να γίνει αυτό εφικτό αξιοποιείται η μεθοδολογία POS Tagging, τα regular expressions αλλά και λίστες λέξεων και φράσεων. Έξοδος του NLP Engine είναι το technical model. 3. Formatter Ο Formatter δέχεται ως είσοδο το technical model και αναλαμβάνει την μετατροπή του σε OpenAPI Specification. Στο μυαλό του υπάρχουν όλες οι απαραίτητες πληροφορίες για το OpenAPI Specification. Έξοδος του Formatter είναι ένα αρχείο swagger.json ή swagger.yaml, το οποίο περιέχει το OpenAPI Specification Τεχνικές που εφαρμόζονται στο NLP Engine Το περιεχόμενο των resource files είναι έως ένα βαθμό προβλέψιμο. Αυτό οφείλεται στο ότι 1. Τα resource files είναι γραμμένα σε γλώσσα Gherkin. Έτσι καταρχήν οι λέξεις κλειδιά της γλώσσας ορίζουν ένα πλαίσιο ελευθερίας. 2. Τα resource files περιγράφουν ένα RESTful Web API. Συνεπώς η αναμενόμενη ορολογία/φρασεολογία είναι σχετική μόνο με RESTful Web APIs. 3. Ο σχεδιασμός της απεικόνισης των απαιτήσεων RESTful Web APIs σε Gherkin, συμπεριλαμβανομένων των συμβάσεων, είναι τέτοιος ώστε να πληρεί την απαίτηση 7 του Gherkin2OAS (απαιτήσεις συστήματος, ενότητα 3.2.3). 4. Το όνομα του resource file, είναι και το όνομα του resource. Αυτή η σχεδιαστική πρωτοβουλία είναι μείζονος σημασίας, διότι επιλύει το πρόβλημα του εντοπισμού των resources στο κείμενο. Τα χαρακτηριστικά αυτά των resource files καθιστούν το έργο του NLP Engine εφικτό. Στόχος του NLP Engine είναι η κατά το δυνατόν ακριβέστερη εξαγωγή τεχνικών χαρακτηριστικών από το HTTP και η παράθεσή τους σε ένα μοντέλο χαρακτηριστικών. Τέτοια χαρακτηριστικά είναι: Τα HTTP ρήματα Οι όποιες παράμετροι εμφανίζονται στο HTTP αίτημα και στην HTTP απάντηση και τα τεχνικά τους χαρακτηριστικά Το HATEOAS των HTTP απαντήσεων Τα status codes και τα όποια μηνύματα αυτών Η ιεραρχία των resources Οι ρόλοι/χρήστες του API και τα δικαιώματα αυτών Στην συνέχεια περιγράφονται οι συναρτήσεις του NLP Engine. Αποτελεί την κύρια συνάρτηση του υποσυστήματος. Δέχεται ώς είσοδο το προ επεξεργασμένο μοντέλο του preprocessor και επιστρέφει ως έξοδο ένα τεχνικό μοντέλο

Κεφάλαιο 4. Μεθοδολογία & Υλοποίηση συστήματος 69 χαρακτηριστικών. Στην Εικόνα 4.1 φαίνεται η μορφή της εισόδου. Αντίστοιχα στην Εικόνα 4.2 φαίνεται η γενική μορφή της εξόδου του της συνάρτησης. Στην θέση των μεταβλητών resource και operation μπαίνουν τα αντίστοιχα ονόματα των resources και των operations αυτών. Η εξετάζει ένα ένα τα resources και τα σενάρια αυτών. Συγκεκριμένα εντός ενός resource, εξετάζει πρώτα το Background και μετά τα Scenario. Στο Background εντοπίζει ρόλους και ιεραρχία resources με την βοήθεια των συναρτήσεων και. Πρώτα αναζητείται ιεραρχία και αν δεν βρεθεί αναζητούνται ρόλοι. Στην συνέχεια εξετάζονται τα σενάρια. Σε κάθε σενάριο, αναλύεται πρώτα το βήμα Given μετά το When και μετά το Then. Στο βήμα Given αναζητούνται ρόλοι με την βοήθεια της. Στην συνέχεια αναλύεται το βήμα When. Στο βήμα When εντοπίζονται οι παράμετροι κειμένου με την και τα operations με την. Για όλες τις παραμέτρους γίνεται καταγραφή αριθμού εμφανίσεων, όπως επίσης γίνεται και καταγραφή εμφανίσεων HTTP αιτημάτων και HTTP απαντήσεων. Αν το operation του σεναρίου είναι GET, DELETE, PUT, επιχειρείται εντοπισμός path παραμέτρου. Αν το operation του σεναρίου είναι PUT ή POST επιχειρείται εύρεση μοντέλου με την βοήθεια της. Αν το operation του σεναρίου είναι PUT, επιχειρείται ειδικός εντοπισμός και καταγραφή query παραμέτρων. Όλες οι παράμετροι πινάκων εντοπίζονται με την βοήθεια της. Για όλες τις παραμέτρους δίνεται προσοχή να μην καταγράφονται δύο φορές. Έπειτα αναλύεται το βήμα Then. Πρώτα γίνεται προσπάθεια εντοπισμού status code στα βήματα με την βοήθεια της. Αν δεν εντοπισθεί, θεωρείται το default ως status code. Στην συνέχεια εντοπίζονται οι παράμετροι και τα HATEOAS links. Για τις παραμέτρους, τους τύπους αυτών και την εμφάνισή τους ισχύει ό,τι και στην ανάλυση του βήματος When. Τα HATEOAS links εντοπίζονται με την βοήθεια της. Τα HATEOAS links καταγράφονται σε δύο μοντέλα γράφων, το resource_state και το state για μελλοντική απεικόνιση σημαντικών πληροφοριών. Το μοντέλο γράφου resource_state καταγράφει τις μεταβάσεις από πόρο σε πόρο, ενώ το μοντέλο γράφου state καταγράφει τις μεταβάσεις από application state σε application state. Στιγμιότυπα των μοντέλων φαίνονται στις Εικόνες 4.3 και 4.4 αντίστοιχα. Την λειτουργία των γράφων θα την εξετάσουμε παρακάτω και στην Ενότητα 5.3.2. Αν το σενάριο έχει description, αυτό καταγράφεται Αφού έχουν αναλυθεί όλα τα resources, ορίζονται τα requirements τους με την βοήθεια της. Εν τέλει η επιστρέφει το τεχνικό μοντέλο και τα μοντέλα γράφων. Εντοπίζει ονόματα resources σε μία πρόταση, πέραν αυτών που δίνονται ως ορίσματα Η συνάρτηση αυτή εντοπίζει ρόλους χρηστών με την βοήθεια NLP. Συγκεκριμένα την διαδικασία του IE έως το POS Tagging. Τα nouns αντιμετωπίζονται ως ρόλοι. Εμπεριέχει εσωτερικό μηχανισμό διάκρισης από πρόταση που περιγράφει ιεραρχία resources (οπότε και η εξεταζόμενη πρόταση δεν πρέπει να εξεταστεί).

Κεφάλαιο 4. Μεθοδολογία & Υλοποίηση συστήματος 70 Εικόνα 4.1: Gherkin2OAS: Preprocessor model Επιχειρεί να εντοπίσει τύπους status codes και τα μηνύματα αυτών. Πρώτα αναζητά φράση σε εισαγωγικά με την βοήθεια της. Εφόσον βρει, μετατρέπει τα κεφαλαία γράμματα σε μικρά και ελέγχει την ύπαρξη της φράσης σε λίστες λέξεων. Οι λίστες αυτές περιέχουν αντιστοιχίες γνωστών φράσεων με status codes. Τέτοιες λίστες φαίνονται στην εικόνα 4.5. Αν δεν βρεθεί αντιστοίχιση υιοθετείται το default status code, κατά το OpenAPI Specification και τυπώνεται προειδοποιητικό μήνυμα. Εντοπίζει operations σε πρόταση με την βοήθεια της. Στην περίπτωση του βήματος Then, οπότε και έχει κληθεί για την εύρεση βήματος μετάβασης ενός HA- TEOAS link, επιβεβαιώνει πρώτα ότι η πρόταση έχει τουλάχιστον ένα resource. Εντοπίζει παραμέτρους κειμένου με την βοήθεια POS Tagging Εντοπίζει ονόματα μοντέλων με την βοήθεια POS Tagging

Κεφάλαιο 4. Μεθοδολογία & Υλοποίηση συστήματος 71 Εικόνα 4.2: Gherkin2OAS: nlp model Εντοπίζει HTTP ρήματα με την βοήθεια POS Tagging και λιστών λέξεων ρημάτων HTTP, όπως φαίνεται στην Εικόνα 4.6. Καταγράφει και την φυσική λέξη του ρήματος (χρειάζεται στον hateoas γράφο). Επεκτείνει τα ονόματα των resources με τους πληθυντικούς αυτών Η συνάρτηση αυτή αναλύει έναν πίνακα παραμέτρων με την βοήθεια των και. Αρχικά διαπιστώνεται η μορφή του πίνακα. Οι πιθανές μορφές του πίνακα που ενδιαφέρουν εδώ είναι δύο: Πίνακας που έχει τα ονόματα των παραμέτρων στην πρώτη γραμμή και πίνακας που έχει τα ονόματα των παραμέτρων στην πρώτη στήλη. Εφόσον αυτό διαπιστωθεί, καταγράφονται οι τύποι, τα μέγιστα και ελάχιστα και τα παραδείγματα των παραμέτρων, εφόσον αυτά υπάρχουν. Η συνάρτηση περιέχει μηχανισμό ασφαλείας σε περίπτωση που η μορφή του πίνακα δεν προβλέπεται. Αναζητεί τον τύπο ενός κελιού πίνακα, όπως ζητήθηκε από την. Η αναζήτηση βασίζεται στους υποστηριζόμενους τύπους δεδομένων, δηλαδή float, int, bool, array, password, file, date-time, date. Οι τύποι δεδομένων βρίσκονται με την βοήθεια των,,,, και. Η συνάρτηση εντοπίζει επίσης το είδος του collection αν ο τύπος είναι array. Επιπλέον έχει την δυνατότητα ορισμού format. Τέλος αν ο τύπος δεν μπορεί να εντοπισθεί, ορίζεται ως string. Η συνάρτηση εντοπίζει μέγιστα και ελάχιστα στο δοθέν κελί με την βοήθεια της. Συγκεκριμένα, ανάλογα με τον τύπο του κελιού και το πλήθος των εμφανιζόμενων αριθμών, ορίζει και τις ανάλογες ιδίοτητες μεγίστου και ελαχίστου. Στην περίπτωση που έχει προσδιοριστεί μόνο ένα νούμερο, το περιεχόμενο του κελιού αναζητείται για γνωστές εκφράσεις μεγίστου και ελαχίστου με την βοήθεια της. Τέτοιες γνωστές φράσεις φαίνονται στην εικόνα 4.7.

Κεφάλαιο 4. Μεθοδολογία & Υλοποίηση συστήματος 72 Εικόνα 4.3: Gherkin2OAS: Παράδειγμα μοντέλου γράφου resource_state Εντοπίζει νούμερα σε κείμενο με απλό text spliting και την βοήθεια της. Η συνάρτηση αρχικά ορίζει όλες τις παραμέτρους ως μη required. Στην συνέχεια αναζητεί και συγκρίνει το πλήθος εμφάνισης των παραμέτρων με το πλήθος εμφάνισης των operation και των HTTP απαντήσεων. Εφόσον είναι ίδιο, η παράμετρος είναι required. Η αναζήτηση αφορά όλων των ειδών της παραμέτρους (query, body και σε πίνακα ή όχι). Σημειώνεται πως ανεξάρτητα από αυτή την συνάρτηση, μία path παράμετρος είναι πάντα required. Αναζητεί φράση σε κείμενο με regular expressions.

Κεφάλαιο 4. Μεθοδολογία & Υλοποίηση συστήματος 73 Εικόνα 4.4: Gherkin2OAS: Παράδειγμα μοντέλου γράφου state Εντοπίζει αριθμητικούς τύπος δεδομένων με την βοήθεια της έτοιμης συνάρτησης του πακέτου. Εφόσον δεν βρεθούν αναζητεί τύπο bool ή file, αλλιώς επιστρέφει τύπο string. Ελέγχει αν το κείμενο περιγράφει ημερομηνία με την βοήθεια της έτοιμης συνάρτησης του πακέτου. Εντοπίζει κείμενο σε εισαγωγικά με την βοήθεια regular expressions. Εντοπίζει κείμενο εντός αγκυλών ([]) με την βοήθεια regular expressions. Ελέγχει αν πρόκειται για κείμενο εντός εισαγωγικών με την βοήθεια regular expressions.

Κεφάλαιο 4. Μεθοδολογία & Υλοποίηση συστήματος 74 Εικόνα 4.5: Αντιστοιχία γνωστών φράσεων με status codes Εικόνα 4.6: Η αντιστοιχία ρημάτων αγγλικής γλώσσας με HTTP ρήματα/operations [23] [21] Ελέγχει αν το δοσμένο string αποτελεί τύπο δεδομένων με την βοήθεια των,,,. Ελέγχει αν το δοσμένο string αποτελείται μόνο από αστερίσκους (*), οπότε και πρόκειται για κωδικό Τεχνικές που εφαρμόζονται στον Formatter Ο Formatter δέχεται ως είσοδο το μοντέλο τεχνικών χαρακτηριστικών του NLP Engine. Ο Formatter γνωρίζει και αυτός όλες τις συμβάσεις και τις σχεδιαστικές αρχές του συστήματος και τις αξιοποιεί. Αποτελείται από μία βασική συνάρτηση την generate_swagger. Στόχος της συνάρτησης είναι η μετατροπή του τεχνικού μοντέλου σε μοντέλο swagger. Η σειρά των βημάτων εντός της generate_swagger έχει σημασία. Στην συνέχεια περιγράφονται οι συναρτήσεις του Formatter. Η συνάρτηση μετατρέπει το τεχνικό μοντέλο του NLP Engine σε valid OpenAPI Specification. Στην συνάρτηση τα resources εξετάζονται πέντε φορές: 1. Την πρώτη φορά αναζητούνται τα paths, τα queries, τα bodies των HTTP αιτημάτων και τα descriptions των operation. Προκειμένου αυτό να επιτευχθεί, τα operations του resource εξετάζονται έξι φορές. Τις πρώτες δύο ορίζονται οι παράμετροι των path για τα operation GET, PUT, DELETE. Σε αυτό συνεισφέρει και η συνάρτηση. Στην συνέχεια, εφ όσον έχουν εντοπισθεί τα paths, τα operations εξετάζονται άλλες δύο φορές ώστε να οριστούν τα query, με την βοήθεια της. Έπειτα, ορίζονται τα bodies των request και τα μοντέλα αυτών με την

Κεφάλαιο 4. Μεθοδολογία & Υλοποίηση συστήματος 75 Εικόνα 4.7: Λίστες φράσεων μεγίστων και ελαχίστων βοήθεια της. Τέλος ορίζεται το description του σεναρίου, εφ όσον υπάρχει. 2. Πλέον έχουμε τις παραμέτρους των path, οπότε μπορούμε να φτιάξουμε τα τελικά path επιλύοντας τις ιεραρχίες. Έτσι στο δεύτερο πέρασμα και με βάση τις όποιες ιεραρχίες των resources εντοπίστηκαν στο NLP, κατασκευάζουμε τα νέα path, προσέχοντας τις path παραμέτρους που κληρονομούνται από την ιεραρχία. Θεωρητικά υποστηρίζεται άπειρη ιεραρχία, εφόσον πάντα υπάρχει ένα root resource. Στιγμιότυπο του μοντέλου που χρησιμοποιείται για την επίλυση των ιεραρχιών φαίνεται στην Εικόνα 4.8. 3. Στο τρίτο πέρασμα κατασκευάζονται οι HTTP απαντήσεις. Οι παράμετροι και τα HATEOAS links οργανώνονται ανά status code, όπως αυτά εντοπίσθηκαν στο NLP Engine. Για τις παραμέτρους ισχύει ό,τι και για τις body παραμέτρους των HTTP αιτημάτων. Τα HATEOAS links, επειδή στην παρούσα έκδοση του OpenAPI Specification δεν υποστηρίζονται με φυσικό τρόπο, προστίθενται ως vendor extension με πρόθεμα x- 4. Την τέταρτη φορά εντοπίζονται ορίζονται οι ρόλοι και τα δικαιώματα αυτών με βάση το oauth2. 5. Τέλος, αφαιρούνται από την τυποποίηση άδεια μοντέλα και ενημερώνονται όλα τα paths στο specification με τις ιεραρχίες τους (άρα και τα hateoas links). Στο τέλος της παραπάνω διαδικασίας έχει ολοκληρωθεί το paths_object του OpenAPI Specification. Επιπλέον όλες οι παράμετροι των HTTP αιτημάτων και των HTTP απαντήσεων οργανώνονται αυτόματα σε μοντέλα (HTTP μοντέλα), τα οποία με τη σειρά τους προστίθενται στο definitions_object του OpenAPI Specification. Τα μοντέλα των HTTP απαντήσεων είναι διαφορετικά για κάθε status code. Έτσι ενώ υπάρχει ένα μοντέλο για κάθε HTTP αίτημα, δεν συμβαίνει το ίδιο και για μία HTTP απάντηση. Περαιτέρω, αν έχουν ορισθεί μοντέλα κατά την διαδικασία συγγραφής της Gherkin, αυτά επίσης προστίθενται στο definitions_object και καθίστανται προσβάσιμα από τα HTTP μοντέλα με σύνδεση ref όπως ορίζει το OpenAPI Specification. Η ίδια σύνδεση χρησιμοποιείται για την παραπομπή των HTTP μοντέλων από το paths_object. Τέλος οι ρόλοι και τα δικαιώματα αυτών ορίζονται στο security_definitions_object. Μετατρέπει πίνακες πινάκων (list σε python) σε μονοδιάστατους πίνακες. Ορίζει τις ιδιότητες μίας path παραμέτρου Ορίζει τις ιδιότητες μίας query παραμέτρου

Κεφάλαιο 4. Μεθοδολογία & Υλοποίηση συστήματος 76 Εικόνα 4.8: Gherkin2OAS: Εσωτερικό μοντέλο που χρησιμοποιείται στον formatter για επίλυση ιεραρχιών Ορίζει τις ιδιότητες μίας schema παραμέτρου Αναλυτικά παραδείγμα των object του OpenAPI Specification, φαίνονται στο Κεφάλαιο 5 και στο Παράρτημα. 4.2.3 Γράφοι καταστάσεων Το σύστημα πλαισιώνει γραφικά ένας σχεδιαστής γράφων. Ο τελευταίος δέχεται ως είσοδο τα μοντέλα γράφων του NLP Engine και τα αναπαριστά με γράφους σε αρχεία pdf. Υπάρχουν τρεις τύποι γράφων Ο γράφος μετάβασης καταστάσεων σε επίπεδο πόρων

Κεφάλαιο 4. Μεθοδολογία & Υλοποίηση συστήματος 77 Ο γράφος μεταβάσης καταστάσεων σε επίπεδο εφαρμογής (application state), σε user friendly μορφή Ο γράφος μεταβάσης καταστάσεων σε επίπεδο εφαρμογής, σε τεχνική μορφή Ο πρώτος γράφος φαίνεται στην Εικόνα 4.9. Κάθε κορυφή του γράφου αντιστοιχεί σε ένα resource, ενώ οι ακμές αντιστοιχούν σε δυνατές μεταβάσεις με http αιτήματα από έναν πόρο σε έναν άλλον. Εικόνα 4.9: Γράφος μετάβασης καταστάσεων σε επίπεδο πόρων Οι δύο άλλοι γράφοι φαίνονται στις Εικόνες 4.10 και 4.11. Οι γράφοι μετάβασης κατάστασης εφαρμογής έχουν ώς κορυφές καταστάσεις εφαρμογής και ως ακμές http αιτήματα. Στις κορυφές εμφανίζεται το όνομα του πόρου, το όνομα του σεναρίου και το status code. Παρατηρούμε ότι σε αυτούς τους γράφους κάποιες ακμές είναι χρωματισμένες με κόκκινο. Οι κόκκινες ακμές μας δείχνουν ότι το Gherkin2OAS εντόπισε αμφιλεγόμενες μεταβάσεις. Δηλαδή δύο ίδιες μεταβάσεις (ίδιο http αίτημα) με κοινή προέλευση προς δύο διαφορετικές καταστάσεις με ίδιο status code. Αν πάρουμε την αυστηρή θεώρηση ότι το interface του συστήματος είναι μόνο το HTTP, το σύστημα θα είναι REST όταν σε κάθε status code αντιστοιχεί ένα και μόνο ένα application state. Διότι αν αντιστοιχούσαν δύο ή παραπάνω application state σε ένα status code, τότε πως θα επέλεγε ο client ανάμεσα σε

Κεφάλαιο 4. Μεθοδολογία & Υλοποίηση συστήματος 78 δύο; Ο Roy Fielding μας λέει ότι το application state διαφημίζεται μόνο μέσω των hypermedia. Αν λοιπόν έχουμε ένα http αίτημα, άρα ένα hypermedia, τότε αυτό δεν μπορεί να διακριθεί από ένα άλλο χωρίς επιπλέον πληροφορίες. Θα μπορούσαμε να παραθέσουμε επιπλέον πληροφορίες, δίπλα στο hypermedia, αλλά τότε θα δημιουργούσαμε ένα υπό πρωτόκολλο μέσα στο HTTP. Έτσι θα παραβιάζαμε τον περιορισμό Uniform Interface του REST. Αν πάρουμε μία λιγότερο αυστηρή, αλλά και την επικρατέστερη σήμερα θεώρηση, ότι δηλαδή στην απόφαση μετάβασης συνεισφέρει και το body του HTTP αιτήματος, τότε το σύστημα είναι γενικώς REST. Σε αυτή την περίπτωση οι κόκκινες ακμές επισημαίνουν στο μηχανικό του εξυπηρετητή (server) ότι πρέπει με βάση κάποιες, μη ξεκάθαρες για το API, πληροφορίες, να στέλνεται στον πελάτη η κατάλληλη αναπαράσταση πόρου (ανάμεσα στις δύο). Επίσης επισημαίνουν στον μηχανικό του συνολικού συστήματος ότι πρέπει να εξηγήσει με περιγραφές του API (άρα με descriptions στα Gherkin σενάρια) πώς θα αντιμετωπίζει ο πελάτης (client) τις φαινομενικά όμοιες καταστάσεις. Αν κρίνει ότι η επεξήγηση είναι αρκετά περίπλοκη, τότε ενδεχομένως πρέπει να αλλάξει τον σχεδιασμό του συστήματος προσθέτοντας νέους πόρους (Ενότητα 5.3.2). Με βάση τους γράφους, ο έλεγχος του συστήματος ως προς το πόσο REST είναι έχει ως εξής: 1. Μελέτη γράφου μετάβασης καταστάσεων σε επίπεδο πόρων. Προκειμένου το σύστημα να είναι REST, αναγκαία συνθήκη είναι να συνδέεται κάθε ζευγάρι κορυφών με ένα κατευθυνόμενο μονοπάτι. Αν αυτό δεν ισχύει, το σύστημα δεν είναι REST. 2. Μελέτη του γράφου μεταβάσης καταστάσεων σε επίπεδο εφαρμογής. Αν εμφανίζονται κόκκινες ακμές, το σύστημα μπορεί να μην είναι REST. Στην Ενότητα 5.3.2 θα δούμε πώς επιλύεται αυτό το πρόβλημα. 3. Μελέτη του γράφου μεταβάσης καταστάσεων σε επίπεδο εφαρμογής. Αν όλες οι ακμές είναι χρωματισμένες μαύρες, το σύστημα είναι πιθανόν REST. Για να είναι REST πρέπει και εδώ να υπάρχει ένα κατευθυνόμενο μονοπάτι από κάθε κατάσταση εφαρμογής σε κάθε άλλη. Αν αυτό ισχύει, τότε το σύστημα είναι REST. Η παραπάνω διαδικασία μπορεί να εκτελείται όσες φορές θέλουμε, για όσα νέα resources βάζουμε στο σύστημά μας. 4.2.4 Gherkin2OAS Data Flows Το Gherkin2OAS έχει δύο διαφορετικά data flow. Το βασικό φαίνεται στην Εικόνα 4.12. Πρόκειται για την κανονική λειτουργία, οπότε και δέχεται ως είσοδο ένα σύνολο από resource files. Εναλλακτικά, υπάρχει και η δυνατότητα εκτέλεσης με την χρήση ενός προηγούμενου τεχνικού μοντέλου, εξαγόμενου από το NLP Engine. Το data flow της εναλλακτικής λειτουργίας φαίνεται στην Εικόνα 4.13. 4.2.5 Gherkin2OAS Production Environment Στην ενότητα αυτή θα παρουσιάσουμε την διαδικασία ανάπτυξης RESTful Web APIs με την Gherkin, το Gherkin2OAS και το OpenApi Specification. Επισημαίνουμε ότι η μόνη προϋπόθεση εκτέλεσης του Gherkin2OAS είναι η ύπαρξη python έκδοσης 3+ στο λειτουργικό. Το Gherkin2OAS μπορεί να εκτελεστεί σε οποιοδήποτε από τα τρία γνωστά λειτουργικά (Windows, Linux, MAC OS X). Η διαδικασία ξεκινάει με την καταγραφή των απαιτήσεων του API σε Gherkin γλώσσα με βάση το Gherkin Specifications Document. Μπορούν να γραφούν όσα resources επιθυμεί

Κεφάλαιο 4. Μεθοδολογία & Υλοποίηση συστήματος 79 Εικόνα 4.10: Ο γράφος μεταβάσης καταστάσεων σε επίπεδο εφαρμογής, σε user friendly μορφή ο μηχανικός. Στο τέλος της διαδικασίας, υπάρχει ένας φάκελος στο λειτουργικό που περιέχει τα resources (εικόνα 4.15). Στην συνέχεια ο μηχανικός πρέπει να εκτελέσει το Gherkin2OAS. H εκτέλεση ξεκινάει από το τερματικό. Σημειώνεται ότι έχει σχεδιαστεί και μία αρχική γραφική διεπαφή, αλλά η ανάπτυξή της σταμάτησε διότι δεν είχε ξεκάθαρο ρόλο. Το μοναδικό παράθυρο της διεπαφής φαίνεται στην Εικόνα 4.14. Έτσι πρώτα πρέπει να εκκινηθεί ένα τερματικό. Έπειτα, μέσω του τερματικού πρέπει να γίνει πλοήγηση στον φάκελο που υπάρχει το Gherkin2OAS. Στην συνέχεια, δίνεται η αντίστοιχη εντολή εκκίνησης, όπως φαίνεται παρακάτω: Παράδειγμα 4.19: Εκκίνηση Gherkin2OAS - τερματικό python main.py f <resource folder path> m <model path> fg Οι επιλογες -f και -m είναι προαιρετικές αλλά μόνο μία μπορεί να χρησιμοποιηθεί. Η επιλογή -fg σημαίνει fix graph και δεν παίρνει είσοδο αλλά είναι boolean. Η επιλογή -f αφορά τον φάκελο με τα resource files. Η επιλογή -m αφορά ένα αρχείο μοντέλου. Όταν το Gherkin2OAS εκτελείται, παράγει ένα αρχείο nlp_model.json. Το αρχείο αυτό, περιέχει το τεχνικό μοντέλο που προκύπτει από την εφαρμογή μηχανισμών NLP στα resource files. Επειδή η εφαρμογή των μηχανισμών αυτών (δηλαδή το NLP Engine) καθυστερεί, δίνεται η δυνατότητα να φορτώνονται έτοιμα μοντέλα από προηγούμενες εκτελέσεις, τα οποία είναι αποθηκευμένα σε αρχεία τύπου json και έχουν παραχθεί από το Gherkin2OAS. Ένα τέτοιο αρχείο μπορεί να φορτωθεί μέσω της επιλογής -m. Όταν ενεργοποιείται η επιλογή -fg, ο χρήστης θα παροτρυνθεί να διορθώσει αμφιλεγόμενες

Κεφάλαιο 4. Μεθοδολογία & Υλοποίηση συστήματος 80 Εικόνα 4.11: Ο γράφος μεταβάσης καταστάσεων σε επίπεδο εφαρμογής, σε τεχνική μορφή μεταβάσεις καταστάσεων στους γράφους, χειροκίνητα. Τέλος πρέπει να συμπληρωθεί και το αρχείο spec_config.ini. Το αρχείο αυτό περιέχει τις γενικές πληροφορίες για το API. Από το αρχείο απαραίτητα πρέπει να συμπληρωθούν οι μεταβλητές title, version, basepath και host. Επισημαίνεται ότι το basepath ξεκινάει πάντα με /. Παράδειγμα του spec_config.ini φαίνεται στην Εικόνα 4.16. Με το πέρας της εκτέλεσης δημιουργούνται 6 αρχεία στον φάκελο output_files. Τα swagger.json, swagger.yaml, nlp_model.json, resource_state_graph.gv.pdf, state_graph.gv.pdf και http_state_graph.gv.pdf (Εικόνα 4.17). Τα swagger.json και swagger.yaml περιέχουν το OpenAPI Specification σε json και yaml μορφή αντίστοιχα. Το nlp_model.json περιέχει το μοντέλο τεχνικών χαρακτηριστικών του NLP Engine. Τα pdf αρχεία απεικονίζουν τους γράφους καταστάσεων. Οι γράφοι μπορούν να αξιοποιηθούν από τους μηχανικούς για περαιτέρω συζήτηση με τον πελάτη αλλά και για βελτίωση του συστήματος. Μέσω αυτών μπορεί να επιβεβαιωθεί με οπτικό τρόπο, αν είναι σωστό το επιχειρησιακό πρωτόκολλο, όπως και αν το σύστημα είναι RESTful. Εφόσον έχει επιβεβαιωθεί το validity του swagger αρχείου από το Gherkin2OAS, στην

Κεφάλαιο 4. Μεθοδολογία & Υλοποίηση συστήματος 81 Εικόνα 4.12: Gherkin2OAS: Data Flow συνέχεια μπορεί να παραχθεί ο κώδικας του συστήματος και της εφαρμογής αλλά και το documentation. Ο κλασσικός τρόπος για να γίνει αυτό είναι με το Swagger Code Generator 1. Αφού γραφεί τουλάχιστον ο κώδικας του συστήματος, το API μπορεί να δοκιμαστεί. Οι δοκιμές μπορούν να γίνουν είτε από εργαλεία του swagger, όπως ο editor ή το Swagger UI, είτε από πληθώρα άλλων γνωστών εργαλείων στην αγορά. Επισημαίνουμε εδώ ότι δοκιμές μπορούν να γίνουν μέχρι και για ένα μόνο resource file. Εξ άλλου με βάση το BDD και το Agile manifesto γενικότερα, δεν προτείνεται η ανάπτυξη ολόκληρου του συστήματος εξ αρχής. Στόχος είναι να γράφονται μόνο τα απαραίτητα resource files, να παράγεται μόνο ο απαραίτητος κώδικας και να εκτελούνται μόνο τα απαραίτητα test. Αφού ολοκληρωθεί η διαδικασία των δοκιμών, μπορούν να γίνουν νέες συζητήσεις με τους πελάτες με βάση τα αποτελέσματα. Επίσης, αν έχει γραφεί μέρος της εφαρμογής, μπορεί να επιδειχθεί και η λειτουργία του συστήματος. 1

Κεφάλαιο 4. Μεθοδολογία & Υλοποίηση συστήματος 82 Εικόνα 4.13: Gherkin2OAS: Alternative Data Flow Εικόνα 4.14: Gherkin2OAS: GUI Εικόνα 4.15: Φάκελος με αρχεία resource

Κεφάλαιο 4. Μεθοδολογία & Υλοποίηση συστήματος 83 Εικόνα 4.16: Παράδειγμα αρχείου spec_config.ini Εικόνα 4.17: Αρχεία εξόδου εκτέλεσης Gherkin2OAS

Κεφάλαιο 4. Μεθοδολογία & Υλοποίηση συστήματος 84 Εικόνα 4.18: Εποπτεία του API με τον swagger editor - Editor

Κεφάλαιο 4. Μεθοδολογία & Υλοποίηση συστήματος 85 Εικόνα 4.19: Εποπτεία του API με τον swagger editor - API UI

Κεφάλαιο 4. Μεθοδολογία & Υλοποίηση συστήματος 86 Εικόνα 4.20: Δοκιμή του API με τον swagger editor

87 Κεφάλαιο 5 Πειράματα & Αποτελέσματα Στο κεφάλαιο αυτό παρουσιάζουμε παραδείγματα χρήσης του RDD, και τα Open API Specification που εξήχθησαν από αυτά. Πριν όμως δούμε τα παραδείγματα, κρίνεται σκόπιμο να σχολιαστεί η δυνατότητα αξιολόγησης του συστήματος. 5.1 Ο μηχανισμός διασφάλισης της αξιοπιστίας του συστήματος Διακρίνονται οι εξής μετρικές αξιολόγησης του συστήματος: Διασφάλιση της επιτυχούς εκτέλεσης του κώδικα, λόγω επεξεργασίας φυσικής γλώσσας Διασφάλιση της εξαγωγής valid OpenAPI Specification, λόγω επεξεργασίας φυσικής γλώσσας Ευχρηστία του RDD Εκπλήρωση απαιτήσεων συστήματος (ενότητα 3.2.3) Η τήρηση των κανόνων του RDD διασφαλίζει πάντα την επιτυχή εκτέλεση του κώδικα και την εξαγωγή valid OpenAPI Specification. Αυτό θα διαπιστωθεί παρακάτω, όπου θα εξεταστούν με παραδείγματα όλα χαρακτηριστικά του συστήματος. Η μη τήρηση των κανόνων του RDD θα οδηγεί πάντα σε invalid OpenAPI Specification. Επιπρόσθετα, το σύστημα δεν μπορεί να διασφαλίσει την επιτυχή εκτέλεση του κώδικα, στην περίπτωση που στο ελεύθερο κείμενο εισάγονται εσκεμμένα τυχαίοι χαρακτήρες, λέξεις και προτάσεις. Η αντιμετώπιση τέτοιων περιπτώσεων θα αναιρούσε το κέρδος της μειωμένης πολυπλκότητας του κώδικα, λόγω RDD. Σε κάθε περίπτωση τέτοιες περιπτώσεις δεν θα έπρεπε να ενδιαφέρουν, δεδομένου ότι το σύστημα σχεδιάστηκε για παραγωγή λογισμικού. Επομένως μη εκτέλεση του κώδικα, δεν θα σήμαινε παραδείγματος χάρη απώλεια προσωπικών δεδομένων, παραβίαση συστήματος κ.λ.π.. Εάν ο κώδικας δεν εκτελεστεί, σημαίνει ότι σίγουρα δεν ακολουθούνται οι κανόνες του RDD. Άρα το πρόβλημα διορθώνεται γρήγορα με συμμόρφωση στους κανόνες. Το ίδιο ισχύει και για το validity του OpenAPI Specification. Η πλήρης αναξιοπιστία του συστήματος όταν δεν ακολουθείται πιστά η μεθοδολογία RDD, είναι σκόπιμη. Όπως ένας compiler γλώσσας προγραμματισμού δεν εξασφαλίζει ποτέ το επιτυχές compilation στην περίπτωση μη τήρησης του συντακτικού, έτσι και το Gherkin2OAS δεν μπορεί να διασφαλίσει την επιτυχή εξαγωγή OpenAPI Specification σε περίπτωση μη τήρησης του RDD. Επιπρόσθετα, ο compiler προσπαθεί να συμβάλλει στην συγγραφή σωστού κώδικα με μηνύματα επισήμανσης λαθών. Το Gherkin2OAS περιέχει μερικά τέτοια μηνύματα, όπου κατέστη εφικτό. Παραδείγματος χάρη τα μηνύματα Warning found duplicate path parameters:...

Κεφάλαιο 5. Πειράματα & Αποτελέσματα 88 Warning, could not find a status code in the phrase... Incorrect table format A unique post operation inside a resource file must ALWAYS specify at least one body parameter Warning, parameter was detected as linking between the resources but was not found in any detected paths. Was it mentioned in any scenario? No operation name operation found in resource file resource file name but such a hateoas link was described in resource file resource file name File type in response is bugged, see https://github.com/oai/openapi- Specification/issues/260 αποτελούν τέτοιου είδους μηνύματα. Έτσι στην πραγματικότητα ο μηχανικός προγραμματίζει το OpenAPI Specification. Άρα ο μηχανισμός διασφάλισης αξιοπιστίας του συστήματος είναι το Gherkin συντακτικό που ορίζει το RDD. Με βάση αυτή την συλλογιστική, η μετρική αξιολόγησης του συστήματος με μεγαλύτερη βαρύτητα, είναι αυτή της ευχρηστίας. Η ευχρηστία του συστήματος μπορεί να διαπιστωθεί με δύο μεθόδους: 1. Με την δοκιμή του συστήματος σε πραγματικό περιβάλλον παραγωγής λογισμικού 2. Με τον έλεγχο συμμόρφωσης σε γνωστές πρακτικές, οι οποίες έχουν αποδώσει αποτελέσματα Η πρώτη μεθοδολογία δεν κατέστη εφικτή στα πλαίσια της διπλωματικής. Αντίθετα, η δεύτερη μεθοδολογία συνδέεται άμεσα με τις απαιτήσεις του συστήματος. Η εκπλήρωση των απαιτήσεων του συστήματος (Ενότητα 3.2.3) κρίνεται επιτυχής ως εξής: Το σύστημα είναι REST-aware. Το Κεφάλαιο 4 επιβεβαιώνει αυτόν τον ισχυρισμό. Το σύστημα είναι Agile-friendly, διότι οι απαιτήσεις περιγράφονται με μορφή User Story. Επίσης δεν απαιτείται η περιγραφή όλων των resources εξ αρχής. Το σύστημα είναι OAS-aware, διότι υποστηρίζεται το path object, όλα τα είδη definition, όλοι οι μη τεχνικοί (όπως byte) τύποι δεδομένων, όλα τα είδη παραμέτρων, όλες οι θέσεις παραμέτρων (εκτός του header που αφορά τεχνική περιγραφή), ο μηχανισμός παραπομπής μοντέλων ( $ref ), required παράμετροι και στο path object και στα μοντέλα, διαφορετικά status code στις HTTP απαντήσεις και τέλος οι πληροφορίες του API με το αρχείο spec_config.ini. Η εκτέλεση γίνεται σε λογικά γρήγορο χρόνο (βλ. 5.2). Οι απαιτήσεις που καταγράφονται σε Gherkin είναι μόνο τύπου λειτουργικες Το σύστημα λαμβάνει υπ όψιν ότι ο χρήστης του API είναι και ο μηχανικός λογισμικού, με το να είναι REST-aware και OAS-aware (σχόλιο: η υποστήριξη path hierarchies επίσης συνεισφέρει στην εκπλήρωση αυτής της απαίτησης, μιας και καθιστά τα path ενστικτώδη (intuitive)) Η ανάπτυξη του συστήματος κατέστη εφικτή χάρη στην κατανόηση του REST, των δυνατοτήτων του NLP, των χαρακτηριστικών του OAS και τον σχεδιασμό της μεθοδολογίας RDD. Με βάση τα παραπάνω, το σύστημα ακολουθεί γνωστές πρακτικές.

Κεφάλαιο 5. Πειράματα & Αποτελέσματα 89 Αναφέρουμε τέλος ότι το OpenAPI Specification που δημιουργείται από το Gherkin2OAS, ελέγχεται ως valid με τον 1. Αν είναι valid, τυπώνεται σχετικό μήνυμα. 5.2 Ταχύτητα εκτέλεσης και POS Tagging Η ταχύτητα εκτέλεσης του Gherkin2OAS εξαρτάται μόνο από την ταχύτητα του POS Tagging. Όλες οι άλλες διαδικασίες είναι αμελητέου χρόνου. Ο χρόνος του POS Tagging εξαρτάται κατ αρχήν από το πόσες φορές καλείται ως διαδικασία. Εξαρτάται όμως και από τον tagger. Έτσι αν πάρουμε ώς δεδομένο τον αριθμό κλήσεων, βελτίωση θα αποτελούσε η επιλογή γρήγορου tagger. Ταυτόχρονα όμως, πρόβλημα αποτελεί το accuracy του tagger. Στην δική μας περίπτωση μας ενδιαφέρει μόνο ο εντοπισμός ουσιαστικών και ρημάτων. Δεδομένου ότι οι προτάσεις των σεναρίων της Gherkin είναι μικρές (έως συνθηματικές), θα ανέμενε κανείς ο οποιοσδήποτε tagger θα είχε 100% accuracy ως προς τον εντοπισμό τους. Στην πραγματικότητα όμως ενώ ο tagger του nltk είναι εξαιρετικά γρήγορος, δεν καταφέρνει πάντα να εντοπίσει τα ρήματα και τα ουσιαστικά. Αντίθετα άλλοι tagger, όπως ο Stanford tagger ή ο Senna Tagger, καταφέρνουν να τα εντοπίσουν, αλλά σε μεγαλύτερο χρόνο. Προφανώς επιλέγεται η χρήση πάντα αξιόπιστων tagger έναντι αναξιόπιστων γρήγορων. Δεδομένου ότι τα σενάρια είναι παρόμοιας μορφής και μεγέθους, μπορούν να αξιοποιηθούν για την μέτρηση μέσου χρόνου εκτέλεσης. Αυτός είναι ο μόνος τρόπος να μελετήσουμε τις επιδόσεις του συστήματος αφού δεν υπάρχουν μεγάλα dataset γραμμένα με RDD. Ύστερα από εκτελέσεις στα σενάρια των παρακάτω παραδειγμάτων, προέκυψε ότι ο μέσος χρόνος επεξεργασίας σεναρίου είναι 1.4 δευτερόλεπτα με τον Stanford ή τον Senna Tagger. Σε προσπάθεια αυτός ο χρόνος να βελτιωθεί, βρέθηκε ο εξής POS Tagger:. Ο tagger χρησιμοποιεί Averaged Perceptron 2 για τον εντοπισμό των tags. Ο tagger αυτός είχε 0.9 δευτερόλεπτα μέσο χρόνο επεξεργασίας σεναρίου. Δεδομένου ότι και αυτός εντοπίζει με 100% accuracy τα ρήματα και τα ουσιαστικά σε μικρές προτάσεις, επιλέχθηκε έναντι των άλλων δύο. 1 2

Κεφάλαιο 5. Πειράματα & Αποτελέσματα 90 5.3 Αναλυτικά Παραδείγματα, Πειράματα και αποτελέσματα Στην ενότητα αυτή θα εξετάσουμε αναλυτικά και βήμα βήμα την συγγραφή 2 web εφαρμογών, με το σύστημα που σχεδιάστηκε. Τα τελικά valid OpenAPI Specifications των web εφαρμογών, βρίσκονται στο παράρτημα. Για λόγους αναγνωσιμότητας, επιλέγουμε για την παρουσίαση των παραδειγμάτων την γραφική αναπαράσταση του API από τον swagger editor, έναντι του specification. 5.3.1 Mytop10 API Η πρώτη web εφαρμογή έχει σχεδιαστεί ως πλαίσιο εργασίας από μεταπτυχιακούς φοιτητές. Η περιγραφή της εφαρμογής βρίσκεται στην διεύθυνση. Πρόκειται για μια εφαρμογή με κοινωνικό χαρακτήρα όπου οι χρήστες μπορούν να δημοσιεύουν λίστες με τις 10 αγαπημένες τους ταινίες, σειρές και τραγούδια, είτε συγκεκριμένης κατηγορίας είτε γενικά. Σκοπός της εφαρμογής είναι να καθιερωθεί ως ένας τρόπος έκφρασης του χρήστη και ανταλλαγής κριτικών απόψεων. Πρόκειται για μια προσβάσιμη εφαρμογή SaaS όπου θελουμε να ξεχωρίζει για το user friendly χαρακτήρα της. Στο repository αυτό υπάρχει αρχείο περιγραφής του API της εφαρμογής ( ). Με βάση αυτή την περιγραφή γράφτηκαν τα αντίστοιχα, και κατά RDD, αρχεία. Επισημαίνεται ότι το API δεν είναι REST, διότι δεν χρησιμοποιεί HATEOAS. Καθώς μελετούμε το API, αντιμετωπίζουμε την περιγραφόμενη του λειτουργία ως αποτέλεσμα επικοινωνίας με έναν πελάτη. Έτσι αφού το API μελετήθηκε, αποφασίστηκε να δημιουργηθεί αρχικά το resource user. Στην συνέχεια, με βάση την περιγραφή των δημιουργών του API αλλά και προσθήκες, γράφτηκαν τα σενάρια του resource user ως εξής: Feature: user Παράδειγμα 5.1: Mytop10 user resource Scenario: Create user Creates a single user Given that I am authorized as admin When I create a user: email `anasdima@ece.auth.gr` username `Tasos` password ******** id 250 date of birth 04/05/1992 sex `male` location `Thessaloniki ` photo `http://photo.com/myphoto ` status `online` trophy `name` Then I should see a message "Successfull new account" Scenario: Attempt to create user while not being authorized # Given that I am not authorized to create users

Κεφάλαιο 5. Πειράματα & Αποτελέσματα 91 When I attempt to create, view, delete or update the user Then I should see a message "You are unauthorized to make this request." Scenario: View user`s details Shows details of single user When I request a user by his id Then I should see his username username `Tasos` Scenario: User does not exist # Given that the user does not exist When I request, update or delete a user by his id Then I should see "User doesn`t exist" Scenario: Delete user Deletes a single user When I delete a user by his id Then I should see "User deleted successfully" Scenario: Update user profile Update your user profile When I update a user by his id And I specify the following information username `Nick` password ******* min length of 8 date of birth 09 08 1002 sex `Male` location `Sweden` photo `http://imgur.com/rand_photo ` Then I should see the message "Successfully updated" Scenario: Check user`s status Returns status about a single user. Valid status requests are `online`, `offline `, `away` and `busy `. The response will be "is <user`s status >" When I request a user by his id And I also request his status status `online ` Then I should see username "Michalis Pap" status "is online" Scenario: Award trophy Give trophy to particular user. When I update a user by it's id And I award a trophy `trophytype ` Then I should see the message "Successfully awarded" Στην συνέχεια εκτελούμε το Gherkin2OAS. Το εξαγόμενο specification είναι valid. Στην Εικόνα 5.1 βλέπουμε τα paths που δημιουργήθηκαν. Το σύστημα σωστά εντόπισε ότι οι user έχουν path παράμετρο id. Επίσης εντόπισε ότι τα GET, PUT, DELETE αναφέρονται σε single resource ενώ το POST σε collection. Συνεχίζοντας, στην Εικόνα 5.2

Κεφάλαιο 5. Πειράματα & Αποτελέσματα 92 Εικόνα 5.1: Mytop10: User resource - paths Βλέπουμε ότι το Gherkin2OAS, εντόπισε σωστά τέσσερα μοντέλα. Επί αυτών σχολιάζουμε ότι: Εντοπίστηκε το μοντέλο user, όπως θέλαμε (και σηματοδοτήσαμε) στο σενάριο Create User Εντοπίστηκαν όλοι οι τύποι δεδομένων σωστά, τα αντίστοιχα format τους και τα όριά τους. Έτσι βλέπουμε πληροφορίες όπως int32, date, password και minlength. Καταγράφηκε σωστά η σύνδεση μεταξύ του μοντέλου user_post_request_body και του user Ως προς το OAuth2 security, βλέπουμε στην Εικόνα 5.3 ότι βρέθηκε ο ρόλος admin στο σενάριο Create User. Στην Εικόνα 5.4 βλέπουμε το operation GET /user/user_id. Το Gherkin2OAS έχει βρει ότι το operation παίρνει δύο παραμέτρους. Έχει σωστά διαπιστώσει ότι το status parameter έχει θέση query. Επίσης ότι είναι προαιρετικό (δεν εμφανίζεται σε όλα τα σενάρια που περιγράφουν το ίδιο operation). Περαιτέρω, εντοπίστηκαν σωστά τρία responses και τα μηνύματα αυτών. Η default σωστά δεν έχει μήνυμα. Παρατηρούμε ακόμη ότι το username στο μοντέλο της default HTTP απάντησης, έχει δίπλα του ένα αστεράκι (*). Δηλαδή ότι βρέθηκε ως required. Αυτό συνέβη διότι εμφανίζεται σε όλα τις default HTTP απαντήσεις των σεναρίων που περιγράφουν GET. Τέλος βλέπουμε ότι καταγράφηκαν όλα τα description που περιγράφουν το ίδιο operation. Στην Εικόνα 5.5 βλέπουμε το PUT operation. Εδώ το σημείο σχολιασμού είναι ότι οι request παράμετροι, παρ όλο που βρίσκονται σε διαφορετικά σενάρια, οργανώθηκαν σε ένα model. Αυτό συμβαίνει διότι το OpenAPI Specification δεν διακρίνει δύο operation μεταξύ τους, όταν αφορούν το ίδιο path. Ταυτόχρονα δεν προσδιορίστηκαν ονόματα μοντέλων γι αυτές, ώστε να διακριθούν σε επίπεδο μοντέλου. Αν όμως εξετάσουμε τον κώδικα του OpenAPI Specification στην Εικόνα 5.6, βλέπουμε ότι καταγράφηκαν δύο διακριτά παραδείγματα, όπως τα περιγράψαμε στα σενάρια. Έτσι ο developer του API μπορεί να αξιοποιήσει και αυτό το χαρακτηριστικό του Gherkin2OAS ώστε να διαπιστώσει διαφορετικά είδη αιτημάτων. Το έργο του μπορεί να βοηθηθεί περαιτέρω με τα διαφορετικά description του operation. Στην προκειμένη περίπτωση αυτά έχουν δοθεί στα σενάρια και καταγράφηκαν.

Κεφάλαιο 5. Πειράματα & Αποτελέσματα 93 Εικόνα 5.2: Mytop10: User resource - models Στις Εικόνες 5.7 και 5.8 βλέπουμε τις περιγραφές των POST και PUT operation. Στο POST παρατηρούμε την καταγραφή του security. Επίσης ότι το model δεν είναι required (σωστό αφού δεν εμφανίζεται σε όλα τα σενάρια που περιγράφουν POST) Στην συνέχεια αποφασίζουμε να δημιουργήσουμε το resource list. feature file του: Έτσι γράφουμε το Feature: lists Παράδειγμα 5.2: Mytop10 list resource Background: Lists belong to users Given a user`s id Scenario: Create new list Create a new single list for a user. When I create a list id 30 category `series` listname `top 10 series` description `Best series since 1990` date of release 05/06/2010

Κεφάλαιο 5. Πειράματα & Αποτελέσματα 94 Εικόνα 5.3: Mytop10: User resource - security Εικόνα 5.4: Mytop10: User resource - GET user tag `mystery ` Then I could see "List created" Scenario: Unsuccessfull list creation # Given WW3 When I create a list id 30 category `series` listname `top 10 series` description `Best series since 1990` date of release 05/06/2010 tag `mystery ` Then I could see "List not created" Scenario: Retrieve list Returns a single list of a particular user. When I check a list by it`s id Then I should see it`s name Scenario: non existing list # Given a list does not exist When I try to view, delete or change a list by it`s id

Κεφάλαιο 5. Πειράματα & Αποτελέσματα 95 Εικόνα 5.5: Mytop10: User resource - PUT user Εικόνα 5.6: Mytop10: User resource - PUT user examples Then I should see "List doesn`t exist" Scenario: Anauthorized list viewing and editing When I request or delete a list by it`s id Then I should see "You are unauthorized to make this request." Scenario: Delete list Delete a single list of a particular user. When I remove a list by it`s id Then I should see "List deleted successfully" Scenario: View all the lists Returns all lists of a particular user. When I submit an all list retrieval as follows all true Then I should see "OK" Scenario: Lists don`t exist #Given user has no list When I submit a request for all the user`s lists by specifying all true

Κεφάλαιο 5. Πειράματα & Αποτελέσματα 96 Εικόνα 5.7: Mytop10: User resource - DELETE user Then I should see "There are no lists" Scenario: Unauthorized to retrieve lists #Given that I don`t have required authorization When I submit a request for all lists all true Then I should see "You are unauthorized to make this request." Scenario: Change list name: Change a name of a single list. When I change a list by it`s id And I specify a list name as the changed value listname `movies ` Then I should see "Listname changed successfully" Εκτελούμε ξανά το Gherkin2OAS. Στην Εικόνα 5.9 βλέπουμε τα νέα path που δημιουργήθηκαν. Παρατηρούμε ότι οι αλγόριθμοι του formatter έχουν εντοπίσει την ιεραρχία μεταξύ user και list, όπως περιγράφηκε στο Background του list. Έτσι τα path του list κατασκευάστηκαν όπως φαίνεται στην εικόνα. Στις εικόνες 5.10-5.13 φαίνονται οι περιγραφές των νέων operation. Στο POST βλέπουμε ότι εντοπίσθηκαν σωστά τέσσερα status code. Γενικότερα, στα μέχρι τώρα operation τα μηνύματα των status code αντιστοιχίζονται στο σωστό νούμερο. Στην συνέχεια γράφουμε το resource admin: Feature: Manage administrators Παράδειγμα 5.3: Mytop10 admin resource Background: Given that I am authorized as system Scenario: Create a new administrator Creates a new single administrator. When I create a new administrator: admin name `ADMIN01 ` admin id 1

Κεφάλαιο 5. Πειράματα & Αποτελέσματα 97 Εικόνα 5.8: Mytop10: User resource - POST user Εικόνα 5.9: Mytop10: List resource - paths Then I should see "Successfull new admin account" Scenario: View admin`s details Returns data about a single administrator. When I check an admin by his id Then I should see "OK" And the details of the admin admin_id 123 username "Kostas Sotiriou" Scenario: Retrieve non existent admin When I check an admin by his id # And there is no such admin Then I should see "Admin doesn`t exist" Στις Εικόνες 5.14-5.17 βλέπουμε τα νέα entry του OpenAPI Specification. Παρατηρούμε ότι προστέθηκαν δύο νέα path. Επίσης προστέθηκε νέο security definition και

Κεφάλαιο 5. Πειράματα & Αποτελέσματα 98 Εικόνα 5.10: Mytop10: List resource - GET καταχωρήθηκαν τα scopes στα αντίστοιχα operations. Τέλος καταχωρήθηκαν σωστά το μοντέλο του admin, οι τύποι δεδομένων και τα requirements των παραμέτρων. Στην συνέχεια προσθέτουμε το rate resource: Feature: rate lists Παράδειγμα 5.4: Mytop10 rate resource Background: Given a list id Scenario: Rate a list When I submit a rating for a list: # parameter names as described by product owners ratio 7 ratio id 4 Then I should see "OK, list rated" Scenario: Rate a non existent list When I submit a rating for a list: ratio 7 ratio id 4 # And the list does not exist Then I should see "List doesn`t exist" Scenario: Unauthorized list When I submit a rating for a list: ratio 7 ratio id 4 # And I`m not authorized to do so Then I should see "You are unauthorized to make this request." Στις Εικόνες 5.18-5.18 φαίνονται οι αλλαγές στο OpenAPI Specification. Στην εικόνα με τα paths βλέπουμε ότι το Gherkin2OAS κατάφερε επιτυχώς να εντοπίσει ιεραρχία τριών επιπέδων. Στην εικόνα με το POST operation, το model rating έχει εντοπιστεί και έχει

Κεφάλαιο 5. Πειράματα & Αποτελέσματα 99 Εικόνα 5.11: Mytop10: List resource - PUT καταχωρηθεί σωστά μία φορά (αν και εμφανίζεται τρεις). Επιπλέον βλέπουμε ότι το body είναι σημασμένο ως required, αφού εμφανίστηκε και στα τρία σενάρια της Gherkin. Ακόμη στην εικόνα 5.20 και το μοντέλο rating εμφανίζεται σωστά ως υποχρεωτική παράμετρος του rate_post_request_body, αφού και αυτό εμφανίστηκε και στα τρία σενάρια. Συνεχίζοντας, αποφασίζουμε να γράψουμε το search resource, στο οποίο οργανώθηκαν όλες οι αναζητήσεις με query μίας παραμέτρου. Το resource file έχει ως εξής: Παράδειγμα 5.5: Mytop10 search resource Feature: Search functionality for the system Scenario: Search for a user Returns data about a single user. When I search for a user And I specify a username Then I should see the user`s short details email `anasdima@ece.auth.gr` username `Tasos` id 250 date of birth 04/05/1992 And I should see the message "User found" Scenario: Search for a list Returns data about a single list. When I search for a list And I specify listname `movies ` Then I should see the list`s short details id 30 category `series` description `Best series since 1990` And I should see the message "List found" Scenario: Search for a list by release date Returns data about a single list.

Κεφάλαιο 5. Πειράματα & Αποτελέσματα 100 Εικόνα 5.12: Mytop10: List resource - DELETE When I search for a list And I specify date of release 19/02/2017 Then I should see the list`s short details id 30 category `series` description `Best series since 1990` date of release 05/06/2010 And I should see the message "List found" Scenario: Search for lists with the bigest ratio Returns the lists with the bigest ratio. When I search for a list And I specify ratio 5 sort `descending ` Then I should see a sorted by ratio list of lists sorted list [`highest ratio listname `, \`medium ratio listname `,`lowest ratio listname `] maximum 15 items And I should see "OK" Scenario: Unauthorized search # Given that I`m unauthorized When I search And I specify for example ratio 5 sort `descending ` Then I should see "You are unauthorized to make this request." Scenario: Search query has no results When I search And I specify for example ratio 5 sort `descending ` # And there are no results Then I should see `none found`

Κεφάλαιο 5. Πειράματα & Αποτελέσματα 101 Εικόνα 5.13: Mytop10: List resource - POST Εικόνα 5.14: Mytop10: Admin resource - paths Στην Εικόνα 5.21 φαίνεται το νέο μοναδικό path που δημιουργήθηκε και η περιγραφή του. Όλες οι query παράμετροι ορθώς ορίστηκαν ως μη required. Οι τύποι δεδομένων εντοπίστηκαν σωστά και εντοπίστηκε και ο τύπος array, τα όρια του και ο εσωτερικός τύπος των δεδομένων του. Τέλος το id είναι required γιατί εμφανίζεται σε όλα τα default response. (Εδώ τα response codes δεν επιλέχτηκαν απαραίτητα ώστε να έχουν νόημα, αλλά περισσότερο ώστε να αναδειχθούν συνδυασμοί χαρακτηριστικών) Τέλος προσθέτουμε τα resource follow list και comment : Feature: follow list Παράδειγμα 5.6: Mytop10 search resource Background: Given a user`s id Scenario:

Κεφάλαιο 5. Πειράματα & Αποτελέσματα 102 Εικόνα 5.15: Mytop10: Admin resource - security Feature: Comment a list When I create a new followlist: users [1,5,7,12,10] maximum of 10000 Then I should see `OK` Background: Given a list id Scenario: Comment list Comment a list of a particular user. When I create a new comment: comment content `I like most of your list` comment id 12 Then I should see "List commented successfully" Στις Εικόνες 5.22-5.23 εμφανίζονται τα νέα specification. Βλέπουμε και εδώ ότι σωστά εντοπίστηκαν οι ιεραρχίες των path, έως βάθους τρία. Τα body έχουν οριστεί ως required. Επίσης φαίνεται και το μέγεθος του array users στο followlist μοντέλο, όπως και ότι το περιεχόμενό του είναι τύπου integer με int32 format. Στις εικόνες 5.24-5.25, τα μοντέλα έχουν οριστεί ως required στα requrest_body μοντέλα. Τα παραπάνω resource files περιγράφουν το σύνολο του API. Επισημαίνουμε ότι όλες οι path παράμετροι που εντοπίστηκαν στις ιεραρχίες, κληρονομήθηκαν και στα νέα (χαμηλότερης ιεραρχίας) operations. Σε κάποια σενάρια των resource file, αξιοποιούνται τα comment ως hidden step για καλύτερη περιγραφή του σεναρίου. Στην Εικόνα 5.26 φαίνονται οι εκτελέσεις του Gherkin2OAS για κάθε νέο resource, όπως παρουσιάστηκαν. Βλέπουμε πως ο χρόνος εκτέλεσης αυξάνεται καθώς προσθέτουμε νέα resource. Αν θέλαμε να δοκιμάζουμε το κάθε resource ξεχωριστά, ώστε να έχουμε γρηγορότερους χρόνους εκτέλεσης, θα μπορούσαμε να αφαιρέσουμε τις περιγραφές ιεραρχίας. Έτσι τα resource θα ήταν αυτόνομα από τα υπόλοιπα και θα προσθέταμε τις περιγραφές, όποτε κρίναμε απαραίτητο.

Κεφάλαιο 5. Πειράματα & Αποτελέσματα 103 Εικόνα 5.16: Mytop10: Admin resource - GET 5.3.2 Generic e-shop Στην υπό ενότητα αυτή μελετούμε το OpenAPI Specification ενός γενικού eshop που σχεδιάστηκε στα πλαίσια της διπλωματικής. Προς χάριν παρουσίασης, τα παραδείγματα του Κεφαλαίου 4, βελτιώθηκαν με πιο ρεαλιστικές περιγραφές. Τα resource files βρίσκονται στο Παράρτημα C.2 και δεν παρατίθενται ολόκληρα και εδώ για συντομία. Στην υπό ενότητα αυτή μας ενδιαφέρει να εξετάσουμε την ανάπτυξη του API από μία άλλη σκοπιά και γι αυτό δεν θα μελετήσουμε αναλυτικά όλα τα σενάρια, όπως κάναμε στην προηγούμενη ενότητα. Έτσι εκτελούμε το Gherkin2OAS με όλα τα resource file ως είσοδο. Στις Εικόνες 5.27 και 5.28 βλέπουμε τα paths που δημιουργήθηκαν, όπως θα θέλαμε. Στην Εικόνα 5.29 βλέπουμε το μοντέλο product και τους εντοπισμένους τύπους δεδομένων. Επίσης στην Εικόνα 5.30 βλέπουμε ενδεικτικά την POST HTTP απάντηση του resource basket. Παρατηρούμε ότι καταγράφηκαν σωστά τα arrays, τα examples, τα μέγιστα, οι τύποι δεδομένων και τα requirements. Επίσης βλέπουμε ότι καταγράφηκαν σωστά και τα HATEOAS links. Αν μελετήσει κανείς το OpenAPI Specification στο Παράρτημα C.2, θα διαπιστώσει ότι όλα τα επιθυμητά χαρακτηριστικά έχουν εντοπιστεί. Έτσι εδώ θα εξετάσουμε προσεκτικά τα HATEOAS links καθώς και την REST ανάλυση του API. Στα resource files δεν περιγράφονται HATEOAS links για όλα τα σενάρια. Έτσι το σύστημα δεν είναι εξ ορισμού REST. Εμείς θα υποβάλλουμε REST ανάλυση στο υποσύστημα που δημιουργείται από τα σενάρια με HATEOAS links. Για το σκοπό αυτό ο κώδικας του γράφου τροποποιήθηκε σκόπιμα ώστε να αποκρύπτει τα resources χωρίς HATEOAS links. Στο Παράδειγμα 5.7 βλέπουμε τα είκοσι τέσσερα (24) links που εντοπίστηκαν σε έντεκα (11) σενάρια. Όλα τα link εντοπίστηκαν σωστά. Βλέπουμε επίσης ότι έχουν καταχωρηθεί και οι ιεραρχίες των path.

Κεφάλαιο 5. Πειράματα & Αποτελέσματα 104 Εικόνα 5.17: Mytop10: Admin resource - POST Εικόνα 5.18: Mytop10: Rate resource - paths Παράδειγμα 5.7: Generic eshop: all HATEOAS links And I should be prompted to request a search order_delete_200_response: x links: path: /search operation: get And I should be prompted to submit a payment And I have the option to review the order And I have the option to cancel the order And I have the option to update the order order_post_200_response: x links: path: `/order/{order_id}/payment ` operation: post path: `/order/{order_id}` operation: get path: `/order/{order_id}` operation: delete path: `/order/{order_id}` operation: put

Κεφάλαιο 5. Πειράματα & Αποτελέσματα 105 Εικόνα 5.19: Mytop10: Rate resource - POST Εικόνα 5.20: Mytop10: Rate resource - required model And I should be prompted to submit a payment And I have the option to review the order And I have the option to cancel the order And I have the option to update the order order_get_default_response: x links: path: `/order/{order_id}/payment ` operation: post path: `/order/{order_id}` operation: get path: `/order/{order_id}` operation: delete path: `/order/{order_id}` operation: put And I should be prompted to submit a payment And I have the option to review the order And I have the option to cancel the order And I have the option to update the order order_put_200_response: x links: path: `/order/{order_id}/payment ` operation: post

Κεφάλαιο 5. Πειράματα & Αποτελέσματα 106 Εικόνα 5.21: Mytop10: Search resource - GET path: `/order/{order_id}` operation: get path: `/order/{order_id}` operation: delete path: `/order/{order_id}` operation: put And I should be prompted to add it to the basket product_get_default_response: x links: path: /basket operation: post Then I should be prompted to view the order payment_post_default_response: x links: path: `/order/{order_id}` operation: get And I should be prompted to submit a payment

Κεφάλαιο 5. Πειράματα & Αποτελέσματα 107 Εικόνα 5.22: Mytop10: Follow list resource - POST And I should be prompted to view the order payment_post_400_response: x links: path: `/order/{order_id}/payment ` operation: post path: `/order/{order_id}` operation: get And I have the option to view a product search_get_default_response: x links: path: `/product/{product_id}` operation: get And I should be prompted to create an order And I should have the option to view my basket basket_get_default_response: x links: path: /order operation: post path: `/basket/{basket_id}` operation: get And I should be prompted to create an order And I should have the option to view my basket basket_put_default_response: x links: path: /order operation: post path: `/basket/{basket_id}` operation: get And I should be prompted to create an order

Κεφάλαιο 5. Πειράματα & Αποτελέσματα 108 Εικόνα 5.23: Mytop10: Comment resource - POST Εικόνα 5.24: Follow list resource - required model And I should have the option to view my basket basket_post_default_response: x links: path: /order operation: post path: `/basket/{basket_id}` operation: get Έχοντας επιβεβαιώσει τον εντοπισμό των link, εξετάζουμε το γράφο με τις μεταβάσεις καταστάσεων σε επίπεδο πόρων. Ο γράφος αυτός έχει την μορφή της Εικόνας 5.31. Παρατηρούμε ότι υπάρχει ένα κατευθυνόμενο μονοπάτι που συνδέει κάθε ζευγάρι κορυφών (υπάρχει κύκλος). Επομένως ικανοποιείται η αναγκαία συνθήκη ώστε το API να είναι REST. Η συνθήκη αυτή όμως δεν είναι ικανή. Συνεχίζουμε την REST ανάλυσή μας, εξετάζοντας των γράφο μετάβασης καταστάσεων σε επίπεδο κατάστασης εφαρμογής. Ο γράφος αυτός φαίνεται στην Εικόνα 5.32. Βλέπουμε ότι υπάρχουν κόκκινες ακμές. Μελετώντας προσεκτικά τις διαδρομές, διαπιστώνουμε ότι όλα τα κόκκινα βέλη καταλήγουν στις καταστάσεις view unpaid order (default) και view

Κεφάλαιο 5. Πειράματα & Αποτελέσματα 109 Εικόνα 5.25: Mytop10: Comment resource - required model paid order (default). Παρατηρούμε ότι αυτές οι δύο καταστάσεις εφαρμογής έχουν το ίδιο status code (default). Περιγράφηκαν όμως διαφορετικά σενάρια. Αν εξετάσουμε το resource file order, βλέπουμε τις εξής περιγραφές σεναρίων: Παράδειγμα 5.8: Generic eshop: GET order - διπλή περιγραφή Scenario: view unpaid order Given that I have ordered When I request an order by it`s id Then I can view the details of the order product names [`Chair`,`Keyboard `,`Dell Laptop `] product descriptions [`Made in Stockholm `,`Mechanical `,`IPS Screen `] And I should be prompted to submit a payment And I have the option to review the order And I have the option to cancel the order And I have the option to update the order Scenario: view paid order Given that I have ordered When I request an order by it`s id Then I can view the details of the order product names [`Chair`,`Keyboard `,`Dell Laptop `] product descriptions [`Made in Stockholm `,`Mechanical `,`IPS Screen `] And I have the option to review the order Όταν σχεδιαζόταν το κατάστημα, διαπιστώθηκε ότι στην περίπτωση που μία παραγγελία είχε πληρωθεί, δεν θα μπορούσε να ξανά πληρωθεί, να διαγραφεί ή να ενημερωθεί. Η μόνη δυνατότητα θα ήταν αυτή της προβολής. Αντίθετα στην περίπτωση μη πληρωμένης παραγγελίας, θέλουμε όλες οι παραπάνω ενέργειες να διαφημίζονται στην απάντηση του API. Δεν περιγράψαμε όμως διαφορετικές καταστάσεις για κάθε απάντηση. Στην πραγματικότητα ταυτίσαμε την αλλαγή κατάστασης του πόρου με την αλλαγή στην κατάσταση της εφαρμογής.έτσι το API θα αγνοεί ποια απάντηση θα διαφημίσει. Από αυτό το σημείο έχουμε δύο επιλογές. Να δώσουμε ένα status code σε μία από τις δύο απαντήσεις ή να δημιουργήσουμε έναν νέο πόρο. Επειδή και τα δύο σενάρια περιγράφουν επιτυχή απάντηση, επιλέγουμε την δημιουργία νέου πόρου. Ο νέος πόρος έχει όνομα pending deliveries και περιεχόμενο ως εξής: Παράδειγμα 5.9: Generic eshop: Δημιουργία resource pending deliveries Feature: Check the products pending for delivery

Κεφάλαιο 5. Πειράματα & Αποτελέσματα 110 Εικόνα 5.26: Mytop10: Gherkin2OAS execution Scenario: view delivery # Given that I have ordered When I request a delivery by it`s id Then I can view the details of the order product names [`Chair`,`Keyboard `\,`Dell Laptop `] product descriptions [`Made in Stockholm `\,`Mechanical `,`IPS Screen `] And I have the option to review the pending deliveries Εκτελούμε το Gherkin2OAS και δημιουργούμε νέο valid OpenAPI Specification. Έπειτα μελετούμε πάλι τον γράφο μετάβασης καταστάσεων σε επίπεδο πόρων (Εικόνα 5.33). Βλέπουμε ότι εμφανίστηκε μία νέα κορυφή, μη συνδεδεμένη με τον υπόλοιπο γράφο. Αυτό είναι λογικό αφού το νέο σενάριο περιγράφει μόνο ένα HATEOAS link στον εαυτό του. Το ότι το νέο υποσύστημα δεν είναι REST, δεν μας ενδιαφέρει στην παρούσα φάση. Έτσι αυτή την στιγμή μας αρκεί το γεγονός ότι ο υπόλοιπος γράφος έχει κύκλο. Στην συνέχεια μελετούμε τον γράφο μετάβασης καταστάσεων σε επίπεδο εφαρμογής (Εικόνα 5.34).

Κεφάλαιο 5. Πειράματα & Αποτελέσματα 111 Εικόνα 5.27: Generic eshop: paths (1/2) Βλέπουμε ότι η αλλαγή που πραγματοποιήσαμε έλυσε το πρόβλημα με τις καταστάσεις. Αγνοώντας και εδώ την καινούργια κατάσταση, εξετάζουμε αν ο γράφος έχει κύκλο. Διαπιστώνουμε ότι δεν έχει, διότι δεν υπάρχει τρόπος να βρεθούμε στην κατάσταση update basket (default). Τώρα μπορούμε να συζητήσουμε με τον πελάτη και τους υπόλοιπους μηχανικούς, πώς θα λύσουμε αυτό το πρόβλημα. Έτσι συνεχίζουμε την διαδικασία ανάπτυξης του API. Αν εκτιμούμε ότι μπορούμε να εξηγήσουμε ικανοποιητικά στον client πώς θα επεξεργαστεί τις αμφιλεγόμενες αναπαράστασεις πόρων, τότε μπορούμε να μην προσθέσουμε νέο πόρο. Αντίθετα, μπορούμε να καλέσουμε την λειτουργία fix graph με την επιλογή -fg στην κλήση τερματικού. Στην περίπτωση αυτή, το σύστημα θα μας προτρέψει να διορθώσουμε τις αμφιλεγόμενες μεταβάσεις όπως φαίνεται στην Εικόνα 5.35. Τα παραπάνω παραδείγματα συνοψίζουν την λειτουργία και τα αποτελέσματα του προτεινόμενου συστήματος.

Κεφάλαιο 5. Πειράματα & Αποτελέσματα 112 Εικόνα 5.28: Generic eshop: paths (2/2) Εικόνα 5.29: Generic eshop: product model

Κεφάλαιο 5. Πειράματα & Αποτελέσματα 113 Εικόνα 5.30: Generic eshop: basket post response

Κεφάλαιο 5. Πειράματα & Αποτελέσματα 114 Εικόνα 5.31: Generic eshop: Γράφος με μεταβάσεις καταστάσεων σε επίπεδο πόρων

Κεφάλαιο 5. Πειράματα & Αποτελέσματα 115 Εικόνα 5.32: Γράφος με μεταβάσεις καταστάσεων σε επίπεδο κατάστασης εφαρμογής

Κεφάλαιο 5. Πειράματα & Αποτελέσματα 116 Εικόνα 5.33: Generic eshop: Νέος γράφος με μεταβάσεις καταστάσεων σε επίπεδο πόρων

Κεφάλαιο 5. Πειράματα & Αποτελέσματα 117 Εικόνα 5.34: Generic eshop: Νέος γράφος με μεταβάσεις καταστάσεων σε επίπεδο κατάστασης εφαρμογής

Κεφάλαιο 5. Πειράματα & Αποτελέσματα 118 Εικόνα 5.35: Generic eshop: Προτροπή διόρθωσης γράφου