¿Qué es Desarrollo de componentes-Driven?

Question

Componente-Driven Development plazo empieza a ser ampliamente utilizado, esp. en conexión con Inversión de Control.

1. ¿Qué es?
2. ¿Qué problemas soluciona?
3. ¿Cuándo es apropiado y cuándo no?

Answer 1

  

¿Qué es?

Creo que la definición en su respuesta a esta pregunta cubre bien. Aunque, me pregunto por qué la definición incluye un componente que tiene que definir explícitamente sus dependencias. Un ejemplo canónico de un componente es un control ActiveX - hacer que necesitan para definir explícitamente sus dependencias

  

¿Qué problemas soluciona?

Gestión de la complejidad. Se trata de abordar que al permitir que piensen sólo alguna vez acerca de la ejecución del componente. Uno debe necesitar solamente al autor componentes, uno debe no a tener que pensar en cómo combinar o gestionarlos. Esto se hace por algún marco o infraestructura externa al componente, y sin importancia para el autor del componente.

  

¿Cuándo es apropiado y cuándo no?

No es necesariamente apropiado en una aplicación trivial o de usar y tirar. El mal olor en una arquitectura de componentes, es si vas a pasar el tiempo pensando o trabajando en la infraestructura para manejar y combinar componentes, en lugar de los propios componentes.

Answer 2

No estoy seguro de que es una terminología "extendida", pero en VCS (sistema de control de versiones), sé de dos formas de gestionar un conjunto de archivos necesarios para construir un programa:

• enfoque , en el que el conjunto tiene toda una vida en común ciclo y debe ser etiquetado como un todo
• enfoque basado en componentes, donde conjunto individual de archivos tienen su propio ciclo de vida, y donde una etiqueta meta referencias todas las etiquetas de los componentes para designar el todo sistema por la composición y las dependencias entre esos componentes.

La arquitectura aplicativo href="https://stackoverflow.com/questions/704855/software-design-vs-software-architecture/705013#705013"> se utiliza para identificar aquellos componentes:

• dominio funcional y aplicaciones
bibliotecas
• terceros
• marcos

Esto es donde entra en juego COI en, ya que está en la base de cualquier marco. El problema que resuelve es le permiten identificar mejor la parte de la aplicación:
Supongamos que el diseño de una aplicación PLR (pérdidas y ganancias), encargado de calcular la ganancia y pérdidas (posición) de un comerciante.
Se daría cuenta rápidamente que no es una sola aplicación, pero una composición de varios:

• GUI
• lanzador
• despachador (a despachar el cálculo a través de varios servidores, porque uno no tiene suficiente memoria para calcular todos!)
• y así sucesivamente

A continuación, puede identificar un marco de cálculo (COI), que le permita plug-in de sus diferentes módulos, los cuales son llamados en el momento adecuado por su marco.

O puede identificar puramente marcos técnicos (KPI, registros, gestiones de excepciones) que puede ser utilizado por cualquiera de el otro funcional componentes.

En términos de gestión de proyectos, que también le permite desarrollar cada parte de forma independiente, asegurando al mismo tiempo una coordinación a nivel mundial a través de la VCS.

Answer 3

Desarrollo basado en componentes es nada realmente nuevo. No sé de Desarrollo de Componentes-Driven, pero voy a asumir que es CDB. Es la forma en Unix está diseñado, manojo de pequeños programas sustituibles cada uno haciendo una cosa muy bien. En la arena de escritorio, VCL de Delphi ha tenido éxito en el uso de componentes ricos con componentes reutilizables y de terceros al mercado como ningún otro. Ahora estamos viendo la reactivación de la CDB como algunas tecnologías están madurando. Por ejemplo aplicaciones web sencillas están evolucionando para SOA y WS REST. Todos los tipos de Java estado hablando es la modularidad y la COI.

La respuesta que buscas es probable que se encuentra en ¿Por qué y de Inversión de Control de Ke Jin.

  

Además, el imperativo de naturales   estos lenguajes de programación orientados a objetos clásicos   tienden a ver el bosque (de alto nivel   arquitecturas / estructuras) para el   árboles (control lógica de bajo nivel   código de procedimiento). Desarrollo y   ingenieros de mantenimiento que tienen más de una   aplicación existente tiene que depender de   su diseño fuera de fecha / Arquitectura   documentos y código de bajo nivel   comentarios / patrones.

     

El desarrollo basado en componentes (CDB)   paradigma fuerza a las dos cuestiones anteriores   desplazando lógica de fontanería en   marcos que manipulan componentes   y configurar aplicaciones basadas en   usuarios / desarrolladores siempre declarativa   descripciones. Al contrario de lo común   confusión, tales declarativa   descripciones no pretenden ser   scripts de configuración de la aplicación. Más bien,   su intención fundamental es   solicitud expresa de manera explícita   arquitecturas / estructuras sin   ordenando su plomería imperativo   procedimientos (a saber, describen el lo   en lugar de la forma). El objetivo de la CDB   paradigma es apoyar eficaz y   composiciones de aplicación flexibles por   estos marcos y que tiene   los desarrolladores de aplicaciones se centran en   la lógica de negocio y los problemas de dominio   sin importar la fontanería de bajo nivel   complejidades.

     

marcos CDB que combinan la   descripciones de las aplicaciones declarativas   y la técnica de IoC se denominan   como marcos COI. Contrariamente a su   predecesores, los marcos son IoC    no invasiva y utilizar el    dependencia / inyección de configuración / escenario configuración .

De acuerdo a Wikipedia, Desarrollo basado en componentes es un alias para de ingeniería de software basado en componentes (CBSE ) .

  

[Esto] es una rama de software   ingeniería, la prioridad de que es   la separación de las preocupaciones respecto   de la funcionalidad de amplio alcance   disponibles a través de un software determinado   sistema.

Esto es un tanto vaga, por lo que vamos a ver más detalles.

  

Un componente individual es un software   paquete, o un módulo, que   encapsula un conjunto de relacionados   funciones (o datos).

     

Todos los procesos del sistema se colocan en   componentes separados de manera que la totalidad de la   datos y funciones dentro de cada   componente son semánticamente relacionados   (Al igual que con los contenidos de   clases). Debido a este principio,   se dice a menudo que los componentes son    modular y cohesiva .

Por lo tanto, según esta definición, un componente puede ser cualquier cosa, siempre y cuando lo hace una cosa muy bien y sólo una cosa.

  

Con respecto a todo el sistema   coordinación, componentes se comunican   unos con otros a través de Interfaces . [...]   Este principio resulta en los componentes mencionados como encapsulados .

Así que esto suena cada vez más como lo que pensamos de buena API o SOA debe ser similar.

La proporcionado las interfaces están representados por una piruleta y requerida interfaces son represented por un símbolo de socket abierto unido al borde exterior del componente en UML.

_{(fuente: wikimedia. org )}

  

Otro atributo importante de   componentes es que son    sustituibles , de modo que un componente   podría ser sustituido por otro (en   tiempo de diseño o en tiempo de ejecución), si el   requisitos de la componente inicial   (Expresada a través de las interfaces) se cumplen   por el componente sucesor.

     

La reutilización es un importante   característica de una alta calidad   componente de software. Un software   componente debe ser diseñado y   implementado de forma que pueda ser reutilizado   en muchos programas diferentes.

La sustituibilidad y la reutilización es lo que hace que un componente a componente. Entonces, ¿cuál es la diferencia entre este y la programación orientada a objetos?

  

La idea de objeto orientado   programación (POO) es que el software   debe ser escrito según un   modelo mental de lo real o imaginario   objetos que representa. [...]

     

ingeniería de software basado en componentes,   por el contrario, no hace tal   supuestos, y en su lugar establece que   el software debe ser desarrollado por encolado   componentes prefabricados juntos de manera mucho   al igual que en el campo de la electrónica o   mecánica.

Answer 4

Aquí está mi definición después de hacer algunas investigaciones.

Componente-Driven Development es un enfoque en el desarrollo de software de código en el que se encuentra fragmentado en componentes reutilizables y comprobables que se combinan entre sí para formar base de aplicaciones para la entrega de la funcionalidad del negocio. La combinación y la gestión de los componentes generalmente se delega a de control Container.

Un componente en sí es una clase que implementa algunas contrato de servicio y define explícitamente las dependencias que necesita con el fin de cumplir con este contrato. La implementación real se oculta a todos los demás fuera del componente.

Enlaces relacionados:

• Componente-Driven Development y de la COI contenedor

Answer 5

Vista de componentes basada en Ingeniería de Software como un enfoque para el desarrollo de sistemas de software a través de la utilización de componentes conectables; con un componente que es " una unidad de composición con interfaces contractualmente establecidas y el contexto explícito dependencias única ", que " se puede implementar de forma independiente y está sujeto a la composición de terceros ". (Clemens Szyperski, " componente de software: más allá orientado a objetos programación")

CBSE facilita la reutilización de código y rápido montaje de los sistemas de software flexible / adaptables.

Hay una investigación sustancial que se ha centrado en este tema durante años. El evento estrella ( ACM SIGSOFT Simposio sobre Ingeniería de Software basada en Componentes ) está en el 14 º año ahora y hay un buen número de nuevas tendencias emergentes.

Además, si quieres un buen ejemplo de componentes reutilizables, enchufables y extensible, en gran medida en el uso por la industria hoy en día, echar un vistazo a MS Enterprise Library .

Answer 6

Si está interesado en la combinación de los componentes (u otros activos reutilizables) en aplicaciones que también hay que echar un vistazo a la líneas de productos software metodología.

En una línea de producto de software las dependencias entre los componentes (o elementos de código de nivel inferior) están controlados de forma explícita fuera de esos componentes. Esto se realiza normalmente usando un modelo de características que contiene reglas como

• Estos dos componentes no debe utilizarse juntos (exclusividad mutua)
• Si se usa este componente, entonces este otro componente debe ser utilizado o (interdependencia)
• Cualquier combinación de un conjunto especificado de los componentes puede ser utilizado (opcionalidad)

Otras reglas más complejas son posibles dependiendo de la complejidad de las dependencias que desea modelar.

Otro enfoque que se utiliza a veces en lugar de modelado de característica es el uso de un generador de código para configurar los diferentes componentes que están a su montaje en la aplicación final. También es posible combinar el modelado de características con la generación de código.

Además de la generación de código, algunos otros términos es posible que buscar como el modelado de dominio específico, el desarrollo de software dirigido por modelos, familia de software.

Answer 7

Usted nunca va a entender lo que es realmente el Desarrollo Dirigido por componentes, hasta que usted intenta utilizar Unity 3D. No es ActiveX o cualquier cosa que hayas visto antes, lo que has visto antes tiene otro significado componentes.

de desarrollo de componentes-Driven, alrededor de cada uno hablando últimamente, significa, que tiene 2 cosas:

1. Objeto - que es como un objeto en la programación orientada a objetos o un objeto del mundo real
.
2. de objetos componentes -. Que es como parte de la funcionalidad del objeto o de una de sus habilidades de

De este modo: Componente - no es un objeto. Es -. La funcionalidad de un objeto

Por lo tanto, en la programación orientada a objetos estándar, cuando se necesita para extender objeto base con nuevas funcionalidades, lo que tiene que hacer el nuevo objeto derivado por objeto descendiente Base.

En el desarrollo impulsado por componentes, cuando se necesita objeto extendido, que acaba de crear el objeto vacío y lo llena de diferentes componentes, sin ningún tipo de herencia. En el desarrollo impulsado por componentes que no hay clases, hay Prefabs en lugar -. Que es predefinidos Los objetos con componentes predefinidos, siendo los niños objetos

Como he dicho nunca entenderás hasta que usted intente. Con el desarrollo de componentes-drived usted no tiene que utilizar siempre la programación, es posible utilizar editores gráficos en su lugar, y también le libera de la herencia Infierno de programación orientada a objetos típicos. Componentes sí programados con la programación habitual, pero el sistema de nivel superior, incluyendo objetos, en su mayoría sólo tendrá que utilizar y combinar los componentes en el Editor de objetos y recibir un comportamiento personalizado.

Por lo tanto: Componente-Driven Development le ofrece:

1. Gran poder de crear la lógica de su Programm, mediante el uso de sólo un editor, sin necesidad de programación.
2. Libera tu mente de programación orientada a objetos Herencia Infierno. Hace un desarrollo más sencillo y rápido.
3. Hace que su Programm altamente personalizable y escalable sin siquiera tocar el código. Menos errores y errores.
4. Es más fácil mantener el código de su Programm, con sólo la reprogramación de componentes específicos, sin sistema de descanso que tanto efectuar.
5. etc ...

También quiero añadir, que la programación basada en componentes (conducido) no es sustituto de la programación orientada a objetos, es en la cima de programación orientada a objetos o la programación habitual. la programación habitual todavía se utiliza en la CBP para la implementación de bajo nivel de componentes. Creo que este artículo también tienen buena y breve explicación de la CBP: http: //acmantwerp.acm.org/wp-content/uploads/2010/10/componentbasedprogramming.pdf