universidad salesiana de bolivia

Post on 13-Feb-2016

92 Views

Category:

Documents

0 Downloads

Preview:

Click to see full reader

DESCRIPTION

UNIVERSIDAD SALESIANA DE BOLIVIA. DIAGRAMAS DE CLASES. PARTICIPANTES: GONZALO QUIROGA CERDANO ANGEL ZULETA MAYTA ANGELO AGUILAR CHAMBI JUAN LAURA QUISPE. DIAGRAMAS DE CLASES . INTRODUCCIÓN - PowerPoint PPT Presentation

TRANSCRIPT

UNIVERSIDAD SALESIANA DE BOLIVIA

DIAGRAMAS DE CLASES

PARTICIPANTES:

GONZALO QUIROGA CERDANOANGEL ZULETA MAYTAANGELO AGUILAR CHAMBIJUAN LAURA QUISPE

DIAGRAMAS DE CLASES

INTRODUCCIÓN

Una ves terminados los diagramas de interacción para el ciclo actual de desarrollo de la aplicación de punto de venta, podemos identificar la especificación de las clases de software (y las interfaces) que participan en la solución de software y complementarlas con detalles de diseño, por ejemplo los métodos.

El lenguaje UML ofrece una notación que muestra los detalles de diseño en los diagramas de estructura - o clase – estática; en este capitulo vamos ha estudiarla y a elaborar los diagramas de clases del diseño

ACTIVIDADES Y DEPENDENCIAS

• Diagramas de interacción: a partir de ellos el diseñador identifica las clases de software que intervienen en la solución, así como los métodos de las clases.

• Modelo conceptual: a partir de este el diseñador agrega detalles a la definición de las clases.

La definición de este tipo de diagramas se lleva a cabo en la fase de diseño del ciclo de desarrollo. Su preparación exige crear antes:

DIAGRAMAS DE CLASES DEL DISEÑO

Perfeccionamientode plan

Sincronizacion de artefactos

Analisis Diseño Construccion Prueba

Ciclo de desarrollo

1.Definir los casos reales de uso.

2. Definir los reportes,la interfaz del usuario

y las storyboards.3.Perfeccionar la arqui

tectura del sistema.

4. Definir los diagramas de interaccion.

5.Definir los diagramasde clases de diseño.

6.Definir el esquemade la base de datos.

Casos de uso:-expandidos-esenciales

Casos de uso:-reales

Ventanas y reportes.

Casos de prueba.

Diagramas decasos de uso.

Modelo conceptual

Closario

Diagramasde secuenciadel sistema.

Contratos operacion

Diagramas de estado

Diagramas deinteraccion

Diagramasde clase de

diseño.

Diagramasde paquete deArquitectura.

Esquema debase de datos.

Metodos

Definiciones de clases y de

interfaz

SQL

dependencia respecto a

COMPARACIÓN ENTRE EL MODELO CONCEPTUAL Y LOS DIAGRAMAS DE CLASES DEL

DISEÑO

En el modelo conceptual por ejemplo una venta no representa una definición de software; mas

bien es una abstracción de un concepto del mundo real cerca del cual queremos afirmar algo.

En cambio, los diagramas de clases del diseño expresan - para el sistema

computarizado – la definición de clases como componentes de software

NOTACIONES QUE SE UTILIZAN PARA LA CONSTRUCCIÓN DE

DIAGRAMAS DE CLASES

CLASIFICACIÓN MÚLTIPLE

• SE REFIERE A LA RELACIÓN ENTRE UN OBJETO Y SU TIPO.

• LA CLASIFICACIÓN MÚLTIPLE NO ES IGUAL A LA HERENCIA MÚLTIPLE

• SE USA UN DISCRIMINADOR QUE SE REPRESENTA DE LA SIGUIENTE MANERA:

AL DISCRIMINADOR SE CONSIDERA COMO OBLIGATORIO

EJEMPLO DE CLASIFICACIÓN MÚLTIPLE

• Para ilustrar, obsérvese las siguientes combinaciones legales de subtipos en el diagrama: (Mujer, Paciente, Enfermera); (Hombre, Fisioterapeuta); (Mujer, Paciente); y (Mujer, Medico, Cirujano). Obsérvense también las combinaciones como (Paciente, Medico) y (Hombre, Medico, Enfermera) son ilegales: la primera, porque no incluye un tipo de discriminador Sexo {obligatorio}; la ultima, porque contiene dos tipos de discriminadores Papel. La clasificación simple, por definición, corresponde a un solo discriminador no etiquetado.

CLASIFICACIÓN DINÁMICA

• La clasificación dinámica permite a los objetos cambiar de tipo dentro de la estructura de subtipificacion; la clasificación estática, no. En la clasificación estática se hace la distinción entre tipos y estados; en la clasificación dinámica se combinan estos dos conceptos.

EJEMPLO DE CLASIFICACIÓN DINÁMICA

. En estos casos, muchas veces vale la pena crear una clase separada para el trabajo y vincular a la persona con ella mediante una asociación.

AGREGACIÓN Y COMPOSICIÓN

• la agregación es la relación de componente..• Con la composición, el objeto parte puede

pertenecer a un todo único

ASOCIACIÓN Y ATRIBUTOS DERIVADOS

• Las asociaciones derivadas y los atributos derivados son aquellos que se pueden calcular a partir de otras asociaciones y atributos, respectivamente, de un diagrama de clase.

Obsérvese lo siguiente:•los objetos de entrada están conectados a Cuentas detalladas.• El balance de una Cuenta se calcula como de las cantidades de entrada.• Las entradas de una Cuentas resumida son las entradas de sus componentes, determinados de manera recurrente.

INTERFACES Y CLASES ABSTRACTAS

• Para permitir que el editor sea independiente de la plataforma, definimos una clase abstracta Ventana, independiente de la plataforma. Esta clase no tiene operaciones; solo define una interfaz para el editor de texto. Las subclases específicas de la plataforma se pueden emplear como se desee.

• InputStream es una clase abstracta; DataInput es una interfaz

EJEMPLO VENTANA COMO CLASE ABSTRACTA

ASOCIACIÓN CALIFICADASUna asociación calificada es el equivalente en UML de un concepto de programación que se conoce de diferentes modos: arreglos asociativos, mapas y diccionarios.

muestra un nodo de representar la asociación entre las clases Pedido y Línea de pedido que emplea un calificador. El calificador dice que, en conexión con un Pedido, puede haber una línea de pedido para cada instancia del Producto.

CLASE DE ASOCIACIÓNLas clases de asociación permiten añadir atributos, operaciones y otras características a las asociaciones, como se muestra en la figura 11.

El diagrama nos permite apreciar que una Persona puede trabajar para una sola compañía. Necesitamos conservar la información sobre el periodo de tiempo que trabaja cada empleado para cada compañía.Para lograrlo, añadimos un atributo de intervaloFechas a la asociación. Podríamos agregar este atributo a la clase Persona y una compañía, la cual cambiara si también lo hiciera el patrón de la persona.

CLASE CON PARÁMETROUna clase con parámetro en UML se declara mediante la notación que aparece en la figura

La T en el diagrama es un marcador para el parámetro de tipo (se podrá tener mas de uno). En un lenguaje sin tipos, como Smalltalk, esta cuestión no surge, por lo que el concepto carece de utilidad.Al uso de una clase con parámetro, tal como Conjunto <Empleado> mostrando antes, se le llama elemento enlazado (bound).

CUANDO CREAR DIAGRAMA DE CLASES DEL DISEÑO

Aunque nuestra exposición de los diagramas de clases del diseño viene después de su elaboración, en la practica suelen prepararse al mismo tiempo que los diagramas de iteración.

Podemos bosquejar muchas clases nombres de métodos y relaciones al inicio de la fase de diseño, aplicando los patrones

de asignación de responsabilidad ante4s de dibujara los diagramas de iteración. Frente a las tarjetas CRC son una notación alterna de4 carácter mas grafico que sirven para

registrar las responsabilidades y los colaboradores

DIAGRAMAS DE CLASES DEL DISEÑO

• El diagrama de clases del diseño describe gráficamente las especificaciones de las clases de software i de las interfases ( las de java por ejemplo) en una ap0licacion normalmente contiene la siguiente información:

• Clases, asociaciones y atributos• Interfaz, con sus operaciones y constantes• Métodos• Información sobre lños tipos de los atributos• Navegabilidad

• dependencias

COMO ELABORAR UN DIAGRAMA DE CLASES DEL

DISEÑO• Identificar todas las clases que participan en la solución del sotfware.Para ello analicé los diagramas de iteración

• Dibújelas en un diagrama de clases• Duplique los atributos provenientes de los conceptos asociados del modelo

conceptual• Agregue los nombres de los métodos analizando los diagramas de iteración• Incorpor4e la información sobre los tipos a los atributos y a los métodos • Agregue las asociaciones necesarias para indicar la dirección de la

visibilidad de los atributos • Agregue flechas de navegabilidad a en las asociaciones para indicar la

dirección de la visibilidad de los atributos• Agregue las líneas de relaciones de dependencia para indicar la visibilidad

no relacionada con los atributos

DIAGRAMA DE CLASES

+Verifica_Ap_Nom()+Registra_Datos()+Muestra_Atributos()+Busqueda_Tram()+Imprimir_leg()+Consulta_Tram_Leg()

-nro_tramite-cert_egreso-cant_cert_egreso-cert_notas-cant_cert_notas-fech_recep-hora_recep-fech_entrega-hora_entrega-estado-obs

Tramite_Leg

+Solicita_leg()+Pide_leg()+Paga_Tram()

-nro-CI-Ap_Pat-Ap_Mat-Nombres-Instituto-Año_Egreso-Ciudad

Persona

solicita

+Registrar()+Eliminar()+Busqueda()+Modificar()

-id_alu-Ap_Pat-Ap_Mat-Nombres-Gestion-Curso-Nivel-Carrera-Distrito

Doc_Cent

Mira en +Busqueda()

-Id_alu-Id_mat-nota-obs

Notas

+Busqueda()

-Id_mat-Id_ins-nom_mat-mod

Materias1

1

1

1 1

1

+Registro()+Modificación()+Busqueda()

-Id_ins-nom_ins-distrito-modalidad-plan-carrera

Instituto

1

*

+Recibe_nro_tram()+Cobra_Costo_Total()+Emite_Fact()

-cod_pago-nro_tramite-monto-fecha

Caja

+Registrar()+Modificar()+Eliminar()+Busqueda()

-nro_tramite-obs-fecha

Doc_Obs

1

1

1

1

1

1

1

1

recibe

contiene

contiene

contiene

Paga a

registra

recibe

GRACIAS

top related