ΠΑΝΕΠΙΣΤΗΜΙΟ ΑΙΓΑΙΟΥ

Transcript

1 ΠΑΝΕΠΙΣΤΗΜΙΟ ΑΙΓΑΙΟΥ ΤΜΗΜΑ ΜΗΧΑΝΙΚΩΝ ΠΛΗΡΟΦΟΡΙΑΚΩΝ ΚΑΙ ΕΠΙΚΟΙΝΩΝΙΑΚΩΝ ΣΥΣΤΗΜΑΤΩΝ ΜΕΤΑΠΤΥΧΙΑΚΟ ΠΡΟΓΡΑΜΜΑ ΣΠΟΥΔΩΝ ΜΑΘΗΜΑ: ΕΛΛΗΝΙΚΟ ΠΛΑΙΣΙΟ ΔΙΑΛΕΙΤΟΥΡΓΙΚΟΤΗΤΑΣ Μοντέλο Τεκμηρίωσης Υπηρεσιών, Εγγράφων και Διαδικτυακών Υπηρεσιών Διδάσκων: Ι. Χαραλαμπίδης, Επ. Καθηγητής

2 Στόχοι Εκπαιδευτικού Μαθήματος Να αποκτήσουν οι καταρτιζόμενοι σφαιρική εικόνα για πρότυπα, μεθόδους και τεχνικές ανάλυσης που χρησιμοποιούνται σήμερα για την μοντελοποίηση της επιχειρησιακής γνώσης και των δεδομένων Να πληροφορηθούν για τεχνολογίες και πρότυπα Καταγραφής Μεταδεδομένων που έχουν διατυπωθεί σε διεθνές επίπεδο Να έχουν πλήρη επίγνωση των κύριων κατευθύνσεων εφαρμογής και αξιοποίησης της μοντελοποίησης επιχειρηματικών διαδικασιών και εγγράφων με τη βοήθεια του Ληξιαρχείου Διαλειτουργικότητας Να γνωρίσουν και να εξοικειωθούν με την έννοια των Διαδικτυακών Υπηρεσιών και τη Μεθοδολογία υλοποίησης τους που προτείνει το ΠΗΔ Να εφαρμόσουν την αποκτημένη τεχνογνωσία στην πράξη με το σχεδιασμό των βασικών διαγραμμάτων μοντελοποίησης μιας δημόσιας υπηρεσίας, των XML Σχημάτων για τα έγγραφα που εμπλέκονται στη διεξαγωγή της και την αναγνώριση και προδιαγραφή των απαιτούμενων web services. Να κατανοούν την έννοια του Ανασχεδιασμού Επιχειρηματικών Διαδικασιών και τι συνεπάγεται στο συμβατικό τρόπο λειτουργίας των Δημοσίων Φορέων 2

3 Περιεχόμενα 1. Εισαγωγή στη BPMN και την Έννοια της Επιχειρησιακής Μοντελοποίησης 2. Μοντελοποίηση Υπηρεσιών στο ΠΗΔ 3. Βασικές Αρχές Ανασχεδιασμού Επιχειρηματικών Διαδικασιών 4. Εισαγωγή στην XML 5. Μοντελοποίηση Εγγράφων και Δεδομένων στο ΠΗΔ 6. Η έννοια των Μεταδεδομένων στο ΠΗΔ 7. Εισαγωγή στις Διαδικτυακές Υπηρεσίες και Προδιαγραφές του ΠΗΔ

4 6. Η έννοια των Μεταδεδομένων στο ΠΗΔ Μοντέλο Τεκμηρίωσης και Διαλειτουργικότητα 1. Εισαγωγή στη BPMN και την Έννοια της Επιχειρησιακής Μοντελοποίησης 2. Μοντελοποίηση Υπηρεσιών στο ΠΗΔ 3. Βασικές Αρχές Ανασχεδιασμού Επιχειρηματικών Διαδικασιών 4. Εισαγωγή στην XML 5. Μοντελοποίηση Εγγράφων και Δεδομένων στο ΠΗΔ 7. Εισαγωγή στις Διαδικτυακές Υπηρεσίες και Προδιαγραφές του ΠΗΔ 4

5 Τι είναι το Μοντέλο Τεκμηρίωσης? Αφορά τον τρόπο τεκμηρίωσης των Συμβατικών και Ηλεκτρονικών Υπηρεσιών, των Εγγράφων και των XML Σχημάτων που πρόκειται να μοντελοποιηθούν και να σχεδιαστούν για τις ανάγκες του Ελληνικού Πλαισίου Παροχής Υπηρεσιών και Πρότυπα Διαλειτουργικότητας (ή Πλαισίου Ηλεκτρονικής Διακυβέρνησης) Περιγράφει τη σημειογραφία, τους κανόνες και τις προδιαγραφές που θα πρέπει να εφαρμόζονται για την ανάπτυξη μοντέλων διαδικασιών και δεδομένων μεταδεδομένων Θέτει τις συμβάσεις ονοματολογίας και σχεδιασμού και τον τρόπο διαχείρισης των εκδόσεων για να διασφαλιστεί η αντιμετώπιση ζητημάτων που εμπίπτουν σε αυτές τις περιοχές με ένα ενιαίο τρόπο για το σύνολο της Ελληνικής Δημόσιας Διοίκησης Κατευθύνει το σχεδιασμό νέων μοντέλων και την προσαρμογή των Μοντέλων που έχει εκδώσει το ΠΗΔ στις ανάγκες και τις απαιτήσεις κάθε Δημόσιου Φορέα με τρόπο που θα παραμένουν συμβατά με τις οδηγίες του ΠΗΔ 5

6 Πού τοποθετείται το Μοντέλο Τεκμηρίωσης? 6

7 Μοντέλο Τεκμηρίωσης : Γιατί? Η υιοθέτηση των προτύπων, οδηγιών και κατευθύνσεων του παρόντος εγγράφου, θα επιτρέψει: την κατανόηση των διαδικασιών και των πληροφοριών που ανταλλάσσονται κάτω από ένα ενιαίο πρίσμα τη μεγιστοποίηση της επαναχρησιμοποίησης της πληροφορίας (μέσω των πρότυπων διαδικασιών και των δομικών XML συστατικών XML Schema Components) για τη βελτίωση της σημασιολογικής διαλειτουργικότητας στον ευρύτερο Δημόσιο Τομέα την ομογενοποίηση και εναρμόνιση των Μοντέλων Διαδικασιών και των XML Σχημάτων για το σύνολο των Φορέων της Δημόσιας Διοίκησης 7

8 Μοντέλο Τεκμηρίωσης : Σε ποιους απευθύνεται? Το κοινό στο οποίο απευθύνεται το παρόν έγγραφο περιλαμβάνει κυρίως: «Μοντελοποιητές» (business modelers) επιχειρηματικών διαδικασιών Αναλυτές (business analysts) επιχειρηματικών διαδικασιών «Ανασχεδιαστές» (business redesigners) επιχειρηματικών διαδικασιών Σχεδιαστές XML Σχημάτων Σε πρώτη φάση, οι προδιαγραφές που τίθενται αξιοποιούνται από: την Ομάδα Έργου του ΠΗΔ, τους Υπεύθυνους για την επέκταση / συντήρησή του, τους Αναδόχους έργων Ηλεκτρονικής Διακυβέρνησης που καλούνται να υιοθετήσουν και να προσαρμόσουν τα Μοντέλα, όποιον άλλο αναζητά κατευθύνσεις και κανόνες μοντελοποίησης Δεδομένου ωστόσο ότι το Μοντέλο Τεκμηρίωσης αποτελεί τεχνικό έγγραφο... Απαραίτητη προϋπόθεση για την κατανόησή του αποτελεί η ύπαρξη επαρκούς τεχνολογικού γνωστικού υποβάθρου 8

9 Εισαγωγή στη BPMN και την Έννοια της Επιχειρησιακής Μοντελοποίησης 1

10 Τι είναι μια Επιχειρηματική Διαδικασία; Επιχειρηματική Διαδικασία είναι ένα δομημένο σύνολο από δραστηριότητες οι οποίες χρησιμοποιούν πληροφορίες, ανθρώπινους και υλικούς πόρους ως είσοδο για να δημιουργήσουν κάποιο αποτέλεσμα που έχει αξία για έναν (εσωτερικό ή εξωτερικό) πελάτη ενός οργανισμού [Hammer and Champy, 1993] Οι επιχειρηματικές Διαδικασίες αναπαριστούν τη ροή εργασίας και πληροφορίας μέσα σε έναν οργανισμό [BOMSIG 1995] Μια διαδικασία ορίζει ΠΩΣ γίνεται κάτι, σε αντίθεση με το προϊόν που δίνει έμφαση στο ΤΙ γίνεται Υπάρχουν διαφορετικές οπτικές κάθε επιχειρηματικής διαδικασίας: οργανισμός, λειτουργίες, δεδομένα που συντελούν στη μείωση της πολυπλοκότητας Διατρέχει αλυσίδες αξίας, οργανισμούς, τμήματα οργανισμών, ανθρώπους 10

11 Τι είναι μια Επιχειρηματική Διαδικασία? Μετασχηματισμός ΣΤΟΙΧΕΙΑ ΕΙΣΟΔΟΥ ΔΙΑΔΙΚΑΣΙΑ ΣΤΟΙΧΕΙΑ ΕΞΟΔΟΥ Επανατροφοδότηση με πληροφορίες ΕΛΕΓΧΟΣ 11

12 Είδη Επιχειρηματικών Διαδικασιών Απλές (single-function): Αφορούν συγκεκριμένες λειτουργίες που εκτελούνται από ένα ορισμένο τμήμα ενός οργανισμού Δια-τμηματικές (cross-functional): Διατρέχουν διάφορες λειτουργίες ή τμήματα ενός οργανισμού. Περισσότερα από 1 άτομα είναι υπεύθυνα για την εκτέλεση τους Κοινές στο πλαίσιο του οργανισμού (common across the enterprise) Δι-επιχειρησιακές (inter-organizational): Απεικονίζουν αμφίδρομη επικοινωνία ανάμεσα σε διαφορετικούς οργανισμούς 12

13 Πόσο καλά γνωρίζουμε τις Επιχειρηματικές Διαδικασίες? Υπηρεσίες Δεδομένα Χρηματικά Ποσά Πληροφορίες / Γνώση Υπηρεσίες Δεδομένα Χρηματικά Ποσά Πληροφορίες / Γνώση Υπηρεσίες Δεδομένα Χρηματικά Ποσά Πληροφορίες / Γνώση 13

14 Η κατάσταση σήμερα... Πηγή: 14

15 Τι είναι ένα Μοντέλο; Aποτελεί μια εξιδανίκευση μιας οντότητας ή κατάστασης, και αποτελεί ένα σύστημα αντικειμένων, ιδιοτήτων και σχέσεων τα οποία έχουν σχεδιαστεί για να μιμούνται, σε συγκεκριμένες σχετικές καταστάσεις, τον χαρακτήρα ενός δοσμένου συστήματος του αληθινού κόσμου Τα μοντέλα πάντα δίνουν έμφαση σε κάποια από τα στοιχεία της πραγματικότητας και υποβιβάζουν ή αγνοούν τα υπόλοιπα Είναι μια απεικόνιση από κάτι, το οποίο έχει σχεδιαστεί για έναν ειδικό σκοπό ή μια σαφής ερμηνεία της αντίληψης ή των ιδεών που μπορεί κάποιος να έχει για μια κατάσταση Mπορεί να εκφραστεί με μαθηματικά, σύμβολα, λέξεις, αλλά είναι βασικά μια περιγραφή από οντότητες, διαδικασίες ή ιδιότητες, καθώς και των σχέσεων ανάμεσα τους. Ένα μοντέλο είναι χρήσιμο όταν διευκολύνει την περιγραφή, κάνει πιο κατανοητή μια σύνθετη κατάσταση και βοηθάει στην επικοινωνία των εννοιών που περιλαμβάνει 15

16 Παραδείγματα Μοντέλων 16

17 Μοντελοποίηση Επιχειρηματικών Διαδικασιών Στοχεύει στην καταγραφή μιας διατεταγμένης αλληλουχίας επιχειρηματικών δραστηριοτήτων και των πληροφοριών που τις υποστηρίζουν Χρησιμοποιείται για να εκφράσει πληροφορία είτε στα άτομα που διαβάζουν το μοντέλο ή ανάμεσα στα άτομα που το δημιουργούν Εξωτερικεύει την επιχειρησιακή γνώση με απώτερο στόχο τη συμφωνία και τη δέσμευση σε μια αναπαράσταση της που θα διαμοιράζεται μέσα στον οργανισμό και θα απεικονίζεται στα πληροφοριακά του συστήματα Παρουσιάζει διάφορα επίπεδα ανάλυσης από απλή απεικόνιση της ροής μιας διαδικασίας μέχρι προσομοίωση και εκτέλεση της 17

18 Βασικές Αρχές Μοντελοποίησης Επιχειρηματικών Διαδικασιών Οπτικοποίηση (Visualization) της διαδικασίας και των συσχετίσεων μεταξύ οργανισμών, δραστηριοτήτων και δεδομένων που περιλαμβάνει Διαχείριση της πολυπλοκότητας μέσω της επιλογής της έμφασης σε συγκεκριμένες όψεις και της επαναχρησιμοποίησης μοντέλων Ενιαία κατανόηση της επιχειρησιακής γνώσης ανάμεσα σε οργανισμό και ειδικό πληροφορικής Σωστή καθοδήγηση του σχεδιασμού και της υλοποίησης πληροφοριακών συστημάτων 18

19 ΤΙ... Σε τι απαντά η Επιχειρησιακή Μοντελοποίηση? Πώς συνδέονται όλες οι πληροφορίες? Μπορεί να λειτουργήσει? Τι ακριβώς χρειαζόμαστε? Πώς καθορίζεται πώς πρέπει να Εξωτερικεύει κανόνες και τη ροή από τα γίνει μια εργασία? ΠΣ Ποιός μπορεί να το κάνει? Πόσο σημαντικό είναι? Πού πηγαίνει κάθε εργασία? Ποιός υπερφορτώνεται? Πώς / πότε έγινε μια εργασία? ΠΩΣ? Απεικονίζει και μοντελοποιεί τις συσχετίσεις μεταξύ πληροφοριών Προσομοιώνει όλες τις εναλλακτικές Περιγράφει τις απαιτήσεις για πόρους Καθορίζει ρόλους Ορίζει προτεραιότητες Δρομολογεί «έξυπνα» τις εργασίες Εξισορροπεί την κίνηση Παρέχει στατιστικά και αναφορές ροής εργασιών 19

20 Στόχοι της Επιχειρησιακής Μοντελοποίησης Τυποποίηση των υπάρχοντων (as-is) και προβλεπόμενων (to-be) διαδικασιών Aνάδειξη των σημείων στον οργανισμό ή τη διαδικασία που χρήζουν βελτιώσεων Διευκόλυνση αυτοματοποιημένων, αποτελεσματικών ροών εργασίας Αύξηση παραγωγικότητας των ανθρώπινων και υλικών πόρων που υποστηρίζουν μια διαδικασία Απλοποίηση των επιχειρηματικών κανόνων και συμμόρφωση με το νομικό πλαίσιο Διαφάνεια στις επιχειρηματικές διαδικασίες Πηγή: Flux Consultancy, Business Process Modelling 20

21 Πώς επιτυγχάνονται οι Στόχοι της Επιχειρησιακής Μοντελοποίησης; Μέσω μιας γλώσσας και σημειογραφίας μοντελοποίησης, που να είναι: Εύκολα κατανοητή από μη ειδικούς σε πληροφορική Επαρκής για τη μοντελοποίηση πολύπλοκων επιχειρηματικών περιβάλλοντων Μέσω ενός «πλαισίου» μοντελοποίησης, το οποίο: Καλύπτει τον κύκλο ζωής των επιχειρησιακών λειτουργιών από την ανάλυση απαιτήσεων μέχρι την «απενεργοποίηση» Εστιάζει σε διαφορετικές όψεις της επιχειρησιακής λειτουργίας αποκρύπτοντας τα μέρη του μοντέλου που δεν αφορούν τη συγκεκριμένη όψη Υποστηρίζει την επαναχρησιμοποίηση των μοντέλων ή τμημάτων τους 21

22 Βασικές Όψεις Μοντελοποίησης Κάθε Φορέας αναπαριστάται σε επίπεδο οργανισμού και λειτουργιών που αναλύουν: Δραστηριότητες Πληροφορία Ροές εργασίας Πόροι Νομικό πλαίσιο Επιχειρηματικοί Κανόνες Συμπεριφορά Πληροφοριακές υποδομές 22

23 Προσεγγίσεις στην Επιχειρησιακή Μοντελοποίηση Zachman Framework for Enterprise Architecture: Προτάθηκε από τον John Zachman το 1987 και ολοκληρώθηκε 5 χρόνια αργότερα CIMOSA Framework for Modelling: Αναπτύχθηκε στο πλαίσιο του Ευρωπαϊκού Έργου AMICE (ESPRIT) GERA Modelling Framework: Προτάθηκε από το IFIP/IFAC Task Force on Architectures for Integrating Manufacturing Activities and Enterprises το 1999 ARIS (Architecture of Integrated Information Systems) Οι προσεγγίσεις αυτές δεν είναι τα εργαλεία που δίνουν τη λύση στο πρόβλημα της Επιχειρησιακής Μοντελοποίησης, αλλα... Παρέχουν έναν ΤΡΟΠΟ ΣΚΕΨΗΣ και μια ΜΕΘΟΔΟΛΟΓΙΑ ΠΩΣ πρέπει να γίνεται η Επιχειρησιακή Μοντελοποίηση 23

24 Επίπεδο Ανάλυσης Βασικές Έννοιες στο «Zachman Framework for Enterprise Architecture» Όψεις Μοντελοποίησης 24

25 Πλεονεκτήματα Μοντελοποίησης Επιχειρηματικών Διαδικασιών Διευκολύνει την κατανόηση της διαδικασίας από κάθε συμμετέχοντα Αποθηκεύει την επιχειρηματική γνώση σε μοντέλα αναφοράς Εστιάζει στο απαιτούμενο επίπεδο ανάλυσης, χωρίς να συμπεριλαμβάνει λεπτομέρειες που αφορούν τα άλλα επίπεδα Δίνει τη δυνατότητα για προσομοίωση μιας διαδικασίας Υπολογίζει το χρόνο και κόστος εκτέλεσης των διαδικασιών Ανάλυση και εξέταση «what-if» σεναρίων με την προσομοίωση της συμπεριφοράς του οργανισμού σε διάφορες περιπτώσεις Αναγνωρίζει τα σύνολα εφαρμογών λογισμικού και τις απαιτούμενες διασυνδέσεις τους, ενώ αναλύει τον απαιτούμενο βαθμό διαλειτουργικότητας μεταξύ τους Βελτιστοποιεί οργανωσιακές αλλαγές Οδηγεί στη βελτίωση του μηχανισμού λήψης αποφάσεων 25

26 Εργαλεία Επιχειρησιακής Μοντελοποίησης CASE Tools: Mega, Casewise Corporate Modeler Suite, Popkin Software System Architect, Rational Rose, Win Design, IBM WebSphere Business Modeler, Sparx Systems Enterprise Architect Business Process Reengineering: ADONIS, Aris, OSSAD Process Design Εργαλεία Σχεδιασμού: MS Visio, MS PowerPoint Open Source: Intalio BPMS Άλλα Εργαλεία: Mo2Go, Cubetto Toolset, Bonapart Ωστόσο, τα πιο γνωστά εργαλεία στην Ευρώπη είναι: ADONIS, Aris, Casewise, WebSphere, System Architect, διότι υποστηρίζονται από βάση δεδομένων. 26

27 Γενικά Χαρακτηριστικά Εργαλείων Μοντελοποίησης Διαδικασιών Εύχρηστο γραφικό περιβάλλον χρήστη με πλούσια λειτουργικότητα και δυνατότητα παραμετροποίησης Συμμόρφωση με διεθνείς μεθοδολογίες Επιχειρησιακής Μοντελοποίησης και με τη σημειογραφία διεθνών προτύπων, όπως BPMN και UML Προχωρημένες δυνατότητες: Μοντελοποίησης εγγράφων, ρόλων, πληροφοριακών συστημάτων και νομικού πλαισίου πλέον της μοντελοποίησης υπηρεσιών Προσομοίωσης διαδικασιών Δυνατότητα αποθήκευσης των Μοντέλων και των αλληλεξαρτήσεων τους σε Βάση Δεδομένων Δυνατότητα εισαγωγής / εξαγωγής των Μοντέλων μαζί με τις συσχετίσεις τους για τη μεταφορά από και προς τα Εργαλεία Δυνατότητα εξαγωγής αναφορών σε word και html μορφή 27

28 Βασικά Χαρακτηριστικά του ADONIS Αποτελεί εμπορικό προϊόν της BOC. Βρίσκεται στην έκδοση 3.9 Υποστηρίζει τις βασικές δραστηριότητες των μεθοδολογιών επιχειρησιακής μοντελοποίησης, όπως απόκτηση πληροφορίας, μοντελοποίηση και σχεδιασμός, ανάλυση, προσομοίωση και αξιολόγηση Παρέχει διάφορες δυνατότητες εισαγωγής / εξαγωγής, δημοσίευσης στον Ιστό, και εργαλεία διαχείρισης Χαρακτηρίζεται για τη λειτουργικότητα και την προσαρμοστικότητα του που επιτρέπει την παραμετροποίηση ανάλογα με τις ανάγκες των χρηστών του Συνεργατικό BPMN Διάγραμμα στο ADONIS Μοντελοποίηση Εγγράφων στο ADONIS Προσομοίωση στο ADONIS 28

29 Δυνατότητες του ADONIS Ομάδες και δομή μοντέλων Εκδόσεις μοντέλων Σημειογραφία και κανόνες μοντελοποίησης Τύποι διαγραμμάτων Συναρτήσεις, λοιπές επιλογές Διαχείριση Βιβλιοθηκών Διαχείριση Μοντέλων Διαχείριση Χρηστών Ομάδες χρηστών Δικαιώματα πρόσβασης Εισαγωγή δεδομένων από φύλλα εργασίας excel ή εξωτερικές βάσεις δεδομένων Εισαγωγή Βάση Δεδομένων Εξαγωγή Αναφορές σε HTML, RTF, Word, PDF Ανταλλαγή μοντέλων σε XML Μετασχηματισμός μοντέλων Μοντελοποίηση Αποθήκευση Μοντέλο = Γραφικά ΚΑΙ κείμενο Ανάλυση Επερωτήσεις (με αποτελέσματα σε μορφή πίνακα) Ανάλυση επίδρασης Υπολογισμός επιδόσεων Αρχείο (παλαιότερες εκδόσεις) Διαχείριση «εναλλακτικών» εκδόσεων BPTrends (Nov. 2005): ADONIS is a well-designed tool that provides a functionality rich modeling and analysis environment behind a very intuitive and friendly UI. 29

30 Βασικά Χαρακτηριστικά του ARIS Αποτελεί εμπορικό προϊόν της IDS Scheer. Βρίσκεται στην Έκδοση 7.02 Διατίθεται ως stand-alone εργαλείο ή ως component του SAP NetWeaver Υποστηρίζει πάνω από 150 σημειογραφίες για τη μοντελοποίηση διαδικασιών, δεδομένων, συστημάτων, οργανισμών, προϊόντων και υπηρεσιών Σύμφωνα με το BPTrends, ARIS offers an integrated and complete software tool portfolio for strategy, design, implementation and controlling of business processes and enterprise architecture management approaches BPMN Διάγραμμα στο ARIS Προσομοίωση στο ARIS 30

31 Βασικά Χαρακτηριστικά του CASEWISE Corporate Modeller Αποτελεί εμπορικό προϊόν της CaseWise. Βρίσκεται στην Έκδοση 10 Διατίθεται σε 2 εκδόσεις: Standard και Enterprise Αφορά: τη μοντελοποίηση και ανασχεδιασμό διαδικασιών, καθώς και τη χάραξη στρατηγικής και τον αρχιτεκτονικό σχεδιασμό Ενημερώνει με mail τους υπεύθυνους των διαδικασιών εάν χρειάζονται ενημέρωση, έγκριση ή έλεγχο BPMN Διάγραμμα στο CaseWise Προσομοίωση στο CaseWise CaseWise Web Portal 31

32 Βασικά Χαρακτηριστικά του ΙΒΜ WebSphere Business Modeler Αποτελεί εμπορικό προϊόν της IBM. Βρίσκεται στην Έκδοση Διατίθεται σε 2 εκδόσεις: Standard και Professional Το component Publishing Service παρέχει ένα forum για το σχολιασμό και την επίλυση ζητημάτων που αφορούν τις διαδικασίες on the spot Πλήρης προσαρμογή των αναφορών χάρη σε διασύνδεση με CrystalReports Περιβάλλον Εργασίας του WebSphere Business Modeler Προσομοίωση στο WebSphere Business Modeler 32

33 Βασικά Χαρακτηριστικά του Popkin Software s System Architect Αποτελεί εμπορικό προϊόν της Popkin Software. Βρίσκεται στην έκδοση 10 Τα μοντέλα αποθηκεύονται σε Microsoft SQL Server Υποστηρίζει τη Microsoft Visual Basic για να δημιουργούν οι χρήστες μακροεντολές και custom εφαρμογές Διάγραμμα και Ορισμός Διαδικασίας στο System Architect 33

34 Βασικά Χαρακτηριστικά του Intalio BPMS Αποτελεί ανοικτό λογισμικό της Intalio. Βρίσκεται στην έκδοση 4.0 Βασίζεται σε πρότυπα που επικρατούν κ ανανεώνονται (BPMN, BPEL, SOAP, XFORMS...) και open source components (Apache Geronimo, Derby, Orbeon, Eclipse...) Είναι ένα εργαλείο με χαμηλό κόστος υιοθέτησης και μικρό κίνδυνο να μείνει χωρίς υποστήριξη Περιλαμβάνει: το Intalio Designer, το Intalio Server, το Intalio Workflow BPMN Διάγραμμα στο Intalio BPMS "Because Intalio is open source, the problem of a heavy investment upfront and shelfware is drastically reduced. Businesses can try the product out; and then through a small amount of investment via training and/or onsite consulting create a prototype project for proof of concept." Neville Bradbury, OpenSoft Australia Προσομοίωση στο Intalio BPMS 34

35 Κριτήρια Επιλογής Εργαλείου Επιχειρησιακής Μοντελοποίησης Αρχιτεκτονική (1-tier, client/server, n-tier) Επεκτασιμότητα με την εισαγωγή νέων συστατικών (components) ή / και βιβλιοθηκών Υποστήριξη Μεθοδολογιών και Προτύπων Ύπαρξη έτοιμης Βιβλιοθήκης Μοντέλων Δυνατότητα αυτόματης δημιουργίας κώδικα Ενοποίηση με άλλα Εργαλεία Ενιαία διαχείριση των μοντέλων που δημιουργούνται από πολλούς χρήστες Ύπαρξη Διαδικτυακής Διεπαφής Χρήστη Διαχείριση χρηστών και ασφάλεια Παροχή πολυγλωσσικού περιεχομένου Ωριμότητα Τεχνική υποστήριξη και νέες εκδόσεις Κόστος απόκτησης άδειας χρήσης 35

36 Ποσοτικά.. Οφέλη για τον Οργανισμό? Μείωση κόστους διαδικασίας % Αύξηση ποιότητας διαδικασίας / λιγότερα λάθη 20 30% Μείωση χρόνου / εξόδων εκπαίδευσης 10 30% Μείωση χρόνου διεκπεραίωσης διαδικασιών 10 30% Μείωση (εσωτερικών) αιτημάτων για υποστήριξη 15 30% Μείωση αριθμού παραπόνων από τους πελάτες 20 30% Αύξηση ακρίβειας προβλέψεων 15 30% >> The processes in the individual work areas could be streamlined and shortened considerably. For example, processing time dropped drastically( ). In the Dealer Service Center (DSC), process costs dropped by 58 percent and staff requirement by 67 percent.>> Πηγή: IS Report, 7+8/2005, BMW Financial Services Switzerland project report on the use of ARIS 36

37 Τι είναι ροή εργασιών? Ως ροή εργασιών (workflow) ορίζεται η αυτοματοποίηση μιας επιχειρηματικής διαδικασίας, στο σύνολό της ή τμηματικά, κατά τη διάρκεια της οποίας έγγραφα, πληροφορία ή δραστηριότητες «περνάνε» από τον έναν εμπλεκόμενο στη διαδικασία σε άλλον για δράση (action) με βάση ένα σύνολο διαδικαστικών (επιχειρηματικών ή / και νομικών) κανόνων Τυπικό Παράδειγμα Ροής Εργασιών: το ποτάμι μέσω του οποίου μεταφέρεται η ροή της δουλειάς, το εμπόρευμα, από λιμάνι σε λιμάνι και αποκτά προστιθέμενη αξία. Η ροή εργασιών ορίζει τις λειτουργίες που πρέπει να γίνουν κατά τη διάρκεια του ταξιδιού, ανάμεσα στους διάφορους προορισμούς και τι πρέπει να γίνει εάν υπάρχει κακοκαιρία ή συναντήσουν οποιοδήποτε άλλο εμπόδιο. Διακρίνεται σε 2 τύπους: Activity-based, με έμφαση στη μοντελοποίηση της εργασίας που πρέπει να γίνει Communication-based, με έμφαση στις συσχετίσεις και τις επικοινωνίες ανάμεσα στους ανθρώπους που εμπλέκονται στη δουλειά 37

38 Εργαλεία Διαχείρισης Ροής Εργασιών Διαχείριση Ροών Εργασίας (Workflow Management): είναι ο αυτοματοποιημένος συντονισμός, έλεγχος και εκτέλεση διαδικασιών, που περιλαμβάνουν συνδυασμούς από δραστηριότητες, οι οποίες εκτελούνται από άνθρωπο ή από μηχανές και ειδικότερα εκείνες, που περιλαμβάνουν αλληλεπίδραση με εφαρμογές και εργαλεία πληροφορικής Τα Συστήματα Διαχείρισης Ροών Εργασιών (Workflow Management Systems) είναι πληροφοριακά συστήματα, τα οποία καθορίζουν, μοντελοποιούν, διαχειρίζονται και εκτελούν Ροές Εργασίας ενός οργανισμού (WFM Coalition) Οφέλη: Αυξάνεται η αποδοτικότητα και η τυποποίηση των διαδικασιών Βελτιώνεται η διαχείριση του ελέγχου Εργασίες ανατίθενται αποτελεσματικά στα στελέχη Παρέχεται η δυνατότητα εύκολου και γρήγορου ανασχεδιασμού διαδικασιών (Process reengineering) Διαφορά Εργαλείων Μοντελοποίησης Διαδικασιών από τα Εργαλεία Διαχείρισης Ροής Εργασιών?? 38

39 Η κλεψύδρα της Μοντελοποίησης Διαδικασιών Πηγή: Stephen A. White, Introduction to BPMN, ΙΒΜ Software Group 39

40 BPMN Business Process Management Notation Oρίστηκε αρχικά από το Business Process Management Initiative (BPMI) το 2004 και υιοθετήθηκε από το Object Management Group (OMG) το 2006 Παρέχει μια σημειογραφία (notation) που είναι εύκολα κατανοητή σε όλους τους χρήστες είτε: Δημιουργούν προσχέδια των διαδικασιών Υλοποιούν τις διαδικασίες Διαχειρίζονται τις διαδικασίες Παρέχει προχωρημένες δυνατότητες έκφρασης εννοιών όπως η διαχείριση εξαιρέσεων (exception handling), οι δοσοληψίες (transactions) και η εναλλακτική αποζημίωση / αναδρομή (compensation) Προσφέρει διασύνδεση και απεικόνιση των επιχειρηματικών μοντέλων σε γλώσσες εκτέλεσης των διαδικασιών, όπως η BPEL (Business Process Execution Language) 40

41 Business Process Execution Language (BPEL) Χρησιμοποιείται για την περιγραφή της ροής εργασιών των (εταιρικών) διαδικασιών που σχετίζονται με την οργάνωση των Web Services, και συνδέεται στενά με τη γλώσσα WSDL Προέκυψε από την πρωτοβουλία της IBM και της Microsoft να συνδυάσουν τη WSFL (Web Services Flow Language) και τη XLANG, που είχαν αναπτύξει αντίστοιχα, σε μια κοινή γλώσσα, τη BPEL4WS Το 2003 η έκδοση BPEL4WS 1.1 υποβλήθηκε στον OASIS για προτυποποίηση και προέκυψε η έκδοση WS-BPEL 2.0 Καθορίζει: την πιθανή σειρά εκτέλεσης των λειτουργιών ενός συνόλου Web services τα δεδομένα που ανταλλάσσονται μεταξύ των Web services ποιοί είναι οι συμμετέχοντες και πώς αυτοί εμπλέκονται στην επιχειρησιακή διαδικασία ένα κοινό χειρισμό των εξαιρέσεων (joint exception handling) για τα σύνολα των Web services Θέματα που αφορούν τα multiple services και τη συμμετοχή Οργανισμών Επιτρέπει τον καθορισμό των συναλλαγών με μεγάλη διάρκεια (long-running transactions) μεταξύ των Web services, αυξάνοντας τη συνέπεια και την αξιοπιστία των Web services Καθώς πρόκειται για μια executable process implementation language, ο ρόλος της BPEL είναι να ορίσει ένα νέο Web service συνθέτοντας υπάρχοντα services 41

42 Επισκόπηση της BPEL 42

43 Διαγράμματα Επιχειρησιακών Διαδικασιών στη BPMN Τα Διαγράμματα Επιχειρησιακών Διαδικασιών (Business Process Diagram - BPD) ουσιαστικά αναπαριστούν: τις δραστηριότητες της διαδικασίας, τους ελέγχους ροής που καθορίζουν την σειρά με την οποία εκτελούνται οι δραστηριότητες και ανταλλάσσονται τα δεδομένα, τους ρόλους που συμμετέχουν στη διαδικασία τα εμπλεκόμενα πληροφοριακά συστήματα τους επιχειρηματικούς κανόνες και το θεσμικό / νομικό πλαίσιο που διέπει τη διεξαγωγή της διαδικασίας 43

44 Είδη Διαγραμμάτων Επιχειρησιακών Διαδικασιών Μια διαδικασία ορίζεται μέσω των ακόλουθων όψεων: Εσωτερική Επιχειρηματική Διαδικασία (Private Business Process) Εξωτερική Δημόσια Επιχειρηματική Διαδικασία (Public Business Process) Συνεργατική Επιχειρηματική Διαδικασία (Collaboration Business Process) 44

45 Εσωτερική Επιχειρηματική Διαδικασία Απεικονίζει λεπτομερώς τις δραστηριότητες που συμβαίνουν μέσα στον Φορέα, τα οργανωτικά τμήματα που είναι αρμόδια για κάθε δραστηριότητα, τα πληροφοριακά συστήματα που υποστηρίζουν τις δραστηριότητες, τους επιχειρησιακούς νομικούς κανόνες τα έγγραφα που ανταλλάσσονται...κάθε εσωτερική διαδικασία μπορεί να αντιστοιχιστεί σε ένα εκτελέσιμο αρχείο BPEL. 45

46 Εξωτερική Δημόσια Επιχειρηματική Διαδικασία Επικεντρώνεται στην αναπαράσταση της επικοινωνίας και των αλληλεπιδράσεων ανάμεσα σε μια εσωτερική διαδικασία ενός Φορέα και άλλες διαδικασίες ή συμμετέχοντες Φορείς Δεν περιέχει λεπτομέρειες σχετικά με πληροφοριακά συστήματα, οργανωτικά ή επιχειρησιακάνομικά ζητήματα... Βοηθά στην αναγνώριση των διαδικτυακών υπηρεσιών (web services) που απαιτούνται για την ηλεκτρονική διεξαγωγή της διαδικασίας. 46

47 Συνεργατική Επιχειρηματική Διαδικασία Αναπαριστά τις αλληλεπιδράσεις ανάμεσα σε όλους τους φορείς που εμπλέκονται στη διαδικασία. Δεν μπαίνει σε λεπτομέρειες σχετικά με τη διεξαγωγή της διαδικασίας εσωτερικά σε κάθε εμπλεκόμενο φορέα Συντελεί στην αναγνώριση των διαδικτυακών υπηρεσιών (web services) που απαιτούνται για την ηλεκτρονική διεξαγωγή της διαδικασίας 47

48 Βασικές Έννοιες Μοντελοποίησης στη BPMN Δραστηριότητα Γεγονός Πύλη Σύνδεσμος 48

49 Κατηγορίες Συμβόλων της BPMN Αντικείμενα Ροής Αντικείμενα Σύνδεσης Swimlanes Συμπληρωματικά Αντικείμενα Γεγονός Ομαλή Ροή Pool Έγγραφα Δραστηριότητα Ροή Μηνυμάτων Lane Ομάδα Πύλη Σύνδεσμος Σχόλια 49

50 Δραστηριότητες (Tasks) Εργασία Απλή δραστηριότητα που εκτελείται στο πλαίσιο μιας υπηρεσίας Δεν μπορεί να αναλυθεί περαιτέρω Υποβολή Αίτησης Υποδιαδικασία Σύνθετη διαδικασία Μπορεί να αναλυθεί σε υπο-δραστηριότητες Πληρωμή Περιοδικού ΦΠΑ Επαναλαμβανόμενη διαδικασία Έλεγχος προϊόντος Βρόχος δραστηριοτήτων 50

51 Γεγονότα (Events) Γεγονός Αρχής Ένα Γεγονός Αρχής υποδεικνύει πότε θα ξεκινήσει μια συγκεκριμένη διαδικασία. Ενδιάμεσο Γεγονός Γεγονός Τέλους Ένα Ενδιάμεσο Γεγονός συμβαίνει ανάμεσα σε ένα Γεγονός Αρχής και ένα Γεγονός Τέλους: Επηρεάζει τη ροή της διαδικασίας, αλλά δεν ξεκινάει ή (απευθείας) τελειώνει τη διαδικασία. Ένα Γεγονός Τέλους υποδεικνύει πότε θα ολοκληρωθεί μια συγκεκριμένη διαδικασία. 51

52 Τύποι Γεγονότων Αρχής Χωρίς τύπο Μήνυμα Χρονιστής Κανόνας Σύνδεσμος Πολλαπλής Φύσεως Ο τύπος του γεγονότος δεν εμφανίζεται ή δεν είναι γνωστός Ένα μήνυμα φτάνει από κάποιο εμπλεκόμενο στη διαδικασία Φορέα και πυροδοτεί την έναρξη της διαδικασίας. Μια συγκεκριμένη ημερομηνία (ή / και ώρα) ή ένας συγκεκριμένος κύκλος πυροδοτούν την έναρξη της διαδικασίας. Η έναρξη του γεγονότος πραγματοποιείται μόλις ικανοποιηθούν οι συνθήκες που επιβάλλει κάποιος κανόνας ή νόμος Η έναρξη μιας διαδικασίας πυροδοτείται με το τέλος (αποτέλεσμα) μιας άλλης Υπάρχει η δυνατότητα έναρξης της διαδικασίας με πολλαπλούς εναλλακτικούς τρόπους, αλλά μόνο ένας τελικά θα πυροδοτήσει την έναρξη της 52

53 Τύποι Ενδιάμεσων Γεγονότων (1) Χωρίς τύπο Δείχνει κάποια αλλαγή κατάστασης στη διαδικασία Μήνυμα Ένα μήνυμα φτάνει από κάποιο εμπλεκόμενο στη διαδικασία και προκαλεί τη συνέχιση της διαδικασίας εάν περίμενε για το μήνυμα ή αλλάζει τη ροή της για χειρισμό εξαίρεσης. Χρονιστής Συνήθως, λειτουργεί σαν μηχανισμός καθυστέρησης. Μια συγκεκριμένη ημερομηνία ή ένας συγκεκριμένος κύκλος (π.χ. κάθε Δευτέρα στις 9π.μ.) πυροδοτούν το γεγονός. Κανόνας Χρησιμοποιείται μόνο για το χειρισμό εξαιρέσεων και προκαλείται όταν η συνθήκη κάποιου κανόνα γίνει αληθής. 53

54 Τύποι Ενδιάμεσων Γεγονότων (2) Αναδρομή Σύνδεσμος Πολλαπλής Φύσεως Σφάλμα Χρησιμοποιείται για το χειρισμό της αναδρομής και για να δημιουργήσει και να εκτελέσει την αναδρομή. Συνδέει το τέλος (αποτέλεσμα) μιας διαδικασίας με ένα ενδιάμεσο γεγονός μιας άλλης. Απεικονίζει την ύπαρξη πολλαπλών εναλλακτικών τρόπων, από τους οποίους μόνο ένας τελικά θα πυροδοτήσει το γεγονός Χρησιμοποιείται για το χειρισμό σφαλμάτων: για να προκαλέσει (throw) και να αντιμετωπίσει (catch) σφάλματα. 54

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

56 Αποκλειστικό Ή Τύποι Πυλών (Gateways) ή Βασισμένο σε Συνθήκες Η υποθετική συνθήκη που ικανοποιείται καθορίζει ποια εναλλακτική διαδρομή θα ακολουθηθεί. Κάθε υποθετική συνθήκη οδηγεί σε μια εναλλακτική διαδρομή. Ή Βασισμένο σε Γεγονότα Το γεγονός που συμβαίνει σε εκείνο το σημείο της διαδικασίας καθορίζει ποια εναλλακτική διαδρομή θα ακολουθηθεί. Σε διασταύρωση, η ροή του ελέγχου μπορεί να ακολουθήσει μια ή περισσότερες εναλλακτικές διαδρομές. Σε ένωση, συνδυάζει 2 ή περισσ. παράλληλες εισερχόμενες διαδρομές σε μια εξερχόμενη ροή. Σύνθετος ΚΑΙ Απεικονίζει σύνθετες συνθήκες (π.χ. απεικόνιση 3 εισερχόμενων ροών και 5 εξερχόμενων) Σε διασταύρωση, οι εξερχόμενες δραστηριότητες εκτελούνται συγχρόνως. Σε ένωση, συνδυάζει 2 ή περισσ παράλληλες εισερχόμενες διαδρομές σε μια εξερχόμενη ροή. 56

57 UML Unified Modelling Language Αποτελεί μια οπτική (visual) γλώσσα μοντελοποίησης με εκφραστικές δυνατότητες για την απεικόνιση, την προδιαγραφή, την τεκμηρίωση και την κατασκευή των προϊόντων της διαδικασίας ανάπτυξης συστημάτων Στην UML στηρίζονται πολλές νέες μεθοδολογίες ανάπτυξης λογισμικού, όπως η RUP (Rational Unified Process), αλλά και οι: Abstraction Method και Dynamic Systems Development Method Κατατάσσεται στις αντικειμενοστρεφείς γλώσσες μοντελοποίησης Θεμελιώδεις έννοιες στην UML είναι ο δράστης (actor), η ιδιότητα (attribute), η κλάση (class), η διεπαφή (interface), το αντικείμενο (object), η δραστηριότητα (activity), το γεγονός (event), το μήνυμα (message), η κατάσταση (state), η περίπτωση χρήσης (use case), η συσχέτιση (association), η σύνθεση (composition), η εξάρτηση (depends), η γενίκευση (generalization) ή η κληρονομιά (inheritance), η πολυπλοκότητα (multiplicity) και ο ρόλος (role) Αναπτύχθηκε από το Object Management Group (OMG) το 1997 και σήμερα βρίσκεται στην έκδοση 2.0 (Αύγουστος 2005) 57

58 Διαγράμματα της UML Διαθέτει 13 τύπους διαγραμμάτων, οι οποίοι διαχωρίζονται σε 3 κατηγορίες: Δομικά Διαγράμματα, τα οποία δίνουν έμφαση στα δομικά μέρη που απαρτίζουν το σύστημα που μοντελοποιείται: Διάγραμμα Κλάσεων, Διάγραμμα Αντικειμένων, Παραταξιακό Διάγραμμα, Διάγραμμα Συνιστωσών, Διάγραμμα Σύνθετης Δομής, Διάγραμμα Πακέτου Διαγράμματα Συμπεριφοράς, που απεικονίζουν την εσωτερική συμπεριφορά του συστήματος και περιέχουν τα εξής: Διάγραμμα Δραστηριοτήτων, Διάγραμμα Περιπτώσεων Χρήσης, Διάγραμμα Καταστάσεων Διαγράμματα αλληλεπίδρασης που αναπαριστούν τη ροή ελέγχου και δεδομένων μέσω των διαγραμμάτων: Ακολουθιακό Διάγραμμα, Συνεργατικό Διάγραμμα (UML 1.x) / Διάγραμμα Επικοινωνίας (UML 2.0), Διάγραμμα Επισκόπησης της Αλληλεπίδρασης (UML 2.0), Διάγραμμα Συγχρονισμού (UML 2.0) 58

59 Παραδείγματα UML Διαγραμμάτων Διάγραμμα Περιπτώσεων Χρήσης Ακολουθιακό Διάγραμμα Διάγραμμα Κλάσεων Παραταξιακό Διάγραμμα Διάγραμμα Καταστάσεων Διάγραμμα Δραστηριοτήτων 59

60 Ανταλλαγή Μοντέλων: Πώς? Ειδικοί Adaptors που διασυνδέουν τα Εργαλεία Με τη βοήθεια προτύπων, όπως: XML Metadata Interchange (XMI): Αποτελεί πρόταση του OMG (Version 2.1 Δεκέμβρης 2007) για την ανταλλαγή UML Μοντέλων. Ενοποιεί τα πρότυπα UML, XML, MOF (Meta Object Facility). Μετατρέπει τα μοντέλα σε XML, π.χ. τα UML Διαγράμματα Κλάσεων σε XML Schemas Model Driven Architecture (MDA): Αναπτύχθηκε από τον OMG το Αποτελεί μια προσέγγιση στην προδιαγραφή IT συστημάτων που διαχωρίζει την προδιαγραφή της λειτουργικότητας ενός συστήματος από την προδιαγραφή της υλοποίησης αυτής της λειτουργικότητας σε συγκεκριμένη πλατφόρμα. Design once, build it on any platform Πηγή: 60

61 Μοντελοποίηση Διαδικασιών στο ΠΗΔ 2

62 Βασικές Αρχές Μοντελοποίησης Υπηρεσιών Συμμόρφωση με τα πρότυπα BPMN (Business Process Modeling Notation) και UML (Unified Modelling Language) Συνέπεια των μοντέλων με τον σκοπό για τον οποίο προορίζονται Απεικόνιση της υπάρχουσας κατάστασης (as-is situation) και ανάδειξη των σημείων που χρειάζονται βελτιώσεις Μοναδικότητα έκφρασης της πληροφορίας Διατηρησιμότητα και ευκολία διαχείρισης των μοντέλων Δυνατότητα αξιοποίησης των μοντέλων κατά το χρόνο εκτέλεσης των υπηρεσιών Ανεξαρτησία από εργαλεία Σχέση με υπάρχοντα μοντέλα 62

63 Φάση Δ Φάση Γ Φάση Β Φάση Α Μεθοδολογία Μοντελοποίησης Υπηρεσιών Καθορισμός Λίστας Υπηρεσιών προς Μοντελοποίηση Δημιουργία Προτεραιοτήτων ανάμεσα στις Υπηρεσίες Συγκέντρωση και Αξιολόγηση Πληροφοριών Ανάδειξη προβληματικών σημείων της υπηρεσίας Καταγραφή Μεταδεδομένων Υπηρεσιών Επικύρωση-Συμπλήρωση Πληροφοριών Σχεδίαση Μοντέλων BPMN των Υπηρεσιών Επαλήθευση ΒΡΜΝ Μοντέλων Συντήρηση Διαγραμμάτων και Μοντέλων των Υπηρεσιών 63

64 Τι σημαίνει για ένα Δημόσιο Φορέα η Μοντελοποίηση Διαδικασιών με βάση το Πλαίσιο? KY.3 Οι υπηρεσίες που προσφέρουν οι Δημόσιοι Φορείς ΠΡΕΠΕΙ ΝΑ: Καταχωρούνται στο Ληξιαρχείο Διαλειτουργικότητας με βάση τα μεταδεδομένα του Μοντέλου Τεκμηρίωσης Εναλλακτικά: Απεικονίζονται σε Διάγραμμα της Συνεργατικής Όψης, το οποίο, όμως, να περιλαμβάνει τις απαραίτητες για τη ροή λεπτομέρειες που παρέχει ένα Διάγραμμα Εσωτερικής Όψης για κάθε Φορέα KY.4 KY.5 Τα μεταδεδομένα περιγραφής μιας υπηρεσίας ΘΑ ΠΡΕΠΕΙ να παραδίδονται ως RDF ή Excel αρχεία. Η διαγραμματική απεικόνιση μιας υπηρεσίας ΠΡΕΠΕΙ ΝΑ παραδίδεται ως αρχείο XMI ή στη μορφή που εξάγεται από το modeling tool που χρησιμοποιείται ή ως εκτελέσιμος κώδικας στη γλώσσα εκτέλεσης διαδικασιών BPEL, εκτός από εικόνα (jpeg, bitmap, etc.). 64

65 Μεταδεδομένα Καταγραφής Υπηρεσίας (Ι) ΓΕΝΙΚΑ ΣΤΟΙΧΕΙΑ ΥΠΗΡΕΣΙΑΣ Κωδικός Υπηρεσίας Τίτλος Υπηρεσίας Υπεύθυνος Δημόσιος Φορέας Εμπλεκόμενοι Φορείς Τελική Υπηρεσία Αποδέκτης Υπηρεσίας Τύπος Υπηρεσίας Κατηγορία Υπηρεσίας Το μοναδικό αναγνωριστικό της υπηρεσίας Το όνομα της υπηρεσίας Η Διεύθυνση ή Υπηρεσία του Φορέα που είναι υπεύθυνη για την διεξαγωγή της υπηρεσίας Οι φορείς που εμπλέκονται κατά τη διεξαγωγή της υπηρεσίας Εάν η υπηρεσία είναι τελική (one stop) ή όχι Ο τελικός αποδέκτης της υπηρεσίας, π.χ. Πολίτες / Επιχειρήσεις / Δημόσιοι Φορείς Ο τύπος στο οποίο εντάσσεται η υπηρεσία (π.χ. Άδεια / Πιστοποιητικό / Βεβαίωση / Πληρωμή)) Η κατηγορία στην οποία εντάσσεται η υπηρεσία με βάση τη Λίστα Κυβερνητικών Υπηρεσιών του ΠΠ- ΔΔΤ (π.χ. Άνθρωποι, Κοιν. & Διαβίωση/Οικογένεια) 65

66 Μεταδεδομένα Καταγραφής Υπηρεσίας (ΙΙ) ΓΕΝΙΚΑ ΣΤΟΙΧΕΙΑ ΥΠΗΡΕΣΙΑΣ Επεισόδιο Ζωής Επιχειρησιακό Γεγονός Είναι Πρότυπη Υπηρεσία Βασίζεται στην Πρότυπη Υπηρεσία Νομικό Πλαίσιο Το επεισόδιο ζωής στο οποίο ανήκει η υπηρεσία (π.χ. Γέννηση, Γάμος) Το επιχειρησιακό γεγονός στο οποίο ανήκει η υπηρεσία (π.χ. Ξεκινάω νέα Επιχείρηση) Εάν πρόκειται για πρότυπη υπηρεσία ή όχι, π.χ. εάν αφορά όλους τους Δήμους ή έναν συγκεκριμένο Δήμο Η πρότυπη υπηρεσία στην οποία στηρίζεται Το νομικό πλαίσιο που διέπει τη διεξαγωγή της υπηρεσίας 66

67 Μεταδεδομένα Καταγραφής Υπηρεσίας (ΙΙΙ) ΣΤΟΙΧΕΙΑ ΣΥΜΒΑΤΙΚΟΥ ΤΡΟΠΟΥ ΔΙΕΚΠΕΡΑΙΩΣΗΣ ΥΠΗΡΕΣΙΑΣ Απαίτηση για φυσική παρουσία κατά την κατάθεση της αίτησης Απαίτηση για φυσική παρουσία κατά την παραλαβή της διοικητικής πράξης Μέθοδος Πιστοποίησης Εάν η υπηρεσία απαιτεί τη φυσική παρουσία του αποδέκτη της κατά την κατάθεση της αίτησης Εάν η υπηρεσία απαιτεί τη φυσική παρουσία του αποδέκτη της κατά την παραλαβή της διοικητικής πράξης Η μέθοδος που απαιτείται για την πιστοποίηση του αποδέκτη της υπηρεσίας, π.χ. αντίγραφο αστυνομικής ταυτότητας 67

68 Μεταδεδομένα Καταγραφής Υπηρεσίας (ΙV) ΣΤΟΙΧΕΙΑ ΗΛΕΚΤΡΟΝΙΚΗΣ ΔΙΑΘΕΣΙΜΟΤΗΤΑΣ ΥΠΗΡΕΣΙΑΣ Ιστοσελίδα Τρόπος παροχής υπηρεσίας Τρέχον Επίπεδο Ηλεκτρονικοποίησης Πολυγλωσσικό Περιεχόμενο Δυνατότητα offline λειτουργίας Δυνατότητα αποστολής XML αρχείου Δυνατότητα επισκόπησης προόδου υπηρεσίας Μέθοδος Πιστοποίησης Ιστοσελίδα στην οποία παρέχεται ηλεκτρονικά η υπηρ. Εάν η υπηρεσία παρέχεται μέσω Internet Browser, SMS, web service, κλπ Το τρέχον επίπεδο ηλεκτρονικοποίησης (1-5) εφόσον η υπηρεσία παρέχεται ηλεκτρονικά Εάν η υπηρ. προσφέρει πολυγλωσσικό περιεχόμενο Εάν υπάρχει η δυνατότητα συμπλήρωσης των πεδίων μιας φόρμας της υπηρεσίας offline Εάν υπάρχει η δυνατότητα αποστολής ενός XML αρχείου στην υπηρεσία αντί για συμπλήρωση κάποιας φόρμας Εάν υπάρχει η δυνατότητα παρακολούθησης της προόδου (status) της υπηρεσίας Μέθοδος που χρησιμοποιείται για την πιστοποίηση των χρηστών της υπηρεσίας 68

69 Μεταδεδομένα Καταγραφής Υπηρεσίας (V) ΣΤΟΙΧΕΙΑ ΣΗΜΑΝΤΙΚΟΤΗΤΑΣ ΥΠΗΡΕΣΙΑΣ Συχνότητα Σημαντικότητα με βάση Ευρωπαϊκές Πολιτικές Αριθμός συναλλαγών της υπηρεσίας ανά έτος Αν σχετίζεται ή όχι η υπηρεσία με ευρωπαϊκές πολιτικές και κατευθύνσεις ΣΤΟΙΧΕΙΑ ΚΑΤΑΓΡΑΦΗΣ ΥΠΗΡΕΣΙΑΣ Πηγή πληροφοριών Ημερομηνία τελευταίας ενημέρωσης πληροφοριών Κατάσταση Περιγραφής Στοιχείων Η πηγή άντλησης των στοιχείων Η ημερομηνία τελευταίας ενημέρωσης των μεταδεδομένων της υπηρεσίας Η κατάσταση στην οποία βρίσκονται τα στοιχεία, π.χ. ημιτελής ή τελικη 69

70 Επιπλέον Μεταδεδομένα Καταγραφής Υπηρεσίας Εμπλεκόμενοι Φορείς - Ρόλοι: Λίστα των εμπλεκόμενων Φορέων, Οργανικών Τμημάτων και Ρόλων που εμπλέκονται στη διαδικασία Γεγονός εκκίνησης υπηρεσίας: Ο τρόπος έναρξης της υπηρεσίας Βήματα Διαδικασίας: Αναλυτική περιγραφή του βήματος που εκτελείται, του τρόπου μετάβασης σε αυτό, εάν απαιτείται (π.χ. εάν πρόκειται για κόμβο απόφασης) και του αρμόδιου Οργανωτικού Τμήματος και Ρόλου που εκτελεί το συγκεκριμένο βήμα. Γεγονός τερματισμού υπηρεσίας: Ο τρόπος τερματισμού της υπηρεσίας Πίνακας Δικαιολογητικών: Λίστα των δικαιολογητικών που απαιτούνται. Καταγράφονται τα ακόλουθα: Τίτλος και Κωδικός Δικαιολογητικού, Εάν το δικαιολογητικό αντικαθιστά κάποιο άλλο, Εάν μπορεί να αναζητηθεί υπηρεσιακά Πίνακας Εγγράφων: Λίστα των εισερχόμενων, εξερχόμενων και ενδιάμεσων εγγράφων που απαιτούνται για τη διεκπεραίωση της διαδικασίας. Καταγράφονται τα ακόλουθα: Τίτλος και Κωδικός Εγγράφου, Βήμα Διαδικασίας στο οποίο εμπλέκεται και ένδειξη της κατάστασής τους (π.χ. σχέδιο, εγκεκριμένο, κλπ.), εάν πρόκειται για ενδιάμεσο έγγραφο. Πληροφοριακά συστήματα που τυχόν υπάρχουν και υποστηρίζουν την υπηρεσία με αναφορά στο βήμα στο οποίο εμπλέκονται Διαδικτυακές υπηρεσίες που τυχόν υπάρχουν και υποστηρίζουν την ηλεκτρονική επικοινωνία με εξωτερικούς φορείς με αναφορά στο βήμα της διαδικασίας στο οποίο εμπλέκονται Εναλλακτικές Διαδικασίες: Τυχόν εναλλακτικές διαδικασίες που αφορούν την ίδια υπηρεσία. 70

71 Καταγραφή Μεταδεδομένων Υπηρεσιών DEMO στο Ληξιαρχείο Διαλειτουργικότητας 71

72 Συμμόρφωση με τη ΒPMN KY.8 KΠ.1 KY.3 Η συμμόρφωση με τη σημειογραφία των προτύπων μοντελοποίησης διαδικασιών (BPMN και UML) ΠΡΕΠΕΙ ΝΑ γίνεται σε δύο άξονες: Στην οπτική εμφάνιση των στοιχείων μοντελοποίησης Στη σημασιολογία και το ρόλο που έχει κάθε στοιχείο μοντελοποίησης Μια διαδικασία ΣΥΝΙΣΤΑΤΑΙ ΝΑ ορίζεται μέσω των ακόλουθων όψεων: Εσωτερική Επιχειρηματική Διαδικασία (Private Business Process) Εξωτερική Δημόσια Επιχειρηματική Διαδικασία (Public Business Process) Συνεργατική Επιχειρηματική Διαδικασία (Collaboration Business Process) Οι υπηρεσίες που προσφέρουν οι Δημόσιοι Φορείς ΠΡΕΠΕΙ ΝΑ απεικονίζονται... Διάγραμμα της Συνεργατικής Όψης, το οποίο, όμως, να περιλαμβάνει τις απαραίτητες για τη ροή λεπτομέρειες που παρέχει ένα Διάγραμμα Εσωτερικής Όψης για κάθε Φορέα. 72

73 Συμβάσεις Ονοματολογίας και Απεικόνισης KY.9 KM.2 KY.10 KY.11 KY.12 Όλα τα ονόματα και οι περιγραφές ΠΡΕΠΕΙ ΝΑ συνίστανται από λέξεις στην ελληνική γλώσσα. Το περιεχόμενο των μεταδεδομένων περιγραφής υπηρεσιών ΜΕΛΕΤΑΤΑΙ ΝΑ διατυπώνεται και στην αγγλική γλώσσα, πλέον της ελληνικής Τα ονόματα των στοιχείων μοντελοποίησης ΔΕΝ ΠΡΕΠΕΙ ΝΑ περιέχουν ακρωνύμια και συντομεύσεις. Η σημειολογία ΔΥΝΑΤΑΙ ΝΑ επεκταθεί από κάθε σχεδιαστή με γραφικά αντικείμενα εννοιών που δεν συμπεριλαμβάνονται στο παρόν Μοντέλο Τεκμηρίωσης και θα θεωρούνται ως συμπληρωματικά αντικείμενα (artifacts). Τα νέα αντικείμενα ωστόσο ΔΕΝ ΠΡΕΠΕΙ ΝΑ συγκρούονται με τα υπάρχοντα αντικείμενα, δηλαδή: να μοντελοποιούν με διαφορετικό τρόπο την ίδια έννοια να μοντελοποιούν με τον ίδιο τρόπο διαφορετικές έννοιες και ΘΑ ΠΡΕΠΕΙ ΝΑ έχουν περάσει επιτυχώς από τη Διαδικασία Έγκρισης και Ενσωμάτωσης στο Ληξιαρχείο προτού χρησιμοποιηθούν. Οι βασικές έννοιες μοντελοποίησης (Γεγονότα, Δραστηριότητες, Πύλες, Ροή και Ροή Μηνυμάτων) ΔΕΝ ΠΡΕΠΕΙ ΝΑ τροποποιούνται με οποιοδήποτε τρόπο. 73

74 Βασικές Αρχές Σχεδιασμού (1/2) KY.13 KY.14 KY.18 KY.15 KY.17 ΘΑ ΠΡΕΠΕΙ ΝΑ χρησιμοποιείται μόνο ένα Γεγονός Έναρξης και ένα Γεγονός Τέλους για κάθε εναλλακτική ροή κάθε εμπλεκόμενου στη διαδικασία. Η κατεύθυνση των διαγραμμάτων ΘΑ ΠΡΕΠΕΙ ΝΑ είναι πάντα από πάνω προς τα κάτω ή από αριστερά προς τα δεξιά με εξαίρεση τους βρόχους που ενδέχεται να πηγαίνουν αντίθετα. Οι Φορείς και τα Οργανωτικά Τμήματα που εμπλέκονται στη διαδικασία ΠΡΕΠΕΙ ΝΑ εμφανίζονται ευκρινώς ως swimlanes στα διαγράμματα, ενώ τα έγγραφα που ανταλλάσσονται ΠΡΕΠΕΙ ΝΑ τοποθετούνται σε κενό διάστημα ανάμεσα στα swimlanes των εμπλεκόμενων Φορέων. Η βασική ροή μιας διαδικασίας ΠΡΕΠΕΙ ΝΑ μοντελοποιείται με ευθεία γραμμή (σύμβολο Ομαλής Ροής). Για την ευκρίνεια των διαγραμμάτων, ΘΑ ΠΡΕΠΕΙ ΝΑ καταβάλλεται κάθε δυνατή προσπάθεια ώστε οι σύνδεσμοι να μην διασταυρώνονται μεταξύ τους. 74

75 Βασικές Αρχές Σχεδιασμού (2/2) KΠ.3 Πριν από κάθε κόμβο απόφασης ΣΥΝΙΣΤΑΤΑΙ ΝΑ προηγείται μια δραστηριότητα που εν μέρει περιγράφει τη διαδικασία απόφασης. Επομένως, μια απόφαση ΔΕΝ ΠΡΟΤΕΙΝΕΤΑΙ ΝΑ τοποθετείται αμέσως μετά το γεγονός έναρξης της διαδικασίας. KΠ.4 Σχολιασμός κειμένου ΠΡΟΑΙΡΕΤΙΚΑ χρησιμοποιείται για να παρέχει λεπτομέρειες για τη διαδικασία ή τις ιδιότητες των αντικειμένων που εμφανίζονται. ΣΥΝΙΣΤΑΤΑΙ ΝΑ χρησιμοποιείται για την καταγραφή πρόσθετων πληροφοριών, π.χ. του νομικού πλαισίου και των πληροφοριακών συστημάτων στο βήμα της διαδικασίας με το οποίο αυτά σχετίζονται. KΠ.5 Τα Αντικείμενα Ροής και η Ροή ΠΡΟΑΙΡΕΤΙΚΑ έχουν «ετικέτες» με το όνομά τους και/ ή άλλα χαρακτηριστικά που τοποθετούνται εντός, πάνω ή κάτω από το σχήμα σε οποιαδήποτε κατεύθυνση. 75

76 Διαχείριση Εκδόσεων των Μοντέλων Υπηρεσιών KY.19 Τα Μοντέλα Διαδικασιών ΠΡΕΠΕΙ ΝΑ υποδεικνύουν την πλήρη έκδοσή τους στο όνομα του αρχείου ως <Κωδικός Υπηρεσίας> <Όνομα Υπηρεσίας>-vn-m όπου n και m είναι η μείζονα και η δευτερεύουσα έκδοση, αντίστοιχα και v είναι ο λατινικός χαρακτήρας v. Μια νέα μείζονα έκδοση δημιουργείται όταν συμβαίνουν αξιοσημείωτες και / ή μη συμβατές προς τα πίσω αλλαγές, όπως ολικός ανασχεδιασμός της διαδικασίας που περιλαμβάνει: Διαγραφή ή τροποποίηση δραστηριοτήτων Αλλαγή των τύπων των γεγονότων Τροποποίηση των κόμβων αποφάσεων και των πυλών που χρησιμοποιούνται Σε μια δευτερεύουσα έκδοση ενός Μοντέλου Διαδικασιών περιέχεται μια σειρά από μικρές ή συμβατές προς τα πίσω αλλαγές, όπως απαλοιφή ή προσθήκη εναλλακτικών διαδρομών 76

77 Δημιουργία Μοντέλων Υπηρεσιών DEMO στο ADONIS 77

78 Πώς διασφαλίζεται η συμβατότητα προς τα πίσω? KY.6 Εναλλακτικά, η απεικόνιση, η προδιαγραφή και η τεκμηρίωση των διαδικασιών του Δημόσιου Τομέα μπορεί να πραγματοποιείται με βάση το πρότυπο UML (Unified Modelling Language), όπως έχει οριστεί από το Object Management Group (OMG). Σε αυτήν την περίπτωση, ΠΡΕΠΕΙ ΝΑ χρησιμοποιείται το Διάγραμμα Δραστηριοτήτων (Activity Diagram). 78

79 Βασικές Αρχές Ανασχεδιασμού Επιχειρηματικών Διαδικασιών 3

80 Ορισμός Ανασχεδιασμού Επιχειρηματικών Διαδικασιών (BPR) Ορίζεται ως η ριζική αναθεώρηση και ο ανασχεδιασμός των επιχειρηματικών διαδικασιών για να επιτευχθούν δραστικές βελτιώσεις σε καίριους, τρέχοντες δείκτες απόδοσης, όπως το κόστος, η ποιότητα, η εξυπηρέτηση και η ταχύτητα (Hammer & Champy, 1993) Περικλείει τον οραματισμό νέων στρατηγικών εργασίας, τον σχεδιασμό πραγματικών δραστηριοτήτων και την υλοποίηση της αλλαγής σε όλες τις πολύπλοκες τεχνολογικές, ανθρώπινες και οργανωτικές διαστάσεις της (Thomas H. Davenport, 1993) Σε σχέση με τις μεθοδολογίες Διαχείρισης Ολικής Ποιότητας και Just-in-time, ο Ανασχεδιασμός αναζητά περισσότερο ριζικές παρά διαρκείς βελτιώσεις... (Johansson et al., 1993) 80

81 Φράσεις για τον Ανασχεδιασμό Επιχειρηματικών Διαδικασιών Για να βελτιώνεσαι πρέπει να αλλάζεις; Για να είσαι τέλειος πρέπει να αλλάζεις συχνά. -- Winston Churchill Τα ανώτερα διοικητικά στελέχη... πρέπει να εγκαταλείψουν τις (οργανωτικές και λειτουργικές) αρχές και διαδικασίες που χρησιμοποιούν σήμερα και να δημιουργήσουν εντελώς νέες... Ο ανασχεδιασμός ενός οργανισμού σημαίνει ξεκινάω από την αρχή, από το μηδέν... Σημαίνει ότι ξεχνάμε πώς έτρεχαν παλιά οι διαδικασίες... Παλιοί τίτλοι εργασίας και οργανωτικές διευθετήσεις παύουν να υφίστανται... Ο ανασχεδιασμός... δεν μπορεί να υλοποιηθεί με μικρά και προσεκτικά βήματα είναι όλα ή τίποτα." Reengineering the Corporation (quotes gathered by Paul Strassmann in The Hocus-Pocus of Reengineering, 1994) Σήμερα οι οργανισμοί πρέπει να αναζητούν όχι κλασματικά, αλλά πολλαπλασιαστικά επίπεδα βελτίωσης 10x αντί για 10%. Thomas H. Davenport,

82 Ανασχεδιασμός vs. Απλοποίηση Διαδικασιών Απλοποίηση Διαδικασιών Σταδιακή Αλλαγή Καθορίζεται από τη Διαδικασία Απλοποιεί υπάρχουσα Διαδικασία Προϋποθέτει την αποδοχή Καθοδηγείται από τη Διοίκηση Σύντομη, μπορεί να τρέχει ταυτόχρονα σε πολλά έργα Μικρή επένδυση Ανασχεδιασμός Διαδικασιών Ριζικός Μετασχηματισμός Καθορίζεται από Όραμα Αναδομεί πλήρως όλες τις Διαδικασίες Αλλάζει τις στάσεις και τις συμπεριφορές Καθοδηγείται από τον Διευθυντή Χρονοβόρος, τρέχει σε περιορισμένο αριθμό έργων Μεγάλη επένδυση Source Coulson-Thomas,

83 Τι είναι τελικά ο Ανασχεδιασμός? Ο Ανασχεδιασμός αναφέρεται σε: Μια νέα αρχή Η αποποίηση εικασιών και θέσεων του παρελθόντος Η αναζήτηση για νέα επιχειρηματικά μοντέλα (Επιχειρήσεις) Η εφεύρεση νέων τρόπων εργασίας Ο Ανασχεδιασμός ΔΕΝ αναφέρεται απλά σε: Αυτοματοποίηση Ανασχεδιασμό λογισμικού Αναδιοργάνωση τμημάτων, λειτουργιών Διοίκηση ποιότητας Περιορισμό μεγέθους (Downsizing) Outsourcing 83

84 Διαμάντι Leavitt: Οι όψεις του BPR ΤΕΧΝΟΛΟΓΙΑ Αρωγός στην αλλαγή ΟΧΙ καθοδηγητής Enabler για ένα νέο οργανισμό, όχι για νέες διαδικασίες Κατανεμημένα Συστήματα με βάση τον πολίτη Διαμοίραση γνώσης ΣΤΡΑΤΗΓΙΚΗ Αναδιαμόρφωση Προσαρμογή στις ανάγκες του περιβάλλοντος Παροχή κινήτρων Ενιαία κουλτούρα ΔΙΑΔΙΚΑΣΙΕΣ Απλοποίηση Κατάργηση Έμφαση στις ανάγκες του πολίτη ΔΕΙΚΤΕΣ ΑΞΙΟΛΟΓΗΣΗΣ Σε σχέση με: Οικονομικά Πολίτες Διαδικασίες Καινοτομία / Γνώση ΑΝΘΡΩΠΙΝΟ ΔΥΝΑΜΙΚΟ Αλλαγή Στάσεων Ισοπέδωση ιεραρχιών Περισσότερες ευθύνες Νέες ειδικότητες Εκπαίδευση Source: Omar A. El Sawy, Redesigning Enterprise Processes for ebusiness, McGraw-Hill 84

85 Η Εξέλιξη του Ανασχεδιασμού Επιχειρηματικών Διαδικασιών Βαθμός αξιοποίησης ΤΠΕ Ηλεκτρονικό Επιχειρείν Διαχείριση Γνώσης Ανασχεδιασμός 1 Διοίκηση ης Γενιάς Ολικής Ποιότητας Ανταγωνισμός με βάση το χρόνο Ανασχεδιασμός 2 ης Γενιάς Βάθος Μετασχηματισμού στον οργανισμό Source: Omar A. El Sawy, Redesigning Enterprise Processes for ebusiness, McGraw-Hill 85

86 Στόχοι του Ανασχεδιασμού Διαδικασιών Διοικητική απλούστευση / Απλοποίηση διαδικασιών Αποτελεσματικός έλεγχος του κόστους/ Μείωση λειτουργικού κόστους και δαπανών Αύξηση της ποιότητας των παρεχόμενων υπηρεσιών Καλύτερη εξυπηρέτηση των πολιτών Μεγαλύτερη ταχύτητα διεκπεραίωσης υποθέσεων Ενοποίηση της στρατηγικής και ομοιομορφία διαδικασιών σε οργανισμούς που παρέχουν ίδιες υπηρεσίες Περισσότερη ευελιξία Μεγαλύτερη αποτελεσματικότητα στον οργανισμό Δυνατότητα επιτυχούς αντίδρασης στις αλλαγές του περιβάλλοντος 86

87 Ανασχεδιασμός Διαδικασιών: Γιατί? Οι πολίτες: Γίνονται πιο απαιτητικοί Έχουν κυμαινόμενες ανάγκες Ζητάνε προσωποποιημένες υπηρεσίες Το «περιβάλλον» εξελίσσεται διαρκώς σε παγκόσμιο και τοπικό επίπεδο Με την πρόοδο των υπολογιστών, η ανάγκη για αλλαγή γίνεται επιτακτική Εφαρμόζεται ο λεγόμενος «κανόνας» των 3 C s: Customers/Citizens take charge Competition intensifies Change becomes constant 87

88 Λόγοι που επιβάλλουν τον Ανασχεδιασμό Παρελθόν 1990 s Μέλλον Παρελθόν 1990 s Μέλλον Ιεραρχική Δομή εξουσίας Τοπική Αυτονομία Προτεραιότητα στις ανάγκες του πολίτη Κεντρικοποιημένο σύστημα διοίκησης Δίκτυα αξίας, κατανεμημένοι οργανισμοί Υπηρεσία Πολίτης Αρωγός η τεχνολογία και τα πληροφοριακά συστήματα 88

89 Ανασχεδιασμός Διαδικασιών: Τι τον εμποδίζει? Ο φόβος της αποτυχίας, π.χ. μελέτες αποδεικνύουν ότι κυμαίνεται από 70 % (Murphy 1994, Malhotra 1998) έως 50 % (Caron et al. 1994) Έλλειψη υποστήριξης και ενθουσιασμού από τη διοίκηση και χαμηλή αποδοχή στον οργανισμό Υπερβολικές προσδοκίες για οφέλη από τον Ανασχεδιασμό και η αδυναμία να εκπληρωθούν (βλ. παράδειγμα του Clarence με τον βάτραχό του Felix) Στήριξη αποκλειστικά σε τεχνολογικές λύσεις Υποτίμηση της αντίστασης για αλλαγή μέσα στον οργανισμό Εφησυχασμός που πηγάζει από την ενδεχόμενη καλή πορεία ενός οργανισμού Υλοποίηση καλών πρακτικών που δεν ταιριάζουν στις ανάγκες του οργανισμού Αντιμετώπιση ως ένα αυτοτελές έργο με περιορισμένες μακροπρόθεσμα προοπτικές Κακή διαχείριση έργου 89

90 Πλέγμα Ανταπόκρισης στις Αλλαγές 90

91 Οφέλη από τον Ανασχεδιασμό Διαδικασιών Μείωση εμμέσου κόστους διαδικασιών Αύξηση αποτελεσματικότητας Μείωση πολυπλοκότητας Διοικητική απλούστευση Ανάπτυξη ενιαίας κουλτούρας και κλίματος στον οργανισμό Αύξηση ευελιξίας και ικανότητας προσαρμογής στις νέες συνθήκες Σαφής καταμερισμός αρμοδιοτήτων και authorities Διασφάλιση δυνατότητας μελλοντικής αναπτύξεως των δραστηριοτήτων Δυνατότητα λήψεως επιχειρηματικών αποφάσεων με βάση τεκμηριωμένα στοιχεία 91

92 Διαφορές Ανασχεδιασμού για Επιχειρήσεις και Δημόσιους Οργανισμούς Αυστηρό Νομικό Πλαίσιο διέπει τις διαδικασίες Μικρή αυτονομία κινήσεων Μεγαλύτερες προσδοκίες Μεγαλύτερος εφησυχασμός / έλλειψη κινήτρων στους εργαζόμενους Πολιτικές δομές «Μονοπώλιο» των δημόσιων οργανισμών, έλλειψη ανταγωνισμού Μεθοδολογίες, Εργαλεία και Τεχνικές που προέρχονται από τον επιχειρηματικό χώρο χρειάζονται προσαρμογές πριν εφαρμοστούν 92

93 Μετά τον Ανασχεδιασμό : Τι βλέπουμε? Πριν Μετά Τμήματα Εργασίας Τμήματα Λειτουργιών Διεργασίες Εργασίες Απλά καθήκοντα Πολυδιάστατη Εργασία Ρόλοι Ανθρώπων Ελεγχόμενοι Ενδυναμωμένοι Οργανωτική Δομή Ιεραρχική Επίπεδη Μέτρηση Απόδοσης Κριτήρια αξιολογήσεως Δραστηριότητα Αρχαιότητα χρόνος προϋπηρεσίας Αποτελέσματα Απόδοση Managers Επιβλέποντες Καθοδηγητές Executives Ελεγκτές Ηγέτες 93

94 Πότε χρειάζεται ο Ανασχεδιασμός σε μια επιχείρηση? Όταν βρίσκεται σε θέση ισχύος: Για να βελτιώσει το ανταγωνιστικό του πλεονέκτημα Για να διευρύνει το χάσμα που τον χωρίζει από τους ανταγωνιστές του Όταν αντιμετωπίζει προβλήματα: Για να καταρτίσει στρατηγική μελλοντικής δράσης Για να εδραιωθεί στο χώρο Για να αποφύγει πιθανά προβλήματα Όταν βρίσκεται σε δυσμενή θέση: Για να εξασφαλίσει την επιβίωση του Για να αλλάξει τη στρατηγική και τον τρόπο λειτουργίας του 94

95 Ποιές Επιχειρηματικές Διαδικασίες χρειάζονται Ανασχεδιασμό? Καθορίζεται με βάση κριτήρια, όπως Δυσλειτουργία (Dysfunction) Ποιες διαδικασίες έχουν τη χειρότερη επίδοση? Βαθμός σημαντικότητας (Importance) Ποιες διαδικασίες έχουν το μεγαλύτερο όφελος και αντίκτυπο για τους πολίτες? Εφικτότητα (Feasibility) Παραδείγματα: Για ποιες διαδικασίες είναι πιο πιθανό να πετύχει ο ανασχεδιασμός? Διαπίστωση: Υπάρχει πλεονασμός ανταλλασσόμενης πληροφορίας Αιτία: Αυθαίρετη κατάτμηση μιας διαδικασίας Διαπίστωση: Επαναλαμβάνονται δραστηριότητες (π.χ. έλεγχοι) που έχουν ήδη γίνει Αιτία: Μη ικανοποιητικός συντονισμός και διαχωρισμός αρμοδιοτήτων ανάμεσα στα τμήματα 95

96 Φάσεις του Ανασχεδιασμού Επιχειρηματικών Διαδικασιών Σύλληψη και Όραμα Κινητοποίηση Ανασχεδιασμός Διαδικασιών Υλοποίηση Αλλαγών Έλεγχος και Συντήρηση Αναγνώριση ανάγκης για Ανασχεδιασμό Διεξαγωγή αρχικών συζητήσεων Επιλογή Ομάδας Έργου Επιλογή διαδικασιών προς ανασχεδιασμό Καθορισμός χρονοδιαγράμματος και προϋπολογισμού Ανασχεδιασμός διαδικασίας Μέτρηση επιδόσεων (benchmarking) Εισαγωγή των ανασχεδιασμένων διαδικασιών στον οργανισμό Πραγματοποίηση οργανωτικών αλλαγών Εκπαίδευση προσωπικού Επίλυση προβλημάτων Έλεγχος διαδικασιών Συντήρηση και τροποποιήσεις στις διαδικασίες όποτε απαιτείται Source: Omar A. El Sawy, Redesigning Enterprise Processes for ebusiness, McGraw-Hill 96

97 Επίπεδα του Ανασχεδιασμού Επιχειρηματικών Διαδικασιών High 5. Business Scope Redefinition Degree of Business Transformation 4. Business Network Redesign 3. Business Process Redesign 2. Internal Integration 1. Localised Exploitation Revolutionary Levels Evolutionary Levels Low Range of potential High 97

98 Είδη του Ανασχεδιασμού Επιχειρηματικών Διαδικασιών I. Λειτουργική Βελτίωση (Functional Improvement): Αφορά την μείωση κόστους και/ή βελτίωση της αποτελεσματικότητάς της μέσω σταδιακής αλλαγής ή απλουστεύσεως μιας λειτουργίας ή τμήματος II. Λειτουργικός ανασχεδιασμός (Process Reengineering): Αποσκοπεί σε υψηλότερα επίπεδα βελτιώσεως της αποδοτικότητος μέσω ανασχεδιασμού των υπαρχόντων διεργασιών, καταργώντας τα οργανωτικά σύνορα και αποδεχόμενοι μία διαλειτουργική άποψη III. Επιχειρηματική αναθεώρηση (Business Rethinking): Ριζική αλλαγή στη φύση της επιχείρησης με τον επαναπροσδιορισμό της αποστολής και του οράματος των προϊόντων / υπηρεσιών της επιχειρήσεως Στην πράξη οι ανωτέρω τύποι BPR δεν τηρούνται επακριβώς και ένα project BPR μπορεί να ξεκινήσει ως τύπου Ι και στην πορεία να καταλήξει σε τύπου ΙΙ ή τύπου ΙΙΙ. 98

99 Σύγχρονες Μεθοδολογίες BPR Μεθοδολογία Process Reengineering Life Cycle (PRLC) Ενοποιημένη μεθοδολογία BPR των Muthu, Whitman and Cheraghi Μεθοδολογία Object-Oriented Business Engineering Methodology (OO-BEM) των Jacobson et al Μεθοδολογία BPR της Accenture Μεθοδολογία BPR της McKinsey Αποτελούν την απάντηση της Δύσης στο Ιαπωνικό Management KAIZEN (TQM) 99

100 Η Μεθοδολογία «Process Reengineering Life Cycle» Πηγή: Kai A. Simon, Towards a theoretical framework for Business Process Reengineering, June

101 Η Ενοποιημένη Μεθοδολογία BPR των «Muthu, Whitman and Cheraghi» Muthu, S., Whitman, L., and Cheraghi, S. H., Business Process Reengineering: A Consolidated Methodology, Proceedings of the 4th Annual International Conference on Industrial Engineering Theory, Applications and Practice,

102 Μεθοδολογία Object-Oriented Business Engineering Methodology (OO-BEM) Business Development Reversing the existing business (Reverse Engineering) Envisioning Engineering the new business (Forward Engineering) Installing the new business Reengineering Directive The reengineered Corporation 102

103 Η Μεθοδολογία BPR της Accenture Πηγή: Kai A. Simon, Andersen Consulting BPR Approach, 103

104 Η Μεθοδολογία BPR της McKinsey Πηγή: Kai A. Simon, McKinsey BPR Approach, 104

105 Η Επιχειρησιακή Μοντελοποίηση συμβάλλει στον Ανασχεδιασμό... Παρέχοντας οπτική απεικόνιση του οργανισμού και του περιβάλλοντος του Δίνοντας τη δυνατότητα να προσομοιωθούν διάφορα σενάρια / εναλλακτικές ώστε να αποφασιστεί: Πώς οι διαδικασίες μπορούν να τροποποιηθούν / βελτιωθούν Ποια σημεία εμποδίζουν την ομαλή ροή εργασιών (bottlenecks, inconsistencies, etc) Καθοδηγώντας (μέσω των μοντέλων) την υλοποίηση των ανασχεδιασμένων διαδικασιών 105

106 Ανασχεδιασμός Επιχειρηματικών Διαδικασιών στην Ελληνική Δημόσια Διοίκηση?? Επικράτηση της γραφειοκρατίας παρά την ηλεκτρονικοποίηση Έλλειψη θεσμών και πρωτοβουλιών αναδιοργάνωσης της Δημόσιας Διοίκησης στο πλαίσιο του 3 ου Κ.Π.Σ. Διεξαγωγή μελετών απλοποίησης / ανασχεδιασμού που υλοποιούνται σε πολύ μικρό χρονικό διάστημα (λόγω της γενικότερης καθυστέρησης απορρόφησης) και χωρίς κεντρικό συντονισμό Αρχικές πιλοτικές προσπάθειες ανασχεδιασμού στο πλαίσιο της Πρόσκλησης 167 του Ε.Π. Κοινωνία της Πληροφορίας Συντονισμένες προσπάθειες αναμένονται στο 4 ο Κ.Π.Σ. και το Ε.Π. Διοικητική Μεταρρύθμιση Οδηγία 2006/123/ΕΚ του Ευρωπαϊκού Κοινοβουλίου και του Συμβουλίου της 12ης Δεκεμβρίου 2006 σχετικά με τις υπηρεσίες στην εσωτερική αγορά 106

107 Παράδειγμα Υπηρεσίας Σήμερα... Ο πολίτης πρέπει να συγκεντρώσει τα έντυπα / δικαιολογητικά Οι Δημόσιες Υπηρεσίες επικοινωνούν μεταξύ τους μέσω τηλεφώνου, fax ή ταχυδρομικά Επαναλαμβάνονται έλεγχοι και διαδικασίες που έχουν γίνει από άλλο Φορέα / Διεύθυνση / Τμήμα 107

108 Παράδειγμα Υπηρεσίας Αύριο... Μετά τον Ανασχεδιασμό... Ο πολίτης προσκομίζει / αποστέλλει μόνο την αίτηση και το ID του Οι Δημόσιες Υπηρεσίες επικοινωνούν ηλεκτρονικά μεταξύ τους μέσω web services Μοναδικοί έλεγχοι 108

109 Μελέτη Περίπτωσης Ανασχεδιασμού Επιχειρηματικών Διαδικασιών (Ι) Το παράδειγμα του Housing Development Board στη Σιγκαπούρη που υλοποιήθηκε μέσα σε 12 μήνες Source: James Y.L. Thong, Chee-Sing Yap, Kin-Lee Se, Business Process Reengineering in the Public Sector: The Case of the Housing Development Board in Singapore, in Journal of Management Information Systems / Summer 2000, Vol. 17, No. 1, pp

110 Μαθήματα από το Παράδειγμα της Σιγκαπούρης.. 1. Οι δημόσιοι φορείς είναι πολύ απρόθυμοι στην αλλαγή. Κοινωνικές και πολιτικές αλλαγές ασκούν επιρροή πάνω τους για να ανασχεδιάσουν τις διαδικασίες τους. 2. Η δημοσιότητα στον τύπο μπορεί να αξιοποιηθεί από τους δημόσιους φορείς για να τονίσουν τη σημασία του ανασχεδιασμού στο προσωπικό τους. 3. Οι δημόσιοι φορείς που τοποθετούν την ομάδα ανασχεδιασμού στις εγκαταστάσεις τους κατά τη διάρκεια του έργου αναπτύσσουν στενές σχέσεις εργασίας που θα βοηθήσουν να ξεπεραστεί η απροθυμία για αλλαγή. 4. Οι δημόσιοι φορείς πρέπει να λαμβάνουν υπόψη τους ότι τα στελέχη που γνωρίζουν τις διαδικασίες διαφόρων τμημάτων και έχουν εκπαιδευτεί σε διοίκηση και επιχειρησιακή έρευνα είναι πολύ χρήσιμοι ανθρώπινοι πόροι για τον ανασχεδιασμό. 5. Η αξιοποίηση μιας ομάδας ουδέτερων υπαλλήλων που έχουν τεχνογνωσία από διάφορα τμήματα για να στελεχώσουν τον πυρήνα της ομάδας ανασχεδιασμού αποτελεί καλή τακτική. 6. Οι δημόσιοι οργανισμοί πρέπει να έχουν υπόψη τους ότι είναι κρίσιμο να ελέγχουν σταδιακά την πρόοδο του έργου με τη βοήθεια επιχειρησιακών στελεχών για να επαληθεύουν την ακρίβειά του. 7. Οι δημόσιοι φορείς που υιοθετούν τη μέθοδο δοκιμαστικής εφαρμογής σε μια μεμονωμένη περίσταση πρέπει να προσέξουν ώστε να είναι αντιπροσωπευτική του οργανισμού. 8. Δεδομένης της έλλειψης δεικτών παρακολούθησης, οι δημόσιοι φορείς πρέπει να υιοθετούν δείκτες επιδόσεων από τον ιδιωτικό τομέα για να παρακολουθούν την πρόοδο βελτίωσης των διαδικασιών τους. 9. Η σύσταση οργανωτικής επιτροπής είναι απαραίτητη για να διασφαλιστεί η έγκριση των ανασχεδιασμένων διαδικασιών στο φορέα. 10. Το βασικό κριτήριο κατά την επιλογή νέων υποδομών και αρχιτεκτονικών ΤΠΕ είναι η δυνατότητα να υποστηρίξουν τις ανασχεδιασμένες διαδικασίες χωρίς αδικαιολόγητους κινδύνους. 11. Οι δημόσιοι φορείς πρέπει να αναθεωρήσουν τις ανάγκες εκπαίδευσης προσωπικού για τις ανασχεδιασμένες δουλειές. 12. Οι δείκτες μέτρησης επιδόσεων πρέπει να είναι απλοί και εστιασμένοι στο τελικό αποτέλεσμα. 13. Μια αναθεωρημένη δομή «κινήτρων» για την υποστήριξη των ανασχεδιασμένων διαδικασιών είναι κρίσιμη για την επιτυχή έκβαση του ανασχεδιασμού στον φορέα. 14. Μια πιλοτική εφαρμογή θα βοηθήσει να τελειοποιηθεί η ανασχεδιασμένη διαδικασία. 15. Τα αποτελέσματα από μια επιτυχημένη πιλοτική εφαρμογή θα συμβάλλουν στην έγκριση της χρηματοδότησης. 16. Οι δημόσιοι φορείς που εφαρμόζουν ανασχεδιασμό πρέπει να αφιερώσουν επαρκή χρόνο και πόρους για την επανεκπαίδευση του προσωπικού. 17. Οι δημόσιοι φορείς πρέπει να σχεδιάσουν την πορεία των ανασχεδιασμένων διαδικασιών προσεκτικά. 18. Οι δημόσιοι φορείς που εφαρμόζουν ανασχεδιασμό πρέπει να εκπαιδεύσουν και να προετοιμάσουν το προσωπικό για τις επερχόμενες αλλαγές με τη βοήθεια ενός εντατικού επικοινωνιακού προγράμματος, πιθανόν με δημοσίευση άρθρων στον τύπο και επιτόπιες επισκέψεις. 19. Οι δημόσιοι φορείς πρέπει να θεωρούν τον ανασχεδιασμό και τις ΤΠΕ σαν μια ενοποιημένη στρατηγική. 110

111 Μελέτη Περίπτωσης Ανασχεδιασμού Επιχειρηματικών Διαδικασιών (IΙ) Το παράδειγμα της Γενικής Γραμματείας Επικοινωνίας Γενική Γραμματεία Ενημέρωσης (ΓΓΕ-ΓΓΕ) που υλοποιήθηκε μέσα σε 4 μήνες Διαδικασία: Επιχορήγηση της ταχυδρομικής διακίνησης του τύπου Εμπλεκόμενοι: ΓΓΕ- ΓΓΕ / Διεύθυνση Εποπτείας ΜΜΕ, ΕΛΤΑ (Τοπικά Καταστήματα ΕΛΤΑ και Κεντρική Υπηρεσία) Εκδότες έντυπων εφημερίδων και περιοδικών Προϋποθέσεις που θέτει ο νόμος για να δικαιούται ένα έντυπο επιχορήγηση Να έχει υποβάλλει σχετική αίτηση ή οποία θα πρέπει να εγκριθεί από την ΓΓΕ-ΓΓΕ Να έχει ήδη εκδώσει 3 έντυπα Να εκδίδει τα έντυπα σε τακτικά διαστήματα σύμφωνα με την περιοδικότητα του εντύπου (π.χ. ένα μηνιαίο έντυπο θα πρέπει να εκδώσει τουλάχιστον 10 έντυπα μέσα στον χρόνο ώστε να δικαιούται επιχορήγησης) Να μην έχει διαφημίσεις πέρα ενός καθορισμένου ορίου Να μην έχει διανέμει μαζί με το έντυπο και άλλο διαφημιστικό υλικό 111

112 Μαθήματα από το Παράδειγμα της ΓΓΕ- ΓΓΕ.. 3 Σενάρια εξετάστηκαν αναλυτικά: Επιδότηση των εκδοτών με voucher που θα περιέχουν barcodes Σύστημα internet Σύστημα CTI ΜΕΤΑ: Παρακολουθεί πλήρως τις κυκλοφορίες των εντύπων Παρακολουθεί τις αιτήσεις των εκδοτών για ένταξη στο καθεστώς επιδότησης Αυτοματοποιεί την παρακολούθηση του δικαιώματος επιδότησης Κάνει οικονομική εκκαθάριση Αποκτειθείσα Εμπειρία: Βελτίωση KPIs (Key Performance Indicators) Διαχείριση Αλλαγών Διαχείριση Εξαιρέσεων Επανεκπαίδευση 112

113 Επιπλέον Μελέτες Περιπτώσεων... ΗΦΑΙΣΤΟΣ και Διαχείριση Πετρελαίου Θέρμανσης Άλλα Παραδείγματα από την Ελληνική Δημόσια Διοίκηση? Συζήτηση... Στο χώρο του Ηλεκτρονικού Εμπορίου διεθνώς: Το παράδειγμα της L.L. Bean (η μεγαλύτερη εταιρεία παραγγελιών μέσω ταχυδρομείου για αθλητικό ντύσιμο στις Η.Π.Α.): Ανασχεδιασμός Διαδικασίας Παραγγελίας Το παράδειγμα της Marshall Industries (μεγάλος διανομέας ηλεκτρονικών εξαρτημάτων στις Η.Π.Α.): Ανασχεδιασμός για να αλλάξει η ροή πληροφορίας Το παράδειγμα της Storage Dimensions (κατασκευαστής αποθηκευτικών συστημάτων): Ανασχεδιασμός για καλύτερη διαχείριση γνώσης σχετικά με προβλήματα των συστημάτων Source: Omar A. El Sawy, Redesigning Enterprise Processes for ebusiness, McGraw-Hill 113

114 Εισαγωγή στην XML 4

115 Από τι αποτελείται ένα έγγραφο? Περιεχόμενο: τα συστατικά (λέξεις, εικόνες, κλπ.) που δημιουργούν ένα έγγραφο Δομή: η οργάνωση των συστατικών αυτών Παρουσίαση: η εμφάνιση και ο τρόπος επεξεργασίας των συστατικών αυτών 115

116 Δεδομένα στο Διαδίκτυο: HTML και XML HTML: XML: Περιγράφει την παρουσίαση και όχι το περιεχόμενο Δεν διευκολύνει άλλα προγράμματα να κατανοήσουν την δομή και το περιεχόμενο μιας σελίδας Χρησιμοποιεί tags ανάμεσα στο κείμενο... για να περιγράψει το layout της σελίδας <p> <b>alan</b>, 42 years, Περιγράφει τη δομή και το περιεχόμενο Χρησιμοποιεί τα tags που ορίζει ο χρήστης για να περιγράψει το περιεχόμενο της σελίδας Τα tags μπορούν να εφωλιασθούν δομικά σε οποιοδήποτε βάθος <book> <author> XX </author> </book> 116

117 XML extensible Markup Language Η ανάπτυξη της XML (extensive Markup Language) ξεκίνησε το 1996 και το 1998 εντάχθηκε στο W3C (World Wide Web Consortium Specification) Προέρχεται από τη SGML (Standard Generalized Markup Language) και συνδυάζει την ισχύ και την επεκτασιμότητα της με την απλότητα που απαιτεί το Διαδίκτυο Σήμερα βρίσκεται στην τέταρτη έκδοση της XML 1.0 (Fourth Edition) Χαρακτηρίζεται ως ευρέως υποστηριζόμενη, ανοικτή τεχνολογία για την περιγραφή και την αναπαράσταση δομημένων δεδομένων Σημείο κλειδί: Τα έγγραφα XML περιγράφουν τον εαυτό τους, δηλαδή εκτός από το ίδιο το κείμενο που εμπεριέχουν, υπάρχει και ένα σύνολο δηλώσεων που στην ουσία ορίζει τη σημασιολογία του περιεχομένου 117

118 Πλεονεκτήματα της XML Υποστηρίζει ανεξαρτησία από τα δεδομένα και διαχωρίζει τα περιεχόμενα από τον τρόπο εμφάνισής τους και τον χειρισμό τους (σε αντίθεση με την HTML) Είναι επεκτάσιμη και ανεξάρτητη από πλατφόρμες Διατίθενται έτοιμοι τρόποι σύνδεσης των κειμένων XML με τα πλέον σύγχρονα προγραμματιστικά περιβάλλοντα, όπως DOM και SAX Είναι αναγνώσιμη από ανθρώπους και μηχανές Είναι πλήρως συμβατή με Unicode Τhe idea of XML is to maintain the 50% of SGML that is used 90% of the time. Liberty and Kraley, W3C 118

119 XML Elements Aποτελούνται υποχρεωτικά από ένα ζεύγος ετικετών (tags): start-tag και end-tag Τι μπορεί να υπάρχει περιέχει 1 element? Απλό κείμενο π.χ. <person>john</person> Αλλα elements π.χ. <person><name>john</name></person> Οποιοδήποτε μίγμα των δύο παραπάνω! π.χ. <person>the name of the person is <name>john</name>.</person> Τα elements και τα tags στην XML: Ορίζονται από τους χρήστες, δεν υπάρχουν προκαθορισμένα tags όπως στην HTML Ανοίγουν και κλείνουν πάντα με την «σωστή» σειρά (σαν παρενθέσεις) Εξαίρεση: empty tag, πχ. <journal/> (το / στο τέλος) <journal/> = <journal></journal> Απαγορεύεται να ξεκινούν με XML είτε σε πεζά είτε σε κεφαλαία Το πρώτο γράμμα πρέπει να είναι χαρακτήρας ή _ ή colon 119

120 XML Attributes Ένα XML Element μπορεί να περιέχει ένα ή περισσότερα attributes (ιδιότητες) Τα attributes παρέχουν πρόσθετη πληροφορία για τα elements Τα attributes στην XML: Ορίζονται από τους χρήστες σαν ζεύγη ονομάτων τιμών Tοποθετούνται στην ετικέτα αρχής του στοιχείου στο οποίο αναφέρονται, π.χ. <book isbn=" x" language="english"> <title> How to learn XML </title> <price currency = Euro"> 100 </price> </book> Δεν επιτρέπεται σε περισσότερα του ενός attributes να έχουν το ίδιο όνομα στο ίδιο element Η σειρά εμφάνισης των attributes ενός element δεν παίζει κανένα ρόλο Τα attributes μπορούν να γραφούν και με τη μορφή εμφωλευμένων elements, π.χ. <book> <isbn> X </isbn> <language>english</language> <title> XML </title> </book> 120

121 Σύνταξη της XML Κάθε XML έγγραφο ξεκινάει με processing instructions, δηλαδή <??> tags: <?xml version="1.0" encoding="utf-8"?> Τα elements και τα attributes ορίζονται ως εξής: <tag attribute1_name="value1" attributen_name = valuen">... περιεχόμενο στοιχείου... </tag> Τα σχόλια επιτρέπονται οπουδήποτε εκτός από το εσωτερικό των tags και ορίζονται ως: <!-- A first example using XML --> 121

122 Παράδειγμα XML Εγγράφου <ARTIST> <NAME> <FIRST>Claude</FIRST> <LAST>Monet</LAST> </NAME> <ARTWORK> <ARTIFACT> <TITLE>Haystacks at Chailly at Sunrise</TITLE> <DATE>1865</DATE> <MATERIAL>Oil on canvas</material> <DIM Metric= cm > <HEIGHT>30</HEIGHT><WIDTH>60</WIDTH></DIM> <DIM Metric= in > <HEIGHT>11 7/8</HEIGHT><WIDTH>23 3/4</WIDTH></DIM> <LOCATION>San Diego Museum of Art</LOCATION> <IMAGE File= /> </ARTIFACT> </ARTWORK> </ARTIST> ΑΠΕΙΚΟΝΙΣΗ ΣΕ ΓΡΑΦΟ

123 Οικογένεια Προτύπων XML XML Schema XML Namespace XSL και XSLT XML Signature XML Encryption XML Query XForms XPath Xlink XPointer CSS RDF (Resource Description Framework) WML (Wireless Markup Language) MathML GML (Geography Markup Language) 123

124 Ανάκτηση Δεδομένων από XML αρχεία: Πώς; Μέσω της λεκτικής ανάλυσης (XML parsing), που αναλύει το ΧΜL αρχείο στα επιμέρους στοιχεία του: αρχή ετικέτας, τέλος ετικέτας, κείμενο, ιδιότητες Οι πιο γνωστοί λεκτικοί αναλυτές που παρέχουν APIs είναι: DOM (Document Object Model) που αποθηκεύει τα δεδομένα εγγράφου ως δομές δένδρων στη μνήμη με αυτόματο τρόπο. Mε το δένδρο DOM ο χρήστης μπορεί να πλοηγηθεί μέσα σ ένα XML αρχείο και να προσθέσει, να μεταβάλει και να αφαιρέσει στοιχεία του. SAX (Simple API for XML) που μοιάζει με σειριακό αναγνώστη (SAX reader) του κειμένου XML, χαρακτήρα προς χαρακτήρα. Αναγνωρίζοντας τα διάφορα μέρη του αρχείου, δημιουργεί αντίστοιχα συμβάντα (events), στα οποία το πρόγραμμα του χρήστη οφείλει να ανταποκριθεί. 124

125 XML Namespace (1/2) Πρόβλημα: ο τύπος των elements είναι καθολικός (global) Το ίδιο έγγραφο πρέπει να μπορεί να χρησιμοποιηθεί από πολλά προγράμματα που καταλαβαίνουν και άλλα έγγραφα Αν υπάρχουν 2 ή παραπάνω elements με το ίδιο όνομα σε διαφορετικά αρχεία τι γίνεται με τις διενέξεις ονομάτων εάν τα συγχωνεύσουμε? Doc1.xml <?xml version="1.0" encoding="utf-8"?> <vehicles> <trolleys design="modern">greek trolleys are new and many in operation <capacity passenger_no="132"/> </trolleys> </vehicles> Doc2.xml <?xml version="1.0" encoding="utf-8"?> <vehicles> <trolleys design="spartan">russian trolleys are old and some are in operation <capacity passenger_no="124"/> </trolleys> </vehicles> Doc3.xml? 125

126 XML Namespace (2/2) Λύση: XML Namespaces = συλλογές ονομάτων που χρησιμοποιούνται στα έγγραφα XML για να διαφοροποιούν τα elements και τα attributes μεταξύ τους με βάση το όνομά τους Ορίζονται ως xmlns:prefix= location όπου prefix: το πρόθεμα και location το URL ή το URN που έχει οριστεί κάθε element / attribute. Εάν απουσιάζει το prefix, πρόκειται για το default namespace. Επομένως το Doc3.xml γίνεται: <?xml version="1.0" encoding="utf-8"?> <vehicles xmlns:gr= " xmlns:ru= " <gr:trolleys design="modern">greek trolleys are new and many in operation <gr:capacity passenger_no="132"/> </gr:trolleys> <ru:trolleys design="spartan">russian trolleys are old and some are in operation <ru:capacity passenger_no="124"/> </ru:trolleys> <trolleys design="elegant">italian trolleys are very old and no longer in operation <capacity passenger_no="108"/> </trolleys> </vehicles> Doc1.xml Doc2.xml 126

127 Σωστά δομημένα και έγκυρα XML Έγγραφα Ως Well-formed XML έγγραφα ορίζονται τα XML έγγραφα στα οποία: Υπάρχει ένα στοιχείο ρίζα (element root) Τα tags είναι σωστά εμφωλιασμένα Τα start-tag και end-tag ταιριάζουν Τα attributes ενός element είναι μοναδικά Εάν ένα έγγραφο δεν είναι well-formed δεν θεωρείται XML έγγραφο... Ως Valid XML έγγραφα ορίζονται τα XML έγγραφα τα οποία: Είναι well-formed Έχουν κάποιο DTD ή XML Schema Συμμορφώνονται με αυτό το DTD ή XML Schema 127

128 XML Schema Αποτελεί σύσταση του W3C από το 2001 Σήμερα η προδιαγραφή βρίσκεται στη δεύτερη έκδοση (Μάιος 2004) και περιλαμβάνει: XML Schema Part 0: Primer XML Schema Part 1: Structures XML Schema Part 2: Datatypes Εκφράζουν ένα σύνολο από κανόνες στους οποίους θα πρέπει να συμμορφώνεται ένα έγγραφο XML για να θεωρείται έγκυρο σύμφωνα με το συγκεκριμένο σχήμα Πλεονέκτηματα σε σχέση με τα DTDs (Document Type Definitions): Μπορούν να υποστούν χειρισμούς, π.χ. μπορούν να προστεθούν ή να διαγραφούν στοιχεία, όπως σε οποιοδήποτε άλλο έγγραφο XML Ορίζουν αυστηρότερα σύνθετους τύπους δεδομένων, με βασικούς τύπους και περιορισμούς Μπορούν να εισάγουν ή να περιέχουν αναφορά σε άλλα XML Σχήματα 128

129 Ποια είναι η λογική πίσω από τα ΧΜL Schemas? 129

130 Τι ορίζει ένα XML Schema Τα elements που εμφανίζονται σε ένα έγγραφο Τα attributes που συνοδεύουν κάθε element Ποια elements είναι εμφωλευμένα σε άλλα Τη σειρά και τον αριθμό των elements Εάν ένα element είναι κενό ή περιλαμβάνει κείμενο Τους τύπους δεδομένων για τα elements και τα attributes Τις προκαθορισμένες και fixed τιμές για τα elements και τα attributes Τα patterns που πρέπει να υπακούν, το μήκος και τον αριθμό εμφανίσεων των τιμών των elements 130

131 Παράδειγμα XML Σχήματος Books.xml <?xml version="1.0" encoding="utf-8"?> <book xmlns:xsi=" xsi:nonamespaceschemalocation="c:\users\teti\desktop\book. xsd"> <title>c# How to program</title> <serial_no> </serial_no> </book> Books.xsd <?xml version="1.0" encoding="utf-8"?> <xs:schema xmlns:xs=" elementformdefault="qualified" attributeformdefault="unqualified"> <xs:element name="book"> <xs:annotation> <xs:documentation>this is the first example in XSD</xs:documentation> </xs:annotation> <xs:complextype> <xs:sequence> <xs:element name="title" type="xs:string"/> <xs:element name="serial_no" type="xs:integer"/> </xs:sequence> </xs:complextype> </xs:element> </xs:schema> 131

132 Δομή ενός XML Schema Κάθε XML Schema ξεκινάει με το root element: <xs:schema xmlns:xs=" Ακολουθούν οι δηλώσεις των elements, attributes και των τύπων δεδομένων τους 132

133 Δήλωση XML Elements σε ένα XML Schema Η δήλωση ενός element τυπικά περιλαμβάνει: name: το όνομα του element type: ο τύπος του element minoccurs: ο ελάχιστος αριθμός εμφανίσεων του element maxoccurs: ο μέγιστος αριθμός εμφανίσεων του element Π.χ. <xs:element name="title" type="xs:string" minoccurs="1" maxoccurs="unbounded"/> 133

134 Δήλωση XML Attributes σε ένα XML Schema Η δήλωση ενός attribute τυπικά περιλαμβάνει: name: το όνομα του attribute type: ο τύπος του attribute use: εάν το attribute είναι υποχρεωτικό (required) ή προαιρετικό (optional) value: η προκαθορισμένη τιμή του attribute σε συνδυασμό με use= default ή fixed Π.χ. <xs:attribute name= Currency" type="xs:string" use="fixed" value="euro"/> <xs:attribute name= IssueDate" type="xs:date" use= required /> 134

135 Δήλωση Data Types σε ένα XML Schema Η δήλωση ενός data type μπορεί να προέρχεται από: Ενσωματωμένους XSD τύπους δεδομένων, π.χ. integer, string, date, boolean Τύπους δεδομένων που ορίζει ο χρήστης σε 2 επίπεδα: Απλούς τύπους που δεν μπορούν να χρησιμοποιούν άλλα elements και attributes π.χ. <xs:simpletype name="taxpayeridtype"> <xs:restriction base="xs:string"> <xs:pattern value= [0-9]{9}"/> </xs:restriction> </xs:simpletype> Σύνθετους τύπους που χρησιμοποιούν άλλα elements ή / και attributes και ορίζουν ότι όλα τα elements πρέπει να εμφανιστούν με δεδομένη σειρά (sequence) ή χωρίς να έχει σημασία η σειρά (all) ή ότι ένα element θα επιλεγεί (choice) π.χ. <xs:complextype name="orderrequesttype"> <xs:sequence> <xs:element name="id" type="xs:token"/> <xs:element name="sellerparty" type="xs:string" minoccurs="0"/> <xs:element name="buyerparty" type="xs:string" minoccurs="0"/> </xs:sequence> </xs:complextype> 135

136 Ιδιότητες των Complex Data Types Extension: ένας complex data type μπορεί να επεκταθεί με την προσθήκη νέων elements ή / και attributes π.χ. <xs:complextype name="purchaseorderrequesttype"> <xs:complexcontent> <xs:extension base="ram:orderrequesttype"> <xs:sequence> <xs:element name="id" type="xs:token"/> <xs:element name="sellerparty" type="xs:string"/> </xs:sequence> <xs:attribute name="ordertype" type="xs:string" fixed="purchase"/> </xs:extension> </xs:complexcontent> </xs:complextype> Restriction: ένας complex data type μπορεί να «περιοριστεί» με την προσθήκη νέων attributes type και use και την μείωση των maxoccurs και minoccurs π.χ. <xs:complextype name="saleorderrequesttype"> <xs:complexcontent> <xs:restriction base="ram:orderrequesttype"> <xs:sequence> <xs:element name="id" type="xs:token"/> <xs:element name="buyerparty" type="xs:string"/> </xs:sequence> </xs:restriction> </xs:complexcontent> </xs:complextype> 136

137 Διαχείριση Δεδομένων: Το Πρόβλημα Σήμερα

138 ISO : UN/CEFACT CCTS Core Components Technical Specification Προτάθηκε από τον οργανισμό UN/CEFACT (United Nations Centre for Trade Facilitation and Electronic Business) το Υιοθετήθηκε από το ISO ως το πρότυπο ISO Παρουσιάζει μια μεθοδολογία για την ανάπτυξη ενός συνόλου κοινών σημασιολογικών δομών που αναπαριστούν γενικούς τύπους επιχειρηματικών δεδομένων. Διασφαλίζει ότι τα επιχειρηματικά δεδομένα που έχουν γραφτεί σε διαφορετική σύνταξη (π.χ. Extensible Markup Language XML και United Nations/EDI for Administration, Commerce, and Transport UN/EDIFACT), αλλά στηρίζονται στα ίδια δομικά συστατικά (core components), έχουν την ίδια σημασιολογία ΠΩΣ? Μέσω των UN/CEFACT CCL και NDR 138

139 Δομή των CCTS Γενικά Δομικά Συστατικά (Core Components - CC) με πληροφορία που μπορεί να χρησιμοποιηθεί σε οποιαδήποτε περίσταση. Συγκεκριμένα Δομικά Συστατικά, τις Οντότητες Επιχειρηματικής Πληροφορίας (Business Information Entities - BIE), που έχουν οριστεί για κάποιο συγκεκριμένο περιβάλλον, π.χ. για ένα συγκεκριμένο Δημόσιο Φορέα. Προσαρμόζουν τα Core Components σε μια συγκεκριμένη περίσταση και πρέπει να: Έχουν το ίδιο μεταμοντέλο με τα θεμελιώδη Core Components Προέρχονται πάντα από αντίστοιχα Core Components Οι τύποι δεδομένων τους να προέρχεται από περιορισμούς στους Core Data Types Διευκρινίζουν το πλαίσιο στο οποίο χρησιμοποιούνται 139

140 Βασικά Σημεία της Μεθοδολογίας CCTS Βασικοί Τύποι Δεδομένων ανεξάρτητοι από σύνταξη (Syntax Neutral Core Data Types), όπως: Amount. Type Code. Type Date. Type Numeric. Type Quantity. Type Text. Type Κατηγορίες ανάλογα με το περιβάλλον (context) που χρησιμοποιούνται τα δεδομένα, όπως: Business Process Constraints Organization Classification Geopolitical Constraints 140

141 Δομή των Core Components Πηγή: UN/CEFACT Core Components Technical Specification, Part 8 of the ebxml Framework, Version 2.01 (November 2003) 141

142 Ποια η σχέση ανάμεσα σε CCs, BIEs και XML Schemas? 142

143 Παράδειγμα Εννοιών CC και BIE 143

144 Τεκμηρίωση των Core Components: Πώς? Με μια σειρά από μεταδεδομένα που περιλαμβάνουν 144

145 Τεκμηρίωση των Βusiness Ιnformation Εntities: Πώς? Με μια σειρά από μεταδεδομένα που περιλαμβάνουν 145

146 Τεκμηρίωση των Qualified Data Types: Πώς? Με μια σειρά από μεταδεδομένα που περιλαμβάνουν 146

147 Πώς ερμηνεύονται τα CCs, BIEs και QDTs στην XML? Πηγή: UN/CEFACT XML Naming and Design Rules, Version 2.0 (February 2006) 147

148 Παράδειγμα ενός Core Component σε excel 148

149 Παράδειγμα ενός Δομικού Συστατικού σε XSD <xs:element name="person" type="cc:persontype" id="εl "> <xs:annotation> <xs:documentation xml:lang="eng"> <ccts:uniqueid>εl </ccts:uniqueid> <ccts:acronym>acc</ccts:acronym> <ccts:dictionaryentryname>person. Details</ccts:DictionaryEntryName> <ccts:version>1.0</ccts:version> <ccts:definition>an individual human being.</ccts:definition> <ccts:objectclassterm>person</ccts:objectclassterm> </xs:documentation> <xs:documentation xml:lang="ell"> <ccts:businessterm>άτομο</ccts:businessterm> </xs:documentation> </xs:annotation> </xs:element> <xs:complextype name="personstructure"> <xs:sequence> <xs:element name="id" type="udt:idtype" id="εl " minoccurs="0" maxoccurs="unbounded"> <xs:annotation> <xs:documentation xml:lang="eng"> <ccts:uniqueid>εl </ccts:uniqueid> <ccts:acronym>bcc</ccts:acronym> <ccts:dictionaryentryname>person. Identification. Identifier</ccts:DictionaryEntryName> <ccts:version>1.0</ccts:version> <ccts:definition>a unique identifier for this person.</ccts:definition> <ccts:objectclassterm>person</ccts:objectclassterm> <ccts:propertyterm>identification</ccts:propertyterm> <ccts:representationterm>identifier</ccts:representationterm> <ccts:cardinality>0..unbounded</ccts:cardinality> </xs:documentation> <xs:documentation xml:lang="ell"> <ccts:businessterm>αναγνωριστικό</ccts:businessterm> </xs:documentation> </xs:annotation> ΕΛΛΗΝΙΚΟ </xs:element> ΠΛΑΙΣΙΟ ΠΑΡΟΧΗΣ... ΥΠΗΡΕΣΙΩΝ ΗΛΕΚΤΡΟΝΙΚΗΣ ΔΙΑΚΥΒΕΡΝΗΣΗΣ </xs:sequence> </xs:complextype> 149

150 Παράδειγμα ενός Business Information Entity σε excel 150

151 Παράδειγμα ενός Qualified Data Type <xs:complextype name="identitycardidtype"> <xs:annotation> <xs:documentation> <ccts:component> <ccts:dictionaryentryname>identity Card_ Identifier. Type</ccts:DictionaryEntryName> <ccts:version>1.0</ccts:version> <ccts:definition>the type for the identifier for an identity card.</ccts:definition> <ccts:representationterm>identifier</ccts:representationterm> <ccts:qualifierterm>identity Card</ccts:QualifierTerm> <ccts:uniqueid/> </ccts:component> </xs:documentation> </xs:annotation> <xs:simplecontent> <xs:restriction base="udt:idtype"> <xs:pattern value="[a-ω]{1,2}\d{6}"/> </xs:restriction> </xs:simplecontent> </xs:complextype> 151

152 Παρουσίαση των XML εγγράφων: Πώς; Εξαρτάται από το style sheet που τα συνοδεύει... Ένα style sheet ορίζει πώς ένα έγγραφο εμφανίζεται, περιλαμβάνει αναδιάταξη, φιλτράρισμα ή και εισαγωγή νέων στοιχείων. Παραδείγματα style sheets εκφράζονται σε: Cascading Stylesheets (CSS) Extensible Stylesheet Language (XSL) LaTeX Styles Word ή Powerpoint Templates 152

153 Οικογένεια Προτύπων XSL Η ΧSL παρέχει μια γλώσσα για τη διαχείριση style sheets Αποτελείται από τρια ξεχωριστά επιμέρους πρότυπα: XSL-FO (XSL Formating Objects) που ορίζει το format παρουσίασης ενός εγγράφου XML XPath (XML Path Language) που επιλέγει τμήματα ενός εγγράφου XML π.χ. Σε απλοποιημένη μορφή, επιστρέφει τα βιβλία σε ένα XML έγγραφο: database/biblio/book (ονόματα XML tags) ή επιστρέφει τους πρώτους συγγραφείς των βιβλίων: root()/descendant::book/child::author[position()=fi rst()] XSLT (XSL Transformation language) που μετατρέπει ένα έγγραφο XML σε κάποιο άλλο έγγραφο 153

154 XSLT (XSL Transformations) Αποτελεί Σύσταση του W3C από το 2001 Ουσιαστικά, Δέχεται ένα XML έγγραφο σαν είσοδο Το μετασχηματίζει σε άλλο markup document (XML, XHTML, WML,...) ή σε κείμενο με βάση κανόνες που δομούνται σε 2 μέρη: pattern matching και substitution και ακολουθούν τη δομή <xsl:template match= [[XPath pattern]] > [[ Substitution part ]] </xsl:template> 154

155 Παράδειγμα ενός XSLT Style Sheet <?xml version="1.0"?> <report> <title>database Access Sample</title> <section> <title>employees by Last Name</title> <dbaccess driver="com.ibm.db2.jdbc.app.db2driver" database="jdbc:db2:sample" tablename="wstkadmin.employee" where="*" fieldnames='lastname as "Last Name", firstnme as "First Name", workdept as "Department"' orderby="lastname" group-by="lastname, firstnme, workdept"/> </section> </report> <?xml version="1.0"?> <xsl:stylesheet xmlns:xsl=" version="1.0"> <xsl:output method="xml"/> <xsl:template match="*"> <xsl:element name="{name()}"> <xsl:for-each <xsl:element name="{name()}"> <xsl:value-of select="."/> </xsl:element> </xsl:for-each> <xsl:apply-templates select="* text()"/> </xsl:element> </xsl:template> </xsl:stylesheet> <?xml version="1.0" encoding="utf-8"?> <report> <title>database Access Sample</title> <section> <title>employees by Last Name</title> <dbaccess> <driver>com.ibm.db2.jdbc.app.db2driver</driver> <database>jdbc:db2:sample</database> <tablename>wstkadmin.employee</tablename> <where>*</where> <fieldnames>lastname as "Last Name", firstnme as "First Name", workdept as "Department"</fieldnames> <order-by>lastname</order-by> <group-by>lastname, firstnme, workdept</groupby> </dbaccess> </section> </report> 155

156 Μοντελοποίηση Εγγράφων και Δεδομένων στο ΠΗΔ 5

157 Μοντελοποίηση Εγγράφων και Δεδομένων: Σήμερα... Συντακτική αναπαράσταση των δεδομένων π.χ. τα πεδία της Διεύθυνσης Σημασιολογική αναπαράσταση των δεδομένων π.χ. η ίδια πληροφορία μπορεί να εκφραστεί με συνώνυμα ή και να έχει διαφορετική ερμηνεία Σημασιολογική ταύτιση δεδομένων με διαφορετικές λίστες π.χ. είναι σύνηθες και χρήσιμο για λόγους αυτοματοποιημένης επεξεργασίας πληροφορίες που αφορούν τυποποιημένες λίστες να ανταλλάσσονται μηχανογραφικά με χρήση κωδικών και όχι των περιγραφών (π.χ. ISO κωδικοί χωρών ή νομισμάτων) που τηρούνται τοπικά

158 Μοντελοποίηση Εγγράφων και Δεδομένων: Αύριο... Κοινό πρότυπο για την ανταλλαγή δεδομένων: XML που συμμορφώνονται σε δομημένα XML Schemas Κοινές, επαναχρησιμοποιήσιμες δομές δεδομένων με κοινή σημασιολογική ερμηνεία Σημασιολογική ταύτιση δεδομένων με καθολικά αποδεκτές λίστες 158

159 Βασικές Αρχές Μοντελοποίησης Δεδομένων Συμμόρφωση με τα πρότυπα W3C XML Schema Definition Language και ISO CCTS (Core Components Technical Specification) Συνέπεια των Σχημάτων με τις πληροφορίες και τα δεδομένα που πραγματικά ανταλλάσσονται Πληρότητα, χωρίς να παραλείπεται κανένας τύπος δεδομένων που χρησιμοποιείται σε έγγραφα Μοναδικότητα έκφρασης της πληροφορίας Διατηρησιμότητα και ευκολία διαχείρισης των Σχημάτων Διασύνδεση με τα Μοντέλα Διαδικασιών Ανεξαρτησία από εργαλεία Σχέση με υπάρχοντα Σχήματα 159

160 Φάση Δ Φάση Γ Φάση Β Φάση Α Μεθοδολογία Μοντελοποίησης Εγγράφων Καθορισμός Λίστας Εγγράφων προς Μοντελοποίηση Δημιουργία Προτεραιοτήτων ανάμεσα στα Έγγραφα Συγκέντρωση και Αξιολόγηση Πληροφοριών Καταγραφή Μεταδεδομένων Εγγράφων Επικύρωση-Συμπλήρωση Πληροφοριών Αναζήτηση για επαναχρησιμοποιήσιμα BIEs Προσαρμογή επαναχρησιμοποιήσιμων BIEs Δημιουργία νέων BIEs με βάση τα CC της egif CCL Σχεδιασμός XML Schema 160

161 Τι σημαίνει για ένα Δημόσιο Φορέα η Μοντελοποίηση Εγγράφων με βάση το Πλαίσιο? KY.23 KY.21, ΚΥ.22 KY.24 KΠ.7 Τα έγγραφα που εκδίδουν οι Δημόσιοι Φορείς ΠΡΕΠΕΙ ΝΑ απεικονίζονται στο Ληξιαρχείο Διαλειτουργικότητας με τα μεταδεδομένα του Μοντέλου Τεκμηρίωσης. Εναλλακτικά, τα μεταδεδομένα περιγραφής ενός εγγράφου ΘΑ ΠΡΕΠΕΙ να παραδίδονται ως RDF ή Excel αρχεία. Τα Σχήματα Δεδομένων (XML Schemas) ΠΡΕΠΕΙ ΝΑ σχεδιάζονται με βάση το σύνολο των οδηγιών και των προτύπων που αποτελούν συστάσεις (recommendation status) του World Wide Web Consortium (W3C) και του UN/CEFACT. Το XML Σχήμα στο οποίο συμμορφώνεται ένα έγγραφο ΠΡΕΠΕΙ ΝΑ παραδίδεται ως αρχείο XSD. Εναλλακτικά, η Μοντελοποίηση Δεδομένων ΔΥΝΑΤΑΙ ΝΑ απεικονιστεί σε Διαγράμματα Κλάσεων (Class Diagrams) της UML. Σε αυτήν την περίπτωση, τα Διαγράμματα Κλάσεων ΘΑ ΠΡΕΠΕΙ ΝΑ μετασχηματίζονται σε XML Σχήματα με τη βοήθεια του προτύπου XMI (XML Metadata Interchange) πριν υποβληθούν στο ΠΗΔ, διότι τα XML Σχήματα ελέγχονται ως προς τη συμμόρφωσή τους με το ΠΗΔ. 161

162 Μεταδεδομένα Καταγραφής Εγγράφου (Ι) ΓΕΝΙΚΑ ΣΤΟΙΧΕΙΑ ΕΓΓΡΑΦΟΥ Κωδικός Εγγράφου Τίτλος Εγγράφου Θέμα Κατηγορία Εγγράφου Συσχετιζόμενη Υπηρεσία Πηγή Εγγράφου Κάλυψη Μορφότυπος Εγγράφου Το μοναδικό αναγνωριστικό του εγγράφου Το όνομα του εγγράφου Μια συνοπτική περιγραφή του εγγράφου Η κατηγορία του εγγράφου (π.χ. Πιστοποιητικό, Αίτηση, Άδεια, κλπ) Η υπηρεσία στο πλαίσιο της οποίας δημιουργείται και ανταλλάσσεται το έγγραφο Η πηγή πληροφοριών για το έγγραφο, π.χ. Φόρμα από site των ΚΕΠ Η έκταση ή η εμβέλεια του περιεχομένου του εγγράφου, π.χ. Αρμόδιος Φορέας, ΚΕΠ, Όλοι οι Φορείς Η φυσική ή ψηφιακή μορφή του πόρου, π.χ. pdf, doc, csv, κλπ 162

163 Μεταδεδομένα Καταγραφής Εγγράφου (ΙΙ) ΓΕΝΙΚΑ ΣΤΟΙΧΕΙΑ ΕΓΓΡΑΦΟΥ Γλώσσα Εγγράφου Δημιουργός Εγγράφου Εκδότης Εγγράφου Κοινό Εγγράφου Αποδέκτης Εγγράφου Ημερομηνία Έκδοσης / Τελευταίας Ενημέρωσης Νομικό Πλαίσιο Κατάσταση Εγγράφου Η γλώσσα του εγγράφου Ο Φορέας που δημιουργεί το έγγραφο Ο Φορέας που καθιστά το έγγραφο διαθέσιμο Ο Φορέας / άτομο που υποβάλλει το έγγραφο Ο Φορέας που παραλαμβάνει το έγγραφο Η ημερομηνία επίσημης έκδοσης / τελευταίας ενημέρωσης του εγγράφου Το Προεδρικό διάταγμα ή άλλος νόμος που επιτρέπει την συγκέντρωση πληροφορίας και δημιουργία του εγγράφου Η κατάσταση του εγγράφου (π.χ. ενεργό) 163

164 Μεταδεδομένα Καταγραφής Εγγράφου (ΙΙΙ) ΑΝΑΛΥΤΙΚΑ ΣΤΟΙΧΕΙΑ ΠΕΡΙΓΡΑΦΗΣ ΓΙΑ ΚΑΘΕ ΠΕΔΙΟ ΤΟΥ ΕΓΓΡΑΦΟΥ Όνομα Πεδίου Περιγραφή Πεδίου Κατηγορία Πεδίου Συμπληρώνεται από Υποχρεωτικό Το όνομα του πεδίου Μια συνοπτική περιγραφή του πεδίου Η κατηγορία / ομαδοποίηση στην οποία μπορεί να ανήκει το πεδίο Ποιος από τους Φορείς ανάμεσα στους οποίους ανταλλάσσεται το έγγραφο συμπληρώνει το πεδίο Εάν το πεδίο είναι υποχρεωτικό 164

165 Μεταδεδομένα Καταγραφής Εγγράφου (ΙV) ΑΝΑΛΥΤΙΚΑ ΣΤΟΙΧΕΙΑ ΠΕΡΙΓΡΑΦΗΣ ΓΙΑ ΚΑΘΕ ΠΕΔΙΟ ΤΟΥ ΕΓΓΡΑΦΟΥ Σύνθετο Πολλαπλές Τιμές Προκαθορισμένες Τιμές Τύπος Πεδίου Μέγεθος Πεδίου Εάν το πεδίο είναι σύνθετο, δηλαδή αποτελείται από άλλα επιμέρους πεδία Εάν το πεδίο παίρνει περισσότερες από μια τιμές κάθε φορά Η προκαθορισμένη τιμή (τιμές) του πεδίου εάν υπάρχει Ο τύπος του πεδίου (π.χ. ακέραιος, γραμματοσειρά) Το μέγεθος του πεδίου (π.χ. εάν είναι αλφαριθμητικό ο αριθμός των χαρακτήρων) 165

166 Καταγραφή Μεταδεδομένων Εγγράφων DEMO στο Ληξιαρχείο Διαλειτουργικότητας 166

167 KY.31 Αρθρωτό Μοντέλο Σχεδίασης XML Σχημάτων Τα XML Σχήματα ΠΡΕΠΕΙ ΝΑ συμμορφώνονται στο Αρθρωτό Μοντέλο του Σχήματος Πηγή: UN/CEFACT XML Naming and Design Rules, Version 2.0 (February 2006) 167

168 Γενική Δομή ενός XML Σχήματος XML Declaration Schema Module Identification and Copyright Information Schema Start-Tag Includes Imports Element Root Element Global Elements Type Definitions 168

169 Οδηγίες για τα Γενικά Στοιχεία και τους Τύπους Δεδομένων (Ι) KY.103 KY.104 Η ιδιότητα id του στοιχείου schema ΘΑ ΠΡΕΠΕΙ ΝΑ χρησιμοποιείται για να αναγνωρίζει την ταυτότητα του σχήματος και η τιμή της ΠΡΕΠΕΙ ΝΑ είναι ίδια με την τιμή του στοιχείου Identifier του Καταλόγου Σχημάτων του ΠΗΔ μόλις εκδοθεί Η ιδιότητα elementformdefault ΠΡΕΠΕΙ ΝΑ παίρνει την τιμή qualified ενώ η ιδιότητα attributeformdefault ΠΡΕΠΕΙ ΝΑ παίρνει την τιμή unqualified. Παράδειγμα: <xs:schema xmlns:xs=" xmlns:ccts="urn:un:unece:uncefact:documentation:standard:corecomponentstechnicalspe cification:2" xmlns:udt="gr:ypes:egif:data:draft:unqualifieddatatype:1" xmlns:ram="gr:ypes:egif:data:draft:reusableaggregatebusinessinformationentity:1" xmlns:qdt="gr:ypes:egif:data:draft:qualifieddatatype:1" xmlns:rsm="gr:ypes:egif:data:draft:identitycard:1" targetnamespace="gr:ypes:egif:data:draft:identitycard:1" elementformdefault="qualified" attributeformdefault="unqualified" version="1-0" id="el "> 169

170 Οδηγίες για τα Γενικά Στοιχεία και τους Τύπους Δεδομένων (ΙΙ) KY.105 Τα σχήματα ΠΡΕΠΕΙ ΝΑ σχεδιάζονται με βάση τη λογική ότι τα στοιχεία (elements) περιέχουν την κύρια πληροφορία. Οι ιδιότητες (attributes) προορίζονται για την αποθήκευση δευτερευόντων μεταδεδομένων απλά παρέχουν περισσότερες πληροφορίες για το περιεχόμενο του στοιχείου. Παραδείγματα: <DateOfBirth VerifiedBy="Πιστοποιητικό Γέννησης"> </DateOfBirth> <DateOfBirth VerifiedBy="Πιστοποιητικό Γέννησης ValueSet="ISO 8601 Code="2"> </DateOfBirth> ΛΑΘΟΣ <DateOfBirth> <VerifiedBy Code="2">Πιστοποιητικό Γέννησης</VerifiedBy> <Value ValueSet="ISO 8601"> </Value> </DateOfBirth> 170

171 Οδηγίες για τα Γενικά Στοιχεία και τους Τύπους Δεδομένων (ΙΙΙ) KY.106 Η απουσία μιας δομής ΔΕΝ ΠΡΕΠΕΙ ΝΑ έχει κάποια ιδιαίτερη σημασία. Οι εναλλακτικές περιπτώσεις ΘΑ ΠΡΕΠΕΙ ΝΑ αποδίδονται με τιμές σε στοιχεία ή ιδιότητες και να μην εξαρτώνται από την παρουσία ή την απουσία ενός στοιχείου. KY.122 Η δήλωση xsd:import ΔΕΝ ΠΡΕΠΕΙ ΝΑ πραγματοποιείται χωρίς την ιδιότητα namespace που δηλώνει το χώρο ονομάτων του εισαγόμενου σχήματος. Παράδειγμα: <xs:import namespace="gr:ypes:egif:data:draft:reusableaggregatebusinessinformatione ntity:1" schemalocation="..\παράρτημα Δ - BIE\eGIF_ReusableAggregateBusinessInformationEntity-v1-0.xsd"/> KY.123 Στην τεκμηρίωση ενός XML Σχήματος, το στοιχείο documentation ΘΑ ΠΡΕΠΕΙ ΝΑ χρησιμοποιείται αντί για σχόλια XML. 171

172 Οδηγίες για τα Γενικά Στοιχεία και τους Τύπους Δεδομένων (ΙV) KY.121 Τα στοιχεία στα έγγραφα XML μπορούν να διαχωριστούν σε δύο κατηγορίες: Τα κειμενο-κεντρικά, όπως τα στοιχεία που εμφανίζονται σε μια αναφορά ως απάντηση σε μια ερώτηση Τα δεδομενο-κεντρικά, όπως τα στοιχεία σε ένα πιστοποιητικό γέννησης Σε κάθε περίπτωση, η ανάμιξη περιεχομένου, δηλαδή η ύπαρξη ενός στοιχείου που περιέχει άλλα στοιχεία και κείμενο, ΘΑ ΠΡΕΠΕΙ ΝΑ αποφεύγεται. Παραδείγματα: <Paragraph>Αυτό είναι ένα παράδειγμα κειμενο-κεντρικού στοιχείου <Emphasize>mixed</Emphasize> content model in a text-centric document, and is acceptable.</paragraph> <DateOfBirth VerifiedBy=Πιστοποιητικό γέννησης> </dateofbirth> <DateOfBirth> <VerifiedBy>Πιστοποιητικό γέννησης </VerifiedBy> </DateOfBirth> 172

173 Οδηγίες για τα Γενικά Στοιχεία και τους Τύπους Δεδομένων (V) KY.113 KY.114 KY.115 KY.116 KY.118 KY.119 Όλες οι δηλώσεις τύπων ΠΡΕΠΕΙ ΝΑ έχουν όνομα και να αποφεύγεται η επανάληψη τύπων με την ίδια σημασιολογία και παρόμοιους περιορισμούς. Οι απλοί τύποι xsd:simpletypes ΠΡΕΠΕΙ ΝΑ χρησιμοποιούνται εφόσον ικανοποιούν τις απαιτήσεις του χρήστη. Εάν αυτό δε συμβαίνει ΠΡΕΠΕΙ ΝΑ χρησιμοποιούνται σύνθετοι τύποι xsd:complextypes. Οι σύνθετοι τύποι xsd:complextypes ΠΡΕΠΕΙ ΝΑ χρησιμοποιούνται για τον ορισμό των ABIEs. Οι δηλώσεις τύπων στα ΒΒΙΕ ΠΡΕΠΕΙ ΝΑ περιέχεται στα udt:unqualifieddatatype ή qdt:qualifieddatatype. Το xsd:extension ΠΡΕΠΕΙ ΝΑ χρησιμοποιείται μόνο στα cct:corecomponenttype και udt:unqualifieddatatype schema modules για να δηλώνει xsd:attributes για σχετικά συμπληρωματικά στοιχεία. Όταν το xsd:restriction εφαρμόζεται σε ένα xsd:simpletype ή xsd:complextype που αναπαριστά ένα τύπο δεδομένων, η δομή που δημιουργείται ΠΡΕΠΕΙ ΝΑ έχει διαφορετικό όνομα. π.χ. <xsd:simpletype name="taxamounttype"> <xsd:restriction base="udt:amounttype"> <xsd:totaldigits value="10"/> <xsd:fractiondigits value="3"/> </xsd:restriction> </xsd:simpletype> 173

174 Core Data Types KY.117 Η σύνδεση ανάμεσα στους «όρους αναπαράστασης» (Representation Terms) της προδιαγραφής UN/CEFACT CCTS και των ισοδύναμων τύπων δεδομένων που δηλώνονται στα CCT schema module και UDT schema module ΠΡΕΠΕΙ ΝΑ συμμορφώνεται στα: Amount Indicator Ratio Binary Object Measure Sound Code Name Text Date Numeric Time Date Time Percent Value Duration Picture Video Graphic Quantity Identifier Rate 174

175 Εγκεκριμένα CodeLists και IdentifierLists KY.86 KY.87 Τα Κωδικολόγια τα οποία έχουν ενσωματωθεί στο ΠΗΔ κατά την έκδοση του παρόντος εγγράφου και στα οποία ΠΡΕΠΕΙ ΝΑ συμμορφώνονται τα XML Σχήματα που σχεδιάζονται έχουν εκδοθεί από διεθνείς οργανισμούς, όπως ISO (International Standardization Organization), UN/CEFACT και IANA (Internet Assigned Numbers Authority) και είναι: ISO για κωδικούς χωρών (country code list) ISO-4217 για κωδικούς νομισμάτων (currency code list) ISO για κωδικούς γλωσσών (language code list) UNECE Units of Measure used in International Trade για μονάδες μέτρησης UNECE Character Set Encoding Code και ΙΑΝΑ Character Set Code για κωδικοποιήσεις χαρακτήρων UNECE Agency Identification Code για την κωδικοποίηση διεθνών Οργανισμών IANA MIME Media Type για τους μορφότυπους Η ενσωμάτωση Κωδικολογίων που έχουν δημιουργηθεί στο πλαίσιο διαφόρων έργων στην Ελληνική Δημόσια Διοίκηση ΠΡΕΠΕΙ ΝΑ πραγματοποιείται εφόσον περάσουν τη Διαδικασία Έγκρισης και Ενσωμάτωσης στο ΠΗΔ. 175

176 Χώροι Ονομάτων KY.99, KY.100 KY.101 Κάθε σχήμα ΠΡΕΠΕΙ ΝΑ δηλώνει κατάλληλα το χώρο ονομάτων του (namespace) στην ιδιότητα xsd:targetnamespace. Κάθε default namespace ΠΡΕΠΕΙ ΝΑ ταυτίζεται με το target namespace. Οι χώροι ονομάτων στο ΠΗΔ ΠΡΕΠΕΙ ΝΑ συμμορφώνονται στη σύσταση του W3C Namespaces in XML (Second Edition). Οι χώροι ονομάτων στο ΠΗΔ ΠΡΕΠΕΙ ΝΑ ορίζονται ως URNs (Uniform Resource Names), σύμφωνα με τη δομή urn:<1ο Επίπεδο>:<2ο Επίπεδο><3ο Επίπεδο><4ο Επίπεδο><5ο Επίπεδο><6ο Επίπεδο><7ο Επίπεδο> Παραδείγματα: gr:ypes:egif:data:draft:identity Card:1 gr:ypes:egif:data:draft:reusable AggregateBusinessInformation Entity:1 KY.102 Εναλλακτικά, οι χώροι ονομάτων στο ΠΗΔ μπορούν να ορίζονται ως URLs (Uniform Resource Locators). Στην περίπτωση αυτή, το URI θα πρέπει να έχει τη μορφή schema title 176

177 KY.131 Συμβάσεις Ονοματολογίας (Ι) KY.125 KY.126 KY.127 KY.124 KY.130 Όλα τα ονόματα (tags) στα XML Σχήματα, καθώς και το περιεχόμενο των Καταλόγων Σχημάτων, ΠΡΕΠΕΙ ΝΑ συνίστανται από λέξεις στην αγγλική γλώσσα που θα αποτελούν μεταφράσεις των αντίστοιχων ελληνικών όρων. Το περιεχόμενο των στοιχείων και των ιδιοτήτων στα XML αρχεία ΠΡΕΠΕΙ ΝΑ είναι στην ελληνική γλώσσα. Το περιεχόμενο των μεταδεδομένων των Core Components ΠΡΕΠΕΙ ΝΑ είναι στην αγγλική γλώσσα. Το όνομα κάθε στοιχείου (element) ή χαρακτηριστικού (attribute) ΘΑ ΠΡΕΠΕΙ ΝΑ καθορίζεται κατά μοναδικό τρόπο από ένα πλήρες μονοπάτι XPath. Τα ονόματα στοιχείων, χαρακτηριστικών και τύπων ΠΡΕΠΕΙ ΝΑ χρησιμοποιούν το ακόλουθο σετ χαρακτήρων: Α-Ζ και a-z. Γενικά, Τα ονόματα στοιχείων, χαρακτηριστικών και τύπων των XML Σχημάτων ΔΕΝ ΘΑ ΠΡΕΠΕΙ ΝΑ περιέχουν κενά, διαχωριστικά ή χαρακτήρες που δεν επιτρέπονται με βάση την προδιαγραφή W3C XML 1.0 για την ονοματοδοσία 177

178 Συμβάσεις Ονοματολογίας (ΙΙ) KY.128 Για την ονοματοδοσία των χαρακτηριστικών των XML Σχημάτων και των ονομάτων των Μεταδεδομένων ΠΡΕΠΕΙ ΝΑ χρησιμοποιείται η σύμβαση Lower Camel Case (LCC), που απαιτεί κεφαλαίο γράμμα κάθε λέξης εκτός από την πρώτη για να συνθέσει το όνομα. Για την ονοματοδοσία των στοιχείων και των τύπων των XML Σχημάτων ΘΑ ΠΡΕΠΕΙ ΝΑ χρησιμοποιείται η σύμβαση Upper Camel Case (UCC), που απαιτεί κεφαλαίο γράμμα κάθε λέξης για να συνθέσει το όνομα. π.χ. <xsd:attribute name="unitcode".../> <xsd:element name="languagecode"...> <xsd:complextype name="despatchadvicecodetype"> KY.129 Τα ονόματα ΘΑ ΠΡΕΠΕΙ ΝΑ είναι στον ενικό, εκτός από τις περιπτώσεις όπου η έννοια που μοντελοποιείται βρίσκεται στον πληθυντικό. 178

179 Διαχείριση Εκδόσεων των XML Σχημάτων KY.133 KY.134 π.χ. KY.135 KY.136 Τα αρχεία Σχημάτων (schema modules), πλην των Κωδικολογίων (Code List Modules) και των Λιστών Αναγνωριστικών (Identifier Lists) ΠΡΕΠΕΙ ΝΑ υποδεικνύουν την πλήρη έκδοσή τους στο όνομα του αρχείου ως <filename>-vn-m.xsd όπου n και m είναι η μείζονα και η δευτερεύουσα έκδοση αντίστοιχα και v είναι ο λατινικός χαρακτήρας v Τα schema module αρχεία με Κωδικολόγια (Code List Modules) και Λίστες Αναγνωριστικών (Identifier Lists) ΠΡΕΠΕΙ ΝΑ υποδεικνύουν την πλήρη έκδοσή τους στο όνομα του αρχείου ως <AgencyName>_<filename>-vn-m.xsd IdentityCard-v1-0 ISO_CountryCodeList-v1-0 Πού χρησιμοποιούνται?? Τα XML Σχήματα ΠΡΕΠΕΙ ΝΑ υποδεικνύουν την έκδοσή τους στην ιδιότητα version του στοιχείου xs:schema Τα αρχεία XML που ανταλλάσσονται ΠΡΕΠΕΙ ΝΑ περιέχουν αναφορά στην έκδοση του XML Σχήματος στο οποίο συμμορφώνονται. 179

180 Νέες εκδόσεις των XML Σχημάτων: Πότε? Μια νέα μείζονα έκδοση δημιουργείται όταν συμβαίνουν αξιοσημείωτες και / ή μη συμβατές προς τα πίσω αλλαγές, όπως : Διαγραφή ή τροποποίηση τιμών σε λίστες απαρίθμησης Αλλαγή των ονομάτων των στοιχείων, των χαρακτηριστικών και των τύπων Τροποποίηση των δομών δεδομένων που χρησιμοποιούνται Απαλοιφή ή προσθήκη υποχρεωτικών στοιχείων ή χαρακτηριστικών Αλλαγή της πολυπλοκότητας στοιχείων από υποχρεωτική σε προαιρετική Σε μια δευτερεύουσα έκδοση ενός XML Σχήματος περιέχεται μια σειρά από μικρές ή συμβατές προς τα πίσω αλλαγές. Περιορίζονται σε: Δήλωση νέων προαιρετικών δομών δεδομένων Επέκταση υπαρχόντων δομών Επαναδιατύπωση προαιρετικής φύσεως 180

181 Διαδικασία Δημιουργίας νέου XML Σχήματος 181

182 Σημεία-Κλειδιά κατά τη Σχεδίαση XML Σχημάτων KY KΠ KY KY KY KY KY Κάθε έγγραφο ΠΡΕΠΕΙ ΝΑ προέρχεται από κάποιο Aggregate Core Component, συνήθως από το ACC Document ή ACC Query ή ACC Response, και να μοντελοποιείται σαν Aggregate Business Information Entity με τη διαφορά ότι θα τοποθετείται ως root schema στο XML Σχήμα στο οποίο συμμορφώνεται. Με στόχο την κατά το δυνατόν μεγαλύτερη επαναχρησιμοποίηση των ABIE, η όποια απαίτηση για υποχρεωτικά πεδία στα ΑΒΙΕ ΣΥΝΙΣΤΑΤΑΙ ΝΑ «χαλαρώνει» στο ελάχιστο σύνολο πεδίων που μπορούν να εμφανιστούν σε παραπάνω από μια περιστάσεις. Κάθε ΑΒΙΕ ΠΡΕΠΕΙ ΝΑ δηλώνει το πλαίσιο στο οποίο χρησιμοποιείται, δηλαδή τον οργανισμό, την υπηρεσία ή την τοποθεσία στα οποία υπάγεται... Ένα ΑΒΙΕ ΔΕΝ ΠΡΕΠΕΙ ΝΑ περιέχει υποχρεωτικά ASBIE που το συνδέουν με τον εαυτό του, ώστε να μην δημιουργούνται loops που ενδέχεται να μην κλείνουν ποτέ. Το Property Term κάθε BBIE και ASBIE ΠΡΕΠΕΙ ΝΑ ταυτίζεται με το Property Term του αντίστοιχου BCC και ASCC από το οποίο προέρχεται. Σε περιπτώσεις όπου μοντελοποιείται η ίδια έννοια, τα Property Term Qualifiers ΠΡΕΠΕΙ ΝΑ συμφωνούν μεταξύ των ABIE. Οι τύποι δεδομένων ΠΡΕΠΕΙ ΝΑ εξειδικεύονται όσο είναι δυνατόν με τη δημιουργία qualified data types που ορίζουν ακριβώς το μέγεθος, το pattern, την περιοχή τιμών ή τις προκαθορισμένες τιμές. 182

183 XML Σχήματα και Web Services KΠ Τα XML Σχήματα που εισάγονται μέσω του <xs:import> ΠΡΟΤΕΙΝΕΤΑΙ ΝΑ ανακτώνται από το Διαδίκτυο μόλις ανοίξει το αρχείο για τα κωδικολόγια και μελλοντικά (μόλις δημοσιευτούν στο Ληξιαρχείο Διαλειτουργικότητας) και για τα Reusable Aggregate Business Information Entities, Qualified Data Type, Unqualified Data Type. 183

184 Δημιουργία ενός XML Σχήματος με βάση τις Προδιαγραφές του Πλαισίου DEMO στο Altova XMLSpy 184

185 Διαδικασία Τροποποίησης XML Σχήματος, ΒΙΕ ή CC 185

186 Επίπεδα Προσαρμογής XML Σχημάτων KM.4 Τα σενάρια για την προσαρμογή των XML Σχημάτων του ΠΗΔ ΜΕΛΕΤΑΤΑΙ ΝΑ διακρίνονται σε τρία επίπεδα: Προσαρμογή Απόλυτα Συμβατή με το ΠΗΔ, όπου οι όποιες αλλαγές στα XML Σχήματα γίνονται εφαρμόζοντας κατά γράμμα τις οδηγίες του ΠΗΔ. Προσαρμογή Μερικώς (ή ελάχιστα) Συμβατή με το ΠΗΔ, όπου τα υπό σχεδίαση Σχήματα χρησιμοποιούν τα Σχήματα του ΠΗΔ, αλλά οι αλλαγές σε αυτά δημιουργούν πρόβλημα συμβατότητας με το ΠΗΔ. Προσαρμογή Συμβατή με τα Δομικά Στοιχεία (Core Components) του ΠΗΔ, διότι δεν υπάρχει πρότυπο XML Σχήμα στο Ληξιαρχείο Διαλειτουργικότητας για τα υπό σχεδίαση XML Σχήματα. Σε αυτήν την περίπτωση, τα Σχήματα θα βασιστούν στα Core Components του ΠΗΔ. 186

187 Τι σημαίνει πρακτικά η προσαρμογή των XML Σχημάτων? KY KY KY KΠ KΠ KY Κάθε τροποποιημένο Σχήμα ΠΡΕΠΕΙ ΝΑ έχει διαφορετικό χώρο ονομάτων (namespace) σε σχέση με το αρχικό Σχήμα. Το πλαίσιο (context) για την τροποποίηση ΘΑ ΠΡΕΠΕΙ ΝΑ ορίζεται ρητά. Στην περίπτωση που η τροποποίηση που γίνεται δεν μπορεί να ενταχθεί σε συγκεκριμένο πλαίσιο οργανισμού, υπηρεσίας ή γεωγραφικής τοποθεσίας, τότε ΠΡΕΠΕΙ ΝΑ δημιουργείται ένα στοιχείο <Context> που επεξηγεί πού αποσκοπεί η τροποποίηση. ΔΕΝ ΘΑ ΠΡΕΠΕΙ ΝΑ διαγράφονται υποχρεωτικά πεδία, δηλαδή να μειώνεται η πολυπλοκότητα ενός BBIE ή ASBIE από x..y σε 0..y Ο αριθμός μέγιστων εμφανίσεων ενός υποχρεωτικού ή μη στοιχείου, αλλάζοντας την πολυπλοκότητά του από σε ΔΥΝΑΤΑΙ ΝΑ μειωθεί. Ένα προαιρετικό πεδίο αλλάζοντας την πολυπλοκότητα από 0..1 σε 0..0 ΔΥΝΑΤΑΙ ΝΑ διαγραφεί. To ΧΜL αρχείο ΠΡΟΤΕΙΝΕΤΑΙ ΝΑ χρησιμοποιεί την ιδιότητα xsi:type για να δηλώσει ότι ένας τροποποιημένος (derived) τύπος δεδομένων χρησιμοποιείται. 187

188 Τι σημαίνει πρακτικά η προσαρμογή των XML Σχημάτων? KY Η επαναδιατύπωση ενός τύπου μέσω του xsd:redefine ΔΕΝ ΠΡΕΠΕΙ ΝΑ πραγματοποιείται διότι δεν δείχνει τι επαναχρησιμοποιείται και ενέχει τον κίνδυνο κυκλικών επαναδιατυπώσεων τύπων. KY Η επέκταση ενός τύπου μέσω του xsd:extension ΠΡΕΠΕΙ ΝΑ χρησιμοποιείται μόνο στα cct:corecomponenttype και udt:unqualifieddatatype schema modules για να δηλώνει xsd:attributes για σχετικά συμπληρωματικά στοιχεία. KY Όταν το xsd:restriction εφαρμόζεται σε ένα xsd:simpletype ή xsd:complextype που αναπαριστά ένα τύπο δεδομένων, η δομή που δημιουργείται ΠΡΕΠΕΙ ΝΑ έχει διαφορετικό όνομα. KY Οι τροποποιημένοι τύποι δεδομένων ΠΡΕΠΕΙ ΝΑ να χρησιμοποιούνται όπου χρησιμοποιούνταν οι αρχικοί τύποι δεδομένων, για παράδειγμα ο τύπος δεδομένων qdt:yeardatetype μπορεί να χρησιμοποιηθεί όπου εμφανιζόταν ο τύπος udt:datetimetype 188

189 Κανόνας μοναδικής τροποποίησης ανά πλαίσιο (Once-per-Context) KY Σε μια αλυσίδα τροποποιήσεων που εξειδικεύουν ένα XML Schema ή ένα ABIE, το ίδιο context ΔΕΝ ΘΑ ΠΡΕΠΕΙ να εμφανίζεται παραπάνω από μια φορά, εκτός εάν είναι για να εξειδικευτεί περαιτέρω (και όχι να επαναπροσδιοριστεί). 189

190 Πώς διασφαλίζεται η συμβατότητα με υπάρχοντα XML Σχήματα? KY.137 Τα XML Σχήματα που δεν συμμορφώνονται στις προδιαγραφές του παρόντος εγγράφου ΘΑ ΠΡΕΠΕΙ ΝΑ μπορούν να μετασχηματίζονται με βάση τη σύσταση του W3C XSL Transformations (XSLT) στα προτεινόμενα XML σχήματα του ΠΗΔ. 190

191 Επίπεδα Ωριμότητας XML Σχημάτων του ΠΗΔ 191

192 Η έννοια των Μεταδεδομένων στο ΠΗΔ 6

193 Το πρόβλημα... Οι οργανισμοί έχουν πληροφορία που αξίζει εκατομμύρια αλλά δεν μπορούν να την διαθέσουν στους σωστούς ανθρώπους, DM Direct Special Report, 2006 Οι χρήστες χρειάζονται την πληροφορία απλά και γρήγορα αλλά ικανοποιούνται μόλις μια φορά στις επτά, Delphi Group, 2006 Οι εργαζόμενοι ψάχνουν για πληροφορία περίπου 2,5 ώρες τη μέρα με ποσοστό επιτυχίας περίπου 40%. Δημιουργούν ξανά υπάρχον υλικό πιο συχνά απ ότι δημιουργούν νέο, Kit Sims Taylor, Eίναι πολύ σημαντικό η εξωτερική πληροφορία να είναι εύκολα προσβάσιμη! Πώς? Με τη βοήθεια των Μεταδεδομένων

194 Τι είναι μεταδεδομένα? Φανταστείτε ένα supermarket... Με προϊόντα χωρίς ετικέτες? Χωρίς σήματα και κατευθύνσεις? Χωρίς προωθητικές προβολές? title supplemental information abstract Πηγή CSC Brands time period author sources (file) size Φανταστείτε μια βιβλιοθήκη... Χωρίς τίτλους στα βιβλία? Χωρίς ράφια ταξινομημένα ανά θέμα? Τώρα φανταστείτε την πληροφορία στον Παγκόσμιο Ιστό

195 Τι είναι μεταδεδομένα? Τα μεταδεδομένα είναι δομημένη πληροφορία που περιγράφει χαρακτηριστικά οντοτήτων που φέρουν πληροφορία ώστε να βοηθήσει στην αναγνώριση, ανακάλυψη, αξιολόγηση και διαχείριση τους Αφορούν οποιαδήποτε πηγή πληροφοριών, από ηλεκτρονικό και χειρόγραφο έγγραφο, βάση δεδομένων μέχρι ιστοσελίδα, και δείχνουν τι αφορά και πώς είναι προσπελάσιμη (περιεχόμενο περιβάλλον δομή) Όταν δομηθούν ιεραρχικά, δημιουργούν μια οντολογία ή σχήμα μεταδεδομένων Συχνά αποθηκεύονται σε μια κεντρική τοποθεσία (Metadata Registry) ώστε να βοηθήσουν τους διάφορους οργανισμούς να οργανώσουν τα δεδομένα τους 195

196 Κρίσιμα Ζητήματα στα Μεταδεδομένα Διαχείριση Μεταδεδομένων: Τα μεταδεδομένα πρέπει να ενημερώνονται εάν ο πόρος που περιγράφουν τροποποιείται «Καταστροφή» Πόρου: Τα μεταδεδομένα πρέπει να συνεχίσουν να τηρούνται ακόμη κι αν ο πόρος δεν είναι πλέον διαθέσιμος Αποθήκευση Μεταδεδομένων: Μπορεί να γίνεται είτε εσωτερικά στο ίδιο αρχείο με τον πόρο ή εξωτερικά σε μια βάση δεδομένων Μορφότυπος Αποθήκευσης Μεταδεδομένων: Μπορεί να είναι είτε XML, RDF/ΧΜL ή σε δυαδική μορφή για λόγους ταχύτητας και εξοικονόμησης μνήμης 196

197 Οφέλη από τα μεταδεδομένα Καλύτερη πληροφόρηση που οδηγεί σε καλύτερες αποφάσεις στο δημόσιο τομέα Διευκολύνση των διαδικτυακών μηχανών αναζήτησης στην κατηγοριοποίηση και indexing του περιεχομένου και βελτίωση της αποτελεσματικότητας τους Ενοποίηση και επαναχρησιμοποίηση αντί για επαναδημιουργία της δημόσιας πληροφορίας (The Stone Soup Example) Προσωποποίηση και προσαρμογή της πληροφορίας ανάλογα με το κοινό στο οποίο απευθύνεται Εύκολη διαχείριση και σαφήνεια ακόμη και σε αδόμητο περιεχόμενο εφόσον διαθέτει μεταδεδομένα Αναγνώριση περιεχομένου που δεν έχει ενημερωθεί, που είναι απαρχαιωμένο ή που η χρήση του περιορίζεται από πνευματικά δικαιώματα Aggregation περιεχομένου από πολλαπλές πηγές 197

198 Διεθνή Πρότυπα Μεταδεδομένων Dublin Core Metadata Initiative: Δημιουργήθηκε από ανοικτό, μη κερδοσκοπικό οργανισμό. Βρίσκεται στην έκδοση 1.1 (Ιανουάριος 2008). Χαρακτηρίζεται ως... lingua franca for metadata,... at a basic level (Milstead & Feldman, 1999) United Kingdom egovernment Metadata Standard (egms): Αναπτύχθηκε από το Cabinet Office στο Ηνωμένο Βασίλειο (Έκδοση 3.1 Αύγουστος 2006) Model Requirements for the Management of Electronic Records (MoReq), που δημοσιεύτηκε από το IDA το 2001 Managing Information Resources for e-government (MIReG), το οποίο αναπτύχθηκε από το IDABC σε συνεργασία με τη Δανία, το Ηνωμένο Βασίλειο, το Dublin Core Metadata Initiative και την ΕΕ 198

199 Μεταδεδομένα Πλαισίου για την Περιγραφή Πόρων (Ι) Κατηγορία Υποκατηγορία Προέλευση Τίτλος (Title) Εναλλακτικός Τίτλος (Alternative) Core (DC) Δημιουργός (Creator) - Core (DC) Θέμα (Subject) Πρόσωπο (Person), Πρόγραμμα (Programme), Έργο (Project) Core (DC) Περιγραφή (Description) Περίληψη (Abstract), Πίνακας Περιεχομένων (Table of contents) Core (DC) Εκδότης (Publisher) - Core (DC) Συντελεστής (Contributor) - Core (DC) Ημερομηνία (Date) Απόκτησης (Acquired), Διαθεσιμότητας (Available), Δημιουργίας Core (DC) (Created), Κλειδώματος (Cut off), Αποδοχής (Date accepted), Κατοχής Δικαιωμάτων copyright (Date copyrighted), Υποβολής (Date submitted), Έκδοσης (Issued), Τροποποίησης (Modified), Επόμενης έκδοσης (Next version due), Συχνότητα τροποποίησης (Updating frequency), Εγκυρότητας (valid) Τύπος (Type) - Core (DC) Μορφότυπος (Format) Μέγεθος (Extent), Μέσο (Medium) Core (DC) Αναγνωριστικό (Identifier) - Core (DC) Πηγή (Source) - Core (DC) Γλώσσα (Language) - Core (DC) 199

200 Μεταδεδομένα Πλαισίου για την Περιγραφή Πόρων (ΙΙ) Κατηγορία Υποκατηγορία Προέλευση Σχέση (Relation) Συμμορφώνεται με (Conforms to), Έκδοση (Has version), Είναι έκδοση του (Is version of), Μορφότυπος (Is format of), Έχει μέρος του (Has part), Εϊναι μέρος (Is part of), Απαιτεί (Requires), Απαιτείται από (Is required by), Αντικαθιστά (Replaces), Αντικαθιστάται από (Is replaced by), Παρέχει ορισμό του (Provides definition of), Αναφέρει (References), Αναφέρεται από (Is Core (DC) referenced by) Εμβέλεια (Coverage) Χωρική (Spatial), Χρονική (Temporal) Core (DC) Δικαιώματα Χρήσης (Rights) Προσβασιμότητα Πνευματικά Δικαιώματα (Copyright), Διαχειριστής (Custodian), Περιγραφή (Descriptor), Πρόσβαση σε ομάδες (Group access), Λίστα πρόσβασης ατομικών χρηστών (Individual user access list), Επίπεδο ασφάλειας (Protective marking), Ημερομηνία εκπνοής δικαιωμάτων (Protective marking expiry date) Υποχρεωτικό, εάν βρίσκει εφαρμογή Core (DC) (Accessibility) Αποδέκτης (Addressee) Προαιρετικό egms Κατηγορία (Aggregation) Προαιρετικό egms egms 200

201 Μεταδεδομένα Πλαισίου για την Περιγραφή Πόρων (ΙΙΙ) Κατηγορία Υποκατηγορία Προέλευση Κοινό (Audience) Ψηφιακή Υπογραφή (Digital Signature) Απαλλαγή (Disposal) Mορφωτικό Επίπεδο (Education Level), Ενδιάμεσος Μεσολαβητής (Mediator) Προαιρετικό Ημερομηνία αυτόματης διαγραφής (Auto remove date), Δράση απαλλαγής (Disposal action), Απαλλαγή εξουσιοδοτημένη από (Disposal authorized by), Σχόλιο (Disposal comment), Συνθήκες (Disposal conditions), Ημερομηνία απαλλαγής (Disposal date), Προορισμός εξαγωγής (Disposal export destination), Κατάσταση εξαγωγής (Disposal export), Ενδιάμεση περίοδος απαλλαγής (Disposal time period) Τοποθεσία (Location) Προσωρινή τοποθεσία (Current location), Έδρα (Home location) egms Νομοθετικό Πλαίσιο Νόμος (Authorising statute), Σκοπός απόκτησης προσωπικών (Mandate) δεδομένων (personal data acquisition purpose) Συντήρηση (Preservation) Αρχικός μορφότυπος (Original format) egms Κατάσταση (State) Προαιρετικό egms egms egms egms egms 201

202 Αναπαράσταση Μεταδεδομένων Πλαισίου: Πώς? KY.144 KΠ.11 KY.145 KΠ.12 Τα μεταδεδομένα του ΠΗΔ ΠΡΕΠΕΙ ΝΑ εκφράζονται σε RDF/XML (the Resource Description Framework using extensable Markup Language), σύμφωνα με τις τρέχουσες συστάσεις του W3C και του Dublin Core Metadata Initiative. Για λόγους γρήγορης πρωτοτυποποίησης (prototyping), η περιγραφή των μεταδεδομένων ΠΡΟΤΕΙΝΕΤΑΙ εναλλακτικά ΝΑ να γίνεται σε οποιοδήποτε normal tabular form εργαλείο όπως το Microsoft EXCEL. Στην περίπτωση που ένα μεταδεδομένο μπορεί να πάρει παραπάνω από μια τιμές, τότε το στοιχείο (element) που το περιγράφει ΠΡΕΠΕΙ ΝΑ επαναληφθεί τόσες φορές όσες οι διαφορετικές τιμές σε μια HTML επικεφαλίδα. Εφόσον πρόκειται για διαδικτυακή σελίδα, τα μεταδεδομένα ΣΥΝΙΣΤΑΤΑΙ ΝΑ ενσωματώνονται και στην επικεφαλίδα των HTML αρχείων. Παραδείγματα: <meta name= DC.description content= Η περιγραφή των στοιχείων, των ορισμών και της δομής για τα μεταδεδομένα του Δημόσιου Τομέα /> <meta name= egms.mandate.authorisingstatute content= Νόμος ΧΧ-1998 /> 202

203 Αναπαράσταση Μεταδεδομένων Πλαισίου: Πώς? KY.149 Τα μεταδεδομένα του ΠΗΔ που προέρχονται από το Dublin Core ΠΡΕΠΕΙ ΝΑ έχουν το όνομα element με πρόθεμα DC, ενώ τα υπόλοιπα το όνομα element με πρόθεμα egms. KY.150 Τα μεταδεδομένα για τα οποία καθορίζονται υπο-μεταδεδομένα ΠΡΕΠΕΙ ΝΑ έχουν το όνομα element.subelement με το ανάλογο πρόθεμα DC ή egms. Παραδείγματα: title με πρόθεμα DC state με πρόθεμα egms date.created με πρόθεμα DC mandate.authorisingstatute με πρόθεμα egms 203

204 Συμβάσεις Ονοματολογίας KY.146 KY.147 KY.148 KΠ.13 Τα ονόματα των Μεταδεδομένων (tags) στα αρχεία RDF, XML και τις επικεφαλίδες HTML ΠΡΕΠΕΙ ΝΑ συνίστανται από λέξεις στην αγγλική γλώσσα που θα αποτελούν μεταφράσεις των αντίστοιχων ελληνικών όρων. Στις υπόλοιπες περιπτώσεις, τα ονόματα των Μεταδεδομένων μπορούν να διατυπώνονται στην ελληνική γλώσσα. Το περιεχόμενο των μεταδεδομένων πλην των Core Components ΠΡΕΠΕΙ ΝΑ είναι στην ελληνική γλώσσα. Το περιεχόμενο των μεταδεδομένων των Core Components ΠΡΕΠΕΙ ΝΑ είναι στην αγγλική γλώσσα. Το περιεχόμενο των μεταδεδομένων ΔΥΝΑΤΑΙ ΝΑ διατυπώνεται και στην αγγλική γλώσσα, πλέον της ελληνικής. Ωστόσο... KY.151 Τα ονόματα των Μεταδεδομένων ΔΕΝ ΘΑ ΠΡΕΠΕΙ ΝΑ πάρουν κάποια τιμή που δεν προδιαγράφεται στην ενότητα

205 Πλαίσιο Resource Description Framework (RDF) Πρωτοεμφανίστηκε το 1997 και αποτελεί σύσταση του W3C από το 1999 Βρίσκει εφαρμογή στις περιπτώσεις όπου οι εφαρμογές καλούνται να επεξεργαστούν την πληροφορία, όχι μόνο να την δείξουν στους ανθρώπους Παρέχει ένα κοινό πλαίσιο για την έκφραση της πληροφορίας ώστε να μπορεί να ανταλλαχθεί μεταξύ εφαρμογών χωρίς να χάσει τη σημασία της Προορίζεται κυρίως για την αναπαράσταση μεταδεδομένων για πόρους Ιστού Βασίζεται στην ιδέα της δημιουργίας δηλώσεων για πόρους στη μορφή εκφράσεων τριπλετών: θέμα (subject) κατηγόρημα (predicate) αντικείμενο (object) Χρησιμοποιεί URIs για να αναγνωρίσει άτομα, είδη πραγμάτων, ιδιότητες, τιμές των ιδιοτήτων Οι δηλώσεις RDF μπορούν να απεικονιστούν και σε κατευθυνόμενο γράφο 205

206 Παράδειγμα Διατύπωσης Δήλωσης σε RDF Η σελίδα δημιουργήθηκε από το Εθνικό Μετσόβιο Πολυτεχνείο Ως URI για την σελίδα του παραδείγματος θα χρησιμοποιήσουμε το html link...άρα το πρώτο μέρος του statement γίνεται: ( ) Ο δημιουργός είναι το Εθνικό Μετσόβιο Πολυτεχνείο...άρα το τρίτο μέρος του statement γίνεται: ( Εθνικό Μετσόβιο Πολυτεχνείο ) Είναι συνηθισμένο στο RDF για συντομία να χρησιμοποιούνται namespaces, π.χ. dc: για Χρησιμοποιώντας το dc:creator, το statement γίνεται: ( dc:creator, Εθνικό Μετσόβιο Πολυτεχνείο ) όπου dc:

207 Παράδειγμα Δήλωσης σε RDF <rdf:rdf xmlns:rdf=" xmlns:dc=" <rdf:description rdf:about=" <dc:creator>ομάδα Έργου ΠΗΔ</dc:creator> <dc:title>μοντέλο Τεκμηρίωσης</dc:title> <dc:description>περιγράφει την τεκμηρίωση που απαιτείται για τη μοντελοποίηση διαδικασιών και εγγράφων (δεδομένων και μεταδεδομένων)</dc:description> <dc:date> </dc:date> </rdf:description> </rdf:rdf> 207

208 Μεταδεδομένα σε Ιστοσελίδες: Πώς? Ενσωματώνονται στις HTML σελίδες <HTML> <HEAD> <TITLE>Alphabetics</TITLE> <META NAME="DC.Title" CONTENT="Alphabetics"> <META NAME="DC.Creator" CONTENT="Hughes, Ronia"> <META NAME="DC.Date" CONTENT="1974"> <META NAME="DC.Type" CONTENT="Text.Poem"> <META NAME="DC.Format" CONTENT="(SCHEME=IMT) text/html"> <META NAME="DC.Identifier CONTENT=" </HEAD> <BODY>...</BODY> </HTML> 208

209 Παράδειγμα Αυτόματης Δημιουργίας Μεταδεδομένων σε RDF Τα αποτελέσματα του εργαλείου DC-dot* για την ιστοσελίδα σε RDF/ΧΜL <?xml version="1.0"?> <!DOCTYPE rdf:rdf SYSTEM " <rdf:rdf xmlns:rdf= xmlns:dc=" <rdf:description rdf:about=" <dc:title> Ελληνικό Πλαίσιο Υπηρεσιών Ηλεκτρονικής Διακυβέρνησης και Πρότυπα Διαλειτουργικότητας </dc:title> <dc:creator> Ελληνικό Πλαίσιο Διαλειτουργικότητας </dc:creator> <dc:subject> egsf; egif; egoverment; goverment; interoperability; framework; xml; egov </dc:subject> <dc:description> ΕΛΛΗΝΙΚΟ ΠΛΑΙΣΙΟ ΥΠΗΡΕΣΙΩΝ ΗΛΕΚΤΡΟΝΙΚΗΣ ΔΙΑΚΥΒΕΡΝΗΣΗΣ </dc:description> <dc:publisher> </dc:publisher> <dc:type> Text </dc:type> <dc:format> text/html; charset=utf-8 </dc:format> <dc:format> bytes </dc:format> </rdf:description> </rdf:rdf> * 209

210 Μεταδεδομένα σε Ιστοσελίδες: Γιατί? Machine2Machine Understanding Semantic Web Internet SMTP: exchange NNTP: NewsGroups FTP: File Transfer TelNet: Remote connection Army, Academia World Wide Web HTML, HTTP(S): hypertext JAVA: Διαδικτυακές Εφαρμογές The whole world but for you eyes only 210

211 Τι είναι ο Σημασιολογικός Ιστός? Ο Σημασιολογικός Ιστός στοχεύει στον εμπλουτισμό του Ιστού με σημασιολογική πληροφορία ώστε: τα δεδομένα να είναι κατανοητά σε επίπεδο μηχανής ώστε να διευκολύνεται η επεξεργασία και αναζήτησή τους. να υπάρχει κοινή ορολογία, οργάνωση και σημασιολογία στα δεδομένα που διακινούνται στον Ιστό, στο βαθμό που αυτό είναι εφικτό. να υπάρχει η ευελιξία σύνθεσης της σημασιολογικής πληροφορίας και δημιουργία νέας. Τεχνολογίες Σημασιολογικού Ιστού: RDF/OWL Ι have a dream for the Web [in which computers] become capable of analyzing all the data on the Web the content, links, and transactions between people and computers. A Semantic Web, which should make this possible, has yet to emerge, but when it does, the day-to-day mechanisms of trade, bureaucracy and our daily lives will be handled by machines talking to machines. The intelligent agents people have touted for ages will finally materialize. * από Tim Berners-Lee το

212 Τι θα αλλάξει με τον Σημασιολογικό Ιστό? Τίποτα για τη γεωργική εκμετάλλευση (farming)? Χρησιμοποιώ τον όρο γεωργία (agriculture) αντί για γεωργική εκμετάλλευση (farming), οπότε θα ψάξω γι αυτόν. 212

213 Τι θα αλλάξει με τον Σημασιολογικό Ιστό? Χρειάζομαι πληροφορίες για οχήματα... Ξέρω ότι τα λεωφορεία, τα αυτοκίνητα και τα φορτηγά είναι είδη οχημάτων, οπότε θα ψάξω και για αυτούς τους όρους μαζί με τον όρο οχήματα. 213

214 Τι θα αλλάξει με τον Σημασιολογικό Ιστό? Χρειάζομαι πληροφορίες για τη γεωργική εκμετάλλευση... OK, θα το κοιτάξω... Μήπως θα σε ενδιέφερε να ψάξω επίσης για δασοκομία, κτηνοτροφία? 214

215 Εισαγωγή στις Διαδικτυακές Υπηρεσίες και Προδιαγραφές του ΠΗΔ 7

216 Η πραγματικότητα σήμερα

217 Υπηρεσιοστρεφής Αρχιτεκτονική και Διαδικτυακές Υπηρεσίες Η λογική των Διαδικτυακών Υπηρεσιών, σχεδιασμένη γύρω από υπηρεσιοστρεφείς αρχιτεκτονικές (Serviceoriented Architectures - SOA), τυποποιημένα μοντέλα δοσοληψιών που στηρίζονται σε περιγραφές XML και προσβάσιμους καταλόγους UDDI, είναι πιθανό να αποτελέσει την πιο σημαντική τεχνολογική πρόοδο προς το 2008 Gartner Group, 3/

218 Υπηρεσιοστρεφής Αρχιτεκτονική (Service-oriented Architecture) Υποστηρίζει το σχεδιασμό των εφαρμογών με επίκεντρο τις υπηρεσίες Τι είναι οι υπηρεσίες? Αναπαραστάσεις πραγματικών προγραμμάτων, βάσεων δεδομένων ή διαδικασιών, που: καθορίζονται σε σχέση με το τι κάνουν, προσδιορίζονται στα πλαίσια μηνυμάτων που ανταλλάσσονται είναι προσπελάσιμες μέσω δικτύου 218

219 Βασικές Αρχές Service-oriented Architecture Ρητός και σαφής ορισμός των ορίων των υπηρεσιών Αυτονομία μεταξύ των υπηρεσιών Διαμοιρασμός σχημάτων (schemas) και συμφωνιών (contracts), αλλά όχι κλάσεων (classes) μεταξύ των υπηρεσιών Διασφάλιση της συμβατότητας ανάμεσα στις υπηρεσίες μέσω πολιτικών (policies) Επιπλέον: Υποστήριξη της χαλαρής διασύνδεσης (loose coupling) μεταξύ των components, μέσω των δημοσιευμένων διεπαφών Αδιαφάνεια τοποθεσίας Επαναχρησιμοποίηση κώδικα και συστατικών στοιχείων (components) 219

220 Παράδειγμα Service-oriented Architecture To compact-disc (CD) και το μηχάνημα αναπαραγωγής CD (CD player), το οποίο παρέχει την υπηρεσία της αναπαραγωγής του ήχου του CD Η SOA μας παρέχει τη δυνατότητα να αντικαταστήσουμε ένα μηχάνημα αναπαραγωγής CD με ένα άλλο, διαφορετικού κατασκευαστή και διαφορετικών προδιαγραφών, όπως ένα φορητό μηχάνημα αναπαραγωγής CD, και η υπηρεσία που προσφέρεται σε κάθε περίπτωση να παραμένει η ίδια: η αναπαραγωγή του CD πραγματοποιείται, το μόνο που αλλάζει είναι η ποιότητά της. Όμως εάν υποθέσουμε ότι το συγκεκριμένο σύστημα ακολουθεί κάποια άλλη αρχιτεκτονική, για παράδειγμα την αντικειμενοστραφή, κάθε CD θα είχε δικό του μηχάνημα αναπαραγωγής, από το οποίο δεν θα μπορούσε να αποσπαστεί. 220

221 Τι αναμένεται στο μέλλον για τη SOA? 221

222 Ορισμός μιας Διαδικτυακής Υπηρεσίας «Διαδικτυακή Υπηρεσία ονομάζεται μια εφαρμογή λογισμικού, που αναγνωρίζεται από ένα μοναδικό ενιαίο προσδιοριστικό πόρου URI (Uniform Resource Identifier). Το περιβάλλον διεπαφής (interfaces) και τα σημεία πρόσδεσης (bindings) πρέπει να είναι καλά ορισμένα, να περιγραφούν και να ανακαλυφθούν ως δεδομένα XML (artifacts). Μια διαδικτυακή υπηρεσία υποστηρίζει απ ευθείας δοσοληψίες με άλλους πράκτορες με ανταλλαγή μηνυμάτων βασισμένων σε XML μέσω πρωτοκόλλων του διαδικτύου.» World Wide Web Consortium 222

223 Πρακτικά πώς αντιλαμβανόμαστε μια Διαδικτυακή Υπηρεσία? Αποτελεί διαδικτυακή υπηρεσία κάθε υπηρεσία που παρέχεται μέσω διαδικτύου, όπως για παράδειγμα η online υπηρεσία κράτησης δωματίων που παρέχεται από μια ξενοδοχειακή επιχείρηση μέσω του εξυπηρετητή της εταιρείας στην επίσημη ιστοσελίδα της? Ταξιδιωτικό Γραφείο Internet Ξενοδοχείο Web Site ΟΧΙ... Η ύπαρξη μιας διαδικτυακής υπηρεσίας κράτησης δωματίων θα έδινε το δικαίωμα σε όλα τα ενημερωτικά τουριστικά sites, αλλά και συνεργαζόμενες επιχειρήσεις να κλείνουν αυτόματα δωμάτιά της. Ταξιδιωτικό Γραφείο 7/6/ , 286 Internet Ξενοδοχείο Web Service «διαθέσιμα δωμάτια» 223

224 Βασικά Χαρακτηριστικά Διαδικτυακών Υπηρεσιών Ανεξαρτησία από την πλατφόρμα υλοποίησης, χωρίς να απαιτείται καμία αλλαγή στον μηχανισμό του συστήματος Χρησιμοποίηση ανοικτών προτύπων και ευρέως διαδεδομένων πρωτοκόλλων, όπως XML (extensible Markup Language) και HTTP (HyperText Transfer Protocol) Γρήγορη ανάπτυξη και μειωμένο κόστος ολοκλήρωσης Συσσώρευση τελικών (back-end) υπηρεσιών Δημοσίευση των πληροφοριών που τις αφορούν, οπότε η εύρεση και η χρήση τους γίνονται ταχύτατα Επαναχρησιμοποίηση 224

225 Αρχιτεκτονική Διαδικτυακών Υπηρεσιών 225

226 Πλεονεκτήματα Web Services Ευκολότερος χειρισμός δεδομένων Απλότητα πρωτοκόλλου επικοινωνίας Απλότητα υποδομής Ευκολία στην επικοινωνία Διαλειτουργικότητα και ευκολία ανάπτυξης νέων εφαρμογών Αλληλεπίδραση μεταξύ υπηρεσιών σε οποιαδήποτε πλατφόρμα και οποιαδήποτε γλώσσα προγραμματισμού Χαλαρή συνδεσιμότητα μεταξύ εφαρμογών Προσαρμογή ήδη υπαρχουσών εφαρμογών στις μεταβαλλόμενες επιχειρησιακές συνθήκες και ανάγκες των πελατών Μικρό κόστος δημιουργίας και χρήσης 226

227 Web Services Standards stack Επιπλέον Πρότυπα 227

228 Πρωτόκολλο SOAP Το Simple Object Access Protocol (SOAP) ξεκίνησε με πρωτοβουλία του W3C το Σήμερα βρίσκεται στην έκδοση 1.2 (Second Edition - Απρίλιος 2007) Καθορίζει κυρίως τα ακόλουθα: Ένα message format για μονόδρομη επικοινωνία που περιγράφει πώς ένα μήνυμα δομείται σε XML έγγραφο Μια περιγραφή πώς ένα SOAP μήνυμα μεταδίδεται στο διαδίκτυο (χρησιμοποιώντας το HTTP) ή μέσω (χρησιμοποιώντας το SMTP) Ένα σύνολο από κανόνες (SOAP Encoding Rules) για την επεξεργασία ενός SOAP μηνύματος, όπως ποια τμήματα των μηνυμάτων μπορούν να διαβαστούν από ποιούς και ποια πρέπει να είναι η αντίδραση εάν το περιεχόμενο δεν είναι κατανοητό 228

229 Δομή του SOAP Μηνύματος Το SOAP βασίζεται σε ανταλλαγές μηνυμάτων Τα μηνύματα θεωρούνται ως φάκελοι στους οποίους η εφαρμογή εσωκλείει τα δεδομένα που αποστέλλει Κάθε μήνυμα έχει 2 κύρια μέρη: επικεφαλίδα (header) και κυρίως τμήμα (body), που μπορούν να χωριστούν περαιτέρω σε τμήματα Η επικεφαλίδα είναι προαιρετική και το κυρίως τμήμα υποχρεωτικό. Η χρήση και των 2 εξασφαλίζει ότι το κυρίως τμήμα αφορά δεδομένα της εφαρμογής, ενώ η επικεφαλίδα δεδομένα «υποδομής» για την αυθεντικοποίηση, την ασφάλεια και την τήρηση αρχείου. Σε περίπτωση που συμβεί κάποιο λάθος κατά τη διάρκεια της επικοινωνίας το μήνυμα περιέχει το στοιχείο Fault μέσα στο κυρίως τμήμα 229

230 Παράδειγμα ενός SOAP Μηνύματος <?xml version='1.0'?> <env:envelope xmlns:env=" <env:header> <m:reservation xmlns:m=" env:role=" env:mustunderstand="true"> <m:reference>uuid:093a2da1-q r-ba5d-pqff98fe8j7d</m:reference> <m:dateandtime> t13:20: :00</m:dateandtime> </m:reservation> <n:passenger xmlns:n=" env:role=" env:mustunderstand="true"> <n:name>åke Jógvan Øyvind</n:name> </n:passenger> </env:header> <env:body> <p:itinerary xmlns:p=" <p:departure> <p:departing>new York</p:departing> <p:arriving>los Angeles</p:arriving> <p:departuredate> </p:departuredate> <p:departuretime>late afternoon</p:departuretime> <p:seatpreference>aisle</p:seatpreference> </p:departure> <p:return> <p:departing>los Angeles</p:departing> <p:arriving>new York</p:arriving> <p:departuredate> </p:departuredate> <p:departuretime>mid-morning</p:departuretime> <p:seatpreference/> </p:return> </p:itinerary> <q:lodging xmlns:q=" <q:preference>none</q:preference> </q:lodging> </env:body> </env:envelope> Πηγή: SOAP Version 1.2 Part 0: Primer (Second Edition) W3C Recommendation 27 April

231 Πως μεταφέρονται τα δεδομένα στο SOAP:Body? Πηγή: G. Alonso, F. Casati, H. Kuno, V. Machiraju Web Services Concepts, Architectures and Applications, Springer-Verlag

232 Πλεονεκτήματα του Πρωτοκόλλου SOAP Ανοικτό Ασφαλές Έχει τη δυνατότητα να διαπερνά τα firewalls. Το Firewall αντιλαμβάνεται τα responses του SOAP σαν Web page requests Δεν απαιτεί να έχει πρόσβαση σε πρόσθετα ports στους Web servers 232

233 WSDL (Web Services Description Language) (1/2) Προδιαγράφει τον ορισμό Διαδικτυακών Υπηρεσιών σε σύνταξη XML, καταγράφει τις λειτουργίες που η Διαδικτυακή Υπηρεσία προσφέρει, τα πρωτόκολλα που μπορούν να χρησιμοποιηθούν για την κλήση της, την τοποθεσία της στο δίκτυο και το πώς δέχεται και επιστρέφει τα δεδομένα. Πριν την WSDL: Κάθε πάροχος περιέγραφε τις υπηρεσίες με δικό του τρόπο Τα αρχεία περιγραφών ήταν ασυνεπή και ασύμβατα μεταξύ τους Η Microsoft και η IBM συνδύασαν τις τεχνολογίες τους SCL και NASSL στην WSDL και με τη βοήθεια της Ariba Η WSDL έκδοση 1.1 υποβλήθηκε στο W3C το 2001 Η έκδοση 2.0 αποτελεί σύσταση του W3C από τον Ιούνιο

234 WSDL (Web Services Description Language) (2/2) Αποτελεί ένα «συμβόλαιο» ανάμεσα στον πάροχο και τον αιτούντα την υπηρεσία Ο πελάτης μπορεί να προσδιορίσει πού βρίσκεται μια διαδικτυακή υπηρεσία και να καλέσει μια διαθέσιμη διεπαφή της Με εργαλεία που υποστηρίζουν τη WSDL, η διαδικασία γίνεται αυτόματα Η WSDL περέχει πληροφορίες για: Διεπαφές (Interfaces) που περιγράφουν όλες τις διαθέσιμες λειτουργίες Τύπους Δεδομένων (Data Type) που αφορούν όλα τα μηνύματα αιτήσεων και αποκρίσεων Πρόσδεση (Binding) όσον αφορά το πρωτόκολλο μεταφοράς Διεύθυνση (Address) που προσδιορίζει πού βρίσκεται η συγκεκριμένη διαδικτυακή υπηρεσία 234

235 Από τι αποτελείται ένα WSDL Αρχείο? «Αφηρημένο» (abstract definition), που καθορίζει τη διεπαφή (interface) της υπηρεσίας και είναι ανεξάρτητο από πλατφόρμα και γλώσσα Περιγραφή των τύπων δεδομένων που αποστέλλονται σε μια αίτηση προς την υπηρεσία Η δομή των μηνυμάτων που αποστέλλονται προς την υπηρεσία Οι επιμέρους λειτουργίες που παρέχονται από την υπηρεσία Η οργάνωση σχετικών λειτουργιών σε επιμέρους διεπαφές που προσφέρονται από την υπηρεσία 235

236 Από τι αποτελείται ένα WSDL Αρχείο? «Σταθερό» (concrete definition), το οποίο παρέχει τις λεπτομέρειες για την πρόσβαση στις υπηρεσίες: Περιγραφή μιας ή περισσότερων υπηρεσιών που προσφέρουν στιγμιότυπα των διαπροσωπειών που ορίζονται στο abstract κομμάτι Η συσχέτιση των διεπαφών με κάποια συγκεκριμένα πρωτόκολλα επικοινωνίας (SOAP, ) Τα στιγμιότυπα της κάθε διεπαφής, τα οποία προσφέρονται σε συγκεκριμένες διευθύνσεις (URΙs) Τα στιγμιότυπα υπηρεσιών, ορισμένα σαν συλλογές από στιγμιότυπα διαπροσωπειών 236

237 WSDL 2.0: Ποιές οι διαφορές? Πηγή Web Services Description Language (WSDL) Version 2.0 Part 0: Primer W3C Recommendation 26 June

238 Παράδειγμα WSDL Αρχείου <?xml version="1.0"?> <definitions name="stockquote targetnamespace=" xmlns:tns=" xmlns:xsd1=" xmlns:soap=" xmlns=" <types> <schema targetnamespace=" xmlns=" <element name="tradepricerequest"> <complextype> <all> <element name="tickersymbol" type="string"/> </all> </complextype> </element> <element name="tradeprice"> <complextype> <all> <element name="price" type="float"/> </all> </complextype> </element> </schema> </types> <message name="getlasttradepriceinput"> <part name="body" element="xsd1:tradepricerequest"/> </message> <message name="getlasttradepriceoutput"> <part name="body" element="xsd1:tradeprice"/> </message> <porttype name="stockquoteporttype"> <operation name="getlasttradeprice"> <input message="tns:getlasttradepriceinput"/> <output message="tns:getlasttradepriceoutput"/> </operation> </porttype> <binding name="stockquotesoapbinding" type="tns:stockquoteporttype"> <soap:binding style="document" transport=" <operation name="getlasttradeprice"> <soap:operation soapaction=" <input> <soap:body use="literal"/> </input> <output> <soap:body use="literal"/> </output> </operation> </binding> <service name="stockquoteservice"> <documentation>my first service</documentation> <port name="stockquoteport" binding="tns:stockquotebinding"> <soap:address location=" </port> </service> </definitions> Πηγή: Web Services Description Language (WSDL) 1.1, W3C Note 15 March

239 Πρωτόκολλο Universal (UDDI) Αποτελεί ένα πρωτόκολλο καταχώρησης για Διαδικτυακές υπηρεσίες Ικανοποιεί δύο στόχους αναφορικά με την ανακάλυψη υπηρεσιών: Βοηθάει τους προγραμματιστές να βρουν πληροφορίες σχετικές με κάποιες υπηρεσίες, για να γνωρίζουν πώς να δημιουργήσουν προγράμματα πελάτες που να αλληλεπιδρούν με αυτές. Δίνει τη δυνατότητα για δυναμική «πρόσδεση» (binding), δηλαδή επιτρέπει στα προγράμματα πελάτες να ρωτάνε την υπηρεσία καταγραφής (registry) και να αποκτάνε εκείνη τη στιγμή αναφορές σε υπηρεσίες που τους ενδιαφέρουν Αποτελεί το ανάλογο του Χρυσού Οδηγού για τις Διαδικτυακές Υπηρεσίες... Στοχεύει στη δημιουργία ενός μοναδικού μητρώου που περιλαμβάνει όλα τα web services, οπότε για παράδειγμα, I want a web service that provides a tax calculator. Who offers such services? Αποτελεί δημιούργημα τριών εταιρειών: Microsoft, IBM και Ariba Αποτελεί πρότυπο του OASIS από το 2003 (Version 2.0). Σήμερα, βρίσκεται στην έκδοση 3.0 (Φεβρουάριος 2005) 239

240 Πληροφορίες για το σύνολο των Web Services που παρέχει ο Φορέας Δομή και Συσχετίσεις στο UDDI Πληροφορίες για τον Φορέα που παρέχει το Web Service businessentity businessentity businessentity businessservice businessservice bindingtemplate bindingtemplate InstanceDetails InstanceDetails categorybag keyedreference keyedreference identifierbag keyedreference keyedreference Rosetta-Net BASDA Simple.Buy Schemas, Interchange specification tmodels SIC CODE NAICS DUNS Numbers Thomas Registry ID Προδιαγραφές και περιγραφές για το Web Service Προσαρμοσμένο από 240

241 Δομή Καταλόγου στο UDDI: Πώς? Λευκές σελίδες (με businessservices), στις οποίες οι ενδιαφερόμενοι μπορούν να βρουν τις διαδικτυακές υπηρεσίες που προσφέρονται από τους Δημόσιους Φορείς. Κίτρινες σελίδες (με businessentities, businessservices και bindingtemplates), όπου είναι δυνατή η αναζήτηση υπηρεσιών ανάλογα με την κατηγορία στην οποία ανήκουν, σύμφωνα με το σχήμα ταξινόμησης υπηρεσιών του ΠΠ- ΔΔΤ και του ΠΔ&ΥΗΣ. Πράσινες σελίδες (με tmodels), που περιγράφουν πώς μπορεί ένας Φορέας να καλέσει μια συγκεκριμένη διαδικτυακή υπηρεσία. 241

242 Υπάρχουν σήμερα UDDI Registries? 4 live UDDI Business Registries (UBRs), όπου αποθηκεύονται λεπτομέρειες για τις διαθέσιμες Διαδικτυακές υπηρεσίες 3 test Registries για τις υπηρεσίες που βρίσκονται στο στάδιο της ανάπτυξης ή τελικού ελέγχου Ενδεικτικά: (και (και (και και 242

243 WS-Security Αποτελεί ένα πρωτόκολλο επικοινωνίας που προσδίδει ασφάλεια στις Διαδικτυακές Υπηρεσίες. Αρχικά αναπτύχθηκε από τις: IBM, Microsoft, VeriSign και Forum Systems και υποβλήθηκε στον OASIS για προτυποποίηση. Αποτελεί πρότυπο του OASIS από το Από τον Φεβρουάριο 2006 βρίσκεται στην έκδοση 1.1 Περλαμβάνει λεπτομέρειες για τη χρήση των προτύπων SAML και Kerberos, καθώς και του X.509 Το WS-Security ανήκει στην ευρύτερη οικογένεια Global XML Web Services Architecture (GXA), η οποία στον τομέα της ασφάλειας περιέχει επιπλέον τα πρότυπα WS-Policy, WS-Trust, WS-Privacy, WS-SecureConversation, WS-Federation και WS-Authorization. 243

244 Τι παρέχει το WS-Security? Αναγνώριση και αυθεντικοποίηση των εμπλεκόμενων Φορέων στη Διαδικτυακή Υπηρεσία. Για την περίπτωση αυτή, το WS-Security ορίζει πώς διαφορετικά σύμβολα ασφάλειας (security tokens) ενσωματώνονται και μεταφέρονται στα SOAP μηνύματα Διασφάλιση Ακεραιότητας των Μηνυμάτων, η οποία πραγματοποιείται με τη βοήθεια του προτύπου W3C XML Signature που έχει υιοθετήσει το WS- Security Προστασία από μη εξουσιοδοτημένη πρόσβαση κατά τη μεταφορά του SOAP μηνύματος, όπου το WS-Security χρησιμοποιεί το πρότυπο W3C XML Encryption για την κρυπτογράφηση των μεταφερόμενων δεδομένων Το WS-Security περιγράφει πώς επισυνάπτονται επικεφαλίδες υπογραφής και κρυπτογράφησης στα SOAP μηνύματα και εξασφαλίζει ασφάλεια από άκρη σε άκρη. 244

245 CORBA stack vs. Web Services stack (1/2) CORBA stack IDL CORBA (Naming) Structure CORBA Stubs / Skeletons CDR binary encoding GIOP/IIOP TCP/IP Web Services stack WSDL UDDI SOAP Messaging XML Unicode encoding HTTP TCP/IP Πηγή: Aniruddha Gokhale, Bharat Kumar, Arnaud Sahuguet, Reinventing the Wheel? CORBA vs. Web Services 245

246 CORBA stack vs. Web Services stack (2/2) Feature CORBA Web Services Client-server coupling Tight coupling Loose coupling Διαφάνεια τοποθεσίας Object references URL Τύποι Δεδομένων IDL XML schemas static + runtime checks runtime checks only Διαχείριση Σφαλμάτων IDL exception SOAP fault messages Πέρασμα Παραμέτρων by reference by value (no notion of objects) Σύνταξη για τη μεταφορά δεδομένων by value (valuetype) CDR used on the wire binary format XML used on the wire Unicode Κατάσταση stateful stateless Request semantics at-most-once defined by SOAP Υποστήριξη γλώσσας any language with an IDL binding any language Ασφάλεια CORBA security service HTTP/SSL, XML signature Πρόσβαση μέσα από Firewall work in progress uses HTTP port 80 Διαχείριση Γεγονότων CORBA event service N/A Πηγή: Aniruddha Gokhale, Bharat Kumar, Arnaud Sahuguet, Reinventing the Wheel? CORBA vs. Web Services 246

247 Μειονεκτήματα παλαιότερων τεχνολογιών Κόστος υποδομής (EDI, CORBA) Κόστος και πολυπλοκότητα υλοποίησης (EDI, CORBA) Χρήση μόνο σε «ιδιωτικά» δίκτυα (EDI, CORBA, DCOM, RMI) Χρήση μόνο σε εφαρμογές που εκτελούνται στην ίδια πλατφόρμα (DCOM) Χρήση μόνο σε εφαρμογές γραμμένες στην ίδια γλώσσα προγραμματισμού (RMI) Μειωμένες λειτουργίες (XML-RPC) Έλειψη ευελιξίας (EDI, CORBA, DCOM, RMI) 247

248 Βασικές Αρχές Υλοποίησης Διαδικτυακών Υπηρεσιών (1/2) Συμμόρφωση με Ανοικτά Πρότυπα, όπως XML, SOAP, WSDL, UDDI Επαναχρησιμοποίηση κώδικα και συστατικών στοιχείων (components) Σχέση με την Υπηρεσιοστραφή Αρχιτεκτονική (Serviceoriented Architecture) Υποστήριξη της χαλαρής διασύνδεσης (loose coupling) μεταξύ των components Η μόνη αλληλεπίδραση ανάμεσα στην εφαρμογή και τις υπηρεσίες πραγματοποιείται μέσω των δημοσιευμένων διεπαφών Αδιαφάνεια τοποθεσίας 248

249 Βασικές Αρχές Υλοποίησης Διαδικτυακών Υπηρεσιών (2/2) Ασφάλεια Διαθεσιμότητα σε επίπεδο περιγραφής στο Ληξιαρχείο Διαδικτυακών Υπηρεσιών του ΠΗΔ και σε επίπεδο υλοποίησης από τον αρμόδιο Φορέα που τις εξέδωσε Επίδοση και Αξιοπιστία Ευκολία ανεύρεσης Διατηρησιμότητα και ευκολία διαχείρισης εκδόσεων Ανεξαρτησία από πλατφόρμες υλοποίησης 249

250 Διεπαφές Διαλειτουργικότητας 250

251 Τι θα πρέπει να αποφευχθεί; Top-down approach: οι Διαδικτυακές Υπηρεσίες να καλύπτουν τις ανάγκες των αποδεκτών της υπηρεσίας, αλλά να μην υποστηρίζονται επαρκώς από τα Πληροφοριακά Συστήματα του Φορέα ή απαιτούν τη δημιουργία νέων Πληροφοριακών Συστημάτων από την αρχή. Bottom-up approach: οι Διαδικτυακές Υπηρεσίες απλώς να εξωτερικεύουν όψεις των back-office εφαρμογών του Φορέα, χωρίς να τοποθετούνται στο συγκεκριμένο πλαίσιο μιας υπηρεσίας Αντίθετα... θα πρέπει να συμβιβάζονται οι επιχειρηματικές ανάγκες και οι παρεχόμενες υπηρεσίες με τις δυνατότητες των Πληροφοριακών Συστημάτων του Φορέα (meet-in-the-middle approach) 251

252 Τι χρειάζεται για την τεκμηρίωση μιας Διαδικτυακής Υπηρεσίας? KY.153 Ως καλά ορισμένη Διαδικτυακή Υπηρεσία θεωρείται η Διαδικτυακή Υπηρεσία που τεκμηριώνεται με: Το πλήρες WSDL αρχείο της, με την περιγραφή διεπαφής και υλοποίησης, και τη διεύθυνση που λειτουργεί το web service στο Διαδίκτυο Mεταδεδομένα που σχετίζονται με τον ιδιοκτήτη της Μοντέλο και Μεταδεδομένα της υπηρεσίας στην οποία εντάσσεται XML Σχήματα για τα ανταλλασσόμενα έγγραφα Το UML Ακολουθιακό Διάγραμμα (Sequence Diagram) που αποτυπώνει αναλυτικά τη ροή της 252

253 Βήμα 5 Βήμα 3 Βήμα 4 Βήμα 2 Βήμα 1 Μεθοδολογία Υλοποίησης Διαδικτυακών Υπηρεσιών Αναγνώριση τελικών υπηρεσιών Αναγνώριση σημείων διαλειτουργικότητας μεταξύ Φορέων Αναγνώριση Διαδικτυακών Υπηρεσιών Αναγνώριση εσωτερικών σημείων διαλειτουργικότητας Σχεδίαση Διαδικτυακών Υπηρεσιών Υλοποίηση Διαδικτυακών Υπηρεσιών Αναζήτηση Διαδικτυακών Υπηρεσιών στο Ληξιαρχείο Διαλειτουργικότητας Δημοσίευση των Διαδικτυακών Υπηρεσιών στο Ληξιαρχείο Διαλειτουργικότητας Αξιοποίηση της Διαδικτυακής Υπηρεσίας από τους εμπλεκόμενους Φορείς Συντήρηση Διαδικτυακών Υπηρεσιών 253

254 Σημείο Κλειδί στο Βήμα 1: Πώς αναγνωρίζονται τα σημεία δημιουργίας Διαδικτυακών Υπηρεσιών? Web Service 1 Web Service 4 Web Service 2 Web Service 3 254

255 Σημεία Κλειδιά στο Βήμα 2 Καταγραφή των μεθόδων και των δεδομένων εισόδου εξόδου που απαιτούνται για να αυτοματοποιήσουν την επικοινωνία Μοντελοποίηση των δεδομένων που ανταλλάσσονται σε XML Schemas Πρόβλεψη για: Διαχείριση του web service ώστε να διατηρείται σε κάθε περίπτωση η ακεραιότητα των συναλλαγών και διασφαλίζεται η διαθεσιμότητα και η ποιότητά του Συντονισμό και επίβλεψη σύνθετων web services, δηλαδή web services που καλούν άλλα web services για να ολοκληρωθούν Παροχή δυνατότητας ενημέρωσης της πορείας εκτέλεσης της Διαδικτυακής Υπηρεσίας μέσω web service και με τη βοήθεια κατάλληλων υποδομών, όπως Συστήματα Διαχείρισης Ροής Εργασιών (Workflow Management System). Οι δυνατές καταστάσεις της πορείας εκτέλεσης ενός web service είναι: Σε εκκρεμότητα (pending) είτε εσωτερικά στο Φορέα είτε από άλλο Φορέα Ολοκληρωμένο είτε επιτυχώς (completed) ή με αποτυχία (failed) 255

256 Σημεία Κλειδιά στο Βήμα 2 Κάθε Διαδικτυακή Υπηρεσία είναι τύπου Request / Response όπου ο ενδιαφερόμενος αποστέλλει ένα αίτημα με τη μορφή SOAP μηνύματος και περιμένει ασύγχρονα την απάντηση Σε κάθε μήνυμα που αποστέλλεται πρέπει να επιστρέφεται βεβαίωση λήψης (acknowledgement) Οι απαραίτητες πληροφορίες για τη δρομολόγηση και την ορθή λήψη του μηνύματος ενσωματώνονται στο soap:header και ενδεικτικά αφορούν τα ακόλουθα: Έκδοση (Version) Ημερομηνία και Ώρα Αποστολής (DispatchDateTime) Ημερομηνία και Ώρα Εκπνοής (ExpiringDateTime) Αποστολέας (Sender) Αποδέκτης (Recipient) Κωδικός και Περιγραφή Κατάστασης (StateCode και StateDescription) Κωδικός Δοσοληψίας (TransactionID) Κωδικός Μηνύματος (MessageID) 256

257 Σημείο Κλειδί στο Βήμα 2: Πώς απεικονίζονται οι Διαδικτυακές Υπηρεσίες? Όλες οι μέθοδοι μιας Διαδικτυακής Υπηρεσίας πρέπει να απεικονίζονται σε UML Sequence Diagrams 257

258 Παράδειγμα WSDL Αρχείου με βάση το Πλαίσιο <?xml version="1.0" encoding="utf-8"?> <wsdl:definitions xmlns:wsdl=" xmlns:soap=" xmlns:http=" xmlns:xs=" xmlns:soapenc=" xmlns:mime=" xmlns:pc=" xmlns:tns=" targetnamespace=" <wsdl:types> <xs:schema targetnamespace=" elementformdefault="qualified"> <xs:import schemalocation="paymentcatalogue-v1-0.xsd" namespace=" </xs:schema> </wsdl:types> <wsdl:message name="messagesendpaymentcatalogue"> <wsdl:part name="parameters" element="pc:paymentcatalogue"/> </wsdl:message> <wsdl:message name="messagereceivepaymentcatalogueacknowledgement"> <wsdl:part name="parameters" element="pc:paymentcatalogueacknowledgment"/> </wsdl:message> <wsdl:porttype name="sendpaymentcatalogueporttype"> <wsdl:operation name="requestresponseoperationsendpaymentcatalogue"> <wsdl:input message="tns:messagesendpaymentcatalogue"/> <wsdl:output message="tns:messagereceivepaymentcatalogueacknowledgement"/> </wsdl:operation> </wsdl:porttype> <wsdl:binding name="sendpaymentcataloguesoap" type="tns:sendpaymentcatalogueporttype"> <soap:binding style="document" transport=" <wsdl:operation name="requestresponseoperationsendpaymentcatalogue"> <soap:operation soapaction=" <wsdl:input> <soap:body use="literal"/> </wsdl:input> <wsdl:output> <soap:body use="literal"/> </wsdl:output> </wsdl:operation> </wsdl:binding> <wsdl:service name="sendpaymentcatalogue"> <wsdl:port name="sendpaymentcatalogueporttype" binding="tns:sendpaymentcataloguesoap"> <soap:address location=" </wsdl:port> </wsdl:service> 258

259 Σημείο Κλειδί στο Βήμα 4: Σε ποιο σημείο των ΠΣ τοποθετούνται οι Διαδικτυακές Υπηρεσίες? Για την εξασφάλιση της μέγιστης δυνατής ευελιξίας στις όποιες αλλαγές του περιβάλλοντος: αντικατάσταση back-office συστημάτων, αντικατάσταση web services Οι Φορείς πρέπει να υιοθετούν τη λύση του μεσισμικού (middleware) και να μην ενσωματώνουν τις Διαδικτυακές Υπηρεσίες στην υλοποίηση των back-office συστημάτων τους 259

260 Σημείο Κλειδί στο Βήμα 5: Εάν αλλάξει έκδοση μια Διαδικτυακή Υπηρεσία? Διασφαλίζεται η συμβατότητα προς τα πίσω (backward compatibility) Ο Φορέας προβαίνει σε άμεση ενημέρωση των Δημόσιων Φορέων που χρησιμοποιούν τη Διαδικτυακή Υπηρεσία Στην περίπτωση που εμπλέκονται για παράδειγμα πολίτες και επιχειρήσεις και είναι δύσκολη η άμεση ενημέρωση των αιτούντων, υπάρχουν 2 εναλλακτικές: Ο Φορέας - πάροχος της υπηρεσίας και το Ληξιαρχείο Διαλειτουργικότητας να τηρεί όλες τις διαθέσιμες εκδόσεις της για ένα λογικό χρονικό διάστημα, αν όχι για πάντα, και μόλις κάποιος καλέσει την υπηρεσία τον ενημερώνει ότι είναι διαθέσιμη μια νέα έκδοσή της και πού μπορεί να αναζητήσει την περιγραφή της. Στην περίπτωση της τήρησης μόνο της νεότερης έκδοσης, είναι απαραίτητη η υλοποίηση της λεγόμενης Service Broker αρχιτεκτονικής από την πλευρά του παρόχου. Η αρχιτεκτονική αυτή προβλέπει έλεγχο στις εισερχόμενες κλήσεις και μετατροπή της αίτησης από την παλιά έκδοση στην νέα. Σε περίπτωση που αυτό δεν είναι εφικτό, ενημερώνει τον αιτούντα υπηρεσίες (service requestor) για την ασυμβατότητα και τον τρόπο με τον οποίο θα την εξαλείψει. 260

261 Ποιά η συμβολή του Πλαισίου? Μεθοδολογία Σχεδίασης Διαδικτυακών Υπηρεσιών Βήμα 1: Αναγνώριση Διαδικτυακής Υπηρεσίας Βήμα 2: Υλοποίηση Διαδικτυακής Υπηρεσίας Βήμα 3: Δημοσίευση Διαδικτυακής Υπηρεσίας Βήμα 4: Αξιοποίηση Διαδικτυακής Υπηρεσίας Βήμα 5: Συντήρηση Διαδικτυακής Υπηρεσίας Συμβολή του ΠΗΔ Δημιουργία μοντέλων και καταγραφή μεταδεδομένων για τις υπηρεσίες, σύμφωνα με τις οδηγίες του Μοντέλου Τεκμηρίωσης του ΠΗΔ. Αναζήτηση στο Ληξιαρχείο Διαλειτουργικότητας για Διαδικτυακές Υπηρεσίες που αφορούν τα σημεία διαλειτουργικότητας του Φορέα. Αναζήτηση στο Ληξιαρχείο Διαλειτουργικότητας για πρότυπα XML Σχήματα. Δημιουργία νέων XML Σχημάτων με βάση τα Core Components του Ληξιαρχείου και τις οδηγίες του Μοντέλου Τεκμηρίωσης του ΠΗΔ. Καταγραφή μεταδεδομένων που σχετίζονται με τον ιδιοκτήτη της Διαδικτυακής Υπηρεσίας με βάση το πρότυπο του ΠΗΔ. Δημοσίευση των μεταδεδομένων του Φορέα και του WSDL αρχείου της υπηρεσίας στο Ληξιαρχείο Διαλειτουργικότητας του ΠΗΔ. Αναζήτηση στο Ληξιαρχείο Διαλειτουργικότητας για τα WSDL αρχεία των Διαδικτυακών Υπηρεσιών. Τήρηση ιστορικότητας εκδόσεων Διαδικτυακών Υπηρεσιών στο Ληξιαρχείο του ΠΗΔ. 261

262 Υλοποίηση μιας Απλής Διαδικτυακής Υπηρεσίας DEMO στο Visual Studio