Busca en este sitio:
Twitter
. Soy Novato
. Soy Gerente de Proyectos
. Quiero ganar más
. Quiero mejorar a mi empresa
y sus proyectos
. Tengo experiencia, pero no soy experto
. Soy experto (o eso creo)
.
.

Contáctanos
Escríbenos a:
contacto@liderdeproyecto.com
Para información de cursos:
cursos@liderdeproyecto.com

Teléfono en México D.F:
+52 (55) 2652 4590


Aviso de privacidad
+
.
Aliados del PMI® México

LiderDeProyecto.com es aliado estratégico del PMI® Capítulo México.
+
.
Humor del Líder

Problemas de comunicación
+
.
Glosario
Ven a conocer el glosario de administración de proyectos. Nuevas definiciones: Condiciones, Diagrama de flujo, Proceso de negocio, Producción, Secuencia.
+
.
Colaboradores

Conoce a los colaboradores de LiderDeProyecto.com. Tu puedes ser uno de ellos.
+
.
 
UML

Brindándole un Hogar al Software:
Diagramas de Distribución

Por Sergio Orozco y Carlos Macías

Imagina tu casa con un televisor de plasma de 50 pulgadas, un refrigerador que te envía mensajes cuando la leche o el huevo está por terminarse, una estufa con parrilla electrónica que se apaga sola, una sala de piel que da masajes y autoregula su temperatura, dos líneas telefónicas con teléfonos inalámbricos de 5.8 Ghz de largo alcance, una cama king size automática con masajes, todo esto para ser disfrutado por ti, por tus padres y tus cinco hermanitos. De fantasía, ¿cierto? Todo esto en una maravillosa casa duplex de interés social de 70 metros cuadrados. ¡Espera! ¿maravillosa casa duplex para todo esto? Hablemos de incongruencias. No parece ser el lugar más apropiado para tener todas esas comodidades, ¿cierto?

Soñar no Cuesta, No Planear Sí

Antes de decidir comprar todos esos componentes tienes que asegurarte que van a caber o van a funcionar en tu casa. Y si no caben, y tienes el presupuesto, tendrás que mudarte a otra casa más apropiada.

Bueno, pues eso mismo sucede con el desarrollo de software. Antes de decidir desarrollar una aplicación con ciertos requerimientos, tienes que asegurarte que cuentas con la infraestructura apropiada para ponerlos a funcionar sin problema. Si no cuentas con ella tendrás que decidir cuál será el equipo y ambiente adecuado (computadoras, servidores, sistemas operativos, etc) para instalar y hacer funcionar tu aplicación. Por supuesto, restringiéndote al presupuesto disponible para tal fin.

Antes de llenar tu casa con todo tipo de muebles y componentes seguramente visualizarás si tu casa tiene espacio donde colocarlos. Si eres suficientemente precavido evaluarás si la instalación eléctrica o hidráulica es la apropiada para que funcionen correctamente. Si eres un diseñador de interiores o un arquitecto bosquejarás algún plano para asegurarte de estar tomando la decisión correcta.

Así mismo ocurre en el caso del software, antes de desarrollar un conjunto de componentes que formarán una aplicación, pensarás si el equipo e infraestructura con la que cuentas es apropiada para dicho sistema. Antes de desarrollar el software, e incluso antes de comprometerte con tu cliente a desarrollarlo, tendrás que asegurarte de identificar si se cuenta con el equipo apropiado o con el presupuesto para adquirirlo y así poder hacer funcionar correctamente la aplicación.

Proponer o Restringir

Al inicio del proyecto, en lo que podemos llamar fase de Inicio o Concepción (“Inception”) en el caso del Proceso Unificado, tendrás que desarrollar un primer diagrama de distribución para identificar las restricciones físicas de hardware en el proyecto (el equipo e instalaciones con las que cuenta el cliente para el proyecto), o en su defecto documentar el hardware propuesto en el cual se tendrá que invertir para hacer funcionar el software.

En la fase posterior, la de Elaboración, este diagrama tendrá que ser refinado para dejar especificadas las decisiones tomadas con respecto a esta perspectiva del sistema.

El diagrama de distribución es el artefacto de UML que nos permite representar los elementos físicos de un sistema; lo que mucha gente conoce tradicionalmente como la arquitectura física. En este puedes visualizar las computadoras (clientes, servidores, PDAs), elementos adicionales de hardware (impresoras, ruteadores) y las conexiones (la red). Incluso puedes indicar qué sistema operativo corre en una computadora o en cuál de las computadoras pondrás a correr ciertos componentes de tu aplicación.

Los componentes de software realizan la dinámica de un sistema; representan agregaciones de clases. Son los moldes de fabricación que construyen a los objetos que colaboran en tiempo de ejecución para llevar a cabo lo que especifican los requerimientos. Estos componentes tienen que ser colocados en el hardware para que los podamos usar. Entender la manera, lugares y necesidades que los alojarán es un factor importante en la definición del dominio de la solución.

Elementos del Diagrama de Distribución

Nodo. Representa un recurso de cómputo que puede alojar artefactos y que se puede interconectar con otros nodos para describir topologías de redes.

Dispositivo. Representa un recurso físico de cómputo que posé capacidad de procesamiento; se representa igual que un nodo.

Entorno Ejecutable. Representa un recurso lógico de cómputo dentro del cual se alojan manifestaciones de componentes de cierto tipo.

Rutas de Comunicación. Asociación que se modela sólo entre objetivos de distribución (nodos, dispositivos o entornos ejecutables) indicando que estos pueden intercambiar mensajes y señales.

Componente. Representa unidades autocontenidas de software que realizan a las clases o a cualquier elemento empacable

Artefacto. Representa la manifestación de un componente en el mundo físico.



Figura 1. Dos recursos de cómputo con capacidad de procesamiento
conectados y alojando artefactos.

Un Artefacto no es una Ilusión

Un concepto que para muchos resulta difícil de entender es el del artefacto. Especialmente por su relación con el concepto de componente. El nivel de abstracción es diferente en ambos casos, aunque podemos estarnos refiriendo en cierta situación a elementos muy similares.

Por más extraño que parezca, ni las clases ni los componentes se ejecutan en el hardware, ya que estos tipos de elementos carecen de manifestación en el mundo físico. Para lograr la manifestación de las clases y componentes necesitamos un artefacto.

Un artefacto es una pieza de información física que usa o produce un proceso de desarrollo de software, una distribución o el funcionamiento de un sistema. Ejemplos de artefactos son los archivos que distribuímos en el hardware, como los archivos JAR, WAR, EAR, EXE y DLL. En la siguiente figura podemos observar la relación que existe entre el concepto tradicional de componente y el artefacto donde se manifiesta.



Figura 2. Relación entre el artefacto y el componente manifestado


Ambientando la Casa

Los componentes necesitan de un ambiente donde se ejecutarán. Si deseas dejar graficamente documentada esta información
El ambiente de ejecución se puede representar de manera similar a los nodos, es decir, en forma de cubo. Sólo que dicho ambiente se aloja dentro de un dispositivo, como se puede ver en la ilustración.



Figura 3. Artefacto que se ejecuta en un ambiente
de ejecución dentro de un dispositivo.

Así que antes de decidir llenarte de comodidades asegúrate de contar con el espacio y las características necesarias en tu casa. Antes de invertir en la compra o desarrollo de un software asegúrate que tendrá un hogar apropiado donde hospedarse.

Publicado en la revista Software Gurú.
Reproducido con permiso del autor.


Temas relacionados:
Curso de análisis y diseño orientado a objetos con UML


indice del manual



Nancy dijo el 26 Abril de 2011:
alguien puede decirme como hacer un diagrama de distribucion (uml) si quiero hacer un sw que es acerca de un sistema para un negocio de una pasteleria

CARLOS ALBERTO RICO URREGO dijo el 16 Septiembre de 2010:
Muy buen ejemplo, con una metáfora muy entendible.
Gracias.



Mejores prácticas para definir la estrategia de un proyecto (Raymundo Sánchez Ticó)
+
.
.
.
Quienes somos I Base de conocimiento I Apoyo y servicios profesionales I Carrera y desarrollo profesional I Material de apoyo I Productos y souvenirs I Comunidad I Contacto I Aviso de privacidad
© LiderDeProyecto.com - Todos los derechos reservados. Capability Maturity Model® y CMM® son marcas registradas en la Oficina de Patentes de los EUA por el Software Engineering Institute (SEI) de la Universidad Carnegie Mellon®. CMM® IntegrationSM, IDEALSM y SCAMPISM son marcas de servicio de la Universidad Carnegie Mellon. PMI®, PMBOK® Guide, OPM3®, CAPM® y PMP® son marcas registradas (en EUA y otos países) del Project Management Institute, Inc. MDA®, BPMN®, SysML®, MOF®, OMG® y UML® son marcas registradas en los EUA y en otros países por el Object Management Group. Microsoft® es una marca registrada en los EUA y en otros países; Microsoft Office, Microsoft Excel y Microsoft Project son productos propiedad de Microsoft Corp. Enterprise Architect es un producto propiedad de Sparx Systems, Australia. RUP® es una marca registrada por IBM Corp.