Universidad Rafael Landvar

Facultad de Ingeniera

tica y Sistemas
Ingeniera en Informa

n
Bases de Programacio
Orientada a Objetos y UML
lisis y Disen
o II
Ana
Ing. Dhaby Eugenio Xiloj C.
Mayo de 2014

Este obra est

a bajo una licencia de Creative Commons
Reconocimiento-CompartirIgual 4.0 Internacional.

Resumen
Conocer el termino Programaci
on Orientada a Objetos no es suficiente para poder decir
que podemos desenvolvernos adecuadamente al querer trabajar programas extensos y de
gran calidad, se requiere conocer todas las interioridades que involucra la palabra objeto y
las interacciones que pueden llegar a tener para poder estructurar de manera adecuada una
aplicacion que resuelva los problemas de la forma mas simple y clara.
Tomando en cuenta que todos las aplicaciones necesitaran uno o mas cambios a lo largo
del tiempo, la estructura e interaccion de sus elementos debe estar preparada para poder
proveer de manera simple la capacidad de agregar nuevas caractersticas o bien ser usado
como parte de otra aplicaci
on mas grande sin muchos cambios.
Por ello este peque
no artculo de apoyo va dirigido a alumnos universitarios que deseen reforzar sus conocimientos b
asicos de POO aunado a la ayuda visual que proveen los diagramas
UML sin pretender ser una gua profunda del tema.

1.

Conceptos

Al trabajar con la Programacion Orientada a Objetos nos encontramos con una serie de terminos que son necesarios conocer, ya que de esta manera podremos comunicar de mejor manera
nuestras ideas y comprender mucho mas facilmente a programadores experimentados cuando entablemos conversaciones para dise
nar una aplicacion.

1.1.

Objeto

Es una unidad, que contiene datos (propiedades) y tareas (metodos) realizables los cuales son
utilizables durante la ejecucion de un programa.
Cada objeto dentro de un programa es distinto, aunque tenga las mismas propiedades y metodos
que otro objeto, se diferenciara por que podra manipular el contenido de sus propiedades por medio
de sus propios metodos. Un metodo, aunque sea com
un para varios objetos, solo podra acceder a
las propiedades de s mismo.

1.2.

Clase

Una clase no es mas que una plantilla, que indica las caractersticas que puede tener un objeto,
mas no indica el contenido explcito de cada objeto.
Cuando un objeto es creado a partir de una clase se denomina instancia, por lo que se dice
que un objeto instancia una clase cuando este objeto reserva un espacio en memoria, conteniendo
dentro de este espacio de memoria una estructura definida por la clase de la cual se instanci
o.

1.3.

Encapsulaci
on

Para entender el encapsulamiento se puede hacer una analoga a una capsula con medicamento,
la cual en su interior tiene un contenido qumico, para el cual el paciente no necesita realmente
conocer la composicion (propiedades) y sera utilizada para curar (metodo) alg
un malestar.
Al pasar la analoga al campo de la programacion, el encapsulamiento se refiere a la accion
de ocultar propiedades o metodos de un objeto a otros objetos dentro de una aplicacion, dejando
generalmente los metodos necesarios para su uso, proveyendo de esta manera una forma simple de
utilizar la informacion, sin entrar en detalles de como este trata su informacion.
Al encapsular los elementos de una clase se debe poder definir como se accedera a los mismos,
para ello existen tres modificadores de acceso o ambito que pueden ser utilizados: P
ublico, Privado
y Protegido.

Acceso
En el mismo objeto
En otro objeto

Modificadores de acceso
P
ublico Protegido Privado





Tabla 1: Modificadores de Acceso en Objetos

Para comprender como estos elementos son alterados cuando se aplica un modificador debemos
comprender primero los principios de herencia, los cuales se profundizaran en la seccion Herencia,
pero para comenzar podemos decir que cualquier objeto puede acceder a sus propios elementos,

pero solamente podra acceder a los elementos de otro objeto si estos son p
ublicos, como podemos
ver en la Tabla 1.

1.4.

Abstracci
on de datos

Si la instanciacion se refiere a cuando un objeto hace uso de la estructura de una clase, la

abstraccion se refiere a la accion opuesta; un conjunto de objetos, con propiedades iguales pueden
ser utilizados para abstraer la informacion y crear una clase.

2.

UML b
asico

UML o Lenguaje Unificado de Modelado, es una herramienta utilizada y estandarizada para

comunicar las ideas entre dise
nadores de software, sin tener que recurrir a codigo o pseudocodigo.
Existen varios tipos de diagramas estandarizados en el UML, pero existen dos tipos de diagramas que seran basicos para comprender la programacion orientada a objetos, los diagramas de
clase y los diagramas de secuencia.

2.1.

Diagramas de clase

Este tipo de diagrama permite expresar de manera simple la estructura de una clase e indicar
cuales son sus relaciones.
Para graficar una clase se hace uso de una caja dividida en tres secciones, con el nombre de la
clase, los atributos y por u
ltimo los metodos. Vea la Figura 1.

Figura 1: Diagrama de clase usando UML

Al inicio de cada elemento de la clase se puede apreciar un smbolo, el cual indicara el modificador de acceso que este tiene; si se sigue el estandar, los smbolos que se deben utilizar son los
siguientes, dependiendo del acceso:
Acceso
P
ublico
Privado
Protegido

Smbolo
+
#

Tabla 2: Simbologa para modificadores de acceso

2.2.

Diagramas de secuencia

Es utilizado para modelar la interaccion entre objetos dentro de una aplicacion, siendo de
mucha utilidad para entender como un objeto se comunicara con otro, ya sea instanciado de la
misma o de otra clase.
/noob:Usuario

/cool:Troll

/admin:Administrador

hola()

Respuesta a hola

preguntar()

molestar

reportar (troll)

accion (patear)

:(
gracias
comunicar (respuesta)

:)

Figura 2: Diagrama de secuencia con tres objetos,

un usuario, un troll y un administrador.
El diagrama es bastante simple, consta de los objetos, colocados en la parte superior del diagrama, los cuales deben tener una barra vertical o lnea de tiempo, que indica cuando se encuentra
en ejecucion alg
un objeto. Por lo general tendra una etiqueta con la sintaxis /objeto:clase, que
corresponde al nombre de una instancia de una clase especfica, como ejemplo se puede observar
la Figura 2 que existe un objeto noob instanciado de la clase Usuario.
La interaccion se representa por medio de flechas, que van de una a otra lnea de tiempo, las
lneas pueden ser de dos tipos, punteadas y solidas, la diferencia radica en si son para indicar una
llamada (solidas) o bien para devolver un resultado (punteadas). Las lneas pueden tener flechas de
distinto tipo en uno de sus extremos, una flecha solida indica una llamada sncrona, lo que quiere
decir que esperara una respuesta del otro objeto, una flecha vaca indicara una llamada asncrona,
lo cual indica que ya no espera respuesta del otro objeto.
Un ejemplo claro de como se ve un diagrama de secuencia se puede ver en la Figura 2, donde se
puede apreciar como, en un entorno de alguna pagina web un objeto usuario interact
ua con otro
personaje realizando una pregunta, sin saber que es un troll, pero luego de obtener la respuesta
4

molesta lo reporta al administrador, quien pone en orden al troll.

Se debe tomar en cuenta las direcciones de las flechas para la correcta interpretacion, por
ejemplo en la primera ejecucion, el objeto noob realiza una llamada a un metodo hola() que es
un metodo del objeto cool. Las flechas de respuesta generalmente sera el mensaje de retorno del
metodo llamado.

3.

Programaci
on Orientada a Objetos

Para conocer a fondo la programacion orientada a objetos debemos conocer tres terminos
importantes, herencia, agregacion y composicion.

3.1.

Herencia

La herencia, al igual que en genetica, es la capacidad de pasar las caractersticas de una clase
a otra con la que esta relacionada, pudiendo agregarle o quitarle elementos para definirse como
otra clase; hay que tomar en cuenta que la herencia solamente se aplica para clases, no as para
objetos, ya que estos solamente toman la estructura de una clase para asignarle valores, mas no
pueden cambiar su estructura.
En UML la herencia entre una clase y otra se representa con una lnea y una flecha con punta
vaca, tal como se observa en la Figura 3, donde la clase padre, en este caso es Usuario y la clase
heredada es Troll. La direccion de la flecha siempre indicara la clase padre.

Figura 3: Herencia de una clase usuario a una clase troll

La clase Troll en la Figura 3 heredara todos los elementos de la clase Usuario por lo que los
metodos pedirAyuda y guardarRespuesta siguen estando presentes y seguiran teniendo el mismo
codigo contenido en la clase padre.
3.1.1.

Elementos est
aticos

Si una propiedad es declarada como estatica, indica que su contenido sera el mismo para todos
los objetos que sean instanciados de la misma clase, as si un objeto cambia el valor de esta variable,
todos los objetos hermanos podran ver los cambios.
Cuando se aplica el mismo mecanismo a un metodo, indica que este se puede utilizar desde la
clase, sin que sea necesario instanciar un objeto para poder llamarlo, por lo que si debe alterar
valores en propiedades, solamente lo podra realizar en propiedades estaticas.
Cuando se debe declarar cualquier elemento como estatico, propiedad o metodo, este debe de
estar subrayado y de esta manera se sabe que es estatico.
3.1.2.

Redefinir (Override)

Tambien es conocido como anulacion, es otro de los terminos que se utilizan con bastante
regularidad, cuando se aplica a metodos que vienen heredados de una clase padre, como el metodo
hola en la clase Troll en la Figura 3, implica que se esta reescribiendo el codigo de este metodo,
ya sea agregandole funcionalidades o reemplazandolo completamente.
Dependiendo del lenguaje y sus restricciones, es posible cambiar el modificador de acceso de los
elementos, pudiendo hacer mas visibles tanto propiedades como metodos a partir de esta clase, tal
como el metodo hola en la clase Troll o bien el atributo nombre en la Figura 3. Algunos lenguajes
prohben estas practicas, por lo que hay que conocer el lenguaje al cual se pretende aplicar la
redefinicion.
3.1.3.

Sobrecarga (Overloading)

La sobrecarga es un mecanismo implementado en los lenguajes de programacion, que permite

a un metodo tener varias formas, tambien conocido como el principio de polimorfismo,
3.1.4.

Modificadores de acceso

Cuando se trabaja con clases, los modificadores de acceso pueden tener otras caractersticas
mas que las consideradas en la Tabla 1 ya que ahora tendremos clases que heredan metodos o
propiedades.

Acceso a datos
De la misma clase
De una clase Padre
De otra clase

Modificadores de acceso
P
ublico Protegido Privado







Tabla 3: Modificadores de Acceso en Clases

La Tabla 3 indica en la primera columna las clases que intentan acceder a elementos con
distintos tipos de modificadores de acceso, pudiendo verse la diferencia entre el acceso de una
6

clase padre, donde una clase heredada puede acceder solamente a los datos p
ublicos y protegidos,
pero no as a los privados; una clase padre no puede acceder a los datos de una clase heredada
directamente y sera tratada como un objeto de otra clase, por lo que el acceso no es bidireccional.
3.1.5.

Casting o conversi
on

El casting o conversion de datos es una de las formas en que la POO permite a las clases padres
hacer uso de metodos o propiedades de clases hijas, para ello cada lenguaje aporta funciones o
bien operadores que permiten realizar esta accion; utilizando las clases de la Figura 3 y con java
podemos realizar lo siguiente:
1
2
3
4
5
6
7
8

T r o l l elTroll = new T r o l l ();

elTroll . edad =15;
elTroll . nombre = " cool " ;
// inicia el casting
Usuario elNoob = ( Usuario ) elTroll ;
/* elNoob utiliza el metodo hola ()
de elTroll */
elNoob . hola ();

Codigo 1: Casting en Java

Aunque en el Codigo 1, en la lnea 8, el objeto elNoob es de tipo Usuario, el metodo que
ejecutara sera el de la clase Troll, ya que esta clase ha redefinido (override) el metodo en cuestion.
3.1.6.

Generalizaci
on

En clases heredadas que contienen los elementos de las clases padre, se dice que estas generalizan
la clase padre, por lo que en muchos textos se le conoce como una relacion IS-A, que puede
traducirse al espa
nol como es de tipo; si vemos de nuevo la Figura 3 podemos decir que Troll
IS-A Usuario o bien que Troll es de tipoUsuario, de esta manera la clase Troll generaliza la
clase Usuario.

3.2.

Asociaci
on

La asociacion de clases es una forma de explicar, que una clase debe contener un objeto de
determinada clase, para diagramarlo se usa una simple lnea que une ambas clases, en cada extremo
se coloca la multiplicidad de la relacion que indica la cantidad de elementos que pude contener.
Una linea de asociacion con una flecha en un extremo indica que la asociacion solo es en un
sentido, por lo que la clase donde se encuentra la flecha no tendra ning
un elemento que la vincule
con la clase desde donde se origina la flecha.
pertenece a

+ Jugador
1..*

+ Equipo

tiene

+ Partido

1..2

+jugadores

+rivales

#equipo

Figura 4: Asociacion entre clases

+juego

En la Figura 4 se puede ver como un equipo puede tener uno o mas jugadores y un jugador
puede estar en un equipo; mientras que para un partido solamente se podra tener de 1 a 2 equipos,
suponiendo que un equipo no se presente. La diferencia entre cada una de las clases puede no
verse tan facilmente en el diagrama, pero podemos ver un ejemplo en el Codigo 2 y entender como
ambos tipos de asociaciones funcionan.
1
2
3

p u b l i c c l a s s Jugador {
protected Equipo equipo ;
}

4
5
6
7
8
9
10
11

p u b l i c c l a s s Equipo {
/* *
*
* @element - type Jugador
*/
p u b l i c Vector jugadores ;
}

12
13
14
15
16
17
18
19

p u b l i c c l a s s Partido {
/* *
*
* @element - type Equipo
*/
p u b l i c Vector rivales ;
}

Codigo 2: Asociacion de clases en Java

3.3.

Agregaci
on

La agregacion, tambien conocida como acumulacion, es un termino bastante utilizado en el

dise
no de patrones, junto con el termino composicion, ambos son muy parecidos en estructura
pero difieren grandemente en como se deben interpretar, ambas son asociaciones pero especifican
mucho mejor la dependencia entre cada clase. Al usar una agregacion entre clases, solamente
deberemos utilizar un rombo en uno e los extremos de una lnea de asociacion, lo que indicara que
la clase que tiene el rombo agregara la clase que se encuentra en el otro extremo.
En la Figura 5 se puede ver como varias clases son agregadas a la clase Acuario, la cual
contendra una lista de cada uno de los objetos pertenecientes a las clases agregadas. Todas las
clases agregadas tienen una forma de referenciar a la clase Acuario, excepto la clase Agua, ya que
su relacion es unidreccional.

3.4.

Composici
on

La composicion vara respecto a la agregacion indicando que la relacion entre los objetos es mas
fuerte, esto quiere decir que las clases vinculadas no pueden existir por separado; en otras palabras
la clase que se encuentra compuesta de las otras clases no podra existir si no tiene objetos de las
clases que la componen.
En la Figura 6 se puede observar como la clase Silla esta compuesta por las clases Respaldo
y Patas; si se instancia un objeto de la clase Silla, este debera tener un objeto instanciado de
8

+ Acuario

+ Alga

1
1..*
+ Filtro
+ Agua

+ Pez

Figura 5: Agregacion de clases

+ Respaldo

+ Silla
1

+ Patas
1

Figura 6: Composicion de clases

Respaldo y cuatro de Patas, al momento de que el objeto instanciado de Silla sea eliminado, los
objetos que lo componen tambien seran eliminados y viceversa.

3.5.

Interfaces

Una interfaz dicta la estructura que debe tener una clase, al igual que una clase lo hace con un
objeto, por lo que una interfaz no puede instanciar un objeto, lo que si puede hacer es realizar
una clase. Comprendiendo esto, se debe de tener en cuenta que una interfaz no tendra nunca
propiedades, ya que estas las define la clase que realice la implementacion.
Cabe destacar que una interfaz tambien tiene la capacidad de poder heredar su estructura a
otras interfaces, como si de clases se tratasen, lo que incrementa su flexibilidad.
interface
+ Animal

+ PatoPlastico

realize

interface
+ Pato

Figura 7: Intrfaces: herencia y realizacion

3.6.

Clases abstractas

Una clase abstracta comparte caractersticas de una interfaz y una clase com
un, una clase
abstracta no puede instanciar objetos, tiene la capacidad de heredar su estructura a otras clases y
puede definir propiedades ademas de metodos con codigo definido o bien abstractos, que permiten
que las instancias definan su propio funcionamiento.

10