Ingeniería de software basada en componentes

Un ejemplo de dos componentes expresados ​​en UML 2.0. El componente de pago, responsable de facilitar el pedido del cliente, requiere que el componente de procesamiento de tarjetas cargue la tarjeta de crédito / débito del cliente (funcionalidad que este último proporciona ).

Paradigmas de programación
Acción Orientado al agente Orientado a matrices Basado en autómatas Computación concurrente Programación relativista Basado en datos Declarativo (contraste: imperativo ) Funcional Lógica funcional Puramente funcional Lógica Lógica abductiva Conjunto de respuestas Lógica concurrente Lógica funcional Lógica inductiva Restricción Lógica de restricción Lógica de restricción concurrente Flujo de datos Basado en flujo Reactivo Reactivo funcional Ontología Diferenciable Dinámico / scripting Evento conducido Nivel de función (contraste: nivel de valor ) Estilo sin puntos Concatenativo Genérico Imperativo (contraste: declarativo ) Procesal Orientado a objetos Polimórfico Intencional Orientado al lenguaje Específico de dominio Alfabetizado Programación en lenguaje natural Metaprogramación Automático Programación inductiva reflexivo Orientado a atributos Macro Plantilla No estructurado (contraste: estructurado ) Formación No determinista Computación paralela Orientado al proceso Probabilístico Cuántico Teórico de conjuntos Basado en pila Estructurado (contraste: no estructurado ) Estructurado en bloque Simultaneidad estructurada Orientado a objetos Basado en actores Basado en clases Concurrente Basado en prototipos Por separación de preocupaciones : Orientado a aspectos Orientado a roles Orientado al sujeto Recursivo Simbólico Nivel de valor (contraste: nivel de función )
v t mi

La ingeniería de software basada en componentes ( CBSE ), también llamada desarrollo basado en componentes ( CBD ), es una rama de la ingeniería de software que enfatiza la separación de preocupaciones con respecto a la amplia funcionalidad disponible en un sistema de software dado . Es un enfoque basado en la reutilización para definir, implementar y componer componentes independientes débilmente acoplados en sistemas. Esta práctica tiene como objetivo generar un grado igualmente amplio de beneficios, tanto a corto como a largo plazo, para el software en sí y para las organizaciones que patrocinan dicho software.

Los profesionales de la ingeniería de software consideran los componentes como parte de la plataforma inicial para la orientación al servicio . Los componentes desempeñan este papel, por ejemplo, en los servicios web y, más recientemente, en las arquitecturas orientadas a servicios (SOA), mediante las cuales el servicio web convierte un componente en un servicio y posteriormente hereda características adicionales más allá de las de un componente ordinario.

Los componentes pueden producir o consumir eventos y pueden usarse para arquitecturas controladas por eventos (EDA).

Definición y características de componentes.

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

Todos los procesos del sistema se colocan en componentes separados para que todos los datos y funciones dentro de cada componente estén relacionados semánticamente (al igual que con el contenido de las clases). Debido a este principio, a menudo se dice que los componentes son modulares y cohesivos .

Con respecto a la coordinación de todo el sistema, los componentes se comunican entre sí a través de interfaces . Cuando un componente ofrece servicios al resto del sistema, adopta una interfaz proporcionada que especifica los servicios que pueden utilizar otros componentes y cómo pueden hacerlo. Esta interfaz puede verse como una firma del componente: el cliente no necesita conocer el funcionamiento interno del componente (implementación) para poder utilizarlo. Este principio da como resultado componentes denominados encapsulados . Las ilustraciones UML de este artículo representan interfaces proporcionadas por un símbolo de piruleta adjunto al borde exterior del componente.

Sin embargo, cuando un componente necesita usar otro componente para funcionar, adopta una interfaz usada que especifica los servicios que necesita. En las ilustraciones de UML de este artículo, las interfaces utilizadas están representadas por un símbolo de conector abierto adjunto al borde exterior del componente.

Un ejemplo simple de varios componentes de software, representados dentro de un sistema hipotético de reserva de vacaciones representado en UML 2.0.

Otro atributo importante de los componentes es que son sustituibles , de modo que un componente puede reemplazar a otro (en tiempo de diseño o tiempo de ejecución), si el componente sucesor cumple con los requisitos del componente inicial (expresado a través de las interfaces). En consecuencia, los componentes se pueden reemplazar con una versión actualizada o una alternativa sin romper el sistema en el que opera el componente.

Como regla general para los ingenieros que sustituyen componentes, el componente B puede reemplazar inmediatamente al componente A, si el componente B proporciona al menos el componente A proporcionado y no usa más que el componente A utilizado.

Los componentes de software a menudo toman la forma de objetos (no clases ) o colecciones de objetos (de programación orientada a objetos ), en alguna forma binaria o textual, adhiriéndose a algún lenguaje de descripción de interfaz (IDL) para que el componente pueda existir de forma autónoma de otros componentes en una computadora . En otras palabras, un componente actúa sin cambiar su código fuente. Sin embargo, el comportamiento del código fuente del componente puede cambiar según la extensibilidad de la aplicación, proporcionada por su escritor.

Cuando se debe acceder a un componente o compartirlo a través de contextos de ejecución o enlaces de red, a menudo se emplean técnicas como la serialización o la clasificación para entregar el componente a su destino.

La reutilización es una característica importante de un componente de software de alta calidad. Los programadores deben diseñar e implementar componentes de software de tal manera que muchos programas diferentes puedan reutilizarlos. Además, se deben considerar las pruebas de usabilidad basadas en componentes cuando los componentes de software interactúan directamente con los usuarios.

Se necesita un gran esfuerzo y conciencia para escribir un componente de software que sea efectivamente reutilizable. El componente debe ser:

• completamente documentado
• probado a fondo
  • robusto: con una completa comprobación de la validez de las entradas
  • capaz de devolver mensajes de error o códigos de retorno apropiados
• diseñado con la conciencia de que va a servir para usos imprevistos

En la década de 1960, los programadores construyeron bibliotecas de subrutinas científicas que eran reutilizables en una amplia gama de aplicaciones científicas y de ingeniería. Aunque estas bibliotecas de subrutinas reutilizaban algoritmos bien definidos de manera eficaz, tenían un dominio de aplicación limitado. Los sitios comerciales creaban rutinariamente programas de aplicación a partir de módulos reutilizables escritos en lenguaje ensamblador , COBOL , PL / 1 y otros lenguajes de segunda y tercera generación utilizando bibliotecas de aplicaciones de usuario y del sistema .

A partir de 2010 ^[actualizar], los componentes reutilizables modernos encapsulan tanto las estructuras de datos como los algoritmos que se aplican a las estructuras de datos. La ingeniería de software basada en componentes se basa en teorías anteriores de objetos de software , arquitecturas de software , marcos de software y patrones de diseño de software , y la teoría extensa de la programación orientada a objetos y el diseño orientado a objetos de todos estos. Afirma que los componentes de software, como la idea de componentes de hardware , utilizados por ejemplo en telecomunicaciones, ^[1]en última instancia, puede hacerse intercambiable y fiable. Por otro lado, se argumenta que es un error centrarse en componentes independientes en lugar del marco (sin el cual no existirían). ^[2]

Historia

La idea de que el software debería estar en componentes, construido a partir de componentes prefabricados , se hizo prominente por primera vez con el discurso de Douglas McIlroy en la conferencia de la OTAN sobre ingeniería de software en Garmisch , Alemania , 1968, titulada Componentes de software producidos en masa . ^[3] La conferencia se propuso contrarrestar la llamada crisis del software . La posterior inclusión de McIlroy de tuberías y filtros en el sistema operativo Unix fue la primera implementación de una infraestructura para esta idea.

Brad Cox de Stepstone definió en gran medida el concepto moderno de un componente de software. ^[4] Los llamó CI de software y se propuso crear una infraestructura y un mercado para estos componentes mediante la invención del lenguaje de programación Objective-C . (Resume este punto de vista en su libro Programación orientada a objetos: un enfoque evolutivo 1986.)

Los componentes de software se utilizan en dos contextos diferentes y de dos tipos: i) utilizando componentes como partes para construir un solo ejecutable, o ii) cada ejecutable se trata como un componente en un entorno distribuido, donde los componentes colaboran entre sí a través de Internet o intranet protocolos de comunicación para IPC (Inter Process Communications). Lo anterior pertenece al tipo anterior, mientras que el siguiente pertenece al tipo posterior.

IBM lideró el camino con su Modelo de objetos de sistema (SOM) a principios de la década de 1990. Como reacción, Microsoft allanó el camino para la implementación real de software de componentes con vinculación e incrustación de objetos (OLE) y Modelo de objetos componentes (COM). ^[5] A partir de 2010 ^[actualizar], existen muchos modelos de componentes de software exitosos.

Arquitectura

Una computadora que ejecuta varios componentes de software a menudo se denomina servidor de aplicaciones . Esta combinación de servidores de aplicaciones y componentes de software generalmente se denomina computación distribuida . La aplicación típica de esto en el mundo real es, por ejemplo, aplicaciones financieras o software empresarial.

Modelos de componentes

Un modelo de componentes es una definición de propiedades que los componentes deben satisfacer, métodos y mecanismos para la composición de componentes. ^[6]

Durante las últimas décadas, investigadores y profesionales han propuesto varios modelos de componentes con diferentes características. Se da una clasificación de los modelos de componentes existentes en. ^{[6] [7]} Ejemplos de modelos de componentes son: modelo Enterprise JavaBeans (EJB), modelo de modelo de objeto componente (COM), modelo .NET , modelo de componente X-MAN, ^{[8 ]} y el modelo de componente Common Object Request Broker Architecture (CORBA).

Tecnologias

Esta sección está en formato de lista , pero puede leerse mejor en prosa . Puede ayudar convirtiendo esta sección , si corresponde. La ayuda de edición está disponible. ( Enero de 2020 )

• Tecnologías de objetos comerciales
  • Newi
• Marcos de software basados ​​en componentes para dominios específicos
  • Marco de componentes avanzado
  • Marco de modelado del sistema terrestre ( ESMF )
  • Plataforma MASH IoT para la gestión de activos ^[9]
  • Modelo de componente KOALA desarrollado para software en electrónica de consumo ^{[10] [11]}
  • React (biblioteca de JavaScript)
  • Arquitectura de comunicaciones de software (JTRS SCA)
• Programación orientada a componentes
  • Paquetes según lo definido por la plataforma de servicios OSGi
  • Modelo de objetos componentes (OCX / ActiveX / COM) y DCOM de Microsoft
  • TASCS - Centro SciDAC de tecnología para software de componentes científicos avanzados
  • Lenguaje de programación Eiffel
  • Enterprise JavaBeans de Sun Microsystems (ahora Oracle )
  • Programación basada en flujo
  • Modelo de componente fractal de ObjectWeb
  • Marco de componentes MidCOM para Midgard y PHP
  • Oberon , Component Pascal y BlackBox Component Builder
  • Método rCOS de diseño basado en modelos basado en componentes de UNU-IIST
  • Sistema de componentes SOFA de ObjectWeb
  • El System.ComponentModelespacio de nombres en Microsoft .NET
  • Unity desarrollado por Unity Technologies
  • Unreal Engine desarrollado por Epic Games
  • UNO de la suite ofimática OpenOffice.org
  • VCL y CLX de Borland y una biblioteca LCL gratuita similar .
  • XPCOM de la Fundación Mozilla
• Tecnologías de documentos compuestos
  • Documentos activos en Oberon System y BlackBox Component Builder
  • KParts , la tecnología de documentos compuestos de KDE
  • Vinculación e incrustación de objetos (OLE)
  • Abrir documento
• Componentes de software de computación distribuida
  • .NET Remoting de Microsoft
  • Protocolo distribuido 9P desarrollado para Plan 9 y utilizado por Inferno y otros sistemas.
  • CORBA y el modelo de componentes CORBA del grupo de gestión de objetos
  • D-Bus de la organización freedesktop.org
  • DCOM y versiones posteriores de COM (y COM +) de Microsoft
  • DSOM y SOM de IBM (ahora descartado)
  • Hielo de ZeroC
  • Java EE de Sun
  • Kompics ^[12] de SICS
  • Objetos de red universal (UNO) de OpenOffice.org
  • servicios web
    • DESCANSAR
  • Zope de Zope Corporation
  • AXCIOMA (el marco de componentes para sistemas distribuidos, en tiempo real e integrados) por Remedy IT
  • COHORTE, el tiempo de ejecución multiplataforma para ejecutar y administrar aplicaciones distribuidas basadas en componentes orientadas a servicios, robustas y confiables, de isandlaTech
  • Modelo de servicio DX-MAN ^[13]
• La programación genérica enfatiza la separación de los algoritmos de la representación de datos
• Lenguajes de descripción de interfaz (IDL)
  • Definiciones de interfaz de servicio abierto (OSID)
  • Parte de COM y CORBA
  • Lenguaje de modelado de componentes independiente de la plataforma
  • SIDL - Lenguaje de definición de interfaz científica
    • Parte del Sistema de interoperabilidad del lenguaje de programación científico de Babel (SIDL y Babel son tecnologías centrales de CCA y del Centro SciDAC TASCS; consulte más arriba).
  • SOAP IDL del Consorcio World Wide Web (W3C)
  • WDDX
  • XML-RPC , el predecesor de SOAP
• Marcos de componentes de inversión de control (IoC) y objetos simples de C ++ / Java (POCO / POJO)
• Tubos y filtros
  • Sistema operativo Unix

Ver también

• Lógica de negocios
• Programación modular
• Arquitectura de componentes de servicio (SCA)
• Arquitectura de comunicaciones de software (JTRS SCA)
• Componente de software de terceros
• servicio web
• Componentes web

Referencias

1. Foukalas et al "Reconfiguración de protocolo mediante diseño basado en componentes"
2. Wallace, Bruce (19 de mayo de 2010). "Un agujero para cada componente y cada componente en su agujero" . Programación existencial. No existe tal cosa como un componente
3. McIlroy, Malcolm Douglas (enero de 1969). "Componentes de software de producción masiva" (PDF) . Ingeniería de software: Informe de una conferencia patrocinada por el Comité Científico de la OTAN, Garmisch, Alemania, 7-11 de octubre de 1968 . División de Asuntos Científicos, OTAN. pag. 79.
4. Rainer Niekamp. "Arquitectura de componentes de software" (PDF) . Gestión de Congresos - CIMNE / Instituto de Computación Científica, TU Braunschweig. pag. 4 . Consultado el 29 de julio de 2011 . El concepto moderno de un componente de software definido en gran medida por Brad Cox de Stepstone, => lenguaje de programación Objective-C
5. Raphael Gfeller (9 de diciembre de 2008). "Actualización de la aplicación basada en componentes" . HSR - Hochschule für Technik Rapperswill. pag. 4 . Consultado el 29 de julio de 2011 . 1990, IBM inventa su modelo de objetos de sistema. 1990, como reacción, Microsoft lanzó los controles personalizados OLE 1.0 OLE (OCX)^{[ enlace muerto permanente ]}
6. Crnkovic, I .; Sentilles, S .; Vulgarakis, A .; Chaudron, MRV (2011). "Un marco de clasificación para modelos de componentes de software". Transacciones IEEE sobre ingeniería de software . 37 (5): 593–615. doi : 10.1109 / TSE.2010.83 . S2CID 15449138 . 
7. Lau, Kung-Kiu; Wang, Zheng (2007). "Modelos de componentes de software". Transacciones IEEE sobre ingeniería de software . 33 (10): 709–724. doi : 10.1109 / TSE.2007.70726 . ISSN 0098-5589 . 
8. Lau, Kung-Kiu; Velasco Elizondo, Perla; Wang, Zheng (2005). Heineman, George T .; Crnkovic, Ivica; Schmidt, Heinz W .; Stafford, Judith A .; Szyperski, Clemens; Wallnau, Kurt (eds.). "Conectores exógenos para componentes de software". Ingeniería de software basada en componentes . Apuntes de conferencias en Ciencias de la Computación. Springer Berlín Heidelberg. 3489 : 90-106. doi : 10.1007 / 11424529_7 . ISBN 9783540320494. S2CID  17971442 .
9. MASH define los activos como personas, propiedad e información y la gestión como supervisión, control y configuración. Presentado en la conferencia IEEE IoT de 2013 en Mountain View, MASH incluye un IDE completo, un cliente de Android y un tiempo de ejecución. "Canal de YouTube MASH"
10. Un enfoque orientado a componentes es una forma ideal de manejar la diversidad de software en la electrónica de consumo. El modelo Koala, utilizado para software integrado en televisores, permite la unión tardía de componentes reutilizables sin gastos generales adicionales. [1]
11. Modelo de componente para dispositivos integrados como TV desarrollado por Philips basado en papel por van Ommering, R .: Koala, un modelo de componente para software de productos de electrónica de consumo [2] Archivado 2014-08-09 en Wayback Machine
12. Arad, Cosmin (abril de 2013). Modelo de programación y protocolos para sistemas distribuidos reconfigurables (PDF) . Tesis de Doctorado . Estocolmo, Suecia: KTH Royal Institute of Technology. ISBN  978-91-7501-694-8.
13. Arellanes, Damian; Lau, Kung-Kiu (2017). "Conectores exógenos para la composición de servicios jerárquicos" (PDF) . 2017 IEEE 10th Conference on Service-Oriented Computing and Applications (SOCA) . Kanazawa: IEEE: 125-132. doi : 10.1109 / SOCA.2017.25 . ISBN  9781538613269. S2CID  31211787 .

Otras lecturas

• Brad J. Cox, Andrew J. Novobilski (1991). Programación orientada a objetos: un enfoque evolutivo . 2ª ed. Addison-Wesley, lectura ISBN 0-201-54834-8 
• Bertrand Meyer (1997). Construcción de software orientado a objetos . 2ª ed. Prentice Hall.
• George T. Heineman, William T. Councill (2001). Ingeniería de software basada en componentes: uniendo las piezas . Addison-Wesley Professional, Lectura 2001 ISBN 0-201-70485-4 
• Richard Veryard (2001). Negocio basado en componentes: plug and play . Londres: Springer. ISBN 1-85233-361-8 
• Clemens Szyperski, Dominik Gruntz, Stephan Murer (2002). Software de componentes: más allá de la programación orientada a objetos . 2ª ed. Prensa ACM - Pearson Educational, Londres 2002 ISBN 0-201-74572-0 

enlaces externos

• Por qué ha fallado la reutilización del software y cómo hacer que funcione para usted por Douglas C. Schmidt
• ¿Cuál es la verdadera esencia y realidad del CBD? (La evidencia para demostrar que el paradigma de CBD existente es defectuoso)
• lista completa de sistemas de componentes en SourceForge
• Breve introducción a Real COP (programación orientada a componentes) mediante el uso de una pequeña aplicación GUI como ejemplo