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

Transcript

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

2 Αρχιτεκτονική Συστήματος Λογισμικού H Αρχιτεκτονική Συστήματος Λογισμικού Ασχολείται με το σχεδιασμό και την υλοποίηση της δομής του λογισμικού σε υψηλό επίπεδο αφαίρεσης Περιγράφει τη γενική στατική δομή του συστήματος, τα βασικά δομικά του στοιχεία, πως αυτά τα στοιχεία επικοινωνούν, και ποια είναι τα βασικά χαρακτηριστικά του κάθε στοιχείου. που ικανοποιούν τις απαιτήσεις λειτουργικότητας και απόδοσης του συστήματος, καθώς και τις μη λειτουργικές απαιτήσεις: αξιοπιστία, κλιμάκωση, μεταφερσιμότητα, διαθεσιμότητα, κλπ Εστιάζει στις βασικές σχεδιαστικές αποφάσεις που λαμβάνονται για ένα σύστημα

3 Ορισμός Αρχιτεκτονικής Σύμφωνα με τους Shaw and Garlan Περιγράφει τα στοιχεία από τα οποία αποτελείται ένα σύστημα (υποσυστήματα/ συστατικά - components) τις αλληλεπιδράσεις ανάμεσα σε αυτά τα στοιχεία, πρότυπα και περιορισμούς που καθοδηγούν τη σύνθεση αυτών των στοιχείων. Ένα σύστημα μπορεί να είναι υποσύστημα σε κάποια άλλη (μεγαλύτερη και πολυπλοκότερη) εφαρμογή Τα υποσυστήματα και τα συστατικά (και συνολικά η αρχιτεκτονική) μπορούν να περιγραφούν από διαφορετικές σκοπιές (π.χ. από λογική, δομική σκοπιά) Σύμφωνα με τον Boehm: Software Architecture = {Elements, Forms, Rationale/Constraints} Άλλοι ορισμοί μπορούν να βρεθούν στον ιστότοπο

4 Τι Προδιαγράφει η Αρχιτεκτονική Τη γενική διάσπαση και κατάτμηση μιας εφαρμογής στα συστατικά δομικά του στοιχεία Η κατάκτηση γίνεται κατά ένα ιεραρχικό τρόπο (υποσυστήματα / ψηφίδες / κλάσεις) Η αρχιτεκτονική μιας εφαρμογής μπορεί να ακολουθεί και να είναι συμβατή με συγκεκριμένες τεχνοτροπίες και πρότυπα Τις σημαντικές ιδιότητες του συστήματος π.χ. απόδοση, ασφάλεια, ευρωστία, ευκολία αναβάθμισης Τις βασικές σχεδιαστικές αποφάσεις που συσχετίζουν απαιτήσεις και υλοποίηση Τον «σκελετό» της εφαρμογής

5 Το 4+1 View Model Αρχιτεκτονικής (1) 4+1 is a view model designed by Philippe Kruchten for describing the architecture of software-intensive systems, based on the use of multiple, concurrent views. The views are used to describe the system from the viewpoint of different stakeholders, such as end-users, developers and project managers. The four views of the model are logical, development, process and physical view. In addition selected use cases or scenarios are used to illustrate the architecture serving as the 'plus one' view. Hence the model contains 4+1 views.

6 Το 4+1 View Model Αρχιτεκτονικής (2)

7 Το 4+1 View Model Αρχιτεκτονικής (3) Logical view : The logical view is concerned with the functionality that the system provides to end-users. UML Diagrams used to represent the logical view include Class diagram, Communication diagram, Sequence diagram. Development view : The development view illustrates a system from a programmer's perspective and is concerned with software management. This view is also known as the implementation view. It uses the UML Component diagram to describe system components. UML Diagrams used to represent the development view include the Package diagram. Process view : deals with the dynamic aspects of the system, explains the system processes and how they communicate, and focuses on the runtime behavior of the system. addresses concurrency, distribution, integrators, performance, and scalability, etc. UML Diagrams to represent process view include the Activity diagram.

8 Το 4+1 View Model Αρχιτεκτονικής (4) Physical view : depicts the system from a system engineer's point of view. It is concerned with the topology of software components on the physical layer, as well as the physical connections between these components. This view is also known as the deployment view. UML Diagrams used to represent physical view include the Deployment diagram. Scenarios : The description of an architecture is illustrated using a small set of use cases, or scenarios which become a fifth view. The scenarios describe sequences of interactions between objects, and between processes. They are used to identify architectural elements and to illustrate and validate the architecture design. as a starting point for tests of an architecture prototype. This view is also known as use case view.

9 Το 4+1 View Model Αρχιτεκτονικής (5) P. Kruchten. The 4+1 View Model of Architecture. In IEEE Software, vol. 12, no. 6, November 1995, pp , IEEE 1995 end-user: functionality (class diagrams, interaction diagrams, statetransition diagrams, etc.) Logical View Use Cases, Scenarios Development View programmers: software management (packages, components, etc.) integrators: performance, scalability (process diagrams, etc.) Process View Physical View system engineers: topology, communications (deployment diagrams, etc.)

10 Αρχιτεκτονική Τεχνοτροπία (Architectural Style) Μια αρχιτεκτονική τεχνοτροπία (architectural style) ορίζει μια οικογένεια από αρχιτεκτονικές που έχουν Κοινή τοπολογία Σημασιολογικούς περιορισμούς Κοινό λεξιλόγιο για τα components και τα connectors

11 Ταξινόμηση Αρχιτεκτονικών Τεχνοτροπιών Βασικές Αρχιτεκτονικές Τεχνοτροπίες Ροής Δεδομένων (Data Flow) Κλήσης-Επιστροφής (Call-and-return) Αλληλεπιδρώντων Λειτουργιών (Interacting processes) Δεδομενο-κεντρικής αποθήκης (Data-oriented repository) Κοινών Δεδομένων (Data-sharing) Ιεραρχικές (Hierarchical) Ετερογενείς Αρχιτεκτονικές (heterogeneous architectures)

12 Αρχιτεκτονική Λογισμικού Με τι ασχολείται - 1 Την οργάνωση του συστήματος ως σύνθεση συστατικών Την ευθυγράμμιση των λειτουργιών με τα συστατικά του σχεδιασμού Τη σύνθεση των συστατικών του σχεδιασμού Καθολικές δομές ελέγχου Πρωτόκολλα επικοινωνίας, συγχρονισμού και πρόσβασης σε αποθηκευμένα δεδομένα Αρχιτεκτονική Λογισμικού

13 Αρχιτεκτονική Λογισμικού Με τι ασχολείται - 2 Τη φυσική υλοποίηση του συστήματος Την απόδοση και την ανταπόκριση σε αυξανόμενες απαιτήσεις (scaling). Τις δυνατότητες εξέλιξης Την επιλογή μεταξύ εναλλακτικών σχεδίων Την περιγραφή του συστήματος ως σύνολο υπολογιστικών συστατικών και συνδέσεων μεταξύ αυτών των συστατικών Αρχιτεκτονική Λογισμικού

14 Αρχιτεκτονική Λογισμικού Τι στόχους έχει και που βοηθάει Την περιγραφή του λογισμικού σε υψηλό επίπεδο αφαίρεσης μέσω συγκεκριμένων αρχιτεκτονικών μοτίβων και προτύπων (architectural styles, architectural patterns) Έναρξη σχεδιασμού: Καθοδηγούμαστε από λύσεις δοκιμασμένες από τον χρόνο και από την πράξη Εντοπίζουμε το αρχιτεκτονικό πρότυπο που ταιριάζει καλύτερα στο σύστημα δεν ανακαλύπτουμε πάλι τον τροχό Αποτελεί Τη βάση της διαδικασίας ανάπτυξης του λογισμικού Το μέσο επικοινωνίας μεταξύ των μηχανικών λογισμικού

15 Αρχιτεκτονική Λογισμικού Βάση της Διεργασίας Ανάπτυξης Λογισμικού Καθοδηγεί τη διεργασία ανάπτυξης λογισμικού: Μετά την ανάλυση των απαιτήσεων επιλέγεται η κατάλληλη για το σύστημα αρχιτεκτονική. Η αρχιτεκτονική αναλύεται και παρουσιάζεται στους εταίρους. Το σύστημα σχεδιάζεται και υλοποιείται σύμφωνα με την αρχιτεκτονική. Επιβεβαιώνεται ότι η υλοποίηση είναι σύμφωνη με την επιλεχθείσα αρχιτεκτονική. Το σύστημα μπορεί να αναλυθεί σε υποσυστήματα με διαφορετική αρχιτεκτονική το καθένα Μπορούν να χρησιμοποιηθούν διάφορες αρχιτεκτονικές σε διαφορετικά επίπεδα αφαίρεσης.

16 Αρχιτεκτονική Λογισμικού Κριτήρια Ποιότητας Καλά τεκμηριωμένη, με χρήση συμβόλων που καταλαβαίνουν όλοι οι εμπλεκόμενοι με την ελάχιστη προσπάθεια Έχει την ελάχιστη δυνατή εξάρτηση από το υλικό. Δεν εξαρτάται από κάποιο εμπορικό εργαλείο ή προϊόν. Περιέχει ποσοτικές μετρικές (π.χ. #δοσοληψιών στη μονάδα του χρόνου) Περιέχει ποιοτικές μετρικές (π.χ. συντηρησιμότητα) Περιέχει ένα μικρό σύνολο περιορισμών οι οποίοι είναι καταγεγραμμένοι και τεκμηριωμένοι. Αποτελείται από καλά ορισμένα τμήματα, ανεξάρτητα που αποκρύπτουν τα εσωτερικά τους χαρακτηριστικά. Επιτρέπει την ανάπτυξη του συστήματος σε βήματα Μπορεί να υλοποιηθεί από πολλές ομάδες που εργάζονται ανεξάρτητα σε διαφορετικά τμήματά της

17 Αρχιτεκτονικά πρότυπα Διαστρωματωμένη αρχιτεκτονική 17

18 Διαστρωματωμένη αρχιτεκτονική 18

19 Χαλαρή Διαστρωμάτωση

20 Πλεονεκτήματα διαστρωμάτωσης Αυξάνεται η συνεκτικότητα του λογισμικού. Κάθε στρώμα παρέχει ένα σύνολο συνεκτικών υπηρεσιών. Μπορούμε να κατανοήσουμε ένα επίπεδο, χωρίς να μας απασχολούν τα υπόλοιπα. Πολλές αλλαγές στο λογισμικό έχουν τοπικό χαρακτήρα. Μπορούμε να υποκαταστήσουμε τις υπηρεσίες ενός στρώματος με κάποια άλλη υλοποίηση. Παρέχονται περισσότερες ευκαιρίες μείωσης της σύζευξης. Διαφορετικές ευθύνες των στρωμάτων καθοδηγούν και τη διανομή της υλοποίησης στην ομάδα ανάπτυξης. Δίνονται περισσότερες ευκαιρίες διανομής των μονάδων λογισμικού σε διαφορετικούς κόμβους επεξεργασίας, υιοθετώντας κατανεμημένες αρχιτεκτονικές. Ένα (χαμηλού επιπέδου) στρώμα μπορεί να επαναχρησιμοποιηθεί σε πολλά διαφορετικά προϊόντα λογισμικού. 20

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

22 Τα τρία στρώματα των πληροφοριακών συστημάτων Στρώμα Στρώμα Παρουσίασης (presentation layer) Στρώμα Λογικής της Εφαρμογής (Application Logic Layer) Στρώμα Διαχείρισης Πόρων (Resource Management Layer) Τι παρέχει/περιέχει Υπηρεσίες που σχετίζονται με την παρουσίαση της πληροφορίας με τις διεπαφές χρήστη Η λογική του πεδίου όπου είναι ο κορμός της λειτουργικότητας του λογισμικού Επικοινωνία με βάσεις δεδομένων ή άλλες πηγές δεδομένων 22

23 Σχεδίαση Πληροφοριακών Συστημάτων (ΠΣ) Σε εννοιολογικό επίπεδο, τα ΠΣ σχεδιάζονται γύρω από τρία στρώματα (layers): Στρώμα Παρουσίασης (presentation layer), Στρώμα Λογικής της Εφαρμογής (Application Logic Layer) και Στρώμα Διαχείρισης Πόρων (Resource Management Layer) Τα στρώματα αυτά μπορεί να είναι μόνο αφαιρετικοί σχεδιασμοί στο μυαλό των σχεδιαστών οι οποίοι παρ όλα αυτά μπορεί να σχεδιάσουν πολύπλοκες υλοποιήσεις για λόγους απόδοσης διακριτά και απομεμονωμένα υποσυστήματα, που συχνά έχουν υλοποιηθεί με διαφορετικά εργαλεία Αρχιτεκτονική Λογισμικού

24 Στρώματα ενός ΠΣ client presentation layer application logic layer resource management layer Client (πελάτης) κάθε χρήστης ή πρόγραμμα το οποίο θέλει να πραγματοποιήσει μία λειτουργία σε ένα σύστημα. Presentation Layer (Στρώμα Παρουσίασης) Διευκολύνει την αλληλεπίδραση των πελατών με το σύστημα Application Logic Layer (Στρώμα λογικής της εφαρμογής) Καθορίζει τι ακριβώς κάνει το σύστημα. Φροντίζει για την εφαρμογή των business rules και εγκαθιδρύει τις business processes. Μπορεί να έχει διάφορες μορφές: προγράμματα, περιορισμοί, business processes, κλπ. Resource Management Layer (Στρώμα Διαχείρισης Πόρων) ασχολείται με την οργάνωση (storage, indexing, και retrieval) των απαραίτητων δεδομένων για την υποστήριξη του πάνω επιπέδου Συνήθως είναι μία βάση δεδομένων Μπορεί να είναι και ένα σύστημα ανάκτησης δεδομένων ή ένα οποιοδήποτε άλλο σύστημα διαχείρισης δεδομένων που παρέχει δυνατότητα επερωτήσεων και persistence. Αρχιτεκτονική Λογισμικού

25 Ένα παιχνίδι με κουτιά και βέλη Δεν υπάρχει πρόβλημα στο σχεδιασμό συστήματος που να μη μπορεί να λυθεί με την προσθήκη ενός ακόμη επιπέδου Δεν υπάρχει πρόβλημα με την απόδοση που να μη μπορεί να λυθεί με την αφαίρεση ενός επιπέδου Κουτί: ένα τμήμα του συστήματος Βέλος: σύνδεση μεταξύ δύο τμημάτων Όσο πιό πολλά κουτιά Τόσο πιό πολύ αρθρωτό (modular) σύστημα Τόσο πιό πολλές δυνατότητες γιά να είναι κατανεμημένο και παράλληλο Υποστηρίζεται η επαναχρησιμοποίηση Όσο πιό πολλά κουτιά και βέλη: Τόσο πιό πολλές συνδέσεις χρειάζεται να συντηρούνται και να συντονίζονται Τόσο πιό πολύπλοκη διαχείριση και παρακολούθηση Τα πολλά κουτιά: Οδηγούν σε μεγάλο αριθμό από context switches και απαιτούμενα ενδιάμεσα βήματα πριν φτάσεις στα δεδομένα Επιδρούν αρνητικά στην απόδοση Χρειάζεται εξισορρόπηση μεταξύ Του αρθρωτού σχεδιασμού Και των απαιτήσεων για απόδοση Οι σχεδιαστές συστημάτων προσπαθούν να συνδυάσουν την ευελιξία του αρθρωτού σχεδιασμού με τις απαιτήσεις απόδοσης των εφαρμογών. Αρχιτεκτονική Λογισμικού

26 1-tier αρχιτεκτονική : πλήρως συγκεντρωτική Οι presentation layer, application logic and resource manager έχουν δημιουργηθεί σαν μία μονολιθική οντότητα Server Χρήστες/προγράμματα προσπελαύνουν το σύστημα μέσω οθονών-τερματικά αλλά το τι εμφανίζεται και το πως ελέγχεται από τον εξυπηρετητή. (Αυτά είναι χαζά τερματικά) Αυτή είναι η τυπική αρχιτεκτονική των mainframes, που προσφέρουν πολλά πλεονεκτήματα: Δεν χρειάζονται context switches στον έλεγχο ροής (όλα συμβαίνουν μέσα στο ίδιο σύστημα), Όλα είναι συγκεντρωμένα, η διαχείριση και ο έλεγχος πόρων είναι πιο εύκολος, η σχεδίαση είναι πλήρως βελτιστοποιημένη κάνοντας αόρατο το διαχωρισμό μεταξύ των επιπέδων. Αρχιτεκτονική Λογισμικού

27 Μειονεκτήματα 1tier αρχιτεκτονικής Μονολιθικά κομμάτια κώδικα Δύσκολη και ακριβή συντήρηση Συνήθως υπάρχει έλειψη τεκμηρίωσης -> αδύνατον να αλλάξει το σύστημα Δύσκολο να κατανοηθεί αρχιτεκτονική του Έλειψη προγραμματιστών με εμπειρία σε αυτά τα συστήματα (legacy systems) Αρχιτεκτονική Λογισμικού

28 2tier Αρχιτεκτονική client presentation layer application logic layer resource management layer Αρχιτεκτονική Λογισμικού

29 2 tier: client/server 2-tier architecture Server Καθώς οι υπολογιστές γίονταν πιο ισχυροί, ήταν εύκολο να μετακινηθεί the presentation layer στον εξυπηρετούμενο. Πλεονεκτήματα: Clients ανεξάρτητοι : μπορεί να υπάρχουν πολλά presentation layers ανάλογα με το τι θέλει να κάνει ο κάθε client. Η υπολογιστική ισχύς της μηχανής μπορεί να εκμεταλλευθεί από τον client για να έχει πιο πολύπλοκα presentation layers (πχ. Χρήστες και διαχειριστές) Έτσι κερδίζει πόρους και ο υπολογιστής του εξυπηρετητή. Eισάγεται η έννοια του API (Application Program Interface). Είναι ένας τρόπος αλληλεπίδρασης με το σύστημα από έξω. The resource manager βλέπει μόνο έναν client: το επίπεδο της επιχειρησιακής λογικής. Αυτό βοηθάει πάρα πολύ την απόδοση αφού δεν υπάρχουν συνδέσεις μεταξύ των clients να διατηρηθούν. Αρχιτεκτονική Λογισμικού

30 API in client/server Tα συστήματα Client/server εισήγαγαν τις έννοιες: service: ο client καλεί ένα service που υλοποιεί ο server service interface: με ποιό τρόπο ο client μπορεί να καλέσει ένα service) Το Application Program Interface (API) είναι όλα μαζί τα service interfaces που παρέχονται από τον server (είτε είναι application-specific είτε system specific). Δηλαδή το ΑPI περιγράφει πως μπορεί κάποιος απ έξω να επικοινωνήσει με τον server. server s API service interface service interface service interface service interface service service service service resource management layer Αρχιτεκτονική Λογισμικού

31 Πλεονεκτήματα 2-tier αρχιτεκτονικής Εκμεταλλεύονται τις δυνατότητες των clients μοιράζοντας φόρτο δουλειάς σε αυτούς. Η εργασία στον εξυπηρετητή λαμβάνει χώρα εντός ενός περιβάλλοντος (σχεδόν όπως στο 1-tier), Η σχεδίαση του εξυπηρετητή παραμένει tightly coupled μπορεί να βελτιστοποιηθεί αγνοώντας τα θέματα παρουσίασης (μιάς και αυτά πάνε στο presentation layer) Εύκολο σχετικά να διαχειριστεί και να ελεγχθεί από άποψη λογισμικού Αρχιτεκτονική Λογισμικού

32 Mειονεκτήματα 2-tier αρχιτεκτονικής Ο εξυπηρετητής έχει να αντιμετωπίσει όλες τις πιθανές συνδέσεις μεταξύ των εξυπηρετούμενων. Ο μέγιστος αριθμός εξυπηρετούμενων δίνεται από τον αριθμό των συνδέσεων που υποστηρίζει ο εξυπηρετητής με αποτέλεσμα να μειώνεται η επεκτασιμότητα της αρχιτεκτονικής. Οι εξυπηρετούμενοι είναι συνδεδεμένοι με το σύστημα αφού δεν υπάρχει συγκεκριμένο presentation layer. Εάν κάποιος θέλει να συνδεθεί με δύο συστήματα χρειάζεται δύο presentation layers. Αυτό συνεπάγεται αύξηση της πολυπλοκότητας του εξυπηρετούμενου. Δεν αντιμετωπίζονται θέματα αποτυχίας του εξυπηρετητή και εξισορρόπησης φορτίου. Εάν ο εξυπηρετητής «πέσει» κανείς δε μπορεί να δουλέψει. Παρόμοια, ο φόρτος που δημιουργήθηκε από τον εξυπηρετούμενο θα επηρεάσει τη δουλειά όλων των υπολοίπων αφού όλοι μοιράζονται τους ίδιους πόρους Αρχιτεκτονική Λογισμικού

33 Βασικός περιορισμός του client/server application logic layer presentation layer 1 resource management layer client application logic presentation layer 2 application logic layer resource management layer Εάν οι εξυπηρετούμενοι θέλουν να προσπελάσουν δύο ή περισσότερους εξυπηρετητές η 2-tier αρχιτεκτονική προκαλεί διάφορα προβλήματα: Τα από κάτω συστήματα δεν γνωρίζονται μεταξύ τους Δεν υπάρχει κοινή business logic Ο client είναι το σημείο της ενοποίησης (increasingly fat clients) Αρχιτεκτονική Λογισμικού Η ευθύνη αντιμετώπισης ετερογενών συστημάτων έχει μεταφερθεί στον εξυπηρετούμενο. Ο εξυπηρετούμενος είναι υπεύθυνος να γνωρίζει που βρίσκονται τα πράγματα, πως να φτάσει σε αυτά και πως να εξασφαλίσει συνέπεια. Αυτό είναι δύσκολο από όλες τις πλευρές (σχεδίαση λογισμικού, μεταφερσιμότητα, επαναχρησιμοποίηση κώδικα, απόδοση αφού οι δυνατότητες του client είναι περιορισμένες κλπ.). Παραμένοντας στο 2 tier μοντέλο δεν υπάρχουν πολλά που μπορούν να γίνουν για να λυθούν τέτοια προβλήματα.

34 3-tier Αρχιτεκτονική Οι 3-tier αρχιτεκτονικές εισάγουν ένα επιπλέον επίπεδο ανάμεσα στον εξυπηρέτη και τον εξυπηρετούμενο. Στο επιπλέον αυτό επίπεδο πραγματοποιείται η ολοκλήρωση των υπηρεσιών από διαφορετικούς εξυπηρετητές μεταφέρεται το application logic layer του πληροφοριακού συστήματος client presentation layer application logic layer middleware resource management layer Αρχιτεκτονική Λογισμικού

35 Middleware clients Middleware or global application logic Local application logic Local resource managers middleware Middleware είναι ένα ενδιάμεσο επίπεδο μεταξύ εξυπηρετούμενων και άλλων επιπέδων του συστήματος. Παρουσιάζει ένα επιπλέον επίπεδο, τη business logic που περικλείει όλα τα υποκείμενα συστήματα. Με αυτό τον τρόπο ένα middleware σύστημα: Απλοποιεί το σχεδιασμό των εξυπηρετούμενων μειώνοντας τον αριθμό των interfaces, Λειτουργεί ως πλατφόρμα για δια-συστημική λειτουργία και υψηλού επιπέδου application logic Φροντίζει για τον εντοπισμό των πόρων, την προσπέλασή τους, και τη συλλογή αποτελεσμάτων (Load balancing, logging, replication, persistence). Αλλά ένα middleware σύστημα είναι σαν ένα οποιοδήποτε άλλο σύστημα! Μπορεί να είναι 1 tier, 2 tier, 3 tier... Server A Server B Αρχιτεκτονική Λογισμικού

36 3 -tier middleware based system External clients External client middleware system internal clients connecting logic control user logic middleware wrappers 2 tier systems Resource managers 2 tier system Resource manager Αρχιτεκτονική Λογισμικού

37 N-tier αρχιτεκτονική: σύνδεση στοweb client Web browser Web server HTML filter application logic layer presentation layer middleware N-tier αρχιτεκτονικές είναι αποτέλεσμα σύνδεσης πολλών 3-tier συστημάτων και προσθέτοντας επιπλέον επίπεδα που να επιτρέπουν στους εξυπηρετούμενους να προσπελαύνουν το σύστημα μέσω ενός Web server Το Web επίπεδο ήταν αρχικά εξωτερικά του συστήματος (πραγματικά επιπλέον επίπεδο). Σήμερα, σταδιακά ενσωματώνεται στο presentation layer που ανήκει στη μεριά του εξυπηρετητή (τμήμα του middleware σε ένα 3-tier σύστημα, ή τμήμα του εξυπηρετητή κατευθείαν σε ένα 2-tier σύστημα) resource management layer Αρχιτεκτονική Λογισμικού

38 N-tier συστήματα σήμερα internal clients LAN middleware application logic LAN INTERNET FIREWALL Web server cluster LAN LAN, gateways Επίπεδο διαχείρισης πόρων database server file server application middleware application logic LAN Επιπλέον επίπεδα Διαχείρισης πόρων Wrappers and gateways LAN Αρχιτεκτονική Λογισμικού