8. DIAGRAMAS DE CLASES

18 de marzo de1999

Son los diagramas más comunes en el modelado de sistemas orientados a objetos.

Un diagrama de clase muestra un conjunto de clases, interfaces, y colaboraciones y sus relaciones entre ellos.

Los diagramas de clase se usan en el diseño del modelo estático para ver un sistema. Para las demás partes, este modelado involucra el vocabulario del sistema, el modelado de colaboraciones, o modelado de esquemas. Los diagramas de clase son también la base para un par de diagramas relacionados: Diagramas de Componente y Diagramas de Instalación(Deployment).

Los diagramas de clase son importantes no solo para la visualización, especificación y documentación del modelo estructural, pero también para la construcción de sistemas ejecutables. Ingeniería hacia adelante e ingeniería inversa.

La construcción de software tiene muchas características similares, excepto, que la calidad(Fluidez) de software, uno tiene la habilidad de definir la construcción de bloques básicos para ir detallando(scratch).

UML, usa los diagramas de clase para visualizar el aspecto estático de esa construcción de bloques y sus relaciones y especificar esos detalles para la construcción, que se puede ver en la fig. 8-1.


 
 

Términos y Conceptos.

Un diagrama de clases muestra un conjunto de clases, interfaces, y colaboraciones y sus relaciones. Gráficamente un diagrama de clase es una colección de vértices y arcos.

Propiedades comunes: Un diagramas de clase es justo un tipo especial de diagrama y comparte propiedades comunes al igual que todos los otros diagramas -un nombre y un contenido gráfico son una proyección dentro de un modelo.

Contenido.

Un diagrama de clases comúnmente con tiene lo siguiente:

Los otros diagramas de clase pueden contener notas y restricciones. Los diagramas de clase pueden también contener paquetes o subsistemas ambos de los cuales son usados para agrupar elementos de su modelo. Algunas veces se quieren instancias de lugar en el diagrama de clases, como también especialmente cuando se quiere visualizar el tipo de una instancia(posibilidad dinámica).

Usos comunes:

- Modelado del diseño estático de un sistema. Esta vista en primer lugar soporta los requerimientos funcionales de un sistema - el servicio del sistema debería de proveer este a los usuarios finales.

Para el modelo de diseño estático de la vista de un sistema, típicamente se usan diagramas de clases en alguna de estas tres alternativas:

  1. Modelo del vocabulario de un sistema. El modelo del vocabulario de un sistema involucra tomar decisiones acerca de las cuales son parte del sistema y cuales quedan fuera del ambiente. Los diagramas de clase especifican estas abstracciones y sus responsabilidades.
  2. Modelado simple de colaboraciones. Una colaboración es una sociedad de clases, interfaces, y otros elementos, estos trabajan juntos para proveer igual comportamiento de colaboración, esto es más grande que la suma de todos los elementos. Por ejemplo, cuando se esta modelando la semántica de una transacción en un sistema distribuido, no se puede fijar la vista en una simple clase, para entender cual irá. Esta semántica es llevada fuera por un conjunto de clases que trabajan juntas. Los diagramas de clases se usan para visualizar y especificar este conjunto de clases y sus relaciones.
  3. Modelo lógico del esquema de la base de datos. Pensar en un esquema como la eliografía(dibujo) para el diseño conceptual de una base de datos. En muchos dominios se quiere almacenar mucha información persistente en una base de datos relacional o en base de datos orientada a objetos. Se pueden modelar esquemas para estas bases de datos usando diagramas de clases.
TECNICAS COMUNES DE MODELADO

Modelado de Colaboraciones Simples.

Las clases no están solas, cada trabajo en colaboración con otros genera semántica igual de grandiosa que cada una de manera individual. Por lo tanto, en agregación a la captura del vocabulario del sistema, también es necesario poner la atención en la visualización, especificación, construcción y documentación de varios caminos esto junto al vocabulario de trabajo. Se usa el diagrama de clases para representar tales colaboraciones.

Cuando se crea un diagrama de clases se modela una parte de los elementos y el conjunto de relaciones de vistas del diseño del sistema. Por esta razón, cada diagrama de clase debería centrarse en una colaboración en un tiempo.

Para Modelar una colaboración.

Por ejemplo fig. 8-2, muestra un conjunto de clases dibujadas para la implementación de un robot autónomo. La figura se centra en las clases involucradas en el mecanismo para el movimiento del robot en una sola ruta. Se encuentra una clase abstracta(motor) con dos hijos en concreto, SteeringMotor y MainMotor. Ambas clases heredan las cinco operaciones de su padre, Motor. Las dos clase permiten, girar, muestran como partes de otras clases Driver. La clase PathAgent tiene una asociación uno-a-uno con la clase Driver y una asociación uno-a-muchos con CollisionSensor. Los atributos y operaciones no son mostradas por PathAgent, no obstante son responsabilidades dadas.

Son muchas mas las clases involucradas en este sistema, pero este diagrama se centra solo en esas abstracciones, esas son las involucradas directamente en el movimiento del robot.



Modelado lógico del esquema de la base de datos.

Muchos de los sistemas a modelar tienen objetos persistentes, con lo cual por medio de ellos pueden ser almacenados en una base de datos para recuperarse mas tarde. Muy frecuentemente se usa una base de datos Relacional, una base de datos orientada a objetos, o un híbrido BD relacional/objetos para almacenar lo persistente. El UML soporta también el modelo lógico del esquema de la base de dato, como también la base de datos física.

En UML los diagramas de clase son un super conjunto de los diagramas E-R(Entidad-Relación), comúnmente las herramientas de modelado para el diseño lógico de la base de datos. Donde clásicamente los diagramas E-R se contraen en los datos, los diagramas de clase van mas allá por permitir el modelado del comportamiento también. En la base de datos física, esas operaciones lógicas son generalmente asignadas entre los triggers o procedimientos almacenados.
 
 

Para modelar un esquema.

Fig. 8-3 muestra un conjunto de clases de un sistema de información para una escuela. Esta fig. expande un diagrama de clases y permite ver el detalle de esas clases revelando un nivel suficiente para la construcción física de la base de datos. Empieza con el botón izquierdo de este diagrama, en él puedes encontrar la clase de nombre Student, Course e Instructor. Esto es una asociación entre Student y Course, especificando que un estudiante asiste a cursos. Además, todo estudiante puede asistir a cualquier número de cursos y todos los cursos pueden tener cualquier número de estudiantes.

Todas las seis de estas clases son marcadas como persistentes, indicando a sus instancias que están intentando vivir en una base de datos o de igual forma persistir almacenados. Este diagrama también expone los atributos de las seis clases. Nota que todos esos atributos son de tipo primitivo. Cuando se modela un esquema, generalmente se quiere modelar las relaciones para cualquier tipo no primitivo usando una agregación explícita en vez de un atributo.

Dos de esas clases(School y Department) muestran diferentes operaciones para la manipulación de sus partes. Estas operaciones son incluidas porque ellas son importantes para el mantenimiento en la integridad de datos.(Por ej. Agregar o borrar un departamento). Son muchas otras operaciones que se deben considerar para esto y para otras clases, tal como consultas de los prerequisitos de un curso antes de asignar un estudiante. Estas son muchas reglas de negocios que son operaciones para la integridad de la base de datos y también son el mejor lugar en un alto nivel de abstracción para este esquema.


 
 


Ingeniería hacia adelante e ingeniería inversa.

El modelado es importante, pero hay que recordar que el principal producto del desarrollo en equipo es el software, no los diagramas. Las razones de crear modelos es predecir el tiempo de liberación del software que satisfaga las metas de los usuarios y del negocio. Por esta razón, es importante que ese modelo que se crea y la implementación tengan un mapeo de uno a otro y también un camino este minimizado o uniforme eliminado los costos de manejar el modelo y la implementación en sincronía con otro diferente.

Para usos similares de UML, los modelos que se crean nunca deberían mapearse al código. Por ejemplo, si tu estas modelando el proceso de un negocio usando diagramas de actividad, muchas de las actividades del modelo involucran gente, no computadoras. En otros casos, se quiere modelar sistemas cuyas partes son, del nivel de abstracción, justo una pieza de hardware.(en otro nivel de abstracción, es bueno que el hardware contenga empotrado el calculo y el software).

En mas casos, la creación de modelos puede mapear al código. En UML no se especifica un mapeo particular a algún lenguaje de programación orientada a objetos, pero UML fue diseñado con tal mapeo en mente. Este es especialmente cierto para los diagramas de clase, con lo cual el contenido tiene un mapeo claro con todas las industrias fuertes de lenguajes orientados a objetos, tales como Java, C++, Smalltalk, Eiffel, Ada, Object-Pascal, y Forte. El UML fue diseñado para el mapeo a una variedad de lenguajes comerciales basados en objetos, tales como Visual Basic.
 
 

Ingeniería hacia adelante.

Es el proceso de transformar un modelo en código a un mapeo en un lenguaje de implementación. La ingeniería hacia adelante resulta en una perdida de información, porque el modelo escrito UML es semánticamente más rico que cualquier lenguaje de programación orientado a objetos. De hecho esta es una mayor razón por lo que es necesario modelar en adición al código.

Características estructurales tales como colaboraciones, y características de comportamiento tales como interacciones pueden ser visualizadas claramente en UML , pero no son tan claras para un línea de código.

Un Diagrama de clases para la ingeniería hacia adelante:

Fig 8-4. Ilustra un simple diagrama de clase especificando una instanciación de series de modelos de responsabilidades. Esta instanciacion en particular involucra tres clases: Client, EventHandler, y GUIEventHandler. El Client y EvenHandler son mostradas como clases abstractas, donde como Guieventhandler es concreto. Event-handler tiene las operaciones usadas esperadas de este modelo(HandlerRequest), si bien dos atributos privados tienen que ser agregados para esta instanciación.





Todas esas clases especifican un mapeo a Java, como nota en su valor de marca. La ingeniería hacia adelante en estos diagramas de clases esta fuertemente ligado a java, usando una herramienta. La ingeniería hacia adelante de la clase EventHandler produce el siguiente código:

public abstract class EventHandler {

EventHandler successor;

private Integer currentEventID;

private String source;

EventHandler() {}

public void handleRequest() {}

}
 
 
 
 
 
 

Ingeniería inversa.

Es el proceso de transformar código en un modelo a un mapeo de la especificación del lenguaje de implementación. La ingeniería inversa es resultado de la abundancia de información, algo de lo cual esta en un nivel bajo de detalle que se necesita para construir modelos útiles. En algún momento la ingeniería inversa es incompleta. Esto trae pérdida de información de los modelos de la ingeniería hacia adelante al código, y también cuando no se puede recrear completamente un modelo de código a menos que las herramientas dosifiquen información en la fuente de comentarios semánticamente mas allá del lenguaje de implementación.

Un Diagrama de clases para la ingeniería inversa: