Programación orientada a Componentes

1. Programaciónorientada a Componentes Rosemary TorricoBascopé

2. Introducción • El uso de componentesesmaduro en muchasdisciplinas de ingeniería. • En el ambito del software, recien se tieneexito en suuso a partir del 1990 • Las razones del fracaso se puedenatribuir a la naturaleza del SW.

3. Naturaleza del SW • Los componentes de software fueron inicialmente considerados similares a los componentes de hardware, como los circuitos integrados. • Así, el término ''Circuito integrado de software'' se volvió fascinante. • También se hicieron analogías de este tipo en la mecánica y la ingeniería civil. • El software es diferente a los productos de todas las demás disciplinas de ingeniería. En lugar de entregar un producto final, la entrega de software significa la entrega de modelos para los productos.

4. Los componentes son paracomposición • La composicionpermitereusar “cosasprefabricadas” adaptandolas en el nuevoambiente. • Componentes de software • Son unidades ejecutables de producción independientes. • Abstracciones, tales como procedimientos, clases, módulos o aplicaciones, podrían formar componentes, siempre y cuando estén en una forma ejecutable susceptible de ser un componente. • Las bibliotecas procedurales son el ejemplo más antiguo de los componentes de software • Independencia y forma ejecutable son esenciales con el fin de permitir el desarrollo independiente y la integración robusta.

5. Porquéproducir, comprar, distribuir, usar… componentes de SW? • Los componentes son el camino a seguir porque todas las disciplinas de ingeniería introdujeron componentes a medida que fueron madurando - y todavía los utilizan. • Poco después de la crisis del software se acuñó el término, fue previsto también: software de circuitos integrados (McIlroy 1968; Cox 1990) Desde entonces, hace 30 años, las personas han preguntado por qué este idea intuitiva realmente nunca llegó a realizarse.

6. Beneficios • El desarrollo de software tradicional pueden dividirse en dos campos. • En un extremo, un proyecto desarrollado íntegramente desde cero (línea por línea), con la ayuda sólo de herramientas de programación y bibliotecas. • En el otro extremo, todo es "Externalizado" - en otras palabras, el software estándar se compra y se parametriza para proporcionar una solución que esta lo "suficientemente cerca" a lo que se necesita. Este tipo de software tiene ventajas significativas (cuando funciona): • Puede ser óptimamente adaptado al modelo de negocio del usuario • Puede tomar ventaja de cualquier conocimiento de su propiedad o prácticas. • Puede proporcionar una ventaja competitiva en la era de la información.

7. Antecendentes: SW hecholíneaporlínea (desventajas) • La producción de SW desde cero es una empresa muy costosa. • El mantenimiento y el seguimiento del estado del arte, como el incorporar accesos Web, pueden convertirse en una mayor carga. • Los requerimientos de interoperabilidad con otros sistemas locales también se ven afectados. • Como resultado, la mayoría de los proyectos grandes fallan parcialmente o totalmente, conduciendo a un riesgo sustancial. Además, en un mundo de rápidos y contínuos cambios en los requerimientos de negocios, el software hecho línea por línea es usualmente muy lento para ser productivo antes de convertirse en obsoleto. 

8. Tendencia outsourcing • Frente a todas estas desventajas mencionadas, la gran tendencia hacia el "outsourcing" en la industria es comprensible. • La producción de software a medida es subcontratada por debajo del precio fijado, para limitar el riesgo financiero, para cubrir el riesgo de tiempo de salida al mercado. • Hay una fuerte tendencia hacia el uso de software estándar - es decir, el software que es sólo ligeramente ajustado a las necesidades reales. • La carga de mantenimiento, evolución del producto, y la interoperabilidad se deja al proveedor del paquete estándar. • Lo que queda es llevar la parametrización y el detalle de configuración al próximo lanzamiento - todavía un esfuerzo considerable, pero inevitable en un mundo de cambio.

9. ¿Qué hay de malo en software estándar? • En primer lugar, Software estándar puede requerir una reorganización mayor o menor de los procesos de negocio afectado. Aunque el proceso de reingeniería del negocio puede valer la pena en la empresa. • Segundo el software estándar es un estándar. Intenta dar una solución general a un problema amplio. Lo cual nos restringe su uso, excepto que se utilice extremadamente bien. • En tercer lugar, como software estándar no está bajo el control local, no es suficientemente ágil como para adaptarse rápidamente a las necesidades cambiantes.

10. El espectro entre hacerlotodo y comprarlotodo Cuandotodoestahecho a medida, la flexibilidad no tienelímitespero la rentabilidadcae en picada.

11. Los componentes son inevitables • El desarrollo de la tecnología de componentes excelentes no es suficiente para establecer un mercado. La disciplina está llena de ejemplos de productos técnicamente superiores que no pudieron capturar mercados suficientemente grandes. Además de la superioridad técnica de un componente se necesita una masa crítica para despegar. • Un paradigma de componentes gana una gran clientela si los componentes ofrecidos tienen suficiente variedad y calidad, entonces, existe un beneficio obvio al usar componentes.  • Una vez que los clientes han cubierto sus necesidades en un segmento del mercado, el uso de componentes en ese segmento se vuelve inevitable. 

12. …Los componentes son inevitables • Si no se encuentran los componentes requeridos disponibles, se provoca la reinvención de soluciones. Esto sólo puede ser justificado cuando la solución creada es superior a la alternativa que se puede comprar. • Un producto que utiliza los beneficios de los componentes, es el que hace uso de una combinación de productividad e innovación de todos los vendedores de componentes. Los vendedores de componentes están enfocados en proveer a muchos clientes diferentes y así ser capaces de perfeccionar sus componentes rápidamente. 

13. Los componentes son unidades de implementación • Un componente de software una implementación aislada de un sistema. • Contrario a lo que se ha dicho, los objetos casi nunca se compran, venden o implementan. • La unidad de implementación es algo mas bien más estático, como una clase, o, más probablemente, un conjunto de clases, compilado y enlazado en algún paquete. • Aunque un componente puede ser una sola clase, es más probable que sea una colección de clases, algunas veces llamado módulo.

14. Mercados • Recientemente han surgido mercados exitosos basados en tecnologías de componentes. • Compañías como ComponentSource.com o Flashline.com venden miles de componentes ya hechos, la mayoría en COM y categorías en Java, pero componentes VCL (una tecnología de Delphi/C++ Builder por Borland) y .NET también están presentes. Compañías como ILOG y Rouge Wave Software generan ingresos sustanciales al enfocarse en su producción de componentes.

15. Bibliografia • http://computacion.cs.cinvestav.mx/~sgarrido/cursos/ing_soft/Componentes/node4.html