Los Componentes: Todos son Reemplazables, Pocos Reutilizables

La mayoría soñamos con desarrollar nuestros propios componentes reutilizables, y desarrollar aplicaciones cada vez más eficientes, en menos tiempo. Pocos lo logran, pero la gran mayoría se queda muy lejos de tan grandiosa meta.Por fortuna, hay empresas que se han enfocado en realizar dicho trabajo por nosotros; y contamos con gran cantidad de librerías de código y componentes que podemos aprovechar para no partir de cero en nuestros proyectos. Gracias a esto, el desarrollo de aplicaciones se vuelve cada día más eficaz; sobre todo para quienes saben buscar y aprovechar dichos componentes, así como las librerías que existen en el mercado.Los más sofisticados emplean cada nueva versión que surge de los mencionados componentes; sacándole todo el jugo en beneficio de un desarrollo más sobresaliente y de calidad. Hoy en día, el desarrollador más inteligente no necesariamente es el que conoce a la perfección un lenguaje de programación, sino el que es capaz de producir una mejor aplicación, y con más calidad. Esto no implica únicamente un conocimiento a fondo del lenguaje de programación, sino de las librerías que puede reutilizar para reducir al máximo la cantidad de nuevo código a escribir. El desarrollador moderno, requiere contar con la habilidad de estructurar adecuadamente las aplicaciones, mediante la integración de componentes propios y de terceros.

El componente según UML
Pero, a todo esto, ¿qué es un componente? De acuerdo a la especificación de UML, un componente: “es una parte modular de un sistema que encapsula su contenido y que es reemplazable en su entorno. Un componente define su comportamiento en términos de sus interfases, proporcionadas y requeridas...” El icono de UML para un componente, es un rectángulo con dos “patitas”. Este icono fue pensado para dar la idea de una clavija, o algo “conectable”.

Figura 1. Representación visual de un componente

A menos que se trate de un sistema pequeño y aislado –de esos que cada vez hay menos–, seguramente tendrás que representar tu sistema con dos o más componentes, por lo que el diagrama de componentes se vuelve un artefacto necesario para modelar tus sistemas.

Las nuevas tecnologías y la mayoría de las arquitecturas modernas, requieren del uso de componentes para estructurar y distribuir la aplicación. Necesitamos decidir en dónde ubicaremos los servicios de usuario, de negocio de datos o cualquier otro tipo de servicio específico; y sin el concepto de componentes esto resultaría imposible.

Componentes y objetos
Cuando hablamos de componentes, estamos llevando el concepto de objetos a un nivel más alto. La orientación a objetos puede hacer maravillas por nuestros desarrollos, una vez que aprendemos a explotar al máximo este paradigma. Pero, el reuso, mantenibilidad y flexibilidad de nuestros sistemas a un mayor nivel, lo conseguiremos en el momento en que aprendamos a definir adecuadamente los componentes de nuestros sistemas. Ya sea que nosotros los construyamos o que reutilicemos componentes ya existentes.

Reemplazable = menor costo
La definición de la especificación de la OMG nos habla acerca de que un componente es reemplazable. Vale la pena detenerse un momento a analizarlo.

De acuerdo a algunos estudios –y no es necesario ser genio para darse cuenta–, un costo importante de los sistemas viene a la hora del mantenimiento. El sistema empieza a crecer y, el costo por cada línea de código adicional va siendo cada vez más alto. Crear un software nuevo es más económico que mantener un software existente. Ya sea para corregirlo, modificarlo o para agregarle nueva funcionalidad.

Aquí es donde entra el concepto de “reemplazabilidad” de los componentes. Si diseñamos adecuadamente nuestro sistema, por medio de componentes que encapsulan de forma modular el comportamiento de nuestro sistema, y las reglas de negocio, entonces podremos modificar el sistema cuando cambien esas reglas de negocio a un costo mucho menor. Esto siempre y cuando seamos capaces de identificar el componente donde tienen que realizarse dichos cambios. Si logramos respetar las interfases de dicho componente, a pesar de los cambios internos requeridos en el componente, tendremos un mantenimiento sumamente eficiente de la aplicación, y muy transparente, en muchos casos, para la mayoría de los involucrados en el desarrollo.

Las interfases
Algunos de los beneficios de trabajar partiendo de un modelo de componentes para construir nuestro sistema:
1. Mayor productividad, si logramos identificar componentes ya existentes que podamos reutilizar o si construimos componentes que podamos reutilizar en el futuro.
2. Reducción del tiempo de entrega, ya sea porque reutilizamos componentes o porque partimos de un plan donde podemos paralelizar mayor cantidad de trabajo. Varias personas pueden trabajar en diferentes componentes al mismo tiempo.
3. Mayor calidad, pues un componente es más fácil de programar y probar que una aplicación completa. Si los componentes están bien planeados para formar la aplicación completa, la calidad de los componentes se verá reflejada en la aplicación final. Además, si un componente fue creado y utilizado anteriormente, significa que ya fue probado en situaciones reales, por lo que es muy probable que ha madurado.
4. Menores costos, tanto por el reuso, como por la facilidad para darle mantenimiento a la aplicación, mediante el mantenimiento a componentes específicos donde se identifican los cambios a realizar.

Las interfases
Pero, ¿qué es esto de las interfases? La interfase representa la declaración de un conjunto de funciones y obligaciones que alguien más lleva a cabo. En el diagrama de componentes la interfase representa aquello que un componente es capaz de hacer por alguien más (interfase proporcionada) o aquellos servicios que posiblemente requiera utilizar un componente y que son proporcionados por otro componente (interfase requerida). Podemos representar la interfase como una clase estereotipada, o iconográficamente como un círculo ligado al componente (a este icono se le acostumbra llamar "lollipop", por su parecido a una paleta).
Figura 2. El componente Ventas expone sus servicios a través de la interfase IVenta y requiere de una interfase IDetalleCliente

Un componente proporciona funcionalidad específica dentro del sistema. Por ejemplo, podríamos tener un componente que se encarga de aplicar las reglas de negocio para realizar una venta (calcular total, calcular IVA, agregar un producto a la venta, cancelar la venta, etcétera). Esa funcionalidad, cuando usamos un lenguaje orientado a objetos, está implementada en un conjunto de clases agrupadas dentro del componente.

No todas las operaciones de las clases agrupadas en el componente, son “visibles” o “utilizables” por otros componentes. Sólo aquellas que decidamos exponer. Esas funciones se exponen precisamente, a través de las interfases. Es por eso que decimos que la interfase contiene un conjunto de declaraciones de operaciones públicas: las que expone el componente.

Figura 3. La interfase de un componente se puede ver como círculo o como una clase estereotipada con una relación de realización desde el componente que la expone

Cuando queremos indicar en un solo diagrama, que la interfase expuesta por un componente es la misma requerida por otro componente, podemos mostrarlo por medio de un ensamble.

Figura 4. El componente Orden requiere utilizar la Interfase CodigoUnidad que expone el componente Producto y la Interfase DetalleCliente que expone el componente Cliente

Al igual que otros artefactos que hemos mostrado, se ha hecho de forma simplificada y para las situaciones más comunes, de la misma forma en esta ocasión se explica el concepto de componente e interfase para la situación más común en que se utiliza. Pues, nuestra intención, en varios de estos artículos, consiste en ayudar a la persona que comienza a trabajar con estos artefactos y no nos gustaría confundirlo con demasiados conceptos.

Para quien conoce ya el tema, recomendamos usar referencias más completas, como sería la especificación de UML en la OMG o participar en un curso especializado en UML, o esperar artículos futuros donde ahondemos en el tema.

Acerca del Autor
Sergio Orozco es director general e instructor senior certificado por la OMG en Milestone Consulting (UML Value Added Training Center), empresa especializada en capacitación práctica y consultoría en UML, CMMI y orientación a objetos. Milestone Consulting es la primer empresa mexicana miembro de la OMG.
info@milestone.com.mx www.milestone.com.mx