1. El Análisis y Diseño Orientado a Objetos

2. Orientaci ó n a Objetos Estilo de desarrollo Los elementos b á sicos de an á lisis, dise ñ o y construcci ó n son los objetos

3. An á lisis Enfocado a investigar y comprender El dominio del problema El QU É del Sistema Incluye: Descripci ó n del problema Requerimientos a cumplir

4. Dise ñ o Enfocado en definir El producto de software La Solución al problema El C Ó MO del sistema Incluye: Definición de la solución Arquitectura del sistema Mecanismos clave

5. Análisis Orientado a Objetos Centrado en la Identificaci ó n de objetos/conceptos para comprender el problema La nómina de los empleados se calcula utilizando el sueldo asignado y descontando el impuesto del IMSS, mismo que se calcula de la siguiente forma....

6. Diseño Orientado a Objetos La estructura del software se determina con base en objetos como elementos básicos de construcción del sistema Nómina Empleado Sueldo Impuesto IMSS

7. Programación Orientada a Objetos Los objetos y componentes diseñados son implementados en un lenguaje como C++, Java, Smalltalk, Delphi o Visual Basic class Nomina { private Empleado empleado; } public class Empleado { private Sueldo sueldo; } public class Sueldo { private ImpuestoIMSS impuestoIMSS; }

8. Lenguaje Común QUÉ CÓMO

9. Qué es un Objeto Es una entidad física o abstracta que existe en el mundo real Se les puede identificar porque … Podemos hablar de ellos – poseen características particulares Podemos manipularlos – poseen comportamiento Son únicos e irrepetibles – poseen identidad

10. Ejemplos de Objetos Ejemplo 1 Juanito Pérez Características: masculino, 10 años, blanco. Comportamiento: Camina, juega, brinca, habla. Ejemplo 2 Seguro de vida de Rubén Ramírez Características: Aseguradora: GNP, número: 2301, fecha: 12/oct/2001, cliente: Rubén Ramírez, Total: $100,000, etc. Comportamiento: Asegurar cliente, Asignar beneficiarios, Cotizar, etc.

11. Caminar Hablar Clases Abstracción de objetos con características y comportamiento similares. Objeto 1: Juan Pérez Objeto 2: María López Persona Profesión Edad Tez

12. Identifica los Objetos y Clases

13. Análisis y Diseño con UML Definir casos de uso Definir modelo conceptual Definir interacciones Diseñar diagramas de clases

14. Actividades Principales del Análisis Casos de Uso. Descripción narrativa de los procesos de un sistema o negocio Modelo Conceptual. Muestra los conceptos relevantes dentro de un contexto Definir casos de uso Definir modelo conceptual Definir interacciones Diseñar diagramas de clases ANÁLISIS

15. Análisis de Requerimientos: Caso de Uso Caso de Uso: Colocar una orden Descripción: El caso de uso comienza cuando un cliente llama a un ejecutivo de cuenta para solicitar la compra de un producto. El ejecutivo de cuenta registra la información del cliente y del producto en una nueva orden

16. Análisis del Dominio: Modelo Conceptual Caso de Uso: Colocar una orden Descripción: El caso de uso comienza cuando un cliente llama a un ejecutivo de cuenta para solicitar la compra de un producto. El ejecutivo de cuenta registra la información del cliente y del producto en una nueva orden Nombre Producto Orden Cliente Ejecutivo de Cuenta Precio Clave Número Nombre Teléfono

17. Actividades Principales del Diseño Interacción entre los objetos. Diagrama de interacción Estructura estática del sistema. Diagrama de clases Definir casos de uso Definir modelo conceptual Definir interacciones Diseñar diagramas de clases DISEÑO

18. Interacción entre Objetos Producto Orden Cliente Ejecutivo de Cuenta Solicitar compra Consultar datos Crear nueva orden Solicitar datos Registrar orden Indicar datos de orden

19. Diagrama de Clases Ejecutivo de Cuenta Nombre Teléfono Nombre Producto Orden Cliente Precio Clave Número Registrar ( ) Modificar ( ) RecibirSolicitud ( ) Registrar ( ) Consultar ( ) objCliente 1..n

20. Ejercicio Caso de Uso: Saciar sed Análisis Caso de Uso Modelo Conceptual Diseño Interacción entre objetos Diagrama de clases

21. Conclusiones El análisis es el momento en que se identifica el QUÉ del sistema, y el diseño es cuando se identifica el CÓMO El análisis y diseño orientado a objetos se caracterizan porque el elemento fundamental son los objetos Una ventaja importante de la orientación a objetos consiste en que los desarrolladores no necesitan hablar en términos diferentes a los usuarios Los objetos se identifican por tener características y comportamiento que los identifican de manera única Las clases surgen al categorizar o abstraer un conjunto de objetos con características similares

22. Conclusiones El análisis con UML incluye la definición de casos de uso y el análisis del dominio El diseño con UML incluye la definición de las interacciones entre los objetos y el diseño del diagrama de clases

23. El Proceso Unificado Un framework para desarrollar sistemas con UML

24. Proceso Conjunto de pasos aplicados a un producto de entrada, llevado a cabo por roles con responsabilidades específicas, utilizando técnicas y herramientas para transformarlo en un producto de salida o para lograr un objetivo específico. Proceso de Venta, Pago de Nómina, Control de Inventarios, Inscripciones Escolares, etc. PROCESO EntradaSalida ¿QUÉ? ¿QUIÉN? ¿CÓMO? ¿CUÁNDO?

25. Proceso de Software Conjunto de actividades necesarias para transformar los requisitos de un usuario en un sistema de software. PROCESO DE SW RequerimientosSoftware

26. Proceso vs. Proyecto Un proceso sigue una serie de pasos realizados por roles involucrados para ir cumpliendo objetivos y/o desarrollando/utilizando productos y recursos Un proyecto es la ejecución en un momento determinado de un proceso con un tiempo, costo y alcance definido Cada proyecto es una instancia ejecutada del proceso

27. Ciclo de Vida de Cascada Requerimientos Análisis Diseño Programación Pruebas

28. Proceso Iterativo Incremental ConcepciónElaboraciónConstrucciónTransición Iteración 1Iteración 2Iteración 3 Planeación Captura de Requerimientos Análisis & DiseñoImplementaciónPruebas Preparar Liberación Proceso de “Mini-Cascada” 1 2 3 Construcción Incremental

29. El Lenguaje Unificado de Modelado Antecedentes y evolución

30. Objetivos Comprender qué es el modelado y para qué sirve Entender la importancia del modelado visual como una de las mejores prácticas de las ingenierías Entender UML Conocer como surge y evoluciona UML Comprender los beneficios del modelado visual y UML en los proyectos de software

31. Modelos Representación simplificada de la realidad Simplifica al mostrar sólo ciertas características en cada modelo Herramienta de comunicación Facilita la comprensión de la idea, concepto, sistema, etc. Cada rol participante requiere vistas especiales para entender el problema Stakeholders

32. Simplificando la Complejidad

33. Modelo Visual Notación gráfica estándar Maquetas, fotografías, dibujos, planos, diagramas

34. UML Siglas de Unified Modeling Language Lenguaje estándar de modelado de sistemas orientado a objetos No es una metodología, es una notación para desarrollar modelos “UML es un lenguaje estándar para visualizar, especificar, construir y documentar los artefactos de un sistema de software.” UML User’s Guide

35. Objetivos al crear UML Contar con un lenguaje expresivo de modelado visual Integrar mejores prácticas de desarrollo de software Ser independiente de cualquier lenguaje y proceso de desarrollo Motivar el desarrollo de las herramientas OO en el mercado Soportar conceptos de más alto nivel como frameworks, patrones y componentes Proporcionar mecanismos que permitieran extender los conceptos básicos

36. Artefactos de UML

37. Enfoques Diagramas Estáticos Clases Objetos Componentes Despliegue/Distribución Diagramas Dinámicos Casos de Uso Secuencia Comunicación Transición de Estados Actividad EstructuralComportamiento

38. Beneficios de UML Mejora la comunicación entre los involucrados Reduce costos y riesgos al permitir la experimentación con modelos Reduce la complejidad Mayor calidad del software y satisfacción del usuario Reuso

39. Tipos de Sistemas Soportados Sistemas de información Empresarial Bancarios y Servicios Financieros Telecomunicaciones Transportes Defensa/aeroespaciales Médicos electrónicos Científicos Servicios distribuidos en Web, etc.

40. ¿Por qué me conviene usar un Proceso Basado en UML? Estandarización de los artefactos a nivel global y organizacional Orden y control en el desarrollo al definir los artefactos a generar Mejora la comunicación interna y externa Aumenta la calidad y mantenibilidad de los sistemas Productividad y eficiencia en los desarrollos Facilita el reuso de artefactos Soporta la tecnología de objetos y componentes

41. Conclusiones Los modelos son una simplificación de la realidad Los modelos son excelentes herramientas de comunicación Los modelos pueden aumentar la eficiencia, reducir costos y aumentar la calidad Los modelos sirven como base para una buena planeación y administración

42. Conclusiones UML, al ser un lenguaje para modelar, proporciona los beneficios mencionados UML es un lenguaje notacional que permite modelar, documentar, visualizar y construir sistemas UML no incluye el orden o responsabilidades en que se utiliza UML puede ser utilizado para cualquier tipo de proyecto de desarrollo orientado a objetos

43. El Diagrama de Casos de Uso El Eje de la Calidad

44. Objetivos Aprender a describir el comportamiento general de un sistema por medio de casos de uso Entender qué es un actor y cómo representar su interacción con el sistema Comprender las relaciones entre casos de uso Conocer los mecanismos de extensión de UML en los diagramas de casos de uso

45. Diagrama de casos de uso Muestra el Comportamiento del Sistema Muestra el Alcance del Sistema Interacciones con entidades externas

46. Elementos del diagrama de casos de uso Asociación Actor Caso de Uso

47. Actor Representa el rol que juega una entidad externa que interactúa con el sistema. Intercambia información con el sistema Puede ser un recipiente pasivo de información Puede representar el rol que juega un humano, una máquina u otro sistema Se nombran generalmente con sustantivos en singular Cliente, Vendedor, Administrador, Alumno, Sistema de Nómina, etc.

48. Carlos imparte un curso y estudia un postgrado Carlos como Profesor Carlos como Alumno Una entidad, varios actores

49. Carmen estudia administración y Claudia diseño gráfico Carmen como Alumno Varias entidades, un actor Claudia como Alumno

50. Caso de Uso Caso de uso Es la especificación de un conjunto de acciones que ejecuta el sistema Genera un resultado observable con valor real para el actor Describe un flujo de eventos completo Describe las interacciones entre el actor y el sistema El actor inicia un caso de uso cuando invoca cierta funcionalidad del sistema Al unir todos los casos de uso se tienen todas las formas posibles de usar el sistema Se nombran generalmente con un verbo en infinitivo: Realizar Venta, Cotizar Seguro, Generar Nómina, etc.

51. Diagrama de casos de uso

52. Relaciones entre casos de uso (1/2) En ocasiones hay fragmentos de funcionalidad que varios casos de uso comparten Para evitar la repetición, esta funcionalidad común la podemos factorizar en un caso de uso nuevo Los casos de uso que lo requieren, invocan al caso de uso factorizado

53. Relaciones entre casos de uso (2/2) Entre los casos de uso pueden darse dos tipos de relaciones: Dependencia Implica que la funcionalidad englobada en un caso de uso depende de otro ya sea por que el primero (dependiente) incluye o extiende la funcionalidad definida por el segundo Generalización Implica que un caso de uso especializado reutiliza tanto el comportamiento como las relaciones que posee otro caso de uso más general Además, el caso de uso especializado puede redefinir ciertas actividades definidas por el padre

54. Relación de dependencia entre casos de uso UML define dos formas de dependencia entre casos de uso: Includes Extends Para representarlos necesitamos utilizar el mecanismo de extensión de UML: Estereotipos Los estereotipos extienden el significado de los elementos de UML Se escriben entre “«” y “»” y se coloca junto al elemento que deseamos extender «includes» «extends» «estereotipo»

55. Relación Include > Las relaciones “include” se usa … Para extraer parte del flujo que comparten más de un caso de uso Cuando se quiere visualizar parte del detalle de un proceso El “casos de uso base” incluye al “caso de uso incluido”

56. Relación Extend La relación “extend” añade un flujo de trabajo a un caso de uso de negocio que ya se ha descrito completamente La mayoría de los casos de uso de extensión no se pueden ejecutar solos. Las relaciones extend se pueden usar para … Modelar un flujo que rara vez ocurre Modelar un flujo que solo ocurre bajo circunstancias especiales. >

57. Puntos de extensión Identifica un punto en la funcionalidad de un caso de uso donde esta se puede extender por la funcionalidad de otro caso de uso (indicado en una relación «extends» )

58. Relación de Generalización La generalización del caso de uso de negocio es usada para mostrar que dos flujos de trabajo comparten estructura, propósito y medio. Llamada LocalLarga distancia 1 Levantar Auricular 2 Esperar tono 3 Marcar numero 4 el sistema conecta con el numero marcado 4 el sistema conecta con otro sistema B 5 Colgar5 Sistema B conecta con numero marcado 6 Sistema desconecta6 Colgar 7 Sistemas desconectan

59. Paquetes Los paquetes sirven para agrupar de una manera lógica elementos de UML y reducir la complejidad Casos de uso Clases Componentes Paquetes

60. Paquetes de casos de uso Un paquete de casos de uso representa agrupación lógica de funcionalidad. Ejemplo: módulos, subsistemas, sistemas.

61. Conclusiones El diagrama de casos de uso muestra el alcance, el comportamiento del sistema y su interacción con entidades externas Un actor es una entidad externa que interactúa con el sistema Un caso de uso es un conjunto de interacciones entre el sistema y uno o más actores Los casos de uso pueden relacionarse mediante dependencias o generalizaciones Las relaciones de dependencia entre casos de uso pueden estereotiparse con «extend» o «include» Los casos de uso se pueden agrupar en paquetes para reducir la complejidad y organizarlos en subsistemas y módulos

62. Documentación de casos de uso Especificación de Casos de Uso y Escenarios

63. Objetivos Aprender a documentar los requerimientos del sistema mediante el uso de flujos de eventos y escenarios Entender la estructura de un flujo de eventos Comprender la ventaja de los flujos de eventos sobre el enfoque basado en listas de requerimientos Comprender el uso que tiene este artefacto para mejorar la comunicación entre las partes involucradas en el proyecto

64. Documentación de los casos de uso Los casos de uso se documentan con: Una breve descripción El propósito del caso de uso en unas cuantas líneas El flujo detallado de los eventos Descripción detallada de eventos Terminología y redacción simple orientada al negocio/usuario

65. Caso de uso de alto nivel Las descripciones breves de los casos de uso se pueden realizar al principio del proyecto Nombre del Caso de Uso: Registrar Calificaciones Descripción Breve: Este caso de uso tiene como propósito permitir al Catedrático registra las calificaciones que obtuvieron sus alumnos tras la aplicación de un examen. Las calificaciones registradas ya no pueden modificarse una vez generada el acta correspondiente.

66. Especificación del caso de uso La especificación de un caso de uso debe incluir: Precondiciones Flujos de eventos Flujo Principal Flujos Alternos Flujos Excepcionales Post-condiciones

67. Precondiciones Es el estado en que se encuentra el sistema antes de iniciar el caso de uso, y que es necesario para poder llevarlo a cabo exitosamente Generalmente son aspectos que no van a ser validados durante el caso de uso, sino que se dan por ciertos

68. Precondiciones (Ejemplo) CU: Registrar Calificaciones Precondiciones: El catedrático debe haber iniciado una sesión en el sistema El examen a calificar debe estar registrado como un examen programado El examen a calificar no debe tener un acta asociada Los alumnos a los que se les asentarán las calificaciones deben estar registrados como alumnos inscritos en el grupo al que se aplicó el examen Los alumnos a los que se les asentará la calificación debe contar con derecho a presentar dicho examen. A los alumnos sin derecho a examen se les asienta una calificación de NA

69. Flujos de eventos Describe sólo los eventos que ocurren dentro del caso de uso y no lo que pasa en otros casos de uso Evita terminología vaga como por ejemplo, “información” y “etc.” Un flujo de eventos debe describir: Cómo y cuándo inicia y termina el caso de uso Cuándo interactúa el sistema con el actor en el caso de uso Qué información es intercambiada entre un actor y el sistema No describir los detalles de la interfase de usuario El flujo básico de eventos Cualquier flujo alterno

70. Tipos de flujos de eventos Cada caso de uso Debe tener un flujo principal (o básico). Este flujo muestra los pasos o transacciones que normalmente ocurren en el caso de uso Puede tener uno o varios flujos alternos Normalmente tiene flujos excepcionales, que indican los pasos a seguir en caso de error Flujo principal Flujos excepcionales Flujos alternos

71. CU: Registrar Calificaciones Flujo principal 1.El caso de uso inicia cuando el Catedrático le indica al sistema que desea registrar las calificaciones resultantes de la aplicación de un examen. 2.El sistema le pide al Catedrático que le indique el examen que desea calificar. 3.El Catedrático le indica al sistema el examen programado que desea calificar. 4.El sistema le indica al catedrático que asiente las calificaciones obtenidas por los alumnos en el examen. 5.El Catedrático asienta las calificaciones obtenidas por los alumnos y al concluir le indica al sistema que las registre. El catedrático sólo podrá registrar las calificaciones para aquellos alumnos con derecho a examen.

72. CU: Registrar Calificaciones (cont.) Flujo principal 6.El caso de uso termina cuando el sistema registra las calificaciones asentadas para los alumnos. A los alumnos sin derecho a examen se les asienta una calificación de NA.

73. CU: Registrar Calificaciones (cont.) Flujos alternos 5a.Identificar a los alumnos sin derecho a examen 1.El Catedrático le indica al sistema que identifique a los alumnos sin derecho a examen. 2.El sistema el sistema identifica a los alumnos sin derecho a examen y el flujo de eventos continúa en el paso 4 del flujo principal.

74. CU: Registrar Calificaciones (cont.) Flujos excepcionales Cancelar el registro de las calificaciones 1.En cualquier momento, el Catedrático le puede indicar al sistema que desea cancelar el registro de calificaciones. 2.El sistema le indica al Catedrático que confirme la cancelación del registro. 3.El Catedrático confirma la cancelación del proceso. 4.El caso de uso termina con la cancelación del proceso de registro. En este caso cualquier calificación asentada por el catedrático no se registrará en el sistema.

75. Post-condiciones Es el estado en el que debe quedar el sistema despu é s de haber llevado a cabo exitosamente un caso de uso CU: Registrar Calificaciones Post-condiciones: Las calificaciones obtenidas por los alumnos en el examen deben estar registradas en el sistema. Los alumnos con derecho a examen tendrán registrada la calificación asignada por el catedrático mientras que a los alumnos sin derecho a examen se les registrará una calificación de NA

76. Usuarios de los casos de uso Clientes – validan que los desarrolladores comprendieron el problema Usuarios – clarifican sus ideas respecto al problema Desarrolladores – comprenden lo que el usuario espera del sistema a desarrollar Revisores – verifican la calidad de los requerimientos Analistas y diseñadores – base para el análisis y el diseño Tester – a partir de estos validan que el sistema hace lo que el cliente/usuario pidió Líder de proyecto – es la base para el plan de trabajo Documentador – lo usan como base aproximada de un manual de usuario

77. Prototipo GUI Facilita el levantamiento de requerimientos Al usuario y a los desarrolladores les ayuda a aterrizar y esclarecer ideas Reduce riesgos de requerimientos mal entendidos Se deben realizar en paralelo con los casos de uso

78. El Prototipo y los casos de uso Caso de Uso: Cotizar Seguro de Vida Descripción: El caso de uso comienza cuando el ejecutivo registra los datos del asegurado, el sistema utiliza los parámetros de cotización para indicar el monto...

79. Ejemplo de flujo de eventos Especifique el Caso de Uso indicado

80. Ejercicio Desarrollar para el caso de uso especificado: Las precondiciones El flujo de eventos principal Los flujos de eventos alternos Un flujo excepcional Las post-condiciones

81. Escenarios Un escenario es al caso de uso, lo que el objeto es a las clases Es una instancia espec í fica de un caso de uso, al llevar a cabo uno de los flujos del caso de uso (ya sea primario, alterno o excepcional) Los escenarios son utilizados para comprender mejor alg ú n caso de uso y para realizar las pruebas funcionales del sistema

82. Posibles Escenarios Para cada uno de los flujos de un caso de uso existe por lo menos un escenario Para el caso de uso “Registrar Calificaciones” existen los siguientes flujos posibles: Cuando el registro de calificaciones sigue la secuencia de eventos típica Cuando se desea identificar a los alumnos sin derecho a examen Cuando se cancela el registro de las calificaciones Y los siguientes ejemplos de escenario para cada flujo: Registrar las calificaciones del examen final para el ciclo 2006 obtenidas por los alumnos inscritos en el curso de Comunicación Oral y Escrita impartido por Marco Aurelio Torres H. los martes y jueves de 14:00 a 16:00 hrs. Identificar a los alumnos sin derecho al examen final para el ciclo 2006 inscritos en el curso de Comunicación Oral y Escrita impartido por Marco Aurelio Torres H. los martes y jueves de 14:00 a 16:00 hrs. Cancelar el registro de las calificaciones del examen final para el ciclo 2006 obtenidas por los alumnos inscritos en el curso de Comunicación Oral y Escrita impartido por Marco Aurelio Torres H. los martes y jueves de 14:00 a 16:00 hrs.

83. Escenario: Registro de Calificaciones Exitoso Escenario: Registrar las calificaciones del examen final para el ciclo 2006 obtenidas por los alumnos inscritos en el curso de Comunicación Oral y Escrita impartido por Marco Aurelio Torres H. los martes y jueves de 14:00 a 16:00 hrs. 1. Marco Aurelio Torres H. le indica al sistema que desea registrar las calificaciones resultantes de un examen 2. El sistema le pide a Marco Aurelio Torres H. que le indique el examen que desea calificar. 3.Marco Aurelio Torres H. le indica al sistema que desea registrar las calificaciones del examen final para el ciclo 2006 obtenidas por Juan de la Barrera, Agustín Melgar y Francisco Márquez, inscritos en el curso de Comunicación Oral y Escrita impartido los martes y jueves de 14:00 a 16:00 hrs. 4.El sistema le indica a Marco Aurelio Torres H. que asiente las calificaciones obtenidas por los alumnos en el examen indicado. 5.Marco Aurelio Torres H. asienta las calificaciones obtenidas por Juan de la Barrera, Agustín Melgar y Francisco Márquez y al concluir le indica al sistema que las registre. 6.El sistema registra las calificaciones obtenidas por Juan de la Barrera, Agustín Melgar y Francisco Márquez

84. Ejercicio Enlistar los posibles flujos Enlistar un escenario para cada flujo Describir a detalle uno de los escenarios

85. Conclusiones Los flujos de eventos son la forma en que se describen textualmente y a detalle los casos de uso Los flujos de eventos permiten especificar el funcionamiento del sistema Es uno de los principales artefactos de entrada utilizados por los diferentes stakeholders Los prototipos GUI facilitan la identificaci ó n de requerimientos y casos de uso, y ayudan a eliminar riesgos tempranamente Los escenarios son instancias espec í ficas para cada flujo del caso de uso Los escenarios son los guiones utilizados para realizar las pruebas al sistema y validar la implementaci ó n de los requerimientos

86. El Diagrama de Clases La Estructura Estática del Sistema

87. Objetivos Conocer los elementos de UML para modelar un diagrama de clases El alumno podrá desarrollar un diagrama de clases con base en los artefactos generados durante el análisis El alumno conocerá los elementos de un diagrama de clases

88. Diagrama de Clases Es el artefacto principal en el desarrollo orientado a objetos Muestra las clases en las que se implementará el sistema, sus relaciones, atributos y operaciones

89. Elementos en un Diagrama de Clases (1/2) Clases Atributos Operaciones Scope o alcance de atributos y operaciones

90. Elementos en un Diagrama de Clases (2/2) Relaciones Elementos de las Asociaciones y Agregaciones Navegabilidad Roles Multiplicidad Visibilidad entre clases

91. Atributos Descripción de un dato que define a una clase El atributo debe tener especificado un nombre, tipo de dato y scope Cada objeto instanciado de una clase tiene su propio valor para el atributo

92. Operaciones Especificación de una transformación o query que puede ser solicitado a un objeto Consta de un nombre y una serie de parámetros (firma de la operación) Un método es la implementación de una operación

93. Scope de Atributos y Operaciones Es la visibilidad que tienen las clases hacia los atributos y operaciones de una clase con la cual están relacionadas. Existen 4 tipos de scope: Público Privado Protegido Friendly

94. Control de Acceso y Encapsulamiento El control de acceso se emplea para reforzar el encapsulamiento Operaciones públicas Operaciones protegidas y privadas Atributos Privados

95. Especificación del Control de Acceso Se pueden usar símbolos de acceso en una clase para indicar la accesibilidad a sus atributos y operaciones + Acceso Público # Acceso Protegido - Acceso Privado ~ Acceso Friendly El acceso es concedido, de manera explícita, por la misma clase y no forzado por el cliente

96. Especificación del Control de Acceso + agregarAlumno () + estaLleno () # determinarTamañoCurso () - maxAlumnos - Nombre Curso

97. Tipos de Relaciones entre Clases Asociación Agregación y Composición Generalización Dependencia Curso Diplomado Modulo Alumno

98. Asociación Es la relación más simple entre dos clases Indica que 2 clases pueden verse o solicitar sus servicios

99. Clases Asociación Una clase asociación contiene información perteneciente a un vínculo entre objetos AlumnoCurso 3..10 4 Promedio Calificación

100. Roles En términos de análisis indica el rol que toma una clase con respecto a otra en una relación de asociación En términos de implementación es el nombre de la instancia u objeto que se utilizará para solicitar los servicios de la clase y para asignarle valores a sus atributos

101. Navegabilidad La asociación sin flechas indica que ambas clases pueden verse y comunicarse entre sí Pero, en ocasiones no es necesario eso, sino que una sola clase es la que requiere comunicarse con la otra, en este caso indicamos que existe navegabilidad hacia un solo lado por medio de una punta de flecha al final de la asociación

102. Agregación Es una clase especial de asociación donde una clase “contiene” a otra clase, o donde una clase “es parte de” otra clase Un Motor “contiene” Válvulas (o las válvulas son parte del motor)

103. Composición Es un tipo de agregación más sólido donde las partes sólo existen cuando existe el contenedor Una mano está compuesta de dedos Si la mano desaparece los dedos no sirven de nada La parte sólo puede ser parte de un contenedor al mismo tiempo

104. Generalización (Herencia) Es una relación donde una clase es un tipo especial de otra clase. Es decir, tiene todas las características (atributos, operaciones y relaciones) de la súperclase más otras especiales Un carro es un tipo especial de transporte Existen dos formas de identificar la herencia: Generalización Especialización

105. Generalización Cuando obtenemos características comunes de varias clases para crear una súperclase de la cual van a heredar todas las subclases las características comunes Carro Motor Llantas Barco Motor Aspas

106. Generalización Transporte Motor Carro Llantas Barco Aspas

107. Especialización Es la técnica mediante la cual se identifica que una clase puede comportarse o tener características diferentes dependiendo de cierta situación o condición Identificamos cuáles son las características que nunca cambian y las dejamos en una súperclase, y las características especiales las ponemos en nuevas clases llamadas subclases Transporte Motor Llantas Aspas Transporte Motor Carro Llantas Barco Aspas

108. Dependencia Es un tipo de relación menos duradera que una asociación o una agregación La comunicación sólo es posible en momentos específicos de la clase dependiente (p.ej. cuando instancía o recibe como parámetro a la 2a clase)

109. Visibilidad Existen cuatro opciones de visibilidad Global El objeto servidor es un objeto global Parámetro El objeto servidor es un parámetro de una operación del objeto cliente Local El objeto servidor se declara localmente dentro de uno de los métodos del objeto cliente Campo El objeto servidor es un campo contenido en el objeto cliente

110. Visibilidad Indica cómo y bajo que circunstancias pueden comunicarse dos clases relacionadas asociación, agregación o composición Por campo dependenciaLocal dependenciaPor parámetro dependenciaGlobal Tipo de Relación Visibilidad

111. Elaboración del Diagrama de Clases Identificar operaciones y su scope (usar d. de interacción) Identificar atributos con su tipo de dato y scope Identificar relaciones entre clases (usar d. de interacción) Organizar clases en paquetes lógicos

112. Información en Diagrama de Interacción El diagrama de interacción es uno de los productos de entrada más importantes para elaborar el de clases Pasos para Refinar el Diagrama de Clases a partir del de interacción Convertir mensajes en operaciones Definir scope de las operaciones Decidir visibilidad requerida entre 2 clases comunicándose en el d. De interacción Si es global, local o por parámetro mostrar una dependencia en el d. De clases Si es por campo Identificar si es una relación de un todo con sus partes Si la parte, sólo es “parte” en una relación de composición, marcarla como composión Si no marcarla como agregación Si no, marcarla como asociación Mostrar la multiplicidad, navegabilidad y rol

113. Paquetes de Clases Las clases se pueden agrupar lógicamente en paquetes Las clases que se agrupan son las que guardan una relación cercana entre sí, ya sea de funcionalidad o de datos Estos grupos o paquetes lógicos de clases son los que suelen convertirse en componentes

114. VentasEmpresaNómina Paquete de Clases EmpleadoEmpresa Dirección Venta Nómina Producto Cliente Impuestos Factura

115. Ejercicio Desarrolle el Diagrama de Clases de Diseño con base en los artefactos antes generados

116. Conclusiones El diagrama de clases muestra la estructura estática del sistema Un diagrama de clases muestra las clases y sus relaciones Existen diferentes tipos de relaciones y visibilidad entre las clases Las clases se pueden agrupar lógicamente en paquetes para reducir la complejidad