Μοντελοποίηση μη λειτουργικών απαιτήσεων λογισμικού σε μοντέλα διαδικτυακών συστημάτων REST

Transcript

1 Διπλωματική Εργασία Μοντελοποίηση μη λειτουργικών απαιτήσεων λογισμικού σε μοντέλα διαδικτυακών συστημάτων REST Δόντσιος Δημήτριος Α.Ε.Μ : 7426 Επιβλέποντες: Επίκουρος Καθηγητής Ανδρέας Λ. Συμεωνίδης Υποψήφιος Διδάκτωρ Χριστόφορος Ζολώτας Εργαστήριο Επεξεργασίας Πληροφορίας και Υπολογιστών Θεσσαλονίκη, Μάρτιος 2017

2 Ευχαριστίες ΜΟΝΤΕΛΟΠΟΙΗΣΗ ΜΗ ΛΕΙΤΟΥΡΓΙΚΩΝ ΑΠΑΙΤΗΣΕΩΝ ΛΟΓΙΣΜΙΚΟΥ ΣΕ ΜΟΝΤΕΛΑ ΔΙΑΔΙΚΤΥΑΚΩΝ ΣΥΣΤΗΜΑΤΩΝ REST Θα ήθελα να ευχαριστήσω αρχικά τον κ. Ανδρέα Συμεωνίδη, για την εμπιστοσύνη που μου έδειξε αναθέτοντάς μου την διπλωματική αυτή. Έπειτα, τον υποψήφιο διδάκτορα Χριστόφορο Ζολώτα για την υπομονή του, την καλή καθοδήγηση, τις άρτιες παρατηρήσεις και τη βοήθεια που μου προσέφερε. Τέλος, θα ήθελα να ευχαριστήσω όλους τους ανθρώπους, οικογένεια και φίλους, που με στήριξαν με οποιονδήποτε τρόπο καθ όλη τη διάρκεια φοίτησης και ιδιαίτερα κατά τη διάρκεια εκπόνησης της διπλωματικής αυτής. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

3 Περίληψη ΜΟΝΤΕΛΟΠΟΙΗΣΗ ΜΗ ΛΕΙΤΟΥΡΓΙΚΩΝ ΑΠΑΙΤΗΣΕΩΝ ΛΟΓΙΣΜΙΚΟΥ ΣΕ ΜΟΝΤΕΛΑ ΔΙΑΔΙΚΤΥΑΚΩΝ ΣΥΣΤΗΜΑΤΩΝ REST To πρότυπο αρχιτεκτονικής διαδικτυακών υπηρεσιών REST πρωτοεμφανίστηκε στην επιστημονική διατριβή του Roy Fielding το To πρότυπο αυτό είναι στην ουσία ένα σετ από κανόνες και περιορισμούς των οποίων η εφαρμογή σε μια διαδικτυακή υπηρεσία την καθιστούν πιο ελκυστική, αυξάνοντας την απόδοσή της, την επεκτασιμότητά της και διευκολύνοντας την διαδικασία κατανόησης και τροποποίησής της. Το REST εισήγαγε πρώτη φορά την ιδέα της μεταχείρισης των αντικειμένων μιας υπηρεσίας ως πόρους οι οποίοι μπορούν να δημιουργηθούν και να καταστραφούν μέσω των Ενιαίων Αναγνωριστικών Πόρων (URI), δηλαδή συνδέσμους στο διαδίκτυο. Οι πόροι αυτοί τροποποιούνται μέσω ενός συνόλου καλώς ορισμένων ενεργειών (HTTP ρήματα) και διαμοιράζονται μεταξύ πελατών και διακομιστών μέσω αναπαραστάσεων και καλώς ορισμένων πρωτοκόλλων. Λόγω της απλότητάς της, η αρχιτεκτονική REST έγινε ιδιαίτερα διάσημη και όλο και περισσότερες υπηρεσίες στο διαδίκτυο είναι RESTful. Έτσι προέκυψε μια συνεχώς αυξανόμενη ανάγκη για ανάπτυξη εργαλείων που αυτοματοποιούν την παραγωγή RESTful υπηρεσιών. Πολλά από τα εργαλεία που αναπτύχθηκαν είναι εύκολα στη χρήση τους, αλλά όλα υστερούν σε κάποιον τομέα. Κάποια από αυτά πετυχαίνουν υψηλότερη κάλυψη των περιορισμών που ορίζει η αρχιτεκτονική REST, ενώ άλλα καταφέρνουν καλύτερη αυτοματοποίηση της διαδικασίας παραγωγής του κώδικα. Το κοινό τους χαρακτηριστικό είναι ότι στοχεύουν στην κάλυψη των λειτουργικών απαιτήσεων της παραγόμενης υπηρεσίας και αγνοούν την σημασία της κάλυψης των μη λειτουργικών απαιτήσεων, γι αυτό και δεν λαμβάνουν τις μη λειτουργικές απαιτήσεις υπόψιν τους στη διαδικασία ανάπτυξης. Η παρούσα διπλωματική παρουσιάζει την ανάπτυξη ενός εργαλείου αυτοματοποίησης της παραγωγής μιας RESTful υπηρεσίας, το οποίο όμως καλύπτει και μη λειτουργικές απαιτήσεις, εκτός από λειτουργικές. Το εργαλείο αυτό είναι μια επέκταση ενός υπάρχοντος συστήματος αυτόματης παραγωγής κώδικα, του S-CASE, το οποίο χρησιμοποιεί τεχνικές μοντελοστραφούς σχεδίασης και μοντελοστραφούς αρχιτεκτονικής. Για τον λόγο αυτό, η τεχνική που ακολουθείται για την αυτόματη παραγωγή κώδικα ακολουθεί όλους τους κανόνες που εισήγαγε ο OMG (Object Management Group) κατά τον ορισμό της αρχιτεκτονικής οδηγούμενης από μοντέλα (MDA). Η παραγόμενη από το εργαλείο υπηρεσία έχει αρχιτεκτονική MVC και η πλατφόρμα εκτέλεσης είναι η Java EE. Συμφωνεί με όλους τους κανόνες που εισάγει το εργαλείο S-CASE. O τρόπος με τον οποίο καλύπτονται οι μη λειτουργικές απαιτήσεις είναι η μοντελοποίηση προτύπων σχεδίασης που τις ικανοποιούν και η ενσωμάτωση των μοντέλων αυτών στην διαδικασία παραγωγής του κώδικα, και άρα, τελικά, η ενσωμάτωση των προτύπων σχεδίασης στον εκτελέσιμο κώδικα. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

4 Meta-modeling of Non-Functional Software Requirements for RESTful Services Abstract The REST design pattern was first introduced in Roy Fielding s dissertation in This pattern is in fact a set of well-defined rules and constraints, which, when applied to a given web service, they make it more appealing by improving performance, enabling scalability, modifiability and easy grasping of the functionality of the service. The basic idea of REST is that every object of the service is a resource that can be easily created and destroyed, using Uniform Resource Identifiers (URIs), namely web links. These resources can be modified by a well-defined set of actions, the HTTP verbs, and they can be shared between clients and servers using strict representation forms and protocols. Due to its simplicity, REST became so popular that more and more services are built guided by its architectural style. Thus, an increasing need for tools that automate the process of building RESTful web services is evident. Many such tools are easy to use, but lack in some aspects. Some of them achieve to meet more constraints that REST demands, while others manage better automation process. However, what is common in all existing tools is that they aim to fulfill only functional requirements whereas they disregard the importance of non-functional requirements. The aim of this thesis is the design and the development of a tool that automates the production of a RESTful API, while taking into account nonfunctional requirements apart from the functional ones. This tool is an extension of the S-CASE MDE Engine that semi-automatically produces RESTful APIs by employing model driven. The implemented extension uses the MDA process, a model driven engineering process that the OMG (Object Management Group) introduced for the purposes of model driven engineering. The generated code conforms to the MVC architecture using JAVA EE. It also complies with all the rules that the S-CASE tool introduces, thus conforms to Richardson s Maturity Model. The nonfunctional requirements are satisfied by modeling design patterns and integrating them into the S-CASE MDE engine, hence by the integration of those patterns into the produced code. Dontsios Dimitrios dontsios@gmail.com Aristotle University of Thessaloniki Electrical & Computer Engineering Department Thessaloniki, March 2017 ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

5 Περιεχόμενα Ευχαριστίες... 2 Περίληψη... 3 Meta-modeling of Non-Functional Software Requirements for RESTful Services... 4 Abstract... 4 Λίστα Εικόνων... 8 Λίστα Πινάκων Λεξικό όρων Όροι στα αγγλικά Αρκτικόλεξα Εισαγωγή Στόχος της διπλωματικής Διάρθρωση του εγγράφου Υπόβαθρο Τεχνολογία Λογισμικού και η σημασία της Διαδικτυακές εφαρμογές, διαδικτυακές υπηρεσίες και Web APIs REST και Richardson s Maturity Model Πόρος Αναπαράσταση Πως πραγματοποιείται η επικοινωνία στο Web? Ιδιότητες της αρχιτεκτονική REST Το μοντέλο ωρίμανσης του Richardson Σύνοψη Μη Λειτουργικές Απαιτήσεις Λογισμικού Γενικά Περιγραφή και Χαρακτηριστικά Πρότυπα Σχεδίασης Δημιουργικά πρότυπα Δομικά Πρότυπα Πρότυπα Συμπεριφοράς MDE και MDA Ecore και EMF ATL Acceleo Η αυξανόμενη ανάγκη για Web APIs State of the Art και Related Work Ruby on Rails ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

6 3.2 EMF-Rest Django-REST-Framework S-CASE Tα πλεονεκτήματά του σε σχέση με τις υπάρχουσες τεχνολογίες ΜΛΑ και MDE Μεθοδολογία Γενικά S-CASE Η μορφή της επέκτασης Γενικά Γενικά στοιχεία του DesignPatternsLayerCIM μεταμοντέλου Γενικά στοιχεία του DesignPatternsLayerPIM μεταμοντέλου Γενικά στοιχεία του DesignPatternsLayerPSM μεταμοντέλου CIM to PIM ATL μετασχηματισμοί για τα γενικά στοιχεία PIM to PSM ATL μετασχηματισμοί για τα γενικά στοιχεία CIM to PIM Builder Pattern Πρότυπο Χτίστη Observer Pattern Πρότυπο Παρατηρητή Memento Pattern Πρότυπο Μνήμης Bridge Pattern Πρότυπο Γέφυρας DesignPatternsLayerPSM to Text Acceleo μετασχηματισμοί Το αποτέλεσμα της χρήσης της επέκτασης Πρότυπο Χτίστη Πρότυπο Παρατηρητή Πρότυπο Μνήμης Πρότυπο Γέφυρας Εφαρμογή της επέκτασης στο RESTMarks To RESTMarks Παραγωγή της υπηρεσίας Το πρότυπο Χτίστη στον πόρο account To πρότυπο Μνήμης στον πόρο bookmark Το πρότυπο παρατηρητή στον πόρο tag To πρότυπο Γέφυρας στον πόρο tagsearch Εκτέλεση της υπηρεσίας Αρχικοποίηση και εκτέλεση Λειτουργικότητα προτύπου Χτίστη Λειτουργικότητα του προτύπου Παρατηρητή ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

7 5.3.4 Λειτουργικότητα του προτύπου Μνήμης Λειτουργικότητα του προτύπου Γέφυρας Επίλογος Μελλοντικές Επεκτάσεις Βιβλιογραφία ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

8 Λίστα Εικόνων Εικόνα 1. SDLC - Software Development Life Cycle - Ο κύκλος της ζωής του λογισμικού Εικόνα 2. Παράδειγμα επικοινωνίας στο Web Εικόνα 3. Παράδειγμα μεταβάσεων στο Web Εικόνα 4. To μοντέλο ωριμότητας του Richardson - RMM Εικόνα 5. Μια ταξινομία των ΜΛΑ Εικόνα 6. Διάγραμμα κλάσεων του Προτύπου Χτίστη Εικόνα 7. Διάγραμμα ενεργειών στο Πρότυπο Χτίστη Εικόνα 8. Διάγραμμα κλάσεων του Προτύπου Γέφυρας Εικόνα 9. Διάγραμμα κλάσεων του προτύπου Παρατηρητή Εικόνα 10. Διάγραμμα κλάσεων του Προτύπου Μνήμης Εικόνα 11. Η βασική αρχιτεκτονική τεσσάρων επιπέδον του MOF Εικόνα 12. Μετασχηματισμός μοντέλου Εικόνα 13. Μηχανισμός μετασχηματισμού μοντέλων σύμφωνα με την MDA προσέγγιση Εικόνα 14. Αποτέλεσμα ερευνών που αφορούν τη χρήση τoυ MDE Εικόνα 15. Συμπεράσματα ερευνών που αφορούν τη χρήση του MDE Εικόνα 16. Απλουστευμένο μεταμοντέλο του Ecore Εικόνα 17. Μεταμοντέλο Ecore Εικόνα 18. EMF και ενοποίηση αναπαραστάσεων Εικόνα 19. ATL model to model μετασχηματισμός Εικόνα 20. Ρυθμός αύξησης των δημόσιων APIs Εικόνα 21. Σύγκριση αριθμού εφαρμογών και αριθμού προγραμματιστών Εικόνα 22. Ruby on Rails Εικόνα 23. EMF-REST Εικόνα 24. Απόκριση στην ερώτηση GET /Family/Simpsons/pets Εικόνα 25. Serializers μιας υπηρεσίας του Django-REST-Framework Εικόνα 26. Απάντηση ενός GET ερωτήματος σε μια υπηρεσία που παράχθηκε με χρήση του Django-REST- Framework Εικόνα 27. Οι 4 φάσεις της δισδιάστατης μοντελοστραφούς σχεδίασης Εικόνα 28. Γενική μορφή ενός μεταμοντέλου - επέκτασης του S-CASE Εικόνα 29. Αρχιτεκτονικό μοντέλο MDA για την επέκταση που προτείνεται Εικόνα 30. Απλοποιημένο DesignPatternsLayerCIM μεταμοντέλο Εικόνα 31. Απλοποιημένο DesignPatternsLayerPIM μεταμοντέλο Εικόνα 32. Απλοποιημένο DesignPatternsLayerPSM μεταμοντέλο Εικόνα 33. Στοιχεία που μοντελοποιούν το πρότυπο Χτίστη στο DesignPatternsLayerCIM μεταμοντέλο Εικόνα 34. Στοιχεία που μοντελοποιούν το πρότυπο Χτίστη στο DesignPatternsLayerPIM μεταμοντέλο Εικόνα 35. Στοιχεία που μοντελοποιούν το πρότυπο Χτίστη στο DesignPatternsLayerPSM μεταμοντέλο Εικόνα 36. Στοιχεία που μοντελοποιούν το πρότυπο Παρατηρητή στο DesignPatternsLayerPIM μεταμοντέλο Εικόνα 37. Στοιχεία που μοντελοποιούν το πρότυπο Παρατηρητή στο DesignPatternsLayerPSM μεταμοντέλο Εικόνα 38. Στοιχεία που μοντελοποιούν το πρότυπο Μνήμης στο DesignPatternsLayerCIM μεταμοντέλο Εικόνα 39. Στοιχεία που μοντελοποιούν το πρότυπο Μνήμης στο DesignPatternsLayerPΙM μεταμοντέλο Εικόνα 40. Στοιχεία που μοντελοποιούν το πρότυπο Μνήμης στο DesignPatternsLayerPSM μεταμοντέλο Εικόνα 41. Στοιχεία που μοντελοποιούν το πρότυπο Γέφυρας στο DesignPatternsLayerCIM μεταμοντέλο Εικόνα 42. Στοιχεία που μοντελοποιούν το πρότυπο Γέφυρας στο DesignPatternsLayerPIM μεταμοντέλο Εικόνα 43. Στοιχεία που μοντελοποιούν το πρότυπο Γέφυρας στο DesignPatternsLayerPSM μεταμοντέλο Εικόνα 44. Διάγραμμα κλάσεων του RESTMarks ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

9 Εικόνα 45. Top Level GUI Εικόνα 46. Ορισμός του CORE CIM μοντέλου Εικόνα 47. Ορισμός του Search CIM μοντέλου Εικόνα 48. Επιλογή των προτύπων σχεδίασης που θα εφαρμοστούν Εικόνα 49. Aναπαράσταση του account με ιδιότητες password, username και Εικόνα 50. Aναπαράσταση του account με ιδιότητες username και Εικόνα 51. Εφαρμογή του προτύπου μνήμης στον πόρο bookmark Εικόνα 52. Εφαρμογή του προτύπου παρατηρητή στον πόρο tag Εικόνα 53. Εφαρμογή του προτύπου παρατηρητή στον πόρο tagsearch Εικόνα 54. Βάση δεδομένων postgres για την υπηρεσία RESTMarks Εικόνα 55. ενημέρωσης από τον παρατηρητή Εικόνα 56. Πίνακας παρατηρητών tag στη βάση δεδομένων μετά το τελευταίο ερώτημα Εικόνα 57. Πίνακας στιγμιότυπων μνήμης bookmark στη βάση δεδομένων ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

10 Λίστα Πινάκων Πίνακας 1. Ρήματα HTTP Πίνακας 2. Δημιουργικά Πρότυπα Σχεδίασης Πίνακας 3. Δομικά Πρότυπα Σχεδίασης Πίνακας 4. Πρότυπα Συμπεριφοράς Πίνακας 5. Επιδράσεις της χρήσης της MDE προσέγγισης Πίνακας 6. Μη λειτουργικές απαιτήσεις και πρότυπα σχεδίασης που μπορούν να τις καλύψουν Πίνακας 7. Συνοπτική περιγραφή των μοντέλων και των μεταμοντέλων της επέκτασης Πίνακας 8. Ιδιότητες του AnnotationModel του DesignPatternsLayerCIM μεταμοντέλου Πίνακας 9. Συσχετίσεις του AnnotationModel του DesignPatternsLayerCIM μεταμοντέλου Πίνακας 10.Ιδιότητες του AnnCRUDActivity του DesignPatternsLayerCIM μεταμοντέλου Πίνακας 11. Συσχετίσεις του AnnCRUDActivity του DesignPatternsLayerCIM μεταμοντέλου Πίνακας 12. Συσχετίσεις του AnnProperty του DesignPatternsLayerCIM μεταμοντέλου Πίνακας 13. Συσχετίσεις του AnnResource του DesignPatternsLayerCIM μεταμοντέλου Πίνακας 14. Συσχετίσεις του AnnAlgoResource του DesignPatternsLayerCIM μεταμοντέλου Πίνακας 15. Συσχετίσεις του DesignPattern του DesignPatternsLayerCIM μεταμοντέλου Πίνακας 16. Συσχετίσεις του DesignPatternModel του DesignPatternsLayerCIM μεταμοντέλου Πίνακας 17. Ιδιότητες του AnnotationModel του DesignPatternsLayerPIM μεταμοντέλου Πίνακας 18. Συσχετίσεις του AnnotationModel του DesignPatternsLayerPIM μεταμοντέλου Πίνακας 19. Ιδιότητες του AnnCRUDActivityHandler του DesignPatternsLayerPIM μεταμοντέλου Πίνακας 20. Ιδιότητες του AnnCRUDActivityHandler του DesignPatternsLayerPIM μεταμοντέλου Πίνακας 21. Συσχετίσεις του AnnPIMComponentProperty του DesignPatternsLayerPIM μεταμοντέλου Πίνακας 22. Συσχετίσεις του AnnResourceModel του DesignPatternsLayerPIM μεταμοντέλου Πίνακας 23. Συσχετίσεις του AnnAlgoResourceModel του DesignPatternsLayerPIM μεταμοντέλου Πίνακας 24. Συσχετίσεις του DesignPattern του DesignPatternsLayerPIM μεταμοντέλου Πίνακας 25. Συσχετίσεις του DesignPatternModel του DesignPatternsLayerPIM μεταμοντέλου Πίνακας 26. Ιδιότητες του AnnotationModel του DesignPatternsLayerPSM μεταμοντέλου Πίνακας 27. Συσχετίσεις του AnnotationModel του DesignPatternsLayerPSM μεταμοντέλου Πίνακας 28. Ιδιότητες του AnnHTTPActivityHandler του DesignPatternsLayerPSM μεταμοντέλου Πίνακας 29 Συσχετίσεις του AnnHTTPActivityHandler του DesignPatternsLayerPSM μεταμοντέλου Πίνακας 30. Συσχετίσεις του AnnPSMComponentProperty του DesignPatternsLayerPSM μεταμοντέλου Πίνακας 31. Συσχετίσεις του AnnJavaResourceModel του DesignPatternsLayerPSM μεταμοντέλου Πίνακας 32. Συσχετίσεις του AnnJavaAlgoResourceModel του DesignPatternsLayerPSM μεταμοντέλου Πίνακας 33. Συσχετίσεις του DesignPattern του DesignPatternsLayerPSM μεταμοντέλου Πίνακας 34. Συσχετίσεις του DesignPatternModel του DesignPatternsLayerPSM μεταμοντέλου Πίνακας 35. Κανόνας DesignPatternsLayerCIMToPIM Πίνακας 36. Κανόνας createanncrudactivityhandler Πίνακας 37. Rule createannpimcomponentproperty Πίνακας 38. Rule createannresourcemodel Πίνακας 39. Rule createannalgoresourcemodel Πίνακας 40. Rule DesignPatternsLayerPIMToPSM Πίνακας 41. Rule createannjavahttpactivityhandler Πίνακας 42. Rule createannpsmcomponentproperty Πίνακας 43. Rule createannjavaresourcemodel Πίνακας 44. Rule createannjavaalgoresourcemodel Πίνακας 45. Συσχετίσεις του BuilderPattern του DesignPatternsLayerCIM μεταμοντέλου Πίνακας 46. Συσχετίσεις του Director του DesignPatternsLayerCIM μεταμοντέλου Πίνακας 47. Συσχετίσεις του Builder του DesignPatternsLayerCIM μεταμοντέλου ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

11 Πίνακας 48. Συσχετίσεις του ConcreteBuilder του DesignPatternsLayerCIM μεταμοντέλου Πίνακας 49. Ιδιότητες του Representation του DesignPatternsLayerCIM μεταμοντέλου Πίνακας 50. Συσχετίσεις του Representation του DesignPatternsLayerCIM μεταμοντέλου Πίνακας 51. Συσχετίσεις του BuilderPattern του DesignPatternsLayerPIM μεταμοντέλου Πίνακας 52. Συσχετίσεις του Director του DesignPatternsLayerPIM μεταμοντέλου Πίνακας 53. Συσχετίσεις του Builder του DesignPatternsLayerPIM μεταμοντέλου Πίνακας 54. Συσχετίσεις του ConcreteBuilder του DesignPatternsLayerPIM μεταμοντέλου Πίνακας 55. Ιδιότητες του Representation του DesignPatternsLayerPIM μεταμοντέλου Πίνακας 56. Συσχετίσεις του Representation του DesignPatternsLayerPIM μεταμοντέλου Πίνακας 57. Συσχετίσεις του JavaBuilderPattern του DesignPatternsLayerPSM μεταμοντέλου Πίνακας 58. Συσχετίσεις του JavaDirector του DesignPatternsLayerPSM μεταμοντέλου Πίνακας 59. Συσχετίσεις του JavaBuilder του DesignPatternsLayerPSM μεταμοντέλου Πίνακας 60. Συσχετίσεις του JavaConcreteBuilder του DesignPatternsLayerPSM μεταμοντέλου Πίνακας 61. Ιδιότητες του JavaRepresentation του DesignPatternsLayerPSM μεταμοντέλου Πίνακας 62. Συσχετίσεις του JavaRepresentation του DesignPatternsLayerPSM μεταμοντέλου Πίνακας 63. Rule createpimbuilderpattern Πίνακας 64. Rule createdirector Πίνακας 65. Rule createpimconcretebuilder Πίνακας 66. Rule createpimrepresentation Πίνακας 67. Rule createpsmbuilderpattern Πίνακας 68. Rule createjavadirector Πίνακας 69. Rule createpsmconcretebuilder Πίνακας 70. Rule createpsmrepresentation Πίνακας 71. Στοιχεία που μοντελοποιούν το πρότυπο Παρατηρητή στο DesignPatternsLayerCIM μεταμοντέλο Πίνακας 72. Συσχετίσεις του ObserverPattern του DesignPatternsLayerCIM μεταμοντέλου Πίνακας 73. Ιδιότητες του Observer του DesignPatternsLayerCIM μεταμοντέλου Πίνακας 74. Συσχετίσεις του Observer του DesignPatternsLayerCIM μεταμοντέλου Πίνακας 75. Συσχετίσεις του ObservalbeAnnCRUDActivity του DesignPatternsLayerCIM μεταμοντέλου Πίνακας 76. Συσχετίσεις του ObserverPattern του DesignPatternsLayerPIM μεταμοντέλου Πίνακας 77. Ιδιότητες του Observer του DesignPatternsLayerPIM μεταμοντέλου Πίνακας 78. Συσχετίσεις του Observer του DesignPatternsLayerPIM μεταμοντέλου Πίνακας 79. Συσχετίσεις του ObservalbeAnnCRUDActivityHandler του DesignPatternsLayerPIM μεταμοντέλου Πίνακας 80. Συσχετίσεις του JavaObserverPattern του DesignPatternsLayerPSM μεταμοντέλου Πίνακας 81. Ιδιότητες του JavaObserver του DesignPatternsLayerPSM μεταμοντέλου Πίνακας 82. Συσχετίσεις του JavaObserver του DesignPatternsLayerPSM μεταμοντέλου Πίνακας 83. Συσχετίσεις του JavaObserver του DesignPatternsLayerPSM μεταμοντέλου Πίνακας 84. Rule createpimobserverpattern Πίνακας 85. Rule createpimobserver Πίνακας 86. Rule createobservableanncrudactivityhandler Πίνακας 87. Rule createpsmobserverpattern Πίνακας 88. Rule createpsmobserver Πίνακας 89. Rule createjavaobservableannhttpactivityhandler Πίνακας 90. Συσχετίσεις του MementoPattern του DesignPatternsLayerCIM μεταμοντέλου Πίνακας 91. Ιδιότητες του Memento του DesignPatternsLayerCIM μεταμοντέλου Πίνακας 92. Συσχετίσεις του Memento του DesignPatternsLayerCIM μεταμοντέλου Πίνακας 93. Συσχετίσεις του MementoPattern του DesignPatternsLayerPIM μεταμοντέλου ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

12 Πίνακας 94. Ιδιότητες του PIMMemento του DesignPatternsLayerPIM μεταμοντέλου Πίνακας 95. Συσχετίσεις του PIMMemento του DesignPatternsLayerPIM μεταμοντέλου Πίνακας 96. Συσχετίσεις του JavaMementoPattern του DesignPatternsLayerPSM μεταμοντέλου Πίνακας 97. Ιδιότητες του JavaResourceModelMemento του DesignPatternsLayerPSM μεταμοντέλου Πίνακας 98. Συσχετίσεις του JavaResourceModelMemento του DesignPatternsLayerPSM μεταμοντέλου Πίνακας 99. Rule createpimmementopattern Πίνακας 100. Rule createpimmementopattern Πίνακας 101. Rule createpimmementopattern Πίνακας 102. Rule createpimmemento Πίνακας 103. Συσχετίσεις του BridgePattern του DesignPatternsLayerCIM μεταμοντέλου Πίνακας 104. Συσχετίσεις του BridgePattern του DesignPatternsLayerPIM μεταμοντέλου Πίνακας 105. Συσχετίσεις του JavaBridgePattern του DesignPatternsLayerPSM μεταμοντέλου Πίνακας 106. Rule createpimbridgepattern Πίνακας 107. Rule createpsmbridgepattern Πίνακας 108. Acceleo πρότυπο generate.mtl Πίνακας 109. Acceleo πρότυπο javarepresentationmodel.mtl Πίνακας 110. Acceleo πρότυπο javaobserver.mtl Πίνακας 111. Acceleo πρότυπο javamemento.mtl Πίνακας 112. Acceleo πρότυπο javaresourcecontroller.mtl Πίνακας 113. Acceleo πρότυπο javaresourcecontrollermanager.mtl Πίνακας 114. Acceleo πρότυπο javahttpactivityhandler.mtl Πίνακας 115. Acceleo πρότυπο getresourcehandlernoparent.mtl Πίνακας 116. Acceleo πρότυπο observablegetresourcehandlernoparents.mtl Πίνακας 117. Acceleo πρότυπο abstractjavarestclienthttpactivityhandler.mtl Πίνακας 118. Acceleo πρότυπο extendedjavarestclienthttpactivityhandler.mtl Πίνακας 119. Acceleo πρότυπο generateabstractsearchhttphandler.mtl Πίνακας 120. Acceleo πρότυπο generateextendedsearchhttphandler.mtl Πίνακας 121. Acceleo πρότυπο javahibernatecontroller.mtl Πίνακας 122. Acceleo πρότυπο javahibernateutil.mtl Πίνακας 123. Acceleo πρότυπο mavenconfigurationfile.mtl Πίνακας 124. Ιδιότητες της κλάσης παρατηρητή σε Java Πίνακας 125. Mέθοδοι της κλάσης παρατηρητή σε Java Πίνακας 126. Μέθοδοι της κλάσης που υλοποιεί ένα παρατηρούμενο HTTP ρήμα σε Java Πίνακας 127. Επιπλέον μέθοδοι της κλάσης HibernateController.java για τους πόρους που ακολουθούν το πρότυπο παρατηρητή Πίνακας 128. Επιπλέον Ιδιότητες της κλάσης στιγμιοτύπου μνήμης σε Java Πίνακας 129. Μέθοδοι της κλάσης στιγμιοτύπου μνήμης σε Java Πίνακας 130. Διαφορές στους handlers των HTTP ερωτημάτων για την εύρυθμη λειτουργία του προτύπου μνήμης Πίνακας 131. Επιπλέον μέθοδοι της κλάσης HibernateController.java για τους πόρους που ακολουθούν το πρότυπο μνήμης Πίνακας 132. GET στο account για τη λήψη αναπαράστασης με ιδιότητες username και Πίνακας 133. GET στο account για τη λήψη αναπαράστασης με ιδιότητες username και password Πίνακας 134. PUT στο bookmark για την εγγραφή ενός παρατηρητή στις ενέργειες PUT συγκεκριμένου tag Πίνακας 135. PUT στο tag για τον έλεγχο της λειτουργικότητας του παρατηρητή Πίνακας 136. PUT στο tag για τον έλεγχο της λειτουργικότητας του παρατηρητή Πίνακας 137. PUT στο tag για την εγγραφή ενός παρατηρητή στις ενέργειες PUT όλων των tags ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

13 Πίνακας 138. PUT στο tag για τον έλεγχο της λειτουργικότητας του παρατηρητή Πίνακας 139. PUT στο tag για την διαγραφή ενός παρατηρητή Πίνακας 140. PUT στο bookmark με εντολή διατήρησης στιγμιοτύπου μνήμης Πίνακας 141. GET στο bookmark για τη λήψη συγκεκριμένου στιγμιοτύπου μνήμης Πίνακας 142. PUT στο bookmark για ανάκτηση προηγούμενης κατάστασης - rollback action Πίνακας 143. GET στο AlgotagSearch για την αναζήτηση του tag που περιέχει τον όρο profile στο description ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

14 Λεξικό όρων ΜΟΝΤΕΛΟΠΟΙΗΣΗ ΜΗ ΛΕΙΤΟΥΡΓΙΚΩΝ ΑΠΑΙΤΗΣΕΩΝ ΛΟΓΙΣΜΙΚΟΥ ΣΕ ΜΟΝΤΕΛΑ ΔΙΑΔΙΚΤΥΑΚΩΝ ΣΥΣΤΗΜΑΤΩΝ REST Όροι στα αγγλικά annotation - παρατήρηση / σημείωση client - πελάτης (αναφέρεται στις web υπηρεσίες) controller - χειριστής (αναφέρεται στο MVC) framework - πλαίσιο (αναφέρεται σε ένα σύνολο βιβλιοθηκών) hypermedia - υπερμέσο media format - μορφή αναπαράστασης μέσων query parameter - παράμετρος ερωτήματος (αναφέρεται στις web υπηρεσίες) representation - αναπαράσταση resource - πόρος rollback - επαναφορά σε προηγούμενη κατάσταση μνήμης server - εξυπηρετητής (αναφέρεται στις web υπηρεσίες) wizard - οδηγός λογισμικού Αρκτικόλεξα ΛΑ - Λειτουργική Απαίτηση ΜΛΑ - Μη Λειτουργική Απαίτηση API CASE CIM GUI HTTP JSON m2m m2t MDA MDE MVC PIM PSM REST SDLC SOA XMI XML URI URL - Application Programming Interface - Computer Aided Software Engineering - Computational Independent Model - Graphical User Interface - Hypertext Transfer Protocol - JavaScript Object Notation (Τύπος media format) - Model to model - Model to text - Model Driven Architecture - Model Driven Engineering - Model View Controller (Τύπος αρχιτεκτονικής συστημάτων λογισμικού) - Platform Independent Model - Platform Specific Model - Representational State Transfer (RESTful) - Software Development Life Cycle - Service Oriented Architecture - XML Metadata Interface - extensible Markup Lanuage - Uniform Resource Identifier - Uniform Resource Locator ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

15 1. Εισαγωγή ΜΟΝΤΕΛΟΠΟΙΗΣΗ ΜΗ ΛΕΙΤΟΥΡΓΙΚΩΝ ΑΠΑΙΤΗΣΕΩΝ ΛΟΓΙΣΜΙΚΟΥ ΣΕ ΜΟΝΤΕΛΑ ΔΙΑΔΙΚΤΥΑΚΩΝ ΣΥΣΤΗΜΑΤΩΝ REST 1.2 Στόχος της διπλωματικής Στον τομέα της επιστήμης των υπολογιστών, ως REST αναφέρεται το αρκτικόλεξο του όρου Representational State Transfer (Μεταφορά Αναπαραστάσεων Κατάστασης) και ορίζει έναν τύπο αρχιτεκτονικής λογισμικού υπηρεσιών του World Wide Web. To REST παρέχει ένα σετ από περιορισμούς και οδηγίες για τη σχεδίαση διανεμημένων υπηρεσιών (κυρίως web) με στόχο την καλύτερη απόδοση και μια περισσότερο διατηρήσιμη και επεκτάσιμη αρχιτεκτονική. Tα συστήματα REST έχουν κατακλύσει το Web και όλο και περισσότεροι είναι οι μοντελοστραφείς μηχανισμοί που χρησιμοποιούνται για την αυτοματοποιημένη δημιουργία τους. Έχουν γίνει πολλές και αξιόλογες προσπάθειες για την κάλυψη λειτουργικών απαιτήσεων RESTful συστημάτων που παράγονται αυτόματα, αλλά η κάλυψη των μη λειτουργικών απαιτήσεων βρίσκεται ακόμη σε βρεφικό στάδιο. Στα πλαίσια αυτής της διπλωματικής εργασίας αναπτύσσονται τρόποι κάλυψης και μη λειτουργικών απαιτήσεων. Ένα πολύ σημαντικό κομμάτι ενός συστήματος, πέρα από τις λειτουργικές απαιτήσεις, είναι οι μη λειτουργικές του απαιτήσεις. Ένα σύστημα που ικανοποιεί τις ΛΑ του έχει πετύχει τον στόχο που ορίστηκε κατά τη δημιουργία; Όχι κατ ανάγκη. Αν το σύστημα δεν ικανοποιεί κάποιες ΜΛΑ, ενώ ικανοποιεί όλες τις ΛΑ, τότε μπορεί να χαρακτηριστεί από αναξιόπιστο έως και ως μη λειτουργικό. Οι ΜΛΑ, εξ ορισμού, χρησιμοποιούνται ως κριτήρια για την φερεγγυότητα και την αποτελεσματικότητα του συστήματος σε διάφορους κλάδους. Αν σκεφτεί κανείς ένα RESTful API που χρησιμοποιείται για τραπεζικές συναλλαγές, το οποίο ικανοποιεί όλες τις ΛΑ του αλλά δεν ικανοποιεί κάποιες ΜΛΑ, όπως αυτές της ελεγχόμενης προσβασιμότητας, της διαθεσιμότητας ή της ανάκτησης δεδομένων σε περίπτωση σφαλμάτων, τότε μπορεί εύκολα να φτάσει στο συμπέρασμα ότι ένα τέτοιο σύστημα θα ήταν άχρηστο. Αν κάποιος ήξερε ότι υπάρχει πιθανότητα τα προσωπικά του δεδομένα (χρήματα στον λογαριασμό, κινήσεις κλπ) να είναι διαθέσιμα σε άλλους χρήστες, δεν θα χρησιμοποιούσε το σύστημα. Στόχος της διπλωματικής αυτής, είναι η δημιουργία μίας επέκτασης σε ένα ήδη υπάρχον σύστημα αυτόματης παραγωγής κώδικα, έτσι ώστε το παραγόμενο σύστημα, με χρήση προτύπων σχεδίασης, να ικανοποιεί και μη λειτουργικές απαιτήσεις λογισμικού. Όταν ο στόχος αυτός επιτευχθεί, τα παραγόμενα συστήματα, εφόσον ικανοποιούν τις ΜΛΑ όπως για παράδειγμα η επεκτασιμότητα, η εύκολη τροποποίηση κώδικα, η διατηρησιμότητα, η καλύτερη συμβατότητα κλπ, γίνονται πιο φερέγγυα και κανείς δεν θα μπορεί να αμφισβητήσει την αποτελεσματικότητα και την αξιοπιστία τους. 1.2 Διάρθρωση του εγγράφου Στο κεφάλαιο αυτό παρουσιάζεται περιληπτικά το αντικείμενο της διπλωματικής καθώς και η το περιεχόμενο του εγγράφου. Στο δεύτερο κεφάλαιο παρουσιάζεται ένα βασικό θεωρητικό υπόβαθρο το οποίο βοηθάει σε έναν α- ναγνώστη που έχει τις βασικές γνώσεις προγραμματισμού να κατανοήσει στοιχειωδώς τα θέματα που πραγματεύεται η παρούσα διπλωματική καθώς επίσης και τις τεχνολογίες που χρησιμοποιούνται για την επίτευξη των στόχων της. Πιο συγκεκριμένα: Αναλύεται αναγκαιότητα και η φιλοσοφία πίσω από την πιο σύγχρονη τεχνική που ακολουθείται στους κλάδους της επιστήμης της τεχνολογίας λογισμικού. Παρουσιάζονται οι βασικές έννοιες των διαδικτυακών εφαρμογών. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

16 Αναλύεται η αρχιτεκτονική REST και το μοντέλο ωριμότητας του Richardson. Παρουσιάζεται μια θεωρητική προσέγγιση για τις μη λειτουργικές απαιτήσεις συστήματος λογισμικού. Παρουσιάζονται τα βασικότερα πρότυπα σχεδίασης και αναλύονται αυτά που θα χρησιμοποιηθούν στην υλοποίηση της διπλωματικής. Επεξηγείται η προσέγγιση του μοντελοστραφούς προγραμματισμού και της μοντελοστραφούς αρχιτεκτονικής. Γίνεται μια σύντομη αναφορά στις τεχνολογίες που χρησιμοποιήθηκαν. Στο τρίτο κεφάλαιο παρουσιάζονται οι πιο σύγχρονες και επιτυχημένες τεχνολογίες για την αυτοματοποιημένη ανάπτυξη διαδικτυακών εφαρμογών REST με ή χωρίς τη χρήση μοντελοστραφών προσεγγίσεων, πλεονεκτήματα και σημεία στα οποία υστερεί η κάθε μία. Στο τέταρτο κεφάλαιο γίνεται παρουσίαση της μεθοδολογίας που ακολουθήθηκε για την επίτευξη των στόχων της διπλωματικής. Παρουσιάζεται το εργαλείο στο οποίο υλοποιείται η επέκταση που προτείνεται, η μορφή της επέκτασης και όλες οι απαραίτητες πληροφορίες για την πλήρη κατανόηση της. Περιγράφονται ε- πίσης οι λόγοι για τους οποίους επιλέχθηκαν οι προσεγγίσεις που επιλέχθηκαν, τα μεταμοντέλα που αναπτύχθηκαν, οι μετασχηματισμοί που υλοποιήθηκαν και το τελικό αποτέλεσμα που παράγεται από την επέκταση που υλοποιήθηκε. Στο πέμπτο κεφάλαιο παρουσιάζεται η εκτέλεση της επέκτασης που υλοποιήθηκε από την εφαρμογή πάνω σε ένα ήδη υπάρχον σύστημα παράδειγμα και ο έλεγχος της υπηρεσίας που παράχθηκε. Στο τελευταίο κεφάλαιο γίνεται μια εκτίμηση για τα αποτελέσματα της διπλωματικής και παρουσιάζονται πιθανές επεκτάσεις που μπορούν να υλοποιηθούν στο μέλλον. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

17 2. Υπόβαθρο ΜΟΝΤΕΛΟΠΟΙΗΣΗ ΜΗ ΛΕΙΤΟΥΡΓΙΚΩΝ ΑΠΑΙΤΗΣΕΩΝ ΛΟΓΙΣΜΙΚΟΥ ΣΕ ΜΟΝΤΕΛΑ ΔΙΑΔΙΚΤΥΑΚΩΝ ΣΥΣΤΗΜΑΤΩΝ REST 2.1 Τεχνολογία Λογισμικού και η σημασία της Είναι πλέον καθολικώς αποδεκτό και πλήρως κατανοητό πως ο κλάδος της τεχνολογίας, της επικοινωνίας και των πληροφοριών εξελίσσεται με ραγδαίους ρυθμούς. Αυτό οφείλεται στο γεγονός ότι η κάλυψη των περισσότερων φυσικών αναγκών εξαρτάται κυρίως από τεχνολογικά επιτεύγματα. Οι κλάδοι της υγείας, της βιομηχανίας, της διατροφής, της μαζικής μετακίνησης, της επικοινωνίας και όχι μόνο, βασίζονται σε προηγμένα τεχνολογικά προϊόντα, προϊόντα τα οποία για τη σχεδίασή τους, την υλοποίησή τους και σε πολλές περιπτώσεις ακόμα και για τη χρήση τους, απαιτούν καταλλήλως σχεδιασμένο λογισμικό. Καταλαβαίνει κανείς λοιπόν, ότι τη ραγδαία εξέλιξη της τεχνολογίας ακολουθεί η συνεχώς αυξανόμενη ανάγκη για λογισμικό. Η τεχνολογία λογισμικού (software engineering) είναι ο τομέας που ασχολείται με την ανάπτυξη μεθόδων και διαδικασιών με σκοπό την ανάπτυξη γρήγορου, φθηνού, αξιόπιστου και ποιοτικού λογισμικού που επιλύει όλο και πιο περίπλοκα προβλήματα. Ορίζεται ως η συστηματική προσέγγιση της ανάλυσης, σχεδιασμού, εκτίμησης, εκτέλεσης, δοκιμής και συντήρησης του λογισμικού με σκοπό την ταχύτερη, φθηνότερη και πιο αξιόπιστη ανάπτυξή του. Για να αντιληφθεί κανείς τη δυσκολία της επιστήμης της τεχνολογίας λογισμικού θα πρέπει να λάβει υπόψιν του ότι ένα λογισμικό δεν αποτελείται από ένα πρόγραμμα. Ως λογισμικό ορίζεται το σύνολο των προγραμμάτων, διαδικασιών, κανόνων, δεδομένων και η αντίστοιχη τεκμηρίωσή τους για τη σωστή διασύνδεσή τους και τη σωστή λειτουργία τους [1] [5]. Κάποιοι από τους πιο σημαντικούς λόγους που οδήγησαν στην ανάγκη για την ανάπτυξη της επιστήμης της τεχνολογίας λογισμικού καταγράφηκαν από τον Brooks, μέντορα της επιστήμης αυτής [3]: To λογισμικό είναι πολύπλοκο. Τα περισσότερα σύγχρονα υπολογιστικά συστήματα αποτελούνται από πολλές μονάδες, κάθε μία από τις οποίες χρειάζεται δικό της λογισμικό για να λειτουργήσει αξιόπιστα. Αυτό σημαίνει ότι ένα σύστημα λογισμικού που αποτελείται από πολλά μικρότερα έχει τεράστια πολυπλοκότητα. Το ίδιο ισχύει και για τα προβλήματα τα οποία χρίζουν λύση μέσω της χρήσης λογισμικού. Είναι προβλήματα που ο άνθρωπος δεν μπορεί να τα λύσει με χαρτί και με μολύβι και χρειάζονται συστήματα που εκτελούν πολύπλοκους μηχανισμούς και μαθηματικές πράξεις για τη λύση τους. Επομένως, η πολυπλοκότητα του λογισμικού που θα αναπτυχθεί είναι άρρηκτα συνδεδεμένη με το πρόβλημα που στοχεύει να επιλύσει και με την πλατφόρμα στην οποία θα εφαρμοστεί. Το λογισμικό είναι αυθαίρετο. Δεν έχει ύλη και είναι ένα σύνολο αφηρημένων οντοτήτων, που όμως εκφράζονται και αναπαρίστανται σε γλώσσα. Το λογισμικό πρέπει να μπορεί να εξελίσσεται και να προσαρμόζεται στις τεχνολογικές αλλαγές. Ένα σύστημα λογισμικού στατικό, που δεν μπορεί να μεταβληθεί σύμφωνα με τις μεταβαλλόμενες ανάγκες της τεχνολογίας που το χρησιμοποιεί είναι κακή λύση, διότι χρειάζεται σύντομη αντικατάσταση. Πολλά ήταν τα μοντέλα ανάπτυξης λογισμικού που δημιουργήθηκαν και δοκιμάστηκαν στα πλαίσια της επιστήμης της τεχνολογίας λογισμικού. Κοινό χαρακτηριστικό όλων είναι η ανάπτυξη του συστήματος σε διακριτά, καλώς ορισμένα στάδια, κάθε στάδιο εκ των οποίων έχει συγκεκριμένη είσοδο και έξοδο. Το πιο διάσημο πρότυπο μεθοδολογία παραγωγής κώδικα είναι το SDLC (Software Development Life Cycle) [2][4]. Αναπτύχθηκε τη δεκαετία του 1960 με σκοπό τη δημιουργία συστημάτων μεγάλης κλίμακας. Οι μηχανικοί λογισμικού και οι προγραμματιστές το χρησιμοποιούν με σκοπό να σχεδιάσουν, να υλοποιήσουν, να ελέγξουν και να παραδώσουν μεγάλα έργα λογισμικού. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

18 Προγραμματισμός Συντήρηση Ανάλυση Testing και Ενσωμάτωση Σχεδίαση Υλοποίηση Εικόνα 1. SDLC - Software Development Life Cycle - Ο κύκλος της ζωής του λογισμικού. Τα στάδια του SDLC, όπως διακρίνονται και στην Εικόνα 1, είναι τα εξής: 1. Προγραμματισμός: Το στάδιο αυτό περιλαμβάνει τη συλλογή της απαραίτητης πληροφορίας για τη συγγραφή των λειτουργικών και των μη λειτουργικών απαιτήσεων και είναι το πιο βασικό κομμάτι του SDLC. Εκτελείται από την ομάδα ανάπτυξης λογισμικού σε συνεργασία με πελάτες, αναλυτές, ερευνητές κλπ. Μόλις οριστούν σαφώς οι λειτουργικές και οι μη λειτουργικές απαιτήσεις του συστήματος που θα αναπτυχθεί, η ομάδα ανάπτυξης μπορεί να χρησιμοποιήσει όλη την παραγόμενη πληροφορία για να κάνει τον βασικό προγραμματισμό του έργου, να εκτιμήσει κόστη και ρίσκα. 2. Ανάλυση: To στάδιο της ανάλυσης περιλαμβάνει τον καθορισμό των στόχων του έργου, τις ενέργειες που πρέπει να γίνουν για τη σωστή υλοποίησή του και τη συγγραφή του εγγράφου προδιαγραφών του έργου (Software requirement specification - SRS). Μόλις το έργο εγκριθεί, ξεκινάει η σχεδίασή του του. 3. Σχεδίαση: Κατά το στάδιο της σχεδίασης, η ομάδα ανάπτυξης λογισμικού χρησιμοποιεί το έγγραφο SRS για να σχεδιάσει τη βέλτιστη αρχιτεκτονική του συστήματος. Αποτέλεσμα του σταδίου αυτού είναι η παραγωγή του εγγράφου σχεδίασης (DDS Design Document Specification), για τη συγγραφή του ο- ποίου λαμβάνονται υπόψιν και όλοι οι περιορισμοί που μπορεί να επιφέρουν αποτυχία οι ΜΛΑ του συστήματος. Στο έγγραφο παρουσιάζονται αρχιτεκτονικές δομές του συστήματος, η επικοινωνία και οι διεπαφές του, η ροή δεδομένων, εξωτερικά συστήματα με τα οποία συνδέεται το σύστημα, επιχειρησιακοί κανόνες και mockups, διαγράμματα ροής κλπ. Οι προγραμματιστές και οι μηχανικοί λογισμικού πρέπει να μπορούν με τη χρήση του εγγράφου αυτού να προχωρήσουν στην υλοποίηση του συστήματος. 4. Υλοποίηση: Το στάδιο της υλοποίησης αποτελεί την έναρξη της διαδικασίας παραγωγής του συστήματος. Η ομάδα ανάπτυξης λογισμικού, λαμβάνοντας υπόψιν το DDS προχωράει στην παραγωγή κομματιών κώδικα που θα συνθέσουν το λογισμικό. 5. Testing και Ενσωμάτωση: To στάδιο αυτό περιλαμβάνει τη σύνδεση των διαφορετικών κομματικών του συστήματος του λογισμικού και του ελέγχου λειτουργικότητάς του. Ελέγχεται πόσο το παραχθέν λογισμικό επιτυγχάνει τους στόχους για τους οποίους αναπτύχθηκε, αν υπάρχουν σφάλματα κατά την εκτέλεση, αν είναι αξιόπιστο και ποια είναι η συμπεριφορά του σε κρίσιμες συνθήκες εκτέλεσης. Αν το έργο περάσει με επιτυχία όλους τους απαραίτητους ελέγχους, παραδίδεται στον πελάτη. 6. Συντήρηση: Το τελευταίο στάδιο στον κύκλο της ζωής ενός έργου λογισμικού είναι το στάδιο της συντήρησης. Όταν το λογισμικό παραδοθεί στον πελάτη, εκτελούνται ενέργειες συντήρησης, βελτίωσης και μερικές φορές παραμετροποίησης με στόχο τη διατήρηση της ποιότητας. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

19 Τα οφέλη που εισάγει η χρήση της πιο βασικής διαδικασίας ανάπτυξης λογισμικού που εισήγαγε η επιστήμη της τεχνολογίας λογισμικού, η χρήση του SDLC, παρατηρούνται σε όλους τους τύπους οργανισμών που παράγουν λογισμικό. Αν το πρότυπο ακολουθηθεί σωστά, τότε μειώνεται πολυπλοκότητα παραγωγής του έργου, αποφεύγονται σφάλματα σχεδίασης, το τελικό έργο είναι σύμφωνο με τις αρχικές προδιαγραφές και λόγω της συντήρησης παραμένει πάντα ενημερωμένο και σύγχρονο. 2.2 Διαδικτυακές εφαρμογές, διαδικτυακές υπηρεσίες και Web APIs Από πολλούς το διαδίκτυο χαρακτηρίζεται ως η πιο σημαντική ανθρώπινη εφεύρεση του 20 ου αιώνα. Παρόλο που ο πρωταρχικός του στόχος ήταν ο διαμοιρασμός εγγράφων, τις τελευταίες δεκαετίες αναδείχθηκε ως μέσο διασύνδεσης διαφορετικών εφαρμογών, γεγονός στο οποίο οδήγησαν η ευρεία χρήση και υποστήριξη του, τα καλώς ορισμένα πρωτόκολλα που συστάθηκαν για τη χρήση του (HTTP) καθώς και η ευρεία χρήση κοινών μορφών αναπαράστασης HTML. Έτσι, το διαδίκτυο μεταμορφώθηκε σε μια παγκόσμια πλατφόρμα α- νταλλαγής και διασύνδεσης δεδομένων και πληροφοριών για ένα οικοσύστημα υπηρεσιών που εκτελούνται στο διαδίκτυο, τις διαδικτυακές εφαρμογές. Ως διαδικτυακή υπηρεσία, το WWW Consortium ορίζει ένα σύστημα λογισμικού σχεδιασμένο με στόχο την υποστήριξη της διαλειτουργικής αλληλεπίδρασης μηχανών μέσω ενός δικτύου. Μια διαδικτυακή υπηρεσία χρειάζεται κάποια διεπαφή για να μπορεί να επικοινωνεί με άλλες υπηρεσίες. Ένα Web APΙ είναι μια διεπαφή η οποία χρησιμοποιείται για γι αυτούς τους σκοπούς. Τα περισσότερα Web APIs βασίζονται σε πρωτόκολλα επικοινωνίας για την επίτευξη της διασύνδεσης μεταξύ των υπηρεσιών. Το πιο σύνηθες είναι το πρωτόκολλο HTTP. Το πρωτόκολλο HTTP (Hypertext Transfer Protocol) είναι ένα σετ από κανόνες που επιτρέπει το διαμοιρασμό πληροφορίας ανάμεσα σε διαδικτυακές εφαρμογές και υπηρεσίες [6]. Βασίζεται στην ιδέα ότι τα δεδομένα που διαμοιράζονται είναι έγγραφα υπερκείμενα, στα οποία υπάρχουν νοητοί σύνδεσμοι (hypermedia links). σε άλλα έγγραφα υπερκείμενα. Οι κανόνες του πρωτοκόλλου ορίζουν μια μεθοδολογία ερωτήσεων και απαντήσεων από πελάτες και εξυπηρετητές διαδικτυακών εφαρμογών. Τα ερωτήματα και οι αποκρίσεις έχουν συγκεκριμένη δομή και αποτελούνται από το ομοιόμορφο αναγνωριστικό πόρου (URI), την επικεφαλίδα, το σώμα του μηνύματος και τους κωδικούς απόκρισης. Στα επόμενα κεφάλαια παρουσιάζονται τα οι βασικότερες πληροφορίες για την κατανόηση διαδικτυακών εφαρμογών REST. Στον τομέα της επιστήμης των υπολογιστών, ως REST αναφέρεται το αρκτικόλεξο του ό- ρου Representational State Transfer (Μεταφορά Αναπαραστάσεων Κατάστασης) και ορίζει έναν τύπο αρχιτεκτονικής διαδικτυακών υπηρεσιών. To REST παρέχει ένα σετ από περιορισμούς και οδηγίες για τη σχεδίαση διανεμημένων υπηρεσιών (κυρίως web) με στόχο την καλύτερη απόδοση και μια περισσότερο διατηρήσιμη και επεκτάσιμη αρχιτεκτονική. 2.3 REST και Richardson s Maturity Model Τα συστήματα που τηρούν τις απαιτήσεις που ορίζουν τα πρότυπα του REST καλούνται RESTful. Γενικά, τα συστήματα αυτά στηρίζουν την επικοινωνία τους στο πρωτόκολλο HTTP, δηλαδή στις μεθόδους HTTP (GET, POST, PUT, PATCH, DELETE κλπ.), τις οποίες χρησιμοποιούν οι φυλλομετρητές του διαδικτύου για να ανακτήσουν αναπαραστάσεις πόρων (resource) άρα και ιστοσελίδες που αποτελούνται από αυτές [7]. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

20 2.3.1 Πόρος ΜΟΝΤΕΛΟΠΟΙΗΣΗ ΜΗ ΛΕΙΤΟΥΡΓΙΚΩΝ ΑΠΑΙΤΗΣΕΩΝ ΛΟΓΙΣΜΙΚΟΥ ΣΕ ΜΟΝΤΕΛΑ ΔΙΑΔΙΚΤΥΑΚΩΝ ΣΥΣΤΗΜΑΤΩΝ REST Πόροι (resources) είναι οι θεμέλιοι λίθοι όλων των web-based συστημάτων, σε βαθμό τέτοιο ώστε το Web να αναφέρεται συχνά ως resource-oriented, δηλαδή κατευθυνόμενο από πόρους. Πόρος είναι οτιδήποτε βρίσκεται στο Web, από ένα απλό έγγραφο ή ένα βίντεο κλιπ, μέχρι και μια επιχειρησιακή διαδικασία ή συσκευή. Ως πόρος θα μπορούσε επίσης να οριστεί οποιοδήποτε αντικείμενο/μέσο χρειάζεται κάποιος για την επίτευξη ενός στόχου. Μπορεί να φαίνεται αδύνατο για πολλά αντικείμενα του πραγματικού κόσμου να αναπαρασταθούν ως πόροι στο Web. Αυτό όμως είναι εύκολο αν γίνει μια αφαίρεση των χρήσιμων πληροφοριών και η αφαίρεση αυτή αναπαρασταθεί στον ψηφιακό κόσμο. Επομένως, οποιοδήποτε φυσικό, υλικό ή άυλο αντικείμενο ή έννοια μπορεί να αναπαρασταθεί ως πόρος στο Web. Για να γίνει χρήση ενός πόρου χρειάζονται τρόποι αναγνώρισής του και διαχείρισής του. Το Web παρέχει το URI (Uniform Resource Identifier Ενιαίο Αναγνωστικό Πόρων) για τους σκοπούς αυτούς. Ένα URI χαρακτηρίζει μοναδικά έναν πόρο, ενώ ταυτόχρονα παρέχει και μια διεύθυνση για τον πόρο αυτόν, μια δυνατότητα δηλαδή μεταχείρισης του πόρου μέσω ενός πρωτοκόλλου, όπως πχ το HTTP. H σχέση μεταξύ των πόρων και των αναπαραστάσεών τους είναι ένα-προς-πολλά. Ένα URI αναπαριστά μόνον έναν πόρο, αλλά ένας πόρος μπορεί να έχει πολλές και διαφορετικές αναπαραστάσεις. Αυτό βοηθάει στην ανάγκη της αναπαράστασης αντικειμένων με παραπάνω από έναν τρόπο. Για παράδειγμα, η αρχική σελίδα του προφίλ ενός χρήστη της υπηρεσίας Facebook (η οποία προφανώς και αποτελεί έναν πόρο) μπορεί να προσπελασθεί είτε με είτε με URI. Εκτός από τα URI υπάρχουν και άλλες μορφές αναγνώρισης και διευθυνσιοδότησης πόρων, αλλά η περεταίρω παρουσίαση λεπτομερειών ξεφεύγει από τους στόχους του εγγράφου αυτού Αναπαράσταση Οι πόροι πρέπει να έχουν τουλάχιστον ένα αναγνωριστικό για να είναι προσπελάσιμοι. Κάθε αναγνωριστικό είναι άρρηκτα συνδεδεμένο με μία ή παραπάνω αναπαραστάσεις. Μια μορφή αναπαράστασης μέσου (media format), απεικονίζει έναν μετασχηματισμό ή μια όψη της κατάστασης της αναπαράστασης του πόρου σε μία συγκεκριμένη χρονική στιγμή. Χαρακτηριστικές μορφές αναπαράστασης μέσων είναι τα αρχεία XML, JSON, CSVs, MP3, JPEG αλλά ακόμα και το απλό κείμενο. Οι αναπαραστάσεις αποτελούν στην ουσία ένα δομημένο έγγραφο πληροφορίας που χαρακτηρίζει έως έναν βαθμό έναν πόρο. Για παράδειγμα, μια αναπαράσταση της πληροφορίας του πόρου καφέ θα μπορούσε να αποτελεί το παρακάτω κείμενο δομημένο σε μορφή XML: <coffee> <name>capuccino</name> <type>hot</type> <num_of_shots>2</num_of_shots> <crema>yes</crema> <cup_type>medium</cup_type> <coffee> H παραπάνω αναπαράσταση πληροφορεί ότι ο καφές με το όνομα Capuccino σερβίρεται ζεστός, περιέχει δύο δόσεις εσπρέσο, έχει αφρόγαλα και σερβίρεται σε μεσαίου μέγεθος ποτήρι. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

21 H προσπέλαση σε έναν πόρο κατευθύνεται από τις αναπαραστάσεις του. Γι αυτόν τον λόγο, όλα τα συστατικά στοιχεία του Web ανταλλάσσουν αναπαραστάσεις. Ποτέ δεν έχουν πρόσβαση στον ίδιο τον πόρο άμεσα το Web δεν υποστηρίζει δείκτες (pointers). Με τον τρόπο αυτό επιτυγχάνεται η χαλαρή σύζευξη ανάμεσα στα backend συστήματα και στις εφαρμογές που τα χρησιμοποιούν. Διευκολύνεται επίσης η επεκτασιμότητα μιας υπηρεσίας. Ακόμα ένας λόγος για τον οποίο είναι επιθυμητή η παρουσία των αναπαραστάσεων και η προσπέλαση των πόρων με τη χρήση τους, είναι η ασφάλεια. Χρησιμοποιώντας αναπαραστάσεις μπορούν να παρέχονται διαφορετικά δικαιώματα πρόσβασης σε διαφορετικές εφαρμογές. Στο Web δεν υπάρχει κανόνας που να ορίζει τους τύπους των αναπαραστάσεων (representation formats media types) που θα χρησιμοποιηθούν. O τύπος επιλέγεται έτσι ώστε να ικανοποιεί τις ανάγκες της υπηρεσίας που χρειάζεται πρόσβαση στον πόρο. Παρόλα αυτά συνηθίζεται ο συνδυασμός που περιλαμβάνει HTML για δομημένα έγγραφα, PNG και JPEG για εικόνες, MPEG για βίντεο και XML και JSON για δεδομένα. Το σημαντικότερο σημείο που πρέπει να γίνει κατανοητό είναι το γεγονός ότι το Web δεν χρησιμοποιείται μόνον για επικοινωνία ανθρώπων και υπολογιστών, αλλά χρησιμοποιείται (κυρίως) για επικοινωνία υπολογιστών με άλλους υπολογιστές. Έτσι, η κατάλληλη επιλογή αναπαραστάσεων πόρων είναι σημαντική για την εύρυθμη λειτουργεία όχι μόνον των ιστοσελίδων, αλλά και όλων των υπηρεσιών που χρησιμοποιούν το Web σαν εργαλείο. Η παραπάνω ανάγκη ικανοποιείται καθώς με το ίδιο αναγνωριστικό (URI), ένας υπολογιστής (μια υπηρεσία) μπορεί να έχει πρόσβαση σε διάφορες μορφές αναπαραστάσεων του ίδιου πόρου (αν φυσικά το σύστημα του επιτρέπει) Πως πραγματοποιείται η επικοινωνία στο Web? Στο Web, οι αναπαραστάσεις καθορίζουν το ποιος επιδρά σε τι. Υπάρχει η ανάγκη όμως κάποιος να καθορίσει τον τρόπο με τον οποίο γίνεται η επίδραση. Ο καθορισμός αυτός πραγματοποιείται με τη χρήση των μεθόδων HTTP (HTTP methods). O όρος Ενιαία Διεπαφή (uniform interface), χρησιμοποιείται για να περιγράψει πως ένας μικρός αριθμός από καλώς ορισμένα ρήματα/μεθόδους μπορεί να επαρκεί για να καλύψει τις ανάγκες των πιο σύνθετων διανεμημένων συστημάτων. Οι μέθοδοι αυτές είναι οι GET, POST, PUT, DELETE, OP- TIONS, HEAD, TRACE, CONNECT και PATCH. Το πρωτόκολλο HTTP, εκτός από τα ρήματά αυτά, ορίζει και μια συλλογή από μοναδικούς κωδικούς-απαντήσεις, όπως το «404 Not Found» ή το «201 Created». O συνδυασμός των μεθόδων και των κωδικών αρκεί για τη διαχείριση των αναπαραστάσεων στο Web και άρα την επικοινωνία των υπολογιστών/υπηρεσιών [8] [10]. Αναπαραστάσεις, αναγνωριστικά και δράσεις είναι τα βασικά υλικά της αλληλεπίδρασης με χρήση πόρων. Στο παρακάτω σχήμα φαίνεται πως μπορεί να ζητηθεί και να παραδοθεί μια αναπαράσταση σε XML: ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

22 Εικόνα 2. Παράδειγμα επικοινωνίας στο Web. O πράσινος agent χρησιμοποιεί τη μέθοδο GET για την ανάκτηση της αναπαράστασης Resource1 του πόρου resource. Ο μπλε agent αναγνωρίζει το αίτημα του πράσινου και απαντάει με τον κωδικό «200 ΟΚ», δηλαδή ότι η αναπαράσταση υπάρχει καλώς, και την αναπαράσταση του πόρου Ιδιότητες της αρχιτεκτονική REST Το μοντέλο ωρίμανσης του Richardson Ο Roy Fielding ήταν ο πρώτος που αναφέρθηκε στον όρο REST, ως μια συντομογραφία της αρχιτεκτονικής που πρότεινε στη διδακτορική του διατριβή, τη Representational State Transfer. Η διατριβή αυτή περιγράφει πως χτίζονται και διατηρούνται διανεμημένα συστήματα όπως το Web. Το REST περιγράφει το Web ως ένα διανεμημένο σύστημα από hypermedia (πολυμέσα που χρησιμοποιούν υπερσυνδέσμους), των οποίων οι συνδεδεμένοι πόροι επικοινωνούν ανταλλάσσοντας αναπαραστάσεις της κατάστασής τους [9] Υπερμέσα ( Hypermedia ) Η εισαγωγή του όρου hypermedia είναι αυτή που καθορίζει τελικά ότι μια υπηρεσία Web είναι RESTful. O Roy συνιστά ότι το Web είναι μια πλατφόρμα εφαρμογή, η οποία, αν χρησιμοποιήσει την αρχιτεκτονική REST, αν οδηγηθεί δηλαδή από συγκεκριμένες αρχές, θα έχει ως αποτέλεσμα εφαρμογές που μπορούν να κλιμακωθούν προσαυξηθούν εύκολα, θα είναι χαλαρά συζευγμένες και θα εγκαθιδρύουν λειτουργικότητα που δεν θα περιορίζεται από τα σύνορα μιας υπηρεσίας. Η ιδέα του αν και απλή είναι πανίσχυρη. Μια εφαρμογή θα προχωράει σε επόμενη κατάσταση όπως μια μηχανή πεπερασμένων καταστάσεων. Η διαφορά με τις παραδοσιακές μηχανές πεπερασμένων καταστάσεων είναι ότι οι πιθανές διαδρομές και οι νέες καταστάσεις δεν υπάρχουν κάπου προ-ορισμένες. Αντιθέτως, καθώς μια εφαρμογή θα φτάνει σε μια νέα κατάσταση, νέες καταστάσεις και διαδρομές θα δημιουργούνται. Παράδειγμα το «Related Video» που παρέχει η υπηρεσία YouTube της Google. Ανάλογα το βίντεο (media) που αναπαράγονται τη συγκεκριμένη στιγμή που το βλέπει ο χρήστης, διαφορετικά «related videos» προκύπτουν, δίνοντας στον χρήστη τη δυνατότητα να επιλέγει διαφορετικό βίντεο ανάλογα με αυτό που έβλεπε πριν. Στα συστήματα υπερμέσων, οι καταστάσεις των εφαρμογών απεικονίζονται σε αναπαραστάσεις μοναδικών αναγνωριστικών URIs. Τα αναγνωριστικά αυτά των καταστάσεων στις οποίες μπορεί να μεταβεί το σύστημα εμπεριέχονται στην αναπαράσταση της τωρινής κατάστασης. Στην παρακάτω εικόνα παρουσιάζεται ένα παράδειγμα για την καλύτερη κατανόηση: ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

23 URIs υπηρεσιών και πόρων Παράδειγμαμεταβάσεων Εικόνα 3. Παράδειγμα μεταβάσεων στο Web. Τα βέλη εκπροσωπούν τις μεταβάσεις (transitions) και τα κουτιά τις αναπαραστάσεις των υπερμέσων. Η εφαρμογή ξεκινάει ακολουθώντας τη μετάβαση στην κατάσταση που αναγνωρίζεται από το URI (6). Στην κόκκινη αναπαράσταση περιέχονται URIs που αντιστοιχούν σε 3 είναι πλέον πιθανές μεταβάσεις. Η εφαρμογή επιλέγει τη μετάβαση προς την κατάσταση που αναγνωρίζεται από το URI (3), το οποίο οδηγεί στην πράσινη κατάσταση. Η εφαρμογή συνεχίζει έτσι, μεταβαίνοντας από μια κατάσταση σε μία άλλη σύμφωνα με τα εμπεριεχόμενα στην αναπαράσταση της κατάστασης URIs. Το πιο ευρέως διαδεδομένο μοντέλο που ακολουθείται για την ανάπτυξη ενός συστήματος REST (και ταυτόχρονα αυτό που χρησιμοποιείται στη συνέχεια) είναι το μοντέλο ωρίμανσης του Leonard Richardson (RMM) [11]. Το μοντέλο αυτό καθορίζει στην ουσία τα επίπεδα τα οποία πρέπει να ακολουθήσει κανείς για να χτίσει μια RESTful υπηρεσία, προσθέτοντας κάθε φορά ένα επίπεδο το οποίο καλύπτει κάποιους από τους περιορισμούς. Το μοντέλο ωρίμανσης του Richardson RMM ορίζει τέσσερα επίπεδα, όπως αυτά φαίνονται στο παρακάτω σχήμα: Level 0: The Swamp of POX Level 1: Resources Level 2: HTTP Verbs Level 3: Hypermedia Controls Glory of REST Εικόνα 4. To μοντέλο ωριμότητας του Richardson - RMM ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

24 Επίπεδο 0: O βάλτος του POX (Plain Old XML) Το κατώτερο επίπεδο ωρίμανσης μιας υπηρεσίας web ορίζει ένα σύστημα μεταφοράς για απομακρυσμένες αλληλεπιδράσεις με χρήση του πρωτοκόλλου HTTP, χωρίς όμως να χρησιμοποιούνται καθόλου μηχανισμοί του web (πόροι, αναπαραστάσεις, δράσεις κλπ). Στην ουσία δημιουργείται ένας μηχανισμός tunneling (δεν υπάρχει ακριβής μετάφραση, ας πούμε επικοινωνίας) μέσα από τον οποίο ανταλλάσσονται αιτήσεις (συνήθως POST) μέσω ενός URI, πχ profilebook.org/users, και υπάρχει απόκριση που παραδίδεται συνήθως σε μορφή XML. Έστω ότι κάποιος θέλει να ζητήσει από μία υπηρεσία νοσοκομείου αυτόματων ραντεβού να του κλείσει ένα ραντεβού στις 3/12/2015 με τον γιατρό Μάριο Παπαθανασίου. Η αίτηση που θα χρειαζόταν να κάνει είναι σε απλή XML: POST /appointmentservice HTTP/1.1 [ ] <openappointmentrequest date= doctor= mpapathanasiou /> Τότε το σύστημα, αν όλα πήγαιναν καλώς, θα αποκρινόταν με έναν κωδικό που δείχνει ότι το request παραλήφθηκε και την απάντησή του: HTTP/ ok [ ] <openappointmentlist> <appointment start= 1400 end= 1450 > <doctor name= mpapathanasiou /> <room name= A21 /> <code id= 123 /> <appointment/> <appointment start= 1500 end= 1550 > <doctor name= mpapathanasiou /> <room name= A21 /> <code id= 124 /> <appointment/> </openappointmentlist> Σε αυτό το σημείο είναι σημαντικό να φανεί πως θα έκλεινε κάποιος ραντεβού. POST /appointmentservice HTTP/1.1 [ ] <appointmentrequest> <appointment doctor= mpapathanasiou start= 1400 end= 1450 /> <patient id= mgeorgiou /> </appointmentrequest> To παραπάνω αποτελεί χαρακτηριστικό παράδειγμα μιας διαδικασίας τύπου RPC (Remote Procedure Call). Είναι στην ουσία ανταλλαγή αρχείων XML πέρα δώθε Επίπεδο 1: Πόροι Το πρώτο βήμα στο να δημιουργηθεί επιτυχώς μια υπηρεσία REST σύμφωνα με το RMM, είναι η εισαγωγή της έννοιας του πόρου. Αντί να γίνεται κάποιο αίτημα στο ίδιο endpoint (URL), πλέον αρχίζει ο διαχωρισμός ανάμεσα στους διάφορους πόρους. Αυτό σημαίνει ότι για κάθε διαφορετικό πόρο της υπηρεσίας το URI συγκεκριμενοποιείται για τον πόρο αυτό. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

25 Αν χρησιμοποιήσουμε το ίδιο παράδειγμα με πριν, εφόσον κάποιος θέλει να κλείσει ραντεβού με τον συγκεκριμένο γιατρό «Μάριο Παπαθανασίου», τότε η αίτηση που θα έκανε στο σύστημα θα ήταν στοχευμένη στον πόρο αυτόν, δηλαδή: POST /doctors/mpapathanasioy HTTP/1.1 [ ] <openappointmentrequest date= /> Τότε το σύστημα, αν όλα πήγαιναν καλώς, θα αποκρινόταν με έναν κωδικό που δείχνει ότι το αίτημα παραλήφθηκε και την απάντησή του θα ήταν: HTTP/ ok [ ] <openappointmentlist> <appointment id= 123 doctor= mpapathanasiou room= A21 start= 1400 end= 1450 /> <appointment id= 124 doctor= mpapathanasiou room= A21 start= 1500 end= 1550 /> <appointment id= 125 doctor= mpapathanasiou room= A21 start= 1600 end= 1650 /> <appointment id= 127 doctor= mpapathanasiou room= A21 start= 1700 end= 1750 /> </openappointmentlist> Σε αυτό το σημείο είναι σημαντικό να φανεί πως θα έκλεινε κάποιος ραντεβού, για να μπορέσει να γίνει αντιληπτή η διαφορά με το επίπεδο 0: POST /appointment/123 HTTP/1.1 [ ] <appointmentrequest> <patient id= mgeorgiou /> </appointmentrequest> Και η απάντηση του server: HTTP/ OK [ ] <appointment> <code id= 123 doctor= mpapathanasiou start= 1400 end= 1450 room= A21 /> <patient id= mgeorgiou /> </appointment> Σε αντίθεση με το επίπεδο 0, στο επίπεδο 1 η κράτηση πραγματοποιείται με μια απλή POST του κωδικού του διαθέσιμου ραντεβού. Από εδώ και πέρα το συγκεκριμένο ραντεβού έχει συγκεκριμενοποιηθεί, έχει γίνει πόρος και μπορεί να προσπελασθεί σαν πόρος με τη χρήση ενός URI όπως Επίπεδο 2: HTTP Verbs Στο επίπεδο 2 υπάρχουν πλέον πολλοί πόροι. Οι υπηρεσίες επιπέδου 2 υποστηρίζουν τη διαχείριση των πόρων με τη χρήση μεθόδων του πρωτοκόλλου HTTP και κωδικών απάντησης πετυχαίνοντας έτσι ένα εύρωστο σύστημα με μεγάλη λειτουργικότητα. Οι μέθοδοι HTTP που χρησιμοποιούνται στα συστήματα τα οποία χαρακτηρίζονται ως RESTful είναι τα: ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

26 Πίνακας 1. Ρήματα HTTP. ΜΟΝΤΕΛΟΠΟΙΗΣΗ ΜΗ ΛΕΙΤΟΥΡΓΙΚΩΝ ΑΠΑΙΤΗΣΕΩΝ ΛΟΓΙΣΜΙΚΟΥ ΣΕ ΜΟΝΤΕΛΑ ΔΙΑΔΙΚΤΥΑΚΩΝ ΣΥΣΤΗΜΑΤΩΝ REST Μέθοδος GET HEAD POST PUT DELETE PATCH OPTIONS CONNECT TRACE Λειτουργικότητα Αιτείται μιας αναπαράστασης ενός συγκεκριμένου πόρου. Μόνο ανακτά δεδομένα και δεν έχει καμία άλλη επίδραση. Χαρακτηρίζεται ως ασφαλής μέθοδος. Όμοια με την GET, με τη διαφορά ότι δεν ζητάει το σώμα της αναπαράστασης, αλλά μόνο τα μεταδεδομένα της. Αιτείται στον server να δεχτεί μια νέα οντότητα ως μια νέα αναπαράσταση ενός συγκεκριμένου πόρου η οποία αναγνωρίζεται από ένα συγκεκριμένο URI. Χρησιμοποιείται συνήθως για τη δημιουργία αναπαραστάσεων πόρων. Αιτείται την αποθήκευση της αποσταλείσας αναπαράστασης υπό το URI που έχει δοθεί. Χρησιμοποιείται συνήθως για ανανέωση (update) και διαγραφή αναπαραστάσεων. Αιτείται τη διαγραφή ενός πόρου. Χρησιμοποιείται για μερική μεταβολή δεδομένων ενός πόρου. Χρησιμοποιείται για να επιστραφούν όλες oι μέθοδοι που υποστηρίζονται από το URI που αποστέλλει ο client. Χρησιμοποιείται για τη δημιουργία σηράγγων κρυπτογράφησης. Χρησιμοποιείται για την λήψη μιας «ηχούς», ενός ιστορικού που δείχνει τις αλλαγές που έγιναν σε έναν πόρο από τον συγκεκριμένο server. Σε συνέχεια του παραδείγματος που παρουσιάστηκε παραπάνω, αν κάποιος ήθελε να μεταβάλει τα στοιχεία του ραντεβού του, θα ζητούσε πρώτα από το σύστημα τη λίστα με τα κλεισμένα ραντεβού στο όνομά του: GET /appointments/mgeorgiou HTTP/1.1 [ ] Με απάντηση του συστήματος: HTTP/ OK [ ] <appointmentlist> <appointment> <code id= 123 doctor= mpapathanasiou start= 1400 end= 1450 room= A21 /> <patient id= mgeorgiou /> <appointment/> </appointmentlist> Έπειτα, για τη μεταβολή των στοιχείων του ραντεβού: PUT /appointment/mgeorgiou/123 HTTP/1.1 [ ] <appointment> <code id= 124 doctor= mpapathanasiou start= 1500 end= 1550 room= A21 /> </appointment> Αν δεν ήταν διαθέσιμη εκείνη η ώρα με εκείνον τον γιατρό, το σύστημα θα μπορούσε να απαντήσει με κώδικα σύγκρουσης και μια λίστα με τις διαθέσιμες ανοικτές ώρες: ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

27 HTTP/ Conflict [ ] <openappointmentlist> <appointment id= 125 doctor= mpapathanasiou room= A21 start= 1600 end= 1650 /> <appointment id= 127 doctor= mpapathanasiou room= A21 start= 1700 end= 1750 /> </openappointmentlist> Επίπεδο 3: Hypermedia Controls Στο τελευταίο επίπεδο εισάγεται το HATEOAS (Hypertext As The Engine Of Application State), μηχανισμός o οποίος μετατρέπει την υπηρεσία επιπέδου 2 σε μια RESTful υπηρεσία, μια υπηρεσία που λειτουργεί σαν πεπερασμένο αυτόματο. Στο επίπεδο αυτό εισάγεται η χρήση των υπερμέσων που περιεγράφηκαν παραπάνω, με σκοπό αυτά να πληροφορούν για το τι μπορεί να κάνει κάποιος μετά από ένα γεγονός. Για παράδειγμα, παραπάνω, αντί για τη λίστα με τις διαθέσιμες ώρες το σύστημα θα μπορούσε να επιστρέφει κώδικα Conflict ακολουθούμενο από πιθανές μεταβάσεις (πχ ακύρωσης ραντεβού ή αλλαγής της ώρας) οι οποίες μπορούν να πραγματοποιηθούν: HTTP/ Conflict [ ] <appointment> <code id= 123 doctor= mpapathanasiou start= 1400 end= 1450 room= A21 /> <link rel= /linkrels/appointment/cancel uri= /appointments/123/appointment /> <link rel= /linkrels/appointment/self uri= /appointments/123/appointment /> <link rel= /linkrels/appointment/changetime uri= /appointment/mgeorgiou/appointment?code=123? /> [ ] </appointment> Η σημασία των επιπέδων To μοντέλο ωρίμανσης του Leonard Richardson, αν και δεν ορίζει μοναδικά το REST, είναι μια προϋπόθεσή του. Ορίζει έναν καλό οδηγό βήμα προς βήμα για την κατανόηση των βασικών εννοιών πίσω από την αρχιτεκτονική REST. Στο επίπεδο 1 αντιμετωπίζεται η ανάγκη της διάσπασης του μεγάλου και ενιαίου συστήματος σε πόρους. Στο επίπεδο 2 εισάγονται τα εργαλεία που χρησιμοποιούνται για την αντιμετώπιση παρόμοιων καταστάσεων με αποτέλεσμα να αποφεύγονται επαναλήψεις κομματιών κώδικα που δεν χρειάζονται. Τέλος, στο επίπεδο 3 επιτυγχάνεται η κάλυψη των απαιτήσεων που εισήχθησαν από τον Roy Fielding για το REST Ιδιότητες της Αρχιτεκτονικής REST Σύμφωνα με τον Roy Fielding «Ο διαχωρισμός των εννοιών client server απλοποιεί την υλοποίηση των συστατικών μερών, μειώνει την πολυπλοκότητα των σημασιολογικών συνδέσμων, βελτιώνει την αποτελεσματικότητα της ρύθμισης της απόδοσης και αυξάνει την επεκτασιμότητα των συστατικών μερών των server. Oι περιορισμοί που εισάγονται από συστήματα δομημένα σε επίπεδα επιτρέπουν τη χρήση ενδιαμέσων proxies, gateways και firewalls για την επικοινωνία, χωρίς να αλλάζουν τα συστατικά ανάμεσα στις διεπαφές, διευκολύνοντας έτσι την επικοινωνία ανάμεσα σε διαφορετικές διεπαφές και βελτιώνοντας την απόδοση με τη χρήση μεγάλης κλίμακας caching. Το REST επιτρέπει την καλή επεξεργασία δεδομένων αναγκάζοντας τα μηνύματα να ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

28 είναι αυτοπεριγραφικά: Η αλληλεπίδραση δεν ορίζεται/φαίνεται ανάμεσα στα requests, καλώς ορισμένες μέθοδοι και τύποι μέσων χρησιμοποιούνται για την υπόδειξη σημασιολογικών στοιχείων και ανταλλαγή πληροφοριών και οι απαντήσεις υποδεικνύουν ρητά την ικανότητα caching.»[9] [10] [12]. Συνοπτικά, οι αρχιτεκτονικές ιδιότητες που επηρεάζονται από την αρχιτεκτονική REST είναι: Συνολική απόδοση: οι αλληλεπιδράσεις ανάμεσα στα συστατικά στοιχεία μιας εφαρμογής δημιουργούν μια αίσθηση γρήγορης αλληλεπίδρασης στους χρήστες αλλά και αυξάνουν την απόδοση χρήσης του δικτύου. Επεκτασιμότητα: Τα συστήματα/υπηρεσίες REST είναι πολύ εύκολα επεκτάσιμες καθώς υποστηρίζουν έναν μεγάλο αριθμό αλληλεπιδράσεων ανάμεσα στα συστατικά τους συστήματος/υπηρεσίας. Απλότητα των διεπαφών. Εύκολη δυνατότητα τροποποιήσεων των συστατικών μερών του συστήματος έτσι ώστε αυτά να ικανοποιούν συγκεκριμένους στόχους (ακόμα και κατά την φάση της εκτέλεσης) Διαύγεια στην διαδικασία επικοινωνίας των συστατικών μερών από agents υπηρεσιών. Μεταφερσιμότητα συστατικών μερών. Επαυξημένη αξιοπιστία συστήματος. Τα παραπάνω αποτελούν κλασικές μη λειτουργικές απαιτήσεις συστημάτων λογισμικού Οι περιορισμοί που χαρακτηρίζουν ένα σύστημα ως RESTful Οι παραπάνω ιδιότητες μπορούν να επιτευχθούν και άρα το σύστημα/υπηρεσία να καλείται RESTful αν και μόνον αν τηρούνται οι παρακάτω περιορισμοί: Client Server O περιορισμός αυτός βασίζεται στον διαχωρισμό των «ανησυχιών» (separation of concerns) ανάμεσα στους clients και τους servers. Με απλά λόγια αυτό σημαίνει ότι οι clients δεν ενδιαφέρονται πχ για τον διαθέσιμο αποθηκευτικό χώρο, αλλά αφήνουν την ανησυχία αυτή στους servers. Αντίστοιχα οι servers δεν ενδιαφέρονται για τις διεπαφές που πρέπει να χρησιμοποιηθούν έτσι ώστε οι clients να αντλήσουν δεδομένα. Ο περιορισμός αυτός είναι απλός και ορίζει πως οι clients στέλνουν μια αίτηση (request) και οι servers λαμβάνουν μια αίτηση. Δίνεται επίσης δυνατότητα απόκρισης (respond) των servers στην αίτηση που δέχτηκαν από clients. Uniform Interface Ενιαία Διεπαφή O περιορισμός αυτός ορίζει ότι η διεπαφή ανάμεσα στον client και τον server πρέπει να είναι όσο πιο απλή γίνεται και τηρεί τους εξής περιορισμούς: Αναγνωριστικά Πόρων: Οι πόροι αναγνωρίζονται μέσα στην αίτηση με χρήση URI. Οι πόροι αυτοί καθαυτοί είναι ξεχωριστοί από τις αναπαραστάσεις που επιστρέφονται στους clients. Διαχείριση των πόρων μέσω των αναπαραστάσεων: Όταν ένας client κατέχει μια αναπαράσταση ενός πόρου, κατέχει αρκετή πληροφορία για τη μεταβολή ή και τη διαγραφή του πόρου αυτού. Αυτοπεριγραφικά μηνύματα: Κάθε μήνυμα πρέπει να περιέχει αρκετή πληροφορία για να περιγράφει το πως θα διαχειριστεί το ίδιο το μήνυμα. Υπερμέσα ως εργαλεία για τη μετάβαση καταστάσεων: Oι clients κάνουν μεταβάσεις μόνο μέσω των ενεργειών που αναγνωρίζονται μέσα στα υπερμέσα που ανταλλάσσονται. Εκτός από κάποια συγκεκριμένα σημεία ( πχ εκκίνηση συστημάτων ), οι clients δεν επιτρέπεται να μαντεύουν πιθανές μεταβάσεις για οποιονδήποτε πόρο, παρά μόνο να ακολουθούν μεταβάσεις που περιγράφονται μέσα στις αναπαραστάσεις των πόρων που έχουν στην κατοχή τους. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

29 Stateless Χωρίς Κατάσταση Οι server δεν καταχωρούν την κατάσταση στην οποία βρίσκονται οι clients. Οι καταστάσεις «αποθηκεύονται» μόνο μέσα στους clients. H μόνη πληροφορία που αποθηκεύεται στον server είναι η κατάσταση της συνεδρίας (session). Cacheable Δυνατότητα caching Η διεπαφή πρέπει να παρέχει μηχανισμούς που να καθιστούν αποκρίσεις/απαντήσεις των server cachable. Αυτό μπορεί να γίνεται έμμεσα, άμεσα ή να διαπραγματεύεται έτσι ώστε να επιτρέπεται στους clients να χρησιμοποιούν το ίδιο μήνυμα, αν αυτό είναι δυνατό. Layered System Σύστημα χτισμένο σε επίπεδα Ένας client δεν μπορεί να διακρίνει τι είναι συνδεδεμένο στον server ή τι υπάρχει συνδεδεμένο γενικά στο σύστημα. Έτσι ο client δεν μπορεί να έχει άμεση πρόσβαση σε έναν server. Code on Demand Οι servers μπορούν προσωρινά να επεκτείνουν ή να μεταβάλλουν γενικά τη λειτουργικότητα των client μεταφέροντας κομμάτια εκτελέσιμου κώδικα. Χαρακτηριστικό παράδειγμα είναι η ανταλλαγή κομματιών κώδικα JavaScript. Κανένας από τους παραπάνω περιορισμούς δεν μπορεί να παραλείπεται (εκτός ίσως από τον τελευταίο) αν κάποιος θέλει να χτίσει ένα RESTful σύστημα/υπηρεσία [8] [13] Σύνοψη Η αρχιτεκτονική REST προσφέρει έναν απλό, διαλειτουργικό και ευέλικτο τρόπο να δημιουργήσει κανείς υπηρεσίες web και εμπεριέχει όλες τις αρχές κλειδιά που μπορούν να καθιστούν τις υπηρεσίες αυτές κλιμακώσιμες και κυρίαρχες έναντι των υπολοίπων. Έχουν γίνει πολλές και αξιόλογες προσπάθειες αυτοματοποιημένης δημιουργίας/σχεδίασης RESTful υ- πηρεσιών που βασίζονται στη μοντελοστραφή σχεδίαση. Οι περισσότερες από αυτές λαμβάνουν υπόψιν κυρίως της λειτουργικές απαιτήσεις του συστήματος/υπηρεσίας. Ένα πολύ σημαντικό κομμάτι όμως των RESTful υπηρεσιών, όπως και κάθε υπηρεσίας/συστήματος που αναπτύσσεται, αποτελούν οι μη λειτουργικές τους α- παιτήσεις, όπως αυτές που αναπτύχθηκαν εδώ. 2.4 Μη Λειτουργικές Απαιτήσεις Λογισμικού Γενικά Ο όρος απαίτηση δεν χρησιμοποιείται με συνεπή τρόπο στην τεχνολογία λογισμού. Στο λεξικό του πανεπιστημίου της Οξφόρδης ως απαίτηση ορίζεται «αυτό που χρειάζεται» ή, ακόμα καλύτερα, «αυτό που είναι αναγκαίο». Στη βιομηχανία της Τεχνολογίας Λογισμικού απαίτηση είναι μια συνθήκη, μια δυνατότητα ή μια υπηρεσία που πρέπει να παρέχεται στον χρήστη, τέτοια ώστε αυτός να λύσει ένα πρόβλημα ή να πετύχει έναν σκοπό. Οι απαιτήσεις χαρακτηρίζονται ως λειτουργικές ή ως μη λειτουργικές απαιτήσεις χρήστη ή συστήματος [15]. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

30 Λειτουργικές απαιτήσεις (functional requirements - ΛΑ): Πρόκειται για δηλώσεις που ορίζουν ποιες υ- πηρεσίες θα πρέπει να παρέχει το σύστημα, πως θα πρέπει το σύστημα να αντιδρά σε συγκεκριμένες εισόδους και πως θα πρέπει να συμπεριφέρεται σε συγκεκριμένες καταστάσεις. Σε μερικές περιπτώσεις οι λειτουργικές απαιτήσεις μπορούν να ορίζουν και τι δεν θα πρέπει να κάνει το σύστημα. Μη λειτουργικές απαιτήσεις (non-functional requirements ΜΛΑ): Πρόκειται για περιορισμούς στις υ- πηρεσίες ή τις λειτουργίες που προσφέρει το σύστημα. Γενικότερα, ως μη λειτουργική απαίτηση μπορεί να χαρακτηριστεί οποιαδήποτε απαίτηση δεν είναι λειτουργική. Στο παρόν έγγραφο στόχος είναι η μοντελοποίηση των μη λειτουργικών απαιτήσεων (ΜΛΑ) συστήματος σε μοντέλα διαδικτυακών συστημάτων REST. Για τον λόγο αυτό παραλείπεται η εκτενέστερη παρουσίαση των χαρακτηριστικών των λειτουργικών απαιτήσεων Περιγραφή και Χαρακτηριστικά Μη λειτουργικές απαιτήσεις, όπως αναφέρει και το όνομά τους, είναι απαιτήσεις που δεν αφορούν άμεσα συγκεκριμένες λειτουργίες που παρέχονται από το σύστημα. Μπορούν να ορίζουν απαιτήσεις στα δεδομένα που χρησιμοποιεί το σύστημα, δηλαδή μορφές αναπαράστασης δεδομένων, περιορισμούς αλλά και απαιτήσεις που αφορούν την ποιότητα. Μπορεί να σχετίζονται με ανακύπτουσες ιδιότητες του συστήματος, όπως η αξιοπιστία, η ασφάλεια, ο χρόνος απόκρισης κλπ., αλλά ταυτόχρονα να ορίζουν και δυνατότητες των συσκευών εισόδου και εξόδου. Οι μη λειτουργικές απαιτήσεις σπανίως σχετίζονται με μεμονωμένα χαρακτηριστικά του συστήματος. Οι απαιτήσεις αυτές χαρακτηρίζουν ιδιότητες του συστήματος ως σύνολο. Επομένως, είναι πιθανό να καθορίζουν διάφορες ανακύπτουσες ιδιότητες, όπως η αξιοπιστία, η δεοντολογία, η ασφάλεια κλπ. Η αποτυχία της ικανοποίησης μιας μη λειτουργικής απαίτησης θα μπορούσε να χαρακτηριστεί πιο σημαντική από την αποτυχία ικανοποίησης μιας λειτουργικής, καθώς η πρώτη μπορεί να επιφέρει σε μη χρήσιμο σύστημα. Για παράδειγμα, αν ένα υπολογιστικό σύστημα ολοκλήρωσης και παραγώγισης κάνει τρεις ώρες να υπολογίσει ένα απλό ολοκλήρωμα δύο διαστάσεων, δεν ικανοποιούνται οι απαιτήσεις αποδοτικότητας, με συνέπεια το σύστημα να μην επιλέγεται από πολλούς χρήστες. Οι μη λειτουργικές απαιτήσεις μπορεί να μην αναφέρονται μόνο στο σύστημα λογισμικού που θα αναπτυχθεί, αλλά μπορεί να θέτουν περιορισμούς και στη διαδικασία ανάπτυξης του συστήματος. Χαρακτηριστικό παράδειγμα είναι μια προδιαγραφή για πρότυπα ποιότητας που πρέπει να χρησιμοποιηθούν κατά τη διαδικασία ανάπτυξης, ποια πρότυπα σχεδίασης δηλαδή πρέπει να χρησιμοποιηθούν με στόχο την ικανοποίηση αναγκών που έχουν προκύψει. Μη λειτουργικές απαιτήσεις μπορεί να προκύπτουν από ανάγκες χρηστών του συστήματος, δηλαδή από τις ίδιες τις λειτουργικές απαιτήσεις, από εσωτερικούς περιορισμούς του συστήματος ή των διαδικασιών που χρησιμοποιούνται, από την ανάγκη της επικοινωνίας με το περιβάλλον αλλά και από το ίδιο περιβάλλον στο οποίο χρησιμοποιείται η εφαρμογή, και από γενικότερα θεσμικά πλαίσια, όπως η νομοθεσία μιας χώρας, πχ για την ιδιωτικότητα των προσωπικών δεδομένων των χρηστών του συστήματος κλπ. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

31 Υπάρχουν πολλές ταξινομίες που χαρακτηρίζουν τις μη λειτουργικές απαιτήσεις. Ο όρος ταξινομία ορίζεται ως η ταξινόμηση (classification) μιας ομάδας χαρακτηριστικών/δεδομένων. Μια από τις σημαντικότερες και γενικότερες ταξινομίες των μη λειτουργικών απαιτήσεων παρουσιάζεται παρακάτω [14]: Μη λειτουργικές απαιτήσεις Απαιτήσεις προϊόντος Εταιρικές απαιτήσεις Εξωτερικές απαιτήσεις Απαιτήσεις χρηστικότητας Απαιτήσεις αποδοτικότητας Απαιτήσεις αξιοπιστίας Απαιτήσεις φορητότητας Απαιτήσεις παράδοσης Απαιτήσεις λειτουργικότητας Δεοντολογικές απαιτήσεις Νομικές απαιτήσεις Απαιτήσεις απόδοσης Απαιτήσεις υλοποίησης Απαιτήσεις ιδιωτικού απορρήτου Απαιτήσεις χώρου Απαιτήσεις προτύπων Απαιτήσεις ασφαλείας Εικόνα 5. Μια ταξινομία των ΜΛΑ. Απαιτήσεις προϊόντος: Οι απαιτήσεις αυτές καθορίζουν τα χαρακτηριστικά και τη συμπεριφορά του προϊόντος. Παράδειγμα είναι η απαίτηση για την απόδοση του συστήματος, πόσο γρήγορα θα λειτουργεί, πόσο χώρο θα πιάνει, αν είναι μεταφέρσιμο, αν είναι ανεκτικό στις αστοχίες κλπ. Εταιρικές απαιτήσεις: Πηγάζουν από τις πολιτικές και τις διαδικασίες της εταιρίας πελάτη και της εταιρίας κατασκευαστή. Χαρακτηριστικά παραδείγματα είναι οι απαιτήσεις για τον χρόνο ανάπτυξης και παράδοσης του έργου οι απαιτήσεις για τη διαδικασία υλοποίησης του έργου, πχ γλώσσα προγραμματισμού, πρότυπα σχεδίασης οι απαιτήσεις προτύπων (ISO κλπ) που πρέπει να ικανοποιούνται. Εξωτερικές απαιτήσεις: Καλύπτουν απαιτήσεις που πηγάζουν από εξωτερικούς προς στο σύστημα και τη διαδικασία ανάπτυξής του παράγοντες. Τέτοιες απαιτήσεις μπορεί να είναι: απαιτήσεις που ορίζουν πως το σύστημα αλληλοεπιδρά με εξωτερικά συστήματα του ίδιου ή άλλων οργανισμών νομικές απαιτήσεις που καθορίζονται από τα θεσμικά πλαίσια του περιβάλλοντος του πεδίου εφαρμογής ηθικές και δεοντολογικές απαιτήσεις, απαιτήσεις που εξασφαλίζουν δηλαδή ότι το σύστημα θα γίνει αποδεκτό από τους χρήστες γιατί δεν παραβιάζει τα προσωπικά τους δεδομένα και την ασφάλειά τους. Ένα συνηθισμένο πρόβλημα που αντιμετωπίζεται κατά τη σχεδίαση συστημάτων λογισμικού είναι η δυσκολία, ή και πολλές φορές η αδυναμία, της επαλήθευσης/κάλυψης των μη λειτουργικών απαιτήσεων. Οι χρήστες/πελάτες των συστημάτων πολλές φορές διατυπώνουν της μη λειτουργικές απαιτήσεις ως γενικούς στόχους, πχ «ευκολία χρήσης», «γρήγορη αποκατάσταση από βλάβες» κλπ. Αυτοί οι αόριστοι στόχοι προκαλούν δυσκολία στους σχεδιαστές του συστήματος. Για τον λόγο αυτό οι μη λειτουργικές απαιτήσεις πρέπει να ορίζονται σαφώς, χωρίς περιθώρια παρερμηνειών [15]. Ένας από τους πλέον αποδοτικούς τρόπους να ικανοποιούνται πολλές από τις μη λειτουργικές απαιτήσεις είναι η χρήση/εφαρμογή προτύπων σχεδίασης κατά τη φάση της σχεδίασης και της υλοποίησης ενός συστήματος. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

32 2.5 Πρότυπα Σχεδίασης ΜΟΝΤΕΛΟΠΟΙΗΣΗ ΜΗ ΛΕΙΤΟΥΡΓΙΚΩΝ ΑΠΑΙΤΗΣΕΩΝ ΛΟΓΙΣΜΙΚΟΥ ΣΕ ΜΟΝΤΕΛΑ ΔΙΑΔΙΚΤΥΑΚΩΝ ΣΥΣΤΗΜΑΤΩΝ REST Ο Christopher Alexander έλεγε «Κάθε πρότυπο περιγράφει ένα πρόβλημα το οποίο επαναλαμβάνεται σε ένα περιβάλλον και στη συνέχεια περιγράφει τον πυρήνα της λύσης στο πρόβλημα αυτό, με τρόπο τέτοιον ώστε η λύση να μπορεί να επαναληφθεί ένα εκατομμύριο φορές, χωρίς να χρειάζεται να κάνουμε το ίδιο πράγμα δύο φορές». Στον κλάδο της Τεχνολογίας Λογισμικού, ως πρότυπο σχεδίασης αναφέρεται μια γενική επαναχρησιμοποιήσιμη λύση που προκύπτει από ένα πρόβλημα που συναντάται συχνά στα πλαίσια της σχεδίασης του λογισμικού. Ένα πρότυπο σχεδίασης έχει τέσσερα κρίσιμα σημεία, το όνομά του, το πρόβλημα στο οποίο συναντάται συχνά, την λύση που προτείνει και τις συνέπειες που επιφέρει. Ορίζει αφαιρέσεις και αναγνωρίζει τις όψεις μιας κοινής σχεδιαστικής δομής. Καθορίζει στην ουσία τη δομή των κλάσεων και των στιγμιότυπων ενός συστήματος, τους ρόλους τους και τις συσχετίσεις τους την κατανομή των υποχρεώσεων. Κάθε πρότυπο εστιάζει σε ένα συγκεκριμένο θέμα πρόβλημα. Περιγράφει πότε μπορεί να εφαρμοστεί, τι θα επωφεληθεί της εφαρμογής του αλλά και το αντάλλαγμα από τη χρήση του. Προφανώς, τα πρότυπα σχεδίασης διαφέρουν μεταξύ τους. Ομαδοποιούνται σε τρεις μεγάλες κατηγορίες ως προς τον σκοπό τους, στα δημιουργικά πρότυπα (creational), στα δομικά πρότυπα (structural) και στα πρότυπα συμπεριφοράς (behavioral). Τα δημιουργικά πρότυπα ασχολούνται με τη διαδικασία δημιουργίας των αντικειμένων των συστημάτων. Τα δομικά πρότυπα ασχολούνται με τη σύσταση των κλάσεων ή των αντικειμένων. Τέλος, τα πρότυπα συμπεριφοράς ορίζουν τρόπους με τους οποίους οι κλάσεις ή τα αντικείμενα αλληλοεπιδρούν και μοιράζουν τις αρμοδιότητές τους [16] [18]. Τυπικές περιπτώσεις χρήσης προτύπων: Δημιουργία αντικειμένων που καθορίζουν κλάσεις ρητά: Ορίζοντας ονόματα κλάσεων όταν κάποιος δημιουργεί ένα αντικείμενο οδηγεί σε συγκεκριμένη υλοποίηση παρά σε συγκεκριμένη διασύνδεση. Αυτός ο περιορισμός περιπλέκει μελλοντικές επεκτάσεις. Για την αποφυγή του χρησιμοποιούνται πρότυπα όπως το Abstract Factory κλπ. Εξάρτηση από συγκεκριμένες διαδικασίες: Όταν κάποιος θέλει να καθορίσει συγκεκριμένες διαδικασίες, περιορίζεται στη μονόδρομη ικανοποίηση μιας απαίτησης. Αποφεύγοντας αυστηρά οριοθετημένες απαιτήσεις μπορεί να κανείς να πετύχει ευκολότερη ικανοποίηση των απαιτήσεων και κατά την εκτέλεση αλλά και κατά το compiling. Πχ Command Pattern Εξάρτηση από πλατφόρμα του υλικού και του λογισμικού: Εξωτερικές διεπαφές των λειτουργικών συστημάτων και APIs διαφέρουν από υλικό σε υλικό και από λογισμικό σε λογισμικό. Λογισμικά τα οποία εξαρτούνται σε συγκεκριμένες πλατφόρμες δεν θα μπορούν να μεταφερθούν εύκολα σε άλλες. Για τον λόγο αυτό είναι σημαντικό κατά τη σχεδίαση να μην εισάγονται περιορισμοί που αφορούν την πλατφόρμα εκτέλεσης. Πχ Abstract Factory, Bridge κλπ. Εξάρτηση από την αναπαράσταση των αντικειμένων ή των υλοποιήσεων: Οι clients που γνωρίζουν πως αναπαρίσταται ένα αντικείμενο, πως αποθηκεύεται, πως αναγνωρίζεται ή υλοποιείται κάτι στο σύστημα είναι πιθανό να χρειάζεται να μεταποιηθούν αν μεταποιηθεί το αντικείμενο. Αποκρύπτοντας την πληροφορία αυτή από τους clients υπάρχει προστασία από «cascading». Πx Abstract Factory, Bridge, Proxy κλπ Αλγοριθμικές εξαρτήσεις: Οι αλγόριθμοι που χρησιμοποιούνται συχνά επεκτείνονται, βελτιστοποιούνται και αντικαθίστανται κατά τη διάρκεια της ανάπτυξης και της επαναχρησιμοποίησης συστημάτων. Αντικείμενα που εξαρτώνται από αλγόριθμους θα πρέπει να αναπροσαρμοστούν μετά από κάθε αναπροσαρμογή αλγορίθμου. Για το λόγο αυτό, αλγόριθμοι που αλλάζουν θα ήταν καλό να απομονώνονται. Πχ bridge pattern, strategy pattern, template κλπ Στενή σύζευξη: Οι κλάσεις που είναι ισχυρά συζευγμένες είναι δύσκολο να επαναχρησιμοποιηθούν ξεχωριστά η μια από την άλλη. Αυτό οδηγεί σε «μονολιθικά» συστήματα, στα οποία δεν μπορείς να μεταβάλλεις σχεδόν τίποτα. Το σύστημα γίνεται έτσι μια πολύ πυκνή μάζα που είναι δύσκολο στην ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

33 κατανόηση. Αντίθετα, σε συστήματα που η σύζευξη είναι πιο χαλαρή, μια κλάση μπορεί να μεταβληθεί, χωρίς να χρειάζεται μεταβολή άλλων στοιχείων του συστήματος. Έτσι η μεταφερσιμότητα και η επεκτασιμότητα επιτυγχάνονται πιο εύκολα. Χρήση Abstract Factory, Bridge, Command, Façade, Observer Επέκταση της λειτουργικότητας με χρήση υποκλάσεων: Η προσαρμογή ενός αντικειμένου με χρήση υποκλάσεων δεν είναι εύκολη υπόθεση. Κάθε νέα κλάση έχει αμετάβλητη διαδικασία υλοποίησης. Ο ορισμός μιας υποκλάσης απαιτεί πολύ καλή κατανόηση της κλάσης πατέρα. Για τον λόγο αυτό η σταδιακή σύνθεση των κλάσεων και η σταδιακή ανάθεση λειτουργικότητας κατά τη φάση της σχεδίασης διευκολύνει επίσης την επεκτασιμότητα. Αυτό επιτυγχάνεται προσαρμόζοντας μοντέλα κληρονομικότητας. Πχ composite pattern, brigde, decorator, observer, strategy Ανικανότητα εύκολης μεταβολής των κλάσεων: Πολλές φορές χρειάζεται μεταβολή των κλάσεων μέσω της αλλαγής κομματιών κώδικα που μπορεί να μην είναι διαθέσιμα ή αλλαγές που χαρακτηρίζονται αδύνατες. Αντιμετώπιση με Adapter Pattern Δημιουργικά πρότυπα Γενικά Τα δημιουργικά πρότυπα προτείνουν μια πιο αφηρημένη διαδικασία αρχικοποίησης. Βοηθούν στη δημιουργία ενός συστήματος ανεξάρτητου από το πως δημιουργούνται τα αντικείμενα, πως συνθέτονται και πως αναπαρίστανται. Ένα δημιουργικό πρότυπο κλάσης χρησιμοποιεί κληρονομικότητα για να διαχωρίσει τις κλάσεις, ενώ ένα δημιουργικό πρότυπο αντικειμένου θα εξουσιοδοτήσει την αρχικοποίηση σε άλλα αντικείμενα. Τα δημιουργικά πρότυπα αρχικά ενσωματώνουν τη γνώση των απτών (όχι αφαιρετικών/αφηρημένων) κλάσεων που χρησιμοποιεί το σύστημα. Επιπλέον αποκρύπτουν το τρόπο με τον οποίο τα instances (στιγμιότυπα) δημιουργούνται. Αυτό που ξέρει το σύστημα είναι το πως αυτά κληρονομούν τις αφηρημένες κλάσεις. Το αρνητικό με τα δημιουργικά πρότυπα είναι ότι δεν μπορούν να συμβιώσουν και να εφαρμοστούν ταυτόχρονα εύκολα με άλλα δημιουργικά πρότυπα. Για παράδειγμα το πρότυπο Builder δεν μπορεί να οδηγηθεί από άλλα πρότυπα κατά τη διαδικασία της δημιουργίας. Πίνακας 2. Δημιουργικά Πρότυπα Σχεδίασης Πρότυπο Abstract Factory Builder Factory Method Prototype Singleton Χρήση Παρέχει μια διεπαφή για τη δημιουργία συσχετιζόμενων ή εξαρτώμενων αντικειμένων χωρίς να προσδιορίζονται απτές κλάσεις. Διαχωρίζει την κατασκευή (construction) σύνθετων αντικειμένων από τις αναπαραστάσεις έτσι ώστε η διαδικασία κατασκευής να μπορεί να δημιουργεί διάφορες αναπαραστάσεις. Επιτρέπει τη διαφοροποίηση μιας κλάσης κατά την αρχικοποίηση των υποκλάσεών της Προσδιορίζει το είδος τους αντικειμένου προς δημιουργία χρησιμοποιώντας στιγμιότυπα «πρωτότυπα», και δημιουργεί νέα αντικείμενα κλωνοποιόντας τα πρωτότυπα. Επιβεβαιώνει ότι μια κλάση έχει μόνον ένα στιγμιότυπο και παρέχει καθολική πρόσβαση σε αυτό. Για ένα σύστημα μοντελοστραφούς αυτοματοποιημένης σχεδίασης συστημάτων REST το Builder είναι πρότυπο τα οποίο θα μπορούσε να συμβάλει σε μια λύση πιο δομημένη, που επιτρέπει τον πολυμορφισμό, δημιουργεί ομάδες παρόμοιων υλοποιήσεων και διευκολύνει την επεκτασιμότητα. Παρακάτω περιγράφεται συνοπτικά τα πρότυπο αυτό: ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

34 Builder Pattern Πρότυπο Χτίστη Σκοπός του προτύπου αυτού είναι ο διαχωρισμός της κατασκευής ενός σύνθετου αντικειμένου από τις αναπαραστάσεις του, έτσι ώστε η ίδια διαδικασία της κατασκευής να μπορεί να δημιουργήσει διάφορες αναπαραστάσεις. Χαρακτηριστικό παράδειγμα αποτελούν τα συστήματα που χρειάζονται πολλούς constructors με διαφορετικές παραμέτρους (δηλαδή όχι απλά υποσύνολα). Για να αποφευχθεί η δημιουργία πολλών διαφορετικών constructor, το πρότυπο χρησιμοποιεί ένα αντικείμενο, τον Builder, ο οποίος δέχεται παραμέτρους αρχικοποίησης μία προς μία και επιστρέφει έναν constructor κατασκευασμένο για συγκεκριμένη υλοποίηση. Το σημαντικό του πλεονέκτημα είναι ότι μπορεί και διαχειρίζεται «flat data», δηλαδή αρχεία HTML, SQL queries κλπ, τα οποία γενικά μεταβάλλονται δύσκολα και η μεταβολής τους πρέπει να καταχωρείται ολόκληρη (δηλαδή δεν επιτρέπεται η παροδική μεταβολή. Πχ η αλλαγή μιας παραμέτρου σε ένα SQL ερώτημα μπορεί να αλλάξει όλο το αποτέλεσμα). Εφαρμογή του προτύπου: Όταν ο αλγόριθμος που χρησιμοποιείται για την υλοποίηση ενός σύνθετου αντικειμένου πρέπει να είναι ανεξάρτητος από τα κομμάτια που το συνθέτουν και από τη διαδικασία σύνθεσης Η διαδικασία κατασκευής πρέπει να επιτρέπει διαφορετικές αναπαραστάσεις κατά τη δημιουργία. Δομή: Director +Construct () builder <<Interface>> Builder +BuildPart () for objects obj in structure do{ builder->buildpart() } ConcreteBuilder +BuildPart () +GetResult () Εικόνα 6. Διάγραμμα κλάσεων του Προτύπου Χτίστη. Product Ο Director είναι το κομμάτι κώδικα που καλεί τον Builder. Ως Builder ορίζεται μια αφηρημένη διεπαφή για τη δημιουργία προϊόντων αντικειμένων. Ο ConcreteBuilder περιέχει ουσιαστικά την υλοποίηση του Builder. Ορίζει και διατηρεί ιστορικό των αναπαραστάσεων που υλοποιεί και παρέχει μια διεπαφή για την ανάκτηση του αντικειμένου. Ως προϊόν(product)/αντικείμενο ορίζεται μια σύνθετη σύνθεση των υπό κατασκευή πραγματικών αντικειμένων. Περιέχει κλάσεις που περιγράφουν πλήρως τη διαδικασία σύνθεσης του τελικού αποτελέσματος. Πως υλοποιείται: Ένας client δημιουργεί το αντικείμενο Director, και παραμετροποιεί το επιθυμητό αντικείμενο Builder. Στη συνέχεια ο Director ειδοποιεί τον Βuilder οποτεδήποτε ένα προϊόν πρέπει να κατασκευαστεί. O Builder δέχεται και διαχειρίζεται τις αιτήσεις του Director και προσθέτει συστατικά μέρη στο προϊόν. Τελικά ο client ανακτά το αντικείμενο από τον Βuilder: ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

35 :Client :Director :ConcreteBuilder new Direcotr(:ConcreBuilder) new ConcreteBuilder Concstruct() BuildPartA() BuildPartB() BuildPartC() GetResult() Εικόνα 7. Διάγραμμα ενεργειών στο Πρότυπο Χτίστη Συνέπειες εφαρμογής του προτύπου: Επιτρέπει τη διαφοροποίηση της εσωτερικής αναπαράστασης ενός προϊόντος. Η διεπαφή επιτρέπει την απόκρυψη της εσωτερικής αναπαράστασης από εξωτερικά συστήματα. Αποκρύπτει επίσης πληροφορία για το πως δημιουργείται ένα προϊόν. Για την εισαγωγή ενός νέου τύπου προϊόντος αρκεί η απλή εισαγωγή ενός νέου είδους Builder. Οι clients επομένως δεν χρειάζεται να γνωρίζουν τον τρόπο με τον οποίο κατασκευάζονται δεδομένα. Απομονώνει τον κώδικα που στοχεύει στην κατασκευή και στην αναπαράσταση. Έτσι επιτυγχάνεται μια πιο «σπονδυλωτή» μορφή, επιτυγχάνεται δηλαδή χαμηλότερη σύζευξη. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

36 2.5.2 Δομικά Πρότυπα Γενικά ΜΟΝΤΕΛΟΠΟΙΗΣΗ ΜΗ ΛΕΙΤΟΥΡΓΙΚΩΝ ΑΠΑΙΤΗΣΕΩΝ ΛΟΓΙΣΜΙΚΟΥ ΣΕ ΜΟΝΤΕΛΑ ΔΙΑΔΙΚΤΥΑΚΩΝ ΣΥΣΤΗΜΑΤΩΝ REST Τα δομικά πρότυπα ασχολούνται με τη διαδικασία της σύνθεσης μεγάλων και σύνθετων δομών αποτελούμενων από απλά αντικείμενα και κλάσεις. Χωρίζονται σε δύο μεγάλες κατηγορίες στα δομικά πρότυπα κλάσεων και στα δομικά πρότυπα αντικειμένων. Τα δομικά πρότυπα κλάσεων χρησιμοποιούν κληρονομικότητα για τη σύνθεση διεπαφών ή υλοποιήσεων. Κλασσικό παράδειγμα είναι ο τρόπος με τον οποίο πραγματοποιείται η πολλαπλή κληρονομικότητα. Το αποτέλεσμα από το «μιξάρισμα» δύο κλάσεων είναι μια νέα κλάση που καλύπτει όλες τις ανάγκες που κάλυπταν οι δύο υποκλάσεις μαζί. Τα πρότυπα αυτά είναι ιδιαίτερα χρήσιμα, διότι επιτρέπουν βιβλιοθήκες που αναπτύχθηκαν ξεχωριστά να λειτουργούν μαζί. Τα δομικά πρότυπα αντικειμένων περιγράφουν τρόπους σύνθεσης έτσι ώστε να επιτευχθεί επιπλέον λειτουργικότητα. Η προστιθέμενη αυτή λειτουργικότητα του αντικειμένου προέρχεται από τη δυνατότητα της αλλαγής της σύνθεσης του αντικειμένου κατά την εκτέλεση. Κάτι τέτοιο θα ήταν σχεδόν αδύνατο χωρίς τη χρήση κάποιου προτύπου. Κάποια από τα βασικά δομικά πρότυπα παρουσιάζονται παρακάτω: Πίνακας 3. Δομικά Πρότυπα Σχεδίασης Πρότυπο Adapter Aggregate Bridge Composite Decorator Extensibility - Framework Facade Flyweight Marker Pattern Proxy Λειτουργικότητα Προσαρμόζει μια διεπαφή μιας κλάσης στις ανάγκες ενός client. Χρήση δενδρικών δομών με μεθόδους συσσωμάτωσης για τις κλάσεις παιδιά. Απομονώνει μια αφαίρεση από την υλοποίησή της. Χρήση δενδρικών δομών όπου κάθε αντικείμενο έχει δική του διεπαφή. Ενσωματώνει επιπλέον χρηστικότητα σε μια κλάση κατά την εκτέλεση. Αποκρύπτει σύνθετα κομμάτια κώδικα πίσω από μία διεπαφή. Δημιουργεί μια απλοποιημένη διεπαφή με μιας ήδη υπάρχουσας σύνθετης διεπαφής με άξονα τη διευκόλυνση χρήσης των πιο συχνά χρησιμοποιούμενων μεθόδων. Μια μεγάλη γκάμα από αντικείμενα μοιράζεται ένα κοινό αντικείμενο ιδιοτήτων για την εξοικονόμηση χώρου. Εισάγει μια κενή διεπαφή την οποία συσχετίζει με μεταδεδομένα μιας κλάσης. Χρήση μιας κλάσης που χρησιμοποιείται σαν διεπαφή για κάτι άλλο. Σε ένα σύστημα αυτοματοποιημένης παραγωγής υπηρεσιών REST, θα επιζητούσε κανείς να επαυξάνει τη λειτουργικότητα της παραγόμενης υπηρεσίας χωρίς να περιορίζεται από σχεδιαστικούς περιορισμούς. Τα πρότυπα Adapter, Bridge, Composite και Façade μπορούν να βοηθήσουν στο εγχείρημα αυτό: Bridge Pattern Πρότυπο Γέφυρας Το πρότυπο διαχωρίζει μια αφαίρεση (abstraction) από την υλοποίησή της έτσι ώστε οι δυο τους να υπάρχουν ανεξάρτητα. Χρησιμοποιείται όταν κάτω από την ίδια διεπαφή πρέπει να ενσωματωθούν διάφορες λειτουργικότητες. Το πρότυπο χρησιμοποιεί την ενθυλάκωση, τη συνάθροιση και ενίοτε την κληρονομικότητα για να πετύχει τους στόχους του. Εφαρμογή του προτύπου όταν: Υπάρχει ανάγκη αποφυγής της μόνιμης δέσμευσης μια αφαίρεσης και της κλάσης που την υλοποιεί. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

37 Οι αφαιρέσεις και οι υλοποιήσεις τους πρέπει να μπορούν να επεκταθούν με χρήση υποκλάσεων. Σε αυτήν την περίπτωση το πρότυπο επιτρέπει την τον συνδυασμό διαφορετικών αφαιρέσεων και υλοποιήσεων και εκτελεί την επέκταση ανεξάρτητα από αυτές. Οι αλλαγές στο σύστημα δεν πρέπει να επηρεάζουν τους clients. Υπάρχει περίπτωση μεγάλης αναπαραγωγής/πολλαπλασιασμού των κλάσεων κατά τη σχεδίαση του συστήματος. Υπάρχει επιθυμία διαμοιρασμού μιας υλοποίησης (κλάσης) ανάμεσα σε πολλά αντικείμενα και αυτό δεν πρέπει να το γνωρίζει ο client. Δομή: <<Interface>> Abstraction -impl: Implementor +Operation1() <<Interface>> Implementor +Implementation() this.impl.implementation() ConcreteImplementor RefinedAbstraction +ConcreteImplementation() +RefinedOperation1() Εικόνα 8. Διάγραμμα κλάσεων του Προτύπου Γέφυρας Στο πρότυπο αυτό ως Abstraction ορίζεται η αφαίρεση(διεπαφή/αφηρημένη δομή) της λύσης, η οποία διατηρεί συσχέτιση με τον Implementor. Ο Implementor ορίζει τη διεπαφή για κλάσεις. Οι RefinedAbstractions κληρονομούν την Abstraction για να εισάγουν επιπλέον λειτουργικότητα και ο ConcreteImplementor υλοποιεί την κλάση που απαιτείται από τη λύση. Συνέπειες εφαρμογής του προτύπου: Αποσύζευξη της διεπαφής και της κλάσης που την υλοποιεί. Μια υλοποίηση δεν δεσμεύεται από μία διεπαφή. Η υλοποίηση μιας αφαίρεσης μπορεί να προσδιορίζεται κατά την εκτέλεση. Ένα αντικείμενο μπορεί να αλλάξει ακόμα και την μορφή του κατά την εκτέλεση. Το πλεονέκτημα έγκειται στο γεγονός ότι κατά την αλλαγή δεν χρειάζεται recompiling, γεγονός που καθιστά διάφορες εκδόσεις κλάσεων συμβατές με άλλες κλάσεις/συστήματα. Επιπλέον, η αποσύζευξη αυτή ενθαρρύνει την «επιπεδοποίηση» (Layering), οδηγώντας σε καλύτερα δομημένα συστήματα. Βελτίωση της επεκτασιμότητας. Απόκρυψη των λεπτομερειών υλοποίησης από τους clients. Χρήση πολλαπλής κληρονομικότητας. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

38 2.5.3 Πρότυπα Συμπεριφοράς Γενικά Τα πρότυπα συμπεριφοράς ασχολούνται με αλγορίθμους και με την ανάθεση υποχρεώσεων μεταξύ των αντικειμένων. Δεν περιγράφουν μόνο τα αντικείμενα και τις κλάσεις, αλλά περιγράφουν επίσης τον τρόπο με τον οποίο πραγματοποιείται επικοινωνία μεταξύ τους. Πετυχαίνουν την αύξηση της ευελιξίας του συστήματος Μερικά χαρακτηριστικά πρότυπα συμπεριφοράς φαίνονται στον παρακάτω πίνακα: Πίνακας 4. Πρότυπα Συμπεριφοράς. Πρότυπο Chain of Responsibility Command Interpreter Iterator Observer Strategy Template Method Memento Λειτουργικότητα Αντικείμενα που διαχειρίζονται το λογικό περιεχόμενο του συστήματος διαχειρίζονται (μετακινούν, προσπελαύνουν κ.α.) και άλλα αντικείμενα ε- λέγχου. Αντικείμενα ελέγχου ενθυλακώνουν τρόπους με τους οποίους εκτελείται μια ενέργεια και τις παραμέτρους που απαιτούνται. Υλοποιείται μια ειδική υπολογιστική γλώσσα για να την άμεση επίλυση κάποιων οικογενειών από προβλήματα. Χρησιμοποιούνται αντικείμενα που καλούνται Iterators για να προσπελαύνουν αντικείμενα ακολουθιακά, χωρίς να εκθέτουν τις υποκείμενες αναπαραστάσεις τους. Αντικείμενα «εγγράφονται» για να λαμβάνουν πληροφορίες ενός γεγονότος. Διαφορετικοί αλγόριθμοι μπορούν να επιλεγούν κατά την εκτέλεση Περιγράφει τον σκελετό ενός προγράμματος. Διατηρεί ιστορικό συγκριμένων πόρων του συστήματος Από τα παραπάνω πρότυπα, εκτός φυσικά από το template pattern που χρησιμοποιείται ούτως ή άλλως κατά τη σχεδίαση των περισσότερων συστημάτων, χρήσιμα είναι τα Observer και Memento πρότυπα Observer Pattern Πρότυπο Παρατηρητή Το πρότυπο ορίζει μια-προς-πολλά σχέσεις εξάρτησης ανάμεσα σε αντικείμενα, έτσι ώστε όταν ένα αντικείμενο αλλάζει κατάσταση, όλα τα υπόλοιπα που εξαρτώνται από αυτό ειδοποιούνται και ανανεώνονται αυτόματα. To αντικείμενο υποκείμενο (subject) διατηρεί μια λίστα με αντικείμενα που καλούνται παρατηρητές (observers) και ενημερώνει τη λίστα αυτή σε κάθε αλλαγή της κατάστασής του. Χρησιμοποιείται κυρίως για την υλοποίηση διανεμημένων συστημάτων διαχείρισης γεγονότων (event). Επιτρέπει την επαναχρησιμοποίηση των subjects ανεξάρτητα από τους observers και αντίστροφα. Είναι θεμέλιος λίθος στα περισσότερα συστήματα που έχουν αρχιτεκτονική MVC (και οι RESTful υπηρεσίες συνήθως χτίζονται με MVC). Χρήση του προτύπου όταν: Όταν μια αφαίρεση έχει δύο πλευρές/λειτουργικότητες, η μια εξαρτώμενη από την άλλη. Η ενθυλάκωση των πλευρών σε διαφορετικά αντικείμενα επιτρέπει την ανεξάρτητη χρήση και προσπέλασή τους. Όταν η μεταβολή σε ένα αντικείμενο απαιτεί την μεταβολή άλλων και η πληροφορία του αριθμού των αντικειμένων που μεταβλήθηκαν συνολικά δεν είναι σημαντική. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

39 Όταν ένα αντικείμενο πρέπει να μπορεί να ενημερώνει άλλα αντικείμενα χωρίς να κάνει υποθέσεις για το ποια αντικείμενα είναι αυτά. Με λίγα λόγια, όταν υπάρχει ανάγκη τα αντικείμενα να μην είναι στενά συζευγμένα. Δομή: <<Interface>> Subject +Attach(Observer) +Detach(Observer) +Notify() observes <<Interface>> Observer +Update() r all observers{ this.update(); } ConcreteSubject -SubjectState +SetState() +GetState() subject Observer -ObserverState +Update() return SubjectState; ObserverState= subject.getstate(); Εικόνα 9. Διάγραμμα κλάσεων του προτύπου Παρατηρητή. To Subject γνωρίζει τους παρατηρητές του. Παρέχει μια διεπαφή για την καταχώρηση και την διαγραφή αντικειμένων που των Observers. Tο ConcreteSubject αποθηκεύει την κατάσταση που θέλει να παρακολουθεί ο ConcreteObserver και τον ενημερώνει σε περίπτωση αλλαγής της κατάστασης. Ο observer με τη σειρά του, ορίζει μια διεπαφή για να ανανεώνει αντικείμενα που πρέπει να ανανεώνονται όταν γίνονται αλλαγές σε ένα subject. Τέλος, o ConcreteObserver διατηρεί την κατάσταση και υλοποιεί τη διαδικασία μέσω της οποίας αποθηκεύεται η κατάσταση που παρακολουθείται. Συνέπειες από την εφαρμογή του προτύπου: Αφαιρετική σύζευξη μεταξύ των Subjects και των Objects. Το μόνο που γνωρίζει το αντικείμενο είναι μια λίστα με τους Observers και τίποτα για την υλοποίησή τους. Υποστήριξη μαζικοποιημένης επικοινωνίας. Σε αντίθεση με την περίπτωση της ερώτησης-απάντησης (request-response), το πρότυπο επιτρέπει την ενημέρωση πολλών αντικειμένων ταυτόχρονα. Ασύγχρονη επικοινωνία αναγνώριση γεγονότων. Τα συστήματα που χρησιμοποιούν το πρωτόκολλο αυτό μπορούν να διαχειρίζονται με μεγάλη ευκολία ασύγχρονα και τυχαία γεγονότα Memento Pattern Πρότυπο Μνήμης Το πρότυπο Memento (Μνήμης), είναι ένα συμπεριφορικό πρότυπο που παρέχει τη δυνατότητα ανάκτησης μιας προγενέστερης κατάστασης ενός αντικειμένου. Στόχος της χρήσης του είναι να επιτευχθεί η λήψη ενός στιγμιότυπου αντιγράφου της σύστασης ενός αντικειμένου, χωρίς να παραβιάζονται τα περιεχόμενα και η δομή του αντικειμένου, με στόχο την επαναφορά της κατάστασης στο στιγμιότυπο αυτό. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

40 Δομή: ΜΟΝΤΕΛΟΠΟΙΗΣΗ ΜΗ ΛΕΙΤΟΥΡΓΙΚΩΝ ΑΠΑΙΤΗΣΕΩΝ ΛΟΓΙΣΜΙΚΟΥ ΣΕ ΜΟΝΤΕΛΑ ΔΙΑΔΙΚΤΥΑΚΩΝ ΣΥΣΤΗΜΑΤΩΝ REST Originator -state +setmemento() +creatememento() Memento -state +getstate() +setstate() Caretaker Εικόνα 10. Διάγραμμα κλάσεων του Προτύπου Μνήμης. O originator είναι το αντικείμενο του οποίου η κατάσταση θα αποθηκευτεί, το memento είναι το στιγμιότυπο μνήμης, το κουτί στο οποίο θα σωθεί η κατάσταση του originator και ο caretaker είναι τοο αντικείμενο που γνωρίζει πότε και γιατί πρέπει να αποθηκευτεί η κατάσταση του originator. 2.6 MDE και MDA Τον Νοέμβριο του 2000, το OMG (Object Management Group) δημοσιοποίησε το MOF (Meta Object Facitilty) μέσω του οποίου προτυποποιούσε την MDA αρχιτεκτονική (Model Driven Architecture), προσέγγιση που ενέπνευσε τη δημιουργία νέων μεθόδων και πρακτικών για τη σχεδίαση και τη δημιουργία λογισμικού. Η βασική του ιδέα είναι η μεταβολή της κωδικοκεντρικής διαδικασίας παραγωγής λογισμικού, σε μια διαδικασία που βασίζεται σε μοντέλα, έτσι ώστε να μπορεί να επιτευχθεί καλύτερη συνοχή, να διευκολυνθεί η αυτοματοποίηση της διαδικασίας και η παραγωγικότητα [24]. Με λίγα λόγια περισσότερος κώδικας σε λιγότερο χρόνο. Το MDA είναι μια από τις βασικές τεχνολογίες που θα χρησιμοποιηθεί στο εγχείρημα της διπλωματικής. Η προσέγγιση του MDA δεν βασίζεται σε μια μοναδική ιδέα. Κάποιοι από τους στόχους του είναι: O διαχωρισμός των επιχειρησιακών, ουδέτερων περιγραφών από υλοποιήσεις που απευθύνονται σε συγκεκριμένες πλατφόρμες. Η έκφραση συγκεκριμένων πλευρών ενός υπο-κατασκευή συστήματος με ειδικές για τον τομέα ανάπτυξης (domain specific) γλώσσες προγραμματισμού. Ο καθορισμός σχέσεων μεγάλης ακρίβειας μεταξύ των διαφορετικών γλωσσών Η ικανότητα να εκφράζονται μετασχηματισμοί μεταξύ τους. H βασική αρχή του MDA, και γενικότερα του MDE (Model Driven Engineering), είναι το «όλα είναι μοντέλα» [19]. Ως μοντέλα ορίζονται αφαιρέσεις συστατικών μερών συστημάτων. Μια συγκεκριμένη όψη ή πλευρά ενός συστήματος μπορεί να απεικονιστεί από ένα μοντέλο και κάθε μοντέλο είναι γραμμένο στη γλώσσα του μεταμοντέλου του. Δύο είναι οι βασικές σχέσεις της προσέγγισης αυτής, η representedby που δηλώνει «αναπαρίσταται ως» και η conformantto «συμμορφώνεται σε». Μεταμοντέλο είναι το μοντέλο ενός μοντέλου. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

41 conformantto Μ 3 meta-meta-model conformantto Μ 2 meta-model conformantto Μ 1 Model representedby Μ 0 System Εικόνα 11. Η βασική αρχιτεκτονική τεσσάρων επιπέδον του MOF. Η βασική αρχιτεκτονική 4 επιπέδων που προτείνει ο OMG μέσω του MOF (Meta object facility) φαίνεται στο παραπάνω σχήμα [25] [26]. Στο επίπεδο Μ 0 βρίσκεται το πραγματικό σύστημα. Ένα μοντέλο αναπαριστά το σύστημα στο επίπεδο Μ 1. Αυτό το μοντέλο συμμορφώνεται σε κανόνες που ορίζονται από το μεταμοντέλο του Μ 2, το οποίο με τη σειρά του συμμορφώνεται σε ένα μετα-μεταμοντέλο. Το μετά-μεταμοντέλο συμμορφώνεται με τον ίδιο του τον εαυτό. Ένα σημαντικό στοιχείο του MDA αποτελεί ο μετασχηματισμός μοντέλων. Ένας μετασχηματισμός είναι η αυτοματοποιημένη παραγωγή ενός μοντέλου στόχου (target model) από ένα μοντέλο πηγή (source model) σύμφωνα με κάποιες προδιαγραφές μετασχηματισμού (transformation definition) oι οποίες αποτελούνται από ένα σύνολο κανόνων. Source meta-model referesto Transfomation Definition refersto Target meta-model conformsto executes ConformsTo Source Model reads Transformation Rules writes Target Model Εικόνα 12. Μετασχηματισμός μοντέλου. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

42 O μηχανισμός που ακολουθείται σύμφωνα με το MDE, στηριζόμενος σε έννοιες που καλύπτει το MDA έχει τέσσερις φάσεις: Πρώτη Φάση Δεύτερη Φάση Τρίτη Φάση Τέταρτη Φάση PSM X Code Implementation X CIM PIM PSM Y Code Implementation Y PSM Z Code Implementation Z Εικόνα 13. Μηχανισμός μετασχηματισμού μοντέλων σύμφωνα με την MDA προσέγγιση. 1. Σχηματισμός του Computational Independent Model (CIM Υπολογιστικά Ανεξάρτητο Μοντέλο). Το μοντέλο αυτό είναι η πιο αφαιρετική προσέγγιση του προς σχεδιασμό συστήματος. Περιλαμβάνει έννοιες, οντότητες και ιδιότητες που ανήκουν αυστηρά στο πεδίο της εφαρμογής. Σε αυτό το στάδιο δεν υπάρχει καμία έννοια που αφορά το σχεδιασμό, την αρχιτεκτονική και την υλοποίηση το συστήματος. Στην προσέγγιση που θα ακολουθηθεί σε αυτήν την εργασία, το πεδίο εφαρμογής είναι το RESTful πεδίο. Κύριες έννοιες του μοντέλου είναι οι αναπαραστάσεις, οι διεπαφές web, οι ιδιότητες των αναπαραστάσεων, οι συσχετίσεις των αναπαραστάσεων κλπ. 2. Μετασχηματισμός M2M (model to model) του CIM για τη δημιουργία του αντίστοιχου Platform Independent Model (PIM Μοντέλο Ανεξάρτητο της Πλατφόρμας Υλοποίησης). Στο στάδιο αυτό εισάγεται μια αφηρημένη σχεδίαση του συστήματος χωρίς λεπτομέρειες της υλοποίησης. 3. Μετασχηματισμός του PIM για τη δημιουργία Platform Specific Models (PSM Μοντέλα Εξαρτημένα της Πλατφόρμας Υλοποίησης). Το PSM συμβιβάζεται στη σχεδίαση που προτείνει το PIM αλλά καθορίζει και τον τρόπο με τον οποίο θα υλοποιηθεί η σχεδίαση εισάγοντας πληροφορίες για τη γλώσσα υλοποίησης, για τα frameworks που χρειάζονται, για βιβλιοθήκες, πρότυπα σχεδίασης κλπ. 4. Δημιουργία κώδικα με χρήση προτύπων και μεταδεδομένων που ορίζει το PSM. Κάποια κομμάτια κώδικα μπορεί να είναι πλήρως υλοποιημένα, κάποια μερικώς. Τα βασικά οφέλη τη της χρήσης του MDE είναι η αύξηση της παραγωγικότητας, της φορητότητας του κώδικα και της δυνατότητας επέκτασης και συντήρησης. Επιπλέον, διευκολύνεται η κατανόηση της δομής και της συμπεριφοράς του συστήματος και αποδεσμεύεται ανάγκη εκμάθησης και κατανόησης τεχνικών λεπτομερειών [22]. Στον παρακάτω πίνακα παρουσιάζονται συνοπτικά οι επιδράσεις της χρήσης της MDE προσέγγισης. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

43 Πίνακας 5. Επιδράσεις της χρήσης της MDE προσέγγισης. Από τα παραπάνω γίνεται σαφές ότι δεν μπορεί να εξαχθεί κάποιο οριστικό συμπέρασμα όσον αφορά τα οφέλη της MDE προσέγγισης. Οι διάφορες αλληλεξαρτώμενες δραστηριότητες που περιλαμβάνει εισάγουν και θετικά και αρνητικές επιδράσεις ταυτόχρονα. Από τις διάφορες έρευνες που έχουν πραγματοποιηθεί με στόχο τη διερεύνηση της επίδρασης της MDE προσέγγισης σε πραγματικές εφαρμογές, τα συμπεράσματα που εξήχθησαν οδηγούν στην ανάγκη για επιπλέον μελέτη του θέματος. Μερικά βασικά συμπεράσματα που διεξάχθηκαν παρουσιάζονται παρακάτω [23]: ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

44 Εικόνα 14. Αποτέλεσμα ερευνών που αφορούν τη χρήση τoυ MDE. Κάποια από τα θετικά αποτελέσματα όπως φαίνονται στην Εικόνα 24: Αύξηση της παραγωγικότητας των μηχανικών λογισμικού και των προγραμματιστών και μείωση του χρόνου παραγωγής και υλοποίησης του συστήματος. Καλύτερη ποιότητα κώδικα, αξιοπιστία και δυνατότητα επαναχρησιμοποίησης κώδικα. Ευκολότερη συντήρηση και επεκτασιμότητα. Η σχεδίαση των μοντέλων υψηλού επιπέδου επιτρέπει την εύκολη διαχείριση αλλαγών και την εύκολη προσθήκη νέας λειτουργικότητας. Εικόνα 15. Συμπεράσματα ερευνών που αφορούν τη χρήση του MDE. Μερικά αρνητικά αποτελέσματα: Μικρός βαθμός υιοθέτησης της MDE μεθοδολογίας, με εξαίρεση μερικούς τομείς όπως αυτός της σχεδίασης ενσωματωμένων συστημάτων, συστημάτων προσομοίωσης και συστημάτων λογισμικού στην αυτοκινητοβιομηχανία. Σύγχυση μεταξύ των διαφορετικών εργαλείων που χρησιμοποιούνται. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

45 Πολλά εργαλεία που είναι ακόμα ανεπαρκή. Σημαντική δυσκολία στην εκμάθηση. Απαιτείται μεγάλη προσπάθεια για την επίτευξη οφελών. 2.7 Ecore και EMF Κατά τον ορισμό του MOF 2.0, εκτός από την δημιουργία του Complete Meta Object Facility ή CMOF, ο OMG εισήγαγε ένα νέο υποσύνολο του CMOF, το EMOF, που στόχευε να μοντελοποιήσει τους βασικούς δομικούς λίθους ενός συστήματος (ενώ το CMOF στόχευε να μοντελοποιήσει και συμπεριφορές). Το μεταμοντέλο Ecore είναι θεμέλιος λίθος πολλών μοντελοστραφών εφαρμογών και επεκτάσεων στο οικοσύστημα του Eclipse, λόγος για τον οποίο χαρακτηρίζεται και ως μετα-μεταμοντέλο [27] [28]. Εφόσον η επέκταση που αναπτύσσεται στα πλαίσια της διπλωματικής αυτής θα λαμβάνει χώρα σε ένα plugin στον Εclipse, το Ecore μεταμοντέλο επιλέχθηκε ως το βασικό μεταμοντέλο των μοντέλων που θα δημιουργούνται από το σύστημα. Αυτό σημαίνει ότι τα CIM, PIM, και PSM μεταμοντέλα είναι στην πραγματικότητα επεκτάσεις του μεταμοντέλου Ecore. Εικόνα 16. Απλουστευμένο μεταμοντέλο του Ecore. Στην παραπάνω εικόνα απεικονίζεται ένα απλοποιημένο διάγραμμα κλάσεων του Ecore μεταμοντέλου. Μπορεί να παρατηρήσει κανείς ότι το EClass στοιχείο χρησιμοποιείται για να μοντελοποιήσει μια κλάση. Έχει ένα όνομα και από κανένα έως περισσότερα EAttributes ή EReferences. Το EΑttribute χρησιμοποιείται ως μια αναπαράσταση ενός χαρακτηριστικού μιας κλάσης. Τα στοιχεία EReferences αντιπροσωπεύουν συσχετίσεις μεταξύ των EClass στοιχείων είτε αυτή η συσχέτιση είναι περιοριστική είτε όχι. Το στοιχείο EDataType μοντελοποιεί την πληροφορία για τον τύπο του κάθε χαρακτηριστικού. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

46 Εικόνα 17. Μεταμοντέλο Ecore To EMF (Eclipse modeling framwork), είναι ένα framework το οποίο ενοποιεί διάφορα από τα εργαλεία που προσφέρει το οικοσύστημα του Eclipse. Όπως δείχνει και η Εικόνα 18, το EMF ενοποιεί τη JAVA, με το XMI και τη UML. Αυτό σημαίνει ότι οποιοδήποτε στιγμιότυπο πληροφορίας (μοντέλο) είναι εκφρασμένο σε οποιαδήποτε από τις παραπάνω τεχνολογίες, μπορεί να εκφραστεί και στις υπόλοιπες χωρίς ασάφειες και παραλείψεις, προσφέροντας έτσι μια φερέγγυα συσχέτιση ανάμεσα σε διαφορετικές αναπαραστάσεις του ίδιου μοντέλου. Εικόνα 18. EMF και ενοποίηση αναπαραστάσεων. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

47 2.8 ATL ΜΟΝΤΕΛΟΠΟΙΗΣΗ ΜΗ ΛΕΙΤΟΥΡΓΙΚΩΝ ΑΠΑΙΤΗΣΕΩΝ ΛΟΓΙΣΜΙΚΟΥ ΣΕ ΜΟΝΤΕΛΑ ΔΙΑΔΙΚΤΥΑΚΩΝ ΣΥΣΤΗΜΑΤΩΝ REST Η ATL (Atlas Transformation Language) αποτελεί μια υβριδική γλώσσα (δηλωτική και προστατική υ- ποστηρίζει τη συγγραφή μεθόδων με προστακτικές τεχνικές) που χρησιμοποιείται για εκτελέσεις και ορισμούς M2M (model to model). Η ATL συμμορφώνεται στους κανόνες του MOF μετα-μεταμοντέλου και εκτελεί μετασχηματισμούς από ένα μοντέλο στιγμιότυπο ενός μεταμοντέλου, σε ένα άλλο μοντέλο, επίσης στιγμιότυπο μεταμοντέλου, τα οποία επίσης υπακούν το MOF μετα-μεταμοντέλο [30]. Εικόνα 19. ATL model to model μετασχηματισμός. Για παράδειγμα, ακολουθούμενου ενός σετ κανόνων, το Ma μοντέλο, το οποίο συμμορφώνεται με το MMa μεταμοντέλο, μετασχηματίζεται στοιχείο προς στοιχείο στο Mb μοντέλο, το οποίο με τη σειρά του συμμορφώνεται με το MMb μεταμοντέλο. Το βασικό στοιχείο ενός μετασχηματισμού σε ATL είναι ο κανόνας (rule). Υπάρχουν τα εξής είδη κανόνων: Matched Rules: Είναι δηλωτικοί κανόνες. Επιτρέπουν την αντιστοίχιση κάποιων στοιχείων με το πηγαίο μοντέλο και τη δημιουργία ενός αριθμού ξεχωριστών μοντέλων ως έξοδο. Ο μηχανισμός της ATL καλεί τους matched rules αυτόματα κάθε φορά που κάποιο στοιχείο του κανόνα «ταιριάζει» με κάποιο στοιχείο του μοντέλου που δώθιηκε ως είσοδος. Lazy Rules: Μια υποκατηγορία των matched rules είναι οι lazy rules. Η βασική τους διαφορά έγκειται στο γεγονός ότι οι lazy rules πρέπει να καλεστούν από άλλους κανόνες. Unique Lazy Rules: Λειτουργεί όπως ο Lazy Rule, αλλά εκτελείται ακριβώς μια φορά για κάθε στοιχείο για το οποίο καλείται. Με άλλα λόγια, όσες κλήσεις και να γίνουν σε αυτόν τον κανόνα σε ένα συγκεκριμένο στοιχείο, ο κανόνας θα εκτελεστεί μια φορά ακριβώς, την πρώτη, και τις υπόλοιπες φορές επιστρέφει το ίδιο μετασχηματισμένο στοιχείο. Called Rules: Είναι προστακτικοί κανόνες που πρέπει να καλεστούν από άλλους κανόνες και δεν έχουν κανένα στοιχείο ως είσοδο. Χρησιμοποιούνται για τη γέννηση στοιχείων σε ένα μοντέλο για τα οποία δεν υπάρχει αντιστοιχία στο μοντέλο που θα μετασχηματιστεί. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

48 2.9 Acceleo ΜΟΝΤΕΛΟΠΟΙΗΣΗ ΜΗ ΛΕΙΤΟΥΡΓΙΚΩΝ ΑΠΑΙΤΗΣΕΩΝ ΛΟΓΙΣΜΙΚΟΥ ΣΕ ΜΟΝΤΕΛΑ ΔΙΑΔΙΚΤΥΑΚΩΝ ΣΥΣΤΗΜΑΤΩΝ REST Για την παραγωγή του πηγαίου κώδικα στο τελευταίο στάδιο της MDA αρχιτεκτονικής για τον Μ2Τ (model to text) μετασχηματισμό, χρησιμοποιείται η γλώσσα Acceleo. Η Acceleo βασίζεται στη χρήση προτύπων κειμένου (templates). Δέχεται ως είσοδο μοντέλα που υπακούν σε κάποιο μεταμοντέλο και εφαρμόζει στα templates της την πληροφορία που δέχεται από τα μοντέλα εισόδου. Μεγάλο ατού της Acceleo είναι η δυνατότητα που παρέχει για τη δημιουργία και την εκτέλεση ερωτημάτων πάνω στα μοντέλα εισόδου, γεγονός που καθιστά πιο εύκολο το χειρισμό των μοντέλων και άρα τον μετασχηματισμό [31] Η αυξανόμενη ανάγκη για Web APIs Είναι πολύ δύσκολο να γίνει ακριβής εκτίμηση όλων των Web APIs που υπάρχουν αυτή τη στιγμή, καθώς, εκτός από αυτά σε οποία έχουν πρόσβαση όλοι μέσω του διαδικτύου, υπάρχουν και ιδιωτικά τα οποία λειτουργούν στα πλαίσια ιδιωτικών εφαρμογών (από Web APIs για ενδοεταιρεικά δίκτυα μέχρι και για Internet of things εφαρμογές). Μια από τις πιο γνωστές ιστοσελίδες ευρετήρια για τα APIs, το φιλοξενεί αυτή τη στιγμή πάνω από APIs, εκ των οποίων περίπου είναι υλοποιημένα σε RESTful αρχιτεκτονική [29]. Εικόνα 20. Ρυθμός αύξησης των δημόσιων APIs Η παραπάνω εικόνα δείχνει τον αριθμό αύξησης των APIs κατά το χρονικό διάστημα και την εκτίμηση που έγινε για τον αριθμό των API μετά το H εκτίμηση αυτή, σύμφωνα με το ήταν επιτυχής. Μια άλλη σημαντική εκτίμηση για τον αριθμό των APIs που υπάρχουν αυτή τη στιγμή, εκτίμηση που πραγματοποιήθηκε από το υπολογίζει ότι ο αριθμός των APIs αυτή τη στιγμή κυμαίνεται στις [32]. Από τα παραπάνω μπορεί να εξαχθεί το συμπέρασμα ότι η ανάγκη για web APIs, και κυρίως για RESTful Web APIs, αυξάνεται συνεχώς. Επιπλέον, όπως φαίνεται και στο παρακάτω διάγραμμα, οι ανάγκες για Web APIs έχουν φτάσει σε μέγεθος το οποίο δεν μπορεί να καλυφθεί από τον αριθμό των επαγγελματιών προγραμματιστών και μηχανικών λογισμικού. Το γεγονός αυτό οδηγεί στην ανάγκη δημιουργίας εργαλείων που βοηθούν στην παραγωγή τους. Ωστόσο, οι προσπάθειες για τη δημιουργία τέτοιων εργαλείων είναι λίγες σε αριθμό. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

49 Εικόνα 21. Σύγκριση αριθμού εφαρμογών και αριθμού προγραμματιστών. Για την κάλυψη της ανάγκης της αυξημένης ζήτησης για ανάπτυξη Web APIs, και πιο συγκεκριμένα RESTful APIs, άρχισαν να αναδύονται και να αναπτύσσονται εργαλεία μοντελοστραφούς αυτοματοποιημένης παραγωγής κώδικα, εργαλεία που στηρίζονται στο MDE και ακολουθούν την MDA προσέγγιση. Στο επόμενο κεφάλαιο παρουσιάζονται συνοπτικά οι πιο επιτυχημένες προσπάθειες που έγιναν για την ανάπτυξη τέτοιων εργαλείων, κάποια πλεονεκτήματά τους και οι λόγοι για τους οποίους το έργο της συγκεκριμένης διπλωματικής εργασίας αποτελεί ένα κομμάτι που συμπληρώνει το παζλ του νεόδμητου τομέα της μοντελοστραφούς σχεδίασης και ανάπτυξης RESTful Web APIs. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

50 3. State of the Art και Related Work Πολλές προσεγγίσεις αυτοματοποιημένης δημιουργίας συστημάτων REST έχουν γίνει μέχρι σήμερα. Χαρακτηριστικό παράδειγμα αποτελεί η προσέγγιση των Markku Laitkorpi and Petri Selonen από το εργαστήριο της Nokia σε συνεργασία με την Tarja Systa [36]. Το paper τους παρουσιάζει τη διαδικασία του μετασχηματισμού των λειτουργικών απαιτήσεων και προδιαγραφών σε μία RESTful υπηρεσία διεπαφών. Κάποια χαρακτηριστικά λειτουργικά εργαλεία για την αυτοματοποιημένη παραγωγή κώδικα συστημάτων REST μέσω μοντελοστραφών προσεγγίσεων παρουσιάζονται παρακάτω. 3.1 Ruby on Rails To Ruby on Rails είναι ένα πλαίσιο (framework) ανοιχτού κώδικα για τη δημιουργία διαδικτυακών ε- φαρμογών χρησιμοποιώντας τη γλώσσα προγραμματισμού Ruby. Η αρχική της έκδοση έγινε διαθέσιμη για το κοινό το Από τότε έχει εξελιχθεί αρκετά. Κάποια από τα κύρια χαρακτηριστικά που κάνουν το Ruby on Rails δημοφιλές είναι [33]: H γλώσσα Ruby είναι εκ φύσεως απλή γλώσσα, κάτι που κάνει τους αρχάριους να τη προτιμήσουν σε σχέση με άλλες πιο περίπλοκες γλώσσες όπως η PHP και η Java. Ενσωματώνει κάποια από τα πιο βασικά αρχιτεκτονικά πρότυπα για web υπηρεσίες, όπως αυτό του MVC, το active record κλπ. Είναι open source. Προσφέρει ταχύτητα και ευλυγισία, ελαχιστοποιώντας ταυτόχρονα το κόστος και τις τεχνικές ικανότητες που χρειάζονται για να παραχθεί μια υπηρεσία. Εικόνα 22. Ruby on Rails. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

51 Όπως μπορεί να παρατηρήσει κανείς και στην Εικόνα 22, ο πυρήνας μιας υπηρεσίας Rail χτίζεται σε πρότυπο MVC. Για τον λόγο αυτό, τα βασικά στοιχεία είναι τα Μοντέλα, οι Ελεγκτές (Controllers) και οι Όψεις (Views). Τα μοντέλα ενσωματώνουν δεδομένα και αντιστοιχίζονται σε πίνακες στη βάση δεδομένων του συστήματος. Οι Ελεγκτές δέχονται και αποκρίνονται σε αιτήματα που δέχεται ο server. Παρόλο που δεν είναι υποχρεωτικό, το Rails δίνει έμφαση στη δημιουργία Restful ενεργειών, κάτι που σημαίνει ότι οι ελεγκτές συνήθως αποκρίνονται σε ρήματα CRUD. Τέλος οι όψεις είναι συνήθως erb αρχεία που μετατρέπονται σε HTML. Tο μειονέκτημα του Ruby on Rails είναι ότι πολλές φορές πάσχει στην επίδοση και στην επεκτασιμότητα, κάτι που κάνει τις εταιρίες και τους προγραμματιστές να προσφεύγουν σε άλλες λύσεις. 3.2 EMF-Rest Το EMF-Rest, είναι ένα framework που βασίζεται στον Eclipse και επιτρέπει την ανάπτυξη μιας διαδικτυακής υπηρεσίας χρησιμοποιώντας τα μεταμοντέλα του Ecore. Όπως φαίνεται και στην παρακάτω εικόνα, o χρήστης του EMF-REST ξεκινάει μοντελοποιώντας τη web υπηρεσία του χρησιμοποιώντας το μεταμοντέλο Ecore. Όταν τελειώσει με αυτό, το EMF-Rest δημιουργεί την υπηρεσία χρησιμοποιώντας JAX-RS, JSON και JavaScript API. Στην Εικόνα 23, παρουσιάζεται ένα RESTful API που παράγεται από το παράδειγμα Family του Ecore μεταμοντέλου καθώς και η JSON αναπαράσταση μιας πιθανής απόκρισης του συστήματος σε HTTP ερώτημα. Μπορεί να παρατηρήσει κανείς ότι στην JSON απόκριση δεν έχουν παραχθεί Hypermedia Controls, λόγο για τον οποίο το EMF-Rest δεν πετυχαίνει την απόλυτη ικανοποίηση μιας web υπηρεσίας όπως αυτή ορίστηκε στο RMM [34]. Εικόνα 23. EMF-REST ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

52 Εικόνα 24. Απόκριση στην ερώτηση GET /Family/Simpsons/pets 3.3 Django-REST-Framework Το Django-REST-Framework είναι ακόμα ένα framework για τη δημιουργία RESTful υπηρεσιών. Το συγκεκριμένο βασίζεται στη γλώσσα python. Οι πρωταρχικές ρυθμίσεις που πρέπει να κάνεις ένας χρήστης του Django-REST-Framework είναι να ρυθμίσει τα Μοντέλα, τους Serializers, τις όψεις και να ονοματίσει τα URLs. Μια συνοπτική διαδικασία που θα ακολουθούσε κάποιος κατά τη χρήση του framework αυτού θα ήταν η εξής [37]: Αρχικά, πρέπει να γίνει ο ορισμός ενός μοντέλου που αναπαριστά την πληροφορία των δεδομένων με τα οποία θα αλληλοεπιδρά η RESTful διεπαφή και στη συνέχεια πρέπει να δημιουργήσει τους serializers οι οποίοι το αρχικοποιούν, όπως φαίνεται στην παρακάτω εικόνα. Εικόνα 25. Serializers μιας υπηρεσίας του Django-REST-Framework. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

53 Έπειτα, πρέπει να δημιουργηθούν οι όψεις που καθορίζουν τον τρόπο με τον οποίο οι πελάτες (clients) θα αλληλοεπιδρούν με τι API (αιτήματα και αποκρίσεις). Το τελικό στάδιο, με σκοπό την ενσωμάτωση των hyperlinks, είναι να οριστούν αρχεία πρότυπα σε python που να περιέχουν τα πρότυπα URL που θα χρησιμοποιηθούν. Στην Εικόνα 26 φαίνεται η απάντηση ενός server σε ένα GET ερώτημα. Ούτε το Django δεν παράγει αυτόματα τα hypermedia controls. Εικόνα 26. Απάντηση ενός GET ερωτήματος σε μια υπηρεσία που παράχθηκε με χρήση του Django-REST-Framework 3.4 S-CASE Tα πλεονεκτήματά του σε σχέση με τις υπάρχουσες τεχνολογίες Παραπάνω παρουσιάζονται οι πιο σοβαρές προσπάθειες που έχουν γίνει για να δημιουργηθούν συστήματα που εκτελούν αυτόματη παραγωγή κώδικα για RESTful web υπηρεσίες. Κάποιες από αυτές πετυχαίνουν υψηλότερη κάλυψη των επιπέδων που ορίζει το RMM, ενώ άλλες καταφέρνουν καλύτερη αυτοματοποίηση της διαδικασίας παραγωγής του κώδικα. Το κύριο μειονέκτημα των παραπάνω frameworks είναι η μη ικανότητα παραγωγής Hypermedia controls, του ανωτέρου δηλαδή επιπέδου του RMM. Ακόμα και στις λίγες περιπτώσεις που γίνεται η εισαγωγή και η παραγωγή των hypermedia controls, αυτή είναι συνήθως ελλιπής και αφήνεται στην ευχέρεια ενός προγραμματιστή η μεταβολή της web υπηρεσίας ώστε να ενσωματωθούν σωστά. Σε αντίθεση με τα παραπάνω, ο στόχος του S-CASE είναι να αυτοματοποιήσει όσο το δυνατόν περισσότερο τη διαδικασία παραγωγής ενός RESTful API. Πετυχαίνει τον στόχο αυτό παράγοντας υπηρεσίες που ανήκουν στο 3 ο επίπεδο του RMM [39]. Tα κυριότερα πλεονεκτήματα του S-CASE σε σχέση με τις υπόλοιπες υπάρχουσες τεχνολογίες είναι: 1. H πλήρης κάλυψη του 3 ου επιπέδου του RMΜ, κάτι που σημαίνει ότι οι παραγόμενες υπηρεσίες δεν παραβιάζουν κανέναν από τους περιορισμούς που απαιτείται να ικανοποιούνται έτσι ώστε ένα σύστημα να είναι RESTful. Οι πόροι που παράγονται είναι σημασιολογικά συνδεδεμένοι με hypermedia controls. Έτσι, κάθε φορά που ένας client θέλει να αλληλεπιδράσει με τους πόρους αυτούς μέσω HTTP ερωτημάτων, στις απαντήσεις από τον server ενσωματώνονται όλα τα hypermedia links του πόρου αυτού. Τα links αυτά περιέχουν το URI που απαιτείται έτσι ώστε η συσχέτιση να είναι ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

54 σαφής και σωστή. Επίσης, στις απαντήσεις εμπεριέχεται και μια λίστα με τις υπόλοιπες επιτρεπόμενες ενέργειες που επιτρέπονται στον πόρο αυτόν. 2. Η εφαρμογή του μοντελοστραφούς προγραμματισμού για την ανάπτυξη RESTful υπηρεσιών. Το MDE Engine ακολουθεί ρητά τα στάδια της MDE προσέγγισης και άρα κληρονομεί όλα τα πλεονεκτήματά της. Το MDE Engine του S-CASE παρέχει έναν κατανοητό μηχανισμό που είναι εύκολα ε- πεκτάσιμος και μπορεί να συνδυάσει και να υποστηρίξει πολλές γλώσσες προγραμματισμού για τη δημιουργία RESTful API που καλύπτουν τις απαιτήσεις του 3 ου επιπέδου του RMM. 3. Η χρήση πλήρως διαφανών και κατανοητών μετασχηματισμών με τη χρήση της ATL γλώσσας αυξάνει την εύκολη ανάγνωση και την ακολουθήσει της διαδικασίας του MDE Engine. 3.5 ΜΛΑ και MDE Όλα τα παραπάνω συστήματα, και καλύτερα από όλα το S-CASE, μπορούν να καλύψουν στην πλειοψηφία τους όλες τις λειτουργικές απαιτήσεις λογισμικού που θα είχε ένα RESTful API. Η κάλυψη όμως των μη λειτουργικών απαιτήσεων, κυρίως με αυτοματοποιημένη εφαρμογή προτύπων σχεδίασης σε συνδυασμό με τη χρήση μοντελοστραφών μεθόδων σε RESTful υπηρεσίες είναι μια ιδέα που βρίσκεται σε βρεφικό στάδιο. Παρόλα αυτά, είναι αρκετές οι αξιόλογες προσπάθειες που στοχεύουν να ενσωματώσουν την μοντελοποίηση και την κάλυψη των μη λειτουργικών απαιτήσεων. Ο Abdelhadi Bouain [35] προσπαθεί να αντιμετωπίσει τα προβλήματα της πολυπλοκότητας και της ε- πεκτασιμότητας, καθώς επίσης και να εισάγει επιπλέον ασφάλεια και απόδοση στο προς σχεδίαση σύστημα. Χρησιμοποιεί μεθόδους MDA και SOA (Service Oriented Architectures). H πρότασή του είναι εξής: Επειδή οι μη λειτουργικές απαιτήσεις είναι πολλές, και συχνά αντιφάσκουν, είναι καλό να ικανοποιούνται κατά τη φάση της σχεδίασης και της κάλυψης των λειτουργικών απαιτήσεων. Για τον λόγο αυτόν προτείνει ότι η προσαρμογή λύσης για την κάλυψη των ΜΛΑ να γίνεται ανάμεσα στα επίπεδα. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

55 Στο CIM επίπεδο: Αναγνωρίζει λειτουργικές και μη λειτουργικές απαιτήσεις Ορίζει το NFR μεταμοντέλο. Επεκτείνει τη λειτουργικότητα του μεταμοντέλου έτσι ώστε να εμπεριέχει πληροφορία και λειτουργικών απαιτήσεων. Στο PIM επίπεδο: Υλοποιεί τις ίδιες λειτουργίες με το CIM. Εκτελεί τον μετασχηματισμό M2M από CIM σε PIM Εκτελεί τον μετασχηματισμό M2T για τη δημιουργία κώδικα. Στο PSM επίπεδο: Υλοποιεί την ίδια διαδικασία με το CIM και το PSM Εκτελεί μετασχηματισμούς PIM σε PSM και M2T για δημιουργία κώδικα Στην πρότασή του πραγματοποιούνται δύο μετασχηματισμοί: Οριζόντιοι μετασχηματισμοί: Για κάθε επίπεδο του MDA, αναγνωρίζεται το μεταμοντέλο που αναπαριστά τη λειτουργική πλευρά, μετά πραγματοποιείται μια ταξινόμηση των μη λειτουργικών α- παιτήσεων σε κατηγορίες σύμφωνα με τους τύπους του και τέλος αναγνωρίζεται το μεταμοντέλο μη λειτουργικών απαιτήσεων για κάθε κατηγορία. Δηλαδή, το αποτέλεσμα θα είναι ένα μεταμοντέλο λειτουργικών-μη λειτουργικών απαιτήσεων. Κατακόρυφοι μετασχηματισμοί: Πραγματοποιούνται οι μετασχηματισμοί που ορίζει το μοντέλο MDA. Μια άλλη προσέγγιση, πιο κοντά σε αυτό που θα προσπαθήσουμε εμείς είναι η πρόταση των Yi Liu Zhiyi Ma, Rui Qiu, Hongjie Chen και Weizhong Shao [40]. Στο paper τους προτείνεται μια προσέγγιση για το πως θα καλυφθούν μη λειτουργικές απαιτήσεις με τη χρήση προτύπων σχεδίασης και πως αυτές θα ενσωματωθούν στη σχεδίαση χρησιμοποιώντας υπάρχοντα μοντέλα UML. Πρότυπα που στοχεύουν στην κάλυψη συγκεκριμένων ΜΛΑ προτείνονται για την επαναχρησιμοποίηση της αποκτηθείσας γνώσης. Οι Sherif M. Yacoub, Hengyi Xue, and Hany H. Ammar από το πανεπιστήμιο της West Virginia, προτείνουν/παρουσιάζουν μια διαδικασία αυτοματοποιημένης εφαρμογής προτύπων σχεδίασης, εισάγοντας τις διεπαφές που ορίζουν τα διάφορα πρότυπα σε διάφορα αρχιτεκτονικά επίπεδα κατά τη σχεδίαση [41]. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

56 4. Μεθοδολογία ΜΟΝΤΕΛΟΠΟΙΗΣΗ ΜΗ ΛΕΙΤΟΥΡΓΙΚΩΝ ΑΠΑΙΤΗΣΕΩΝ ΛΟΓΙΣΜΙΚΟΥ ΣΕ ΜΟΝΤΕΛΑ ΔΙΑΔΙΚΤΥΑΚΩΝ ΣΥΣΤΗΜΑΤΩΝ REST Στο κεφάλαιο αυτό παρουσιάζεται όλη μεθοδολογία που ακολουθήθηκε για την επίτευξη των στόχων της διπλωματικής. 4.1 Γενικά H παρούσα διπλωματική εργασία έχει ως στόχο την επέκταση του ήδη υπάρχοντος δισδιάστατου μηχανισμού μοντελοστραφούς σχεδίασης διαδικτυακών υπηρεσιών REST, S-CASE, ώστε να μπορεί να λαμβάνει υπόψη και μη λειτουργικές απαιτήσεις. Αυτό θα το επιτυγχάνει εισάγοντας πρότυπα σχεδίασης που τις ικανοποιούν, ενσωματώνοντας επιπλέον περιορισμούς και λειτουργικότητα στην παραγόμενη υπηρεσία. Οι πιο συνήθεις μη λειτουργικές απαιτήσεις που συναντώνται στα περισσότερα συστήματα λογισμού είναι οι εξής: Έλεγχος συστήματος Παρακολούθηση συμβάντων (audit trail). Είναι πολύ σημαντικό, για την καταγραφή κακόβουλων ενεργειών σε ένα σύστημα, για την αναγνώριση σφαλμάτων αλλά και για στατιστικούς λόγους να γίνεται κάποιου είδους παρακολούθηση (auditing) σε συγκεκριμένους πόρους. Παράδειγμα οι κινήσεις σε έναν τραπεζικό λογαριασμό, όταν ο λογαριασμός είναι κοινός μεταξύ 2 ή περισσότερων ατόμων. Reporting. Πολλές φορές υπάρχει ανάγκη ώστε να γίνονται αναφορές. Για παράδειγμα κατά την χρέωση ενός λογαριασμού, ο κάτοχος του θα ήθελε να ενημερώνεται για την ενέργεια αυτή. Συμβατότητα. Είναι θεμιτό μια παραγόμενη υπηρεσία να είναι συμβατή με ήδη υπάρχοντα κομμάτια κώδικα και τεχνολογίες. Επεκτασιμότητα. Η προσθήκη νέων λειτουργικών σε ένα υπάρχον σύστημα λογισμικού και η επιπλέον παραμετροποίησή του όταν αυτό είναι υπό εκτέλεση. Εύκολη τροποποίηση κώδικα. Ένα σύστημα λογισμικού πρέπει να είναι ευανάγνωστο και να μπορεί να τροποποιηθεί εύκολα. Επαναχρησιμοποίηση κώδικα. Είναι θεμιτό κομμάτια κώδικα να μπορούν να επαναχρησιμοποιηθούν. Διατηρησιμότητα. Ένα σύστημα πρέπει να είναι διατηρήσιμο. Να μπορεί να επεκταθεί και να αναβαθμιστεί έτσι ώστε να μπορεί να εκτελεστεί παρά την αλλαγή των τεχνολογιών με τις οποίες συνδέεται. Κάποιες μη λειτουργικές απαιτήσεις για μια RESTful υπηρεσία. Πολλαπλές αναπαραστάσεις πόρων και έλεγχος πρόσβασης και προσπέλασης δεδομένων. Σε πολλές RESTful υπηρεσίες απαιτείται η ύπαρξη ενός μηχανισμού που θα δημιουργεί αναπαραστάσεις πόρου έναν πόρο αντίγραφο με ιδιότητες ένα υποσύνολο των ιδιοτήτων του αρχικού πόρου. Οι αναπαραστάσεις αυτές μπορούν να χρησιμοποιηθούν για τον έλεγχο των πληροφοριών που βλέπει ένας πελάτης. Δυνατότητα απομνημόνευσης παλαιότερης κατάστασης πόρων και ανάκτησης παλαιότερων καταστάσεων. Εξ ορισμού, ένα RESTful API είναι stateless (χωρίς κατάσταση), λόγος στον οποίο οι περισσότερες RESTful υπηρεσίες δεν κρατούν ιστορικό καταστάσεων. Πολλές φορές όμως συναντάται η α- νάγκη διατήρησης ιστορικού των καταστάσεων έτσι ώστε να μπορεί να εκτελεστεί ένας μηχανισμός rollback. Παράδειγμα ένα edit σε ένα post σε ένα blog και η επιλογή undo. Στον παρακάτω πίνακα φαίνεται συνοπτικά μια αντιστοίχιση ανάμεσα σε πρότυπα σχεδίασης και λειτουργικές απαιτήσεις που αυτά θα καλύψουν: ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

57 Πίνακας 6. Μη λειτουργικές απαιτήσεις και πρότυπα σχεδίασης που μπορούν να τις καλύψουν. Χτίστη Παρατηρητή Μνήμης Γέφυρας Πρότυπο ΜΛΑ Έλεγχος Συστήματος Reporting Συμβατότητα Επεκτασιμότητα Διατηρησιμότητα Εύκολη Τροποποίηση Επαναχρησιμοποίηση Πολλαπλές αναπαραστάσεις πόρων Έλεγχος πρόσβασης στα δεδομένα Δυνατότητα απομνημόνευσης και ανάκτησης παλαιότερης κατάστασης ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

58 4.2 S-CASE ΜΟΝΤΕΛΟΠΟΙΗΣΗ ΜΗ ΛΕΙΤΟΥΡΓΙΚΩΝ ΑΠΑΙΤΗΣΕΩΝ ΛΟΓΙΣΜΙΚΟΥ ΣΕ ΜΟΝΤΕΛΑ ΔΙΑΔΙΚΤΥΑΚΩΝ ΣΥΣΤΗΜΑΤΩΝ REST Το S-CASE είναι το σύστημα δισδιάστατους μοντελοστραφούς σχεδίασης διαδικτυακών υπηρεσιών REST που θα επεκταθεί, καθώς, όπως αναφέρθηκε σε προηγούμενη ενότητα, είναι αυτό που επιτυγχάνει την καλύτερη κάλυψη των απαιτήσεων του 3 ου επιπέδου του RMM. Στην πραγματικότητα, το S-CASE αποτελεί ένα εργαλείο το οποίο παρέχει σε στους χρήστες του τη δυνατότητα να επιταχύνουν τη διαδικασία ανάπτυξης ενός RESTful Web API. Το σύστημα αποτελείται από δύο ξεχωριστά στοιχεία, το Reqs2Specs και το MDE Engine. Τα δύο αυτά στοιχεία είναι επεκτάσεις του Eclipse και μπορούν να χρησιμοποιηθούν πάνω σε αυτόν. Το Req2Specs περιλαμβάνει ένα σύνολο εργαλείων για τη συγγραφή, εισαγωγή λειτουργικών απαιτήσεων και σεναρίων χρήσης καθώς και κάποιες μεθοδολογίες μετασχηματισμού των παραπάνω σε μοντέλα. Το MDE engine εκτελεί την αλληλουχία δημιουργίας και μετασχηματισμό μοντέλων, όπως αυτή ορίζεται στο πρότυπο MDA. Η επέκταση της παρούσας διπλωματικής εφαρμόζεται συγκεκριμένα στο 2 ο κομμάτι του S-CASE, στο MDE engine. Περισσότερα για το S-CASE εδώ [38]. Τo MDE Engine του S-CASE απαρτίζεται από 4 ξεχωριστά συστατικά, κάθε ένα από τα οποία αντιστοιχίζεται σε μία από τις φάσης της δισδιάστατης μοντελοστραφούς σχεδίασης. Στην Εικόνα 27 φαίνεται συνοπτικά η δομή αυτή. Είσοδος από το S-CASE ontology Παραγόμενη από το σύστημα υπηρεσία CIM Generator m2m PIM Generator m2m PSM Generator m2r Code Generator CIM Model PIM Model PSM Model Εικόνα 27. Οι 4 φάσεις της δισδιάστατης μοντελοστραφούς σχεδίασης Ο CIM Generator, λαμβάνοντας υπόψιν το CIM μεταμοντέλο που έχει οριστεί, παράγει του το CIM μοντέλο του οραματιζόμενου συστήματος σε μορφή XMI. Το τελευταίο δίνεται ως είσοδο στον PIM Generator, ο οποίος με τη σειρά του, λαμβάνοντας υπόψιν το PIM μεταμοντέλο που έχει οριστεί, παράγει το PIM μοντέλο του οραματιζόμενου συστήματος σε μορφή XMI. Η κύρια διαφορά μεταξύ του CIM και του PIM μοντέλου είναι ότι στο δεύτερο έχουν εισαχθεί αφαιρέσεις και έννοιες της αρχιτεκτονικής ενός RESTful συστήματος. Το PIM μοντέλο δίνεται στη συνέχεια ως είσοδος στον PSM Generator, ο οποίος παράγει το PSM μοντέλο του οραματιζόμενου συστήματος, το οποίο είναι προσαρμοσμένο στο PSM μεταμοντέλο. Το PSM μοντέλο, επίσης εκφρασμένο σε μορφή XMI, ορίζει συγκεκριμένες τεχνολογίες (γλώσσες προγραμματισμού), εξωτερικά συστήματα που θα χρησιμοποιηθούν κλπ. Το παραγόμενο PSM μοντέλο εμπεριέχει όλη την απαραίτητη πληροφορία για την αυτοματοποίηση της παραγωγής του τελικού κώδικα, καθώς και τις οδηγίες χτισίματος της υπηρεσίας. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

59 4.3 Η μορφή της επέκτασης Γενικά Η κύρια ιδέα πίσω από την επέκταση του μηχανισμού MDE Engine είναι αυτή της χρήσης σημειώσεων παρατηρήσεων (annotations) σε ήδη υπάρχουσες έννοιες και μεταμοντέλα. Αυτές οι παρατηρήσεις μπορούν είτε να αλλάζουν εντελώς το νόημα μιας σχεδίασης ή μιας ιδέας είτε να εισάγουν νέες έννοιες οι οποίες είναι συσχετισμένες με τις ήδη υπάρχουσες και επαυξάνουν τη λειτουργικότητα του συστήματος. Τα μεταμοντέλα επεκτάσεις που προκύπτουν παρέχουν γενικές σχεδιαστικές ιδέες. Στην παρακάτω εικόνα φαίνεται η γενική μορφή ενός τέτοιου μεταμοντέλου επέκτασης. Εικόνα 28. Γενική μορφή ενός μεταμοντέλου - επέκτασης του S-CASE Κάθε μοντέλο επέκταση περιέχει τα στοιχεία στα οποία γίνεται η παρατήρηση, τα οποία είναι στοιχεία που συμμορφώνονται στο μεταμοντέλο που επεκτείνεται, καθώς επίσης και στις παρατηρήσεις, τα στοιχεία δηλαδή που επεκτείνουν ή διαφοροποιούν τις υπάρχουσες ιδέες. Η επέκταση που υλοποιείται στη διπλωματική αυτή, ακολουθεί ακριβώς το ίδιο μοντέλο αρχιτεκτονικής MDΑ που ακολουθείται και στο S-CASE για τις επεκτάσεις του. Εικόνα 29. Αρχιτεκτονικό μοντέλο MDA για την επέκταση που προτείνεται. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

60 Στην Εικόνα 29 φαίνεται συνοπτικά ο μηχανισμός του 2D MDE Engine. Μπορεί να παρατηρήσει κανείς ότι οι τέσσερις φάσεις της MDA αρχιτεκτονικής είναι παρούσες. Παρόλα αυτά, κάθε φάση πλέον έχει πολλά μεταμοντέλα στα οποία υπακούει, ένα επιπλέον για κάθε επέκταση σε κάθε επίπεδο. Τα πορτοκαλί βέλη αναπαριστούν τους ATL model-to-model μετασχηματισμούς ενώ τα πράσινα βέλη αναπαριστούν τις εισόδους των μοντέλων στους μηχανισμούς του μετασχηματισμού. Οι μετασχηματισμό Core CIM to Core PIM και Core PIM to Core PSM παραμένουν αμετάβλητοι. Οι επιπλέον μετασχηματισμοί που απαιτούνται είναι εντελώς ανεξάρτητοι από τους προηγούμενους. Στο τελευταίο στάδιο, το στάδιο της παραγωγής του κώδικα, ο μετασχηματισμός πλέον δέχεται ως είσοδο και το μεταμοντέλο του πυρήνα αλλά και το μεταμοντέλο της επέκτασης. Ορίστηκαν τρία νέα μεταμοντέλα επεκτάσεις για τους σκοπούς της διπλωματικής, το DesignPatternsLayerCIM, το DesignPatternsLayerPIM και το DesignPatternsLayerPSM, σύμφωνα με τα οποία, η επέκταση σε κάθε φάση της θα παράγει το αντίστοιχο μοντέλο σε μορφή XMI. Σε πρώτη φάση, με τη χρήση ενός εξειδικευμένου wizard που θα παρουσιαστεί σε επόμενη ενότητα, το υποσύστημα DesignPatternsLayerCIM Model Generator παράγει το μοντέλο της οραματιζόμενης επέκτασης πάνω στη ήδη ορισμένο σύστημα. Το μοντέλο αυτό είναι σε μορφή XMI και συμμορφώνεται στο DesignPatternsLayerCIM μεταμοντέλο. Μέσω του DesignPatternsLayerCIMtoPIM m2m μετασχηματισμού παράγεται το DesignPatternsLayerPΙM model, το οποίο είναι εκφρασμένο σε μορφή XMI και συμμορφώνεται στο DesignPatternsLayerPIM μεταμοντέλο. Στη συνέχεια λαμβάνει χώρα ένας δεύτερος ATL m2m μετασχηματισμός Design- PatternsLayerPIMtoPSM, χάρη στον οποίο παράγεται το DesignPatternsLayerPSM μοντέλο του συστήματος, εκφρασμένο σε μορφή XMI και συμμορφωμένο με τους κανόνες του DesignPatternsLayerPSM μεταμοντέλου. Πίνακας 7. Συνοπτική περιγραφή των μοντέλων και των μεταμοντέλων της επέκτασης. Μεταμοντέλο DesignPatternsLayerCIM Metamodel DesignPatternsLayerCIM Model DesignPatternsLayerPIM Metamodel DesignPatternsLayerPIM Model DesignPatternsLayerPSM Metamodel DesignPatternsLayerPSM Metamodel Επεξήγηση Tο μεταμοντέλο αυτό ορίζει τους κανόνες που αφορούν το DesignPatternsLayerCIM μοντέλο. Το μοντέλο που περιγράφει πλήρως τις απαιτήσεις και τις προδιαγραφές των απαιτήσεων των ΜΛΑ που πρόκειται να καλυφθούν από την επέκταση. Tο μεταμοντέλο αυτό ορίζει τους κανόνες που αφορούν το DesignPatternsLayerPIM μοντέλο. Tο μοντέλο που παραμένει ανεξάρτητο της πλατφόρμας υλοποίησης αλλά ταυτόχρονα περιγράφει σαφώς τον τρόπο με τον οποίο το σύστημα θα καλύψει τις ΜΛΑ. Tο μεταμοντέλο αυτό ορίζει τους κανόνες που αφορούν το DesignPatternsLayerPSM μοντέλο. Το μοντέλο που περιγράφει πλήρως τη λειτουργικότητα του συστήματος εκφρασμένο σε συγκεκριμένη πλατφόρμα. Στις επόμενες ενότητες παρουσιάζονται τα βασικά στοιχεία των τριών μεταμοντέλων που ορίστηκαν. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

61 4.3.2 Γενικά στοιχεία του DesignPatternsLayerCIM μεταμοντέλου Στην ενότητα αυτή παρουσιάζονται τα γενικά στοιχεία DesignPatternsLayerCIM μεταμοντέλου. Εικόνα 30. Απλοποιημένο DesignPatternsLayerCIM μεταμοντέλο AnnotationModel Σύνοψη: To στοιχείο AnnotationModel είναι η ρίζα του μεταμοντέλου επέκτασης DesignPatternsLayerCIM και αποτελείται από όλα τα εισαγόμενα annotations και τα ήδη υπάρχοντα στοιχεία του Core CIM στα οποία εφαρμόζονται τα annotations με στόχο την επαύξηση της ιδέας που τα διέπει. Ιδιότητες: Πίνακας 8. Ιδιότητες του AnnotationModel του DesignPatternsLayerCIM μεταμοντέλου Όνομα Τύπος Πολλαπλότητα Επεξήγηση name Estring 1 Το όνομα του στοιχείου ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

62 Συσχετίσεις: ΜΟΝΤΕΛΟΠΟΙΗΣΗ ΜΗ ΛΕΙΤΟΥΡΓΙΚΩΝ ΑΠΑΙΤΗΣΕΩΝ ΛΟΓΙΣΜΙΚΟΥ ΣΕ ΜΟΝΤΕΛΑ ΔΙΑΔΙΚΤΥΑΚΩΝ ΣΥΣΤΗΜΑΤΩΝ REST Πίνακας 9. Συσχετίσεις του AnnotationModel του DesignPatternsLayerCIM μεταμοντέλου Συσχέτιση με στοιχείο Τύπος Πολλαπλότητα Δομικοί Περιορισμοί CIM AnnotatedElement Composition Σύνθεση 1..* Κάθε AnnotationModel πρέπει να εχει τουλάχιστον ένα AnnotatedElement Annotation Composition 1..* Κάθε AnnotationModel πρέπει να έχει τουλάχιστον ένα Annotation AnnotatedElement Σύνοψη: Το στοιχείο AnnotatedElement μοντελοποιεί ένα υπάρχον στοιχείο του Core CIM μεταμοντέλου, πάνω στο οποίο θα εφαρμοστεί η ιδέα της επέκτασης. Ιδιότητες: Συσχετίσεις: Το AnnotatedElement δεν έχει ιδιότητες Το AnnotatedElement δεν έχει συσχετίσεις Annotation Σύνοψη: Το Annotation μοντελοποιεί νέες ιδέες ή σχεδιάσεις που θα προσαρμοστούν σε ένα στοιχείο του Core CIM μεταμοντέλου Ιδιότητες: Συσχετίσεις: Το Annotation δεν έχει ιδιότητες. Το Annotation δεν έχει συσχετίσεις AnnCRDUActivity Σύνοψη: Το στοιχείο AnnCRUDActivity μοντελοποιεί το υπάρχον CRUDActivity του CORE CIM μοντέλου στο ο- ποίο μπορεί να πραγματοποιηθεί annotation από το DesignPatternsLayerCIM μεταμοντέλο. Ιδιότητες: Πίνακας 10.Ιδιότητες του AnnCRUDActivity του DesignPatternsLayerCIM μεταμοντέλου. Όνομα Τύπος Πολλαπλότητα Περιγραφή name EString 1 Το όνομα του CORE CIM μοντέλου CRUDActivity στο οποίο θα πραγματοποιηθεί annotation ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

63 Συσχετίσεις: ΜΟΝΤΕΛΟΠΟΙΗΣΗ ΜΗ ΛΕΙΤΟΥΡΓΙΚΩΝ ΑΠΑΙΤΗΣΕΩΝ ΛΟΓΙΣΜΙΚΟΥ ΣΕ ΜΟΝΤΕΛΑ ΔΙΑΔΙΚΤΥΑΚΩΝ ΣΥΣΤΗΜΑΤΩΝ REST Πίνακας 11. Συσχετίσεις του AnnCRUDActivity του DesignPatternsLayerCIM μεταμοντέλου. Συσχέτιση με στοιχείο Τύπος Πολλαπλότητα Δομικοί Περιορισμοί CIM CRUDAvtivity Reference 1 To στοιχείο AnnCRUDActivity πρέπει πάντα να συσχετίζεται με ακριβώς ένα CRUDActivity στοιχείο του Core CIM μοντέλου. Είναι το CRUDActivity πάνω στο οποίο θα εφαρμοστεί ένα annotation AnnProperty Σύνοψη: Το στοιχείο AnnProperty μοντελοποιεί ένα υπάρχον στοιχείο Propety του Core CIM μοντέλου στο οποίο μπορεί να πραγματοποιηθεί annotation από το DesignPatternsLayerCIM μεταμοντέλο. Ιδιότητες: Συσχετίσεις: To στοιχείο AnnProperty δεν έχει ιδιότητες. Πίνακας 12. Συσχετίσεις του AnnProperty του DesignPatternsLayerCIM μεταμοντέλου. Συσχέτιση με στοιχείο Τύπος Πολλαπλότητα Δομικοί Περιορισμοί CIM Property Reference 1 Το στοιχείο AnnProperty πρέπει να συσχετίζεται με ακριβώς ένα στοιχείο Property του Core CIM μοντέλου AnnResource Σύνοψη: Το στοιχείο AnnResource μοντελοποιεί ένα υπάρχον στοιχείο Resource του Core CIM μοντέλου στο οποίο μπορεί να πραγματοποιηθεί annotation από το DesignPatternsLayerCIM μεταμοντέλο. Ιδιότητες: To στοιχείο AnnResource δεν έχει ιδιότητες. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

64 Συσχετίσεις: ΜΟΝΤΕΛΟΠΟΙΗΣΗ ΜΗ ΛΕΙΤΟΥΡΓΙΚΩΝ ΑΠΑΙΤΗΣΕΩΝ ΛΟΓΙΣΜΙΚΟΥ ΣΕ ΜΟΝΤΕΛΑ ΔΙΑΔΙΚΤΥΑΚΩΝ ΣΥΣΤΗΜΑΤΩΝ REST Πίνακας 13. Συσχετίσεις του AnnResource του DesignPatternsLayerCIM μεταμοντέλου. Συσχέτιση με στοιχείο Τύπος Πολλαπλότητα Δομικοί Περιορισμοί CIM Resource Reference 1 Το στοιχείο AnnResource πρέπει να συσχετίζεται με ακριβώς ένα στοιχείο Resource του Core CIM μοντέλου AnnAlgoResource Σύνοψη: Το στοιχείο AnnAlgoResource μοντελοποιεί ένα υπάρχον στοιχείο Resource του Core CIM μοντέλου, το οποίο έχει την ιδιότητα isalgorithmic να είναι true, στο οποίο μπορεί να πραγματοποιηθεί annotation από το DesignPatternsLayerCIM μεταμοντέλο. Ιδιότητες: Συσχετίσεις: To AnnAlgoResource δεν έχει ιδιότητες. Πίνακας 14. Συσχετίσεις του AnnAlgoResource του DesignPatternsLayerCIM μεταμοντέλου. Συσχέτιση με στοιχείο Τύπος Πολλαπλότητα Δομικοί Περιορισμοί CIM Resource reference 1 Το στοιχείο AnnResource πρέπει να συσχετίζεται με ακριβώς ένα στοιχείο Resource του Core CIM μοντέλου το οποίο έχει την isalgorithmic ιδιότητα true DesignPattern Σύνοψη: To στοιχείο DesignPattern μοντελοποιεί μια σημείωση παρατήρηση (annotation) του DesignPatternsLayerCIM μεταμοντέλου. Στόχος του είναι να ενσωματώσει την πληροφορία του προτύπου σχεδίασης που θα ενσωματωθεί στο παραγόμενο σύστημα. Ιδιότητες: Συσχετίσεις: Το DesignPattern δεν έχει ιδιότητες. Πίνακας 15. Συσχετίσεις του DesignPattern του DesignPatternsLayerCIM μεταμοντέλου. Συσχέτιση με στοιχείο Τύπος Πολλαπλότητα Δομικοί Περιορισμοί CIM Annotation super type Το DesignPattern επεκτείνει το στοιχείο Annotation ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

65 DesignPatternModel Σύνοψη: To στοιχείο DesignPatternModel μοντελοποιεί ένα annotation του DesignPatternsLayerCIM μεταμοντέλου. Στόχος του είναι να ενσωματώσει την πληροφορία για συστήματα τα οποία θα έχουν παραπάνω από ένα πρότυπα σχεδίασης σε έναν πόρο. Ιδιότητες: Συσχετίσεις: Το DesignPatternModel δεν έχει ιδιότητες. Πίνακας 16. Συσχετίσεις του DesignPatternModel του DesignPatternsLayerCIM μεταμοντέλου. Συσχέτιση με στοιχείο Τύπος Πολλαπλότητα Δομικοί Περιορισμοί CIM Annotation super type Το στοιχείο DesignPatternModel επεκτείνει το στοιχείο Annotation Γενικά στοιχεία του DesignPatternsLayerPIM μεταμοντέλου Στην ενότητα αυτή παρουσιάζονται τα γενικά στοιχεία του DesignPatternsLayerPIM μεταμοντέλου AnnotationModel Σύνοψη: Εικόνα 31. Απλοποιημένο DesignPatternsLayerPIM μεταμοντέλο. Το στοιχείο AnnotationModel είναι η ρίζα του μεταμοντέλου επέκτασης DesignPatternsLayerPIM και αποτελείται από όλα τα εισαγόμενα Annotations και τα ήδη υπάρχοντα στοιχεία του Core PIM στα οποία ε- φαρμόζονται τα Annotations με στόχο την επαύξηση της ιδέας που τα διέπει. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

66 Ιδιότητες: ΜΟΝΤΕΛΟΠΟΙΗΣΗ ΜΗ ΛΕΙΤΟΥΡΓΙΚΩΝ ΑΠΑΙΤΗΣΕΩΝ ΛΟΓΙΣΜΙΚΟΥ ΣΕ ΜΟΝΤΕΛΑ ΔΙΑΔΙΚΤΥΑΚΩΝ ΣΥΣΤΗΜΑΤΩΝ REST Πίνακας 17. Ιδιότητες του AnnotationModel του DesignPatternsLayerPIM μεταμοντέλου. Όνομα Τύπος Πολλαπλότητα Περιγραφή name EString 1 To όνομα του AnnotationModel Συσχετίσεις: Πίνακας 18. Συσχετίσεις του AnnotationModel του DesignPatternsLayerPIM μεταμοντέλου. Συσχέτιση με στοιχείο Τύπος Πολλαπλότητα Δομικοί Περιορισμοί PIM AnnotatedElement composition 1..* Κάθε AnnotationModel πρέπει να εχει τουλάχιστον ένα AnnotatedElement Annotation composition 1..* Κάθε AnnotationModel πρέπει να εχει τουλάχιστον ένα Annotation AnnotatedElement Σύνοψη: Το στοιχείο AnnotatedElement μοντελοποιεί ένα υπάρχον στοιχείο του Core PIM μετα-μοντέλου, πάνω στο οποίο θα εφαρμοστεί η ιδέα της επέκτασης. Ιδιότητες: Συσχετίσεις: Το AnnotatedElement δεν έχει ιδιότητες. Το AnnotatedElement δεν έχει συσχετίσεις Annotation Σύνοψη: Το Annotation μοντελοποιεί νέες ιδέες ή σχεδιάσεις που θα προσαρμοστούν σε ένα στοιχείο του Core PIM μεταμοντέλου Ιδιότητες: Συσχετίσεις: Το Annotation δεν έχει ιδιότητες Το Annotation δεν έχει συσχετίσεις. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

67 AnnCRDUActivityHandler Σύνοψη: Το στοιχείο AnnCRUDActivityHandler μοντελοποιεί το υπάρχον CRUDActivityHandler του CORE PIM μοντέλου στο οποίο μπορεί να πραγματοποιηθεί annotation από το DesignPatternsLayerPIM μεταμοντέλο. Ιδιότητες: Πίνακας 19. Ιδιότητες του AnnCRUDActivityHandler του DesignPatternsLayerPIM μεταμοντέλου. Όνομα Τύπος Πολλαπλότητα Περιγραφή name EString 1 Το όνομα του CORE PIM μοντέλου CRUDActivityHandler στο ο- ποίο θα πραγματοποιηθεί annotation Συσχετίσεις: Πίνακας 20. Ιδιότητες του AnnCRUDActivityHandler του DesignPatternsLayerPIM μεταμοντέλου. Συσχέτιση με στοιχείο Τύπος Πολλαπλότητα Δομικοί Περιορισμοί PIM CRUDAvtivityHandler reference 1 To στοιχείο AnnCRUDActivityHandler πρέπει πάντα να συσχετίζεται με ακριβώς ένα CRU- DActivityHandler στοιχείο του Core PIM μοντέλου. Είναι το CRUDActivityHandler πάνω στο οποίο θα εφαρμοστεί ένα annotation AnnPIMComponentProperty Σύνοψη: Το στοιχείο AnnPIMComponentProperty μοντελοποιεί ένα υπάρχον στοιχείο PIMComponentProperty του Core PIM μοντέλου στο οποίο μπορεί να πραγματοποιηθεί annotation από το DesignPatternsLayerPIM μεταμοντέλο. Ιδιότητες: Συσχετίσεις: To στοιχείο AnnPIMComponentProperty δεν έχει ιδιότητες. Πίνακας 21. Συσχετίσεις του AnnPIMComponentProperty του DesignPatternsLayerPIM μεταμοντέλου. Συσχέτιση με στοιχείο Τύπος Πολλαπλότητα Δομικοί Περιορισμοί PIM PIMComponentProperty reference 1 Το στοιχείο AnnPIMComponentProperty πρέπει να συσχετίζεται με ακριβώς ένα στοιχείο PIMComponentProperty του Core PIM μοντέλου ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

68 AnnResourceModel Σύνοψη: ΜΟΝΤΕΛΟΠΟΙΗΣΗ ΜΗ ΛΕΙΤΟΥΡΓΙΚΩΝ ΑΠΑΙΤΗΣΕΩΝ ΛΟΓΙΣΜΙΚΟΥ ΣΕ ΜΟΝΤΕΛΑ ΔΙΑΔΙΚΤΥΑΚΩΝ ΣΥΣΤΗΜΑΤΩΝ REST Το στοιχείο AnnResourceModel μοντελοποιεί ένα υπάρχον στοιχείο ResourceModel του Core PIM μοντέλου στο οποίο μπορεί να πραγματοποιηθεί annotation από το DesignPatternsLayerPIM μεταμοντέλο. Ιδιότητες: Συσχετίσεις: To στοιχείο AnnResourceModel δεν έχει ιδιότητες. Πίνακας 22. Συσχετίσεις του AnnResourceModel του DesignPatternsLayerPIM μεταμοντέλου. Συσχέτιση με στοιχείο Τύπος Πολλαπλότητα Δομικοί Περιορισμοί PIM ResourceModel reference 1 Το στοιχείο AnnResourceModel πρέπει να συσχετίζεται με ακριβώς ένα στοιχείο Resource- Model του Core PIM μοντέλου AnnAlgoResourceModel Σύνοψη: Το στοιχείο AnnAlgoResourceModel μοντελοποιεί ένα υπάρχον στοιχείο AlgooResourceModel του Core PIM μοντέλου στο οποίο μπορεί να πραγματοποιηθεί annotation από το DesignPatternsLayerPIM μεταμοντέλο. Ιδιότητες: Συσχετίσεις: To AnnAlgoResourceModel δεν έχει ιδιότητες. Πίνακας 23. Συσχετίσεις του AnnAlgoResourceModel του DesignPatternsLayerPIM μεταμοντέλου. Συσχέτιση με στοιχείο Τύπος Πολλαπλότητα Δομικοί Περιορισμοί PIM Resource reference 1 Το στοιχείο AnnAlgoResource- Model πρέπει να συσχετίζεται με ακριβώς ένα στοιχείο AlgoResourceModel του Core PIM μοντέλου DesignPattern Σύνοψη: To στοιχείο DesignPattern μοντελοποιεί μια σημείωση παρατήρηση (annotation) του DesignPatternsLayerPIM μεταμοντέλου. Στόχος του είναι να ενσωματώσει την πληροφορία του προτύπου σχεδίασης που θα ενσωματωθεί στο παραγόμενο σύστημα. Ιδιότητες: Το DesignPattern δεν έχει ιδιότητες. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

69 Συσχετίσεις: ΜΟΝΤΕΛΟΠΟΙΗΣΗ ΜΗ ΛΕΙΤΟΥΡΓΙΚΩΝ ΑΠΑΙΤΗΣΕΩΝ ΛΟΓΙΣΜΙΚΟΥ ΣΕ ΜΟΝΤΕΛΑ ΔΙΑΔΙΚΤΥΑΚΩΝ ΣΥΣΤΗΜΑΤΩΝ REST Πίνακας 24. Συσχετίσεις του DesignPattern του DesignPatternsLayerPIM μεταμοντέλου. Συσχέτιση με στοιχείο Τύπος Πολλαπλότητα Δομικοί Περιορισμοί PIM Annotation super type Το DesignPattern επεκτείνει το στοιχείο Annotation DesignPatternModel Σύνοψη: To στοιχείο DesignPatternModel μοντελοποιεί ένα annotation του DesignPatternsLayerPIM μεταμοντέλου. Στόχος του είναι να ενσωματώσει την πληροφορία για συστήματα τα οποία θα έχουν παραπάνω από ένα πρότυπα σχεδίασης σε έναν πόρο. Ιδιότητες: Συσχετίσεις: Το DesignPatternModel δεν έχει ιδιότητες. Πίνακας 25. Συσχετίσεις του DesignPatternModel του DesignPatternsLayerPIM μεταμοντέλου. Συσχέτιση με στοιχείο Τύπος Πολλαπλότητα Δομικοί Περιορισμοί PIM Annotation super type Το στοιχείο DesignPatternModel επεκτείνει το στοιχείο Annotation ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

70 4.3.4 Γενικά στοιχεία του DesignPatternsLayerPSM μεταμοντέλου Στην ενότητα αυτή παρουσιάζονται τα γενικά στοιχεία DesignPatternsLayerPSM μεταμοντέλου AnnotationModel Σύνοψη: Εικόνα 32. Απλοποιημένο DesignPatternsLayerPSM μεταμοντέλο. Το στοιχείο AnnotationModel είναι η ρίζα του μεταμοντέλου επέκτασης DesignPatternsLayerPSM και αποτελείται από όλα τα εισαγόμενα Annotations και τα ήδη υπάρχοντα στοιχεία του Core PSM στα οποία ε- φαρμόζονται τα Annotations με στόχο την επαύξηση της ιδέας που τα διέπει. Ιδιότητες: Πίνακας 26. Ιδιότητες του AnnotationModel του DesignPatternsLayerPSM μεταμοντέλου. Όνομα Τύπος Πολλαπλότητα Περιγραφή name EString 1 To όνομα του AnnotationModel AnnotationType EString 1 O τύπος του AnnotationModel, δηλαδή από ποιο μοεταμοντέλο παράχθηκε το παραχθέν μοντέλο. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

71 Συσχετίσεις: ΜΟΝΤΕΛΟΠΟΙΗΣΗ ΜΗ ΛΕΙΤΟΥΡΓΙΚΩΝ ΑΠΑΙΤΗΣΕΩΝ ΛΟΓΙΣΜΙΚΟΥ ΣΕ ΜΟΝΤΕΛΑ ΔΙΑΔΙΚΤΥΑΚΩΝ ΣΥΣΤΗΜΑΤΩΝ REST Πίνακας 27. Συσχετίσεις του AnnotationModel του DesignPatternsLayerPSM μεταμοντέλου. Συσχέτιση με στοιχείο Τύπος Πολλαπλότητα Δομικοί Περιορισμοί PSM AnnotatedElement composition 1..* Κάθε AnnotationModel πρέπει να εχει τουλάχιστον ένα AnnotatedElement Annotation composition 1..* Κάθε AnnotationModel πρέπει να εχει τουλάχιστον ένα Annotation AnnotatedElement Σύνοψη: Το στοιχείο AnnotatedElement μοντελοποιεί ένα υπάρχον στοιχείο του Core PSM μετα-μοντέλου, πάνω στο οποίο θα εφαρμοστεί η ιδέα της επέκτασης. Ιδιότητες: Συσχετίσεις: Το AnnotatedElement δεν έχει ιδιότητες. Το AnnotatedElement δεν έχει συσχετίσεις Annotation Σύνοψη: Το Annotation μοντελοποιεί νέες ιδέες ή σχεδιάσεις που θα προσαρμοστούν σε ένα στοιχείο του Core PSM μεταμοντέλου Ιδιότητες: Συσχετίσεις: Το Annotation δεν έχει ιδιότητες. Το Annotation δεν έχει συσχετίσεις. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

72 AnnHTTPActivityHandler Σύνοψη: Το στοιχείο AnnHTTPActivityHandler μοντελοποιεί το υπάρχον HTTPActivityHandler του CORE PSM μοντέλου στο οποίο μπορεί να πραγματοποιηθεί annotation από το DesignPatternsLayerPSM μεταμοντέλο. Ιδιότητες: Πίνακας 28. Ιδιότητες του AnnHTTPActivityHandler του DesignPatternsLayerPSM μεταμοντέλου. Όνομα Τύπος Πολλαπλότητα Περιγραφή name EString 1 Το όνομα του CORE PSM μοντέλου HTTPActivityHandler στο ο- ποίο θα πραγματοποιηθεί annotation Συσχετίσεις: Πίνακας 29 Συσχετίσεις του AnnHTTPActivityHandler του DesignPatternsLayerPSM μεταμοντέλου. Συσχέτιση με στοιχείο Τύπος Πολλαπλότητα Δομικοί Περιορισμοί PSM HTTPActivityHandler reference 1 To στοιχείο AnnHTTPActivityHandler πρέπει πάντα να συσχετίζεται με ακριβώς ένα HTTPActivityHandler στοιχείο του Core PSM μοντέλου. Είναι το HTTPActivityHandler πάνω στο οποίο θα εφαρμοστεί ένα annotation AnnPSMComponentProperty Σύνοψη: Το στοιχείο AnnPSMComponentProperty μοντελοποιεί ένα υπάρχον στοιχείο PSMComponentProperty του Core PSM μοντέλου στο οποίο μπορεί να πραγματοποιηθεί annotation από το DesignPatternsLayerPSM μεταμοντέλο. Ιδιότητες: Συσχετίσεις: To στοιχείο AnnPSMComponentProperty δεν έχει ιδιότητες Πίνακας 30. Συσχετίσεις του AnnPSMComponentProperty του DesignPatternsLayerPSM μεταμοντέλου. Συσχέτιση με στοιχείο Τύπος Πολλαπλότητα Δομικοί Περιορισμοί PSM PSMComponentProperty reference 1 Το στοιχείο AnnPSMComponentProperty πρέπει να συσχετίζεται με ακριβώς ένα στοιχείο PSMComponentProperty του Core PSM μοντέλου ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

73 AnnJavaResourceModel Σύνοψη: Το στοιχείο AnnJavaResourceModel μοντελοποιεί ένα υπάρχον στοιχείο JavaResourceModel του Core PSM μοντέλου στο οποίο μπορεί να πραγματοποιηθεί annotation από το DesignPatternsLayerPSM μεταμοντέλο. Ιδιότητες: Συσχετίσεις: To στοιχείο AnnJavaResourceModel δεν έχει ιδιότητες. Πίνακας 31. Συσχετίσεις του AnnJavaResourceModel του DesignPatternsLayerPSM μεταμοντέλου. Συσχέτιση με στοιχείο Τύπος Πολλαπλότητα Δομικοί Περιορισμοί PSM JavaResourceModel reference 1 Το στοιχείο AnnJavaResourceModel πρέπει να συσχετίζεται με ακριβώς ένα στοιχείο JavaResourceModel του Core PSM μοντέλου AnnJavaAlgoResourceModel Σύνοψη: Το στοιχείο AnnJavaAlgoResourceModel μοντελοποιεί ένα υπάρχον στοιχείο JavaAlgoResourceModel του Core PIM μοντέλου, το οποίο έχει την ιδιότητα isalgorithmic να είναι true, στο οποίο μπορεί να πραγματοποιηθεί annotation από το DesignPatternsLayerCIM μεταμοντέλο. Ιδιότητες: Συσχετίσεις: To AnnJavaAlgoResourceModel δεν έχει ιδιότητες. Πίνακας 32. Συσχετίσεις του AnnJavaAlgoResourceModel του DesignPatternsLayerPSM μεταμοντέλου. Συσχέτιση με στοιχείο Τύπος Πολλαπλότητα Δομικοί Περιορισμοί PSM Resource reference 1 Το στοιχείο AnnJavaAlgoResourceModel πρέπει να συσχετίζεται με ακριβώς ένα στοιχείο JavaAlgoResourceModel του Core PSM μοντέλου DesignPattern Σύνοψη: To στοιχείο DesignPattern μοντελοποιεί μια σημείωση παρατήρηση (annotation) του DesignPatternsLayerPSM μεταμοντέλου. Στόχος του είναι να ενσωματώσει την πληροφορία του προτύπου σχεδίασης που θα ενσωματωθεί στο παραγόμενο σύστημα. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

74 Ιδιότητες: ΜΟΝΤΕΛΟΠΟΙΗΣΗ ΜΗ ΛΕΙΤΟΥΡΓΙΚΩΝ ΑΠΑΙΤΗΣΕΩΝ ΛΟΓΙΣΜΙΚΟΥ ΣΕ ΜΟΝΤΕΛΑ ΔΙΑΔΙΚΤΥΑΚΩΝ ΣΥΣΤΗΜΑΤΩΝ REST Συσχετίσεις: Το DesignPattern δεν έχει ιδιότητες. Πίνακας 33. Συσχετίσεις του DesignPattern του DesignPatternsLayerPSM μεταμοντέλου. Συσχέτιση με στοιχείο Τύπος Πολλαπλότητα Δομικοί Περιορισμοί PIM Annotation super type Το DesignPattern επεκτείνει το στοιχείο Annotation DesignPatternModel Σύνοψη: To στοιχείο DesignPatternModel μοντελοποιεί ένα annotation του DesignPatternsLayerPSM μεταμοντέλου. Στόχος του είναι να ενσωματώσει την πληροφορία για συστήματα τα οποία θα έχουν παραπάνω από ένα πρότυπα σχεδίασης σε έναν πόρο. Ιδιότητες: Συσχετίσεις: Το DesignPatternModel δεν έχει ιδιότητες. Πίνακας 34. Συσχετίσεις του DesignPatternModel του DesignPatternsLayerPSM μεταμοντέλου. Συσχέτιση με στοιχείο Τύπος Πολλαπλότητα Δομικοί Περιορισμοί PSM Annotation super type Το στοιχείο DesignPatternModel επεκτείνει το στοιχείο Annotation Για τα στοιχεία των Core CIM, PIM και PSM μεταμοντέλου μπορεί να ανατρέξει κανείς στα παραδοτέα του S-Case. Παρακάτω παρουσιάζονται ένα προς ένα, όλα τα πρότυπα σχεδίασης τα οποία μπορεί να εφαρμόσει κάποιος στην αυτόματη διαδικασία παραγωγής του κώδικα. Σε κάθε μία από τις παρακάτω υποενότητες παρουσιάζονται διακριτά όλα τα στάδια του MDE Engine για κάθε ένα από τα υλοποιημένα πρότυπα σχεδίασης. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

75 4.3.5 CIM to PIM ATL μετασχηματισμοί για τα γενικά στοιχεία Μετασχηματισμός του AnnotationModel O ATL κανόνας μετασχηματισμού DesignPatternsLayerCIMToPIM, μετασχηματίζει το στοιχείο AnnotationModel από το DesignPatternsLayerCIM μεταμοντέλο στο αντίστοιχό του στο DesignPatternsLayerPIM μεταμοντέλο. Για τον λόγο αυτό, το AnnotationModel του DesignPatternsLayerPIM μεταμοντέλου εμπεριέχει μια αφαιρετική προσέγγιση της ιδέας που εισήγαγε το AnnotationModel του DesignPatternsLayerCIM μεταμοντέλου. Στον παρακάτω πίνακα φαίνεται η αντιστοίχιση ανάμεσα στα δύο μεταμοντέλα. Πίνακας 35. Κανόνας DesignPatternsLayerCIMToPIM. AnnotationModel AnnotationModel Επεξήγηση Name Name Το όνομα του AnnotationModel του Design- PatternsLayerPIM μεταμοντέλου είναι ίδιο με το όνομα του DesignPatternsLayerCIM μεταμοντέλου. AnnotatedElement AnnotatedElement Κάθε AnnotatedElement του DesignPatternsLayerCIM μεταμοντέλου μετασχηματίζεται στο αντίστοιχο AnnotatedElement του DesignPatternsLayerPIM μεταμοντέλο καλώντας είτε τον κανόνα createannresource- Model γα κάθε AnnResource, είτε τον κανόνα createannalgoresourcemodel για κάθε AnnAlgoResourceModel, είτε καλώντας τον κανόνα createannpimcomponentproperty για κάθε AnnProperty, είτε καλώντας τον κανόνα createanncrudactivityhandler για κάθε στοιχείο AnnCRUDActivity. Annotation Annotation Κάθε Annotation του DesignPatternsLayerCIM μεταμοντέλου μετασχηματίζεται στο αντίστοιχο Annotation του DesignPatternsLayer- PIM μεταμοντέλου καλόντας είτε καλώντας τον κανόνα createpimbuilderpattern για κάθε BuilderPattern στοιχείο, είτε καλώντας τον κανόνα reatepimobserverpattern για κάθε στοιχείο ObserverPattern, είτε τον κανόνα createobervableanncrudactivities για κάθε στοιχείο observableanncrudactivity, είτε καλώντας τον κανόνα createpimmementopattern για το στοιχείο MementoPattern, είτε καλώντας τον κανόνα createpimbridgepattern για το στοιχείο BridgePattern Δημιουργία του AnnCRUDActivityHandler O ΑΤL κανόνας createanncrudactivityhandler εισάγει νέα στοιχεία AnnCRUDActivityHandler του μεταμοντέλου DesignPatternsLayerPIM, δεχόμενος ως είσοδο ένα AnnCRUDActivity στοιχείο. Στο CIM μεταμοντέλο δεν υπάρχει αντιστοιχία για το στοιχείο αυτό. Στον παρακάτω πίνακα φαίνεται. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

76 Πίνακας 36. Κανόνας createanncrudactivityhandler. AnnCRUDActivityHandler CRUDActivityandler Επεξήγηση Ο κανόνας αυτός δημιουργεί τη συσχέτιση που έχει ένα AnnCRUDActivityHandler με ένα CRUDActivityHandler του Core PIM μεταμοντέλου Μετασχηματισμός του AnnProperty O ATL κανόνας μετασχηματισμού createannpimcomponentproperty μετασχηματίζει το στοιχείο AnnProperty από το DesignPatternsLayerCIM μεταμοντέλο στο αντίστοιχο AnnPIMComponentProperty του DesignPatternsLayerPIM μεταμοντέλου. Για τον λόγο αυτό, το AnnPMComponentProperty του DesignPatternsLayerPIM μεταμοντέλου εμπεριέχει μια αφαιρετική προσέγγιση της ιδέας που εισήγαγε το στοιχείο Property του DesignPatternsLayerCIM μεταμοντέλου. Στον παρακάτω πίνακα φαίνεται η αντιστοίχιση ανάμεσα στα δύο στοιχεία. Πίνακας 37. Rule createannpimcomponentproperty. AnnProperty AnnPIMComponentProperty Επεξήγηση Property PIMComponentProperty Ο κανόνας αυτός μετασχηματίζει οποιεσδήποτε συσχετίσεις έχει ένα AnnProperty με Property του Core CIM μεταμοντέλου σε συσχετίσεις ανάμεσα σε AnnPIMComponentProperty με PIMComponentProperty του Core PIM μεταμοντέλου Μετασχηματισμός του AnnResource O ATL κανόνας μετασχηματισμού createannresourcemodel μετασχηματίζει το στοιχείο AnnResource από το DesignPatternsLayerCIM μεταμοντέλο στο αντίστοιχο AnnResourceModel του DesignPatternsLayerPIM μεταμοντέλου. Για τον λόγο αυτό, το AnnResourceModel του DesignPatternsLayerPIM μεταμοντέλου εμπεριέχει μια αφαιρετική προσέγγιση της ιδέας που εισήγαγε το στοιχείο AnnResource του DesignPatternsLayerCIM μεταμοντέλου. Στον παρακάτω πίνακα φαίνεται η αντιστοίχιση ανάμεσα στα δύο στοιχεία. Πίνακας 38. Rule createannresourcemodel. AnnResource AnnResourceModel Επεξήγηση Resource ResourceModel Ο κανόνας αυτός μετασχηματίζει οποιεσδήποτε συσχετίσεις έχει ένα AnnResource με Resource του Core CIM μεταμοντέλου σε συσχετίσεις ανάμεσα σε AnnResourceModel με ResourceModel του Core PIM μεταμοντέλου Μετασχηματισμός του AnnAlgoResource O ATL κανόνας μετασχηματισμού createannalgoresourcemodel μετασχηματίζει το στοιχείο AnnAlgoResource από το DesignPatternsLayerCIM μεταμοντέλο στο αντίστοιχο AnnAlgoResourceModel του Design- PatternsLayerPIM μεταμοντέλου. Για τον λόγο αυτό, το AnnAlgoResourceModel του DesignPatternsLayerPIM ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

77 μεταμοντέλου εμπεριέχει μια αφαιρετική προσέγγιση της ιδέας που εισήγαγε το στοιχείο Resource του Design- PatternsLayerCIM μεταμοντέλου που έχει την ιδιότητα isalgorithmic να είναι true. Στον παρακάτω πίνακα φαίνεται η αντιστοίχιση ανάμεσα στα δύο στοιχεία. Πίνακας 39. Rule createannalgoresourcemodel. AnnAlgoResource AnnAlgoResourceModel Επεξήγηση Resource AlgoResourceModel Ο κανόνας αυτός μετασχηματίζει οποιεσδήποτε συσχετίσεις έχει ένα AnnAlgoResource με Resource του Core CIM μεταμοντέλου σε συσχετίσεις ανάμεσα σε AnnAlgoResource- Model με AlgoResourceModel του Core PIM μεταμοντέλου PIM to PSM ATL μετασχηματισμοί για τα γενικά στοιχεία Μετασχηματισμός του AnnotationModel O ATL κανόνας μετασχηματισμού DesignPatternsLayerPIMToPSM, μετασχηματίζει το στοιχείο AnnotationModel από το DesignPatternsLayerPIM μεταμοντέλο στο αντίστοιχό του στο DesignPatternsLayerPSM μεταμοντέλο. Για τον λόγο αυτό, το AnnotationModel του DesignPatternsLayerPSM μεταμοντέλου εμπεριέχει μια υλοποίηση της ιδέας που εισήγαγε το AnnotationModel του DesignPatternsLayerCIM μεταμοντέλου σε συγκεκριμένη τεχνολογία. Στον παρακάτω πίνακα φαίνεται η αντιστοίχιση ανάμεσα στα δύο μεταμοντέλα. Πίνακας 40. Rule DesignPatternsLayerPIMToPSM. AnnotationModel AnnotationModel Επεξήγηση Name Name Το όνομα του AnnotationModel του Design- PatternsLayerPSM μεταμοντέλου είναι ίδιο με το όνομα του DesignPatternsLayerPIM μεταμοντέλου. AnnotatedElement AnnotatedElement Κάθε AnnotatedElement του DesignPatternsLayerPIM μεταμοντέλου μετασχηματίζεται στο αντίστοιχο AnnotatedElement του DesignPatternsLayerPSM μεταμοντέλου καλώντας είτε τον κανόνα createannjavaresourcemodel γα κάθε AnnResourceModel, είτε τον κανόνα createannjavaalgoresource- Model για κάθε AnnAlgoResourceModel, είτε καλώντας τον κανόνα createannpsmcomponentproperty για κάθε AnnPIMComponentProperty, είτε καλώντας τον κανόνα createannjavahttpactivityhandler για κάθε στοιχείο AnnCRUDActivityHandler. Annotation Annotation Κάθε Annotation του DesignPatternsLayerPIM μεταμοντέλου μετασχηματίζεται στο αντίστοιχο Annotation του DesignPatternsLayerPSM μεταμοντέλου καλώντας είτε καλώντας τον κανόνα createpsmbuilderpattern για κάθε BuilderPattern στοιχείο, είτε καλώντας τον κανόνα createpsmobserverpattern για ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

78 Μετασχηματισμός του AnnCRUDActivityHandler κάθε στοιχείο ObserverPattern, είτε τον κανόνα createjavaobservableannhttpactivityhandler για κάθε στοιχείο observableanncrudactivityhandler, είτε καλώντας τον κανόνα createpsmmementopattern για το στοιχείο PIMMementoPattern, είτε καλώντας τον κανόνα createpsmbridgepattern για το στοιχείο BridgePattern. O ATL κανόνας μετασχηματισμού createannjavahttpactivityhandler μετασχηματίζει το στοιχείο AnnCRDUActivityHandler από το DesignPatternsLayerPIM μεταμοντέλο στο αντίστοιχο AnnJavaHTTPActivityHandler του DesignPatternsLayerPSM μεταμοντέλου. Για τον λόγο αυτό, το AnnJavaHTTPActivityHandler του DesignPatternsLayerPSM μεταμοντέλου εμπεριέχει υλοποίηση της ιδέας που εισήγαγε το στοιχείο AnnCRU- DActivityHandler του DesignPatternsLayerPIM μεταμοντέλου. Στον παρακάτω πίνακα φαίνεται η αντιστοίχιση ανάμεσα στα δύο στοιχεία. Πίνακας 41. Rule createannjavahttpactivityhandler. AnnCRUDActivityHandler AnnJavaHTTPActivityHandler Επεξήγηση CRUDActivityHandler HTTPActivityHandler Ο κανόνας αυτός μετασχηματίζει οποιεσδήποτε συσχετίσεις έχει ένα AnnCRUDActivityHandler με CRUDActivityHandler του Core PIM μεταμοντέλου σε συσχετίσεις ανάμεσα σε AnnJavaHTTPActivityHandler με HTTPActivityHandler του Core PSM μεταμοντέλου Μετασχηματισμός του AnnPSMComponentProperty O ATL κανόνας μετασχηματισμού createannpsmcomponentproperty μετασχηματίζει το στοιχείο AnnPIMComponentProperty από το DesignPatternsLayerPIM μεταμοντέλο στο αντίστοιχο AnnPSMComponentProperty του DesignPatternsLayerPSM μεταμοντέλου. Για τον λόγο αυτό, το AnnPMComponentProperty του DesignPatternsLayerPIM μεταμοντέλου εμπεριέχει μια υλοποίηση της ιδέας που εισήγαγε το στοιχείο Property του DesignPatternsLayerCIM μεταμοντέλου σε συγκεκριμένη πλατφόρμα. Στον παρακάτω πίνακα φαίνεται η αντιστοίχιση ανάμεσα στα δύο στοιχεία. Πίνακας 42. Rule createannpsmcomponentproperty. AnnPIMComponentProperty AnnPSMComponentProperty Επεξήγηση PIMComponentProperty PSMComponentProperty Ο κανόνας αυτός μετασχηματίζει οποιεσδήποτε συσχετίσεις έχει ένα AnnPIMComponentProperty με PIMComponentProperty του Core PIM μεταμοντέλου σε συσχετίσεις ανάμεσα σε AnnPSMComponentProperty με PSMComponentProperty του Core PSM μεταμοντέλου Μετασχηματισμός του AnnResource O ATL κανόνας μετασχηματισμού createannjavaresourcemodel μετασχηματίζει το στοιχείο AnnResourceModel από το DesignPatternsLayerPIM μεταμοντέλο στο αντίστοιχό του, το AnnResourceModel του DesignPatternsLayerPIM μεταμοντέλου. Για τον λόγο αυτό, το AnnJavaResourceModel του DesignPatternsLayerPIM μεταμοντέλου εμπεριέχει μια υλοποίηση της ιδέας που εισήγαγε το στοιχείο AnnResourceModel του ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

79 DesignPatternsLayerCIM μεταμοντέλου σε συγκεκριμένη πλατφόρμα. Στον παρακάτω πίνακα φαίνεται η αντιστοίχιση ανάμεσα στα δύο στοιχεία. Πίνακας 43. Rule createannjavaresourcemodel. AnnResourceModel AnnJavaResourceModel Επεξήγηση ResourceModel AnnJavaResourceModel Ο κανόνας αυτός μετασχηματίζει οποιεσδήποτε συσχετίσεις έχει ένα AnnResourceModel με ResourceModel του Core PIM μεταμοντέλου σε συσχετίσεις ανάμεσα σε AnnJavaResourceModel με JavaResourceModel του Core PSM μεταμοντέλου Μετασχηματισμός του AnnAlgoResource O ATL κανόνας μετασχηματισμού createannjavaalgoresourcemodel μετασχηματίζει το στοιχείο AnnAlgoResourceModel από το DesignPatternsLayerPIM μεταμοντέλο στο αντίστοιχό του, το AnnJavaAlgoResourceModel του DesignPatternsLayerPSM μεταμοντέλου. Για τον λόγο αυτό, το AnnJavaAlgoResourceModel του DesignPatternsLayerPSM μεταμοντέλου εμπεριέχει μια υλοποίηση της ιδέας που εισήγαγε το στοιχείο AnnAlgoResourceModel του DesignPatternsLayerPIM μεταμοντέλου σε συγκεκριμένη πλατφόρμα. Στον παρακάτω πίνακα φαίνεται η αντιστοίχιση ανάμεσα στα δύο στοιχεία. Πίνακας 44. Rule createannjavaalgoresourcemodel. AnnAlgoResourceModel AnnJavaAlgoResource- Επεξήγηση Model AlgoResourceModel JavaAlgoResourceModel Ο κανόνας αυτός μετασχηματίζει οποιεσδήποτε συσχετίσεις έχει ένα AnnAlgoResource- Model με AlgoResourceModel του Core PIM μεταμοντέλου σε συσχετίσεις ανάμεσα σε AnnJavaAlgoResourceModel με JavaAlgoResourceModel του Core PIM μεταμοντέλου. 4.4 CIM to PIM Για την κάλυψη των προαναφερθέντων μη λειτουργικών απαιτήσεων επιλέχθηκαν τέσσερα πρότυπα σχεδίασης, τα οποία, αν εφαρμοστούν κατάλληλα, όχι μόνο καλύπτουν τις ΜΛΑ απαιτήσεις, αλλά χτίζουν ένα RESTful API πιο φερέγγυο και πιο ελκυστικό. Παρακάτω παρουσιάζονται συνοπτικά οι στόχοι και η γενική ι- δέα για την υλοποίηση του κάθε προτύπου, τα στοιχεία που μοντελοποιούν το κάθε πρότυπο στα DesignPatternsLayerCIM, DesignPatternsLayerPIM και DesignPatternsLayerPSM μεταμοντέλα, καθώς επίσης και οι model-to-model μετασχηματισμοί Builder Pattern Πρότυπο Χτίστη Γενική Περιγραφή Το πρότυπο Χτίστη (Builder) επιλέχτηκε με σκοπό τη δημιουργία ενός μηχανισμού παραγωγής αναπαραστάσεων όσο το σύστημα βρίσκεται σε εκτέλεση. Μια αναπαράσταση είναι ένα στιγμιότυπο της τρέχουσας κατάστασης ενός πόρου, το οποίο έχει ως ιδιότητες ένα υποσύνολο των ιδιοτήτων του πόρου. Στόχος είναι να μπορεί κάποιος πελάτης να πάρει συγκεκριμένες αναπαραστάσεις με χρήση ερωτημάτων προς τον server, α- ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

80 νάλογα με τις εκάστοτε ανάγκες του, και ο server από την πλευρά του να προσφέρει στους πελάτες συγκεκριμένες αναπαραστάσεις πόρων ανάλογα με την πληροφορία που θέλει να διαμοιράσει. Για παράδειγμα, σε έναν πόρο account με ιδιότητες username, password, , το password είναι ευαίσθητη πληροφορία και πολύ πιθανό να μην πρέπει πάντα κάποιος πελάτης να έχει πρόσβαση σε αυτή παρά την αυθεντικοποίηση που υ- πάρχει ήδη. Το παραπάνω θα υλοποιηθεί με τη χρήση ερωτημάτων με παραμέτρους (query parameter) προς τον server. Κατά τη δημιουργία του DesignPatternsLayerCIM μοντέλου, θα επιτρέπεται στον χρήστη κατά τη ρύθμιση του προτύπου χτίστη, να δημιουργήσει στιγμιότυπα αναπαραστάσεων από όλους τους διαθέσιμους CRUD πόρους. Η πληροφορία αυτή θα αποθηκεύεται στο μοντέλο DesignPatternsLayerCIM του συστήματος. Οι πιθανές αναπαραστάσεις που θα μπορούν να οριστούν για κάθε πόρο θα είναι όσες και τα διαφορετικά υποσύνολα των ιδιοτήτων τους. Κατά την εκτέλεση, όταν ο πελάτης ζητάει την κατάσταση ενός πόρου στον οποίο έχει ενσωματωθεί το πρότυπο χτίστης με HTTP GET ερώτημα, υπάρχουν οι εξής περιπτώσεις: O πελάτης ζήτησε επιτρεπτή αναπαράσταση με το όνομά της Η αναπαράσταση επιστρέφεται Ο πελάτης δεν ζήτησε επιτρεπτή αναπαράσταση Επιστρέφεται το όνομα της προκαθορισμένης αναπαράστασης έτσι ώστε ο πελάτης να ξέρει ποια αναπαράσταση μπορεί να ζητήσει. Εισάγοντας το πρότυπο θα καταφέρουμε να ικανοποιήσουμε τη μη λειτουργική απαίτηση της ύπαρξης πολλαπλών αναπαραστάσεων των πόρων και του ελέγχου πρόσβασης και προσπέλασης σε ευαίσθητα δεδομένα, με ή χωρίς την ύπαρξη αυθεντικοποίησης στο σύστημα. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

81 Στοιχεία που μοντελοποιούν το πρότυπο Χτίστη στο DesignPatternsLayerCIM μεταμοντέλο Εικόνα 33. Στοιχεία που μοντελοποιούν το πρότυπο Χτίστη στο DesignPatternsLayerCIM μεταμοντέλο BuilderPattern Σύνοψη: To στοιχείο BuilderPattern επεκτείνει την πληροφορία που ενσωματώνει το Annotation DesignPattern. Στόχος του είναι να μοντελοποιήσει μέσω των συσχετίσεών του όλη την πληροφορία που απαιτείται για το πρότυπο Χτίστη. Συνδέεται με όλα τα AnnResource στοιχεία πάνω στα οποία θα εφαρμοστεί το πρότυπο Χτίστη. Ιδιότητες: Συσχετίσεις: Το BuilderPattern δεν έχει ιδιότητες. Πίνακας 45. Συσχετίσεις του BuilderPattern του DesignPatternsLayerCIM μεταμοντέλου. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

82 Συσχέτιση με στοιχείο Τύπος Πολλαπλότητα Δομικοί Περιορισμοί CIM AnnResource association 1..* Το στοιχείο BuilderPattern πρέπει να συνδέεται με τουλάχιστον ένα AnnResource. Director composition 1 Κάθε υπηρεσία που παράγεται με το ενσωματωμένο το πρότυπο Χτίστη πρέπει να έχει ακριβώς έναν Director, όπως ορίζει το πρότυπο Χτίστη Director Σύνοψη: To στοιχείο Director μοντελοποιεί την οντότητα Director που χρειάζεται το πρότυπο Χτίστη ώστε να καλεί τους Builders του συστήματος. Ιδιότητες: Συσχετίσεις: Το Director δεν έχει ιδιότητες. Πίνακας 46. Συσχετίσεις του Director του DesignPatternsLayerCIM μεταμοντέλου. Συσχέτιση με στοιχείο Τύπος Πολλαπλότητα Δομικοί Περιορισμοί CIM Builder composition 1..* Kάθε στοιχείο Director πρέπει να συσχετίζεται με composition συσχέτιση με τουλάχιστον ένα στοιχείο Builder Builder Σύνοψη: Το στοιχείο Builder μοντελοποιεί την οντότητα Builder που χρειάζεται το πρότυπο Χτίστη ώστε να ε- κτελεί τη λειτουργικότητά του. Ιδιότητες: Συσχετίσεις: Το Builder δεν έχει ιδιότητες. Πίνακας 47. Συσχετίσεις του Builder του DesignPatternsLayerCIM μεταμοντέλου. Συσχέτιση με στοιχείο Τύπος Πολλαπλότητα Δομικοί Περιορισμοί CIM AnnResource association 1 Κάθε στοιχείο Builder πρέπει να συνδέεται με ακριβώς ένα AnnResource, το AnnResource του Resource του Core CIM μοντέλου που θα χτίζει. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

83 ConcreteBuilder Σύνοψη: ΜΟΝΤΕΛΟΠΟΙΗΣΗ ΜΗ ΛΕΙΤΟΥΡΓΙΚΩΝ ΑΠΑΙΤΗΣΕΩΝ ΛΟΓΙΣΜΙΚΟΥ ΣΕ ΜΟΝΤΕΛΑ ΔΙΑΔΙΚΤΥΑΚΩΝ ΣΥΣΤΗΜΑΤΩΝ REST Το στοιχείο ConcreteBuilder μοντελοποιεί την οντότητα ConcreteBuilder του προτύπου Χτίστη. Κληρονομεί τo στοιχείο Builder και τις συσχετίσεις τoυ και επεκτείνει το σημασιολογικό της περιεχόμενο. Ιδιότητες: Συσχετίσεις: Το ConcreteBuilder δεν έχει ιδιότητες. Πίνακας 48. Συσχετίσεις του ConcreteBuilder του DesignPatternsLayerCIM μεταμοντέλου. Συσχέτιση με στοιχείο Τύπος Πολλαπλότητα Δομικοί Περιορισμοί CIM Representation composition 1 Κάθε στοιχείο ConcreteBuilder πρέπει να συσχετίζεται με composition συσχέτιση με ακριβώς ένα στοιχείο Representation, το Representation ουσιαστικά που μπορεί να χτίζει Representation Σύνοψη: To στοιχείο Representation αποτελεί το προϊόν που παράγει μια οντότητα Χτίστη στο σύστημα. Αποτελεί μια αναπαράσταση ενός Resource του Core CIM μοντέλου και περιέχει Properties του Core CIM μοντέλου. Ιδιότητες: Πίνακας 49. Ιδιότητες του Representation του DesignPatternsLayerCIM μεταμοντέλου. Όνομα Τύπος Πολλαπλότητα Περιγραφή name EString 1 Αποτελεί το όνομα του Representation που δημιουργείται. Συσχετίσεις: Πίνακας 50. Συσχετίσεις του Representation του DesignPatternsLayerCIM μεταμοντέλου. Συσχέτιση με στοιχείο Τύπος Πολλαπλότητα Δομικοί Περιορισμοί CIM AnnResource association 1 Κάθε στοιχείο Representation πρέπει να συνδέεται με ακριβώς ένα στοιχείο AnnResource. Η συσχέτιση αυτή εκφράζει για ποιο Resource χτίζεται το συγκεκριμένο Representation. AnnProperty association 0..* Κάθε στοιχείο Representation πρέπει να συνδέεται με στοιχεία AnnProperty. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

84 Στοιχεία που μοντελοποιούν το πρότυπο Χτίστη στο DesignPatternsLayerPIM μεταμοντέλο Εικόνα 34. Στοιχεία που μοντελοποιούν το πρότυπο Χτίστη στο DesignPatternsLayerPIM μεταμοντέλο BuilderPattern Σύνοψη: To στοιχείο BuilderPattern επεκτείνει την πληροφορία που ενσωματώνει το Annotation DesignPattern. Στόχος του είναι να μοντελοποιήσει μέσω των συσχετίσεών του όλη την πληροφορία που απαιτείται για το πρότυπο Χτίστη. Συνδέεται με όλα τα AnnResourceModel στοιχεία πάνω στα οποία θα εφαρμοστεί το πρότυπο Χτίστη. Ιδιότητες: Το BuilderPattern δεν έχει ιδιότητες. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

85 Συσχετίσεις: ΜΟΝΤΕΛΟΠΟΙΗΣΗ ΜΗ ΛΕΙΤΟΥΡΓΙΚΩΝ ΑΠΑΙΤΗΣΕΩΝ ΛΟΓΙΣΜΙΚΟΥ ΣΕ ΜΟΝΤΕΛΑ ΔΙΑΔΙΚΤΥΑΚΩΝ ΣΥΣΤΗΜΑΤΩΝ REST Πίνακας 51. Συσχετίσεις του BuilderPattern του DesignPatternsLayerPIM μεταμοντέλου. Συσχέτιση με στοιχείο Τύπος Πολλαπλότητα Δομικοί Περιορισμοί PIM AnnResourceModel association 1..* Το στοιχείο BuilderPattern πρέπει να συνδέεται με τουλάχιστον ένα AnnResourceModel. Director composition 1 Κάθε υπηρεσία που παράγεται με το ενσωματωμένο το πρότυπο Χτίστη πρέπει να έχει ακριβώς έναν Director, όπως ορίζει το πρότυπο Χτίστη Director Σύνοψη: To στοιχείο Director μοντελοποεί την οντότητα Director που χρειάζεται το πρότυπο Χτίστη ώστε να καλεί τους Builders του συστήματος. Ιδιότητες: Συσχετίσεις: Το Director δεν έχει ιδιότητες. Πίνακας 52. Συσχετίσεις του Director του DesignPatternsLayerPIM μεταμοντέλου. Συσχέτιση με στοιχείο Τύπος Πολλαπλότητα Δομικοί Περιορισμοί PIM Builder composition 1..* Kάθε στοιχείο Director πρέπει να συσχετίζεται με composition συσχέτιση με τουλάχιστον ένα στοιχείο Builder Builder Σύνοψη: Το στοιχείο Builder μοντελοποιεί την οντότητα Builder που χρειάζεται το πρότυπο Χτίστη ώστε να εκτελεί τη λειτουργικότητά του. Ιδιότητες: Το Builder δεν έχει ιδιότητες. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

86 Συσχετίσεις: ΜΟΝΤΕΛΟΠΟΙΗΣΗ ΜΗ ΛΕΙΤΟΥΡΓΙΚΩΝ ΑΠΑΙΤΗΣΕΩΝ ΛΟΓΙΣΜΙΚΟΥ ΣΕ ΜΟΝΤΕΛΑ ΔΙΑΔΙΚΤΥΑΚΩΝ ΣΥΣΤΗΜΑΤΩΝ REST Πίνακας 53. Συσχετίσεις του Builder του DesignPatternsLayerPIM μεταμοντέλου. Συσχέτιση με στοιχείο Τύπος Πολλαπλότητα Δομικοί Περιορισμοί PIM AnnResourceModel association 1 Κάθε στοιχείο Builder πρέπει να συνδέεται με ακριβώς ένα AnnResourceModel, το AnnResourceModel του Resource- Model του Core PIM μοντέλου που θα χτίζει ConcreteBuilder Σύνοψη: Το στοιχείο ConcreteBuilder μοντελοποιεί την οντότητα ConcreteBuilder του προτύπου Χτίστη. Κληρονομεί τo στοιχείο Builder και τις συσχετίσεις τoυ και επεκτείνει το σημασιολογικό της περιεχόμενο. Ιδιότητες: Συσχετίσεις: Το ConcreteBuilder δεν έχει ιδιότητες. Πίνακας 54. Συσχετίσεις του ConcreteBuilder του DesignPatternsLayerPIM μεταμοντέλου Συσχέτιση με στοιχείο Τύπος Πολλαπλότητα Δομικοί Περιορισμοί PIM Representation composition 1 Κάθε στοιχείο ConcreteBuilder πρέπει να συσχετίζεται με composition συσχέτιση με ακριβώς ένα στοιχείο Representation, το Representation ουσιαστικά που μπορεί να χτίζει Representation Σύνοψη: To στοιχείο Representation αποτελεί το προϊόν που παράγει μια οντότητα Χτίστη στο σύστημα. Αποτελεί μια αναπαράσταση ενός ResourceModel του Core PIM μοντέλου και περιέχει AnnPIMComponentProperty στοιχεία του Core PIM μοντέλου. Ιδιότητες: Πίνακας 55. Ιδιότητες του Representation του DesignPatternsLayerPIM μεταμοντέλου. Όνομα Τύπος Πολλαπλότητα Περιγραφή name Estring 1 Αποτελεί το όνομα του Representation που δημιουργείται. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

87 Συσχετίσεις: ΜΟΝΤΕΛΟΠΟΙΗΣΗ ΜΗ ΛΕΙΤΟΥΡΓΙΚΩΝ ΑΠΑΙΤΗΣΕΩΝ ΛΟΓΙΣΜΙΚΟΥ ΣΕ ΜΟΝΤΕΛΑ ΔΙΑΔΙΚΤΥΑΚΩΝ ΣΥΣΤΗΜΑΤΩΝ REST Πίνακας 56. Συσχετίσεις του Representation του DesignPatternsLayerPIM μεταμοντέλου. Συσχέτιση με στοιχείο Τύπος Πολλαπλότητα Δομικοί Περιορισμοί PIM AnnResourceModel association 1 Κάθε στοιχείο Representation πρέπει να συνδέεται με ακριβώς ένα στοιχείο AnnResource- Model. Η συσχέτιση αυτή εκφράζει για ποιο ResourceModel χτίζεται το συγκεκριμένο Representation. AnnProperty association 0..* Κάθε στοιχείο Representation πρέπει να συνδέεται με στοιχεία AnnPIMComponentProperty. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

88 Στοιχεία που μοντελοποιούν το πρότυπο Χτίστη στο DesignPatternsLayerPSM μεταμοντέλο Εικόνα 35. Στοιχεία που μοντελοποιούν το πρότυπο Χτίστη στο DesignPatternsLayerPSM μεταμοντέλο JavaBuilderPattern Σύνοψη: To στοιχείο JavaBuilderPattern επεκτείνει την πληροφορία που ενσωματώνει το Annotation DesignPattern. Στόχος του είναι να μοντελοποιήσει μέσω των συσχετίσεών του όλη την πληροφορία που απαιτείται για το πρότυπο Χτίστη. Συνδέεται με όλα τα AnnResourceModel στοιχεία πάνω στα οποία θα εφαρμοστεί το πρότυπο Χτίστη. Ιδιότητες: Το JavaBuilderPattern δεν έχει ιδιότητες ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

89 Συσχετίσεις: ΜΟΝΤΕΛΟΠΟΙΗΣΗ ΜΗ ΛΕΙΤΟΥΡΓΙΚΩΝ ΑΠΑΙΤΗΣΕΩΝ ΛΟΓΙΣΜΙΚΟΥ ΣΕ ΜΟΝΤΕΛΑ ΔΙΑΔΙΚΤΥΑΚΩΝ ΣΥΣΤΗΜΑΤΩΝ REST Πίνακας 57. Συσχετίσεις του JavaBuilderPattern του DesignPatternsLayerPSM μεταμοντέλου. Συσχέτιση με στοιχείο Τύπος Πολλαπλότητα Δομικοί Περιορισμοί PSM AnnJavaResourceModel association 1..* Το στοιχείο BuilderPattern πρέπει να συνδέεται με τουλάχιστον ένα AnnJavaResource- Model. JavaDirector composition 1 Κάθε υπηρεσία που παράγεται σε Java με το ενσωματωμένο το πρότυπο Χτίστη πρέπει να έχει ακριβώς έναν JavaDirector, ό- πως ορίζει το πρότυπο Χτίστη JavaDirector Σύνοψη: To στοιχείο JavaDirector μοντελοποεί την οντότητα Director που χρειάζεται το πρότυπο Χτίστη ώστε να καλεί τους Builders του συστήματος. Ιδιότητες: Συσχετίσεις: Το JavaDirector δεν έχει ιδιότητες. Πίνακας 58. Συσχετίσεις του JavaDirector του DesignPatternsLayerPSM μεταμοντέλου. Συσχέτιση με στοιχείο Τύπος Πολλαπλότητα Δομικοί Περιορισμοί PSM JavaBuilder composition 1..* Kάθε στοιχείο JavaDirector πρέπει να συσχετίζεται με composition συσχέτιση με τουλάχιστον ένα στοιχείο JavaBuilder Builder Σύνοψη: Το στοιχείο JavaBuilder μοντελοποιεί την οντότητα Builder που χρειάζεται το πρότυπο Χτίστη ώστε να εκτελεί τη λειτουργικότητά του. Ιδιότητες: Το JavaBuilder δεν έχει ιδιότητες. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

90 Συσχετίσεις: ΜΟΝΤΕΛΟΠΟΙΗΣΗ ΜΗ ΛΕΙΤΟΥΡΓΙΚΩΝ ΑΠΑΙΤΗΣΕΩΝ ΛΟΓΙΣΜΙΚΟΥ ΣΕ ΜΟΝΤΕΛΑ ΔΙΑΔΙΚΤΥΑΚΩΝ ΣΥΣΤΗΜΑΤΩΝ REST Πίνακας 59. Συσχετίσεις του JavaBuilder του DesignPatternsLayerPSM μεταμοντέλου. Συσχέτιση με στοιχείο Τύπος Πολλαπλότητα Δομικοί Περιορισμοί PSM AnnJavaResourceModel association 1 Κάθε στοιχείο JavaBuilder πρέπει να συνδέεται με ακριβώς ένα AnnJavaResourceModel, το AnnJavaResourceModel του JavaResourceModel του Core PSM μοντέλου που θα χτίζει JavaConcreteBuilder Σύνοψη: Το στοιχείο JavaConcreteBuilder μοντελοποιεί την οντότητα ConcreteBuilder του προτύπου Χτίστη. Κληρονομεί τo στοιχείο JavaBuilder και τις συσχετίσεις του και επεκτείνει το σημασιολογικό της περιεχόμενο. Ιδιότητες: Συσχετίσεις: Το JavaConcreteBuilder δεν έχει ιδιότητες. Πίνακας 60. Συσχετίσεις του JavaConcreteBuilder του DesignPatternsLayerPSM μεταμοντέλου. Συσχέτιση με στοιχείο Τύπος Πολλαπλότητα Δομικοί Περιορισμοί PSM JavaRepresentation composition 1 Κάθε στοιχείο JavaConcreteBuilder πρέπει να συσχετίζεται με composition συσχέτιση με ακριβώς ένα στοιχείο Java- Representation, το JavaRepresentation ουσιαστικά που μπορεί να χτίζει JavaRepresentation Σύνοψη: To στοιχείο JavaRepresentation αποτελεί το προϊόν που παράγει μια οντότητα Χτίστη στο σύστημα. Αποτελεί μια αναπαράσταση ενός JavaResourceModel του Core CIM μοντέλου και περιέχει AnnPSMComponentProperty στοιχεία του Core PSM μοντέλου. Ιδιότητες: Πίνακας 61. Ιδιότητες του JavaRepresentation του DesignPatternsLayerPSM μεταμοντέλου. Όνομα Τύπος Πολλαπλότητα Περιγραφή name Estring 1 Αποτελεί το όνομα του JavaRepresentation που δημιουργείται. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

91 Συσχετίσεις: ΜΟΝΤΕΛΟΠΟΙΗΣΗ ΜΗ ΛΕΙΤΟΥΡΓΙΚΩΝ ΑΠΑΙΤΗΣΕΩΝ ΛΟΓΙΣΜΙΚΟΥ ΣΕ ΜΟΝΤΕΛΑ ΔΙΑΔΙΚΤΥΑΚΩΝ ΣΥΣΤΗΜΑΤΩΝ REST Πίνακας 62. Συσχετίσεις του JavaRepresentation του DesignPatternsLayerPSM μεταμοντέλου. Συσχέτιση με στοιχείο PSM Τύπος Πολλαπλότητα Δομικοί Περιορισμοί AnnJavaResourceModel association 1 Κάθε στοιχείο JavaRepresentation πρέπει να συνδέεται με α- κριβώς ένα στοιχείο AnnJava- ResourceModel. Η συσχέτιση αυτή εκφράζει για ποιο Java- ResourceModel χτίζεται το συγκεκριμένο JavaRepresentation. AnnPSMComponentProperty association 0..* Κάθε στοιχείο Representation πρέπει να συνδέεται με στοιχεία AnnPSMComponentProperty Μετασχηματισμοί ATL στοιχείων του προτύπου Χτίστη από το DesignPatternsLayerCIM στο DesignPatternsLayerPIM Μετασχηματισμός τους BuilderPattern O ATL κανόνας μετασχηματισμού createpimbuilderpattern μετασχηματίζει το στοιχείο BuilderPattern από το DesignPatternsLayerCIM μεταμοντέλο στο αντίστοιχο BuilderPattern του DesignPatternsLayerPIM μεταμοντέλου. Για τον λόγο αυτό, το BuilderPattern του DesignPatternsLayerPIM μεταμοντέλου εμπεριέχει μια α- φαιρετική προσέγγιση της ιδέας που εισήγαγε το στοιχείο BuilderPattern του DesignPatternsLayerCIM μεταμοντέλου. Στον παρακάτω πίνακα φαίνεται η αντιστοίχιση ανάμεσα στα δύο στοιχεία. Πίνακας 63. Rule createpimbuilderpattern. BuilderPattern BuilderPattern (PIM) Επεξήγηση AnnResource AnnResourceModel Ο κανόνας αυτός μετασχηματίζει οποιεσδήποτε συσχετίσεις έχει το BuilderPattern με AnnResource του CIM μεταμοντέλου σε συσχετίσεις ανάμεσα σε BuilderPattern με AnnResourceModel του PIM μεταμοντέλου. Director Director (PIM) Ο κανόνας αυτός μετασχηματίζει οποιεσδήποτε συσχετίσεις έχει το BuilderPattern με Director του CIM μεταμοντέλου σε συσχετίσεις ανάμεσα σε BuilderPattern με Director του PIM μεταμοντέλου Μετασχηματισμός του Director O ATL κανόνας μετασχηματισμού createdirector μετασχηματίζει το στοιχείο Director από το Design- PatternsLayerCIM μεταμοντέλο στο αντίστοιχο Director του DesignPatternsLayerPIM μεταμοντέλου. Για τον λόγο αυτό, το Director του DesignPatternsLayerPIM μεταμοντέλου εμπεριέχει μια αφαιρετική προσέγγιση της ιδέας που εισήγαγε το στοιχείο Director του DesignPatternsLayerCIM μεταμοντέλου. Στον παρακάτω πίνακα φαίνεται η αντιστοίχιση ανάμεσα στα δύο στοιχεία. Πίνακας 64. Rule createdirector. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

92 Director Director (PIM) Επεξήγηση Builder Builder Ο κανόνας αυτός μετασχηματίζει οποιεσδήποτε συσχετίσεις έχει το Director με Builder του CIM μεταμοντέλου σε συσχετίσεις ανάμεσα σε Director με Builder του PIM μεταμοντέλου Μετασχηματισμός του ConcreteBuilder O ATL κανόνας μετασχηματισμού createpimconcretebuilder μετασχηματίζει το στοιχείο ConcreteBuilder από το DesignPatternsLayerCIM μεταμοντέλο στο αντίστοιχο ConcreteBuilder του DesignPatternsLayerPIM μεταμοντέλου. Για τον λόγο αυτό, το ConcreteBuilder του DesignPatternsLayerPIM μεταμοντέλου εμπεριέχει μια αφαιρετική προσέγγιση της ιδέας που εισήγαγε το στοιχείο Director του DesignPatternsLayerCIM μεταμοντέλου. Στον παρακάτω πίνακα φαίνεται η αντιστοίχιση ανάμεσα στα δύο στοιχεία. Πίνακας 65. Rule createpimconcretebuilder. ConcreteBuilder ConcreteBuilder (PIM) Επεξήγηση AnnResource AnnResourceModel Ο κανόνας αυτός μετασχηματίζει οποιεσδήποτε συσχετίσεις έχει το ConcreteBuilder με AnnResource του CIM μεταμοντέλου σε συσχετίσεις ανάμεσα σε ConcreteBuilder με AnnResourceModel του PIM μεταμοντέλου. Representation Representation Ο κανόνας αυτός μετασχηματίζει οποιεσδήποτε συσχετίσεις έχει το ConcreteBuilder με Representation του CIM μεταμοντέλου σε συσχετίσεις ανάμεσα σε ConcreteBuilder με Representation του PIM μεταμοντέλου Μετασχηματισμός του Representation O ATL κανόνας μετασχηματισμού createpimrepresentation μετασχηματίζει το στοιχείο Representation από το DesignPatternsLayerCIM μεταμοντέλο στο αντίστοιχό του, το Representation του DesignPatternsLayer- PIM μεταμοντέλου. Για τον λόγο αυτό, το Representation του DesignPatternsLayerPIM μεταμοντέλου εμπεριέχει μια αφαιρετική προσέγγιση της ιδέας που εισήγαγε το στοιχείο Representation του DesignPatternsLayerCIM μεταμοντέλου. Στον παρακάτω πίνακα φαίνεται η αντιστοίχιση ανάμεσα στα δύο στοιχεία. Πίνακας 66. Rule createpimrepresentation. Representation Representation (PIM) Επεξήγηση AnnResource AnnResourceModel Ο κανόνας αυτός μετασχηματίζει οποιεσδήποτε συσχετίσεις έχει το Representation με AnnResource του CIM μεταμοντέλου σε συσχετίσεις ανάμεσα σε Representation με AnnResourceModel του PIM μεταμοντέλου. name name Ο κανόνας αυτός μεταφέρει την ιδιότητα name από το Representation του DesignPatternsLayerCIM αυτούσιο στο Representation του DesignPatternsLayerPIM. name resourceinstanceid Ο κανόνας, χρησιμοποιώντας το name του Representation του DesignPatternsLayerCIM ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

93 δημιουργεί την ιδιότητα resourceinstanceid για το Representation του DesignPatternsLayerPIM. AnnProperty AnnPIMComponentProperty Ο κανόνας αυτός μετασχηματίζει οποιεσδήποτε συσχετίσεις έχει το Representation με AnnProperty του CIM μεταμοντέλου σε συσχετίσεις ανάμεσα σε Representation με AnnPIMComponentProperty του PIM μεταμοντέλου Μετασχηματισμοί ATL στοιχείων του προτύπου Χτίστη από το DesignPatternsLayerPIM στο Design- PatternsLayerPSM Μετασχηματισμός τους BuilderPattern O ATL κανόνας μετασχηματισμού createpsmbuilderpattern μετασχηματίζει το στοιχείο BuilderPattern από το DesignPatternsLayerPIM μεταμοντέλο στο αντίστοιχο JavaBuilderPattern του DesignPatternsLayerPSM μεταμοντέλου. Για τον λόγο αυτό, το JavaBuilderPattern του DesignPatternsLayerPSM μεταμοντέλου εμπεριέχει μια υλοποίηση της προσέγγισης που εισήγαγε το στοιχείο BuilderPattern του DesignPatternsLayerPIM μεταμοντέλου σε συγκεκριμένη πλατφόρμα.. Στον παρακάτω πίνακα φαίνεται η αντιστοίχιση ανάμεσα στα δύο στοιχεία. Πίνακας 67. Rule createpsmbuilderpattern. BuilderPattern BuilderPattern (PSM) Επεξήγηση AnnResourceModel AnnJavaResourceModel Ο κανόνας αυτός μετασχηματίζει οποιεσδήποτε συσχετίσεις έχει το BuilderPattern με AnnResourceModel του PIM μεταμοντέλου σε συσχετίσεις ανάμεσα σε JavaBuilderPattern με AnnJavaResourceModel του PSM μεταμοντέλου. Director JavaDirector Ο κανόνας αυτός μετασχηματίζει οποιεσδήποτε συσχετίσεις έχει το BuilderPattern με Director του Core PIM μεταμοντέλου σε συσχετίσεις ανάμεσα σε JavaBuilderPattern με JavaDirector του PSM μεταμοντέλου Μετασχηματισμός του Director O ATL κανόνας μετασχηματισμού createjavadirector μετασχηματίζει το στοιχείο Director από το DesignPatternsLayerPIM μεταμοντέλο στο αντίστοιχο JavaDirector του DesignPatternsLayerPSM μεταμοντέλου. Για τον λόγο αυτό, το JavaDirector του DesignPatternsLayerPSM μεταμοντέλου εμπεριέχει μια υλοποίηση της προσέγγισης εισήγαγε το στοιχείο Director του DesignPatternsLayerPIM μεταμοντέλου. Στον παρακάτω πίνακα φαίνεται η αντιστοίχιση ανάμεσα στα δύο στοιχεία. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

94 Πίνακας 68. Rule createjavadirector. Director JavaDirector Επεξήγηση Builder JavaBuilder Ο κανόνας αυτός μετασχηματίζει οποιεσδήποτε συσχετίσεις έχει το Director με Builder του PIM μεταμοντέλου σε συσχετίσεις ανάμεσα σε JavaDirector με JavaBuilder του PIM μεταμοντέλου Μετασχηματισμός του ConcreteBuilder O ATL κανόνας μετασχηματισμού createpsmconcretebuilder μετασχηματίζει το στοιχείο ConcreteBuilder από το DesignPatternsLayerPIM μεταμοντέλο στο αντίστοιχo JavaConcreteBuilder του DesignPatternsLayerPSM μεταμοντέλου. Για τον λόγο αυτό, το JavaConcreteBuilder του DesignPatternsLayerPSM μεταμοντέλου εμπεριέχει μια υλοποίηση της προσέγγισης εισήγαγε το στοιχείο Director του DesignPatternsLayerΠIM μεταμοντέλου. Στον παρακάτω πίνακα φαίνεται η αντιστοίχιση ανάμεσα στα δύο στοιχεία. Πίνακας 69. Rule createpsmconcretebuilder. ConcreteBuilder JavaConcreteBuilder (PIM) Επεξήγηση AnnResourceModel AnnJavaResourceModel Ο κανόνας αυτός μετασχηματίζει οποιεσδήποτε συσχετίσεις έχει το ConcreteBuilder με AnnResourceModel του PIM μεταμοντέλου σε συσχετίσεις ανάμεσα σε JavaConcreteBuilder με AnnJavaResourceModel του PSM μεταμοντέλου. Representation JavaRepresentation Ο κανόνας αυτός μετασχηματίζει οποιεσδήποτε συσχετίσεις έχει το ConcreteBuilder με Representation του CIM μεταμοντέλου σε συσχετίσεις ανάμεσα σε JavaConcreteBuilder με JavaRepresentation του PSM μεταμοντέλου Μετασχηματισμός του Representation O ATL κανόνας μετασχηματισμού createpsmrepresentation μετασχηματίζει το στοιχείο Representation από το DesignPatternsLayerCIM μεταμοντέλο στο αντίστοιχό του, το JavaRepresentation του DesignPatternsLayerPSM μεταμοντέλου. Για τον λόγο αυτό, το JavaRepresentation του DesignPatternsLayerPSM μεταμοντέλου εμπεριέχει μια υλοποίηση της προσέγγισης που εισήγαγε το στοιχείο Representation του DesignPatternsLayerPIM μεταμοντέλου. Στον παρακάτω πίνακα φαίνεται η αντιστοίχιση ανάμεσα στα δύο στοιχεία. Πίνακας 70. Rule createpsmrepresentation. Representation JavaRepresentation Επεξήγηση AnnResourceModel AnnJavaResourceModel Ο κανόνας αυτός μετασχηματίζει οποιεσδήποτε συσχετίσεις έχει το Representation με AnnResourceModel του CIM μεταμοντέλου σε συσχετίσεις ανάμεσα σε JavaRepresentation με AnnJavaResourceModel του PIM μεταμοντέλου. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

95 AnnPIMComponentProperty name name Ο κανόνας αυτός μεταφέρει την ιδιότητα name από το Representation του DesignPatternsLayerPCIM αυτούσιο στο JavaRepresentation του DesignPatternsLayerPSM. resourceinstanceid resourceinstanceid Ο κανόνας αυτός μεταφέρει την ιδιότητα resourceinstanceid από το Representation του DesignPatternsLayerPCIM αυτούσιο στο Java- Representation του DesignPatternsLayerPSM. AnnPSMComponentProperty Ο κανόνας αυτός μετασχηματίζει οποιεσδήποτε συσχετίσεις έχει το Representation με AnnPIMComponentProperty του CIM μεταμοντέλου σε συσχετίσεις ανάμεσα σε JavaRepresentation με AnnPSMComponentProperty του PIM μεταμοντέλου Observer Pattern Πρότυπο Παρατηρητή Γενική Περιγραφή Το πρότυπο παρατηρητή επιλέχθηκε με σκοπό τη δημιουργία ενός μηχανισμού παρατήρησης ενεργειών του RESTful συστήματος και αντίδρασης σε αυτές. Οι ενέργειες που θα μπορούν να παρατηρούνται παρακολουθούνται μετά την εισαγωγή του προτύπου αυτού είναι όλα τα HTTP ερωτήματα σε CRUD πόρους. Κατά τη δημιουργία του CIM μοντέλου θα επιτρέπεται η δημιουργία οντοτήτων παρατηρητών observer για όλους τους διαθέσιμους CRUD πόρους. Κάθε ένας observer θα πρέπει να υπακούει παρακολουθεί παρατηρεί ένα CRUD ρήμα για τον πόρο για τον οποίο ορίστηκε. Κατά την εκτέλεση της RESTful υπηρεσίας θα δίνεται η δυνατότητα αρχικοποίησης και εγγραφής ενός παρατηρητή σε μια συγκεκριμένη ενέργεια, η δυνατότητα διαγραφής ενός παρατηρητή από την ενέργεια στην οποία έχει εγγραφεί να παρακολουθεί καθώς και η δυνατότητα επιλογής αποστολής ενημερωτικού για την ενέργεια που παρακολουθεί. Οι τρεις παραπάνω επιλογές θα εκτελούνται με τη χρήση κατάλληλου ερωτήματος PUT προς τον server με τις αντίστοιχες παραμέτρους (query parameters). Οι οντότητες των παρατηρητών αποθηκεύονται στη βάση δεδομένων του συστήματος αλλά δεν αποτελούν πόρους της RESTful υπηρεσίας. Δεν επιτρέπεται δηλαδή η εκτέλεση HTTP ερωτημάτων σε αυτές. Εισάγοντας το πρότυπο αυτό επιτυγχάνεται η ικανοποίηση των ΜΛΑ του ελέγχου συστήματος και της παρακολούθησης συμβάντων και ενεργειών σε αυτό καθώς επίσης και η ΜΛΑ της δημιουργίας αναφορών μέσω των που θα μπορεί να στέλνει το σύστημα ως αντίδραση στην εκτέλεση των HTTP ερωτημάτων. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

96 Στοιχεία που μοντελοποιούν το πρότυπο Παρατηρητή στο DesignPatternsLayerCIM μεταμοντέλο Πίνακας 71. Στοιχεία που μοντελοποιούν το πρότυπο Παρατηρητή στο DesignPatternsLayerCIM μεταμοντέλο ObserverPattern Σύνοψη: To στοιχείο ObserverPattern επεκτείνει την πληροφορία που ενσωματώνει το Annotation DesignPattern. Στόχος του είναι να μοντελοποιήσει μέσω των συσχετίσεών του όλη την πληροφορία που απαιτείται για το πρότυπο Παρατηρητή. Ιδιότητες: Συσχετίσεις: Το ObserverPattern δεν έχει ιδιότητες. Πίνακας 72. Συσχετίσεις του ObserverPattern του DesignPatternsLayerCIM μεταμοντέλου. Συσχέτιση με στοιχείο Τύπος Πολλαπλότητα Δομικοί Περιορισμοί CIM Observer composition 1..* Κάθε στοιχείο ObserverPattern πρέπει να συσχετίζεται με composition συσχέτιση με τουλάχιστον ένα στοιχείο Observer ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

97 Observer Σύνοψη: ΜΟΝΤΕΛΟΠΟΙΗΣΗ ΜΗ ΛΕΙΤΟΥΡΓΙΚΩΝ ΑΠΑΙΤΗΣΕΩΝ ΛΟΓΙΣΜΙΚΟΥ ΣΕ ΜΟΝΤΕΛΑ ΔΙΑΔΙΚΤΥΑΚΩΝ ΣΥΣΤΗΜΑΤΩΝ REST To στοιχείο Observer μοντελοποιεί την οντότητα observer του προτύπου παρατηρητή. Είναι ουσιαστικά η οντότητα που παρακολουθεί τις ενέργειες που έχει οριστεί να παρακολουθούνται στο σύστημα. Ιδιότητες: Πίνακας 73. Ιδιότητες του Observer του DesignPatternsLayerCIM μεταμοντέλου. Όνομα Τύπος Πολλαπλότητα Περιγραφή name String 1 Αποτελεί το όνομα του Observer. Συσχετίσεις: Πίνακας 74. Συσχετίσεις του Observer του DesignPatternsLayerCIM μεταμοντέλου. Συσχέτιση με στοιχείο CIM Τύπος Πολλαπλότητα Δομικοί Περιορισμοί AnnResource association 1 Κάθε στοιχείο Observer θα πρέπει να συνδέεται με ακριβώς ένα AnnResource, το AnnResource του Resource του Core CIM μοντέλου τις ενέργειες του οποίου θα παρακολουθεί. ObservableAnnCRUDActivity association 1 Κάθε στοιχείο Observer θα πρέπει να συνδέεται με ακριβώς ένα ObservableAnnCRUDActivity, το στοιχείο δηλαδή που μοντελοποιεί ε- νέργειες του συστήματος ObservableAnnCRUDActivity Σύνοψη: Το στοιχείο ObservableAnnCRUDActivity μοντελοποιεί την observable οντότητα του προτύπου παρατηρητή. Αποτελεί στην ουσία μια ενέργεια που θα παρακολουθείται στο σύστημα. Επεκτείνει τη λειτουργικότητα ενός ήδη ορισμένου CRUDActivity του Core CIM μοντέλου. Ιδιότητες: Συσχετίσεις: Το ObservalbeAnnCRUDActivity δεν έχει ιδιότητες. Πίνακας 75. Συσχετίσεις του ObservalbeAnnCRUDActivity του DesignPatternsLayerCIM μεταμοντέλου. Συσχέτιση με στοιχείο Τύπος Πολλαπλότητα Δομικοί Περιορισμοί CIM AnnCRUDActivity association 1 Κάθε στοιχείο ObservableAnnCRUDActivity πρέπει να συνδέεται με ακριβώς ένα AnnCRUDActivity, το AnnCRU- DActivity του CRUDActivity του Core CIM μοντέλου που θα παρατηρείται. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

98 AnnResource association 1 Κάθε στοιχείο ObservableAnnCRUDActivity πρέπει να συνδέεται με ακριβώς ένα AnnResource, το AnnResource του Resource του Core CIM μοντέλου για το οποίο το CRUDActivity αποτελεί CRUD ρήμα που παρακολουθείται. Observer association 0..* Το στοιχείο ObservableAnnCRU- DActivity μπορεί να συνδέεται με στοιχεία Observer. Ο λόγος για τον οποίο η πολλαπλότητα είναι έχει κάτω όριο 0 και όχι 1 είναι επειδή μπορεί κάποια χρονική στιγμή το στοιχείο να μην παρακολοθουθείται από κανέναν Observer Στοιχεία που μοντελοποιούν το πρότυπο Παρατηρητή στο DesignPatternsLayerPIM μεταμοντέλο Εικόνα 36. Στοιχεία που μοντελοποιούν το πρότυπο Παρατηρητή στο DesignPatternsLayerPIM μεταμοντέλο ObserverPattern Σύνοψη: To στοιχείο ObserverPattern επεκτείνει την πληροφορία που ενσωματώνει το Annotation DesignPattern. Στόχος του είναι να μοντελοποιήσει μέσω των συσχετίσεών του όλη την πληροφορία που απαιτείται για το πρότυπο Παρατηρητή. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

99 Ιδιότητες: ΜΟΝΤΕΛΟΠΟΙΗΣΗ ΜΗ ΛΕΙΤΟΥΡΓΙΚΩΝ ΑΠΑΙΤΗΣΕΩΝ ΛΟΓΙΣΜΙΚΟΥ ΣΕ ΜΟΝΤΕΛΑ ΔΙΑΔΙΚΤΥΑΚΩΝ ΣΥΣΤΗΜΑΤΩΝ REST Συσχετίσεις: Το ObserverPattern δεν έχει ιδιότητες. Πίνακας 76. Συσχετίσεις του ObserverPattern του DesignPatternsLayerPIM μεταμοντέλου. Συσχέτιση με στοιχείο Τύπος Πολλαπλότητα Δομικοί Περιορισμοί PIM Observer composition 1..* Κάθε στοιχείο ObserverPattern πρέπει να συσχετίζεται με composition συσχέτιση με τουλάχιστον ένα στοιχείο Observer Observer Σύνοψη: To στοιχείο Observer μοντελοποιεί την οντότητα observer του προτύπου παρατηρητή. Είναι ουσιαστικά η οντότητα που παρακολουθεί τις ενέργειες που έχει οριστεί να παρακολουθούνται στο σύστημα. Ιδιότητες: Πίνακας 77. Ιδιότητες του Observer του DesignPatternsLayerPIM μεταμοντέλου. Όνομα Τύπος Πολλαπλότητα Περιγραφή name String 1 Αποτελεί το όνομα του Observer. Συσχετίσεις Πίνακας 78. Συσχετίσεις του Observer του DesignPatternsLayerPIM μεταμοντέλου. Συσχέτιση με στοιχείο PIM Τύπος Πολλαπλότητα Δομικοί Περιορισμοί AnnResourceModel association 1 Κάθε στοιχείο Observer θα πρέπει να συνδέεται με ακριβώς ένα AnnResourceModel, το AnnResourceModel του ResourceModel του Core PIM μοντέλου τις ενέργειες του οποίου θα παρακολουθεί. ObservableAnnCRUDActivityHandler association 1 Κάθε στοιχείο Observer θα πρέπει να συνδέεται με ακριβώς ένα ObservableAnnCRUDActivityHandler, το στοιχείο δηλαδή που μοντελοποιεί ενέργειες του συστήματος ObservableAnnCRUDActivityHandler Σύνοψη Το στοιχείο ObservableAnnCRUDActivityHandler μοντελοποιεί την observable οντότητα του προτύπου παρατηρητή. Αποτελεί στην ουσία μια ενέργεια που θα παρακολουθείται στο σύστημα. Επεκτείνει τη λειτουργικότητα ενός ήδη ορισμένου CRUDActivityHandler του Core PIM μοντέλου. Ιδιότητες: Το ObservalbeAnnCRUDActivityHandler δεν έχει ιδιότητες. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

100 Συσχετίσεις: ΜΟΝΤΕΛΟΠΟΙΗΣΗ ΜΗ ΛΕΙΤΟΥΡΓΙΚΩΝ ΑΠΑΙΤΗΣΕΩΝ ΛΟΓΙΣΜΙΚΟΥ ΣΕ ΜΟΝΤΕΛΑ ΔΙΑΔΙΚΤΥΑΚΩΝ ΣΥΣΤΗΜΑΤΩΝ REST Πίνακας 79. Συσχετίσεις του ObservalbeAnnCRUDActivityHandler του DesignPatternsLayerPIM μεταμοντέλου. Συσχέτιση με στοιχείο PIM AnnCRUDActivityHandler Τύπος Πολλαπλότητα Δομικοί Περιορισμοί association 1 Κάθε στοιχείο ObservableAnnCRUDActivityHandler πρέπει να συνδέεται με ακριβώς ένα AnnCRUDActivityHandler, το AnnCRUDActivityHandler του CRUDActivityHandler του Core PIM μοντέλου που θα παρατηρείται. AnnResourceModel association 1 Κάθε στοιχείο ObservableAnnCRUDActivityHandler πρέπει να συνδέεται με ακριβώς ένα AnnResourceModel, το AnnResourceModel του ResourceModel του Core PIM μοντέλου για το οποίο το CRUDActivityHandler αποτελεί CRUD ρήμα που παρακολουθείται. Observer association 0..* Το στοιχείο ObservableAnnCRU- DActivityHandler μπορεί να συνδέεται με στοιχεία Observer. Ο λόγος για τον οποίο η πολλαπλότητα είναι έχει κάτω όριο 0 και όχι 1 είναι επειδή μπορεί κάποια χρονική στιγμή το στοιχείο να μην παρακολοθουθείται από κανέναν Observer. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

101 Στοιχεία που μοντελοποιούν το πρότυπο Παρατηρητή στο DesignPatternsLayerPSM μεταμοντέλο Εικόνα 37. Στοιχεία που μοντελοποιούν το πρότυπο Παρατηρητή στο DesignPatternsLayerPSM μεταμοντέλο JavaObserverPattern Σύνοψη: To στοιχείο JavaObserverPattern επεκτείνει την πληροφορία που ενσωματώνει το Annotation Design- Pattern. Στόχος του είναι να μοντελοποιήσει μέσω των συσχετίσεών του όλη την πληροφορία που απαιτείται για το πρότυπο Παρατηρητή. Ιδιότητες: Συσχετίσεις: Το JavaObserverPattern δεν έχει ιδιότητες Πίνακας 80. Συσχετίσεις του JavaObserverPattern του DesignPatternsLayerPSM μεταμοντέλου. Συσχέτιση με στοιχείο Τύπος Πολλαπλότητα Δομικοί Περιορισμοί PSM JavaObserver composition 1..* Κάθε στοιχείο JavaObserverPattern πρέπει να συσχετίζεται με composition συσχέτιση με τουλάχιστον ένα στοιχείο JavaObserver ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

102 Σύνοψη: ΜΟΝΤΕΛΟΠΟΙΗΣΗ ΜΗ ΛΕΙΤΟΥΡΓΙΚΩΝ ΑΠΑΙΤΗΣΕΩΝ ΛΟΓΙΣΜΙΚΟΥ ΣΕ ΜΟΝΤΕΛΑ ΔΙΑΔΙΚΤΥΑΚΩΝ ΣΥΣΤΗΜΑΤΩΝ REST To στοιχείο JavaObserver μοντελοποιεί την οντότητα observer του προτύπου παρατηρητή. Είναι ουσιαστικά η οντότητα που παρακολουθεί τις ενέργειες που έχει οριστεί να παρακολουθούνται στο σύστημα. Ιδιότητες: Πίνακας 81. Ιδιότητες του JavaObserver του DesignPatternsLayerPSM μεταμοντέλου. Όνομα Τύπος Πολλαπλότητα Περιγραφή name String 1 Αποτελεί το όνομα του JavaObserver. Συσχετίσεις: Πίνακας 82. Συσχετίσεις του JavaObserver του DesignPatternsLayerPSM μεταμοντέλου. Συσχέτιση με στοιχείο PIM Τύπος Πολλαπλότητα Δομικοί Περιορισμοί AnnJavaResourceModel association 1 Κάθε στοιχείο Observer θα πρέπει να συνδέεται με ακριβώς ένα AnnJavaResourceModel, το AnnJavaResource- Model του JavaResourceModel του Core PSM μοντέλου τις ενέργειες του οποίου JavaObservableAnnHTTPActivityHandler association θα παρακολουθεί. 1 Κάθε στοιχείο Observer θα πρέπει να συνδέεται με ακριβώς ένα JavaObservableAnnHTTPActivityHandler, το στοιχείο δηλαδή που μοντελοποιεί ενέργειες του συστήματος JavaObservableAnnHTTPActivityHandler Σύνοψη: Το στοιχείο JavaObservableAnnHTTPActivityHandler μοντελοποιεί την observable οντότητα του προτύπου παρατηρητή. Αποτελεί στην ουσία μια ενέργεια που θα παρακολουθείται στο σύστημα. Επεκτείνει τη λειτουργικότητα ενός ήδη ορισμένου HTTPActivityHandler του Core PSM μοντέλου. Ιδιότητες: Συσχετίσεις: Το JavaObservableAnnHTTPActivityHandler δεν έχει ιδιότητες. Πίνακας 83. Συσχετίσεις του JavaObserver του DesignPatternsLayerPSM μεταμοντέλου. Συσχέτιση με στοιχείο PIM AnnJavaHTTPActivityHandler Τύπος Πολλαπλότητα Δομικοί Περιορισμοί association 1 Κάθε στοιχείο AnnJavaObservableHTTPActivityHandler πρέπει να συνδέεται με ακριβώς ένα AnnJavaHTTPActivityHandler, το AnnJavaHTTPActivityHandler του HTTPActivityHandler του Core PSM μοντέλου που θα παρατηρείται. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

103 AnnJavaResourceModel association 1 Κάθε στοιχείο JavaObservableAnn- HTTPActivityHandler πρέπει να συνδέεται με ακριβώς ένα AnnJavaResourceModel, το AnnJavaResource- Model του JavaResourceModel του Core PSM μοντέλου για το οποίο το HTTActivityHandler αποτελεί CRUD ρήμα που παρακολουθείται. JavaObserver association 0..* Το στοιχείο JavaObservableAnn- HTTPActivityHandler μπορεί να συνδέεται με στοιχεία JavaObserver. Ο λόγος για τον οποίο η πολλαπλότητα είναι έχει κάτω όριο 0 και όχι 1 είναι επειδή μπορεί κάποια χρονική στιγμή το στοιχείο να μην παρακολουθείται από κανέναν JavaObserver Μετασχηματισμοί ATL στοιχείων του προτύπου Παρατηρητή από το DesignPatternsLayerCIM στο DesignPatternsLayerPIM Μετασχηματισμός του ObserverPattern O ATL κανόνας μετασχηματισμού createpimobserverpattern μετασχηματίζει το στοιχείο ObserverPattern από το DesignPatternsLayerCIM μεταμοντέλο στο αντίστοιχό του, το ObserverPattern του DesignPatternsLayerPIM μεταμοντέλου. Για τον λόγο αυτό, το ObserverPattern του DesignPatternsLayerPIM μεταμοντέλου εμπεριέχει μια αφαιρετική προσέγγιση της ιδέας που εισήγαγε το στοιχείο ObserverPattern του Design- PatternsLayerCIM μεταμοντέλου. Στον παρακάτω πίνακα φαίνεται η αντιστοίχιση ανάμεσα στα δύο στοιχεία. Πίνακας 84. Rule createpimobserverpattern. ObserverPattern ObserverPattern (PIM) Επεξήγηση Observer Observer (PIM) Ο κανόνας αυτός μετασχηματίζει οποιεσδήποτε συσχετίσεις έχει το ObserverPattern με Observer του CIM μεταμοντέλου σε συσχετίσεις ανάμεσα σε ObserverPattern με Observer του PIM μεταμοντέλου Μετασχηματισμός του Observer O ATL κανόνας μετασχηματισμού createpimobserver μετασχηματίζει το στοιχείο Observer από το DesignPatternsLayerCIM μεταμοντέλο στο αντίστοιχό του, το Observer του DesignPatternsLayerPIM μεταμοντέλου. Για τον λόγο αυτό, το Observer του DesignPatternsLayerPIM μεταμοντέλου εμπεριέχει μια αφαιρετική προσέγγιση της ιδέας που εισήγαγε το στοιχείο Observer του DesignPatternsLayerCIM μεταμοντέλου. Στον παρακάτω πίνακα φαίνεται η αντιστοίχιση ανάμεσα στα δύο στοιχεία. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

104 Πίνακας 85. Rule createpimobserver. Observer Observer Επεξήγηση AnnResource AnnResourceModel Ο κανόνας αυτός μετασχηματίζει οποιεσδήποτε συσχετίσεις έχει το Observer με AnnResource του CIM μεταμοντέλου σε συσχετίσεις ανάμεσα σε Observer με AnnResourceModel του PIM μεταμοντέλου. ObservalbeAnnCRUDActivity ObservalbeAnnCRUDActivityHandler Ο κανόνας αυτός μετασχηματίζει οποιεσδήποτε συσχετίσεις έχει το Observer με ObservalbeAnnCRUDActivity του CIM μεταμοντέλου σε συσχετίσεις ανάμεσα σε Observer με ObservalbeAnnCRUDActivityHandler του PIM μεταμοντέλου. name name Ο κανόνας αυτός μεταφέρει την ιδιότητα name από το Observer του DesignPatternsLayerPCIM αυτούσιο στο Observer του DesignPatternsLayerPSM Μετασχηματισμός του ObservableAnnCRUDActivity O ATL κανόνας μετασχηματισμού createobservableanncrudactivityhandler μετασχηματίζει δεχόμενος ως είσοδο το στοιχείο ObservableAnnCRUDActivity από το DesignPatternsLayerCIM μεταμοντέλο στο ObservableAnnCRUDActivityHandler του DesignPatternsLayerPIM μεταμοντέλου. Tο ObservableAnnCRUDActivityHandler του DesignPatternsLayerPIM μεταμοντέλου εμπεριέχει μια αφαιρετική προσέγγιση της ιδέας της παρακολουθούμενης ενέργειας ObservalbeAnnCRUDActivity του DesignPatternsLayerCIM μεταμοντέλου. Στον παρακάτω πίνακα φαίνεται η αντιστοίχιση ανάμεσα στα δύο στοιχεία. Πίνακας 86. Rule createobservableanncrudactivityhandler. ObservableAnnCRUDActivity ObservableAnnCRUDActivityHandler Επεξήγηση AnnResource AnnResourceModel Ο κανόνας αυτός μετασχηματίζει ο- ποιεσδήποτε συσχετίσεις έχει το ObservableAnnCRUDActivity με AnnResource του CIM μεταμοντέλου σε συσχετίσεις ανάμεσα σε ObservableAnnCRUDActivityHandler με AnnResourceModel του PIM μεταμοντέλου. Observer Observer (PIM) Ο κανόνας αυτός μετασχηματίζει ο- ποιεσδήποτε συσχετίσεις έχει το ObservableAnnCRUDActivity με Observer του CIM μεταμοντέλου σε συσχετίσεις ανάμεσα σε ObservableAnnCRUDActivityHandler με Observer του PIM μεταμοντέλου. AnnCRUDActivity AnnCRUDActivityHandler Ο κανόνας αυτός μετασχηματίζει ο- ποιεσδήποτε συσχετίσεις έχει το ObservableAnnCRUDActivity με AnnCRUDActivity του CIM μεταμοντέλου σε συσχετίσεις ανάμεσα σε ObservableAnnCRUDActivityHandler ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

105 με AnnCRUDActivityHandler του PIM μεταμοντέλου Μετασχηματισμοί ATL στοιχείων του προτύπου Παρατηρητή από το DesignPatternsLayerPIM στο DesignPatternsLayerPIM Μετασχηματισμός του ObserverPattern O ATL κανόνας μετασχηματισμού createpsmobserverpattern μετασχηματίζει το στοιχείο ObserverPattern από το DesignPatternsLayerPIM μεταμοντέλο στο αντίστοιχό του, το JavaObserverPattern του DesignPatternsLayerPSM μεταμοντέλου. Για τον λόγο αυτό, το JavaObserverPattern του DesignPatternsLayerPSM μεταμοντέλου εμπεριέχει μια υλοποίηση της προσέγγισης εισήγαγε το στοιχείο ObserverPattern του DesignPatternsLayerPIM μεταμοντέλου. Στον παρακάτω πίνακα φαίνεται η αντιστοίχιση ανάμεσα στα δύο στοιχεία. Πίνακας 87. Rule createpsmobserverpattern. ObserverPattern JavaObserverPattern Επεξήγηση Observer JavaObserver Ο κανόνας αυτός μετασχηματίζει οποιεσδήποτε συσχετίσεις έχει το ObserverPattern με Observer του PIM μεταμοντέλου σε συσχετίσεις ανάμεσα σε JavaObserverPattern με JavaObserver του PSM μεταμοντέλου Μετασχηματισμός του Observer O ATL κανόνας μετασχηματισμού createpsmobserver μετασχηματίζει το στοιχείο Observer από το DesignPatternsLayerPIM μεταμοντέλο στο αντίστοιχό του, το JavaObserver του DesignPatternsLayerPSM μεταμοντέλου. Για τον λόγο αυτό, το JavaObserver του DesignPatternsLayerPSM μεταμοντέλου εμπεριέχει μια υλοποίηση της προσέγγισης που εισήγαγε το στοιχείο Observer του DesignPatternsLayerPIM μεταμοντέλου. Στον παρακάτω πίνακα φαίνεται η αντιστοίχιση ανάμεσα στα δύο στοιχεία. Πίνακας 88. Rule createpsmobserver. Observer JavaObserver Επεξήγηση AnnResourceModel AnnJavaResourceModel Ο κανόνας αυτός μετασχηματίζει ο- ποιεσδήποτε συσχετίσεις έχει το Observer με AnnResourceModel του PIM μεταμοντέλου σε συσχετίσεις ανάμεσα σε JavaObserver με AnnJavaResourceModel του PIM μεταμοντέλου. ObservalbeAnnCRUDActivityHandler JavaObservableAnnHTTPActivityHandler Ο κανόνας αυτός μετασχηματίζει ο- ποιεσδήποτε συσχετίσεις έχει το Observer με ObservalbeAnnCRUDActivityHandler του PIM μεταμοντέλου σε συσχετίσεις ανάμεσα σε JavaObserver με JavaObservableAnnHTTPActivityHandler του PSM μεταμοντέλου. name name Ο κανόνας αυτός μεταφέρει την ιδιότητα name από το Observer του DesignPatternsLayerPCIM αυτούσιο ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

106 στο Observer του DesignPatternsLayerPSM Μετασχηματισμός του ObservableAnnCRUDActivityHandler O ATL κανόνας μετασχηματισμού createjavaobservableannhttpactivityhandler μετασχηματίζει στοιχείο ObservableAnnCRUDActivityHandler από το DesignPatternsLayerPIM μεταμτονέλο στο αντίστοιχό του, το JavaObservableAnnHTTPActivityHandler του DesignPatternsLayerPSM μεταμοντέλου. Tο JavaObservableAnn- HTTPActivityHandler του DesignPatternsLayerPSM μεταμοντέλου εμπεριέχει μια υλοποίηση της προσέγγγισης που εισήγαγε το ObservalbeAnnCRUDActivityHandler του DesignPatternsLayerPIM μεταμοντέλου. Στον παρακάτω πίνακα φαίνεται η αντιστοίχιση ανάμεσα στα δύο στοιχεία. Πίνακας 89. Rule createjavaobservableannhttpactivityhandler. ObservableAnnCRUDActivityHandletyHandler JavaObservableAnnHTTPActivi- Επεξήγηση AnnResourceModel AnnJavaResourceModel Ο κανόνας αυτός μετασχηματίζει ο- ποιεσδήποτε συσχετίσεις έχει το ObservableAnnCRUDActivityHandler με AnnResourceModel του PIM μεταμοντέλου σε συσχετίσεις ανάμεσα σε JavaObservableAnnHTTPActivityHandler με AnnJavaResourceModel του PSM μεταμοντέλου. Observer JavaObserver Ο κανόνας αυτός μετασχηματίζει ο- ποιεσδήποτε συσχετίσεις έχει το ObservableAnnCRUDActivityHandler με Observer του PIM μεταμοντέλου σε συσχετίσεις ανάμεσα σε JavaObservableAnnHTTPActivityHandler με JavaObserver του PSM μεταμοντέλου. AnnCRUDActivityHandler AnnHTTPActivityHandler Ο κανόνας αυτός μετασχηματίζει ο- ποιεσδήποτε συσχετίσεις έχει το ObservableAnnCRUDActivityHandler με AnnCRUDActivityHandler του PIM μεταμοντέλου σε συσχετίσεις ανάμεσα σε JavaObservableAnnHTTPActivityHandler με AnnHTTPActivityHandler του PSM μεταμοντέλου. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

107 4.4.3 Memento Pattern Πρότυπο Μνήμης Γενική Περιγραφή Το πρότυπο μνήμης επιλέχθηκε με σκοπό τη δημιουργία ενός μηχανισμού μνήμης, ο οποίος θα δημιουργεί στιγμιότυπα μνήμης ενός πόρου, ένας μηχανισμός δηλαδή που θα αποθηκεύει παλαιότερες καταστάσεις ενός πόρου. Στόχος της εισαγωγής του προτύπου είναι να μπορεί ένας πελάτης να έχει πρόσβαση σε πληροφορία που έχει μεταβληθεί και δεν υπάρχει αλλά και να μπορεί να την επαναφέρει. Το παραπάνω υλοποιείται με τη δημιουργία ενός πίνακα στιγμιότυπων μνήμης στη βάση για κάθε έναν πόρο για τον οποίο έχει οριστεί το πρότυπο μνήμης. Ο κάθε πίνακας θα έχει στήλες όλες τις ιδιότητες του πόρου για τον οποίο δημιουργήθηκε, καθώς επίσης και μια στήλη που δηλώνει την παλαιότητα της εγγραφής στιγμιότυπου μνήμης. Όσο πιο παλιό είναι το στιγμιότυπο μνήμης, τόσο πιο μεγάλος θα είναι ο αριθμός που είναι αποθηκευμένος στη στήλη αυτή. Ο αριθμός των στιγμιότυπων μνήμης που θα αποθηκεύονται στη βάση θα ορίζεται από τον χρήστη του S-CASE. Όταν τα στιγμιότυπα μνήμης για έναν συγκεκριμένο πόρο υπερβούν τον αριθμό που έχει οριστεί, τότε αυτά θα διαγράφονται. Η οδηγία του να διατηρηθεί ένα στιγμιότυπο μνήμης, η επιλογή συγκεκριμένου στιγμιότυπου καθώς επίσης και η ανάκτηση ενός στιγμιότυπου θα πραγματοποιείται με τη χρήση κατάλληλων ε- ρωτημάτων από τον πελάτη προς τον εξυπηρετητή. Εισάγοντας το πρότυπο θα καταφέρουμε να ικανοποιήσουμε τη ΜΛΑ της δυνατότητας απομνημόνευσης παλαιότερης κατάστασης πόρων και ανάκτησης παλαιότερων καταστάσεων (rollback - undo) Στοιχεία που μοντελοποιούν το πρότυπο Μνήμης στο DesignPatternsLayerCIM μεταμοντέλο Εικόνα 38. Στοιχεία που μοντελοποιούν το πρότυπο Μνήμης στο DesignPatternsLayerCIM μεταμοντέλο. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

108 MementoPattern Σύνοψη: To στοιχείο MementoPattern επεκτείνει την πληροφορία που ενσωματώνει το Annotation DesignPattern. Στόχος του είναι να μοντελοποιήσει μέσω των συσχετίσεών του όλη την πληροφορία που απαιτείται για το πρότυπο Μνήμης. Ιδιότητες: Συσχετίσεις: Το MementoPattern δεν έχει ιδιότητες. Πίνακας 90. Συσχετίσεις του MementoPattern του DesignPatternsLayerCIM μεταμοντέλου. Συσχέτιση με στοιχείο Τύπος Πολλαπλότητα Δομικοί Περιορισμοί CIM Memento composition 1..* Kάθε στοιχείο MementoPattern πρέπει να συσχετίζεται με composition συσχέτιση με τουλάχιστον ένα στοιχείο Memento Memento Σύνοψη: To στοιχείο Memento αποτελεί την οντότητα memento του προτύπου Μνήμης. Αποτελεί ουσιαστικά την πληροφορία που θα απομνημονεύεται στο σύστημα, το στιγμιότυπο μνήμης. Ιδιότητες: Πίνακας 91. Ιδιότητες του Memento του DesignPatternsLayerCIM μεταμοντέλου. Όνομα Τύπος Πολλαπλότητα Περιγραφή mementonum Int 1 Προσδιορίζει τον αριθμό των στιγμιότυπων μνήμης που θα α- ποθηκεύονται στο σύστημα για το στοιχείο Resource που ορίστηκε. Συσχετίσεις: Πίνακας 92. Συσχετίσεις του Memento του DesignPatternsLayerCIM μεταμοντέλου. Συσχέτιση με στοιχείο Τύπος Πολλαπλότητα Δομικοί Περιορισμοί CIM AnnResource association 1 Κάθε στοιχείο Memento πρέπει να συνδέεται με ακριβώς ένα AnnResource, το AnnResource του Resource του Core CIM για το οποίο θα διατηρούνται στιγμιότυπα μνήμης. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

109 Στοιχεία που μοντελοποιούν το πρότυπο Μνήμης στο DesignPatternsLayerPΙM μεταμοντέλο Εικόνα 39. Στοιχεία που μοντελοποιούν το πρότυπο Μνήμης στο DesignPatternsLayerPΙM μεταμοντέλο MementoPattern Σύνοψη: To στοιχείο MementoPattern επεκτείνει την πληροφορία που ενσωματώνει το Annotation DesignPattern. Στόχος του είναι να μοντελοποιήσει μέσω των συσχετίσεών του όλη την πληροφορία που απαιτείται για το πρότυπο Μνήμης. Ιδιότητες: Συσχετίσεις: Το MementoPattern δεν έχει ιδιότητες. Πίνακας 93. Συσχετίσεις του MementoPattern του DesignPatternsLayerPIM μεταμοντέλου. Συσχέτιση με στοιχείο Τύπος Πολλαπλότητα Δομικοί Περιορισμοί PIM PIMMemento composition 1..* Kάθε στοιχείο MementoPattern πρέπει να συσχετίζεται με composition συσχέτιση με τουλάχιστον ένα στοιχείο PIMMemento. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

110 PIMMemento Σύνοψη: ΜΟΝΤΕΛΟΠΟΙΗΣΗ ΜΗ ΛΕΙΤΟΥΡΓΙΚΩΝ ΑΠΑΙΤΗΣΕΩΝ ΛΟΓΙΣΜΙΚΟΥ ΣΕ ΜΟΝΤΕΛΑ ΔΙΑΔΙΚΤΥΑΚΩΝ ΣΥΣΤΗΜΑΤΩΝ REST To στοιχείο PIMMemento αποτελεί την οντότητα memento του προτύπου Μνήμης. Αποτελεί ουσιαστικά την πληροφορία που θα απομνημονεύεται στο σύστημα, το στιγμιότυπο μνήμης. Ιδιότητες: Πίνακας 94. Ιδιότητες του PIMMemento του DesignPatternsLayerPIM μεταμοντέλου. Όνομα Τύπος Πολλαπλότητα Περιγραφή mementonum Int 1 Προσδιορίζει τον αριθμό των στιγμιότυπων μνήμης που θα α- ποθηκεύονται στο σύστημα για το στοιχείο ResourceModel που ορίστηκε. Συσχετίσεις: Πίνακας 95. Συσχετίσεις του PIMMemento του DesignPatternsLayerPIM μεταμοντέλου. Συσχέτιση με στοιχείο Τύπος Πολλαπλότητα Δομικοί Περιορισμοί PIM AnnResourceModel association 1 Κάθε στοιχείο Memento πρέπει να συνδέεται με ακριβώς ένα AnnResourceModel, το AnnResourceModel του Resource- Model του Core PIM για το ο- ποίο θα διατηρούνται στιγμιότυπα μνήμης. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

111 Στοιχεία που μοντελοποιούν το πρότυπο Μνήμης στο DesignPatternsLayerPSM μεταμοντέλο Εικόνα 40. Στοιχεία που μοντελοποιούν το πρότυπο Μνήμης στο DesignPatternsLayerPSM μεταμοντέλο JavaMementoPattern Σύνοψη: To στοιχείο JavaMementoPattern επεκτείνει την πληροφορία που ενσωματώνει το Annotation Design- Pattern. Στόχος του είναι να μοντελοποιήσει μέσω των συσχετίσεών του όλη την πληροφορία που απαιτείται για το πρότυπο Μνήμης. Ιδιότητες: Συσχετίσεις: Το JavaMementoPattern δεν έχει ιδιότητες. Πίνακας 96. Συσχετίσεις του JavaMementoPattern του DesignPatternsLayerPSM μεταμοντέλου. Συσχέτιση με στοιχείο PSM JavaResource- ModelMemento Τύπος Πολλαπλότητα Δομικοί Περιορισμοί composition 1..* Kάθε στοιχείο JavaMementoPattern πρέπει να συσχετίζεται με composition συσχέτιση με τουλάχιστον ένα στοιχείο JavaResourceModelMemento. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

112 JavaResourceModelMemento Σύνοψη: To στοιχείο JavaResourceModelMemento αποτελεί την οντότητα memento του προτύπου Μνήμης. Α- ποτελεί ουσιαστικά την πληροφορία που θα απομνημονεύεται στο σύστημα, το στιγμιότυπο μνήμης. Ιδιότητες: Πίνακας 97. Ιδιότητες του JavaResourceModelMemento του DesignPatternsLayerPSM μεταμοντέλου. Όνομα Τύπος Πολλαπλότητα Περιγραφή mementonum Int 1 Προσδιορίζει τον αριθμό των στιγμιότυπων μνήμης που θα α- ποθηκεύονται στο σύστημα για το στοιχείο JavaResourceModel που ορίστηκε. Συσχετίσεις Πίνακας 98. Συσχετίσεις του JavaResourceModelMemento του DesignPatternsLayerPSM μεταμοντέλου. Συσχέτιση με στοιχείο Τύπος Πολλαπλότητα Δομικοί Περιορισμοί PSM AnnJavaResourceModel association 1 Κάθε στοιχείο Memento πρέπει να συνδέεται με ακριβώς ένα AnnJavaResourceModel, το AnnJavaResourceModel του JavaResourceModel του Core PSM για το οποίο θα διατηρούνται στιγμιότυπα μνήμης Μετασχηματισμοί ATL στοιχείων του προτύπου Μνήμης από το DesignPatternsLayerCIM στο DesignPatternsLayerPIM Μετασχηματισμός του MementoPattern O ATL κανόνας μετασχηματισμού createpimmementopattern μετασχηματίζει το στοιχείο MementoPattern από το DesignPatternsLayerCIM μεταμοντέλο στο αντίστοιχό του, το MementoPattern του Design- PatternsLayerPIM μεταμοντέλου. Για τον λόγο αυτό, το MementoPattern του DesignPatternsLayerPIM μεταμοντέλου εμπεριέχει μια αφαιρετική προσέγγιση της ιδέας που εισήγαγε το στοιχείο MementoPattern του DesignPatternsLayerCIM μεταμοντέλου. Στον παρακάτω πίνακα φαίνεται η αντιστοίχιση ανάμεσα στα δύο στοιχεία. Πίνακας 99. Rule createpimmementopattern. MementoPattern MementoPattern (PIM) Επεξήγηση Memento PIMMemento Ο κανόνας αυτός μετασχηματίζει οποιεσδήποτε συσχετίσεις έχει το MementoPattern με Memento του CIM μεταμοντέλου σε συσχετίσεις ανάμεσα σε MementoPattern με PIMMemento του PIM μεταμοντέλου. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

113 Μετασχηματισμός του Memento O ATL κανόνας μετασχηματισμού createpimmemento μετασχηματίζει το στοιχείο Memento από το DesignPatternsLayerCIM μεταμοντέλο στο αντίστοιχό του, το PIMMemento του DesignPatternsLayerPIM μεταμοντέλου. Για τον λόγο αυτό, το PIMMemento του DesignPatternsLayerPIM μεταμοντέλου εμπεριέχει μια α- φαιρετική προσέγγιση της ιδέας που εισήγαγε το στοιχείο Memento του DesignPatternsLayerCIM μεταμοντέλου. Στον παρακάτω πίνακα φαίνεται η αντιστοίχιση ανάμεσα στα δύο στοιχεία. Πίνακας 100. Rule createpimmementopattern. Memento PIMMemento Επεξήγηση AnnResource AnnResourceModel Ο κανόνας αυτός μετασχηματίζει οποιεσδήποτε συσχετίσεις έχει το Memento με AnnResource του CIM μεταμοντέλου σε συσχετίσεις ανάμεσα σε PIMMemento με AnnResource- Model του PIM μεταμοντέλου. mementonum mementonum Ο κανόνας αυτός μεταφέρει την ιδιότητα mementonum από το Memento του DesignPatternsLayerCIM αυτούσιο στο mementonum του Memento του DesignPatternsLayerPSM Μετασχηματισμοί ATL στοιχείων του προτύπου Μνήμης από το DesignPatternsLayerPIM στο DesignPatternsLayerPSM Μετασχηματισμός του MementoPattern O ATL κανόνας μετασχηματισμού createpimmementopattern μετασχηματίζει το στοιχείο MementoPattern από το DesignPatternsLayerCIM μεταμοντέλο στο αντίστοιχό του, το JavaMementoPattern του DesignPatternsLayerPSM μεταμοντέλου. Για τον λόγο αυτό, το MementoPattern του DesignPatternsLayerPSM μεταμοντέλου εμπεριέχει μια υλοποίηση της προσέγγισης της ιδέας που εισήγαγε το στοιχείο MementoPattern του DesignPatternsLayerPIM μεταμοντέλου. Στον παρακάτω πίνακα φαίνεται η αντιστοίχιση ανάμεσα στα δύο στοιχεία. Πίνακας 101. Rule createpimmementopattern. MementoPattern JavaMementoPattern (PIM) Επεξήγηση PIMMemento JavaResource- ModelMemento Ο κανόνας αυτός μετασχηματίζει οποιεσδήποτε συσχετίσεις έχει το MementoPattern με PIMMemento του PIM μεταμοντέλου σε συσχετίσεις ανάμεσα σε JavaMementoPattern με JavaResourceModelMemento του PSM μεταμοντέλου Μετασχηματισμός του PIMMemento O ATL κανόνας μετασχηματισμού createpimmemento μετασχηματίζει το στοιχείο Memento από το DesignPatternsLayerCIM μεταμοντέλο στο αντίστοιχό του, το PIMMemento του DesignPatternsLayerPIM μεταμοντέλου. Για τον λόγο αυτό, το PIMMemento του DesignPatternsLayerPIM μεταμοντέλου εμπεριέχει μια α- φαιρετική προσέγγιση της ιδέας που εισήγαγε το στοιχείο Memento του DesignPatternsLayerCIM μεταμοντέλου. Στον παρακάτω πίνακα φαίνεται η αντιστοίχιση ανάμεσα στα δύο στοιχεία. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

114 Πίνακας 102. Rule createpimmemento. PIMMemento JavaResouce- Επεξήγηση ModelMemento AnnResourceModel AnnJavaResourceModel Ο κανόνας αυτός μετασχηματίζει οποιεσδήποτε συσχετίσεις έχει το PIMMemento με AnnResourceModel του PIM μεταμοντέλου σε συσχετίσεις ανάμεσα σε JavaResouce- ModelMemento με AnnJavaResourceModel του PSM μεταμοντέλου. mementonum mementonum Ο κανόνας αυτός μεταφέρει την ιδιότητα mementonum από το PIMMemento του Design- PatternsLayerPIM αυτούσιο στο mementonum του JavaResourceModelMemento του DesignPatternsLayerPSM. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

115 4.4.4 Bridge Pattern Πρότυπο Γέφυρας Γενική Περιγραφή Το πρότυπο γέφυρας επιλέχθηκε με σκοπό τη δημιουργία ενός μηχανισμού υποστήριξης, εισαγωγής και εκτέλεσης επεκτάσεων αλγοριθμικών πόρων σε μια παραγόμενη από το S-CASE υπηρεσία. Στόχος της εισαγωγής του προτύπου είναι η παροχή της δυνατότητας στους προγραμματιστές να παράγουν ένα RESTful API στο οποίο διευκολύνεται η εισαγωγή και η επαναχρησιμοποίηση κώδικα καθώς επίσης και η επιλογή συγκεκριμένου εκτελέσιμου κώδικα κατά την εκτέλεση μιας υπηρεσίας παραπέμπει και στο πρότυπο Command. Το πρότυπο θα εφαρμοστεί στους αλγοριθμικούς πόρους που χρησιμοποιούνται για τη σύνδεση του παραγόμενου RESTful API με μια εξωτερική ως προς το api υπηρεσία καθώς επίσης και στους αλγοριθμικούς πόρους που χρησιμοποιούνται για την εισαγωγή του μηχανισμού αναζήτησης [περισσότερα για τους μηχανισμούς αυτούς στα παραδοτέα του S-CASE]. Τα παραπάνω υλοποιούνται με τη χρήση κλάσεων αφαιρέσεων και κλάσεων που κληρονομούν τις α- φαιρέσεις. Όταν ένα σύστημα παράγεται από το 2D MDE Engine θα έχει ως προκαθορισμένο κομμάτι εκτελέσιμου κώδικα αυτό που παράγεται από το S-CASE χωρίς τη χρήση του προτύπου γέφυρας. Ένας προγραμματιστής όμως, μπορεί κατά βούληση να εισάγει επιπλέον εκτελέσιμα κομμάτια κώδικα (που είτε κληρονομούν τις αφαιρέσεις, είτε όχι) και να ζητάει την εκτέλεσή τους μέσω ερωτημάτων (query parameters) μέσω του επαυξημένου controller που δημιουργεί η εισαγωγή του προτύπου γέφυρας. Εισάγοντας το πρότυπο αυτό θα καταφέρουμε να ικανοποιήσουμε τις ΜΛΑ της συμβατότητας, της ε- πεκτασιμότητας, της διατηρησιμότητας και της εύκολης τροποποίησης και της επαναχρησιμοποίησης κώδικα Στοιχεία που μοντελοποιούν το πρότυπο Γέφυρας στο DesignPatternsLayerCIM μεταμοντέλο Εικόνα 41. Στοιχεία που μοντελοποιούν το πρότυπο Γέφυρας στο DesignPatternsLayerCIM μεταμοντέλο. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

116 BridgePattern Σύνοψη: ΜΟΝΤΕΛΟΠΟΙΗΣΗ ΜΗ ΛΕΙΤΟΥΡΓΙΚΩΝ ΑΠΑΙΤΗΣΕΩΝ ΛΟΓΙΣΜΙΚΟΥ ΣΕ ΜΟΝΤΕΛΑ ΔΙΑΔΙΚΤΥΑΚΩΝ ΣΥΣΤΗΜΑΤΩΝ REST To στοιχείο BridgePattern επεκτείνει την πληροφορία που ενσωματώνει το Annotation DesignPattern. Στόχος του είναι να μοντελοποιήσει μέσω των συσχετίσεών του όλη την πληροφορία που απαιτείται για το πρότυπο Γέφυρα. Ιδιότητες: Συσχετίσεις: Το BridgePattern δεν έχει ιδιότητες. Πίνακας 103. Συσχετίσεις του BridgePattern του DesignPatternsLayerCIM μεταμοντέλου. Συσχέτιση με στοιχείο Τύπος Πολλαπλότητα Δομικοί Περιορισμοί CIM AnnAlgoResource Association 1 To στοιχείο BridgePattern πρέπει να συνδέεται με τουλάχιστον ένα AnnAlgoResource, το AnnAlgoResource του Resource του Core CIM μοντέλου στο ο- ποίο θα εφαρμοστεί το πρότυπο γέφυρα Στοιχεία που μοντελοποιούν το πρότυπο Γέφυρας στο DesignPatternsLayerPIM μεταμοντέλο Εικόνα 42. Στοιχεία που μοντελοποιούν το πρότυπο Γέφυρας στο DesignPatternsLayerPIM μεταμοντέλο. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

117 BridgePattern Σύνοψη: ΜΟΝΤΕΛΟΠΟΙΗΣΗ ΜΗ ΛΕΙΤΟΥΡΓΙΚΩΝ ΑΠΑΙΤΗΣΕΩΝ ΛΟΓΙΣΜΙΚΟΥ ΣΕ ΜΟΝΤΕΛΑ ΔΙΑΔΙΚΤΥΑΚΩΝ ΣΥΣΤΗΜΑΤΩΝ REST To στοιχείο BridgePattern επεκτείνει την πληροφορία που ενσωματώνει το Annotation DesignPattern. Στόχος του είναι να μοντελοποιήσει μέσω των συσχετίσεών του όλη την πληροφορία που απαιτείται για το πρότυπο Γέφυρα. Ιδιότητες: Συσχετίσεις: Το BridgePattern δεν έχει ιδιότητες. Πίνακας 104. Συσχετίσεις του BridgePattern του DesignPatternsLayerPIM μεταμοντέλου. Συσχέτιση με στοιχείο Τύπος Πολλαπλότητα Δομικοί Περιορισμοί PIM AnnAlgoResourceModel Association 1 To στοιχείο BridgePattern πρέπει να συνδέεται με τουλάχιστον ένα AnnAlgoResource- Model, το AnnAlgoResource- Model του AlgoResourceModel του Core PIM μοντέλου στο ο- ποίο θα εφαρμοστεί το πρότυπο γέφυρα Στοιχεία που μοντελοποιούν το πρότυπο Γέφυρας στο DesignPatternsLayerPSM μεταμοντέλο Εικόνα 43. Στοιχεία που μοντελοποιούν το πρότυπο Γέφυρας στο DesignPatternsLayerPSM μεταμοντέλο. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

118 JavaBridgePattern Σύνοψη To στοιχείο JavaBridgePattern επεκτείνει την πληροφορία που ενσωματώνει το Annotation DesignPattern. Στόχος του είναι να μοντελοποιήσει μέσω των συσχετίσεών του όλη την πληροφορία που απαιτείται για το πρότυπο Γέφυρα. Ιδιότητες: Συσχετίσεις: Το JavaBridgePattern δεν έχει ιδιότητες. Πίνακας 105. Συσχετίσεις του JavaBridgePattern του DesignPatternsLayerPSM μεταμοντέλου. Συσχέτιση με στοιχείο PSM AnnJavaAlgoResource- Model Τύπος Πολλαπλότητα Δομικοί Περιορισμοί Association 1 To στοιχείο JavaBridgePattern πρέπει να συνδέεται με τουλάχιστον ένα AnnJavaAlgoResource- Model, το AnnJavaAlgoResourceModel του JavaAlgoResourceModel του Core PSM μοντέλου στο οποίο θα εφαρμοστεί το πρότυπο γέφυρα Μετασχηματισμοί ATL στοιχείων του προτύπου Γέφυρας από το DesignPatternsLayerCIM στο Design- PatternsLayerPIM Μετασχηματισμός του BridgePattern O ATL κανόνας μετασχηματισμού createpimbridgepattern μετασχηματίζει το στοιχείο BridgePattern από το DesignPatternsLayerCIM μεταμοντέλο στο αντίστοιχό του, το BridgePattern του DesignPatternsLayerPIM μεταμοντέλου. Για τον λόγο αυτό, το MementoPattern του DesignPatternsLayerPIM μεταμοντέλου εμπεριέχει μια αφαιρετική προσέγγιση της ιδέας που εισήγαγε το στοιχείο BridgePattern του DesignPatternsLayerCIM μεταμοντέλου. Στον παρακάτω πίνακα φαίνεται η αντιστοίχιση ανάμεσα στα δύο στοιχεία. Πίνακας 106. Rule createpimbridgepattern. BridgePattern BridgePattern (PIM) Επεξήγηση AnnResource AnnResourceModel Ο κανόνας αυτός μετασχηματίζει οποιεσδήποτε συσχετίσεις έχει το BridgePattern με AnnResource του CIM μεταμοντέλου σε συσχετίσεις ανάμεσα σε BridgePattern με AnnResourceModel του PIM μεταμοντέλου. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

119 Μετασχηματισμοί ATL στοιχείων του προτύπου Μνήμης από το DesignPatternsLayerPIM στο DesignPatternsLayerPSM Μετασχηματισμός του BridgePattern O ATL κανόνας μετασχηματισμού createpsmbridgepattern μετασχηματίζει το στοιχείο BridgePattern από το DesignPatternsLayerPIM μεταμοντέλο στο αντίστοιχό του, το JavaBridgePattern του DesignPatternsLayerPSM μεταμοντέλου. Για τον λόγο αυτό, το MementoPattern του DesignPatternsLayerPIM μεταμοντέλου ε- μπεριέχει μια υλοποίηση της προσέγγισης εισήγαγε το στοιχείο BridgePattern του DesignPatternsLayerPIM μεταμοντέλου σε συγκεκριμένη πλατφόρμα. Στον παρακάτω πίνακα φαίνεται η αντιστοίχιση ανάμεσα στα δύο στοιχεία. Πίνακας 107. Rule createpsmbridgepattern. BridgePattern JavaBridgePattern Επεξήγηση AnnResourceModel AnnJavaResourceModel Ο κανόνας αυτός μετασχηματίζει οποιεσδήποτε συσχετίσεις έχει το BridgePattern με AnnResourceModel του CIM μεταμοντέλου σε συσχετίσεις ανάμεσα σε JavaBridgePattern με AnnJavaResourceModel του PIM μεταμοντέλου. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

120 4.5 DesignPatternsLayerPSM to Text Acceleo μετασχηματισμοί Για την εισαγωγή του προτύπων σχεδίασης στην παραγόμενη υπηρεσία χρησιμοποιούνται Acceleo πρότυπα, κάποια εκ των οποίων εισήχθησαν για συγκεκριμένο για κάποιο πρότυπο σχεδίασης και είναι καινούρια για το S-CASE και κάποια που υπήρχαν και μεταβλήθηκαν σε σχέση με τα αρχικά πρότυπα του S-CASE. Όλα παρουσιάζονται συνοπτικά παρακάτω: Πίνακας 108. Acceleo πρότυπο generate.mtl. Όνομα του Acceleo προτύπου: generate.mtl Τύπος: Προϋπάρχουν μεταβλήθηκε. Παράγει το αρχείο: - Διαφορές με το προϋπάρχον: Χρησιμοποιεί τα Όλα το νέο AnnotationStack, δηλαδή όλα PSM μεταμοντέλα: τα PSM μεταμοντέλα του S-CASE, συμπεριλαμβανομένου και του DesignPatternsLay- Καλεί επιπλέον Acceleo πρότυπα: erpsm μεταμοντέλο. javarepresentationmodel.mtl (εάν θα εισαχθεί το πρότυπο Χτίστη) javaobserver.mtl (εάν θα εισαχθεί το πρότυπο Παρατηρητή) javamemento.mtl (εάν θα εισαχθεί το πρότυπο Mνήμης) Πρότυπα σχεδίασης στα οποία Builder, Bridge, Observer, Memento χρειάζεται: Σχόλια: To ήδη υπάρχον generate.mtl πρότυπο μεταβλήθηκε κατάλληλα επεκτάθηκε, για να μπορεί να υποστηρίξει την εισαγωγή όλων των προτύπων σχεδίασης στην παραγόμενη υπηρεσία. Πίνακας 109. Acceleo πρότυπο javarepresentationmodel.mtl. Όνομα του Acceleo προτύπου: javarepresentationmodel.mtl Τύπος: Νέο Χρησιμοποιεί τα PSM μεταμοντέλα: AnnotationLayerStack, RestfulServicePSM, DesignPatternsLayerPSM, AuthenticationLayerPSM Παράγει το αρχείο: javaresourcemodel s name + Representation.java Καλεί άλλα Acceleo πρότυπα: - Σχόλια: To πρότυπο αυτό είναι υπεύθυνο για την παραγωγή του κώδικα για το representation που θα δημιουργεί η προσθήκη του προτύπου Χτίστη. Πίνακας 110. Acceleo πρότυπο javaobserver.mtl. Όνομα του Acceleo προτύπου: javaobserver.mtl Τύπος: Νέο Χρησιμοποιεί τα PSM μεταμοντέλα: AnnotationLayerStack, RestfulServicePSM, DesignPatternsLayerPSM Παράγει το αρχείο: javaresourcemodel s ParentName + Observer.java Καλεί άλλα Acceleo πρότυπα: - Σχόλια: To πρότυπο αυτό είναι υπεύθυνο για την παραγωγή του κώδικα για τoν παρατηρητή που θα δημιουργεί η προσθήκη του προτύπου Παρατηρητή. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

121 Πίνακας 111. Acceleo πρότυπο javamemento.mtl. Όνομα του Acceleo προτύπου: javamemento.mtl Τύπος: Νέο Χρησιμοποιεί τα PSM μεταμοντέλα: AnnotationLayerStack, RestfulServicePSM, DesignPatternsLayerPSM Παράγει το αρχείο: javaresourcemodel s ParentName + Memento.java Καλεί άλλα Acceleo πρότυπα: - Σχόλια: To πρότυπο αυτό είναι υπεύθυνο για την παραγωγή του κώδικα για τα στιγμιότυπα μνήμης που θα δημιουργεί η προσθήκη του προτύπου Μνήμης. Πίνακας 112. Acceleo πρότυπο javaresourcecontroller.mtl. Όνομα του Acceleo προτύπου: Τύπος: Παράγει το αρχείο: Διαφορές με το προϋπάρχον: Πρότυπα σχεδίασης στα οποία χρειάζεται: Σχόλια: Χρησιμοποιεί τα PSM μεταμοντέλα: javaresourcecontroller.mtl Προϋπάρχουν μεταβλήθηκε. javaresourcecontroller s name +.java AnnotationLayerStack, RestfulServicePSM, DesignPatternsLayerPSM, AuthenticationLayerPSM Καλεί επιπλέον Acceleo πρότυπα: Builder, Observer, Memento To ήδη υπάρχον javaresourcecontroller.mtl πρότυπο μεταβλήθηκε κατάλληλα επεκτάθηκε, για να μπορεί να υποστηρίξει την εισαγωγή όλων των προτύπων σχεδίασης στην παραγόμενη υπηρεσία. Πιο συγκεκριμένα μεταβλήθηκε έτσι ώστε να υποστηρίζει τους διαφορετικούς handlers που θα καλεί ο controller για κάποιο resource, σύμφωνα με το πρότυπο σχεδίασης που έχει εφαρμοστεί σε αυτό. Πίνακας 113. Acceleo πρότυπο javaresourcecontrollermanager.mtl. Όνομα του Acceleo προτύπου: Τύπος: Παράγει το αρχείο: Διαφορές με το προϋπάρχον: Πρότυπα σχεδίασης στα οποία χρειάζεται: Σχόλια: javaresourcecontrollermanager.mtl Προϋπάρχουν μεταβλήθηκε. javaresourcecontrollermanager s name +.java AnnotationLayerStack, RestfulServicePSM, DesignPatternsLayerPSM, AuthenticationLayerPSM Χρησιμοποιεί τα PSM μεταμοντέλα: Καλεί επιπλέον Acceleo πρότυπα: Observer To ήδη υπάρχον javaresourcecontroller.mtl πρότυπο μεταβλήθηκε κατάλληλα επεκτάθηκε, για να μπορεί να υποστηρίξει την εισαγωγή του προτύπου Παρατηρητή. Πιο συγκεκριμένα μεταβλήθηκε έτσι ώστε να υποστηρίζει τους διαφορετικούς POST handlers που θα καλεί ο controllermanager για κάποιο resource, σύμφωνα με το πρότυπο παρατηρητή. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

122 Πίνακας 114. Acceleo πρότυπο javahttpactivityhandler.mtl. Όνομα του Acceleo προτύπου: javahttpactivityhandler.mtl Τύπος: Προϋπάρχουν μεταβλήθηκε. Παράγει το αρχείο: - Διαφορές με το προϋπάρχον: Χρησιμοποιεί τα AnnotationLayerStack, RestfulServicePSM, PSM μεταμοντέλα: DesignPatternsLayerPSM, AuthenticationLayerPSM, SearchLayerPSM. External- Πρότυπα σχεδίασης στα οποία χρειάζεται: Σχόλια: Καλεί επιπλέον Acceleo πρότυπα: ServiceLayerPSM generateabstractsearchhttphandler.mtl, generateextendedsearchhttphandler.mtl, abstractjavarestclienthttpactivityhandler.mtl, extendedjavarestclienthttpactivityhandler.mtl, observablepostresourcehandlernoparents.mtl, observablepostresourcehandlersingleparent.mtl, observablepostresourcelisthandlermultipleparents.mtl, observableputresourcehandlermultiple- Parents.mtl, observableputresourcehandlernoparents.mtl. observableputresourcehandlersingleparent.mtl, observablegetresourcehandlermultiple- Parents.mtl, observablegetresourcehandlernoparents.mtl, observablegetresourcehandlersingleparent.mtl, observabledeleteresourcehandlermultipleparents.mtl, observabledeleteresourcehandlernoparents.mtl, observabledeleteresourcehandlersingle- Parent.mtl Builder, Observer, Memento, Bridge To ήδη υπάρχον javahttpactivityhandler.mtl πρότυπο μεταβλήθηκε κατάλληλα επεκτάθηκε, για να μπορεί να υποστηρίξει την εισαγωγή όλων των προτύπων σχεδίασης στην παραγόμενη υπηρεσία. Πιο συγκεκριμένα μεταβλήθηκε έτσι ώστε να δημιουργεί τους διαφορετικούς handlers που για κάποιο resource, σύμφωνα με το αν έχει εφαρμοστεί σε αυτούς το κάποιο πρότυπο σχεδίασης ή όχι, και αν ναι, σύμφωνα με τις παραμέτρους του προτύπου αυτού. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

123 Πίνακας 115. Acceleo πρότυπο getresourcehandlernoparent.mtl. Όνομα του Acceleo προτύπου: Τύπος: Παράγει το αρχείο: Διαφορές με το προϋπάρχον: Πρότυπα σχεδίασης στα οποία χρειάζεται: Σχόλια: getresourcehandlernoparent.mtl Προϋπάρχουν μεταβλήθηκε. getresourcehandlersingleparent s name +.java Χρησιμοποιεί τα AnnotationLayerStack, RestfulServicePSM, PSM μεταμοντέλα: DesignPatternsLayerPSM, AuthenticationLayerPSM, SearchLayerPSM Καλεί επιπλέον Acceleo πρότυπα: - Builder, Observer, Memento To ήδη υπάρχον javaresourcecontroller.mtl πρότυπο μεταβλήθηκε κατάλληλα επεκτάθηκε, για να μπορεί να υποστηρίξει την εισαγωγή όλων των προτύπων σχεδίασης στην παραγόμενη υπηρεσία. Πιο συγκεκριμένα μεταβλήθηκε έτσι ώστε να υποστηρίζει τους διαφορετικούς GET handlers που για κάποιο resource, σύμφωνα με το αν έχει εφαρμοστεί σε αυτούς το πρότυπο Χτίστη ή όχι. Τα getresourcehandlersingleparent.mtl και getresourcehandlermultipleparent.mtl τροποποιήθηκαν κατάλληλα και αντίστοιχα με το getresourcehandlernoparent.mtl και έχουν ίδια είσοδο και ίδια έξοδο με μικρές διαφοροποιήσεις στον κώδικα που παράγεται. Πίνακας 116. Acceleo πρότυπο observablegetresourcehandlernoparents.mtl. Όνομα του Acceleo προτύπου: observablegetresourcehandlernoparents.mtl Τύπος: Νέο Χρησιμοποιεί τα PSM μεταμοντέλα: AnnotationLayerStack, RestfulServicePSM, DesignPatternsLayerPSM, AuthenticationLayer.PSM Παράγει το αρχείο: Observable + getresourcehandlersingleparent s name +.java Καλεί άλλα Acceleo πρότυπα: - Σχόλια: To πρότυπο αυτό είναι υπεύθυνο για την παραγωγή του κώδικα για τα παρατηρήσιμα GET που θα δημιουργεί η προσθήκη του προτύπου παρατηρητής. Τα παρακάτω πρότυπα Acceleo έχουν ίδια είσοδο και ίδια έξοδο με το observablegetresourcehandlernoparents.mtl πρότυπο, με τη διαφορά ότι τα κομμάτια κώδικα που παράγουν έχουν διαφορές ανάλογα με το HTTP αίτημα που χειρίζονται: observablepostresourcehandlernoparents.mtl, observablepostresourcehandlersingleparent.mtl, observablepostresourcelisthandlermultipleparents.mtl, observableputresourcehandlermultipleparents.mtl, observableputresourcehandlernoparents.mtl. observableputresourcehandlersingleparent.mtl, observablegetresourcehandlermultipleparents.mtl, observablegetresourcehandlernoparents.mtl, observablegetresourcehandlersingleparent.mtl, observabledeleteresourcehandlermultipleparents.mtl, ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

124 observabledeleteresourcehandlernoparents.mtl, observabledeleteresourcehandlersingleparent.mtl Πίνακας 117. Acceleo πρότυπο abstractjavarestclienthttpactivityhandler.mtl. Όνομα του Acceleo προτύπου: abstractjavarestclienthttpactivityhandler.mtl Τύπος: Νέο Χρησιμοποιεί τα PSM μεταμοντέλα: RestfulServicePSM, SearchLayerPSM, AuthenticationLayer.PSM, ExternalServiceLayerPSM Παράγει το αρχείο: Abstract + JavaAlgoRControllerHasHTTPActivity s verb + JavaAlgoRControllerHasHTTPActivity s parent name + Handler.java Καλεί άλλα Acceleo πρότυπα: - Σχόλια: To πρότυπο αυτό είναι υπεύθυνο για την παραγωγή του κώδικα για τις αφαιρέσεις των handler των εξωτερικών συστημάτων που απαιτεί το πρότυπο γέφυρα. Πίνακας 118. Acceleo πρότυπο extendedjavarestclienthttpactivityhandler.mtl. Όνομα του Acceleo προτύπου: extendedjavarestclienthttpactivityhandler.mtl Τύπος: Νέο Χρησιμοποιεί τα PSM μεταμοντέλα: AnnotationLayerStack, RestfulServicePSM, SearchLayerPSM, AuthenticationLayer.PSM, ExternalServiceLayerPSM Παράγει το αρχείο: JavaAlgoRControllerHasHTTPActivity s verb + JavaAlgoRController- HasHTTPActivity s parentname + Handler.java Καλεί άλλα Acceleo πρότυπα: - Σχόλια: To πρότυπο αυτό είναι υπεύθυνο για την παραγωγή του κώδικα για τις υλοποιήσεις των αφαιρέσεων των handler των εξωτερικών συστημάτων που απαιτεί το πρότυπο Γέφυρα. Πίνακας 119. Acceleo πρότυπο generateabstractsearchhttphandler.mtl. Όνομα του Acceleo προτύπου: generateabstractsearchhttphandler.mtl Τύπος: Νέο Χρησιμοποιεί τα PSM μεταμοντέλα: RestfulServicePSM, SearchLayerPSM, AuthenticationLayer.PSM, DesignPatternsLayerPSM Παράγει το αρχείο: Abstract + JavaAlgoRControllerHasHTTPActivity s verb + JavaAlgoRControllerHasHTTPActivity s parent name + Handler.java Καλεί άλλα Acceleo πρότυπα: - Σχόλια: To πρότυπο αυτό είναι υπεύθυνο για την παραγωγή του κώδικα για τις αφαιρέσεις των handler των υπηρεσιών αναζήτησης που α- παιτεί το πρότυπο Γέφυρα. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

125 Πίνακας 120. Acceleo πρότυπο generateextendedsearchhttphandler.mtl. Όνομα του Acceleo προτύπου: generateextendedsearchhttphandler.mtl Τύπος: Νέο Χρησιμοποιεί τα PSM μεταμοντέλα: RestfulServicePSM, SearchLayerPSM, AuthenticationLayer.PSM, DesignPatternsLayerPSM Παράγει το αρχείο: JavaAlgoRControllerHasHTTPActivity s verb + JavaAlgoRController- HasHTTPActivity s parent name + Handler.java Καλεί άλλα Acceleo πρότυπα: - Σχόλια: To πρότυπο αυτό είναι υπεύθυνο για την παραγωγή του κώδικα για τις υλοποιήσεις των αφαιρέσεων των handler των υπηρεσιών αναζήτησης που απαιτεί το πρότυπο γέφυρα. Πίνακας 121. Acceleo πρότυπο javahibernatecontroller.mtl. Όνομα του Acceleo προτύπου: Τύπος: Παράγει το αρχείο: Διαφορές με το προϋπάρχον: Πρότυπα σχεδίασης στα οποία χρειάζεται: Σχόλια: javahibernatecontroller.mtl Προϋπάρχουν μεταβλήθηκε. HibernateController.java Χρησιμοποιεί τα AnnotationLayerStack, RestfulServicePSM, PSM μεταμοντέλα: DesignPatternsLayerPSM, AuthenticationLayerPSM Καλεί επιπλέον Acceleo πρότυπα: - Observer, Memento, Builder To ήδη υπάρχον javahibernatecontroller.mtl πρότυπο μεταβλήθηκε κατάλληλα επεκτάθηκε, για να μπορεί να υποστηρίξει την εισαγωγή των προτύπων Παρατηρητή, Χτίστη και Μνήμης στην παραγόμενη υπηρεσία. Πιο συγκεκριμένα μεταβλήθηκε έτσι ώστε να υποστηρίζει τους διαφορετικούς χειριστές σύμφωνα με τα hibernate transactions που θα εκτελεί το κάθε πρότυπο. Πίνακας 122. Acceleo πρότυπο javahibernateutil.mtl. Όνομα του Acceleo προτύπου: Τύπος: Παράγει το αρχείο: Διαφορές με το προϋπάρχον: Πρότυπα σχεδίασης στα οποία χρειάζεται: Σχόλια: javahibernateutil.mtl Προϋπάρχουν μεταβλήθηκε. HibernateUtil.java Χρησιμοποιεί τα AnnotationLayerStack, RestfulServicePSM, PSM μεταμοντέλα: DesignPatternsLayerPSM, AuthenticationLayerPSM Καλεί επιπλέον Acceleo πρότυπα: - Observer, Memento, Builder To ήδη υπάρχον javahibernatecontroller.mtl πρότυπο μεταβλήθηκε κατάλληλα επεκτάθηκε, για να μπορεί να υποστηρίξει την εισαγωγή των προτύπων Παρατηρητή, Χτίστη και Μνήμης στην παραγόμενη υπηρεσία. Πιο συγκεκριμένα μεταβλήθηκε έτσι ώστε να υποστηρίζει τους διαφορετικούς χειριστές σύμφωνα με τα hibernate transactions που θα εκτελεί το κάθε πρότυπο. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

126 Πίνακας 123. Acceleo πρότυπο mavenconfigurationfile.mtl. Όνομα του Acceleo προτύπου: Τύπος: Παράγει το αρχείο: Διαφορές με το προϋπάρχον: Πρότυπα σχεδίασης στα οποία χρειάζεται: Σχόλια: mavenconfigurationfile.mtl Προϋπάρχουν μεταβλήθηκε. HibernateUtil.java Χρησιμοποιεί τα AnnotationLayerStack, RestfulServicePSM, PSM μεταμοντέλα: DesignPatternsLayerPSM, AuthenticationLayerPSM, ExternalServiceLayerPSM Καλεί επιπλέον Acceleo πρότυπα: - Observer To ήδη υπάρχον mavenconfigurationfile.mtl πρότυπο μεταβλήθηκε κατάλληλα επεκτάθηκε, για να μπορεί να υποστηρίξει την εισαγωγή του προτύπου Παρατηρητή στην παραγόμενη υπηρεσία. Πιο συγκεκριμένα μεταβλήθηκε έτσι ώστε να ενσωματώνει στις maven ρυθμίσεις το εκτελέσιμο java.mail που απαιτείται για την αποστολή mail μιας υπηρεσίας που έχει ενσωματωμένο το πρότυπο Παρατηρητή. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

127 4.6 Το αποτέλεσμα της χρήσης της επέκτασης Στο υποκεφάλαιο αυτό παρουσιάζονται οι διαφορές προσθήκες επιπλέον λειτουργίες που προσφέρει η εισαγωγή του κάθε προτύπου σε μία παραγόμενη από το MDE Engine υπηρεσία Πρότυπο Χτίστη Οι διαφορές ανάμεσα σε ένα endpoint στο οποίο έχει εφαρμοστεί το πρότυπο Χτίστη και σε ένα που δεν έχει εφαρμοστεί το πρότυπο χτίστη παρουσιάζονται παρακάτω Η κλάση αναπαράστασης Η εισαγωγή του προτύπου Χτίστη σε έναν πόρο έχει ως αποτέλεσμα τη δημιουργία της κλάσης JavaResourceModelRepresentation.java, η οποία υλοποιεί το στιγμιότυπο αναπαράστασης ενός πόρου. Αποτελεί στην ουσία την τωρινή κατάσταση ενός πόρου και περιέχει όλες τις ιδιότητες και τις μεθόδους του πόρου JavaResourceModel.java, καθώς επίσης και μια ιδιότητα representationname, η οποία χρησιμοποιείται για την εξαγωγή του κατάλληλου υποσυνόλου ιδιοτήτων, ανάλογα με την αναπαράσταση που ζήτησε ο πελάτης της υπηρεσίας Ο controller και ο GET Handler Η εισαγωγή του προτύπου Χτίστη σε έναν πόρο έχει ως αποτέλεσμα τη μεταβολή του controller του πόρου στον οποίο εφαρμόστηκε το πρότυπο με τέτοιον τρόπο ώστε αυτό να μπορεί να χρησιμοποιήσει τον νέο GET Handler που εισήγαγε το πρότυπο. Πιο συγκεκριμένα, όταν ένας client ζητάει έναν πόρο, του δίνεται η δυνατότητα να ζητήσει συγκεκριμένη αναπαράσταση, ρωτώντας με το κατάλληλο representationname query parameter. Ως default τιμή της παραμέτρου αυτής ορίζεται από το MDE Engine το resourcename_property1_property2_..._propertyn, όπου Ν ο αριθμός των ιδιοτήτων. Ο controller ζητάει από τον handler την αναπαράσταση με representationname resourcename_propertyx_propertyy_.... O Handler θα του επιστρέψει με τη σειρά του μια αναπαράσταση του πόρου, την οποία θα χτίζει με το πρότυπο χτίστη έτσι ώστε να έχει ως ιδιότητες αυτές που αναφέρονται στο όνομα της αναπαράστασης που του ζητήθηκε από τον controller. Αν δηλαδή ζητηθεί η αναπαράσταση με το όνομα resourcename_propertyx_propertyy, και αν αυτή η αναπαράσταση έχει οριστεί στο στάδιο δημιουργίας του CIM Μοντέλου, τότε ο handler θα επιστρέψει μια αναπαράσταση του πόρου που ζητήθηκε, με ιδιότητες τις propertyx και propertyy. Αν η αναπαράσταση που ζήτησε ο πελάτης δεν έχει οριστεί στο στάδιο δημιουργίας του CIM μοντέλου, τότε ο handler επιστρέφει ένα όνομα με το οποίο o client θα μπορεί να ζητήσει μια σωστά ορισμένη αναπαράσταση. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

128 4.8.2 Πρότυπο Παρατηρητή Οι διαφορές ανάμεσα σε ένα endpoint στο οποίο έχει εφαρμοστεί το πρότυπο Παρατηρητή και σε ένα που δεν έχει εφαρμοστεί το πρότυπο παρουσιάζονται παρακάτω H κλάση παρατηρητή Η εισαγωγή του προτύπου Παρατηρητή σε έναν πόρο έχει ως αποτέλεσμα τη δημιουργία της κλάσης JavaResourceObserver.java, η οποία υλοποιεί την οντότητα του παρατηρητή. Είναι εμπλουτισμένη με Ηibernate annotations με σκοπό τη δημιουργία ενός πίνακα με τους παρατηρητές του συστήματος για τους πόρους για τους οποίους ορίστηκε. Οι ιδιότητες της κλάσης αυτής (και άρα τα στοιχεία του πίνακα παρατηρητών) είναι: Πίνακας 124. Ιδιότητες της κλάσης παρατηρητή σε Java Ιδιότητα Τύπος Επεξήγηση οbserverid Int Το μοναδικό αναγνωριστικό του κάθε παρατηρητή. HTTPAction String Η ενέργεια την οποία παρατηρεί ο παρατηρητής. Τιμές: GET PUT UPDATE DELETE name String Το όνομα του παρατηρητή. type String Ο τύπος του παρατηρητή, αν δηλαδή ακούει σε Τιμές: instance verb συγκεκριμένη εγγραφή πόρου ή σε όλους τους πόρους στο ρήμα HTTPAction. action String Ιδιότητα που ενσωματώνει επιπλέον πληροφορία για τον παρατηρητή. Αν για παράδειγμα στο action υπάρχει μια διεύθυνση ηλεκτρονικού ταχυδρομείου, τότε ο παρατηρητής θα στέλνει mail στη διεύθυνση που υπάρχει σε αυτό το πεδίο. actiondone Boolean Ιδιότητα που πληροφορεί εάν ο παρατηρητής έχει εκτελέσει την ενέργεια για την οποία ορίστηκε. Οι μέθοδοι τις οποίες μπορεί να εκτελέσει μια οντότητα παρατηρητή, εκτός από τους κλασσικούς setters και getters μιας κλάσης Java, είναι οι ακόλουθες: Πίνακας 125. Mέθοδοι της κλάσης παρατηρητή σε Java. Όνομα Τύπος Επεξήγηση update() void Η μέθοδος αυτή καλείται όταν πραγματοποιείται η αντίδραση στην παρατηρούμενη ενέργεια. generateandsend () void Αρχικοποιεί τις ρυθμίσεις για την αποστολή ηλεκτρονικού μηνύματος μέσω του Google Mail API. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

129 Οι κλάσεις των παρατηρούμενων ενεργειών Όταν σε έναν πόρο εισάγεται το πρότυπο Παρατηρητή για ένα συγκεκριμένο ρήμα HTTP, τότε ο κλασικός HTTPActionHandler σταματάει να είναι σε λειτουργία και από τον controller καλείται ο αντίστοιχος ObservableHTTPActionHandler. O δεύτερος είναι μια επέκταση του πρώτου, με τη διαφορά ότι σε αυτόν έχουν ενσωματωθεί οι μέθοδοι για τη δημιουργία και την αρχικοποίηση των οντοτήτων παρατηρητών. Οι επιπλέον ενέργειες ενός ObservableHTTPActionHandler παρουσιάζονται παρακάτω: 1. Στον constructor της κλάσης καλείται ο Hibernate controller, έτσι ώστε να ληφθεί η λίστα με τους observers. 2. Έχουν οριστεί οι παρακάτω μέθοδοι για την αρχικοποίηση των παρατηρητών και για την ενεργοποίηση και την απενεργοποίησή τους. Οι μέθοδοι register ενεργοποιούν έναν παρατηρητή ενώ η μέθοδος unregister τον απενεργοποιεί και τον διαγράφει. Πίνακας 126. Μέθοδοι της κλάσης που υλοποιεί ένα παρατηρούμενο HTTP ρήμα σε Java. registertoinstance(string observerreaction) Όνομα Τύπος Επεξήγηση registertoverb(string observerreaction) int Θέτει την ιδιότητα type ενός παρατηρητή σε verb, ορίζει την ενέργεια αντίδρασης του παρατηρητή για την εκτέλεση της ενέργειας που παρατηρεί. Επιστρέφει το observerid του συγκεκριμένου παρατηρητή. int Θέτει την ιδιότητα type ενός παρατηρητή σε instance, ο- ρίζει την ενέργεια αντίδρασης του παρατηρητή για την εκτέλεση της ενέργειας που παρατηρεί και επιστρέφει το observerid του συγκεκριμένου παρατηρητή. unregister (String observerid) void Αρχικοποιεί τις ρυθμίσεις για την αποστολή ηλεκτρονικού μηνύματος μέσω του Google Mail API. notifyobservers() void Ειδοποιεί τους παρατηρητές ότι η ενέργεια έλαβε χώρα, καλώντας για κάθε ενεργό παρατηρητή τη μέθοδο update() Οι controllers Για την υποστήριξη των παρατηρούμενων HTTP ενεργειών οι controllers των πόρων στους οποίους έχει εφαρμοστεί το πρότυπο παρατηρητή έχουν μεταβληθεί κατάλληλα. Πιο συγκεκριμένα, χρησιμοποιείται η μέθοδος που εκτελεί το PUT HTTP ρήμα για να κληθούν και να αρχικοποιηθούν παρατηρήσιμες ενέργειες, με την χρήση επιπλέον query παραμέτρων. Έτσι επιτυγχάνεται η μη παραβίαση του RMM και της αρχιτεκτονικής REST. Για κάθε μέθοδο που εκτελεί παρατηρήσιμη ενέργεια, ο controller αρχικοποιεί και καλεί τον παρατηρήσιμο handler και όχι τον κανονικό Hibernate Controller Για την υποστήριξη του προτύπου παρατηρητή, η κλάση HibernateController.java, η οποία εκτελεί συναλλαγές μεταξύ της υπηρεσίας και τη βάσης δεδομένων, έχει εμπλουτιστεί κατάλληλα. Πιο συγκεκριμένα, έχουν υλοποιηθεί οι μέθοδοι createresourceobserver, updateresourceobserver, getresourceobservers, deleteresourceobserver, όπου Resource το όνομα του συγκεκριμένου πόρου. Παρακάτω περιγράφεται η λειτουργικότητα των μεθόδων αυτών: ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

130 Πίνακας 127. Επιπλέον μέθοδοι της κλάσης HibernateController.java για τους πόρους που ακολουθούν το πρότυπο παρατηρητή. Όνομα createresourceobserver updateresourceobserver getresourceobservers deleteresourceobserver Επεξήγηση Εκτελεί τις συναλλαγές της υπηρεσίας με τη βάση δεδομένων με στόχο τη δημιουργία νέων εγγραφών παρατηρητών. Εκτελεί τις συναλλαγές της υπηρεσίας με τη βάση δεδομένων με στόχο την ανανέωση/αναβάθμιση της εγγραφής ενός ήδη υπάρχοντος παρατηρητή. Εκτελεί τις συναλλαγές της υπηρεσίας με τη βάση δεδομένων με στόχο την κλήση των εγγραφών των ήδη υπαρχόντων παρατηρητών. Εκτελεί τις συναλλαγές της υπηρεσίας με τη βάση δεδομένων με στόχο τη διαγραφή μιας εγγραφής ενός ήδη υπάρχοντος παρατηρητή. *Όπου resource το όνομα του πόρου Τέλος, πρέπει να σημειωθεί ότι έχουν προστεθεί και κάποιες παράμετροι αρχικοποίησης του Hibernate Controller μέσα στο HibernateUtil.class και ένα επιπλέον dependency στο maven configuration αρχείο, dependency που επιτρέπει τη χρήση του Google Mail API Πρότυπο Μνήμης Οι διαφορές ανάμεσα σε ένα endpoint στο οποίο έχει εφαρμοστεί το πρότυπο Μνήμης και σε ένα που δεν έχει εφαρμοστεί το πρότυπο παρουσιάζονται παρακάτω H κλάση του στιγμιότυπου μνήμης Η εισαγωγή του προτύπου μνήμης σε έναν πόρο έχει ως αποτέλεσμα τη δημιουργία της κλάσης στιγμιότυπου μνήμης, JavaResourceMemento.java, όπου Resource το όνομα του πόρου. Είναι εμπλουτισμένη με Ηibernate annotations με σκοπό τη δημιουργία ενός πίνακα στη βάση με τα στιγμιότυπα μνήμης του πόρου τον οποίο ορίστηκε. Η κλάση αυτή έχει τις ίδιες ιδιότητες με τον πόρο αυτόν και επιπλέον: Πίνακας 128. Επιπλέον Ιδιότητες της κλάσης στιγμιοτύπου μνήμης σε Java. Ιδιότητα Τύπος Επεξήγηση mementoid Int Το μοναδικό αναγνωριστικό του κάθε στιγμιότυπου μνήμης. oldness Int Στοιχείο που δηλώνει την παλαιότητα του στιγμιότυπου μνήμης. Κάθε φορά που ένα στιγμιότυπο εισάγεται για ένα στιγμιότυπο κάποιου πόρου, το oldness όλων των υπόλοιπων αντίστοιχων στιγμιότυπων μνήμης αυξάνεται κατά ένα. Αυτό σημαίνει ότι το πιο καινούριο στιγμιότυπο είναι αυτό με τον μικρότερο αριθμό oldness. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

131 Οι μέθοδοι τις οποίες μπορεί να εκτελέσει μια οντότητα στιγμιότυπου μνήμης, εκτός από τους κλασσικούς setters και getters μιας κλάσης Java, είναι οι ακόλουθες: Πίνακας 129. Μέθοδοι της κλάσης στιγμιοτύπου μνήμης σε Java. Όνομα Τύπος Επεξήγηση creatememento() void Καλώντας τον Hibernate controller δημιουργεί ένα στιγμιότυπο μνήμης στη βάση. definememento(int resourceid) void Αρχικοποιεί τις ρυθμίσεις για τη δημιουργία του στιγμιότυπου μνήμης. updatemementos(resourcememento omemento) void Αυξάνει το oldness των στιγμιότυπων μνήμης. getbookmarkmementohanlder(int resourceid, void Επιστρέφει το στιγμιότυπο μνήμης με το int oldness) putrestorebookmarkfrommementohandler(int resourceid, int oldness) Ο controller και οι handlers void oldness που του ζητήθηκε. Επαναφέρει στη μνήμη της υπηρεσίας το στιγμιότυπο μνήμης σύμφωνα με το οldness που ζητήθηκε. Ο μόνος περιορισμός που εισάγεται κατά τη διαδικασία επαναφοράς, είναι το γεγονός ότι μια διαγραμμένη εγγραφή από τη βάση θα επανέλθει με διαφορετικό Id, λόγω του περιορισμού μοναδικότητας των κλειδιών της βάσης δεδομένων του συστήματος. *Όπου resource το όνομα του πόρου Για την υποστήριξη του προτύπου μνήμης, ο controller και οι handlers ενός πόρου στον οποίο έχει εισαχθεί το πρότυπο μεταβάλλονται κατάλληλα. Πιο συγκεκριμένα, στις τρείς μεθόδους του controller έχουν εισαχθεί επιπλέον query παράμετροι, τους οποίους χρησιμοποιεί ο πελάτης της υπηρεσίας ανάλογα με τις α- νάγκες του. Στον παρακάτω πίνακα παρουσιάζονται συνοπτικά οι προσθήκες στις συναρτήσεις αυτές: Πίνακας 130. Διαφορές στους handlers των HTTP ερωτημάτων για την εύρυθμη λειτουργία του προτύπου μνήμης. Μέθοδος Τύπος Επιπλέον ορίσματα Επεξήγηση getresource resourcemodel mementonum Int O πελάτης, εκτελώντας ένα GET HTTP ε- ρώτημα με την παράμετρο mementonum μπορεί να ζητήσει την συγκεκριμένη κατάσταση πόρου. Αν το mementonum είναι 0, τότε επιστρέφεται η τωρινή κατάσταση του πόρου, αλλιώς επιστρέφεται το στιγμιότυπο με oldness ίσο με το mementonum που ζήτησε ο πελάτης. putresource resourcemodel mementonum, action Int String O πελάτης, εκτελώντας ένα PUT HTTP ε- ρώτημα με τις παραμέτρους action και mementonum, μπορεί είτε να ζητήσει από την υπηρεσία να κρατήσει στιγμιότυπο μνήμης είτε να επαναφέρει στη μνήμη το στιγμιότυπο μνήμης με oldness ίσο με το mementonum. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

132 deleteresource ΜΟΝΤΕΛΟΠΟΙΗΣΗ ΜΗ ΛΕΙΤΟΥΡΓΙΚΩΝ ΑΠΑΙΤΗΣΕΩΝ ΛΟΓΙΣΜΙΚΟΥ ΣΕ ΜΟΝΤΕΛΑ ΔΙΑΔΙΚΤΥΑΚΩΝ ΣΥΣΤΗΜΑΤΩΝ REST resourcemodel keepmemento String O πελάτης, εκτελώντας ένα DELETE HTTP ερώτημα με την παράμετρο keep- Memento, μπορεί να ζητήσει από την υπηρεσία να κρατήσει ένα στιγμιότυπο μνήμης πριν τη διαγραφή του πόρου. *Όπου resource το όνομα του πόρου Ο Hibernate Controller Για την υποστήριξη του προτύπου Μνήμης, η κλάση HibernateController.java, η οποία εκτελεί συναλλαγές μεταξύ της υπηρεσίας και τη βάσης δεδομένων, έχει εμπλουτιστεί κατάλληλα. Πιο συγκεκριμένα, έχουν υλοποιηθεί οι μέθοδοι createresourcememento, updateresourcememento, getresourcemementos, delete- ResourceMemento και getresourcememento, όπου Resource το όνομα του συγκεκριμένου πόρου. Παρακάτω περιγράφεται η λειτουργικότητα των μεθόδων αυτών: Πίνακας 131. Επιπλέον μέθοδοι της κλάσης HibernateController.java για τους πόρους που ακολουθούν το πρότυπο μνήμης. Όνομα createresourcememento updateresourcememento getresourcememento getresourcemementos deleteresourcememento Επεξήγηση Εκτελεί τις συναλλαγές της υπηρεσίας με τη βάση δεδομένων με στόχο τη δημιουργία νέων εγγραφών στιγμιότυπων μνήμης. Εκτελεί τις συναλλαγές της υπηρεσίας με τη βάση δεδομένων με στόχο την ανανέωση/αναβάθμιση της εγγραφής ενός ήδη υπάρχοντος στιγμιότυπου μνήμης. Εκτελεί τις συναλλαγές της υπηρεσίας με τη βάση δεδομένων με στόχο την κλήση των κλήση της εγγραφής ενός ήδη υπάρχοντος στιγμιότυπου μνήμης. Εκτελεί τις συναλλαγές της υπηρεσίας με τη βάση δεδομένων με στόχο την κλήση των ήδη υπαρχόντων εγγραφών στιγμιότυπων μνήμης.. Εκτελεί τις συναλλαγές της υπηρεσίας με τη βάση δεδομένων με στόχο τη διαγραφή μιας εγγραφής ενός ήδη υπάρχοντος στιγμιότυπου μνήμης. *Όπου resource το όνομα του πόρου Πρότυπο Γέφυρας Οι διαφορές ανάμεσα σε ένα endpoint στο οποίο έχει εφαρμοστεί το πρότυπο Γέφυρας και σε ένα που δεν έχει εφαρμοστεί το πρότυπο παρουσιάζονται παρακάτω H κλάση αφαίρεση και του handler και η κλάση που την κληρονομεί Η εισαγωγή του προτύπου Γέφυρας σε έναν αλγοριθμικό πόρο ο οποίος έχει εξωτερική σύνδεση με υπηρεσία ή είναι πόρος αναζήτησης, έχει ως αποτέλεσμα την παραγωγή μιας κλάσης αφαίρεσης και μιας κλάσης υλοποίησης της αφαίρεσης για κάθε HTTP handler που χειρίζεται ο πόρος αυτός. Πιο αναλυτικά, η κλάση αφαίρεση περιλαμβάνει όλες τις δηλώσεις των συναρτήσεων που απαιτούνται σίγουρα από τον controller του πόρου. Η κλάση υλοποίηση είναι και στις δύο περιπτώσεις αυτή που θα παρήγαγε το S-CASE, χωρίς την εισαγωγή του προτύπου. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

133 Ο controller ΜΟΝΤΕΛΟΠΟΙΗΣΗ ΜΗ ΛΕΙΤΟΥΡΓΙΚΩΝ ΑΠΑΙΤΗΣΕΩΝ ΛΟΓΙΣΜΙΚΟΥ ΣΕ ΜΟΝΤΕΛΑ ΔΙΑΔΙΚΤΥΑΚΩΝ ΣΥΣΤΗΜΑΤΩΝ REST Για την υποστήριξη του προτύπου γέφυρας, ο controller ενός πόρου στον οποίο έχει εφαρμοστεί το πρότυπο γέφυρας έχει μεταβληθεί κατάλληλα. Πιο συγκεκριμένα, στις μεθόδους που καλούν τους handler των HTTP ερωτημάτων έχει εισαχθεί η query παράμετρος action, η οποία αποτελεί ουσιαστικά οδηγία τη συγκεκριμένη υλοποίηση handler που θα κληθεί από τη μέθοδο που ζητήθηκε. Ως προεπιλεγμένη υλοποίηση, όπως έχει προαναφερθεί, χρησιμοποιείται αυτή που παράγει το S-CASE χωρίς την χρήση του προτύπου γέφυρας. Ένας προγραμματιστής μπορεί να εισάγει νέους handlers και μέσω της συνθήκης εντός των μεθόδων του controller μπορεί να καλεί τις δικές του υλοποιήσεις κατά την εκτέλεση, με τη χρήση του κατάλληλου query parameter. Κάπως έτσι, επιτεύχθηκε και η μερική προσθήκη του προτύπου Command Διαταγής στην παραγόμενη υπηρεσία. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

134 5 Εφαρμογή της επέκτασης στο RESTMarks 5.1 To RESTMarks Στο κεφάλαιο αυτό, παρουσιάζεται μια επίδειξη της δημιουργίας και της εκτέλεσης μιας υπηρεσίας με τη χρήση του S-CASE και την επέκταση που δημιουργήθηκε στα πλαίσια της διπλωματικής αυτής. Πιο συγκεκριμένα, θα χρησιμοποιηθεί η υπηρεσία RESTMarks, πάνω στους πόρους της οποίας θα εφαρμοστούν τα διάφορα πρότυπα σχεδίασης. Το RESTMarks είναι μια υπηρεσία που θα μπορούσε να χαρακτηριστεί ως κοινωνικό δίκτυο. Αποτελεί την υλοποίηση μιας εφαρμογής που δίνει τη δυνατότητα στους χρήστης της να αποθηκεύουν, ανακτούν και να διαμοιράζονται σελιδοδείκτες. Οι χρήστες μπορούν επίσης να δίνουν ετικέτες στους σελιδοδείκτες τους. Εκτός από τους CRUD πόρους (account, bookmark, tag) το RESTMarks περιέχει και αλγοριθμικούς πόρους (tagsearch). account [1..*] -username: String - String -password: String has attributes depending on the searchable resource bookmark AlgoTagSearch -url : String tag [1..*] [1..*] -descritpion: String Εικόνα 44. Διάγραμμα κλάσεων του RESTMarks. Το RESTMarks θα αποτελέσει την ιδανική υπηρεσία παράδειγμα την οποία θα χρησιμοποιήσει η επέκταση που υλοποιήθηκε στη διπλωματική αυτή, καθώς διαθέτει τέσσερις πόρους, στον καθένα από τους οποίους θα εφαρμοστεί ένα πρότυπο σχεδίασης. Όλα τα απαραίτητα δεδομένα για τη δημιουργία της υπηρεσίας βρίσκονται αποθηκευμένα σε μια επαυξημένη οντότητα μοντέλου YAML. To πρώτο βήμα είναι ρύθμιση κάποιων βασικών παραμέτρων στον top layer wizard του MDE GUI. H διαδικασία φαίνεται στην εικόνα δεξιά. Ορίζεται το αρχείο εισόδου, το όνομα της υπηρεσίας, ο φάκελος εξόδου, το IP και το Port της βάσης δεδομένων, το username, το password και ο τύπος της βάσης δεδομένων. Τέλος επιλέγονται οι επεκτάσεις που θα εφαρμοστούν στην υπηρεσία. Στο συγκεκριμένο παράδειγμα θα εφαρμοστούν οι επεκτάσεις προτύπων σχεδίασης και αναζήτησης στη βάση. Εικόνα 45. Top Level GUI ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

135 Στο επόμενο βήμα ορίζονται όλες οι απαραίτητες πληροφορίες για τη δημιουργία του CIΜ Core μοντέλου. Αυτό σημαίνει ότι ορίζονται σαφώς οι ποροι, ο τύπος τους, οι ιδιότητες των πόρων, οι αναπαραστάσεις μέσων (media format) εισόδου και εξόδου και τα CRUD ρήματα που θα επιρέπονται σε κάθε πόρο. Δίνεται επιπλέον η επιλογή δημιουργίας συσχετίσεν ανάμεσα σε πόρους. Έπειτα, μέσω του wizard της δημιουργίας του Search CIM μοντέλου, ορίζονται οι παράμετροι για τον αλγοριθμικό πόρου που θα χρησιμοποιηθεί από την επέκταση αναζήτησης. Εικόνα 47. Ορισμός του Search CIM μοντέλου. Εικόνα 46. Ορισμός του CORE CIM μοντέλου. Τέλος, εμφανίζεται ο wizard για την παραμετροποίηση του CIM μεταμοντέλου προτύπων σχεδίασης, ο wizard που υλοποιεί δηλαδή τη δημιουργία του CIM μοντέλου της επέκτασης της διπλωματικής αυτής. Εικόνα 48. Επιλογή των προτύπων σχεδίασης που θα εφαρμοστούν. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

136 Στα επόμενα κεφάλαια παρουσιάζεται η εφαρμογή του κάθε προτύπου σε έναν από τους πόρους του REST- Marks, η παραμετροποίηση του CIM μοντέλου, η παραγόμενη υπηρεσία και στιγμιότυπα από την εκτέλεσή της. 5.2 Παραγωγή της υπηρεσίας Το πρότυπο Χτίστη στον πόρο account Στον πόρο account του RESTMarks θα εφαρμοστεί το πρότυπο Χτίστη για τη δημιουργία δύο αναπαραστάσεων. Η μία αναπαράσταση θα περιέχει και τις τρεις ιδιότητες του πόρου και η άλλη θα περιέχει μόνο το username και το . Εικόνα 49. Aναπαράσταση του account με ιδιότητες password, username και . Εικόνα 50. Aναπαράσταση του account με ιδιότητες username και . ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

137 5.2.2 To πρότυπο Μνήμης στον πόρο bookmark Στον πόρο bookmark του RESTMarks θα εφαρμοστεί το πρότυπο Μνήμης για τη δημιουργία στιγμιότυπων μνήμης. Στη βάση θα κρατιούνται μέχρι και 10 στιγμιότυπα παλαιότερες καταστάσεις του πόρου. Εικόνα 51. Εφαρμογή του προτύπου μνήμης στον πόρο bookmark Το πρότυπο παρατηρητή στον πόρο tag Στον πόρο tag του RESTMarks θα εφαρμοστεί το πρότυπο Παρατηρητής για τη δημιουργία οντοτήτων που παρακολουθούν τα HTTP ρήματα PUT (δηλαδή τα CRUD Update). Εικόνα 52. Εφαρμογή του προτύπου παρατηρητή στον πόρο tag. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

138 5.2.4 To πρότυπο Γέφυρας στον πόρο tagsearch Στον πόρο tagseach του RESTMarks θα εφαρμοστεί το πρότυπο Γέφυρας για τη δημιουργία αφαιρέσεων και διαφορετικών υλοποιήσεων του handler αναζήτησης. Εικόνα 53. Εφαρμογή του προτύπου παρατηρητή στον πόρο tagsearch. 5.3 Εκτέλεση της υπηρεσίας Στο κεφάλαιο αυτό φαίνεται η αλληλεπίδραση με τη παραχθείσα υπηρεσία. Παρουσιάζονται παραδείγματα για όλες τις ενέργειες που μπορεί να εκτελέσει η υπηρεσία σύμφωνα με τις οδηγίες που στέλνει ένας πελάτης μέσω query παραμέτρων κατά HTTP ερωτήματα που εκτελεί Αρχικοποίηση και εκτέλεση Η υπηρεσία που παράγεται, μέσω του maven εργαλείου χτίζεται και τρέχει σε έναν Jetty server. Οι δύο παραπάνω τεχνολογίες δεν θα παρουσιαστούν διότι η παρουσίασή τους ξεπερνάει τα όρια της διπλωματικής αυτής. Συνοπτικά, το maven είναι ένα εργαλείο πλατφόρμα διαχείρισης project και ο jetty server είναι ένας εξυπηρετητής που μπορεί να τρέξει σε τοπικό δίκτυο. Ο server αυτός στη συγκεκριμένη περίπτωση θα χρησιμοποιηθεί για τον έλεγχο των RESTful API που αναπτύσσει το S-CASE μαζί με την επέκταση της διπλωματικής. Μόλις ξεκινήσει η λειτουργία του server και κάνουμε ένα ερώτημα στο RESTMarks, η βάση δεδομένων δημιουργείται επιτυχώς. Όπως φαίνεται και στην παρακάτω εικόνα, έχουν δημιουργηθεί οι πίνακες που αποθηκεύουν τους πόρους account, tag, bookmark καθώς και ο πίνακας για τους παρατηρητές του πόρου tag, tagobserver, και ο πίνακας τα στιγμιότυπα μνήμης του πόρου bookmark, bookmarkmemento. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

139 Εικόνα 54. Βάση δεδομένων postgres για την υπηρεσία RESTMarks Για τον σωστό έλεγχος της υπηρεσίας, πρέπει να αρχικά να δημιουργηθούν οι πόροι στη βάση δεδομένων του συστήματος. Αυτό πραγματοποιείται με τη χρήση POST HTTP ερωτημάτων. Εκτελούνται μέσω του POSTMan (ένα εργαλείο διαχείρισης HTTP ερωτημάτων) τα εξής ερωτήματα: 1. POST με σώμα: { dontsios@gmail.com, username : dimitrisdontsios,\ passworkd : } 2. POST με σώμα: { url : } 3. POST με σώμα: { description : It is the user s profile } Και στις τρεις παραπάνω περιπτώσεις ο server αποκρίνεται με κωδικό 200 : OK και με το σώμα της απάντησης που έχει προκαθορισμένη η υπηρεσία. Το σώμα για τις υπηρεσίες που παράγει το S-CASE αποτελείται από τις ιδιότητες του πόρου και από τα hypermedia links του. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

140 5.3.2 Λειτουργικότητα προτύπου Χτίστη. Για τον έλεγχο του προτύπου Χτίστη και της λειτουργικότητάς του εκτελούνται τα εξής ερωτήματα: Πίνακας 132. GET στο account για τη λήψη αναπαράστασης με ιδιότητες username και . Ρήμα GET URI Query Parameters representationname account_username_ Σώμα - Στόχος H λήψη της αναπαράστασης με ιδιότητες username και . Απάντηση Η αναπαράσταση που ζητήθηκε Πίνακας 133. GET στο account για τη λήψη αναπαράστασης με ιδιότητες username και password. Ρήμα GET URI Query Parameters representationname account_username_password Σώμα - Στόχος H λήψη της αναπαράστασης με ιδιότητες username και password. Απάντηση Μια κενή από ιδιότητες του πόρου account αναπαράσταση και οδηγία προς τον client με την default αναπαράσταση που μπορεί να ζητήσει Λειτουργικότητα του προτύπου Παρατηρητή. Για τον έλεγχο του προτύπου Παρατηρητή και της λειτουργικότητάς του εκτελούνται τα εξής ερωτήματα: Πίνακας 134. PUT στο bookmark για την εγγραφή ενός παρατηρητή στις ενέργειες PUT συγκεκριμένου tag. Ρήμα PUT URI Query Parameters action registertoinstance reaction dontsios@gmail.com obserververb PUT Σώμα { "description" : "It's the users profile" } Στόχος H εγγραφή ενός observer στο tag με tagid 3 για τα ρήματα PUT και η ενημέρωση της ενέργειας PUT με αποστολή στο dontsios@gmail.com. Απάντηση 200 : OK, οι ιδιότητες και τα hypermedia links του πόρου και το observerid (4) του παρατηρητή. Πίνακας 135. PUT στο tag για τον έλεγχο της λειτουργικότητας του παρατηρητή. Ρήμα PUT URI Query Parameters action registertoinstance reaction dontsios@gmail.com obserververb PUT Σώμα { "description" : "It's the users profile" } Στόχος H εγγραφή ενός observer στο tag με tagid 3 για τα ρήματα PUT και η ενημέρωση της ενέργειας PUT με αποστολή στο dontsios@gmail.com. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

141 Απάντηση ΜΟΝΤΕΛΟΠΟΙΗΣΗ ΜΗ ΛΕΙΤΟΥΡΓΙΚΩΝ ΑΠΑΙΤΗΣΕΩΝ ΛΟΓΙΣΜΙΚΟΥ ΣΕ ΜΟΝΤΕΛΑ ΔΙΑΔΙΚΤΥΑΚΩΝ ΣΥΣΤΗΜΑΤΩΝ REST 200 : OK, οι ιδιότητες και τα hypermedia links του πόρου και το observerid (4) του παρατηρητή. Πίνακας 136. PUT στο tag για τον έλεγχο της λειτουργικότητας του παρατηρητή 2. Ρήμα PUT URI Query Parameters - Σώμα { "description" : "It's the users profile!" } Στόχος Τεστ για το αν ο παρατηρητής έτρεξε. Απάντηση 200 : OK και οι ιδιότητες και τα hypermedia links του πόρου. Σχόλια Μετά την εκτέλεση των παραπάνω δύο ερωτημάτων, ένα mail έχει αποσταλεί στην διεύθυνση dontsios@gmail.com. Εικόνα 55. ενημέρωσης από τον παρατηρητή. Πίνακας 137. PUT στο tag για την εγγραφή ενός παρατηρητή στις ενέργειες PUT όλων των tags. Ρήμα PUT URI Query Parameters action registertoverb obserververb PUT Σώμα { "description" : "It's the users profile!" } Στόχος H εγγραφή ενός observer σε όλους τους tag πόρους για τα ρήματα PUT. Απάντηση 200 : OK, οι ιδιότητες και τα hypermedia links του πόρου και το observerid (5) του παρατηρητή ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

142 Πίνακας 138. PUT στο tag για τον έλεγχο της λειτουργικότητας του παρατηρητή. Ρήμα PUT URI Query Parameters - Σώμα { "description" : "It's the users profile!" } Στόχος Τεστ για το αν ο παρατηρητής έτρεξε. Απάντηση 200 : OK και οι ιδιότητες και τα hypermedia links του πόρου. Σχόλια Μπορεί κανείς να διαπιστώσει ότι ο παρατηρητής εκτελείται βλέποντας τα μηνύματα που εκτυπώνει η κονσόλα του server. Πίνακας 139. PUT στο tag για την διαγραφή ενός παρατηρητή. Ρήμα PUT URI Query Parameters action unregister observerid 4 obserververb PUT Σώμα { "description" : "It's the users profile!" } Στόχος H διαγραφή του observer με observerid 4 από την ενέργεια που έχει οριστεί να παρακολουθεί. Απάντηση 200 : OK, οι ιδιότητες και τα hypermedia links του πόρου. Σχόλια Μπορεί να παρατηρηθεί ότι η ενέργεια εκτελέστηκε από μια γρήγορη ματιά στον πίνακα της βάσης που είναι αποθηκευμένοι οι παρατηρητές. Εικόνα 56. Πίνακας παρατηρητών tag στη βάση δεδομένων μετά το τελευταίο ερώτημα. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ

143 5.3.4 Λειτουργικότητα του προτύπου Μνήμης. Για τον έλεγχο του προτύπου Μνήμης και της λειτουργικότητάς του εκτελούνται τα εξής ερωτήματα: Πίνακας 140. PUT στο bookmark με εντολή διατήρησης στιγμιοτύπου μνήμης. Ρήμα PUT URI Query Parameters action keepmemento Σώμα { url : } Στόχος Διατήρηση της προηγούμενης κατάστασης του bookmark 2. Απάντηση 200 : OK Σχόλιο Μπορεί να διαπιστωθεί ότι η ενέργεια ήταν πετυχημένη ανατρέχοντας στον πίνακα bookmarkmemento της βάσης δεδομένων. Εκεί παρατηρείται η προηγούμενη κατάσταση του πόρου. Εικόνα 57. Πίνακας στιγμιότυπων μνήμης bookmark στη βάση δεδομένων. Πίνακας 141. GET στο bookmark για τη λήψη συγκεκριμένου στιγμιοτύπου μνήμης. Ρήμα GET URI Query Parameters takememento 1 Σώμα - Στόχος Προβολή της ακριβώς προηγούμενης κατάστασης του πόρου bookmark με bookmarkid 2. Απάντηση { "bookmarkid": "2", "url": " } Σχόλια Αν κανείς ήθελε να διαλέξει ακόμα πιο προηγούμενη κατάσταση, θα μπορούσε να επιλέξει στιγμιότυπο μνήμης μεγαλύτερο από 1 και μέχρι 10, σύμφωνα με την υπηρεσία που παράχθηκε. ΘΕΣΣΑΛΟΝΙΚΗ, ΜΑΡΤΙΟΣ