Diagrama de co­m­po­ne­n­tes: modelado eficiente de sistemas con módulos de software

El Unified Modeling Language (en ca­s­te­llano, lenguaje de mo­de­la­ción unificado) es la norma ISO de apli­ca­ción general para el de­sa­rro­llo de software y ar­qui­te­c­tu­ras de sistemas complejos. Este lenguaje de modelado, abreviado como “UML”, utiliza di­fe­re­n­tes tipos de diagramas para los procesos de pla­ni­fi­ca­ción y de­sa­rro­llo en la pro­gra­ma­ción orientada a objetos.

En la versión actual (UML 2.5) se cla­si­fi­can 14 tipos de diagramas, que se dividen a grandes rasgos en diagramas de co­m­po­r­ta­mie­n­to y diagramas es­tru­c­tu­ra­les. Este último subgrupo incluye los diagramas de co­m­po­ne­n­tes. Aquí te contamos en qué consisten y uti­li­za­mos un ejemplo concreto para ilustrar cómo crear un diagrama de co­m­po­ne­n­tes. Además, apre­n­de­rás para qué se utilizan los diagramas de co­m­po­ne­n­tes UML.

Los diagramas de co­m­po­ne­n­tes UML re­pre­se­n­tan las re­la­cio­nes entre los co­m­po­ne­n­tes in­di­vi­dua­les del sistema mediante una vista de diseño estática. Pueden ilustrar aspectos de modelado lógico y físico.

En el contexto del UML, los co­m­po­ne­n­tes son partes modulares de un sistema in­de­pe­n­die­n­tes entre sí, que pueden re­em­pla­zar­se con co­m­po­ne­n­tes equi­va­le­n­tes. Son au­to­co­n­te­ni­dos y en­ca­p­su­lan es­tru­c­tu­ras de cualquier grado de co­m­ple­ji­dad. Los elementos en­ca­p­su­la­dos solo se comunican con los otros a través de in­te­r­fa­ces. Los co­m­po­ne­n­tes no solo pueden pro­po­r­cio­nar sus propias in­te­r­fa­ces, sino que también pueden utilizar las in­te­r­fa­ces de otros co­m­po­ne­n­tes, por ejemplo, para acceder a sus funciones y servicios. A su vez, las in­te­r­fa­ces de un diagrama de co­m­po­ne­n­tes do­cu­me­n­tan las re­la­cio­nes y de­pe­n­de­n­cias en una ar­qui­te­c­tu­ra de software.

Los co­m­po­ne­n­tes suelen en­ca­p­su­lar clases y, por lo tanto, también se los conoce como subformas o es­pe­cia­li­za­cio­nes de clases. Al igual que las clases, tienen una es­tru­c­tu­ra compuesta y pueden definirse en más detalle por medio de atributos, métodos y ope­ra­cio­nes, por ejemplo. Los co­m­po­ne­n­tes pueden ser una co­m­pi­la­ción de clases y, por ejemplo, ser im­ple­me­n­ta­dos si­mu­l­tá­nea­me­n­te por varias clases en tiempo de ejecución. Aunque los co­m­po­ne­n­tes se equiparan a menudo con las clases, no son lo mismo. Si bien los co­m­po­ne­n­tes suelen requerir in­te­r­fa­ces para la in­ter­ac­ción, una clase también puede acceder di­re­c­ta­me­n­te a un método.

El término “co­m­po­ne­n­te” en UML tiene una de­fi­ni­ción muy amplia. Se utiliza para denominar varias partes del sistema, como bases de datos, paquetes, archivos y bi­blio­te­cas (por ejemplo, bi­blio­te­cas de enlace dinámico/DLL). Además de los co­m­po­ne­n­tes técnicos, por ejemplo, para el acceso a las bases de datos, hay también co­m­po­ne­n­tes es­pe­cia­li­za­dos que pueden estar re­la­cio­na­dos con los ámbitos y procesos em­pre­sa­ria­les. Para definir estas re­la­cio­nes, que pueden ser muy amplias, UML define el es­te­reo­ti­po <<subsystem>>.

Como los diagramas de co­m­po­ne­n­tes modelan los sistemas de manera orientada a la im­ple­me­n­ta­ción, existen co­m­po­ne­n­tes de im­ple­me­n­ta­ción concretos dedicados ex­clu­si­va­me­n­te a ciertos aspectos re­la­cio­na­dos con la rea­li­za­ción. Estos co­m­po­ne­n­tes se pueden utilizar, por ejemplo, para im­ple­me­n­tar otros co­m­po­ne­n­tes, como los eje­cu­ta­bles (archivos eje­cu­ta­bles con la extensión *.exe) en Windows.

En conjunto, varios co­m­po­ne­n­tes forman una ar­qui­te­c­tu­ra de sistema más amplia. Los co­m­po­ne­n­tes pueden también contener otros co­m­po­ne­n­tes y basarse unos en otros, de modo que un co­m­po­ne­n­te puede pre­su­po­ner la exi­s­te­n­cia de otros co­m­po­ne­n­tes (relación de de­pe­n­de­n­cia). Asimismo, los módulos de software pueden ser apli­ca­bles a di­fe­re­n­tes fases de rea­li­za­ción: algunos co­m­po­ne­n­tes se utilizan pri­n­ci­pa­l­me­n­te para la pla­ni­fi­ca­ción y la in­ge­nie­ría de proyectos durante la fase de diseño, mientras que otros solo existen durante el tiempo de ejecución de un programa in­fo­r­má­ti­co. En este contexto, también puede hablarse de los co­m­po­ne­n­tes de diseño y de tiempo de ejecución.

Un diagrama de co­m­po­ne­n­tes pro­po­r­cio­na una visión general del sistema y documenta la or­ga­ni­za­ción de los co­m­po­ne­n­tes del sistema y sus re­la­cio­nes y de­pe­n­de­n­cias mutuas. Los diagramas de co­m­po­ne­n­tes pro­po­r­cio­nan una visión orientada a la ejecución, es decir, dan al de­sa­rro­lla­dor in­fo­r­ma­ción sobre si un sistema funciona de forma coherente y cumple sus tareas y objetivos.

Los objetivos y pro­pó­si­tos más im­po­r­ta­n­tes de este tipo de diagrama son el modelado de sistemas de software basados en co­m­po­ne­n­tes, la es­pe­ci­fi­ca­ción de ar­qui­te­c­tu­ras de software y la división de sistemas en su­b­si­s­te­mas (por ejemplo, interfaz gráfica de usuario/IGU, ámbito em­pre­sa­rial y capa de pe­r­si­s­te­n­cia con base de datos re­la­cio­nal). Asimismo, se asignan tareas y funciones concretas a las subáreas y sus in­te­r­fa­ces dentro del sistema.

Los diagramas de co­m­po­ne­n­tes UML son básicos para la co­mu­ni­ca­ción con el cliente en el plano económico, porque, con ellos, los proyectos y planes son más tangibles y co­m­pre­n­si­bles y pueden ex­pli­car­se mejor, ya que expresan los datos de manera sencilla. Los diagramas de co­m­po­ne­n­tes también facilitan la gestión del de­sa­rro­llo de programas in­fo­r­má­ti­cos, por ejemplo, co­m­bi­na­n­do clases en co­m­po­ne­n­tes ma­ne­ja­bles.

Asimismo, la na­tu­ra­le­za modular de este tipo de diagramas co­n­tri­bu­ye a la re­n­ta­bi­li­dad y la efi­cie­n­cia de los proyectos, ya que los sistemas de software también pueden modelarse como re­la­cio­nes fu­n­cio­na­les es­tru­c­tu­ra­das a partir de co­m­po­ne­n­tes re­uti­li­za­bles. Los diagramas de co­m­po­ne­n­tes, por ejemplo, permiten vi­sua­li­zar de forma clara qué bloques modulares se pueden utilizar varias veces en varios puntos de una ar­qui­te­c­tu­ra. Así, los sistemas se pueden diseñar para optimizar la re­uti­li­za­ción de los co­m­po­ne­n­tes y su in­ter­ac­ción eficiente.

Los sistemas de software basados en co­m­po­ne­n­tes ahorran tiempo y costes en la fase de pla­ni­fi­ca­ción y durante la im­ple­me­n­ta­ción de los sistemas, ya que los sistemas exi­s­te­n­tes se pueden re­uti­li­zar. Además, sus módulos de software de probada eficacia reducen los riesgos y las causas de error, es­pe­cia­l­me­n­te al im­ple­me­n­tar proyectos más complejos. Como también se ofrecen módulos de terceros que se pueden adquirir para im­ple­me­n­tar los sistemas, se puede compensar la falta de co­no­ci­mie­n­tos técnicos internos.

A partir de estos elementos básicos, se puede crear un diagrama de co­m­po­ne­n­tes simple uti­li­za­n­do el software libre de código abierto JGraph.

Se puede aumentar la pro­fu­n­di­dad de re­pre­se­n­ta­ción de un diagrama de co­m­po­ne­n­tes de­fi­nie­n­do los elementos in­vo­lu­cra­dos de forma aún más precisa siguiendo la norma UML. Por ejemplo, se pueden definir las clases uti­li­za­das con mayor precisión uti­li­za­n­do atributos y ope­ra­cio­nes. Nuestro artículo sobre diagramas de clases presenta muchas opciones para es­pe­ci­fi­car las clases de forma más detallada. Los diagramas de caso de uso y los diagramas de estado ofrecen otras opciones de diseño y modelado.