Προγραμματισμός και Τεχνολογία Λογισμικού Programming and Software Engineering

1. Προγραμματισμός και Τεχνολογία Λογισμικού Programming and Software Engineering Αλέξανδρος Χατζηγεωργίου Τμήμα Εφαρμοσμένης Πληροφορικής Πανεπιστήμιο Μακεδονίας Τμήμα Διοίκησης Τεχνολογίας, 25Απριλίου 2007

2. Παραγωγικότητα Προγραμματιστών ... Έστω ένας τυπικός προγραμματιστής .... με μέση παραγωγικότητα productivity = average; που εργάζεται σε μια μεγάλη εταιρεία ανάπτυξης λογισμικού: Πόσες γραμμές κώδικα γράφει κατά μέσο όρο ανά ημέρα ?? (LOC/day)

3. Προγραμματισμός ... στην πράξη Εταιρεία Ανάπτυξης Λογισμικού: SuperSoftware SA(300 empl), CMM level = 1 Δευτέρα 8:00 π.μ.Boss -> Bob (programmer): "Γράψε ένα πρόγραμμα που να διαβάζει το χρώμα από το πληκτρολόγιο και να σχεδιάζει έναν κύκλο" Bob …. hmm (λιγότερο από 10 γραμμές κώδικα) Bob ….. 1 ώρα σχεδίαση, κώδικας, 1 ώρα testing, meetings, εκπαίδευση, καφές, φαγητό, τηλέφωνα κλπ κλπ (1 εβδομάδα) Bob -> Boss: "Τρεις εβδομάδες" Boss: OK !!!

4. Προγραμματισμός ... στην πράξη Αρχικό Σχέδιο σε 5 λεπτά(3 μονάδες λογισμικού)

5. Προγραμματισμός ... στην πράξη Παρασκευή 10:00 πμ:Μετά από πολλαπλά meetings, σεμινάρια, compiling, debugging, ανάκτηση της βάσης δεδομένων, επικοινωνία με πελάτες ....., ολοκλήρωση του εγχειριδίου χρήσης. Εύσημα από τον Boss διάδοση της φήμης του Bob ως εξαιρετικού προγραμματιστή σε όλη την εταιρεία !!!

6. Προγραμματισμός ... στην πράξη Τρεις μήνες μετά…: Boss: "Οι απαιτήσεις τροποποιήθηκαν, το πρόγραμμα θέλουμε να σχεδιάζει και τετράγωνα. Bob: Διαμαρτύρεται γιατί άλλαξαν οι απαιτήσεις, και προειδοποιεί τον Boss ότι θα χαλάσει όλη η καλή σχεδίαση που έκανε Ποιά θα ήταν η ιδανική τροποποίηση του προγράμματος ?? Bob: …… θα προσθέσω μία boolean παράμετρο στη μονάδα DrawColoredShape. true: Σχεδίαση Κύκλου, false: σχεδίαση τετραγώνου.

7. ProgramM ProgramN Προγραμματισμός ... στην πράξη Program1 DrawColoredShape Program2 Bob: …..hmmm, το interface δεν μπορεί να αλλάξει Bob:…..Aha, θα προσθέσω μία καθολική (global) μεταβλητή !!!

8. Προγραμματισμός ... στην πράξη // remember to reset the flag αν κάποιος θέλει να σχεδιάσει τετράγωνα πρέπει να θέσει την τιμή false για να μην σχεδιάζουν όλοι οι επόμενοι τετράγωνα πρέπει να επαναφέρει την τιμή true γι’ αυτό ο Bob είναι ευτυχής που θυμήθηκε να βάλει σχόλιο !!!

9. Προγραμματισμός ... στην πράξη Μερικές εβδομάδες μετά:o Boss (που παραμένει boss παρόλο που έγιναν ανακατατάξεις στην εταιρεία), λέει ότι ορισμένοι πελάτες "Θέλουν να μπορούν να διαβάζουν το χρώμα και από οθόνη αφής" Bob: …. Πελάτες !!! αυτοί πάντοτε καταστρέφουν τα σχέδια μου. Ο προγραμματισμός θα ήταν πολύ ευκολότερος αν δεν υπήρχαν πελάτες Anyway….Λύση με ακόμη μία καθολική μεταβλητή !!!

10. Προγραμματισμός ... στην πράξη // remember to reset the flags η αξία του Bob φαίνεται από το γεγονός ότι θυμήθηκε να τροποποιήσει το σχόλιο !!!

11. Προγραμματισμός ... στην πράξη • Η έλευση και δύο μόνο απαιτήσεων υποβάθμισε την ποιότητα. (Ο Bob αρχίζει να ξεσκονίζει το βιογραφικό του !!) • Δίδαγμα:Οι απαιτήσεις πάντοτε αλλάζουν ! • Ο σχεδιαστής – προγραμματιστής λογισμικού πρέπει να αναγνωρίζει ότι οι απαιτήσεις πρόκειται να αλλάξουν και να εξασφαλίζει ότι το λογισμικό θα μπορέσει να "επιβιώσει" όταν οι απαιτήσεις αλλάξουν.

12. Προγραμματισμός ... στην πράξη • Το γεγονός ότι ζητήθηκε αλλαγή του σχήματος υποδηλώνει έναν “άξονα αλλαγών”(axis of change) • Επομένως, το σχέδιο πρέπει να γίνει ανθεκτικό σε αλλαγές ιδίου τύπου • Το καλύτερο σχέδιο θα πρέπει να συμμορφώνεται με την Αρχή της Ανοικτής-Κλειστής Σχεδίασης(Open-Closed Principle) • Μια καλή ομάδα ανάπτυξης δεν κάνει προσπάθεια πρόβλεψης των αλλαγών: “Θεραπεία μετά τη διάγνωση” • Τέτοια προβλήματα καλείται να αντιμετωπίσει ...... η

13. Τεχνολογία Λογισμικού Software Engineering

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

15. Τεχνολογία Λογισμικού ...είπαν Software Engineering is: David Parnas: "the multi-person construction of multi-version software" Ghezzi: "the application of engineering to software" IEEE: "the application of a systematic, disciplined, quantifiable approach to the development, operation and maintenance of software" Roberts: "the discipline of writing programs that can be understood and maintained by others" in contrast to: "Programming is the discipline of writing programs that cannot be understood and maintained by anyone else than the author"

16. Έργα Λογισμικού • μικρής κλίμακας Μείζον πρόβλημα: • η κατάστρωση αλγορίθμων • η μετατροπή αλγορίθμων σε κώδικα • μεγάλης κλίμακας • (Multi-person, multi-version projects) •  Μείζον πρόβλημα: • ηεπικοινωνίαμεταξύ των υπομονάδων του έργου • η συντήρηση του λογισμικού

17. Τεχνολογία Λογισμικού • Software Crisis (μέσα 1960 ... σήμερα ?) Software Hall of Shame Συντηρητική Εκτίμηση: Στις ΗΠΑ, απώλειες 60 – 70 δις δολ / έτος

18. 1962, Mariner1(NASA), ΗΠΑ • καταστροφή πυραύλου αξίας $12M • O αλγόριθμος ιχνηλάτισης βασίζεται στη μέση ταχύτητα • απαιτήσειςR (εσφαλμένο) • (ορθό) .. άλλες διάσημες αποτυχίες • 1961, Mercury(NASA), ΗΠΑ • ανεπαρκής ακρίβεια στον υπολογισμό τροχιάς • FORTRAN DO 10 I=1.10 (εσφαλμένο) • DO 10 I=1,10 (ορθό)

19. .. άλλες διάσημες αποτυχίες • 1996, Ariane 5(European Space Agency) • καταστροφή πυραύλου αξίας $370M • Γλώσσα: Ada • Μετατροπή ενός 64-bit floating-point αριθμού σε 16-bit προσημασμένο ακέραιο -> υπερχείλιση -> έλλειψη χειρισμού εξαίρεσης • 1985-1986, Therac(AECL), Καναδάς • σύστημα ελέγχου ακτινοβολίας ασθενών • Γλώσσα: Assembly • Θάνατος ασθενών από υπερβολική δόση ακτινοβολίας !!

20. Ιδιαιτερότητες Έργων Λογισμικού Διαφέρουν τα έργα λογισμικού από τα άλλα τεχνικά έργα ? Test 1:Έστω ότι ένα έργο λογισμικού έχει καθυστερήσει σε σχέση με το χρονοδιάγραμμα του. Αν είσαστε ο project manager με τι τρόπους μπορείτε να το επιταχύνετε ? Αν απαντήσατε με αύξηση των ατόμων ή με χρήση νέων εργαλείων ….. wrong answer ! (Mythical Man-Month) Test 2: Έστω ότι είστε ο project manager σε ένα έργο λογισμικού (μη έχοντας σχέση με προγραμματισμό). Πώς θα παρακολουθήσετε την πορεία του ? Προφανώς εξαρτάστε από τις αναφορές των υπολοίπων !! Test 3: Πουλάτε ένα προϊόν λογισμικού και σας ρωτούν να προσδιορίσετε την ποιότητα του. Τι θα αναφέρατε ? Προφανώς δεν υπάρχουν σαφή χαρακτηριστικά ποιότητας !!!

21. Κύκλος Ζωής Λογισμικού Έλεγχος Εφικτότητας Μοντέλο Καταρράκτη Καθορισμός απαιτήσεων Σχεδίαση λογισμικού Υλοποίηση και έλεγχος τμημάτων Ολοκλήρωση και Επαλήθευση συστήματος Λειτουργία και Συντήρηση

22. Κώδικας (Code) Τεκμηρίωση (Documentation) Προϊόντα Λογισμικού Προϊόν Λογισμικού (Software Product)

23. Προϊόντα Λογισμικού ERICSSON UNIVERSITIES Docs Code

24. Κόστος Λογισμικού Σε τι συνίσταται το κόστος λογισμικού ? (Τι πληρώνουμε) Μισθούς προγραμματιστών ως επί το πλείστον !! Η εκτίμηση του κόστους που απαιτείται για την ανάπτυξη λογισμικού πολύ δύσκολη: 50% υπό-εκτίμησηαπό managers (κόστος, χρονοδιάγραμμα, πόροι)

25. Κατανομή Κόστους Τυπικού Έργου Λογισμικού Συντήρηση Υλοποίηση - Επαλήθευση Σχεδίαση Προδιαγραφές

26. Τι είναι η Συντήρηση Λογισμικού ? • Το λογισμικό δεν “φθείρεται” !! • Η συντήρηση συνίσταται στις ενέργειες που είναι απαραίτητες λόγω της εξέλιξης του λογισμικού: • διορθωτική συντήρηση (corrective maintenance) • προσαρμοστική συντήρηση (adaptive maintenance) • βελτιωτική συντήρηση (perfective maintenance)

27. Ο Προγραμματισμός ως δραστηριότητα στα πλαίσια της Τεχνολογίας Λογισμικού

28. Σχεδίαση λογισμικού Υλοποίηση Σχεδίαση / Προγραμματισμός • Η υλοποίηση ενός έργου λογισμικού (προγραμματισμός) καθορίζεται άμεσα από τη σχεδίαση του συστήματος

29. Σύστημα Σχεδίαση • Σχεδίαση (οποιουδήποτε τεχνικού έργου) είναι: • Η αποσύνθεση ενός συστήματος σε τμήματα (μονάδες)

30. Σύστημα Σχεδίαση • Σχεδίαση (οποιουδήποτε τεχνικού έργου) είναι: • Η αποσύνθεση ενός συστήματος σε τμήματα (μονάδες) • Ο καθορισμός των σχέσεων μεταξύ των τμημάτων

31. Functionality A Functionality B Σύστημα Σχεδίαση • Σχεδίαση (οποιουδήποτε τεχνικού έργου) είναι: • Η αποσύνθεση ενός συστήματος σε τμήματα (μονάδες) • Ο καθορισμός των σχέσεων μεταξύ των τμημάτων • Η ανάθεση αρμοδιοτήτων σε κάθε τμήμα

32. Functionality A Requirements Functionality B Σύστημα Σχεδίαση • Σχεδίαση (οποιουδήποτε τεχνικού έργου) είναι: • Η αποσύνθεση ενός συστήματος σε τμήματα (μονάδες) • Ο καθορισμός των σχέσεων μεταξύ των τμημάτων • Η ανάθεση αρμοδιοτήτων σε κάθε σχήμα • Η επικύρωση ότι όλα τα τμήματα μαζί επιτυγχάνουν τους σκοπούς του συστήματος

33. Ποιότητα Σχεδίασης • Μια σχεδίαση μπορεί να είναι “καλή” ή “κακή” • Είναι εύκολο να εντοπίσει κανείς τα συμπτώματα μιας κακής σχεδίασης • Είναι εξαιρετικά δύσκολο να καθορίσει κανείς ένα σαφές, πεπερασμένο και αποτελεσματικό σύνολο βημάτων για την επίτευξη καλής σχεδίασης • Μετά το πέρας της σχεδίασης η ποιότητα αξιολογείται συνήθως από τους “γκουρού” της ομάδας ! • Πλέον εμφανές επακόλουθο "κακής" σχεδίασης: Δυσκολία συντήρησης

34. Ποιότητα Σχεδίασης • Συμπτώματα "κακής" σχεδίασης: • Δυσκαμψία (Rigidity):Το σύστημα είναι δύσκολο να τροποποιηθεί διότι κάθε αλλαγή οδηγεί σε πληθώρα αλλαγών σε άλλα τμήματα του συστήματος • Ευθραυστότητα (Fragility):Οι αλλαγές που πραγματοποιούνται στο λογισμικό προκαλούν σφάλματα σε διάφορα σημεία. • Ακινησία (Immobility):Υπάρχει δυσκολία διαχωρισμού του συστήματος σε συστατικά τα οποία μπορούν να επαναχρησιμοποιηθούν σε άλλες εφαρμογές. • Έλλειψη ρευστότητας (Viscosity):Η πραγματοποίηση τροποποιήσεων με λάθος τρόπο είναι ευκολότερη από την πραγματοποίησή τους με τον ορθό τρόπο. • Περιττή Πολυπλοκότητα (Needless Complexity):Το λογισμικό περιλαμβάνει στοιχεία που δεν είναι (ούτε πρόκειται να γίνουν) χρήσιμα. • Περιττή Επανάληψη (Needless Repetition):Η σχεδίαση περιλαμβάνει επαναλαμβανόμενες δομές που θα μπορούσαν να ενοποιηθούν υπό μία κοινή αφαίρεση. • Αδιαφάνεια (Opacity): Δυσκολία κατανόησης μιας μονάδας (σε επίπεδο σχεδίου ή κώδικα).

35. Ποιότητα Σχεδίασης • Τα δύο κυριότερα χαρακτηριστικά ενός σχεδίου λογισμικού είναι: • σύζευξη(coupling):μέτρο του κατά πόσο οι μονάδες αλληλο-εξαρτώνται μεταξύ τους • συνεκτικότητα (cohesion): μέτρο της εσωτερικής συνοχής μιας μονάδας

36. Σύζευξη Παράδειγμα σύζευξης μεταξύ δύο μονάδων void functionA() { int x; . . . x = functionB(); . . . } int functionB() { int z; z = . . .; return z; } functionA functionB

37. Σύζευξη Στόχος Σχεδίασης: Ελαχιστοποίηση της σύζευξης • Αν τροποποιηθεί η μονάδα Χρονόμετρο απαιτείται (τουλάχιστον) ο έλεγχος και (ενδεχομένως) η μεταγλώττιση των συσχετιζόμενων μονάδων • Για να επαναχρησιμοποιηθεί η μονάδα Χρονόμετρο απαιτείται “μεταφορά” των συσχετιζόμενων μονάδων

38. Τύποι σύζευξης Υψηλή Σύζευξη Περιεχόμενη Σύζευξη Σύζευξη από κοινού Χαλαρή Σύζευξη Σύζευξη ελέγχου Σύζευξη αντιγράφου Σύζευξη Δεδομένων Μή Σύζευξη

39. Τύποι σύζευξης Περιεχόμενη Σύζευξη: Μία μονάδα επεμβαίνει και τροποποιεί μία άλλη Μονάδα Η Μονάδα G GOTO G1 G1 : Η μονάδα G είναι δυνατόν να τροποποιήσει τον κώδικα της μονάδας H (μόνο σε assembly, Basic, Cobol)

40. Τύποι σύζευξης Μονάδα Η Μονάδα G Μπορούμε να μειώσουμε τη σύζευξη τοποθετώντας δεδομένα σε κοινή περιοχή (π.χ. καθολικές μεταβλητές) Η εξάρτηση συνεχίζει να υπάρχει(από κοινού σύζευξη),αφού αλλαγές στις καθολικές μεταβλητές επηρεάζουν όλες τις μονάδες που έχουν πρόσβαση σε αυτές global variables

41. Τύποι σύζευξης Σύζευξη ελέγχουέχουμε όταν μία μονάδα περνά flags για να ελέγξει τη δραστηριότητα μιας άλλης μονάδας (Π.χ. μία μονάδα ξεκινά τη λειτουργία της όταν μία άλλη ολοκληρωθεί και η τιμή ενός flag τεθεί σε κατάλληλη τιμή) Συνήθως πρόκειται για μεταβλητές που εμπλέκονται σε παραστάσεις δομών ελέγχου (conditional statements) Σύζευξη αντιγράφου: Πέρασμα δομών δεδομένων Εάν μεταξύ των μονάδων ανταλλάσσονται δεδομένα έχουμεσύζευξη δεδομένων. Στην περίπτωση αυτή, μία μονάδα μπορεί να τροποποιήσει τα ίδια τα δεδομένα μιας άλλης μονάδος (κλήση κατ’ αναφορά) ή να δράσει επάνω σε αντίγραφα των δεδομένων μιας άλλης μονάδος (κλήση κατ’ αξία)

42. Συνεκτικότητα Παράδειγμα χαμηλής συνεκτικότητας σε μονάδα ATM void ΑΤΜ() { εντολές επικοινωνίας με το χρήστη εντολές κρυπτογράφησης δεδομένων εντολές επικύρωσης ταυτότητας χρήστη εντολές επικοινωνίας με την τράπεζα εντολές εκτύπωσης απόδειξης } Στόχος Σχεδίασης: Μεγιστοποίηση της συνεκτικότητας

43. Τύποι Συνεκτικότητας Λειτουργία Α Λειτουργία Β Λειτουργία C Λειτουργία D ΜΟΝΑΔΑ Α Συμπτωματική συνεκτικότητα (Μέρη ασυσχέτιστα)

44. Τύποι Συνεκτικότητας Χρόνος Τ0 ΜΟΝΑΔΑ Α Χρονική συνεκτικότητα (Συσχέτιση μέσω χρόνου) Χρόνος Τ0+Δ Χρόνος Τ0+2Δ

45. Τύποι Συνεκτικότητας Λειτουργία Α ΜΟΝΑΔΑ Α Επικοινωνιακή συνεκτικότητα (Προσπέλαση στα ίδια δεδομένα) Λειτουργία Β Λειτουργία C

46. Τύποι Συνεκτικότητας Λειτουργία Α ΜΟΝΑΔΑ Α Ακολουθιακή συνεκτικότητα (Έξοδος ενός είσοδος σε άλλο) OUT IN Λειτουργία Β OUT IN Λειτουργία C

47. Τύποι Συνεκτικότητας ΜΟΝΑΔΑ Α = ΛΕΙΤΟΥΡΓΙΑ Α Λειτουργική συνεκτικότητα (Πλήρη και συσχετισμένα τμήματα που εκτελούν τμήματα της ίδια λειτουργίας) Λειτουργία Α, τμήμα 1 Λειτουργία Α, τμήμα 2 Λειτουργία Α, τμήμα 3

48. Fan-in, Fan-out A B C D E F G H I Fan-out: 4 Fan-in: 1 Fan-out: 3 Fan-in: 2 Fan-out: 0

49. Fan-in, Fan-out Στόχος 1: Ελαχιστοποίηση αριθμού μονάδων με υψηλό fan-out Μία μονάδα που ελέγχει πολλές άλλες, συνήθως εκτελεί πολλές εργασίες (κακή συνεκτικότητα). Δυσκολία στον εντοπισμό σφαλμάτων, στην τροποποίηση, στην επαναχρησιμοποίηση Στόχος 2: Μεγιστοποίηση αριθμού μονάδων με υψηλό fan-in Μία μονάδα που ελέγχεται από πολλές άλλες, είναι μονάδα γενικής χρησιμότητας και είναι σαφώς προτιμότερο μία λειτουργία που εκτελείται συχνά να βρίσκεται σε μία μονάδα, παρά κατανεμημένη ή υλοποιημένη σε πολλές μονάδες

50. Γενικές Συμβουλές (Fairley 1985) • Χρήση περιορισμένων γλωσσικών δομικών στοιχείων ροής ελέγχου (Βοhm & Jacopini) • Συνετή χρήση της εντολής GOTO • Ορισμός καινούριων τύπων δεδομένων για την ευχερέστερη διάκριση οντοτήτων (OOP principle) • Απόκρυψη δομών δεδομένων πίσω από διαδικασίες πρόσβασης (information hiding principle) • Απομόνωση των τμημάτων του κώδικα που εξαρτώνται από το μηχάνημα σε ξεχωριστές (λίγες) συναρτήσεις • Χρήση τυποποιημένων περιγραφικών προλόγων στην αρχή κάθε υποπρογράμματος