Diagramas de clases



Descargar 12.1 Kb.
Fecha de conversión20.12.2017
Tamaño12.1 Kb.

Diagramas de clases

Las clases representan los bloques de construcción más importantes de cualquier sistema orientado a objetos. Una clase es una descripción de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semántica. La representación gráfica de clases en UML se muestra en la siguiente figura.


Esta notación es independiente de cualquier lenguaje de programación. El primer bloque de la figura representa el nombre de la clase, el segundo bloque contiene los atributos, y el tercer bloque contiene las operaciones. El nombre de la clase puede ser simple (ej: Figura) o puede indicar el camino completo (paquete) donde reside la clase (ej: Grafico::Figura). En la definición de los atributos se pueden incluir sus tipos (ej: altura:Real). Lo mismo para las operaciones (ej: mover(a:int, b:int):boolean).

No es necesario mostrar todas las características. A veces las clases tienen tantas características, que no es conveniente mostrarlas todas. En estos casos también se pueden organizar las características usando estereotipos. Por ejemplo:


Responsabilidades

Una responsabilidad es un contrato o una obligación de una clase. Al modelar clases, un buen comienzo consiste en especificar las responsabilidades de los elementos. Una clase bien estructurada tiene al menos una responsabilidad (debería tener pocas). Gráficamente, las respondabilidades se expresan en una sección al final de la clase. Por ejemplo:






Uso de clases

Modelar el vocabulario de un sistema: Para modelar el vocabulario de un sistema, hay que identificar aquellas cosas que utilizan los usuarios para describir el problema o la solución. Para esto se pueden utilizar tarjetas CRC y análisis basado en casos de uso. Una vez identificadas las abstracciones, hay que identificar sus responsabilidades. El siguiente es un ejemplo del modelado del vocabulario de un sistema.




Modelar la distribución de responsabilidades: Para modelar la distrubución de responsabilidades en un sistema, hay que identificar un conjunto de clases que colaboren entre ellas para llevar a cabo algún comportamiento. Luego hay que identificar el conjunto de responsabilidades para cada clase. Por ejemplo:

Observe cómo estas clases colaboran de forma que ninguna clase hace mucho ni muy poco.



Relaciones

Las clases casi nunca se encuentran aisladas. Por lo general la mayoría de ellas colaboran con otras de varias maneras. Por tanto, al modelar un sistema también hay que modelar la forma en que las clases se ralacionan. En el modelado orientado a objetos hay tres tipos de relaciones: dependencias, generalizaciones y asociaciones.


Una dependencia es una relación de uso, que declara que un cambio en la especificación de un elemento (por ejemplo la clase Evento) puede afectar a otro elemento que la utiliza (por ejemplo la clase Ventana), pero no necesariamente a la inversa (la flecha va dirigida hacia el elemento del cual se depende). Una dependencia quiere decir que un elemento utiliza a otro.

Una generalización conecta una clase general (llamada superclase o padre) con otra clase más especializada (llamada subclase o hijo). Es una relación "es-un" o "es-una". Por ejemplo, el CuadroDialogo es una Ventana.

Las asociaciones son relaciones estructurales entre instancias, que especifican que los objetos de un elemento están conectados con los objetos de otro. Es legal que los objetos de una clases estén conectados con objetos de la misma clase. Hay cuatro tipos de "adornos" que se le pueden poner a estas relaciones: nombre, rol, multiplicidad y agregación. Ejemplo:




Nombre: Una asociación puede tener un nombre, que se utiliza para describir la naturaleza de la relación. Para evitar ambigüedades, se puede indicar una dirección al nombre, es decir, la dirección en que se debe leer el nombre.

Rol: Un rol es la cara que la clase de un extremo de la asociación presenta a la clase del otro extremo. Es el rol que juega la clase en la asociación.

Multiplicidad: Representa el número de objetos que pueden conectarse a través de una relación de asociación. Se puede indicar una multiplicidad de exactamente uno (1), cero o uno (0..1), muchos (0..*), o uno o más (1..*). También se puede indicar un valor exacto (por ejemplo, 3).

Agregación: A veces se desea modelar una relación de tipo "todo/parte", en la cual una clase representa algo grande (el todo), que consta de elementos más pequeños (las partes). Este tipo de relación se denomina agregación, y es una relación "tiene-un" o "tiene-una". Ejemplo:


Composición: La composición es un tipo especial de asociación, que también modela relaciones "todo/parte". La diferencia es que tiene una fuerte relación de pertenencia y vidas coincidentes de la parte con el todo. Las "partes" pueden crearse después del "todo", pero una vez creadas, viven y mueren con el "todo" (se pueden eliminar explícitamente antes). Quiere decir que una "parte", solamente puede estar relacionada con un "todo". Ejemplo:

En el siguiente ejemplo se muestran algunas de la relaciones antes descritas. Observen el poder de expresión de esta notación.




Algunos conceptos

Para diferenciar a las clases abstractas, el nombre de éstas se pone en cursiva. Las clases abstractas no pueden tener instancias directas. La visibilidad de una característica especifica si puede ser utilizada por otros objetos. Hay tres niveles de visibilidad en UML: public (cualquiera la puede usar, la característica es precedida por el símbolo +), protected (cualquier descendiente la puede utilizar, se especifica con el símbolo #), y private (solamente la propia clase la usa, se especifica con el símbolo -). El alcance de una característica define si la característica aparece en cada instancia de la clase, o si sólo hay una característica para todas las instancias. Para definir alcance de clase, las características se subrayan. Por defecto, las características tienen alcance de instancia. Ejemplo:


Hay otras propiedades poco utilizadas. Por ejemplo, leaf, que indica que una clase es una hoja, y por tanto no permite que otras clases herenden características de ella. La propiedad root indica que una clase no puede tener padres. Por ejemplo:


La multiplicidad define el número de instancias que puede tener una clase. Esta es 0, 1 o n. Por defecto, las clases tienen multiplicidad n. Si se quiere definir una multiplicidad diferente de n, hay que especificarla. Por ejemplo:





Esto quiere decir que la clase ControladorRed solamente puede tener una instancia. A su vez, para esta clase pueden haber dos o más puertoConsola.

Compartir con tus amigos:


La base de datos está protegida por derechos de autor ©composi.info 2017
enviar mensaje

    Página principal