Che cosa è Guidato da Componente di Sviluppo?

Question

Componente-Driven Development termine inizia ad essere ampiamente utilizzato, esp.in connessione con l'Inversione del Controllo.

1. Che cosa è?
2. Quali problemi risolve?
3. Quando è giusto e quando no?

Answer 1

  

Di cosa si tratta?

Credo che la definizione nella sua risposta copre bene questa domanda. Anche se, mi chiedo il motivo per cui la definizione comprende che un componente deve definire in modo esplicito le sue dipendenze. Un esempio canonico di un componente è un controllo ActiveX -? Hanno bisogno di definire in modo esplicito le loro dipendenze

  

Quali problemi risolve?

Gestione della complessità. Si cerca di affrontare che, consentendo di pensare sempre e solo circa l'attuazione del componente. Si dovrebbe solo bisogno all'autore componenti, si dovrebbe non di dover pensare a come combinare o gestirli. Questo viene fatto da qualche quadro o infrastrutture esterne al componente, e poco importante per l'autore componente.

  

Quando è opportuno e quando no?

Non necessariamente appropriata in un'applicazione banale o getta. Il cattivo odore in un'architettura a componenti, è se si stanno spendendo tempo a pensare o lavorare sulle infrastrutture per gestire e combinare i componenti, piuttosto che i componenti stessi.

Answer 2

Non sono sicuro che si tratta di una terminologia "diffusa", ma in VCS (Version Control System), so di due modi di gestire una serie di file necessari per costruire un programma:

• approccio , dove il tutto insieme ha una vita comune ciclo e deve essere etichettato come un tutto
• approccio basato su componenti, dove insieme individuale di file hanno il loro ciclo di vita, e dove una meta-etichetta riferimenti tutte le etichette dei componenti per designare tutto il sistema per la composizione e le dipendenze tra i componenti.

L'architettura applicativa href="https://stackoverflow.com/questions/704855/software-design-vs-software-architecture/705013#705013"> viene utilizzato per identificare i componenti:

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

E 'qui che entra in gioco CIO, dal momento che è alla base di ogni quadro. Il problema si risolve è consentono di identificare meglio la parte della vostra applicazione:
Si supponga di progettare un PLR (profitti e perdite) di applicazione, in carica per calcolare il guadagno e le perdite (posizione) di un commerciante.
Si potrebbe rapidamente rendersi conto che non è una singola applicazione, ma una composizione di diversi:

• GUI
• launcher
• dispatcher (di spedire il calcolo attraverso diversi server, in quanto uno non dispone di memoria sufficiente per calcolare tutti!)
• e così via

È possibile quindi identificare un quadro di calcolo (IOC) che permetterebbe di plug-nei vostri diversi moduli, che poi sono chiamati al momento giusto per il vostro quadro.

In alternativa, è possibile identificare puramente quadri tecnici (KPI, tronchi, gestioni di eccezione), che può poi essere utilizzato da qualsiasi l'altra funzionale componenti.

In termini di gestione del progetto, che permette anche di sviluppare ogni parte in modo indipendente, assicurando un coordinamento globale attraverso il VCS.

Answer 3

Lo Sviluppo Basato su componenti è nulla di veramente nuovo.Non so di Componente-Driven-Development, ma ho intenzione di assumere è CBD.È come Unix è stato progettato, mazzo di sostituibili piccoli programmi, ognuno fa una cosa molto bene.Nel desktop arena, VCL di Delphi è riuscito utilizzando componenti con funzionalità di componenti riutilizzabili e terzo mercato come nessun altro.Ora stiamo a vedere il rilancio del CBD di alcune tecnologie sono in scadenza.Ad esempio una semplice web app sono in continua evoluzione SOA e Riposante WS.Tutti i Java ragazzi state parlando è la modularità e Cio.

La risposta che stai cercando è probabile che sarà trovato in Perché e che cosa di Inversion of Control da Ke Jin.

Inoltre, l'imperativo naturale di questi classici linguaggi di programmazione OO tendono a perdere la foresta (di alto livello architetture e/o strutture) per il alberi (basso livello di logica di controllo codice procedurale).Sviluppo e i tecnici di manutenzione prendendo più di un applicazione esistente contare su la sua data di uscita di design e architettura documenti e codice di livello basso commenti/modelli.

Il componente di base di sviluppo (CBD) paradigma affronta due problemi di cui sopra spostando idraulico logica in quadri di manipolare i componenti e il set di applicazioni basate su gli utenti/sviluppatori hanno fornito dichiarativa descrizioni.Contraria al comune confusione, ad dichiarativa le descrizioni non sono destinate ad essere applicazione di script di installazione.Piuttosto, il loro intento fondamentale è quello di esprime esplicitamente applicazione architetture e/o strutture senza mandato il loro imperativo idraulico procedure (cioè descrivere la cosa invece il "come").L'obiettivo della CBD paradigma è il supporto di una efficace e applicazione flessibile composizioni questi quadri e avendo gli sviluppatori di applicazioni focus su la logica di business e di dominio problemi senza riguardo a basso livello dell'impianto idraulico complessità.

CBD di quadri di combinare l' dichiarativa applicazione descrizioni e Cio tecnica di cui all' Cio quadri.Contrariamente a loro predecessori, Cio quadri non invasivo e utilizzare il dipendenza/configurazione di iniezione/impostazione scenario.

Secondo Wikipedia, lo Sviluppo Basato su Componenti è un alias per Component-based software engineering (CBSE).

[It] è un ramo di software di ingegneria, la cui priorità è il la separazione delle preoccupazioni nel rispetto un'ampia serie di funzionalità disponibile in un determinato software sistema.

Questo è un po ' vaga, così andiamo a guardare i dettagli.

Un singolo componente è un software pacchetto, o di un modulo, che racchiude in sé una serie di funzioni (o dati).

Tutti i processi di sistema sono inseriti in componenti separati in modo che tutte le dati e funzioni all'interno di ogni componente sono semanticamente correlati (proprio come con il contenuto di classi).A causa di questo principio, si dice spesso che i componenti sono modulare e coesa.

Così, secondo questa definizione, un componente può essere qualsiasi cosa, purché lo fa una cosa bene, solo una cosa.

Per quanto riguarda a livello di sistema di coordinamento, di comunicazione tra componenti con gli altri tramite interfacce.[...] Questo principio risultati in componenti di cui all'come encapsulated.

Quindi, questo suona più come quello che noi pensiamo bene di API o SOA dovrebbe essere simile.

Il fornito le interfacce sono rappresentati da un lecca-lecca e richiesto le interfacce sono rappresentati da un socket aperto simbolo collegato al bordo esterno del componente in UML.

_{(fonte: wikimedia.org)}

Un altro importante attributo di componenti che sono sostituibili, in modo che un componente potrebbe essere sostituito da un altro (a fase di progettazione o in fase di esecuzione), se il requisiti iniziale del componente (espresso tramite le interfacce sono soddisfatte il successore del componente.

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

La sostituibilità e la riutilizzabilità è ciò che rende un componente.Allora, qual è la differenza tra questo e di Programmazione Object-Oriented?

L'idea in object-oriented programmazione a oggetti (OOP) è che il software dovrebbe essere scritto secondo un modello mentale del reale o immaginato gli oggetti che esso rappresenta.[...]

Component-based software engineering, per contro, non fa nessuna ipotesi, e, invece, sostiene che il software deve essere sviluppato mediante incollaggio i componenti prefabbricati insieme molto come nel campo dell'elettronica o la meccanica.

Answer 4

Ecco la mia definizione dopo aver fatto qualche ricerca.

Componente-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 è usualmente delegata di controllo contenitore.

Un componente per sé è una classe che implementa un certo contratto di servizio ed esplicitamente definisce le dipendenze di cui ha bisogno per adempiere il presente contratto. implementazione effettiva è nascosto da tutti gli altri al di fuori del componente.

Link correlati:

• componente Sviluppo-Driven e IOC Container

Answer 5

ho vista Component-Based Software Engineering come un approccio per lo sviluppo di sistemi software attraverso l'utilizzo di componenti pluggable; con un componente essendo " un'unità di composizione con interfacce contrattualmente determinate e contesto esplicito dipendenze solo ", che " può essere implementato in modo indipendente ed è subordinata alla composizione di terze parti ." (Clemens Szyperski, " componenti software: oltre orientata agli oggetti programmazione")

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

C'è una sostanziale ricerca che è stato incentrato su questo argomento per anni. L'evento di punta ( ACM Symposium on Sigsoft Component Based Software Engineering ) si trova nel 14 ° anno ormai e non ci sono un bel paio di nuove tendenze emergenti.

Inoltre, se si vuole un buon esempio di componenti riutilizzabili, pluggable e estensibili, pesantemente in uso da parte dell'industria di oggi, dare un'occhiata a MS Enterprise Library .

Answer 6

Se siete interessati a combinare componenti (o altre attività) riutilizzabili nelle applicazioni si dovrebbe anche dare un'occhiata alla noreferrer linee di prodotti software metodologia.

In una linea di prodotti software le dipendenze tra i componenti (o elementi di codice di livello inferiore) sono esplicitamente gestiti fuori di tali componenti. Questo è in genere fatto utilizzando una funzione di modello di che contiene le regole come ad esempio

• Questi due componenti non deve essere utilizzato insieme (esclusività reciproca)
• Se questo componente viene utilizzato allora questo altro componente deve essere utilizzato o (interdipendenza)
• Qualsiasi combinazione di un insieme di componenti determinata può essere utilizzato (optionality)

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 funzione modellazione è di utilizzare un generatore di codice per configurare le diverse componenti che devono essere assemblati nell'applicazione finale. E 'anche possibile combinare funzionalità di modellazione con la generazione del codice.

A parte la generazione di codice, alcuni altri termini si potrebbe cercare, come la modellazione specifica del dominio, lo sviluppo di software model-driven, famiglia di software.

Answer 7

Lei non potrà mai capire che cosa è veramente Sviluppo Component-Driven, fino a che non tenta di utilizzare Unity 3D. Non è ActiveX o qualsiasi cosa tu mai visto prima, ciò che avete visto prima ha un altro significato dei componenti.

Componente-Driven di sviluppo, su ognuno parla ultimamente, significa, si dispone di 2 cose:

1. Oggetto - che è proprio come un oggetto in programmazione OOP o un oggetto del mondo reale
.
2. del Component Object -. Che è come parte della funzionalità di oggetto o di una delle sue abilità

In questo modo: Componente - non è un oggetto. E '-. Funzionalità di un oggetto

Quindi, nella programmazione OOP normale, quando è necessario estendere oggetto di base con nuove funzionalità, è necessario fare il nuovo oggetto derivato da oggetto che eredita Base.

In sviluppo Component-Driven, quando hai bisogno di oggetto esteso, basta creare vuoto oggetto e lo riempie con diversi componenti, senza alcuna eredità. Nello sviluppo dei componenti-Driven non ci sono classi, v'è Prefabbricati , invece -. Che è oggetti predefiniti con componenti predefiniti, con bambini a oggetti

Come ho detto non si sarà mai a capire fino a che non provi. Con il componente-pilotato sviluppo non dovete usare sempre la programmazione, è possibile utilizzare gli editor grafico, invece, ed inoltre si libera dalla eredità inferno di tipica OOP. Componenti stessa programmati con programmazione usuale, ma sistema di livello superiore, inclusi gli oggetti, per lo più solo bisogno di usare e combinare componenti in Editor e ricevere oggetti comportamento personalizzato.

Quindi: Component-Driven Development ti dà:

1. Gran potere di creare la logica del vostro programma, utilizzando un semplice editor, senza programmazione.
2. libera la mente da OOP Inheritance inferno. Rende sviluppo più semplice e veloce.
3. rende il vostro programma altamente personalizzabile e scalabile senza codice nemmeno toccare. Meno errori e bug.
4. Più facile mantenere il codice del programma, semplicemente riprogrammando componenti specifici, senza sistema di meritato riposo effettuare.
5. ecc ...

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. programmazione di consueto ancora usato in CBP per l'implementazione a basso livello di componente. Penso che questo articolo ha anche una buona e breve spiegazione del CBP: http: //acmantwerp.acm.org/wp-content/uploads/2010/10/componentbasedprogramming.pdf