Cos’è lo sviluppo guidato dai componenti?

Il termine di sviluppo basato su componenti sta iniziando a essere ampiamente utilizzato, esp. in connessione con Inversion of Control.

  1. Che cos’è?
  2. Quali problemi risolve?
  3. Quando è appropriato e quando no?

Che cos’è?

Penso che la definizione nella tua risposta risponda bene a questa domanda. Anche se, mi chiedo perché la definizione include che un componente ha bisogno di definire esplicitamente le sue dipendenze. Un esempio canonico di un componente è un controllo ActiveX: hanno bisogno di definire esplicitamente le loro dipendenze?

Quali problemi risolve?

Gestione della complessità. Cerca di affrontare ciò consentendo di pensare sempre e solo all’implementazione del componente. Uno dovrebbe solo avere bisogno di componenti dell’autore, non si deve pensare a come combinarli o gestirli. Questo viene fatto da qualche framework o infrastruttura esterna al componente e non importante per l’autore del componente.

Quando è appropriato e quando no?

Non necessariamente appropriato in un’applicazione trival o throw-away. Il cattivo odore in un’architettura a componenti, è se si sta spendendo tempo a pensare o lavorare sull’infrastruttura per gestire e combinare componenti, piuttosto che i componenti stessi.

Non sono sicuro che sia una terminologia “diffusa”, ma in VCS (Version Control System), conosco due modi per gestire un insieme di file necessari per creare un programma:

  • approccio basato sul sistema , in cui l’insieme ha un ciclo di vita comune e deve essere contrassegnato come un tutto
  • approccio basato su componenti, in cui singoli set di file hanno il proprio ciclo di vita e in cui una meta-etichetta fa riferimento a tutte le etichette dei componenti per designare tutto il sistema per composizione e dipendenze tra tali componenti.

L’ architettura applicativa viene utilizzata per identificare tali componenti:

  • dominio funzionale e applicazioni
  • librerie di terze parti
  • quadri

È qui che entra in gioco IoC, poiché è alla base di qualsiasi struttura. Il problema che risolve ti consente di identificare meglio la parte della tua applicazione:
Supponete di progettare un’applicazione PLR ​​(Profit and Loss), incaricata di calcolare il guadagno e le perdite (posizione) di un trader.
Ti accorgerai presto che non è una singola applicazione, ma una composizione di più:

  • GUI
  • launcher
  • dispatcher (per inviare il calcolo su più server, perché uno non avrebbe memoria sufficiente per calcolare tutto!)
  • e così via

È quindi ansible identificare un framework di calcolo (Ioc) che consente di colbind i diversi moduli, che vengono quindi richiamati al momento giusto dal framework.

Oppure è ansible identificare framework puramente tecnici (KPI, log, gestioni di eccezioni) che possono essere utilizzati da qualsiasi altro componente funzionale .

In termini di gestione del progetto, ciò consente anche di sviluppare ciascuna parte in modo indipendente, garantendo nel contempo un coordinamento globale attraverso il VCS.

Lo sviluppo basato sui componenti non è davvero nuovo. Non conosco lo sviluppo guidato dai componenti, ma assumerò che sia il CBD. È come è progettato Unix, un gruppo di piccoli programmi sostituibili che fanno una cosa molto bene. In ambito desktop, VCL di Delphi ha avuto successo nell’utilizzare componenti con componenti riutilizzabili ricchi e mercati di terze parti come nessun altro. Stiamo assistendo al revival della CBD mentre alcune tecnologie stanno maturando. Ad esempio, le semplici app Web si stanno evolvendo in SOA e RESTful WS. Tutti i ragazzi di Java hanno parlato di modularità e IoC.

La risposta che stai cercando probabilmente sarà trovata in Why e What of Inversion of Control di Ke Jin.

Inoltre, il carattere imperativo di questi classici linguaggi di programmazione OO tende a mancare alla foresta (architetture / strutture di alto livello) per gli alberi (codice procedurale di controllo logico di basso livello). I tecnici di sviluppo e manutenzione che si occupano di un’applicazione esistente devono fare affidamento sui documenti di progettazione / architettura non aggiornati e su commenti / modelli di codice di basso livello.

Il paradigma di sviluppo basato sui componenti (CBD) affronta le due questioni precedenti spostando la logica idraulica in strutture che manipolano componenti e configurano applicazioni basate su utenti / sviluppatori forniti di descrizioni dichiarative. Contrariamente alla confusione comune, tali descrizioni dichiarative non sono intese come script di impostazione dell’applicazione. Piuttosto, la loro intenzione fondamentale è di esprimere esplicitamente architetture / strutture applicative senza imporre le loro imperative procedure idrauliche (cioè descrivere il cosa invece del come). L’objective del paradigma CBD è supportare le composizioni di applicazioni efficaci e flessibili da questi framework e gli sviluppatori di applicazioni si concentrano sulla logica di business e sui problemi di dominio senza riguardo alle complessità di impianto idraulico di basso livello.

I framework CBD che combinano le descrizioni dichiarative delle applicazioni e la tecnica IoC sono indicati come framework IoC. Contrariamente ai loro predecessori, i framework IoC non sono invasivi e utilizzano lo scenario di immissione / impostazione della dipendenza / configurazione .

Secondo Wikipedia, Component-Based Development è un alias per l’ ingegneria del software basata su componenti (CBSE) .

[È] una branca dell’ingegneria del software, la cui priorità è la separazione delle preoccupazioni in relazione alle funzionalità di vasta portata disponibili in un determinato sistema software.

Questo è un po ‘vago, quindi diamo un’occhiata a maggiori dettagli.

Un singolo componente è un pacchetto software o un modulo che incapsula un insieme di funzioni (o dati) correlate.

Tutti i processi di sistema sono collocati in componenti separati in modo che tutti i dati e le funzioni all’interno di ciascun componente siano correlati semanticamente (proprio come con il contenuto delle classi). A causa di questo principio, si dice spesso che i componenti sono modulari e coesi .

Quindi, secondo questa definizione, un componente può essere qualsiasi cosa fintanto che fa una cosa veramente bene e solo una cosa.

Per quanto riguarda il coordinamento a livello di sistema, i componenti comunicano tra loro tramite interfacce . […] Questo principio si traduce in componenti indicati come incapsulati .

Quindi questo suona sempre più simile a quello che pensiamo debba essere una buona API o SOA.

Le interfacce fornite sono rappresentate da un lecca-lecca e le interfacce richieste sono rappresentate da un simbolo di socket aperto collegato al bordo esterno del componente in UML.

alt text http://sofit.miximages.com/inversion-of-control/Component-based_Software_Engineering_(CBSE)_-_example_2.gif

Un altro attributo importante dei componenti è che sono sostituibili , in modo che un componente possa essere sostituito da un altro (in fase di progettazione o di esecuzione), se i requisiti del componente iniziale (espressi tramite le interfacce) sono soddisfatti dal componente successivo.

La riusabilità è una caratteristica importante di un componente software di alta qualità. Un componente software dovrebbe essere progettato e implementato in modo che possa essere riutilizzato in molti programmi diversi.

La sostituibilità e la riusabilità sono ciò che rende un componente un componente. Quindi qual è la differenza tra questa e la programmazione orientata agli oggetti?

L’idea nella programmazione orientata agli oggetti (OOP) è che il software dovrebbe essere scritto secondo un modello mentale degli oggetti reali o immaginati che rappresenta. […]

L’ingegneria del software basata su componenti, al contrario, non fa presupposti del genere e afferma invece che il software dovrebbe essere sviluppato incollando componenti prefabbricati insieme molto come nel campo dell’elettronica o della meccanica.

Ecco la mia definizione dopo aver fatto qualche ricerca.

Lo sviluppo guidato dai componenti è un approccio nello sviluppo di software in cui il codice è frammentato in componenti riutilizzabili e testabili che vengono combinati insieme per formare le basi applicative per fornire funzionalità di business. La combinazione e la gestione dei componenti viene solitamente delegata a Inversion of Control Container.

Un componente stesso è una class che implementa alcuni contratti di servizio e definisce esplicitamente le dipendenze di cui ha bisogno per soddisfare questo contratto. L’implementazione effettiva è nascosta da tutti gli altri al di fuori del componente.

Link correlati:

  • Sviluppo basato su componenti e contenitore IoC

Considero l’ingegneria del software basata su componenti come un approccio allo sviluppo di sistemi software attraverso l’uso di componenti innestabili; con un componente che è ” un’unità di composizione con le interfacce specificate contrattualmente e solo le dipendenze di contesto esplicite “, che ” può essere implementato indipendentemente ed è sobject alla composizione di terze parti “. (Clemens Szyperski, ” Software componente: oltre la programmazione orientata agli oggetti “)

CBSE facilita il riutilizzo del codice e il rapido assemblaggio di sistemi software flessibili / adattabili.

C’è una ricerca sostanziale che è stata incentrata su questo argomento per anni. L’evento di punta ( ACM SIGSOFT Symposium on Component Based Software Engineering ) è giunto al 14 ° anno e ci sono alcune nuove tendenze emergenti.

Inoltre, se si desidera un buon esempio di componenti riutilizzabili, collegabili ed estensibili, ampiamente utilizzati dall’industria oggi, dare un’occhiata a MS Enterprise Library .

Se sei interessato a combinare componenti (o altre risorse riutilizzabili) in applicazioni, dovresti anche dare un’occhiata alla metodologia delle linee di prodotto software .

In una linea di prodotti software le dipendenze tra componenti (o elementi di codice di livello inferiore) vengono gestite esplicitamente al di fuori di tali componenti. In genere ciò viene fatto utilizzando un modello di funzionalità che contiene regole come

  • Queste due componenti non devono essere utilizzate insieme (esclusività reciproca)
  • Se questo componente viene utilizzato, è necessario utilizzare questo altro componente o (interdipendenza)
  • È ansible utilizzare qualsiasi combinazione di alcuni set di componenti specificati (opzionalità)

Altre regole più complesse sono possibili a seconda della complessità delle dipendenze che si desidera modellare.

Un altro approccio che a volte viene utilizzato al posto della modellazione di feature consiste nell’utilizzare un generatore di codice per configurare i diversi componenti che devono essere assemblati nell’applicazione finale. È anche ansible combinare la modellazione delle caratteristiche con la generazione del codice.

A parte la Generazione di codice, alcuni altri termini che è ansible cercare come modellizzazione specifica del dominio, sviluppo di software guidato dal modello, famiglia di software.

Non capirai mai cos’è realmente lo sviluppo guidato dai componenti, fino a quando non proverai a utilizzare Unity 3D. Non è ActiveX o qualsiasi cosa tu abbia mai visto prima, ciò che hai visto prima ha un altro significato di Componente.

Lo sviluppo guidato dai componenti, su tutti quelli che parlano ultimamente, significa che hai 2 cose:

  1. Oggetto – che è proprio come un object nella programmazione OOP o object del mondo reale.
  2. Componente dell’object – che è come parte della funzionalità dell’object o di una delle sue abilità.

Quindi: Componente – non è un Oggetto. È – Funzionalità di un object .

Quindi, nella programmazione OOP standard, quando è necessario estendere Base Object con una nuova funzionalità, è necessario creare un nuovo object derivato ereditando l’object base.

Nello sviluppo basato su componenti, quando hai bisogno di un object esteso, devi solo creare object vuoto e riempirlo con componenti diversi, senza alcuna eredità. Nello sviluppo di Component-Driven non ci sono Classi, c’è invece Prefabs – che è Oggetti predefiniti con Componenti predefiniti, con Oggetti per Bambini.

Come ho detto, non capirai mai fino a quando non ci proverai. Con lo sviluppo basato sui componenti non è necessario utilizzare sempre la programmazione, è ansible utilizzare invece gli editor grafici e inoltre è ansible liberare dall’ineroità ereditaria del tipico OOP. I componenti stessi sono programmati con la normale programmazione, ma i sistemi di livello superiore, inclusi gli oggetti, per lo più devono solo utilizzare e combinare i componenti nell’editor e ricevere il comportamento degli oggetti personalizzati.

Quindi: lo sviluppo guidato dai componenti ti offre:

  1. Grande potenza per creare la logica del tuo programma, utilizzando solo un editor, senza programmazione.
  2. Libera la tua mente dall’inferno dell’eredità OOP. Rende lo sviluppo più semplice e veloce.
  3. Rende il tuo programma altamente personalizzabile e scalabile senza nemmeno toccare il codice. Meno errori e bug.
  4. Più facile mantenere il codice del tuo programma, semplicemente riprogrammando i componenti specifici, senza molto effetto sul sistema di rest.
  5. eccetera…

Voglio anche aggiungere che la programmazione basata su componenti non è sostitutiva della programmazione OOP, è in TOP of OOP o della programmazione abituale. La programmazione usuale è ancora utilizzata nel CBP per l’implementazione di componenti a basso livello. Penso che questo articolo abbia anche una buona e breve spiegazione di CBP: http://acmantwerp.acm.org/wp-content/uploads/2010/10/componentbasedprogramming.pdf