Docente: Lic. Elisa Arizaca Ramirez Semestre: 6– A1. Fecha: 18/11/14.

UNIVERSIDAD SALESIANA DE BOLIVIA

INGENIERIA DE SISTEMAS

DIAGRAMAS DE CLASES

INTEGRANTES:

DANIEL DORIA MEDINA FRANCO

LUIS HUANCA ZABALETA

PABLO MAMANI ARHUATA

JUAN CARLOS BALERO MAMANI

OMAR CHIPANA ROCHA

PROJECT

DIAGRAMA DE CLASES

DEFINICION:Un diagrama de clases es un tipo de diagrama estático que describe la estructura de un sistema mostrando sus clases, atributos y las relaciones entre ellos.

Para que sirven:

 Los diagramas de clases son utilizados durante el proceso de análisis y diseño de los sistemas, donde se crea el diseño conceptual de la información que se manejará en el sistema, y los componentes que se encargaran del funcionamiento y la relación entre uno y otro.

•El propósito de este diagrama es el de representar los objetos fundamentales del sistema, es decir los que percibe el usuario y con los que espera tratar para completar su tarea en vez de objetos del sistema o de un modelo de programación.•La clase define el ámbito de definición de un conjunto deobjetos.•Cada objeto pertenece a una clase.•Los objetos se crean por instanciación de las clases.

DEPENDENCIAS

El diagrama de clases empieza en la fase de diseño del ciclo de desarrollo en el cual se desarrolla a través de información obtenida en los:

*Diagramas de Casos de Uso * Diagramas de Secuencia * Diagramas de Colaboración * Diagramas de estado *Diagramas de actividades *Diagramas de objetos.

Los objetos encontrados durante el análisis son modelados en términos de la clase a la que instancian, y las interacciones entre objetos son referenciados a relaciones entre las clases instanciadas.

1PACHAMAMA ENPIESA

NOTACION:

Clase : atributos, métodos y visibilidad. Relaciones : Herencia, Composición, Agregación, Asociación y Uso.

*Clases Una clase se representa mediante una caja subdividida en tres en tres compartimientos.

En donde la clase en la parte:

*Superior: Contiene el nombre de la Clase*Intermedio: Contiene los atributos (o variables de instancia) que caracterizan a la Clase (pueden ser private, protected o public).*Inferior: Contiene los métodos u operaciones, los cuales son la forma como interactúa el objeto con su entorno (dependiendo de la visibilidad: private, protected o public).

•Nombre de la clase

•Atributos de la clase

•Operaciones de la clase

Ejemplos

2: HUANCA DESDE NOTACION

Nombre de laClase 1

Atributo 1Atributo 2.................Operacion1( )Operacion2( ).................

Atributos y Métodos:

Atributos:Los atributos o características de una Clase pueden ser de tres tipos, los que definen el grado de comunicación y visibilidad de ellos con el entorno, estos son:

public (+, : Indica que el atributo será visible tanto dentro como fuera de la clase, es decir, es accsesible desde todos lados.

private (-, ): Indica que el atributo sólo será accesible desde dentro de la clase (sólo sus métodos lo pueden accesar).

protected (#, ): Indica que el atributo no será accesible desde fuera de la clase, pero si podrá ser accesado por métodos de la clase además de las subclases que se deriven (por herencia).

Métodos:Los métodos u operaciones de una clase son la forma en como ésta interactúa con su entorno, éstos pueden tener las características:

public (+, ): Indica que el método será visible tanto dentro como fuera de la clase, es decir, es accsesible desde todos lados.

private (-, ): Indica que el método sólo será accesible desde dentro de la clase (sólo otros métodos de la clase lo pueden accesar).

protected (#, ): Indica que el método no será accesible desde fuera de la clase, pero si podrá ser accesado por métodos de la clase además de métodos de las subclases que se deriven (por herencia).

*Relaciones entre Clases:

En el concepto de Clase, es necesario explicar como se pueden interrelacionar dos o más clases (cada uno con características y objetivos diferentes).

En UML, la cardinalidad de las relaciones indica el grado y nivel de dependencia, se anotan en cada extremo de la relación y éstas pueden ser:

Multiplicidad

HUANCA TERMINA Y ENPIESA 3 PANCRACIO O PABLO

Representa el número de objetos que pueden conectarse a través de una relación de asociación.

1 El atributo debe tener un único valor.0..1 El atributo puede o no tener un valor.0..* El atributo puede tener varios valores o ninguno. 1..* El atributo puede tener varios valores, pero debe ** El atributo puede tener varios valores.M..N El atributo puede tener entre M y N valores.

Ejemplos

1...*

Rol•Identificado como un nombre a los finales de la asociaci o describe la semántica de la relación en el sentido indicado.•Cada asociación tiene dos roles; cada rol es una dirección la asociación.

Ejemplo

Asociación: 

La relación entre clases conocida como Asociación, permite asociar objetos que colaboran entre si. Cabe destacar que no es una relación fuerte, es decir, el tiempo de vida de un objeto no depende del otro.

Trabaja_paraCompañíaPersona

Ejemplos:

Un cliente puede tener asociadas muchas Ordenes de Compra, en cambio una orden de compra solo puede tener asociado un cliente.

Agregación: 

Para modelar objetos complejos, no bastan los tipos de datos básicos que proveen los lenguajes: enteros, reales y secuencias de caracteres. Cuando se requiere componer objetos que son instancias de clases definidas por el desarrollador de la aplicación, tenemos dos posibilidades:

Por Valor: Es un tipo de relación estática, en donde el tiempo de vida del objeto incluido esta condicionado por el tiempo de vida del que lo incluye. Este tipo de relación es comunmente llamada Composición (el Objeto base se contruye a partir del objeto incluido, es decir, es "parte/todo").

Por Referencia: Es un tipo de relación dinámica, en donde el tiempo de vida del objeto incluido es independiente del que lo incluye. Este tipo de relación es comunmente llamada Agregación (el objeto base utiliza al incluido para su funcionamiento).

Un Ejemplo es el siguiente:

4 BALA

TERMINA PANCRACIO

En donde se destaca que:

Un Almacen posee Clientes y Cuentas (los rombos van en el objeto que posee las referencias).

Cuando se destruye el Objeto Almacen también son destruidos los objetos Cuenta asociados, en cambio no son afectados los objetos Cliente asociados.

La composición (por Valor) se destaca por un rombo relleno. La agregación (por Referencia) se destaca por un rombo transparente.

La flecha en este tipo de relación indica la navegabilidad del objeto refereniado. Cuando no existe este tipo de particularidad la flecha se elimina.

Herencia (Especialización/Generalización): 

Indica que una subclase hereda los métodos y atributos especificados por una Super Clase, por ende la Subclase además de poseer sus propios métodos y atributos, poseerá las características y atributos visibles de la Super Clase (public y protected),

ejemplo:

Vehículo

5 ALEX

- Ruedas- Puertas- Asiento+ Arrancar( )+ Acelerar( )+ Frenar( )+ Girar( )

En la figura se especifica que Auto y Camión heredan de Vehículo, es decir, Auto posee las Características de Vehículo (Precio, VelMax, etc) además posee algo particular que es Descapotable, en cambio Camión también hereda las características de Vehiculo (Precio, VelMax, etc) pero posee como particularidad propia Acoplado, Tara y Carga.

Cabe destacar que fuera de este entorno, lo único "visible" es el método Caracteristicas aplicable a instancias de Vehículo, Auto y Camión, pues tiene definición publica, en cambio atributos como Descapotable no son visibles por ser privados.

Dependencia o Instanciación (uso): 

Representa un tipo de relación muy particular, en la que una clase es instanciada (su instanciación es dependiente de otro objeto/clase). Se denota por una flecha punteada.

El uso más particular de este tipo de relación es para denotar la dependencia que tiene una clase de otra, como por ejemplo una aplicación grafica que instancia una ventana (la creación del Objeto Ventana esta condicionado a la instanciación proveniente desde el objeto Aplicacion):

6 DODO

Camión- Remolque+ Cargar( )

Ejemplo

Cabe destacar que el objeto creado (en este caso la Ventana gráfica) no se almacena dentro del objeto que lo crea (en este caso la Aplicación).

COMO ELABORAR UN DIAGRAMA DE CLASES DEL DISEÑO

Aplique la siguiente estrategia para elaborar diagramas de clases:

1. Identifique todas las clases que participan en la solución del software. Para ello analice los diagramas de interacción.

*El primer paso en la preparación de diagramas como parte del modelo de la solución del software es identificar las clases que intervienen en la solución del software.

Podremos encontrarlas con solo examinar todos los diagramas de interacción, y listarlas:

PACHACUTI 1Y2

2. Dibújelas en un diagrama de clases

El siguiente paso consiste en dibujar un diagrama de clases para estas, e incluir atributos y asociaciones del modelo conceptual.

No es necesario – en el actual ciclo de desarrollo – representarlos en el software.

3. Duplique los atributos provenientes del modelo conceptual:

Para identificar los métodos de las clases se analizan los Diagramas de Colaboración.

Por ejemplo, si el mensaje hacerLineadeProducto se envía a una instancia de la clase Venta, entonces deberá definir el método hacerLineadeProducto en Venta.

Nombres de los Métodos tomados de los Diagramas de Colaboración / Interacción:

HUANCA EL 3

En términos generales, el conjunto de los mensajes enviados a la clase X a través de los diagramas de colaboración indica la mayoría de los métodos que ha de definir la clase X.

4. Agregue los nombres de los métodos analizando los diagramas de interacción

Los siguientes aspectos especiales deben tenerse en cuenta con respecto a los nombres de los métodos:

Interpretación de los mensajes Crear().

Descripción de los Métodos de Acceso.

Interpretación de los mensajes dirigidos a multiobjetos.

* Sintaxis dependiente del estado

Nombre de los métodos: Crear.

BALA

El mensaje “Crear” es la forma en que, en UML, indicamos: instanciación e inicialización.

Nombres de los Métodos: Métodos de “Acceso”.

Los Métodos de Acceso son aquellos que recuperan (Método Accesor) o establecen (Método Mutador) el valor de los atributos.

Nombre de los Métodos: “Multiobjetos”.

Un mensaje a un Multiobjeto se interpreta como si estuviera destinado al objeto contenedor/colección.

Nombre de los métodos: sintaxis dependiente del lenguaje

Algunos lenguajes (Smalltalk) tienen una forma sintáctica para los métodos distinto al formato básico de:

nombredelmetodo (listadeparametros).

Recomendamos utilizar el formato básico de UML, aun cuando el lenguaje de implementaron planeada aplique otra sintaxis.

5. Incorpore la información sobre los tipos de atributos y los métodos

Es opcional mostrar el tipo de los atributos, los parámetros del método y los valores de devolver método.

La cuestión de si debe incluirse o no esta información deberá considerares dentro del siguiente contexto:

El Diagrama de Clases Orientado al Diseño deberá elaborase teniendo en cuenta que:

Si vamos a crearlo para que lo lean los diseñadores del software, el exceso de detalles puede influir negativamente.

Incorporación de Información sobre los “Tipos”:

PANCRACIO

O PABLO

EL 5.INCORPORE

6. Agregue flechas de navegabilidad a las asociaciones

Se da nombre de papel al final de una asociación; en los Diagramas de Clases orientados al Diseño podemos adornar el papel con una “Flecha de Navegabilidad”.

La navegabilidad es una propiedad del papel e indica la posibilidad de navegar unidireccionalmente en una asociación, desde el objeto fuente hasta el destino.

La navegabilidad significa visibilidad, generalmente visibilidad de atributo.

Descripción gráfica de la navegabilidad, o sea de la visibilidad de los atributos

La interpretación usual de una asociación con una flecha de navegabilidad es la visibilidad de atributo, desde la clase fuente hasta la destino.

ALEX EL 6

La visibilidad y las asociaciones requeridas entre las clases se indican con los diagramas de interacción.

A continuación se mencionan 3 situaciones comunes que revelan la necesidad de definir una asociación con flecha de navegabilidad de A a B:

A envía un mensaje a BA crea una instancia de BA necesita mantener una conexión con B

Basándose en el criterio anterior de asociaciones y de navegabilidad, el análisis de los diagramas de colaboración, se produce el siguiente diagrama de clases:

7. Agregue la líneas de relaciones de dependencia

El lenguaje UML incluye una relación general de dependencia, la cual indica que un elemento (de cualquier tipo como clases, casos de uso y otros) conoce la existencia de otro.

Se denota con una línea punteada y con flecha.

En el Diagrama de Clases, la Relación de Dependencia sirve para describir la visibilidad entre atributos que no se relacionan; es decir: la visibilidad de parámetro global o declarada localmente.

En cambio, la visibilidad simple de atributos se indica con una flecha normal de asociación y con una flecha de navegabilidad.

Asociaciones con Símbolos de Navegabilidad:

DODO EL 7 + EXPLICA EL EJEMPLOS DE APLICACION

si en el ejercicio del punto de Venta, se prevé que CAJA gestione la devolución de algún ítem que se iba a comprar originariamente, pero que luego el Cliente desiste de su adquisición, entonces se puede prever una relación de dependencia directa y temporal con EspecificaciondeProducto, para concretar esta operación excepcional.

Así, CAJA puede tener una visibilidad de corto plazo localmente declarada en EspecificaciondeProducto.

EJEMPLO DE APLICACIÓN

BIBLIOGRAFÍA

- UML GOTA A GOTA - AUTOR MARTÍN FOWLER CON KENDALL SCOTT - EDICIÓN 1997

Direcciones de internet

www.teknodatips.com.arkovachi.sel.inf.uc3m.esnaslyuribe0507ita.blogspot.comhttp://bittacorp.wordpress.com/2008/11/26/diagrama-de-clases/http://upload.wikimedia.org/wikipedia/commons/a/af/Notacion_Diagramas_de_Clase.png