Programación Orientada a Objetos

Presentación del tema: "Programación Orientada a Objetos"— Transcripción de la presentación:

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 UML Hardware Real Modelo - Hardware o Software Software
Modelo en papel o Herramienta CASE prototipo 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 Modelar sistemas (no solo software) usando OO
¿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 Entender y especificar
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 Diseño
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 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 UML Modelos estáticos ladra guau 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: Modelos Dinámicos:
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 Casos de uso del sistema
Usuario del sistema Cliente (usuario de la empresa) Casos de uso de la empresa

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

33 Casos de Uso Ejm: ¿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 Sistema Verificador de tarjeta de crédito
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 Casos de Uso Caso de Uso A Lista de Casos de Uso Caso de Uso B
Nombre: _________________ Descripción: ______________ ________________________ Notas:___________________ Descripción de Actores Nombre: _________________ Descripción: ______________ ________________________ Notas:___________________ Descripción de 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 Rol Z Rol Y Rol X
Objetivo a Objetivo c Rol Z Objetivo b Rol Y Objetivo e Objetivo d Rol X

45 Casos de Uso Descripción de Casos de Uso Sistema Rol Z Rol Y Rol X
Objetivo a Objetivo c Rol Z Rol Y Objetivo b 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.

51 Modelo de Caso de Uso: Actores
Los actores NO son parte del sistema, representan a cualquier persona o cosa que deba interactuar con el sistema. El afiliado a la biblioteca “presta una copia del libro” El bibliotecario “actualiza el catálogo” Un actor puede: Solamente ingresar información al sistema Solamente recibir información del sistema Ingresar y recibir información del sistema Los actores leen, crean, destruyen y modifican información Los actores son encontrados en la declaración del problema y en conversaciones con los clientes y expertos del dominio Un solo actor puede realizar muchos casos de uso y un solo caso de uso puede tener varios actores realizándolo Questions to identify actors: Who is interested in a certain requirement? Where in the organization is the system used? Who will benefit from the use of the system? Who will supply the system with this information, use this information, and remove this information? Who will support and maintain the system? Does the system use an external resource? Does one person play several different roles? Do several people play the same role? Does the system interact with a legacy system? Creation of an actor for each role a person can play can be overkill. Only create different actors in that case they use the system differently.

52 Modelo de Casos de Uso: Casos de Uso (1)
Un caso de uso modela un dialogo entre un actor y el sistema. Un editor de texto: “marca un texto en negrillas”, “crea un indice” Un sistema bibliotecario: “presta una copia del libro”, “actualiza el catálogo” Un caso de uso representa la funcionalidad provista por el sistema, ej. Las capacidades que el sistema proveerá al actor. La suma de todos los casos de uso es la figura externa del sistema. Un caso de uso es una secuencia de transacciones realizadas por un sistemas que conducen a un valores de resultado mesurables para un determinado actor. Questions to identify use cases for a system: What are the tasks of each actor? Will any actor create, store, change, remove, or read information in the system? What use cases will create, store, change, remove or read this information? Will any actor need to be informed about certain occurences in the system? What use cases will support and maintain the system? Can all functional requirements be performed by the use cases?

53 Modelo de Casos de Uso: Casos de Uso (2)
Un caso de uso puede ser pequeño o grande pero logra un objetivo discreto para algún usuario. Un caso de uso tipicamente representa una parte importante de la funcionalidad que se completa de principio a fin. Un caso de uso debe proveer algo de valor para el actor. Definición de un caso de uso: curso básico de eventos, número de cursos de acción excepcionales o alternativos No existe estandar para ellos en UML

54 Modelo de Casos de Uso: Casos de Uso (3)
Ejemplos de definición de un caso de uso: Nombre: nombre usado para referirse al caso de uso Resumen: una descripción corta Actores: todos los actores involucrados Precondiciones: condiciones del sistema al comienzo de un caso de uso. Descripción: la descripción completa Excepciones: casos especiales Resultado: condición del sistema al final del caso de uso

55 Ejemplo: Carreteras Casos de Uso (1)
Una persona puede aplicar para registrarse como cliente Alguna información personal deber ser entregada y registrada en el sistema, el cliente comienza con una cuenta en cero. Un cliente puede aplicar a una tarjeta El sistema verifica la cuenta, cuando el límite de crédito es excedido, la tarjeta es negada, sino una nueva tarjeta es entregada y el sistema lo registra. Un cliente puede aplicar por una tarjeta prepago El sistema verifica la cuenta, cuando el límite de crédito es excedido la tarjeta es rechazada, sino una nueva tarjeta es entregada y el sistema lo registra. El sistema imprime una factura para la nueva tarjeta y actualiza la cuenta del cliente.

56 Ejemplo: Carreteras Casos de Uso (2)
Un cliente puede (tratar de) viajar una trayectoria en una fecha dada con una tarjeta regular. El cliente entra a la red vial a través de algún tipo de control de acceso. El sistema verifica la validez de las tarjetas y la cuenta del cliente; Cuando se aprueba, el sistema registra el nodo de entrada y la fecha de entrada para la tarjeta y permite el acceso; Cuando no esta ok, el acceso es denegado. El cliente deja la red vial en algún punto con otro nodo de control. El sistema calcula el precio total, lo imprime como una factura, actualiza la cuenta de cliente y permite la salida.

57 Ejemplo: Carreteras Casos de Uso (3)
Un cliente puede (intentar) viajar una trayectoria en una fecha dada con un tarjeta de vacaciones. Es una variación del caso previo, a la salida no se imprime factura la cuenta del cliente no es actualizada. Un cliente puede (intentar) viajar una trayectoria en un día dado con una tarjeta minitrip. Es una extensión del caso de uso anterior, los nodos de entrada y salida son verificados contra la trayectoria para la cual esta hecha la tarjeta. Un ingeniero puede actualizar la red de carreteras Un fiscalizador o auditor puede registrar el pago de una factura.

58 Apply For Card <<includes>> Apply For Prepaid Card Travel Trajectory With Regular Card customer Travel Trajectory With Season Card Travel Trajectory With Minitrip Card <<extends>> Update Road Network Register Payment Of Invoices engineer bookkeeper

59 Diagramas de Casos de Uso Relaciones de Actores
La relación de “asociación” entre un actor y un caso de uso La participación de un actor en un caso de uso Es la única relación entre los actores y los casos de uso La “generalización” de un actor A a un actor B Indica que una instancia de A puede comunicarse con la misma clase de instancias de casos de uso que una instancia de B

60 Diagramas de Casos de Uso Relaciones de Casos de Uso
La relación <<incluye>> permite factorizar una porción de comportamiento que es similar a través de dos o más casos de uso para evitar copiar descripciones de ese comportamiento La relación <<extiende>> provee una forma más controlada de extensión del comportamiento de un caso de uso que la relación de generalización. El caso de uso base declara un número de puntos de extensión. El caso de uso extendido puede solamente alterar el comportamiento de esos puntos de extensión. La relación de “generalización” indica que uno de los casos de uso es una variación del otro. Permite a un caso de uso especializado cambiar cualquier aspecto del caso de uso base.

61 After creation of the deal
Analyze Risk Price Deal <<includes>> Valuation Trader Capture Deal _________ Extension points After creation of the deal Request Catalog <<extends>> Limits Exceeded SalesPerson

62 Relaciones de Casos de Uso Reglas empíricas
Usar incluir cuando se esta repitiendo dos o más casos de uso y se quiere evitar la repetición Use generalización cuando esta describiendo una variación de un comportamiento normal y desea describirlo brevemente Use extender cuando este describiendo la variación de un comportamiento normal y se desea hacerlo de una manera más controlado, declarando los puntos de extensión en el caso base.