Tema 10: Interfaces Antonio J. Sierra.

Slides:



Advertisements
Presentaciones similares
FUNDAMENTALS OF THE JAVA PROGRAMMING LANGUAGE
Advertisements

Lenguaje Unificado de Modelado
Curso de Java Capitulo 7: Continuación Poo Profesor:
Curso de Java Capitulo 7: Conceptos sobre poo Profesor:
POLIMORFISMO UNIDAD 4.
TEMA 8: DIAGRAMAS EN UML.
Tomado de:
UML 1.4 Peter Emerson Pinchao Solis.
Arquitectura CLARO-TECNOTREE
UNIVERSIDAD LATINA (UNILA) ENCAPSULACION Y HERENCIA
Aplicación del paradigma orientado a objetos
INTRODUCCIÓN A UML Oscar Miguel Alonso Moreno.
LENGUAJE UNIFICADO DE MODELADO UML
DIAGRAMAS DE CLASES Completando los diagramas de interacción, es posible identificar la especificación de las clases que participarán en la solución indicando.
Diseño y programación de
Rosalía Laza Fidalgo Reyes Pavón Rial Curso
DESCRIPCION DEL PROBLEMA
Diagramas de clases Modelan la vista estática del sistema
HERENCIA.
Tema 7: Polimorfismo Antonio J. Sierra. Índice Introducción. Sobrecarga de métodos. Objetos como parámetros. Paso de argumentos. Devolución de objetos.
Lic. Rosemary Torrico Bascopé
Unified Modeling Language (Lenguaje de Modelamiento unificado)
Análisis y Diseño orientado a objetos con UML.
Profesor: Miguel Angel Vidal
El patrón de diseño Proxy Raúl Heras Alberto Blasco José Manuel Arévalo.
Clases y objetos La unidad fundamental de programación OO son las clases. Conjunto de métodos y semántica Qué se va a hacer POO Clase: que define la implementación.
Tema 6: Clases Antonio J. Sierra.
UNIDAD 2 CLASES Y OBJETOS. CLASE Elementos cabecera y cuerpo de la clase. Cabecera: aporta información fundamental sobre la clase en sí y constituye de.
Diagramas de Clase Angela Carrillo R..

ESTRUCTURA DE DATOS EN JAVA
Tema 11: Excepciones Antonio J. Sierra.
Ingeniería de Software Orientado a Objetos
UNIDAD 3: “Desarrollo Orientado a Objetos con UML”
Fundamentos de programación
CASOS DE USO Ing. Sonia Godoy H..
Ingeniería de software
Metodología de Programación Ayudantía 5 lelagos.ublog.cl 2009.
Diagrama de Clases ACI 570.
Herencia. Introducción La idea básica es poder crear clases basadas en clases ya existentes. Cuando heredamos de una clase existente, estamos re-usando.
Introducción a UML DIAGRAMA DE CLASES Departamento de Informática
Unidad 2.1: INTRODUCCIÓN A LA ORIENTACIÓN A OBJETOS.
TEMA 9: DIAGRAMA DE CLASE EN UML
Ingeniería de Software
La Universidad de Guayaquil Carrera de Ingeniería en Sistemas.
Clasificación de Diagramas
Introducción a la Programación Orientada a Objetos (POO)
Ingeniería de Requisitos
Introducción a UML Ing. José Manuel Poveda.
Ésta es la relación más común e importante. Se puede incluir una relación entre 2 casos de uso de tipo “include” si se desea especificar comportamiento.
UML.
Departamento de Informática Universidad de Rancagua Prof:Paula Quitral Introducción a UML Caso de uso Departamento de Informática Universidad de Aconcagua.
UML Casos de Uso (repaso) y Diagramas de Clase
Fundamentos del Análisis Orientado a Objetos
DESARROLLO DE PROYECTOS DE SOFTWARE ACTIVIDAD Y CASOS DE USO BARTOLOME CRUZ CRUZ.
Modelan la vista estática del sistema Elementos básicos: Clases Relaciones Objeto: Representación de una entidad discreta (real o abstracta) - Estado:
Unified Modeling Language (Lenguaje de Modelamiento unificado)
Clases “ Es una Abstracción de un elemento del mundo real ”
Diagrama de Clases.
PRESENTACION DE INGENIERIA ORIENTADA A OBJETOS
Fundamentos de Ingeniería de Software
Herencias Conceptos básicos i
Programación orientada a objetos La programación orientada a objetos o POO (OOP según sus siglas en inglés) es un paradigma de programación que usa objetos.
Modelado UML Diagramas de Casos de Uso
Presentación De UML Lenguaje estándar para escribir planos de software Se usa para visualizar, especificar, construir y documentar los artefactos de un.
1 Qué es UML Es un Lenguaje de Modelado Unificado basado en una notación gráfica que permite especificar,construir, visualizar y documentar los objetos.
Modelado UML Diagrama de Clases
Programación en Java Introducción a Java. Reseña histórica Surge en 1991 por Sun Microsystems Desarrollado para electrodomésticos Se buscaba un código.
Programación I Clases. Paradigma POO La programación Orientada a objetos (POO) es una forma programar, más cercana a como expresaríamos las cosas en la.
Programación en Java Introducción a Java. Reseña histórica Surge en 1991 por Sun Microsystems Desarrollado para electrodomésticos Se buscaba un código.
Transcripción de la presentación:

Tema 10: Interfaces Antonio J. Sierra

Índice 1. Definición de una interfaz. 2. Implementación y uso de una interfaz. 3. Extensión de las interfaces. 4. Modelado UML de las interfaces. 5. Casos de uso. Diagrama UML de los casos de uso.

Introducción Abstracción completa de la implementación de una clase. La interfaz no define la implementación. Métodos sin cuerpo. Una clase puede implementar cualquier número de interfaces. Una clase sólo puede heredar de una superclase (abstracta o no) Admiten resolución de método dinámica.

Definición de Interfaz (I) acceso interface nombre{ tipo var_final1 = valor; tipo var_final2 = valor; // … tipo var_finalN = valor; tipo_devuelto método1 (lista_de_parámetros); tipo_devuelto método2 (lista_de_parámetros); tipo_devuelto métodoN(lista_de_parámetros); }

Definición de Interfaz (II) acceso: o public o no se utiliza (por defecto). tipo var_final1 = valor; Implícitamente final y static.

Implementación parcial abstract class Imcompleto implements LaInterfaz{ int a, b; void muestra() { System.out.println(a +" " + b); } // …

Acceso a implementaciones a través de la interfaz Se pueden declarar variables referencias a la interfaz Cualquier instancia que implementa la interfaz puede almacenarse en una variable de ese tipo. El método al que llamar se determina dinámicamente durante la ejecución. Proceso similar al uso de una referencia a la superclase para acceder a un objeto de la subclase.

Herencia con interfaces Una interfaz puede heredar otra utilizando la palabra clave extends. La sintaxis es la misma que se utiliza en la herencia de clases. Cuando una clase implementa una interfaz que hereda de otra, tiene que implementar todos los métodos definidos en la cadena de herencia de la interfaz.

Interfaz en UML.Definición Una interfaz es una colección de operaciones que especifican un servicio de una clase o componente. Por lo tanto, una interfaz describe el comportamiento visible externamente de ese elemento. Una interfaz puede representar el comportamiento completo de una clase o componente o sólo una parte de este comportamiento. Una interfaz define un conjunto de especificaciones de operaciones (o sea, sus signaturas), pero nunca sus implementaciones. Una interfaz raramente se encuentra asilada, más bien, suele estar conectada a la clase o componente que la realiza.

Modelado UML de las interfaces Es un elemento estructural.

Caso de uso Un Caso de uso, es una descripción de un conjunto de secuencias de acciones que un sistema ejecuta y que produce un resultado observable de interés para un actor particular. Un caso de uso se utiliza para estructurar los aspectos de comportamiento en un modelo. Un caso de uso es realizado por una colaboración.

Modelado de los Casos de Uso Es un elemento estructural Realizar Pedido

Diagrama de casos de uso Un diagrama de casos de uso es una representación gráfica de parte o el total de los actores y casos de uso del sistema, incluyendo sus interacciones. Todo sistema tiene como mínimo un diagrama Main Use Case, que es una representación gráfica del entorno del sistema (actores) y su funcionalidad principal (casos de uso). El diagrama muestra los distintos requisitos funcionales que se esperan de una aplicación o sistema y cómo se relaciona con su entorno (usuarios u otras aplicaciones).

Actor Un actor es una entidad que utiliza alguno de los casos de uso del sistema. En el ejemplo observamos un único actor representando al usuario de la máquina de café.

Ejemplo. Máquina de Café Se tienen como casos de uso de la máquina de café RecibirDinero, PedirAzucar, PedirProducto, DarVueltas y Cancelar.

Tres tipos de Relaciones entre Casos de Uso "comunica" (<<communicates>>): Relación (asociación) entre un actor y un caso de uso que denota la participación del actor en dicho caso de uso. En el diagrama del ejemplo de la figura anterior todas las líneas que salen del actor denotan este tipo de asociación (en realidad estereotipada como <<comunicates>>). " usa'' ( <<uses>>) (o <<include>> en la nueva versión de UML): Relación de dependencia entre dos casos de uso que denota la inclusión del comportamiento de un escenario en otro. En el caso del ejemplo el caso de uso Cancelar incluye en su comportamiento al de DarVueltas y PedirProducto incluye también DarVueltas. "extiende'' (<< extends>>): Relación de dependencia entre dos casos de uso que denota que un caso de uso es una especialización de otro. Por ejemplo, podría tenerse un caso de uso que extienda la forma de pedir azúcar, para que permita escoger el tipo de azúcar (normal, dietético o moreno) y además la cantidad en las unidades adecuadas (cucharadas o bolsas).

Cuando usarlas Se utiliza una relación de tipo <<extends>> entre casos de uso cuando nos encontramos con un caso de uso similar a otro pero que hace algo más que éste (variante). Por contra, utilizaremos una relación tipo <<uses>> cuando nos encontramos con una parte de comportamiento similar en dos casos de uso y no queremos repetir la descripción de dicho comportamiento común. En una relación <<extends>> , un actor que lleve a cabo el caso de uso base puede realizar o no sus extensiones. Mientras, en una relación <<include>> el actor que realiza el caso de uso base también realiza el caso de uso incluido. En general utilizaremos <<extends>> cuando se presenta una variación del comportamiento normal, y <<include>> cuando se repite un comportamiento en dos casos de uso y queremos evitar dicha repetición.