Venus AUEB Forum

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

Να είσαι καλα!!! Πιστεύω πως μετά τις 20 του μήνα θα υπάρξει ένας ψιλοκατεγισμός

Ερώτηση: μήπως στην έκδοση του Rational Rose που έχουμε δεν υποστηρίζεται η Structured Activity? Γιατί ψάχνω να βρω το σηματάκι της τρίαινας αλλά δεν...
Θέλω να απλοποιήσω μια activity και να τη διασπάσω σε επιμέρους, ώστε να μην είναι τόσο πολύπλοκο το Activity Diagram μου. Αν όντως δεν υποστηρίζεται να το κάνω όπως μπορώ και ας είναι πολύπλοκο?

merged by P3

Ερώτηση 2: στο Activity Diagram όταν φτιάχνω έναν κόμβο απόφασης (το ρόμβο) πρέπει πάντα να φτιάχνω και τον κόμβο merge (άλλο ρόμβο) για να δηλώνω το τέλος της απόφασης? Τι γίνεται όταν δεν καταλήγουν στο ίδιο σημείο οι 2 διαδρομές? Μήπως απλά να μην το βάλω πουθενά και να υπονοείται πότε τελειώνει η διαδικασία της απόφασης? Σε πολλά παραδείγματα το έχω δει χωρίς ρόμβο merge.

Προφανώς και θα υπάρξουν και άλλες ερωτήσεις μέσα στην ημέρα, οπότε θα προσπαθώ να τις στέλνω όλες μαζεμένες...

Ευχαριστώ

Από ότι είδα στο XDE δεν έχει το σύμβολο της structured activity.
Πάντως μπορείτε να μοντελοποιείσετε μιασύνθετη activity φτιάχνοντας ένα νέο activity διάγραμμα μέσα σε μία activity (δεν έχει κλικ σtο activity).

merged by P3

Καποιες γενικές παρατηρήσεις σχετικά με τα μοντέλα:
1) Στο XDΕ το μοντέλο δεν είναι οργανωμένο όπως στην προηγούμενη έκδοση του Rational Rose (δηλ. δεν υπάρχει Use case, Logical, Component, Deployment view κτλ.)
2) Κατ' αρχήν θα πρέπει να φτιάξετε ένα project (File->New->Project). Ένα project περιλαμβάνει ένα ή περισσότερα μοντέλα. Θα χρειαστεί να φτιάξετε τα εξής μοντέλα (File -> New --> Model, θα πρέπει να έχετε ανοικτή την Modeling Perspective για να δείτε το μενού Model).
a) Use case model: το οποίο θα περιλαμβάνει actors, use cases και use case
διαγράμματα.
b) Analysis model: όπου κάθε use case που εντοπίσαμε στο παραπάνω μοντέλο αναλύεται με στόχο τον εντοπισμό κλάσεων, γνωρισμάτων και βασικών αρμοδιοτήτων αυτών καθώς και των σχέσεων μεταξύ τους.
c) Design model: το μοντέλο της ανάλυσης αναπτύσσεται σε μεγαλύτερο βαθμό λεπτομέρειας στο μοντέλο σχεδίασης. Πάλι η δημιουργία του οδηγείται από τα use cases. Κάθε use case realization της ανάλυσης περιγράφεται αυτή τη φορά με κλάσεις σχεδίασης. Σκοπός είναι ο εντοπισμός των κλάσεων του συστήματος, ο εντοπισμός υποσυστημάτων και των interfaces μεταξύ τους και η οργάνωση των κλάσεων σε packages. Στο design model δεν θα γίνει ανάπτυξη του συστήματος στο μέγιστο βαθμό λεπτομέρειας (δηλ. κάποιες κλάσεις ίσως λιγότερο βασικές μπορεί να προστεθούν και στην υλοποίηση). Θα εντοπίσετε σημαντικές κλάσεις που υλοποιούν τη βασική λειτουργικότητα των use cases. Επαναλαμβάνω ο στόχος είναι:
- Εντοπισμός κλάσεων που υλοποιούν βασική λειτουργικότητα των use cases, καθώς και των βασικών γνωρισμάτων και λειτουργιών των κλάσεων.
- Οργάνωσή τους σε packages και υποσυστήματα
- Εντοπισμός διεπαφών του συστήματος και περιγραφή της υλοποίησής τους.
Προσοχή! Το Design model δεν κάνει παραγωγή κώδικα. Η παραγωγή κώδικα γίνεται από ένα Code Model (Java, C++, Web κτλ.). Το ερώτημα βέβαια είναι αν θα ξαναφτιάξουμε τις κλάσεις που εντοπίσαμε στη σχεδίαση στο μοντέλο κώδικα. Όπως το βλέπω υπάρχουν τρεις επιλογές α) είτε τις ξαναφτιάχνετε όλες, β) είτε τις παίρνετε copy paste, γ) δημιουργείτε τις κλάσεις στο Code Model απευθείας και τις κάνετε drag & drop σε όσα διαγράμματα τις χρειάζεστε.
d) Code Model (Java Code Model, C++ or Web). Πρόκειται για την υλοποίηση του συστήματος. Στο μοντέλο αυτό μπορείτε να δείξετε και την κατανομή των τμημάτων του συστήματος στους διάφορους υπολογιστικούς κόμβους.
e) Data model: Σε περίπτωση που χρησιμοποιήσετε βάση δεδομένων στο μοντέλο αυτό δημιουργείτε και παράγετε το σχήμα της βάσης.

merged by P3

Επίσης, προκειμένου να δημιουργήσετε στα Analysis και Design Model use case realizations θα πρέπει να κάνετε το εξής:
Σε ένα package π.χ. αυτό που ονομάζεται use case realizations, πατάτε δεξί κλικ και επιλέγετε collaboration instance. Στη συνέχεια στο collaboration instance που δημιουργείται επιλέγετε από τα properties το stereotype use case realization.

Ερωτήσεις:
α)Στο Rational Rose για να φτιάξεις την εφαρμογή σε jsp φτιάχνεις: use case model, analysis model, design model, sql server data model (sql server 2000), virtual directory model (όπου θα μπούν τα αρχεία .jsp, τα αρχεία αυτά θα καλούν κάποια javabeans). Χρειάζεται κάτι άλλο?
β)Τα javabeans σε ποιό code model θα μπουν? Θα μπουν και αυτά στο Web -> virtual directory model?
γ)Πού θα μπούν τα jar αρχεία του προγράμματος, στο οποίο τρέχει η εφαρμοφή (NetBeans 4.1), και του tomcat?
δ)Για το data model θα πρέπει να συνδεθούμε με τον sql server ή θα δημιουργηθεί κάπως αλλιώς η βάση μέσα στο rational?

Καλά Χριστούγεννα σε όλους.

Κατ'αρχήν χρόνια πολλά και καλή χρονιά!

Απαντήσεις:
α)Πιστεύω ότι δεν χρειάζονται άλλα μοντέλα
β)Εφόσον σου δίνει δυνατότητα να φτιάχνεις σε αυτο java classes μπορούν να μπουν εκεί.
γ)Τα αρχεία jar θα μπουν στο μοντέλο κώδικα που για σένα είναι το virtual directory model
δ)Το data model ορίζεται στο sql server data model. Αυτό θα σου παράγει τον κώδικα DDL για την δημιουργία της βάσης. Δεν εχς δει αν συνδέεται κατευθείαν με SQL Server για τη δημιουργία τησ Βάσης.

Καλή χρονιά και χρόνια πολλά. Θα ήθελα να τονίσω ότι τα ίδια ισχύουν και στην .net. Δηλαδή η ακολουθία των μοντέλων και η παραγωγή κώδικα γίνεται ακριβώς με τον ίδιο τρόπο. Μάλιστα το περιβάλλον και οι toolbars είναι σχεδόν ίδιες.

Moderation Message

Θα σας παρακαλούσα, για την καλύτερη λειτουργία του φόρουμ, να μην γράφεται σε greeklish.

Ευχαριστώ.

Καλησπέρα και χρόνια πολλά:
Θα ήθελα να κάνω κάποιες ερωτήσεις σχετικά με το Analysis model.Ποια είναι η διαφορά μεταξύ της boundary class και της control class;
Επίσης τις entity,boundary,control classes μέσα στο Analysis elements δεν τα δημιουργούμε;
και τέλος υπάρχει τρόπος να δημιουργηθεί entity,boundary ή control class με τη μορφή που υπάρχει ήδη στα analysis elments από το πρόγραμμα;γιατί δημιουργώ νέα κλάση,επιλέγω ως στερεότυπο π.χ. το entity και το ορθογώνιο της κλάσης δεν έχει περίγραμμα,ούτε υπάρχει το όνομα του στερεοτύπου αλλά εμφανίζεται το σύμβολο του .
Ευχαριστώ.

Η boundary class είναι αυτή που παρέχει κάποια διεπαφή π.χ. κάποια φόρμα. Για κάθε actor του μοντέλου, πρέπει να υπάρχει σίγουρα μια boundary class μέσω της οποίας θα επικοινωνεί με το σύστημα.
Η control class απ'ότι έχω καταλάβει είναι μια τάξη που εμπεριέχει τη λογική ενός πακέτου (όπως ορίζεται στο analysis model).
Και τα 3 δημιουργούνται στο μοντέλο αυτό.

Ερωτήσεις

α)Στην εκφώνηση της άσκησης, όταν λέει οτι θέλει 5-10 λειτουργίες εκτυπώσεων τι ακριβώς εννοεί? Δεν εννοεί την παρουσίαση στοιχείων μέσα απο φόρμες γιατί αυτό το λέει παραπάνω. Δεν νομίζω οτι εννοεί να πατάμε ενα κουμπί και να κάνει print. Άρα τι εννοεί?

β)Στο design model - στα sequence διαγράμματα, τους πίνακες της βάσης θα τους αναπαριστούμε ως class ή θα τα κάνουμε drag & drop απο το data model ? (ρωτάω για να δώ αν πρέπει πρώτα να φτιάξω το data model και μετά το design model).

Λογικά πρέπει να έχουμε τελειώσει το analysis Model έχοντας δημιουργήσει τα συγκεκριμένα πακέτα, κλάσεις, τις μεθόδους που υπάρχουν σε αυτές, τα sequence & class diagrams κτλ κτλ
Στο design model τι θα κάνουμε? Θέλω να πω πως από ότι έχουμε διαβάσει πρέπει να δημιουργήσουμε καινούργια πακέτα? Καινούργια sequence & class diagrams? Ποια η διαφορά? Γενικότερα δεν καταλαβαίνουμε τη λογική.
Σε τι θα διαφέρει το design από το analysis. Mε άλλα λόγια, υπάρχουν κάποια βήματα που πρέπει να ακολουθήσουμε για να μεταβούμε στο design model?

kmast wrote:Καλησπέρα και χρόνια πολλά:
Θα ήθελα να κάνω κάποιες ερωτήσεις σχετικά με το Analysis model.Ποια είναι η διαφορά μεταξύ της boundary class και της control class;
Επίσης τις entity,boundary,control classes μέσα στο Analysis elements δεν τα δημιουργούμε;
και τέλος υπάρχει τρόπος να δημιουργηθεί entity,boundary ή control class με τη μορφή που υπάρχει ήδη στα analysis elments από το πρόγραμμα;γιατί δημιουργώ νέα κλάση,επιλέγω ως στερεότυπο π.χ. το entity και το ορθογώνιο της κλάσης δεν έχει περίγραμμα,ούτε υπάρχει το όνομα του στερεοτύπου αλλά εμφανίζεται το σύμβολο του .
Ευχαριστώ.

Η boundary class αντιπροσωπεύει διεπαφή του συστήματος με ένα ή περισσότερους actors. Η control class ενσωματώνει τη ροή ελέγχου στο εσωτερικό της use case. Οι control, boundary και entity κλάσεις έχουν νόημα στο μοντέλο ανάλυσης και τις δημιουργείτε στο εσωτερικό του package Analysis elements.

Για να ρυθμίσετε πως εμφανίζονται οι διάφορες κλάσεις και τα στερεότυπά τους τις επιλέγετε και χρησιμοποιείτε το μενού Format-->Stereotype and Visibility Style.

Brashear wrote:Ερωτήσεις

α)Στην εκφώνηση της άσκησης, όταν λέει οτι θέλει 5-10 λειτουργίες εκτυπώσεων τι ακριβώς εννοεί? Δεν εννοεί την παρουσίαση στοιχείων μέσα απο φόρμες γιατί αυτό το λέει παραπάνω. Δεν νομίζω οτι εννοεί να πατάμε ενα κουμπί και να κάνει print. Άρα τι εννοεί?

β)Στο design model - στα sequence διαγράμματα, τους πίνακες της βάσης θα τους αναπαριστούμε ως class ή θα τα κάνουμε drag & drop απο το data model ? (ρωτάω για να δώ αν πρέπει πρώτα να φτιάξω το data model και μετά το design model).

a) Δεν αναφέρεται σε φόρμες εκτύπωσης αλλά στη δημιουργία αναφορών για την παρουσίαση στοιχείων που διατηρεί το σύστημά σας.

β) Μπορείς να τις κάνεις d&d απο το ένα μοντέλο στο άλλο.

Einherjar wrote:Λογικά πρέπει να έχουμε τελειώσει το analysis Model έχοντας δημιουργήσει τα συγκεκριμένα πακέτα, κλάσεις, τις μεθόδους που υπάρχουν σε αυτές, τα sequence & class diagrams κτλ κτλ
Στο design model τι θα κάνουμε? Θέλω να πω πως από ότι έχουμε διαβάσει πρέπει να δημιουργήσουμε καινούργια πακέτα? Καινούργια sequence & class diagrams? Ποια η διαφορά? Γενικότερα δεν καταλαβαίνουμε τη λογική.
Σε τι θα διαφέρει το design από το analysis. Mε άλλα λόγια, υπάρχουν κάποια βήματα που πρέπει να ακολουθήσουμε για να μεταβούμε στο design model?

Στο analysis model δημιουργείται ένα αφαιρετικό μοντέλο του εσωτερικού του συστήματος το οποίο είναι :
α) σύμφωνα με τις απαιτήσεις του use case model
β) ανεξάρτητο από γλώσσες προγραμματισμού ή άλλες τεχνολογίες υλοποίησης

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

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

Σε γενικές γραμμές ο τρόπος δουλειάς είναι:
1) Αποφασίζω ποια γλώσσα προγραμματισμού θα χρησιμοποιήσω και την βασική αρχιτεκτονική της εφαρμογής μου (δηλαδή θα είναι web εφαρμογή, client server, 3-tier πχ. J2EE κτλ.) καθώς και ποια βάση δεδομένων θα χρησιμοποιήσω για την αποθήκευση των στοιχείων. Αυτά τα δυο καθορίζουν το είδος του Code model και data model.
2) Χωρίζω το σύστημα σε υποσυστήματα και προσδιορίζω τις διεπαφές κυρίως για τα υποσυστήματα που επαναχρησιμοποιούνται από διάφορα τμήματα της εφαρμογής. Δείχνω με διαγράμματα τις σχέσεις μεταξύ υποσυστημάτων.
3) Για κάθε use case realization της ανάλυσης φτιάχνω το αντίστοιχο use case realization στη σχεδίαση με στόχο τον εντοπισμό νέων κλάσεων, την λεπτομερέστερη περιγραφή αυτών που έχουν ήδη εντοπιστεί, την δυνατότητα επαναχρησιμοποίησής τους. Επιστρέφω και διορθώνω τα αποτελέσματα του βήματος 2 όποτε χρειαστεί.

3.1) Για κάθε κλάση που συμμετέχει στο αντίστοιχο use case realization της ανάλυσης προσπαθώ να απαντήσω σε διάφορα ερωτήματα:
α) Ποια είναι η σχέση της με κλάσεις υποδομής της γλώσσας προγραμματισμού που χρησιμοποιώ (π.χ. απογονος του JFrame για μια φόρμα);
β) Χρειάζεται περαιτέρω διάσπαση σε επιμέρους κλάσεις; Μήπως η λειτουργικότητά της έχει ενσωματωθεί ήδη σε άλλες κλάσεις και δεν χρειάζεται πλέον; (Αν μια κλάση είναι entity μπορεί να παραλειφθεί εφόσον έχει δημιουργηθεί αντίστοιχος πίνακας στο data model)
γ) Ποιοι είναι οι τύποι δεδομένων των γνωρισμάτων της;Χρειάζονται επιπλέον γνωρίσματα;
δ) Ποιες είναι οι μέθοδοι της κλάσης, ποιο το αποτέλεσμα και τα ορίσματά τους; Στο ερώτημα αυτό βοηθά η υλοποίηση των διαφόρων σεναρίων εκτέλεσής της use case με χρήση sequence διαγραμμάτων.
ε) Ποιες είναι οι σχέσεις της κλάσης με τις υπόλοιπες κλάσεις του συστήματος.
ζ) Σε ποιο package θα πρέπει να τοποθετηθεί η κλάση;
η) Μπορώ να την επαναχρησιμοποιήσω;

Κάθε jsp στο Virtual Directory Model έχει τις εξής κλάσεις: ένα server, ένα cient και πολλά form.

Στο Design Model, για web εφαρμογή σε jsp:
Θεωρώ κάθε jsp ως μια κλάση. Στα sequence διαγράμματα μπορώ να έχω και τον server και τον client σε μια κλάση (π.χ. request.jsp) ή θα πρέπει να φαίνονται στο διάγραμμα όλα: server, client, form1, form2,...?

α)Μπορώ να βάλω στο sequence ένα object του request.jsp και να βάζω Self Messages στο ίδιο το object. Να λέω για παράδειγμα οτι ο χρήστης εισάγει κάποια δεδομένα και μέσω μιας φόρμας (form - που είναι μέρος του κώδικα του request.jsp) να καλεί το request.jsp κάποια άλλη κλάση (π.χ. την queryDatabaseTable) και τα αποτελέσματα να εμφανίζονται πάλι στο ίδιο request.jsp - το τι ακριβώς γίνεται μέσα στην κλάση request.jsp μπορεί να μπεί στο Documentation του sequence.

β)Διαφορετικά θα πρέπει να φαίνεται στο sequence οτι η κλάση request.jsp_client θέτει μέσω της κλάσης form1 κάποια html_inputs και καλεί την κλάση queryDatabaseTable με παραμέτρους τα παραπάνω html_inputs κ.λ.π. Το οποιο θα είναι ενα τεράστιο sequence διάγραμμα το οποίο δεν ξέρω κατα πόσο θα διαβάζεται.

Πώς πρέπει να είναι?
(Μιλάμε πάντα για τα sequence διαγράμματα στο Design Model)

Κατ' αρχήν θα έχετε διαπιστώσει ότι υπάρχει επιλογή στο XDE για δημιουργία Web Modeling Project όπου μπορείτε να δείτε πάνω κάτω ποια μοντέλα σχετίζονται με μια web εφαρμογή.

Brashear wrote:Κάθε jsp στο Virtual Directory Model έχει τις εξής κλάσεις: ένα server, ένα cient και πολλά form.

Στο Design Model, για web εφαρμογή σε jsp:
Θεωρώ κάθε jsp ως μια κλάση. Στα sequence διαγράμματα μπορώ να έχω και τον server και τον client σε μια κλάση (π.χ. request.jsp) ή θα πρέπει να φαίνονται στο διάγραμμα όλα: server, client, form1, form2,...?

Ναι ακριβώς κάθε jsp αντιστοιχεί σε ένα server page ενώ αντίστοιχες κλάσεις υπάρχουν για τις φόρμες (HTMLForm) και τις client σελίδες (Client page). Στα sequence διαγράμματα θα υπάρχουν όλες οι σχετικές κλάσεις π.χ. ο χρήστης αλληλεπιδρά με την client σελίδα, συμπληρώνει τα στοιχεία μίας ή περισσοτέρων HTMLForm τις οποίες υποβάλλει και η υποβολή γίνεται σε αντίστοιχες server page.

Στην περίπτωση που η client σελίδα περιλαμβάνει και javascript κώδικα μπορείτε αν θέλετε να τον μοντελοποιήσετε σαν απλή κλάση με μεθόδους τις αντίστοιχες μεθόδους της javascript. Ομοίως για applets κτλ.

Brashear wrote: α)Μπορώ να βάλω στο sequence ένα object του request.jsp και να βάζω Self Messages στο ίδιο το object. Να λέω για παράδειγμα οτι ο χρήστης εισάγει κάποια δεδομένα και μέσω μιας φόρμας (form - που είναι μέρος του κώδικα του request.jsp) να καλεί το request.jsp κάποια άλλη κλάση (π.χ. την queryDatabaseTable) και τα αποτελέσματα να εμφανίζονται πάλι στο ίδιο request.jsp - το τι ακριβώς γίνεται μέσα στην κλάση request.jsp μπορεί να μπεί στο Documentation του sequence.

H φόρμα δεν είναι μέρος του κώδικα της jsp σελίδας αλλά μέρος της client σελίδας που παράγεται από αυτή. Συνεπώς το self message δεν έχει νόημα όπως το εννοείς. Όμως η request.jsp μπορεί να καλέσει κάποια κλάση π.χ. ένα java bean ή άλλη σελίδα jsp. Στην περίπτωση αυτή τα αποτελέσματα εμφανίζονται σε μια άλλη ή στην ίδια client page. Η server page δεν εμφανίζει αποτελέσματα απλώς παράγει client pages.

Brashear wrote:
β)Διαφορετικά θα πρέπει να φαίνεται στο sequence οτι η κλάση request.jsp_client θέτει μέσω της κλάσης form1 κάποια html_inputs και καλεί την κλάση queryDatabaseTable με παραμέτρους τα παραπάνω html_inputs κ.λ.π. Το οποιο θα είναι ενα τεράστιο sequence διάγραμμα το οποίο δεν ξέρω κατα πόσο θα διαβάζεται.

Πώς πρέπει να είναι?
(Μιλάμε πάντα για τα sequence διαγράμματα στο Design Model)

Έτσι θα είναι. Προσπάθησε να απλοποιήσεις το διάγραμμα αν είναι τεράστιο χρησιμοποιώντας υποδιαγράμματα. Έτσι μπορείς να φτιάξεις ένα νέο διάγραμμα (Interaction Instance) και να κάνεις drag & drop αυτό σε κατάλληλο σημείο στο αρχικό σου διάγραμμα. Δημιουργείται με τον τρόπο αυτό ένα Global Action με το ίδιο όνομα με το υποδιάγραμμα. Κάνοντας διπλό κλικ σε αυτό γίνεται μετάβαση στο υποδιάγραμμα.

Στο Java Code Model φτιάχνω μια κλάση και τις μεθόδους της, κάνω generate code και φτιάχνει τον κώδικα. Όταν κάνω διπλό κλίκ πάνω στη μέθοδο στον model explorer δεν εμφανίζεται η γραμμή του κώδικα όπου αρχίζει η μέθοδος.
Κανονικά θα έπρεπε πατώντας το εικονίδιο της μεθόδου να μας πηγαίνει στην συγκεκριμένη γραμμή του κώδικα της κλάσης.

Μου βγάζει ένα παράθυρο Browse Code που γράφει τα εξής:
Unable to browse the model item. Possible reasons:
- source file does not exist or is in improper location;
- model item is excluded from RTE;
- model item doesn't have UMLComponent associated.

- Το αρχείο υπάρχει και είναι στο σωστό path.
Τα άλλα δύο τι σημαίνουν? - και τι πρέπει να κάνω σε κάθε περίπτωση?
Πρέπει να κάνω κάποιες ρυθμίσεις?
(Ο κώδικας προχωράει κανονικά - απλά δεν μου εμφανίζει την μέθοδο που επιλέγω απο το Code Model).

Brashear wrote:Στο Java Code Model φτιάχνω μια κλάση και τις μεθόδους της, κάνω generate code και φτιάχνει τον κώδικα. Όταν κάνω διπλό κλίκ πάνω στη μέθοδο στον model explorer δεν εμφανίζεται η γραμμή του κώδικα όπου αρχίζει η μέθοδος.
Κανονικά θα έπρεπε πατώντας το εικονίδιο της μεθόδου να μας πηγαίνει στην συγκεκριμένη γραμμή του κώδικα της κλάσης.

Μου βγάζει ένα παράθυρο Browse Code που γράφει τα εξής:
Unable to browse the model item. Possible reasons:
- source file does not exist or is in improper location;
- model item is excluded from RTE;
- model item doesn't have UMLComponent associated.

- Το αρχείο υπάρχει και είναι στο σωστό path.
Τα άλλα δύο τι σημαίνουν? - και τι πρέπει να κάνω σε κάθε περίπτωση?
Πρέπει να κάνω κάποιες ρυθμίσεις?
(Ο κώδικας προχωράει κανονικά - απλά δεν μου εμφανίζει την μέθοδο που επιλέγω απο το Code Model).

TO RTE σημαίνει Round-Trip-Engineering είναι η ταυτοχρονη δυνατότητα παραγωγής κώδικα και reverse engineering του κώδικα της κλάσης ώστε το μοντέλο να είναι ενημερωμένο με την τρέχουσα μορφή του κώδικα. Στα Java properties της κλάσης κοίταξε αν η επιλογή Synchronization είναι η 3-RTE.

Όσο για το δεύτερο μήνυμα αναφέρεται στην απουσία ενός αντίστοιχου component στο μοντέλο που αναπαριστά το αρχείο κώδικα. Το component εχει το ίδιο όνομα με την κλάση και συνδέεται με κάποια dependency με αυτή. Σου το δημιουργεί αυτόματα όταν κάνεις Synchronization για παραγωγή κώδικα. Αν δεν υπάρχει φτιάξε ένα.

Όσον αφορά την προηγούμενή μου ερώτηση: έκανα και την επιλογή Synchronization 3-RTE και υπάρχει και το component (εχει το ίδιο όνομα με την κλάση και συνδέεται με κάποια dependency με αυτή) αλλά δεν λειτουργεί.
Δεν πιστεύω οτι αυτό είναι τόσο σημαντικό.

a)Στο design model έχω βάλει τα jsp στο <<layer>> Presentation και την κλάση που επικοινωνεί με τη βάση στο <<layer>> Integration. Πειράζει που δεν έχω βάλει καμία κλάση στο <<layer>> Business? Οι κλάσεις που ανέφερα παραπάνω πιστεύω οτι έχουν μπεί στη σωστή τους θέση. Πρέπει οπωσδήποτε να υπάρχουν κλάσεις στο <<layer>> Business? Και αν ναι ποιές να βάλω? Αφού ο κώδικας είναι μέσα στα jsp.

b)Τη βάση (SQL Server Data Model) θα την κάνουμε με κάποιο τρόπο import στον SQL Server και εκεί θα γεμίσουμε τους πίνακες με τιμές. Σωστά?

Καλημέρα!
Θα ήθελα και εγώ με τη σειρά μου να ρωτήσω κάποια πράγματα για τη Uml. Όταν έχουμε ένα Use Case με 3-4 εναλλακτικές ροές(μέσα σε αυτές περιέχονται και η ακύρωση, επιστροφή, εκτύπωση κτλ) πρέπει να δημιουργήσω ισάριθμα sequence diagrams ή υπάρχει κάποιος πιο βολικός τρόπος;
Επίσης ήθελα να μάθω εαν ανάμεσα σε use cases που το ένα ακολουθεί το άλλο υπάρχει "μνήμη" δηλαδή ένα στοιχείο που έχω πάρει από το ένα use case διατηρείται και όταν μεταβώ στο επόμενο;
Ευχαριστώ!

Κάθε use case στο realisation του μπορεί να έχει παραπάνω του ενός εναλλακτικά flows. Με άλλα λόγια για κάθε εναλλακτική λειτουργία που εκτελεί το κάθε use case θα φτιάξουμε και ένα αντίστοιιχο sequence diagram.
Όσο για το δεύτερο τι εννοείς με το "στοιχείο"; Εννοείς αν κάτι που εξάγεται από ένα use case είναι είσοδος για κάποιο άλλο;