¿QUÉ ES
UN COMPONENTE?
Surgió a
finales de los 90 como una aproximación basada en reutilización al desarrollo
de sistemas software. Su creación fue motivada por la frustración de los
diseñadores de que el desarrollo orientado a objetos no reconducido a una
reutilización extensiva, tal y como se sugirió originalmente. Las clases de
objetos simples eran demasiado detalladas y específicas, y a menudo tenían que
ser enlazada con aplicaciones en tiempo de compilación. Había que tener un
conocimiento detallado de clases para usarlas, lo cual generalmente significaba
que había que tener acceso al código fuente del componente. Esto hizo que fuera
difícil el marketing de objetos como componentes reutilizables. A pesar de las
predicciones optimistas iniciales, nunca se desarrolló un mercado significativo
para objetos individuales (Sommerville, 2005).
Un
componente, es un bloque de construcción de software de cómputo. Con más
formalidad, la especificación del Lenguaje de Modelado Unificado define un
componente como “una parte modular, desplegable y sustituible de un sistema,
que incluye la implantación y expone un conjunto de interfaces”. Los
componentes forman la arquitectura del software jugando un papel importante en
el logro de los objetivos y de los requerimientos del sistema que se va a
construir. Como los componentes se encuentran en la arquitectura del software,
deben comunicarse y colaborar con otros componentes y con entidades (otros
sistemas, dispositivos, personas, entre otros.) que existen fuera de las
fronteras del software. El verdadero significado del término componente difiere
en función del punto de vista del ingeniero de software que lo use. (Pressman,
2010).
Consiguientemente,
un componente es una
unidad de software independiente y desplegable definida completamente, al cual
se accede a través de un conjunto de interfaces, así mismo debe contar con
algunas características como son: ser reutilizable, cohesivo, intercambiable y contar
con interfaces definidas.
En diferentes paradigmas de programación la piedra angular son los componentes, por lo cual se genera la aparición en el mercado de diferentes descripciones que plantean la forma de construirlos, utilizarlos y distribuirlos. Dividiéndose en dos vertientes que son:
- Estándares
§
Common Object Request
Broker Architecture (CORBA) del Object Management Group.
§ JavaBeans, servlets y Enterprise
Java Beans de Oracle
§
Open Services Gateway
Initiative (OSGi) de OSGi Alliance
§ COM, COM + y DCOM de Microsoft
-
Paradigmas
Los componentes de software son útiles en:
§ Programación Orientada a Componentes
§ Programación Orientada a Objetos
§ Arquitectura Orientada a
Servicios (SOA)
SISTEMAS
DE COMPONENTES INDEPENDIENTES
Es un
estilo de diseño para aplicaciones compuestas de componentes individuales. Pone
énfasis en la descomposición del sistema en componentes lógicos o funcionales
que tienen interfaces bien definidas. Define una aproximación de diseño que usa
componentes discretos, los que se comunican a través de interfaces que
contienen métodos, eventos y propiedades.
En
tal sentido Sommerville (2005) define los componentes independientes, como aquellos “que
son completamente especificados por sus interfaces. Debería haber una clara
separación entre la interfaz de los componentes y su implementación para que
una implementación de un componente se pueda reemplazar por otro sin cambiar el
sistema”.
·
El proceso de comunicación: se define en implementar e
integrar o componer en sistemas componentes independientes débilmente
acoplados. Se ha convertido en una importante aproximación de desarrollo del
software debido a que los sistemas software son cada vez más grandes y más
complejos y los clientes demandan software más confiable desarrollado más
rápidamente. La única forma en la que podemos tratar con la complejidad y
entregar software de calidad más rápidamente es reutilizar.
Los componentes de algunos
modelos definen interfaces que deberían implementarse conforme a todos los
componentes. Si los componentes cumplen con los estándares, entonces su
funcionamiento es independiente de su lenguaje de programación, permitiendo así
que componentes escritos en diferentes lenguajes puedan integrarse en un mismo
sistema.
·
Las arquitecturas basadas en eventos: se han llamado también de invocación
implícita. Otros nombres propuestos para el mismo estilo han sido
integración reactiva o difusión (emisión) selectiva. Por supuesto que
existen estrategias de programación basadas en eventos, sobre todo referida a
interfaces de usuario, existiendo además eventos en los modelos de objetos y
componentes, aunque no es a eso a lo que se refiere primariamente el estilo, no
obstante esa variedad no está del todo excluida. En términos de patrones
de diseño, el patrón que corresponde más estrechamente a este estilo es el que
se conoce como Observador.
Los dos modelos de control
dirigidos por eventos:
1. Modelos de transmisión: En estos modelos, un evento se
transmite a todos los subsistemas. Cualquier subsistema que haya sido
programado para manejar ese evento puede responder a él.
2. Modelos dirigidos por interrupciones: Éstos se usan exclusivamente en
sistemas de tiempo real, en donde las interrupciones externas son detectadas
por un manejador de interrupciones, para seguidamente, éstas ser enviadas a
algún otro componente para su procesamiento.
SISTEMAS BASADOS EN TRANSACCIONES
Los
sistemas de procesamiento de transacciones se diseñan para procesar peticiones
de usuario a fin de obtener información de una base de datos o peticiones para
actualizar la base de datos (Lewis et al., 2003). Técnicamente, una
transacción de una base de datos es una secuencia de operaciones tratada como
una única unidad (una unidad atómica). Todas las operaciones de una transacción
tienen que ser completadas antes de que los cambios en la base de datos sean
permanentes. Esto significa que los fallos de operaciones dentro de la
transacción no conducen a inconsistencias en la base de datos.
Un
ejemplo de una transacción es una petición de un cliente para efectuar un
reintegro de una cuenta bancaria utilizando un ATM (Máquina conectada
informáticamente con un banco que permite efectuar al cliente ciertas
operaciones bancarias mediante una tarjeta o libreta magnéticas que tienen
asignada una clave personal). Esto implica obtener detalles de la cuenta del
cliente, comprobar el saldo, modificar el saldo por la cantidad reintegrada y
enviar comandos al ATM para proporcionar el dinero en efectivo. Hasta que todos
estos pasos no hayan sido completados, la transacción está incompleta y no se
modifica la base de datos de cuentas de clientes.
Desde la
perspectiva de un usuario, una transacción es cualquier secuencia coherente de
operaciones que satisface un objetivo, tal como “encuentra los horarios de
vuelos desde Londres a París”. Si la transacción del usuario no requiere que la
base de datos sea modificada, los sistemas de procesamiento de transacciones
son normalmente sistemas interactivos en donde los usuarios realizan peticiones
de servicios de forma asíncrona.
