Componiendo lo Descompuesto - Diagrama de Estructura Compuesta

Por Sergio Orozco

En el mundo real, el mundo de los objetos, algo normal que nos encontramos son objetos que estn
compuestos por ms objetos. UML nos permite modelar dicha informacin por medio de relaciones de
composicin entre los objetos contenedores y sus partes.
Dicha relacin se muestra tradicionalmente con un diamante relleno en la orilla del contenedor, en una
relacin entre el contenedor y la parte. En el siguiente diagrama podemos ver que un carro tiene un motor, y
dicho motor no puede ser parte de otro carro en un momento determinado en el tiempo.

Pero, modelar en UML composiciones de objetos poda volverse muy complejo en ciertas situaciones. Como
en el caso de un carro y un barco que estuvieran compuestos por motor, pero donde para el primero el motor
ayudara a mover las ruedas delanteras y en el segundo caso el motor sirviera para mover el propulsor del
barco. Habra que realizar un modelo complejo para aclarar (a quien pudiera leer el diagrama), que habia una
diferencia entre el motor que tena el carro y el motor del barco.

El diagrama anterior intenta explicar esto, pero tiene deficiencias, pues aunque aclara con la multiplicidad de
las conexiones de carro y barco (0..1) como contenedores del motor, que slo puede estar la instancia del
motor en uno de los dos; por otra parte parece decirnos que el motor del carro puede mover tanto propulsor
como llantas. Lo cual es equivocado, pues el motor del barco slo mueve el propulsor y el del carro slo
mueve sus llantas. Tampoco aclara que las dos llantas que mueve el motor en el carro son las delanteras, y
no las dos traseras.
Para modelarlo correctamente en un diagrama de clases tendramos que elaborar toda una jerarqua de
herencia entre clases para distinguir entre los motores de barcos y carros, y entre las llantas delanteras y
traseras de un carro, o marcando dependencias entre las relaciones.
Con UML 2 ahora contamos con un nuevo diagrama, llamado diagrama de estructura compuesta, que nos
permite contextualizar las partes que componen a una clase. As podemos armar un diagrama donde
aclaremos que el carro tiene un motor que mueve las dos llantas delanteras (pero, no las traseras ni el
propulsor), y otro diagrama del mismo tipo que nos permitira mostrar el barco con un motor que
exclusivamente mueve su propulsor (y no las llantas).

El contexto lo define la clase contenedora, que con fines de este ejemplo seran el carro o el barco. Y dentro
de dicha clase modelamos las partes que lo componen, como se muestra a continuacin. Cada uno de estos
diagramas muestra la estructura interna de una instancia de carro y de barco respectivamente.

En este caso nos queda mucho ms claro que cada uno tiene un motor, pero que funciona de manera
diferente. Incluso es claro que el motor del carro mueve exclusivamente las dos llantas delanteras, y no las
dos traseras.
Los elementos que tradicionalmente se muestran en este tipo de diagrama son:

Clase. Para mostrar la parte de la cual se ilustra su composicin interna (ejemplo: carro o Barco)

Parte. Se muestra con un rectngulo, e indica los objetos que conforman al objeto principal. Ejemplo:
el motor y las llantas en el carro, o el motor y el propulsor en el Barco. Si se coloca una parte dentro
de una clase significa, en un diagrama de clases, que la clase contenedor tiene una relacin de
composicin con dicho elemento.

Conector. Indica la relacin 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 pequeos cuadrados al final de un conector entre dos partes. No son obligatorias,
pero son recomendables si se quiere encapsular el funcionamiento de las partes.

Un uso adicional que se puede dar a los diagramas de estructura compuesta es para mostrar las partes que
colaboran, por ejemplo, en un caso de uso. Aunque en esta ocasin no explicaremos esta perspectiva,
consideramos importante mencionarlo y mostrar un pequeo ejemplo.

En este ejemplo podemos ver que son tres las clases que colaboran en el caso de uso Participar en curso: el
estudiante, el curso y el seminario. Esta forma nos permitira modelar patrones de diseo indicando los roles
que juega cada clase en la colaboracin.
Publicado en la revista Software Gur.
Reproducido con permiso del autor.
Temas relacionados:
Curso de anlisis y diseo orientado a objetos con UML

Los Casos de Uso y el Valor del Sistema

Por Sergio Orozco.
A quin no le ha pasado que siente la necesidad de comprar algo slo para terminar con ese producto en un
rincn sin jams ser utilizado. Nos pudo haber pasado porque no alcanz nuestras expectativas, o porque
result demasiado complicado de utilizar, o porque en realidad no era una verdadera necesidad sino
simplemente un capricho. Sea cual fuera la razn, la realidad es que hicimos un gasto intil e innecesario.
Con el software, y en particular con el desarrollo de software a la medida ocurre con bastante frecuencia algo
similar. Pues, no es raro encontrarse con empresas que contratan un desarrollo de software slo para darse
cuenta de que desperdiciaron su dinero y su tiempo, pues no obtuvieron lo que ellos esperaban o
necesitaban. En otras palabras, no obtuvieron el valor que esperaban recibir para su negocio con el software
adquirido.
La Admninistracin de Requerimientos

Una de las razones principales por las cuales se da esta situacin, y de hecho, una de las causas principales
por las cuales los proyectos de desarrollo fracasan o por lo menos no tienen el xito que deberan, se debe a
una mala administracin de requerimientos. Esto generalmente se da por falta ya sea de habilidades en el
personal responsable o de tcnicas apropiadas utilizadas para llevar a cabo esta labor.
La administracin de requerimientos, de acuerdo a CMM, abarca actividades como la recopilacin,
documentacin, validacin y control de los requerimientos y sus cambios. UML, como estndar integrador
de las buenas prcticas de desarrollo nos ofrece en este sentido los casos de uso como una tcnica
excelente para administrar los requerimientos de nuestros proyectos.

Consultora

Manufactura?

Si queremos realizar una verdadera consultora de software entonces nos corresponde algo ms que
escuchar la lista de funciones que el cliente cree que debera de tener su sistema (a menos que nuestro
cliente tenga un rea con la capacidad de realizar una buena recopilacin y anlisis de requerimientos).
Si nos limitramos a lo primero entonces en lugar de llamarle consultora a nuestro trabajo, deberamos
llamarle manufactura de software, donde uno implementa las funciones exactamente como se las solicita el
cliente, cuestionando nada o muy poco, tal como se hara en una planta manufacturera donde se reciben las
especificaciones
del
producto
a
construir.
El

Sistema

su

Misin

Si queremos desarrollar el mejor sistema posible debemos realizar un trabajo serio para identificar, en primer
lugar, cul es el valor que el sistema debe proporcionar al negocio. Para lo cual habr que preguntrselo a las
personas que obtendrn alguna clase de beneficio cuando se ponga en operacin. Una buena parte de estas
personas probablemente vayan a ser usuarios del sistema; en UML los conocemos como Actores (ms
adelante
veremos
otros
tipos
de
Actores
que
tambin
tendremos
que
identificar).
Buscando

los

Beneficios

del

Sistema

Una vez identificados los usuarios del sistema (actores primarios) habr que preguntarles en qu situaciones
valdr la pena para ellos utilizarlo. La lista identificada de dichas situaciones no debera de tener pequeas
funciones, sino flujos completos que le proporcionen suficiente valor tanto a ellos como al negocio, de manera
que
valga
la
pena
usar
el
sistema
en
dichas
situaciones.
Ejemplo: un vendedor en cierto sistema de ventas querr Registrar venta, Registrar pedido, Consultar
comisiones, Administrar prospectos, Generar factura y Administrar clientes. Todas ellas son ejemplos de
situaciones u objetivos importante que podra necesitar un vendedor para llevar a cabo su trabajo, conocidas y
modeladas como casos de uso en UML, tal como se muestra en el diagrama.

Diagrama de casos de uso para el sistema de venta

Los

Requerimientos

Funcionales

Normalmente los casos de uso son iniciados por algn actor, conocido como actor primario. Lo inicia con
algn evento, que podra ser tan simple como elegir una opcin en el sistema, y contina como una serie de
eventos o interacciones entre actores y sistema, hasta que el objetivo del caso de uso se cumple (el objetivo
principal del caso de uso es lo que le da el nombre al mismo). Por lo tanto los casos de uso describen la
funcionalidad
del
sistema
para
alcanzar
objetivos
importantes.
Lo que estamos obteniendo as es una especificacin de requerimientos funcionales mediante un anlisis topdown (de lo general a lo particular), es decir, primero obtenemos los objetivos que hay que cumplir en el
sistema descritos con el nombre del caso de uso (p. ej: Realizar una venta) y despus buscamos cules son
las funciones o requerimientos funcionales precisos y ordenados para que el actor cumpla dicho objetivo al
utilizar sistema. Esto nos lleva a identificar requerimientos realmente relevantes para alcanzar la misin del
sistema.
Resumen para recopilar los requerimientos funcionales adecuados del sistema mediante casos de uso:
1.
Especificar
la
misin
del
sistema
2.
Identificar
quines
utilizarn
el
sistema
(actores
primarios)
3. Averiguar cules objetivos desean cumplir los actores al usar el sistema (casos de uso)
4. Identificar los pasos o eventos de cada caso de uso (especificacin del caso de uso)

Las

Interfases

del

Sistema

Hay otro tipo de actores que tambin hay que modelar; los actores secundarios. Suelen ser otros sistemas,
componentes externos o dispositivos con los cuales interacta nuestro sistema. A diferencia de los actores
secundarios, stos no son los que inician o requieren del caso de uso, sino que nuestro sistema, al llevar a
cabo
un
caso
de
uso
requiere
tener
algn
tipo
de
interaccin
con
l.
En el diagrama de casos de uso tambin suele ser apropiado mostrar a este tipo de actores, en cuyo caso
aparecern asociados a los casos de uso durante los cuales tienen que intervenir con algn tipo de
interaccin con el sistema a modelar.
Ejemplo de Actor 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 experiencia 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 la
simplicidad, ya que facilita el anlisis, entendimiento y comunicacin entre quienes solicitan el sistema y los
que
participan
en
su
desarrollo.
En otras oportunidades veremos elementos adicionales para modelar los casos de uso, pero podemos
asegurar que la sencillez es parte importante del modelado, y esto implica que en ocasiones, y sobre todo
cuando el analista no tiene tanta experiencia en UML, es mejor limitarnos a los elementos ms bsicos.
Publicado en la revista Software Gur.
Reproducido con permiso del autor.

Temas relacionados:
Curso de anlisis y diseo orientado a objetos con UML