Architettura basata su componenti
L'architettura basata sui componenti si concentra sulla scomposizione del progetto in singoli componenti funzionali o logici che rappresentano interfacce di comunicazione ben definite contenenti metodi, eventi e proprietà. Fornisce un livello più elevato di astrazione e divide il problema in sotto-problemi, ciascuno associato alle partizioni dei componenti.
L'obiettivo principale dell'architettura basata sui componenti è garantire component reusability. Un componente incapsula funzionalità e comportamenti di un elemento software in un'unità binaria riutilizzabile e auto-distribuibile. Esistono molti framework di componenti standard come COM / DCOM, JavaBean, EJB, CORBA, .NET, servizi Web e servizi di griglia. Queste tecnologie sono ampiamente utilizzate nella progettazione di applicazioni GUI desktop locali come componenti JavaBean grafici, componenti MS ActiveX e componenti COM che possono essere riutilizzati semplicemente trascinando e rilasciando.
La progettazione di software orientata ai componenti presenta molti vantaggi rispetto ai tradizionali approcci orientati agli oggetti come:
Riduzione dei tempi di commercializzazione e dei costi di sviluppo grazie al riutilizzo dei componenti esistenti.
Maggiore affidabilità con il riutilizzo dei componenti esistenti.
Cos'è un componente?
Un componente è un insieme di funzionalità ben definite modulare, portatile, sostituibile e riutilizzabile che ne incapsula l'implementazione e lo esporta come interfaccia di livello superiore.
Un componente è un oggetto software, destinato a interagire con altri componenti, incapsulando determinate funzionalità o un insieme di funzionalità. Ha un'interfaccia chiaramente definita e si conforma a un comportamento consigliato comune a tutti i componenti all'interno di un'architettura.
Un componente software può essere definito come un'unità di composizione con un'interfaccia specificata contrattualmente e solo dipendenze di contesto esplicite. Cioè, un componente software può essere distribuito in modo indipendente ed è soggetto a composizione da parte di terzi.
Viste di un componente
Un componente può avere tre diverse visualizzazioni: visualizzazione orientata agli oggetti, visualizzazione convenzionale e visualizzazione relativa al processo.
Object-oriented view
Un componente è visto come un insieme di una o più classi cooperanti. Ogni classe di dominio del problema (analisi) e classe di infrastruttura (progettazione) viene spiegata per identificare tutti gli attributi e le operazioni che si applicano alla sua implementazione. Comporta anche la definizione delle interfacce che consentono alle classi di comunicare e cooperare.
Conventional view
È visto come un elemento funzionale o un modulo di un programma che integra la logica di elaborazione, le strutture dati interne necessarie per implementare la logica di elaborazione e un'interfaccia che consente di richiamare il componente e di passargli i dati.
Process-related view
In questa visualizzazione, invece di creare ogni componente da zero, il sistema sta costruendo da componenti esistenti mantenuti in una libreria. Man mano che viene formulata l'architettura del software, i componenti vengono selezionati dalla libreria e utilizzati per popolare l'architettura.
Un componente dell'interfaccia utente (UI) include griglie, pulsanti denominati controlli e componenti di utilità espongono un sottoinsieme specifico di funzioni utilizzate in altri componenti.
Altri tipi comuni di componenti sono quelli a uso intensivo di risorse, a cui non si accede frequentemente e che devono essere attivati utilizzando l'approccio just-in-time (JIT).
Molti componenti sono invisibili e vengono distribuiti in applicazioni aziendali aziendali e applicazioni Web Internet come Enterprise JavaBean (EJB), componenti .NET e componenti CORBA.
Caratteristiche dei componenti
Reusability- I componenti sono generalmente progettati per essere riutilizzati in diverse situazioni in diverse applicazioni. Tuttavia, alcuni componenti possono essere progettati per un'attività specifica.
Replaceable - I componenti possono essere liberamente sostituiti con altri componenti simili.
Not context specific - I componenti sono progettati per funzionare in ambienti e contesti diversi.
Extensible - Un componente può essere esteso da componenti esistenti per fornire un nuovo comportamento.
Encapsulated - Il componente AA rappresenta le interfacce, che consentono al chiamante di utilizzare la sua funzionalità e non espone i dettagli dei processi interni o eventuali variabili interne o stato.
Independent - I componenti sono progettati per avere dipendenze minime da altri componenti.
Principi di progettazione basata sui componenti
Un progetto a livello di componente può essere rappresentato utilizzando una rappresentazione intermedia (ad esempio grafica, tabellare o basata su testo) che può essere tradotta in codice sorgente. La progettazione di strutture di dati, interfacce e algoritmi dovrebbe essere conforme a linee guida consolidate per aiutarci a evitare l'introduzione di errori.
Il sistema software è scomposto in unità componenti riutilizzabili, coesive e incapsulate.
Ogni componente ha la propria interfaccia che specifica le porte richieste e le porte fornite; ogni componente nasconde la sua implementazione dettagliata.
Un componente dovrebbe essere esteso senza la necessità di apportare modifiche al codice interno o alla progettazione delle parti esistenti del componente.
La componente dipendono dalle astrazioni non dipendono da altre componenti concrete, che aumentano la difficoltà di spendibilità.
Connettori collegati componenti, specificando e regolando l'interazione tra i componenti. Il tipo di interazione è specificato dalle interfacce dei componenti.
L'interazione dei componenti può assumere la forma di invocazioni di metodi, invocazioni asincrone, trasmissione, interazioni guidate da messaggi, comunicazioni di flussi di dati e altre interazioni specifiche del protocollo.
Per una classe server, è necessario creare interfacce specializzate per servire le principali categorie di client. Nell'interfaccia devono essere specificate solo le operazioni rilevanti per una particolare categoria di client.
Un componente può estendersi ad altri componenti e offrire ancora i propri punti di estensione. È il concetto di architettura basata su plug-in. Ciò consente a un plug-in di offrire un'altra API del plug-in.
Linee guida per la progettazione a livello di componente
Crea convenzioni di denominazione per i componenti specificati come parte del modello architettonico e quindi perfeziona o elabora come parte del modello a livello di componente.
Ottiene i nomi dei componenti architettonici dal dominio del problema e garantisce che abbiano un significato per tutte le parti interessate che visualizzano il modello architettonico.
Estrae le entità del processo aziendale che possono esistere indipendentemente senza alcuna dipendenza associata da altre entità.
Riconosce e scopre queste entità indipendenti come nuovi componenti.
Utilizza nomi dei componenti dell'infrastruttura che riflettono il loro significato specifico dell'implementazione.
Modella le dipendenze da sinistra a destra e l'ereditarietà dall'alto (classe base) verso il basso (classi derivate).
Modella le dipendenze dei componenti come interfacce piuttosto che rappresentarle come una dipendenza diretta da componente a componente.
Conduzione della progettazione a livello di componente
Riconosce tutte le classi di progettazione che corrispondono al dominio del problema come definito nel modello di analisi e nel modello architettonico.
Riconosce tutte le classi di progettazione che corrispondono al dominio dell'infrastruttura.
Descrive tutte le classi di progettazione che non vengono acquisite come componenti riutilizzabili e specifica i dettagli del messaggio.
Identifica le interfacce appropriate per ogni componente ed elabora gli attributi e definisce i tipi di dati e le strutture dati necessarie per implementarli.
Descrive dettagliatamente il flusso di elaborazione all'interno di ciascuna operazione mediante pseudo codice o diagrammi di attività UML.
Descrive le origini dati persistenti (database e file) e identifica le classi richieste per gestirle.
Sviluppa ed elabora rappresentazioni comportamentali per una classe o un componente. Ciò può essere fatto elaborando i diagrammi di stato UML creati per il modello di analisi ed esaminando tutti i casi d'uso rilevanti per la classe di progettazione.
Elabora diagrammi di distribuzione per fornire ulteriori dettagli di implementazione.
Dimostra l'ubicazione di pacchetti chiave o classi di componenti in un sistema utilizzando istanze di classe e designando hardware e ambiente del sistema operativo specifici.
La decisione finale può essere presa utilizzando principi e linee guida di progettazione consolidati. I progettisti esperti considerano tutte (o la maggior parte) delle soluzioni di design alternative prima di stabilirsi sul modello di progettazione finale.
Vantaggi
Ease of deployment - Man mano che nuove versioni compatibili diventano disponibili, è più facile sostituire le versioni esistenti senza alcun impatto sugli altri componenti o sul sistema nel suo insieme.
Reduced cost - L'utilizzo di componenti di terze parti consente di ripartire i costi di sviluppo e manutenzione.
Ease of development - I componenti implementano interfacce ben note per fornire funzionalità definite, consentendo lo sviluppo senza influire su altre parti del sistema.
Reusable - L'uso di componenti riutilizzabili significa che possono essere utilizzati per distribuire i costi di sviluppo e manutenzione su diverse applicazioni o sistemi.
Modification of technical complexity - Un componente modifica la complessità attraverso l'uso di un contenitore di componenti e dei suoi servizi.
Reliability - L'affidabilità complessiva del sistema aumenta poiché l'affidabilità di ogni singolo componente aumenta l'affidabilità dell'intero sistema tramite il riutilizzo.
System maintenance and evolution - Facile da modificare e aggiornare l'implementazione senza influire sul resto del sistema.
Independent- Indipendenza e connettività flessibile dei componenti. Sviluppo indipendente di componenti da diversi gruppi in parallelo. Produttività per lo sviluppo del software e lo sviluppo futuro del software.