Ingeniería de software basada en componentes

Es un acercamiento basado en la reutilización para definir, implementar, y componer componente de software débilmente acoplados en sistemas.Debido a este principio, con frecuencia se dice que los componentes son modulares y cohesivos.Cuando un componente ofrece servicios al resto del sistema, este adopta una interfaz proporcionada que especifica los servicios que otros componentes pueden utilizar, y cómo pueden hacerlo.Las ilustraciones UML de este artículo representan a las interfaces proporcionadas, con un símbolo lollipop unido al borde externo del componente.Cuando un componente debe ser accesado o compartido a través de contextos de ejecución o enlaces de red, a menudo son empleados técnicas tales como serialización o marshalling para enviar el componente a su destino.Toma un significativo esfuerzo y conciencia para escribir un componente de software que sea efectivamente reutilizable.[1]​ Surgió a finales de los 90's como reutilización, fue motivada por los desarrolladores de que el modelo orientado a objetos no aplicaba la reutilización por lo que se debía tener un acceso al código fuente.[2]​ La conferencia se propuso para hacer frente la llamada crisis del software.Él sumariza esta visión en su libro de 1986 Object-Oriented Programming - An Evolutionary Approach (Programación orientada a objetos - Un acercamiento evolutivo).A principio de los 1990, IBM encabezó esta trayectoria con su System Object Model (SOM).La OOP y las disciplinas relacionadas de análisis orientado a objetos y el diseño orientado a objetos están enfocados en el modelado de interacciones del mundo real [cita requerida] e intentan identificar los "sustantivos" y los "verbos" en las reuniones de levantamiento de requerimientos, para esos conceptos sean programados directamente en clases y métodos, que pueden ser usados en más formas humanamente legibles, idealmente por los usuarios finales así como por los programadores que codifican para esos usuarios finales.Por contraste, la ingeniería de software basado en componentes no hace tal asunción, y en lugar ello expresa que los desarrolladores deben construir el software pegando entre sí componentes prefabricados - como en los campos de la electrónica o la mecánica.
Un simple ejemplo de dos componentes expresado en UML 2.0. El componente Checkout (comprobación), responsable de facilitar los pedidos del cliente, requiere al componente CardProcessing (procesador de tarjetas) para cargar el monto a la tarjeta de crédito/débito del cliente (funcionalidad que este último provee ).
Un simple ejemplo de varios componentes de software - representados dentro de un hipotético sistema de reservaciones de días de fiesta representado en UML 2.0.