ΣΧΕ∆ΙΑΣΜΟΣ ΛΟΓΙΣΜΙΚΟΥ...

106
Ε ΛΛΗΝΙΚΟ Α ΝΟΙΚΤΟ Π ΑΝΕΠΙΣΤΗΜΙΟ ΣΧΕ∆ΙΑΣΜΟΣ ΛΟΓΙΣΜΙΚΟΥ ΠΛΗ24 ΤΕΧΝΟΛΟΓΙΑ ΛΟΓΙΣΜΙΚΟΥ ΙΙ ΜΕΛΕΤΗ ΠΕΡΙΠΤΩΣΗΣ ΗΛΕΚΤΡΟΝΙΚΟ ΚΑΤΑΣΤΗΜΑ Πάνος Φιτσιλής 2004

Transcript of ΣΧΕ∆ΙΑΣΜΟΣ ΛΟΓΙΣΜΙΚΟΥ...

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

ΣΧΕ∆ΙΑΣΜΟΣ ΛΟΓΙΣΜΙΚΟΥ – ΠΛΗ24

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

ΜΕΛΕΤΗ ΠΕΡΙΠΤΩΣΗΣ

ΗΛΕΚΤΡΟΝΙΚΟ ΚΑΤΑΣΤΗΜΑ

Πάνος Φιτσιλής

2004

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

2 ΠΛΗ24 – Σχεδιασµός Λογισµικού

Πίνακας Περιεχοµένων 1 Γνωσιολογικοί στόχοι ........................................................................... 5

1.1 Σκοπός ........................................................................................ 5 1.2 Προσδοκώµενα αποτελέσµατα ......................................................... 5 1.3 Έννοιες κλειδιά ............................................................................. 5

2 Εισαγωγικές έννοιες............................................................................. 6 3 Η διαδικασία ..................................................................................... 11

3.1 Ο κύκλος ζωής στην ενοποιηµένη προσέγγιση.................................. 12 4 Περιγραφή Μελέτης Περίπτωσης Ηλεκτρονικού Ανθοπωλείου ................... 17 5 Καταγραφή και Ανάλυση Απαιτήσεων (Requirements Capture and analysis) 19

5.1 Το µοντέλο του πεδίου προβλήµατος .............................................. 19 5.2 Το µοντέλο των περιπτώσεων χρήσης (use case model) .................... 28

5.2.1 Προσδιορισµός των χειριστών (actors)...................................... 30 5.2.2 Προσδιορισµός των περιπτώσεων χρήσης (use cases) ................. 33 5.2.3 Αναλυτική περιγραφή των περιπτώσεων χρήσης......................... 40 5.2.4 Κανόνες για την ανάπτυξη του µοντέλου περιπτώσεων χρήσης ..... 50

5.3 ∆ιαγράµµατα ∆ραστηριοτήτων ....................................................... 52 5.4 Το µοντέλο αλληλεπίδρασης του χρήστη µε το σύστηµα .................... 56

6 Μοντέλο Ανάλυσης ............................................................................ 63 6.1 Εκλέπτυνση του διαγράµµατος κλάσεων ......................................... 64 6.2 Η συνεργασία των αντικειµένων .................................................... 67 6.3 Ο κύκλος ζωής ενός αντικειµένου .................................................. 74

7 Μοντέλο Σχεδιασµού.......................................................................... 79 7.1 Αποθήκευση των δεδοµένων ......................................................... 85 7.2 Προσδιορισµός των υποσυστηµάτων............................................... 87 7.3 ∆ιαγράµµατα διάταξης (deployment diagrams) ................................ 88

8 Μοντέλο Υλοποίησης.......................................................................... 93 9 Μοντέλο Ελέγχου .............................................................................. 94 10 Συµπεράσµατα .................................................................................104 11 Βιβλιογραφία ...................................................................................106

Πίνακας Εικόνων

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

3 ΠΛΗ24 – Σχεδιασµός Λογισµικού

Εικόνα 1: Η δοµή των διαγραµµάτων UML..................................................... 8 Εικόνα 2: Βασικές έννοιες του κύκλου ζωής στην ενοποιηµένη προσέγγιση....... 13 Εικόνα 3: Παράδειγµα ορισµού ροής εργασίας.............................................. 14 Εικόνα 4: Ο κύκλος ζωής στην ενοποιηµένη προσέγγιση................................ 15 Εικόνα 5: Λεκτική ανάλυση αρχικής περιγραφής του συστήµατος.................... 22 Εικόνα 6: ∆ιάγραµµα κλάσεων του πεδίου προβλήµατος ................................ 26 Εικόνα 7: Η σχέση του µοντέλου περιπτώσεων χρήσης µε τα άλλα µοντέλα ...... 29 Εικόνα 8: Το αρχικό σύνολο περιπτώσεων χρήσης (scope map)...................... 30 Εικόνα 9: Οι χειριστές του συστήµατος ηλεκτρονικού ανθοπωλείου ................. 33 Εικόνα 10: Τα επίπεδα των περιπτώσεων χρήσης.......................................... 35 Εικόνα 11: Οι περιπτώσεις χρήσης για το χειριστή «Ανώνυµο πελάτη» ............. 36 Εικόνα 12: Οι περιπτώσεις χρήσης για το χειριστή «Καταχωρηµένος πελάτης» .. 37 Εικόνα 13: Η ανάλυση της περίπτωσης χρήσης «∆ιαχείριση Επετείων» σε υπο-

περιπτώσεις. ..................................................................................... 38 Εικόνα 14: Οι περιπτώσεις χρήσης για το χειριστή «∆ιαχειριστή Συστήµατος» ... 39 Εικόνα 15: Το συνολικό διάγραµµα περιπτώσεων χρήσης του συστήµατος. ....... 40 Εικόνα 16: Πρότυπο περιγραφής περίπτωσης χρήσης σε µορφή πίνακα............ 42 Εικόνα 17: Πρότυπο περιγραφής περίπτωσης χρήσης UP. .............................. 43 Εικόνα 18: Περιγραφή της περίπτωσης χρήσης «∆ηµιουργία Ανθοδέσµης» ....... 44 Εικόνα 19: Περιγραφή της περίπτωσης χρήσης «∆ηµιουργία Λογαριασµού

Πελάτη»........................................................................................... 46 Εικόνα 20: Περιγραφή της περίπτωσης χρήσης «Τροποποίηση Στοιχείων Πελάτη»

...................................................................................................... 48 Εικόνα 21: Περιγραφή της περίπτωσης χρήσης «log-in» ................................ 50 Εικόνα 22: Παράδειγµα διαγράµµατος δραστηριότητας .................................. 54 Εικόνα 23: ∆ιάγραµµα δραστηριότητας για την περίπτωση χρήσης «∆ηµιουργία

Λογαριασµού Πελάτη» ........................................................................ 55 Εικόνα 24: Παραδείγµατα σχέσεων συναρµολόγησης και σύνθεσης ................. 58 Εικόνα 25: Χάρτης πλοήγησης για τη «∆ιαχείριση Λογαριασµού Πελάτη» ......... 59 Εικόνα 26: Σελίδα δηµιουργίας λογαριασµού πελάτη ..................................... 60 Εικόνα 27: Σελίδα παρουσίασης συνθέσεων................................................. 61 Εικόνα 28: Σελίδα λεπτοµερειών ανθοδέσµης .............................................. 62 Εικόνα 29: ∆ιάγραµµα κλάσεων µε εµφάνιση πεδίων..................................... 66

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

4 ΠΛΗ24 – Σχεδιασµός Λογισµικού

Εικόνα 30: ∆ιάγραµµα κλάσης για περίπτωση χρήσης «∆ηµιουργία Λογαριασµού Πελάτη»........................................................................................... 67

Εικόνα 31: ∆ιάγραµµα ακολουθίας για την περίπτωση χρήσης «∆ηµιουργία Λογαριασµού Πελάτη» ........................................................................ 68

Εικόνα 32: Ο συµβολισµός των κλάσεων και των στιγµιότυπων ...................... 69 Εικόνα 33: Είδη µηνυµάτων σε διαγράµµατα ακολουθίας ............................... 69 Εικόνα 34: ∆ιάγραµµα συνεργασίας για την περίπτωση χρήσης «∆ηµιουργία

Λογαριασµού Πελάτη» ........................................................................ 70 Εικόνα 35: Κανόνες διαγραµµάτων συνεργασίας .......................................... 72 Εικόνα 36: Παράδειγµα συνεργασίας συνοριακής κλάσης µε κλάση οντοτήτων .. 72 Εικόνα 37: Η αντιστοίχηση µεταξύ των στοιχείων του user interface και των

συνοριακών κλάσεων ......................................................................... 73 Εικόνα 38: ∆ιάγραµµα συνεργασίας για την περίπτωση χρήσης «Επιλογή

ανθοδέσµης» .................................................................................... 74 Εικόνα 39: ∆ιάγραµµα κατάστασης για την κλάση «Ηλεκτρονικό Καρότσι» ....... 78 Εικόνα 40: Αρχιτεκτονική πολλών επιπέδων ................................................ 83 Εικόνα 41: Σχεδιασµός της περίπτωσης χρήσης «Login» ................................ 84 Εικόνα 42: ∆ηµιουργία πινάκων από τις κλάσεις του συστήµατος .................... 87 Εικόνα 43: Οργάνωση υποσυστηµάτων....................................................... 88 Εικόνα 44: Απλοποιηµένο διάγραµµα διάταξης ............................................. 90 Εικόνα 45: Αναλυτικό διάγραµµα διάταξης για ηλεκτρονικό ανθοπωλείο........... 92

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

5 ΠΛΗ24 – Σχεδιασµός Λογισµικού

1 Γνωσιολογικοί στόχοι 1.1 Σκοπός

Σκοπός της παρούσας µελέτης περίπτωσης είναι να παρουσιάσει την κατασκευή ενός συστήµατος λογισµικού ηλεκτρονικού εµπορίου µε τη χρήση της γλώσσας UML (Unified Modeling Language). Επιπλέον, εκτός από τη χρήση UML κατά την ανάπτυξη του συστήµατος θα παρουσιασθούν πρακτικά θέµατα διαδικασιών ανάπτυξης λογισµικού µε αντικειµενοστρεφή τρόπο και θα δοθούν ανά κατηγορία πρακτικές οδηγίες για την καλύτερη χρήση της γλώσσας UML.

1.2 Προσδοκώµενα αποτελέσµατα

Μετά τη µελέτη του παραδείγµατος ο αναγνώστης θα είναι σε θέση να:

• Να χρησιµοποιεί την Ενοποιηµένη Προσέγγιση (Unified Process - UP) για την ανάπτυξη ενός συστήµατος λογισµικού µε αντικειµενοστρεφή τρόπο

• Να δηµιουργεί τα απαραίτητα µοντέλα που απαιτούνται στην κάθε φάση ανάπτυξης λογισµικού

• Να εµβαθύνει στον τρόπο περιγραφής ενός συστήµατος µε τη χρήση της γλώσσας UML.

1.3 Έννοιες κλειδιά

Τεχνολογία Λογισµικού

UML (Unified Modeling Language)

Ενοποιηµένη Προσέγγιση (Unified Process - UP)

∆ιαχείριση Απαιτήσεων (Requirements Management)

Ανάλυση και Σχεδιασµός Συστηµάτων

Έλεγχος Συστηµάτων

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

6 ΠΛΗ24 – Σχεδιασµός Λογισµικού

2 Εισαγωγικές έννοιες Ο όρος UML προέρχεται από τα αρχικά των αγγλικών λέξεων «Unified Modelling Language», που σηµαίνει «Ενοποιηµένη Γλώσσα Μοντελοποίησης» η οποία είναι η στάνταρτ γλώσσα για την περιγραφή και ανάπτυξη πληροφοριακών συστηµάτων. Η UML περιλαµβάνει ένα σύνολο δοµικών στοιχείων τα οποία συντίθενται σε διαγράµµατα που έχουν τους παρακάτω στόχους:

• Τον προσδιορισµό πληροφοριακών συστηµάτων (Specification)

• Την οπτικοποίηση της δοµής αυτών, της συµπεριφοράς τους και του τρόπου που αλληλεπιδρούν µε το χρήστη (Visualization)

• Τον Αρχιτεκτονικό Σχεδιασµό

• Την Κατασκευή

• Τον Έλεγχο του συστήµατος και

• Την τεκµηρίωση

Η UML κατασκευάσθηκε για να βελτιώσει την επικοινωνία των συµµετεχόντων στην ανάπτυξη συστηµάτων πληροφορικής µε αντικειµενοστρεφή τρόπο µε σκοπό την αύξηση της παραγωγικότητας. Πολύ γρήγορα όµως η UML άρχισε να επηρεάζει την ανάπτυξη λογισµικού γενικότερα καθώς και την κουλτούρα των ανθρώπων που συµµετείχαν στην ανάπτυξη συστηµάτων.

Η UML ικανοποιεί µια βασική ανάγκη στην ανάπτυξη λογισµικού και συστηµάτων: την ανάγκη της µοντελοποίησης. Ένα µοντέλο είναι στην ουσία µια αφαίρεση (abstraction) του πραγµατικού κόσµου η οποία µας επιτρέπει να συγκεντρώσουµε την προσοχή µας σε συγκεκριµένα σηµεία και να µελετήσουµε πιθανά προβλήµατα µε σκοπό της εξαγωγή συµπερασµάτων που θα µας προφυλάξουν από σφάλµατα στην ανάπτυξη του συστήµατος. Ένα καλά ορισµένο µοντέλο αποτελεί µια αποδοτική µέθοδο επικοινωνίας των συµµετεχόντων (stakeholders) στο έργο αφού επιτρέπει την ακριβή περιγραφή του προβλήµατος και της λύσης που προτείνεται.

Ένα από τα πιο απλά παραδείγµατα µοντέλου είναι ο χάρτης. Ένας χάρτης µοντελοποιεί τον κόσµο µε διαφορετικούς τρόπους (πολιτικός, γεωγραφικός, συγκοινωνιακός χάρτης), καθένας από τους οποίους παρουσιάζει µια διαφορετική όψη χωρίς ποτέ να ταυτίζεται µε τον πραγµατικό κόσµο. Αντίστοιχα κάθε διαφορετικού τύπου διάγραµµα UML µοντελοποιεί το πρόβληµα µε έναν διαφορετικό τρόπο, που παρουσιάζει µια διαφορετική οπτική γωνία του ιδίου προβλήµατος.

Η χρήση της αφαίρεσης, στα µοντέλα και τα διαγράµµατα της UML, µας επιτρέπει να χειριστούµε καλύτερα την πολυπλοκότητα εφόσον κάθε φορά µπορούµε να εστιάσουµε την προσοχή µας σε διαφορετικά θέµατα-παραµέτρους του συστήµατος. Η UML επιτρέπει τη δηµιουργία εξειδικευµένων όψεων (view) του συστήµατος περιορίζοντας τα στοιχεία του διαγράµµατος που εµφανίζονται κάθε

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

7 ΠΛΗ24 – Σχεδιασµός Λογισµικού

φορά. Για παράδειγµα ένα διάγραµµα κλάσεων (class diagram) µπορεί να χρησιµοποιηθεί για την ανάλυση του προβλήµατος, για το σχεδιασµό της λύσης, για την υλοποίηση του συστήµατος καθώς και για τον έλεγχο αυτού. Έτσι κατά τη διάρκεια της ανάλυσης και για το ίδιο διάγραµµα κλάσεων εστιάζουµε την προσοχή µας σε λογικές έννοιες και σχέσεις του πεδίου του προβλήµατος, κατά τη διάρκεια του σχεδιασµού εστιάζουµε την προσοχή µας στο πως θα υλοποιήσουµε τις κλάσεις και τις σχέσεις µεταξύ τους ενώ τέλος κατά την υλοποίηση ενδιαφερόµαστε για τις προγραµµατιστικές κλάσεις.

Συµπερασµατικά µπορούµε να πούµε ότι η χρήση UML για τη δηµιουργία µοντέλων µας επιτρέπει:

1. Να οπτικοποιήσουµε παραµέτρους του συστήµατος που θέλουµε να κατασκευάσουµε

2. Να προσδιορίσουµε τη δοµή και τη συµπεριφορά ενός συστήµατος

3. Να δηµιουργήσουµε πρότυπα που θα µας καθοδηγήσουν στην κατασκευή του συστήµατος και

4. Να τεκµηριώσουµε τις αποφάσεις που έχουµε λάβει σχετικά µε την ανάπτυξη του συστήµατος

Η UML έχει µεγάλο αριθµό διαγραµµάτων, πράγµα το οποίο αποτελεί πολλές φορές λόγο σύγχυσης. Επιπλέον, η προσαρµοστικότητα (flexibility) της γλώσσας µας επιτρέπει να τοποθετούµε κατά το δοκούν στοιχεία από έναν τύπο διαγράµµατος σε έναν άλλο, ιδιότητα που αυξάνει την εκφραστικότητα της γλώσσας αλλά και περιπλέκει ακόµη περισσότερο τα πράγµατα. Στην UML 2.0 υπάρχουν 13 επίσηµα είδη διαγραµµάτων και αρκετά ανεπίσηµα.

Στην Εικόνα 1 παρουσιάζονται τα διαφορετικά είδη επίσηµων διαγραµµάτων UML µε τη µορφή µιας σχέσης γενίκευσης – ειδίκευσης. Σύµφωνα µε αυτήν την εικόνα υπάρχουν δύο µεγάλες κατηγορίες διαγραµµάτων:

1. Τα δοµικά διαγράµµατα (structural diagrams)και

2. Τα διαγράµµατα συµπεριφοράς (behavioral diagrams)

Τα δοµικά διαγράµµατα είναι αυτά που περιγράφουν τη στατική δοµή του συστήµατος, τα συστατικά του στοιχεία και γενικά όλα αυτά τα χαρακτηριστικά που δε µεταβάλλονται στο χρόνο. Τα διαγράµµατα συµπεριφοράς περιγράφουν τη δυναµική συµπεριφορά του συστήµατος, πώς το σύστηµα αποκρίνεται στις απαιτήσεις και το πώς τα αντικείµενα συνεργάζονται για να επιτύχουν τους σκοπούς του συστήµατος.

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

8 ΠΛΗ24 – Σχεδιασµός Λογισµικού

Εικόνα 1: Η δοµή των διαγραµµάτων UML

Στον παρακάτω πίνακα παρουσιάζεται επιγραµµατικά η χρησιµότητα του κάθε είδους διαγράµµατος:

Τύπος ∆ιαγράµµατος Σύντοµη Περιγραφή

∆ιάγραµµα Κλάσεων

(Class Diagram)

Παρουσιάζει τη στατική δοµή του συστήµατος, µε τη µορφή κλάσεων και συσχετίσεων µεταξύ τους

∆ιάγραµµα Αντικειµένων

(Object Diagram)

Χρησιµοποιείται για να δείξει συγκεκριµένα παραδείγµατα του τρόπου µε τον οποίο συνδέονται τα αντικείµενα

∆ιάγραµµα Σύνθετης ∆οµής

(Composite Structure

Είναι ένας νέος τύπος διαγράµµατος στην UML 2.0, το οποίο χρησιµοποιείται για να παρουσιάσει µε εναλλακτικό τρόπο τη σχέση σύνθεσης

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

9 ΠΛΗ24 – Σχεδιασµός Λογισµικού

Τύπος ∆ιαγράµµατος Σύντοµη Περιγραφή Diagram) (composition).

∆ιάγραµµα ∆ιάταξης

(Deployment Diagram)

Χρησιµοποιείται για να περιγράψει την αρχιτεκτονική του συστήµατος σε σχέση µε άλλα προϊόντα λογισµικού που απαιτούνται, σε σχέση µε το υλικό κ.λπ.

∆ιάγραµµα Συστατικών

(Component Diagram)

Χρησιµοποιείται για να δείξει την οργάνωση και τις σχέσεις του συστήµατος

∆ιάγραµµα Πακέτων

(Package Diagram)

Χρησιµοποιείται για την οµαδοποίηση των κλάσεων του συστήµατος

∆ιάγραµµα ∆ραστηριοτήτων

(Activity Diagram)

Χρησιµοποιείται για την περιγραφή της ροής των δεδοµένων και του ελέγχου. Είναι επίσης πολύ καλός τρόπος για την περιγραφή της ροής των εργασιών.

∆ιάγραµµα Περιπτώσεων Χρήσης

(Use Case Diagram)

Χρησιµοποιείται για να περιγράψει τις υπηρεσίες που παρέχονται από το σύστηµα ή/και για να περιγράψει τη λειτουργικότητα του συστήµατος

∆ιάγραµµα Καταστάσεων/Πρωτοκόλλου

(State Machine Diagram/ Protocol State Machine Diagram)

Χρησιµοποιείται για να περιγράψει τον κύκλο ζωής των αντικειµένων µιας κλάσης ή τις διαδοχικές καταστάσεις στις οποίες µπορεί να βρεθεί.

∆ιάγραµµα Συνοπτικό

(Overview Diagram)

Είναι ένα ειδικού τύπου διάγραµµα δραστηριότητας που χρησιµοποιείται για να περιγράψει µια σύνθετη περίπτωση χρήσης.

∆ιάγραµµα Ακολουθίας

(Sequence Diagram)

Χρησιµοποιείται για να περιγράψει την ανταλλαγή µηνυµάτων µεταξύ αντικειµένων καθώς και τη σειρά εκτέλεσης των µηνυµάτων

∆ιάγραµµα Επικοινωνίας

(Communication Diagram)

Όπως και το διάγραµµα ακολουθίας χρησιµοποιείται για την περιγραφή της επικοινωνίας µεταξύ των αντικειµένων. Ονοµάσθηκαν διαγράµµατα επικοινωνίας στην UML 2.0 ενώ στις προηγούµενες εκδόσεις της UML ονοµάζονταν διαγράµµατα συνεργασίας (collaboration diagrams). Για λόγους συµβατότητας µε το ήδη υπάρχον εκπαιδευτικό υλικό και καλύτερης κατανόησης θα εξακολουθήσουµε να τα αποκαλούµε διαγράµµατα

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

10 ΠΛΗ24 – Σχεδιασµός Λογισµικού

Τύπος ∆ιαγράµµατος Σύντοµη Περιγραφή συνεργασίας.

∆ιάγραµµα Χρονισµού

(Timing Diagram)

Τα διαγράµµατα χρονισµού χρησιµοποιούνται σε συστήµατα πραγµατικού χρόνου µε σκοπό να δείξουµε το χρονισµό του ρολογιού µέσα στο σύστηµα

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

11 ΠΛΗ24 – Σχεδιασµός Λογισµικού

3 Η διαδικασία Η ενοποιηµένη προσέγγιση (UP –Unified Process) είναι µια επαναληπτική (iterative) διαδικασία ανάπτυξης συστηµάτων. Για ένα απλό σύστηµα, θα ήταν εφικτό να προσδιορισθεί αρχικά όλο το σύστηµα, να σχεδιαστεί ολόκληρη η λύση, να υλοποιηθεί το λογισµικό, και στη συνέχεια να ελεγχθεί το τελικό προϊόν. Εντούτοις, λαµβάνοντας υπόψη την πολυπλοκότητα, την εµβάθυνση που απαιτείται και την εκλέπτυνση που χρειάζεται για την ανάπτυξη ενός συστήµατος σήµερα, αυτή η γραµµική προσέγγιση είναι µη ρεαλιστική. Αντίθετα, µια επαναληπτική προσέγγιση επιτυγχάνει τη διαδοχικά αυξανόµενη κατανόηση του προβλήµατος µέσω της συνεχούς εµβάθυνσης στο πρόβληµα και εκλέπτυνσης της λύσης. Επιπλέον η επαναληπτική προσέγγιση προσφέρει την ευελιξία που απαιτείται στην ανάπτυξη των συστηµάτων σήµερα λόγω των συχνών αλλαγών στις απαιτήσεις ή των τακτικών αλλαγών στους επιχειρησιακούς στόχους.

Οι δραστηριότητες της ενοποιηµένης προσέγγισης βασίζονται στη δηµιουργία και τη συντήρηση των µοντέλων παρά στη δηµιουργία και συντήρηση εγγράφων. Τα UML µοντέλα υπερέχουν έναντι των εγγράφων µια και περιέχουν πλούσια σηµειολογία και σηµασιολογία που εστιάζεται στην ανάπτυξη λογισµικού. Επιπλέον τα µοντέλα µπορούν να ειδωθούν από πολλές οπτικές γωνίες ενώ η πληροφορία που περιέχουν µπορεί να διαχειριστεί ηλεκτρονικά. Το σκεπτικό πίσω από την προσέγγιση αυτή είναι να ελαχιστοποιηθεί το κόστος ανάπτυξης πληροφοριακών συστηµάτων, µέσω της ελαχιστοποίησης του κόστους ανάπτυξης και συντήρησης εγγράφων.

Η ενοποιηµένη προσέγγιση είναι µια διαδικασία αρχιτεκτονικο-κεντρική (architecture centric). Η ενοποιηµένη προσέγγιση εστιάζει την προσοχή στην όσο το δυνατόν νωρίτερα ανάπτυξη της αρχιτεκτονικής του λογισµικού καθώς και του καθαυτό λογισµικού. Η ύπαρξη µιας αρχιτεκτονικής σε ισχύ διευκολύνει την παράλληλη ανάπτυξη, ελαχιστοποιεί την επανάληψη, αυξάνει την πιθανότητα της επαναχρησιµοποίησης τµηµάτων και βελτιώνει τη συντηρησιµότητα των συστηµάτων.

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

Συνοψίζοντας, θα µπορούσαµε να πούµε ότι τέσσερις είναι βασικές αρχές στις οποίες βασίζεται η ενοποιηµένη προσέγγιση:

1. Εφαρµόζεται επαναληπτικά (iterative)

2. Το σύστηµα χτίζεται σταδιακά (incremental)

3. Είναι αρχιτεκτονικό-κεντρική (architecture centric) και

4. Βασίζεται στις περιπτώσεις χρήσης (use case driven)

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

12 ΠΛΗ24 – Σχεδιασµός Λογισµικού

3.1 Ο κύκλος ζωής στην ενοποιηµένη προσέγγιση

Σύµφωνα µε την ενοποιηµένη προσέγγιση, ο κύκλος ζωής ανάπτυξης λογισµικού έχει τέσσερις φάσεις:

1. Η έναρξη (inception) είναι η πρώτη φάση της ενοποιηµένης προσέγγισης, όπου παρουσιάζεται η αρχική ιδέα του συστήµατος τουλάχιστον µέχρι του σηµείου που είναι αρκετά καλά θεµελιωµένη έτσι ώστε να επιτρέψει την είσοδο στη φάση επεξεργασίας.

2. Η επεξεργασία (elaboration) είναι η δεύτερη φάση, όπου περιγράφεται το όραµα του συστήµατος καθώς και η υψηλού επιπέδου αρχιτεκτονική του. Σε αυτήν τη φάση, προσδιορίζονται οι απαιτήσεις του συστήµατος.

3. Η κατασκευή (construction) είναι η τρίτη φάση, όπου σχεδιάζεται και κατασκευάζεται το λογισµικό.

4. Η µετάβαση (transition) είναι η τέταρτη φάση της διαδικασίας, όπου το λογισµικό υπόκειται σε έλεγχο και τελικά παραδίδεται στους χρήστες. Η φάση της µετάβασης σηµατοδοτεί την έναρξη της φάσης της συντήρησης λογισµικού και όχι το τέλος της διαδικασίας.

Αν προσπαθήσουµε να συνοψίσουµε σε µια φράση το περιεχόµενο της κάθε φάσης τότε θα λέγαµε:

1. Έναρξη (inception) - Τεκµηριώνουµε την επιχειρηµατική ανάγκη ύπαρξης του συστήµατος

2. Επεξεργασία (elaboration) – Προγραµµατίζουµε το έργο (project planning) και δηµιουργούµε την αρχιτεκτονική του συστήµατος

3. Κατασκευή (construction) – Αναπτύσσουµε το σύστηµα

4. Μετάβαση (transition) – Παραδίδουµε το σύστηµα στους τελικούς χρήστες

Σε κάθε φάση µπορεί να εκτελεστεί ένας αριθµός επαναλήψεων (iterations). Στη συνέχεια, σε κάθε επανάληψη µπορεί να εκτελείται ένας αριθµός διαδικασιών (process) όπου κάθε διαδικασία, περιγράφεται µε ένα αριθµό διαφορετικών εργασιών (workflows). Έτσι µπορούµε να πούµε ότι ξεκινούµε από ένα γενικό κύκλο ζωής ενός έργου, συνεχίζουµε µε τις φάσεις, όπου σε κάθε φάση εκτελούµε επαναλήψεις, επαναλήψεις διαδικασιών που περιγράφονται µε ροές εργασιών.

Στην Εικόνα 2 παρουσιάζονται οι βασικές έννοιες του κύκλου ζωής και των επαναλήψεων που εκτελούνται µε γραφικό τρόπο.

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

13 ΠΛΗ24 – Σχεδιασµός Λογισµικού

επανάληψη φάση

Κύκλος ζωής

σύλληψη επεξεργασία κατασκευή µετάβαση

Τελικόσύστηµα

Στόχοισυστήµατος

ΑρχιτεκτονικήΣυστήµατος

ΣύστηµαΛειτουργικάΙκανό

επανάληψη φάση

Κύκλος ζωής

σύλληψη επεξεργασία κατασκευή µετάβαση

Τελικόσύστηµα

Στόχοισυστήµατος

ΑρχιτεκτονικήΣυστήµατος

ΣύστηµαΛειτουργικάΙκανό

Εικόνα 2: Βασικές έννοιες του κύκλου ζωής στην ενοποιηµένη προσέγγιση

Μια ροή εργασίας (workflow) είναι µια λογική οµαδοποίηση των δραστηριοτήτων και περιγράφει τους ρόλους των συµµετεχόντων, τις δραστηριότητες που εκτελούνται καθώς και τα αποτελέσµατα (artifacts) των δραστηριοτήτων που µπορεί να είναι παραδοτέα (deliverables), έγγραφα, κώδικας, πρότυπα ή οτιδήποτε άλλο µπορεί να παράγει µια δραστηριότητα.

Στην ενοποιηµένη προσέγγιση έχουµε εννέα διαφορετικές ροές εργασιών (process workflows) οι οποίες είναι οι ακόλουθες:

Βασικά workflows

1. Μοντελοποίηση επιχειρηµατικών διαδικασιών (business modeling): Περιγράφει τη δοµή και την οργάνωση των διαδικασιών µιας επιχείρησης

2. Προδιαγραφές (requirements): Περιγραφή προδιαγραφών συστήµατος µε χρήση περιπτώσεων χρήσης

3. Ανάλυση και σχεδίαση (analysis and design): Περιγραφή των µοντέλων του συστήµατος

4. Υλοποίηση (implementation): Υλοποίηση του συστήµατος, µοναδιαίος έλεγχος (unit testing) και έλεγχος ολοκλήρωσης (integration testing)

5. Έλεγχος (testing): Καταγραφή των περιπτώσεων ελέγχων, της διαδικασίας ελέγχου καθώς και των µετρικών που θα χρησιµοποιηθούν.

6. ∆ιάταξη (deployment): Αναφέρεται στη διάταξη του παραδοτέου συστήµατος

Βοηθητικά workflows

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

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

14 ΠΛΗ24 – Σχεδιασµός Λογισµικού

7. ∆ιοίκηση Σχηµατισµών (configuration management): ∆ιαχείριση όλων των παραδοτέων του έργου

8. ∆ιαχείριση έργου (project management): ∆ιαχείριση των στοιχείων του έργου (χρόνου, πόρων κ.λπ.)

9. Περιβάλλον (environment): ∆ηµιουργία της αναγκαίας υποδοµής για την εκτέλεση του έργου

Ένα παράδειγµα του τρόπου ορισµού της ροής εργασίας για τη διαχείριση έργου δίνεται στην Εικόνα 3.

ΑνάπτυξηΕπιχειρηµατικήςΠερίπτωσης

∆ιευθυντήςΈργου

ΑνάπτυξηΠλάνουΈργου

ΕπανεκτίµησηΚινδύνων

ΣτελέχωσηΈργου

Αξιολόγησηκύκλου

ΕκτέλεσηΚύκλου

ΑνάπτυξηΠλάνουΕπαναληπτικής Ανάπτυξης

ΠροσδιορισµόςΚινδύνων

ΑνάπτυξηΕπιχειρηµατικήςΠερίπτωσης

∆ιευθυντήςΈργου

ΑνάπτυξηΠλάνουΈργου

ΕπανεκτίµησηΚινδύνων

ΣτελέχωσηΈργου

Αξιολόγησηκύκλου

ΕκτέλεσηΚύκλου

ΑνάπτυξηΠλάνουΕπαναληπτικής Ανάπτυξης

ΠροσδιορισµόςΚινδύνων

Εικόνα 3: Παράδειγµα ορισµού ροής εργασίας

Στην Εικόνα 4 παρουσιάζεται ο συνδυασµός των φάσεων και των εργασιών στον κύκλο ζωής ενός έργου στο οποίο ακολουθείται η ενοποιηµένη προσέγγιση.

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

15 ΠΛΗ24 – Σχεδιασµός Λογισµικού

ΕΡΓΑΣΙΕΣ

Προδιαγραφές

Έλεγχος

Υλοποίηση

Ανάλυση και σχεδίαση

Μοντελοποίησηεπιχειρηµατικών διαδικασιών

Σύλληψη Επεξεργασία Κατασκευή Μετάβαση

ΦΑΣΕΙΣ

∆ιάταξη Συστήµατος

∆ιοίκηση Σχηµατισµών

∆ιαχείριση Έργου

Περιβάλλον

Εικόνα 4: Ο κύκλος ζωής στην ενοποιηµένη προσέγγιση.

Τα βασικά παραδοτέα της ενοποιηµένης προσέγγισης όπως τονίστηκε και παραπάνω είναι τα µοντέλα. Εποµένως το αποτέλεσµα των παραπάνω workflows είναι η δηµιουργία ενός αριθµού µοντέλων τα οποία στις περισσότερες περιπτώσεις βρίσκονται σε αντιστοιχία µε το όνοµα του workflow και είναι τα ακόλουθα:

1. Επιχειρηµατικό µοντέλο (Business model). Μοντελοποιεί την επιχείρηση και τις διαδικασίες της

2. Μοντέλο πεδίου προβλήµατος (Domain model). Περιγράφει το σύστηµα και καθορίζει τα όρια του συστήµατος.

3. Μοντέλο περιπτώσεων χρήσης (Use case model). Ορίζει τις προδιαγραφές του συστήµατος

4. Μοντέλο ανάλυσης (Analysis model). Περιγράφει τις αρχικές ιδέες (concepts) του συστήµατος

5. Μοντέλο σχεδιασµού (Design model). Περιγράφει το πώς θα υλοποιηθεί το σύστηµα.

6. Μοντέλο διαδικασιών (Process model). Περιγράφει τις φυσικές διαδικασίες του συστήµατος και τους µηχανισµούς συγχρονισµού.

7. Μοντέλο διάταξης (Deployment Model). Περιγράφει τη διάταξη-τοπολογία του φυσικού συστήµατος σε σχέση µε το περιβάλλον όπου το λογισµικό εκτελείται.

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

16 ΠΛΗ24 – Σχεδιασµός Λογισµικού

8. Μοντέλο Υλοποίησης (Implementation model). Περιγράφει το τρόπο µε τον οποίο θα κατασκευασθεί το τελικό σύστηµα από τα συστατικά του στοιχεία.

9. Μοντέλο Ελέγχου (Test model). Περιγράφει τη στρατηγική και τις διαδικασίες ελέγχου καθώς και τις περιπτώσεις ελέγχου (test cases).

Όπως περιγράφτηκε και παραπάνω ο τρόπος εφαρµογής της ενοποιηµένης προσέγγισης είναι δυναµικός και προσαρµόσιµος στις εκάστοτε ανάγκες. Στα επόµενα κεφάλαια θα περιγραφούν τα απαιτούµενα µοντέλα για την κατασκευή ενός συστήµατος για τη λειτουργία του ηλεκτρονικού ανθοπωλείου «Λευκός Κρίνος».

Πιο συγκεκριµένα για τη µελέτη περίπτωσης του ηλεκτρονικού ανθοπωλείου «Λευκός Κρίνος» θα δοθούν για τις βασικές εργασίες ανάπτυξης του συστήµατος τα εξής:

• καταγραφή των προδιαγραφών του συστήµατος

o το µοντέλο περιπτώσεων χρήσης και

o το µοντέλο του πεδίου προβλήµατος,

• ανάλυση και το σχεδιασµό

o το µοντέλο ανάλυσης

o το µοντέλο του σχεδιασµού

o το µοντέλο διάταξης

• υλοποίηση

o το µοντέλο υλοποίησης

• έλεγχος

o το µοντέλο ελέγχου

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

17 ΠΛΗ24 – Σχεδιασµός Λογισµικού

4 Περιγραφή Μελέτης Περίπτωσης Ηλεκτρονικού Ανθοπωλείου Το κεντρικό ανθοπωλείο «Λευκός Κρίνος» αποφάσισε να επεκτείνει τις δραστηριότητές του στο Internet δηµιουργώντας ένα ηλεκτρονικό ανθοπωλείο όπου οι πελάτες του θα µπορούν να παραγγέλνουν τις ανθοδέσµες της αρεσκείας τους. Πιο συγκεκριµένα το ανθοπωλείο αυτό θα προσφέρει τις εξής υπηρεσίες:

1. Ο κάθε πελάτης θα µπορεί να δηµιουργεί προσωπικό λογαριασµό στον οποίο θα αποθηκεύονται τα προσωπικά του δεδοµένα και ο οποίος θα προστατεύεται µε password.

2. To ανθοπωλείο θα µπορεί να δέχεται παραγγελίες από το internet. Ο χρήστης θα επιλέγει ένα-ένα τα διαφορετικά λουλούδια που θα βάλει στην ανθοδέσµη του καθώς και τον αριθµό των λουλουδιών του κάθε είδους που θέλει να αγοράσει. Εναλλακτικά, ο χρήστης θα µπορεί να επιλέξει µια ανθο-σύνθεση η οποία είναι προκαθορισµένη όσον αφορά το περιεχόµενο αλλά και την τιµή της.

3. Ανάλογα µε το είδος του προορισµού (κοντινός, µακρινός) του παραλήπτη θα γίνεται µια επισήµανση προς τον πελάτη σχετικά µε την ανθεκτικότητα των λουλουδιών. Επιπλέον για κάθε λουλούδι θα παρουσιάζονται τα χαρακτηριστικά του, άρωµα, χρώµα, µέγεθος, οικογένεια, προέλευση, ειδική περίσταση στην οποία προσφέρεται, φωτογραφία κ.λπ. Αντίστοιχα για τις συνθέσεις θα δίνεται µια σύντοµη περιγραφή, ο τύπος της (ροµαντική, επαγγελµατική, κ.λπ.) καθώς και φωτογραφία.

4. Όταν ο πελάτης ολοκληρώσει την επιλογή των λουλουδιών θα ζητούνται από το σύστηµα τα στοιχεία του παραλήπτη των λουλουδιών. Τα στοιχεία αυτά θα αποθηκεύονται στο σύστηµα σε σχέση µε κάθε πελάτη και θα είναι διαθέσιµα για να χρησιµοποιηθούν κάποια επόµενη φορά. Ταυτόχρονα ο πελάτης θα γράφει το µήνυµα το οποίο θα ήθελε να συνοδεύει την ανθοδέσµη.

5. Ο πελάτης θα µπορεί να προσθέσει όσες ανθοδέσµες θέλει στο «ηλεκτρονικό καρότσι», να τις αφαιρέσει ακυρώνοντας την επιλογή του, ή να ολοκληρώσει τη συναλλαγή του µε την πληρωµή αυτών που έχει επιλέξει.

6. Επιπλέον, για κάθε πελάτη το σύστηµα θα µπορεί να αποθηκεύει τα ονόµατα φίλων, συνεργατών, αγαπηµένων προσώπων µαζί µε σηµαντικές ηµεροµηνίες – επετείους έτσι ώστε όταν πλησιάζει η ηµεροµηνία της επετείου να στέλνει e-mail και να υπενθυµίζει την ηµέρα αυτή.

7. Το ηλεκτρονικό ανθοπωλείο θα συνδέεται µε το λογιστήριο της εταιρείας όπου υπάρχει το σύστηµα πληρωµής µε πιστωτικές κάρτες (το υποσύστηµα αυτό δεν ανήκει στο ηλεκτρονικό ανθοπωλείο αλλά συνεργάζεται µε αυτό). Το σύστηµα πιστωτικών καρτών επιτρέπει την ασφαλή πληρωµή των παραγγελθέντων λουλουδιών.

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

18 ΠΛΗ24 – Σχεδιασµός Λογισµικού

Την επιλεγµένη µελέτη περίπτωσης την συναντάµε πολύ συχνά στη διεθνή βιβλιογραφία για τον απλό λόγο ότι είναι εύκολη στην κατανόηση καθώς ο τρόπος λειτουργίας ενός ηλεκτρονικού καταστήµατος είναι γνωστός στους περισσότερους. Στα επόµενα κεφάλαια θα παρουσιασθεί βήµα-βήµα η ανάπτυξη του πληροφοριακού συστήµατος για το ηλεκτρονικό ανθοπωλείο. Πρέπει όµως στο σηµείο αυτό να γίνει ξεκάθαρο ότι στόχος δεν είναι να δοθεί η πλήρης τεκµηρίωση του συστήµατος αλλά να δοθούν ξεκάθαρα παραδείγµατα και πρακτικές συµβουλές για τον τρόπο ανάπτυξης µε τη χρήση της γλώσσας UML.

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

19 ΠΛΗ24 – Σχεδιασµός Λογισµικού

5 Καταγραφή και Ανάλυση Απαιτήσεων (Requirements Capture and analysis)

Η καταγραφή και η ανάλυση των απαιτήσεων έχει ως στόχο να απαντήσει στη βασική ερώτηση για το τι πρέπει να κάνει το σύστηµα. Είναι µια διαδικασία ιδιαίτερα επίπονη και δύσκολη καθώς πρέπει να κατανοήσουµε τις πραγµατικές ανάγκες των χρηστών και στη συνέχεια να τις καταγράψουµε. Ορισµένα από τα χαρακτηριστικά γνωρίσµατα της καταγραφής των απαιτήσεων είναι:

1. στις περισσότερες περιπτώσεις το σύστηµα απευθύνεται σε πολλούς χρήστες, οι οποίοι έχουν γνώση ενός µικρού µέρους µόνο της συνολικής εργασίας που καλείται να υποστηρίξει το πληροφοριακό σύστηµα,

2. οι ανάγκες της επιχείρησης αλλάζουν κατά τη διάρκεια ανάπτυξης του συστήµατος,

3. κάθε έργο ανάπτυξης λογισµικού είναι µοναδικό· η µοναδικότητα αυτή προέρχεται από τη διαφορετικότητα του πεδίου προβλήµατος, τη διαφορετικότητα του οργανισµού που θα χρησιµοποιεί το σύστηµα κ.λπ.

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

Είναι προφανές λοιπόν ότι η καταγραφή των απαιτήσεων είναι µια διαδικασία σύνθετη η οποία και διαφέρει από έργο σε έργο. Στη γενική περίπτωση η καταγραφή και η ανάλυση των απαιτήσεων περιλαµβάνει τα ακόλουθα:

1. Προσδιορισµός του µοντέλου του πεδίου προβλήµατος (domain model). Το µοντέλο του προβλήµατος περιγράφει τις βασικές οντότητες-έννοιες που αποτελούν το σύστηµα.

2. Προσδιορισµός του αντικειµένου εργασιών του συστήµατος (scope map). Προσδιορίζει µε επιγραµµατικό τρόπο τις απαιτήσεις του συστήµατος.

3. Προσδιορισµός του µοντέλου των περιπτώσεων χρήσης (use case model). Προσδιορίζει τον τρόπο µε τον οποίο χρησιµοποιείται το σύστηµα

4. Οργάνωση των περιπτώσεων χρήσης σε πακέτα. Οµαδοποιεί τις περιπτώσεις χρήσεις σε λογικά πακέτα.

5. Ανάπτυξη πρωτότυπων του συστήµατος µε σκοπό την επίδειξη στο χρήστη βασικών παραµέτρων.

5.1 Το µοντέλο του πεδίου προβλήµατος

Το µοντέλο πεδίου προβλήµατος είναι ένα από τα βασικά µοντέλα της UML. Πρωταρχικός µας στόχος στη δηµιουργία του µοντέλου του πεδίου προβλήµατος είναι να προσδιορίσουµε τις αφαιρέσεις του πραγµατικού κόσµου που απαιτούνται για την κατασκευή του συστήµατος —δηλαδή τα κύρια εννοιολογικά (conceptual)

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

20 ΠΛΗ24 – Σχεδιασµός Λογισµικού

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

Θα περίµενε κάποιος ότι ο ορισµός των περιπτώσεων χρήσης προηγείται του ορισµού του µοντέλου πεδίου προβλήµατος. Αν και στην πράξη ο ορισµός των δύο µοντέλων γίνεται ταυτόχρονα, ο ορισµός του µοντέλου πεδίου προβλήµατος προηγείται των περιπτώσεων χρήσης µια και οι περιπτώσεις χρήσης πρέπει να γραφούν µε τέτοιο τρόπο ώστε να λαµβάνουν υπόψη τα εννοιολογικά αντικείµενα που καθορίζονται στο µοντέλο του προβλήµατος (conceptual model). Επιπλέον, µε την προσέγγιση αυτή µπορούµε να συνδέσουµε το στατικό και το δυναµικό µοντέλο του συστήµατος. Εν κατακλείδι, το µοντέλο του πεδίου προβλήµατος αποτελεί ένα αρχικό λεξικό όρων και εννοιών του προς ανάπτυξη συστήµατος.

Καθώς προσδιορίζουµε τα εννοιολογικά αντικείµενα, πρέπει επίσης να προσδιορίσουµε τις σχέσεις µεταξύ τους. Τρεις είναι οι πιο σηµαντικοί τύποι σχέσεων:

• η σχέση γενίκευσης/ειδίκευσης (generalization/specialization) µε την οποία περιγράφουµε την κληρονοµικότητα,

• η σχέση συναρµολόγησης (aggregation) µε την οποία περιγράφουµε τη σύνθεση και τέλος

• οι απλές συσχετίσεις που περιγράφουν την ανάγκη ύπαρξης άλλων αντικειµένων µε σκοπό την υλοποίηση µιας συµπεριφοράς.

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

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

Μερικοί βασικοί κανόνες για την εύρεση των κλάσεων είναι:

1. Τα ουσιαστικά και οι ονοµαστικές φράσεις γίνονται κλάσεις ή πεδία κλάσεων.

2. Τα ρήµατα και οι ρηµατικές φράσεις γίνονται µέθοδοι και συνδέσεις (associations).

3. Οι κτητικές φράσεις δείχνουν ότι το ουσιαστικό αναπαριστά µια ιδιότητα παρά µια κλάση.

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

21 ΠΛΗ24 – Σχεδιασµός Λογισµικού

Αν εφαρµόσουµε τους κανόνες χρησιµοποιώντας τη γενική περιγραφή του προβλήµατος τότε καταλήγουµε σε ένα αριθµό υποψηφίων κλάσεων. Οι κλάσεις που παράγονται µε τον τρόπο αυτό παρουσιάζονται υπογραµµισµένες.

Το κεντρικό ανθοπωλείο «Λευκός Κρίνος» αποφάσισε να επεκτείνει τις δραστηριότητές του στο Internet δηµιουργώντας ένα ηλεκτρονικό ανθοπωλείο όπου οι πελάτες του θα µπορούν να παραγγέλνουν τις ανθοδέσµες της αρεσκείας τους. Πιο συγκεκριµένα το ανθοπωλείο αυτό θα πρέπει να δίνει τη δυνατότητα στους πελάτες του να κάνουν τα ακόλουθα:

1. Ο κάθε πελάτης µπορεί να δηµιουργεί προσωπικό λογαριασµό στον οποίο αποθηκεύονται τα προσωπικά του δεδοµένα και ο οποίος προστατεύεται µε password.

2. To ανθοπωλείο θα µπορεί να δέχεται παραγγελίες από το internet. Ο χρήστης επιλέγει ένα-ένα τα διαφορετικά λουλούδια που θα βάλει στην ανθοδέσµη του καθώς και τον αριθµό των λουλουδιών του κάθε είδους που θέλει να αγοράσει. Εναλλακτικά, ο χρήστης µπορεί να επιλέξει µια ανθο-σύνθεση η οποία είναι προκαθορισµένη όσο αφορά το περιεχόµενο αλλά και την τιµή της.

3. Ανάλογα µε το είδος του προορισµού (κοντινός, µακρινός) του παραλήπτη γίνεται µια επισήµανση προς τον πελάτη σχετικά µε την ανθεκτικότητα των λουλουδιών. Επιπλέον για κάθε λουλούδι παρουσιάζονται τα χαρακτηριστικά του: άρωµα, χρώµα, µέγεθος, οικογένεια, προέλευση, ειδική περίσταση στην οποία προσφέρεται, φωτογραφία κ.λπ. Αντίστοιχα για τις συνθέσεις δίνεται µια σύντοµη περιγραφή, ο τύπος της (ροµαντική, επαγγελµατική, κ.λπ.) καθώς και φωτογραφία.

4. Όταν ο πελάτης ολοκληρώσει την επιλογή των λουλουδιών ζητούνται από το σύστηµα τα στοιχεία του παραλήπτη των λουλουδιών. Τα στοιχεία αυτά αποθηκεύονται στο σύστηµα σε σχέση µε κάθε πελάτη και είναι διαθέσιµα για να χρησιµοποιηθούν κάποια επόµενη φορά. Ταυτόχρονα ο πελάτης γράφει το µήνυµα το οποίο θα ήθελε να συνοδεύει την ανθοδέσµη.

5. Ο πελάτης µπορεί να προσθέσει όσες ανθοδέσµες θέλει στο «ηλεκτρονικό καρότσι», να τις αφαιρέσει ακυρώνοντας την επιλογή του, ή να ολοκληρώσει τη συναλλαγή του µε την πληρωµή αυτών που έχει επιλέξει.

6. Επιπλέον, για κάθε πελάτη το σύστηµα µπορεί να αποθηκεύει τα ονόµατα φίλων, συνεργατών, αγαπηµένων προσώπων µαζί µε σηµαντικές ηµεροµηνίες – επετείους έτσι ώστε όταν πλησιάζει η ηµεροµηνία της επετείου να στέλνει e-mail και να υπενθυµίζει την ηµέρα αυτή.

7. Το ηλεκτρονικό ανθοπωλείο θα συνδέεται µε το λογιστήριο της εταιρείας όπου υπάρχει το σύστηµα πληρωµής µε πιστωτικές κάρτες (το υποσύστηµα αυτό δεν ανήκει στο ηλεκτρονικό ανθοπωλείο αλλά συνεργάζεται µε αυτό). Το σύστηµα πιστωτικών καρτών επιτρέπει την ασφαλή πληρωµή των παραγγελθέντων λουλουδιών.

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

22 ΠΛΗ24 – Σχεδιασµός Λογισµικού

Εικόνα 5: Λεκτική ανάλυση αρχικής περιγραφής του συστήµατος

Αφού έχουµε εντοπίσει τις βασικές κλάσεις του συστήµατος ρωτάµε για κάθε µια από αυτές τις ακόλουθες ερωτήσεις:

• Είναι πράγµα ή είναι οικογένεια/κατηγορία πραγµάτων;

• Είναι µέρος του προβλήµατος;

• Έχει δεδοµένα και συµπεριφορά;

• Είναι λεπτοµέρεια υλοποίησης ή όχι;

• Είναι ένα συµβάν/γεγονός;

• Είναι ιδιότητα ενός πράγµατος;

Βάση της παραπάνω ανάλυσης θα καταλήξουµε στις κλάσεις του πεδίου προβλήµατος µετά από προσεκτική ανάλυση της κάθε περίπτωσης. Στον παρακάτω πίνακα οι υποψήφιες κλάσεις παρουσιάζονται µε τη σειρά εµφάνισης στο κείµενο της γενικής περιγραφής του προβλήµατος.

Όνοµα υποψήφιας κλάσης

Σκεπτικό

Ανθοπωλείο Αν και η περιγραφή του προβλήµατος δε ζητάει συγκεκριµένα να κρατάµε τα στοιχεία του Ανθοπωλείου, είναι προφανές ότι κάθε κατάστηµα (ηλεκτρονικό η όχι) έχει µια διεύθυνση, ΑΦΜ, υπεύθυνο κατά το νόµο, στοιχεία τα οποία θα πρέπει να αναγράφονται στο τιµολόγιο πώλησης.

Internet Η υποψήφια κλάση είναι αόριστη και συνεπώς απορρίπτεται

Πελάτης Είναι βασική οντότητα του συστήµατος

Ανθοδέσµη Είναι βασική οντότητα του συστήµατος. Από την εµπειρική γνώση γνωρίζουµε ότι µια ανθοδέσµη αποτελείται από λουλούδια

Λογαριασµός (πελάτη) Αποτελεί βασική οντότητα του συστήµατος. Θα πρέπει να διευκρινίσουµε στη συνέχεια τη σχέση µεταξύ λογαριασµού πελάτη και πελάτη και να προσδιορίσουµε τις υπευθυνότητες της κάθε κλάσης.

Προσωπικά ∆εδοµένα Τα προσωπικά δεδοµένα είναι δεδοµένα που αναφέρονται στον πελάτη. Εποµένως η πιο λογική επιλογή είναι να αποτελέσουν πεδίο της κλάσεως πελάτης

Password Βάση του ιδίου σκεπτικού µε παραπάνω, το password

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

23 ΠΛΗ24 – Σχεδιασµός Λογισµικού

Όνοµα υποψήφιας κλάσης

Σκεπτικό

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

Παραγγελία Αποτελεί βασική οντότητα του συστήµατος. Χρειάζεται να ορίσουµε τον τρόπο µε τον οποίο µια παραγγελία σχετίζεται µε τα αντικείµενα παραγγελίας (ανθοδέσµες)

Χρήστης Είναι συνώνυµο του πελάτη

Λουλούδι Είναι βασική οντότητα του συστήµατος. Βάση της εµπειρικής γνώσης γνωρίζουµε ότι πολλά λουλούδια φτιάχνουν µια ανθοδέσµη

Αριθµός (λουλουδιών) Είναι πεδίο της ανθοδέσµης

Είδος (λουλουδιών) Είναι ασαφές. Θα µπορούσε να είναι συνώνυµο µε το λουλούδι. Η κλάση λουλούδι δηµιουργεί «αντικείµενα» λουλούδια τα οποία έχουν διαφορετικά είδη.

Ανθοσύνθεση Είδος προκατασκευασµένης ανθοδέσµης.

Περιεχόµενο (ανθοσύνθεσης)

Το περιεχόµενο της ανθοσύνθεσης περιγράφεται ουσιαστικά από τη σχέση µεταξύ των κλάσεων λουλούδι-ανθοδέσµη

Τιµή (ανθοσύνθεσης) Είναι πεδίο της ανθοδέσµης

Παραλήπτης Είναι οντότητα του συστήµατος που σχετίζεται µε την παραγγελία

Επισήµανση Είναι πεδίο της κλάσης λουλούδι που σχετίζεται µε την ανθεκτικότητα του λουλουδιού.

Χαρακτηριστικά λουλουδιού (άρωµα, χρώµα, µέγεθος, οικογένεια, προέλευση, ειδική περίσταση)

Πεδία του λουλουδιού

Περιγραφή, Τύπος (Ανθοσύνθεσης)

Πεδία της ανθοσύνθεσης

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

24 ΠΛΗ24 – Σχεδιασµός Λογισµικού

Όνοµα υποψήφιας κλάσης

Σκεπτικό

Σύνθεση Συνώνυµο της ανθοσύνθεσης

Επιλογή (λουλουδιών) Τρόπος υλοποίησης της διαδικασίας κατασκευής ανθοδέσµης

Στοιχεία (παραλήπτη ανθοδέσµης)

Σύνθετο πεδίο του παραλήπτη της ανθοδέσµης

Μήνυµα (ανθοδέσµης) Το µήνυµα που συνοδεύει την ανθοδέσµη. Οντότητα του συστήµατος

Σύστηµα Γενική περιγραφή. Απορρίπτεται από υποψήφια κλάση ως γενική περιγραφή

Ηλεκτρονικό καρότσι Οντότητα του συστήµατος που οµαδοποιεί τις παραγγελίες και κρατάει τις µέχρι τώρα επιλογές του χρήστη

Συναλλαγή Οντότητα του συστήµατος η οποία ολοκληρώνει την παραγγελία του πελάτη µε την πληρωµή.

Πληρωµή Θα µπορούσε να είναι οντότητα του συστήµατος αλλά στην προκείµενη περίπτωση χρησιµοποιήθηκε η συναλλαγή. Εποµένως η υποψήφια αυτή κλάση απορρίπτεται ως πλεονασµατική.

Όνοµα φίλου Πεδίο της κλάσης επετείου

Επέτειος Η επέτειος είναι κλάση του συστήµατος η οποία συσχετίζεται µε την κλάση πελάτης. Παρατηρούµε ότι θα µπορούσαµε να θεωρήσουµε την επέτειο ως την ηµεροµηνία της επετείου η οποία σχετίζεται µε ένα µέλος της κλάσης φίλου. Το γεγονός όµως ότι µπορούµε να σχετίζουµε µε κάθε άτοµο-φίλο πολλές ηµεροµηνίες επετείων (γάµου, γενεθλίων κ.λπ.) µας κατευθύνει στο να ορίσουµε την επέτειο ως τη βασική οντότητα και όχι το όνοµα του φίλου.

Αποστολή e-mail Η γενική περιγραφή του συστήµατος δεν προσδιορίζει το τι ακριβώς πρέπει να γίνεται στην περίπτωση αυτή. Πρέπει απλά να στέλνουµε ένα e-mail στην αποθηκευµένη διεύθυνση ή µήπως να καταγράφουµε ειδικό µήνυµα και να κρατάµε επιπλέον στοιχεία. Στη δεδοµένη περίπτωση επιλέγουµε απλά η διεύθυνση e-mail να είναι ένα πεδίο της κλάσης επέτειος.

Λογιστήριο Γενική περιγραφή µιας οργανωτικής δοµής. ∆εν αποτελεί κλάση του πεδίου προβλήµατος.

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

25 ΠΛΗ24 – Σχεδιασµός Λογισµικού

Όνοµα υποψήφιας κλάσης

Σκεπτικό

Εταιρεία Είναι συνώνυµο της κλάσης Ανθοπωλείο

Σύστηµα πληρωµής Αναφέρεται ρητά ότι το σύστηµα αυτό δεν αποτελεί κλάση του πεδίου προβλήµατος.

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

1. Κλάσεις που αν και έχουν διαφορετικό όνοµα επαναλαµβάνουν την ίδια έννοια, πράγµα π.χ. πελάτης και χρήστης θα πρέπει να απαλείφονται.

2. Κλάσεις οι οποίες είναι άσχετες µε το πεδίο προβλήµατος που καλούµαστε να επιλύσουµε θα πρέπει να απαλείφονται.

3. Κλάσεις που είναι γενικές και συνεπώς δεν συνεισφέρουν στην επίλυση του προβλήµατος (π.χ. internet) θα πρέπει να απαλείφονται.

4. Έννοιες που περιγράφουν µια λειτουργία-διαδικασία που εφαρµόζεται σε άλλες οντότητες είναι πιθανότερο να αντιστοιχούν σε µεθόδους και όχι σε κλάσεις.

5. Περιγραφές για το πως θα υλοποιηθεί µια έννοια ή µια διαδικασία θα πρέπει να απαλείφονται από το µοντέλο του πεδίου προβλήµατος.

Στην Εικόνα 6 παρουσιάζονται οι κλάσεις του πεδίου προβλήµατος µαζί µε τις βασικές τους σχέσεις. Υπενθυµίζουµε, ότι το γραφικό σύµβολο του ρόµβου συµβολίζει τη σχέση συναρµολόγησης, το σύµβολο του τριγώνου αναπαριστά σχέση κληρονοµικότητας ενώ η απλή γραµµή αναπαριστά σχέση συσχέτισης.

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

26 ΠΛΗ24 – Σχεδιασµός Λογισµικού

Εικόνα 6: ∆ιάγραµµα κλάσεων του πεδίου προβλήµατος

Ξεκινώντας από την κλάση «Ανθοπωλείο» παρατηρούµε ότι η κλάση συνδέεται µε σχέση συναρµολόγησης µε τις κλάσεις «Πελάτης» και «Κατάλογος». Η ερµηνεία των σχέσεων αυτών είναι ότι ένα ανθοπωλείο έχει πελάτες και οι πωλήσεις γίνονται βάση καταλόγου. Η κλάση κατάλογος δεν προκύπτει από την περιγραφή του πεδίου προβλήµατος αλλά από τη γνώση του πεδίου προβλήµατος.

Ο πελάτης σχετίζεται µε τις κλάσεις «Λογαριασµός», «Προτιµήσεις Πελάτη» και «Επέτειος».

Το «Λουλούδι» συνδέεται µε σχέση συναρµολόγησης µε την «Ανθοδέσµη». Η σχέση συναρµολόγησης είναι τύπου «περιέχει» (aggregation) και για το λόγο αυτό χρησιµοποιούµε το λευκό ρόµβο. Επιπλέον, η κλάση «Ανθοδέσµη» σχετίζεται µε την κλάση «Σύνθεση» µε σχέση κληρονοµικότητας µια και η «Σύνθεση» είναι ειδικού τύπου ανθοδέσµη.

Αντίστοιχα υπάρχει σχέση συναρµολόγησης µεταξύ των κλάσεων «Λίστα Παραγγελιών», «Παραγγελίας» και «Ανθοδέσµης».

Κάθε «Πελάτης» του συστήµατος έχει ένα µοναδικό «Ηλεκτρονικό Καρότσι» το οποίο κρατά όλες τις παραγγελίες («Λίστα Παραγγελιών») του συγκεκριµένου πελάτη. Το «Ηλεκτρονικό Καρότσι» προσδιορίζεται µοναδικά ανά πελάτη και ανά

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

27 ΠΛΗ24 – Σχεδιασµός Λογισµικού

session (σύνδεση πελάτη µε το ηλεκτρονικό ανθοπωλείο µια συγκεκριµένη ώρα και ηµέρα).

Ο παρακάτω πίνακας είναι αρκετά βοηθητικός για τον προσδιορισµό των κλάσεων και των σχέσεων µεταξύ τους:

Τύπος Ουσιαστικό Παράδειγµα Τι µπορεί να είναι

Οικογένεια/κατηγορία πραγµάτων

Άτοµο, λογιστής, όχηµα, τιµολόγιο, προϊόν

Κλάση

Ένα όνοµα, ένα ουσιαστικό µε επιθετικό προσδιορισµό

Γιώργος, µεγαλύτερο όχηµα, πρώτο τιµολόγιο

Αντικείµενο

Ιδιότητα αντικειµένου Ηλικία, Χρώµα Πεδίο κλάσης

Τιµή αντικειµένου 27 ετών, κίτρινο Τιµή πεδίου

Μια συνθήκη Ηλικία > Κατάσταση αντικειµένου

Ρήµα ενεργητικής φωνής µετά από αντικείµενο

Γιώργος δίνει αναφορά.

Γιώργος αποθηκεύει

Μέθοδος κλάσης

Γεγονός, χρόνος, συµβάν

Χτύπηµα τηλέφωνο, Πάρτι Γενέθλιων

Μέθοδος κλάσης,

Συνεργασία αντικειµένων

Μερικά σηµεία που θα πρέπει να προσέχουµε κατά τη διάρκεια της κατασκευής του µοντέλου του πεδίου προβλήµατος είναι τα ακόλουθα:

• ∆εν είναι σκόπιµο στην παρούσα φάση να αφιερώσουµε χρόνο στον ορισµό της πολλαπλότητας (multiplicity) των σχέσεων µεταξύ των κλάσεων.

• Η λεκτική ανάλυση της γενικής περιγραφής του προβλήµατος είναι σηµαντική αλλά δε θα πρέπει να γίνεται εξαντλητικά µια και αποτελεί µόνο το εφαλτήριο. Άλλες πηγές αρχικής πληροφορίας είναι: οι συνεντεύξεις µε τους χρήστες, η γνώµη των ειδικών, η καλή γνώση του πεδίου προβλήµατος, η εµπειρία κ.λπ.

• ∆ε θα πρέπει να αναθέτουµε µεθόδους στις κλάσεις κατά την κατασκευή του πεδίου προβλήµατος Αυτό θα γίνει αργότερα όταν θα αναλύσουµε τη δυναµική συµπεριφορά του συστήµατος.

• Το µοντέλο πεδίου προβλήµατος δε θα πρέπει να προκρίνει τεχνικές λύσεις. Για παράδειγµα η χρήση συγκεκριµένων πρωτοκόλλων, βάσεων δεδοµένων θα πρέπει να αποφασισθεί ή απλά να ληφθεί υπόψη κατά τη φάση του σχεδιασµού.

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

28 ΠΛΗ24 – Σχεδιασµός Λογισµικού

• Συζητήσεις για το αν θα πρέπει να χρησιµοποιηθεί σχέση σύνδεσης (association) ή σχέση συναρµολόγησης (aggregation) ή σχέση σύνθεσης (composition) δεν έχουν ουσία στη φάση της κατασκευής του µοντέλου του πεδίου προβλήµατος.

• Η κατασκευή και η εύρεση των κλάσεων απαιτεί την κατανόηση του προβλήµατος- συστήµατος υπό κατασκευή

• Προσπαθήστε να κρατήσετε το διάγραµµά σας όσο το δυνατόν πιο απλό. Η εύκολη κατανόηση του διαγράµµατος πρέπει να αποτελεί βασικό στόχο.

• ∆ιαλέξτε ονόµατα πολύ προσεκτικά. Τα ονόµατα δηµιουργούν συνειρµούς και συσχετίσεις. Για το λόγο αυτό τα ονόµατα πρέπει ναι είναι προσεκτικά επιλεγµένα από το πεδίο του προβλήµατος.

5.2 Το µοντέλο των περιπτώσεων χρήσης (use case model)

Το µοντέλο των περιπτώσεων χρήσης του συστήµατος είναι από τα σπουδαιότερα στην ανάπτυξη του συστήµατος µια και περιγράφει για ποιόν αναπτύσσεται το σύστηµα και τι πρέπει να κάνει το σύστηµα. Ίσως είναι το πιο διαδεδοµένο µοντέλο της UML. Αν και το µοντέλο περιπτώσεων χρήσης, περιλαµβάνει το διάγραµµα περιπτώσεων χρήσης, η βασική περιγραφή του συστήµατος γίνεται στην αναλυτική περιγραφή των περιπτώσεων χρήσης και όχι µε τη χρήση του διαγράµµατος.

Μια περίπτωση χρήσης είναι ένας διαφορετικός τρόπος µε τον οποίο ένας χρήστης µπορεί πραγµατικά να χρησιµοποιήσει το σύστηµα. Η εκφραστική δύναµη των περιπτώσεων χρήσης βασίζεται κατά κύριο λόγο στην απλότητα και την οργάνωση: όταν προσδιορίζουµε και οργανώνουµε τις περιπτώσεις χρήσης, µπορούµε να έχουµε µια σαφή εικόνα αυτού που το σύστηµα πρέπει να κάνει. Επιπλέον, χρησιµοποιώντας το µοντέλο των περιπτώσεων χρήσης µπορούµε να παρουσιάσουµε αυτήν τη σαφή εικόνα στους πελάτες, τους χρήστες του συστήµατος — πράγµα το οποίο βοηθά στην επικοινωνία και τη συζήτηση για το τι πρέπει να κάνει το σύστηµα.

Στην ενοποιηµένη προσέγγιση, το µοντέλο των περιπτώσεων χρήσης έχει κεντρικό ρόλο στην ανάπτυξη του συστήµατος µια και χρησιµοποιείται για την κατασκευή όλων των µοντέλων του συστήµατος. Επιπλέον, είναι αυτό το οποίο χρησιµοποιείται για την ιχνηλάτιση των απαιτήσεων (traceability) σε όλες της φάσης ανάπτυξης του συστήµατος. Αυτό παρουσιάζεται µε σαφήνεια στην Εικόνα 7, όπου και παρουσιάζεται η σχέση µεταξύ των διαφορετικών µοντέλων µε το µοντέλο περιπτώσεων χρήσης.

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

29 ΠΛΗ24 – Σχεδιασµός Λογισµικού

Class …

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

Μοντέλοπεδίου προβλήµατος

Μοντέλοανάλυσης

Μοντέλοσχεδιασµού

Μοντέλουλοποίησης

Μοντέλοελέγχου

OK

FAIL

εκφράζεται µε

δοµείται µεπραγµατοποιείται µε

υλοποιείται µεελέγχεται µε

Εικόνα 7: Η σχέση του µοντέλου περιπτώσεων χρήσης µε τα άλλα µοντέλα

Οι περιπτώσεις χρήσης µπορούν να χρησιµοποιηθούν µε πολλούς διαφορετικούς τρόπους και σε διαφορετικές περιπτώσεις, όπως:

• Για την περιγραφή επιχειρηµατικών διαδικασιών

• Για την περιγραφή των προδιαγραφών του συστήµατος

• Για τον προσδιορισµό των απαιτήσεων

• Για την τεκµηρίωση της λειτουργικότητας του συστήµατος

Η διαδικασία ανάπτυξης του µοντέλου των περιπτώσεων χρήσης συνίσταται στον προσδιορισµό των παρακάτω:

• Ποιος χρησιµοποιεί το σύστηµα

• Πως χρησιµοποιείται το σύστηµα

• Ποιο είναι το περιβάλλον του συστήµατος και ποια τα όρια του συστήµατος

• Πως το σύστηµα οργανώνεται σε πακέτα.

Η ανάπτυξη του µοντέλου των περιπτώσεων χρήσης είναι µια επαναληπτική διαδικασία στην οποία πρέπει να εµπλέκονται όλοι οι συµµετέχοντες του έργου. Για το λόγο αυτό θα πρέπει να καθορίσουµε επαναληπτικούς κύκλους, σε κάθε ένα εκ των οποίων θα αναπτύσσουµε ένα αριθµό περιπτώσεων χρήσης. Με τον τρόπο αυτό µπορούµε να έχουµε σταθερή πρόοδο (4-6 εβδοµάδες) και σε τακτά χρονικά διαστήµατα να δίνουµε στους συµµετέχοντες για επαλήθευση έναν αριθµό περιπτώσεων χρήσης. Για το λόγο αυτό χρειάζεται να προσδιορίσουµε την λίστα των αρχικών περιπτώσεων χρήσης (scope map).

Για το ηλεκτρονικό ανθοπωλείο µπορούµε να ορίσουµε ένα αρχικό σύνολο περιπτώσεων χρήσης (scope map) οι οποίες και είναι:

1. ∆ηµιουργία Λογαριασµού Πελάτη

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

30 ΠΛΗ24 – Σχεδιασµός Λογισµικού

2. Σύνδεση Πελάτη µε Σύστηµα (Log In)

3. ∆ιαχείριση Παραγγελίας

4. ∆ηµιουργία Ανθοδέσµης

5. Επιλογή Λουλουδιών

6. Επιλογή Ανθοδέσµης

7. Προβολή Στοιχείων Λουλουδιών/Ανθοδέσµης

8. ∆ιαχείριση «ηλεκτρονικού καροτσιού»

9. ∆ιαχείριση στοιχείων παραλήπτη/µηνύµατος

10. Πληρωµή λογαριασµού

11. ∆ιαχείριση επετείων

12. ∆ιαχείριση προτιµήσεων πελάτη

Εικόνα 8: Το αρχικό σύνολο περιπτώσεων χρήσης (scope map)

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

5.2.1 Προσδιορισµός των χειριστών (actors)

Όπως έχουµε ήδη αναφέρει το µοντέλο των περιπτώσεων χρήσης περιγράφει το τι κάνει το σύστηµα για κάθε τύπο χρήστη. Κάθε διαφορετική κατηγορία χρηστών αναπαρίσταται µε ένα χειριστή (actor). Επιπλέον κάθε εξωτερικό σύστηµα που αλληλεπιδρά µε το υπό ανάπτυξη σύστηµα αναπαρίσταται µε ένα χειριστή.

Στο σηµείο αυτό αξίζει να αναφερθούµε και να επεξηγήσουµε µερικές βασικές έννοιες οι οποίες συγχέονται και προκαλούν προβληµατισµό:

Συµµετέχοντες (stakeholders): Είναι όλοι αυτοί που ενδιαφέρονται για την πρόοδο του έργου της ανάπτυξης του συστήµατος λογισµικού. Βάση αυτού του ορισµού συµµετέχοντες είναι η διοίκηση της εταιρείας που χρηµατοδοτεί την ανάπτυξη του έργου, η διοίκηση της εταιρείας που εκτελεί το έργο, η οµάδα του έργου, οι χρήστες του συστήµατος, κ.λπ.

Πελάτες (customers): Ο οργανισµός που χρηµατοδοτεί την ανάπτυξη του συστήµατος. Η ικανοποίηση των πελατών είναι βασικός στόχος της διαδικασίας ανάπτυξης του συστήµατος

Χρήστες (users): Οι εργαζόµενοι του οργανισµού για τον οποίο φτιάχνεται το σύστηµα και οι πελάτες (clients) του οργανισµού που χρηµατοδοτεί την ανάπτυξη του συστήµατος (οι πελάτες του πελάτη). Η ικανοποίηση των αναγκών των χρηστών, η αυτοµατοποίηση της εργασίας τους, η αύξηση της παραγωγικότητας,

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

31 ΠΛΗ24 – Σχεδιασµός Λογισµικού

η ευχάριστη εµπειρία από την αλληλεπίδρασή τους µε το σύστηµα είναι βασικοί στόχοι της ανάπτυξης του συστήµατος.

Χειριστές (actors): Είναι οι χρήστες του συστήµατος καθώς και τα εξωτερικά συστήµατα µε τα οποία αλληλεπιδρά το σύστηµα. Είναι αυτοί που περιγράφονται στο µοντέλο των περιπτώσεων χρήσης του συστήµατος.

Στις περισσότερες περιπτώσεις οι χειριστές είναι οι άνθρωποι που αλληλεπιδρούν µε το σύστηµα, δηλαδή οι χρήστες. Για τον προσδιορισµό των χειριστών που δεν είναι χρήστες, πρέπει να λάβουµε υπόψη τους ακόλουθους κανόνες:

1. Στην περίπτωση που έχουµε εξωτερικά συστήµατα που αλληλεπιδρούν µε το σύστηµα τότε εισάγουµε έναν χειριστή ο οποίος λειτουργεί ως πληρεξούσιο (proxy). Εάν το εξωτερικό σύστηµα είναι µια βάση δεδοµένων τότε θα πρέπει να εξετάσουµε µε προσοχή αν η βάση δεδοµένων θεωρείται εσωτερική ή εξωτερική του συστήµατος. Αν οι χειριστές της βάσης δεδοµένων είναι ίδιοι µε αυτούς του συστήµατος τότε θεωρούµε ότι είναι εσωτερική του συστήµατος και τη χειριζόµαστε σαν υποσύστηµα.

2. Μια άλλη περίπτωση που θα πρέπει να προβληµατισθούµε σχετικά µε την ύπαρξη χειριστή, είναι όταν έχουµε συσκευές εισόδου (input device) ή/και εξόδου (output device).

a. Οι συσκευές εισόδου µεταφέρουν κάποιο γεγονός ή συνθήκη από τον εξωτερικό κόσµο στο σύστηµα. Γενικά µια συσκευή εισόδου µπορεί να δρα µε δύο διαφορετικούς διακριτούς τρόπους: o πρώτος τρόπος είναι η συσκευή εισόδου να δρα ως ενδιάµεσος σε σχέση µε αυτόν που προκαλεί το γεγονός. Για παράδειγµα, το πληκτρολόγιο είναι συσκευή εισόδου για όλους τους χρήστες, ή το τηλεχειριστήριο δρα ως ενδιάµεσος µεταξύ του τηλεθεατή και της τηλεόρασης. Στην περίπτωση αυτή δεν εισάγουµε χειριστή. Ο δεύτερος τρόπος µε τον οποίο µπορεί να λειτουργεί µια συσκευή εισόδου είναι ως πληρεξούσιο για το ρυθµιστή του ορίου ενός αισθητήρα. Παραδείγµατος χάριν ένας θερµοστάτης σε ένα σύστηµα ψύξης ρυθµίζει τη λειτουργία του κινητήρα όταν η θερµοκρασία αυξάνεται πάνω από ένα προκαθορισµένο επίπεδο. Ο θερµοστάτης είναι χειριστής επειδή ενεργεί ως πληρεξούσιο του προσώπου που θέτει το όριο θερµοκρασίας.

b. Αντίστοιχα, οι συσκευές εξόδου παράγουν ένα αποτέλεσµα το οποίο χρησιµοποιείται από ένα συµµετέχοντα ή χρήστη του συστήµατος. Παραδείγµατος χάριν ο συµπιεστής σε ένα σύστηµα ψύξης είναι χειριστής επειδή ενεργεί πάνω στο σύστηµα για να ικανοποιήσει τις επιθυµίες του προσώπου που θέλει το περιεχόµενο κρύο.

c. Τέλος δε µπορούµε να θεωρήσουµε όλες τις συσκευές εισόδου/εξόδου ως χειριστές. Για παράδειγµα, οι στάνταρτ συσκευές εισόδου/εξόδου όπως το πληκτρολόγιο, το ποντίκι, η οθόνη δε θεωρούνται χειριστές

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

32 ΠΛΗ24 – Σχεδιασµός Λογισµικού

γιατί η λειτουργία τους είναι διαφανής (απλά περνούνε δεδοµένα από τους χειριστές προς το σύστηµα και αντίστροφα).

3. Μια ειδική περίπτωση χειριστή είναι τα ωρολόγια του συστήµατος. Συνήθως όλες οι ενέργειες που εκτελούνται από ένα σύστηµα ξεκινούν µετά από απαίτηση ενός χειριστή. Εξαίρεση σε αυτό είναι οι προγραµµατισµένες λειτουργίες του συστήµατος οι οποίες ξεκινούν αυτόµατα από ένας χειριστή τύπου ωρολόγιο.

Στο παράδειγµά µας του ηλεκτρονικού ανθοπωλείου έχουµε εντοπίσει τους παρακάτω χειριστές:

1. ο πελάτης

2. ο ανώνυµος πελάτης, είναι ένας πελάτης που δεν έχει ακόµα ταυτοποιηθεί από το σύστηµα. Το όνοµα του χειριστή αυτού φαίνεται λίγο παράξενο αλλά οι χειριστές αναπαριστούν και τους ρόλους του συστήµατος. Συνεπώς, ο ανώνυµος πελάτης είναι ο πελάτης που απλά δεν έχει καταχωρήσει ακόµη τα στοιχεία του ή κοιτάξει τα προϊόντα που προσφέρει το ανθοπωλείο «Λευκός Κρίνος».

3. ο καταχωρηµένος πελάτης, ο οποίος έχει καταχωρήσει τα στοιχεία του στο σύστηµα και το σύστηµα γνωρίζει την ταυτότητά του

4. ο διαχειριστής, είναι ο εργαζόµενος στην εταιρεία που διατηρεί το ηλεκτρονικό ανθοπωλείο και

5. το σύστηµα έγκρισης πιστωτικών καρτών είναι ένας χειριστής που δρα ως πληρεξούσιο του εξωτερικού συστήµατος έγκρισης πιστωτικών καρτών

Οι χειριστές «πελάτης» µε τους χειριστές «καταχωρηµένος πελάτης» και «ανώνυµος πελάτης» συνδέονται µε σχέση γενίκευσης. Η σχέση γενίκευσης χρησιµοποιείται µεταξύ χειριστών όταν αυτοί µοιράζονται κοινές χρήσεις και κοινή συµπεριφορά.

Στην Εικόνα 9 παρουσιάζονται οι χειριστές του συστήµατος ηλεκτρονικού ανθοπωλείου.

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

33 ΠΛΗ24 – Σχεδιασµός Λογισµικού

Εικόνα 9: Οι χειριστές του συστήµατος ηλεκτρονικού ανθοπωλείου

5.2.2 Προσδιορισµός των περιπτώσεων χρήσης (use cases)

Μετά την εύρεση και την ταξινόµηση των συµµετεχόντων και τον προσδιορισµό των χειριστών θα πρέπει να δείξουµε τον τρόπο µε τον οποίο οι χειριστές χρησιµοποιούν το σύστηµα. Κάθε διακριτή χρήση του συστήµατος καλείται περίπτωση χρήσης. Κάθε περίπτωση χρήσης πάντα ξεκινάει από κάποιο χειριστή, είτε είναι χρήστης, συσκευή, ρολόι, είτε άλλο σύστηµα.

Για την εύρεση των περιπτώσεων χρήσης πρέπει να σκεφτούµε τους στόχους/απαιτήσεις του κάθε χρήστη από το σύστηµα. Για κάθε έναν από τους διακριτούς στόχους θα πρέπει να καθορίσουµε πώς το σύστηµά βοηθά το χρήστη να τους εκπληρώσει.

Επιπλέον, όλες οι αλληλεπιδράσεις µεταξύ του συστήµατος και των χειριστών είναι τµήµα κάποιας περίπτωσης χρήσης. Για κάθε αλληλεπίδραση πρέπει να εξετάσουµε τους στόχους του χειριστή που ξεκινά αυτή την αλληλεπίδραση. Ο χειριστής αυτός ονοµάζεται από πολλούς ως βασικός χειριστής (primary actor). Σε περίπτωση που για την ολοκλήρωση της περίπτωσης χρήσης συµµετέχουν και άλλοι χειριστές αυτοί χαρακτηρίζονται ως δευτερεύοντες (secondary). Πολλοί συχνά οι χειριστές που είναι βασικοί σε κάποιες περιπτώσεις χρήσης είναι δευτερεύοντες σε κάποιες άλλες.

Μερικοί βοηθητικοί κανόνες για το σωστό ορισµό των περιπτώσεων χρήσης είναι οι ακόλουθοι:

• Το όνοµα της περίπτωσης χρήσης δείχνει ενέργεια. Η περίπτωση χρήσης περιγράφει µια συµπεριφορά του συστήµατος και συνεπώς το όνοµα της θα πρέπει να δείχνει ενέργεια (ρήµα ή ουσιαστικό που δείχνει ενέργεια).

• Η περίπτωση χρήσης πρέπει να περιγράφει µια πλήρη συµπεριφορά που αρχίζει µε το γεγονός έναρξης από τον αρχικό χειριστή και τελειώνει µε

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

34 ΠΛΗ24 – Σχεδιασµός Λογισµικού

την επιτυχηµένη επίτευξη του σκοπού. Εάν η προτεινόµενη περίπτωση χρήσης είναι µόνο ένα βήµα για την επίτευξη του στόχου του χειριστή, τότε η προτεινόµενη περίπτωση δε θα πρέπει να θεωρηθεί ως περίπτωση χρήσης. Παραδείγµατος χάριν, η επιλογή ενός λουλουδιού είναι ένα βήµα για τη δηµιουργία µιας ανθοδέσµης και δε µπορεί να σταθεί από µόνη της ως ξεχωριστή περίπτωση χρήσης.

• Η περίπτωση χρήσης θα πρέπει να µπορεί να ολοκληρωθεί. Για να επιτευχθεί ο σκοπός της περίπτωσης χρήσης και να παραχθεί κάποιο αποτέλεσµα για το χειριστή του συστήµατος θα πρέπει να υπάρχει δυνατότητα ολοκλήρωσης της περίπτωσης χρήσης. Αυτό σηµαίνει ότι υπάρχει ροή που επιτρέπει την ολοκλήρωση της επιθυµητής συµπεριφοράς. Η ροή αυτή χαρακτηρίζεται ως το «χαρούµενο µονοπάτι» (happy path).

• Αντίστροφη περίπτωση χρήσης. Όταν υπάρχει περίπτωση χρήσης που επιτυγχάνει ένα διακριτό αποτέλεσµα συνήθως θα πρέπει να υπάρχει και η αντίστροφη περίπτωση χρήσης που ακυρώνει αυτό το αποτέλεσµα. Για παράδειγµα η περίπτωση χρήσης «Παραγγελία Ανθοδέσµης» καλό είναι να συνοδεύεται από την αντίστροφή της η οποία είναι «Ακύρωση Παραγγελίας».

• Μια περίπτωση χρήσης – µια συµπεριφορά. Περιορίστε την περίπτωση χρήσης έτσι ώστε να περιγράφει µόνο µια περίπτωση χρήσης. Είναι πολύ συνηθισµένο να έχουµε γενικές περιπτώσεις χρήσεις που περιγράφουν περισσότερες συµπεριφορές. Η λύση στο πρόβληµα αυτό είναι να εισάγουµε περιπτώσεις χρήσης που περιγράφουν µια γενική συµπεριφορά και στη συνέχεια να αναλύσουµε τη γενική περίπτωση χρήσης σε υποπεριπτώσεις.

• Χρησιµοποιείστε την ορολογία του πεδίου προβλήµατος. Με τον τρόπο αυτό οι χρήστες και οι συµµετέχοντες στην ανάπτυξη του συστήµατος µπορούν να συµµετάσχουν στην αξιολόγηση των περιπτώσεων χρήσης.

Το µοντέλο των περιπτώσεων χρήσης του συστήµατος στη γενική περίπτωση είναι επίπεδο. Η περιγραφή ωστόσο όλων των περιπτώσεων χρήσης στο ίδιο επίπεδο ενδέχεται να δηµιουργήσει σηµαντικά προβλήµατα ειδικά αν το υπ’ ανάπτυξη σύστηµα είναι µεγάλο. Αυτό σηµαίνει ότι όλες οι περιπτώσεις χρήσης περιγράφονται στο ίδιο επίπεδο και ότι αν κάποιος θα ήθελε να δει τη συνολική εικόνα του συστήµατος θα είχε σηµαντικό πρόβληµα ειδικά αν το σύστηµα υπό ανάπτυξη είναι µεγάλο. Για την επίλυση αυτού του προβλήµατος είναι δυνατόν να εισάγουµε επίπεδα στη δηµιουργία του µοντέλου των περιπτώσεων χρήσης. Στο γενικό επίπεδο του έργου προσδιορίζουµε τους βασικούς στόχους του συστήµατος (system context) και στη συνέχεια προχωρούµε στο πιο αναλυτικό επίπεδο όπου περιγράφονται οι στόχοι των χρηστών (user goals) µε πιο ειδικές περιπτώσεις χρήσης. Το τελευταίο επίπεδο είναι αυτό των διακριτών λειτουργιών στο οποίο µας επιτρέπει να περιγράψουµε συµπεριφορές πολύ χαµηλού επιπέδου (function level). Η τεχνική της ιεραρχικής παρουσίασης των περιπτώσεων χρήσης σε συνδυασµό µε τα πακέτα περιπτώσεων χρήσης µας επιτρέπει τον καλό χειρισµό

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

35 ΠΛΗ24 – Σχεδιασµός Λογισµικού

της πολυπλοκότητας. Η πολυπλοκότητα είναι ένα από τα βασικά προβλήµατα στην ανάπτυξη πληροφοριακών συστηµάτων.

Στην Εικόνα 10 παρουσιάζονται σχηµατικά τα τρία αυτά επίπεδα χρησιµοποιώντας την αρχική λίστα των περιπτώσεων χρήσης που παρουσιάσθηκε στην Εικόνα 8.

Σύστηµα

∆ιαχείριση πελατών ∆ιαχείριση προϊόντων Πωλήσεις Βασικοί στόχοι

Στόχοι χειριστών

∆ιακριτές λειτουργίες

∆ηµιουργία λογαριασµούπελάτη

Σύνδεση µε το σύστηµα(log in)

∆ηµιουργία ανθοδέσµης

Επιλογή Λουλουδιών

Επιλογή Ανθοδέσµης

Προβολή Στοιχείων Λουλουδιών/Ανθοδέσµης

∆ιαχείριση«Ηλεκτρονικού Καροτσιού»

∆ιαχείριση Παραλήπτη-Μηνύµατος

Πληρωµή Παραγγελίας

∆ιαχείριση Επετείων

∆ιαχείριση Προτιµήσεων Πελάτη

Σύστηµα

∆ιαχείριση πελατών ∆ιαχείριση προϊόντων Πωλήσεις Βασικοί στόχοι

Στόχοι χειριστών

∆ιακριτές λειτουργίες

∆ηµιουργία λογαριασµούπελάτη

Σύνδεση µε το σύστηµα(log in)

∆ηµιουργία ανθοδέσµης

Επιλογή Λουλουδιών

Επιλογή Ανθοδέσµης

Προβολή Στοιχείων Λουλουδιών/Ανθοδέσµης

∆ιαχείριση«Ηλεκτρονικού Καροτσιού»

∆ιαχείριση Παραλήπτη-Μηνύµατος

Πληρωµή Παραγγελίας

∆ιαχείριση Επετείων

∆ιαχείριση Προτιµήσεων Πελάτη

Εικόνα 10: Τα επίπεδα των περιπτώσεων χρήσης

Το επόµενο βήµα είναι να παρουσιάσουµε µε γραφικό τρόπο τις περιπτώσεις χρήσης για τον κάθε ένα από τους χειριστές του συστήµατος.

Ο χειριστής «πελάτης του συστήµατος» µπορεί να έχει δύο τύπους: είτε να είναι «Ανώνυµος Πελάτης» είτε «Καταχωρηµένος Πελάτης».

Ένας «Ανώνυµος Πελάτης» µπορεί:

• να δηµιουργήσει καινούργιο λογαριασµό και να καταχωρήσει τα στοιχεία του στο σύστηµα γεγονός που αντιστοιχεί στην περίπτωση χρήσης «∆ηµιουργία Λογαριασµού Πελάτη»

• να δει τα προϊόντα του ανθοπωλείου γεγονός που αντιστοιχεί στην περίπτωση χρήσης «Προβολή Στοιχείων Λουλουδιών/Ανθοδέσµης»

• να συνδέεται µε το σύστηµα χρησιµοποιώντας την περίπτωση χρήσης «Log-In»

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

36 ΠΛΗ24 – Σχεδιασµός Λογισµικού

Εικόνα 11: Οι περιπτώσεις χρήσης για το χειριστή «Ανώνυµο πελάτη»

Αντίστοιχα, ο χειριστής «Καταχωρηµένος Πελάτης» µπορεί:

• να διαχειρίζεται τις επετείους των φίλων του µε την περίπτωση χρήσης «∆ιαχείριση Επετείων»

• να δηµιουργεί καινούργιου τύπου ανθοδέσµες µε την περίπτωση χρήσης «∆ηµιουργία Ανθοδέσµης». Η περίπτωση χρήσης «∆ηµιουργία Ανθοδέσµης» περιλαµβάνει (include) την περίπτωση χρήσης «Επιλογή Λουλουδιών»

• να επιλέγει ανθοδέσµες από λίστα των υπαρχόντων ανθοσυνθέσεων µε την περίπτωση χρήσης «Επιλογή Ανθοδέσµης». Παρατηρούµε ότι η περίπτωση χρήσης «Επιλογή Ανθοδέσµης» περιλαµβάνει (includes) την περίπτωση χρήσης «Προβολή Στοιχείων Λουλουδιών/Ανθοδέσµης» η οποία είναι κοινή και για την περίπτωση χρήσης «∆ηµιουργία Ανθοδέσµης». Η σχέση include, η οποία συµβολίζεται µε διακεκοµµένο βέλος χρησιµοποιείται για να περιγράψει συµπεριφορές οι οποίες είναι διακριτές αλλά όχι αυθύπαρκτες. Επιπλέον η σχέση include είναι ιδιαιτέρως χρήσιµη στις περιπτώσεις που µια συµπεριφορά επαναλαµβάνεται µε τον ίδιο τρόπο πολλές φορές.

• Να διαχειρίζεται τις παραγγελίες του µε την περίπτωση χρήσης «∆ιαχείριση Παραγγελίας» η οποία περιλαµβάνει την περίπτωση χρήσης «∆ιαχείριση Στοιχείων παραλήπτη/µηνύµατος».

• Να επιλέγει περισσότερες της µια ανθοδέσµες τις οποίες τοποθετεί στο ηλεκτρονικό καρότσι. Παρατηρούµε ότι η αρχική περίπτωση χρήσης «∆ιαχείριση ηλεκτρονικού καροτσιού» επεκτείνεται-αναλύεται περισσότερο µε τη χρήση της σχέσης περιλαµβάνει µε την προσθήκη των περιπτώσεων χρήσης:

o Προβολή Επιλεγµένων Ανθοδεσµών

o Προσθήκη Ανθοδέσµης

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

37 ΠΛΗ24 – Σχεδιασµός Λογισµικού

o ∆ιαγραφή Ανθοδέσµης

• Τέλος ο χειριστής «Καταχωρηµένος Χρήστης» µπορεί να πληρώνει το λογαριασµό του µε την πιστωτική του κάρτα στην περίπτωση χρήσης «Πληρωµή Λογαριασµού».

Η περίπτωση χρήσης «∆ιαχείριση Επετείων» θα µπορούσε να αναλυθεί µε τον ίδιο τρόπο (σχέση include) που αναλύθηκε και η περίπτωση χρήσης «∆ιαχείριση ηλεκτρονικού καροτσιού», ώστε να περιλαµβάνει τις υποπεριπτώσεις:

• ∆ηµιουργία Επετείου

• ∆ιαγραφή Επετείου

• Προβολή Επετείων

• Αποστολή µηνύµατος για Επέτειο

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

Εικόνα 12: Οι περιπτώσεις χρήσης για το χειριστή «Καταχωρηµένος πελάτης»

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

38 ΠΛΗ24 – Σχεδιασµός Λογισµικού

Εικόνα 13: Η ανάλυση της περίπτωσης χρήσης «∆ιαχείριση Επετείων» σε υπο-περιπτώσεις.

Για το χειριστή «διαχειριστής του συστήµατος» δεν περιγράφονται στο αρχικό κείµενο περιγραφής του συστήµατος συγκεκριµένες απαιτήσεις. Για το λόγο αυτό προσδιορίζουµε σε ένα βαθµό βάση της εµπειρίας και σε ένα βαθµό αυθαίρετα ότι οι περιπτώσεις χρήσης του χειριστή είναι οι ακόλουθες:

• Να συνδέεται µε το σύστηµα µε την περίπτωση χρήσης «Log-In»

• ∆ιαχείριση πελατών που περιλαµβάνουν τις υποπεριπτώσεις

o ∆ηµιουργία λογαριασµού πελάτη

o Τροποποίηση στοιχείων πελάτη

o Προβολή λίστας πελατών

o Προβολή στοιχείων πελάτη

• ∆ιαχείριση προϊόντων

o ∆ηµιουργία Ανθοδέσµης

o ∆ηµιουργία Λουλουδιού

o Προβολή Καταλόγου

o Προβολή Στοιχείων Λουλουδιών/Ανθοδέσµης

o Τροποποίηση Στοιχείων Λουλουδιών

o Τροποποίηση Στοιχείων Ανθοδέσµης

o ∆ιαγραφή Ανθοδέσµης

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

39 ΠΛΗ24 – Σχεδιασµός Λογισµικού

o ∆ιαγραφή Λουλουδιού

Είναι προφανές ότι µε τον προσδιορισµό των περιπτώσεων χρήσης για το διαχειριστή του συστήµατος θα πρέπει στην επόµενη επανάληψη της φάσεως της καταγραφής των απαιτήσεων να τροποποιηθεί το µοντέλο του πεδίου προβλήµατος και η λίστα των περιπτώσεων χρήσης (scope map).

Εικόνα 14: Οι περιπτώσεις χρήσης για το χειριστή «∆ιαχειριστή Συστήµατος»

Η Εικόνα 15 παρουσιάζει το διάγραµµα των περιπτώσεων χρήσης του συστήµατος όπου οι περιπτώσεις χρήσης έχουν οµαδοποιηθεί σε πακέτα. Στο γενικό αυτό διάγραµµα οι περιπτώσεις χρήσης οµαδοποιήθηκαν σε τρία πακέτα:

• Το πακέτο περιπτώσεων χρήσης του «Ηλεκτρονικού Καροτσιού»,

• Το πακέτο περιπτώσεων χρήσης για τη «∆ιαχείριση Πελατών» και

• Το πακέτο περιπτώσεων χρήσης για τη «∆ιαχείριση προϊόντων»

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

40 ΠΛΗ24 – Σχεδιασµός Λογισµικού

Εικόνα 15: Το συνολικό διάγραµµα περιπτώσεων χρήσης του συστήµατος.

5.2.3 Αναλυτική περιγραφή των περιπτώσεων χρήσης

Η αναλυτική περιγραφή των περιπτώσεων χρήσης απαιτεί σηµαντική προσπάθεια από την οµάδα ανάπτυξης του συστήµατος. Τόσο ο τρόπος περιγραφής των περιπτώσεων χρήσης (χρησιµοποιούµενο πρότυπο) όσο η λεπτοµέρεια περιγραφής µπορεί να διαφέρει ανάλογα µε την περίσταση. Συνήθως η λεπτοµέρεια περιγραφής εξαρτάται από τη φάση στην οποία βρίσκεται το έργο. Εάν αρχίσουµε να περιγράφουµε τις περιπτώσεις χρήσης λεπτοµερώς από την αρχή του έργου, δε θα µπορέσουµε να καλύψουµε όλο το εύρος του πεδίου προβλήµατος µε αποτέλεσµα οι συµµετέχοντες να µην έχουν τη δυνατότητα να σχολιάσουν τις αρχικές ιδέες. Επιπλέον, εάν οι αρχικές ιδέες είναι λανθασµένες θα χάσουµε µα την ανάλυσή τους πολύτιµο χρόνο. Για το λόγο αυτό είναι πολύ καλύτερα να ορίσουµε, αρκετά νωρίς το πλαίσιο εργασίας του συστήµατος και στη συνέχεια να προχωρήσουµε στην καταγραφή των λεπτοµερειών.

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

41 ΠΛΗ24 – Σχεδιασµός Λογισµικού

Συνήθως, η περιγραφή των περιπτώσεων χρήσης γίνεται σε βήµατα, κάθε ένα εκ των οποίων έχει διακριτούς στόχους. Έτσι µετά την απαρίθµηση των χειριστών και των στόχων τους από το σύστηµα χρειάζεται να περιγράψουµε τα ακόλουθα µε τη σειρά που αναφέρονται:

• τη βασική ροή για την κάθε περίπτωση χρήσης.

• τις συνθήκες αποτυχίας (failure conditions). Προσπαθούµε να βρούµε όλους τους τρόπους µε τους οποίους µπορεί η περίπτωση χρήσης να αποτύχει. Αποτυχία για µια περίπτωση χρήσης σηµαίνει ότι ο χειριστής δεν µπόρεσε να επιτύχει το σκοπό του.

• Τον τρόπο αντιµετώπισης των αποτυχιών (failure handling). Για κάθε περίπτωση αποτυχίας προσπαθούµε να περιγράψουµε το πως το σύστηµα θα συµπεριφερθεί. Στο βήµα αυτό ερχόµαστε πολύ συχνά µε επιχειρηµατικούς κανόνες (business rules) για το τι τελικά πρέπει να γίνει.

Λόγω του µεγάλου αριθµού διαφορετικών περιπτώσεων αποτυχίας (failure cases- error cases) που συνήθως υπάρχουν σε ένα σύστηµα (όσες περισσότερες περιπτώσεις εντοπίζουµε τόσο πιο σταθερό – robust θα είναι το υπό ανάπτυξη σύστηµα) πρέπει πρώτα να απαριθµούµε τις περιπτώσεις αποτυχίας και στη συνέχεια να τις περιγράφουµε. Σε αντίθετη περίπτωση είναι σχεδόν βέβαιο ότι λόγω ελλείψεως χρόνου δε θα προλάβουµε να καλύψουµε όλες τις περιπτώσεις χρήσης.

Ένα ακόµη σηµείο το οποίο θα πρέπει να λάβουµε σοβαρά υπόψη µας είναι η διαφορετική προτεραιότητα-σηµασία που έχουν οι περιπτώσεις χρήσης για τους χειριστές του συστήµατος. Για το λόγο αυτό ξεκινάµε πάντα την περιγραφή από αυτές τις περιπτώσεις χρήσης που ο χειριστής θεωρεί βασικές-κρίσιµες για την εκπλήρωση του στόχου του-εργασίας του. ∆ε θα πρέπει να ξεχνάµε τον εµπειρικό κανόνα 20-80, ο οποίος περιγράφει ότι το 20% της λειτουργικότητας απορροφά το 80% του διαθέσιµου χρόνου.

Στη διεθνή βιβλιογραφία υπάρχουν διάφορα πρότυπα για τη συγγραφή περιπτώσεων χρήσης. Για λόγους πληρότητας παραθέτουµε δύο από τα πιο διαδεδοµένα στη διεθνή βιβλιογραφία.

Περίπτωση Χρήσης #

<ο σκοπός της περίπτωσης χρήσης σε µια πρόταση>

Πλαίσιο εφαρµογής <πότε εφαρµόζεται η περίπτωση χρήσης – προαιρετικά>

Επίπεδο <Ένα από τα: υψηλού επιπέδου, Βασική διαδικασία, Χαµηλού επιπέδου>

Βασικός χειριστής <Το όνοµα του βασικού χειριστή>

Συµµετέχοντες & Συµφέρον που έχουν από την

Συµµετέχων Συµφέρον

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

42 ΠΛΗ24 – Σχεδιασµός Λογισµικού

περίπτωση χρήσης

<Όνοµα συµµετέχοντα> <περιγραφή γιατί ο συµµετέχων χρειάζεται την περίπτωση χρήσης>

<Όνοµα συµµετέχοντα> <περιγραφή γιατί ο συµµετέχων χρειάζεται την περίπτωση χρήσης>

Κατάσταση εισόδου

(preconditions)

<Οι συνθήκες που πρέπει να προϋπάρχουν>

Ελάχιστη λειτουργία <Η περίπτωση χρήσης εγγυάται ότι τουλάχιστον θα εκπληρωθεί ένα ελάχιστο τµήµα του αρχικού στόχου>

Κανονική λειτουργία

<Η περίπτωση χρήσης στην κανονική της λειτουργία επιτυγχάνει ...>

Γεγονός έναρξης <Το γεγονός που σηµατοδοτεί την έναρξη της περίπτωσης χρήσης>

ΠΕΡΙΓΡΑΦΗ ΒΗΜΑ ΕΝΕΡΓΕΙΑ

1 <Οι ενέργειες που εκτελούνται>

2 <Οι ενέργειες που εκτελούνται>

3 <Οι ενέργειες που εκτελούνται>

ΕΠΕΚΤΑΣΕΙΣ ΒΗΜΑ ΕΝΑΛΛΑΚΤΙΚΗ ΕΝΕΡΓΕΙΑ

1α <Οι εναλλακτικές ενέργειες που εκτελούνται>

1β <Οι εναλλακτικές ενέργειες που εκτελούνται>

ΤΕΧΝΟΛΟΓΙΑ & ΠΑΡΑΛΛΑΓΕΣ ∆Ε∆ΟΜΕΝΩΝ

ΒΗΜΑ <Λίστα παραλλαγών>

Εικόνα 16: Πρότυπο περιγραφής περίπτωσης χρήσης σε µορφή πίνακα.

Το πρότυπο το οποίο προτείνεται από την ενοποιηµένη προσέγγιση είναι το ακόλουθο:

1. Τίτλος περίπτωσης χρήσης : ……

1.1. Σύντοµη περιγραφή: ……

1.2. Χειριστές: ……

1.3. Γεγονός έναρξης: ……

2. Ροή γεγονότων.

2.1 Βασική ροή

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

43 ΠΛΗ24 – Σχεδιασµός Λογισµικού

……

2.2 Εναλλακτικές ροές

2.2.1 Εναλλακτική ροή 1

……

2.2.2 Εναλλακτική ροή 2

……

3. Ειδικές απαιτήσεις

3.1 Μη λειτουργικές απαιτήσεις: ……

3.2 Περιβάλλον: ……

4. Κατάσταση εισόδου (preconditions): ……

5. Κατάσταση εξόδου (postconditions): ……

6. Σηµεία επέκτασης: ……

Εικόνα 17: Πρότυπο περιγραφής περίπτωσης χρήσης UP.

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

• ∆ηµιουργία Ανθοδέσµης

• ∆ηµιουργία Λογαριασµού Πελάτη

• Τροποποίηση Στοιχείων Πελάτη

• Log-in

1. Τίτλος περίπτωσης χρήσης: ∆ηµιουργία Ανθοδέσµης

1.1. Σύντοµη περιγραφή

Η εφαρµογή εµφανίζει µία φόρµα διαλόγου µέσω της οποίας ο πελάτης επιλέγει τα λουλούδια που επιθυµεί για τη δηµιουργία µιας ανθοδέσµης.

1.2. Χειριστές: ∆ιαχειριστής Συστήµατος, Καταχωρηµένος Πελάτης

2. Ροή γεγονότων.

2.1 Βασική ροή

1. Ο πελάτης επιλέγει από το βασικό µενού της εφαρµογής «∆ηµιουργία Ανθοδέσµης».

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

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

44 ΠΛΗ24 – Σχεδιασµός Λογισµικού

3. Ο πελάτης επιλέγει «Εισαγωγή Στοιχείων Παραλήπτη»

4. Η εφαρµογή ελέγχει την εγκυρότητα των στοιχείων.

5. Η εφαρµογή εισάγει µια νέα εγγραφή στο αρχείο µε τα στοιχεία των Παραληπτών συνδεδεµένη µε τον κωδικό του συγκεκριµένου Πελάτη.

6. Ο πελάτης επιλέγει «Εισαγωγή Μηνύµατος για τον Παραλήπτη»

7. Ο πελάτης επιλέγει «Προσθήκη στο Ηλεκτρονικό Καρότσι»

2.2 Εναλλακτικές ροές

2.2.1 Εναλλακτική ροή 1

4α. Η εφαρµογή εµφανίζει µήνυµα για ελλιπή στοιχεία παραλήπτη.

4β. Η εφαρµογή επιστρέφει στο βήµα 3.

2.2.2 Εναλλακτική ροή 2

7α. Ο πελάτης πατά το κουµπί για ακύρωση της σύνθεσης και η εφαρµογή επιστρέφει στο βήµα 1.

2.2.3 Εναλλακτική ροή 3

2α. Το σύστηµα ελέγχει αν ο αριθµός των ζητούµενων λουλουδιών είναι µικρότερος από τα διαθέσιµα.

2β. Το σύστηµα εµφανίζει µήνυµα λάθους

3. Μη λειτουργικές απαιτήσεις

Ο χρόνος καταχώρισης της παραγγελίας στο «Ηλεκτρονικό Καρότσι δεν πρέπει να ξεπερνά τα 3 δευτερόλεπτα.

4. Κατάσταση εισόδου

Θα πρέπει να υπάρχουν τα αρχεία Πελατών, Παραληπτών και Λουλουδιών και το «Ηλεκτρονικό Καρότσι».

5. Κατάσταση εξόδου

Έχουν ενηµερωθεί 0-Ν εγγραφές στα αρχεία «Ηλεκτρονικό Καρότσι», Παραληπτών και Λουλουδιών.

Εικόνα 18: Περιγραφή της περίπτωσης χρήσης «∆ηµιουργία Ανθοδέσµης»

1. Τίτλος περίπτωσης χρήσης: ∆ηµιουργία Λογαριασµού Πελάτη

1.1. Σύντοµη περιγραφή

Η περίπτωση χρήσης «∆ηµιουργία Λογαριασµού Πελάτη» επιτρέπει στο χειριστή να δηµιουργήσει ένα καινούργιο Πελάτη και να καταχωρήσει τις απαραίτητες πληροφορίες και προτιµήσεις του χρήστη.

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

45 ΠΛΗ24 – Σχεδιασµός Λογισµικού

Όταν δηµιουργείται ένα καινούργιος πελάτης γίνεται ταυτόχρονα login στο σύστηµα και αλλάζει η κατάστασή του από «ανώνυµος πελάτης» σε «καταχωρηµένος πελάτης».

1.2. Χειριστές: ∆ιαχειριστής Συστήµατος, Ανώνυµος Πελάτης

2. Ροή γεγονότων.

2.1 Βασική ροή

Αυτή η περίπτωση χρήσης αρχίζει όταν ο χρήστης επιλέξει τη λειτουργία «∆ηµιουργία Λογαριασµού Πελάτη».

1. Το σύστηµα παρουσιάζει τη φόρµα µε τις απαιτούµενες πληροφορίες που πρέπει να εισαχθούν για τον πελάτη.

2. Ο χρήστης εισάγει τις απαραίτητες πληροφορίες που ζητά το σύστηµα και ζητά από το σύστηµα να επικυρώσει τα στοιχεία του πελάτη.

3. Το σύστηµα επικυρώνει τις πληροφορίες καθώς επίσης την πιστωτική κάρτα µε την υποβολή ενός αιτήµατος επικύρωσης πιστωτικής κάρτας στο σύστηµα έγκρισης πιστωτικών καρτών.

4. Το σύστηµα παρουσιάζει τα στοιχεία που έχουν εισαχθεί και ζητά από το χρήστη να επιβεβαιώσει ότι ο λογαριασµός πρέπει να δηµιουργηθεί µε τις τιµές των µεταβλητών που παρουσιάζονται.

5. Ο χρήστης επιβεβαιώνει ότι ο λογαριασµός πρέπει να δηµιουργηθεί. Ταυτόχρονα µε τη δηµιουργία του λογαριασµού γίνεται η ενεργοποίησή του. Ενεργοποίηση σηµαίνει ότι η κατάσταση του χρήστη αλλάζει από ανώνυµος πελάτης σε καταχωρηµένος πελάτης.

6. Τέλος το σύστηµα επιτρέπει την πρόσβαση του χρήστη στις επιλογές των καταχωρηµένων χρηστών (κάνει log-in).

Η περίπτωση χρήσης τελειώνει.

2.2 Εναλλακτικές ροές

2.2.1 Εναλλακτική ροή 1 - «Ακύρωση της ∆ηµιουργίας Λογαριασµού»

Σε οποιοδήποτε σηµείο της περίπτωσης χρήσης ο χρήστης µπορεί να ακυρώσει τη δηµιουργία λογαριασµού. Το αποτέλεσµα είναι ότι δεν δηµιουργείται λογαριασµός.

2.2.2 Εναλλακτική ροή 2 – «Ο χρήστης εισάγει λανθασµένη πληροφορία»

Το σύστηµα αναγνώρισε ότι ο χρήστης έχει εισάγει λανθασµένη-άκυρη πληροφορία

3α. Το σύστηµα παρουσιάζει στο χρήστη το σχετικό µήνυµα λάθους µαζί µε τη λανθασµένη πληροφορία

3β. Το σύστηµα προτρέπει το χρήστη να επανεισάγει την πληροφορία

3γ. Ο χρήστης εισάγει εκ νέου την πληροφορία που ζητά το σύστηµα

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

46 ΠΛΗ24 – Σχεδιασµός Λογισµικού

3δ. Το σύστηµα ελέγχει ξανά κατά πόσο η πληροφορία που εισήχθη είναι σωστή.

3ε. Εάν η πληροφορία είναι σωστή το σύστηµα συνεχίζει µε το βήµα 4 της κανονικής ροής δεδοµένων.

3στ. Εάν η πληροφορία που εισήχθη δεν είναι σωστή το σύστηµα επανέρχεται στο βήµα 3α της εναλλακτικής ροής 2.

Λανθασµένη πληροφορία για τη δηµιουργία λογαριασµού πελάτη µπορεί να είναι:

- ∆εν έχει εισαχθεί πληροφορία σε κάποιο πεδίο

- Το όνοµα πελάτη υπάρχει ήδη στο σύστηµα

- Το username υπάρχει ήδη στο σύστηµα

- Ο τρόπος γραφής του ταχυδροµικού κώδικα δεν είναι σωστός

- Ο τρόπος γραφής του e-mail είναι λανθασµένος

- Ο αριθµός πιστωτικής κάρτας είναι λανθασµένος

- Η πιστωτική κάρτα έχει λήξει

- Το όνοµα που αναγράφεται πάνω στην πιστωτική κάρτα ανήκει σε άλλο πρόσωπο

3. Μη λειτουργικές απαιτήσεις

Ο χρόνος επικοινωνίας µε το εξωτερικό σύστηµα έγκρισης χρήσης πιστωτικών καρτών δεν πρέπει να ξεπερνά τα 5 δευτερόλεπτα.

4. Κατάσταση εισόδου

∆εν υπάρχουν

5. Κατάσταση εξόδου

1. Ο λογαριασµός πελάτη δηµιουργήθηκε επιτυχηµένα, ο λογαριασµός έχει ενεργοποιηθεί και ο πελάτης χρησιµοποιεί το σύστηµα

2. Ο λογαριασµός δε δηµιουργήθηκε είτε γιατί ο χρήστης απέτυχε να εισάγει τη σωστή πληροφορία είτε γιατί ακύρωσε τη διαδικασία δηµιουργίας λογαριασµού.

Εικόνα 19: Περιγραφή της περίπτωσης χρήσης «∆ηµιουργία Λογαριασµού Πελάτη»

1. Τίτλος περίπτωσης χρήσης: Τροποποίηση Στοιχείων Πελάτη

1.1. Σύντοµη περιγραφή

Η περίπτωση χρήσης «Τροποποίηση Στοιχείων Πελάτη» επιτρέπει στο χειριστή να τροποποιήσει την πληροφορία που το σύστηµα διατηρεί για ένα Πελάτη.

1.2. Χειριστές: Καταχωρηµένος Πελάτης

2. Ροή γεγονότων.

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

47 ΠΛΗ24 – Σχεδιασµός Λογισµικού

2.1 Βασική ροή

Αυτή η περίπτωση χρήσης αρχίζει όταν ο πελάτης επιλέξει τη λειτουργία «Τροποποίηση Στοιχείων Πελάτη».

1. Το σύστηµα παρουσιάζει τις πληροφορίες που ήδη υπάρχουν αποθηκευµένες για το συγκεκριµένο πελάτη.

2. Ο χρήστης εισάγει τις νέες πληροφορίες και ζητά από το σύστηµα να αποθηκεύσει τις νέες πληροφορίες.

3. Το σύστηµα επικυρώνει τις πληροφορίες καθώς και την πιστωτική κάρτα µε την υποβολή ενός αιτήµατος επικύρωσης πιστωτικής κάρτας στο σύστηµα έγκρισης πιστωτικών καρτών.

4. Το σύστηµα παρουσιάζει τα νέα στοιχεία που έχουν εισαχθεί και ζητά από το χρήστη να επιβεβαιώσει ότι οι τιµές των µεταβλητών που παρουσιάζονται είναι σωστές.

5. Ο χρήστης επιβεβαιώνει ότι ο λογαριασµός πρέπει να τροποποιηθεί µε τις υπάρχουσες πληροφορίες.

6. Το σύστηµα αποθηκεύει τις πληροφορίες και ενηµερώνει τον πελάτη ότι ο λογαριασµός έχει τροποποιηθεί.

Η περίπτωση χρήσης τελειώνει.

2.2 Εναλλακτικές ροές

2.2.1 Εναλλακτική ροή 1 - «Ακύρωση της Τροποποίησης Λογαριασµού»

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

2.2.2 Εναλλακτική ροή 2 – «Ο χρήστης εισάγει λανθασµένη πληροφορία»

Το σύστηµα αναγνώρισε ότι ο χρήστης έχει εισάγει λανθασµένη-άκυρη πληροφορία

3α. Το σύστηµα παρουσιάζει στο χρήστη το σχετικό µήνυµα λάθους µαζί µε τη λανθασµένη πληροφορία

3β. Το σύστηµα προτρέπει το χρήστη να επανεισάγει την πληροφορία

3γ. Ο χρήστης εισάγει εκ νέου την πληροφορία που ζητά το σύστηµα

3δ. Το σύστηµα ελέγχει ξανά κατά πόσο η πληροφορία που εισήχθη είναι σωστή.

3ε. Εάν η πληροφορία είναι σωστή το σύστηµα συνεχίζει µε το βήµα 4 της κανονικής ροής δεδοµένων.

3στ. Εάν η πληροφορία που εισήχθη δεν είναι σωστή το σύστηµα επανέρχεται στο βήµα 3α της εναλλακτικής ροής 2.

Λανθασµένη πληροφορία για τη δηµιουργία λογαριασµού πελάτη µπορεί να είναι:

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

48 ΠΛΗ24 – Σχεδιασµός Λογισµικού

- ∆εν έχει εισαχθεί πληροφορία σε κάποιο πεδίο

- Το όνοµα πελάτη υπάρχει ήδη στο σύστηµα

- Το username υπάρχει ήδη στο σύστηµα

- Ο τρόπος γραφής του ταχυδροµικού κώδικα δεν είναι σωστός

- Ο τρόπος γραφής του e-mail είναι λανθασµένος

- Ο αριθµός πιστωτικής κάρτας είναι λανθασµένος

- Η πιστωτική κάρτα έχει λήξει

- Το όνοµα που αναγράφεται πάνω στην πιστωτική κάρτα ανήκει σε άλλο πρόσωπο

3. Μη λειτουργικές απαιτήσεις

Ο χρόνος επικοινωνίας µε το εξωτερικό σύστηµα έγκρισης χρήσης πιστωτικών καρτών δεν πρέπει να ξεπερνά τα 5 δευτερόλεπτα.

4. Κατάσταση εισόδου

Ο χρήστης να έχει κάνει επιτυχηµένα log-in στο σύστηµα

5. Κατάσταση εξόδου

1. Ο λογαριασµός πελάτη τροποποιήθηκε επιτυχηµένα, και συνεχίζει να χρησιµοποιεί το σύστηµα

2. Ο λογαριασµός δεν τροποποιήθηκε είτε γιατί ο χρήστης απέτυχε να εισάγει τη σωστή πληροφορία είτε γιατί ακύρωσε τη διαδικασία τροποποίησης του λογαριασµού.

Εικόνα 20: Περιγραφή της περίπτωσης χρήσης «Τροποποίηση Στοιχείων Πελάτη»

1. Τίτλος περίπτωσης χρήσης: Log In

1.1. Σύντοµη περιγραφή

Η περίπτωση χρήσης log in επιτρέπει στον ανώνυµο πελάτη να ταυτοποιηθεί από το σύστηµα και να αποκτήσει πρόσβαση στη λειτουργικότητα του συστήµατος ανάλογα µε το ρόλο του. Αν ο ρόλος του αντιστοιχεί σε πελάτη τότε αποκτά το ρόλο του καταχωρηµένου πελάτη. Σε αντίθετη περίπτωση αποκτά το ρόλο του ∆ιαχειριστή του συστήµατος. Τέλος εάν ο χρήστης δεν έχει λογαριασµό στο σύστηµα του δίνεται η δυνατότητα να δηµιουργήσει ένα νέο λογαριασµό πελάτη.

1.2. Χειριστές: Ανώνυµος Πελάτης

2. Ροή γεγονότων.

2.1 Βασική ροή

Αυτή η περίπτωση χρήσης αρχίζει όταν ο πελάτης επιλέξει τη λειτουργία «log-in”.

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

49 ΠΛΗ24 – Σχεδιασµός Λογισµικού

1. Το σύστηµα παρουσιάζει τη φόρµα εισαγωγής στο σύστηµα όπου ζητά από το χρήστη να δώσει το username και το password.

2. Ο χρήστης εισάγει το username και το password.

3. Το σύστηµα ελέγχει ότι το ζευγάρι των τιµών username/password αντιστοιχεί σε έναν πελάτη του συστήµατος.

4. Ο χρήστης εισέρχεται στο σύστηµα αποκτώντας πρόσβαση στη λειτουργικότητα του ρόλου που έχει ο χρήστης (καταχωρηµένος πελάτης ή διαχειριστής του συστήµατος),

5. Το σύστηµα παρουσιάζει µήνυµα καλωσορίσµατος του χρήστη.

Η περίπτωση χρήσης τελειώνει.

2.2 Εναλλακτικές ροές

2.2.1 Εναλλακτική ροή 1 - «Νέος χρήστης»

Ο χρήστης δεν έχει λογαριασµό. Το σύστηµα επιτρέπει την «∆ηµιουργία Λογαριασµού Πελάτη» σε όσους χρήστες δεν έχουν λογαριασµό

2.2.2 Εναλλακτική ροή 2 – «Αποτυχία ταυτοποίησης χρήστη»

Το σύστηµα δε µπόρεσε να αναγνωρίσει το συνδυασµό username/password.

4α. Το σύστηµα παρουσιάζει στο χρήστη σχετικό µήνυµα

4β. Η ροή µεταφέρεται στο βήµα 1.

3. Μη λειτουργικές απαιτήσεις

Η πληροφορία username/password πρέπει να µεταφέρεται κρυπτογραφηµένη από τον internet browser στον web server έτσι ώστε να αποφύγουµε τον κίνδυνο υποκλοπής δεδοµένων.

4. Κατάσταση εισόδου

∆εν υπάρχει

5. Κατάσταση εξόδου

1. Ο πελάτη ταυτοποιήθηκε επιτυχηµένα από το σύστηµα και ξεκίνησε να χρησιµοποιεί το σύστηµα

2. Το σύστηµα απέτυχε να ταυτοποιήσει τον πελάτη και παραµένει µε το ρόλο του ανώνυµου πελάτη.

Εικόνα 21: Περιγραφή της περίπτωσης χρήσης «log-in»

5.2.4 Κανόνες για την ανάπτυξη του µοντέλου περιπτώσεων χρήσης

Λόγω του γεγονότος ότι το µοντέλο των περιπτώσεων χρήσης είναι το σηµαντικότερο τόσο στην UML όσο και στην ενοποιηµένη προσέγγιση, στην παράγραφο αυτή, θα παρουσιάσουµε ορισµένους πρακτικούς κανόνες για τη

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

50 ΠΛΗ24 – Σχεδιασµός Λογισµικού

δηµιουργία του µοντέλου αυτού. Η παρακάτω λίστα κανόνων είναι ενδεικτική και όχι εξαντλητική. Οι κανόνες είναι:

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

2. Οι περιπτώσεις χρήσης του συστήµατος πρέπει να είναι ευκολοδιάβαστες. Για να επιτύχουµε αυτό το στόχο πρέπει να δώσουµε έµφαση στα εξής:

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

b. Ο τίτλος των περιπτώσεων χρήσης πρέπει να είναι σαφής, σύντοµος και ξεκάθαρος.

c. Χρησιµοποιείστε ρήµατα ενεργητικής φωνής όσο είναι δυνατόν.

d. Οι χειριστές πρέπει να εµφανίζονται σε κάθε βήµα (ποιος κάνει τι).

e. Ξεκινήστε µε το γεγονός που σηµατοδοτεί την έναρξη της περίπτωση χρήσης και καταλήξτε στην επίτευξη του σκοπού (επιτυχία).

f. Περιγράψτε τις συνθήκες (if) σαν εναλλακτικά σενάρια.

g. Περιγράψτε µε διακριτό τρόπο σαν εναλλακτικά σενάρια, τις περιπτώσεις αποτυχίας της περίπτωσης χρήσης.

3. Κάθε βήµα του σεναρίου να είναι µια απλή σύντοµη πρόταση σε ενεργητική φωνή.

4. Προτιµήστε πολλές µικρές προτάσεις αντί για µια µεγάλη.

5. Χρησιµοποιείστε υπο-περιπτώσεις χρήσης όπου µπορείτε για να απλοποιήσετε την περιγραφή

6. Ο αριθµός των βηµάτων της βασικής ροής µιας περίπτωσης χρήσης δε µπορεί να είναι µεγάλος. Ο ιδανικός αριθµός είναι µικρότερος του 10.

7. Μια περίπτωση χρήσης περιγράφει το τι µπορεί να κάνει ένας χειριστής µέσα σε λίγα λεπτά (2-20 λεπτά).

8. Οι περιπτώσεις χρήσης περιγράφουν την πρόθεση του χειριστή να επιτύχει το σκοπό του και όχι τις κινήσεις που πρέπει να κάνει αυτός στο user interface. Αυτό ισχύει γιατί αν περιγράψουµε το user interface.

a. Το έγγραφο των περιπτώσεων χρήσης γίνεται πάρα πολύ µεγάλο.

b. Οι αλλαγές στο user interface είναι συχνές, το οποίο σηµαίνει ότι θα πρέπει να αλλάζουµε/συντηρούµε το έγγραφο των περιπτώσεων χρήσης συχνά, ενέργεια που αυξάνει το κόστος.

c. Ο σχεδιασµός του user interface ακολουθεί γενικότερους κανόνες και είναι πρόβληµα σχεδίασης και όχι καταγραφής απαιτήσεων.

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

51 ΠΛΗ24 – Σχεδιασµός Λογισµικού

9. Κάθε περίπτωση χρήσης µπορεί να τελειώσει τουλάχιστον µε δύο τρόπους: την επιτυχία και την αποτυχία. Μια καλή περιγραφή οφείλει να λαµβάνει υπόψη της και τους δύο τρόπους.

10. Μια περίπτωση χρήσης δεν περιγράφει απλά την αλληλεπίδραση του χειριστή µε το σύστηµα αλλά εγγυάται τα συµφέροντα των συµµετεχόντων. Για παράδειγµα, στην περίπτωση χρήσης «Πληρωµή Παραγγελίας» ο βασικός χειριστής απλά επιθυµεί την πληρωµή του ποσού. Η εταιρεία στην οποία ανήκει το ηλεκτρονικό κατάστηµα χρειάζεται να εξασφαλίσει ότι κανείς δεν παίρνει κάτι χωρίς να πληρώσει, η εφορία χρειάζεται να εξασφαλίσει ότι γίνεται η παρακράτηση του ΦΠΑ και ότι υπάρχουν σχετικές λογιστικές εγγραφές κ.λπ. Όλα αυτά πρέπει να καταγράφονται στην βασική και στις εναλλακτικές ροές.

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

12. Όπως έχουµε ήδη αναφέρει το µοντέλο των περιπτώσεων χρήσης παράγει µεγάλο µέγεθος κειµένων. Για την καλύτερη οργάνωση των περιπτώσεων χρήσης υπάρχουν τρεις τρόποι:

a. Ανά χειριστή (όλες οι περιπτώσεις χρήσης για κάθε χειριστή)

b. Ανά θεµατική ενότητα (οι περιπτώσεις χρήσεις περιγράφονται ανά πακέτο)

c. Ανά οµάδα εργασίας (ο διαχωρισµός αυτό λαµβάνει υπόψη την τεχνογνωσία της κάθε οµάδας).

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

14. Η ανάπτυξη του µοντέλου περιπτώσεων χρήσης γίνεται πρώτα σε πλάτος και στη συνέχεια σε βάθος. Έτσι µπορούµε να ξεκινήσουµε τη συζήτηση µε τους συµµετέχοντες, για τις περιπτώσεις χρήσης.

Συνοψίζοντας, οι βασικές αρχές του µοντέλου περιπτώσεων χρήσης είναι:

1. Οι περιπτώσεις χρήσης πρέπει να περιγράφουν τους στόχους των βασικών χρηστών σε σχέση µε το σύστηµα .

2. Το µοντέλο των περιπτώσεων χρήσης περιγράφει τη συµπεριφορά του συστήµατος όπως αυτό παρουσιάζεται εξωτερικά και όχι την εσωτερική του λειτουργία.

3. Το µοντέλο πρέπει να είναι απλό, σύντοµο και ευκολονόητο.

4. Το µοντέλο των περιπτώσεων χρήσης αποτελεί τη βάση για όλα τα άλλα µοντέλα του συστήµατος (βλέπε Εικόνα 7).

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

52 ΠΛΗ24 – Σχεδιασµός Λογισµικού

5.3 ∆ιαγράµµατα ∆ραστηριοτήτων

Για την καλύτερη περιγραφή των περιπτώσεων χρήσης µπορούµε να χρησιµοποιήσουµε και διαγράµµατα δραστηριοτήτων (activity diagrams). Τα διαγράµµατα δραστηριοτήτων περιγράφουν µια ακολουθία δραστηριοτήτων, όπου µπορούµε να έχουµε παράλληλες δραστηριότητες, συνθήκες κ.λπ.

Συνήθως χρησιµοποιούνται για:

1. την καλύτερη περιγραφή των περιπτώσεων χρήσης

2. την περιγραφή της ροής των εργασιών (workflow)

3. την περιγραφή ενός πολύπλοκου αλγορίθµου

4. την περιγραφή παράλληλων δραστηριοτήτων

Αντίστοιχα, τα διαγράµµατα δραστηριοτήτων δε µπορούν να χρησιµοποιηθούν για την περιγραφή:

1. του τρόπου συνεργασίας των αντικειµένων

2. της εσωτερικής συµπεριφοράς των αντικειµένων

Τα βασικά δοµικά στοιχεία ενός διαγράµµατος δραστηριοτήτων είναι τα ακόλουθα:

• ∆ράση (action): Μια απλή ενέργεια που δε µπορεί να αναλυθεί περαιτέρω καλείται δράση. Για κάθε δράση µπορούµε να ορίσουµε την κατάσταση εισόδου (pre-conditions) και την κατάσταση εξόδου (post-condition) Παραδείγµατα δράσης είναι τα ακόλουθα:

o ∆ιαβάζουµε ή δίνουµε τιµή σε ένα πεδίο

o Καλούµε µια µέθοδο µιας κλάσης

o Ξεκινάµε την εκτέλεση µιας άλλης δραστηριότητας

o Στέλνουµε ένα µήνυµα σε ένα άλλο αντικείµενο

Μια δράση αναπαρίσταται στη UML ως ορθογώνιο µε στρογγυλευµένες άκρες.

• ∆ραστηριότητα (activity): Οι δραστηριότητες περιέχουν ακολουθίες δράσεων ή/και άλλων δραστηριοτήτων. Οι δραστηριότητες αναπαρίστανται µε τον ίδιο τρόπο όπως και οι δράσεις. Μια δραστηριότητα µπορεί επίσης να παρουσιασθεί σε ένα µεγάλο στρογγυλευµένο ορθογώνιο που περιέχει σύνθετες ακολουθίες δράσεων, ροές αντικειµένου και ροές ελέγχου. Η σύνθετη µορφή µιας δραστηριότητας επιτρέπει να παρουσιάσουµε τις παραµέτρους, την κατάσταση εισόδου, την κατάσταση εξόδου, και τις ιδιότητες της δραστηριότητας.

• Ροή ελέγχου (control flow): Μια ροή ελέγχου συνδέει τις δράσεις/δραστηριότητες µεταξύ τους και παρουσιάζει την ακολουθία εκτέλεσης.

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

53 ΠΛΗ24 – Σχεδιασµός Λογισµικού

• Κόµβος ελέγχου (control node): Ένας κόµβος ελέγχου χρησιµοποιείται για να προσδιορίσει τη ροή του ελέγχου (και τη ροή των αντικειµένων) µέσα σε µια οµάδα δραστηριοτήτων και δράσεων. Οι κόµβοι ελέγχου έρχονται µε ποικίλες µορφές, ανάλογα µε την ανάγκη και χρησιµεύουν ως σήµατα κυκλοφορίας για τη ροή του ελέγχου και τη ροή των αντικειµένων. Οι διαφορετικοί κόµβοι ελέγχου είναι οι ακόλουθοι:

o Αρχικός κόµβος: Χρησιµοποιείται για να σηµατοδοτήσει την έναρξη µιας ακολουθίας δραστηριοτήτων ή δράσεων.

o Τελικός κόµβος: Χρησιµοποιείται για να σηµατοδοτήσει τη λήξη µιας ακολουθίας δραστηριοτήτων ή δράσεων.

o Τελική ροή: Σηµατοδοτεί το πέρας µιας ροής.

o Απόφαση: Ένας κόµβος απόφασης χρησιµοποιείται για τον έλεγχο µιας συνθήκης και τη δροµολόγηση της αντίστοιχης ροής.

o Συγχώνευση (merge): Χρησιµοποιείται για να σηµατοδοτήσει το τέλος µιας συνθήκης και των εναλλακτικών ροών που αυτή παράγει. Το αποτέλεσµα είναι ότι επαναφέρει χωριστές ροές ελέγχου ή αντικειµένων ξανά σε µια ροή.

o ∆ιακλάδωση (fork): Σηµατοδοτεί την έναρξη ταυτόχρονων δραστηριοτήτων.

o Σύνδεση (join): Είναι το αντίθετο της διακλάδωσης. Ενώνει δύο παράλληλες ροές ταυτόχρονων δραστηριοτήτων.

Η γραφική αναπαράσταση των συµβόλων που χρησιµοποιούνται στα διαγράµµατα δραστηριοτήτων παρουσιάζεται στην Εικόνα 26.

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

54 ΠΛΗ24 – Σχεδιασµός Λογισµικού

Εικόνα 22: Παράδειγµα διαγράµµατος δραστηριότητας

Οι παλαιότερες εκδόσεις UML είχαν τα διαγράµµατα δραστηριότητας ως ένα ειδικό είδος διαγραµµάτων καταστάσεων. Στην UML 2 τα διαγράµµατα δραστηριότητας αποκτούν νέο νόηµα, και λειτουργούν όπως ένα δίκτυο Petri.

Τα δίκτυα Petri, αναπαριστούν ένα σύστηµα σαν ένα σύνολο αλληλεπιδρώντων ενεργών και παθητικών οντοτήτων, όπου οι ενεργές οντότητες ονοµάζονται µεταβάσεις και οι παθητικές οντότητες ονοµάζονται θέσεις.

Στα διαγράµµατα δραστηριότητας οι ενεργές οντότητες είναι τα αντικείµενα τα οποία καταναλώνονται από τις δραστηριότητες/δράσεις, οι οποίες µε τη σειρά τους παράγουν νέα αντικείµενα. Με τον τρόπο αυτό τα διαγράµµατα δραστηριότητας µπορούν να χρησιµοποιηθούν µε τέτοιο τρόπο ώστε να περιγράψουν συστήµατα πραγµατικού χρόνου ή κατανεµηµένα συστήµατα.

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

55 ΠΛΗ24 – Σχεδιασµός Λογισµικού

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

Εικόνα 23: ∆ιάγραµµα δραστηριότητας για την περίπτωση χρήσης «∆ηµιουργία Λογαριασµού Πελάτη»

Στην Εικόνα 23 παρουσιάζεται το διάγραµµα δραστηριοτήτων για την περίπτωση χρήσης «∆ηµιουργία Λογαριασµού Πελάτη». Στο διάγραµµα αυτό παρουσιάζονται τα επιµέρους βήµατα που εκτελούνται από κάθε διαφορετικό χειριστή. Γενικά στα διαγράµµατα δραστηριοτήτων, για την αναπαράσταση των υπευθυνοτήτων, «ποιος κάνει τι» χρησιµοποιούµαι λωρίδες (swimlanes) οι οποίες παρουσιάζουν µε εποπτικό τρόπο την αλληλεπίδραση των χειριστών.

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

56 ΠΛΗ24 – Σχεδιασµός Λογισµικού

5.4 Το µοντέλο αλληλεπίδρασης του χρήστη µε το σύστηµα

Ο τρόπος που θα αλληλεπιδρά ο χρήστης µε το σύστηµα είναι µια πολύ σοβαρή παράµετρος του συστήµατος η οποία θα πρέπει να ληφθεί υπόψη από τις πρώτες φάσεις ανάπτυξης αυτού.

Το µοντέλο αλληλεπίδρασης (user experience model) είναι σηµαντικό όχι µόνο γιατί ο χρήστης αποκτά από πολύ νωρίς άποψη για το πως θα λειτουργεί το σύστηµά του αλλά και για την οµάδα ανάπτυξης η οποία θα µπορέσει να κατανοήσει µε καλύτερο τρόπο την εργασία των χειριστών, τα κρίσιµα σηµεία καθώς και τις τεχνικές δυσκολίες που θα προκύψουν στην πορεία.

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

Επιπλέον, κατά τη διάρκεια της καταγραφής και ανάλυσης των απαιτήσεων πολλές φορές υπάρχουν αµφιβολίες σχετικά µε τον τρόπο λειτουργίας του συστήµατος, η του κατά πόσο είναι εφικτή µια προσέγγιση. Για τη διερεύνηση των απαιτήσεων αλλά και της ανάπτυξης του συστήµατος χρησιµοποιείται η τεχνική της πρωτοτυποποίησης. Γενικότερα, η πρωτοτυποίηση µπορεί να είναι εξελικτική ή διερευνητική. Το διερευνητικό πρωτότυπο ή πρωτότυπο µιας χρήσης (throw-away prototype) είναι λογισµικό που αναπτύσσεται για τη διερεύνηση κάποιων από τα στοιχεία του συστήµατος, της αποδοτικότητας µιας λύσης, την ελκυστικότητα µιας προσέγγισης κ.λπ. Λόγω του γεγονότος ότι ένα διερευνητικό πρωτότυπο διερευνά ένα συγκεκριµένο πρόβληµα-θέµα, και ο σκοπός του είναι η εξαγωγή συµπερασµάτων, το ίδιο το πρωτότυπο δε µπορεί να επαναχρησιµοποιηθεί σε επόµενη φάση της ανάπτυξης και είναι άχρηστο µετά το τέλος του πειράµατος. Σε αντιδιαστολή ένα εξελικτικό πρωτότυπο (evolutionary prototype) θα επαναχρησιµοποιηθεί σε επόµενη φάση της ανάπτυξης του συστήµατος.

Η αντικειµενοστρεφής ανάπτυξη συστηµάτων µε τη χρήση της ενοποιηµένης προσέγγισης είναι επαναληπτική διαδικασία και συνεπώς εκ φύσεως ταιριάζει πολύ καλύτερα µε τη χρήση της εξελικτικής πρωτοτυποποίησης. Παρόλα αυτά δε µπορούµε να αποκλείσουµε τη χρήση διερευνητικών πρωτοτύπων σε ειδικές περιπτώσεις.

Για την ανάπτυξη του µοντέλου αλληλεπίδρασης µε το χρήστη χρειάζεται:

• Ο ορισµός του χάρτη πλοήγησης στο σύστηµα (navigation map)

• Την ανάπτυξη της διεπαφής µε το χρήστη (user interface)

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

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

57 ΠΛΗ24 – Σχεδιασµός Λογισµικού

Στην Εικόνα 25 παρουσιάζεται ο χάρτης πλοήγησης για την «∆ιαχείριση Λογαριασµού Πελάτη». Για τη δηµιουργία του χάρτη πλοήγησης χρησιµοποιούµε ένα διάγραµµα αντικειµένων (object diagram). Στο διάγραµµα αυτό παρουσιάζονται τρία καινούργια στοιχεία της γλώσσας UML:

• τα στερεότυπα,

• η χρήση κατεύθυνσης στις σχέσεις και

• η σχέση σύνθεσης.

Στο διάγραµµα αντικειµένων χρησιµοποιήσαµε δύο στερεότυπα. Το στερεότυπο (stereotypes) «screen» και το στερεότυπο «input form».

Ένα στερεότυπο είναι ένας µηχανισµός επέκτασης του λεξιλογίου της UML, που µας επιτρέπει να δηµιουργήσουµε νέα δοµικά στοιχεία µε τα οποία δίνουµε όνοµα σε συγκεκριµένου τύπου κατασκευές, ή δοµές που εντοπίζουµε στο πεδίο του προβλήµατος. Είναι ο πιο διαδεδοµένος µηχανισµός επεκτασιµότητας της γλώσσας UML και γραφικά αναπαρίσταται ως ένα όνοµα µέσα σε διπλά εισαγωγικά και που τοποθετείται επάνω από το όνοµα του στοιχείου που προσδιορίζει. Ακόµη και στον αρχικό ορισµό της γλώσσας UML γίνεται εκτεταµένη χρήση των στερεότυπων. Ως χαρακτηριστικό παράδειγµα µπορούµε να αναφέρουµε, τη δοµή µιας σχέσης (dependency) η οποία µπορεί να χαρακτηρισθεί χρησιµοποιώντας 17 διαφορετικά στερεότυπα: όταν χρησιµοποιείται µεταξύ κλάσεων και αντικειµένων, όταν χρησιµοποιείται µεταξύ πακέτων, όταν χρησιµοποιείται µεταξύ περιπτώσεων χρήσης, κ.λπ. Για να γίνει η παραπάνω έννοια πιο κατανοητή, θα αναφέρουµε το παράδειγµα µιας σχέσης σε ένα διάγραµµα περιπτώσεων χρήσης, όπου ανάλογα µε το στερεότυπο που χρησιµοποιούµε αλλάζει εντελώς η σηµειολογία της σχέσης. Εάν χρησιµοποιήσουµε το στερεότυπο «extends» σηµαίνει ότι η περίπτωση χρήσης στόχος επεκτείνει τη συµπεριφορά της αρχικής περίπτωσης χρήσης. Εάν χαρακτηρίσουµε τη σχέση µε το στερεότυπο «includes» σηµαίνει ότι η αρχική περίπτωση στόχος περιλαµβάνει τη συµπεριφορά περίπτωσης χρήσης στόχος. Όπως είναι προφανές η χρήση στερεοτύπων αλλάζει δραστικά τη σηµασιολογία του στοιχείου που χαρακτηρίζει και κατά συνέπεια την ερµηνεία του διαγράµµατος.

Το δεύτερο καινούργιο στοιχείο που παρουσιάζεται στο χάρτη πλοήγησης είναι η κατεύθυνση πάνω στις σχέσεις. Η χρήση βέλους πάνω στη γραµµή που συνδέει τις σχέσεις βοηθά σε µεγάλο βαθµό στην αναγνωσιµότητα του διαγράµµατος. Η χρήση κατεύθυνσης πάνω σε σχέσεις δε σηµαίνει ότι δε µπορούµε να προσπελάσουµε τη σχέση και τα αντικείµενα από αντίθετη κατεύθυνση, σηµαίνει απλά ότι αυτός είναι ο πιο συνηθισµένος τρόπος µε τον οποίο χρησιµοποιείται η σχέση.

Το τρίτο νέο στοιχείο που παρουσιάζεται στο διάγραµµα είναι η σχέση σύνθεσης (composition). Η σχέση σύνδεσης είναι µια ειδικού τύπου σχέση συναρµολόγησης. Γενικά, η σχέση συναρµολόγησης είναι η σχέση µε την οποία περιγράφουµε το γεγονός ότι µια κλάση «το ολόκληρο» περιέχει, αποτελείται, περιλαµβάνει άλλες κλάσεις «τα µέρη». Η σχέση συναρµολόγησης έχει δύο µορφές:

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

58 ΠΛΗ24 – Σχεδιασµός Λογισµικού

• τη σχέση απλής συναρµολόγησης (aggregation) και

• τη σχέση σύνθεσης (composition).

Η βασική διαφορά των δύο σχέσεων είναι η ακόλουθη:

Αν η κλάση που αποτελεί το «µέρος» ανήκει αποκλειστικά σε µία κλάση «ολόκληρο» τότε η σχέση αυτή είναι σχέση σύνθεσης (composition) και συµβολίζεται µε µαύρο ρόµβο. Στην περίπτωση αυτή όταν το αντικείµενο της κλάσης «ολόκληρο» καταστρέφεται, τότε καταστρέφονται και όλα τα αντικείµενα των κλάσεων «τα µέρη».

Αντίστοιχα, η ύπαρξη της σχέσεως συναρµολόγησης (aggregation) δεν αποκλείει την ύπαρξη των κλάσεων «µέρος» ακόµη και αν δεν υπάρχει το «ολόκληρο».

Αυτοκίνητο

Μηχανή Τιµόνι

Τσάντα

Μήλο Πορτοκάλι

Τσάντα

Μήλο Πορτοκάλι

Αποτελείται περιέχει

Σύνθεση Συναρµολόγηση

Εικόνα 24: Παραδείγµατα σχέσεων συναρµολόγησης και σύνθεσης

Στο παραπάνω παράδειγµα, οι κλάσεις «Μηχανή» και «Τιµόνι» µπορούν να υπάρχουν µόνο στα πλαίσια µιας κλάσης «Αυτοκίνητο» και συνεπώς έχουµε σχέση συναρµολόγησης, ενώ οι κλάσεις «Μήλο» και «Πορτοκάλι» µπορούν να υπάρχουν ανεξάρτητα από την κλάση «Τσάντα».

Στην Εικόνα 25 παρουσιάζεται ο χάρτης πλοήγησης για τη «∆ιαχείριση Λογαριασµού Πελάτη». Η ερµηνεία του συγκεκριµένου χάρτη πλοήγησης είναι η ακόλουθη:

Αρχικά ο χρήστης συνδέεται µε την αρχική σελίδα του ιστοχώρου «Λευκός Κρίνος». Στη συνέχεια ο πελάτης µπορεί να συνδεθεί µε το σύστηµα εάν έχει ήδη λογαριασµό ή να δηµιουργήσει νέο λογαριασµό στην περίπτωση που δεν έχει.

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

59 ΠΛΗ24 – Σχεδιασµός Λογισµικού

Εικόνα 25: Χάρτης πλοήγησης για τη «∆ιαχείριση Λογαριασµού Πελάτη»

Η δηµιουργία νέου λογαριασµού γίνεται εισάγοντας τις πληροφορίες που απαιτούνται στην «input form» µε όνοµα «Φόρµα Λειτουργίας Λογαριασµού». Εάν η πληροφορία που έχει εισαχθεί είναι σωστή τότε ο χρήστης καταχωρείται, γίνεται «καταχωρηµένος πελάτης» και κατευθύνεται στην προσωπική του σελίδα που µόλις έχει δηµιουργηθεί αυτόµατα χρησιµοποιώντας τις πληροφορίες που ο νέος πελάτης καταχώρησε στο σύστηµα. Στην περίπτωση που η πληροφορία που εισήχθη δεν είναι σωστή τότε ο χρήστης κατευθύνεται στη «screen» «∆ιαχείριση Λογαριασµού».

Στις επόµενες εικόνες παρουσιάζονται παραδείγµατα του user interface της εφαρµογής ηλεκτρονικού ανθοπωλείο «Λευκός Κρίνος»

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

60 ΠΛΗ24 – Σχεδιασµός Λογισµικού

Εικόνα 26: Σελίδα δηµιουργίας λογαριασµού πελάτη

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

61 ΠΛΗ24 – Σχεδιασµός Λογισµικού

Εικόνα 27: Σελίδα παρουσίασης συνθέσεων

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

62 ΠΛΗ24 – Σχεδιασµός Λογισµικού

Εικόνα 28: Σελίδα λεπτοµερειών ανθοδέσµης

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

63 ΠΛΗ24 – Σχεδιασµός Λογισµικού

6 Μοντέλο Ανάλυσης Στη φάση της ανάλυσης, αναλύουµε, εκλεπτύνουµε και δοµούµε περαιτέρω τις απαιτήσεις που συλλέξαµε στην προηγούµενη φάση. Σκοπός µας είναι να κατανοήσουµε το σύστηµα σε ικανή λεπτοµέρεια έτσι ώστε να προχωρήσουµε στο σχεδιασµό . Είναι προφανές ότι ο διαχωρισµός των φάσεων της καταγραφής απαιτήσεων και της ανάλυσης είναι σε ένα βαθµό τεχνητός µια και το ένα µοντέλο αποτελεί τη συνέχεια του άλλου.

Οι βασικοί στόχοι του µοντέλου ανάλυσης είναι οι παρακάτω:

• Να προδιαγράψουµε όλες τις απαιτήσεις του συστήµατος.

• Να προσδιορίσουµε επακριβώς τις κλάσεις του συστήµατος

• Να ορίσουµε την αλληλεπίδραση των κλάσεων.

Συχνά επιλέγεται να παραληφθεί το µοντέλο της ανάλυσης και να περάσουµε κατευθείαν από το µοντέλο των απαιτήσεων στο µοντέλο του σχεδιασµού γεγονός που είναι επιθυµητό στις περιπτώσεις που υπάρχει πίεση χρόνου και θέλουµε να συντοµεύσουµε τον κύκλο ζωής του συστήµατος. Από την άλλη πλευρά υπάρχουν πολλά παραδείγµατα περιπτώσεων τα οποία αποδεικνύουν τη χρησιµότητα του µοντέλου. Μερικές από αυτές τις περιπτώσεις είναι οι ακόλουθες:

• Η ανάπτυξη του συστήµατος γίνεται σε µία συνολική φάση καταγραφής των απαιτήσεων και ανάλυσης αυτών ενώ ο σχεδιασµός και υλοποίηση του συστήµατος γίνεται ανά υποσύστηµα.

• Η χρήση του µοντέλου ανάπτυξης σε πολύ µεγάλα συστήµατα επιτρέπει την καλύτερη και ταχύτερη κατανόηση των απαιτήσεων του συστήµατος καθώς και της αρχιτεκτονικής του.

• Σε πολλές περιπτώσεις υπάρχουν εναλλακτικοί τρόποι σχεδιασµού και υλοποίησης του συστήµατος µε χρήση διαφορετικών τεχνικών ή τεχνολογίας. Η χρήση του µοντέλου ανάλυσης δίνει µια καλύτερη εικόνα των εναλλακτικών αυτών περιπτώσεων και των επιπτώσεων που έχουν αυτοί οι τρόποι στο σύστηµα γενικότερα.

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

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

Μοντέλο απαιτήσεων Μοντέλο ανάλυσης

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

64 ΠΛΗ24 – Σχεδιασµός Λογισµικού

Μοντέλο απαιτήσεων Μοντέλο ανάλυσης

Περιγράφει το σύστηµα χρησιµοποιώντας τη γλώσσα του πελάτη

Περιγράφει το σύστηµα χρησιµοποιώντας τη γλώσσα του τεχνικού

Παρουσιάζει την εικόνα του συστήµατος από έξω

Παρουσιάζει την εικόνα του συστήµατος εσωτερικά

Είναι δοµηµένο γύρω από τις περιπτώσεις χρήσης

Είναι δοµηµένο γύρω από τις κλάσεις

Χρησιµοποιείται για την επικοινωνία µέσα στο έργο και έχει την αξία συµβολαίου µεταξύ της οµάδας ανάπτυξης και του πελάτη του έργου

Χρησιµοποιείται κυρίως από την οµάδα του έργου για την καλύτερη κατανόηση του συστήµατος

Το µοντέλο µπορεί να περιέχει ανακρίβειες και επικαλύψεις

Το µοντέλο πρέπει να είναι όσο το δυνατόν πιο σαφές και ακριβές

Γενικά θα µπορούσαµε να συνοψίσουµε και να αναφέρουµε ότι υπάρχουν τρεις προσεγγίσεις για το µοντέλο ανάλυσης µέσα στον κύκλο ζωής του έργου οι οποίες είναι:

1. Το µοντέλο της ανάλυσης είναι βασικό, παράγεται και συντηρείται καθ’όλη τη διάρκεια του έργου και χρησιµοποιείται για την ιχνηλάτιση των απαιτήσεων.

2. Το µοντέλο της ανάλυσης χρησιµοποιείται ως βοηθητικό εργαλείο και για τη µετάβαση από την καταγραφή απαιτήσεων στο σχεδιασµό

3. Το µοντέλο της ανάλυσης δεν χρησιµοποιείται καθόλου και από τη φάση της καταγραφής και ανάλυσης απαιτήσεων περνάµε απ’ευθείας στη φάση του σχεδιασµού.

Στη παρούσα µελέτη περίπτωσης, το µοντέλο ανάλυσης θα χρησιµοποιηθεί ως ενδιάµεσο εργαλείο για τη µετάβαση στη φάση του σχεδιασµού, µια και η φάση της καταγραφής και ανάλυσης των απαιτήσεων υπήρξε αναλυτική. Πιο συγκεκριµένα θα χρησιµοποιηθεί για:

• την εκλέπτυνση του µοντέλου του πεδίου προβλήµατος (class model)

• τη δηµιουργία διαγραµµάτων συνεργασίας (collaboration diagrams) και

• την αντιστοίχηση των περιπτώσεων χρήσης σε πακέτα ανάλυσης

6.1 Εκλέπτυνση του διαγράµµατος κλάσεων

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

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

65 ΠΛΗ24 – Σχεδιασµός Λογισµικού

Στην Εικόνα 29 παρουσιάζεται το µοντέλο κλάσεων. Επιπλέον, για κάθε κλάση παρουσιάζονται τα πεδία των κλάσεων. Στο σηµείο αυτό θα πρέπει να αναφέρουµε ότι για λόγους αναγνωσιµότητας του µοντέλου δεν έχουν γραφτεί όλα τα πεδία αλλά µόνο αυτά που περιγράφουν καλύτερα το πρόβληµα.

Επιπλέον, στην Εικόνα 29 παρουσιάζεται η πολλαπλότητα (multiplicity) των σχέσεων. Η πολλαπλότητα µιας σχέσης υποδηλώνει µε πόσα αντικείµενα µιας κλάσης µπορεί να συνδέεται ένα αντικείµενο µιας άλλης κλάσης. Για τον προσδιορισµό της πολλαπλότητας χρειάζεται για κάθε κλάση η οποία συνδέεται µε κάποια άλλη να αναλύσουµε το είδος της σχέσης. Για παράδειγµα στην Εικόνα 29 υπάρχει µια σύνδεση (association) µεταξύ της κλάσης ανθοπωλείου και του πελάτη. Εξετάζοντας τη σύνδεση από την πλευρά της κλάσεως «Ανθοπωλείο» µπορούµε να ρωτήσουµε τις παρακάτω ερωτήσεις:

• Μπορεί ένα ανθοπωλείο να µην έχει κανέναν πελάτη (ναι µπορεί, την πρώτη µέρα λειτουργίας του – είναι σπάνιο αλλά µπορεί να συµβεί);

• Πόσους πελάτες µπορεί να έχει ένα ανθοπωλείο ( από 1 έως πολλούς);

Από τις απαντήσεις στις παραπάνω ερωτήσεις προκύπτει ότι ένα ανθοπωλείο «έχει» από 0 έως ν πελάτες. Η παραπάνω πολλαπλότητα συµβολίζεται µε «0..*» το οποίο και γράφουµε στο άκρο της σύνδεσης από την πλευρά του πελάτη.

Αντίστοιχα, ρωτάµε και για τον πελάτη. Για το συγκεκριµένο σύστηµα έχουµε ένα και µόνο ένα ανθοπωλείο και συνεπώς ο πελάτης σχετίζεται αποκλειστικά µε ένα ανθοπωλείο. Με τον ίδιο τρόπο προχωράµε και προσδιορίζουµε όλες τις συνδέσεις.

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

66 ΠΛΗ24 – Σχεδιασµός Λογισµικού

Εικόνα 29: ∆ιάγραµµα κλάσεων µε εµφάνιση πεδίων

Αντιστοίχως επεκτείνουµε το διάγραµµα έτσι ώστε να συµπεριλάβει και τις µεθόδους των κλάσεων. Επιπλέον, στο σηµείο αυτό εκτός από την περαιτέρω ανάλυση του µοντέλου των κλάσεων του πεδίου προβλήµατος θα πρέπει να λάβουµε υπόψη τη γενικότερη δοµή του user interface όπως αυτή ορίσθηκε στο πρωτότυπο του συστήµατος και στο χάρτη πλοήγησης.

Για παράδειγµα, για την περίπτωση χρήσης «∆ηµιουργία Λογαριασµού Πελάτη» της οποίας ο χάρτης πλοήγησης παρουσιάσθηκε στην Εικόνα 25, το διάγραµµα κλάσεων περιγράφεται στην Εικόνα 30.

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

67 ΠΛΗ24 – Σχεδιασµός Λογισµικού

Εικόνα 30: ∆ιάγραµµα κλάσης για περίπτωση χρήσης «∆ηµιουργία Λογαριασµού Πελάτη»

6.2 Η συνεργασία των αντικειµένων

Μέχρι στιγµής έχουµε περιγράψει το σύστηµα εξωτερικά, µε τις περιπτώσεις χρήσης (το τι θα θέλαµε το σύστηµα να κάνει), έχουµε περιγράψει τη στατική δοµή του συστήµατος (τη δοµή των κλάσεων και τις σχέσεις µεταξύ τους) αλλά δεν έχουµε περιγράψει τη δυναµική συµπεριφορά του. Όταν λέµε δυναµική συµπεριφορά εννοούµε τον τρόπο µε τον οποίο συνεργάζονται τα αντικείµενα έτσι ώστε να υλοποιήσουν µια περίπτωση χρήσης.

Για την καλύτερη κατανόηση του τρόπου µε τον οποίο συνεργάζονται τα αντικείµενα για την επίτευξη ενός σκοπό η UML παρέχει έναν αριθµό διαγραµµάτων όπως τα διαγράµµατα επικοινωνίας (communication diagram) ή τα διαγράµµατα ακολουθίας (sequence diagram) ή τα διαγράµµατα δραστηριοτήτων (activity diagram).

Τα διαγράµµατα επικοινωνίας (communication diagram) είναι τα διαγράµµατα που στην UML 2.0 αντικατέστησαν τα διαγράµµατα συνεργασίας (collaboration diagram)1.

Τα διαγράµµατα ακολουθίας και τα διαγράµµατα συνεργασίας είναι σηµασιολογικά ισοδύναµα. Η διαφορά είναι o τρόπος µε τον οποίο παρουσιάζεται η πληροφορία

1 Στην παρούσα µελέτη περίπτωσης θα συνεχίσουµε να χρησιµοποιούµε τον όρο διαγράµµατα συνεργασίας για λόγους οµοιοµορφίας µε το υπάρχον εκπαιδευτικό υλικό.

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

68 ΠΛΗ24 – Σχεδιασµός Λογισµικού

και όχι η σηµασιολογία της. Τα διαγράµµατα ακολουθίας υπογραµµίζουν τη χρονική αλληλουχία των µηνυµάτων, ενώ τα διαγράµµατα συνεργασίας εστιάζονται περισσότερο στην οργανωτική δοµή. Πολλά εργαλεία UML µετατρέπουν αυτόµατα τον έναν τύπο διαγράµµατος στον άλλο. Μάλλον, υπάρχουν και τα δύο για ιστορικούς λόγους.

Εικόνα 31: ∆ιάγραµµα ακολουθίας για την περίπτωση χρήσης «∆ηµιουργία Λογαριασµού Πελάτη»

Στην Εικόνα 31 παρουσιάζεται το διάγραµµα ακολουθίας για την περίπτωση χρήσης «∆ηµιουργία Λογαριασµού Πελάτη». Στο παραπάνω διάγραµµα παρατηρούµε ότι ο χειριστής «Ανώνυµος Χρήστης» ξεκινά την αλληλεπίδραση µε το σύστηµα επιλέγοντας τη δηµιουργία νέου λογαριασµού µε την κλήση της µεθόδου createNewAccount() της κλάσης «Αρχική Σελίδα». Στη συνέχεια, ο χρήστης υποβάλλει την απαιτούµενη πληροφορία η οποία και παρουσιάζεται ξανά στο χρήστη για επαλήθευση (confirmNewAccount).

Σε ένα διάγραµµα ακολουθίας στον οριζόντιο άξονα και από αριστερά προς τα δεξιά παρουσιάζονται τα αντικείµενα που συµµετέχουν στην αλληλεπίδραση. Αναφέρουµε αντικείµενα και όχι κλάσεις γιατί πλέον αναφερόµαστε στον τρόπο µε τον οποίο τρέχει το σύστηµα και όχι σε µια δοµή του συστήµατος. Στο παραπάνω σχήµα για τα αντικείµενα χρησιµοποιούµε την ονοµατολογία :Νέος Λογαριασµός, όπου «Νέος Λογαριασµός» είναι το όνοµα της κλάσης. Αν είχαµε περισσότερα του ενός αντικείµενα της ίδιας κλάσης θα γράφαµε x1:Νέος Λογαριασµός και x2:Νέος Λογαριασµός. Η Εικόνα 32 παρουσιάζει την παραπάνω έννοια αναλυτικά.

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

69 ΠΛΗ24 – Σχεδιασµός Λογισµικού

Εικόνα 32: Ο συµβολισµός των κλάσεων και των στιγµιότυπων

Ο κάθετος άξονας είναι ο άξονας του χρόνου. Στον άξονα αυτό παρουσιάζονται διαδοχικά τα µηνύµατα που τα αντικείµενα στέλνει το ένα στο άλλο µε σκοπό την εκπλήρωση της αποστολής του συστήµατος. Στη γενική και απλή περίπτωση τα µηνύµατα είναι κλήσης µεθόδων ενός αντικειµένου. Για παράδειγµα, createNewAccount() είναι µια µέθοδος της κλάσης «Αρχική Σελίδα». Γενικά, υπάρχουν αρκετοί διαφορετικοί τύποι µηνυµάτων οι οποίοι και είναι:

Αντικείµενο Α

x

Γενική µορφή µηνύµατος ή ασύγχρονο µήνυµα

Σύγχρονο µήνυµα

Επιστροφή

∆ηµιουργία αντικειµένου

Καταστροφή αντικειµένου

Κλήση που εγκαταλείπεται αν ο δέκτης δενείναι έτοιµος

Κλήση µε χρόνο (ακυρώνεται αν δεν συµπληρωθεί στον προκαθορισµένο χρόνο)

Αντικείµενο Α

x

Γενική µορφή µηνύµατος ή ασύγχρονο µήνυµα

Σύγχρονο µήνυµα

Επιστροφή

∆ηµιουργία αντικειµένου

Καταστροφή αντικειµένου

Κλήση που εγκαταλείπεται αν ο δέκτης δενείναι έτοιµος

Κλήση µε χρόνο (ακυρώνεται αν δεν συµπληρωθεί στον προκαθορισµένο χρόνο)

Εικόνα 33: Είδη µηνυµάτων σε διαγράµµατα ακολουθίας

Η πιο απλή µορφή µηνύµατος είναι η σύγχρονη κλήση (κλήση µιας µεθόδου στη java, κλήση µιας member function στην C++). Σε µια τέτοια κλήση ο έλεγχος µεταφέρεται στην καλούµενη µέθοδο και µένει εκεί µέχρι τον τερµατισµό της µεθόδου. Με τον τερµατισµό της µεθόδου ο έλεγχος επιστρέφει στην καλούσα συνάρτηση. Συνήθως, η επιστροφή από µια κλήση µεθόδου, είναι ένα µήνυµα, το οποίο παραλείπεται εκτός και αν θέλουµε να τονίσουµε τις τιµές που επιστρέφει µια κλήση.

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

70 ΠΛΗ24 – Σχεδιασµός Λογισµικού

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

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

Μερικοί κανόνες που πρέπει να έχουµε στο µυαλό µας όταν φτιάχνουµε διαγράµµατα ακολουθίας είναι οι ακόλουθοι:

• Χρησιµοποιείστε ένα διάγραµµα ακολουθίας για κάθε περίπτωση χρήσης.

• Στα διαγράµµατα ακολουθίας δίνουµε λεπτοµέρειες για τον τρόπο που υλοποιείται µια συµπεριφορά. Τα διαγράµµατα ακολουθίας δεν είναι απλή αντιγραφή των βηµάτων που περιγράψαµε στις περιπτώσεις χρήσης αλλά είναι το εργαλείο για να αναθέσουµε/ξεκαθαρίσουµε τη λειτουργία, το ρόλο και τη συµπεριφορά των αντικείµενων.

• Για να παρουσιάσετε τη σχέση µεταξύ του διαγράµµατος ακολουθίας και της περίπτωσης χρήσης γράψτε στο περιθώριο του διαγράµµατος ακολουθίας το αντίστοιχο κείµενο από την περίπτωση χρήσης

Ένας εναλλακτικός τρόπος αναπαράστασης της δυναµικής συµπεριφοράς του συστήµατος είναι η χρήση διαγραµµάτων συνεργασίας. Όπως έχουµε ήδη αναφέρει το διάγραµµα συνεργασίας είναι ισοδύναµο µε το διάγραµµα ακολουθίας. Στην Εικόνα 34 παρουσιάζεται το διάγραµµα συνεργασίας που έχει δηµιουργηθεί αυτόµατα από αυτό της Εικόνα 31

Εικόνα 34: ∆ιάγραµµα συνεργασίας για την περίπτωση χρήσης «∆ηµιουργία Λογαριασµού Πελάτη»

Στο σηµείο αυτό είναι σηµαντικό να κατανοήσουµε ότι το µοντέλο της ανάλυσης περιστρέφεται γύρω από τις τρεις επόµενες έννοιες:

• τις συνοριακές κλάσεις (boundary classes),

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

71 ΠΛΗ24 – Σχεδιασµός Λογισµικού

• τις κλάσεις ελέγχου (control classes) και

• τις κλάσεις οντοτήτων (entity classes).

Οι συνοριακές κλάσεις έχουν δύο στόχους. Πρωταρχικά χρησιµοποιούνται για να µοντελοποιήσουν την αλληλεπίδραση του συστήµατος µε τον πραγµατικό κόσµο (το user interface). Στη συνέχεια, στο σχεδιασµό του συστήµατος χρησιµοποιούνται για να αναπαραστήσουν web σελίδες, web φόρµες, οθόνες, παράθυρα, µηνύµατα κ.λπ. Ο δεύτερος στόχος των συνοριακών κλάσεων είναι να αναπαραστήσουν την αλληλεπίδραση του συστήµατος µε άλλα συστήµατα.

Οι κλάσεις ελέγχου αναπαριστούν τη λογική της συµπεριφοράς του συστήµατος. Η συµπεριφορά µπορεί να αναφέρεται τόσο στην επιχειρηµατική λογική (business logic) όσο και στη λογική της διπροσωπίας. Στην περίπτωση που αναφέρεται στην επιχειρηµατική λογική, η κλάση ελέγχου χρησιµοποιείται για να ελέγξει και να συντονίσει την προσπέλαση σε κλάσεις οντοτήτων και γι’αυτό το λόγο ονοµάζεται και διαχειριστής οντοτήτων (entity manager).

Τέλος, οι κλάσεις οντοτήτων είναι αυτές που αναπαριστούν τις επιχειρηµατικές οντότητες που διαχειρίζεται το σύστηµα και των οποίων η πληροφορία-δεδοµένα πρέπει να αποθηκευτούν και να συντηρηθούν. Οι κλάσεις οντοτήτων, αποθηκεύονται σε πίνακες σε βάσεις δεδοµένων και προσπελαύνονται µε τη χρήση διαχειριστών οντοτήτων. Είναι πιθανόν, η ίδια κλάση οντοτήτων να προσπελαύνεται από πολλούς διαφορετικούς χειριστές οντοτήτων (δηλαδή να χρειάζεται σε περισσότερες από µια περιπτώσεις χρήσης) ή ακόµη να είναι ανεξάρτητη του υπό ανάπτυξη συστήµατος και να χρησιµοποιείται και από άλλα συστήµατα της επιχείρησης. Είναι καλό όλες οι λειτουργίες µιας κλάσης οντοτήτων να συντονίζονται από έναν ελεγκτή οντοτήτων. Αυτό βέβαια οδηγεί στην επανάληψη της λογικής (η κλάση οντοτήτων και ο ελεγκτής οντοτήτων έχουν ίδιες ή παρόµοιες µεθόδους). Αν και η προσέγγιση αυτή έχει το µειονέκτηµα της επανάληψης των µεθόδων είναι επιθυµητή γιατί οδηγεί στον διαχωρισµό της λογικής παρουσίασης (presentation logic layer), της επιχειρηµατικής λογικής (business logic layer) από τα δεδοµένα (data layer).

Μερικές συµβουλές για την ανάπτυξη ενός διαγράµµατος συνεργασίας είναι οι ακόλουθες:

• Οι χειριστές επικοινωνούν µόνο µε συνοριακές κλάσεις

• Οι συνοριακές κλάσεις επικοινωνούν µόνο µε χειριστές και µε κλάσεις ελέγχου

• Οι κλάσεις ελέγχου επικοινωνούν µε άλλες κλάσεις ελέγχου, συνοριακές κλάσεις και κλάσεις οντοτήτων.

• Οι κλάσεις οντοτήτων επικοινωνούν µόνο µε κλάσεις ελέγχου (ελεγκτή οντοτήτων).

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

72 ΠΛΗ24 – Σχεδιασµός Λογισµικού

Σωστοί συνδυασµοί Μη συνιστώµενοι συνδυασµοί

Εικόνα 35: Κανόνες διαγραµµάτων συνεργασίας

Η χρήση των παραπάνω κανόνων απλοποιεί τη λογική και την παρουσίαση στα διαγράµµατα συνεργασίας. Πολλές φορές όµως στην πράξη δεν ακολουθούνται ειδικά στην περίπτωση των µικρών συστηµάτων, όπου δεν υπάρχει σαφής διαχωρισµός των επιπέδων (layers). Έτσι το πρότυπο που παρουσιάζεται στην Εικόνα 36 είναι πολύ συνηθισµένο όπου ο χειριστής µέσω µιας φόρµας user interface - συνοριακή κλάση - προσπελαύνει τα δεδοµένα που διαχειρίζεται µια κλάση οντοτήτων.

Εικόνα 36: Παράδειγµα συνεργασίας συνοριακής κλάσης µε κλάση οντοτήτων

Στην Εικόνα 37 παρουσιάζεται η αντιστοίχηση µεταξύ των οθονών και των φορµών user interface και των συνοριακών αντικειµένων.

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

73 ΠΛΗ24 – Σχεδιασµός Λογισµικού

Εικόνα 37: Η αντιστοίχηση µεταξύ των στοιχείων του user interface και των συνοριακών κλάσεων

Στην Εικόνα 38 παρουσιάζεται το διάγραµµα συνεργασίας για την περίπτωση χρήσης «Επιλογή ανθοδέσµης». Το διάγραµµα ξεκινά µε την εµφάνιση της «φόρµας επιλογής ανθοδέσµης». Ο χειριστής «καταχωρηµένος πελάτης» µε κατάλληλες επιλογές κάνει navigate στη συγκεκριµένη φόρµα. Στην «φόρµα επιλογής ανθοδέσµης» ο χρήστης µπορεί να δει τις διαθέσιµες ανθοδέσµες. Επιπλέον, µπορεί να επιλέξει να δει περισσότερες πληροφορίες για κάποια από τις ανθοδέσµες. Αυτό γίνεται µε το µήνυµα viewDetails. Όταν ληφθεί αυτό το µήνυµα η κλάση ελέγχου «Επιλογή Ανθοδέσµης» δηµιουργεί την «Φόρµα Προβολής Στοιχείων Ανθοδέσµης» ανακτά τις απαραίτητες πληροφορίες από την κλάση οντοτήτων «Ανθοδέσµη» και παρουσιάζει την πληροφορία στην «Φόρµα Προβολής Στοιχείων Ανθοδέσµης».

Τέλος, αφού ο χρήστης δει τις απαραίτητες πληροφορίες επιλέγει την ανθοδέσµη του, µε το µήνυµα selectFlowers. Το µήνυµα selectFlowers στέλνεται στην κλάση ελέγχου «Επιλογή Ανθοδέσµης». Αντίστοιχα, η κλάση ελέγχου «Επιλογή Ανθοδέσµης» στέλνει το µήνυµα insert στην άλλη κλάση ελέγχου «Ηλεκτρονικό Καρότσι». Τέλος, η κλάση ελέγχου «Ηλεκτρονικό Καρότσι» στέλνει το µήνυµα insert στην κλάση οντοτήτων «Λίστα Παραγγελιών», οι οποία αποθηκεύει και διαχειρίζεται όλες τις παραγγελίες του πελάτη µέχρι αυτός να αποφασίσει να αποχωρήσει από το ηλεκτρονικό κατάστηµα.

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

74 ΠΛΗ24 – Σχεδιασµός Λογισµικού

Εικόνα 38: ∆ιάγραµµα συνεργασίας για την περίπτωση χρήσης «Επιλογή ανθοδέσµης»

Όπως αναφέραµε και νωρίτερα τα διαγράµµατα ακολουθίας και συνεργασίας είναι σηµασιολογικά ισοδύναµα. Αυτό όµως δεν σηµαίνει ότι τα διαγράµµατα δείχνουν ακριβώς την ίδια πληροφορία. Τα πλεονεκτήµατα και µειονεκτήµατα του κάθε συµβολισµού συνοψίζονται στον παρακάτω πίνακα:

∆ιάγραµµα Πλεονεκτήµατα Μειονεκτήµατα

Συνεργασίας - Παρουσιάζει µε καλύτερο τρόπο τις δοµές επανάληψης, τις συνθήκες, την ταυτόχρονη εκτέλεση

- Παρουσιάζει δυσκολία στην κατανόηση της σειράς εκτέλεσης των µηνυµάτων

- Χρησιµοποιεί πολύπλοκο συµβολισµό

Ακολουθίας - ∆είχνει καλύτερα τη χρονική ακολουθία των µηνυµάτων

- Χρησιµοποιεί ευκολότερο συµβολισµό

- Όταν το διάγραµµα είναι µεγάλο και συµµετέχουν πολλά αντικείµενα επεκτείνεται προς τα δεξιά, πράγµα που δηµιουργεί δυσκολίες χώρου.

6.3 Ο κύκλος ζωής ενός αντικειµένου

Τα αντικείµενα δεν είναι απλά ένα σύνολο από δεδοµένα και µεθόδους. Σε πολλές περιπτώσεις τα αντικείµενα έχουν µνήµη – ζωή. Στο παράδειγµά µας, χρησιµοποιώντας την κλάση «Ηλεκτρονικό Καρότσι» δηµιουργούµε αντικείµενα τύπου «Ηλεκτρονικό Καρότσι» για κάθε συνδεδεµένο πελάτη του συστήµατος. Στην αρχή το ηλεκτρονικό καρότσι του πελάτη δηµιουργείται όταν αυτός συνδέεται µε το σύστηµα. Στη συνέχεια, κάθε φορά που ο πελάτης επιλέγει µια ανθοδέσµη αυτή προστίθεται στο ηλεκτρονικό καρότσι, µέχρις ότου ο πελάτης αποφασίζει να αποχωρήσει από το ηλεκτρονικό κατάστηµα όποτε και φεύγει

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

75 ΠΛΗ24 – Σχεδιασµός Λογισµικού

πληρώνοντας τις ανθοδέσµες. Στο σηµείο αυτό το καρότσι αδειάζει και καταστρέφεται.

Συνήθως, στις γλώσσες προγραµµατισµού όταν καλούµε µια συνάρτηση (function) πρέπει να περάσουµε ως παραµέτρους όλες τις τιµές που είναι απαραίτητες για τη λειτουργία της συνάρτησης. Αντίθετα, σε ένα αντικείµενο που έχει δυναµική συµπεριφορά, οι τιµές των πεδίων ενός αντικειµένου είναι κρυµµένες µέσα στο αντικείµενο. Έτσι όταν ξεκινάει η εκτέλεση µιας µεθόδου το αντικείµενο έχει µνήµη της προηγούµενης ζωής του. Για παράδειγµα, το ηλεκτρονικό καρότσι ενός δεδοµένου πελάτη γνωρίζει τι παραγγελίες περιέχει και ότι δεν είναι άδειο. Η εσωτερική κατάσταση ενός αντικειµένου, καθορίζεται από το συνδυασµό των τιµών των πεδίων που «καθοριστικά κατάστασης».

Για την περιγραφή του κύκλου ζωής ενός αντικειµένου χρησιµοποιούµε τα διαγράµµατα καταστάσεων (state diagram). ∆ύο είναι οι βασικές έννοιες-συµβολισµοί που χρησιµοποιούνται για την κατασκευή των διαγραµµάτων κατάστασης:

• οι καταστάσεις (state) και

• οι µεταβάσεις (transitions)

Μια κατάσταση περιγράφει ένα σηµείο στη ζωή του αντικειµένου κατά την οποία το αντικείµενο ικανοποιεί µια συνθήκη-περιορισµό (constraint-based state), εκτελεί µια ενέργεια (on-going process states) ή περιµένει για να συµβεί ένα γεγονός (wait state).

Για την περιγραφή µιας κατάστασης εκτός από το όνοµα της κατάστασης χρειάζεται να περιγράψουµε:

• τις ενέργειες εισόδου (entry actions)

• τις ενέργειες εξόδου (exit actions)

• τις εσωτερικές µεταβάσεις (µεταβάσεις που συµβαίνουν εσωτερικά της κατάστασης)

• υπο-καταστάσεις (substates)

Μια µετάβαση είναι µία σχέση µεταξύ δύο αντικειµένων που δείχνει ότι αν το αντικείµενο εκτελέσει µια σειρά ενεργειών θα µεταβεί σε επόµενη κατάσταση µε την προϋπόθεση ότι έχουν συµβεί συγκεκριµένα γεγονότα και ικανοποιούνται συγκεκριµένες συνθήκες. Για την περιγραφή µιας µετάβασης χρειάζεται να περιγραφούν τα ακόλουθα:

• την κατάσταση πηγή (source state): είναι η κατάσταση που επηρεάζεται από τη µετάβαση. Μια εξερχόµενη µετάβαση πυροδοτείται όταν ληφθεί το γεγονός πυροδότησης και εφόσον η συνθήκη φρουρός ικανοποιείται

• την κατάσταση στόχος (target state): είναι η κατάσταση που είναι ενεργή µετά την ολοκλήρωση της µετάβασης

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

76 ΠΛΗ24 – Σχεδιασµός Λογισµικού

• το γεγονός πυροδότησης (event trigger): το γεγονός που όταν ληφθεί από το αντικείµενο και µε την προϋπόθεση ότι η συνθήκη φρουρός ικανοποιείται προκαλεί τη µετάβαση

• τη συνθήκη φρουρός (guard condition). Είναι µια λογική συνθήκη η οποία ελέγχεται όταν συµβεί το γεγονός πυροδότησης. Εάν η συνθήκη είναι αληθής τότε πυροδοτείται η µετάβαση κατάστασης. Εάν η συνθήκη είναι ψευδής (µε την προϋπόθεση ότι υπάρχουν άλλες µεταβάσεις καταστάσεων) ελέγχονται οι άλλες µεταβάσεις κατάστασης. Σε αντίθετη περίπτωση το γεγονός χάνεται.

• την ενέργεια (action) που είναι ένας απλός υπολογισµός πάνω στις µεταβλητές κατάστασης του αντικειµένου.

Για τη δηµιουργία ενός διαγράµµατος καταστάσεων µπορούµε να ακολουθήσουµε τα ακόλουθα βήµατα:

• Θέτουµε το πλαίσιο της µηχανής καταστάσεων (state machine), εάν είναι µια κλάση, µια περίπτωση χρήσης, ή το σύστηµα συνολικά.

o Εάν αναφερόµαστε σε µια κλάση ή σε µια περίπτωση χρήσης, καταγράφουµε τις γειτονικές κλάσεις, συµπεριλαµβανοµένων και των κλάσεων πατέρας, εάν η κλάση συµµετέχει σε σχέση κληρονοµικότητας, και οποιωνδήποτε κλάσεων σχετίζονται µε την κλάση υπό εξέταση. Οι κλάσεις αυτές είναι υποψήφιες για να συµπεριληφθούν ως ενέργειες ή στις συνθήκες φρουρός.

o Είναι εξαιρετικά δύσκολο-ανέφικτο να φτιάξουµε ένα διάγραµµα καταστάσεων για όλο το σύστηµα. Όπως έχουµε ήδη αναφέρει, οι καταστάσεις προσδιορίζονται από τις τιµές των πεδίων που είναι καθοριστικά της κατάστασης (state dependent). Συνεπώς, ο συνδυασµός των διαφορετικών τιµών όλων των καθοριστικών κατάστασης πεδίων του συστήµατος παράγει πρακτικά άπειρο αριθµό καταστάσεων. Για το λόγο αυτό πρέπει να περιορίσουµε και να εστιάσουµε το διάγραµµα.

• Προσδιορίζουµε τις αρχικές και τελικές καταστάσεις του αντικειµένου. Ο προσδιορισµός αυτών των καταστάσεων βοηθά γενικότερα στη δηµιουργία του µοντέλου.

• Αποφασίζουµε σχετικά µε τα γεγονότα στα οποία το αντικείµενο µπορεί να αποκριθεί. Τα γεγονότα αυτά συνήθως προσδιορίζονται στις διεπαφές των αντικειµένων.

• Προσδιορίζουµε τις ενέργειες εισόδου ή εξόδου.

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

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

77 ΠΛΗ24 – Σχεδιασµός Λογισµικού

• Εάν µια κατάσταση είναι ιδιαίτερα πολύπλοκη τότε αναλύστε την κατάσταση αυτή δηµιουργώντας ένα άλλο διάγραµµα καταστάσεων για την κατάσταση αυτή όπου παρουσιάζονται οι υποκαταστάσεις

• Αν το αντικείµενο χρειάζεται να τρέχει συνεχώς τότε δεν υπάρχει τελική κατάσταση π.χ. embedded systems, real time systems

Όπως περιγράψαµε µέχρι τώρα ένα διάγραµµα καταστάσεων δείχνει τον τρόπο µε τον οποίο το αντικείµενο αντιδρά στα γεγονότα και µας περιγράφει τη συµπεριφορά του. Αυτό το είδος του διαγράµµατος ονοµάζεται και µηχανή καταστάσεων. Όµως µερικές φορές θέλουµε να δείξουµε απλά την ακολουθία των γεγονότων στην οποία αντιδρά ένα αντικείµενο. Στην περίπτωση αυτή δηµιουργούµε ένα διάγραµµα πρωτοκόλλου (protocol state diagram) το οποίο είναι µια ειδική περίπτωση των διαγραµµάτων καταστάσεων.

Στην Εικόνα 39 παρουσιάζεται το διάγραµµα καταστάσεων για την κλάση «Ηλεκτρονικό Καρότσι». Το «Ηλεκτρονικό Καρότσι» δηµιουργείται µε την είσοδο του πελάτη στο σύστηµα ClientLogin. Μετά την είσοδο του πελάτη το «Ηλεκτρονικό Καρότσι» είναι στην κατάσταση Opened. Όταν ο πελάτης επιλέξει νέα παραγγελία (NewOrder) τότε το «Ηλεκτρονικό Καρότσι» γεµίζει (OrderNo=1) και η κατάστασή του γίνεται Filled. Από την κατάσταση αυτή υπάρχουν τέσσερις περιπτώσεις:

• ο πελάτης επιλέγει νέα παραγγελία (NewOrder) οπότε παραµένουµε στην κατάσταση Filled

• ο πελάτης επιλέγει να σβήσει µια υπάρχουσα παραγγελία (DeleteOrder) οπότε παραµένουµε στην κατάσταση Filled. Η µετάβαση εκτελείται µε την προϋπόθεση ότι υπάρχουν στο καλάθι παραγγελίες (OrderNo >1)

• ο πελάτης όταν ολοκληρώσει τις παραγγελίες του (CheckOut) επιλέγει να πληρώσει οπότε και µεταφερόµαστε στην κατάσταση WaitPayment και

• τέλος ο πελάτης δεν κάνει τίποτε οπότε µετά από 10 λεπτά (TimeOutTimer > 10 min) µη δραστηριότητας το σύστηµα κλείνει τη σύνδεση µε τον πελάτη (TimeOut)

Το ίδιο µπορεί να συµβεί και από την κατάσταση Opened.

Τέλος µετά την εκτέλεση της συναλλαγής το «Ηλεκτρονικό Καρότσι» µεταβαίνει από την κατάσταση WaitPayment στην κατάσταση Closed.

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

78 ΠΛΗ24 – Σχεδιασµός Λογισµικού

Εικόνα 39: ∆ιάγραµµα κατάστασης για την κλάση «Ηλεκτρονικό Καρότσι»

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

79 ΠΛΗ24 – Σχεδιασµός Λογισµικού

7 Μοντέλο Σχεδιασµού Το µοντέλο του σχεδιασµού έχει ως στόχο:

• την κατανόηση των µη λειτουργικών απαιτήσεων και των περιορισµών που σχετίζονται µε το περιβάλλον υλοποίησης, το περιβάλλον λειτουργίας, τη χρήση βάσεων δεδοµένων κ.λπ.

• τον καλύτερο ορισµό όλων των δοµικών στοιχείων που αποτελούν το σύστηµα καθώς και τον ορισµό των διεπαφών µε άλλα συστήµατα και

• τη διαχείριση της εργασίας και το σπάσιµό της σε υπο-ενότητες έτσι ώστε η υλοποίηση να γίνει µε το βέλτιστο τρόπο

Προφανώς, δεν υπάρχει µόνο µια λύση, δηλαδή µόνο ένα µοντέλο σχεδιασµού που ικανοποιεί τις απαιτήσεις. Αντίθετα, υπάρχουν πρακτικά άπειροι συνδυασµοί ανάλογα µε τις αποφάσεις που θα λάβουµε, αποφάσεις που σχετίζονται µε την αρχιτεκτονική, την τεχνολογία, το περιβάλλον ανάπτυξης, το περιβάλλον λειτουργίας, το hardware που θα επιλέξουµε κ.λπ.

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

Μοντέλο ανάλυσης Μοντέλο σχεδιασµού

Παράγει το ιδεατό µοντέλο (conceptual model) όπου δεν περιγράφουµε τις λεπτοµέρειες υλοποίησης

Παράγει το φυσικό µοντέλο (physical model) που είναι λεπτοµερές µια και είναι αυτό που καθοδηγεί την ανάπτυξη

Το µοντέλο της ανάλυσης λόγω της γενικότητάς του µπορεί υλοποιηθεί από πολλά διαφορετικά – εναλλακτικά µοντέλα σχεδιασµού

Το µοντέλο σχεδιασµού είναι ένα και συγκεκριµένο. Όλες οι εναλλακτικές λύσεις έχουν αξιολογηθεί και έχει επιλεγεί η βέλτιστη

Το µοντέλο της ανάλυσης είναι γενικό και βασίζεται στα τρία στερεότυπα των κλάσεων (συνοριακές, ελέγχου και οντοτήτων)

Το µοντέλο του σχεδιασµού βασίζεται στα στερεότυπα της υλοποίησης τα οποία εξαρτώνται από τις αποφάσεις που έχουµε λάβει

∆εν είναι τόσο αυστηρά ορισµένο Είναι αυστηρά ορισµένο

Στο µοντέλο της ανάλυσης παρουσιάζονται λίγα αρχιτεκτονικά επίπεδα

Στο µοντέλο του σχεδιασµού παρουσιάζονται πολλά αρχιτεκτονικά επίπεδα και η συγκεκριµένη αρχιτεκτονική που έχει επιλεγεί για να υλοποιηθεί.

Περιγράφει την αρχιτεκτονική του συστήµατος

Ορίζει την αρχιτεκτονική του συστήµατος

Καλό είναι να συντηρούµε, το µοντέλο της ανάλυσης σε όλο το κύκλο ζωής

Είναι απαραίτητο να συντηρούµε, να ενηµερώνουµε και να συγχρονίζουµε το

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

80 ΠΛΗ24 – Σχεδιασµός Λογισµικού

Μοντέλο ανάλυσης Μοντέλο σχεδιασµού ανάπτυξης του συστήµατος µοντέλο του σχεδιασµού σε όλο το

κύκλο ζωής ανάπτυξης του συστήµατος

Αν προσπαθήσουµε να περιγράψουµε τη διαδικασία του σχεδιασµού βήµα-βήµα τότε έχουµε τα ακόλουθα βήµατα:

1. Καταγραφή των προτεραιοτήτων του σχεδιασµού:

a. Λειτουργικές απαιτήσεις (functional requirements): Κάθε περίπτωση χρήσης περιγράφει ένα τµήµα της λειτουργικότητας του συστήµατος. Κάποιες από τις περιπτώσεις χρήσης είναι πιο σηµαντικές από άλλες, ή ο ρόλος τους είναι κρισιµότερος. Είναι βέβαιο ότι ο σχεδιασµός πρέπει να δώσει προτεραιότητα στις σηµαντικές και κρίσιµες περιπτώσεις χρήσης.

b. Μη λειτουργικές απαιτήσεις (non-functional requirements) Προσδιορίζουν ιδιότητες του συστήµατος και περιορισµούς στους οποίους υπόκειται το σύστηµα. Στις πιο πολλές περιπτώσεις οι µη λειτουργικές απαιτήσεις είναι βασικές αφού η µη ικανοποίηση αυτών αχρηστεύει το σύστηµα. Ως παραδείγµατα µη λειτουργικών απαιτήσεων µπορούµε να αναφέρουµε την απόδοση (performance), τη διαθεσιµότητα (availability), την επεκτασιµότητα (scalability) κ.λπ. Ας πάρουµε για παράδειγµα τη διαθεσιµότητα. Αν οι απαιτήσεις του πελάτη υπαγορεύουν την κατασκευή ενός συστήµατος το οποίο πρέπει να είναι διαθέσιµο 24 ώρες την ηµέρα, 7 ηµέρες την εβδοµάδα, ή όπως αλλιώς λέγεται ένα σύστηµα 24x7, οι αποφάσεις σχεδιασµού είναι τελείως διαφορετικές από την περίπτωση που το σύστηµα µας είναι 10x5 (10 ώρες για 5 ηµέρες την εβδοµάδα). Στην πρώτη περίπτωση πρέπει να σχεδιάσουµε ένα σύστηµα το οποίο εργάζεται αδιάλειπτα, που σηµαίνει ότι πρέπει να συντηρείται ενόσω δουλεύει, ότι πρέπει να έχει διπλές και πιθανόν τριπλές εφεδρείες (redundant), ότι θα πρέπει να είναι ανεκτικό στα σφάλµατα (fault tolerant) κ.λπ. Στη δεύτερη περίπτωση δεν έχουµε τόσο αυστηρούς περιορισµούς.

c. Ευελιξία (flexibility): To σύστηµα πρέπει να είναι δοµηµένο σε τµήµατα (modular). Με τον τρόπο αυτό είναι πιο ανθεκτικό σε αλλαγές ενώ ταυτόχρονα ελέγχεται και πιο εύκολα. Από την άλλη την πλευρά η κατασκευή σε τµήµατα αυξάνει το κόστος κατασκευής.

d. Ο σχεδιασµός πρέπει να λαµβάνει υπόψη του το κόστος και το διαθέσιµο προϋπολογισµό.

e. Το χρονοδιάγραµµα επηρεάζει πολλές φορές σε σηµαντικό βαθµό το σχεδιασµό καθώς ένα σύστηµα θα πρέπει να είναι διαθέσιµο µια συγκεκριµένη ηµεροµηνία. Εποµένως µια καλή αλλά χρονοβόρα λύση πολλές φορές δεν είναι επιθυµητή.

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

81 ΠΛΗ24 – Σχεδιασµός Λογισµικού

Κάθε µια από τις παραπάνω προτεραιότητες επηρεάζει το σχεδιασµό του συστήµατος. ∆υστυχώς, οι περισσότερες από τις παραπάνω κατευθύνσεις σχεδιασµού είναι αλληλοσυγκρουόµενες. Για παράδειγµα, η αύξηση της αξιοπιστίας µειώνει την απόδοση, η βελτίωση της κατάτµησης αυξάνει το κόστος κ.λπ. Συνεπώς όλα τα παραπάνω πρέπει να µελετηθούν προσεκτικά και να αξιολογηθούν µαζί µε τους συµµετέχοντες του έργου.

2. Ανάλυση του συστήµατος σε υποσυστήµατα. Η υποδιαίρεση του προβλήµατος σε µικρότερα προβλήµατα είναι η πιο συνηθισµένη τεχνική σχεδιασµού. Αφού λύσουµε κάθε ένα από τα µικρότερα προβλήµατα, η σύνθεση των λύσεων µας δίνει τη συνολική λύση του προβλήµατος.

3. Ο ορισµός της αρχιτεκτονικής. Από τη στιγµή που έχουµε ορίσει τα υποσυστήµατα που απαρτίζουν το σύστηµα, πρέπει να περιγράψουµε τις σχέσεις µεταξύ τους καθώς και το υλικό (hardware) που είναι απαραίτητο για το κάθε ένα από αυτά.

4. Προσδιορισµός των διεπαφών µεταξύ των υποσυστηµάτων.

5. Επιλογή των συστατικών (components) από τα οποία θα κατασκευασθεί το σύστηµα. Η επιλογή των συστατικών συνίσταται στην επιλογή των κατάλληλων βιβλιοθηκών-πακέτων που θα χρησιµοποιηθούν καθώς και του κατάλληλου υλικού (hardware).

6. Αποφάσεις σχετικά µε το ποια δεδοµένα πρέπει να αποθηκευτούν (object persistence). Είναι προφανές ότι πολλά από τα δεδοµένα που χρειάζεται το σύστηµα πρέπει να είναι διαθέσιµα για µεγαλύτερη διάρκεια. Η απόφαση σχετικά µε το ποια από τα δεδοµένα χρειάζεται να αποθηκευτούν είναι µια από τις πιο σηµαντικές αποφάσεις στη φάση του σχεδιασµού.

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

Για τη δηµιουργία του σχεδιασµού είναι απαραίτητη η επαναληπτική εφαρµογή των παραπάνω βηµάτων. Συνήθως, ένα καλό µοντέλο σχεδιασµού χρειάζεται 2-3 επαναλήψεις για να δηµιουργηθεί.

Στη συγκεκριµένη µελέτη περίπτωσης θα ακολουθήσουµε τα παρακάτω βήµατα:

• Χρήση του διαγράµµατος κλάσεων για την προσθήκη στοιχείων σχεδιασµού

• Μελέτη της αποθήκευσης των δεδοµένων

• Χρήση διαγραµµάτων διάταξης (deployment diagram) για τον ορισµό του υλικού του συστήµατος και της σχέσης µεταξύ των υποσυστηµάτων και του υλικού.

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

82 ΠΛΗ24 – Σχεδιασµός Λογισµικού

• Χρήση διαγραµµάτων συστατικών (component diagram) για την περιγραφή των συστατικών (components), υποσυστηµάτων (subsystems) και επιπέδων (layers) του συστήµατος.

Όπως αναφέραµε και πιο πάνω ο σχεδιασµός του συστήµατος οφείλει να λάβει υπόψη το περιβάλλον υλοποίησης µια και πρέπει να δοθούν τεχνικές λεπτοµέρειες σχετικά µε τη δοµή του συστήµατος. Για την υλοποίηση του συστήµατος ηλεκτρονικού ανθοπωλείου αποφασίσαµε τη χρήση της τεχνολογίας Java και πιο συγκεκριµένα Java 2 Platform Enterprise Edition (J2EE). Εναλλακτικά θα µπορούσε να χρησιµοποιηθεί η τεχνολογία της Microsoft .Net και η γλώσσα προγραµµατισµού C#. Και οι δύο αυτές αρχιτεκτονικές παρέχουν δυνατότητες για την ανάπτυξη κατανεµηµένων συστηµάτων για το internet.

Όχι πολλά χρόνια πριν, οι εφαρµογές φτιάχνονταν ενιαίες, χωρίς να υπάρχει διαχωρισµός µεταξύ της λογικής παρουσίασης (presentation logic layer), της επιχειρηµατικής λογικής (business logic layer) και των δεδοµένων (data layer).

Έτσι όλη η εφαρµογή έτρεχε στον κεντρικό υπολογιστή mainframe. Το επόµενο βήµα ήταν η ανάπτυξη των εφαρµογών χρησιµοποιώντας την αρχιτεκτονική πελάτη εξυπηρετητή (client-server), όπου το user interface και η επιχειρηµατική λογική συνυπήρχαν στον πελάτη, ενώ τα δεδοµένα βρίσκονταν στον εξυπηρετητή.

Σήµερα, το λογισµικό αναπτύσσεται σε πολλαπλά επίπεδα (n-tier). Η εξέλιξη αυτή παρουσιάζεται στην Εικόνα 40.

Τερµατικό

Τερµατικό

Τερµατικό

ΚεντρικόςΥπολογιστής(mainframe)

απλή σύνδεση

Πελάτης(client)

Εξυπηρετητής(server)

Τοπικό δίκτυο(LAN)

ΕξυπηρετητήςWeb server

internet

Internet Browser

Εξυπηρετητήςεφαρµογών

Application server

Βάση∆εδοµένων

Βάση∆εδοµένων

1-tier

3-tier

N-tier

Εικόνα 40: Αρχιτεκτονική πολλών επιπέδων

Η τεχνολογία J2EE συνδυάζει ένα ευρύ φάσµα τεχνικών και API (Application Programming Interface) που απλοποιεί την ανάπτυξη δικτυακών εφαρµογών.

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

83 ΠΛΗ24 – Σχεδιασµός Λογισµικού

Μπορούµε να αναφέρουµε τις τεχνολογίες Enterprise Java Beans (EJB), Servlets, Java Server Pages (JSP) κ.λπ.

Η τεχνολογία J2EE βασίζεται σε ένα πολυεπίπεδο κατανεµηµένο µοντέλο, στο οποίο η λογική χωρίζεται σύµφωνα µε τη λειτουργικότητα. Ένα βασικό χαρακτηριστικό της τεχνολογίας J2EE είναι τα συστατικά (components): ένα σύνολο σχετιζόµενων κλάσεων που υλοποιεί µια συµπεριφορά και είναι ικανό να επικοινωνεί µε άλλα συστατικά. Στον επόµενο πίνακα παρουσιάζονται τα συστατικά του J2EE, το λογικό επίπεδο και το φυσικό επίπεδο στο οποίο ανήκουν.

J2EE συστατικό (component) Λογικό Επίπεδο Φυσικό Επίπεδο HTML σελίδες, applets, java

clients Πελάτη Μηχανή πελάτη

Java Server Pages Java Servlets

Web J2EE Server

Enterprise JavaBeans Επιχειρηµατικό J2EE Server Database EIS Database Server

Η παρούσα µελέτη περίπτωσης θα χρησιµοποιήσει την τεχνολογία Java Server Pages (JSP) για την παρουσίαση, ενώ για την υλοποίηση της επιχειρηµατικής λογικής θα χρησιµοποιηθούν EJB (Enterprise Java Beans)

Μια JSP σελίδα είναι ο συνδυασµός κώδικα Java ο οποίος έχει ενσωµατωθεί µέσα σε ένα HTML έγγραφο. Η βασική ιδέα πίσω από µια JSP σελίδα είναι ότι χρησιµοποιούµε µια γλώσσα σαν την HTML για να παρουσιάσουµε τα στατικά στοιχεία του user interface, ενώ χρησιµοποιούµε ειδικά εντολές µαρκαρίσµατος (tags) για να παράγουµε το δυναµικό περιεχόµενο (δεδοµένα µέσα στη σελίδα). Έτσι, όταν ο browser ζητά µια σελίδα JSP, η αίτηση αυτή στέλνεται στο server, ο οποίος επεξεργάζεται τη σελίδα και συνδυάζοντας το στατικό µε το δυναµικό περιεχόµενο δηµιουργεί την τελική σελίδα και τη στέλνει πίσω στον browser.

Η χρήση των JSP σελίδων επιτρέπει να συντηρούµε εύκολα τον κώδικα σαν html σελίδες και απλοποιεί την ανάπτυξη δικτυακών εφαρµογών. Από την άλλη πλευρά το γεγονός ότι ο κώδικας java συνδυάζεται µε το user interface αναιρεί το διαχωρισµό της λογικής της παρουσίασης από την επιχειρηµατική λογική.

Η µοντελοποίηση µιας JSP σελίδας σε UML είναι κάπως περίπλοκη µια και µια JSP σελίδα είναι ένα υβρίδιο µεταξύ ιστοσελίδας η οποία εκτελείται στον browser και κάποιας λογικής που εκτελεί στον εξυπηρετητή.

Φυσικά µια JSP σελίδα µπορεί να µοντελοποιηθεί σαν µια ενιαία κλάση, αυτό όµως σηµαίνει ότι δεν υπάρχει σαφής διαχωρισµός των αρµοδιοτήτων του πελάτη και του εξυπηρετητή πράγµα που µπορεί να οδηγήσει σε κάποια σύγχυση, µια και δε µπορούµε να γνωρίζουµε που εκτελείται µια διαδικασία: στον πελάτη ή στον εξυπηρετητή;

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

84 ΠΛΗ24 – Σχεδιασµός Λογισµικού

Για την καλύτερη µοντελοποίηση χωρίζουµε την JSP σελίδα σε δύο ιδεατά τµήµατα: τη σελίδα που τρέχει στον πελάτη «client page» και τη σελίδα που τρέχει στον εξυπηρετητή «server page».

«http_servlet»

LoginServlet

Login.jsp«server page»

Banner.jsp Footer.jsp

«include» «include»

«build»Login.jsp

«client page»«screen»

LoginForm.jsp«input form»

«submit»

«forward»

Εικόνα 41: Σχεδιασµός της περίπτωσης χρήσης «Login»

Ας προσπαθήσουµε να κατανοήσουµε το τι κάνει το σύστηµα όταν ο χρήστης προσπαθεί να συνδεθεί µε το σύστηµα (login). Η σελίδα login.jsp είναι η αρχή της περίπτωσης χρήσης που περιέχει τη φόρµα LoginForm.jsp στην οποία ζητάµε από το χρήστη να εισάγει το username/password. Όταν η φόρµα συµπληρώνεται πατάµε το κουµπί «Υποβολή» (submit) και η πληροφορία στέλνεται στον κεντρικό εξυπηρετητή.

Όπως φαίνεται από το σχήµα, η σελίδα κατασκευάζεται στην πλευρά του εξυπηρετητή. Η σελίδα αποτελείται από τα στατικά κοµµάτια, όπως την επικεφαλίδα (banner), το υποσέλιδο (footer) και το κυρίως σώµα LoginServlet το οποίο παρουσιάζει τη δυναµική λειτουργία.

Αντίστοιχα, βλέπουµε ότι ένα τµήµα της σελίδας εκτελείται στον πελάτη και ένα τµήµα στον εξυπηρετητή.

Με αντίστοιχο τρόπο σχεδιάζονται όλες οι σελίδες του συστήµατος.

7.1 Αποθήκευση των δεδοµένων

Η µόνιµη αποθήκευση των δεδοµένων των αντικειµένων είναι κάτι που συναντάµε στις περισσότερες εφαρµογές και συστήµατα. Υπάρχουν αρκετές εναλλακτικές µέθοδοι και τρόποι που µπορούµε να χρησιµοποιήσουµε ανάλογα µε τις εκάστοτε ανάγκες. Στη γενική περίπτωση υπάρχουν τρεις εναλλακτικές περιπτώσεις που µπορούµε να χρησιµοποιήσουµε:

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

85 ΠΛΗ24 – Σχεδιασµός Λογισµικού

• Μετατροπή των αντικειµένων σε σειριακή µορφή (Object serialization)

• Αποθήκευση σε σχεσιακή βάση δεδοµένων

• Αποθήκευση σε αντικειµενοστραφή βάση δεδοµένων

Στην πρώτη περίπτωση µετατρέπουµε τα δεδοµένα των αντικειµένων σε µια σειριακή ακολουθία δεδοµένων (data stream). Αφού γίνει αυτή η µετατροπή στη συνέχεια µπορούµε να χειριστούµε τα δεδοµένα αυτά µε ποικιλία τρόπων – να τα αποθηκεύσουµε σε µια βάση δεδοµένων, σε ένα σειριακό αρχείο, να τα µεταδώσουµε σε ένα δίκτυο.

Η µέθοδος αυτή αποθήκευσης των δεδοµένων έχει το µειονέκτηµα ότι δε µπορεί να εφαρµοσθεί για µεγάλο όγκο δεδοµένων. Φανταστείτε σε ένα σύστηµα όπου έχουµε 10000 πελάτες, να δηµιουργούµε κάθε φορά που το σύστηµα βρίσκεται σε λειτουργία 10000 αντικείµενα πελατών τα οποία όλα βρίσκονται στη µνήµη του υπολογιστή. Προφανώς δεν είναι εφικτό. Όµως, όταν ο όγκος των δεδοµένων είναι µικρός και η εφαρµογή αναφέρεται σε ένα χρήστη, όπου δεν έχουµε πρόβληµα ασφάλειας, είναι η πιο πρακτική και οικονοµική λύση.

Ο πιο δηµοφιλής τρόπος για την αποθήκευση των δεδοµένων είναι η χρήση µιας σχεσιακής βάσης δεδοµένων όπως η ORACLE ή Microsoft SQL Server. Στην περίπτωση αυτή για κάθε κλάση της οποίας θέλουµε να αποθηκεύσουµε τα δεδοµένα δηµιουργούµε ένα πίνακα στη βάση δεδοµένων όπου και τα αποθηκεύουµε. Έτσι για την κλάση του συστήµατος «Πελάτης» δηµιουργούµε στη βάση δεδοµένων τον αντίστοιχο πίνακα. Στη συνέχεια όταν θέλουµε να χρησιµοποιήσουµε τα δεδοµένα δηµιουργούµε το αντικείµενο και στη συνέχεια φορτώνουµε τα δεδοµένα. Η απεικόνιση των αντικειµένων στο σχεσιακό σχήµα δεδοµένων µπορεί να γίνει µε δύο τρόπους:

• µε τη χρήση εργαλείων όπως τα εργαλεία TopLink ή JavaBlend που αυτοµατοποιούν την απεικόνιση και

• µε τη χρήση του API JDBC και την κατά περίπτωση απεικόνιση των αντικειµένων σε πίνακες

Η τρίτη περίπτωση είναι η χρήση αντικειµενοστρεφών βάσεων δεδοµένων (object oriented databases όπου τα αντικείµενα αποθηκεύονται απευθείας. Η χρήση των αντικειµενοστρεφών βάσεων δεδοµένων ήταν αρκετά υποσχόµενη ως τεχνολογία στα πρώτα χρόνια της εισαγωγής των αντικειµενοστρεφών γλωσσών προγραµµατισµού αλλά η χρήση τους έχει σήµερα έχει περιορισθεί µόνο σε ειδικές εφαρµογές.

Μερικοί κανόνες που θα πρέπει να έχουµε υπόψη µας για τη µετατροπή των µοντέλων είναι οι ακόλουθοι:

• Κάθε κλάση απεικονίζεται σε έναν ή περισσότερους πίνακες

• Η σχέση σύνδεσης µεταξύ κλάσεων µε πολλαπλότητα πολλά-προς-πολλά (n-n) απεικονίζεται σε ξεχωριστό πίνακα

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

86 ΠΛΗ24 – Σχεδιασµός Λογισµικού

• Η σχέση σύνδεσης µεταξύ κλάσεων µε πολλαπλότητα ένα-προς-πολλά (1-n) απεικονίζεται είτε σε ξεχωριστό πίνακα, είτε µε τη δηµιουργία ενός εξωτερικού κλειδιού (foreign-key) στον πίνακα της κλάσης που συµµετέχει στη σχέση µε πολλά.

• Η σχέση σύνδεσης µεταξύ κλάσεων µε πολλαπλότητα ένα-προς-ένα (1-1) απεικονίζεται είτε σε ξεχωριστό πίνακα, είτε µε τη δηµιουργία ενός εξωτερικού κλειδιού (foreign-key) σε οποιοδήποτε από τους δύο πίνακες που αντιστοιχούν στις κλάσεις που συµµετέχουν στη σχέση.

• Η σχέση συναρµολόγησης ακολουθεί τους ίδιους κανόνες µε τη σχέση σύνδεσης

• Στη σχέση κληρονοµικότητας τόσο οι πίνακες γενίκευσης όσο και οι πίνακες ειδίκευσης απεικονίζονται σε ξεχωριστούς πίνακες.

Στην Εικόνα 42 παρουσιάζεται η δηµιουργία πινάκων για τις κλάσεις «Πελάτης» και «ΑνΘοπωλείο». Η σχέση 1-n µεταξύ των δύο κλάσεων αναπαρίσταται ως το εξωτερικό κλειδί (foreign key) «Foreign Key» FK_FLShop_Cust ().

«column» name : VARCHAR(255)«column» address: VARCHAR(255) «column» zip : VARCHAR(255)«column» city: VARCHAR(255)«column» country: VARCHAR(255)«column» telHome : VARCHAR(255)«column» telWork : VARCHAR(255)«column» email: VARCHAR(255)«column» userName: CHAR(15)«column» password: CHAR(15)

«Primary Key» PK_Cust()«Index» IX_Cust()

«Table»Customer

«column» name : VARCHAR(255)«column» address: VARCHAR(255) «column» zip : VARCHAR(255)«column» city: VARCHAR(255)«column» country: VARCHAR(255)«column» ownerName : VARCHAR(255)«column» VATNumber : CHAR(15)

«Primary Key» PK_FLShop()«Foreign Key» FK_FLShop_Cust ()

«Table»FLShop

«column» name : VARCHAR(255)«column» address: VARCHAR(255) «column» zip : VARCHAR(255)«column» city: VARCHAR(255)«column» country: VARCHAR(255)«column» ownerName : VARCHAR(255)«column» VATNumber : CHAR(15)

«Primary Key» PK_FLShop()«Foreign Key» FK_FLShop_Cust ()

«Table»FLShop

Εικόνα 42: ∆ηµιουργία πινάκων από τις κλάσεις του συστήµατος

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

87 ΠΛΗ24 – Σχεδιασµός Λογισµικού

7.2 Προσδιορισµός των υποσυστηµάτων

Τα υποσυστήµατα µας επιτρέπουν να οργανώσουµε το µοντέλο σχεδιασµού µε τέτοιο τρόπο ώστε να γίνει πιο εύκολο στη διαχείρισή του. Όπως φαίνεται και στην Εικόνα 43 στη γενική περίπτωση ένα σύστηµα µπορεί να αναλυθεί σε τρία επίπεδα:

• Το επίπεδο της εφαρµογής (application layer). Το επίπεδο της εφαρµογής αναλύεται σε δύο υπο-επίπεδα: το εξειδικευµένο (application specific) και το γενικό (application generic). Τα υποσυστήµατα συνήθως προκύπτουν από την ανάλυση και είναι πιθανό να µην τροποποιηθούν κατά τη διάρκεια του σχεδιασµού. Στη συνέχεια κατά τη διάρκεια της φάσης της υλοποίησης θα αντιστοιχίσουµε τα υποσυστήµατα µε φυσικά αρχεία τα οποία περιέχουν τον κώδικα.

• Το ενδιάµεσο επίπεδο (middleware layer) είναι το επίπεδο το οποίο απεικονίζει και συνδέει την εφαρµογή µε τους φυσικούς πόρους του συστήµατος. Είναι η βάση πάνω στην οποία δοµούµε το σύστηµα, µια και η ανάπτυξη συστηµάτων σήµερα βασίζεται στην ύπαρξη βάσεων δεδοµένων, εργαλεία σχεδιασµού user interface, λογισµικό επικοινωνίας. Η επιλογή του κατάλληλου middleware είναι αυτή που απλοποιεί ή δυσκολεύει την ανάπτυξη του συστήµατος

• Το λογισµικό στο επίπεδο του συστήµατος (system layer) είναι αυτό που διαχειρίζεται τους φυσικούς πόρους του συστήµατος.

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

88 ΠΛΗ24 – Σχεδιασµός Λογισµικού

Εικόνα 43: Οργάνωση υποσυστηµάτων

7.3 ∆ιαγράµµατα διάταξης (deployment diagrams)

Τα διαγράµµατα διάταξης είναι ένα από τα δύο ήδη διαγραµµάτων που χρησιµοποιούνται για την περιγραφή των φυσικών χαρακτηριστικών του συστήµατος. Ένα διάγραµµα διάταξης δείχνει πώς το λογισµικό (software) κατανέµεται πάνω στο υλικό (hardware). Εποµένως, µε τα διαγράµµατα διάταξης µπορούµε να σχεδιάσουµε την τοπολογία του συστήµατος. Επιπλέον, τα διαγράµµατα διάταξης µπορούν να χρησιµοποιηθούν για την καταγραφή της δοµής του συστήµατος κατά τη διάρκεια της λειτουργίας του συστήµατος.

Συνήθως, οι µηχανικοί λογισµικού (software engineers) τις περισσότερες φορές εστιάζουν την προσοχή τους στην ανάλυση και σχεδιασµό του λογισµικού. Όµως, και ειδικά στα µεγάλα συστήµατα, πρέπει να λάβουµε σοβαρά υπόψη τα

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

89 ΠΛΗ24 – Σχεδιασµός Λογισµικού

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

Οι πιο συνηθισµένοι τρόποι χρήσης των διαγραµµάτων είναι: σε κατανεµηµένα συστήµατα (distributed systems), σε δικτυακές εφαρµογές και σε συστήµατα πελάτη-εξυπηρετητή (client-server). Όπως είναι προφανές τα διαγράµµατα διάταξης δεν χρησιµεύουν σε µικρά συστήµατα, ή σε συστήµατα που δουλεύουν µε ένα µόνο υπολογιστή.

Τα διαγράµµατα διάταξης αποτελούνται από κόµβους (nodes) και από σχέσεις-συνδέσεις µεταξύ των κόµβων. Ένας κόµβος µπορεί να χαρακτηρισθεί µε ένα από τα ακόλουθα στερεότυπα:

• «device»: Συσκευή χαρακτηρίζεται ένας κόµβος µε υπολογιστική δυνατότητα.

• «application server»: Εξυπηρετητής εφαρµογών είναι ένας κόµβος που παρέχει µια υπηρεσία σε µια αποµακρυσµένη εφαρµογή.

• «client workstation »: Είναι ο υπολογιστής που χρησιµοποιείται από ένα πελάτη του συστήµατος.

• «mobile device»: Μια φορητή συσκευή αναπαριστά συσκευές όπως φορητούς υπολογιστές, κινητά τηλέφωνα κ.λπ.

• «embedded device»: Αναπαριστά εµπεριεχόµενα συστήµατα. Ένα εµπεριεχόµενο σύστηµα είναι συνδυασµός λογισµικού, υλικού και συσκευών ελέγχου που αλληλεπιδρά µε το φυσικό περιβάλλον

• «execution environment»: Περιβάλλον εκτέλεσης ενός συστήµατος που συµπεριλαµβάνει το υλικό και το λογισµικό εκτέλεσης όπως το λειτουργικό σύστηµα, το ιδεατό περιβάλλον εκτέλεσης της java (Java Virtual Machine) κ.λπ.

• «container»: Είναι ένα στερεότυπο ειδικού τύπου που χρησιµοποιείται στην J2EE για να δείξει την εκτέλεση ενός κοµµατιού κώδικα java (bean) µέσα σε ένα υπολογιστικό πλαίσιο.

Αντίστοιχα µπορούµε να χρησιµοποιήσουµε στερεότυπα για να χαρακτηρίσουµε τις σχέσεις µεταξύ των κόµβων. Αυτά είναι:

• «serial»: Το στερεότυπο αυτό δείχνει τη σύνδεση δύο κόµβων µέσω της σειριακής θύρας των υπολογιστών

• «parallel»: Το στερεότυπο αυτό δείχνει τη σύνδεση δύο κόµβων µέσω της παράλληλης θύρας των υπολογιστών

• «usb»: Το στερεότυπο αυτό δείχνει τη σύνδεση δύο κόµβων µέσω της θύρας USB (Universal Serial Bus) των υπολογιστών. Το είδος αυτό των

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

90 ΠΛΗ24 – Σχεδιασµός Λογισµικού

συνδέσεων χρησιµοποιείται για τη σύνδεση εξωτερικών συσκευών σε υπολογιστές

• «lan»: ∆ύο υπολογιστές ενωµένες σε δίκτυο.

• «internet»: Το στερεότυπο αυτό δείχνει ότι δύο κόµβοι χρησιµοποιούν για την επικοινωνία τους το internet.

Ανάλογα µε το είδος του συστήµατος που φτιάχνουµε µπορούµε να ορίσουµε επιπλέον τα στερεότυπα που θεωρούµε εµείς απαραίτητα, όπως «web server», «database server», «application server». Στην Εικόνα 44 παρουσιάζεται το απλοποιηµένο διάγραµµα διάταξης στο οποίο παρουσιάζονται οι διαθέσιµοι κόµβοι του συστήµατος ηλεκτρονικού ανθοπωλείου.

Εικόνα 44: Απλοποιηµένο διάγραµµα διάταξης

Στην πραγµατικότητα η εικόνα είναι αρκετά πιο πολύπλοκη εφόσον σε ένα ηλεκτρονικό κατάστηµα πρέπει να υπάρχει πρόβλεψη:

• για την ασφάλεια του συστήµατος από εξωτερικές επιθέσεις

• για αυξηµένη διαθεσιµότητα του συστήµατος και

• κατανοµή φόρτου (load balancing) σε περίπτωση αυξηµένων αιτήσεων από πελάτες

Το σύστηµα του ηλεκτρονικού ανθοπωλείου συνδέεται µε δύο εταιρείες παροχής υπηρεσιών internet (internet providers) έτσι ώστε να εξασφαλίσουµε ότι σε περίπτωση διακοπής λόγω µη διαθεσιµότητας του ενός κυκλώµατος, να υπάρχει εναλλακτικό κύκλωµα που µπορεί να χρησιµοποιηθεί. Η σύνδεση στο internet γίνεται µε τη χρήση ενός δροµολογητή (router). Η ύπαρξη δύο εναλλακτικών κυκλωµάτων υπαγορεύει αντίστοιχα τη χρήση δύο routers καθώς και δύο firewall (τοίχου ασφαλείας). Ο firewall αναπαρίσταται στο διάγραµµα ως συσκευή (device) καθώς πρόκειται για εξειδικευµένη συσκευή (appliance). Η χιαστή συνδεσµολογία που χρησιµοποιείται αυξάνει τη διαθεσιµότητα του συστήµατος σε περίπτωση που

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

91 ΠΛΗ24 – Σχεδιασµός Λογισµικού

ένας εκ των δύο firewalls τεθεί εκτός λειτουργίας καθώς επίσης µοιράζει το φόρτο µεταξύ των δύο κυκλωµάτων.

Στη συνέχεια και «πίσω» από τον τοίχο ασφαλείας τοποθετούµε τον web server. Συνήθως, ο web server τοποθετείται µαζί µε τον DNS server. Ένας DNS (Domain Name Server) παρέχει υπηρεσίες ονοµατολογίας δικτύου. Επιπλέον, λόγω του γεγονότος ότι το σύστηµα υποστηρίζει οικονοµικές συναλλαγές όλα τα δεδοµένα πρέπει να διακινούνται κρυπτογραφηµένα. Για το λόγο αυτό πρέπει να χρησιµοποιηθεί το πρωτόκολλο https το οποίο επιτρέπει την κρυπτογραφηµένη διακίνηση δεδοµένων.

Στη συνέχεια τα δεδοµένα δροµολογούνται µέσω ενός δροµολογητή στο εσωτερικό δίκτυο του web site. Πάνω στο εξωτερικό δίκτυο συνδέονται οι δύο εξυπηρετητές εφαρµογών και η βάση δεδοµένων. Η βάση δεδοµένων χρησιµοποιεί τεχνολογία cluster η οποία επιτρέπει την αυτόµατη διανοµή του φόρτου εργασίας στους εξυπηρετητές και την αυξηµένη διαθεσιµότητα του συστήµατος.

Για την αποθήκευση των δεδοµένων χρησιµοποιείται µια εξειδικευµένη συσκευή αποθήκευσης µεγάλης διαθεσιµότητας (availability) SAN (Storage Array Network).

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

92 ΠΛΗ24 – Σχεδιασµός Λογισµικού

<<device>>FIREWALL

<<web server>>APACHEWWW

<<router>>CISCO

<<device>>FIREWALL

<<web server>>APACHEWWW

<<router>>CISCO

DNS

<<router>>CISCO

<<router>>CISCO

LOAD BALANCING

DNS

LOAD BALANCING

FAIL OVER

<<device>>SWITCH SWITCH

UPLINK

<< LAN>>

<<applicationserver>>

ORACLE9iAS

<<device>>switch

<<device>>SAN

CLUSTER

ORACLE 9i RAC

InternetProvider

InternetProvider

<<applicationserver>>

ORACLE9iAS

<<device>>switch

ORACLE9i<<database>>

ORACLE9i<<database>>

<<device>>

<<device>>FIREWALL

<<web server>>APACHEWWW

<<router>>CISCO

<<device>>FIREWALL

<<web server>>APACHEWWW

<<router>>CISCO

DNS

<<router>>CISCO

<<router>>CISCO

LOAD BALANCING

DNS

LOAD BALANCING

FAIL OVER

<<device>>SWITCH SWITCH

UPLINK

<< LAN>>

<<applicationserver>>

ORACLE9iAS

<<device>>switch

<<device>>SAN

CLUSTER

ORACLE 9i RAC

InternetProvider

InternetProvider

<<applicationserver>>

ORACLE9iAS

<<device>>switch

ORACLE9i<<database>>

ORACLE9i<<database>>

<<device>>

Εικόνα 45: Αναλυτικό διάγραµµα διάταξης για ηλεκτρονικό ανθοπωλείο.

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

93 ΠΛΗ24 – Σχεδιασµός Λογισµικού

8 Μοντέλο Υλοποίησης Για την υλοποίηση του συστήµατος ξεκινάµε από τα αποτελέσµατα του σχεδιασµού και υλοποιούµε το σύστηµα χρησιµοποιώντας το περιβάλλον ανάπτυξης που έχουµε επιλέξει. Το µοντέλο της υλοποίησης του συστήµατος παράγεται µετά την εκτέλεση των παρακάτω βηµάτων:

• ∆ηµιουργία και οργάνωση των φυσικών αρχείων που περιέχουν τον πηγαίο κώδικα

• Τον ορισµό των σχέσεων µεταξύ των αρχείων αυτών

• Τον προσδιορισµό του τρόπου µε τον οποίο παράγονται τα εκτελέσιµα αρχεία

• Την οργάνωση του µοναδιαίου ελέγχου (unit test)

• Τη χρήση εργαλείων διοίκησης σχηµατισµών (configuration management)

Είναι προφανές ότι η υλοποίηση του συστήµατος έχει άµεση σχέση µε το περιβάλλον ανάπτυξης και λιγότερη µε τη γλώσσα UML και για αυτό και ο ρόλος της UML ως βασικό εργαλείο είναι περιορισµένος.

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

94 ΠΛΗ24 – Σχεδιασµός Λογισµικού

9 Μοντέλο Ελέγχου Το µοντέλο του ελέγχου περιγράφει πώς τα εκτελέσιµα στοιχεία του µοντέλου υλοποίησης ελέγχονται. Υπάρχουν πολλά και διαφορετικά είδη και φάσεις ελέγχου τα οποία µπορούν να εφαρµοσθούν κατά τη διάρκεια της ανάπτυξης του συστήµατος.

Μπορούµε να αναφέρουµε τέσσερις βασικές φάσεις ελέγχου. Οι φάσεις αυτές είναι:

• Ο µοναδιαίος έλεγχος (unit testing) κατά τη διάρκεια του οποίου ελέγχουµε κατά πόσο το σύστηµα ικανοποιεί τη συµπεριφορά του συστήµατος όπως έχει προδιαγραφεί στο σχεδιασµό. Για παράδειγµα κατά τη διάρκεια του µοναδιαίου ελέγχου ελέγχουµε κατά πόσο το σύστηµα µεταγλωττίζεται (compilation) σωστά, αν τα αντικείµενα µια κλάσης δηµιουργούνται σωστά, αν οι µέθοδοι µια κλάσης επιστρέφουν το σωστό αποτέλεσµα κ.λπ. Ο µοναδιαίος έλεγχος ελέγχει την εσωτερική λειτουργία του συστήµατος και είναι υπευθυνότητα της οµάδας ανάπτυξης λογισµικού.

• Ο έλεγχος ολοκλήρωσης κατά τη διάρκεια του οποίου ελέγχεται το σύστηµα που µόλις έχει πάρει µορφή ως µια οντότητα από τα επιµέρους συστατικά του. Για παράδειγµα, ελέγχεται κατά πόσο τα συστατικά του συστήµατος συνεργάζονται µε το σωστό τρόπο, κατά πόσο τα δεδοµένα αποθηκεύονται σωστά, αν όλα τα υποσυστήµατα ξεκινούν σωστά και αναγνωρίζουν την ύπαρξη των άλλων κ.λπ. Ο έλεγχος ολοκλήρωσης είναι υπευθυνότητα της οµάδας ανάπτυξης λογισµικού.

• Ο έλεγχος αποδοχής από τον ανάδοχο, ο οποίος έχει επικρατήσει να αναφέρεται ως FAT (Factory Acceptance Testing) όπου ελέγχεται η λειτουργικότητα του συστήµατος από ανεξάρτητη οµάδα ελέγχου µε τη συµµετοχή της οµάδας διασφάλισης ποιότητας (Quality Assurance team). Η επιτυχή ολοκλήρωση του ελέγχου FAT σηµατοδοτεί την παράδοση του συστήµατος για εγκατάσταση στους υπολογιστές του πελάτη.

• Ο έλεγχος αποδοχής στον πελάτη, ο οποίος έχει επικρατήσει να αναφέρεται ως SAT (Site Acceptance Testing) όπου ελέγχεται η λειτουργικότητα του συστήµατος αφού πρώτα εγκατασταθεί στο περιβάλλον τελικής λειτουργίας του πελάτη, από ανεξάρτητη οµάδα ελέγχου µε τη συµµετοχή του πελάτη. Η επιτυχή ολοκλήρωση του ελέγχου SAT σηµατοδοτεί την παράδοση του συστήµατος στον πελάτη και την έναρξη λειτουργίας του συστήµατος.

Εκτός των παραπάνω κατηγοριών ελέγχου µπορούµε να εφαρµόζουµε µεµονωµένες κατηγορίες ελέγχου, όπως:

• Έλεγχος εγκατάστασης (installation test). Ελέγχεται ο τρόπος εγκατάστασης του συστήµατος.

• Έλεγχος απόδοσης (performance testing). Για παράδειγµα ελέγχουµε κατά πόσο το σύστηµα µπορεί να εξυπηρετήσει 10 χρήστες, έχοντας απόκριση 3

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

95 ΠΛΗ24 – Σχεδιασµός Λογισµικού

δευτερόλεπτα, όταν αυτοί ταυτόχρονα προσπαθούν να δουν τις λεπτοµέρειες µιας ανθοδέσµης.

• Έλεγχος πίεσης (stress testing). Για παράδειγµα, ποιος είναι ο µέγιστος αριθµός χρηστών που µπορεί να υποστηρίξει ένα σύστηµα χωρίς να µειωθεί η απόδοσή του;

• Έλεγχος όγκου (volume testing). Έστω ότι το σύστηµα δηµιουργεί και αποθηκεύει δεδοµένα σε αρχεία. Ποιο είναι το µέγιστο µέγεθος αρχείου;

• Έλεγχος αξιοπιστίας και διαθεσιµότητας (availability and resilience). Για παράδειγµα εάν υπάρξει διακοπή ρεύµατος, το σύστηµα σταµατά κανονικά; χάνονται δεδοµένα;

• Έλεγχος ασφαλείας (security test). Μπορεί να παρακαµφτούν οι µηχανισµοί ασφαλείας του συστήµατος.

• Έλεγχος ανεξαρτησίας (platform independence test) Για παράδειγµα ελέγχουµε εάν το γραφικό µέρος του συστήµατος παρουσιάζεται σωστά σε όλους τους internet browser ή ελέγχουµε κατά πόσο η εφαρµογή java τρέχει σωστά τόσο σε windows όσο και σε unix περιβάλλον. Το είδος αυτό του ελέγχου έχει µεγάλη σηµασία αν οι χρήστες του συστήµατος είναι άγνωστοι και δεν ξέρουµε επακριβώς το περιβάλλον που χρησιµοποιούν.

• Έλεγχος τεκµηρίωσης. Ελέγχουµε κατά πόσο η τεκµηρίωση που παρέχεται περιγράφει επακριβώς τη λειτουργικότητα του συστήµατος. Για παράδειγµα, διαβάζοντας το εγχειρίδιο χρήσης (user guide) προσπαθούµε να εκτελέσουµε µια λειτουργία του συστήµατος.

Η σχέση των φάσεων ελέγχου και του είδους του ελέγχου που εκτελείται στην κάθε φάση παρουσιάζεται στον παρακάτω πίνακα.

Είδος ελέγχου Μοναδιαίος έλεγχος

Έλεγχος ολοκλήρωσης

FAT SAT

Έλεγχος εγκατάστασης * *

Εξωτερικός έλεγχος λειτουργικότητας (black-box testing)

* * * *

Εσωτερικός έλεγχος λειτουργικότητας (white-box testing)

* * * *

Έλεγχος απόδοσης * *

Έλεγχος πίεσης * *

Έλεγχος αξιοπιστίας και διαθεσιµότητας

* *

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

96 ΠΛΗ24 – Σχεδιασµός Λογισµικού

Είδος ελέγχου Μοναδιαίος έλεγχος

Έλεγχος ολοκλήρωσης

FAT SAT

Έλεγχος ασφαλείας * *

Έλεγχος ανεξαρτησίας * *

Έλεγχος τεκµηρίωσης * *

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

Το µοντέλο ελέγχου αναπτύσσεται ορίζοντας:

• Τις περιπτώσεις ελέγχου (test cases)

• Τις διαδικασίες ελέγχου (test procedures) και

• Τα συστατικά ελέγχου (test components)

Οι περιπτώσεις ελέγχου (test cases) προσδιορίζουν τι πρέπει να ελεγχθεί, και ποιο θα είναι το αποτέλεσµα κάτω από δεδοµένες συνθήκες και γνωρίζοντας τα δεδοµένα εισόδου. Υπάρχουν δύο είδη περιπτώσεων ελέγχου:

• Οι περιπτώσεις ελέγχου που προσδιορίζουν πως να ελέγχουµε µια περίπτωση ελέγχου. Στην περίπτωση αυτή ελέγχουµε την αλληλεπίδραση του χειριστή µε το σύστηµα, το ότι οι συνθήκες της κατάστασης εισόδου και εξόδου ικανοποιούνται, και ότι αν ακολουθήσουµε τα βήµατα της περίπτωσης χρήσης έχουµε το επιθυµητό αποτέλεσµα. Το είδος αυτό των περιπτώσεων ελέγχου υλοποιούν το λεγόµενο έλεγχο µαύρου κουτιού (black box testing).

• Η δεύτερη κατηγορία περιπτώσεων ελέγχου είναι αυτές που ελέγχουν την υλοποίηση της περίπτωσης ελέγχου (use case realization). Σε αυτή την περίπτωση ελέγχουµε τον τρόπο αλληλεπίδρασης των συστατικών (components) και κλάσεων (class). Το είδος αυτό των περιπτώσεων ελέγχου υλοποιούν το λεγόµενο έλεγχο λευκού κουτιού (white box testing).

Οι διαδικασίες ελέγχου (test procedures) συνδυάζουν ένα αριθµό περιπτώσεων ελέγχου µε σκοπό να ελέγξουν κατά πόσο µια επιχειρηµατική διαδικασία (business process) εκτελείται σωστά. Επιπλέον προσδιορίζουν τον τρόπο εκτέλεσης των περιπτώσεων χρήσης, τη σειρά εκτέλεσης αυτών, τις τιµές εισόδου κ.λπ. Για παράδειγµα µπορούµε να έχουµε δυο διαδικασίες ελέγχου στις οποίες εκτελούµε τις ίδιες περιπτώσεις χρήσης µε τη διαφορά ότι δίνουµε διαφορετικές τιµές εισόδου. Η σχέση διαδικασιών ελέγχου µε τις περιπτώσεις ελέγχου είναι πολλά-προς-πολλά: µια περίπτωση χρήσης µπορεί να µετέχει σε πολλές διαδικασίες ελέγχου ενώ αντίστοιχα µια διαδικασία ελέγχου προσδιορίζει την εκτέλεση πολλών περιπτώσεων ελέγχου.

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

97 ΠΛΗ24 – Σχεδιασµός Λογισµικού

Τέλος, τα συστατικά ελέγχου αυτοµατοποιούν την εκτέλεση των διαδικασιών ελέγχου µε τη χρήση αυτοµατοποιηµένων εργαλείων, η ειδικών scripts. Ένα από τα βασικά χαρακτηριστικά του ελέγχου είναι η επαναληπτικότητα (regression testing). Ο έλεγχος του συστήµατος πρέπει να επαναλαµβάνεται, τουλάχιστον η εκτέλεση µέρους των διαδικασιών ελέγχου, όταν αλλάζει ένα κοµµάτι του συστήµατος λόγω κάποιας διόρθωσης, επέκτασης. Το φαινόµενο αυτό είναι εξαιρετικά συνηθισµένο και για το λόγο αυτό τα συστατικά ελέγχου είναι εξαιρετικά χρήσιµα καθώς µειώνουν σηµαντικά το χρόνο που απαιτείται για την επανάληψη του ελέγχου.

Οι περιπτώσεις ελέγχου είναι το βασικό εργαλείο ελέγχου. Όπως ήδη έχουµε πει, µια περίπτωση ελέγχου ορίζει τα δεδοµένα εισόδου, τις συνθήκες εκτέλεσης καθώς και τα αναµενόµενα αποτελέσµατα. Μπορούµε να πούµε λοιπόν ότι µια περίπτωση ελέγχου είναι ένα στιγµιότυπο εκτέλεσης µιας περίπτωσης χρήσης, ένα σενάριο, στο οποίο εκτελούνται τα βήµατα της κυρίας ροής, ή κάποια βήµατα της κυρίας ροής µαζί µε µια εναλλακτική ροή. Ο παραπάνω ορισµός βρίσκεται πολύ κοντά στον ορισµό ενός διαγράµµατος ακολουθίας ή συνεργασίας. Εποµένως, ένας κανόνας είναι να δηµιουργήσουµε µια περίπτωση ελέγχου για κάθε διάγραµµα ακολουθίας που έχουµε. Αν ακολουθήσουµε τον κανόνα αυτό δηµιουργούµε περιπτώσεις ελέγχου white box testing µια και ελέγχουµε το σύστηµα εσωτερικά. Για το λόγο αυτό θα πρέπει να συνδυάσουµε τα διαγράµµατα ακολουθίας µε τις περιπτώσεις χρήσης έτσι ώστε να παράγουµε τις περιπτώσεις ελέγχου.

Για τον προσδιορισµό των περιπτώσεων χρήσης χρησιµοποιείται ο παρακάτω πίνακας.

ΠΡΟΤΥΠΟ ΠΕΡΙΠΤΩΣΗΣ ΕΛΕΓΧΟΥ

Έργο <Το όνοµα του έργου>

Ηµεροµηνία <ΗΗ/ΜΜ/ΧΧ>

Πακέτο εργασίας (work package)

<Το όνοµα του πακέτου εργασίας στη δοµική ανάλυση εργασιών του έργου>

Α/Α Περίπτωσης Ελέγχου

<ΟΝΟΜΑ_ΕΡΓΟΥ.ΥΠΟΣΥΣΤΗΜΑ.TC.ΑΥΞΩΝ_ΑΡΙΘΜΟΣ>

Συστατικό υπό έλεγχο

(component/ unit)

<Το όνοµα του component, υποσυστήµατος υπό έλεγχο>

Σχηµατισµός ελέγχου

(test configuration)

Όνοµα ελεγκτή (tester)

<Όνοµα> Εξαρτήσεις (dependencies) από άλλες περιπτώσεις ελέγχου

Τίτλος Περίπτωσης Χρήσης: <Συνοπτικός τίτλος περίπτωσης ελέγχου>

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

98 ΠΛΗ24 – Σχεδιασµός Λογισµικού

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

∆Ε∆ΟΜΕΝΑ ΕΙΣΟ∆ΟΥ

∆Ε∆ΟΜΕΝΑ ΕΞΟ∆ΟΥ

Ο αύξων αριθµός περίπτωσης ελέγχου δηµιουργείται από τη σύνθεση του ονόµατος του έργου, του υποσυστήµατος και από τον αριθµό της περίπτωσης ελέγχου. Για παράδειγµα, E-FLOWER.UM.TC.01 αναφέρεται στην περίπτωση ελέγχου 01 του υποσυστήµατος user management, του συστήµατος e-flower. Τα αρχικά TC αναφέρονται στον όρο Test Case ώστε να γίνεται αντιδιαστολή µε τις διαδικασίες ελέγχου (Test Procedures - TP)

Ο έλεγχος του συστήµατος µπορεί να γίνεται µε τη χρήση του εξοπλισµού ανάπτυξης του συστήµατος (development environment), είτε σε εξειδικευµένο περιβάλλον ελέγχου, είτε στο τελικό περιβάλλον λειτουργίας (καλό είναι να αποφεύγεται). Το πεδίο της φόρµας «Σχηµατισµός Ελέγχου» καταγράφει σε πιο περιβάλλον γίνεται ο έλεγχος.

Για παράδειγµα για το παράδειγµα µας και για την περίπτωση χρήσης «∆ηµιουργίας Λογαριασµού Πελάτη» έχουµε την παρακάτω περίπτωση ελέγχου:

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

99 ΠΛΗ24 – Σχεδιασµός Λογισµικού

ΠΡΟΤΥΠΟ ΠΕΡΙΠΤΩΣΗΣ ΕΛΕΓΧΟΥ

Έργο E-FLOWER Ηµεροµηνία 15/09/2004

Πακέτο εργασίας WP4 Α/Α Περίπτωσης Ελέγχου

E-FLOWER.UM.02

Συστατικό υπό έλεγχο

UserManagement (UM)

Σχηµατισµός ελέγχου

Ν/Α

Όνοµα ελεγκτή Χ.ΠΑΠΑ∆ΟΠΟΥΛΟΣ Εξαρτήσεις από άλλες περιπτώσεις ελέγχου

E-FLOWER.UM.01

(εξαρτάται από την επιτυχηµένη δηµιουργία λογαριασµού πελάτη)

Τίτλος Περίπτωσης Χρήσης: ∆ηµιουργία λογαριασµού πελάτη

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

Ο ανώνυµος χρήστης δηµιουργεί καινούργιο λογαριασµό πελάτη, αλλά το username που δίνει υπάρχει ήδη στο σύστηµα.

∆Ε∆ΟΜΕΝΑ ΕΙΣΟ∆ΟΥ Τίτλος = Κ.

Όνοµα = Γιώργος

Επίθετο = Παπαδόπουλος

.........

Usename = papadop

∆Ε∆ΟΜΕΝΑ ΕΞΟ∆ΟΥ

Το σύστηµα παρουσιάζει µήνυµα «Το username που δώσατε υπάρχει ήδη στο σύστηµα. Παρακαλώ δώστε διαφορετικό username»

Η εκτέλεση της παραπάνω περίπτωσης ελέγχου έχει ως προϋπόθεση την ύπαρξη ενός λογαριασµού πελάτη µε username “papadop”. Για να µπορέσουµε να περιγράψουµε την προϋπόθεση αυτή χρησιµοποιούµε µια διαδικασία ελέγχου (test procedure). Μια διαδικασία ελέγχου προδιαγράφεται µε τη χρήση του παρακάτω πίνακα.

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

100 ΠΛΗ24 – Σχεδιασµός Λογισµικού

∆ΙΑ∆ΙΚΑΣΙΑ ΕΛΕΓΧΟΥ

Έργο E-FLOWER Ηµεροµηνία 15/09/2004

Πακέτο εργασίας

WP4 Α/Α ∆ιαδικασίας E-FLOWER.UM.TP.01

Συστατικό υπό έλεγχο

UserManagement (UM)

Περιπτώσεις χρήσης που συµµετέχουν

E-FLOWER.UM.TC.01

E-FLOWER.UM.TC.02

E-FLOWER.UM.TC.30

Όνοµα ελεγκτή

Χ.ΠΑΠΑ∆ΟΠΟΥΛΟΣ

Περιγραφή: Έλεγχος µοναδικότητας username στη δηµιουργία λογαριασµού πελάτη

ΑΡΧΗ

Ο χρήστης επιλέγει από την αρχική σελίδα του συστήµατος την επιλογή «∆ηµιουργία Λογαριασµού»

ΕΚΤΕΛΕΣΗ

Εκτελούµε την περίπτωση χρήσης E-FLOWER.UM.TP.01 και δηµιουργούµε το λογαριασµό πελάτη µε username “papadop”

Εκτελούµε την περίπτωση χρήσης E-FLOWER.UM.TP.30 για την αποσύνδεση του πελάτη “papadop” από το σύστηµα

Εκτελούµε την περίπτωση χρήσης E-FLOWER.UM.TP.02 για τη δηµιουργία λογαριασµού πελάτη µε username “papadop”

Σηµείωση: Επανέλαβε τις περιπτώσεις χρήσης χρησιµοποιώντας µικρά και κεφαλαία γράµµατα. Τα µικρά και κεφαλαία γράµµατα είναι διαφορετικά.

ΑΠΟΤΕΛΕΣΜΑΤΑ

Τα αναµενόµενα αποτελέσµατα περιγράφονται στις περιπτώσεις χρήσης.

ΤΕΛΟΣ

Αποσύνδεση του πελάτη “papadop” από το σύστηµα

ΚΛΕΙΣΙΜΟ

∆ιαγραφή του πελάτη “papadop” από το σύστηµα

Συνεπώς προκύπτει, ότι οι περιπτώσεις ελέγχου δεν είναι από µόνες τους ικανές να περιγράψουν πλήρως το µοντέλο ελέγχου αλλά χρειαζόµαστε τις διαδικασίες

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

101 ΠΛΗ24 – Σχεδιασµός Λογισµικού

ελέγχου ώστε να περιγράψουµε τα βήµατα και τις συνθήκες που πρέπει να ισχύουν.

Ανατρέχοντας ξανά στις περιπτώσεις ελέγχου για την περίπτωση χρήσης «∆ηµιουργία Λογαριασµού Πελάτη» είναι προφανές ότι η συγκεκριµένη περίπτωση ελέγχου δεν εξαντλεί όλες τις δυνατές περιπτώσεις. Αν προσπαθήσουµε να συνοψίσουµε τις περιπτώσεις ελέγχου που πρέπει να δηµιουργήσουµε για αυτή την περίπτωση χρήσης τότε έχουµε:

E-FLOWER.UM.TC.01 Επιτυχηµένη ∆ηµιουργία Λογαριασµού Πελάτη

E-FLOWER.UM.TC.02 Username Πελάτη υπάρχει ήδη

E-FLOWER.UM.TC.03 Το password δεν επιβεβαιώθηκε σωστά

E-FLOWER.UM.TC.04 ∆εν συµπληρώθηκαν όλα τα απαραίτητα πεδία (mandatory fields)

E-FLOWER.UM.TC.05 Ο αριθµός της πιστωτικής κάρτας είναι λάθος

E-FLOWER.UM.TC.06 Η ηµεροµηνία της πιστωτικής κάρτας είναι λανθασµένη

E-FLOWER.UM.TC.07 Η πιστωτική κάρτα έχει λήξει

E-FLOWER.UM.TC.08 Το e-mail είναι γραµµένο λάθος

Κατά την εκτέλεση του ελέγχου, τα αποτελέσµατα των ελέγχων καταγράφονται και αξιολογούνται. Ανάλογα µε τη σοβαρότητα των σφαλµάτων αποφασίζουµε για την αποδοχή ή όχι του συστήµατος.

Πιο συγκεκριµένα ο έλεγχος µπορεί να βρει προβλήµατα τριών ειδών:

• στο λογισµικό: το λογισµικό δεν συµπεριφέρεται όπως έχει προδιαγραφεί

• στην τεκµηρίωση: η τεκµηρίωση του συστήµατος δεν είναι ενηµερωµένη ή περιέχει σφάλµατα ή/και

• στο σχεδιασµό: το σύστηµα συµπεριφέρεται σύµφωνα µε τις προδιαγραφές αλλά η συµπεριφορά του δεν είναι επιθυµητή από το χρήστη.

Στον επόµενο πίνακα παρουσιάζονται ειδικές περιπτώσεις για το τι µπορεί να συµβεί:

Σοβαρότητα σφάλµατος

Περιγραφή ∆ιορθωτικές ενέργειες

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

102 ΠΛΗ24 – Σχεδιασµός Λογισµικού

1 Το σύστηµα:

• δε µπορεί να λειτουργήσει γιατί κρεµάει (hangs)

• σταµατάει να λειτουργεί

• έχει απροσδιόριστη συµπεριφορά

• δεν υπάρχει σηµαντικό κοµµάτι της λειτουργικότητας που θα έπρεπε να έχει

Σταµατάµε τον έλεγχο και µόλις η βλάβη επιδιορθωθεί ξεκινάµε ξανά.

2 Το πρόβληµα επιτρέπει στο χρήστη να συνεχίσει τη χρήση αλλά µε µεγάλη δυσκολία. Λόγοι:

• Η λειτουργικότητα υπάρχει αλλά η συµπεριφορά είναι λανθασµένη

• ∆εν υπάρχει εναλλακτικός τρόπος για να επιτύχουµε το σκοπό µας

• Η λειτουργικότητα δεν υπάρχει αλλά µπορούµε να συνεχίσουµε τη δουλειά µας

• Η επικοινωνία µεταξύ δύο υποσυστηµάτων δε λειτουργεί πλήρως

• Η επικοινωνία µε άλλα εξωτερικά συστήµατα δεν είναι δυνατή

3 Μικρό σφάλµα της λειτουργικότητας ή µικρή παράλειψη. Υπάρχει εναλλακτικός τρόπος για να επιτύχουµε το σκοπό µας. Παραδείγµατα:

• Παράληψη ενός πεδίου βοηθητικής πληροφορίας

• Παράλειψη ελέγχου τιµών

1. Συνεχίζουµε τον έλεγχο

2. Καταγράφουµε το συµβάν

3. Μετά το τέλος του ελέγχου διορθώνουµε το σφάλµα

4. Επαναλαµβάνουµε τον έλεγχο

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

103 ΠΛΗ24 – Σχεδιασµός Λογισµικού

• Έλλειψη µηνύµατος 4 Πρόβληµα που δεν επηρεάζει

την επεξεργασία. Παραδείγµατα:

• Κοσµητικό πρόβληµα

• Λάθος µήνυµα

• Ορθογραφικό λάθος

• Ασαφής περιγραφή στην τεκµηρίωση

Η φάση του ελέγχου είναι εξαιρετικά χρονοβόρα µια και ο αριθµός των περιπτώσεων ελέγχου για ένα σύστηµα µπορεί να είναι εξαιρετικά µεγάλος. Σε ένα συνηθισµένο έργο ανάπτυξης λογισµικού συνήθως προϋπολογίζουµε ένα 30% του συνολικού χρόνου για τις διαδικασίες του ελέγχου ενώ σε έργα µε τεχνική ή άλλη δυσκολία φτάνουµε µέχρι και το 50% του συνολικού χρόνου του έργου.

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

104 ΠΛΗ24 – Σχεδιασµός Λογισµικού

10 Συµπεράσµατα Στην παρούσα µελέτη περίπτωσης παρουσιάσαµε την κατασκευή του ηλεκτρονικού καταστήµατος «Λευκός Κρίνος» χρησιµοποιώντας τη γλώσσα UML (Unified Modeling Language) και την Ενοποιηµένη Προσέγγιση (Unified Process). Παρουσιάσαµε τα µοντέλα που πρέπει κάποιος να χτίσει έτσι ώστε να καταλήξει στο τελικό σύστηµα. Παρουσιάσαµε παραδείγµατα για το πως χρησιµοποιείται η γλώσσα UML σε φάση της ανάπτυξης και δώσαµε πρακτικές συµβουλές για την ανάπτυξη των µοντέλων.

Βέβαια σε ένα πραγµατικό έργο, η ανάλυση και ο σχεδιασµός δε γίνονται ακολουθώντας κατά γράµµα τα βήµατα που περιγράψαµε καθώς ο τρόπος λειτουργίας των ατόµων µέσα σε µια πολυµελή οµάδα είναι διαφορετικός. Στην πραγµατικότητα µέσα σε µια οµάδα τα µέλη µιας οµάδας επικοινωνούν, ανταλλάσσουν απόψεις, φτιάχνουν διαγράµµατα στο χαρτί, ενώ σχεδόν πάντα υπάρχει µια ανυποµονησία να αρχίσουµε να προγραµµατίζουµε όσο το δυνατόν πιο νωρίς. Έτσι πολλές φορές θα δούµε µισοτελειωµένα διαγράµµατα ενώ οι προγραµµατιστές έχουν ήδη φτιάξει τον πυρήνα του συστήµατος.

Σε άλλες περιπτώσεις υπάρχουν έργα όπου η φάση της ανάλυσης διαρκεί µήνες ή και χρόνια σε σηµείο που όταν φτάνουµε στο σηµείο να οριστικοποιήσουµε τις περιπτώσεις χρήσης αυτές έχουν αλλάξει.

Είναι πολύ δύσκολο να βρούµε τη χρυσή τοµή µεταξύ των δύο άκρων. Αυτό που πάντα πρέπει να έχουµε στο µυαλό µας είναι ότι το τελικό αποτέλεσµα είναι ο κώδικας και ότι µόνο ο κώδικας που τρέχει µπορεί να αποδείξει ότι ο σχεδιασµός είναι σωστός. Όπως είπε και ο Bertrand Meyer “Bubbles don’t crash” (σε ελεύθερη µετάφραση σηµαίνει ότι ένα διάγραµµα δεν σταµατά να λειτουργεί λόγω σφάλµατος, αλλά µόνο ο κώδικας σταµατά να λειτουργεί). Επιπλέον θα πρέπει πάντα να έχουµε στο νου µας ότι στόχος της µηχανικής λογισµικού είναι να αναπτύξουµε ένα σύστηµα που ικανοποιεί τις ανάγκες των χρηστών και το οποίο χρησιµοποιείται καθηµερινά και όχι ένα τέλειο σύστηµα από άποψη σχεδίασης.

Ορισµένες συµβουλές που µπορούν να βοηθήσουν για την καλύτερη οργάνωση και λειτουργία της οµάδας είναι:

• Σχεδιάζετε πάντα τα διαγράµµατα σε οµάδες των δύο όπου ο ένας εκ των δύο είναι περισσότερο έµπειρος από τον άλλο. Οι άνθρωποι µαθαίνουν γρήγορα ο ένας από τον άλλο.

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

• Επιλέξτε εκ των προτέρων το CASE εργαλείο που θα χρησιµοποιήσετε και εκπαιδεύστε το απαραίτητο προσωπικό σε αυτό.

• Αποφασίστε ποια διαγράµµατα θα χρησιµοποιήσετε σε κάθε φάση και µε ποιο σκοπό. Η UML είναι εξ’ ορισµού ευπροσάρµοστη γλώσσα και σχεδόν

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

105 ΠΛΗ24 – Σχεδιασµός Λογισµικού

πάντα υπάρχουν εναλλακτικοί τρόποι περιγραφής. ∆ηµιουργείστε αν είναι απαραίτητο πρότυπα (templates) και χρησιµοποιείτε τα σχολαστικά.

• ∆ιαλέξτε ένα CASE εργαλείο που να συνεργάζεται απρόσκοπτα µε το εργαλείο ανάπτυξης που χρησιµοποιείτε. Βασική λειτουργικότητα που θα πρέπει να υποστηρίζει το εργαλείο είναι να επιτρέπει reverse engineering (να µπορεί να διαβάζει τον υπάρχων κώδικα και να παράγει τα διαγράµµατα) και να επιτρέπει τον αυτόµατο συγχρονισµό των µοντέλων του σχεδιασµού και της υλοποίησης.

• Σε πολλές περιπτώσεις ο σχεδιασµός των διαγραµµάτων στο χαρτί είναι ευκολότερος και γρηγορότερος από ότι η χρήση του CASE εργαλείου. Αναθέστε σε ένα νεαρό µέλος της οµάδας τη δραστηριότητα της µεταφοράς των διαγραµµάτων από το χαρτί στο CASE εργαλείο. Ένα πλεονέκτηµα αυτής της τακτικής είναι η οµοιοµορφία στο σχεδιασµό των διαγραµµάτων.

• ∆ηµιουργείστε κανάλια επικοινωνίας µέσα στην οµάδα, µε συναντήσεις, λίστες συζήτησης κ.λπ. Χρησιµοποιείστε τις συναντήσεις για την επίλυση και κατανόηση δύσκολων σηµείων παρά για διαδικαστικά θέµατα. Ψηφιοποιείστε, άµεσα τα διαγράµµατα που παράγονται κατά τη διάρκεια των συναντήσεων.

• ∆ηµιουργείστε πρωτότυπα του συστήµατος από τον πρώτο µήνα του έργου. Τα πρωτότυπα οπτικοποιούν το σύστηµα το οποίο έχει πολύ θετικά αποτελέσµατα.

• Χρησιµοποιείστε πίνακες για να αναρτήσετε τα βασικά διαγράµµατα του συστήµατος. Αν είναι δυνατόν όλα τα διαγράµµατα του συστήµατος να είναι ανηρτηµένα σε προσιτό σηµείο κάντε το χωρίς δισταγµό.

Κλείνοντας θα πρέπει να τονίσουµε ότι η γνώση της γλώσσας UML είναι ιδιαίτερα σηµαντική για την ανάπτυξη συστηµάτων λογισµικού µια και η γλώσσα αυτή αποτελεί το διεθνές στάνταρτ σε παγκόσµιο επίπεδο.

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

106 ΠΛΗ24 – Σχεδιασµός Λογισµικού

11 Βιβλιογραφία 1. Grady Booch, Object-Oriented Analysis and Design with Applications, Second

Edition. Addison-Wesley 1994.

2. Grady Booch, James Rumbaugh, Ivar Jacobson: The Unified Modeling Language User Guide. Addison Wesley Longman, 1999.

3. Martin Fowler, UML Distilled, Addison-Wesley, 3rd Edition 2004.

4. Ivar Jacobson, Magnus Christerson, Patrick Jonsson, Gunnar Overgaard, Object-Oriented Software Engineering: A Use Case Driven Approach. Addison-Wesley 1992.

5. Doug Rosenberg, Kendall Scott, Applying Use Case Driven Object Modelling with UML, Addison-Wesley, 2001.

6. James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy, William Lorenzen: Object-Oriented Modeling and Design. Prentice Hall 1991.

7. Enricos Manassis, Practical Software Engineering: Analysis and Design for the .NET Platform, Addisson-Wesley, 2003.

8. Michael Jesse Chonoles and James A. Schardt, UML 2 for Dummies, Hungry Minds, 2003

9. Alistair Cockburn, Writing Effective Use Cases, Addisson-Wesley, 2000.

10. Scott Ambler, The Elements of UML Style, Cambridge University Press, 2003.

11. Shari Lawrence Pfleeger, Τεχνολογία Λογισµικού, Θεωρία και Πράξη, Τόµος 1, Εκδόσεις Κλειδάριθµος, 2003.

12. Ivar Jacobson, Maria Ericsson, Agneta Jacobson, The object Advantage, ACM Press, Addison-Wesley, 1995.

13. Floyd Marinescu, EJB Design Patterns, John Willey & Sons, Inc., 2002.

14. Ed Roman, Mastering Enterprise Java Beans, John Willey & Sons, Inc., 1999.

15. Khawar Zamn Ahmed, Cary Umrysh, Developing Enterprise Java Applications with J2EE and UML, Addison-Wesley, 2002.

16. ORACLE 9iAS TopLink Getting Started, Release 2 (9.0.3), 2002.