P. 1
pli42b

pli42b

5.0

|Views: 486|Likes:
Published by api-3777834

More info:

Published by: api-3777834 on Oct 16, 2008
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

03/18/2014

pdf

text

original

Eγκυροποίηση Λογισµικού

Σηµείωση
Το ΕΑΠ είναι υπεύθυνο για την επιµέλεια έκδοσης και την ανάπτυξη των κειµένων σύµφωνα µε τη Μεθο-
δολογία της εξ Αποστάσεως Εκπαίδευσης. Για την επιστηµονική αρτιότητα και πληρότητα των συγγραµ-
µάτων την αποκλειστική ευθύνη φέρουν οι συγγραφείς, κριτικοί αναγνώστες και ακαδηµαϊκοί υπεύθυνοι
που ανέλαβαν το έργο αυτό.
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 1
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 2
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
Σχολή Θετικών Επιστηµών και Τεχνολογίας
Πρόγραµµα Σπουδών
ΠΛHPOΦOPIKH
Θεµατική Ενότητα
EI∆IKA ΘEMATA TEXNOΛOΓIAΣ ΛOΓIΣMIKOY
Τόµος B'
Eγκυροποίηση Λογισµικού
ΑΧΙΛΛΕΑΣ ΚΑΜΕΑΣ
∆ρ Mηχανικός H/Y & Πληροφορικής
ΠATPA 2003
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 3
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
Σχολή Θετικών Επιστηµών και Τεχνολογίας
Πρόγραµµα Σπουδών
ΠΛHPOΦOPIKH
Θεµατική Ενότητα
EI∆IKA ΘEMATA TEXNOΛOΓIAΣ ΛOΓIΣMIKOY
Τόµος B'
Eγκυροποίηση Λογισµικού
Συγγραφή
AXIΛΛEAΣ KAMEAΣ
∆ρ Mηχανικός H/Y & Πληροφορικής
Κριτική Ανάγνωση
ΠΑΝΑΓΙΩΤΗΣ ΠΙΝΤΕΛΑΣ
Kαθηγητής Tµήµατος Mαθηµατικών
Πανεπιστηµίου Πατρών
Ακαδηµαϊκός Υπεύθυνος για την επιστηµονική επιµέλεια του τόµου
ΠΑΝΑΓΙΩΤΗΣ ΠΙΝΤΕΛΑΣ
Kαθηγητής Tµήµατος Mαθηµατικών
Πανεπιστηµίου Πατρών
Επιµέλεια στη µέθοδο της εκπαίδευσης από απόσταση
IΩANNHΣ KOYTΣONIKOΣ
Γλωσσική Επιµέλεια
KΩNΣTANTINOΣ KΛAMΠANIΣTHΣ
Τεχνική Επιµέλεια
EΣΠI EK∆OTIKH E.Π.E.
Συντονισµός ανάπτυξης εκπαιδευτικού υλικού και γενική επιµέλεια των εκδόσεων
ΟΜΑ∆Α ΕΚΤΕΛΕΣΗΣ ΕΡΓΟΥ ΕΑΠ / 1997–2003
ISBN: 960–538–221–0
Kωδικός Έκδοσης: ΠΛH 42/2
Copyright 2003 για την Ελλάδα και όλο τον κόσµο
ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ
Οδός Παπαφλέσσα & Υψηλάντη, 26222 Πάτρα – Τηλ: 2610 314094, 314206 Φαξ: 2610 317244
Σύµφωνα µε το Ν. 2121/1993, απαγορεύεται η συνολική ή αποσπασµατική αναδηµοσίευση του βιβλίου αυτού
ή η αναπαραγωγή του µε οποιοδήποτε µέσο χωρίς την άδεια του εκδότη.
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 4
¶ÂÚȯfiÌÂÓ·
Πρόλογος ............................................................................................................................................................................. 11
K ∂ º ∞ § ∞ π √ 1
EÈÛ·ÁˆÁ‹
Σκοπός, Προσδοκώµενα αποτελέσµατα, Έννοιες κλειδιά,
Eισαγωγικές παρατηρήσεις .................................................................................................................................... 15
1.1 Φύση και θέση των δραστηριοτήτων E & E ........................................................................ 17
1.2 Kατηγοριοποίηση τεχνικών E & E ............................................................................................... 20
Σύνοψη ................................................................................................................................................................................... 23
Bιβλιογραφία ..................................................................................................................................................................... 24
K ∂ º ∞ § ∞ π √ 2
™Ù·ÙÈΤ˜ T¯ÓÈΤ˜ E & E
Σκοπός, Προσδοκώµενα αποτελέσµατα, Έννοιες κλειδιά,
Eισαγωγικές παρατηρήσεις .................................................................................................................................... 25
2.1 Στατική ανάλυση .......................................................................................................................................... 27
2.2 Aναθεωρήσεις ................................................................................................................................................. 30
2.2.1 Oδηγίες διεξαγωγής αναθεωρήσεων ............................................................................. 31
2.3 Περιηγήσεις ....................................................................................................................................................... 32
2.4 Eπισκοπήσεις ................................................................................................................................................... 33
Σύνοψη ................................................................................................................................................................................... 37
Bιβλιογραφία ..................................................................................................................................................................... 38
K ∂ º ∞ § ∞ π √ 3
¢˘Ó·ÌÈΤ˜ T¯ÓÈΤ˜ E & E
Σκοπός, Προσδοκώµενα αποτελέσµατα, Έννοιες κλειδιά,
Eισαγωγικές παρατηρήσεις .................................................................................................................................... 39
3.1 Συµβολική εκτέλεση .................................................................................................................................. 40
3.2 Προσοµοίωση .................................................................................................................................................. 45
3.3 Aνάλυση ευαισθησίας .............................................................................................................................. 47
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 5
6 E ° ∫ À ƒ √¶√π ∏™ ∏ § √° π ™ ªπ ∫ √À
Σύνοψη ................................................................................................................................................................................... 52
Bιβλιογραφία ..................................................................................................................................................................... 52
K ∂ º ∞ § ∞ π √ 4
T¯ÓÈΤ˜ ۯ‰›·Û˘ ÙˆÓ ÂÚÈÙÒÛÂˆÓ ÂϤÁ¯Ô˘ ÏÔÁÈÛÌÈÎÔ‡
Σκοπός, Προσδοκώµενα αποτελέσµατα, Έννοιες κλειδιά,
Eισαγωγικές παρατηρήσεις .................................................................................................................................... 53
4.1 Oργάνωση των δραστηριοτήτων ελέγχου λογισµικού ................................................. 56
4.2 Στρατηγικές ελέγχου του λογισµικού ......................................................................................... 58
4.2.1 Προδιαγραφές µε εξισώσεις και σχέσεις ................................................................. 61
4.2.2 Πότε τελειώνει ο έλεγχος; .................................................................................................... 61
4.3 Σχεδίαση περιπτώσεων ελέγχου ...................................................................................................... 62
4.4 Tεχνικές ελέγχου αδιαφανούς κουτιού
Σκοπός, Προσδοκώµενα αποτελέσµατα, Έννοιες κλειδιά,
Eισαγωγικές παρατηρήσεις .................................................................................................................................... 64
4.4.1 ∆ιαµέριση σε κλάσεις ισοδυναµίας .............................................................................. 65
4.4.2 Aνάλυση οριακών τιµών ........................................................................................................ 68
4.4.3 Γραφήµατα αιτίου–αποτελέσµατος .............................................................................. 71
4.4.4 Συγκριτικές δοκιµές ................................................................................................................... 74
4.5 Tεχνικές ελέγχου διαφανούς κουτιού
Σκοπός, Προσδοκώµενα αποτελέσµατα, Έννοιες κλειδιά,
Eισαγωγικές παρατηρήσεις .................................................................................................................................... 77
4.5.1 ∆οκιµή βασικών µονοπατιών ............................................................................................ 78
4.5.2 ∆οκιµή δοµών επανάληψης ................................................................................................. 87
4.6 Tεχνικές ελέγχου διεπαφών
Σκοπός, Προσδοκώµενα αποτελέσµατα, Έννοιες κλειδιά,
Eισαγωγικές παρατηρήσεις .................................................................................................................................... 93
4.6.1 Σφάλµατα διεπαφών .................................................................................................................. 94
4.6.2 Σχεδίαση περιπτώσεων ελέγχου διεπαφών ............................................................ 94
Σύνοψη ................................................................................................................................................................................... 98
Bιβλιογραφία ..................................................................................................................................................................... 98
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 6
K ∂ º ∞ § ∞ π √ 5
¶Ú·ÎÙÈ΋ ÂÊ·ÚÌÔÁ‹ ÙˆÓ ‰Ú·ÛÙËÚÈÔÙ‹ÙˆÓ ÂϤÁ¯Ô˘:
¢ÔÎÈ̤˜ ÏÔÁÈÛÌÈÎÔ‡
Σκοπός, Προσδοκώµενα αποτελέσµατα, Έννοιες κλειδιά,
Eισαγωγικές παρατηρήσεις .................................................................................................................................... 99
5.1 ∆οκιµές µονάδων ...................................................................................................................................... 102
5.5.1 ∆οκιµή επαφών ............................................................................................................................. 103
5.5.2 ∆οκιµή τοπικών δοµών δεδοµένων ............................................................................. 103
5.1.3 ∆οκιµή µονοπατιών εκτέλεσης ....................................................................................... 104
5.1.4 ∆οκιµή του κώδικα διαχείρισης σφαλµάτων ...................................................... 104
5.1.5 ∆οκιµή οριακών συνθηκών ................................................................................................ 105
5.1.6 Oδηγοί και στελέχη ................................................................................................................... 105
5.2 ∆οκιµές συγκρότησης ........................................................................................................................... 107
5.2.1 ∆οκιµή συγκρότησης από πάνω προς τα κάτω ................................................. 108
5.2.2 ∆οκιµή συγκρότησης από κάτω προς τα πάνω ................................................. 110
5.2.3 Συνδυασµός ...................................................................................................................................... 112
5.3 ∆οκιµές επικύρωσης ............................................................................................................................... 116
5.3.1 ∆οκιµή Άλφα και Bήτα .......................................................................................................... 117
5.4 ∆οκιµές συστήµατος ............................................................................................................................... 118
5.4.1 ∆οκιµή εκφάνσεων εκτέλεσης ......................................................................................... 118
5.4.2 ∆οκιµή αντοχής ............................................................................................................................. 119
5.4.3 ∆οκιµή ανάκαµψης .................................................................................................................... 120
5.4.4 ∆οκιµή ασφάλειας ...................................................................................................................... 120
5.4.5 ∆οκιµή απόδοσης ........................................................................................................................ 120
Σύνοψη ................................................................................................................................................................................ 123
Bιβλιογραφία .................................................................................................................................................................. 124
7 ¶E P I E X OME NA
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 7
K ∂ º ∞ § ∞ π √ 6
EÎÛÊ·ÏÌ¿ÙˆÛË
Σκοπός, Προσδοκώµενα αποτελέσµατα, Έννοιες κλειδιά,
Eισαγωγικές παρατηρήσεις ................................................................................................................................ 125
6.1 H διαδικασία της εκσφαλµάτωσης ............................................................................................. 127
6.2 Mεθοδολογίες εκσφαλµάτωσης .................................................................................................... 129
6.2.1 Kατά µέτωπο επίθεση ........................................................................................................... 129
6.2.2 Oπισθοδρόµηση ......................................................................................................................... 133
6.2.3 Eξάλειψη του αιτίου ............................................................................................................... 133
6.2.4 Bοήθεια! ............................................................................................................................................. 136
6.3 Eκκαθάριση σφαλµάτων ..................................................................................................................... 144
Σύνοψη ................................................................................................................................................................................ 146
Bιβλιογραφία .................................................................................................................................................................. 147
K ∂ º ∞ § ∞ π √ 7
EÍ·ÛÊ¿ÏÈÛË ÔÈfiÙËÙ·˜ Î·È ·ÍÈÔÈÛÙ›·
Σκοπός, Προσδοκώµενα αποτελέσµατα, Έννοιες κλειδιά,
Eισαγωγικές παρατηρήσεις ................................................................................................................................ 149
7.1 Παράγοντες ποιότητας και µετρικές ......................................................................................... 152
7.2 ∆ιαδικασία εξασφάλισης ποιότητας .......................................................................................... 159
7.2.1 Oµάδα εξασφάλισης της ποιότητας ........................................................................... 160
7.2.2 Tο σύστηµα διαχείρισης της ποιότητας ................................................................. 162
7.2.3 Πλάνο EΠΛ .................................................................................................................................... 163
7.3 Tυπικές Tεχνικές EΠΛ ......................................................................................................................... 165
7.3.1 Aπόδειξη ορθότητας ............................................................................................................... 165
7.3.2 Στατιστική EΠΛ ....................................................................................................................... 165
7.3.3 H διαδικασία του «καθαρού δωµατίου» ............................................................... 166
7.4 Aξιοπιστία λογισµικού ......................................................................................................................... 166
7.4.1 ∆ιακοπή λειτουργίας και επιδιόρθωση ................................................................... 167
7.4.2 Mοντέλα αξιοπιστίας λογισµικού ............................................................................... 168
Σύνοψη ................................................................................................................................................................................ 171
8 E ° ∫ À ƒ √¶√π ∏™ ∏ § √° π ™ ªπ ∫ √À
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 8
Bιβλιογραφία .................................................................................................................................................................. 172
K ∂ º ∞ § ∞ π √ 8
EÊ·ÚÌÔÁ‹ ÙˆÓ ‰È·‰ÈηÛÈÒÓ ÂϤÁ¯Ô˘
Σκοπός, Προσδοκώµενα αποτελέσµατα, Έννοιες κλειδιά,
Eισαγωγικές παρατηρήσεις ................................................................................................................................ 173
8.1 Tυπική επαλήθευση ................................................................................................................................ 176
8.2 Aυτοµατοποιηµένα εργαλεία ελέγχου .................................................................................... 181
8.2.1 Eργαλεία στατικής ανάλυσης ......................................................................................... 181
8.2.2 Eργαλεία δυναµικής ανάλυσης ..................................................................................... 182
8.2.3 Eργαλεία διαχείρισης της διαδικασίας ελέγχου .............................................. 182
8.2.4 Άλλα εργαλεία ............................................................................................................................. 183
8.3 Eλεγξιµότητα λογισµικού .................................................................................................................. 183
8.3.1 Aπώλεια πληροφορίας .......................................................................................................... 185
8.3.2 Bελτίωση της σχεδίασης ..................................................................................................... 186
8.4 Λογισµικό χωρίς ελαττώµατα ........................................................................................................ 186
8.4.1 Προδιαγραφές .............................................................................................................................. 188
8.4.2 Σχεδίαση αυξητικής ανάπτυξης .................................................................................... 188
8.4.3 Σχεδίαση και επαλήθευση ................................................................................................. 188
8.4.4 Πιστοποίηση ποιότητας ....................................................................................................... 189
8.4.5 Aνάδραση ........................................................................................................................................ 190
Σύνοψη ................................................................................................................................................................................ 192
Bιβλιογραφία .................................................................................................................................................................. 192
Eπίλογος ............................................................................................................................................................................. 193
Aπαντήσεις Aσκήσεων Aυτοαξιολόγησης ............................................................................................... 195
Γενική Bιβλιογραφία ............................................................................................................................................... 209
Bιβλιογραφία για περαιτέρω µελέτη ........................................................................................................... 210
Γλωσσάρι .......................................................................................................................................................................... 214
9 ¶E P I E X OME NA
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 9
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 10
¶ÚfiÏÔÁÔ˜
Στους Γονείς µου …
Τα βιβλία έχουν µια σηµαντική διαφορά από τους υπολογιστές: δεν αρνούνται να δια-
βαστούν. Ποτέ ένα βιβλίο δε θα σας εµποδίσει να γυρίσετε το εξώφυλλό του (ή οποι-
αδήποτε σελίδα του), ούτε πρόκειται να κλείσει απότοµα την ώρα που το διαβάζετε.
Αντίθετα, ένα λογισµικό µπορεί πολύ καλά να «κλείσει» απότοµα την ώρα που το
χρησιµοποιείτε, αφού σας ανακοινώσει ότι «This program has performed an illegal
operation and will be shut down», παίρνοντας µαζί του στη λήθη τη δουλειά της
τελευταίας ώρας. Όσο απεγνωσµένα κι αν προσπαθείτε να σώσετε τη δουλειά σας
(µάλλον επειδή πιστέψατε εκείνο το µήνυµα που έλεγε «Press this button to save your
work»), το λογισµικό µοιάζει να έπαθε αµνησία. ∆εν αναγνωρίζει τον ιδιοκτήτη του.
Το βιβλίο αυτό απευθύνεται σε όσους έχουν πολλάκις φτάσει στα όρια της αντοχής
(και της υγείας) τους, καθώς χρησιµοποιούν διαδεδοµένα (ή λιγότερο διαδεδοµένα)
λογισµικά. ∆ιαβάστε το όλοι εσείς που αναρωτιέστε γιατί ένα τόσο προηγµένο τεχνο-
λογικά προϊόν, όπως είναι το λογισµικό των υπολογιστών, είναι τόσο λιγότερο αξιό-
πιστο από ένα απλό βιβλίο. Αν ανήκετε σε αυτούς που θεωρούν αυτή τη συµπερι-
φορά ως αποτέλεσµα του δυναµικού χαρακτήρα και της πολυπλοκότητας του λογι-
σµικού, θα χάσετε την ώρα σας µαζί του. ∆υο λόγια µόνο, πριν το κλείσετε: γνωρί-
ζετε αυτό που λένε για τα αυτοκίνητα: εάν οι εταιρείες λογισµικού αρχίσουν να κατα-
σκευάζουν αυτοκίνητα, τότε (α) για κάποιο περίεργο λόγο, η µηχανή θα σβήνει χωρίς
προειδοποίηση, καθώς το αυτοκίνητο κινείται κανονικά και (β) κάθε φορά που σβή-
νει η µηχανή, ο οδηγός θα πρέπει να κατεβαίνει, να επανεγκαθιστά τη µηχανή και
να ξεκινά πάλι το αυτοκίνητο!
Ωραία, είστε ακόµη µαζί µας. Θα σας πω λοιπόν τη µαγική λέξη: ποιότητα. Τι είναι
η ποιότητα; Αυτό που λείπει από το σηµερινό λογισµικό. Γιατί; Επειδή η εξασφάλι-
ση της ποιότητας του λογισµικού κοστίζει τόσο που σίγουρα θα βγάλει εκτός προϋ-
πολογισµού το χρονοδιάγραµµα ανάπτυξης (το οποίο έτσι κι αλλιώς βγαίνει εκτός
προϋπολογισµού). Τι θα έπρεπε να είχε γίνει; Να ενσωµατωθούν δραστηριότητες
εγκυροποίησης καθ’ όλη τη διάρκεια του κύκλου ζωής (δηλαδή, ακόµη µεγαλύτερη
επιβάρυνση του προϋπολογισµού – θα αστειεύεστε).
Λοιπόν, το βιβλίο αυτό θα σας πείσει για το αντίθετο: η σωστή σχεδίαση και η έγκαι-
ρη ενσωµάτωση δραστηριοτήτων εγκυροποίησης ουσιαστικά µειώνουν τον προϋ-
πολογισµό ενός έργου ανάπτυξης λογισµικού. Και το κυριότερο, ο συνεχής (στατι-
κός και δυναµικός) έλεγχος βελτιώνει την ποιότητά του. Να πώς:
Στο Kεφάλαιο 1περιγράφονται οι δραστηριότητες Eπαλήθευσης και Eπικύρωσης, οι
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 11
1 2 E ° ∫ À ƒ √¶√π ∏™ ∏ § √° π ™ ªπ ∫ √À
οποίες συνθέτουν τη Φάση Ε&Ε. Οι δραστηριότητες αυτές τοποθετούνται µέσα στον
κύκλο ανάπτυξης λογισµικού (µοντέλο V) και τεκµηριώνεται η σηµασία τους. Έπει-
τα, παρουσιάζονται οι κατηγορίες των τεχνικών Ε&Ε, µε τις οποίες θα ασχοληθού-
µε ουσιαστικά στο υπόλοιπο βιβλίο.
Στο Kεφάλαιο 2 παρουσιάζονται οι στατικές τεχνικές Ε&Ε, οι οποίες εφαρµόζονται
κατά τη διάρκεια της σχεδίασης και της κωδικοποίησης του λογισµικού. Το βασικό
τους χαρακτηριστικό είναι ότι για την ανακάλυψη σφαλµάτων δεν απαιτείται η εκτέ-
λεση του κώδικα του λογισµικού. Σε ξεχωριστές ενότητες παρουσιάζονται η στατι-
κή ανάλυση και τα δύο είδη αναθεωρήσεων, η περιήγηση και η επισκόπηση. Αυτές
οι δύο τελευταίες τεχνικές είναι πολύ σηµαντικές και αρκετά διαδεδοµένες, καθώς
είναι φθηνές στην εφαρµογή και αποτελεσµατικές.
Από το Kεφάλαιο 3 αρχίζει η παρουσίαση των δυναµικών τεχνικών Ε&Ε, οι οποίες
εντοπίζουν τα σφάλµατα που παρουσιάζονται κατά την εκτέλεση του κώδικα του
λογισµικού. Το σύντοµο αυτό κεφάλαιο παρουσιάζει τη συµβολική εκτέλεση και την
προσοµοίωση του λογισµικού, δύο τεχνικές στις οποίες είτε χρησιµοποιούνται συµ-
βολικά (όχι πραγµατικά) δεδοµένα, είτε προσοµοιώνεται µέρος της λειτουργικότη-
τας του λογισµικού, η οποία ίσως δεν έχει ακόµη υλοποιηθεί. Στην τελευταία ενό-
τητα παρουσιάζεται µια πρόσφατη σχετικά τεχνική, η ανάλυση ευαισθησίας, η οποία
αποτελεί τµήµα µιας γενικότερης προσέγγισης που πρεσβεύει τη σχεδίαση του λογι-
σµικού ώστε να διευκολύνεται ο έλεγχός του.
Τα επόµενα τρία κεφάλαια αποτελούν το πιο σηµαντικό τµήµα του τόµου. Στο Kεφά-
λαιο 4 παρουσιάζεται ο έλεγχος λογισµικού, η περισσότερο διαδεδοµένη δυναµική
τεχνική Ε&Ε. Το κεφάλαιο επικεντρώνεται στις τρεις διαδεδοµένες µεθοδολογίες
σχεδίασης περιπτώσεων ελέγχου, τη µεθοδολογία δοµικού ελέγχου, τη µεθοδολογία
λειτουργικού ελέγχου και τη µεθοδολογία ελέγχου διεπαφών. Οι περισσότερο δια-
δεδοµένες τεχνικές της κάθε µεθοδολογίας παρουσιάζονται αναλυτικά µέσα από ένα
πλήθος παραδειγµάτων, δραστηριοτήτων και ασκήσεων.
Στο Kεφάλαιο 5 συζητούµε για την πρακτική εφαρµογή των µεθοδολογιών αυτών
στην υλοποίηση µιας στρατηγικής ελέγχου του λογισµικού. Στα πλαίσια της αυξη-
τικής συγκρότησης του λογισµικού παρουσιάζονται οι δραστηριότητες δοκιµής µονά-
δων, δοκιµής συγκρότησης, δοκιµής επικύρωσης και δοκιµής συστήµατος, οι οποί-
ες συγκροτούν µια ολοκληρωµένη στρατηγική ελέγχου.
Το Kεφάλαιο 6 ασχολείται µε την εκσφαλµάτωση, τη δραστηριότητα που ακολου-
θεί έναν επιτυχηµένο έλεγχο (επιτυχηµένος είναι ο έλεγχος που αποκάλυψε σφάλ-
µατα!). Οι τρεις γενικές κατηγορίες τεχνικών εκσφαλµάτωσης (κατά µέτωπο επίθε-
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 12
ση, οπισθοδρόµηση, εξάλειψη του αιτίου) παρουσιάζονται αναλυτικά, ενώ στο τέλος
αναφέρεται και ο έλεγχος παλινδρόµησης, ο οποίος ακολουθεί τις δραστηριότητες
εκσφαλµάτωσης και διόρθωσης του λογισµικού.
Στο Kεφάλαιο 7 επιχειρείται η τοποθέτηση των δραστηριοτήτων Ε&Ε µέσα στο
γενικότερο πλαίσιο της εξασφάλισης της ποιότητας του λογισµικού και παρουσιά-
ζεται η σηµασία της ανάπτυξης ποιοτικού λογισµικού. Η ποιότητα του λογισµικού
ορίζεται σαν η συνισταµένη ενός συνόλου παραγόντων, οι οποίοι είναι δυνατό να
αποτιµηθούν µε ένα σύνολο µετρικών. Ο πιο σηµαντικός από τους παράγοντες ποι-
ότητας, η αξιοπιστία του λογισµικού, αναλύεται σε ξεχωριστή ενότητα.
Στο τελευταίο κεφάλαιο του τόµου παρουσιάζονται τέσσερα ζητήµατα που άπτονται
πτυχών της πρακτικής εφαρµογής των διαδικασιών ελέγχου: η τυπική επαλήθευση
του λογισµικού, η αυτοµατοποιηµένη ανάπτυξη και επαλήθευση του λογισµικού, η
έννοια της ελεγξιµότητας και η διαδικασία του «καθαρού δωµατίου». Αν και καθε-
µία από τις τέσσερις ενότητες έχει τη δική της βαρύτητα, περισσότερο σηµαντικές
θεωρώ την πρώτη και την τελευταία.
Το Kεφάλαιο 1 είναι εισαγωγικό στις έννοιες της εγκυροποίησης λογισµικού. Το
Kεφάλαιο 2 αναφέρεται στις στατικές τεχνικές Ε&Ε και είναι αυτόνοµο. Τα Kεφά-
λαια 3 έως 6 αναφέρονται στις δυναµικές τεχνικές Ε&Ε, µε το τρίτο κεφάλαιο να
είναι το λιγότερο σηµαντικό. Εάν τα κεφάλαια αυτά στοχεύουν στη µετάδοση γνώ-
σεων και (κυρίως τα Kεφάλαια 2, 4, 5) δεξιοτήτων, το Kεφάλαιο 7 στοχεύει να σας
πείσει να συνδέσετε άρρηκτα την έννοια «ποιότητα» µε το λογισµικό που σχεδιάζε-
τε ή αναπτύσσετε. Από την άποψη αυτή, πρόκειται για ένα σηµαντικό κεφάλαιο, στο
οποίο «κορυφώνεται» η ανάλυση των δραστηριοτήτων Ε&Ε, που άρχισε στο πρώτο
κεφάλαιο. Το Kεφάλαιο 8 λειτουργεί ενηµερωτικά γύρω από τις πλέον σύγχρονες
προσεγγίσεις στην εφαρµογή διαδικασιών Ε&Ε. Καθεµία από τις ενότητες που περι-
λαµβάνει θα µπορούσε να αποτελεί ξεχωριστό τόµο.
Η προσέγγιση που ακολούθησα στον τόµο αυτό είναι µάλλον αφαιρετική. Προσπά-
θησα να τοποθετήσω τις δραστηριότητες Ε&Ε στο συνολικό πλαίσιο που ορίζει ο
κύκλος ανάπτυξης λογισµικού και να τις παρουσιάσω ως αναπόσπαστες δραστη-
ριότητες της Τεχνολογίας Λογισµικού (όπως και είναι). Το πλεονέκτηµα είναι ότι θα
έχετε µια ξεκάθαρη αντίληψη του «πότε», «πού» και «γιατί» θα χρειαστεί να εφαρ-
µόσετε δραστηριότητες Ε&Ε, ενώ θα µπορείτε µε λίγη προσπάθεια να βρείτε «ποια
δραστηριότητα είναι κατάλληλη για ποιο σκοπό». Αυτή η προσέγγιση διευκολύνει
και το συνολικό στόχο του τόµου, που είναι να σας βοηθήσει να αντιληφθείτε την
αξία της εξασφάλισης της ποιότητας του λογισµικού, ώστε να πεισθείτε να ανα-
1 3 ¶P O§ O° O™
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 13
1 4 E ° ∫ À ƒ √¶√π ∏™ ∏ § √° π ™ ªπ ∫ √À
πτύσσετε ποιοτικό και µόνο λογισµικό. Το µειονέκτηµα είναι ότι στην περιορισµέ-
νη έκταση του τόµου δεν είναι δυνατό να καλυφθούν σε λεπτοµέρεια πρακτικά και
ειδικά ζητήµατα που ανακύπτουν κατά την εφαρµογή των δραστηριοτήτων Ε&Ε.
Απάντηση σε αυτά µπορείτε να βρείτε σε κάποιο από τα βιβλία που σας προτείνω
στο τέλος του τόµου. Όπως θα διαπιστώσετε, η υπάρχουσα βιβλιογραφία είναι ογκώ-
δης και η προτεινόµενη εκτενής, κάτι που αποτελεί ένδειξη της βαρύτητας του αντι-
κειµένου. Στην προτεινόµενη βιβλιογραφία προσπάθησα να καλύψω τόσο γενικότε-
ρα ζητήµατα και αφαιρετικές (εισαγωγικές) προσεγγίσεις στο θέµα (όπως αυτή που
ακολούθησα στον παρόντα τόµο), όσο και επιµέρους θέµατα, σύγχρονες προσεγγί-
σεις και ανακύπτοντα ζητήµατα σε ένα τόσο δυναµικό χώρο όπως είναι η εγκυρο-
ποίηση του λογισµικού.
Οφείλω να σας προειδοποιήσω ότι, µελετώντας τον τόµο, θα συναντήσετε αρκετές
νέες και δύσκολες έννοιες. Θα χρειαστεί επιµονή και προσπάθεια από την πλευρά σας
για να τις «κατακτήσετε». Ο τρόπος µε τον οποίο είναι δοµηµένο το υλικό του τόµου
θα σας βοηθήσει στην προσπάθειά σας, αλλά µην ξεχνάτε: ο βαθµός στον οποίο θα
ωφεληθείτε από την ανάγνωση του βιβλίου εξαρτάται κυρίως από εσάς τους ίδιους.
Στον τόµο (και ειδικότερα στα Kεφάλαια 2 και 4 – 6) περιέχεται πλήθος παραδειγ-
µάτων, ασκήσεων αυτοαξιολόγησης και δραστηριοτήτων. Οι απαντήσεις στις δρα-
στηριότητες δίνονται µέσα στο ίδιο το κείµενο, ενώ οι ασκήσεις αυτοαξιολόγησης
απαντώνται συγκεντρωτικά στο τέλος του τόµου. Σας συνιστώ να δοκιµάσετε (και
µακάρι να καταφέρετε) όλες τις ασκήσεις και τις δραστηριότητες. Οι δεξιότητες
εγκυροποίησης αποκτώνται µόνο µέσα από την πρακτική εφαρµογή και η επίλυση
ασκήσεων αποτελεί ένα καλό σηµείο εκκίνησης. Από την άλλη πλευρά, επιλύοντας
τις ασκήσεις θα µπορέσετε να αυτοαξιολογείτε την πρόοδό σας και να εντοπίζετε
έγκαιρα τα σηµεία που σας δυσκολεύουν, ώστε να µπορέσετε να τα αντιµετωπίσετε
(µε τη βοήθεια του διδάσκοντα, αν χρειαστεί). Σηµαντικό βοήθηµα στη µελέτη σας
πιστεύω ότι θα αποδειχθεί και το γλωσσάριο όρων που παρατίθεται στο τέλος του
τόµου. Μη διστάσετε να ανατρέξετε σε αυτό όταν συναντήσετε µια δύσκολη έννοια.
Εντάξει. Βιάζεστε να δείτε πώς θα µπορέσετε να παράγετε ποιοτικό λογισµικό. Να
µη σας καθυστερώ άλλο, λοιπόν …
A.Kαµέας
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 14
EÈÛ·ÁˆÁ‹
™Ùfi¯ÔÈ
Στο πρώτο κεφάλαιο του βιβλίου θα εισαχθούν οι έννοιες που σχετίζονται µε την εγκυ-
ροποίηση του λογισµικού µε στόχο να τεκµηριωθεί η σηµασία των δραστηριοτήτων
που αυτή περιλαµβάνει. Επειτα, θα ενηµερωθείτε σφαιρικά για τις διάφορες τεχνικές
εγκυροποίησης που εφαρµόζονται σήµερα και οι οποίες θα αποτελέσουν τον κορµό
της θεµατικής ενότητας.
¶ÚÔÛ‰ÔÎÒÌÂÓ· ·ÔÙÂϤÛÌ·Ù·
Όταν θα έχετε µελετήσει αυτό το εισαγωγικό κεφάλαιο, θα µπορείτε να:
• διαχωρίσετε τις δραστηριότητες επαλήθευσης και επικύρωσης,
• εξηγήσετε τη θέση των διαδικασιών εγκυροποίησης στον κύκλο ζωής λογισµικού,
• αναφέρετε τουλάχιστον δύο θετικές και δύο αρνητικές επιπτώσεις της εφαρµογής
διαδικασιών εγκυροποίησης στον κύκλο ανάπτυξης λογισµικού,
• διαχωρίσετε τις δύο κύριες κατηγορίες τεχνικών εγκυροποίησης,
• διαχωρίσετε τις δύο κύριες κατηγορίες µη – τυπικών τεχνικών εγκυροποίησης.
ŒÓÓÔȘ ÎÏÂȉȿ
1
∫ ∂ º ∞ § ∞ π √
• Eγκυροποίηση,
• επαλήθευση,
• επικύρωση,
• φάση Ε&Ε,
• µοντέλο V,
• σχέδιο Ε&Ε,
• τυπικές τεχνικές Ε&Ε,
• µη – τυπικές τεχνικές Ε&Ε,
• στατικές τεχνικές Ε&Ε,
• δυναµικές τεχνικές Ε&Ε,
• σφάλµατα.
∂ÈÛ·ÁˆÁÈΤ˜ ·Ú·ÙËÚ‹ÛÂȘ
Η εγκυροποίηση του λογισµικού περιλαµβάνει ένα σύνολο διαδικασιών, οι οποίες
έχουν όλες τους ίδιους στόχους: να ελέγξουν την ορθότητα και την εγκυρότητα του
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 15
1 6 K E ºA § A I O 1 : E I ™ A ° ø° H
λογισµικού και να βελτιώσουν την ποιότητα των προϊόντων ενός έργου ανάπτυξης
λογισµικού. Επειδή ένα τέτοιο έργο παράγει διάφορα ενδιάµεσα προϊόντα πριν τον
τελικό κώδικα του λογισµικού, διάφορες διαδικασίες εγκυροποίησης εκτελούνται
συνεχώς καθ’ όλη τη διάρκεια του κύκλου ζωής του λογισµικού.
Οι διαδικασίες εγκυροποίησης οµαδοποιούνται σε δύο ξεχωριστές δραστηριότητες:
την επαλήθευση και την επικύρωση. Επειδή και οι δύο αυτές δραστηριότητες είναι
απαραίτητες, συχνά η φάση εγκυροποίησης του λογισµικού αναφέρεται ως «φάση
Ε&Ε», δηλαδή «φάση Eπαλήθευσης & Eπικύρωσης».
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 16
1.1 º‡ÛË Î·È ı¤ÛË ÙˆÓ ‰Ú·ÛÙËÚÈÔÙ‹ÙˆÓ ∂&∂
Οι δύο δραστηριότητες της φάσης Ε&Ε διαφέρουν µεταξύ τους τόσο ως προς το
περιεχόµενο, όσο και ως προς το χρόνο εφαρµογής τους κατά τη διάρκεια του κύκλου
ανάπτυξης του λογισµικού. Οι διαδικασίες επαλήθευσης (verification) εφαρµόζο-
νται συνεχώς κατά τη διάρκεια του κύκλου ανάπτυξης και ορίζονται ως «οι διαδι-
κασίες αξιολόγησης ενός συστήµατος ή ενός τµήµατος κάποιου συστήµατος µε
στόχο να προσδιοριστεί κατά πόσο τα προϊόντα µιας συγκεκριµένης φάσης ανάπτυ-
ξης ικανοποιούν τις προδιαγραφές που είχαν τεθεί στην αρχή της φάσης» (ΙΕΕΕ[90]).
Αντίθετα, οι διαδικασίες επικύρωσης (validation) εκτελούνται στο τέλος της διαδι-
κασίας ανάπτυξης και ελέγχουν κατά πόσο το λογισµικό που αναπτύχθηκε συµφω-
νεί µε τις αρχικές απαιτήσεις και τις προσδοκίες αυτών που θα το χρησιµοποιήσουν.
1 7 1 . 1 ºÀ ™ ∏ ∫ ∞ π £∂ ™ ∏ ∆ ø¡ ¢ ƒ∞ ™ ∆ ∏ƒ π √∆ ∏∆ ø¡ ∂ & ∂
Ενας εύκολος τρόπος για να µην συγχέετε τις δραστηριότητες της φάσης Ε&Ε είναι
να θυµάστε ότι οι αντίστοιχες διαδικασίες απαντούν στις εξής ερωτήσεις
(Boehm[81]):
• Επαλήθευση: αναπτύσσουµε σωστά το λογισµικό;
• Επικύρωση: αναπτύξαµε το σωστό λογισµικό;
Συχνά λέγεται ότι η εγκυροποίηση δεν αποτελεί µια ξεχωριστή φάση, αλλά έναν
τρόπο σκέψης (concept), ο οποίος πρέπει να διέπει κάθε φάση του κύκλου ζωής
του λογισµικού. Λαµβάνοντας υπόψη όσα έχουν αναφερθεί έως τώρα, προσπαθή-
στε να περιγράψετε και να τεκµηριώσετε τη θέση σας απέναντι στον ισχυρισµό
Στην ιδανική περίπτωση, ένα πρόγραµµα λογισµικού που παραδίδεται προς χρήση
δεν θα πρέπει να παρουσιάζει σφάλµατα εκτέλεσης. Στην πράξη, αυτό είναι σχεδόν
αδύνατο, ιδιαίτερα όταν πρόκειται για ένα µεγάλο σύστηµα λογισµικού. Επιπλέον,
όσο πολλές δοκιµές εκτέλεσης (testing) του κώδικα ενός προγράµµατος (source
program code) και αν γίνουν, δεν αρκούν για να αποδείξουν ότι το λογισµικό δεν
έχει λάθη. H εµπειρία έχει δείξει ότι ο αριθµός των λαθών που αποµένουν σε ένα
πρόγραµµα είναι ανάλογος µε τον αριθµό των λαθών που έχουν ήδη ανακαλυφθεί
και διορθωθεί. Αυτό σηµαίνει ότι είναι καλύτερο να εµπιστευόµαστε ένα λογισµικό
στο οποίο βρέθηκαν λίγα λάθη µετά από εξαντλητικές δοκιµές, παρά ένα λογισµικό
το οποίο έχει διορθωθεί πολλές φορές.
¢Ú·ÛÙËÚÈfiÙËÙ· 1.1
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 17
1 8 K E ºA § A I O 1 : E I ™ A ° ø° H
Η ενσωµάτωση διαδικασιών Ε&Ε σε µια φάση του κύκλου ζωής επιπλέον των δρα-
στηριοτήτων ανάπτυξης της φάσης οδηγεί στην αύξηση του κόστους εκτέλεσης της
φάσης και της πολυπλοκότητας του χρονοδιαγράµµατος. Επιπλέον, περιορίζονται
και οι διαθέσιµοι για την ανάπτυξη του λογισµικού πόροι, αφού προσωπικό, εξο-
πλισµός, χρόνος και χρήµατα θα πρέπει να διατεθούν στις δραστηριότητες που υλο-
ποιούν τις διαδικασίες Ε&Ε.
Όµως, η σωστή και έγκαιρη εφαρµογή δραστηριοτήτων Ε&Ε συντελεί στον εντοπι-
σµό λαθών και παρανοήσεων νωρίς στον κύκλο ανάπτυξης. Έτσι, µειώνεται τελικά
το συνολικό κόστος του έργου, αφού διευκολύνονται (και συνεπώς κοστίζουν λιγό-
τερο) οι τελικές διαδικασίες ελέγχου και αποδοχής, βελτιώνονται οι δυνατότητες δια-
χείρισης του έργου και µειώνεται ο κίνδυνος αποτυχίας.
Ταυτόχρονα, βελτιώνονται η ποιότητα και η αξιοπιστία του λογισµικού. Για παρά-
δειγµα, η τελευταία ορίζεται ως «η πιθανότητα λειτουργίας του λογισµικού χωρίς
αστοχία για ένα καθορισµένο χρονικό διάστηµα, σε ένα καθορισµένο περιβάλλον
και για ένα καθορισµένο σκοπό». Από την άλλη πλευρά, οι αναθεωρήσεις αποτε-
λούν τη βασική µέθοδο ελέγχου της ποιότητας µιας διαδικασίας ανάπτυξης λογι-
σµικού ή ενός προϊόντος λογισµικού. Περισσότερα για τη σχέση των δραστηριοτή-
των Ε&Ε µε τη διασφάλιση της αξιοπιστίας και της ποιότητας του λογισµικού θα
δούµε στα τελευταία κεφάλαια του βιβλίου.
Σε αναγνώριση της σηµασίας των δραστηριοτήτων εγκυροποίησης, το διαδεδοµένο
µοντέλο κύκλου ζωής «καταρράκτη» επεκτάθηκε συσχετίζοντας κάθε φάση ανάπτυ-
ξης µε µια δραστηριότητα Ε&Ε. Το µοντέλο ανάπτυξης λογισµικού που προέκυψε
είναι γνωστό ως «µοντέλο V» και απεικονίζεται στο Σχήµα 1.1. Σύµφωνα µε αυτό, οι
δραστηριότητες Ε&Ε εκτελούνται πάνω σε συγκεκριµένα σχέδια δοκιµών (test plans),
τα οποία προκύπτουν µε βάση τα εξαγόµενα των αντίστοιχων φάσεων ανάπτυξης.
αυτό. (Υπόδειξη: Θα χρειαστεί να καταγράψετε τι αποφέρουν και τι κοστίζουν οι
διαδικασίες Ε&Ε στον πελάτη – τελικό χρήστη του λογισµικού, στο διαχειριστή –
ανάδοχο του έργου ανάπτυξης του λογισµικού και στα διάφορα µέλη της οµάδας
ανάπτυξης. Καλό είναι να καταγράψετε και το κόστος των ενδεχόµενων προβλη-
µάτων που θα οφείλονται στην απουσία δραστηριοτήτων Ε&Ε).
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 18
Οι δραστηριότητες Ε&Ε συνήθως ανατίθενται στην οµάδα διασφάλισης της ποιό-
τητας του λογισµικού, η οποία εξετάζει τα προϊόντα του έργου προσπαθώντας να
διασφαλίσει ότι οι µέθοδοι και τα εργαλεία που χρησιµοποιήθηκαν για τη σχεδίαση
και ανάπτυξη του λογισµικού είναι αποδεκτά και οδηγούν τελικά στην παράδοση
έγκυρου λογισµικού.
Ο έλεγχος των µονάδων του λογισµικού (software program units) γίνεται από τους
προγραµµατιστές που αναπτύσσουν το λογισµικό, συνήθως χωρίς οργανωµένο σχέ-
διο. Όταν όµως πολλές µονάδες συνδυαστούν σε ένα τµήµα ή υποσύστηµα, τότε ο
έλεγχος γίνεται από ανεξάρτητη οµάδα (π.χ. οµάδα διασφάλισης ποιότητας) µε βάση
το «σχέδιο δοκιµής συγκρότησης υποσυστήµατος» που έχει ήδη συντεθεί κατά τις
φάσεις σχεδίασης του συστήµατος. Αντίστοιχα, η συγκρότηση (integration – ανα-
φέρεται και ως «ολοκλήρωση») του συστήµατος γίνεται µε βάση το «σχέδιο δοκι-
µής συγκρότησης συστήµατος» που έχει συντεθεί κατά την παραγωγή των προδια-
γραφών, ενώ ο τελικός έλεγχος πριν την παράδοση του συστήµατος γίνεται µε βάση
το «σχέδιο δοκιµής αποδοχής» που έχει ήδη συντεθεί κατά τον ορισµό των απαιτή-
σεων από το σύστηµα.
Οι έλεγχοι και οι άλλες δραστηριότητες του µοντέλου V θα παρουσιαστούν αναλυ-
τικότερα στο Kεφάλαιο 4. Προς το παρόν σηµειώνουµε ότι απαιτείται η σύνταξη
ενός συνολικού «σχεδίου Ε&Ε», στο οποίο θα περιγράφονται επακριβώς οι διαδι-
κασίες Ε&Ε που θα εκτελεστούν στα πλαίσια του έργου. Το σχέδιο Ε&Ε θεωρείται
τόσο σπουδαίο, ώστε η δοµή του να περιγράφεται από ένα πρότυπο του ΙΕΕΕ
(ΙΕΕΕ[86]), το οποίο απαιτεί για κάθε φάση Ε&Ε να ορίζονται τα εξής:
• Εργασίες Ε&Ε
• Μέθοδοι και κριτήρια
1 9 1 . 1 ºÀ ™ ∏ ∫ ∞ π £∂ ™ ∏ ∆ ø¡ ¢ ƒ∞ ™ ∆ ∏ƒ π √∆ ∏∆ ø¡ ∂ & ∂
™¯‹Ì· 1.1
Το µοντέλο V
Προδιαγραφές 
Απαιτήσεων
Προδιαγραφές 
Συστήµατος
Σχεδίαση 
Συστήµατος
Λεπτοµερής 
Σχεδίαση
Χρήση 
Συστήµατος
Έλεγχος 
Αποδοχής 
Συστήµατος
Έλεγχος 
Συγκρότησης 
Συστήµατος
Έλεγχος 
Συγκρότησης 
Υποσυστηµάτων
Κωδικοποίηση 
Έλεγχος Μονάδων 
και Τµηµάτων
Σχέδιο ∆οκιµής 
Αποδοχής 
Συστήµατος
Σχέδιο ∆οκιµής 
Συγκρότησης 
Συστήµατος
Σχέδιο ∆οκιµής 
Συγκρότησης 
Υποσυστηµάτων
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 19
2 0 K E ºA § A I O 1 : E I ™ A ° ø° H
• Είσοδοι και έξοδοι
• Χρονοπρογραµµατισµός
• Πόροι
• Κίνδυνοι και παραδοχές
• Ρόλοι και υπευθυνότητες
1.2 ∫·ÙËÁÔÚÈÔÔ›ËÛË ÙÂÓÈÎÒÓ ∂&∂
Έως τώρα έχει προταθεί µια πληθώρα τεχνικών Ε&Ε, κάτι που δείχνει πόσο σηµα-
ντικές είναι αυτές οι δραστηριότητες στον κύκλο ανάπτυξης λογισµικού. Οι τεχνι-
κές αυτές χωρίζονται σε δύο µεγάλες κατηγορίες (Σχήµα 1.2) (Σκορδαλάκης[91]):
• στις τυπικές τεχνικές Ε&Ε (formal techniques), οι οποίες παράγουν µια αυστη-
ρή µαθηµατική απόδειξη ότι το λογισµικό λειτουργεί σύµφωνα µε τις προδια-
γραφές του. Το αποτέλεσµα µιας τέτοιας διαδικασίας είναι συνήθως δυαδικό: το
δοκιµαζόµενο τµήµα κώδικα είτε ικανοποιεί τις προδιαγραφές του, είτε όχι
• στις µη τυπικές τεχνικές Ε&Ε (informal techniques), οι οποίες δεν µπορούν να
αποδείξουν την ορθότητα του λογισµικoύ, αλλά επικεντρώνονται στην ανακά-
λυψη και αντιµετώπιση όσο το δυνατόν περισσότερων λαθών. Οι τεχνικές αυτές
εφαρµόζονται επαναληπτικά µέχρι να αποκτηθεί ένας βαθµός εµπιστοσύνης στον
ισχυρισµό ότι το λογισµικό είναι σωστό και δεν έχει λάθη (δηλαδή, το λογισµι-
κό είναι «µάλλον ορθό»).
Οι µη τυπικές τεχνικές Ε&Ε είναι πιο φθηνές και εύκολες στην εφαρµογή, γι’ αυτό
και είναι οι περισσότερο διαδεδοµένες. Ανάλογα µε τη µέθοδο ανακάλυψης λαθών
που χρησιµοποιούν διακρίνονται σε:
• στατικές τεχνικές Ε&Ε (static techniques), οι οποίες ασχολούνται µε την εξέ-
ταση διαφόρων αναπαραστάσεων του συστήµατος λογισµικού. Τέτοιες αναπα-
ραστάσεις είναι οι προδιαγραφές, το σχέδιο του συστήµατος και βεβαίως ο κώδι-
κας των προγραµµάτων. Η εφαρµογή των τεχνικών αυτών µπορεί να αυτοµατο-
ποιηθεί όταν η υπό εξέταση αναπαράσταση έχει περιγραφεί µε κάποιο συντα-
κτικά αυστηρό τρόπο
• δυναµικές τεχνικές Ε&Ε (dynamic techniques), µε τις οποίες εξετάζεται ο τρό-
πος υλοποίησης και λειτουργίας ενός λογισµικού. Η πιο σηµαντική δυναµική
τεχνική είναι ο έλεγχος του προγράµµατος (program testing).
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 20
Εκτός από τη στατική ανάλυση των περιγραφών του συστήµατος λογισµικού, στις
στατικές τεχνικές περιλαµβάνονται και οι αναθεωρήσεις (reviews) του λογισµικού.
Κατά τη διάρκεια µιας αναθεώρησης, η οµάδα ανάπτυξης του λογισµικού περιγρά-
φει τον τρόπο σχεδίασης, λειτουργίας ή υλοποίησης του λογισµικού σε µια οµάδα
ελεγκτών, µε στόχο να ανακαλυφθούν λάθη κατά τη διάρκεια της συζήτησης.
Οι στατικές τεχνικές είναι πολύ αποτελεσµατικές στην ανακάλυψη λαθών, ενώ η
εφαρµογή τους είναι σχετικά φθηνή σε σχέση µε τις δυναµικές τεχνικές. Για τους
λόγους αυτούς, στο παρελθόν έχει προταθεί η αντικατάσταση των δυναµικών τεχνι-
κών από στατικές τεχνικές. Αυτό όµως είναι αδύνατο, αφού οι στατικές τεχνικές µπο-
ρούν να ελέγξουν µόνο το βαθµό συµµόρφωσης του λογισµικού στις αρχικές προ-
διαγραφές του, αλλά δεν µπορούν να αποδείξουν ότι το λογισµικό είναι λειτουργι-
κά χρήσιµο. Έτσι, αν και οι στατικές τεχνικές Ε&Ε διαδίδονται όλο και περισσότε-
ρο, ο έλεγχος του λογισµικού είναι ακόµη η πιο σηµαντική τεχνική Ε&Ε.
Κατά τον έλεγχο του προγράµµατος, αυτό εκτελείται δοκιµαστικά χρησιµοποιώντας
δεδοµένα που προσοµοιάζουν όσο το δυνατό καλύτερα τα αληθινά δεδοµένα που θα
χρησιµοποιεί το λογισµικό, όταν παραδοθεί προς χρήση. Από τη µελέτη των πραγ-
µατικών εξόδων του προγράµµατος (και τη σύγκριση µε τις αναµενόµενες εξόδους)
είναι δυνατή η ανακάλυψη λαθών ή παραλείψεων.
Ανάλογα µε τα δεδοµένα που χρησιµοποιούνται για την εξέταση του λογισµικού µπο-
ρεί να έχουµε στατιστικό έλεγχο (όπου εξετάζεται η συµπεριφορά του λογισµικού
µε βάση τη συχνότητα των πραγµατικών ενεργειών ή δεδοµένων χρήστη) και έλεγ-
2 1 1 . 1 ºÀ ™ ∏ ∫ ∞ π £∂ ™ ∏ ∆ ø¡ ¢ ƒ∞ ™ ∆ ∏ƒ π √∆ ∏∆ ø¡ ∂ & ∂
™¯‹Ì· 1.2
Κατηγοριοποίηση
των τεχνικών
Ε&Ε
Τεχνικές E&E
Tυπικές Μη Τυπικές
Στατικές ∆υναµικές
Στατική 
Ανάλυση
Αναθεωρήσεις
Συµβολική 
Εκτέλεση
Έλεγχος 
Αποδοχής
Επισκοπήσεις Περιηγήσεις
Έλεγχος 
Μονάδων
Έλεγχος
Έλεγχος 
Συγκρότησης 
Υποσυστηµατών
Έλεγχος 
Συγκρότησης 
Συστήµατος
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 21
2 2 K E ºA § A I O 1 : E I ™ A ° ø° H
χο για την ανακάλυψη ελαττωµάτων (όπου επιχειρείται η ανακάλυψη τµηµάτων του
λογισµικού που δεν ανταποκρίνονται στις αρχικές προδιαγραφές).
Ανάλογα µε το µέγεθος του τµήµατος του συστήµατος λογισµικού όπου εφαρµόζε-
ται η εξέταση έχουµε τον έλεγχο µονάδων, τον έλεγχο τµηµάτων, τον έλεγχο υποσυ-
στηµάτων, τον έλεγχο συστήµατος και τον έλεγχο αποδοχής. Οι τεχνικές αυτές ελέγ-
χουν διαδοχικά όλο και µεγαλύτερα τµήµατα του συστήµατος, πριν καταλήξουν στον
έλεγχο όλου του συστήµατος στο πραγµατικό περιβάλλον όπου αυτό θα λειτουργεί.
Σφάλµατα (bugs, faults) εµφανίζονται όταν κάποια αναπαράσταση του λογισµικού
είναι ατελής, ασυνεπής ή λανθασµένη. Τρεις µεγάλες κατηγορίες σφαλµάτων είναι
οι εξής:
• Tα σφάλµατα προδιαγραφών, τα οποία οφείλονται σε λανθασµένη διατύπωση
των αναγκών του χρήστη, σε αδυναµία περιγραφής λειτουργικών απαιτήσεων,
σε ασυνέπειες ανάµεσα στις προδιαγραφές κ.ά.
• Tα σφάλµατα σχεδίασης, τα οποία δείχνουν αδυναµία µετάφρασης των προ-
διαγραφών σε σωστές και πλήρεις διαδικασίες επίλυσης του προβλήµατος που
προσπαθούµε να αντιµετωπίσουµε µε το λογισµικό.
• Tα σφάλµατα υλοποίησης, τα οποία δηµιουργούνται κατά τη µετάφραση των
προδιαγραφών και του σχεδίου σε κώδικα προγράµµατος. Τέτοια σφάλµατα µπο-
ρεί να συµβούν κατά τη δήλωση ή τη χρήση των µεταβλητών, στη λογική της
ροής του προγράµµατος, σε εκφράσεις εκτέλεσης υπολογισµών, στην επικοινω-
νία µε υπορουτίνες και σε διαδικασίες εισόδου/εξόδου.
Τα σφάλµατα που θα βρεθούν σε ένα πρόγραµµα λογισµικού πρέπει να απαλειφθούν. Η
διαδικασία αυτή καλείται εκσφαλµάτωση (debugging – αναφέρεται και ως «αποσφαλ-
µάτωση»). Μετά τη διόρθωση των λαθών, το λογισµικό πρέπει να δοκιµαστεί ξανά.
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 22
™‡ÓÔ„Ë
Στο κεφάλαιο που µόλις διαβάσατε παρουσιάσθηκαν οι δύο σηµαντικές δραστηριό-
τητες της εγκυροποίησης, η επαλήθευση και η επικύρωση (γνωστές και ως δραστη-
ριότητες Ε&Ε). Η σηµασία των δραστηριοτήτων αυτών για τον κύκλο ανάπτυξης
λογισµικού είναι τόσο µεγάλη, ώστε αναπτύχθηκε ειδικό µοντέλο κύκλου ζωής που
τις αναφέρει ρητά (το µοντέλο V), ενώ υπάρχει ειδικό πρότυπο ΙΕΕΕ για την περι-
γραφή των διαδικασιών Ε&Ε που θα εκτελεστούν στα πλαίσια ενός έργου ανάπτυ-
ξης λογισµικού. Οι τεχνικές που εφαρµόζονται σε κάθε δραστηριότητα διαχωρίζονται
σε τυπικές και µη τυπικές, ανάλογα µε το εάν αποδεικνύουν ή απλά παρέχουν ενδεί-
ξεις της εγκυρότητας του λογισµικού. Οι τελευταίες διαχωρίζονται σε δυναµικές και
στατικές, ανάλογα µε το εάν απαιτούν την εκτέλεση (δοκιµή) του υπό εγκυροποίηση
προγράµµατος ή όχι.
Στη συνέχεια του βιβλίου, καθώς θα παρουσιάζονται οι διάφορες τεχνικές Ε&Ε, θα
πρέπει να έχετε υπόψη σας το εξής παράδοξο: οι δραστηριότητες Ε&Ε και ειδικότε-
ρα οι έλεγχοι αποτελούν µια «ανωµαλία» για τον µηχανικό λογισµικού. Ενώ στις υπό-
λοιπες φάσεις του κύκλου ανάπτυξης λογισµικού, αυτός προσπαθεί να «χτίσει» ένα
σύστηµα λογισµικού από την αφηρηµένη περιγραφή του έως την υλοποίησή του, κατά
τη διάρκεια της φάσης Ε&Ε, προσπαθεί να «γκρεµίσει» το οικοδόµηµά του. Οι δια-
δικασίες Ε&Ε φαίνεται ότι αποτελούν δραστηριότητες καταστροφής και όχι δηµι-
ουργίας, γι’ αυτό και οι µηχανικοί λογισµικού (που είναι κατά κανόνα δηµιουργικά
άτοµα), τείνουν να αποφεύγουν το συστηµατικό έλεγχο του λογισµικού που αναπτύσ-
σουν, επειδή νοιώθουν ενοχές όταν ανακαλύπτουν σφάλµατα. Στα επόµενα κεφάλαια,
θα προσπαθήσω να σας πείσω ότι τα πράγµατα δεν είναι καθόλου έτσι!
2 3 ™ Y NOæH
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 23
2 4 K E ºA § A I O 1 : E I ™ A ° ø° H
BÈ‚ÏÈÔÁÚ·Ê›·
[1] Β.W. Boehm (1981), Software Engineering Economics. Prentice – Hall,
Englewood Cliffs:.
[2] IEEE (1986), Software Verification and Validation Plans, ANSI – IEEE Standard
1012 – 1986, IEEE Press, New York.
[3] ΙΕΕΕ (1990), Standard Glossary of Software Engineering Terminology, ANSI –
IEEE Standard 610.12 – 1990, IEEE Press, New York.
[4] Ε. Σκορδαλάκης (1991), Εισαγωγή στην Τεχνολογία Λογισµικού.
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 24
™Ù·ÙÈΤ˜ Ù¯ÓÈΤ˜ ∂&∂
™Ùfi¯ÔÈ
Το κεφάλαιο αυτό παρουσιάζει τις στατικές τεχνικές Ε&Ε (στατική ανάλυση, περιήγη-
ση, επισκόπηση) και στοχεύει να σας βοηθήσει να κατανοήσετε τη διαδικασία και τα
σηµεία εφαρµογής τους, καθώς και τους στόχους και τα πλεονεκτήµατα της καθεµιάς.
¶ÚÔÛ‰ÔÎÒÌÂÓ· ·ÔÙÂϤÛÌ·Ù·
Όταν θα έχετε µελετήσει το κεφάλαιο για τις στατικές τεχνικές Ε&Ε θα µπορείτε να:
• αναφέρετε τα πέντε στάδια εφαρµογής της στατικής ανάλυσης,
• αναφέρετε τουλάχιστον ένα θεωρητικό και έναν πρακτικό περιορισµό της στατι-
κής ανάλυσης,
• αναφέρετε τα τέσσερα χαρακτηριστικά µιας διαδικασίας αναθεώρησης,
• αναφέρετε τις δέκα οδηγίες για τη σωστή οργάνωση µιας αναθεώρησης,
• εξηγήσετε τι περιλαµβάνει µια περιήγηση,
• εξηγήσετε τι περιλαµβάνει µια επισκόπηση,
• συγκρίνετε τα δύο είδη αναθεωρήσεων ως προς το περιεχόµενο και την εφαρµογή τους.
ŒÓÓÔȘ ÎÏÂȉȿ
2
∫ ∂ º ∞ § ∞ π √
• στατική ανάλυση,
• αναθεώρηση,
• περιήγηση,
• αναθεωρούµενος,
• αναθεωρητής,
• αναφορά περιήγησης,
• επισκόπηση,
• επόπτης.
∂ÈÛ·ÁˆÁÈΤ˜ ·Ú·ÙËÚ‹ÛÂȘ
Οι στατικές τεχνικές Ε&Ε δεν απαιτούν την εκτέλεση του υπό αξιολόγηση λογισµι-
κού. Αντίθετα, περιλαµβάνουν την εξέταση της σχεδίασης ή του κώδικα ενός προ-
γράµµατος και στοχεύουν στην ανακάλυψη λαθών πριν την εκτέλεση ή τον συστηµα-
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 25
2 6 K E ºA § A I O 2 : ™ ∆∞∆ π ∫ ∂ ™ ∆ ∂ Ã ¡π ∫ ∂ ™ ∂ & ∂
τικό έλεγχο. Επιπλέον, επειδή κάθε λάθος µπορεί να εξεταστεί ξεχωριστά και επειδή
οι αλληλεξαρτήσεις ανάµεσα στα λάθη δεν είναι στη φάση αυτή σηµαντικές, οι στα-
τικές τεχνικές προτιµώνται για την εξέταση του λογισµικού από την οµάδα αξιολό-
γησης, αφού είναι δυνατό ένα ολόκληρο τµήµα λογισµικού να αξιολογηθεί σε µία
µόνο συνεδρίαση της οµάδας αξιολόγησης. Συνεπώς, η στατική εγκυροποίηση είναι
περισσότερο αποδοτική από τον έλεγχο του λογισµικού.
Όµως, αυτό δεν σηµαίνει ότι οι στατικές τεχνικές Ε&Ε µπορούν να αντικαταστήσουν
εντελώς τις δοκιµές του λογισµικού. Είναι βέβαια καλύτερο να χρησιµοποιούνται
αυτές στα αρχικά στάδια της φάσης Ε&Ε, ώστε να ανακαλυφθούν τα περισσότερα
λάθη πριν γίνουν οι δοκιµές. Οι τελευταίες είναι απαραίτητες, γιατί οι στατικές τεχνι-
κές Ε&Ε δεν µπορούν να ελέγξουν τη δυναµική συµπεριφορά του λογισµικού.
Στη συνέχεια του κεφαλαίου παρουσιάζονται οι δύο επικρατέστερες στατικές τεχνι-
κές Ε&Ε, η στατική ανάλυση και οι αναθεωρήσεις, οι οποίες περιλαµβάνουν τις
περιηγήσεις και τις επισκοπήσεις.
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 26
2.1 ™Ù·ÙÈ΋ ·Ó¿Ï˘ÛË
Η στατική ανάλυση (static analysis) µπορεί να εφαρµοστεί για την επαλήθευση εκεί-
νων των προϊόντων του κύκλου ανάπτυξης που µπορούν να περιγραφούν µε κάποιο
τυπικό ή δοµηµένο τρόπο. Τέτοια είναι οι προδιαγραφές, η σχεδίαση, αλλά κυρίως ο
κώδικας του λογισµικού, στον οποίο εφαρµόζεται περισσότερο αυτή η τεχνική.
Αν και η στατική ανάλυση του κώδικα µπορεί να γίνει και χειρωνακτικά, χρησιµο-
ποιώντας τεχνικές περιήγησης ή επισκόπησης (περιγράφονται στις επόµενες ενότη-
τες του κεφαλαίου) συνήθως χρησιµοποιούνται αυτόµατα εργαλεία (οι στατικοί ανα-
λυτές). Τα εργαλεία αυτά δέχονται στην είσοδο τον πηγαίο κώδικα ενός προγράµ-
µατος, εξετάζουν τη δοµή του χωρίς να εκτελέσουν το πρόγραµµα και ανακαλύπτουν
διάφορα λάθη, παραλείψεις ή ανωµαλίες στον τρόπο προγραµµατισµού.
Για να το κάνουν αυτό, οι στατικοί αναλυτές δηµιουργούν για κάθε πρόγραµµα
(Fairley[85]) τα εξής:
• Έναν πίνακα συµβόλων (symbol table), όπου καταγράφονται πληροφορίες για
όλες τις µεταβλητές που χρησιµοποιούνται στο πρόγραµµα (π.χ. τύπος, εντολή
δήλωσης, εντολές καταχώρισης νέας τιµής, εντολές χρήσης κ.ά.).
• Ένα γράφηµα ροής ελέγχου (control flow graph), οι κόµβοι του οποίου αναπα-
ριστούν τα «βασικά τµήµατα» του λογισµικού και οι πλευρές τη ροή ελέγχου ανά-
µεσα σε αυτά. Ένα βασικό τµήµα έχει την ιδιότητα ότι εάν εκτελεστεί η πρώτη
εντολή του, τότε θα εκτελεστούν όλες οι εντολές που περιέχει.
• Ένα γράφηµα κλήσεων (call graph), οι κόµβοι του οποίου αναπαριστούν τις υπο-
ρουτίνες (συναρτήσεις, διαδικασίες κ.λπ.) του λογισµικού και οι πλευρές µια πιθα-
νή κλήση µιας υπορουτίνας από µια άλλη.
Η στατική ανάλυση περιλαµβάνει τα ακόλουθα στάδια (Sommerville[96]):
• Ανάλυση ροής ελέγχου: Eντοπίζονται βρόχοι (loops) µε πολλαπλά σηµεία εισό-
δου ή εξόδου και κώδικας που δεν εκτελείται ποτέ (πρόκειται για τµήµατα κώδι-
κα που αφενός βρίσκονται ανάµεσα σε δύο εντολές goto χωρίς συνθήκη και αφε-
τέρου δεν γίνεται αναφορά σε αυτά από κανένα άλλο σηµείο του προγράµµατος).
• Ανάλυση χρήσης δεδοµένων: Eξετάζεται η χρήση των µεταβλητών και εντοπί-
ζονται µεταβλητές που χρησιµοποιούνται χωρίς πρότερη αρχικοποίηση και µετα-
βλητές που ενώ έχουν δηλωθεί, δεν χρησιµοποιούνται ποτέ.
• Ανάλυση διεπαφών: Eλέγχεται η συνέπεια του τρόπου κλήσης των υπορουτι-
νών του λογισµικού σε σχέση µε τον τρόπο που αυτές έχουν δηλωθεί. Επιπλέον,
εντοπίζονται υπορουτίνες που ενώ δηλώνονται, δεν χρησιµοποιούνται ποτέ οι
2 7 2 . 1 ™ ∆∞∆ π ∫ ∏ ∞ ¡∞ § À ™ ∏
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 27
2 8 K E ºA § A I O 2 : ™ ∆∞∆ π ∫ ∂ ™ ∆ ∂ Ã ¡π ∫ ∂ ™ ∂ & ∂
ίδιες ούτε τα αποτελέσµατα που επιστρέφουν.
• Ανάλυση ροής πληροφορίας: Για κάθε µεταβλητή εξόδου, εντοπίζονται όλες οι
µεταβλητές εισόδου από τις οποίες αυτή εξαρτάται, καθώς και οι συνθήκες από
τις οποίες εξαρτάται η τιµή της.
• Ανάλυση µονοπατιού εκτέλεσης: Eντοπίζονται όλα τα δυνατά µονοπάτια εκτέλεσης
του λογισµικού και καταγράφονται οι εντολές που εκτελούνται σε κάθε µονοπάτι.
Στην πραγµατικότητα, στα δύο τελευταία στάδια δεν γίνεται εντοπισµός λαθών. Ο
στόχος είναι να παραχθεί ένα σύνολο πληροφοριών, το οποίο αποτελεί ουσιαστικά
εναλλακτική περιγραφή του υπό ανάλυση λογισµικού. Ο (συνήθως τεράστιος) όγκος
των πληροφοριών αυτών χρησιµοποιείται για ανάλυση του λογισµικού µε κάποια
άλλη τεχνική (π.χ. επισκόπηση των διαφορετικών µονοπατιών εκτέλεσης).
Στον Πίνακα 2.1 αναφέρονται συγκεντρωτικά µερικοί από τους ελέγχους που εκτε-
λούν οι στατικοί αναλυτές (Fairley[85], Sommerville[96]).
¶›Ó·Î·˜ 2.1
Κατάλογος ελέγχων που εκτελούν οι στατικοί αναλυτές
Σφάλµατα δεδοµένων Μεταβλητές που χρησιµοποιούνται χωρίς αρχικοποίηση.
Μεταβλητές που έχουν δηλωθεί αλλά δεν χρησιµοποιούνται
Μεταβλητές στις οποίες γίνονται δύο διαδοχικές κατα-
χωρίσεις τιµής χωρίς να χρησιµοποιούνται ενδιάµεσα.
Πιθανή υπέρβαση ορίων πίνακα.
Μεταβλητές που δεν έχουν δηλωθεί.
Σφάλµατα ελέγχου Κώδικας στον οποίο ποτέ δεν φτάνει ο έλεγχος εκτέλεσης.
∆ιακλαδώσεις χωρίς συνθήκη µέσα σε βρόχους.
Σφάλµατα εισόδου /
εξόδου
Μεταβλητές που γράφονται στην έξοδο διαδοχικές φορές
χωρίς να γίνεται ενδιάµεσα καταχώριση τιµής.
Σφάλµατα διεπαφών Ασυµφωνία στον τύπο των παραµέτρων κλήσης υπορουτινών.
Ασυµφωνία στον αριθµό των παραµέτρων κλήσης υπο-
ρουτινών.
Αποτελέσµατα συναρτήσεων που δεν χρησιµοποιούνται ποτέ.
Υπορουτίνες που δεν καλούνται ποτέ.
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 28
Η στατική ανάλυση δεν µπορεί να αντικαταστήσει τις επιθεωρήσεις ή τον έλεγχο
του λογισµικού, γιατί υπόκειται σε πολλούς πρακτικούς αλλά και θεωρητικούς περιο-
ρισµούς (Fairley[85], Σκορδαλάκης[91]). Στην πρώτη κατηγορία αναφέρουµε ενδει-
κτικά τους εξής:
• Mόνο πιθανά (και όχι εξακριβωµένα) λάθη χρήσης δεικτών πινάκων ή µεταβλη-
τών τύπου δείκτη µπορούν να ανακαλυφθούν, γιατί αυτές οι µεταβλητές παίρ-
νουν διαφορετικές τιµές κάθε φορά που το πρόγραµµα εκτελείται.
• ∆εν είναι δυνατή η ανακάλυψη εντολών λανθασµένης αρχικοποίησης µεταβλητών.
• ∆εν είναι δυνατός ο εντοπισµός µιας κλήσης υπορουτίνας όπου περνιέται λαν-
θασµένη παράµετρος του σωστού τύπου.
Ο βασικός θεωρητικός περιορισµός των δυνατοτήτων των στατικών αναλυτών προ-
2 9 2 . 1 ™ ∆∞∆ π ∫ ∏ ∞ ¡∞ § À ™ ∏
Σφάλµατα διαχείρισης
χώρου αποθήκευσης
∆είκτες που δεν χρησιµοποιούνται.
Αριθµητικά λάθη σε δείκτες.
Γενικές πληροφορίες Συνολικό πλήθος γραµµών κώδικα.
Συνολικό πλήθος και θέση γραµµών µε σχόλια.
Συνολικό πλήθος και θέση γραµµών µε εντολές διακλά-
δωσης.
Συνολικό πλήθος και θέση γραµµών µε κλήσεις υπορου-
τινών συστήµατος.
Συνολικό πλήθος και θέση των σταθερών του προγράµ-
µατος.
Υπάρχουν θεωρητικοί και πρακτικοί περιορισµοί των δυνατοτήτων της στατικής
ανάλυσης. Πριν προχωρήσετε, προσπαθήστε να σκεφθείτε και να καταγράψετε
τουλάχιστον έναν από κάθε κατηγορία. (Υπόδειξη: Eπειδή πρόκειται για ένα δύσκο-
λο ερώτηµα, µην απογοητευθείτε εάν δεν τα καταφέρετε αµέσως, αλλά ανατρέξτε
σε βιβλία προγραµµατισµού, τεχνολογίας λογισµικού και θεωρίας υπολογισµού.
Μερικά από τα καλύτερα σχετικά βιβλία παρατίθενται ως βιβλιογραφία στο τέλος
του κεφαλαίου, αλλά και στο τέλος του τόµου).
¢Ú·ÛÙËÚÈfiÙËÙ· 2.1
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 29
3 0 K E ºA § A I O 2 : ™ ∆∞∆ π ∫ ∂ ™ ∆ ∂ Ã ¡π ∫ ∂ ™ ∂ & ∂
έρχεται από τη θεωρία υπολογισµού, όπου το θεώρηµα δυνατότητας λήψης απόφα-
σης (decidability theorem) δηλώνει ότι «δεδοµένου ενός προγράµµατος, το οποίο
έχει γραφεί σε µια γλώσσα προγραµµατισµού ικανή να εξοµοιώσει µια Μηχανή
Turing (βλ. Σηµείωση 1 στο τέλος του κεφαλαίου), δεν είναι δυνατό να εξεταστεί µε
αλγοριθµικό τρόπο και να αποφασιστεί εάν µια οποιαδήποτε εντολή του προγράµ-
µατος θα εκτελεστεί τελικά, όταν το πρόγραµµα εκτελείται µε δεδοµένα εισόδου που
έχουν επιλεγεί τυχαία». Σε αντίθετη περίπτωση θα ήταν δυνατή η επίλυση και του
προβλήµατος τερµατισµού (halting problem).
Αυτό σηµαίνει ότι δεν είναι δυνατό να αναπτυχθεί ένας στατικός αναλυτής, ο οποίος
εξετάζοντας τον κώδικα ενός οποιουδήποτε προγράµµατος µε τυχαία δεδοµένα εισό-
δου, θα µπορεί να αποφανθεί εάν κατά την εκτέλεση του προγράµµατος θα εκτελεστεί
κάποια συγκεκριµένη εντολή. Το πρόβληµα γίνεται αποφασίσιµο µόνο εάν θέσουµε
περιορισµούς στη δοµή του προγράµµατος (π.χ. ένας στατικός αναλυτής µπορεί να
εγγυηθεί την εκτέλεση όλων των εντολών ενός προγράµµατος χωρίς διακλαδώσεις).
2.2 ∞Ó·ıˆڋÛÂȘ
Η αναθεώρηση (review) είναι µια τεχνική διασφάλισης της ορθότητας και της ποι-
ότητας του λογισµικού που µπορεί να εφαρµοστεί σε διάφορα σηµεία του κύκλου
ανάπτυξης του συστήµατος λογισµικού. Οι στόχοι µιας αναθεώρησης είναι
(Pressman[94]):
• να ανακαλύψει λάθη στη λειτουργία, λογική ή υλοποίηση οποιασδήποτε αναπα-
ράστασης του λογισµικού,
• να επαληθεύσει ότι το λογισµικό ικανοποιεί τις προδιαγραφές του,
• να διασφαλίσει ότι το λογισµικό υιοθετεί αναγνωρισµένα πρότυπα,
• να αµβλύνει τις διαφορές στον τρόπο σχεδίασης ή ανάπτυξης του λογισµικού,
• να διευκολύνει τη διαχείριση του έργου,
• να προωθήσει την επικοινωνία ανάµεσα στα µέλη της οµάδας ανάπτυξης του λογισµικού,
• να βοηθήσει στην εκπαίδευση νέων µελών της οµάδας ανάπτυξης του λογισµικού.
Στην πραγµατικότητα υπάρχουν διάφοροι τύποι αναθεωρήσεων, οι οποίοι παρου-
σιάζουν αρκετά κοινά χαρακτηριστικά:
• Συνήθως συµµετέχουν λίγα άτοµα (3 – 5 συµµετέχοντες είναι αρκετοί).
• Πρέπει να δίδεται σε όλους αρκετός χρόνος (όχι όµως περισσότερο από 2 ώρες)
και µέσα για την προετοιµασία της αναθεώρησης.
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 30
• H διάρκεια της αναθεωρητικής συνάντησης δεν πρέπει να ξεπερνά τις 2 ώρες.
• Σε κάθε συνάντηση εξετάζεται ένα ολοκληρωµένο αλλά σχετικά µικρό τµήµα
του λογισµικού, ώστε να αυξηθεί η πιθανότητα ανακάλυψης λαθών.
Στο τέλος της αναθεώρησης, όλοι οι συµµετέχοντες πρέπει να αποφασίσουν εάν:
• θα αποδεχθούν το προϊόν χωρίς περαιτέρω τροποποιήσεις,
• θα απορρίψουν το προϊόν εξ’ αιτίας σοβαρών λαθών (αυτό σηµαίνει ότι όταν
διορθωθούν τα λάθη, θα γίνει νέα αναθεώρηση),
• θα αποδεχθούν προσωρινά το προϊόν επειδή έχουν βρεθεί όχι κρίσιµα λάθη (που
σηµαίνει ότι τα λάθη πρέπει να διορθωθούν, αλλά δεν θα γίνει νέα αναθεώρηση).
Μπορεί οι διάφοροι τύποι αναθεωρήσεων να µοιάζουν στον τρόπο οργάνωσης και
διεξαγωγής (Σχήµα 2.1), διαφέρουν όµως ως προς το στόχο. Στη συνέχεια θα παρου-
σιαστούν οι δύο πιο συνηθισµένοι τύποι, οι περιηγήσεις και οι επισκοπήσεις.
3 1 2 . 2 ∞ ¡∞ £∂ øƒ ∏™ ∂ π ™
™¯‹Ì· 2.1
Τα στάδια µιας
αναθεώρησης
Συνέχεια ∆ιόρθωση
Συµπλήρωση 
Εντύπων
Επιλογή 
Οµάδας 
Αναθεώρητων
Καθορισµός 
Τόπου και 
Χρόνου
∆ιανοµή 
Εντύπων
Αναθεώρηση
Σχεδίαση
Σφαιρική 
Ενηµέρωση
Ατοµική 
Προετοιµασία
Σύνοδος 
Αναθεώρησης
2.2.1 √‰ËÁ›Â˜ ‰ÈÂÍ·ÁˆÁ‹˜ ·Ó·ıˆڋÛˆÓ
Τέτοιες οδηγίες πρέπει να έχουν εκ των προτέρων καθοριστεί, συµφωνηθεί και δια-
νεµηθεί σε όλους τους συµµετέχοντες, ώστε η αναθεώρηση να µην ξεφύγει από τον
έλεγχο. Σε αυτές µπορεί να περιλαµβάνονται οι ακόλουθες δέκα (Pressman[94]):
1. Όλοι πρέπει να θυµούνται ότι κατά την αναθεώρηση εξετάζεται το προϊόν λογι-
σµικού και όχι η οµάδα ή το άτοµο που το ανέπτυξε.
2. H «ατζέντα» της συνάντησης, ή ο κατάλογος των σηµείων που θα εξεταστούν,
πρέπει να έχει προσχεδιαστεί και γνωστοποιηθεί στους συµµετέχοντες. Η ανα-
θεώρηση πρέπει να ακολουθεί αυστηρά την προσυµφωνηµένη ατζέντα.
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 31
3 2 K E ºA § A I O 2 : ™ ∆∞∆ π ∫ ∂ ™ ∆ ∂ Ã ¡π ∫ ∂ ™ ∂ & ∂
3. Mόνο βασικά ζητήµατα πρέπει να θίγονται. ∆εν πρέπει να γίνεται αναλυτική συζή-
τηση επί των θεµάτων που προκύπτουν, αλλά είναι αρκετό αυτά να καταγράφονται.
4. ∆εν πρέπει να γίνεται προσπάθεια επίλυσης των προβληµάτων που ανακύπτουν,
αλλά να δίνεται έµφαση µόνο στην ανακάλυψη των λαθών. Τα προβλήµατα λύνο-
νται αργότερα από τον υπεύθυνο του υπό αναθεώρηση λογισµικού, ο οποίος σε
κάποια άλλη συνάντηση (ή µε ένα υπόµνηµα) ενηµερώνει τους αναθεωρητές.
5. Kάποιος πρέπει να κρατά σηµειώσεις.
6. O αριθµός των συµµετεχόντων πρέπει να είναι περιορισµένος, αλλά όλοι πρέ-
πει να έχουν προετοιµαστεί.
7. Kάθε προϊόν πρέπει να εξετάζεται µε βάση έναν κατάλογο χαρακτηριστικών.
8. Oι αναθεωρήσεις αποτελούν απαραίτητη δραστηριότητα και πρέπει να προ-
βλέπονται στο χρονοδιάγραµµα του έργου. Έτσι, οι συµµετέχοντες θα τις θεω-
ρούν ως µέρος των υποχρεώσεών τους και όχι σαν κάτι έκτακτο.
9. Oι συµµετέχοντες στην αναθεώρηση (λέγονται και αναθεωρητές) καλό είναι να
είναι έµπειροι και να έχουν εκπαιδευτεί τόσο σε τεχνικά θέµατα όσο και σε
θέµατα ψυχολογίας.
10. H διαδικασία αναθεώρησης πρέπει τακτικά να αναθεωρείται.
2.3 ¶ÂÚÈËÁ‹ÛÂȘ
Κατά την περιήγηση (walkthrough), ο αναθεωρούµενος (reviewee), ο οποίος έχει
κατασκευάσει το υπό αναθεώρηση προϊόν, παρουσιάζει το προϊόν αυτό στους ανα-
θεωρητές (reviewers). Η συνάντηση αρχίζει µε συζήτηση επί της ατζέντας και συνε-
χίζει µε µια σύντοµη εισαγωγή από τον αναθεωρούµενο. Στη συνέχεια, αυτός παρου-
σιάζει στους αναθεωρητές το προϊόν, εξηγώντας τη λειτουργία του και τον τρόπο
που αναπτύχθηκε. Η παρουσίαση πρέπει να είναι περιγραφική και µεστή, σαν ο ανα-
θεωρούµενος να «περιηγείται» µέσα στο προϊόν. Κατά την παρουσίαση, οι αναθεω-
ρητές επισηµαίνουν και καταγράφουν λάθη ή παρατηρήσεις.
Στην περιήγηση συµµετέχουν, εκτός του αναθεωρούµενου και ο υπεύθυνος του
έργου, µέλη της οµάδας ανάπτυξης του προϊόντος, ένας εκπρόσωπος της οµάδας ποι-
ότητας, ένας υπεύθυνος για την καταγραφή των συζητήσεων και άλλα άτοµα που
ενδιαφέρονται για το έργο (π.χ. στις αρχικές φάσεις του έργου καλό είναι να συµ-
µετέχουν και εκπρόσωποι του πελάτη ή των χρηστών).
Της περιήγησης προΐσταται ο υπεύθυνος του έργου ή ο υπεύθυνος ποιότητας του
λογισµικού, ο οποίος συντονίζει τη συζήτηση και είναι υπεύθυνος για την τήρηση
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 32
της ατζέντας και τη διατήρηση ενός κλίµατος άνεσης και εµπιστοσύνης ανάµεσα
στους συµµετέχοντες. Ένας από τους αναθεωρητές είναι υπεύθυνος για την κατα-
γραφή της συζήτησης και τη σύνταξη της «Αναφοράς Περιήγησης», στην οποία
περιγράφονται: (α) το προϊόν που εξετάσθηκε, (β) οι αναθεωρητές, (γ) ο κατάλογος
µε τα ζητήµατα που ανέκυψαν και (δ) οι παρατηρήσεις και τα συµπεράσµατα.
3 3 2 . 4 ∂ ¶π ™ ∫ √¶∏™ ∂ π ™
Θα ήθελα να τονίσω ιδιαίτερα ότι κατά την περιήγηση, ο αναθεωρούµενος δεν πρέ-
πει να αισθανθεί ότι βρίσκεται σε άµυνα, αλλά πρέπει όλοι να κατανοήσουν ότι ο
στόχος είναι να υποβοηθήσουν δηµιουργικά την ανάπτυξη του προϊόντος. Επιπλέον,
παρ’ όλο που µια τέτοια διαδικασία αποκαλύπτει τις αδυναµίες και τις ικανότητες
του αναθεωρούµενου, δεν θα πρέπει να χρησιµοποιείται ως µέσο αξιολόγησής του.
Προσπαθήστε ανατρέχοντας σε βιβλία Τεχνολογίας Λογισµικού (µπορείτε να χρη-
σιµοποιήσετε κάποια από τα βιβλία που παρατίθενται στο τέλος του τόµου) να συν-
θέσετε έναν ενδεικτικό κατάλογο σηµείων αναθεώρησης για καθεµία από τις
φάσεις: παραγωγή προδιαγραφών, σχεδίαση, προγραµµατισµός.
¢Ú·ÛÙËÚÈfiÙËÙ· 2.2
2.4 ∂ÈÛÎÔ‹ÛÂȘ
Κατά την επισκόπηση (inspection), µια οµάδα εποπτών (inspectors) υποβάλλει το
προϊόν σε ένα σύνολο προκαθορισµένων ελέγχων µε στόχο την ανακάλυψη λαθών.
Η εµπειρία έχει δείξει ότι η επισκόπηση είναι αποδοτική όταν ελέγχεται η σχεδίαση
ή ο κώδικας ενός τµήµατος λογισµικού (το τελευταίο είδος επισκόπησης είναι τόσο
αποτελεσµατικό που τείνει να αντικαταστήσει τον έλεγχο των µονάδων λογισµικού).
Η επισκόπηση είναι µια τυπική διαδικασία και κάθε µέλος της οµάδας εποπτών έχει
συγκεκριµένο ρόλο σε αυτή (Πίνακας 2.2). Υπεύθυνος για τη διεξαγωγή της επι-
σκόπησης είναι ο πρόεδρος, ο οποίος σχεδιάζει τη διαδικασία, συγκροτεί την οµάδα,
φροντίζει για τη διανοµή του υλικού προετοιµασίας, συνθέτει τον κατάλογο ελέγ-
χων, διασφαλίζει ότι το υπό επισκόπηση προϊόν βρίσκεται σε κατάλληλη κατάστα-
ση, οργανώνει και συντονίζει τη συνάντηση, φροντίζει για την καταγραφή των λαθών
και επιβλέπει την κατοπινή επιδιόρθωσή τους.
Πραγµατικά, µετά την επισκόπηση ακολουθεί ένα στάδιο προσαρµογής ή διόρθω-
σης του λογισµικού από την οµάδα που το ανέπτυξε, σύµφωνα µε τις παρατηρήσεις
της οµάδας των ελεγκτών (οι οποίοι πρέπει να αποφύγουν να κάνουν υποδείξεις για
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 33
3 4 K E ºA § A I O 2 : ™ ∆∞∆ π ∫ ∂ ™ ∆ ∂ Ã ¡π ∫ ∂ ™ ∂ & ∂
τον τρόπο που θα γίνει η προσαρµογή ή η διόρθωση). Μετά από το στάδιο αυτό, ο
Πρόεδρος πρέπει να αποφασίσει εάν απαιτείται νέα επισκόπηση ή τα προβλήµατα
έχουν αντιµετωπιστεί επιτυχώς.
¶›Ó·Î·˜ 2.2
Ρόλοι των µελών της οµάδας ελεγκτών
Συγγραφέας
(αναθεωρούµενος)
Ο υπεύθυνος ανάπτυξης του σχεδίου ή του λογισµικού
που βρίσκεται υπό αναθεώρηση. Είναι επίσης υπεύθυνος
για τη διόρθωση των λαθών που θα βρεθούν.
Επόπτης Βρίσκει λάθη, παραλείψεις ή σηµεία ασυµβατότητας σε
προγράµµατα και αναφορές, ενώ µπορεί και να επισηµά-
νει ζητήµατα µε σηµασία ευρύτερη των στόχων της
συγκεκριµένης επισκόπησης.
Αναγνώστης ∆ιαβάζει τον κώδικα ή την αναφορά σχεδίασης στα οποία
γίνεται επισκόπηση.
Καταγραφέας Καταγράφει τις συζητήσεις και τα αποτελέσµατα της
συνάντησης.
Πρόεδρος ή
Συντονιστής
Οργανώνει και συντονίζει τη διαδικασία, διευκολύνοντας
την αναθεώρηση. Αναφέρει τα αποτελέσµατα στον αρχι
– συντονιστή ή στον υπεύθυνο Ε&Ε.
Αρχι – συντονιστής ή
Υπεύθυνος Ε&Ε
Υπεύθυνος για την εφαρµογή και βελτίωση των διαδικα-
σιών Ε&Ε.
Η επισκόπηση, εάν διεξαχθεί σωστά, µπορεί να αποφέρει πολλά οφέλη στην επι-
χείρηση που αναπτύσσει το λογισµικό. Κατ’ αρχήν, µετά από αρκετές επισκοπή-
σεις, κάθε επιχείρηση αναπτύσσει το δικό της ιδιαίτερο κατάλογο σηµείων προς
έλεγχο, τον οποίο συνεχώς εµπλουτίζει και προσαρµόζει στις ανάγκες του κάθε
έργου. Αφού τα ευρήµατα της επισκόπησης ανατροφοδοτούνται στους προγραµ-
µατιστές, αυτοί τείνουν να τα διορθώσουν µε αποτέλεσµα τη βελτίωση της ποιό-
τητας των προγραµµάτων που αναπτύσσουν. Τέλος, η επιτυχία µιας επισκόπησης
στην ανεύρεση λαθών µπορεί να είναι τέτοια που να µην χρειάζεται έλεγχος των
µονάδων του λογισµικού (unit testing), οπότε η επιχείρηση εξοικονοµεί πόρους
(βλ. µελέτη περίπτωσης που ακολουθεί).
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 34
ªÂϤÙË ÂÚ›ÙˆÛ˘ 2.1
Η επισκόπηση ως στατική τεχνική Ε&Ε αναπτύχθηκε αρχικά στην IBM. Ένας αριθ-
µός έργων στα οποία εφαρµόστηκε περιγράφεται από τον Fagan (Fagan[76]). Στο
αρχικό πείραµα, η οµάδα επισκόπησης πραγµατοποιούσε δύο συνόδους διάρκειας 1
– 2 ωρών κάθε ηµέρα, ενώ κάθε µέλος χρειαζόταν άλλες δύο ώρες προετοιµασίας για
κάθε σύνοδο. Κατά την προετοιµασία, κάθε µέλος µπορούσε να εξετάσει περίπου 125
γραµµές κώδικα την ώρα, ενώ µια επισκόπηση συνήθως περιελάµβανε την εξέταση
90 – 125 γραµµών κώδικα την ώρα. Εάν τέσσερα άτοµα συµµετέχουν στη διαδικα-
σία, τότε απαιτείται περίπου µία ανθρωποηµέρα για την επισκόπηση 100 γραµµών
κώδικα (ενώ ο έλεγχος µονάδων του λογισµικού απαιτεί σχεδόν το διπλάσιο κόπο).
Οι µετρήσεις αυτές επιβεβαιώθηκαν αργότερα και από άλλες οµάδες ανάπτυξης.
Κατά το αρχικό πείραµα ανακαλύφθηκε το 67% των λαθών της σχεδίασης και του
κώδικα του προγράµµατος, ενώ σε επόµενο πείραµα το ποσοστό ανέβηκε στο 82%.
Άλλες οµάδες ανάπτυξης ανακοίνωσαν ποσοστά λίγο µεγαλύτερα από 70%.
3 5 2 . 4 ∂ ¶π ™ ∫ √¶∏™ ∂ π ™
Περιήγηση
Πότε
εφαρµόζεται
Σε αρχικά στάδια της διαδικα-
σίας ανάπτυξης.
Όταν απαιτείται µια όχι τυπική
παρουσίαση του λογισµικού.
Επισκόπηση
Μετά από το πέρας της σχεδία-
σης ή του προγραµµατισµού.
Όταν απαιτείται µια τυπική
παρουσίαση του λογισµικού.
Αφού διαβάσετε τις ενότητες 2.3 & 2.4 προσπαθήστε να τεκµηριώσετε τον ισχυ-
ρισµό «ένας ισορροπηµένος συνδυασµός περιηγήσεων και επισκοπήσεων µπορεί
να αποδειχθεί εξαιρετικά επωφελής για ένα έργο ανάπτυξης λογισµικού». (Υπό-
δειξη: Για να απαντήσετε, εξετάστε σε ποια σηµεία της διαδικασίας ανάπτυξης
λογισµικού µπορεί να εφαρµοστεί καθεµία από τις δύο τεχνικές, ποιοι συµµετέ-
χουν συνήθως, ποιος είναι ο στόχος της κάθε τεχνικής και ποια πλεονεκτήµατα
προσφέρει η καθεµία.). Έπειτα συγκρίνετε την απάντησή σας µε τον Πίνακα 2.3.
¢Ú·ÛÙËÚÈfiÙËÙ· 2.3
¶›Ó·Î·˜ 2.3
Σύγκριση των τεχνικών περιήγησης και επισκόπησης
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 35
3 6 K E ºA § A I O 2 : ™ ∆∞∆ π ∫ ∂ ™ ∆ ∂ Ã ¡π ∫ ∂ ™ ∂ & ∂
™ËÌÂÈÒÛÂȘ
1. Η µηχανή που περιέγραψε το 1937 ο Alan Turing µπορεί να κάνει κάθε συµβολικό
υπολογισµό χρησιµοποιώντας µόνο µια απείρου µεγέθους ταινία χαρτιού, µια κεφα-
λή γραφής/ανάγνωσης από την ταινία και ένα σύνολο κανόνων που µετακινούν την
κεφαλή κατά µια θέση πάνω στην ταινία ή την αναγκάζουν να γράψει σε ή να δια-
βάσει ένα σύµβολο από αυτή. Έχει αποδειχθεί ότι, εάν αγνοηθούν παράµετροι ταχύ-
τητας και διαθεσιµότητας υπολογιστικών πόρων, αυτή η τόσο απλή υποθετική µηχα-
νή, αποτελεί το γενικότερο και ισχυρότερο τυπικό µοντέλο υπολογισµού.
Ποιοι
συµµετέχουν
Aναθεωρούµενος, µέλη οµάδας
ανάπτυξης, υπεύθυνος έργου,
υπεύθυνος ποιότητας, γραφέας,
άλλοι ενδιαφερόµενοι.
Τον έλεγχο της διαδικασίας έχει
ο αναθεωρούµενος.
Αναθεωρούµενος, επόπτης, ανα-
γνώστης, γραφέας, πρόεδρος.
Τον έλεγχο της διαδικασίας έχει
η οµάδα ελεγκτών.
Στόχος Aνακάλυψη λαθών µετά από
περιγραφική παρουσίαση της
λειτουργίας του προϊόντος.
Aνακάλυψη λαθών µε βάση
ένα προκαθορισµένο κατάλογο
σηµείων ελέγχου.
Πλεονεκτήµατα Bελτίωση της επικοινωνίας
µεταξύ των µελών της οµάδας
ανάπτυξης.
Προαγωγή της συνοχής της
οµάδας και ανύψωση του ηθι-
κού της.
Πολύ καλό µέσο εκπαίδευσης
ενός νέου µέλους.
O πρόεδρος και όχι ο αναθεω-
ρούµενος έχει τον έλεγχο της
διαδικασίας.
Κάθε µέλος της οµάδας επο-
πτών έχει συγκεκριµένο ρόλο.
Ανατροφοδότηση λαθών στους
προγραµµατιστές.
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 36
™‡ÓÔ„Ë
Στο κεφάλαιο αυτό γνωρίσατε τις ακόλουθες στατικές τεχνικές Ε&Ε:
• την στατική ανάλυση, κατά την οποία ο κώδικας του λογισµικού αναλύεται σε
σχέση µε τις µεταβλητές, τα σηµεία κλήσης υπορουτινών και αλλαγής ροής εκτέ-
λεσης και τις εντολές εισόδου/εξόδου,
• τις περιηγήσεις, κατά τις οποίες η λειτουργία του λογισµικού περιγράφεται άτυπα
σε µια οµάδα αναθεωρητών,
• τις επισκοπήσεις, κατά τις οποίες το λογισµικό ελέγχεται από µια οµάδα εποπτών
µε βάση ένα κατάλογο σηµείων ελέγχου.
Καθώς θα διαβάζετε για τις δυναµικές τεχνικές Ε&Ε στο επόµενο κεφάλαιο, να θυµά-
στε αφενός ότι οι στατικές τεχνικές είναι καλό να εφαρµόζονται στα αρχικά στάδια
ανάπτυξης, ενώ οι δυναµικές τεχνικές στα τελικά, αφού απαιτούν την εκτέλεση του
λογισµικού και αφετέρου ότι είναι απαραίτητη η συνδυασµένη εφαρµογή και των δύο
τεχνικών Ε&Ε.
3 7 ™ Y NOæH
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 37
3 8 K E ºA § A I O 2 : ™ ∆∞∆ π ∫ ∂ ™ ∆ ∂ Ã ¡π ∫ ∂ ™ ∂ & ∂
BÈ‚ÏÈÔÁÚ·Ê›·
[1] M. Fagan (1976), Design and Code Inspections to Reduce Errors in Program
Development. IBM Systems Journal, 15(3).
[2] R. Fairley (1985), Software Engineering Concepts. McGraw – Hill, Singapore.
[3] R. Pressman (1994), Software Engineering: a practitioner’s approach. McGraw
– Hill, England
[4] Ι. Sommerville (1996), Software Engineering. Addison – Wesley, USA
[5] Ε. Σκορδαλάκης (1991), Εισαγωγή στην Τεχνολογία Λογισµικού. Συµµετρία,
Αθήνα.
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 38
¢˘Ó·ÌÈΤ˜ T¯ÓÈΤ˜ ∂&∂
™Ùfi¯ÔÈ
Ο στόχος του κεφαλαίου είναι να σας γνωρίσει τρεις όχι και τόσο διαδεδοµένες δυνα-
µικές τεχνικές Ε&Ε, οι οποίες µπορεί παρόλα αυτά να φανούν χρήσιµες σε ορισµέ-
νες περιπτώσεις (ιδιαίτερα όταν ο προϋπολογισµός της φάσης Ε&Ε δεν αντέχει την
εκτέλεση εξαντλητικών ελέγχων). Οι τελευταίοι αποτελούν τις πιο γνωστές δυναµι-
κές τεχνικές Ε&Ε και παρουσιάζονται στα επόµενα κεφάλαια.
¶ÚÔÛ‰ÔÎÒÌÂÓ· ·ÔÙÂϤÛÌ·Ù·
Όταν θα έχετε µελετήσει το κεφάλαιο αυτό, θα µπορείτε να:
• περιγράψετε τη διαδικασία και τα αποτελέσµατα της συµβολικής εκτέλεσης,
• περιγράψετε το σκοπό και την εφαρµογή των δοκιµών προσοµοίωσης,
• περιγράψετε το στόχο, τα πλεονεκτήµατα και τα µειονεκτήµατα της ανάλυσης ευαι-
σθησίας.
ŒÓÓÔȘ ÎÏÂȉȿ
3
∫ ∂ º ∞ § ∞ π √
• τυπικές µέθοδοι που βασίζονται σε
µαθηµατικά µοντέλα,
• πρόταση,
• προτασιακός τελεστής,
• αξιωµατικές µέθοδοι,
• αλγεβρικές µέθοδοι,
• συνάρτηση / λογική συνάρτηση,
• πεδίο ορισµού / τιµών,
• σύνολο,
• πίνακας αλήθειας,
• υπογραφή,
• κατηγόρηµα,
• καθολικός τελεστής,
• υπαρξιακός τελεστής.
∂ÈÛ·ÁˆÁÈΤ˜ ·Ú·ÙËÚ‹ÛÂȘ
Σε αντίθεση µε τις στατικές τεχνικές Ε&Ε που περιγράφηκαν στο Kεφάλαιο 2, οι
δυναµικές τεχνικές περιλαµβάνουν την εκτέλεση του συστήµατος λογισµικού ή ενός
τµήµατος λογισµικού, του οποίου την ορθότητα εξετάζουµε.
Η εκτέλεση γίνεται συνήθως µε τη χρήση υπολογιστή, χρησιµοποιώντας ένα σύνολο από
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 39
3.1 ™˘Ì‚ÔÏÈ΋ ÂÎÙ¤ÏÂÛË
Η συµβολική εκτέλεση (symbolic execution) είναι µια δυναµική τεχνική επικύρω-
σης της ορθότητας ενός προγράµµατος λογισµικού. Σύµφωνα µε αυτή, στις µετα-
βλητές εισόδου του λογισµικού «καταχωρίζονται» συµβολικές τιµές και έπειτα
εκτελείται ο κώδικας του προγράµµατος.
Η ανάλυση του λογισµικού µπορεί να γίνει χειρωνακτικά ή µε αυτοµατοποιηµένα
εργαλεία. Σε κάθε περίπτωση, περιλαµβάνει την παρακολούθηση του τρόπου διά-
δοσης των συµβολικών τιµών στις υπόλοιπες µεταβλητές του προγράµµατος που
λαµβάνουν µέρος στους υπολογισµούς που γίνονται στο λογισµικό. Με τον τρόπο
αυτό, όλοι οι υπολογισµοί, οι καταχωρίσεις και οι συνθήκες του προγράµµατος απο-
κτούν συµβολικές τιµές.
Ακολουθούν δύο παραδείγµατα χρήσης της συµβολικής εκτέλεσης, τα οποία περιέ-
χονται στο (Fairley[85]).
4 0 K E ºA § A I O 3 : ¢ À ¡∞ ªπ ∫ ∂ ™ T ∂ Ã ¡π ∫ ∂ ™ ∂ & ∂
δεδοµένα εισόδου. Η συµπεριφορά του λογισµικού για τα δεδοµένα αυτά αναλύεται και
παρατηρούνται οι έξοδοι που αυτό παράγει. Συγκρίνοντας τις πραγµατικές εξόδους µε
τις επιθυµητές, µπορούµε να συµπεράνουµε εάν το λογισµικό έχει σφάλµατα ή οχι.
Υπάρχουν δύο µεγάλες κατηγορίες δυναµικών τεχνικών Ε&Ε, ανάλογα µε το εάν χρη-
σιµοποιούνται συµβολικά ή πραγµατικά δεδοµένα. Στην πρώτη περίπτωση έχουµε τη
συµβολική εκτέλεση και στη δεύτερη τον έλεγχο του λογισµικού. Ενδιάµεση τεχνική
είναι η προσοµοίωση, όπου κατά την εκτέλεση ενός πραγµατικού συστήµατος λογι-
σµικού, προσοµοιώνεται το µέρος του προγράµµατος ή των δεδοµένων που λείπει.
Στο κεφάλαιο αυτό θα παρουσιαστούν οι δυναµικές τεχνικές Ε&Ε πλην των δοκι-
µών, οι οποίες παρουσιάζονται αναλυτικά στο επόµενο κεφάλαιο. Πρώτα περιγρά-
φεται η συµβολική εκτέλεση ενός προγράµµατος και ακολουθούν οι προσοµοιώσεις.
Το κεφάλαιο κλείνει µε την παρουσίαση της τεχνικής της ανάλυσης ευαισθησίας, η
οποία χρησιµοποιείται για να αποδείξει πόσο σοβαρά είναι τα λάθη που αποµένουν
στο λογισµικό.
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 40
4 1 3 . 1 ™ À ªµ √§ π ∫ ∏ ∂ ∫ ∆ ∂ § ∂ ™ ∏
ΑΛΓΟΡΙΘΜΟΣ TEST
ΑΡΧΗ
∆ΙΑΒΑΣΕ (B, C) ; B <― b ; C <― c;
A : = B+C ; A <― b+c;
X : = A * C ; X <― (b+c)*c
EAN (A < X) ΤΟΤΕ {Εξωτερικό ΕΑΝ} (b+c) <= (b+c)*c
ΕΚΤΕΛΕΣΕ ΤΜΗΜΑ ΚΩ∆ΙΚΑ 1
ΑΛΛΙΩΣ
ΕΑΝ (B >= 1) OR (B <= – 1) ΤΟΤΕ {Εσωτερικό ΕΑΝ} (b >= 1) OR (b <= – 1)
ΕΚΤΕΛΕΣΕ ΤΜΗΜΑ ΚΩ∆ΙΚΑ 2
ΑΛΛΙΩΣ
ΕΚΤΕΛΕΣΕ ΤΜΗΜΑ ΚΩ∆ΙΚΑ 3
ΕΑΝ – ΤΕΛΟΣ {Εσωτερικό ΕΑΝ}
ΕΑΝ – ΤΕΛΟΣ {Εξωτερικό ΕΑΝ}
ΤΕΛΟΣ.
¶·Ú¿‰ÂÈÁÌ· 3.1: ∞Ó¿Ï˘ÛË ÙˆÓ ÌÔÓÔ·ÙÈÒÓ ÂÎÙ¤ÏÂÛ˘
Ο αλγόριθµος TEST που ακολουθεί διαβάζει δύο µεταβλητές b και c, µε βάση τις
οποίες υπολογίζει τις a και x. Έπειτα, χρησιµοποιεί διάφορες συνθήκες στις τιµές
των µεταβλητών αυτών για να εκτελέσει ένα από τα τρία τµήµατα κώδικα που περι-
λαµβάνει. ∆ίπλα στις εντολές του αλγορίθµου παρατίθενται οι αντίστοιχες ενέργει-
ες που πρέπει να κάνουµε κατά τη συµβολική εκτέλεσή του.
Έτσι, κατά την ανάγνωση των τιµών των µεταβλητών εισόδου B και C, καταχωρί-
ζουµε σ’ αυτές τις συµβολικές τιµές b και c αντίστοιχα. Έπειτα υπολογίζουµε τις συµ-
βολικές τιµές των µεταβλητών Α και Χ (a και x αντίστοιχα) και προχωρούµε στην
περιγραφή των συνθηκών των δοµών απόφασης µε συµβολικές τιµές. Παρατηρήστε
ότι από τη στιγµή που σε κάποια µεταβλητή καταχωρισθεί συµβολική τιµή, αυτή χρη-
σιµοποιείται αντί της µεταβλητής σε όλες τις εντολές όπου συµµετέχει η µεταβλητή.
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 41
4 2 K E ºA § A I O 3 : ¢ À ¡∞ ªπ ∫ ∂ ™ T ∂ Ã ¡π ∫ ∂ ™ ∂ & ∂
Σύµφωνα µε τις αντικαταστάσεις των τιµών των µεταβλητών που έγιναν κατά τη
συµβολική εκτέλεση, οι συνθήκες εκτέλεσης των τµηµάτων κώδικα είναι οι εξής:
ΤΜΗΜΑ 1: [(b+c) <= (b+c)*c]
ΤΜΗΜΑ 2: [(b+c) > (b+c)*c] AND [(b >= 1) OR (b <= – 1)]
ΤΜΗΜΑ 3: [(b+c) > (b+c)*c] AND [( – 1 < b < 1)]
Στη γραφική παράσταση του Σχήµατος 3.1 φαίνονται οι περιοχές τιµών των µετα-
βλητών b και c για τις οποίες εκτελούνται τα τµήµατα κώδικα 1, 2 και 3 (περιοχές
1, 2 και 3, αντίστοιχα). Με βάση αυτή τη γραφική παράσταση, µπορούµε να εξά-
γουµε κατάλληλα σύνολα τιµών για τις µεταβλητές εισόδου, ώστε η εκτέλεση του
προγράµµατος να ακολουθεί το µονοπάτι που εµείς θέλουµε να ελέγξουµε. Η ανεύ-
ρεση δοκιµαστικών δεδοµένων (test data) ενός λογισµικού είναι µια αρκετά χρήσι-
µη εφαρµογή της συµβολικής εκτέλεσης, µε την προϋπόθεση ότι οι συνθήκες που
καθορίζουν την εκτέλεση του κάθε µονοπατιού περιγράφονται από εξισώσεις πρώ-
του βαθµού επί των συµβολικών µεταβλητών εισόδου.
Επιπλέον, µπορούµε µε τον ίδιο τρόπο να ελέγξουµε και την ασφάλεια της εκτέλε-
σης εντολών διαίρεσης, δεικτοδότησης πινάκων ή αναφοράς σε δείκτες. Για παρά-
δειγµα, στην περιοχή 1 του Σχήµατος 3.1 µπορεί η διαίρεση µε Α= b + c να µην είναι
ασφαλής, αφού η ευθεία b + c = 0 περιέχεται εκεί.
™¯‹Ì· 3.1
Περιοχές τιµών
των µεταβλητών B
και C του προ-
γράµµατος TEST
b
c
0,0
c = +1
b = +1
b = -1
b + c = 0
Περιοχή 1
Περιοχή 2
Περιοχή 3
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 42
¶·Ú¿‰ÂÈÁÌ· 3.2: ∞Ó¿Ï˘ÛË ‚Úfi¯ˆÓ
Ο ακόλουθος αλγόριθµος SUM_ARRAY υπολογίζει το άθροισµα των στοιχείων ενός
πίνακα ακεραίων Α[1..Ν]. Χρησιµοποιεί µια δοµή επανάληψης (βρόχο) για να δια-
βάσει κάθε φορά το επόµενο στοιχείο του πίνακα και να το προσθέσει στο µερικό
άθροισµα, το οποίο καταχωρεί στη µεταβλητή TOTAL.
ΑΛΓΟΡΙΘΜΟΣ SUM_ARRAY
ΑΡΧΗ
TOTAL := 0 ;
ΓΙΑ Ι := 1 ΕΩΣ Ν ΚΑΝΕ
TOTAL := TOTAL + A[I]
ΕΠΑΝΕΛΑΒΕ
ΤΕΛΟΣ
Εάν οι συµβολικές τιµές που δίνουµε στα στοιχεία του πίνακα Α είναι
Α[1] <― a1, A[2] <― a2, A[3] <― a3, …, A[n] <― an,
τότε στο Σχήµα 3.2 φαίνεται το δένδρο εκτέλεσης του προγράµµατος SUM_ARRAY.
Ο συνολικός υπολογισµός που περιγράφεται από το δένδρο συµβολικής εκτέλεσης
(Σχήµα 3.2) µπορεί να εκφραστεί σε συµβολική µορφή ως:
Η έκφραση αυτή καλείται αναλλοίωτο του βρόχου (loop invariant) και περιγράφει
τη «συµπεριφορά» ενός βρόχου ανεξάρτητα από τις φορές που αυτός επαναλαµβά-
νεται. Οι τεχνικές µε τις οποίες αποδεικνύουµε ότι µια τέτοια έκφραση παραµένει
πραγµατικά «αναλλοίωτη» θα περιγραφούν στα πλαίσια της τυπικής επαλήθευσης
στο Kεφάλαιο 8. Εάν υποθέσουµε ότι αυτό ισχύει στο παράδειγµά µας, τότε µπο-
ρούµε να χρησιµοποιήσουµε το αναλλοίωτο του βρόχου για να δείξουµε ότι ο αλγό-
ριθµος SUM_ARRAY επιστρέφει το επιθυµητό αποτέλεσµα: εάν στην έκφραση του
αναλλοίωτου αντικαταστήσουµε το Ι µε την τιµή του κατά την έξοδο από το βρόχο
(Ι=Ν+1), έχουµε

TOTAL A j A j A j
j
I
j
N
j
N
= = =
=

= =
+ −
∑ ∑ ∑
[ ] [ ] [ ]
( )
1
1
1 1
1 1

TOTAL A j
j
I
=
=


[ ]
1
1
4 3 3 . 1 ™ À ªµ √§ π ∫ ∏ ∂ ∫ ∆ ∂ § ∂ ™ ∏
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 43
4 4 K E ºA § A I O 3 : ¢ À ¡∞ ªπ ∫ ∂ ™ T ∂ Ã ¡π ∫ ∂ ™ ∂ & ∂
™¯‹Ì· 3.2
Το δένδρο συµβο-
λικής εκτέλεσης
του προγράµµατος
SUM_ARRAY

Total = 0+a1+a2+a3 
I = 2
Total = 0+a1+a2 
I = 2
Total = 0+a1 
I = 2
Total = 0 
I = 1
Total = a1+a2+a3
Total = a1
Total = 0
Total = a1+a2
N > = 1
N > = 2
N > = 3
N > = 4
N < 1
N < 2
N < 3
N < 4
Αυτή είναι κάθε φορά η τελική τιµή της µεταβλητής TOTAL, η οποία και συµφωνεί
µε την επιθυµητή τιµή της.
Εκτός από γέφυρα προς την τυπική επαλήθευση, η συµβολική εκτέλεση µπορεί να
συνδυαστεί µε τη δοκιµή ενός λογισµικού, εάν σε κάποιες από τις εισόδους δοθούν
αληθινές τιµές ενώ στις υπόλοιπες δοθούν συµβολικές τιµές. Με τον τρόπο αυτό,
µπορούµε να πετύχουµε διάφορες διαβαθµίσεις δοκιµών ανάµεσα στην καθαρή συµ-
βολική εκτέλεση (σε όλες τις µεταβλητές εισόδου καταχωρίζονται συµβολικές τιµές)
και την καθαρή δοκιµή (σε όλες τις µεταβλητές εισόδου καταχωρίζονται αληθινές
τιµές). Για παράδειγµα, εάν θέλουµε να ελέγξουµε την ευαισθησία ενός προγράµ-
µατος σε κάποια συγκεκριµένη µεταβλητή εισόδου, χρησιµοποιούµε συµβολική τιµή
για τη µεταβλητή αυτή και αληθινές τιµές για τις υπόλοιπες. Περισσότερα για την
ανάλυση ευαισθησίας στην ενότητα 3.3.
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 44
4 5 3 . 2 ¶ƒ √™ √ª√π ø™ ∏
Προσπαθήστε να συνοψίσετε σε 50 περίπου λέξεις τη διαδικασία και τα αποτελέ-
σµατα της συµβολικής εκτέλεσης. Έπειτα συγκρίνατε την απάντησή σας µε το κεί-
µενο στο πλαίσιο που ακολουθεί.
Συνοψίζοντας, µε τη συµβολική εκτέλεση ενός λογισµικού, οι τιµές των µεταβλη-
τών του προγράµµατος εκφράζονται σαν συναρτήσεις των µεταβλητών εισόδου.
Με τον τρόπο αυτό, προκύπτουν οι εκφράσεις του αναλλοίωτου του βρόχου, ενώ
είναι δυνατή η ανακάλυψη µονοπατιών εκτέλεσης του προγράµµατος που δεν εκτε-
λούνται ποτέ. Επιπλέον, διαφαίνεται η πιθανότητα (ή η απιθανότητα) σηµασιολο-
γικών λαθών (π.χ. διαίρεση µε το µηδέν, δείκτης πίνακα εκτός ορίων κ.ά.) σε διά-
φορα τµήµατα του κώδικα.
¢Ú·ÛÙËÚÈfiÙËÙ· 3.1
3.2 ¶ÚÔÛÔÌÔ›ˆÛË
Μια από τις τελευταίες γραµµές άµυνας απέναντι στα σφάλµατα είναι η προσοµοί-
ωση (simulation) της εκτέλεσης ενός λογισµικού. Η τεχνική αυτή είναι αρκετά απο-
τελεσµατική, αλλά και δαπανηρή, γι’ αυτό και χρησιµοποιείται στα τελευταία στά-
δια της φάσης ανάπτυξης ή ελέγχου του λογισµικού. Βέβαια, οι δοκιµές προσοµοί-
ωσης είναι συµφέρουσες µόνο όταν είναι πιο φθηνές από το κόστος επισκευής του,
συστήµατος, αφού αυτό παραδοθεί (δηλαδή τη συντήρηση του συστήµατος).
Όταν λέµε προσοµοίωση, εννοούµε κάποιου είδους προσέγγιση της πραγµατικότη-
τας. Πιο συγκεκριµένα, θεωρούµε ότι η ανάπτυξη του λογισµικού έχει προχωρήσει
αρκετά και το σύστηµα βρίσκεται σε προχωρηµένο στάδιο συγκρότησης, οπότε µπο-
ρούµε να δοκιµάσουµε το σύστηµα µε τρόπο που προσεγγίζει τις πραγµατικές συν-
θήκες στις οποίες αυτό θα λειτουργήσει όταν παραδοθεί (Shooman[83]).
Σε µια δοκιµή προσοµοίωσης πρέπει να προσεγγισθεί τόσο το πραγµατικό λογισµι-
κό, όσο και το πραγµατικό υλικό όπου θα εκτελείται το λογισµικό, ώστε να δοκιµα-
στούν διάφορες πραγµατικές περιπτώσεις χρήσης του συστήµατος. Πολλές φορές,
τµήµατα του υλικού ή του λογισµικού λείπουν ή δεν έχουν ακόµη καθοριστεί επα-
κριβώς. Πριν αυτά υλοποιηθούν προσοµοιώνεται η λειτουργία τους, ώστε να δοκι-
µαστεί η συµπεριφορά τους αλλά και η συµπεριφορά του συνολικού συστήµατος.
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 45
4 6 K E ºA § A I O 3 : ¢ À ¡∞ ªπ ∫ ∂ ™ T ∂ Ã ¡π ∫ ∂ ™ ∂ & ∂
Ο σκοπός των δοκιµών προσοµοίωσης είναι να αναπαραστήσουν µε τον καλύτε-
ρο δυνατό τρόπο τις πραγµατικές συνθήκες λειτουργίας του συστήµατος. Όµως,
το µεγαλύτερο βάρος κατά την προσοµοίωση δίνεται στον έλεγχο των περιπτώσε-
ων (ή αλλιώς σεναρίων) χρήσης του συστήµατος. Οι περιπτώσεις χρήσης (use
cases) πρέπει να είναι αντιπροσωπευτικές των διαφόρων τρόπων πραγµατικής λει-
τουργίας του συστήµατος και να αντικατοπτρίζουν τη συχνότητα και την πολυ-
πλοκότητα των τρόπων αυτών. Έτσι, πολλές φορές η προσοµοίωση µιας σύνθετης
περίπτωσης χρήσης αποτελείται από απλούστερες προσοµοιώσεις των επιµέρους
περιπτώσεων. Επιπλέον, για τις δοκιµές προσοµοίωσης που θα εκτελέσουµε, πρέ-
πει να γνωρίζουµε τα αναµενόµενα (σωστά ή λάθος) αποτελέσµατα, ώστε να µπο-
ρούµε να αξιολογήσουµε τα εκάστοτε εξαγόµενα.
Πολλές φορές, οι δοκιµές προσοµοίωσης ενός συστήµατος ξεκινούν από τις αρχικές
φάσεις της ανάπτυξης και διαρκούν µέχρι την παράδοση του συστήµατος στον πελά-
τη. Οι αρχικές δοκιµές γίνονται στις εγκαταστάσεις ανάπτυξης του συστήµατος.
Είναι φυσικό στη φάση αυτή πολλά τµήµατα του λογισµικού να µην έχουν ακόµη
υλοποιηθεί (για τα τµήµατα αυτά χρησιµοποιείται ειδικός κώδικας – λέγεται stub –
ο οποίος εξοµοιώνει την αναµενόµενη εξωτερική συµπεριφορά του τµήµατος χωρίς
να έχει υλοποιηθεί η εσωτερική επεξεργασία που προκαλεί αυτή τη συµπεριφορά,
ώστε το συνολικό σύστηµα να λειτουργεί). Καθώς αναπτύσσονται τα τµήµατα που
λείπουν, ενσωµατώνονται στα υπάρχοντα και αντικαθιστούν τα stubs, µε αποτέλε-
σµα οι προσοµοιώσεις να είναι πληρέστερες. Η τελική προσοµοίωση γίνεται εγκα-
θιστώντας το σύστηµα στο υλικό του πελάτη, όπου και λειτουργεί δοκιµαστικά για
µερικούς µήνες µέχρι να παραδοθεί τελικά.
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 46
3.3 ∞Ó¿Ï˘ÛË Â˘·ÈÛıËÛ›·˜
Η ανάλυση ευαισθησίας (sensitivity analysis) περιγράφει ποσοτικά τη συµπεριφο-
ρά του συστήµατος λογισµικού σε σχέση µε την πιθανότητα να υπάρχουν κρυµµέ-
να σφάλµατα. Περιλαµβάνει την επαναλαµβανόµενη εκτέλεση του αρχικού κώδικα
του προγράµµατος, αλλά και παραλλαγών αυτού, χρησιµοποιώντας δύο υποθέσεις
(Voas[95]):
• την υπόθεση µοναδικού σφάλµατος, η οποία ισχυρίζεται ότι το λογισµικό περιέχει
ένα µόνο σφάλµα και όχι πολλά σφάλµατα κατανεµηµένα σε όλο τον κώδικα, και
• την υπόθεση απλού σφάλµατος, η οποία ισχυρίζεται ότι το σφάλµα βρίσκεται σε
µια και µοναδική θέση µέσα στον κώδικα, χωρίς να είναι κατανεµηµένο σε ολό-
κληρο τον κώδικα και το σφάλµα αυτό έχει την ίδια πιθανότητα να βρίσκεται σε
οποιαδήποτε θέση µέσα στον κώδικα.
Αυτές οι υποθέσεις αποτελούν παραλλαγή της υπόθεσης του ικανού προγραµµατι-
στή, η οποία ισχυρίζεται ότι ένας ικανός προγραµµατιστής θα γράψει κώδικα που είναι
αρκετά κοντά στο να χαρακτηριστεί «ορθός».
4 7 3 . 3 ∞ ¡∞ § À ™ ∏ ∂ À∞ π ™ £∏™ π ∞ ™
Ο στόχος της ανάλυσης ευαισθησίας είναι να υποδείξει πόσο «µικρά» µπορεί να είναι
τα µικρότερα σφάλµατα ενός λογισµικού. Έχοντας αυτή την πρόβλεψη, µπορούµε
να εφαρµόσουµε στατιστικές τεχνικές για να προσδιορίσουµε πόσες δοκιµές χρειά-
ζονται για να ανακαλυφθούν σφάλµατα αυτού του µεγέθους και έτσι να έχουµε ένα
κριτήριο τερµατισµού των δοκιµών.
Το πλεονέκτηµα της µεθόδου είναι ότι η πρόβλεψη βασίζεται στην παρατήρηση απο-
τελεσµάτων που οφείλονται στην ύπαρξη πραγµατικών σφαλµάτων. Η αδυναµία της
έγκειται στο γεγονός ότι τα σφάλµατα αυτά αποτελούν ένα µικρό υποσύνολο όλων
των πιθανών λαθών.
Η ανάλυση ευαισθησίας εκτιµά την πιθανότητα αποτυχηµένης λειτουργίας του λογι-
σµικού εξαιτίας ενός µοναδικού λάθους που θα µπορούσε να συµβεί σε ένα συγκε-
κριµένο σηµείο του κώδικα, για κάθε σηµείο του προγράµµατος.
Για να παράσχει αυτή την πρόβλεψη, η ανάλυση ευαισθησίας εισάγει εσκεµµένα σφάλ-
µατα µέσα στον κώδικα και εκτιµά την ορατή επίδρασή τους (που είναι η αστοχία –
failure – του λογισµικού). Η επιτυχία της εξαρτάται πολύ από τον τρόπο που έγιναν οι
δοκιµές για να µετρηθεί η επίδραση: στη χειρότερη περίπτωση πρέπει να ελεγχθούν
όλα τα «σηµεία» του κώδικα που αλλάζουν τις τιµές κάποιων µεταβλητών, δεδοµέ-
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 47
4 8 K E ºA § A I O 3 : ¢ À ¡∞ ªπ ∫ ∂ ™ T ∂ Ã ¡π ∫ ∂ ™ ∂ & ∂
νων, αρχείων ή ακόµη και του µετρητή εντολών προγράµµατος.
Για να συµβεί και να παρατηρηθεί µια αστοχία κατά την εκτέλεση του λογισµικού,
πρέπει να συµβούν τρία πράγµατα: πρέπει να εκτελεστεί το σφάλµα που την προκα-
λεί, να βρεθεί το λογισµικό σε µια κατάσταση δεδοµένων που δεν είναι ορθή, η οποία
να διαδοθεί µέχρι κάποια παρατηρούµενη έξοδο του λογισµικού. Η ανάλυση ευαι-
σθησίας διαχωρίζει τρία αντίστοιχα είδη γεγονότων που µπορεί να προκαλέσουν αστο-
χία του λογισµικού. Με στόχο να εκτιµηθεί η πιθανότητα εµφάνισης κάθε τέτοιου γεγο-
νότος, χρησιµοποιεί τις εξής διαφορετικές διαδικασίες ανάλυσης για κάθε σηµείο του
προγράµµατος:
• Ανάλυση εκτέλεσης (execution analysis): Eκτιµά την πιθανότητα εκτέλεσης ενός
σηµείου του κώδικα, εκτελώντας το συνολικό λογισµικό πολλές φορές. Κάθε φορά,
χρησιµοποιούνται δεδοµένα εισόδου που επιλέγονται από ένα σύνολο δεδοµένων
που έχει µια συγκεκριµένη κατανοµή. Μετά την εκτέλεση του δοκιµαζόµενου
σηµείου, καταγράφεται η κατάσταση δεδοµένων (αυτή είναι η «αρχική κατάστα-
ση δεδοµένων»)
• Ανάλυση µόλυνσης (infection analysis): Eάν ένα σηµείο κώδικα περιέχει ένα σφάλ-
µα και εάν το σηµείο αυτό εκτελεστεί κατά την εκτέλεση του προγράµµατος µε ένα
σύνολο δεδοµένων εισόδου, τότε το σφάλµα µπορεί να διαταράξει την ορθότητα
της κατάστασης των δεδοµένων. Τότε, η κατάσταση δεδοµένων για το συγκεκρι-
µένο σύνολο δεδοµένων εισόδου θεωρείται «µολυσµένη». Για να εκτιµήσει την
πιθανότητα µόλυνσης, ο αλγόριθµος ανάλυσης ευαισθησίας εφαρµόζει µια σειρά
συντακτικών παραλλαγών σε κάθε σηµείο. Ως συντακτική παραλλαγή ορίζεται η
αλλαγή από την αρχική σύνταξη σε µια νέα σύνταξη που είναι γραµµατικά ορθή
και έχει διαφορετικό νόηµα για ένα τουλάχιστον δεδοµένο εισόδου. Μετά από κάθε
παραλλαγή, το λογισµικό εκτελείται ξανά µε τυχαία δεδοµένα εισόδου και συγκρί-
νεται η κατάσταση δεδοµένων αµέσως µετά την εκτέλεση του δοκιµαζόµενου
σηµείου, µε την αρχική κατάσταση δεδοµένων. Εάν οι δύο καταστάσεις διαφέρουν,
τότε έχει συµβεί «µόλυνση».
• Ανάλυση διάδοσης (propagation analysis): Mετά την εκτέλεση του δοκιµαζόµε-
νου σηµείου, τροποποιούµε την παραγόµενη κατάσταση δεδοµένων δίνοντας µια
τυχαία τιµή (από ένα σύνολο τιµών µε συγκεκριµένη κατανοµή) σε ένα αντικείµε-
νο δεδοµένων. Έπειτα συνεχίζεται η εκτέλεση του προγράµµατος µέχρι να παρα-
χθεί κάποια έξοδος, την οποία συγκρίνουµε µε την έξοδο που θα είχε παραχθεί,εάν
δεν είχε γίνει τροποποίηση της κατάστασης δεδοµένων. Εάν αυτές διαφέρουν, τότε
το σφάλµα έχει διαδοθεί.
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 48
¶·Ú¿‰ÂÈÁÌ· 3.3
Επανερχόµαστε στο πρόγραµµα του πρώτου παραδείγµατος της ενότητας 3.1, το οποίο
τροποποιούµε ώστε να εκτελείται µόνο εάν τουλάχιστον ένας από τους B και C είναι
θετικός αριθµός
ΑΛΓΟΡΙΘΜΟΣ TEST – 1
ΑΡΧΗ
∆ΙΑΒΑΣΕ (B, C) ;
ΕΑΝ (Β>0) OR (C>0) ΤΟΤΕ {Αρχικό ΕΑΝ}
ΑΡΧΗ
A := B+C ;
X := A * C ;
EAN (A < X) ΤΟΤΕ {Εξωτερικό ΕΑΝ}
ΕΚΤΕΛΕΣΕ ΤΜΗΜΑ ΚΩ∆ΙΚΑ 1
ΑΛΛΙΩΣ
ΕΑΝ (B >= 1) OR (B <= – 1) ΤΟΤΕ {Εσωτερικό ΕΑΝ}
ΕΚΤΕΛΕΣΕ ΤΜΗΜΑ ΚΩ∆ΙΚΑ 2
ΑΛΛΙΩΣ
ΕΚΤΕΛΕΣΕ ΤΜΗΜΑ ΚΩ∆ΙΚΑ 3
ΕΑΝ – ΤΕΛΟΣ {Εσωτερικό ΕΑΝ}
ΕΑΝ – ΤΕΛΟΣ {Εξωτερικό ΕΑΝ}
ΤΕΛΟΣ
ΕΑΝ – ΤΕΛΟΣ {Αρχικό ΕΑΝ}
ΤΕΛΟΣ
Ας προσπαθήσουµε να προσδιορίσουµε την πιθανότητα αστοχίας του προγράµµατος,
εάν συµβεί λάθος στην εντολή Α : = Β + C, εφαρµόζοντας τις τρεις διαδικασίες της
ανάλυσης ευαισθησίας.
Κατά την ανάλυση εκτέλεσης, παρατηρούµε ότι η εκτέλεση αυτής της γραµµής κώδι-
κα εξαρτάται από την τιµή των B και C: εάν και οι δύο αριθµοί είναι αρνητικοί, αυτή
δεν εκτελείται. Ας υποθέσουµε στο παράδειγµά µας ότι από τα 100 δεδοµένα δοκιµής
4 9 3 . 3 ∞ ¡∞ § À ™ ∏ ∂ À∞ π ™ £∏™ π ∞ ™
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 49
5 0 K E ºA § A I O 3 : ¢ À ¡∞ ªπ ∫ ∂ ™ T ∂ Ã ¡π ∫ ∂ ™ ∂ & ∂
(τα οποία είναι ζεύγη τιµών για τους Β και C) που έχουµε επιλέξει, µόνο σε 10 από
αυτά οι δύο αριθµοί έχουν αρνητικές τιµές. Συνεπώς, η εντολή εκτελείται στο 90% των
περιπτώσεων δοκιµής, οπότε η πιθανότητα εκτέλεσης είναι Ρ
ε
=0,9.
Για να εφαρµόσουµε τις άλλες δύο διαδικασίες, πρώτα εισάγουµε ένα σφάλµα στο υπό
δοκιµή σηµείο του κώδικα: τροποποιούµε την εντολή Α := Β+C σε Α := Β – C. Ας εξε-
τάσουµε τη συµπεριφορά του προγράµµατος για 2 από τα 100 δεδοµένα δοκιµής:
Ζεύγος δεδοµένων Α: (Β=6, C=2) Ζεύγος ∆εδοµένων Β: (B= – 1, C=3)
Αναµενόµενη Παρατηρούµενη
κατάσταση κατάσταση
Αναµενόµενη Παρατηρούµενη
κατάσταση κατάσταση
Α = 8 Α=4
Χ = 16 Χ = 8
Α=2 Α= – 4
Χ=6 Χ= – 12
Τµήµα κώδικα που εκτελείται Τµήµα κώδικα που εκτελείται
ΤΜΗΜΑ 1 ΤΜΗΜΑ 1 ΤΜΗΜΑ 1 ΤΜΗΜΑ 2
Παρατηρούµε λοιπόν τα εξής:
• Kαι στις δύο περιπτώσεις δοκιµής, προκλήθηκε σφάλµα στην κατάσταση δεδοµέ-
νων του προγράµµατος, αφού οι µεταβλητές Α και Χ βρέθηκαν να έχουν διαφορε-
τική τιµή από την αναµενόµενη στην ορθή κατάσταση. Συνεπώς, η κατάσταση
δεδοµένων είναι και στις δύο περιπτώσεις µολυσµένη.
• Στην πρώτη περίπτωση δοκιµής, η µόλυνση δεν διαδόθηκε, αφού δεν προκλήθηκε
αλλαγή στην παρατηρούµενη έξοδο του προγράµµατος (και τις δύο φορές εκτελέ-
σθηκε το ΤΜΗΜΑ 1).
• Στη δεύτερη περίπτωση, εξαιτίας της µόλυνσης εκτελέσθηκε το ΤΜΗΜΑ 2 αντί
του ΤΜΗΜΑΤΟΣ 1, οπότε συµπεραίνουµε ότι η µόλυνση διαδόθηκε.
Κατά την ανάλυση µόλυνσης θα δοκιµάσουµε το «λανθασµένο» πρόγραµµα µε όλα
τα 100 δεδοµένα εισόδου και θα µετρήσουµε την πιθανότητα µόλυνσης Ρ
µ
ως το πλή-
θος των µολυσµένων καταστάσεων που παρατηρήθηκαν. Κατά την ανάλυση διάδο-
σης, εκτελούµε το πρόγραµµα µε την τροποποιηµένη κατάσταση δεδοµένων και
µετρούµε την πιθανότητα επίδρασης της τροποποίησης στις εξόδους του προγράµµα-
τος Ρ
δ
ως το πλήθος των µη αναµενόµενων εξόδων που παρατηρήθηκαν.
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 50
Το αποτέλεσµα της ανάλυσης ευαισθησίας είναι η εκτιµώµενη πιθανότητα αστοχίας του
προγράµµατος, εάν υπήρχε σφάλµα στη συγκεκριµένη εντολή, και προκύπτει πολλα-
πλασιάζοντας τους µέσους όρους των πιθανοτήτων Ρ
ε
, Ρ
µ
και Ρ
δ
. Εάν πολλαπλασιάσουµε
τις ελάχιστες τιµές των τριών πιθανοτήτων, τότε βρίσκουµε το κάτω όριο της πιθανότη-
τας αστοχίας του προγράµµατος εξαιτίας ενδεχόµενου λάθους στην εντολή αυτή.
Η ανάλυση ευαισθησίας βοηθά στον προσδιορισµό του αριθµού δοκιµών που απαι-
τούνται ώστε να πεισθούµε ότι σε ένα σύστηµα λογισµικού δεν υπάρχουν κρυµµένα
λάθη. Επιπλέον, βοηθά στην ανεύρεση τµηµάτων κώδικα που έχουν πολύ µικρή πιθα-
νότητα ελέγχου, ώστε να γίνουν περισσότερο συστηµατικές δοκιµές τους. Παρ’ όλο
που και οι δύο αρχικές υποθέσεις περιορίζουν το πλήθος των κατηγοριών σφαλµάτων
στα οποία µπορεί να εφαρµοστεί η ανάλυση ευαισθησίας, η πολυπλοκότητα των τριών
διαδικασιών ανάλυσης είναι ανάλογη µε το τετράγωνο των σηµείων κώδικα που εξε-
τάζονται. Χωρίς τους δύο αρχικούς περιορισµούς, η πολυπλοκότητα αυτή είναι µη
ιχνηλατήσιµη (intractable).
5 1 3 . 3 ∞ ¡∞ § À ™ ∏ ∂ À∞ π ™ £∏™ π ∞ ™
Αφού έχετε µελετήσει τις δυναµικές τεχνικές Ε&Ε που παρουσιάσθηκαν, να χαρα-
κτηρίσετε ως σωστό ή λάθος καθένα από τους παρακάτω ισχυρισµούς (οι τρεις πρώ-
τοι αναφέρονται στο στόχο κάθε τεχνικής και οι υπόλοιποι τρεις στη διαδικασία):
Σ Λ
Ο στόχος της συµβολικής εκτέλεσης είναι να προσδιορίσουµε
τις περιοχές τιµών των µεταβλητών για τις οποίες αλλάζει η ροή
εκτέλεσης του προγράµµατος. ❏ ❏
Ο στόχος των δοκιµών προσοµοίωσης είναι να µας δώσουν µια καλή
εικόνα της ιδανικής συµπεριφοράς του συστήµατος. ❏ ❏
Ο στόχος της ανάλυσης ευαισθησίας είναι να διορθώσει ακόµη
και τα µικρότερα λάθη που υπάρχουν στο λογισµικό. ❏ ❏
Κατά την ανάλυση ευαισθησίας εξετάζουµε τη σοβαρότητα
των επιπτώσεων και το βαθµό διάδοσης ενός σφάλµατος. ❏ ❏
Κατά τις δοκιµές προσοµοίωσης εφαρµόζουµε διάφορα σενάρια
χρήσης που αντιστοιχούν σε πραγµατικές περιπτώσεις χρήσης. ❏ ❏
Κατά τη συµβολική εκτέλεση, εισάγουµε λανθασµένα δεδοµένα
και παρατηρούµε τη συµπεριφορά του συστήµατος. ❏ ❏
ÕÛÎËÛË ·˘ÙÔ·ÍÈÔÏfiÁËÛ˘ 3.1
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 51
5 2 K E ºA § A I O 3 : ¢ À ¡∞ ªπ ∫ ∂ ™ T ∂ Ã ¡π ∫ ∂ ™ ∂ & ∂
™‡ÓÔ„Ë
Πριν προχωρήσουµε στα επόµενα κεφάλαια, όπου περιγράφονται οι δοκιµές εκτέλεσης
ενός συστήµατος λογισµικού, στο κεφάλαιο αυτό γνωρίσαµε πρώτα τρεις άλλες δυνα-
µικές τεχνικές Ε&Ε:
• Τη συµβολική εκτέλεση, στην οποία εκτελούµε το λογισµικό χρησιµοποιώντας συµ-
βολικά δεδοµένα αντί πραγµατικών τιµών στις µεταβλητές εισόδου του προγράµ-
µατος,
• τις δοκιµές προσοµοίωσης, στις οποίες εκτελούµε ένα ελλιπές σύστηµα λογισµικού
σαν να ήταν πλήρες, και
• την ανάλυση ευαισθησίας, η οποία στοχεύει να ανακαλύψει τη σοβαρότητα των
λαθών που αποµένουν στο πρόγραµµα, ώστε να καθορίσουµε πότε θα τερµατιστεί
ο έλεγχός του.
BÈ‚ÏÈÔÁÚ·Ê›·
[1] R. Fairley (1985), Software Engineering Concepts. McGraw – Hill, Singapore.
[2] M.L. Shooman (1983), Software Engineering. McGraw – Hill, Tokyo.
[3] Ε. Σκορδαλάκης (1991), Εισαγωγή στην Τεχνολογία Λογισµικού. Συµµετρία,
Αθήνα.
[4] J.M. Voas and K.W. Miller (1995), Software Testability: the new Verification. IEEE
Software, 12(3), pp 17 – 28.
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 52
∆¯ÓÈΤ˜ ™¯Â‰›·Û˘ ÙˆÓ ¶ÂÚÈÙÒÛÂˆÓ EϤÁ¯Ô˘ §ÔÁÈÛÌÈÎÔ‡
™ÎÔfi˜
Ο στόχος του κεφαλαίου είναι διττός: αφενός να σας εισάγει στο πνεύµα των στρατη-
γικών ελέγχου λογισµικού και αφετέρου να σας παρουσιάσει αναλυτικά τις «χαµηλού
επιπέδου» τεχνικές σχεδίασης περιπτώσεων ελέγχου για το λογισµικό.
¶ÚÔÛ‰ÔÎÒÌÂÓ· ·ÔÙÂϤÛÌ·Ù·
Όταν θα έχετε µελετήσει το κεφάλαιο αυτό, θα µπορείτε να:
• αναφέρετε τις τρεις γενικές αρχές και τα τέσσερα στάδια που πρέπει να ακολουθεί
µια στρατηγική ελέγχου λογισµικού,
• ορίσετε µια καλά σχεδιασµένη και µια επιτυχηµένη περίπτωση ελέγχου,
• περιγράψετε πέντε δραστηριότητες και τρεις φάσεις µιας στρατηγικής ελέγχου,
• περιγράψετε συνοπτικά τις τρεις µεθόδους σχεδίασης περιπτώσεων ελέγχου.
ŒÓÓÔȘ – ÎÏÂȉȿ
4
∫ ∂ º ∞ § ∞ π √
• περίπτωση ελέγχου,
• δεδοµένα ελέγχου,
• οµάδα δοκιµής,
• στρατηγική ελέγχου,
• µέθοδος λειτουργικού ελέγχου,
• µέθοδος ελέγχου αδιαφανούς κουτιού,
• µέθοδος δοµικού ελέγχου,
• µέθοδος ελέγχου διαφανούς κουτιού,
• έλεγχος / δοκιµές µονάδων,
• έλεγχος τµηµάτων,
• έλεγχος υπο – συστηµάτων,
• έλεγχος συστήµατος,
• έλεγχος αποδοχής,
• δοκιµές συγκρότησης,
• δοκιµές επικύρωσης,
• µέθοδος ελέγχου διεπαφών.
∂ÈÛ·ÁˆÁÈΤ˜ ·Ú·ÙËÚ‹ÛÂȘ
Στα πρώτα δύο κεφάλαια του τόµου έχουµε ήδη αναφερθεί στον έλεγχο λογισµικού
(software testing), τον οποίο παρουσιάσαµε σαν την πιο διαδεδοµένη και χρήσιµη µη
τυπική, δυναµική τεχνική Ε&Ε. Ο έλεγχος του λογισµικού περιλαµβάνει δραστηριότη-
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 53
τες µε τις οποίες δοκιµάζεται απευθείας ο κώδικας του λογισµικού και όχι κάποια ανα-
παράστασή του. Είναι δε τόσο σηµαντικές αυτές οι δραστηριότητες που έχουν ενσω-
µατωθεί στο µοντέλο κύκλου ζωής λογισµικού «καταρράκτης», οδηγώντας στην ανά-
πτυξη του µοντέλου V (το µοντέλο αυτό, µαζί µε µια συνοπτική περιγραφή των δρα-
στηριοτήτων ελέγχου, παρουσιάστηκαν στην ενότητα 1.1).
Ο έλεγχος ενός συστήµατος λογισµικού περιλαµβάνει τη δοκιµαστική του εκτέλεση χρη-
σιµοποιώντας δεδοµένα που µοιάζουν µε τα πραγµατικά δεδοµένα, τα οποία το λογι-
σµικό θα επεξεργάζεται όταν παραδοθεί προς χρήση. Κάθε δοκιµαστική εκτέλεση του
λογισµικού καλείται «περίπτωση ελέγχου» (test case), ενώ τα δεδοµένα εισόδου που
χρησιµοποιούνται σ’ αυτή καλούνται «δεδοµένα ελέγχου» (test data). Μια περίπτωση
ελέγχου περιγράφεται από τις προδιαγραφές εισόδου και εξόδου του λογισµικού υπό
δοκιµή, µαζί µε µια περιγραφή της επεξεργασίας που εκτελεί το λογισµικό. Τα δεδοµέ-
να ελέγχου σχεδιάζονται για να δοκιµαστεί η συµπεριφορά του λογισµικού σε σχέση µε
αυτές τις προδιαγραφές.
Είναι πρακτικά αδύνατο να σχεδιαστούν περιπτώσεις ελέγχου που θα δοκιµάζουν όλες
τις εντολές κάθε πιθανού µονοπατιού εκτέλεσης ενός προγράµµατος µε όλα τα δυνατά
δεδοµένα εισόδου (είναι δηλαδή αδύνατο να υποβληθεί ένα λογισµικό σε εξαντλητικό
έλεγχο – exhaustive testing). Ετσι, κάθε οργανισµός ανάπτυξης λογισµικού αναγκάζε-
ται να υιοθετήσει συγκεκριµένες στρατηγικές ελέγχου του λογισµικού (software testing
strategies) για να προσδιορίσει το ικανό και αναγκαίο υποσύνολο περιπτώσεων ελέγ-
χου που µπορεί να εγγυηθεί την αξιοπιστία του λογισµικού.
Μια στρατηγική ελέγχου λογισµικού καλό είναι να υιοθετεί τις εξής γενικές αρχές:
• Ο έλεγχος των δυνατοτήτων (λειτουργιών) του συστήµατος είναι πιο σηµαντικός από
τον έλεγχο των συστατικών του τµηµάτων, αφού ο χρήστης τελικά ενδιαφέρεται να
κάνει τη δουλειά του.
• Ο έλεγχος υπαρχουσών δυνατοτήτων είναι πιο σηµαντικός από τον έλεγχο νέων
δυνατοτήτων, αφού ο χρήστης έχει συνηθίσει στην ύπαρξη τους και αναµένει αυτές
να συνεχίσουν να παρέχονται.
• Ο έλεγχος τυπικών (συνηθισµένων) περιπτώσεων χρήσης είναι πιο σηµαντικός από
τον έλεγχο οριακών συνθηκών χρήσης, χωρίς βέβαια αυτό να σηµαίνει ότι πρέπει
να αγνοηθούν εντελώς οι οριακές καταστάσεις.
Το κεφάλαιο αυτό είναι αφιερωµένο στη σχεδίαση των δραστηριοτήτων ελέγχου λογι-
σµικού. Στην ενότητα 4.1 περιγράφεται γενικά ο τρόπος οργάνωσης του ελέγχου, ο στό-
χος των δραστηριοτήτων ελέγχου και οι ρόλοι που εµπλέκονται σε αυτές. Στην ενότη-
5 4 K E ºA § A I O 4 : ∆ ∂ à ¡π ∫ ∂ ™ ™ à ∂ ¢ π ∞ ™ ∏™ ∆ ø¡ ¶∂ ƒ π ¶∆ ø™ ∂ ø¡ E § ∂ ° à √À § √° π ™ ªπ ∫ √À
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 54
τα 4.2 περιγράφονται συνοπτικά οι στρατηγικές ελέγχου λογισµικού, οι οποίες παρου-
σιάζονται αναλυτικά στο Kεφάλαιο 5. Η αναφορά τους στο σηµείο αυτό στοχεύει να
σας βοηθήσει να αποκτήσετε µια σφαιρική εικόνα για τον τρόπο που εφαρµόζονται οι
δραστηριότητες ελέγχου. Στην επόµενη ενότητα (4.3) γίνεται µια γενική εισαγωγή στις
τεχνικές σχεδίασης περιπτώσεων ελέγχου, οι οποίες αποτελούν τις αρχικές και τις πιο
σηµαντικές δραστηριότητες µιας στρατηγικής ελέγχου λογισµικού. Στη συνέχεια παρου-
σιάζονται σε ξεχωριστές ενότητες οι τρεις µέθοδοι σχεδίασης περιπτώσεων ελέγχου που
χρησιµοποιούνται σήµερα, δηλαδή :
• ο λειτουργικός έλεγχος ή έλεγχος αδιαφανούς κουτιού, όπου περιλαµβάνονται τεχνι-
κές σχεδίασης περιπτώσεων ελέγχου µε τις οποίες δοκιµάζεται η εξωτερική συµπε-
ριφορά του λογισµικού σε σχέση µε τις προδιαγραφές εισόδου/εξόδου (ενότητα 4.4)
• ο δοµικός έλεγχος ή έλεγχος διαφανούς κουτιού, όπου περιλαµβάνονται τεχνικές σχε-
δίασης περιπτώσεων ελέγχου µε τις οποίες δοκιµάζεται η ορθότητα του κώδικα του
λογισµικού σε σχέση µε τις προδιαγραφές εκτέλεσης (ενότητα 4.5),
• ο έλεγχος διεπαφών, όπου περιλαµβάνονται τεχνικές σχεδίασης περιπτώσεων ελέγ-
χου µε τις οποίες δοκιµάζεται η επικοινωνία και η συγκρότηση των τµηµάτων του
λογισµικού (ενότητα 4.6),
Σε καθεµία από αυτές τις ενότητες περιγράφονται αναλυτικά διάφορες επί µέρους τεχνι-
κές σχεδίασης των δεδοµένων ελέγχου και δίνονται αντιπροσωπευτικά παραδείγµατα.
Ο στόχος της µελέτης σας δεν πρέπει να είναι µόνο να µάθετε τα βήµατα της κάθε τεχνι-
κής, αλλά και να κατανοήσετε τις κατηγορίες ελαττωµάτων του λογισµικού που µπορεί
να ανακαλύψει κάθε τεχνική και το κόστος της εφαρµογής της.
5 5 ∂ π ™ ∞ ° ø° π ∫ ∂ ™ ¶∞ ƒ∞∆ ∏ƒ ∏™ ∂ π ™
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 55
5 6 K E ºA § A I O 4 : ∆ ∂ à ¡π ∫ ∂ ™ ™ à ∂ ¢ π ∞ ™ ∏™ ∆ ø¡ ¶∂ ƒ π ¶∆ ø™ ∂ ø¡ E § ∂ ° à √À § √° π ™ ªπ ∫ √À
4.1 √ÚÁ¿ÓˆÛË ÙˆÓ ‰Ú·ÛÙËÚÈÔÙ‹ÙˆÓ ÂϤÁ¯Ô˘ ÏÔÁÈÛÌÈÎÔ‡
Στο Σχήµα 4.1 φαίνονται τα στάδια µιας στρατηγικής ελέγχου λογισµικού, η οποία
στοχεύει στην ανακάλυψη ατελειών στο λογισµικό (defect testing strategy). Μετά τη
σχεδίαση των περιπτώσεων και των δεδοµένων ελέγχου, το λογισµικό εκτελείται δοκι-
µαστικά και καταγράφονται τα αποτελέσµατα της εκτέλεσης. Στη συνέχεια, αυτά
συγκρίνονται µε τις προδιαγραφές εξόδου των περιπτώσεων ελέγχου και παράγονται
οι αναφορές δοκιµών, µε βάση τις οποίες θα γίνουν οι απαραίτητες διορθώσεις κατά
την εκσφαλµάτωση (debugging) του λογισµικού.
Αφού η βασική δραστηριότητα αυτής της κατηγορίας ελέγχου λογισµικού είναι η
εκτέλεση του προγράµµατος µε στόχο την ανακάλυψη ατελειών:
• µια καλά σχεδιασµένη περίπτωση ελέγχου ορίζεται ως η δοκιµή που έχει µεγάλη
πιθανότητα ανεύρεσης ενός κρυµµένου ελαττώµατος,
• µια επιτυχηµένη περίπτωση ελέγχου ορίζεται ως η δοκιµή που ανακαλύπτει του-
λάχιστον ένα κρυµµένο ελάττωµα.
Συνεπώς, εάν ένα σύνολο περιπτώσεων ελέγχου δεν αποκαλύψει κάποιο ελάττωµα,
αυτό δε σηµαίνει ότι το λογισµικό δεν έχει λάθη, αλλά ότι οι δοκιµές δεν ήταν σχε-
διασµένες αρκετά καλά ώστε να αποκαλύψουν τα ελαττώµατα!
Σχεδίαση 
Περιπτώσεων 
Eλέγχου
Προετοιµασία 
∆εδοµένων 
Eλέγχου
∆οκιµαστική 
Eκτέλεση 
Προγράµµατος
Aξιολόγηση 
Aποτελεσµάτων
Περιπτώσεις 
Eλέγχου
∆εδοµένα 
Eλέγχου
Aποτελέσµατα 
δοκιµών
Aναφορές
™¯‹Ì· 4.1
Τα στάδια µιας
στρατηγικής ελέγ-
χου λογισµικού
Επειδή όλα τα προηγούµενα µπορεί να σας φαίνονται αποκαρδιωτικά, σας προτείνω
στο σηµείο αυτό να σκεφτείτε και να περιγράψετε σε 50 – 100 λέξεις τη φιλοσοφία
που πρέπει να υιοθετήσει κάποιος που εµπλέκεται στον έλεγχο λογισµικού, ώστε να
οδηγηθεί σε σχεδίαση επιτυχηµένων δοκιµών.
¢Ú·ÛÙËÚÈfiÙËÙ· 4.1
Με βάση τους προηγηθέντες ορισµούς πρέπει να συµπεράνουµε, αντίθετα ίσως µε την
κοινή λογική, ότι, αφού µια επιτυχηµένη περίπτωση ελέγχου είναι αυτή που ανακα-
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 56
λύπτει ελαττώµατα, ο στόχος µας είναι να σχεδιάσουµε περιπτώσεις ελέγχου οι οποί-
ες συστηµατικά θα ανακαλύπτουν διαφορετικές κατηγορίες λαθών απαιτώντας όσο το
δυνατό λιγότερο κόπο και χρόνο. Οι δοκιµές µπορούν να δείξουν εάν το λογισµικό λει-
τουργεί σύµφωνα µε τις προδιαγραφές, αλλά και να χρησιµοποιηθούν για τη συλλογή
δεδοµένων µε τα οποία µπορεί να εκτιµηθεί η αξιοπιστία και η ποιότητα του λογισµι-
κού. Όµως, ο έλεγχος του λογισµικού δεν µπορεί να αποδείξει την απουσία ελαττω-
µάτων – µπορεί µόνο να δείξει την ύπαρξή τους.
Εάν ισχύουν όλα αυτά, ποιος είναι λοιπόν ο πλέον κατάλληλος για να ελέγξει ένα λογι-
σµικό; Ποιος θα µπορούσε να σχεδιάσει τις περισσότερο πετυχηµένες περιπτώσεις
ελέγχου; Εύκολα θα µπορούσαµε να απαντήσουµε «µα αυτός που το ανέπτυξε, αφού
το γνωρίζει καλύτερα από όλους!». Αυτή όµως η άποψη δεν λαµβάνει υπόψη τα εξής
δύο σηµεία:
• H οµάδα που ανέπτυξε το λογισµικό προσπαθεί να αποδείξει (συνειδητά ή όχι) ότι
αυτό δεν έχει ελαττώµατα και ότι λειτουργεί σύµφωνα µε τις προδιαγραφές
• Aπό ψυχολογική σκοπιά, ο έλεγχος του λογισµικού φαίνεται να είναι µια διαδικα-
σία καταστροφής (σε αντίθεση µε την ανάπτυξη λογισµικού που είναι µια δηµι-
ουργική διαδικασία), αφού στοχεύει στην «κατεδάφισή» του
Συνεπώς, η οµάδα ανάπτυξης έχει την τάση να µη σχεδιάζει «σκληρές» περιπτώσεις
ελέγχου, οι οποίες έχουν αυξηµένη πιθανότητα ανακάλυψης ελαττωµάτων στο λογι-
σµικό που η ίδια ανέπτυξε! Επειδή όµως όποιο ελάττωµα «ξεφύγει» από τον έλεγχο θα
ανακαλυφθεί από τον χρήστη, οπότε το κόστος της διόρθωσής του θα είναι πολλαπλά-
σιο, οι φορείς που αναπτύσσουν λογισµικό προτιµούν να συγκροτούν ανεξάρτητες οµά-
δες δοκιµής, τα µέλη των οποίων δεν έχουν εµπλακεί στις δραστηριότητες υλοποίη-
σης (αν και µπορεί να συµµετέχουν σε προηγούµενες φάσεις του κύκλου ανάπτυξης)
του λογισµικού και ουσιαστικά «πληρώνονται για να ανακαλύψουν ελαττώµατα».
5 7 4 . 1 √ƒ °∞ ¡ø™ ∏ ∆ ø¡ ¢ ƒ∞ ™ ∆ ∏ƒ π √∆ ∏∆ ø¡ ∂ § ∂ ° à √À § √° π ™ ªπ ∫ √À
Σηµειώστε ποιος είναι σωστός και ποιος λανθασµένος από τους παρακάτω ισχυ-
ρισµούς:
Σ Λ
1. Οι πρόσφατες εξαντλητικές δοκιµές του προγράµµατος Χ απέδειξαν
ότι δεν έχει ελαττώµατα. ❏ ❏
2. Η οµάδα ανάπτυξης του λογισµικού δεν πρέπει να το δοκιµάζει,
αφού έχει την τάση να αποφύγει να ανακαλύψει λάθη. ❏ ❏
ÕÛÎËÛË ·˘ÙÔ·ÍÈÔÏfiÁËÛ˘ 4.1
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 57
5 8 K E ºA § A I O 4 : ∆ ∂ à ¡π ∫ ∂ ™ ™ à ∂ ¢ π ∞ ™ ∏™ ∆ ø¡ ¶∂ ƒ π ¶∆ ø™ ∂ ø¡ E § ∂ ° à √À § √° π ™ ªπ ∫ √À
4.2 ™ÙÚ·ÙËÁÈΤ˜ ÂϤÁ¯Ô˘ ÙÔ˘ ÏÔÁÈÛÌÈÎÔ‡
Ο έλεγχος του λογισµικού είναι µια χρονοβόρος διαδικασία, η οποία εξελίσσεται στα-
διακά και περιλαµβάνει την επαναλαµβανόµενη εφαρµογή περιπτώσεων ελέγχου
(δηλαδή, τη δοκιµαστική εκτέλεση του λογισµικού µε «τεχνητά» δεδοµένα ελέγχου
και την αξιολόγηση της συµπεριφοράς του). Η στρατηγική ελέγχου αποτελεί τµήµα
του µοντέλου ανάπτυξης και υλοποιεί τη γενικότερη φιλοσοφία εφαρµογής των δρα-
στηριοτήτων ελέγχου που ασπάζεται η οµάδα ανάπτυξης.
Κάθε στρατηγική ελέγχου περιλαµβάνει έναν αριθµό δραστηριοτήτων, οι οποίες εκτε-
λούνται ακολουθιακά και σε άµεση σύνδεση µε τις δραστηριότητες ανάπτυξης
(Sommerville[96]). Μια δραστηριότητα ελέγχου οµαδοποιεί ένα σύνολο περιπτώσε-
ων ελέγχου, οι οποίες αφορούν σε συγκεκριµένο τµήµα του λογισµικού. Γενικά, οι
δοκιµές που περιλαµβάνονται στις δραστηριότητες της στρατηγικής προχωρούν:
• από το τµήµα προς το σύνολο: πρώτα δοκιµάζονται οι µονάδες και τα µικρά τµή-
µατα του λογισµικού και στη συνέχεια µεγαλύτερα υποσυστήµατα,
• από την οµάδα ανάπτυξης προς τους χρήστες: η οµάδα ανάπτυξης κάνει τις πρώ-
τες δοκιµές, έπειτα η οµάδα δοκιµής και τέλος οι χρήστες,
• από το περιβάλλον ανάπτυξης στο περιβάλλον λειτουργίας: οι πρώτες δοκιµές γίνο-
νται αναγκαστικά στο περιβάλλον όπου αναπτύσσεται το λογισµικό, ενώ η τελική
δοκιµή γίνεται πάντα στο περιβάλλον όπου αυτό θα χρησιµοποιηθεί.
Μια γενική στρατηγική ελέγχου περιλαµβάνει τις ακόλουθες δραστηριότητες (Σχήµα 4.2):
3. Το λογισµικό πρέπει να παραδοθεί σε ανεξάρτητη οµάδα δοκιµής,
η οποία έχει κάθε λόγο να το δοκιµάσει «ανελέητα». ❏ ❏
4. Για λόγους αξιοπιστίας, η οµάδα δοκιµής δεν πρέπει να εµπλακεί
καθόλου σε προηγούµενη φάση του έργου ανάπτυξης
του λογισµικού. ❏ ❏
5. Η ανάγκη ελέγχου του λογισµικού αποτελεί απόδειξη
της ανεπάρκειας της οµάδας ανάπτυξης και η δυσκολία
σχεδίασης των περιπτώσεων ελέγχου είναι µια µορφή «τιµωρίας». ❏ ❏
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 58
• έλεγχος µονάδων (unit testing): Oι διάφορες µονάδες του λογισµικού δοκιµάζο-
νται καθώς τελειώνει η ανάπτυξή τους, ανεξάρτητα από οποιαδήποτε άλλα τµή-
µατα του λογισµικού.
• έλεγχος τµηµάτων (module testing): Ένα τµήµα περιλαµβάνει σχετιζόµενες µονά-
δες και δοκιµάζεται ανεξάρτητα από άλλα τµήµατα. Πολλές φορές, η δραστηριό-
τητα αυτή ενσωµατώνεται στον έλεγχο µονάδων.
• έλεγχος υπο – συστηµάτων (sub – system testing): Oι µονάδες και τα τµήµατα
λογισµικού συγκροτούνται (ολοκληρώνονται) σε υπο – συστήµατα. Η δραστηριό-
τητα αυτή περιλαµβάνει δοκιµές συγκρότησης και διεπαφής ανάµεσα στα τµήµα-
τα του λογισµικού.
• έλεγχος συστήµατος (system testing): Περιλαµβάνει τη δοκιµή συγκρότησης των
υπο – συστηµάτων σε ένα σύστηµα και στοχεύει στην επικύρωση του λογισµικού
σε σχέση µε τις προδιαγραφές του. Πολλές φορές, ο έλεγχος υπο – συστηµάτων
συµπεριλαµβάνεται στον έλεγχο συστήµατος.
• έλεγχος αποδοχής (acceptance testing): Eίναι το τελευταίο στάδιο δοκιµών πριν
το σύστηµα παραδοθεί για χρήση. Για τον έλεγχο, ο οποίος συνήθως γίνεται στο
περιβάλλον λειτουργίας του λογισµικού, χρησιµοποιούνται πραγµατικά δεδοµένα.
Εκτός από την οµαδοποίηση των περιπτώσεων ελέγχου σε δραστηριότητες ελέγχου,
ανάλογα µε το τµήµα του λογισµικού στο οποίο αυτές εφαρµόζονται, οι περιπτώσεις
ελέγχου µπορούν να οµαδοποιηθούν ανάλογα µε το στόχο που εξυπηρετούν οι δοκι-
µές που περιλαµβάνονται σε αυτές. Οι στόχοι των επί µέρους δοκιµών ορίζουν τις ακό-
5 9 4 . 2 ™ ∆ ƒ ∆ ∏° π ∫ ∂ ™ ∂ § ∂ ° à √À ∆ √À § √° π ™ ªπ ∫ √À
∆οκιµές Mονάδων ∆οκιµές Συγκρότησης ∆οκιµές Eπικύρωσης
Έλεγχος 
Συστήµατος
Έλεγχος 
Αποδοχής
Έλεγχος 
Υποσυστη- 
µάτων
Έλεγχος  
Μονάδων
Έλεγχος 
Τµηµάτων
™¯‹Ì· 4.2
Οι δραστηριότητες
και οι φάσεις µιας
στρατηγικής
ελέγχου λογισµικού
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 59
6 0 K E ºA § A I O 4 : ∆ ∂ à ¡π ∫ ∂ ™ ™ à ∂ ¢ π ∞ ™ ∏™ ∆ ø¡ ¶∂ ƒ π ¶∆ ø™ ∂ ø¡ E § ∂ ° à √À § √° π ™ ªπ ∫ √À
λουθες τρεις φάσεις ελέγχου (Σχήµα 4.2):
• δοκιµή µονάδων λογισµικού: Περιλαµβάνει περιπτώσεις ελέγχου που ανήκουν
σε δραστηριότητες ελέγχου µονάδων ή τµηµάτων και στοχεύει στη δοκιµή της εκτέ-
λεσης κάθε εντολής ενός τµήµατος ή µιας µονάδας. Κάτι τέτοιο είναι εφικτό σε
αυτό το στάδιο, αφού το µέγεθος των µονάδων ή των τµηµάτων είναι µικρό. Για τη
σχεδίαση των περιπτώσεων ελέγχου χρησιµοποιούνται τεχνικές δοµικού ελέγχου,
ενώ για την εφαρµογή τους απαιτείται γνώση του τρόπου υλοποίησης των µονά-
δων ή τµηµάτων λογισµικού, γι’ αυτό και εκτελούνται από την οµάδα ανάπτυξης
του λογισµικού.
• δοκιµή συγκρότησης (integration testing): Περιλαµβάνει περιπτώσεις ελέγχου που
ανήκουν σε δραστηριότητες ελέγχου υπο – συστηµάτων και συστήµατος και στο-
χεύει στην επαλήθευση της σχεδίασης και της αρχιτεκτονικής του λογισµικού.
Εφαρµόζεται αφού τα επί µέρους τµήµατα έχουν συνενωθεί σε υπο – συστήµατα
και χρησιµοποιεί κυρίως τεχνικές λειτουργικού ελέγχου, για τη δοκιµή της επικοι-
νωνίας ανάµεσα στα τµήµατα αλλά και τεχνικές δοµικού ελέγχου για τη δοκιµή
των κυριότερων µονοπατιών εκτέλεσης του συνολικού υπο – συστήµατος. Εκτε-
λείται σε συνεργασία από την οµάδα ανάπτυξης και την οµάδα δοκιµής.
• δοκιµή επικύρωσης (validation testing): Περιλαµβάνει περιπτώσεις ελέγχου που
ανήκουν σε δραστηριότητες ελέγχου συστήµατος και αποδοχής και στοχεύει στη
διασφάλιση ότι το λογισµικό ικανοποιεί τις λειτουργικές προδιαγραφές του και έχει
την αναµενόµενη συµπεριφορά και τις απαιτούµενες επιδόσεις. Εφαρµόζεται από
την οµάδα δοκιµής και χρησιµοποιεί αποκλειστικά τεχνικές λειτουργικού ελέγχου
για τη σχεδίαση των περιπτώσεων ελέγχου.
Σηµειώνεται ότι η εφαρµογή δοκιµαστικών περιπτώσεων σε οποιοδήποτε επίπεδο
(εκτός του ελέγχου µονάδων) προϋποθέτει ότι έχει τελειώσει ο έλεγχος στο προη-
γούµενο επίπεδο. Έτσι, δεν αρχίζουµε π.χ. έλεγχο υποσυστήµατος, εάν δεν έχουµε
τελειώσει µε τον έλεγχο τµηµάτων. Αντίστοιχα, η εφαρµογή δοκιµαστικών περι-
πτώσεων για την επιδίωξη ενός στόχου προϋποθέτει ότι έχουν επιτευχθεί οι στόχοι
της προηγούµενης φάσης. Έτσι, δεν εφαρµόζουµε π.χ. δοκιµή συγκρότησης, εάν δεν
έχει επιτευχθεί ο στόχος της δοκιµής µονάδων.
Σχόλιο Μελέτης
Παράδειγµα της ενσωµάτωσης διαδικασιών ελέγχου σε ένα µοντέλο κύκλου ζωής
λογισµικού αποτελεί το µοντέλο V που παρουσιάστηκε στην ενότητα 1.1. Ανατρέξ-
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 60
4.2.1 ŒÏÂÁ¯Ô˜ ·ÓÙÈÎÂÈÌÂÓÔÛÙÚ·ÊÔ‡˜ ÏÔÁÈÛÌÈÎÔ‡
Οι διαδικασίες που έχουν περιγραφεί εφαρµόζονται εύκολα όταν ακολουθείται αυξη-
τική ανάπτυξη του λογισµικού. Όταν όµως ακολουθούµε αντικειµενοστραφή µεθο-
δολογία σχεδίασης και ανάπτυξης, τα στάδια συγκρότησης δεν είναι ξεκάθαρα. Σε
τέτοια περίπτωση, µερικές από τις προτεινόµενες δραστηριότητες ελέγχου είναι:
• έλεγχος κλάσεων και αντικειµένων (class & object testing): Aντιστοιχεί στον
έλεγχο µονάδων, αφού οι λειτουργίες και τα δεδοµένα ενσωµατώνονται σε κλά-
σεις και αντικείµενα.
• έλεγχος οµάδων (cluster testing): Περιλαµβάνει ένα σύνολο από κλάσεις που
συνεργάζονται στην παροχή ενός συνόλου υπηρεσιών.
• έλεγχος µονοπατιών που ακολουθούν τα µηνύµατα (method – message testing):
Περιλαµβάνει την ιχνηλάτηση µιας ακολουθίας µηνυµάτων που ανταλλάσσουν
τα αντικείµενα. Αυτή αρχίζει από κάποια µέθοδο ενός αντικειµένου (που υλο-
ποιεί κάποια λειτουργία), η οποία στέλνει κάποιο αρχικό µήνυµα σε κάποια µέθο-
δο άλλου αντικειµένου. Η τεχνική ακολουθεί όλα τα µηνύµατα που ανταλλάσ-
σονται ως συνέπεια του αρχικού µηνύµατος µέχρι τη µέθοδο εκείνη, η οποία δεν
στέλνει κανένα µήνυµα.
• έλεγχος ατοµικών λειτουργιών συστήµατος (atomic system function testing):
Στοχεύει στη δοκιµή της απόκρισης του λογισµικού σε κάποιο γεγονός εισόδου
(input event) και περιλαµβάνει το γεγονός και την ακολουθία των µηνυµάτων που
αυτό προκαλεί, η οποία τερµατίζεται από κάποιο γεγονός εξόδου (output event).
Το στάδιο αυτό µοιάζει µε τη δοκιµή εκφάνσεων εκτέλεσης (thread testing) που
χρησιµοποιείται κυρίως σε συστήµατα πραγµατικού χρόνου.
4.2.2 ¶fiÙ ÙÂÏÂÈÒÓÂÈ Ô ¤ÏÂÁ¯Ô˜;
Ένα άλλο σηµαντικό ερώτηµα στο οποίο πρέπει να απαντήσει µια στρατηγική ελέγχου
είναι «πότε τελειώνουν οι δοκιµές;» ή «πώς γνωρίζουµε ότι έχουµε δοκιµάσει αρκετά
ένα λογισµικό;». ∆υστυχώς, δεν υπάρχει οριστική απάντηση, αλλά η εµπειρία έχει δεί-
ξει ότι, ενώ στην πράξη, οι δοκιµές τελειώνουν όταν τελειώσει ο χρόνος ή τα χρήµατα,
στην πραγµατικότητα, ποτέ δεν τελειώνουµε µε τον έλεγχο ενός λογισµικού. Κάθε φορά
6 1 4 . 2 ™ ∆ ƒ ∆ ∏° π ∫ ∂ ™ ∂ § ∂ ° à √À ∆ √À § √° π ™ ªπ ∫ √À
τε στην ενότητα αυτή και µελετήστε το µοντέλο V µε στόχο να κατανοήσετε γιατί ο
έλεγχος του λογισµικού πρέπει να λαµβάνεται υπόψη και να σχεδιάζεται από τις αρχι-
κές φάσεις ανάπτυξης και πώς οι δραστηριότητες ελέγχου συσχετίζονται µε δρα-
στηριότητες ανάπτυξης.
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 61
6 2 K E ºA § A I O 4 : ∆ ∂ à ¡π ∫ ∂ ™ ™ à ∂ ¢ π ∞ ™ ∏™ ∆ ø¡ ¶∂ ƒ π ¶∆ ø™ ∂ ø¡ E § ∂ ° à √À § √° π ™ ªπ ∫ √À
που το λογισµικό χρησιµοποιείται, είναι σαν να δοκιµάζεται µε ένα νέο σύνολο δεδο-
µένων. Έτσι, αυτό που συµβαίνει µε το τέλος του ελέγχου είναι να µεταφέρεται η «ευθύ-
νη» από την οµάδα ανάπτυξης στους χρήστες του λογισµικού.
Βέβαια, ένας µηχανικός λογισµικού χρειάζεται «κριτήρια τερµατισµού των δοκιµών»,
ώστε να µεγιστοποιήσει την απόδοση των πόρων µέσα στο χρονοδιάγραµµα και να
ελαχιστοποιήσει τα ελαττώµατα που θα ανακαλύψει ο χρήστης. Τέτοια κριτήρια παρέ-
χει η θεωρία αξιοπιστίας λογισµικού (software reliability theory), σύµφωνα µε την
οποία συλλέγονται δεδοµένα κατά τις δοκιµές του λογισµικού και συγκρίνονται µε τα
αποτελέσµατα που δίνουν στατιστικά µοντέλα του αριθµού αστοχιών του λογισµικού
ως συνάρτηση του χρόνου εκτέλεσης.
4.3 ™¯Â‰›·ÛË ÂÚÈÙÒÛÂˆÓ ÂϤÁ¯Ô˘
Η σχεδίαση δοκιµών για το λογισµικό (αλλά και για άλλα προϊόντα εφαρµοσµένων επι-
στηµών ή µηχανικής) µπορεί να αποδειχθεί το ίδιο απαιτητική µε την ανάπτυξη του λογι-
σµικού. Αυτό επειδή οι δοκιµές πρέπει να σχεδιάζονται µε στόχο να ανακαλύψουν το
µεγαλύτερο αριθµό ελαττωµάτων (errors) µε το µικρότερο κόπο και στο συντοµότερο
χρόνο. Θυµηθείτε ότι ο στόχος των δραστηριοτήτων ελέγχου είναι να ανακαλύπτουν
ελαττώµατα και όχι να αποδείξουν την απουσία σφαλµάτων στον κώδικα.
Για τους λόγους αυτούς, τα τελευταία χρόνια έχουν παρουσιαστεί διάφορες τεχνικές
σχεδίασης δοκιµών, οι οποίες συµπεριλαµβάνουν ένα συστηµατικό τρόπο σχεδίασης
των περιπτώσεων και των δεδοµένων ελέγχου του λογισµικού. Αυτές οι τεχνικές οµα-
δοποιούνται σε δύο µεγάλες κατηγορίες, οι οποίες γενικά περιγράφουν δύο συµπλη-
ρωµατικές µεθόδους για τον έλεγχο ενός προϊόντος:
• Tη µέθοδο του λειτουργικού ελέγχου (functional testing) ή ελέγχου αδιαφανούς
κουτιού (black – box testing), όπως αλλιώς λέγεται, η οποία περιλαµβάνει τεχνι-
κές για τη δοκιµή των εξόδων σε σχέση µε τις εισόδους του συστήµατος, της επι-
κοινωνίας του λογισµικού µε άλλα τµήµατα λογισµικού και της ακεραιότητας των
δεδοµένων. Οι τεχνικές αυτές, γνωρίζοντας τις συγκεκριµένες λειτουργίες που πρέ-
πει να εκτελεί το λογισµικό, στοχεύουν στο να αποδείξουν ότι κάθε λειτουργία εκτε-
λείται πλήρως και σωστά.
• Tη µέθοδο του δοµικού ελέγχου (structural testing) ή ελέγχου διαφανούς κουτι-
ού (white – box testing), η οποία περιλαµβάνει την λεπτοµερή δοκιµή εκτέλεσης
των λογικών µονοπατιών εκτέλεσης του κώδικα και τη συστηµατική εξέταση της
κατάστασης δεδοµένων και ελέγχου του λογισµικού. Οι τεχνικές αυτές στοχεύουν
στο να αποδείξουν ότι οι εσωτερικές λειτουργίες του λογισµικού (ακόµη και σε επί-
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 62
πεδο κώδικα) είναι σύµφωνες µε τις προδιαγραφές και ότι όλα τα εµπεριεχόµενα
τµήµατα του λογισµικού συνεργάζονται σωστά. Η εφαρµογή τους προϋποθέτει
γνώση της εσωτερικής δοµής του λογισµικού.
Επίπλέον των δύο αυτών µεθόδων, οι οποίες ουσιαστικά δοκιµάζουν την ατοµική
συµπεριφορά τµηµάτων του λογισµικού, χρησιµοποιείται και η µέθοδος του ελέγχου
διεπαφών (interface testing). Οι τεχνικές της µεθόδου δοκιµάζουν τη συµπεριφορά
ενός τµήµατος λογισµικού σε σχέση µε τα υπόλοιπα τµήµατα λογισµικού, τα οποία
αυτό χρησιµοποιεί ή από τα οποία αυτό χρησιµοποιείται.
Αν και, κατ’ αρχήν, κάποια τεχνική από αυτές τις τρεις µεθόδους µπορεί να υιοθετη-
θεί σε οποιαδήποτε φάση ή δραστηριότητα ελέγχου, η πράξη έχει δείξει ότι ο δοµικός
έλεγχος είναι καλύτερο να εφαρµόζεται σε επίπεδο µονάδων ή τµηµάτων του λογι-
σµικού, ο έλεγχος διεπαφών σε επίπεδο υποσυστηµάτων και ο λειτουργικός έλεγχος
είναι καλύτερο να εφαρµόζεται σε επίπεδο συστήµατος (Σχήµα 4.3)
6 3 4 . 3 ™ à ∂ ¢ π ∞ ™ ∏ ¶∂ ƒ π ¶∆ ø™ ∂ ø¡ ∂ § ∂ ° à √À
Oµάδα ∆οκιµής
Λειτουργικός 
Έλεγχος
Έλεγχος 
∆ιεπαφών
∆οµικός 
Έλεγχος
Oµάδα Aνάπτυξης
Σύστηµα Yποσύστηµα Mονάδα – Tµήµα
™¯‹Ì· 4.3
Κατανοµή
δραστηριοτήτων
και αρµοδιοτήτων
δοκιµής
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 63
6 4 K E ºA § A I O 4 : ∆ ∂ à ¡π ∫ ∂ ™ ™ à ∂ ¢ π ∞ ™ ∏™ ∆ ø¡ ¶∂ ƒ π ¶∆ ø™ ∂ ø¡ E § ∂ ° à √À § √° π ™ ªπ ∫ √À
4.4 ∆¯ÓÈΤ˜ ÂϤÁ¯Ô˘ ·‰È·Ê·ÓÔ‡˜ ÎÔ˘ÙÈÔ‡
™ÎÔfi˜
Στην ενότητα αυτή θα παρουσιασθούν οι σηµαντικότερες τεχνικές σχεδίασης περιπτώ-
σεων ελέγχου για το λειτουργικό έλεγχο του λογισµικού. Κατά την εφαρµογή των τεχνι-
κών αυτών, το λογισµικό θεωρείται ως ένα «αδιαφανές κουτί», οπότε δεν χρειάζεται
να έχουµε γνώση της εσωτερικής λειτουργικότητας του λογισµικού.
¶ÚÔÛ‰ÔÎÒÌÂÓ· ·ÔÙÂϤÛÌ·Ù·
Όταν θα έχετε µελετήσει την ενότητα αυτή, θα µπορείτε να:
• αναφέρετε τέσσερις τρόπους ορισµού των δεδοµένων ελέγχου σύµφωνα µε την τεχνι-
κή διαµέρισης των δεδοµένων εισόδου σε κλάσεις ισοδυναµίας,
• αναφέρετε τέσσερις συµπληρωµατικούς τρόπους ορισµού των δεδοµένων ελέγχου
σύµφωνα µε την τεχνική της ανάλυσης των οριακών τιµών,
• αναφέρετε και εφαρµόσετε τα τέσσερα βήµατα της τεχνικής που χρησιµοποιεί γρα-
φήµατα αιτίου – αποτελέσµατος και πίνακες αποφάσεων,
• επιλέξετε και εφαρµόσετε την πιο κατάλληλη κατά περίπτωση από τις τέσσερις τεχνι-
κές σχεδίασης περιπτώσεων ελέγχου για το λειτουργικό έλεγχο του λογισµικού.
ŒÓÓÔȘ ÎÏÂȉȿ
• διαµέριση σε κλάσεις ισοδυναµίας,
• γράφηµα αιτίου – αποτελέσµατος,
• ανάλυση οριακών τιµών.
EÈÛ·ÁˆÁÈΤ˜ ·Ú·ÙËÚ‹ÛÂȘ
Στις τεχνικές του ελέγχου αδιαφανούς κουτιού ή λειτουργικού ελέγχου χρησιµοποι-
ούµε τις λειτουργικές απαιτήσεις ή προδιαγραφές ενός τµήµατος λογισµικού για να σχε-
διάσουµε τις περιπτώσεις ελέγχου του. Το τµήµα αυτό θεωρείται σαν ένα «αδιαφανές
κουτί», του οποίου η συµπεριφορά µπορεί να προσδιοριστεί µόνο µε την εξέταση των
εισόδων και των εξόδων του.
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 64
Ο έλεγχος αδιαφανούς κουτιού επιχειρεί να αποκαλύψει ελαττώµατα των εξής κατη-
γοριών:
• λανθασµένες ή απούσες λειτουργίες
• σφάλµατα επικοινωνίας
• σφάλµατα σε δοµές δεδοµένων ή στην προσπέλαση εξωτερικών βάσεων δεδοµένων
• ελαττώµατα στην απόδοση
• σφάλµατα αρχικοποίησης και τερµατισµού
Η εφαρµογή των τεχνικών της µεθόδου γίνεται σχεδιάζοντας ένα σύνολο δεδοµένων
ελέγχου εισόδου ικανών να εξετάσουν πλήρως την υλοποίηση των λειτουργικών απαι-
τήσεων ενός προγράµµατος. Το ζητούµενο κατά τη σχεδίαση των περιπτώσεων ελέγχου
είναι να βρούµε εκείνα τα δεδοµένα εισόδου που θα έχουν τη µεγαλύτερη πιθανότητα να
προκαλέσουν την εµφάνιση ανώµαλης συµπεριφοράς από το λογισµικό.
Αν και οι µηχανικοί λογισµικού συνηθίζουν να χρησιµοποιούν ευρετικές τεχνικές βασι-
σµένες στην εµπειρία τους για να βρουν τα κατάλληλα δεδοµένα ελέγχου, στη συνέχεια
περιγράφονται µερικές τεχνικές που µπορούν να συµβάλουν στη συστηµατική σχεδία-
ση περιπτώσεων ελέγχου.
4.4.1 ¢È·Ì¤ÚÈÛË Û ÎÏ¿ÛÂȘ ÈÛÔ‰˘Ó·Ì›·˜
Η τεχνική αυτή διαµερίζει το σύνολο των δεδοµένων εισόδου ενός προγράµµατος σε
κλάσεις δεδοµένων από τις οποίες είναι δυνατό να προκύψουν περιπτώσεις ελέγχου.
Βασίζεται στην παραδοχή ότι «ένα πρόγραµµα συνήθως συµπεριφέρεται µε παρόµοιο
(ισοδύναµο) τρόπο για όλα τα µέλη µιας κλάσης δεδοµένων εισόδου».
Η σχεδίαση περιπτώσεων ελέγχου µε την τεχνική της διαµέρισης σε κλάσεις ισοδυ-
ναµίας (equivalence partitioning) περιλαµβάνει αρχικά τον ορισµό κλάσεων ισοδυ-
ναµίας των καταστάσεων του προγράµµατος σε σχέση µε κάθε περιορισµό που ισχύ-
ει σε κάθε δεδοµένο εισόδου. Επειτα, σχεδιάζουµε περιπτώσεις ελέγχου για κάθε δεδο-
µένο εισόδου, φροντίζοντας σε κάθε περίπτωση να δοκιµάζεται ο µεγαλύτερος δυνα-
τός αριθµός χαρακτηριστικών µιας κλάσης.
6 5 4 . 4 ∆ ∂ à ¡π ∫ ∂ ™ ∂ § ∂ ° à √À ∞ ¢ π ∞ º∞ ¡√À ™ ∫ √À ∆ π √À
Οι κλάσεις ισοδυναµίας ορίζονται, ανάλογα µε το είδος του περιορισµού που εφαρ-
µόζεται σε ένα δεδοµένο εισόδου, µε τον ακόλουθο τρόπο:
• Eάν ο περιορισµός αφορά µια συγκεκριµένη τιµή, ορίζονται τρεις κλάσεις ισο-
δυναµίας, µια για τις έγκυρες και δύο για τις άκυρες καταστάσεις.
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 65
6 6 K E ºA § A I O 4 : ∆ ∂ à ¡π ∫ ∂ ™ ™ à ∂ ¢ π ∞ ™ ∏™ ∆ ø¡ ¶∂ ƒ π ¶∆ ø™ ∂ ø¡ E § ∂ ° à √À § √° π ™ ªπ ∫ √À
Αφού οριστούν οι κλάσεις ισοδυναµίας, πρέπει να σχεδιαστούν περιπτώσεις ελέγχου
για καθεµία από αυτές. Μία µέθοδος που δίνει ικανοποιητικά αποτελέσµατα περι-
λαµβάνει τη σχεδίαση περιπτώσεων ελέγχου για:
• δεδοµένα εισόδου που βρίσκονται κοντά στο µέσο της κλάσης, ώστε να δοκιµα-
σθεί η συµπεριφορά του προγράµµατος για «τυπικές» (συνηθισµένες) τιµές των
δεδοµένων εισόδου,
• δεδοµένα εισόδου που βρίσκονται κοντά στα όρια της κλάσης, ώστε να δοκιµασθεί
η συµπεριφορά του προγράµµατος για «οριακές» (µη αναµενόµενες) τιµές των
δεδοµένων εισόδου,
• δεδοµένα εισόδου τα οποία παράγουν δεδοµένα σε κάθε κλάση δεδοµένων εξόδου.
¶·Ú¿‰ÂÈÁÌ· 4.1
Έστω το πρόγραµµα ΑΝΑΖΗΤΗΣΗ, το οποίο αναζητά την εµφάνιση της ακέραιης
τιµής KEY µέσα σε ένα πίνακα ακεραίων Τ (ο δείκτης FIRST αναφέρεται στην πρώτη
θέση του πίνακα και ο LAST στην τελευταία):
ΑΛΓΟΡΙΘΜΟΣ ΑΝΑΖΗΤΗΣΗ
ΕΙΣΟ∆ΟΣ
Τ: ARRAY [FIRST..LAST] OF INTEGER ;
KEY: INTEGER ;
ΕΞΟ∆ΟΣ
POS: INTEGER ;
FOUND: BOOLEAN ;
Μαζί µε την περιγραφή των δεδοµένων εισόδου και εξόδου του προγράµµατος, χρει-
αζόµαστε και την ακόλουθη περιγραφή των προδιαγραφών λειτουργίας του (σηµειώ-
στε ότι επειδή εφαρµόζουµε τη µέθοδο ελέγχου αδιαφανούς κουτιού, δεν χρειαζόµα-
στε περιγραφή του κώδικα που υλοποιεί το πρόγραµµα):
Εάν η KEY βρεθεί σε κάποια θέση του Τ, το πρόγραµµα επιστρέφει τη θέση του πίνακα στη
µεταβλητή POS και θέτει τη BOOLEAN (λογική) µεταβλητή FOUND σε TRUE. Εάν η τιµή
• Eάν ο περιορισµός αφορά ένα πεδίο τιµών, ορίζονται πάλι τρεις κλάσεις ισοδυναµίας.
• Eάν ο περιορισµός αφορά συµµετοχή σε ένα σύνολο τιµών, ορίζονται δύο κλά-
σεις ισοδυναµίας, µια για τις έγκυρες και µια για τις άκυρες καταστάσεις.
• Eάν ο περιορισµός είναι λογικός, ορίζονται πάλι δύο κλάσεις ισοδυναµίας.
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 66
δεν βρεθεί, τότε η FOUND επιστρέφεται µε τιµή FALSE, ενώ η τιµή της µεταβλητής POS
είναι απροσδιόριστη. Το πρόγραµµα δεν εφαρµόζεται σε κενούς πίνακες.
Οι προδιαγραφές του προγράµµατος χρησιµοποιούνται για την εξαγωγή των ακόλου-
θων περιορισµών για τα δεδοµένα εισόδου και εξόδου:
Συνθήκες εισόδου:
FIRST <= LAST
Συνθήκες εξόδου:
FOUND = TRUE AND Τ[POS] = KEY
OR
FOUND = FALSE AND (¬∃ POS: FIRST <= POS <= LAST AND Τ[POS] =
KEY)
Από τις συνθήκες εισόδου προκύπτουν δύο κλάσεις ισοδυναµίας:
1. O πίνακας είναι κενός (FIRST > LAST).
2. O πίνακας περιέχει ένα τουλάχιστον στοιχείο (FIRST <= LAST).
Σύµφωνα όµως µε τις προδιαγραφές, ο αλγόριθµος δεν εφαρµόζεται σε κενό πίνακα,
οπότε θεωρούµε ότι πάντα βρισκόµαστε στη δεύτερη περίπτωση (FIRST <= LAST) και
χρησιµοποιούµε τις συνθήκες εξόδου για να σχεδιάσουµε τις εξής κλάσεις ισοδυναµίας:
• δεδοµένα εισόδου όπου η τιµή της µεταβλητής KEY υπάρχει στον πίνακα
(FOUND = TRUE),
• δεδοµένα εισόδου όπου η τιµή της µεταβλητής KEY δεν υπάρχει στον πίνακα
(FOUND = FALSE).
Σχεδιάζουµε τις περιπτώσεις ελέγχου αναζητώντας ένα συγκεκριµένο στοιχείο ΚΕΥ
στο δοκιµαστικό πίνακα [1, 3, 5, 4, 8]. Τότε προκύπτουν οι εξής περιπτώσεις ελέγχου:
6 7 4 . 4 ∆ ∂ à ¡π ∫ ∂ ™ ∂ § ∂ ° à √À ∞ ¢ π ∞ º∞ ¡√À ™ ∫ √À ∆ π √À
ΤΟ ∆Ε∆ΟΜΕΝΟ ΕΛΕΓΧΟΥ: ΕΙΣΟ∆ΟΣ ΕΞΟ∆ΟΣ
Είναι το πρώτο στοιχείο του πίνακα. KEY = 1 FOUND = TRUE & POS = 1
Είναι το τελευταίο στοιχείο του πίνακα. KEY = 8 FOUND = TRUE & POS = 5
Είναι ένα οποιοδήποτε «µεσαίο» στοιχείο
του πίνακα.
KEY = 5 FOUND = TRUE & POS = 3
∆εν βρίσκεται στον πίνακα. KEY = 12 FOUND = FALSE & POS= ?
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 67
6 8 K E ºA § A I O 4 : ∆ ∂ à ¡π ∫ ∂ ™ ™ à ∂ ¢ π ∞ ™ ∏™ ∆ ø¡ ¶∂ ƒ π ¶∆ ø™ ∂ ø¡ E § ∂ ° à √À § √° π ™ ªπ ∫ √À
Σηµειώστε ότι δεν έχουµε συµπεριλάβει περιπτώσεις ελέγχου όπου τα δεδοµένα εισό-
δου δίνονται στο πρόγραµµα µε λάθος σειρά ή είναι λανθασµένος ο τύπος τους, κλπ.
Τέτοια σφάλµατα συνήθως ανακαλύπτονται κατά την επισκόπηση του κώδικα, ή εφαρ-
µόζοντας κάποια άλλη στατική τεχνική εγκυροποίησης.
4.4.2 ∞Ó¿Ï˘ÛË ÔÚÈ·ÎÒÓ ÙÈÌÒÓ
Η τεχνική αυτή αναπτύχθηκε επειδή ο µεγαλύτερος αριθµός ελαττωµάτων τείνει να
εµφανίζεται στα όρια του πεδίου τιµών των δεδοµένων εισόδου. Η ανάλυση οριακών
τιµών (boundary value analysis) λειτουργεί συµπληρωµατικά προς την διαµέριση σε
κλάσεις ισοδυναµίας, οδηγώντας στη σχεδίαση περιπτώσεων ελέγχου «στα όρια τιµών»
κάθε κλάσης, ενώ µπορεί να εφαρµοστεί και στη σχεδίαση περιπτώσεων ελέγχου για
το πεδίο τιµών των δεδοµένων εξόδου.
Συνεπώς, οι οδηγίες σχεδίασης περιπτώσεων ελέγχου µοιάζουν πολύ µε αυτές της
διαµέρισης σε κλάσεις ισοδυναµίας:
• Eάν ένας περιορισµός καθορίζει ένα σύνολο τιµών, πρέπει να σχεδιασθούν περι-
πτώσεις ελέγχου για τη µεγαλύτερη και τη µικρότερη τιµή, αλλά και για τιµές λίγο
µεγαλύτερες ή µικρότερες από αυτές.
• Eάν ένας περιορισµός καθορίζει ένα πεδίο τιµών ανάµεσα στις τιµές Χ1 και Χ2,
πρέπει να σχεδιασθούν περιπτώσεις ελέγχου για τις τιµές Χ1 και Χ2, αλλά και για
τιµές λίγο µεγαλύτερες από τη Χ1 και λίγο µικρότερες από τη Χ2.
• Oι δύο προηγούµενες οδηγίες πρέπει να εφαρµοστούν και για τους περιορισµούς
που ισχύουν για τα δεδοµένα εξόδου.
• Eάν υπάρχουν εσωτερικές δοµές δεδοµένων µε καθορισµένα όρια (π.χ. πίνακες),
πρέπει να σχεδιασθούν περιπτώσεις ελέγχου της κάθε δοµής κοντά στα όριά της.
¶·Ú¿‰ÂÈÁÌ· 4.1 (συνέχεια)
Σύµφωνα µε τα προηγούµενα, για τον αλγόριθµο ΑΝΑΖΗΤΗΣΗ προκύπτουν δύο
ακόµη κλάσεις ισοδυναµίας µε βάση τον αριθµό των στοιχείων του πίνακα:
• περίπτωση όπου ο πίνακας έχει ένα µόνο στοιχείο (οριακή περίπτωση),
• περίπτωση όπου ο πίνακας έχει πολλά στοιχεία (συνηθισµένη περίπτωση).
Σχεδιάζουµε εκ νέου τις περιπτώσεις ελέγχου αναζητώντας ένα συγκεκριµένο στοιχείο
ΚΕΥ στον πίνακα. Τότε προκύπτουν οι εξής περιπτώσεις ελέγχου:
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 68
Ο ΠΙΝΑΚΑΣ ΕΧΕΙ: ΤΟ ∆Ε∆ΟΜΕΝΟ ΕΛΕΓΧΟΥ:
Ένα µόνο στοιχείο Βρίσκεται στον πίνακα.
Ένα µόνο στοιχείο ∆εν βρίσκεται στον πίνακα.
Πολλά στοιχεία Είναι το πρώτο στοιχείο του πίνακα.
Πολλά στοιχεία Είναι το τελευταίο στοιχείο του πίνακα.
Πολλά στοιχεία Είναι ένα οποιοδήποτε «µεσαίο» στοιχείο του πίνακα.
Πολλά στοιχεία ∆εν βρίσκεται στον πίνακα.
6 9 4 . 4 ∆ ∂ à ¡π ∫ ∂ ™ ∂ § ∂ ° à √À ∞ ¢ π ∞ º∞ ¡√À ™ ∫ √À ∆ π √À
Έστω η µεταβλητή Χ, η οποία παίρνει πραγµατικές τιµές από 1 έως 10. Προσπαθή-
στε να απαντήσετε στις εξής ερωτήσεις
(α) Πόσες και ποιες περιπτώσεις ελέγχου πρέπει να σχεδιάσετε σύµφωνα µε την τεχνι-
κή διαµέρισης σε κλάσεις ισοδυναµίας;
(β) Ποιες επιπλέον περιπτώσεις ελέγχου πρέπει να σχεδιάσετε σύµφωνα µε την ανά-
λυση οριακών τιµών;
(γ) Εάν η µεταβλητή έπαιρνε ακέραιες τιµές από έναν πίνακα Α 10 θέσεων, πόσες
περιπτώσεις ελέγχου θα έπρεπε να σχεδιάσετε σύµφωνα µε την τεχνική διαµέρι-
σης σε κλάσεις ισοδυναµίας;
ÕÛÎËÛË ·˘ÙÔ·ÍÈÔÏfiÁËÛ˘ 4.2
Θεωρείστε το πρόγραµµα ΥΠΟΛΟΓΙΣΜΟΣ – ΜΙΚΤΗΣ – ΑΜΟΙΒΗΣ, το οποίο χρη-
σιµοποιείται από το τµήµα µισθοδοσίας της επιχείρησης CHILDWARE στο τέλος
κάθε µήνα για την πληρωµή των υπαλλήλων της εταιρείας:
ΑΛΓΟΡΙΘΜΟΣ ΥΠΟΛΟΓΙΣΜΟΣ – ΜΙΚΤΗΣ – ΑΜΟΙΒΗΣ
ΕΙΣΟ∆ΟΣ
HOURS: ARRAY [1..31] OF INTEGER ;
HWAGES, BONUS, OVER: INTEGER ;
ΕΞΟ∆ΟΣ
MA: INTEGER ;
¢Ú·ÛÙËÚÈfiÙËÙ· 4.2
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 69
7 0 K E ºA § A I O 4 : ∆ ∂ à ¡π ∫ ∂ ™ ™ à ∂ ¢ π ∞ ™ ∏™ ∆ ø¡ ¶∂ ƒ π ¶∆ ø™ ∂ ø¡ E § ∂ ° à √À § √° π ™ ªπ ∫ √À
Θα σχεδιάσουµε τις περιπτώσεις ελέγχου για τον αλγόριθµο ΥΠΟΛΟΓΙΣΜΟΣ –
ΜΙΚΤΗΣ – ΑΜΟΙΒΗΣ βασιζόµενοι στις συνθήκες επί των δεδοµένων εισόδου και
χρησιµοποιώντας όσα αναφέρθηκαν στις ενότητες 4.4.1 και 4.4.2. Για κάθε µεταβλη-
τή εισόδου, τα δεδοµένα ελέγχου διαµερίζονται ως εξής:
ΜΕΤΑΒΛΗΤΗ ΕΙΣΟ∆ΟΥ (είδος) ΠΕΡΙΠΤΩΣΕΙΣ ΕΛΕΓΧΟΥ
HWAGES 1. HWAGES < 5
(πεδίο τιµών) 2. 5 = < HWAGES = < 10
3. HWAGES > 10
OVER 1. OVER in {60, 90, 120, 150, 180, 210}
(σύνολο τιµών) 2. OVER not in {60, 90, 120, 150, 180, 210}
BONUS 1. BONUS < 60
(τιµή) 2. BONUS = 60
3. BONUS > 60
(boolean) 4. BONUS = 0.
HOURS 1. HOURS είναι κενός.
(πίνακας) 2. HOURS περιέχει ένα στοιχείο.
3. HOURS περιέχει πολλά στοιχεία.
Για τη δοκιµή οριακών τιµών προσθέτουµε τις εξής περιπτώσεις ελέγχου:
Ο αλγόριθµος εκτελείται µία φορά για κάθε υπάλληλο και διαβάζει στην είσοδο ένα
πίνακα HOURS µε τις ώρες εργασίας ανά ηµέρα του υπαλλήλου, καθώς και το ωροµί-
σθιο HWAGES που αντιστοιχεί στο µισθολογικό του κλιµάκιο. Κάθε ηµέρα ένας υπάλ-
ληλος µπορεί να εργασθεί από 0 έως 6 ώρες, ενώ τα ωροµίσθια κυµαίνονται από € 5
έως € 10 Ακόµη, ένας υπάλληλος µπορεί να λαµβάνει µηνιαίο οικογενειακό επίδοµα
BONUS, το οποίο ξεκινά από € 60 για τους έγγαµους και αυξάνεται κατά € 30 ανά
παιδί, χωρίς όµως να ξεπερνά τα € 210 Τέλος, κάθε µήνα δίνεται σε έναν υπάλληλο επί-
δοµα παραγωγικότητας OVER ύψους € 60.
Ο αλγόριθµος υπολογίζει τη µικτή αµοιβή του υπαλλήλου στη µεταβλητή ΜΑ (η
οποία δεν µπορεί να πάρει αρνητικές τιµές). Εάν ένας υπάλληλος δεν εργαστεί καθό-
λου για κάποιο µήνα, τότε η αµοιβή του είναι µηδέν.
Προσπαθήστε να σχεδιάσετε τις δικές σας περιπτώσεις ελέγχου για το πρόγραµµα ΥΠΟ-
ΛΟΓΙΣΜΟΣ – ΜΙΚΤΗΣ – ΑΜΟΙΒΗΣ, πριν διαβάσετε την πρότασή µας που ακολουθεί.
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 70
ΜΕΤΑΒΛΗΤΗ ΕΙΣΟ∆ΟΥ (είδος) ΠΕΡΙΠΤΩΣΕΙΣ ΕΛΕΓΧΟΥ
HWAGES 4. 5=< HWAGES =< 5.1
(πεδίο τιµών) 5. 9.9 = < HWAGES =< 10
OVER 3. 30< OVER < 85
(σύνολο τιµών) 4. 190 < OVER < 240
HOURS 4. HOURS περιέχει δύο στοιχεία.
(πίνακας) 5. HOURS περιέχει είκοσι επτά στοιχεία.
6. HOURS περιέχει είκοσι οκτώ στοιχεία.
7. HOURS περιέχει είκοσι εννέα στοιχεία.
8. HOURS περιέχει τριάντα στοιχεία.
9. HOURS περιέχει τριάντα ένα στοιχεία.
10. ΗOURS περιέχει τριάντα δύο στοιχεία.
ΜΕΤΑΒΛΗΤΗ ΕΞΟ∆ΟΥ (είδος)
ΜΑ 1. ΜΑ < 0
(πεδίο τιµών) 2. ΜΑ = 0
3. 0 < ΜΑ < 180*
4. ΜΑ > 1.300*
* Με τις περιπτώσεις αυτές δοκιµάζουµε τη συµπεριφορά του προγράµµατος για πολύ χαµη-
λόµισθους και πολύ υψηλόµισθους υπαλλήλους.
4.4.3 °Ú·Ê‹Ì·Ù· ·ÈÙ›Ô˘ – ·ÔÙÂϤÛÌ·ÙÔ˜
Σύµφωνα µε την τεχνική αυτή, ακολουθούµε τέσσερα βήµατα για να περιγράψουµε
συνοπτικά τις λογικές συνθήκες και τις αντίστοιχες ενέργειες που περιέχονται σε ένα
πρόγραµµα:
1. Για κάθε τµήµα προγράµµατος, προσδιορίζουµε τους περιορισµούς στα δεδοµένα
εισόδου (αίτια) και τα αποτελέσµατά τους (ενέργειες).
2. Σχεδιάζουµε ένα γράφηµα αιτίου – αποτελέσµατος (cause – effect graph).
3. Mετατρέπουµε το γράφηµα σε ένα πίνακα αποφάσεων (οπότε, εάν έχει χρησιµο-
ποιηθεί πίνακας αποφάσεων κατά τη σχεδίαση του προγράµµατος, δεν είναι πια
απαραίτητη η εφαρµογή αυτής της τεχνικής).
4. Oι περιπτώσεις ελέγχου σχεδιάζονται ώστε να εξεταστεί κάθε κανόνας του πίνακα
αποφάσεων.
Ο βασικός συµβολισµός που χρησιµοποιείται στα γραφήµατα αιτίου – αποτελέσµα-
τος φαίνεται στο Σχήµα 4.4.
7 1 4 . 4 ∆ ∂ à ¡π ∫ ∂ ™ ∂ § ∂ ° à √À ∞ ¢ π ∞ º∞ ¡√À ™ ∫ √À ∆ π √À
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 71
7 2 K E ºA § A I O 4 : ∆ ∂ à ¡π ∫ ∂ ™ ™ à ∂ ¢ π ∞ ™ ∏™ ∆ ø¡ ¶∂ ƒ π ¶∆ ø™ ∂ ø¡ E § ∂ ° à √À § √° π ™ ªπ ∫ √À
¶·Ú¿‰ÂÈÁÌ· 4.2
Υποθέτουµε ότι η εταιρία CHILDWARE εφαρµόζει την ακόλουθη πολιτική παροχής
bonus σε καθεµία από τις τρεις κατηγορίες αµοιβών των υπαλλήλων της:
• Εάν ο υπάλληλος αµείβεται µε € 5 ανά ώρα, τότε είναι υποψήφιος για µηνιαίο
bonus σε περίπτωση που έχει συµπληρώσει περισσότερες από 120 ώρες εργασίας
χωρίς να έχει απουσιάσει ούτε µια ηµέρα. Αντίθετα, εάν συµπληρώσει λιγότερες
από 120 ώρες εργασίας και έχει απουσιάσει περισσότερες από 4 ηµέρες, στον υπάλ-
ληλο θα επιβληθεί επίπληξη
• Εάν ο υπάλληλος αµείβεται µε € 6 ανά ώρα, τότε µπορεί να πάρει µηνιαίο bonus
εάν έχει συµπληρώσει περισσότερες από 120 ώρες εργασίας (ακόµη και αν έχει
απουσιάσει περισσότερες από 4 ηµέρες), ή εάν δεν έχει απουσιάσει ούτε µια ηµέρα
(ακόµη και εάν δεν έχει συµπληρώσει 120 ώρες εργασίας). Αντίθετα, εάν δεν έχει
συµπληρώσει 120 ώρες εργασίας ενώ έχει απουσιάσει περισσότερες από 4 ηµέρες,
είναι υποψήφιος για επίπληξη
• Εάν ο υπάλληλος αµείβεται µε € 10 ανά ώρα, τότε λαµβάνει µηνιαίο bonus µόνο
σε περίπτωση που δεν έχει απουσιάσει ούτε µια ηµέρα, ενώ εάν έχει απουσιάσει
περισσότερες από 4 ηµέρες, θα του επιβληθεί επίπληξη
Θα προσπαθήσουµε να δοκιµάσουµε την ορθότητα ενός προγράµµατος που υπολογί-
ζει εάν σε κάποιον υπάλληλο θα δοθεί bonus ή θα επιβληθεί επίπληξη ή τίποτε από τα
δύο (µπορείτε να δοκιµάσετε να γράψετε έναν τέτοιο αλγόριθµο). Για να σχεδιάσου-
µε το γράφηµα αιτίου – αποτελέσµατος, πρέπει να εντοπίσουµε τις αιτίες (δηλαδή τους
περιορισµούς στα δεδοµένα εισόδου) και τα αποτελέσµατα (δηλαδή, τις ενέργειες που
πρέπει να γίνουν κάθε φορά):
ΑΙΤΙΑ ΑΠΟΤΕΛΕΣΜΑΤΑ
1. Ωροµίσθιο = 5 4. Ωρες > 120 101. Bonus
2. Ωροµίσθιο = 6 5. Ηµέρες απουσίας < 4 102. Επίπληξη
3. Ωροµίσθιο = 10 6. Ηµέρες απουσίας = 0
™¯‹Ì· 4.4
Βασικά σύµβολα
των γραφηµάτων
αιτίου –
αποτελέσµατος
Tαυτότητα
E
 
Λ
R
V
OR AND
EXCLUSIVE 
OR
NOT Aπαιτεί
~
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 72
Το γράφηµα αιτίου – αποτελέσµατος σχεδιάζεται ως εξής:
7 3 4 . 4 ∆ ∂ à ¡π ∫ ∂ ™ ∂ § ∂ ° à √À ∞ ¢ π ∞ º∞ ¡√À ™ ∫ √À ∆ π √À
Πριν προχωρήσετε, προσπαθήστε να βάλετε στη σωστή σειρά τα βήµατα της τεχνικής
σχεδίασης περιπτώσεων ελέγχου µε τη χρήση γραφήµατος αιτίου – αποτελέσµατος:
ΤΥΧΑΙΑ ΣΕΙΡΑ ΣΩΣΤΗ ΣΕΙΡΑ
Σχεδίαση περιπτώσεων ελέγχου 1.
Σχεδίαση του γραφήµατος αιτίου – αποτελέσµατος 2.
Σχεδίαση πίνακα αποφάσεων 3.
Προσδιορισµός αιτίων και ενεργειών 4.
ÕÛÎËÛË ·˘ÙÔ·ÍÈÔÏfiÁËÛ˘ 4.3
Η ∆ΕΗ χρησιµοποιεί διαφορετικό τρόπο πάγιας χρέωσης ενός καταναλωτή ηλε-
κτρικού ρεύµατος, ανάλογα µε το εάν αυτό διοχετεύεται σε κατοικία ή σε επιχείρη-
ση. Οι καταναλωτές έχουν τη δυνατότητα χρήσης και νυκτερινού τιµολογίου µόλις
καταναλώσουν 100 KWh ρεύµατος. Εάν η χρήση αφορά κατοικία και η κατανάλω-
¢Ú·ÛÙËÚÈfiÙËÙ· 4.3
Με βάση το γράφηµα κατασκευάζουµε τον πίνακα αποφάσεων και σχεδιάζουµε τις
περιπτώσεις ελέγχου ώστε να εκτελείται κάθε κανόνας του πίνακα.
E
Λ
Λ
Λ
Λ
Λ
Λ
Λ
R
V
~
~
~
1
2
3
4
5
6
11
13
12
22
23
21
24
26
25
101
102
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 73
7 4 K E ºA § A I O 4 : ∆ ∂ à ¡π ∫ ∂ ™ ™ à ∂ ¢ π ∞ ™ ∏™ ∆ ø¡ ¶∂ ƒ π ¶∆ ø™ ∂ ø¡ E § ∂ ° à √À § √° π ™ ªπ ∫ √À
Τα αίτια και τα αποτελέσµατα αυτού του προβλήµατος έχουν ως εξής:
ΑΙΤΙΑ ΑΠΟΤΕΛΕΣΜΑΤΑ
1. χρήση σε κατοικία 2. χρήση σε επιχείρηση 101. Πάγιο Α
3. κατανάλωση > 100 KWh 102. Πάγιο Β
4. κατανάλωση νυκτερινού > 100 KWh 103. Πάγιο Γ
Στη συνέχεια, σχεδιάζουµε το γράφηµα αιτίου – αποτελέσµατος και το µετατρέπουµε
σε ένα πίνακα αποφάσεων. Όταν προσπαθήσουµε να σχεδιάσουµε περιπτώσεις ελέγ-
χου για κάθε κανόνα του πίνακα αποφάσεων, θα διαπιστώσουµε ότι αυτός δεν περι-
λαµβάνει κανόνες για την περίπτωση όπου η χρήση αφορά επιχείρηση και η κατανά-
λωση νυκτερινού ρεύµατος είναι µικρότερη από 100 KWh.
4.4.4 ™˘ÁÎÚÈÙÈΤ˜ ‰ÔÎÈ̤˜
Οι τεχνικές συγκριτικής δοκιµής (comparison testing) ή αλλιώς δοκιµής κατ’ αντι-
παράθεση (back – to – bask testing) εφαρµόζονται σε περιπτώσεις όπου η αξιοπιστία
του προγράµµατος είναι τόσο κρίσιµη, ώστε το ίδιο λογισµικό (δηλαδή διαφορετικές
εκδόσεις του λογισµικού που ικανοποιούν τις ίδιες αρχικές προδιαγραφές) αναπτύσ-
σεται παράλληλα από διαφορετικές οµάδες. Άλλη περίπτωση εφαρµογής της τεχνικής
είναι ο έλεγχος µιας νεότερης έκδοσης ενός λογισµικού, η οποία έχει κοινή λειτουργι-
κότητα µε την προηγούµενη έκδοση.
Σε αυτές τις περιπτώσεις, κάθε έκδοση του λογισµικού πρέπει να δοκιµασθεί µε τα ίδια
δεδοµένα ελέγχου και να εξασφαλισθεί ότι όλες οι εκδόσεις παράγουν την ίδια έξοδο.
Οι περιπτώσεις ελέγχου σχεδιάζονται χρησιµοποιώντας κάποια από τις άλλες τεχνικές
ελέγχου αδιαφανούς κουτιού και εφαρµόζονται σε κάθε έκδοση του λογισµικού. Για
κάθε περίπτωση, εάν η έξοδος όλων των εκδόσεων είναι ίδια, θεωρούµε ότι όλες οι
εκδόσεις είναι σωστές. Εάν η έξοδος διαφέρει, τότε ελέγχονται όλες οι εκδόσεις για να
ανακαλυφθεί σε ποια (ή ποιες) βρίσκεται το ελάττωµα (και ποιο είναι αυτό).
ση είναι µικρότερη από 100 KWh, τότε ο καταναλωτής χρεώνεται µε πάγιο Α. Εάν
η κατανάλωση και στα δύο τιµολόγια ξεπεράσει τις 100 KWh, τότε χρεώνεται µε
πάγιο Γ, ενώ εάν η κατανάλωση του νυκτερινού είναι το πολύ ίση µε 100 KWh, χρε-
ώνεται µε πάγιο Β. Εάν η χρήση αφορά επιχείρηση και η κατανάλωση είναι µικρό-
τερη από 100 KWh, τότε ο καταναλωτής χρεώνεται µε πάγιο Α, ενώ εάν η κατανά-
λωση ξεπεράσει τις 100 KWh, τότε χρεώνεται µε πάγιο Γ. Προσπαθήστε να σχεδιά-
σετε περιπτώσεις ελέγχου για τον αλγόριθµο αυτό εφαρµόζοντας την τεχνική του
γραφήµατος αιτίου – αποτελέσµατος. Τι παρατηρείτε ;
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 74
7 5 4 . 4 ∆ ∂ à ¡π ∫ ∂ ™ ∂ § ∂ ° à √À ∞ ¢ π ∞ º∞ ¡√À ™ ∫ √À ∆ π √À
∆οκιµάστε να συµπληρώσετε τα κενά στο κείµενο που ακολουθεί χρησιµοποιώντας
(στην κατάλληλη πτώση) κάποιες από τις φράσεις:
Περιγραφή του κώδικα ∆ιαµέριση σε κλάσεις ισοδυναµίας
Προδιαγραφές εισόδου / εξόδου Εκτέλεση των περιορισµών
Γραφήµατα ροής Ανάλυση οριακών τιµών
Γραφήµατα αιτίου – αποτελέσµατος
Οι τεχνικές ελέγχου αδιαφανούς κουτιού χρησιµοποιούν …………………………..
για τη σχεδίαση των περιπτώσεων ελέγχου. Η βάση των τεχνικών αυτών είναι ……
………………………… των δεδοµένων εισόδου, δηλαδή η οµαδοποίηση των δεδο-
µένων ελέγχου µε βάση τους περιορισµούς εισόδου που ισχύουν στο υπό δοκιµή πρό-
γραµµα. Η τεχνική αυτή συνήθως συµπληρώνεται µε …………………., κατά την
οποία δοκιµάζεται η συµπεριφορά του προγράµµατος, όταν τα δεδοµένα ελέγχου
λαµβάνουν ακραίες τιµές σε σχέση µε τους ισχύοντες περιορισµούς. Εναλλακτικά,
µπορούν να χρησιµοποιηθούν τα …………………………… για να αναπαραστή-
σουν τον τρόπο µε τον οποίο οι έξοδοι του προγράµµατος εξαρτώνται από τους περιο-
ρισµούς που ισχύουν στα δεδοµένα εισόδου.
ÕÛÎËÛË ·˘ÙÔ·ÍÈÔÏfiÁËÛ˘ 4.4
Η εταιρεία THUNDERSOFT έχει αναλάβει την ανάπτυξη του λογισµικού για το λογι-
στήριο της CHILDWARE και σας έχει προσλάβει ως υπεύθυνο της οµάδας δοκιµής.
Μπορείτε να έχετε µία άποψη της αρχιτεκτονικής του λογισµικού ανατρέχοντας στο
Σχήµα 4.7 (βρίσκεται στην ενότητα 4.6 προς το τέλος του κεφαλαίου), χωρίς αυτό να
είναι απόλυτα απαραίτητο για την απάντηση της άσκησης. Εσείς χρειάζεται να γνω-
ρίζετε τις προδιαγραφές εισόδου / εξόδου (αλλά όχι την εσωτερική λειτουργικότητα)
όλων των τµηµάτων του προγράµµατος, από τις οποίες προκύπτουν τα εξής:
• Το υποσύστηµα αρχείου χρησιµοποιεί πολύπλοκες δοµές δεδοµένων.
• Το τµήµα υπολογισµού της µικτής αµοιβής εκτελεί υπολογισµούς µε πολλά και
διαφορετικά δεδοµένα, για τα οποία ισχύουν διάφοροι περιορισµοί.
• Το τµήµα υπολογισµού κρατήσεων παράγει διαφορετικό αποτέλεσµα ανάλογα µε
το συνδυασµό των περιορισµών που ισχύουν στα δεδοµένα εισόδου.
• Ως υποσύστηµα παραγωγής αναφορών θα χρησιµοποιηθεί µια βελτιωµένη έκδο-
ση ενός υπάρχοντος προγράµµατος.
ÕÛÎËÛË ·˘ÙÔ·ÍÈÔÏfiÁËÛ˘ 4.5
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 75
7 6 K E ºA § A I O 4 : ∆ ∂ à ¡π ∫ ∂ ™ ™ à ∂ ¢ π ∞ ™ ∏™ ∆ ø¡ ¶∂ ƒ π ¶∆ ø™ ∂ ø¡ E § ∂ ° à √À § √° π ™ ªπ ∫ √À
Με βάση τα προηγούµενα και όσα αναφέρθηκαν στην ενότητα 4.4, δοκιµάστε, στον
πίνακα που ακολουθεί, να αντιστοιχίσετε σε κάθε τµήµα / υποσύστηµα του προ-
γράµµατος (βρίσκεται στην αριστερή στήλη) τη βασική τεχνική σχεδίασης περιπτώ-
σεων ελέγχου που θα ακολουθήσετε, από αυτές που βρίσκονται στη δεξιά στήλη:
Αρχείο ∆ιαµέριση σε κλάσεις ισοδυναµίας
Υπολογισµός µικτής αµοιβής Ανάλυση οριακών τιµών
Υπολογισµός κρατήσεων Γράφηµα αιτίου – αποτελέσµατος
Παραγωγή αναφορών Συγκριτική δοκιµή
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 76
4.5 ∆¯ÓÈΤ˜ ÂϤÁ¯Ô˘ ‰È·Ê·ÓÔ‡˜ ÎÔ˘ÙÈÔ‡
™ÎÔfi˜
Στην ενότητα αυτή θα παρουσιασθούν οι σηµαντικότερες τεχνικές σχεδίασης περι-
πτώσεων ελέγχου για το δοµικό έλεγχο του λογισµικού. Οι τεχνικές αυτές θεωρούν
το λογισµικό ως ένα «διαφανές κουτί», οπότε κατά την εφαρµογή τους χρειάζεται να
έχουµε γνώση της εσωτερικής λειτουργικότητας του λογισµικού.
¶ÚÔÛ‰ÔÎÒÌÂÓ· ·ÔÙÂϤÛÌ·Ù·
Όταν θα έχετε µελετήσει την ενότητα αυτή, θα µπορείτε να:
• αναφέρετε τα τέσσερα βήµατα της τεχνικής που βασίζεται στον έλεγχο των βασι-
κών µονοπατιών εκτέλεσης του λογισµικού,
• περιγράψετε τους ελέγχους που µπορούν να εφαρµοστούν σε καθένα από τα τέσ-
σερα είδη επαναληπτικών προγραµµατιστικών δοµών,
• επιλέξετε και εφαρµόσετε κατά περίπτωση την πιο κατάλληλη από τις δύο τεχνικές
σχεδίασης περιπτώσεων ελέγχου για το δοµικό έλεγχο του λογισµικού.
ŒÓÓÔȘ ÎÏÂȉȿ
• δοκιµή βασικών µονοπατιών,
• κυκλωµατική πολυπλοκότητα,
• γράφηµα ροής,
• δοκιµή δοµών επανάληψης.
EÈÛ·ÁˆÁÈΤ˜ ·Ú·ÙËÚ‹ÛÂȘ
Χρησιµοποιώντας τεχνικές ελέγχου διαφανούς κουτιού µπορούµε να σχεδιάσουµε
περιπτώσεις ελέγχου οι οποίες:
• εγγυώνται ότι η εκτέλεση κάθε ανεξάρτητου λογικού µονοπατιού ενός προγράµ-
µατος έχει δοκιµαστεί τουλάχιστον µια φορά,
• εξετάζουν την επίδραση στην εκτέλεση του προγράµµατος κάθε λογικής συνθήκης
(απόφασης) τόσο όταν αυτή είναι αληθής όσο και όταν είναι ψευδής,
• εκτελούν κάθε δοµή επανάληψης, µε τιµές κανονικές αλλά και κοντά στα όρια,
• ελέγχουν την εγκυρότητα των εσωτερικών δοµών δεδοµένων.
7 7 4 . 5 ∆ ∂ à ¡π ∫ ∂ ™ ∂ § ∂ ° à √À ¢ π ∞ º∞ ¡√À ™ ∫ √À ∆ π √À
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 77
7 8 K E ºA § A I O 4 : ∆ ∂ à ¡π ∫ ∂ ™ ™ à ∂ ¢ π ∞ ™ ∏™ ∆ ø¡ ¶∂ ƒ π ¶∆ ø™ ∂ ø¡ E § ∂ ° à √À § √° π ™ ªπ ∫ √À
Γιατί, λοιπόν, χρειαζόµαστε τον έλεγχο διαφανούς κουτιού, ενώ φαίνεται ότι µπο-
ρούµε να διασφαλίσουµε την ορθότητα της (παρατηρήσιµης) λειτουργίας του λογι-
σµικού µε έλεγχο αδιαφανούς κουτιού; Η απάντηση βρίσκεται στη φύση των ελατ-
τωµάτων του λογισµικού:
• Tα σφάλµατα τείνουν να «συγκεντρώνονται» σε µονοπάτια που εκτελούνται σπά-
νια ή σε ειδικές περιπτώσεις. Στην πραγµατικότητα φαίνεται ότι το πλήθος λογι-
κών ελαττωµάτων και λανθασµένων υποθέσεων είναι αντιστρόφως ανάλογο µε
την πιθανότητα εκτέλεσης ενός µονοπατιού του προγράµµατος.
• Ίσως δεν έχουµε αντιληφθεί καλά τη λογική ροή εκτέλεσης του προγράµµατος, µε
αποτέλεσµα να πιστεύουµε ότι κάποιο µονοπάτι έχει µικρή συχνότητα εκτέλεσης,
ενώ, στην πραγµατικότητα, αυτό εκτελείται τακτικά.
• Eίναι πιθανό κάποια σηµασιολογικά λάθη να µην ανακαλυφθούν κατά τη µετα-
γλώττιση του πηγαίου κώδικα. Τέτοια λάθη, όµως, µπορεί να βρίσκονται τόσο σε ένα
µονοπάτι εκτέλεσης που εκτελείται συχνά, όσο και σε κάποιο που εκτελείται σπάνια.
Οι έλεγχοι αδιαφανούς κουτιού δεν µπορούν να αποκαλύψουν τέτοιου είδους ελατ-
τώµατα (να θυµάστε ότι «τα σφάλµατα καραδοκούν στις γωνίες και συγκεντρώνο-
νται στα όρια»)
4.5.1 ¢ÔÎÈÌ‹ ‚·ÛÈÎÒÓ ÌÔÓÔ·ÙÈÒÓ
Η τεχνική δοκιµής των βασικών µονοπατιών (basis path testing) προτάθηκε αρχι-
κά από τον Tom McCabe και περιλαµβάνει τον προσδιορισµό ενός συνόλου βασι-
κών µονοπατιών εκτέλεσης του προγράµµατος και τη σχεδίαση περιπτώσεων ελέγ-
χου για τα µονοπάτια αυτά. Κάθε µονοπάτι εκτέλεσης ξεκινά από τον κόµβο εισό-
δου του προγράµµατος, περιλαµβάνει µια ακολουθία από ενδιάµεσους κόµβους και
τελειώνει στον κόµβο εξόδου. Εάν κάθε βασικό µονοπάτι δοκιµαστεί, τότε κάθε εντο-
λή του προγράµµατος θα έχει εκτελεστεί δοκιµαστικά τουλάχιστον µια φορά.
Το γράφηµα ροής
Για τη γραφική αναπαράσταση των µονοπατιών εκτέλεσης χρησιµοποιείται ο συµβολι-
σµός των γραφηµάτων ροής (flowgraphs). Ενα γράφηµα ροής αποτελείται από κορυ-
φές, οι οποίες αντιπροσωπεύουν µία ή περισσότερες εντολές του προγράµµατος και πλευ-
ρές, οι οποίες αντιπροσωπεύουν ροή ελέγχου. Κάθε πλευρά πρέπει να τερµατίζει πάνω
σε µια κορυφή. Ο χώρος που περικλείεται από πλευρές και κορυφές καλείται «περιοχή».
Όπως φαίνεται στο Σχήµα 4.5, κάθε προγραµµατιστική δοµή του δοµηµένου προ-
γραµµατισµού µπορεί να αναπαρασταθεί µε ένα γράφηµα ροής, συνεπώς, για κάθε
K·Ì¤·˜ II (224) 18/7/2003 11:19 ™ÂÏ›‰· 78
αναπαράσταση διαδικασιακού προγράµµατος µπορεί να κατασκευαστεί ένα αντί-
στοιχο γράφηµα ροής. Στο Σχήµα 4.5, κάθε κύκλος αναπαριστά µία ή περισσότερες
εντολές προγράµµατος που εκτελούνται ακολουθιακά.
7 9 4 . 5 ∆ ∂ à ¡π ∫ ∂ ™ ∂ § ∂ ° à √À ¢ π ∞ º∞ ¡√À ™ ∫ √À ∆ π √À
™¯‹Ì· 4.5
Γραφήµατα ροής
για τις απλές
προγραµµατιστικές
δοµές
Aκολουθία
Aπόφαση
Eπανάλυψη 
Mέχρι
Eπανάλυψη 
Eνόσω
Πολλαπλή 
Eπιλογή
¶·Ú¿‰ÂÈÁÌ· 4.3
Έστω ο ακόλουθος αλγόριθµος, ο οποίος διαβάζει το πολύ 100 ακεραίους και υπο-
λογίζει τη µέση τιµή (ΜΤΜ), το άθροισµα (SUM) και το πλήθος (VALID) όσων από
αυτούς βρίσκονται ανάµεσα στις τιµές ΜΙΝ και ΜΑΧ. Το πλήθος των ακεραίων
εισόδου µετρείται από την INP, ενώ, εάν αυτό είναι µικρότερο από 100, η τιµή – 999
χρησιµοποιείται για να δηλώσει το τέλος των δεδοµένων εισόδου.
AΛΓOPIΘMOΣ MEΣH TIMH 
∆E∆OMENA 
I, INP, VALID, SUM: INTEGER; 
MTM: REAL; 
VAL: ARAY [1..100] OF INTEGER; 
APXH 
SUM = INP = VALID = MTM: = 0; 
I: = 1; 
ENOΣΩ ((VAL[I]< > –999) AND (INP < 100)) EΠANAΛABE 
INP: = INP + 1; 
EAN ((VAL[I] > MIN) AND (VAL[I] < MAX)) TOTE 
VALID: = VALID + 1; 
SUM: = SUM + VAL[I] 
EAN – TEΛOΣ; 
I: = I + 1 
ENOΣΩ – TEΛOΣ; 
EAN (INP > 0) TOTE 
MTM: = SUM / VALID 
AΛΛIΩΣ 
MTM: = –999 
EAN – TEΛOΣ 
TEΛOΣ
1
2
5
9
3
6 4
7
8
11
12
13
10
Στο Σχήµα 4.6(α) φαίνεται το ∆ιάγραµµα Ροής Προγράµµατος (∆ΡΠ), ενώ στο Σχήµα
4.6(β) φαίνεται το αντίστοιχο γράφηµα ροής. Παρατηρήστε τον τρόπο µε τον οποίο τα
σηµεία του ∆ΡΠ αντιστοιχούν σε κορυφές του γραφήµατος και προσπαθήστε να τα
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 79
8 0 K E ºA § A I O 4 : ∆ ∂ à ¡π ∫ ∂ ™ ™ à ∂ ¢ π ∞ ™ ∏™ ∆ ø¡ ¶∂ ƒ π ¶∆ ø™ ∂ ø¡ E § ∂ ° à √À § √° π ™ ªπ ∫ √À
™¯‹Ì· 4.6
Το ∆ΡΠ και το γράφηµα ροής του αλγορίθµου
ΜΕΣΗ ΤΙΜΗ
Aρχή 1
1
1
2
2
2
3
3
3
4
4
4
5
5
5
6
6
6
7
7
8
8
9
9
10
10
11
11
12
12
13
13
I=I+1
Yes
Yes
Yes
Yes
Yes
No
No
No
No
No
Tέλος
(α)
(β)
SUM = 0 
INP = 0 
VALID = 0 
MTM = 0 
I = 1
VAL[I] < > – 999
INP < 100
INP > 0
INP = INP + 1
VAL[1] > MIN
VAL[1] < MAX
VALID = VALID + 1 
SUM = SUM + VAL[I]
MTM = –999 MTM = SUM/VALID
συσχετίσετε µε τους αντίστοιχους αριθµούς που περιλαµβάνονται στην περιγραφή του
αλγορίθµου. Προσέξτε τα εξής:
• Εντολές επεξεργασίας που εκτελούνται ακολουθιακά οµαδοποιούνται σε ένα κόµβο
(π.χ. κόµβοι 1 και 7).
• Οι δύο σύνθετες συνθήκες (κόµβοι 2 & 3, 5 & 6) του αλγορίθµου χρειάζεται να
διασπαστούν σε απλές συνθήκες, καθώς καθεµία από αυτές µπορεί να καθορίσει
τη ροή εκτέλεσης.
• Ως κόµβοι µπορεί να ορίζονται και εντολές που απλά σηµαίνουν το τέλος κάποιας
δοµής (π.χ. κόµβοι 8, 9, 13).
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 80
Το σύνολο βασικών µονοπατιών και η κυκλωµατική πολυπλοκότητα
Λέγοντας «σύνολο βασικών µονοπατιών» εννοούµε ένα σύνολο από ανεξάρτητα µονο-
πάτια εκτέλεσης του προγράµµατος. Αυτό σηµαίνει ότι κανένα από τα µονοπάτια του
συνόλου δεν µπορεί να παραχθεί συνενώνοντας δύο ή περισσότερα άλλα µονοπάτια
του συνόλου. Ακόµη, κάθε εντολή του προγράµµατος πρέπει να ανήκει σε ένα του-
λάχιστον τέτοιο µονοπάτι. Κάθε άλλο µονοπάτι εκτέλεσης (πέραν των βασικών) προ-
κύπτει συνδυάζοντας δύο τουλάχιστον µονοπάτια από το σύνολο αυτό.
Μπορούµε να ορίσουµε αυστηρότερα το σύνολο των βασικών µονοπατιών ως τη βάση
του χώρου των µονοπατιών εκτέλεσης του προγράµµατος: όλα τα υπόλοιπα µονοπά-
τια εκτέλεσης είναι γραµµικώς εξαρτηµένα µε το σύνολο αυτό. Χρησιµοποιώντας την
αναπαράσταση των γραφηµάτων ροής, ένα ανεξάρτητο µονοπάτι εκτέλεσης περιλαµ-
βάνει τουλάχιστον µια πλευρά που δεν ανήκει σε κανένα άλλο µονοπάτι από το σύνο-
λο βασικών µονοπατιών.
Για τον προσδιορισµό του πλήθους των µονοπατιών που ορίζουν ένα σύνολο βασικών
µονοπατιών εκτέλεσης χρησιµοποιείται ένα µέγεθος που καλείται «κυκλωµατική
πολυπλοκότητα» (cyclomatic complexity). Το µέγεθος αυτό αποτελεί µέτρο της λογι-
κής πολυπλοκότητας του προγράµµατος και ταυτόχρονα παρέχει ένα άνω όριο του
αριθµού των δοκιµών που πρέπει να εφαρµόσουµε, ώστε να διασφαλίσουµε ότι η εκτέ-
λεση κάθε εντολής του προγράµµατος έχει δοκιµαστεί τουλάχιστον µια φορά και η
εκτέλεση κάθε συνθήκης έχει δοκιµαστεί τόσο για την περίπτωση που η συνθήκη είναι
αληθής, όσο και για την περίπτωση που αυτή είναι ψευδής.
Η κυκλωµατική πολυπλοκότητα V(G) ενός γραφήµατος G που έχει Ν κορυφές και Ε
πλευρές υπολογίζεται µε έναν από τους εξής τρεις τρόπους (εάν έχει δηµιουργηθεί
σωστά το γράφηµα ροής και οι τρεις τρόποι θα δώσουν το ίδιο αποτέλεσµα):
• Eίναι ίση µε το πλήθος των περιοχών του γραφήµατος.
• Oρίζεται ως V(G) = E – N + 2.
• Oρίζεται ως V(G) = P + 1, όπου Ρ το πλήθος των απλών συνθηκών του προγράµ-
µατος (γι’ αυτό και πρέπει πρώτα να διασπώνται οι σύνθετες συνθήκες πριν επι-
χειρήσουµε τον υπολογισµό της κυκλωµατικής πολυπλοκότητας).
¶·Ú¿‰ÂÈÁÌ· 4.3 (συνέχεια)
Η κυκλωµατική πολυπλοκότητα του προγράµµατος υπολογισµού της µέσης τιµής, υπο-
λογίζεται, σύµφωνα µε τους τρεις τρόπους που προαναφέρθηκαν, ως εξής:
• Tο γράφηµα έχει έξι περιοχές (αριθµούνται στο Σχήµα 4.6(β)).
• V(G) = 17 πλευρές – 13 κορυφές + 2 = 6
8 1 4 . 5 ∆ ∂ à ¡π ∫ ∂ ™ ∂ § ∂ ° à √À ¢ π ∞ º∞ ¡√À ™ ∫ √À ∆ π √À
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 81
8 2 K E ºA § A I O 4 : ∆ ∂ à ¡π ∫ ∂ ™ ™ à ∂ ¢ π ∞ ™ ∏™ ∆ ø¡ ¶∂ ƒ π ¶∆ ø™ ∂ ø¡ E § ∂ ° à √À § √° π ™ ªπ ∫ √À
• V(G) = 5 κόµβοι συνθηκών + 1 = 6
Τα βασικά µονοπάτια εκτέλεσης για το πρόγραµµα ΜΕΣΗ – ΤΙΜΗ είναι:
1. 1 – 2 – 10 – 11 – 13
2. 1 – 2 – 10 – 12 – 13
3. 1 – 2 – 3 – 10 – 11 – 13
4. 1 – 2 – 3 – 4 – 5 – 6 – 7 – 8 – 9 – 2 – 10 – 11 – 13
5. 1 – 2 – 3 – 4 – 5 – 6 – 8 – 9 – 2 – 10 – 11 – 13
6. 1 – 2 – 3 – 4 – 5 – 8 – 9 – 2 – 10 – 11 – 13
Παρατηρήστε ότι το σύνολο αυτό ικανοποιεί τις ιδιότητες των βασικών µονοπατιών
που προαναφέρθηκαν. Εσείς που σκεφθήκατε ότι θα έπρεπε να περιλαµβάνεται και το
µονοπάτι 1 – 2 – 3 – 10 – 12 – 13, προσέξτε ότι οι συνθήκες 2 και 3 καθιστούν αδύ-
νατο ένα τέτοιο µονοπάτι εκτέλεσης.
Υπολογισµός περιπτώσεων ελέγχου
Θα δείξουµε τον τρόπο υπολογισµού των περιπτώσεων ελέγχου µε ένα παράδειγµα.
¶·Ú¿‰ÂÈÁÌ· 4.3 (συνέχεια)
Στη συνέχεια παρατίθεται ενδεικτικός κατάλογος περιπτώσεων ελέγχου για τον αλγό-
ριθµο ΜΕΣΗ – ΤΙΜΗ και τα βασικά µονοπάτια που έχουν περιγραφεί:
∆Ε∆ΟΜΕΝΑ ΕΛΕΓΧΟΥ ΑΝΑΜΕΝΟΜΕΝΑ ΑΠΟΤΕΛΕΣΜΑΤΑ
Μονοπάτι 1
VAL[Κ] περιέχει έγκυρη τιµή, για Κ < Ι
VAL[Ι] = – 999, για 2<= Ι<= 100
σωστή µέση τιµή, βασισµένη σε Κ τιµές και σωστά
αθροίσµατα
Μονοπάτι 2
VAL[1] = – 999 ΜΤΜ= – 999 & οι υπόλοιποι µετρητές έχουν
ακόµη τις αρχικές τους τιµές
Μονοπάτι 3
Επεξεργασία 101 εγγραφών σωστή µέση τιµή, βασισµένη σε Κ τιµές και σωστά
αθροίσµατα
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 82
Μετά την εφαρµογή κάθε δοκιµής συγκρίνουµε τα αποτελέσµατά της µε τα αναµενόµε-
να αποτελέσµατα. Εάν εκτελεστούν όλες οι περιπτώσεις ελέγχου, η οµάδα δοκιµής γνω-
ρίζει ότι όλες οι εντολές του προγράµµατος έχουν εκτελεστεί τουλάχιστον µια φορά.
∆υστυχώς, όµως, αυτό δεν σηµαίνει ότι το πρόγραµµα έχει δοκιµαστεί εξαντλητικά. Το
µόνο που µπορούµε να ισχυριστούµε είναι ότι έχουµε ελέγξει ένα ποσοστό από τα δυνα-
τά µονοπάτια εκτέλεσης του προγράµµατος. Έτσι λοιπόν ελαττώµατα µπορεί να εµφα-
νιστούν όταν εκτελεστεί κάποιος συγκεκριµένος συνδυασµός µονοπατιών εκτέλεσης,
ο οποίος δεν έχει ελεγχθεί, ακόµη και εάν όλες οι εντολές έχουν δοκιµαστεί µόνο µια
φορά. Συνεπώς, η τεχνική της δοκιµής µονοπατιών εκτέλεσης είναι πραγµατικά χρήσι-
µη µόνο στις δραστηριότητες ελέγχου των µονάδων ενός προγράµµατος.
8 3 4 . 5 ∆ ∂ à ¡π ∫ ∂ ™ ∂ § ∂ ° à √À ¢ π ∞ º∞ ¡√À ™ ∫ √À ∆ π √À
Μονοπάτι 4
VAL[Ι] = έγκυρη, Ι < 100
VAL[Κ] > ΜΙΝ, Κ < Ι
σωστή µέση τιµή, βασισµένη σε Κ τιµές και σωστά
αθροίσµατα
Μονοπάτι 5
VAL[Ι] = έγκυρη, Ι < 100
VAL[Κ] > ΜΑΧ, Κ < Ι
σωστή µέση τιµή, βασισµένη σε Ν τιµές και σωστά
αθροίσµατα
Μονοπάτι 6
VAL[Ι] = έγκυρη, Ι < 100
VAL[Κ] < ΜΙΝ, Κ < Ι
σωστή µέση τιµή, βασισµένη σε Ν τιµές και σωστά
αθροίσµατα
Πριν προχωρήσετε, προσπαθήστε να βάλετε στη σωστή σειρά τα βήµατα της τεχνι-
κής σχεδίασης περιπτώσεων ελέγχου µε τη δοκιµή βασικών µονοπατιών εκτέλεσης:
ΤΥΧΑΙΑ ΣΕΙΡΑ ΣΩΣΤΗ ΣΕΙΡΑ
υπολογισµός των βασικών µονοπατιών εκτέλεσης 1.
υπολογισµός της κυκλωµατικής πολυπλοκότητας 2.
του γραφήµατος ροής
σχεδίαση περιπτώσεων ελέγχου που εκτελούν κάθε 3.
βασικό µονοπάτι
σχεδίαση του γραφήµατος ροής 4.
ÕÛÎËÛË ·˘ÙÔ·ÍÈÔÏfiÁËÛ˘ 4.6
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 83
8 4 K E ºA § A I O 4 : ∆ ∂ à ¡π ∫ ∂ ™ ™ à ∂ ¢ π ∞ ™ ∏™ ∆ ø¡ ¶∂ ƒ π ¶∆ ø™ ∂ ø¡ E § ∂ ° à √À § √° π ™ ªπ ∫ √À
Έστω ο αλγόριθµος δυαδικής αναζήτησης (binary search) που ακολουθεί. Στο παρά-
δειγµά µας, ο αλγόριθµος εφαρµόζεται σε ένα πίνακα ακεραίων Τ, στον οποίο ανα-
ζητούµε το στοιχείο που αναπαριστά η µεταβλητή KEY. Εάν το στοιχείο βρεθεί, η
BOOLEAN (λογική) µεταβλητή FOUND επιστρέφεται µε τιµή TRUE, µαζί µε τη
θέση του στοιχείου στη µεταβλητή POS, αλλιώς η µεταβλητή FOUΝD επιστρέφε-
ται µε τιµή FALSE. Για την αναζήτηση στον πίνακα χρησιµοποιούνται οι εξής τρεις
δείκτες: FIRST, ο οποίος δείχνει πάντα στο πρώτο στοιχείο, LAST, ο οποίος δείχνει
στο τελευταίο στοιχείο και MID, ο οποίος δείχνει στο µεσαίο στοιχείο της περιοχής
του πίνακα όπου ψάχνει ο αλγόριθµος.
Ο πίνακας Τ θεωρείται ταξινοµηµένος κατ’ αύξουσα σειρά. Τότε, ο αλγόριθµος αρχι-
κά συγκρίνει τη µεταβλητή KEY µε το µεσαίο στοιχείο του πίνακα που αναπαρί-
σταται από τη µεταβλητή MID. Εάν KEY < MID, τότε ο αλγόριθµος ψάχνει, ακο-
λουθώντας την ίδια στρατηγική, το αριστερό µισό του πίνακα. Εάν KEY > MID, τότε
ψάχνει το δεξιό µισό. Προφανώς, εάν KEY = MID, τότε έχει βρεθεί το στοιχείο και
ο αλγόριθµος τερµατίζει.
ΑΛΓΟΡΙΘΜΟΣ ∆ΥΑ∆ΙΚΗ – ΑΝΑΖΗΤΗΣΗ
ΕΙΣΟ∆ΟΣ
KEY: INTEGER ;
T: ARRAY [1..N] OF INTEGER ;
ΕΞΟ∆ΟΣ
FOUND: BOOLEAN ;
POS: INTEGER ;
∆Ε∆ΟΜΕΝΑ
FIRST, LAST: INTEGER ;
ΑΡΧΗ
FIRST := 1 ;
LAST := Ν ;
FOUND := FALSE ;
ΕΝΟΣΩ((FIRST <= LAST) AND (FOUND = FALSE)) ΕΠΑΝAΛΑΒΕ
¢Ú·ÛÙËÚÈfiÙËÙ· 4.4
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 84
Στη συνέχεια, παραθέτουµε µια προτεινόµενη απάντηση. Σας προτείνουµε να τη µελε-
τήσετε µόνο αφού έχετε σχεδιάσει τις δικές σας περιπτώσεις ελέγχου και έχοντας
υπόψη ότι σε κάθε αλγόριθµο υπάρχουν πολλά σύνολα βασικών µονοπατιών. Συνε-
πώς, εάν έχετε χρησιµοποιήσει κάποιο άλλο σύνολο από αυτό που προτείνουµε εµείς,
µπορείτε να ελέγξετε την καταλληλότητά του, ελέγχοντας εάν κάθε εντολή του προ-
γράµµατος εκτελείται σε µια τουλάχιστον περίπτωση ελέγχου.
Βήµα 1. Κατασκευή του γραφήµατος ροής
Οπως έχουµε αναφέρει, ξεκινούµε τη σχεδίαση των περιπτώσεων ελέγχου από την
κατασκευή του γραφήµατος ροής για τον αλγόριθµο ∆ΥΑ∆ΙΚΗ – ΑΝΑΖΗΤΗΣΗ. Για
την κατασκευή του, χρειάζεται να αναλύσουµε τη σύνθετη συνθήκη της δοµής ΕΝΟΣΩ
σε µια δοµή επανάληψης µε απλή συνθήκη και µια δοµή απόφασης, ως εξής:
8 5 4 . 5 ∆ ∂ à ¡π ∫ ∂ ™ ∂ § ∂ ° à √À ¢ π ∞ º∞ ¡√À ™ ∫ √À ∆ π √À
MID := (FIRST + LAST) div 2 ;
ΕΑΝ (Τ[MID] = KEY) ΤΟΤΕ
FOUND := TRUE ;
POS := MID
ΑΛΛΙΩΣ
ΕΑΝ (Τ[MID] < KEY) ΤΟΤΕ
FIRST := MID + 1
ΑΛΛΙΩΣ
LAST := MID – 1
ΕΑΝ – ΤΕΛΟΣ
ΕΑΝ – ΤΕΛΟΣ
ΕΝΟΣΩ – ΤΕΛΟΣ
ΤΕΛΟΣ
∆οκιµάστε να σχεδιάσετε περιπτώσεις ελέγχου για τον αλγόριθµο ∆ΥΑ∆ΙΚΗ – ΑΝΑ-
ΖΗΤΗΣΗ.
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 85
8 6 K E ºA § A I O 4 : ∆ ∂ à ¡π ∫ ∂ ™ ™ à ∂ ¢ π ∞ ™ ∏™ ∆ ø¡ ¶∂ ƒ π ¶∆ ø™ ∂ ø¡ E § ∂ ° à √À § √° π ™ ªπ ∫ √À
ΕΝΟΣΩ(FIRST <= LAST) ΕΠΑΝAΛΑΒΕ
ΕΑΝ (FOUND := TRUE) ΤΟΤΕ
ΕΞΟ∆ΟΣ
ΑΛΛΙΩΣ
MID := (FIRST + LAST) div 2 ;

Η ανάλυση της σύνθετης συνθήκης γίνεται για να διευκολυνθεί η δοκιµή όλων των
µονοπατιών εκτέλεσης που ξεκινούν από δοµές απόφασης (δηλαδή το µονοπάτι που,
εκτελείται όταν η συνθήκη είναι ΑΛΗΘΗΣ, και το µονοπάτι που εκτελείται, όταν η
συνθήκη είναι ΨΕΥ∆ΗΣ).
Βήµα 2. Υπολογισµός της κυκλωµατικής πολυπλοκότητας
Η κυκλωµατική πολυπλοκότητα του αλγορίθµου ∆ΥΑ∆ΙΚΗ – ΑΝΑΖΗΤΗΣΗ είναι 5.
Ο αριθµός αυτός προκύπτει:
• εξετάζοντας τις περιοχές του γραφήµατος ροής (οι οποίες είναι 5),
• από τις κορυφές και τις πλευρές του γραφήµατος: V(G) = 16 πλευρές – 13 κορυφές
+ 2 = 5,
• από τις συνθήκες του αλγορίθµου: V(G) = 4 κόµβοι συνθηκών + 1 = 5.
Βήµα 3. Υπολογισµός των βασικών µονοπατιών
Αφού βρείτε ένα σύνολο βασικών µονοπατιών, πρέπει να εξακριβώσετε ότι, εάν δοκι-
µαστεί η εκτέλεση όλων αυτών των µονοπατιών,
• κάθε εντολή του αλγόριθµου ∆ΥΑ∆ΙΚΗ – ΑΝΑΖΗΤΗΣΗ θα έχει εκτελεστεί του-
λάχιστον µια φορά και
• κάθε συνθήκη θα έχει δοκιµαστεί τόσο για την περίπτωση που είναι ΑΛΗΘΗΣ όσο
και για την περίπτωση που είναι ΨΕΥ∆ΗΣ.
Βήµα 4. Σχεδίαση περιπτώσεων ελέγχου
Ένα ενδεικτικό σύνολο περιπτώσεων ελέγχου είναι το εξής:
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 86
8 7 4 . 5 ∆ ∂ à ¡π ∫ ∂ ™ ∂ § ∂ ° à √À ¢ π ∞ º∞ ¡√À ™ ∫ √À ∆ π √À
∆Ε∆ΟΜΕΝΑ ΕΛΕΓΧΟΥ ΑΝΑΜΕΝΟΜΕΝΑ ΑΠΟΤΕΛΕΣΜΑΤΑ
Μονοπάτι 1
FIRST > LAST Το πρόγραµµα τερµατίζει ανεπιτυχώς και FOUND
= FALSE, POS = ??
Μονοπάτι 2
FIRST <= LAST AND FOUND = TRUE Το πρόγραµµα τερµατίζει επιτυχώς και FOUND =
TRUE, POS = MID
Μονοπάτι 3
FIRST <= LAST AND FOUND = FALSE AND
T[MID] = KEY
Το πρόγραµµα τερµατίζει επιτυχώς και FOUND =
TRUE, POS = MID
Μονοπάτι 4
FIRST <= LAST AND FOUND = FALSE AND
T[MID] < KEY
Το πρόγραµµα επαναλαµβάνει την εκτέλεση της
επανάληψης µε FOUND = FALSE και FIRST =
MID + 1. Εαν συµβεί FIRST > LAST, τότε το πρό-
γραµµα τερµατίζει ανεπιτυχώς και FOUND =
FALSE, POS = ??
Μονοπάτι 5
FIRST <= LAST AND FOUND = FALSE AND
T[MID] > KEY
Το πρόγραµµα επαναλαµβάνει την εκτέλεση της
επανάληψης µε FOUND = FALSE και FIRST =
MID – 1. Εάν συµβεί FIRST > LAST, τότε το πρό-
γραµµα τερµατίζει ανεπιτυχώς και FOUND =
FALSE, POS = ??
Επιστρέψτε στον αλγόριθµο TEST που περιγράφηκε στο Παράδειγµα 1 της ενότη-
τας 3.1 και προσπαθήστε να σχεδιάσετε τις κατάλληλες περιπτώσεις ελέγχου ανά-
λογα µε τους περιορισµούς στις τιµές των δεδοµένων εισόδου.
ÕÛÎËÛË ·˘ÙÔ·ÍÈÔÏfiÁËÛ˘ 4.7
4.5.2 ¢ÔÎÈÌ‹ ‰ÔÌÒÓ Â·Ó¿Ï˄˘
Οι δοµές επανάληψης (loops) αποτελούν θεµελιώδεις προγραµµατιστικές δοµές, γι’
αυτό και έχει αναπτυχθεί µια τεχνική που επικεντρώνεται αποκλειστικά στον έλεγ-
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 87
8 8 K E ºA § A I O 4 : ∆ ∂ à ¡π ∫ ∂ ™ ™ à ∂ ¢ π ∞ ™ ∏™ ∆ ø¡ ¶∂ ƒ π ¶∆ ø™ ∂ ø¡ E § ∂ ° à √À § √° π ™ ªπ ∫ √À
χό τους. Στη συνέχεια περιγράφονται οι δοκιµές που πρέπει να εφαρµόσουµε σε
καθένα από τα τέσσερα είδη δοµών επανάληψης που µπορούν να οριστούν.
Απλές δοµές επανάληψης
Σε µια δοµή όπου n είναι ο µέγιστος αριθµός επιτρεπόµενων επαναλήψεων, πρέπει
να εφαρµοστούν οι ακόλουθες δοκιµές:
• H δοµή επανάληψης δεν εκτελείται καθόλου.
• H δοµή επανάληψης εκτελείται µόνο µια φορά.
• H δοµή επανάληψης εκτελείται δύο φορές.
• H δοµή επανάληψης εκτελείται m φορές, m < n.
• H δοµή επανάληψης εκτελείται n – 1, n, n + 1 φορές.
Φωλιασµένες δοµές επανάληψης
Εάν επιχειρήσουµε να εφαρµόσουµε τις προηγούµενες οδηγίες σε καθεµία από ένα
σύνολο φωλιασµένων δοµών επανάληψης, ο αριθµός των απαιτούµενων δοκιµών
θα µεγαλώνει µε γεωµετρική πρόοδο. Το ακόλουθο σύνολο δοκιµών επιχειρεί να µει-
ώσει την πολυπλοκότητα του ελέγχου:
1. Ξεκινώντας από την εσωτερική επανάληψη, θέτουµε ελάχιστες τιµές στις µετα-
βλητές των υπόλοιπων επαναλήψεων,
2. Eφαρµόζουµε τεχνικές δοκιµής απλών επαναλήψεων, διατηρώντας τις µεταβλη-
τές των εξωτερικών επαναλήψεων σε ελάχιστες τιµές, ενώ προσθέτουµε και άλλες
δοκιµές για τιµές εκτός ορίων,
3. Προχωρούµε «προς τα έξω», δοκιµάζοντας την αµέσως πιο εξωτερική δοµή επανά-
ληψης, ενώ ταυτόχρονα διατηρούµε τις µεταβλητές των εξωτερικών επαναλήψεων σε
ελάχιστες τιµές και τις µεταβλητές των εσωτερικών επαναλήψεων σε «τυπικές» τιµές,
4. Συνεχίζουµε µε τον τρόπο αυτό µέχρι να δοκιµαστούν όλες οι επαναλήψεις.
Ακολουθία δοµών επανάληψης
Μπορούµε να δοκιµάσουµε δοµές επανάληψης που βρίσκονται σε ακολουθία εφαρ-
µόζοντας τις τεχνικές δοκιµής απλών δοµών επανάληψης.
Μη δοµηµένες επαναλήψεις
Τέτοια τµήµατα κώδικα πρέπει, πριν δοκιµαστούν, να επανασχεδιάζονται ώστε να ακο-
λουθούν τις αρχές του δοµηµένου προγραµµατισµού.
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 88
¶·Ú¿‰ÂÈÁÌ· 4.4
Θα εξετάσουµε τη σχεδίαση περιπτώσεων ελέγχου για τρεις αλγορίθµους επεξεργα-
σίας των στοιχείων ενός πίνακα. Ο πρώτος αλγόριθµος αναζητά ένα συγκεκριµένο
στοιχείο KEY σε ένα µονοδιάστατο πίνακα Ρ[1..Ν] θετικών ακεραίων συγκρίνοντας
τα στοιχεία ένα – προς – ένα. Ο δεύτερος κάνει το ίδιο για ένα δισδιάστατο πίνακα
Μ × N θετικών ακεραίων. Ο τρίτος, αναζητά ένα συγκεκριµένο στοιχείο KEY σε ένα
µονοδιάστατο πίνακα Ν θετικών ακεραίων και αφού το βρει, υπολογίζει το άθροισµα
όλων των στοιχείων του πίνακα. Στη συνέχεια δίνονται οι περιπτώσεις ελέγχου (Yπό-
δειξη: δοκιµάστε να περιγράψετε τους αλγορίθµους µε ψευδοκώδικα):
Ο πρώτος αλγόριθµος περιέχει µια απλή δοµή επανάληψης (έστω Ι µε τιµές από 1 έως
Ν). Οι περιπτώσεις δοκιµής που µπορούµε να σχεδιάσουµε γι’ αυτή είναι οι εξής:
8 9 4 . 5 ∆ ∂ à ¡π ∫ ∂ ™ ∂ § ∂ ° à √À ¢ π ∞ º∞ ¡√À ™ ∫ √À ∆ π √À
ΣΤΟΧΟΣ ∆ΟΚΙΜΗΣ ΠΕΡΙΠΤΩΣΗ ΕΛΕΓΧΟΥ
H δοµή επανάληψης δεν εκτελεί-
ται καθόλου.
Ν < 1
KEY < 0
H δοµή επανάληψης εκτελείται
µόνο µια φορά.
Ν = 1
KEY = Ρ[1]
H δοµή επανάληψης εκτελείται
δύο φορές.
Ν = 2 AND KEY < > Ρ[Ι]
KEY = Ρ[2]
H δοµή επανάληψης εκτελείται m
φορές, m < n.
Ν = m AND KEY < > Ρ[Ι], 1 <= Ι < m
KEY = Ρ[m]
H δοµή επανάληψης εκτελείται
n – 1 φορές.
N = n – 1 AND KEY < > Ρ[Ι], 1 <= Ι < n – 1
KEY = Ρ[n – 1]
H δοµή επανάληψης εκτελείται
n φορές.
N = n AND KEY < > Ρ[Ι], 1 <= Ι < n
KEY = Ρ[n]
H δοµή επανάληψης εκτελείται
n + 1 φορές.
N = n+1 AND KEY < > Ρ[Ι], 1 <= Ι <= n
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 89
9 0 K E ºA § A I O 4 : ∆ ∂ à ¡π ∫ ∂ ™ ™ à ∂ ¢ π ∞ ™ ∏™ ∆ ø¡ ¶∂ ƒ π ¶∆ ø™ ∂ ø¡ E § ∂ ° à √À § √° π ™ ªπ ∫ √À
Ο δεύτερος αλγόριθµος περιέχει δύο φωλιασµένες δοµές επανάληψης (έστω Κ από 1
έως Μκαι µέσα σ’ αυτή την Ι από 1 έως Ν). Σύµφωνα µε την προηγούµενη περίπτω-
ση χρειαζόµαστε 13 δοκιµαστικές περιπτώσεις για κάθε απλή δοµή επανάληψης. Εάν
δοκιµάσουµε κάθε δοµή ως απλή δοµή επανάληψης, τότε χρειαζόµαστε συνολικά
13 × 13 = 169 δοκιµαστικές περιπτώσεις. Προτιµούµε λοιπόν να εφαρµόσουµε τις ειδι-
κές οδηγίες για φωλιασµένες δοµές επανάληψης και σχεδιάζουµε δοκιµαστικές περι-
πτώσεις πρώτα για την εσωτερική δοµή επανάληψης, θέτοντας ελάχιστη τιµή στη µετα-
βλητή της εξωτερικής επανάληψης (Κ = 1).
Έπειτα, προσθέτουµε δοκιµές για τιµές εκτός ορίων της µεταβλητής της εξωτερικής
επανάληψης και τέλος, δοκιµάζουµε τώρα την εξωτερική δοµή επανάληψης, θέτοντας
«τυπικές» τιµές στην εσωτερική.
Ο τρίτος αλγόριθµος περιέχει δύο επαναλήψεις σε ακολουθία (έστω R από 1 έως Ν και
T από 1 έως Ν). Οι επαναλήψεις Τ και R δεν εξαρτώνται άµεσα, οπότε µπορούµε να
χρησιµοποιήσουµε για καθεµία τεχνικές δοκιµής απλών επαναλήψεων.
Ανατρέξτε στο παράδειγµα 2 της ενότητας 3.1, όπου αναλύεται η ορθότητα του αλγό-
ριθµου SUM_ARRAY εφαρµόζοντας συµβολική εκτέλεση. Συγκρίνετε την τεχνική
της συµβολικής εκτέλεσης µε τις δοκιµές που σχεδιάσαµε για τους αλγορίθµους του
Παραδείγµατος 4.4, πιο πάνω. Προσπαθήστε να επιλέξετε την καταλληλότερη τεχνι-
κή για να δείξουµε την ορθότητα του αλγορίθµου ανάλογα µε το στόχο εγκυροποί-
ησης που περιγράφεται στην αριστερή στήλη:
ΣΤΟΧΟΙ ΣΤΑΤΙΚΗ ΕΛΕΓΧΟΣ
ΑΝΑΛΥΣΗ
Έλεγχος αποτελέσµατος για συνηθισµένες τιµές
του µετρητή και ανεξάρτητα από τις τιµές
του πίνακα
Έλεγχος αποτελέσµατος για οριακές αλλά
σωστές τιµές του µετρητή
Έλεγχος αποτελέσµατος για οριακές αλλά
λανθασµένες τιµές του µετρητή
Έλεγχος αποτελέσµατος για πίνακα ενός
στοιχείου
ÕÛÎËÛË ·˘ÙÔ·ÍÈÔÏfiÁËÛ˘ 4.8
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 90
9 1 4 . 5 ∆ ∂ à ¡π ∫ ∂ ™ ∂ § ∂ ° à √À ¢ π ∞ º∞ ¡√À ™ ∫ √À ∆ π √À
Έλεγχος αποτελέσµατος για πίνακα πολλών
στοιχείων
Έλεγχος αποτελέσµατος για κενό πίνακα
Για τον αλγόριθµο ∆ΥΑ∆ΙΚΗ – ΑΝΑΖΗΤΗΣΗ που παρουσιάσθηκε στην ενότητα
4.5.1, δοκιµάστε να σχεδιάσετε περιπτώσεις ελέγχου για τη δοµή επανάληψης που
περιέχει. Μια προτεινόµενη απάντηση δίνεται στη συνέχεια.
¢Ú·ÛÙËÚÈfiÙËÙ· 4.5
ΣΤΟΧΟΣ ∆ΟΚΙΜΗΣ ΠΕΡΙΠΤΩΣΗ ΕΛΕΓΧΟΥ
Η δοµή επανάληψης δεν εκτελεί-
ται καθόλου.
FIRST > LAST
FOUND := TRUE
Η δοµή επανάληψης εκτελείται
µόνο µια φορά.
FIRST <= LAST AND FOUND := FALSE
AND Τ[MID] = KEY, όπου MID =
(FIRST+LAST) div 2
Η δοµή επανάληψης εκτελείται
δύο φορές.
FIRST <= LAST AND FOUND := FALSE
AND Τ[MID] = KEY, όπου MID = (FIRST +
((FIRST+LAST) div 2) – 1) div 2
FIRST <= LAST AND FOUND := FALSE
AND Τ[MID] = KEY, όπου MID = (LAST +
((FIRST+LAST) div 2)+1) div 2
Η δοµή επανάληψης εκτελείται m
φορές, m < n.
KEY = Τ[Κ], όπου Κ < Ν ένας οποιοσδήποτε
αριθµός
Η δοµή επανάληψης εκτελείται
n – 1 φορές.
KEY = Τ[2]
KEY = Τ[Ν – 1]
Η δοµή επανάληψης εκτελείται
n φορές.
KEY = Τ[1]
KEY = Τ[Ν]
Η δοµή επανάληψης εκτελείται
n + 1 φορές.
Η KEY δεν περιέχεται στον πίνακα Τ
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 91
9 2 K E ºA § A I O 4 : ∆ ∂ à ¡π ∫ ∂ ™ ™ à ∂ ¢ π ∞ ™ ∏™ ∆ ø¡ ¶∂ ƒ π ¶∆ ø™ ∂ ø¡ E § ∂ ° à √À § √° π ™ ªπ ∫ √À
∆οκιµάστε να συµπληρώσετε τα κενά στο κείµενο που ακολουθεί χρησιµοποιώντας
(στην κατάλληλη πτώση) κάποιες από τις φράσεις:
Περιγραφή του κώδικα Όλες τις εντολές
Προδιαγραφές εισόδου/εξόδου Όλα τα µονοπάτια
Μονοπάτια εκτέλεσης Όλα τα τµήµατα
Περιορισµοί Ανάλυση οριακών τιµών
Προδιαγραφές ∆οκιµή βασικών µονοπατιών
Πίνακας αποφάσεων Κυκλωµατική πολυπλοκότητα
Αριθµός συνθηκών ∆οκιµή δοµών επανάληψης
Απλές Συµβολική εκτέλεση
Φωλιασµένες Λειτουργικός έλεγχος
Γράφηµα ροής Γράφηµα αιτίου – αποτελέσµατος
Οι τεχνικές ελέγχου διαφανούς κουτιού σχεδιάζουν τις περιπτώσεις ελέγχου µε βάση
………… του λογισµικού. Όλες οι τεχνικές της κατηγορίας αυτής ξεκινούν από τη
δοκιµή διαφόρων …………… του κώδικα, προσπαθώντας να εκτελέσουν ……
……… χωρίς να εκτελέσουν ……………………. και ταυτόχρονα να καλύψουν όσο
το δυνατό περισσότερους από τους πιθανούς τρόπους χρήσης του λογισµικού.
Η πιο διαδεδοµένη τεχνική είναι …………., όπου χρησιµοποιείται το ……………
για τον υπολογισµό ……………. του προγράµµατος, µε στόχο να συµπεράνουµε τον
ελάχιστο αριθµό µονοπατιών εκτέλεσης που χρειάζεται να δοκιµαστούν ώστε να
εκτελεστούν ……………….. Εάν το πρόγραµµα περιέχει επαναλήψεις, τότε εφαρ-
µόζουµε συµπληρωµατικά ………………. Το µειονέκτηµα αυτής της τεχνικής είναι
ότι υπαγορεύει τη σχεδίαση πολλών περιπτώσεων ελέγχου όταν οι επαναλήψεις είναι
………, γι’ αυτό πολλές φορές προτιµάται στην περίπτωση αυτή η …………… του
προγράµµατος.
ÕÛÎËÛË ·˘ÙÔ·ÍÈÔÏfiÁËÛ˘ 4.9
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 92
4.6 ∆¯ÓÈΤ˜ ÂϤÁ¯Ô˘ ‰ÈÂ·ÊÒÓ
™ÎÔfi˜
Στην ενότητα αυτή θα παρουσιασθούν οι σηµαντικότερες τεχνικές σχεδίασης περιπτώ-
σεων ελέγχου των διεπαφών ανάµεσα στα τµήµατα που συγκροτούν ένα σύστηµα λογι-
σµικού.
¶ÚÔÛ‰ÔÎÒÌÂÓ· ·ÔÙÂϤÛÌ·Ù·
Όταν θα έχετε µελετήσει την ενότητα αυτή, θα µπορείτε να:
• περιγράψετε πέντε γενικές αρχές σχεδίασης του ελέγχου διεπαφών,
• εφαρµόσετε τις αρχές αυτές κατά τον έλεγχο συστηµάτων λογισµικού.
∂ÓÓÔȘ ÎÏÂȉȿ
• είδη διεπαφών,
• σφάλµατα διεπαφών.
EÈÛ·ÁˆÁÈΤ˜ ·Ú·ÙËÚ‹ÛÂȘ
Ο έλεγχος διεπαφών εφαρµόζεται κατά την συγκρότηση τµηµάτων του λογισµικού για
τη δηµιουργία υποσυστηµάτων ή συστηµάτων (Sommerville[96]). Κάθε τµήµα ή υπο-
σύστηµα έχει µια καθορισµένη διεπαφή (interface) µέσα από την οποία επικοινωνεί µε
(καλεί ή καλείται από) άλλα τµήµατα. Ο στόχος του ελέγχου διεπαφών είναι να ανακα-
λύψει λάθη που εισάγονται στο σύστηµα εξαιτίας ελαττωµάτων των διεπαφών ή λανθα-
σµένων υποθέσεων για τις διεπαφές των επί µέρους τµηµάτων.
Αυτό το είδος ελέγχου είναι ιδιαίτερα κατάλληλο για αντικειµενοστραφή συστήµατα,
όπου τα αντικείµενα ουσιαστικά «ορίζονται» από τη διεπαφή τους. Οι άλλες τεχνικές
δεν µπορούν να ανακαλύψουν ελαττώµατα που εµφανίζονται στις διεπαφές, αφού τεί-
νουν να δοκιµάζουν την αποµονωµένη συµπεριφορά κάθε τµήµατος και όχι τη δυνα-
µική συµπεριφορά ολόκληρου του λογισµικού. Στην πραγµατικότητα, υπάρχουν τέσσε-
ρα είδη διεπαφών ανάµεσα σε τµήµατα λογισµικού, σε καθεµία από τις οποίες µπορεί
να εµφανιστεί και διαφορετικό ελάττωµα:
• ∆ιεπαφές παραµέτρων: Mέσα απ΄αυτές, τα τµήµατα ανταλλάσσουν δεδοµένα ή ανα-
φορές σε συναρτήσεις.
• ∆ιεπαφές µοιραζόµενης µνήµης: ∆ύο ή περισσότερα τµήµατα µοιράζονται (δηλαδή
9 3 4 . 6 ∆ ∂ à ¡π ∫ ∂ ™ ∂ § ∂ ° à √À ¢ π ∂ ¶∞ ºø¡
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 93
9 4 K E ºA § A I O 4 : ∆ ∂ à ¡π ∫ ∂ ™ ™ à ∂ ¢ π ∞ ™ ∏™ ∆ ø¡ ¶∂ ƒ π ¶∆ ø™ ∂ ø¡ E § ∂ ° à √À § √° π ™ ªπ ∫ √À
έχουν δικαίωµα ανάγνωσης από και εγγραφής σε) ένα τµήµα της µνήµης.
• ∆ιαδικασιακές διεπαφές: Ένα τµήµα εµπεριέχει ένα σύνολο διαδικασιών τις οποίες
µπορούν να χρησιµοποιήσουν άλλα τµήµατα.
• ∆ιεπαφές ανταλλαγής µηνυµάτων: Ένα τµήµα αιτείται µια υπηρεσία από ένα άλλο
τµήµα στέλνοντας ένα µήνυµα. Το δεύτερο τµήµα απαντά µε ένα άλλο µήνυµα όπου
περιέχονται τα αποτελέσµατα της υπηρεσίας.
4.6.1 ™Ê¿ÏÌ·Ù· ‰ÈÂ·ÊÒÓ
Τα σφάλµατα διεπαφών µπορεί να οφείλονται στους εξής λόγους:
• Kατάχρηση της διεπαφής: Tο τµήµα που καλεί κάνει ένα λάθος καθώς χρησιµο-
ποιεί τη διεπαφή του καλούµενου τµήµατος (π.χ. σε διεπαφή παραµέτρων, χρη-
σιµοποιεί παραµέτρους διαφορετικού τύπου ή διαφορετικό πλήθος παραµέτρων
ή παραµέτρους σε διαφορετική σειρά).
• Παρανόηση της διεπαφής: Tο τµήµα που καλεί έχει λάθος πληροφόρηση για τις
προδιαγραφές της διεπαφής και την αναµενόµενη συµπεριφορά του καλούµενου
τµήµατος. Τότε, η πραγµατική συµπεριφορά του τελευταίου µπορεί να προκαλέ-
σει µη αναµενόµενη αντίδραση στο καλόν τµήµα (π.χ. κλήση µιας ρουτίνας δυα-
δικής αναζήτησης µε παράµετρο ένα µη ταξινοµηµένο πίνακα).
• Λανθασµένο συγχρονισµό: Mπορεί να εµφανιστεί σε συστήµατα πραγµατικού
χρόνου, όταν π.χ. ένα τµήµα παράγει δεδοµένα σε διαφορετικό ρυθµό από αυτόν
µε τον οποίο ένα άλλο τµήµα τα καταναλώνει, µε συνέπεια να υπάρχει πιθανό-
τητα το δεύτερο τµήµα να µη χρησιµοποιεί πάντα τα πιο πρόσφατα δεδοµένα.
4.6.2 ™¯Â‰›·ÛË ÂÚÈÙÒÛÂˆÓ ÂϤÁ¯Ô˘ ‰ÈÂ·ÊÒÓ
Η σχεδίαση επιτυχηµένων περιπτώσεων ελέγχου διεπαφών είναι ιδιαίτερα δύσκολη,
γιατί τα ελαττώµατα των διεπαφών τείνουν να εκδηλώνονται σε ασυνήθιστες συν-
θήκες. Ακόµη, ελαττώµατα σε ένα τµήµα µπορεί να έχουν επίδραση σε (και ίσως να
αναιρούνται από) ελαττώµατα που εµφανίζονται σε άλλο τµήµα, οπότε σφάλµα θα
δηµιουργηθεί σε κάποιο µεταγενέστερο στάδιο επεξεργασίας. Μάλιστα, στην περί-
πτωση των διεπαφών, οι στατικές τεχνικές εγκυροποίησης µπορεί να αποδειχθούν
περισσότερο αποτελεσµατικές από τους ελέγχους.
Μερικές γενικές αρχές σχεδίασης περιπτώσεων ελέγχου διεπαφών είναι οι εξής:
• Kαταγράφουµε, εξετάζοντας τον κώδικα υπό δοκιµή, κάθε χρήση της διεπαφής
άλλου τµήµατος. Επειτα, σχεδιάζουµε περιπτώσεις ελέγχου όπου δίνουµε ακραί-
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 94
¶·Ú¿‰ÂÈÁÌ· 4.5
Στο Σχήµα 4.7 φαίνεται η δοµή του προγράµµατος που χρησιµοποιεί το λογιστήριο
της επιχείρησης CHILDWARE. Σύµφωνα µε αυτό, το κυρίως πρόγραµµα χρησιµο-
ποιεί τρία υπο – προγράµµατα: το ΑΡΧΕΙΟ (το οποίο χρησιµοποιεί δύο τµήµατα για
να επεξεργαστεί τα ΑΤΟΜΙΚΑ ΣΤΟΙΧΕΙΑ και τα ΣΤΟΙΧΕΙΑ ΕΡΓΑΣΙΑΣ κάθε
υπαλλήλου), το βασικό πρόγραµµα ΜΙΣΘΟ∆ΟΣΙΑΣ (το οποίο χρησιµοποιεί δύο
τµήµατα για τον υπολογισµό της ΚΑΘΑΡΗΣ ΑΜΟΙΒΗΣ και της ΜΙΚΤΗΣ
ΑΜΟΙΒΗΣ) και το πρόγραµµα παραγωγής ΑΝΑΦΟΡΩΝ.
9 5 4 . 6 ∆ ∂ à ¡π ∫ ∂ ™ ∂ § ∂ ° à √À ¢ π ∂ ¶∞ ºø¡
ες τιµές στις παραµέτρους που ανταλλάσσονται, µε στόχο να ανακαλύψουµε
ασυµβατότητες ανάµεσα στις διεπαφές.
• Eάν µέσα από τη διεπαφή ανταλλάσσονται δείκτες (pointers), τους δοκιµάζου-
µε πάντα µε κενή (null) τιµή.
• Όταν καλείται ένα τµήµα µέσα από διαδικασιακή διεπαφή, φροντίζουµε πάντα
να δοκιµάζουµε την περίπτωση αστοχίας του καλούµενου τµήµατος, µε στόχο
να ανακαλύψουµε παρανοήσεις.
• Eφαρµόζουµε πρακτική ελέγχου της αντοχής των διεπαφών ανταλλαγής µηνυ-
µάτων (παρουσιάζεται στο Kεφάλαιο 5), µε στόχο να ανακαλύψουµε σφάλµα-
τα συγχρονισµού.
• Όταν διάφορα τµήµατα επικοινωνούν µέσα από µοιραζόµενη µνήµη, σχεδιάζου-
µε περιπτώσεις ελέγχου µε διαφορετική ακολουθία ενεργοποίησης των τµηµάτων.
™¯‹Ì· 4.7
∆ιάγραµµα δοµής
του προγράµµατος
ΛΟΓΙΣΤΗΡΙΟ
Λογιστήριο
Αναφορές Μισθοδοσία Αρχείο
AM
AM
EMPL
EMPL – DATA 
WORK – DATA
AM 
ST – DATE 
END – DATE
HOURS 
OVER
Υπολογισµός 
Μικτής 
Αµοιβής
Υπολογισµός 
Κρατήσεων
Στοιχεία 
Εργασίας
Ατοµικά 
Στοιχεία
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 95
9 6 K E ºA § A I O 4 : ∆ ∂ à ¡π ∫ ∂ ™ ™ à ∂ ¢ π ∞ ™ ∏™ ∆ ø¡ ¶∂ ƒ π ¶∆ ø™ ∂ ø¡ E § ∂ ° à √À § √° π ™ ªπ ∫ √À
Για τις διεπαφές αυτές σχεδιάζουµε περιπτώσεις ελέγχου ως εξής:
ΥΠΟΛΟΓΙΣΕ ΣΤΟΙΧΕΙΑ – ΕΡΓΑΣΙΑΣ
(ΑΜ, ST – DATE, END – DATE ; HOURS, OVER)
Συνδυάζουµε µεταξύ τους τις περιπτώσεις όπου:
• ο ΑΜ υπάρχει µέσα στο αρχείο και είναι ο πρώτος ή ο τελευταίος ή κάποιος
τυχαίος ΑΜ ή ο ΑΜ δεν υπάρχει µέσα στο αρχείο,
• η ST – DATE είναι σωστή ή η ST – DATE είναι λάθος,
• η END – DATE είναι σωστή ή η END – DATE είναι λάθος,
• ο πίνακας HOURS έχει 0 ή 1 ή 2 ή 29 ή 30 ή 31 τιµές,
• ο πίνακας OVER έχει 0 ή 1 ή 2 ή 29 ή 30 ή 31 τιµές.
Οι διεπαφές µερικών από τα προγράµµατα αυτά έχουν ως εξής:
ΣΤΟΙΧΕΙΑ – ΕΡΓΑΣΙΑΣ ΑΡΧΕΙΟ
ΕΙΣΟ∆ΟΣ ΕΙΣΟ∆ΟΣ
AM: INTEGER ΑΜ: INTEGER
ST – DATE, END – DATE: CHAR
ΕΞΟ∆ΟΣ ΕΞΟ∆ΟΣ
HOURS, OVER: ARRAY [1..31] OF INTEGER EMPL – DATA, WORK – DATA: POINTER
ΑΤΟΜΙΚΑ – ΣΤΟΙΧΕΙΑ ΚΛΗΣΗ ΤΜΗΜΑΤΩΝ :
ΕΙΣΟ∆ΟΣ ΥΠΟΛΟΓΙΣΕ ΣΤΟΙΧΕΙΑ – ΕΡΓΑΣΙΑΣ
ΑΜ: INTEGER (ΑΜ, ST – DATE, END – DATE ;
ΕΞΟ∆ΟΣ HOURS, OVER)
EMPL: RECORD OF
NAME: CHAR ΥΠΟΛΟΓΙΣΕ ΑΤΟΜΙΚΑ – ΣΤΟΙΧΕΙΑ
ADDRESS: CHAR (ΑΜ ; EMPL)
RANK: INTEGER
BONUS: INTEGER ΥΠΟΛΟΓΙΣΕ ΑΡΧΕΙΟ
(ΑΜ ; EMPL – DATA, WORK – DATA)
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 96
Ακόµη, δοκιµάζουµε την περίπτωση η εκτέλεση του τµήµατος ΣΤΟΙΧΕΙΑ –
ΕΡΓΑΣΙΑΣ να αστοχήσει, οπότε είναι απροσδιόριστες οι τιµές των HOURS και
OVER (στην περίπτωση αυτή θέλουµε να δούµε την έξοδο που θα δώσει το τµήµα
ΑΡΧΕΙΟ, ενώ γνωρίζουµε ότι τα περιεχόµενα των πινάκων είναι λανθασµένα).
ΥΠΟΛΟΓΙΣΕ ΑΤΟΜΙΚΑ – ΣΤΟΙΧΕΙΑ (ΑΜ ; EMPL)
Συνδυάζουµε µεταξύ τους τις περιπτώσεις όπου:
• ο ΑΜ υπάρχει µέσα στο αρχείο και είναι ο πρώτος ή ο τελευταίος ή κάποιος
τυχαίος ΑΜ ή ο ΑΜ δεν υπάρχει µέσα στο αρχείο,
• το πεδίο ΝΑΜΕ έχει σωστή τιµή ή έχει λανθασµένη τιµή ή δεν έχει τιµή,
• το πεδίο ADDRESS έχει σωστή τιµή ή έχει λανθασµένη τιµή ή δεν έχει τιµή,
• το πεδίο RANK έχει σωστή τιµή ή έχει λανθασµένη τιµή ή δεν έχει τιµή,
• το πεδίο BONUS έχει σωστή τιµή ή έχει λανθασµένη τιµή ή δεν έχει τιµή.
Και στην περίπτωση αυτή δοκιµάζουµε τη συµπεριφορά του τµήµατος ΑΡΧΕΙΟ,
όταν η εκτέλεση του τµήµατος ΑΤΟΜΙΚΑ – ΣΤΟΙΧΕΙΑ αστοχήσει.
ΥΠΟΛΟΓΙΣΕ ΑΡΧΕΙΟ(ΑΜ ; EMPL – DATA, WORK – DATA)
Συνδυάζουµε µεταξύ τους τις περιπτώσεις όπου:
• ο ΑΜ υπάρχει µέσα στο αρχείο και είναι ο πρώτος ή ο τελευταίος ή κάποιος
τυχαίος ΑΜ ή ο ΑΜ δεν υπάρχει µέσα στο αρχείο,
• ο δείκτης EMPL – DATA επιστρέφει σωστή τιµή ή επιστρέφει τιµή NULL,
• ο δείκτης WORK – DATA επιστρέφει σωστή τιµή ή επιστρέφει τιµή NULL.
Όπως και πριν, δοκιµάζουµε την περίπτωση η εκτέλεση του τµήµατος ΑΡΧΕΙΟ να
αστοχήσει, οπότε είναι απροσδιόριστες οι τιµές των EMPL – DATA και WORK –
DATA (στην περίπτωση αυτή θέλουµε να δούµε την έξοδο που θα δώσει το πρό-
γραµµα ΛΟΓΙΣΤΗΡΙΟ, ενώ γνωρίζουµε ότι οι τιµές των δεικτών είναι ουσιαστικά
τυχαίες και λανθασµένες).
9 7 4 . 6 ∆ ∂ à ¡π ∫ ∂ ™ ∂ § ∂ ° à √À ¢ π ∂ ¶∞ ºø¡
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 97
9 8 K E ºA § A I O 4 : ∆ ∂ à ¡π ∫ ∂ ™ ™ à ∂ ¢ π ∞ ™ ∏™ ∆ ø¡ ¶∂ ƒ π ¶∆ ø™ ∂ ø¡ E § ∂ ° à √À § √° π ™ ªπ ∫ √À
™‡ÓÔ„Ë
Στο κεφάλαιο αυτό παρουσιάστηκαν τρεις συµπληρωµατικές µέθοδοι για τη σχεδία-
ση των περιπτώσεων ελέγχου ενός λογισµικού:
• O έλεγχος αδιαφανούς κουτιού, κατά τον οποίο δοκιµάζονται οι έξοδοι σε σχέση
µε τις εισόδους του συστήµατος, η επικοινωνία του λογισµικού µε άλλα τµήµατα
λογισµικού και η ακεραιότητα των δεδοµένων, µε στόχο να αποδειχθεί ότι κάθε
λειτουργία του λογισµικού εκτελείται πλήρως και σωστά. Στην κατηγορία αυτή
παρουσιάσθηκαν οι τεχνικές διαµέρισης των δεδοµένων εισόδου σε κλάσεις ισο-
δυναµίας, ανάλυσης οριακών τιµών των περιορισµών στα δεδοµένα εισόδου, σχε-
δίασης περιπτώσεων ελέγχου µε τη χρήση γραφηµάτων αιτίου – αποτελέσµατος
και συγκριτικών δοκιµών.
• O έλεγχος διαφανούς κουτιού, ο οποίος προϋποθέτει γνώση της εσωτερικής δοµής
του λογισµικού και περιλαµβάνει τεχνικές που δοκιµάζουν την ορθότητα κάθε εσω-
τερικής λειτουργίας του. Τέτοιες τεχνικές είναι η δοκιµή βασικών µονοπατιών εκτέ-
λεσης και η δοκιµή δοµών επανάληψης.
• O έλεγχος διεπαφών, ο οποίος στοχεύει στην ανακάλυψη ελαττωµάτων κατά την
επικοινωνία δύο ή περισσότερων τµηµάτων µέσα από τις διεπαφές τους. Τα προ-
κύπτοντα σφάλµατα συνήθως οφείλονται σε κατάχρηση ή παρανόηση του τρόπου
χρήσης της διεπαφής του καλούµενου τµήµατος από το τµήµα που το καλεί, ή είναι
σφάλµατα συγχρονισµού των δύο τµηµάτων.
Οι τεχνικές σχεδίασης περιπτώσεων ελέγχου χρησιµοποιούνται σε διάφορες φάσεις
των στρατηγικών ελέγχου λογισµικού, οι οποίες θα παρουσιασθούν στο επόµενο κεφά-
λαιο.
BÈ‚ÏÈÔÁÚ·Ê›·
[1] Σ. Ξανθάκης και Χ. Σκουρλάς (1991), Τεχνικές Ελέγχου Προγραµµάτων. Εκδό-
σεις Νέων Τεχνολογιών, Αθήνα.
[2] R. Pressman (1994), Software Engineering: a practitioner’s approach. McGraw
– Hill, England.
[3] I. Sommerville (1996), Software Engineering. Addison – Wesley, USA.
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 98
¶Ú·ÎÙÈ΋ EÊ·ÚÌÔÁ‹ ÙˆÓ ¢Ú·ÛÙËÚÈÔÙ‹ÙˆÓ EϤÁ¯Ô˘:
¢ÔÎÈ̤˜ §ÔÁÈÛÌÈÎÔ‡
™ÎÔfi˜
Ο στόχος αυτού του κεφαλαίου είναι να σας παρουσιάσει τον τρόπο που οι δραστηριότη-
τες ελέγχου λογισµικού χρησιµοποιούν τις διάφορες τεχνικές σχεδίασης περιπτώσεων ελέγ-
χου (τις οποίες γνωρίσατε στο προηγούµενο κεφάλαιο) για να εξυπηρετήσουν στην πράξη
τους στόχους των διαφόρων φάσεων δοκιµής που συγκροτούν µια στρατηγική ελέγχου.
¶ÚÔÛ‰ÔÎÒÌÂÓ· ·ÔÙÂϤÛÌ·Ù·
Όταν θα έχετε µελετήσει αυτό το κεφάλαιο, θα µπορείτε να:
• διακρίνετε ανάµεσα στην αυξητική και τη µη αυξητική συγκρότηση ενός συστήµατος
λογισµικού,
• αναφέρετε τις πέντε δραστηριότητες ελέγχου των µονάδων ενός λογισµικού,
• εξηγήσετε τι είναι οδηγός και τι στέλεχος ενός υπό δοκιµή τµήµατος λογισµικού και
να δώσετε από ένα παράδειγµα χρήσης τους,
• περιγράψετε τα τέσσερα βήµατα του από πάνω προς τα κάτω ελέγχου συγκρότησης
ενός λογισµικού και να δώσετε ένα παράδειγµα εφαρµογής του,
• περιγράψετε τα τέσσερα βήµατα του από κάτω προς τα πάνω ελέγχου συγκρότησης
ενός λογισµικού και να δώσετε ένα παράδειγµα εφαρµογής του,
• εξηγήσετε τι είναι η δοκιµή άλφα και η δοκιµή βήτα,
• περιγράψετε πέντε πρακτικές ελέγχου συστήµατος.
ŒÓÓÔȘ ÎÏÂȉȿ
5
∫ ∂ º ∞ § ∞ π √
• αυξητική συγκρότηση,
• µη αυξητική συγκρότηση,
• στέλεχος,
• «σάντουιτς» δοκιµή,
• «σάντουιτς» συγκρότηση,
• οδηγός,
• δοκιµή από πάνω προς τα κάτω,
• συγκρότηση από πάνω προς τα κάτω,
• δοκιµή από κάτω προς τα πάνω,
• συγκρότηση από κάτω προς τα πάνω,
• δοκιµή εκφάνσεων εκτέλεσης,
• δοκιµή άλφα,
• δοκιµή βήτα,
• δοκιµή ανάκαµψης,
• δοκιµή ασφάλειας,
• δοκιµή απόδοσης,
• δοκιµή αντοχής.
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 99
1 0 0 K E ºA § A I O 5 : ¶ƒ∞ ∫ ∆ π ∫ ∏ E º∞ ƒ ª√° ∏ ∆ ø¡ ¢ ƒ∞ ™ ∆ ∏ƒ π √∆ ∏∆ ø¡ E § ∂ ° à √À: ¢ √∫ π ª∂ ™ § √° π ™ ªπ ∫ √À
∂ÈÛ·ÁˆÁÈΤ˜ ·Ú·ÙËÚ‹ÛÂȘ
Ένα σύστηµα λογισµικού προκύπτει είτε µε µη αυξητική (ολοκληρωτική) είτε µε αυξη-
τική (σταδιακή) συγκρότηση (αναφέρεται και ως «ολοκλήρωση») των επί µέρους τµη-
µάτων του (Pressman[94]). Η στρατηγική ελέγχου ενός συστήµατος λογισµικού ανα-
γκαστικά προσαρµόζεται στη διαδικασία συγκρότησης που θα υιοθετηθεί.
Κατά τη µη αυξητική συγκρότηση (non – incremental integration) των τµηµάτων
λογισµικού, κάθε µονάδα ή τµήµα δοκιµάζεται ανεξάρτητα από τα υπόλοιπα τµήµατα
και όταν όλα τα τµήµατα έχουν δοκιµαστεί ανεπιτυχώς, τότε τα συνενώνουµε ώστε να
προκύψει το πλήρες σύστηµα. Είναι ακριβώς αυτή η τελευταία ενέργεια που οδήγησε
στην ονοµασία αυτού του τρόπου ως «συγκρότηση µε τη µορφή µεγάλης έκρηξης (big
– bang integration)».
Η επιτυχηµένη µη αυξητική ολοκλήρωση προϋποθέτει ότι η σχεδίαση του λογισµικού έχει
υψηλό βαθµό τµηµατοποίησης και ότι η διάδραση ανάµεσα στα τµήµατα του λογισµικού
είναι η ελάχιστη δυνατή. Εάν αυτές οι δύο προϋποθέσεις ισχύουν, τότε η δοκιµή του λογι-
σµικού ουσιαστικά περιλαµβάνει µόνο τον έλεγχο των διεπαφών ανάµεσα στα τµήµατά
του. Έτσι, εάν οι διεπαφές ανάµεσα στα τµήµατα είναι καλά προδιαγραµµένες, τότε η
διάρκεια και το κόστος των φάσεων ελέγχου µικραίνουν σηµαντικά.
Αντίθετα, κατά την αυξητική συγκρότηση (incremental integration), κάθε νέο τµήµα
του λογισµικού δοκιµάζεται αφού ενσωµατωθεί σε ένα σύνολο άλλων τµηµάτων, τα
οποία έχουν ήδη δοκιµασθεί. Έτσι, µε το ίδιο σύνολο δοκιµών ελέγχεται τόσο το νέο
τµήµα, όσο και η διάδρασή του µε τα άλλα τµήµατα.
Η πράξη έχει δείξει ότι είναι πάντα αποδοτικό να εφαρµόζουµε τις διαδικασίες ελέγχου
σταδιακά, καθώς αυξάνει ο αριθµός των τµηµάτων του λογισµικού που έχουν υλοποιη-
θεί. Με τον τρόπο αυτό, δοκιµές, οι οποίες στο παρελθόν ήταν ανεπιτυχείς (δηλαδή δεν
είχαν αποκαλύψει λάθη), µπορεί, καθώς ένα νέο τµήµα λογισµικού ολοκληρώνεται στο
σύστηµα, να ανακαλύψουν ελαττώµατα. Τότε, αυτά θα οφείλονται κατά πάσα πιθανό-
τητα στο νέο τµήµα λογισµικού, οπότε διευκολύνεται ο εντοπισµός και η διόρθωσή τους.
Στη συνέχεια θα παρουσιαστεί ο τρόπος µε τον οποίο οι πιο σηµαντικές από τις δρα-
στηριότητες ελέγχου ενσωµατώνονται πρακτικά στις διάφορες φάσεις ελέγχου, καθώς
προχωρεί η αυξητική συγκρότηση του λογισµικού. Η παρουσίαση ακολουθεί την οµα-
δοποίηση των δραστηριοτήτων ελέγχου µε βάση το στόχο που εξυπηρετούν οι δραστη-
ριότητες δοκιµών (οι τρεις φάσεις ελέγχου παρουσιάστηκαν στην ενότητα 4.2).
Η αρχή γίνεται από τις δοκιµές µονάδων (ενότητα 5.1), µε τις οποίες κάθε µονάδα ή
τµήµα του λογισµικού δοκιµάζεται ανεξάρτητα από το υπόλοιπο σύστηµα και πριν ενσω-
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 100
µατωθεί σε αυτό. Στη συνέχεια παρουσιάζονται οι δοκιµές συγκρότησης (ενότητα 5.2).
Πρόκειται για την περισσότερο σηµαντική φάση µιας στρατηγικής ελέγχου. Οι δραστη-
ριότητες αυτές περιλαµβάνουν, ανάλογα µε την κατεύθυνση της ολοκλήρωσης, δοκιµές
από – πάνω – προς – τα – κάτω ή από – κάτω – προς – τα – πάνω, ή ένα συνδυασµό
των δύο. Στην ενότητα 5.3 παρουσιάζονται οι δοκιµές επικύρωσης, οι οποίες εφαρµό-
ζονται κατά το διάστηµα παράδοσης του λογισµικού στους χρήστες του, ενώ το κεφά-
λαιο κλείνει µε την περιγραφή των δοκιµών ελέγχου συστήµατος (ενότητα 5.4), οι οποί-
ες εφαρµόζονται όταν το λογισµικό ήδη χρησιµοποιείται.
1 0 1 ∂ π ™ ∞ ° ø° π ∫ ∂ ™ ¶∞ ƒ∞∆ ∏ƒ ∏™ ∂ π ™
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 101
1 0 2 K E ºA § A I O 5 : ¶ƒ∞ ∫ ∆ π ∫ ∏ E º∞ ƒ ª√° ∏ ∆ ø¡ ¢ ƒ∞ ™ ∆ ∏ƒ π √∆ ∏∆ ø¡ E § ∂ ° à √À: ¢ √∫ π ª∂ ™ § √° π ™ ªπ ∫ √À
5.1 ¢ÔÎÈ̤˜ ÌÔÓ¿‰ˆÓ
Οι δοκιµές των µονάδων του λογισµικού (unit testing) επικεντρώνονται στα µικρό-
τερα τµήµατα του λογισµικού και στοχεύουν να δείξουν ότι καθένα από αυτά λει-
τουργεί σωστά και ικανοποιεί τις προδιαγραφές του. Για τη σχεδίαση των δοκιµών
χρησιµοποιούνται οι προδιαγραφές και ο κώδικας κάθε τµήµατος και εφαρµόζονται
τεχνικές διαφανούς κουτιού.
Η πολυπλοκότητα της σχεδίασης των περιπτώσεων ελέγχου ενός τµήµατος είναι σχε-
τικά µικρή, εξαιτίας του µικρού µεγέθους του κώδικα και της µειωµένης πολυπλοκό-
τητας της επεξεργασίας που εκτελεί ένα (καλά σχεδιασµένο) τµήµα. Η πολυπλοκότη-
τα αυτή µειώνεται ακόµη περισσότερο όταν η σχεδίαση εµφανίζει υψηλή συνοχή (στην
ιδανική περίπτωση, όταν κάθε τµήµα εκτελεί µια µόνο λειτουργία). Αντίστοιχα όµως,
είναι περιορισµένη και η εµβέλεια των δοκιµών που µπορούµε να εφαρµόσουµε σε
ένα τµήµα, ενώ το ίδιο µικρή είναι και η σηµασία των λαθών που θα ανακαλύψουµε.
Αυτό όµως δεν πρέπει να µας οδηγήσει σε επιφανειακές δοκιµές των µονάδων του
λογισµικού, καθώς το κόστος διόρθωσης κάθε ελαττώµατος που θα ξεφύγει από αυτή
τη φάση γίνεται στη συνέχεια των δοκιµών πολύ µεγάλο έως απαγορευτικό!
Στις δοκιµές µονάδων περιλαµβάνονται:
• η δοκιµή της διεπαφής του τµήµατος, ώστε να διασφαλιστεί ότι οι πληροφορίες
εισέρχονται στο τµήµα και εξέρχονται από αυτό σωστά,
• η δοκιµή των τοπικών (εσωτερικών) δοµών δεδοµένων, ώστε να διασφαλιστεί
ότι το τµήµα, κατά την εκτέλεση των λειτουργιών του, δεν παραβιάζει την ακε-
ραιότητα των δεδοµένων που διατηρεί προσωρινά,
• η δοκιµή των οριακών συνθηκών, ώστε να διασφαλιστεί ότι το τµήµα λειτουρ-
γεί σωστά κοντά στα όρια επεξεργασίας που του έχουν τεθεί,
• η δοκιµή βασικών µονοπατιών εκτέλεσης, ώστε η εκτέλεση κάθε εντολής του
κώδικα του τµήµατος να δοκιµαστεί τουλάχιστον µια φορά,
• η δοκιµή του χειρισµού λαθών που περιλαµβάνεται στο τµήµα, δηλαδή δοκι-
µαστική εκτέλεση του κώδικα που εκτελείται όταν παρουσιαστούν σφάλµατα.
Σχόλιο Μελέτης
Στο σηµείο αυτό σας προτείνουµε να ανατρέξετε στο Kεφάλαιο 4 και να κάνετε
µια σύντοµη ανασκόπηση των τεχνικών σχεδίασης περιπτώσεων ελέγχου.
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 102
5.1.1 ¢ÔÎÈÌ‹ ‰ÈÂ·ÊÒÓ
Καθώς η διεπαφή ενός τµήµατος είναι το σηµείο απ’ όπου πρέπει να αρχίσουµε τις
δοκιµές (εάν τα δεδοµένα δεν εισέρχονται και εξέρχονται σωστά, τα αποτελέσµατα
όλων των υπόλοιπων δοκιµών δεν έχουν αξία), ακολουθεί ένας κατάλογος µε προ-
τεινόµενα σηµεία ελέγχου:
• O αριθµός των δεδοµένων εισόδου κατά την κλήση του τµήµατος από άλλο
τµήµα πρέπει να είναι ίσος µε τον αριθµό των παραµέτρων που περιέχονται στη
διεπαφή του υπό δοκιµή τµήµατος.
• Oι τύποι και η διάταξη των δεδοµένων κλήσης του άλλου τµήµατος και των
παραµέτρων εισόδου του υπό δοκιµή τµήµατος πρέπει να ταιριάζουν ακριβώς.
• O αριθµός των δεδοµένων που χρησιµοποιούνται για να κληθεί κάποιο άλλο
τµήµα από το υπό δοκιµή τµήµα πρέπει να είναι ίσος µε τον αριθµό των παρα-
µέτρων που περιέχονται στη διεπαφή του άλλου τµήµατος.
• Oι τύποι και η διάταξη των δεδοµένων κλήσης του υπό δοκιµή τµήµατος και των
παραµέτρων εισόδου του άλλου τµήµατος πρέπει να ταιριάζουν ακριβώς,.
• Oι τύποι και η διάταξη των παραµέτρων κλήσης συναρτήσεων εσωτερικών του
υπό δοκιµή τµήµατος πρέπει να είναι σωστά ορισµένοι.
• ∆εν πρέπει να γίνεται αναφορά σε παραµέτρους που δεν «περνούν» µέσα από τη
διεπαφή του τµήµατος.
• ∆εν πρέπει εσωτερικά να τροποποιούνται δεδοµένα τα οποία το υπό δοκιµή
τµήµα µπορεί µόνο να διαβάσει.
• Oι σφαιρικές µεταβλητές πρέπει να χρησιµοποιούνται µε τρόπο συνεπή ως προς
τον ορισµό τους.
• Oποιαδήποτε εξωτερικά αρχεία πρέπει να χρησιµοποιούνται µε συνέπεια ως προς
τα κατηγορήµατά τους και µε σωστές εντολές OPEN/CLOSE.
• Tα εξωτερικά αρχεία πρέπει να ανοίγονται πριν χρησιµοποιηθούν.
• Πρέπει να γίνεται χειρισµός της περίπτωσης εµφάνισης του χαρακτήρα «τέλος
αρχείου».
• Πρέπει να γίνεται χειρισµός της περίπτωσης εµφάνισης λάθους εισόδου – εξόδου.
5.1.2 ¢ÔÎÈÌ‹ ÙÔÈÎÒÓ ‰ÔÌÒÓ ‰Â‰Ô̤ӈÓ
Η δοκιµή των τοπικών δοµών δεδοµένων στοχεύει στην ανακάλυψη λαθών στα εξής
σηµεία:
1 0 3 5 . 1 ¢ √∫ π ª∂ ™ ª√¡∞ ¢ ø¡
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 103
1 0 4 K E ºA § A I O 5 : ¶ƒ∞ ∫ ∆ π ∫ ∏ E º∞ ƒ ª√° ∏ ∆ ø¡ ¢ ƒ∞ ™ ∆ ∏ƒ π √∆ ∏∆ ø¡ E § ∂ ° à √À: ¢ √∫ π ª∂ ™ § √° π ™ ªπ ∫ √À
• λανθασµένη ή ασυνεπής πληκτρολόγηση
• λανθασµένη αρχικοποίηση µεταβλητών ή χρήση λανθασµένων εξορισµού τιµών
• λάθος χρήση των ονοµάτων των µεταβλητών
• ασυνεπής χρήση των τύπων δεδοµένων
• σφάλµατα υπερχείλισης (προς το πάνω ή το κάτω όριο) και διευθυνσιοδότησης
5.1.3 ¢ÔÎÈÌ‹ ÌÔÓÔ·ÙÈÒÓ ÂÎÙ¤ÏÂÛ˘
Για τη δοκιµή της εκτέλεσης του κώδικα του τµήµατος µπορούν να χρησιµοποιη-
θούν οι τεχνικές δοκιµής των βασικών µονοπατιών και των δοµών επανάληψης, µε
στόχο να ανακαλύψουν ελαττώµατα που οφείλονται σε εσφαλµένους υπολογισµούς,
λανθασµένες συγκρίσεις ή ακατάλληλη ροή ελέγχου.
Στα περισσότερο συνηθισµένα λάθη υπολογισµών περιλαµβάνονται η λανθασµένη
διατύπωση ή χρήση της προτεραιότητας των τελεστών, η λανθασµένη αρχικοποίη-
ση, η ανεπαρκής ακρίβεια των υπολογισµών και η λανθασµένη συµβολική παρά-
σταση µιας αριθµητικής ή λογικής έκφρασης.
Επειδή η µεταβολή της ροής ελέγχου συνήθως οφείλεται σε κάποια σύγκριση, τα
προκύπτοντα ελαττώµατα είναι στενά συσχετισµένα. Οι δοκιµές πρέπει να ανακα-
λύψουν λάθη, όπως η σύγκριση διαφορετικών τύπων δεδοµένων, η λανθασµένη
χρήση λογικών τελεστών, η ανισότητα δύο ποσοτήτων που οφείλεται αποκλειστικά
σε λάθος ακρίβειας των υπολογισµών, η σύγκριση λάθος µεταβλητών, ο τερµατι-
σµός µιας δοµής επανάληψης µε ακατάλληλο τρόπο ή η παντελής απουσία τερµατι-
σµού, η αδυναµία εξόδου υπό συνθήκη από µια δοµή επανάληψης και η λάθος τρο-
ποποίηση των µεταβλητών που καθορίζουν την επανάληψη.
5.1.4 ¢ÔÎÈÌ‹ ÙÔ˘ ÎÒ‰Èη ‰È·¯Â›ÚÈÛ˘ ÛÊ·ÏÌ¿ÙˆÓ
Παρ’ όλο που η καλή σχεδιαστική πρακτική υπαγορεύει την πρόβλεψη των συνθη-
κών εµφάνισης σφαλµάτων και το γράψιµο κώδικα για τη διαχείριση των λαθών,
συνήθως η λειτουργία του ίδιου του κώδικα διαχείρισης λαθών δεν ελέγχεται ποτέ!
Κι όµως, πιθανά ελαττώµατα που µπορεί να εµφανίσει αυτός ο κώδικας είναι τα εξής:
• H περιγραφή του ελαττώµατος είναι ακατανόητη.
• O κώδικας διαχειρίζεται διαφορετικό ελάττωµα από αυτό που υποτίθεται – σύµ-
φωνα µε την περιγραφή του – ότι διαχειρίζεται.
• H συνθήκη εµφάνισης του ελαττώµατος προκαλεί την παρέµβαση του συστήµα-
τος πριν την εκτέλεση του δικού µας κώδικα διαχείρισης.
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 104
• H επεξεργασία των συνθηκών που οδήγησαν στην εµφάνιση του λάθους είναι
λανθασµένη.
• H περιγραφή του λάθους δεν παρέχει αρκετή πληροφορία για τον εντοπισµό της
αιτίας του ελαττώµατος.
5.1.5 ¢ÔÎÈÌ‹ ÔÚÈ·ÎÒÓ Û˘ÓıËÎÒÓ
Τελευταίες από όλες πρέπει να γίνονται οι δοκιµές του λογισµικού σε οριακές συν-
θήκες λειτουργίας. Πρόκειται για ένα σηµαντικό σύνολο δοκιµών, καθώς το λογι-
σµικό τείνει να αστοχεί στα όρια της λειτουργίας του.
5.1.6 √‰ËÁÔÈ Î·È ÛÙÂϤ¯Ë
Οι δραστηριότητες ελέγχου των µονάδων ή τµηµάτων λογισµικού είναι στενά συν-
δεµένες µε την ανάπτυξη των µονάδων ή των τµηµάτων αυτών. Επειδή όµως κάθε
τµήµα δεν είναι ένα ανεξάρτητο πρόγραµµα, συνήθως απαιτείται η συγγραφή επί-
πλέον κώδικα για τις δοκιµές που περιλαµβάνονται στις δραστηριότητες ελέγχου. Ο
πλεονάζων αυτός κώδικας ουσιαστικά εξοµοιώνει το περιβάλλον µέσα στο οποίο θα
λειτουργήσει το υπό δοκιµή τµήµα, όταν ενσωµατωθεί στο πλήρες σύστηµα λογι-
σµικού. Όπως φαίνεται και από το Σχήµα 5.1, για το περιβάλλον δοκιµής ενός τµή-
µατος λογισµικού, µπορεί να απαιτηθεί η ανάπτυξη των εξής τµηµάτων:
• Eνός τµήµατος λογισµικού που θα «οδηγεί» την εκτέλεση του υπό δοκιµή τµήµατος
(driver). Το τµήµα αυτό συνήθως εκτελεί το υπό δοκιµή τµήµα χρησιµοποιώντας στη
διεπαφή τα δεδοµένα ελέγχου και τυπώνει τα αποτελέσµατα της εκτέλεσης.
• Tµηµάτων λογισµικού που αποτελούν «στελέχη» του υπό δοκιµή τµήµατος και εξο-
µοιώνουν τη λειτουργία των τµηµάτων λογισµικού που καλούνται (εκτελούνται)
από αυτό (stubs). Κάθε τέτοιο τµήµα χρησιµοποιεί την πραγµατική διεπαφή του τµή-
µατος που εξοµοιώνει, αλλά συνήθως απλά τυπώνει µια επιβεβαίωση της κλήσης
του, εκτελεί την ελάχιστη δυνατή επεξεργασία των δεδοµένων και τερµατίζει.
1 0 5 5 . 1 ¢ √∫ π ª∂ ™ ª√¡∞ ¢ ø¡
™¯‹Ì· 5.1
Ο ρόλος
των οδηγών και
των στελεχών
Οδηγός
Τµήµα Υπό 
∆οκιµή
Στέλεχος 
Για Τµήµα 
Α
Στέλεχος 
Για Τµήµα 
Β
Αποτελέσµατα 
∆οκιµής
Περιπτώσεις 
Ελέγχου
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 105
1 0 6 K E ºA § A I O 5 : ¶ƒ∞ ∫ ∆ π ∫ ∏ E º∞ ƒ ª√° ∏ ∆ ø¡ ¢ ƒ∞ ™ ∆ ∏ƒ π √∆ ∏∆ ø¡ E § ∂ ° à √À: ¢ √∫ π ª∂ ™ § √° π ™ ªπ ∫ √À
Η ανάπτυξη οδηγών ή στελεχών αποτελεί επιβάρυνση του χρονοδιαγράµµατος, αφού
ο κώδικας αυτός δεν παραδίδεται στον τελικό χρήστη. Eπίπλέον, είναι πρακτικά
άχρηστο να δοκιµάζουµε τον κώδικα χρησιµοποιώντας απλά προγράµµατα οδηγών
ή στελεχών, τα οποία δεν εξοµοιώνουν πλήρως το περιβάλλον εκτέλεσης ενός τµή-
µατος. Έτσι, πολλές φορές είναι προτιµότερο να αναβάλουµε το διεξοδικό έλεγχο
µέχρι τη φάση συγκρότησης του λογισµικού.
ªÂϤÙË ÂÚ›ÙˆÛ˘ 5.1
Στο Σχήµα 5.2 φαίνεται το διάγραµµα δοµής του πληροφοριακού συστήµατος, το
οποίο ανέπτυξε η εταιρεία THUNDERSOFT για τις ανάγκες της επιχείρησης παιδι-
κών ρούχων CHILDWARE. Κατά την υλοποίηση του συστήµατος, η οµάδα ανά-
πτυξης εφάρµοσε ένα σύνολο δοκιµών των µονάδων του, ώστε να εµποδίσει τη διά-
δοση σηµαντικών ελαττωµάτων στα επόµενα στάδια ανάπτυξης.
™¯‹Ì· 5.2
Το σύστηµα
λογισµικού
της εταιρείας
CHILDWARE
CHILDWARE
Προσωπικό
Πρόσληψη
Απόλυση Αναφορές
Μεταβολή
Λογιστήριο
Αρχείο Αναφορές Μισθοδοσία
Ατοµικά 
Στοιχεία
Στοιχεία 
Εργασίας
Υπολογισµός 
Μικτής 
Αµοιβής
Υπολογισµός 
Κρατήσεων
Αποθήκη
Προµήθειες Ελλείψεις Πωλήσεις
Εξαγωγές
Υποκατα– 
στήµατα
Αρχικά δοκιµάστηκαν τα µονοπάτια εκτέλεσης κάθε τµήµατος µαζί µε τις δοµές
δεδοµένων που αυτό χρησιµοποιεί. Σχεδόν ταυτόχρονα, δοκιµάστηκαν οι διεπαφές
ανάµεσα στα τµήµατα (παρατηρήστε ότι, για παράδειγµα, το τµήµα Προσωπικό
καλεί τα τµήµατα Πρόσληψη Υπαλλήλου, Απόλυση Υπαλλήλου, Μεταβολή Υπαλ-
λήλου και Αναφορές Προσωπικού, ενώ καλείται από το συνολικό σύστηµα λογι-
σµικού). Ακολούθησε η δοκιµή οριακών συνθηκών και τέλος η δοκιµή του κώδικα
διαχείρισης των πιθανών ελαττωµάτων.
Για την εφαρµογή των δοκιµών χρειάστηκε η ανάπτυξη οδηγών και στελεχών. Για
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 106
παράδειγµα, η δοκιµή του τµήµατος Προσωπικό απαιτεί την ανάπτυξη:
• ενός οδηγού που θα εξοµοιώνει τη συµπεριφορά του συνολικού συστήµατος (από
το οποίο καλείται το τµήµα Προσωπικό),
• τεσσάρων στελεχών, καθένα από τα οποία εξοµοιώνει τη συµπεριφορά ενός από
τα τµήµατα που καλεί το Προσωπικό.
1 0 7 5 . 2 ¢ √∫ π ª∂ ™ ™ À ° ∫ ƒ √∆ ∏™ ∏™
Θεωρήστε ότι σας έχει ανατεθεί ο έλεγχος του τµήµατος Λογιστήριο του λογισµι-
κού που περιγράφεται στην προηγούµενη µελέτη περίπτωσης. ∆οκιµάστε να
συµπληρώσετε στον πίνακα που ακολουθεί ποιους οδηγούς και ποια στελέχη θα
χρειαστείτε για να δοκιµάσετε πρώτο το τµήµα του λογισµικού που αναφέρεται
στην αριστερή στήλη.
ΤΜΗΜΑ Ο∆ΗΓΟΙ ΣΤΕΛΕΧΗ
Αρχείο
Αναφορές
Ατοµικά στοιχεία
Υπολογισµός µικτής αµοιβής
Μισθοδοσία
Στοιχεία εργασίας
Υπολογισµός κρατήσεων
ÕÛÎËÛË ·˘ÙÔ·ÍÈÔÏfiÁËÛ˘ 5.1
5.2 ¢ÔÎÈ̤˜ Û˘ÁÎÚfiÙËÛ˘
Οι δοκιµές συγκρότησης (integration testing) στοχεύουν στην ανακάλυψη ελατ-
τωµάτων που οφείλονται στη διάδραση των (ήδη δοκιµασµένων) µονάδων ή τµη-
µάτων λογισµικού, καθώς αυτά ολοκληρώνονται µε συστηµατικό τρόπο κατά την
υλοποίηση της αρχιτεκτονικής δοµής του λογισµικού. Συνεπώς, οι δοκιµές της φάσης
αυτής είναι στενά συνδεµένες µε τη στρατηγική συγκρότησης που θα ακολουθηθεί.
Στη συνέχεια, περιγράφονται ορισµένες πρακτικές, οι οποίες έχουν εφαρµογή κυρίως
όταν επιλεγεί η αυξητική συγκρότηση του λογισµικού.
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 107
1 0 8 K E ºA § A I O 5 : ¶ƒ∞ ∫ ∆ π ∫ ∏ E º∞ ƒ ª√° ∏ ∆ ø¡ ¢ ƒ∞ ™ ∆ ∏ƒ π √∆ ∏∆ ø¡ E § ∂ ° à √À: ¢ √∫ π ª∂ ™ § √° π ™ ªπ ∫ √À
5.2.1 ¢ÔÎÈÌ‹ Û˘ÁÎÚfiÙËÛ˘ ·Ô ¿Óˆ ÚÔ˜ Ù· οو
Κατά την συγκρότηση από πάνω προς τα κάτω (top – down integration), το λογι-
σµικό «χτίζεται» ξεκινώντας από το κύριο τµήµα ή πρόγραµµα, στο οποίο σταδια-
κά ολοκληρώνονται τα υπόλοιπα τµήµατα. Ανάλογα µε την κατεύθυνση της διαδι-
κασίας, η συγκρότηση µπορεί να προχωρά είτε κατά πλάτος, είτε σε βάθος.
Αντίστοιχα, η πρακτική εφαρµογή της δοκιµής από πάνω προς τα κάτω (top –
down testing) ενός λογισµικού επιβάλλει τη δοκιµή των τµηµάτων υψηλού επιπέδου
ενός συστήµατος πριν δοκιµαστούν τα επί µέρους τµήµατα.
Η δοκιµή συγκρότησης από πάνω προς τα κάτω περιλαµβάνει τα εξής βήµατα:
1. Aρχικά το λογισµικό αναπαρίσταται σαν ένα αφηρηµένο τµήµα, ενώ τα συστα-
τικά του τµήµατα αναπαρίστανται ως στελέχη µε περιορισµένη εσωτερική λει-
τουργικότητα. Το τµήµα αυτό υλοποιείται και δοκιµάζεται.
2. Aφού το κύριο τµήµα έχει δοκιµαστεί, χρησιµοποιείται ως οδηγός για τη δοκι-
µή των κύριων υποσυστηµάτων. Τα τµήµατα αυτά υλοποιούνται, αντικαθιστούν
τα αντίστοιχα στελέχη και δοκιµάζονται.
3. H πρακτική συνεχίζεται µε τον ίδιο τρόπο, µέχρι να υλοποιηθούν και δοκιµα-
στούν και τα τµήµατα του χαµηλότερου επιπέδου. Η σειρά υλοποίησης και ολο-
κλήρωσης των τµηµάτων µπορεί να γίνεται κατά πλάτος ή σε βάθος.
4. Tο συνολικό σύστηµα µπορεί να δοκιµαστεί.
ªÂϤÙË ÂÚ›ÙˆÛ˘ 5.1 (συνέχεια)
Εάν εφαρµόσουµε δοκιµές από πάνω προς τα κάτω στο λογισµικό της
CHILDWARE, θα αρχίσουµε τη δοκιµή των τµηµάτων του λογισµικού από το
κυρίως πρόγραµµα (Σχήµα 5.3(α)), χρησιµοποιώντας στελέχη για τα υποσυστήµα-
τα. Στη συνέχεια, όταν υλοποιηθεί το τµήµα Προσωπικό, αντικαθιστούµε το στέλε-
χος και δοκιµάζουµε πάλι το σύστηµα (Σχήµα 5.3(β)). Παρατηρήστε ότι χρησιµο-
ποιούµε στελέχη για τα τµήµατα που καλεί το Προσωπικό. Με τον ίδιο τρόπο ολο-
κληρώνουµε στο πλήρες σύστηµα το τµήµα Λογιστήριο και Αποθήκη (Σχήµα 5.3(γ)),
ενώ φροντίζουµε να δοκιµάζουµε το συνολικό σύστηµα µετά από κάθε συγκρότη-
ση. Στη συνέχεια, ολοκληρώνουµε ένα – ένα τα τµήµατα χαµηλότερου επιπέδου (στο
Σχήµα 5.3(δ) δείχνεται η ολοκλήρωση της διαδικασίας διαχείρισης της πρόσληψης
ενός υπαλλήλου), δοκιµάζοντας κάθε φορά το συνολικό σύστηµα.
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 108
Η δοκιµή από πάνω προς τα κάτω καλό είναι να συνδυάζεται µε ανάπτυξη από πάνω
προς τα κάτω, ώστε κάθε τµήµα λογισµικού να ελέγχεται µόλις υλοποιηθεί. Τότε, η ανά-
πτυξη, η συγκρότηση και η δοκιµή µπορούν να συνδυασθούν σε µια δραστηριότητα.
1 0 9 5 . 2 ¢ √∫ π ª∂ ™ ™ À ° ∫ ƒ √∆ ∏™ ∏™
™¯‹Ì· 5.3
Συγκρότηση από
πάνω προς τα
κάτω του λογισµι-
κού της
CHILDWARE (α) (β)
(γ)
(δ)
CHILDWARE CHILDWARE
CHILDWARE CHILDWARE
Προσωπικό Λογιστήριο Αποθήκη
Πρόσληψη
Προσωπικό
Προσωπικό
Λογιστήριο Αποθήκη
Η δοκιµή συγκρότησης από πάνω προς τα κάτω εξετάζει νωρίς τα σηµαντικά σηµεία
ελέγχου ή λήψης αποφάσεων σε ένα λογισµικό και µπορεί από τις αρχικές δραστη-
ριότητες ελέγχου να ανακαλύψει τα σηµαντικά λάθη σχεδιασµού. Η ανακάλυψη
τέτοιων λαθών νωρίς σηµαίνει ότι αυτά είναι δυνατό να διορθωθούν χωρίς επιβά-
ρυνση και οπωσδήποτε αποφεύγοντας εκτεταµένη επανασχεδίαση ή εκ νέου υλο-
ποίηση του λογισµικού.
Eπίπλέον, µια περιορισµένη αλλά λειτουργική έκδοση του λογισµικού είναι διαθέ-
σιµη από τα αρχικά στάδια ανάπτυξης, κάτι που ανυψώνει το ηθικό της οµάδας ανά-
πτυξης! Αυτή η έκδοση µπορεί ακόµη και να διατεθεί στους χρήστες µε στόχο να
ξεκινήσει νωρίς η επικύρωση του λογισµικού.
Το βασικό πρόβληµα στην εφαρµογή αυτής της πρακτικής έγκειται στη δυσκολία
ανάπτυξης στελεχών που να προσοµοιώνουν ικανοποιητικά τα αληθινά τµήµατα,
χωρίς τα τελευταία να υλοποιηθούν πραγµατικά. Eπίπλέον, επειδή συνήθως η επε-
ξεργασία των δεδοµένων συµβαίνει στα τµήµατα χαµηλού επιπέδου, στο λογισµικό
δεν «κυκλοφορούν» αρκετά δεδοµένα µέχρι να υλοποιηθούν αυτά τα τµήµατα (θυµη-
θείτε ότι τα στελέχη απλά προσοµοιώνουν την εξωτερική συµπεριφορά ενός τµή-
µατος – δεν εκτελούν επεξεργασία, ούτε παράγουν δεδοµένα). Ένα άλλο µειονέ-
κτηµα οφείλεται στο ότι τα τµήµατα υψηλών επιπέδων ενός συστήµατος λογισµι-
κού συνήθως δεν παράγουν παρατηρήσιµη έξοδο, οπότε η οµάδα δοκιµής πρέπει να
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 109
1 1 0 K E ºA § A I O 5 : ¶ƒ∞ ∫ ∆ π ∫ ∏ E º∞ ƒ ª√° ∏ ∆ ø¡ ¢ ƒ∞ ™ ∆ ∏ƒ π √∆ ∏∆ ø¡ E § ∂ ° à √À: ¢ √∫ π ª∂ ™ § √° π ™ ªπ ∫ √À
υλοποιήσει ένα τεχνητό περιβάλλον δοκιµής του λογισµικού, το οποίο θα παράγει
εξόδους σε όλα τα επίπεδα.
Η πρακτική είναι ανεφάρµοστη σε αντικειµενοστραφή συστήµατα, τα οποία δεν
περιλαµβάνουν συνήθως κάποιας µορφής ιεραρχία ανάµεσα στα αντικείµενα. Μπο-
ρεί όµως να εφαρµοστεί εσωτερικά στις µεθόδους κάθε αντικειµένου.
Έστω ότι επιλέγετε την (κατά πλάτος) από πάνω προς τα κάτω δοκιµή του λογι-
σµικού του τµήµατος Λογιστήριο. ∆οκιµάστε να τοποθετήσετε στον πίνακα που
ακολουθεί τα τµήµατα του προγράµµατος µε τη σωστή σειρά ελέγχου, σηµειώνο-
ντας ποιους οδηγούς και ποια στελέχη θα χρειαστείτε σε κάθε βήµα. Τι παρατηρεί-
τε;
ΤΜΗΜΑ Ο∆ΗΓΟΙ ΣΤΕΛΕΧΗ
1.
2.
3.
4.
5.
6.
7.
8.
ÕÛÎËÛË ·˘ÙÔ·ÍÈÔÏfiÁËÛ˘ 5.2
5.2.2 ¢ÔÎÈÌ‹ Û˘ÁÎÚfiÙËÛ˘ ·Ô Î¿Ùˆ ÚÔ˜ Ù· ¿Óˆ
Κατά την από κάτω προς τα πάνω συγκρότηση (bottom – up integration), ανα-
πτύσσονται πρώτα τα χαµηλού επιπέδου τµήµατα του λογισµικού, τα οποία συγκρο-
τούνται σε υποσυστήµατα, τα οποία µε τη σειρά τους συγκροτούνται στο πλήρες
σύστηµα. Συνεπώς, κατά την ολοκλήρωση ενός τµήµατος είναι πάντα διαθέσιµα τα
«εσωτερικά» του τµήµατα, οπότε δεν υπάρχει η ανάγκη υλοποίησης στελεχών.
Αντίστοιχα, η από κάτω προς τα πάνω δοκιµή (bottom – up testing) ακολουθεί αντί-
στροφη πορεία από τη δοκιµή από πάνω προς τα κάτω, ξεκινώντας από τη δοκιµή
των µικρότερων τµηµάτων και προχωρώντας προς µεγαλύτερα τµήµατα και υπο –
συστήµατα, µέχρι να δοκιµαστεί το τελικό σύστηµα.
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 110
ªÂϤÙË ÂÚ›ÙˆÛ˘ 5.1 (συνέχεια)
Η εφαρµογή δοκιµών από κάτω προς τα πάνω στο λογισµικό της CHILDWARE υπα-
γορεύει την έναρξη του ελέγχου από τις µονάδες λογισµικού του χαµηλότερου επι-
πέδου (π.χ. από τη διαδικασία καταγραφής των πωλήσεων των υποκαταστηµάτων,
όπως φαίνεται στο Σχήµα 5.4(α), παρατηρήστε ότι χρειάζεται να αναπτύξουµε έναν
οδηγό που θα εξοµοιώνει τη συµπεριφορά του τµήµατος Πωλήσεις). Στη συνέχεια,
αναπτύσσουµε και δοκιµάζουµε µε τον ίδιο τρόπο το τµήµα καταγραφής των Eξα-
γωγών. Αφού αναπτυχθεί το τµήµα Πωλήσεις, τα δύο επί µέρους τµήµατα συγκρο-
τούνται σε αυτό και δοκιµάζεται το υποσύστηµα (Σχήµα 5.4(β)) χρησιµοποιώντας
έναν οδηγό για το τµήµα Αποθήκη. Μετά την υλοποίηση του τµήµατος του λογι-
σµικού για την Αποθήκη, συγκροτούνται σε αυτό όλα τα τµήµατα και δοκιµάζεται
το σύστηµα χρησιµοποιώντας έναν οδηγό για το συνολικό σύστηµα (Σχήµα 5.4(γ)).
1 1 1 5 . 2 ¢ √∫ π ª∂ ™ ™ À ° ∫ ƒ √∆ ∏™ ∏™
Συνεπώς, η δοκιµή συγκρότησης από κάτω προς τα πάνω µπορεί να περιλαµβάνει
τα εξής βήµατα:
1. Πρώτα υλοποιούνται και δοκιµάζονται ανεξάρτητα τα τµήµατα του χαµηλότε-
ρου επιπέδου.
2. Tα τµήµατα αυτά συνδυάζονται σε οµάδες (clusters) µε βάση τη συµµετοχή
τους σε κοινές λειτουργίες. Η κάθε οµάδα δοκιµάζεται χρησιµοποιώντας έναν
κατάλληλο οδηγό.
3. Oι οδηγοί αφαιρούνται, οι οµάδες ολοκληρώνονται και το τµήµα που προκύ-
πτει δοκιµάζεται χρησιµοποιώντας τον κατάλληλο οδηγό.
4. H πρακτική συνεχίζεται µε τον ίδιο τρόπο µέχρι να προκύψει το συνολικό
σύστηµα (το οποίο, βέβαια, δοκιµάζεται χωρίς τη χρήση οδηγών).
™¯‹Ì· 5.4
Συγκρότηση
από κάτω
προς τα πάνω
του λογισµικού
της CHILDWARE
(α) (β) (γ)
Αποθήκη
Προµήθειες Ελλείψεις Πωλήσεις Πωλήσεις
Εξαγωγές Εξαγωγές
Υποκατα– 
στήµατα
Υποκατα– 
στήµατα
Υποκατα– 
στήµατα
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 111
1 1 2 K E ºA § A I O 5 : ¶ƒ∞ ∫ ∆ π ∫ ∏ E º∞ ƒ ª√° ∏ ∆ ø¡ ¢ ƒ∞ ™ ∆ ∏ƒ π √∆ ∏∆ ø¡ E § ∂ ° à √À: ¢ √∫ π ª∂ ™ § √° π ™ ªπ ∫ √À
Όπως και στην προηγούµενη περίπτωση, η ανάπτυξη και ο έλεγχος µπορούν να συν-
δυασθούν σε µια δραστηριότητα, εάν η δοκιµή από κάτω προς τα πάνω συνδυάζεται
µε ανάπτυξη από κάτω προς τα πάνω. Γενικά, τα πλεονεκτήµατα της δοκιµής από
πάνω προς τα κάτω αποτελούν µειονεκτήµατα της δοκιµής από κάτω προς τα πάνω
και αντίστροφα. Η ανάγκη ανάπτυξης οδηγών αποτελεί ένα επίπλέον µειονέκτηµα
της από κάτω προς τα πάνω δοκιµής συγκρότησης, το οποίο όµως ισοσταθµίζεται από
την απουσία των στελεχών. Ένα άλλο πιο σηµαντικό µειονέκτηµα είναι ότι το συνο-
λικό λογισµικό γίνεται «ορατό» µόνο όταν ενσωµατωθεί και το τελευταίο τµήµα.
Η πρακτική αυτή είναι κατάλληλη για δραστηριότητες ελέγχου αντικειµενοστραφών
συστηµάτων λογισµικού, αφού επιβάλλει τη δοκιµή ανεξάρτητων αντικειµένων πριν
αυτά συγκροτηθούν σε µια οµάδα (οπότε µπορεί µε τον ίδιο τρόπο να δοκιµαστεί
ολόκληρη η οµάδα).
Εστω ότι επιλέγετε την από κάτω προς τα πάνω δοκιµή του λογισµικού του τµή-
µατος Λογιστήριο. ∆οκιµάστε να τοποθετήσετε στον πίνακα που ακολουθεί τα τµή-
µατα του προγράµµατος µε τη σωστή σειρά ελέγχου, σηµειώνοντας ποιους οδη-
γούς και ποια στελέχη θα χρειαστείτε σε κάθε βήµα. Τι παρατηρείτε;
ΤΜΗΜΑ Ο∆ΗΓΟΙ ΣΤΕΛΕΧΗ
1.
2.
3.
4.
5.
6.
7.
8.
ÕÛÎËÛË ·˘ÙÔ·ÍÈÔÏfiÁËÛ˘ 5.3
5.2.3 ™˘Ó‰˘·ÛÌfi˜
Εάν η από πάνω προς τα κάτω ανάπτυξη συνδυαστεί µε από κάτω προς τα πάνω δοκι-
µή συγκρότησης, τότε όλα τα τµήµατα του λογισµικού θα πρέπει να υλοποιηθούν πριν
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 112
αρχίσουν οι δοκιµές του. Αυτό σηµαίνει ότι λάθη σχεδίασης είναι απίθανο να ανα-
καλυφθούν πριν ελεγχθεί µεγάλο µέρος του συστήµατος, οπότε η διόρθωσή τους µπο-
ρεί να επιβαρύνει πολύ το χρονοδιάγραµµα ανάπτυξης. Το πολύ σοβαρό αυτό πρό-
βληµα έχει προκαλέσει τη σκληρή κριτική της συνδυασµένης πρακτικής.
Από την άλλη πλευρά, πρέπει να έχουµε στο µυαλό µας ότι µια αυστηρή από πάνω
προς τα κάτω διαδικασία ανάπτυξης που συνδυάζει από πάνω προς τα κάτω δοκιµές
συγκρότησης είναι πρακτικά ανεφάρµοστη – σχεδόν πάντα είναι απαραίτητη η ανά-
πτυξη και ο έλεγχος κρίσιµων τµηµάτων χαµηλού επιπέδου.
Προτείνεται, λοιπόν, ο συνδυασµός της από πάνω προς τα κάτω δοκιµής για τα τµή-
µατα υψηλού επιπέδου µε την από κάτω προς τα πάνω δοκιµή για τα τµήµατα χαµη-
λότερων επιπέδων. Αυτή η συνδυαστική προσέγγιση (που πολλές φορές καλείται
«σάντουιτς δοκιµή συγκρότησης») µπορεί να είναι τελικά ο καλύτερος συµβιβασµός.
Σε τέτοια δοκιµή, σηµαντικό ρόλο παίζει και η ικανότητα της οµάδας δοκιµών να
αναγνωρίσει και να δοκιµάσει όσο πιο νωρίς γίνεται τα κρίσιµα τµήµατα. Ένα κρί-
σιµο τµήµα έχει ένα ή περισσότερα από τα ακόλουθα χαρακτηριστικά:
• Iκανοποιεί ταυτόχρονα πολλές από τις απαιτήσεις των χρηστών.
• Yλοποιεί ένα σηµαντικό επίπεδο ελέγχου (βρίσκεται δηλαδή σχετικά ψηλά στην
αρχιτεκτονική του λογισµικού).
• Eίναι πολύπλοκο ή υποψήφιο να εµφανίσει πολλά ελαττώµατα (η κυκλωµατική
πολυπλοκότητα µπορεί να χρησιµοποιηθεί ως ένδειξη).
• Έχει συγκεκριµένους περιορισµούς ή καθορισµένες απαιτήσεις απόδοσης.
ªÂϤÙË ÂÚ›ÙˆÛ˘ 5.1 (συνέχεια)
Για το λογισµικό της CHILDWARE, ένα κρίσιµο τµήµα είναι η Αποθήκη (εάν το
καλοσκεφτείτε, θα δείτε ότι ικανοποιεί όλα τα κριτήρια που αναφέρθηκαν πιο πάνω).
Ξεκινούµε λοιπόν την ανάπτυξη (και τις δοκιµές) από το τµήµα αυτό, χρησιµοποι-
ώντας έναν οδηγό για το συνολικό σύστηµα και στελέχη για τα τµήµατα Προµήθει-
ες, Ελλείψεις και Πωλήσεις (Σχήµα 5.5(α)). Στη συνέχεια, προχωρούµε προς τα
κάτω, αναπτύσσοντας, δοκιµάζοντας και ολοκληρώνοντας το τµήµα Πωλήσεις (είναι
το «πιο κρίσιµο» από τα τρία τµήµατα που καλεί η Αποθήκη), το οποίο µας ανα-
γκάζει να αναπτύξουµε στελέχη για τα τµήµατα καταγραφής των πωλήσεων των
υποκαταστηµάτων και των εξαγωγών (Σχήµα 5.5(β)).
1 1 3 5 . 2 ¢ √∫ π ª∂ ™ ™ À ° ∫ ƒ √∆ ∏™ ∏™
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 113
1 1 4 K E ºA § A I O 5 : ¶ƒ∞ ∫ ∆ π ∫ ∏ E º∞ ƒ ª√° ∏ ∆ ø¡ ¢ ƒ∞ ™ ∆ ∏ƒ π √∆ ∏∆ ø¡ E § ∂ ° à √À: ¢ √∫ π ª∂ ™ § √° π ™ ªπ ∫ √À
™¯‹Ì· 5.5
Σάντουιτς έλεγχος
του λογισµικού
της CHILDWARE
(α) (β)
Αποθήκη Αποθήκη
Πωλήσεις
Έστω ότι επιλέγετε τη σάντουιτς δοκιµή του λογισµικού του τµήµατος Λογιστή-
ριο. ∆οκιµάστε να τοποθετήσετε στον πίνακα που ακολουθεί τα τµήµατα του προ-
γράµµατος µε τη σωστή σειρά δοκιµής, σηµειώνοντας ποιους οδηγούς και ποια
στελέχη θα χρειαστείτε σε κάθε βήµα. Ποιο είναι κατά τη γνώµη σας το κρίσιµο
τµήµα από το οποίο πρέπει να ξεκινήσετε;
ΤΜΗΜΑ Ο∆ΗΓΟΙ ΣΤΕΛΕΧΗ
1.
2.
3.
4.
5.
6.
7.
8.
ÕÛÎËÛË ·˘ÙÔ·ÍÈÔÏfiÁËÛ˘ 5.4
Είναι σηµαντικό στο χρονοδιάγραµµα ανάπτυξης ενός συστήµατος λογισµικού να
συµπεριλαµβάνονται πολλές δραστηριότητες ελέγχου. Οι περισσότερες από αυτές
συνήθως περιλαµβάνουν δοκιµές συγκρότησης, αφού η αυξητική ανάπτυξη/ολο-
κλήρωση του λογισµικού αποτελεί πια την περισσότερο διαδεδοµένη µεθοδολο-
¢Ú·ÛÙËÚÈfiÙËÙ· 5.1
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 114
¶›Ó·Î·˜ 5.1
Σύνοψη των κυριότερων χαρακτηριστικών, πλεονεκτηµάτων και µειονεκτηµάτων
των δοκιµών συγκρότησης
1 1 5 5 . 2 ¢ √∫ π ª∂ ™ ™ À ° ∫ ƒ √∆ ∏™ ∏™
γία. Θα σας είναι, λοιπόν, αρκετά χρήσιµο να επαναλάβετε την ενότητα 5.2 και να
συγκεντρώσετε σε 1 πίνακα τα κυριότερα χαρακτηριστικά, τα πλεονεκτήµατα και
τα µειονεκτήµατα καθεµιάς από τις τρεις πρακτικές που περιγράφονται. Στη συνέ-
χεια, δοκιµάστε να τις συγκρίνετε µε βάση ένα σύνολο χαρακτηριστικών που θα
χρησιµοποιούσατε εσείς για την επιλογή κάποιας πρακτικής. Έπειτα ρίξτε µια µατιά
στους ακόλουθους Πίνακες 5.1 και 5.2, οι οποίοι περιέχονται στο Shooman[83].
ΠΡΑΚΤΙΚΗ ΧΑΡΑΚΤΗΡΙΣΤΙΚΑ ΠΛΕΟΝΕΚΤΗΜΑΤΑ ΜΕΙΟΝΕΚΤΗΜΑΤΑ
Από πάνω προς
τα κάτω
• Το κύριο πρόγραµµα δοκι-
µάζεται πρώτο.
• Τα επί µέρους τµήµατα
συγκροτούνται και δοκιµά-
ζονται ένα – ένα.
• Έµφαση δίνεται στη δοκιµή
διεπαφών.
• ∆ε χρειάζονται οδηγοί.
• Πολύ σύντοµα µπορεί να
παραχθεί και να δοκιµαστεί
ένα πρωτότυπο του
λογισµικού.
• Τα ελαττώµατα των διεπα-
φών ανακαλύπτονται νωρίς.
• Η τµηµατοποιηµένη ανάπτυ-
ξη ευνοεί την εκσφαλµάτωση.
• Απαιτούνται στελέχη.
• Τα ελαττώµατα των κρίσι-
µων τµηµάτων χαµηλού επι-
πέδου ανακαλύπτονται αργά.
• Είναι δύσκολο να συγκροτη-
θεί η οµάδα δοκιµής.
• Είναι σχεδόν αδύνατο να
εφαρµοστεί στην πράξη µια
«καθαρή» από πάνω προς τα
κάτω πρακτική.
Από κάτω
προς τα πάνω
Σάντουιτς Συνδυάζει τα σηµαντικότερα χαρακτηριστικά, πλεονεκτήµατα και µειονεκτήµατα των άλλων δύο πρακτικών
• Οι δοκιµές ξεκινούν νωρίς
µε στόχο να αποδείξουν τη
χρησιµότητα ορισµένων
τµηµάτων.
• Η συγκρότηση των επί
µέρους τµηµάτων µπορεί να
γίνει σε διαφορετικές οµάδες.
• Η έµφαση τίθεται στη λει-
τουργικότητα και την από-
δοση των τµηµάτων.
• ∆ε χρειάζονται στελέχη.
• Ευνοείται η συγκρότηση της
οµάδας δοκιµής.
• Τα ελαττώµατα των κρίσι-
µων τµηµάτων ανακαλύπτο-
νται νωρίς.
• Σε οποιαδήποτε χρονική
στιγµή µε την πρακτική
αυτή (σε σύγκριση µε την
από πάνω προς τα κάτω
πρακτική), θα έχουµε ανα-
πτύξει και ελέγξει µεγαλύτε-
ρο τµήµα του κώδικα.
• Απαιτούνται οδηγοί δοκιµής.
• Ένα λειτουργικό πρωτότυπο
του συστήµατος παράγεται
µόνο προς το τέλος της δια-
δικασίας, αφού έχουν δοκι-
µαστεί ανεξάρτητα πολλά
τµήµατά του.
• Τα ελαττώµατα των διεπα-
φών ανακαλύπτονται αργά.
• Πρόκειται για πρακτική που
βασίζεται πολύ στο ένστικτο
και την εµπειρία.
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 115
1 1 6 K E ºA § A I O 5 : ¶ƒ∞ ∫ ∆ π ∫ ∏ E º∞ ƒ ª√° ∏ ∆ ø¡ ¢ ƒ∞ ™ ∆ ∏ƒ π √∆ ∏∆ ø¡ E § ∂ ° à √À: ¢ √∫ π ª∂ ™ § √° π ™ ªπ ∫ √À
¶›Ó·Î·˜ 5.2
Συγκριτική παρουσίαση των δοκιµών συγκρότησης µε βάση ένα σύνολο χαρακτηρι-
στικών
ΧΑΡΑΚΤΗΡΙΣΤΙΚΟ ΑΠΟ
ΚΑΤΩ
ΠΡΟΣ ΤΑ
ΠΑΝΩ
ΑΠΟ
ΠΑΝΩ
ΠΡΟΣ ΤΑ
ΚΑΤΩ
ΣΑΝΤΟΥΙΤΣ BIG
BANG
Συγκρότηση Νωρίς Νωρίς Νωρίς Αργά
Παράδοση µιας πρώτης
λειτουργικής έκδοσης
Αργά Νωρίς Νωρίς Αργά
Ανάγκη οδηγών Nαι Όχι Εν µέρει Ναι
Ανάγκη στελεχών Όχι Ναι Εν µέρει Ναι
∆υνατότητα παράλλη-
λων εργασιών δοκιµής
Μέτρια Χαµηλή Μέτρια Υψηλή
∆υνατότητα δοκιµής
µονοπατιών
Εύκολη ∆ύσκολη Μέτρια Εύκολη
∆υνατότητα σχεδίασης
και ελέγχου των δοκιµών
Εύκολη ∆ύσκολη ∆ύσκολη Εύκολη
Σύγχυση οµάδας
δοκιµής
Χαµηλή Χαµηλή Χαµηλή Υψηλή
Κόστος ελέγχου Μέτριο Μέτριο Μέτριο Υψηλό
Χρόνος ελέγχου Μέτριος Μέτριος Μέτριος Μεγάλος
5.3 ¢ÔÎÈ̤˜ ÂÈ΢ÚÒÛ˘
Οι δοκιµές επικύρωσης (validation testing) στοχεύουν να δείξουν ότι το λογισµικό
λειτουργεί όπως περιγράφεται στο κείµενο «Προδιαγραφές των απαιτήσεων του λογι-
σµικού», δηλαδή ότι το λογισµικό ικανοποιεί τις δηλωµένες απαιτήσεις των χρηστών.
Οι δοκιµές επικύρωσης εφαρµόζονται µετά τις δοκιµές συγκρότησης, όταν το λογι-
σµικό έχει «συναρµολογηθεί» σε ένα σύστηµα και τα ελαττώµατα των διεπαφών
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 116
έχουν διορθωθεί. Οι βασικές κατευθύνσεις για τη σχεδίαση των περιπτώσεων ελέγ-
χου (τα λεγόµενα «κριτήρια επικύρωσης») έχουν ήδη περιγραφεί από τη φάση της
ανάλυσης απαιτήσεων.
Με βάση αυτά, εφαρµόζεται ένα σύνολο ελέγχων αδιαφανούς κουτιού, µε στόχο να
δειχθεί ότι ικανοποιούνται όλες οι λειτουργικές απαιτήσεις, επιτυγχάνονται όλες οι
απαιτήσεις επίδοσης, αντιµετωπίζονται όλες οι υπόλοιπες απαιτήσεις και υπάρχει
σωστή και επαρκής τεκµηρίωση.
Μετά την εφαρµογή κάθε περίπτωσης ελέγχου, υπάρχουν δύο ενδεχόµενα:
• H υπό δοκιµή λειτουργία ικανοποιεί τις απαιτήσεις και γίνεται αποδεκτή ή
• ανακαλύπτεται απόκλιση της υπό δοκιµής λειτουργίας από τις προδιαγραφές,
οπότε συµπληρώνεται ένας κατάλογος ελαττωµάτων.
1 1 7 5 . 3 ¢ √∫ π ª∂ ™ ∂ ¶π ∫ À ƒ ø™ ∏™
Η διόρθωση ελαττωµάτων που ανακαλύπτονται σε αυτό το στάδιο είναι αδύνατο
να γίνει χωρίς να «κινδυνέψει» το χρονοδιάγραµµα παράδοσης του λογισµικού.
Συνήθως απαιτούνται διαπραγµατεύσεις µε τους χρήστες για να συµφωνηθεί µια
πολιτική αντιµετώπισης τέτοιου είδους ελαττωµάτων.
5.3.1 ¢ÔÎÈÌ‹ ¿ÏÊ· Î·È ‚‹Ù·
Οταν ένα σύστηµα λογισµικού αναπτύσσεται για τις ανάγκες κάποιου πελάτη, είναι
σχεδόν αδύνατο για την οµάδα ανάπτυξης να µπορέσει να προβλέψει πώς ακριβώς
αυτός θα το χρησιµοποιήσει. Για το λόγο αυτό, συνήθως σχεδιάζεται ένα σύνολο
από δοκιµές αποδοχής (acceptance tests) µε τις οποίες ο πελάτης θα µπορέσει να
επικυρώσει όλες τις προδιαγραφές του λογισµικού.
Οι δοκιµές αποδοχής εφαρµόζονται από τον πελάτη και όχι από την οµάδα ανάπτυ-
ξης ή δοκιµής και µπορεί να περιλαµβάνουν από µια δοκιµαστική χρήση του λογι-
σµικού, µέχρι συστηµατικές δοκιµές του λογισµικού που εκτείνονται σε περίοδο
εβδοµάδων ή µηνών.
Όµως, εάν οι τελικοί χρήστες του λογισµικού είναι πολλοί, είναι πρακτικά ανεφάρ-
µοστο να περιµένουµε από τον καθένα να το δοκιµάσει πριν την τελική αποδοχή.
Έτσι, χρησιµοποιούµε συνήθως τις λεγόµενες δοκιµές άλφα και βήτα για να ανακα-
λύψουµε ελαττώµατα που µόνο ο τελικός χρήστης µπορεί να βρει.
Η δοκιµή άλφα (alpha testing) γίνεται από ένα τελικό χρήστη στο (ελεγχόµενο) περι-
βάλλον ανάπτυξης του λογισµικού. Η οµάδα ανάπτυξης τον παρακολουθεί καθώς
χρησιµοποιεί το λογισµικό, σηµειώνοντας ελαττώµατα και δύσχρηστες λειτουργίες.
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 117
1 1 8 K E ºA § A I O 5 : ¶ƒ∞ ∫ ∆ π ∫ ∏ E º∞ ƒ ª√° ∏ ∆ ø¡ ¢ ƒ∞ ™ ∆ ∏ƒ π √∆ ∏∆ ø¡ E § ∂ ° à √À: ¢ √∫ π ª∂ ™ § √° π ™ ªπ ∫ √À
Η δοκιµή βήτα (beta testing) γίνεται από έναν ή πολλούς τελικούς χρήστες στο περι-
βάλλον λειτουργίας του λογισµικού. Πρόκειται λοιπόν για χρήση του λογισµικού σε
αληθινές συνθήκες, οι οποίες δεν είναι δυνατό να ελεγχθούν από την οµάδα ανά-
πτυξης (η οποία συνήθως δεν συµµετέχει σε δοκιµές βήτα). Ο πελάτης καταγράφει
όλα τα προβλήµατα που ανακύπτουν κατά τη χρήση και τα µεταφέρει σε τακτά χρο-
νικά διαστήµατα στην οµάδα ανάπτυξης. Με βάση αυτά, η οµάδα ανάπτυξης ετοι-
µάζει την επόµενη έκδοση του λογισµικού.
5.4 ¢ÔÎÈ̤˜ Û˘ÛÙ‹Ì·ÙÔ˜
Αφού το λογισµικό έχει τεθεί σε λειτουργία µέσα στο περιβάλλον του χρήστη, µπο-
ρεί να ανακύψουν ελαττώµατα που δεν είχαν εµφανιστεί κατά τη διάρκεια των δοκι-
µών. Τα ελαττώµατα αυτά συνήθως «οφείλονται» σε κακή εκτίµηση ή ελλιπή έλεγ-
χο της επίδρασης που έχει στο λογισµικό το πραγµατικό περιβάλλον λειτουργίας του.
Η σοβαρότητα τέτοιων ελαττωµάτων είναι µεγάλη, επειδή αφενός δηµιουργείται
άσχηµη εντύπωση στους χρήστες για τις δυνατότητες του λογισµικού και της οµάδας
ανάπτυξης και αφετέρου είναι µεγάλο το κόστος της αντιµετώπισης των σφαλµάτων.
Σε µια τέτοια κατάσταση ο καθένας που συµµετείχε στη διαδικασία ανάπτυξης µπορεί
να φτάσει να κατηγορεί τους άλλους ως υπαίτιους για την ύπαρξη των ελαττωµάτων!
Εάν δε τα ελαττώµατα είναι πολύ σοβαρά (δηλαδή κάποιες ή όλες οι λειτουργίες του
λογισµικού δεν είναι διαθέσιµες), στο κόστος πρέπει να συνυπολογιστεί και το «κόστος»
που δηµιουργείται στους χρήστες από τη µη διαθεσιµότητα του συστήµατος.
Ένας τρόπος για να αποφύγουµε τέτοιες δυσάρεστες καταστάσεις είναι να σχεδιά-
σουµε ένα σύνολο περιπτώσεων ελέγχου µε το οποίο θα µπορούµε να ελέγξουµε διε-
ξοδικά τους περιορισµούς που θα επιβάλει στο λογισµικό το πραγµατικό περιβάλ-
λον λειτουργίας του. Παρ’ όλο που οι δοκιµές συστήµατος θεωρούνται από πολλούς
ως τµήµα των δοκιµών επικύρωσης, έχουν από αυτές µία σηµαντική διαφορά: οι
δοκιµές συστήµατος στοχεύουν να δοκιµάσουν την επίδραση που έχουν στη συµπε-
ριφορά του λογισµικού διάφοροι εξωγενείς παράγοντες και καταστάσεις που συµ-
βαίνουν στο περιβάλλον χρήσης του. Για το λόγο αυτό προτιµούµε να παρουσιά-
σουµε τις δοκιµές συστήµατος (system testing) σε ξεχωριστή ενότητα, σηµειώνο-
ντας ότι καθεµία από αυτές δοκιµάζει και µία διαφορετική λειτουργική άποψη.
5.4.1 ¢ÔÎÈÌ‹ ÂÎÊ¿ÓÛÂˆÓ ÂÎÙ¤ÏÂÛ˘
Εφαρµόζεται κυρίως σε αντικειµενοστραφή συστήµατα ή σε συστήµατα πραγµατι-
κού χρόνου και χρησιµοποιείται από δραστηριότητες ελέγχου που δοκιµάζουν την
επίδραση που έχουν στο λογισµικό διάφορα εξωτερικά γεγονότα. Ενδιαφέρον παρου-
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 118
σιάζουν µόνο τα γεγονότα που ενεργοποιούν µία ή περισσότερες λειτουργίες (µε τη
µορφή µιας ακολουθίας λειτουργιών) του συστήµατος.
Η επεξεργασία ενός τέτοιου γεγονότος «εξυφαίνει το δρόµο της» µέσα από τις διερ-
γασίες ή τα αντικείµενα του συστήµατος. Σε κάθε βήµα εκτελείται και ένα τµήµα
της. Το συνολικό µονοπάτι εκτέλεσης µπορεί να ιχνηλατηθεί από τα µηνύµατα που
αντάλλαξαν τα αντικείµενα ή από τις κλήσεις µεταξύ διεργασιών. Έτσι, για να είναι
εφαρµόσιµη η δοκιµή αυτή, πρέπει τα επί µέρους αντικείµενα ή διεργασίες να έχουν
ελεγχθεί και συγκροτηθεί σε υποσυστήµατα.
Η εξαντλητική δοκιµή εκφάνσεων εκτέλεσης (thread testing) θα έπρεπε να περι-
λαµβάνει την επισήµανση και δοκιµαστική εκτέλεση κάθε πιθανής ακολουθίας βηµά-
των επεξεργασίας ενός γεγονότος (δηλαδή κάθε έκφανσης εκτέλεσης). Βέβαια, κάτι
τέτοιο είναι πρακτικά αδύνατο, καθώς το πλήθος των πιθανών εκφάνσεων µπορεί να
είναι πολύ µεγάλο.
Το λογισµικό, λοιπόν, αναλύεται, µε στόχο τον προσδιορισµό κατά το δυνατό περισ-
σότερων εκφάνσεων. Από αυτές ελέγχονται οι συχνότερα χρησιµοποιούµενες. Οι
δοκιµές περιλαµβάνουν:
• τη δοκιµή κάθε έκφανσης µε ένα µόνο γεγονός,
• τη δοκιµή κάθε έκφανσης µε πολλά γεγονότα του ίδιου τύπου ή της ίδιας κλάσης,
• τη δοκιµή του συστήµατος µε πολλά γεγονότα διαφορετικών κλάσεων. Κάθε
τέτοιο γεγονός θα ενεργοποιήσει διαφορετική έκφανση εκτέλεσης, οπότε, στην
περίπτωση αυτή, µπορεί να ελέγχονται ταυτόχρονα πολλές εκφάνσεις (µία έκφαν-
ση µπορεί να προκαλείται από συνδυασµό διαφορετικών γεγονότων).
5.4.2 ¢ÔÎÈÌ‹ ·ÓÙÔ¯‹˜
Η δοκιµή αντοχής (stress testing) εφαρµόζεται σε συστήµατα λογισµικού που έχουν
σχεδιαστεί ώστε να αντέχουν µέχρι ένα καθορισµένο «φορτίο» χρήσης (π.χ. ένα τρα-
πεζικό σύστηµα που σχεδιάστηκε να «σηκώνει» µέχρι 100 συναλλαγές το δευτερό-
λεπτο). Η πρακτική αυτή περιλαµβάνει το σχεδιασµό ενός συνόλου περιπτώσεων
ελέγχου όπου το φορτίο του λογισµικού αυξάνει σταδιακά. Οι δοκιµές αντοχής στο-
χεύουν να δείξουν ότι το λογισµικό µπορεί να επεξεργαστεί το µέγιστο καθορισµέ-
νο φορτίο, αλλά µπορεί ακόµα να χρησιµοποιηθούν για άλλους σκοπούς:
• Nα δοκιµάσουν τη συµπεριφορά του συστήµατος κατά τη διάρκεια µιας αστο-
χίας. Η επιθυµητή συµπεριφορά, όταν συµβεί ένας συνδυασµός γεγονότων που
υπερβαίνει τις προκαθορισµένες δυνατότητες του λογισµικού, είναι η απόδοση
1 1 9 5 . 4 ¢ √∫ π ª∂ ™ ™ À ™ ∆ ∏ª∞∆ √™
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 119
1 2 0 K E ºA § A I O 5 : ¶ƒ∞ ∫ ∆ π ∫ ∏ E º∞ ƒ ª√° ∏ ∆ ø¡ ¢ ƒ∞ ™ ∆ ∏ƒ π √∆ ∏∆ ø¡ E § ∂ ° à √À: ¢ √∫ π ª∂ ™ § √° π ™ ªπ ∫ √À
του συστήµατος να υποβαθµίζεται σταδιακά, χωρίς να προκαλείται φθορά ή απώ-
λεια δεδοµένων ή υπηρεσιών.
• Προκαλέσουν την εµφάνιση ελαττωµάτων τα οποία είχαν διαφύγει των υπόλοι-
πων δοκιµών. Βέβαια, είναι απίθανο τα ελαττώµατα αυτά να εµφανιστούν κατά
την «κανονική» χρήση του λογισµικού (δηλαδή τη χρήση των περισσότερο συνη-
θισµένων λειτουργιών λογισµικού από ένα µέσο χρήστη).
5.4.3 ¢ÔÎÈÌ‹ ·Ó¿Î·Ì„˘
Η δοκιµή ανάκαµψης (recovery testing) εφαρµόζεται σε συστήµατα τα οποία πρέ-
πει να είναι ανεκτικά σε σφάλµατα (fault – tolerant) ή πρέπει να αναλαµβάνουν ξανά
λειτουργία µέσα σε προκαθορισµένο χρονικό διάστηµα από την εµφάνιση του
λάθους. Η τεχνική αυτή οδηγεί το λογισµικό σε λειτουργική αστοχία χρησιµοποιώ-
ντας διάφορους τρόπους και έπειτα επαληθεύει ότι το λογισµικό ανακάµπτει κατά
τον προβλεπόµενο τρόπο.
5.4.4 ¢ÔÎÈÌ‹ ·ÛÊ·Ï›·˜
Εφαρµόζεται σε συστήµατα που µεταχειρίζονται σηµαντικά δεδοµένα και χρησιµοποι-
ούνται από πολλούς χρήστες. Σε τέτοια συστήµατα, είναι δυνατό να γίνει εκούσια ή
ακούσια κατάχρηση των δεδοµένων, η οποία µπορεί να οδηγήσει σε παράνοµες δρα-
στηριότητες. Για την προστασία του συστήµατος από τέτοιους κινδύνους υλοποιούνται
µηχανισµοί ελέγχου της προσπέλασης των χρηστών (π.χ. κωδικοί πρόσβασης), περιο-
ρισµού ή κατάτµησης των δικαιωµάτων των χρηστών στα δεδοµένα, πιστοποίησης της
ακεραιότητας των δεδοµένων και εξασφάλισης της διαθεσιµότητας του συστήµατος.
Οι δοκιµές ασφάλειας (security testing) στοχεύουν να δείξουν ότι οι µηχανισµοί
ασφάλειας πραγµατικά προστατεύουν το λογισµικό από κακή χρήση. Συνήθως ανα-
τίθεται σε µια οµάδα το έργο της παραβίασης µε οποιοδήποτε µέσο των µηχανισµών
ασφάλειας, ώστε η οµάδα να αποκτήσει πρόσβαση σε προστατευόµενα δεδοµένα.
Εάν της δοθούν αρκετός χρόνος και πόροι, η οµάδα αυτή θα καταφέρει στο τέλος να
παραβιάσει την ασφάλεια του λογισµικού. Το έργο του σχεδιαστή του συστήµατος
είναι να κάνει την παραβίαση αυτή περισσότερο «ακριβή» από την αξία των δεδο-
µένων που περιέχει το σύστηµα.
5.4.5 ¢ÔÎÈÌ‹ ·fi‰ÔÛ˘
Η δοκιµή απόδοσης (performance testing) εξετάζει εάν το λογισµικό ικανοποιεί τις
απαιτήσεις απόδοσης κατά την εκτέλεσή του µέσα σε ένα ολοκληρωµένο περιβάλ-
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 120
λον. Αν και η τεχνική θα έπρεπε να εφαρµόζεται σε όλα τα στάδια ανάπτυξης του
λογισµικού, µόνο αφού συγκροτηθούν όλα τα τµήµατά του είναι δυνατή η δοκιµή
της αληθινής απόδοσης του λογισµικού. Εφαρµόζοντας την τεχνική αυτή µπορεί να
ανακαλύψουµε καταστάσεις, οι οποίες µπορεί να οδηγήσουν σε µειωµένη απόδοση
και ίσως τελική αστοχία του λογισµικού.
1 2 1 5 . 4 ¢ √∫ π ª∂ ™ ™ À ™ ∆ ∏ª∞∆ √™
Με βάση όσα διαβάσατε στο κεφάλαιο αυτό, δοκιµάστε να συγκρίνετε τις τεχνι-
κές δοκιµής µονάδων και συγκρότησης µε τις τεχνικές επισκόπησης του σχεδίου
και του κώδικα του λογισµικού, ως προς την αποτελεσµατικότητα της κάθε τεχνι-
κής στη ανακάλυψη ελαττωµάτων. Στη συνέχεια, µπορείτε να συγκρίνετε την απά-
ντησή σας µε τον Πίνακα 5.3, ο οποίος αρχικά περιέχεται στο Shooman[83].
ΕΙ∆ΟΣ
ΕΛΑΤΤΩΜΑ-
ΤΟΣ
ΕΛΕΓΧΟΣ
ΤΜΗΜΑΤΩΝ
ΕΛΕΓΧΟΣ
ΣΥΓΚΡΟΤΗ-
ΣΗΣ
ΕΠΙΣΚΟΠΗΣΗ
ΚΩ∆ΙΚΑ
ΕΠΙΣΚΟΠΗΣΗ
ΣΧΕ∆ΙΟΥ
Λογικής Καλή Μέτρια Μέτρια Μικρή
Τεκµηρίωσης Μικρή Μέτρια Καλή Καλή
Υπερχείλισης Καλή Καλή Μέτρια Μικρή
Χρονισµού Μέτρια Καλή Μέτρια Μέτρια
Απόδοσης Μέτρια Καλή Μέτρια Μέτρια
Ανάκαµψης Μικρή Καλή Μέτρια Μέτρια
Προδιαγραφών Μικρή Μέτρια Μέτρια Καλή
Υλικού Μικρή Καλή Μικρή Μέτρια
¢Ú·ÛÙËÚÈfiÙËÙ· 5.2
¶›Ó·Î·˜ 5.3
Σύγκριση τεσσάρων τεχνικών ελέγχου ως προς την αποτελεσµατικότητα στην ανακάλυψη λαθών
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 121
1 2 2 K E ºA § A I O 5 : ¶ƒ∞ ∫ ∆ π ∫ ∏ E º∞ ƒ ª√° ∏ ∆ ø¡ ¢ ƒ∞ ™ ∆ ∏ƒ π √∆ ∏∆ ø¡ E § ∂ ° à √À: ¢ √∫ π ª∂ ™ § √° π ™ ªπ ∫ √À
∆οκιµάστε να αντιστοιχίσετε τις πρακτικές δοκιµών που δίνονται στην αριστερή
στήλη µε τις φάσεις της στρατηγικής ελέγχου όπου ανήκουν, οι οποίες δίνονται
στη δεξιά στήλη:
ΠΡΑΚΤΙΚΗ ΦΑΣΗ
Άλφα δοκιµή ∆οκιµές µονάδων
∆οκιµή µονοπατιών εκτέλεσης
∆οκιµή απόδοσης
∆οκιµή από κάτω προς τα πάνω
Βήτα δοκιµή
∆οκιµή ανάκαµψης
∆οκιµή οριακών συνθηκών ∆οκιµές συγκρότησης
∆οκιµή αντοχής
∆οκιµή από πάνω προς τα κάτω
∆οκιµή ασφάλειας
∆οκιµή διεπαφών
∆οκιµή εκφάνσεων εκτέλεσης
∆οκιµή σάντουιτς
∆οκιµή δοµών δεδοµένων ∆οκιµές επικύρωσης/συστήµατος
ÕÛÎËÛË ·˘ÙÔ·ÍÈÔÏfiÁËÛ˘ 5.5
Εχοντας στο µυαλό σας το σύστηµα της επιχείρησης CHILDWARE, σκεφτείτε ένα
κύκλο ανάπτυξης του λογισµικού που ακολουθεί το µοντέλο V. Προσπαθήστε να
σχεδιάσετε µια στρατηγική ελέγχου και καταγράψτε κάποιες από τις δραστηριό-
τητες ελέγχου που θα εφαρµόζατε σε κάθε φάση. Για να απαντήσετε θα χρειαστείτε
τις γνώσεις που περιέχονται στα Kεφάλαια 4 και 5.
¢Ú·ÛÙËÚÈfiÙËÙ· 5.3
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 122
™‡ÓÔ„Ë
Στο κεφάλαιο αυτό πήρατε µια σφαιρική εικόνα για τις διάφορες πρακτικές δοκιµών
που χρησιµοποιούνται κατά την εφαρµογή των δραστηριοτήτων ελέγχου που είχαν
αναλυτικά περιγραφεί στο προηγούµενο κεφάλαιο. Τώρα πρέπει να είναι πια ξεκά-
θαρο ότι οι δραστηριότητες ελέγχου είναι στενά συνδεµένες µε τις δραστηριότητες
ανάπτυξης και αποτελούν αναπόσπαστο τµήµα ενός οποιουδήποτε µοντέλου ανά-
πτυξης λογισµικού.
Οι διάφορες πρακτικές δοκιµών, µπορούν να οµαδοποιηθούν σε τρεις φάσεις δοκι-
µών, καθεµία από τις οποίες ικανοποιεί έναν από τους στόχους της στρατηγικής δοκι-
µών. Οι στόχοι κλιµακώνονται, καθώς η ανάπτυξη του λογισµικού προχωρά από τα
επί µέρους τµήµατα προς το συνολικό σύστηµα, ως εξής:
• ∆οκιµές µονάδων: Eφαρµόζονται από την οµάδα ανάπτυξης σε κάθε τµήµα του
συστήµατος και περιλαµβάνουν τη δοκιµή βασικών µονοπατιών εκτέλεσης, τη δοκι-
µή δοµών δεδοµένων, τη δοκιµή οριακών συνθηκών, τη δοκιµή διεπαφών, αλλά
και τη δοκιµή του κώδικα διαχείρισης σφαλµάτων.
• ∆οκιµές συγκρότησης: Στοχεύουν στην παραγωγή ενός ορθού συστήµατος ή υπο-
συστήµατος από τµήµατα που έχουν ήδη δοκιµαστεί. Μπορεί να ξεκινήσουν από
το κυρίως τµήµα του λογισµικού προς τα υποσυστήµατα (δηλαδή από πάνω προς
τα κάτω) ή από τα χαµηλού επιπέδου τµήµατα προς τα υποσυστήµατα και το
σύστηµα (δηλαδή από κάτω προς τα πάνω). Στην πρώτη περίπτωση χρειάζεται να
αναπτύξουµε στελέχη που θα εξοµοιώνουν τη συµπεριφορά των επί µέρους τµη-
µάτων (µέχρι βέβαια αυτά να υλοποιηθούν και να ενσωµατωθούν στο σύστηµα),
ενώ στη δεύτερη απαιτείται η ανάπτυξη οδηγών, οι οποίοι θα εξοµοιώνουν τη
συµπεριφορά των τµηµάτων υψηλού επιπέδου. Εναλλακτικά, µπορούµε να ακο-
λουθήσουµε και «σάντουιτς» δοκιµή, ξεκινώντας από τα τµήµατα ενδιάµεσων επι-
πέδων που θεωρούµε ότι είναι κρίσιµα.
• ∆οκιµές επικύρωσης και συστήµατος: Eφαρµόζονται στο πλήρες σύστηµα και στο-
χεύουν να δοκιµάσουν τόσο το βαθµό στον οποίο το λογισµικό ικανοποιεί τις αρχι-
κές προδιαγραφές, όσο και τη συµπεριφορά του σε συνθήκες πραγµατικής λει-
τουργίας.
Επαναλαµβάνουµε εδώ ότι επιτυχηµένη στρατηγική/δραστηριότητα ελέγχου είναι αυτή
που αποκαλύπτει ελαττώµατα στο λογισµικό. Τι θα κάνουµε όµως όταν, εφαρµόζο-
ντας µια επιτυχηµένη δραστηριότητα ελέγχου, εµφανιστεί ένας αριθµός από σφάλ-
µατα; Η απάντηση είναι το θέµα του επόµενου κεφαλαίου: εκσφαλµάτωση, δηλαδή
αποµάκρυνση των σφαλµάτων.
1 2 3 ™ Y NOæH
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 123
1 2 4 K E ºA § A I O 5 : ¶ƒ∞ ∫ ∆ π ∫ ∏ E º∞ ƒ ª√° ∏ ∆ ø¡ ¢ ƒ∞ ™ ∆ ∏ƒ π √∆ ∏∆ ø¡ E § ∂ ° à √À: ¢ √∫ π ª∂ ™ § √° π ™ ªπ ∫ √À
µÈ‚ÏÈÔÁÚ·Ê›·
[1] R. Pressman (1994), Software Engineering: a practitioner’s approach. McGraw
– Hill, England.
[2] M.L. Shooman (1983), Software Engineering. McGraw – Hill, Tokyo.
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 124
∂ÎÛÊ·ÏÌ¿ÙˆÛË
™ÎÔfi˜
Το κεφάλαιο παρουσιάζει αναλυτικά τις δραστηριότητες εκσφαλµάτωσης, οι οποίες
ακολουθούν µια επιτυχηµένη φάση ελέγχου, µε σκοπό τη διόρθωση των σφαλµάτων
που αυτή αποκάλυψε.
¶ÚÔÛ‰ÔÎÒÌÂÓ· ·ÔÙÂϤÛÌ·Ù·
Όταν θα έχετε µελετήσει το κεφάλαιο αυτό, θα µπορείτε να:
• ∆ιακρίνετε ανάµεσα στη διαδικασία ελέγχου και τη διαδικασία εκσφαλµάτωσης
• Αναφέρετε τα τέσσερα τουλάχιστον στάδια της διαδικασίας εκσφαλµάτωσης
• Περιγράψετε τρεις γενικές κατηγορίες µεθοδολογιών εκσφαλµάτωσης
• Περιγράψετε πέντε τεχνικές που συγκροτούν την εκσφαλµάτωση µε «κατά µέτωπο
επίθεση»
• Αναφέρετε και εφαρµόσετε τα τέσσερα βήµατα των τεχνικών επαγωγής και απαγωγής
• Συνοψίσετε τα καθήκοντα του εκκαθαριστή σφαλµάτων λογισµικού
ŒÓÓÔȘ ÎÏÂȉȿ
6
∫ ∂ º ∞ § ∞ π √
• εκσφαλµάτωση,
• σφάλµα,
• ελάττωµα,
• ελεγχος παλινδρόµησης,
• εκκαθαριστής σφαλµάτων λογισµικού,
• τεχνικές κατά µέτωπο επίθεσης,
• οπισθοδρόµηση,
• επαγωγή,
• απαγωγή.
∂ÈÛ·ÁˆÁÈΤ˜ ·Ú·ÙËÚ‹ÛÂȘ
Η εκσφαλµάτωση (debugging) ακολουθεί µετά τον επιτυχηµένο έλεγχο (δηλαδή, τον
έλεγχο που ανακάλυψε κάποιο σφάλµα) και στοχεύει στην εξάλειψη του σφάλµατος.
Πρόκειται για µια διαδικασία που βασίζεται περισσότερο στην έµπνευση και την εµπει-
ρία, παρά στην εφαρµογή κάποιας συστηµατικής µεθοδολογίας.
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 125
1 2 6 K E ºA § A I O 6 : ∂ ∫ ™ º∞ § ª∞∆ ø™ ∏
Αυτό οφείλεται περισσότερο στη φύση της εκσφαλµάτωσης: τα µέλη της οµάδας δοκι-
µής, η οποία ελέγχει το λογισµικό, συνήθως αντιµετωπίζουν κάποιο σφάλµα (error)
στη λειτουργία του, το οποίο οφείλεται σε κάποιο εσωτερικό ελάττωµα (fault). Συνε-
πώς, η οµάδα δοκιµής δεν έρχεται σε άµεση επαφή µε το ίδιο το ελάττωµα, αλλά µε τα
αποτελέσµατα που αυτό προκαλεί. Πολλές φορές, όµως, το ελάττωµα και το σφάλµα
δεν έχουν κάποια ορατή συσχέτιση. Η σύνδεση του αιτίου µε τα αποτελέσµατα, η οποία
αποτελεί θεµελιώδη δραστηριότητα της εκσφαλµάτωσης, είναι µια νοητική διαδικασία
που δεν έχει ακόµη κατανοηθεί επαρκώς.
Στη συνέχεια του κεφαλαίου, θα γίνει αρχικά (ενότητα 6.1) µια ανάλυση της διαδικα-
σίας της εκσφαλµάτωσης πριν προχωρήσουµε στη µελέτη των µεθοδολογιών εκσφαλ-
µάτωσης (ενότητα 6.2). Βέβαια, σύµφωνα µε όσα έχουµε αναφέρει, πρόκειται περισ-
σότερο για τεχνικές εντοπισµού των ελαττωµάτων, παρά για συγκροτηµένες µεθοδο-
λογίες. Παρουσιάζονται τρεις κατηγορίες τεχνικών (σε κλίµακα αυξανόµενης πολυ-
πλοκότητας):
• Τεχνικές κατά µέτωπο επίθεσης, η οποία δεν απαιτεί λεπτοµερή σχεδιασµό και έχει
ως αποτέλεσµα τη συγκέντρωση ενός µεγάλου όγκου δεδοµένων για τη λειτουργία
του προγράµµατος.
• Η οπισθοδρόµηση, η οποία ξεκινά από το σφάλµα και προσπαθεί, εκτελώντας «ανά-
ποδα» το πρόγραµµα, να εντοπίσει την αιτία του.
• Τεχνικές εντοπισµού του αιτίου του σφάλµατος, οι οποίες χρησιµοποιούν τα δεδο-
µένα που συλλέγονται από τεχνικές κατά µέτωπο επίθεσης για να διαµορφώσουν µια
ή περισσότερες υποθέσεις σχετικά µε τις πιθανές αιτίες του σφάλµατος, τις οποίες
στη συνέχεια επιχειρούν να αποδείξουν ή να αντικρούσουν.
Η τελευταία ενότητα (ενότητα 6.3) παρουσιάζει τη δραστηριότητα που ακολουθεί µια
επιτυχηµένη φάση εκσφαλµάτωσης, δηλαδή τη διόρθωση του ελαττώµατος.
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 126
6.1 ∏ ‰È·‰Èηۛ· Ù˘ ÂÎÛÊ·ÏÌ¿ÙˆÛ˘
Η διαδικασία της εκσφαλµάτωσης είναι µέρος ενός γενικότερου κύκλου δραστη-
ριοτήτων, ο οποίος συνήθως ξεκινά µε την εφαρµογή µιας περίπτωσης ελέγχου και
την ανάλυση των αποτελεσµάτων της (Σχήµα 6.1). Εάν η οµάδα δοκιµής ανακαλύ-
ψει κάποια απόκλιση ανάµεσα στα πραγµατικά και τα αναµενόµενα αποτελέσµατα,
υποψιάζεται ότι το λογισµικό περιέχει κάποιο κρυµµένο ελάττωµα.
Εδώ τελειώνει και η ανάµιξη της οµάδας δοκιµής, καθώς η εκσφαλµάτωση ανατί-
θεται συνήθως σε εκπαιδευµένα άτοµα, τα οποία ειδικεύονται ακριβώς στην απο-
κάλυψη και διόρθωση ελαττωµάτων. Οι προσπάθειες ενός «εκκαθαριστή σφαλµά-
των λογισµικού» (debugger) επικεντρώνονται αρχικά στην αποκάλυψη του ελατ-
τώµατος, το οποίο προκαλεί το σφάλµα λειτουργίας.
Οι σηµερινές µεθοδολογίες θεωρούν την εκσφαλµάτωση ως µια διαδικασία επίλυσης
προβληµάτων: O εκκαθαριστής πρέπει να κάνει υποθέσεις για το αίτιο της παρατη-
ρήσιµης συµπεριφοράς του λογισµικού, τις οποίες ελέγχει στη συνέχεια, ελπίζοντας
να ανακαλύψει το ελάττωµα. Ο ελέγχος αυτός µπορεί να αποκαλύψει ή όχι το ελάτ-
τωµα. Στη δεύτερη περίπτωση, ο κύκλος των δραστηριοτήτων αυτών επαναλαµβάνε-
ται έως ότου ο εκκαθαριστής αποκαλύψει το ελάττωµα. Τότε, προχωρά σε διόρθωση
του ελαττώµατος και ξεκινά ένα νέο κύκλο δοκιµών του λογισµικού, µε στόχο να επι-
βεβαιώσει ότι επιλύθηκε το πρόβληµα χωρίς να δηµιουργηθούν νέα σφάλµατα.
1 2 7 6 . 1 ∏ ¢ π ∞ ¢ π ∫ ∞ ™ π ∞ ∆ ∏™ ∂ ∫ ™ º∞ § ª∞∆ ø™ ∏™
™¯‹Ì· 6.1
Η διαδικασία της
εκσφαλµάτωσης
ως τµήµα ενός
κύκλου δραστη-
ριοτήτων
Aποτελέσµατα
Eφαρµογή 
Περιπτώσεων Eλέγχου
Eκσφαλµάτωση
Περιπτώσεις 
ελέγχου
Έλεγχοι 
Παλινδρόµησης
∆ιόρθωση
Eξακριβωµένες 
Aιτίες
Πιθανές 
Aιτίες
Πρόσθετοι 
Έλεγχοι
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 127
1 2 8 K E ºA § A I O 6 : ∂ ∫ ™ º∞ § ª∞∆ ø™ ∏
Τι είναι αυτό που δυσκολεύει τόσο πολύ το έργο του εκκαθαριστή σφαλµάτων λογι-
σµικού; Περισσότερο από οτιδήποτε άλλο, κάποια χαρακτηριστικά των ελαττωµά-
των που εµφανίζει το λογισµικό, όπως (Pressman[94]) τα ακόλουθα:
• Το σφάλµα και η αιτία του µπορεί να βρίσκονται σε διαφορετικά τµήµατα του
προγράµµατος. Κάτι τέτοιο είναι συνηθισµένο σε λογισµικό που εµφανίζει υψηλό
βαθµό σύζευξης.
• Όταν διορθωθεί κάποιο άλλο (µη σχετιζόµενο) ελάττωµα, το σφάλµα µπορεί προ-
σωρινά να εξαφανιστεί.
• Το σφάλµα µπορεί να οφείλεται σε ανθρώπινο λάθος, σε λάθος στρογγυλοποίη-
σης ή και σε προβλήµατα χρονισµού.
• Η επανάληψη (και η µελέτη) των συνθηκών που δηµιούργησαν το σφάλµα µπο-
ρεί να είναι αδύνατη.
• Το σφάλµα µπορεί να είναι διαλειπτόµενο, δηλαδή, να µην εµφανίζεται πάντα.
• Το σφάλµα µπορεί να οφείλεται σε ένα σύνολο ελαττωµάτων, τα οποία είναι
κατανεµηµένα σε έναν αριθµό διεργασιών που εκτελούνται σε διαφορετικούς
επεξεργαστές.
Πολλοί νοµίζουν ότι ο έλεγχος και η εκσφαλµάτωση του λογισµικού είναι ένα και
το αυτό. Όµως, αν και συνδέονται στενά, αποτελούν διακριτές διαδικασίες. ∆οκι-
µάστε να τεκµηριώσετε τον ισχυρισµό αυτό σε 5 – 10 γραµµές. Έπειτα, ρίξτε µια
µατιά στο πλαίσιο που ακολουθεί.
Ο έλεγχος και η εκσφαλµάτωση του λογισµικού συνδέονται µεν στενά, αποτελούν
όµως διακριτές διαδικασίες. Η διαδικασία ελέγχου στοχεύει στην αποκάλυψη των
σφαλµάτων. Η διαδικασία εκσφαλµάτωσης ασχολείται µε τον εντοπισµό και τη
διόρθωση των ελαττωµάτων που προκαλούν τα σφάλµατα. Η εκσφαλµάτωση στη-
ρίζεται στον έλεγχο, καθώς χρησιµοποιεί τα αποτελέσµατα του ελέγχου ως ένδει-
ξη της ύπαρξης ελαττωµάτων στο λογισµικό.
Συνοψίζοντας, η εκσφαλµάτωση δεν είναι έλεγχος, αλλά πάντα λαµβάνει χώρα ως
συνέπεια ενός επιτυχηµένου ελέγχου.
¢Ú·ÛÙËÚÈfiÙËÙ· 6.1
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 128
6.2 MÂıÔ‰ÔÏÔÁ›Â˜ ÂÎÛÊ·ÏÌ¿ÙˆÛ˘
∆υστυχώς, η συγκρότηση ενός συνόλου οδηγιών εκσφαλµάτωσης έχει έως τώρα
αποδειχθεί αδύνατη. Στην πραγµατικότητα, οι µετρήσεις δείχνουν ότι η ικανότητα
στην εκσφαλµάτωση είναι έµφυτη και δύσκολα διδάσκεται. Αν και δεν έχουν κατα-
νοηθεί οι εµπλεκόµενες διανοητικές διαδικασίες, φαίνεται ότι ο ικανός εκκαθαρι-
στής αναζητά επαναλαµβανόµενες βασικές δοµές στα αποτελέσµατα του ελέγχου
που έδειξαν το σφάλµα και χρησιµοποιεί τις γνώσεις που έχει για το σφάλµα, τη
βασική δοµή και τον προγραµµατισµό για να εντοπίσει το ελάττωµα.
Η εµπειρία και η γνώση των διαδικασιών εκσφαλµάτωσης είναι επίσης σηµαντικές:
ο εκκαθαριστής γνωρίζει τα σφάλµατα που προκαλούν τα περισσότερο συνηθισµέ-
να ελαττώµατα και προσπαθεί να τα ταιριάξει µε τις βασικές δοµές που εµφανίζο-
νται στα αποτελέσµατα του ελέγχου.
Βέβαια, έχει προταθεί ένα σύνολο µεθοδολογιών (προσεγγίσεων, θα λέγαµε) για την
εφαρµογή της εκσφαλµάτωσης. Τα στάδια που περιλαµβάνουν αυτές οι µεθοδολο-
γίες φαίνονται στο Σχήµα 6.2 (Sommerville[96]). Ανεξάρτητα από τη µεθοδολογία
που θα υιοθετηθεί, η επιτυχία της εκσφαλµάτωσης βασίζεται σε ένα συνδυασµό
συστηµατικής ανάλυσης και αξιολόγησης, έµπνευσης και τύχης.
1 2 9 6 . 2 M∂ £√¢ √§ √° π ∂ ™ ∂ ∫ ™ º∞ § ª∞∆ ø™ ∏™
™¯‹Ì· 6.2
Τα στάδια της
εκσφαλµάτωσης
Eντοπισµός 
Eλαττώµατος
∆ιόρθωση 
Eλαττώµατος
Σχεδίαση 
∆ιόρθωσης
Eπανέλεγχος
Τρεις γενικές κατηγορίες µεθοδολογιών εκσφαλµάτωσης έχουν έως τώρα προταθεί:
• Κατά µέτωπο επίθεση
• Οπισθοδρόµηση
• Εξάλειψη του αιτίου
Θα µελετήσουµε τις µεθοδολογίες αυτές ως προς το στάδιο του εντοπισµού του ελατ-
τώµατος, η επιτυχηµένη εκτέλεση του οποίου καθορίζει σε µεγάλο βαθµό και το τελι-
κό αποτέλεσµα της µεθοδολογίας.
6.2.1 ∫·Ù¿ ̤وÔ Â›ıÂÛË
Πρόκειται για την πιο διαδεδοµένη, αλλά και τη λιγότερο αποτελεσµατική µεθοδο-
λογία εκσφαλµάτωσης. Στην πραγµατικότητα δεν αποτελεί µεθοδολογία, αφού δεν
περιλαµβάνει κάποια συγκροτηµένη ακολουθία βηµάτων ή οδηγιών, αλλά ένα σύνο-
λο ευριστικών τεχνικών, τις οποίες εφαρµόζει ο εκκαθαριστής «ευχόµενος» ότι
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 129
1 3 0 K E ºA § A I O 6 : ∂ ∫ ™ º∞ § ª∞∆ ø™ ∏
κάποια από αυτές θα αποδειχθεί αποτελεσµατική.
Για το λόγο αυτό, οι έµπειροι εκκαθαριστές σφαλµάτων λογισµικού προτιµούν να
εφαρµόζουν τις τεχνικές της κατά µέτωπο επίθεσης (brute force) όταν αποτύχουν
όλες οι άλλες µεθοδολογίες, καθώς αυτές οδηγούν στη συλλογή ενός τεράστιου
όγκου δεδοµένων, τα οποία πρέπει να µελετηθούν διεξοδικά. Τέτοιες τεχνικές είναι
οι ακόλουθες:
• H εκτύπωση διαγνωστικών µηνυµάτων: H τεχνική αυτή περιλαµβάνει την εισα-
γωγή στον κώδικα ειδικών εντολών, οι οποίες εκτυπώνουν τιµές µεταβλητών ή
δοµών δεδοµένων σε συγκεκριµένα σηµεία της εκτέλεσης του προγράµµατος.
Πρόκειται για την περισσότερο διαδεδοµένη τεχνική, την οποία θα µελετήσουµε
αναλυτικότερα στη συνέχεια.
• H εκτύπωση αντιγράφων των περιεχοµένων της µνήµης σε συγκεκριµένη στιγµή:
Η εφαρµογή της τεχνικής αυτής οδηγεί στην εκτύπωση µιας λεπτοµερούς περι-
γραφής της κατάστασης του προγράµµατος σε µια δεδοµένη στιγµή της εκτέλε-
σης. Η περιγραφή γίνεται σε επίπεδο µηχανής, µπορεί να είναι δοµηµένη και περι-
λαµβάνει όλες τις µεταβλητές και τις τιµές τους, καθώς και τα περιεχόµενα της
µνήµης που χρησιµοποιεί το πρόγραµµα και των καταχωρητών του υπολογιστή.
• H επιλεκτική ιχνηλάτηση µεταβλητών: Ο εκκαθαριστής µπορεί να επιλέξει κάποι-
ες από τις µεταβλητές ή τις δοµές δεδοµένων του προγράµµατος και να ζητήσει
τη λεπτοµερή καταγραφή των διαφόρων καταστάσεων στις οποίες αυτές βρί-
σκονται κατά την εκτέλεση του προγράµµατος (tracing). Κάποιοι διερµηνευτές
παρέχουν ακόµη και τη δυνατότητα καταγραφής ενός πλήρους ιστορικού της
εκτέλεσης ενός προγράµµατος.
• H χρήση σηµείων διακοπής: Πρόκειται για ειδικές εντολές (breakpoints), οι οποί-
ες προκαλούν διακοπή της εκτέλεσης του προγράµµατος, όταν ο έλεγχος ροής
συναντήσει µια από αυτές. Ο εκκαθαριστής µπορεί τότε να εξετάσει τις τιµές των
µεταβλητών και την κατάσταση του προγράµµατος, να τροποποιήσει κάποιες από
τις τιµές αυτές, να εισάγει νέες εντολές διακοπής, να συνεχίσει την εκτέλεση του
προγράµµατος ή να ξεκινήσει µια νέα δοκιµαστική εκτέλεση.
• H χρήση σηµείων διακοπής υπό συνθήκη: Στα σηµεία αυτά ο εκκαθαριστής εισά-
γει ειδικές εντολές, οι οποίες περιγράφουν έναν ισχυρισµό (assertion), ως λογι-
κή συνθήκη επί των τιµών κάποιων µεταβλητών. Η ικανοποίηση της συνθήκης
προκαλεί καταγραφή της κατάστασης του προγράµµατος, διακοπή της εκτέλε-
σής του και µεταφορά του ελέγχου στον εκκαθαριστή.
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 130
Παρόλο που η επεξεργασία των δεδοµένων που συλλέγονται µε τις τεχνικές κατά
µέτωπο επίθεσης µπορεί τελικά να αποκαλύψει το ελάττωµα, τις περισσότερες φορές,
η τεχνική αυτή από µόνη της δεν είναι αρκετή. Η επιτυχηµένη εκσφαλµάτωση απαι-
τεί πρώτα πολλή σκέψη και προσεκτική σχεδίαση!
1 3 1 6 . 2 M∂ £√¢ √§ √° π ∂ ™ ∂ ∫ ™ º∞ § ª∞∆ ø™ ∏™
Πριν προχωρήσετε, σκεφτείτε και καταγράψτε τις τεχνικές εκσφαλµάτωσης, από
αυτές που αναφέρθηκαν πιο πάνω, που υποστηρίζει το περιβάλλον προγραµµατι-
σµού που χρησιµοποιείτε. Ποιες από αυτές χρησιµοποιείτε εσείς συχνότερα και
γιατί;
¢Ú·ÛÙËÚÈfiÙËÙ· 6.2
Η εφαρµογή της τεχνικής αυτής, αν και έχει πολλές πιθανότητες να οδηγήσει στον
εντοπισµό του ελαττώµατος, παρουσιάζει σηµαντικά µειονεκτήµατα. Προσπαθή-
στε να καταγράψετε τουλάχιστον τρία, πριν µελετήσετε το πλαίσιο που ακολουθεί.
¢Ú·ÛÙËÚÈfiÙËÙ· 6.3
Εκτύπωση διαγνωστικών µηνυµάτων
Η εισαγωγή στον κώδικα των εντολών εκτύπωσης διαγνωστικών µηνυµάτων µπο-
ρεί να γίνει:
• αφού εµφανιστεί κάποιο σφάλµα οπότε οι εντολές περιορίζονται στο τµήµα του
κώδικα που σχετίζεται µε το σφάλµα και στοχεύουν στον εντοπισµό και διόρθω-
σή του, ή
• κατά την αρχική κωδικοποίηση του προγράµµατος, οπότε οι εντολές εκτείνονται
σε ολόκληρο το πρόγραµµα και στοχεύουν στην πρόληψη των σφαλµάτων.
Ο εντοπισµός του ελαττώµατος µπορεί να γίνει συγκρίνοντας διαδοχικά στιγµιότυπα
των τιµών αυτών, έως ότου ανακαλυφθεί κάποια ανωµαλία. Τότε, το ελάττωµα εντο-
πίζεται στο τµήµα του κώδικα που βρίσκεται ανάµεσα στην εντολή που εκτύπωσε το
τελευταίο ορθό στιγµιότυπο και σε αυτή που εκτύπωσε το πρώτο λανθασµένο.
Εάν το τµήµα αυτό είναι εκτεταµένο, ο εκκαθαριστής µπορεί να συνεχίσει να προ-
σθέτει εντολές εκτύπωσης διαγνωστικών µηνυµάτων µέχρι να περιορίσει το πιθανό
αίτιο του σφάλµατος σε µερικές µόνο εντολές. Αυτό δε σηµαίνει ότι είναι λανθα-
σµένες οι εντολές: µπορεί να υλοποιούν σωστά µια λανθασµένη σχεδίαση!
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 131
1 3 2 K E ºA § A I O 6 : ∂ ∫ ™ º∞ § ª∞∆ ø™ ∏
Καθώς η τεχνική αυτή είναι αρκετά διαδεδοµένη, ο εκκαθαριστής µπορεί να πάρει
κάποια µέτρα για να µειώσει τις συνέπειες που έχει η χρήση εντολών εκτύπωσης δια-
γνωστικών µηνυµάτων. Έτσι, υπάρχουν τρεις τρόποι απενεργοποίησης των εντολών
αυτών πριν την τελική διάθεση του προγράµµατος (Sommerville[96]):
• Όλες αυτές οι εντολές µπορεί να έχουν ένα κοινό πρόθεµα (π.χ. DEBUG), ώστε
να είναι εύκολη η αυτοµατοποιηµένη αναζήτησή τους και η διαγραφή ή η µετα-
τροπή τους σε σχόλια. ∆υστυχώς, η αναστροφή αυτής της διαδικασίας (δηλαδή,
η εκ νέου εισαγωγή ή ενεργοποίηση των διαγραµµένων εντολών) είναι από ασύµ-
φορη έως αδύνατη.
• Μερικοί µεταγλωττιστές επιτρέπουν την ελεγχόµενη (µε βάση κάποια ειδική οδη-
γία) µεταγλώττιση των εντολών αυτών, µε την προϋπόθεση ότι έχουν γραφεί σύµ-
φωνα µε κάποιους κανόνες. ∆υστυχώς, αυτή η δυνατότητα δεν παρέχεται από
όλους τους µεταγλωττιστές.
• Οι εντολές αυτές γράφονται έτσι ώστε να εκτελούνται όταν ισχύει κάποια σφαι-
ρική συνθήκη. Όταν το πρόγραµµα πρόκειται να διατεθεί στους χρήστες, η συν-
θήκη αυτή γίνεται ψευδής, µε αποτέλεσµα ο µεταγλωττιστής να αγνοεί τις εντο-
λές αυτές. ∆υστυχώς, όµως, αυτές παραµένουν στον κώδικα του προγράµµατος,
µε αποτέλεσµα να αυξάνεται το µέγεθός του.
Εάν δε κατά την εφαρµογή του τελευταίου τρόπου χρησιµοποιηθεί συνθήκη που µπορεί
να λάβει περισσότερες από δύο τιµές, ο εκκαθαριστής µπορεί να ελέγξει και τον όγκο
Τα µειονεκτήµατα που παρουσιάζει η εισαγωγή εντολών εκτύπωσης διαγνωστικών
µηνυµάτων στον κώδικα ενός προγράµµατος είναι τα εξής:
• Η συνεχής εισαγωγή εντολών εκτύπωσης διαγνωστικών µηνυµάτων είναι µια
κουραστική και χρονοβόρος διαδικασία.
• Κάθε φορά που εισάγονται επιπλέον εντολές αυτού του είδους, ο κώδικας πρέ-
πει να υποστεί νέα µεταγλώττιση.
• Οι εντολές αυτές πρέπει να αφαιρεθούν από τον κώδικα πριν την τελική διάθε-
ση του λογισµικού.
• Σε περίπτωση που εµφανιστούν νέα σφάλµατα, χρειάζεται να εισαχθούν ή να
ενεργοποιηθούν εκ νέου οι εντολές εκτύπωσης διαγνωστικών µηνυµάτων.
• Το χρονοδιάγραµµα ανάπτυξης σπάνια µπορεί να «αντέξει» το χρόνο που απαιτεί
η επεξεργασία του τεράστιου όγκου δεδοµένων, τα οποία παράγονται κατά την
εκτέλεση ενός προγράµµατος, ο κώδικας του οποίου περιέχει τέτοιες εντολές.
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 132
των παραγόµενων δεδοµένων: οι εντολές εκτύπωσης διαγνωστικών µηνυµάτων παρά-
γουν έξοδο µε διαφορετικά επίπεδα λεπτοµέρειας, ανάλογα µε την τιµή της συνθήκης.
6.2.2 √ÈÛıÔ‰ÚfiÌËÛË
Η οπισθοδρόµηση (backtracking) µπορεί να εφαρµοστεί µε επιτυχία σε µικρού µεγέ-
θους προγράµµατα. ∆υστυχώς, καθώς αυξάνονται οι γραµµές κώδικα, µειώνονται
και οι πιθανότητες εντοπισµού του ελαττώµατος, αφού αυξάνονται θεαµατικά τα
δυνατά µονοπάτια εκτέλεσης.
Σύµφωνα µε τη µεθοδολογία αυτή, ξεκινούµε τον έλεγχο του πηγαίου κώδικα του
ελαττωµατικού προγράµµατος από το σηµείο όπου εµφανίστηκε το σφάλµα. Ιχνη-
λατούµε την εκτέλεση του κώδικα προς τα πίσω, µέχρι να φτάσουµε στο ελάττωµα
που αποτελεί και την πηγή του σφάλµατος.
Ο στόχος της οπισθοδρόµησης είναι να προσδιορίσει την «περιοχή» του κώδικα,
όπου µπορεί να βρίσκεται το ελάττωµα, το οποίο µπορεί στη συνέχεια να αποκαλυ-
φθεί µετά από προσεκτική εξέταση του κώδικα που βρίσκεται µέσα στα όρια της
«ύποπτης» περιοχής ή µετά από εφαρµογή τεχνικών εξάλειψης του αιτίου (περι-
γράφονται στην επόµενη υπο – ενότητα).
6.2.3 ∂Í¿ÏÂÈ„Ë ÙÔ˘ ·ÈÙ›Ô˘
Η εφαρµογή αυτής της µεθοδολογίας απαιτεί την οργάνωση και επεξεργασία των
δεδοµένων που σχετίζονται µε το σφάλµα, ώστε να αποµονωθούν τα πιθανά αίτια.
Τότε είναι δυνατή:
• η διαµόρφωση µιας υπόθεσης εργασίας για το αίτιο, η αλήθεια ή το ψεύδος της
οποίας µπορεί να αποδειχθεί µε τα δεδοµένα, ή
• η εφαρµογή ελέγχων µε στόχο να απορριφθεί καθένα από τα αίτια.
Ο έλεγχος της αλήθειας µιας υπόθεσης γίνεται χρησιµοποιώντας την τεχνική της επα-
γωγής ή της απαγωγής σε άτοπο. Εάν κάποια υπόθεση φαίνεται να οδηγεί στην απο-
κάλυψη του ελαττώµατος, εφαρµόζονται περισσότεροι έλεγχοι, χρησιµοποιώντας
λεπτοµερέστερα δεδοµένα ελέγχου.
Επαγωγή
Η επαγωγή (induction) περιλαµβάνει τη διαµόρφωση µιας υπόθεσης εργασίας µε
βάση την ανάλυση των δεδοµένων ελέγχου και τη συλλογή ειδικών δεδοµένων µε
τα οποία µπορεί να αποδειχθεί η αλήθεια ή το ψεύδος αυτής. Τα βήµατα της τεχνι-
κής (αναπαρίστανται γραφικά στο Σχήµα 6.3) είναι τα ακόλουθα (Shooman[83]):
1 3 3 6 . 2 M∂ £√¢ √§ √° π ∂ ™ ∂ ∫ ™ º∞ § ª∞∆ ø™ ∏™
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 133
1 3 4 K E ºA § A I O 6 : ∂ ∫ ™ º∞ § ª∞∆ ø™ ∏
• Εντοπισµός και συλλογή όλων των σχετικών µε το σφάλµα δεδοµένων. Αποτελεί
σοβαρότατο σφάλµα του εκκαθαριστή η παράλειψη της συλλογής όλων των δεδο-
µένων που σχετίζονται µε το πρόβληµα πριν αρχίσει η προσπάθεια εντοπισµού
του ελαττώµατος. Περιλαµβάνει την καταγραφή όλων των δεδοµένων σχετικά
µε τη λανθασµένη αλλά και την ορθή συµπεριφορά του προγράµµατος, αλλά και
των αποτελεσµάτων που έδωσαν παρόµοιες περιπτώσεις ελέγχου στις οποίες δεν
εµφανίστηκε το σφάλµα.
• Οργάνωση των δεδοµένων. Καθώς η επαγωγή προχωρά από το ειδικό στο γενι-
κό, η οργάνωση των δεδοµένων επιτρέπει την παρατήρηση επαναλαµβανόµενων
βασικών δοµών και αντιφάσεων.
• ∆ιαµόρφωση µιας υπόθεσης εργασίας. Η µελέτη των σχέσεων και των βασικών
δοµών που εµφανίζονται στα δεδοµένα οδηγεί στη διαµόρφωση µιας ή περισσό-
τερων υποθέσεων σχετικά µε το κρυµµένο ελάττωµα. Στην περίπτωση που είναι
δυνατή η διαµόρφωση πολλών υποθέσεων, η περισσότερο πιθανή εξετάζεται
πρώτη. Εάν δεν είναι δυνατή η διαµόρφωση κάποιας υπόθεσης, χρειάζεται να
συλλεχθούν περισσότερα δεδοµένα.
• Απόδειξη της υπόθεσης. Η απόδειξη της ορθότητας της υπόθεσης είναι καθορι-
στική πριν την απόπειρα διόρθωσης του ελαττώµατος. Παράλειψη του βήµατος
αυτού (κάτι που, δυστυχώς, είναι συνηθισµένο κάτω από την πίεση που δέχεται
ο εκκαθαριστής) οδηγεί στη διόρθωση ενός µέρους του ελαττώµατος. Η ορθό-
τητα µπορεί να αποδειχθεί συγκρίνοντας την υπόθεση µε τα αρχικά δεδοµένα και
διασφαλίζοντας ότι αυτή επεξηγεί πλήρως την ύπαρξη των δεδοµένων αυτών.
Εάν αυτό δεν ισχύει, τότε η υπόθεση είναι άκυρη ή είναι ατελής ή υπάρχουν
περισσότερα από ένα ελαττώµατα.
™¯‹Ì· 6.3
Η εφαρµογή της
επαγωγής για την
αποκάλυψη ελατ-
τωµάτων
Eντοπισµός 
και Συλλογή 
Όλων των 
∆εδοµένων
Oργάνωση των 
∆εδοµένων
∆υνατή
∆υνατή
Aδύνατη
Aδύνατη
∆ιόρθωση 
Σφάλµατος
Aπόδειξη 
Yπόθεσης
∆ιαµόρφωση 
Yπόθεσης
Mελέτη των 
Συσχετίσεων
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 134
Απαγωγή
Η απαγωγή (deduction) αρχίζει µε την καταγραφή όλων των πιθανών αιτίων ή υπο-
θέσεων. Στη συνέχεια, αυτά απορρίπτονται ένα προς ένα, µέχρι να αποµείνει ένα
πιθανό αίτιο προς επικύρωση. Η τεχνική (Σχήµα 6.4) περιλαµβάνει τα ακόλουθα
βήµατα (Shooman[83]):
• Απαρίθµηση των πιθανών αιτίων ή υποθέσεων. Περιλαµβάνει την δηµιουργία µιας
λίστας µε όλα τα πιθανά αίτια του ελαττώµατος που µπορεί να σκεφθεί ο εκκα-
θαριστής. ∆εν χρειάζεται, στο βήµα αυτό, πλήρης τεκµηρίωση της εγκυρότητας
κάθε αιτίου. Στην ουσία πρόκειται για τρόπους οργάνωσης και ανάλυσης των
δεδοµένων.
• Απόρριψη αιτίων µε βάση τα δεδοµένα. Μετά από προσεκτική ανάλυση των δεδο-
µένων, ο εκκαθαριστής προσπαθεί να απορρίψει όλα τα πιθανά αίτια, πλην ενός.
Εάν περισσότερα από ένα αίτια παραµένουν πιθανά, το περισσότερο πιθανό από
αυτά εξετάζεται πρώτο. Εάν δεν αποµείνει κανένα πιθανό αίτιο, τότε χρειάζεται
η συλλογή περισσότερων δεδοµένων.
• Εκλέπτυνση της επιλεγµένης υπόθεσης. Στο σηµείο αυτό, το πιθανό αίτιο που έχει
αποµείνει είναι ίσως σωστό, αλλά η περιγραφή του είναι µάλλον αρκετά γενική
για να οδηγήσει στον εντοπισµό του ελαττώµατος. Συνεπώς, το επόµενο βήµα
είναι να χρησιµοποιηθούν τα δεδοµένα και οι ενδείξεις για να γίνει περισσότερο
λεπτοµερής η περιγραφή του πιθανού αιτίου.
• Απόδειξη της υπόθεσης. Πρόκειται για το κρίσιµο βήµα, το οποίο εκτελείται µε
τον ίδιο τρόπο όπως στην περίπτωση της επαγωγής.
1 3 5 6 . 2 M∂ £√¢ √§ √° π ∂ ™ ∂ ∫ ™ º∞ § ª∞∆ ø™ ∏™
™¯‹Ì· 6.4
Η εφαρµογή της
απαγωγής για την
αποκάλυψη
ελαττωµάτων
Συλλογή 
Περισσοτέρων 
∆εδοµένων
∆υνατή
∆ιόρθωση 
Σφάλµατος
Aδύνατη
∆εν έµεινε 
Kανένα
Aπόδειξη 
Yπόθεσης
Eκλέπτυνση 
Eπιλεγµένης 
Yπόθεσης
Aπόρριψη Aιτίων 
µε Bάση τα 
∆εδοµένα
Aπαρίθµηση 
των Πιθανών 
Aιτίων
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 135
1 3 6 K E ºA § A I O 6 : ∂ ∫ ™ º∞ § ª∞∆ ø™ ∏
6.2.4 µÔ‹ıÂÈ·!
Στην ενότητα αυτή µελετήσαµε ένα σύνολο τεχνικών εκσφαλµάτωσης. Όλες αποτε-
λούν δοκιµασµένα εργαλεία, τα οποία διευκολύνουν το έργο της εκσφαλµάτωσης. Να
θυµάστε όµως: καµία δεν εγγυάται ότι θα αποκαλύψει τα ελαττώµατα του κώδικά σας.
Τι θα κάνετε σε περίπτωση όπου, αφού έχετε δοκιµάσει όλες τις τεχνικές και τις ιδέες
σας, το σφάλµα στην εκτέλεση επιµένει να εµφανίζεται; Υπάρχει µια τελευταία ελπί-
δα: οι συνεργάτες σας! Καλύτερα να υιοθετήσετε τη στάση του «µη εγωιστή προ-
γραµµατιστή» και να ζητήσετε τη βοήθειά τους. Μια νέα µατιά στον κώδικα και µια
διαφορετική προσέγγιση από έναν άλλο άνθρωπο µπορεί να κάνει θαύµατα!
∆οκιµάστε στη δεξιά στήλη να τοποθετήσετε στη σωστή σειρά τα βήµατα των
τεχνικών της επαγωγής και της απαγωγής, τα οποία δείχνονται σε τυχαία σειρά
στην αριστερή στήλη:
ΤΥΧΑΙΑ ΣΕΙΡΑ
1. ∆ιαµόρφωση µιας υπόθεσης εργασίας
2. Απαρίθµηση των πιθανών αιτίων
3. Απόδειξη της υπόθεσης
4. Οργάνωση των δεδοµένων
5. Εκλέπτυνση της επιλεγµένης υπόθεσης
6. Συλλογή όλων των δεδοµένων
7. Απόρριψη αιτίων µε βάση τα δεδοµένα
ΣΩΣΤΗ ΣΕΙΡΑ
Επαγωγή
1.
2.
3.
4.
Απαγωγή
1.
2.
3.
4.
ÕÛÎËÛË ·˘ÙÔ·ÍÈÔÏfiÁËÛ˘ 6.1
∆οκιµάστε να συµπληρώσετε τα κενά στο κείµενο που ακολουθεί χρησιµοποιώ-
ντας, στην κατάλληλη πτώση, κάποιες από τις λέξεις:
Κατά µέτωπο επίθεση Καταχώρηση Πριν
Υπόθεση εργασίας Εξαρτηµένη Μαζί µε
∆οκιµή βήτα Οπισθοδρόµηση Μετά
Ιχνηλάτηση ∆ιαδικασία ελέγχου Εκτύπωση µηνυµάτων
ÕÛÎËÛË ·˘ÙÔ·ÍÈÔÏfiÁËÛ˘ 6.2
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 136
1 3 7 6 . 2 M∂ £√¢ √§ √° π ∂ ™ ∂ ∫ ™ º∞ § ª∞∆ ø™ ∏™
Ανεξάρτητη Απαγωγή Ελάττωµα
Αυξητική συγκρότηση Σηµείο διακοπής Απόφαση
Χρόνο ∆ιαδικασία ανάπτυξης Εµπρός
Επαγωγή Πίσω Σφάλµα
Σηµείο διακλάδωσης ∆οκιµαστική περίπτωση Εκσφαλµάτωση
Αφορµή για την εφαρµογή µιας διαδικασίας εκσφαλµάτωσης αποτελεί η εµφάνι-
ση ενός ………………. κατά τον έλεγχο ενός προγράµµατος. Συνεπώς η εκσφαλ-
µάτωση αποτελεί …………. διαδικασία, η οποία εφαρµόζεται ………… τον έλεγ-
χο του λογισµικού. Στόχος της είναι η ανακάλυψη του ………………… του κώδι-
κα, το οποίο προκάλεσε το ……………………
Για τον εντοπισµό της περιοχής του κώδικα όπου βρίσκεται το ελάττωµα, µπορεί
να χρησιµοποιηθεί η ………………… Σύµφωνα µε την τεχνική αυτή, ξεκινούµε
από το σηµείο όπου εµφανίστηκε το σφάλµα και καταγράφουµε, προχωρώντας
προς τα …………, τα µονοπάτια εκτέλεσης του πηγαίου κώδικα. Τότε, µελετώ-
ντας τα αποτελέσµατα του ελέγχου µπορούµε να εντοπίσουµε το αίτιο του σφάλ-
µατος χρησιµοποιώντας µια από τις µαθηµατικές τεχνικές της ……………… ή της
………… … Και οι δύο τεχνικές περιλαµβάνουν τη διαµόρφωση (ή την επιλογή)
µιας ……… …………, την ισχύ της οποίας προσπαθούµε να αποδείξουµε ή να
απορρίψουµε.
Όταν όλες οι άλλες τεχνικές αποτύχουν, µένει µόνο να χρησιµοποιήσουµε µεθό-
δους ………………… Αυτές περιλαµβάνουν την τοποθέτηση µέσα στον κώδικα
……… ……… (ώστε να διακόπτεται η εκτέλεση του προγράµµατος όταν εµφα-
νιστεί µια συνθήκη), αλλά και εντολών …………………… (οι οποίες τυπώνουν
κάποιο µήνυµα όταν εµφανιστεί µια συνθήκη) ή ………………… (ώστε να κατα-
γράφονται οι τιµές επιλεγµένων µεταβλητών).
Έστω ότι ο έλεγχος του ακόλουθου αλγόριθµου δυαδικής αναζήτησης (ενός στοι-
χείου ΚΕΥ σε ένα ταξινοµηµένο πίνακα Τ) έδωσε τα αποτελέσµατα που φαίνονται
στον Πίνακα 6.1. Είναι φανερό ότι ο αλγόριθµος εµφανίζει σφάλµα εκτέλεσης όταν
αναζητείται το πρώτο ή το τελευταίο στοιχείο του πίνακα (KEY = T[FIRST(T)]
OR KEY = T[LAST(T)]).
¢Ú·ÛÙËÚÈfiÙËÙ· 6.4 (ανακεφαλαιωτική)
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 137
1 3 8 K E ºA § A I O 6 : ∂ ∫ ™ º∞ § ª∞∆ ø™ ∏
ΑΛΓΟΡΙΘΜΟΣ ∆ΥΑ∆ΙΚΗ – ΑΝΑΖΗΤΗΣΗ
ΕΙΣΟ∆ΟΣ
KEY: INTEGER ;
T: ARRAY [1..N] OF INTEGER ;
ΕΞΟ∆ΟΣ
FOUND: BOOLEAN ;
POS: INTEGER ;
∆Ε∆ΟΜΕΝΑ
TOP, BOT, MID: INTEGER ;
ΑΡΧΗ
FOUND := FALSE ;
POS := – 1 ;
BOT := T[FIRST(T)] ;
TOP := T[LAST(T)] ;
ΕΝΟΣΩ ((BOT < TOP) AND (FOUND = FALSE)) ΕΠΑΝAΛΑΒΕ
MID := (TOP + BOT) div 2 ;
ΕΑΝ (Τ[MID] = KEY) ΤΟΤΕ
FOUND := TRUE ;
POS := MID
ΑΛΛΙΩΣ
ΕΑΝ (Τ[MID] < KEY) ΤΟΤΕ
BOT := MID + 1
ΑΛΛΙΩΣ
TOP := MID – 1
ΕΑΝ – ΤΕΛΟΣ
ΕΑΝ – ΤΕΛΟΣ
ΕΝΟΣΩ – ΤΕΛΟΣ
ΤΥΠΩΣΕ(FOUND, POS)
ΤΕΛΟΣ
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 138
1 3 9 6 . 2 M∂ £√¢ √§ √° π ∂ ™ ∂ ∫ ™ º∞ § ª∞∆ ø™ ∏™
¶›Ó·Î·˜ 6.1
Τα αποτελέσµατα της δοκιµαστικής εκτέλεσης του αλγορίθµου
ΠΙΝΑΚΑΣ Τ ΣΤΟΙΧΕΙΟ ΚΕΥ ΑΠΟΤΕΛΕΣΜΑ-
ΤΑ
[1, 4] 1 FOUND = T
POS = 1
[1, 4] 4 FOUND = F
POS = – 1
[1, 3, 5, 7] 1 FOUND = F
POS = – 1
[1, 3, 5, 7] 3 FOUND = T
POS = 2
[1, 3, 5, 7] 7 FOUND = F
POS = – 1
Με βάση τον αλγόριθµο και τα αποτελέσµατα του ελέγχου, προσπαθήστε να απα-
ντήσετε στις ακόλουθες έξι ερωτήσεις, µε στόχο να εντοπίσετε το ελάττωµα του
αλγορίθµου. Έπειτα συγκρίνετε τις απαντήσεις σας µε τη δική µας πρόταση, η
οποία παρατίθεται στη συνέχεια.
(α) Προσπαθήστε να διατυπώσετε τρεις υποθέσεις, µε βάση τα δεδοµένα και τον
αλγόριθµο, για το πιθανό αίτιο του σφάλµατος. Ποια νοµίζετε ότι είναι η πιθα-
νότερη αιτία;
(β) Όπως θα διαπιστώσετε, τα αποτελέσµατα του ελέγχου δεν επαρκούν για να
τεκµηριώσετε την υποψία σας. Ποιες άλλες περιπτώσεις ελέγχου νοµίζετε ότι
πρέπει να εκτελεστούν;
(γ) ∆οκιµάστε να εισάγετε στον κώδικα εντολές εκτύπωσης διαγνωστικών µηνυ-
µάτων. Ποιες είναι οι µεταβλητές των οποίων η εκτέλεση νοµίζετε ότι πρέπει
να ιχνηλατηθεί; Για τη συνέχεια της δραστηριότητας, καλύτερα να καταγρά-
ψετε τις τιµές των µεταβλητών που καταγράφουν οι εντολές αυτές για όσες
δοκιµαστικές περιπτώσεις κρίνετε απαραίτητο να εκτελέσετε.
(δ) Σε ποιο σηµείο του κώδικα νοµίζετε ότι πρέπει να εισαχθεί ένα σηµείο διακο-
πής της εκτέλεσης;
(ε) Προσπαθήστε να εντοπίσετε την περιοχή του κώδικα όπου µπορεί να βρίσκε-
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 139
1 4 0 K E ºA § A I O 6 : ∂ ∫ ™ º∞ § ª∞∆ ø™ ∏
Για να εντοπίσουµε το ελάττωµα του αλγορίθµου, µπορούµε να προχωρήσουµε ως εξής:
(α) H αρχικοποίηση του αλγορίθµου είναι µάλλον ορθή, άρα η αιτία του ελαττώµα-
τος πρέπει να αναζητηθεί στην επεξεργασία και τον τερµατισµό. Μια λίστα από
πιθανά αίτια είναι η ακόλουθη:
1. Oι συνθήκες τερµατισµού είναι λανθασµένες.
2. H εντολή υπολογισµού του µεσαίου στοιχείου MID είναι λανθασµένη.
3. Mια τουλάχιστον από τις εντολές υπολογισµού του νέου κάτω (BOT) ή άνω
ορίου (TOP) του πίνακα είναι λανθασµένη.
Από τις τρεις αυτές υποθέσεις, πιθανότερη φαίνεται να είναι η πρώτη. Παρατη-
ρήστε ότι στα αποτελέσµατα του ελέγχου, η τιµή της µεταβλητής FOUND δεν
αλλάζει σε TRUE, παρόλο που το αναζητούµενο στοιχείο βρίσκεται στον πίνα-
κα. Αυτό σηµαίνει ότι δεν εκτελείται το σώµα της εντολής ΕΝΟΣΩ, δηλαδή οι
συνθήκες της δεν ισχύουν.
Εάν αποδειχθεί ότι δεν είναι αυτή η αιτία, τότε το σφάλµα µπορεί να οφείλεται
σε λανθασµένο υπολογισµό της τιµής της MID. Κάτι τέτοιο όµως δε φαίνεται
πιθανό, αφού δεν υπάρχει άλλος τρόπος υπολογισµού του µεσαίου στοιχείου.
Ακόµη και αν θεωρήσουµε MID := ((TOP + BOT) div 2) + 1, δεν αλλάζει ουσια-
στικά τίποτε, αφού δεν αλλάζει ο τρόπος υπολογισµού των νέων ορίων, ενώ κιν-
δυνεύουµε να εισάγουµε νέα ελαττώµατα στον αλγόριθµο (πράγµατι, εάν δοκι-
µάσετε, θα δείτε ότι αυτή η αλλαγή προκαλεί σοβαρά σφάλµατα).
Εάν το ελάττωµα βρίσκεται στις συνθήκες του ΕΝΟΣΩ, τότε µπορούµε να εκλε-
πτύνουµε την υπόθεση, ως εξής:
1.1 H συνθήκη BOT < TOP είναι λανθασµένη.
1.2 H συνθήκη FOUND = FALSE είναι λανθασµένη.
ται το ελάττωµα εφαρµόζοντας την τεχνική της οπισθοδρόµησης. Ξεκινήστε
από τα δεδοµένα που προκαλούν το σφάλµα και ιχνηλατήστε προς τα πίσω
την εκτέλεση του αλγορίθµου.
(στ) Προσπαθήστε τώρα να εντοπίσετε το ελάττωµα ιχνηλατώντας προς τα εµπρός
την εκτέλεση του προγράµµατος. Ξεκινήστε από την αρχική κατάσταση, κατα-
γράψτε όλες τις ορθές τιµές των µεταβλητών και συγκρίνετέ τες µε τις πραγ-
µατικές τιµές που βρίσκονται στα δεδοµένα που συλλέξατε από τις εντολές
εκτύπωσης διαγνωστικών µηνυµάτων.
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 140
1.3 O τελεστής AND είναι λανθασµένος.
(β) Tα υπάρχοντα αποτελέσµατα του ελέγχου δεν επαρκούν για να απορρίψουµε τις
δύο από τις τρεις αρχικές υποθέσεις, ούτε να επιλέξουµε ανάµεσα στις τρεις πιο
συγκεκριµένες εκφράσεις της πρώτης υπόθεσης. Πρέπει να εφαρµοστούν περι-
πτώσεις ελέγχου όταν ο Τ περιέχει µόνο ένα στοιχείο (δηλαδή Ν=1, οπότε
FIRST(T) = LAST(T) = 1), αλλά και όταν το ΚΕΥ δε βρίσκεται στον Τ. Για το
σχεδιασµό των περιπτώσεων ελέγχου, µπορείτε να επαναλάβετε τη δραστηριό-
τητα 4 του Kεφαλαίου 4.
(γ) Aφού υποψιαζόµαστε ότι το λάθος βρίσκεται στη συνθήκη του ΕΝΟΣΩ, οπωσ-
δήποτε πρέπει να ιχνηλατηθούν οι τιµές των µεταβλητών που συµµετέχουν στη
συνθήκη, δηλαδή των BOT, TOP και FOUND. Για να συγκεντρώσουµε δεδοµέ-
να σχετικά µε τις υπόλοιπες πιθανές αιτίες, φροντίζουµε να τυπώνουµε και τις τιµές
των MID, BOT και TOP, όπως αυτές υπολογίζονται µέσα στο σώµα του ΕΝΟΣΩ.
Ο αλγόριθµος, λοιπόν, γίνεται ως εξής:
ΑΛΓΟΡΙΘΜΟΣ ∆ΥΑ∆ΙΚΗ – ΑΝΑΖΗΤΗΣΗ – ΜΕ – ΕΚΣΦΑΛΜΑΤΩΣΗ
ΕΙΣΟ∆ΟΣ
KEY: INTEGER ;
T: ARRAY [1..N] OF INTEGER ;
ΕΞΟ∆ΟΣ
FOUND: BOOLEAN ;
POS: INTEGER ;
∆Ε∆ΟΜΕΝΑ
TOP, BOT, MID: INTEGER ;
ΑΡΧΗ
FOUND := FALSE ;
POS := – 1 ;
BOT := T[FIRST(T)] ;
TOP := T[LAST(T)] ;
ΤΥΠΩΣΕ(BOT, TOP, FOUND, POS) ; { DEBUG }
ΕΝΟΣΩ ((BOT < TOP) AND (FOUND = FALSE)) ΕΠΑΝAΛΑΒΕ
MID := (TOP + BOT) div 2 ;
1 4 1 6 . 2 M∂ £√¢ √§ √° π ∂ ™ ∂ ∫ ™ º∞ § ª∞∆ ø™ ∏™
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 141
1 4 2 K E ºA § A I O 6 : ∂ ∫ ™ º∞ § ª∞∆ ø™ ∏
ΤΥΠΩΣΕ(MID, T[MID]) ; { DEBUG }
ΕΑΝ (Τ[MID] = KEY) ΤΟΤΕ
FOUND := TRUE ;
POS := MID
ΑΛΛΙΩΣ
ΕΑΝ (Τ[MID] < KEY) ΤΟΤΕ
BOT := MID + 1
ΑΛΛΙΩΣ
TOP := MID – 1
ΕΑΝ – ΤΕΛΟΣ
ΕΑΝ – ΤΕΛΟΣ
ΤΥΠΩΣΕ(FIRST, LAST, FOUND, POS) ; { DEBUG }
ΕΝΟΣΩ – ΤΕΛΟΣ
ΤΥΠΩΣΕ(FOUND, POS)
ΤΕΛΟΣ
Παρατηρήστε ότι έχουµε χρησιµοποιήσει τρεις εντολές εξόδου, µε τις οποίες τυπώ-
νουµε τις τιµές των µεταβλητών. Χαρακτηρίσαµε τις εντολές αυτές µε το σχόλιο
DEBUG, ώστε να είναι δυνατή η ανεύρεση και αποµάκρυνσή τους, όταν διορθωθεί
το πρόγραµµα. Οι τιµές των µεταβλητών που ιχνηλατούµε, οι οποίες εκτυπώθηκαν
από τις εντολές αυτές, φαίνονται στον Πίνακα 6.2.
¶›Ó·Î·˜ 6.2
Τα αποτελέσµατα της ιχνηλάτησης του αλγορίθµου
ΠΙΝΑΚΑΣ Τ ΣΤΟΙΧΕΙΟ ΚΕΥ ΑΠΟΤΕΛΕΣΜΑΤΑ
[1, 4] 1 BOT=1, TOP=2, FOUND=F, POS= – 1
MID=1, T[1]=1
BOT=1, TOP=2, FOUND=T, POS=1
FOUND=T, POS = 1
[1, 4] 4 BOT=1, TOP=2, FOUND=F, POS= – 1
MID=1, T[1]=1
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 142
BOT=2, TOP=2, FOUND=F, POS= – 1
FOUND=F, POS= – 1
[1, 3, 5, 7] 1 BOT=1, TOP=4, FOUND=F, POS= – 1
MID=2, T[2]=3
BOT=1, TOP=1, FOUND=F, POS= – 1
FOUND=F, POS= – 1
[1, 3, 5, 7] 3 BOT=1, TOP=4, FOUND=F, POS= – 1
MID=2, T[2]=3
BOT=1, TOP=4, FOUND=T, POS=2
FOUND=T, POS=2
[1, 3, 5, 7] 7 BOT=1, TOP=4, FOUND=F, POS= – 1
MID=2, T[2]=3
BOT=3, TOP=4, FOUND=F, POS= – 1
MID=3, T[3]=5
BOT=4, TOP=4, FOUND=F, POS= – 1
FOUND=F, POS= – 1
(δ) Tο καλύτερο σηµείο για την εισαγωγή εντολής διακοπής της εκτέλεσης είναι
ακριβώς πριν την εντολή ΕΝΟΣΩ – ΤΕΛΟΣ, όπου καθορίζεται εάν θα επανα-
ληφθεί η εκτέλεση του ΕΝΟΣΩ ή θα τερµατιστεί το πρόγραµµα. Τυπώνοντας
και µελετώντας τις τιµές των µεταβλητών και την κατάσταση του προγράµµα-
τος στο σηµείο αυτό, θα µπορέσουµε ίσως να συµπεράνουµε πότε το πρόγραµ-
µα δεν εκτελεί το σωστό αριθµό επαναλήψεων της δοµής ΕΝΟΣΩ.
(ε) Στη συνέχεια θα εφαρµόσουµε την οπισθοδρόµηση σε µία από τις δοκιµαστικές
περιπτώσεις (περίπτωση 3 του Πίνακα 6.2). Καλύτερα να κάνετε το ίδιο για όλες
τις περιπτώσεις για τις οποίες συλλέξατε δεδοµένα ελέγχου. Έχουµε λοιπόν:
1. Οι τιµές FOUND=F, POS= – 1 σηµαίνουν ότι η συνθήκη T[MID] = KEY
ποτέ δεν έγινε αληθής, άρα δεν ίσχυσε ποτέ MID=1.
2. Η τιµή της MID υπολογίζεται µε την εντολή MID := (TOP + BOT) div 2.
Όµως, αµέσως πριν τον τερµατισµό του προγράµµατος ίσχυε BOT=1 και
TOP=1, άρα έπρεπε να ισχύει και MID=1.
1 4 3 6 . 2 M∂ £√¢ √§ √° π ∂ ™ ∂ ∫ ™ º∞ § ª∞∆ ø™ ∏™
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 143
1 4 4 K E ºA § A I O 6 : ∂ ∫ ™ º∞ § ª∞∆ ø™ ∏
3. Συνεπώς, δεν έγινε ποτέ ο υπολογισµός της τιµής της MID, όταν BOT=1 και
TOP=1, άρα δεν εκτελέστηκε η δοµή ΕΝΟΣΩ, όταν ίσχυαν αυτές οι τιµές.
4. Το πρόβληµα, λοιπόν, εντοπίζεται στις συνθήκες της ΕΝΟΣΩ. Με µια
µατιά, βλέπουµε ότι, όταν BOT=1 και TOP=1, δεν ισχύει η πρώτη συνθή-
κη (BOT<TOP).
5. Προτείνουµε τη διόρθωση της συνθήκης σε BOT <= TOP και τον εκ νέου
έλεγχο του προγράµµατος.
(στ) Tο σφάλµα εµφανίζεται στις περιπτώσεις 2, 3 και 5 του Πίνακα 6.2. Ενώ το πρό-
γραµµα δίνει στην έξοδο FOUND=F και POS= – 1, η σωστή έξοδος είναι
FOUND=Τ και POS=1, POS=1 και POS=4, αντίστοιχα. Επιβεβαιώνεται, λοι-
πόν, η αρχική υποψία ότι ο αλγόριθµος παρουσιάζει πρόβληµα, όταν το αναζη-
τούµενο στοιχείο ΚΕΥ βρίσκεται στην αρχή ή το τέλος του πίνακα Τ.
Συγκρίνοντας τα ορθά µε τα λανθασµένα αποτελέσµατα και µελετώντας τα τελευ-
ταία παρατηρούµε ότι η ελαττωµατική συµπεριφορά εµφανίζεται όταν, κατά την
εκτέλεση του προγράµµατος, προκύψει BOT=TOP. Τότε, το πρόγραµµα δεν εκτελεί
την τελευταία επανάληψη του ΕΝΟΣΩ µε την οποία θα εύρισκε και το αναζητού-
µενο στοιχείο, αλλά (λανθασµένα) τερµατίζει.
Το πρόβληµα, λοιπόν, βρίσκεται στη συνθήκη του ΕΝΟΣΩ. Φαίνεται ότι η επιλογή
της πρώτης υπόθεσης για το πιθανό αίτιο (βλ. Απάντηση α) ήταν σωστή. Από τις
τρεις επιµέρους υποθέσεις της υπόθεσης 1, φαίνεται ότι η 1.1 είναι σωστή: το πρό-
βληµα βρίσκεται στη συνθήκη BOT < TOP, η οποία πρέπει να γίνει BOT <= TOP.
6.3 ∂Îηı¿ÚÈÛË ÛÊ·ÏÌ¿ÙˆÓ
Αφού βρεθεί το ελάττωµα στον κώδικα, πρέπει αυτός να διορθωθεί, ώστε να µην
εµφανιστεί ξανά το σφάλµα. Η διόρθωση του ελαττώµατος µπορεί να είναι απλή δια-
δικασία (εάν π.χ. πρόκειται για ένα απλό λάθος στην κωδικοποίηση). ∆υστυχώς, τις
περισσότερες φορές, η διόρθωση του ελαττώµατος απαιτεί την εκ νέου σχεδίαση του
λογισµικού ή ακόµα και την τροποποίηση των προδιαγραφών!
Σε µια τέτοια περίπτωση, ο φόρτος της διόρθωσης είναι µεγάλος. Μερικές φορές, το
χρονοδιάγραµµα ανάπτυξης και οι διαθέσιµοι πόροι δεν επαρκούν για πλήρη διόρ-
θωση. Αυτός είναι και ο λόγος για τον οποίο επιµένουµε στην υιοθέτηση µεθοδο-
λογιών επικύρωσης του λογισµικού από τα αρχικά στάδια ανάπτυξης. Τεχνικές όπως
η επισκόπηση του κώδικα και οι στατικές δοκιµές είναι φθηνές και αποτελεσµατι-
κές. Όσο περισσότερα λάθη ξεφύγουν µέχρι το στάδιο του ελέγχου, τόσο αυξάνει το
κόστος του έργου και τόσο περισσότερο κινδυνεύει η επιτυχής περάτωσή του.
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 144
Πριν προχωρήσει στη διόρθωση του κώδικα, ο εκκαθαριστής πρέπει να θέσει στον
εαυτό του τρεις ερωτήσεις (Pressman[94]):
1. Μήπως η αιτία του σφάλµατος εµφανίζεται και σε άλλα σηµεία του κώδικα; Κάτι
τέτοιο µπορεί να οφείλεται, π.χ. στην επαναχρησιµοποίηση του λανθασµένου
τµήµατος κώδικα ή στην υιοθέτηση λανθασµένου τρόπου σκέψης κατά την ανά-
πτυξη του προγράµµατος.
2. Μήπως η επιχειρούµενη διόρθωση προκαλέσει νέα σφάλµατα; Για παράδειγµα,
εάν το ελαττωµατικό σηµείο του κώδικα εµφανίζει υψηλό βαθµό σύζευξης, είναι
πιθανό ότι οποιαδήποτε παρέµβαση θα προκαλέσει νέα σφάλµατα.
3. Τι έπρεπε να είχε γίνει από την αρχή, ώστε να είχε αποφευχθεί η εµφάνιση του
σφάλµατος; Εάν, εκτός από το πρόγραµµα, διορθώσουµε και τη διαδικασία σχε-
δίασης ή ανάπτυξης που ακολουθήθηκε, τότε, όχι µόνο θα εξαφανίσουµε το
ελάττωµα από το συγκεκριµένο πρόγραµµα, αλλά θα αποφύγουµε την εµφάνι-
σή του σε επόµενα προγράµµατα.
1 4 5 6 . 3 ∂ ∫ ∫ ∞ £∞ ƒ π ™ ∏ ™ º∞ § ª∞∆ ø¡
Μετά τη διόρθωση του ελαττώµατος, ο κώδικας πρέπει να ελεγχθεί ξανά από την
οµάδα δοκιµής, ώστε να βεβαιωθεί ο εκκαθαριστής ότι:
• δεν παρουσιάζεται πια το ίδιο σφάλµα,
• δεν εµφανίστηκαν νέα σφάλµατα ως αποτέλεσµα της επέµβασής του στον κώδικα.
Η διαδικασία αυτή ονοµάζεται «έλεγχος παλινδρόµησης» (regression testing) και
περιλαµβάνει την εκ νέου εκτέλεση των δοκιµαστικών περιπτώσεων που αποκάλυ-
ψαν το σφάλµα. Εάν ο νέος έλεγχος επιτύχει ξανά, η διαδικασία εκσφαλµάτωσης
επαναλαµβάνεται, µέχρι την οριστική αποµάκρυνση των ελαττωµάτων του κώδικα.
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 145
1 4 6 K E ºA § A I O 6 : ∂ ∫ ™ º∞ § ª∞∆ ø™ ∏
™‡ÓÔ„Ë
Στο παρόν κεφάλαιο αναφερθήκαµε στις διαδικασίες εκσφαλµάτωσης, οι οποίες ακο-
λουθούν τις διαδικασίες του (επιτυχηµένου) ελέγχου, µε στόχο να διορθώσουν τα
σφάλµατα που αποκαλύφθηκαν κατά τη διάρκειά του. Η εκσφαλµάτωση είναι µια
διαδικασία ανεξάρτητη από τον έλεγχο, η οποία βρίσκεται στην ευθύνη του εκκαθα-
ριστή σφαλµάτων λογισµικού. Περιλαµβάνει τρία βασικά στάδια: εντοπισµό του ελατ-
τώµατος που προκαλεί το σφάλµα, διόρθωση του ελαττώµατος και επανέλεγχο του
λογισµικού.
∆υστυχώς, έως σήµερα δεν έχουν προταθεί συγκροτηµένες και ολοκληρωµένες µεθο-
δολογίες εκσφαλµάτωσης, µε αποτέλεσµα στη διάθεση του εκκαθαριστή να βρίσκε-
ται ένα σύνολο τεχνικών, οι οποίες ανήκουν σε µία από τις ακόλουθες κατηγορίες:
κατά µέτωπο επίθεση, οπισθοδρόµηση και εξάλειψη του αιτίου. Οι τεχνικές της πρώ-
της κατηγορίας στοχεύουν στη συγκέντρωση δεδοµένων, η ανάλυση των οποίων ίσως
αποκαλύψει το ελάττωµα. Όµως, οι µέθοδοι συγκέντρωσης των δεδοµένων (ιχνηλά-
τηση, εκτύπωση διαγνωστικών µηνυµάτων, εισαγωγή σηµείων διακοπής κ.λπ.) είναι
χρονοβόρες, παρεµβαίνουν στη δοµή του κώδικα και συνήθως οδηγούν στη συγκέ-
ντρωση ενός τεράστιου όγκου δεδοµένων, τα οποία στο µεγαλύτερο µέρος τους δε
σχετίζονται µε το ελάττωµα.
Έτσι, οι εκκαθαριστές προτιµούν να χρησιµοποιούν είτε την οπισθοδρόµηση, είτε
τεχνικές εξάλειψης του αιτίου. Σύµφωνα µε την πρώτη τεχνική, οι εκκαθαριστές επι-
χειρούν να αποκαλύψουν το ελάττωµα ξεκινώντας από το σφάλµα που αυτό προκα-
λεί και «εκτελώντας» το πρόγραµµα «προς τα πίσω». Οι τεχνικές εξάλειψης του αιτί-
ου χρησιµοποιούν την επαγωγή ή την απαγωγή για να αποδείξουν ή να καταρρίψουν
µε µαθηµατικά επιχειρήµατα υποθέσεις για την αιτία του σφάλµατος.
Το τελευταίο στάδιο της εκσφαλµάτωσης περιλαµβάνει τη διόρθωση του ελαττώµα-
τος και τη διεξαγωγή ελέγχων παλινδρόµησης. Στο σηµείο αυτό, η επιθυµία όλων
είναι όχι µόνο να έχει διορθωθεί το ελάττωµα, αλλά και να µην έχουν προκληθεί νέα
ελαττώµατα από τον κώδικα που υλοποιεί τις διορθώσεις!
Στα Kεφάλαια 4, 5 και 6 µελετήσαµε διεξοδικά τις δραστηριότητες που σχετίζονται
µε τον έλεγχο και τη διόρθωση του λογισµικού. Στα Kεφάλαια 2 και 3 είχαµε µελε-
τήσει άλλες τεχνικές εγκυροποίησης, πέραν του ελέγχου. Η δοµηµένη και κατατµη-
µένη παρουσίαση των ζητηµάτων αυτών σας έχει ίσως δηµιουργήσει την αίσθηση ότι
πρόκειται για διακριτές, αποσπασµατικές δραστηριότητες, η εφαρµογή των οποίων
αφήνεται στη διάθεση του διαχειριστή του έργου και εξαρτάται σε µεγάλο βαθµό από
το χρονοδιάγραµµα και τη διαθεσιµότητα των πόρων.
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 146
Ετοιµαστείτε να γνωρίσετε στο Kεφάλαιο 7 το γενικότερο πλαίσιο µέσα στο οποίο
εντάσσονται όλες αυτές οι δραστηριότητες και να «εκπλαγείτε» από τη σηµασία του
στην ανάπτυξη ποιοτικού λογισµικού: πρόκειται για τις διαδικασίες εξασφάλισης της
ποιότητας του λογισµικού και τους παράγοντες που την επηρεάζουν.
µÈ‚ÏÈÔÁÚ·Ê›·
[1] R. Pressman (1994), Software Engineering: a practitioner’s approach. McGraw
– Hill, England.
[2] M.L. Shooman (1983), Software Engineering. McGraw – Hill, Tokyo.
[3] I. Sommerville (1996), Software Engineering. Addison – Wesley, USA
1 4 7 B I B § I O° PA ºI A
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 147
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 148
∂Í·ÛÊ¿ÏÈÛË ¶ÔÈfiÙËÙ·˜ & AÍÈÔÈÛÙ›·˜
™ÎÔfi˜
Το κεφάλαιο παρουσιάζει τη γενική έννοια της ποιότητας του λογισµικού, τις διαδικασίες
της εξασφάλισης της ποιότητας και την αξιοπιστία του λογισµικού ως το σηµαντικότερο
παράγοντα ποιότητας. Στοχεύει να σας βοηθήσει να κατανοήσετε ότι οι διαδικασίες εγκυ-
ροποίησης εντάσσονται µέσα σε ένα γενικότερο πλάνο ποιότητας του λογισµικού.
¶ÚÔÛ‰ÔÎÒÌÂÓ· ·ÔÙÂϤÛÌ·Ù·
Όταν θα έχετε µελετήσει αυτό το κεφάλαιο, θα µπορείτε να:
• ορίζετε τις τρεις διαστάσεις της ποιότητας του λογισµικού,
• περιγράφετε τους βασικούς παράγοντες που καθορίζουν την ποιότητα του λογισµικού,
• αναφέρετε τις σηµαντικότερες µετρικές που χρησιµοποιούνται για την ποσοτικοποί-
ηση των παραγόντων ποιότητας,
• συσχετίσετε µετρικές µε παράγοντες και διαγνώσετε αλληλοσυγκρουόµενους παρά-
γοντες,
• αναφέρετε πέντε τουλάχιστον δραστηριότητες που περιλαµβάνει η εξασφάλιση της
ποιότητας του λογισµικού,
• αναφέρετε τρεις τυπικές τεχνικές εξασφάλισης της ποιότητας του λογισµικού,
• ορίσετε το µέσο χρόνο ανάµεσα στην εµφάνιση σφαλµάτων, την διαθεσιµότητα, το
χρόνο διακοπής λειτουργίας και το χρόνο επιδιόρθωσης του λογισµικού,
• αναφέρετε δύο µοντέλα εµφάνισης σφαλµάτων και δύο µοντέλα αξιοπιστίας του λογι-
σµικού.
ŒÓÓÔȘ ÎÏÂȉȿ
7
∫ ∂ º ∞ § ∞ π √
• ποιότητα λογισµικού,
• παράγων / µετρική ποιότητας,
• αξιοπιστία λογισµικού,
• διαθεσιµότητα,
• χρόνος επιδιόρθωσης,
• εξασφάλιση ποιότητας λογισµικού,
• πλάνο εξασφάλισης της ποιότητας,
• διαδικασία του «καθαρού δωµατίου»,
• χρόνος διακοπής λειτουργίας,
• µέσος χρόνος ανάµεσα στην εµφάνιση
σφαλµάτων,
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 149
1 5 0 K E ºA § A I O 7 : ∂ •∞ ™ º∞ § π ™ ∏ ¶√π √∆ ∏∆∞ ™ & A •π √¶π ™ ∆ π ∞ ™
∂ÈÛ·ÁˆÁÈΤ˜ ·Ú·ÙËÚ‹ÛÂȘ
Φτάνοντας στο σηµείο αυτό του τόµου, έχετε ουσιαστικά µελετήσει όλες τις πλευρές και
τα στάδια της εγκυροποίησης λογισµικού. Ήδη, από το πρώτο κεφάλαιο, έχει αναφερθεί
ότι βασικός στόχος της εγκυροποίησης είναι η βελτίωση της ποιότητας του παραγόµενου
λογισµικού. Πραγµατικά, η διάδοση της χρήσης των υπολογιστών έχει µετατρέψει το λογι-
σµικό σε ένα βιοµηχανικό κατασκεύασµα, η ποιότητα του οποίου πρέπει να µετρείται
συνεχώς και µε αξιοπιστία. Η παράδοση λογισµικού χαµηλής ποιότητας µπορεί να έχει
σοβαρές ατοµικές, οικονοµικές και κοινωνικές συνέπειες για τους χρήστες του.
Όµως, πώς ορίζεται η ποιότητα του λογισµικού; ∆υστυχώς, δεν υπάρχει ένας καθολι-
κά αποδεκτός ορισµός: όλοι συµφωνούν ότι πρέπει να παράγεται ποιοτικό λογισµικό,
αλλά ο καθένας καταλαβαίνει τον όρο µε το δικό του τρόπο· όλοι πιστεύουν ότι η παρα-
γωγή ποιοτικού λογισµικού είναι αποτέλεσµα εφαρµογής κάποιων οδηγιών· όλοι θεω-
ρούν ότι για τα προβλήµατα του λογισµικού ευθύνονται οι «άλλοι».
Για τις ανάγκες µας θα υιοθετήσουµε έναν ορισµό που είναι αρκετά περιεκτικός
(Pressman[94]). Θεωρούµε ότι η ποιότητα (quality) του λογισµικού περιλαµβάνει την
ικανοποίηση ρητά εκφρασµένων απαιτήσεων σχετικά µε τη λειτουργία και την απόδο-
σή του, την τεκµηριωµένη υιοθέτηση αποδεκτών προτύπων ανάπτυξης και την ενσω-
µάτωση όλων εκείνων των χαρακτηριστικών του λογισµικού που έχει αναπτυχθεί µε
συστηµατικό τρόπο.
Ο ορισµός αυτός «σηκώνει» αρκετή (ατέλειωτη, ίσως) συζήτηση. Μας είναι όµως χρή-
σιµος, γιατί δίνει έµφαση σε τρια σηµαντικά σηµεία:
1. Η ποιότητα του λογισµικού µετρείται κυρίως µε βάση τις απαιτήσεις από το λογι-
σµικό. Οποιαδήποτε αποτυχία στην ικανοποίηση των απαιτήσεων µειώνει την ποι-
ότητα του λογισµικού.
2. Υπάρχουν διαδεδοµένα και αποδεκτά πρότυπα ικανά να καθοδηγήσουν τη σχεδία-
ση και ανάπτυξη του λογισµικού. Εάν δεν υιοθετηθούν τέτοια πρότυπα, είναι σχεδόν
σίγουρο ότι το λογισµικό που θα παραχθεί τελικά θα είναι χαµηλής ποιότητας.
3. Υπάρχει ένα σύνολο απαιτήσεων, οι οποίες συνήθως υπονοούνται και δεν εκφράζο-
νται καθαρά από τους τελικούς χρήστες. Το λογισµικό που ικανοποιεί τις ρητά εκφρα-
σµένες απαιτήσεις αλλά δεν ικανοποιεί τις υπονοούµενες απαιτήσεις είναι αµφίβο-
λης ποιότητας.
Μερικοί, δικαίως, θα αναρωτηθούν: µα στο τέλος των δραστηριοτήτων εγκυροποί-
ησης θα ασχοληθούµε µε την ποιότητα του λογισµικού; Από αυτή την άποψη, η θέση
του κεφαλαίου στον τόµο είναι παραπλανητική: η εξασφάλιση της ποιότητας του λογι-
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 150
σµικού στηρίζεται σε ένα σύνολο δραστηριοτήτων που πρέπει να εκτελούνται καθ’ό-
λη τη διάρκεια του κύκλου ανάπτυξης του λογισµικού. Στην πραγµατικότητα, όµως,
δεν πρόκειται για ένα σύνολο γνώσεων (αν και η εφαρµογή των δραστηριοτήτων προ-
ϋποθέτει τις γνώσεις που έχετε έως τώρα µελετήσει), αλλά περισσότερο είναι µια επαγ-
γελµατική στάση που πρέπει συνειδητά να υιοθετήσετε κατά την ανάπτυξη λογισµι-
κού. Υπό το πρίσµα αυτό, η εφαρµογή της γνώσης που περιέχεται στον παρόντα τόµο
συµβάλλει στη βελτίωση της ποιότητας του λογισµικού µε τους τρόπους που θα µελε-
τήσουµε στο κεφάλαιο αυτό.
Στην πρώτη ενότητα του κεφαλαίου (ενότητα 7.1) θα µελετήσουµε τους παράγοντες που
προσδιορίζουν την ποιότητα του λογισµικού και ένα σύνολο µετρικών, δηλαδή µετρή-
σιµων µεγεθών. Οι τιµές ενός συνόλου µετρικών καθορίζουν το βαθµό στον οποίο ο
αντίστοιχος παράγοντας ποιότητας έχει ενσωµατωθεί στο λογισµικό.
Στην ενότητα 7.2 θα αναφερθούµε στις δραστηριότητες διασφάλισης της ποιότητας του
λογισµικού, στο σχέδιο ποιότητας και στην οµάδα που είναι υπεύθυνη για την εφαρµο-
γή του. Στην επόµενη ενότητα (ενότητα 7.3) αναφέρονται σύντοµα τρεις τυπικές τεχνι-
κές εξασφάλισης της ποιότητας, ενώ στην τελευταία ενότητα (ενότητα 7.4) θα µελετή-
σουµε διεξοδικά το σηµαντικότερο από τους παράγοντες ποιότητας, την αξιοπιστία του
λογισµικού.
1 5 1 ∂ π ™ ∞ ° ø° π ∫ ∂ ™ ¶∞ ƒ∞∆ ∏ƒ ∏™ ∂ π ™
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 151
1 5 2 K E ºA § A I O 7 : ∂ •∞ ™ º∞ § π ™ ∏ ¶√π √∆ ∏∆∞ ™ & A •π √¶π ™ ∆ π ∞ ™
7.1 ¶·Ú¿ÁÔÓÙ˜ ÔÈfiÙËÙ·˜ Î·È ÌÂÙÚÈΤ˜
Η ποιότητα του λογισµικού εξαρτάται από ένα πολύπλοκο πλέγµα παραγόντων, οι
οποίοι διαφοροποιούνται ανάλογα µε την στοχευόµενη εφαρµογή και τους τελικούς
χρήστες του λογισµικού. Οι παράγοντες που επηρεάζουν την ποιότητα του λογισµι-
κού µπορούν να χωριστούν σε δύο κατηγορίες: στους παράγοντες που είναι άµεσα
µετρήσιµοι και σε αυτούς που είναι έµµεσα µετρήσιµοι.
Σε κάθε περίπτωση, οι παράγοντες ποιότητας του λογισµικού πρέπει να µετρώνται:
το λογισµικό πρέπει να συγκρίνεται µε κάτι που θεωρείται ως γνωστό πρότυπο,
ώστε από τη σύγκριση να προκύπτει ένδειξη της ποιότητάς του.
Ο McCall και η οµάδα του (McCall[77]) έχουν προτείνει µια κατηγοριοποίηση των
παραγόντων που επιδρούν στην ποιότητα του λογισµικού, µε βάση την άποψη του
λογισµικού που περιγράφει ο καθένας. Θεωρούν (όπως φαίνεται και στο Σχήµα 7.1)
ότι υπάρχουν τρεις σηµαντικές απόψεις περιγραφής του λογισµικού ως προϊόν: οι
λειτουργίες που παρέχει (operations), η δυνατότητα αναθεώρησης/βελτίωσης
(revision) και η δυνατότητα µεταφοράς/προσαρµογής (transition) του λογισµικού.
Οι ένδεκα παράγοντες ποιότητας του λογισµικού, σύµφωνα µε την κατηγοριοποίη-
ση αυτή είναι οι εξής:
Α. Παράγοντες που περιγράφουν χαρακτηριστικά σχετιζόµενα
µε τις παρεχόµενες λειτουργίες:
1. Ακεραιότητα (Integrity): Ο βαθµός στον οποίο µπορεί να ελεγχθεί η πρόσβαση
στο λογισµικό ή στα δεδοµένα από µη εξουσιοδοτηµένα για αυτό άτοµα.
2. Αξιοπιστία (Reliability): Ο βαθµός στον οποίο ένα πρόγραµµα αναµένεται να
εκτελεί την προδιαγεγραµµένη λειτουργία του µε την απαιτούµενη ακρίβεια.
3. Αποτελεσµατικότητα (Efficiency): Ο βαθµός απασχόλησης των υπολογιστικών
πόρων που απαιτεί ένα πρόγραµµα για να εκτελέσει τις λειτουργίες του (κατά τον
καλύτερο τρόπο) σε συνάρτηση µε το µέγεθος του κώδικα που τις περιγράφει.
4. Ευχρηστία (Usability): Η προσπάθεια που απαιτείται για να µάθει κανείς να χρη-
σιµοποιεί ένα πρόγραµµα, να δίνει δεδοµένα εισόδου σε αυτό και να ερµηνεύει
την έξοδο που αυτό παράγει.
5. Ορθότητα (Correctness): Ο βαθµός στον οποίο το λογισµικό ικανοποιεί τις προ-
διαγραφές του και πληροί τις προσδοκίες των χρηστών.
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 152
Β. Παράγοντες που περιγράφουν χαρακτηριστικά σχετιζόµενα
µε τη δυνατότητα αναθεώρησης / βελτίωσης του λογισµικού:
6. Ελεγξιµότητα (Testability): Η προσπάθεια που απαιτείται για τον έλεγχο και την
εγκυροποίηση του λογισµικού.
7. Ευελιξία (Flexibility): Η προσπάθεια που πρέπει να καταβληθεί για την τροπο-
ποίηση ενός λειτουργικού προγράµµατος.
8. Συντηρησιµότητα (Maintainability): Η προσπάθεια που απαιτείται για τον εντο-
πισµό και τη διόρθωση ενός ελαττώµατος του προγράµµατος.
Γ. Παράγοντες που περιγράφουν χαρακτηριστικά σχετιζόµενα
µε τη δυνατότητα µεταφοράς / προσαρµογής του λογισµικού:
9. ∆ιαλειτουργισιµότητα (Interoperability): Η προσπάθεια που πρέπει να καταβλη-
θεί για να «συνδεθεί» ένα σύστηµα λογισµικού µε ένα άλλο.
10.Επαναχρησιµοποιησιµότητα (Reusability): Ο βαθµός στον οποίο το λογισµικό ή
τµήµατα αυτού µπορούν να χρησιµοποιηθούν ξανά σε άλλες εφαρµογές.
11. Μεταφερσιµότητα (Portability): Η προσπάθεια που χρειάζεται για να µεταφερθεί
το λογισµικό από ένα περιβάλλον υλικού / λογισµικού σε ένα άλλο.
1 5 3 7 . 1 ¶∞ ƒ∞ ° √¡∆ ∂ ™ ¶√π √∆ ∏∆∞ ™ ∫ ∞ π ª∂ ∆ ƒ π ∫ ∂ ™
™¯‹Ì· 7.1
Παράγοντες που
επηρεάζουν την
ποιότητα
του λογισµικού
Συντηρισιµότητα: Mπορώ Nα Tο ∆ιορθώσω; 
Eυελιξία: Mπορώ Nα Tο αλλάξω; 
Eλεγξιµότητα: Mπορώ Nα Tο ελέγξω;
Mεταφερσιµότητα: Θα Mπορέσω Nα Tο 
Xρησιµοποιήσω Σε Άλλο Yπολογιστή; 
Eπαναχρησιµοποιησιµότητα: Θα Mπορέσω Nα 
Xρησιµοποιήσω Aλλού Tµήµα Tου Λογισµικού; 
∆ιαλειτουργισιµότητα: Θα Mπορέσω Nα Tο 
Kάνω Nα Eπικοινωνήσει Mε Άλλο Σύστηµα;
 
Xαρακτηριστικά 
Σχετιζόµενα Mε 
Bελτίωση
Xαρακτηριστικά 
Σχετιζόµενα Mε 
Προσαρµογή
Xαρακτηριστικά 
Σχετιζόµενα Mε 
Λειτουργία
Oρθότητα: Kάνει Aυτά Που Θέλω; 
Aξιοπιστία: Λειτουργεί Πάντα Mε Aκρίβεια; 
Aποτελεσµατικότητα: Λειτουργεί Στον Eξοπλισµό Mου Mε Tον 
Kαλύτερο ∆υνατό Tρόπο; 
Aκεραιότητα: Eίναι Aσφαλές; 
Eυχρηστία: Eίναι Σχεδιασµένο Για Tις Aνάγκες Tου Xρήστη;
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 153
1 5 4 K E ºA § A I O 7 : ∂ •∞ ™ º∞ § π ™ ∏ ¶√π √∆ ∏∆∞ ™ & A •π √¶π ™ ∆ π ∞ ™
Επειδή είναι δύσκολο έως αδύνατο να αναπτυχθούν τεχνικές άµεσης µέτρησης των
παραγόντων ποιότητας, έχει ορισθεί ένα σύνολο µετρικών Μ = {m
1
, …, m
n
}, έτσι
ώστε η τιµή κάθε παράγοντα QF να υπολογίζεται ως γινόµενο κάποιων από αυτές:
QF = w
1
× m
1
+ w
2
× m
2
+ … + w
k
× m
k
Το βασικό πρόβληµα µε τις µετρικές m είναι ότι η τιµή των περισσότερων από αυτές
είναι καθαρά υποκειµενική, αν και συνήθως βρίσκεται στο διάστηµα 1 έως 10. Το
ίδιο υποκειµενικό είναι και το βάρος w που έχει κάθε µετρική, το οποίο εξαρτάται
από το λογισµικό όπου εφαρµόζεται και την πολιτική που έχει υιοθετήσει η οµάδα
του έργου ανάπτυξης.
Στη µέθοδο υπολογισµού τιµών των παραγόντων ποιότητας που πρότεινε ο McCall
περιλαµβάνονται 21 µετρικές. Αµέσως µετά αυτές παρουσιάζονται µε αλφαβητική
σειρά. Μην ανησυχείτε εάν δεν τις κατανοήσετε µε την πρώτη ανάγνωση. Προσπα-
θήστε να απαντήσετε στη δραστηριότητα 1 που ακολουθεί, η οποία θα σας βοηθή-
σει να συσχετίσετε τις µετρικές µε τους παράγοντες ποιότητας. Εάν χρειαστεί, µπο-
ρείτε να επαναλάβετε τη µελέτη των µετρικών σε σχέση µε τους παράγοντες ποιό-
τητας. Οι µετρικές είναι οι ακόλουθες:
1. Ακρίβεια (Accuracy): H ακρίβεια των υπολογισµών, των συµβολισµών και του
ελέγχου.
2. Ανεξαρτησία από το σύστηµα λογισµικού (Software system independence): O
βαθµός στον οποίο το πρόγραµµα δεν εξαρτάται από µη διαδεδοµένα χαρακτη-
ριστικά της γλώσσας προγραµµατισµού, χαρακτηριστικά του λειτουργικού
συστήµατος ή άλλους περιορισµούς του περιβάλλοντος.
3. Ανεξαρτησία από το υλικό (Hardware independence): O βαθµός στον οποίο το
λογισµικό δεν εξαρτάται από το υλικό στο οποίο εκτελείται.
4. Ανοχή λαθών (Error tolerance): H ζηµιά που υφίσταται το πρόγραµµα όταν
συναντήσει ένα ελάττωµα.
5. Απλότητα (Simplicity): O βαθµός στον οποίο ένα πρόγραµµα µπορεί να γίνει
κατανοητό χωρίς δυσκολία.
6. Αποτελεσµατικότητα εκτέλεσης (Execution efficiency): H απόδοση του προ-
γράµµατος κατά την εκτέλεση, όσον αφορά στους πόρους που χρησιµοποιεί.
7. Ασφάλεια (Security): H διαθεσιµότητα µηχανισµών για τον έλεγχο ή την προ-
στασία προγραµµάτων και δεδοµένων.
8. Αυτο – περιγραφικότητα (Self – documentation): O βαθµός στον οποίο ο πηγαί-
ος κώδικας παρέχει τεκµηρίωση για τη λειτουργία του.
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 154
9. Γενικότητα (Generality): Tο εύρος εφαρµογής των συστατικών µερών του προ-
γράµµατος.
10. Εκπαίδευση (Training): O βαθµός στον οποίο το σύστηµα συµβάλλει στη διευ-
κόλυνση και τη γρήγορη εξοικείωση των νέων χρηστών.
11. Ενορχήστρωση (Instrumentation): O βαθµός στον οποίο το πρόγραµµα κατα-
γράφει την ίδια του τη λειτουργία και εντοπίζει τα λάθη που συµβαίνουν.
12. Επεκτασιµότητα (Expandability): O βαθµός στον οποίο µπορεί να επεκταθεί το
σχέδιο αρχιτεκτονικής, λειτουργιών ή δεδοµένων.
13. Ιχνηλατησιµότητα (Traceability): H δυνατότητα να ιχνηλατηθεί ένα τµήµα του
σχεδίου ή ένα συστατικό τµήµα του λογισµικού µέχρι τις αρχικές απαιτήσεις.
14. Λακωνικότητα (Conciseness): H συνοχή και η περιεκτικότητα των γραµµών
κώδικα του προγράµµατος.
15. Λειτουργισιµότητα (Operability): H ευκολία χρήσης ενός προγράµµατος.
16. Πληρότητα (Completeness): O βαθµός στον οποίο έχει επιτευχθεί πλήρης υλο-
ποίηση των προδιαγραφών των απαιτήσεων από καθεµία λειτουργία.
17. Συµβατότητα δεδοµένων (Data commonality): H χρήση τυποποιηµένων δοµών
και τύπων δεδοµένων σε όλη την έκταση του προγράµµατος.
18. Συµβατότητα επικοινωνίας (Communication commonality): H έκταση στην οποία
χρησιµοποιούνται τυποποιηµένες διεπαφές, τρόποι διασύνδεσης και πρωτόκολλα.
19. Συµβατότητα προτύπων (Auditability): H ευκολία µε την οποία µπορεί να ελεγ-
χθεί η υιοθέτηση προτύπων.
20. Συνέπεια (Consistency): H χρήση οµοιόµορφων τεχνικών σχεδίασης και τεκ-
µηρίωσης καθ’όλη τη διάρκεια του κύκλου ανάπτυξης.
21. Τµηµατικότητα (Modularity): O βαθµός λειτουργικής ανεξαρτησίας των συστα-
τικών τµηµάτων του λογισµικού.
1 5 5 7 . 1 ¶∞ ƒ∞ ° √¡∆ ∂ ™ ¶√π √∆ ∏∆∞ ™ ∫ ∞ π ª∂ ∆ ƒ π ∫ ∂ ™
Χρησιµοποιήστε τις γνώσεις, την εµπειρία και τη διαίσθησή σας για να συµπλη-
ρώσετε ένα πίνακα µε τις µετρικές εκείνες που συνεισφέρουν στη µέτρηση κάθε
παράγοντα ποιότητας. Η άσκηση είναι δύσκολη
.
για να λυθεί χρειάζεται προσε-
κτική µελέτη και κατανόηση των παραγόντων ποιότητας και των µετρικών. Στη
συνέχεια, συγκρίνετε τον πίνακά σας µε τον Πίνακα 7.1, ο οποίος συνοψίζει τις
προτάσεις που απαντώνται στη βιβλιογραφία.
¢Ú·ÛÙËÚÈfiÙËÙ· 7.1
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 155
1 5 6 K E ºA § A I O 7 : ∂ •∞ ™ º∞ § π ™ ∏ ¶√π √∆ ∏∆∞ ™ & A •π √¶π ™ ∆ π ∞ ™
¶›Ó·Î·˜ 7.1
Συσχέτιση µετρικών µε παράγοντες ποιότητας
Παράγοντας ποιότητας Μετρικές
Ακεραιότητα Ασφάλεια
Ενορχήστρωση
Συµβατότητα προτύπων
Αξιοπιστία Ανοχή λαθών
Συνέπεια
Ακρίβεια
Απλότητα
Τµηµατικότητα
Αποτελεσµατικότητα Αποτελεσµατικότητα εκτέλεσης
Λειτουργισιµότητα
Λακωνικότητα
∆ιαλειτουργισιµότητα Τµηµατικότητα
Γενικότητα
Συµβατότητα επικοινωνίας
Συµβατότητα δεδοµένων
Ελεγξιµότητα Απλότητα
Τµηµατικότητα
Συµβατότητα προτύπων
Ενορχήστρωση
Αυτο – περιγραφικότητα
Επαναχρησιµοποιησιµότητα Γενικότητα
Τµηµατικότητα
Ανεξαρτησία από το υλικό
Ανεξαρτησία από το σύστηµα λογισµικού
Ευελιξία Λακωνικότητα
Απλότητα
Τµηµατικότητα
Γενικότητα
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 156
Επεκτασιµότητα
Αυτο – περιγραφικότητα
Ευχρηστία Λειτουργισιµότητα
Εκπαίδευση
Μεταφερσιµότητα Γενικότητα
Τµηµατικότητα
Αυτο – περιγραφικότητα
Ανεξαρτησία από το υλικό
Ανεξαρτησία από το σύστηµα λογισµικού
Ορθότητα Ιχνηλατησιµότητα
Συνέπεια
Πληρότητα
Συντηρησιµότητα Συνέπεια
Ενορχήστρωση
Τµηµατικότητα
Απλότητα
Αυτο – περιγραφικότητα
1 5 7 7 . 1 ¶∞ ƒ∞ ° √¡∆ ∂ ™ ¶√π √∆ ∏∆∞ ™ ∫ ∞ π ª∂ ∆ ƒ π ∫ ∂ ™
Είναι επιθυµητό το υπό ανάπτυξη λογισµικό να συγκεντρώνει υψηλό «βαθµό» σε
καθένα από τους παράγοντες ποιότητας. Όπως όµως συµβαίνει µε οποιοδήποτε
τεχνολογικό προϊόν, αρκετοί από τους παράγοντες ποιότητας λογισµικού αλληλο-
αναιρούνται, µε αποτέλεσµα ο µηχανικός λογισµικού να πρέπει να επιλέξει ανάµε-
σά τους, ή (το καλύτερο) να εξασφαλίσει µια ισορροπία, θυσιάζοντας τον υψηλό
«βαθµό» σε ένα παράγοντα ποιότητας προς όφελος κάποιου άλλου παράγοντα
(tradeoff). ∆οκιµάστε να καταγράψετε πέντε τουλάχιστον ζεύγη παραγόντων που
αλληλοαναιρούνται, πριν µελετήσετε τον κατάλογο που εµείς έχουµε συγκροτήσει.
¢Ú·ÛÙËÚÈfiÙËÙ· 7.2
Μελετώντας λοιπόν την περιγραφή των παραγόντων ποιότητας και των µετρικών
που σχετίζονται µε τον καθένα, µπορούµε να πούµε ότι υπάρχουν αρκετά ζεύγη αντι-
κρουόµενων παραγόντων ποιότητας, όπως φαίνεται και στον Πίνακα 7.2.
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 157
1 5 8 K E ºA § A I O 7 : ∂ •∞ ™ º∞ § π ™ ∏ ¶√π √∆ ∏∆∞ ™ & A •π √¶π ™ ∆ π ∞ ™
¶›Ó·Î·˜ 7.2
Ζεύγη αντικρουόµενων παραγόντων ποιότητας (Σκορδαλάκης[91])
Ζεύγος παραγόντων Εξήγηση
Ακεραιότητα κατά
Αποτελεσµατικότητας
Η διασφάλιση της ακεραιότητας των δεδοµένων ή του
λογισµικού απαιτεί τη συγγραφή ειδικού πρόσθετου κώδι-
κα, ο οποίος επιµηκύνει την εκτέλεση του προγράµµατος.
Ευχρηστία κατά
Αποτελεσµατικότητας
Για να διευκολυνθεί το έργο των χρηστών του προγράµ-
µατος απαιτείται η συγγραφή πρόσθετου κώδικα, ο οποί-
ος επιµηκύνει την εκτέλεση του προγράµµατος.
Συντηρησιµότητα
κατά
Αποτελεσµατικότητας
Εάν βελτιστοποιηθεί ο κώδικας, δυσκολεύει η απλότητα
του προγράµµατος και κατ’ επέκταση το έργο του συντη-
ρητή. Η ανάπτυξη τµηµατοποιηµένου και ενορχηστρωµέ-
νου κώδικα επιβαρύνει την εκτέλεση του προγράµµατος.
Ελεγξιµότητα κατά
Αποτελεσµατικότητας
Η τµηµατοποιηµένη σχεδίαση και ανάπτυξη, η χρήση ευα-
νάγνωστων ονοµάτων µεταβλητών κ.λπ. και η συγγραφή
απλοποιηµένου και ενορχηστρωµένου κώδικα µειώνουν την
αποτελεσµατικότητα χρήσης των πόρων του συστήµατος.
Μεταφερσιµότητα
κατά
Αποτελεσµατικότητας
Ένα µεταφέρσιµο λογισµικό είναι ανεξάρτητο από ένα
συγκεκριµένο σύστηµα και εκµεταλλεύεται µόνο εκείνες
τις δυνατότητες του συστήµατος που είναι κοινές σε όλα
τα συστήµατα. ∆ε χρησιµοποιεί τα όποια ιδιαίτερα χαρα-
κτηριστικά παρέχει το σύστηµα και τα οποία ενισχύουν
την αποτελεσµατικότητα της εκτέλεσής του.
Ευελιξία
κατά
Αποτελεσµατικότητας
Η γενικότητα στη σχεδίαση, η οποία οδηγεί στην ευελιξία,
µειώνει την αποτελεσµατικότητα εφαρµογής του λογισµι-
κού σε συγκεκριµένες απαιτήσεις.
Επαναχρησιµοποιησι-
µότητα κατά Αποτε-
λεσµατικότητας
Η σχεδίαση για επαναχρησιµοποίηση δεν εκµεταλλεύεται
τις ιδιαίτερες ικανότητες ενός συγκεκριµένου συστήµατος
λογισµικού.
∆ιαλειτουργισιµότητα
κατά
Αποτελεσµατικότητας
Ο κώδικας που εκτελεί τη µετατροπή δεδοµένων, ώστε να
είναι δυνατή η διασύνδεση του λογισµικού µε άλλα
συστήµατα επιβαρύνει την εκτέλεση του λογισµικού.
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 158
7.2 ¢È·‰Èηۛ· ÂÍ·ÛÊ¿ÏÈÛ˘ ÔÈfiÙËÙ·˜
Η Εξασφάλιση της Ποιότητας του Λογισµικού – ΕΠΛ (Software Quality
Assurance – SQA) ορίζεται από την ΙΕΕΕ (ΙΕΕΕ[83]) ως «ένα προδιαγραµµένο και
συστηµατικό σύνολο ενεργειών, οι οποίες είναι απαραίτητες για την παροχή επαρ-
κούς εµπιστοσύνης στο ότι ένα σύστηµα λογισµικού είναι σύµφωνο µε όλες τις προ-
διαγραφές που σχετίζονται µε αυτό».
Η ΕΠΛ είναι ευθύνη ολόκληρης της οµάδας ανάπτυξης του λογισµικού, αφού περι-
λαµβάνει δραστηριότητες που πρέπει να εκτελούνται καθ’όλη τη διάρκεια του
κύκλου ανάπτυξης του λογισµικού, όπως:
• Μεθοδολογίες και εργαλεία ανάλυσης, σχεδίασης, υλοποίησης και ελέγχου
• Την εκτέλεση τεχνικών επισκοπήσεων και επιθεωρήσεων σε κάθε βήµα ανάπτυξης
• Μια πολυεπίπεδη στρατηγική ελέγχου
• Τον έλεγχο της τεκµηρίωσης του λογισµικού και των τροποποιήσεων που αυτή
υφίσταται
• Μια µεθοδολογία που διασφαλίζει τη συµβατότητα µε διεθνή πρότυπα ανάπτυ-
ξης λογισµικού
• Μηχανισµούς µέτρησης και δηµιουργίας αναφορών
1 5 9 7 . 2 ¢ π ∞ ¢ π ∫ ∞ ™ π ∞ ∂ •∞ ™ º∞ § π ™ ∏™ ¶√π √∆ ∏∆∞ ™
Ευελιξία
κατά Ακεραιότητας
Η γενικευµένη σχεδίαση και ανάπτυξη µειώνει την αποτε-
λεσµατικότητα των µηχανισµών ασφάλειας που υλοποιεί.
Επαναχρησιµοποιησι-
µότητα κατά Ακεραι-
ότητας
Η δυνατότητα επαναχρησιµοποίησης λογισµικού σε δια-
φορετικά συστήµατα απαιτεί την υλοποίηση γενικευµέ-
νων µηχανισµών ασφάλειας, των οποίων η αποτελεσµα-
τικότητα είναι µειωµένη.
∆ιαλειτουργισιµότητα
κατά Ακεραιότητας
Η διασύνδεση συστηµάτων συνήθως αφήνει αρκετές
«ανοιχτές» πόρτες για µη εξουσιοδοτηµένη πρόσβαση.
Επαναχρησιµοποιησι-
µότητα κατά
Αξιοπιστίας
Ένα λογισµικό που έχει αναπτυχθεί για «όλες τις περι-
πτώσεις» συνήθως έχει µειωµένη αντοχή σε λάθη και
περιορισµένη ακρίβεια.
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 159
1 6 0 K E ºA § A I O 7 : ∂ •∞ ™ º∞ § π ™ ∏ ¶√π √∆ ∏∆∞ ™ & A •π √¶π ™ ∆ π ∞ ™
Η εφαρµογή διαδικασιών ΕΠΛ πρέπει να ξεκινά από τις αρχικές φάσεις του κύκλου
ανάπτυξης και να συνεχίζεται µέχρι την απόσυρση του λογισµικού. Ο λόγος είναι
ότι σε κάθε φάση και δραστηριότητα του κύκλου ανάπτυξης παρουσιάζονται «ευκαι-
ρίες» ικανές να οδηγήσουν στην ανάπτυξη προϊόντων κακής ποιότητας. Τίποτα δεν
µας «εγγυάται» ότι από απαιτήσεις ποιότητας θα παραχθούν προδιαγραφές ίσης ποι-
ότητας. Ακόµη και αν χρησιµοποιηθούν προδιαγραφές καλής ποιότητας, δεν εξα-
σφαλίζουµε ότι και η σχεδίαση ή ο κώδικας θα είναι καλής ποιότητας.
Από την άλλη πλευρά, εάν επιτρέψουµε την παραγωγή προδιαγραφών χαµηλής ποι-
ότητας, τότε σίγουρα η σχεδίαση θα είναι το ίδιο κακής ή και χειρότερης ποιότητας.
Η ποιότητα της κωδικοποίησης θα είναι επίσης επικίνδυνα χαµηλή, µε αποτέλεσµα
το προϊόν που θα παραχθεί να είναι πολύ κακής ποιότητας. Και το χειρότερο: όσο
πιο νωρίς στον κύκλο ανάπτυξης βρίσκεται η αιτία της κακής ποιότητας, τόσο δυσκο-
λότερη (έως αδύνατη) γίνεται η βελτίωση του λογισµικού.
7.2.1 √Ì¿‰· ÂÍ·ÛÊ¿ÏÈÛ˘ Ù˘ ÔÈfiÙËÙ·˜
Κύριος υπεύθυνος για την ΕΠΛ σε ένα έργο λογισµικού είναι ο διαχειριστής (υπεύ-
θυνος) του έργου. Παρόλο που όλα τα µέλη της οµάδας ανάπτυξης του λογισµικού
θα χρειαστεί να συµµετάσχουν σε διαδικασίες ΕΠΛ, αποτελεί αρµοδιότητα και κύριο
καθήκον του διαχειριστή να λάβει όλα τα απαραίτητα µέτρα για να διασφαλίσει την
ποιότητα του λογισµικού.
Υπάρχουν τρεις βασικοί λόγοι που δυσκολεύουν την εξασφάλιση της ποιότητας του
λογισµικού:
• ∆εν έχει δοθεί ακόµη ένας καθολικά αποδεκτός ορισµός της ποιότητας λογισµικού.
• ∆εν έχει βρεθεί ακόµη µια αποτελεσµατική τεχνική για την εξασφάλιση της ποι-
ότητας σε ένα λογισµικό.
• ∆εν έχει ακόµη περιγραφεί ένας αποτελεσµατικός τρόπος µέτρησης της ποιότη-
τας των συστηµάτων λογισµικού.
Στην προσπάθεια αυτή ο διαχειριστής µπορεί να βοηθηθεί αποτελεσµατικά από την
Έχοντας µελετήσει όσα αναφέρθηκαν έως τώρα, δοκιµάστε να εξηγήσετε σε 10 –
15 γραµµές, γιατί η ποιότητα δεν µπορεί εκ των υστέρων να «προστεθεί» σε ένα
λογισµικό. Έπειτα µελετήστε και τη δική µας εξήγηση.
¢Ú·ÛÙËÚÈfiÙËÙ· 7.3
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 160
οµάδας εξασφάλισης ποιότητας. Σε κάθε έργο λογισµικού συνήθως συγκροτείται µια
τέτοια οµάδα µε καθήκοντα όπως τα ακόλουθα τα ακόλουθα:
• Πρόσθεση στο έγγραφο απαιτήσεων του λογισµικού της µη λειτουργικής απαί-
τησης για «την εξασφάλιση της ποιότητας του λογισµικού». Έτσι, στα επόµενα
στάδια του κύκλου ανάπτυξης, θα είναι δυνατό να αναπτυχθούν προδιαγραφές
και να γραφεί κώδικας για την ικανοποίηση της απαίτησης αυτής.
• Επιλογή των παραγόντων που καθορίζουν την ποιότητα στο συγκεκριµένο υπό
ανάπτυξη λογισµικό, καθορισµός των µηχανισµών µε τους οποίους οι παράγο-
ντες αυτοί θα ενσωµατωθούν στο λογισµικό και προδιαγραφή των µετρικών µε
τις οποίες θα αξιολογηθεί ο βαθµός της ποιότητας.
• Σύνταξη του εγγράφου «Πλάνο ΕΠΛ» µε τη δοµή που περιγράφεται στην υπο –
ενότητα 7.2.2.
• Επιτήρηση της εφαρµογής των οδηγιών που περιέχονται στο Πλάνο ΕΠΛ και
ενεργή συµµετοχή σε όλα τα ζητήµατα που άπτονται της ΕΠΛ.
¶·Ú¿‰ÂÈÁÌ· 7.1
Ας εξετάσουµε τους σηµαντικούς παράγοντες ποιότητας για ένα λογισµικό ελέγχου
της εναέριας κυκλοφορίας. Ο σηµαντικότερος παράγων ποιότητας στην περίπτωση
αυτή είναι η ορθότητα του λογισµικού, καθώς οποιαδήποτε αστοχία ή σφάλµα λει-
τουργίας µπορεί να προκαλέσει «καταστροφή». Κατά την ανάπτυξη του λογισµικού,
ο διαχειριστής του έργου µπορεί:
• Nα αποφασίσει να χρησιµοποιήσει τυπικές µεθόδους προδιαγραφής και εγκυρο-
ποίησης του λογισµικού,
• Nα διαθέσει περισσότερους πόρους (χρόνο, προσωπικό, εξοπλισµό κ.λπ.) στις
διαδικασίες εγκυροποίησης του λογισµικού από αυτούς που διατίθενται σε ένα
συνηθισµένο έργο.
1 6 1 7 . 2 ¢ π ∞ ¢ π ∫ ∞ ™ π ∞ ∂ •∞ ™ º∞ § π ™ ∏™ ¶√π √∆ ∏∆∞ ™
Αφού µελετήσετε το Παράδειγµα 1, προσπαθήστε να περιγράψετε το σηµαντικό-
τερο παράγοντα ποιότητας για ένα περιβάλλον εκπαίδευσης από απόσταση για το
αντικείµενο της πληροφορικής. Η εταιρεία που το αναπτύσσει στοχεύει να ανα-
πτύξει πολλά παρόµοια συστήµατα για διαφορετικά γνωστικά πεδία, καθώς και για
χρήστες µε διαφορετικές δυνατότητες επεξεργασίας και επικοινωνίας µέσω δικτύ-
ου. Μια ενδεικτική απάντηση ακολουθεί.
¢Ú·ÛÙËÚÈfiÙËÙ· 7.4
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 161
1 6 2 K E ºA § A I O 7 : ∂ •∞ ™ º∞ § π ™ ∏ ¶√π √∆ ∏∆∞ ™ & A •π √¶π ™ ∆ π ∞ ™
Το συγκεκριµένο σύστηµα πρέπει να παρουσιάζει υψηλό βαθµό επαναχρησιµοποι-
ησιµότητας, καθώς το µεγαλύτερο µέρος του θα χρησιµοποιηθεί αναλλοίωτο στα
επόµενα συστήµατα, ώστε η εταιρεία να εξοικονοµήσει όσο το δυνατό περισσότε-
ρους πόρους.
Ο διαχειριστής του έργου, λοιπόν, είναι αναµενόµενο να αποφασίσει ότι η «επανα-
χρησιµοποιησιµότητα» είναι ο σηµαντικότερος παράγων ποιότητας και να οδηγηθεί:
• Στην υιοθέτηση µιας αντικειµενοστραφούς µεθοδολογίας σχεδίασης του συστή-
µατος.
• Στην απαίτηση για εφαρµογή αυστηρών κανόνων κατά την ανάπτυξη του λογι-
σµικού, οι οποίοι κάνουν τον κώδικα ευανάγνωστο και διευκολύνουν το έργο των
νέων προγραµµατιστών.
7.2.2 ∆Ô Û‡ÛÙËÌ· ‰È·¯Â›ÚÈÛ˘ Ù˘ ÔÈfiÙËÙ·˜
Το σύστηµα διαχείρισης της ποιότητας περιλαµβάνει τη διοικητική δοµή, τις ευθύ-
νες, τις ικανότητες, τις ενέργειες και τους πόρους που διασφαλίζουν ότι τα προϊόντα
λογισµικού ενσωµατώνουν τους επιθυµητούς παράγοντες ποιότητας. Στο Σχήµα 7.2
φαίνεται η δοµή ενός σύγχρονου συστήµατος διαχείρισης της ποιότητας, το οποίο
περιλαµβάνει ενέργειες όπως:
• τον τακτικό έλεγχο των έργων ανάπτυξης λογισµικού για να βεβαιωθεί ότι έχουν
εκτελεστεί σωστά οι ενέργειες εκείνες που διασφαλίζουν την παρουσία των παρα-
γόντων ποιότητας,
• την αναθεώρηση του συστήµατος ποιότητας µε στόχο τη βελτίωσή του, ώστε να
ικανοποιεί τις προκύπτουσες απαιτήσεις της αγοράς και να ενσωµατώνει τις
τεχνολογικές εξελίξεις,
• την υποστήριξη της συνεχούς επιµόρφωσης των µελών της οµάδας ποιότητας,
• τη διαπραγµάτευση για τη διάθεση των πόρων που απαιτούν οι δραστηριότητες
ΕΠΛ,
• την ανάπτυξη προτύπων και διαδικασιών ελέγχου της εφαρµογής αυτών,
• την παραγωγή αναφορών για τη διοίκηση του έργου.
Οι λεπτοµέρειες του συστήµατος διαχείρισης της ποιότητας αναφέρονται στο εγχει-
ρίδιο ποιότητας, το οποίο περιέχει πρότυπα, διαδικασίες και οδηγίες για την εφαρ-
µογή της ποιότητας. Το εγχειρίδιο ποιότητας είναι συνήθως επηρεασµένο από διε-
θνώς αποδεκτά πρότυπα ποιότητας, όπως το ISO9001.
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 162
7.2.3 ¶Ï¿ÓÔ ∂¶§
Το Πλάνο ΕΠΛ είναι ένα από τα σηµαντικότερα έγγραφα που παράγονται κατά τη
διάρκεια ενός έργου λογισµικού. Η σύνταξή του γίνεται νωρίς, ώστε να είναι διαθέ-
σιµο σε όλες τις φάσεις του κύκλου ανάπτυξης, των οποίων αποτελεί σηµείο ανα-
φοράς. Στον Πίνακα 7.3 περιγράφονται τα ελάχιστα έγγραφα που απαιτούνται για
την ΕΠΛ, σύµφωνα µε το πρότυπο που έχει θεσπίσει η ΙΕΕΕ (ΙΕΕΕ[84], ΙΕΕΕ[86]).
1 6 3 7 . 2 ¢ π ∞ ¢ π ∫ ∞ ™ π ∞ ∂ •∞ ™ º∞ § π ™ ∏™ ¶√π √∆ ∏∆∞ ™
Ανατρέξτε στη βιβλιοθήκη του ΕΑΠ (ή σε οποιαδήποτε άλλη επιστηµονική βιβλιο-
θήκη), στο δικτυακό τόπο του International Standards Institute (www.iso.org) ή σε
αυτόν του British Standards Institute (www.bsi.uk.org) και αναζητήστε πληροφο-
ρίες για τη δοµή και τα περιεχόµενα του προτύπου 9001.
¢Ú·ÛÙËÚÈfiÙËÙ· 7.5
™¯‹Ì· 7.2
Ένα σύγχρονο
σύστηµα διαχείρι-
σης της ποιότητας
∆ιεθνή Πρότυπα (ISO 9001)
Παρέχουν Kαθοδήγηση στο
Σύστηµα ∆ιαχείρισης Ποιότητας
Έργο 1
Πλάνο 
Ποιότητας 
1
Έργο 2
Πλάνο 
Ποιότητας 
2
Έργο N
Πλάνο 
Ποιότητας 
N
Xρησιµοποιούνται 
Για Tην Aνάπτυξη
Πρότυπα ∆ιαδικασίες 
Έλεγχοι Ποιότητας
Eγχειρίδιο Eξασφάλισης της 
Ποιότητας

K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 163
1 6 4 K E ºA § A I O 7 : ∂ •∞ ™ º∞ § π ™ ∏ ¶√π √∆ ∏∆∞ ™ & A •π √¶π ™ ∆ π ∞ ™
Φάσεις Έγγραφα τεκµηρίωσης Αναθεωρήσεις και έλεγχοι
Απαιτήσεις Πλάνο Εξασφάλισης Ποιό-
τητας Λογισµικού
Έγγραφο Προδιαγραφών
Απαιτήσεων από το
Λογισµικό
Πλάνο Επαλήθευσης και
Επικύρωσης Λογισµικού
Αναθεώρηση εγγράφου Προ-
διαγραφών Απαιτήσεων
από το Λογισµικό
∆ειγµατοληπτικός έλεγχος
Αναθεώρηση πλάνου Επαλή-
θευσης και Επικύρωσης
Λογισµικού
∆ιοικητική αναθεώρηση
Σχεδίαση Προκαταρκτικό Έγγραφο
Περιγραφής Σχεδίου
Λογισµικού
Έγγραφο Περιγραφής Σχεδί-
ου Λογισµικού
Τεκµηρίωση χρήστη
Αναθεώρηση προκαταρκτι-
κού εγγράφου Περιγρα-
φής Σχεδίου Λογισµικού
∆ειγµατοληπτικός έλεγχος
Αναθεώρηση εγγράφου
Περιγραφής Σχεδίου
Λογισµικού
Αναθεώρηση τεκµηρίωσης
χρήστη
Κωδικοποίηση Κώδικας
Τεκµηρίωση κώδικα
∆ειγµατοληπτικός έλεγχος
Έλεγχος Τεκµηρίωση ελέγχου Λειτουργικός έλεγχος
Εγκατάσταση Παραδοτέα αντικείµενα
Έκθεση Επαλήθευσης και
Επικύρωσης Λογισµικού
Φυσικός έλεγχος
¶›Ó·Î·˜ 7.3
Ελάχιστα έγγραφα τεκµηρίωσης και ελάχιστοι έλεγχοι για την ΕΠΛ σύµφωνα µε το
πρότυπο ΙΕΕΕ (Σκορδαλάκης[91])
Το Πλάνο ΕΠΛ δεν περιλαµβάνει µόνο τα έγγραφα και τις διαδικασίες που είναι
απαραίτητες για τη διασφάλιση της ποιότητας στο συγκεκριµένο έργο, αλλά και ένα
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 164
κατάλογο ελέγχων ποιότητας. Ο έλεγχος ποιότητας είναι µια διαδικασία που εκτε-
λείται για να εξασφαλίσει ότι κάποιος παράγοντας ποιότητας έχει ληφθεί υπόψη στο
σύστηµα και την τεκµηρίωσή του. Παραδείγµατα ελέγχων ποιότητας είναι η περιή-
γηση ενός τµήµατος κώδικα, ο έλεγχος αποδοχής µιας λειτουργίας, µια αναφορά
ελέγχου για την υιοθέτηση προτύπων κ.ά.
7.3 ∆˘ÈΤ˜ Ù¯ÓÈΤ˜ ∂¶§
Τα τελευταία χρόνια αρχίζει να κερδίζει έδαφος ανάµεσα στους µηχανικούς λογι-
σµικού η άποψη ότι οι διαδικασίες ΕΠΛ που έχουν περιγραφεί στις ενότητες 7.1 και
7.2 πρέπει να συµπληρωθούν µε τυπικές τεχνικές ΕΠΛ. Η ενσωµάτωση τυπικών
τεχνικών συνήθως παρουσιάζει υψηλό αρχικό κόστος, καθώς απαιτεί την αλλαγή
των παγιωµένων διαδικασιών και την εκπαίδευση του προσωπικού στη χρήση εξει-
δικευµένων εργαλείων, αλλά αποδίδει στη συνέχεια, αφού οδηγεί στην έγκαιρη ανα-
κάλυψη των περισσότερων ελαττωµάτων. Υπάρχουν στη βιβλιογραφία περιπτώσεις
όπου, µε τη χρήση τυπικών τεχνικών ΕΠΛ, περισσότερο από το 90% των ελαττω-
µάτων ενός συστήµατος ανακαλύφθηκαν πριν καν αρχίσουν οι δοκιµές του.
7.3.1 ∞fi‰ÂÈÍË ÔÚıfiÙËÙ·˜
Οι τεχνικές αυτής της κατηγορίας θεωρούν ένα πρόγραµµα ως µια ακολουθία εντο-
λών που υλοποιεί µια συγκεκριµένη λειτουργία. Σε διάφορα σηµεία s
1
, s
2
, …, s
n
της
ακολουθίας, ο σχεδιαστής µπορεί να εισάγει «ισχυρισµούς» c
1
, c
2
, …, c
n
σχετικά µε
τις τιµές µεταβλητών ή συνθηκών.
Ο σχεδιαστής πρέπει να αποδείξει, µε βάση τις προδιαγραφές, ότι οι ισχυρισµοί αυτοί
είναι ορθοί. Τότε, οι εντολές ανάµεσα στις s
n
και s
n + 1
είναι σωστές, εάν προκαλούν
τη µετατροπή του (ορθού) ισχυρισµού c
n
στον (επίσης ορθό) ισχυρισµό c
n + 1
.
Γενικεύοντας, µπορεί να αποδειχθεί η ορθότητα ολόκληρου του προγράµµατος, θεω-
ρώντας ότι πρέπει η εφαρµογή του στα δεδοµένα εισόδου να οδηγήσει στους ισχυ-
ρισµούς εξόδου. Με ανάλογο τρόπο δείχνεται και η αντιστοιχία ανάµεσα στις τυπι-
κές προδιαγραφές του προγράµµατος και το ίδιο το πρόγραµµα.
7.3.2 ™Ù·ÙÈÛÙÈ΋ ∂¶§
Η στατιστική ΕΠΛ αποτελεί µια πρόσφατη εξέλιξη, η οποία µπορεί να οδηγήσει στην
ποσοτικοποίηση των αποτελεσµάτων της ΕΠΛ. Περιλαµβάνει τα ακόλουθα βήµατα:
• Συλλογή και κατηγοριοποίηση πληροφοριών για τα σφάλµατα του λογισµικού.
• Σύνδεση του κάθε σφάλµατος µε τα ελαττώµατα που το προκαλούν.
1 6 5 7 . 3 ∆ À ¶π ∫ ∂ ™ ∆ ∂ à ¡π ∫ ∂ ™ ∂ ¶§
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 165
1 6 6 K E ºA § A I O 7 : ∂ •∞ ™ º∞ § π ™ ∏ ¶√π √∆ ∏∆∞ ™ & A •π √¶π ™ ∆ π ∞ ™
• Χρησιµοποιώντας την αρχή ότι «το 80% των σφαλµάτων οφείλεται στο 20% των
ελαττωµάτων», αποµόνωση του «κρίσιµου 20%».
• ∆ιόρθωση των λίγων κρίσιµων ελαττωµάτων.
Η τεχνική της στατιστικής ΕΠΛ µπορεί να συνοψισθεί στην ακόλουθη οδηγία: ανα-
λώστε το χρόνο σας µόνο στα ζητήµατα που έχουν πραγµατικά σηµασία, αφού πρώτα
βεβαιωθείτε ότι έχετε καταλάβει ποια ζητήµατα έχουν πραγµατικά σηµασία!
7.3.3 ∏ ‰È·‰Èηۛ· ÙÔ˘ «Î·ı·ÚÔ‡ ‰ˆÌ·Ù›Ô˘»
Η διαδικασία του «καθαρού δωµατίου» (cleanroom process) συνδυάζει την τυπι-
κή επαλήθευση µε τη στατιστική ΕΠΛ. Η τεχνική αυτή δίνει προτεραιότητα στην
πρόληψη της εµφάνισης των ελαττωµάτων αντί να βασίζεται στη µετέπειτα αποµά-
κρυνσή τους (βέβαια, όσα ελαττώµατα ανακαλυφθούν, θα αποµακρυνθούν).
Αυτό επιτυγχάνεται µε τη χρήση τυπικών τεχνικών εγκυροποίησης, αντί της εκσφαλ-
µάτωσης του κώδικα, πριν τον έλεγχο του λογισµικού. Στη συνέχεια, καταγράφει το
µέσο χρόνο µέχρι την εµφάνιση του πρώτου σφάλµατος για να εγγυηθεί στατιστικά
την ποιότητα του λογισµικού.
Προσπαθήστε να αντιστοιχίσετε καθεµία τυπική τεχνική ΕΠΛ (από την αριστερή
στήλη) µε τη βασική της δραστηριότητα (από τη δεξιά στήλη):
Τυπική τεχνική ΕΠΛ ∆ραστηριότητα
Απόδειξη ορθότητας Πρόληψη ελαττωµάτων
Στατιστική ΕΠΛ Απόδειξη ορθότητας ισχυρισµών
∆ιαδικασία «καθαρού δωµατίου» Εντοπισµός και διόρθωση των κρίσιµων
ελαττωµάτων
ÕÛÎËÛË ·˘ÙÔ·ÍÈÔÏfiÁËÛ˘ 7.1
7.4 ∞ÍÈÔÈÛÙ›· ÏÔÁÈÛÌÈÎÔ‡
Η αξιοπιστία του λογισµικού (software reliability) είναι ένας από τους σηµαντικό-
τερους παράγοντες ποιότητας. Επιπλέον, η αξιοπιστία µπορεί να µετρηθεί άµεσα και
να εκτιµηθεί χρησιµοποιώντας δεδοµένα που έχουν συλλεχθεί κατά την ανάπτυξη
του λογισµικού. Στατιστικά, η αξιοπιστία ορίζεται ως «η πιθανότητα της χωρίς σφάλ-
µατα λειτουργίας του λογισµικού σε ένα καθορισµένο περιβάλλον για ένα καθορι-
σµένο χρονικό διάστηµα».
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 166
Συνεπώς, µέτρο της αξιοπιστίας αποτελεί ο «µέσος χρόνος ανάµεσα στην εµφάνι-
ση σφαλµάτων» (mean time between failure – MTBF), ο οποίος ορίζεται ως
MTBF = MTTF + MTTR, όπου
• MTTF (mean time to failure) είναι ο µέσος χρόνος µέχρι την εµφάνιση σφάλµατος,
• MTTR (mean time to repair) είναι ο µέσος χρόνος που απαιτείται για τη διόρθω-
ση του σφάλµατος.
Η µέτρηση της αξιοπιστίας µε τον τρόπο αυτό είναι πολύ πιο χρήσιµη από τη µέτρη-
ση των ελαττωµάτων ανά 1000 γραµµές κώδικα (KLOC): Eπειδή κάθε ελάττωµα που
περιέχεται στο πρόγραµµα δεν προκαλεί τον ίδιο ρυθµό εµφάνισης σφαλµάτων, η απλή
µέτρηση των λαθών µπορεί να οδηγήσει σε λανθασµένη εκτίµηση της αξιοπιστίας.
Με βάση αυτό το µέτρο αξιοπιστίας µπορεί να οριστεί και η διαθεσιµότητα του
συστήµατος, ως εξής:
∆ιαθεσιµότητα = 100% * MTTF / (MTTF + MTTR)
¶·Ú¿‰ÂÈÁÌ· 7.2
Έστω ότι η αξιοπιστία ενός προγράµµατος Χ (το οποίο εκτελείται συνεχώς επί 12
ώρες) είναι 0,90. Στατιστικά, αυτό σηµαίνει ότι, εάν το πρόγραµµα χρειασθεί 12 ώρες
για να εκτελεσθεί 100 φορές, υπάρχει πιθανότητα να εµφανίσει σφάλµα εκτέλεσης
στις 10 από τις 100 φορές.
1 6 7 7 . 4 ∞ •π √¶π ™ ∆ π ∞ § √° π ™ ªπ ∫ √À
Έστω ότι τις τελευταίες 2 ώρες ελέγχετε την αξιοπιστία της εκτέλεσης ενός υπο-
προγράµµατος Α. Η εντολή κλήσης του Α βρίσκεται στο κυρίως πρόγραµµα. Έχετε
εκτελέσει το Α 5 φορές, µε συνολικό χρόνο επεξεργασίας 1 ώρα και 20 λεπτά.
Μετά την εντολή κλήσης του, εµφανίστηκε σφάλµα µετά από χρόνο t sec, όπου t
∈ {20, 40, 40, 60, 90}. Για καθένα από τα σφάλµατα αυτά απαιτήθηκε χρόνος επι-
διόρθωσης T min, όπου Τ ∈ {7, 6, 12, 6, 9}. ∆οκιµάστε να υπολογίσετε την αξιο-
πιστία και τη διαθεσιµότητα του Α.
ÕÛÎËÛË ·˘ÙÔ·ÍÈÔÏfiÁËÛ˘ 7.2
7.4.1 ¢È·ÎÔ‹ ÏÂÈÙÔ˘ÚÁ›·˜ Î·È ÂȉÈfiÚıˆÛË
Η διαθεσιµότητα ενός συστήµατος σχετίζεται µε τις έννοιες του χρόνου διακοπής
λειτουργίας (downtime) και της επιδιόρθωσης (repair) του συστήµατος. Ο χρόνος
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 167
1 6 8 K E ºA § A I O 7 : ∂ •∞ ™ º∞ § π ™ ∏ ¶√π √∆ ∏∆∞ ™ & A •π √¶π ™ ∆ π ∞ ™
διακοπής λειτουργίας περιλαµβάνει το χρονικό διάστηµα κατά το οποίο το σύστη-
µα δεν είναι διαθέσιµο λόγω ενός σφάλµατος, αλλά και το χρόνο που διαρκεί η επι-
διόρθωση του σφάλµατος.
Σε πολλά συστήµατα είναι ανεκτός ένας µικρός χρόνος διακοπής (βέβαια, ο µικρός
χρόνος διακοπής ορίζεται διαφορετικά για ένα σύστηµα ελέγχου εναέριας κυκλο-
φορίας και για ένα σύστηµα καταχώρησης βαθµολογιών των φοιτητών του ΕΑΠ).
O στόχος της οµάδας ανάπτυξης είναι να µειώσει στο ελάχιστο το χρόνο διακοπής
λειτουργίας, ρυθµίζοντας τους παράγοντες που τον επηρεάζουν (ο χρόνος διακοπής
λειτουργίας δε µηδενίζεται ποτέ).
Ο συνολικός χρόνος επιδιόρθωσης περιλαµβάνει τη διάγνωση του σφάλµατος, τον
εντοπισµό του ελαττώµατος, τη διόρθωση του ελαττώµατος, τον έλεγχο του διορθω-
µένου λογισµικού και την επανεκκίνηση του συστήµατος. Πολλές φορές, πριν επι-
χειρήσουµε τον εντοπισµό και τη διόρθωση του ελαττώµατος, δοκιµάζουµε απλά να
επανεκκινήσουµε το σύστηµα, ελπίζοντας ότι το σφάλµα δεν θα εµφανιστεί ξανά. Ο
χρόνος επιδιόρθωσης είναι µια τυχαία µεταβλητή. Στα απλούστερα µοντέλα αξιοπι-
στίας χρησιµοποιείται αντί αυτής ο µέσος χρόνος επιδιόρθωσης ή ο ρυθµός αστοχίας.
7.4.2 ªÔÓ٤Ϸ ·ÍÈÔÈÛÙ›·˜ ÏÔÁÈÛÌÈÎÔ‡
Τα µοντέλα αξιοπιστίας λογισµικού εφαρµόζονται για τρεις κυρίως λόγους: πρό-
βλεψη, συγκριτική ανάλυση και έλεγχο της διαδικασίας ανάπτυξης. Η πρόβλεψη της
αξιοπιστίας του λογισµικού πρέπει να γίνει κατά τη διάρκεια της καταγραφής των
απαιτήσεων, καθώς πολλές φορές, ο µηχανικός λογισµικού πρέπει να εγγυηθεί στους
χρήστες έναν ελάχιστο χρόνο λειτουργίας του λογισµικού χωρίς αστοχία. Τα µοντέ-
λα αξιοπιστίας εφαρµόζονται και κατά τη διάρκεια της σχεδίασης του λογισµικού,
καθώς η αξιοπιστία του τελικού προϊόντος (θα πρέπει να) είναι ένας σηµαντικός
παράγοντας για την επιλογή ανάµεσα σε εναλλακτικά σχέδια. Τέλος, κατά τη διαδι-
κασία ανάπτυξης του λογισµικού, η σύγκριση των αποτελεσµάτων που έδωσαν οι
έλεγχοι του λογισµικού µε το µοντέλο αξιοπιστίας αποτελεί σοβαρή ένδειξη του στα-
δίου ανάπτυξης. Από την ίδια σύγκριση είναι δυνατή και η εκτίµηση του απαιτού-
µενου χρόνου εκσφαλµάτωσης µέχρι να φτάσει το λογισµικό σε ένα αποδεκτό επί-
πεδο αξιοπιστίας.
Τα τελευταία 30 χρόνια έχει αναπτυχθεί ένας σηµαντικός αριθµός µοντέλων αξιοπι-
στίας, τα οποία χρησιµοποιούν στοιχεία από τη θεωρία των πιθανοτήτων και χρησι-
µοποιούν δεδοµένα που προέρχονται από τον έλεγχο παρόµοιων συστηµάτων λογι-
σµικού (Shooman[83]). Στα µοντέλα αυτά, ορίζεται πρώτα η τυχαία µεταβλητή που
θα µελετηθεί. Ανάλογα µε τη µεταβλητή που θα οριστεί, έχουµε:
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 168
• Τα µοντέλα εµφάνισης σφαλµάτων, όπου η τυχαία µεταβλητή είναι ο αριθµός
των ελαττωµάτων σε ένα πρόγραµµα,
• Τα µοντέλα αξιοπιστίας, όπου η τυχαία µεταβλητή είναι ο χρόνος µέχρι την αστο-
χία του λογισµικού.
Μοντέλα εµφάνισης σφαλµάτων
Τα µοντέλα αυτά επιχειρούν να εκτιµήσουν τον αριθµό των σφαλµάτων που απο-
µένουν σε ένα πρόγραµµα, καθώς µια τέτοια εκτίµηση αποτελεί µέτρο της προόδου
της διαδικασίας ανάπτυξης. Βασίζονται στις εξής δύο υποθέσεις:
• Ο κανονικοποιηµένος αριθµός των ελαττωµάτων που βρίσκονται σε παρόµοια
συστήµατα λογισµικού είναι κατά προσέγγιση σταθερός. Ο κανονικοποιηµένος
αριθµός των ελαττωµάτων προκύπτει διαιρώντας το συνολικό αριθµό ελαττω-
µάτων Ε
Τ
µε το πλήθος των εντολών του προγράµµατος Ι
Τ
, µε την προϋπόθεση
ότι οι γλώσσες προγραµµατισµού είναι συγκρίσιµες. Λέγοντας «κατά προσέγγι-
ση σταθερός» εννοούµε ότι αρχικά µας είναι αρκετή µια «χονδρική» εκτίµηση
του αριθµού των ελαττωµάτων (π.χ. µε ακρίβεια 50%), η οποία θα γίνεται περισ-
σότερο ακριβής κατά τη σταδιακή εφαρµογή του µοντέλου (έχετε υπόψη σας ότι
ο αριθµός των ελαττωµάτων αποτελεί µια παράµετρο ενός στοχαστικού µοντέ-
λου, όχι µια φυσική σταθερή). Για να ορίσουµε την «οµοιότητα» δύο προγραµ-
µάτων πρέπει να θεωρήσουµε ότι οι δύο οµάδες ανάπτυξης έφεραν συγκρίσιµο
«µείγµα ικανοτήτων», ότι χρησιµοποιήθηκαν παρόµοιες τεχνικές ελέγχου του
λογισµικού, ότι κατά την ανάπτυξη των δύο προγραµµάτων υιοθετήθηκαν παρό-
µοιες µεθοδολογίες, ενώ η ανάπτυξη βρίσκεται στο ίδιο στάδιο, κ.ά.
• Ο κανονικοποιηµένος ρυθµός εκκαθάρισης λαθών σε παρόµοια συστήµατα λογι-
σµικού είναι κατά προσέγγιση σταθερός. Ο κανονικοποιηµένος ρυθµός εκκαθά-
ρισης λαθών προκύπτει διαιρώντας το ρυθµό εκκαθάρισης λαθών r
T
µε το πλή-
θος των εντολών του προγράµµατος Ι
Τ.
Στην περίπτωση αυτή πρέπει να προσθέ-
σουµε δύο προϋποθέσεις οµοιότητας δύο συστηµάτων: (α) η σύνθεση, οι ικανό-
τητες και ο χρόνος απασχόλησης των οµάδων ανάπτυξης και ελέγχου είναι παρό-
µοιες για τα δύο συστήµατα και (β) η ένταση και ο χρόνος ελέγχου στη µονάδα
χρόνου είναι συγκρίσιµοι για τα δύο συστήµατα.
Χρησιµοποιώντας δεδοµένα που έχουν συλλεχθεί κατά την ανάπτυξη παρόµοιων
προγραµµάτων, µπορούµε, µε βάση τις δύο αυτές υποθέσεις, να εκτιµήσουµε τον
αριθµό των σφαλµάτων που αποµένουν και στο πρόγραµµα που ελέγχουµε. Η βασι-
κή ποσότητα, η οποία εµφανίζεται σε όλους τους υπολογισµούς, είναι ο συνολικός
1 6 9 7 . 4 ∞ •π √¶π ™ ∆ π ∞ § √° π ™ ªπ ∫ √À
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 169
1 7 0 K E ºA § A I O 7 : ∂ •∞ ™ º∞ § π ™ ∏ ¶√π √∆ ∏∆∞ ™ & A •π √¶π ™ ∆ π ∞ ™
αριθµός ελαττωµάτων Ε
Τ.
Για την εκτίµηση της ποσότητας αυτής κατά τη διάρκεια
του ελέγχου του λογισµικού έχουν αναπτυχθεί ειδικά µοντέλα, όπως τα ακόλουθα:
• Μοντέλα εισαγωγής ελαττωµάτων, σύµφωνα µε τα οποία, ένας αριθµός Κ γνω-
στών ελαττωµάτων εισάγεται στο λογισµικό. Κατά τον έλεγχο, η πιθανότητα
εντοπισµού m άγνωστων (πραγµατικών) ελαττωµάτων από τα συνολικά Μπραγ-
µατικά ελαττώµατα µπορεί να συσχετιστεί µε την πιθανότητα ανακάλυψης k από
τα Κ γνωστά ελαττώµατα που έχουν εισαχθεί στον κώδικα,
• Μοντέλα παλινδρόµησης, τα οποία σχεδιάζουν µια γραφική παράσταση των έως
τώρα δεδοµένων του ελέγχου, την οποία ανάγουν σε µια από τις γνωστές καµπύ-
λες, µε βάση την οποία επιχειρούν να προβλέψουν την µελλοντική πορεία της
εκσφαλµάτωσης.
Μοντέλα αξιοπιστίας
Έως τώρα χρησιµοποιούνται δύο προσεγγίσεις για τον ορισµό ενός µοντέλου αξιο-
πιστίας: η µακροσκοπική και η µικροσκοπική. Τα µοντέλα της πρώτης κατηγορίας
δε λαµβάνουν υπόψη τους τα ιδιαίτερα χαρακτηριστικά κάθε λογισµικού, αλλά εξε-
τάζουν τον αριθµό των εντολών, τον αριθµό των ελαττωµάτων που έχουν διορθω-
θεί κ.λπ. και βασίζονται σε δεδοµένα που προέρχονται από παρόµοια συστήµατα, τα
οποία είχαν αναπτυχθεί στο παρελθόν. Τα µικροσκοπικά µοντέλα βασίζονται σε
λεπτοµερειακή ανάλυση της δοµής ελέγχου και των εντολών του λογισµικού.
Τα µοντέλα αξιοπιστίας λογισµικού διακρίνονται σε αυτά που προβλέπουν την αξιο-
πιστία ως συνάρτηση ηµερολογιακού χρόνου και σε αυτά που την εκτιµούν ως
συνάρτηση χρόνου επεξεργασίας. Η εµπειρία έχει δείξει ότι τα µοντέλα της δεύτε-
ρης κατηγορίας δίνουν καλύτερα συνολικά αποτελέσµατα.
Τα περισσότερα από τα µέτρα και τα µοντέλα αξιοπιστίας λογισµικού που ανα-
φέρθηκαν στην ενότητα αυτή προέρχονται από τη θεωρία αξιοπιστίας του υλικού
(hardware reliability theory). Μπορείτε να εντοπίσετε το βασικό παράγοντα της
θεωρίας αξιοπιστίας υλικού, ο οποίος δεν εφαρµόζεται στη θεωρία αξιοπιστίας
λογισµικού; Προσέξτε: η άσκηση είναι δύσκολη! Πριν απαντήσετε, αναλογιστεί-
τε εκείνες τις βασικές διαφορές του υλικού από το λογισµικό, οι οποίες οφείλονται
στη «φύση» των δύο συστατικών του υπολογιστή.
ÕÛÎËÛË ·˘ÙÔ·ÍÈÔÏfiÁËÛ˘ 7.3
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 170
™‡ÓÔ„Ë
Στο κεφάλαιο αυτό µελετήσαµε το θέµα της ποιότητας του λογισµικού. ∆υστυχώς, για
ένα τόσο σηµαντικό θέµα, δεν υπάρχουν διαθέσιµα µοντέλα µέτρησης, ούτε µεθοδολο-
γίες εφαρµογής. Μοιραία λοιπόν, η εξασφάλιση της ποιότητας του λογισµικού αποτε-
λεί καθήκον του διαχειριστή του έργου, ο οποίος συνήθως συγκροτεί µια «οµάδα ποι-
ότητας». Οι αρµοδιότητες µιας τέτοιας οµάδας περιλαµβάνουν την εκπόνηση του πλά-
νου εξασφάλισης της ποιότητας και την επίβλεψη εφαρµογής των οδηγιών ποιότητας.
Η ποιότητα του λογισµικού περιγράφεται από ένδεκα παράγοντες ποιότητας, για την
ποσοτική εκτίµηση των οποίων χρησιµοποιούνται είκοσι µία µετρικές. Το επίπεδο
ενσωµάτωσης κάθε παράγοντα ποιότητας παράγεται ως ένα σταθµισµένο άθροισµα
των σχετιζόµενων µε αυτόν µετρικών. Βέβαια, δεν είναι δυνατή η βέλτιστη ενσωµά-
τωση όλων των παραγόντων ποιότητας στο ίδιο λογισµικό, καθώς αρκετοί από
αυτούς είναι αλληλοαναιρούµενοι. Συµπληρωµατικά µε την τεχνική που χρησιµοποιεί
µετρικές, η οµάδα ποιότητας µπορεί να χρησιµοποιήσει και κάποιες τυπικές τεχνικές
εξασφάλισης της ποιότητας.
Ο σηµαντικότερος από τους παράγοντες ποιότητας είναι η αξιοπιστία του λογισµι-
κού, η οποία µετρείται ως ο µέσος χρόνος ανάµεσα στην εµφάνιση σφαλµάτων. Η
αξιοπιστία του λογισµικού σχετίζεται µε το χρόνο διακοπής λειτουργίας και το χρόνο
επιδιόρθωσης και επηρεάζει τη διαθεσιµότητα του λογισµικού.
1 7 1 ™ Y NOæH
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 171
1 7 2 K E ºA § A I O 7 : ∂ •∞ ™ º∞ § π ™ ∏ ¶√π √∆ ∏∆∞ ™ & A •π √¶π ™ ∆ π ∞ ™
µÈ‚ÏÈÔÁÚ·Ê›·
[1] ΙΕΕΕ (1983), Glossary of Software Engineering Terminology. ANSI – IEEE
Standard 729 – 1983, IEEE Press, New York.
[2] ΙΕΕΕ (1984), Software Quality Assurance Plans. ANSI – IEEE Standard 730 –
1984, IEEE Press, New York.
[3] ΙΕΕΕ (1986), Software Quality Assurance Planning. ANSI – IEEE Standard 983
– 1986, IEEE Press, New York.
[4] J. McCall, P. Richards and G. Walters (1977), Factors in Software Quality. NTIS
AD – A049 – 014, 015, 055 (3 τόµοι).
[5] R. Pressman (1994), Software Engineering: a practitioner’s approach. McGraw
– Hill, England.
[6] M.L. Shooman (1983), Software Engineering. McGraw – Hill, Tokyo.
[7] Ε. Σκορδαλάκης (1991), Εισαγωγή στην Τεχνολογία Λογισµικού. Συµµετρία,
Αθήνα.
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 172
EÊ·ÚÌÔÁ‹ ÙˆÓ ¢È·‰ÈηÛÈÒÓ EϤÁ¯Ô˘
™ÎÔfi˜
Το τελευταίο κεφάλαιο του τόµου παρουσιάζει κάποια βασικά ζητήµατα που άπτονται
πτυχών της πρακτικής εφαρµογής των διαδικασιών ελέγχου.
¶ÚÔÛ‰ÔÎÒÌÂÓ· ·ÔÙÂϤÛÌ·Ù·
Όταν θα έχετε µελετήσει το κεφάλαιο αυτό, θα µπορείτε να:
• αναφέρετε τουλάχιστον τρία µειονεκτήµατα των στρατηγικών δυναµικού ελέγχου,
• εφαρµόσετε τα πέντε βασικά σηµεία της αξιωµατικής επαλήθευσης,
• περιγράψετε τρεις κατηγορίες αυτοµατοποιηµένων εργαλείων ελέγχου,
• δώσετε τον ορισµό της ελεγξιµότητας, ώστε να τη διαχωρίσετε από την αξιοπιστία,
• περιγράψετε τα πέντε βήµατα της διαδικασίας «καθαρού δωµατίου».
ŒÓÓÔȘ ÎÏÂȉȿ
8
∫ ∂ º ∞ § ∞ π √
• τυπική επαλήθευση,
• ισχυρισµός,
• αξιωµατική προσέγγιση,
• ελεγξιµότητα,
• τεχνολογία Λογισµικού
Υποστηριζόµενη από Υπολογιστή,
• παρεµβατικά / µη παρεµβατικά εργα-
λεία δυναµικής ανάλυσης,
• λογισµικό χωρίς ελαττώµατα,
• διαδικασία του «καθαρού δωµατίου».
∂ÈÛ·ÁˆÁÈΤ˜ ·Ú·ÙËÚ‹ÛÂȘ
Οι στρατηγικές δυναµικού ελέγχου που περιγράφηκαν στα Kεφάλαια 4 και 5 παρου-
σιάζουν προβλήµατα κατά την πρακτική τους εφαρµογή. Τα περισσότερα από αυτά σχε-
τίζονται µε το αυξηµένο κόστος που έχουν οι διαδικασίες ελέγχου, αφού συνήθως εφαρ-
µόζονται σχετικά αργά στη διαδικασία ανάπτυξης. Άλλα µειονεκτήµατα είναι:
• η εµπλοκή πολλών και διαφορετικών ανθρώπων σε κάθε στάδιο ελέγχου, η οποία
δυσκολεύει τη διαχείριση της διαδικασίας,
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 173
1 7 4 K E ºA § A I O 8 : E º∞ ƒ ª√° ∏ ∆ ø¡ ¢ π ∞ ¢ π ∫ ∞ ™ π ø¡ E § ∂ ° à √À
• η συνηθισµένη έλλειψη ορθών και λεπτοµερειακών προδιαγραφών, η οποία ευνοεί
µια επαναληπτική διαδικασία ανάπτυξης,
• οι αυξηµένες απαιτήσεις σε πόρους των στρατηγικών ελέγχου,
• η µειωµένη αποδοτικότητα των µεθοδολογιών ελέγχου και η δυσκολία εφαρµογής
τους ακόµη και σε µεσαίου µεγέθους προγράµµατα,
• το µεγάλο κόστος της διόρθωσης των όποιων ελαττωµάτων ανακαλυφθούν, το οποίο
αυξάνει όσο πλησιάζει στο τέλος της η διαδικασία ανάπτυξης,
• η απουσία τεχνικών εκτίµησης των ελαττωµάτων που δεν έχουν ακόµη αποκαλυ-
φθεί, µε αποτέλεσµα ο κατασκευαστής να µην µπορεί να εγγυηθεί την ποιότητα του
λογισµικού, κ.ά.
Η εµπειρία έχει δείξει ότι είναι δυνατή η µείωση του βαθµού δυσκολίας στην αντιµε-
τώπιση των περισσότερων από τα προβλήµατα αυτά εάν, συµπληρωµατικά µε τις στρα-
τηγικές ελέγχου, χρησιµοποιηθούν κάποιες από τις πρακτικές που περιγράφονται στο
κεφάλαιο αυτό.
Στην ενότητα 8.1 παρουσιάζεται η ιδέα της τυπικής επαλήθευσης, η οποία περιλαµβά-
νει την απόδειξη της ορθότητας του λογισµικού χρησιµοποιώντας µαθηµατικά εργα-
λεία. Η µεθοδολογία αυτή εισάγει ισχυρισµούς για την ορθότητα του κώδικα σε διά-
φορα σηµεία του, τους οποίους στη συνέχεια προσπαθεί να «αποδείξει» µέσα από τη
στατική εκτέλεση του προγράµµατος.
Η ευκολία εφαρµογής και η αποτελεσµατικότητα µιας στρατηγικής ελέγχου αυξάνεται
σηµαντικά µε τη βοήθεια των εργαλείων αυτοµατοποιηµένης ανάπτυξης λογισµικού
(ενότητα 8.2). Τα εργαλεία αυτά, αν και έχουν ακόµη περιορισµένη εφαρµογή, υπο-
στηρίζουν όλες τις φάσεις του κύκλου ανάπτυξης, ανάµεσα στις οποίες βρίσκεται και η
φάση της εγκυροποίησης.
Στην ενότητα 8.3 παρουσιάζεται η έννοια της «ελεγξιµότητας», δηλαδή της ευκολίας
µε την οποία µπορεί να ελεγχθεί ένα λογισµικό. Είναι φανερό ότι η σχεδίαση του λογι-
σµικού ώστε να έχει αυξηµένη ελεγξιµότητα µπορεί να αυξήσει την αποδοτικότητα των
στρατηγικών ελέγχου.
Η τελευταία ενότητα (ενότητα 8.4) περιγράφει µια διαφορετική προσέγγιση στην ανά-
πτυξη λογισµικού. Ακολουθώντας τη διαδικασία του «καθαρού δωµατίου», είναι δυνα-
τή η ανάπτυξη λογισµικού µε σηµαντικά µειωµένο αριθµό ελαττωµάτων, οπότε η φάση
του ελέγχου είναι σύντοµη, φθηνή και αποτελεσµατική.
Το τελευταίο αυτό κεφάλαιο του τόµου δεν σκοπεύει τόσο στη µετάδοση γνώσεων, όσο
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 174
στην ενηµέρωσή σας γύρω από τις προσπάθειες επίλυσης των πρακτικών προβληµά-
των που ανακύπτουν κατά την εγκυροποίηση του λογισµικού και τις σύγχρονες προτά-
σεις για την εφαρµογή των διαδικασιών ελέγχου. Καθεµία από τις τέσσερις ενότητες θα
µπορούσε να παρουσιαστεί διεξοδικά σε ένα ξεχωριστό τόµο
.
το παρόν κεφάλαιο στο-
χεύει να λειτουργήσει ως ερέθισµα για την περαιτέρω µελέτη των ζητηµάτων αυτών µε
δική σας πρωτοβουλία.
1 7 5 ∂ π ™ ∞ ° ø° π ∫ ∂ ™ ¶∞ ƒ∞∆ ∏ƒ ∏™ ∂ π ™
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 175
1 7 6 K E ºA § A I O 8 : E º∞ ƒ ª√° ∏ ∆ ø¡ ¢ π ∞ ¢ π ∫ ∞ ™ π ø¡ E § ∂ ° à √À
8.1 ∆˘È΋ E·Ï‹ı¢ÛË
Κατά την τυπική επαλήθευση (formal verification) του λογισµικού, επιχειρούµε να
αποδείξουµε, χρησιµοποιώντας µαθηµατικές µεθόδους, ότι το λογισµικό ικανοποιεί τις
προδιαγραφές του. Η εφαρµογή των µεθόδων τυπικής επαλήθευσης προϋποθέτει ότι:
• Η σηµασιολογία της γλώσσας προγραµµατισµού είναι τυπικά ορισµένη.
• Οι προδιαγραφές του λογισµικού περιγράφονται µε ένα τυπικό συµβολισµό, ο οποί-
ος είναι συµβατός µε τις τεχνικές τυπικής επαλήθευσης που χρησιµοποιούνται.
∆υστυχώς, δεν είναι όλες οι γλώσσες τυπικά ορισµένες, ούτε είναι διαδεδοµένη η
χρήση των τυπικών προδιαγραφών. Έτσι, η εφαρµογή της τυπικής επαλήθευσης γίνε-
ται ακριβή και, για µεγάλα συστήµατα λογισµικού, πρακτικά ανεφάρµοστη.
Στη συνέχεια θα µελετήσουµε την αξιωµατική προσέγγιση στην τυπική επαλή-
θευση, µια σχετικά απλή και διαδεδοµένη τεχνική. Η αξιωµατική προσέγγιση βασί-
ζεται στα εξής (Sommerville[96]):
• Υπάρχει ένας αριθµός σηµείων σε ένα πρόγραµµα, όπου µπορούν να γίνουν ισχυ-
ρισµοί (assertions) για τις µεταβλητές του προγράµµατος και τις σχέσεις µεταξύ
αυτών
• Έτσι, οι ισχυρισµοί Α
1
, Α
2
, …, Α
n
συσχετίζονται µε τα σηµεία P
1
, P
2
, …, P
n
του
προγράµµατος. Ο ισχυρισµός Α
1
αφορά στις εισόδους του προγράµµατος (προ –
συνθήκη), ενώ ο ισχυρισµός Α
n
αφορά στις εξόδους του προγράµµατος (µετα –
συνθήκη).
• Για να δείξουµε ότι ο κώδικας ανάµεσα στα σηµεία P
i
και P
i+1
είναι σωστός, αρκεί
να δείξουµε ότι οι ενδιάµεσες εντολές προκαλούν το µετασχηµατισµό του ισχυ-
ρισµού A
i
στον A
i+1.
• Εάν µπορεί να αποδειχθεί ότι ο Α
1
µετατρέπεται πάντα στον Α
2
, ο Α
2
µετατρέπε-
ται πάντα στον Α
3
κ.ο.κ. έως ότου εξεταστούν όλες οι εντολές, ο συνδυασµός των
ισχυρισµών αυτών δείχνει ότι ο Α
1
πάντα µετατρέπεται στον Α
n
. Συνεπώς, το πρό-
γραµµα είναι µερικώς ορθό.
• Για να αποδείξουµε πλήρως την ορθότητα, χρειάζεται ακόµη να αποδείξουµε ότι
το πρόγραµµα θα τερµατίζει πάντα.
¶·Ú¿‰ÂÈÁÌ· 8.1
Θα εφαρµόσουµε την αξιωµατική προσέγγιση στη διαδικασία δυαδικής αναζήτησης.
Υπενθυµίζουµε ότι στον αλγόριθµο που ακολουθεί, οι συναρτήσεις FIRST(X) και
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 176
LAST(X) επιστρέφουν το κάτω και το άνω όριο του πίνακα Χ και ότι χρησιµοποι-
ούµε τις µεταβλητές BOT και TOP για να «κρατάµε» κάθε φορά το κάτω και το άνω
όριο του υπο – πίνακα που ψάχνουµε. Αρχικά, εισάγουµε ισχυρισµούς σε διάφορα
σηµεία της διαδικασίας (γράφονται µε πλάγια γραφή):
ΑΛΓΟΡΙΘΜΟΣ ∆ΥΑ∆ΙΚΗ – ΑΝΑΖΗΤΗΣΗ
ΕΙΣΟ∆ΟΣ
KEY: INTEGER ;
T: ARRAY [1..N] OF INTEGER ;
ΕΞΟ∆ΟΣ
FOUND: BOOLEAN ;
POS: INTEGER ;
∆Ε∆ΟΜΕΝΑ
TOP, BOT, MID: INTEGER ;
ΠΡΟ – ΣΥΝΘΗΚΗ
LAST(T) – FIRST(T) > 0 AND
(FORALL i, FIRST(T) >= i =< LAST(T) – 1, T[i] <= T[i+1])
ΑΡΧΗ
FOUND := FALSE ;
POS := – 1 ;
BOT := T[FIRST(T)] ;
TOP := T[LAST(T)] ;
ΙΣΧΥΡΙΣΜΟΣ 1
(FOUND = TRUE AND T[POS] = ΚΕΥ) OR
(FOUND = FALSE AND NOT(KEY IN T[BOT.. TOP]
ΕΝΟΣΩ ((BOT =< TOP) AND (FOUND = FALSE)) ΕΠΑΝAΛΑΒΕ
MID := (TOP + BOT) div 2 ;
ΕΑΝ (Τ[MID] = KEY) ΤΟΤΕ
FOUND := TRUE ;
POS := MID
1 7 7 8 . 1 ∆ À ¶π ∫ ∏ E ¶∞ § ∏£∂ À ™ ∏
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 177
1 7 8 K E ºA § A I O 8 : E º∞ ƒ ª√° ∏ ∆ ø¡ ¢ π ∞ ¢ π ∫ ∞ ™ π ø¡ E § ∂ ° à √À
ΙΣΧΥΡΙΣΜΟΣ 2
ΚΕΥ = Τ[ΜΙD] AND FOUND = TRUE
ΑΛΛΙΩΣ
ΕΑΝ (Τ[MID] < KEY) ΤΟΤΕ
ΙΣΧΥΡΙΣΜΟΣ 3
NOT (ΚΕΥ IN Τ[FIRST(T).. ΜΙD]
BOT := MID + 1
ΙΣΧΥΡΙΣΜΟΣ 4
NOT (ΚΕΥ IN Τ[FIRST(T).. BOT – 1]
ΑΛΛΙΩΣ
ΙΣΧΥΡΙΣΜΟΣ 5
NOT (ΚΕΥ IN Τ[ΜΙD.. LAST(T)]
TOP := MID – 1
ΙΣΧΥΡΙΣΜΟΣ 6
NOT (ΚΕΥ IN Τ[TOP + 1.. LAST(T)]
ΕΑΝ – ΤΕΛΟΣ
ΕΑΝ – ΤΕΛΟΣ
ΕΝΟΣΩ – ΤΕΛΟΣ
ΤΥΠΩΣΕ(FOUND, POS)
META – ΣΥΝΘΗΚΗ
(FOUND = TRUE AND T[POS] = KEY) OR
(FOUND = FALSE AND NOT(FORALL i, FIRST(T) >= i =< LAST(T) – 1, T[i]
= KEY))
ΤΕΛΟΣ
Στη συνέχεια πρέπει να αποδείξουµε ότι:
• Το πρόγραµµα τερµατίζει.
• Η προ – συνθήκη, µαζί µε τις εντολές του προγράµµατος, παράγουν τη µετα –
συνθήκη.
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 178
Για να αποδείξουµε ότι το πρόγραµµα τερµατίζει, πρέπει να αποδείξουµε ότι δεν
υπάρχει περίπτωση στην οποία η έξοδος από τη δοµή επανάληψης είναι αδύνατη. Η
δοµή αυτή τερµατίζει όταν FOUND = TRUE ή όταν ΤΟΡ > ΒΟΤ. Συνεπώς:
• Εάν βρεθεί στοιχείο του Τ ίσο µε ΚΕΥ, τότε FOUND = TRUE και η δοµή επα-
νάληψης τερµατίζει.
• Για να εκτελεστεί η δοµή επανάληψης, πρέπει ΒΟΤ =< ΤΟΡ ή (ΒΟΤ – ΤΟΡ) <=
0. Εάν δείξουµε ότι ισχύει (ΒΟΤ – ΤΟΡ) > 0, ο τερµατισµός της δοµής επανάλη-
ψης είναι εγγυηµένος. Εάν δε βρεθεί στοιχείο ίσο µε ΚΕΥ σε κάποια εκτέλεση της
δοµής επανάληψης, θα εκτελεστεί µια από τις εντολές ΒΟΤ := MID + 1 ή ΤΟΡ :=
MID – 1. Η MID είναι πάντα θετική, αφού υπολογίζεται από την εντολή MID :=
(ΤΟΡ + ΒΟΤ) div 2, οπότε ισχύει ΒΟΤ < MID < ΤΟΡ. Αφού οι εντολές του προ-
γράµµατος είτε αυξάνουν τη ΒΟΤ είτε µειώνουν τη ΤΟΡ, είναι αναµενόµενο ότι
κάποτε θα γίνει (ΒΟΤ – ΤΟΡ) > 0 και η δοµή επανάληψης θα τερµατιστεί.
1 7 9 8 . 1 ∆ À ¶π ∫ ∏ E ¶∞ § ∏£∂ À ™ ∏
Προσπαθήστε να αποδείξετε χρησιµοποιώντας µαθηµατικές τεχνικές ότι ο αλγό-
ριθµος της δυαδικής αναζήτησης τερµατίζει. Στη συνέχεια, µελετήστε τα δικά µας
επιχειρήµατα.
¢Ú·ÛÙËÚÈfiÙËÙ· 8.1
∆οκιµάστε να κατασκευάσετε έναν πίνακα, στον οποίο θα φαίνεται ο τρόπος µε
τον οποίο η προ – συνθήκη µετατρέπεται στη µετα – συνθήκη, ικανοποιώντας δια-
δοχικά τους ενδιάµεσους ισχυρισµούς. Μπορείτε να συγκρίνετε την απάντησή σας
µε τον Πίνακα 8.1.
Ισχυρισµός Ερµηνεία Επιχειρηµατολογία
Προσυνθήκη Ο πίνακας Τ είναι διατεταγµένος κατ’
αύξουσα σειρά και έχει τουλάχιστον ένα
στοιχείο.
Υποθέτουµε ότι ισχύει η προ – συνθήκη.
¢Ú·ÛÙËÚÈfiÙËÙ· 8.2
¶›Ó·Î·˜ 8.1
Τυπική επαλήθευση της διαδικασίας δυαδικής αναζήτησης
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 179
1 8 0 K E ºA § A I O 8 : E º∞ ƒ ª√° ∏ ∆ ø¡ ¢ π ∞ ¢ π ∫ ∞ ™ π ø¡ E § ∂ ° à √À
1 Είτε δεν υπάρχει στοιχείο ίσο µε ΚΕΥ στο
τµήµα του Τ που έχει εξεταστεί, είτε το
µεσαίο στοιχείο είναι ίσο µε ΚΕΥ.
Ισχύει κατά την πρώτη είσοδο στη δοµή
επανάληψης. Αφού δεν έχει εξεταστεί
κανένα τµήµα του Τ, δεν έχει βρεθεί στοι-
χείο ίσο µε ΚΕΥ.
2 Το µεσαίο στοιχείο είναι ίσο µε ΚΕΥ,
οπότε FOUND = TRUE.
Ισχύει γιατί η συνθήκη KEY = T[MID]
είναι αληθής.
3 Το στοιχείο ΚΕΥ δε βρίσκεται στο κάτω
µισό του πίνακα.
Ισχύει γιατί ο Τ είναι διατεταγµένος και
Τ[MID] < KEY. Όλα τα στοιχεία των
οποίων ο απαριθµητής είναι µικρότερος
από MID πρέπει να είναι µικρότερα από
το ΚΕΥ.
4 Το στοιχείο ΚΕΥ δε βρίσκεται στο κάτω
µισό του πίνακα, µετά τη νέα τιµή της
FIRST(Τ).
Προκύπτει αντικαθιστώντας το MID µε
ΒΟΤ + 1.
5 Το στοιχείο ΚΕΥ δε βρίσκεται στο πάνω
µισό του πίνακα.
Προκύπτει αν ακολουθήσουµε παρόµοια
προσέγγιση µε τον ισχυρισµό 3. Όλα τα
στοιχεία των οποίων ο απαριθµητής είναι
µεγαλύτερος από MID πρέπει να είναι
µεγαλύτερα από το ΚΕΥ.
6 Το στοιχείο ΚΕΥ δε βρίσκεται στο πάνω
µισό του πίνακα, µετά τη νέα τιµή της
LAST(Τ).
Προκύπτει αντικαθιστώντας το MID µε
ΤΟΡ – 1.
7 Η δοµή επανάληψης εκτελείται ξανά,
αφού FOUND = FALSE, ενώ δεν ισχύει
ΒΟΤ > ΤΟΡ.
Το στοιχείο ΚΕΥ δε βρέθηκε στο τµήµα
του Τ που ελέγθηκε.
Μετασυν-
θήκη
Η δοµή επανάληψης τερµατίζει επειδή το
στοιχείο ΚΕΥ βρέθηκε στον πίνακα ή
επειδή έχει ελεγχθεί ολόκληρος ο πίνακας.
Η FOUND γίνεται πάντα TRUE όταν βρε-
θεί το ΚΕΥ. Αλλιώς, ολόκληρος ο πίνακας
έχει ελεγχθεί, αφού όλα τα στοιχεία του
βρίσκονται ανάµεσα στα T[FIRST(Τ)..
LAST(Τ)].
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 180
8.2 ∞˘ÙÔÌ·ÙÔÔÈË̤ӷ ÂÚÁ·Ï›· ÂϤÁ¯Ô˘
Είναι γεγονός ότι µόλις τα τελευταία χρόνια άρχισαν να χρησιµοποιούνται από τις
εταιρείες ανάπτυξης λογισµικού εργαλεία λογισµικού τα οποία αυτοµατοποιούν σε
κάποιο βαθµό τον κύκλο ανάπτυξης λογισµικού: η κοινότητα των µηχανικών λογι-
σµικού ήταν πολύ απασχοληµένη αναπτύσσοντας λογισµικό για άλλους µε αποτέ-
λεσµα να παραµελήσει τις δικές της ανάγκες. Το σύνολο των εργαλείων αυτών γενι-
κά προωθούν την «Τεχνολογία Λογισµικού Υποστηριζόµενη από Υπολογιστή»
(Computer – Aided Software Engineering – CASE).
Υπάρχουν διάφορα είδη εργαλείων CASE, ανάλογα µε τη φάση του κύκλου ανά-
πτυξης στην οποία επικεντρώνονται και την έκταση της παρεχόµενης υποστήριξης.
Από αυτά, τα ολοκληρωµένα εργαλεία υποστηρίζουν όλες τις φάσεις του κύκλου
ανάπτυξης (π.χ. καταγραφή απαιτήσεων, σχεδίαση, αυτοµατοποιηµένη ανάπτυξη,
έλεγχο, διάθεση κλπ.), ενώ παρέχουν και υπηρεσίες υποστήριξης (π.χ. αυτοµατο-
ποιηµένη τεκµηρίωση) αλλά και διαχείρισης του κύκλου ανάπτυξης.
Στην παρούσα ενότητα µας ενδιαφέρουν εργαλεία (ή τµήµατα ολοκληρωµένων εργα-
λείων) που υποστηρίζουν την αυτοµατοποίηση φάσεων ή δραστηριοτήτων, οι οποί-
ες σχετίζονται άµεσα µε την εγκυροποίηση του λογισµικού. Τέτοια είναι:
• εργαλεία συλλογής δεδοµένων, τα οποία θα χρησιµοποιηθούν κατά τον έλεγχο,
• εργαλεία στατικής ανάλυσης του κώδικα,
• εργαλεία δυναµικής ανάλυσης του κώδικα κατά τη διάρκεια της εκτέλεσης,
• εργαλεία προσοµοίωσης της λειτουργίας του υλικού ή άλλων εξωτερικών προ-
γραµµάτων,
• εργαλεία διαχείρισης του ελέγχου, τα οποία βοηθούν στη σχεδίαση, εφαρµογή
και έλεγχο της διαδικασίας εγκυροποίησης,
• δια – λειτουργικά εργαλεία, τα οποία υλοποιούν διάφορες λειτουργίες από τις
παραπάνω κατηγορίες.
Στη συνέχεια θα παρουσιάσουµε τρεις κατηγορίες εργαλείων που αυτοµατοποιούν
τη διαδικασία ελέγχου, αφού αυτή είναι η κύρια δραστηριότητα της εγκυροποίησης
(Pressman[94]).
8.2.1 ∂ÚÁ·Ï›· ÛÙ·ÙÈ΋˜ ·Ó¿Ï˘Û˘
Τα εργαλεία στατικής ανάλυσης χρησιµοποιούνται για την παραγωγή περιπτώσεων
ελέγχου. Στις περισσότερες περιπτώσεις χρησιµοποιούνται για την τεκµηρίωση και
1 8 1 8 . 2 ∞ À ∆ √ª∞∆ √¶√π ∏ª∂ ¡∞ ∂ ƒ °∞ § ∂ π ∞ ∂ § ∂ ° à √À
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 181
1 8 2 K E ºA § A I O 8 : E º∞ ƒ ª√° ∏ ∆ ø¡ ¢ π ∞ ¢ π ∫ ∞ ™ π ø¡ E § ∂ ° à √À
την αρχειοθέτηση των ελέγχων. Ακόµη, στις περισσότερες περιπτώσεις, µπορούν να
συγκρίνουν τα αποτελέσµατα των εξόδων του ελέγχου µε τα αναµενόµενα αποτε-
λέσµατα και να εντοπίσουν διαφορές.
Στη βιοµηχανία λογισµικού χρησιµοποιούνται τρία είδη εργαλείων στατικής ανάλυσης:
• εργαλεία που επεξεργάζονται τον πηγαίο κώδικα (ή µια περιγραφή σε ψευδοκώ-
δικα) του προγράµµατος και εφαρµόζουν µια σειρά αναλύσεων σε µια περιγρα-
φή των εισόδων του για να παράγουν τις περιπτώσεις ελέγχου,
• ειδικευµένες γλώσσες, οι οποίες επιτρέπουν στην οµάδα δοκιµής να γράψει
λεπτοµερείς προδιαγραφές για κάθε περίπτωση ελέγχου και για τον τρόπο εφαρ-
µογής της,
• εργαλεία που επικεντρώνονται σε συγκεκριµένες απαιτήσεις των χρηστών, για
τις οποίες προτείνουν περιπτώσεις (ή κλάσεις περιπτώσεων) ελέγχου (τα εργα-
λεία αυτά απαιτούν την τυπική περιγραφή των απαιτήσεων).
8.2.2 ∂ÚÁ·Ï›· ‰˘Ó·ÌÈ΋˜ ·Ó¿Ï˘Û˘
Τα εργαλεία αυτά συνήθως χρησιµοποιούνται για να εφαρµόσουν τις περιπτώσεις
ελέγχου που σχεδιάστηκαν µε τη χρήση των στατικών εργαλείων. Όταν ενεργοποι-
ηθούν, αλληλεπιδρούν µε το πρόγραµµα υπό εκτέλεση και ελέγχουν την ορθότητα
ενός συνόλου ισχυρισµών για τις τιµές διαφόρων µεταβλητών. Στο τέλος, παράγουν
ένα σύνολο αναφορών όπου καταγράφεται πόσες φορές εκτελέστηκε µια οµάδα
εντολών και ο µέσος χρόνος εκτέλεσης.
Τα δυναµικά εργαλεία ελέγχου µπορεί να είναι ή να µην είναι παρεµβατικά
(intrusive). Ένα παρεµβατικό εργαλείο τροποποιεί το υπό δοκιµή πρόγραµµα, εισά-
γοντας εντολές που υλοποιούν όσα αναφέρονται πιο πάνω. Τα µη παρεµβατικά εργα-
λεία χρησιµοποιούν ένα ξεχωριστό επεξεργαστή, ο οποίος λειτουργεί παράλληλα µε
τον επεξεργαστή που εκτελεί το υπό δοκιµή πρόγραµµα.
8.2.3 ∂ÚÁ·Ï›· ‰È·¯Â›ÚÈÛ˘ Ù˘ ‰È·‰Èηۛ·˜ ÂϤÁ¯Ô˘
Χρησιµοποιούνται για το συντονισµό και τον έλεγχο των σηµαντικών σταδίων της
διαδικασίας ελέγχου. Υποστηρίζουν τον έλεγχο παλινδρόµησης, τη σύγκριση ανά-
µεσα στις πραγµατικές και τις αναµενόµενες εξόδους, το διεξοδικό έλεγχο διαλογι-
κών εφαρµογών κλπ. Άλλη σηµαντική χρήση τους είναι ως «οδηγοί» του ελέγχου:
επιλέγουν έναν αριθµό περιπτώσεων ελέγχου από ένα αρχείο, µορφοποιούν κατάλ-
ληλα τα δεδοµένα ελέγχου, καλούν το υπό δοκιµή πρόγραµµα και καταγράφουν τις
προκύπτουσες εξόδους.
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 182
8.2.4 ÕÏÏ· ÂÚÁ·Ï›·
Επειδή οι δραστηριότητες εγκυροποίησης διατρέχουν ολόκληρο τον κύκλο ανάπτυ-
ξης, σχεδόν κάθε τµήµα ενός εργαλείου CASE παρέχει λειτουργίες εγκυροποίησης.
Υπάρχει, λοιπόν, ένα σύνολο αυτοµατοποιηµένων εργαλείων που σχετίζονται έµµε-
σα µε την εγκυροποίηση, όπως τα ακόλουθα:
• Εργαλεία ανίχνευσης απαιτήσεων: Tα εργαλεία αυτά επεξεργάζονται το έγγραφο των
προδιαγραφών των απαιτήσεων και δηµιουργούν µια βάση δεδοµένων µε τις απαι-
τήσεις των χρηστών, η οποία χρησιµοποιείται στη συνέχεια ως σηµείο αναφοράς.
• Εργαλεία µετρήσεων: Xρησιµοποιούν µετρικές για να εκτιµήσουν χαρακτηριστι-
κά ποιότητας του λογισµικού, τα οποία στη συνέχεια συγκρίνουν µε τις τυπικές
τιµές που εµφανίζουν τα προγράµµατα που βρίσκονται στην ίδια κατηγορία µε
το υπό δοκιµή λογισµικό.
• Εργαλεία τεκµηρίωσης: Bελτιώνουν σηµαντικά την ποιότητα των παραγόµενων
εγγράφων, µειώνοντας ταυτόχρονα τον απαιτούµενο χρόνο και φόρτο.
• Εργαλεία εξασφάλισης της ποιότητας: Bασικά, πρόκειται για εργαλεία µετρήσε-
ων, τα οποία λαµβάνουν υπόψη τους και διαδεδοµένα πρότυπα.
• Εργαλεία πρωτοτυποποίησης: Παράγουν ένα πρωτότυπο του υπό ανάπτυξη
συστήµατος, το οποίο υλοποιεί (ή προσοµοιώνει) ένα υποσύνολο όλων των λει-
τουργιών του τελικού συστήµατος, µε στόχο να δοκιµαστούν (και να αναλυθούν)
οι προδιαγραφές των απαιτήσεων των χρηστών.
8.3 ∂ÏÂÍÌfiÙËÙ· ÏÔÁÈÛÌÈÎÔ‡
Η ελεγξιµότητα (testability) του λογισµικού ορίζεται ως:
1. ο βαθµός στον οποίο ένα σύστηµα ή ένα στοιχείο διευκολύνει τον καθορισµό κρι-
τηρίων ελέγχου και τη διεξαγωγή ελέγχων για να διαπιστωθεί κατά πόσο αυτά
ικανοποιούνται και
2. ο βαθµός στον οποίο µια απαίτηση εκφράζεται µε τρόπο ώστε να επιτρέπεται ο
καθορισµός κριτηρίων ελέγχου και η διεξαγωγή ελέγχων για να διαπιστωθεί κατά
πόσο αυτά ικανοποιούνται (IEEE[90]).
Σύµφωνα µε τον ορισµό αυτό, χρειάζονται µια κατανοµή των εισόδων που παρέχο-
νται στο λογισµικό και ένα σύνολο κριτηρίων ελέγχου ώστε να είναι δυνατή η εκτί-
µηση της ελεγξιµότητας. Τότε, η ελεγξιµότητα αναπαριστά την πιθανότητα να αστο-
χήσει το ελαττωµατικό λογισµικό στην επόµενη δοκιµαστική του εκτέλεση και απο-
τελεί µέτρο του πόσο δύσκολο είναι να ικανοποιηθεί ένας συγκεκριµένος στόχος των
ελέγχων του λογισµικού.
1 8 3 8 . 3 ∂ § ∂ •ª√∆ ∏∆∞ § √° π ™ ªπ ∫ √À
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 183
1 8 4 K E ºA § A I O 8 : E º∞ ƒ ª√° ∏ ∆ ø¡ ¢ π ∞ ¢ π ∫ ∞ ™ π ø¡ E § ∂ ° à √À
Μελετήστε ξανά την ενότητα 7.4, η οποία αναφέρεται στην αξιοπιστία του λογι-
σµικού. Προσπαθήστε να τη συγκρίνετε µε την προσέγγιση της ελεγξιµότητας και
να εντοπίσετε µία βασική τους διαφορά. Έπειτα µελετήστε το κείµενο στο πλαίσιο
που ακολουθεί.
Η προσέγγιση της ελεγξιµότητας είναι θεµελιωδώς διαφορετική από τα παραδο-
σιακά µοντέλα αξιοπιστίας λογισµικού: τα τελευταία επιχειρούν να απαντήσουν
στο ερώτηµα «ποια είναι η πιθανότητα ο συγκεκριµένος κώδικας να περιέχει ελάτ-
τωµα;». Η θεωρία της ελεγξιµότητας εξετάζει µια διαφορετική άποψη: «ποια είναι
η πιθανότητα να παρουσιαστεί σφάλµα κατά την εκτέλεση του συγκεκριµένου
κώδικα, εάν αυτός περιέχει ελάττωµα;».
¢Ú·ÛÙËÚÈfiÙËÙ· 8.3
Με βάση όλα τα προηγούµενα, µπορούµε να θεωρήσουµε ότι η ελεγξιµότητα του λογι-
σµικού πρέπει να χρησιµοποιείται συµπληρωµατικά προς τον έλεγχο και την τυπική
επαλήθευση του λογισµικού κατά την εκτίµηση της αξιοπιστίας του (Voas[95]). Ο έλεγ-
χος µπορεί να αποκαλύψει ελαττώµατα
.
η ελεγξιµότητα δεν µπορεί να αποκαλύψει
ελαττώµατα, µπορεί µόνο να εντοπίσει τµήµατα του κώδικα όπου µπορεί να «κρύβο-
νται» ελαττώµατα. Επιπλέον, η ελεγξιµότητα συµπληρώνει µε εµπειρικά δεδοµένα τις
πληροφορίες για την αξιοπιστία του λογισµικού που παρέχει η τυπική επαλήθευση.
¶·Ú¿‰ÂÈÁÌ· 8.2
Έστω ότι χρησιµοποιούµε µόνο τεχνικές αδιαφανούς κουτιού για να ελέγξουµε την
αξιοπιστία κάποιου λογισµικού. Όπως θα δείτε, χρειαζόµαστε έναν τεράστιο αριθ-
µό δοκιµών για να εκτιµήσουµε µε βεβαιότητα 99% ότι η πιθανότητα αστοχίας είναι
< 10
– 9
(δηλαδή, το λογισµικό στατιστικά εµφανίζει λιγότερα από 10
– 9
σφάλµατα
ανά δοκιµή). Στην πραγµατικότητα, χρειαζόµαστε περίπου 4,6 δισεκατοµµύρια απο-
τυχηµένους ελέγχους, ανάλογα µε την κατανοµή των δεδοµένων εισόδου!
Το πρόβληµα µεγαλώνει επειδή, εάν παρουσιαστεί σφάλµα κατά τη διάρκεια του
ελέγχου, πρέπει αυτό να διορθωθεί και ο έλεγχος αδιαφανούς κουτιού να επαναλη-
φθεί από την αρχή ! Ακόµη χειρότερα, οι στατιστικές δείχνουν ότι το 30% του όποι-
ου νέου κώδικα που προσθέτουµε στο λογισµικό (π.χ. για να επιδιορθώσουµε κάποιο
ελάττωµα) περιέχει νέα ελαττώµατα.
Από το Παράδειγµα 8.2 γίνεται φανερό ότι πρέπει να αναζητήσουµε τρόπους αύξη-
σης της αποτελεσµατικότητας των ελέγχων. Υπάρχουν δύο τέτοιοι τρόποι, οι οποί-
οι µειώνουν των αριθµό των απαιτούµενων δοκιµών:
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 184
• Να επιλέγουµε δοκιµαστικές περιπτώσεις που αποκαλύπτουν περισσότερα ελατ-
τώµατα.
• Να σχεδιάζουµε λογισµικό, στο οποίο να έχει πολλές πιθανότητες η εµφάνιση
ενός σφάλµατος όταν ο κώδικας περιέχει ελάττωµα.
Η δεύτερη στρατηγική, η οποία καλείται «σχεδίαση µε στόχο την ελεγξιµότητα»,
είναι προτιµότερη, αλλά και δυσκολότερη στην υλοποίηση, επειδή:
• µεγαλύτερο τµήµα του κώδικα πρέπει να δοκιµάζεται µε κάθε σύνολο δεδοµέ-
νων εισόδου,
• ο κώδικας πρέπει να περιέχει δοµές, οι οποίες έχουν µεγάλη πιθανότητα να προ-
καλέσουν σφάλµα στην κατάσταση του προγράµµατος κατά την εκτέλεση, όταν
οι ίδιες οι δοµές περιέχουν ελάττωµα,
• το πρόγραµµα πρέπει να έχει την ικανότητα να µετατρέπει τις εσφαλµένες κατα-
στάσεις σε αστοχίες εκτέλεσης.
8.3.1 ∞ÒÏÂÈ· ÏËÚÔÊÔÚ›·˜
Μελετώντας τα προηγούµενα µπορεί να αναρωτηθήκατε: µα, ποιό είναι το πρόβλη-
µα στη σχεδίαση ενός προγράµµατος µε αυξηµένη ελεγξιµότητα; Το βασικό πρό-
βληµα προκαλείται έµµεσα από τις σύγχρονες τεχνικές σχεδίασης (π.χ. τµηµατο-
ποιηµένη σχεδίαση, αντικειµενοστραφής σχεδίαση κ.ά.), οι οποίες τείνουν να απο-
κρύπτουν πληροφορίες σχετικές µε την εσωτερική οργάνωση και λειτουργία των
τµηµάτων λογισµικού: όταν τα τµήµατα του λογισµικού περιέχουν τοπικές µετα-
βλητές, δεν έχουµε τη δυνατότητα να συγκεντρώσουµε πληροφορίες γι’ αυτές κατά
τη διάρκεια των λειτουργικών ελέγχων.
Το πρόβληµα αυτό θέτει τελικά ένα άνω όριο στην ελεγξιµότητα ενός τµήµατος λογι-
σµικού που µπορεί να επιτύχει ένα σύνολο δοκιµαστικών δεδοµένων εισόδου. Όµως,
το όριο µπορεί να αυξηθεί, εάν τροποποιήσουµε την περιγραφή του τµήµατος, ώστε
περισσότερη «εσωτερική» πληροφορία να είναι διαθέσιµη. Η αύξηση της εσωτερι-
κής πληροφορίας µπορεί να αντισταθµίσει την απώλεια που προκαλείται όταν η εσω-
τερική πληροφορία του τµήµατος δεν «φτάνει» ως την έξοδό του.
1 8 5 8 . 3 ∂ § ∂ •ª√∆ ∏∆∞ § √° π ™ ªπ ∫ √À
Η απώλεια εσωτερικής πληροφορίας αυξάνει την πιθανότητα να µην ανακαλυ-
φθούν σφάλµατα στην κατάσταση του λογισµικού, επειδή όλες οι ενδείξεις της
εσφαλµένης κατάστασης ίσως να περιέχονται στην απωλεσθείσα πληροφορία.
Συνεπώς, η απώλεια πληροφορίας µειώνει την ελεγξιµότητα.
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 185
1 8 6 K E ºA § A I O 8 : E º∞ ƒ ª√° ∏ ∆ ø¡ ¢ π ∞ ¢ π ∫ ∞ ™ π ø¡ E § ∂ ° à √À
Υπάρχουν δύο είδη απώλειας πληροφοριών:
• Εµµεση απώλεια: Συµβαίνει όταν δύο ή περισσότερες παράµετροι εισόδου σε ένα
τµήµα παράγουν το ίδιο αποτέλεσµα στην έξοδο. Είναι αρκετά διαδεδοµένη ανά-
µεσα στους περισσότερους από τους τελεστές που υποστηρίζουν οι σύγχρονες
γλώσσες προγραµµατισµού, µε σοβαρότερους υποψήφιους τους λογικούς τελε-
στές, όπου ο βαθµός του πεδίου τιµών είναι µόλις 2.
• Άµεση απώλεια: Συµβαίνει όταν δεν επικυρώνεται η τιµή των µεταβλητών κατά
την εκτέλεση ή µετά το τέλος αυτής. Τις περισσότερες φορές εµφανίζεται ως απο-
τέλεσµα της απόκρυψης πληροφοριών, γι’ αυτό και είναι πολύ δύσκολο να ανι-
χνευθεί νωρίς στη διαδικασία ανάπτυξης
8.3.2 µÂÏÙ›ˆÛË Ù˘ ۯ‰›·Û˘
Από τις τεχνικές µείωσης των επιπτώσεων που έχει στην ελεγξιµότητα η απώλεια
πληροφοριών, οι περισσότερο σηµαντικές είναι οι εξής:
• ∆ιάσπαση των προδιαγραφών, ώστε να µειωθεί η πιθανότητα να χάνονται οι
εσφαλµένες καταστάσεις ανάµεσα στις κλήσεις διαφόρων τµηµάτων.
• Ελαχιστοποίηση της πολλαπλής χρήσης του ονόµατος κάθε µεταβλητής. Αυτό
θα οδηγήσει αναπόφευκτα στη χρήση περισσότερων µεταβλητών, µε αποτέλε-
σµα να χειροτερέψει η απόδοση του συστήµατος. Όµως, η αύξηση της ελεγξι-
µότητας του προγράµµατος µειώνει τον απαιτούµενο χρόνο ελέγχου και συνεπώς
µειώνει το συνολικό κόστος.
• Αύξηση των µεταβλητών εξόδου, µε τη χρήση εντολών που τυπώνουν τις τιµές
διαφόρων συνθηκών και εσωτερικών µεταβλητών (η µέθοδος παρουσιάστηκε
στην ενότητα 6.2.1).
Η αύξηση στην ελεγξιµότητα του λογισµικού µπορεί να µετρηθεί µε την ανάλυση
ευαισθησίας, η οποία ποσοτικοποιεί τις πληροφορίες που έχουµε συλλέξει σχετικά
µε την πιθανότητα να υπάρχουν κρυµµένα λάθη στον κώδικα.
Σχόλιο µελέτης
Στο σηµείο αυτό, καλό είναι να ρίξετε άλλη µια µατιά στην ενότητα 3.3, όπου περι-
γράφεται η ανάλυση ευαισθησίας.
8.4 §ÔÁÈÛÌÈÎfi ¯ˆÚ›˜ ÂÏ·ÙÙÒÌ·Ù·
Η διαδικασία του «καθαρού δωµατίου» (cleanroom process), που έχει αναφερθεί
και στην ενότητα 7.3.3, είναι µια προσέγγιση στην ανάπτυξη λογισµικού, η οποία
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 186
βασίζεται στη στατική επαλήθευση και στοχεύει στην παραγωγή λογισµικού χωρίς
ελαττώµατα (zero – defect software). Η διαδικασία αυτή δίνει µεγαλύτερο βάρος
στην πρόληψη αντί στη διόρθωση των ελαττωµάτων. Το όνοµά της προέρχεται από
τις διαδικασίες κατασκευής ηµιαγωγών στοιχείων, οι οποίες, προς αποφυγή ελατ-
τωµάτων, λαµβάνουν χώρα σε «αποστειρωµένα» δωµάτια.
Στη διαδικασία του «καθαρού δωµατίου» εµπλέκονται δύο ξεχωριστές οµάδες: η
οµάδα ανάπτυξης και η οµάδα πιστοποίησης. Τα βήµατα της διαδικασίας φαίνονται
στο Σχήµα 8.1, ενώ στη συνέχεια περιγράφονται τα πέντε βασικά της χαρακτηρι-
στικά (Linger[94]).
1 8 7 8 . 4 § √° π ™ ªπ ∫ √ à øƒ π ™ ∂ § ∞∆ ∆ øª∞∆∞
™¯‹Ì· 8.1
Το µοντέλο
«καθαρού δωµατί-
ου» (τα πολλαπλά
ορθογώνια είναι
ένδειξη διαδοχι-
κών επαυξηµένων
εκδόσεων)
Aπαιτήσεις Xρηστών
Προδιαγραφές
Λειτουργι– 
κότητας
Xρήσης
Σχεδίαση Aυξητικής 
Aνάπτυξης
Προδιαγραφές Λειτουργικότητας
Πλάνο Aυξητικής 
Aνάπτυξης
Προδιαγραφές Xρήσης
Πηγαίος Kώδικας
Στατιστικός Έλεγχος
Περιπτώσεις Eλέγχου
Mοντέλο Ποιστοποίησης 
Ποιότητας Bελτιωτική Aνάδραση
Eκτιµήσεις Mέσου 
Xρόνου Mέχρι Tην 
Eµφάνιση Σφάλµατος
Xρόνοι Mεταξύ 
Eµφανίσεων 
Σφαλµάτων
Tυπική Σχεδίαση 
Eπαλήθευση 
Oρθότητας
Σχεδίαση Περιπτώσεων 
Στατιστικού Eλέγχου
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 187
1 8 8 K E ºA § A I O 8 : E º∞ ƒ ª√° ∏ ∆ ø¡ ¢ π ∞ ¢ π ∫ ∞ ™ π ø¡ E § ∂ ° à √À
8.4.1 ¶ÚԉȷÁڷʤ˜
Οι δύο οµάδες αναπτύσσουν προδιαγραφές για τη λειτουργικότητα και τη χρήση του
υπό ανάπτυξη λογισµικού. Οι προδιαγραφές λειτουργικότητας περιγράφουν την
απαιτούµενη εξωτερική συµπεριφορά του λογισµικού σε κάθε περίπτωση. Οι προ-
διαγραφές χρήσης ορίζουν σενάρια χρήσης, τα οποία εξαντλούν τις δυνατότητες του
λογισµικού, µαζί µε την πιθανότητα εµφάνισης κάθε σεναρίου. Οι προδιαγραφές λει-
τουργικότητας αποτελούν τη βάση της αυξητικής ανάπτυξης, ενώ οι προδιαγραφές
χρήσης χρησιµοποιούνται για τη σχεδίαση περιπτώσεων στατιστικού ελέγχου κατά
την πιστοποίηση του λογισµικού.
Για την καλύτερη απόδοση της διαδικασίας, συστήνεται στις δύο οµάδες να χρησι-
µοποιούν τυπικές τεχνικές προδιαγραφής του λογισµικού, οι οποίες περιγράφουν
αφαιρετικούς τύπους δεδοµένων ή αντικείµενα και ενσωµατώνουν την αρχή της ανα-
φορικής ακεραιότητας (referential integrity). Υπενθυµίζουµε ότι η τελευταία περι-
λαµβάνει κανόνες που απαγορεύουν την εφαρµογή λειτουργιών οι οποίες πιθανόν
να προσβάλλουν την ακεραιότητα των δεδοµένων (π.χ. η διαγραφή µιας εγγραφής
από έναν πίνακα προκαλεί τη διαγραφή όλων των εγγραφών που είναι διασυνδεµέ-
νες µε αυτή και δεν διαθέτουν πρωτεύον κλειδί). Κάθε αντικείµενο των προδιαγρα-
φών µπορεί να οριστεί και να αναλυθεί στη συνέχεια µε µια προσέγγιση ανάλογη µε
την κατά βήµα εκλέπτυνση.
8.4.2 ™¯Â‰›·ÛË ·˘ÍËÙÈ΋˜ ·Ó¿Ù˘Í˘
Με βάση τις προδιαγραφές, οι δύο οµάδες σχεδιάζουν, από τα αρχικά στάδια της
διαδικασίας, τις διαφορετικές εκδόσεις του λογισµικού, οι οποίες θα οδηγήσουν στην
ανάπτυξη της τελικής µορφής του λογισµικού. Κάθε έκδοση βασίζεται στην προη-
γούµενη, αλλά αναπτύσσεται ανεξάρτητα εφαρµόζοντας τη διαδικασία του «καθα-
ρού δωµατίου».
Η διαδικασία του «καθαρού δωµατίου» είναι «γρήγορη και καθαρή», όχι «γρήγορη
και βρώµικη». Η γενική ιδέα είναι να αναπτυχθεί γρήγορα το σωστό προϊόν, του οποί-
ου η ποιότητα θα είναι υψηλή, να παραδοθεί στους χρήστες και στη συνέχεια να ανα-
πτυχθεί µια νέα έκδοση, όπου θα έχουν ληφθεί υπόψη οι παρατηρήσεις των χρηστών.
8.4.3 ™¯Â‰›·ÛË Î·È Â·Ï‹ı¢ÛË
Η οµάδα ανάπτυξης ακολουθεί έναν κύκλο σχεδίασης – ανάπτυξης – επαλήθευσης για
κάθε έκδοση του λογισµικού. Παράλληλα, η οµάδα πιστοποίησης σχεδιάζει περιπτώ-
σεις ελέγχου κατάλληλες για την αναµενόµενη χρήση της συγκεκριµένης έκδοσης.
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 188
Κατά τη σχεδίαση των διαδικασιών, ορίζονται οι επιθυµητές λειτουργίες του λογι-
σµικού. Καθεµία από αυτές αναλύεται σε µια δοµή ελέγχου και ένα νέο σύνολο επι-
θυµητών λειτουργιών. Για την κωδικοποίησή τους, χρησιµοποιούνται οι δοµές ελέγ-
χου του δοµηµένου διαδικασιακού προγραµµατισµού (ακολουθία, απόφαση, επα-
νάληψη), οι οποίες δεν προκαλούν παρενέργειες, επειδή έχουν µια είσοδο και µια
έξοδο µόνο. Μια δοµή ελέγχου απλά µετατρέπει ένα σύνολο δεδοµένων εισόδου σε
ένα σύνολο δεδοµένων εξόδου, µε τον ίδιο τρόπο µε τον οποίο µια µαθηµατική
συνάρτηση ορίζει µια απεικόνιση του πεδίου ορισµού στο πεδίο τιµών της.
Η επαλήθευση της ορθότητας κάθε δοµής ελέγχου γίνεται υπολογίζοντας τη συνάρ-
τηση που αυτή υλοποιεί και συγκρίνοντάς την µε την επιθυµητή λειτουργία. Η
σύγκριση χρησιµοποιεί ένα θεώρηµα ορθότητας, το οποίο ορίζει τον τρόπο εφαρ-
µογής σε κάθε δοµή ελέγχου ενός συνόλου συνθηκών ορθότητας.
8.4.4 ¶ÈÛÙÔÔ›ËÛË ÔÈfiÙËÙ·˜
Κάθε νέα έκδοση του λογισµικού ενσωµατώνεται από την οµάδα ανάπτυξης στις
προηγούµενες εκδόσεις και παραδίδεται στην οµάδα πιστοποίησης. Αυτή εφαρµό-
ζει στατιστικό έλεγχο µε βάση τις περιπτώσεις ελέγχου που έχει σχεδιάσει και ελέγ-
χει τα αποτελέσµατα σε σχέση µε τις προδιαγραφές λειτουργικότητας.
Η οµάδα πιστοποίησης πρέπει να έχει καλή γνώση των τρόπων µε τους οποίους οι
χρήστες θα χρησιµοποιήσουν το λογισµικό: ο στατιστικός έλεγχος ουσιαστικά ελέγ-
χει το λογισµικό σε συνθήκες παρόµοιες µε τις πραγµατικές. Στη συνέχεια χρησι-
µοποιεί ένα µοντέλο πιστοποίησης της ποιότητας για να εκτιµήσει την ποιότητα του
λογισµικού (π.χ. υπολογίζοντας το µέσο χρόνο µέχρι την εµφάνιση του επόµενου
σφάλµατος).
Η πιστοποίηση εφαρµόζεται σε όλη τη διάρκεια του κύκλου ανάπτυξης, καθώς νέες
εκδόσεις του λογισµικού αυξάνουν τη λειτουργικότητα των παλαιότερων εκδόσεων.
Συνέπεια αυτής της προσέγγισης είναι να ελέγχονται περισσότερες φορές τα τµή-
µατα του λογισµικού που υλοποιήθηκαν πρώτα, τα οποία συνήθως είναι τα σηµα-
ντικότερα και πιο γενικά. Στην πράξη, η πιστοποίηση της ποιότητας περιλαµβάνει
τρια βήµατα:
• Καθορισµός όλων των πιθανών σεναρίων και τρόπων χρήσης, στα οποία περι-
λαµβάνονται και λανθασµένοι τρόποι χρήσης, µαζί µε την πιθανότητα εµφάνι-
σης του καθενός. Ο καθορισµός γίνεται µε βάση τις προδιαγραφές λειτουργικό-
τητας και χρησιµοποιώντας πληροφορίες από διάφορες πηγές, όπως συνεντεύ-
ξεις µε τους χρήστες και µελέτη του τρόπου χρήσης προηγούµενων εκδόσεων.
1 8 9 8 . 4 § √° π ™ ªπ ∫ √ à øƒ π ™ ∂ § ∞∆ ∆ øª∞∆∞
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 189
1 9 0 K E ºA § A I O 8 : E º∞ ƒ ª√° ∏ ∆ ø¡ ¢ π ∞ ¢ π ∫ ∞ ™ π ø¡ E § ∂ ° à √À
• Σχεδίαση περιπτώσεων ελέγου, οι οποίες προκύπτουν µε τυχαίο τρόπο από τα
πιθανά σενάρια χρήσης. Η διαδικασία αυτή µπορεί να αυτοµατοποιηθεί, καθώς οι
περιπτώσεις ελέγχου καθορίζονται πλήρως από τους δυνατούς τρόπους χρήσης.
• Εφαρµογή των περιπτώσεων ελέγχου, εκτίµηση των αποτελεσµάτων και υπολο-
γισµός των µετρικών ποιότητας. Στο σηµείο αυτό εκτελείται για πρώτη φορά το
λογισµικό από την οµάδα πιστοποίησης, η οποία εφαρµόζει τις περιπτώσεις ελέγ-
χου και συγκρίνει τα αποτελέσµατα µε τις αρχικές προδιαγραφές. Ταυτόχρονα,
καταγράφει το χρόνο λειτουργίας του λογισµικού µέχρι να εµφανιστεί το πρώτο
ελάττωµα, καθώς και άλλες µετρικές για τον υπολογισµό των παραγόντων ποιό-
τητας του λογισµικού.
8.4.5 ∞Ó¿‰Ú·ÛË
Τα ελαττώµατα που εντοπίζονται από την οµάδα πιστοποίησης αναφέρονται προς
διόρθωση στην οµάδα ανάπτυξης. Εάν η ποιότητα του λογισµικού είναι χαµηλή, οι
οµάδες σχεδιάζουν και τη βελτίωση της διαδικασίας.
Θεωρητικά, δεν είναι δυνατό να γνωρίζει κανείς µε βεβαιότητα ότι ένα λογισµικό δεν
έχει κανένα ελάττωµα. Είναι όµως δυνατό να συµπεράνουµε µε µεγάλη πιθανότητα
ότι ο αριθµός των ελαττωµάτων έχει σχεδόν µηδενιστεί, καθώς αυξάνεται ο αριθµός
των δοκιµαστικών εκτελέσεων του προγράµµατος, οι οποίες δεν εµφάνισαν σφάλµα.
ªÂϤÙË ÂÚ›ÙˆÛ˘ 8.1
Η σύγκριση ανάµεσα στις παραδοσιακές µεθοδολογίες ανάπτυξης λογισµικού και
τη µεθοδολογία του «καθαρού δωµατίου» έχει νόηµα µόνο εάν ξεκινήσει από την
πρώτη εκτέλεση του προγράµµατος. Πρέπει να θυµόµαστε ότι οι παραδοσιακές µεθο-
δολογίες ανάπτυξης περιλαµβάνουν εκτεταµένο έλεγχο κατά τη φάση της κωδικο-
ποίησης των µονάδων λογισµικού.
Έτσι, κατά τον έλεγχο µονάδων, ένα τυπικό λογισµικό µπορεί να εµφανίσει από 25
έως 35 ελαττώµατα ανά 1000 γραµµές κώδικα (KLOC). Αντιπαραβάλλετε τον αριθ-
µό αυτό µε τα 2,3 ελαττώµατα ανά KLOC που εµφάνισαν 17 έργα ανάπτυξης λογι-
σµικού, συνολικού όγκου 1000 KLOC, τα οποία υιοθέτησαν διαδικασίες «καθαρού
δωµατίου». Ενδεικτικά, αναφέρονται τα ακόλουθα έργα:
• Έργο ελέγχου δορυφόρων της NASA (1989): Aνάπτυξη του Coarse/Fine Attitude
Determination System, περιλαµβάνει 40 KLOC Fortran και παρουσίασε ρυθµό
εµφάνισης σφαλµάτων 4,5 ανά KLOC.
• Έργα δορυφόρων της NASA (1991): Ως συνέχεια του πρώτου έργου, η NASA
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 190
ανέπτυξε τα attitude determination subsystem (20 KLOC) και flight – dynamics
subsystem (150 KLOC), τα οποία εµφάνισαν συνδυασµένο ρυθµό σφαλµάτων
4,2 ανά KLOC.
• Έργο σχεσιακής βάσης δεδοµένων (1992): Aνάπτυξη του Martin Marietta
Automated Documentation System, σε 1,3 KLOC Foxbase, το οποίο παρουσία-
σε 0 σφάλµατα ανά KLOC (!)
• Έργο ανάπτυξης λειτουργικού συστήµατος Ericsson (1993): Aνάπτυξη του OS32,
ενός 350 KLOC λειτουργικού συστήµατος για προϊόντα της εταιρείας, παρου-
σίασε µόλις 1 σφάλµα ανά KLOC.
1 9 1 8 . 4 § √° π ™ ªπ ∫ √ à øƒ π ™ ∂ § ∞∆ ∆ øª∞∆∞
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 191
1 9 2 K E ºA § A I O 8 : E º∞ ƒ ª√° ∏ ∆ ø¡ ¢ π ∞ ¢ π ∫ ∞ ™ π ø¡ E § ∂ ° à √À
™‡ÓÔ„Ë
Στο τελευταίο κεφάλαιο του τόµου παρουσιάστηκαν τέσσερα ζητήµατα που σχετίζο-
νται µε την πρακτική εφαρµογή των διαδικασιών εγκυροποίησης. Όλα αυτά τα ζητή-
µατα αποτελούν ανοιχτά πεδία έρευνας και συνιστούν τις κατευθύνσεις µελλοντικής
εξέλιξης της εγκυροποίησης.
Η εγκυροποίηση του λογισµικού θα είναι πάντα απαραίτητη. Όλο και περισσότεροι
διαχειριστές έργων πείθονται για τα πλεονεκτήµατα της συνεχούς (καθ’ όλη τη διάρ-
κεια της ανάπτυξης) εγκυροποίησης του λογισµικού. Ισχυρά εργαλεία που προάγουν
την ενσωµάτωση δραστηριοτήτων εγκυροποίησης είναι οι νέες τεχνικές που παρου-
σιάστηκαν στο κεφάλαιο αυτό. Οι τεχνικές αυτές υπόσχονται να µειώσουν το κόστος
της εγκυροποίησης, υιοθετώντας την προσέγγιση ότι ο δυναµικός έλεγχος του λογι-
σµικού πρέπει να αρχίσει αφού διάφορες τεχνικές στατικού ελέγχου (π.χ. τυπική επα-
λήθευση, ελεγξιµότητα κ.ά.) αφαιρέσουν τα περισσότερα από τα ελαττώµατα.
Ο διαχειριστής του έργου, ο οποίος είναι συνήθως υπεύθυνος για την εγκυροποίηση,
µπορεί να χρησιµοποιήσει εργαλεία λογισµικού, τα οποία αυτοµατοποιούν πολλές
από τις δραστηριότητες ανάπτυξης, ανάµεσά τους και τις διαδικασίες εγκυροποίησης.
Ακόµη καλύτερα, µπορεί από την αρχή να υιοθετήσει µια συγκεκριµένη µεθοδολογία
(διαδικασία «καθαρού δωµατίου»), η οποία, εάν εφαρµοστεί σωστά, υπόσχεται να
οδηγήσει στην ανάπτυξη λογισµικού χωρίς ελαττώµατα.
µÈ‚ÏÈÔÁÚ·Ê›·
[1] R. C. Linger (1994), «Cleanroom process model». IEEE Software, 11(2), pp 50
– 58.
[2] R. Pressman (1994), Software Engineering: a practitioner’s approach. McGraw
– Hill, England.
[3] I. Sommerville (1996), Software Engineering. Addison – Wesley, USA
[4] J. Voas and K. Miller (1995), «Software Testability: the new verification». IEEE
Software, 12(3), pp 17 – 28.
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 192
∂›ÏÔÁÔ˜
Είµαι βέβαιος ότι θα αισθάνεστε µεγάλη ικανοποίηση τώρα που τελειώσατε αυτό το
βιβλίο. Μετά από τόσες ώρες µελέτης και αφού «παλέψατε» µε τόσες ασκήσεις και
δραστηριότητες (µερικές από αυτές ήταν πραγµατικά δύσκολες), µπορείτε να ισχυ-
ριστείτε ότι γνωρίζετε το αντικείµενο της «εγκυροποίησης λογισµικού». Μπορείτε
λοιπόν να περιγράψετε τις τεχνικές εγκυροποίησης (τυπικές και µη τυπικές, στατι-
κές και δυναµικές), να σχεδιάσετε περιηγήσεις και επισκοπήσεις και να εφαρµόσε-
τε τη συµβολική εκτέλεση και την ανάλυση ευαισθησίας. Γνωρίζετε τις δύσκολες
µεθόδους του λειτουργικού και του δοµικού ελέγχου και τις τεχνικές ελέγχου διε-
παφών και µπορείτε να σχεδιάσετε και να εφαρµόσετε δραστηριότητες δοκιµών και
τεχνικές εκσφαλµάτωσης.
Το σηµαντικότερο είναι ότι αποκτήσατε µια γενικότερη αντίληψη περί εξασφάλισης
της ποιότητας και της αξιοπιστίας του λογισµικού, η οποία ελπίζω να διαποτίσει την
όποια ενασχόλησή σας µε την πληροφορική. Ελπίζω το τέλος αυτού του βιβλίου να
είναι η αρχή ενός καινούριου κόσµου για σας. Ενός κόσµου όπου το λογισµικό έχει
τα λιγότερα δυνατά σφάλµατα και την υψηλότερη ποιότητα. Ενός κόσµου όπου κι
εσείς συµβάλλετε στην παραγωγή έγκυρου, πιστοποιηµένου, αξιόπιστου λογισµι-
κού.
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 193
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 194
∞·ÓÙ‹ÛÂȘ ·Û΋ÛÂˆÓ ·˘ÙÔ·ÍÈÔÏfiÁËÛ˘
3.1
Οι σωστές απαντήσεις είναι οι εξής (προσέξτε: οι απαντήσεις δίνονται αφού τα ερω-
τήµατα έχουν οµαδοποιηθεί ανά τεχνική, ώστε να διευκολυνθείτε στην αντιπαρα-
βολή του σωστού µε τον λανθασµένο ισχυρισµό):
Σ Λ
Ο στόχος της συµβολικής εκτέλεσης είναι να προσδιορίσουµε
τις περιοχές τιµών των µεταβλητών για τις οποίες αλλάζει η ροή
εκτέλεσης του προγράµµατος. ❏


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

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

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


Η προσοµοίωση στοχεύει στην όσο το δυνατό καλύτερη αναπαράσταση του πραγ-
µατικού περιβάλλοντος λειτουργίας και χρήσης του συστήµατος. Σηµειώστε ότι στα
σενάρια χρήσης µπορεί να περιλαµβάνονται και περιπτώσεις (εκούσιας ή ακούσιας)
λανθασµένης χρήσης του συστήµατος.
Σ Λ
Ο στόχος της ανάλυσης ευαισθησίας είναι να διορθώσει ακόµη
και τα µικρότερα λάθη που υπάρχουν στο λογισµικό. ❏ ❏

K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 195
1 9 6 E ° ∫ À ƒ √¶√π ∏™ ∏ § √° π ™ ªπ ∫ √À
Κατά την ανάλυση ευαισθησίας εξετάζουµε τη σοβαρότητα
των επιπτώσεων και το βαθµό διάδοσης ενός σφάλµατος. ❏


Κατά την ανάλυση ευαισθησίας προσπαθούµε να ανακαλύψουµε το όριο δοκιµών
πέρα από το οποίο µπορούµε να πείσουµε ότι το λογισµικό µας «λειτουργεί σωστά».
Για το σκοπό αυτό εξετάζουµε τη σοβαρότητα της επίπτωσης που έχουν στο λογι-
σµικό διάφορα σφάλµατα που εισάγουµε εσκεµµένα. Η ανάλυση ευαισθησίας µας
βοηθά να µελετήσουµε τον τρόπο µε τον οποίο τα σφάλµατα αυτά προκαλούν πιθα-
νή αστοχία του λογισµικού, αλλά δεν τα διορθώνει κιόλας!
4.1
Όλοι οι ισχυρισµοί είναι λανθασµένοι! Στην ενότητα 4.1 έχουµε αναφέρει ότι (α)
δεν µπορεί κάποιος να ισχυριστεί ότι έχει δοκιµάσει εξαντλητικά ένα πρόγραµµα
(εκτός και αν πρόκειται για πολύ µικρά υποπρογράµµατα) και (β) οι δοκιµές ενός
προγράµµατος, όσο εξαντλητικές και αν είναι, δεν µπορούν να αποδείξουν την απου-
σία ελαττωµάτων.
Παρ’ όλο που η οµάδα ανάπτυξης έχει συµφέρον να µην ανακαλύψει ελαττώµατα,
έχει επίσης συµφέρον να παραδώσει ένα λογισµικό που λειτουργεί (αρχή του ικα-
νού προγραµµατιστή). Έτσι, η οµάδα ανάπτυξης καλό είναι να δοκιµάζει το λογι-
σµικό στα αρχικά στάδια ανάπτυξης, ενώ στη συνέχεια ο έλεγχος συνεχίζεται από
την οµάδα δοκιµής. Αυτό, βέβαια, δε σηµαίνει ότι η οµάδα ανάπτυξης «παραδίδει»
αδοκίµαστο το λογισµικό στα µέλη της οµάδας δοκιµής, τα οποία θα το δοκιµάσουν
«ανελέητα». Αντίθετα, οι δύο οµάδες συνεργάζονται καθ’ όλη τη διάρκεια της σχε-
δίασης και ανάπτυξης του λογισµικού, αλλά και κατά τη διάρκεια του ελέγχου. Πολ-
λές φορές, οι φάσεις αυτές µπορεί να εκτελούνται και µε σηµαντική χρονική επικά-
λυψη, οπότε η οµάδα δοκιµής ελέγχει ένα τµήµα του λογισµικού, ενώ η οµάδα ανά-
πτυξης υλοποιεί ένα άλλο.
Η εφαρµογή δραστηριοτήτων ελέγχου νωρίς στο χρονοδιάγραµµα ανάπτυξης µε τη
συνεργασία της οµάδας δοκιµής έχει αποδειχθεί στην πράξη ότι µειώνει το χρόνο
των δραστηριοτήτων ελέγχου και αυξάνει τον αριθµό των ελαττωµάτων που ανα-
καλύπτονται στα αρχικά στάδια ανάπτυξης. Η ανάγκη ελέγχου του λογισµικού προ-
κύπτει από τη φύση και τη σηµασία του λογισµικού, αλλά και από το δυναµικό χαρα-
κτήρα των µεθοδολογιών ανάπτυξης.
4.2
Οι σωστές απαντήσεις έχουν ως εξής:
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 196
(α)Σύµφωνα µε αυτά που αναφέρονται στην ενότητα 4.4.1, η µεταβλητή παίρνει
τιµές από ένα πεδίο τιµών, άρα πρέπει να σχεδιάσουµε τις εξής τρεις περιπτώσεις
ελέγχου:
Χ <1 1 < Χ < 10 Χ > 10
(β) Σύµφωνα µε αυτά που αναφέρονται στην ενότητα 4.4.2, η µεταβλητή παίρνει
τιµές από ένα πεδίο τιµών, άρα πρέπει να σχεδιάσουµε τις εξής επιπλέον περι-
πτώσεις ελέγχου:
Χ = 1 Χ = 1,0001 Χ = 10 Χ = 9,9999
(γ) Σύµφωνα µε αυτά που αναφέρονται στην ενότητα 4.4.1, στην περίπτωση αυτή,
η µεταβλητή παίρνει τιµές από ένα σύνολο τιµών, άρα πρέπει να σχεδιάσουµε τις
εξής δύο περιπτώσεις ελέγχου:
Χ βρίσκεται στον Α Χ δεν βρίσκεται στον Α
Εάν απαντήσατε σωστά σε όλες τις ερωτήσεις, συγχαρητήρια! Έχετε κατανοήσει τη
φιλοσοφία των τεχνικών διαµέρισης και ανάλυσης οριακών τιµών. Εάν κάνατε
κάποια λάθη, καλύτερα να επαναλάβετε τις ενότητες 4.4.1 και 4.4.2. Το σηµείο –
κλειδί είναι η σωστή αναγνώριση του είδους των τιµών που παίρνει η µεταβλητή.
4.3
Η σωστή σειρά των βηµάτων αναφέρεται στην αρχή της ενότητας 4.4.3 και είναι:
(α)Προσδιορισµός αιτίων και ενεργειών.
(β) Σχεδίαση του γραφήµατος αιτίου – αποτελέσµατος (µε βάση το σκεπτικό ότι τα
αίτια προκαλούν κάποιες ενέργειες από πλευράς του προγράµµατος).
(γ) Σχεδίαση πίνακα αποφάσεων (µε βάση το γράφηµα προσδιορίζεται το πραγµα-
τικό σύνολο των κανόνων που προκαλούν τις ενέργειες).
(δ) Σχεδίαση περιπτώσεων ελέγχου (ώστε να δοκιµάζεται η ορθή και η λανθασµένη
εκτέλεση κάθε κανόνα).
4.4
Η σωστή απάντηση έχει ως εξής:
Οι τεχνικές ελέγχου αδιαφανούς κουτιού χρησιµοποιούν τις προδιαγραφές εισό-
δου/εξόδου για τη σχεδίαση των περιπτώσεων ελέγχου. Η βάση των τεχνικών αυτών
είναι η διαµέριση σε κλάσεις ισοδυναµίας των δεδοµένων εισόδου, δηλαδή η οµαδο-
ποίηση των δεδοµένων ελέγχου µε βάση τους περιορισµούς εισόδου που ισχύουν
1 9 7 ∞ ¶∞ ¡∆ ∏™ ∂ π ™ ∞ ™ ∫ ∏™ ∂ ø¡ ∞ À ∆ √∞ •π √§ √° ∏™ ∏™
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 197
1 9 8 E ° ∫ À ƒ √¶√π ∏™ ∏ § √° π ™ ªπ ∫ √À
στο υπό δοκιµή πρόγραµµα. Η τεχνική αυτή συνήθως συµπληρώνεται µε την ανά-
λυση οριακών τιµών, κατά την οποία δοκιµάζεται η συµπεριφορά του προγράµµα-
τος όταν τα δεδοµένα ελέγχου λαµβάνουν ακραίες τιµές σε σχέση µε τους ισχύοντες
περιορισµούς. Εναλλακτικά, µπορούν να χρησιµοποιηθούν τα γραφήµατα αιτίου –
αποτελέσµατος για να αναπαραστήσουν τον τρόπο µε τον οποίο οι έξοδοι του προ-
γράµµατος εξαρτώνται από τους περιορισµούς που ισχύουν στα δεδοµένα εισόδου.
Οι υπόλοιπες φράσεις δεν έχουν θέση σε αυτό το κείµενο (στην πραγµατικότητα
είναι όροι που συναντώνται στην ενότητα 4.5). Εάν απαντήσατε σωστά, συγχαρη-
τήρια! Έχετε κατανοήσει την ουσία των τεχνικών ελέγχου αδιαφανούς κουτιού. Εάν
κάνατε κάποια λάθη, καλύτερα να ανατρέξετε στη σχετική ενότητα και να µελετή-
σετε ξανά την περιγραφή της τεχνικής.
4.5
Η σωστή αντιστοίχιση φαίνεται στη συνέχεια:
Αρχείο ∆ιαµέριση σε κλάσεις ισοδυναµίας
Υπολογισµός µικτής αµοιβής Ανάλυση οριακών τιµών
Υπολογισµός κρατήσεων Γράφηµα αιτίου – αποτελέσµατος
Παραγωγή αναφορών Συγκριτική δοκιµή
Τα τµήµατα εκείνα (αρχείο, υπολογισµός µικτής αµοιβής) που χρησιµοποιούν πολύ-
πλοκα δεδοµένα ή δοµές δεδοµένων είναι λογικό να δοκιµαστούν διαµερίζοντας τα
δεδοµένα σε κλάσεις ισοδυναµίας και ταυτόχρονα αναλύοντας τις περιπτώσεις εκτέ-
λεσης µε οριακά δεδοµένα. Για το τµήµα υπολογισµού κρατήσεων προτιµούµε να
χρησιµοποιήσουµε γράφηµα αιτίου – αποτελέσµατος, ώστε να ελέγξουµε τη συµπε-
ριφορά του προγράµµατος ανάλογα µε τον κάθε δόκιµο συνδυασµό περιορισµών
στα δεδοµένα εισόδου που θα προκύψει από τον πίνακα αποφάσεων. Τέλος, το υπο-
σύστηµα παραγωγής αναφορών θα το ελέγξουµε κατ’ αντιπαράθεση µε το προη-
γούµενο πρόγραµµα, ώστε να διασφαλίσουµε ότι θα διατηρηθεί η υπάρχουσα λει-
τουργικότητα.
Εάν απαντήσατε σωστά, έχετε καταφέρει κάτι σηµαντικό: γνωρίζετε πότε πρέπει να
εφαρµόσετε την κάθε τεχνική (αν και πρέπει να θυµάστε ότι ποτέ δεν αρκεί µια µόνο
τεχνική). Εάν δεν τα καταφέρατε, σας συνιστώ να επαναλάβετε την ενότητα 4.4 και
να ξαναδοκιµάσετε.
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 198
4.6
Η σωστή σειρά εφαρµογής των βηµάτων της τεχνικής δοκιµής των βασικών µονο-
πατιών εκτέλεσης, όπως περιγράφεται στην ενότητα 4.5.1, είναι η εξής:
1. σχεδίαση του γραφήµατος ροής που αντιστοιχεί στο υπό δοκιµή πρόγραµµα
2. υπολογισµός της κυκλωµατικής πολυπλοκότητας του γραφήµατος ροής
3. υπολογισµός ενός συνόλου βασικών (γραµµικά ανεξάρτητων) µονοπατιών εκτέ-
λεσης
4. σχεδίαση περιπτώσεων ελέγχου που εκτελούν κάθε βασικό µονοπάτι.
4.7
Η κυκλωµατική πολυπλοκότητα του αλγορίθµου είναι 4, συνεπώς πρέπει να δοκι-
µάσουµε τέσσερα διαφορετικά µονοπάτια εκτέλεσης. Εάν ρίξετε µια µατιά στις συν-
θήκες εκτέλεσης των τµηµάτων κώδικα που αναφέρονται στο Παράδειγµα 3.1, θα
δείτε ότι ουσιαστικά περιγράφουν τέσσερα διαφορετικά µονοπάτια εκτέλεσης (το
τµήµα κώδικα 2 εκτελείται σε δύο διαφορετικές περιπτώσεις). Με βάση τις συνθή-
κες αυτές, σχεδιάζουµε τις εξής περιπτώσεις ελέγχου:
1 9 9 ∞ ¶∞ ¡∆ ∏™ ∂ π ™ ∞ ™ ∫ ∏™ ∂ ø¡ ∞ À ∆ √∞ •π √§ √° ∏™ ∏™
∆Ε∆ΟΜΕΝΑ ΕΛΕΓΧΟΥ ΑΝΑΜΕΝΟΜΕΝΑ ΑΠΟΤΕΛΕΣΜΑΤΑ
Μονοπάτι 1
Α < Χ Το πρόγραµµα τερµατίζει επιτυχώς και εκτελείται
το ΤΜΗΜΑ 1.
Μονοπάτι 2
Α >= Χ AND B >= 1 Το πρόγραµµα τερµατίζει επιτυχώς και εκτελείται
το ΤΜΗΜΑ 2.
Μονοπάτι 3
A >= X AND B =< – 1 Το πρόγραµµα τερµατίζει επιτυχώς και εκτελείται
το ΤΜΗΜΑ 2.
Μονοπάτι 4
A >= X AND – 1 < B < 1 Το πρόγραµµα τερµατίζει επιτυχώς και εκτελείται
το ΤΜΗΜΑ 3.
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 199
2 0 0 E ° ∫ À ƒ √¶√π ∏™ ∏ § √° π ™ ªπ ∫ √À
Εάν βρήκατε τις περιπτώσεις ελέγχου, συγχαρητήρια! Έχετε αποδεδειγµένα πλέον
την ικανότητα να εφαρµόζετε την τεχνική ελέγχου βασικών µονοπατιών εκτέλεσης.
Εάν δεν τα καταφέρατε, είµαι σίγουρος ότι δεν δώσατε αρκετή προσοχή. Καλύτερα
να επαναλάβετε την ενότητα 4.5.1 και τη δραστηριότητα 5.
Παρατηρήστε ότι τόσο η εφαρµογή της δοκιµής βασικών µονοπατιών, όσο και της
συµβολικής εκτέλεσης, στον αλγόριθµο αυτό έχουν ισοδύναµο αποτέλεσµα. Σε
τέτοια περίπτωση, ίσως είναι προτιµότερο να χρησιµοποιήσουµε την τεχνική της
συµβολικής εκτέλεσης αντί της αναζήτησης των βασικών µονοπατιών για τη σχε-
δίαση των δεδοµένων ελέγχου. Για να πειστείτε, προσπαθήστε να σχεδιάσετε τα
δεδοµένα ελέγχου µόνο κοιτάζοντας το διάγραµµα 3.1. ∆εν είναι πιο εύκολο; ∆εν
είναι εµφανές ότι η περίπτωση B + C = 0 χρειάζεται ιδιαίτερη προσοχή; (κάτι που
δεν προκύπτει από την τεχνική δοκιµής βασικών µονοπατιών).
4.8
Ο γενικός κανόνας που θα χρησιµοποιήσουµε για να απαντήσουµε στην άσκηση
αυτή είναι ότι η συµβολική εκτέλεση είναι πιο «οικονοµική», όταν πρόκειται για
συνηθισµένες συνθήκες εκτέλεσης του προγράµµατος, ενώ για τις οριακές ή λαν-
θασµένες περιπτώσεις είναι ασφαλέστερο να εκτελέσουµε το πρόγραµµα µε δεδο-
µένα ελέγχου. Με βάση αυτά, οι σωστές απαντήσεις είναι οι εξής:
ΣΤΟΧΟΙ ΣΤΑΤΙΚΗ ΕΛΕΓΧΟΣ
ΑΝΑΛΥΣΗ
Έλεγχος αποτελέσµατος για συνηθισµένες τιµές
του µετρητή και ανεξάρτητα από τις τιµές
του πίνακα
Έλεγχος αποτελέσµατος για οριακές αλλά
σωστές τιµές του µετρητή
Έλεγχος αποτελέσµατος για οριακές αλλά
λανθασµένες τιµές του µετρητή
Έλεγχος αποτελέσµατος για πίνακα ενός
στοιχείου
Έλεγχος αποτελέσµατος για πίνακα πολλών
στοιχείων
Έλεγχος αποτελέσµατος για κενό πίνακα
Η άσκηση αυτή ήταν πραγµατικά δύσκολη και σας αξίζει ένα µεγάλο «µπράβο» εάν
απαντήσατε σωστά. Εάν όµως δεν τα καταφέρατε, µην απογοητεύεστε. Με την
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 200
πρώτη ευκαιρία διαβάστε µαζί τις ενότητες 3.1 και 4.5.2 και προσπαθήστε ξανά!
4.9
Η σωστή απάντηση είναι η εξής:
Οι τεχνικές ελέγχου διαφανούς κουτιού σχεδιάζουν τις περιπτώσεις ελέγχου µε βάση
την περιγραφή του κώδικα του λογισµικού. Όλες οι τεχνικές της κατηγορίας αυτής
ξεκινούν από τη δοκιµή διαφόρων µονοπατιών εκτέλεσης του κώδικα, προσπαθώ-
ντας να εκτελέσουν όλες τις εντολές χωρίς να εκτελέσουν όλα τα µονοπάτια και ταυ-
τόχρονα να καλύψουν όσο το δυνατό περισσότερους από τους πιθανούς τρόπους
χρήσης του λογισµικού.
Η πιο διαδεδοµένη τεχνική είναι η δοκιµή βασικών µονοπατιών, όπου χρησιµοποιεί-
ται το γράφηµα ροής για τον υπολογισµό της κυκλωµατικής πολυπλοκότητας του προ-
γράµµατος, µε στόχο να συµπεράνουµε τον ελάχιστο αριθµό µονοπατιών εκτέλεσης
που χρειάζεται να δοκιµαστούν ώστε να εκτελεστούν όλες οι εντολές. Εάν το πρό-
γραµµα περιέχει επαναλήψεις, τότε εφαρµόζουµε συµπληρωµατικά δοκιµές δοµών
επανάληψης. Το µειονέκτηµα αυτής της τεχνικής είναι ότι υπαγορεύει τη σχεδίαση
πολλών περιπτώσεων ελέγχου, όταν οι επαναλήψεις είναι φωλιασµένες, γι’ αυτό πολ-
λές φορές προτιµάται στην περίπτωση αυτή η συµβολική εκτέλεση του προγράµµατος.
Κάποιες από τις φράσεις δεν έχουν θέση σε αυτό το κείµενο, αλλά είναι όροι που
συναντώνται στην ενότητα 4.4. Εάν απαντήσατε σωστά σε αυτό το δύσκολο κείµε-
νο, συγχαρητήρια! Κατέχετε την ουσία των τεχνικών ελέγχου διαφανούς κουτιού και
µπορείτε να τις διαχωρίσετε από τις τεχνικές αδιαφανούς κουτιού. Εάν κάνατε κάποια
λάθη, καλύτερα να µελετήσετε ξανά τις τεχνικές που περιγράφονται στην ενότητα
4.5, συγκρίνοντας τα βασικά τους χαρακτηριστικά και σε αντιδιαστολή µε τις τεχνι-
κές αδιαφανούς κουτιού που περιγράφονται στην ενότητα 4.4.
5.1
Ο πίνακας πρέπει να συµπληρωθεί ως εξής:
ΤΜΗΜΑ Ο∆ΗΓΟΙ ΣΤΕΛΕΧΗ
Αρχείο Λογιστήριο Ατοµικά στοιχεία
Στοιχεία εργασίας
Αναφορές Λογιστήριο ―
Ατοµικά στοιχεία Αρχείο ―
Υπολογισµός µικτής αµοιβής Μισθοδοσία ―
2 0 1 ∞ ¶∞ ¡∆ ∏™ ∂ π ™ ∞ ™ ∫ ∏™ ∂ ø¡ ∞ À ∆ √∞ •π √§ √° ∏™ ∏™
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 201
2 0 2 E ° ∫ À ƒ √¶√π ∏™ ∏ § √° π ™ ªπ ∫ √À
Μισθοδοσία Λογιστήριο Υπολ. Μικτής αµοιβής
Υπολ. Κρατήσεων
Στοιχεία εργασίας Αρχείο ―
Υπολογισµός κρατήσεων Μισθοδοσία ―
Εάν τα καταφέρατε συγχαρητήρια! Έχετε κατανοήσει το ρόλο των οδηγών και των
στελεχών κατά τον έλεγχο συγκρότησης ενός λογισµικού, κάτι που θα διευκολύνει
τη µελέτη σας στη συνέχεια. Εάν όµως σας «ξέφυγαν» κάποιοι οδηγοί ή στελέχη,
καλύτερα να ξαναπροσπαθήσετε, αφού πρώτα µελετήσετε πιο προσεκτικά την ενό-
τητα 5.1.6 και τη µελέτη περίπτωσης που περιέχεται εκεί. Ίσως διευκολυνθείτε εάν
για κάθε τµήµα υπό δοκιµή σχεδιάσετε ένα σχήµα αντίστοιχο του Σχήµατος 5.1.
5.2
Για να απαντήσετε στην άσκηση χρειάζεται να ακολουθήσετε τα βήµατα που περι-
γράφονται στο πλαίσιο της ενότητας 5.2.1 και να έχετε κατανοήσει το Σχήµα 5.3
(στα οποία πρέπει να ανατρέξετε, εάν δεν έχετε απαντήσει σωστά). Εάν έχετε πραγ-
µατικά κατανοήσει τη διαδικασία της από πάνω προς τα κάτω συγκρότησης, θα
συµπληρώσετε τον πίνακα ως εξής:
ΤΜΗΜΑ Ο∆ΗΓΟΙ ΣΤΕΛΕΧΗ
1. Λογιστήριο ― Αρχείο
Αναφορές
Μισθοδοσία
2. Αρχείο ― Ατοµικά στοιχεία
Στοιχεία εργασίας
3. Μισθοδοσία ― Υπολ. Μικτής αµοιβής
Υπολ. Κρατήσεων
4. Αναφορές ― ―
5. Ατοµικά στοιχεία ― ―
6. Στοιχεία εργασίας ― ―
7. Υπολ. Μικτής αµοιβής ― ―
8. Υπολ. Κρατήσεων ― ―
Θεωρητικά, τα βήµατα 2, 3 και 4 µπορούν να εκτελεσθούν µε οποιαδήποτε σειρά (η
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 202
σειρά που παρατίθεται εδώ είναι αρκετά διαδεδοµένη και υλοποιεί την ακολουθία
είσοδος – επεξεργασία – έξοδος των δεδοµένων). Εάν υιοθετήσετε διαφορετική σειρά,
ίσως αντίστοιχα να διαφοροποιείται και η σειρά των βηµάτων 5 – 6 και 7 – 8.
Τα βήµατα 2, 3 και 4 πρέπει να εκτελεστούν πριν τα βήµατα 5 – 8, αφού πρόκειται
για κατά πλάτος έλεγχο συγκρότησης. Αντίθετα, στην κατά βάθος δοκιµή, η σειρά
θα ήταν 1 – 2 – 5 – 6 – 3 – 7 – 8 – 4 (ρίξτε µια µατιά στο Σχήµα 5.2, εάν δυσκολεύ-
εστε να κατανοήσετε τι σηµαίνει «κατά πλάτος» και «κατά βάθος»).
Aς σηµειωθεί ότι δεν χρειάζονται καθόλου οδηγοί κατά τη διαδικασία ελέγχου.
5.3
Για να απαντήσετε στην άσκηση χρειάζεται να ακολουθήσετε τα βήµατα που περι-
γράφονται στο πλαίσιο της ενότητας 5.2.2 και να έχετε κατανοήσει το Σχήµα 5.4
(στα οποία πρέπει να ανατρέξετε, εάν δεν έχετε απαντήσει σωστά). Εάν έχετε πραγ-
µατικά κατανοήσει τη διαδικασία της από κάτω προς τα πάνω συγκρότησης, θα
συµπληρώσετε τον πίνακα ως εξής:
ΤΜΗΜΑ Ο∆ΗΓΟΙ ΣΤΕΛΕΧΗ
1. Ατοµικά στοιχεία Αρχείο ―
2. Στοιχεία εργασίας Αρχείο ―
3. Αρχείο Λογιστήριο ―
4. Υπολ. Μικτής αµοιβής Μισθοδοσία ―
5. Υπολ. Κρατήσεων Μισθοδοσία ―
6. Μισθοδοσία Λογιστήριο ―
7. Αναφορές Λογιστήριο ―
8. Λογιστήριο ― ―
Όπως και στην προηγούµενη άσκηση, η συγκρότηση µπορεί να αρχίσει και από τα
τµήµατα υπολογισµού της µικτής αµοιβής και των κρατήσεων (οπότε η σειρά θα
είναι 4 – 5 – 6 – 1 – 2 – 3 – 7 – 8).
Aς σηµειωθεί ότι η διαδικασία δοκιµής δεν απαιτεί την ανάπτυξη στελεχών.
5.4
Το κρισιµότερο από τα τµήµατα του λογισµικού για το λογιστήριο είναι το τµήµα
της µισθοδοσίας. Πρόκειται για το τµήµα που εκτελεί τους πιο πολύπλοκους υπο-
2 0 3 ∞ ¶∞ ¡∆ ∏™ ∂ π ™ ∞ ™ ∫ ∏™ ∂ ø¡ ∞ À ∆ √∞ •π √§ √° ∏™ ∏™
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 203
2 0 4 E ° ∫ À ƒ √¶√π ∏™ ∏ § √° π ™ ªπ ∫ √À
λογισµούς, χωρίς να είναι τµήµα χαµηλού επιπέδου, ενώ πρόκειται να χρησιµοποι-
ηθεί συχνότερα από όλα τα άλλα τµήµατα και πάντα µε πολύ µικρό (έως µηδενικό)
περιθώριο λάθους. Αρχίζουµε λοιπόν τη σάντουιτς δοκιµή συγκρότησης από το
τµήµα αυτό (προχωρώντας προς τα κάτω) και συνεχίζουµε µε το τµήµα αρχείο, από
το οποίο εισέρχονται τα δεδοµένα στο σύστηµα. Το τµήµα παραγωγής αναφορών
είναι το λιγότερο κρίσιµο και ενσωµατώνεται τελευταίο:
ΤΜΗΜΑ Ο∆ΗΓΟΙ ΣΤΕΛΕΧΗ
1. Μισθοδοσία Λογιστήριο Υπολ. Μικτής αµοιβής
Υπολ. Κρατήσεων
2. Υπολ. Μικτής αµοιβής ― ―
3. Υπολ. Κρατήσεων ― ―
4. Αρχείο Λογιστήριο Ατοµικά στοιχεία
Στοιχεία εργασίας
5. Ατοµικά στοιχεία ― ―
6. Στοιχεία εργασίας ― ―
7. Αναφορές Λογιστήριο ―
8. Λογιστήριο ― ―
Η άσκηση αυτή είναι σχετικά δύσκολη και σας αξίζουν πολλά «µπράβο», εάν τα
καταφέρατε. Εάν ξεκινήσατε από άλλο τµήµα, διαβάστε πάλι τα χαρακτηριστικά των
κρίσιµων τµηµάτων που παρατίθενται στην ενότητα 5.2.3 και να θυµάστε ότι τα απο-
τελέσµατα των επιλογών ενός µηχανικού κρίνονται πάντα στην πράξη!
5.5
Ο σωστός τρόπος αντιστοίχισης είναι ο εξής (προσοχή: η σειρά των πρακτικών δοκι-
µής, για λόγους βελτίωσης της ευκρίνειας της απάντησης, είναι διαφορετική από
αυτή της εκφώνησης – καλύτερα να ελέγξετε µία προς µία τις απαντήσεις σας):
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 204
ΠΡΑΚΤΙΚΗ ΦΑΣΗ
∆οκιµή µονοπατιών εκτέλεσης
∆οκιµή οριακών συνθηκών δοκιµές µονάδων
∆οκιµή διεπαφών
∆οκιµή δοµών δεδοµένων
∆οκιµή από πάνω προς τα κάτω
∆οκιµή από κάτω προς τα πάνω δοκιµές συγκρότησης
∆οκιµή σάντουιτς
∆οκιµή αντοχής
Βήτα δοκιµή
Άλφα δοκιµή
∆οκιµή απόδοσης δοκιµές επικύρωσης / συστήµατος
∆οκιµή εκφάνσεων εκτέλεσης
∆οκιµή ανάκαµψης
∆οκιµή ασφαλείας
Εάν τα καταφέρατε, συγχαρητήρια! Γνωρίζετε πότε πρέπει να εφαρµοστεί κάθε πρα-
κτική δοκιµής. Εάν σας έχουν «ξεφύγει» κάποιες πρακτικές, δεν έχετε παρά να επα-
ναλάβετε την αντίστοιχη ενότητα του κεφαλαίου.
6.1
Η σωστή σειρά των βηµάτων που συγκροτούν την τεχνική της επαγωγής, όπως αυτά
αναφέρθηκαν στην ενότητα 6.2.3, είναι η εξής:
1. Συλλογή όλων των δεδοµένων
2. Οργάνωση των δεδοµένων
3. ∆ιαµόρφωση µιας υπόθεσης εργασίας
4. Απόδειξη της υπόθεσης
Αντίστοιχα, η σωστή σειρά των βηµάτων που συγκροτούν την τεχνική της απαγω-
γής, όπως αυτά αναφέρθηκαν στην ενότητα 6.2.3, είναι η εξής:
1. Απαρίθµηση των πιθανών αιτίων
2 0 5 ∞ ¶∞ ¡∆ ∏™ ∂ π ™ ∞ ™ ∫ ∏™ ∂ ø¡ ∞ À ∆ √∞ •π √§ √° ∏™ ∏™
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 205
2 0 6 E ° ∫ À ƒ √¶√π ∏™ ∏ § √° π ™ ªπ ∫ √À
2. Απόρριψη αιτίων µε βάση τα δεδοµένα
3. Εκλέπτυνση της επιλεγµένης υπόθεσης
4. Απόδειξη της υπόθεσης
Εάν απαντήσατε σωστά, συγχαρητήρια! Έχετε κατανοήσει τον τρόπο εφαρµογής των
δύο τεχνικών, οι οποίες είναι αρκετά ισχυρές και συνεπώς διαδεδοµένες. Εάν κάπου
κάνατε λάθη, δεν πειράζει. Σίγουρα οφείλονται σε επιπολαιότητα. Μελετήστε καλύ-
τερα την ενότητα 6.2.3 καθώς και τα σχήµατα 6.3 και 6.4 και ξαναπροσπαθήστε.
6.2
Το σωστά συµπληρωµένο κείµενο έχει ως εξής:
Αφορµή για την εφαρµογή µιας διαδικασίας εκσφαλµάτωσης αποτελεί η εµφάνιση
ενός σφάλµατος κατά τον έλεγχο ενός προγράµµατος. Συνεπώς, η εκσφαλµάτωση
αποτελεί ανεξάρτητη διαδικασία, η οποία εφαρµόζεται µετά τον έλεγχο του λογισµι-
κού. Στόχος της είναι η ανακάλυψη του ελαττώµατος του κώδικα, το οποίο προκά-
λεσε το σφάλµα.
Για τον εντοπισµό της περιοχής του κώδικα όπου βρίσκεται το ελάττωµα, µπορεί να
χρησιµοποιηθεί η οπισθοδρόµηση. Σύµφωνα µε την τεχνική αυτή, ξεκινούµε από το
σηµείο όπου εµφανίστηκε το σφάλµα και καταγράφουµε, προχωρώντας προς τα
πίσω, τα µονοπάτια εκτέλεσης του πηγαίου κώδικα. Τότε, µελετώντας τα αποτελέ-
σµατα του ελέγχου µπορούµε να εντοπίσουµε το αίτιο του σφάλµατος χρησιµοποι-
ώντας µια από τις µαθηµατικές τεχνικές της επαγωγής ή της απαγωγής. Και οι δύο
τεχνικές περιλαµβάνουν τη διαµόρφωση (ή την επιλογή) µιας υπόθεσης εργασίας,
την ισχύ της οποίας προσπαθούµε να αποδείξουµε ή να απορρίψουµε.
Όταν όλες οι άλλες τεχνικές αποτύχουν, µένει µόνο να χρησιµοποιήσουµε µεθόδους
κατά µέτωπο επίθεσης. Αυτές περιλαµβάνουν την τοποθέτηση µέσα στον κώδικα
σηµείων διακοπής (ώστε να διακόπτεται η εκτέλεση του προγράµµατος όταν εµφα-
νιστεί µια συνθήκη), αλλά και εντολές εκτύπωσης µηνυµάτων (οι οποίες τυπώνουν
κάποιο µήνυµα όταν εµφανιστεί µια συνθήκη) ή ιχνηλάτησης (ώστε να καταγράφο-
νται οι τιµές επιλεγµένων µεταβλητών).
Ο στόχος της πρώτης παραγράφου είναι να διαχωρίσετε το σφάλµα από το ελάττω-
µα: το δεύτερο περιέχεται στον κώδικα και, κατά την εκτέλεση του προγράµµατος,
προκαλεί το πρώτο. Εάν δεν απαντήσατε σωστά στην παράγραφο αυτή, καλύτερα
να µελετήσετε ξανά τις εισαγωγικές παρατηρήσεις και την ενότητα 6.1.
Η δεύτερη και η τρίτη παράγραφος επικεντρώνονται στις τεχνικές εκσφαλµάτωσης:
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 206
στη δεύτερη παράγραφο περιγράφονται οι τεχνικές της οπισθοδρόµησης και της ανα-
ζήτησης του αιτίου (αναφέρονται στις υποενότητες 6.2.2 και 6.2.3), ενώ η τρίτη ανα-
φέρεται αποκλειστικά στην τεχνική της κατά µέτωπο επίθεσης (περιγράφεται στην
υπο – ενότητα 6.2.1). Για να διορθώσετε τα όποια λάθη κάνατε, θα χρειαστεί να επα-
ναλάβετε κάποιες από τις ενότητες αυτές.
Εάν όµως έχετε συµπληρώσει σωστά όλα τα κενά, σας αξίζουν πολλά συγχαρητή-
ρια! Πραγµατικά έχετε κατανοήσει το αντικείµενο του κεφαλαίου σε όλες του τις
διαστάσεις.
7.1
Η σωστή αντιστοίχιση είναι η ακόλουθη:
Τυπική τεχνική ΕΠΛ ∆ραστηριότητα
Απόδειξη ορθότητας Πρόληψη ελαττωµάτων
Στατιστική ΕΠΛ Απόδειξη ορθότητας ισχυρισµών
∆ιαδικασία «καθαρού δωµατίου» Εντοπισµός και διόρθωση
των κρίσιµων ελαττωµάτων
Εάν απαντήσατε σωστά, συγχαρητήρια! Έχετε κατανοήσει τη βασική φιλοσοφία
κάθε τυπικής τεχνικής ΕΠΛ, οπότε θα µπορείτε ευκολότερα να επιλέξετε την κατάλ-
ληλη. Εάν δεν τα καταφέρατε, µελετήστε ξανά την ενότητα 7.3.
7.2
Μέτρο της αξιοπιστίας του Α αποτελεί ο µέσος χρόνος ανάµεσα στην εµφάνιση
σφαλµάτων (MTBF). Για τον υπολογισµό του MTBF υπολογίζουµε τους χρόνους
MTTF και MTTR (50 sec και 8 min, αντίστοιχα). Τότε MTBF = 8 min 50 sec = 530
sec. Το Α λοιπόν, λειτουργεί συνολικά κατά 4800 sec, από τα οποία λειτουργεί
σωστά κατά 4270 sec. Η αξιοπιστία του είναι 88,9% και η διαθεσιµότητα του Α είναι
9,43%.
Αν και το Α φαίνεται να έχει υψηλή αξιοπιστία, έχει µικρή διαθεσιµότητα. Αυτό
οφείλεται στο ότι ο MTBF είναι το ίδιο ευαίσθητος στους MTTF και MTTR, ενώ η
διαθεσιµότητα εξαρτάται περισσότερο από τον MTTR. Το Α προφανώς βρίσκεται
στο στάδιο ελέγχου. Όταν παραδοθεί προς χρήση, αυξάνεται κατά πολύ ο MTTF
(φτάνει στο επίπεδο µηνών ή ετών). Σε συστήµατα µε υψηλή συντηρησιµότητα µει-
ώνεται και ο MTTR. Συνολικά, λοιπόν, το κλάσµα µεγαλώνει, άρα αυξάνεται και η
διαθεσιµότητα του συστήµατος.
2 0 7 ∞ ¶∞ ¡∆ ∏™ ∂ π ™ ∞ ™ ∫ ∏™ ∂ ø¡ ∞ À ∆ √∞ •π √§ √° ∏™ ∏™
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 207
2 0 8 E ° ∫ À ƒ √¶√π ∏™ ∏ § √° π ™ ªπ ∫ √À
Εάν απαντήσατε σωστά, σας αξίζουν πολλά µπράβο! Έχετε κατανοήσει το ρόλο του
MTBF και τους παράγοντες που τον επηρεάζουν. Εάν δεν τα καταφέρατε, µην απο-
γοητεύεστε. Μελετήστε πιο προσεκτικά το πρώτο τµήµα της ενότητας 7.4 και το
παράδειγµα 2, πριν επιχειρήσετε ξανά να απαντήσετε.
7.3
Τα περισσότερα µοντέλα αξιοπιστίας υλικού χρησιµοποιούν κυρίως την αστοχία που
προέρχεται από τη φθορά (wear) του υλικού και όχι αυτή που οφείλεται σε σχεδια-
στικά ελαττώµατα, καθώς η φυσική φθορά που προέρχεται από τη χρήση του υλι-
κού αποτελεί συχνότερη αιτία αστοχίας από το σχεδιαστικό λάθος. Στην περίπτωση
του λογισµικού, τα πράγµατα είναι εντελώς διαφορετικά: όλες οι αστοχίες οφείλο-
νται σε σχεδιαστικά ελαττώµατα, καθώς δεν υπάρχει η έννοια της «φθοράς που οφεί-
λεται στη χρήση του λογισµικού».
Η ερώτηση ήταν πραγµατικά δύσκολη. Εάν την απαντήσατε, σας αξίζουν πολλά
«µπράβο!», επειδή καταφέρατε να συµπεράνετε τον τρόπο µε τον οποίο οι «φυσι-
κές» διαφορές των δύο συστατικών οδηγούν σε διαφορετική αντιµετώπισή τους σε
σχέση µε την αξιοπιστία. Εάν δε βρήκατε την απάντηση, µην απογοητεύεστε. Μελε-
τήστε πιο προσεκτικά την ενότητα 7.4 και συνδυάστε την µε τις γενικότερες γνώσεις
που έχετε για τη σύνθεση των υπολογιστών από υλικό και λογισµικό.
Σε κάθε περίπτωση, έχετε υπόψη σας ότι οι ερευνητές δεν έχουν καταφέρει ακόµη
να συσχετίσουν οριστικά τις βασικές έννοιες της αξιοπιστίας υλικού µε την αξιοπι-
στία λογισµικού, ώστε η εφαρµογή των θεωριών αξιοπιστίας υλικού στην αξιοπιστία
λογισµικού να είναι αναµφισβήτητη. Για παράδειγµα, µια βασική υπόθεση των θεω-
ριών αξιοπιστίας υλικού είναι ότι κάθε ελάττωµα αποµακρύνεται µόλις ανακαλυ-
φθεί, µε αποτέλεσµα να µειώνεται κατά ένα ο συνολικός αριθµός των ελαττωµάτων.
Αυτό, βέβαια, δεν ισχύει κατά τη µελέτη της αξιοπιστίας λογισµικού, όπου η διόρ-
θωση ενός ελαττώµατος (ειδικά όταν γίνεται µε την προσθήκη νέου κώδικα) µπορεί
να εισαγάγει νέα ελαττώµατα στο λογισµικό.
Από την άλλη πλευρά, ο MTBF για ορισµένα ελαττώµατα του λογισµικού µπορεί
να τείνει στο άπειρο. Αρκεί να σκεφτείτε την περίπτωση κάποιο ελάττωµα να προ-
καλεί σφάλµα σε µια σπάνια λειτουργία, η οποία χρησιµοποιείται π.χ. κάθε 50 ή 100
χρόνια (!), οπότε ο MTTF γίνεται πρακτικά άπειρος.
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 208
°ÂÓÈ΋ ‚È‚ÏÈÔÁÚ·Ê›·
Ελληνόγλωσση
[1] Σ. Ξανθάκης και Χ. Σκουρλάς (1991), Τεχνικές Ελέγχου Προγραµµάτων. Εκδό-
σεις Νέων Τεχνολογιών, Αθήνα.
[2] Ε. Σκορδαλάκης (1991), Εισαγωγή στην Τεχνολογία Λογισµικού. Συµµετρία,
Αθήνα.
Ξενόγλωσση
[3] B.W. Boehm (1981), Software Engineering Economics. Prentice – Hall,
Englewood Cliffs: NJ.
[4] R. Fairley (1985), Software Engineering Concepts. McGraw – Hill, Singapore.
[5] ΙΕΕΕ (1983), Glossary of Software Engineering Terminology. ANSI – IEEE
Standard 729 – 1983, IEEE Press, New York.
[6] ΙΕΕΕ (1984), Software Quality Assurance Plans. ANSI – IEEE Standard 730 –
1984, IEEE Press, New York.
[7] ΙΕΕΕ (1986), Software Quality Assurance Planning. ANSI – IEEE Standard 983
– 1986, IEEE Press, New York.
[8] IEEE (1986), Software Verification and Validation Plans. ANSI – IEEE Standard
1012 – 1986, IEEE Press, New York.
[9] IEEE (1990), Standard Glossary of Software Engineering Terminology. ANSI
– IEEE Standard 610.12 – 1990, IEEE Press, New York.
[10] R. C. Linger (1994), «Cleanroom process model». IEEE Software, 11(2), pp 50
– 58.
[11] J. McCall, P. Richards and G. Walters (1977), Factors in Software Quality. NTIS
AD – A049 – 014, 015, 055 (3 τόµοι).
[12] R. Pressman (1994), Software Engineering: a practitioner’s approach. McGraw
– Hill, England.
[13] M.L. Shooman (1983), Software Engineering. McGraw – Hill, Tokyo.
[14] I. Sommerville (1996), Software Engineering. Addison – Wesley, USA
[15] J. Voas and K. Miller (1995), «Software Testability: the new verification». IEEE
Software, 12(3), pp 17 – 28.
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 209
µÈ‚ÏÈÔÁÚ·Ê›· ÁÈ· ·Ú·¤Ú· ÌÂϤÙË
Οι δραστηριότητες επικύρωσης και επαλήθευσης λογισµικού είναι πολύ σηµαντικές
στη διαδικασία ανάπτυξης λογισµικού, ενώ τα αποτελέσµατά τους διαδίδονται και στους
τελικούς χρήστες. Είναι λοιπόν φυσικό να υπάρχει µεγάλης έκτασης βιβλιογραφία στο
θέµα, το µεγαλύτερο τµήµα της οποίας αναφέρεται στον έλεγχο του λογισµικού.
Ένα καλό σηµείο εκκίνησης είναι τα γενικότερα βιβλία της Τεχνολογίας Λογισµι-
κού, µε τα οποία µπορείτε να αποκτήσετε µια συνολική παιδεία στα ζητήµατα που
άπτονται των δραστηριοτήτων Ε&Ε, αλλά και του γενικότερου περιβάλλοντος όπου
αυτές εντάσσονται (π.χ. αξιοπιστία λογισµικού). ∆ύο από τα καλύτερα βιβλία αυτής
της κατηγορίας είναι αυτό του R. Pressman, Software Engineering: a
Practitioner’s Approach (McGraw – Hill, 1994) και αυτό του I. Sommerville,
Software Engineering (Addison – Wesley, 1996). Και τα δύο αφιερώνουν ολόκληρα
κεφάλαια σε θέµατα Ε&Ε, µε το πρώτο να προσεγγίζει το αντικείµενο από την πλευ-
ρά της αξιοπιστίας και της διασφάλισης της ποιότητας, ενώ το δεύτερο επικεντρώ-
νεται στις τεχνικές δοµικού και λειτουργικού ελέγχου. ∆ύο καλά κεφάλαια για τον
έλεγχο και την αξιοπιστία του λογισµικού περιλαµβάνονται και στο βιβλίο του M.
Shooman, Software Engineering (McGraw – Hill, 1983). Ένα ακόµη σχετικό
βιβλίο, το οποίο αποτέλεσε ορόσηµο για την Τεχνολογία Λογισµικού είναι αυτό του
F. Brooks Jr., The Mythical Man – month: Essays on Software Engineering
(Addison – Wesley, 1995). ∆ιαβάστε το, ακόµη και την ώρα που έχετε ξαπλώσει για
να κοιµηθείτε!
Ολοκληρωµένη παρουσίαση των δραστηριοτήτων Ε&Ε περιέχεται στο βιβλίο του
J. Grady, System Validation & Verification (CRC Press, 1995). Το βιβλίο παρου-
σιάζει τη σχέση των δραστηριοτήτων Ε&Ε µε τις διάφορες φάσεις ανάπτυξης και
υποδεικνύει το αντίστοιχο περιεχόµενο ώστε να ολοκληρώνονται οµαλά σε αυτές.
Στο ίδιο κλίµα, αλλά σε περισσότερο πρακτικό επίπεδο, κινείται το βιβλίο των E.
Kit και S. Finzi, Software Testing in the Real World: Improving the Process
(ACM Press, 1995). Πρόκειται για ένα βιβλίο που χρησιµοποιείται διεθνώς για την
υποστήριξη µαθηµάτων σχετικά µε τον έλεγχο του λογισµικού, καθώς παρουσιάζει
µια ολοκληρωµένη προσέγγιση από την πλευρά του προγραµµατιστή. Ένα ακόµη
πιο σύγχρονο βιβλίο, το οποίο παρουσιάζει την εφαρµογή δραστηριοτήτων Ε&Ε στις
διάφορες αρχιτεκτονικές λογισµικού είναι το βιβλίο των G. Schulmeyer και G.
McKenzie, Verification and Validation of Modern Software Systems (Prentice
– Hall, 2000). Τα θέµατα που αντιµετωπίζει είναι σύγχρονα και δεν απαντώνται σε
άλλα βιβλία του είδους.
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 210
Από τα βιβλία που αναφέρονται στον έλεγχο του λογισµικού ξεχωρίζουµε αυτό του
G. Myers, The Art of Software Testing, (John Wiley & sons, 1979). Πρόκειται
για το βιβλίο που έχουν διαβάσει όλοι: οι επαγγελµατίες, οι φοιτητές, αλλά κυρίως,
οι συγγραφείς άλλων βιβλίων. Είναι το καλύτερο σηµείο εκκίνησης, καθώς παρέχει
µια πρακτική προσέγγιση του ελέγχου λογισµικού, παρουσιάζει µεθοδολογίες σχε-
δίασης αποτελεσµατικών περιπτώσεων ελέγχου, καλύπτει οικονοµικές, διοικητικές
και ψυχολογικές πλευρές του ελέγχου, παρουσιάζει εργαλεία ελέγχου και περιέχει
εκτενή βιβλιογραφία. Παρά την «ηλικία» του αποτελεί κλασικό σηµείο αναφοράς.
Καλό εισαγωγικό βιβλίο (και πιο σύγχρονο) είναι και αυτό του P. Jorgensen,
Software Testing: a Craftsman’s Approach (CRC Press, 1995).
Το βιβλίο Automated Software Testing: Introduction, Management and
Performance των E. Dustin, J. Rashka και J. Paul (Addison – Wesley, 1999)
απευθύνεται σε όσους έχουν βασικές γνώσεις Τεχνολογίας Λογισµικού. Παρουσιά-
ζει αφ’ ενός µια ολοκληρωµένη µεθοδολογία διαχείρισης και εφαρµογής διαδικα-
σιών ελέγχου (λέγεται ATLM – Automated Testing Lifecycle Management) και αφ’
ετέρου ένα κατάλογο όλων των αυτοµατοποιηµένων εργαλείων ελέγχου. Το τελευ-
ταίο αυτό χαρακτηριστικό είναι σηµαντικό και δίνει ιδιαίτερη αξία στο βιβλίο. Στο
ίδιο κλίµα, αλλά σε πιο προχωρηµένο επίπεδο βρίσκεται το βιβλίο του W. Perry,
Effective Methods for Software Testing, 2
nd
edition (John Wiley & sons, 2000).
Ένα µεγάλο τµήµα του είναι αφιερωµένο στον έλεγχο ειδικών αρχιτεκτονικών (π.χ.
client – server, intranets κ.λπ.).
Τα επόµενα βιβλία αναφέρονται σε συγκεκριµένα θέµατα εγκυροποίησης. Έτσι, το
βιβλίο των J. Musa, A. Iannino και K. Okumoto, Software Reliability:
Measurement, Prediction, Application (McGraw – Hill, 1987) αποτελεί κλασικό
ανάγνωσµα στο αντικείµενο της αξιοπιστίας λογισµικού. Ο J. Musa, ο θεωρούµενος
ως πατέρας της αξιοπιστίας λογισµικού έχει γράψει ένα ακόµη καλό βιβλίο, το J.
Musa, Software Reliability Engineering: More Reliable Software, Faster
Development and Testing (McGraw – Hill, 1998). Περισσότερο πρακτικές προ-
σεγγίσεις στο ίδιο θέµα περιέχονται στο βιβλίο του M. Lyu, Handbook of Software
Reliability Engineering (McGraw – Hill, 1996) και σε αυτό του H. Pham,
Software Reliability and Testing (IEEE Computer Society, 1995). Πρόκειται για
δύο συλλογές εργασιών: στο πρώτο βιβλίο περιλαµβάνονται εργασίες που συνοψί-
ζουν την εµπειρία και τις πρακτικές αξιοπιστίας που εφαρµόζουν µεγάλες εταιρείες
πληροφορικής, ενώ στο δεύτερο περιγράφονται σύγχρονα µοντέλα αξιοπιστίας και
ο τρόπος µε τον οποίο µπορούν αυτά να ενσωµατωθούν στις δραστηριότητες ελέγ-
χου.
2 1 1 µ π µ § π √° ƒ∞ ºπ ∞ ° π ∞ ¶∞ ƒ∞ ¶∂ ƒ∞ ª∂ § ∂ ∆ ∏
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 211
2 1 2 E ° ∫ À ƒ √¶√π ∏™ ∏ § √° π ™ ªπ ∫ √À
Στο ίδιο αντικείµενο, αλλά µε µεγαλύτερη έµφαση στην ελεγξιµότητα µπορείτε να
βρείτε το βιβλίο των M. Friedman και J. Voas, Software Assessment: Reliability,
Safety, Testability (John Wiley & sons, 1995). Το βιβλίο είναι κατάλληλο τόσο για
σπουδαστές, όσο και για επαγγελµατίες, καθώς παρέχει τόσο το απαραίτητο θεω-
ρητικό υπόβαθρο, αλλά και πρακτικές µεθόδους αξιολόγησης του λογισµικού, δίνο-
ντας έµφαση στην προσέγγιση της ελεγξιµότητας (δηλαδή, την ανάπτυξη του λογι-
σµικού µε τρόπο ώστε να διευκολύνεται ο έλεγχός του).
Για τη µελέτη της διασφάλισης της ποιότητας του λογισµικού προτείνουµε το βιβλίο
των G. Schulmeyer και J. McManus, The Handbook of Software Quality
Assurance (Prentice – Hall, 1998), το οποίο αποτελεί συλλογή εργασιών στο αντικεί-
µενο, οι οποίες πραγµατεύονται θέµατα όπως οι θεωρητικές βάσεις της αξιοπιστίας λογι-
σµικού, τρόποι, µέθοδοι, εργαλεία και κόστος εφαρµογής των σχετικών διαδικασιών,
πρότυπα αξιοπιστίας, πρακτικές περιπτώσεις εφαρµογής και εµπειρία, κ.ά.
∆ύο καλά βιβλία που αναφέρονται σε στατικό έλεγχο του λογισµικού είναι αυτό των
D. Wheeler, B. Brykczynski και R. Meeson, Software Inspection: An Industry
Best Practice (IEEE Computer Society, 1996) και αυτό των D. Freedman και G.
Weinberg, Handbook of Walkthroughs, Inspections and Technical Reviews
(Dorset House, 1990). Το πρώτο αποτελεί συλλογή άρθρων από την εµπειρία ανθρώ-
πων που εφαρµόζουν στην πράξη τεχνικές αναθεωρήσεων. Το δεύτερο αποτελεί πρα-
κτικό οδηγό εφαρµογής διαδικασιών αναθεώρησης.
Το βιβλίο του A. Stavely, Towards Zero – Defect Programming (Addison –
Wesley, 1998) αποτελεί µια άριστη παρουσίαση της θεωρίας και της πρακτικής εφαρ-
µογής των διαδικασιών «καθαρού δωµατίου». Στο ίδιο θέµα, το βιβλίο των S.
Prowell, C. Trammell, R. Linger και J. Poore, Cleanroom Software Engineering:
Technology and Process (Addison – Wesley, 1999), προσφέρει µια περισσότερο
πρακτική προσέγγιση και περιέχει µια εκτενή µελέτη περίπτωσης εφαρµογής της
συγκεκριµένης µεθοδολογίας ανάπτυξης λογισµικού.
Ειδικά στον έλεγχο αντικειµενοστραφών συστηµάτων αναφέρονται τα βιβλία του R.
Binder, Testing Object Oriented Systems: Models, Patterns and Tools (Addison
– Wesley, 1999) και των D. Kung, P. Hsia, J. Gao και C. Ho – Kung, Testing
Object Oriented Software (IEEE Computer Society, 1998). Το πρώτο επικε-
ντρώνεται περισσότερο στον έλεγχο συστηµάτων που έχουν σχεδιαστεί µε χρήση
του συµβολισµού UML ενώ αναφέρει και πρότυπες τεχνικές ελέγχου που έχουν απο-
δειχθεί αποτελεσµατικές. Το δεύτερο είναι συλλογή εργασιών, οι οποίες συγκροτούν
µια γενικότερη προσέγγιση στον έλεγχο αντικειµενοστραφών συστηµάτων, ανεξάρ-
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 212
τητη από τη γλώσσα υλοποίησης.
Τέλος, µπορείτε να είστε συνεχώς ενήµεροι για τις τελευταίες εξελίξεις στο χώρο
παρακολουθώντας τόσο τα πρακτικά των (πολυάριθµων) διεθνών συνεδρίων και ηµε-
ρίδων που διοργανώνονται στα σχετικά αντικείµενα, όσο και τις περιοδικές εκδό-
σεις διεθνών οργανισµών. Τα περισσότερο γνωστά συνέδρια είναι τα ακόλουθα:
• Software Testing, Verification and Analysis
• Software Testing, Reliability and Quality Assurance
• Software Reliability Engineering
• Design, Specification and Verification of Interactive Systems
• Computer – Aided Verification
∆ιεθνούς φήµης περιοδικά που φιλοξενούν άρθρα σχετικά µε το αντικείµενο είναι:
• IEEE Design & Test of Computers
• IEEE Software
• IEEE Computer (εκδίδεται από την IEEE Computer Society)
• IEEE Trans. On Reliability (εκδίδεται από την IEEE Reliability Society)
• ACM Trans. On Information & System Security
• ACM Trans. On Software Engineering & Methodology
• Communications of the ACM
2 1 3 µ π µ § π √° ƒ∞ ºπ ∞ ° π ∞ ¶∞ ƒ∞ ¶∂ ƒ∞ ª∂ § ∂ ∆ ∏
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 213
°ÏˆÛÛ¿ÚÈÔ fiÚˆÓ
Αναθεώρηση (review)
Σύνολο µη – τυπικών στατικών τεχνικών Ε&Ε, οι οποίες εκτελούνται από µια
µικρή οµάδα ατόµων, τα οποία, αφού προετοιµαστούν ατοµικά, εξετάζουν από
κοινού σε κάθε αναθεωρητική σύνοδο ένα µικρό τµήµα του λογισµικού. Οι
περισσότερο διαδεδοµένες τεχνικές αναθεωρήσεων είναι οι περιηγήσεις και οι
επισκοπήσεις (βλ. Σχετικά).
Αναθεωρούµενος (reviewee)
Eκπρόσωπος της οµάδας σχεδίασης ή ανάπτυξης ενός τµήµατος λογισµικού, υπεύθυ-
νος για την παρουσίαση του συγκεκριµένου τµήµατος σε µια σύνοδο αναθεώρησης.
Αναλλοίωτο βρόχου (loop invariant)
Έκφραση που περιγράφει την αναµενόµενη συµπεριφορά ενός βρόχου, δηλαδή
τις τιµές εξόδου των µεταβλητών που περιέχονται σε αυτό σε συνάρτηση µε τον
αριθµό των επαναλήψεων.
Ανάλυση ευαισθησίας (sensitivity analysis)
Περιγράφει ποσοτικά τη συµπεριφορά του λογισµικού σε σχέση µε την πιθανό-
τητα να υπάρχουν κρυµµένα σφάλµατα, µε στόχο να υποδείξει πόσο «µικρά»
µπορεί να είναι αυτά. Έτσι, µετά από στατιστική ανάλυση είναι δυνατό να παρα-
χθούν κριτήρια τερµατισµού των δοκιµών. Σχετίζεται άµεσα µε την ελεγξιµότη-
τα του λογισµικού (βλ. σχετικά) και χρησιµοποιεί τρεις διαφορετικές διαδικασίες
ανάλυσης: την ανάλυση εκτέλεσης, την ανάλυση µόλυνσης και την ανάλυση διά-
δοσης.
Αναφορά περιήγησης (walkthrough report)
Συντάσσεται από τους αναθεωρητές στο τέλος µιας συνόδου αναθεώρησης και
περιλαµβάνει περιγραφή του υπό αναθεώρηση προϊόντος, των συµµετεχόντων
επιθεωρητών, του καταλόγου µε τα ζητήµατα που ανέκυψαν και των σχετιζοµέ-
νων παρατηρήσεων – συµπερασµάτων.
Αξιοπιστία λογισµικού (software reliability)
H πιθανότητα της χωρίς σφάλµατα λειτουργίας του λογισµικού σε ένα καθορι-
σµένο περιβάλλον για ένα καθορισµένο χρονικό διάστηµα. Είναι ένας από τους
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 214
σηµαντικότερους παράγοντες ποιότητας, ο οποίος µπορεί να εκτιµηθεί µε βάση
δεδοµένα που έχουν συλλεχθεί κατά την ανάπτυξη του λογισµικού. Μέτρο του
αποτελεί ο µέσος χρόνος ανάµεσα στην εµφάνιση σφαλµάτων (βλ. σχετικά).
Αξιωµατική τυπική επαλήθευση
∆ιαδεδοµένη µεθοδολογία τυπικής επαλήθευσης (βλ. σχετικά), σύµφωνα µε την
οποία εισάγεται στο λογισµικό ένας αριθµός ισχυρισµών (βλ. σχετικά) για τις
µεταβλητές του λογισµικού και τις σχέσεις µεταξύ αυτών. Κάθε ισχυρισµός εισά-
γεται σε συγκεκριµένο σηµείο του προγράµµατος. Ξεκινώντας από τον αρχικό
ισχυρισµό, αρκεί να αποδειχθεί ότι (α) κάθε ισχυρισµός προκύπτει από τον προη-
γούµενό του εάν εκτελεστεί ο ενδιάµεσος κώδικας για όλους τους ισχυρισµούς
και (β) το πρόγραµµα τερµατίζει πάντα, ώστε να αποδειχθεί πλήρως η ορθότητα
του λογισµικού.
Αυτοµατοποιηµένα εργαλεία ελέγχου
Eργαλεία (ή τµήµατα εργαλείων CASE – Computer – Aided Software Engineering),
τα οποία υποστηρίζουν τη µερική ή ολική αυτοµατοποίηση φάσεων ή δραστηριο-
τήτων που σχετίζονται άµεσα µε την εγκυροποίηση του λογισµικού.
Γράφηµα ροής (flowgraph)
Γραφική αναπαράσταση των µονοπατιών εκτέλεσης ενός τµήµατος κώδικα. Κάθε
διαδικασιακό πρόγραµµα µπορεί να αναπαρασταθεί µε ένα γράφηµα ροής. Τα
γραφήµατα ροής χρησιµοποιούνται κατά το δοµικό έλεγχο του λογισµικού (βλ.
σχετικά).
∆εδοµένα ελέγχου (test data)
∆εδοµένα εισόδου σε µια δοκιµαστική περίπτωση (βλ. σχετικά).
∆ιαδικασία του «καθαρού δωµατίου» (cleanroom software development process)
Tεχνική ανάπτυξης λογισµικού, η οποία δίνει έµφαση στην πρόληψη της εµφά-
νισης ελαττωµάτων και στοχεύει στην παραγωγή λογισµικού χωρίς ελαττώµατα.
∆ιαθεσιµότητα (availability)
Mέτρο της αξιοπιστίας του λογισµικού που χρησιµοποιείται εναλλακτικά του
µέσου χρόνου ανάµεσα στην εµφάνιση σφαλµάτων (βλ. σχετικά).
2 1 5 ° § ø™ ™ ∞ ƒ π √ √ƒ ø¡
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 215
2 1 6 E ° ∫ À ƒ √¶√π ∏™ ∏ § √° π ™ ªπ ∫ √À
∆οκιµές αποδοχής (acceptance testing)
Eφαρµόζονται αφού το σύστηµα έχει συγκροτηθεί και στοχεύουν στον έλεγχο
της λειτουργίας του λογισµικού από τους τελικούς χρήστες σε πραγµατικό περι-
βάλλον λειτουργίας. ∆ιακρίνονται σε δοκιµή άλφα και βήτα.
∆οκιµές µονάδων (unit testing)
Eπικεντρώνονται στα µικρότερα τµήµατα λογισµικού και χρησιµοποιούν τεχνι-
κές δοµικού ελέγχου για να δείξουν την ορθότητα και την εγκυρότητα της λει-
τουργίας τους. Περιλαµβάνουν δοκιµή διεπαφών, µονοπατιών εκτέλεσης και τοπι-
κών δοµών δεδοµένων, οριακών συνθηκών εκτέλεσης, καθώς και δοκιµή του
κώδικα διαχείρισης σφαλµάτων.
∆οκιµές συγκρότησης (integration testing)
Eκτελούνται κατά το σταδιακό χτίσιµο του λογισµικού από τµήµατα. ∆ιακρίνο-
νται δύο είδη συγκρότησης (βλ. σχετικά), τα οποία περιλαµβάνουν αντίστοιχες
δραστηριότητες δοκιµής: η µη – αυξητική και η αυξητική συγκρότηση. Ανάλο-
γα µε το σηµείο εκκίνησης και την κατεύθυνση της διαδικασίας ολοκλήρωσης,
η αυξητική συγκρότηση (και η αντίστοιχη δοκιµή) διακρίνεται σε: συγκρότη-
ση/δοκιµή από πάνω προς τα κάτω, συγκρότηση/δοκιµή από κάτω προς τα πάνω
και σάντουιτς συγκρότηση/δοκιµή.
∆οκιµές συστήµατος (system testing)
Eφαρµόζονται στο συνολικό σύστηµα µε στόχο να ανακαλυφθούν οι περιορισµοί
που επιβάλλει στη συµπεριφορά του λογισµικού το πραγµατικό περιβάλλον λει-
τουργίας του (αυτός είναι ο λόγος για τον οποίο πολλές φορές αποτελούν µέρος
των δοκιµών αποδοχής – βλ. σχετικά). Περιλαµβάνουν τις ακόλουθες δραστη-
ριότητες: δοκιµή εκφάνσεων (νηµάτων) εκτέλεσης, δοκιµή αντοχής, δοκιµή ανά-
καµψης, δοκιµή ασφάλειας και δοκιµή απόδοσης.
∆οµικός έλεγχος (structural testing)
Σύνολο τεχνικών µε τις οποίες δοκιµάζονται λεπτοµερώς τα µονοπάτια εκτέλε-
σης του κώδικα του λογισµικού. Ο στόχος είναι να αποδειχθεί ότι οι εσωτερικές
λειτουργίες του λογισµικού είναι σύµφωνες µε τις προδιαγραφές και ότι τα εµπε-
ριεχόµενα τµήµατα του λογισµικού συνεργάζονται σωστά. Περιλαµβάνει τις ακό-
λουθες τεχνικές: δοκιµή βασικών µονοπατιών και δοκιµή δοµών επανάληψης.
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 216
Εγκυροποίηση
Σύνολο διαδικασιών, οι οποίες εκτελούνται συνεχώς κατά τη διάρκεια του κύκλου
ανάπτυξης του λογισµικού, µε στόχο να ελέγξουν την ορθότητα και να βελτιώ-
σουν την ποιότητα του λογισµικού, αλλά και των άλλων, ενδιάµεσων προϊόντων
της ανάπτυξης. Οι διαδικασίες εγκυροποίησης περιλαµβάνουν δραστηριότητες
επαλήθευσης και επικύρωσης, γι’ αυτό και είναι γνωστές ως «φάση Ε&Ε».
Εκκαθαριστής σφαλµάτων λογισµικού (debugger)
Άτοµο εκπαιδευµένο στην αποκάλυψη και διόρθωση των ελαττωµάτων που προ-
καλούν τα σφάλµατα, τα οποία ανακάλυψε η οµάδα δοκιµής κατά τον έλεγχο του
λογισµικού.
Εκσφαλµάτωση (debugging)
Aκολουθεί µετά τον επιτυχηµένο έλεγχο και στοχεύει στην εξάλειψη των σφαλ-
µάτων που αυτός απεκάλυψε µέσω της διόρθωσης των ελαττωµάτων του κώδι-
κα που τα προκαλούν. ∆ιεξάγεται από τον «εκκαθαριστή σφαλµάτων λογισµι-
κού» (βλ. σχετικά) και συνήθως περιλαµβάνει τα στάδια: εντοπισµός ελαττώµα-
τος, σχεδίαση διόρθωσης, διόρθωση ελαττώµατος, επανέλεγχος. Τρεις γενικές
κατηγορίες µεθοδολογιών εκσφαλµάτωσης έχουν έως τώρα προταθεί (βλ. σχετι-
κά):κατά µέτωπο επίθεση, οπισθοδρόµηση και εξάλειψη του αιτίου.
Ελάττωµα (fault)
H αιτία εµφάνισης σφαλµάτων (βλ. σχετικά). ∆ιακρίνονται σε ελαττώµατα προ-
διαγραφών, ελαττώµατα σχεδίασης και ελαττώµατα υλοποίησης. Η αποµάκρυν-
ση των ελαττωµάτων είναι το αντικείµενο της εκσφαλµάτωσης (βλ. σχετικά).
Ελεγξιµότητα λογισµικού (software testability)
O βαθµός στον οποίο ένα λογισµικό διευκολύνει τον καθορισµό κριτηρίων ελέγ-
χου και τη διεξαγωγή ελέγχων για να διαπιστωθεί κατά πόσον αυτά ικανοποιού-
νται, αλλά και ο βαθµός στον οποίο µια απαίτηση εκφράζεται µε τρόπο ώστε να
επιτρέπεται ο καθορισµός κριτηρίων ελέγχου και η διεξαγωγή ελέγχων για να δια-
πιστωθεί κατά πόσον αυτά ικανοποιούνται. Η ελεγξιµότητα δεν µπορεί να απο-
καλύψει ελαττώµατα, αλλά να βοηθήσει στον εντοπισµό τµηµάτων όπου µπορεί
να κρύβονται τα ελαττώµατα.
Έλεγχος αδιαφανούς κουτιού (black – box testing)
βλ. Λειτουργικός έλεγχος
2 1 7 ° § ø™ ™ ∞ ƒ π √ √ƒ ø¡
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 217
2 1 8 E ° ∫ À ƒ √¶√π ∏™ ∏ § √° π ™ ªπ ∫ √À
Έλεγχος διαφανούς κουτιού (white – box testing)
βλ. ∆οµικός έλεγχος
Έλεγχος διεπαφών (interface testing)
Eφαρµόζεται κατά τη συγκρότηση τµηµάτων λογισµικού για τη δηµιουργία µεγα-
λύτερων τµηµάτων ή (υπο)συστηµάτων. Ο στόχος είναι να ανακαλύψει λάθη που
εισάγονται στο σύστηµα εξαιτίας ελαττωµάτων των διεπαφών ή λανθασµένων
υποθέσεων για τις διεπαφές των επιµέρους τµηµάτων.
Έλεγχος λογισµικού (software testing)
Σύνολο δραστηριοτήτων µε τις οποίες δοκιµάζεται απευθείας ο κώδικας του λογι-
σµικού. Πρόκειται για την περισσότερο διαδεδοµένη τεχνική ελέγχου, η οποία
περιλαµβάνει ένα σύνολο περιπτώσεων ελέγχου, σε καθεµία από τις οποίες γίνε-
ται δοκιµαστική εκτέλεση του κώδικα χρησιµοποιώντας ανάλογα δεδοµένα ελέγ-
χου (βλ. σχετικά). Εκτελείται από ειδική οµάδα δοκιµής, σύµφωνα µε τη στρα-
τηγική ελέγχου της επιχείρησης (βλ. σχετικά) και δεν µπορεί να αποδείξει την
απουσία ελαττωµάτων – µπορεί µόνο να δείξει την ύπαρξη σφαλµάτων. ∆ιακρί-
νονται οι εξής δραστηριότητες ελέγχου: Έλεγχος µονάδων, τµηµάτων, υποσυ-
στηµάτων, συστήµατος και αποδοχής.
Έλεγχος παλινδρόµησης (regression testing)
∆ιαδικασία ελέγχου του λογισµικού µετά τη διόρθωση ενός ή περισσότερων ελατ-
τωµάτων, µε στόχο να εξασφαλισθεί αφενός ότι διορθώθηκαν τα ελαττώµατα και
αφετέρου ότι η διόρθωση δεν προκαλεί νέα σφάλµατα.
Εξάλειψη του αιτίου (cause removal)
Tεχνική εκσφαλµάτωσης, η οποία βασίζεται στην επεξεργασία των δεδοµένων του
ελέγχου µε στόχο τη διαµόρφωση υποθέσεων εργασίας για το αίτιο του σφάλµατος.
Οι υποθέσεις ελέγχονται µε στόχο να απορριφθούν όλα τα πιθανά αίτια πλην ενός. Ο
έλεγχος γίνεται εφαρµόζοντας µια από τις τεχνικές της επαγωγής ή της απαγωγής.
Εξασφάλιση ποιότητας λογισµικού (software quality assurance)
Προδιαγραµµένο και συστηµατικό σύνολο ενεργειών, οι οποίες είναι απαραίτη-
τες για την απόκτηση επαρκούς εµπιστοσύνης σε ένα λογισµικό ότι είναι σύµ-
φωνο µε όλες τις προδιαγραφές που σχετίζονται µε αυτό.
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 218
Επαλήθευση (verification)
Tυπικά ορίζονται ως «οι διαδικασίες αξιολόγησης ενός συστήµατος ή τµήµατος
ενός συστήµατος µε στόχο να προσδιοριστεί κατά πόσο τα προϊόντα µιας συγκε-
κριµένης φάσης ανάπτυξης ικανοποιούν τις προδιαγραφές που είχαν τεθεί στην
αρχή της φάσης». Εκτελούνται καθ’ όλη τη διάρκεια του κύκλου ανάπτυξης και
απαντούν στην ερώτηση: «αναπτύσσουµε σωστά το λογισµικό;».
Επιθεωρητές (reviewers)
Oµάδα αξιολόγησης, η οποία συµµετέχει σε µια σύνοδο αναθεώρησης µε στόχο
τη βελτίωση της ποιότητας του λογισµικού µέσα από την έγκαιρη ανακάλυψη
ελαττωµάτων.
Επικύρωση (validation)
∆ιαδικασίες που ελέγχουν το µέτρο στο οποίο το λογισµικό που αναπτύχθηκε ικα-
νοποιεί τις απαιτήσεις και τις προσδοκίες που είχαν θέσει οι µελλοντικοί του χρή-
στες στις αρχικές φάσεις του κύκλου ανάπτυξης. Εκτελούνται προς το τέλος της
διαδικασίας ανάπτυξης και απαντούν στην ερώτηση: «αναπτύσσουµε το σωστό
λογισµικό;».
Επισκόπηση (inspection)
Eίδος αναθεώρησης, η οποία περιλαµβάνει τον έλεγχο ενός προϊόντος του κύκλου
ανάπτυξης από µια οµάδα εποπτών, µε βάση έναν κατάλογο προκαθορισµένων
σηµείων ελέγχου.
Επόπτες (inspectors)
Oµάδα αξιολόγησης, η οποία ελέγχει ένα προϊόν του κύκλου ανάπτυξης µε βάση
ένα σύνολο προκαθορισµένων σηµείων ελέγχου.
Ισχυρισµός (assertion)
Λογική έκφραση επί των τιµών των µεταβλητών ενός προγράµµατος, η οποία
συσχετίζεται µε την αναµενόµενη (ορθή) κατάσταση του προγράµµατος σε
κάποιο σηµείο του κώδικά του.
Κατά µέτωπο επίθεση (brute force)
Tεχνική εκσφαλµάτωσης (η περισσότερο διαδεδοµένη, αλλά και λιγότερο απο-
2 1 9 ° § ø™ ™ ∞ ƒ π √ √ƒ ø¡
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 219
2 2 0 E ° ∫ À ƒ √¶√π ∏™ ∏ § √° π ™ ªπ ∫ √À
δοτική), η οποία βασίζεται στη συλλογή και επεξεργασία ενός τεράστιου όγκου
δεδοµένων σχετικά µε την εκτέλεση του λογισµικού. Τα δεδοµένα προέρχονται
από την εκτύπωση διαγνωστικών µηνυµάτων, την εκτύπωση αντιγράφων της µνή-
µης, την επιλεκτική ιχνηλάτηση µεταβλητών, τη χρήση σηµείων διακοπής και
την εισαγωγή ισχυρισµών.
Κυκλωµατική πολυπλοκότητα (cyclomatic complexity)
Mέτρο της λογικής πολυπλοκότητας ενός τµήµατος λογισµικού, το οποίο παρέ-
χει ένα άνω όριο των δοκιµών δοµικού ελέγχου που πρέπει να εφαρµοστούν ώστε
να διασφαλίζεται ότι κάθε εντολή του κώδικα έχει δοκιµαστεί τουλάχιστον µια
φορά και κάθε συνθήκη έχει δοκιµαστεί για καθένα από τα δύο δυνατά εξαγόµε-
να.
Λειτουργικός έλεγχος (functional testing)
Σύνολο τεχνικών µε τις οποίες δοκιµάζεται η εξωτερικά παρατηρήσιµη συµπερι-
φορά του λογισµικού σε σχέση µε τις προδιαγραφές του. Ο έλεγχος γίνεται στο
σύνολο των λειτουργιών του λογισµικού, χωρίς να ελέγχεται ο κώδικας και περι-
λαµβάνει τη δοκιµή των εξόδων σε σχέση µε τις εισόδους του συστήµατος, της
επικοινωνίας µε άλλα τµήµατα λογισµικού και της ακεραιότητας των δεδοµένων.
Περιλαµβάνει τις ακόλουθες τεχνικές: διαµέριση σε κλάσεις ισοδυναµίας, ανάλυ-
ση οριακών τιµών, γραφήµατα αιτίου – αποτελέσµατος και συγκριτική δοκιµή.
Λογισµικό χωρίς ελαττώµατα (zero defect software)
βλ. ∆ιαδικασία του καθαρού δωµατίου.
Μέσος χρόνος ανάµεσα στην εµφάνιση σφαλµάτων
(mean time between failures – MTBF)
Mέτρο της αξιοπιστίας του λογισµικού (βλ. σχετικά) που ορίζεται ως εξής: MTBF
= MTTF + MTTR, όπου MTTF είναι ο µέσος χρόνος µέχρι την εµφάνιση του
επόµενου σφάλµατος και MTTR είναι ο µέσος χρόνος που απαιτείται για τη διόρ-
θωση ενός σφάλµατος.
Μετρικές ποιότητας (metrics)
Xαρακτηριστικά του λογισµικού που συµµετέχουν στον υπολογισµό των τιµών
των παραγόντων ποιότητας (βλ. σχετικά). Συνήθως, χρησιµοποιούνται είκοσι µία
µετρικές.
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 220
Μοντέλο V (V model)
Eπέκταση του γνωστού µοντέλου κύκλου ζωής λογισµικού «καταρράκτη», στο
οποίο κάθε δραστηριότητα του κύκλου ανάπτυξης συσχετίζεται µε µια δραστη-
ριότητα Ε&Ε.
Οδηγός (driver)
Σύντοµος κώδικας, ο οποίος χρησιµοποιείται στη θέση ενός µεγαλύτερου τµή-
µατος το οποίο δεν έχει ακόµη υλοποιηθεί για να «οδηγήσει» (δηλαδή να καλέ-
σει) την εκτέλεση υφιστάµενων τµηµάτων λογισµικού.
Ολοκλήρωση (integration)
βλ. Συγκρότηση λογισµικού.
Οµάδα δοκιµής (testing group)
Oµάδα ατόµων που δεν έχουν εµπλακεί στην υλοποίηση του λογισµικού και
έχουν ως καθήκον την εξαντλητική δοκιµή του λογισµικού µε στόχο την ανακά-
λυψη σφαλµάτων.
Οµάδα εξασφάλισης της ποιότητας (SQA group)
Oµάδα ατόµων που βοηθούν το διαχειριστή ενός έργου στην λήψη των απαραί-
τητων µέτρων για τη διασφάλιση της ποιότητας του λογισµικού.
Οπισθοδρόµηση (backtracking)
Tεχνική εκσφαλµάτωσης, σύµφωνα µε την οποία, η εκτέλεση του κώδικα του
λογισµικού ιχνηλατείται από το σηµείο όπου εµφανίστηκε το σφάλµα προς τα
πίσω, µέχρι να αποκαλυφθεί το ελάττωµα που προκάλεσε το σφάλµα. Η τεχνική
αυτή µπορεί να προσδιορίσει τη γενικότερη «περιοχή» του κώδικα όπου «κρύ-
βεται» το ελάττωµα.
Περιήγηση (walkthrough)
Eίδος αναθεώρησης, κατά την οποία η οµάδα σχεδίασης ή ανάπτυξης ενός τµή-
µατος λογισµικού (συνήθως µέσω ενός εκπροσώπου της που καλείται «αναθεω-
ρούµενος» – βλ. σχετικά) παρουσιάζει το προϊόν στην οµάδα αναθεώρησης
(καλούνται «επιθεωρητές» – βλ. σχετικά). Στο τέλος της περιήγησης συντάσσε-
ται η αναφορά περιήγησης (βλ. σχετικά).
2 2 1 ° § ø™ ™ ∞ ƒ π √ √ƒ ø¡
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 221
2 2 2 E ° ∫ À ƒ √¶√π ∏™ ∏ § √° π ™ ªπ ∫ √À
Περίπτωση ελέγχου (test case)
∆οκιµαστική εκτέλεση του υπό έλεγχο λογισµικού χρησιµοποιώντας δεδοµένα
ελέγχου εισόδου (βλ. σχετικά). Με βάση τα δεδοµένα ελέγχου, καταγράφονται
οι έξοδοι του λογισµικού και συγκρίνονται τα αποτελέσµατα µε τις προδιαγρα-
φές εισόδου και συµπεριφοράς του λογισµικού, µε στόχο να ανακαλυφθούν
παρεκκλίσεις. Υπάρχουν τρεις διαδεδοµένες τεχνικές σχεδίασης περιπτώσεων
ελέγχου, ο λειτουργικός έλεγχος, ο δοµικός έλεγχος και ο έλεγχος διεπαφών (βλ.
σχετικά). Αυτές εφαρµόζονται µε τον τρόπο που περιγράφει η στρατηγική ελέγ-
χου λογισµικού της επιχείρησης (βλ. σχετικά).
Περίπτωση χρήσης (use case)
βλ. Προσοµοίωση
Ποιότητα λογισµικού (software quality)
Περιλαµβάνει την ικανοποίηση ρητά εκφρασµένων απαιτήσεων σχετικά µε τη
λειτουργία και την απόδοση του λογισµικού, την τεκµηριωµένη υιοθέτηση απο-
δεκτών προτύπων ανάπτυξης και την ενσωµάτωση όλων εκείνων των χαρακτη-
ριστικών που έχει οποιοδήποτε λογισµικό έχει αναπτυχθεί µε συστηµατικό τρόπο.
Μετρείται κυρίως µε βάση τις απαιτήσεις που έχουν εκφρασθεί (ή υπονοηθεί)
από τους χρήστες και επηρεάζεται από ένδεκα παράγοντες, οι τιµές των οποίων
υπολογίζονται µε βάση ένα σύνολο µετρικών (βλ. σχετικά).
Προσοµοίωση (simulation)
∆οκιµαστική εκτέλεση του λογισµικού, στην οποία γίνεται προσπάθεια να προ-
σεγγιστεί το πραγµατικό περιβάλλον λειτουργίας του λογισµικού (δηλαδή να ανα-
παρασταθεί στο χώρο ανάπτυξης το λογισµικό και το υλικό που βρίσκεται στο
περιβάλλον χρήσης του λογισµικού), αλλά και η λειτουργία τµηµάτων του λογι-
σµικού που δεν έχουν ακόµη υλοποιηθεί.
Στατική ανάλυση (static analysis)
Eφαρµόζεται κυρίως στον κώδικα του λογισµικού, αλλά µπορεί να εφαρµοστεί
και στις προδιαγραφές ή το σχέδιο του λογισµικού. Περιλαµβάνει την ανάλυση
της ροής ελέγχου (κυρίως των βρόχων και των διακλαδώσεων), της χρήσης των
µεταβλητών, των διεπαφών των τµηµάτων, της ροής πληροφορίας από τις µετα-
βλητές εισόδου στις µεταβλητές εξόδου και των µονοπατιών εκτέλεσης του λογι-
σµικού.
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 222
Στέλεχος (stub)
Σύντοµος κώδικας ο οποίος εξοµοιώνει τη λειτουργία ενός τµήµατος λογισµικού
το οποίο δεν έχει ακόµη υλοποιηθεί.
Στρατηγική ελέγχου (testing strategy)
Σύνολο δραστηριοτήτων, µε τις οποίες προσδιορίζεται και εφαρµόζεται το ικανό
και αναγκαίο σύνολο περιπτώσεων ελέγχου που µπορεί να εγγυηθεί την αξιοπι-
στία του λογισµικού. Επικεντρώνεται συνήθως στον έλεγχο των λειτουργιών που
πραγµατικά παρέχει το λογισµικό και των πιο συνηθισµένων περιπτώσεων χρή-
σης. Περιλαµβάνει τέσσερα στάδια (σχεδίαση περιπτώσεων ελέγχου, προετοι-
µασία δεδοµένων ελέγχου, δοκιµαστική εκτέλεση και αξιολόγηση αποτελεσµά-
των) και ένα αντίστοιχο σύνολο αναφορών.
Συγκρότηση λογισµικού (software integration)
Tο «χτίσιµο» ενός συστήµατος λογισµικού από την ενσωµάτωση ή συνένωση
ελεγµένων µικρότερων τµηµάτων (βλ. ∆οκιµή συγκρότησης).
Συµβολική εκτέλεση (symbolic execution)
∆υναµική τεχνική Ε&Ε, σύµφωνα µε την οποία καταχωρούνται συµβολικές (όχι
πραγµατικές) τιµές στις µεταβλητές εισόδου του λογισµικού και ιχνηλατείται η
εκτέλεσή του, χειρωνακτικά ή χρησιµοποιώντας αυτοµατοποιηµένα εργαλεία.
Σύνολο βασικών µονοπατιών (basis path set)
Πρόκειται για ένα σύνολο από γραµµικά ανεξάρτητα µονοπάτια εκτέλεσης, από
το οποίο είναι δυνατό να παραχθούν µε συνδυασµό δύο ή περισσότερων µελών
του, όλα τα δυνατά µονοπάτια εκτέλεσης ενός τµήµατος κώδικα. Προκύπτει από
την ανάλυση του γραφήµατος ροής (βλ. σχετικά), διασφαλίζει ότι κάθε εντολή
του κώδικα ανήκει σε ένα τουλάχιστον µέλος του συνόλου και χρησιµοποιείται
κατά το δοµικό έλεγχο του λογισµικού (βλ. σχετικά).
Σφάλµα (bug, error)
Πρόκειται για την εµφάνιση λανθασµένης συµπεριφοράς κατά την εκτέλεση του
λογισµικού, η οποία οφείλεται σε ένα ή περισσότερα ελαττώµατα (faults) του
λογισµικού (βλ.σχετικά).
2 2 3 ° § ø™ ™ ∞ ƒ π √ √ƒ ø¡
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 223
2 2 4 E ° ∫ À ƒ √¶√π ∏™ ∏ § √° π ™ ªπ ∫ √À
Σχέδιο Ε&Ε (V&V plan)
Περιγράφει επακριβώς τις διαδικασίες Ε&Ε που θα εκτελεστούν στα πλαίσια του
έργου.
Σχέδιο ποιότητας (SQA plan)
Περιλαµβάνει τα έγγραφα και τις διαδικασίες που είναι απαραίτητες για την εξα-
σφάλιση της ποιότητας του λογισµικού, καθώς και ένα κατάλογο ελέγχων ποιό-
τητας.
Τεχνικές Ε&Ε (V&V techniques)
Tρόποι, µεθοδολογίες, εργαλεία που χρησιµοποιούνται κατά την εφαρµογή δρα-
στηριοτήτων Ε&Ε. ∆ιακρίνονται σε τυπικές και µη τυπικές τεχνικές Ε&Ε, οι
οποίες µε τη σειρά τους, διακρίνονται σε στατικές και δυναµικές τεχνικές.
Τυπική επαλήθευση (formal verification)
Mεθοδολογία επαλήθευσης, η οποία χρησιµοποιεί µαθηµατικά εργαλεία για να
αποδείξει ότι ένα πρόγραµµα ικανοποιεί τις προδιαγραφές του.
Φάση Ε&Ε (V&V phase)
βλ. Εγκυροποίηση.
Χρόνος διακοπής λειτουργίας (downtime)
Περιλαµβάνει το χρονικό διάστηµα κατά το οποίο το λογισµικό δεν είναι διαθέ-
σιµο λόγω εµφάνισης σφάλµατος και το χρόνο επιδιόρθωσης του σφάλµατος.
Χρόνος επιδιόρθωσης (repair time)
Περιλαµβάνει το χρονικό διάστηµα που απαιτείται για τη διάγνωση του σφάλ-
µατος, τον εντοπισµό του ελαττώµατος, τη διόρθωση του ελαττώµατος, τον έλεγ-
χο παλινδρόµησης του διορθωµένου λογισµικού και την επανεκκίνηση του συστή-
µατος (βλ. σχετικά).
K·Ì¤·˜ II (224) 18/7/2003 11:20 ™ÂÏ›‰· 224

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->