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
+
.
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

Modelando con Clase:
El Rey de la Orientación a Objetos

Por Sergio Orozco y Carlos Macías

Si alguien se lleva la corona en UML lo más probable es que sean las clases, finalmente todo surgió en un principio en UML debido a la necesidad de unificar los criterios para la representación de la orientación a objetos, y las clases son un elemento básico en este paradigma. Cabe decir, que lo que hemos visto hasta el momento, en las ediciones anteriores de esta sección, son de alguna manera el preámbulo para llegar a un buen diseño de clases del sistema apropiado para nuestro cliente.

Por supuesto que cada artefacto tiene un valor importante en el ciclo de vida. Los casos de uso ayudándonos a identificar y a validar mejor con el usuario sus necesidades; el modelo conceptual (un previo del diagrama de clases) permitiéndonos comprender mejor el problema del usuario para lograr una mejor solución; el diagrama de interacción mostrándonos la colaboración entre los objetos para ejecutar un proceso o un caso de uso.

Pero, además todos estos realizando su aportación para llegar al punto que trataremos en esta ocasión: el diseño de las clases que constituirán nuestro sistema. Los casos de uso aportaron en este sentido la identificación de las posibles clases mediante un análisis del dominio que se reflejó en un modelo conceptual. El caso de uso junto con el modelo conceptual posteriormente fueron usados como base para definir una serie de interacciones en los diagramas de secuencia y comunicación.

Efectos del Diagrama de Interacción en las Clases

En este caso vamos a ver cómo las decisiones que tomamos en estos diagramas se pueden ver reflejadas en el diagrama de clases para definir algunas de sus características principales, como son la funcionalidad a implementar en cada una de las clases, así como las relaciones entre estas.

¿Qué es lo que tenemos hasta el momento en nuestro diagrama de clases, según lo trabajado previamente? Contamos con candidatas a ser clases de diseño de nuestro sistema con sus posibles atributos y relaciones (las obtenidas en el modelo conceptual). Como se puede ver en el siguiente ejemplo de una parte del modelo conceptual obtenido al analizar una terminal punto de venta (TPV).


Figura 1. Modelo conceptual del punto de venta


El diagrama de clases de diseño al que llegaremos, por lo menos en la capa de negocio, probablemente tenga un gran parecido al modelo conceptual que mostramos. Entre los cambios más importantes está la aparición de operaciones y el refinamiento de las relaciones, que se verán reflejadas en el código como la funcionalidad asignada en cada clase de nuestro sistema y en el mecanismo de comunicación entre ellas, respectivamente.

Las Relaciones y los Mensajes

¿Cómo nos puede ayudar el diagrama de interacción para refinar nuestras clases de diseño? En primer lugar, para identificar relaciones entre dos clases sólo hay que observar cuáles son las clases que se comunican en el diagrama de interacción, y representarlas con algún tipo de relación en el diagrama de clases.


Figura 2. Diagrama de secuencia para “Realizar Venta”

Como ejemplo, en el diagrama de secuencia anterior, se vé cómo la clase TPV (en realidad las instancias de esta clase) requiere comunicarse con Venta para enviarle mensajes, y a su vez Venta requiere comunicarse con los objetos de la clase RenglonVenta. Esto significa que en el diagrama de clases tendremos que mostrar una relación con navegabilidad de TPV a Venta, y otra de Venta a RenglonVenta.


Figura 3. Relaciones obtenidas del diagrama de secuencia

Las relaciones mostradas en el diagrama de clases de diseño pudieron o no haber existido durante el modelo conceptual, pero es en este momento (en el diseño) donde se toma la decisión final con respecto a las relaciones a incluir en la construcción (implementación) del sistema orientado a objetos, de conectar o no dichas clases. Recuerda que con fines de diseño, el modelo conceptual no es más que un previo o bosquejo de lo que podría ser nuestro sistema.

Cabe aclarar que el tipo específico de relación se define de una manera más elaborada, tema que será tratada en ediciones posteriores de esta sección. Sólo para no dejar un hueco en la descripción de nuestro ejemplo hay que mencionar que las relaciones aquí mostradas corresponden a una dependencia y composición respectivamente.

Los Mensajes y las Operaciones

Las operaciones son uno de los elementos de UML más relevantes para la implementación del sistema, pues son el elemento más básico donde se ubicará la funcionalidad de nuestro sistema. Una identificación adecuada de las operaciones de cada clase es clave para el desarrollo de un sistema de calidad. Incluso facilitará el contar con cualidades como el reuso y la mantenibilidad del mismo.

El realizar un diagrama de secuencia con una perspectiva de diseño nos puede ayudar a identificar y a ubicar de una mejor manera estas operaciones en sus correspondientes clases. Cuando existe un mensaje entre dos objetos tenemos que tomar la decisión de diseño de usar o no dicho mensaje como una llamada a operación, esto significa que la clase receptora del mensaje tendrá asignada dicha operación en el diagrama de clases de diseño.

Si volvemos al ejemplo del diagrama de secuencia mostrado anteriormente, podemos observar cómo los cuatro mensajes corresponden a llamadas a operaciones de las clases. Dos de estas operaciones corresponden a constructores de las clases y las otras dos a métodos tradicionales implementadas en las clases que reciben los mensajes.

La clase Venta recibe el mensaje agregarRenglonVenta( ) y registrarPago( ), lo cual se traduce en el diagrama de clases como dos operaciones en dicha clase, como podemos observar en el siguiente ejemplo de un diagrama de clases más elaborado.


Figura 4. Operaciones obtenidas del diagrama de secuencia


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





Cambios previstos para el PMBOK® Guide 6ta edición (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. PMBOK, PMP, Project Management Professional, Project Management Professional (PMP), PgMP, Program Management Professional (PgMP), PMI-RMP, PMI Risk Management Professional (PMI-RMP), CAPM, Certified Associate in Project Management (CAPM), PMI-SP, PMI Scheduling Professional (PMI-SP), THE PMI TALENT TRIANGLE and the PMI REP Logo are registered marks of the Project Management Institute. 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. 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.