POOA Teoría 1. Introducción

UNIVERSIDAD POLITÉCNICA DE MADRID
ESCUELA UNIVERSITARIA DE INFORMÁTICA

LENGUAJES, PROYECTOS Y SISTEMAS INFORMÁTICOS
Tema 1. INTRODUCCIÓN
PROGRAMACIÓN ORIENTADA A OBJETOS AVANZADA

GRADO EN INGENIERÍA DEL SOFTWARE
© Luis Fernández Muñoz y Adolfo Yela Ruiz

OBJETIVOS
Establecer
el marco de trabajo de la asignatura
sentando las bases de
la orientación a objetos con
el lenguaje JAVA y
la metodología de desarrollo PUD.
Tema 1. INTRODUCCIÓN - 1
ÍNDICE
1. Programación Orientada a Objetos
2. Plataforma de Desarrollo JAVA
3. Método de Desarrollo PUD
4. Dirigido por Casos de Uso
5. Lenguaje de Modelado UML
6. Iterativo e Incremental
7. Centrado en la Arquitectura MVC
8. Patrones de Diseño
1. PROGRAMACIÓN
ORIENTADA A OBJETOS
BASES DE LA PROGRAMACIÓN (I):
• Abstracción: proceso mental de extracción de las
características esenciales de algo, ignorando los detalles
superfluos
• Encapsulación: proceso por el que se ocultan los detalles del
soporte de las características de una abstracción
• Modularización: proceso de descomposición de un sistema en un
conjunto de módulos (‘piezas’) poco acoplados (independientes) y
cohesivos (con significado propio)
1. PROGRAMACIÓN
ORIENTADA A OBJETOS
BASES DE LA PROGRAMACIÓN (II):
• Jerarquización: proceso de estructuración por el que se produce
una organización (jerarquía) de un conjunto de elementos en grados
o niveles de responsabilidad, de incumbencia o de composición,
entre otros. Jerarquía de composición
Jerarquía de clasificación
1. PROGRAMACIÓN
ORIENTADA A OBJETOS
EVOLUCIÓN DE LOS LENGUAJES DE PROGRAMACIÓN (I):
BASES CÓDIGO ENSAMBLADOR PROGRAMACIÓN
MÁQUINA DE ALTO NIVEL
Abstracción {0,1} Identificadores Subprogramas
Encapsulación Nula Nula Reglas de Ámbito
Modularización Nula Macros Subprogramas
Jerarquización Nula Nula Expresiones,
Registros y
Subprogramas
1. PROGRAMACIÓN
ORIENTADA A OBJETOS
EVOLUCIÓN DE LOS LENGUAJES DE PROGRAMACIÓN (II):
BASES PROGRAMACIÓN PROGRAMACIÓN MODULAR
ESTRUCTURADA
Abstracción Estructuras de Espacios de nombres
Encapsulación Control de Flujo Privacidad en Módulos
de Ejecución
Modularización Módulos
Jerarquización Jerarquías de dependencia
cliente/servidor entre los
módulos
1. PROGRAMACIÓN
ORIENTADA A OBJETOS
EVOLUCIÓN DE LOS LENGUAJES DE PROGRAMACIÓN (II):
BASES TIPOS ABSTRACTOS PROGRAMACIÓN
DE DATOS ORIENTADA A OBJETOS
Abstracción Vista Pública Herencia y Polimorfismo
Encapsulación Vista Privada =
Modularización TAD’s Clases
Jerarquización Jerarquías de composición Jerarquías de clasificación
y dependencia
OO = TAD’s + Herencia
1. PROGRAMACIÓN
ORIENTADA A OBJETOS
ELEMENTOS DE LA POO (I):
Clase: descripción de los datos y de las operaciones que
describen el comportamiento de un cierto conjunto de
elementos homogéneos.
Ej. Clase Intervalo
- datos: extremos inferior y superior;
- operaciones: intersección, longitud, desplazar, …
Objeto: ejemplar concreto (instancia) de una clase, que responde
al comportamiento definido por las operaciones de la clase a la
que pertenece, adecuándose al estado de sus datos particulares.
Ej. Objetos de la clase Intervalo :
- constantes: (8,10), (-100,100),…
- variables: misHorasDeTrabajo, miPresiónArterial, …
1. PROGRAMACIÓN
ORIENTADA A OBJETOS
ELEMENTOS DE LA POO (II):
Mensaje: invocación de una operación sobre un objeto. Un
objeto es el agente activo que lanza el mensaje y otro objeto es
el agente pasivo que recibe el mensaje. El objeto receptor del
mensaje debe contemplar dicha operación entre las definidas en
su clase.
Ej. Mensajes a objetos de la Clase Intervalo
- (8,10).longitud = 2; (-100,100).desplazar(3) => (-97,103),…
- misHorasDeTrabajo.interseccion(tusHorasDeTrabajo), …
Método: definición de una operación de una clase.
Ej. Métodos de la Clase Intervalo
- longitud: extremo superior menos extremo inferior;
- desplazar: acumular cantidad a ambos extremos;
1. PROGRAMACIÓN
ORIENTADA A OBJETOS
ELEMENTOS DE LA POO (III):
Atributo: cada uno de los datos de una clase, y por tanto,
presente en todos los objetos de esa clase.
Ej. Atributos de la clase Intervalo
- extremos inferior y superior
Estado: conjunto de los valores de los atributos que tiene un
objeto, por pertenecer a una clase, en un instante dado.
Ej. Estados de objetos de la clase Intervalo
- 8 en el extremo inferior y 14 en el extremo superior de
presiónArterial;
- 9 en el extremo inferior y 18 en el extremo superior de
misHorasDeTrabajo;
1. PROGRAMACIÓN
ORIENTADA A OBJETOS
ELEMENTOS DE LA POO (IV):
Herencia: transmisión de atributos y métodos de una clase a otra
clase.
Ej. A partir de la Clase Intervalo
- IntervaloCerradoCerrado [x,x], IntervaloAbiertoCerrado
(x,x],…
Polimorfismo: enlace dinámico de expresiones a clases y/o de
mensajes a métodos.
Ej. Objetos intercambiables de las clases Intervalo,
IntervaloCerradoCerrado, …
1. PROGRAMACIÓN
ORIENTADA A OBJETOS
RELACIÓN DE LOS ELEMENTOS DE LA POO:
Una clase es la definición de los atributos y métodos que
describen el comportamiento de un cierto conjunto de objetos
homogéneos.
Un objeto es un ejemplar concreto de una clase que responde a
los mensajes correspondientes a los métodos de ésta,
adecuándose al estado de sus atributos.
La clase hija hereda los atributos y métodos de la clase padre y
se especializa añadiendo y/o redefiniendo atributos y métodos.
En el polimorfismo, el objeto activo sólo necesita conocer qué
mensajes puede aceptar el objeto pasivo, no qué clase de objeto
cree que es y, por tanto, qué método ejecuta en cada instante.
1. PROGRAMACIÓN
ORIENTADA A OBJETOS
COMPARATIVA DE LA POO vs PROGRAMACIÓN ESTRUCTURADA:
PROGRAMACIÓN BASES DE LA POO
ESTRUCTURADA PROGRAMACIÓN
Registro + Funciones Abstracción, Encapsulación Clase
y Modularidad
Variable de Tipo Registro Abstracción, Encapsulación Objeto
Función Modularidad Método
Llamada a Función Abstracción Mensaje
Campo de un Registro Encapsulación Atributo
y Modularidad
Estado de una Variable Registro Encapsulación Estado
Registros de Campos Variables Abstracción y Modularidad Herencia
Punteros a Funciones Abstracción y Encapsulación Polimorfismo
1. PROGRAMACIÓN
ORIENTADA A OBJETOS
SÍNTESIS DE LA POO:
“En vez de un procesador de celdas de memoria…
tenemos un universo de objetos de buen comportamiento
que cortésmente solicitan entre sí llevar a cabo diversos
deseos” [Ingalls. Byte,1981]
La Programación Orientada a Objetos es
un nuevo equilibrio entre procesos y datos
que aporta un enfoque antropomórfico
próximo al pensamiento humano
1. PROGRAMACIÓN
ORIENTADA A OBJETOS
OBJETIVO DE LA POO (I):
Premisas: (Leyes de Lehman y Belady)
• Ley del Cambio Continuo: Un programa que se usa en un
ámbito del mundo real, necesariamente debe cambiar o
convertirse cada vez en menos útil
• Ley de la Complejidad Creciente: Debido a que los programas
cambian por evolución, su estructura se convierte en más
compleja a menos que se hagan esfuerzos activos para
evitar este fenómeno
1. PROGRAMACIÓN
ORIENTADA A OBJETOS
OBJETIVO DE LA POO (II):
Implicaciones:
• El incremento de abstracción, encapsulación, modularidad y
jerarquización aumentan la compresión, la escalabilidad y la
flexibilidad del software
• El incremento de la comprensión , la escalabilidad y la
flexibilidad del software reduce los costes del mantenimiento del
software (correctivo, adaptativo y perfectivo)
• La reducción de los costes del mantenimiento del software
reduce drásticamente los costes del desarrollo del software
2. PLATAFORMA DE
DESARROLLO JAVA
COMPUESTO POR:
• lenguaje de programación
• herramientas de desarrollo
JDK (Java Development Kit)
• máquina virtual
JVM (Java Virtual Machine)
• biblioteca estándar (logotipo)
API (Application Programming Interface)
2. PLATAFORMA DE
DESARROLLO JAVA
LENGUAJE:
• imperativo: permite la asignación de valores a variables
• orientado a objetos: permite clases, herencia y polimorfismo
• concurrente: permite la ejecución paralela de varios procesos
P. Lógico
Prolog Parlog Vulcan Prolog++
P. Funcional
LISP Clean Haskell CLOS
P. Imperativo Ada95
Ada Smalltalk Eiffel
Pascal
C
Cobol Occam Objetive-C C++
ObjectPascal
P. Concurrente
P. Orientado a Objetos
2. PLATAFORMA DE
DESARROLLO JAVA
HERRAMIENTAS DE DESARROLLO:
• javac: compila programas Java (*.java)
• java: ejecuta programas Java compilados (*.class)
• javadoc: generación automática de documentación (*.html)
• jar: creación de archivos para distribución (*.jar)
•…
2. PLATAFORMA DE
DESARROLLO JAVA
MÁQUINA VIRTUAL (JVM):
• ficheros compilados (*.class)
no son código nativo (*.exe)
de una plataforma, son
bytecodes (≈ensamblador OO)
• interpreta los bytecodes
• existe una JVM por cada
plataforma
• permite ejecutar el mismo
programa en cualquier
plataforma
2. PLATAFORMA DE
DESARROLLO JAVA
BIBLIOTECA:
• clases básicas del lenguaje (java.lang)
• estructuras de datos y utilidades (java.util),
• acceso a ficheros (java.io),
• interfaces gráficas de usuario (java.awt, javax.swing),
• acceso a redes (java.net) ,
• acceso a bases de datos (java.sql),
•…
2. PLATAFORMA DE
DESARROLLO JAVA
DISTRIBUCIONES:
• Java SE Runtime Environment (JRE): incluye la máquina virtual y
la biblioteca; lo necesario para ejecutar aplicaciones.
• Java SE Development Kit (JDK): incluye al JRE y las herramientas
para desarrollar aplicaciones.
2. PLATAFORMA DE
DESARROLLO JAVA
IMPLANTACIONES:
• SUN: http://java.sun.com/
• IBM: http://www.ibm.com/
•…
• Compiladores a código nativo:
GCJ: http://gcc.gnu.org/java/
• Compiladores de otros lenguajes para la plataforma Java:
Jruby: http://www.jruby.org/
Groovy http://groovy.codehaus.org/
2. PLATAFORMA DE
DESARROLLO JAVA
EDICIONES:
• J2SE (Java2 Platform, Standard Edition): Versión usada en
ordenadores personales
• J2EE (Java 2 Platform, Enterprise Edition): Estándar para el
desarrollo de aplicaciones distribuidas multicapa, basada en
componentes
• J2ME (Java 2 Platform, Micro Edition): Entorno para
desarrollar aplicaciones en dispositivos con recursos limitados
como dispositivos móviles, software empotrado en
electrodomésticos, etc.
2. PLATAFORMA DE
DESARROLLO JAVA
HISTORIA:
Año Plataforma Lenguaje Novedades
1995 JDK 1.02 Primera núcleo inicial
1996 JDK 1.1 edición
1998 JDK 1.2 Segunda clases anidadas, clases anónimas, …
2000 JDK 1.3 edición
2002 JDK 1.4

2004 JDK 1.5 Tercera clases genéricas, enumerados, …
2006 Java SE 6 edición
2011 Java SE 7
Tanto “1.5” como “5.0” se refieren a la misma versión. Al utilizar “5.0” se suele hacer referencia al
producto y “1.5.0” es más usado por los desarrolladores
2. PLATAFORMA DE
DESARROLLO JAVA
CARACTERÍSTICAS POR EL LENGUAJE:
• Orientado a objetos: excepto en los tipos primitivos
• Concurrente: dispone de primitivas de sincronización para
aplicaciones concurrentes
• Fuertemente tipado: toda variable debe declararse con un tipo
y éste no se puede cambiar durante la ejecución
• Sencillo: basado en la sintaxis y semántica de C/C++, pero
eliminando las características complejas y propensas a errores:
aritmética de punteros, herencia múltiple, gestión de la
liberación de memoria, etc.
• De propósito general: no está orientado a un tipo de
aplicaciones particular
2. PLATAFORMA DE
DESARROLLO JAVA
CARACTERÍSTICAS POR LA BIBLIOTECA:
• Dedicada a dominios: dispone de bibliotecas específicas
CARACTERÍSTICAS POR LA MÁQUINA VIRTUAL:
• Neutra frente a la arquitectura: ejecutable (x86, RISC, …)
• Portable: La misma aplicación se puede ejecutar en diferentes
sistemas operativos
• Dinámico: las clases se enlazan a medida que se necesitan sin
necesidad de re-compilar toda la aplicación
• Gestión automática de memoria: no es necesaria la liberación
explícita de memoria
• Robusto: chequeos en tiempo de compilación y de ejecución
3. MÉTODO DE DESARROLLO
PUD
MÉTODO/PROCESO DE DESARROLLO SOFTWARE: conjunto
total de actividades necesarias para transformar los requisitos
de un cliente en un conjunto consistente de artefactos (código
+ documentación) que representan un producto software y
para transformar cambios en dichos requisitos en nuevas
versiones del producto software.
Ej. de Actividades:
• Captura de Requisitos, Análisis de Datos, Diseño de la
Interfaz, Programación de Módulos, Pruebas de Rendimiento,
…
Ej. de Procesos de Desarrollo Software:
• Cascada, Espiral, Top-Down, Bottom-Up, …
3. MÉTODO DE DESARROLLO
PUD
PROCESO DE UNIFICADO DE DESARROLLO (PUD): proceso de
desarrollo software
• orientado a objetos,
• dirigido por casos de uso y riesgos,
• basado en el Lenguaje Unificado de Modelado (UML)
• centrado en la arquitectura,
• iterativo e incremental.
4. DIRIGIDO POR CASOS DE
USO
CASO DE USO: descripción de un conjunto de secuencias de
acciones, incluyendo variaciones, que un sistema lleva a cabo y
que conduce a un resultado observable de interés para un actor
determinado.
ACTOR: un conjunto coherente de roles que los
usuarios/sistemas externos de los casos de uso desempeñan
cuando interaccionan con el sistema.
¿Qué hace el sistema para cada usuario? ≠ funciones
4. DIRIGIDO POR CASOS DE
USO
Ej. Aplicación Web para la matrícula en la EUI:
• Actores:
– Alumno,
– Jefe de estudios,
–…
• Casos de Uso:
– Alumno: incorporar asignatura, generar solicitud, …
– Jefe de Estudios: establecer cupos por grupo, cerrar periodo de
matricula, …
• Funciones:
– Automatiza la solicitud a distancia de matriculas válidas;
– Automatiza el cálculo del coste de las matrículas;
–…
5. LENGUAJE DE MODELADO
UML
LENGUAJE UNIFICADO DE MODELADO: lenguaje gráfico
estándar para visualizar, especificar, documentar y comunicar
sistemas basados en software.
Referencia básica: http://www.uml.org
Tutorial: Plataforma POOA
Resumen: http://www.holub.com/goodies/uml/index.html
Tipos de Diagramas: • Diagramas de Comunicación

• Diagramas de Casos de Uso • Diagramas de Estados
• Diagramas de Clases y Objetos • Diagramas de Actividad
• Diagramas de Secuencia • Diagramas de Despliegue
UML
DIAGRAMAS DE CASOS DE USO:
• 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)
UML
DIAGRAMAS DE CLASES:
• Muestra entidades del mundo real, elementos de análisis y
diseño o clases de implementación y sus relaciones;
• Muestra un ejemplo ilustrativo de objetos y sus enlaces
Pueden ser objetos en memoria, objetos en base de datos,
objetos de modelado…
UML
DIAGRAMAS DE SECUENCIA:
• Muestran como los objetos se intercambian mensajes a
lo largo del tiempo
UML
DIAGRAMAS DE COMUNICACIÓN:
• Muestran los enlaces e interacciones entre los objetos
UML
DIAGRAMAS DE ESTADOS:
• Muestra los estados y las transiciones entre los estados
dependiendo de los eventos que se producen
UML
DIAGRAMAS DE ACTIVIDAD:
• Muestra el flujo de datos o
el flujo de control
UML
DIAGRAMAS DE DESPLIEGUE:
• Muestra las partes físicas del sistema (PCs, ficheros,
directorios, servidores, …) y conectadas por líneas de
comunicaciones
6. ITERATIVO E INCREMENTAL
ITERACION: conjunto de actividades llevadas a cabo de acuerdo

a un plan (de iteración) y unos criterios de evaluación, que lleva
a producir una versión, ya sea interna o externa.
INCREMENTO: parte pequeña y manejable del sistema,
normalmente la diferencia entre dos construcciones sucesivas.
Cada iteración resultará, al menos, en una nueva
construcción, de forma que se añada un incremento al
sistema.
Planificar un poco.
Especificar, diseñar e implementar un poco.
Integrar, probar y ejecutar un poco en cada iteración.
Proyecto Tres en Raya. Una única iteración.
Tema 1. Introducción
Tema 2. Programación Estructurada
Proyecto Agenda. 1ª Iteración:
Tema 3. Programación Basada en Objetos.
Tema 4. Programación Orientada a Objetos.
Tema 5. Programación Modular.
Tema 6. Programación con Excepciones
Tema 7. Programación Parametrizada
Estructuras de Datos de la Biblioteca!!!

Tema 8. Programación con Eventos
Tema 9. Programación Concurrente
Ejecución Multihilo!!!

Tema 10. Programación con Redes
Tema 11. Programación con BBDD
Tema 12. Programación en Web
Tema 13. Programación de Sistemas Inteligentes
7. CENTRADO EN LA
ARQUITECTURA MVC
ARQUITECTURA: conjunto de decisiones significativas acerca
de la organización de un sistema software, la selección de los
elementos estructurales a partir de los cuales se compone el
sistema, y las interfaces entre ellos, junto con su
comportamiento, tal y como se especifica en las
colaboraciones entre esos elementos, la composición de estos
elementos estructurales y de comportamiento en subsistemas
progresivamente mayores, y el estilo arquitectónico que guía
esta organización.
sin Arquitectura = “parábola del ciego y el elefante”

(una ducha, 4 columnas, un cabo roto, …)
7. CENTRADO EN LA
ARQUITECTURA MVC
Modelo/Vista/Controlador es un estilo de arquitectura de
software que separa los datos de una aplicación, la interfaz
de usuario, y la lógica de negocio en tres componentes
distintos:
• Modelo: es el objeto que representa los datos del
programa, maneja los datos y controla todas sus
transformaciones.
• Vista: es el objeto que maneja la presentación visual de
los datos representados por el Modelo.
• Controlador: es el objeto que proporciona significado a las
ordenes del usuario, actuando sobre los datos
representados por el Modelo y dirigiendo la Vista.
7. CENTRADO EN LA
ARQUITECTURA MVC
El Modelo no tiene conocimiento
específico de los Controladores ni de
las Vistas, ni siquiera contiene
referencias a ellos.
La Vista interactúa con el Modelo a
través de una referencia para solicitar
la información a mostrar.
El Controlador interactúa con el
Modelo y con la Vista acorde a la
secuencia de acciones de un caso de
uso.
7. CENTRADO EN LA
ARQUITECTURA MVC
Ej. En un taller mecánico (de más de 10 personas):
• los modelos son los mecánicos, no interactúan con el los
clientes ni toman decisiones al margen de la reparación
particular sobre un coche;
• las vistas son los recepcionistas ofrecen información a los
clientes que eventualmente solicitan a los mecánicos;
• los controladores son los directores que establece las
políticas de trabajo de la organización: determinan quién es
el recepcionista adecuado para cada cliente, qué información
debe suministrar, quién es el mecánico que debe reparar cada
coche, …
7. CENTRADO EN LA
ARQUITECTURA MVC
JERARQUÍA EN MVC
• un controlador puede delegar
tareas en otros controladores;
• un controlador puede
controlar varios modelos y
vistas;
• una vista puede estar
compuesta de varias vistas;
• una vista puede no estar
asociada a ningún modelo;
• un modelo puede estar
compuesto por varios modelos;
7. CENTRADO EN LA
ARQUITECTURA MVC
Ej. En un taller mecánico (de más de 100 personas):
• los modelos son grupos de mecánicos organizados
jerárquicamente: equipo de mecánica, equipo de chapa, …;
• las vistas son grupos de recepcionistas: equipo comercial,
equipo administrativo, …;
• los controladores son grupos de directores: director general,
director comercial, director financiero, …
8. PATRONES DE DISEÑO
DEFINICIÓN: es una solución a un problema de diseño que ha
demostrado su efectividad resolviendo problemas similares
de forma recurrente y que, por tanto, es reusable en
diferentes problemas de diseño en distintas circunstancias.
Ejemplos:
• Tema 2: Singleton y Facade;
• Tema 4. Composite , Facade, Prototype, Observer y Visitor
• Tema 7: Iterator;
• Tema 10: Proxy;
• Tema 11: Abstract Factory
http://es.wikipedia.org/wiki/Patr%C3%B3n_de_dise%C3%B1o
8. PATRONES DE DISEÑO
DESCRIPCIÓN DE UN PATRÓN DE DISEÑO:
• Nombre del patrón: nombre estándar del patrón por el cual
será reconocido en la comunidad.
• Motivación: Escenario de ejemplo para la aplicación del
patrón.
• Objetivo: ¿Qué problema pretende resolver el patrón?
• Estructura: Diagramas de clases oportunos para describir las
clases que intervienen en el patrón.
• Participantes: Enumeración y descripción de las entidades
que participan en el patrón.
• Colaboraciones: Explicación de las interrelaciones que se
dan entre los participantes.
•…

POOA Teoría 1. Introducción

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

POOA Teoría 1. Introducción

Uploaded by

Copyright:

Available Formats

UNIVERSIDAD POLITÉCNICA DE MADRID

ESCUELA UNIVERSITARIA DE INFORMÁTICA

PROGRAMACIÓN ORIENTADA A OBJETOS AVANZADA

© Luis Fernández Muñoz y Adolfo Yela Ruiz

API (Application Programming Interface)

2002 JDK 1.4

¿Qué hace el sistema para cada usuario? ≠ funciones

Tipos de Diagramas: • Diagramas de Comunicación

ITERACION: conjunto de actividades llevadas a cabo de acuerdo

Estructuras de Datos de la Biblioteca!!!

Proyecto Agenda. 6ª Iteración:

Proyecto Agenda. 8ª Iteración:

sin Arquitectura = “parábola del ciego y el elefante”

You might also like