7/25/2019 Componiendo Lo Descompuesto

1/6

Componiendo lo Descompuesto - Diagrama de Estructura CompuestaPor Sergio Orozco

En el mundo real, el mundo de los objetos, algo normal que nos encontramos son objetos que estncompuestos por ms objetos. UML nos permite modelar dicha inormaci!n por medio de relaciones decomposici!n entre los objetos contenedores " sus partes.

#icha relaci!n se muestra tradicionalmente con un diamante relleno en la orilla del contenedor, en unarelaci!n entre el contenedor " la parte. En el siguiente diagrama podemos $er que un carro tiene un motor, "dicho motor no puede ser parte de otro carro en un momento determinado en el tiempo.

Pero, modelar en UML composiciones de objetos pod%a $ol$erse mu" complejo en ciertas situaciones. &omo

en el caso de un carro " un barco que estu$ieran compuestos por motor, pero donde para el primero el motora"udara a mo$er las ruedas delanteras " en el segundo caso el motor sir$iera para mo$er el propulsor delbarco. 'abr%a que realizar un modelo complejo para aclarar (a quien pudiera leer el diagrama), que habia unadierencia entre el motor que ten%a el carro " el motor del barco.

El diagrama anterior intenta e*plicar esto, pero tiene deiciencias, pues aunque aclara con la multiplicidad delas cone*iones de carro " barco (+..) como contenedores del motor, que s!lo puede estar la instancia delmotor en uno de los dos- por otra parte parece decirnos que el motor del carro puede mo$er tanto propulsorcomo llantas. Lo cual es equi$ocado, pues el motor del barco s!lo mue$e el propulsor " el del carro s!lomue$e sus llantas. ampoco aclara que las dos llantas que mue$e el motor en el carro son las delanteras, "no las dos traseras.

Para modelarlo correctamente en un diagrama de clases tendr%amos que elaborar toda una jerarqu%a deherencia entre clases para distinguir entre los motores de barcos " carros, " entre las llantas delanteras "traseras de un carro, o marcando dependencias entre las relaciones.

&on UML / ahora contamos con un nue$o diagrama, llamado diagrama de estructura compuesta, que nospermite conte*tualizar las partes que componen a una clase. 0s% podemos armar un diagrama dondeaclaremos que el carro tiene un motor que mue$e las dos llantas delanteras (pero, no las traseras ni elpropulsor), " otro diagrama del mismo tipo que nos permitir%a mostrar el barco con un motor quee*clusi$amente mue$e su propulsor (" no las llantas).

7/25/2019 Componiendo Lo Descompuesto

2/6

El conte*to lo deine la clase contenedora, que con ines de este ejemplo ser%an el carro o el barco. 1 dentrode dicha clase modelamos las partes que lo componen, como se muestra a continuaci!n. &ada uno de estosdiagramas muestra la estructura interna de una instancia de carro " de barco respecti$amente.

En este caso nos queda mucho ms claro que cada uno tiene un motor, pero que unciona de maneradierente. 2ncluso es claro que el motor del carro mue$e e*clusi$amente las dos llantas delanteras, " no lasdos traseras.

Los elementos que tradicionalmente se muestran en este tipo de diagrama son3

Clase.Para mostrar la parte de la cual se ilustra su composici!n interna (ejemplo3 carro o 4arco)

Parte.Se muestra con un rectngulo, e indica los objetos que conorman al objeto principal. Ejemplo3

el motor " las llantas en el carro, o el motor " el propulsor en el 4arco. Si se coloca una parte dentrode una clase signiica, en un diagrama de clases, que la clase contenedor tiene una relaci!n de

composici!n con dicho elemento.

Conector.2ndica la relaci!n entre las parte internas de la clase que se analiza.

Puertos.Se pueden mostrar puertos para indicar la entrada o salida de una parte hacia otra parte.

Se muestran como peque5os cuadrados al inal de un conector entre dos partes. 6o son obligatorias,pero son recomendables si se quiere encapsular el uncionamiento de las partes.

Un uso adicional que se puede dar a los diagramas de estructura compuesta es para mostrar las partes quecolaboran, por ejemplo, en un caso de uso. 0unque en esta ocasi!n no e*plicaremos esta perspecti$a,consideramos importante mencionarlo " mostrar un peque5o ejemplo.

7/25/2019 Componiendo Lo Descompuesto

3/6

En este ejemplo podemos $er que son tres las clases que colaboran en el caso de uso 7Participar en curso83 elestudiante, el curso " el seminario. Esta orma nos permitir%a modelar patrones de dise5o indicando los rolesque juega cada clase en la colaboraci!n.

Publicado en la re$ista Sot9are :ur;.

7/25/2019 Componiendo Lo Descompuesto

4/6

'Consultor(a o Manu)actura*

Si queremos realizar una $erdadera consultor%a de sot9are entonces nos corresponde algo ms que

escuchar la lista de unciones que el cliente cree que deber%a de tener su sistema (a menos que nuestro

cliente tenga un rea con la capacidad de realizar una buena recopilaci!n " anlisis de requerimientos).

Si nos limitramos a lo primero entonces en lugar de llamarle consultor%a a nuestro trabajo, deber%amos

llamarle manuactura de sot9are, donde uno implementa las unciones e*actamente como se las solicita el

cliente, cuestionando nada o mu" poco, tal como se har%a en una planta manuacturera donde se reciben las

especiicaciones del producto a construir.

El "istema y su Misi$n

Si queremos desarrollar el mejor sistema posible debemos realizar un trabajo serio para identiicar, en primer

lugar, cul es el $alor que el sistema debe proporcionar al negocio. Para lo cual habr que preguntrselo a las

personas que obtendrn alguna clase de beneicio cuando se ponga en operaci!n. Una buena parte de estas

personas probablemente $a"an a ser usuarios del sistema- en UML los conocemos como 0ctores (ms

adelante $eremos otros tipos de 0ctores que tambi=n tendremos que identiicar).

+uscando los +ene)icios del "istema

Una $ez identiicados los usuarios del sistema (actores primarios) habr que preguntarles en qu= situaciones

$aldr la pena para ellos utilizarlo. La lista identiicada de dichas situaciones no deber%a de tener peque5as

unciones, sino lujos completos que le proporcionen suiciente $alor tanto a ellos como al negocio, de manera

que 7$alga la pena usar el sistema8 en dichas situaciones.

Ejemplo3 un $endedor en cierto sistema de $entas querr 7

7/25/2019 Componiendo Lo Descompuesto

5/6

Diagrama de casos de uso para el sistema de venta

os %e&uerimientos ,uncionales

6ormalmente los casos de uso son iniciados por alg;n actor, conocido como actor primario. Lo inicia con

alg;n e$ento, que podr%a ser tan simple como elegir una opci!n en el sistema, " contin;a como una serie de

e$entos o interacciones entre actores " sistema, hasta que el objeti$o del caso de uso se cumple (el objeti$o

principal del caso de uso es lo que le da el nombre al mismo). Por lo tanto los casos de uso describen la

uncionalidad del sistema para alcanzar objeti$os importantes.

Lo que estamos obteniendo as% es una especiicaci!n de requerimientos uncionales mediante un anlisis top>

do9n (de lo general a lo particular), es decir, primero obtenemos los objeti$os que ha" que cumplir en el

sistema descritos con el nombre del caso de uso (p. ej3

7/25/2019 Componiendo Lo Descompuesto

6/6

as nter)ases del "istema

'a" otro tipo de actores que tambi=n ha" que modelar- los actores secundarios. Suelen ser otros sistemas,

componentes e*ternos o dispositi$os con los cuales interact;a nuestro sistema. 0 dierencia de los actores

secundarios, =stos no son los que inician o requieren del caso de uso, sino que nuestro sistema, al lle$ar a

cabo un caso de uso requiere tener alg;n tipo de interacci!n con =l.

En el diagrama de casos de uso tambi=n suele ser apropiado mostrar a este tipo de actores, en cu"o caso

aparecern asociados a los casos de uso durante los cuales tienen que inter$enir con alg;n tipo de

interacci!n con el sistema a modelar.

Ejemplo de 0ctor Secundario

Nuestro sistema de ventas podra requerir enviarle informacin al sistema de contabilidad cuando se ejecuta

la funcionalidad del caso de uso Generar factura. En dicha situacin el sistema de contabilidad aparecer

como un actor secundario asociado a dicho caso de uso. De esta forma estamos mostrando las interfases

requeridas con otros sistema en cada momentos.

Por e*periencia sabemos que, en los modelos de UML, el buen uso de pocos elementos da mejores

resultados que el uso de muchos elementos mal aplicados. La esencia de los modelos radica en lasimplicidad, "a que acilita el anlisis, entendimiento " comunicaci!n entre quienes solicitan el sistema " los

que participan en su desarrollo.

En otras oportunidades $eremos elementos adicionales para modelar los casos de uso, pero podemos

asegurar que la sencillez es parte importante del modelado, " esto implica que en ocasiones, " sobre todo

cuando el analista no tiene tanta e*periencia en UML, es mejor limitarnos a los elementos ms bsicos.

Publicado en la re$ista Sot9are :ur;.