You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
154 lines
12 KiB
154 lines
12 KiB
6 years ago
|
\subsection{Στόχος του εγγράφου}
|
||
|
|
||
|
Ακολουθώντας τα στάδια ανάπτυξης λογισμικού, στα προηγούμενα έγγραφα,
|
||
|
το “Έγγραφο Απαιτήσεων Χρηστών” και το “Έγγραφο Απαιτήσεων
|
||
|
Λογισμικού”, καθορίστηκαν όσο το δυνατόν πιο εύστοχα οι απαιτήσεις
|
||
|
χρηστών και λογισμικού, αντίστοιχα. Στο παρόν έγγραφο σειρά έχει ο
|
||
|
αρχιτεκτονικός σχεδιασμός του συστήματος.
|
||
|
|
||
|
Αρχικά σημαντική προϋπόθεση για την σχεδίαση του συστήματος είναι η
|
||
|
δυναμική μοντελοποίηση του συστήματος Robobar με τον πλέον λεπτομερή
|
||
|
τρόπο. Αυτός είναι η παρουσίαση των ροών που περιγράφουν το πώς οι
|
||
|
κλάσεις που αναπτυχτήκαν κατά τη στατική μοντελοποίηση των κλάσεων
|
||
|
ικανοποιούν τα σενάρια χρήσης που δημιουργήθηκαν στο έγγραφο
|
||
|
απαιτήσεων χρηστών. Η δημιουργία δηλαδή των διαγραμμάτων ροών για την
|
||
|
εκτενή περιγραφή της συμπεριφοράς του συστήματος κατά την εκτέλεση των
|
||
|
λειτουργιών του αλλά και κατά την αλληλεπίδραση με τους χρήστες και τα
|
||
|
εξωτερικά συστήματα.
|
||
|
|
||
|
Επιπλέον η αποδόμηση του συστήματος σε υποσυστήματα αποτελεί πάγια
|
||
|
τακτική για την ανάπτυξη ενός λογισμικού και επιτυγχάνεται με την εξής
|
||
|
διαδικασία: το υπάρχον σύστημα διαιρείται σε υποσυστήματα, τα οποία
|
||
|
αλληλεπιδρούν. Στη συνέχεια επιλέγεται η κατάλληλη αρχιτεκτονική ώστε
|
||
|
να έχουμε το καλύτερο δυνατό αποτέλεσμα ως προς την επικοινωνία μεταξύ
|
||
|
των υποσυστημάτων αλλά και τη λειτουργικότητα συστήματος.
|
||
|
|
||
|
Τέλος στο παρόν έγγραφο γίνεται μία λεπτομερής ανάλυση της
|
||
|
αρχιτεκτονικής του συστήματος Robobar, με γνώμονα τις απαιτήσεις
|
||
|
χρηστών και λογισμικού που περιγράφτηκαν στα δύο προηγούμενα
|
||
|
έγγραφα. Τα δομικά στοιχεία του συστήματος, ο τρόπος που επικοινωνούν
|
||
|
μεταξύ τους και τυχόν περιορισμοί που πρέπει να ληφθούν υπόψιν,
|
||
|
αποτελούν μέρη της ανάλυσης αυτής.
|
||
|
|
||
|
|
||
|
\subsection{Αντικείμενο του Λογισμικού}
|
||
|
|
||
|
Το λογισμικό Robobar έχει ως αντικείμενο το σύνολο των δραστηριοτήτων
|
||
|
που χρειάζονται ώστε να λειτουργήσει ένα μπαρ. Αναλυτικότερα, το
|
||
|
λογισμικό RoboBar έχει ως στόχο την γρήγορη και εύκολη εξυπηρέτηση των
|
||
|
πελατών ενός μπαρ.
|
||
|
|
||
|
Το σύστημα αλληλεπιδρά με δυο είδη χρηστών τους απλούς
|
||
|
χρήστες-εργαζόμενους του μπαρ και των διαχειριστών. Ο χρήστης μπορεί
|
||
|
να δεχτεί μια παραγγελία από τους πελάτες του μπαρ από το υπάρχον
|
||
|
μενού ,όπως επίσης έχει την δυνατότητα να ενημερωθεί ή να επιλέξει την
|
||
|
ακύρωση μιας εκκρεμής παραγγελίας ανάλογα με το τι θα ζητηθεί από τους
|
||
|
πελάτες. Ο διαχειριστής του συστήματος έχει όλες τις παραπάνω
|
||
|
δυνατότητες και επιπλέον μπορεί να επεξεργαστεί το μενού του
|
||
|
καταστήματος δηλαδή να προσθέσει η να αναιρέσει συνταγές και υλικά.
|
||
|
|
||
|
Οι παραπάνω λειτουργίες του συστήματος RoboBar εξυπηρετούνται με χρήση
|
||
|
μια βάσης δεδομένων που περιέχει όλα τα απαραίτητα δεδομένα, καθώς και
|
||
|
ενός ρομπότ ΝΑΟ το οποίο εκτελεί τις παραγγελίες των πελατών.
|
||
|
|
||
|
|
||
|
|
||
|
\subsection{Ορισμοί, Ακρωνύμια, Συντομεύσεις}
|
||
|
|
||
|
\begin{itemize}[noitemsep,nolistsep]
|
||
|
\item ΟΑ: Ομάδα Ανάπτυξης
|
||
|
\item GUI: Graphical User Interface (Γραφική Διεπαφή Χρήστη)
|
||
|
\item SQL: Structured Query Language
|
||
|
\item MySQL: Σύστημα διαχείρισης σχεσιακών βάσεων δεδομένων
|
||
|
\item Client: Πελάτης
|
||
|
\item Server: Εξυπηρετητής
|
||
|
\item Client-‐Server: Πελάτης-‐Εξυπηρετητής
|
||
|
\item DB: Βάση Δεδομένων
|
||
|
\item UI: User Interface
|
||
|
\item UML: Unified Modeling Language
|
||
|
\item API: Application Programming Interface
|
||
|
\end{itemize}
|
||
|
|
||
|
|
||
|
\subsection{Τυπογραφικές παραδοχές του εγγράφου}
|
||
|
|
||
|
|
||
|
Το κείμενο του παρόντος εγγράφου είναι γραμμένο με γραμματοσειρά
|
||
|
Baskerville, μεγέθους 11pt και διάστιχο 1.15. Οι επικεφαλίδες του
|
||
|
εγγράφου έχουν μέγεθος 14pt και o τίτλος κάθε κεφαλαίο 13pt σε
|
||
|
γραμματοσειρά Naxos. Οι απαιτήσεις στο κεφάλαιο 2 ονομάζονται και
|
||
|
αριθμούνται κατάλληλα και, επίσης, συντάσσονται με την αρμόζουσα
|
||
|
μορφή.
|
||
|
|
||
|
|
||
|
\subsection{Στόχοι Σχεδίασης}
|
||
|
|
||
|
Στόχος της σχεδίασης του συστήματος είναι η ικανοποίηση των τριών
|
||
|
διαφορετικών ομάδων φυσικών προσώπων που σχετίζονται με αυτό: του
|
||
|
πελάτη, του τελικού χρήστη και του προγραμματιστή
|
||
|
|
||
|
Πελάτης του συστήματος μπορεί να θεωρηθεί ο ιδιοκτήτης μιας εταιρείας
|
||
|
ανάπτυξης, διαχείρισης και πώλησης εφαρμογών ή και κάποιο γραφείο
|
||
|
ευρέσεως εργασίας. Όπως είναι λογικό, ο πελάτης, επιθυμεί το προϊόν να
|
||
|
έχει χαμηλό κόστος, συμβατότητα, , να παρακολουθεί τις λειτουργικές
|
||
|
και μη απαιτήσεις που έχουν τεθεί και η ανάπτυξη του να είναι όσο το
|
||
|
δυνατόν πιο γρήγορη.
|
||
|
|
||
|
Ο τελικός χρήστης επιθυμεί το σύστημα να είναι χρηστικό, φιλικό προς
|
||
|
αυτόν και η διαδικασία εκμάθησής του να είναι απλή, εύκολη και
|
||
|
γρήγορη. Ακόμα, θέλει η λειτουργία του συστήματος να είναι ευσταθής,
|
||
|
να ανέχεται σφάλματα και συνεπώς να είναι αποδοτική.
|
||
|
|
||
|
Επίσης, ο προγραμματιστής του συστήματος, (ή ο συντηρητής) έχει την
|
||
|
απαίτηση, να μην παρουσιάζονται σφάλματα στο σύστημα, να προσαρμόζεται
|
||
|
εύκολα και γρήγορα σε μεταβολές, τροποποιήσεις και αναβαθμίσεις
|
||
|
λογισμικού και ακόμα ο διαχωρισμός των υποσυστημάτων να είναι σωστός
|
||
|
και ορισμένος με σαφήνεια.
|
||
|
|
||
|
|
||
|
\subsection{Αναγνωστικό κοινό και τρόπος ανάγνωσης}
|
||
|
|
||
|
Το έγγραφο αυτό γράφτηκε για συγκεκριμένες ομάδες ανθρώπων προκειμένου
|
||
|
να μελετηθούν και να σχεδιαστούν τα χαρακτηριστικά του συστήματος και
|
||
|
στη συνέχεια να γίνει ο προγραμματισμός και η υλοποίηση της
|
||
|
εφαρμογής. Οι βασικοί αναγνώστες του συγκεκριμένου εγγράφου θα είναι:
|
||
|
\begin{itemize}
|
||
|
\item Προϊστάμενοι καθώς και ορισμένοι αρμόδιοι μηχανικοί
|
||
|
λογισμικού των εταιριών ανάπτυξης ανάλογων εφαρμογών
|
||
|
\item Προγραμματιστές που θα αναλάβουν τη συγγραφή του κώδικα
|
||
|
ο οποίος θα υλοποιεί το σύστημα
|
||
|
\item Μηχανικοί λογισμικού που θα αναλάβουν τη συντήρηση του
|
||
|
συστήματος.
|
||
|
\item Μηχανικοί υλικού που θα αναλάβουν το σχεδιασμό και την
|
||
|
εγκατάσταση των συστημάτων που ικανοποιούν τις τεχνολογικές απαιτήσεις
|
||
|
του έργου
|
||
|
\end{itemize}
|
||
|
|
||
|
Αρχικά, είναι σημαντικό να αναφερθεί ότι για την ευκολότερη κατανόηση
|
||
|
και αποτελεσματική ανάγνωση του έγγραφου αποτελεί σημαντική προϋπόθεση
|
||
|
να έχει προηγηθεί η ανάγνωση των δύο προηγουμένων εγγράφων, αυτού των
|
||
|
απαιτήσεων χρηστών και αυτού των απαιτήσεων λογισμικού.
|
||
|
|
||
|
Επιπροσθέτως, η ανάγνωση των κεφαλαίων θα πρέπει να γίνει με τη σειρά
|
||
|
που υπάρχουν στο έγγραφο για να μη δημιουργηθούν προβλήματα στην
|
||
|
κατανόηση του.
|
||
|
|
||
|
\subsection{Επισκόπηση Εγγράφου}
|
||
|
|
||
|
\begin{itemize}[noitemsep,nolistsep]
|
||
|
\item \textbf{ΚΕΦΑΛΑΙΟ 1}: Το κεφάλαιο αυτό αποτελεί μια
|
||
|
εισαγωγή που περιλαμβάνει γενικές πληροφορίες για το περιεχόμενο του
|
||
|
εγγράφου καθώς και για τα κεφάλαια που ακολουθούν.
|
||
|
\item \textbf{ΚΕΦΑΛΑΙΟ 2}:Στο κεφάλαιο αυτό παρουσιάζεται η
|
||
|
δυναμική μοντελοποίηση του συστήματος Robobar
|
||
|
\item \textbf{ΚΕΦΑΛΑΙΟ 3}: Στο κεφάλαιο αυτό γίνεται αναλυτική
|
||
|
περιγραφή και παρουσίαση της αρχιτεκτονικής του συστήματος .
|
||
|
\item \textbf{ΚΕΦΑΛΑΙΟ 4}:Στο τέταρτο κεφάλαιο γίνεται η
|
||
|
αποδόμηση του συστήματος σε υποσυστήματα, σύμφωνα με την αρχιτεκτονική
|
||
|
που επιλέχθηκε και περιγράφηκε στο τρίτο κεφάλαιο. Επιπλέον
|
||
|
περιλαμβάνει λεπτομερή διαγράμματα της διασύνδεσης μεταξύ των
|
||
|
υποσυστημάτων, ώστε να δοθεί στον αναγνώστη μια πλήρη και παραστατική
|
||
|
εικόνα για την αρχιτεκτονική του συστήματος. Τέλος αναλύονται θέματα
|
||
|
γενικού ελέγχου, ασφάλειας, πρόσβασης και οριακών συνθηκών στα οποία
|
||
|
πρέπει να δοθεί ιδιαίτερη προσοχή.
|
||
|
\end{itemize}
|