Τεχνολογία Λογισμικού Ι Ν. Πεταλίδης Τει Σερρών 2008

Τεχνολογία Λογισμικού I Ν.
Πεταλίδης ΤΕΙ Σερρών
Περιεχόμενο Διαλέξεων Θεωρίας Τεχνολογίας Λογισμικού Ι
Διάλεξη
1. Εισαγωγή
2. UML – Διαγράμματα κλάσεων
3. UML – Διαγράμματα Περιπτώσεων
Χρήσης
UML – Διαγράμματα Δραστηριότητας
4. UML – Διαγράμματα Αλληλεπίδρασης
5. UML – Χάρτες Κατάστασης
6. Διαδικασίες Ανάπτυξης Λογισμικού
7. Η Καταγραφή των Απαιτήσεων
8. Παράδειγμα: Παραγωγή
περιπτώσεων χρήσης από τις
απαιτήσεις ενός πελάτη
9. Η Ανάλυση των Απαιτήσεων
10. Παράδειγμα: Ανάλυση απαιτήσεων
συστήματος καταχώρησης ονομάτων
χώρου
11. Η Σχεδίαση του Συστήματος
Παράδειγμα Σχεδίασης
12. Θέματα Σχεδίασης: Σύζευξη
13. Θέματα Σχεδίασης: Συνεκτικότητα
14. Προχωρημένα Θέματα Σχεδίασης
15. Ανασκόπηση – Βιβλιογραφία
Τεχνολογία Λογισμικού I
Συντάκτης: Δρ. Ν. Πεταλίδης
1 Υποέργο 1 «Αυτεπιστασία του τμήματος Πληροφορικής και Επικοινωνιών»,

«Ενίσχυση Σπουδών Πληροφορικής στο ΤΕΙ Σερρών» Μέτρο 2.2, Γ' ΚΠΣ
1η Διάλεξη
Εισαγωγή

Τεχνολογία Λογισμικού
 Σκοπός της Τεχνολογίας Λογισμικού είναι
η ανάπτυξη μεθοδολογιών, πρακτικών
και εργαλείων που θα βοηθήσουν στην
ανάπτυξη προϊόντων λογισμικού με το
βέλτιστο συνδυασμό κόστους, εύρους και
ποιότητας
 Αυτό επιτυγχάνεται με την πρακτική
εφαρμογή διαφόρων θεωριών από την
επιστήμη υπολογιστών

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

σημαντική;
 Μεγάλο μέρος της παγκόσμιας οικονομίας
στηρίζεται σε λογισμικό. Η επικράτηση του
λογισμικού μέσω της διάδοσης προσωπικών
υπολογιστών, κινητών και διαδικτύου είναι
καθολική
 Οι αποδεκτοί χρόνοι παράδοσης ενός λογισμικού
έχουν μειωθεί και οι απαιτήσεις των χρηστών
έχουν αυξηθεί
 Οι παραδοσιακές μέθοδοι παραγωγής προϊόντων
δε μπορούν να εφαρμοστούν στο λογισμικό
Τα βήματα ανάπτυξης ενός
προϊόντος λογισμικού
 Σε γενικές γραμμές η Τεχνολογία

Λογισμικού λέει ότι για να αναπτύξεις ένα
προϊόν λογισμικού πρέπει
 (1) Να προετοιμάσεις ένα πλάνο,
 (2) Να καταλάβεις τι πρέπει να κάνεις,
 (3) Να σχεδιάσεις το σύστημα
 (4) Να γράψεις τα προγράμματα,
 (5) Να το ελέγξεις, και
 (6) Να το συντηρήσεις.

Γιατί να τα κάνεις όλα αυτά;

 Συχνά φοιτητές λένε ότι «εμείς κάνουμε
προγράμματα χωρίς να ακολουθούμε τίποτα από
όσα λέει η τεχνολογία λογισμικού και δεν έχουμε
πρόβλημα»
 Παρόμοιες ιστορίες για φοιτητές που δούλευαν
στο γκαράζ του σπιτιού τους και κατασκεύασαν
το ΧΨΖ καταπληκτικό πρόγραμμα μέσα σε 2
νύχτες επίσης αναφέρονται πολύ συχνά στον
τύπο.
 Επομένως, για ποιο λόγο να μπει κανείς στην
επίπονη διαδικασία της σχεδίασης, ελέγχων κτλ;
Η διαφορά ανάμεσα σε λογισμικό, σύστημα λογισμικού
και προϊόν λογισμικού
Αναπτύσσεται και χωρίς Χωρίς ιδιαίτερη μεθοδολογία
ιδιαίτερη μεθοδολογία x3 αποτυγχάνει
Σύστημα
Λογισμικό Λογισμικού
(Συνεργασία και
ενσωμάτωση με
Χωρίς ιδιαίτερη υπάρχοντα συστήματα)
μεθοδολογία αποτυγχάνει
x3
Χωρίς ιδιαίτερη
Προϊόν μεθοδολογία αποτυγχάνει
Λογισμικού Προΐόν
(Γενίκευση, Δοκιμές,
Σύστηματος
Τεκμηρίωση, Συντήρηση) Λογισμικού

Η διαφορά ανάμεσα σε λογισμικό, σύστημα

λογισμικού και προϊόν λογισμικού
 Το προηγούμενο διάγραμμα προέρχεται

από το βιβλίο «The Mythical Man Month»
του Frederick Brooks
 Δείχνει ότι αν Χ το κόστος ανάπτυξης
ενός προγράμματος, τότε
 αν πρόκειται αυτό να μετουσιωθεί σε προϊόν τότε το
κόστος είναι τριπλάσιο.
 Αν πρέπει να συνεργασθεί με υπάρχοντα προγράμματα
τρίτων τότε το κόστος είναι πάλι τριπλάσιο.
 Επομένως αν πρέπει να μετουσιωθεί σε προϊόν που
πρέπει να συνεργαστεί με άλλα υπάρχοντα τότε το κόστος
είναι εννεαπλάσιο…
Συμπέρασμα
 Είναι εύκολο να αναπτύξεις χωρίς
ιδιαίτερη οργάνωση ένα πρόγραμμα,
αλλά αδύνατο να αναπτύξεις ένα καλό
προϊόν λογισμικού που πρέπει να
συνεργάζεται με άλλα προϊόντα
λογισμικού

Τι έχει πετύχει η Τεχνολογία

Λογισμικού;
 Το να αναπτύσσεις λογισμικό είναι και

τέχνη και επιστήμη
 Η τεχνολογία λογισμικού αφορά την
ανάπτυξη συστημάτων με υψηλή
ποιότητα.
 Βέβαια τα συστήματα λογισμικού έχουν
ακόμα ατέλειες.
 Παρόλα αυτά έχει κάνει τεράστια βήματα!

Πως προσπαθεί η Τεχνολογία
Λογισμικού να πετύχει;
 Βελτιώνοντας τις διαδικασίες ανάπτυξης

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

 Είναι ο τρόπος που οργανώνουμε την
παραγωγή του προϊόντος, δηλαδή την
καταγραφή των απαιτήσεων, το
μετασχηματισμό τους σε λογισμικό, τον
έλεγχο της ορθότητάς του και τέλος τη
συντήρηση του προϊόντος
 Μια σωστή διαδικασία ανάπτυξης
συμβάλλει στην ποιότητα και την
ταχύτητα με την οποία αναπτύσσεται το
λογισμικό
Μέθοδοι και συμβολισμοί
ανάλυσης και σχεδίασης
 Η Τεχνολογία Λογισμικού δίνει τρόπους

για να μετασχηματίζουμε τις απαιτήσεις
των χρηστών σε λογισμικό και να
κατασκευάζουμε μοντέλα που μπορούμε
εύκολα να ελέγχουμε για συνέπεια και
ορθότητα.
 Αναπτύσσει επίσης συμβολισμούς που
μπορούμε να χρησιμοποιούμε για
ευκολία στην επικοινωνία μεταξύ μας

Αφαιρετική προσέγγιση
 Είναι η περιγραφή ενός προβλήματος σε
κάποιο επίπεδο γενίκευσης το οποίο μας
επιτρέπει να εστιάσουμε στα σημαντικά
σημεία του προβλήματος χωρίς να μας
παρασύρουν οι λεπτομέρειες.
 Για παράδειγμα η Τεχνολογία Λογισμικού
μας προτρέπει να βρίσκουμε κλάσεις από
αντικείμενα με κοινά χαρακτηριστικά και
να σχηματίζουμε ιεραρχίες

Παράδειγμα αφαιρετικής
προσέγγισης
Άνθρωπος
Υπάλληλος
Τεχνικός Πωλητής

Επαναχρησιμοποίηση
 Στόχο έχει να επισημάνει τα κοινά
στοιχεία που μπορεί να υπάρξουν σε
διαφορετικά προϊόντα λογισμικού και να
τα σχεδιάσει και να τα υλοποιήσει έτσι
ώστε είναι δυνατό να
ξαναχρησιμοποιηθούν αυτούσια σε
μελλοντικά προϊόντα
 Τα επαναχρησιμοποιήσιμα συστατικά
αποτελούν σημαντικό κεφάλαιο μιας
επιχείρησης
Μετρήσεις
 Σημαντικό κομμάτι της Τεχνολογίας
Λογισμικού ασχολείται με το να
μεταφράσει σε μετρήσιμα μεγέθη έννοιες
όπως “καλή σχεδίαση”, “ποιότητα” κτλ.
 Με τον τρόπο αυτό γίνεται ευκολότερη η
σύγκριση και η εξαγωγή συμπερασμάτων

Εργαλεία και ολοκληρωμένα

περιβάλλοντα ανάπτυξης
 Μεγάλος στόχος της Τεχνολογίας

Λογισμικού είναι η αυτοματοποίηση
πολλών από τις εργασίες για την ανάπτυξη
ενός προϊόντος λογισμικού. Για το σκοπό
αυτό αναπτύσσονται εργαλεία που
 σας βοηθούν να παρακολουθήσετε την
πρόοδο του έργου
 σας βοηθούν στην ανάπτυξη και
επιδιόρθωση
 σας βοηθούν στον έλεγχο του λογισμικού
Σε τι θα επικεντρωθούν οι διαλέξεις;
 Χρήση συμβολισμών
 Θα δείτε τη χρήση της συμβολικής
γλώσσας UML, lingua franca για τους
Τεχνολόγους Λογισμικού
 Μεθοδολογίες ανάλυσης και σχεδίασης
 Θα δείτε μεθόδους για την καταγραφή και
ανάλυση των απαιτήσεων, για τη
σχεδίαση και υλοποίηση προϊόντων

2η Διάλεξη
UML – Διαγράμματα Κλάσεων

UML
 Είναι μια γλώσσα που χρησιμοποιείται
κυρίως για τη γραφική αναπαράσταση
αντικειμενοστραφών σχεδίων
 Αποτελεί αρχικά των λέξεων Unified
Modeling Language και είναι απόγονος των
αντικειμενοστραφών μεθόδων ανάλυσης και
σχεδιασμού που εμφανίστηκαν στα τέλη της
δεκαετίας του 80
 Ενοποιεί τις μεθόδους των Booch (Booch),
Rambaugh (OMT) και Jacobson (OOSE)

Τι μας επιτρέπει να κάνουμε

 Να παράγουμε μοντέλα
αντικειμενοστραφών προγραμμάτων με
εύκολο τρόπο χωρίς να μπλεκόμαστε στις
λεπτομέρειες γλωσσών
προγραμματισμού όπως η C++ και η
Java
 Μπορεί εύκολα ένα μοντέλο σε UML να
μεταφραστεί σε μια αντικειμενοστραφή
γλώσσα προγραμματισμού

Διαγράμματα UML
 H UML προσφέρει ένα σύνολο από
διαγράμματα που μπορούν να
χρησιμοποιηθούν για να αναπαραστήσουν
διαφορετικές πτυχές ενός συστήματος.
 Κάποια διαγράμματα αναπαριστούν στατικά
το σύστημα (δηλαδή πως είναι το σύστημα
σε μια συγκεκριμένη στιγμή) και κάποια
κάνουν δυναμική αναπαράσταση (δηλαδή
δείχνουν πως μπορεί να εξελιχθεί το
σύστημα)
Διαγράμματα UML
 Στατικά διαγράμματα
 Διάγραμμα Κλάσεων
 Διάγραμμα Περιπτώσεων Χρήσης
 Διάγραμμα παράταξης (δε θα καλυφθεί)
 Δυναμικά Διαγράμματα
 Διαγράμματα αλληλεπίδρασης
 Διαγράμματα ακολουθίας
 Διαγράμματα συνεργασίας
 Διαγράμματα δραστηριότητας
 Χάρτες καταστάσεων
Διαγράμματα κλάσεων
 Αναπαριστούν τις κλάσεις ενός
λογισμικού και τις συσχετίσεις μεταξύ
τους
 Δείχνουν επίσης τις ιδιότητες και τις
μεθόδους μιας κλάσης αλλά και τους
περιορισμούς που υπάρχουν στον τρόπο
που συνδέονται μεταξύ τους
 Δίνουν μια στατική όψη ενός συστήματος

Αναπαράσταση κλάσης στη UML
Όνομα Κλάσης Person

-name : string
Ιδιότητες (χαρακτηριστικά) κλάσης -surname : string
+ Person(in name : string, in surname : string)
Μέθοδοι (συναρτήσεις) + getName() : string
+ setName(in name : string)
κλάσεις + getSurname() : string
+ setSurname(in surname : string)

Συσχετίσεις
 Σε ένα διάγραμμα κλάσεων, οι κλάσεις
μπορεί να συσχετίζονται μεταξύ τους
 Η UML αναπαριστά τη συσχέτιση μεταξύ
δύο κλάσεων πολύ απλά με μια γραμμή
8 Υποέργο «Αυτεπιστασία του τμήματος Πληροφορικής και Επικοινωνιών»,

«Ενίσχυση Σπουδών Πληροφορικής στο ΤΕΙ Σερρών» Μέτρο , Γ' ΚΠΣ
Συσχετίσεις ανάμεσα σε κλάσεις

Person
-name : string
class Person -surname : string
{ +Person(in name : string, in surname : string)
private: +getName() : string
string name; +setName(in name : string)
+getSurname() : string
... +setSurname(in surname : string)
Address homeAddress;
... Σε UML 1
}
1 -homeAddress
class Address
{ Address
... Ένα Person σχετίζεται με ένα
αντικείμενο Address. Το βελάκι
} δηλώνει τη φορά της συσχέτισης

Διμερείς συσχετίσεις
class Team
{
LinkedList members = new Team
LinkedList();
…
}
Σε UML 1
1..*
class member
{
Member
Team memberOf;
…
}
Ένα Team έχει πολλά

Members. Ένα Member έχει
ένα Team

Κληρονομικότητα
class Person
{
private:
Person
string name;
-name : string
... -surname : string
Σε UML +Person(in name : string, in surname : string)
} +getName() : string
class Employee : public Person { +setName(in name : string)
+getSurname() : string
+setSurname(in surname : string)
public:
float getSalary();
Employee
void setSalary(float salary);
-salary : float
private: +getSalary() : float
Στη γλώσσα της UML η +setSalary(in salary : float)
float salary; κληρονομικότητα
ονομάζεται “γενίκευση”
};

Άλλοι συμβολισμοί της UML
 Πέρα από τις προηγούμενες συσχετίσεις
υπάρχουν και άλλοι συμβολισμοί για ειδικές
περιπτώσεις συσχετίσεων
 Συναρμολόγηση ή συσσωμάτωση
 Όταν μια κλάση είναι τμήμα μιας άλλης
κλάσης
 Σύνθεση
 Όταν μια κλάση είναι ΠΑΝΤΑ
αναπόσπαστο κομμάτι μιας άλλης
κλάσης
 Για παράδειγμα ένα χέρι έχει πάντα
δάχτυλα
Σύνθεση/Συσσωμάτωση
 Είναι συμβολισμοί χρήσιμοι σε
περιπτώσεις που θέλουμε να δείξουμε
κάποιες λεπτομέρειες. Μπορούν να
αντικατασταθούν από μια απλή
συσχέτιση.
 Η σύνθεση μπορεί να χρησιμοποιηθεί αν
θέλουμε να τονίσουμε ότι η διαγραφή
μιας κλάσης συνεπάγεται και τη διαγραφή
της άλλης
 Πχ αν διαγράψουμε την κλάση χέρι πρέπει
να διαγράψουμε και την κλάση δάχτυλο
Σύνθεση και συσσωμάτωση
Company Department Employee
Σύνθεση: Αν διαγραφεί Συσσωμάτωση: Η

η Company διαγραφή του
διαγράφεται και το Department δεν
Department επηρεάζει το Employee

Εξάρτηση
 Εξάρτηση υπάρχει
αν μια κλάση
χρησιμοποιεί μια
άλλη κλάση σαν B
a
se
Cl
ass F
a
ct
or
yCl
ass
παράμετρο ή σαν
επιστρεφόμενη τιμή
+
g
et
I
nst
anc
e
()
:Ba
s
eC
l
ass
σε κάποια
συνάρτησή της

Παράδειγμα

Ποιες κλάσεις αναπαριστά το

διάγραμμα;
 Πελάτης
 Πωλητής
 Ραντεβού
 Διευθυντής

Παρατηρήσεις
 Σε ένα διάγραμμα κλάσεων μπορεί να
δείχνουμε για ευκολία μόνο τα ονόματα
των κλάσεων και όχι τις μεθόδους ή τα
χαρακτηριστικά τους.

3η Διάλεξη
UML – Διαγράμματα
Περιπτώσεων
Χρήσης/Δραστηριότητας

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

 Σε κάθε διάγραμμα περίπτωσης χρήσης
απεικονίζεται ένας χρήστης του συστήματος
(άνθρωπος ή άλλο σύστημα) ως ένα ανθρωπάκι
 Η ίδια η περίπτωση χρήσης απεικονίζεται ως
μία έλλειψη.
 Ο χρήστης «ξεκινά» μία περίπτωση χρήσης
αναμένοντας την εκτέλεση κάποια λειτουργίας.
Η συσχέτιση μεταξύ χρήστη και περίπτωσης
χρήσης απεικονίζεται με μία γραμμή μεταξύ τους
ενώ η φορά της ενεργοποίησης με τη χρήση
κατευθυνόμενης γραμμής.
 Ένας χαρακτήρας που αλληλεπιδρά με το
σύστημα υπό διαφορετικό ρόλο κάθε φορά,
αναγνωρίζεται ως διαφορετικός χρήστης.
(Π.χ. ένας άνθρωπος μπορεί να λειτουργεί
είτε ως απλός χρήστης είτε ως administrator).
 Ένας χρήστης μπορεί να είναι ένας
άνθρωπος ή ακόμα και ένα μηχάνημα με το
οποίο συνεργάζεται το σύστημά μας
 Οι πελάτες αποφασίζουν για το ποιες
λειτουργίες θα πρέπει να υλοποιηθούν
Περιπτώσεων Χρήσης ATM

 Μία περίπτωση χρήσης μπορεί να συνεργάζεται με
άλλες περιπτώσεις χρήσης ή χαρακτήρες ως εξής
Συσχέτιση: Το μονοπάτι επικοινωνίας μεταξύ ενός χαρακτήρα και

μιας περίπτωσης χρήσης στην οποία συμμετέχει
«extends»
Επέκταση: Η προσθήκη λειτουργικότητας σε μία βασική περίπτωση
χρήσης (η οποία δεν γνωρίζει για αυτή)
Γενίκευση: Μία συσχέτιση μεταξύ μιας γενικής περίπτωσης χρήσης

και μίας ειδικότερης που κληρονομεί στοιχεία συμπεριφοράς και
προσθέτει νέα χαρακτηριστικά.
Περιεκτικότητα: Η προσθήκη λειτουργικότητας σε μία βασική περίπτωση

χρήσης (η οποία περιγράφει σαφώς την περίπτωση που εμπεριέχεται) <<includes>>


 Πέρα από το διάγραμμα, μια περίπτωση
χρήσης συνοδεύεται και από ένα κείμενο (~1
σελίδα). Εκεί περιγράφονται οι δυνατές
συμπεριφορές που μπορεί να παρατηρηθούν.
Συνήθως υπάρχει μια κανονική συμπεριφορά
και πολλές εναλλακτικές
 Η εκτέλεση κάθε περίπτωσης χρήσης είναι
ανεξάρτητη από τις υπόλοιπες, παρόλο που η
υλοποίηση του συστήματος μπορεί να
συνεπάγεται έμμεσες εξαρτήσεις μεταξύ τους
λόγω κοινών αντικειμένων.
Δομή της περιγραφής μιας
περίπτωσης χρήσης
Τίτλος Περίπτωσης Χρήσης
Σύντομη περιγραφή (1-2 σειρές)
Προαπαιτούμενα (Συνθήκες που θα πρέπει να ισχύουν
ώστε να είναι δυνατή η έναρξη της περίπτωσης
χρήσης)
Κύρια ροή γεγονότων (Περιγραφή των βημάτων που
λαμβάνουν χώρα για την υλοποίηση της
συμπεριφοράς)
Εναλλακτική ροή γεγονότων (Περιγραφή εξαιρέσεων ή
λανθασμένων καταστάσεων)
Αποτέλεσμα (Τι ισχύει μετά το πέρας της λειτουργίας)
Παράδειγμα περιγραφής
Ανάληψη μετρητών
Σύντομη περιγραφή: Ανάληψη μετρητών από το ΑΤΜ
Προαπαιτούμενα: Ο πελάτης έχει εισάγει σωστά την κάρτα του και το PIN του
Κύρια ροή γεγονότων
1. Το σύστημα δίνει στο χρήστη τη δυνατότητα να επιλέξει ποσό ανάληψης
2. Ο χρήστης επιλέγει ποσό
3. Το σύστημα δίνει το ανάλογο ποσό μαζί με απόδειξη με το υπόλοιπο του λογαριασμού
Εναλλακτική ροή
α. 3.1Δεν υπάρχουν αρκετά χρήματα στο λογαριασμό και ενημερώνεται ο χρήστης
β. 3.1 Το ΑΤΜ δεν έχει τα απαραίτητα χαρτονομίσματα και ενημερώνει το χρήστη
Αποτέλεσμα
Ο χρήστης έχει παραλάβει το ποσό και το υπόλοιπό του έχει μειωθεί αντίστοιχα

Δραστηριότητας

Διαγράμματα δραστηριότητας
 Τα διαγράμματα δραστηριότητας
αποτελούν συνδυασμό τεχνικών όπως
Petri Nets, SDL και activity diagrams
 Βασικό τους σύμβολο είναι μια
«κατάσταση δραστηριότητας» ή απλώς
δραστηριότητα
 Περιγράφουν την ακολουθία των
δραστηριοτήτων και παρέχει υποστήριξη
τόσο για υπο-συνθήκη όσο και
παράλληλη συμπεριφορά
Διχάλα
Έναρξη
Παραλαβή
παραγγελίας
Διακλάδωση
Συμπλήρωση Αποστολή
παραγγελίας τιμολογίου
[Βιαστική]
[Αλλιώς]
Πληρωμή
Κανονική
Άμεση Παράδοση
Παράδοση
Συγχώνευση Ένωση
Κλείσιμο
Παραγγελίας
Τέλος

Διάγραμμα δραστηριότητας
 Μια διακλάδωση έχει μια μόνο εισερχόμενη μετάβαση
και πολλές φρουρούμενες εξερχόμενες
 Μια συγχώνευση έχει πολλές εισερχόμενες και μία μόνο
έξοδο
 Μια διχάλα έχει μια εισερχόμενη μετάβαση και πολλές
εξερχόμενες. Όταν συμβαίνει η εισερχόμενη μετάβαση
ακολουθούνται παράλληλα όλες οι εξερχόμενες
 Μια ένωση σημαίνει το συγχρονισμό κάποιων
παράλληλων διαδικασιών. Η εξερχόμενη μετάβαση
ακολουθείται μόνο όταν συμβούν όλες οι εισερχόμενες

Διάσπαση μιας δραστηριότητας
 Μια δραστηριότητα μπορεί να διασπαστεί
σε υποδραστηριότητες
 Τα πλεονεκτήματα της διάσπασης και της
ύπαρξης συγκεκριμένης αρχής και τέλους
είναι ότι η δραστηριότητα μπορεί να
χρησιμοποιηθεί και σε άλλα διαγράμματα

Διάσπαση μιας δραστηριότητας

Παραλαβή
Πληρωμή
Κανονική
Άμεση Παράδοση
Παράδοση
Κλείσιμο

Διάδρομοι (swimlanes)
 Τα διαγράμματα δραστηριότητας σας
λένε τι συμβαίνει αλλά δε σας λένε ποιος
το κάνει
 Οι διάδρομοι είναι ένας τρόπος να λύσετε
το πρόβλημα
 Διαρρυθμίστε το διάγραμμα σε
κατακόρυφες ζώνες που χωρίζονται με
γραμμές

Τμήμα Διεκπεραίωσης Τμήμα εξυπηρέτησης Τμήμα Οικονομικών
Παραλαβή
Πληρωμή
Πληρωμή
Κλείσιμο

Που χρησιμοποιούνται τα
διαγράμματα δραστηριότητας
 Στην ανάλυση μιας περίπτωσης χρήσης

για να βρείτε ποιες ενέργειες χρειάζονται
και ποιες εξαρτήσεις υπάρχουν
 Στην κατανόηση της ροής των εργασιών
 Στην περιγραφή ενός πολύπλοκου
σειριακού αλγορίθμου
 Στο χειρισμό πολυνηματικών (multi-
threaded) εφαρμογών

Που δε χρησιμοποιούνται τα
διαγράμματα δραστηριότητας
 Όταν προσπαθείτε να δείτε πώς

συνεργάζονται τα αντικείμενα
 Όταν προσπαθείτε να δείτε πώς
συμπεριφέρεται ένα αντικείμενο στη
διάρκεια της ζωής του
 Για την απεικόνιση πολύπλοκης υπό
συνθήκη λογικής. Χρησιμοποιήστε έναν
πίνακα αλήθειας

4η Διάλεξη
αλληλεπίδρασης

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

 Τα διαγράμματα αλληλεπίδρασης είναι
δύο ειδών
 Διαγράμματα ακολουθίας (sequence
diagrams)
 Διαγράμματα συνεργασίας (collaboration
diagrams)

 Έστω ότι θέλετε να αναπαραστήσετε την
ακόλουθη ροή των γεγονότων.
 Ένας πελάτης (o Jim) δίνει την παραγγελία του μέσα
από μια φόρμα
 Η παραγγελία μπορεί να έχει παραπάνω από ένα
στοιχεία (π.χ. Έναν υπολογιστή και έναν εκτυπωτή)
 Αφού δημιουργηθεί η παραγγελία πρέπει να
ετοιμαστεί κάθε στοιχείο της παραγγελίας για
παράδοση.
 Για κάθε στοιχείο ελέγχουμε αν υπάρχει στην
αποθήκη.
 Αν υπάρχει στην αποθήκη το παραδίδουμε και
μειώνουμε αντίστοιχα το απόθεμα της αποθήκης.
 Αν δεν υπάρχει και χρειάζεται να το παραγγείλουμε
από τον προμηθευτή μας τότε δημιουργούμε μια νέα
παραγγελία προς τον προμηθευτή
 Μπορείτε να χρησιμοποιήσετε για την
αναπαράσταση της ροής αυτών των
γεγονότων το ακόλουθο διάγραμμα
ακολουθίας
 Σε αυτό το διάγραμμα κάθε
παραλληλόγραμμο αφορά και ένα
αντικείμενο

Διαγράμματα ακολουθίας Αντικείμενο
JimsOrderForm: JimsOrder: JimsOrderItem: JimsStockItem: NewOrderItem: JimsDeliveredItem:

Φόρμα Παραγγελί ΣτοιχείοΠαραγγελία Αποθήκη ΠαραγγελίαΠροϊόντο Παράδοση
Παραγγελίας α ς ς
αυτόκληση
μήνυμα
Γραμμή ζωής
(lifeline)
επανάληψη Δημιουργία

Επεξήγηση του διαγράμματος

 Το αντικείμενο JimsOrderForm στέλνει ένα μήνυμα
ετοίμασε() στο αντικείμενο JimsOrder
 Για κάθε στοιχείο παραγγελίας, το αντικείμενο
JimsOrder στέλνει ένα μήνυμα ετοίμασεΠροϊον()
στο αντικείμενο JimsOrderItem
 To αντικείμενο JimsOrderItem στέλνει ένα μήνυμα
έλεγξεΑποθήκη() στο αντικείμενο JimsStockITem
και αποθηκεύει το αποτέλεσμα στη μεταβλητή
ΥπάρχειΣτοΣτοκ
 Το αντικείμενο JimsStockITem στέλνει ένα μήνυμα
στον εαυτό του χρειάζεταιΠαραγγελία() και
αποθηκεύει το αποτέλεσμα στη μεταβλητή
χρειάζεταιΠαραγγελία
 Αν η μεταβλητή χρειάζεταιΠαραγγελία είναι
αληθής τότε το αντικείμενο AthensStock στέλνει ένα
μήνυμα νέο στο αντικείμενο ΝewOrderItem ...
Διαγράμματα ακολουθίας
 Στα διαγράμματα ακολουθίας μπορείτε να
προσθέσετε και επεξηγηματικά σχόλια

Σχόλια Χρησιμοποιήστε τη
διακεκομμένη γραμμή όταν δεν έχετε
Όταν νέο
Παράδειγμα να τονίσετε κάτι σημαντικό για
το αντικείμενο στο συγκεκριμένο
χρονικό διάστημα
JimsOrder
δημιουργείται
μιασυναλλαγή
...δημιουργεί έναν νέο :Συντονιστής
συντονιστήγιατη Συναλλαγής
διαχείρισητω ν
ελέγχω ν
Έ ναςσυντονιστής νέο
Έναςπ ρώτος
δημιουργεί μιασειρά
απ όΕλεγκτές,έναγια Ελεγκτης:
κάθεείδοςελέγχου νέο Ένας
Δεύτερος
Ελεγκτής:
Ανέναςέλεγχος
αποτύχει τότεο
Συντονιστήςτερματίζει
αποτυχία
όλουςτουςάλλους
πουεκτελούνται ακόμα
τερμάτισετους
Επιστροφή ελεγκτές
γίνεΆκυρη τερμάτισε
...και λέει στη
Συναλλαγήπ ω ςείναι
άκυρη
Εντολή να
διαγραφεί το
αντικείμενο
Αυτοδιαγραφή Υποέργο «Αυτεπιστασία του τμήματος Πληροφορικής και Επικοινωνιών»,
10
Διαγράμματα ακολουθίας
 Στα διαγράμματα ακολουθίας
προσπαθήστε να δείξετε μία
συγκεκριμένη περίπτωση φορά
 Αν υπάρχουν πολλές εναλλακτικές ροές
κάντε και πολλά διαγράμματα

Διαγράμματα συνεργασίας
 Σε ένα διάγραμμα συνεργασίας τα
αντικείμενα απεικονίζονται ως εικονίδια
 Όπως και σε ένα διάγραμμα ακολουθίας
τα βέλη απεικονίζουν αποστολές
μηνυμάτων στο πλαίσιο της
αναπαράστασης μιας συγκεκριμένης
λειτουργίας

Διάγραμμα συνεργασίας

Επεξήγηση διαγράμματος
 Το αντικείμενο JimsOrderForm στέλνει ένα μήνυμα
ετοίμασε() στο αντικείμενο JimsOrder
 Για κάθε στοιχείο παραγγελίας, το αντικείμενο
JimsOrder στέλνει ένα μήνυμα ετοίμασεΠροϊον()
στο αντικείμενο JimsOrderItem
 To αντικείμενο JimsOrderItem στέλνει ένα μήνυμα
έλεγξεΑποθήκη() στο αντικείμενο JimsStockITem
και αποθηκεύει το αποτέλεσμα στη μεταβλητή
ΥπάρχειΣτοΣτοκ
 Το αντικείμενο JimsStockITem στέλνει ένα μήνυμα
στον εαυτό του χρειάζεταιΠαραγγελία() και
αποθηκεύει το αποτέλεσμα στη μεταβλητή
χρειάζεταιΠαραγγελία
 Αν η μεταβλητή χρειάζεταιΠαραγγελία είναι
αληθής τότε το αντικείμενο AthensStock στέλνει ένα
μήνυμα νέο στο αντικείμενο ΝewOrderItem ...
Διαγράμματα συνεργασίας
 Στα διαγράμματα συνεργασίας η αρίθμηση των
μηνυμάτων δείχνει την ακολουθία τους
 Αυτό μπορεί να κάνει πιο δύσκολη την
παρακολούθηση της ακολουθίας σε σχέση με
την παράθεση των μηνυμάτων από πάνω προς
τα κάτω
 Όμως μπορείτε να δείξετε πιο εύκολα πως
συνδέονται τα αντικείμενα μεταξύ τους

 Η μέθοδος ονομασίας των αντικειμένων
που εμφανίζεται στα διαγράμματα
αλληλεπίδρασης ακολουθεί τη μορφή:
– Όνομα αντικειμένου: όνομα κλάσης
 Πολλές φορές μπορεί να αναγράψουμε
μόνο το ένα από τα δύο, δηλ.
– Όνομα αντικειμένου:
– :Όνομα κλάσης ή Όνομα κλάσης

Διαγράμματα ακολουθίας -
συνεργασίας
 Τα δύο είδη διαγραμμάτων είναι
ισοδύναμα
 Απλά κάποιες φορές είναι πιο εύκολο
(οπτικά) να αναπαραστήσουμε την
πληροφορία είτε με τον ένα είτε με τον
άλλο τρόπο

Τι είδους μηνύματα υπάρχουν;

 Τα μηνύματα από ένα αντικείμενο σε ένα άλλο
στα διαγράμματα αλληλεπίδρασης μπορεί να
είναι:
 Απλά
 O έλεγχος περνάει από το ένα αντικείμενο στο άλλο, χωρίς
να περιγράφονται άλλες λεπτομέρειες
 Σύγχρονα
 Υλοποιούνται σαν μια κλήση συνάρτησης.
 Ασύγχρονα
 O αποστολέας συνεχίζει να εκτελεί τις υπόλοιπες
λειτουργίες του αφού στείλει το μήνυμα , χωρίς να
περιμένει για την διαχείρισή του.

Αναπαράσταση μηνυμάτων
Σύγχρονα
Ασύγχρονα
Απλά
Σύγχρονα με άμεση
επιστροφή
Πότε χρησιμοποιούνται τα
διαγράμματα αλληλεπίδρασης
 Όταν θέλετε να μελετήσετε τον τρόπο με

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

5η Διάλεξη
UML – Χάρτες κατάστασης

Χάρτες καταστάσεων
(Statecharts)
 Η UML μας δίνει σαν εργαλείο τους

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

 Έστω ότι είχαμε μια κλάση
«Παραγγελία»
 Έστω ότι ξέραμε ότι μια «Παραγγελία»
μπορεί να είναι είτε «Ανοιχτή» (που
σημαίνει ότι μόλις παραλήφθηκε) είτε
«Υπό εκτέλεση» (που σημαίνει ότι
κάποιος ανέλαβε να την διεκπεραιώσει)
είτε «Ολοκληρωμένη» (που σημαίνει ότι
η παραγγελία έχει αποσταλεί στον
πελάτη).
 Θα ήταν χρήσιμο να αποδίδαμε την πιο
πάνω περιγραφή και γραφικά
Οι «καταστάσεις» μιας παραγγελίας

(statecharts)
 Είναι μια πολύ γνωστή τεχνική για την

καταγραφή συστημάτων και περιγράφουν
όλες τις πιθανές καταστάσεις στις οποίες
μπορεί να βρεθεί ένα αντικείμενο
 Ειδικά στις αντικειμενοστραφείς τεχνικές
ανάπτυξης τα διαγράμματα κατάστασης
σχεδιάζονται για μια κλάση και δείχνουν
τη συμπεριφορά ενός αντικειμένου αυτής
της κλάσης στη διάρκεια της ζωής του

(Statecharts)
 Σε ένα χάρτη καταστάσεων συμβαίνουν κάποιες
ενέργειες οι οποίες αλλάζουν την κατάσταση
του συστήματος και τις δραστηριότητες που
μπορούν να εκτελεστούν
 Συνήθως η τριπλέτα Συμβάν[Συνθήκη]/Ενέργεια
σημαίνει ότι αν συμβεί το “Συμβάν” και η
“Συνθήκη” είναι αληθής τότε εκτελείται η
“Ενέργεια” και ολοκληρώνεται η μετάβαση από
μια κατάσταση σε μια άλλη.
 Ενόσω το σύστημα είναι σε μια κατάσταση
μπορεί να ολοκληρώσει διάφορες δραστηριότητες

Συμβάν [Φρουρός] / Ενέργεια
Έναρξη
Μετάβαση
Δραστηριότητα
/πάρε το πρώτο στοιχείο
[δεν έχουν ελεγθεί όλα τα στοιχεία]

/πάρε το επόμενο στοιχείο
Έλεγχος Διεκπεραίωση
κάνε/έλεγξε κάνε/ξεκίνησε την
στοιχείο παράδοση
Στοιχείο Παραλήφθηκε
[Όλα τα στοιχεία είναι διαθέσιμα]
Παραδόθηκε
Όλα τα στοιχεία ελέγθηκαν && κάποια
[στοιχεία δεν υπάρχουν στην αποθήκη]
Προϋπόθεση αυτομετάβαση
Αναμονή Παραδόθηκε
Στοιχείο παραλήφθηκε
[κάποια στοιχεία δεν υπάρχουν στην αποθήκη]

 Έστω ότι έχουμε μία κλάση που αφορά
ένα πρωτόκολλο εισόδου (Login Protocol)
 Σε αυτό το πρωτόκολλο αφού πάρουμε
εντολή στέλνουμε ένα αίτημα Login
περιμένουμε μια απάντηση OK.
(LoginSent)
 Αν η απάντηση είναι θετική θεωρούμε ότι
η είσοδος είναι πετυχημένη (LoginDone)
 Αν η απάντηση είναι αρνητική θεωρούμε
ότι η είσοδος είναι αποτυχημένη
(LoginRejected)
 Αν αργήσουμε να πάρουμε απάντηση για
πάνω από 30sec τότε έχουμε ένα
Timeout και ξαναπροσπαθούμε για το
πολύ 3 φορές.
 Την 3η φορά θεωρούμε ότι αποτύχαμε
στην είσοδο (LoginFailed)
 Επίσης ακυρώνουμε την ενέργεια
οποτεδήποτε η συνθήκη cancelIsPressed
γίνει αληθής οπότε και ακυρώνουμε την
είσοδο (LoginCancelled)
Αναπαράσταση με StateCharts

4 είδη συμβάντων
 Στο διάγραμμα αυτό βλέπουμε και τα 4
πιθανά είδη συμβάντων που μπορούν να
μας μεταφέρουν από μία κατάσταση σε μια
άλλη:
 CallEvent: λήψη ενός μηνύματος, π.χ.
sendLogin
 SignalEvent: λήψη ενός σήματος, π.χ.
OKReceived
 ChangeEvent: συνθήκη γίνεται αληθής, π.χ.
when(cancelIedPressed)
 TimeEvent: σχετικό ή απόλυτο σημείο στο
χρόνο, π.χ. after(30 sec)
Διαφορές
 Signal Event-Call Event
 Ένα Call Event είναι συνήθως η κλήση
μιας συνάρτησης
 Ένα Signal Event είναι συνήθως η λήψη
ενός ασύγχρονου σήματος από ένα άλλο
αντικείμενο (π.χ. ButtonClicked)

Διαφορές
 Change Event – Συνθήκη
 Ένα change event αξιολογείται συνεχώς
ενόσω ήμαστε σε μια κατάσταση (π.χ.
cancelIsPressed)
 Μια συνθήκη (guard) που αναφέρεται σε
μια μετάβαση αξιολογείται μόνο όταν
πρόκειται να γίνει μια μετάβαση
(retries<3)

Υπερκαταστάσεις
 Όταν από πολλές καταστάσεις υπάρχει η
ίδια μετάβαση στην ίδια κατάσταση τότε
μπορούμε να χρησιμοποιήσουμε την
έννοια της υπερκατάστασης

Ενεργός
[δεν έχουν ελεγθεί όλα τα στοιχεία]

/πάρε το επόμενο στοιχείο
κάνε/έλεγξε κάνε/ξεκίνησε την
στοιχείο παράδοση
Στοιχείο Παραλήφθηκε
[Όλα τα στοιχεία είναι διαθέσιμα]
Όλα τα στοιχεία ελέγθηκαν && κάποια
[στοιχεία δεν υπάρχουν στην αποθήκη]
Αναμονή
Στοιχείο παραλήφθηκε
[κάποια στοιχεία δεν υπάρχουν στην αποθήκη]
Ακύρωση

Ταυτοχρονισμός
 Υπάρχουν επίσης πολλά προβλήματα τα
οποία εμπεριέχουν την έννοια της
παραλληλίας
 Για παράδειγμα όσο γίνεται ο έλεγχος για
μια παραγγελία στην αποθήκη,
ταυτόχρονα γίνεται έλεγχος για την
πληρωμή της παραγγελίας

Ακυρώθηκε
Αναμονή
Έγκριση Εγκρίθηκε
Απορρίφθηκε

Που χρησιμοποιούνται οι χάρτες

καταστάσεων
 Είναι κατάλληλοι για την περιγραφή της
συμπεριφοράς ενός αντικειμένου που
περιλαμβάνεται σε πολλές περιπτώσεις
χρήσης
 Δεν είναι κατάλληλοι για την περιγραφή
συμπεριφορών που περιλαμβάνουν έναν
αριθμό συνεργαζόμενων αντικειμένων

6η Διάλεξη
Διαδικασίες ανάπτυξης

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

 Στις προηγούμενες διαφάνειες είδαμε κάποια
από τα διαγράμματα που προσφέρει η UML
 Στις επόμενες διαφάνειες θα δούμε πως
μπορούν να υιοθετηθούν τα διαγράμματα
αυτά σε μια δομημένη διαδικασία ανάπτυξης

Διαδικασίες Ανάπτυξης
 Μια διαδικασία ανάπτυξης ορίζει τα βήματα

και τις ενέργειες που πρέπει να γίνουν για να
υλοποιηθεί ένα προϊόν λογισμικού
 Μια διαδικασία ανάπτυξης στόχο έχει να

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

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

Τι περιλαμβάνει μια διαδικασία
ανάπτυξης
 Τα συνηθισμένα στάδια ανάπτυξης

λογισμικού είναι τα ακόλουθα:
 Καταγραφή και ανάλυση απαιτήσεων
 Σχεδίαση
 Υλοποίηση
 Έλεγχος μονάδων, ολοκλήρωσης και
 Λειτουργία και συντήρηση

Ποια είναι η σωστή διαδικασία;

 Δεν υπάρχει μια και μοναδική διαδικασία.
Διαφορετικά έργα χρειάζονται
διαφορετικές διαδικασίες και έχουν
διαφορετικές ανάγκες
 Οι διαδικασίες συνήθως διαφέρουν στο
“πότε” και “για πόσο” εφαρμόζουν κάθε
ένα από τα προηγούμενα στάδια

Γνωστές Διαδικασίες Ανάπτυξης
Κάποιες γνωστές διαδικασίες ανάπτυξης είναι οι
ακόλουθες:
– Καταρράκτης
– Ενοποιημένη Διαδικασία
– Ακραίος Προγραμματισμός
– Ανάπτυξη Βασισμένη σε πρότυπα
– Διαδικασίες βασισμένες σε φορμαλιστικά μοντέλα
– Σπειροειδής διαδικασία ανάπτυξης

Επαναληπτική και προσθετική

διαδικασία
 Μέσα από την εμπειρία πολλών χρόνων

διαπιστώθηκε ότι μια διαδικασία ανάπτυξης
πρέπει να έχει 2 βασικά χαρακτηριστικά:
 Επανάληψη
 Το λογισμικό αναπτύσσεται μέσα από πολλές
επαναλήψεις και ολοκληρώνεται σιγά-σιγά
 Πρόσθεση
 Το λογισμικό αναπτύσσεται και σιγά-σιγά του
προστίθεται νέα λειτουργικότητα

Επαναληπτική και προσθετική
διαδικασία
 Χωρίζει ένα έργο σε μικρά κομμάτια ή
μικρότερα έργα.
 Υλοποιεί το έργο σε πολλές επαναλήψεις
 Κάθε φορά επιλέγεται ένα κομμάτι του
έργου προς υλοποίηση και σιγά-σιγά
προστίθενται οι λειτουργίες του

Η σχεδίαση των επαναλήψεων

Σε κάθε επανάληψη μόνο ένα κομμάτι του έργου
υλοποιείται
Η επιλογή βασίζεται συνήθως στη
λειτουργικότητα που θέλετε να προσθέσετε
Ποιες λειτουργίες θεωρεί σημαντικές ο πελάτης;
Ποιες λειτουργίες είναι απαραίτητες για να θεμελιωθεί
σωστά το έργο;
στο ρίσκο που θα έχει η υλοποίηση
Ποιες είναι οι λειτουργίες που η υλοποίησή τους αποτελεί
κίνδυνο για το έργο;

Τα βήματα της κάθε επανάληψης
 Στις επόμενες διαλέξεις παρουσιάζονται τα
βήματα που μπορούν να ακολουθηθούν σε
μία επανάληψη
 Τα βήματα αυτά βασίζονται στη διαδικασία
ανάπτυξης UP (Unified Process)
 Αποτελούν έναν μόνο από τους πολλούς
τρόπους που μπορούν να υιοθετηθούν για
την ολοκλήρωση μιας επανάληψης

7η Διάλεξη
Η καταγραφή των απαιτήσεων

Καταγραφή απαιτήσεων
 Μια διαδικασία ανάπτυξης ξεκινά συνήθως

με την καταγραφή απαιτήσεων
 Το βήμα αυτό είναι και το πιο σημαντικό
γιατί προσπαθούμε να καταλάβουμε τι
πρέπει να κάνουμε
 Ένας αρκετά συνηθισμένος τρόπος
καταγραφής απαιτήσεων είναι οι
περιπτώσεις χρήσης

Καταγραφή απαιτήσεων
 Σε μια επαναληπτική διαδικασία

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

Απαιτήσεις
 Με τον όρο “απαίτηση” εννοούμε ένα
χαρακτηριστικό που πρέπει να έχει το
σύστημα προκειμένου να εκπληρώνει το
σκοπό του.
 Οι απαιτήσεις περιγράφουν τι θέλουμε να
κάνει το σύστημα, αλλά όχι πως να το
κάνει
 Η καταγραφή τους είναι το πρώτο και το
πιο σημαντικό βήμα που πρέπει να
κάνετε
Η διαδικασία συλλογής και

καταγραφής απαιτήσεων
 Μπορεί να περιλαμβάνει διάφορα στάδια:

 συζήτηση με τον πελάτη,
παρουσίαση ανάλογων συστημάτων
και κατανόηση του συστήματος
 ορισμός των απαιτήσεων σε κάποιο
κείμενο
 Επαλήθευση ότι οι απαιτήσεις δεν
αλληλοαναιρούνται

Κάποιες απαιτήσεις είναι πιο
σημαντικές
 Κάποιες απαιτήσεις πρέπει να

υλοποιηθούν οπωσδήποτε
 Κάποιες είναι περισσότερο αναγκαίες
από κάποιες άλλες
 Και κάποιες μπορούν να μην
υλοποιηθούν

Λειτουργικές και μη-λειτουργικές

απαιτήσεις
 Οι απαιτήσεις μπορεί να είναι λειτουργικές
ή μη-λειτουργικές
 Οι απαιτήσεις λειτουργικότητας αφορούν
κυρίως τις συναλλαγές του συστήματός μας
με το περιβάλλον του: τι μπορεί να δεχθεί
σαν είσοδο και τι θα δώσει σαν έξοδο
 Μη λειτουργικές απαιτήσεις είναι αυτές που
θέτουν περιορισμούς στο σύστημα, πχ: το
σύστημα πρέπει να μπορεί να δουλεύει
χωρίς πρόβλημα για τουλάχιστον 25 ώρες
Βήματα για την καταγραφή των
απαιτήσεων
 Βήμα 1
 Ζητήστε μια περιγραφή του προβλήματος
που προσπαθείτε να λύσετε. Την
περιγραφή αυτή θα σας τη δώσει ο
πελάτης σας, οι χρήστες του συστήματος
που θα υλοποιήσετε ή ακόμα και οι
ανταγωνιστές σας!
 Βήμα 2
 Φτιάξτε ένα γλωσσάρι που να εξηγεί τους
πιο σημαντικούς ή τους πιο κοινούς
όρους που χρησιμοποιούν οι πελάτες
8 σας για να περιγράψουν
Υποέργο τις διαδικασίες
1 «Αυτεπιστασία του τμήματος Πληροφορικής και Επικοινωνιών»,
που ακολουθούν
 Βήμα 3
 Κάντε μια βασική καταγραφή και αρίθμηση των
απαιτήσεων που πρέπει να πληροί το σύστημά σας
 Βήμα 4
 Βρείτε πόσους διαφορετικούς τύπους χρηστών έχει το
σύστημα που θα φτιάξετε
 Βήμα 5
 Βρείτε τις βασικές έννοιες(κλάσεις) του συστήματός
σας (domain model) και αναπαραστήστε τες με ένα
διάγραμμα κλάσεων

 Βήμα 6
 Βρείτε τις περιπτώσεις χρήσης. Φτιάξτε μια
περίπτωση χρήσης για τη
δημιουργία/αλλαγή/διαγραφή των βασικών
εννοιών του συστήματός σας
 Βήμα 7
 Περιγράψτε τις περιπτώσεις χρήσης και δώστε
και μια συνολική περιγραφή του συστήματός
σας.

Πώς ανακαλύπτουμε τις βασικές

κλάσεις ενός συστήματος;
 Κοιτάξτε την περιγραφή του

προβλήματος που σας έχουν δώσει.
 Υπογραμμίστε ό,τι ουσιαστικά
εμφανίζονται
 Υπογραμμίστε ό,τι οργανισμοί, ό,τι ρόλοι
εμφανίζονται

 Ποιες κλάσεις αναγνωρίζετε στην
παρακάτω περιγραφή;
 Φτιάξτε ένα σύστημα που να το χρησιμοποιούν οι
μαθητές για να αξιολογούν τα βιβλία τους. Οι
προϊστάμενοι του ΤΕΙ ή οι γραμματείς τους θα
μπορούν να εισάγουν νέα βιβλία για αξιολόγηση
και να βλέπουν τις αξιολογήσεις που έχουν γίνει.
Οι εκδότες θα πρέπει να μπορούν να εισέρχονται
στο σύστημα και να βλέπουν τις αξιολογήσεις
που έχουν γίνει. Τέλος ένας ειδικός χρήστης θα
μπορεί να δημιουργεί νέους χρήστες (πχ
προϊσταμένους, εκδότες κτλ).

Προσοχή
 Πολλοί κάνουν το λάθος και προσπαθούν
να ανακαλύψουν ενέργειες όταν
διαβάζουν μια περιγραφή ενός
προβλήματος
 Αυτός ήταν ο τρόπος δημιουργίας
προγραμμάτων στο διαδικασιακό
προγραμματισμό (procedural
programming)

 Ένας μαθητής εγγράφεται σε ένα
μάθημα, ή μπορεί να διαγραφεί από αυτό

Λύση
 Λανθασμένη λύση
 Υπάρχει η κλάση μαθητής, η κλάση
εγγραφή και η κλάση διαγραφή
 Αυτή η προσέγγιση είναι λάθος!
 Έτσι θα σκεφτόσασταν αν φτιάχνατε
συναρτήσεις στη C αλλά όχι στον
αντικειμενοστραφή προγραμματισμό!
 Ορθότερη λύση
 Υπάρχει η κλάση μαθητής και η κλάση
μάθημα
Χαρακτηριστικά (attributes)
 Κάθε κλάση έχει κάποια χαρακτηριστικά ή
ιδιότητες
 Για παράδειγμα μια κλάση «Τραπεζικός
Λογαριασμός» θα έχει ως χαρακτηριστικό
ένα «Αριθμό Λογαριασμού»
 Για παράδειγμα η «Πιστωτική κάρτα» έχει
ως χαρακτηριστικά (αριθμό, τύπο και PIN)

Μέθοδοι
 Συνήθως στα αντικείμενα μιας κλάσης
μπορούν να γίνουν και κάποιες ενέργειες.
Για παράδειγμα στα αντικείμενα της
κλάσης Πιστωτική Κάρτα θα μπορούσε
να γίνει η ενέργεια «Χρέωση» ή
«Συναλλαγή»

Πως βρίσκουμε τις μεθόδους;
 Ψάξτε στην περιγραφή του προβλήματος
σας για ρήματα. Αυτά συνήθως
δηλώνουν ενέργειες που μπορούν να
γίνουν σε μια κλάση ή λειτουργίες που
ξέρει να διεκπεραιώνει.

 Φτιάξτε ένα σύστημα που να το χρησιμοποιούν οι
μαθητές για να αξιολογούν τα βιβλία τους. Οι
προϊστάμενοι του ΤΕΙ ή οι γραμματείς τους θα μπορούν
να εισάγουν νέα βιβλία για αξιολόγηση και να βλέπουν
τις αξιολογήσεις που έχουν γίνει. Οι εκδότες θα πρέπει
να μπορούν να εισέρχονται στο σύστημα και να
βλέπουν τις αξιολογήσεις που έχουν γίνει. Τέλος ένας
ειδικός χρήστης θα μπορεί να δημιουργεί νέους χρήστες
(πχ προϊσταμένους, εκδότες κτλ).

 Μια κλάση μπορεί να συσχετίζεται με μια
άλλη.
 Στο παράδειγμα με τους μαθητές και τα
βιβλία, ένας μαθητής μπορεί να
συσχετιστεί με τα βιβλία που έχει
αξιολογήσει

 Μια συσχέτιση απλά τονίζει συνήθως ότι
μια κλάση έχει ως χαρακτηριστικό, κάτι
που από μόνο του είναι και αυτό μια
κλάση.
 Για παράδειγμα ένας πελάτης έχει μια
διεύθυνση. Και ο «πελάτης» είναι κλάση
και η διεύθυνση είναι «κλάση». Επειδή η
κλάση πελάτης περιέχει ως
χαρακτηριστικό την κλάση «Διεύθυνση»
μπορούμε να πούμε ότι η κλάση πελάτης
σχετίζεται με την κλάση διεύθυνση
Ένα ακόμα παράδειγμα
 Ένα ηλεκτρονικό κατάστημα έχει πελάτες
είτε εταιρείες είτε ιδιώτες.
 Οι εταιρείες έχουν έκπτωση στα προϊόντα
που αγοράζουν ενώ οι ιδιώτες όχι. Οι
ιδιώτες μπορούν να ζητούν δώρα από το
κατάστημα αν κάνουν πολλές αγορές
 Κάθε εταιρεία δηλώνει τη διεύθυνση, την
επωνυμία και το ΑΦΜ της
 Κάθε ιδιώτης δηλώνει μόνο τη διεύθυνση
και την επωνυμία του
(συνέχεια)
 Υπάρχει η κλάση προϊόν, η κλάση
πελάτης, η κλάση εταιρεία και η κλάση
ιδιώτης
 Οι τρεις τελευταίες όμως έχουν πολλά
κοινά μεταξύ τους!
 Στον αντικειμενοστραφή προγραμματισμό
προσπαθούμε να βρούμε τέτοιες κλάσεις
που έχουν κοινά στοιχεία

Κληρονομικότητα
 Χρησιμοποιούμε την κληρονομικότητα ως εξής
 Ορίζουμε την κλάση πελάτης με
 τα κοινά χαρακτηριστικά των κλάσεων εταιρεία,
ιδιώτης
 τις κοινές ενέργειες που μπορούν να κάνουν οι
δύο κλάσεις
 Ορίζουμε ότι την κλάση εταιρεία με
 μόνο τα ιδιαίτερα χαρακτηριστικά της
 και τις ιδιαίτερες ενέργειες
 Παρόμοια ορίζουμε και την κλάση ιδιώτης
 Τα υπόλοιπα χαρακτηριστικά τους τα
«κληρονομούν» από την κλάση «Πελάτης»

8η Διάλεξη
Παραγωγή περιπτώσεων χρήσης από

τις απαιτήσεις ενός πελάτη

Η απαίτηση του πελάτη
 Κατασκευάστε ένα σύστημα
καταχώρησης ονομάτων χώρου

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

στους χρήστες τους να δημιουργήσουν
ονόματα χώρου. Σε κάθε όνομα χώρου
ο χρήστης μπορεί να αντιστοιχίσει 4
υπευθύνους (Ιδιοκτήτης, Τεχνικός
Υπεύθυνος, Υπεύθυνος Χρέωσης και
Υπεύθυνος διαχείρισης) καθώς και 4
εξυπηρετητές ονοματοδοσίας.

Συνέχεια της περιγραφής

 Για την καλύτερη διαχείριση των
ονομάτων, ο χρήστης έχει τη δυνατότητα
να δημιουργήσει προφίλς ή πελάτες,
τετράδες υπευθύνων και εξυπηρετητών
δηλαδή. Έτσι όταν πρόκειται να
δημιουργήσει ένα όνομα χώρου ο
χρήστης απλά επιλέγει το προφίλ που θα
χρησιμοποιήσει για το συγκεκριμένο
όνομα χώρου.

Και μετά;
 Σε αυτό το σημείο έχετε μια πρώτη
καλύτερη επαφή με το αντικείμενο του
συστήματός σας, αλλά δεν ξέρετε ακόμα
τις βασικές έννοιες του
 Αρχίστε με ένα γλωσσάρι

Βήμα 2 Γλωσσάρι
 Όνομα χώρου
 Αντιστοιχεί σε μια IP διεύθυνση (π.χ. teiser.gr)
 Υπεύθυνος
 Ένα άτομο το οποίο έχει κάποια αρμοδιότητα
πάνω σε ένα όνομα χώρου. Μπορεί να είναι ο
ιδιοκτήτης, ο τεχνικός υπεύθυνος, ο υπεύθυνος
διαχείρισης ή ο υπεύθυνος χρέωσης
 Εξυπηρετητής ονοματοδοσίας
 Ένας εξυπηρετητής που γνωρίζει την IP διεύθυνση
ενός ονόματος (name server)
 Προφίλ/Πελάτης
 Μια τετράδα υπευθύνων και εξυπηρετητών

Περιγράψτε ένα σενάριο
 Ο χρήστης φτιάχνει το προφίλ
“Something” στο οποίο αντιστοιχεί τους
κατάλληλους υπεύθυνους και τους
κατάλληλους εξυπηρετητές
ονοματοδοσίας
 Στη συνέχεια αν θέλει να καταχωρήσει τα
ονόματα “something.com” και
“something.org” λέει στο σύστημα ότι θα
χρησιμοποιήσει για αυτά το προφίλ
“Something”
Γιατί τα κάναμε όλα αυτά;

 Όλες οι προηγούμενες ενέργειες έγιναν για
να κατανοήσουμε καλύτερα το πρόβλημα
που έχουμε να λύσουμε.
 Δεν είναι όλες οι εφαρμογές που
αναπτύσσουμε κατανοητές, ούτε οι
πελάτες μας έχουν πάντα κάτι ξεκάθαρο
στο μυαλό τους
 Και η συνέχεια…; προσπαθήστε να κάνετε
μια αρχική καταγραφή των απαιτήσεων τις
οποίες πρέπει να ακολουθήσετε
Βήμα 3 Αριθμήστε τις απαιτήσεις
Περιγραφή συστήματος κατοχύρωσης ονομάτων χώρου
Ένα σύστημα κατοχύρωσης ονομάτων χώρου επιτρέπει στους χρήστες του να

κατοχυρώνουν ονόματα χώρου και να δημιουργούν εξυπηρετητές
ονοματοδοσίας και υπεύθυνους για το όνομα.
1. Το σύστημα πρέπει να επιτρέπει σε χρήστες να εγγραφούν δωρεάν.
2. Οι μη εγγεγραμμένοι χρήστες έχουν τη δυνατότητα να εγγραφούν και να
ελέγξουν τη διαθεσιμότητα ενός ονόματος χώρου.
3. Οι εγγεγραμμένοι χρήστες αφού εισέλθουν έχουν επιπλέον τη δυνατότητα να
δημιουργήσουν προφίλ. Σε κάθε προφίλ δίνουν ένα όνομα και τους 4
εξυπηρετητές και υπεύθυνους που ανήκουν σε αυτό το προφίλ Ένας από τους
υπευθύνους θεωρείται ο ιδιοκτήτης του προφίλ Κάθε εξυπηρετητής έχει ένα
όνομα και μια διεύθυνση IP. Κάθε υπεύθυνος έχει ένα όνομα και ένα email.
4. Οι εγγεγραμμένοι χρήστες αφού εισέλθουν έχουν τη δυνατότητα να
επεξεργαστούν τα προφιλς που έχουν δημιουργήσει.
5. Οι εγγεγραμμένοι χρήστες αφού εισέλθουν έχουν τη δυνατότητα να κάνουν μια
αίτηση για την κατοχύρωση ενός ονόματος, δίνοντας το όνομα χώρου που
επιθυμούν, το προφίλ στο οποίο θα ανήκει και έναν κωδικό. Το σύστημα
επικοινωνεί με έναν εξωτερικό οργανισμό για την έγκριση ο οποίος αποδίδει
έναν αριθμό πρωτοκόλλου στην αίτηση...
Βήμα 4 Χαρακτήρες (actors)

 Το σύστημα που περιγράψαμε είναι
αρκετά απλό μέχρι τώρα και έχει μόνο
ένα χαρακτήρα (actor), τον πελάτη του
συστήματος μας, οπότε ορίζουμε απλά
μόνο τον επόμενο χαρακτήρα:
 Πελάτης:
 Το άτομο που θα χρησιμοποιεί το
σύστημα για την κατοχύρωση ονομάτων
χώρου

Και η συνέχεια;
 Δείτε την περιγραφή που έχετε για το
σύστημα
 Ξεχωρίστε τις βασικές έννοιες που
υπάρχουν σε αυτήν την περιγραφή.
 Συνήθως οι βασικές έννοιες είναι
ουσιαστικά
 Στο παράδειγμα οι βασικές έννοιες που
είχαμε ήταν το προφίλ, το όνομα
χώρου, ο υπεύθυνος, ο εξυπηρετητής
ονοματοδοσίας
Αναπαραστήστε βασικές έννοιες

Βρείτε τις βασικές σχέσεις
 Ξέρετε ότι ένα προφίλ μπορεί να

συσχετιστεί με πολλά ονόματα χώρου
συσχετιστεί με 4 εξυπηρετητές
συσχετιστεί με 4 υπευθύνους

Βήμα 5 Domain model

Έκδοση 1
Δε γίνεται διάκριση
ανάμεσα στους υπευθύνους

Βήμα 5 Domain model Ορίζουμε τους
ρόλους
Έκδοση 2
Έχουμε δώσει ονόματα
στις συσχετίσεις
Γίνεται διάκριση.
Μια έννοια μπορεί να έχει διαφορετικού
τύπου συσχετίσεις με μια άλλη

Καθορίστε τα χαρακτηριστικά της

κάθε έννοιας
 Τα χαρακτηριστικά (attributes) πρέπει να

είναι πολύ απλές έννοιες (ονόματα,
αριθμοί κτλ)
 Στη συγκεκριμένη περίπτωση μαθαίνουμε
για παράδειγμα ότι για ένα υπεύθυνο
αποθηκεύονται τα στοιχεία:
 Όνομα, τηλέφωνο, email

Βήμα 5 Domain model,
Έκδοση 3

Βήμα 6 Περιπτώσεις χρήσης

 Στη συνέχεια πρέπει να δούμε σε
μεγαλύτερο βαθμό λεπτομέρειας της
λειτουργίας του συστήματος.
 Για το λόγο αυτό συνήθως κοιτάμε πώς
δημιουργούνται, επεξεργάζονται και
διαγράφονται οι έννοιες που
περιγράψαμε προηγουμένως.
 Αυτό το κάνουμε με απλό τρόπο
καταγράφοντας τις περιπτώσεις χρήσης
Πώς θα δουλεύει το σύστημα μας
 Σκεφθείτε ότι κάθε περίπτωση χρήσης
πρέπει να είναι ολοκληρωμένη και να
δίνει αξία στο σύστημα.
 Π.χ. Θα δίνει τη δυνατότητα το σύστημά
σας στο χρήστη να δημιουργεί χωριστά
υπευθύνους ή θα το επιτρέπει μόνο κατά
τη δημιουργία του προφίλ;

Βήμα 6 Μοντέλο περιπτώσεων χρήσης

'Εκδοση 1
Ένας χαρακτήρας
Μια περίπτωση χρήσης
μπορεί να περιλάβει
κάποιες
υποπεριπτώσεις
Ο τίτλος μιας
περίπτωσης χρήσης

 Στο προηγούμενο παράδειγμα
αποφασίσαμε ότι η περίπτωση χρήσης
“Δημιούργησε υπεύθυνο” δε θα ήταν
αυτόνομη αλλά υποπερίπτωση της
περίπτωσης χρήσης “Δημιούργησε
Προφίλ”
 Πέρα όμως από τις περιπτώσεις χρήσης
δημιουργίας έχουμε και αυτές τις
επεξεργασίας και διαγραφής

Βήμα 6 Μοντέλο περιπτώσεων χρήσης

Έκδοση 2
Η σχέση extend δηλώνει ότι

μια περίπτωση χρήσης
επεκτείνει μια άλλη

 Το διάγραμμά μας αρχίζει να γεμίζει
 Επιλέγουμε να μην αναπαραστήσουμε τις
υποπεριπτώσεις “Επεξεργασία
Υπευθύνου”, “Επεξεργασία Εξυπηρετητή
Ονοματοδοσίας κτλ” μιας και μπορούν να
εννοηθούν από την περίπτωση
“Δημιουργία Προφίλ”

Ολοκληρώστε τις περιγραφές

 Κάντε παρόμοιες περιγραφές για όλες τις
περιπτώσεις χρήσης που έχετε σκεφθεί
ακόμα και αν δεν εμφανίζονται στο
διάγραμμα σας
 Προσοχή, οι περιπτώσεις χρήσης δε
καταγράφουν μη-λειτουργικές απαιτήσεις.
 Αναφέρεται απλά τις μη-λειτουργικές
απαιτήσεις στο τέλος κάθε περίπτωσης
χρήσης που επηρεάζουν
Άλλες περιπτώσεις χρήσης
 Μας ενημερώνουν ότι το σύστημα πρέπει
να επιτρέπει την αναζήτηση, προβολή
στοιχείων κτλ.
 Σημειώνετε καινούργιες περιπτώσεις
χρήσης οι οποίες υλοποιούν τη
συγκεκριμένη λειτουργικότητα
 Σε αυτό το σημείο μπορείτε να
αποφασίσετε και ποιες από τις
περιπτώσεις είναι αρκετά σημαντικές για
να υλοποιηθούν στην πρώτη επανάληψη
Βήμα 7 Περιγραφή περιπτώσεων χρήσης

Έκδοση 1
 Για κάθε περίπτωση χρήσης κάνουμε μια

σύντομη περιγραφή

Αποφασίζετε τις προτεραιότητες
 Αποφασίζετε ότι οι περιπτώσεις χρήσης
που αφορούν την αναζήτηση και
προβολή στοιχείων είναι δευτερεύουσες
και δεν αποτελούν δομικά στοιχεία του
συστήματός σας.

Επαναλάβετε όσες φορές

χρειαστεί διάφορα βήματα
 Ξαναβλέπετε το μοντέλο σας και βλέπετε

ότι κάποιες περιπτώσεις χρειάζονται
περισσότερη εμβάθυνση.
 Για παράδειγμα τι γίνεται αν κάποιος
προσπαθήσει να κατοχυρώσει ένα όνομα
χώρου που ήδη υπάρχει;

Βήμα 7 Περιγραφή περιπτώσεων χρήσης
Έκδοση 2

Βήμα 7 Ετοιμάστε μια συνολική

περιγραφή του συστήματος

Τα επόμενα βήματα
 Μέχρι τώρα είδαμε ότι η καταγραφή των
περιπτώσεων χρήσης έγινε κατά βάση με
απλά κείμενα.
 Κάποιες φορές ίσως να είναι πιο εύκολη
μια περισσότερο τεχνική περιγραφή μιας
περίπτωσης χρήσης.
 Για το σκοπό αυτό μπορούμε να
χρησιμοποιήσουμε τα διαγράμματα
δραστηριότητας της UML.

Μπορούμε να φτιάξουμε ένα «διάγραμμα

δραστηριότητας»

Μετά;
 Σε αυτό το σημείο έχουμε μια κατανόηση
των βασικών εννοιών και λειτουργιών του
συστήματος που θέλουμε να
αναπτύξουμε.
 Μπορούμε να προχωρήσουμε σε
ανάλυση και σχεδίαση, έχοντας πάντα
όμως στο νου μας ότι θα χρειαστεί να
ξαναδούμε τις απαιτήσεις για να
ορίσουμε διάφορα σημεία με μεγαλύτερη
λεπτομέρεια
9η Διάλεξη
Η ανάλυση των απαιτήσεων

Η ανάλυση
 Αναλύουμε τις απαιτήσεις προκειμένου
να τις βελτιώσουμε και να τις δομήσουμε
καλύτερα προκειμένου να αναδείξουμε
την αρχιτεκτονική του συστήματος
 Η ανάλυση βοηθά να ξεκαθαρίσουμε
θέματα που μπορεί να έμειναν
αδιευκρίνιστα κατά την καταγραφή των

Γιατί μπορεί να έμειναν αδιευκρίνιστα

θέματα
 Γιατί οι περιπτώσεις χρήσης ορίστηκαν

ανεξάρτητα η μία από την άλλη
 Γιατί περιγράφηκαν στη γλώσσα του
πελάτη
 Κάθε περίπτωση χρήσης δομήθηκε ώστε
να αποτελεί μια ολοκληρωμένη και
κατανοητή προδιαγραφή λειτουργίας

Η διαφορά ανάλυσης και
καταγραφής απαιτήσεων
 Η ανάλυση επιλύει προβλήματα που

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

Ποια είναι η διαφορά της ανάλυσης από

τη σχεδίαση και την υλοποίηση
 Η ανάλυση βρίσκεται ανάμεσα στην

καταγραφή των απαιτήσεων και τη
σχεδίαση
 Περιγράφει τις περιπτώσεις χρήσης σε
ένα βαθμό λεπτομέρειας που ο πελάτης
μπορεί να βαριόταν να το κάνει
 Στη σχεδίαση απαντώνται ερωτήματα
όπως
 «πως μπορούμε να κάνουμε αυτή τη συνάρτηση πιο
γρήγορη;»
 «πως μπορούμε να μην υπερφορτώσουμε το δίκτυο;»
Άλλες περιπτώσεις που η
ανάλυση είναι αναγκαία
 Η ανάλυση αποτυπώνει, σχετικά φθηνά,
ολόκληρο το σύστημα
 Νέοι μηχανικοί εκπαιδεύονται πιο εύκολα
βλέποντας το μοντέλο ανάλυσης παρά
τον κώδικα
 Το μοντέλο ανάλυσης παρέχει εικόνα
ανεξάρτητη από την υλοποίηση
 Ένα παλαιότερο σύστημα για το οποίο
υπάρχει μοντέλο ανάλυσης είναι πιο
εύκολο να κατανοηθεί και να
επανασχεδιαστεί

Τι να κάνετε στη διάρκεια της

ανάλυσης
 Αναλύστε τις περιπτώσεις χρήσης

 Βρείτε τις τάξεις ανάλυσης (ορίου,
ελέγχου και οντότητας)
 Βρείτε τις σχέσεις μεταξύ τους
 Βρείτε τα χαρακτηριστικά κάθε τάξης
 Βρείτε πιθανές σχέσεις περιεκτικότητας
και γενικεύσεις

Βήμα 1
Αναλύστε τις περιπτώσεις χρήσης
 Για την ανάλυση των περιπτώσεων
χρήσης ξεκινήστε προσπαθώντας να
κάνετε ένα διάγραμμα συνεργασίας.
 Στο διάγραμμα συνεργασίας
χρησιμοποιήστε 3 γενικές κατηγορίες
κλάσεων, οι οποίες ονομάζονται κλάσεις
ανάλυσης (θα τις δούμε παρακάτω)
 Στο διάγραμμα συνεργασίας δείξτε πως
θα μπορούσε να πραγματωθεί η
περίπτωση χρήσης αν συνεργαζόταν
μεταξύ τους «αντικείμενα» αυτών των
κλάσεων
Κλάση ανάλυσης
 Αποτελεί μια γενικευμένη έννοια η οποία
κατά τη φάση της σχεδίασης θα
αντιστοιχηθεί σε μία ή περισσότερες από
μια κλάσεις
 Δεν περιέχει μεθόδους. Το πως
συμπεριφέρεται ορίζεται ουσιαστικά από
τις υποχρεώσεις της
 Έχει χαρακτηριστικά (τα οποία αργότερα
μπορεί να γίνουν κλάσεις)
 Σχετίζεται με άλλες κλάσεις
Για να βρείτε τις κλάσεις
ανάλυσης
 Δείτε κάθε περίπτωση χρήσης και
φανταστείτε ότι έχετε μόνο τρία είδη κλάσεων
στη διάθεσή σας
 Κλάσεις ορίου: Είναι υπεύθυνες για να
στέλνουν δεδομένα σε χαρακτήρες ή να
παίρνουν δεδομένα από αυτούς.
 Κλάσεις οντότητας ή δεδομένων: Είναι
υπεύθυνες για να αποθηκεύουν δεδομένα.
 Κλάσεις ελέγχου: Κάνουν ελέγχους, ορίζουν
με ποια σειρά πρέπει να γίνουν διάφορες
ενέργειες και «συνδέουν» τις ενέργειες των
κλάσεων ορίου με τις κλάσεις οντότητας.
Στερεότυπα κλάσεων ανάλυσης

(πώς μπορούμε να τις
αναπαραστήσουμε)
Τάξη ανάλυσης
(Analysis Class)
Ευθύνες
Χαρακτηριστικά
Σχέσεις
Ειδικές απαιτήσεις
Τάξη ορίων Τάξη ελέγχου Τάξη οντότητας

(Boundary Class) (Control Class) (Entity Class)

Στερεότυπα
 Εναλλακτικά μπορείτε να τις
αναπαραστήσετε ως εξής:
<<Ορίου>> <<Ελέγχου>> <<Οντότητας>>
Name Name Name

Κλάσεις ορίου (Boundary Classes)

 Περιγράφουν τη διασύνδεση μεταξύ του
συστήματος και των χαρακτήρων
 Αφορούν συνήθως λήψη και παρουσίαση
πληροφορίας
 Είναι συνήθως φόρμες, πρωτόκολλα,
drivers κτλ
 Περιγράφουν το ΤΙ επιτυγχάνεται από τη
διασύνδεση και όχι το ΠΩΣ
 Κάθε τέτοια κλάση συνδέεται με
τουλάχιστον ένα χαρακτήρα

Χαρακτηριστικά
(attributes) κλάσεων ορίου
 Αν επικοινωνούν με ανθρώπους έχουν

συνήθως χαρακτηριστικά που αφορούν
πληροφορίες (πχ text fields, labels etc)
 Αν επικοινωνούν με άλλα συστήματα
έχουν χαρακτηριστικά κάποιου
πρωτοκόλλου επικοινωνίας

Κλάσεις οντότητας (Entity Class)

 Αναπαριστούν πληροφορία η οποία
διατηρείται για κάποιο χρονικό διάστημα
 Στις περισσότερες περιπτώσεις
προέρχονται κατευθείαν από το πεδίο
εφαρμογής (domain model)

Χαρακτηριστικά κλάσεων
οντοτήτων
 Τα χαρακτηριστικά μιας τάξης οντοτήτων

είναι συνήθως αρκετά φανερά
 Συνήθως μπορείτε να τα βρείτε από τα
χαρακτηριστικά των εννοιών που έχετε
αναπαραστήσει στο domain model

Ανακαλύπτοντας τάξεις
οντοτήτων
 Αρχικά μπορούν να σκιαγραφηθούν οι

βασικές τάξεις οντοτήτων από το domain
model.
 Οι σχέσεις που υπάρχουν στο domain
model μπορούν να χρησιμοποιηθούν για
να αποκαλύπτουν και τις σχέσεις
ανάμεσα στις τάξεις οντοτήτων

Κλάσεις ελέγχου
 Αναπαριστούν συνεργασίες, μεταφορές,
έλεγχο άλλων αντικειμένων.
Αναπαριστούν υπολογισμούς
 Σε γενικές γραμμές η «δυναμική» του
συστήματος αναπαριστάται από τις
κλάσεις ελέγχου

Χαρακτηριστικά κλάσεων ελέγχου
 Συνήθως οι κλάσεις ελέγχου δεν έχουν

κάποια χαρακτηριστικά γιατί συνήθως
έχουν και σύντομη διάρκεια ζωής.
 Πολλές φορές όμως μπορεί να έχουν
χαρακτηριστικά που συσσωρεύονται, πχ
μετρητές, που χρησιμοποιούνται σε μια
περίπτωση χρήσης

Βήμα 2
Κάντε διαγράμματα συνεργασίας
 Κάντε ένα διάγραμμα συνεργασίας για

κάθε περίπτωση χρήσης και προσθέστε,
αν θεωρήσετε αναγκαίο, και μια
περιγραφή.
 Στο διάγραμμα συνεργασίας δείξτε με
ποιο τρόπο κλάσεις ορίου, ελέγχου και
οντότητας μπορούν να συνεργαστούν για
να πραγματώσουν την περίπτωση
χρήσης

Βήμα 3
Βρείτε τις συσχετίσεις των κλάσεων
 Αφού ολοκληρώσετε τα διαγράμματα
συνεργασίας για κάθε περίπτωση χρήσης
δείτε από τις κλάσεις που έχετε ορίσει αν
μπορείτε να βρείτε σχέσεις γενίκευσης ή
εξάρτησης. Δείτε αν μπορείτε να
επαναχρησιμοποιήσετε κάποια κλάση.
 Ίσως σας βοηθήσει για κάθε κλάση να
φτιάξετε μια καρτέλα στην οποία φαίνεται
το όνομα της κλάσης, τι κάνει και με
ποιους συνεργάζεται

Βρείτε τις συσχετίσεις
 Χρησιμοποιήστε διαγράμματα
συνεργασίας
 Αν σε μια περίπτωση χρήσης υπάρχουν
πάνω από μια ροές μπορείτε να φτιάξετε
ένα διάγραμμα συνεργασίας για κάθε ροή
 Αρχίστε κοιτώντας τη ροή των γεγονότων
ένα βήμα τη φορά αποφασίζοντας ποιο
αντικείμενο ανάλυσης θα
χρησιμοποιήσετε
Βρείτε την ευθύνη της κάθε

κλάσης
 Οι ευθύνες μιας κλάσης μπορούν να

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

Μη-λειτουργικές απαιτήσεις
 Στην ανάλυση σε ένα κείμενο ορίστε και
τις μη-λειτουργικές απαιτήσεις που
αφορούν την πραγματοποίηση μιας
περίπτωσης χρήσης. Παράδειγμα
 Δεν πρέπει να περνάν πάνω από 5
δευτερόλεπτα από τη στιγμή που θα
ζητήσει ένας πελάτης να κατοχυρώσει ένα
όνομα μέχρι τη στιγμή που θα αποσταλεί η
αίτηση στον εξωτερικό οργανισμό

10η Διάλεξη
Παράδειγμα: Ανάλυση απαιτήσεων

συστήματος καταχώρησης ονομάτων
χώρου

Σύστημα καταχώρησης
ονομάτων χώρου
 Έχουμε δει κάποιες περιγραφές για ένα

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

Απαιτήσεις

Περιγραφές περιπτώσεων
χρήσης

Διαγράμματα δραστηριότητας

Βήμα 1
 Κοιτώντας την περιγραφή της περίπτωσης
χρήσης βλέπουμε ότι θα χρειαστούμε:
 1 κλάση ορίου για την επικοινωνία με το χρήστη.
Σκοπός της θα είναι να συλλέγει τις
πληροφορίες για την κατοχύρωση του ονόματος
 1 κλάση ορίου για να εμφανίζουμε το
αποτέλεσμα της συναλλαγής στο χρήστη
 1 κλάση ορίου για την επικοινωνία με τον
εξωτερικό οργανισμό (Προσοχή: Αυτή η κλάση
επικοινωνεί όχι με άνθρωπο αλλά με μηχάνημα)

Βήμα 1
 Έχουμε 3 κλάσεις οντοτήτων/δεδομένων
 1 που αποθηκεύει τα στοιχεία του προφίλ
 1 που αποθηκεύει τα στοιχεία της αίτησης
 1 που αποθηκεύει τα στοιχεία του
λογαριασμού
 Έχουμε 1 κλάση ελέγχου
 Είναι ο “τροχονόμος” που ορίζει τη σειρά με
την οποία γίνονται οι ενέργειες και ελέγχει για
τυχόν λάθη

Ανάλυση περίπτωσης χρήσης
 (1)Η κλάση ApplyForm διαβάζει όλα τα
διαθέσιμα profils από την κλάση Profil
 (2)Ο χρήστης επιλέγει το προφίλ που θέλει να
χρησιμοποιήσει και εισάγει το όνομα χώρου που
επιθυμεί
 (3) Η κλάση ApplyForm στέλνει τα στοιχεία
αυτά στην κλάση ProcessApply η οποία και
ελέγχει για την ορθότητά τους
 (4) Αν αυτά είναι σωστά τα στέλνει στην κλάση
EppProtocol η οποία και τα προωθεί στον
εξωτερικό οργανισμό
Βήμα 2: Διάγραμμα συνεργασίας για την περίπτωση

χρήσης «Καταχώρηση ονόματος»
Παρουσιάζεται
μόνο για ευκολία
Κάποια στιγμή
αυτή θα
υλοποιηθεί από
μια φόρμα
Θα
υλοποιηθεί
με ένα
πρωτόκολλο
επικοινωνία
ς

Βήμα 3: Συνεργασίες/Εξαρτήσεις
Μια τέτοια
καρτέλα
ApplyForm
ονομάζεται Class
Responsibility
-domainName : .
-profileName : . Collaborator card
+submit() : .
(CRC)
Class ApplyForm
Superclass(es)
Subclasses
Ευθύνη Συνεργάτες
O χρήστης μπορεί να δώσει OK, να επιλέξει User
προφιλ και όνομα χώρου
Εμφάνισε όλα τα προφιλ για να επιλέξει ο Profile
χρήστης
Μόλις ο χρήστης πατήσει OK στέλνονται το ProcessApply
όνομα χώρου και το επιλεγμένο προφιλ

Συμπεράσματα από την ανάλυση

 Για κάθε περίπτωση χρήσης έχουμε στο
τέλος ένα σύνολο από κλάσεις ορίου,
ελέγχου και οντότητας
 Κάποιες από τις κλάσεις οντότητας θα έχουν
κοινά στοιχεία και μπορούμε να τις
συνδυάσουμε με κληρονομικότητα
 Κλάσεις ορίου που υλοποιούν πρωτόκολλα
μπορούν να συνδυαστούν σε μία κλάση
 Κλάσεις ελέγχου συνήθως δε μπορούν να
συνδυαστούν
11η Διάλεξη
Η σχεδίαση του συστήματος

Τι κάνουμε στη σχεδίαση;

 Βρίσκουμε τη μορφή του συστήματος
 Ενώ στην καταγραφή των απαιτήσεων
και την ανάλυση η επιλογή της γλώσσας
υλοποίησης δεν ήταν σημαντική στη
σχεδίαση οι κλάσεις σχεδιάζονται έχοντας
υπόψη μια συγκεκριμένα γλώσσα
 Η σχεδίαση πρέπει να λάβει υπ΄ όψη της
τόσο τις λειτουργικές όσο και τις μη-
λειτουργικές απαιτήσεις
Σκοπός της σχεδίασης
 Καθορίζουμε με μεγάλη λεπτομέρεια τη
συμπεριφορά (ιδιότητες, μεθόδους) των
κλάσεων
 Κάποιες από τις κλάσεις που
ανακαλύφθηκαν κατά την ανάλυση θα
σχεδιαστούν με περισσότερες από μία
κλάσεις
 Λαμβάνονται υπόψη και οι μη-
λειτουργικές απαιτήσεις

Βρείτε τις κλάσεις σχεδίασης

 Μελετήστε τις κλάσεις ανάλυσης που
παίρνουν μέρος στις αναλύσεις των
περιπτώσεων χρήσης
 Μελετήστε τις ειδικές απαιτήσεις της
αντίστοιχης ανάλυσης της περίπτωσης
χρήσης. Ορίστε αντίστοιχες κλάσεις
σχεδίασης που υλοποιούν αυτές τις
απαιτήσεις

Περιγράψτε τις αλληλεπιδράσεις
μεταξύ των αντικειμένων
 Αφού βρείτε τα αντικείμενα που παίρνουν

μέρος σε μια περίπτωση χρήσης ορίστε
και τον τρόπο που αυτά αλληλεπιδρούν
μεταξύ τους
 Η περιγραφή μπορεί να γίνει είτε
χρησιμοποιώντας ένα διάγραμμα
συνεργασίας ή ένα διάγραμμα
ακολουθίας
 Χρησιμοποιήστε ένα διάγραμμα για κάθε
πιθανή εναλλακτική ροή
Σχεδίαση των κλάσεων

 Καθορίστε:
 τις λειτουργίες της κλάσης
 τα χαρακτηριστικά της
 τις σχέσεις στις οποίες μετέχει
 τις μεθόδους που υλοποιούν τις λειτουργίες
 τις πιθανές καταστάσεις της
 πιθανές εξαρτήσεις της από τη γενική
σχεδίαση
 Απαιτήσεις από την υλοποίηση
 Πιθανές διεπαφές που πρέπει να προσφέρει

Πώς θα μπορούσατε να
προχωρήσετε;
 Δείτε τις κλάσεις ορίου

 Αν αφορούν επικοινωνία με ανθρώπινο
χαρακτήρα, αποφασίστε ποια ακριβώς
πληροφορία θα παρουσιάσουν και πώς
 Ορίστε για παράδειγμα Buttons, TextAreas
κτλ
 Δείτε τις κλάσεις ελέγχου

 Αποφασίστε πως θα αντιδρά κάθε τάξη
ελέγχου σε περιπτώσεις λαθών; Τι θα
κάνει;
Πώς θα μπορούσατε να
προχωρήσετε;
 Δείτε τις τάξεις οντοτήτων

 Πώς θα αποθηκεύονται και που;
 Ανάλογα με την τεχνολογία που θα
χρησιμοποιήσετε μπορεί να πρέπει να
υλοποιήσετε και ένα μηχανισμό
διασύνδεσης
 Για τις σχεσιακές βάσεις υπάρχουν
αυτόματα εργαλεία που μπορούν να
κάνουν σε κάποιο βαθμό τη μετατροπή
ανάμεσα σε τάξεις και πίνακες.

Άλλες ενέργειες που θα
μπορούσατε να κάνετε
 Ορισμένα αντικείμενα αλλάζουν πολλές

καταστάσεις στη διάρκεια ζωής τους.
 Για παράδειγμα μια παραγγελία μπορεί
να είναι «Ανοικτή», «Υπό εκτέλεση»,
«Υπό παράδοση», «Ολοκληρωμένη»,
«Πληρωμένη» κτλ.
 Για τέτοια αντικείμενα μπορεί να είναι
χρήσιμο να κάνετε ένα διάγραμμα που
δείχνει πότε και πως αλλάζουν
καταστάσεις
Παράδειγμα Σχεδίασης

Σχεδίαση
 Σε προηγούμενη διάλεξη είχαμε αναλύσει την
περίπτωση χρήσης “Αίτηση για όνομα χώρου”
 Στην ανάλυση είχε αποφασιστεί ότι θα
χρησιμοποιηθεί μια κλάση ορίου που θα έχει ως
ευθύνη την παρουσίαση των προφίλς και θα
επιτρέπει στο χρήση να εισάγει το όνομα χώρου
που επιθυμεί
 Τώρα σχεδιάζουμε αυτήν την κλάση
χρησιμοποιώντας τη γλώσσα της επιλογής μας
(στη συγκεκριμένη περίπτωση Java) ως μια
φόρμα με κάποια components
Σχεδίαση της ApplyForm
ApplyForm
-domainName : JTextField
-profileName : JComboBox
-buttonOK : JButton
+OKButton_Clicked() : .
+Profil_Selected()

Άλλες ενέργειες στη σχεδίαση
 Κοιτούμε ξανά με ποιες κλάσεις θα
συνεργάζεται η ApplyForm
 Παρατηρούμε ότι κάπως πρέπει να
«γεμίζουμε» το ComboBox με τα ονόματα
των προφίλς και αποφασίζουμε ότι μια νέα
κλάση θα είναι υπεύθυνη για να διαβάζει τα
profils και να τα δίνει στην ApplyForm
(ApplicationFormController)
 Κάνουμε μια πρώτη προσπάθεια
σχεδιάζοντας ένα διάγραμμα συνεργασίας
Σχεδίαση

Σχεδίαση των κλάσεων ελέγχου
 Είναι δύσκολη και λεπτεπίλεπτη δουλειά.
Εξαρτάται από
 την κατανομή του συστήματος
 τις απαιτήσεις σε απόδοση
 τις απαιτήσεις σε ασφάλεια

Σχεδίαση της Apply Process

 Τι πρέπει να κάνει αυτή η κλάση; Από τη
φάση ανάλυσης βλέπουμε ότι έχει τις
ακόλουθες υποχρεώσεις
Class ProcessApply
Superclass(es)
Subclasses
Responsibility Collaborators
Εξετάζει την ορθότητα της αίτησης που έστειλε ο ApplyForm
χρήστης
Αποστέλει την αίτηση και ελέγχει την απάντηση EppProtocol
Αν η απάντηση ότι η αίτηση παραλήφθηκε χωρίς Application
πρόβλημα δημιουργεί την αίτηση
Ενημερώνει τις μονάδες του χρήστη Account
Ενημερώνει το χρήστη ResultWindow

Προβλήματα που μπορεί να
συναντήσετε
 Η ProcessApply είναι υπεύθυνη για την

αντιμετώπιση πιθανών προβλημάτων.
 Να μην έχει συμπληρώσει σωστά ο χρήστης την
αίτηση (δηλαδή να μην έχει συμπληρώσει τα
στοιχεία του domain name, ή του προφίλ)
 Να μη μπορεί να στείλει την αίτηση ή να τη
στείλει αλλά να πάρει απάντηση ότι υπήρχε
πρόβλημα
 Να μη μπορέσει να αποθηκεύσει τα στοιχεία της
αίτησης
 Να μη μπορέσει να αλλάξει τα στοιχεία των
μονάδων του χρήστη
Στη συγκεκριμένη περίπτωση

 Αποφασίζουμε ότι σε όλα τα προβλήματα
απλά εμφανίζουμε ένα μήνυμα λάθους
στο χρήστη
 Για την περίπτωση που δε μπορούμε να
μειώσουμε τις μονάδες του χρήστη
αποφασίζουμε ότι θα αλλάξουμε και τη
ροή των γεγονότων. Έτσι πλέον πριν
γίνει η αποστολή της αίτησης αφαιρούμε
τις μονάδες και μόνο τότε αποστέλλουμε
την αίτηση
Μπορούμε επομένως να περιγράψουμε
τη ροή της ProcessApply ως εξής

Βελτιώνουμε και το διάγραμμα
Δε φαίνεται όλο το διάγραμμα

αλλά μόνο το κομμάτι που μας
ενδιαφέρει

Άλλες ενέργειες
 H διαχείριση ονομάτων χώρου κάνει

«αιτήσεις» για ονόματα που μπορεί να
εγκριθούν ή να απορριφθούν. Το
σύστημά μας μάλιστα έχει και μια κλάση
με το όνομα «Application» που
αντιστοιχεί στις αιτήσεις.
 Μπορούμε να κάνουμε ένα διάγραμμα για
να αναπαραστήσουμε πως δημιουργείται
και πώς αλλάζει ένα αντικείμενο αυτής
της κλάσης.
Η ζωή ενός αντικειμένου μιας

κλάσης “Application”

12η Διάλεξη
Θέματα Σχεδίασης/Σύζευξη

Θέματα σχεδίασης
 Η ποιότητα μιας σχεδίασης κρίνεται τις
πιο πολλές φορές από την ανεξαρτησία
των κλάσεων που έχουμε δημιουργήσει
 Κλάσεις που είναι ανεξάρτητες μεταξύ
τους επαναχρησιμοποιούνται πιο εύκολα,
έχουν λιγότερα λάθη και κατανοούνται
πιο εύκολα

Ανεξαρτησία συστατικών
 Για να αναγνωρίσουμε και να μετρήσουμε
το βαθμό ανεξαρτησίας μεταξύ των
συστατικών χρησιμοποιούμε συχνά δύο
έννοιες:
 Σύζευξη
 Μετράει την εξάρτηση που υπάρχει μεταξύ
δύο συστατικών
 Συνεκτικότητα
 Μετράει τη συνοχή ενός συστατικού

Σύζευξη
Μη συζευγμένα -
καμία εξάρτηση
Χαλαρή σύζευξη Υψηλή σύζευξη

κάποιες εξαρτήσεις πολλές εξαρτήσεις

Κατηγορίες σύζευξης
Σύζευξη περιεχομένου
Σύζευξη κοινών δεδομένων Υψηλή σύζευξη (κακή)
Σύζευξη ελέγχου
Σύζευξη αντιγράφου
Σύζευξη δεδομένων Χαμηλή σύζευξη (καλή)

Μη σύζευξη

Σύζευξη περιεχομένου
 Όταν το ένα συστατικό α αλλάζει το
περιεχόμενο ενός άλλου συστατικού β
 Παράδειγμα 1
 Μια συνάρτηση Α αλλάζει μια εντολή
που βρίσκεται σε μια συνάρτηση Β.
 Συνήθως αυτό είναι δυνατόν μόνο σε
assembly
 Παράδειγμα 2
 Μια συνάρτηση Α περιέχει μια εντολή
goto σε μια συνάρτηση Β
Γιατί είναι κακή;
 Σχεδόν οποιαδήποτε αλλαγή στο Β,
ακόμα και αλλαγή του compiler που
χρησιμοποιείται προϋποθέτει αλλαγή και
στο Α.
 Αδύνατον να χρησιμοποιηθεί το Α χωρίς
να χρησιμοποιηθεί και το Β

Σύζευξη κοινών δεδομένων

 Όταν δύο συστατικά μοιράζονται κοινά
δεδομένα. Πχ
 Η συνάρτηση cca και η συνάρτηση ccb
μπορούν ΚΑΙ να διαβάσουν ΚΑΙ να
αλλάξουν μια καθολική μεταβλητή (global
variable)

 Παράδειγμα 2
 Δύο διαφορετικές συναρτήσεις έχουν
πρόσβαση στην ίδια βάση δεδομένων και
μπορούν να αλλάξουν ΤΗΝ ΙΔΙΑ
ΕΓΓΡΑΦΗ
 Προσοχή ποιοι μπορούν να αλλάζουν στη

C++ τα public attributes


 Γιατί είναι αντίθετη στις αρχές του
δομημένου προγραμματισμού
 Ο κώδικας που παράγεται δε διαβάζεται
 Ποιος σταματά τον ακόλουθο βρόγχο;

Γιατί είναι κακή; (συνέχεια)
 Τα συστατικά (μια συνάρτηση, μια κλάση)
μπορούν να έχουν “παρενέργειες”. Αυτό
τα κάνει δυσανάγνωστα αφού πρέπει
κανείς να διαβάσει ολόκληρο το
συστατικό με προσοχή να δει αν αλλάζει
κάποια καθολική μεταβλητή
 Αν αλλάξει η καθολική μεταβλητή πρέπει
να αλλάξει και κάθε συστατικό που τη
χρησιμοποιεί

Γιατί είναι κακή; (συνέχεια)

 Η επαναχρησιμοποίηση είναι δύσκολη
 Πρέπει να υπάρχει το ίδιο σύνολο
καθολικών μεταβλητών όποτε
επαναχρησιμοποιείται το συστατικό
 Κάθε συστατικό έχει πρόσβαση σε
περισσότερα δεδομένα από όσα
χρειάζεται. Αυτό κάνει ευκολότερη τη
δημιουργία λαθών από απροσεξία

Πότε είναι καλή
 Όταν ένα συστατικό έχει ένα τεράστιο
αριθμό μεταβλητών και πρέπει να
αρχικοποιηθούν, αντί να περαστούν σα
παράμετροι όποτε χρησιμοποιείται το
συστατικό, ορίζονται σαν καθολικές
μεταβλητές και αρχικοποιούνται έτσι πιο
γρήγορα

Σύζευξη ελέγχου
 Όταν το ένα συστατικό περνά
παραμέτρους στο άλλο που ελέγχουν τη
συμπεριφορά του μέσω flags
 Συνήθως εμφανίζεται σε συστατικά που

παρουσιάζουν λογική συνεκτικότητα
(δείτε τις παρακάτω διαφάνειες)

 Η συνάρτηση Α καλεί τη συνάρτηση Β.
 Αν περαστεί ως παράμετρος ο αριθμός 1
η συνάρτηση Β κάνει ταξινόμηση, αν
περαστεί ως παράμετρος ο αριθμός 2 η
συνάρτηση Β διαβάζει από το δίσκο, αν
περαστεί ο αριθμός 3 η Β παίζει μουσική
κτλ

Γιατί δεν είναι καλή

 Τα συστατικά δεν είναι ανεξάρτητα.
 Το συστατικό που καλείται πρέπει να
ξέρει την εσωτερική δομή του συστατικού
που το καλεί
 Επηρεάζει την επαναχρησιμοποίηση

 Πολλές γλώσσες επιτρέπουν μόνο απλές
μεταβλητές σαν παραμέτρους σε
συναρτήσεις ή μεθόδους
 Το όνομα ενός υπαλλήλου
 Ο κωδικός ενός προϊόντος
 Αλλά πολλές γλώσσες επιτρέπουν
ολόκληρες δομές
 Το struct υπάλληλος
 Την κλάση προϊόν

 Σύζευξη αντιγράφου έχουμε όταν ένα
συστατικό Α καλεί ένα συστατικό Β και
περνά μια ολόκληρη δομή σε αυτό σαν
παράμετρο και επιπλέον το Β χρειάζεται
να ξέρει μόνο συγκεκριμένα πεδία από
αυτή τη δομή

function calculateWithHolding(employeeRecord R);
 Δε μπορείτε να πείτε χωρίς να δείτε τον

κώδικα ποια πεδία του R αλλάζουν ή
χρησιμοποιούνται
 Θα έπρεπε να περνάν σαν παράμετροι
ΜΟΝΟ συγκεκριμένα πεδία


 Δεν είναι εύκολο να ξεκαθαρίσεις τι κάνει
το κάθε συστατικό
 Η επαναχρησιμοποίηση δεν είναι εύκολη
 Τα συστατικά αποκτούν πρόσβαση σε
δεδομένα που δε θα έπρεπε

Προσοχή
 Δεν είναι κακό να περνάτε ολόκληρες
δομές αν αυτό είναι απαραίτητο:
invertΜatrix (originalΜatrix, invertedΜatrix);

printRecord(warehouseRecord);

Σύζευξη δεδομένων
 Όταν το ένα συστατικό περνά δεδομένα
στο άλλο
 Είναι η καλύτερη σύζευξη που μπορείτε
να πετύχετε
 displayTimeOfArrival (flightNumber);
 computeProduct (firstNumber, secondNumber);
 getJobWithHighestPriority (jobQueue);

Γιατί είναι καλή;
 Δεν υπάρχουν τα προβλήματα με τις
συζεύξεις αντιγράφου, ελέγχου, κοινών
δεδομένων και περιεχομένου
 Είναι πιο εύκολο να συντηρηθούν τα
συστατικά
 Μια αλλαγή σε ένα είναι δύσκολο να
προκαλέσει προβλήματα στο άλλο

Συζεύξεις
 Ένα από τα πλεονεκτήματα των
αντικειμενοστραφών συστημάτων είναι
ότι παρουσιάζουν μικρή σύζευξη καθώς
κάθε κλάση μπορεί και περιορίζει τις
πράξεις που γίνονται στα δεδομένα της
αλλά και περιέχει τους ορισμούς των
πράξεων αυτών

13η Διάλεξη
Σχεδίαση
συστημάτων/Συνεκτικότητα

Συνεκτικότητα
 Αναφέρεται στην εσωτερική συνοχή ενός
συστατικού
 Όσο πιο συνεκτικό είναι ένα συστατικό
τόσο περισσότερο σχετίζονται μεταξύ
τους τα εσωτερικά του μέρη και
εξυπηρετούν καλύτερα το συνολικό
σκοπό του
 Ένα συστατικό με μεγάλη συνοχή δεν
έχει παραπανίσια κομμάτια!
Είδη συνεκτικότητας
Λειτουργική Υψηλή συνεκτικότητα

Σειριακή (καλή)
Επικοινωνιακή
Διαδικασιακή
Χρονική
Χαμηλή συνεκτικότητα
Λογική
(κακή)
Συμπτωματική
Συμπτωματική συνεκτικότητα
 Όταν τα μέρη δε σχετίζονται μεταξύ τους
 Παράδειγμα:
function doItAll(char *par1,int par2)‫‏‬
printNextLine();
ReverseString(par1)‫‏‬
par2 += 7;
return par2
 Συνήθως προκύπτει από εντολές του τύπου
 “Γράψτε μια συνάρτηση που αποτελείται
από 10-20 εντολές”

 Το συστατικό δε συντηρείται εύκολα γιατί
είναι δυσνόητο
 Δε μπορεί να επαναχρησιμοποιηθεί
 Διορθώνεται όμως εύκολα!

 Φτιάξτε τόσα χωριστά συστατικά όσες και οι
ενέργειες που έχετε

Λογική συνεκτικότητα
 Όταν διάφορα λογικά σχετιζόμενες συναρτήσεις
ή δεδομένα τοποθετούνται στο ίδιο συστατικό
 Για παράδειγμα έχετε μια συνάρτηση η οποία
γράφει δεδομένα σε συσκευές. Επιλέγετε τη
συσκευή στην οποία θα γράψει περνώντας μια
παράμετρο: Αν περαστεί το 1 γράφει σε δίσκο,
αν περαστεί το 2 γράφει στη μνήμη κτλ
 Συνήθως συνάρτηση αυτή θα παίρνει και άλλες
παραμέτρους που θα τους χρησιμοποιεί
ανάλογα με τον κωδικό που περάσατε

Λογική συνεκτικότητα
 Παράδειγμα
function code = 7;
writeData(op code, dummy 1, dummy 2, dummy
3);
// dummy 1, dummy 2, and dummy 3 are dummy
variables,
// not used if function code is equal to 7
 Η writeData καλείται με 4
παραμέτρους αλλά μόνο 3
χρησιμοποιούνται όταν ο κωδικός είναι 7

Το συστατικό στα δεξιά
περιέχει κώδικα που
διαχειρίζεται όλες τις
εγγραφές/αναγνώσεις.
Βάζετε μια καινούργια
συσκευή. (πχ. Ένα νέο
δίσκο). Πρέπει να αλλάξετε τα
κομμάτια 1,2,3,4,7,8.
Τι θα γίνει όμως με τις
συσκευές που ήδη
χρησιμοποιούσαν αυτόν τον
κώδικα;
 Οι διεπαφές δεν είναι ξεκάθαρες
 Δεν είναι ξεκάθαρο που βρίσκεται και τι
κάνει κάθε κομμάτι
 Η επαναχρησιμοποίηση είναι δύσκολη

Χρονική συνεκτικότητα
 Όταν τα μέρη σχετίζονται με βάση το
χρονισμό τους
 Παράδειγμα.
 Ένα συστατικό που κάνει αρχικοποίηση
class initialize {
Αρχικοποίησε μεταβλητές προγράμματος
Άδειασε τον πίνακα Sales
Διάβασε την πρώτη εγγραφή από τον πίνακα Transactions
Εμφάνισε μήνυμα στην οθόνη

Γιατί είναι τόσο κακή;
 Γιατί οι ενέργειες που εκτελούνται μέσα
στο συστατικό έχουν μόνο μικρή σχέση
μεταξύ τους αλλά συνήθως μεγάλη σχέση
με ενέργειες που γίνονται σε άλλα
συστατικά.
 Αρχικοποιούμε τον πίνακα Sales αλλά άλλες
ενέργειες όπως «ενημέρωσε τον Sales»
«τύπωσε τον Sales» βρίσκονται σε άλλα
συστατικά
 Αν θέλουμε να αλλάξουμε τη δομή του πίνακα σε ποιά
συστατικά πρέπει να αλλάξουμε τον κώδικα;
 Δεν επιτρέπει την επαναχρησιμοποίηση
Διαδικασιακή συνεκτικότητα
 Διαφορετικές λειτουργίες ομαδοποιούνται σε ένα
συστατικό επειδή πρέπει να εκτελεστούν με
συγκεκριμένη σειρά
 Συνήθως οι λειτουργίες δεν έχουν κάποιο κοινό
δεδομένο, αλλά απλά όταν ολοκληρώνεται η μία
περνάει τον έλεγχο στην άλλη
 Για παράδειγμα:
 function makeRepairs() {
read part number
update repair record on master file
}

 Δεν επιτρέπει την επαναχρησιμοποίηση
 Οι ενέργειες μέσα στο συστατικό είναι
μόνο χαλαρά συνδεδεμένες μεταξύ τους.

Πότε είναι καλή;

 Όταν φτιάχνεται ένα συστατικό που
ελέγχει (βρίσκεται πάνω από) όλα τα
άλλα

Επικοινωνιακή συνεκτικότητα
 Ομαδοποιούνται συναρτήσεις που δρουν
στο ίδιο σύνολο δεδομένων. Μοιάζει με
τη χρονική αλλά εδώ κάθε λειτουργία δρα
στα ίδια δεδομένα και η σειρά με την
οποία γίνονται οι λειτουργίες δεν είναι
τόσο σημαντική
 Παράδειγμα
 Ενημέρωσε μια εγγραφή στη βάση ΚΑΙ γράψε τα
στοιχεία της εγγραφής σε ένα αρχείο
 Υπολόγισε νέες συντεταγμένες ΚΑΙ τύπωσέ τες
στην οθόνη

Γιατί δεν είναι καλή;

 Οι ενέργειες είναι πιο στενά
συνδεδεμένες αλλά όχι με το βέλτιστο
τρόπο
 Δεν είναι εύκολη η επαναχρησιμοποίηση
γιατί κάθε συστατικό τελικά εκτελεί πάνω
από μια ενέργειες
 Καλό θα ήταν να χωριστεί σε
περισσότερα συστατικά, ένα για κάθε
ενέργεια
Ακολουθιακή συνεκτικότητα
 Όταν ένα συστατικό εκτελεί μια σειρά από
ενέργειες, αλλά κάθε μία είναι ορισμένη
ανεξάρτητα από την άλλη και όλες
ενεργούν πάνω στο ίδιο σύνολο
δεδομένων


Παράδειγμα (σε κώδικα C)
 Ένα αρχείο salesRegion.c που
περιέχει
struct SalesRegion {}; //definition

initSalesRegion() //function
updateSalesRegion() //function
printSalesRegion() //function

Γιατί είναι καλή

 Γιατί ο κώδικας για κάθε ενέργεια είναι
ανεξάρτητος και η επαναχρησιμοποίηση
είναι πιο εύκολη

Λειτουργική συνεκτικότητα
 Κάθε τμήμα επεξεργασίας είναι
απαραίτητο για την απόδοση μιας μόνο
λειτουργίας
 Παράδειγμα
 Υπολόγισε τη θερμοκρασία του
δωματίου
 Παράδειγμα
 Υπολόγισε το εμβαδόν ενός
τετραγώνου

Γιατί είναι καλή

 Γιατί η επαναχρησιμοποίηση είναι εύκολη
 Γιατί η εύρεση και διόρθωση λαθών είναι
εύκολη
 Η λειτουργική συνεκτικότητα είναι ιδεατή
και όχι πάντα δυνατή

14η Διάλεξη
Προχωρημένα θέματα
σχεδίασης

Μοτίβα σχεδίασης
 Οι σχεδιαστές έχουν διαπιστώσει ότι
συγκεκριμένα μοτίβα (patterns) εμφανίζονται
διαρκώς κατά τη σχεδίαση προγραμμάτων
 Για αυτό έχουν αναπτύξει συγκεκριμένες λύσεις
οι οποίες μπορούν να εφαρμοστούν όποτε
αναγνωρίζεται ότι το πρόβλημα εντάσσεται σε
ένα από τα γνωστά μοτίβα ανάπτυξης

Τι είναι τα μοτίβα σχεδίασης;
 Προσφέρουν λύσεις σε προβλήματα που
συναντιούνται συχνά
 Είναι γενικά και μπορούν να
εφαρμοσθούν σε πολλές περιπτώσεις
 Περιγράφουν τη μορφή του κώδικα και
όχι τις λεπτομέρειες

Μοτίβα Σχεδίασης
 Υπάρχουν πολλά μοτίβα σχεδίασης αλλά
αρχικά ορίσθηκαν 23 βασικά
 Κάθε μοτίβο έχει τουλάχιστον
 Ένα όνομα
 Ένα σκοπό για τον οποίο δημιουργήθηκε
 Μια περιγραφή του προβλήματος το
οποίο προσπαθεί να λύσει

Κατηγορίες μοτίβων σχεδίασης
 Δημιουργικά μοτίβα (Creational)
 Ποιος είναι ο καλύτερος τρόπος να φτιάχνεις
αντικείμενα
 Abstract Factory, Factory, Prototype, Singleton
 Μοτίβα συμπεριφοράς (Behavioural)
 Επικοινωνία μεταξύ αντικειμένων
 Iterator, Visitor
 Δομικά μοτίβα (Structural)
 Συνδυασμός ομάδων αντικειμένων
 Composite, Adaptor
 Παρακάτω θα παρουσιαστεί το Factory Pattern ως
παράδειγμα μοτίβου
 Γράφετε κώδικα και για Windows και για
Unix.
 Πρέπει να γράψετε μια κλάση η οποία
είναι υπεύθυνη για τη δημιουργία μιας
σύνδεσης TCP
 Όμως η κλάση αυτή πρέπει να υλοποιεί
διαφορετικά τη σύνδεση, αν πρόκειται για
την υλοποίηση σε Windows και
διαφορετικά αν πρόκειται για την
υλοποίηση σε Unix
Χωρίς το Factory Pattern
 Ορίζετε δύο κλάσεις
 WindowsTcpConnection
 UnixTcpConnection


 Και μέσα στον κώδικά σας, όποτε
χρειάζεται να χρησιμοποιήσετε αυτήν την
κλάση έχετε:
if (platform == "Unix") {
UnixTcpConnection connection;
connection.connect();
} else if (platform == "Windows") {
WindowsTcpConnection connection;
}
// κ.τ.λ.

 Αν αργότερα αποφασίσετε να
προσθέσετε και μια υλοποίηση για Mac,
τότε θα προσθέσετε μια κλάση
MacTcpConnection και παντού θα πρέπει
να προσθέσετε τον αντίστοιχο κώδικα


} else if (platform == "Mac") {
MacTcpConnection connection;
}
// κ.τ.λ.

 Τα πράγματα είναι ακόμα πιο δύσκολα αν
αποφασίσετε να κρατάτε και μία λίστα με
όλες τις ανοιχτές συνδέσεις σας. Σε αυτήν
την περίπτωση θα πρέπει να γράψετε τον
ακόλουθο κώδικα

vector<UnixTcpConnection> unixTcpConnections;
vector<WindowsTcpConnection> windowsTcpConnections;
unixTcpConnections.add(connection);
windowsTcpConnections.add(connection);
}
// κ.τ.λ.

Προβλήματα
 Το κύριο πρόβλημα είναι ότι πρέπει να
γράφετε τον κώδικά σας 2 φορές, μία για
κάθε υλοποίηση.
 Αυτό τον κάνει πολύπλοκο,
δυσανάγνωστο ενώ είναι εύκολο να
γίνουν και λάθη

Με το Factory Pattern
 Χρησιμοποιώντας την κληρονομικότητα
και τον πολυμορφισμό μπορούμε να
καταφύγουμε σε μια λύση η οποία είναι
αρκετά πιο κομψή
 Ορίζετε κλάσεις όπως στο ακόλουθο
διάγραμμα

TCP
Conne
ction
+
conn e ct():b o ol
+
send (ind ata:s trin
g):v
oid
+
receiv e():s trin
g
+
clo
se ():v oid
TCP
Conne
ctionFa
ctory
+
getIn
sta
nce
():T
C P
Con
nec
tio
n
U
nix
T C
PConne
ction
W
indows
T C
PConne
ction +
conn e ct():b o ol
+
conn e ct():b o ol +
send (ind ata:s trin
g):v
oid
+
send (ind ata :strin
g):v
oid +
receiv e():s trin
g
+
receiv e():s trin
g +
clo
se ():v oid
+
clo
se ():v oid

Με το FactoryPattern
 H κλάση TcpConnection είναι abstract, δεν
περιέχει υλοποίηση δηλαδή των μεθόδων
connect(), send(), receive(), close().
 Ορίζει ουσιαστικά τη διεπαφή
επικοινωνίας με τις κλάσεις
WindowsTcpConnection,
UnixTcpConnection

 H κλάση TcpConnectionFactory περιέχει μια μέθοδο
getInstance η οποία μπορεί να οριστεί όπως παρακάτω:
class TcpConnectionFactory {
public:
static TcpConnection &getInstance(string type) {
if (type=="Windows") {
WindowsTcpConnection *connection = new
WindowsTcpConnection();
return connection;
} else {
UnixTcpConnection *connection = new
UnixTcpConnection();
return connection;
}
};

Με το FactoryPattern
 Και πώς χρησιμοποιείται; Απλά:
TcpConnection connection =
TcpConnectionFactory::getInstance("Windows");

 Αν θέλετε να κρατάτε και μια λίστα με
όλες τις συνδέσεις σας;
vector<TcpConnection> connections;
TcpConnection connection =
TcpConnectionFactory.getInstance("Windows
");
connections.add(connection);

Factory Pattern
 Σκοπός
 Ορίζει μια διεπαφή για τη δημιουργία
αντικειμένων αλλά αφήνει τις υποκλάσεις
να αποφασίσουν τι είδους αντικείμενο θα
φτιάξουν
 Που μπορεί να χρησιμοποιηθεί
 Όταν χρειάζεται να δημιουργήσετε
αντικείμενα κλάσεων που έχουν την ίδια
διεπαφή (αλλά διαφορετική υλοποίηση)
και δε γνωρίζετε τη συγκεκριμένη στιγμή τι
είδους αντικείμενα θα χρειαστείτε
Μοτίβα σχεδίασης
 Τα περισσότερα μοτίβα σχεδίασης
στηρίζονται σε έξυπνη χρήση
 Της κληρονομικότητας
 Του πολυμορφισμού
 Της περιεκτικότητας

15η Διάλεξη
Ανασκόπηση/Βιβλιογραφία

Ανασκόπηση
 Η UML είναι μια γλώσσα που μπορεί να
χρησιμοποιηθεί για την γραφική
αναπαράσταση διαφόρων πτυχών ενός
συστήματος σε διάφορα στάδια ανάπτυξής
του
 Για αυτό το σκοπό παρέχει τόσο στατικά
διαγράμματα όσο και δυναμικά

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

 Η ανάπτυξη ενός λογισμικού, προτού την
υλοποίηση περνά συνήθως από
 Τη φάση καταγραφής των απαιτήσεων
 Την ανάλυση
 Και τη σχεδίαση

 Στην καταγραφή των απαιτήσεων είναι
σημαντικό να επικεντρωθούμε στο ΤΙ θέλει να
κάνει ο χρήστης και όχι το ΠΩΣ
 Η καταγραφή των απαιτήσεων μπορεί να
γίνει με τις περιπτώσεις χρήσης

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

 Τη σχεδίαση την κάνουμε με βάση μια
γλώσσα υλοποίησης και χρησιμοποιούμε τις
δομές που μας παρέχει η γλώσσα
 Δίνουμε σημασία ώστε η σύζευξη των
συστατικών μας να είναι μεγάλη και η συνοχή
μικρή
 Τα μοτίβα σχεδίασης μας βοηθούν στο να
πετύχουμε τα παραπάνω

Βιβλιογραφία
 Οι διαφάνειες σε αυτές τις διαλέξεις
βασίστηκαν στις παρακάτω πηγές
 Shari Lawrence Pfleeger, Software Engineering, Theory and
Practice (Ελληνική έκδοση)
 Martin Fowler, Kendall Scott, Εισαγωγή στη UML, Κλειδάριθμος
 Craig Larman, Applying UML and Patterns, Prentice Hall PTR
 Ian Sommervile, Software Engineering, Addison Wesley
 Roger Pressman, Software Engineering, A Practioner’s Approach,
Higher Education
 Jacobson, Rumbaugh, Booch, The Unified Software Development
Process, Addison Wesley


Τεχνολογία Λογισμικού Ι Ν. Πεταλίδης Τει Σερρών 2008

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

Τεχνολογία Λογισμικού Ι Ν. Πεταλίδης Τει Σερρών 2008

Uploaded by

Copyright:

Available Formats

Τεχνολογία Λογισμικού I Ν.

Πεταλίδης ΤΕΙ Σερρών

Περιεχόμενο Διαλέξεων Θεωρίας Τεχνολογίας Λογισμικού Ι

Συντάκτης: Δρ. Ν. Πεταλίδης

1 Υποέργο 1 «Αυτεπιστασία του τμήματος Πληροφορικής και Επικοινωνιών»,

2 Υποέργο 1 «Αυτεπιστασία του τμήματος Πληροφορικής και Επικοινωνιών»,

3 Υποέργο 1 «Αυτεπιστασία του τμήματος Πληροφορικής και Επικοινωνιών»,

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

 Σε γενικές γραμμές η Τεχνολογία

5 Υποέργο 1 «Αυτεπιστασία του τμήματος Πληροφορικής και Επικοινωνιών»,

Γιατί να τα κάνεις όλα αυτά;

7 Υποέργο 1 «Αυτεπιστασία του τμήματος Πληροφορικής και Επικοινωνιών»,

Η διαφορά ανάμεσα σε λογισμικό, σύστημα

 Το προηγούμενο διάγραμμα προέρχεται

9 Υποέργο 1 «Αυτεπιστασία του τμήματος Πληροφορικής και Επικοινωνιών»,

Τι έχει πετύχει η Τεχνολογία

 Το να αναπτύσσεις λογισμικό είναι και

10 Υποέργο 1 «Αυτεπιστασία του τμήματος Πληροφορικής και Επικοινωνιών»,

 Βελτιώνοντας τις διαδικασίες ανάπτυξης

Διαδικασία ανάπτυξης λογισμικού

 Η Τεχνολογία Λογισμικού δίνει τρόπους

13 Υποέργο 1 «Αυτεπιστασία του τμήματος Πληροφορικής και Επικοινωνιών»,

14 Υποέργο 1 «Αυτεπιστασία του τμήματος Πληροφορικής και Επικοινωνιών»,

15 Υποέργο 1 «Αυτεπιστασία του τμήματος Πληροφορικής και Επικοινωνιών»,

17 Υποέργο 1 «Αυτεπιστασία του τμήματος Πληροφορικής και Επικοινωνιών»,

Εργαλεία και ολοκληρωμένα

 Μεγάλος στόχος της Τεχνολογίας

19 Υποέργο 1 «Αυτεπιστασία του τμήματος Πληροφορικής και Επικοινωνιών»,

UML – Διαγράμματα Κλάσεων

1 Υποέργο 1 «Αυτεπιστασία του τμήματος Πληροφορικής και Επικοινωνιών»,

2 Υποέργο 1 «Αυτεπιστασία του τμήματος Πληροφορικής και Επικοινωνιών»,

Τι μας επιτρέπει να κάνουμε

3 Υποέργο 1 «Αυτεπιστασία του τμήματος Πληροφορικής και Επικοινωνιών»,

6 Υποέργο 1 «Αυτεπιστασία του τμήματος Πληροφορικής και Επικοινωνιών»,

Αναπαράσταση κλάσης στη UML

Όνομα Κλάσης Person

7 Υποέργο 1 «Αυτεπιστασία του τμήματος Πληροφορικής και Επικοινωνιών»,

8 Υποέργο «Αυτεπιστασία του τμήματος Πληροφορικής και Επικοινωνιών»,

Συσχετίσεις ανάμεσα σε κλάσεις

9 Υποέργο «Αυτεπιστασία του τμήματος Πληροφορικής και Επικοινωνιών»,

Ένα Team έχει πολλά

10 Υποέργο 1 «Αυτεπιστασία του τμήματος Πληροφορικής και Επικοινωνιών»,

11 Υποέργο «Αυτεπιστασία του τμήματος Πληροφορικής και Επικοινωνιών»,

Company Department Employee

Σύνθεση: Αν διαγραφεί Συσσωμάτωση: Η

14 Υποέργο 1 «Αυτεπιστασία του τμήματος Πληροφορικής και Επικοινωνιών»,

15 Υποέργο 1 «Αυτεπιστασία του τμήματος Πληροφορικής και Επικοινωνιών»,

16 Υποέργο 1 «Αυτεπιστασία του τμήματος Πληροφορικής και Επικοινωνιών»,

Ποιες κλάσεις αναπαριστά το

17 Υποέργο 1 «Αυτεπιστασία του τμήματος Πληροφορικής και Επικοινωνιών»,

18 Υποέργο 1 «Αυτεπιστασία του τμήματος Πληροφορικής και Επικοινωνιών»,

1 Υποέργο 1 «Αυτεπιστασία του τμήματος Πληροφορικής και Επικοινωνιών»,

Διαγράμματα Περιπτώσεων χρήσης

5 Υποέργο 1 «Αυτεπιστασία του τμήματος Πληροφορικής και Επικοινωνιών»,

Συσχέτιση: Το μονοπάτι επικοινωνίας μεταξύ ενός χαρακτήρα και

Γενίκευση: Μία συσχέτιση μεταξύ μιας γενικής περίπτωσης χρήσης

Περιεκτικότητα: Η προσθήκη λειτουργικότητας σε μία βασική περίπτωση

6 Υποέργο 1 «Αυτεπιστασία του τμήματος Πληροφορικής και Επικοινωνιών»,

Διαγράμματα Περιπτώσεων χρήσης

9 Υποέργο «Αυτεπιστασία του τμήματος Πληροφορικής και Επικοινωνιών»,

10 Υποέργο 1 «Αυτεπιστασία του τμήματος Πληροφορικής και Επικοινωνιών»,

12 Υποέργο 1 «Αυτεπιστασία του τμήματος Πληροφορικής και Επικοινωνιών»,

13 Υποέργο «Αυτεπιστασία του τμήματος Πληροφορικής και Επικοινωνιών»,

14 Υποέργο 1 «Αυτεπιστασία του τμήματος Πληροφορικής και Επικοινωνιών»,