Τεχνολογία Λογισμικού Κώστας Βασιλάκης ΠΑΝΕΠΙΣΤΗΜΙΟ ΠΕΛΟΠΟΝΝΗΣΟΥ

ΠΑΝΕΠΙΣΤΗΜΙΟ ΠΕΛΟΠΟΝΝΗΣΟΥ
Κώστας Βασιλάκης
ΤΕΧΝΟΛΟΓΙΑ ΛΟΓΙΣΜΙΚΟΥ (SOFTWARE

ENGINEERING)
Πλαίσιο μαθήματος, εισαγωγή

• Αντικείμενο μαθήματος
• Προαπαιτούμενα
• Οργάνωση εκπαιδευτικής διαδικασίας μαθήματος
• Ποιοτικές διαστάσεις λογισμικού
• Κύκλος ζωής λογισμικού και διαχείρισή του
2
Τεχνολογία Λογισμικού
• Κλάδος της πληροφορικής που ασχολείται με τη μελέτη και την
εφαρμογή συστηματικών, μεθοδικών και ποσοτικοποιημένων
προσεγγίσεων για την ανάπτυξη, λειτουργία και συντήρηση του
λογισμικού [IEEE Standard 610.12]
• Στοχεύει στην ανάπτυξη αξιόπιστου λογισμικού με μεγάλο
κύκλο ζωής που ικανοποιεί τις απαιτήσεις των χρηστών και των
πελατών. Εστιάζει τη προσοχή της στην ανάπτυξη και εφαρμογή
συστηματικών μεθόδων, τεχνικών και εργαλείων που αφορούν
ολόκληρο το κύκλο ζωής του Λογισμικού και υποστηρίζουν την
επιτυχία των παραπάνω στόχων.
Η ανάγκη για την Τεχνολογία Λογισμικού:

«κρίση λογισμικού», 1968
• Αποκλίσεις του λογισμικού από τη
λειτουργικότητα που επιθυμούσαν οι πελάτες που
το παρήγγειλαν,
• Αποκλίσεις από το χρονοδιάγραμμα ανάπτυξης,
• Αποκλίσεις από τον οικονομικό προγραμματισμό
ανάπτυξης του λογισμικού,
• Αποκλίσεις από το προβλεπόμενο κόστος του
περιβάλλοντος λειτουργίας του λογισμικού,
• Αδυναμία εξέλιξης του λογισμικού με σκοπό τα
προσαρμοσθεί στις νέες ανάγκες των πελατών
4
Η ανάγκη εξακολουθεί να
υφίσταται: Standish 2020
• το 2020:
◦ 19% των έργων ανάπτυξης λογισμικού απέτυχαν και ματαιώθηκε η
ολοκλήρωση τους.
◦ 50% των έργων ολοκληρώθηκε με αποκλίσεις είτε στον προϋπολογισμό
τους είτε στο χρονοπρογραμματισμό τους είτε στην λειτουργικότητα του
προϊόντος λογισμικού
◦ Μόλις 31% των έργων ολοκληρώθηκε σύμφωνα με τον χρονικό και
οικονομικό τους προγραμματισμό
Πηγή: CHAOS REPORT 2000, 2015,2022
2000 2015 2020

Επιτυχία 28% 36% 31%
Με προβλήματα 49% 45% 50%
Αποτυχία 23% 19% 19%
υφίσταται
Έργα που τελείωσαν (περίοδος αναφοράς 2011-2015)
Εντός χρονοδιαγράμματος Εντός προϋπολογισμού Εντός στόχων
44% 40% 44%

56% 60% 56%
6
υφίσταται
Επιτυχία Με προβλήματα Αποτυχία
Τεράστιο 6% 51% 43%
Μεγάλο 11% 59% 30%
Μεσαίο 12% 62% 26%
Περιορισμένο 24% 64% 12%
Μικρό 61% 32% 7%
Αναφορά της Standish 2015

• Παράγοντες επιτυχίας:
◦ Επιχειρησιακή υποστήριξη
◦ Συναισθηματική ωριμότητα
◦ Εμπλοκή χρηστών
◦ Βελτιστοποίηση
◦ Ικανότητες προσωπικού
◦ Τυποποιημένο περιβάλλον διαχείρισης αρχιτεκτονικής
◦ Υιοθέτηση ευέλικτων διαδικασιών
◦ Ικανός διοικητής έργου
◦ Σαφείς επιχειρησιακοί στόχοι
8
Τι γίνεται μετά την αποτυχία;
•Έρευνα του 2002 σε οργανισμούς πληροφορικής
(Πηγή: Cutter Consortium)
◦ Το 78% ενεπλάκη σε διαφωνίες που κατέληξαν σε
δικαστικές διαδικασίες
◦ Από τις περιπτώσεις που έφτασαν σε δικαστική
διαδικασία
◦ Στο 67% το δικαστήριο απεφάνθη ότι το προϊόν δεν είχε τη
λειτουργικότητα που ισχυριζόταν η εταιρεία παραγωγής του
◦ Στο 56% η προθεσμία παράδοσης μετατέθηκε πολλές φορές
◦ Στο 45% τα προβλήματα ήταν τόσο σημαντικά που το προϊόν
δεν ήταν δυνατόν να χρησιμοποιηθεί
Τι συμβαίνει με άλλους τομείς;

• Ο κατασκευαστικός τομέας είναι ένα καλό
παράδειγμα όπου τα έργα αποτυγχάνουν πιο σπάνια.
Ποια διαδικασία ακολουθείται;
◦ Πρώτα βλέπουμε την αρχιτεκτονική προσέγγιση – τι θέλουμε
να κατασκευάσουμε και τι σκοπούς εξυπηρετεί;
◦ Κατόπιν τη μέθοδο/τεχνική: βηματική προσέγγιση για το πώς
θα κατασκευάσουμε αυτό που επιθυμούμε
◦ Εξετάζουμε τα εργαλεία: με πιο τρόπο θα γίνει «καλύτερα»
το κάθε βήμα;
◦ Καλύτερα: οικονομικότερα, ταχύτερα, ασφαλέστερα, πιο ποιοτικά...
◦ Η εξειδίκευση μεθόδων/τεχνικών με συγκεκριμένα εργαλεία
οδηγεί σε διαδικασίες
10
Μια χρήσιμη αναλογία
11
Τεχνικές, μεθοδολογίες και εργαλεία

• Τεχνικές
◦ Τυπικές διαδικασίες για παραγωγή αποτελεσμάτων με χρήση
μιας καλά ορισμένης σημειογραφίας
• Μεθοδολογίες
◦ Συλλογές τεχνικών που εφαρμόζονται σε όλες τις φάσεις της
ανάπτυξης λογισμικού και που ενοποιούνται υπό μία
φιλοσοφική προσέγγιση
• Εργαλεία
◦ Μέσα ή αυτοματοποιημένα συστήματα για να εφαρμόσουμε
μία τεχνική
◦ Διαδραστικό περιβάλλον ανάπτυξης (IDE)
◦ Computer Aided Software Engineering (CASE)
12
Γιατί είναι δύσκολη η ανάπτυξη
λογισμικού;
• Το πρόβλημα συνηθέστατα είναι ασαφές
• Οι απαιτήσεις είναι συνήθως ασαφείς και –όταν
αποσαφηνίζονται- αλλάζουν
• Το «πεδίο ορισμού» του προβλήματος (το πεδίο των
εφαρμογών) είναι σύνθετο και πολύπλοκο – το ίδιο ισχύει
και για το πεδίο των λύσεων (τις υλοποιημένες εφαρμογές)
• Η διαδικασία ανάπτυξης απαιτεί διαχείριση, η οποία είναι
πολύπλοκη
• Το λογισμικό προσφέρει ευελιξία (και συνακόλουθα
πληθώρα επιλογών)
13
Η ανάπτυξη του λογισμικού δεν

περιορίζεται στην ανάπτυξη κώδικα
• Περιλαμβάνει επίλυση προβλημάτων
◦ Κατανόηση του προβλήματος
◦ Πρόταση μιας λύσης και ενός σχεδίου εφαρμογής της
◦ Κατασκευή ενός συστήματος που βασίζεται στην προτεινόμενη λύση
χρησιμοποιώντας έναν καλό σχεδιασμό
• Περιλαμβάνει αντιμετώπιση της πολυπλοκότητας
◦ Δημιουργία αφαιρέσεων και μοντέλων
◦ Χρήση σημειογραφιών (notations) για τις αφαιρέσεις
• Περιλαμβάνει διαχείριση γνώσης
◦ Εκμαίευση, ανάλυση, σχεδιασμός, επικύρωση τόσο του συστήματος όσο και της
διαδικασίας επίλυσης
• Περιλαμβάνει διαχείριση συλλογιστικής
◦ Οι αποφάσεις σχεδιασμού και υλοποίησης είναι σαφείς για όλους τους
εμπλεκόμενους
14
Ιδιαιτερότητα του λογισμικού (1/2)
• Εκτός από τα εργαλεία, τις τεχνικές και την αρχιτεκτονική
προσέγγιση υπάρχει και ο άνθρωπος (παραγωγικότητα 1 έως
10)
◦ Πολύ μεγαλύτερη επίπτωση στην ποιότητα απ’ ό,τι π.χ. στον
κατασκευαστικό τομέα
• Το λογισμικό είναι πολύπλοκο

◦ Στις κατασκευές για την τοιχοποιία έχουμε τούβλα τυποποιημένων
διαστάσεων. Πόσοι τρόποι υπάρχουν για να δείξουμε π.χ. τη δομή του
συστήματος αρχείων;
15
Ιδιαιτερότητα του λογισμικού (2/2)

• Το λογισμικό απαιτεί προσαρμοστικότητα
◦ Ένα σπίτι ή μία γέφυρα, αφού κατασκευαστεί, δεν αλλάζει δομικά
χαρακτηριστικά. Στο λογισμικό μπορεί να ζητηθεί αλλαγή
οποιασδήποτε παραμέτρου ή λειτουργίας του.
• Το λογισμικό είναι άϋλο
◦ Σε σπίτια, γέφυρες κ.λπ. μπορούμε να δούμε σχέδια, μακέτες και
να αντιληφθούμε πως θα είναι στην πραγματικότητα. Στο
λογισμικό αυτό δεν είναι το ίδιο απλό.
• Το λογισμικό αλλάζει διαρκώς
◦ Για να προσαρμοστεί στο υλικό, σε αλλαγές της τεχνολογίας, σε
νέους επιχειρηματικούς κανόνες κ.ο.κ.
16
Γιατί όχι χρήση της γενικής
επιστημονικής μεθοδολογίας; (1/2)
(1) Υπάρχουσες
θεωρίες και (2) Υποθέσεις (3) Προβλέψεις
παρατηρήσεις
Οι υποθέσεις πρέπει Οι υποθέσεις πρέπει
να επανακαθοριστούν προσαρμοστούν
πλήρως
(4) Δοκιμές και
νέες
(6) Επιλογή παρατηρήσεις
ανάμεσα στις
επικρατέστερες Επίτευξη συνέπειας
θεωρίες
(5) Επιβεβαίωση
παλαιάς ή
διατύπωση νέας
θεωρίας
17
Γιατί όχι χρήση της γενικής

επιστημονικής μεθοδολογίας; (2/2)
• Χρειαζόμαστε ιδέες και υποθέσεις
◦ Που δεν καθορίζεται από τη μέθοδο το από που και πώς θα τις
βρούμε...
• Η επιστημονική μεθοδολογία λειτουργεί κυρίως με την

«ύστερη γνώση» δηλ. την αναγνώριση της πραγματικότητας,
των εναλλακτικών ή των απαιτήσεων μιας κατάστασης,
απόφασης ή ενός συμβάντος αφού έχουν γίνει
◦ Χρήσιμο για να δούμε που είχαμε βρεθεί και για να ελέγχουμε αυτό
που πιστεύουμε ότι γνωρίζουμε.
◦ Καθόλου χρήσιμο για να δούμε που θα πάμε.
• Χρειαζόμαστε δημιουργικότητα, πρωτοτυπία,

εφευρετικότητα, διαίσθηση, φαντασία, υπέρβαση
προβλημάτων.
18
Ένας λειτουργικός ορισμός της
τεχνολογίας λογισμικού
• Κλάδος της πληροφορικής που ασχολείται με τη μελέτη και την

εφαρμογή συστηματικών, μεθοδικών και ποσοτικοποιημένων
προσεγγίσεων για την ανάπτυξη, λειτουργία και συντήρηση του
λογισμικού [IEEE Standard 610.12]
• Η τεχνολογία λογισμικού είναι μία συλλογή από τεχνικές,
μεθοδολογίες και εργαλεία που βοηθούν στο να παραχθεί
Λογισμικό υψηλής ποιότητας με δεδομένο προϋπολογισμό εντός
συγκεκριμένης προθεσμίας ενώσω συντελούνται αλλαγές
• Η πρόκληση είναι η διαχείριση της πολυπλοκότητας και των
αλλαγών
19
Ποιότητες που ενδιαφέρουν

• Το λογισμικό έχει ποιοτικά χαρακτηριστικά. Τα χαρακτηριστικά
που ενδιαφέρουν τον κάθε εμπλεκόμενο είναι διαφορετικά:
Συντηρητής
Καλή τεκμηρίωση
Κατανοητός κώδικας
Καλή σχεδίαση
Επαναχρησιμοποίηση
Αξιοπιστία
Χαμηλό κόστος
Ορθότητα
Μεταφέρσιμο
Αποδοτικότητα
Λειτουργικότητα Αυξάνει την
Ευκολία χρήσης παραγωγικότητα
Ευκολία εκμάθησης
Χρήστης Πελάτης
20
Ποιοτικό Λογισμικό (1/3)
• Διαθεσιμότητα: ποσοστό του χρόνου που είναι λειτουργικό και
μπορεί να χρησιμοποιηθεί το σύστημα (π.χ. 99,99%)
• Απόδοση: Η ταχύτητα απόκρισης του συστήματος
• Ευελιξία: Ευκολία τροποποίησης ή προσαύξησης της
λειτουργικότητας
• Ακεραιότητα: διατήρηση συνέπειας των δεδομένων και
ασφάλεια (μόνο οι εξουσιοδοτημένοι χρήστης έχουν πρόσβαση
στις σχετικές λειτουργικότητες και τα δεδομένα)
• Διαλειτουργικότητα: η ικανότητα ανταλλαγής δεδομένων και
υπηρεσιών με άλλα συστήματα
• Συντηρησιμότητα: η ευκολία για διόρθωση σφαλμάτων και
τροποποίηση του λογισμικού
21

• Μεταφερσιμότητα: η ικανότητα να εκτελεστεί σε
διαφορετικό υλικό ή/και λειτουργικό σύστημα
ή/και με διαφορετικές συνιστώσες (π.χ. ΣΔΒΔ,
εξυπηρέτες διαδικτύου). Περιλαμβάνει και τις
διαδικασίες διεθνοποίησης (internationalization)
• Αξιοπιστία: η ικανότητα να λειτουργεί σωστά και
να εκτελεί σωστά τις λειτουργίες
• Επαναχρησιμότητα: η δυνατότητα κάποιες
συνιστώσες να χρησιμοποιηθούν σε άλλα
συστήματα λογισμικού.
22
• Ευρωστία: Ανοχή σε σφάλματα που ξεκινούν από εσφαλμένη
είσοδο χρηστών και αδυναμίες επικοινωνίας και εκτείνονται ως
τη δυνατότητα ανάκαμψης κάτω από ακραίες συνθήκες (π.χ.
διακοπή ρεύματος, καταστροφή δίσκου). Οι δυνατότητες
προβλέψιμου τερματισμού και ορθού χειρισμού σφαλμάτων
είναι σημαντικές.
• Ελεγχξιμότητα: Ο βαθμός ευχέρειας στον πλήρη και διεξοδικό
έλεγχο του λογισμικού και στον εντοπισμό της αιτίας ενός
σφάλματος
• Ευχρηστία: ο βαθμός ευκολίας για την χρήση και εκμάθηση του
λογισμικού από τους τελικούς χρήστες, η δυνατότητα
προσαρμογής στις ιδιαίτερες ανάγκες του κάθε χρήστη και άλλα
θέματα επικοινωνίας ανθρώπου-μηχανής.
23
Αντικείμενο μαθήματος
• Οι βασικές έννοιες της τεχνολογίας λογισμικού
◦ Μεθοδολογίες
◦ Μοντέλα διαδικασιών
◦ Τεχνικές περιγραφής και μοντελοποίησης
◦ Ανάλυση συστήματος – Μηχανική απαιτήσεων
◦ Σχεδιασμός συστήματος
◦ Υλοποίηση: βασικές αρχές της ανάπτυξης συστημάτων
◦ Έλεγχος και ολοκλήρωση
24
1ος στόχος: τεχνική γνώση
• Υπάρχουν διάφορες μεθοδολογίες (φιλοσοφίες) για την
ανάπτυξη συστημάτων λογισμικού
• ... και διάφορες σημειογραφίες μοντελοποίησης
• ... και διάφορες μεθοδολογίες μοντελοποίησης
• ... και διάφορα μοντέλα διαχείρισης του κύκλου ζωής του
λογισμικού (τόσο εμπειρικά όσο και τυπικά)
• ... και διάφορες τεχνικές ελέγχου (π.χ. κατακόρυφος
έλεγχος, οριζόντιος έλεγχος)
• Διαχείριση εκδόσεων και διαμορφώσεων συστήματος
25
2ος στόχος: διαχειριστική γνώση

• Βασικά στοιχεία τις διαχείρισης έργων λογισμικού
• Κατανόηση της διαχείρισης με μοντέλα κύκλου
ζωής λογισμικού
• Εμπέδωση της γνώσης για τον τρόπο ανάπτυξης
του λογισμικού
• Διαχείριση αλλαγών μέσω της διαχείρισης
διαμορφώσεων
• Εμπέδωση των βασικών μεθοδολογιών
◦ Παραδοσιακή ανάπτυξη λογισμικού
◦ Ευέλικτες (agile) μέθοδοι
26
Γενικό πλαίσιο μαθήματος
Διαχείριση πολυπλοκότητας Διαχείριση αλλαγών
– Σημειογραφίες (UML, OCL) – Διαχείριση συλλογιστικής
– Μηχανική απαιτήσεων, (μοτίβα διαχείρισης
ανάλυση και σχεδιασμός γνώσης)
(αντικειμενοστρεφής – Διαχείριση εκδόσεων
τεχνολογία λογισμικού, (διαχείριση διαμορφώσεων,
δομημένη ανάλυση και συνεχής ολοκλήρωση)
σχεδιασμός, σχεδιασμός – Κύκλος ζωής λογισμικού
βάσει σεναρίων, τυπικές (γραμμικά μοντέλα,
προδιαγραφές) επαναληπτικά μοντέλα,
– Έλεγχος (κατακόρυφος και όψεις βασισμένες σε
οριζόντιος έλεγχος) δραστηριότητες έναντι
όψεων βασισμένων σε
οντότητες)
ΕΦΑΡΜΟΓΗ ΣΤΙΣ ΕΡΓΑΣΙΕΣ

27
Προαπαιτούμενα του μαθήματος

• Αντικειμενοστρεφής προγραμματισμός
• Επιθυμητές γνώσεις
◦ Βάσεις δεδομένων
28
Συγγράμματα
• Μπορείτε να προμηθευτείτε τα συγγράμματα
◦ Βασικές αρχές τεχνολογίας Λογισμικού, I. Sommerville
◦ Τεχνολογία λογισμικού, Ε. Γιακουμάκης & Ν. Διαμαντίδης
• Συνιστώμενα συγγράμματα
◦ Object-Oriented Software Engineering Using UML, Patterns and
Java, B. Bruegge & A. Dutoit
◦ Software Engineering A Practitioner's Approach 7th edition
Roger S. Pressman.pdf
◦ Object-Oriented and Classical Software Engineering, Eighth
Edition, Stephen R. Schach
29
Η τεχνολογία λογισμικού ως
διαδικασία επίλυσης προβλημάτων
• Θα χρειαστούμε δύο βασικές διαδικασίες:
◦ Ανάλυση
◦ Κατανόηση της φύσης του προβλήματος και αποσύνθεσή του σε
τμήματα (μικρότερα επί μέρους προβλήματα) που είναι πιο
εύκολα στην αντιμετώπισή τους
◦ Σύνθεση
◦ Ολοκλήρωση επί μέρους λύσεων σε σύνολο που απαντά στο
σύνολο του προβλήματος
• Για την επίλυση του προβλήματος
χρησιμοποιούμε τεχνικές, μεθοδολογίες και
εργαλεία
Ανάπτυξη Λογισμικού
Ανάπτυξη λογισμικού
Απαιτήσεις Κατασκευή Λογισμικό
Ανάλυση Σχεδίαση Κωδικοποίηση Έλεγχος
35
Συμμετέχοντες, Εργασίες και

Αρμοδιότητες
• Πελάτης: εταιρία, οργανισμός ή φυσικό πρόσωπο που χρηματοδοτεί το έργο. Το
λογισμικό προορίζεται να υποστηρίξει τον πελάτη να πετύχει τους στόχους του.
• Χρήστες: αυτοί που τελικά θα «καθίσουν στον υπολογιστή» και θα
χρησιμοποιήσουν το λογισμικό.
• Ομάδα ανάπτυξης: αναλυτές, σχεδιαστές, προγραμματιστές, ελεγκτές, συντηρητές.
• Ομάδα διοίκησης: αποφασίζει για το που και πότε θα διατεθούν πόροι,
παραλαμβάνει & ελέγχει παραδοτέα, διαχειρίζεται τη σύμβαση με τον πελάτη.
• Ομάδα διασφάλισης ποιότητας: παρακολουθεί την εξέλιξη του έργου και προτείνει
ενέργειες για την εξασφάλιση της ποιότητας των παραδοτέων.
• Ωφελούμενοι από το λογισμικό: π.χ. από το λογισμικό γραμματείας ωφελούμενοι
είναι και οι φοιτητές, από λογισμικό ιατρικού φακέλου οι ασθενείς κ.ο.κ.
36
Συμμετέχοντες, Εργασίες και
Αρμοδιότητες
Ανάγκες, απαιτήσεις
Χρήστες Ομάδα ανάπτυξης

Λογισμικό
Στρατηγικός στόχος Πλάνο του έργου

Χρηματοδότηση
Πελάτης Συμβατικές Ομάδα διοίκησης

υποχρεώσεις
Ανάγκες
Μέτρα βελτίωσης ποιότητας
Απαιτήσεις για ποιότητα υπηρεσιών
Ομάδα διασφάλισης
Επωφελούμενοι
ποιότητας
37
Δραστηριότητες Ανάπτυξης (1/2)

• Προσδιορισμός Απαιτήσεων
◦ Προδιαγραφή του τι θα κάνει το σύστημα. Καταλήγει σε συμφωνία
με τον πελάτη που αποτυπώνεται στο Έγγραφο Προδιαγραφής
Απαιτήσεων Λογισμικού (ΕΠΑΛ)
• Σχεδίαση
◦ Το σύνολο των αποφάσεων που λαμβάνεται για των επίλυση του
προβλήματος που θέτουν οι απαιτήσεις. Διακρίνουμε δύο επίπεδα:
◦ Αρχιτεκτονική σχεδίαση: ο σκελετός του λογισμικού (αντίστοιχα με τα σχέδια
των κτηρίων)
◦ Λεπτομερής αρχιτεκτονική: οργάνωση και επικοινωνία λειτουργικών μονάδων
χαμηλότερου επιπέδου
◦ Παράγονται: Έγγραφο αρχιτεκτονικής λογισμικού και Έγγραφο
περιγραφής σχεδίου λογισμικού
38
Δραστηριότητες Ανάπτυξης (2/2)
• Κατασκευή
◦ Η συγγραφή του κώδικα και η παραγωγή του λογισμικού
• Έλεγχος
◦ Ελέγχουμε αν το λογισμικό έχει την επιθυμητή συμπεριφορά.
Εκτός από την ορθότητα ελέγχονται και άλλες παράμετροι, π.χ.
απόδοση, αξιοπιστία, μεταφερσιμότητα κ.λπ.
• Συντήρηση
◦ Όλες οι παραπάνω δραστηριότητες εκτελούνται για το προϊόν
που έχει ήδη παραδοθεί ώστε να τροποποιηθεί ή/και επεκταθεί η
λειτουργικότητα του λογισμικού.
39
Κόστος των φάσεων

Υπάρχει σημαντική αλλαγή στα ποσοστά
25%
33%
67% 75%
Ανάπτυξη Συντήρηση Ανάπτυξη Συντήρηση
1976-1981 1992-1998 40
Μέση Κατανομή Κόστους
Object-Oriented and Classical Software Engineer 5th Edition, Schach (2002)
41
Σχετικό κόστος διόρθωσης σφαλμάτων

Πότε διορθώνεται το σφάλμα;
Πότε Απαιτήσεις Αρχιτεκτονική Κατασκευή Έλεγχος Συντήρηση

δημιουργείται Συστήματος
το σφάλμα;
Απαιτήσεις 1 3 5-10 10 10-100
Αρχιτεκτονική - 1 10 15 25-100
Κατασκευή - - 1 10 10-25
42
Σχετικό κόστος διόρθωσης
σφαλμάτων
Το ίδιο
διαχρονικά
43
Ουσιαστικός ο εντοπισμός αρκετά

νωρίς
• Αν ο εντοπισμός γίνει στην αρχή...
◦ Αρκεί να διορθωθεί το σχετικό έγγραφο
• ... αν όμως γίνει αργά:

◦ Αλλαγή των εγγράφων προδιαγραφών
◦ Πιθανή αλλαγή στον σχεδιασμό
◦ Αλλαγή της υλοποίησης
◦ Δοκιμή της αλλαγής και των τυχόν επιπτώσεων που μπορεί να έχει σε άλλα
τμήματα
◦ Επανεγκατάσταση
44
Τι τύπου λάθη βρίσκουμε;
• Περίπου 60%-70% των σφαλμάτων στα μεγάλης
κλίμακας συστήματα εντοπίζονται στην ανάλυση
απαιτήσεων και τον σχεδιασμό
• Παράδειγμα: ανάλυση των επιθεωρήσεων από τα έργα
της Jet Propulsion Laboratory:
◦ 1.9 σφάλματα ανά σελίδα προδιαγραφών
◦ 0.9 σφάλματα ανά σελίδα σχεδιασμού
◦ 0.3 σφάλματα ανά σελίδα κώδικα
45
Μοντέλα κύκλου ζωής

• κύκλος ζωής : ο χρόνος από την σύλληψη της ιδέας
ανάπτυξης ενός προϊόντος μέχρι την απόσυρσή του
• Για να μπορέσουμε να επέμβουμε με σωστό τρόπο στις
μεθοδολογίες και στις τεχνικές ανάπτυξης του λογισμικού
πρέπει να έχουμε γνώση του τρόπου ανάπτυξης,
λειτουργίας και απόσυρσης του λογισμικού, των χρονικών
φάσεων που συνθέτουν τη ζωή του λογισμικού σ'
ολόκληρο τον κύκλο ζωής του.
• Τα μοντέλα κύκλου ζωής μας παρέχουν μία γενική
προσέγγιση για τον τρόπο ανάπτυξης του λογισμικού.
46
Μοντέλα κύκλου ζωής
• Μοντέλο κύκλου ζωής : μια απλοποιημένη περιγραφή
μιας διαδικασίας ανάπτυξης λογισμικού που
παρουσιάζεται από ορισμένη οπτική γωνία. Το μοντέλο
του κύκλου ζωής περιγράφει τον τρόπο οργάνωσης των
δραστηριοτήτων ανάπτυξης (απαιτήσεις, σχεδίαση,
κωδικοποίηση, έλεγχος) του λογισμικού.
• Διαδικασία ανάπτυξης λογισμικού (software process):
υιοθετεί ένα μοντέλο του κύκλου ζωής και το εξειδικεύει
περιγράφοντας μια ακολουθία βημάτων που έχουν ως
αποτέλεσμα την ανάπτυξη λογισμικού υψηλής ποιότητας
στο προβλεπόμενο χρόνο και στο προϋπολογισμένο
κόστος.
47
Μία απλοϊκή προσέγγιση

• Το βασικό μοντέλο «φτιάξε και διόρθωσε» (build & fix)
◦ Όλοι ξεκινάνε με αυτό!
Φτιάξε την
πρώτη έκδοση
Τροποποίησε μέχρι
να είμαστε ΟΚ
Συντήρηση μετά
την παράδοση
Ανάπτυξη
Συντήρηση
Απόσυρση
48
Μοντέλο «φτιάξε και διόρθωσε»
• Δεν λειτουργεί παρά μόνο για τις εργασίες των 2-3
πρώτων ετών στο Πανεπιστήμιο
◦ Μέγεθος κώδικα το πολύ 300-500 γραμμές
◦ Δεν υπάρχει σχεδιασμός του συστήματος
◦ Ανάγκη για συνεχείς αλλαγές στον κώδικα
◦ Δεν υπάρχει τυπικός ορισμός προδιαγραφών, άρα δεν
ξέρουμε πότε έχει ολοκληρωθεί η ανάπτυξη
◦ Δύσκολη η συντήρηση (χωρίς προδιαγραφές και σχεδιασμό,
συνήθως και χωρίς τεκμηρίωση...)
• Χρειάζεται να οριοθετήσουμε φάσεις με σαφή αρχή,
τέλος, παραδοτέα και ελέγχους ποιότητας!
49
Το Μοντέλο του Καταρράκτη
50
Το Μοντέλο του Καταρράκτη (συνέχεια)
• Ακολουθιακή οργάνωση των δραστηριοτήτων ανάπτυξης
◦ Κάθε φάση αξιολογείται από τη διοίκηση έργου και τον πελάτη και μετά
προχωράμε στην επόμενη
◦ Αν διαπιστώσουμε σφάλματα ή ελλείψεις, επιστρέφουμε στη σχετική
προγενέστερη φάση
• Αξιολόγηση
+ «Εύκολος» χρονικός προγραμματισμός και «απλή» διοίκηση έργου
- Προϋποθέτει σταθερότητα στις απαιτήσεις και την αρχιτεκτονική
Κάτι που συνήθως δεν ισχύει!
- Μικρή συμμετοχή τελικών χρηστών
Η εμπλοκή τους περιορίζεται στις απαιτήσεις και την αποδοχή
- Παραπλανητική εικόνα της πορείας του έργου
Τα αρχικά χρονοδιαγράμματα μπορούν να τηρούνται. Τι γίνεται όμως αν διαπιστωθεί
αργότερα σφάλμα;
- Δεν ευνοεί την ενεργητική διαχείριση κινδύνων
- Πολλοί κίνδυνοι θα διαγνωστούν σε αρκετά προχωρημένη φάση του έργου με πολύ
μικρά περιθώρια παρεμβάσεων
51
Το Επαυξητικό μοντέλο
• Στόχος να καλυφθούν αδυναμίες του
μοντέλου του καταρράκτη
• Το λογισμικό παραδίδεται σταδιακά με
επαυξήσεις (increments) που
εμπλουτίζουν τη λειτουργικότητα
• Επιδίωξη είναι να καλυφθεί σταδιακά
η συνολική λειτουργικότητα ώστε να
μειωθεί η πιθανότητα να αποκλίνει το
τελικό προϊόν από τις επιθυμίες του
πελάτη
52
Το επαυξητικό μοντέλο (συνέχεια)
• Παράδειγμα: έστω ότι αναπτύσσουμε λογισμικό
επεξεργασίας κειμένου
◦ Πρώτο παραδοτέο: βασικές λειτουργίες επεξεργασίας και
διαχείρισης αρχείων
◦ Δεύτερο παραδοτέο: προηγμένες λειτουργίες επεξεργασίες
κειμένου (π.χ. μεταφορά και εναπόθεση, «έξυπνος» χειρισμός
κενών κατά την αντιγραφή, αυτόματη διόρθωση)
◦ Τρίτο παραδοτέο: ορθογραφικός και γραμματικός έλεγχος
◦ Τέταρτο παραδοτέο: προηγμένες δυνατότητες προβολής
κειμένου (σελίδας, πολλαπλών σελίδων, διάρθρωσης
εγγράφου κ.λπ.)
53
Το Επαυξητικό μοντέλο (συνέχεια)

• Η λεπτομερής σχεδίαση και η κωδικοποίηση γίνεται
σταδιακά με παραγωγή νέων εκδόσεων του λογισμικού
+ Μεγαλύτερη ευελιξία σε σχέση με το μοντέλο του καταρράκτη
+ Βελτιωμένη διαχείριση κινδύνων και καλύτερη αξιολόγηση της
πορείας του έργου
- Προϋποθέτει σταθερότητα των απαιτήσεων και της αρχιτεκτονικής
του λογισμικού
54
Το σπειροειδές μοντέλο
• Μη γραμμική διαδοχή των δραστηριοτήτων ανάπτυξης -
Ανάπτυξη σε κύκλους.
• Σε κάθε κύκλο πραγματοποιούνται πολλές δραστηριότητες
χωρισμένες σε τέσσερις υπο-φάσεις:
◦ Καθορισμός στόχων, εναλλακτικών και περιορισμών
◦ Αξιολόγηση εναλλακτικών, εντοπισμός και διαχείριση κινδύνων
◦ Ανάπτυξη και επαλήθευση προϊόντος κύκλου
◦ Σχεδιασμός επόμενων κύκλων
• Οι αποφάσεις για τον προγραμματισμό κάθε κύκλου
καθορίζονται από τους κινδύνους του έργου
• Δημιουργία πρωτοτύπων (prototypes) ως μέσο μείωσης
των κινδύνων του έργου
55
Το Σπειροειδές Μοντέλο (συνέχεια)
56
• Παράδειγμα ανάλυσης επικινδυνότητας
Πρότυπο Εξήγηση Παράδειγμα
Στόχοι Ποιοί είναι οι Να αυξηθεί η ποιότητα του λογισμικού
στόχοι του έργου
Περιορισμοί Περιορισμοί που Εντός τριών ετών
υπάρχουν Χωρίς μεγάλη επένδυση κεφαλαίου
Χωρίς δραστικές αλλαγές στα πρότυπα που ακολουθεί η
εταιρεία
Εναλλακτικές Πιθανοί τρόποι Επαναχρησιμοποίηση ήδη υπάρχοντος πιστοποιημένου
επίτευξης των λογισμικού
στόχων Εισαγωγή τυπικών μεθόδων και επαλήθευσης
Επένδυση σε εργαλεία ελέγχου και επαλήθευσης
Κίνδυνοι Πιθανοί κίνδυνοι Δεν είναι εφικτή η αύξηση της ποιότητας χωρίς
υπέρμετρη αύξηση του κόστους
Οι νέες μέθοδοι μπορεί να οδηγήσουν σε αποχώρηση
προσωπικού
Αντιμετώπιση Πώς περιορίζονται Βιβλιογραφική μελέτη, πιλοτικό έργο, έρευνα για πιθανά
κινδύνων οι κίνδυνοι επαναχρησιμοποιήσιμα στοιχεία, αξιολόγηση της
υποστήριξης από εργαλεία, εκπαίδευση προσωπικού και
σεμινάρια για παροχή κινήτρων
57
• Παράδειγμα ανάλυσης επικινδυνότητας

Πρότυπο Εξήγηση Παράδειγμα
Αποτελέσματα Αποτελέσματα της Η εμπειρία σε τυπικές μεθόδους είναι περιορισμένη –
εφαρμογής των δεν είναι εύκολο να αξιολογηθούν οι βελτιώσεις
στρατηγικών Περιορισμένη υποστήριξη για εργαλεία που αφορούν
αντιμετώπισης πρότυπα ανάπτυξης λογισμικού σε εταιρικό
κινδύνων περιβάλλον
Υπάρχουν διαθέσιμα επαναχρησιμοποιήσιμα
στοιχεία, αλλά περιορισμένη υποστήριξη από
εργαλεία
Σχέδια Σχέδια ανάπτυξης Να διερευνηθεί η επαναχρησιμοποίηση πιο
για την επόμενη λεπτομερώς
φάση Να αναπτυχθούν πρότυπα εργαλεία υποστήριξης
της επαναχρησιμοποίησης
Διερεύνηση σχήματος πιστοποίησης στοιχείων
λογισμικού
Δέσμευση Δέσμευση πόρων Χρηματοδότηση 18μηνου έργου
για την επίτευξη
των σχεδίων
58
Το Σπειροειδές Μοντέλο
(συνέχεια)
• Οι πρώτοι κύκλοι είναι φθηνότεροι σε
ανθρωποπροσπάθεια, χρόνο, κόστος
• Κάθε πρόσθετος κύκλος αυξάνει το κόστος, μειώνοντας
τους κινδύνους
• Το πλήθος των κύκλων είναι αντιστάθμισμα
κόστους/χρόνου και διαχείρισης κινδύνων
59
Το σπειροειδές μοντέλο (συνέχεια)

+ Ενεργητική αντιμετώπιση κινδύνων
◦ Το μοντέλο βάζει τη διαχείρισή τους στο επίκεντρο
+ Προσαρμογή σε μεταβαλλόμενες απαιτήσεις
◦ Αν η μεταβολή απαιτήσεων αναγνωρισθεί ως κίνδυνος, λαμβάνονται
κατάλληλα μέτρα, π.χ. ανάπτυξη πρωτοτύπων. Αντίστοιχα, η αρχιτεκτονική του
λογισμικού μπορεί να διαγνωστεί ως κίνδυνος και να οδηγηθούμε σε ανάπτυξη
πρωτοτύπων
+ Καλύτερη συμμετοχή των χρηστών
◦ Η ανάπτυξη πρωτοτύπων που παρουσιάζονται στους χρήστες είναι βασικό
στοιχείο του μοντέλου
+ Βελτιωμένη αξιολόγηση της πορείας του έργου
◦ Κάθε κύκλος έχει παραδοτέα που αξιολογούνται. Η ύπαρξη κύκλων δίνει και
βραχυχρόνιους στόχους, για καλύτερο έλεγχο.
- Απαιτητική διοίκηση έργου
60
Το σπειροειδές μοντέλο
(συνέχεια)
• Ορόσημα σπειροειδούς μοντέλου
◦ Ορόσημο: ένα σημείο στον προγραμματισμό έργου που υποδεικνύει πόση
πρόοδος έχει γίνει στο έργο. Συνήθως συνοδεύεται και από παραδοτέο-
ορόσημο, που είναι ένα σαφές προϊόν (έγγραφο, λογισμικό).
• Στο σπειροειδές μοντέλο δεν υπάρχουν σαφή ορόσημα για τη

μακροσκοπική αξιολόγηση της πορείας του έργου, οπότε εισάγουμε
πρόσθετα:
◦ Διαπίστωση της εφικτότητας του συστήματος: έχουμε κατανοήσει το πρόβλημα;
Έχουμε καταγράψει τις βασικές ανάγκες; Έχουμε καλή εκτίμηση χρόνου-κόστους;
◦ Εντοπισμός και εξάλειψη των βασικών κινδύνων του έργου και ο ασφαλής
προσδιορισμός της αρχιτεκτονικής του λογισμικού
◦ Η αρχική παράδοση του λογισμικού στον πελάτη και τους χρήστες
61
Το Επαναληπτικό μοντέλο
• Το επαναληπτικό μοντέλο, όπως και το σπειροειδές, δεν έχει
γραμμική οργάνωση των δραστηριοτήτων ανάπτυξης.
• Η ανάπτυξη οργανώνεται σε επαναλήψεις (iterations) όπου σε κάθε
επανάληψη εκτελούνται όλες οι δραστηριότητες, ξεκινώντας από τον
προσδιορισμό απαιτήσεων και καταλήγοντας στην κωδικοποίηση και
τον έλεγχο
• Κάθε επανάληψη είναι μικρογραφία ενός έργου ανάπτυξης,
οδηγώντας στην παραγωγή ημιτελών εκτελέσιμων και επιτυχώς
ελεγμένων προγραμμάτων
◦ Η βαρύτητα της κάθε δραστηριότητας σε κάθε επανάληψη είναι διαφορετική:
στις πρώτες επαναλήψεις το βάρος είναι στις απαιτήσεις, στις επόμενες
μετακινείται στη λεπτομερή σχεδίαση, την κωδικοποίηση και τον έλεγχο
62
(συνέχεια)
Ε1 Ε2 Ε3 ... Εν
63
(συνέχεια)
• Τα εκτελέσιμα προγράμματα δεν είναι απαραίτητο να
παρουσιάζονται στους χρήστες – μπορούν να
παραμένουν εσωτερικά στη ομάδα ανάπτυξης. Κάποια
μπορούν ωστόσο να παρουσιάζονται στους χρήστες
• Τα πρωτότυπα επίσης παρέχουν ανατροφοδότηση στην
ομάδα. Κάθε πρωτότυπο έχει έναν βαθμό
λειτουργικότητας και κάθε επόμενο πρωτότυπο τον
επαυξάνει, καταλήγοντας στο τελικό λογισμικό.
• Η διαδικασία ονομάζεται και εξελικτική
πρωτοτυποποίηση.
64
(συνέχεια)
• Χρονική πλαισίωση (timeboxing)
◦ Μία πρακτική του επαναληπτικού μοντέλου, σύμφωνα με την οποία η
ημερομηνία λήξης των επαναλήψεων δεν μετατίθεται. Αν έχουν γίνει
λιγότερα απ’ όσα είχαν σχεδιαστεί παραδίδονται μόνον αυτά.
◦ Σκεπτικό:
◦ Στο τέλος κάθε επανάληψης θέλουμε ελεγμένα προγράμματα. Μπορούμε να
αναβάλλουμε δραστηριότητες για επόμενες φάσεις, αλλά το προϊόν της
επανάληψης πρέπει να είναι ελεγμένο.
◦ Οι επαναλήψεις θέτουν βραχυχρόνιους στόχους (τυπικά: 1-6 εβδομάδες) που
παρακολουθούνται ευκολότερα και δίνουν αίσθηση προόδου.
◦ Στο τέλος κάθε επανάληψης έχουμε και ανασκόπησή της, η οποία καθοδηγεί το
έργο της επόμενης. Έτσι ελέγχουμε την πορεία του έργου, διαπιστώνουμε
προβλήματα και καθυστερήσεις και λαμβάνουμε κατάλληλα μέτρα.
65
Το Επαναληπτικό μοντέλο (συνέχεια)

+ Άριστη προσαρμογή σε μεταβαλλόμενες απαιτήσεις
◦ Δίνει τη δυνατότητα να δοκιμάζεται η αρχιτεκτονική με τον έλεγχο των εκτελέσιμων
προγραμμάτων
+ Δυνατότητες για ενεργητική αντιμετώπιση κινδύνων του έργου
◦ Εξαιρετικό για τις αλλαγές στις απαιτήσεις, πολύ καλό για τους κινδύνους της
αρχιτεκτονικής. Αντιμετωπίζονται οι κίνδυνοι για την τελική ποιότητα με τους
ελέγχους σε κάθε επανάληψη. Έγκαιρος εντοπισμός των κινδύνων,
προτεραιοποίησή τους και εξάλειψη των σοβαρότερων στην αρχή.
+ Ενθάρρυνση ενεργούς και διαρκούς συμμετοχής των χρηστών
◦ Σε κάθε επανάληψη οι χρήστες συμμετέχουν από τα αρχικά στάδια και διατηρείται
ως την τελική παράδοση.
+ Άριστη παρακολούθηση της πορείας του έργου με τον καθορισμό
βραχυχρόνιων στόχων
+ Πιο ευέλικτο από το σπειροειδές μοντέλο, με πιο πολλά περιθώρια
προσαρμογής και ταχύτερη εισαγωγή διορθωτικών κινήσεων
66
(συνέχεια)
• Αξιολόγηση: κίνδυνοι
◦ Η μακροχρόνια συμμετοχή των χρηστών ενέχει τον κίνδυνο να
μην είναι διαθέσιμοι οι χρήστες σε όλη την πορεία ανάπτυξης του
έργου
◦ Πολύ απαιτητική διαδικασία διοίκησης του έργου
◦ «Εκφυλισμός» σε μοντέλο καταρράκτη από αναβολή διαδικασιών
◦ Π.χ. Μη έλεγχος των εκδόσεων στο τέλος της κάθε επανάληψης αλλά
αναβολή του ελέγχου για το τέλος.
67
Επαναληπτικό μοντέλο και

πρωτοτυποποίηση
• Το επαναληπτικό μοντέλο είναι πλέον το κυρίαρχο μοντέλο του κύκλου ζωής του
λογισμικού.
• Παρέχει μεγάλη ευελιξία στον τρόπο που παραδίδεται το λογισμικό
• Εξελικτική πρωτοτυποποίηση (evolutionary prototyping). Με την ολοκλήρωση
κάποιων επαναλήψεων παραδίδονται πρωτότυπα στον πελάτη για αξιολόγηση και
ανατροφοδότηση
• Εξελικτική παράδοση (evolutionary delivery). Με την ολοκλήρωση κάποιων
επαναλήψεων παραδίδονται στον πελάτη εκδόσεις του λογισμικού προς χρήση.
68
Λίγα λόγια για το λογισμικό [1/4] (με
άμεση εφαρμογή στην εργασία)
• Το λογισμικό είναι προϊόν
◦ Πρέπει να ικανοποιεί τον πελάτη
◦ Μερικές φορές αυτό που θέλει ο πελάτης είναι διαφορετικό από αυτό που
χρειάζεται. Εδώ θα πρέπει να τον βοηθήσουμε
◦ Πρέπει να είναι ποιοτικό
• Απαιτήσεις και προδιαγραφές
◦ Χρηστικότητα
◦ Εξελιξιμότητα-επεκτασιμότητα
• Διαχείριση του έργου ανάπτυξης
◦ Ανθρώπινοι παράγοντες
◦ Οικονομικοί, επιχειρηματικοί, νομικοί και κοινωνικοί παράγοντες
69
Ακόμα και μέσα στην ομάδα δεν

είναι πάντα καλή η συνεργασία…
70
• Σχεδιασμός λογισμικού
◦ Αρχιτεκτονική λογισμικού
◦ Αντικειμενοστρεφής σχεδιασμός
• Αξιοπιστία συστημάτων
◦ Αξιοπιστία και επαλήθευση
• Διαχείριση «παλαιών» (legacy) συστημάτων
• Γενικά χαρακτηριστικά
◦ Χρηστικότητα, συντηρησιμότητα, αποδοτικότητα, αξιοπιστία
• Προφανώς απαιτείται καλός προγραμματισμός ΑΛΛΑ ο καλός
προγραμματισμός ΔΕΝ αρκεί
◦ Η ποιότητα του προγραμματισμού είναι εργαλείο, ΟΧΙ ο σκοπός
71

• Ο πελάτης
◦ Είναι αυτός που πληρώνει και περιμένει το λογισμικό
◦ Το κύριο μέτρο επιτυχίας είναι η ικανοποίηση του πελάτη
◦ Μερικές φορές δεν είναι σαφές ποιος είναι: ποιος είναι ο πελάτης
για το Excel; Για την Oracle;
• Κατηγορίες λογισμικού
◦ Γενικής χρήσης (π.χ. Excel)
◦ Ειδικής χρήσης (π.χ. TAXIS, δημοτολόγιο, διαχείριση αποθήκης)
◦ Μπορούμε να εξειδικεύσουμε ένα λογισμικό γενικής χρήσης
72
• Τα προϊόντα λογισμικού έχουν μεγάλη ποικιλομορφία
◦ Οι απαιτήσεις των πελατών είναι πολύ διαφορετικές μεταξύ τους
◦ Δεν υπάρχει 100% τυποποιημένος τρόπος για την διαδικασία
ανάπτυξης λογισμικού
◦ Δεν υπάρχει μοναδική επιλογή για βέλτιστη γλώσσα, βέλτιστο
λειτουργικό, βέλτιστο υλικό, βέλτιστο περιβάλλον ανάπτυξης κ.ο.κ.
◦ Βασική δεξιότητα είναι η γνώση πολλών μεθόδων, εργαλείων και
προσεγγίσεων, η δυνατότητα επιλογής των καταλληλότερων και η
αποτελεσματική εφαρμογή τους.
73
Το λογισμικό ως προϊόν
• Πακέτο - “COTS”
◦ Αυτόνομα συστήματα που παράγονται από ένα οίκο λογισμικού και πωλούνται
στην αγορά σε κάθε ενδιαφερόμενο
• Customized λογισμικό
◦ Συστήματα που αφορούν συγκεκριμένο πελάτη και έχουν αναπτυχθεί στα
πλαίσια συγκεκριμένων συμβολαίων για λογαριασμό του
• Συνδυασμός
◦ Συστήματα που έχουν αναπτυχθεί αλλά απαιτούν παραμετροποίηση σε κάθε
εγκατάσταση
74
Επαγγελματική δεοντολογία
• Η ανάθεση από τον πελάτη ενός έργου ανάπτυξης λογισμικού
σημαίνει ότι σας δείχνει εμπιστοσύνη:
◦ Ότι είστε ικανοί: λογισμικό που δεν λειτουργεί καλά μπορεί να καταστρέψει
έναν οργανισμό
◦ Ότι είστε εχέμυθοι: μπορεί να έχετε πρόσβαση σε ιδιαίτερα ευαίσθητα
δεδομένα (οικονομικά, ιατρικά, εμπορικά μυστικά, κ.λπ.)
◦ Νομικές πτυχές: η νομοθεσία για το λογισμικό είναι αρκετά περίπλοκη
(πνευματικά δικαιώματα, προσωπικά δεδομένα, ευθύνη του προγραμματιστή
κ.λπ.)
◦ Αποδεκτή χρήση και κατάχρηση. Ακόμη και η νομότυπη χρήση μπορεί να
οδηγήσει σε προβλήματα, π.χ. επιθέσεις τύπου DOS (worms, μαζική αποστολή
e-mail, κ.ο.κ.)
75

ENGINEERING)
Διαχείριση πολυπλοκότητας, έννοιες, επισκόπηση
UML, βασικοί συμβολισμοί και διαγράμματα
1
Θέματα που θα παρουσιάσουμε
• Διαχείριση πολυπλοκότητας
◦ Αφαίρεση και μοντελοποίηση
◦ Αποσύνθεση
◦ Ιεραρχίες
◦ Έννοιες συστημάτων
◦ Ανάπτυξη βασιζόμενη σε μοντέλα
• Επισκόπηση UML
◦ Γενικά για τη UML
Ποιο είναι το πρόβλημα με το

διάγραμμα που βλέπουμε;
3
Αφαίρεση
• Τα πολύπλοκα συστήματα είναι δύσκολο να κατανοηθούν
◦ Το φαινόμενο του 7 ± 2: η βραχυπρόθεσμη μνήμη μας (short term memory)
μπορεί να αποθηκεύσει 7 ± 2 ταυτόχρονα (περιορισμός του εγκέφαλου).
◦ Ο αριθμός μητρώου: 2025200100056
• Κατάτμηση (chunking):
◦ Ομαδοποίηση αντικειμένων για μείωση πολυπλοκότητας
◦ Κωδικός τμήματος, έτος εγγραφής, αριθμός έτους
Αριθμός μητρώου
Κωδικός τμήματος Έτος εγγραφής Αριθμός έτους

4
Αφαίρεση
• Η αφαίρεση μας επιτρέπει να αγνοήσουμε λεπτομέρειες
που (στην εκάστοτε φάση) δεν είναι σημαντικές
• Μπορούμε να θεωρήσουμε την αφαίρεση από δύο
προοπτικές:
◦ Η αφαίρεση ως δραστηριότητα:
◦ Η αφαίρεση είναι μία διαδικασία συλλογισμού όπου οι ιδέες διαχωρίζονται
από τα αντικείμενα
◦ Η αφαίρεση ως οντότητα:
◦ Η αφαίρεση είναι η ιδέα που προκύπτει από μία διαδικασία συλλογισμού,
στην οποία οι ιδέες έχουν διαχωριστεί από τα αντικείμενα
• Οι ιδέες μπορούν να εκφράζονται μέσω μοντέλων
5
Μοντέλα
• Το μοντέλο είναι η αφαίρεση ενός
συστήματος
• Χρήσιμο για:
◦ Συστήματα που δεν υπάρχουν πια
◦ Συστήματα που υπάρχουν
◦ Συστήματα που πρόκειται να
κατασκευαστούν στο μέλλον
Χρήση μοντέλων για περιγραφή

συστήματα λογισμικού
• Υπάρχουν διάφορα μοντέλα:
◦ Το μοντέλο αντικειμένων: ποια είναι η δομή του συστήματος;
◦ Το λειτουργικό μοντέλο: Ποιες είναι οι λειτουργίες του συστήματος;
◦ Το δυναμικό μοντέλο: Πώς αντιδρά το σύστημα στα εξωτερικά συμβάντα;
• Μοντέλο συστήματος: Μοντέλο αντικειμένων + Λειτουργικό

Μοντέλο + Δυναμικό μοντέλο
7
Ποια άλλα μοντέλα χρησιμοποιούμε για
περιγραφή συστημάτων λογισμικού; [1/3]
• Μοντέλο δράσεων (task model)
◦ Διάγραμμα PERT (program evaluation review technique): ποιες
είναι οι εξαρτήσεις μεταξύ των δράσεων;
◦ Στόχος να αποτυπωθούν οι δράσεις, οι εξαρτήσεις και οι διάρκειες και να
βρεθεί η κρίσιμη διαδρομή που δίνει τη διάρκεια του έργου
◦ Το διάγραμμα pert του παραδείγματος έχει δύο κρίσιμες διαδρομές, (10  30
 40  50) και (10  20  50) που δίνουν διάρκεια έργου 7 μήνες.

• Μοντέλο δράσεων (task model)
◦ Χρονοπρογραμματισμός (schedule): Πώς μπορεί να επιτευχθεί ο στόχος
μέσα σε χρονικό όριο;
◦ Οργανωτικό διάγραμμα: ποιοι είναι οι ρόλοι εντός του έργου;
9
• Μοντέλο ζητημάτων (issues model)
◦ Ποια ζητήματα είναι ανοικτά και ποια έχουν κλείσει;
◦ Τι με εμποδίζει από το να συνεχίσω;
◦ Ποιοι οι περιορισμοί που έχουν τεθεί από τον πελάτη;
◦ Ποιες αποφάσεις πρέπει να ληφθούν;
◦ ... όλα αυτά οδηγούν σε ενέργειες που πρέπει να γίνουν
10
Παράδειγμα μοντέλου ζητημάτων

Πού να
κωδικοποιήσω
τον έλεγχο;
Πρόταση 1: Πρόταση 2:
Στη διεπαφή Στη βάση
χρήστη δεδομένων
Υπέρ: Κατά: Υπέρ:

Ταχύτερη Ο έλεγχος δεν καλύπτει
Καλύπτονται όλες
ανταπόκριση για εναλλακτικές μεθόδους
οι μέθοδοι
τον χρήστη εισαγωγής στη Β.Δ.
εισαγωγής
Κατά:
Κατά:
Αν η Javascript είναι
Λιγότερο φιλικό
απενεργοποιημένη, δεν
μήνυμα σφάλματος
λειτουργεί
11
Πού να
κωδικοποιήσω Απόφαση 1: επιλέγουμε
τον έλεγχο; το (2) γιατί οι χρήστες
είναι λίγοι και ειδικοί
Πρόταση 1: Πρόταση 2:
Στη διεπαφή Στη βάση
χρήστη δεδομένων

οι μέθοδοι
εισαγωγής
Κατά:
Κατά:
λειτουργεί 12

Απόφαση 2: επιλέγουμε Πού να Απόφαση 1: επιλέγουμε
το (1) γιατί η εφαρμογή κωδικοποιήσω το (2) γιατί οι χρήστες
χρησιμοποιείται και τον έλεγχο; είναι λίγοι και ειδικοί
από άλλους χρήστες
Πρόταση 1: Πρόταση 3: Πρόταση 2:

Στη διεπαφή Και στα δύο Στη βάση
χρήστη επίπεδα δεδομένων

οι μέθοδοι
εισαγωγής
Κατά:
Κατά:
λειτουργεί 13
Τεχνική αντιμετώπισης πολυπλοκότητας:
αποσύνθεση [1/8]
• Η αποσύνθεση (decomposition) είναι μία τεχνική για να
αντιμετωπίσουμε την πολυπλοκότητα που ακολουθεί τη
στρατηγική διαίρει και βασίλευε (divide and conquer)
• Δύο κύριοι τύποι αποσύνθεσης:
◦ Λειτουργική αποσύνθεση
◦ Αντικειμενοστρεφής αποσύνθεση
• Λειτουργική αποσύνθεση
◦ Το σύστημα αποσυντίθεται σε ενότητες
◦ Κάθε ενότητα είναι μία μείζων λειτουργία της εφαρμογής
◦ Οι ενότητες μπορούν να αποσυντίθενται σε μικρότερες ενότητες
14

• Παράδειγμα λειτουργικής αποσύνθεσης (με χρήση
διαγραμμάτων ροής δεδομένων)
(1) σύστημα και αλληλεπιδρώσες οντότητες περιβάλλοντος
15
(2) περαιτέρω ανάλυση του συστήματος δανεισμού
16

(3) περαιτέρω ανάλυση της λειτουργίας διαχείρισης δανεισμού
17
• Αντικειμενοστρεφής αποσύνθεση
◦ Το σύστημα αποσυντίθεται σε κλάσεις (αντικείμενα)
◦ Κάθε κλάση είναι μία μείζων οντότητα της εφαρμογής
◦ Οι κλάσεις μπορούν να αποσυντίθενται σε μικρότερες κλάσεις
• Ποια αποσύνθεση είναι καλύτερη; Λειτουργική ή
αντικειμενοστρεφής;
18

• Η λειτουργικότητα συνήθως διατέμνει όλη την έκταση του συστήματος
◦ Π.χ. αλλαγή στη μοντελοποίηση ενός φοιτητή  συντήρηση δομών αποθήκευσης,
οθονών παρουσίασης & εισαγωγής στοιχείων, βάσης δεδομένων, κώδικα που χειρίζεται
οποιοδήποτε στοιχείο του φοιτητή
◦ Άρα ο συντηρητής πρέπει να κατανοεί όλο το σύστημα για να κάνει τις αλλαγές
• Συνέπεια
◦ Ο κώδικας γίνεται δυσχερής στην κατανόηση
◦ Ο κώδικας γίνεται πολύπλοκος και σχεδόν αδύνατο να συντηρηθεί
◦ Η διεπαφή του χρήστη δεν είναι διαισθητική
◦ Οι αναπαραστάσεις δεδομένων στη βάση είναι ημιβέλτιστες
• Έχει αποδειχθεί ότι η λειτουργική προσέγγιση δεν μπορεί να ανταποκριθεί σε
έργα άνω των 5.000-50.000 γραμμών κώδικα (συνήθη μεγέθη σήμερα: 50.000-
5.000.000)
• Οι συνέπειες είναι πολύ σημαντικές, διότι το 60%-75% του προϋπολογισμού για
λογισμικό σχετίζεται με τη συντήρηση
19
• Παράδειγμα: Λειτουργική αποσύνθεση στα «αυτόματα
σχήματα» του Microsoft Office
Autoshape
Change D raw
Change Change Change D raw D raw D raw

Rectangle Oval Circle Rectangle Oval Circle
Τι θα συμβεί αν προσθέσουμε ένα καινούργιο σχήμα;

– Πρέπει σε όλες τις λειτουργίες να προβλέψουμε εξειδίκευση για το νέο
είδος σχήματος
20

• Αντικειμενοστρεφής αποσύνθεση
Autoshape
Draw()
Change()
Rectangle Oval Circle
Draw() Draw() Draw()

Change() Change() Change()
21
Προσδιορισμός κλάσεων
• Βασική πράξη στην αντικειμενοστρεφή αποσύνθεση
◦ Είναι δυνατόν να γίνεται για ένα νέο σύστημα (σχεδιασμός εξ
αρχής - greenfield engineering)
◦ Είναι δυνατόν να γίνεται για ένα υπάρχον σύστημα
(ανασχεδιασμός – reengineering)
◦ Είναι δυνατόν να θέλουμε να φτιάξουμε μία βασισμένη σε κλάσεις
διεπαφή για ένα υπάρχον σύστημα (σχεδιασμός διεπαφών –
interface engineering)
• Ανάλογα με τον σκοπό του συστήματος μπορούμε να
εντοπίσουμε αντικείμενα διαφορετικού είδους
• Συνεπώς πρώτα προσδιορίζουμε τον σκοπό του
συστήματος!
22
Προσδιορισμός κλάσεων ανάλογα

με τον σκοπό
• Παράδειγμα: «συγγράμματα μαθήματος»
◦ Σκοπός: να καταγράφονται τα συγγράμματα για τον οδηγό
σπουδών
◦ Αρκεί η κλάση «Μάθημα» όπου υπάρχει ένα πεδίο κειμένου «Συγγράμματα»
◦ Να αποστέλλεται ενημερωτικό e-mail στους φοιτητές που
παρακολουθούν το μάθημα όταν είναι διαθέσιμο το σύγγραμμα
στη βιβλιοθήκη
◦ Χρειάζεται και η κλάση «Φοιτητής» που έχει τουλάχιστον το e-mail και
σύνδεση μεταξύ κλάσεων «Μάθημα» και «Φοιτητής»
◦ Να γίνονται παραγγελίες βιβλίων
◦ Χρειάζονται ξεχωριστές κλάσεις «Σύγγραμμα», «Εκδοτικός οίκος», «Δήλωση
μαθημάτων» (για έλεγχο) κ.λπ.
23
Ιεραρχία
• Μέσω της αφαίρεσης προσδιορίζουμε κλάσεις και
αντικείμενα
◦ Που ουσιαστικά είναι τμήματα πληροφορίας
• Ένας συμπληρωματικός τρόπος για να αντιμετωπίσουμε
την πολυπλοκότητα είναι να εγκαθιδρύσουμε συσχετίσεις
ανάμεσα στα τμήματα
• Μία από τις πιο σημαντικές συσχετίσεις είναι η ιεραρχία
• Και από όλες τις ιεραρχίες, υπάρχουν δύο με μεγάλο
ενδιαφέρον:
◦ «τμήμα-του» (part of)
◦ «είναι-ένα» (is-a ή is-kind-of)
24
Παράδειγμα ιεραρχίας «τμήμα-του»

(συνάθροιση)
Υπολογιστής
Συσκευές
εισόδου- Κ.Μ.Ε. Μνήμη
εξόδου
Αριθμητική-
Κρυφή
Λογική Καταχωρητές
μνήμη
Μονάδα
25
Παράδειγμα ιεραρχίας «είναι-ένα»
(ταξονομία)
Συσκευές
εισόδου-
εξόδου
Συσκευές Συσκευές
Συσκευές
αποθήκευσης εισόδου
δικτύου
δεδομένων χρήστη
Σκληρός Flash Μαγνητική Πληκτρο-

Ποντίκι Joystick
δίσκος disk ταινία λόγιο
26
Σύνοψη
• Έχουμε τρεις τρόπους να χειριστούμε την πολυπλοκότητα
◦ Αφαίρεση, αποσύνθεση, ιεραρχία
• Η αντικειμενοστρεφής αποσύνθεση είναι καλή προσέγγιση
◦ Ανάλογα όμως με τον σκοπό του συστήματος μπορούμε να καταλήξουμε σε
διαφορετικά αντικείμενα
• Μπορούμε να οδηγηθούμε στα σωστά αντικείμενα;
◦ Πρέπει να ξεκινήσουμε με μία περιγραφή της λειτουργικότητας του
συστήματος, μετά να συνεχίσουμε στην περιγραφή της δομής του.
◦ Σημαντική είναι επίσης η οριοθέτηση του συστήματος τι ανήκει δηλαδή στο
σύστημα και τι όχι
• Διατάσσουμε τις δραστηριότητες
◦ Η διάταξη μας οδηγεί στον κύκλο ζωής του λογισμικού
27
Συστήματα
• Ένα σύστημα είναι ένα οργανωμένο σύνολο από
αλληλεπιδρώντα μέρη
◦ Στα φυσικά συστήματα, δεν είναι γνωστός ο σκοπός του
◦ Στα σχεδιασμένα συστήματα, ο σκοπός τους είναι αυτός για τον
οποίο φτιάχτηκαν
• Τα τμήματα των συστημάτων μπορεί να θεωρηθούν με τη
σειρά τους ως συστήματα
◦ Αυτά καλούνται υποσυστήματα
• Παραδείγματα συστημάτων
◦ Φυσικά: σύμπαν, γη, ωκεανός
◦ Σχεδιασμένα: Αεροπλάνο, ρολόι, GPS
◦ Υποσυστήματα: τουρμπίνα, μπαταρία, δορυφόρος
28
Συστήματα, Μοντέλα, Όψεις,

Σημειογραφίες
• Ένα μοντέλο είναι μία αφαίρεση που περιγράφει ένα σύστημα
ή ένα υποσύστημα
• Μία όψη απεικονίζει συγκεκριμένες πλευρές ενός μοντέλου
• Μία σημειογραφία είναι ένα σύνολο από κανόνες για την
αναπαράσταση μοντέλων είτε με γραφικό τρόπο είτε με
κείμενο
◦ Υπάρχουν τόσο τυπικές συντομογραφίες όσο και άτυπες
• Παραδείγματα για το σύστημα: αεροπλάνο
◦ Μοντέλα: εξομοιωτής πτήσης, μοντέλο κλίμακας
◦ Όψεις: σχέδια των συνιστωσών του αεροπλάνου, διάγραμμα
καλωδιώσεων ρεύματος, σύστημα καυσίμων, το ηχητικό κύμα που
δημιουργεί το αεροπλάνο
29
Συστήματα, μοντέλα, Όψεις, Σημειογραφίες –
άτυπη αναπαράσταση
Εξομοιωτής
Αεροπλάνο πτήσης Σύστημα
καυσίμων
Μοντέλο 2
Όψη 2
Όψη 1
Σύστημα
Όψη 3
Μοντέλο 1
Σχέδια Καλωδιώσεις
ρεύματος
Μοντέλο κλίμακας
Οι όψεις και τα μοντέλα σε πολύπλοκα συστήματα συνήθως επικαλύπτονται
30
Συστήματα, μοντέλα, Όψεις, Σημειογραφίες

– σημειογραφία UML
Διάγραμμα κλάσεων
* *
Σύστημα Μοντέλο Όψη
Περιγράφεται από Απεικονίζεται από
Αεροπλάνο: Διάγραμμα
Σύστημα αντικειμένων
Μοντέλο κλίμακας:Μοντέλο Εξομοιωτής πτήσης:Μοντέλο
Σχέδιο: Σύστημα καυσίμων: Ηλεκτρικές καλωδιώσεις:

Όψη Όψη Όψη
31
Ανάπτυξη καθοδηγούμενη από μοντέλα
(model-driven development) [1/2]
• Είναι η «τελευταία λέξη» στην ανάπτυξη λογισμικού
1. Δημιουργία ενός ανεξάρτητου από πλατφόρμα μοντέλου της
λειτουργικότητας και της συμπεριφοράς της εφαρμογής
a. Περιγράφεται το μοντέλο με σημειογραφία μοντελοποίησης (UML)
b. Μετατρέπεται το μοντέλο σε μοντέλο για συγκεκριμένη πλατφόρμα
(platform specific)
2. Δημιουργία εκτελέσιμου από το μοντέλο για συγκεκριμένη
πλατφόρμα
32
Ανάπτυξη καθοδηγούμενη από μοντέλα

(model-driven development) [2/2]
• Πλεονεκτήματα:
◦ Ο κώδικας παράγεται (σε κάποιο βαθμό) από τα μοντέλα
◦ Το ανεξάρτητο από πλατφόρμα μοντέλο παραμένει
σταθερό, ανεξάρτητα από την πρόοδο της τεχνολογίας
◦ Η μεταφερσιμότητα και η διαλειτουργικότητα είναι
ενσωματωμένες στο μοντέλο ανάπτυξης
◦ Δείτε: http://www.omg.org/mda
◦ OMG: Object Management Group
33
Ανάπτυξη λογισμικού καθοδηγούμενη
από μοντέλα [1/2]
• Ξεκινάμε με αποτύπωση της πραγματικότητας
◦ Σε ένα χρηματιστήριο υπόκεινται σε διαπραγμάτευση μετοχές πολλών
εταιρειών. Κάθε εταιρεία προσδιορίζεται από μία συντομογραφία
• Συνεχίζουμε με την ανάλυση που μας δίνει το μοντέλο

δεδομένων ανάλυσης (ή μοντέλο πεδίου) [διάγραμμα κλάσεων
UML)
StockExchange * * Company
Lists tickerSymbol
Είναι σωστή η πληθικότητα * στις δύο πλευρές της συσχέτισης;
34
Ανάπτυξη λογισμικού
καθοδηγούμενη από μοντέλα [2/2]
• Ακολουθεί η υλοποίηση (παράδειγμα σε Java)
public class StockExchange {

public m_Company = new Vector();
};
public class Company {

public int m_tickerSymbol;
public Vector m_StockExchange = new Vector();
};
35
Παράδειγμα ανάπτυξης καθοδηγούμενης από
μοντέλα: Apache Cordova
• Περιβάλλον ανάπτυξης για εφαρμογές κινητών
τηλεφώνων / smartphones
◦ Βασίζεται στις τεχνολογίες HTML, CSS & JS
◦ Η ανάπτυξη γίνεται μία φορά και λειτουργεί σε όλες τις
συσκευές
◦ Δωρεάν διάθεση, ανοικτός κώδικας
◦ Αντίστοιχα υπάρχουν και άλλες πλατφόρμες π.χ. Adobe
phonegap, Appcelerator
36
Παράδειγμα ανάπτυξης καθοδηγούμενης από

μοντέλα: Apache Cordoba
37
Παράδειγμα
ανάπτυξης
καθοδηγούμενης
από μοντέλα:
Apache Cordoba
38
Η UML – Unified Modeling Language

• Πρότυπο που δεν ανήκει σε συγκεκριμένο κατασκευαστή
(nonproprietary) για τη μοντελοποίηση συστημάτων (όχι
μόνο λογισμικού)
◦ Σύγκλιση συμβολισμών που χρησιμοποιούνται σε
αντικειμενοστρεφείς μεθόδους
◦ OMT (James Rumbaugh and colleagues)
◦ Booch (Grady Booch)
◦ OOSE (Ivar Jacobson)
• Συντηρείται από τον OMG, τρέχουσα έκδοση 2.5
◦ Δείτε: http://www.uml.org/
• Εμπορικά εργαλεία: Rational (IBM),Together (Borland), Visual
Architect (business processes, BCD)
• Εργαλεία ανοικτού λογισμικού: ArgoUML, StarUML, Umbrello
39
UML: χρειάζεται όλη;
• Στην έκδοση 2.5:
◦ 794 σελίδες για τον προσδιορισμό της γλώσσας!
• Ευτυχώς ισχύει ο κανόνας Pareto (κανόνας «σημαντικών
ολίγων» ή κανόνας 80-20)
◦ Στην περίπτωσή μας: «Με το 20% της UML μπορούμε να
μοντελοποιήσουμε πλήρως το 80% των προβλημάτων»
◦ Θα εστιάσουμε στο συγκεκριμένο 20%
40
Βασικά διαγράμματα
• Διαγράμματα περιπτώσεων χρήσης (use case diagrams)
◦ Περιγράφουν τη λειτουργική συμπεριφορά του συστήματος από την οπτική
του χρήστη
• Διαγράμματα κλάσεων
◦ Περιγράφουν τη στατική δομή του συστήματος:
• Διαγράμματα ακολουθίας
◦ Περιγράφουν τη δυναμική συμπεριφορά ανάμεσα σε αντικείμενα του
• Διαγράμματα μηχανής καταστάσεων
◦ Περιγράφουν τη δυναμική συμπεριφορά μεμονομένων αντικειμένων
• Διαγράμματα δραστηριότητας
◦ Περιγράφουν τη δυναμική συμπεριφορά του συστήματος, και συγκεκριμένα
της ροής εργασιών
41
Βασικοί συμβολισμοί της UML
• H UML χρησιμοποιεί γραφικές αναπαραστάσεις με μορφή
γραφημάτων που έχουν κόμβους και ακμές
◦ Οι κόμβοι αναπαριστούν οντότητες και σημειώνονται με:
◦ Παραλληλόγραμμα αν πρόκειται για κλάσεις ή στιγμιότυπα
◦ Ελλείψεις αν πρόκειται για λειτουργίες
• Τα ονόματα των κλάσεων δεν υπογραμμίζονται
◦ Book
• Τα ονόματα των στιγμιοτύπων υπογραμμίζονται
◦ DonQuixote:Book
• Μία ακμή μεταξύ δύο κόμβων δηλώνει μία συσχέτιση
μεταξύ των κόμβων
42
Μια γρήγορη ματιά: Διαγράμματα

περιπτώσεων χρήσης
• Οι περιπτώσεις χρήσης χρησιμοποιούνται για την
εξαγωγή (elicitation) και περιγραφή των
λειτουργικών απαιτήσεων
• Είναι διηγήσεις χρήσης του συστήματος
λογισμικού – κάνουν συστηματική την καταγραφή
των σεναρίων αλληλεπίδρασης του συστήματος
με το περιβάλλον του
43
Μια γρήγορη ματιά: Διαγράμματα περιπτώσεων
χρήσης
Κατηγοριοποίηση
Μάθημα Περίπτωση
Δώσε χρήσης
διάλεξη
Διδάσκων
Actor Βάλε
εργασία
Φοιτητής
Βοηθός Λύσε την Όριο

διδασκαλίας εργασία συστήματος
Τα διαγράμματα περιπτώσεων χρήσης αναπαριστούν τη
λειτουργικότητα του συστήματος από την προοπτική του χρήστη
44

κλάσεων
• Είναι διαγράμματα που απεικονίζουν τη στατική δομή
του συστήματος, δείχνοντας κλάσεις, ιδιότητες,
λειτουργίες και σχέσεις μεταξύ κλάσεων
• Χρησιμοποιούνται στην ανάλυση των απαιτήσεων και
στη σχεδίαση του λογισμικού
◦ Μοντελοποιούν αντικείμενα που θα είναι και τα δομικά
στοιχεία του λογισμικού που θα αναπτύξουμε
• Θεωρούνται από τα σημαντικότερα διαγράμματα της
UML
45
Μια γρήγορη ματιά: Διαγράμματα κλάσεων
Συσχέτιση
Κλάση
Πολλαπλότητα SimpleWatch
1 1 1 1
2 1 2 1
PushButton Display Battery Time
Τα διαγράμματα κλάσεων αναπαριστούν τη δομή του

46

κλάσεων
Συσχέτιση
Κλάση
Πολλαπλότητα Watch
1 1 1 1
2
1 2 1
PushButton
LCDDisplay Battery Time
state
push() blinkIdx Load Now
release()
blinkSeconds()
blinkMinutes()
blinkHours()
stopBlinking()
Λειτουργίες
Χαρακτηριστικό referesh()
47
Μια γρήγορη ματιά: διαγράμματα
ακολουθίας
• Τα διαγράμματα κλάσεων παρέχουν την στατική
όψη (δομή) των κλάσεων
• Τα διαγράμματα ακολουθίας (sequence diagrams)
παρέχουν τη δυναμική όψη, όπως και τα
διαγράμματα επικοινωνίας
• Εμφανίζουν την επικοινωνία αντικειμένων μέσω
της ανταλλαγής μηνυμάτων
48
Μια γρήγορη ματιά: διαγράμματα ακολουθίας

Actor
Μήνυμα Αντικείμενο Γραμμή ζωής
:WatchUser :Watch :LCDDisplay :Time
pressButton1() blinkHours()
pressButton1()
blinkMinutes()
pressButton2()
incrementMinutes()
refresh()
pressButton1and2()
commitNewTime()
stopBlinking()
Ενεργοποίηση
Τα διαγράμματα ακολουθίας αναπαριστούν τη συμπεριφορά του

συστήματος με μορφή μηνυμάτων (αλληλεπιδράσεων) μεταξύ αντικειμένων
49
Μια γρήγορη ματιά: διαγράμματα
μηχανής καταστάσεων
• Τα διαγράμματα μηχανής καταστάσεων (state machine
diagrams) χρησιμοποιούνται για τη μοντελοποίηση της
διακριτής συμπεριφοράς κάποιου συστήματος.
• Η συμπεριφορά του συστήματος μοντελοποιείται ως η
μετάβαση από μία κατάσταση σε κάποια άλλη.
• Τα διαγράμματα μηχανής καταστάσεων μπορούν να
χρησιμοποιηθούν και για τη μοντελοποίηση της
συμπεριφοράς των αντικειμένων.
• Κατάσταση αντικειμένων: το σύνολο των τιμών των
ιδιοτήτων σε κάποια χρονική στιγμή.
50
Μια γρήγορη ματιά: διαγράμματα μηχανής

καταστάσεων
Αρχική κατάσταση
Συμβάν
πάτημαΚουμπιού1&2 πάτημαΚουμπιού2
Αναβόσβησε Αύξησε ώρες
ώρες
μετάβαση
πάτημαΚουμπιού1
κατάσταση Αναβόσβησε Αύξησε
λεπτά λεπτά
πάτημαΚουμπιού2 Αύξησε
Σταμάτα να Αναβόσβησε
αναβοσβήνεις δευτερόλεπτα δευτερόλεπτα
Τελική κατάσταση
Αναπαριστά τη συμπεριφορά ενός μοναδικού αντικειμένου την οποία
κρίνουμε ενδιαφέρουσα. 51
Άλλοι συμβολισμοί της UML
• Η UML παρέχει πολλές άλλες σημειογραφίες, π.χ.
◦ Διαγράμματα θέσης σε λειτουργία για μοντελοποίηση διαμορφώσεων
◦ Χρήσιμο για έλεγχο και διαχείριση εκδόσεων
◦ Θα εισάγουμε τις σημειογραφίες σταδιακά, όταν τις
χρειαζόμαστε
• Η UML πλέον ενσωματώνει την OCL (Object constraint language)
για ορισμό περιορισμών στα αντικείμενα (δείτε:
http://www.omg.org/spec/OCL/)
◦ Παράδειγμα αμετάβλητης (invariant): inv: self.age >= 0
◦ Παράδειγμα προ-συνθήκης (precondition)
context Auction::placeBid(bidder:Id, bid:Money)
pre : not bidder.oclIsUndefined()
pre : not bid.oclIsUndefined()
pre : bid.currency = self.bids->first().amount.currency
pre : bid > self.currentBid().money
52

ENGINEERING)
UML – διαγράμματα περιπτώσεων χρήσης, διαγράμματα
κλάσεων, διαγράμματα ακολουθίας, διαγράμματα
δραστηριότητας, διαγράμματα παράταξης
1
Θέματα που θα παρουσιάσουμε
• Τι είναι η UML
• Αναλυτική παρουσίαση διαγραμμάτων
◦ περιπτώσεις χρήσης
◦ διαγράμματα κλάσεων
◦ διαγράμματα ακολουθίας
◦ διαγράμματα δραστηριότητας
UML – Unified Modeling Language

• Πρότυπο που δεν ανήκει σε συγκεκριμένο κατασκευαστή
(nonproprietary) για τη μοντελοποίηση συστημάτων (όχι μόνο
λογισμικού)
◦ Σύγκλιση συμβολισμών που χρησιμοποιούνται σε αντικειμενοστρεφείς
μεθόδους
◦ OMT (James Rumbaugh and colleagues)
◦ Booch (Grady Booch)
◦ OOSE (Ivar Jacobson)
• Συντηρείται από τον OMG, τρέχουσα έκδοση 5
◦ Δείτε: http://www.uml.org/
• Εμπορικά εργαλεία: Rational (IBM),Together (Borland), Visual Architect
(business processes, BCD), Visual Paradigm for UML
• Εργαλεία ανοικτού λογισμικού: ArgoUML, StarUML, Umbrello
3
Διαγράμματα περίπτωσης χρήσης
• Χρησιμοποιείται κατά την εκμαίευση των απαιτήσεων και στην
ανάλυση των απαιτήσεων για να αναπαραστήσει την «εξωτερική
συμπεριφορά» του συστήματος (η συμπεριφορά όπως φαίνεται
από εξωτερικό προς το σύστημα παρατηρητή)
• Βασικά σύμβολα:
◦ Actor: αναπαριστά έναν ρόλο – κατά κάποιο τρόπο έναν χρήστη του
συστήματος.
◦ Περίπτωση χρήσης: μια κατηγορία λειτουργικότητας που παρέχεται από το
σύστημα
• Μοντέλο περιπτώσεων χρήσης: το σύνολο των περιπτώσεων
χρήσης, περιγράφει πλήρως τη λειτουργικότητα του συστήματος
Αγόρασε
εισιτήριο
Επιβάτης
4
Actor
• Ο actor μοντελοποιεί μία εξωτερική
οντότητα που αλληλεπιδρά
(επικοινωνεί) με το σύστημα
◦ Άνθρωπος
◦ Εξωτερικό σύστημα (τρίτο σύστημα)
◦ Φυσικό περιβάλλον (π.χ. καιρός)
• Ο actor έχει ένα μοναδικό όνομα και
μία προαιρετική περιγραφή
• Παραδείγματα: Προαιρετική
Επιβάτης ◦ Επιβάτης: Ένας άνθρωπος στο τραίνο περιγραφή
◦ Δορυφόρος GPS: ένα εξωτερικό σύστημα
Όνομα που παρέχει στο δικό μας σύστημα
συντεταγμένες GPS
5
Περίπτωση χρήσης
• Μία περίπτωση χρήσης περιγράφει μία
κατηγορία λειτουργικότητας που παρέχεται
από το σύστημα
• Οι περιπτώσεις χρήσης μπορούν να
περιγράφονται συμπληρωματικά και με
Αγόρασε κείμενο, με εστίαση στη ροή συμβάντων
εισιτήριο μεταξύ actor και συστήματος
• Η περιγραφή κειμένου μιας περίπτωσης
χρήσης έχει 6 τμήματα:
◦ Μοναδικό όνομα
◦ Actors που μετέχουν
◦ Συνθήκες εισόδου
◦ Συνθήκες εξόδου
◦ Ροή συμβάντων
◦ Ειδικές απαιτήσεις
Περιγραφή κειμένου περιπτώσεων

χρήσης
1. Όνομα: Αγόρασε εισιτήριο 5. Ροή συμβάντων:
2. Actor που μετέχει: 1. Ο Επιβάτης επιλέγει προορισμό
Επιβάτης 2. Το αυτόματο μηχάνημα εμφανίζει
3. Συνθήκη εισόδου: την τιμή του εισιτηρίου
3. Ο Επιβάτης εισάγει τα χρήματα,
◦ Ο Επιβάτης πηγαίνει στο τουλάχιστον όσα και η τιμή του
αυτόματο μηχάνημα εισιτηρίου
πώλησης εισιτηρίων 4. Το αυτόματο μηχάνημα επιστρέφει
◦ Ο Επιβάτης διαθέτει τυχόν ρέστα
αρκετά χρήματα για να 5. Το αυτόματο μηχάνημα δίνει το
αγοράσει το εισιτήριο εισιτήριο
4. Συνθήκη εξόδου: 6. Ειδικές απαιτήσεις:
Ο Επιβάτης έχει εισιτήριο Καμία
7
Παράδειγμα: UC «δανεισμός
αντιτύπων»
1. Όνομα: δανεισμός αντιτύπων
2. Πρωτεύων actor: βιβλιοθηκονόμος
3. Ενδιαφερόμενοι και απαιτήσεις των:
1. Βιβλιοθηκονόμος: θέλει να καταγράφει ορθά και σύντομα τον δανεισμό
ενός ή περισσοτέρων αντιτύπων
2. Δανειζόμενος: να δανειστεί τα αντίτυπα και να γνωρίζει την προθεσμία
επιστροφής
3. Προϊστάμενος βιβλιοθήκης: να δανείζονται μόνο οι δικαιούμενοι. Να
γνωρίζει ποιος έχει δανειστεί τι. Γρήγορη εξυπηρέτηση. Μη υπέρβαση
ορίων δανεισμού.
4. Προϋποθέσεις: το σύστημα έχει διακριβώσει την ταυτότητα του

βιβλιοθηκονόμου
Παράδειγμα: Βασική ροή UC

«δανεισμός αντιτύπων»
1. Ο δανειζόμενος έρχεται στο βιβλιοθηκονόμο κρατώντας τα αντίτυπα
των βιβλίων προς δανεισμό.
2. Ο βιβλιοθηκονόμος αναζητά τον δανειζόμενο.
3. Το Σύστημα παρουσιάζει τα στοιχεία του δανειζομένου.
4. Ο βιβλιοθηκονόμος αναζητά το αντίτυπο.
5. Το Σύστημα παρουσιάζει τα στοιχεία του αντιτύπου.
6. Ο βιβλιοθηκονόμος επιλέγει το αντίτυπο προς δανεισμό.
7. Το Σύστημα επιβεβαιώνει ότι ο δανειζόμενος μπορεί να δανειστεί το
αντίτυπο.
8. Το Σύστημα καταχωρίζει το δανεισμό και εμφανίζει την προθεσμία
επιστροφής.
9. Ο βιβλιοθηκονόμος ενημερώνει τον δανειζόμενο για την προθεσμία
επιστροφής του αντιτύπου.
Ο βιβλιοθηκονόμος επαναλαμβάνει τα βήματα 4 έως 9 για όλα τα αντίτυπα.
9
Παράδειγμα: Εναλλακτικές ροές UC
«δανεισμός αντιτύπων»
* Σε οποιοδήποτε σημείο το λογισμικό καταρρέει. [*  σε οποιοδήποτε βήμα]
1. Ο βιβλιοθηκονόμος εκκινεί το Σύστημα.
2. Το Σύστημα ταυτοποιεί το βιβλιοθηκονόμο.
3. Ο βιβλιοθηκονόμος εκκινεί το δανεισμό για τα εναπομείναντα αντίτυπα.
2α. Ο δανειζόμενος έρχεται για πρώτη φορά για δανεισμό. [2α  εναλλακτική του βήματος 2]
1. Ο βιβλιοθηκονόμος επιβεβαιώνει ότι ο δανειζόμενος μπορεί να δανειστεί βιβλία από τη
Βιβλιοθήκη.
1α. Ο δανειζόμενος δε δικαιούται να δανειστεί από τη Βιβλιοθήκη.
1. Ο δανεισμός τερματίζει.
2. Ο βιβλιοθηκονόμος καταχωρίζει τον δανειζόμενο στο σύστημα με τη Διαχείριση
Δανειζομένου.
5α. Το Σύστημα δε βρίσκει το αντίτυπο του βιβλίου [5α  εναλλακτική του βήματος 5]
1. Ο βιβλιοθηκονόμος κρατά το αντίτυπο για να διαπιστώσει το σφάλμα αργότερα.
2. Ο δανεισμός τερματίζει.
7α. Ο δανειζόμενος δεν μπορεί να δανειστεί βιβλία [7α  εναλλακτική του βήματος7]
1. Ο βιβλιοθηκονόμος ενημερώνει το δανειζόμενο.
2. Κρατά τα εναπομείναντα αντίτυπα για να επιστρέψουν στα ράφια.
3. Ο δανεισμός τερματίζεται.
10
Περιγραφή περιπτώσεων χρήσης -

σενάρια (1/2)
• Μία περίπτωση χρήσης μπορεί να θεωρηθεί ως ένα σύνολο πιθανών –
διαφορετικών μεταξύ τους- ακολουθιών βημάτων που εξυπηρετούν
ένα συγκεκριμένο στόχο του πρωτεύοντος actor και είναι πιθανό να
εκτελεστούν, όταν ο πρωτεύων actor εκκινεί την περίπτωση χρήσης.
• Τα διαφορετικά μονοπάτια στη ροή εκτέλεσης ονομάζονται σενάρια -
Ένα σενάριο (ή στιγμιότυπο περίπτωσης χρήσης) είναι μία ακολουθία
ενεργειών και αλληλεπιδράσεων actors και συστήματος.
• Δεν περιγράφονται όλες οι δυνατότητες εκτέλεσης της περίπτωσης
χρήσης και όλα τα δυνατά μονοπάτια στη ροή εκτέλεσης των
βημάτων.
• Οι ροές των βημάτων σε μία περίπτωση χρήσης χωρίζονται σε δύο
κατηγορίες. Η πρώτη κατηγορία είναι η βασική ροή (basic flow) η
οποία περιγράφει το κύριο σενάριο και είναι μία τυπική ροή των
βημάτων με επιτυχή κατάληξη. Η δεύτερη κατηγορία, είναι οι
εναλλακτικές ροές (alternative flows) που είναι εναλλακτικές
επιτυχημένες ή αποτυχημένες ροές εκτέλεσης της περίπτωσης χρήσης.
11
Περιγραφή περιπτώσεων χρήσης -
σενάρια (2/2)
• Ανάλογα με το πόσο λεπτομερής είναι η διατύπωση των βημάτων και
των δυνατών σεναρίων, έχουμε τρεις μορφές περιπτώσεων χρήσης που
είναι:
◦ Σύντομη . Περιγράφουμε την περίπτωση χρήσης σε μία παράγραφο καταγράφοντας
τη βασική ροή
◦ Ουσιώδης (essential use cases). Περιγράφονται αναλυτικά όλα τα βήματα της
αλληλεπίδρασης με όλες τις εναλλακτικές ροές.
◦ Συστήματος (system use cases). Χρησιμοποιούνται κυρίως ως μέσο προδιαγραφής
των απαιτήσεων.
• Η σύντομη περιγραφή χρησιμοποιείται κυρίως για μία πρώτη
καταγραφή της περίπτωσης χρήσης στα πρώτα στάδια της εξαγωγής
των απαιτήσεων. Όταν οι περιπτώσεις χρήσης εξετάζονται
λεπτομερέστερα, περιγράφονται με χρήση της ουσιώδους μορφής. Εάν
θέλουμε να προδιαγράψουμε με λεπτομέρεια την αλληλεπίδραση του
actor με το σύστημα χρησιμοποιούμε τη μορφή του συστήματος.
12
Οδηγίες για τη σύνταξη του

κειμένου
• Τα βήματα των περιπτώσεων χρήσης περιγράφονται με απλές
καταφατικές και σύντομες προτάσεις.
• Διατυπώνουν με ακρίβεια για το τι κάνει το σύστημα και τι ο
πρωτεύων actor.
• Δεν περιγράφεται το πώς δουλεύει το σύστημα αλλά μόνο το
τι κάνει. Η εσωτερική λειτουργία θεωρείται εδώ ως μαύρο
κουτί.
• Δεν περιγράφονται στοιχεία της διεπαφής χρήστη, όπως και
άλλα στοιχεία που αφορούν τη σχεδίαση του λογισμικού.
Λεπτομερέστερα στοιχεία της διεπαφής μπορούμε να
συμπεριλάβουμε μόνο στη μορφή συστήματος
13
Οι περιπτώσεις χρήσης μπορούν να
αλληλοσυνδέονται – σχέση «extends»
• Η σχέση επέκτασης (extends) χρησιμοποιείται για αναπαράσταση
περιπτώσεων χρήσης με εμπλουτισμένη λειτουργικότητα ή
σπανίως καλούμενες
◦ Όταν μία περίπτωση χρήσης Α επεκτείνει τη λειτουργικότητα μίας
περίπτωσης χρήσης Β, η Β ΔΕΝ το γνωρίζει (η Β σε ΚΑΜΜΙΑ περίπτωση δεν
τροποποιείται για να «εξυπηρετήσει» την Α και στο κείμενο της Α ΔΕΝ
αναφέρεται η Β).
◦ Αν οι Β, Γ, Δ, Ε συνδέονται με την Α με σχέση επέκτασης, τότε στα πλαίσια
της Α είναι πιθανό να κληθεί μία ή περισσότερες από τις Β, Γ, Δ, Ε, μπορεί
όμως και καμία
◦ Μπορούμε να το παραλληλίσουμε με «υπό συνθήκη κλήση διαδικασίας» ή
«διακοπή από το υλικό» (μπορεί να γίνει, μπορεί και όχι)
◦ Η σχέση σημειώνεται με διάστικτη γραμμή με φορά ΑΠΟ αυτή που
επεκτείνει ΠΡΟΣ αυτή που επεκτείνεται. Η διάστικτη γραμμή επιγράφεται με
τη λέξη-κλειδί <<extend>>
14

αλληλοσυνδέονται – σχέση «extends»
Οι εμπλουτισμένες- σπάνιες
περιπτώσεις χρήσης διαχωρίζονται
Επιβάτης από τη «βασική» για να έχουμε πιο
εύληπτη αναπαράσταση
Οι περιπτώσεις χρήσης που
αναπαριστούν εξαιρέσεις μπορούν
ΑγόρασεΕισητήριο να κάνουν «extend» πάνω από μία
περιπτώσεις χρήσης
<<extends>>
<<extends>>
<<extends>>
ΈχειΒλάβη <<extends>> ΕξάντλησηΧρονικούΟρίου
Ακύρωση ΔενΥπάρχουνΡέστα
15
Χρήση της σχέσης επέκτασης
• Θέλουμε να τροποποιήσουμε μία περίπτωση χρήσης, χωρίς να
αλλάξουμε το κείμενό της.
• Το τελικό προϊόν λογισμικού παράγεται σε παραπάνω από μία
εκδόσεις, οι οποίες προσθέτουν λειτουργικότητα σε μία βασική
έκδοση. Οι περιπτώσεις χρήσης της βασικής έκδοσης
συντάσσονται αγνοώντας την πιθανή πρόσθετη λειτουργικότητα
των εμπλουτισμένων εκδόσεων. Οι περιπτώσεις χρήσης των
εμπλουτισμένων εκδόσεων συντάσσονται ως επεκτάσεις της
λειτουργικότητας της βασικής έκδοσης.
• Υπάρχουν πολλά ασύγχρονα γεγονότα που μπορεί να
διακόψουν τη ροή των βημάτων της περίπτωσης χρήσης.
16

αλληλοσυνδέονται – σχέση «includes»
• Σχέση συμπερίληψης («includes»)
◦ Για αναπαράσταση λειτουργικής συμπεριφοράς που είναι κοινή σε
περισσότερες από μία περιπτώσεις χρήσης
◦ Σε αντιδιαστολή με τη σχέση επέκτασης που χρησιμοποιείται για
εμπλουτισμό λειτουργικότητας μιας περίπτωσης χρήσης ή για
λειτουργίες που είναι σχετικά σπάνιες, η σχέση συμπερίληψης
χρησιμοποιείται κυρίως για να επαναχρησιμοποιήσουμε μία
μοντελοποίηση
17
<<include>>
A B
• Στα βήματα της περίπτωσης χρήσης Α συμπεριλαμβάνονται τα

βήματα της περίπτωσης χρήσης Β (μπορούμε να το
παραλληλίσουμε με «κλήση διαδικασίας»)
• Η Α αναφέρεται ως βασική και η Β ως συμπεριλαμβανόμενη
(included) περίπτωση χρήσης
• Η σχέση σημειώνεται με διάστικτη γραμμή με φορά ΑΠΟ αυτή
που συμπεριλαμβάνει ΠΡΟΣ αυτή που συμπεριλαμβάνεται. Η
διάστικτη γραμμή επιγράφεται με τη λέξη-κλειδί <<include>>
18

Επιβάτης
ΑγοράΠολλαπλούΕισητηρίου
ΑγοράΑπλούΕισητηρίου
<<includes>>
<<includes>>
<<extends>>
ΣυλλογήΑντιτίμου
<<extends>> <<extends>>
<<extends>>
ΕξάντλησηΧρονικούΟρίου
ΔενΥπάρχουνΡέστα Ακύρωση ΈχειΒλάβη
19
Αφηρημένες έναντι συγκεκριμένων
• Περιπτώσεις χρήσης που ενεργοποιούνται αυτόνομα
ονομάζονται συγκεκριμένες (concrete)
• Περιπτώσεις χρήσης που ΔΕΝ ενεργοποιούνται αυτόνομα
–παρά μόνο ως τμήμα άλλων μέσω συμπερίληψης–
ονομάζονται αφηρημένες (abstract)
<<include>>
ΑγοράΑπλού
Εισιτηρίου
Συλλογή
Αντιτίμου
Αγορά
Πολλαπλού
Εισιτηρίου
<<include>>
20
Μερικοί κανόνες για τις σχέσεις

συμπερίληψης
• ΔΕΝ διασπούμε περιπτώσεις χρήσης σε
«συμπεριλαμβανόμενες υποπεριπτώσεις» για να
αναδείξουμε τα βήματα της κάθε υποπερίπτωσης
◦ Φτιάχνουμε «συμπεριλαμβανόμενη υποπερίπτωση» ΜΟΝΟ αν αυτή
χρησιμοποιείται σε δύο τουλάχιστον περιπτώσεις χρήσης, ή είναι
αφ’ εαυτής συγκεκριμένη (π.χ. Η «ΣυλλογήΑντιτίμου» στην
«ΑγοράΕισητηρίου»)
• Η υπερβολική χρήση σχέσεων συμπερίληψης μπορεί να

βοηθά τη συγγραφή, αλλά μειώνει την αναγνωσιμότητα
και δυσχεραίνει τη διαχείριση
• Κάθε «βασική» περίπτωση χρήσης προϋποθέτει ΟΛΕΣ τις
συμπεριλαμβανόμενες
21
κατηγοριοποιούνται
Κατηγοριοποίηση
Μάθημα Περίπτωση
διάλεξη
Διδάσκων
Actor Βάλε
εργασία
Φοιτητής

22
Κατηγοριοποίηση στη UML 1: πακέτα

πακέτο
Μάθημα
Περίπτωση
διάλεξη
Διδάσκων
Actor Βάλε
εργασία
Φοιτητής

23
Διαφορές συμπερίληψης -
επέκτασης
• Στη συμπερίληψη, έχουμε σαφή αναφορά της συμπεριλαμβανόμενης
περίπτωσης χρήσης στο κείμενο που περιγράφει τη βασική.
• Στη σχέση της επέκτασης η λειτουργικότητα της βασικής περίπτωσης
χρήσης επεκτείνεται, χωρίς η ίδια να το γνωρίζει. Όταν
χρησιμοποιείται η επέκταση, δε γίνεται κάποια αναφορά στα βήματα
της βασικής περίπτωση χρήσης σε αυτή που την επεκτείνει.
• Οι επεκτάσεις στις περιγραφές των περιπτώσεων χρήσης
περιγράφονται εκτός των βημάτων των ροών, σε ξεχωριστή ενότητα,
ως σημεία επέκτασης (extension points).
• Ένα τελευταίο σημαντικό σημείο διαφοροποίησης της επέκτασης από
τη συμπερίληψη είναι ότι η βασική περίπτωση χρήσης μπορεί να
νοηθεί ανεξάρτητα από τις επεκτάσεις της.
24

αλληλοσυνδέονται – σχέση γενίκευσης
Β
Οι περιπτώσεις χρήσης B και Γ κληρονομούν τη συμπεριφορά της

Α.
Μπορούν να εξειδικεύσουν τα βήματα των ροών της Α.
Σημειώνεται με πλήρεις γραμμές ΑΠΟ τις ειδικές ΠΡΟΣ τη γενική
ΟΛΑ τα βήματα της γενικής περίπτωσης χρήσης (βασικής και
εναλλακτικών ροών) ΠΡΕΠΕΙ να συμπεριλαμβάνονται στις ειδικές,
εξειδικευμένα πιθανώς σε πιο συγκεκριμένα βήματα
25
Η γενίκευση ισχύει και για τους actors
Χρησιμοποιούμε τη
γενίκευση των actor
όταν θέλουμε να
Πρόσωπο δείξουμε ομοιότητες
μεταξύ των actors
Γενίκευση Οι actors θα πρέπει
να εμφανίζουν κοινή
συμπεριφορά σε
σχέση με το σύστημα
Καθηγητής Φοιτητής
26
Παράδειγμα περίπτωσης χρήσης
http://www.math-
cs.gordon.edu/local/courses/cs211
/ATMExample/Intro.html
27
Παράδειγμα Διαγράμματος Χρήσης UML
Μολονότι τα «άνοιγμα
διαφράγματος»,
«ενεργοποίηση φλας»,
Σωστό «κλείσιμο
διαφράγματος» ΕΙΝΑΙ
λειτουργίες της
φωτογραφικής μηχανής,
ΔΕΝ τα εκτελεί ο
φωτογράφος ΑΛΛΑ η
φωτογραφική μηχανή
Λάθος ως τμήμα της
διαδικασίας υλοποίησης
των προσταγών του
φωτογράφου!
http://www.andrew.cmu.edu/course/90-754/umlucdfaq.html
28
Άλλα πιθανά στοιχεία/ενότητες

των περιπτώσεων χρήσης (1/2)
• Ύστερες συνθήκες (postconditions)
◦ Συνθήκη που πρέπει να ισχύει μετά από επιτυχή ή αποτυχημένη ολοκλήρωση
περίπτωση χρήσης – π.χ. «το πλήθος των διαθέσιμων μη τυπωμένων εισιτηρίων
έχει μειωθεί κατά 1»
• Εναύσματα (triggers)
◦ Γεγονότα που ενεργοποιούν την περίπτωση χρήσης. Θα μπορούσαν να
περιλαμβάνουν χρονικά σημεία π.χ. «κάθε 24 ώρες». Αν δεν συμπεριλάβουμε
τέτοιες, θεωρείται ότι είναι το 1ο βήμα.
• Εξαιρέσεις
◦ Διαχωρίζουμε επιτυχημένες και αποτυχημένες ροές με τις αποτυχημένες να
πηγαίνουν στην ενότητα «εξαιρέσεις» - π.χ. «το μηχάνημα δεν διαθέτει μη
τυπωμένα εισιτήρια»
• Ειδικές απαιτήσεις
◦ Για καταγραφή μη λειτουργικών απαιτήσεων ή/και περιορισμών.
• Δευτερεύοντες actors
◦ Καταγράφονται μετά τον πρωτεύοντα
29
Άλλα πιθανά στοιχεία/ενότητες
των περιπτώσεων χρήσης (2/2)
• Τεχνολογικές επιλογές
◦ Όταν έχουμε ένα συγκεκριμένο βήμα που μπορεί να πραγματοποιηθεί με πάνω
από ένα τεχνολογικά μέσα-τρόπους. Π.χ. σε ένα σούπερ-μάρκετ ένα είδος
μπορεί να «χτυπηθεί» διαβάζοντας το barcode με την ειδική διάταξη ή
πληκτρολογώντας τον κωδικό του.
◦ Αν οι τεχνολογικές επιλογές αλλάζουν σημαντικά την αλληλεπίδραση του actor
με το σύστημα, τότε πιθανόν να δημιουργήσουμε ξεχωριστό use case (π.χ. σε
ένα τραπεζικό σύστημα, πληρωμή λογαριασμού μέσω ATM ή μέσω web
banking)
• Υπορροές
◦ Για ροές με μακροσκελή περιγραφή, ομαδοποιούμε και ονοματίζουμε βήματα
και τα εισάγουμε στην ενότητα των υπορροών. Κατόπιν τα αναφέρουμε (στη
βασική ή τις εναλλακτικές ροές) με το όνομά τους.
• Σημεία επέκτασης
◦ Αναφέρονται στα σημεία των ροών της βασικής περίπτωσης χρήσης όπου
επεκτείνεται η συμπεριφορά της
30
Γενικές οδηγίες για συγγραφή

περιπτώσεων χρήσης (1/3)
• Οι περιπτώσεις χρήσης είναι εργαλείο επικοινωνίας
◦ Πρέπει να είναι κατανοητές και σαφείς από όλους τους ενδιαφερόμενους
ώστε να μπορούν να επαληθευθούν
• Επαναληπτική και επαυξητική συγγραφή

◦ Αρχικά εντοπίζουμε τον πρωτεύοντα actor και περιγράφουμε τη βασική
ροή, πιθανότατα με τη συνοπτική μορφή
◦ Κατόπιν μπορούμε να προσθέσουμε λεπτομέρειες μέσω ερωτημάτων «τι
θα γίνει αν...»
◦ Το επίπεδο λεπτομέρειας δεν είναι πάντα ίδιο
◦ Κάποιες φορές αρκεί η ουσιώδης περιγραφή για να συμφωνήσουν όλοι ότι
«αυτές είναι οι απαιτήσεις» και τυχόν κενά θα καλυφθούν με την παράδοση των
πρωτοτύπων του λογισμικού
◦ Για τις δύσκολες και πολύπλοκες περιπτώσεις χρήσεις μπορεί να χρειαστεί να
καταφύγουμε στη μορφή συστήματος της περίπτωσης χρήσης
31
• Διαχείριση οντοτήτων δεδομένων
◦ Περιπτώσεις χρήσης που διαχειρίζονται πληροφορίες για οντότητες
δεδομένων που αποθηκεύονται στο σύστημα (π.χ. σε ένα σύστημα
βιβλιοθήκης, οι δικαιούμενοι δανεισμό)
◦ Μπορούμε να έχουμε περιπτώσεις χρήσης για «ανάκτηση»,
«δημιουργία», «τροποποίηση», «διαγραφή», αλλά αν η διαχείριση
είναι απλή μπορούμε να τα συνενώσουμε σε «Διαχείριση
οντότητας» (π.χ. «Διαχείριση δανειζομένων»).
• Ενεργοποίηση από τον χρόνο

◦ Αν μία περίπτωση ενεργοποιείται από χρονικό έναυσμα, τότε
θέτουμε ως πρωτεύοντα actor αυτόν που κυρίως εξυπηρετείται από
τον στόχο
32

• Σύνδεση με τους επιχειρησιακούς κανόνες
◦ Συνδέουμε τις περιπτώσεις χρήσης με τους επιχειρησιακούς
κανόνες για να έχουμε ολοκληρωμένη άποψη των απαιτήσεων,
συνδυάζοντας τη λειτουργικότητα του λογισμικού με τους
κανόνες του οργανισμού.
◦ Πρόσθετο πλεονέκτημα: Αν αλλάξουν οι κανόνες, ξέρουμε ποια τμήματα του
λογισμικού επηρεάζονται
◦ Όταν οι επιχειρησιακοί κανόνες καταγράφονται μαζί με τις
απαιτήσεις υπάρχει κίνδυνος να τα «μπλέξουμε»
◦ Απλός κανόνας: ό,τι ισχύει ανεξαρτήτως παρουσίας λογισμικού, είναι
επιχειρησιακός κανόνας, τα άλλα είναι απαιτήσεις
33
Διαγράμματα κλάσεων
• Τα διαγράμματα κλάσεων αναπαριστούν τη δομή του
• Χρησιμοποιούνται:
◦ Κατά την ανάλυση για να μοντελοποιηθούν οι έννοιες στο πεδίο της
εφαρμογής
◦ Κατά τον σχεδιασμό του συστήματος για να μοντελοποιηθούν τα
υποσυστήματα
◦ Κατά τον σχεδιασμό των αντικειμένων για να οριστούν η λεπτομερής
συμπεριφορά και τα γνωρίσματα των κλάσεων
FareCatalogue Trip
Table zone2price zone:Zone
Enumeration getZones() * * Price: Price
Price getPrice(Zone)
34
Βασικές έννοιες
αντικειμενοστρεφούς μοντέλου
• Αντικείμενο: μία αυτόνομη και ανεξάρτητη οντότητα που
χαρακτηρίζεται από:
◦ Ταυτότητα: το διαχωρίζει από τα άλλα αντικείμενα και παραμένει
αναλλοίωτη καθ’ όλη τη διάρκεια ζωής του αντικειμένου, ανεξάρτητα από
άλλες αλλαγές στην κατάστασή του
◦ Κατάσταση: ένα σύνολο δεδομένων που αφορούν το αντικείμενο και
αποτυπώνουν όλες τις ιδιότητες του αντικειμένου
◦ Συμπεριφορά: ο τρόπος με τον οποίο το αντικείμενο αντιδρά σε σχέση με
τις αλλαγές στην κατάστασή του και την επικοινωνία με άλλα αντικείμενα.
Υλοποιείται μέσω των πράξεών του. Η συμπεριφορά επιδρά στην
κατάσταση του αντικειμένου και τη διαμορφώνει
• Αναπαράσταση αντικειμένου: Όνομα (ταυτότητα)
Κατάσταση
Πράξεις
35
Βασικές έννοιες αντικειμενοστρεφούς
μοντέλου (συνέχεια)
• Αντικείμενα (συνέχεια)
◦ Οι πράξεις του αντικειμένου διακρίνονται σε ελεγκτικές (δεν τροποποιούν την
κατάσταση) και κατασκευαστικές (τροποποιούν την κατάσταση)
◦ Ο εξωτερικός κόσμος γνωρίζει για το αντικείμενο το όνομά του (ταυτότητα) και
το όνομα κάποιων πράξεών του αλλά ΟΧΙ το πώς υλοποιούνται οι πράξεις ή την
κατάστασή του (ενθυλάκωση – encapsulation)
◦ Μεταξύ αντικειμένων μπορούμε να έχουμε στατικές σχέσεις (δεν αλλάζουν με
τον χρόνο) ή δυναμικές σχέσεις (μεταβάλλονται χρονικά)
36

• Αντικείμενα (συνέχεια): Σχέση σύνθεσης
◦ Περιγράφει ότι ένα αντικείμενο συντίθεται από μία
ομάδα αντικειμένων
◦ Π.χ. Ένα αυτοκίνητο έχει σασί, μηχανή, δύο άξονες,
τέσσερις τροχούς, τιμόνι κ.τ.λ.
◦ Εξωτερικά δεν ξέρουμε ούτε ποια μέρη το συνθέτουν,
ούτε το σε ποια μηνύματα αντιδρά το καθένα – για να το
δούμε θα πρέπει να εξετάσουμε εσωτερικά το
αντικείμενο (αν μας επιτρέπεται και μας ενδιαφέρει)
◦ Π.χ. Η μηχανή μπορεί να δίνει στους τροχούς το μήνυμα
«περιστρέψου» και το τιμόνι στον άξονα το μήνυμα «στρίψε»
37
• Αλληλεπίδραση αντικειμένων
◦ Τα αντικείμενα αλληλεπιδρούν αποστέλλοντας μεταξύ τους
μηνύματα
◦ Το μήνυμα είναι ένα αίτημα εκτέλεσης πράξης και το
παραλαμβάνον αντικείμενο αποκρίνεται εκτελώντας την πράξη
◦ Ένα μήνυμα μπορεί να συνοδεύεται από παραμέτρους και να
επιστρέφει αποτέλεσμα
◦ Τα μηνύματα που μπορούν να αποσταλούν σε ένα αντικείμενο
κοινοποιούνται στη διεπαφή του αντικειμένου – μόνο οι
υπογραφές των μηνυμάτων κοινοποιούνται μέσω της διεπαφής
ενώ ο τρόπος υλοποίησής τους αποκρύπτεται.
38

• Κλάσεις και στιγμιότυπα
◦ Κλάση: μηχανισμός ομαδοποίησης αντικειμένων με κοινή δομή
και συμπεριφορά
◦ Στιγμιότυπο: αντικείμενο που ορίζεται με βάση κάποια κλάση
◦ Οι τιμές που συνθέτουν την κατάσταση ενός στιγμιοτύπου είναι
ιδιαίτερες για κάθε μεμονωμένο αντικείμενο
◦ Οι πράξεις και η δομή ορίζονται μία φορά στην κλάση και ισχύουν
για όλα τα στιγμιότυπα της κλάσης.
◦ Φυσικά η υλοποίηση κάποιας πράξης μπορεί να λαμβάνει υπ’ όψιν τιμές της
κατάστασης και να διαφοροποιεί τη ροή εκτέλεσης με υπό συνθήκη εκτέλεση
κώδικα
◦ Εναλλακτικά μπορούμε να ορίσουμε διαφορετικές κλάσεις που να
διαφέρουν ως προς την υλοποίηση μίας η περισσοτέρων πράξεων
39
• Πολυμορφισμός
◦ Η χρήση του ίδιου μηνύματος στη διεπαφή πάνω από μίας
κλάσεων για υλοποίηση εννοιολογικά όμοιων αλλά
διαφορετικών σε λεπτομέρειες υλοποίησης πράξεων
◦ Π.χ. στη Java η μέθοδος .toString() υλοποιείται σε όλα τα
αντικείμενα με εντελώς διαφορετικό τρόπο, κάνει ωστόσο
εννοιολογικά το ίδιο πράγμα
◦ Με τον πολυμορφισμό ο αποστολέας ενός μηνύματος δεν
χρειάζεται να γνωρίζει την κλάση του αποδέκτη του
μηνύματος, παρά μόνο το γεγονός ότι το μήνυμα ανήκει στη
διεπαφή του
40

• Κληρονομικότητα
◦ Τρόπος επέκτασης-εξειδίκευσης της συμπεριφοράς (ή/και της κατάστασης) ενός
αντικειμένου
◦ Παράδειγμα: φοιτητής από εισαγωγικές και φοιτητής από κατατακτήριες
◦ Και οι δύο έχουν αριθμό μητρώου, ονοματεπώνυμο και άλλα ατομικά στοιχεία,
παρακολουθούν μαθήματα, δικαιούνται παροχές, παίρνουν πτυχίο κ.λπ.
◦ Αλλάζει μόνο ο τρόπος εγγραφής, το ακαδημαϊκό εξάμηνο εγγραφής και η αναγνώριση
μαθημάτων (υπάρχει μόνο στον φοιτητή από κατατακτήριες)
◦ Έτσι φτιάχνουμε την κλάση Φοιτητής που έχει τα κοινά στοιχεία κατάστασης και
συμπεριφορές. Δημιουργούμε την υποκλάση Φοιτητής από εισαγωγικές που υλοποιεί
την πράξη εγγραφή θέτοντας το εξάμηνο εγγραφής σε «1» και την υποκλάση Φοιτητής
από κατατακτήριες που υλοποιεί διαφορετικά την πράξη εγγραφή θέτοντας το εξάμηνο
εγγραφής κατάλληλα και επίσης υλοποιεί την πράξη αναγνώριση μαθημάτων
41
• Κλάσεις, αφαίρεση και διεπαφές
◦ Οι κλάσεις με τον μηχανισμό της ενθυλάκωσης και την κοινοποίηση των
διεπαφών βοηθούν στην επίτευξη της αφαίρεσης
◦ Μπορούμε να αλλάξουμε οποιοδήποτε στοιχείο της κατάστασης (τύπο, πλήθος
στοιχείων κ.λπ.) στον βαθμό που διατηρούμε τις ίδιες διεπαφές – το
αντικείμενο θα μπορεί να χρησιμοποιηθεί χωρίς καμία τροποποίηση στον
κώδικα. Έτσι προάγεται η συντηρησιμότητα και η δυνατότητα
επαναχρησιμοποίησης.
◦ Από την άλλη πλευρά, θα πρέπει οι διεπαφές να είναι καλά μελετημένες ώστε
να μην χρειάζεται να αλλάξουν.
◦ Κατά περίπτωση μπορούμε να υλοποιούμε διαφορετικές διεπαφές, αν
πρόκειται να «ταιριάξουμε» σε διαφορετικές συνθήκες του πραγματικού
κόσμου (π.χ. κάρτες ανάληψης με ή χωρίς «τσιπάκι ασφαλείας»)
42
Κλάσεις
FareCatalogue
Table zone2price
Όνομα Τύπος Enumeration getZones()
FareCatalogue
zone2price Γνωρίσματα
Υπογραφή
getZones()
getPrice(Zone) Λειτουργίες FareCatalogue
• Μία κλάση αναπαριστά μία έννοια

• Μία κλάση ενθυλακώνει κατάσταση (γνωρίσματα – attributes) και συμπεριφορά
(λειτουργίες – operations)
◦ Κάθε γνώρισμα έχει τύπο
◦ Κάθε λειτουργία έχει μία υπογραφή
• Μόνο το όνομα της κλάσης είναι υποχρεωτικό και τυπικά ξεκινάμε από αυτό
◦ Τα υπόλοιπα στοιχεία προστίθενται προοδευτικά όσο προχωράει η ανάπτυξη
43
Διαγράμματα Κλάσεων:
Ιδιότητες
• Οι ιδιότητες (attributes) παραπέμπουν στα
πεδία της Java/C++ και σχετίζονται με
δεδομένα της κλάσης
• Τυπική σύνταξη ιδιοτήτων
Όνομα : Τύπος = αρχική_τιμή
Student
• Ο τύπος μπορεί να είναι ένας τύπος της
lastName: String UML, κάποιος τύπος της γλώσσας
προγραμματισμού (π.χ. float, long) ή
firstName: String κάποια κλάση
birthDate: Date • Παραγόμενες (derived) ιδιότητες είναι
phoneNo: String αυτές που η τιμή τους προκύπτει από
/age: Integer άλλες ιδιότητες της κλάσης. Οι
παραγόμενες ιδιότητες έχουν το σύμβολο
“/” πριν από το όνομα.
44
Λειτουργίες
• Οι λειτουργίες (operations)
παραπέμπουν στις μεθόδους της
Java
Shape
• Τυπική σύνταξη
color: Color
position: Point Όνομα(Παράμετρος1 : Τύπος1,
draw()
Παράμετρος2 : Τύπος2, …) :
erase() Τύπος_Επιστροφής
move(newPos: Point): Shape • Το όνομα μιας λειτουργίας σε
συνδυασμό με το πλήθος και τη
σειρά των τύπων των παραμέτρων
της συνιστούν την υπογραφή της
λειτουργίας
45
Λειτουργίες (συνέχεια)
• Αν και οι λειτουργίες μίας κλάσης παραπέμπουν στις
μεθόδους της, οι δύο έννοιες δεν είναι ταυτόσημες:
◦ Με τη UML ορίζουμε μία λειτουργία ως μία υπηρεσία που
παρέχουν τα αντικείμενα της κλάσης.
◦ Η μέθοδος είναι μία υλοποίηση της λειτουργίας δηλαδή της
υπηρεσίας που παρέχεται από τα αντικείμενα.
• Επομένως, μία απλή διάκριση είναι ότι οι λειτουργίες
παρέχουν τις διεπαφές για την παροχή των υπηρεσιών,
ενώ οι μέθοδοι παρέχουν την υλοποίησή τους.
• Με τον πολυμορφισμό μπορούμε να έχουμε διαφορετικές
μεθόδους που υλοποιούν την ίδια λειτουργία.
46
Διαγράμματα κλάσεων: ορατότητα

μελών
• Πριν το όνομα κάθε μέλους (ιδιότητας ή λειτουργίας)
μπορούμε να σημειώσουμε την ορατότητά του:
- Ιδιωτικό (private)
+ Δημόσιο (public)
# Προστατευμένο (protected)
~ Πακέτο (Package)
47
Διαγράμματα κλάσεων –
δυνατότητα αλλαγής γνωρισμάτων
• Ένα γνώρισμα μπορεί να σημειωθεί ως:
◦ changeable (εξ ορισμού χαρακτηρισμός) – μπορεί να
αλλάξει η τιμή του
◦ frozen (καμία αλλαγή δεν επιτρέπεται)
◦ addOnly (μπορούν μόνο να προστεθούν τιμές – έχει
νόημα για γνωρίσματα που δέχονται πολλαπλές τιμές)
48
Διαγράμματα κλάσεων –
περιορισμοί σε γνωρίσματα
• Περικλείονται σε άγκιστρα { } και σημειώνονται δίπλα
στο γνώρισμα που αφορούν
◦ Μπορούν να γραφούν ως ελεύθερο κείμενο, σε OCL, σε
κάποια γλώσσα προγραμματισμού
Exercise
no: Integer
points: Integer {value >= 0}
text: String
49
Actor έναντι Κλάσης έναντι
Αντικειμένου
• Actor
◦ Μία οντότητα εκτός του συστήματος που μοντελοποιείται, η οποία
αλληλεπιδρά με το σύστημα (π.χ. επιβάτης)
• Κλάση
◦ Μία αφαίρεση που μοντελοποιεί μία οντότητα είτε στο «πεδίο της
εφαρμογής» (π.χ. «Εισιτήριο», «Πελάτης») είτε στο «πεδίο της
λύσης» (π.χ. «Πλαίσιο διαλόγου»).
◦ Η κλάση είναι τμήμα του μοντέλου του συστήματος («Χρήστης»,
«Αυτόματος πωλητής εισιτηρίων», «Εξυπηρέτης»)
• Αντικείμενο
◦ Ένα συγκεκριμένο στιγμιότυπο μιας κλάσης (π.χ. η διαδρομή
«Τρίπολη - Αθήνα»)
50
Στιγμιότυπα
• Ένα στιγμιότυπο αναπαριστά ένα συγκεκριμένο μέλος μιας
κλάσης
• Τα γνωρίσματα αναπαρίστανται με τις τιμές τους
• Το όνομα του στιγμιοτύπου υπογραμμίζεται
• Το όνομα του στιγμιοτύπου μπορεί να περιλαμβάνει μόνο το
όνομα της κλάσης (ανώνυμα αντικείμενα)
Ανώνυμο αντικείμενο
fullFare: FareCatalogue : FareCatalogue
Zone2price = { Zone2price = {
{‘1’, 1.20}, {‘1’, 1.20},
{‘2’, 1.40}, {‘2’, 1.40},
{‘3’, 2.50} {‘3’, 2.50}
} }
51
Συσχετίσεις
• Η συσχέτιση (association) αναπαριστά κάποια σύνδεση
των αντικειμένων δύο κλάσεων
• Απεικονίζει τη σχέση μεταξύ των κλάσεων
• Η συσχέτιση μπορεί να ονοματίζεται με κάποιο ρήμα
που αναπαριστά τη σημασία της
◦ Μπορεί να σημειώνεται και ένα βέλος, ειδικότερα όταν δεν
διαβάζεται από αριστερά προς τα δεξιά
FareCatalogue Trip
isSubjectToFare
Table zone2price zone:Zone
Enumeration getZones() * * Price: Price
52
Συσχετίσεις (συνέχεια)
• Κάθε άκρο της συσχέτισης μπορεί να διαθέτει πρόσθετα
χαρακτηριστικά:
◦ Όνομα, για καλύτερη περιγραφή της σημασιολογίας
◦ Πολλαπλότητα
◦ Πλοηγησιμότητα (navigability)
53
Πολλαπλότητα Συσχετίσεων
Οδηγεί
Πρόσωπο Αυτοκίνητο • Η πολλαπλότητα
1 0..1 αναφέρεται στα άκρα των
Κάθε πρόσωπο οδηγεί 0 ή 1 αυτοκίνητο. Κάθε συσχετίσεων.
αυτοκίνητο οδηγείται από ακριβώς 1 πρόσωπο.
◦ Ακριβώς ένα  1
Οδηγεί ◦ Ένα ή περισσότερα  1..*
Πρόσωπο Αυτοκίνητο ◦ Κανένα ή περισσότερα  *
1 *
◦ Κανένα ή ένα  0..1
Κάθε πρόσωπο οδηγεί 0 ή περισσότερα
αυτοκίνητα. Κάθε αυτοκίνητο οδηγείται από
ακριβώς 1 πρόσωπο.
Οδηγεί
Πρόσωπο Αυτοκίνητο
1..* 1..*
Κάθε πρόσωπο οδηγεί 1 ή περισσότερα αυτοκίνητα. Κάθε
αυτοκίνητο οδηγείται από 1 ή περισσότερα πρόσωπο.
54
Πολλαπλότητες Συσχετίσεων (συνέχεια)
1 Ακριβώς ένα
10 Ακριβώς δέκα
* Κανένα, ένα ή περισσότερα
1..* Ένα ή περισσότερα
1..10 Ένα έως δέκα
55
Διαγράμματα Κλάσεων: πλοηγησιμότητα
συσχετίσεων
• Σε μία γραμμή συσχέτισης σημειώνουμε ένα βέλος αν
μπορούμε να πλοηγηθούμε προς αυτό το άκρο της συσχέτισης
όταν γνωρίζουμε το άλλο
◦ Αν δεν σημειώνουμε καθόλου πλοηγησιμότητα, δεν παρέχεται εγγύηση ότι
υπάρχει.
Περιλαμβάνει
Παραγγελία Προϊόν
0..* 1..*
0..*
Κάνει
1
Πελάτης
56
Διαγράμματα Κλάσεων: Γενίκευση

• Η γενίκευση παραπέμπει στην κληρονομικότητα.
• Η κλάση Β είναι υποκλάση της κλάσης Α.
• Η υποκλάση κληρονομεί ιδιότητες συσχετίσεις και
λειτουργίες της υπερκλάσης.
• Μία υποκλάση μπορεί να επανορίσει (override)
λειτουργίες της υπερκλάσης της, ενώ μπορεί να προσθέσει
και ιδιότητες.
Α
Β
57
Γενίκευση
Σχήμα
Κύκλος Παραλληλόγραμμο Τρίγωνο
Τετράγωνο
58
Αφηρημένες κλάσεις
• Οι αφηρημένες κλάσεις είναι κλάσεις που εξυπηρετούν
την εννοιολογική ομαδοποίηση των κλάσεων που
γενικεύουν και τον ορισμό της διεπαφής των κλάσεων
αυτών
◦ Οι αφηρημένες κλάσεις ΔΕΝ μπορούν να δημιουργήσουν
αντικείμενα αυτό γίνεται μόνο στις υποκλάσεις
• Οι λειτουργίες στη διεπαφή των αφηρημένων κλάσεων

μπορεί να είναι και αυτές αφηρημένες (abstract) , δηλαδή
λειτουργίες για τις οποίες δεν παρέχεται υλοποίηση, ενώ
κάποιες άλλες συγκεκριμένες (concrete – παρέχεται
υλοποίηση)
◦ Η υλοποίηση των αφηρημένων λειτουργιών πρέπει να παρέχεται
από τις υποκλάσεις της αφηρημένης κλάσης
59
Αφηρημένες κλάσεις -συμβολισμοί
• Το όνομα μιας αφηρημένης κλάσης ή λειτουργίας συμβολίζεται:
◦ Παραθέτοντας τον συμβολισμό {abstract} δίπλα από το όνομα
◦ Χρησιμοποιώντας πλάγια γράμματα (μπορεί να είναι δυσδιάκριτα)
Shape {abstract} Shape

Αφηρημένη
color: Color κλάση color: Color
position: Point position: Point
draw() {abstract} draw()
erase() {abstract} erase()
move(newPos: Point): Shape Αφηρημένες & move(newPos: Point): Shape
συγκεκριμένες
λειτουργίες
Square
sideLength: float Ορισμός των
draw() αφηρημένων μεθόδων
erase() της υπερκλάσης
60
Πακέτα
• Τα πακέτα βοηθούν στην οργάνωση των μοντέλων της UML για
να αυξηθεί η αναγνωσιμότητά τους
• Μπορούμε να χρησιμοποιήσουμε τον μηχανισμό πακέτων της
UML για να οργανώσουμε τις κλάσεις σε υποσυστήματα
◦ Κάθε πολύπλοκο σύστημα μπορεί να αποσυντεθεί σε υποσυστήματα, όπου
κάθε υποσύστημα μοντελοποιείται ως ένα πακέτο
Account
Bank Customer
61
Μοντελοποίηση των κλάσεων στην
πράξη
• Μελετούμε
◦ τη γενική περιγραφή του συστήματος
◦ τις περιπτώσεις χρήσης, οι οποίες αντανακλούν τις
απαιτήσεις του συστήματος
◦ εξετάζουμε και συνοδευτικά έγγραφα των απαιτήσεων
όπως το λεξικό δεδομένων, το γλωσσάρι, κ.λπ.
• Συζητούμε
◦ Με τους χρήστες του συστήματος
… και βρίσκουμε κλάσεις και λειτουργίες
62
Παράδειγμα ανάδειξης κλάσεων

«Σε ένα τραπεζικό σύστημα οι πελάτες δημιουργούν τραπεζικούς
λογαριασμούς. Οι πελάτες μπορούν να πραγματοποιούν καταθέσεις
και αναλήψεις χρημάτων. Το τραπεζικό σύστημα καταγράφει κάθε
δοσοληψία κατάθεσης ή ανάληψης χρημάτων και ενημερώνει το
υπόλοιπο του λογαριασμού του πελάτη. Ένας πελάτης μπορεί να
εξυπηρετείται από τραπεζικά υποκαταστήματα. Μπορεί επίσης να
πραγματοποιεί καταθέσεις ή αναλήψεις μετρητών μέσω των ΑΤΜ της
τράπεζας. Μπορεί να αιτείται και να λαμβάνει από την τράπεζα μία
κάρτα ανάληψης μετρητών. Η κάρτα που παραλαμβάνει συνδέεται με
κάποιον από τους λογαριασμούς της επιλογής του.»
Ερώτημα: Ποιες είναι οι κλάσεις για το παραπάνω
πρόβλημα;
63
Παράδειγμα ανάδειξης κλάσεων
«Σε ένα τραπεζικό σύστημα οι πελάτες δημιουργούν τραπεζικούς
λογαριασμούς. Οι πελάτες μπορούν να πραγματοποιούν καταθέσεις
και αναλήψεις χρημάτων. Το τραπεζικό σύστημα καταγράφει κάθε
δοσοληψία κατάθεσης ή ανάληψης χρημάτων και ενημερώνει το
υπόλοιπο του λογαριασμού του πελάτη. Ένας πελάτης μπορεί να
εξυπηρετείται από τραπεζικά υποκαταστήματα. Μπορεί επίσης να
πραγματοποιεί καταθέσεις ή αναλήψεις μετρητών μέσω των ΑΤΜ της
τράπεζας. Μπορεί να αιτείται και να λαμβάνει από την τράπεζα μία
κάρτα ανάληψης μετρητών. Η κάρτα που παραλαμβάνει συνδέεται με
κάποιον από τους λογαριασμούς της επιλογής του.»
• Οι σημαντικές έννοιες του προβλήματος είναι με έντονη γραφή.
64
Κλάσεις Τραπεζικού Συστήματος

• Οι βασικές κλάσεις είναι ο πελάτης, ο
λογαριασμός, η δοσοληψία, η ανάληψη, η
κατάθεση, και η κάρτα
Customer Account Transaction
Withdrawal Deposit Card
65
Ανάδειξη κλάσεων
• Εξετάζουμε τις λειτουργίες που πρέπει να παρέχει μία κλάση
Account
D eposit()
Withdraw ()
GetBalance()
66
Ανάδειξη κλάσεων: Ιδιότητες

• Οι ιδιότητες μίας κλάσης περιγράφουν τα
δεδομένα των αντικειμένων της
• Βασικό στοιχείο των ιδιοτήτων είναι οι τύποι
• Όταν η τιμή μίας ιδιότητας έχει ιδιαίτερη σημασία
τότε αποφεύγουμε τους πρωταρχικούς τύπους
δεδομένων (String, Integer, Boolean) αλλά
δημιουργούμε νέους απλούς τύπους
◦ Οι απλοί τύποι ορίζονται ως κλάσεις
◦ Οι απλοί τύποι χρησιμοποιούν την έννοια της αφαίρεσης
(abstraction)
67
Μοντέλα Πεδίου:
Ιδιότητες
Customer Account Card
surname cardNo
balance
name pin
accountNo
email expiryDate
phone declaredMissing
/active
Transaction Το αν είναι ενεργή η

date κάρτα προκύπτει από
amount την ημερομηνία λήξης
και τη δήλωση απώλειας
68
Ανάδειξη κλάσεων: Συσχετίσεις

• Για τον καθορισμό των συσχετίσεων μεταξύ των
κλάσεων αναζητούμε τη δυνατότητα γνώσης των
αντικειμένων μίας κλάσης από μία άλλη
• Όταν καθορίζουμε τις συσχετίσεις ορίζουμε και τις
πολλαπλότητες στα άκρα τους.
69
Συσχετίσεις Τραπεζικού Συστήματος
• Το απεικονιζόμενο μοντέλο των εννοιολογικών κλάσεων δηλώνει ότι
ένας πελάτης μπορεί να έχει κανένα, έναν ή περισσότερους
τραπεζικούς λογαριασμούς, ενώ ένας λογαριασμός θα πρέπει να
ανήκει σε έναν μόνο πελάτη (αν γνωρίζουμε τον πελάτη πρέπει να
γνωρίζουμε και τους λογαριασμούς του και αντίστροφα). Μία
τραπεζική δοσοληψία αφορά ένα λογαριασμό, ενώ σε ένα λογαριασμό
μπορούν να γίνουν καμία, μία ή περισσότερες τραπεζικές δοσοληψίες.
Customer 1 * Account 1 * Card
1 1 1
* * *
Deposit Transaction Withdrawal
70
Ανάδειξη κλάσεων: Συσχετίσεις

• Εύρεση ταξονομιών
Card linkedTo
* Account
Customer
performedOn Balance
accountNo
* Has N ame
* D eposit()
Transaction Withdraw ()
GetBalance() CustomerId()
Savings Checking Mortgage

Account Account Account
D eposit Withdraw al
Withdraw () Withdraw () Withdraw ()

71
Ανάδειξη κλάσεων: αναθεώρηση
• Ξαναβλέπουμε τις κλάσεις, τις λειτουργίες, τις συσχετίσεις και τις
ιδιότητες και αναθεωρούμε το μοντέλο μέχρις ότου καταλήξουμε σε
ένα μοντέλο που να καλύπτει πλήρως τις απαιτήσεις
◦ Πιθανώς να χρειαστεί να εκτελέσουμε αναθεωρήσεις και μετά τη σύνταξη
άλλων διαγραμμάτων π.χ. των διαγραμμάτων ακολουθίας.
72
Συνάθροιση ή Συσσωμάτωση
• Η συνάθροιση ή συσσωμάτωση (aggregation) είναι μία
ειδική μορφή συσχέτισης.
• Είναι μία συσχέτιση όλου – τμήματος.
• Η κλάση Α αναπαριστά το «όλο» και η κλάση Β το «τμήμα»
• Δεν επιτρέπονται «κύκλοι» συναθροίσεων -
συσσωματώσεων
• Η διάκριση από τη συσχέτιση έχει περισσότερο
εννοιολογικό χαρακτήρα: για να υπάρχει το «όλο» πρέπει
οπωσδήποτε να υπάρχει και το «τμήμα».
◦ Αν πάψει να υπάρχει το όλον, τα τμήματα εξακολουθούν να
υφίστανται
Α Β
73
Διαγράμματα Κλάσεων
Συνάθροιση - Συσσωμάτωση
• Μία ομάδα αποτελείται από ποδοσφαιριστές
• Ο κάθε ποδοσφαιριστής ανήκει σε μία ομάδα
• Σημασιολογική ερμηνεία: «Η ομάδα δεν έχει έννοια χωρίς
τους παίκτες»
◦ Αν η ομάδα πάψει να υπάρχει, οι παίκτες εξακολουθούν να
υπάρχουν
1 1..*
Ομάδα Ποδοσφαιριστής
ΈχειΣτιςΤάξειςΤης
ΛαμβάνειΤεχνικέςΣυμβουλές
ΤεχνικόςΔιευθυντής
74
Διαγράμματα Κλάσεων: Σύνθεση

• Η σύνθεση (composition) είναι μία ισχυρή μορφή
συσσωμάτωσης
• Το όλο ελέγχει πλήρως τα τμήματά του και
ιδιαίτερα τον κύκλο ζωής τους. Π.χ. η διαγραφή
ενός αντικειμένου «όλου» διαγράφει και τα
τμήματά του.
• Η πρόσβαση σε κάποιο «τμήμα» γίνεται
αποκλειστικά μέσω του «όλου»
• Κάθε «τμήμα» ανήκει μόνο σε ένα «όλον»
Α Β
75
Σύνθεση
• Η εταιρεία αποτελείται από τμήματα
◦ Όπως και στη συνάθροιση, δεν νοείται η εταιρεία χωρίς
τα τμήματά της
◦ Σε αντίθεση με τη συνάθροιση, ούτε τα τμήματα
νοούνται χωρίς την εταιρεία
• Ο έξω κόσμος δεν έχει πρόσβαση στο τμήμα παρά
μόνο μέσω της Εταιρείας.
1 1..*
Εταιρεία Τμήμα
Περιλαμβάνει
76
Μοντελοποίηση κλάσεων:
Απλοί Τύποι
• Οι απλοί τύποι μπορεί να είναι
◦ Ατομικά δεδομένα που συνοδεύονται από κανόνες
επαλήθευσης ή αποτελούνται από υποτμήματα. Π.χ
ταχυδρομικοί κωδικοί, ημερομηνίες, αριθμοί τηλεφώνου,
αριθμοί πιστωτικοί καρτών, διευθύνσεις IP, κ.τ.λ.
◦ Σύνθετα δεδομένα με εννοιολογική ενότητα όπως. π.χ
Βάρος ή ύψος (με διαφορετικές μονάδες μέτρησης),
χρήματα, εύρη ημερομηνιών
◦ Απλές απαριθμήσεις, π.χ. οι ημέρες της εβδομάδας, τα
χρώματα. Χρησιμοποιούνται οι απαριθμήσεις της UML
◦ Ομαδοποίηση ατομικών δεδομένων που απαρτίζουν μία
εννοιολογική οντότητα,. π.χ. ταχυδρομικές διευθύνσεις
77
Απλοί Τύποι - Παραδείγματα
EmailAddress ΤαχυδρΚώδικας Διεύθυνση Διάρκεια
eMail: String ταχΚωδ: String οδός: String αρχή: Date

isValid: Boolean αριθμός: String τέλος: Date
isValid: Boolean
ταχΚωδ : ZipCode
Ποσότητα Χρήματα
ποσότητα: BigDecimal ποσό: float

μονάδα: Unit νόμισμα: Currency
plus(other: Quantity): Quantity plus(other: Money): Money
minus(other: Quantity): Quantity minus(other: Money): Money
times(factor: BigDecimal): Quantity times(factor: BigDecimal): Money
dividedBy(divisor: BigDecimal): Quantity dividedBy(divisor: BigDecimal): Money
… convertTo(othCurrency: Currency): Money
...
78
Μοντέλο Πεδίου Τραπεζικού

Συστήματος με Απλούς Τύπους
• Οι τύποι ορισμένων ιδιοτήτων του μοντέλου, είναι
απλοί τύποι που ορίζονται ως κλάσεις
(EmailAddress, Address, ZipCode)
Πελάτης EmailAddress Διεύθυνση
επώνυμο eMail: String οδός: String

όνομα αριθμός: String
email: EmailAddress ταχΚωδ : ZipCode
διεύθυνση: Address
ΤαχυδρΚώδικας
ταχΚωδ: String
79
Απλοί Τύποι και Συσχετίσεις
• Εναλλακτικά τους απλούς τύπους μπορούμε να
τους εμφανίσουμε και ως συσχετίσεις (απλές ή
συναθροίσεις/συσσωματώσεις ή συνθέσεις).
1
Πελάτης EmailAddress
επώνυμο eMail: String
όνομα
Διεύθυνση ΤαχυδρΚώδικας
* 1
οδός: String ταχΚωδ: String
αριθμός: String
1
80
Μοντέλο Πεδίου Τραπεζικού

Συστήματος με ιδιότητες
1 *
Πελάτης Λογαριασμός
επώνυμο: String
αριθΛογ: AccountId 1
όνομα: String
/υπόλοιπο: Money
email: EmailAddress
*
1
1
Κάρτα
*
Διεύθυνση
αριθΚάρτας: CardId
Δοσοληψία
οδός: String pin: String
αριθμός: String ημερομηνία: Date ημερομΛήξης: Date
πόλη: String ποσό: Money δήλωσηΑπώλειας: Boolean
ΤΚ: ΤαχυδρΚώδικας /ενεργή:Boolean
81
Διάκριση ιδιοτήτων και κλάσεων
• Μερικές φορές η χρήση «String» μοιάζει φυσική αλλά το σωστό είναι
να χρησιμοποιήσουμε κλάση
◦ Αν χρειαζόμαστε περιορισμένο λεξιλόγιο ή ελέγχους, πολλαπλές
συσχετίσεις ή λειτουργίες, μάλλον πρέπει να επιλέξουμε κλάση
• Στις ιδιότητες προσέχουμε να μην επαναλαμβάνουμε πληροφορία
Βιβλίο Διεύθυνση
διεύθυνσηΕπικοινωνίας
Σφάλμα: ο τίτλος: String
διεύθυνσηΟικίας
...
εκδοτικός εκδοτικόςΟίκος: string
οίκος είναι isbn: ISBN
κλάση έκδοση: int
έτοςΕκδοσης: int
1
* Δανειζόμενος
Σφάλμα: ο Αντίτυπο * 1 επώνυμο: String

δανείζεται
τίτλος είναι αριθΕισαγωγής: Int όνομα: String
περιττός τίτλος: String email: EmailAddress
82
Αυτοσυσχέτιση
• Υπάρχει και η δυνατότητα αυτοσυσχέτισης.
• Η αυτοσυσχέτιση του σχήματος παράγει ιεραρχία
αντικειμένων (στο επίπεδο των αντικειμένων όχι
των κλάσεων)
◦ Εξαιρετικά χρήσιμη η παρουσία ονομάτων στα άκρα
Εποπτεύει
Υφιστάμενος *
Εργαζόμενος
0..1 Προϊστάμενος
83
Κλάση Συσχέτισης
• Μία κλάση συσχέτισης (association class)
αποδίδει ιδιότητες και λειτουργίες σε μία
συσχέτιση
• Η κλάση C είναι η κλάση συσχέτισης των Α και B
• Χρησιμοποιείται συνήθως σε συσχετίσεις «πολλά
προς πολλά»
Α Β
84
Διαγράμματα κλάσεων:
Παράδειγμα κλάσης Συσχέτισης
• Ένας εργαζόμενος συμμετέχει σε πολλά έργα της
εταιρείας που εργάζεται.
• Ερώτημα: Πώς θα απεικονιστεί το πλήθος των
ωρών που απασχολείται σε κάθε έργο και η
αρμοδιότητά του σε κάθε έργο;
* *
Εργαζόμενος Έργο
85
Διαγράμματα κλάσεων
Παράδειγμα κλάσης Συσχέτισης
• Υπάρχουν δύο λύσεις. Η πρώτη είναι με την κλάση
συσχέτισης. Η δεύτερη είναι με «ενδιάμεση» κλάση.
• Ο περιορισμός της κλάσης συσχέτισης είναι ότι ο
υπάλληλος δεν μπορεί να έχει δύο «συμμετοχές» στο ίδιο
έργο.
• Στο συγκεκριμένο παράδειγμα η κλάση συσχέτισης είναι η
σωστή λύση
1 *
* *
Συμμετοχή
Εργαζόμενος Έργο Εργαζόμενος
ρόλος
* ώρες
Συμμετοχή
ρόλος
ώρες Έργο 1
Κλάση συσχέτισης Ενδιάμεση κλάση 86
Διαφορές κλάσης συσχέτισης και

παρεμβαλλομένης κλάσης
• Οι δύο λύσεις μοιάζουν, αλλά δεν είναι ίδιες.
• Η χρήση της κλάσης συσχέτισης υπονοεί επιπλέον ότι δεν μπορεί να
υπάρξουν δύο αντικείμενα της κλάσης συσχέτισης για τον ίδιο
συνδυασμό αντικειμένων των κλάσεων που συσχετίζονται.
• Στο συγκεκριμένο παράδειγμα η κλάση συσχέτισης Συμμετοχή μάς
λέει ότι ένας εργαζόμενος μπορεί να εργάζεται σε διαφορετικά έργα,
αλλά δεν μπορεί ταυτόχρονα να έχει δύο συμμετοχές στο ίδιο έργο.
• Αντίθετα, στη λύση όπου η κλάση Συμμετοχή απλώς παρεμβάλλεται
μεταξύ του εργαζομένου και του έργου, επιτρέπεται ένας εργαζόμενος
να έχει πολλές συμμετοχές στο ίδιο έργο με διαφορετικούς ίσως
ρόλους και ώρες απασχόλησης.
• Έτσι στις συσχετίσεις πολλά-προς-πολλά, ανάλογα με τη σημασιολογία
που προκύπτει από το πρόβλημα, επιλέγεται η κλάση συσχέτισης ή η
παρεμβαλλόμενη κλάση
87
Προσδιοριστές (qualifiers)
• Οι προσδιοριστές εξειδικεύουν μία συσχέτιση, ορίζοντας το
γνώρισμα (ή τα γνωρίσματα) των οποίων οι τιμές ορίζουν το
σύνολο των αντικειμένων που συσχετίζονται με ένα αντικείμενο
μέσω της συσχέτισης
◦ Παράδειγμα 1:
◦ Αν κάθε άσκηση έχει μοναδικό αριθμό εντός ενός κεφαλαίου, αυτό μπορεί να
εκφραστεί με τη βοήθεια ενός προσδιοριστή:
1 0..1
Κεφάλαιο αριθ: Integer Άσκηση
Πρακτικά το κάθε στιγμιότυπο της κλάσης «Κεφάλαιο» περιέχει έναν

πίνακα από συνδέσμους προς στιγμιότυπα της κλάσης «Άσκηση»
Ο πίνακας δεικτοδοτείται από έναν ακέραιο (αριθ: Integer) και
επιστρέφει 0 ή 1 στιγμιότυπα της κλάσης «Άσκηση»
88
Γιατί προσδιοριστές;
• Με προσδιοριστές
1 0..1
Κεφάλαιο αριθ: Integer Άσκηση
– Ένα συγκεκριμένο κεφάλαιο και ένας αριθμός άσκησης οδηγούν

σε 0 ή 1 στιγμιότυπα της κλάσης «Άσκηση»
Χωρίς προσδιοριστές
1 0..*
Κεφάλαιο Άσκηση
– Γνωρίζουμε μόνο ότι ένα «κεφάλαιο» περιλαμβάνει 0 ή

περισσότερα στιγμιότυπα της κλάσης «Άσκηση»
Τελικά με τους προσδιοριστές η UML έχει μία έννοια παραπλήσια του
«κλειδιού», αλλά μόνο στα πλαίσια ενός συγκεκριμένου αντικειμένου
Προσοχή στο (α) ότι αλλάζουν οι πληθικότητες και (β) ο προσδιοριστής
ΔΕΝ είναι μέλος της κλάσης προς την οποία δείχνει (εδώ στην Άσκηση)
– Μπορεί όμως να αποθηκευθεί ως πλεοναστικό γνώρισμα (επόμενη
διαφάνεια) 89
Προσδιοριστές ως πλεοναστικά
γνωρίσματα
Κεφάλαιο
αριθ: Integer
1
{same}
0..1
Άσκηση
αριθ: Integer
90
Σημασιολογία πληθικότητας υπό την

παρουσία προσδιοριστών
• 0..1 : κάθε τιμή του γνωρίσματος-προσδιοριστή
επιλέγει 1 αντικείμενο αλλά μπορεί και κανένα
• 1 : κάθε τιμή του γνωρίσματος-προσδιοριστή
επιλέγει ακριβώς 1 αντικείμενο. Προφανώς
πρέπει το πεδίο ορισμού του γνωρίσματος-
προσδιοριστή να είναι πεπερασμένο
• * : η τιμή του γνωρίσματος-προσδιοριστή επιλέγει
πολλά αντικείμενα
• Η πληθικότητα είναι ανά τιμή του γνωρίσματος-
προσδιοριστή!
91
Τύπος δεδομένου προσδιοριστών
• Δεν είναι απαραίτητο να είναι ακέραιος
◦ Η «φυσική» υλοποίηση για τους προσδιοριστές με τύπο
«ακέραιο» είναι ένας πίνακας (ειδικότερα αν η αρίθμηση
ξεκινάει από το 0 ή το 1 και αυξάνεται κατά μία μονάδα
σε κάθε βήμα)
◦ Για προσδιοριστές με τύπο συμβολοσειράς μπορεί να
επιλεγεί άλλη δομή αναπαράστασης (π.χ. πίνακας
κερματισμού ή δένδρο αναζήτησης).
92
Παράδειγμα προσδιοριστή-
πληθικότητας-τύπου
• Στο σύστημα αρχείων του Unix το όνομα ενός αρχείου
αποθηκεύεται στον κατάλογο όπου αυτό περιέχεται
◦ Ένας κατάλογος μπορεί να περιέχει ένα αρχείο με ένα συγκεκριμένο
όνομα ή όχι
◦ Ένα όνομα μπορεί να βρίσκεται σε οποιοδήποτε πλήθος καταλόγων
Directory
filename: String
0..*
0..1
File
93
Περιορισμοί
• Μπορεί να ορισθεί ότι δύο συσχετίσεις είναι αμοιβαίως
αποκλειόμενες
πρόσωποΙδιοκτήτης
Πρόσωπο
λογαριασμός
Λογαριασμός {xor}
λογαριασμός
Εταιρεία
εταιρείαΙδιοκτήτης
94
• Μπορεί να οριστεί ότι μία συσχέτιση υπονοεί μία άλλη:
* ΜέλοςΤης *
Πρόσωπο {subset} Επιτροπή
1 ΠρόεδροςΤης *
Όπως και τα γνωρίσματα, και οι συσχετίσεις

μπορούν να σημειωθούν ως:
– changeable (εξ ορισμού χαρακτηρισμός)
– addOnly (μπορούν μόνο να προστεθούν σύνδεσμοι)
– frozen (καμία αλλαγή)
95
Διεπαφές
• Οι διεπαφές (interfaces) είναι μηχανισμοί των
σύγχρονων γλωσσών προγραμματισμού όπως η
Java για τη δημιουργία ενός «πακέτου»
συμπεριφοράς
◦ Οι κλάσεις που υλοποιούν κάποια διεπαφή ορίζουν όλες
πολυμορφικά την ίδια συμπεριφορά
• Μία διεπαφή μπορεί να θεωρηθεί ως μία κλάση
χωρίς πεδία όπου όλες οι πράξεις είναι
αφηρημένες.
96
Διεπαφές έναντι αφηρημένων κλάσεων

(1/2)
• Οι διεπαφές της Java μοιάζουν με τις αφηρημένες κλάσεις,
αλλά παρουσιάζουν και σημαντικές διαφορές που είναι:
◦ Οι αφηρημένες κλάσεις μπορεί να έχουν πεδία, ενώ οι διεπαφές όχι.
◦ Οι αφηρημένες κλάσεις μπορεί να έχουν αφηρημένες λειτουργίες,
δηλαδή χωρίς υλοποίηση, αλλά μπορεί να έχουν και συγκεκριμένες
λειτουργίες που κληρονομούνται από τις υποκλάσεις. Οι διεπαφές
δηλώνουν τις υπογραφές των λειτουργιών, χωρίς να παρέχουν καμία
υλοποίηση
◦ Συνακόλουθα, ενώ οι υποκλάσης μιας αφηρημένης κλάσης μπορούν να
επανορίζουν λειτουργίες, οι κλάσεις που υλοποιούν μία διεπαφή ορίζουν τις
λειτουργίες εξ αρχής
◦ Οι αφηρημένες κλάσεις δηλώνουν κατασκευαστές, ενώ οι διεπαφές όχι
◦ Η ορατότητα μίας διεπαφής για τη Java μπορεί να είναι μόνο δημόσια ή
προκαθορισμένη (πακέτο)
◦ Οι λειτουργίες μίας αφηρημένης κλάσης μπορεί να έχουν ορατότητα
προστατευμένη ή ιδιωτική, ενώ οι λειτουργίες που δηλώνει μία
διεπαφή έχουν δημόσια ορατότητα.
97
Διεπαφές έναντι αφηρημένων κλάσεων
(2/2)
• Οι διεπαφές της Java μοιάζουν με τις αφηρημένες
κλάσεις, αλλά παρουσιάζουν και σημαντικές
διαφορές που είναι (συνέχεια):
◦ Μία κλάση μπορεί να υλοποιεί (και δεν κληρονομεί) μία ή
περισσότερες διεπαφές.
◦ Η κλάση θα πρέπει να παρέχει την υλοποίηση για τις μεθόδους που
δηλώνει μία διεπαφή, να παρέχει δηλαδή την υλοποίηση της
διεπαφής
◦ Αντίθετα μία κλάση που κληρονομεί από μία αφηρημένη κλάση μπορεί να
μην υλοποιεί μερικές μεθόδους, καθιστώμενη και αυτή αφηρημένη με τη
σειρά της
98
Διεπαφές - Σύνοψη
• Επομένως, μία διεπαφή έχει περισσότερο το χαρακτήρα
μίας δήλωσης. Δηλώνει υπογραφές (signatures) μεθόδων
στις οποίες μία κλάση θα πρέπει να συμμορφώνεται σε
περίπτωση που υλοποιεί τη διεπαφή.
• Οι διεπαφές είναι και το βασικό αντίδοτο για τις γλώσσες
προγραμματισμού που δεν υποστηρίζουν την πολλαπλή
κληρονομικότητα. Μία κλάση μπορεί να είναι υποκλάση
μίας και μόνο κλάσης, ενώ μπορεί να υλοποιεί πολλές
διεπαφές.
99
Διεπαφές – Συμβολισμός
υλοποίησης διεπαφής
Υλοποίηση διεπαφής
– το όνομα της
<<interface>> διεπαφής σημειώνεται
ΜεταφορικόΜέσο δίπλα από κύκλο
ΜεταφορικόΜέσο Αυτοκίνητο
travelTo(dest: Destination)
ΜεταφορικόΜέσο Πλοίο
Αυτοκίνητο Πλοίο Υλοποίηση διεπαφής

– διάστικτη γραμμή
από κλάση προς τη
διεπαφή
100
Οι δύο συμβολισμοί της UML για την

παροχή και χρήση διεπαφής
<<interface>>
ΜεταφορικόΜέσο
Χρήση
Πρόσωπο
διεπαφής
Πρόσωπο
Παροχή
και χρήση Πρόσωπο Αυτοκίνητο Κλάση που
διεπαφής
υλοποιεί τη
διεπαφή
Πρόσωπο Αυτοκίνητο
101
Γενίκευση διεπαφών
• Οι διεπαφές μπορούν να οργανώνονται και σε
ιεραρχίες με χρήση γενίκευσης
<<interface>>
ΜεταφορικόΜέσο
Γενίκευση
διεπαφής
<<interface>>
Όχημα
Αυτοκίνητο
Υλοποίηση
διεπαφής 102
Συνύπαρξη διεπαφών και

αφηρημένων κλάσεων
<<interface>> <<interface>>
Όχημα ΜεταφορικόΜέσο
travelTo(dest: Destination) travelTo(dest: Destination)
Αυτοκινούμενο {abstract}
Αυτοκίνητο Φορτηγό Πλοίο
103
Διαγράμματα αντικειμένων
• Εμφανίζουν κάποιο στιγμιότυπο των αντικειμένων και των
σχέσεών τους
◦ Τα αντικείμενα είναι στιγμιότυπα των κλάσεων
• Εμφανίζουμε και τις συγκεκριμένες τιμές που λαμβάνουν
οι ιδιότητες
• Οι σύνδεσμοι είναι στιγμιότυπα των συσχετίσεων
• Συνδέουν τα αντικείμενα μεταξύ τους
Γιάννης: Student : Student
lastName = ‘Νικολάου’ lastName = ‘Πέτρου’ Ανώνυμο
firstName = ‘Γιάννης’ firstName = ‘Γιώργος’ αντικείμενο
: Πρόσωπο : Αντικείμενο
104
Διαγράμματα Αντικειμένων -
Αντικείμενα
• Ο συμβολισμός των αντικειμένων είναι όμοιος με
το συμβολισμό των κλάσεων με τη διαφορά ότι το
τμήμα του ονόματος είναι υπογραμμισμένο
• Τυπική σύνταξη αντικειμένου
◦ όνομα_αντικειμένου : όνομα_κλάσης
◦ Για ανώνυμα αντικείμενα : όνομα_κλάσης
• Οι ιδιότητες των κλάσεων έχουν πλέον και τιμές
• Σε ένα διάγραμμα αντικειμένων απεικονίζουμε
ένα δίκτυο αντικειμένων για κάποια χρονική
στιγμή
105
Χρήση Διαγραμμάτων Αντικειμένων
• Επαλήθευση διαγραμμάτων κλάσεων
• Εμφάνιση σχέσεων για τις οποίες τα διαγράμματα κλάσεων δεν
επαρκούν – για παράδειγμα ιεραρχικές σχέσεις αντικειμένων
106
Χρήση Διαγραμμάτων Αντικειμένων

• Το διάγραμμα κλάσεων μας δίνει μία γενική δομή μίας ιεραρχίας
• Το διάγραμμα αντικειμένων μας δίνει την ίδια την ιεραρχία
Εποπτεύει
Υφιστάμενη
*
Διάγραμμα
κλάσεων Οργανωτική
μονάδα 0..1 Προϊστάμενη
Διάγραμμα
Βιβλιοθήκη: Οργανωτική μονάδα
αντικειμένων
Τμήμα Βιβλίων: Οργανωτική Αναγνωστήριο: Οργανωτική

μονάδα μονάδα
Τμήμα Επιστημονικών Περιοδικών:

Οργανωτική μονάδα 107
Από την διατύπωση του
προβλήματος στον κώδικα
• Διατύπωση προβλήματος: σε ένα χρηματιστήριο
υπόκεινται σε διαπραγμάτευση μετοχές εταιρειών, με
κάθε μία να αναπαρίσταται από ένα σύμβολο
• Διάγραμμα κλάσεων:
StockExchange * * Company
Lists tickerSymbol
Κώδικας Java
public class StockExhange {
private Vector<Company> m_Company = new Vector Vector<Company> ();
} Οι συσχετίσεις απεικονίζονται σε
γνωρίσματα (ανάλογα με την
public class Company { πλοηγισιμότητα!)
public int m_tickerSymbol;
private Vector<StockExchange> m_StockExchange = new Vector<StockExchange>();
}
108
Παραγωγή κώδικα Java από UML

public class Component { }
*
Component
public class Leaf extends Component { }
Leaf Composite public class Composite extends Component

{
private Collection<Component>
components;
…
}
109
Διαγράμματα ακολουθίας – βασική
σημειογραφία
• Τα διαγράμματα ακολουθίας αναπαριστούν τη συμπεριφορά
του συστήματος με τη μορφή μηνυμάτων μεταξύ διαφορετικών
: Student : Portal : Blog
αντικείμενο
navigateToBlog() show()
pushAddButton() showEntryForm()
μήνυμα
edit()
submit()
<<create>>
: BlogEntry
setProperties()
Προδιαγραφή
update()
εκτέλεσης Γραμμή ζωής
110
Γραμμή ζωής και προδιαγραφή

εκτέλεσης
• Μία γραμμή ζωής αναπαριστά έναν συγκεκριμένο
συμμετέχοντα (ή αντικείμενο) στη διάδραση
◦ Απεικονίζεται με ένα ορθογώνιο που αναπαριστά το
αντικείμενο, το οποίο ακολουθείται από μία κάθετη
γραμμή που αναπαριστά τον χρόνο ζωής του
συμμετέχοντα
• Μία προδιαγραφή εκτέλεσης καθορίζει μία
συμπεριφορά ή διάδραση εντός της γραμμής ζωής
◦ Απεικονίζεται ως ένα ορθογώνιο πάνω από τη γραμμή
ζωής
111
Μηνύματα
• Τα μηνύματα ορίζουν μία συγκεκριμένη επικοινωνία
μεταξύ γραμμών ζωής σε μία διάδραση
• Παραδείγματα επικοινωνίας:
◦ Αποστολή ενός σήματος
◦ Κλήση μιας λειτουργίας
◦ Δημιουργία ή καταστροφή ενός στιγμιοτύπου
• Καθορίζουν (έμμεσα) τον αποστολέα και τον παραλήπτη

◦ Απεικονίζονται με τη μορφή μιας γραμμής από τον αποστολέα προς
τον παραλήπτη
◦ Η μορφή της γραμμής και του τόξου αντικατοπτρίζουν τις ιδιότητες
του μηνύματος
112
Είδη μηνύματος
• Ασύγχρονο
• Σύγχρονο
◦ Κλήση λειτουργίας και δημιουργία
• Απόκριση
• Απωλεσθέν
◦ γνωστή η αποστολή αλλά όχι η
παραλαβή – συνήθως ερμηνεύεται
ότι η παραλαβή είναι εκτός του
πεδίου του συστήματος
• Ευρεθέν
◦ Γνωστή η παραλαβή αλλά όχι η
αποστολή
113
Διαγράμματα ακολουθίας
• Η έμφαση είναι στον έλεγχο ροής
TicketMachine
Passenger • Χρησιμοποιούνται στην ανάλυση για:
selectZone() ◦ Εκλέπτυνση των περιπτώσεων χρήσης
◦ Εύρεση πρόσθετων αντικειμένων που έχουν
διαλάθει
insertCoins()
• Χρησιμοποιούνται στον σχεδιασμό για:
◦ Εκλέπτυνση των διεπαφών
pickupChange() TicketMachine
selectZone()
pickUpTicket() insertCoins()
pickupChange()
pickUpTicket()
114
Διαγράμματα ακολουθίας και ροή

δεδομένων
• Τα διαγράμματα ακολουθίας μπορούν επίσης να δείχνουν
τη ροή των δεδομένων
◦ Οι αφετηρίες των τόξων δείχνουν την ενεργοποίηση των μηνυμάτων
◦ Οι διάστικτες γραμμές δείχνουν ροή δεδομένων, π.χ. επιστροφή
αποτελεσμάτων
ZoneButton FareCatalogue Display

Passenger
selectZone()
lookupFare(selection)
fare
Ροή δεδομένων
displayFare(fare)
115
Διαγράμματα ακολουθίας:
επαναλήψεις και συνθήκες
• Οι επαναλήψεις δηλώνονται με έναν αστερίσκο
πριν από το μήνυμα
• Οι συνθήκες εντός αγκυλών πριν το μήνυμα
MoneyProcessor CoinIdentifier Display CoinDrop

Passenger
* insertMoney(coin)
lookupCoin(coin)
coinValue
Επανάληψη
displayPrice(owedAmount)
[owedAmount<0] returnChange(-owedAmount)
Συνθήκη 116
Δημιουργία και καταστροφή

• Η δημιουργία αντικειμένου συμβολίζεται με ένα μήνυμα που δείχνει
στο αντικείμενο (ή με ένα μήνυμα <<create>> και θέτοντας τη γραμμή
ζωής να ξεκινά από το συγκεκριμένο σημείο)
• Η καταστροφή αντικειμένου συμβολίζεται με ένα «Χ» και τερματισμό
της γραμμής ζωής
◦ Σε περιβάλλοντα με συλλογή απορριμμάτων, η καταστροφή δηλώνει το
τέλος της χρήσης του αντικειμένου
MoneyProcessor
Passenger
createTicket(selection)
Ticket
print()
free()
X 117
Ιδιότητες διαγραμμάτων
• Τα διαγράμματα ακολουθίας της UML
αναπαριστούν συμπεριφορά σε όρους
διαδράσεων
• Είναι χρήσιμα για τον προσδιορισμό ή τον
εντοπισμό αντικειμένων ή λειτουργιών που
λείπουν
• Είναι χρονοβόρα στην κατασκευή τους, αλλά
αξίζουν τον κόπο
• Συμπληρώνουν τα διαγράμματα κλάσεων (που
αναπαριστούν τη δομή)
118
Διαγράμματα μηχανής καταστάσεων

Αρχική κατάσταση
Συμβάν
Αναβόσβησε Αύξησε ώρες
ώρες
μετάβαση
κατάσταση Αναβόσβησε Αύξησε
λεπτά λεπτά
πάτημαΚουμπιού2 Αύξησε
Σταμάτα να Αναβόσβησε
αναβοσβήνεις δευτερόλεπτα δευτερόλεπτα
Τελική κατάσταση
Αναπαριστά τη συμπεριφορά ενός μοναδικού αντικειμένου την οποία
κρίνουμε ενδιαφέρουσα. 119
Διαγράμματα δραστηριότητας
• Διαγράμματα συμπεριφοράς με έμφαση στη ροή ελέγχου
• Δείχνουν την ακολουθιακή ή παράλληλη ροή δραστηριοτήτων
αναπαριστώντας τη ροή εκτέλεσης (workflow) OXI μόνο στο
λογισμικό αλλά και γενικότερα
• Υπάρχουν από την UML 2 και μετά
• Ένα διάγραμμα δραστηριότητας αποτελείται από κόμβους και
ακμές
• Υπάρχουν τρία είδη κόμβων δραστηριότητας
◦ Κόμβοι ελέγχου
◦ Εκτελέσιμοι κόμβοι
◦ Πιο συνηθισμένος: Action (ενέργεια)
◦ Κόμβοι αντικειμένων
◦ π.χ. ένα έγγραφο
• Μία ακμή είναι μία κατευθυνόμενη σύνδεση μεταξύ κόμβων
◦ Δύο βασικοί τύποι ακμών
◦ Ακμές ροής ελέγχου
◦ Ακμές ροής αντικειμένων
120
Σύμβολα κόμβων ελέγχου σε

διαγράμματα δραστηριότητας
Κόμβος έναρξης
Κόμβος ολοκλήρωσης δραστηριότητας
Κόμβος ολοκλήρωσης ροής
Κόμβος διακλάδωσης (διχάλα - fork)
Κόμβος συνένωσης (join)
Κόμβος απόφασης
Κόμβος συγχώνευσης
121
Σύμβολα κόμβων δραστηριότητας και
Κόμβος ενέργειας
Κόμβος αντικειμένου
Συγγραφή Διόρθωση
Εργασία
εργασίας εργασίας
122
Παράδειγμα διαγράμματος
δραστηριότητας
Ακμή ροής διακλάδωση
Αρχικός Κόμβος ελέγχου
κόμβος απόφασης
[παραγγελία
δεκτή]
Παραλαβή Εκτέλεση
παραγγελίας παραγγελίας
[παραγγελία
όχι δεκτή]
Αποστολή
παραγγελίας
Κλείσιμο
παραγγελίας Αποδοχή Πραγματοποίηση Αποστολή
πληρωμής πληρωμής τιμολογίου
Ακμή ροής Τιμολόγιο

συνένωση αντικειμένου
123
Διαγράμματα Δραστηριότητας:
Ακίδες
• Οι ακίδες (pins) είναι ένας εναλλακτικός συμβολισμός των
κόμβων αντικειμένων
◦ Ένας κόμβος ενέργειας μπορεί να έχει πολλές ακίδες εξόδου και
πολλές ακίδες εισόδου
◦ Αν μία ενέργεια έχει ακίδες εισόδου, πρέπει οι ακίδες εισόδου να
έχουν τιμές προκειμένου να ξεκινήσει η εκτέλεση της ενέργειας
Παραγγελία
Δημιουργία Παραλαβή
παραγγελίας Παραγγελία παραγγελίας
Τιμολόγιο Τιμολόγιο
Αποστολή Εξόφληση
τιμολογίου τιμολογίου
Ακίδες
124
Διαγράμματα παράταξης
• Τα διαγράμματα παράταξης (deployment diagrams)
παρουσιάζουν το πραγματικό περιβάλλον στο οποίο
λειτουργεί το λογισμικό.
• Ένα διάγραμμα παράταξης παρουσιάζει συσκευές του
υλικού και τις φυσικές μονάδες λογισμικού που
διανέμονται στο υλικό.
• Τα διαγράμματα παράταξης είναι ένα μέσο για την
τεκμηρίωση της φυσικής αρχιτεκτονικής του συστήματος.
• Το βασικό στοιχείο ενός διαγράμματος παράταξης είναι οι
κόμβοι (nodes).
125
Διαγράμματα παράταξης –
κατηγορίες κόμβων
• Η πρώτη κατηγορία των κόμβων είναι οι συσκευές
(devices) που αναπαριστούν φυσικές μονάδες
επεξεργασίας που αντιστοιχούν στο υλικό. Οι συσκευές
έχουν μνήμη και επεξεργαστική ικανότητα.
• Η δεύτερη κατηγορία των κόμβων είναι τα περιβάλλοντα
εκτέλεσης (execution environments). Περιβάλλοντα
εκτέλεσης είναι λογισμικό συστημάτων, όπως τα
λειτουργικά συστήματα, τα συστήματα διαχείρισης
βάσεων δεδομένων κ.ά.
• Και για τα δύο χρησιμοποιούμε συμβολισμό αντικειμένων
και όχι κλάσεων, γιατί μιλάμε για συγκεκριμένα
μηχανήματα και τμήματα λογισμικού
126
Διαγράμματα παράταξης
<<device>>
: DatabaseServer
<<executionEnvironment>>
: LinuxOS
: MySQL
127
Μονοπάτια επικοινωνίας στα
διαγράμματα παράταξης
• Οι κόμβοι επικοινωνούν μεταξύ τους μέσω μονοπατιών
επικοινωνίας (communications paths) και απεικονίζουν
τυπικά διασύνδεση μέσω δικτύου. Τα μονοπάτια
επικοινωνίας είναι εξειδίκευση των συσχετίσεων και
συμβολίζονται με απλές γραμμές
<<device>> <<device>>
: DatabaseServer : ApplicationServer
<<executionEnvironment>> <<executionEnvironment>>
: LinuxOS : LinuxOS
<<executionEnvironment>> <<executionEnvironment>>
: MySQL : Tomcat 7
128
Προϊόντα στα διαγράμματα

παράταξης
• Ένας κόμβος μπορεί να περιέχει ένα προϊόν (artifact) το
οποίο είναι μία διακριτή φυσική οντότητα του λογισμικού
και το οποίο είναι συνήθως ένα αρχείο. Ένα προϊόν μπορεί
να είναι ένα εκτελέσιμο αρχείο, ένα αρχείο ρυθμίσεων,
σελίδες HTML κ.ά. Ένα προϊόν φέρει τη λέξη-κλειδί
«artifact» ή ένα εικονίδιο που παρουσιάζεται στο σχήμα
της επόμενης διαφάνειας
• Οι κόμβοι περιέχουν προϊόντα (artifacts) που είναι οι
φυσικές μονάδες λογισμικού, όπως είναι τα εκτελέσιμα
αρχεία, τα αρχεία jar, τα αρχεία war, αρχεία ρυθμίσεων,
σελίδες HTML κ.λπ.
129
Συμβολισμοί για τα προϊόντα στα
διαγράμματα παράταξης
• Συμβολισμός 1: με τη λέξη-κλειδί <<artifact>>
• Συμβολισμός 2: με εικονίδιο εντός του πλαισίου
<<artifact>>
libraryLogic.war libraryLogic.war
130
Ένα συνολικό διάγραμμα παράταξης

<<device>>
<<device>> : ApplicationServer
: RemotePC
<<executionEnvironment>> : Apache 2
: Browser
: Tomcat 7
libraryLogic.war
<<device>>
: LocalPC
<<device>>
<<executionEnvironment>> : DatabaseServer
: Browser
: MySQL
131
Ένα συνολικό διάγραμμα
παράταξης
• Το διάγραμμα της προηγούμενης διαφάνειας
εμφανίζει μία αρχιτεκτονική τριών επιπέδων (3-
tier architecture).
◦ Ένα επίπεδο είναι η βάση δεδομένων
◦ Ένα επίπεδο είναι ο εξυπηρέτης διαδικτύου
◦ Ένα επίπεδο είναι οι υπολογιστές των χρηστών με τα
προγράμματα πλοήγησης
132
Προδιαγραφές παράταξης
• Ένα διάγραμμα παράταξης μπορεί να έχει μία
προδιαγραφή παράταξης
<<device>>
<< deployment spec>> : ApplicationServer
libspec.xml
: Apache 2
<<artifact>> : Tomcat 7
libraryLogic.war
<<deploy>>
libraryLogic.war
133
Διαγράμματα διάδρασης
• Νέα έννοια του αποσπάσματος διάδρασης
◦ Διάδραση είναι ένα κομμάτι συμπεριφοράς που εστιάζεται στην
παρατηρήσιμη ανταλλαγή πληροφορίας μεταξύ αντικειμένων που μπορούν
να συνδέονται
• Υπάρχουν 4 είδη διαγραμμάτων διάδρασης:
◦ Διαγράμματα ακολουθίας
◦ Διαγράμματα επικοινωνίας
◦ Συνδυασμός πληροφοριών από τα διαγράμματα κλάσεων, περιπτώσεων
χρήσης, και ακολουθίας. Μοιάζουν με τα διαγράμματα ακολουθίας,
αναπαριστώντας πιο εύληπτα το ποιός επικοινωνεί με ποιόν, ενώ τα
διαγράμματα ακολουθίας δίνουν καλύτερα τη σειρά των μηνυμάτων
◦ Διαγράμματα επισκόπησης αλληλεπίδρασης
◦ Μοιάζουν με τα διαγράμματα δραστηριότητας, ωστόσο κάθε κόμβος
ενέργειας μπορεί να αναλύεται περαιτέρω χρησιμοποιώντας
οποιοδήποτε τύπο διαγράμματος διάδρασης
◦ Διαγράμματα χρονισμού
◦ Εστιάζει στους χρονικούς περιορισμούς. Μοιάζει με διάγραμμα
ακολουθίας περιεστραμμένο κατά 900 ώστε ο οριζόντιος άξονας να είναι ο
χρόνος
134
Διαδράσεις
• Οι διαδράσεις στη UML χρησιμοποιούνται κυρίως στην
ανάλυση για να κατανοήσουμε καλύτερα τις διαδράσεις
μεταξύ των αντικειμένων
• Χρησιμοποιούνται επίσης κατά τον λεπτομερή σχεδιασμό,

ειδικότερα αν απαιτείται ακριβής διαδιεργασιακή
επικοινωνία βασισμένη σε τυπικά πρωτόκολλα
• Μπορούν επίσης να χρησιμοποιηθούν κατά τον έλεγχο για

να περιγράψουν την επιθυμητή συμπεριφορά του
συστήματος και να τη συγκρίνουμε έτσι με την
παρατηρούμενη συμπεριφορά
135
Παράδειγμα διάδρασης: διάγραμμα
Όνομα διάδρασης (sd:
sd UserAccepted πλαίσιο διάδρασης)
+PIN: Integer {readonly 0 <= PIN <= 9999}

Τοπικό γνώρισμα
: User : ATM
Code(PIN)
Γραμμή ζωής
CardOut
OK
Unlock
Το μήνυμα πηγαίνει στο όριο

του διαγράμματος. Υποθέτουμε
Τα μηνύματα παραδίδονται με σειρά αντίστροφη την ύπαρξη μιας πύλης με το
από αυτή που αποστέλλονται – μπορεί να συμβεί όνομα out_Unlock
136
σε ασύγχρονα μηνύματα
Παράδειγμα διάδρασης:
διάγραμμα επικοινωνίας
137
Παράδειγμα διάδρασης: διάγραμμα
επισκόπησης αλληλεπίδρασης
138
Παράδειγμα διάδρασης:
διάγραμμα χρονισμού
139
Απόσπασμα διάδρασης
• Είναι ένα τμήμα μιας διάδρασης
• Έχει ακριβώς τη λειτουργικότητα μιας διάδρασης
• Μπορούμε να έχουμε συνδυασμούς αποσπασμάτων διάδρασης
◦ Είναι αποσπάσματα διάδρασης που συνδυάζονται μέσω τελεστών
140
Τελεστές για αποσπάσματα διάδρασης

alt Αντίστοιχο του if then else
opt Αντίστοιχο του if then (χωρίς else)
par Τα τμήματα εκτελούνται παράλληλα
loop Επανάληψη, με δυνατότητα ορισμού ορίων & συνθήκης τερματισμού
break Τερματισμός του αποσπάσματος διάδρασης (συνήθως υπό συνθήκη)
critical Δύο «critical» στο ίδιο lifeline δεν εκτελούνται ποτέ παράλληλα
neg Μηνύματα που η παρουσία τους δείχνει προβλεπόμενη αποτυχία του συστήματος,
π.χ. ένα μήνυμα «timeout» σε μία απομακρυσμένη σύνδεση
assert Ορίζει μία συνθήκη που πρέπει να ισχύει για να συνεχίσει η διάδραση
strict Τα τμήματα εκτελούνται αυστηρά σειριακά
seq Όταν έχουμε ενεργοποιήσεις σε διαφορετικά αποσπάσματα και σε διαφορετικές
γραμμές ζωής, αυτές μπορεί να γίνουν με οποιαδήποτε σειρά
ignore Μηνύματα που θεωρούνται όχι σημαντικά και δεν φαίνονται στο σχήμα π.χ.
ignore{get,set}
consider Μόνο αυτά τα μηνύματα θεωρούνται σημαντικά και φαίνονται στο σχήμα π.χ.
consider{add,delete,remove,update}
141
Παραδείγματα τελεστών
Πιθανώς ατέρμονος βρόχος Ακριβώς 10 επαναλήψεις Από 5 έως 10 επαναλήψεις και

εφ’ όσον αληθεύει η συνθήκη
http://www.uml-diagrams.org/sequence-diagrams.html
142
Εκτέλεσε την αναζήτηση στα google, bing και ask,

αν είναι δυνατόν παράλληλα
Πρώτα γίνεται αναζήτηση στο google, Η αναζήτηση στο google γίνεται

μετά στο bing και μετά στο yahoo παράλληλα με τις άλλες, αλλά αυτή στο
bing γίνεται πριν από αυτή στο yahoo143
Πιθανώς να υπάρχουν και μηνύματα

Τα add και remove δεν θα εκτελεστούν get και set, αλλά δεν απεικονίζονται
ποτέ ταυτόχρονα θεωρούμενα μη σημαντικά
Πιθανώς να υπάρχουν και Μόνο οι καταστάσεις Αν λάβουμε μήνυμα

άλλα μηνύματα, αλλά δεν όπου αληθεύει το timeout το σύστημα έχει
απεικονίζονται t==complete είναι αποτύχει
έγκυρες στο σύστημα
144
Χρονικοί περιορισμοί στα

διαγράμματα UML
• Μπορούμε να ορίσουμε ορισμούς χρονικής διάρκειας
Τα μηνύματα με χρονικούς
περιορισμούς
αναπαρίστανται ως
κεκλιμένες γραμμές
Από την πλοήγηση μέχρι την επιστροφή της απάντησης μπορούμε να έχουμε από 3 sec έως
5min. Η αποστολή του μηνύματος της αίτησης πρέπει να διαρκέσει λιγότερο από 10 sec
145
Στερεότυπα στη UML
• Τα στερεότυπα είναι ένας τρόπος επέκτασης υπαρχουσών
μετα-κλάσεων
• Παράδειγμα:
<<metaclass>> <<stereotype>>
Class Computer
os: OperatingSystem
osVersion: Integer
vendor: String
• Τα στερεότυπα χρησιμοποιούνται για να φτιάξουμε νέα στοιχεία
των μοντέλων που βασίζονται σε υπάρχοντα, αλλά που έχουν
εξειδικευμένες ιδιότητες, κατάλληλες για το συγκεκριμένο
πρόβλημα (ή σύνολο προβλημάτων)
• Π.χ. αν μοντελοποιούμε ένα εταιρικό δίκτυο, θέλουμε κλάσεις για
δρομολογητές, μεταγωγείς, εκτυπωτές, εξυπηρέτες κ.λπ.
146
Σημειογραφία στερεοτύπων
• Είτε με εισαγωγικά πριν το όνομα
<<Computer>>
ApplicationServer
• Είτε με κάποιο γραφικό εντός του συμβόλου
• Είτε με μόνο το γραφικό

ApplicationServer
ApplicationServer
147
Οδηγίες για στερεότυπα
• Η χρήση γραφικών προάγει την αναγνωσιμότητα, ειδικότερα για κοινό
που δεν είναι εξοικειωμένο με τη UML
◦ Χωρίς να θυσιάζει τη συμβατότητα με τη UML
• Η κατάχρηση γραφικών μπορεί όμως να έχει τα αντίθετα

αποτελέσματα
◦ Πρόσθετος φόρτος εκμάθησης των συμβόλων, ειδικότερα αν έχουμε και
αφηρημένες έννοιες
• Μπορούν να οριστούν προφίλ που περιέχουν πολλά στερεότυπα για

ένα συγκεκριμένο χώρο (π.χ. προφίλ MARTE για εφαρμογές
πραγματικού χρόνου και ενσωματωμένες εφαρμογές)
• Προσοχή, τα εισαγωγικά δεν σηματοδοτούν πάντα στερεότυπο!
◦ «interface», «extend» είναι βασικά στοιχεία της UML!
148

ENGINEERING)
Οργάνωση έργου και επικοινωνία στο έργο
1
Εισαγωγή - συνεργασία
• Η τεχνολογία λογισμικού είναι μία συνεργατική
δραστηριότητα
◦ Συμμετέχουν μέλη με διαφορετικό υπόβαθρο, όπως ειδικοί στο
αντικείμενο, αναλυτές, σχεδιαστές, προγραμματιστές, στελέχη
διοίκησης, γραφίστες, χρήστες
◦ Κανείς δεν μπορεί να κατανοήσει (και να λύσει!) το πρόβλημα
μόνος του, συνεπώς κάθε ένας εξαρτάται από άλλους
◦ Οι συνεχείς αλλαγές καθιστούν απαραίτητο ο κάθε μετέχων να
επικαιροποιεί τις γνώσεις και την αντίληψή του για το πρόβλημα
Εισαγωγή - επικοινωνία
• Η επικοινωνία σε ένα έργο μπορεί να έχει πολλές
μορφές ανάλογα με τη δραστηριότητα που
υποστηρίζει
◦ Σε συναντήσεις με αποτύπωση στα πρακτικά, σε αναφορές
προς τον πελάτη, σε μοντέλα και τεκμηρίωση, σε άτυπες
τηλεφωνικές ή κατ’ ιδίαν συνομιλίες κ.λπ.
◦ Σε μεγάλα έργα, η επικοινωνία μπορεί να είναι αρκετά
χρονοβόρα, μειώνοντας τον χρόνο που διατίθεται σε τεχνικές
ενέργειες
◦ Είναι ουσιώδες να οργανωθούν ομάδες και να διαμοιράζεται η
πληροφορία, τόσο μέσω τυπικών όσο και άτυπων καναλιών
3
Ορισμός έργου (τεχνολογίας
λογισμικού)
• Ένα έργο είναι ένα εγχείρημα, με συγκεκριμένο χρονικό
ορίζοντα, όπου πρέπει να επιτευχθεί ένα σύνολο στόχων το
οποίο απαιτεί συντονισμένες προσπάθειες
• Ένα έργο περιλαμβάνει:
◦ Ένα σύνολο παραδοτέων στους πελάτες
◦ Ένα χρονοδιάγραμμα
◦ Τεχνικές και διοικητικές ενέργειες που απαιτούνται για να παραδοθούν τα
παραδοτέα
◦ Πόρους που καταναλώνονται από τις δραστηριότητες (άνθρωποι,
προϋπολογισμός)
• Εστίαση της διοίκησης έργου
◦ Διαχείριση των πόρων
◦ Διατήρηση του ποιος είναι υπεύθυνος για ποια πράγματα
◦ Αντίδραση στις αλλαγές
◦ Διασφάλιση ότι οι στόχοι θα επιτευχθούν
4
Μοντελοποίηση του έργου σε UML
Έργο
Παραδοτέα Χρονοδιάγραμμα Δραστηριότητα Πόρος
5
Εκλέπτυνση του μοντέλου
Εξοπλισμός
Έργο
* Μέσο (facility)
Πόρος Χρηματοδότηση
Δομή * Οργάνωση
κατάτμησης περι- Πακέτο
Χρονοδιάγραμμα γράφει εργασίας
εργασίας
*
* * *
παράγει Υπεύ- Οργανωτική
Αποτέλεσμα
Εργασία θυνος μονάδα *
* * για παίζει
εξαρτάται
Ρόλος
Σύνολο Προϊόν
Δραστη- Συμμετέχων Προσω-
προϊόντων εργασίας Καθήκον
ριότητα πικό
εργασίας
Εσωτερικό Παραδοτέο
προϊόν εργασίας Λειτουργία έργου Τμήμα Ομάδα
Μοντελοποίηση του έργου σε

UML
• Διάγραμμα καταστάσεων του έργου
Ορίστηκε η εμβέλεια
Ορισμός Έναρξη
do/Όρισε εμβέλεια do/Ανάθεσε καθήκοντα
Ανατέθηκαν τα
καθήκοντα
Τερματισμός
Σταθερή κατάσταση
do/Παράδωσε το σύστημα do/Ανάπτυξε το σύστημα
Ολοκληρώθηκε το σύστημα
7
Εργασίες σε κάθε κατάσταση
(φάση) του έργου (1/3)
• Ορισμός έργου
◦ Μετέχουν ο διοικητής του έργου, ο πελάτης και ο αρχιτέκτονας λογισμικού
◦ Εστιάζουμε στην αρχική κατανόηση της αρχιτεκτονικής του λογισμικού
(ιδιαίτερα στην αποσύνθεση σε υποσυστήματα) και στο έργο ιδιαίτερα στο
χρονοδιάγραμμα, τη δουλειά που πρέπει να γίνει και τους πόρους
◦ Παράγονται τρία έγγραφα, η διατύπωση του προβλήματος (problem
statement), η αρχική αρχιτεκτονική λογισμικού (initial software architecture)
και το αρχικό σχέδιο διαχείρισης έργου λογισμικού (initial software project
management plan)
• Έναρξη του έργου
◦ Ο διοικητής έργου δημιουργεί την υποδομή του έργου, προσλαμβάνει τους
συμμετέχοντες, τους οργανώνει σε ομάδες, αναθέτει καθήκοντα σε ομάδες
και καθορίζει τα ορόσημα (milestones)
Κατά τις δύο αυτές φάσεις, η περισσότερη δουλειά γίνεται από τον διοικητή
έργου

• «Σταθερή κατάσταση» έργου
◦ Οι συμμετέχοντες υλοποιούν το σύστημα
◦ Οι συμμετέχοντες αναφέρονται στον επικεφαλής της ομάδας τους, ο
οποίος είναι υπεύθυνος να παρακολουθεί την πρόοδο των εργασιών
και να εντοπίζει προβλήματα
◦ Οι επικεφαλείς των ομάδων αναφέρονται στον διοικητή του έργου,
ο οποίος αποτιμά την κατάσταση του όλου έργου.
◦ Οι επικεφαλείς των ομάδων αντιμετωπίζουν αποκλίσεις από το
αρχικό σχέδιο, είτε ανακατανέμοντας τις αναθέσεις είτε ζητώντας
πρόσθετους πόρους από τον διοικητή έργου
◦ Ο διοικητής του έργου είναι ο υπεύθυνος για την επικοινωνία με τον
πελάτη και επαναδιαπραγματεύεται τις προθεσμίες ή/και τους
πόρους
9
• Τερματισμός έργου
◦ Το εξαγόμενο του έργου παραδίδεται στον πελάτη
◦ Η εμπλοκή των περισσότερων μελών της ομάδας ανάπτυξης έχει
ολοκληρωθεί αρκετά πριν από αυτή τη φάση
◦ Λίγα «σημαίνοντα» μέλη της ομάδας ανάπτυξης, οι συγγραφείς
τεχνικών κειμένων και οι επικεφαλείς των ομάδων «πακετάρουν» το
σύστημα για να παραδοθεί στον πελάτη, να εγκατασταθεί και να
γίνουν οι έλεγχοι αποδοχής
◦ Συλλέγεται επίσης το ιστορικό του έργου για μελλοντική αναφορά
και για καταγραφή της εμπειρίας.
10
Επισκόπηση της επικοινωνίας στο έργο

(1/2)
• Λαμβάνει χώρα μέσα από προγραμματισμένα συμβάντα
◦ Στόχος: η διάχυση της πληροφορίας που είναι απαραίτητη στους
συμμετέχοντες
◦ Εξέταση προβλήματος - συλλέγονται πληροφορίες για τη διατύπωση
του προβλήματος, τον πελάτη, τους χρήστες και τις απαιτήσεις
◦ Τακτικές συναντήσεις – επιθεωρείται η πρόοδος
◦ Συναντήσεις μελών ομάδων – εντοπισμός προβλημάτων και εύρεση
λύσεων για τα προκαταρκτικά προϊόντα εργασίας
◦ Επιθεωρήσεις πελάτη ή έργου – οι πελάτες ή τα μέλη του έργου
επιθεωρούν την ποιότητα των προϊόντων εργασίας, ιδίως των
παραδοτέων
◦ Εκδόσεις – η ομάδα έργου καθιστά διαθέσιμη στον πελάτη και τους
χρήστες εκδόσεις του συστήματος και σχετική τεκμηρίωση
11
Επισκόπηση της επικοινωνίας στο
έργο (2/2)
• και μη προγραμματισμένα συμβάντα
◦ Στόχος: η αντιμετώπιση προβλημάτων και αναγκών
πληροφορίας που δεν είχαν προβλεφθεί
◦ Αιτήματα διευκρίνισης – ζητούνται συγκεκριμένες
πληροφορίες για το σύστημα, το έργο ή το πεδίο της
εφαρμογής
◦ Αιτήματα αλλαγής – περιγράφονται προβλήματα στο
σύστημα ή νέα χαρακτηριστικά για ενσωμάτωση
◦ Επίλυση ζητημάτων – όταν παρατηρείται διαφωνία
εξετάζονται οι πιθανές λύσεις και επιλέγεται ο τρόπος
επίλυσης του ζητήματος
12
Οργάνωση έργου
• Η οργάνωση έργου ορίζει τη σχέση ανάμεσα σε
πόρους και ειδικότερα μεταξύ των συμμετεχόντων σε
ένα έργο
• Η οργάνωση έργου πρέπει να ορίζει:
◦ Ποιος λαμβάνει τις αποφάσεις (δομή αποφάσεων)
◦ Ποιοι αναφέρουν την κατάστασή τους σε ποιον (δομή
αναφορών)
◦ Ποιοι επικοινωνούν με ποιους (δομή επικοινωνίας)
Οργάνωση * Ομάδα * Συμμετέχων
13
Ενδεικτική οργάνωση του έργου
ΕνδεικτικήΟργάνωση:
Οργάνωση
Διοίκηση: ΔιεπαφήΧρήστη: ΒάσηΔεδομένων: Έλεγχος:

Ομάδα Ομάδα Ομάδα Ομάδα
14
Αλληλεπίδραση στο έργο

• Τρεις κύριοι τύποι:
◦ Αναφορές (reporting): παροχή πληροφορίας για την κατάσταση-πρόοδο
των εργασιών
◦ Π.χ. το API είναι έτοιμο, ο υπεύθυνος ομάδας αναφέρει στον διοικητή έργου
ότι ολοκληρώθηκε κάποια εργασία
◦ Αποφάσεις (decisions): διακίνηση πληροφορίας για αποφάσεις
◦ Π.χ. ο υπεύθυνος ομάδας αποφασίζει ότι ένας προγραμματιστής πρέπει να
συντάξει ένα API, o διοικητήw έργου αποφασίζει τη μετάθεση μιας
προθεσμίας, αποφασίζεται η επίλυση ενός ζητήματος με συγκεκριμένο τρόπο
◦ Επικοινωνία (communication): η διακίνηση κάθε άλλης πληροφορίας
που σχετίζεται με το έργο
◦ Π.χ. η ανταλλαγή απαιτήσεων, μοντέλων, η διαμόρφωση επιχειρημάτων για
υποστήριξη μιας άποψης κ.λπ.
15
Ιεραρχικό μοντέλο αλληλεπίδρασης
Η επικοινωνία εντάσσεται στα «κανάλια» της αναφοράς και

των αποφάσεων. Οι αναφορές πηγαίνουν προς τα επάνω, οι
αποφάσεις προς τα κάτω. Παράδειγμα:
Διοίκηση:
Ομάδα
επικοινωνίαΑπόφασης() επικοινωνίαΑπόφασης()
επικοινωνίαΚατάστασης() επικοινωνίαΚατάστασης()
ΔιεπαφήΧρήστη: ΒάσηΔεδομένων: Έλεγχος:

Ομάδα Ομάδα Ομάδα
• Προβλήματα:
◦ Αναποτελεσματικό για αποφάσεις που πρέπει να λαμβάνονται τοπικά. Δημιουργεί
μεγάλες καθυστερήσεις. Π.χ. οι προγραμματιστές μιας ομάδας συζητούν μεταξύ τους
για ένα θέμα που χρειάζεται πληροφορία από προγραμματιστές σε άλλη ομάδα
◦ Θέματα κακής ερμηνείας των ερωτήσεων και παρανοήσεων.
16
Ιεραρχική επικοινωνία
Γενικός συντονισμός
Διοίκηση 1ου επιπέδου
A B
Μέλη έργου
Ο «Α» θέλει να επικοινωνήσει με τον Β (ροή πληροφορίας)

Ο Α θέλει να διασφαλίσει ότι ο Β θα κάνει μία αλλαγή (ροή ελέγχου)
Τα προβλήματα επικοινωνίας μεταξύ ατόμων σε διαφορετικές

ιεραρχίες είναι προφανή
17
Διαχωρισμός επικοινωνίας από
αναφορές
• Οι αναφορές υποστηρίζουν την παρακολούθηση του
έργου από τη διοίκηση του έργου
◦ Ποιες εργασίες έχουν ολοκληρωθεί;
◦ Ποιες εργασίες έχουν καθυστερήσει;
◦ Ποια ζητήματα «απειλούν» την πρόοδο του έργου;
• Η αναφορές στο δένδρο της ιεραρχίας δεν είναι

κατάλληλες όταν χρειάζεται η επικοινωνία μεταξύ ομάδων
◦ Χρειάζεται μία ξεχωριστή δομή επικοινωνίας
◦ Ένα μέλος κάθε ομάδας είναι υπεύθυνος για να διευκολύνει την
επικοινωνία μεταξύ των ομάδων
◦ Τα μέλη αυτά ονομάζονται σύνδεσμοι
18
Παράδειγμα δομής επικοινωνίας

ΔιεπαφήΧρήστη: Διεπαφή με
Ομάδα Ρόλος άλλη ομάδα
επικοινωνεί
Γιάννης: Διοίκηση: Ομάδα
υπεύθυνος Προγραμματιστής
ομάδας
Πέτρος: Αρχιτεκτονική: Ομάδα
μηχανικός Προγραμματιστής
API
Μαρία: Σχεδιαστής Τεκμηρίωση: Ομάδα
Συντάκτης
Ελένη: επικοινωνεί Έλεγχος: Ομάδα

Προγραμματιστής Προγραμματιστής
Νίκος:
Προγραμματιστής Προγραμματιστής
Η ομάδα έχει πέντε μέλη

19
Ρόλοι
• Ένας ρόλος ορίζει ένα σύνολο από καθήκοντα (“to-dos”)
• Παραδείγματα
• Ρόλος: Ελεγκτής
◦ Συγγραφή ελέγχων
◦ Αναφορά σφαλμάτων / αποτυχιών
◦ Έλεγχος αν οι διορθώσεις σφαλμάτων αντιμετωπίζουν πλήρως μία
αναφορά αποτυχίας
• Ρόλος: Αρχιτέκτονας συστήματος

◦ Διασφάλιση συνέπειας σε σχεδιαστικές αποφάσεις και ορισμός διεπαφών
υποσυστημάτων
◦ Κατάρτιση στρατηγικής ολοκλήρωσης συστήματος
• Ρόλος: Σύνδεσμος
◦ Διευκόλυνση της επικοινωνίας μεταξύ δύο ομάδων
20
Τύποι ρόλων σε οργανώσεις έργων

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

της εφαρμογής
Σύμβουλος Ειδικός στο πεδίο

της λύσης
Πελάτης
Τελικός χρήστης
21
Ανάθεση καθηκόντων
• Τα καθήκοντα ανατίθενται σε ρόλους Ομάδα A .
• Οι ρόλοι ανατίθενται σε πρόσωπα
• Καθήκον 1 Καθήκον 1 Πρόσωπο Α
• Καθήκον 2 Καθήκον 2
Καθήκον 9 Ρόλος 1
• Καθήκον 3
Ρόλος 1 Ρόλος 2
• Καθήκον 4 Ρόλος 2
• Καθήκον 7 Καθήκον 7 Πρόσωπο Β
Ρόλος 3
Καθήκον 3 Ρόλος 3
Καθήκον 6
Καθήκοντα για το έργο
Καθήκον 8
22
Πιθανά σχήματα αναθέσεων

ρόλων σε συμμετέχοντες
• Ένας προς έναν
◦ Ιδεώδες αλλά σπάνιο
• Πολλοί προς έναν
◦ Κάθε μέλος του έργου έχει πολλά «καπέλα»
◦ Κίνδυνος υπερφόρτωσης
◦ Ανάγκη για εξισορρόπηση φόρτου
• Πολλοί προς πολλούς
◦ Μερικοί συμμετέχοντες μπορεί να μην έχουν κάποιο σημαντικό
ρόλο
◦ Απώλεια υπευθυνότητας και δυνατότητας καταλογισμού
ευθυνών
◦ Υποβάθμιση της δυνατότητας διοίκησης του έργου
23
Εργασίες (1/2)
• Μία εργασία (task) περιγράφει τη μικρότερη ποσότητα
εργασίας που ανατίθεται και παρακολουθείται από τη
διοίκηση του έργου
• Τυπικά αντιστοιχεί σε δουλειά 3-10 εργάσιμων ημερών
24
Εργασίες (2/2)
• Περιγραφή εργασίας
◦ Η εργασία ανατίθεται σε κάποιο ρόλο
◦ Η εργασία παράγει ένα συγκεκριμένο προϊόν εργασίας που θα
πρέπει να είναι «απτό» και ελέγξιμο.
◦ Λάθος προϊόν εργασίας: κατανόηση της διαδικασίας δανεισμού
◦ Σωστό προϊόν: έγγραφο περιγραφής της διαδικασίας δανεισμού
◦ Τα προϊόντα μιας εργασίας μπορεί να αποτελούν είσοδο σε άλλες
εργασίες
◦ Αυτά που παραδίδονται στον πελάτη ονομάζονται παραδοτέα
◦ Η εργασία έχει ημερομηνία έναρξης και προγραμματισμένη
διάρκεια
◦ Η εργασία απαιτεί συγκεκριμένους πόρους
◦ Ο συμμετέχων στον οποίο έχει ανατεθεί ο ρόλος εκτελεί την εργασία
και η διοίκηση παρακολουθεί την πρόοδο και την κατανάλωση των
πόρων
25
Παράδειγμα: εργασίες για κτίσιμο ενός σπιτιού
Εγκατάστ. Εγκατάστ. Σοβάτισμα
εσωτ. εσωτ. εσωτ.
σωλήνων ηλεκτρικών τοίχων
Βαφή
εσωτ.
Τοποθ.
πατωμάτων Τοποθ.
εσωτ.
θυρών
Κτίσιμο
Έναρξη Μελέτη Εκσκαφή
ΜελέτηΕκσκαφή Αγορά Τοποθετ.
Αγορά Τοποθετ.Κτίσιμο
εξωτ. εξωτ. Τοποθ. ΤΕΛΟΣ
υλικών θεμελίων
υλικών θεμελίωντοίχων τοίχων οροφής
Τοποθ.
εξωτ.
Αίτηση
θυρών
Αίτηση
άδειας άδειας Βάψιμο εξωτ.
τοίχων
Εγκατάστ. Εγκατάστ. Μόνωση και

εξωτ. εξωτ. σοβάτισμα
σωλήνων ηλεκτρικών εξωτ. τοίχων
26
Παράδειγμα προϊόντων εργασίας

Προϊόντα εργασίας
συστήματος βάσης δεδομένων
μόνιμαΑντικείμενα: Class Model

κώδικας: Source Code
σχεδιαστικάΑντικείμενα: Class Model
σφάλματαΕπιθεώρησης: Document
σχέδιοΕλέγχου: Document
Περιλαμβάνει όλα τα αντικείμενα

που αποθηκεύονται, και που σφάλματαΕλέγχου: Document
πιθανώς να μην περιλαμβάνονται
στα μόνιμαΑντικείμενα
27
Εργασίες και πακέτα εργασιών
• Το ποια δουλειά πρέπει να γίνει σε μία εργασία καθορίζεται
σε ένα πακέτο εργασίας. Στο πακέτο εργασίας
περιλαμβάνεται:
◦ Περιγραφή της δουλειάς που πρέπει να γίνει
◦ Προϋποθέσεις για έναρξη, η διάρκεια, οι απαιτούμενοι πόροι
◦ Τα προϊόντα εργασίας που πρέπει να παραχθούν και τα κριτήρια
αποδοχής τους
◦ Οι ενδεχόμενοι κίνδυνοι (καθυστερήσεις, αλλαγές στις προδιαγραφές,
αλλαγές στην τεχνολογία κ.τ.λ.)
• Μία εργασία πρέπει να έχει κριτήρια ολοκλήρωσης
◦ Περιλαμβάνουν τα κριτήρια αποδοχής των προϊόντων εργασίας που
παράγονται από την εργασία
◦ Ελέγχεται και η συμμόρφωση με τους περιορισμούς (χρονικούς, πόρων
κ.ο.κ.)
28
Μέγεθος εργασιών
• Οι εργασίες αποσυντίθενται σε μεγέθη που να επιτρέπουν την
αποτελεσματική παρακολούθηση
◦ Μπορεί αρχικά να μην είναι προφανές πώς θα αποσυντεθεί σε
εργασίες
◦ Εξαρτάται από τη φύση της εργασίας και πόσο καλά έχει
κατανοηθεί
• Η εύρεση του κατάλληλου μεγέθους είναι ιδιαίτερα σημαντική
◦ Λίστες καθηκόντων από προηγούμενα έργα
◦ Κάθε δραστηριότητα ανάπτυξης λογισμικού ορίζει νέες
δραστηριότητες και τροποποιεί τις ήδη υπάρχουσες
◦ Π.χ. Ορισμός διεπαφής με προσωπική προσαρμογή: ορίζει τις εργασίες
του σχεδιασμού της διεπαφής, του σχεδιασμού της προσωπικής
προσαρμογής και τροποποιεί τη διαδικασία σχεδιασμού της βάσης
δεδομένων
29
Δραστηριότητες
• Αντιστοιχούν σε μείζονες ενότητες εργασίας
• Ολοκληρώνονται σε ορόσημα του έργου
◦ Χρονοπρογραμματισμένα σημεία για τη μέτρηση της προόδου
◦ Τα εσωτερικά σημεία ελέγχου δεν πρέπει να είναι ορατά εξωτερικά
◦ Ένα ορόσημο συνήθως παράγει μία γραμμή βάσης (baseline)
◦ Ένα προϊόν εργασίας που επιθεωρείται τυπικά και για το οποίο εφαρμόζονται
διαδικασίες ελέγχου αλλαγών
◦ Κάθε αλλαγή σε μία γραμμή βάσης απαιτεί την εκτέλεση μιας συμφωνημένης
διαδικασίας
• Οι δραστηριότητες συνήθως ομαδοποιούνται σε υψηλότερου
επιπέδου δραστηριότητες
◦ Π.χ. Φάση 1, φάση 2, ...
• Επιτρέπουν τον διαχωρισμό των ασχολιών
• Μπορούν να εισαχθούν σχέσεις προήγησης μεταξύ των
δραστηριοτήτων
◦ Π.χ.: “Η δ1 πρέπει να εκτελεστεί πριν τη δ2”
30
Παράδειγμα: εργασίες για κτίσιμο σπιτιού

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

εξωτ. εσωτ. σοβάτισμα
σωλήνων καλωδίων εξωτ. τοίχων
31
Παράδειγμα: εργασίες για κτίσιμο σπιτιού
Τοποθ.
εσωτ.
Ολοκλήρωση
Τοποθ.
εσωτ.
Σοβάτισμα
εσωτ.
σωλήνων εσωτερικού
καλωδίων τοίχων
Βαφή
εσωτ.
Τοποθ.
πατωμάτων
Τοποθ.
εσωτ.
Κτίσιμο θυρών
Κτίσιμο
Έναρξη Αγορά
Θεμελίωση
Έναρξη ΜελέτηΕκσκαφή
υλικών
εξωτερικών
Τοποθ.
θεμελίων Εξωτ. Τοποθ.
Τέλος
Τέλος
τοίχωντοίχων οροφής
Τοποθ.
Αίτηση εξωτ.
άδειας Βαφή θυρών
εξωτ.
Τοποθ.
εξωτ.
Ολοκλήρωση
Τοποθ.
εσωτ.
Μόνωση και
σοβάτισμα
σωλήνων εσωτερικού
καλωδίων εξωτ. τοίχων
32
Παραδείγματα δραστηριοτήτων
στην τεχνολογία λογισμικού
• Σχεδιασμός έργου (planning)
• Εκμαίευση απαιτήσεων (requirements elicitation)
• Ανάλυση (analysis)
• Σχεδιασμός συστήματος (system design)
• Σχεδιασμός αντικειμένων (object design)
• Υλοποίηση (implementation)
• Έλεγχος (testing)
• Παράδοση (delivery)
33
Συσχετίσεις μεταξύ έργων, δραστηριοτήτων, ρόλων,
προϊόντων εργασίας και πακέτων εργασίας
περιγράφει έχει αποτέλεσμα

Πακέτο εργασίας Προϊόν εργασίας
* Μονάδα εργασίας
1
Δραστηριότητα Εργασία
* 1 Ρόλος
ανατίθεται σε
34
Παράδειγμα περιγραφής εργασιών

Όνομα Ρόλος που Περιγραφή εργασίας Είσοδος Έξοδος
εργασίας ανατίθεται
Εκμαίευση Αρχιτέκτονας Εκμαίευση απαιτήσεων από Σύνδεσμοι API συστήματος Β.Δ.,
απαιτήσεων συστήματος ομάδες υποσυστημάτων για τις ομάδων μοντέλο ανάλυσης
για Β.Δ. ανάγκες αποθήκευσης. μονίμων αντικειμένων
Περιλαμβάνονται αντικείμενα, (διάγραμμα κλάσεων)
γνωρίσματα και συσχετίσεις
Σχεδιασμός Σχεδιαστής Σχεδιασμός του υποσυστ. API Σχεδιασμός
συστήματος αντικειμένων βάσης δεδομένων, με πιθανή υποσυστήματος υποσυστήματος Β.Δ.
Β.Δ. επιλογή εμπορικού προϊόντος (διάγραμμα κλάσεων)
Υλοποίηση Προγραμματιστής Υλοποιεί το υποσύστημα Β.Δ, Σχεδιασμός Πρωτογενής κώδικας
συστήματος υποσυστήματος
Β.Δ. Β.Δ.
Επιθεώρηση Προγραμματιστής, Επιθεωρείται ο κώδικας του Πρωτογενής Λίστα προβλημάτων
συστήματος ελεγκτής, υποσυστήματος Β.Δ. κώδικας
Β.Δ. σχεδιαστής υποσυστήματος
Σχέδιο Ελεγκτής Ανάπτυξη πακέτου ελέγχου για API Έλεγχοι και σχέδιο
ελέγχου το υποσύστημα Β.Δ. υποσυστήματος, ελέγχου
συστήματος Πρωτογενής
Β.Δ. κώδικας
Έλεγχος Ελεγκτής Εκτελεί το πακέτο ελέγχου για Υποσύστημα, Αποτελέσματα ελέγχων,
συστήματος το υποσύστημα Β.Δ. σχέδιο ελέγχου λίστα προβλημάτων
Β.Δ. 35
Χρονοπρόγραμμα (schedule)
• Το χρονοπρόγραμμα είναι μία απεικόνιση των εργασιών στον χρόνο
◦ Σε κάθε εργασία ανατίθενται χρόνοι έναρξης και ολοκλήρωσης
◦ Με αυτόν τον τρόπο σχεδιάζουμε τις προθεσμίες των παραδοτέων
• Οι δύο συχνότερες διαγραμματικές απεικονίσεις

χρονοπρογραμμάτων είναι τα διαγράμματα PERT και τα
διαγράμματα GANTT
• Στα διαγράμματα GANTT ο οριζόντιος άξονας αντιστοιχεί στον
χρόνο και ο κατακόρυφος στις εργασίες
◦ Κάθε εργασία απεικονίζεται με μία ράβδο, της οποίας το μήκος αντιστοιχεί στη
χρονική της διάρκεια
◦ Οι εργασίες μπορούν να ομαδοποιούνται σε δραστηριότητες ή/και πακέτα
εργασίας
36
Παράδειγμα χρονοπρογράμματος σε
διάγραμμα GANTT
37
Διαγράμματα PERT
• Διάγραμμα PERT (program evaluation review technique): ποιες είναι

οι εξαρτήσεις μεταξύ των δράσεων;
◦ Στόχος να αποτυπωθούν οι δράσεις, οι εξαρτήσεις και οι διάρκειες και να
βρεθεί η κρίσιμη διαδρομή που δίνει τη διάρκεια του έργου
◦ Το διάγραμμα pert του παραδείγματος έχει δύο κρίσιμες διαδρομές, (10  30
 40  50) και (10  20  50) που δίνουν διάρκεια έργου 7 μήνες.
38
Σύνοψη
• Τα έργα είναι συντονισμένες προσπάθειες για την επίτευξη
ενός στόχου που πρέπει να γίνει σε περιορισμένο χρόνο
• Οι συμμετέχοντες στο έργο οργανώνονται σε ομάδες, ρόλους
ενώ υπάρχουν σχέσεις ελέγχου (control relationships) και
σχέσεις επικοινωνίας (communication relationships)
• Ένας συμμετέχων μπορεί να έχει πάνω από έναν ρόλους
• Η δουλειά οργανώνεται σε όρους εργασιών που ανατίθενται σε
ρόλους και παράγουν προϊόντα εργασίας
39
Η επικοινωνία είναι κρίσιμη
• Στα μεγάλα έργα ανάπτυξης, ο χρόνος επικοινωνίας είναι
σημαντικό μέρος του συνολικού χρόνου
• Ένας μηχανικός λογισμικού πρέπει να αποκτήσει τις
επονομαζόμενες «ήπιες δεξιότητες» (soft skills)
◦ Συνεργασία
◦ Διαπραγμάτευση των απαιτήσεων με τον πελάτη και με τα μέλη της
ομάδας (και τα μέλη των άλλων ομάδων)
◦ Παρουσίαση
◦ Παρουσίαση μεγάλων τμημάτων του συστήματος κατά τη διάρκεια
επιθεωρήσεων
◦ Διοίκηση-Διαχείριση
◦ Να προεδρεύσει σε μία συνάντηση ή να ηγηθεί μιας ομάδας
◦ Συγγραφή τεχνικών κειμένων
◦ Συγγραφή τμήματος της τεκμηρίωσης του έργου.
40
Γεγονός επικοινωνίας έναντι

μηχανισμού επικοινωνίας
Γεγονός επικοινωνίας
• Ανταλλαγή πληροφορίας με καθορισμένο στόχο και εμβέλεια
• Χρονοπρογραμματισμένη: Σχεδιασμένη επικοινωνία
◦ Παραδείγματα: εβδομαδιαία συνάντηση ομάδας, επιθεώρηση
• Μη χρονοπρογραμματισμένη: επικοινωνία που καθοδηγείται από
τα γεγονότα
◦ Παραδείγματα: αναφορά προβλήματος, αίτημα για αλλαγή ή
διευκρίνιση
Μηχανισμός επικοινωνίας
• Εργαλείο ή διαδικασία που χρησιμοποιείται για να μεταδοθεί
πληροφορία
• Σύγχρονος: Ο αποστολέας και ο παραλήπτης επικοινωνούν την ίδια
στιγμή
• Ασύγχρονος: Ο αποστολέας και ο παραλήπτης δεν επικοινωνούν
την ίδια στιγμή
41
Μοντελοποίηση επικοινωνίας
Υποστηρίζεται από
Γεγονός Μηχανισμός
επικοινωνίας * * επικοινωνίας
Χρονοπρο- Μη χρονοπρο- Σύγχρονος Ασύγχρονος

γραμματισμένο γραμματισμένο μηχανισμός μηχανισμός
γεγονός γεγονός
42
Σχεδιασμένα γεγονότα επικοινωνίας

• Ορισμός προβλήματος
◦ Στόχος: Παρουσίαση στόχων, απαιτήσεων και
περιορισμών
◦ Παράδειγμα: Παρουσίαση από πλευράς πελάτη
◦ Τυπικά λαμβάνει χώρα στην αρχή ενός έργου
• Επιθεώρηση από πελάτη: Εστίαση στις
απαιτήσεις
◦ Στόχος : Η ενημέρωση του πελάτη και η συμφωνία για τις
αλλαγές στις απαιτήσεις
◦ Δεν πρέπει να εστιάζεται στον σχεδιασμό ή την υλοποίηση, εκτός αν
επηρεάζουν τον πελάτη ή τους χρήστες
◦ Η πρώτη επιθεώρηση πελάτη συνήθως γίνεται μετά τη
φάση της ανάλυσης
43
• Επιθεώρηση έργου: εστίαση στα μοντέλα συστήματος
◦ Στόχος: Εκτίμηση της κατάστασης του έργου και επιθεώρηση του μοντέλου
συστήματος και των διεπαφών των υποσυστημάτων
◦ Επίσης δίνουν τη δυνατότητα ανταλλαγής λειτουργικής γνώσης, όπως
προβλήματα με τα εργαλεία ή το σύστημα
◦ Η εστίαση εξαρτάται από το παραδοτέο που επιθεωρείται:
◦ Σχεδιασμός συστήματος: εξετάζεται η αποσύνθεση σε υποσυστήματα και οι διεπαφές
των υποσυστημάτων
◦ Σχεδιασμός αντικειμένων: εξετάζονται οι διεπαφές των αντικειμένων
◦ Ολοκλήρωση και έλεγχος: εξετάζονται οι έλεγχοι και τα αποτελέσματά τους
◦ Παράδειγμα: Επιθεώρηση ανάλυσης, επιθεώρηση σχεδιασμού
◦ Τυπικά λαμβάνει χώρα κοντά στα ορόσημα και στα παραδοτέα του έργου
44

Επιθεωρήσεις κώδικα και περιηγήσεις (επιθεωρήσεις
ομοτίμων)
◦ Στόχος: Να αυξηθεί η ποιότητα ενός προϊόντος
◦ Στην περιήγηση (μη τυπική) ο προγραμματιστής παρουσιάζει
τον κώδικά του γραμμή προς γραμμή στα άλλα μέλη της ομάδας
◦ Τα άλλα μέλη εστιάζουν στα «ύποπτα» σημεία του κώδικα και
επιχειρούν να εντοπίσουν όσο το δυνατόν περισσότερα σφάλματα
◦ Ο προγραμματιστής κατευθύνει τη συζήτηση και απαντά σε ερωτήσεις
των άλλων μελών της ομάδας
◦ Εστίαση σε προκαθορισμένα κριτήρια (υλοποιείται ο αλγόριθμος που
έχει αποφασιστεί; Χρησιμοποιούνται σωστά οι διεπαφές;)
◦ Χρονοπρογραμματίζεται από κάθε ομάδα
◦ Στην επιθεώρηση (τυπική) μία ομάδα από ειδικούς επιθεωρεί
το προϊόν εργασίας
◦ Συνήθως επιθεωρούνται προϊόντα όπως οι προδιαγραφές απαιτήσεων
λογισμικού και τα σχέδια ελέγχου
◦ Χρονοπρογραμματίζεται από τη διοίκηση του έργου
45
Επιθεώρηση κατάστασης
◦ Στόχος: Εύρεση & διόρθωση αποκλίσεων από τον
χρονοπρογραμματισμό ή ανάδειξη νέων ζητημάτων
◦ Η εστίαση είναι σε εργασίες (σε αντίθεση με την επιθεώρηση
έργου που εστιάζει στο σύστημα)
◦ Επίσης συζητούνται ανοικτά ζητήματα και προβλήματα που
ανέκυψαν
◦ Οι λύσεις σε κοινά προβλήματα γίνονται κτήμα όλων και η
λειτουργική γνώση διαχέεται πιο αποτελεσματικά σε επίπεδο
ομάδας, παρά σε επίπεδο έργου
◦ Πρέπει να διαμορφώνεται ατζέντα για να προετοιμάζονται οι
συμμετέχοντες και πρέπει να τηρούνται πρακτικά (οπωσδήποτε
περιλαμβάνοντας την αναφορά κατάστασης και τις αποφάσεις)
◦ Παράδειγμα
◦ Ενότητα «κατάσταση» στις εβδομαδιαίες συναντήσεις της
ομάδας
46
Σχεδιασμένα γεγονότα
επικοινωνίας
«Νοητικός καταιγισμός» (Brainstorming)
◦ Στόχος: Να δημιουργηθεί και να αξιολογηθεί ένα μεγάλο
πλήθος λύσεων («λογικών» αλλά και «απίθανων») για
ένα πρόβλημα
◦ Συνήθως με παρουσία όλων των συμμετεχόντων, αλλά
είναι δυνατό να γίνει και με άλλους τρόπους, π.χ. e-mail
◦ Η αξιολόγηση βοηθάει στο να διαμορφωθούν σαφή
κριτήρια αξιολόγησης των λύσεων και την επίτευξη
συναίνεσης στην επιλεχθείσα λύση
◦ Παράδειγμα
◦ Ενότητα «συζήτηση» στις εβδομαδιαίες συναντήσεις της ομάδας
47
Διάθεση (release)
◦ Στόχος: Να καταστεί διαθέσιμο κάποιο προϊόν εργασίας σε άλλους
συμμετέχοντες (μερικές φορές αντικαθιστά παλαιότερη έκδοση)
◦ Μπορεί να περιλαμβάνει τη (νέα) έκδοση του προϊόντος, μία λίστα
από ανοικτά ζητήματα που πρέπει ακόμη να διευθετηθούν,
τεκμηρίωση κ.λπ.
◦ Ο μηχανισμός χρησιμοποιείται για να διατίθενται μεγάλες
ποσότητες πληροφορίας με ελεγχόμενο τρόπο ομαδοποιώντας,
τεκμηριώνοντας και επιθεωρώντας πολλές αλλαγές ταυτόχρονα
◦ Συνηθέστατα των επιθεωρήσεων έργου και πελάτη προηγείται μία
διάθεση
◦ Χρονοπρογραμματίζεται έτσι μετά τη σχετική δραστηριότητα (ή
“φάση”)
◦ Παραδείγματα:
◦ Σχέδιο διοίκησης έργου λογισμικού, έγγραφο ανάλυσης απαιτήσεων,
έγγραφο σχεδιασμού συστήματος, “beta” έκδοση λογισμικού, τελική
έκδοση λογισμικού, εγχειρίδιο χρήστη
48
Σχεδιασμένα γεγονότα
«Νεκροψία» (Postmortem Review)
◦ Στόχος: Να καταγραφούν οι εμπειρίες από το έργο,
θετικές και αρνητικές
◦ Γίνεται μετά το τέλος του έργου, αλλά σύντομα για
να είναι νωπές οι μνήμες
◦ Μπορεί να διενεργείται με ερωτηματολόγιο, νοητικό
καταιγισμό ή αναφορές
◦ Περιλαμβάνει εργαλεία, μεθόδους, οργάνωση,
διαδικασίες
◦ Προτιμότερο να καταγράφονται τα αποτελέσματα σε
τεχνική έκθεση
49
Μη σχεδιασμένα γεγονότα
Αίτημα για διευκρίνιση
◦ Περιλαμβάνει επικοινωνία ανάμεσα σε
προγραμματιστές, πελάτες και χρήστες
◦ Παράδειγμα: Λέμε ότι τα προαπαιτούμενα μεταξύ
εξαμήνων του ίδιου έτους δεν εφαρμόζονται: πρέπει
να καταχωρούνται στο σύστημα ή όχι;
50
Μη σχεδιασμένα γεγονότα
Αίτημα αλλαγής
◦ Ένας συμμετέχων αναφέρει ένα πρόβλημα και (πιθανώς να)
προτείνει λύση
◦ Αν το μέγεθος του έργου είναι μεγάλο, μπορεί οι αιτήσεις
αλλαγής να τυποποιούνται
◦ Παράδειγμα: Διόρθωση υπολογισμού βαθμού πτυχίου
Αναφορά: 1291 Ημερομηνία: 5/12 Συντάκτης: Νίκος
Σύνοψη: Ο βαθμός πτυχίου δεν υπολογίζεται σωστά
Υποσύστημα: Διαχείριση φοιτητών
Έκδοση: 3.4.1
Κατηγορία: Σφάλμα
Σοβαρότητα: σημαντικό
Προτεινόμενη λύση: πρέπει να εφαρμόζεται ο τρόπος υπολογισμού στη σελίδα 3
του οδηγού σπουδών
51
Μη σχεδιασμένα γεγονότα επικοινωνίας
Επίλυση ζητήματος
◦ Επιλέγεται μία λύση για ένα ζήτημα όπου έχουν προταθεί
πολλές λύσεις
◦ Από το αποθετήριο ανοικτών ζητημάτων ανακτώνται τα ανοικτά
ζητήματα και οι προτάσεις
Ζήτημα[0]: Ποια πολιτική πρέπει να εφαρμοστεί για την προσκόμιση γνωρισμάτων από
τη βάση δεδομένων;
– Πρόταση[1]: Κατ’ απαίτηση ανά γνώρισμα
Κατά[2]: κακή απόδοση
Υπέρ[3]: απλούστερο
– Πρόταση[4]: κατ’ απαίτηση ανά αντικείμενο (να προσκομίζονται προκαταβολικά
όλα τα γνωρίσματα)
Υπέρ[5]: καλύτερη απόδοση. Στη διαχείριση φοιτητών, μαθημάτων, βαθμολογίων
χρειάζονται συνήθως όλα τα γνωρίσματα (πρβλ. πρακτικά συνάντησης 3/12)
– Επίλυση[6]: Να υλοποιηθεί η Πρόταση[4]. Η κρυφή μνήμη πρέπει να μείνει στο
επίπεδο της Β.Δ. ώστε η πολιτική προσκόμισης να μην είναι ορατή εκτός του API.
Αν αποτύχει αυτή η επιλογή, υλοποιούμε την Πρόταση[1].
– Ενέργεια: για: Νίκο: Τροποποίησε την πολιτική προσκόμισης χωρίς να αλλάξει το
API 52
Σύγχρονοι τρόποι επικοινωνίας

• Συζήτηση στους διαδρόμους
◦ Υποστηρίζει: Μη σχεδιασμένόυς διαλόγους, αιτήσεις για
διευκρίνιση, αιτήσεις για αλλαγή
+ Μικρή δαπάνη χρόνου και αποτελεσματικό για να επιλύονται
απλά ζητήματα
– Απώλεια πληροφορίας, συχνές παρανοήσεις
53
Σύγχρονοι τρόποι επικοινωνίας
• Σύσκεψη (άμεση, τηλεφωνική, βιντεοδιάσκεψη)
◦ Υποστηρίζει: Σχεδιασμένους διαλόγους, επιθεώρηση
πελάτη, επιθεώρηση κατάστασης, νοητικό καταιγισμό,
επίλυση ζητημάτων
◦ Υπάρχει ατζέντα, συντονιστής, πρακτικογράφος, υπεύθυνος
τήρησης χρόνου
◦ Η ατζέντα πρέπει να περιγράφει σαφώς τα ζητήματα που θα
συζητηθούν:
+ «Επίλυση ζητημάτων με τις απαιτήσεις που εμποδίζουν την
έναρξη της ανάπτυξης», «τρόπος χειρισμού δεδομένων
εξόδου»
- «επίλυση ανοικτών ζητημάτων», «ζητήματα υλοποίησης»
+Αποτελεσματική για επίλυση ζητημάτων και διαμόρφωση
συναίνεσης
– Υψηλό κόστος (άνθρωποι, πόροι), χαμηλό «εύρος ζώνης»
54
Ασύγχρονοι τρόποι επικοινωνίας

• E-Mail
◦ Υποστηρίζει: διάθεση, αίτημα αλλαγής, νοητικό καταιγισμό
+ Ιδεώδες για μη προγραμματισμένη επικοινωνία και ανακοινώσεις
– Χωρίς τα συμφραζόμενά του μπορεί να παρανοηθεί, να σταλεί
στον λάθος άνθρωπο ή να χαθεί
• Ομάδα νέων (Newsgroup)
◦ Υποστηρίζει: διάθεση, αίτημα αλλαγής, νοητικό καταιγισμό
+ Κατάλληλο για συζητήσεις μεταξύ ατόμων με κοινά ενδιαφέροντα.
Φθηνό (διαθέσιμο ανοικτό λογισμικό)
– «Πρωτόγονος» έλεγχος πρόσβασης (συμμετέχεις ή δεν
συμμετέχεις)
• Δικτυακή πύλη (portal)
◦ Υποστηρίζει: διάθεση, αίτημα αλλαγής, επιθεωρήσεις
+ Παροχή στους χρήστες της μεταφοράς του υπερκειμένου
(έγγραφα-συνδέσεις)
– Δεν υποστηρίζει αποτελεσματικά τα συχνά μεταβαλλόμενα
έγγραφα
55
Μηχανισμοί για σχεδιασμένα γεγονότα
Ορισμός Επιθεώρηση Αναφορά Επιθεώρηση- Διάθεση
προβλήματος- έργου-πελάτη κατάστασης περιήγηση
Νοητικός
καταιγισμός
Συζήτηση
στους  
διαδρόμους
Σύσκεψη
   
Ηλ.
ταχυδρομείο
Ομάδα νέων
(newsgroup) 
WWW
(δικτυακή  
πύλη)
56
Μηχανισμοί για μη σχεδιασμένα γεγονότα

Αίτημα Αίτημα αλλαγής Επίλυση
διευκρίνισης ζητήματος
Συζήτηση στους
διαδρόμους  
Σύσκεψη
 
Ηλ. ταχυδρομείο
 
Ομάδα νέων
(newsgroup)  
WWW (δικτυακή
πύλη) 
57
Δραστηριότητες επικοινωνίας
• Τυπικές δραστηριότητες επικοινωνίας σε ένα
έργο λογισμικού
◦ Κατανόηση διατύπωσης προβλήματος
◦ Ένταξη σε ομάδα
◦ Προγραμματισμός και συμμετοχή σε συσκέψεις
κατάστασης ομάδας
◦ Ένταξη στη «δομή επικοινωνίας»
58
Κατανόηση της διατύπωσης του

προβλήματος
• Η διατύπωση του προβλήματος γίνεται από τον
πελάτη
◦ Καλείται επίσης διατύπωση εμβέλειας
• Η διατύπωση του προβλήματος περιγράφει:
◦ Την τρέχουσα κατάσταση
◦ Τη λειτουργικότητα που πρέπει να υποστηρίζει το
νέο σύστημα
◦ Το περιβάλλον στο οποίο θα λειτουργεί το νέο
σύστημα
◦ Τα παραδοτέα που περιμένει ο πελάτης
◦ Τις ημερομηνίες παράδοσης
◦ Τα κριτήρια για τον έλεγχο αποδοχής
59
Ένταξη σε ομάδα
• Κατά τη φάση του ορισμού έργου, ο διοικητής του έργου
δημιουργεί μία ομάδα για κάθε υποσύστημα
• Μπορεί να δημιουργηθούν και πρόσθετες «διαθεματικές»
ομάδες (περιλαμβάνουν άτομα από διαφορετικά τμήματα
μέσα στον οργανισμό, π.χ. διαχείριση ανθρώπινων πόρων,
μηχανικοί, πωλήσεις, εμπορική προώθηση κ.λπ.) για να
υποστηρίξουν τις ομάδες των υποσυστημάτων
• Κάθε ομάδα έχει έναν επικεφαλής
• Άλλοι ρόλοι μπορεί να είναι:
◦ Διαχειριστής διαμόρφωσης
◦ Σύνδεσμος για θέματα API
◦ Συγγραφέας τεχνικών κειμένων
◦ Διαχειριστής ιστοχώρου
• Πρέπει να καθορίζονται σαφών τα καθήκοντα της ομάδας και
κάθε μέλους για να διασφαλίζεται η επιτυχία της ομάδας
60
Συμμετοχή σε συσκέψεις κατάστασης

ομάδας
• Οι τακτικές συναντήσεις ομάδων (εβδομαδιαίες,
ημερήσιες κ.τ.λ.) είναι ιδιαίτερα σημαντικό μέρος ενός
έργου λογισμικού
• Μερικές φορές θεωρούνται ως «χαμένος χρόνος»
• Ο επικεφαλής της ομάδας έχει πολύ σημαντικό ρόλο:
◦ «Εκπαιδεύει» τα μέλη της ομάδας στη διαχείριση συσκέψεων
◦ Διαμορφώνει και ανακοινώνει την ατζέντα
◦ Μεριμνά για την τήρηση πρακτικών
◦ Να παρακολουθεί την πρόοδο των ενεργειών που έχουν ανατεθεί
◦ Να αναδείξει τη χρησιμότητα των συσκέψεων της ομάδας
◦ Να αναδείξει την εξοικονόμηση στον χρόνο
61
Ένταξη στη «δομή επικοινωνίας»
• Μία καλή δομή επικοινωνίας είναι εξαιρετικά σημαντική για
κάθε έργο λογισμικού
◦ διαδικτυακή πύλη, e-mail, ομάδες νέων, εξειδικευμένο λογισμικό
• Θα πρέπει να μάθουν οι συμμετέχοντες να χρησιμοποιούν
τον κατάλληλο μηχανισμό για την κάθε κατάσταση
◦ Η «καταλληλότητα» μπορεί να εξαρτάται από την «εταιρική
κουλτούρα»
• Θα πρέπει να «εγγραφεί» ο κάθε συμμετέχων σε όλους τους
σχετικούς μηχανισμούς που πρέπει να μετέχει
◦ Ενεργοποίηση λογαριασμού, εκπαίδευση
• Ερωτήσεις που πρέπει να απαντηθούν:
◦ Χρονοπρογραμματίζονται οι συσκέψεις σε λογισμικό ημερολογίου;
◦ Διαθέτει το έργο ένα σύστημα αναφοράς προβλημάτων;
◦ Εκτελούν τα μέλη της ομάδας «επιθεωρήσεις ομοτίμων» στις
συσκέψεις ή σε γραπτή μορφή;
62
Οργάνωση
ανατίθεται σε
Ομάδα
*
*
υπεύθυνος για
Συμμετέχων
* 1
Ρόλος
*
Εργασία παράγει Προϊόν εργασίας
1 *
* 1 *
Χρονοπρόγραμμα
απεικονίζεται σε
1
Επικοινωνία
εμφανίζεται σε
Σχεδιασμένο γεγονός Μη σχεδιασμένο γεγονός αφορά
* *
Διατύπωση Αίτημα για
προβλήματος διευκρίνιση
Επιθεώρηση Αίτημα αλλαγής
Επίλυση
Διάθεση ζητήματος
63
Σύνοψη
• Γεγονότα επικοινωνίας
◦ Σχεδιασμένα (καθορισμένα στο χρονοπρόγραμμα)
◦ Μη σχεδιασμένα (καθοδηγούμενα από μη προβλεπόμενα
συμβάντα)
• Μηχανισμοί επικοινωνίας
◦ Ασύγχρονοι
◦ Σύγχρονοι
• Σημαντικά γεγονότα και μηχανισμοί σε ένα έργο

◦ Εβδομαδιαία συνάντηση
◦ Επιθεωρήσεις έργου
◦ Online μηχανισμοί επικοινωνίας:
◦ Φόρουμ συζήτησης, email, διαδίκτυο (portal, wikis)
64

ENGINEERING)
Διατύπωση προβλήματος
1
Περιεχόμενα
• Διατύπωση προβλήματος
• Λειτουργικές προδιαγραφές
• Μη λειτουργικές προδιαγραφές
• Διεπαφή χρήστη
• Μοντέλο αντικειμένων
• Αποσύνθεση συστήματος
• Θέση σε λειτουργία
Διατύπωση προβλήματος
• Η διατύπωση προβλήματος αναπτύσσεται από
τον πελάτη ως μία περιγραφή του προβλήματος
που θα αντιμετωπίσει το σύστημα
• Η διατύπωση προβλήματος περιγράφει
◦ Την τρέχουσα κατάσταση
◦ Τους στόχους
◦ Τη λειτουργικότητα που πρέπει να υποστηρίζει το
◦ Το περιβάλλον εντός του οποίου θα λειτουργήσει το
◦ Παραδοτέα που αναμένονται από τον πελάτη
◦ Ημερομηνίες παράδοσης των παραδοτέων
◦ Ένα σύνολο κριτηρίων αποδοχής
3
Τρέχουσα κατάσταση – το
πρόβλημα προς αντιμετώπιση
• Υπάρχει ένα πρόβλημα στην τρέχουσα κατάσταση.
◦ Παραδείγματα:
◦ Σε ένα παιχνίδι σκάκι η απόκριση είναι αργή.
◦ Στο διαδικτυακό τάβλι δεν βρίσκω αντιπάλους του επιπέδου μου
• Τι έχει αλλάξει; Γιατί μπορούμε να αντιμετωπίσουμε το
πρόβλημα τώρα;
◦ Αλλαγή στο πεδίο της εφαρμογής
◦ Διότι έχει εισαχθεί μία νέα επιχειρηματική διαδικασία στον οργανισμό
◦ Π.χ. Θέλουμε να παίζουμε διαδραστικά παιχνίδια με απομακρυσμένους συμπαίκτες
◦ Αλλαγή στο πεδίο της λύσης
◦ Έχει εμφανιστεί μία νέα λύση (υποστηρικτική τεχνολογία)
◦ Π.χ. Το διαδίκτυο επιτρέπει τη δημιουργία εικονικών κοινοτήτων
Παράδειγμα – Τρέχουσα κατάσταση για

ARENA (διαδικτυακή πλατφόρμα παιχνιδιών)
• Το διαδίκτυο έχει καταστήσει δυνατές τις εικονικές κοινότητες
◦ Με σύντομη ή μεγαλύτερη διάρκεια ζωής (π.χ. μέλη ενός chat room
παιχνιδιού έναντι μελών μιας λίστας αλληλογραφίας)
• Τα παιχνίδια υπολογιστών για πολλούς παίκτες υποστηρίζουν
πλέον τις εικονικές κοινότητες
◦ Οι παίκτες μπορούν να λαμβάνουν νέα για αναβαθμίσεις, νέα
επίπεδα, ανακοινώσεις για αγώνες και σκορ
• Αυτή τη στιγμή κάθε εταιρεία παιχνιδιών αναπτύσσει
υποστήριξη για εικονικές κοινότητες σε κάθε παιγνίδι
ξεχωριστά
◦ Κάθε εταιρεία χρησιμοποιεί διαφορετική υποδομή, διαφορετικές
έννοιες και παρέχει διαφορετικό επίπεδο υποστήρικης
• Η κατάσταση αυτή οδηγεί σε προβλήματα
◦ Οι χρήστες πρέπει να μάθουν κάθε σύστημα υποστήριξης
ξεχωριστά
◦ Οι εταιρείες παιχνιδιών αναπτύσσουν σύστημα & υποστήριξη
εξαρχής
◦ Οι διαφημιστές πρέπει να επικοινωνήσουν με κάθε ομάδα
ξεχωριστά
5
ARENA: Οι στόχοι
• Παροχή μιας γενικής υποδομής για:
◦ Υποστήριξη εικονικών κοινοτήτων παιχνιδιών
◦ Εγγραφή νέων παιχνιδιών
◦ Εγγραφή νέων παικτών
◦ Οργάνωση τουρνουά
◦ Καταγραφή των σκορ των παικτών
• Παροχή ενός πλαισίου εργασίας για τους διοργανωτές
τουρνουά
◦ Να μπορούν να προσαρμόζουν το πλήθος και τη σειρά των
παιχνιδιών και τη συλλογή «βαθμών εμπειρίας-κατάταξης»
• Παροχή ενός πλαισίου εργασίας για όσους
αναπτύσσουν παιχνίδια
◦ Για ανάπτυξη νέων παιχνιδιών ή για την προσαρμογή
υπαρχόντων παιχνιδιών στο πλαίσιο του ARENA
• Παροχή ενός πλαισίου εργασίας για τους διαφημιστές
ARENA – λειτουργικές προδιαγραφές

• Υποστηρίζονται πέντε τύποι χρηστών:
◦ Οι χειριστές πρέπει να μπορούν να ορίζουν νέους τύπους παιχνιδιών (π.χ.
τουρνουά με αποκλεισμό, πρωταθλήματα, όμιλοι), να ορίζουν νέους
τρόπους βαθμολόγησης εμπειρίας και να διαχειρίζονται τους χρήστες
◦ Οι διοργανωτές τουρνουά, πρέπει να μπορούν να ορίζουν «ομοσπονδίες»
(π.χ. «ομοσπονδία τάβλι») να διοργανώνουν τουρνουά εντός των
ομοσπονδιών («κύπελλο στις πόρτες», «πρωτάθλημα σε όλα τα παιχνίδια»
κ.λπ.), να διεξάγουν ένα τουρνουά και να ανακηρύσσουν τον νικητή
◦ Οι παίκτες πρέπει να μπορούν να γράφονται στην πλατφόρμα, να
εγγράφονται σε ομοσπονδία, να παίζουν τα παιχνίδια που έχουν
προγραμματιστεί και να εγκαταλείπουν ένα τουρνουά
◦ Οι θεατές πρέπει να μπορούν να παρακολουθούν αγώνες και να βλέπουν
αποτελέσματα και στατιστικά παλαιών αγώνων και παικτών. Οι θεατές δεν
γράφονται στην πλατφόρμα.
◦ Οι διαφημιστές πρέπει να μπορούν να «ανεβάζουν» νέες διαφημίσεις, να
επιλέγουν τύπο διαφήμισης (π.χ. χορηγός τουρνουά), να ελέγχουν τα
οικονομικά τους και να ακυρώνουν διαφημίσεις
7
ARENA: μη λειτουργικές
προδιαγραφές
• Το σύστημα πρέπει να υποστηρίζει
◦ 10 παράλληλα τουρνουά
◦ με κάθε ένα να περιλαμβάνει έως 64 παίκτες
◦ και αρκετές εκατοντάδες θεατές
◦ Ο εξυπηρέτης πρέπει να είναι διαθέσιμος σε 24ωρη βάση
• Ο χειριστής πρέπει να έχει τη δυνατότητα να προσθέτει νέα
παιχνίδια (και άλλα χαρακτηριστικά) προσθέτοντας απλώς
συνιστώσες (π.χ. κλάσεις Java) και ενδεχομένως επανεκκινώντας το
σύστημα αλλά χωρίς να τροποποιεί το υπάρχον σύστημα
• Το σύστημα πρέπει να έχει χαμηλές απαιτήσεις εύρους ζώνης –
πρέπει να είναι δυνατή η συμμετοχή στα παιχνίδια με 60kbps ή
περισσότερο (υποστήριξη GPRS)
• Το σύστημα πρέπει να έχει χαμηλό κόστος λειτουργίας – να μη
χρειάζεται αγορά πρόσθετου λογισμικού και να μην απαιτείται η
συμμετοχή εξειδικευμένου τεχνικού προσωπικού
• Περιορισμός: Κάθε περιορισμός που τίθεται από τον
πελάτη στο πεδίο λύσης ή στην οργάνωση του έργου
◦ Καλούνται και ψευδο-απαιτήσεις
• Παραδείγματα
◦ Περιορισμοί παράδοσης (“πρέπει να παραδοθεί πριν τις
31/10”)
◦ Περιορισμοί οργάνωσης (“πρέπει να δημιουργηθεί ξεχωριστή
ομάδα ελέγχου”)
◦ Περιορισμοί υλοποίησης (“πρέπει να γραφεί σε Java”)
◦ Περιορισμοί πλατφόρμας-στόχου (“πρέπει να τρέχει σε
Android, Windows και Linux”)
9
ARENA: Περιβάλλον-στόχος
Παράδειγμα:
• Οι χρήστες πρέπει να μπορούν να εκτελούν το ARENA ως
applet μέσα σε ένα πρόγραμμα πλοήγησης
• Η ιστοσελίδα πρέπει να επικυρώνεται ως απόλυτα σωστή
από την υπηρεσία W3C Markup Validation Service
• Η διάδραση με τον εξυπηρέτη ARENA πρέπει να γίνεται
αποκλειστικά με αιτήσεις/αποκρίσεις HTTP/1.1
Το περιβάλλον-στόχος είναι διαφορετικό από το περιβάλλον
ανάπτυξης
• «Η γλώσσα υλοποίησης πρέπει να είναι η Java 1.5»
• “Οι δοκιμές θα γίνονται σε IE, Firefox, Chrome”
• “Η πλατφόρμα ανάπτυξης θα είναι to Eclipse 3.7”
10
Χρονοπρόγραμμα έργου
• Το χρονοπρόγραμμα έργου είναι προαιρετικό τμήμα της
διατύπωσης του προβλήματος
◦ Διαχειριστική πληροφορία
◦ Συχνά αποτελεί το πρωτόλειο για το χρονοπρόγραμμα που θα
δημιουργηθεί στον σχεδιασμό διαχείρισης έργου λογισμικού
• Περιλαμβάνει μόνο μείζονα ορόσημα που συζητούνται

με τον πελάτη
◦ 3 έως 4 ημερομηνίες (καθορισμένες)
◦ Έναρξη έργου 15 Ιανουαρίου
◦ Επιθεώρηση συστήματος 22 Φεβρουαρίου
◦ Επιθεώρηση πρώτου πρωτοτύπου 26 Απριλίου
◦ Δοκιμές αποδοχής πελάτη 15 Ιουνίου
11
Κριτήρια αποδοχής πελάτη
• Το σύστημα υποστηρίζει 10 παράλληλα
τουρνουά με 64 παίκτες και 10 θεατές ανά
τουρνουά
• Οι δοκιμές θα γίνουν με τα παιχνίδια «τρίλιζα»
και «Asteroids»
• Ο μέσος χρόνος απόκρισης για εντολές που
δίνονται από τους εξυπηρετούμενους
(υπολογιστές παικτών-θεατών) θα είναι < 1 sec
• Κατά τη μία εβδομάδα δοκιμών, ο μέσος χρόνος
διαθεσιμότητας του εξυπηρέτη θα είναι > 95%
12
(Αρχικά) μοντέλα συστήματος

ARENA
• Αποσύνθεση σε υποσυστήματα
• Διεπαφή χρήστη στον εξυπηρετούμενο
• Διεπαφή χρήστη στον εξυπηρέτη
• Μοντέλο αντικειμένων
13
Αποσύνθεση σε υποσυστήματα
Διεπαφή χρήστη
Τουρνουά Διαχείριση
Διαφήμιση
χρηστών
Διαχείριση
συνιστωσών Κατάλογος
χρηστών
Στατιστικά
Διαχείριση τουρνουά
συνόδων
14
Μοντέλο αντικειμένων συστήματος

ARENA
Παιχνίδι
ΕίδοςΤουρνουά
Ομοσπονδία
Τουρνουά ΜεΑποκλεισμό
ΌλοιΜεΌλους
Γύρος
Παίκτης Παιχνίδι
15
Εκλέπτυνση του μοντέλου
Παιχνίδι
Τρίλιζα
Ομοσπονδία ΕίδοςΤουρνουά
Asteroids
Τουρνουά ΜεΑποκλεισμό
ΌλοιΜεΌλους
Γύρος
Παίκτης Κίνηση
Παιχνίδι
Έλεγχοςπαιχνιδιού creates Έλεγχοςπαιχνιδιού

Factory 16
Διάγραμμα στιγμιοτύπων
συστήματος AREMA
17
Διεπαφή χρήστη στο ARENA
(εξυπηρετούμενος)
18
Διεπαφή χρήστη στο ARENA

(εξυπηρέτης)
19
ENGINEERING)
Εκμαίευση απαιτήσεων
Τι είναι η εκμαίευση απαιτήσεων

• Επικοινωνία μεταξύ ομάδας ανάπτυξης, πελατών και
χρηστών για να οριστεί ένα νέο σύστημα
• Εξαιρετικά σημαντικό στάδιο καθώς η αποτυχία θα
οδηγήσει σε σύστημα που δεν θα υποστηρίζει σωστά την
εργασία των χρηστών
◦ Κοινά σφάλματα λογισμικού λόγω λαθών στη διαδικασία
εκμαίευσης απαιτήσεων: λείπει λειτουργικότητα, λανθασμένη
υλοποίηση λειτουργικότητας, δύσχρηστες ή ατελείς διεπαφές
χρήστη, παρωχημένη λειτουργικότητα
◦ Τα σφάλματα στην εκμαίευση των απαιτήσεων, αν δεν γίνουν
έγκαιρα αντιληπτά, διορθώνονται πολύ δύσκολα ή/και με μεγάλο
κόστος
• Ο στόχος είναι να βελτιωθεί η επικοινωνία μεταξύ

πελατών, χρηστών και ομάδας ανάπτυξης
2
Γενικό πλαίσιο
• Η ομάδα ανάπτυξης δημιουργεί ένα μοντέλο που
είναι κατανοητό από πελάτες και χρήστες, π.χ.
σενάρια ή περιπτώσεις χρήσης
◦ Πηγές για τη δημιουργία του μοντέλου: ερωτηματολόγια,
παρατήρηση, κανονισμοί κ.λπ.
• Η ομάδα ανάπτυξης επιβεβαιώνει το μοντέλο με:
◦ επιθεώρηση από τον πελάτη όσο και
◦ δημιουργία απλών πρωτότυπων της διεπαφής χρήστη,
τα οποία δίνονται στους πελάτες-χρήστες για δοκιμή και
σχολιασμό
Τοποθέτηση μέσα στον κύκλο

ζωής λογισμικού
• ... με τα σχετικά μοντέλα
Εκμαίευση Σχεδιασμός Λεπτομερής Υλοποί-
Ανάλυση Έλεγχος
απαιτήσεων συστήματος σχεδιασμός ηση
Υλοποιείται από
Εκφράζεται με Δομείται σε Απεικονίζεται
όρους Επαληθεύεται
σε από
class...
class... ?
class... ?
class....
Μοντέλο Αντικείμενα Αντικείμενα
περιπτώσεων πεδίου Υποσυ- πεδίου λύσης Πρωτογενής Μοντέλο
εφαρμογής στήματα κώδικα περιπτώσεων
χρήσης
ελέγχου
4
Χειρισμός απαιτήσεων:
προσδιορισμός συστήματος (1/2)
• Πρέπει να απαντηθούν δύο ερωτήσεις:
1. Πώς μπορούμε να προσδιορίσουμε τον σκοπό του
συστήματος;
◦ Ποιες είναι οι απαιτήσεις και ποιοι οι περιορισμοί;
2. Τι βρίσκεται εντός και τι εκτός του συστήματος;
◦ Τα αντικείμενα και διαδικασίες που θα αναδειχθούν στη
συνέχεια και τα όρια του συστήματος είναι ισχυρά αλληλένδετα
• Οι δύο αυτές ερωτήσεις απαντώνται κατά την εκμαίευση και
ανάλυση των απαιτήσεων.
• Εκμαίευση απαιτήσεων:
◦ Ορισμός του συστήματος με όρους που είναι κατανοητοί από τον
πελάτη ή/και τον χρήστη (παράγεται η “προδιαγραφή απαιτήσεων”)
Χειρισμός απαιτήσεων:
προσδιορισμός συστήματος (2/2)
• Ανάλυση απαιτήσεων:
◦ Ορισμός του συστήματος σε όρους που είναι κατανοητοί από την
ομάδα ανάπτυξης (τεχνικές προδιαγραφές, “μοντέλο ανάλυσης”)
◦ «Προδιαγραφή απαιτήσεων» & «Μοντέλο ανάλυσης» είναι η ίδια
πληροφορία ΑΛΛΑ με το (1) αναπαρίσταται σε φυσική γλώσσα και
στοχεύει στην επικοινωνία ομάδας ανάπτυξης-χρηστών ενώ το (2)
αναπαρίσταται με (ήμι-) τυπικό τρόπο και στοχεύει στην επικοινωνία
μελών ομάδας ανάπτυξης
• Διαδικασία απαιτήσεων: Περιλαμβάνει την εκμαίευση και την
ανάλυση των απαιτήσεων
6
Διαδικασία απαιτήσεων
Διατύπωση
Εκμαίευση απαιτήσεων Προδιαγραφή απαιτήσεων
: μη λειτουργικές
: λειτουργικό μοντέλο
Ανάλυση Μοντέλο ανάλυσης
: δυναμικό μοντέλο
Διάγραμμα
δραστηριότητας : μοντέλο αντικειμένων
UML ανάλυσης
7
Τι είναι απαιτήσεις και τι όχι;

• Μόνο ό,τι ανήκει στην οπτική γωνία του χρήστη
• Είναι απαιτήσεις
◦ Η λειτουργικότητα του συστήματος
◦ Η αλληλεπίδραση χρήστη-συστήματος
◦ Τα σφάλματα που μπορεί να ανιχνεύσει και να χειριστεί
το σύστημα
• ΔΕΝ είναι απαιτήσεις
◦ Η τεχνολογία με την οποία θα κατασκευαστεί το σύστημα
◦ Η μεθοδολογία διοίκησης του έργου
◦ Οτιδήποτε άλλο δεν είναι άμεσα ορατό από τον χρήστη
του συστήματος
8
Βασικές δραστηριότητες στην
εκμαίευση απαιτήσεων (1)
• Προσδιορισμός actors
◦ Προσδιορίζονται οι τύπου των χρηστών που θα υποστηρίζει το
σύστημα
• Προσδιορισμός σεναρίων
◦ η ομάδα ανάπτυξης δημιουργεί ένα σύνολο λεπτομερών σεναρίων
για την τυπική λειτουργικότητα που θα παρέχεται από το σύστημα
◦ Πρόκειται για συγκεκριμένα παραδείγματα χρήσης του συστήματος
◦ Αποτελούν ένα μέσο επικοινωνίας της ομάδας ανάπτυξης με τους
χρήστες ώστε η ομάδα να κατανοήσει καλύτερα το πεδίο εφαρμογής
• Προσδιορισμός περιπτώσεων χρήσης
◦ Από τα σενάρια εξάγονται οι περιπτώσεις χρήσης που αναπαριστούν
πλήρως το σύστημα
◦ Σε αντίθεση με τα σενάρια που περιγράφουν μόνο παραδείγματα χρήσης
◦ Οι περιπτώσεις χρήσης ορίζουν την εμβέλεια του συστήματος
Βασικές δραστηριότητες στην

εκμαίευση απαιτήσεων (2)
• Εκλέπτυνση περιπτώσεων χρήσης
◦ Η ομάδα ανάπτυξης διασφαλίζει ότι η προδιαγραφή των
απαιτήσεων είναι πλήρης, αναπτύσσοντας λεπτομερώς τις
περιπτώσεις χρήσης και περιγράφοντας το πώς το σύστημα θα
λειτουργήσει υπό την παρουσία σφαλμάτων και ειδικών συνθηκών
• Προσδιορισμός συσχετίσεων μεταξύ περιπτώσεων χρήσης
◦ Η ομάδα ανάπτυξης εντοπίζει εξαρτήσεις μεταξύ των περιπτώσεων
χρήσης (η Α είναι γενικότερη της Β, η Α προϋποθέτει τη Β κ.ο.κ.)
◦ Επίσης αναγνωρίζεται κοινή λειτουργικότητα μεταξύ περιπτώσεων
χρήσης και εξάγεται σε βοηθητικές περιπτώσεις χρήσης
◦ Με τον τρόπο αυτό προάγεται η συνέπεια του μοντέλου
• Προσδιορισμός μη λειτουργικών απαιτήσεων
◦ Η ομάδα ανάπτυξης, οι χρήστες και ο πελάτης συμφωνούν σε
ζητήματα που είναι ορατά στους χρήστες αλλά δεν είναι
λειτουργικότητα
◦ Π.χ. επιδόσεις, τεκμηρίωση, ασφάλεια, ποιότητα, κατανάλωση πόρων
10
Έννοιες εκμαίευσης απαιτήσεων (1)
• Λειτουργικές απαιτήσεις
◦ Περιγράφουν την αλληλεπίδραση του συστήματος με το
περιβάλλον του, ανεξάρτητα από την υλοποίησή του
◦ Περιβάλλον: χρήστες και άλλα συστήματα με τα οποία
αλληλεπιδρά το υπό ανάπτυξη σύστημα
◦ Π.χ. Ένα σύστημα πλοήγησης αλληλεπιδρά με τους δορυφόρους
GPS, τον χρήστη και με το σύστημα ενημέρωσης λογισμικού της
εταιρείας κατασκευής (για να λάβει νέους χάρτες ή αλγόριθμους
δρομολόγησης)
11

• Μη λειτουργικές απαιτήσεις [1]
◦ Περιλαμβάνουν ένα μεγάλο πλήθος από ποικίλα είδη
απαιτήσεων που αφορούν διάφορες απόψεις του
◦ Ενδεικτικές κατηγορίες:
◦ Χρηστικότητα: η ευκολία με την οποία οι χρήστες μπορούν να
μάθουν τη χρήση, να προετοιμάζουν είσοδο για το σύστημα (ή
μιας συνιστώσας του) ή να ερμηνεύουν τις εξόδους του
◦ Περιλαμβάνει τη βοήθεια άμεσης πρόσβασης, την τεκμηρίωση,
συμβάσεις στη διεπαφή κ.ο.κ.
◦ Πολλές φορές απαιτείται να ακολουθηθούν κατευθυντήριες γραμμές
ανάπτυξης της διεπαφής
12
•Μη λειτουργικές απαιτήσεις [2]
◦ Αξιοπιστία: η ικανότητα του συστήματος να εκτελεί τις
απαιτούμενες λειτουργίες υπό δοθείσες συνθήκες για κάποιο
διάστημα.
◦ Παραδείγματα: Μέσος χρόνος μέχρι να σημειωθεί βλάβη, η
ικανότητα ανίχνευσης συγκεκριμένων σφαλμάτων, η αντοχή σε
επιθέσεις.
◦ Απόδοση: αφορά μετρήσιμα χαρακτηριστικά του συστήματος,
όπως ο χρόνος απόκρισης, η ρυθμαπόδοση, η διαθεσιμότητα
13

◦ Υποστηριξιμότητα: η ευχέρεια πραγματοποίησης αλλαγών στο
σύστημα μετά τη θέση σε λειτουργία. Περιλαμβάνει:
◦ Δυνατότητα προσαρμογής: αλλαγή του συστήματος για να
ενσωματώσει πρόσθετες έννοιες του πεδίου εφαρμογής
◦ Συντηρισιμότητα: αλλαγή για ενσωμάτωση νέας τεχνολογίας ή
διόρθωση σφαλμάτων
◦ Διεθνοποίηση: υποστήριξη γλωσσών, μονάδων μέτρησης,
μορφών αριθμών κ.λπ.
◦ Μεταφερσιμότητα: η ευκολία λειτουργίας του λογισμικού σε
διαφορετικά περιβάλλοντα υλικού και λογισμικού
14
◦ Λοιπές κατηγορίες:
◦ Απαιτήσεις υλοποίησης: περιορισμοί χρήσης συγκεκριμένων
εργαλείων, γλωσσών προγραμματισμού, πλατφορμών υλικού κ.ο.κ.
◦ Απαιτήσεις διεπαφής: τίθενται από εξωτερικά συστήματα,
περιλαμβάνοντας «παλαιά» συστήματα και μορφότυπους διεπαφής
◦ Απαιτήσεις λειτουργικού περιβάλλοντος: περιορισμοί στη διαχείριση
και τον χειρισμό του συστήματος στην παραγωγική του λειτουργία
◦ Απαιτήσεις «πακέτου παράδοσης»: περιορισμοί αναφορικά με την
παράδοση του συστήματος, π.χ. σε ποιο μέσο θα παραδοθεί το
λογισμικό (CD/DVD/USB stick κ.ο.κ.)
◦ Νομικές απαιτήσεις: τίθενται από το νομικό πλαίσιο, π.χ. η διεπαφή
των συστημάτων λογισμικού του δημοσίου πρέπει να είναι στα
Ελληνικά. Επίσης αδειοδότηση (GPL κ.λπ.)
15

• Πληρότητα, συνέπεια, σαφήνεια και ορθότητα (1)
◦ Οι απαιτήσεις επικυρώνονται διαρκώς ως προς τα χαρακτηριστικά
αυτά από τον πελάτη και τον χρήστη
◦ Η επικύρωση είναι κρίσιμη, για να αποφευχθούν προβλήματα στη
συνέχεια
◦ Η προδιαγραφή απαιτήσεων είναι:
◦ Πλήρης όταν ΟΛΑ τα πιθανά σενάρια έχουν περιγραφεί,
συμπεριλαμβανομένων των λιγότερο συνηθισμένων ροών
◦ Συνεπής όταν δεν περιέχει αντιφάσεις (π.χ. υπάρχουν δύο
διαφορετικά σενάρια για την ίδια λειτουργία)
◦ Σαφής όταν η ερμηνεία της είναι μονοσήμαντη
◦ Ορθή αν αναπαριστά το σύστημα που πραγματικά χρειάζεται ο
πελάτης
16
• Πληρότητα, συνέπεια, σαφήνεια και ορθότητα (2)
• Παραδείγματα:
◦ Μη πλήρης προδιαγραφές: Μετά από αίτησή του ένας φοιτητής
μπορεί να αναστείλει τη φοίτησή του.
◦ Δεν υπάρχει όμως προδιαγραφή που να λέει πώς μπορεί να αρθεί η
αναστολή!
◦ Ασυνεπείς προδιαγραφές: Η πηγή προδιαγραφών 1 αναφέρει ότι αν
ένας φοιτητής αποτύχει 3 φορές σε ένα μάθημα, εξετάζεται από
επιτροπή. Η πηγή 2 αναφέρει ότι ένας φοιτητής εξετάζεται
απεριόριστο πλήθος φορών στο μάθημα.
◦ Ασαφής προδιαγραφή: Το σύστημα θα υποστηρίζει προθεσμίες
παράδοσης της ηλεκτρονικής αλληλογραφίας
◦ Τι σημαίνει το «υποστηρίζει»; Γράφουμε «να παραδοθεί μέχρι τότε»; Το
σύστημα τι κάνει για να τηρήσει τις προθεσμίες; κ.λπ.
◦ Λάθος προδιαγραφή: Σημειώνεται αν ο φοιτητής έχει εισαχθεί στο
τμήμα με πανελλήνιες ή κατατακτήριες εξετάσεις.
◦ Μεταγραφές; Ειδικές κατηγορίες (π.χ. Ολυμπιονίκες);
17

• Ρεαλισμός, επαληθευσιμότητα και ιχνηλατησιμότητα
απαιτήσεων [1]
◦ Ρεαλισμός: το σύστημα μπορεί να υλοποιηθεί με τους δοθέντες
περιορισμούς
◦ Μη ρεαλιστική προδιαγραφή: Το βίντεο να έχει καθυστέρηση μικρότερη
από 10 msec σε όλες τις περιπτώσεις (Αθήνα – Νέα Υόρκη: 7919.99 χλμ.)
◦ Επαληθευσιμότητα: μετά την κατασκευή του συστήματος είναι
δυνατόν με ελέγχους που έχουν τη δυνατότητα επανάληψης
(repeatable) να διαπιστώσουμε αν το σύστημα πληροί τις
προδιαγραφές
◦ Μη επαληθεύσιμες προδιαγραφές: «καλή διεπαφή χρήστη» (ασαφής),
«το λογισμικό δεν πρέπει να έχει σφάλματα» (αν μπορεί να αποδειχθεί
χρειάζεται τεράστιους πόρους)
18
• Ρεαλισμός, επαληθευσιμότητα και ιχνηλατησιμότητα
απαιτήσεων [2]
◦ Ιχνηλατησιμότητα: πρέπει να μπορεί να βρεθεί η διαδρομή μεταξύ
κάθε προδιαγραφής και των αντίστοιχων λειτουργιών του
συστήματος και αντίστροφα
◦ Επίσης να μπορεί να βρεθεί η συσχέτιση μεταξύ προδιαγραφών,
λειτουργιών του συστήματος και ενδιάμεσων σχεδιαστικών αντικειμένων
όπως συνιστώσες του συστήματος, κλάσεις, μεθόδους και γνωρίσματα
αντικειμένων.
◦ Η ιχνηλατησιμότητα είναι πολύ σημαντική για να ελέγχουμε τις αλλαγές
και να δημιουργούμε πλαίσια ελέγχου του λογισμικού
19

• Σχεδιασμός εξ αρχής (greenfield engineering), ανασχεδιασμός
(reengineering) και σχεδιασμός διεπαφών (interface engineering)
◦ Στον σχεδιασμό εξ αρχής δεν υπάρχει προηγούμενο σύστημα, οπότε όλες οι
προδιαγραφές συλλέγονται από τους χρήστες και τον πελάτη
◦ Ο ανασχεδιασμός αφορά στον εκ νέου σχεδιασμό και υλοποίηση ενός
υπάρχοντος συστήματος, είτε γιατί έχουν αλλάξει οι επιχειρηματικές
διαδικασίες είτε γιατί έχουν εμφανιστεί νέες τεχνολογίες.
◦ Ο στόχος του συστήματος παραμένει ίδιος, συνεπώς μεγάλο τμήμα των
προδιαγραφών μπορεί να εξαχθεί από το υπάρχον σύστημα
◦ Στον σχεδιασμό διεπαφών ανασχεδιάζουμε τις διεπαφές (προς ανθρώπους ή
συστήματα) ενός υπάρχοντος συστήματος
◦ Που δεν θέλουμε να το πετάξουμε γιατί είναι δαπανηρό
◦ Ο τύπος του σχεδιασμού επηρεάζει τις δραστηριότητες εκμαίευσης
απαιτήσεων
◦ Ειδικά στον σχεδιασμό εξ αρχής και στον ανασχεδιασμό πρέπει να συλλεχθεί όσο
το δυνατόν περισσότερη πληροφορία για το πεδίο της εφαρμογής
20
Δραστηριότητες εκμαίευσης
• Προσδιορισμός actors
• Προσδιορισμός σεναρίων
• Προσδιορισμός περιπτώσεων χρήσης
• Εκλέπτυνση περιπτώσεων χρήσης
• Προσδιορισμός συσχετίσεων μεταξύ περιπτώσεων χρήσης
• Προσδιορισμός μη λειτουργικών απαιτήσεων
21
Προσδιορισμός actors
• Το πρώτο βήμα στην εκμαίευση απαιτήσεων
• Δίνει τη δυνατότητα:
◦ να καθοριστούν τα όρια του συστήματος
◦ να αναδειχθούν όλες οι οπτικές γωνίες που πρέπει να ληφθούν υπ’
όψιν στην ανάπτυξη του συστήματος
• Οι περισσότεροι actors προϋπάρχουν της ανάπτυξης του
◦ Αντιστοιχούν σε ρόλους στον οργανισμό
• Στην αρχή μπορεί να μην είναι εμφανές αν κάτι είναι actor
ή αντικείμενο
◦ Π.χ. Στο σύστημα της γραμματείας η βάση δεδομένων πτυχιακών
εργασιών είναι actor ή αντικείμενο;
◦ Αν είναι εντός της εμβέλειας του συστήματος, είναι αντικείμενο,
ειδάλλως είναι actor
22
Βασικές ερωτήσεις για
προσδιορισμό actors
• Ποιες ομάδες χρηστών υποστηρίζονται από το σύστημα για κατά την
εκτέλεση των εργασιών τους;
• Ποιες ομάδες χρηστών εκτελούν τις βασικές λειτουργίες του
• Ποιες ομάδες χρηστών εκτελούν δευτερεύουσες λειτουργίες, όπως
συντήρηση και διαχείριση;
• Ποιά είναι τα εξωτερικά λογισμικά και υλικά με τα οποία αλληλεπιδρά
το σύστημα;
• Οι ομάδες χρηστών μπορεί να συμπτύσσονται σε μία γενικότερη όταν
έχουν κοινή προοπτική στο σύστημα
◦ Π.χ. ο «διδάσκων» και ο «βοηθός διδασκαλίας» στο e-class δεν
διαφοροποιούνται ως προς τις λειτουργίες που εκτελούν
• Το επόμενο βήμα είναι να προσδιοριστεί η λειτουργικότητα που είναι
διαθέσιμη σε κάθε ομάδα χρηστών
◦ Διαθέσιμα εργαλεία: ερωτηματολόγια, παρατήρηση, σενάρια και τυπικά
διατυπωμένες περιπτώσεις χρήσης
23
Τεχνικές για την εκμαίευση των

• Προσπαθούν να γεφυρώσουν το χάσμα εννοιών
μεταξύ πελάτη/χρήστη και ομάδας ανάπτυξης:
◦ Ερωτηματολόγια: Υποβάλλεται στους χρήστες μία
σειρά από προεπιλεγμένες ερωτήσεις
◦ Ανάλυση εργασιών: Παρατήρηση των χρηστών στο
λειτουργικό τους περιβάλλον
◦ Σενάρια: Περιγράφεται η χρήση του συστήματος με
τη μορφή συγκεκριμένων διαδράσεων μεταξύ ενός
συγκεκριμένου χρήστη και του συστήματος
◦ Περιπτώσεις χρήσης: Αφαιρέσεις που περιγράφουν
μία κατηγορία σεναρίων
24
Σενάρια (1/2)
• Μία περιγραφή ενός γεγονότος ή μιας σειράς ενεργειών και
γεγονότων που περιλαμβάνουν τη χρήση του συστήματος
• Πρόκειται για περιγραφή σε μορφή κειμένου
◦ Πιθανώς ο χρήστης να το εκφράζει προφορικά και να καταγράφεται
στη συνέχεια
◦ Απεικονίζει την οπτική γωνία του χρήστη
• Μπορεί να περιλαμβάνει κοινωνικές πτυχές (σχέσεις με πελάτες-

συναδέλφους), πόρους (χρόνος εκτέλεσης, χώρος στον δίσκο),
περιορισμούς και άλλες «πληροφορίες υπόβαθρου» (π.χ.
κανονισμούς του οργανισμού ή πρακτικές που ακολουθούνται)
25
Σενάρια (2/2)
• Μπορεί να περιγράφει είτε τρέχουσα χρήση ή σχεδιαζόμενη χρήση
• Μπορεί να περιλαμβάνει κείμενο, γραφικά, βίντεο, «πινάκια
εξιστόρησης» (storyboards) κ.τ.λ.
• Με την περιγραφή αυτή μπορεί να αποτυπωθεί περισσότερη
πληροφορία για τους στόχους του χρήστη και το περιβάλλον εντός
του οποίου εργάζεται ο χρήστης
26
Είδη σεναρίων
• Σενάριο αποτύπωσης (As-is scenario):
◦ Περιγράφει μία τρέχουσα κατάσταση.
◦ Συνήθως χρησιμοποιείται σε έργα αναθεώρησης
λογισμικού (re-engineering)
◦ Ο χρήστης περιγράφει το σύστημα
• Σενάριο προοπτικής:
◦ Περιγράφει ένα μελλοντικό σύστημα
◦ Παράδειγμα: διαδικτυακή πλατφόρμα για on-line παιχνίδια
◦ Χρησιμοποιείται στην ανάπτυξη νέων συστημάτων
(greenfield engineering) και σε έργα ανάπτυξης
διεπαφών (interface engineering projects)
◦ Συνήθως συνεργάζονται ο πελάτης και η ομάδα
ανάπτυξης
27
Πρόσθετοι τύποι σεναρίων

• Σενάριο αξιολόγησης
◦ Περιγραφή μιας εργασίας χρήστη η οποία θα
χρησιμοποιηθεί για την αξιολόγηση του συστήματος
◦ Παράδειγμα: Τέσσερις χρήστες (δύο αρχάριοι και δύο έμπειροι)
παίζουν ένα παιχνίδι τρίλιζας στη διαδικτυακή πλατφόρμα
• Σενάριο εκπαίδευσης:
◦ Βήμα προς βήμα οδηγίες για να καθοδηγήσουν έναν
αρχάριο χρήστη στο σύστημα
◦ Παράδειγμα: Πώς να παίξετε ένα παιχνίδι τρίλιζας στη διαδικτυακή
πλατφόρμα
28
Παρατηρήσεις για τα σενάρια
• Τα σενάρια δεν υποκαθιστούν τις περιπτώσεις χρήσης
◦ Εστιάζουν σε συγκεκριμένα στιγμιότυπα και γεγονότα σε
αντιδιαστολή με γενικές περιγραφές που καλύπτουν όλες τις
δυνατές ροές γεγονότων
• Είναι ένα καλό εργαλείο για την εκμαίευση των

απαιτήσεων καθώς είναι πλήρως κατανοητό από χρήστες
και πελάτες
• Δεν περιγράφουν αποφάσεις και εναλλακτικές ροές
γεγονότων
◦ Εάν κάτι τέτοιο είναι επιθυμητό πρέπει να δημιουργηθούν
πολλαπλά σενάρια, ένα για την απόφαση Α, ένα για τη Β κ.ο.κ.
29
Παράδειγμα σεναρίου
Όνομα σεναρίου: ΦωτιάΣεΑποθήκη
Συμμετέχοντα Γιάννης, Μαρία: Διασώστες

στιγμιότυπα actors: Πέτρος: Συντονιστής
Ροή γεγονότων: O Γιάννης οδηγώντας το περιπολικό του παρατηρεί να βγαίνει
καπνός από μία αποθήκη. Η συνοδηγός του Μαρία αναφέρει
το θέμα από τον ασύρματό της.
Η Μαρία εισάγει τη διεύθυνση του κτηρίου στον υπολογιστή
παλάμης της, μία σύντομη περιγραφή της τοποθεσίας (π.χ.
απέναντι από το πάρκο) και ένα επίπεδο συναγερμού.
Επιβεβαιώνει τα στοιχεία και περιμένει την επιβεβαίωση.
Ο Πέτρος ειδοποιείται για το περιστατικό μέσω ηχητικού
σήματος από τον υπολογιστή του. Εξετάζει τις πληροφορίες
που δόθηκαν από τη Μαρία και επιβεβαιώνει τη λήψη της
αναφοράς. Στέλνει ένα πυροσβεστικό όχημα και αποστέλλει
τον εκτιμώμενο χρόνο άφιξης (ΕΧΑ) στη Μαρία.
Η Μαρία λαμβάνει την επιβεβαίωση και τον ΕΧΑ.
30
Ανάδειξη σεναρίων
• Αν το σύστημα δεν υπάρχει, ο πελάτης πιθανότατα δεν
θα δώσει αυθόρμητα πολλές πληροφορίες
◦ Οι πελάτες κατανοούν το χώρο του προβλήματος, όχι αυτόν της
λύσης!
• ... το ίδιο μάλλον θα συμβεί και αν το σύστημα υπάρχει
◦ “Μα είναι προφανές, γιατί να το πω;”
• Χρησιμοποιούμε διαλογική τεχνική
◦ Προσπαθούμε να βοηθήσουμε τον πελάτη να σχηματοποιήσει
τις απαιτήσεις
◦ Και ο πελάτης με τη σειρά του θα μας βοηθήσει να τις
κατανοήσουμε
◦ Οι απαιτήσεις εξελίσσονται ενόσω γίνεται η ανάπτυξη των
σεναρίων.
31
Ερωτήσεις για την ανάδειξη

σεναρίων
• Ποιες είναι οι εργασίες που επιθυμεί ο actor να
εκτελέσει το σύστημα;
• Ποιες πληροφορίες θέλει να προσπελάσει ο actor;
Ποιός τις δημιουργεί; Μπορούν να
τροποποιηθούν ή να διαγραφούν και από ποιόν;
• Για ποιες εξωτερικές αλλαγές πρέπει ο actor να
ενημερώσει το σύστημα; Πόσο συχνά; Πότε;
• Για ποια γεγονότα πρέπει το σύστημα να
ενημερώσει τον actor; Με ποια καθυστέρηση;
32
Απαντήσεις στις ερωτήσεις
• Η ομάδα ανάπτυξης μελετά υπάρχοντα έγγραφα για το πεδίο
εφαρμογής
◦ Εγχειρίδια του προηγούμενου συστήματος, εγχειρίδια διαδικασιών,
στάνταρ του οργανισμού κ.λπ.
◦ Επίσης συνεντεύξεις χρηστών και πελατών
• Τα σενάρια γράφονται με την ορολογία του πεδίου εφαρμογής

(χρηστών/πελατών) όχι αυτή της ομάδας ανάπτυξης
• Τα σενάρια εμπλουτίζονται με λεπτομέρειες καθώς η ομάδα
ανάπτυξης κατανοεί το πεδίο της εφαρμογής και τις δυνατότητες της
τεχνολογίας
• Η δημιουργία ψευδοπρωτοτύπων («mock ups») της διεπαφής του
χρήστη βοηθά στον εντοπισμό παραλείψεων στην προδιαγραφή και
στη δημιουργία μιας πιο σαφούς εικόνας του συστήματος
33
Προσδιορισμός περιπτώσεων
χρήσης
• Ένα σενάριο είναι ένα συγκεκριμένο στιγμιότυπο μιας περίπτωσης
χρήσης
• Μία περίπτωση χρήσης εκκινείται από έναν actor
◦ Μετά την εκκίνησή της, μία περίπτωση χρήσης μπορεί να αλληλεπιδρά και
με άλλους actors
• Η περίπτωση χρήσης αναπαριστά μία πλήρη ροή γεγονότων μέσα από

το σύστημα
◦ Μία ακολουθία σχετιζόμενων διαδράσεων που λαμβάνουν χώρα ως
αποτέλεσμα της εκκίνησής της
• Οι περιπτώσεις χρήσης εντοπίζονται με γενίκευση των σεναρίων και

επιτρέπουν τον καθορισμό της εμβέλειας του συστήματος
• Η αντιστοίχιση του actor ενεργοποίησης με την περίπτωση χρήσης
συχνά οδηγεί σε εντοπισμό actors που είχαν παραβλεφθεί
34
Περιγραφή περίπτωσης χρήσης
(1)
• Έξι βασικά στοιχεία:
◦ Συνθήκες εισόδου και εξόδου που περιγράφουν τις συνθήκες κάτω
από τις οποίες ενεργοποιείται η περίπτωση χρήσης και το
αποτέλεσμα που έχει στο σύστημα
◦ Αυτές μπορεί να βοηθήσουν στον προσδιορισμό περιπτώσεων χρήσης
που λείπουν
◦ Π.χ. αν η περίπτωση χρήσης «Ανακήρυξη πτυχιούχου» απαιτεί να έχει
υποβληθεί αίτηση περάτωσης σπουδών, πρέπει να υπάρχει περίπτωση
χρήσης που να αφορά την υποβολή αυτής της αίτησης
◦ Ροή γεγονότων η οποία επιτρέπει στους πελάτες και τους χρήστες να
συζητήσουν την αλληλεπίδραση συστήματος-χρηστών
◦ Καθορίζονται όρια του συστήματος, με λήψη αποφάσεων του τι κάνει το
σύστημα και του τι κάνουν οι actors
◦ Π.χ. στην ανακήρυξη πτυχιούχου, τον έλεγχο αν έχουν περαστεί τα
απαιτούμενα μαθήματα και τον υπολογισμό του βαθμού τον κάνει το
σύστημα ή η γραμματέας;
35
Περιγραφή περίπτωσης χρήσης

(2)
• Εναλλακτικές ροές συμβάντων
◦ Για χειρισμό εξαιρέσεων και μη συνήθων συνθηκών
• Απαιτήσεις ποιότητας οι οποίες επιτρέπουν την
εξαγωγή μη λειτουργικών απαιτήσεων για τη
συγκεκριμένη λειτουργικότητα
36
Προσδιορισμός συνθηκών
εισόδου
• Τι πρέπει να ισχύει για να εκτελεστεί η περίπτωση
χρήσης
◦ Παραλείπουμε τα απολύτως προφανή
◦ Το σύστημα πρέπει να είναι εγκατεστημένο
◦ Δεν πρέπει να υπονοούμε βασική λειτουργικότητα
◦ Παράδειγμα: ο πελάτης πρέπει να υπάρχει στο σύστημα
◦ Όπου υπάρχει άλλη περίπτωση χρήσης που δημιουργεί τον πελάτη
37
Προσδιορισμός συνθηκών εξόδου

• Ποιο είναι το επιθυμητό αποτέλεσμα της
περίπτωσης χρήσης
◦ Περιλαμβάνεται η κατάσταση του συστήματος
◦ Αλλαγές δεδομένων
◦ Αλλαγές σε οποιαδήποτε αντικείμενα
◦ Μερικές συνθήκες εξόδου είναι συνθήκες εισόδου για
άλλες περιπτώσεις χρήσης
38
Απλοί κανόνες συγγραφής
περιπτώσεων χρήσης (1)
• Οι περιπτώσεις χρήσης πρέπει να ονομάζονται με
ρηματικές προτάσεις (να περιέχουν ρήμα) π.χ. «Ανάφερε
περιστατικό», «Κατάθεσε χρήματα»
• Οι actors πρέπει να ονομάζονται με ονοματικές φράσεις
(να μην περιέχουν ρήμα) π.χ. «Πελάτης»,
«ΠρόεδροςΣυμβουλίου»
• Τα όρια του συστήματος πρέπει να είναι σαφή. Τα βήματα
που εκτελούνται από τον actor και τα βήματα που
εκτελούνται από το σύστημα πρέπει να διακρίνονται
σαφώς.
◦ Ένας εύκολος εποπτικός τρόπος είναι να στοιχίζονται δεξιά τα
βήματα που εκτελούνται από το σύστημα
39

• Τα βήματα στη ροή των γεγονότων πρέπει να
διατυπώνονται σε ενεργητική φωνή
◦ Καθίσταται σαφές ποιος εκτελεί το βήμα.
• Η σχέση αιτίου-αιτιατού μεταξύ διαδοχικών βημάτων

πρέπει να είναι σαφής
• Μία περίπτωση χρήσης πρέπει να περιγράφει τη
δοσοληψία στο σύνολό της
• Οι εξαιρέσεις καταγράφονται ξεχωριστά
40
• Η περίπτωση χρήσης ΔΕΝ ΑΣΧΟΛΕΙΤΑΙ με τη διεπαφή
χρήστη – κάτι τέτοιο θα αποσπάσει την προσοχή της
ομάδας, του πελάτη ή/και του χρήστη από την περιγραφή
των βημάτων και θα τη στρέψει στο αν τα κουμπιά, μενού
κ.λπ. είναι κατάλληλα
◦ Η διεπαφή αντιμετωπίζεται ξεχωριστά, π.χ. με ψευδοπρωτότυπα
• Μία περίπτωση χρήσης δεν πρέπει να ξεπερνά τις 3

σελίδες
◦ Δυσχεραίνεται η κατανόησή της από τον πελάτη-χρήστη και η
επιβεβαίωσή της
◦ Μεγάλες περιπτώσεις χρήσης αποσυντίθενται σε μικρότερες με
χρήση των σχέσεων includes και extends
41

• Σχετικά με τις συνθήκες εισόδου & εξόδου
◦ Οι χρήστες πρέπει να μπορούν να επαληθεύσουν ότι
ικανοποιούνται οι συνθήκες εισόδου
◦ Π.χ. Το «η μεταβλητή Χ έχει τιμή 1» δεν είναι κατάλληλη συνθήκη
εισόδου
◦ Όλες οι συνθήκες εισόδου πρέπει να είναι αληθείς για να εκκινηθεί
η περίπτωση χρήσης
◦ Ωστόσο η περίπτωση χρήσης εκκινείται από τον actor (ή κάποιο συμβάν)
◦ Οι συνθήκες εισόδου αφορούν τόσο στην κανονική όσο και στις
εναλλακτικές ροές
◦ Οι συνθήκες εξόδου αφορούν στην επιτυχή ολοκλήρωση της
◦ Οι στόχοι της περίπτωσης χρήσης πρέπει επίσης να μπορούν να επαληθευθούν
◦ Αν οι εναλλακτικές ροές οδηγούν το σύστημα σε διαφορετική κατάσταση,
μπορούμε να γράψουμε γι’ αυτές ξεχωριστές συνθήκες εξόδου
42
«Προβληματική» περιγραφή περίπτωσης
χρήσης
Όνομα περίπτωσης Ατύχημα κακή επιλογή ονόματος – ποιος είναι ο στόχος του
χρήσης: χρήστη;
Εκκινών actor: Διασώστης
Ροή γεγονότων: 1. Ο διασώστης αναφέρει το ατύχημα

2. Αποστέλλεται ένα ασθενοφόρο α) παθητική φωνή –
ποιος αποστέλλει το ασθενοφόρο β) απουσία σχέσης
αιτίου-αιτιατού: ποια ενέργεια είναι αυτή που οδηγεί στην
αποστολή ασθενοφόρου;
3. Ο συντονιστής ειδοποιείται όταν το ασθενοφόρο φθάνει
στον τόπο του περιστατικού α) παθητική φωνή – ποιος
ειδοποιεί τον συντονιστή β) ημιτελής δοσοληψία: τι κάνει ο
διασώστης αφού έχει αποσταλεί το ασθενοφόρο;
43
Ορθή περιγραφή περίπτωσης χρήσης

Όνομα περίπτωσης Ανάφερε Περιστατικό
χρήσης:
Συμμετέχοντες actors: Διασώστης. Επικοινωνεί με τον συντονιστή
Ροή γεγονότων: 1. Ο διασώστης ενεργοποιεί τη λειτουργία «Αναφορά

περιστατικού» στον υπολογιστή του
2. Το σύστημα παρουσιάζει μία φόρμα
(για εισαγωγή των στοιχείων)
3. Ο διασώστης συμπληρώνει τη φόρμα, εισάγοντας επίπεδο
συναγερμού, τύπο περιστατικού, θέση, σύντομη περιγραφή και
ενδεχομένως κατάλληλους τρόπους αντιμετώπισης. Ο διασώστης
υποβάλλει τη φόρμα.
4. Το σύστημα αποδέχεται τη φόρμα και ενημερώνει
τον συντονιστή
5. Ο συντονιστής επιθεωρεί τα στοιχεία και καταχωρεί ένα νέο
περιστατικό στο σύστημα μέσω της περίπτωσης χρήσης
Καταχώρησε περιστατικό. Ο συντονιστής επιλέγει τρόπο
αντιμετώπισης και ενημερώνει τον διασώστη
6. Το σύστημα παρουσιάζει την αναγνώριση λήψης
και την επιλεχθείσα αντιμετώπιση στον διασώστη
44
Ορθή περιγραφή περίπτωσης χρήσης (2)
Συνθήκες εισόδου: Ο διασώστης είναι συνδεδεμένος με το σύστημα
Συνθήκες εξόδου: Ο διασώστης έχει λάβει επιβεβαίωση ότι η αναφορά

του έχει παραδοθεί και έχει ενημερωθεί για την
επιλεχθείσα αντιμετώπιση
Ή
Ο διασώστης έχει ενημερωθεί σχετικά με τον λόγο που
εμπόδισε την ολοκλήρωση της δοσοληψίας [σύνοψη
των εναλλακτικών ροών]
Απαιτήσεις Η αναφορά του διασώστη αναγνωρίζεται εντός 30’’
ποιότητας Η επιλεχθείσα απόκριση παραδίδεται στον διασώστη
το πολύ 30’’ από τη στιγμή που θα αποσταλεί από τον
συντονιστή
45
Απόδοση προτεραιοτήτων στις

• Υψηλή προτεραιότητα
◦ Η απαίτηση εξετάζεται κατά τις φάσεις της ανάλυσης, του
σχεδιασμού και της υλοποίησης
◦ Εντάσσεται στη διαδικασία του αρχικού ελέγχου αποδοχής από
τον πελάτη
• Μεσαία προτεραιότητα
◦ Η απαίτηση εξετάζεται κατά τις φάσεις της ανάλυσης και του
σχεδιασμού
◦ Παρουσιάζεται στο δεύτερο πρωτότυπο του συστήματος
• Χαμηλή προτεραιότητα
◦ Η απαίτηση εξετάζεται κατά τη φάση της ανάλυσης
◦ Κυρίως αφορά το πώς το σύστημα μπορεί να επεκταθεί στο
μέλλον.
46
Εκλέπτυνση περιπτώσεων χρήσης
• Στην εκλέπτυνση των περιπτώσεων χρήσης
περιλαμβάνουμε:
◦ Λεπτομέρειες για τις διαδράσεις ανάμεσα στους actors και το
σύστημα
◦ Για τον σκοπό αυτό χρησιμοποιούμε και τα διαγράμματα ακολουθίας
◦ Ορίζουμε τις εναλλακτικές ροές γεγονότων
◦ Λεπτομέρειες σχετικά με τις εξειδικεύσεις των αντικειμένων που
αναφέρονται στην περίπτωση χρήσης
◦ Π.χ. περιστατικό: πυρκαγιά, ατύχημα σε μεταφορικά μέσα, άλλο
περιστατικό
◦ Ορίζουμε ελέγχους συστήματος για τον καθορισμό των κριτηρίων
αποδοχής κάθε περίπτωση χρήσης
◦ Και σενάρια διενέργειας των ελέγχων συστήματος
◦ Ορίζουμε δικαιώματα πρόσβασης
◦ Ποιοι actors μπορούν να εκκινήσουν ποιες περιπτώσεις χρήσης
47
Παράδειγμα εκλέπτυνσης
περίπτωσης χρήσης (1)
Ροή γεγονότων: 1. Ο διασώστης ενεργοποιεί τη λειτουργία «Αναφορά ατυχήματος» στον
υπολογιστή του
2. Το σύστημα παρουσιάζει μία φόρμα. Η φόρμα περιλαμβάνει
ένα μενού περιστατικών (φωτιά, ατύχημα, άλλο περιστατικό),
τη θέση, σύντομη περιγραφή, προτεινόμενη αντιμετώπιση και
ένδειξη επιβλαβών υλικών στον χώρο του περιστατικού
3. Ο διασώστης συμπληρώνει τη φόρμα, εισάγοντας τουλάχιστον το
επίπεδο συναγερμού και τη σύντομη περιγραφή και ενδεχομένως
κατάλληλους τρόπους αντιμετώπισης. Ο διασώστης υποβάλλει τη φόρμα.
4. Το σύστημα αποδέχεται τη φόρμα και ενημερώνει
τον συντονιστή με ένα αναδυόμενο παράθυρο
5. Ο συντονιστής επιθεωρεί τα στοιχεία και καταχωρεί ένα νέο περιστατικό
στο σύστημα μέσω της περίπτωσης χρήσης «Καταχώρησε περιστατικό».
Όλα τα πεδία που έχουν συμπληρωθεί στη φόρμα, μεταφέρονται
αυτόματα στην καταχώρηση περιστατικού. Ο συντονιστής αναθέτει
πόρους στην αντιμετώπιση του περιστατικού μέσω της περίπτωσης
χρήσης «Κατάνειμε πόρους» και αναγνωρίζει την παραλαβή της
αναφοράς αποστέλλοντας ένα σύντομο μήνυμα στον διασώστη.
6. Το σύστημα παρουσιάζει την αναγνώριση λήψης
και την επιλεχθείσα αντιμετώπιση στον διασώστη
48
Διάγραμμα ακολουθίας
:Διεπαφή :Εφαρμογή :Εφαρμογή :Διεπαφή
Διασώστη Διασώστη Συντονιστή Συντονιστή
:Διασώστης
αναφορά :ΦόρμαΠεριστ :Συντονιστής
Περιστατικού()
<<create>>
συμπλήρωση()
ενημέρωση
αποστολή παράδοση εμφάνιση Νέου
υποβολή()
Αναφορ() Αναφοράς() popup() Περιστατικού
αναγνώριση
αποστολή
αναγν() Λήψης()
κλείσε() παράδοση
εμφάνιση αναγν()
popup()
ενημέρωση
Αναγνώρισης()
49
Προσδιορισμός εναλλακτικών
ροών
• Ρωτάμε τους χρήστες
◦ Ποιά σφάλματα αντιμετωπίζουν;
◦ Ποιες διαφορετικές εναλλακτικές χρειάζονται-διαθέτουν-
περιμένουν;
• Ρωτάμε τους ειδικούς του πεδίου
◦ Τι μπορεί να πάει στραβά;
◦ Τι συμβαίνει όταν κάτι πάει στραβά; Πώς ανακάμπτουμε;
• Οι εναλλακτικές ροές μπορεί να προσδιοριστούν –
επεκταθούν σε πολλαπλά στάδια (iterations)
εκλέπτυνσης της περίπτωσης χρήσης
50
Σχέσεις επικοινωνίας μεταξύ
actors και περιπτώσεων χρήσης
• Οι σχέσεις επικοινωνίας μεταξύ actors και
περιπτώσεων χρήσης αναπαριστούν τη ροή της
πληροφορίας στην περίπτωση χρήσης
◦ Ο actor που εκκινεί την περίπτωση χρήσης διακρίνεται
από τους υπόλοιπους που μετέχουν στην περίπτωση
χρήσης
◦ Ορίζοντας ποιος εκκινεί την περίπτωση χρήσης, ορίζουμε έμμεσα
και ποιος δεν έχει δικαίωμα να την εκκινήσει
◦ Ορίζοντας τους actors που επικοινωνούν με την
περίπτωση χρήσης ορίζουμε το ποιοι μπορούν να δουν
συγκεκριμένες πληροφορίες και ποιοι όχι
• Με τον τρόπο αυτό ορίζουμε τον έλεγχο
πρόσβασης, σε αδρό επίπεδο
51
Διάγραμμα σχέσεων επικοινωνίας μεταξύ

actors και περιπτώσεων χρήσης
Καταχώρησε
<<εκκίνηση>> Περιστατικό
<<εκκίνηση>>
<<εκκίνηση>>
Διασώστης <<συμμετοχή>> Συντονιστής
Κατάνειμε
Ανάφερε
Πόρους
Περιστατικό
52
Συσχετίσεις <<extend>> μεταξύ
• Μία περίπτωση χρήσης Α συνδέεται με μία άλλη Β με μία
σχέση <<extend>> αν η Α δύναται να ενσωματώσει τη
συμπεριφορά της Β υπό συγκεκριμένες συνθήκες
◦ Στην περίπτωση χρήσης Ανάφερε Περιστατικό μπορεί να διακοπεί η
επικοινωνία μεταξύ του υπολογιστή του διασώστη και του
συντονιστή ενώ συμπληρώνεται η φόρμα
◦ Η εφαρμογή του διασώστη πρέπει να τον ενημερώσει ότι η φόρμα
του δεν απεστάλη ώστε αυτός να προβεί στις κατάλληλες ενέργειες
◦ Η περίπτωση χρήσης Διακοπή Σύνδεσης μοντελοποιείται ως
επέκταση (<<extend>>) στην περίπτωση χρήσης Ανάφερε
περιστατικό
◦ Οι συνθήκες κάτω από τις οποίες ενεργοποιείται η Διακοπή
Σύνδεσης περιγράφονται στην ίδια τη Διακοπή Σύνδεσης ΚΑΙ ΟΧΙ
στην Ανάφερε περιστατικό
53

Ανάφερε Περιστατικό
<<extends>> Διακοπή
extension points:
Διακοπή Σύνδεσης Σύνδεσης
Διασώστης
• Πλεονεκτήματα διαχωρισμού:
◦ Η βασική περίπτωση χρήσης παραμένει σύντομη και έτσι πιο εύκολη στην κατανόησή
της
◦ Η συνήθης περίπτωση διακρίνεται από την κατ’ εξαίρεση και έτσι η ομάδα ανάπτυξης
μπορεί να τις χειριστεί διαφορετικά, π.χ. Να βελτιστοποιήσει την συνήθη για χρόνο
απόκρισης ενώ τη δεύτερη για ευρωστία
• Τόσο η επεκτεινόμενη περίπτωση χρήσης όσο και οι επεκτάσεις της είναι
πλήρεις περιπτώσεις χρήσης
◦ Η κάθε μία έχει συνθήκες εισόδου και εξόδου και πρέπει να είναι κατανοητές από τους
χρήστες ως ανεξάρτητες ολότητες
• Τα σημεία επέκτασης (extension points) είναι σημεία στη ροή γεγονότων της
επεκτεινόμενης περίπτωσης χρήσης όπου εισάγεται η ροή γεγονότων της
επέκτασης
◦ Μπορεί να είναι πάνω από ένα σημεία, π.χ. στην περίπτωση χρήσης Ανάφερε
περιστατικό όλα τα σημεία επικοινωνίας διασώστη-συντονιστή
54
Περιγραφή περίπτωσης χρήσης επέκτασης
Όνομα περίπτωσης Διακοπή επικοινωνίας
χρήσης:
Συμμετέχοντες Διασώστης
actors:
Επεκτείνει: Ανάφερε περιστατικό
Συνθήκες εισόδου: Η αποστολή της φόρμας στον συντονιστή απέτυχε
Συνθήκες εξόδου: Το σύστημα έχει αποστείλει τη φόρμα Ή το σύστημα
ενημερώνει τον διασώστη ότι η αποστολή είναι αδύνατη
Ροή γεγονότων: 1. Το σύστημα ενημερώνει τον διασώστη και τον
συντονιστή ότι η επικοινωνία έχει χαθεί. Τους
εμφανίζονται πιθανές αιτίες (π.χ. ο διασώστης
βρίσκεται σε σήραγγα)
2. Το σύστημα καταχωρεί το περιστατικό διακοπής
της επικοινωνίας σε αρχείο καταγραφής και η
φόρμα αποστέλλεται όταν αποκατασταθεί η επικοινωνία
3. Ο διασώστης και ο συντονιστής επικοινωνούν με άλλο
τρόπο
4. Ο συντονιστής εκκινεί την περίπτωση χρήσης Ανάφερε
Περιστατικό από τον δικό του σταθμό εργασίας.
55

• Παράδειγμα κατ’ επιλογή συμπεριφοράς
Ανάφερε Περιστατικό <<extends>>

extension points: Διακοπή
Διακοπή Σύνδεσης Σύνδεσης
Διασώστης Βοήθεια
<<extends>>
Βοήθεια
56
Συσχετίσεις <<include>> μεταξύ
• Οι συσχετίσεις <<include>> χρησιμοποιούνται για να
επιτύχουμε τη λειτουργική αποσύνθεση
◦ Έχουμε ένα σύνθετο πρόβλημα και θέλουμε να το
διασπάσουμε σε μικρότερα και πιο διαχειρίσιμα
◦ Παράδειγμα:
Διαχειρίσου Περιστατικό
<<include>>
<<include>>
<<include>>
Καταχώρισε Περιστατικό Αντιμετώπισε Περιστατικό Κλείσε Περιστατικό
57

• Οι συσχετίσεις <<include>> χρησιμοποιούνται επίσης για
να απαλείψουν τον πλεονασμό μεταξύ περιπτώσεων
χρήσης
◦ Μοιάζουν με τις κλήσεις διαδικασιών
◦ Ο συντονιστής χρειάζεται να συμβουλευτεί έναν χάρτη της πόλης
όταν (α) καταγράφει ένα περιστατικό (π.χ. προκειμένου να εξετάσει
ποιες περιοχές διατρέχουν κίνδυνο) και (β) όταν κατανέμει πόρους
(π.χ. για να δει ποιοι πόροι βρίσκονται πιο κοντά).
◦ Εισάγουμε μία περίπτωση χρήσης Δες Χάρτη την οποία
ενσωματώνουν (include) οι περιπτώσεις χρήσης Κατάγραψε
Περιστατικό και Κατάνειμε Πόρους
58
<<include>>
Δες Χάρτη
Ανάφερε Περιστατικό
<<include>>
Κατάνειμε Πόρους
• Εκτός από την απάλειψη του πλεονασμού, η

συμπερίληψη βοηθάει στο να διατηρούνται οι
περιγραφές σύντομες
◦ Χρησιμοποιείται μόνο όταν δύο ή περισσότερες περιπτώσεις
χρήσης έχουν κοινή λειτουργικότητα
59
Ευρεστικοί κανόνες για εντοπισμό

σχέσεων επέκτασης και συμπερίληψης
• Χρησιμοποιούμε τη συσχέτιση <<extend>> για κατ’
εξαίρεση, κατ’ επιλογή (optional) ή σπάνια εμφανιζόμενη
συμπεριφορά
◦ Κατ’ εξαίρεση συμπεριφορά: π.χ. βλάβη σε έναν πόρο
◦ Κατ’ επιλογή συμπεριφορά: π.χ. Ενημέρωση πόρων που
αντιμετωπίζουν ένα διαφορετικό, μη σχετιζόμενο περιστατικό
• Χρησιμοποιούμε την συσχέτιση <<include>> για (α)
αποσύνθεση προβλήματος και (β) συμπεριφορά που
διαμοιράζεται μεταξύ δύο ή περισσοτέρων περιπτώσεων
χρήσης
• Μην ξεχνάμε, ο στόχος είναι η προαγωγή της κατανόησης!

◦ Μερικές φορές μία περίπτωση χρήσης 2 σελίδων είναι πιο εύληπτη
από 10 περιπτώσεις χρήσης 10 γραμμών η κάθε μία!
60
Γενίκευση περιπτώσεων χρήσης
• Χρησιμοποιείται όταν έχουμε παρόμοια αλλά όχι
ταυτόσημη λειτουργικότητα
• Η γονική περίπτωση χρήσης ενσωματώνει τα κοινά σημεία
της συμπεριφοράς και οι θυγατρικές περιλαμβάνουν τα
διαφορετικά
• Παράδειγμα: έχουμε διακρίβωση ταυτότητας χρήστη με
συνθηματικό ή με δακτυλικό αποτύπωμα
Έλεγξε συνθηματικό
Διακρίβωσε ταυτότητα Θυγατρική

περίπτωση χρήσης
χρήστη
Έλεγξε δακτυλικό
Γονική
αποτύπωμα
61
Προσδιορισμός αντικειμένων της

ανάλυσης (1)
• Σημαντικό ζήτημα στη συνεργασία ομάδας ανάπτυξης-
χρηστών είναι η διαφορετική ορολογία
◦ Τα στελέχη της ομάδας ανάπτυξης προοδευτικά μαθαίνουν την
ορολογία των χρηστών, αλλά στη διάρκεια ζωής του έργου μπορεί
να προστεθούν νέα στελέχη οπότε το πρόβλημα εμφανίζεται ξανά
• Ένα ουσιαστικό βήμα για την αντιμετώπιση του
προβλήματος είναι να αναδειχθούν τα αντικείμενα που
μετέχουν σε κάθε περίπτωση χρήσης και να
καταχωρηθούν σε ένα γλωσσάρι
◦ Το γλωσσάρι αποτελεί τμήμα των προδιαγραφών και των
εγχειριδίων
◦ Συντηρείται κατά την ανάπτυξη της εφαρμογής
◦ Αποσαφηνίζει τους όρους και δίνει την «επίσημη» ερμηνεία τους
62
Προσδιορισμός αντικειμένων της
• Η σύνταξη του γλωσσαρίου είναι το πρώτο βήμα στη
σύνταξη του μοντέλου ανάλυσης (επόμενη φάση)
◦ Περιγράφει τα αντικείμενα και τις ιδιότητές τους, που είναι το μόνο
τμήμα του μοντέλου ανάλυσης το οποίο είναι ορατό στους χρήστες
και επιβεβαιώνεται από αυτούς
• Κατά την ανάλυση δημιουργούνται αντικείμενα για κάθε

◦ Αν δύο περιπτώσεις χρήσης αναφέρονται στο ίδιο αντικείμενο,
πρέπει να χρησιμοποιούν το ίδιο όνομα
◦ Αν το ίδιο όνομα χρησιμοποιείται για πάνω δύο διακριτά
αντικείμενα, το ένα (ή και τα δύο) πρέπει να μετονομασθεί για να
μην υπάρχει ασάφεια
63
Παραδείγματα αντικειμένων ανάλυσης

Συντονιστής Αξιωματικός της πολιτικής προστασίας που διαχειρίζεται τα
Περιστατικά. Ο συντονιστής καταχωρεί, τεκμηριώνει και κλείνει τα
περιστατικά, σε απόκριση των ΑναφορώνΠεριστατικών και της
λοιπής επικοινωνίας με τους Διασώστες. Οι συντονιστές
προσδιορίζονται μοναδικά από τον
ΑριθμόΣτελέχουςΠολιτικήςΠροστασίας
Αναφορά Αρχική αναφορά σχετικά με ένα περιστατικό από έναν Διασώστη
Περιστατικού προς τον Συντονιστή. Μία ΑναφοράΠεριστατικού δίνει το έναυσμα
για τη δημιουργία ενός Περιστατικού από τον Συντονιστή. Μία
ΑναφοράΠεριστατικού συνίσταται από μία διαβάθμιση
σοβαρότητας, έναν τύπο (φωτιά, τροχαίο, άλλο), μία τοποθεσία
και μία περιγραφή.
Περιστατικό Κατάσταση που απαιτεί την προσοχή ενός Διασώστη. Ένα
Περιστατικό μπορεί να αναφερθεί στο σύστημα από έναν
Διασώστη ή από κάποιον εξωτερικό προς το σύστημα. Ένα
Περιστατικό συνίσταται από μία περιγραφή, μία κατάσταση
απόκρισης (ανοικτό, κλειστό, τεκμηριωμένο), μία τοποθεσία, και
ένα πλήθος Διασωστών.
64
Ευρεστικές για προσδιορισμό
αρχικών αντικειμένων ανάλυσης
• Οι όροι που η ομάδα ανάπτυξης ή οι χρήστες πρέπει να
αποσαφηνίσουν-εξηγήσουν για να κατανοήσουν την περίπτωση
χρήσης
• Όροι που εμφανίζονται συχνά στις περιπτώσεις χρήσης (περιστατικό,
δανεισμός, εξέταση κ.λπ.)
• Οντότητες του πραγματικού κόσμου τις οποίες πρέπει να καταγράφει-
παρακολουθεί το σύστημα (διασώστης, πόρος, βιβλιάριο καταθέσεων
κ.λπ.)
• Περιπτώσεις χρήσης (π.χ. ανάφερε περιστατικό, κατάθεσε χρήματα)
• Πηγές ή καταβόθρες δεδομένων (π.χ. αισθητήρας καπνού, αναφορά)
• Στοιχεία με τα οποία αλληλεπιδρά ο χρήστης (π.χ. υποκατάστημα
τράπεζας)
• Πάντοτε χρησιμοποιούμε όρους από το πεδίο της εφαρμογής
65
Ευρεστικές για συνδυαστικό έλεγχο περιπτώσεων χρήσης και

των αντικειμένων που προκύπτουν από αυτές
• Ποιες περιπτώσεις χρήσης δημιουργούν το αντικείμενο;

(δηλ. κατά τη διάρκεια ποιων περιπτώσεων χρήσης
εισάγονται οι τιμές των γνωρισμάτων των αντικειμένων
στο σύστημα);
• Ποιοι actors έχουν πρόσβαση στην πληροφορία;
• Ποιες περιπτώσεις χρήσης τροποποιούν και καταστρέφουν
το αντικείμενο; (δηλ. ποιες περιπτώσεις χρήσης αλλάζουν
ή διαγράφουν αυτή την πληροφορία από το σύστημα;)
• Ποιοι actors εκκινούν αυτές τις περιπτώσεις χρήσης;
• Χρειάζεται το αντικείμενο (δηλ. υπάρχει τουλάχιστον μία
περίπτωση χρήσης που εξαρτάται από αυτή την
πληροφορία);
66
Προσδιορισμός μη λειτουργικών
• Οι μη λειτουργικές απαιτήσεις περιγράφουν
απόψεις του συστήματος που δεν σχετίζονται
άμεσα με τη λειτουργική του συμπεριφορά
• Αφορούν ένα πλήθος θεμάτων, από τη διεπαφή
χρήστη μέχρι την ασφάλεια και τον χρόνο
απόκρισης
• Ορίζονται μαζί με τις λειτουργικές απαιτήσεις
γιατί επηρεάζουν σημαντικά τόσο την ανάπτυξη
όσο και το κόστος του συστήματος
67
Λειτουργικές έναντι μη λειτουργικών

Λειτουργικές απαιτήσεις Μη λειτουργικές απαιτήσεις
• Περιγράφουν εργασίες των • Περιγράφουν ιδιότητες του
χρηστών που πρέπει να συστήματος ή του πεδίου
υποστηρίζει το σύστημα
• Περιγράφονται ως • Περιγράφονται ως
ενέργειες περιορισμοί ή αρνητικές
“Διαφήμισε μία νέα διαβεβαιώσεις (assertions)
ομοσπονδία” “Κάθε είσοδος του χρήστη πρέπει
“Προγραμμάτισε ένα να προκαλεί ανάδραση εντός 1
τουρνουά” δευτερολέπτου”
“Ενημέρωσε μία ομάδα “Η κατάρρευση του συστήματος
ενδιαφέροντος” δεν πρέπει να προκαλεί απώλεια
δεδομένων”
68
Ερωτήσεις για εκμαίευση μη
λειτουργικών απαιτήσεων (1)
• Χρηστικότητα
◦ Ποιο είναι το επίπεδο ικανότητας (expertise) του χρήστη;
◦ Ποιά πρότυπα διεπαφής είναι οικεία στον χρήστη;
◦ Ποιά τεκμηρίωση πρέπει να είναι διαθέσιμη στον χρήστη;
◦ Ποιά εκπαίδευση πρέπει να παρασχεθεί στον χρήστη;
• Αξιοπιστία
◦ Πόσο αξιόπιστο, διαθέσιμο και εύρωστο πρέπει να είναι το σύστημα; Ποιός ο
αποδεκτός χρόνος μέχρι τη βλάβη και ποιος ο αποδεκτός χρόνος μέχρι την
επιδιόρθωση;
◦ Είναι αποδεκτό να επανεκκινείται το σύστημα σε περίπτωση αποτυχίας;
◦ Ποιός βαθμός απώλειας δεδομένων είναι ανεκτός;
◦ Πώς πρέπει το σύστημα να χειρίζεται τις εξαιρέσεις (π.χ. Σφάλματα εισόδου);
◦ Υπάρχουν απαιτήσεις ασφάλειας χρήσης-εγκατάστασης (safety) για το
σύστημα;
◦ Υπάρχουν απαιτήσεις ασφάλειας δεδομένων-διαδικασιών (security) για το
σύστημα;
69

• Επιδόσεις
◦ Πόσο ταχεία πρέπει να είναι η απόκριση του συστήματος;
◦ Είναι ο χρόνος κρίσιμος σε κάποια από τις εργασίες των χρηστών;
◦ Πόσο μεγάλη είναι η αποθήκη δεδομένων σε συγκρίσιμα συστήματα;
◦ Ποιά είναι η μεγαλύτερη καθυστέρηση που θεωρείται αποδεκτή από τους
χρήστες;
70
• Δυνατότητα υποστήριξης
◦ Υπάρχουν επεκτάσεις του συστήματος που μπορούμε να
προβλέψουμε;
◦ Τι είδους αλλαγές περιμένουμε;
◦ Ποιός συντηρεί το σύστημα;
◦ Υπάρχουν σχέδια για μεταφορά του συστήματος σε
διαφορετικό λογισμικό/υλικό;
• Υλοποίηση
◦ Υπάρχουν περιορισμοί για το υλικό;
◦ Υπάρχουν περιορισμοί για το λογισμικό συστήματος;
◦ Ποιά τα χαρακτηριστικά του υλικού όπου θα εκτελείται
το σύστημα, συμπεριλαμβανομένης της μνήμης και του
βοηθητικού χώρου αποθήκευσης;
71

• Διεπαφή
◦ Θα διαδρά το σύστημα με υπάρχοντα συστήματα;
◦ Πώς εξάγονται/εισάγονται δεδομένα από/προς το
σύστημα (σε μέσο, μέσω δικτύου, με ποιο μορφότυπο
κ.ο.κ.);
◦ Ποιά πρότυπα που χρησιμοποιεί ο πελάτης πρέπει να
υποστηρίζονται από το σύστημα;
• Λειτουργία
◦ Ποιός διαχειρίζεται το σύστημα;
◦ Πόσο συχνά θα λαμβάνονται αντίγραφα ασφαλείας;
◦ Ποιός θα είναι υπεύθυνος για τη λήψη τους;
72
• «Πακετάρισμα»
◦ Ποιός εγκαθιστά το σύστημα;
◦ Πόσες εγκαταστάσεις προβλέπονται;
◦ Υπάρχουν περιορισμοί στην εγκατάσταση;
• Νομικές απαιτήσεις
◦ Ποιο θα είναι το μοντέλο αδειοδότησης;
◦ Υπάρχουν ευθύνες για πιθανές επιπτώσεις από
αποτυχίες του συστήματος;
◦ Πρέπει να πληρωθούν δικαιώματα χρήσης για
συγκεκριμένους αλγορίθμους ή συνιστώσες που
χρησιμοποιούνται;
73

• Φυσικό περιβάλλον
◦ Πού θα λειτουργεί το σύστημα;
◦ Οι περιβαλλοντικές συνθήκες θα είναι συνηθισμένες;
◦ Θα υπάρχει εξοπλισμός σε μία ή σε περισσότερες
τοποθεσίες;
• Θέματα ασφάλειας
◦ Πρέπει να ελέγχεται η πρόσβαση στο σύστημα και τα
δεδομένα;
◦ Πρέπει να μας απασχολήσει η φυσική ασφάλεια του
74
Πρότυπο εγγράφου ανάλυσης
απαιτήσεων (1/2)
1. Εισαγωγή
2. Τρέχον σύστημα
3. Προτεινόμενο σύστημα
3.1 Επισκόπηση
3.2 Λειτουργικές απαιτήσεις
3.3 Μη λειτουργικές απαιτήσεις
3.4 Περιορισμοί (“ψεύδο-απαιτήσεις”)
75

απαιτήσεων (2/2)
3.5 Μοντέλα συστήματος
3.5.1 Σενάρια
3.5.2 Μοντέλα περιπτώσεων χρήσης
3.5.3 Μοντέλα αντικειμένων
3.5.3.1 Λεξικό δεδομένων
3.5.3.2 Διάγραμμα κλάσεων
3.5.4 Δυναμικά μοντέλα
3.5.5 Διεπαφή χρήστη
4. Γλωσσάρι
76
ENGINEERING)
Ανάλυση
Εισαγωγή
• Η ανάλυση παράγει ένα μοντέλο του συστήματος που πρέπει να είναι
ορθό, πλήρες, συνεπές και απαλλαγμένο από αμφισημίες
• Η ομάδα ανάπτυξης δημιουργεί τυπικές μορφές των προδιαγραφών
απαιτήσεων που παρήχθησαν κατά την εκμαίευση των απαιτήσεων
◦ Εξετάζονται πιο αναλυτικά οι οριακές συνθήκες και οι ειδικές περιπτώσεις
• Η ομάδα ανάπτυξης επικυρώνει, διορθώνει και αποσαφηνίζει τις
προδιαγραφές απαιτήσεων αν εντοπισθούν σφάλματα ή ασάφειες
◦ Αμφισημίες εισάγονται πολλές φορές λόγω των εγγενών χαρακτηριστικών της
φυσικής γλώσσας καθώς λόγω των παραδοχών που έχουν κάνει οι συντάκτες
των προδιαγραφών
◦ Π.χ. «η απόσταση θα είναι μικρότερη από 20» (εκατοστά; πόδια; μέτρα;), «η
ανταλλαγή δεδομένων θα γίνεται στις 12:00 ακριβώς» (σε ποιά χρονική ζώνη;)
◦ Η σύνταξη τυπικών προδιαγραφών βοηθά στον εντοπισμό ασαφειών
◦ Αν απαιτηθεί αλλαγή των προδιαγραφών απαιτήσεων ή συλλογή πρόσθετων
πληροφοριών, μετέχουν στη διαδικασία ο πελάτης και ο χρήστης
2
Εισαγωγή
• Στην αντικειμενοστρεφή ανάλυση η ομάδα ανάπτυξης δημιουργεί
ένα μοντέλο που περιγράφει το πεδίο εφαρμογής
◦ Π.χ. για μία γραμματεία πανεπιστημίου θα υπάρχουν φοιτητές, μαθήματα,
διδάσκοντες, δηλώσεις, αναθέσεις κ.ο.κ.
• Το μοντέλο της ανάλυσης στη συνέχεια επεκτείνεται για να

περιλάβει το πώς οι actors και το σύστημα αλληλεπιδρούν για να
χειριστούν το μοντέλο του πεδίου εφαρμογής
◦ Π.χ. πώς γίνονται οι δηλώσεις; Οι αναθέσεις;
• Η ομάδα ανάπτυξης θα χρησιμοποιήσει το μοντέλο ανάλυσης και

τις μη λειτουργικές προδιαγραφές για να προετοιμάσει την
αρχιτεκτονική του συστήματος κατά τον υψηλού επιπέδου
σχεδιασμό
Ανάδραση μεταξύ ανάλυσης και

προδιαγραφής απαιτήσεων
• Το μοντέλο της ανάλυσης δεν είναι απαραίτητα
κατανοητό από τους χρήστες
◦ Αυτό καθιστά αναγκαίο το να ενημερώνονται οι προδιαγραφές
απαιτήσεων όταν συλλεχθούν πρόσθετες πληροφορίες,
αποσαφηνιστούν σημεία, επιλυθούν αμφισημίες
◦ Αφού ενημερωθούν οι προδιαγραφές απαιτήσεων πρέπει να
επαληθευθούν από τους χρήστες και τον πελάτη
• Οι απαιτήσεις πρέπει πάντα να είναι πάντα επίκαιρες
και κατανοητές από τους χρήστες και τον πελάτη
4
Διαδικασία απαιτήσεων
Διατύπωση
Εκμαίευση απαιτήσεων
Προδιαγραφή απαιτήσεων
: λειτουργικό μοντέλο
Ανάλυση Μοντέλο ανάλυσης
Διάγραμμα
: μοντέλο αντικειμένων
δραστηριότητας ανάλυσης
UML
5
Ανάλυση και λήψη αποφάσεων

• Υπάρχει μία τάση τόσο οι χρήστες όσο και η ομάδα ανάπτυξης να
αναβάλλουν τις δύσκολες αποφάσεις για αργότερα.
• Μία απόφαση μπορεί να είναι δύσκολη γιατί:
◦ Δεν έχει κατανοηθεί αρκετά το πεδίο εφαρμογής
◦ Δεν υπάρχει επαρκής τεχνική γνώση
◦ Υπάρχει διαφωνία μεταξύ χρηστών και ομάδας ανάπτυξης
• Η αναβολή των αποφάσεων επιτρέπει στο έργο να συνεχίσει και
στους μετέχοντες να αποφύγουν την αντιπαράθεση
◦ Ωστόσο οι αποφάσεις θα πρέπει να ληφθούν κάποτε, συνηθέστατα με
μεγαλύτερο κόστος απ’ ό,τι αν είχαν ληφθεί εγκαίρως καθώς τα ζητήματα θα
ανακύψουν είτε στη φάση του ελέγχου είτε σε αυτή της αξιολόγησης των
χρηστών
• Η μετάφραση των προδιαγραφών απαιτήσεων σε ένα τυπικό ή ημι-
τυπικό μοντέλο εξαναγκάζει την ομάδα ανάπτυξης να εντοπίσει και
να επιλύσει τα δύσκολα ζητήματα νωρίς στη διαδικασία ανάπτυξης
6
Το μοντέλο της ανάλυσης
• Το μοντέλο της ανάλυσης απαρτίζεται από τρία επί
μέρους μοντέλα:
◦ Το λειτουργικό μοντέλο, που περιλαμβάνει περιπτώσεις
χρήσης και σενάρια
◦ Το μοντέλο αντικειμένων ανάλυσης που περιλαμβάνει
διαγράμματα κλάσεων και αντικειμένων
◦ Το δυναμικό μοντέλο, που περιλαμβάνει διαγράμματα
ακολουθίας και τα διαγράμματα μηχανής καταστάσεων
• Θα εξετάσουμε το πώς εκλεπτύνεται το λειτουργικό
μοντέλο για να εξαχθεί το μοντέλο αντικειμένων και
το μοντέλο αντικειμένων
Το μοντέλο της ανάλυσης
useCaseDiagram: classDiagram: stateMachine sequence

View View Diagram: View Diagram: View
functionalModel: objectModel: dynamicModel:

Model Model Model
analysisModel:
Model
8
Έννοιες της ανάλυσης
• Οι βασικές έννοιες της ανάλυσης που θα συνοψισθούν είναι:
◦ Τα μοντέλα αντικειμένων ανάλυσης και τα δυναμικά μοντέλα
◦ Τα αντικείμενα οντότητας, ορίου και ελέγχου
◦ Γενίκευση και εξειδίκευση
Μοντέλα αντικειμένων ανάλυσης

και δυναμικά μοντέλα (1)
• Το μοντέλο αντικειμένων ανάλυσης εστιάζει στις
έννοιες που διαχειρίζεται το σύστημα, τις ιδιότητες
και τις συσχετίσεις μεταξύ τους
• Το μοντέλο αντικειμένων ανάλυσης απεικονίζεται με
διαγράμματα κλάσεων της UML, περιλαμβάνοντας
κλάσεις, γνωρίσματα και λειτουργίες
• Το μοντέλο αντικειμένων ανάλυσης είναι ένα
«οπτικό λεξικό» των βασικών εννοιών που είναι
ορατές στον χρήστη
10
• Το δυναμικό μοντέλο εστιάζει στη συμπεριφορά του
• Απεικονίζεται με διαγράμματα ακολουθίας και διαγράμματα
μηχανής καταστάσεων
◦ Τα διαγράμματα ακολουθίας αναπαριστούν τις αλληλεπιδράσεις μεταξύ
συνόλων αντικειμένων κατά τη διάρκεια μίας περίπτωσης χρήσης
◦ Τα διαγράμματα μηχανής καταστάσεων αναπαριστούν τη συμπεριφορά
ενός μεμονωμένου αντικειμένου (ή μιας ομάδας από πολύ στενά
συνδεδεμένα αντικείμενα)
• Το δυναμικό μοντέλο εξυπηρετεί στην ανάθεση «καθηκόντων»

στις κλάσεις και στον προσδιορισμό νέων κλάσεων,
συσχετίσεων και γνωρισμάτων που μπορούν να προστεθούν
στα αντικείμενα της ανάλυσης
11

• Και τα δύο μοντέλα αναπαριστούν έννοιες επιπέδου χρήστη, όχι
πραγματικές κλάσεις ή συνιστώσες λογισμικού
◦ Συνακόλουθα, κλάσεις όπως Database, Subsystem, SessionManager,
Network ΔΕΝ πρέπει να περιλαμβάνονται στα μοντέλα αυτά
• Οι κλάσεις στο μοντέλο αντικειμένων ανάλυσης θα
απεικονίζονται σε μία ή περισσότερες κλάσεις στο τελικό
σύστημα
◦ Θα έχουν ωστόσο αρκετά περισσότερα γνωρίσματα και συσχετίσεις απ’ ό,τι
έχουν στο μοντέλο ανάλυσης
• Οι κλάσεις ανάλυσης πρέπει να θεωρούνται ως υψηλού
επιπέδου αφαιρέσεις, οι οποίες θα υλοποιηθούν με
περισσότερες λεπτομέρειες στη συνέχεια
12
Παραδείγματα «καλών» και «κακών»
αντικειμένων ανάλυσης
Αναφέρεται στο πώς
Βιβλίο ΒάσηΔεδομένωνΒιβλίων αποθηκεύονται τα
δεδομένα (απόφαση
σταδίου σχεδιασμού)
Αναφέρεται σε
Δανειζόμενος UserId εσωτερική λέπτομέρεια
υλοποίησης
Αναφέρεται στο πώς

Προμηθευτής Καταγραφέας RFID καταγράφονται τα βιβλία
(απόφαση σταδίου
σχεδιασμού)
«καλά» αντικείμενα «κακά» αντικείμενα
13
Αντικείμενα οντότητας, ορίου και

ελέγχου (1)
• Τα αντικείμενα στο μοντέλο αντικειμένων ανάλυσης
διαχωρίζονται σε:
◦ αντικείμενα οντότητας, που αντιπροσωπεύουν τη μόνιμη
πληροφορία που διαχειρίζεται το σύστημα
◦ Στον αυτόματο πωλητή εισιτηρίων, οι ζώνες και οι τιμοκατάλογοι είναι
αντικείμενα οντότητας
◦ Αντικείμενα ορίου που αντιπροσωπεύουν τις αλληλεπιδράσεις
μεταξύ actors και συστήματος.
◦ Στον αυτόματο πωλητή εισιτηρίων η οθόνη και το κουμπί επιλογής ζώνης
είναι αντικείμενα ορίου
◦ Αντικείμενα ελέγχου που αναλαμβάνουν τη διεκπεραίωση της
◦ Στον αυτόματο πωλητή ένα αντικείμενο TicketSaleControl αντιπροσωπεύει τη
δραστηριότητα της πώλησης ενός εισιτηρίου
14
ελέγχου (2)
• Η χρήση αυτών των τριών τύπων αντικειμένων διευκολύνει την
ομάδα ανάπτυξης να διακρίνει σχετιζόμενες αλλά διαφορετικές
έννοιες
◦ Π.χ. η ζώνη ταξιδιού που διαχειρίζεται ο πωλητής έχει διαφορετικές ιδιότητες
από την οθόνη που δείχνει την επιλεγείσα ζώνη
◦ Η μοντελοποίηση της ζώνης ως αντικείμενο οντότητας και της οθόνης ως
αντικείμενο ορίου εξαναγκάζει τον διαχωρισμό
◦ Με τον τρόπο αυτό καταλήγουμε σε μικρότερα και πιο εξειδικευμένα
• Επίσης έχουμε μοντέλα πιο εύκολο να συντηρηθούν

◦ Π.χ. αν αλλάξει η διεπαφή με το σύστημα (αντικείμενα ορίου), η βασική
λειτουργικότητα (αντικείμενα οντότητας και ελέγχου) δεν θα χρειαστεί να
μεταβληθεί
15

ελέγχου (3)
• Στη UML μπορούμε να χρησιμοποιήσουμε στερεότυπα για να
χαρακτηρίσουμε τις κλάσεις
<<entity>> <<control>> <<boundary>>
Zone TicketSaleControl ZoneSelectButton
<<entity>> <<boundary>>
FareCatalogue LCDDisplay
Μπορούμε επίσης να χρησιμοποιήσουμε και σύμβαση ονοματολογίας των

κλάσεων:
– Οι κλάσεις που τελειώνουν σε Control είναι αντικείμενα ελέγχου
– Οι κλάσεις που τελειώνουν σε Form, Button, Display, Boundary είναι αντικείμενα
ορίου
– Όλες οι άλλες κλάσεις είναι αντικείμενα οντότητας
Αυτό μας διευκολύνει ακόμη και στην περίπτωση που έχουμε μόνο τον πηγαίο
κώδικα
16
Γενίκευση και εξειδίκευση (1)
• Η γενίκευση είναι μία δραστηριότητα μοντελοποίησης
όπου αναγνωρίζουμε αφαιρετικές έννοιες από έννοιες
χαμηλότερου επιπέδου
◦ Χρησιμοποιείται ευρέως στον ανασχεδιασμό – αντίστροφη μηχανική
◦ Π.χ. έστω ότι εντοπίζουμε διαφορετικές φόρμες για διαχείριση
δανεισμού βιβλίων, δανεισμού περιοδικών και δανεισμού
ηλεκτρονικών μέσων (CD, DVD). Παρατηρούμε τα κοινά στοιχεία και
δημιουργούμε μία αφαιρετική έννοια την Δανεισμός που εμπεριέχει
τα κοινά στοιχεία των τριών επί μέρους εννοιών
17

• Η εξειδίκευση είναι μία δραστηριότητα μοντελοποίησης
όπου αναγνωρίζουμε πιο συγκεκριμένες έννοιες από
κάποια έννοια υψηλότερου επιπέδου
◦ Χρησιμοποιείται ευρέως στην εξ αρχής δημιουργία συστημάτων
◦ Π.χ. έστω ότι ο πελάτης περιγράφει την έννοια της πρόσκτησης και
στη συνέχεια περιγράφει τις έννοιες του Βιβλίου, του Περιοδικού και
του Ηλεκτρονικού μέσου
18
• Σε κάθε περίπτωση καταλήγουμε σε μία ιεραρχία εννοιών που
συνδέονται με σχέσεις κληρονομικότητας
◦ Όταν αναφερόμαστε σε μία έννοια υψηλότερου επιπέδου, εννοούμε και
όλες τις έννοιες χαμηλότερου επιπέδου στο τμήμα της ιεραρχίας που
ξεκινά από την έννοια υψηλού επιπέδου
Πρόσκτηση
Περιοδικό Βιβλίο ΗλεκτρονικόΜέσο
Πρακτικά
Εγκυκλοπαίδεια Μονογραφία Σύγγραμμα
Συνεδρίου
19
Δραστηριότητες ανάλυσης: από τις περιπτώσεις

χρήσης στα αντικείμενα
• Στη συνέχεια θα δούμε τις δραστηριότητες μετατροπής των περιπτώσεων χρήσης
και των σεναρίων σε μοντέλο ανάλυσης. Οι δραστηριότητες ανάλυσης
περιλαμβάνουν:
◦ Τον προσδιορισμό των αντικειμένων οντότητας
◦ Τον προσδιορισμό των αντικειμένων ορίου
◦ Τον προσδιορισμό των αντικειμένων ελέγχου
◦ Την απεικόνιση των περιπτώσεων χρήσης σε αντικείμενα μέσω διαγραμμάτων
◦ Τη μοντελοποίηση διαδράσεων μεταξύ αντικειμένων χρησιμοποιώντας κάρτες CRC
(κλάσεις, ευθύνες και συνεργασίες)
◦ Τον προσδιορισμό συσχετίσεων
◦ Τον προσδιορισμό συναθροίσεων
◦ Τον προσδιορισμό γνωρισμάτων
◦ Τη μοντελοποίηση συμπεριφοράς που εξαρτάται από την κατάσταση σε επίπεδο
μεμονωμένου αντικειμένου
◦ Τη μοντελοποίηση συσχετίσεων κληρονομικότητας
◦ Την επιθεώρηση του μοντέλου της ανάλυσης
20
Προσδιορισμός αντικειμένων
οντότητας (1)
• Τα αντικείμενα οντότητας μπορούν να
εντοπισθούν εξετάζοντας τις περιπτώσεις χρήσης
• Η διαδικασία βασίζεται στην ανάλυση της φυσικής
γλώσσας και επιτρέπει τον εντοπισμό κλάσεων,
στιγμιοτύπων, λειτουργιών κ.ο.κ.
• Οι πρώτες ευρεστικές προτάθηκαν από τον Abbot
(1983)
21
Προσδιορισμός αντικειμένων οντότητας (2)

• Ευρεστικές του Abbot
Μέρος του λόγου Στοιχείο μοντέλου Παράδειγμα
Κύριο όνομα Στιγμιότυπο Πέτρος
Ουσιαστικό Κλάση διασώστης
Ρήμα ενέργειας Λειτουργία-Συσχέτιση Δημιουργεί, υποβάλλει,
επιλέγει
Ρήμα δηλωτικό είδους Κληρονομικότητα «είναι τύπου», «είναι
ένα από» ...
Ρήμα δηλωτικό κτήσης Συνάθροιση «Αποτελείται από»,
«περιλαμβάνει» ...
Τροπικό ρήμα Περιορισμός «Πρέπει να είναι»
Επιθετικοί Γνώρισμα Περιγραφή
προσδιορισμοί περιστατικού
22
• Περιορισμοί της ανάλυσης φυσικής γλώσσας
◦ Εξαρτάται ισχυρά από το στυλ γραφής του αναλυτή
◦ Συνέπεια όρων (κάρτα δανειζομένου - ταυτότητα δανειζομένου, δανεισμός –
χρέωση)
◦ Χρήση ρημάτων αντί ουσιαστικών (εκδίδεται το τιμολόγιο, τιμολογείται το
προϊόν)
◦ Η ομάδα ανάπτυξης πιθανώς να πρέπει να επαναδιατυπώσει και να
αποσαφηνίσει τις απαιτήσεις
◦ Έχει την τάση να παράγει υπερβολικά πολλές κλάσεις
◦ Πολλά ουσιαστικά αντιστοιχούν σε γνωρίσματα ή σε συνώνυμα άλλων κλάσεων –
η διάκριση απαιτεί επεξεργασία που –για μεγάλα έργα- είναι χρονοβόρα
◦ Μπορεί να χρησιμοποιηθεί για την εξαγωγή μιας αρχικής λίστας
υποψήφιων αντικειμένων από τις περιγραφές
23
• Πρόσθετες ευρεστικές
◦ Οι όροι που η ομάδα ανάπτυξης ή οι χρήστες πρέπει να αποσαφηνίσουν-
εξηγήσουν για να κατανοήσουν την περίπτωση χρήσης
◦ Όροι που εμφανίζονται συχνά στις περιπτώσεις χρήσης (περιστατικό,
δανεισμός, εξέταση κ.λπ.)
◦ Οντότητες του πραγματικού κόσμου τις οποίες πρέπει να καταγράφει-
παρακολουθεί το σύστημα (διασώστης, πόρος, βιβλιάριο καταθέσεων κ.λπ.)
◦ Δραστηριότητες του πραγματικού κόσμου τις οποίες πρέπει να καταγράφει-
παρακολουθεί το σύστημα (π.χ. κατάθεση, δανεισμός)
◦ Πηγές ή καταβόθρες δεδομένων (π.χ. αισθητήρας καπνού, αναφορά)
◦ Στοιχεία με τα οποία αλληλεπιδρά ο χρήστης (π.χ. υποκατάστημα τράπεζας)
24
• Η ομάδα ανάπτυξης περιγράφει τα αντικείμενα, τα γνωρίσματα και
τις λειτουργίες τους
• Δίνουμε έμφαση στο να δίνονται μοναδικά ονόματα
• Για τα αντικείμενα οντότητας πάντοτε δίνουμε τα ονόματα που
χρησιμοποιούν οι χρήστες και οι ειδικοί στο αντικείμενο
◦ Μπορούμε να τα αλλάξουμε μόνο για να τα αποσαφηνίσουμε σε περίπτωση
ασάφειας
• Η περιγραφή πρέπει να είναι σαφής για να αποφεύγονται
παρεξηγήσεις και σύντομη για να μη δαπανάται πολύς χρόνος
◦ Περαιτέρω τεκμηρίωση μπορεί να χρησιμοποιηθεί για τα γνωρίσματα και τις
λειτουργίες που δεν είναι προφανής η σημασία τους (π.χ. «εισαγωγικό τέλος
τραπεζικού προϊόντος»)
25
Προσδιορισμός αντικειμένων ορίου

(1)
• Τα αντικείμενα ορίου αναπαριστούν τη διεπαφή του συστήματος
με τους actors
• Σε κάθε περίπτωση χρήσης ο actor αλληλεπιδρά με τουλάχιστον
ένα αντικείμενο ορίου
◦ Το αντικείμενο ορίου συλλέγει πληροφορία από τον actor και τη μετατρέπει σε
μορφή που μπορεί να χρησιμοποιηθεί από τα αντικείμενα οντότητας και
ελέγχου (και αντίστροφα)
• Τα αντικείμενα ορίου μοντελοποιούν τη διεπαφή χρήστη σε γενικές
γραμμές
◦ Δεν περιλαμβάνουν οπτικές λεπτομέρειες, π.χ. τα αντικείμενα «επιλογή
μενού» ή «ράβδος κύλισης» είναι υπερβολικά λεπτομερειακά
◦ Η διεπαφή χρήστη θα διαμορφωθεί με σκίτσα και ψευδοπρωτότυπα και στη
συνέχεια με δοκιμές ευχρηστίας
◦ Οι αλλαγές στη διεπαφή ΔΕΝ πρέπει να απαιτούν αλλαγές στο μοντέλο
ανάλυσης
26
Προσδιορισμός αντικειμένων ορίου (2)
• Ευρεστικές για προσδιορισμό αντικειμένων ορίου
◦ Προσδιορίζουμε τα στοιχεία ελέγχου της διεπαφής που ο χρήστης χρειάζεται
για να ξεκινήσει την περίπτωση χρήσης («κουμπί επιλογής ζώνης», «κουμπί
αναφοράς περιστατικού»)
◦ Προσδιορισμός των στοιχείων που χρειάζεται ο χρήστης για να εισάγει
δεδομένα στο σύστημα (π.χ. «φόρμα αναφοράς περιστατικού»,
«κερματοδέκτης»)
◦ Προσδιορισμός ειδοποιήσεων και μηνυμάτων που δίνει το σύστημα στον
χρήστη («υπόλοιπο πληρωμής», «αναγνώριση παράδοσης αναφοράς»
◦ Όταν έχουμε πολλαπλούς actors σε μία περίπτωση χρήσης, προσδιορίζουμε
τον σταθμό εργασίας του actor (π.χ. ΟθόνηΔιασώστη»)
◦ Αν κάποιο αντικείμενο αναφέρεται σε οπτικά χαρακτηριστικά της διεπαφής,
τότε δεν είναι κατάλληλο
◦ Χρησιμοποιούμε την ορολογία των χρηστών, όχι αυτή της τεχνολογίας που θα
χρησιμοποιήσουμε («κουμπί επιλογής ζώνης» όχι «δυαδικός διακόπτης πίεσης
1»)
27
Προσδιορισμός αντικειμένων ορίου (3)

• Παραδείγματα αντικειμένων ορίου στο σύστημα διαχείρισης
περιστατικών
ΑναγνώρισηΠαράδοσης Ειδοποίηση για την παρουσίαση της αναγνώρισης του
ΑναφοράςΌριο συντονιστή στον διασώστη
ΣταθμόςΔιασώστηΌριο Ο υπολογιστής που χρησιμοποιεί ο διασώστης
ΣταθμόςΣυντονιστήΌριο Ο υπολογιστής που χρησιμοποιεί ο συντονιστής
ΑναφοράΠεριστατικούΦόρμα Φόρμα που χρησιμοποιείται για την εισαγωγή στοιχείων
στην περίπτωση χρήσης ΑνάφερεΠεριστατικό.
Παρουσιάζεται στον ΣταθμόςΔιασώστη. Περιέχει πεδία
για να εισάγονται όλα τα γνωρίσματα της
ΑναφοράςΠεριστατικού και ένα στοιχείο (π.χ. κουμπί)
για την υποβολή της συμπληρωμένης φόρμας
ΔημιουργίαΠεριστατικούΦόρμα Φόρμα που παρουσιάζεται στον ΣταθμόςΣυντονιστή
όταν λαμβάνεται ΑναφοράΠεριστατικού. Περιέχει
στοιχεία για την κατανομή πόρων και για την αποστολή
αναγνώρισης στον διασώστη
28
ορίου (4)
• Μερικά αντικείμενα ορίου δεν περιλαμβάνονται
στις περιγραφές των περιπτώσεων χρήσης
◦ Συνάγονται από την ομάδα ανάπτυξης
◦ Π.χ. η ΔημιουργίαΠεριστατικούΦόρμα δεν
περιλαμβάνεται στην περίπτωση χρήσης
ΑνάφερεΠεριστατικό
◦ Όμως ο συντονιστής χρειάζεται μία διεπαφή για να μπορεί να δει
την αναφορά και να αποστείλει την αναγνώριση!
29
ελέγχου (1)
• Τα αντικείμενα οντότητας και ορίου περιγράφουν το πεδίο
εφαρμογής και τη διεπαφή συστήματος-actor
◦ Δεν περιγράφουν όμως καθόλου το ποιες λειτουργίες χρησιμοποιούνται σε
μία περίπτωση χρήσης, τη σειρά που καλούνται κ.λπ.
◦ Το κενό αυτό –τον συντονισμό δηλαδή των αντικειμένων οντότητας και
ορίου- καλύπτουν τα αντικείμενα ελέγχου
• Τα αντικείμενα ελέγχου δεν έχουν φυσικό αντίστοιχο στην
πραγματικό κόσμο
• Τις περισσότερες φορές δημιουργούνται στην αρχή εκτέλεσης
μιας περίπτωσης χρήσης και καταστρέφονται στο τέλος της
• Είναι υπεύθυνα να συλλέγουν πληροφορίες από τα αντικείμενα
ορίου και να τις προωθούν στα αντικείμενα οντότητας
30
Προσδιορισμός αντικειμένων ελέγχου (2)
• Ευρεστικές για δημιουργία αντικειμένων ελέγχου
◦ Προσδιορίζουμε ένα αντικείμενο ελέγχου ανά περίπτωση χρήσης
◦ Στην περίπτωση χρήσης «ΔημιούργησεΤουρνουά» στη διαδικτυακή
πλατφόρμα παιχνιδιών έχουμε ένα αντικείμενο ελέγχου το
«ΔημιούργησεΤουρνουάΈλεγχος»
◦ Αν η περίπτωση χρήσης περιλαμβάνει πολλαπλούς actors,
προσδιορίζουμε ένα αντικείμενο ελέγχου ανά actor
◦ Στην περίπτωση χρήσης «ΑνάφερεΠεριστατικό» έχουμε δύο αντικείμενα
ελέγχου το «ΑνάφερεΠεριστατικόΕλεγχος» και το
«ΔιαχειρίσουΠεριστατικόΈλεγχος»
◦ Η διάρκεια ζωής ενός αντικειμένου ελέγχου είναι είτε μία
περίπτωση χρήσης είτε μία συνεδρία χρήστη
◦ Αν δεν είναι εύκολο να βρούμε την αρχή και το τέλος της ενεργοποίησης ενός
αντικειμένου ελέγχου, πιθανότατα η σχετική περίπτωση χρήσης δεν έχει
καλά ορισμένες συνθήκες εισόδου και εξόδου
31
Προσδιορισμός αντικειμένων ελέγχου (3)
• Παραδείγματα αντικειμένων ελέγχου

ΑνάφερεΠεριστατικό Διαχειρίζεται τη λειτουργία ΑνάφερεΠεριστατικό στον
Ελεγχος ΣταθμόςΔιασώστη. Δημιουργείται όταν ο Διασώστης επιλέγει το κουμπί
«ΑνάφερεΠεριστατικό». Δημιουργεί μία φόρμα
«ΦόρμαΑναφοράςΠεριστατικού» και την παρουσιάζει στον Διασώστη.
Μετά την υποβολή της φόρμας, το αντικείμενο συλλέγει από τη φόρμα
την πληροφορία, δημιουργεί μία ΑναφοράΠεριστατικού και την
προωθεί στον Συντονιστή. Κατόπιν αναμένει να ληφθεί αναγνώριση
από τον ΣταθμόςΣυντονιστή. Όταν ληφθεί, το αντικείμενο ελέγχου
δημιουργεί μία ΑναγνώρισηΠαράδοσηςΑναφοράς και την παρουσιάζει
στον διασώστη.
Διαχειρίσου Διαχειρίζεται τη λειτουργία ΑνάφερεΠεριστατικό στον
ΠεριστατικόΈλεγχος ΣταθμόςΣυντονιστή. Δημιουργείται όταν λαμβάνεται μία
ΑναφοράΠεριστατικού. Στη συνέχεια δημιουργεί μία
ΦόρμαΔημιουργίαςΠεριστατικού και την παρουσιάζει στον συντονιστή.
Όταν ο συντονιστής έχει δημιουργήσει το περιστατικό, κατανείμει
πόρους και έχει αποστείλει την αναγνώριση, το αντικείμενο ελέγχου
προωθεί την αναγνώριση στον ΣταθμόςΔιασώστη.
32
Απεικόνιση των περιπτώσεων χρήσης σε
αντικείμενα μέσω διαγραμμάτων ακολουθίας (1)
• Ένα διάγραμμα ακολουθίας δείχνει πώς η συμπεριφορά
μιας περίπτωσης χρήσης (ή σεναρίου) κατανέμεται μεταξύ
των αντικειμένων
◦ Δεν είναι κατάλληλο μέσο για επικοινωνία με τους πελάτες, διότι
περιλαμβάνουν περισσότερες σημειογραφίες που χρειάζονται
τεχνολογικό υπόβαθρο
◦ Αν υπάρχει η σχετική τεχνογνωσία στον πελάτη, τα διαγράμματα
ακολουθίας μπορούν να χρησιμοποιηθούν και να είναι ακριβέστερα
από τις περιπτώσεις χρήσης
◦ Αν δεν υπάρχει η σχετική τεχνογνωσία στον πελάτη, τα διαγράμματα
ακολουθίας χρησιμοποιούνται εσωτερικά από την ομάδα ανάπτυξης
κατά τη μετάβαση από τις προδιαγραφές απαιτήσεων στο μοντέλο
ανάλυσης
33

• Ένα διάγραμμα ακολουθίας έχει «στήλες» που
αντιστοιχούν στις οντότητες που λαμβάνουν μέρος στη
σχετική περίπτωση χρήσης
• Στη γενική περίπτωση:
◦ Η πρώτη στήλη ενός διαγράμματος ακολουθίας αντιστοιχεί στον
actor που εκκινεί την περίπτωση χρήσης
◦ Η δεύτερη στήλη αντιστοιχεί στο αντικείμενο ορίου που
χρησιμοποιεί ο actor για την εκκίνηση της περίπτωσης χρήσης
◦ Η τρίτη στήλη αντιστοιχεί στο αντικείμενο ελέγχου που θα
αποτελέσει το συνδετικό κρίκο μεταξύ αντικειμένων ορίου και
αντικειμένων οντότητας
◦ Το αντικείμενο ελέγχου μπορεί να δημιουργεί-ενεργοποιεί και άλλα
αντικείμενα ορίου, να αλληλεπιδρά με άλλα αντικείμενα ελέγχου
(εάν υπάρχουν) και να αλληλεπιδρά με αντικείμενα οντότητας
34
Παράδειγμα διαγράμματος ακολουθίας
:Tournament
:Arena :League
League Boundary
Owner
newTournament
(league)
«new»
:Create
Tournament
Control
checkMax
Tournament()
setName(name)
setMaxPlayers
(maxp)
commit() create
createTournament Tournament «new»
(name, maxp) :Tourname
(name, maxp)
nt
35

• Το προηγούμενο διάγραμμα ακολουθίας εισάγει
τρεις νέες κλάσεις:
◦ TournamentBoundary – το όριο της περίπτωσης χρήσης.
Περιλαμβάνει τις φόρμες και τα στοιχεία ελέγχου μέσω
των οποίων γίνεται η διαχείριση του τουρνουά
◦ CreateTournamentControl – το αντικείμενο ελέγχου για
την υλοποίηση της περίπτωσης χρήσης
ΔημιούργησεΤουρνουά
◦ Arena – αντικείμενο οντότητας που δεν είχε
προσδιοριστεί αρχικά.
◦ Προκύπτει από την αναγκαιότητα ύπαρξης αντικειμένου που να
διατηρεί το πλήθος των ενεργών τουρνουά
36
Παράδειγμα διαγράμματος ακολουθίας με
περισσότερα από ένα αντικείμενα ελέγχου (1/3)
37

38
39

• Στο προηγούμενο παράδειγμα εισάγεται η κλάση
Acknowledgment που δεν είχε αναδειχθεί στην πρώτη
φάση δημιουργίας των αντικειμένων
◦ Το Acknowledgment είναι διαφορετικό από το
AcknowledgmentNotice μια και το πρώτο είναι αντικείμενο
οντότητας που φέρει την πληροφορία που θα παρουσιάσει το
δεύτερο (το οποίο είναι αντικείμενο ορίου)
• Θα πρέπει επίσης να προσδιοριστεί το πληροφοριακό

περιεχόμενο της κλάσης Acknowledgment
◦ Αυτό γίνεται σε συνεργασία με τους χρήστες και τον πελάτη, και
απαιτεί την ενημέρωση των προδιαγραφών απαιτήσεων
40
Κανόνες σύνταξης διαγραμμάτων
• Η πρώτη στήλη ενός διαγράμματος ακολουθίας αντιστοιχεί στον actor
που εκκινεί την περίπτωση χρήσης
• Η δεύτερη στήλη αντιστοιχεί στο αντικείμενο ορίου που χρησιμοποιεί
ο actor για την εκκίνηση της περίπτωσης χρήσης
• Η τρίτη στήλη αντιστοιχεί στο αντικείμενο ελέγχου που θα
διαχειριστεί την περίπτωση χρήσης
• Τα αντικείμενα ελέγχου δημιουργούνται από τα αντικείμενα ορίου
που εκκινούν την περίπτωση χρήσης
• Πρόσθετα αντικείμενα ορίου δημιουργούνται από τα αντικείμενα
ελέγχου
• Τα αντικείμενα οντότητας προσπελαύνονται από τα αντικείμενα
ελέγχου και ορίου
• Τα αντικείμενα οντότητας ΠΟΤΕ δεν προσπελαύνουν αντικείμενα
ορίου και ελέγχου
◦ Με τον τρόπο αυτό καθίσταται δυνατή η επαναχρησιμοποίηση των
αντικειμένων οντότητας σε πολλαπλές περιπτώσεις χρήσης
41
Μοντελοποίηση διάδρασης μεταξύ

αντικειμένων μέσω καρτών CRC (1)
• Εναλλακτικός τρόπος για τον προσδιορισμό διαδράσεων
μεταξύ αντικειμένων
• CRC: Classes-Responsibilities-Collaborations / κλάσεις,
ευθύνες και συνεργασίες
◦ Αρχικά χρησιμοποιήθηκαν για διδασκαλία του αντικειμενοστρεφούς
μοντέλου
• Κάθε κλάση αναπαρίσταται από μία κάρτα (η κάρτα CRC)

◦ Στο πάνω μέρος αναγράφεται το όνομα της κλάσης
◦ Οι ευθύνες της κλάσης αναγράφονται στο αριστερό μέρος
◦ Οι κλάσεις που χρειάζεται για να φέρει σε πέρας τις ευθύνες της
αναγράφονται στο δεξί μέρος
42
• Παραδείγματα καρτών CRC
ΑνάφερεΠεριστατικόΕλεγχος
Ευθύνες Συνεργάτες
Συλλέγει είσοδο από τους διασώστες ΑναφοράΠεριστατικούΦόρμα
Ελέγχει την ακολουθία των φορμών ΑναφοράΠεριστατικού
κατά την αναφορά περιστατικών ΕιδοποίησηΑναγνώρισης
Ευθύνες Συνεργάτες
Διαχειρίζεται όλες τις πληροφορίες Πόρος
που σχετίζονται με ένα περιστατικό
43

• Οι κάρτες χρησιμοποιούνται σε συνεδρίες μοντελοποίησης
με ομάδες
• Στις ομάδες μετέχουν στελέχη από την ομάδα ανάπτυξης
και ειδικοί στο πεδίο της εφαρμογής, τα οποία εξετάζουν
τα σενάρια και προσδιορίζουν τις κλάσεις που
συμμετέχουν στην πραγματοποίηση του σεναρίου
• Τρόπος διεξαγωγής της συνεδρίας:
◦ Τοποθετείται μία κάρτα CRC ανά στιγμιότυπο στο τραπέζι
◦ Οι συμμετέχοντες διαπραγματεύονται τις ευθύνες του κάθε
◦ Οι στήλες των συνεργατών συμπληρώνονται καθώς προσδιορίζονται
εξαρτήσεις με άλλες κάρτες
44
Διαγράμματα ακολουθίας έναντι
καρτών CRC
• Τα διαγράμματα CRC και τα διαγράμματα
ακολουθίας εξυπηρετούν τον ίδιο στόχο
◦ Οι κάρτες CRC είναι προτιμότερο εργαλείο για χρήση από
ομάδες, κατά τη διαδικασία της εκλέπτυνσης και της
επανεξέτασης ενός μοντέλου, καθώς δημιουργούνται και
τροποποιούνται πιο εύκολα
◦ Τα διαγράμματα ακολουθίας είναι προτιμότερο εργαλείο
για εργασία από έναν μόνο προγραμματιστή ή για την
τεκμηρίωση μιας ακολουθίας διαδράσεων, καθώς
παρέχουν μεγαλύτερη ακρίβεια και έχουν πιο
συμπυκνωμένη πληροφορία
45
Προσδιορισμός συσχετίσεων (1)

• Μία συσχέτιση παρουσιάζει μία σχέση μεταξύ δύο
ή περισσοτέρων κλάσεων
• Ο προσδιορισμός τους είναι απαραίτητος γιατί:
◦ Αποσαφηνίζει το μοντέλο της ανάλυσης, κάνοντας ρητές
τις συσχετίσεις μεταξύ αντικειμένων (π.χ. μία
ΑναφοράΟεριστατικού συμπληρώνεται από τον
διασώστη ή τον συντονιστή)
◦ Επιτρέπει στην ομάδα ανάπτυξης να προσδιορίσει
οριακές περιπτώσεις (boundary cases) που έχουν να
κάνουν με τις συσχετίσεις
◦ Π.χ. οι αναφορές περιστατικών γίνονται από έναν διασώστη.
Μπορούν να γίνουν από πάνω από έναν διασώστες; Μπορούν να
γίνουν από άτομα εκτός του συστήματος (πολίτες);
46
• Κανόνες για τον προσδιορισμό συσχετίσεων
◦ Εξετάζουμε τις ρηματικές φράσεις
◦ Οι συσχετίσεις και οι ρόλοι στις συσχετίσεις πρέπει να
ονοματίζονται με ακρίβεια
◦ Αν είναι δυνατόν, χρησιμοποιούμε προσδιοριστές για να
προσδιορίσουμε τα γνωρίσματα-κλειδιά
◦ Συσχετίσεις που είναι δυνατό να συναχθούν από άλλες
συσχετίσεις απαλείφονται
◦ Δεν είναι απαραίτητο να ορίσουμε σε αυτή τη φάση την
πολλαπλότητα των συσχετίσεων
◦ Πρώτα πρέπει να οριστικοποιηθεί το σύνολο των συσχετίσεων
◦ Η υπερβολική χρήση συσχετίσεων καθιστά δυσανάγνωστο το
μοντέλο
47

• Παράδειγμα εξάλειψης πλεονάζουσας συσχέτισης
συγγραφέας έγγραφο
Διασώστης 1 * ΑναφοράΠεριστατικού
συγγράφει
1 1
αναφέρει προκαλείΔημιουργία
1 1
Οι συσχετίσεις αυτές προκύπτουν από την ανάλυση του κειμένου

της φυσικής γλώσσας
Ωστόσο ο «Διασώστης» συνδέεται άμεσα με την
«ΑναφοράΠεριστατικού» οπότε η έμμεση συσχέτιση
(προκαλείΔημιουργία) απαλείφεται.
48
• Τα περισσότερα αντικείμενα οντότητας διαθέτουν ένα
χαρακτηριστικό μοναδικού προσδιορισμού που
χρησιμοποιούν οι actors για να τα προσπελάσουν
◦ Π.χ. οι διασώστες και οι Συντονιστές έχουν αριθμό υπηρεσιακής
ταυτότητας, στα περιστατικά και τις αναφορές αποδίδονται αριθμοί
• Όταν το μοντέλο κλάσεων είναι σχετικά πλήρες, η ομάδα
ανάπτυξης πρέπει να εξετάσει πώς τα στιγμιότυπα της
κάθε κλάσης προσδιορίζονται από τους actors και σε ποια
συμφραζόμενα
◦ Π.χ. οι αριθμοί υπηρεσιακής ταυτότητας είναι μοναδικοί σε επίπεδο
περιοχής; πόλης; χώρας; ηπείρου; υφηλίου;
◦ Αν είναι μοναδικοί σε επίπεδο πόλης, πώς μπορεί το σύστημα να
εντάξει Διασώστες από περισσότερες από μία πόλεις;
49

• Η τυπική εκτέλεση του βήματος αυτού είναι για κάθε
κλάση να προσδιορίζεται η ακολουθία των συσχετίσεων
που πρέπει να διασχισθούν για να εντοπισθεί ένα
συγκεκριμένο στιγμιότυπο της κλάσης
50
Προσδιορισμός συναθροίσεων (1)
• Οι συναθροίσεις είναι ειδικοί τύποι συσχετίσεων που
δηλώνουν σχέσεις όλου-τμήματος
◦ Π.χ. ένας σταθμός πολιτικής προστασίας συντίθεται από πυροσβέστες,
πυροσβεστικά οχήματα, ασθενοφόρα και τραυματιοφορείς
◦ Μία περιφέρεις συντίθεται από νομούς, που με τη σειρά τους
απαρτίζονται από δήμους
• Υπάρχουν δύο είδη συνάθροισης:
◦ Η συνάθροιση σύνθεσης που δείχνει ότι τα τμήματα εξαρτώνται από το
όλον
◦ Π.χ. ένας δήμος νοείται μόνο ως μέρος ενός νομού
◦ Συμβολίζεται με έναν «γεμάτο» ρόμβο
◦ Η διαμοιραζόμενη συνάθροιση (ή συσσωμάτωση) όπου τα τμήματα
υπάρχουν και ανεξάρτητα από το όλον
◦ Π.χ. ένα πυροσβεστικό όχημα μπορεί να υπάρχει χωρίς τον σταθμό πολιτικής
προστασίας ή να κατανεμηθεί σε άλλον σταθμό
◦ Συμβολίζεται με έναν «κενό» ρόμβο
51

• Παράδειγμα συνάθροισης σύνθεσης και διαμοιραζόμενης
συνάθροισης
Σταθμός Πολιτικής
Περιφέρεια
Προστασίας
Νομός Πυροσβέστης Τραυματιοφορέας
Πυροσβεστικό
Ασθενοφόρο
Δήμος Όχημα
52
• Οι συναθροίσεις προκύπτουν από τα ρήματα δηλωτικά κτήσης
(«Αποτελείται από», «περιλαμβάνει» ...)
• Το αν θα έχουμε συνάθροιση σύνθεσης ή διαμοιραζόμενης
συνάθροισης εξαρτάται από τη σημασιολογία του μοντέλου
• Οι συναθροίσεις μας προσφέρουν πρόσθετη πληροφορία σε σχέση με
τις απλές συσχετίσεις
◦ Δίνουν το πώς οι σχέσεις «περιέχεσθαι» οργανώνονται σε μία ιεραρχία ή
κατευθυνόμενο γράφο
◦ Μπορούν να αξιοποιηθούν και σε επίπεδο διεπαφής χρήστη, π.χ.
παρουσιάζουμε μία δενδροειδή δομή για να ξεκινήσουμε από επίπεδο
περιφέρειας μετά να πάμε σε νομό και τελικά να εντοπίσουμε τον δήμο
• Αν δεν είναι σαφές εάν κάποια συσχέτιση είναι πράγματι όλου-
τμήματος, είναι προτιμότερο να τη μοντελοποιήσουμε ως απλή
συσχέτιση και να το επανεξετάσουμε όταν θα έχουμε κατανοήσει
πληρέστερα το πεδίο της εφαρμογής
53
Προσδιορισμός γνωρισμάτων (1)

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

που αναπαρίστανται από κλάσεις
◦ Π.χ. ο συγγραφέας μιας ΑναφοράςΠεριστατικού ΔΕΝ είναι
γνώρισμα, αλλά αναπαρίσταται μέσω μίας συσχέτισης με την κλάση
Διασώστης.
◦ Πρώτα εντοπίζουμε τις συσχετίσεις και κατόπιν προχωρούμε στον
προσδιορισμό των γνωρισμάτων
54
• Ιδιότητες των γνωρισμάτων
◦ Ένα όνομα, που θα πρέπει να είναι κατατοπιστικό και χωρίς
αμφισημίες
◦ Π.χ. μία αναφορά περιστατικού μπορεί να έχει έναν τύπο αναφοράς
(αρχική, αίτημα πόρου κ.λπ.) και έναν τύπο περιστατικού (φωτιά, τροχαίο
κ.τ.λ.). Κανένα από τα δύο δεν πρέπει να ονομαστεί τύπος.
◦ Μία σύντομη περιγραφή
◦ Ένας τύπος, που ορίζει τις παραδεκτές τιμές του γνωρίσματος.
Μπορεί να είναι ένας βασικός τύπος της UML, μία απαρίθμηση
κ.ο.κ.
55

• Τα γνωρίσματα μπορούν να προσδιοριστούν με
τις ευρεστικές του Abbott. Εξετάζονται:
◦ Ονοματική προτάσεις ακολουθούμενες από κτητικό
◦ Π.χ. «η περιγραφή του περιστατικού»
◦ Επιθετικές φράσεις
◦ Κυρίως στα Αγγλικά (π.χ. emergency description)
◦ Για τα αντικείμενα οντότητας, κάθε ιδιότητα που πρέπει
να αποθηκεύεται από το σύστημα είναι υποψήφιο
γνώρισμα
56
• Τα γνωρίσματα είναι το πιο «ασταθές» τμήμα του
μοντέλου ανάλυσης
◦ Πολύ συχνά γνωρίσματα ανακαλύπτονται και προστίθενται αργά στη
διαδικασία ανάπτυξης, κυρίως κατά την αξιολόγηση του συστήματος
από τους χρήστες
◦ Η προσθήκη γνωρισμάτων συνήθως δεν επιφέρει σημαντικές
αλλαγές στο σύστημα (εκτός αν σχετίζεται με την προσθήκη
λειτουργικότητας)
◦ Η ομάδα ανάπτυξης δεν πρέπει να δαπανά υπερβολικό χρόνο-
προσπάθεια για τον προσδιορισμό και τη λεπτομερή περιγραφή των
γνωρισμάτων που δεν είναι σημαντικά για το σύστημα
◦ Τα γνωρίσματα αυτά θα προστεθούν χωρίς ιδιαίτερο πρόβλημα στη
συνέχεια
57
Μοντελοποίηση συμπεριφοράς που εξαρτάται από

την κατάσταση του αντικειμένου (1)
• Τα διαγράμματα μηχανής κατάστασης αναπαριστούν τη
συμπεριφορά από την προοπτική ενός μοναδικού
• Η αναπαράσταση αυτή είναι χρήσιμη, καθώς εξετάζοντας
συγκεκριμένες καταστάσεις η ομάδα ανάπτυξης μπορεί να
εντοπίσει νέες συμπεριφορές – και συνακόλουθα
περιπτώσεις χρήσης που λείπουν
◦ Π.χ. εξετάζουμε τις μεταβάσεις στο διάγραμμα μηχανής κατάστασης
που προκαλούνται από ενέργειες χρήστη
◦ Για όλες πρέπει να υπάρχει αντίστοιχο βήμα σε περίπτωση χρήσης
που να προκαλεί τη μετάβαση
58
• Δεν είναι απαραίτητο να δημιουργήσουμε
διαγράμματα μηχανής κατάστασης για όλα τα
◦ Μόνο για όσα έχουν μεγάλη διάρκεια ζωής και έχουν
συμπεριφορά που εξαρτάται από την κατάστασή τους
◦ Συχνό για αντικείμενα ελέγχου
◦ Αυτά που ζουν περισσότερο από μία περίπτωση χρήσης, π.χ. το
αντικείμενο ελέγχου ενός ATM (διαφορετική λειτουργικότητα
χωρίς εισηγμένη κάρτα, με εισηγμένη κάρτα, με εισηγμένο σωστό
PIN κ.λπ.)
◦ Λιγότερο συχνό για αντικείμενα οντότητας
◦ Π.χ. ένας λογαριασμός μπορεί να είναι στην «κανονική
κατάσταση» ή «δεσμευμένος»
◦ Σχεδόν ποτέ για αντικείμενα ορίου
59

• Παράδειγμα διαγράμματος μηχανής κατάστασης
60
Μοντελοποίηση κληρονομικότητας (1)
• Η γενίκευση χρησιμοποιείται για την απαλοιφή
του πλεονασμού
◦ Αν δύο ή περισσότερες κλάσεις έχουν κοινή κατάσταση ή
συμπεριφορά οργανώνονται κάτω από μία υπερκλάση
◦ Για παράδειγμα οι Διασώστες και οι Συντονιστές είναι και οι δύο
ΥπάλληλοιΠολιτικήςΠροστασίας
ΥπάλληλοςΠολιτικήςΠροστασίας
Διασώστης Συντονιστής
61
Μοντελοποίηση κληρονομικότητας (2)

• Ευρεστικές για εντοπισμό κληρονομικότητας
◦ Όταν δύο κλάσεις διαφέρουν μόνο σε μερικά
γνωρίσματα, συσχετίσεις και λειτουργίες τότε είναι
υποψήφιες να οργανωθούν κάτω από μία υπερκλάση
◦ Τα κοινά γνωρίσματα εντάσσονται στην υπερκλάση και τα
διαφορετικά παραμένουν στις υποκλάσεις
◦ Θα πρέπει η κατάταξη αυτή να έχει και νόημα – π.χ. μπορεί το
«αυτοκίνητο», «φορτηγό» και «λεωφορείο» είναι λογικό να
οργανωθούν κάτω από υπερκλάση, αλλά η ένταξη τής κλάσης
«περιοδικό» γιατί έχει «αριθμόΚυκλοφορίας» δεν είναι λογική
◦ Όταν μία κλάση παίζει πολλαπλούς ρόλους, τότε είναι
υποψήφια να διασπαστεί σε υποκλάσεις
◦ Π.χ. μία «δοσοληψία» σε ένα ATM μπορεί να διασπαστεί σε
«κατάθεση», «ανάληψη», «ερώτηση υπολοίπου», «πληρωμή
λογαριασμού»
62
Ανασκόπηση του μοντέλου
• Το μοντέλο ανάλυσης κτίζεται επαυξητικά και
επαναληπτικά
◦ Σπάνια είναι σωστό από την πρώτη επανάληψη
◦ Π.χ. ο εντοπισμός μιας παράλειψης στην ανάλυση, θα οδηγήσει
στην προσθήκη ή στην επέκταση μιας περίπτωσης χρήσης, που με τη
σειρά της θα οδηγήσει σε εκμαίευση περισσότερων πληροφοριών
από τον χρήστη
• Το μοντέλο σταθεροποιείται όταν το πλήθος των αλλαγών
είναι μικρό και έχουν τοπική επίδραση
• Τότε το μοντέλο ανάλυσης επιθεωρείται, πρώτα από την
ομάδα ανάπτυξης και κατόπιν από την ομάδα ανάπτυξης
και τους χρήστες-πελάτες
63

• Ο στόχος της ανασκόπησης είναι να διασφαλιστεί ότι η
προδιαγραφή απαιτήσεων είναι ορθή, πλήρης, συνεπής και
απαλλαγμένη ασαφειών
• Επαληθεύεται επίσης ότι οι απαιτήσεις είναι ρεαλιστικές και
επαληθεύσιμες
• Είναι σχετικά βέβαιο ότι θα βρεθούν σφάλματα και

παραλείψεις στη συνέχεια της διαδικασίας ανάπτυξης
◦ Ο εντοπισμός των προβλημάτων όμως στο στάδιο αυτό είναι
σημαντικός, καθώς μειώνει το κόστος και τον χρόνο που απαιτείται
για την αντιμετώπισή τους σε μεταγενέστερο στάδιο
• Υπάρχουν λίστες ερωτήσεων ελέγχου για διευκόλυνση της

διαδικασίας
64
• Ερωτήσεις για τη διασφάλιση της ορθότητας του μοντέλου
◦ Είναι η ορολογία για τα αντικείμενα οντότητας κατανοητή στους
χρήστες;
◦ Οι αφηρημένες κλάσεις αντιστοιχούν σε έννοιες που χρησιμοποιούν
οι χρήστες (π.χ. «λογαριασμός» με υποκλάσεις «όψεως»
«ταμιευτηρίου»);
◦ Οι περιγραφές είναι σύμφωνες με τους ορισμούς που έχουν δώσει
οι χρήστες;
◦ Έχουν όλα τα αντικείμενα οντότητας και ορίου ονόματα που (α)
είναι ονοματικές φράσεις και (β) δίνουν το σωστό νόημα;
◦ Έχουν όλες οι περιπτώσεις χρήσης και τα αντικείμενα ελέγχου
ονόματα που (α) είναι ρηματικές φράσεις και (β) δίνουν το σωστό
νόημα;
◦ Περιγράφονται και τυγχάνουν χειρισμού όλες οι περιπτώσεις
σφαλμάτων;
65

• Ερωτήσεις για τη διασφάλιση της πληρότητας του
μοντέλου
◦ Για κάθε αντικείμενο: χρησιμοποιείται από κάποια περίπτωση
χρήσης; Σε ποιά περίπτωση χρήσης δημιουργείται; τροποποιείται;
καταστρέφεται; Μπορεί να προσπελαστεί από κάποιο αντικείμενο
ορίου;
◦ Για κάθε γνώρισμα: Πότε τίθεται η τιμή του; Πότε προσπελαύνεται;
Ποιός είναι ο τύπος του; Πρέπει να είναι προσδιοριστής (qualifier);
◦ Για κάθε συσχέτιση: πότε διασχίζεται; Γιατί επιλέχθηκε η
συγκεκριμένη πολλαπλότητα; Μπορούν να χρησιμοποιηθούν
προσδιοριστές σε συσχετίσεις ένα-προς-πολλά και πολλά-προς-
πολλά;
◦ Για κάθε αντικείμενο ελέγχου: διαθέτει τις κατάλληλες συσχετίσεις
για να προσπελάσει τα αντικείμενα που μετέχουν στην σχετική
περίπτωση χρήσης;
66
• Ερωτήσεις για τη διασφάλιση της συνέπειας του μοντέλου
◦ Υπάρχουν πολλαπλές κλάσεις ή περιπτώσεις χρήσης με το ίδιο
όνομα;
◦ Οι οντότητες (περιπτώσεις χρήσης, κλάσεις, γνωρίσματα) με
παρόμοια ονόματα αντιστοιχούν όντως σε παρόμοιες έννοιες;
◦ Υπάρχουν αντικείμενα με παρόμοια γνωρίσματα και συσχετίσεις
που δεν ανήκουν στην ίδια ιεραρχία εξειδίκευσης-γενίκευσης;
• Ερωτήσεις για τη διασφάλιση της ρεαλιστικότητας του
μοντέλου
◦ Υπάρχουν καινοτόμα χαρακτηριστικά στο σύστημα; Υπάρχουν
μελέτες ή πρωτότυπα για τη διασφάλιση ότι είναι εφικτό να
υλοποιηθούν;
◦ Είναι δυνατόν να επιτευχθούν οι απαιτήσεις σε επιδόσεις και
αξιοπιστία; Έχουν επαληθευθεί οι απαιτήσεις αυτές από
πρωτότυπα που έχουν τρέξει στο συγκεκριμένο υλικό;
67
Σύνοψη της ανάλυσης

• Η διαδικασία της ανάλυσης είναι ισχυρά επαναληπτική
◦ Τμήματα λειτουργικότητας σκιαγραφούνται και προτείνονται στον
πελάτη και τους χρήστες
◦ Οι χρήστες προσθέτουν λειτουργικότητα, κάνουν παρατηρήσεις για
την προτεινόμενη και τροποποιούν τις απαιτήσεις
◦ Η ομάδα ανάπτυξης διερευνά τις μη λειτουργικές απαιτήσεις μέσω
πρωτοτύπων και μελετών τεχνολογίας, και επίσης ελέγχει αν κάθε
απαίτηση είναι εύλογη και χρήσιμη
◦ Η επανάληψη τελειώνει όταν οι αλλαγές που προτείνονται είναι
λίγες και επουσιώδεις
• Στην αρχή, η διαδικασία εκμαίευσης απαιτήσεων μοιάζει

με διαδικασία νοητικού καταιγισμού (brainstorming)
◦ Καθώς η ανάπτυξη εξελίσσεται και οι απαιτήσεις γίνονται πιο
συγκεκριμένες, το μοντέλο ανάλυσης επεκτείνεται και τροποποιείται
ώστε να αντιμετωπισθεί η πολυπλοκότητα της πληροφορίας
68
Διάγραμμα δραστηριοτήτων ανάλυσης
Ορισμός
Ορισμός αντικειμένων
που συμμετέχουν
Ορισμός αντικειμένων Ορισμός αντικειμένων Ορισμός αντικειμένων

οντότητας ορίου ελέγχου
Ορισμός
αλληλεπιδράσεων
Ορισμός Ορισμός συμπεριφοράς

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

• Ο βασικός στόχος είναι να διατηρηθεί η συνέπεια του
μοντέλου ενώ εμπλέκονται πολλοί συμμετέχοντες επί
μακρόν
• Στο τέλος πρέπει να παραχθεί το παραδοτέο της
ανάλυσης, που πρέπει να περιγράφει πλήρως και συνεπώς
το σύστημα με κατανοητό τρόπο
• Κύριες απόψεις της διαχείρισης:
◦ Τεκμηρίωση της ανάλυσης
◦ Ανάθεση αρμοδιοτήτων
◦ Επικοινωνία στην ανάλυση
◦ Επαναληπτική εξέταση προδιαγραφών και μοντέλου
◦ Αποδοχή από τον πελάτη
70
Τεκμηρίωση της ανάλυσης
• Οι δραστηριότητες της εκμαίευσης απαιτήσεων και της
ανάλυσης τεκμηριώνονται στο έγγραφο ανάλυσης
απαιτήσεων (επόμενη διαφάνεια)
◦ Οι ενότητες 1 έως και 3.5.2 συντάσσονται στη φάση της εκμαίευσης
των απαιτήσεων
◦ Στη φάση της ανάλυσης εστιαζόμαστε στα:
◦ 3.5.3 Μοντέλα αντικειμένων: τεκμηριώνει λεπτομερώς τα αντικείμενα που
προσδιορίσαμε, τα γνωρίσματα, τις συσχετίσεις και (αρκετές από) τις
λειτουργίες τους. Αποτυπώνονται με διαγράμματα κλάσεων και περιγραφές
κειμένου
◦ 3.5.4 Δυναμικά μοντέλα: τεκμηριώνει τη συμπεριφορά του μοντέλου
αντικειμένων χρησιμοποιώντας διαγράμματα μηχανής καταστάσεων και
διαγράμματα ακολουθίας. Παρουσιάζει την ίδια πληροφορία με το μοντέλο
περιπτώσεων χρήσης, αλλά είναι ακριβέστερο –ειδικότερα για περίπλοκες
συμπεριφορές και περιπτώσεις χρήσης με πολλούς actors
◦ Το έγγραφο ανάλυσης απαιτήσεων μπορεί να αλλάξει στη συνέχεια,
πάντα όμως τηρούμε ιστορικό αλλαγών και τις προηγούμενες εκδόσεις
71

1. Εισαγωγή
2. Τρέχον σύστημα
3. Προτεινόμενο σύστημα
3.1 Επισκόπηση
3.2 Λειτουργικές απαιτήσεις
3.3 Μη λειτουργικές απαιτήσεις
3.4 Περιορισμοί (“ψεύδο-απαιτήσεις”)
3.5 Μοντέλα συστήματος
3.5.1 Σενάρια
3.5.2 Μοντέλα περιπτώσεων χρήσης
3.5.3 Μοντέλα αντικειμένων
3.5.3.1 Λεξικό δεδομένων
3.5.3.2 Διάγραμμα κλάσεων
3.5.4 Δυναμικά μοντέλα
3.5.5 Διεπαφή χρήστη
4. Γλωσσάρι
72
Ανάθεση αρμοδιοτήτων (1)
• Στην ανάλυση εμπλέκονται άτομα με διαφορετικό
υπόβαθρο και δεξιότητες
◦ Οι χρήστες παρέχουν τις γνώσεις για το πεδίο της εφαρμογής
◦ Ο πελάτης χρηματοδοτεί το έργο και συντονίζει τους χρήστες
◦ Οι αναλυτές εκμαιεύουν και τυποποιούν τη γνώση πεδίου της
εφαρμογής
◦ Τα στελέχη ανάπτυξης παρέχουν στοιχεία για την εφικτότητα και το
κόστος
◦ Ο υπεύθυνος έργου συντονίζει όλη την προσπάθεια από την πλευρά
της ομάδας ανάπτυξης
• Για τον καλύτερο συντονισμό της προσπάθειας, στα

μεγάλα έργα χρησιμοποιούνται τρεις τύποι ρόλων:
δημιουργία πληροφορίας, ολοκλήρωση και ανασκόπηση
73

• Οι τελικοί χρήστες έχουν ρόλο δημιουργίας πληροφορίας
◦ Περιγράφουν το τρέχον σύστημα το περιβάλλον του υπό ανάπτυξη
συστήματος και τη λειτουργικότητα που πρέπει να υποστηρίζει
◦ Κάθε τελικός χρήστης αντιστοιχεί σε έναν ή περισσότερους actors
και συνεισφέρει στη δημιουργία των σχετικών περιπτώσεων χρήσης
• Ο πελάτης έχει ρόλο ολοκλήρωσης

◦ Ορίζει την εμβέλεια του συστήματος, βάσεων των απαιτήσεων του
χρήστη
◦ Συνεισφέρει στην ολοκλήρωση των απαιτήσεων των χρηστών
◦ Είτε αθροιστικά, καθώς διαφορετικοί χρήστες έχουν εικόνα μόνο για ένα
τμήμα του συστήματος
◦ Είτε επιλύοντας αντιθέσεις, καθώς διαφορετικοί χρήστες μπορεί να έχουν
διαφορετική άποψη για το τι πρέπει να κάνει το σύστημα
74
• Ο αναλυτής έχει ρόλο δημιουργίας πληροφορίας
◦ Μοντελοποιεί το τρέχον σύστημα και δίνει πληροφορίες για το νέο
◦ Σε κάθε αναλυτή ανατίθεται αρχικά η λεπτομερής επεξεργασία
κάποιων περιπτώσεων χρήσης
◦ Από αυτή θα προκύψουν αντικείμενα, συσχετίσεις και γνωρίσματα
◦ Ο αναλυτής συνήθως είναι στέλεχος της ομάδας ανάπτυξης με
γνώση του πεδίου εφαρμογής
• Ο αρχιτέκτονας συστήματος έχει ρόλο ολοκλήρωσης
◦ Ενοποιεί τις περιπτώσεις χρήσης και το μοντέλο αντικειμένων από
την οπτική του συστήματος
◦ Οι διάφοροι αναλυτές ακολουθούν διαφορετικά στυλ μοντελοποίησης και
επίσης έχουν περιορισμένη οπτική, καθώς ασχολούνται με υποσύνολα
◦ Μολονότι οι αναλυτές συνεργάζονται, θα πρέπει να υπάρχει σαφής ρόλος
που θα έχει την αρμοδιότητα της ενοποίησης, θα καθορίζει τη φιλοσοφία
του συστήματος και θα εντοπίζει ελλείψεις
75

• Ο συντάκτης εγγράφων έχει ρόλο ολοκλήρωσης
◦ Συνθέτει τα κείμενα από τα επί μέρους τμήματα, ενοποιεί τη μορφή του
κειμένου, δημιουργεί πίνακες περιεχομένων κ.λπ.
• Ο διαχειριστής διαμορφώσεων (configuration manager) έχει ρόλο
ολοκλήρωσης
◦ Διατηρεί τις εκδόσεις και το ιστορικό αλλαγών
◦ Φροντίζει για τη διατήρηση της ιχνηλατησιμότητας των πληροφοριών του
εγγράφου ανάλυσης απαιτήσεων με άλλα έγγραφα (π.χ. σχεδιασμός
συστήματος)
• Ο επιθεωρητής (reviewer) είναι ένας ρόλος ολοκλήρωσης
◦ Ελέγχει το έγγραφο ανάλυσης απαιτήσεων για ορθότητα, πληρότητα,
συνέπεια και σαφήνεια
◦ Ο ρόλος μπορεί να ανατίθεται σε χρήστες, πελάτες, στελέχη της ομάδας
ανάπτυξης ή τρίτους
◦ Οι τρίτοι που δεν έχουν εμπλακεί στην ανάπτυξη είναι καλοί υποψήφιοι για
επιθεωρητές, διότι μπορούν καλύτερα να εντοπίσουν ασάφειες και περιοχές που
χρειάζονται αποσαφήνιση
76
• Το πλήθος των χρηστών και αναλυτών που χρειάζονται για
την εκμαίευση απαιτήσεων και την ανάλυση εξαρτάται
από το μέγεθος του συστήματος
◦ Πρέπει να υπάρχει πάντα ένας συντονιστής από την πλευρά του
πελάτη και ένας από την πλευρά της ομάδας ανάπτυξης
• Στο τέλος της διαδικασίας, το έγγραφο ανάλυσης

απαιτήσεων πρέπει να είναι κατανοητό από οποιοδήποτε
μεμονωμένο άτομο που διαθέτει γνώσεις στο πεδίο της
εφαρμογής
77
Η επικοινωνία στην ανάλυση (1)

• Χρειάζεται ιδιαίτερη προσοχή και επιμέλεια διότι:
◦ Οι συμμετέχοντες έχουν διαφορετικά υπόβαθρα (και διαφορετικό
λεξιλόγιο)
◦ Οι μετέχοντες από την πλευρά του χρήστη (πελάτης, χρήστες,
διοίκηση) μπορεί να έχουν διαφορετικές προσδοκίες από το
σύστημα
◦ Πιθανώς το ίδιο να ισχύει και για διαφορετικούς χρήστες σε μία ροή
εργασιών
◦ Οι ομάδες εργασίας είναι γενικά νεοσύστατες (δημιουργούνται με
την έναρξη του έργου λογισμικού) και συνεπώς απαιτείται χρόνος
μέχρι να μάθουν να δουλεύουν ως ομάδες
◦ Το σύστημα εξελίσσεται και οι προδιαγραφές αλλάζουν.
◦ Ειδικά όταν πρόκειται για εξ αρχής ανάπτυξη συστήματος, οι όροι και οι
έννοιες μπορεί να αλλάζουν ορισμό πολύ συχνά.
78
• Κανόνες για τη διαχείριση της πολυπλοκότητας και των
αντικρουόμενων απόψεων για το σύστημα
◦ Σαφής οριοθέτηση
◦ Πρέπει να ορίζονται ρόλοι (παροχή πληροφορίας, ολοκλήρωση, επιθεώρηση)
◦ Πρέπει να ορίζονται δημόσιες και ιδιωτικές περιοχές διαλόγου, ώστε ο καθένας
να λαμβάνει την πληροφορία που χρειάζεται – π.χ. ο πελάτης δεν πρέπει να έχει
πρόσβαση στην εσωτερική επικοινωνία της ομάδας ανάπτυξης, ούτε η ομάδα
ανάπτυξης να έχει πρόσβαση στις διαπραγματεύσεις με τον πελάτη
◦ Ορισμός σαφών στόχων και κριτηρίων επιτυχίας.
◦ Γίνεται σε συνεργασία από την ομάδα ανάπτυξης και τον πελάτη
◦ Πιο εύκολο να αναβληθεί για το μέλλον, αλλά η αναβολή μπορεί να οδηγήσει σε
σημαντικά προβλήματα
◦ Χρήση νοητικού καταιγισμού (brainstorming)
◦ Οι συσκέψεις όλων των συμμετεχόντων για την ταχεία δημιουργία λύσεων και
ορισμών επιλύει αρκετά προβλήματα στην επικοινωνία
◦ Το ίδιο συμβαίνει αν παραδοτέα και από τις δύο πλευρές επιθεωρούνται στην
ίδια συνεδρία
79

• Κανόνες για τη διαχείριση της πολυπλοκότητας και των
αντικρουόμενων απόψεων για το σύστημα
◦ Είναι σημαντικό να είναι όλοι ενημερωμένοι για την πιο πρόσφατη
έκδοση των απαιτήσεων
◦ Διαθεσιμότητα σε web site
◦ Ειδοποιήσεις αλλαγής στις απαιτήσεις μέσω e-mail
80
Επαναληπτική εξέταση
προδιαγραφών και μοντέλου (1)
• Η ανάλυση είναι επαναληπτική και επαυξητική διαδικασία
και λαμβάνει χώρα παράλληλα με άλλες δραστηριότητες,
π.χ. σχεδιασμός και ανάπτυξη
◦ Έτσι η χωρίς έλεγχο τροποποίηση και επέκταση της ανάλυσης
μπορεί να οδηγήσει σε χαοτικές καταστάσεις
• Οι επαναλήψεις και οι επαυξήσεις πρέπει να έχουν

προσεκτική διαχείριση και να παρακολουθούνται οι
αλλαγές από τη στιγμή που θα έχουμε την πρώτη έκδοση
• Για την καλύτερη διαχείριση, μπορεί η διαχείριση των
απαιτήσεων να οργανωθεί σε τρεις φάσεις
◦ Νοητικός καταιγισμός
◦ Παγίωση
◦ Ωρίμανση
81
• Νοητικός καταιγισμός
◦ Χρησιμοποιείται πριν ξεκινήσει οποιαδήποτε άλλη διαδικασία (σχεδιασμός,
ανάπτυξη)
◦ Οτιδήποτε μπορεί να αλλάξει (οι έννοιες του πεδίου, οι όροι που
χρησιμοποιούνται κ.τ.λ.)
◦ Βασική ιδέα είναι να παραχθούν και να αξιολογηθούν πολλές ιδέες, χωρίς
απαραίτητα να οργανωθούν
◦ Μπορούμε να έχουμε συχνές επαναλήψεις
• Παγίωση
◦ Η φάση αυτή ξεκινά όταν πελάτης και ομάδα ανάπτυξης συγκλίνουν προς
μία ιδέα, καθορίζουν τα όρια του συστήματος και συμφωνούν στην
ορολογία
◦ Η λειτουργικότητα οργανώνεται σε ομάδες περιπτώσεων χρήσης με τις
αντίστοιχες διεπαφές
◦ Οι ομάδες περιπτώσεων χρήσης ανατίθενται σε διαφορετικές ομάδες για
περαιτέρω λεπτομερειακή εργασία και εκλέπτυνση
◦ Οι επαναλήψεις είναι συχνές, αλλά οι αλλαγές είναι τοπικές
82
• Ωρίμανση (1)
◦ Στη φάση αυτή οι αλλαγές σε υψηλό επίπεδο είναι δυνατές αλλά έχουν
εκτενέστερες συνέπειες, οπότε γίνονται με προσοχή και πιο δύσκολα
◦ Κάθε ομάδα είναι υπεύθυνη για τις περιπτώσεις χρήσης και το μοντέλο
των αντικειμένων που αφορά τη λειτουργικότητα που της έχει ανατεθεί
◦ Συγκροτείται μία οριζόντια ομάδα (ομάδα αρχιτεκτονικής) -συνήθως
από αντιπρόσωπους των ομάδων- που εκτελεί την ολοκλήρωση των
απαιτήσεων (ονοματολογία, συσχετίσεις κ.λπ.)
◦ Όταν ο πελάτης υπογράψει τις απαιτήσεις, οι τροποποιήσεις πρέπει να
αντιμετωπίζουν παραλείψεις και αλλαγές, όχι ευρύτερα ζητήματα
◦ Η ομάδα αρχιτεκτονικής πρέπει να διασφαλίζει ότι δεν διακυβεύεται η
συνέπεια του μοντέλου
◦ Οι αλλαγές στις απαιτήσεις πρέπει να αντανακλώνται και στα μοντέλα
σχεδίασης
◦ Οι επαναλήψεις εκτελούνται πιο αργά και οι αλλαγές είναι τοπικές
83
• Ωριμότητα (2)
◦ Οι αλλαγές οδηγούν συνήθως σε αύξηση της λειτουργικότητας
◦ Οι αλλαγές όμως μπορεί να διακυβεύσουν την ακεραιότητα του
συστήματος, εισάγοντας ασυνέπειες, αντίγραφα πληροφοριών,
πλεοναστικές συσχετίσεις κ.λπ.
◦ Τα προβλήματα είναι αποτέλεσμα της απώλειας πληροφορίας για το
έργο
◦ Οι εξαρτήσεις μεταξύ λειτουργιών δεν καταγράφονται
◦ Πολλές υποθέσεις δεν καταγράφονται ρητά και στη συνέχεια ξεχνιόνται
◦ Συχνά οι αλλαγές γίνονται υπό την πίεση να υλοποιηθεί κάποια
λειτουργικότητα, οδηγώντας σε επιφανειακή μόνο εξέταση των
συνεπειών της αλλαγής
84
• Ωριμότητα (3)
◦ Ερωτήσεις που πρέπει να απαντηθούν πριν εισαχθεί νέα
λειτουργικότητα:
◦ Ζητήθηκαν από τον πελάτη;
◦ Είναι απαραίτητες ή μικροπροσθήκες;
◦ Μήπως είναι σκόπιμο να υλοποιηθούν ως ένα βοηθητικό πρόγραμμα αντί
να ενσωματωθούν στο βασικό σύστημα
◦ Π.χ. προετοιμασία δεδομένων για εισαγωγή στο σύστημα
◦ Πρόκειται για βασικές απαιτήσεις ή προαιρετική λειτουργικότητα;
◦ Ποιές είναι οι επιπτώσεις των αλλαγών στις υπάρχουσες λειτουργικότητες
αναφορικά με τη συνέπεια, τη διεπαφή και την αξιοπιστία;
◦ Όταν οι αλλαγές είναι απαραίτητες:
◦ Ο πελάτης και η ομάδα ανάπτυξης ορίζουν την εμβέλεια της αλλαγής, το
επιθυμητό αποτέλεσμα και τροποποιούν το μοντέλο ανάλυσης
◦ Ο ορισμός της νέας λειτουργικότητας είναι πιο εύκολος, μια και υπάρχει
ήδη το πλήρες μοντέλο ανάλυσης (π.χ. έννοιες, ορολογία, πιθανόν
κάποιες κλάσεις), η υλοποίηση ωστόσο είναι πιο δύσκολη
85
Υπογραφή των απαιτήσεων από

τον πελάτη (1)
• Η υπογραφή των απαιτήσεων (όπως περιγράφονται στο
έγγραφο ανάλυσης απαιτήσεων) από τον πελάτη
σηματοδοτεί την αποδοχή τους
• Ο πελάτης και η ομάδα ανάπτυξης συμφωνούν στα
ακόλουθα:
◦ Στο γενικό μοντέλο του συστήματος
◦ Στη λειτουργικότητα και στα χαρακτηριστικά του συστήματος
◦ Σε μία λίστα προτεραιοτήτων
◦ Σε μία διαδικασία αναθεώρησης
◦ Σε μία λίστα κριτηρίων για την αποδοχή ή όχι του συστήματος
◦ Στο χρονοδιάγραμμα και τον προϋπολογισμό
86
Υπογραφή των απαιτήσεων από τον
πελάτη (2)
• Η ανάθεση προτεραιοτήτων είναι σημαντική
◦ Επιτρέπει τον διαχωρισμό των ουσιωδών λειτουργικών από τις
λιγότερο σημαντικές
◦ Επιτρέπει την αυξητική παράδοση του συστήματος
◦ Υψηλή προτεραιότητα: στην επόμενη έκδοση
◦ Μεσαία προτεραιότητα: όχι στην επόμενη έκδοση, σε μεταγενέστερη
◦ Χαμηλή προτεραιότητα: αν το επιτρέπουν οι πόροι, σε κάποια (αρκετά)
μεταγενέστερη έκδοση
◦ Μερικές φορές η εκτίμηση του κόστους αλλάζει τις προτεραιότητες!
◦ Υπάρχουν και άλλες κλίμακες προτεραιοτήτων
◦ Ουσιώδης – το σύστημα δεν είναι αποδεκτό χωρίς αυτή τη λειτουργικότητα
◦ Υπό συνθήκη – θα βελτίωνε το προϊόν, αλλά το σύστημα είναι αποδεκτό και
χωρίς αυτή τη λειτουργικότητα
◦ Προαιρετική – μπορεί να αξίζει τον κόπο ή όχι
87

πελάτη (3)
• Μετά την «οριστικοποίηση» των απαιτήσεων εκτιμάται με
μεγαλύτερη λεπτομέρεια το κόστος του συστήματος και το
χρονοδιάγραμμα
◦ Αλλαγές μπορούν να γίνουν στη συνέχεια (λόγω παραλείψεων,
σφαλμάτων, αλλαγών στο περιβάλλον ή στην πολιτική του
οργανισμού), αλλά μόνο μέσα από τυπική διαδικασία αναθεώρησης
◦ Η διαδικασία δεν χρειάζεται να είναι δύσκαμπτη ή γραφειοκρατική
◦ Αρκεί να διατηρεί τη συνέπεια του μοντέλου, να παρακολουθεί την
υλοποίηση των αλλαγών και να διαχέει την πληροφορία στην ομάδα
ανάπτυξης
88
Υπογραφή των απαιτήσεων από τον πελάτη (4) –
παράδειγμα διαδικασίας αναθεώρησης
89

πελάτη (5)
• Πριν την υπογραφή, αναθεωρούνται τα κριτήρια αποδοχής
◦ Έχουν διατυπωθεί με τη μορφή λειτουργικών και μη λειτουργικών
απαιτήσεων αλλά εδώ συνοψίζονται και επικαιροποιούνται
• Πριν την υπογραφή, αναθεωρούνται χρονοδιάγραμμα και

προϋπολογισμός
◦ Με βάση τις «τελικές» απαιτήσεις, τις προτεραιότητες, τα κριτήρια
αποδοχής
• Θεωρείται ότι η αποδοχή του εγγράφου ανάλυσης

απαιτήσεων είναι η πιο σημαντική αποδοχή εγγράφου
◦ Διότι από αυτό εξαρτώνται πολλές δραστηριότητες
90
ENGINEERING)
Σχεδιασμός Συστήματος
Εισαγωγή (1)
• Η διαδικασία του σχεδιασμού συστήματος μετασχηματίζει το
μοντέλο ανάλυσης σε μοντέλου σχεδιασμού συστήματος
• Η ομάδα ανάπτυξης:
◦ Ορίζει τους σχεδιαστικούς στόχους του έργου
◦ Αποσυνθέτει το σύστημα σε μικρότερα υποσυστήματα με στόχο κάθε
υποσύστημα να μπορεί να υλοποιηθεί από μία ομάδα
◦ Επίσης επιλέγονται στρατηγικές για:
◦ την ανάπτυξη του συστήματος (π.χ. στρατηγική υλικού-λογισμικού)
◦ τη διαχείριση των μόνιμα αποθηκευόμενων δεδομένων
◦ τη συνολική ροή ελέγχου
◦ Την πολιτική ελέγχου πρόσβασης
◦ Το χειρισμό των οριακών περιπτώσεων
• Το αποτέλεσμα είναι ένα μοντέλο που περιλαμβάνει την
αποσύνθεση σε υποσυστήματα και μία σαφή περιγραφή των
στρατηγικών
2
• Ο σχεδιασμός συστήματος δεν είναι αλγοριθμική διαδικασία

◦ Χρειάζεται να βρεθεί η «χρυσή τομή» σε πολλές αντικρουόμενες απαιτήσεις και
να υπάρξει εξισορρόπηση στις απαιτήσεις
Χαμηλό κόστος
Αυξημένη παραγωγικότητα Λειτουργικότητα
Συμβατότητα με προηγούμενες Αποδοτικότη- Φιλικότητα
εκδόσεις τα εκτέλεσης Χρηστικότητα
Ιχνηλασιμότητα απαιτήσεων Ευκολία εκμάθησης
Ταχεία ανάπτυξη Αξιοπιστία Ανοχή σε σφάλματα
Ευελιξία Ευρωστία
Μεταφερσιμότητα,
Πελάτης τεκμηρίωση
Ελάχιστα σφάλματα Τελικός
Τροποποίησομότητα, αναγνωσιμότητα χρήστης
επαναχρησιμοποιησιμότητα,
προσαρμοστικότητα, καλά
Ορισμένες διεπαφές Ομάδα ανάπτυξης-
συντήρησης
3
διαθεσιμότητα
- Δυνατότητα
διαχείρισης
+
-
ικανότητα -
κλιμάκωσης
-
- - -
Απόδοση
- - -
- ασφάλεια
-
- +
μεταφερσιμότητα
+
+ δυνατότητα
συντήρησης
Ευελιξία
4
• Ο σχεδιασμός συστήματος δεν είναι αλγοριθμική
διαδικασία
◦ Η διαδικασία με τη σειρά της σε ένα πλήθος δραστηριοτήτων που
κάθε μία να εξετάζει τμήμα της αποσύνθεσης του συστήματος
◦ Προσδιορισμός σχεδιαστικών στόχων: Η ομάδα ανάπτυξης προσδιορίζει
τα χαρακτηριστικά του συστήματος που θα αναπτυχθεί και αναθέτει
προτεραιότητες σ’ αυτά
◦ Δημιουργία της αρχικής αποσύνθεσης του συστήματος: το σύστημα
αποσυντίθεται σε μικρότερα τμήματα με βάση τις περιπτώσεις χρήσης και
το μοντέλο ανάλυσης. Υπάρχουν τυποποιημένα μοντέλα αρχιτεκτονικής
που μπορούν να χρησιμοποιηθούν ως αφετηρίες.
◦ Εκλέπτυνση της αποσύνθεσης σε υποσυστήματα έως ότου
ικανοποιηθούν οι σχεδιαστικοί στόχοι: Η αρχική αποσύνθεση
πιθανότατα δεν θα ικανοποιεί τους σχεδιαστικούς στόχους, οπότε το
μοντέλο εκλεπτύνεται και τροποποιείται μέχρι να επιτευχθεί το σύνολο
των στόχων
Επισκόπηση του σχεδιασμού

συστήματος (1)
• Η διαδικασία της ανάλυσης παράγει ένα μοντέλο που
περιλαμβάνει:
◦ Ένα σύνολο από μη λειτουργικές προδιαγραφές και περιορισμούς
◦ Ένα μοντέλο περιπτώσεων χρήσης, που περιγράφει τη λειτουργικότητα
του συστήματος από την πλευρά του actor
◦ Ένα μοντέλο αντικειμένων που περιγράφει τις οντότητες που
διαχειρίζεται το σύστημα
◦ Ένα διάγραμμα ακολουθίας για κάθε περίπτωση χρήσης, που δείχνει την
αλληλεπίδραση μεταξύ των αντικειμένων που συμμετέχουν στην
• Περιγράφει το σύστημα από την οπτική του actor και
χρησιμοποιείται για επικοινωνία ομάδας ανάπτυξης-πελάτη
• ... αλλά δεν περιέχει πληροφορίες για την εσωτερική δομή
του συστήματος, το λογισμικό, τη διαμόρφωση και γενικά το
πώς θα υλοποιηθεί το σύστημα
6
• Ο σχεδιασμός του συστήματος είναι το πρώτο βήμα προς
αυτή την κατεύθυνση και καταλήγει στα εξής
αποτελέσματα:
◦ Σχεδιαστικοί στόχοι, που δίνουν τα ποιοτικά χαρακτηριστικά του
συστήματος που πρέπει να λαμβάνει υπ’ όψιν η ομάδα ανάπτυξης
κατά την υλοποίηση
◦ Αρχιτεκτονική λογισμικού, που περιγράφει την αποσύνθεση του
συστήματος σε υποσυστήματα
◦ Ευθύνες, εξαρτήσεις μεταξύ των αντικειμένων, ανάθεση
υποσυστημάτων σε υλικό και μείζονες αποφάσεις πολιτικής, όπως
ροή ελέγχου, έλεγχος πρόσβασης και αποθήκευση δεδομένων
◦ Οριακές περιπτώσεις χρήσης, που περιγράφουν τη διαμόρφωση του
συστήματος, την εκκίνηση, τον τερματισμό και τον χειρισμό
εξαιρέσεων

• Οι σχεδιαστικοί στόχοι παράγονται από της μη
λειτουργικές απαιτήσεις
◦ Βάσει αυτών λαμβάνονται οι αποφάσεις όταν χρειάζονται να
υπάρχει εξισορρόπηση μεταξύ των διαφόρων παραμέτρων
• Η αποσύνθεση σε υποσυστήματα είναι το κύριο μέρος του
σχεδιασμού συστήματος
◦ Η ομάδα ανάπτυξης αποσυνθέτει το σύστημα σε διαχειρίσιμες
ενότητες για να αντιμετωπίσει την πολυπλοκότητα
◦ Κάθε υποσύστημα ανατίθεται σε μία ομάδα και υλοποιείται αυτόνομα
◦ Για να είναι όμως αυτό δυνατό, πρέπει κατά την αποσύνθεση να
αντιμετωπιστούν ζητήματα εμβέλειας συστήματος
• Στη συνέχεια θα αναλύσουμε την αποσύνθεση του
συστήματος, θα παρουσιάσουμε αρχιτεκτονικά μοντέλα
και θα δούμε πώς εκλεπτύνεται η αποσύνθεση για να
επιτευχθούν οι σχεδιαστικοί στόχοι
8
Ο σχεδιασμός και οι άλλες δραστηριότητες ανάπτυξης
Ανάλυση
: μοντέλο αντικειμένων
ανάλυσης
Σχεδιασμός συστήματος
: σχεδιαστικοί στόχοι
: αποσύνθεση σε
υποσυστήματα
Σχεδιασμός αντικειμένων
: μοντέλο σχεδιασμού
Διάγραμμα δραστηριότητας UML 9
Οι έννοιες του σχεδιασμού

• Σχέση υποσυστήματος και κλάσεων
◦ Πώς οργανώνονται οι κλάσεις σε υποσυστήματα;
• Διεπαφή των υποσυστημάτων και υπηρεσίες
◦ Τα υποσυστήματα ορίζονται βάσει των υπηρεσιών που προσφέρουν
◦ Μία υπηρεσία είναι ένα σύνολο σχετιζόμενων λειτουργιών που
υπηρετούν έναν κοινό στόχο
• Σύζευξη (coupling) και συνεκτικότητα (cohesion)
◦ Σύζευξη: μέτρο της εξάρτησης μεταξύ δύο υποσυστημάτων
◦ Συνεκτικότητα: μέτρο της εξάρτησης των κλάσεων εντός ενός
υποσυστήματος
• Διαστρωμάτωση (layering) και διαμέριση (partitioning)
◦ Διαστρωμάτωση: διάταξη των υποσυστημάτων σε ιεραρχική δομή
με τα χαμηλότερα στρώματα να παρέχουν υπηρεσίες στα ανώτερα
◦ Διαμέριση: διάταξη των υποσυστημάτων ως ομότιμες ενότητες που
η κάθε μία παρέχει υπηρεσίες στις άλλες
10
Υποσυστήματα και κλάσεις (1)
• Ένα υποσύστημα είναι ένα αντικαταστάσιμο τμήμα του
συστήματος με καλά καθορισμένες διεπαφές που
ενθυλακώνει την κατάσταση και τη συμπεριφορά των
κλάσεων που περιέχει
◦ Παραδείγματα: μία βάση δεδομένων ή ένα σύστημα αρχείων
• Συνήθως ένα υποσύστημα αντιστοιχεί σε εργασία που
μπορεί να εκτελέσει ένας προγραμματιστής ή μία ομάδα
προγραμματιστών
• Η αποσύνθεση σε υποσυστήματα (εφ’ όσον έχει γίνει
σωστά!) επιτρέπει την παράλληλη ανάπτυξη με μικρές
ανάγκες για επικοινωνία
• Αν κάποιο υποσύστημα είναι ιδιαίτερα μεγάλο-
πολύπλοκο, εφαρμόζουμε αναδρομικά την αποσύνθεση
11

Σύστημα Τμήμα
* *
Κλάση Υποσύστημα
Σχέση συστήματος-υποσυστημάτων-κλάσεων με όρους

διαγράμματος κλάσεων UML
12
• Παράδειγμα: Στο σύστημα αναφοράς περιστατικών θα
μπορούσαμε να διακρίνουμε τα εξής υποσυστήματα:
◦ ΔιεπαφήΣυντονιστή
◦ ΔιεπαφήΔιασώστη
◦ ΔιαχείρισηΠεριστατικών (δημιουργία, τροποποίηση, αποθήκευση,
ανάκτηση περιστατικών)
◦ ΔιαχείρισηΠόρων (παρακολούθηση διαθέσιμων πόρων, π.χ.
ασθενοφόρα, τραυματιοφορείς)
◦ ΔιαχείρισηΧαρτών (απεικόνιση χαρτών και τοποθεσιών)
◦ Ειδοποιήσεις (επικοινωνία μεταξύ διασώστη και συντονιστή)
13

• Τα υποσυστήματα μπορούν να απεικονίζονται σε διαγράμματα
συνιστωσών (component diagrams) της UML
ΔιεπαφήΔιασώστη ΔιεπαφήΣυντονιστή
ΔιαχείρισηΧαρτών ΔιαχείρισηΠεριστατικών
Ειδοποιήσεις ΔιαχείρισηΠόρων
Συνιστώσα (component) Εξάρτηση

14
• Δύο είδη συνιστωσών:
◦ Φυσικές συνιστώσες: συγκεκριμένα μηχανήματα π.χ. εξυπηρέτης βάσεων
δεδομένων
◦ Λογικές συνιστώσες: δεν αντιστοιχούν σε συγκεκριμένα φυσικά
αντικείμενα, π.χ. η ΔιαχείρισηΠεριστατικών ή οι Ειδοποιήσεις
• Σε κάποιες γλώσσες προγραμματισμού υπάρχουν δομές που
επιτρέπουν την οργάνωση κλάσεων σε λογικές συνιστώσες
◦ Π.χ. package στη Java, module στη Modula
• Άλλες γλώσσες, όπως η C δεν έχουν αντίστοιχη έννοια
◦ Οι προγραμματιστές μπορούν να προσομοιώσουν την έννοια της
συνιστώσας, π.χ. οργανώνοντας τον κώδικα της κάθε συνιστώσας σε
διαφορετικό κατάλογο
◦ Η C++ έχει την έννοια του namespace που μπορεί να χρησιμοποιηθεί για
οργάνωση κώδικα
• Η υποστήριξη ή όχι από τη γλώσσα προγραμματισμού είναι αδιάφορη
σε ό,τι αφορά τη διαδικασία αποσύνθεσης
15
Υπηρεσίες και διεπαφές υποσυστημάτων (1)

• Ένα υποσύστημα χαρακτηρίζεται από τις υπηρεσίες που
προσφέρει σε άλλα υποσυστήματα
• Μία υπηρεσία είναι ένα σύνολο από σχετιζόμενες
λειτουργίες που υπηρετούν έναν κοινό στόχο
◦ Π.χ. Ένα υποσύστημα ειδοποιήσεων δίνει τη δυνατότητα να
δημιουργούνται/καταστρέφονται κανάλια ειδοποιήσεων, να
αποστέλλονται ειδοποιήσεις, να γίνεται εγγραφή/απεγγραφή σε ένα
κανάλι, να γίνεται αναζήτηση καναλιών
• Το σύνολο των λειτουργιών ενός υποσυστήματος που είναι
διαθέσιμο σε άλλα υποσυστήματα αποτελούν τη διεπαφή
του υποσυστήματος
◦ Περιλαμβάνει το όνομα των λειτουργιών, τις παραμέτρους τους και
τους τύπους δεδομένων που επιστρέφουν
16
Υπηρεσίες και διεπαφές υποσυστημάτων (2)
• Ο σχεδιασμός του συστήματος εστιάζει στον να οριστούν
οι υπηρεσίες που παρέχονται από κάθε υποσύστημα,
απαριθμώντας τις λειτουργίες, τις παραμέτρους και τη
συμπεριφορά τους, σε υψηλό επίπεδο
• Στον σχεδιασμό των αντικειμένων η εστίαση μετατοπίζεται
στην προγραμματιστική διεπαφή εφαρμογών (application
programming interface – API), η οποία εκλεπτύνει και
επεκτείνει τη διεπαφή των υποσυστημάτων
◦ Η προγραμματιστική διεπαφή εφαρμογών επίσης περιλαμβάνει τον
τύπο των παραμέτρων και τον τύπο που επιστρέφει η κάθε
λειτουργία
17
Υπηρεσίες και διεπαφές

υποσυστημάτων (3)
• Η UML παρέχει ξεχωριστό συμβολισμό για την αναπαράσταση
των διεπαφών
◦ Η προσφορά διεπαφής συμβολίζεται ως
και επιγράφεται με το όνομα της διεπαφής
◦ Η χρήση διεπαφής συμβολίζεται ως
◦ Η εξάρτηση μεταξύ δύο συνιστωσών ανάγεται σε ένα ζεύγος προσφοράς-
χρήσης διεπαφής
ΥπηρεσίαΕνημέρωσηςΠόρων
ΔιεπαφήΔιασώστη
ΔιαχείρισηΠόρων
ΥπηρεσίαΚατανομήςΠόρων
ΔιεπαφήΣυντονιστή
18
Υπηρεσίες και διεπαφές
υποσυστημάτων (4)
• Ο προσδιορισμός των διεπαφών και των χρήσεων ξεκινά όταν η
αποσύνθεση σε υποσυστήματα είναι σχετικά σταθερή
◦ Πρακτικά τότε αλλάζουμε την εστίαση της διαδικασίας από τον ορισμό των
υποσυστημάτων στον ορισμό των διεπαφών
◦ Πριν από αυτό το σημείο, χρησιμοποιούμε τον συμβολισμό με τα βέλη για να
δείξουμε γενικές εξαρτήσεις
• Ο ορισμός του υποσυστήματος με όρους των υπηρεσιών που
παρέχει μας βοηθά να επικεντρωθούμε στη διεπαφή του και όχι
στον τρόπο υλοποίησης
◦ Στον ορισμό της διεπαφής πρέπει να προσπαθούμε να «αποκαλύπτουμε» όσο
το δυνατόν λιγότερα για την υλοποίηση
◦ Π.χ. δεν χρειάζεται να αποκαλύπτεται αν μία δυναμική δομή υλοποιείται με
συνδεδεμένη λίστα, πίνακα ή πίνακα κερματισμού
◦ Αποκάλυψη: π.χ. παροχή λειτουργίας setHashField(fieldName);
◦ Μην αποκαλύπτοντας την υλοποίηση, μπορούμε να την αλλάξουμε χωρίς να
επηρεάζονται όσοι χρησιμοποιούν τη διεπαφή
19
Σύζευξη (1)
• Η σύζευξη αφορά το πλήθος των εξαρτήσεων μεταξύ δύο
◦ Επιθυμητή: χαλαρή σύζευξη  τα υποσυστήματα είναι σχετικά
ανεξάρτητα και αλλαγές στο ένα δεν επηρεάζουν το άλλο
◦ Μη επιθυμητή: ισχυρή σύζευξη  τα υποσυστήματα είναι
εξαρτημένα μεταξύ τους
◦ Έστω το σύστημα διαχείρισης περιστατικών
◦ Αποφασίζουμε ότι τα δεδομένα θα αποθηκεύονται σε σχεσιακή
βάση δεδομένων και δημιουργούμε ένα υποσύστημα
ΒάσηΔεδομένων
◦ Ο αρχικός σχεδιασμός του υποσυστήματος ΒάσηΔεδομένων είναι να
επικοινωνούν με αυτό τα υπόλοιπα υποσυστήματα μέσω εντολών σε
SQL
20
Σύζευξη (2)
ΔιαχείρισηΧαρτών ΔιαχείρισηΠόρων ΔιαχείρισηΠεριστατικών
ΒάσηΔεδομένων
• Ο σχεδιασμός αυτός έχει υψηλή σύζευξη μεταξύ του

υποσυστήματος ΒάσηΔεδομένων και των τριών υποσυστημάτων
που το χρησιμοποιούν
◦ Αν γίνει αλλαγή στο υποσύστημα ΒάσηΔεδομένων (π.χ. από σχεσιακή βάση
σε βάση XML) πρέπει να αλλάξουν και τα τρία υποσυστήματα
21
Σύζευξη (3)
• Μπορούμε να μειώσουμε την εξάρτηση μεταξύ των τριών
υποσυστημάτων και του υποσυστήματος της βάσης δεδομένων
εισάγοντας ένα ενδιάμεσο υποσύστημα ΔιαχείρισηΑποθήκευσης
ΔιαχείρισηΧαρτών ΔιαχείρισηΠόρων ΔιαχείρισηΠεριστατικών
ΔιαχείρισηΑποθήκευσης
ΒάσηΔεδομένων 22
Σύζευξη (4)
• Στην εναλλακτική σχεδίαση, η αλλαγή της βάσης
δεδομένων επηρεάζει μόνο το υποσύστημα
ΔιαχείρισηΑποθήκευσης
• Η μείωση της σύζευξης είναι επιθυμητή, όμως δεν είναι

αυτοσκοπός
◦ Στο παράδειγμα, με την εισαγωγή ενός πρόσθετου στρώματος
μειώσαμε μεν τη σύζευξη, αυξήσαμε όμως τη δουλειά που πρέπει
να γίνει και εισάγαμε επιβάρυνση κατά την εκτέλεση
◦ Τα σημεία που είναι πιο πιθανό να αλλάξουν είναι αυτά στα οποία
θα εστιάσουμε για τη μείωση της σύζευξης
23
Σύζευξη (5) - Τύποι σύζευξης

• Σύζευξη περιεχομένου (content coupling): μία συνιστώσα
Α βασίζεται στην εσωτερική δομή ή λειτουργία της
συνιστώσα Β. Έτσι, οι αλλαγές στη δομή ή τη λειτουργία
της Β οδηγούν αναπόφευκτα σε αλλαγές στην Α.
◦ Π.χ. η συνιστώσα ΔιαχείρισηΠελατών βασίζεται στη μεταβλητή head
της συνιστώσας ΑποθήκευσηΠελατών
• Σύζευξη κοινών δεδομένων (common coupling): οι
συνιστώσες μοιράζονται έναν κοινό πόρο, π.χ. μία
καθολική μεταβλητή ή μία περιοχή μνήμης. Αλλαγές στον
πόρο οδηγούν σε αλλαγές σε όλες τις συνιστώσες
◦ Π.χ. η μεταβλητή φθηνότερηΠροσφορά που μπορεί να αλλάξει από
πραγματικός σε κλάση/δομή {amount, currency}
24
• Εξωτερική σύζευξη (external coupling): δύο συνιστώσες
μοιράζονται μία εξωτερικά καθοριζόμενη μορφή
δεδομένων, πρωτόκολλο επικοινωνίας κ.ά.
◦ Π.χ. η μία συνιστώσα γράφει δεδομένα σε ένα αρχείο με μία
συγκεκριμένη μορφή και η άλλη συνιστώσα διαβάζει το αρχείο
• Σύζευξη ελέγχου (control coupling): η μία συνιστώσα
ελέγχει τη δραστηριότητα της άλλης
◦ π.χ. μεταβιβάζοντας μία ένδειξη (flag) του τι να κάνει:
// συνιστώσα A
function do(what) {
if (what == 1) do_something;
else if (what == 2) do_something_quite_different;
}
// συνιστώσα B
A.do(1);
25

• Σύζευξη δομής δεδομένων (data structure coupling ή
stamp coupling). Εμφανίζονται σε περιπτώσεις όπου
έχουμε μία δομή δεδομένων και οι συνιστώσες Α, Β, Γ...
χρησιμοποιούν μόνο ένα τμήμα αυτής.
◦ Τότε, η τροποποίηση της δομής μπορεί να οδηγήσει σε αλλαγές σε
όλα τα τμήματα αντί μόνο σε αυτά που χρησιμοποιούν τα κομμάτια
που άλλαξαν.
◦ Π.χ. μεταβιβάζουμε μία ολόκληρη δομή σε μία συνάρτηση που
απλώς διαβάζει ένα πεδίο της δομής:
struct employee {int age; double salary;}
int age_range(employee e) {
if (e.age < 30) return 1;
else if (e.age < 45) return 2;
else return 3;
}
Τι συμβαίνει αν αλλάξουμε το age σε date_of_birth;
26
• Αποδεκτοί τύποι σύζευξης:
• Σύζευξη δεδομένων (data coupling). Όταν οι συνιστώσες

ανταλλάσσουν δεδομένα μέσω π.χ. παραμέτρων. Κάθε
δεδομένο είναι στοιχειώδες και τα ανταλλασσόμενα
δεδομένα είναι τα μόνα που πρέπει να μοιράζονται
◦ Π.χ. B.add(2, 4); // στη συνιστώσα Α
• Σύζευξη μηνυμάτων (message coupling). Οι συνιστώσες
επικοινωνούν μόνο μέσω μηνυμάτων χωρίς παραμέτρους
(οι καλούμενες λειτουργίες δεν έχουν παραμέτρους). Η
κάθε μία βασίζεται μόνο στη δημόσια διεπαφή της άλλης.
• Καμία σύζευξη (no coupling). Οι συνιστώσες δεν
επικοινωνούν καθόλου μεταξύ τους
27
Σύζευξη (8) - Η κλίμακα της σύζευξης

6. Σύζευξη δεδομένων Χαλαρή ή χαμηλή
5. Σύζευξη δομής δεδομένων Πιο επιθυμητή
4. Σύζευξη ελέγχου
3. Εξωτερική σύζευξη
2. σύζευξη κοινών δεδομένων Λιγότερο επιθυμητή
1. Σύζευξη περιεχομένου Υψηλή

28
Συνεκτικότητα (1)
• Η συνεκτικότητα είναι μία μετρική των εξαρτήσεων εντός
ενός υποσυστήματος
◦ Επιθυμητή: Υψηλή συνεκτικότητα  το υποσύστημα περιέχει πολλά
αντικείμενα που σχετίζονται μεταξύ τους και εκτελούν παρόμοιες
λειτουργίες
◦ Μη επιθυμητή: Χαμηλή συνεκτικότητα  το υποσύστημα περιέχει
αντικείμενα που δεν σχετίζονται μεταξύ τους
◦ Το υποσύστημα μάλλον έχει πολλές μη σχετιζόμενες αρμοδιότητες
◦ Έστω ένα σύστημα για διαχείριση του σχεδιασμού λογισμικού
◦ Σε σχέση με τα ζητήματα σχεδιασμού, καταγράφουμε σχεδιαστικά
προβλήματα, τις εναλλακτικές επιλογές που έχουμε, τα κριτήρια
αξιολόγησης και τις αποφάσεις
◦ Για κάθε απόφαση, δημιουργούμε μία εργασία, που μπορεί να
αποσυντίθεται σε υπο-εργασίες ή δραστηριότητες
29
• Διάγραμμα κλάσεων του συστήματος
αποτιμά
Κριτήριο ΕναλλακτικήΕπιλογή
* *
*
λύνεταιΜε
βασίζεταιΣε
ΣχεδιαστικόΖήτημα
επιλέγεταιΝαΕπιλυθεί Απόφαση
υπο-εργασία
*
υποεργασίες
υλοποιείταιΑπό
30
• Αρχική επιλογή: το σύστημα είναι μικρό, ας γίνει ένα υποσύστημα
ΥποσύστημαΣχεδιασμού
αποτιμά
* *
*
λύνεταιΜε
Υπο-εργασία
*
31
• Όχι καλή επιλογή!
• Το υποσύστημα πρακτικά χωρίζεται σε δύο υπογράφους
όπου:
◦ Ο κάθε υπογράφος είναι αρκετά «πυκνά» συνδεδεμένος
◦ Οι δύο υπογράφοι έχουν μία μόνο σύνδεση μεταξύ τους
• Δημιουργούμε ένα υποσύστημα ΔιαχείρισηΣυλλογιστικής
◦ ΣχεδιαστικόΖήτημα, ΕναλλακτικήΕπιλογή, Κριτήριο, Απόφαση
• Και ένα υποσύστημα ΔιαχείρισηΕργασιών
◦ Εργασία, Υπο-εργασία και Δραστηριότητα
• Κάθε υποσύστημα έχει υψηλότερη συνεκτικότητα από το
αρχικό
◦ Μπορούμε να χρησιμοποιήσουμε το κάθε τμήμα αυτόνομα, π.χ. αν
χρειαζόμαστε μόνο τη διαχείριση εργασιών
◦ Κάθε τμήμα είναι μικρότερο σε μέγεθος, μπορεί να ανατεθεί σε έναν
μόνο προγραμματιστή
32
ΔιαχείρισηΣυλλογιστικής
αποτιμά
* *
*
λύνεταιΜε
ΔιαχείρισηΕργασιών
Υπο-εργασία
*
33
• Λειτουργική συνεκτικότητα (functional cohesion): Επιτυγχάνεται
όταν η συνιστώσα εκτελεί ένα μοναδικό είδος υπολογισμού και
επιστρέφει αποτέλεσμα, χωρίς πλευρικά αποτελέσματα (side
effects)
◦ Κάθε στοιχείο επεξεργασίας της συνιστώσας είναι απαραίτητο για την εκτέλεση της
λειτουργίας
◦ Τυπικά, η είσοδος στις συνιστώσες με λειτουργική συνεκτικότητα είναι παράμετροι
λειτουργιών, αλλά μπορεί να είναι και αρχεία ή άλλες ροές δεδομένων
◦ Το αποτέλεσμα που επιστρέφεται πρέπει να είναι το μοναδικό στοιχείο που
επηρεάζει τους υπολογισμούς στη συνέχεια
◦ Συνιστώσες που ενημερώνουν βάσεις δεδομένων ή προτρέπουν τον χρήστη για
είσοδο δεν είναι λειτουργικά συνεκτικές διότι έχουν πλευρικά αποτελέσματα
(αλλάζουν την κατάσταση της βάσης δεδομένων και έχουν έξοδο προς τον χρήστη)
◦ Οι λειτουργικά συνεκτικές συνιστώσες βρίσκονται συνήθως σε χαμηλά στρώματα
στην ιεραρχία αποσύνθεσης
◦ Παραδείγματα λειτουργικά συνεκτικών συνιστωσών: ανάγνωσηΕγγραφής,
εύρεσηΘέσηςΕπιβάτηΠτήσης, υπολογισμόςΣυνημιτόνου
34
• Συνεκτικότητα διαστρωμάτωσης (layer cohesion):
επιτυγχάνεται όταν διατηρούμε στην ίδια συνιστώσα τα
μέσα για να παρέχουμε ένα σύνολο από υπηρεσίες στο
ανώτερο στρώμα και δεν περιλαμβάνουμε στη συνιστώσα
τίποτε άλλο
◦ Προφανώς ισχύει όταν έχουμε διαστρωμάτωση
◦ Επιτρέπονται πλευρικά αποτελέσματα – συχνά είναι απαραίτητα
◦ Παραδείγματα συνιστωσών με συνεκτικότητα διαστρωμάτωσης:
διαχείρισηΑσφάλειας, διάδρασηΜεΧρήστη,
αποθήκευσηΔεδομένων, επεξεργασίαΑρχείωνXML
35
• Ακολουθιακή συνεκτικότητα (sequential cohesion). Αν
ομαδοποίηση σε μονάδες στηρίζεται στο ότι η έξοδος μιας
λειτουργίας είναι είσοδος στην επόμενη
◦ Παραδείγματα: στάδια επεξεργασίας ήχου, αναγνώριση κειμένου
Συνεκτικότητα επικοινωνίας (communicational cohesion). Τα

κομμάτια ομαδοποιούνται σε συνιστώσες γιατί λειτουργούν πάνω
στις ίδιες δομές δεδομένων
– Π.χ. εύρεσηΣτοιχείωνΠελάτη που συλλέγει τον αριθμό πελάτη, στοιχεία
επικοινωνίας, υπολογίζει πιστοληπτική ικανότητα κ.λπ.
– Τι συμβαίνει αν θέλουμε μόνο ένα τμήμα της λειτουργικότητας;
36
• Διαδικαστική συνεκτικότητα (procedural cohesion). Οι
λειτουργίες ομαδοποιούνται σε συνιστώσες διότι πάντα
ακολουθούν μία συγκεκριμένη σειρά εκτέλεσης – π.χ. μία
διαδικασία που ελέγχει τα προνόμια ενός αρχείου και μετά το
ανοίγει.
◦ Το αποτέλεσμα της πρώτης διαδικασίας δεν είναι είσοδος για τη δεύτερη
37
• Χρονική συνεκτικότητα (temporal cohesion): οι
λειτουργίες της συνιστώσας σχετίζονται μόνο λόγω του ότι
καλούνται σε χρονικά παραπλήσιες στιγμές
◦ Π.χ. μετά την εμφάνιση μιας εξαίρεσης, κλείνουμε τα ανοικτά
αρχεία, καταγράφουμε το σφάλμα και ενημερώνουμε τον χρήστη.
◦ Π.χ. Αναθέτουμε αρχικές τιμές σε όλες τις μεταβλητές, ανοίγουμε
όλα τα αρχεία (δεδομένων, καταγραφής, ...)
• Λογική συνεκτικότητα (logical cohesion): ένας αριθμός
λειτουργιών τοποθετούνται στην ίδια συνιστώσα διότι
κατηγοριοποιούνται σε λογικό επίπεδο ότι κάνουν το ίδιο
πράγμα, ακόμη και αν είναι αρκετά διαφορετικό
◦ Π.χ. Κεντρική συνιστώσα διαχείρισης σφαλμάτων
◦ Π.χ. Προετοιμασία πακέτων δεδομένων για μετάδοση, χειρισμός
πακέτων που ελήφθησαν
38
• Συμπτωματική συνεκτικότητα (coincidental cohesion): τα
τμήματα μιας συνιστώσας είναι εντελώς ασυσχέτιστα και
κατά σύμπτωση βρέθηκαν μαζί (π.χ. βιβλιοθήκη «utilities»)
39
Κλίμακα τύπων συνεκτικότητας

7. Λειτουργική Πιο επιθυμητή
6. Ακολουθιακή
5. Επικοινωνίας
4. Διαδικαστική
3. Χρονική
2. Λογική
1. Συμπτωματική Λιγότερο επιθυμητή
40
Εξισορρόπηση σύζευξης και
συνεκτικότητας
• Γενικά υπάρχει μία σχέση μεταξύ σύζευξης και
συνεκτικότητας
◦ Μπορούμε να αυξήσουμε τη συνεκτικότητα με περαιτέρω
αποσύνθεση
◦ Αυτό όμως αυξάνει το πλήθος των διεπαφών και συνακόλουθα τη
σύζευξη
• Ευρεστική: 7 ± 2 έννοιες σε κάθε επίπεδο αφαίρεσης

◦ Αν υπάρχουν πάνω από 7 ± 2 υποσυστήματα σε ένα επίπεδο
αφαίρεσης ή ένα υποσύστημα προσφέρει πάνω από 7 ± 2
υπηρεσίες, πιθανώς να πρέπει να αναθεωρηθεί ο σχεδιασμός
◦ Όμοια, το πλήθος των στρωμάτων δεν πρέπει γενικά να υπερβαίνει
τα 7 ± 2
◦ Συνήθως τρία επίπεδα είναι αρκετά
41
Διαστρωμάτωση (1)
• Η ιεραρχική αποσύνθεση ενός συστήματος οδηγεί σε ένα
διατεταγμένο σύνολο στρωμάτων
• Ένα στρώμα είναι μία ομαδοποίηση υποσυστημάτων που
παρέχουν σχετιζόμενες υπηρεσίες
◦ Πιθανόν να υλοποιείται με χρήση υπηρεσιών από άλλο, χαμηλότερο
επίπεδο
• Τα επίπεδα διατάσσονται ώστε κάθε επίπεδο:
◦ δεν έχει καμία γνώση για τα επίπεδα πάνω από το ίδιο
◦ εξαρτάται μόνο από επίπεδα χαμηλότερου επιπέδου
◦ Στην κλειστή αρχιτεκτονική το κάθε επίπεδο μπορεί να χρησιμοποιεί μόνο
επίπεδα του αμέσως κατώτερου επιπέδου
◦ Στην ανοικτή αρχιτεκτονική το κάθε επίπεδο μπορεί να χρησιμοποιεί
οποιοδήποτε κατώτερο επίπεδο
◦ Τα επίπεδα που δεν εξαρτώνται από άλλα απαρτίζουν το κατώτατο
επίπεδο, ενώ το επίπεδο που δεν χρησιμοποιείται από κανένα άλλο
καλείται το ανώτατο επίπεδο
42
Α: υποσύστημα Επίπεδο 1
(ανώτατο)
Β: υποσύστημα Γ: υποσύστημα Δ: υποσύστημα Επίπεδο 2
Επίπεδο 3
Ε: υποσύστημα Ζ: υποσύστημα Η: υποσύστημα
(κατώτατο)
Κατακόρυφη τομή
• Η κατακόρυφη τομή (vertical slice) διεκπεραιώνει πλήρως ένα

σύνολο λειτουργικότητας
◦ Π.χ. διαχείριση προφίλ χρηστών και βάση δεδομένων XML
43
7 Εφαρμογής
Δεδομένα
• Παράδειγμα κλειστής
6 Παρουσίασης κοινής μορφή αρχιτεκτονικής: μοντέλο
διασύνδεσης ανοικτών
5 Συνόδου Σύνδεση
συστημάτων ISO/OSI
4 Μεταφοράς Μήνυμα
3 Δικτύου Πακέτο
2 Συνδ. Δεδομ. Πλαίσιο
1 Φυσικό bits
44
7 Εφαρμογής
• Το μοντέλο ISO/OSI με
επίπεδα υποσυστημάτων
6 Παρουσίασης
Αντικείμενο
RMI
5 Συνόδου
4 Μεταφοράς
TCP/IP Δίοδος (socket)
3 Δικτύου
2 Συνδ. Δεδομ.
Ethernet Διεύθυνση MAC
1 Φυσικό
45
• Παράδειγμα ανοικτής αρχιτεκτονικής: Swing/AWT
◦ Η εφαρμογή κανονικά χρησιμοποιεί το Swing ΑΛΛΑ μπορεί να
χρησιμοποιήσει και το AWT για ταχύτητα και ευελιξία.
Κύρια βιβλιοθήκη με Εφαρμογή

παράθυρα, διαχειριστές
διάρθρωσης κ.λπ.
Swing
AWT
Αφηρημένη
παραθυρική διεπαφή
X11
Βασικό παραθυρικό
σύστημα 46
• Πλεονεκτήματα-Μειονεκτήματα κλειστές έναντι ανοικτών
αρχιτεκτονικών
Οι κλειστές αρχιτεκτονικές οδηγούν σε χαμηλότερη σύζευξη μεταξύ
των υποσυστημάτων
Επίσης, τα υποσυστήματα μπορούν να ολοκληρωθούν και να
ελεγχθούν επαυξητικά
Κάθε επίπεδο εισάγει επιβάρυνση επεξεργασίας και (δυνητικά)
αποθήκευσης (δυσχεραίνοντας την επίτευξη των στόχων που
τίθενται στις μη λειτουργικές προδιαγραφές)
Η προσθήκη λειτουργικότητας μπορεί να είναι δύσκολη στη
συνέχεια (πρέπει να τροποποιηθούν περισσότερα στρώματα)
• Συνήθως η αποσύνθεση εκτείνεται σε 3-5 στρώματα
47
Διαμέριση
• Εναλλακτικά (ή συμπληρωματικά) προς την ιεραρχική
αποσύνθεση, διαμερίζουμε το σύστημα σε ομότιμα
υποσυστήματα (peer subsystems), κάθε ένα από τα οποία
είναι υπεύθυνο για διαφορετικά είδη υπηρεσιών
◦ Παράδειγμα: διάρθρωση εταιρικού συστήματος
Πελάτες Αποθήκη Προμήθειες
Διαχείριση
Πωλήσεις
προσωπικού
48
Διαστρωμάτωση και διαμέριση
• Γενικά, μία αποσύνθεση συστήματος περιλαμβάνει τόσο
διαμέριση όσο και διαστρωμάτωση
◦ Αρχικά εκτελούμε διαμέριση στα ανώτερου επιπέδου
υποσυστήματα, με κάθε υποσύστημα να είναι υπεύθυνο για
συγκεκριμένη λειτουργικότητα
◦ Αν κάποιο υποσύστημα είναι υπερβολικά πολύπλοκο, προχωρούμε
σε ιεραρχική αποσύνθεσή του
◦ ... στη διαδικασία θυμόμαστε ότι κάθε περαιτέρω διαχωρισμός σε
υποσυστήματα εισάγει επιβάρυνση λόγω της επικοινωνίας μεταξύ
◦ Επίσης, η υπερβολική αποσύνθεση αυξάνει τη συνολική
πολυπλοκότητα και δυσχεραίνει την κατανόηση του μοντέλου
49
Μοτίβα αρχιτεκτονικής (1)

• Ο σωστός ορισμός των υποσυστημάτων είναι πολύ
σημαντικός διότι είναι πολύ δύσκολο να διορθωθεί όταν
έχει ξεκινήσει η ανάπτυξη
◦ Ειδικότερα δεδομένης της αύξησης της πολυπλοκότητας των
συστημάτων
• Αναγνωρίζοντας τη σημαντικότητα του θέματος, έχει

καθιερωθεί η έννοια της αρχιτεκτονικής λογισμικού
◦ Περιλαμβάνει την αποσύνθεση του συστήματος, την καθολική ροή
ελέγχου, τον χειρισμό των οριακών συνθηκών και τα πρωτόκολλα
επικοινωνίας μεταξύ υποσυστημάτων
• Η αρχιτεκτονική λογισμικού έχει παράξει ένα πλήθος από

μοτίβα αρχιτεκτονικής που μπορούν να εφαρμοστούν στη
διαδικασία της αποσύνθεσης
50
Μοτίβο Αποθετηρίου (1)
• Τα υποσυστήματα προσπελαύνουν και τροποποιούν μία
μοναδική δομή δεδομένων που ονομάζεται αποθετήριο
(repository)
• Τα υποσυστήματα είναι (σχετικά) ανεξάρτητα και
επικοινωνούν μόνο μέσω του αποθετηρίου
• Η ροή ελέγχου υπαγορεύεται είτε από τα υποσυστήματα
(π.χ. ανεξάρτητη ροή ελέγχου με κλειδώματα στο
αποθετήριο) ή από το αποθετήριο [π.χ. με εναύσματα
(triggers) που ενεργοποιούν διαδικασίες στα
υποσυστήματα) Αποθετήριο
Υποσύστημα 1 <<διαθέσιμες διεπαφές>>

createData()
setData()
getData()
Υποσύστημα 2 searchData() 51
Μοτίβο Αποθετηρίου (2)

• Χρησιμοποιείται κυρίως συστήματα που χτίζονται γύρω
από μία βάση δεδομένων, π.χ. συστήματα μισθοδοσίας
◦ Επίσης περιβάλλοντα ανάπτυξης χρησιμοποιούν αυτό το μοτίβο
• Η διεπαφή του αποθετηρίου τυπικά περιλαμβάνει ένα API

ή μία γλώσσα ερωτήσεων
52
Μοτίβο πολλαπλών στρωμάτων (1)
• Η αποσύνθεση σε στρώματα είναι μία τυπική διαδικασία
σχεδιασμού
• Όταν την εφαρμόζουμε, το ανώτερο επίπεδο αφορά στη
διεπαφή του actor με το σύστημα – συνήθως στη διεπαφή
του χρήστη
◦ Έτσι μπορούμε να έχουμε πολλές διεπαφές για την ίδια
λειτουργικότητα, π.χ. γραφική διεπαφή έναντι διεπαφής γραμμής
εντολών, διεπαφές για διαφορετικές πλατφόρμες κ.ο.κ.
◦ Τα κατώτερα στρώματα αφορούν τις λειτουργίες εφαρμογής που
ορίσθηκαν από τις περιπτώσεις χρήσης
◦ Τα στρώματα στο κάτω μέρος της ιεραρχίας αφορούν συνήθως
υπηρεσίες όπως αποθήκευση και μετάδοση
53
Μοτίβο πολλαπλών στρωμάτων (2)

• Συνήθης αποσύνθεση σε μοντέλο πολλαπλών στρωμάτων
Διεπαφή χρήστη
Λογική της εφαρμογής
Πρόσβαση στο Λ.Σ. Αποθήκευση Επικοινωνία
54
Μοτίβο πολλαπλών στρωμάτων
(3)
• Το μοτίβο έχει και γενικότερη χρήση (εκτός από
εφαρμογές)
◦ Στα λειτουργικά συστήματα, τα χαμηλότερα στρώματα ασχολούνται
με βασικές λειτουργίες (π.χ. ανάθεση διεργασιών σε επεξεργαστές,
διαχείριση μνήμης, είσοδο-έξοδο χαμηλού επιπέδου) και τα
ανώτερα στρώματα σχηματίζουν πιο σύνθετες λειτουργίες (π.χ.
διαχείριση μπλοκ δίσκου  αρχεία και κατάλογοι)
◦ Εφαρμόζεται επίσης στα τηλεπικοινωνιακά συστήματα (π.χ. μοντέλο
OSI)
• Η επικοινωνία μεταξύ των στρωμάτων μπορεί να γίνεται

με κλήσεις μεθόδων/διαδικασιών
◦ Ή όμως και με διαδιεργασιακή επικοινωνία
◦ Έτσι τα κατώτερα τμήματα μπορούν να γίνουν εξυπηρέτες (και ίσως
να εκτελούνται και σε διαφορετικό μηχάνημα)
55
Μοτίβο εξυπηρέτη-
εξυπηρετούμενου (1)
• Βασική διάταξη:
◦ Υπάρχει μία τουλάχιστον συνιστώσα με τον ρόλο του εξυπηρέτη
(server) που περιμένει και εξυπηρετεί αιτήματα
◦ Υπάρχει μία τουλάχιστον συνιστώσα με τον ρόλο του
εξυπηρετούμενου (client) που αποστέλλει αιτήματα για εκτέλεση
(και συνήθως λαμβάνει κάποια απάντηση)
◦ Η συνιστώσα του εξυπηρέτη παρέχει συγκεκριμένες υπηρεσίες, τις
οποίες η συνιστώσα του εξυπηρετούμενου χρησιμοποιεί
εξυπηρετούμενος Εξυπηρέτης
<<παρεχόμενες υπηρεσίες>>
υπηρεσία1
υπηρεσία2
υπηρεσία3
...
56
Μοτίβο εξυπηρέτη-εξυπηρετούμενου (2)
• Παραδείγματα:
◦ Οποιοδήποτε σύστημα με μία βάση δεδομένων
◦ Οι εξυπηρετούμενοι συλλέγουν τα δεδομένα, τα ελέγχουν και εκτελούν τις
δοσοληψίες
◦ Οι ιστοχώροι στο διαδίκτυο
◦ όπου ένας εξυπηρετούμενος μπορεί να συνδέεται σε πολλούς εξυπηρέτες
◦ και ένας εξυπηρέτης μπορεί να δέχεται συνδέσεις από πολλούς διαφορετικού τύπου
εξυπηρετούμενους (εφαρμογές πλοήγησης, ιστοσυλλέκτες (bots) κ.λπ.)
◦ Η εφαρμογή πλοήγησης απλώς δρα ως διεπαφή με τον χρήστη – όλη η επεξεργασία
και αποθήκευση γίνεται στο επίπεδο του εξυπηρέτη
◦ Ο εξυπηρέτης μπορεί να έχει και άλλα στρώματα που δεν είναι άμεσα ορατά
◦ Το παράδειγμα της βάσης δεδομένων καλείται βαρύς πελάτης, ενώ το
παράδειγμα του προγράμματος πλοήγησης ελαφρύς πελάτης
firefox: WebBrowser www.uop.gr: WebServer
chrome: WebBrowser mail.uop.gr: WebServer

57
Μοτίβο τριών στρωμάτων (1)

• Παραλλαγή του μοτίβου εξυπηρέτη-εξυπηρετούμενου
• Στρώματα: διεπαφή χρήστη, λογική της εφαρμογής,
αποθήκευση
◦ Πρακτικά το στρώμα της επεξεργασίας δεν εντάσσεται ούτε στον
εξυπηρετούμενο ούτε στον εξυπηρέτη, αλλά σε ένα ανεξάρτητο
στρώμα, το στρώμα της επεξεργασίας (ή επιχειρηματικής λογικής ή
λογικής της εφαρμογής)
διεπαφή επεξεργασία αποθήκευση
Φόρμα Σύνδεση Ερώτηση
58
Μοτίβο τριών στρωμάτων (2)
• Πλεονεκτήματα μοντέλου τριών στρωμάτων
◦ Εύκολη υλοποίηση πολλών διεπαφών για την ίδια εφαρμογή
◦ Π.χ. Διαλογική, διεπαφής με μηχανές, για διαφορετικές συσκευές...
◦ Ευκολότερη συντήρηση
◦ Πιο εύκολος ο περιορισμός της συντήρησης μόνο σε ένα στρώμα
◦ Μεγαλύτερη ευελιξία στη διαμόρφωση των μηχανημάτων
◦ Άλλες οι ανάγκες για βάσεις δεδομένων, άλλες για ταχύτητα
επεξεργασίας
◦ Ικανότητα κλιμάκωσης
◦ Με προσθήκη εξυπηρετών / αποθήκευσης στο κατάλληλο στρώμα
59
Μοτίβο ομοτίμων (1)

• Ένα σύστημα ομοτίμων απαρτίζεται από ένα πλήθος
συνιστωσών λογισμικού, τυπικά κατανεμημένους σε
πολλούς υπολογιστές
• Κάθε τέτοια συνιστώσα μπορεί να είναι τόσο εξυπηρέτης
(παρέχει υπηρεσίες) όσο και εξυπηρετούμενος (λαμβάνει
υπηρεσίες)
• Κάθε ζεύγος συνιστωσών μπορεί να επικοινωνήσει για να
ανταλλάξει υπηρεσίες
• Οι συνιστώσες μαθαίνουν η μία για την ύπαρξη της άλλης
είτε μέσω ειδικών κόμβων (super-peers) ή
ανταλλάσσοντας μεταξύ τους πληροφορίες για τους
κόμβους που γνωρίζουν
60
• Τυπικά παραδείγματα:
διαμοιρασμός αρχείων, chatting
• Παράδειγμα: Gnutella
61

• Παράδειγμα: Skype
◦ εξυπηρετούμενοι: οι υπολογιστές που
πραγματοποιούν και δέχονται κλήσεις
◦ Super nodes: εξυπηρετούμενοι που δεν είναι
πίσω από firewalls ή NAT και βοηθάνε τους
λοιπούς εξυπηρετούμενους να
επικοινωνήσουν μεταξύ τους
◦ Πύλες: σημεία επικοινωνίας με το
τηλεφωνικό δίκτυο
◦ Εξυπηρέτης πιστοποίησης: συνιστώσα που
διατηρεί τα στοιχεία σύνδεσης και τα προφίλ
62
Μοτίβο μεσάζοντα
• Στόχος είναι να κατανεμηθούν απόψεις του συστήματος
λογισμικού με διαφανή τρόπο σε ένα πλήθος υπολογιστών
◦ Ένα αντικείμενο Α καλεί λειτουργίες ενός άλλου Β, χωρίς να γνωρίζει
που βρίσκεται το Β
• Χρησιμοποιείται ένας αντιπρόσωπος (proxy) στη

συνιστώσα, ο οποίος καλεί τον μεσάζοντα που με τη σειρά
του εντοπίζει το αντικείμενο και του μεταβιβάζει την
κλήση
• Χαρακτηριστικός αντιπρόσωπος: CORBA
εξυπηρετούμενος
μεσάζων
Αντιπρόσωπος Απομακρυσμένο αντικείμενο
63
Μοτίβο σωλήνωσης & φίλτρου

• Τα υποσυστήματα δέχονται δεδομένα από εισόδους και
στέλνουν δεδομένα σε άλλα υποσυστήματα μέσω ενός
συνόλου εξόδων
◦ Τα ίδια τα υποσυστήματα ονομάζονται φίλτρα και οι σύνδεσμοι
μεταξύ τους σωληνώσεις
• Κάθε φίλτρο γνωρίζει μόνο το τι διαβάζει και τι κάνει, όχι
πως παρήχθη η είσοδος (με ποιά φίλτρα) ή πως θα
χρησιμοποιηθεί η έξοδος
• Ο συγχρονισμός επιτυγχάνεται μέσω των σωληνώσεων
• Ένα φίλτρο μπορεί να αντικατασταθεί ή να επανα-
προγραμματιστεί, για την επίτευξη διαφορετικού
αποτελέσματος
• Τυπικό παράδειγμα: σωληνώσεις Unix
64
Μοτίβο μοντέλου-όψης-ελεγκτή (1)
• Τα υποσυστήματα χωρίζονται σε τρεις κατηγορίες:
◦ Μοντέλα, που έχουν την γνώση της περιοχής εφαρμογής
◦ Όψεις, που την παρουσιάζουν στον χρήστη
◦ Ελεγκτές, που διαχειρίζονται την ακολουθία των διαδράσεων με τον
χρήστη
• Τα μοντέλα δεν πρέπει να εξαρτώνται από συγκεκριμένους

ελεγκτές ή όψεις
• Οι αλλαγές στην κατάσταση των μοντέλων διαδίδονται
στην όψη με χρήση του πρωτοκόλλου
συνδρομής/ενημέρωσης
• Μπορεί να θεωρηθεί ως ειδική περίπτωση του
πολυεπίπεδου μοτίβου
65

Τη βλέπει
ο actor Δημιουργεί και ενημερώνει
Όψη
ελεγκτής
Ειδοποιεί για
αλλαγές τροποποιεί Χειρίζεται τα
συμβάντα του actor
μοντέλο
• Το σκεπτικό του μοντέλου είναι ότι η πιο επιρρεπής σε αλλαγή

συνιστώσα είναι αυτή της διεπαφής χρήστη (όψη)
◦ Οι αλλαγές στην όψη δεν επηρεάζουν το μοντέλο
• Εξαιρετικά κατάλληλο για διαλογικά συστήματα
66
• Παράδειγμα διαγράμματος επικοινωνίας για το μοτίβο μοντέλο-όψη-ελεγκτής
67

Τεχνολογία Λογισμικού Κώστας Βασιλάκης ΠΑΝΕΠΙΣΤΗΜΙΟ ΠΕΛΟΠΟΝΝΗΣΟΥ

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Τεχνολογία Λογισμικού Κώστας Βασιλάκης ΠΑΝΕΠΙΣΤΗΜΙΟ ΠΕΛΟΠΟΝΝΗΣΟΥ

Uploaded by

Copyright:

Available Formats

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

ΤΕΧΝΟΛΟΓΙΑ ΛΟΓΙΣΜΙΚΟΥ (SOFTWARE

Πλαίσιο μαθήματος, εισαγωγή

Η ανάγκη για την Τεχνολογία Λογισμικού:

2000 2015 2020

44% 40% 44%

Αναφορά της Standish 2015

Τι συμβαίνει με άλλους τομείς;

Τεχνικές, μεθοδολογίες και εργαλεία

Η ανάπτυξη του λογισμικού δεν

• Το λογισμικό είναι πολύπλοκο

Ιδιαιτερότητα του λογισμικού (2/2)

Γιατί όχι χρήση της γενικής

• Η επιστημονική μεθοδολογία λειτουργεί κυρίως με την

• Χρειαζόμαστε δημιουργικότητα, πρωτοτυπία,

• Κλάδος της πληροφορικής που ασχολείται με τη μελέτη και την

Ποιότητες που ενδιαφέρουν

Ποιοτικό Λογισμικό (2/3)

2ος στόχος: διαχειριστική γνώση

ΕΦΑΡΜΟΓΗ ΣΤΙΣ ΕΡΓΑΣΙΕΣ

Προαπαιτούμενα του μαθήματος

Ανάλυση Σχεδίαση Κωδικοποίηση Έλεγχος

Συμμετέχοντες, Εργασίες και

Χρήστες Ομάδα ανάπτυξης

Στρατηγικός στόχος Πλάνο του έργου

Πελάτης Συμβατικές Ομάδα διοίκησης

Δραστηριότητες Ανάπτυξης (1/2)

Κόστος των φάσεων

Ανάπτυξη Συντήρηση Ανάπτυξη Συντήρηση

Object-Oriented and Classical Software Engineer 5th Edition, Schach (2002)

Σχετικό κόστος διόρθωσης σφαλμάτων

Πότε Απαιτήσεις Αρχιτεκτονική Κατασκευή Έλεγχος Συντήρηση

Ουσιαστικός ο εντοπισμός αρκετά

• ... αν όμως γίνει αργά:

Μοντέλα κύκλου ζωής

Μία απλοϊκή προσέγγιση

Το Μοντέλο του Καταρράκτη

Το Επαυξητικό μοντέλο (συνέχεια)

Το Σπειροειδές Μοντέλο (συνέχεια)

Το Σπειροειδές Μοντέλο (συνέχεια)

• Παράδειγμα ανάλυσης επικινδυνότητας

Το σπειροειδές μοντέλο (συνέχεια)

• Στο σπειροειδές μοντέλο δεν υπάρχουν σαφή ορόσημα για τη

Το Επαναληπτικό μοντέλο (συνέχεια)

Επαναληπτικό μοντέλο και

Ακόμα και μέσα στην ομάδα δεν

Λίγα λόγια για το λογισμικό [3/4] (με

ΤΕΧΝΟΛΟΓΙΑ ΛΟΓΙΣΜΙΚΟΥ (SOFTWARE

Ποιο είναι το πρόβλημα με το

Κωδικός τμήματος Έτος εγγραφής Αριθμός έτους

• Οι ιδέες μπορούν να εκφράζονται μέσω μοντέλων

Χρήση μοντέλων για περιγραφή

• Μοντέλο συστήματος: Μοντέλο αντικειμένων + Λειτουργικό

Ποια άλλα μοντέλα χρησιμοποιούμε για

Παράδειγμα μοντέλου ζητημάτων

Υπέρ: Κατά: Υπέρ:

Υπέρ: Κατά: Υπέρ:

Παράδειγμα μοντέλου ζητημάτων

Πρόταση 1: Πρόταση 3: Πρόταση 2:

Υπέρ: Κατά: Υπέρ:

Τεχνική αντιμετώπισης πολυπλοκότητας:

Τεχνική αντιμετώπισης πολυπλοκότητας:

Τεχνική αντιμετώπισης πολυπλοκότητας:

Change Change Change D raw D raw D raw