html> Αρχιτεκτονική Λογισμικού

Αρχιτεκτονική Λογισμικού


Παναγιώτης Λουρίδας
Τμήμα Διοικητικής Επιστήμης και Τεχνολογίας
Οικονομικό Πανεπιστήμιο Αθηνών

Εισαγωγή

Η αρχιτεκτονική λογισμικού (software architecture) ασχολείται με (Shan and Garlan, 1996):

  • Την οργάνωση του συστήματος ως σύνθεση εξαρτημάτων.

  • Καθολικές δομές ελέγχου.

  • Πρωτόκολλα επικοινωνίας, συγχρονισμού και πρόσβασης σε αποθηκευμένα δεδομένα.

  • Την ευθυγράμμιση των λειτουργιών με τα στοιχεία του σχεδίου.

  • Τη σύνθεση των στοιχείων του σχεδίου.

  • Τη φυσική υλοποίηση του συστήματος.

  • Την απόδοση και την ανταπόκριση σε αυξανόμενες απαιτήσεις (scaling).

  • Τις δυνατότητες εξέλιξης.

  • Την επιλογή μεταξύ εναλλακτικών σχεδίων.

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

Στόχοι της Αρχιτεκτονικής Λογισμικού

  • Η αρχιτεκτονική λογισμικού στοχεύει στον εντοπισμό και την καταγραφή, μέσα από την συσσωρευμένη πείρα των μηχανικών λογισμικού, συγκεκριμένων αρχιτεκτονικών μοτίβων και προτύπων (architectural styles, architectural patterns) που περιγράφουν συστήματα λογισμικού σε υψηλό επίπεδο αφαίρεσης.

  • Στην αρχή του σχεδιασμού ενός συστήματος λογισμικού εντοπίζουμε το αρχιτεκτονικό πρότυπο που ταιριάζει καλύτερα στο σύστημα.

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

  • Καθοδηγούμαστε έτσι ώστε να αποφύγουμε τον καταποντισμό μέσα σε μία θάλασσα αντικειμένων (Brushmann et al., 1996).

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

Η Αρχιτεκτονική ως Βάση της Διεργασίας Ανάπτυξης Λογισμικού

Η αρχιτεκτονική λογισμικού καθοδηγεί τη διεργασία ανάπτυξης λογισμικού:

  • Μετά την ανάλυση των απαιτήσεων επιλέγεται η κατάλληλη για το σύστημα αρχιτεκτονική.

  • Η αρχιτεκτονική αναλύεται και παρουσιάζεται στους εταίρους.

  • Το σύστημα σχεδιάζεται και υλοποιείται σύμφωνα με την αρχιτεκτονική.

  • Επιβεβαιώνεται ότι η υλοποίηση είναι σύμφωνη με την επιλεχθείσα αρχιτεκτονική.

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

Κριτήρια Ποιότητας Αρχιτεκτονικής

Μπορούμε να ξεχωρίσουμε τα παρακάτω κριτήρια ποιότητας μιας αρχιτεκτονικής (Bush et al. 1998):

  • Η αρχιτεκτονική πρέπει να είναι καλά τεκμηριωμένη, με τη χρήση συμβόλων που καταλαβαίνουν όλοι οι εταίροι με την ελάχιστη προσπάθεια.

  • Οι εταίροι πρέπει να επιθεωρήσουν την αρχιτεκτονική.

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

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

  • Η αρχιτεκτονική πρέπει να οδηγεί σε ένα μικρό σύνολο περιορισμών οι οποίοι είναι καταγεγραμμένοι και τεκμηριωμένοι.

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

  • Διαφορετικές ομάδες θα πρέπει να μπορούν να εργαστούν παράλληλα σε διαφορετικά τμήματα της αρχιτεκτονικής.

  • Η αρχιτεκτονική πρέπει να έχει την ελάχιστη δυνατή εξάρτηση από το υλικό.

  • Η αρχιτεκτονική δεν πρέπει ποτέ να εξαρτάται από κάποιο εμπορικό εργαλείο ή προϊόν.

  • Τα τμήματα που παράγουν δεδομένα πρέπει να είναι διαφορετικά από αυτά που καταναλώνουν δεδομένα.

  • Τα σενάρια χρήσης της αρχιτεκτονικής πρέπει να είναι λίγα και απλά.

Υπηρεσιακοστραφής Αρχιτεκτονική

Η υπηρεσιακοστραφής αρχιτεκτονική (service-oriented architecture, SOA) αντιμετωπίζει το λογισμικό ως σύνολο υπηρεσιών. Διακρίνει:

  • Παροχείς υπηρεσιών (service providers)

  • Καταναλωτές (consumers)

  • Κατάλογοι διαθέσιμων υπηρεσιών (registries)

Υπηρεσιακοστραφής Αρχιτεκτονική

Διάγραμμα Ακολουθίας Υπηρεσιακοστραφής Αρχιτεκτονικής

Πλεονεκτήματα

  • Πλήρης διαχωρισμός καταναλωτή-παροχέα.

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

  • Βασίζεται σε ανοιχτά πρότυπα (SOAP, REST, WSDL, UDDI, κ.λπ).

  • Η ανταλλαγή δεδομένων γίνεται με χρήση της XML.

  • Υπάρχουσες υπηρεσίες μπορούν να συνδυάζονται για τη δημιουργία πιο σύνθετων υπηρεσιών και ολόκληρων επιχειρηματικών διαδικασιών.

Μειονεκτήματα

  • Ο ορισμός υπηρεσιών και ο συνδυασμός τους είναι περίπλοκος και τα εμπλεκόμενα πρότυπα πολλά και αλληλοεπικαλυπτόμενα.

  • Μερικές από τις απαραίτητες τεχνολογίες δεν είναι ακόμα έτοιμες

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

  • Η χρήση XML μπορεί να οδηγήσει σε ανταλλαγή τεράστιων όγκων δεδομένων.

Πελάτης-Εξυπηρετητής

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

Κλάσεις Πελάτη-Εξυπηρετητή (προσαρμοσμένο από Buschmann et al., 1996, σ. 326)

Διάγραμμα Ακολουθίας Πελάτη-Εξυπηρετητή (προσαρμοσμένο από Buschmann et al., 1996, σ. 327)

Η αρχιτεκτονική πελάτη-εξυπηρετητή συναντάται σε:

  • Βάσεις δεδομένων

  • Παγκόσμιος Ιστός (World Wide Web)

  • Πληροφοριακά Συστήματα (Information Systems)

Παραλλαγές. 

  • thin client, όπου ο πελάτης είναι υπεύθυνος μόνο για την διεπαφή με τον χρήστη.

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

Πλεονεκτήματα

  • Μεταφερσιμότητα (portability)

  • Απόδοση (performance)

  • Διαχειρισιμότητα (ease of administration)

  • Ικανότητα κλιμάκωσης (scalability)

  • Προσαρμοστικότητα στη διεπαφή με τον χρήστη (user interface flexibility)

  • Αξιοπιστία (reliability)

Μειονεκτήματα

  • Πιθανώς αυξημένες ανάγκες μεταφοράς δεδομένων μέσω δικτύου

  • Προβλήματα λόγω καθυστερήσεων στην μεταφορά δεδομένων

  • Πιθανώς δύσκολο προγραμματιστικό μοντέλο

  • Πιθανώς να απαιτείται επικοινωνία μεταξύ ισότιμων μερών (peer-to-peer)

Αρχιτεκτονικές Πελάτη-Εξυπηρετητή Δύο Επιπέδων

Τα πληροροφιακά συστήματα μέχρι περίπου το 1990 δομούνταν σε δύο επίπεδα (two-tier architecture):

Two-tier architecture

Πλεονεκτήματα

  • Γρήγορη υλοποίηση.

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

  • Κατάλληλο για ομογενή περιβάλλοντα.

Μειονεκτήματα

  • Δεν προσαρμόζεται σε ετερογενή περιβάλλοντα.

  • Οδηγεί σε κλειστές λύσεις, δεμένες με συγκεκριμένο προμηθευτή.

  • Δεν υπάρχει λόγος να επιβαρύνεται ο κάθε πελάτης με την επιχειρησιακή λογική, η οποία είναι ίδια για όλους και θα μπορούσε να εκτελείται από τον εξυπηρετητή.

Αρχιτεκτονικές Πελάτη-Εξυπηρετητή Τριών Επιπέδων

Σήμερα τις περισσότερες φορές τα πληροφοριακά συστήματα δομούνται σε τρία επίπεδα (three-tier architecture):

Three-tier architecture

Διάγραμμα ακολουθίας three-tier architecture

  • Παρουσίαση (presentation layer)

  • Επιχειρηματική λογική (business logic)

  • Βάση δεδομένων (database)

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

Πλεονεκτήματα

  • Ανεξαρτησία διεπαφής από την υπόλοιπη εφαρμογή.

  • Κατάλληλο για ετερογενή περιβάλλοντα (μπορούν να υπάρχουν διαφορετικές διεπαφές για διαφορετικούς χρήστες).

  • Ελαχιστοποιούνται οι απαιτήσεις στον υπολογιστή του χρήστη, καθώς εκτελείται μόνο κώδικας διεπαφής.

  • Καλύτερη διαχείριση πόρων, καθώς μπορεί να καταμεριστεί και η πρόσβαση στα δεδομένα και η επιχειρησιακή λογική.

Μειονεκτήματα

  • Περίπλοκη υλοποίηση.

  • Δεν υπάρχει λόγος να επιβαρύνεται ο κάθε πελάτης με την επιχειρησιακή λογική, η οποία είναι ίδια για όλους και θα μπορούσε να εκτελείται από τον εξυπηρετητή.

  • Αυξημένες ανάγκες μεταφοράς δεδομένων στο δίκτυο.

Αρχιτεκτονικές Πελάτη-Εξυπηρετητή Υπηρεσιών Ιστού

Οι υπηρεσίες ιστού είναι αρχιτεκτονικές πελάτη-εξυπηρετητή στις οποίες:

  • Όλα τα δεδομένα ανταλλάσσονται με τη μορφή XML (SOAP, REST).

  • Για τη μεταφορά των δεδομένων χρησιμοποιούνται πρωτόκολλα του διαδικτύου όπως το HTTP.

  • Η διεπαφή μεταξύ πελάτη-εξυπηρετητή περιγράφεται συνήθως σε διάλεκτο της XML (WSDL).

  • Χρησιμοποιούνται από εταιρείες για την επικοινωνία μεταξύ ετερογενών συστημάτων, όπως και για την επικοινωνία με εξωτερικούς εταίρους (π.χ., Google, Yahoo, Amazon).

Διαστρωμάτωση

Το αρχιτεκτονικό πρότυπο της διαστρωμάτωσης (layers, Buschmann et al., 1996, σ. 31--51) είναι κατάλληλο για τη δόμηση εφαρμογών που μπορούν να αναλυθούν σε ομάδες λειτουργιών όπου η κάθε ομάδα βρίσκεται σε ένα συγκεκριμένο επίπεδο αφαίρεσης.

Three-tier architecture

Το κάθε επίπεδο:

  • Προσφέρει υπηρεσίες στο αμέσως ανώτερο επίπεδο.

  • Χρησιμοποιεί τις υπηρεσίες του αμέσως χαμηλότερου επιπέδου.

Πλεονεκτήματα

  • Επαναχρησιμοποίηση επιπέδων.

  • Υποστήριξη τυποποίησης.

  • Περιορισμός των εξαρτήσεων.

  • Ανταλλαξιμότητα.

Μειονεκτήματα

  • Μετάδοση αλλαγών.

  • Χαμηλότερη απόδοση.

  • Εκτέλεση περιττών εργασιών σε κάποιο επίπεδο.

  • Δυσκολία στον εντοπισμό των σωστών επιπέδων.

Παράδειγμα Υλοποίησης

Ένα παράδειγμα υλοποίησης του προτύπου των πολλαπλών επιπέδων είναι το παρακάτω (προσαρμοσμένο από Buschmann et al., 1996, σ. 42--43):

public abstract class L1Provider {
    public abstract void L1Service();
}

public abstract class L2Provider {
    protected L1Provider level1;
	
    public abstract void L2Service();
    public void setLowerLayer(L1Provider l1) {
        level1 = l1;
    }
}

public abstract class L3Provider {
    protected L2Provider level2;
	
    public abstract void L3Service();
    public void setLowerLayer(L2Provider l2) {
        level2 = l2;
    }
}

public class DataLink extends L1Provider {

    public void L1Service() {
        System.err.println("L1Service doing its job");
    }
}

public class Transport extends L2Provider {
    public void L2Service() {
        System.err.println("L2Service starting its job");
        level1.L1Service();
        System.err.println("L2Service finishing its job");
    }
}

public class Session extends L3Provider{
    public void L3Service() {
        System.err.println("L3Service starting its job");
        level2.L2Service();
        System.err.println("L3Service finishing its job");		
    }
}

public class Network {
    public static void main(String args[]) {
        DataLink dataLink = new DataLink();
        Transport transport = new Transport();
        Session session = new Session();
		
        transport.setLowerLayer(dataLink);
        session.setLowerLayer(transport);
		
        session.L3Service();
    }
}

Το παραπάνω πρόγραμμα θα μας δώσει τα εξής αποτελέσματα:

L3Service starting its job
L2Service starting its job
L1Service doing its job
L2Service finishing its job
L3Service finishing its job

Διαστρωμάτωση: Το Διαδίκτυο

Το διαδίκτυο ακολουθεί την ακόλουθη διαστρωμάτωση:

Τα επίπεδα του διαδικτύου

Λειτουργικά Συστήματα

Τα λειτουργικά συστήματα συχνά δομούνται σύμφωνα με την ακόλουθη διαστρωμάτωση:

  • Εφαρμογές (applications)

  • Φλοιός (shell)

  • Πυρήνας (kernel)

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

Η αρχιτεκτονική του λειτουργικού συστήματος Unix (Bach, 1986, σ. 5)

Ιδεατή μηχανή

Το πρότυπο της ιδεατής μηχανής (virtual machine) είναι μια εφαρμογή του προτύπου των πολλαπλών επιπέδων. Πρόκειται για την υλοποίηση μιας ιδεατής υπολογιστικής μηχανής πάνω σε διάφορες άλλες υπολογιστικές μηχανές, ώστε να μπορεί να χρησιμοποιείται η ίδια προγραμματιστική διεπαφή (Application Programming Interface, API) ανεξαρτήτως του υλικού στο οποίο θα τρέξει.

Σε μία ιδεατή μηχανή βασίζεται η γλώσσα Java:

  • Ο προγραμματιστής χρειάζεται να γνωρίζει μόνο τη γλώσσα Java.

  • Ο μεταγλωττιστής μεταγλωτίζει τα προγράμματα σε μία μορφή ενδιάμεσου κώδικα (bytecodes) που είναι κατανοητή από την ιδεατή μηχανή.

  • Η ιδεατή μηχανή δε γνωρίζει γλώσσα Java, αλλά μόνο τις εντολές του ενδιάμεσου κώδικα.

  • Η ιδεατή μηχανή μεταφράζει τις εντολές του ενδιάμεσου κώδικα στις εντολές της γλώσσας μηχανής της πλατφόρμας στην οποία βρίσκεται.

Αγωγοί και Φίλτρα

Το αρχιτεκτονικό πρότυπο των αγωγών και των φίλτρων (pipes and filters, Buschmann et al., 1996, σ. 53--70) είναι κατάλληλο για τη δόμηση συστημάτων που επεξεργάζονται ροές δεδομένων (streams of data). Τα δεδομένα διασχίζουν αγωγούς περνώντας μέσα από φίλτρα. Οικογένειες συστημάτων μπορούν να χτιστούν συνδυάζοντας φίλτρα.

Το πρότυπο αποτελείται από φίλτρα, αγωγούς, πηγές δεδομένων (data sources) και αποδέκτες δεδομένων (data sinks). Ένα φίλτρο:

  • Παίρνει δεδομένα στην είσοδό του.

  • Επεξεργάζεται τα δεδομένα με κάποιον συγκεκριμένο τρόπο.

  • Δίνει τα δεδομένα στην έξοδό του.

  • Συνεργάζεται με αγωγούς.

Ένας αγωγός:

  • Μεταφέρει δεδομένα.

  • Αποθηκεύει προσωρινά (buffers) δεδομένα.

  • Συγχρονίζει τους ενεργούς γειτονές του.

  • Συνεργάζεται με φίλτρα, πηγές δεδομένων και αποδέκτες δεδομένων.

Μία πηγή δεδομένων:

  • Μεταφέρει δεδομένα σε έναν αγωγό.

Ένας αποδέκτης δεδομένων:

  • Απορροφά δεδομένα εξόδου.

Παραδείγματα

Το πρότυπο αγωγών και φίλτρων έχει χρησιμοποιηθεί, μεταξύ άλλων:

  • Στο λειτουργικό σύστημα UNIX

  • Στην κατασκευή μεταγλωττιστών. Η διαδικασία μεταγλώττισης χωρίζεται στις εξής φάσεις:

    1. Λεκτική ανάλυση

    2. Συντακτική ανάλυση

    3. Σημασιολογική ανάλυση

    4. Βελτιστοποίηση κώδικα

    5. Παραγωγή κώδικα

Παράδειγμα Μεταγλωττιστή (προσαρμοσμένο από Buschmann et al. 2004, σ. 53)

Πρότυπο ώθησης

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

Παράδειγμα Προτύπου Ώθησης (Buschmann et al. 2004, σ. 58)

Πρότυπο έλξης

Στο πρότυπο έλξης (pull) οι αγωγοί ενεργοποιούνται από τον αποδέκτη των δεδομένων.

Παράδειγμα Προτύπου Έλξης (Buschmann et al. 2004, σ. 58)

Παράδειγμα ώθησης/έλξης

Στο πρότυπο ώθησης/έλξης (push/pull) όλα τα φιλτρα είναι ενεργά, τρέχουν σε διαφορετικές διεργασίες ή νήματα και συγχρονίζονται με τη χρήση ενδιάμεσου χώρου αποθήκευσης (buffer).

Παράδειγμα Προτύπου Ώθησης/Έλξης (Buschmann et al. 2004, σ. 59)

Πλεονεκτήματα

  • Δεν χρειάζονται ενδιάμεσα αρχεία.

  • Ευελιξία στη χρήση φίλτρων.

  • Ευελιξία στον συνδυασμό φίλτρων.

  • Επαναχρησιμοποίηση.

  • Γρήγορη υλοποίηση συνδυασμών.

  • Παράλληλη επεξεργασία.

Μειονεκτήματα

  • Δυσκολία στη χρήση δεδομένων που χρησιμοποιούνται από όλα τα βήματα.

  • Η εκμετάλλευση της παραλληλίας δεν είναι πάντα εφικτή.

  • Κόστος μετατροπής δεδομένων.

  • Χειρισμός λαθών.

Μοντέλο-Άποψη-Χειριστής

Το πρότυπο μοντέλου-άποψης-χειριστής (model-view-controller, MVC) χρησιμοποιείται σε εφαρμογές όπου η διεπαφή με το χρήστη έχει ιδιαίτερη σημασία. Το πρότυπο διαιρεί την εφαρμογή σε τρία μέρη.

  • Το μοντέλο περιέχει τη λογική της εφαρμογής και τα δεδομένα.

  • Οι απόψεις παρουσιάζουν την πληροφορία στον χρήστη.

  • Οι χειριστές χειρίζονται την είσοδο του χρήστη.

Χειριστής Σελίδας

Ο χειριστής σελίδας (page controller) χειρίζεται μια αίτηση για μια συγκεκριμένη σελίδα ή λειτουργία σε έναν δικτυακό τόπο (Fowler 2003):

Χειριστής Σελίδας

Το πρότυπο αυτό μπορεί να υλοποιηθεί με τεχνολογία servlets ως εξής:

Υλοποίηση Χειριστή Σελίδας

Χειριστής Πρόσοψης

Ο χειριστής πρόσοψης (front controller) χειρίζεται όλες τις αιτήσεις για έναν δικτυακό τόπο (Fowler 2003):

Χειριστής Πρόσοψης

Ο χειριστής πρόσοχης λειτουργεί με τον ακόλουθο τρόπο:

Χειριστής Πρόσοψης

Το πρότυπο αυτό μπορεί να υλοποιηθεί με τεχνολογία servlets ως εξής:

Υλοποίηση Χειριστή Πρόσοψης

Βιβλιογραφία

Ασκήσεις

  1. Δώστε ένα παράδειγμα εφαρμογής για κάθε ένα από τα δομικά αρχιτεκτονικά πρότυπα που περιγράφηκαν. Αναφέρετε τα πλεονεκτήματα και τα μειονεκτήματά τους.

  2. Περιγράψτε μέ τα κατάλληλα διαγράμματα της UML δύο εναλλακτικούς τρόπους υλοποίησης του ίδιου συστήματος. Αναφέρετε τα συγκριτικά πλεονεκτήματα και μειονεκτήματα κάθε υλοποίησης.

  3. Στη γλώσσα Java η διεπαφή με τον χρήστη υλοποιείται με τη βιβλιοθήκη Swing. Εξετάστε πώς η βιβλιοθήκη υιοθετεί το πρότυπο μοντέλο-άποψης-χειριστή. Σε περίπτωση που δεν γνωρίζετε τη βιβλιοθήκη μπορείτε να βρείτε περισσότερα στοιχεία στο διαδίκτυο (http://java.sun.com/products/jfc/docs.html).

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

    • Ένα σύστημα παρακολούθησης των πόρων μιας εταιρείας. Η εταιρεία αυτή χρησιμοποιεί προγράμματα από διάφορους προμηθευτές. Το ζητούμενο σύστημα θα πρέπει να ανταλλάσει δεδομένα με τα προγράμματα αυτά και να δίνει στον χρήστα μια ολοκληρωμένη εικόνα

    • Το σύστημα παραγγελιών μιας επιχείρησης. Το σύστημα θα πρέπει να παρακολουθεί τα αποθέματα που υπάρχουν και να προχωρά αυτόματα σε παραγγελίες όσων χρειάζονται.

    • Ένα σύστημα αγοραπωλησίας μετοχών. Το σύστημα παρέχει δύο διεπαφές: μία για χρήση μέσα στην εταιρεία που το φιλοξενεί και μία για χρήση μέσω του διαδικτύου.

    • Ένα λειτουργικό σύστημα.

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


Περιεχόμενα