universidad salesiana de bolivia ingenieria de sistemas diagramas

Anuncio
Docente:
Semestre:
Fecha:
Lic. Elisa Arizaca Ramirez
6– A1.
18/11/14.
1PACHAMAMA ENPIESA
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.
2: HUANCA DESDE NOTACION
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).
•Atributos de la clase
Nombre de la
Clase 1
Atributo 1
Atributo 2
.................
•Operaciones de la clase
Operacion1( )
Operacion2( )
.................
•Nombre de la clase
Ejemplos
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).
HUANCA TERMINA Y ENPIESA 3 PANCRACIO O PABLO
*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
Representa el número de objetos que pueden conectarse a través de una relación de
asociación.
1
0..1
0..*
1..*
*
M..N
El atributo debe tener un único valor.
El atributo puede o no tener un valor.
El atributo puede tener varios valores o ninguno.
El atributo puede tener varios valores, pero debe *
El atributo puede tener varios valores.
El atributo puede tener entre M y N valores.
Ejemplos
Persona
Trabaja_para
1...*
Compañía
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.
Ejemplos:
Un cliente puede tener asociadas muchas Ordenes de Compra, en cambio una orden de
compra solo puede tener asociado un cliente.
TERMINA PANCRACIO
4 BALA
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:
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.
5 ALEX
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
- Ruedas
- Puertas
- Asiento
+ Arrancar( )
+ Acelerar( )
+ Frenar( )
+ Girar( )
Automóvil
- Deportivo
+ Correr( )
Camión
- Remolque
+ Cargar( )
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.
6 DODO
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):
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
PACHACUTI Aplique la siguiente estrategia para elaborar diagramas de clases:
1Y2
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:
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.
HUANCA EL
3. Duplique los atributos provenientes del modelo conceptual:
3

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:

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.
BALA
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.

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.
PANCRACIO
5. Incorpore la información sobre los tipos de atributos y los métodos
O PABLO
Es opcional mostrar el tipo de los atributos, los parámetros del método y los valores de
devolver método.
EL
5.INCORPORE

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”:
ALEX EL 6
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.

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 B
A crea una instancia de B
A 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:
Asociaciones con Símbolos de Navegabilidad:
DODO EL 7
+ EXPLICA
EL
EJEMPLOS
DE
APLICACION
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.

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.ar
kovachi.sel.inf.uc3m.es
naslyuribe0507ita.blogspot.com
http://bittacorp.wordpress.com/2008/11/26/diagrama-de-clases/
http://upload.wikimedia.org/wikipedia/commons/a/af/Notacion_Diagramas_de_Clase.png
Descargar