Sviluppo basato su componenti termine sta iniziando a essere ampiamente utilizzato, esp. in connessione con Inversion of Control.Che cos'è lo sviluppo guidato dai componenti?
cosa si tratta?
Penso che la definizione nella 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 bisogno di componenti autore, uno dovrebbe non a dover 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.
io non sono sicuro che è una terminologia "diffusa", ma in VCS (Version Control System), so di due modi di gestire una serie di file necessari per costruire un programma:
Il applicative architecture viene utilizzato per identificare i componenti:
Questo è dove IoC entra in gioco, dal momento che è alla base di qualsiasi quadro. Il problema che risolve ti consente di identificare meglio la parte della tua applicazione:
Supponi di progettare un'applicazione PLR (Profit and Loss), incaricata di calcolare il guadagno e le perdite (posizione) di un trader.
Si potrebbe rapidamente rendersi conto che non è una singola applicazione, ma una composizione di molteplici:
È possibile quindi identificare un quadro di calcolo (IOC) che permetterebbe di plug-in diversi moduli, che vengono quindi chiamati al momento giusto dal tuo framework.
Oppure è possibile identificare semplicemente technical frameworks (KPI, registri, gestioni di eccezioni) che possono quindi essere utilizzati da qualsiasi altro componente funzionale funzionante.
In termini di gestione del progetto, ciò consente anche di sviluppare ciascuna parte in modo indipendente, garantendo nel contempo un coordinamento globale tramite VCS.
Ecco la mia definizione dopo aver fatto qualche ricerca.
Component-Driven Development è un approccio nello sviluppo di software in cui il codice è frammentato in componenti riutilizzabili e testabili che vengono combinati insieme per formare Application Foundation per la fornitura di funzionalità di business. La combinazione e la gestione dei componenti viene solitamente delegata al contenitore Inversion of Control.
Un componente è una classe 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:
Se sei interessato a combinare componenti (o altre risorse riutilizzabili) in applicazioni, devi anche dare un'occhiata alla metodologia software product lines.
In una linea di prodotti software le dipendenze tra componenti (o elementi di codice di livello inferiore) vengono gestite esplicitamente all'esterno di tali componenti.Ciò avviene tipicamente utilizzando un modello caratteristica contenente regole come
Altre regole più complesse sono possibili a seconda della complessità delle dipendenze che si desidera modellare.
Un altro approccio che viene talvolta utilizzato al posto della modellazione di funzioni consiste nell'utilizzare un generatore di codice per configurare i diversi componenti che devono essere assemblati nell'applicazione finale. È anche possibile combinare la modellazione delle caratteristiche con la generazione del codice.
Oltre alla generazione del codice, alcuni altri termini che è possibile cercare come modellazione specifica del dominio, sviluppo di software basato su modelli, famiglia di software.
Lo sviluppo basato sui componenti non è una novità. 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 sarà trovata in Why and what of Inversion of Control da Ke Jin.
Inoltre, il naturale imperativo di questi classici linguaggi di programmazione OO tendono a perdere la foresta (di alto livello architetture/strutture) per le alberi (basso livello di controllo logico Codice di procedura). Sviluppo e Gli ingegneri addetti alla manutenzione che si occupano di un'applicazione esistente devono affidarsi a documenti di progettazione/architettura non aggiornati e codice/codice a basso livello commenti/modelli.
Lo sviluppo basato su componenti (CBD) paradigma affronta i due problemi sopra spostando logica idraulici in quadri che manipolano componenti e applicazioni istituiti basato su utenti/sviluppatori forniti dichiarativa descrizioni. Contrariamente alla comune confusione di , tali descrizioni dichiarative non devono essere intese come script di installazione dell'applicazione . Piuttosto, la loro intenzione fondamentale è quello di esplicitamente Express Application architetture e/o strutture senza mandato il loro impianto idraulico imperativo procedure (vale a dire descrivere la cosa anziché il come).L'obiettivo della CBD paradigma è quello di sostenere efficace e composizioni applicative flessibili di questi quadri e avendo sviluppatori di applicazioni concentrarsi sulla logica di business e dominio problemi senza preoccuparsi di basso livello idraulico complessità.
quadri CBD che combinano le descrizioni delle applicazioni dichiarative e la tecnica IoC sono indicati come quadri CIO. Contrariamente ai loro predecessori , strutture IoC sono non invasiva e utilizzare l'iniezione dipendenza/configurazione/impostazione scenario.
Secondo Wikipedia, Component-Based Development è uno pseudonimo per Component-based software engineering (CBSE).
[E] è un ramo di software ingegneria, la cui priorità è la separazione degli interessi rispetto della ampia funzionalità disponibili durante un dato 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 correlati funzioni (o dati).
Tutto il sistema processi sono inseriti in componenti separati in modo che tutti i dati e le funzioni all'interno di ogni componente sono semanticamente corrispondenti (proprio come con il contenuto della classi). A causa di questo principio, si dice spesso che i componenti sono modulare e coesivo.
Quindi, secondo questa definizione, un componente può essere qualsiasi cosa purché faccia una cosa veramente bene e solo una cosa.
quanto riguarda livello di sistema coordinamento, componenti comunicano tra loro tramite interfacce . [...] Questo principio comporta componenti denominati incapsulati.
Quindi questo suona sempre più simile a quello che pensiamo debba essere una buona API o SOA.
Il disponibile interfacce sono rappresentati da un lecca-lecca e tenuti interfacce sono rappresentati dal simbolo socket aperto fissato al bordo esterno del componente in UML.
Un'altra caratteristica importante componenti è che sono sostituibili, in modo che un componente potrebbe essere sostituito da un altro (in fase di progettazione o run-time), se il I requisiti del componente iniziale (espressi tramite le interfacce) sono soddisfatti dal componente successivo.
La riutilizzabilità è un'importante caratteristica di di un componente software di alta qualità . Un componente software deve essere progettato e implementato in in modo che possa essere riutilizzato in molti programmi diversi.
Sostituibilità e riusabilità è ciò che rende un componente un componente. Quindi qual è la differenza tra questa e la programmazione orientata agli oggetti?
L'idea orientata agli oggetti programmazione (OOP) è che il software dovrebbe essere scritto secondo un modello mentale delle reali o immaginari oggetti che rappresenta. [...]
Component-based software engineering, al contrario, rende tali ipotesi, e invece afferma che il software dovrebbe essere sviluppata incollando componenti prefabbricati insieme molto come nel campo dell'elettronica o meccanica.
Vedo l'ingegneria del software basata su componenti come approccio allo sviluppo di sistemi software attraverso l'uso di componenti collegabili; con un componente "un'unità di composizione con interfacce specificate dal contratto e dipendenze di contesto esplicite solo", che "può essere distribuito indipendentemente ed è soggetto alla composizione di terze parti". (Clemens Szyperski, "Component software : beyond object-oriented programming")
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) è nel quattordicesimo 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.
Non capirai mai cos'è realmente lo sviluppo basato su 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.
Component-Driven di sviluppo, su ognuno parla ultimamente, significa, si dispone di 2 cose:
Così: Componente: non è un oggetto. È - Funzionalità di un oggetto.
Quindi, nella programmazione OOP standard, quando è necessario estendere Base Object con una nuova funzionalità, è necessario creare un nuovo oggetto derivato ereditando l'oggetto base.
Nello sviluppo basato su componenti, quando è necessario un oggetto esteso, basta creare oggetto vuoto e riempirlo con componenti diversi, senza alcuna eredità. Nello sviluppo di Component-Driven non ci sono Classi, ci sono invece le Prefabbricati - che sono gli Oggetti predefiniti con Componenti predefiniti, con Oggetti 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, è possibile utilizzare invece gli editor grafici e inoltre è possibile 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.
Così: Sviluppo Component-Driven ti dà:
voglio anche aggiungere che Component-based (guidata) la programmazione non è la sostituzione per la programmazione OOP, è sulla parte superiore della programmazione orientata agli oggetti o di programmazione al solito. 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 del CBP: http://acmantwerp.acm.org/wp-content/uploads/2010/10/componentbasedprogramming.pdf
Bella risposta, grazie. I componenti ActiveX in senso stretto sono componenti di controllo che sono quasi un programma (che potrebbe utilizzare IoC internamente), mentre nel CDD stiamo parlando principalmente di componenti di livello di classe. Ancora, ActiveX ha alcune dipendenze definite in modo esplicito - una sorta di host, sistema operativo Windows. Applicazioni re-throw-away: i prototipi di ricerca e sviluppo e architettura sono un'applicazione da buttare via, tuttavia trovo che sia molto più facile sviluppare con CDD lì. Dipende probabilmente dalla scala. –