UML Domine el lenguaje de modelado más utilizado en la actualidad

D iagram a de com p o n e n te s DIAGRAMA DE COMPONENTES Los diagramas de componentes reflejan la estructura estática de nuestro sistema, pero desde un punto de vista físico. Generalmente, ya tenemos la codificación de nuestro sistema realizada y plasmamos las ubicaciones físicas dentro de los diagra­ mas de componentes. Un componente puede representar tanto el código de una clase como de una instancia, una interfaz o, incluso, también puede interpretarse como paquetes. Sus principales usos son ios siguientes: • Modelar el código fuente. • Modelar las distintas versiones de nuestro software final. • Modelar base de datos físicas. De los tres usos que mencionamos, sin dudas el primero es el más popular de todos. Es importante que tengamos en cuenta que cuando hablamos de modelar código fuente, incluimos librerías, ejecutables, tablas, archivos y documentos, es decir, el objetivo es modelar la visión global del código. Los elementos que componen un diagrama de componentes son los componentes propiamente dichos sumados a la especificación de interfaces, así como también toda la variedad posible de relaciones entre todos los elementos. Los componentes, a su vez, en su estructura interna pueden incluir tanto paquetes como clases. Diagramas de componentes en UML Tradicionalmente, los componentes se representan gráficamente como rectángu­ los con otros dos pequeños rectángulos que sobresalen del lado izquierdo. Sin embargo. Visual Paradigm los dibuja de una manera un poco diferente: son representados gráficamente con un rectángulo tradicional a cuyo nombre se le antepone el estereotipo « c o m p o n e n t » seguido de un símbolo tradicional de los componentes. Claramente, estas diferencias atentan contra la estandarización del lenguaje UM L y si bien un porcentaje altísimo de los elementos del lenguaje UM L es uniforme en todas sus versiones y en todas las herramientas, lo ideal Q Q EVOLUCIÓN DE UN PROGRAMA Un producto de software generalmente es implementado de manera escalar, partiendo de un programa básico al cual se van agregando nuevas funcionalidades. Cada prototipo entregado tiene una fecha lím ite dentro del proceso y se lo conoce como mílestone. üsualmente. cada milestone va acompañado de un número único que lo identifica (por ejemplo. Mi Sistema 1.0). 129