Contenidos Diseño orientado a objetos Curso de Programación en Java! Fundamentos del diseño orientado a objetos! Casos de uso! Diseño orientado a objetos Jesús Montes Sánchez jmontes@fi.upm.es Marzo 2011 Programación orientada a objetos Fundamentos del diseño orientado a objetos! Facilidad de diseño y relación con el mundo real! Reusabilidad y facilidad de mantenimiento! Sistemas más complejos! Abstracción! Trabajo en equipo! Del lenguaje máquina hacia el mundo real! Resuelve problemas complicados. No está pensado para tareas sencillas Ciclo de vida del soqware Ciclo de vida del soqware Implantación Validación Especificación Análisis Diseño! Especificación y análisis! Se especifican las tareas que va a realizar el sistema! QUÉ hace nuestro programa?! Diseño! Se dis[nguen las diferentes partes del sistema y su interacción! CÓMO lo hace? Programación 1
UML (Unified Modeling Language) Especificación y análisis! Lenguaje unificado de modelado! Planos de la aplicación. No sirve para desarrollar, sino para describir (análisis y diseño)! Se u[lizan diferentes diagramas. (13 [pos en UML 2.0)! Definimos de forma no ambigua QUÉ va ha hacer nuestro programa.! Funcionalidades del programa.! Mecanismos de interacción con el usuario.! Como interactúa con el exterior.! Definición de CASOS DE USO Sistema y entorno Modelo de caja negra! Sistema! El programa que estamos desarrollando. Es el objeto de nuestro trabajo y es lo que especificamos, analizamos, diseñamos, programamos! Entorno! Todo aquello que aparece en nuestro análisis y diseño y que es externo al sistema.! Usuarios! Otros sistemas!! Los elementos del entorno deben ver al sistema como una caja negra! Una caja negra es un sistema cerrado, del que no conocemos su funcionamiento.! Una caja negra ofrece una interfaz con el exterior, que permite usarla. A través de dicha interfaz los usuarios pueden operar la caja y recibir los resultados de dicha operación.! El proceso de análisis y diseño se basa en este principio fundamental. Se analiza y diseña cada componente del sistema como una caja negra y luego se profundiza, repi[endo el proceso en su interior. Casos de uso Casos de uso! Cada caso de uso es una historia de uso del sistema.! Los casos de uso SON requisitos.! Recogen fundamentalmente requisitos funcionales.! Los casos de uso NO SON ORIENTADOS A OBJETOS. 2
Casos de uso Elementos de un caso de uso! Los casos de uso permiten considerar y organizar los requisitos en el contexto de los obje[vos y escenarios de uso del sistema.! Los casos de uso mejoran la comprensión y cohesión frente a una lista extensa de caracterís[cas inconexas.! Ejemplo: procesar una venta El cliente llega a la caja con los arjculos que desea comprar. El cajero pasa cada arjculo por el lector de código de barras y el sistema presenta el coste total de la compra. El cliente paga y el sistema registra y valida el pago. El sistema actualiza el inventario y produce un recibo. El cliente se va con sus arjculos y su recibo.! Precondiciones! Aquello que se debe cumplir para que el caso se de.! Actor! Individuo involucrado en el caso de uso.! Escenario o curso de eventos! Lo que ocurre cuando se da el caso de uso.! Garanja de éxito (postcondiciones)! Resultado final del caso de uso. Actor Escenario o curso de eventos! En[dad externa al sistema que interactúa con él.! Tiene comportamiento propio.! Pueden ser humanos, organizaciones, disposi[vos informá[cos! Se nombran por el rol que desempeñan: Cliente, cajero, administrador! En un diseño con varios sistemas, un programa (sistema) puede ser actor de otro.! Una secuencia específica de acciones e interacciones entre los actores y el sistema objeto de estudio.! Puede haber escenarios de éxito! Ejemplo: procesar una venta sin incidencias! y escenarios de fracaso! Ejemplo: Procesar una venta donde el cliente no lleva suficiente dinero para pagarla y debe cancelarse la venta. Definición de caso de uso Planteamiento de casos de uso! Un caso de uso es una colección de escenarios de éxito y fracaso relacionados, que describe a los actores u[lizando el sistema para sa[sfacer un obje[vo.! Estrategia basada en Actores! Iden[ficar actores principales.! Iden[ficar los obje[vos de usuario de dichos actores.! Definir un caso de uso por cada obje[vo de usuario.! Estrategia basada en Eventos! Iden[ficar eventos a los que debe responder el sistema.! Relacionar los eventos con actores y casos de uso. 3
Casos de uso (UML) Especificación de casos de uso! Nombre Actor! Actores Caso de uso Nombre Nombre! Escenario principal de éxito Nombre Sistema Ejemplo: programa mi mi: Actores! mi es un programa que permite a dis[ntos usuarios enviarse mensajes electrónicos.! Un usuario de mi usa el programa a través de su interfaz.! Un usuario de mi se iden[fica con su nombre y su contraseña.! Los usuarios de mi puede enviar mensajes a otros indicando el nombre del des[natario y el texto del mensaje.! Usuario! La persona que hace uso de la aplicación! No hay mas actores! Los usuarios de mi pueden acceder al sistema para ver si [ene mensajes nuevos en su buzón y leerlos. mi: casos de uso mi: diagrama de casos de uso! Enviar un mensaje! El usuario envía un mensaje a otro usuario del sistema.! Consultar no léidos! El usuario consulta los mensajes recibidos en su buzón.! Iniciar sesión?! NO: No es un caso de uso porque no representa un uso completo del sistema. El obje[vo del usuario nunca es iniciar sesión sin mas. Usuario mi Enviar mensaje Consultar no leídos 4
mi: consultar no leídos! Actores! Usuario! Escenario principal 1. El usuario se auten[ca con su nombre y contraseña. 2. El sistema da la bienvenida al usuario. 3. El usuario selecciona la opción de enviar un mensaje, indicando el des[natario y texto del mensaje. 4. El sistema envía el mensaje y confirma la operación.! Contraseña incorrecta: El sistema da error y la operación termina.! Des[natario no encontrado: El sistema da error y se vuelve a 2.! Actores! Usuario! Escenario principal 1. El usuario se auten[ca con su nombre y contraseña. 2. El sistema da la bienvenida al usuario. 3. El usuario selecciona la opción de leer los mensajes no leídos. 4. El sistema muestra los mensajes al usuario.! Contraseña incorrecta: El sistema da error y la operación termina.! No hay nuevos: En 4, el sistema no[fica que no hay mensajes. Diseño Diseño orientado a objetos! La especificación y análisis en casos de uso nos dan una idea clara de las funcionalidades que va a tener nuestro programa y como se interactúa con él.! Hasta ahora hemos visto el programa completo (sistema) como una caja negra.! El siguiente paso es entrar en la caja y definir los elementos que la forman: Clases y objetos. Iden[ficación de conceptos Iden[ficación de clases! Iden[ficar sustan[vos y frases nominales, en los casos de uso completos, en los requisitos, y en descripciones del dominio.! Intui[vamente (mucho cuidado con esto)! Cada nombre un objeto! Cada verbo un método! En general, los principales conceptos de nuestro programa estarán representados por clases que se instanciarán en objetos.! Iden[ficar conceptos! Iden[ficar elementos que dis[nguen a esos conceptos: atributos! Iden[ficar relaciones entre clases! A par[r de los casos de uso, iden[ficar la interacción entre objetos que da lugar a la funcionalidad deseada. 5
Clases (UML) mi: iden[ficando conceptos! Nombre de la clase! Atributos! Métodos + público, - privado Nombre + atributo1: int - atributo2: double + método1(par1): int + método2(par1, par2): double + método3(): void! mi es un programa que permite a dis[ntos usuarios enviarse mensajes electrónicos.! Un usuario de mi usa el programa a través de su interfaz.! Un usuario de mi se iden[fica con su nombre y su contraseña.! Los usuarios de mi puede enviar mensajes a otros indicando el nombre del des[natario y el texto del mensaje.! Los usuarios de mi pueden acceder al sistema para ver si [ene mensajes nuevos en su buzón y leerlos. mi: clases mi: diagrama de clases!! Los elementos de comunicación con el exterior.!! Cada uno de los usuarios que hacen uso del sistema.! Mensaje! Los mensajes que los usuarios se intercambian.!! El buzón personal de cada persona. Con[ene los mensajes dirigidos a ésta. - nombre: String - contraseña: String Mensaje - texto: String Relaciones entre clases Asociación! Asociación! Agregación! Composición! Dependencia! Generalización! Relación entre clases que se man[ene en el [empo! Puede tener un nombre, una dirección y una cardinalidad.! Se refleja cuando se introducen referencias a objetos como atributos! Dependiendo de la cardinalidad, habrá que usar arrays o estructuras de datos Clase1 - Atributo1 - Atributo2 + Operación1 - Atributo3 Clase2 - Atributo + Operación1 + Operación2 6
Agregación Composición! Asociación con contenido semán[co.! Caso par[cular de agregación! Una clase representa el todo y la otra una parte! La parte no existe sin el todo! La parte no está necesariamente ligadas al todo (puede exis[r sin él) PC - Marca - Modelo - Monitor Pantalla! En Java la dis[nción entre agregación y composición es puramente conceptual (recolector de basura) Arbol - Hojas * Hoja Dependencia Generalización! Indica que una clase hace uso de otra.! Representa herencia entre clases. Clase padre! Una clase instancia otro objeto.! Se recibe un objeto como parámetro.! Se devuelve un objeto como resultado. Clase1 Clase2! Un caso par[cular de generalización es la Realización, que se da cuando se hereda de una clase de interfaz Clase hija <<interfaz>> Clase interfaz Clase1 Relaciones como atributos mi: diagrama de clases! Cuando una relación entre clases se refiere a un atributo de la clase, éste se pone sobre la línea que representa la asociación.! También se puede poner como un atributo más y dejar la línea vacía PC - Marca: String - Modelo: String PC - Marca: String - Modelo: String - Monitor: Pantalla - Monitor Pantalla Pantalla - usuarios: List<> - nombre: String - contraseña: String - buzónl: - mensajes: List<Mensaje> Mensaje - remitente: - texto: String - destinatario: 7
Operaciones! A par[r de los casos de uso iden[ficados, se describen las operaciones del sistema.! Esta descripción se puede hacer de manera informal (en texto) o mediante diagramas de interacción. Por sencillez, en este curso lo haremos de manera informal.! UML proporciona dos [pos de diagramas de interacción: diagramas de secuencia y diagramas de colaboración.! La descripción de estas operaciones dará lugar a los métodos de las clases del sistema.! Caso de uso:! Escenario principal 1. El usuario se auten[ca con su nombre y contraseña. 2. El sistema da la bienvenida al usuario. 3. El usuario selecciona la opción de enviar un mensaje, indicando el des[natario y texto del mensaje. 4. El sistema envía el mensaje y confirma la operación.! Contraseña incorrecta: El sistema da error y la operación termina.! Des[natario no encontrado: El sistema da error y se vuelve a 2. 1. El usuario se auten[ca, indicando su usuario y contraseña. 2. La interfaz localiza al usuario (objeto ). Si la contraseña es correcta con[núa. Si no, se da un mensaje de error. 3. La interfaz solicita el nombre del des[natario y lo busca. Si lo encuentra con[núa. Si no, da un mensaje de error. 4. La interfaz solicita el texto del mensaje. 5. La interfaz crea el mensaje y se lo entrega a la persona des[no. 6. La persona des[no almacena el mensaje en su buzón. Auten[car Enviar mensaje Comp. contraseña Entregar mensaje Crear 1 (rem.) 2 (dest.) Mensaje Guardar mensaje mi: consultar no leídos! Métodos necesarios:!! auten[car (usuario, contraseña) :! enviarmensaje (remitente, des[natario, texto)!! obtenernombre () : String! comprobarcontraseña (contraseña) : Boolean! entregarmensaje(mensaje)! Mensaje! crearmensaje (remitente, des[natario, texto)!! almacenarmensaje (mensaje)! Caso de uso! Escenario principal 1. El usuario se auten[ca con su nombre y contraseña. 2. El sistema da la bienvenida al usuario. 3. El usuario selecciona la opción de leer los mensajes no leídos. 4. El sistema muestra los mensajes al usuario.! Contraseña incorrecta: El sistema da error y la operación termina.! No hay nuevos: En 4, el sistema no[fica que no hay mensajes. 8
mi: consultar no leídos 1. El usuario se auten[ca, indicando su usuario y contraseña. 2. La interfaz localiza al usuario (objeto ). Si la contraseña es correcta con[núa. Si no, se da un mensaje de error. 3. La interfaz solicita a la sus mensajes no leídos. 4. La persona solicita a su sus mensajes no leídos. Auten[car Ver no leídos Comp. contraseña Ver no leídos Obtener no leídos 5. La interfaz muestra por pantalla los mensajes no leídos, si los hay. 6. El buzón se vacía mi: diagrama de clases! Métodos necesarios (no vistos antes):!! vernoleídos()!! vernoleídos() : List<Mensaje>!! obtenernoleídos() : List<Mensaje> - usuarios: List<> + autenticar (usuario: String, contraseña: String) + enviarmensaje(destinatario: String, texto: String) + vernoleídos() - nombre: String - contraseña: String - buzónl: + obtenernombre(): String + comprobarcontraseña(contr: String): Boolean + entregarmensaje(mensaje: Mensaje) + vernoleídos(): List<Mensaje> - mensajes: List<Mensaje> + almacenarmensaje(mensaje: Mensaje) + obtenernoleídos(): List<Mensaje> Mensaje - remitente: - texto: String - destinatario: + crear(remit:, dest:, texto: String) 9