Manual de programacion orientada a Objetos

Introducción al Paradigma de Objetos

1. LOS PARADIGMAS......................................................................................................................................3

1.1. QUE ES UN PARADIGMA .............................................................................................................................3 1.2. EL PARADIGMA DE OBJETOS .....................................................................................................................3 1.3. LA PROGRAMACIÓN ORIENTADA A OBJETOS .............................................................................................4 1.4. POR QUE OBJETOS ......................................................................................................................................4 2. MODELADO DE OBJETOS ................................................... .............................................................................................................. ..................................................................... ..........66

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. INTRODUCCIÓN INTRODUCCIÓN 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. INTRODUCCIÓN A UML..........................................................................................................................24

4.1. QUÉ ES UML...........................................................................................................................................24 4.2. COMO NACE UML ...................................................... ................................................................................................................. ........................................................... .................. 24 4.3. DONDE SE UTILIZA ...................................................................................................................................25 5. INTRODUCCIÓN INTRODUCCIÓN A LOS DIAGRAMAS DE UML UML .................................................... ................................................................................ ............................ 26

5.1. INTRODUCCIÓN ........................................................................................................................................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 COMUNICACIÓN ...............................................................................................................27 5.8. DIAGRAMA DE SECUENCIA ......................................................................................................................27 5.9. DIAGRAMA DE COMPONENTES ................................................................................................................27 5.10. DIAGRAMA DE DESPLIEGUE ...................................................................................................................28 6. CLASIFICACIÓN DE DIAGRAMAS ........................................................ ....................................................................................................... ............................................... 29

6.1. CATEGORÍAS ............................................................................................................................................29 6.2. DIAGRAMAS ESTÁTICOS ..........................................................................................................................29 6.3. DIAGRAMAS DINÁMICOS .........................................................................................................................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

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

Página 1


7.3. EJERCICIO #1 – DETECCIÓN DE CLASES ...................................................................................................32 7.4. EJERCICIO #2 – DETECCIÓN DE ATRIBUTOS .............................................................................................33 7.5. EJERCICIO #3 – DETECCIÓN DE OPERACIONES .........................................................................................34 7.6. EJERCICIO #4 – RELACIONES SIMPLES .....................................................................................................35 7.7. EJERCICIO #5 – RELACIONES MÚLTIPLES ................................................................................................36 7.8. EJERCICIO #6 – USO DE OBJETOS .............................................................................................................37 7.9. EJERCICIO #7 – HERENCIA .......................................................................................................................38 8. DIAPOSITIVAS .................................................... ............................................................................................................... ....................................................................................... ............................ 39


Página 2


1. Los Paradigmas 1.1. Que es un Paradigma Un Paradigma es un concepto abstracto, la definición de un modelo o patrón en cualquier disciplina física. Todo paradigma nace de la filosofía de una comunidad científica que, especializada en un tema particular, decide plantear algún nuevo concepto abstracto o forma de pensar. En este caso en particular, una parte de la comunidad científica que estudiaba la computación como una rama matemática y se especializaba en ello, forja esta nueva ideología o forma de pensar que es el Paradigma de Programación Orientado a Objetos. En programación, el paradigma, nos determina como van a ser los bloques de construcción de los programas, es decir, los elementos que los constituyen.

1.2. El Paradigma de Objetos El paradigma de programación orientada a objetos plantea que todo sistema o proceso informático puede modelarse con Objetos que se encuentren vivos en algún tipo de Ambiente y se relacionan con otros Objetos enviando y recibiendo Mensajes. Es decir, programar bajo este paradigma, paradigma, implica que

nuestros programas, programas,

deberán ser pensados sólo 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 comunicación dirigida de un objeto a otro. Información enviada desde emisor, hasta el receptor. El paradigma de objetos tiene otros conceptos que completan este esquema de Objeto-Mensaje, que se irán detallando a lo largo del curso. Como todo concepto teórico o abstracto que quiera ser llevado a la vida real o a la práctica, requiere de algún tipo de implementación.


Página 3


Si queremos desarrollar un software, con la idea teórica o paradigma únicamente no nos alcanzaría, es necesario tener algo concreto con lo cual trabajar, una implementación del paradigma. Un

paradigma,

en

tanto

que

es

un

concepto

teórico,

tiene

infinitas

implementaciones. A la vez, por este mismo motivo, una implementación es una y sólo una instancia posible que responde al Paradigma. Cuando hablamos de una “implementación” estamos hablando de un lenguaje de programación orientado a objetos (es decir, que contempla los conceptos teóricos 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 “implementación del paradigma”. Es decir, por ejemplo, primero es necesario conocer la definición de un “objeto” según el paradigma, y luego, conocer la implementación de un objeto para determinado lenguaje de programación. Vamos a ir clarificando cada uno de estos conceptos a lo largo de las clases.

1.3. La Programación Orientada a Objetos OOP (Object Oriented Programming o en español Programación orientada a objetos en ingles) se basa en el concepto de agrupar código y datos juntos en una misma unidad llamada clase. Este proceso es usualmente referido como encapsulamiento o información oculta. Estas clases son esencialmente la representación de un set de funciones (llamadas métodos) 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 podrán 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 línea de producción. Podríamos decir que una clase es una fábrica de objetos.

1.4. Por que objetos


Página 4


La programación orientada a objetos tiende a ser una simple idea. Esta simple idea es: en lugar de crear estructuras de datos por un lado y código por el otro, la idea es asociar piezas de código junto con los datos. El mercado de lenguajes de programación, tiende a utilizar este paradigma ya que trae innumerables ventajas con respecto a la programación estructurada. A continuación 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 módulos y

cambios en su comportamiento, es necesario contar con lenguaje de programación que permita fácilmente administrar estos tipos de desarrollos empresariales. 

Mantenimiento: Una de las principales características del paradigma de objetos, es su capacidad realizar cambios en el programa a muy bajo costo (esfuerzo del programador). Gracias a una buena organización de las clases y sus herencias es posible hacer pequeños 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. 

Reutilización: A través de la correcta utilización de jerarquía de clases, y la redefinición de funciones – polimorfismo, se puede reutilizar un importante porcentaje de código, evitando escribir subprogramas parecidos dentro de un mismo desarrollo.



Simplicidad: Cuando el código 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 través de su estructura de clases y objetos.


Página 5


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 también cuando se construye un auto se confeccionan distintos planos o modelos a escala para intentar simular o prever su comportamiento. Académicamente, es posible definirla como una abstracción de la realidad, es una simplificación de la realidad, con el objetivo final de pasar del modelo a producto real. Los modelos pueden ser expresados en distintos niveles de precisión, desde algo muy genérico presentando una visión, 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 más a informática, 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 aplicación. Si seguimos con el ejemplo de Persona, una persona puede comer, vestirse, trasladarse, leer, y muchas cosas más! Si revisamos la primera definición, dice que sabe “responder ciertos mensajes” entonces, estos son, los mensajes de los que hablábamos. ¿Y quién le envía los mensajes? La respuesta es fácil, otro objetos, recordemos, que en el paradigma de objetos, sólo tenemos objetos y mensajes, y nada más. ¿Y que pasa con los números? ¿También son objetos?


Página 6


Va a depender del lenguaje. En principio, en un lenguaje orientado a objetos, todo debería ser un objeto, pero esto no es tan así, existen algunos lenguajes que eligen no respetar eso a rajatabla y modelan algunos conceptos muy básicos como tipos primitivos, como por ejemplo los número, los booleanos, los caracteres.

2.3. Que es un Mensaje En una aplicación orientada a objetos, entonces, tenemos objetos que se piden cosas entre sí. Por lo que, un mensaje, es una comunicación 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 número que representa la edad de la persona. Si tengo un objeto Alumno, podría 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 envía? 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 estaría andando bien.

2.4. Que es el Comportamiento


Página 7


Ya dijimos que un objetos era un ente abstracto, que sabía 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, podríamos entonces entender un objeto como: “Un ente computacional que exhibe comportamiento”. De esta forma, dado un objeto, por ejemplo Persona, uno podría preguntar, ¿cuál 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 ¿quién es ese alguien? un objeto! como todo... y se mueren porque alguien los destruye, esto también dependerá del lenguaje, pero vamos a hablar de esto más adelante. Los objetos viven “dentro de la computadora”, en algún lugar determinado, que es el responsable de contenerlos, manejar su ciclo de vida, dar el contexto para la creación y el envío de mensajes.


Página 8


2.6. El Software Orientado a Objetos Con estos conceptos, podemos decir que es el software. Es el resultado de la interacción de un conjunto de objetos que viven en un ambiente y que se comunican entre sí enviándose mensajes. Es importante definir software desde el punto de vista de la programación orientada a objetos, ya que esta es la forma que voy a tener de pensar en una programa, en la construcción de un programa. Entonces, de ahora en más, para pensar un programa, tenemos que pensar: 

Que objetos vamos a incluir en la aplicación



Que mensajes va a entender cada objeto



Como van a interactuar los objetos entre sí

3. Introducción 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 características

representativas.

Estos

objetos

representan

(o

deberían

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


Página 9


en general. Por ejemplo si tuviéramos la clase “Automovil”, podríamos 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 instanciación de esa clase; es decir, al crear un objeto de la clase “Banco” y asignarle el nombre “bancoNacion”, el objeto “bancoNacion” es una instanciación de “Banco”. Continuando con este ejemplo, podríamos crear más instanciaciones de “Banco” y asignarles nombres como “bancoRio” o “bancoCityBank”, y todos ellos tendrían algo en común, 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 continuación se muestran algunas clases representadas gráficamente:


Página 10


Las clases están compuestas por atributos y operaciones, y serán presentadas a continuación.

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 características 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 diferenciarán a este de otras instancias (objetos) de la clase “Automovil”. Lo mismo podríamos hacer con una clase “CuentaBancaria”, como se muestra a continuación:

En este caso la clase “CuentaBancaria” cuenta con un atributo “saldo”. En resumen, los atributos son las características de una clase.

3.3. Los Tipos de Dato Podemos encontrar la definición de atributo, mediante la cual definimos que un objeto tiene un conjunto de ”características” 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 número , 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 podría ser cualquier número de tipo entero.


Página 11


De la misma manera, un objeto Persona podría tener un atributo “Trabajo”, donde trabajo es también un objeto con sus propias características, es decir, el trabajo podría tener un empleador, un nombre, una ubicación, 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 trabajábamos 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 más, eso va a ser un nuevo tipo con el que podemos trabajar. De la misma manera si creamos un clase “Banco”, de ahora en más vamos a tener objetos que son instancias de la clase Banco, o también 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 más autoexplicativos sean los nombres, mejor). Las operaciones son, en el 99% de los casos, verbos. Las operaciones pueden admitir parámetros. Los parámetros son variables que utilizará la operación para generar cierto comportamiento. Las operaciones acelerar y frenar tienen como parámetros dos valores “int” (números enteros) que representan la velocidad y el tiempo que acelerará o frenará. Las operaciones de una clase “CuentaBancaria” podrían ser las siguientes:


Página 12


Las operaciones “depositar” y “extraer” tienen un solo parámetro, este parámetro 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 operación. 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 simbología es el signo +) y como “privado” (su simbología es el signo -) Que un atributo u operación sea privado significa que aquel atributo u operación solo puede ser accedido desde dentro del objeto que lo contiene. En cambio si este atributo u operación fuera público podría ser accedido por cualquier objeto. En el siguiente ejemplo podemos ver los miembros públicos 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é debería de tener un miembro privado?”. Hacer que un atributo sea


Página 13


privado se utiliza para tratar con datos o valores los cuales no queremos que sean accedidos más 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 podría resultar peligroso para la integridad del objeto contenedor). El porqué de utilizar miembros privados se aclarará a continuación junto con el tema “Encapsulamiento”. En resumen, la visibilidad determina el alcance (scope) del atributo u operación en cuestión

3.6. El Encapsulamiento El encapsulamiento es una de las características 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 operación pública que le permite interactuar con otros objetos. Esta operación recibe como parámetro un valor que representa la velocidad que se le quiere asignar a dicho automóvil. Si esta operación recibiera un valor negativo, podría pasarlo a un número positivo, mantener la velocidad anterior o hacer cualquier otra cosa evitando que aparezcan errores en el objeto por un dato inválido (velocidad negativa). Si en vez de utilizar un atributo privado y una operación pública, utilizáramos directamente un atributo público, este tipo de casos no podrían ser manejados y se atentaría contra la integridad del objeto. El ocultamiento puede visualizarse mejor en el siguiente gráfico:


Página 14


El grafico representa que los atributos están encerrados por operaciones, es decir que los atributos son privados y las operaciones son públicas. Esto significa que para poder acceder a un atributo es necesario utilizar una operación, es decir que no hay posible acceso al atributo sino no se utiliza una operación. A continuación se presenta el encapsulamiento con la clase “CuentaBancaria”:

Para poder modificar al atributo saldo, es necesario hacerlo a través 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 más de un constructor en una misma clase; en este caso, cada constructor debe aceptar parámetros distintos para poder así distinguirlos.


Página 15


Los constructores suelen llamarse con el mismo nombre de las clases, como se muestra a continuación:

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 parámetros. En resumen, un constructor es una operación que es invocada al instanciar una clase.

3.8. La Sobrecarga de Operaciones Así como es posible tener más de un constructor (que es una operación), es posible tener más de una operación 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 operación tenga distintos tipos de parámetros. ¿Para qué podría servir tener varias operaciones con el mismo nombre pero con distintos parámetros? Por ejemplo, si quisiéramos crear una operación llamada ”extraer()” que extraiga un determinado saldo de una cuenta, podríamos querer utilizarla sin determinar un tipo de moneda (utilizando la moneda del país como “por defecto”), o determinando un tipo de moneda para hacer la extracción de ese tipo de moneda (euro, dólar, etc). La sobrecarga de operaciones nos permite utilizar el mismo nombre de operación para dos operaciones distintas, es decir, que aceptan distintos parámetros y tienen distinta funcionalidad. Sin la existencia de este mecanismo, se debería crear una operación distinta por cada “versión” de nuestra operación. Sin la sobrecarga de operaciones, las operaciones están limitadas a los parámetros de una sola definición de operación.


Página 16


Si quisiéramos aplicar la sobrecarga de operaciones en una clase “Automovil”:

La operación “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 parámetro de tipo booleano En resumen, la sobrecarga de operaciones es la capacidad de poder crear comportamientos distintos para la misma operación aceptando distintos tipos de parámetros.

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 típico árbol de herencia simple:


Página 17


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 jerarquía 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


Página 18


incluso podemos agregar nuevos o modificar estos ya heredados. Con las clases heredadas ampliamos la descripción de un concepto de la vida real, lo volvemos más específico. Para comprender mejor la herencia y la naturaleza de las clases heredadas, es necesario entender que una clase hija es más específica conceptualmente que la clase padre, a la vez que la clase padre es más general conceptualmente que la clase hija. Esto lo podemos visualizar mejor de la siguiente manera:


Página 19


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é tendrían en común las clases “Avion” y “Motocicleta”? Que ambas clases tienen como superclase a la clase vehículo, es decir, ambas SON “Vehículo”. Es importante destacar que una clase ES UN cualquiera de sus superclases, es decir: “Motocicleta” ES UN “VehiculoTerrestre” y ES UN “Vehículo”, Con cada subclase, se amplia la cantidad de elementos de dicha clase con respecto a sus superclases, volviéndola más específica. Así, por ejemplo, la clase vehículo 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 sólido, y la clase “Automovil” hace referencia a un tipo de transporte específico. Podríamos ir más allá en el árbol de herencia y crear clases para cada modelo de automóvil y hacer que extiendan a la clase “Automovil”. Otro árbol de herencia podría 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 comúnmente 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 operación heredada de la clase padre.


Página 20


Esto significa que, en una clase padre conceptualmente más general, al tener un método al cual le dimos cierto comportamiento básico, que puede no ser exactamente lo que debe suceder al invocar ese método desde un objeto correspondiente a una clase hija, debemos sobrescribir esa operación en la clase hija con la funcionalidad o comportamiento apropiado. Si la clase hija no redefiniera ese comportamiento, el comportamiento sería el mismo de la clase padre (tras invocar a dicho método). Por lo cual, tendríamos una clase padre con la operación “hacerAlgo” que hace “x” cosa, y una clase hija con la operación “hacerAlgo” que hace “y” cosa., es decir que la misma operación tiene comportamientos distintos según la clase En el siguiente caso:

La clase “AutomovilDeCarrera” debe reemplazar el comportamiento de la operación “acelerar()” heredado de la clase “Automovil”, ya que el tipo de aceleración es completamente distinta. Lo mismo sucede con las siguientes clases:


Página 21


En este caso, las operaciones “extraer()” de ambas clases deben tener comportamientos distintos debido a que el límite 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 También llamados atributos estáticos, 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” podríamos declarar un atributo estático 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 estáticos.

En el diagrama anterior el atributo “descubierto” aparece subrayado, esto es lo que nos indica que es un atributo estático. Lo mismo sucedería para una clase “Automovil” con un atributo estático “velocidadMaxima”:

En resumen, los atributos de clase (o estáticos) 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.


Página 22


3.12. Operaciones de Clase También llamadas operaciones estáticas, son operaciones que corresponden a la clase y no a las instancias de dicha clase, es decir a los objetos. La explicación es análoga a la presentada en el tema anterior de atributos de clase. En los siguientes ejemplos se aplican operaciones estáticas:

Se debe observar que en ambas clases se dispone de un atributo estático y dos operaciones estáticas, y en este caso ambas operaciones estáticas se utilizan modificar los atributos estáticos. En resumen, las operaciones de clase (o estáticas) 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.


Página 23


4. Introducción 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 semántica •

Esta Unificado: unifica los distintos criterios utilizados antes de su

creación, es decir que toma las mejores propuestas de herramientas previas para presentar una propuesta sumamente abarcativa e integradora •

Permite Modelar: está basado en la construcción de modelos que

permite representar abstracciones de la realidad. UML esta estrechamente ligado con el paradigma de objetos, lo que permite construir sistemas de información de una forma mucho mas intuitiva, integrada y sencilla con el proceso de desarrollo. UML no es una metodología 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 unión de los “tres amigos”: Booch, Rumbaugh y Jacobson. En los años 80 cada uno utilizaba un lenguaje propietario aunque como denominador común tenían como objetivo el desarrollo de sistemas, con previa modelización. A partir de los años 90 comienzan a intercambiar ideas para intentar unificar criterios. Booch es el fundador de Rational Software Corp, y recluta en el año 1995 a Rumbaugh y Jacobson para comenzar a determinar una especificación genérica, sencilla y abarcativa.


Página 24


Así es como las grandes empresas de tecnologías de información – entre ellas Rational - deciden forman un consorcio para la construcción de un Lenguaje Unificado de Modelado: UML. La primer versión de UML, la 1.0, sale a la luz en el año 1997, y a partir de 1998 un organización llamada OMG (Object Management Group) se encargo de generar nuevas revisiones. En el año 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 tecnología de la información, como ser el modelado de un motor o de una turbina. En el campo de IT, se utiliza tanto para sistemas monolíticos como para sistemas distribuidos, abarca desde proyectos pequeños hasta grandes proyectos. Permite realizar la integración del software, donde representa el correcto enlace de los roles para lograr el éxito de la constricción del sistema. En proyectos de software, es utilizado desde la gestación hasta la instalación y el testing. Si bien para utilizar UML es posible realizar los distintos diagramas con papel y lápiz, es conveniente contar con alguna herramienta del tipo IDE que facilite su construcción, corrección e integración ente diagramas.


Página 25


5. Introducción a los diagramas de UML 5.1. Introducción UML esta organizado en una serie de diagramas que tienen objetivos bien definidos, con una sintaxis y semántica 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 estático, 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 fotografía o snapshot del sistema en un momento determinado. Esta compuesto por objetos y relaciones de enlace. También 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


Página 26


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 Comunicación El Diagrama de Comunicación tiene como objetivo describir como colaboran o se comunican los distintos objetos entre sí para conseguir un objetiv o. Se lo suele llamar también Diagrama de Colaboración. Es posible verlo como una extensión del Diagrama de Objetos, ya que es muy parecido pero tiene como valor agregado los mensajes que se envían entre los objetos. Esta compuesto por objetos, relaciones de enlace y relaciones del tipo llamadas, representando que objeto se comunica con que otro. Es semánticamente 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 Comunicación 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 semánticamente equivalente al Diagrama de Comunicación.

5.9. Diagrama de Componentes


Página 27


El Diagrama de Componentes tiene como objetivo describir la relación que existe entre los distintos componentes del sistema. Esta directamente vinculado con el diseño del sistema, permitiendo modelar las relaciones e interfaces que existen entre los componentes. Está orientado a la implementación 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 lógico, basándose en la organización del software, o desde una punto de vista físico, representando directamente cada unidad de hardware. Esta compuesto por nodos, componentes y sus relaciones.


Página 28


6. Clasificación de Diagramas 6.1. Categorías Es posible clasificar a los diagramas según si tienen alguna relación con el tiempo o no. Existen dos posibles categorías, los diagramas estáticos y los diagramas dinámicos.

6.2. Diagramas Estáticos Los Diagramas Estáticos Estáticos son aquellos que no tienen ninguna relación con el tiempo. Generalmente representan a estructuras o a posibles acciones pero sin una relación 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 Dinámicos Los Diagramas Dinámicos son Dinámicos son aquellos que tienen relación con el tiempo. Están directamente vinculados con acciones que ocurren bajo cierta secuencia, es decir primero una acción, luego otra, y así sucesivamente. Estos diagramas son: •

Diagrama de Actividades

•

Diagramas de Interacción (es una subcategoría, que incluye a los

Diagramas de Secuencia y Comunicación) •

Diagrama de Estado


Página 29


6.4. Diagramas Estructurales Los Diagramas Estructurales son aquellos que reflejan relaciones estáticas de una estructura. Estos diagramas son: •

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 características de comportamiento del sistema o modelan procesos de negocios. Estos diagramas son: •

Diagrama de Casos de Uso

•

Diagrama de Comunicación

•

Diagrama de Secuencia

•

Diagrama de Actividades

•

Diagrama de Estados


Página 30


7. Laboratorios 7.1. Consigna Los ejercicios serán realizados en forma grupal, en grupos de 4 o 5 personas, analizando un caso de estudio y armando una solución utilizando el pensamiento de objetos. El caso de estudio y su solución consisten en pensar e identificar cuáles son los objetos que tendríamos en nuestro sistema de gestión bancaria.

7.2. Caso de Estudio BancoMax es el primer banco privado del sistema financiero argentino en ahorro (depósitos más fondos comunes) y en volumen de crédito. La entidad cuenta con 276 sucursales, más de 2 millones de clientes (entre ellos más de 100 mil PyMEs y aproximadamente 1.100 empresas corporativas), tiene presencia en 20 provincias y en la Ciudad Autónoma de Buenos Aires. Es uno de los bancos líderes en medios de pago, en comercio exterior, servicios transaccionales y cash management a través de la gestión de cuentas comerciales de caja de ahorro y cuentas corrientes. Y también uno de los principales protagonistas en los mercados bursátiles, de títulos públicos y cambiarios. El Banco desarrolla asimismo un amplio programa de responsabilidad social corporativa, focalizado en la educación superior y que incluye también proyectos para generación de empleo. Estas acciones están en línea con lo que BancoMax realiza en las comunidades en donde está presente. De acuerdo a su estructura de organización, BancoMax cuenta con una jerarquía bien definida de cadena de mando, con un director general, un director por región 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 también una posición de liderazgo en el Reino Unido y Latinoamérica. Es uno de los principales grupos financieros del mundo, logrando este lugar gracias a su calidad de servicios, innovación, dinamismo, disciplina y visión global. Con más de 11.000 sucursales, BancoMax es el grupo financiero con más sucursales en todo el mundo.


Página 31


7.3. Ejercicio #1 – Detección de Clases Identificar las clases iniciales y necesarias para construir un sistema de gestión bancaria TIP: las clases se detectan como sustantivos en singular


Página 32


7.4. Ejercicio #2 – Detección 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 características de una clase Pregunta: en que clase ubicarías los siguientes atributos? 

cantidadDeEmpleados



numeroDeCuenta



edad


Página 33


7.5. Ejercicio #3 – Detección 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 ubicarías las siguientes operaciones ? 

informarSaldo()



informarSucursales()



informarClientes()



depositarDinero(monto)



informarDatosDeCuenta(nroDeCuenta)


Página 34


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.


Página 35


7.7. Ejercicio #5 – Relaciones Múltiples A partir de las clases detectadas previamente, identifique las relaciones múltiples que existen entre las mismas. Para este ejercicio, asumiremos que un cliente corporativo puede tener más de una cuenta corriente.


Página 36


7.8. Ejercicio #6 – Uso de Objetos Asumiendo que un cliente individual utiliza el cajero automático para realizar un depósito de $2500, ingresa su DNI número 27.014.589 como pin y realiza el depósito. El código 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 extracción 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 máximo 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 extracción o un pago, puede utilizar automáticamente hasta $5.000 Realizar

el

código

en

forma

genérica

utilizando

las

clases

Programa,

ClienteCorporativo y CuentaCorriente.


Página 37


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.


Página 38


8. Diapositivas


Página 39



Página 40



Página 41



Página 42



Página 43



Página 44



Página 45



Página 46



Página 47



Página 48



Página 49



Página 50



Página 51



Página 52



Página 53



Página 54



Página 55



Página 56



Página 57



Página 58



Página 59



Página 60



Página 61



Página 62



Página 63



Página 64



Página 65



Página 66



Página 67



Página 68



Página 69



Página 70



Página 71



Página 72



Página 73



Página 74



Página 75



Página 76



Página 77



Página 78



Página 79



Página 80



Página 81



Página 82



Página 83



Página 84



Página 85



Página 86



Página 87



Página 88



Página 89



Página 90



Página 91



Página 92



Página 93



Página 94



Página 95



Página 96



Página 97



Página 98



Página 99



Página 100



Página 101



Página 102



Página 103



Página 104



Página 105



Página 106



Página 107

Manual de programacion orientada a Objetos

Recommend Documents