UNIVERSIDAD SALESIANA DE BOLIVIA

1. UNIVERSIDAD SALESIANA DE BOLIVIA DIAGRAMAS DE CLASES PARTICIPANTES: GONZALO QUIROGA CERDANO ANGEL ZULETA MAYTA ANGELO AGUILAR CHAMBI JUAN LAURA QUISPE

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

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

4. 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:

5. DIAGRAMAS DE CLASES DEL DISEÑO Ciclo de desarrollo Perfeccio namiento de plan Sincroni zacion de artefactos Analisis Diseño Construccion Prueba 2. Definir los reportes, la interfaz del usuario y las storyboards. 3.Perfeccionar la arqui tectura del sistema. 1.Definir los casos reales de uso. 4. Definir los diagra mas de interaccion. 5.Definir los diagramas de clases de diseño. 6.Definir el esquema de la base de datos.

6. Casos de uso: -expandidos -esenciales Casos de uso: -reales Ventanas y reportes. Casos de prueba. Diagramas de casos de uso. Diagramas de interaccion Metodos Modelo conceptual Diagramas de clase de diseño. Definiciones de clases y de interfaz Closario Diagramas de secuencia del sistema. Diagramas de paquete de Arquitectura. dependencia respecto a Contratos operacion SQL Esquema de base de datos. Diagramas de estado

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

8. En cambio, los diagramas de clases del diseño expresan - para el sistema computarizado – la definición de clases como componentes de software

9. NOTACIONES QUE SE UTILIZAN PARA LA CONSTRUCCIÓN DE DIAGRAMAS DE CLASES

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

11. EJEMPLO DE CLASIFICACIÓN MÚLTIPLE

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

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

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

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

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

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

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

19. EJEMPLO VENTANA COMO CLASE ABSTRACTA

20. ASOCIACIÓN CALIFICADAS Una 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.

21. CLASE DE ASOCIACIÓN Las 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.

22. CLASE CON PARÁMETRO Una 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).

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

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

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

26. DIAGRAMA DE CLASES

27. GRACIAS