-
Notifications
You must be signed in to change notification settings - Fork 1
/
EESL-greek.tex
408 lines (262 loc) · 82.7 KB
/
EESL-greek.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
\documentclass[12pt]{article}
\usepackage{enumerate}
\usepackage{xcolor}
\usepackage[utf8]{inputenc}
\usepackage[greek, english]{babel}
\usepackage{alphabeta}
\usepackage{libertine}
\usepackage{graphicx}
\usepackage{biblatex}
\usepackage{wrapfig}
\usepackage{hyperref}
\pagenumbering{arabic}
\newcommand{\quotebox}[1]{\begin{center}\fcolorbox{white}{blue!15!gray!15}{\begin{minipage}{0.9\linewidth}\vspace{10pt}\center\begin{minipage}{0.8\linewidth}{\space\Huge``}{#1}{\hspace{1.5em}\break\null\Huge\hfill''}\end{minipage}\smallbreak\end{minipage}}\end{center}}
\newcommand{\linkstyle}[1]{\color{blue}\underline{#1}}
\graphicspath{ {./images/} }
\addbibresource{refs.bib}
\title{Θεωρητικές και Εφαρμοσμένες Τεχνικές Ελέγχου σε Σύγχρονα Αντικειμενοστραφή Συστήματα\\\large Οικονομικό Πανεπιστήμιο Αθηνών}
\author{Τσίρμπας Δημήτριος, Μανδελιάς Αλέξιος}
\begin{document}
\begin{titlepage}
\maketitle
\end{titlepage}
\tableofcontents
\newpage
\section{Περίληψη}
Η επαλήθευση και η επικύρωση του λογισμικού ήταν ανέκαθεν μια από τις πιο σημαντικές πτυχές της ανάπτυξης λογισμικού. Αυτήν τη στιγμή εκτιμάται ότι πάνω από το 50\% του χρόνου ανάπτυξης του λογισμικού καταναλώνεται στη φάση της δοκιμής/επαλήθευσης (testing). Από την άλλη, η επικράτηση των αντικειμενοσταφών γλωσσών προγραμματισμού έχει αλλάξει ριζικά, πέρα από τον τρόπο της σχεδίασης και ανάπτυξης του λογισμικού, και τις απαιτήσεις και δυσκολίες στην διαδικασία της επαλήθευσης, με αποτέλεσμα πολλές παραδοσιακές τεχνικές επαλήθευσης να μην εξυπηρετούν πια τους προγραμματιστές. Για αυτόν τον λόγο έχει διεξαχθεί εντατική έρευνα τα τελευταία χρόνια με σκοπό τόσο να προσδιοριστούν ποιές τεχνικές είναι ακόμα αποτελεσματικές, όσο και να βρεθούν καινούριες, κατάλληλες για τις προκλήσεις των αντικειμενοστραφών συστημάτων. Σε αυτήν την αναφορά ερευνούμε τις δυσκολίες που επιφέρει η χρήση του αντικειμενοστρεφούς μοντέλου στη διαδικασία της επαλήθευσης, τις διαφορές της αντικειμενοστρεφούς επαλήθευσης από την παραδοσιακή (διαδικαστική) και τρόπους συμφιλίωσης των διαφορών αυτών. Αναλύουμε ποιές τεχνικές τελικά άντεξαν την πάροδο του χρόνου και παραμένουν σε χρήση ακόμα, καθώς και καινούριες τεχνικές και εργαλεία που αναπτύχθηκαν για να αντιμετωπίσουν τις σύγχρονες προκλήσεις.
\section{Διαδικαστικό vs Αντικειμενοστραφές μοντέλο επαλήθευσης}
\par Οι κύριες διαφορές μεταξύ των μεθόδων επαλήθευσης των δύο μοντέλων ανάπτυξης συνοψίζονται στην εικόνα \ref{fig:hayes_table} (\textcite{hayes} όπως αναφέρεται από τους \textcite{gordon}).
\begin{figure}
\label{fig:hayes_table}
\caption{Τα πιο σχετικά αξιώματα του Hayes}
\includegraphics[width=\textwidth,height=\textheight,keepaspectratio]{hayes_table.PNG}
\end{figure}
\par Ο πίνακας αυτός αναφέρεται σε 5 από τα 11 αξιώματα του Haeys, καθώς τα υπόλοιπα είναι κοινά μεταξύ των μοντέλων ανάπτυξης, σύμφωνα με τον συγγραφέα. Μπορούμε να εκτιμήσουμε λοιπόν ότι οι μισές αρχές στις οποίες βασίζονται οι έλεγχοι στο διαδικαστικό μοντέλο δεν ισχύουν στο αντικειμενοστρεφές.
\par Ακολούθως περιγράφουμε αναλυτικά τις διαφορές αυτές, καθώς και τις δυσκολίες με τις οποίες αυτές σχετίζονται.
\subsection{Κατάσταση}
Στο διαδικαστικό μοντέλο ένας έλεγχος μπορεί να θεωρηθεί ως ένα διατεταγμένο σύνολο ζευγών εισόδου-εξόδου, αφού το αποτέλεσμα μιας κλήσης στο μοντέλο αυτό εξαρτάται μόνο από την είσοδο που της δίνεται.
\par Στο αντικειμενοστρεφές μοντέλο κάθε αντικείμενο έχει κατά κανόνα μια εσωτερική κατάσταση. Οι μέθοδοι που καλούνται στο αντικείμενο αυτό όχι μόνο παράγουν εξόδους αλλά και αλλάζουν την εσωτερική του κατάσταση (έχουν δηλαδή παρενέργειες – side effects).
\par Είναι επομένως εμφανές, πως στο αντικειμενοστραφές μοντέλο η παραπάνω αναπαράσταση του ελέγχου δεν εφαρμόζεται, αφού το αποτέλεσμα μιας κλήσης καθορίζεται από την κατάσταση του αντικειμένου στο οποίο καλείται, η οποία μπορεί να αλλάξει μεταξύ των κλήσεων. Μία επιπλέον δυσκολία είναι ότι η αλλαγή της κατάστασης πολλές φορές δε γίνεται αντιληπτή παρατηρώντας τις εξόδους του προγράμματος.
\par Για να αντεπεξέλθουν οι έλεγχοι στις νέες απαιτήσεις, πρέπει να λαμβάνεται υπόψιν κατά τον έλεγχο και η αλλαγή στην εσωτερική κατάσταση των αντικειμένων και όλες οι διαφορετικές σειρές κλήσεων των μεθόδων του.
\par Πιο συγκεκριμένα σύμφωνα με τους \textcite{gordon}, για έναν ορθό και ανεπτυγμένο έλεγχο απαιτούνται:
\begin{itemize}
\item Μια λίστα από μηνύματα και πράξεις που \textit{μπορούν} να εκτελεστούν από αυτόν.
\item Μια λίστα από εξαιρέσεις που μπορεί ή πρέπει να πεταχτούν.
\item Ένα σταθερό περιβάλλον εκτέλεσης.
\item Όλες οι συμπληρωματικές πληροφορίες που είναι απαραίτητες στον έλεγχο.
\end{itemize}
\subsection{Πολυμορφισμός}
\par Ο πολυμορφισμός εισαγάγει το πρόβλημα ότι δεν υπάρχουν σταθερές υποθέσεις κατά τη διάρκεια της μεταγλώττισης. Επειδή είναι μια δυναμική λειτουργία, είναι αδύνατο να ξέρουμε κατά τον έλεγχο \textit{ποιος} κώδικας θα εκτελεστεί.
\par Οι κλάσεις στο αντικειμενοστρεφές μοντέλο είναι κατά κανόνα άπειρα επεκτάσιμες, και κάθε επέκταση της κλάσης μπορεί να επεκτείνει και να επαναπροσδιορίσει τις λειτουργίες των κλάσεων πάνω από αυτή στην ιεραρχία. Για κάθε έλεγχο επομένως θα αναγκαζόμασταν να ελέγξουμε όλες τις πιθανές υποκλάσεις του αντικειμένου, πράγμα αδύνατο, αφού οποτεδήποτε μπορούμε να προσθέσουμε μια καινούρια υποκλάση της κλάσης του.
\par Ένα καλό παράδειγμα του προβλήματος δίνεται από τους \textcite{claurence}:
\quotebox{
Ως παράδειγμα, έστω μια μέθοδος που χρησιμοποιείται για τη σχεδίαση γραφικών. Αν περάσετε τρεις παραμέτρους, η μέθοδος draw δημιουργεί ένα τρίγωνο, αν τέσσερις ένα ορθογώνιο, αν πέντε ένα πεντάγωνο κ.ο.κ. Στην περίπτωση αυτή υπάρχουν τρεις διαφορετικές μέθοδοι με το ίδιο όνομα, αλλά δέχονται διαφορετικό αριθμό παραμέτρων κατά την κλήση τους. Γενικά, η επιλογή της σωστής υπερφορτωμένης μεθόδου καθορίζεται κατά την εκτέλεση (δυναµική δέσµευση) από τον µεταγλωττιστή µε βάση τον τύπο και τον αριθµό των ορισμάτων που δίνονται κατά την κλήση:
\begin{itemize}
\item Χρειαζόµαστε µόνο µία υπερφορτωμένη μέθοδο;
\item Ελέγχουμε όλες τις υπερφορτωμένες μεθόδους;
\item Αν όλες, χρειάζεται να τις δοκιμάσουμε όλες σε όλες τις κλάσεις της ιεραρχίας;
\end{itemize}
\par Δεν υπάρχει μια συγκεκριμένη απάντηση για αυτά τα ερωτήματα. Οι απαντήσεις σε αυτά τα ερωτήματα εξαρτώνται από τους ελεγκτές, τις εταιρικές πολιτικές κ.λπ. Σε έναν τέλειο κόσμο θα δοκιμάζαμε τα πάντα. Ωστόσο, στην πραγματικότητα είναι συχνά αδύνατο να δοκιμάσουμε τα πάντα σε έργα μεγάλης κλίμακας.
}
\par Οι συγγραφείς εδώ αναφέρονται και στην λειτουργία της δυναμικής δέσμευσης (dynamic binding). Για παράδειγμα η C++ χρησιμοποιεί κυρίως στατική δέσμευση, η οποία γίνεται κατά τη διάρκεια της μεταγλώττισης, ενώ η Java δυναμικό, μέσω του JVM (Java Virtual Machine). Στην περίπτωση της δεύτερης, επειδή το πρόγραμμα ξέρει μόνο κατά τη διάρκεια της εκτέλεσης τους τύπους παραμέτρων, επιστροφής και άλλων δεδομένων που θα χρησιμοποιηθούν, τα παραπάνω προβλήματα διογκώνονται.
\par Οι συγγραφείς συμβουλεύουν το πρόβλημα του πολυμορφισμού να μετακινηθεί όσο γίνεται στο επίπεδο Ελέγχου Συστήματος και Συνένωσης αντί για το επίπεδο Ελέγχου Μονάδας.
\par Στο \textcite{chandra} μια λύση που προτείνεται είναι να οριστεί μια προδιαγραφή ιεραρχίας («hierarchy specification»), δηλαδή όλες οι υποκλάσεις συμφωνούν σε μια κοινή, ελάχιστη λειτουργικότητα. Άλλες λύσεις θα αναλυθούν αργότερα στο έγγραφο.
\subsection{Κληρονομικότητα}
Στο παραπάνω εδάφιο έγινε μια σύντομη αναφορά στο πρόβλημα της επικάλυψης (override) των μεθόδων της υπερκλάσης. Το πρόβλημα αυτό δεν περιορίζεται μόνο στο άπειρο πλήθος των πιθανών αντικειμένων που απαντάνε μια κλήση, αλλά επεκτείνεται και στο πεδίο της ίδιας της υπερκλάσης.
\par Έστω ότι έχουμε μια πλήρως ελεγμένη κλάση Α και μια υποκλάση της Β που επαναπροσδιορίζει μόνο ένα υποσύνολο των μεθόδων της Α. Θα ήταν φυσικό να υποθέσουμε ότι χρειάζεται να ελέγξουμε μόνο τις μεθόδους αυτές. Σύμφωνα με τους \textcite{perry} όπως αναφέρεται από τους \textcite{barbey}, αυτή η υπόθεση δεν ισχύει, επειδή οι αλλαγμένες μέθοδοι ενδέχεται να χρησιμοποιούνται από άλλες κληρονομημένες, αλλάζοντας έτσι τη συμπεριφορά των δεύτερων ή αλλάζοντας την εσωτερική κατάσταση των αντικειμένων. Ένα ακόμα πρόβλημα που δημιουργεί η κληρονομικότητα είναι η παραβίαση της ενθυλάκωσης, καθώς μια υποκλάση μπορεί να έχει πρόσβαση - έμμεσα ή άμεσα – στα δεδομένα των άμεσων και έμμεσων υπερκλάσεών της.
\par Επομένως, αναγκαζόμαστε είτε να επαληθεύσουμε εκ νέου όλες τις ιδιότητες της καινούριας κλάσης είτε να ανακαλύψουμε το ελάχιστο σύνολο από τις ιδιότητες οι οποίες είναι διαφορετικές από την κλάση-γονέα. Αλγόριθμοι και τεχνικές για την εύρεση αυτού του συνόλου δίνονται αργότερα στο έγγραφο.
\par Περιέργως, η πολλαπλή κληρονομικότητα δεν δημιουργεί προβλήματα στη διαδικασία της επαλήθευσης, τουλάχιστον όσον αφορά στις μοντέρνες αντικειμενοστρεφείς γλώσσες (\textcite{barbey}, page 11).
\subsection{Ενθυλάκωση}
Η ενθυλάκωση (encapsulation / data hiding) είναι μια θεμελιώδης αρχή του αντικειμενοστραφούς προγραμματισμού, σύμφωνα με την οποία τα εσωτερικά δεδομένα ενός αντικειμένου μπορούν να μεταβληθούν και να προσπελαστούν μόνο μέσω μιας διεπαφής. Εφόσον, όπως εξηγήθηκε παραπάνω, ο έλεγχος της εσωτερικής κατάστασης του αντικειμένου είναι απαραίτητος για τον έλεγχο κλάσεων, ο περιορισμός της ορατότητας δε μας επιτρέπει να αξιολογήσουμε ορθά την κατάσταση αυτή.
\par Οι διαισθητικές λύσεις απαιτούν είτε να παραβούμε την ενθυλάκωση την ίδια, είτε να παραγάγουμε κλάσεις που μας παρέχουν μεθόδους πρόσβασης. Η πρώτη λύση παραβαίνει τον λόγο ύπαρξης της κλάσης ενώ η δεύτερη ενδέχεται να μην λύσει καν το πρόβλημα, σε περιπτώσεις όπου η υποκλάση δεν έχει πρόσβαση στα εσωτερικά δεδομένα της εξεταζόμενης κλάσης.\newline
Τέλος περιλαμβάνουμε έναν πίνακα (Πίνακας \ref{fig:panos}) από τους \textcite{kung} στον οποίο συνοψίζονται οι κύριες αλλαγές στους ελέγχους, που επιφέρουν αλλαγές στον κώδικα.
\begin{figure}
\label{fig:panos}
\caption{Πιθανές αλλαγές στον κώδικα των ελέγχων}
\includegraphics[width=\textwidth,height=\textheight,keepaspectratio]{code_changes_table.PNG}
\end{figure}
\section{Λύσεις}
\subsection{Έλεγχος Μονάδων}
Κατά τον Έλεγχο Μονάδων συγγράφονται περιπτώσεις ελέγχου οι οποίες καλύπτουν κατά το δυνατόν περισσότερες καταστάσεις των αντικειμένων του λογισμικού σε μια προσπάθεια εύρεσης λαθών. Όσο η πολυπλοκότητα του λογισμικού αυξάνεται, ο εξαντλητικός έλεγχος όλων των μονοπατιών εκτέλεσης και όλων των συμπεριφορών των αντικειμένων του συστήματος καθίσταται πρακτικά αδύνατος. Αυτό δυσχεραίνεται από το γεγονός ότι ο αριθμός των πιθανών καταστάσεων ενός μόνο αντικειμένου του λογισμικού είναι απαγορευτικά μεγάλος για να ελεγχθεί με το χέρι και τα εργαλεία αυτόματης κατασκευής περιπτώσεων ελέγχου κατασκευάζουν ένα επίσης απαγορευτικά μεγάλο δέντρο πιθανών καταστάσεων. Ακόμη, ο παραδοσιακός τρόπος ελέγχου με hard-coded δεδομένα αισθητά περιορίζει το πλήθος διαφορετικών μονοπατιών εκτέλεσης που όντως ελέγχονται με αποτέλεσμα μια οριστική απάντηση για το αν υπάρχουν ακόμη σφάλματα να είναι ακόμη πιο δύσκολο να δοθεί.
\subsubsection{YAQC4J}
Ένα παράδειγμα προσαρμογής πιο παραδοσιακών τεχνικών ελέγχου στο αντικειμενοστραφές μοντέλο είναι το εργαλείο είναι το YAQC4J. Η τεχνική που χρησιμοποιείται είναι η τυχαιοποιημένη παραγωγή δεδομένων, η οποία πρωτοεμφανίστηκε στον συναρτησιακό προγραμματισμό, και συγκεκριμένα με το εργαλείο QuickCheck\cite{quickcheck}. Οι βασικές αρχές που διέπουν τη λειτουργία του QuickCheck αναπροσαρμόστηκαν και επεκτάθηκαν για το αντικειμενοστρεφές μοντέλο προγραμματισμού και υλοποιούνται στο εργαλείο YAQC4J, το οποίο μπορεί να χρησιμοποιηθεί συμπληρωματικά με τις υπάρχουσες μεθόδους ελέγχου, την αποτελεσματικότητα των οποίων επαυξάνει\cite{andres}.
\par Το εργαλείο αναλαμβάνει να παραγάγει τα τυχαιοποιημένα αντικείμενα και έπειτα να εκτελέσει τις περιπτώσεις ελέγχου έναν μεγάλο αριθμό φορών έως ότου είτε μια εκτέλεση να αποτύχει, είτε ένας προκαθορισμένος αριθμός από εκτελέσεις να επιτύχει. Αν αποτύχει, μαθαίνουμε ότι βρέθηκε κάποιο σφάλμα στο λογισμικό, αλλιώς μαθαίνουμε με μεγάλο αριθμό βεβαιότητας πως το λογισμικό δεν περιέχει σφάλματα.
\par Παρόλο που βασίζεται στην ίδια λογική με τον προκάτοχό του, το YAQC4J σίγουρα δεν χαίρει την ίδια δημοσίοτητα με αυτόν. Αυτό, μαζί με την σχετική έλλειψη δημοφιλών εργαλείων που βασίζονται στην παραγωγή τυχαίων δεδομένων, είναι μια ένδειξη ότι η συγκεκριμένη τεχνική \textbf{δεν} προτιμάται από τους προγραμματιστές αντικειμενοστραφών προγραμμάτων.
\subsection{Έλεγχος Συνένωσης}
Όσο προχωράει η ανάπτυξη του λογισμικού, δίδεται όλο και περισσότερη προσοχή στη λειτουργικότητα του λογισμικού, επομένως ο έλεγχος συνένωσης οφείλει να εξασφαλίζει τη σωστή συμπεριφορά του λογισμικού όσο συνενώνει διαφορετικές μονάδες μεταξύ τους. Οι καταστάσεις των αντικειμένων καθώς και η υπερφόρτωση μεθόδων και η δυναμική σύνδεση αντικειμένων με τις αναφορές τους καθιστούν τον έλεγχο διεπαφών δύσκολο, καθώς σε κάθε εκτέλεση και η εσωτερική κατάσταση των αντικειμένων αλλάζει, αλλά και σε κάθε κλήση μεθόδου αντιστοιχούν πιθανόν πολλές υλοποιήσεις.
Προβλήματα που πρέπει να αντιμετωπιστούν κατά τον έλεγχο συνένωσης είναι τα εξής:
\begin{enumerate}
\item Θέλουμε να έχουμε τον σκελετό του συστήματος το νωρίτερο δυνατό
\item Κατά τη συνένωση προσέχουμε έτσι ώστε οι διεπαφές των μονάδων ενώνονται και αλληλοεπιδρούν σωστά
\item Οι μονάδες επικοινωνούν αρκούντως ικανοποιητικά έτσι ώστε να μπορεί να διεξαχθεί έλεγχος συστήματος.
\end{enumerate}
\paragraph{Προσέγγιση}
Για τον Έλεγχο Συνένωσης πρέπει να απαντήσουμε στα ακόλουθα τρία ερωτήματα:
\begin{enumerate}
\item Πόσα αντικείμενα πρέπει να φτιάξουμε προτού αρχίσουμε τους ελέγχους;
\item Με ποια σειρά πρέπει να συνενώσουμε τις διαφορετικές μονάδες;
\item Χρειάζεται πάνω από ένας σκελετός για την συνένωση;
\end{enumerate}
\par Η προτεινόμενη μέθοδος που απαντάει στις 3 αυτές ερωτήσεις είναι η ακόλουθη και χρησιμοποιεί μια «εικονική μηχανή συνένωσης» που είναι υπεύθυνη για τη συνένωση των μεμονωμένων κομματιών ενός συστήματος. Η μηχανή έχει ως είσοδο μια λίστα με τα use cases του λογισμικού καθώς και μια λίστα με τα αντικείμενα που θα χρησιμοποιηθούν. Προσπαθεί να εκτελέσει με τη σειρά κάθε use case και κάθε φορά που απαιτείται κάποιο καινούριο αντικείμενο, επιλέγεται κάποιο από τη λίστα, το οποίο ακολούθως ελέγχεται σε συνδυασμό με τα υπόλοιπα που έχουν προηγουμένως επιλεγεί για σωστή λειτουργικότητα και συνένωση.
\par Αυτή η μηχανή απαντάει στις τρεις αυτές ερωτήσεις καθώς κατασκευάζει αντικείμενα όταν αυτά χρειαστούν, οι διαφορετικές μονάδες συνενώνονται σύμφωνα με τη σειρά που καθορίζεται από το λογισμικό και παρέχει έναν σκελετό για τη συνένωση.
\subsection{Διαφορικός Έλεγχος}
Μια από τις μεγαλύτερες δυσκολίες κατά τον έλεγχο είναι η αξιολόγηση του αποτελέσματος του ελέγχου. Τα σύγχρονα συστήματα λογισμικού είναι τόσο περίπλοκα που αποτελεί συχνά πρόκληση ο εκ των προτέρων προσδιορισμός του αναμενόμενου αποτελέσματος, πόσο μάλλον για τους τυχαιοποιημένους ελέγχους. Απαιτείται, λοιπόν, η χρήση ενός «μαντείου» με τη βοήθεια του οποίου να αποφανθούμε αν ένας έλεγχος είναι επιτυχής ή όχι. Τα καταστροφικά λάθη στο λογισμικό εντοπίζονται σχετικά εύκολα, όμως τα λογικά και σημασιολογικά λάθη δύσκολα ανιχνεύονται με παραδοσιακές μεθόδους.
\par Ο Διαφορικός Έλεγχος αποτελεί προσπάθεια εντοπισμού εκείνων των δυσεύρετων λογικών και σημασιολογικών σφαλμάτων στο λογισμικό δίνοντας την ίδια είσοδο σε πολλές παρόμοιες εφαρμογές και παρατηρώντας διαφοροποιήσεις στην έξοδο του λογισμικού ή στη συμπεριφορά του. Χρησιμοποιώντας σαν «μαντείο» τις διαφορετικές υλοποιήσεις εντοπίζονται αποκλίσεις στη συμπεριφορά των προγραμμάτων οι οποίες αποτελούν πιθανό σφάλμα στο λογισμικό \cite{william}.
\paragraph{Μη-Καθοδηγούμενη Παραγωγή Εισόδων}
Νέες είσοδοι παράγονται τυχαία, αγνοώντας τα αποτελέσματα από τις προηγούμενες εκτελέσεις. Μια τέτοια στρατηγική δεν είναι αποδοτική καθώς οι είσοδοι επιλέγονται από ένα απαγορευτικά μεγάλο σύνολο πιθανών εισόδων. Η πιθανότητα εύρεσης στην τύχη εκείνων των εισόδων που θα εμφανίσουν κάποιο σφάλμα λογισμικού είναι εξαιρετικά μικρή, δεδομένης της λανθάνουσας φύσης των σφαλμάτων.
\paragraph{Καθοδηγούμενη Παραγωγή Εισόδων}
Λαμβάνοντας υπόψιν πληροφορίες για τη συμπεριφορά του λογισμικού από προηγούμενες εκτελέσεις μπορούμε πιο αποδοτικά να ελέγξουμε το λογισμικό με τις εισόδους εκείνες οι οποίες είναι πιο πιθανό να αποκαλύψουν κάποιο σφάλμα του λογισμικού.
\paragraph{Εξελικτική Καθοδήγηση Ανεξάρτητη από το Πεδίο}
Χρησιμοποιώντας μετρικές λογισμικού μπορούμε να αξιολογήσουμε τις διαφοροποιήσεις μεταξύ των παρόμοιων προγραμμάτων για να προσδιοριστεί καλύτερα η ποικιλία που υπάρχει μεταξύ τους. Έτσι, επιλέγοντας αυτά τα προγράμματα που εμφανίζουν μεγαλύτερη ποικιλία, εφαρμόζονται πιο αποτελεσματικά τεχνικές διαφορικού ελέγχου με μεθόδους μαύρου κουτιού που είναι ανεξάρτητες πάντα του πεδίου.
\paragraph{Συμβολική Εκτέλεση}
Αυτή η τεχνική ελέγχου άσπρου-κουτιού εκτελεί το πρόγραμμα συμβολικά, υπολογίζοντας περιορισμούς σε κάθε μονοπάτι εκτέλεσης τους οποίους έπειτα επιλύει προκειμένου να παραγάγει εισόδους που ικανοποιούν αυτούς τους περιορισμούς για κάθε μονοπάτι εκτέλεσης. Αυτή η τεχνική, αν και είναι δύσκολο να χρησιμοποιηθεί σε κλίμακα λόγω της εκθετικής πολυπλοκότητας που προκύπτει από τον αριθμό διαφορετικών μονοπατιών εκτέλεσης στα διάφορα παρόμοια προγράμματα, μπορεί να παραγάγει εισόδους για τον διαφορικό έλεγχο.
\subsection{Αρχιτεκτονική}
Η ευκολία σύνταξης σωστών ελέγχων εν μέρει εξαρτάται από τη συνοχή της κλάσης στην οποία αυτοί εφαρμόζονται (\textcite{yeresime} όπως αναφέρεται
από τους \textcite{gordon}). Στο διαδικαστικό μοντέλο η συνοχή (cohesion) σχετίζεται με παρόμοιες παραμέτρους και λειτουργικότητα ενώ στο αντικειμενοστραφές με το πόσο συνεκτικές είναι οι επιμέρους κλάσεις του προγράμματος. Μια κλάση θεωρείται συνεκτική αν όλες οι μέθοδοί της την ορίζουν καλά ως μια αυτοτελή μονάδα.
\par Μια κλάση με υψηλή συνοχή θα έχει μεγάλη ομοιότητα στους τύπους και τις λειτουργίες της, άρα η παραγωγή δεδομένων ελέγχου είναι εύκολη. Στην περίπτωση της χαμηλής συνοχής, η ύπαρξη πολλών ετερογενών δεδομένων και λειτουργιών σημαίνει ότι οι έλεγχοι έχουν μεγαλύτερο κόστος και είναι πιο ευάλωτοι σε σφάλματα.
\par Οι \textcite{gordon} προτείνουν μια μονάδα μέτρησης η οποία αναπαριστά τη συνοχή μιας κλάσης. Παραθέτουμε τον ορισμό της:
\quotebox{
Έλλειψη συνοχής στις μεθόδους (Lack of Cohesion in Methods - LCOM) ορίζεται ως η μαθηματική διαφορά μεταξύ του αριθμού των μεθόδων των οποίων η μεταβλητές στιγμιοτύπου είναι εντελώς ανόμοιες, και του αριθμό των μεθόδων των οποίων οι μεταβλητές στιγμιοτύπου μοιράζονται (Yeresime, et al., 2012).
\par [...]
\par Εάν η μετρική LCOM είναι υψηλή, σημαίνει ότι μια κλάση δεν είναι συνεκτική (και μπορεί να είναι υποψήφια για αναδιαμόρφωση σε δύο κλάσεις). Στο στάδιο των ελέγχων, μια κλάση θα πρέπει να έχει διαφορετικά σύνολα ελέγχων για τις διάφορες μεθόδους και όχι ένα σύνολο ελέγχων για ολόκληρη την κλάση. Αυτό οδηγεί σε σύγχυση και αύξηση της συνολικής πολυπλοκότητας της διαδικασίας ελέγχων.»
Σύμφωνα με τους Badri and Fadel (Badri \& Toure, 2012) η LCOM είναι μια από τις καλύτερες μετρικές για να προβλεφθεί η πολυπλοκότητα του κώδικα.
}
\par Μια δεύτερη έννοια που σχετίζεται με την ευκολία σύνταξης ελέγχων είναι η σύζευξη (coupling). Γενικά υπάρχει μια αντιστρόφως ανάλογη σχέση μεταξύ συνοχής και σύζευξης: όσο πιο πολλή συνοχή έχει μια κλάση τόσο πιο λίγη σύζευξη έχει και αντίστροφα (\textcite{khatri} όπως αναφέρεται από τους \textcite{gordon}).
\par Η σύζευξη είναι μια μέτρηση που εκτιμάει τον βαθμό εξάρτησης μεταξύ κλάσεων του προγράμματος. Ενώ λοιπόν η συνοχή ασχολείται με τις σχέσεις εσωτερικά μιας κλάσης, η σύζευξη ασχολείται με τις σχέσεις \textit{μεταξύ} κλάσεων.
\par Η υψηλή σύζευξη σημαίνει ότι όλες ή οι περισσότερες μέθοδοι πρέπει να κατανοηθούν σαν ένα στενά συνδεδεμένο σύνολο, αντί για ανεξάρτητες λειτουργίες. Αυτό προφανώς επηρεάζει αρνητικά την επαλήθευση αφού οι Έλεγχοι Μονάδας είναι πολύ πιο δύσκολο να γραφτούν. Η χαμηλή σύζευξη είναι ένας από τους στόχους της καλής αρχιτεκτονικής του λογισμικού, ιδιαίτερα για μεγάλα, περίπλοκα συστήματα στα οποία πρέπει κατά το δυνατόν να αποφεύγεται η ανάθεση της επαλήθευσης στον έλεγχο Συστήματος και Συνένωσης.
\par Η δοκιμή των χαρακτηριστικών θα πρέπει να γίνεται σε Ελέγχους Μονάδας και κλάσης. Άλλες δοκιµές περιλαµβάνουν µεθόδους με τιμές επιστροφής που είναι πολυμορφικές, καθώς και πολυμορφικές παραμέτρους. Αυτό γίνεται ευκολότερα σε συστάδες ή σε Ελέγχους Συστήματος.
\subsection{Κληρονομικότητα}
Η υλοποίηση κλάσεων είναι πιο απλή όταν γίνεται από την κορυφή της ιεραρχίας προς τα κάτω. Κατά τον ίδιο τρόπο, ο έλεγχος των κλάσεων σε μια ιεραρχία κληρονομικότητας είναι γενικά πιο απλός όταν προσεγγίζεται από την κορυφή προς τα κάτω. Εξετάζοντας πρώτα την κορυφή μιας ιεραρχίας, μπορούμε να ασχοληθούμε με την κοινή διεπαφή και τον κώδικα και στη συνέχεια με τον κώδικα της περίπτωσης ελέγχου για κάθε υποκλάση. Η υλοποίηση ιεραρχιών κληρονομικότητας από κάτω προς τα πάνω μπορεί να απαιτήσει σημαντική αναδιαμόρφωση του κοινού κώδικα σε μια νέα υπερκλάση. Οι πιθανότητες αντιμετώπισης διαφορετικών δομών κληρονομικότητας και η πρόσθετη δυνατότητα πιθανής αντιμετώπισης πολλαπλών μορφών κληρονομικότητας μπορεί να προσθέσει άλλο ένα επίπεδο πολυπλοκότητας στη διαδικασία δοκιμής. Τα θέματα αυτά εγείρουν μια σειρά από ερωτήματα:
\begin{itemize}
\item Ελέγχουμε πλήρως όλες τις βασικές κλάσεις και τις υποκλάσεις τους και σε ποια επίπεδα πρέπει να ελέγξουμε;
\item Δοκιμάζουμε πλήρως όλες τις βασικές κλάσεις ή μόνο τις αλλαγές ή τροποποιήσεις στις υποκλάσεις, και αν ναι σε ποια επίπεδα;
\item Με ποια σειρά ελέγχουμε την ιεραρχία, από πάνω προς τα κάτω ή από κάτω προς τα πάνω;
\end{itemize}
\par Για να απαντήσουμε στην 3η ερώτηση, η γενικά αποδεκτή απάντηση είναι από πάνω προς τα κάτω. Οι υπόλοιπες ερωτήσεις απαντώνται κυρίως στην\newline
\hyperref[sec:Regression]{\linkstyle{ενότητα της Παλινδρόμησης}}.
\subsection{Τεχνητή Νοημοσύνη}
\par Μελετούμε τη συνεισφορά της Τεχνητής Νοημοσύνης στο έλεγχο λογισμικού εξετάζοντας πώς έχει χρησιμοποιηθεί στα διαφορετικά τμήματα του κύκλου ζωής ελέγχου λογισμικού.
\subsubsection{Επίδραση της Τεχνητής Νοημοσύνης στον Έλεγχο Λογισμικού}
\paragraph{Προδιαγραφή των Ελέγχων \cite{zubair}}
Στην αρχή του κύκλου ζωής ελέγχου λογισμικού συγγράφονται περιπτώσεις ελέγχου σύμφωνα με τις απαιτήσεις του λογισμικού. Οι περιπτώσεις ελέγχου οργανώνονται σε ένα έγγραφο προδιαγραφών προκειμένου να εξασφαλιστεί ότι όλες οι απαιτήσεις έχουν ελεγχθεί.
\par Σε αυτήν τη διαδικασία μπορούν να χρησιμοποιηθούν Info-Fuzzy Networks (IFN) για την εκμαίευση λειτουργικών απαιτήσεων από τα δεδομένα εκτέλεσης με σκοπό την ανάκτηση ελλειπόντων ή ατελών προδιαγραφών, τον προσδιορισμό ενός ελαχίστου συνόλου ελέγχων και την αξιολόγηση της ορθότητας των εξόδων του λογισμικού.
\paragraph{Ξεσκαρτάρισμα Περιπτώσεων Ελέγχου}
Είναι η διαδικασία κατά την οποία επιλέγονται για εκτέλεση μόνο οι πιο αποδοτικές περιπτώσεις ελέγχου με αποτέλεσμα τη μείωση του συνολικού κόστους του ελέγχου.
\par Χρησιμοποιώντας Info-Fuzzy Networks (INF) εντοπίζονται αυτόματα συσχετίσεις μεταξύ εισόδων και των αντίστοιχων εξόδων του λογισμικού. Το INF έπειτα μαθαίνει από αυτές τις συσχετίσεις προκειμένου να δημιουργήσει ένα δέντρο κατηγοριοποίησης για τις περιπτώσεις ελέγχου από το οποίο μετά επιλέγονται οι πιο σημαντικές. Έτσι μειώνεται σημαντικά ο αριθμός συνδυαστικών ελέγχων μαύρου κουτιού.
\paragraph{Παραγωγή Περιπτώσεων Ελέγχου}
Τον προσδιορισμό κριτηρίων καταλληλότητας ελέγχου ακολουθεί η παραγωγή ενός συνόλου ελέγχων που συμμορφώνεται με αυτά τα κριτήρια. Μια τέτοια διαδικασία είναι εμφανώς υπερβολικά περίπλοκη για να εκτελεστεί με το χέρι, ειδικά για πολύπλοκα συστήματα, επομένως υπάρχει μια στροφή προς στην τεχνητή νοημοσύνη σχετικά με την αυτόματη παραγωγή των περιπτώσεων ελέγχου.
\par Αρχικά χρησιμοποιήθηκαν μέθοδοι επαγωγικής μάθησης για την παραγωγή από παραδείγματα εισόδων και εξόδων εκείνων των περιπτώσεων ελέγχου οι οποίες αρκούν για τη διαφοροποίηση του λογισμικού P που ελέγχεται από κάθε άλλο λογισμικό P’ ενός συνόλου εναλλακτικών λογισμικών.
\par Για τον έλεγχο μαύρου κουτιού κατασκευάζεται ένα μοντέλο της συμπεριφοράς του λογισμικού μέσω παραδειγμάτων εισόδων-εξόδων, το οποίο χρησιμοποιείται για να δημιουργήσει νέες εισόδους.
\par Περιπτώσεις ελέγχου μπορούν να παραχθούν αναλύοντας απευθείας το Έγγραφο Προσδιορισμού Απαιτήσεων Λογισμικού χρησιμοποιώντας τεχνικές επεξεργασίας φυσικής γλώσσας (Natural Language Processing, NLP).
\paragraph{Παραγωγή Δεδομένων Ελέγχου}
Για την εκτέλεση των Περιπτώσεων Ελέγχου απαιτείται παραγωγή των δεδομένων τα οποία θα χρησιμοποιηθούν για τον έλεγχο του λογισμικού. Όσο καλύτερη είναι η ποιότητα αυτών των δεδομένων τόσο μεγαλύτερη θα είναι και η κάλυψη του κώδικα από τις περιπτώσεις ελέγχου.
\par Με τη βοήθεια γενετικών αλγορίθμων πραγματοποιείται αναζήτηση στον χώρο των εισόδων του λογισμικού για την εύρεση δεδομένων τα οποία καλύπτουν κάθε μονοπάτι εκτέλεσης.
\par Χρησιμοποιώντας βαθιά μάθηση, με τη μέθοδο της «μαϊμούς» γίνεται εκμάθηση των εισόδων που θα έβαζε ο ελεγκτής του λογισμικού και στατιστική συσχέτισή τους με τα συμφραζόμενα. Ακολούθως η «μαϊμού» προβλέπει νέες εισόδους με βάση τα παρατηρούμενα συμφραζόμενα σε κάθε περίπτωση.
\paragraph{Κατασκευή «Μαντείου» (Oracle) Ελέγχου}
Προκειμένου να επιτελέσει ο έλεγχος λογισμικού σωστά τη λειτουργεία του χρειάζεται ένας μηχανισμός ο οποίος να έχει τη δυνατότητα, δεδομένης μιας εισόδου στο λογισμικό, να διαχωρίσει τη σωστή και λανθάνουσα συμπεριφορά του λογισμικού. Αυτός ο μηχανισμός αποτελεί το πρόβλημα του μαντείου (oracle problem).
\par Αλγόριθμοι μηχανικής μάθησης μπορούν να χρησιμοποιηθούν για την αυτόματη κατασκευή μαντείων, ακόμα και σε περιπτώσεις όπου οι προδιαγραφές λογισμικού είναι ελλιπείς. Κάθε εκτέλεση του ελέγχου παράγει αποτελέσματα με τα οποία τροφοδοτείται ο αλγόριθμος. Το μοντέλο που προκύπτει χρησιμοποιείται ως το μαντείο.
\par Όταν υπάρχει ένα μοντέλο αναφοράς του λογισμικού, τότε μπορεί επίσης να χρησιμοποιηθεί επιβλεπόμενη μηχανική μάθηση μέσω της οποίας το μοντέλο που προκύπτει μαθαίνει να διαχωρίσει τις περιπτώσεις ελέγχου ως επιτυχείς και ανεπιτυχείς.
\par Η επιβλεπόμενη μάθηση εφαρμόζεται και σε νευρωνικά δίκτυα, όπου το μοντέλο μαθαίνει να διαχωρίζει μοτίβα εκτέλεσης για επιτυχείς και μη εκτελέσεις για ένα δοσμένο λογισμικό. Ένα μικρό υποσύνολο των ιχνών εκτέλεσης κατηγοριοποιούνται ως επιτυχείς ή μη και το μοντέλο έπειτα μαθαίνει από αυτά.
\paragraph{Ιεράρχηση Περιπτώσεων Ελέγχου}
Οι διάφορες περιπτώσεις ελέγχου μπορούν να εκτελεστούν με πολλούς διαφορετικούς τρόπους. Προσπαθούμε να βρούμε τη βέλτιστη σειρά εκτέλεσης έτσι ώστε να δοθεί προτεραιότητα σε αυτές τις περιπτώσεις ελέγχου οι οποίες είναι πιο πιθανό να αποκαλύψουν ατέλειες του λογισμικού, ή σε αυτές οι οποίες συσχετίζονται με μεγαλύτερο κίνδυνο ανάλογα με, φερ’ ειπείν, τη σοβαρότητα του αντικειμένου υπό έλεγχο ή την επίπτωση του κινδύνου εάν εμφανιστεί.
\par Ένα σύνολο υπάρχουσων τεχνικών συνενώνεται και λειτουργεί ως μηχανική μάθηση για την ιεράρχηση περιπτώσεων ελέγχου χρησιμοποιώντας πληροφορίες όπως κάλυψη του κώδικα, ηλικία του ελέγχου, ιστορικό αποτυχιών και ομοιότητα του κειμενικού περιεχομένου, προκειμένου να κατασκευάσει ένα μοντέλο που ιεραρχεί αποτελεσματικά περιπτώσεις ελέγχου
\par Για την Κατάταξη SVM (support-vector machines, επίσης ως και support-vector networks) χρησιμοποιούνται μετά-δεδομένα μαύρου κουτιού, όπως ιστορικό περιπτώσεων ελέγχου, αλλά και οι περιγραφές των περιπτώσεων ελέγχου σε φυσική γλώσσα, προκειμένου να ιεραρχηθούν οι περιπτώσεις χρήσης.
\paragraph{Εκτίμηση του Κόστους των Περιπτώσεων Ελέγχου}
Η εκτίμηση του κόστους είναι η διαδικασία κατά την οποία προβλέπεται η απαιτούμενη προσπάθεια για την ανάπτυξη του λογισμικού. Γενικά δε θα έπρεπε να υπάρχει έλλειμα στην εκτίμηση, και αυτή θα πρέπει να είναι διαθέσιμη το νωρίτερο δυνατό.
\par Μοντελοποιώντας το κόστος ως ένα τρισδιάστατο διάνυσμα του αριθμού των περιπτώσεων ελέγχου, της πολυπλοκότητας εκτέλεσης του ελέγχου και των ανθρώπων που ελέγχουν το λογισμικό, δημιουργείται μια βάση με προηγούμενα δεδομένα πάνω στην οποία εφαρμόζεται SVM για την εκτίμηση του κόστους για δεδομένα ιστορικά δεδομένα και διανύσματα που μοντελοποιούν το κόστος.
\par Η μηχανική μάθηση μπορεί να προβλέψει το μέγεθος του κώδικα ελέγχου, δηλαδή τη μετρική λογισμικού «γραμμές κώδικα ελέγχου», που αποτελεί σημαντικό δείκτη της προσπάθειας που θα καταβληθεί κατά τον έλεγχο. Χρησιμοποιώντας τεχνικές όπως γραμμική παλινδρόμηση, Κ-κοντινότεροι-γείτονες, αφελής ταξινομητής Bayes, τυχαίο δάσος και Perceptron πολλαπλών επιπέδων κατασκευάστηκε μοντέλο που με ακρίβεια προβλέπει αυτήν τη μετρική.
\par Επειδή η υποεκτίμηση του κόστους έχει σοβαρές συνέπειες στην ποιότητα του λογισμικού, τα μοντέλα που εκτιμούν το κόστος περιλαμβάνουν κάποια προκατάληψη προς την υπερεκτίμηση. Ακόμη, εντοπίζονται τα χαρακτηριστικά εκείνα που είναι πιο σημαντικά για την πρόβλεψη του κόστους ελέγχου λογισμικού, και συγκεκριμένα του χρόνου ελέγχου.
\begin{table}[]
\begin{tabular}{|p{0.3\textwidth}|p{0.7\textwidth}|}
\hline
\textbf{Software Testing Activity} & \textbf{AI Technique Applied} \\ \hline
Test Case Generation & Inductive Learning - Active Learning - Ant colony Optimization - Markov Model - AI Planner -GA - Tabu Search - NLP - Re-enforcement Learning C4.5 - Goal Based - Decision Tree - K-Nearest Neighbour - Logistic Regression - Random Forest - Multi-Layer Perceptron - K star - LSTM - Heuristic Search \\ \hline
Test Data Generation & GA - Simulated Annealing - Hill Climbing - Generative Model - LSTM - Deep Re-enforcement Learning - Ant Colony Optimization - Heuristic Methods \\ \hline
Test Oracle Construction & ANN - SVM - Decision Trees - AdaBoostM1 - Incremental Reduced Error Pruning (IREP) - Info Fuzzy Network \\ \hline
Test Case Prioritization & K-Means - Expectation-Maximization - c4.5 - Cob Web - Reinforcement Learning - CBR - ANN - Markov Model - K-NN - Logistic Regression - SVM Rank \\ \hline
Test Case Specification & IFN - C4.5 \\ \hline
Test Case Refinement & IFN - Classification Tree Method \\ \hline
Test Cost Estimation & SVM - linear regression - k-NN - Naïve Bayes - C4.5 - Random Forest - Multilayer Perceptron \\ \hline
\end{tabular}
\caption{Τεχνικές που εφαρμόζονται ανά τύπο δραστηριότητας ελέγχου}
\end{table}
\subsubsection{Γενετικοί Αλγόριθμοι}
Όπως και στο διαδικαστικό μοντέλο, έτσι και στο αντικειμενοστρεφές, ο έλεγχος περιπτώσεων δοκιμών μεγάλου μεγέθους θα μπορούσε να καταστήσει ανέφικτη την εκτέλεση όλων των πιθανών περιπτώσεων ελέγχου για την επαλήθευση του προγράμματος. Μια λύση σε αυτό το πρόβλημα είναι ο τυχαίος έλεγχος. Οι \textcite{ciupa} παρέχουν αποδείξεις ότι ο σχετικός αριθμός σφαλμάτων που ανιχνεύονται από τυχαίο έλεγχο με την πάροδο του χρόνου είναι προβλέψιμος και μάλιστα ότι αυτός βρίσκει σφάλματα σχετικά γρήγορα. Η πρώτη αποτυχία είναι πιθανό να προκληθεί εντός 30 δευτερολέπτων. Οι εξελικτικοί αλγόριθμοι, όπως είναι οι γενετικοί αλγόριθμοι, έχουν χρησιμοποιηθεί ευρέως για διαδικαστικούς ελέγχους λογισμικού. Σε ορισμένα μέρη, προσεγγίσεις που βασίζονται σε γενετικούς αλγορίθμους έχουν προταθεί για τη δοκιμή αντικειμενοστρεφούς λογισμικού.
\par Μια διαισθητική χρήση γενετικού προγραμματισμού είναι να κατασκευαστούν έλεγχοι οι οποίοι αποτελούνται από μια ακολουθία κλήσεων μεθόδων. Αυτό θα μπορούσε να υλοποιηθεί κωδικοποιώντας μεθόδους σαν αναγνωριστικά τα οποία ο αλγόριθμος θα αξιολογούσε χρησιμοποιώντας μία συνάρτηση καταλληλότητας (fitness function). Παρόλα αυτά αποδείχτηκε, πως η υλοποίηση αυτή παράγει τόσες πολλές άκυρες ακολουθίες κλήσεων που ο αλγόριθμος δεν είναι αποδοτικός.
\par Στο \textcite{meziane} γίνεται αναφορά στους \textcite{wappler}), οι οποίοι χρησιμοποίησαν επίσης γενετικό προγραμματισμό, όχι για τυχαιοποιημένο έλεγχο, αλλά για να παραχθούν αυτόματοι έλεγχοι με την παραγωγή και εξέλιξη δέντρων τα οποία αναπαριστούν συναρτήσεις ή μεθόδους. Η ακριβής υλοποίηση δίνεται παρακάτω:
\quotebox{
Η βασική αναπαράσταση στα περισσότερα συστήματα γενετικού προγραμματισμού είναι ένα δέντρο αντί της αριθμημένης λίστας. Γενικά, ένα δέντρο αναπαριστά μια συνάρτηση, όπου οι κόμβοι-φύλλα αναπαριστούν τα ορίσματα και οι ενδιάμεσοι κόμβοι τις συναρτήσεις. Στο πλαίσιο των ελέγχων, τα δέντρα αυτά μπορούν να αναπαραστήσουν τις εξαρτήσεις μεταξύ των κλήσεων μεθόδων, οι οποίες μπορούν στη συνέχεια να μετατραπούν σε γραμμική μορφή για την παραγωγή δοκιμών. Η χρήση της μετάλλαξης και της διασταύρωσης σε αυτά τα δέντρα μπορεί να οδηγήσει σε άκυρες συναρτήσεις και ακατάλληλα ορίσματα στο πλαίσιο της δοκιμής αντικειμενοστρεφών προγραμμάτων.
}
\quotebox{
Ως εκ τούτου, οι Wappler και Wegener(2006), προτείνουν τη χρήση ισχυρά τυποποιημένου γενετικού προγραμματισμού (Montana, 1995), όπου οι τύποι των κόμβων χρησιμοποιούνται για να διασφαλιστεί ότι εξελίσσονται μόνο δέντρα με τις κατάλληλες παραμέτρους. Αυτό εξακολουθεί να αφήνει ανοιχτό το ζήτημα του τρόπου με τον οποίο φτιάχνονται αυτά τα δέντρα εξ αρχής. Η προσέγγιση που υϊοθετούν είναι να ληφθεί πρώτα ένας γράφος εξάρτησης κλήσεων μεθόδων που έχει ακμές μεταξύ των κόμβων των κλάσεων και των κόμβων των μεθόδων. Οι ακμές καθορίζουν τις μεθόδους που μπορούν να χρησιμοποιηθούν για τη δημιουργία στιγμιοτύπων μιας κλάσης, και τα στιγμιότυπα χρειάζονται από μια συγκεκριμένη μέθοδο. Αυτός ο γράφος μπορεί στη συνέχεια να διανυθεί για τη δημιουργία δέντρων που θα αποτελούν τον αρχικό πληθυσμό. Τα απαιτούμενα ορίσματα (αντικείμενα) για τα δέντρα λαμβάνονται από μια διαδικασία δευτέρου επιπέδου που περιλαμβάνει αρχικά τη δημιουργία γραμμικών ακολουθιών κλήσης μεθόδων από τα δέντρα και στη συνέχεια χρησιμοποιεί έναν γενετικό αλγόριθμο για την εύρεση των πιο κατάλληλων δέντρων. Μόλις επιτευχθεί αυτό, τα δέντρα βελτιστοποιούνται με τη χρήση επανασυνδυασμού και μεταλλάξεων με γνώμονα ορισμένους στόχους, όπως η κάλυψη των μεθόδων.
}
\par Μια σημαντική βελτίωση στο έργο των Wappler and Wegener έφερε ο Ribeiro (2008), ο οποίος εκτέλεσε τον παραπάνω αλγόριθμο αγνοώντας μεθόδους που δεν είχαν καμία παρενέργεια (δηλαδή δεν μετέβαλλαν την εσωτερική κατάσταση του αντικειμένου). Μια δοκιμή στην \href{https://docs.oracle.com/javase/7/docs/api/java/util/Stack.html}{\linkstyle{κλάση Stack}} της Java Standard Library απέδειξε ότι αυτή η βελτίωση μείωσε το χρόνο εκτέλεσης έως την πλήρη κάλυψη κατά δύο τρίτα.
\par Οι \textcite{meziane} αναφέρουν και ακόμη μια ενδιαφέρουσα χρήση γενετικών αλγορίθμων (ΓΑ) στο πεδίο της ανάπτυξης ελέγχων:
\par Οι \textcite{briand} διερευνούν τη χρήση ΓΑ για τον προσδιορισμό της βέλτιστης σειράς για την ενσωμάτωση και τον έλεγχο κλάσεων. Ένα σημαντικό πρόβλημα κατά τον προσδιορισμό της κατάλληλης σειράς εμφανίζεται επειδή πρέπει να σπάσουν οι κύκλοι εξάρτησης των κλάσεων καθιστώντας απαραίτητη τη χρήση στελεχών (stubs). Η πολυπλοκότητα των απαιτούμενων στελεχών ποικίλλει, ανάλογα με το επίπεδο σύζευξης που υπάρχει μεταξύ των κλάσεων, συνεπώς διαφορετικές διατάξεις απαιτούν διαφορετικά επίπεδα προσπάθειας για τη δημιουργία των στελεχών.
\par Οι \textcite{briand} εκμεταλλεύονται προηγούμενες εργασίες για τον προγραμματισμό, για παράδειγμα στη χρήση ΓΑ για το πρόβλημα του πλανόδιου πωλητή, και χρησιμοποιούν μια κωδικοποίηση των κλάσεων με μεταθέσεις μαζί με μια συνάρτηση καταλληλότητας που μετρά το βαθμό σύζευξης μεταξύ των κλάσεων. Το μέτρο καταλληλότητας ορίζεται έτσι ώστε να μειώνεται ο αριθμός των χαρακτηριστικών, οι μέθοδοι που θα χρειαζόταν να αλλάξουν αν αποκοπεί μια εξάρτηση και ο αριθμός των στελεχών που δημιουργούνται. Επιπλέον, δεν επιτρέπουν την αποκοπή των εξαρτήσεων κληρονομικότητας και σύνθεσης, καθώς οδηγούν σε δαπανηρά στελέχη. Έπειτα από πειραματισμό με αυτή την προσέγγιση σε μια μελέτη περίπτωσης ΑΤΜ χρησιμοποιώντας το σύστημα ΓΑ "Evolver" (Palisade, 1998), η σύγκριση των αποτελεσμάτων με εκείνα που προέκυψαν με τη χρήση μιας προσέγγισης βασισμένης σε γράφους και προκύπτει το συμπέρασμα ότι η χρήση ΓΑ μπορεί να παρέχει μια καλύτερη προσέγγιση για την παραγωγή διατάξεων ενσωμάτωσης και δοκιμής κλάσεων.
\subsubsection{Νευρωνικά δίκτυα}
Στο \textcite{chandra} γίνεται αναφορά στο έργο των \textcite{gong}, οι οποίοι πρότειναν την χρήση Event-Driven Petri Nets (EDPN) έτσι ώστε να μοντελοποιηθούν οι μεταβολές στην εσωτερική κατάσταση και στην συμπεριφορά των αντικειμένων.
\quotebox{
Τα σφάλματα ανιχνεύονται με την ανάλυση των διαφορών των σεναρίων ελέγχου στις δυναμικές συμπεριφορές των EDPN και η μέθοδος μπορεί να επιλέξει μια περίπτωση ελέγχου που ανιχνεύει σφάλματα που περιγράφονται στα μοντέλα σφαλμάτων. Οι Ghang et al. πρότειναν μια μέθοδο που χρησιμοποιεί ελέγχους σχετικής αξιοπιστίας και πρόβλεψη της αξιοπιστίας των μονοπατιών εκτέλεσης για την προσαρμογή της κατανομής των δοκιμών αξιοπιστίας λογισμικού στον αντικειμενοστρεφή προγραμματισμό. Στην προσέγγισή τους, ο έλεγχος αξιοπιστίας λογισμικού βασίζεται στα προφίλ λειτουργίας και στην πρόβλεψη της σχετικής αξιοπιστίας των μονοπατιών λειτουργίας. Για το σκοπό αυτό χρησιμοποίησαν έναν αλγόριθμο μάθησης νευρωνικού δικτύου.
}
\par Μέχρι στιγμής το έγγραφο αυτό έχει επικεντρωθεί αποκλειστικά στην επαλήθευση του λογισμικού, εφόσον αυτό είναι το θέμα το οποίο καταναλώνει τον περισσότερο χρόνο και είναι πιο άμεσα σχετικό με το αντικειμενοστρεφές μοντέλο. Παρόλα αυτά η επικύρωση του λογισμικού, ο έλεγχος ότι η λειτουργικότητα του λογισμικού ανταποκρίνεται στις απαιτήσεις του πελάτη, είναι ένα εξίσου σημαντικό κομμάτι της διαδικασίας ανάπτυξης. Εδώ τα νευρωνικά δίκτυα μπορούν να μας βοηθήσουν αναλύοντας τις απαιτήσεις του πελάτη, οι οποίες είναι γραμμένες σε φυσική γλώσσα, και μετατρέποντάς τες σε μορφή κατάλληλη για τους σχεδιαστές και τους προγραμματιστές, αποφεύγοντας έτσι ανθρώπινα λάθη στη διαδικασία αυτή.
\par Οι \textcite{feras} περιγράφουν ένα τέτοιο σύστημα:
\quotebox{
Οι περιπτώσεις χρήσης που προέκυψαν ήταν σαφείς και συνεπείς, ανεξάρτητα από το μέγεθος του κειμένου των απαιτήσεων. Τα R-Tool, NL-OOPS, CM-BUILDER είναι μερικά ακόμη εργαλεία μηχανικής λογισμικού υποβοηθούμενης από υπολογιστή, που βασίζονται σε NLP. Τα εργαλεία αυτά παράγουν διαγράμματα κλάσεων από το έγγραφο απαιτήσεων χρήστη (αν και εξακολουθεί να απαιτεί την παρέμβαση του χρήστη).
\par Οι Michl et al. πρότειναν το NL-OOPS (Natural Language - Object-Oriented Production System) για την ανάπτυξη ενός εργαλείου που υποστηρίζει αντικειμενοστρεφή ανάλυση. Τα έγγραφα απαιτήσεων αναλύονται με το LOLITA (Large-scale Object-based Linguistic Interactor, Translator and Analyzer), ένα σύστημα επεξεργασίας φυσικής γλώσσας μεγάλης κλίμακας. Και οι γνώσεις που περιέχονται στα έγγραφα αλλά και αυτές που είναι ήδη αποθηκευμένες στη Βάση Γνώσης του LOLITA προτείνονται στη συνέχεια για χρήση για την παραγωγή μοντέλων απαιτήσεων. Η προσέγγιση ήταν βασισμένη στη θεώρηση ότι οι απαιτήσεις συχνά γράφονται σε αδόμητη φυσική γλώσσα και σε πολλές περιπτώσεις είναι αδύνατο να επιβληθούν περιορισμοί στη γλώσσα που χρησιμοποιείται για τη συγγραφή τους.
\par Η αντικειμενοστρεφής μονάδα μοντελοποίησης υλοποίησε έναν αλγόριθμο που φιλτράρει τους κόμβους οντοτήτων και συμβάντων στη βάση γνώσης του για εντοπισμό κλάσεων και συσχετίσεων. Παράλληλα, οι Ninaus et al. πρότειναν μια μέθοδο για τη μείωση του κινδύνου των απαιτήσεων χαμηλής ποιότητας μέσω της βελτίωσης της υποστήριξης των ενδιαφερόμενων μερών στην ανάπτυξη μοντέλων RE. Οι συγγραφείς εισήγαγαν το περιβάλλον INTELLIREQ, το οποίο βασίζεται σε διαφορετικές προσεγγίσεις προτάσων, οι οποίες προτάσεις υποστηρίζουν τα ενδιαφερόμενα μέρη στις δραστηριότητες που σχετίζονται με τις απαιτήσεις, όπως ο ορισμός, η διασφάλιση της ποιότητας, η επαναχρησιμοποίηση και ο τελικός σχεδιασμός.
}
\subsubsection{Δοκιμές Παλινδρόμησης}
\label{sec:Regression}
Σύμφωνα με τους \textcite{kung}, ο έλεγχος παλινδρόμησης πρέπει να αντιμετωπίσει τέσσερα θεμελιώδη προβλήματα:
\begin{itemize}
\item Πώς να προσδιορίσουμε αυτόματα τα στοιχεία εκείνα που έχουν επηρεαστεί λόγω αλλαγής ορισμένων άλλων στοιχείων;
\item Ποια στρατηγική πρέπει να χρησιμοποιηθεί για την επαναληπτική δοκιμή αυτών των επηρεασμένων στοιχείων;
\item Ποια είναι τα κριτήρια κάλυψης για τον επανέλεγχο αυτών των στοιχείων;
\item Πώς να επιλέξουμε, να επαναχρησιμοποιήσουμε και να τροποποιήσουμε τον υπάρχοντα έλεγχο (και να δημιουργηθούν νέοι);
\end{itemize}
\par Λύσεις σε αυτά τα προβλήματα για τα παραδοσιακά προγράμματα έχουν προταθεί τις τελευταίες δύο δεκαετίες. Ωστόσο, στον έλεγχο των αντικειμενοστρεφών προγραμμάτων δεν έχει δοθεί πολλή προσοχή, ενώ στην παλινδρόμηση σχεδόν καθόλου. Αυτό γίνεται για τρείς κύριους λόγους, σύμφωνα με τον συγγραφέα:
\par Πρώτον, οι παραδοσιακές προσεγγίσεις δεν αντιμετωπίζουν τις πολύπλοκες σχέσεις και εξαρτήσεις, όπως η κληρονομικότητα, η συνάθροιση και η συσχέτιση, που υπάρχουν μεταξύ των κλάσεων. Δεύτερον, οι περισσότερες παραδοσιακές προσεγγίσεις βασίζονται στο μοντέλο ροής ελέγχου, αλλά τα αντικείμενα των κλάσεων έχουν συμπεριφορά εξαρτώμενη από κατάσταση που μπορεί να αλλάξει με διάφορους τρόπους. Ως εκ τούτου, οι παραδοσιακές προσεγγίσεις δεν μπορούν να εφαρμοστούν στον έλεγχο κλάσεων. Τρίτον, οι παραδοσιακές προσεγγίσεις χρησιμοποιούν στελέχη για να προσομοιώσουν τις μονάδες που καλούνται, αλλά σε αντικειμενοστρεφή προγράμματα αυτό είναι δύσκολο και δαπανηρό, επειδή απαιτεί την κατανόηση πολλών σχετικών κλάσεων, των μεθόδων τους και του τρόπου με τον οποίο καλούνται οι μέθοδοι.
\subsubsection{Έλεγχοι Παλινδρόμησης}
Στο \textcite{divya} χρησιμοποιείται γραμμική παλινδρόμηση σε αρχεία πηγαίου κώδικα java για να παραχθεί το ελάχιστο σύνολο ελέγχων που πρέπει να εκτελεστούν ώστε να αντιμετωπιστεί η μεγάλη πλειοψηφία πιθανών σφαλμάτων.
\begin{figure}
\label{fig:regression}
\caption{Το πλάνο εκτέλεσης του προγράμματος των \textcite{divya}}
\includegraphics[width=\textwidth,height=\textheight,keepaspectratio]{regression_plan.PNG}
\end{figure}
\par Ο αλγόριθμος εξετάζει πολλές μετρικές αξιολόγησης του λογισμικού, σε μερικές από τις οποίες έχουμε ήδη αναφερθεί (σαν το LCOM) και αξιολογεί πόσο «συνεισφέρει» κάθε μονάδα στην πιθανότητα κάποιου bug. Το λογισμικό WAKA παράγει μια πρωτοβάθμια εξίσωση στην οποία κάθε μετρική είναι μια παράμετρος. Αντικαθιστώντας κάθε παράμετρο με τη μετρική του κάθε λογισμικού παράγεται ένας αριθμός που αξιολογεί την καταλληλότητα ενός ελέγχου να βρίσκει σφάλματα.
\par Τέλος, ταξινομούμε κάθε ακολουθία από ελέγχους με βάση την παραπάνω τιμή και φτιάχνουμε έναν πίνακα (Πίνακας \ref{fig:test_table}) με τους πιο αποτελεσματικούς ελέγχους. Στο παρακάτω παράδειγμα αυτές θα ήταν οι TS3, TS4, TS5, TS6, TS7, TS10.
\begin{figure}
\label{fig:test_table}
\caption{Τα αποτελέσματα του προγράμματος για κάθε ακολουθία ελέγχου}
\includegraphics[width=\textwidth,height=\textheight,keepaspectratio]{test_table.PNG}
\end{figure}
\par Οι συγγραφείς καταλήγουν στο ότι «μπορεί εύκολα να διαπιστωθεί ότι σχεδόν το 80\% των σφαλμάτων έχουν καλυφθεί στο 60\% του συνολικού χρόνου. Επομένως, συνάγεται το συμπέρασμα ότι ο αριθμός των σφαλμάτων που αποκαλύπτονται ανά μονάδα χρόνου είναι καλύτερος με την προτεινόμενη μεθοδολογία».
\par Για να εκτιμήσουμε τα πλεονεκτήματα αυτής της μεθόδου και το πώς η τεχνητή νοημοσύνη τα ενισχύει, μπορούμε να την συγκρίνουμε με μια πιο παραδοσιακή μέθοδο.
\par Οι \textcite{kung} οι οποίοι χρησιμοποιούν μαθηματικές λύσεις, κυρίως βασισμένες σε θεωρία γράφων, ώστε να κατασκευάσουν αλγορίθμους που εντοπίζουν σχέσεις εξάρτησης μεταξύ στοιχείων του προγράμματος και άρα ποιοι έλεγχοι πρέπει να μεταβληθούν. Η θεωρία και οι αλγόριθμοι που χρησιμοποιούνται καθώς και οι μέθοδοι αξιοποίησής τους διαφεύγουν της εμβέλειας αυτού του εγγράφου και άρα παραπέμπουμε τον αναγνώστη να διαβάσει την αναφορά ο ίδιος.
\par Γίνεται σαφές ότι αυτή η προσέγγιση, αν και θεωρητικά πιο αξιόπιστη, υστερεί σε δυνατότητα (και ευκολία) αυτοματοποίησης με την εναλλακτική παραπάνω λύση. Αυτός είναι πιθανώς και ο λόγος που η συγκεκριμένη έρευνα τελικά απέτυχε να παράξει πρακτικό αποτέλεσμα στο αντικειμενοστραφές πεδίο.
\subsection{Αυτοματοποίηση}
Μακράν ο πιο συνηθισμένος και συχνά πιο πρακτικός τρόπος να διευκολύνουμε την επαλήθευση αντικειμενοστρεφών προγραμμάτων παραμένει η αυτοματοποίηση των ελέγχων. Αυτή είναι απαραίτητη για τη παράδοση προϊόντος με καλή ποιότητα στον κατάλληλο χρόνο.
\par Η αυτοματοποίηση δοκιμών είναι λογισμικό που αυτοματοποιεί οποιαδήποτε πτυχή της δοκιμής ενός συστήματος εφαρμογών με δυνατότητα παραγωγής δοκιμαστικών εισόδων και αναμενόμενων αποτελεσμάτων. Μειώνει τις επαναλαμβανόμενες εργασίες που κάνουμε χειροκίνητα και επίσης μας παρέχει το αποτέλεσμα "επιτυχία" ή "αποτυχία".
\par Σύμφωνα με \textcite{claurence}, η κατάλληλη έκταση των αυτοματοποιημένων δοκιμών εξαρτάται από
\quotebox {
[...] τους στόχους των ελέγχων, τον προϋπολογισμό, τη διαδικασία λογισμικού, το είδος του υπό ανάπτυξη λογισμικού και τις ιδιαιτερότητες του περιβάλλοντος ανάπτυξης και του περιβάλλοντος στο οποίο θα τρέχει το λογισμικό τελικά. Οι αυτοματοποιημένοι έλεγχοι εξασφαλίζουν χαμηλό ποσοστό ελαττωμάτων και συνεχή πρόοδο, ενώ οι χειροκίνητοι έλεγχοι θα οδηγούσαν πολύ γρήγορα σε εξάντληση των ελεγκτών.
}
Προσθέτοντας αργότερα πως:
\quotebox {
Για να συνοψίσουμε τα χαρακτηριστικά των ελέγχων που επιδιώκουμε:
\begin{itemize}
\item Οι έλεγχοι \textit{εκτελούν} το σύστημα σε αντίθεση µε τις στατικές αναλύσεις που αναλύουν απλά τον κώδικα.
\item Οι έλεγχοι είναι αυτόματοι για να αποφευχθούν περιπτώσεις όπου τα μέλη του έργου να λόγω οκνηρίας δεν πραγματοποιούν τους ελέγχους (ή εναλλακτικά για να αποφευχθούν περιπτώσεις όπου ένα σύστημα που δεν έχει ελεγχθεί αρκετά).
\item Οι αυτοματοποιημένοι έλεγχοι δημιουργούν τα δεδομένα ελέγχου, εκτελούν τον έλεγχο και εξετάζουν το αποτέλεσμα αυτόματα.
\item Η επιτυχία ή η αποτυχία του ελέγχου παρατηρείται αυτόματα κατά τη διάρκεια της εκτέλεσης του ελέγχου.
\item Μια σουίτα ελέγχων ορίζει επίσης ένα σύστημα που εκτελείται μαζί με το δοκιμασμένο σύστημα παραγωγής. Ο σκοπός αυτού του εκτεταµένου συστήµατος είναι να εκτελεί τους ελέγχους σε αυτοµατοποιηµένη µορφή.
\item Ένας έλεγχος είναι υπόδειγμα. Ένας έλεγχος χρησιμοποιεί συγκεκριμένες τιμές για τα δεδομένα εισόδου, τα δεδομένα ελέγχου.
\item Ένας έλεγχος είναι επαναλήψιμος και καθορισμένος. Για τις ίδιες παραμέτρους παράγονται τα ίδια αποτελέσματα.
\end{itemize}
}
Το σημείο στο οποίο ξεχωρίζει όμως η αυτοματοποίηση, και ο λόγος που χρησιμοποιείται ευρύτατα (σχεδόν καθολικά) στην επαλήθευση λογισμικού είναι ότι μέσω αυτής μπορούν να χρησιμοποιηθούν όλες σχεδόν οι τεχνικές στις οποίες αναφερθήκαμε σε αυτό το έγγραφο - εφόσον αυτές δεν είναι υπολογιστικά δύσκολες. Παραδοσιακοί έλεγχοι μονάδας, έλεγχοι τυχαίων δεδομένων και έλεγχοι παλινδρόμησης μπορούν εύκολα να εκτελούνται ανά τακτά χρονικά διαστήματα, χωρίς την παρέμβαση του προγραμματιστή.
\section{Συμπέρασμα}
Η σύγχρονη περιόδος, κατα την οποία η ανάπτυξη λογισμικού καθοδειγείται από το αντικειμενοστραφές μοντέλο, έχει οδηγήσει στην αλλαγή τόσο των τεχνικών όσο και των εργαλείων που χρησιμοποιούνται για την επαλήθευσή του. Τεχνικές που βασίζονται στην παραγωγή δεδομένων ή στην μαθηματική επαλήθευση των δοκιμασιών επιλέγονται σπάνια, αντίθετα με άλλα μοντέλα ανάπτυξης όπως το συναρτησιακό, ενώ απλές τεχνικές όπως η κατασκευή ελέγχων μονάδας χρησιμοποιούνται εκτενώς με την βοήθεια εργαλείων αυτοματοποίησης. Η έρευνα στον τομέα αυτόν επίσης δείχνει προς την παραγωγή σωστών ελέγχων μέσω σωστού σχεδιασμού και αρχιτεκτονικής, αντί για την εύρεση κάποιου βέλτιστου τρόπου επαλήθευσης. Σε κάθε περίπτωση, λόγω της ραγδιαίας εξέλιξης του πεδίου, της σχετικά νεογνούσας έρευνας γύρω από αυτό και την συνεχή ανάπτυξη άλλων εργαλείων (π.χ Τεχνητής Νοημοσύνης) ενδέχεται να ανακαλυφθούν στο προσεχές μέλλον καινούριοι τρόποι και εργαλεία που οδηγούν σε πιο αποτελεσματική και εύχρηστη παραγωγή ελέγχων.
\printbibliography
\end{document}