Resumen Completo MOO (2015)

Apunte Español
Universidad Universidad Politécnica de Cataluña (UPC)
Grado Ciencias y Tecnologías de Telecomunicación - 1º curso
Asignatura Metodologia y Programacion Orientada a Objetos - MOO
Año del apunte 2015
Páginas 13
Fecha de subida 24/01/2015
Descargas 21
Subido por

Vista previa del texto

2-POO • • • • Modelo de programación que utiliza objetos que colaboran entre si para resolver problemas Facilidad en el diseño problema en clases Modularidad y reutilización de código Facilidad en el mantenimiento Objeto (Entidad) • • Atributos: propiedades que lo caracterizan Métodos: formas de operar Clases • • • Tipos de objetos definidos por el programador Generalización de un tipo especifico de objetos Un objeto de una clase se crea en el momento que se define una variable de dicha clase Características POO Abstracción • Expresa las características esenciales de un objeto, aquellas que lo distinguen del resto Herencia • • • Permite que los objetos sean creados a partir de otros Heredan atributos y métodos Garantiza la reutilización de código Polimorfismo • • Implementar múltiples formas de un mismo método Cada implementación dependerá de la clase sobre la que se realice Encapsulación • • Ver objetos como una caja negra Modificar atributos del objetos a través de los métodos definidos 3-Java • • Lenguaje de programación de alto nivel Plataforma • POO Orientado a objetos, creación y interacción de objetos • Independiente de la plataforma JavaVM • Gestión dinámica de la memoria: o Crea objetos o Garbage Collector (elimina objetos no usados) • Seguro • Simple o No hay construcciones complejas o Se usan referencias a objetos (no punteros) • Distribuida • Multihead 4-Clases y Objetos Java Clase Nombre Empieza en mayúscula Modificador de acceso Relación con otras clases de otros paquetes Niveles de protección Atributos Propiedades Métodos Conjunto de sentencias que ejecutan una tarea determinada Constructores Procedimiento especial que es llamado automáticamente siempre que se crea un objeto de la clase. Inicia el objeto [mod] class NomClase{ //Definición de atributos //Definición de constructores //Definición de métodos } Carlos Angulo Paquete: contiene un conjunto de clases Importar Package nomPaquete; nomPaquete.NomClase Import nomPaquete.NomClase Import nomPaquete.* importa todas Resumen MOO 1 Modificadores: niveles de acceso • private misma clase • public cualquier parte del programa • protected clases del mismo package o derivada Atributos [mod] tipoDato nomAtri; Objeto • Instancia de una clase • Tiene los mismos atributos pero con valores diferentes • Operador “new” • Reserva memoria (un bloque) • Devuelve la dirección del bloque MiClase nomObjeto = new MiClase([listaParam]); Métodos [mod] tipoRet nomMetodo([listaParam]){ //declaración variables locales //sentencias return [variabledetipoRet]; } • Si no devuelve nada  void Constructores: cada vez que se crea un objeto [mod] NombreConstructor([listaParam]){ //código del constructor inicialización de las variables del objeto //uso del this.atributo } • una clase puede tener muchos constructores con parámetros diferentes( o sin parámetro).
Referencia a this.
• Referencia que apunta al propio objeto • Diferencia los atributos de los parámetros o variables locales 5-Encapsulamiento Encapsulación • Mostrar solo los aspectos necesarios ocultando todo lo que se considera interno y no deba ser mostrado • Permite que una clase tenga muchos atributos y operaciones que solo la propia clase conoce y nadie más puede utilizar, de forma que solo muestra los elementos con los cuales es posible interactuar • Ocultar los atributos de un objeto de forma que solo se puedan modificar mediante los métodos definidos para dicho objeto Métodos de acceso Consultar valores • Getters • Devuelve el valor del atributo getX() Asignar valores • Setters • Se les pasa el valor a asignar al atributo setX(tipoDato atrib) Carlos Angulo X=atributo Resumen MOO 2 Guía de estilo java (convención) Se han de encapsular todos los atributos excepto los que sean accesibles por herencia, que serán protected Atributos private tipoDatos nomAtri; Getters public tipoRetun getNomAtri(); Setters public void setNomAtri([tipoDato atrib]); Modificadores Para atributos y métodos static Asocia los atributos y métodos a la clase no a los objetos final Impide que se modifique su valor durante la ejecución del programa Atributos de instancia • Comunes para todos los objetos de clase • Valores diferente para cada objeto (instancia de la clase) Atributos estáticos • El atributo es de la clase • Lo comparten todos los objetos o Hay una sola copia o Si se modifica para uno se modifica para todos • [mod] static tipoDato nomAtri; • Acceso a través o NombreClase.nomAtributo Métodos estáticos • • • • Atributos finales • Atributos para los que su valor permanecerá constante durante la ejecución del programa • Solo se le puede asignar un valor u objeto a la vez [mod] final tipoDato nomAtribu; • El valor se ha de asignar en la declaración del atributo o en el constructor Mod. Final.
Variables • Solo se puede asignar un valor una vez [mod] final tipoDAto nomVarible; Métodos finales • No permite que una clase derivada la modifique [mod] final miMetodo([listaParam]) [mod] miMetodo(final tipoDato1 nom1…)no se puede modificar el valor de los parámetros, su valor dentro del método Mod. Final.
Clases.
• Clase final cuando no nos interesa crear clases derivadas final NomClase; Constantes [mod] static final tipoDatos NOMCONSTANTE = valor; • nombre siempre en mayúscula Carlos Angulo Operaciones comunes a todos los objetos de la clase No acceden a los atributos de la clase a la que pertenecen Se puede invocar sin haber creado ningún objeto nomClase.metodoEstatico() Resumen MOO 3 6-Contenedores Vectores • • Crear Vector nomVector = nom Vector(tam); acceso nomVector[pos] Se ha de definir el tamañotamaño fijo Gestión de sus elementos es compleja Conjuntos: no ordenados Colecciones • • • Listas: ordenados Se redimensionan dinámicamente No tienen tamaño fijo Package java.util.NomCole; Mapas acceso mediante clave NomClasseContenidor<NomClasseDesada> nomVariable = new NomClasseContenidor<NomClasseDesada>(); No ordenados No pueden haber objetos repetidos Tiene la opción de pasara un iterator Clases: HashSet, TreeSet, SortedSet, LinkedHashSet add(obj): boolean remove(obj): boolean clear(): void contains(obj): boolean size():int iterator(): Iterator<Object> isEmpty():boolean toArray():Object[] Lista • Ordenados por un índice • Acceso por este índice • Podemos añadir, obtener y eliminar elementos de cualquier posición • Tiene la opción de pasara un iterator • Clases: ArrayList, LinkedList get(pos): Object contains(obj): boolean add(obj): boolean add(pos,obj) void clear(): void remove(obj): boolean remove(pos): Object indexOf(obj): int set(pos, obj): Obj iterator(): Iterator<Object> Iterator • Objetos que recorren todos los elementos de un conjunto o lista • Podremos acceder a todos los elementos • Package java.útil hasNext(): boolean next(): Object • Acceso mediante una clave única • Mapa<TipoClave,TipoObjecto> nom • Clases HashMap, TreeMap, HashTable containsKey(key):boolean containsValue(value):boolean clear(): void get(key):Object isEmpty():boolean keySet():Set<Object> put(key,Object):Object remove(key): Object size():int Conjuntos Mapas • • • • Carlos Angulo Resumen MOO 4 7 Diagramas de Clases Clases • • • Atributos Métodos Visibilidad Relaciones • • • • <NomClase> Asociación Agregación Herencia Dependencia Modificador es de acceso - Private +Public #Protected <Atributos> 𝑚𝑜𝑑 𝑛𝑜𝑚: 𝑡𝑖𝑝𝑜 + − 𝑛𝑜𝑚: 𝑡𝑖𝑝𝑜 # <Métodos> Relaciones entre clases 1.
Asociación Clase A 2.
Una asociación, donde la clase origen y destino son la misma, la llamamos asociación reflexiva.
Clase B • Objetos que colaboran entre si • ClaseA tiene objetos de tipo ClaseB Clase B • Objetos de un extremo forma parte de los objetos del otro • La ClaseA tiene como atributos objeto de tipo ClaseB, en consecuencia sus objetos también • Si se elimina el contenedor, el contenido sigue existiendo Agregación Clase A Agregación fuerte (o composición) 3.
Clase A Clase B agregador agregado Dependencia Clase A 4.
Clase B • El objeto de la clase B, agregado no tiene sentido sin el de clase A, agregador • El objeto agregado es parte vital de agregador • El tiempo de vida del agregado esta condicionado por el tiempo de vida del agregador • Si el agregador (ClaseA) se elimina, también se elimina el agregado (claseB) • Una clase hace uso de la otra, de sus métodos • Un objeto de clase B no es atributo de una de claseA Herencia • Clase hija hereda de la clase Padre • Todos los atributos (que estén en protected) superclase subclase • Todos los métodos, todos menos los constructores • La clase hija es más especifica, la clase Padre más Definicion SubClase genérica (es una generalización de las subclases) Public class ClaseB extends ClaseA{ Extensibilidad } • Las subclases puede redefinir los métodos Definición constructor SubClase heredados y añadir nuevos atributos y métodos Public NombreSubClase([parámetros]){ • El constructor de la subclase ha de invocar al de la superclase con “super” Super([paramDeSuperClase]) • Acceso atributos de la SuperClase desde la } subclase Conversión en implícita super.atributoDeSuperClase ClaseA nomObjecte =new ClaseB();referencia Clase A Clase B a superclase Carlos Angulo Resumen MOO 5 5.
Asociación calificada Clase A Tipoclave:nomclave Clase B • Utilizar mapa • Clave establecida en el diagrama 9 Polimorfismo • Capacidad de llamar a muchos métodos con una sentencia • Cuando se invoca un método redefinido en una subclase la versión que se ejecutar dependen de la clase del objeto referenciado • Redefinir los métodos en las subclases Clases Abstractas • Clase genérica, que no necesita instancias  NO se puede INSTANCIAR, pero si referenciar • Proporciona atributos y métodos básicos que serán compartidos por todas las subclases public abstract class NomClase • Las subclases DEBEN implementar OBLIGATORIAMENTE los métodos abstractos de su superclase Metodos Abstractos • En ClaseA solo tendrá cabecera ya que será redefinido en la subclase, en CURSIVA • En ClaseA[mod] abstract tipoRet nomMeto(param); • En ClaseB[mod] tipoRet nomMeto(param); Interfaces • Plantillas de comportamiento que se espera sean implementados en las subclases • Declaran un conjunto de método per no los definen • Conjunto de métodos abstractos y constantes public interface nomInterface Interface{} • NO se puede INSTANCIAR pero si referenciar • Una clase puede implementar varias interfaces • En las subclases se ha de poner implements public class nomSubClasse implements nomInterface{} Carlos Angulo Resumen MOO 6 10 Excepciones • • • • • manejar situaciones anómalas verificación de errores contiene datos que describen el error(tipo, mensaje, punto del programa) objeto de clases derivadas de Throwable cuando se produce un error, una anomalía, se crea un objeto (Excepción) y se lanza throw el catch lo caza y se encarga de tratarlo METODO QUE LANZA LA EXCEPTION public tipoRet nomMet() trows Tipo_Exception_Lanzada{ //Código del método que lanzara una Exception en un determinado caso if(caso malo){ throw newException(“Descripcion”); }else{ //codigo } return tipoRet; } PROGRAMA DONDE RECIBE LA EXCEPTION try{ //Código de la aplicación //aquí estará un método que lanza una excepción }catch(Clase_Excepción_Lanzada cel){ //Tratamiento de excepción en caso de que no se lance //ninguna no entrara en el catch System.err.printlon(“Sucedió”`cel.getMEssage()); }finally { //operaciones comunes } Carlos Angulo Resumen MOO 7 11 Diagramas de secuencia UML • • Diagrama de interacción que muestra los objetos como líneas de vida Muestra las interacciones entre las diferentes instancias de los objetos de un programa para una aplicación concreta en el tiempo o Representadas como mensajes dibujados como flechas desde la línea de vida origen hasta la línea de vida destino Muestra qué objetos se comunican con qué otros objetos y qué mensajes disparan esas comunicaciones • Interacciones entre objetos 2 O1:Clase1 Los objetos pueden 1. Crear otro durante la ejecución de un método 2. Puedo invocar a un método de otro objeto 3. Puede destruir a otro objeto durante la ejecución de un método O2:Clase1 m1(a) res 1,2,3 O1:Clase1 • <<create>> • m1(a)= mensaje del objeto 1 (O1) que le pasamos al objeto 2 (O2) res lo que devuelve el O2 Tiempo de ejecución O2:Clase1 Condicionales m() O1:Clase1 O2:Clase1 [condición==true] m1() res [else] m2() <<drestroy>> Foco de control Iteraciones con condición dentro this O1:Clase1 O1:Clase1 m1() O2:Clase1 for(0,N-1) [condición==true] m1() [else] m2() Colección de objetos O1:Clase1 O2:Clase1 El método es de la clase a la que apunta a la que pertenece Clase a la que pertenece método() Carlos Angulo Resumen MOO 8 12 Análisis de requisitos • Funcionalidades que el cliente necesita y ha de tener el software Se plasma en • Especificación de Requisitos del Sistema (ERS) • Diagrama de entidad/relación que contendrá las principales entidades que desarrollaran el software • IEEE 830-1998 : estándar que normaliza la creación de especificaciones Casos de uso Tipos de requisitos • • • Comportamiento del sistema Secuencia de interacciones entre un sistema y alguien o algo que usa alguna de sus servicios La notación de casos de uso forma parte del lenguaje estándar de modelado UML Están acotados al uso de una determinada funcionalidad del sistema Describen tanto lo que hace el actor como lo que hace el sistema • • • • Funcionales: definen qué debe hacer nuestro sistema en términos de funcionalidad funcionamiento No funcionales: detalles más técnicos  características Contenido Caso de uso Actor • Agrupación uniforme de personas, sistemas o máquinas que interactúan con el sistema • Prologo o Número y nombre del caso de uso (expresado con un verbo en gerundio) o Objetivo que se persigue en el caso de uso o Actores • Elementos externos al sistema (ya sean personas o no) que intervienen en el caso de uso o Precondiciones o Postcondiciones Descripción de los Escenarios o Escenario principal o Escenarios alternativos Precondiciones o Son condiciones que siempre son ciertas antes de comenzar el escenario de éxito del caso de uso o No se comprueban, se asume que son ciertas o Pueden hacer referencia a otros casos de uso ya completados Postcondiciones o Refleja el estado en que se queda el sistema una vez ejecutado el caso de uso Actor primario o Interaccionan con el sistema para explotar su funcionalidad o Trabajan directa y frecuentemente con el software Actor de soporte o Suministra un servicio al sistema en desarrollo Proceso para generar los casos de uso: 1.
2.
3.
4.
Elegir los límites del sistema.
Identificar los actores primarios.
Identificar los objetivos Generar un caso de uso para cada objetivo.
Caso de uso Abstracto • Los detalles dependen de el tipo de objeto Escenarios Describe el conjunto de pasos que lleva de un Estado Inicial (Ei) a un Estado Final (Ef) • Escenario principal: el conjunto de pasos que llevan de Ei al Escenario final deseado (Efd) • Escenarios alternativos: el conjunto de pasos que llevan de Ei a un Escenario Final Alternativo (Efa1, Efa2...), alcanzados cuando la secuencia de pasos de Ei a Efd no puede finalizarse o Dan una salida controlada a una situación anómala (error del sistema, un dato mal introducido, un proceso erróneo del usuario...) Carlos Angulo Resumen MOO 9 Escenario Principal Escenario Alternativo • Escenario de éxito • • • Manejo de errores Posible bifurcación del Escenario principal Se numeran mediante el número de ese paso, seguido por una letra (a, b, c, d, etc) para cada extensión del escenario principal que comience en ese punto <<include>> Declara que el caso de uso del que parte la flecha punteada, usa completamente los pasos del caso de uso apuntado (incluido).
<<extends>> Un caso de uso extiende a otro caso de uso base, añadiendo nuevos pasos, cuando se dan ciertas condiciones. En este caso, la flecha apunta hacia el caso de uso base.
Escenario Principal EP 1.Introducción de datos 1) 2) 3) 4) Introducción de dato base 1 Introducción de dato base 2 … … 2.Comprobaci ón de datos 5) Comprobar dato base 1 A 6) … 7) … 3. Final 8) Crea Objeto principal, el cual necesitaba los datos bases anteriores Comprobar dato base = Comprobar existencia dato base 1 Escenario Alternativo 5a. Opción negación de A (!A) 1. Advierte al usuario 2. Confirmación de otro intento de introducción de datosB 3. Vuelve a paso 1 de EP 2a. ! B 1.Vuelve al menú principal 13 GRASP • • • General Responsibility Assignment Software Patterns Las responsabilidades se asignan a los objetos en el diseño Los patrones GRASP se aplican durante la elaboración de los diagramas de secuencia al asignar las responsabilidades a los objetos y al diseñar la colaboración entre ellos Responsabilidades • Contrato u obligación de un tipo o clase.
• Obligaciones que tiene un objeto.
Dos categorías: • Conocer: o Estar enterado de los datos privados encapsulados o Estar enterado de la existencia de objetos conexos o Estar enterado de cosas que se puede derivar o calcular • Hacer: o Hacer algo en uno mismo o Iniciar una acción entre objetos o Controlar y coordinar actividades entre objetos Carlos Angulo Resumen MOO Las responsabilidades se implementan usando métodos que operen solos o en colaboración con otros objetos y métodos 10 Patrones Alta cohesión Cada elemento de nuestro diseño debe realizar una labor Bajo acoplamiento • Las clases están lo menos ligadas entre sí que se pueda • Una modificación en una clase tendrá poca repercusión en las demás Experto • Asignar una responsabilidad al experto en información: o la clase que cuenta con toda la información necesaria para cumplir la responsabilidad o La responsabilidad de una función debe recaer en la clase que tiene toda la información para asumirla correctamente.
Creador • El patrón creador guía la asignación de responsabilidades relacionadas con la creación de objetos • Determina qué clase es la idónea para asumir la responsabilidad de crear un objeto (instancia de una clase) Controlador • Separa la lógica de la clase de presentación • Intermediario entre una interfaz y el algoritmo que la implementa.
• Recibe los eventos del usuario y accede/modifica a las distintas clases que controla Fabricación pura • Clases que no representan un concepto real dentro del dominio del problema.
• Creadas para disminuir el acoplamiento y/o aumentar la cohesión.
• Realizan funciones auxiliares.
Polimorfismo • Siempre que se tenga que llevar a cabo una responsabilidad que dependa del tipo se tiene que hacer uso del polimorfismo • Asigna el mismo nombre a métodos en diferentes objetos :interfazUsuario :Controlador ob:Object Da dato 1 Da datos Da dato 2 getObject Da dato 3 Object ob Metodo_de_object() Metodo_de_object():Patron experto: es el objeto ob el que tiene acceso a la información necesaria para llevar a cabo correctamente su responsabilidad mediante el método ejecutado Carlos Angulo Resumen MOO 11 Notas para el examen Final <NomClase> • • <Atributos> 𝑚𝑜𝑑 𝑛𝑜𝑚: 𝑡𝑖𝑝𝑜 + − 𝑛𝑜𝑚: 𝑡𝑖𝑝𝑜 # LEER TODO EL EXAMEN PRMERO ANALIZAR QUE NOS PIDE CADA EJERCICIO <Métodos> 1. Analizar los requerimientos • En una hoja aparte Diagrama UML 2. Hacer una hoja el diagrama UML y los ejercicios en otra • Comprobar las cardinalidades, relaciones y roles • Comprobar si es mejor la clase abstracta o una interface Implementación • Comprobar Contenedores, revisar si es más adecuado una lista o un mapa Casos de uso • Buscar los datos BÁSICOS NECESARIOS para llevar a cabo el objetivo , que serán posiblemente los que necesite un método • Buscar si en los requerimientos hay algo que afecte al escenario principal Carlos Angulo Resumen MOO 12 Ánimos Carlos Angulo Resumen MOO 13 ...