DIAGRAMAS DE CLASES
This presentation is the property of its rightful owner.
Sponsored Links
1 / 10

DIAGRAMAS DE CLASES PowerPoint PPT Presentation


  • 139 Views
  • Uploaded on
  • Presentation posted in: General

DIAGRAMAS DE CLASES. Completando los diagramas de interacción, es posible identificar la especificación de las clases que participarán en la solución indicando detalles de su implementación, como por ejemplo los métodos. Entradas de los Diagramas de Clases

Download Presentation

DIAGRAMAS DE CLASES

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Diagramas de clases

DIAGRAMAS DE CLASES

Completando los diagramas de interacción, es posible identificar la especificación de las clases que participarán en la solución indicando detalles de su implementación, como por ejemplo los métodos.

  • Entradas de los Diagramas de Clases

  • Diagramas de interacción, a partir de ellos se identifica las clases de software y sus métodos.

  • Modelo conceptual, a partir de éste se agrega detalle a la definición de las clases.

Características

Un diagrama de clases (DCD) representa las especificaciones de las clases e interfaces de software (por ejemplo, las interfaces de java) en una aplicación. Entre la información general que entregan se encuentran:

  • Clases, asociaciones y atributos.

  • Interfaces con sus operaciones y constantes.

  • Información acerca del tipo de los atributos.

  • Métodos.

  • Navegabilidad.

  • Dependencias.

Modelo de Dominio vs Modelo de Diseño

En el modelo de dominio, una Venta no representa una definición de software, sino que se trata de una abstracción de un concepto del mundo real acerca del cual estamos interesados en realizar una declaración. En cambio, los DCD expresan (para la aplicación de software) la definición de las clases como componentes de software.


Diagramas de clases

DIAGRAMAS DE CLASES

Modelo de Dominio

vs

Modelo de Diseño


Diagramas de clases

DIAGRAMAS DE CLASES

Identificación y representación de las clases de software

El primer paso de los DCD como parte del modelo de la solución es identificar aquellas clases que participan en la solución software. Se pueden encontrar examinando todos los diagramas de interacción y listando las clases que se mencionan. El siguiente paso es dibujar un diagrama de clases para estas clases e incluir los atributos que se identificaron previamente en el modelo del dominio que también se utilizan en el Diseño.

Añadir los nombres de los métodos. Se pueden identificar los nombres de los métodos analizando los diagramas de interacción.

En general, el conjunto de todos los mensajes enviados a una clase X a lo largo de todos los diagramas de interacción indican la mayoría de los métodos que debe definir la clase X.


Diagramas de clases

DIAGRAMAS DE CLASES

Añadir los nombres de los métodos. Se deben tener en cuenta los siguientes aspectos especiales respecto a los nombres de los métodos.

  • Interpretación del mensaje create(): Por ser la inicialización una actividad muy común, se acostumbra a omitir los métodos de creación. Se supone por default.

  • Descripción de los métodos de acceso:

  • Son aquellos que establecen o recuperan el valor de los atributos.

  • Implican un accesor (de obtención) y un mutador (de cambio) para cada atributo.

  • Por su amplia utilización se omiten. Se suponen por defecto.

  • Se deben tener en cuenta los siguientes aspectos especiales respecto a los nombres de los métodos.

  • A. Interpretación de los mensajes dirigidos a multiobjetos: Un mensaje a un multiobjeto se interpreta como si estuviera destinado al objeto contenedor /colección. Estas clases contenedor/colección son clases predefinidas de las bibliotecas, y rara vez sirve mostrarlas explícitamente en el diagrama respectivo porque incorpora ruido y aportan escasa información nueva.


Diagramas de clases

DIAGRAMAS DE CLASES

Añadir los nombres de los métodos. Es opcional mostrar el tipo de los atributos, los parámetros del método y los valores de devolver método. El diagrama de clases orientado al diseño debería elaborarse teniendo en cuenta la audiencia:

  • Si vamos a crearlo con una herramienta CASE con generación automática de código se requerirán detalles completos y exhaustivos.

  • Si vamos a crearlo para los diseñadores de software, el exceso de información puede influir negativamente en su efectiva comprensión.

  • Incorporación de asociaciones y navegabilidad.

  • Cada extremo de la asociación se denomina Rol, y en los DCD el Rol podría decorarse con una flecha de navegabilidad.

  • Navegabilidad: propiedad del rol que indica posibilidad de navegar unidireccionalmente a través de la asociación desde los objetos de la clase origen a la clase destino.

  • La navegabilidad implica visibilidad – normalmente visibilidad de atributo.

Es necesario definir una asociación con una flecha de navegabilidad de A a B cuando: A envía un mensaje a B - A crea una instancia de B - A necesita mantener una conexión con B.

La mayoría, por no decir todas, las asociaciones en los DCD deberían adornarse con las flechas de navegabilidad necesarias.

Añadir relaciones de dependencia. UML incluye una relación de dependencia general, que indica que un elemento (de cualquier tipo, como clases, casos de uso, etc.) tiene conocimiento de otro elemento. Se representa mediante una flecha de línea punteada. En los diagramas de clase la relación de dependencia es útil para describir la visibilidad entre clases que no es de atributo; en otras palabras, la declaración de visibilidad de parámetros, local y global.


Diagramas de clases

DIAGRAMAS DE CLASES

1. 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 responsabilidades se expresan en una sección al final de la clase. Por ejemplo:

2. USO DE CLASES.Modelar la distribución de responsabilidades: Para modelar la distribució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.


Diagramas de clases

DIAGRAMAS DE CLASES

3. 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 relacionan. Las relaciones constituyen el camino para que se comuniquen los objetos.

Se examinan los diagramas de interacción para determinar qué tipo de relación entre objetos tiene que existir para que pueda darse el comportamiento deseado  Si 2 objetos necesitan comunicarse, debe haber una relación entre ellos. En el modelado orientado a objetos hay tres tipos de relaciones: dependencias, generalizaciones y asociaciones.


Diagramas de clases

DIAGRAMAS DE CLASES

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 clase 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).


Diagramas de clases

DIAGRAMAS DE CLASES

Empresa

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

1

*

Departamento

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). Significa que una "parte", solamente puede relacionarse con un "todo".

Ventana

1

1

Marco


Diagramas de clases

DIAGRAMAS DE CLASES

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


  • Login