Objetivos

 Aprender a “pensar” Orientado a Objetos (OO).

 Procesos, Métodos, Modelos, Herramientas

 Los Fundamentos del Paradigma OO

 Herramienta de Programación para expresar

ese pensamiento.

Complejidad del Software

“La construcción de software siempre será una tarea difícil. No hay bala de plata”
(F. Brooks, 1987)

 La complejidad es una característica

esencial de todos los sistemas de software

– Los requerimientos están sujetos a continuos cambios

– Complejidad del dominio del problema

– Dificultad de administrar el proceso de desarrollo

1

– Flexibilidad que posibilita la creación de software

Formas de Manejar la Complejidad
Descomposición “Divide et Impera”

Al menos dos alternativas para encararla:

– Descomposición Algorítmica o Funcional

• “top-down”, ...

– Descomposición Orientada a Objetos

• Entes autónomos que colaboran para realizar una tarea más
o menos compleja...

Evolución de los Paradigmas

 Generaciones Previas Topología de los finales de la

3era generación -PASCAL

DATOS

Función 1 Función 2
Función 3 Función 4
Formas de Manejar la Complejidad

Focalizarse sobre el comportamiento observable

de un objeto (vista exterior del mismo).

Así sirve para separar el comportamiento

esencial del objeto de su implementación.

Formas de Manejar la Complejidad

Jerarquías

Clasificando los objetos en GRUPOS de

abstracciones relacionadas, se logra
distinguir lo que es común, y a su vez, lo
distinto entre ellos, lo que nos ayuda a
manejar la complejidad 3
Conclusiones sobre Complejidad

 “Crisis del Software” = DEMASIADOS

FRACASOS
– Complejidad del dominio del problema
– Dificultad de gestionar el proceso de desarrollo
– Requerimientos cambiantes
 Estrategias para manejar la complejidad:
– Descomposición
– Abstracción
– Jerarquías

Inconvenientes de la
Descomposición Funcional
 Un sistema difícilmente se puede caracterizar
por una sola función (ej. comportamiento colaborativo)
 Las funciones tienden a ser la parte más
volátil de los requerimientos
 El método ataca directamente el “cómo”, sin 4

detenerse en el “qué”
 No promueve la extensibilidad, reusabilidad
La propuesta OO:
 Usar abstracciones como CONCEPTOS
(objetos) y no funciones como base para
descomponer los sistemas. Con ello logramos
incrementos sustanciales de :

– Cercanía
• Entre “el problema” y “la solución”
– Extensibilidad, Reusabilidad
• Por basar estructura en conceptos
– Mantenibilidad
• Por tener una arquitectura más sólida y robusta frente a
cambios de requerimientos

¿OO es el final de la crisis?

 La OO es una estrategia de desarrollo de
software que permite mejorar mucho
nuestras posibilidades de hacer frente a la
crisis....

... MEJOR QUE LAS GENERACIONES PREVIAS:

5
Principio del Objeto/Clase

Cápsula Cápsula
(Encapsulamiento):
Barrera alrededor de las
Interface funciones y datos que ayuda
OPERACIONES al proceso de Abstracción
Y DATOS
ENCAPSULADAS Interface:
DEL OBJETO Ventana que deja ver sólo la
parte pública de la clase

Ejemplo: Clase que define “cuentas bancarias”

Estado Interface
NombreCliente:String
Codigo:String
Saldo:Entero depósito() {...}
UltimaOper: Lista verSaldo() {...}
extracción() {...}
Operaciones
depósito() { ...}
extracción() { ...}
verSaldo() { ...}
calculaInteres() { ...}

NO SI 6

Un objeto incluye una estructura de datos junto con un

conjunto de operaciones para manipularla.
Orientación a Objetos...

 Hacer un programa Orientado a Objetos

significa estructurarlo en base a los
conceptos (clases) que maneja y no a
las funciones

Características Básicas de la OO

 Todo es un objeto
– Mantiene estado (atributo/datos)
– Ejecuta operaciones (métodos)

 Un programa es un conjunto de objetos

colaborativos que interoperan mediante el
envío de mensajes
7

 Cada objeto creado a partir de una clase

posee su propio estado
Características Básicas de la OO
 Todo objeto es de una clase (tipo)
determinada
– Todo objeto es una instancia de una clase

 Todos los objetos de una clase o jerarquía de

clases pueden recibir los mismos mensajes
– Polimorfismo:
Ejemplo (Figura, Cuadrado, Segmento)

Ejemplo Figura: Clases, Atributos,

Operaciones, Jerarquía de Herencia
Figura
origen
color
dibujar() Atributos
mover()
.....
origen
color
Figura Abierta Figura Cerrada
área
....
rellenar()
......
Operaciones
dibujar()
Segmento
Polígono Elipse
radio borrar()
8
mover()
Círculo
Triángulo Rectángulo rotar()
....
Cuadrado
Ciclo de vida
 Sucesión de etapas (procesos) por las que
atraviesa un producto software a lo largo de
su existencia
– esto es, durante su desarrollo y explotación.

 Modelos de proceso/Modelos de ciclo de vida

 Evolución de los Modelos de Proceso

– cascada (Royce)
– espiral (Bohem)
– incremental, otros

Modelo de proceso Clásico

PLANIFICACION

Errores de
análisis
ANALISIS Y
ESPECIFICACION
INFORMAL
ESPECIFICACION DE
REQUERIMIENTOS
VALIDADA Errores de
diseño
DISEÑO
DISEÑO
VALIDADO
Errores de
codificación 9
IMPLEMENTACION
CODIGO
VALIDADO
(Producto liberado)
A todas las
MANTENIMIENTO fases
Modelo en cascada. Fases
Análisis del sistema.
 ¿Qué debe hacer el sistema?
 El software suele formar parte de un sistema
mayor:
– Identificar los requisitos de todos los elementos
del sistema (Sw, Hw).
– Asignar un subconjunto de dichos requisitos al
software.

Modelo en cascada. Fases

Análisis de los requisitos del software.
 El proceso de recopilación de los requisitos
se centra especialmente en el software.
 Hay que especificar requisitos funcionales y
no-funcionales:
– funciones que el software debe realizar
– la información que el software va a gestionar 10
– condicionantes existentes: rendimiento,
confiabilidad, usabilidad, etc.
Modelo en cascada. Fases
Análisis de los requisitos del software.
 Los requisitos del software se documentan y
se revisan con el cliente.

 Se genera la especificación de requisitos

del software
– (SRS, Software Requirements Specification p.ej., Estándar
IEEE 830-1993).

Modelo en cascada. Fases

Diseño.
 ¿Cómo se ha de construir el sistema?
 Definir estructura del software para satisfacer
los requisitos con la calidad necesaria:
– Estructura de los datos
– Arquitectura del software
– Representaciones de interface
– Determinar los algoritmos 11
Modelo en cascada. Fases
Generación de código
 Implementación.
 Se podría realizar de forma automática a
partir de un diseño detallado (herramienta
CASE).

Prueba.
 ¿Se ha construido el sistema que se
deseaba?
– Prueba interna.
– Prueba externa.

Modelo en cascada. Fases

Mantenimiento.

 El software sufrirá cambios después de que

se entregue al cliente
– (errores, nuevas funciones, aumentos del
rendimiento, etc.)
 Volver a aplicar cada una de las fases
anteriores al programa existente.
12
Modelo clásico
 Críticas al modelo ideal

– Los proyectos reales raramente pueden seguir el

flujo secuencial que se propone.

– Dificultad para establecer todos los requisitos al

principio del proceso.

– El mantenimiento recae sobre el código.

Modelo clásico

 Críticas al modelo ideal

– “El usuario debe tener paciencia”.

– Se tarda mucho tiempo en pasar por todo el ciclo

(hasta que no termina una fase no empieza la 13
siguiente)

Retrasos innecesarios
 Modelo clásico

 Ventajas:

– “Es mejor que nada” (prácticas ad-hoc).

– Proporciona un marco para aplicar métodos,
técnicas y herramientas.
– Es “sencillo” controlar el desarrollo del proyecto.

Modelo en espiral (Boehm 88)

Planificación Análisis de riesgo Análisis de riesgo

Recolección de basado en los
requisitos. Planifica- requisitos iniciales
ción del proyecto
inicial Análisis de riesgo
basado en la reacción
Planificación basada del cliente
en los comentarios
del cliente Prototipo inicial
del software

Evaluación del Prototipos de

cliente siguiente nivel
14
Evaluación del cliente Ingeniería Hacia el final del
sistema

• Más realista que el ciclo de vida clásico

• Relativamente poco probado
 Ciclo de vida OO
Identificar clases
Planificación Análisis de riesgo candidatas

Construir Buscar clases

n-ésima iteración en biblioteca
del sistema

Extraer nuevas
Añadir las nuevas
clases si existen
clases a la
Evaluación del cliente Ingeniería
biblioteca

Desarrollar
las clases
si no existen

Análisis OO
Diseño OO
Programación OO
Pruebas OO
• Hincapié en la reutilización
• Notación uniforme en todas las fases de desarrollo.

Ciclo de vida OO
Booch 94 (Macroproceso)
Establecer requisitos Desarrollar un modelo del
básicos comportamiento deseado
Prototipo
(conceptualización) desechable (análisis)

Crear una arquitectura

(diseño)
15
Gestionar la
evolución tras la
Desplegar la implementación
entrega
(evolución)
(mantenimiento)
 Ciclo de vida OO
Booch 94 (Microproceso)
Identificar clases y
objetos

Especificar Identificar la
interfaces e semántica de clases y
implementación de objetos
clases y objetos

Identificar relaciones entre

clases y objetos

Modelos ¿Por qué modelar?

Modelo: “Un modelo es una simplificación de la
realidad”

 Construimos modelos para comprender mejor

el sistema que estamos modelando
 Cuatro utilidades de los modelos:
– Visualizar cómo es o queremos que sea el sistema
– Especificar la estructura y comportamiento del 16
sistema
– Proporcionan plantillas que guían la construcción
del sistema
– Documentan las decisiones
Utilidad del modelado

 Por ejemplo: ¿Escribimos código

directamente?

 Se facilita la comunicación entre el equipo al

existir un lenguaje común (ejemplo UML).
 Se dispone de documentación que trasciende al
proyecto.
 Hay estructuras que trascienden lo
representable en un lenguaje de programación.

Utilidad de UML (Unified

Modeling Language)

 Permite especificar todas las decisiones de

análisis, diseño e implementación,
construyéndose modelos precisos, no
ambiguos y completos.
 UML puede conectarse a lenguajes de
programación:
– Ingeniería directa e inversa 17

 Permite documentar todos los productos de

un proceso de desarrollo (requisitos, análisis,
arquitectura, distribución física,...)
UML y el modelado

UML es un lenguaje para visualizar, especificar,

construir y documentar los productos de un sistema
que involucra una gran cantidad de software, desde
una perspectiva OO.

 UML es una notación, no es un proceso

Ejemplo de Clase en UML

Cuenta
codigo
saldo
nombreCliente
UltimoCodigo

depósito()
extracción()
ultimasOperaciones()
verSaldo()
18
Ejemplo de Diagrama de Clases

Pedido
info Cliente
pagoAdelantado? : Boolean
nombre
numero : String
direccion
precio : Dinero
* 1..1
tipo:String()
entregar()
cerrar()
1..1
Empresa Personal
Nombre tarjetaCredito
if Pedido.cliente.tipo="Pobre"
tipo
then Pedido.pagoAdelantado?
creditoLimite
= true

+linea items facturar()

* avisar()
LineaPedido * { tipo()="pobre"}
cantidad : Integer
precio : Dinero 0..1
esSatisfecho : Boolean +repr ventas

Empleado
*
1..1 Producto

● Pilares de la OO:
– Abstracción
• Clases y Objetos
• Atributos, Métodos, y Mensajes
– Herencia
– Polimorfismo
– Encapsulamiento y Ocultamiento de 19

Información

38
Abstracción (Figura tomada de Booch 94)

Se enfoca en las características esenciales de algún

objeto, relativo a la perspectiva del observador.
39

Abstracción

Objeto Real

Una cuestión importante que se debe tener en cuenta al 20

momento de modelizar es el de decidir sobre el conjunto de
abstracciones claves del espacio del problema.

40
Abstracción

Objetos Bicicletas Clase Bicicleta

Atributos
cuadro
rueda
Abstracción velocidades
color
Operaciones
frenar()
acelerar()
girar()

41

Abstracción
● Una abstracción denota los elementos
principales de un objeto que lo distingue de
los otros tipos de objetos y así provee límites
conceptuales bien definidos, relativo a la
perspectiva de un observador

• Se enfoca en la parte visible del objeto

• Captura el comportamiento total del objeto 21

42
 Abstracción Fundamental en OO

Clase Comportamiento y Atributos (TAD)

Ej. Diagrama de Clases:

Modelo OO Colección estructurada de clases

Programa Ej. Un programa en ejecución:

OO Colección cooperativa de objetos
o instancias de clases
43

Clases

● Una clase describe objetos que van a tener la

misma estructura de datos (atributos) y el
mismo comportamiento (operaciones).
● Las clases son entidades sintácticas y
semánticas.
22

● Una clase puede ser vista como una

abstracción y módulo primitivo, y como un tipo
de datos 44
Doble naturaleza de las clases
Una clase es un módulo y un tipo de dato:
● Módulo (concepto sintáctico)
– Mecanismo para organizar el software
– Encapsula componentes software

● Tipo (concepto semántico)

– Mecanismo de definición de nuevos tipos de datos:
describe una estructura de datos (objetos) para
representar valores de un dominio y las operaciones
aplicables.
45

Componentes de un clase
● Atributos
– Representan las variables (y constantes) que
determinarán el estado interno para cada objeto de
una clase
● Operaciones (Métodos)
– Representan el comportamiento, las posibles
acciones u operaciones aplicables a cada objeto de
una clase
– Único modo de acceder a los atributos 23
Ejemplo: Al modelar un banco, encontramos objetos Cuenta. Todos
los objetos Cuenta tienen atributos comunes:
• atributos: saldo, titular, ...
• operaciones: extracción, depósito, …
46
Ejemplo: Definiendo la Clase Cuenta
Estado Interface
NombreCliente:String
Codigo:String
Saldo:Entero depósito() {...}
UltimaOper: Lista verSaldo() {...}
extracción() {...}
Operaciones
depósito() { ...}
extracción() { ...}
verSaldo() { ...}
calculaInteres() { ...}

NO SI

Una clase incluye atributos junto con un conjunto de

47
operaciones para manipularla.

Ejemplo de Clase en UML

Cuenta
codigo
saldo
nombreCliente
ultimoCodigo

depósito()
extracción(
ultimasOperaciones()
)
verSaldo()
24

48
 DECLARACIÓN DE UNA CLASE

La primera palabra que aparece es lógicamente class que sirve para declarar una
clase. Su uso es parecido a la ya conocida struct:
class <identificador de clase> [<:lista de clases
base>]
{
<lista de miembros>
} [<lista de objetos>];
La lista de clases base se usa para derivar clases, de momento no le prestes
demasiada
atención, ya que por ahora sólo declararemos clases base.
La lista de miembros será en general una lista de funciones y datos.

25
 Ejemplo de Clase en C++
class Circulo{

private: // Variables y funciones de la clase de ámbito privado

float rad;

public: // Variables y funciones de la clase de ámbito público

Circulo(); // Constructor por defecto
Circulo(float); // Constructor sobrecargado

radio(float r); // Función para establecer el radio del círculo

diametro(float d);// Función para establecer el diámetro del círculo
float area(); // Cálculo del área del círculo
float perimetro(); // Cálculo del perímetro del círculo

};
51

// Cálculo del perímetro del círculo float CCirculo::perimetro(){ return 2*Pi*(*rad); }

Ejemplo de Clase en C++

#define Pi 3.14159265

// Constructor por defecto

Circulo::Circulo (){
rad = 0; // Cálculo del área del círculo
} float Circulo::area(){
return Pi*(*rad)*(*rad);
// Constructor sobrecargado }
Circulo::Circulo(float r){
rad = r; // Cálculo del perímetro del círculo
} float CCirculo::perimetro(){
return 2*Pi*(*rad);
// Establecer el radio del círculo }
Circulo::radio(float r){
26
rad = r;
}

// Establecer el diámetro del círculo

Circulo::diametro(float d){
rad = d/2; 52
}
 Ejemplo de Clase en C++

53

Características de la POO
Encapsulamiento

 Los datos y los métodos se encapsulan en

una única entidad denominada Objeto .

Ocultación de datos

27
 Los datos están ocultos y sólo a través de
los métodos es posible acceder a ellos.
Encapsulamiento
 Ocultar los detalles de la implementación,
el interior de la clase está oculto, sólo se
pueden ver la interfases externas por los
otros objetos.
 Permite modificar la implementación,
siempre y cuando mantenga la interfaz.
 La clase define la estructura y el
comportamiento (datos + código)
 Cada miembro de la clase puede ser
privado o público. La interfaz pública
representa lo que los usuarios de la clase
pueden acceder.

Especificadores de Acceso

 Se debe a la característica de ocultación

de datos.
 Indican el nivel de acceso a los miembros
de la clase.

28
Especificadores de Acceso

Private
 Un miembro declarado private puede ser
utilizado solamente por los métodos
miembro de su propia clase, pero no
puede ser utilizado por funciones externas
o de una clase derivada aunque esta haya
heredado dichos miembros.
Public
 Un miembro declarado public es accesible
por cualquier objeto de la clase desde
cualquier parte del programa donde exista
dicho objeto.

Mensajes y Métodos
 Cuando alguien llama al método X de un
objeto se dice que le está pasando el
mensaje X.
 No sólo el programador llama a los
métodos (pasa mensajes) de los objetos.
También el sistema puede ejecutar
algunos métodos. Por ejemplo, cuando el
usuario mueve el ratón el sistema llamará
29
a algún método determinado (ya lo
veremos) con ciertos parámetros (por
ejemplo, coordenadas) para indicar que el
ratón ha sido movido.
Tarea
 Describir el escenario, identificar los
objetos con sus datos y métodos en las
transacciones:
 Pago de cheque.
 Apertura de cuenta.
 Solicitud de Crédito.
 Apertura de Póliza.

Herencia

 Proceso mediante el cual un objeto

adquiere las propiedades de otro
objeto.
 Ej pastor aleman, es un perro, que
además es un mamifero, que es un
animal, etc
 Sólo se necesita definir las cualidades
que lo hacen único dentro de la clase 30

 En objeto puede ser una instancia más

específica de un caso más general.
 Las subclases heredan todos los
atributos y métodos de la superclase,
clase padre, ascendente.
Herencia (cont)
 Todas las clases que se definen en Java
heredan de otra existente explicita o
implícitamente. La superclase es Object
 En java no está implementada la herencia
múltiple, que permite heredar de más de
un padre, se reemplaza con interfases.

Polimorfismo

 Permite que una interfaz sea utilizada

como una clase de acción general. La
acción específica se determina de
acuerdo a la situación.
 Permite enviar el mismo mensaje a
objetos de diferente clase, cada uno de
ellos responde a ese mismo mensaje de
forma diferente, de acuerdo a como ha 31
sido implementado.
 Anulación (overriding) un método se
define en una clase y en las clases
derivadas, las instancias van a
responder distinta
Polimorfismo (cont)
 Sobrecarga: métodos con el mismo
nombre empleado sobre tipo de datos
distintos
 En Java sólo el operador + con cadenas de
caracteres y otros datos primitivos (int,
double).
 Cuando una clase tiene múltiples métodos
de igual nombre y distinta signatura
(nombre, tipo y nro de argumentos)

Objetos

● Es una instancia de una clase

● Es un ente formado por tantos campos como
atributos tiene la clase.
● El estado de un objeto viene dado por el
valor de los atributos. (ver variable de clase)
● Los métodos u operaciones permiten 32
consultar y modificar el estado del objeto.
● Durante la ejecución de un programa OO se
crearán objetos. 64
 Objetos
Clases Objetos

Auto

instancias

Avión

65

Objetos dominio vs. Objetos aplicación

Cuenta Persona
empleado cuentaAhorro
CuentaCorriente CuentaAhorro Empleado Cliente

cuentaCorriente cliente

Sistema Software (Clases)

Objetos del Dominio del Problema

:empleado :cuentaAhorro
33

:cuentaCorriente :cliente

Instancias de clases (Objetos Aplicación)

Cada objeto es instancia directa de una clase
66
Clases, objetos, métodos y
atributos
Clase
Atributos Estado

métodos()
Acciones

Objeto Point

setXY 1
x
Mensajes getX
2
getY y

Interface Implementación
privada 67

Tipos de Datos / Variables

● Primitivos vs. Clases
– En C++:
• int, char (ej. int var_primitiva)
• Integer, Character (ej. Integer var_no_primitiva)
• Color

● Variables de Instancia
34
– Cada objeto de una clase tiene su copia.

68
 Métodos
Están compuestos por:
– Signatura: Nombre, Parámetros y Tipo
– Cuerpo: Bloque de instrucciones

Ejemplo (C++):

// Cálculo del área del círculo

float Circulo::area(){
return Pi*(*rad)*(*rad);
}

69

Métodos : Bloque de Instrucciones

● ¿Qué tipo de instrucciones podemos
incluir en el cuerpo de un método?
– Asignación
– Condicionales
– de Iteración
– Invocación a otro método = Mensajes
– Creación de objetos
35
● Un método se ejecutará como respuesta
a un mensaje.

70
Objetos y mensajes

Objeto :punto
Objeto :circulo

setXY 10
......
......
point.setXY(1, x
point.setXY(1, 2)
2) getX
......
...... 20
getY y

Interface Implementación
privada
Mensaje

71

Mensajes
● Mecanismo básico de computación OO.
● Mecanismo básico de invocación de un
método de un objeto.
● La modificación o consulta del estado de un
objeto se realiza mediante mensajes.
● Formado por tres partes:
36
– Objeto receptor
– Selector e identificador (Nombre) del método a
aplicar
– Argumentos 72
 Sintaxis de los mensajes

Eiffel Java C++

Sintaxis receptor.nombre(listArg) Receptor.nombre(listArg)

73

Mensajes vs. Funciones

● Un mensaje se asemeja a una llamada a
función en la que sólo cambia el formato:

unaCuenta.deposito (100000)
deposito(unaCuenta,100000)

37
● En un mensaje se tiene el mecanismo especial
de: “objeto receptor”

74
Modelo de ejecución
● Para obtener un código ejecutable se deben
ensamblar las clases para formar sistemas.
● Un sistema viene dado por:
– Un conjunto de clases
– La clase raíz (en donde se inicia la ejecución)
– El procedimiento de creación de la clase raíz.

● La ejecución de un programa OO consiste en:

– Creación dinámica de objetos
– Envío de mensajes entre los objetos creados

75

Modelo de ejecución
● ¿Cómo empieza la ejecución de un programa OO?
– Creación de un “objeto raíz”
– Aplicar mensaje sobre “objeto raíz”

● En tiempo de ejecución, el flujo de ejecución implica

una operación sobre un objeto (mensaje) o una
operación que no es un mensaje (asignación, etc.).

● En un instante dado o bien se aplica un mensaje sobre la

38
instancia actual o sobre un objeto accesible desde él.

● ¿Cómo se ejecuta un mensaje? Ej: c.deposito(cantidad)

76
 Herencia (Figura tomada de Booch 94)

Una subclase puede heredar la estructura y

comportamiento de su superclase
77

Herencia (Figura tomada de Booch 94)

• Las abstracciones clasificadas
pueden conformar jerarquías.
• La jerarquía es una clasificación
u ordenación de abstracciones.
Ej. :
• Generalización/especialización
• Todo/parte
• Los objetos o clases pueden
heredar atributos y
comportamiento de otras clases.
39
• Superclase, y subclase o clase
derivada
Herencia simple y múltiple
78
 Herencia: Introducción
● Entre algunas clases pueden existir relaciones
conceptuales, por ej.:
Generalización, Especialización, Combinación, ...

“Libros y Revistas tienen propiedades comunes”

“Un rectángulo es una especialización de polígono”
“Una ventana de texto es un rectángulo dónde se manipula texto”

¿Tiene sentido crear una clase a partir de otra?

soporte para utilizar estas relaciones

Herencia
posibilita la definición de una clase a partir de otra
79

Herencia: Introducción
La herencia organiza las clases en una estructura jerárquica:
Jerarquías de clases
Ejemplos:

Publicación

Libro Revista

Libro_Texto Investigación Deportiva

40

• No es tan solo un mecanismo para compartir código.

• Consistente con el sistema de tipos del lenguaje
80
Herencia: Introducción
La herencia organiza las clases en una estructura jerárquica:

81

Herencia: Introducción
A Si B hereda de A entonces B incorpora la estructura
(atributos) y comportamiento (métodos) de la clase A, pero
puede incluir adaptaciones:

B -B puede añadir nuevos atributos

-B puede añadir nuevos métodos

-B puede Redefinir métodos

... • Refinamiento: Extender la implementación original 41

• Reemplazo: Anular y Redefinir la implementación de A

- B puede implementar un método diferido en A

82
El proceso de herencia es transitivo
A B hereda de A
C hereda de B y A

B B y C son descendientes (subclases) de A

B es un descendiente directo de A
C es un descendiente indirecto de A
B hereda de A
C B es subclase de A (Smalltalk, Java)
A es superclase de B (Smalltalk, Java)
Terminología B es una clase derivada de A (C++)
A es la clase base de B (C++)
B es descendiente de A (Eiffel)
A es un ascendiente de B (Eiffel) 83

Tipos de herencia
A ● Herencia simple
– Una clase puede heredar de una única
B C superclase.

D E – Ejemplo: Smalltalk, Java

● Herencia múltiple
B C – Una clase puede heredar de varias 42
superclases.

A – Clases forman un grafo dirigido aciclíco

– Ejemplos: Eiffel, C++ 84

 ¿Cómo detectar la herencia
durante el Análisis/Diseño?
● Generalización
Se detectan clases con un comportamiento común a una
posible superclase (p.ej. Libro y Revista de Publicaciones)

● Especialización
Se detecta que una clase es un caso especial de otra (p.ej.
Rectangulo de Polígono)

No hay receta mágica para crear buenas jerarquías

Potenciales problemas con la evolución de la jerarquía

85

Ejemplo: Polígonos y Rectángulos

● Tenemos la clase Polígono y necesitamos

representar rectángulos:

¿Debemos crear la clase Rectángulo partiendo

de cero?
43
● Podemos aprovechar la existencia de
similitudes y particularidades entre ambas
clases
86
Ejemplo: Polígonos y Rectángulos
● Un rectángulo tiene muchas de las características de
un polígono (rotar, trasladar, vértices,..)
● Pero tiene características especiales como 4 lados y
ángulos rectos
● Algunas características de polígono pueden
implementarse de un modo más específico

class Rectangulo extends Poligono

{
...Atributos y Métodos específicos de Rectángulo
}

87

¿Cómo detectar la herencia

durante el Análisis/Diseño?
No hay receta mágica para crear buenas jerarquías

Circulo Elipse

Elipse Circulo 44
(a) (b)

a) herencia para compartir código (implementación)

b) herencia para especializar un tipo (comportamiento)
88
 Herencia simple y múltiple

Vehículo

Terrestre Acuático

Bicicleta Automóvil Vehículo Bote

Anfibio
Herencia
Herencia Múltiple
Simple

89

Herencia simple y múltiple

● En los lenguajes de programación puede existir

una clase “raíz” de la cual heredan las demás
directa o indirectamente.
● Incluye todas las características comunes a
todas las clases
Java: clase Object 45
Eiffel: clase ANY
Smalltalk: clase Object
C++: no existe
90
 Otras Relaciones

● Herencia (o relación de Generalización).

– Es-un-tipo-de

● Asociación (relación estructural)

– Agregación (todo-parte)

● Dependencia (o relación de Uso)

● Realización

91

Agregación vs. Generalización

• Herencia: relación “es-un”
• Agregación: relación “todo-parte”

Lámpara

Lámpara Lámpara Cab

Base
Fluorescente Incandescente le
46
Cubierta Interruptor

92
Encapsulamiento (Figura tomada de Booch 94)

Esconde los detalles de la implementación de un objeto.

Los objetos combinan datos y operaciones.
93

Encapsulamiento

● La abstracción y el encapsulamiento son

conceptos complementarios

ABSTRACCION ENCAPSULAMIENTO

Da una idea del Se enfoca sobre la 47

comportamiento implementación que
externo: la interface logrará ese
contractual comportamiento
94
 Encapsulamiento
● Ejemplos:
Abstracción Cuenta
Encapsulamiento Cómo hace el proceso de depósito,
extracción, etc.
● Prácticamente, cada Clase debe tener 2
partes:
– Interface: La vista externa de la abstracción desde el punto
de vista de un objeto cliente
– Implementación y Ocultamiento de Información
● Definición
El encapsulamiento consiste en separar la
interface (comportamiento público) de la
implementación y comportamiento privado
(métodos y atributos privados)
95

Encapsulamiento: Ejemplo
Cuenta
Estado
NombreCliente:String
Codigo:String
Saldo:Entero
UltimaOper: Lista Interface
(Parte visible de un objeto)
Métodos
depósito() { ...} depósito()
extracción() { ...} verSaldo()
verSaldo() { ...}
calculaInteres() { ...} extracción()
48

Una clase incluye atributos (privados y/o públicos)

junto con un conjunto de métodos (privados y/o
públicos) para manipularla. 96
Encapsulamiento:
Ocultamiento de Información
● Definición
proceso que esconde los detalles de implementación dentro
de un módulo y los hace inaccesibles fuera del módulo
[Carrano1995]

● Niveles de Acceso
– Privado
– Público
– Protegido

97

Ocultamiento de Información

Objeto :circulo
Objeto :point
......
......
point.setXY(1,
point.setXY(1, 2)
2)
...... setXY 10
......
x
getX
20
......
point.y = 5 getY y
......
Interface Implementación 49
privada

98
Polimorfismo

● poly = muchas, morphos = forma

– Polimorfismo es la capacidad de adoptar varias

formas.

● Tipos de Polimorfismo (de valor para sistemas

informáticos)
– Estático
– Dinámico
– ...

99

Polimorfismo Estático
● También llamado sobrecarga de funciones
● Es el nombre del método lo que es polimórfico: un
mismo nombre, diferentes comportamientos ()
● El comportamiento a invocar se resuelve en tiempo
de compilación, según los argumentos utilizados (la
signatura de la función).

● No es necesario que exista similitud semántica.

50

100
Polimorfismo Estático
● Ej.: Utilizar una única interfaz que permita realizar
depósitos bancarios en diferentes monedas:
En el caso por defecto los depósitos se realizan en
la moneda de la cuenta
Si el depósito se realiza en una moneda diferente a
la de la cuenta, la misma deberá ser especificada.

CuentaBancaria

- nombreCliente: String
- codigo: String
- saldo: double
- operaciones: List Cuenta
- moneda:String Bancaria

+ depositar(monto:double); depositar()
+ depositar(monto:double, moneda:String);
+ extraer() …
+ verSaldo()
- calcularInteres()
Interfaz Pública
Implementación

Polimorfismo Dinámico
● Enfoque simplista
cuando instancias de distintas clases de una
misma jerarquia de herencia responden de
manera diferente a un mismo mensaje

Mensaje: acelerar Mensaje: acelerar

51

102
 Polimorfismo Dinámico
 Un mismo método se comporta diferente para
distintos objetos
 Restringido a métodos delegados/redefinidos
en una jerarquia de herencia
 Se puede utilizar el comportamiento de una
superclase para enviar mensajes a objetos de
las subclases.

Polimorfismo Dinámico
• Un método definido (abstracto o concreto) en una
clase es redefinido en todas las subclases que la
extienden.
• La definición del método (en la superclase) provee la
interfaz común
• El método heredado y redefinido en cada una de las
subclases provee las diferentes implementaciones
● El comportamiento a invocar se resuelve en tiempo de
ejecución, según el objeto que reciba el mensaje 52
● Importante para escribir código genérico
– reúso de interfaces

104
Polimorfismo Dinámico

Transporte

acelerar()

Bicicleta Automóvil

acelerar() acelerar()

105

Polimorfismo Dinámico
● sea x una variable que referencia a un objeto
de tipo (clase) Transporte

● sea el mensaje
x.acelerar()

● la forma en que x responde al mensaje

acelerar depende del objeto actualmente 53
referido por x (Bicicleta o Automóvil)

106
Polimorfismo Dinámico
● Invocación Dinámica
Transporte x
+acelerar()
Bicicleta Transporte x = new Bicicleta();
void acelerar() { x.acelerar();
//pedalear mas rápido
}

Transporte x
+acelerar()
Transporte x = new Automovil();
Automóvil
x.acelerar();
void acelerar() {
//dejar pasar más combustible
}

Polimorfismo Dinámico

Atributos
origen
color
....
Operaciones
dibujar()
borrar()
54
mover()
rotar()
....
108
 Polimorfismo Dinámico
● Supongamos que tenemos las siguientes
declaraciones:
– Poligono p; Rectangulo r; Triangulo t;

● y la creación de objetos
– Rectangulo r = new Rectangulo ();
– Triangulo t = new Triangulo ();
● Entonces, las siguientes asignaciones son válidas:
– p = r; p = t;
● Def.: Un tipo T es compatible con un tipo P sólo si la
clase de T es un descendiente de la clase base de P.
Además, todo parámetro de T debe ser compatible con
el correspondiente parámetro formal en P. 109

Relaciones

 Están presentes en cualquier sistema

 Definen como se producen los
intercambios de información y datos
 También ayudan a comprender las
propiedades de unas clases a partir de
las propiedades de otras
 Existen 4 tipos de relaciones:
55
 Asociación
 Herencia
 Agregación
 Instanciación
Relación de Asociación

 Relación más general

 Denota una dependencia semántica
 Es bidireccional
 Primer paso para determinar una relación
más compleja
Ejemplo: Relación entre un producto y una venta.
Cualquier venta está asociada a un producto, pero no es,
ni forma parte de, ni posee ningún producto… al menos
en una primera aproximación.

 Cardinalidad: multiplicidad a cada lado

 Uno a uno: Venta-Transacción
 Uno a muchos: Producto-Venta
Muchos a muchos: Comprador-Vendedor

Relación de Herencia

 ¡Relación característica de la OOP!

 Puede expresar tanto
especialización como generalización
 Evita definir repetidas veces
las características comunes a
varias clases
 Una de las clases comparte la
estructura y/o el comportamiento 56

de otra(s) clase(s).
 También se denomina relación “es
un/a” (is a)
Relación de Herencia (vocabulario)
 Clase base o superclase: clase de la cual se
hereda
 Clase derivada o subclase: clase que hereda
 Herencia simple: Hereda de una sola clase
 Herencia múltiple: Hereda de varias clases
 Java solo la soporta parcialmente
 Presenta diversos problemas (¿qué hacer cuando se
hereda más de una vez de la misma clase?)
 Clase abstracta: La que no lleva, ni puede
llevar, ningún objeto asociado
 Polimorfismo: Posibilidad de usar
indistintamente todos los objetos de un clase y
derivadas.

Relación de Herencia (ejemplo)

Equilátero
Polimorfismo

Clase abstracta Triángulo Isósceles

Figura plana
Escaleno
Herencia simple 57

Rectángulo Cuadrado

Superclase Subclase
Relación de Agregación

 Una clase contiene a otra

clase
 Ésta “es parte de” aquélla.
 También se denomina
relación “es parte de” (has a)
 Una clase puede contener a otra:
 Por valor: Cuando los objetos de la clase
contenida se crean y destruyen al mismo
tiempo que los de la clase continente
 Por referencia: Cuando no necesariamente
ocurre lo anterior

Relación de Agregación
Un coche está hecho de
 Volante
 Palanca de cambio Volante
 Motor
 Ruedas
Marchas

Coche
Motor 58

Ruedas
Relación de Instanciación

 En determinados casos una clase (p.ej. un

vector) puede implementarse
independientemente del tipo (real,
complejo, color...) de alguno de sus
atributos: Tipo

 Definimos una clase Vector

parametrizada o template
(plantilla)
 Para cada uno de los tipos
VectorColores VectorEnteros
que necesitemos <Color> <int>
definimos una nueva
clase  Instanciación

Técnica CRC
Clase-Responsabilidad-Colaboración
• Técnica utilizada para obtener un diseño OO a
partir de un enunciado/especificación que describe
un sistema.
• Pasos:
• Encontrar clases
• Encontrar responsabilidades
• Encontrar colaboraciones

59

118
 Técnica CRC
Clase-Responsabilidad-Colaboración
• Encontrar Clases
• Objetivo: crear las clases que modelarán el dominio de la
aplicación

• Registrar sustantivos o frases sustantivas

• Pasar sustantivos a singular
• Clasificar el listado en:
• Clases obvias
• Clases posibles
• Clases improbables (automaticamente descartadas)
• Intentar definir el propósito de cada item de la lista como
clase del sistema descartando aquellas sin sentido para el
sistema.
• Siempre tener en mente el objetivo del sistema
119

Técnica CRC
Clase-Responsabilidad-Colaboración
• Encontrar Clases - Ejemplo
Clase: Dibujo

Responsabilidades Colaboraciones

Clase: ATM

Responsabilidades Colaboraciones 60
 Técnica CRC
Clase-Responsabilidad-Colaboración
• Encontrar Responsabilidades
• Objetivo: Asignar responsabilidades a cada clase
encontrada reafirmando su propósito y su rol en el sistema
• Que son responsabilidades?:
• El conocimiento que mantiene una clase/objeto
• Las acciones que una clase/objeto puede realizar
• Registrar verbos que representen accione que el sistema
debe realizar
• Tener en cuenta que las clases identificadas sugieren una
responsabilidad dentro del sistema
• La definición o propósito de la clase puede sugerir
responsabilidades adicionales
• Asignar cada responsabilidad a la clase a la cual esta
asociada lógicamente (ver el contexto en el que se menciona
la responsabilidad) 121

Técnica CRC
Clase-Responsabilidad-Colaboración
• Encontrar Responsabilidades (cont.)
• Tener en cuenta:
• Distribuir las responsabilidades de forma balanceada
• Enunciar las responsabilidades lo suficientemente
generales
• Tener en cuenta responsabilidades relacionadas

61

122
Técnica CRC
Clase-Responsabilidad-Colaboración
• Encontrar Responsabilidades - Ejemplo
Clase: Dibujo

Responsabilidades Colaboraciones
 Conocer que elementos contiene

 Mantener el ordenamiento entre los

elementos

Clase: ATM

Responsabilidades Colaboraciones
 Crear e iniciar transacciones

 Mostrar el menu principal

 Emitir Recibo

 Liberar tarjeta

Técnica CRC
Clase-Responsabilidad-Colaboración
• Encontrar Colaboraciones
• Objetivo: Establecer las relaciones entre las clases/objetos
necesarias para realizar las responsabilidades identificadas
• Que es una colaboración:
• Solicitudes del estilo cliente/servidor basadas en una
relación entre dos clases
• Examinar en la especificación las interacciones de cada
clase
• Determinar las dependencias que surgan de cada
responsabilidad
• Establecer relaciones entre clases que posean 62
resposabilidades dependientes entre si.

124
Técnica CRC
Clase-Responsabilidad-Colaboración
• Encontrar Colaboraciones - Ejemplo
Clase: Dibujo

Responsabilidades Colaboraciones
 Conocer que elementos contiene  Elemento de Dibujo

 Mantener el ordenamiento entre los

elementos

Clase: ATM

Responsabilidades Colaboraciones
 Crear e iniciar transacciones  Transacción

 Mostrar el menu principal  Menu

 Emitir Recibo  Impresora de Recibos

 Liberar tarjeta  Lector de Tarjetas

63