Desarrollo de Proyecto de software

DIRECCIÓN GENERAL DE EDUCACIÓN SUPERIOR TECNOLÓGICA

INSTITUTO TECNOLOGICO DE ACAPULCO

“Educación Tecnológica con compromiso social”

INGENIERIA EN SISTEMAS COMPUTACIONALES

DIAGRAMAS DE CLASES, INTERACCIÓN Y DE ESTADOS.

Desarrollo de Proyecto de software

Noé de la Cruz Montes de Oca

Maestro: Cesar Augusto Sebastián Gómez

26 de abril de 2013

Diagramas de clases 3

Perspectivas 4

Clases 4

Compartimento del nombre 5

Compartimento de la lista de atributos 5

Relaciones en un diagrama de clases 6

• Relación de asociación 7

• Relación de dependencia 7

• Relación de generalización 7

Asociación 7

• Nombre 7

• Rol 7

• Multiplicidad 8

• Restricciones 8

Tipos de asociación 8

1. Asociación normal 8

2. Agregación 9

• Agregación normal 9

• Agregación compartida 9

• Agregación de composición 9

Ejemplos de asociaciones normales 10

Ejemplos de agregaciones 11

Dependencia 11

• bind 12

• derive 12

friend 12

• powertype 12

• refine 13

Ejemplos de dependencias 13

Diagramas de interacción 14

Diagramas de secuencia 16

Diagrama de colaboración 17

Enfatiza la organización estructural de los objetos que envían y reciben mensajes. Gráficamente, es una colección de vértices y arcos. 17

Para hacer un diagrama de secuencia 17

Para hacer un diagrama de colaboración 18

Diferencias entre los diagramas se secuencia y colaboración Diagrama de secuencia: 18

Diagrama de colaboración: 18

Usos comunes 18

1. Para modelar flujos de control por orden de tiempo 19

2. Para modelar flujos de control por organización 19

Modelando flujos de control por orden de tiempo 19

Modelando flujos de control por organización 20

Ingeniería hacia delante (creación de código desde un modelo) 21

Ingeniería inversa (creación de un modelo desde código) 22

Diagramas de estado 22

Casos de uso reales 26

Diagramas de colaboración 26

Bibliografía 31

Diagramas de clases

Los diagramas de clases se utilizan para modelar la visión estática de un sistema. Esta visión soporta los requisitos funcionales del sistema, en concreto, los servicios que el sistema debería proporcionar a sus usuarios finales. Normalmente contienen: clases, interfaces y relaciones entre ellas: de asociación, de dependencia y/o de generalización.

Los diagramas de clases también pueden contener a paquetes o subsistemas, que se usan para agrupar elementos del modelo en partes más grandes (por ejemplo, paquetes que a su vez contienen a varios diagramas de clases).

Al igual que otros diagramas, en los diagramas de clases pueden aparecer notas explicativas y restricciones.

Perspectivas

Según Fowler, hay tres perspectivas que podemos tener en cuenta a la hora de dibujar los diagramas de clases (o cualquier otro tipo de diagrama, pero es más evidente en los diagramas de clases):

• Conceptual: Estamos dibujando un diagrama que representa los conceptos del dominio del sistema. Estos conceptos se relacionarán de forma natural con las clases que los implementen, pero a menudo no hay una aplicación directa. Es decir, el modelo se dibuja sin tener en cuenta el software que lo implementa y generalmente es independiente del lenguaje de programación.

• Análisis: Desde el punto de vista del software, nos fijamos en las interfaces del software, no en su implementación. Es decir, miramos los tipos más que las clases.

El desarrollo orientado a objetos pone mucho énfasis en la diferencia entre tipo y clase, pero luego no se aplica en la práctica. Es importante separar interfaz (tipo) de implementación (clase). Muchos lenguajes de programación no lo hacen y los métodos, influidos por ellos, tampoco. Esto está cambiando, pero no lo suficientemente rápido (Java y CORBA tendrán algo de influencia aquí). Los tipos representan una interfaz que puede tener muchas implementaciones diferentes debidas, por ejemplo, a las características del entorno de instalación.

• Implementación: Estamos poniendo la implementación al descubierto, pues realmente tenemos clases. Es la perspectiva más utilizada, pero de todas formas la perspectiva del análisis se considera la mejor de las tres.

Clases

Las clases describen un conjunto de objetos con características y comportamiento idénticos, es decir, objetos que comparten los mismos atributos, operaciones y relaciones.

Las clases se representan gráficamente por medio de un rectángulo con tres divisiones internas. Los tres compartimentos alojan el nombre de la clase, sus atributos y sus operaciones, respectivamente. En muchos diagramas se omiten los dos compartimentos inferiores. Incluso cuando están presentes, no muestran todos los atributos y todas las operaciones. Por ejemplo, en la Figura 3.1 viene representada la clase Ventana de tres formas diferentes: sin detalles, detalles en el ámbito de análisis y detalles en el ámbito de implementación.

Compartimento del nombre

Cada clase debe tener un nombre que la distinga de las otras clases. Dicho nombre puede ser un nombre simple (nombre de la clase) o un nombre compuesto (nombre del paquete que contiene a la clase :: nombre de la clase).

En el ejemplo de la Figura 3.1 Ventana es un nombre simple de clase; pero si estuviese contenida en el paquete Gráficos, entonces el nombre compuesto sería Gráficos::Ventana. Otra forma de representar dicho nombre compuesto es escribir dentro de este compartimento primero el nombre del paquete (en este caso, «Gráficos») y debajo el nombre de la clase contenida en él.

Compartimento de la lista de atributos

Los atributos describen las características propias de los objetos de una clase. La sintaxis completa de un atributo es:

[visibilidad] nombre [multiplicidad] [: tipo] [= valor-inicial]

[{lista-propiedades}]

donde visibilidad puede ser:

• + (pública): que hace el atributo visible a todos los clientes de la clase;

• - (privada): que hace el atributo visible sólo para

...