Ο Σκοπός της Τεχνολογίας Λογισμικού Δρ. Μαρία Ι. Ανδρέου

Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 2 Περιεχόμενα Ιστορικά στοιχεία Οικονομικές πτυχές Συντήρηση Πτυχές απαιτήσεων, ανάλυσης και σχεδιασμού Πτυχές αναφορικά με Ομαδική Εργασία Γιατί δεν υπάρχει φάση  Σχεδιασμού (planning)  Ελέγχου (testing)  Τεκμηρίωσης (documentation) Το αντικειμενοστρεφές (object oriented) παράδειγμα Ορολογία (terminology) Θέματα Ηθικής

Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 3 Ιστορικά Στοιχεία 1968 NATO Software Engineering conference, Garmisch, Γερμανία  Στόχος: Να λύσει την κρίση στο λογισμικό (software crisis) η οποία περιλαμβάνει ανάμεσα σε άλλα την παράδοση του Λογισμικού: Με καθυστέρηση Υπερ-εκτιμημένο Με λάθη

Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 4 Standish Group Data Δεδομένα σε έργα (projects) που ολοκληρώθηκαν το % Ολοκληρώθηκαν με καθυστέρηση, με υπέρβαση κόστους, και με παράληψη κάποιων μερών 23% Ακυρώθηκαν 28% Επιτυχής

Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 5 Cutter Consortium Data 2002: έρευνα σε information technology οργανισμούς  78% έχουν εμπλακεί σε διαμάχες που κατέληξαν σε δίκη  Από τους οργανισμούς που πήγαν σε δίκη σε 67% από τις διαμάχες, η λειτουργικότητα των πληροφοριακών συστημάτων που παραδόθηκαν δεν ικανοποιούσαν τις αξιώσεις των κατασκευαστών Σε 56% από τις διαμάχες, η ημερομηνία παράδοσης που καθορίσθηκε μετατέθηκε πολλαπλές φορές. Σε 45% από τις διαμάχες, το ελάττωμα ήταν τόσο σοβαρό που τον πληροφοριακό σύστημα που παραδόθηκε ΔΕΝ ήταν χρήσιμο.

Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 6 Συμπεράσματα για την Κρίση του Λογισμικού Η κρίση του Λογισμικού ΔΕΝ έχει ξεπεραστεί. Ίσως ο όρος Ύφεση Λογισμικού (software depression) να την αντιπροσωπεύει καλύτερα  Μεγαλύτερη διάρκεια  Μη ασφαλής προγνώσεις

Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 7 Οικονομικές Πτυχές Έστω ότι, οι νέες μέθοδοι κωδικοποίησης (coding method), CM new, είναι 10 φορές πιο γρήγορες από αυτές που χρησιμοποιούνται ήδη, CM old.  Μήπως θα έπρεπε να χρησιμοποιηθούν αυτές;  Η κοινή λογική θα έδινε την απάντηση: Φυσικά  Η απάντηση στην τεχνολογία λογισμικού είναι: Εξαρτάται από το κόστος εκπαίδευσης (training) Εξαρτάται από τις επιδράσεις της εισαγωγής της νέας τεχνολογίας Εξαρτάται από το πως επηρεάζουν οι CM new την συντήρηση

Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 8 Πτυχές Συντήρησης Το μοντέλο του κύκλου ζωής (Life-cycle model)  Τα βήματα (φάσεις) που ακολουθούμε όταν δημιουργούμε λογισμικό  Μια θεωρητική περιγραφή του τι πρέπει να γίνει Κύκλος ζωής  Τα πραγματικά βήματα που εκτελούνται σε ένα συγκεκριμένο προϊόν

Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 9 Waterfall Life-Cycle model Το κλασικό μοντέλο (Classical model) Η φάση των Απαιτήσεων (requirements phase) 2. Η φάση της Ανάλυσης (analysis, specification phase) 3. Η φάση του σχεδιασμού (design phase) 4. Η φάση της υλοποίησης (implementation phase) 5. Συντήρηση μετά την παράδοση (postdelivery maintenance) 6. Αποχώρησης (retirement)

Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 10 Οι τυπικές Κλασικές Φάσεις Requirements phase  Διερεύνηση της βασικής ιδέας  Εκμαίευση των απαιτήσεων του χρήστη Analysis (specification) phase  Ανάλυση των απαιτήσεων του χρήστη  Σύνταξη του εγγράφου προδιαγραφών (specification document)  Σύνταξη του σχεδίου διαχείρισης του έργου λογισμικού (software project management plan)  «τι υποτίθεται ότι θα κάνει το προϊόν»

Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 11 Οι τυπικές Κλασικές Φάσεις συνέχ. Design phase  Αρχιτεκτονικό σχέδιο  Λεπτομερής σχεδιασμός  «Πως το προϊόν επιτυγχάνει το στόχο του» Implementation phase  Κωδικοποίηση (coding)  Έλεγχος μονάδων (unit testing)  Ενσωμάτωση (integration)  Έλεγχος αποδοχής (acceptance testing)

Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 12 Οι τυπικές Κλασικές Φάσεις συνέχ. Postdelivery maintenance  Συντήρηση διόρθωσης (corrective maintenance)  Τελειοποίηση συντήρησης (perfective maintenance)  Συντήρηση προσαρμογής (adaptive maintenance) Retirement

Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 13 Κλασικές και Μοντέρνες μορφές Συντήρησης Κλασική συντήρηση  Μοντέλο Ανάπτυξη-και μετά-Συντήρηση Αυτός είναι ένας χρονικός ορισμός (βασισμένος στο χρόνο)  Η ταξινόμηση στην ανάπτυξη ή στη συντήρηση εξαρτάται από το πότε γίνεται μια δραστηριότητα

Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 14 Παραδείγματα με βάση τον Κλασικό Ορισμό Συντήρησης Έστω ότι, ένα λάθος ανακαλύπτεται και διορθώνεται μια μέρα μετά που το προϊόν λογισμικού έχει εγκατασταθεί.  Classical maintenance Έστω ότι το ίδιο λάθος εντοπίζεται και διορθώνεται μια μέρα πριν την εγκατάσταση  Classical development

Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 15 Παραδείγματα με βάση τον Κλασικό Ορ. Συντήρισης συνεχ Έστω ότι ένα προϊόν λογισμικού έχει εγκατασταθεί  Και ο πελάτης θέλει να εμπλουτίσει τη λειτουργικότητα του Classical (perfective) maintenance Αν ο πελάτης ζητήσει αυτή την αλλαγή πριν την εγκατάσταση του προϊόντος  Classical development

Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 16 Θέματα σχετικά με Classical maintenance Ο λόγος για τον οποίο στα πιο πάνω παραδείγματα μια δραστηριότητα κάποιες φορές παρουσιάζεται σαν μέρος την φάσης Classical development και κάποιες άλλες σαν μέρος της φάσης Classical maintenance είναι  Το γεγονός ότι ορίσαμε σαν συντήρηση (maintenance) τις δραστηριότητες που γίνονται μετά την εγκατάσταση του προϊόντος. Δηλ. Με βάση το χρόνο Πως θα χαρακτηρίζαμε (σε ποια φάση θα κατατάσσαμε) δραστηριότητες που γίνονται για επέκταση ήδη υπαρχόντων λογισμικών  Ανάπτυξη μεγάλων λογισμικών προϊόντων ξεκινώντας από το μηδέν είναι σχεδόν σπάνια περίπτωση στις μέρες μας.  Η Επαναχρησιμοποίηση είναι αρκετά διαδεδομένη.

Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 17 Ορισμός Modern Maintenance Το 1995, the international standards organization and international electrotechnical commission όρισαν τη συντήρηση (maintenance) λειτουργικά (operationally). Modern Maintenance Definition  Η διαδικασία η οποία λαμβάνει χώρα όταν ένα μέρος του λογισμικού τροποποιείται εξαιτίας κάποιου προβλήματος ή λόγο ανάγκης βελτίωσης ή προσαρμογής. Με όρους του ορισμού του ISO/IEC  Maintenance συμβαίνει όποτε το λογισμικό τροποποιείται  Ανεξάρτητα από το πότε έγινε χρονικά η τροποποίηση (πριν ή μετά την εγκατάσταση του λογισμικού) Ο ορισμός του ISO/IEC έχει υιοθετηθεί και από την ΙΕΕΕ και ΕΙΑ

Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 18 Ο όρος maintenance τι θα σημαίνει τελικά για μας Postdelivery maintenance  Αφορά αλλαγές στο λογισμικό μετά την παράδοση και την εγκατάσταση του [ΙΕΕΕ 1990] Modern maintenance (ή απλά maintenance)  Maintenance για: Διόρθωση, τελειοποίηση ή προσαρμογή που διενεργείται οποιαδήποτε ώρα [ISO/IEC 1995, IEEE/EIA 1998]

Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 19 Η σημαντικότητα του Postdelivery Maintenance Κακό λογισμικό αχρηστεύεται Καλό λογισμικό διατηρείται για 10, 20 χρόνια ή και περισσότερα Το λογισμικό είναι ένα μοντέλο της πραγματικότητας η οποία αλλάζει σταθερά

Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 20 Ποσοστό του χρόνου (=κόστους) για Postdelivery maintenace (a) μεταξύ (β) μεταξύ Development 33% Postdelivery Maintenance 67% Development 25% Postdelivery Maintenance 75% a b

Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 21 Το κόστος στις Κλασικές Φάσεις Διάφορα Projects πιο πρόσφατα Hewlett-Packard projects Requirements and analysis phase 21%18% Design phase18%19% Implementation phase Κοδικοποίηση (και έλεγχο) Ενσωμάτωση 36% 24% 34% 29%

Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 22 Συνέπειες από τα σχετικά κόστα των φάσεων Αποτέλεσμα του CT old και CT new Μειώνοντας το κόστος κωδικοποίησης κατά 10% έχουμε το πολύ 0.85% μείωση του συνολικού κόστους  Λαμβάνοντας υπόψη τα έξοδα και την διάσπαση που θα προκύψει Μειώνοντας το κόστος Postdelivery maintenance κατά 10% έχουμε 7.5% μείωση του συνολικού κόστους

Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 23 Πτυχές από τις φάσεις: Requirements, Analysis and Design Για να διορθωθεί νωρίς ένα λάθος στον life cycle  Συχνά χρειάζεται να αλλαχθεί μόνο ένα κείμενο Για να διορθωθεί αργά ένα λάθος στον life cycle  χρειάζεται να αλλαχθεί ο κώδικας και η τεκμηρίωση  Πρέπει να ελεγχθεί η αλλαγή από μόνη της  Έλεγχος ξανά του όλου συστήματος  Επανεγκατάταση του προϊόντος στους υπολογιστές των πελατών

Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 24

Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 25

Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 26 Πτυχές από τις φάσεις:Requirements,Analysis,Design συνεχ Ανάμεσα σε 60% και 70% όλων των λαθών σε μεγάλων διαστάσεων προϊόντα είναι στις φάσεις requirements, analysis και design Παράδειγμα:  1.9 λάθη σε κάθε σελίδα των προδιαγραφών (specifications)  0.9 σε κάθε σελίδα του σχεδιασμού (design)  0.3 σε κάθε σελίδα στην κωδικοποίηση (coding)

Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 27 Συμπεράσματα Είναι αναγκαίο να βελτιωθούν οι τεχνικές των requirements, analysis και design  Για να μπορούμε να εντοπίζουμε τα λάθη όσο πιο νωρίς γίνεται.  Για να μειώσουμε το συνολικό αριθμό λαθών Συνεπώς ολόκληρου του κόστους

Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 28 Πτυχές από τον Προγραμματισμό σε Ομάδα Το hardware είναι φθηνό  Μπορούμε να δημιουργήσουμε προϊόντα που είναι πολύ μεγάλα για να γραφτούν από ένα άνθρωπο Το λογισμικό δημιουργείται από ομάδες  Προβλήματα αλληλεπίδρασης ανάμεσα σε τμήματα  Προβλήματα επικοινωνίας ανάμεσα στα μέλη της ομάδας

Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 29 Γιατί δεν υπάρχει Planning Phase; Δεν μπορούμε να κάνουμε πλάνο στην αρχή του project  Δεν ξέρουμε ακόμα τι ακριβώς είναι αυτό που θα κατασκευαστεί

Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 30 Ενέργειες για τη δημιουργία πλάνου στο Κλασικό Παράδειγμα Στην αρχή του project γίνεται προκαταρτικό πλάνο για τις φάσεις requirements και analysis Το πλάνο για την διαχείριση του software project (software project management plan SPMP) συντάσσεται όταν ο πελάτης υπογράψει τις προδιαγραφές. Ο διευθυντής πρέπει να παρακολουθεί το SPMP καθόλη τη διάρκεια του έργου

Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 31 Συμπεράσματα Ενέργειες για το πλάνο γίνονται καθόλη τη διάρκεια του life cycle Δεν υπάρχει ξεχωριστή φάση για planning

Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 32 Γιατί δεν υπάρχει ξεχωριστή φάση για έλεγχο; Είναι πολύ αργά να ελέγξουμε το προϊόν μετά την ανάπτυξη του και πριν την παράδοση του

Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 33 Ενέργειες για έλεγχο στο κλασικό παράδειγμα Επαλύθεση (verification)  Έλεγχος στο τέλος κάθε φάσης Εγκυρότητα  Έλεγχος στο τέλος του project

Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 34 Συμπεράσματα Συνεχής ενέργειες ελέγχου πρέπει να γίνονται καθόλη την διάρκεια του life cycle Αυτός ο έλεγχος είναι ευθύνη  Κάθε επαγγελματία προγραμματιστή  Της ομάδας βεβαίωσης για την ποιότητα του λογισμικού (software quality assurance) Δεν υπάρχει ξεχωριστή φάση ελέγχου

Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 35 Γιατί δεν υπάρχει ξεχωριστή φάση για τεκμηρίωση Είναι πολύ αργά να γράψουμε την τεκμηρίωση του προϊόντος μετά την ανάπτυξη του και πριν την παράδοση του

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

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

Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 38 Το Αντικειμενοστρεφές (Object-Oriented ) Παράδειγμα Το δομημένο (structured) παράδειγμα ήταν επιτυχής στην αρχή. Σε μεγάλα προϊόντα (> 50,000 LOC) όμως,  Η φάση του Postdelivery maintenance δυσκόλεψε (σήμερα είναι το 70% – 80% του συνολικού έργου) Λόγοι: Οι δομημένες μέθοδοι είναι  Οριοθετούμενες με βάση τις δράσεις (actions) (π.χ., μηχανές πεπερασμένων καταστάσεων, διαγράμματα ροής δεδομένων), ή  Οριοθετούμενες με βάση τα δεδομένα (data) (π.χ., διάγραμμα σχέσεων οντοτήτων, Jackson’s μέθοδος);  Άλλα όχι και τα δυο

Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 39 Το Object-Oriented Παράδειγμα (συνέχ.) Από κοινού τα δεδομένα και οι δράσεις έχουν την ίδια σημαντικότητα Αντικείμενο (object):  Ένα λογισμικό μέρος/κομμάτι (component) που περιλαμβάνει από κοινού δεδομένα και δράσεις που εκτελούνται πάνω σε αυτά τα δεδομένα. Παράδειγμα:  Τραπεζικός Λογαριασμός Δεδομένα:υπόλοιπο λογαριασμού Δράσεις: κατάθεση, ανάληψη, καθορισμός υπολοίπου.

Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 40 Structured έναντι Object-Oriented Παραδείγματος Απόκρυψη Πληροφοριών (information hitting) Design καθοδηγούμενο από τις ευθύνες (responsibilities) Επίπτωση on maintenance, development Figure 1.7

Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 41 Απόκρυψη Πληροφοριών - Information Hiding Στην object-oriented version  Η συνεχόμενη γραμμή γύρο από το accountBalance δηλώνει ότι έξω από το αντικείμενο δεν υπάρχει γνώση για το ΠΩΣ υλοποιείται το accountBalance. Στην classical version  Όλα τα μέρη ξέρουν τις λεπτομέρειες της υλοποίησης του account_balance

Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 42 Η δύναμη του Object-Oriented Παραδείγματος Με information hiding, η φάση του postdelivery maintenance είναι πιο ασφαλής (εύκολη)  Η πιθανότητα να οδηγηθούμε σε ανεπιθύμητες καταστάσεις ελαττώνεται Η φάση του Development είναι πιο εύκολη  Τα Objects έχουν συνήθως αντίστοιχες ιδιότητες.  Αυτό διευκολύνει την μοντελοποίηση (μια πτυχή κλειδί στο object-oriented paradigm)

Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 43 Η δύναμη του Object-Oriented Παραδείγματος (συνέχ.) Καλά-Σχεδιασμένα (Well-designed) objects είναι ξεχωριστές οντότητες  Καθετί που έχει σχέση με object στον πραγματικό κόσμο μοντελοποιείται στο object— encapsulation  Επικοινωνία με τα objects επιτυγχάνεται με αποστολή μηνυμάτων (messages)  Αυτή η ανεξαρτησία επιτυγχάνεται με responsibility- driven design (θα το ορίσουμε στην συνέχεια)

Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 44 Η δύναμη του Object-Oriented Παραδείγματος (συνέχ.) Ένα classical product εννοιολογικά συνίσταται από μια απλή μονάδα (παρόλα αυτά υλοποιείται από ένα σύνολο μερών)  Το object-oriented paradigm μειώνει την πολυπλοκότητα, επειδή το product συνίσταται από ανεξάρτητες οντότητες Το object-oriented paradigm προαγάγει την επαναχρησιμοποίηση  Τα Objects είναι ανεξάρτητες οντότητες

Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 45 Responsibility-Driven Design Επίσης καλείται design by contract Έστω ότι θέλεις να στείλεις λουλούδια σε μια φίλη σου στο Chicago  Τηλεφώνα στο flowers  Που βρίσκεται flowers ?  Ποιο ανθοπωλείο στο Chicago θα κάνει την παράδοση;  Information hiding  Στείλε ένα μήνυμα στη μέθοδο [action] ενός object χωρίς να έχεις γνώση της εσωτερικής δομής του object

Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 46 Classical Phases vs Object-Oriented Workflows ΔΕΝ υπάρχει αντιστοιχία μεταξύ των φάσεων και των workflows Figure 1.8

Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 47 Analysis/Design “Hump” Στο Structured paradigm:  Υπάρχει μεγάλη διαφορά ανάμεσα στην analysis (τι) και το design (πως) Στο Object-oriented paradigm:  Τα Objects εισάγονται από την αρχή

Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 48 Analysis/Design “Hump” (συνεχ.) Στο classical paradigm  Classical analysis Καθορίζει ΤΙ πρέπει να γίνει  Design Καθορίζει ΠΩΣ πρέπει να γίνει αυτό Αρχιτεκτονικό (Architectural) design — καθορίζει τα μέρη/τμήματα (module) Λεπτομερή (Detailed) design — σχεδιάζει κάθε μέρος/τμήμα

Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 49 Removing the “Hump” Στο object-oriented paradigm  Object-oriented analysis Καθορίζει ΤΙ πρέπει να γίνει Καθορίζει τα objects  Object-oriented design Καθορίζει ΠΩΣ πρέπει να γίνει αυτό Σχεδιάζει τα objects Η διαφορά των δυο παραδειγμάτων παρουσιάζεται στην επόμενη διαφάνεια

Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 50 Περισσότερη Λεπτομέρεια Εισαγωγή Αντικειμένου Εδώ Figure 1.9

Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 51 Object-Oriented Paradigm Modules (objects) εισάγονται ΝΩΡΙΣ από την object-oriented analysis workflow  Αυτό εξασφαλίζει μια ομαλή μετάβαση από την analysis workflow στην design workflow Τα objects υλοποιούνται κατά την implementation workflow  Και πάλιν, η μετάβαση είναι ομαλή

Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 52 Η προοπτική του Object-Oriented Paradigm Το object-oriented paradigm ΠΡΕΠΕΙ να χρησιμοποιείται σωστά  Όλα τα παραδείγματα είναι εύκολο να χρησιμοποιηθούν αδόκιμα Όταν χρησιμοποιείται σωστά το object-oriented paradigm μπορεί να λύσει μερικά (άλλα όχι όλα) από τα προβλήματα του classical paradigm

Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 53 Η προοπτική του Object-Oriented Paradigm (συνεχ.) Το object-oriented paradigm έχει προβλήματα από μόνο του Το object-oriented paradigm είναι η καλύτερη εναλλαχτική λύση που έχουμε σήμερα  Όμως, είναι σίγουρο ότι θα υπάρξει κάτι στο μέλλον που θα είναι καλύτερο του

Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 54 Ορολογία Πελάτης (Client), developer, χρήστης (user) Internal software Contract software Commercial off-the-shelf (COTS) software Open-source software  Linus’s Law

Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 55 Ορολογία (συνέχ.) Λογισμικό (Software) Πρόγραμμα (Program), Σύστημα (system), προϊόν (product) Μεθοδολογία (Methodology), Παράδειγμα (paradigm)  Object-oriented paradigm  Classical (traditional) paradigm Τεχνική (Technique)

Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 56 Ορολογία (συνεχ.) Mistake, fault, failure, error Ατέλεια (Defect) Bug   “A bug  crept into the code” instead of  “I made a mistake”

Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 57 Object-Oriented Ορολογία Το τμήμα Δεδομένων (Data component) of an object  State variable (μεταβλητή κατάστασης)  Instance variable (Java) (μεταβλητή στιγμιότυπου)  Field (C++) (πεδίο)  Attribute (generic) (χαρακτηριστικό) Τμήμα Δράσεων (Action component) of an object  Member function (C++) (συνάρτηση μέλους)  Method (generic) (μέθοδος)

Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 58 Object-Oriented Ορολογία (συνεχ.) C++: A member είναι είτε  Attribute (“field”), ή  Method (“member function”) Java: A field είναι είτε  Attribute (“instance variable”), ή  Method

Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 59 Θέματα Ηθικής Developers and maintainers πρέπει να είναι  Είναι Σκληρά εργαζόμενοι  Είναι Έξυπνοι  Έχουν συναίσθηση των ευθυνών τους  Είναι Ενημερωμένοι για τις νέες μεθοδολογίες και τεχνικές  Είναι ΗΘΗΚΟΙ IEEE-CS ACM Software Engineering Code of Ethics and Professional Practice