diseño’orientado’aobjetos’ -...

27/03/11

Diseño orientado a objetos Curso de Programación en Java

Jesús Montes Sánchez jmontes@fi.upm.es

Marzo 2011

Contenidos

!   Fundamentos del diseño orientado a objetos

!   Casos de uso

!   Diseño orientado a objetos

Fundamentos del diseño orientado a objetos

Programación orientada 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

Especificación

Análisis

Diseño

Programación

Validación

Implantación

Ciclo de vida del soQware

!   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?

27/03/11

UML (Unified Modeling Language)

!   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)

Especificación y análisis

!   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

!   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

Modelo de 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

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

27/03/11

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

Elementos de un caso de uso

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

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

Escenario o curso de eventos

!   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

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

Planteamiento de casos de uso

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

27/03/11

Casos de uso (UML)

Nombre

Caso de uso

Sistema

Especificación de casos de uso

!   Nombre

!   Actores

!   Escenario principal de éxito

!   Escenarios alterna[vos

Ejemplo: programa miBuzón

! miBuzón es un programa que permite a dis[ntos usuarios enviarse mensajes electrónicos.

!   Un usuario de miBuzón usa el programa a través de su interfaz.

!   Un usuario de miBuzón se iden[fica con su nombre y su contraseña.

!   Los usuarios de miBuzón puede enviar mensajes a otros indicando el nombre del des[natario y el texto del mensaje.

!   Los usuarios de miBuzón pueden acceder al sistema para ver si [ene mensajes nuevos en su buzón y leerlos.

miBuzón: Actores

!   Usuario !   La persona que hace uso de la aplicación

!   No hay mas actores

miBuzón: 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.

miBuzón: diagrama de casos de uso

Usuario

miBuzón

Enviar mensaje

Consultar no leídos

27/03/11

miBuzón: enviar mensaje

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

!   Escenarios alterna[vos !   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.

miBuzón: 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 leer los mensajes no leídos. 4.  El sistema muestra los mensajes al usuario.

!   Escenarios alterna[vos !   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 orientado a objetos

Diseño

!   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[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[ficación de clases

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

27/03/11

Clases (UML)

!   Nombre de la clase

!   Atributos

!   Métodos

+ público, -‐ privado

+ método1(par1): int+ método2(par1, par2): double+ método3(): void...

+ atributo1: int- atributo2: double...

Nombre

miBuzón: iden[ficando conceptos

! miBuzón es un programa que permite a dis[ntos usuarios enviarse mensajes electrónicos.

!   Un usuario de miBuzón usa el programa a través de su interfaz.

!   Un usuario de miBuzón se iden[fica con su nombre y su contraseña.

!   Los usuarios de miBuzón puede enviar mensajes a otros indicando el nombre del des[natario y el texto del mensaje.

!   Los usuarios de miBuzón pueden acceder al sistema para ver si [ene mensajes nuevos en su buzón y leerlos.

miBuzón: clases

!   Interfaz !   Los elementos de comunicación con el exterior.

!   Persona !   Cada uno de los usuarios que hacen uso del sistema.

!   Mensaje !   Los mensajes que los usuarios se intercambian.

!   Buzón !   El buzón personal de cada persona. Con[ene los mensajes

dirigidos a ésta.

miBuzón: diagrama de clases

Buzón

- texto: String

Mensaje

- nombre: String- contraseña: String

Persona

Interfaz

Relaciones entre clases

!   Asociación

!   Agregación

!   Composición

!   Dependencia

!   Generalización

Asociació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

+ Operación1+ Operación2

- Atributo

Clase2

+ Operación1

- Atributo1- Atributo2

Clase1

- Atributo3

27/03/11

Agregación

!   Asociación con contenido semán[co.

!   Una clase representa el todo y la otra una parte

!   La parte no está necesariamente ligadas al todo (puede exis[r sin él)

Pantalla

- Marca- Modelo

- Monitor

Composición

!   Caso par[cular de agregación

!   La parte no existe sin el todo

!   En Java la dis[nción entre agregación y composición es puramente conceptual (recolector de basura)

Arbol- Hojas *

Dependencia

!   Indica que una clase hace uso de otra.

!   Una clase instancia otro objeto.

!   Se recibe un objeto como parámetro.

!   Se devuelve un objeto como resultado.

Clase2

Clase1

Generalización

!   Representa herencia entre clases.

!   Un caso par[cular de generalización es la Realización, que se da cuando se hereda de una clase de interfaz

Clase hija

Clase padre

Clase1

<<interfaz>>Clase interfaz

Relaciones como atributos

!   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

Pantalla

- Marca: String- Modelo: String

- Monitor

Pantalla

- Marca: String- Modelo: String- Monitor: Pantalla

- usuarios: List<Persona>

Interfaz

- mensajes: List<Mensaje>

Buzón

- nombre: String- contraseña: String- buzónPersonal: Buzón

Persona

- remitente: Persona- texto: String- destinatario: Persona

Mensaje

27/03/11

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.

!   Escenarios alterna[vos !   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 Persona). 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.

Interfaz

Persona 1 (rem.)

Persona 2 (dest.)

Mensaje

Buzón

Auten[car

Enviar mensaje

Comp. contraseña

Entregar mensaje

Guardar mensaje

!   Métodos necesarios: !   Interfaz

!   auten[car (usuario, contraseña) : Persona ! enviarMensaje (remitente, des[natario, texto)

!   Persona ! obtenerNombre () : String ! comprobarContraseña (contraseña) : Boolean ! entregarMensaje(mensaje)

!   Mensaje ! crearMensaje (remitente, des[natario, texto)

!   Buzón ! 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.

!   Escenarios alterna[vos !   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.

27/03/11

1.  El usuario se auten[ca, indicando su usuario y contraseña.

2.  La interfaz localiza al usuario (objeto Persona). Si la contraseña es correcta con[núa. Si no, se da un mensaje de error.

3.  La interfaz solicita a la Persona sus mensajes no leídos.

4.  La persona solicita a su Buzón sus mensajes no leídos.

5.  La interfaz muestra por pantalla los mensajes no leídos, si los hay.

6.  El buzón se vacía

Interfaz Persona

Buzón

Auten[car

Ver no leídos

Obtener no leídos

Comp. contraseña

!   Métodos necesarios (no vistos antes): !   Interfaz

! verNoLeídos()

!   Persona ! verNoLeídos() : List<Mensaje>

!   Buzón ! obtenerNoLeídos() : List<Mensaje>

+ autenticar (usuario: String, contraseña: String)+ enviarMensaje(destinatario: String, texto: String)+ verNoLeídos()

- usuarios: List<Persona>

Interfaz

+ almacenarMensaje(mensaje: Mensaje)+ obtenerNoLeídos(): List<Mensaje>

- mensajes: List<Mensaje>

Buzón

+ obtenerNombre(): String+ comprobarContraseña(contr: String): Boolean+ entregarMensaje(mensaje: Mensaje)+ verNoLeídos(): List<Mensaje>

- nombre: String- contraseña: String- buzónPersonal: Buzón

Persona

+ crear(remit: Persona, dest: Persona, texto: String)

- remitente: Persona- texto: String- destinatario: Persona

Mensaje

diseño’orientado’aobjetos’ -...

Documents

sistemas distribuidos -...

introducción&ajava -...

sistemas distribuidos -...

modelización de sistemas biológicos -...

programación orientada a objetos i -...

modelización de sistemas biológicos -...

diseño de sistemas operativos -...

diseño de sistemas operativos -...

sistemas distribuidos -...

tema 1 introducción -...

sistemas operativos distribuidos -...

tema 1 introducción -...

sistemas distribuidos fernando pérez...

sistemas operativos...

curso de java -...

arquitectura de los sistemas...

introducción&ajava -...

tema 1 introducción -...

capítulo 4 planificación del...

sistemas distribuidos -...