Διάλεξη

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

Δεύτερο θετικό: οι φοιτητές είναι σε μία πολύ καλύτερη κατάσταση σε σύγκριση με τα προηγούμενα έτη όσον αφορά το programming. Και αυτό οφείλεται στο νέο ΠΣ που θέσπισε ένα εξαμηνιαίο μάθημα σε programming με υποχρεωτικό εργαστήριο.

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

Στα πλαίσια αυτά η σημερινή διάλεξη είχε τρία μέρη:

ΠΡΩΤΟ ΜΕΡΟΣ

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

ΔΕΥΤΕΡΟ ΜΕΡΟΣ

Στο δεύτερο μέρος παρουσιάστηκε η πρώτη εργαστηριακή άσκηση η οποία έχει στόχο την εξάσκηση με τις συναρτήσεις και την οργάνωση προγράμματος μέσα από ένα παράδειγμα αυτό της Reverse Polish Notation Calculator (RPNCalculator). Τονίσαμε την σημασία του procedural abstraction, της λεκτικής περιγραφής και της αυξητικής ανάπτυξης (incremental development) στην διαδικασία ανάπτυξης προγράμματος. Αναγνωρίσαμε τις βασικές διεργασίες που πρέπει να εκτελεί η αριθμομηχανή μας για να μπορεί να υπολογίσει την τιμή μιας έκφρασης σε RPN και δώσαμε την δομή της main την οποία και ελέγξαμε (https://eclass.upatras.gr/.../Ch0-ProgramStructure1_6.pdf).

ΤΡΙΤΟ ΜΕΡΟΣ

Στο τρίτο μέρος γράψαμε τον πρώτο κώδικα της RPNCalculator με βάση όσα είπαμε στο προηγούμενο μέρος . Αυτός ο κώδικας είναι μέρος της 1ης έκδοσης της RPNCalculator όπως αυτή περιγράφεται στην εργαστηριακή άσκηση. Ο βασικός της στόχος είναι η συγγραφή του σώματος της main και ο έλεγχος της σωστής λειτουργίας της.

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

Καλό εξάμηνο!

Εργαστηριακή Άσκηση Νο1

RPN CALCULATOR ΣΕ C

Την άσκηση του K&R, ελαφρά τροποποιημένη για τους σκοπούς μας, θα δουλέψουμε την πρώτη εβδομάδα για να δούμε μέσα από αυτή προαπαιτούμενες γνώσεις για το εξάμηνο αυτό.

Ένα πρώτο σκελετό διαμορφώσαμε στην ώρα της διάλεξης. Θα συνεχίσουμε πάνω σε αυτόν την Παρασκευή.

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

Φροντιστήριο

Συνεχίσαμε τη διαδικασία ανάπτυξης της RPNCalculator αφού τονίσαμε τον ρόλο της main ως συντονιστή των άλλων συναρτήσεων. Ολοκληρώσαμε τον έλεγχο της main() και δώσαμε τον κώδικα της getOp() που μας επιτρέπει να υπολογίζουμε εκφράσεις με μονοψήφιους τελεστεους. Για να το πετύχουμε αυτό δώσαμε και μια πρώτη πολύ απλή υλοποίηση της στοίβας (RPNCalculatorV2).

Προχωρήσαμε στην επόμενη έκδοση (RPNCalculatorV3) που μας επιτρέπει να έχουμε τελεστέους με περισσότερα ψηφία. Διαπιστώσαμε πως έχουμε πρόβλημα όταν ο χρήστης δεν αφήσει κενό μεταξύ του τελεστή + και του προηγούμενου τελεστέου. Αυτό ήταν αναμενόμενο καθώς παραβιάζεται ο περιορισμός που θέσαμε για να διευκολύνουμε την την υλοποίηση της προηγούμενης έκδοσης. Το πρόγραμμα φαίνεται πως “κολλάει” αν ο χρήστης δώσει την έκφραση 10 20+=<ENTER>. Εξηγήστε για ποιο λόγο έχουμε αυτή τη συμπεριφορά.

Παραβλέψαμε το πρόβλημα αυτό για να ασχοληθούμε με την οργάνωση του προγράμματος και την προστασία των μεταβλητών stack και topItem από την πιθανή χρήση τους από συναρτήσεις πλην των push() και pop(). Τις μεταφέραμε ακριβώς πάνω από τις push και pop τις οποίες φροντίσαμε να έχουμε τελευταίες στο αρχείο. Λύσαμε με τον τρόπο αυτό προσωρινά το πρόβλημα της ορατότητας των stack και topItem.

Για να αφαιρέσουν οι Κ&R τον περιορισμό που επιβάλει ένα κενό μεταξύ τελεστέου και τελεστή χρησιμοποίησαν τις getch() και ungetch(). Περάσαμε στην έκδοση 4 (RPNCalculatorV4). Εξηγήσαμε την λογική που υιοθέτησαν οι K&R και ορίσαμε τις συναρτήσεις στο τέλος του πηγαίου κώδικα. Ορίσαμε και τις γενικές μεταβλητές buf και bufp και τις τοποθετήσαμε ακριβώς πάνω από τις getch() και ungetch() για να περιορίσουμε την ορατότητα τους μόνο σε αυτές. Παρατηρήσαμε όμως ότι οι getch() και ungetch() βλέπουν τώρα τις stack και topItem. Λύση στο πρόβλημα αυτό μας έδωσε ο μηχανισμός του αρχείου. Δημιουργήσαμε το αρχείο stack.c με περιεχόμενα τις μεταβλητές της στοίβας και τις συναρτήσεις push() και pop(). Δώσαμε τη σημασία της λέξης κλειδί static που μας επιτρέπει να περιορίσουμε την ορατότητα μιας καθολικής μεταβλητής στα όρια του αρχείου στο οποίο αυτή βρίσκεται.

Είδαμε μια ακόμη εναλλακτική επιλογή οργάνωσης του κώδικα σε αρχεία για έλεγχο ορατότητας μεταβλητών και συναρτήσεων (RPNCalculatorV5). Δημιουργήσαμε το αρχείο getop.c και βάλαμε μέσα τις getOp() και τις getch() και ungetch() που αυτή μόνο χρησιμοποιεί. Αυτό μας επέτρεψε να περιορίσουμε την ορατότητα των getch() και ungetch() μόνο μέσα στο αρχείο getop.

Στο 2ο μέρος των διαφανειών δώσαμε εναλλακτικές επιλογές οργάνωσης του πηγαίου κώδικα.

Εδώ ολοκληρώθηκε η ενασχόληση μας στις διαλέξεις και το φροντιστήριο με την εργαστηριακή άσκηση Νο 1. Θα έχετε τη δυνατότητα να δουλέψετε πάνω στην άσκηση στο προαιρετικό εργαστήριο της Τετάρτης 1/3.

Το μπάλα είναι τώρα σε εσάς. Δουλέψτε όσες περισσότερες από τις εκδόσεις της εργαστηριακής άσκησης Νο 1 αξιοποιώντας όλα τα παραπάνω. Προσέξτε πως οι εκδόσεις που δουλέψαμε στην αίθουσα δεν είναι σε συμφωνία με αυτές που ορίζει η εργαστηριακή άσκηση Νο 1.

Εδώ κλείνω το λαπτοπ … Καλό καρναβάλι! 

Διάλεξη

Η σημερινή διάλεξη είχε τρία μέρη.

Στο πρώτο συζητήσαμε όλες τις εκκρεμότητες που είχαμε αφήσει στον κώδικα της getOp() της RPNCalculator με στόχο να αποκτήσει την λειτουργικότητα της Κ&Ρ getop(). Αναφέραμε τις εναλλακτικές για την περίπτωση που θέλουν μια 2η και ίσως μια 3ηστοίβα. Αναφέραμε επιλογές που έχω με την C για να διαχειριστώ την απαίτηση αυτή. Τονίσαμε για άλλη μια φορά πως αυτό ήταν δουλειά που θα έπρεπε να είχατε κάνει εσείς.

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

Τονίσαμε την σημασία της επικοινωνίας για την επίτευξη των στόχων του μαθήματος. Αναφέραμε πως αν οι συνιστώσες ενός προγράμματος (οι συναρτήσεις για τον διαδικαστικό προγραμματισμό, αντικείμενα για τον OOP) δεν επικοινωνούν σωστά μεταξύ τους δεν υπάρχει περίπτωση να πετύχει το πρόγραμμα τον στόχο του ακόμη και αν όλες οι συνιστώσες του κάνουν η κάθε μια σωστά την δουλειά που της έχει ανατεθεί. Eclass και Object Technology Group τα δυο μέσα που θα χρησιμοποιείτε για την επικοινωνία. Οι ερωτήσεις απασχολούν πιθανότατα και άλλους συμφοιτητές σας. Πολλές φορές την απάντηση μπορεί να σας την δώσει συμφοιτητής σας. Και σας παροτρύνουμε σε αυτό. Εμείς να επέμβουμε και θα διορθώσουμε αν χρειαστεί. Τονίσαμε επίσης τη σημασία της ενεργούς συμμετοχής.

Στο τρίτο μέρος κάναμε μια εισαγωγή στο conceptual model του αντικειμενοστρεφούς προγραμματισμού και τονίσαμε πως το μάθημα έχει ως βασικό στόχο την εκμάθηση του αντικειμενοστρεφούς παραδείγματος προγραμματισμού και όχι την εκμάθηση της Java. Την Java χρησιμοποιούμε για να δούμε τον τρόπο που μια γλώσσα προγραμματισμού υλοποιεί το αντικειμενοστρεφές παράδειγμα προγραμματισμού. Αν κατανοήσετε τις βασικές αρχές του OOP θα σας είναι εύκολο να χρησιμοποιήσετε στο μέλλον μια άλλη γλώσσα OOP. Αναφέραμε τις έννοιες του αντικειμένου (object) , του στιγμιοτύπου (instance) και της κλάσης (class) και δώσαμε τον λιτό αλλά πολύ μεστό ορισμό του αντικειμένου toy Grady Booch “ An object has state, behavior and identity”. Αναφέραμε το μήνυμα (message) ως μέσου υλοποίησης της συνεργασίας (collaboration) των αντικειμένων που απαρτίζουν το σύστημα. Είδαμε τις βασικές σχέσεις μεταξύ αντικειμένων, σχέση γενίκευσης/εξειδίκευσης και συνάθροισης και τον τρόπο που η UML τις αναπαριστά. Είδαμε το σύστημα ως συνάθροιση αντικειμένων που το καθένα έχει τις δικές του αρμοδιότητες (Responsibilities) και συνεργάζονται μεταξύ τους ανταλλάσσοντας μηνύματα για να παρέχουν την υπηρεσία για την οποία αναπτύχθηκε το σύστημα (η εφαρμογή). Class-Responsibility-Collaboration (CRC). Ολοκληρώσαμε τη διάλεξη με χρήση της έννοιας της στοίβας ως παράδειγμα των όσων αναφέραμε στο τρίτο αυτό μέρος. Κλείσαμε με απλές ερωτήσεις τις οποίες θα απαντήσουμε στην επόμενη συνάντηση μας.

Φροντιστήριο

ΕΡΓΑΣΤΗΡΙΑΚΗ ΑΣΚΗΣΗ ΝΟ 2

Ξεκινήσαμε το σημερινό δίωρο με μια αναφορά στην τραγωδία των Τεμπών. Αναζητήσαμε το ανθρώπινο λάθος που μας οδήγησε στην τραγωδιά αυτή. Αιτιολογήσαμε γιατί το βασικό ανθρώπινο λάθος δεν είναι ο λάθος χειρισμός του σταθμάρχη αλλά η μη τοποθετηση στο σύστημα μηχανισμού ελέγχου των ενεργειών του χειριστή και αποτροπής κακών χειρισμών. Είπαμε πως ένα τέτοιο σύστημα που χαρακτηρίζεται ως safety critical πρέπει να έχει ενσωματομένους μηχανισμούς ελέγχου κακών χειρισμών. Κάθε κυβερνοφυσικό σύστημα όπως το σύστημα των σιδηροδρόμων πρέπει να διασφαλίζει πως κανένας χειρισμός του ανθρώπινου παράγοντα δεν μπορεί να το οδηγήσει σε απώλεια ανθρώπινης ζωής ή φυσικής καταστροφής. Ακόμη και στην περίπτωση που ο κάθε σταθμάρχης θα θέλει να βάλει μια αμαξοστοιχία σε τμήμα γραμμής που είναι δεσμευμένο το σύστημα δεν θα πρέπει να του το επιτρέπει. Και η τεχνολογία σήμερα μας δίνει όλα τα εργαλεία για αυτό. Το ανθρώπινο λάθος στην περίπτωση μας είναι η μη αξιοποίηση της τεχνολογίας σε ένα ζωτικής σημασίας safety critical σύστημα. Αναφέραμε και το πρόβλημα του αμοιβαίου αποκλεισμού (mutual exclusion) στην χρήση των πόρων από τις διεργασίες και τον σηματοφόρο (semaphore) ως πρώτο βασικό εργαλείο διασφάλισης του αμοιβαίου αποκλεισμού.

Περιγράψαμε το σύστημα ως μια συνάθριση αντικειμένων όπου το καθένα έχει τις αρμοδιότητες που του ανέθεσε ο σχεδιαστής (δημιουργός) του συστήματος και όλα μαζί με την κατάλληλη συνεργασία (collaboration) επιτυχγάνουν το σκοπό για τον οποίο δημιουργήθηκε το σύστημα, δηλαδή την παροχή μίας ή περισσοτέρων υπηρεσιών. Class-Responsibility-Collaboration (CRC).

Περάσαμε στην περιγραφή του αντικειμεονστρεφούς προγραμματισμού ως μιας lego προσέγγισης για την δημιουργία κατασκευών χρησιμοποιώντας έτοιμα τουβλάκια. Τα τουβλάκια μας τα δίνει η βασική βιβλιοθήκη της Java και την χρήση τους είδαμε μέσα από το BlueJ που μας επιτρέπει μέσα από ένα γραφικό περιβάλλον να αλληλεπιδράσουμε με αυτά και να χρησιμοποιήσουμε τις υπηρεσίες τους.

Εξοικείωση με την βασική βιβλιοθήκη της Java και του τρόπου αξιοποίησης των “plastic bricks” που μας δίνει μπορούμε να κάνουμε εκτελώντας την εργαστηριακή άσκηση Νο2. Την άσκηση δουλέψαμε στο πρώτο της μέρος και με αυτό κλείσαμε την σημερινή συνάντηση μας.

Εργαστηριακή Άσκηση Νο2

Πρόσθεση 2 αριθμών με χρήση στοίβας

Tην άσκηση θα δουλέψουμε στο 1ο Εργαστήριο του μαθήματος.

Διάλεξη

Δεν πραγματοποιήθηκε λόγω Κατάληψης του κτιρίου από τους φοιτητές.

Φροντιστήριο

Το πρόγραμμα της σημερινής διάλεξης ανατράπηκε λόγω της κατάληψης της Τετάρτης και της απώλειας της αντίστοιχης διάλεξης.

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

Έτσι δώσαμε ένα μέρος από την σειρά διαφανειών Ch3 PartB-JavaAsAnOopLangPartA (εδώ) και μετά προχωρήσαμε στην σειρά διαφανειών Ch4 PartB-LegoApproachPartB στην οποία δώσαμε πάλι ένα μέρος (εδώ) για να δούμε και την εργαστηριακή άσκηση Νο 3 (RPN Calculator σε Java) την οποία ξεκινάτε να δουλεύετε από σήμερα μετά την ολοκλήρωση της Νο 2.

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

Είδαμε τον ορισμό δημιουργού και την σημασία της λέξης κλειδί this. Αξιοποιώντας όλα αυτά είδαμε και την 2η έκδοση της εφαρμογής CirclesHandlingApp.

Στη συνέχεια περάσαμε στο 2 μέρος της LEgoApproach. Είδαμε τον τρόπο που αναθέτουμε στον υπολογιστή την διεργασία πρόσθεσης 2 αριθμών με χρήση στοίβας, αυτή δηλαδή που είχαμε κάνει διαδραστικά στο πρώτο μέρος της Εργαστηριακής άσκησης Νο2 με χρήση του BlueJ. Αυτό απαιτεί τον ορισμό ενός νέου αντικειμένου που θα αναπαριστά το πρόγραμμα μας. Η συμπεριφορά του αντικειμένου αυτού θα προσδιοριστεί από την μέθοδο main(). Πριν γράψουμε τον κώδικα της main αναφέραμε την σημασία του διαγράμματος αλληλεπίδρασης αντικειμένων (object interaction or sequence diagram). Με βάση αυτά δώσαμε τον κώδικα της main(). Τέλος κάναμε μια αναφορά στις κλάσεις Generic με αφορμή την κλάση Stack και είδαμε την σημασία της έκφρασης System.out.println().

Κλείσαμε την σημερινή διάλεξη με μια σύντομη αναφορά στην εργαστηριακή άσκηση Νο3 που έχει πρώτο κύριο στόχο την κατανόηση έτοιμου κώδικα ανατρέχοντας στην βασική βιβλιοθήκη της Java.

Είναι μια καλή άσκηση που θα σας βοηθήσει να εξοικειωθείτε με τις βασικές έννοιες του μαθήματος με την προϋπόθεση να της δώσετε χρόνο.

Καλό σκ.

Διάλεξη

Ξεκινήσαμε τη σημερινή διάλεξη με μια ακόμη αναφορά στο keyword this και επεξήγηση του χρησιμοποιώντας το παράδειγμα της κλάσης Circle στον μαυροπίνακα (αρχείο Ch3_PartB-JavaAsAnOopLangPartA_3). Είδαμε την χρήση του μέσα στον δημιουργό και είπαμε πως η αναφορά που περιέχει είναι η επιστρεφόμενη τιμή του δημιουργού. Δώσαμε την μέθοδο hasRadius ως παράδειγμα μεθόδου που η χρήση του this επιβάλλεται από τον τρόπο ορισμού της υπογραφής της μεθόδου. Στη συνέχεια είδαμε τον τρόπο εμφάνισης των data members των στιγμιότυπων της Circle με την μέθοδο print() και δώσαμε ως καλύτερη επιλογή για την δουλειά αυτή την μέθοδο toSting() την οποία και ορίσαμε μέσα στην κλάση Circle. Την μέθοδο toString() είχαμε αναφέρει στην προσπάθεια εξήγησης της πρότασης System.out.println(“Stack status: ” + st1) όπου το st1 ήταν αναφορά στοίβας. Στη συνέχεια δώσαμε τον τρόπο που μπορούμε να κάνουμε enforce το data encapsulation στην κλάση με την χρήση των Accessors και Mutators.

Συνεχίσαμε με το αρχείο διαφανειών Ch4_PartB-LegoApproachPartB_2 βλέποντας πάλι εν συντομία το πρόγραμμα Calc όπως το είχαμε δομήσει στην προηγούμενη διάλεξη. Παρατηρήσαμε πως όλη η λειτουργικότητα του προγράμματος υλοποιείται από την main(). Βάλαμε ως στόχο να αυξήσουμε τo modularity του προγράμματος μας με ταυτόχρονη αύξηση της επαναχρησιμοποίησης (reusability). Εντοπίσαμε ένα τμήμα κώδικα που υλοποιεί μια αυτόνομη λειτουργικότητα, αυτή της πρόσθεσης με την χρήση της στοίβας, και δώσαμε εναλλακτικές επιλογές υλοποίησης. Πρώτα ορίσαμε την μέθοδο κλάσης add() και αναφέραμε τους περιορισμούς στην επαναχρησιμοποίηση που αυτή υποστηρίζει. Προτιμάμε να αναθέσουμε την αρμοδιότητα αυτή σε ένα άλλο αντικείμενο το οποίο ονομάσαμε Adder. Είδαμε τη λειτουργικότητα ως μέθοδο κλάσης και ως μέθοδο στιγμιότυπου και τα είδαμε όλα αυτά γράφοντας κώδικα στο BlueJ (CalcLectureTime15Mar23). Λύσαμε και το πρόβλημα της εξάρτησης της Adder από την Calc και το εξηγήσαμε στον μαυροπίνακα (σχετική εικόνα επισυνάπτεται). H εξάρτηση αυτή δεν επέτρεπε την αξιοποίηση της Adder σε άλλο πρόγραμμα. Ολοκληρώσαμε έτσι την σειρά διαφανειών Ch4_PartB-LegoApproachPartB_2.

Στο τρίτο και τελευταίο μέρος ξεκινήσαμε με μία αναφορά στην Εργαστηριακή Άκηση Νο 3 η οποία αξιοποιεί την κλάση Scanner την οποία χρησιμοποιήσαμε μέσα από το BlueJ για να εξοικειωθούμε μαζί της. Διαβάσαμε την έκφραση χρησιμοποιώντας ένα στιγμιότυπο της (με μέθοδο την μέθοδο nextLine()), βάλαμε την έκφραση σε ένα αλφαριθμητικό και στην συνέχεια δημιουργήσαμε ένα άλλο στιγμιότυπο της Scanner από το οποίο πήραμε τους τελεστέους (με την nextDouble()) και τους βάλαμε σε μία στοίβα (usingScanner).

Περάσαμε στην πρώτη παρουσίαση της εργαστηριακής άσκησης Νο 4 (αρχείο Ch5_Activity5-9_WindowsApp)

Κλείσαμε την σημερινή διάλεξη με μια αναφορά στους πολλαπλούς δημιουργούς, το method overloading που μας επιτρέπει να τους έχουμε και την χρήση του keyword this μέσα στον δημιουργό για κλήση ενός άλλου δημιουργού για αύξηση της επαναχρησιμοποίησης (αρχείο Ch5_PartA-JavaAsAnOopLangPartB_4).

Πολλές νέες έννοιες που θέλουν χρόνο από εσάς για την κατανόηση τους.

Φροντιστήριο

ObjectStateApp

Η σημερινή διάλεξη ξεκίνησε με σχολιασμό του εργαστηρίου που προηγήθηκε και της προβληματικής εικόνας που αυτό εμφάνισε. Τονίσαμε για μια ακόμη φορά πως οι έννοιες είναι νέες και δεν αρκεί μόνο να τις ακούμε στις διαλέξεις. Για την κατανόηση τους είναι απαραίτητη η δική σας ενασχόληση σε χρόνο που εσείς θα επιλέξετε. Οι ασκήσεις θα πρέπει να δουλεύονται στο σπίτι και στο εργαστήριο ερχόμαστε για απορείς και ολοκλήρωση τους. Θέλει δουλειά. Άκρως απαραίτητα: α) εξοικείωση με τις βασικές έννοιες που ήδη αναφέραμε και επαναλάβαμε, β) εξοικείωση με την τεκμηρίωση της βασικής βιβλιοθήκης γ) με τον τρόπο αξιοποίησης των συνθετικών της βασικής βιβλιοθήκης δ) με το BleuJ. Κάθε άσκηση έχει τον στόχο της και δίνει προαπαιτούμενα για τις επόμενες.

Ολοκληρώσαμε την σειρά διαφανειών PartA-JavaAsAnOopLangPartB_4κάνοντας αναφορά σε σταθερές, σε μεθόδους κλάσεις, σε factory methods χρησιμοποιώντας ως παράδειγμα την κλάση Double. Δώσαμε βασικές οδηγίες για την συγγραφή java κώδικα (Java Code Style Guidelines) και δώσαμε ενναλακτικές υλοποιήσεις σε μία πολύ απλή άσκηση. Υλοποιήσεις που πρέπει να είναι όλες κατανοητές. Αφήσαμε την άσκηση ObjectStateApp για το τέλος της διάλεξης για να δώσουμε βασικές έννοιες της τεχνολογίας της Java.

Τονίσαμε πως παραμένουμε στο imperative programming paradigm όπως και με την C στο πρώτο εξάμηνο αλλά τώρα ήμαστε στο Object-Oriented Programming και όχι στο procedural της C. Αναφέραμε τα bytecodes και την διαφοροποίηση που η αξιοποίηση τους εισάγει όχι μόνο στην ανάπτυξη της εφαρμογής αλλά και στην εκτέλεση της. Κάναμε σύντομη αναφορά σε JDK, JRE, τα εργαλεία του JDK javac, java, jar, Javadoc, … και φυσικά τα IDEs που μας προσφέρουν ένα πιο αποτελεσματικό περιβάλλον ανάπτυξης εφαρμογών (αρχείο Ch3_PartA-JavaTechnologyIntro_2).

Ολοκληρώσαμε την σημερινή διάλεξη δουλεύοντας πάνω στην άσκηση ObjectStateApp. Ξεκινήσαμε εφαρμόζοντας την bottom-up προσέγγιση με βάση την οποία αναγνωρίζω πρώτα τα αντικείμενα που θα πρέπει να απαρτίζουν το σύστημα μου στο χρόνο εκτέλεσης (και αυτά μπορεί να είναι κλάσεις και στιγμιότυπα) και στη συνέχει ορίζω την δομή τους και τους αναθέτω αρμοδιότητες (responsibilities) ορίζοντας την συμπεριφορά τους. Αποτυπώνω αυτά σε ένα διάγραμμα κλάσεων. Έτσι δημιουργήσαμε σε συνεργασία ένα πρώτο διάγραμμα κλάσεων (ObjectStateApp UML class diagram). Τέλος θα πρέπει να ορίσω τον τρόπο συνεργασίας τους (Object collaboration) για να έχω την απαιτούμενη συμπεριφορά από το σύστημα.

Κάντε μια προσπάθεια να αξιοποιήσετε το διάγραμμα αλληλεπίδρασης αντικειμένων (sequence diagram) για να περιγράψετε την συμπεριφορά που υλοποιεί η εφαρμογή σας. Το επόμενο βήμα, η συγγραφή του πηγαίου κώδικα που υλοποιεί την δομή και συμπεριφορά που αποτυπώνουν τα 2 παραπάνω διαγράμματα είναι μια πολύ καλή άσκηση για εσάς. Μέσα από αυτή τη διαδικασία θα σας είναι εύκολο να σχολιάσετε τον όρο Switch που πρότεινε ένα συμφοιτητής σας για μία από τις κλάσεις μας. 

Διάλεξη

Η σημερινή διάλεξη είχε τρία βασικά θέματα:

1. Η java ως επέκταση της C (Ch5_PartB-JavaAsExtensionOfC_2)

2. Garbage Collector (Ch5_PartD-GarbageCollector_1)

3. Εισαγωγή στην Κληρονομικότητα (Ch7-InheritancePartA_1-part1)

Την διάλεξη κλείσαμε με την άσκηση του Παραγωγού/Καταναλωτή, για την οποία δώσαμε μια πρόταση υλοποίησης (Ch4_Activity4-10_ProducerConsumer.pdf) η οποία όμως δεν αποτελεί προσομοίωση του πραγματικού προβλήματος. Αυτό θα διορθώσουμε όταν αργότερα μιλήσουμε για ενεργά (ACTIVE) αντικείμενα. Σας συνιστώ να υλοποιήσετε την πρόταση που δώσαμε. Είναι μια καλή άσκηση.

Φροντιστήριο

Διάλεξη

Το θέμα της σημερινής διάλεξης ήταν development process με έμφαση στο System integration. Χρησιμοποιήσαμε πρώτα ως παράδειγμα για το system integration το πρόγραμμα ObjectState για να σχολιάσουμε μέσα από αυτό και τα παραδοτέα σας. Επαναλάβαμε σύντομα την διαδικασία αναγνώρισης αντικειμένων από την περιγραφή της άσκησης και πως αυτό μας οδηγεί στην δομή της εφαρμογής που την εκφράσαμε με το διάγραμμα κλάσεων. Αναθέσαμε αρμοδιότητες (responsibilities) στα αντικείμενα της εφαρμογής και περάσαμε στο system integration. Ορίσαμε έτσι της κλάση ObjectState. Στη συνέχεια περιγράψαμε την λειτουργικότητα της εφαρμογής χρησιμοποιώντας το sequence diagram. Σχεδιάσαμε βήμα-βήμα το διάγραμμα ακολουθίας (sequence diagram) που περιγράφει τον τρόπο που τα αντικείμενα της εφαρμογής συνεργάζονται (object collaboration) για να υλοποιήσουν την λειτουργικότητα που η εφαρμογή μας θέλουμε να υλοποιεί. Η παραγωγή του κώδικα με βάση τα δύο αυτά διαγράμματα είναι μηχανική δουλειά. Τονίσαμε ότι ο κώδικας θα πρέπει να είναι σύμφωνος με τα διαγράμματα όπως και τα δύο διαγράμματα θα πρέπει να είναι συμβατά μεταξύ τους.

Περάσαμε σε πιο συνθέτες αλληλεπιδράσεις αντικειμένων χρησιμοποιώντας την εργαστηριακή άσκηση RPN Calculator με συνιστώσες, την οποία θα δουλέψετε τις επόμενες 2 εβδομάδες. Είναι μια καλή άσκηση για εξάσκηση στην incremental development τεχνική που θα μας δώσει και την δυνατότητα να δούμε τις γραφικές διεπαφές. Σε πρώτη φάση θα δουλέψετε με μια γραφική διεπαφή που θα σας δώσουμε με την μορφή jar αρχείου. Σε επόμενο στάδιο θα αναπτύξετε την δική σας γραφική διεπαφή. Ξεκινήσαμε την διαδικασία ανάπτυξης αναγνωρίζοντας τα αντικείμενα με τα οποία θα συνθέσουμε την εφαρμογή μας και δημιουργήσαμε ένα πρώτο διάγραμμα κλάσεων. Τονίσαμε πως η γραφική διεπαφή δεν θα υλοποιεί καμιά λειτουργικότητα. Θα επιτρέπει απλά στον χρήστη να επικοινωνεί με τα αντικείμενα που απαρτίζουν την καρδιά της αριθμομηχανής. Αυτό μας μεταφέρει σε ένα άλλο παράδειγμα προγραμματισμού το event-driven. Πρέπει να ορίσουμε λειτουργικότητα για κάθε ένα συμβάν που θα κοινοποιείται στην αριθμομηχανή μέσα από την γραφική διεπαφή. Λειτουργικότητα για το πάτημα του πλήκτρου ψηφίου, το πάτημα του πλήκτρου ENTER, το πάτημα του πλήκτρου Backspace, το πάτημα του πλήκτρου +. Αυτό μας οδήγησε στην ανάθεση αρμοδιοτήτων στα αντικείμενα που απαρτίζουν την καρδία της αριθμομηχανής (engine της αριθμομηχανής την ονομάσαμε για να την διακρίνουμε από τα αντικείμενα της γραφικής διεπαφής). Οι αρμοδιότητες αυτές μας οδήγησαν στον ορισμό των υπογραφών των μεθόδων των κλάσεων. Εστιάσαμε στην αλληλεπίδραση της γραφικής διαπαφής με το στιγμιότυπο της Operand. Περιγράψαμε δύο εναλλακτικές υλοποιήσεις της Operand. Μία με μεταβλητή στιγμιοτύπου πρωτογενή τύπο int. Και μια με StringBuffer καθώς η String είναι immutable. Στα πλαίσια της εργαστηριακής άσκησης θα πρέπει να υλοποιήσετε και τις δύο επιλογές. Σε επόμενο βήμα μπορείτε να αναβαθμίσετε την αριθμομηχανή σας να υποστηρίζει αριθμούς κινητής υποδιαστολής. (αρχείο developmentProcess&systemIntegration)

Αναγνωρίσαμε στην συνέχεια την ύπαρξη σχέσης γενίκευσης/εξειδίκευσης (gen/spec) στις έννοιες του προβλήματος. Adder, Multiplier, κ.λ.π. είναι εξειδικεύσεις της έννοιας Τελεστής. Ορίσαμε έτσι την κλάση Operator και την καταγράψαμε στο διάγραμμα κλάσεων. Αναζητήσαμε κοινή δομή και συμπεριφορά που θα πρέπει να περιληφθεί σε αυτή. Παρατηρήσαμε πώς όλοι οι τελεστές έχουν μία μέθοδο με υπογραφή void operate(). Παρατηρήσαμε όμως ότι τα σώματα των μεθόδων είναι διαφορετικά. Άρα το κοινό είναι μόνο η υπογραφή της μεθόδου. Αυτήν περιλάβαμε στην κλάση Operator και αυτή ήταν η αφορμή να δώσουμε τον ορισμό της abstract μεθόδου και της abstract κλάσης. (αρχείο Ch7-Inheritance)

Ολοκληρώσαμε την σημερινή διάλεξη με μια πρώτη αναφορά σε Shadowed variables και την σημασία της λέξης κλειδί super.

Φροντιστήριο

Κάναμε μια σύντομη αναφορά στις abstract μεθόδους και abstract κλάσεις καθώς και τις επισκιαζόμενες μεταβλητές (shadowed variables) που είχαμε περιγράψει στην προηγούμενη συνάντηση μας, για να περάσουμε στις επικαλυπτόμενες μεθόδους (overriding methods). Δώσαμε ένα απλό αλλά πολύ καλό παράδειγμα που μας επιτρέπει να δούμε την διαφορετική αντιμετώπιση των data members απόγονης κλάσης που έχουν ίδιο όνομα με αυτών πρόγονης κλάσης από τις μεθόδους με το ίδιο όνομα.

Δώσαμε τον ορισμό της πολλαπλής κληρονομικότητας (multiple inheritance) και σημειώσαμε τα προβλήματα που αυτή μπορεί να δημιουργήσει (αρχείο Ch7-Inheritance_2). Προβλήματα που οδήγησαν τους σχεδιαστές της Java να μην υποστηρίξουν με την γλώσσα άμεσα την κληρονομικότητα όπως κάνει η C++. Για να αξιοποιηθούν όμως τα πλεονεκτήματα της πολλαπλής κληρονομικότητας επιλέχθηκε έμμεση υποστήριξη της με την κατασκευή του Interface. Ετσι μια κλάση μπορεί να κληρονομεί (extends) μία μόνο κλάση, αλλά μπορεί ταυτόχρονα να υλοποιεί (implements) ένα ή περισσότερα Interfaces. Αυτό επιτρέπει στα στιγμιότυπα της κλάσης να μπορούν να θεωρηθούν στιγμιότυπα όχι μόνο της πρόγονης κλάσης αλλά και όλων των Interfaces που αυτή υλοποιεί. Μπορούν με άλλα λόγια να φοράνε «διαφορετικά καπέλα».

Αφήσαμε την κατασκευή του Interface να την δούμε την επόμενη εβδομάδα και περάσαμε σε μια πολύ σημαντική ιδιότητα του OOP, στον πολυμορφισμό (Polymorphism). Χρησιμοποιήσαμε την WindowsApp ως μελέτη περίπτωσης για να δούμε την σημασία της ιδιότητας αυτής και των πλεονεκτημάτων που προσφέρει στην διαμόρφωση του πηγαίου κώδικα της εφαρμογής. Είδαμε τα προβλήματα που δημιουργεί στον κώδικα της WindowApp η μη αναγνώριση της σχέσης γενίκευσης/εξειδίκευσης που υπάρχει ανάμεσα στις βασικές έννοιες του προβλήματος. Αναγνωρίσαμε την γενική έννοια Shape της οποίας εξειδικεύσεις μπορούν να θεωρηθούν οι Circle, Rectangle και Triangle. Αναδομήσαμε τον κώδικα μας ώστε να ορίζει τις κλάσεις αυτές ως απογόνους της Shapes στην οποία βάλαμε τα κοινά χαρακτηριστικά τους. Αυτό μας οδήγησε στην διαπίστωση πως καθώς τα στιγμιότυπα τους μπορούν να θεωρηθούν στιγμιότυπα της Shape μπορούμε να τα βάζουμε όχι σε διαφορετικούς πίνακες /διαφορικές συλλογές (Collections) αλλά σε ένα πίνακα/συλλογή.

Είδαμε την ευελιξία που αυτό προσφέρει στον κώδικα μας, και δώσαμε τον ορισμό του πολυμορφισμού. Είδαμε πως η αξιοποίηση του εισάγει την έννοια του late binding (όψιμης διασύνδεσης) σε αντίθεση με την διασύνδεση που μέχρι τώρα είχαμε στον κώδικα μας, της java αλλά και της C, Εξηγήσαμε το late binding σε συνδυασμό με το early binding και αναφέραμε τις επιπτώσεις που αυτό έχει στο χρόνο εκτέλεσης.

Καθώς η WindowsApp μας επιτρέπει την αξιοποίηση του Iterator κάναμε μια σύντομη αναφορά σε αυτόν και δώσαμε παράδειγμα αξιοποίησης του με το for loop. Και με αφορμή αυτό δώσαμε κα μία πιο ευέλικτη μορφή του for loop το for-each loop. Αυτό αποτελεί ένα ακόμη βήμα αφαιρετικότητας που έδωσαν οι σχεδιαστές της γλώσσας για να την φέρουν πιο κοντά στην φυσική γλώσσα και να διευκολύνουν ακόμη περισσότερο την μετατροπή της λεκτικής περιγραφής σε γλώσσα πηγαίου κώδικα διεκολύνοντας έτσι το έργο του προγραμματιστή. Είπαμε πως το επόμενο βήμα το βλέπουμε ήδη μέσα από το ChatGPT το οποίο ξεπερνάει το επίπεδο της διευκόλυνσης και μας οδηγεί στην αφαίρεση της δραστηριότητας του προγραμματισμού από τον άνθρωπο με ότι συνέπειες αυτό μπορεί να έχει.

Αφήσαμε τις διαφάνειες για πακέτα (packets), προσδιοριστές ορατότητας μεταβλητών (visibility modifiers) και αρχικοποιήσεις μεταβλητών (field initialization) (αρχείο Ch5-PartC_1) για να δώσουμε λίγο χρόνο στην επίδειξη του Eclipse με την ανάπτυξη του project HandleShapes το οποίο αναπτύξαμε βήμα-βήμα μαζί (HandleShapes.rar).

Όλα αυτά έχετε την ευκαιρία να αξιοποιήσετε στην ανάπτυξη της δικής έκδοσης της WindowsApp και να υποβάλετε ένα αξιόλογο παραδοτέο.

Καλή σκ … και μην ξεχνάτε την ευχαρίστηση που θα έχετε όταν ο κώδικας σας δουλέψει !

RPN Calculator με συνιστώσες

H ΕΑ RPN Calculator με συνιστώσες - V2.0 αποτελείται από τρεις ασκήσεις. Τις δυο πρώτες μπορείτε να δουλέψετε στις διακοπές του Πάσχα. Την τρίτη θα δουλέψουμε μετά το Πάσχα οπότε θα δώσουμε και την θεματική ενότητα event handling. Για την εκτέλεση της άσκησης χρησιμοποιήστε τον πίνακα περιεχομένων που δίνεται στο pdf και μπορείτε να δείτε στα αριστερά του κειμένου.

Η ΕΑ RPN Calculator με συνιστώσες θα μας απασχολήσει τις επόμενες 2-3 εβδομάδες, καθώς εισάγει σύνθετες αλληλεπιδράσεις των συνιστωσών της, χρήση της κατασκευής του Interface, γραφικές διαπαφές και event-handling.

ChatGPT and WindowsApp

To chatGPT μπορεί ...τουλάχιστο το προσπαθεί ... εσείς;

https://sharegpt.com/c/V0I1WEz?fbclid=IwAR2DAzgxhUhEzZBGE0phLnx3Td_ZWHS3lXRtdaQRmuZaP9vg8aCeg_49nqU

1ο Παραδοτέο - WindowsApp

Αναρτήθηκε η περιγραφή του 1ου παραδοτέου που αφορά την Εργαστηριακή Άσκηση (ΕΑ) WindowsApp. Είναι το πρώτο επίσημο παραδοτέο που θα αξιολογηθεί.

Η ΕΑ παρουσιάστηκε στις 15/3, την δουλέψαμε στις διαλέξεις, στα φροντιστήρια και στο εργαστήριο. Είναι μια πλούσια άσκηση που σας επιτρέπει να χρησιμοποιήσετε, εκτός από τις πολύ βασικές έννοιες του OOP, κληρονομικότητα, πολυμορφισμό, τον τύπο του πίνακα, abstract μεθόδους και abstract κλάσεις, τις utility κλάσεις Vector, ArrayList, LinkedList, τον Iterator, το for-each loop.

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

Διάλεξη

Με βάση το αποτέλεσμα της δημοσκόπησης για τον βαθμό δυσκολίας της ΕΑ WidnowsApp ξεκινήσαμε το πρώτο μέρος της σημερινής διάλεξης με σχολιασμό του παραδοτέου της πρώτης έκδοσης της εφαρμογής που δεν αξιοποιεί την κληρονομικότητα. Σχολιάσαμε το draft διάγραμμα κλάσεων που είχαμε δώσει πριν 20 μέρες και το συμπληρώσαμε με τις υπόλοιπες μεθόδους. Περιγράψαμε με λόγια την λειτουργικότητα της bringToFront η οποία υλοποιεί την αρμοδιότητα που αναθέσαμε στην κλάση Window. Στη συνέχεια δημιουργήσαμε μαζί το διάγραμμα ακολουθίας για την bringToFrontκαι εξηγήσαμε γιατί ο User δεν εμφανίζεται σε αυτό το sequence diagram. Σχολιάσαμε τις μεθόδους addCircle(), addRectangle() and addTriangle() και είδαμε πως διαμορφώνονται με την αξιοποίηση του method overloading. Τονίσαμε την σημασία στην εκπαιδευτική διαδικασία της αξιοποίησης από μέρους σας του ChatGPT με αφορμή τον διάλογο που σας κοινοποίησα για να σας παρακινήσω προς την κατεύθυνση αυτή και την διαπίστωση ότι μόνο 77 από εσάς έκαναν κλικ στον σύνδεσμο του διαλόγου. Στο ίδιο κλίμα δυστυχώς και η συμμετοχή μόνο 49 από εσάς στην δημοσκόπηση για τη δυσκολία της ΕΕ WindowsAppπου είχε στόχο να δούμε αν υπήρχε ανάγκη να αφιερώσουμε χρόνο από την σημερινή διάλεξη για σχολιασμό του παραδοτέου.

Το δεύτερο μέρος αφιερώθηκε στην έκδοση που χρησιμοποιεί κληρονομικότητα στην οποία κάναμε μια γρήγορη αναφορά πάλι (αρχείο Ch7-PartA_Inheritance_4). Σχεδιάσαμε το τροποποιημένο διάγραμμα κλάσεων της εφαρμογής και είδαμε την αξιοποίηση της abstract μεθόδου και της abstract κλάσης. Αναζητήσαμε τα σημεία του κώδικα όπου γίνεται αξιοποίηση του πολυμορφισμού και αυτά στα οποία γίνεται αξιοποίηση του late binding. Δώσαμε τον αντίστοιχο κώδικα και εξηγήσαμε πάνω σε αυτόν τις δύο αυτές πολύ βασικές ιδιότητες του OOP. Είδαμε για μία ακόμη φορά και εξηγήσαμε την χρήση του iterator και την χρήση του for-each loop μέσα στο σώμα της bringToFront(). Έτσι κλείσαμε την ενασχόληση μας με την ΕΑ WindowsApp και ήμαστε έτοιμοι για να περάσουμε στην επόμενη ΕΑ, την RPN Calculator με συνιστώσες που θα μας απασχολήσει τις επόμενες 2-3 εβδομάδες.

Αφιερώσαμε το τρίτο μέρος αποκλειστικά στον τύπο αναφοράς interface (αρχείο Ch7-PartB_Interfaces_1). Δώσαμε το κίνητρο για την αξιοποίηση της κατασκευής αυτής χρησιμοποιώντας ως μελέτη περίπτωσης την αλληλεπίδραση της γραφικής διεπαφής της RPN Calculator, στιγμιότυπου της κλάσης CalculatorGui, με το στιγμιότυπο της Operand. Δώσαμε τον ορισμό του interface, είδαμε τον τρόπο αξιοποίησης της κληρονομικότητας στον ορισμό του αλλά και στην χρήση του. Το συγκρίναμε με την abstract κλάση και είδαμε την σημασία των default μεθόδων. Κλείσαμε την σημερινή διάλεξη με αναφορά στις συλλογές (Collections) της java αναφέροντας ορισμένες από τις βασικές κλάσεις και interfaces που τις απαρτίζουν.

Θέλουμε δουλεία!

Φροντιστήριο

Η τελευταία μας συνάντηση πριν τις διακοπές του Πάσχα είχε δύο μέρη.

Στο πρώτο μέρος δουλέψαμε πάνω στην ΕΑ5. Αναπτύξαμε μαζί βήμα προς βήμα την άσκηση Νο 1 και τα δύο iterations της άσκησης Νο2 (δες νέα έκδοση (V2.0) της ΕΑ5 RPN Calculator με συνιστώσες στην σχετική ανάρτηση - Εργαστηριακή Άσκηση Νο 5).

Στο δεύτερο μέροςείδαμε εν τάχει πακέτα, ορατότητα μεταβλητών, απόδοση αρχικών τιμών σε data members, και autoboxing (αρχείο Ch5-PartC_1-Part1) . Δώσαμε την άσκηση WordRepetitionCounter με χρήση Map. Η άσκηση αποτελεί βάση για μία από τις ασκήσεις για εξάσκηση (δες σχετική ανάρτηση – Ασκήσεις για εξάσκηση Νο1).

Συνεχίσαμε με βασικές έννοιες πάνω στις γραφικές διεπαφές χρησιμοποιώντας ως μελέτη περίπτωσης την γραφική διεπαφή της RPN Calculator (αρχείο Ch8-PartA_HumanComputerInteraction). Είπαμε πως για την υλοποίηση βασικής λειτουργικότητας στην γραφική διεπαφή είναι απαραίτητη η θεματική ενότητα event handling την οποία θα καλύψουμε μετά το Πάσχα.

Ασκήσεις για εξάσκηση Νο1

Άσκηση Νο1 : WordRepetirionCounter

Τροποποιήστε το πρόγραμμα WordRepetirionCounter που είδαμε στην συνάντηση μας (αρχείο Ch5-PartC_1-Part1) ώστε να δέχεται το κείμενο από την βασική είσοδο (System.in).

Άσκηση Νο2 : WindowsApp using Container

Στην διάλεξη για τις γραφικές διεπαφές είδαμε πως η κλάση Frame που χρησιμοποιήσαμε για την γραφική διεπαφή της CalculatorGui κληρονομεί την Window η οποία με την σειρά της κληρονομεί την Container.

Στην τεκμηρίωση της βασικής βιβλιοθήκης βρίσκουμε τα παρακάτω για την κλάση Conatiner.

“A generic Abstract Window Toolkit(AWT) container object is a component that can contain other AWT components.

Components added to a container are tracked in a list. The order of the list will define the components' front-to-back stacking order within the container. If no index is specified when adding a component to a container, it will be added to the end of the list (and hence to the bottom of the stacking order)”.

Δώσετε μια τροποποιημένη υλοποίηση της WindowsApp η οποία να αξιοποιεί αυτή την λειτουργικότητα που παρέχει η κλάση Container. Δώστε το διάγραμμα κλάσεων της νέας υλοποίησης. 

Διάλεξη

Ξεκινήσαμε με μια σύντομη αναφορά σε γραφικές διεπαφές και event handling. Εξηγήσαμε τη σημασία του όρου awt και τα πλεονεκτήματα που αυτό παρέχει.

Οσον αφορά το event handling επικεντρώσαμε κυρίως στην αντιστοίχιση του σεναρίου event handling του Goody’s με αυτό που υλοποιήσαμε στην RpnCalculator με τις κλάσεις ButtonListeners.

Εντοπίσαμε τη διαφορά και προσπαθήσαμε πρώτα να δούμε στο Goody’s μια υλοποίηση αντίστοιχη της RpnCalculator. Την απάντηση μας την έδωσε ο "σερβιτόρος".

Για να δούμε στην RpnCalculator μια υλοποίηση αντίστοιχη του Goody’s όπου ο Listener έχει και την αρμοδιότητα της κατανάλωσης του event και απόκρισης σε αυτό, θεωρήσαμε τον Listener του ButtonPlus. Μια αντιστοίχιση μας οδηγεί στην θεώρηση στιγμιότυπου της Adder ως Listener στην ButtonPlus. ¨Έτσι το στιγμιότυπο της Adder μπορεί να θεωρηθεί αντίστοιχο του Νικολάου στο σενάριο Goody’s. Αυτό, είδαμε, πως προϋποθέτει η Adder να κάνει implements το ActionListener interface, και ως εκ τούτου να υλοποιεί την μέθοδο actionPerformed. Και αν αξιοποιήσουμε την κληρονομικότητα της Adder από την Operator μπορούμε να βάλουμε την Operator να κάνει implements το ActionListener interface και με τον τρόπο αυτό κληρονομούν και οι υπόλοιποι Τελεστές μας την ιδιότητα να μπορούν τα στιγμιότυπα τους να παίξουν τον ρόλο του Listener. Θα πρέπει βέβαια να δοκιμάσετε την υλοποίηση αυτή για να την κατανοήσετε σε βάθος.

Αλλάξαμε θέμα. Επιστρέψαμε στο System Integration και στο object collaboration. Δημιουργήσαμε ένα RpnCalculator με τους Χρήστο, Άγγελο, Μιχάλη, Κων/νο, Πέτρο, Γιάννη, Ραγαήλ, Έλενα, Νίκο, και Ράνια, να παίζουν τον ρόλο των συνθετικών της RpnCalculator και να συνεργάζονται για τον υπολογισμό της έκφρασης 10 10 += ανταποκρινόμενοι στην πίεση από τον χρήστη των κατάλληλων πλήκτρων της γραφικής διεπαφής. Διαμορφώσαμε βήμα προς βήμα ένα πρόχειρο διάγραμμα ακολουθίας που περιγράφει το object collaboration για τον υπολογισμό της τιμής της έκφρασης.

Είδαμε πως για να αποκριθεί η Έλενα στο κλικ πρέπει να γνωρίζει το όνομα του Γιάννη (την αναφορά του Listener) και πως την πληροφορία αυτή έχει την αρμοδιότητα να της την δώσει ο Άγγελος όταν δημιουργεί την Έλενα. Διαπιστώσαμε πως Χρήστος και Άγγελος έχουν το πιο σύνθετο έργο αλλά μόνο στο «στήσιμο» του συστήματος μετά «ξεκουράζονται».

Περάσαμε σε ενναλακτικές υλοποιήσεις του delegation event model χρησιμοποιώντας ως μελέτη περίπτωσης (Case study) την RpnCalculator. Είδαμε πως μπορούν να χρησιμοποιηθούν εσωτερικές κλάσεις (inner class), local inner class, anonymous class και lambda expressions. Τονίσαμε πως τα τελευταία είναι πολύ σύνθετα για το επίπεδο σας και πως θα πρέπει να ασχοληθείτε με την κατανόηση τους μόνο όταν έχετε κατανοήσει σε βάθος το προηγούμενο σενάριο της RpnCalculator με τους συμφοιτητές σας.

Με όλα αυτά δεν έμεινε χρόνος για exception Handling. Θα το δούμε αυριο.

Φροντιστήριο

EXCEPTION HANDLING

H συνάντηση μας είχε αποκλειστικό θέμα τη διαχείριση εξαιρέσεων.

Στο 1ο μέρος είδαμε τις βασικές έννοιες και τονίσαμε πως είστε ήδη εξοικειωμένοι με αυτές από την καθημερινή πρακτική. Παρουσιάσαμε τις βασικές έννοιες χρησιμοποιώντας το Goody’s. Είδαμε επίσης τον τρόπο που κάνουμε διαχείριση λαθών στην C και εντοπίσαμε τις αδυναμίες. Αυτό ήταν και το κίνητρο για την δημιουργία του μηχανισμού του Exception Handling με στόχο να διατηρήρησουμε το clarity διασφαλίζοντας ταυτόχρονα και το correctness του πηγαίου κώδικα. (αρχείο Ch9-PartA_ExceptionHandlingIntro).

Στο 2ο μέρος είδαμε τον τρόπο που η Java υλοποιεί τη διαχείριση εξαιρέσεων με την κατασκευή try-catch-finally. Είδαμε πως η διαχείριση εξαιρέσεων επιβάλλεται από το σύστημα. Θα πρέπει η να συλλάβουμε ή να μεταδώσουμε μια εξαίρεση η οποία γενάτε από μέθοδο που θα καλέσουμε. Αυτός είναι και ο λόγος που οι εξαιρέσεις που εγείρει μια μέθοδος αποτελούν μέρος της υπογραφής της μεθόδου καθώς ο χρήστης της θα πρέπει να τις γνωρίζει ώστε να τις χειριστεί κατάλληλα. Δώσαμε ως παράδειγμα τις μεθόδους της κλάσης Stack που έχουμε ήδη χρησιμοποιήσει. Είδαμε τον ορισμό τύπου εξαίρεσης και παράδειγμα συγγραφής μεθόδου που εγείρει εξαίρεση (αρχείο Ch9-PartB_ExceptionHandlingInJava(partOf).pdf)).

Πάνω στο θέμα της διαχείρισης εξαιρέσεων θα συνεχίσουμε στην επόμενη διάλεξη.

Logic Gates Circuit Simulator

Με την ολοκλήρωση της ΕΑ5 ήμαστε έτοιμοι να προχωρήσουμε στην ΕΑ6 (Logic Gates Circuit Simulator) που εστιάζει στο data abstraction και φυσικά αξιοποιεί όλα όσα διδαχθήκατε μέχρι σήμερα και έπρεπε να έχετε αξιοποιήσει επιτυχώς στην ΕΑ5.

Μέσα από την ΕΑ6 σας δίνεται μία ακόμη ευκαιρία να καλύψετε τις γνώσεις σας σε βασικές έννοιες του OOP και να βελτιώσετε τις δεξιότητες σας στην χρήση των κατασκευών μιας OOP γλώσσας και την αξιοποίηση της βασικής βιβλιοθήκης.

Την ΕΑ6 θα εκτελέσετε αύριο στο εργαστήριο και στόχος σας θα είναι η ολοκλήρωση του πρώτου Iteration της.

Αυτό προϋποθέτει την μελέτη της άσκησης από μέρους σας πριν την προσέλευση σας στο εργαστήριο.

Στο δίωρο του φροντιστηρίου θα εστιάσουμε σε τρία θέματα:

1. Σχόλια στο παραδοτέο της ΕΑ5.

2. Exception Handling

3. Data abstraction χρησιμοποιώντας ως μελέτη περίπτωσης το iteration 2 (και αν προλάβουμε και το 3) της ΕΑ6. 

Διάλεξη

Φροντιστήριο

Διάλεξη

Μεταξύ των παρακάτω θεμάτων που σας πρότεινα επιλέξατε να ξεκινήσουμε με το 2 και να δούμε και το 3.

1. Exception Handling Revisited

2. Αναπαράσταση και Οργάνωση Δεδομένων φυσικού προβλήματος. Μελέτη περίπτωσης: ΕΑ6 Logic Gates Circuit Simulator (Ch4_Activity4-8_LGSim)

3. Ταυτόχρονος Προγραμματισμός (Concurrent Programming). Μελέτη περίπτωσης: Παραγωγός/Καταναλωτής

4. EA5 Comments on Deliverables

Ξεκινήσαμε με την μελέτη της περίπτωσης που το κύκλωμα μας είναι hardcoded στον κώδικα και συζητήσαμε ενναλακτικές υλοποιήσεις δίνοντας ενδεικτικό κώδικα για την περίπτωση που έχουμε το κύκλωμα μας πάνω στο breadboard.

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

Προς την κατεύθυνση αυτή εντοπίσαμε την πληροφορία που δίνει την σύνθεση του κυκλώματος, την πληροφορία δηλαδή που χρειάζεται η μηχανή για να υπολογίσει την έξοδο του κυκλώματος. Βάλαμε ταυτόχρονα ορισμένους περιορισμούς για να έχουμε διαχειρίσιμη πολυπλοκότητα στην πρώτη μας αυτή προσπάθεια υλοποίησης.

Την πληροφορία αυτή πρέπει να αναπαραστήσουμε σε μορφή που κατανοεί η μηχανή και να την οργανώσουμε με τρόπο που θα μπορεί να την αξιοποιήσει αποτελεσματικά η μηχανή. Συζητήσαμε ενναλακτικές υλοποιήσεις και δώσαμε ενδεικτική υλοποίηση χρησιμοποιώντας array. Φτάσαμε έτσι στον ορισμό του πίνακα circuitGate[3][8][5];

Παρατηρήσατε πως η πληροφορία για κάθε πύλη της στήλης στην οποία βρίσκεται είναι πλεονασμός και αυτό μας οδήγησε στην μετατροπή του ορισμού σε circuitGate[3][8][5];

Με βάση αυτόν τον ορισμό περιγράψαμε την διεργασία υπολογισμού της εξόδου του κυκλώματος, δηλαδή την calculateCircuitOutputs(). Είδαμε πως η περιγραφή αυτή είναι ανεξάρτητη από την σύνθεση του συγκεκριμένου κυκλώματος.

Το επόμενο πρόβλημα που συζητήσαμε ήταν η απόδοση τιμών στον πίνακα circuitGate. Δεν θέλουμε αυτό να είναι hardcoded. Δώσαμε μια πρόταση αντιμετώπισης με την χρήση μιας περιγραφής του κυκλώματος σε μορφή κειμένου. Έχουμε έτσι τρεις περιγραφές του κυκλώματος:

1.Το σχήμα του κυκλώματος (human-readable περιγραφή)

2.Τον πίνακα circuitGate (machine-readable περιγραφή)

3. Την περιγραφή σε μορφή κειμένου.

Η τρίτη είναι human-readable και ταυτόχρονα μπορούμε να δώσουμε οδηγίες στην μηχανή να την επεξεργαστεί και να παράγει την machine-readable. Επιπλέον μπορούμε εμείς να την δημιουργήσουμε με βάση το σχήμα του κυκλώματος. Μπορούμε δηλαδή να περιγράψουμε την διεργασία που θα διαβάζει το αρχείο κειμένου περιγραφής του κυκλώματος και θα δημιουργεί την machine-readable περιγραφή.

Όλα τα παραπάνω είναι εφαρμόσιμα και σε μια διαδικαστική προσέγγιση με υλοποίηση σε μία γλώσσα διαδικαστικού προγραμματισμού π.χ. την C που έχετε ήδη δει.

Περάσαμε στην συνέχεια στην συζήτηση μιας αντικειμενοστρεφούς προσέγγισης και αναφέραμε ενναλακτικές υλοποιήσεις. Δώσαμε ενδεικτικό διάγραμμα κλάσεων και αναθέσαμε αρμοδιότητες στα αντικείμενα που συνθέτουν την εφαρμογή μας. Συζητήσαμε την κλάση gateOnBreadboard και την σχέση της με της Gate. Είδαμε πως η διεργασία της μετατροπής της περιγραφής σε μορφή κειμένου του κυκλώματος στην machine-readable μπορεί να είναι αρμοδιότητα του δημιουργού της Circuit ή αρμοδιότητα μιας μεθόδου της με όνομα π.χ. load().

Αναφέραμε και το επόμενο βήμα σε μια τέτοια εφαρμογή. Την δημιουργία γραφικής διεπαφής που θα επιτρέπει στον χρήση να σχηματίζει το κύκλωμα και η μηχανή στη συνέχει να ενημερώνει την machine-readable περιγραφή. Ενδεικτική υλοποίηση εδώ και υλοποίηση ενός φοιτητή εδώ.

Είδαμε όλα τα παραπάνω στον μαυροπίνακα (ενδεικτικές εικόνες στο τέλος της ανάρτησης) και στις διαφάνειες Ch4_Activity4-8_LogicGatesCircuitSim_2.pdf.

Με όλα αυτά δεν έμεινε χρόνος για Ταυτόχρονο Προγραμματισμό. Στην επόμενη συνάντηση μας.

Φροντιστήριο

Διάλεξη

Δύο μήνες πριν, στις 20 Μαρτίου, δώσαμε στον μαυροπίνακα μια πρόταση υλοποίησης του προβλήματος Παραγωγού/Καταναλωτή. Μια πρόταση για την οποία αναφέραμε πως δεν αποτελεί προσομοίωση του πραγματικού προβλήματος. Και είπαμε πως αυτό θα διορθώσουμε όταν αργότερα μιλήσουμε για ενεργά (ACTIVE) αντικείμενα. Σας προέτρεψα τότε να υλοποιήσετε την πρόταση που δώσαμε καθώς αυτό είναι μια καλή άσκηση για το επίπεδο στο οποίο βρισκόσασταν τότε.

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

Δώσαμε τον κώδικα υλοποίησης χωρίς χρήση των κατασκευών ταυτόχρονου προγραμματισμού και εξηγήσαμε γιατί δεν αποτελεί προσομοίωση του φυσικού προβλήματος Παραγωγού/Καταναλωτή.

Για να διορθώσουμε την πρόταση μας, μετατρέψαμε τα αντικείμενα του Παραγωγού και του Καταναλωτή σε ενεργά. Σε αντικείμενα δηλαδή που έχουν το δικό τους νήμα εκτέλεσης (thread of execution). Αυτό το κάναμε αξιοποιώντας την κλάση Thread της βασικής βιβλιοθήκης. Ορίσαμε τις μεθόδους run των δύο κλάσεων και στη συνέχεια δώσαμε την main της κλάσης Producer/Consumer. Προσπαθήσαμε να περιγράψουμε τον τρόπο εκτέλεσης του προγράμματος και μέσα από αυτό να εντοπίσουμε τα προβλήματα που η λύση μας έχει. Καταγράψαμε και περιγράψαμε τρία προβλήματα. Αιτιολογήσαμε γιατί αυτά εμφανίζονται.

Στην αρχή της σημερινής μας συνάντησης και με αφορμή ερωτήσεις σας συζητήσαμε πάλι τo iteration 3 της ΕΑ6. Αιτιολογήσαμε αναλυτικά τη σημασία της κλάσης GateOnBoard και τον τρόπο αξιοποίησης της για την συγγραφή της μεθόδου calculateOutput() της κλάσης Circuit.

Φροντιστήριο

Διάλεξη

Δέκατη Τρίτη εβδομάδα και με την αναφορά στην C++ για Java Developers ολοκληρώσαμε το μάθημα για το εξάμηνο αυτό. Είδαμε πως με την γνώση της C από το χειμερινό εξάμηνο και την γνώση του αντικειμενοστρεφούς προγραμματισμού από το εαρινό η μετάβαση στην C++ είναι σχετικά απλή υπόθεση.

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

Σε κάθε περίπτωση η εξοικείωση με μία γλώσσα προϋποθέτει την συγγραφή κώδικα. Μπορείτε για εξάσκηση να δουλέψετε πάνω στην υλοποίηση των ΕΑ που εκτελέσαμε κατά την διάρκεια του εξαμήνου.

Αν έχετε ενδιαφέρον να σχολιάσουμε παραδοτέα της ΕΑ6 και των άλλων ΕΑ δηλώστε το ενδιαφέρον σας αυτό και θα αξιοποιήσουμε την ώρα της Παρασκευής για το αντικείμενο αυτό.

Φροντιστήριο