Manual de programacion orientada a Objetos

Introduccin al Paradigma de Objetos

www.educacionIT.com.ar | Tel. (54) (011) 4328-0457 Pgina 1 Lavalle 648 8vo Piso Capital Federal Copyright 2011-Actualidad, educacionIT. Todos los derechos estn reservados

1. LOS PARADIGMAS......................................................................................................................................3 1.1. QUE ES UN PARADIGMA.............................................................................................................................3 1.2. EL PARADIGMA DE OBJETOS .....................................................................................................................3 1.3. LA PROGRAMACIN ORIENTADA A OBJETOS.............................................................................................4 1.4. POR QUE OBJETOS ......................................................................................................................................4

2. MODELADO DE OBJETOS ........................................................................................................................6 2.1. QUE ES UN MODELO ..................................................................................................................................6 2.2. QUE ES UN OBJETO ....................................................................................................................................6 2.3. QUE ES UN MENSAJE .................................................................................................................................7 2.4. QUE ES EL COMPORTAMIENTO...................................................................................................................7 2.5. QUE ES UN AMBIENTE................................................................................................................................8 2.6. EL SOFTWARE ORIENTADO A OBJETOS......................................................................................................9

3. INTRODUCCIN AL PARADIGMA DE OBJETOS ...............................................................................9 3.1. LOS OBJETOS Y LAS CLASES......................................................................................................................9 3.2. LOS ATRIBUTOS.......................................................................................................................................11 3.3. LOS TIPOS DE DATO ................................................................................................................................11 3.4. LAS OPERACIONES...................................................................................................................................12 3.5. LA VISIBILIDAD .......................................................................................................................................13 3.6. EL ENCAPSULAMIENTO............................................................................................................................14 3.7. LOS CONSTRUCTORES .............................................................................................................................15 3.8. LA SOBRECARGA DE OPERACIONES.........................................................................................................16 3.9. MECANISMO DE HERENCIA......................................................................................................................17 3.10. POLIMORFISMO ......................................................................................................................................20 3.11. ATRIBUTOS DE CLASE ...........................................................................................................................22 3.12. OPERACIONES DE CLASE .......................................................................................................................23

4. INTRODUCCIN A UML..........................................................................................................................24 4.1. QU ES UML...........................................................................................................................................24 4.2. COMO NACE UML ...................................................................................................................................24 4.3. DONDE SE UTILIZA...................................................................................................................................25

5. INTRODUCCIN A LOS DIAGRAMAS DE UML ................................................................................26 5.1. INTRODUCCIN ........................................................................................................................................26 5.2. DIAGRAMA DE CLASES ............................................................................................................................26 5.3. DIAGRAMA DE OBJETOS ..........................................................................................................................26 5.4. DIAGRAMA DE CASOS DE USO .................................................................................................................26 5.5. DIAGRAMA DE ESTADOS..........................................................................................................................26 5.6. DIAGRAMA DE ACTIVIDADES ..................................................................................................................27 5.7. DIAGRAMA DE COMUNICACIN ...............................................................................................................27 5.8. DIAGRAMA DE SECUENCIA ......................................................................................................................27 5.9. DIAGRAMA DE COMPONENTES ................................................................................................................27 5.10. DIAGRAMA DE DESPLIEGUE...................................................................................................................28

6. CLASIFICACIN DE DIAGRAMAS .......................................................................................................29 6.1. CATEGORAS............................................................................................................................................29 6.2. DIAGRAMAS ESTTICOS ..........................................................................................................................29 6.3. DIAGRAMAS DINMICOS .........................................................................................................................29 6.4. DIAGRAMAS ESTRUCTURALES.................................................................................................................30 6.5. DIAGRAMAS DE COMPORTAMIENTO ........................................................................................................30

7. LABORATORIOS .......................................................................................................................................31 7.1. CONSIGNA ...............................................................................................................................................31 7.2. CASO DE ESTUDIO ...................................................................................................................................31



7.3. EJERCICIO #1 DETECCIN DE CLASES ...................................................................................................32 7.4. EJERCICIO #2 DETECCIN DE ATRIBUTOS.............................................................................................33 7.5. EJERCICIO #3 DETECCIN DE OPERACIONES.........................................................................................34 7.6. EJERCICIO #4 RELACIONES SIMPLES .....................................................................................................35 7.7. EJERCICIO #5 RELACIONES MLTIPLES ................................................................................................36 7.8. EJERCICIO #6 USO DE OBJETOS.............................................................................................................37 7.9. EJERCICIO #7 HERENCIA .......................................................................................................................38

8. DIAPOSITIVAS ...........................................................................................................................................39



1. Los Paradigmas

1.1. Que es un Paradigma Un Paradigma es un concepto abstracto, la definicin de un modelo o patrn en

cualquier disciplina fsica.

Todo paradigma nace de la filosofa de una comunidad cientfica que,

especializada en un tema particular, decide plantear algn nuevo concepto

abstracto o forma de pensar. En este caso en particular, una parte de la

comunidad cientfica que estudiaba la computacin como una rama matemtica y

se especializaba en ello, forja esta nueva ideologa o forma de pensar que es el

Paradigma de Programacin Orientado a Objetos.

En programacin, el paradigma, nos determina como van a ser los bloques de

construccin de los programas, es decir, los elementos que los constituyen.

1.2. El Paradigma de Objetos El paradigma de programacin orientada a objetos plantea que todo sistema o

proceso informtico puede modelarse con Objetos que se encuentren vivos en

algn tipo de Ambiente y se relacionan con otros Objetos enviando y recibiendo

Mensajes.

Es decir, programar bajo este paradigma, implica que nuestros programas,

debern ser pensados slo con objetos y mensajes.

Un objeto, en OOP, es un ente completamente abstracto que sabe escuchar,

responder y enviar ciertos mensajes.

Un Mensaje es una comunicacin dirigida de un objeto a otro. Informacin

enviada desde emisor, hasta el receptor.

El paradigma de objetos tiene otros conceptos que completan este esquema de

Objeto-Mensaje, que se irn detallando a lo largo del curso.

Como todo concepto terico o abstracto que quiera ser llevado a la vida real o a

la prctica, requiere de algn tipo de implementacin.



Si queremos desarrollar un software, con la idea terica o paradigma nicamente

no nos alcanzara, es necesario tener algo concreto con lo cual trabajar, una

implementacin del paradigma.

Un paradigma, en tanto que es un concepto terico, tiene infinitas

implementaciones. A la vez, por este mismo motivo, una implementacin es una

y slo una instancia posible que responde al Paradigma.

Cuando hablamos de una implementacin estamos hablando de un lenguaje de

programacin orientado a objetos (es decir, que contempla los conceptos tericos

del paradigma orientado a objetos). Cada uno de estos lenguajes implementar

cada uno de estos conceptos de forma diferente. Por eso es importante

diferenciar los conceptos del paradigma de la implementacin del paradigma.

Es decir, por ejemplo, primero es necesario conocer la definicin de un objeto

segn el paradigma, y luego, conocer la implementacin de un objeto para

determinado lenguaje de programacin.

Vamos a ir clarificando cada uno de estos conceptos a lo largo de las clases.

1.3. La Programacin Orientada a Objetos OOP (Object Oriented Programming o en espaol Programacin orientada a

objetos en ingles) se basa en el concepto de agrupar cdigo y datos juntos en

una misma unidad llamada clase. Este proceso es usualmente referido como

encapsulamiento o informacin oculta.

Estas clases son esencialmente la representacin de un set de funciones

(llamadas mtodos) y variables (llamadas propiedades) designadas para trabajar

juntas y proveer una interfaz especifica.

Es importante entender que las clases son una estructura que no puede ser

utilizada directamente, estas deben ser instancia das en objetos, los cuales

podrn as interactuar con el resto de las aplicaciones.

Es posible pensar en clases como un plano para crear un auto, mientras el objeto

es de hecho el auto en si mismo, ya que se puede crear en una lnea de

produccin. Podramos decir que una clase es una fbrica de objetos.

1.4. Por que objetos



La programacin orientada a objetos tiende a ser una simple idea. Esta simple

idea es: en lugar de crear estructuras de datos por un lado y cdigo por el otro,

la idea es asociar piezas de cdigo junto con los datos.

El mercado de lenguajes de programacin, tiende a utilizar este paradigma ya

que trae innumerables ventajas con respecto a la programacin estructurada.

A continuacin se enumeran algunas de ellas:

Escalabilidad: Capacidad de crecimiento. Que un sistema sea escalable,

significa que esta preparado para poder crecer sin limitaciones ni perjuicios.

En casos de desarrollo corporativos como por ejemplo el de un sistema

bancario, donde constantemente se necesitan agregar nuevos mdulos y

cambios en su comportamiento, es necesario contar con lenguaje de

programacin que permita fcilmente administrar estos tipos de desarrollos

empresariales.

Mantenimiento: Una de las principales caractersticas del paradigma de

objetos, es su capacidad realizar cambios en el programa a muy bajo costo

(esfuerzo del programador). Gracias a una buena organizacin de las clases y

sus herencias es posible hacer pequeos pero importantes cambios que

impacten luego en todas las partes del sistema.

Seguridad: Este paradigma posee lo que se denomina como encapsulamiento

y visibilidad lo cual permite establecer diferentes niveles de seguridad dentro

de un equipo de desarrolladores, organizando el trabajo en equipo y limitando

la posible existencia de errores o incongruencias cometidos por los

programadores.

Reutilizacin: A travs de la correcta utilizacin de jerarqua de clases, y la

redefinicin de funciones polimorfismo, se puede reutilizar un importante

porcentaje de cdigo, evitando escribir subprogramas parecidos dentro de un

mismo desarrollo.

Simplicidad: Cuando el cdigo de un programa desarrollado con lenguaje

estructurado, crece indefinidamente, se llega a un punto donde el mismo se

vuelve confuso y engorroso. El paradigma de objetos provee simplicidad al

poder organizar la complejidad del mismo a travs de su estructura de clases

y objetos.



2. Modelado de Objetos

2.1. Que es un Modelo Un modelo es una posibilidad de visualizar a escala o de una manera simulada

algo que ser construido en la realidad. Es posible decir que antes de construir un

edificio se realizan maquetas a escala que representa modelos a seguir, as como

tambin cuando se construye un auto se confeccionan distintos planos o modelos

a escala para intentar simular o prever su comportamiento.

Acadmicamente, es posible definirla como una abstraccin de la realidad, es una

simplificacin de la realidad, con el objetivo final de pasar del modelo a producto

real.

Los modelos pueden ser expresados en distintos niveles de precisin, desde algo

muy genrico presentando una visin, hasta algo mucho mas especifico que

representa un gran compromiso con el producto a construir.

2.2. Que es un Objeto Un objeto en OOP es un ente completamente Abstracto que sabe escuchar,

responder, y enviar ciertos mensajes.

Bajando ms a informtica, podemos definir un objeto como un ente

computacional, que est dentro del software, y puede representar o no un ente

de la realidad que est fuera de la computadora.

Por ejemplo, un objeto Persona, o un Usuario, puede representar una persona

real, en el manejo de usuarios de una aplicacin.

Si seguimos con el ejemplo de Persona, una persona puede comer, vestirse,

trasladarse, leer, y muchas cosas ms! Si revisamos la primera definicin, dice

que sabe responder ciertos mensajes entonces, estos son, los mensajes de los

que hablbamos.

Y quin le enva los mensajes?

La respuesta es fcil, otro objetos, recordemos, que en el paradigma de objetos,

slo tenemos objetos y mensajes, y nada ms.

Y que pasa con los nmeros? Tambin son objetos?



Va a depender del lenguaje. En principio, en un lenguaje orientado a objetos,

todo debera ser un objeto, pero esto no es tan as, existen algunos lenguajes

que eligen no respetar eso a rajatabla y modelan algunos conceptos muy bsicos

como tipos primitivos, como por ejemplo los nmero, los booleanos, los

caracteres.

2.3. Que es un Mensaje En una aplicacin orientada a objetos, entonces, tenemos objetos que se piden

cosas entre s. Por lo que, un mensaje, es una comunicacin entre dos objetos,

emisor y receptor, donde el emisor le pide algo al receptor, y puede (o no)

obtener algo como respuesta.

Por ejemplo, si a un objeto Persona le pido que me diga su edad, voy a recibir

como respuesta un nmero que representa la edad de la persona.

Si tengo un objeto Alumno, podra pedirle los cursos que est haciendo

actualmente, y en este caso que me devuelve? Me devuelve un objeto que

representa el conjunto de cursos que esta haciendo.

Un objeto entiende cualquier mensaje que se le enva?

No! Nosotros, como programadores de objetos, debemos definir cuales son los

mensajes que entiende cada objeto.

Y que pasa si le mando un mensaje que no entiende?

Esto depender del lenguaje, pero en principio, esto causa un error, ya que si un

objeto no entiendo el mensaje que se le est mandando, entonces nuestro

programa no estara andando bien.

2.4. Que es el Comportamiento



Ya dijimos que un objetos era un ente abstracto, que saba enviar y responder

mensajes. Y que nosotros debemos definir cuales son los mensajes que un objeto

debe entender.

El comportamiento, es el conjunto de mensajes que un objeto entiende, y a los

que me puede o no responder. Lo importante, es que lo entiende.

Con este nuevo concepto, podramos entonces entender un objeto como:

Un ente computacional que exhibe comportamiento.

De esta forma, dado un objeto, por ejemplo Persona, uno podra preguntar, cul

es el comportamiento de una Persona? Y ah uno debe responder con todo lo que

el objeto persona sabe hacer. Esto, lo define el programador de ese objeto.

Dicho de otra manera, el comportamiento son las cosas que sabe hacer un

objeto, el conjunto de mensajes que un objeto le va a poder enviar.

2.5. Que es un Ambiente Los objetos nacen y mueren, o sea viven. En general nacen porque alguien los

creo quin es ese alguien? un objeto! como todo... y se mueren porque alguien

los destruye, esto tambin depender del lenguaje, pero vamos a hablar de esto

ms adelante.

Los objetos viven dentro de la computadora, en algn lugar determinado, que

es el responsable de contenerlos, manejar su ciclo de vida, dar el contexto para

la creacin y el envo de mensajes.



2.6. El Software Orientado a Objetos

Con estos conceptos, podemos decir que es el software. Es el resultado de la

interaccin de un conjunto de objetos que viven en un ambiente y que se

comunican entre s envindose mensajes.

Es importante definir software desde el punto de vista de la programacin

orientada a objetos, ya que esta es la forma que voy a tener de pensar en una

programa, en la construccin de un programa.

Entonces, de ahora en ms, para pensar un programa, tenemos que pensar:

Que objetos vamos a incluir en la aplicacin

Que mensajes va a entender cada objeto

Como van a interactuar los objetos entre s

3. Introduccin al Paradigma de Objetos

3.1. Los Objetos y las Clases En este paradigma todo se lleva a cabo con clases y objetos. Qu es un

objeto? Un objeto es un conjunto de atributos (estado) y operaciones

(comportamiento).

Debemos entender los objetos como abstracciones de la realidad con ciertas

caractersticas representativas. Estos objetos representan (o deberan

representar) ideas del mundo real, ideas concretas como por ejemplo animales o

personas.

En el POO (Paradigma Orientado a Objetos) existen dos conceptos claves que

deben ser comprendidos, los conceptos de clase y objeto.

Las clases son plantillas que contienen atributos y operaciones, se consideran los

moldes para los objetos. Las clases se detectan como sustantivos en singular el

99% de las veces, esto significa que suelen tener nombres como

CuentaCorriente o Automovil.

Ahora bien, qu es un objeto exactamente? Un objeto es la instancia de una

clase, podemos decir que el objeto representa algo en particular y la clase algo



en general. Por ejemplo si tuviramos la clase Automovil, podramos crear las

instancias (objetos) llamados renault, volkswagen o ford.

Si tenemos una clase CuentaBancaria, podemos tener infinita cantidad de

objetos de CuentaBancaria, pero cada una tendr sus valores individuales,

aunque todas pertenezcan a esta clase.

Decimos que un objeto pertenece a una clase, cuando es una instanciacin de esa

clase; es decir, al crear un objeto de la clase Banco y asignarle el nombre

bancoNacion, el objeto bancoNacion es una instanciacin de Banco.

Continuando con este ejemplo, podramos crear ms instanciaciones de Banco y

asignarles nombres como bancoRio o bancoCityBank, y todos ellos tendran

algo en comn, que pertenecen a la clase Banco, a pesar de que cada objeto

tenga sus distintos valores, como por ejemplo, distinta cantidad de clientes, de

sucursales, etc (representados por los atributos).

A continuacin se muestran algunas clases representadas grficamente:



Las clases estn compuestas por atributos y operaciones, y sern presentadas a

continuacin.

3.2. Los Atributos Como mencionamos anteriormente, los atributos son las variables contenidas por

los objetos. Las clases definen los atributos y los objetos los completan. Las

variables de una clase definen las caractersticas de sus objetos, por ejemplo:

En este caso creamos una clase Automovil y colocamos atributos color, modelo,

precio, y usado que al adquirir valores en un objeto, lo diferenciarn a este de

otras instancias (objetos) de la clase Automovil.

Lo mismo podramos hacer con una clase CuentaBancaria, como se muestra a

continuacin:

En este caso la clase CuentaBancaria cuenta con un atributo saldo.

En resumen, los atributos son las caractersticas de una clase.

3.3. Los Tipos de Dato Podemos encontrar la definicin de atributo, mediante la cual definimos que un

objeto tiene un conjunto de caractersticas que lo describe, y que se definen en

una clase.

Por ejemplo, el atributo nombre, va ser una palabra, es decir, va a ser un String,

de la misma manera, la edad, es un nmero, es decir, va a ser un int.

int y String son tipos. Un tipo es la forma de describir o almacenar un dato.

Cuando decimos que tenemos un dato del tipo int, estamos diciendo que podra

ser cualquier nmero de tipo entero.



De la misma manera, un objeto Persona podra tener un atributo Trabajo,

donde trabajo es tambin un objeto con sus propias caractersticas, es decir, el

trabajo podra tener un empleador, un nombre, una ubicacin, etc. De esta

manera, estamos diciendo que Persona, tiene como atributo Trabajo, que ser

de que tipo? De tipo trabajo!

Ac empezamos a ver la potencia de los objetos.

Anteriormente, nosotros trabajbamos con un conjunto acotado de tipos para

las variables (int, String, boolean, etc), ahora, con los objetos, nosotros podemos

crear nuestros propios tipos. Cualquier clase que nosotros creamos, de ahora

en ms, eso va a ser un nuevo tipo con el que podemos trabajar.

De la misma manera si creamos un clase Banco, de ahora en ms vamos a

tener objetos que son instancias de la clase Banco, o tambin podemos decir que

tenemos objetos del tipo Banco.

3.4. Las Operaciones Las operaciones son acciones contenidas por el objeto que definen su

comportamiento.

En este caso hemos agregado dos operaciones a la clase Automovil. Estas

operaciones le permiten acelerar o frenar, como indican sus respectivos nombres

(cuanto ms autoexplicativos sean los nombres, mejor).

Las operaciones son, en el 99% de los casos, verbos.

Las operaciones pueden admitir parmetros. Los parmetros son variables que

utilizar la operacin para generar cierto comportamiento. Las operaciones

acelerar y frenar tienen como parmetros dos valores int (nmeros enteros)

que representan la velocidad y el tiempo que acelerar o frenar.

Las operaciones de una clase CuentaBancaria podran ser las siguientes:



Las operaciones depositar y extraer tienen un solo parmetro, este parmetro

representa el monto a extraer o depositar.

En resumen, las operaciones son acciones contenidas por un objeto que definen

su comportamiento.

3.5. La Visibilidad La visibilidad o accesibilidad determina el alcance que tiene un atributo u

operacin. El alcance (scope) de un miembro representa qu partes pueden

acceder a dicho miembro. El alcance est determinado por los modificadores de

visibilidad, presentados como publico (su simbologa es el signo +) y como

privado (su simbologa es el signo -)

Que un atributo u operacin sea privado significa que aquel atributo u operacin

solo puede ser accedido desde dentro del objeto que lo contiene. En cambio si

este atributo u operacin fuera pblico podra ser accedido por cualquier objeto.

En el siguiente ejemplo podemos ver los miembros pblicos y privados de la clase

Auto diferenciados por los signos - y +:

Esto mismo se puede aplicar con la clase CuentaBancaria:

Una de las dudas que surgen a la hora de entender los modificadores de acceso

es por qu debera de tener un miembro privado?. Hacer que un atributo sea



privado se utiliza para tratar con datos o valores los cuales no queremos que

sean accedidos ms que por el objeto contenedor. Las operaciones privadas

cobran sentido como procesamientos internos del objeto que no queremos sean

accedidas por otros objetos (tanto porque no tiene sentido que la accedan otros

objetos como porque podra resultar peligroso para la integridad del objeto

contenedor).

El porqu de utilizar miembros privados se aclarar a continuacin junto con el

tema Encapsulamiento.

En resumen, la visibilidad determina el alcance (scope) del atributo u operacin

en cuestin

3.6. El Encapsulamiento El encapsulamiento es una de las caractersticas representativas de la POO. Este

concepto tiene que ver con la forma correcta de pensar en clases y objetos.

Significa aislar o independizar las clases de nuestro programa de tal manera que

su funcionamiento sea independiente del de las otras clases.

La clase Automovil posee un atributo privado que representa la velocidad y

posee una operacin pblica que le permite interactuar con otros objetos. Esta

operacin recibe como parmetro un valor que representa la velocidad que se le

quiere asignar a dicho automvil. Si esta operacin recibiera un valor negativo,

podra pasarlo a un nmero positivo, mantener la velocidad anterior o hacer

cualquier otra cosa evitando que aparezcan errores en el objeto por un dato

invlido (velocidad negativa). Si en vez de utilizar un atributo privado y una

operacin pblica, utilizramos directamente un atributo pblico, este tipo de

casos no podran ser manejados y se atentara contra la integridad del objeto.

El ocultamiento puede visualizarse mejor en el siguiente grfico:



El grafico representa que los atributos estn encerrados por operaciones, es decir

que los atributos son privados y las operaciones son pblicas. Esto significa que

para poder acceder a un atributo es necesario utilizar una operacin, es decir que

no hay posible acceso al atributo sino no se utiliza una operacin.

A continuacin se presenta el encapsulamiento con la clase CuentaBancaria:

Para poder modificar al atributo saldo, es necesario hacerlo a travs de las

operaciones depositar() o extraer().

En resumen, el encapsulamiento es la capacidad que tienen las clases de permitir

que ciertos miembros sean accesibles y ciertos miembros no lo sean, y as lograr

ocultar el estado interno de sus instancias.

3.7. Los Constructores Toda clase tiene un constructor. Los constructores son operaciones que son

invocadas al instanciar una clase. Los constructores se encargan de inicializar

atributos y configurar todo lo que sea necesario antes de que comience a existir

el objeto.

Al tratarse de operaciones, los constructores pueden contener cualquier

comportamiento, aunque estas no tengan que ver exactamente con construir el

objeto. Es posible tener ms de un constructor en una misma clase; en este caso,

cada constructor debe aceptar parmetros distintos para poder as distinguirlos.



Los constructores suelen llamarse con el mismo nombre de las clases, como se

muestra a continuacin:

Por lo tanto la clase Automovil tendr un constructor llamado Automovil(), y

la clase CuentaBancaria tendr un constructor llamado CuentaBancaria(). En

los ejemplos anteriores los constructores no tienen parmetros.

En resumen, un constructor es una operacin que es invocada al instanciar una

clase.

3.8. La Sobrecarga de Operaciones As como es posible tener ms de un constructor (que es una operacin), es

posible tener ms de una operacin con el mismo nombre dentro de la misma

clase. Para poder hacer esto es necesario que se cumplan las mismas condiciones

que para los constructores, es decir, que cada sobrecarga de operacin tenga

distintos tipos de parmetros.

Para qu podra servir tener varias operaciones con el mismo nombre pero con

distintos parmetros? Por ejemplo, si quisiramos crear una operacin llamada

extraer() que extraiga un determinado saldo de una cuenta, podramos querer

utilizarla sin determinar un tipo de moneda (utilizando la moneda del pas como

por defecto), o determinando un tipo de moneda para hacer la extraccin de

ese tipo de moneda (euro, dlar, etc).

La sobrecarga de operaciones nos permite utilizar el mismo nombre de operacin

para dos operaciones distintas, es decir, que aceptan distintos parmetros y

tienen distinta funcionalidad. Sin la existencia de este mecanismo, se debera

crear una operacin distinta por cada versin de nuestra operacin. Sin la

sobrecarga de operaciones, las operaciones estn limitadas a los parmetros de

una sola definicin de operacin.



Si quisiramos aplicar la sobrecarga de operaciones en una clase Automovil:

La operacin acelerar() tiene dos definiciones, en una acepta como argumento

la cantidad de tiempo que debe acelerar, y en la otra la cantidad de tiempo que

debe acelerar y si el auto utiliza turbo o no, representado por el segundo

parmetro de tipo booleano

En resumen, la sobrecarga de operaciones es la capacidad de poder crear

comportamientos distintos para la misma operacin aceptando distintos tipos de

parmetros.

3.9. Mecanismo de Herencia El mecanismo de herencia es otro de los conceptos clave de la POO, y uno de sus

puntos fuertes. Este mecanismo nos permite que una clase "herede de otra clase"

o "extienda otra clase" recibiendo o heredando todos los atributos y operaciones

de su clase "padre".

En el siguiente diagrama podemos ver como est compuesto un tpico rbol de

herencia simple:



En el diagrama anterior vemos como una clase puede tener tanto superclases

como subclases. Esto significa que una clase hereda de una superclase o clase

padre, y es heredada por subclases o clases hijas. La flecha indica quien

hereda a quien, es decir, el origen de la flecha es la clase hija y el destino de la

flecha es la clase padre.

Se considera clases hijas a las clases que heredan directamente de una clase y

subclases tanto a las clases hijas como al resto de clases que tengan menor

jerarqua en el rbol de herencia; se considera clase padre a la clase de la que se

hereda directamente.

Cuando una clase hereda de otra, todas las operaciones y atributos pasan a estar

disponibles en la clase hija, es decir que partimos de todos estos elementos e



incluso podemos agregar nuevos o modificar estos ya heredados. Con las clases

heredadas ampliamos la descripcin de un concepto de la vida real, lo volvemos

ms especfico.

Para comprender mejor la herencia y la naturaleza de las clases heredadas, es

necesario entender que una clase hija es ms especfica conceptualmente que la

clase padre, a la vez que la clase padre es ms general conceptualmente que la

clase hija. Esto lo podemos visualizar mejor de la siguiente manera:



En este diagrama podemos ver a la clase padre Vehiculo y su rbol de herencia.

Por comodidad no hemos colocado las clases hijas de las clases VehiculoAereo y

VehiculoAcuatico. Qu tendran en comn las clases Avion y Motocicleta?

Que ambas clases tienen como superclase a la clase vehculo, es decir, ambas

SON Vehculo.

Es importante destacar que una clase ES UN cualquiera de sus superclases, es

decir: Motocicleta ES UN VehiculoTerrestre y ES UN Vehculo,

Con cada subclase, se amplia la cantidad de elementos de dicha clase con

respecto a sus superclases, volvindola ms especfica. As, por ejemplo, la clase

vehculo hace referencia a cualquier tipo de transporte, en cambio la clase

VehiculoTerrestre hace referencia a cualquier tipo de transporte que se desplace

en un medio slido, y la clase Automovil hace referencia a un tipo de transporte

especfico. Podramos ir ms all en el rbol de herencia y crear clases para cada

modelo de automvil y hacer que extiendan a la clase Automovil.

Otro rbol de herencia podra ser el siguiente:

En este caso, la clase padre es CuentaBancaria y las clases hijas son

CajaDeAhorro y CuentaCorriente, donde CajaDeAhorro ES UNA

CuentaBancaria y CuentaCorriente ES UNA CuentaBancaria

Resumiendo, el mecanismo de herencia es la capacidad que tienen las clases de

recibir el comportamiento (operaciones) y estado (atributos) de otras clases.

3.10. Polimorfismo Otro mecanismo presente en el POO es el polimorfismo. En el POO encontramos

dos tipos de polimorfismo, uno de ellos ya lo vimos y se conoce comnmente

como "Sobrecarga de Operaciones". El otro, el que veremos ahora, tiene que ver

con la capacidad que tienen las clases de redefinir el comportamiento de una

operacin heredada de la clase padre.



Esto significa que, en una clase padre conceptualmente ms general, al tener un

mtodo al cual le dimos cierto comportamiento bsico, que puede no ser

exactamente lo que debe suceder al invocar ese mtodo desde un objeto

correspondiente a una clase hija, debemos sobrescribir esa operacin en la clase

hija con la funcionalidad o comportamiento apropiado. Si la clase hija no

redefiniera ese comportamiento, el comportamiento sera el mismo de la clase

padre (tras invocar a dicho mtodo).

Por lo cual, tendramos una clase padre con la operacin hacerAlgo que hace x

cosa, y una clase hija con la operacin hacerAlgo que hace y cosa., es decir

que la misma operacin tiene comportamientos distintos segn la clase

En el siguiente caso:

La clase AutomovilDeCarrera debe reemplazar el comportamiento de la

operacin acelerar() heredado de la clase Automovil, ya que el tipo de

aceleracin es completamente distinta. Lo mismo sucede con las siguientes

clases:



En este caso, las operaciones extraer() de ambas clases deben tener

comportamientos distintos debido a que el lmite de dinero a extraer es distinto

en cada clase. La clase CajaDeAhorro no tiene la posibilidad de extraer en

descubierto, sin embargo la clase CajaDeAhorroConDescubierto permite extraer

dinero aun cuando ya no hay mas saldo en la caja. Es decir que ambas clases

permiten extraer dinero pero de formas distintas.

En resumen, el polimorfismo es el mecanismo que permite que un objeto sea

tratado como alguna de sus superclases conservando los miembros de su propia

clase.

3.11. Atributos de Clase Tambin llamados atributos estticos, son atributos que pertenecen a la clase y

no a un objeto o instancia de clase. Esto significa que son atributos compartidos

por todos los objetos.

Por ejemplo en una clase CajaDeAhorroConDescubierto podramos declarar un

atributo esttico llamado descubierto que contenga el valor en pesos de

descubierto que puede brindar esa caja de ahorro a los clientes, es decir, no

necesitamos que cada instancia de CajaDeAhorroConDescubierto almacene un

valor independiente, sino tan solo uno que sirve para todas las instancias. Este es

el tipo de usos que se le da a los atributos estticos.

En el diagrama anterior el atributo descubierto aparece subrayado, esto es lo

que nos indica que es un atributo esttico. Lo mismo sucedera para una clase

Automovil con un atributo esttico velocidadMaxima:

En resumen, los atributos de clase (o estticos) son atributos que existen en la

clase y no en cada uno de los objetos, motivo por el cual son compartidos por

todos los objetos.



3.12. Operaciones de Clase Tambin llamadas operaciones estticas, son operaciones que corresponden a la

clase y no a las instancias de dicha clase, es decir a los objetos.

La explicacin es anloga a la presentada en el tema anterior de atributos de

clase.

En los siguientes ejemplos se aplican operaciones estticas:

Se debe observar que en ambas clases se dispone de un atributo esttico y dos

operaciones estticas, y en este caso ambas operaciones estticas se utilizan

modificar los atributos estticos.

En resumen, las operaciones de clase (o estticas) son operaciones que existen

en la clase y no en cada uno de los objetos, motivo por el cual son compartidos

por todos los objetos.



4. Introduccin a UML

4.1. Qu es UML UML es un lenguaje grafico que permite modelar, visualizar y documentar

sistemas. Esta compuesto por distintos diagramas que permiten ir representando

las distintas vistas de un sistema, cada diagrama tiene un objetivo bien definido.

UML significa Unified Modeling Language o Lenguaje Unificado de Modelado, y

esta basa en tres principios fundamentales:

Es un Lenguaje: est formado por elementos y reglas bien definidas,

que poseen su propia sintaxis y semntica

Esta Unificado: unifica los distintos criterios utilizados antes de su

creacin, es decir que toma las mejores propuestas de herramientas previas

para presentar una propuesta sumamente abarcativa e integradora

Permite Modelar: est basado en la construccin de modelos que

permite representar abstracciones de la realidad.

UML esta estrechamente ligado con el paradigma de objetos, lo que permite

construir sistemas de informacin de una forma mucho mas intuitiva, integrada y

sencilla con el proceso de desarrollo.

UML no es una metodologa que presenta los pasos a seguir para realizar un

desarrollo, sino que es un lenguaje grafico de modelado.

4.2. Como nace UML La historia cuenta que UML da sus primeros pasos con al unin de los tres

amigos: Booch, Rumbaugh y Jacobson.

En los aos 80 cada uno utilizaba un lenguaje propietario aunque como

denominador comn tenan como objetivo el desarrollo de sistemas, con previa

modelizacin. A partir de los aos 90 comienzan a intercambiar ideas para

intentar unificar criterios.

Booch es el fundador de Rational Software Corp, y recluta en el ao 1995 a

Rumbaugh y Jacobson para comenzar a determinar una especificacin genrica,

sencilla y abarcativa.



As es como las grandes empresas de tecnologas de informacin entre ellas

Rational - deciden forman un consorcio para la construccin de un Lenguaje

Unificado de Modelado: UML. La primer versin de UML, la 1.0, sale a la luz en el

ao 1997, y a partir de 1998 un organizacin llamada OMG (Object Management

Group) se encargo de generar nuevas revisiones. En el ao 1998 UML se

establece como Standard de facto en la industria del Software.

4.3. Donde se utiliza UML se utiliza dentro del marco de IT, aunque puede utilizarse en proyectos que

no son de tecnologa de la informacin, como ser el modelado de un motor o de

una turbina.

En el campo de IT, se utiliza tanto para sistemas monolticos como para sistemas

distribuidos, abarca desde proyectos pequeos hasta grandes proyectos. Permite

realizar la integracin del software, donde representa el correcto enlace de los

roles para lograr el xito de la constriccin del sistema. En proyectos de software,

es utilizado desde la gestacin hasta la instalacin y el testing.

Si bien para utilizar UML es posible realizar los distintos diagramas con papel y

lpiz, es conveniente contar con alguna herramienta del tipo IDE que facilite su

construccin, correccin e integracin ente diagramas.



5. Introduccin a los diagramas de UML

5.1. Introduccin UML esta organizado en una serie de diagramas que tienen objetivos bien

definidos, con una sintaxis y semntica determinada, que intentan representar /

modelar distintas vistas de un sistema.

5.2. Diagrama de Clases El Diagrama de Clases tiene como objetivo describir las clases del dominio y

sus relaciones. Permite modelar la estructura del sistema desde un punto de

vista esttico, modelando las clases desde distintos enfoques de acuerdo a la

etapa del proyecto.

Esta compuesto por clases, relaciones entre clases y opcionalmente los paquetes

que agrupan a las clases.

5.3. Diagrama de Objetos El Diagrama de Objetos tiene como objetivo describir los objetos del dominio

y sus relaciones. Permite representar al sistema en un momento determinado

del tiempo, es proporcional a obtener una fotografa o snapshot del sistema en un

momento determinado.

Esta compuesto por objetos y relaciones de enlace. Tambin es posible pensarlo

como una instancia de un Diagrama de Clases.

5.4. Diagrama de Casos de Uso El Diagrama de Casos de Uso tiene como objetivo describir las acciones del

sistema desde el punto de vista del usuario. Representa las formas que tiene

un usuario de utilizar un sistema, y se puede utilizar como un contrato entre

cliente y proveedor de software para determinar la funcionalidad del sistema, es

decir los requisitos funcionales.

Esta compuesto por actores (agentes externos al sistemas, pueden ser usuarios u

otros sistemas), casos de uso y distintos tipos de relaciones. Es posible construir

diagramas con diferentes niveles de detalle.

5.5. Diagrama de Estados



El Diagrama de Estados tiene como objetivo describir los estados por los

cuales puede pasar un objeto durante su ciclo de vida. Permite modelar

tanto estas simples como compuestos y concurrentes.

Esta compuesto por estados, pseudo-estados y transiciones entre estados.

5.6. Diagrama de Actividades El Diagrama de Actividades tiene como objetivo describir las acciones que

ocurren dentro de un proceso. Se utiliza principalmente para modelar flujo de

trabajo o workflow, con lo cual visualiza las acciones de manera ordenada.

Esta compuesto por acciones simples y concurrentes, y transiciones entre las

acciones.

5.7. Diagrama de Comunicacin El Diagrama de Comunicacin tiene como objetivo describir como colaboran o

se comunican los distintos objetos entre s para conseguir un objetivo. Se

lo suele llamar tambin Diagrama de Colaboracin. Es posible verlo como una

extensin del Diagrama de Objetos, ya que es muy parecido pero tiene como

valor agregado los mensajes que se envan entre los objetos.

Esta compuesto por objetos, relaciones de enlace y relaciones del tipo llamadas,

representando que objeto se comunica con que otro.

Es semnticamente equivalente al Diagrama de Secuencia.

5.8. Diagrama de Secuencia El Diagrama de Secuencia tiene como objetivo describir como colaboran los

distintos objetos entre s para conseguir un objetivo a lo largo del

tiempo. Esta directamente relacionado con el Diagrama de Comunicacin ya que

el objetivo es el mismo, pero tiene la particularidad de estar obligatoriamente

ordenado en el tiempo.

Esta compuesto por objetos y relaciones del tipo llamadas, representando que

objeto se comunica con que otro.

Es semnticamente equivalente al Diagrama de Comunicacin.

5.9. Diagrama de Componentes



El Diagrama de Componentes tiene como objetivo describir la relacin que

existe entre los distintos componentes del sistema. Esta directamente

vinculado con el diseo del sistema, permitiendo modelar las relaciones e

interfaces que existen entre los componentes. Est orientado a la implementacin

del sistema.

Esta compuesto por componentes, interfaces y sus relaciones.

5.10. Diagrama de Despliegue El Diagrama de Despliegue tiene como objetivo describir la arquitectura de un

sistema. Es posible representar la arquitectura desde el punto de vista lgico,

basndose en la organizacin del software, o desde una punto de vista fsico,

representando directamente cada unidad de hardware.

Esta compuesto por nodos, componentes y sus relaciones.



6. Clasificacin de Diagramas

6.1. Categoras Es posible clasificar a los diagramas segn si tienen alguna relacin con el tiempo

o no. Existen dos posibles categoras, los diagramas estticos y los diagramas

dinmicos.

6.2. Diagramas Estticos Los Diagramas Estticos son aquellos que no tienen ninguna relacin con el

tiempo. Generalmente representan a estructuras o a posibles acciones pero sin

una relacin directa con el tiempo.

Estos diagramas son:

Diagrama de Clases

Diagrama de Objetos

Diagrama de Casos de Uso

Diagrama de Componentes

Diagrama de Despliegue

6.3. Diagramas Dinmicos Los Diagramas Dinmicos son aquellos que tienen relacin con el tiempo. Estn

directamente vinculados con acciones que ocurren bajo cierta secuencia, es decir

primero una accin, luego otra, y as sucesivamente.


Diagrama de Actividades

Diagramas de Interaccin (es una subcategora, que incluye a los

Diagramas de Secuencia y Comunicacin)

Diagrama de Estado



6.4. Diagramas Estructurales Los Diagramas Estructurales son aquellos que reflejan relaciones estticas de

una estructura.


Diagrama de Clases

Diagrama de Objetos

Diagrama de Componentes

Diagrama de Despliegue

6.5. Diagramas de Comportamiento Los Diagramas de Comportamiento son aquellos que reflejan caractersticas

de comportamiento del sistema o modelan procesos de negocios.


Diagrama de Casos de Uso

Diagrama de Comunicacin

Diagrama de Secuencia

Diagrama de Actividades

Diagrama de Estados



7. Laboratorios

7.1. Consigna Los ejercicios sern realizados en forma grupal, en grupos de 4 o 5 personas,

analizando un caso de estudio y armando una solucin utilizando el pensamiento

de objetos.

El caso de estudio y su solucin consisten en pensar e identificar cules son los

objetos que tendramos en nuestro sistema de gestin bancaria.

7.2. Caso de Estudio BancoMax es el primer banco privado del sistema financiero argentino en ahorro

(depsitos ms fondos comunes) y en volumen de crdito. La entidad cuenta con

276 sucursales, ms de 2 millones de clientes (entre ellos ms de 100 mil PyMEs

y aproximadamente 1.100 empresas corporativas), tiene presencia en 20

provincias y en la Ciudad Autnoma de Buenos Aires. Es uno de los bancos lderes

en medios de pago, en comercio exterior, servicios transaccionales y cash

management a travs de la gestin de cuentas comerciales de caja de ahorro y

cuentas corrientes. Y tambin uno de los principales protagonistas en los

mercados burstiles, de ttulos pblicos y cambiarios.

El Banco desarrolla asimismo un amplio programa de responsabilidad social

corporativa, focalizado en la educacin superior y que incluye tambin proyectos

para generacin de empleo. Estas acciones estn en lnea con lo que BancoMax

realiza en las comunidades en donde est presente.

De acuerdo a su estructura de organizacin, BancoMax cuenta con una jerarqua

bien definida de cadena de mando, con un director general, un director por regin

y un director responsable de cada sucursal.

BancoMax integra una amplia red de servicios financieros internacionales que

brinda el Grupo BancoMaxGroup. Las capacidades internacionales han llevado a

BancoMax a ocupar tambin una posicin de liderazgo en el Reino Unido y

Latinoamrica. Es uno de los principales grupos financieros del mundo, logrando

este lugar gracias a su calidad de servicios, innovacin, dinamismo, disciplina y

visin global. Con ms de 11.000 sucursales, BancoMax es el grupo financiero

con ms sucursales en todo el mundo.



7.3. Ejercicio #1 Deteccin de Clases Identificar las clases iniciales y necesarias para construir un sistema de gestin

bancaria

TIP: las clases se detectan como sustantivos en singular



7.4. Ejercicio #2 Deteccin de Atributos A partir de las clases detectadas en el ejercicio anterior, identificar los atributos

que consideres necesarios en cada clase. Cada atributo deber tener establecido

un tipo de dato. Se requiere identificar al menos tres atributos por clase.

Los tipos de datos a utilizar para este ejercicio son: String, int, long, float,

double, Date

TIP: los atributos son caractersticas de una clase

Pregunta: en que clase ubicaras los siguientes atributos?

cantidadDeEmpleados

numeroDeCuenta

edad



7.5. Ejercicio #3 Deteccin de Operaciones A partir de las clases y los atributos detectados en los ejercicios anteriores,

identificar al menos dos operaciones que realiza cada clase.

Tip: las operaciones son verbos

Pregunta: en que clase ubicaras las siguientes operaciones ?

informarSaldo()

informarSucursales()

informarClientes()

depositarDinero(monto)

informarDatosDeCuenta(nroDeCuenta)



7.6. Ejercicio #4 Relaciones Simples A partir de las clases detectadas previamente, identifique las relaciones simples

que existen entre las mismas.

Para este ejercicio, asumiremos que cada cliente puede tener una nica cuenta.



7.7. Ejercicio #5 Relaciones Mltiples A partir de las clases detectadas previamente, identifique las relaciones mltiples

que existen entre las mismas.

Para este ejercicio, asumiremos que un cliente corporativo puede tener ms de

una cuenta corriente.



7.8. Ejercicio #6 Uso de Objetos Asumiendo que un cliente individual utiliza el cajero automtico para realizar un

depsito de $2500, ingresa su DNI nmero 27.014.589 como pin y realiza el

depsito.

El cdigo que respalda las siguientes operaciones es el siguiente:

ClienteIndividuo c = ClienteIndividuo(27014589);

CajaDeAhorro cda = c.obtenerCajaDeAhorro();

cda.depositar(2500);

Suponiendo ahora que un cliente corporativo desea realizar una extraccin de

una cuenta corriente, teniendo en cuenta los siguientes datos:

el cuit de la empresa es 30-12345678-1

desea extraer $20.000

en la cuenta hay disponible $18.000

el giro en descubierto es de $5.000

TIP: el giro en descubierto es el monto mximo que el banco le presta al cliente

en caso de que el saldo en su cuenta sea cero. Es decir que si el cliente no tiene

fondos en la cuenta, y desea realizar una extraccin o un pago, puede utilizar

automticamente hasta $5.000

Realizar el cdigo en forma genrica utilizando las clases Programa,

ClienteCorporativo y CuentaCorriente.



7.9. Ejercicio #7 Herencia A partir de las clases detectadas previamente, identificar las relaciones de

herencia que existen.

Si consideras til y/o necesario, puedes proponer nuevas clases.



8. Diapositivas

Manual de programacion orientada a Objetos

Documents