Programación Orientada a Objetos

1. Programación Orientada a Objetos ANALISIS Y DISEÑO UML

2. UML • Un sistema orientado a objetos está conformado por objetos • Pero eso es lo mismo que decir que una circuito electrónico está hecho con diodos, transistores, resistencias, capacitores, etc • De la misma manera que para construir un circuito necesitamos especificar que componentes, sus valores y las interconexiones entre ellos (un esquemático), para construir un sistema OO necesitamos saber cuales son los objetos, sus atributos y métodos y cómo se interrelacionan entre sí

3. UML • Un esquemático esta formado por símbolos estándar que pueden ser comprendidos por cualquier ingeniero o técnico electrónico • Así también un sistema OO necesita ser representado de una manera estándar para que este pueda ser entendido por diseñadores y programadores

4. UML • A la acción de construir estos diagramas se lo conoce como modelamiento • Al producto se lo conoce como modelo • Modelo es una abstracción que se construye para entender y resolver problemas • Los modelos limitan nuestra vista a un subconjunto de la realidad

5. Hardware Real Modelo - Hardware o Software prototipo Modelo en papel o Herramienta CASE UML Software

6. ¿Para que A&D OO? • El cambio a OO no es fácil, los lenguajes de modelamiento OO ayudan de alguna manera para que el cambio de paradigma sea un poco más sencillo. • Uno de los grandes retos en el desarrollo es construir el sistema correcto. Los lenguajes de modelamiento OO ayudan a lograr buena comunicación con los clientes y los expertos en el dominio.

7. UML • ¿Qué es Lenguaje de Modelamiento Unificado? • Lenguaje de modelamiento estándar para: • Modelar sistemas (no solo software) usando OO • Establecer un modo de acoplamiento explícito entre los modelos conceptuales y ejecutables • Manejar las complejidades de sistemas de misión crítica • Proveer un lenguaje de modelamiento que pueda ser utilizado tanto por humanos como por las máquinas.

8. UML • Los modelos se caracterizan por ser: • Precisos • Consistentes • Fácil de comunicar • Fácil de cambiar • Entendibles

9. UML • La Guerra de los modelos (80s-90s): • Booch - Grady Booch • OMT - James Rumbaugh • OOSE/Objectory - Ivar Jacobson • Fusion - David Coleman • OOA/OOD - Coad & Yourdon

10. UML Método Boch

11. UML Método OMT

12. UML Método UML

13. Lenguaje Unificado de Modelamiento • El lenguaje unificado de modelamiento (UML) unifica las notaciones de Booch, Rumbaugh (OMT) y Jacobson (OOSE) • Notación es la representación gráfica de diferentes modelos, es la sintaxis del lenguaje de modelamiento. • El UML es un estándar aprobado por la OMG y es ampliamente aceptado en la industria. • UML es un lenguaje de modelamiento, no un proceso de desarrollo de software; su intención es ayudar a las diferentes acercamientos para la producción de software OO.

14. UML • Se utiliza UML en diferentes tipos de sistemas: • Sistemas de información • Técnicos • Tiempo real • Distribuidos • Software • Sistemas de negocios

15. UML • Hay tres dimensiones para entender los modelos OO: • ¿Por qué se construyen los modelos? • ¿Qué hay en el modelo? • ¿Cómo se relacionan los modelos?

16. UML • Fases en el desarrollo de sistemas: • Análisis de requerimientos • Análisis del sistema • Diseño • Implementación (programación) • Pruebas de aceptación.

17. UML Los Modelos se utilizan para…. Resolver el problema Entender y especificar el problema Construir la solución Análisis OO Diseño OO Construcción OO

18. UML • Para cada una de estas fases existen modelos UML: • Análisis • Foco: Especificar el dominio o el problema • Perspectiva: Desde el punto de vista del cliente o usuario • Actividades típicas: Entendimiento de los requerimientos, entendimiento del dominio del problema, identificar límites del sistema, etc. • Diseño • Foco: Resolver el problema • Perspectiva: Del arquitecto, analista, diseñador, programador • Actividades típicas: Definición de arquitectura del software, escoger estructura de datos, desarrollar algoritmos, implementar relaciones, etc. • Implementación y Pruebas • Foco: Construir la solución para soportar el modelo del diseño • Perspectiva: Del arquitecto, analista, diseñador, programador • Actividades típicas: Implementar clases, manejo de persistencias, concurrencia, pruebas, funcionamiento

19. UML • Para cada una de estas fases existen modelos UML: • Análisis de requerimientos • Casos de Uso • Escenarios • Análisis del sistema • Diagrama Análisis Interacción • Modelo de Análisis de Objetos • Diseño • Diagrama Diseño Interacción • Modelo de Diseño de Objetos • Diagrama de Estados • Implementación (programación) • Diseño Descripción de Clases • Instalación • Diagrama de Puesta en Producción

20. UML • Diferentes modelos dan diferentes vistas de un problema, enfocados a responder preguntas particulares • Modelos estáticos • ¿Cuáles son los objetos (entidades o cosas) en el problema? • ¿Cuáles son sus características? • ¿Qué tienen en común? • ¿Cuáles son las relaciones estructurales entre ellos? • Modelos dinámicos • ¿Qué pasa cuando el sistema esta corriendo? • ¿Cuáles son las colaboraciones entre objetos • ¿Cuál es la secuencia de eventos? • ¿Cómo se comportan los objetos?

21. guau guau UML Modelos estáticos ladra mueve la cola Es un tiene cola tiene nariz húmeda perro Es un tiene 4 patas Modelos estáticos se concentran en la estructura y similitudes

22. UML Modelo dinámico muchacho entrega periódico perro persigue al muchacho perro muerde al muchacho perro entrega el periódico Modelos dinámicos se concentran en el flujo de control y secuencia de eventos

23. Diagramas UML • Diagramas de Caso de Uso • Diagramas de Clase • Diagramas de Interacción • Diagramas de secuencia • Diagramas de colaboración • Diagrama de Estados • Diagramas de Actividad • Diagramas de Componentes • Diagrama de Puesta en Producción

24. UML • Modelos Estáticos: • Modelo de Análisis de Objetos • Modelo de Diseño de Objetos • Diseño de Descripción de Clases • Diagrama de Componentes • Diagrama de Puesta en Producción • Modelos Dinámicos: • Casos de Uso • Escenarios • Diagrama de Análisis Interacción • Diagrama de Diseño Interacción • Diagramas de Estado

25. Herramientas CASE • Dibujar Diagramas • Actúan como repositorio • Ayudan a la navegación • Soporte Multiusuario • Genéran código • Ingeniería Reversa • Integración con otras herramientas

26. CASOS DE USO

27. Casos de Uso • Requerimientos del Sistema • Requerimientos son el conjunto de frases que describen el comportamiento externo esperado de un sistema, cuando este sea puesto en operación.

28. Casos de Uso • Los requerimientos pueden ser expresados como: • Requerimientos funcionales: comportamiento observable de lo que hará el sistema. Ej: • cliente renta un vídeo. • Requerimientos no funcionales: limitaciones en el sistema y/o criterios aceptables como rendimiento, confiabilidad, utilidad, costo, disponibilidad, etc. Ej.: • El sistema debería poder ser utilizado por alguien que no sabe de computadoras, después de 2 horas de entrenamiento. • Un usuario del sistema debería poder procesar un reclamo en no más de 3 minutos.

29. Casos de Uso • Un caso de uso es la secuencia de transacciones en un sistema cuya tarea es producir un resultado con valor medible para un actor del sistema • Sistema: Entidad encapsulada cuyos requerimientos han sido descritos (programa, computador) • Actor: Entidad fuera del sistema que interactúa con este (usuario, otro sistema) • Secuencia de transacciones: Serie de interacciones entre el sistema y el actor que lo usa. • Resultado con valor medible: objetivo logrado con valor no trivial para el actor. • El conjunto de casos de uso puede ser utilizado para documentar los requerimientos funcionales del sistema

30. Casos de Uso Sistema Caso de Uso Entidad fuera del sistema quien interactúa con este Serie de transacciones de valor para el actor

31. Casos de Uso La Empresa Sistema Casos de uso del sistema Usuario del sistema Cliente (usuario de la empresa) Casos de uso de la empresa

32. Hace depósito Casos de Uso Banco (empresa) Sistema computacional Añade cliente Agente Cajera Retira fondos Procesa préstamo Deposita cheque Adquiere préstamo Cliente

33. Casos de Uso • ¿Quiénes son los actores? • Un actor es una entidad que interactúa con el sistema. Ejm: • Un usuario humano • Otro sistema que requiere de servicios • Otro sistema que provee de servicios • El tiempo • El actor esta fuera de los límites del sistema - No es un objeto dentro del sistema • Un actor es una abstracción de un rol - No es un sola persona o el puesto de una persona • Un usuario puede jugar múltiples roles • Dos personas diferentes podrían jugar el mismo rol.

34. Casos de Uso • ¿Qué son la secuencia de transacciones? • Una secuencia es una serie de interacciones • El foco esta en las interacciones que cruzan los límites del sistema, no son acciones internas del sistema • La atención esta en las interacciones entre el actor y el sistema, no entre actores • La implementación precisa de las interacciones no deben describirse en el caso de uso • La serie de interacciones es iniciada por algún evento.

35. Casos de Uso Sistema Organizador de Reuniones Planifica reunión María (usuario del sistema) Juega el rol de registradora María (usuario del sistema) Juega el rol de planificadora Registra invitado a reunión

36. Casos de Uso Sistema Organizador de Reuniones Planificador (actor primario) Planifica reunión Registrador (actor primario) Registra invitado a reunión Sistema Verificador de tarjeta de crédito (actor secundario)

37. Casos de Uso Sistema de registros médicos Actualiza ficha de paciente Enfermero Respaldo de información en tape

38. Casos de Uso • Una lista de casos de uso incluye: • Lista de casos de uso utilizando el formato de objetos. • Descripción de cada caso de uso • Descripción de cada actor • (opcional) Diagrama o tabla de relaciones entre casos de uso y actores.

39. Nombre: _________________ Descripción: ______________ ________________________ ________________________ Notas:___________________ ________________________ Nombre: _________________ Descripción: ______________ ________________________ ________________________ Notas:___________________ ________________________ Descripción de Actores Descripción de Casos de Uso Casos de Uso 1. Caso de Uso A 2. Caso de Uso B 3. Caso de Uso C …………. …………. …………. Caso de Uso A Lista de Casos de Uso Caso de Uso B Caso de Uso C Diagrama de Casos de Uso

40. Casos de Uso • Para identificar actores • Buscar primero los actores primarios (los actores secundarios pueden ser descubiertos a medida que se elabora el comportamiento de los casos de uso) • Buscar por roles, no usuarios individuales o títulos • El nombre debería enfocar en el rol de actor, con respecto a su interacción con el sistema.

41. Casos de Uso Diagrama de Casos de Uso Sistema Rol Y Rol Z Rol X

42. Casos de Uso • Identificación de los roles de los actores • Los casos de uso documentan lo que el sistema debe hacer para satisfacer los objetivos de los actores que interactúan con el sistema • Los objetivos del actor deben reflejar un valor medible - no pasos individuales para alcanzar un objetivo de valor o interacciones triviales • Ordena pizza - es un objetivo de valor para el actor que juega el rol de cliente • Selecciona aceitunas - es solo un paso en ordenar pizza • Presionar ENTER es una interacción trivial

43. Casos de Uso • Los objetivos pueden ser descritos desde la perspectiva de un actor quien utiliza el sistema - o desde la perspectiva del sistema • Ordena pizza es un objetivo desde la perspectiva del actor cliente • Envía la orden de pizza a la cocina es un objetivo desde la perspectiva del sistema • Cada objetivo de valor puede ser descrito con los casos de uso.

44. Casos de Uso Diagrama de Casos de Uso Sistema Objetivo a Objetivo c Rol Z Objetivo b Rol Y Objetivo e Objetivo d Rol X

45. Casos de Uso Sistema Objetivo a Objetivo c Rol Z Objetivo b Rol Y Objetivo d Objetivo e Nombre: Caso de uso E Descripción: Describe funcionalidad y aplicabilidad dentro del contexto Notas: Describe limitaciones y decisiones Describe reglas y políticas del negocio Rol X Nombre: Caso de uso D Descripción: Describe funcionalidad y aplicabilidad dentro del contexto Notas: Describe limitaciones y decisiones Describe reglas y políticas del negocio Descripción de Casos de Uso

46. Ejemplo: Carreteras

47. Ejemplo: Carreteras (1) • La compañía Pague&Maneje administra una red de carreteras. La red consiste en número de segmentos de vía. Cada segmento de vía esta delimitados por dos nodos que están descritos normalmente con su posición geográfica. La distancia entre los nodos delimitantes de un segmento de vía es conocido. • Algunos de los nodos están equipados con estaciones de control de acceso que pueden ser usadas para entrar y salir de la red de carreteras. Algunos de los nodos están equipados como puntos de servicio (estación de gasolina, baños, etc) • Una trayecto es una secuencia consecutiva de segmentos de vía. Comienza y termina en nodos con control de acceso.

48. Ejemplo: Carreteras (2) • Los clientes pueden registrarse con Pague&Maneje y obtener hasta 3 tarjetas. Los clientes pueden usar estas tarjetas para viajar en trayectorias en la red vial. • Las tarjetas regulares son válidas por un período y se envían facturas por cada uso de la tarjeta. El valor de la facturas se calculada a partir de la longitud de la trayectoria recorrida y el precio unitario esta asociado con cada tarjeta. • Además de las tarjetas regulares existe un número de tarjetas especiales. Las tarjetas MiniViaje son tarjetas prepagadas, válidas para una sola trayectoria. Están expiran cuando se recorre la trayectoria. Las tarjetas temporales son también prepagadas, son válidas por un tiempo dado y pueden dar acceso a toda la red vial.

49. De captura de requerimientos a Análisis • Descubrir los potenciales casos de uso de un sistema, las interacciones típicas que el usuario tiene con el sistema para alcanzar sus objetivos. • Un caso de uso está escrito como un para de párrafos de texto, UML provee diagramas de caso de uso. • Desarrollar un modelo conceptual del domino, explorar el vocabulario del domino, dar una descripción del mundo en el cual deberá encajar. • Un diagrama de clases conceptual es útil aquí y algunos diagramas UML de actividad podrían ser útiles cuando el proceso de workflow es parte del mundo del usuario.

50. Análisis y Diseño de Métodos • El diagrama de clases conceptual resultante del análisis del domino junto con los casos de uso constituyen un modelo de análisis. • Un modelo de diseño comprende tanto la información de los conceptos del dominio como el comportamiento en los casos de uso, añade las clases que realmente hacen el trabajo y provee cierta arquitectura. • Un diagrama UML de especificación puede ser usado junto con diagramas UML de interacción y/o estado que muestran como las clases implementan los casos de uso.