Component-Driven Development El término está comenzando a utilizarse ampliamente, esp. en relación con la Inversión de Control.¿Qué es el desarrollo impulsado por componentes?
¿Qué es?
Creo que la definición en su respuesta cubre bien esta pregunta. Aunque, me pregunto por qué la definición incluye que un componente necesita definir explícitamente sus dependencias. Un ejemplo canónico de un componente es un control ActiveX: ¿necesitan definir explícitamente sus dependencias?
¿Qué problemas soluciona?
Gestión de la complejidad. Busca abordar eso permitiéndole solo pensar en la implementación del componente. Uno solo debe crear componentes, uno debe no para tener que pensar sobre cómo combinarlos o administrarlos. Esto se hace mediante un 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 trival o desechable. El mal olor en una arquitectura de componentes, es si está pasando tiempo pensando o trabajando en la infraestructura para administrar y combinar componentes, en lugar de los componentes mismos.
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:
El applicative architecture se utiliza para identificar aquellos componentes:
Ahí es donde entra COI en, ya que está en la base de cualquier marco. El problema que resuelve le permite identificar mejor la parte de su aplicación:
Supongamos que diseña una aplicación PLR (Ganancia y Pérdida), a cargo de calcular la ganancia y las pérdidas (posición) de un operador.
Usted se da cuenta rápidamente de que no es una sola aplicación, pero una composición de varios:
continuación, se puede identificar un marco de cálculo (COI), que le permita a su plug-in diferentes módulos, que luego son llamados en su momento por su framework.
O puede identificar puramente technical frameworks (KPI, registros, gestiones de excepciones) que puede ser utilizado por cualquiera de sus otros componentes funcionales .
En términos de gestión de proyectos, eso también le permite desarrollar cada parte de forma independiente, mientras asegura una coordinación global a través del VCS.
Aquí está mi definición después de investigar un poco.
Desarrollo Componente-Driven 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 administración de los componentes generalmente se delega en el contenedor Inversion of Control.
Un componente en sí es una clase que implementa algún contrato de servicio y define explícitamente las dependencias que necesita para cumplir este contrato. La implementación real está oculta para todos los demás fuera del componente.
Enlaces relacionados:
Si está interesado en combinar componentes (u otros activos reutilizables) en las aplicaciones, también debe consultar la metodología software product lines.
En una línea de productos de software, las dependencias entre componentes (o elementos de código de nivel inferior) se gestionan explícitamente fuera de esos componentes.Esto normalmente se realiza utilizando un modelo de característica que contiene reglas tales como
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.
Aparte de 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.
El desarrollo basado en componentes no es nada nuevo. No sé de Desarrollo impulsado por componentes, pero voy a suponer que es CBD. Así es como se diseña Unix, un montón de pequeños programas sustituibles, cada uno haciendo una cosa muy bien. En el campo de los escritorios, Delphi's VCL ha tenido éxito en el uso de componentes con componentes reutilizables y de terceros como ningún otro. Ahora estamos viendo la reactivación del CDB ya que algunas tecnologías están madurando. Por ejemplo, las aplicaciones web simples evolucionan hacia SOA y RESTful WS. Todos los chicos de Java han estado hablando sobre modularidad y IoC.
La respuesta que buscas es probable que se encuentra en Why and what of Inversion of Control de Ke Jin.
Además, lo natural imperativo de estos clásicos lenguajes de programación orientado a objetos tienden a perder el bosque (alto nivel arquitecturas/estructuras) para los árboles (control lógico de bajo nivel código de procedimiento). Desarrollo y ingenieros de mantenimiento que se hacen cargo de una aplicación existente tienen que confiar en sus documentos de diseño/arquitectura obsoletos y comentarios/patrones de bajo nivel de código .
El desarrollo basado en componentes (CDB) paradigma fuerza a las dos cuestiones anteriores al cambiar la lógica de plomería en marcos que manipulan componentes y aplicaciones creados en base a usuarios/desarrolladores siempre declarativas descripciones. Contrariamente a la confusión común de , tales descripciones declarativas no son scripts de configuración de aplicación . Más bien, su intención fundamental es aplicación arquitecturas/estructuras explícitamente expresar sin que ordena su plomería imperativo procedimientos (es decir, describir el lo que en lugar de la forma).El objetivo del CDB paradigma es apoyar eficaz y composiciones de aplicaciones flexibles por estos marcos y tener desarrolladores de aplicaciones se centran en lógica de negocio y de dominio cuestiones sin preocuparse de bajo nivel de fontanería complejidades.
marcos CDB que combinan las descripciones de aplicaciones declarativas y la técnica IoC se denominan como marcos COI. Contrariamente a sus predecesores, los marcos IoC son no invasiva y utilizan la inyección dependencia/configuración/ajuste escenario.
De acuerdo con Wikipedia, el desarrollo basado en componentes es un alias para Component-based software engineering (CBSE).
[IT] es una rama de software ingeniería, la prioridad de los cuales es la separación de las preocupaciones respecto de la amplia funcionalidad disponible en todo un sistema de software dado.
Esto es algo vago, así que veamos más detalles.
un componente individual es un paquete de software, o un módulo, que encapsula un conjunto de relacionados funciones (o datos).
Todo sistema de procesos se colocan en componentes separados de manera que todos los datos y funciones dentro de cada componente son semánticamente relacionada (al igual que con el contenido de clases). Debido a este principio, a menudo se dice que los componentes son modular y cohesivo.
De acuerdo con esta definición, un componente puede ser cualquier cosa siempre que haga una cosa realmente bien y solo una cosa.
Con respecto a todo el sistema coordinación, componentes se comunican entre sí a través de interfaces . [...] Este principio da como resultado componentes a los que se hace referencia como encapsulado.
Esto suena cada vez más como lo que pensamos que debería ser una buena API o SOA.
El proporcionan interfaces están representados por una piruleta y requieren interfaces están representados por un símbolo socket abierto unido al borde exterior del componente en UML.
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 los requisitos del componente inicial (expresado a través de las interfaces) se cumplen por el componente sucesor.
La reutilización es una característica importante de un componente de software de alta calidad . Se debe diseñar un componente de software y implementado para que pueda ser reutilizado en muchos programas diferentes.
La capacidad de sustitución y reutilización es lo que hace que un componente sea un componente. ¿Cuál es la diferencia entre esto y la Programación Orientada a Objetos?
La idea en programación orientada a objetos (POO) es que el software debe escribirse de acuerdo con un modelo mental de los reales o imaginarios objetos que representa. [...]
la ingeniería de software basado en componentes, por el contrario, no hace tales supuestos, y en su lugar afirma que el software debe desarrollarse mediante pegado componentes prefabricados juntos de manera mucho como en el campo de la electrónica o mecánica.
Veo la ingeniería de software basada en componentes como un enfoque para desarrollar sistemas de software mediante el uso de componentes conectables; con un componente que es "una unidad de composición con interfaces especificadas contractualmente y dependencias de contexto explícito solo", que "se puede implementar de forma independiente y está sujeto a la composición de terceros". (Clemens Szyperski, "Component software : beyond object-oriented programming")
CBSE facilita la reutilización de código y el montaje rápido de sistemas de software flexibles/adaptables.
Hay una investigación sustancial que se ha centrado en este tema durante años. El evento principal (ACM SIGSOFT Symposium on Component Based Software Engineering) se encuentra en su decimocuarto año y están surgiendo bastantes nuevas tendencias.
Además, si desea un buen ejemplo de componentes reutilizables, conectables y extensibles, muy utilizados por la industria actual, eche un vistazo a MS Enterprise Library.
Nunca entenderá qué es realmente el desarrollo impulsado por componentes, hasta que intente utilizar Unity 3D. No es ActiveX ni nada que hayas visto antes, lo que has visto antes tiene otro significado Componente.
de desarrollo de componentes-Driven, alrededor de cada uno hablando últimamente, significa, que tiene 2 cosas:
Así: Componente - no es un objeto. Es - Funcionalidad de un Objeto.
Por lo tanto, en la programación OOP estándar, cuando necesita extender el Objeto Base con la nueva Funcionalidad, debe crear un Objeto Derivado Heredando Objeto Base.
En el desarrollo impulsado por componentes, cuando necesita objetos extendidos, solo crea objetos vacíos y los llena con diferentes componentes, sin ningún tipo de herencia. En el desarrollo Dirigido por Componente no hay Clases, hay Prefabricados en su lugar - que es Objetos predefinidos con Componentes predefinidos, con Objetos para Niños.
Como dije, nunca entenderás hasta que lo intentes. Con el desarrollo impulsado por componentes, no es necesario utilizar siempre la programación, puede utilizar editores gráficos en su lugar, y también lo libera de Inferancia infernal de OOP típico. Los componentes en sí programados con la programación habitual, pero el sistema de nivel superior, incluidos los objetos, en su mayoría solo necesitan usar y combinar componentes en el Editor y recibir el comportamiento de objetos personalizados.
Por lo tanto: Desarrollo de Componentes-Driven le da:
Yo 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 usa en CBP para la implementación de Componente de bajo nivel. Creo que este artículo también tiene una buena y breve explicación de CBP: http://acmantwerp.acm.org/wp-content/uploads/2010/10/componentbasedprogramming.pdf
Una respuesta agradable, gracias. Estrictamente hablando, los componentes ActiveX son componentes de control que son casi un programa (que podría emplear IoC internamente), mientras que en CDD estamos hablando principalmente de componentes de nivel de clase. Sin embargo, todavía ActiveX tiene algunas dependencias explícitamente definidas, algún tipo de host, sistema operativo Windows. Re-aplicaciones desechables: los prototipos de I + D y arquitectura son aplicaciones desechables, pero me resulta mucho más fácil desarrollar con CDD allí. Depende de la escala, probablemente. –