Notas de Clase Pai2

1 INTRODUCCION
2009-I, Versin 4(20 de Marzo)

Modelado, hilos, Sockets y RMI | Camilo Andrs Ferrer Bustos
EAM
NOTAS DE CLASE PROGRAMACION
AVANZADA I
2 INTRODUCCION

CAPITULO I: ANALISIS Y DISEO
ORIENTADO A OBJETOS.

INTRODUCCION
Uno de las principales metas de la programacin orientada a objetos es modelar sistemas del
mundo real tal y de una forma similar en la que la gente piensa. Las entidades u objetos del
modelo pensado se abstraen en lo que se denominan clases. Una clase es una abstraccin de
un objeto del mundo real en la cual se encapsulan los datos y el comportamiento del objeto en
cuestin as como las relaciones de los otros objetos presentes en el modelo. Estas
interacciones deben comportarse de manera similar que aquellas del mundo real, por esta
razn los diseadores y programadores deben hacer hincapi en que las clases que
construyan garanticen este comportamiento.
Este captulo pretende mostrar los pasos mnimos que se deben tomar antes de empezar con
la etapa de implementacin de un sistema del mundo real, as como algunas prcticas sanas
en el proceso de modelado orientado a objetos. Tambin se introducir el modelado de
sistemas usando el mtodo de notacin UML (Unified modelling Lenguage).

GUIA DE DISEO ORIENTADO A OBJETOS
Antes de empezar el proceso de programacin de una solucin basada en software es
necesario seguir una metodologa de diseo la cual nos lleve a entender el problema a
solucionar y sobre todo saber exactamente lo que se debe hacer en el proceso de codificacin.
El proceso de diseo es un proceso iterativo el cual tiene como objetivo que en cada iteracin
del proceso el mismo sea ms preciso y vislumbre de manera ms clara una solucin ptima al
dicho problema a solucionar. Metodologas hay muchas, pero la mayora siguen ciertos pasos
mnimos que son:

Anlisis del problema
El primer paso para resolver un problema con la metodologa orientada a objetos es analizar el
problema en cuestin. En esta etapa el desarrollador y el usuario final de la solucin deben
tener una comunicacin intensa la cual debe llevar al encargado de solucionar el problema
entenderlo a cabalidad teniendo en cuenta los deseos y necesidades del cliente. En esta etapa
no se debe pensar en la solucin del problema sino meramente en entender lo que piensa
hacer.
2009-I, Versin 4(20 de Marzo) NOTAS DE CLASE PROGRAMACION AVANZADA I

Definicin de los requerimientos. 3

Definicin de los requerimientos.
Los requerimientos definen lo que el usuario quiere que el sistema haga. Estos requerimientos
deben expresar las necesidades del cliente. En la etapa de anlisis los requerimientos pueden
llegar a ser la parte ms importante y la solucin final debe cumplir cada uno de los
requerimientos para estar completamente terminada.

Desarrollo de un prototipo de la interfaz de usuario
Una de las mejoras cosas que pueden asegurar que los usuarios y desarrolladores estn
entendiendo el sistema es crear un prototipo. U prototipo puede ser cualquier cosa, pero una
aproximacin podra ser el diseo de la interfaz de usuario al crear las ventanas y como fluyen
unas con otras. Esto podra dar una idea de cmo el sistema lucir y cmo ser la interaccin
con el usuario. Cualquier prototipo creado no debe contemplar ninguna funcionalidad final. En
el diseo de la interfaz de usuario deben aplicarse principios de usabilidad los cuales permitan
una interaccin ms natural entre el usuario final y la solucin diseada.

Identificacin De Las Clases.
Ya definidos los requerimientos del sistema se puede seguir identificando las clases del mismo.
Una manera fcil de identificar las clases es tomar los requerimientos e identificar los
sustantivos. Se pueden subrayar todos los sustantivos presentes en los requerimientos y luego
de un anlisis posterior se pueden filtrar los sustantivos innecesarios hasta llegar un conjunto
mejor definido. Hay que recordar que el proceso de diseo es iterativo y en dicho proceso se
puede aadir o eliminar clases segn sea la necesidad.

Determinar Las Responsabilidades De Cada Clase.
Ya determinadas las clases es necesario asignarles responsabilidades entre las cuales se
encuentran que datos va almacenar y cules son las operaciones sobre dichos datos.

Determinar Como Las Clases Se Colaboran Unas A Otras.
Las clases no existen en el modelo aisladamente. Como en los sistemas del mundo real, las
entidades del modelo deben interactuar entre ellas para reflejar el comportamiento del
sistema que modelan. El medio por el cual las clases se comunican entre s es envindose
mensajes.

Camilo Andrs Ferrer Bustos
CAPITULO I: ANALISIS Y DISEO ORIENTADO A OBJETOS.

4 Caso de estudio I: JUEGO DE BLACK JACK. | EAM

Crear Un Modelo De Clases Para Describir El Sistema.
Cuando todas las clases estn determinadas juntos con sus responsabilidades y
colaboraciones, se puede usar una notacin para representar toda esta informacin de
manera ms grafica. Una notacin muy utilizada para este fin es el UML el cual es un medio
muy eficiente para representar las clases de un modelo.

Caso de estudio I: JUEGO DE BLACK JACK.
El resto de este captulo se enfocara en aplicar los conceptos anteriores a travs de ejemplos o
casos de estudio. El primer caso de estudio ser un juego de BLACK JACK. Lo primero que se
debe entender es el problema el cual esta a continuacin:
Se desea implementar un juego de BLACK JACK. En el Black Jack varios jugadores juegan
contra un Dealer o casa.
Desde la perspectiva del jugador, el objetivo del juego tomar cartas de un mazo de cartas hasta
que la suma de las cartas de 21 o lo ms cercano posible sin exceder este valor. El Dealer
juega solo con los jugadores, baraja las cartas, da cartas a los jugadores, muestra las manos,
calcula el valor de una mano y cuantas cartas posee, determinar el ganador , recibir una
apuesta de un jugador, pagar apuesta al ganador y empezar un nuevo juego.
Una carta tiene un valor y una pinta y debe ser capaz de reportar ese valor aunque para este
juego en particular la pinta no tiene importancia. Todas las cartas deben ser miembros de un
mazo de cartas. El mazo debe tener la posibilidad de barajar las cartas, dar la siguiente carta y
reportar cuantas cartas quedan en el mazo. El rey, prncipe y la reina valen 10 y el as vale 1 u
once. Las otras cartas.
Durante el juego un jugador puede pedir una carta para aadir a su mano. El jugador debe
mostrar, calcular el valor y las cartas de su mano. Cuando el Dealer pida empezar otra mano,
el jugador debe responder. Adems el jugador posee una cantidad de dinero que apostar.
las reglas del juego contemplan que si la suma de una mano de un jugador suma 21 o llega los
ms cerca posible gana 3:2 de la apuesta hecha, pero si esa suma excede el 21 la apuesta se
pierde. Si el Dealer y el jugador quedan empate y excede la suma en 17 hay empate y el
jugador se queda con su apuesta. Al principio del juego los jugadores deben hacer su apuesta.
Cuando el Dealer recibe apuestas, debe saber de quin vienen y cuanto es el valor de la
misma.

Identificar Clases.
Como primera medida se identificaran las clases presentes en el enunciado del problema. Una
tcnica fcil es tomar el enunciado y resaltar los sustantivos que en ella se encuentran. Hay
que recordar que este es un proceso iterativo en el cual las primeras clases que se identifiquen
puedan no sobrevivir al proceso y otras nuevas aparecer.
A continuacin se muestran los sustantivos del problema:


Identificar Clases. 5

Se desea implementar un juego de BLACK JACK. En el Black Jack varios jugadores juegan
contra un Dealer o casa.
Desde la perspectiva del jugador, el objetivo del juego tomar cartas de un mazo de cartas hasta
que la suma de las cartas de 21 o lo ms cercano posible sin exceder este valor. El Dealer
juega solo con los jugadores, baraja las cartas, da cartas a los jugadores, muestra las manos,
calcula el valor de una mano y cuantas cartas posee, determinar el ganador , recibir una
apuesta de un jugador, pagar apuesta al ganador y empezar un nuevo juego.
Una carta tiene un valor y una pinta y debe ser capaz de reportar ese valor aunque para este
juego en particular la pinta no tiene importancia. Todas las cartas deben ser miembros de un
mazo de cartas. El mazo debe tener la posibilidad de barajar las cartas, dar la siguiente carta y
reportar cuantas cartas quedan en el mazo. El rey, prncipe y la reina valen 10 y el as vale 1 u
once. Las otras cartas.
Durante el juego un jugador puede pedir una carta para aadir a su mano. El jugador debe
mostrar, calcular el valor y las cartas de su mano. Cuando el Dealer pida empezar otra mano,
el jugador debe responder. Adems el jugador posee una cantidad de dinero que apostar.
las reglas del juego contemplan que si la suma de una mano de un jugador suma 21 o llega los
ms cerca posible gana 3:2 de la apuesta hecha, pero si esa suma excede el 21 la apuesta se
pierde. Si el Dealer y el jugador quedan empate y excede la suma en 17 hay empate y el
jugador se queda con su apuesta. Al principio del juego los jugadores deben hacer su apuesta.
Cuando el dealer recibe apuestas, debe saber de quin vienen y cuanto es el valor de la
misma.
Los sustantivos encontrados son:
Jugadores jugador Dealer Cartas
Mazo Mano Carta apuesta
rey reina prncipe As
ganador Black Jack pinta casa

Lo que sigue es determinar cul de estas clases deben sobrevivir para eso hay que analizarlas
una a una.
Jugador: es uno de los actores principales del juego, es obvia su permanencia en el modelo.
Jugadores: son varias instancias de jugador. No es necesario ya que jugador est definido.
Dealer: tambin es un actor principal, no se puede hacer nada sin el Dealer.
Cartas: pasa lo mismo que entre jugador y jugadores.
Carta: este es un juego de cartas, tambin es esencial la permanencia de esta clase.
Casa: es el mismo Dealer.


Mazo: muchas de las tareas del juego necesitan el mazo, es por eso que es necesaria esta
clase.
Pinta: la pinta es un atributo de una carta al igual que el valor.

Black Jack: es el juego en s.
Ganador: es un jugador.
Reina, Prncipe, as: son tipos de cartas.
Mano: el jugador juega sobre una mano lo que hace que esta entidad sea de gran utilidad.
Apuesta: es lo que apuesta el jugador. Esto est presente en el juego y por eso debe ser otra
clase del modelo.
Este anlisis deja seis clases sobrevivientes:

Jugador Mazo Mano
Dealer Apuesta Carta

Identificar Responsabilidades.
Ya con las clases identificadas hay que determinar que debe hacer cada una de las clases. Un
mtodo fcil para determinar las responsabilidades de una clase es mirando los verbos del
enunciado del problema o de los requerimientos.
Hay que tener en cuenta ciertos aspectos para determinar responsabilidades:
No todos los verbos llegan a ser responsabilidades.
Si varias clases comparten la misma responsabilidad, ambas son responsables de
dicha responsabilidad.
Debido a la naturaleza iterativa del proceso de diseo, hay que revisar si faltan o
sobran responsabilidades.
A continuacin se toma cada clase y leyendo el enunciado del problema se establecen los
verbos asociados a ella.


Identificar Responsabilidades. 7

Carta.
Dar el valor
Dar la pinta
Saber si es un comodn
Saber si es un as
Mazo.
Barajar
Dar una carta
Determinar el nmero de cartas en el mazo
Mano
Saber cuntas cartas hay en la mano.
Saber el valor de la mano
Mostrar la mano.
Dealer
Dar una carta
Barajar el mazo
Mostrar la mano de un jugador
Calcular el valor de la mano de un jugador
Saber el nmero de cartas en la mano del Dealer
Pedir una carta
Determinar el ganador
Empezar una mano
Recibir apuestas
Pagar premio

Jugador
Pedir una carta al dealer
Mostrar la mano
Calcular el valor de su mano
Saber cuntas cartas hay en la mano
Saber si hay Black Jack
Saber si se perdi.
Hacer una apuesta.
Recibir premio



Apuesta
Saber el valor de la apuesta.
Saber el jugador que hizo la apuesta.

En general, una clase debe ser responsable de administrar sus propios atributos ya sea dando a
conocer su valor o cambiando el valor del mismo.

Para identificar las colaboraciones entre las clases del modelo se necesita tener muy claras las
responsabilidades de las mismas y para as determinar cmo las clases interactan entre ellas,
lo que se puede resumir respondiendo la siguiente pregunta: Qu otras clases necesita este
objeto para cumplir todas sus responsabilidades y hacer su trabajo completo? En este proceso
se puede llegar a la conclusin que faltan clases o sobran clases para que el modelo quede lo
mejor expresado posible.
Una manera muy til de determinar las colaboraciones entre las clases del modelo es
identificar en el enunciado del problema las interacciones que hay entre los diferentes actores
del mismo y luego determinar que operaciones deben llevarse a cabo para completar dicha
interaccin. Veamos lo anterior aplicado a nuestro caso de estudio:
1. El Dealer Inicia el juego
2. Dealer Baraja el mazo
3. Jugador hace apuestas
4. El dealer toma una carta del Mazo
5. El Dealer reparte las cartas inciales
6. El jugador aade cartas a su mano
7. El dealer aade cartas a su mano
8. La mano informa al jugador su valor
9. La mano retorna al dealer su valor
10. El dealer pide el jugador si desea jugar ms
11. El dealer reparte otra carta al jugador
12. Dealer pregunta al jugador si quiere otra carta
13. Dealer pide al jugador el valor de su mano
14. El Dealer pide o enva apuestas
15. El jugador enva apuestas al Dealer

Examinando estas oraciones se pueden establecer que clases colaboran entre si y como lo
hacen. Lo que sigue es determinar qu pasos son necesarios para lo anterior sea posible.


Determinar Como Las Clases Se Colaboran Unas A Otras. 9

Inicio del Juego.

Tomar una Carta del Mazo

El Dealer pide al jugador el valor de su mano

Dealer
barajarMazo
Mazo
Dealer
reiniciarMazo
Mazo
Dealer
darCarta
Jugador
Dealer
pedirCarta
Mazo
RetornarCarta
Dealer
pedirValorMano
Jugador
Jugador
pedirValorMano
Mano
darValorMano
Dealer Jugador
darValorMano


Ya que estn determinadas todas las operaciones que se llevan a cabo por todas las entidades
del sistema se puede pensar es crear un representacin grafica del mismo en l cual se expresen
las relaciones entre las entidades del mismo. Antes de eso, es necesario tener claro cules son
las relaciones entre las clases de un modelo y como se expresa en notacin UML. UML define
muchos tipos de diagramas para representar muchos aspectos en el desarrollo de la solucin.
El diagrama a usar en el modelado Orientado a objetos es el diagrama de clases.
Un diagrama de clases es el principal diagrama en el diseo orientado a objetos y su
importancia yace en el hecho que contiene los elementos principales que tendr el cdigo de
la aplicacin que en nuestro caso en particular sern las clases de Java. Un diagrama de clases
es aquel que contiene todos los objetos y las relaciones entre ellos

Relaciones entre clases
Un conjunto de objetos aislados tiene escasa capacidad para resolver un problema. En una
Aplicacin til los objetos colaboran e intercambian informacin, mantienen distintos tipos de
relaciones entre ellos.
A nivel de diseo, podemos distinguir entre 5 tipos de relaciones bsicas entre clases de
objetos: asociacin, agregacin, composicin y herencia
1
Asociacin

Como los objetos por lo general se necesitan los unos a los otros para cumplir con su tarea,
deben estar estrechamente relacionados. Una de las ms importantes relaciones es la
asociacin. Los objetos que estn relacionados se cooperan envindose mensajes.
La asociacin es la relacin ms importante y ms comn. Refleja una relacin entre
dos clases independientes que se mantiene durante la vida de los objetos de dichas clases o al
menos durante un tiempo prolongado En UML suele indicarse el nombre de la relacin, el
sentido de dicha relacin y las cardinalidades en los dos extremos.

El nombre de la relacin es titular el (* 1) indica que varias cuentas se pueden asociar
a un cliente.

1
Tema tratado ms adelante.

Crear Un Modelo De Clases Para Describir El Sistema. 11

Relacin de muchos a muchos. Un estudiante puede tener varios tutores y un tutor varios
estudiantes.

Asociacin recursiva: una madre puede tener
varios hijos que tambin son personas.

Una asociacin se implementa en Java introduciendo referencias a objetos de la clase destino
de la relacin como atributos de la clase origen Si la relacin tiene una cardinalidad superior a
uno entonces ser necesario utilizar un array o una estructura de datos dinmica del paquete
java.util como Vector o LinkedList. Normalmente la conexin entre los objetos se realiza
recibiendo la referencia de uno de ellos en el constructor u otra operacin similar.

Agregacin
La agregacin es un tipo especial de asociacin que define que una clase (todo) est
conformada de otras clases (las partes). Esta relacin es llamada tambin tiene un o hace
parte de. La agregacin define una relacin mucho ms fuerte que la asociacin ya que el todo
no puede existir sin las partes y viceversa. Este tipo de relacin define lo siguiente:
La destruccin del todo implica la destruccin de las partes.
Las partes no pueden accederse fuera del todo. Los mensajes a las partes deben llegar
a su todo y este se las enva.



El banco est conformado de cuentas. Sin las cuentas el banco no puede existir y las cuentas
no pueden existir sin las cuentas.

Composicin
Es un tipo de agregacin que aade el matiz de que la clase todo controla la existencia de las
clases parte. Es decir, normalmente la clase todo crear al principio las clases parte y al
final se encargar de su destruccin. Las composiciones tienen una implementacin similar a
las asociaciones, con la diferencia de que el objeto principal realizar en algn momento la
construccin de los objetos compuestos.

Ya aclarado este punto se puede crear el diagrama UML del caso de estudio.
Las agregaciones y composiciones se especifican con un Rombo al final de las lneas. El rombo
est en la clase Todo.
En los extremos de las lneas se coloca la multiplicidad de la relacin.
Uno: 1
Muchos: *, 0...*



Herencia
Esta relacin indica que una clase puede ser una versin ms especializada de otra, es decir,
una clase puede implementar todas las funcionalidades de otra. Si la clase A hereda sus
caractersticas de una clase B, entonces se dice que la clase A es hija de la clase B o la clase B
es superclase de la A.

En este diagrama vemos la organizacin jerrquica de la herencia. La clase A es madre de B y a
su vez esta es madre de C y D. otro aspecto importante es que A al ser la superclase de B, es a
su vez la superclase de C y D tambin.
Diagrama de clases
El diagrama de clases es aquel donde se muestran todas las relaciones entre las clases, los
atributos y mtodos de estas.
Dealer
Jugador
BlackJack -tiene un
1
-hace parte de
1
1
*
-los jugadores
*
-administra 1
Mano
-J uega con una 1
-hace parte de 1
Mazo
-tiene un 1
-hace parte de 1
Carta
-esta compuesto de 1
-componen 0..*
-esta compuesto de
1
-componen 0..*
Apuesta
-tiene varias
1
-son recibidas
0..*
-realiza 1
*

Fig. 1: Diagrama UML del Black Jack


Para que este modelo este totalmente completo, es necesario identificar los atributos y
mtodos de cada una de las clases del mismo. Esto se puede determinar del enunciado del
problema y de las responsabilidades de cada entidad.

Carta
Atributos
o Nombre: cadena
o Pinta:cadena
o Valor:numrico
Metodos
o darNombre:cadena
o darPinta:cadena
o darValor:numerico

+darValor() : double
+darNombre() : string
+darPinta() : string
-nombre : string
-pinta : string
-valor : int
Carta

Mano
atributos
o cards:carta
mtodos
o darValor:numrico
o agregarCarta:void
o mostrarMano:carta[0..n]
o numCartas:numerico
+agregarCarta(entrada card : Carta)
+darValor() : int
+mostrarMano() : Carta
+numCartas() : int
-cards : Carta
Mano

Mazo
Atributos
o lasCartas:Carta[0..n]
o cartasBarajadas:carta[0..n]
Metodos
o reiniciarMazo:void
o barajarMazo:void
o numCartas:numrico
o darCarta():carta
+reiniciarMazo() : void
+barajarMazo() : void
+numCartas() : int
+darCarta() : Carta
-lascartas : Carta
-cartasBarajadas : Carta
Mazo

Jugador
Atributos
o Mano:hand
o Dinero: doubl
Metodos
o agregarCartaMano(card:carta)
o mostrarMano():carta
o valorMano():int
o pedirCartaDealer()
+agregarCartaaMano(entrada card : Carta) : void
+mostrarMano() : Carta[0..n]
+numCartasMano() : int
+valorMano() : int
+pedirCartaDealer() : void
+apostar(entrada valor : double) : void
-Hand : Mano
-dinero : double
Jugador

Lo mismo se hace con todas las clases identificadas. Al final, el diagrama UML se completa con
este anlisis.


+iniciarJ uego() : void
+repartirRonda() : void
+indicarGanador() : J ugador
+recibirApuesta(entrada bet : Apuesta) : void
-jugadores : J ugador
-deck : Mazo
-apuestas : Apuesta
Dealer
+agregarCartaaMano(entrada card : Carta) : void
+mostrarMano() : Carta[0..n]
+numCartasMano() : int
+valorMano() : int
+pedirCartaDealer() : void
+apostar(entrada valor : double) : void
-Hand : Mano
-dinero : double
Jugador
-players : J ugador[0..n]
-dealer : Dealer
BlackJack
-tiene un
1
-hace parte de
1
1
*
-los jugadores
*
-administra 1
+agregarCarta(entrada card : Carta)
+darValor() : int
+mostrarMano() : Carta
+numCartas() : int
-cards : Carta
Mano
-J uega con una 1
-hace parte de 1
+reiniciarMazo() : void
+barajarMazo() : void
+numCartas() : int
+darCarta() : Carta
-lascartas : Carta
-cartasBarajadas : Carta
Mazo
-tiene un 1
-hace parte de 1
+darValor() : double
+darNombre() : string
+darPinta() : string
-nombre : string
-pinta : string
-valor : int
Carta
-esta compuesto de 1
-componen 0..*
-esta compuesto de
1
-componen 0..*
-valor : double
-player : J ugador
Apuesta -tiene varias
1
-son recibidas
0..*
-realiza 1
*

Fig. 2: Diagrama de Clases Completo


16 Caso de estudio II: JUEGO DE PARQUES. | EAM

Caso de estudio II: JUEGO DE PARQUES.
Es un juego de mesa que consiste en llevar todas las fichas del mismo color, hasta la meta final,
antes que los dems contrincantes lo hagan. Si otro jugador llega al espacio que no es
denominado "seguro", en donde se encuentra una ficha de otro color, este tiene la
oportunidad de enviarlo a la crcel, haciendo devolver la ficha al inicio del juego. En caso de no
enviar las fichas del contrincante a la crcel el jugador que avanza recibe un castigo y debe
regresar su ficha al punto de partida. A esta situacin se le llama soplar.

El juego consta de un tablero, que puede tener espacio para cuatro o seis jugadores, divididos
por colores, cada jugador tiene cuatro fichas y los espacios a mover estn definidos por una
pareja de dados.
Todos los jugadores comienzan con sus fichas en las respectivas crceles. El primer turno se
escoge por medio de los dados: el jugador que saque el mayor nmero es el que comienza el
juego. Tiene tres oportunidades para sacar sus fichas de la crcel y posicionarlas en la casilla de
salida. Se sacan fichas con las presadas, es decir, cuando ambos dados tienen el mismo valor.
Por ejemplo, 1-1 y 3-3 son presadas. La presadas 1-1 o 6-6 sacan todas las fichas de la crcel;
las restantes, como 3-3, sacan slo dos. Existe una variacin a esta regla, que debe ser
acordada al comienzo del juego: Si el jugador obtiene 1-1 o 6-6 en los dados, podr sacar de la
crcel, si quiere, dos fichas y en este caso tendr de opcin de mover una de las fichas el valor
que tenga un dado, es decir, mover 1 o mover 6.

Si puede sacar alguna ficha tiene que lanzar de nuevo y pasar el turno. El turno se pasa al
jugador en la derecha. Despus de que haya salido de la crcel, el jugador debe decidir cmo
distribuir su puntaje: puede "correr" ("mover") todo con una sola ficha o mover lo de cada
dado con una ficha. La mecnica del juego contina de esta manera hasta que algn jugador
lleve todas sus fichas hasta la casilla final. En este momento, habr ganado el juego.
Las fichas son similares a los peones del ajedrez y cada jugador posee fichas de un color
especfico, lo mismo que su crcel y sus casillas de llegada. Como se juega con dados normales,
el menor valor a sacar es 2 y el mximo 12. Cuando se saca el mismo valor en ambos dados,
tiene un significado especial.

Para capturar fichas (comer fichas, mandar a la crcel), hay que poner la ficha de uno en la
misma casilla de la ficha del oponente. La ficha se captura y se devuelve a la crcel. Hay casillas
de "seguro" donde no se puede mandar a la crcel. Despus de comer una ficha, se debe
avanzar lo que le queda en el otro dado con otra de las fichas que se encuentre en la tabla de
juego, excepto si es la nica ficha con la que se cuenta; slo en ese caso se puede avanzar con
el mismo dado. Cada vez que un jugador se coma una ficha de un oponente tiene derecho a un
nuevo lanzamiento de los dados slo cuando saca pares. Si el jugador tiene una ficha en la
crcel y saca pares tiene que salir de la crcel, obligatoriamente. No ser soplado si tiene una
ficha para comer con el valor de los dos dados o no sale de la crcel y come la ficha. Pero ser
soplado si no come o sale de la crcel. Tambin se pueden comer fichas en la casilla de salida si
hay una ficha ajena en la salida y el otro jugador sale de la crcel.


Identificar Clases 17

Identificar Clases
Observando los sustantivos del enunciado y realizando el proceso de filtrado se encuentran las
siguientes entidades:
Ficha: son con las que se juega y las que recorren el tablero.
Tablero: es el rea de juego y sobre el cual se hacen muchas operaciones.
Dado: el que determina los movimientos de los jugadores. Las reglas del juego los
involucran mucho.
Casilla: donde se posicionan las fichas del tablero. Hay varios tipos de casillas y en ellas
se llevan a cabo muchas tareas relevantes.
Crcel: rea especial del tablero en la cual se llevan muchas operaciones importantes.
Jugador: es el actor principal del juego.
Identificar Responsabilidades.
Revisar verbos y asociarlos a las entidades del problema.
Ficha
Mover la ficha
Indicar su posicin en el tablero
Ir a la crcel
Salir de la crcel
Indicar en qu casilla esta
Coronar ficha
Dado
Lanzar dado
Dar valor sacado
Crcel
Agregar ficha
Sacar ficha
Jugador
Lanzar dados
Mover sus fichas
Comer otra ficha
Soplar la ficha del contrincante
Coronar ficha
Saber si gano



Casilla
Agregar fichas a la casilla.
Dar fichas puestas en la casilla
Quitar fichas de la casilla.
Buscar ficha de un jugador

Tablero
Sacar ficha de la crcel
Enviar ficha a la crcel
Mover ficha
Indicar ganador
Indicar par en los dados
Determinar quien saca
Avanzar o pasar el turno
Lanzar dados.
Determinar salida de la crcel.
Coronar ficha.
Esta clase en particular ser la responsable de hacer cumplir todas las reglas del juego.

En este punto como se ha explicado en varias ocasiones se determinan las interacciones entre
las clases del modelo y los mensajes que se deben enviar las unas a las otras. Primero es til
determinar los escenarios o situaciones que se presentaran en el caso de estudio.
El Jugador Usa Su Turno

Jugador
lanzarDados
Tablero
Tablero Dado
lanzarDado
retornaValorAleatori

Tablero
darValorDados
Jugador


Enviar A La Crcel

Salida

Jugador Tablero
ponerFicha
Tablero
Casilla
moverFichaACasilla
Ficha Jugador
darCasilla
quitarFicha
Tablero
Casilla
quitarFicha
Tablero
Casilla
Tablero
aadirFicha
Crcel
Jugador
lanzarDados
Tablero
Tablero Dado
lanzarDado
retornaValorAleatorio


Comer Ficha Contrincante

Estos dibujos muestran las relaciones y mensajes que se envan entre cada una de las
entidades. Otra tcnica que se puede usar son las tarjetas CRC (Class-Responsabilities-
Collaboration) en las cuales se puede expresar de manera ms rpida estas relaciones. Existe
tambin otro mtodo los cuales son los diagramas de secuencia que principalmente muestran
los mensajes que se envan las clases entre s.

Tablero Tablero
verificarPar
Tablero Crcel
sacarFichas
Tablero Casilla
indicarTipoCasilla
Retornar num fichas

Tablero Crcel
aadirFicha
Tablero Casilla
numeroFichasCasilla


Diagrama de Secuencia.
Usar turno
J UGADOR
FICHA
DADO TABLERO
lanzarDado
lanzarDado
valorDado
valorDados
darCasilla
casilla
moverFicha
CASILLA
quitarFicha
ponerFicha

Las entidades que participan en la situacin de estudio se ponen en la cabeza del diagrama
seguido de las cuales salen las lneas de vida (en naranja). De estas lneas se desprenden los
mensajes que envan la entidad a otras entidades. Las lneas punteadas son las respuestas a
esos mensajes. Los cuadros azules son los tiempos de activacin de las entidades. En este
tiempo la entidad est realizando alguna tarea y cuando termine el trabajo de la entidad en
esta operacin ha terminado.
Salir de la crcel
DADO J UGADOR TABLERO
CARCEL
lanzarDados
lanzarDado
valorDado
verificarPar
sacarFichas[3 pares]

Lnea de vida
activacin
mensaje
respuesta


Aqu se crea el modelo UML del sistema analizado en las etapas anteriores.
Ficha
Casilla
Tablero Carcel
Jugador
Dado
parques
-los dados
1 *
-esta compuesto 1
*
-contiene
1 *
-fichas
1 *
1
1
-jugadores
1 *
*
-fichas
1
-fichas
*
*
El diagrama expresa que el tablero est compuesto de las casillas, crcel y dados. El parqus lo
forman los jugadores y el tablero. Las fichas tienen una asociacin con las fichas y la crcel.
Observando las responsabilidades y las colaboraciones se pueden inferir los mtodos y
atributos que tendr cada entidad.


23

Caso de estudio III: Tienda Autoservicio de Msica.
En este caso de estudio se pretende modelar una tienda autoservicio de Msica. Una tienda de
esta naturaleza e aquella en la que todo el proceso de pago y facturacin est a cargo del
mismo cliente. En esta clase de tiendas solo pueden comprar clientes que ya se hayan
registrado previamente en el almacn. Los clientes se identifican con su nmero de cedula y La
nica forma de pago con la que cuentan es con tarjeta crdito o debito. Estas tarjetas deben
ser registradas en el almacn previamente para su uso. Solo se pueden registrar hasta 3
tarjetas por cliente y el registro consta del nmero de la tarjeta, su tipo y su fecha de
expiracin. Un cliente no puede comprar con tarjetas que hayan caducado. Cuando llega un
cliente a realizar una compra, este puede llevar DVDs, libros o CDs de msica. Cualquier
producto est identificado por un cdigo nico. En el momento de realizar una compra, el
cliente puede agregar o quitar elementos de la misma a voluntad, lo que debe reflejarse en el
costo total de la venta. Estos elementos definen el producto y la cantidad del mismo que se
est comprando. Los productos en general tienen un precio. En caso de los libros, tienen un
autor, un ISBN y un ao de publicacin, los CDs de msica tienen un artista y una productora
y los DVD la productora. Cuando se confirma la venta por parte del cliente, debe quedar
registrada en esta la tarjeta que uso. En todas las compras debe estar presente el registro del
cliente y la fecha de dicha compra. Todas las compras tienen un nmero de identificacin
nico. Una compra tiene derecho a muchos descuentos dependiendo de la naturaleza de la
misma. Cuando se usa tarjeta debito, se aplica un descuento del 4% sobre el total de dicha
compra.
Para este caso de estudio se presentara el patrn de diseo Modelo-vista-controlador adems
de todo el proceso de anlisis de la solucin ya abarcado anteriormente.

Identificar Entidades
Leyendo el ejercicio se encuentran los siguientes sustantivos.
Tienda, pago, facturacin, cliente, cedula, tarjeta de crdito, tarjeta debito, almacn, registro,
nmero de tarjeta, tipo, fecha expiracin, compra, DVD, CD, libro, compra, elemento,
producto, autor, ISBN, ao de publicacin, artista, productora, venta, numero de id,
descuento.
Con una lectura cuidadosa del caso de estudio se puede ver que los siguientes sustantivos son
atributos de otro sustantivo: cedula, nmero de tarjeta, tipo, fecha de expiracin, autor, ISBN,
ao de publicacin, numero de id.
Lo que deja los siguientes:
Tienda, pago, facturacin, cliente, tarjeta de crdito, tarjeta debito, almacn, registro,
compra, DVD, CD, libro, compra, elemento, producto, venta, descuento.


24 Caso de estudio III: Tienda Autoservicio de Msica. | EAM

De estos se puede ver que:
venta y compra es lo mismo visto desde el punto de vista del cliente y la tienda, solo
una debe ser entidad.
Descuento es algo que se puede calcular.
Facturacin es la representacin de una compra o una venta.
Registro es lo que debe tener la compra con respecto al cliente.
Despus de esto las entidades del problema se reducen a:

Tienda
Tarjeta
Compra
Elemento
Producto

DVD
CD
Libro
cliente

Responsabilidades De Las Entidades.
Para cada entidad hay que identificar las responsabilidades.
Producto, DVD, Libro, CD
Administrar sus atributos, es decir, dar y establecer el valor de los mismos. Para quienes estn
familiarizados con el lenguaje de programacin Java, esto se hace a travs de los setter y
getters.
Tarjeta
Administrar atributos
Indicar fecha de expiracion
Cliente
Pagar cuenta
Aadir elemento a la compra.
Quitar elemento de la compra
Aadir tarjeta de crdito
Indicar expiracin tarjeta de crdito
Compra
Calcular total comprado
Calcular descuento
Agregar elemento
Quitar elemento
Asignar tarjeta
Asignar cliente


Colaboraciones Entre Las Clases 25

Elemento
Asignar producto
Asignar cantidad
calcularTotal

Colaboraciones Entre Las Clases
Luego de establecer las entidades y sus relaciones es momento de determinar como estas se
comunican las unas con las otras para satisfacer las necesidades del sistema que modelan.
Como se explico con anterioridad estas colaboraciones se pueden apreciar mediante el
diagrama de secuencia.
Primero se deben identificar los escenarios o casos de uso en la aplicacin.
La aplicacin debe permitir:
1. Crear una compra al cliente
2. Pagar una compra
3. Agregar y quitar elementos de una compra

Pagar una compra
Objeto2
Objeto1
compra
Paquete superior::cliente
calcularTotal
elemento
tarjeta
calcularTotal
totalElemento
tipo
getTipo
calcularDescuento
totalCompra



El modelo representa el corazn de la aplicacin, en el est la lgica de la misma, las
reglas y restricciones en el manejo de la informacin. Como el modelo est enfocado
solo en la informacin de la aplicacin, solo se convierten en mtodos las
responsabilidades que administren de alguna manera algn atributo.

Para definir el modelo es necesario establecer los atributos, mtodos y relaciones
entre las entidades.
El elemento define el producto y la
cantidad.
Atributos:
o Prod:producto
o Cantidad:int
Mtodo:
o totalElem:double

Una compra

Atributos
o Cdigo:String
o Cadr:tarjeta
o Client:cliente
o Elemens: elemento[0*]

Metodos
o agregarElemento(elemento item)
o calcularTotal():doubl
o calcularDescuento():doubl
o quitarElemento(String codProd)
o getters y setters en general



Atributo:
o Atributos
o fechaExpiracion:Date
o tipo:int
o numero:String
o
o Metodos
o indicarExpiracion(fechaActual:date):boolean
o getters y setters en general.

A continuacin se muestra el diagrama de clases de las entidades. fjese que los
mtodos de las entidades solo buscan la administracin de los atributos de las mismas.
Tambin estn definidas las relaciones entre las clases.
Tarjeta-cliente: composicin. La vida de las tarjetas es responsabilidad del
cliente.
Tarjeta-compra: Agregacin: la Compra necesita una tarjeta pero no es
responsable de la vida de la misma
Elemento-Producto: Agregacin.
Producto-DVD-CD-Libro: Herencia
Elemento-Compra: Composicin: los elementos solo tienen razn de existir
dentro de una compra.

Camilo Andrs Ferrer Bustos CAPITULO I: ANALISIS Y DISEO ORIENTADO A OBJETOS.


Nota: Este diagrama de clases esta hecho en netbeans.

PATRON DE DISEO ARQUITECTONICO MODELO-VISTA-CONTROLADOR 29

PATRON DE DISEO ARQUITECTONICO MODELO-VISTA-
CONTROLADOR

Un patrn es una disciplina de diseo que rene las experiencias de expertos en algn tema. El
patrn captura las experiencias bien probadas de estos expertos para definir buenas prcticas
en el proceso de anlisis e implementacin de una solucin basada en software.
Cuando los expertos trabajan en una nueva solucin es muy comn que la manera de
abordarla se haya hecho en ocasiones anteriores, es decir, la estructura general de la solucin
siempre es la misma, este comportamiento y manera de resolver los problemas se puede
estructurar en un patrn de diseo. Un representante muy famoso de los patrones de diseo
de software es el denominado Modelo-Vista-Controlador.
Para el diseo de aplicaciones con sofisticados interfaces se utiliza el patrn de diseo Modelo-
Vista-Controlador. La lgica de un interfaz de usuario cambia con ms frecuencia que los
almacenes de datos y la lgica de negocio. Si realizamos un diseo ofuscado, es decir, un
pastiche que mezcle los componentes de interfaz y de negocio, entonces la consecuencia ser
que, cuando necesitemos cambiar el interfaz, tendremos que modificar trabajosamente los
componentes de negocio. Mayor trabajo y ms riesgo de error. Cuando se desarrolla usando
GUI hay que tener en cuenta lo siguiente:
Cambios en la interfaz deben ser fciles e incluso pueden pasar en tiempo de ejecucin
Los cambios en la interfaz no deben afectar el cdigo que sea el ncleo de la
aplicacin.
Para resolver el problema se suele dividir la solucin del problema en tres partes
fundamentales:
Modelo: componente que encapsula el comportamiento y los datos de la
informacin. El modelo debe ser independiente de la manera en cmo se represente.
Vista: componentes que muestran la informacin al usuario. Obtiene los datos del
modelo y los muestra al usuario. Pueden haber varias vistas del modelo.
Controlador: el controlador es el responsable de traducir los deseos del usuario que
se dan a travs de eventos en cambios en el modelo. El usuario interacta con el
modelo a travs del controlador.
La separacin del modelo de la vista permite tener varias vista del mismo modelo. Si un
controlador cambia el modelo en alguna de las vista, este modelo debe notificar a sus vistas el
cambio. Las vistas atienden esta notificacin que debe traer los datos modificados para ser
mostrados.
Esta divisin tambin permite cambiar alguna de las partes sin causar mayores efectos sobre
las otras, adems que permite el desarrollo de la aplicacin en equipos de trabajo dedicados a
cada una de las partes mencionadas.



Un esquema grafico del patrn de diseo es el siguiente:

Las responsabilidades de cada una de las partes son:
Modelo: define los datos y las operaciones entre ellos. Idealmente el modelo debe ser
independiente de la manera como se almacenen los datos. El modelo debe notificar a las vistas
sus cambios.
Controlador: si queremos que el modelo sea independiente de la manera como se persistan
los datos, entonces el controlador debe gestionar los accesos a la base de datos o archivos que
contengan la informacin que debe administra el modelo. El controlador debe registrar ante el
modelo las vistas que este debe actualizar. Recibe los eventos y los traduce en cambios en el
modelo. Cualquier cambio sobre el modelo se debe hacer a travs del controlador.
Interfaz: la interfaz debe tener una referencia de su controlador para poder cambiar el
modelo. Recibir notificaciones del modelo para actualizar la vista del mismo.

Modelo vista controlador en el caso de estudio III

En el caso de estudio ya se ha defino a cabalidad el modelo, falta definir la vista y el
controlador. Idealmente cada entidad deber tener su controlador, pero para este caso en
particular solo se creara un controlador para las operaciones ms recurrentes como son las
compras, los clientes, los productos y la tienda en s, las tarjetas son administradas por los
clientes, entonces es controlador de cliente podr implementar la persistencia de las tarjetas.

Modifica
Vista
Controlador Modelo

Notifica cambios Eventos

PATRON DE DISEO ARQUITECTONICO MODELO-VISTA-CONTROLADOR 31

Controladores

Tienda
Este controlador gestiona la Connection a la base de datos y crea los controladores para
cliente y compra.

Ntese que este controlador tiene un objeto de tipo Connection para establecer conexin con
la base de datos que posee los datos.

controladorCliente

Esta clase administra la persistencia de la tarjetas para lo cual posee los mtodos de:
cargarCliente: recibe la Cedula del cliente a cargar de la BD. En el proceso de carga se llama al
mtodo prvate cargarTarjeta que lee en la BD las tarjetas del cliente y las almacena en un
Hashtable.
quitarTarjeta: mtodo para borrar una de las tarjetas del cliente, recibe el numero de la tarjeta
a borrar.


PATRON DE DISEO ARQUITECTONICO OBSERVADOR-
OBSERVABLE

En el patrn MVC se indico que el modelo debe informar a la vista o vistas de sus propios
cambios. si varias vistas estn mostrando el mismo modelo, ambas deben mostrar la
informacin actual del modelo, es decir, debe haber una sincronizacin entre las dos
interfaces; si alguna de las interfaces modifica el modelo a travs del controlador, en la otra
interfaz ese cambio debe reflejarse inmediatamente para que el usuario que ve esa interfaz
vea la informacin actual del modelo. La sincronizacin de las interfaces se convierte en un
problema cuando ellas no ese conocen mutuamente y no hay referencias entre ellas. Para
resolver ese inconveniente se implementa en la aplicacin el patrn observador.
El patrn observador define que es responsabilidad del modelo informar a quien les puedan
interesar los cambios que se producen en l, y es responsabilidad de las interfaces estar
monitoreando los mensajes que enva el modelo a cerca de sus cambios para mostrarlos en la
interfaz. Usando este enfoque, el modelo se dice que es observable y la vista se dice que es
observador. El lenguaje de programacin java implementa este patrn de diseo a travs de la
clase Observable y la interfaz Observer.
Usando este patrn, las clases del modelo deben heredar de Observable y la vista implementar
la interfaz Observable.

Procedimiento para Implementar el patrn Observador en una
aplicacin JAVA

Para ilustrar la implementacin del patrn observador consideremos el siguiente ejemplo:

Se desea que dos interfaces diferentes muestren el valor de un numero y que cualquier
cambio de ese nmero en alguna de las interfaces se vea reflejado en la otra interfaz.

Cualquier cambio en el deslizador de la ventana1 debe reflejarse en la ventana2 y cualquier
cambio en el numero en el campo de texto debe reflejarse en la ventana1 ya que ambas estn
mostrando el mismo numero.

PATRON DE DISEO ARQUITECTONICO OBSERVADOR-OBSERVABLE 33

Solucin:

Para solucionar el problema hay que tener en cuentea que las dos vistas deben mostrar el
mismo modelo y si se usa MVC deben tener asociados el mismo controlador que modifique
dicho modelo. El modelo se define como una clase que contiene un nmero y el setter y getter
para manipularlo; La clase se muestra a continuacin:

Y el controlador de esta clase:

public class numero
{
private int valor;

public numero(int valor) {
this.valor = valor;
}
//obtiene el valor del numero
public int getValor() {
return valor;
}
//establece el valor del numero
public void setValor(int valor) {
this.valor = valor;
}

}
public class controlNumero
{
private numero miNumero;

public controlNumero()
{
miNumero=new numero(0);
}

public void cambiarNumero(int valor)
{
miNumero.setValor(valor);
}

}
Modelo que manejara el
controlador
Se instancia el modelo.
Mtodo del controlador para
cambiar el modelo.


Para que las dos interfaces controlen el mismo modelo deben tener el mismo controlador.
Esto se consigue instancindolo en el Main del proyecto y envindolo como parmetro al
constructor de las dos ventanas.
Constructor Ventana1 y 2.
private controlNumero control;

public ventana1(controlNumero control) {
initComponents();
this.control=control;
}

initComponents();
}

Fjese que se reciben como parmetro en el constructor.
El main del proyecto entonces debe ser asi:

Hasta este punto la aplicacin ya esta operativa, pero cualquier cambio que se haga en la
primera no afecta a las segunda y viceversa aunque ambas representen el mismo nmero.
Para que esto ocurra se implementa en la aplicacin el patrn observador. Los pasos para
aplicar el patrn son:
1. El modelo debe heredar Observable
public class numero extends Observable
Recuerde que la clase del modelo es la clase numero.
2. cuando el modelo cambie sus atributos debe notificarlos.
Para que el modelo notifique los cambios se usa el mtodo setChange() y para enviar
los cambios se usa notifyObservers(Object); que recibe el objeto que se va a notificar.
Por lo general es una referencia a la clase con this o el valor como tal que cambio.
El modelo cambia en el mtodo setValor, ah se escribe lo anterior.

public static void main(String[] args)
{
controlNumero control=new controlNumero(); //instancia el controlador
ventana1 v1=new ventana1(control); //enva el controlador a ventana1
ventana2 v2=new ventana2(control); //enva el controlador a ventana2
}


3. la vista debe implementar la interfaz Observer y el mtodo update.
public class ventana1 extends javax.swing.JFrame implements Observer
update en ventana1.

update en ventana2.

El metodo update recibe dos parametros:
Observable o: informa que objeto del modelo notifico el cambio.
Object arg: recibe el valor que se enva desde el modelo a travs de
notifyObserver. En nuestro caso el valor. Ver punto 2.

Como se recibe arg como object es necesario convertirlo a travs de un cast a entero
porque lo que se envi fue un entero.
La diferencia entre el update de Ventana1 y de Ventana2 es donde se muestra ese
nmero. En una interfaz se hace en un JTextField y en otra en una barra de progreso.

public void setValor(int valor)
{
this.valor = valor; //cambia el valor
setChanged(); //se notifica el cambio a quien le pueda interesar
notifyObservers(valor); //se envia el cambio para que el que le interese lo
//tome
}

public void update(Observable o, Object arg)
{
Integer numero=(Integer)arg;
TFVAlor.setText(numero+"");
}
{
Integer numero=(Integer)arg;
jProgressBar1.setValue(numero);
jSlider1.setValue(numero);
}


4. Registrar los observadores.
Los observadores son las ventanas. Hay que registrarlos en el modelo a travs del mtodo
addObserver de la clase Observable que en este caso es la clase numero que heredo
caractersticas dela clase en mencin. Este mtodo recibe como parmetro un objeto que
haya implementado la interfaz Observer que en nuestro caso son las ventana1 y ventana2.
Como se est usando MVC y la vista no conoce el modelo, esta operacin se hace a travs
del controlador creando un mtodo en la clase controlNumero que agregue el observador
a el objeto miNumero del controlador.

Cada vista debe llamar a este mtodo del controlador para registrarse ante el modelo.

initComponents();
control. agregarObservador (this)
}

initComponents();
control. agregarObservador (this)
}

Se usa this por que son estas clases(las ventanas) las que son las observadores del modelo
y como el controlador es el mismo en las dos vistas, estas se estarn registrando como
observadores del mismo modelo.
Los eventos de las ventanas1 y 2 se muestran a continuacin:
Evento clic botn cambiar ventana 1.

Evento ItemStateChange del deslizador en la ventana 2.

public void agregarObservador(Observer obs)
{
miNumero.addObserver(obs);
}
int valor=Integer.parseInt(TFVAlor.getText());
control.cambiarNumero(valor);
int valor=jSlider1.getValue();
control.cambiarNumero(valor);


Ya en este punto cualquier cambio realizado en la ventana1 o 2 se refleja en la otra
automticamente.

Si se siguen los pasos anteriores en cualquier aplicacin, la implementacin de este patrn de
diseo ser un xito.

CAPITULO II: HILOS Y CONCURRENCIA

38 INTRODUCCION | EAM

CAPITULO II: HILOS Y
CONCURRENCIA
INTRODUCCION
Un punto de vista muy simple de un sistema de computo es aquel que posee una CPU para
realizar los clculos, una memoria que contiene el programa que la CPU ejecuta y una memoria
que almacena los datos para la ejecucin del programa; desde este punto de vista solo se
puede ejecutar una sola tarea. Un punto de vista ms actualizado nos provee la posibilidad de
ejecutar ms de una tarea al mismo tiempo. Como programadores no hay que tener en cuenta
el hecho que la CPU pueda ejecutar ms de una tarea, solo hay que pensar en las implicaciones
que esto tiene, porque ejecutar ms de una tarea al tiempo significa tener ms de una CPU, lo
cual en definitiva se convierte se una ventaja muy significativa.
El hecho de poder ejecutar ms de una tarea a la vez se le denomina concurrencia. El lenguaje
de programacin JAVA nos provee la concurrencia a travs de lo que se conoce como hilos. Un
hilo se considera como un contexto de ejecucin que posee su propia CPU (virtual), sus datos y
cdigo ejecutable. Los hilos estn representados principalmente por la clase Thread.
Las caractersticas de un hilo son las siguientes:
Un hilo se considera como una unidad independiente que encapsula datos y programa
ejecutados por una CPU virtual
Un hilo es creado y controlado por la clase Thread.

Un hilo entonces est compuesto por tres partes principales:

CPU virtual
Datos
Programa


Clase Thread. 39

IMPLEMENTANDO HILOS EN JAVA
El lenguaje de programacin JAVA est diseado para ejecutar a hilos desde sus mismas bases.
Es as como muchos procesos dentro del lenguaje se haces a travs de hilos. Un ejemplo claro
de esto es en la ejecucin de la interfaz grafica que es un hilo que espera recibir eventos para
procesar.
Como se dijo anteriormente, los hilos en java se implementan a travs de la clase Thread y
tambin por medio de la interfaz Runnable.

Clase Thread.
Por medio de la clase Thread se puede crear un contexto de ejecucin independiente con sus
datos y su cdigo ejecutable. La estructura bsica un hilo pro medio de Thread es la siguiente:

La manera ms fcil de implementar un hilo es crear una clase que herede todas las funciones
definidas en Thread. Dentro de esta clase se definen los datos del mismo como atributos de
esta clase y el cdigo ejecutable se escribe en el mtodo run. El mtodo run est definido en
la clase Thread y permite ser redefinido en las subclases de esta.
A los hilos tambin se les puede dar un nombre a travs del constructor de Thread:
public Thread(String nombreHilo)
public class hilo extends Thread
{
//los datos del hilo se implementan como
//atributos de esta clase.
/**
* constructor. instancia la clase madre tambin
* a travs del super.
*/
public hilo()
{
super();
}
/**
* En este mtodo se escribe el cdigo que se quiere
* ejecutar en el hilo.
*/
public void run()
{
//.
}
}

40 IMPLEMENTANDO HILOS EN JAVA | EAM

El tiempo en el que se ejecute le mtodo run determina la vida del hilo, si este mtodo llega a
su fin, entonces el hilo habr muerto y no se podr ejecutar de nuevo. Para ejecutar el hilo se
debe llamar al mtodo start() de la clase Thread. A continuacin un ejemplo.

En este hilo se incrementa un contador indefinidamente y se muestra en la consola.
Para correr el hilo se crea una instancia de la clase miHilo y se llama al mtodo start.

Lo interesante de esto es que se estn ejecutando dos procesos independientes cada uno un
hilo aparte. La consola lucira algo asi:
public class miHilo extends Thread
{

private int valor;

public miHilo (String nombre)
{
super(nombre);
valor=0;
}

public void run()
{
while(true)
{
valor++;
System.out.println(getName()+ "dice: valor->" +valor);
}
}
}
Llama al constructor de Thread
que tiene un nombre
Ciclo infinito para que el mtodo
nunca termine y el hilo nunca muera.
Se muestra en consola el nombre
del hilo con getName() y el valor
del contador.
public static void main(String[] args) {

miHilo h=new miHilo ("camilo");
h.start();

miHilo p=new miHilo ("juan");
p.start();

}
Se crean dos instancia de miHilo
con nombre Camilo y Juan y se
arrancan los hilos con start()

Clase Thread. 41

Fjese como en la consola van apareciendo el nombre del hilo y el
valor presente en. En la consola aparecen los dos hilos, lo que es
prueba de la ejecucin en simultnea de los dos hilos. El problema
que se ve ac es la velocidad en la ejecucin ya que a los pocos
segundos en la ejecucin de los hilos el valor del contador es muy
alto.
Cuando se quiere retrasar la ejecucin del hilo se utiliza el mtodo
sleep(long milisegundos) de la clase Thread. Es mtodo introduce
un tiempo de espera en el momento de su ejecucin, literalmente,
duerme el hilo el numero de milisegundos que recibe como
parmetro. El uso de este mtodo genera una excepcin del tipo
InterruptedException que se explicara ms adelante. Un ejemplo de
del uso de sleep se muestra a continuacin.

La consola en este caso la consola luce as:

public void run()
{
while(true)
{
try
{
valor++;
sleep(100);
System.out.println(getName() + "dice: valor->" + valor);
}
catch (InterruptedException ex)
{
ex.printStackTrace();
}
}
}
Cuando la ejecucin del hilo llega a este
punto, se crea un retardo de 100
milisegundos. Este mtodo se pone aqu en el
run ya que aqu es donde se ejecuta el hilo.


Ejemplo: Animacin Pelotas.
Se desea crear una aplicacin que permita ver en movimiento dos pelotas como se ve
en esta figura:
Se desea iniciar, finalizar, parar
y reanudar la simulacin.

c

Primero se debe crear la pelota, esto se puede hacer en una clase JPanel que dibuje
una pelota en su interior.

Hay que recordar que el JPanel como cualquier otro componente se ubica en el contenedor a
travs del mtodo setLocation(x,y). en esta clase el radio define el tamao del JPanel.
El mtodo especial en esta clase en el paint. paint es un mtodo de la clase Component que se
puede sobrecargar para que en el componente dibuje lo que el desee.
En esta clase se define el color de la pelota y su radio.


Clase Thread. 43

Se desean mover N pelotas y eso se puede hacer mediante un hilo. Un hilo para cada pelota.
La clase hiloPelota controlara el movimiento de la pelota en el contenedor que es un JPanel.

La idea es que las pelotas reboten en
los bordes del contenedor.
Eso obliga a que la clase hiloPelota
conozca el contenedor y la pelota que
controlara. Un diagrama de clases de
la clase hiloPelota se muestra a
continuacin.

en la clase hiloControlador que hereda
sus caractersticas de la clase Thread
se encuentran las referencias de la
pelota a controlar y el contenedor
donde se encuentra esta, variables
booleanas para controlar la ejecucin
del mtodo y sy y sx para controlar la
direccin del movimiento en x y y.
Contiene los mtodos para cambiar el
valor de las variables booleanas y el
mtodo redefinido run() de la clase
Thread. El constructor de la clase
recibe la pelota y el panel donde se
encuentra esta.
public void paint(Graphics g)
{
if (g!=null)
{
g.setColor(color);
g.fillOval(0, 0, radio*2, radio*2);
}
}
Contexto de dibujo. Cualquier dibujo que se
quiera hacer se hace sobre este objeto
Se dibuja un ovalo lleno con el color que se
defini con setColor. el dibujo empieza en el
origen (0,0) y el ancho y el alto son el dimetro
del circulo.


La lgica del movimiento es la siguiente:
Se sabe que las coordenadas en el panel aumentan de izquierda a derecha en X y de arriba
abajo en Y, es as que el origen del componente se encuentra en la esquina superior izquierda
y el fin en la esquina inferior derecha.

el siguiente dibujo muestra el movimiento de una pelota en el contenedor. Se muestra como
se comporta X y Y en cada trayectoria.

Si se analiza bien las descripciones, los cambios de direccin de X y Y se dan cuando la posicin
de la bola alcanza alguno de los bordes. De 1 a 2 toco el borde derecho y la direccin de X
cambio y as mismo con Y. este punto es clave para disear el algoritmo de movimiento.
El algoritmo de movimiento se escribe en el mtodo run() donde se implementa el cdigo que
ejecuta el hilo.

2. Disminuye X y
disminuye Y. fjese que
Y va de abajo hacia
arriba y X de izquierda a
derecha
1. Aumenta X y
Y va de abajo hacia
arriba y X de derecha a
izquierda
3. Disminuye X y
aumenta Y. Y va de
arriba hacia abajo y X
de izquierda a derecha
4. Aumenta X y
Y va de abajo hacia
arriba y X de derecha a
izquierda

Clase Thread. 45

Es de resaltar que cuando se alcanza alguno de los bordes sea en X o en Y, el valor de sx y de sy
cambia de signo para que si estaba sumando, empiece a restar; y si estaba restando empiece a
sumar las posiciones actuales.
El constructor del hilo recibe como parmetro la pelota a mover y el contenedor donde se
encuentra ya que estos son componentes de la interfaz de usuario.

public void run()
{
while(parar!=true)
{
if (pause==false)
{
try
{
if (ball.getX()>contenedor.getWidth() || ball.getX()<0)
sx=-sx;

if (ball.getY()>contenedor.getHeight() || ball.getY()<0)
sy=-sy;

ball.setLocation(ball.getX() + sx,ball.getY() + sy);
sleep(1);
}
catch (Exception ex) {
Logger.getLogger(hiloPelota.class.getName()).log(Level.SEVERE, null, ex);
}
}
}
}
Cliclo que se acaba cuando parar =true, en cuyo momento se
acaba el hilo.
Si pause es true no se hace nada. El hilo no muere.
Si la posicin de la bola
es mayor que el ancho o
alto del contenedor o es
cero, indica que se toco
un borde horizontal o
vertical.
Se ubica la bola en la posicin actual
mas un desplazamiento dado por sx y
sy. Si estas variables son negativas no
se produce un incremento si no un
decremento.


Ya definido el hilo que mover la pelota, lo nico que falta es usar en la interfaz el hilo y crear
las pelotas para que se muevan. Esto se puede hacer en el constructor de la misma. Eso se
muestra a continuacin.

Y por ltimo, en el evento del botn iniciar se inician los hilos.

public class ventana extends javax.swing.JFrame {

hiloPelota hBall;
hiloPelota hBall2;

public ventana()
{
initComponents();
setVisible(true);
pelota p=new pelota(50, 70, 20, Color.BLUE);
pelota p2=new pelota(100, 20, 20, Color.RED);
jPanel1.add(p);hBall2 =new hiloPelota(p,jPanel1);
jPanel1.add(p2);hBall=new hiloPelota(p2,jPanel1);
}
.
.
.
}
Definicin de los hilos que movern
las pelotas
Instancia de las pelotas a
mover.
Se agregan las pelotas al
contenedor y se instancian
los hilos. El hilo recibe la
pelota y el contenedor.
public hiloPelota(pelota ball,JPanel contenedor)
{
this.ball=ball;//inicializa la pelota
pause=false; //el hilo inicia corriendo
parar=false; //el hilo inicia corriendo
this.contenedor=contenedor; //inicializa el contendor
sx=1;
sy=1;
}
private void jButton1ActionPerformed(java.awt.event.ActionEvent evt)
{
hBall.start(); //inicia el hilo de la primera pelota

hBall2.start(); //inicia el hilo de la segunda pelota.
}

Clase Thread. 47

Ejemplo: Reloj con MVC y Patrn Observador.
Se desea crear un reloj digital utilizando MVC y patrn observador.
Para solucionar este problema se crea el modelo del reloj que es el siguiente.

Esta clase contiene los minutos,
horas y segundos, el constructor sin
parmetros inicializa los atributos
de la clase con la hora actual.
avanzarSegundo() implementa la
lgica del valor de los atributos del
reloj (hora, minuto y segundo).

Como se sabe los segundos, minutos y horas del reloj tienen un comportamiento especial y
muy ligado el uno con el otro.
Ya que se va a usar el patrn observador, esta clase debe heredar Observable para que pueda
ser observada por una o varias vistas.
El controlador es la clase que manipula el modelo, la manipulacin del reloj ser aumentar los
segundos del reloj que controle, ese incremento en los segundos es una operacin peridica y
continua, lo que indica que se puede implementar en un hilo. Los hilos muchas veces caben en
la clasificacin de controladores porque tienen la posibilidad de cambiar el modelo de la
aplicacin.
El controlador es el siguiente:

El controlador hereda Thread por
que va a ser un hilo y Como tal
implementa el mtodo run. Una
de las responsabilidades de un
controlador es registrar los
observadores del modelo, esto
se hace en el mtodo
agregarObservador. Este
controlador tambin tiene el
objeto tipo reloj a controlar.
La vista diseada es la siguiente:



Para aplicar el patrn observador la interfaz grafica de implementar la interfaz Observer y el
mtodo update para recibir las notificaciones de los cambios en el modelo. El modelo debe
notificar esos cambios cuando los haya. Para el caso de nuestro ejemplo, se notifica los
cambios cuando se llama al mtodo de avanzarSegundo() que es el que implementa el cambio
en los segundos, minutos y horas.

El update en la interfaz recibe esa notificacin y muestra los segundos, minutos y horas.

Cada vez que se llame el mtodo avanzarSegundo() el reloj notificara a la interfaz el cambio la
cual lo muestra en los JTextField dispuesto. El hilo-controlador deber llamar este mtodo
cada segundo.
public void avanzarSegundo()
{
segundos++;
if (segundos==60)
{
segundos=0;
minutos++;

if (minutos==60)
{
minutos=0;
horas++;

if (horas==12)
horas=0;
}
}
setChanged();
notifyObservers(this);
}
Notifica a los observadores a
travs de notifyObserver que
enva una referencia del objeto
reloj.
{
reloj r=( reloj)arg;

TFMinuto.setText(r.getMinutos()+"");
TFSegundo.setText(r.getSegundos()+"");
TFHora.setText(r.getHoras()+"");
}
El parmetro arg recibe lo que
se envi en notifyObserver en
el modelo
Se muestran los atributos
del reloj
El parmetro arg se
transforma en reloj ya que es
un Object

Clase Thread. 49

El llamado antes mencionado debe hacerse en el mtodo run() del hilo.

El constructor del hilo tiene la responsabilidad de crear el reloj que va a controlar.

public void run()
{
while(true)
{
try
{
clock.avanzarSegundo();
sleep(1000);
}
{
}
}
}
Mtodo del reloj que incrementa los
segundos y cuando sea necesario las
horas y los minutos. Este mtodo
notifica a la interfaz del cambio.
Se esperan 1000 milisegundos (1
segundo) entre llamado y llamado
del mtodo del reloj. Esto garantiza
que los segundos avancen en el
tiempo justo. sleep genera
excepcin
public class Timer extends Thread
{
private reloj clock;

public Timer()
{
super();
clock=new reloj();
}
.
.

}
Instancia del reloj. Este constructor
inicializa el reloj con la hora actual
del sistema.


ESTADOS Y CICLO DE VIDA DE UN HILO

Los hilos al ser entidades activas en la aplicacin tienen un tiempo de vida o tiempo en el que
estn activos. Bsicamente un hilo nace cuando se instancia y muere cuando despus de
llamar al mtodo start() de Thread, el mtodo run() termina su ejecucin o retorna. Entre
estos episodios el hilo pasa continuamente de un estado a otro ya sea por que el programador
o los sistemas as lo decidieron, la siguiente figura muestra los estados de un hilo:

Un hilo puede estar en tres estados principalmente:
Nuevo: Hilo recin instanciado, aun no se ha llamado al mtodo start().
Runnable: preparado para ejecutarse. El sistema operativo (SO) asigna a cada hilo un tiempo
de ejecucin. Solo los hilos en este estado pueden ser llegar a ser ejecutados.
Running: el hilo est corriendo. Cuando el SO decide ejecutar el hilo, pasa a este estado.
Blocked: hilo bloqueado: cuando un hilo esta en este estado es porque dejo de correr por
alguna razn, como puede ser un tiempo de espera con sleep, o que est esperando un dato
de un Dispositivo de entrada y salida o de otro hilo. Cuando el hilo sale de este estado pasa al
de Runnable para esperar a ser ejecuta en Running.
Muerto: cuando el mtodo run() completa su ejecucin, este muere y no puede volver a
ningn otro estado.
El mtodo isAlive() indica por medio de un booleano si el hilo est vivo o muerto.


SINCRONIZACIN DE HILOS. 51

SINCRONIZACIN DE HILOS.
Considrese el escenario cuando dos hilos poseen una referencia a la misma instancia de una
clase. Un hilo esta aadiendo elementos a una pila y otro los est sacando. En principio, los
datos son agregados y sacados exitosamente. Sin embargo, esto tiene problemas potenciales.
Supngase que el hilo a agrega elementos a una velocidad dada y el hilo b saca elementos a
otra velocidad, eventualmente la pila se quedara sin elementos dado el caso que el hilo b
saque a una mayor velocidad de lo que el hilo a produce, entonces, que hacer en esa
situacin?.
Una solucin a este problemas seria evitar que el hilo b saque elementos de la pila hasta que el
hilo a haya producido alguno, pero como se le informa a b que ya puede sacar?

Cuando dos hilos manipulan un mismo
objeto, cabe la posibilidad que uno de los
hilos lo necesite usar cuando el primero
todava lo est usando, dando la
posibilidad que el segundo lea un dato
invalido o cambie el comportamiento del
primer hilo por esta accin, lo ideal para
estos casos es que solo un hilo a la vez
use los datos compartido con otros hilo.
El lenguaje de programacin java provee
la palabra syncronize para proteger los
datos de accesos simultneos.

Ejemplo: Producto-Consumidor.
Una bodega modelada mediante una pila (estructura de datos que indica que el primer
elemento que sale es el ultimo que entro) es llenada por un productor con elementos y
vaciada por varios consumidores. Las velocidades de produccin y de consumo son aleatorias.
Resolver este problema usando MVC.
El modelo que se manipulara es la pila. Se puede formar por un ArrayList que se le agregan
elementos en la posicin cero y se le sacan de ah mismo . Este sera el modelo:



La interfaz grafica para mostrar la bodega
es muy simple y es la siguiente:

Esta interfaz implementa a Observer y debe
tener el mtodo update para mostrar el
contenido de la pila y los que los
consumidores sacan de la pila.

public class pila extends Observable
{
private ArrayList<Integer> elementos;
public pila()
{
elementos=new ArrayList<Integer>();
}
/**
* agrega un elemento en la pila
* @param elem elemento a agregar.
*/
public void agregarElemento(int elem)
{
elementos.add(0, elem);
setChanged();
}
/**
* metodo para sacar un elemnto de la pila
* @return ele elemento
*/
public int sacarElemento()
{
int elem=elementos.remove(0);
setChanged();
return elem;
}
public ArrayList<Integer> getElementos() {
return elementos;
}
}
Se agrega un elemento a la primera
posicin del ArrayList. Se notifica a los
observadores
Se saca el primer elemento del
ArrayList. Se notifica a los observadores
Notificara a los Observadores.


El productor se puede definir como un hilo que peridicamente agregue un elemento a la pila
y el consumidor como otro hilo que los saque.

public class productor extends Thread
{
private pila stack;

public productor(pila stack)
{
super("Productor");
this.stack=stack;

}
//------------------------------------------------------------------------------------------------------
public void run()
{
while(true)
{
try
{
int elem = (int) (Math.random()*1000);
stack.agregarElemento(elem);
sleep((int) (Math.random()*500));
System.out.println("Bodega:" + elem);

}
{
}
}
}
Se genera un elemento aleatorio
para agregarlo a la pila y se crea
otro tiempo aleatorio de espera.
El productor debe tener una
referencia de la pila que llega
como parmetro al
constructor.


El consumidor como se dijo antes es otro hilo que saca los elementos de la pila en periodos de
tiempo aleatorios.

public class consumidor extends Thread
{
private pila stack;

public consumidor(String nombre, pila stack)
{
super(nombre);
this.stack=stack;
}
//--------------------------------------------------------------------------------------------------------
public void run()
{
while(true)
{
try
{
int d = stack.sacarElemento();
System.out.println(getName() + ":" + d);
sleep((int) (Math.random()*1000));
}
catch (InterruptedException ex) {
Logger.getLogger(consumidor.class.getName()).log(Level.SEVERE, null, ex);
}
}
}

Saca el elemento de la pila. Y
espera un tiempo aleatorio.
El consumidor recibe la pila de
donde saca los datos.


Para garantizar que el productor y el consumidor utilizan la misma pila, estas se reciben como
parmetro en el constructor. El constructor de la interfaz instancia el productor y dos
consumidores y se les asigna una pila.

El update de la interfaz muestra el ArrayList de la pila en el JList.

En este punto el problema est resuelto, lo nico que hay que determinar es que pasa cuando
la pila no tenga elementos para entregar a alguno de los consumidores. Para resolver este
dilema se tiene que conocer el significado de las palabras reservadas syncronize, wait y notify.

public ventana()
{
initComponents();
setVisible(true);

bodega=new pila();
bodega.addObserver(this);

prod=new productor(bodega);
con1=new consumidor("Camilo", bodega);
con2=new consumidor("Juan", bodega);

prod.start();
con1.start();
con2.start();

}
Crea la pila y le agrega el observador
que es esta interfaz.
Se crea el productor y dos
consumidores que reciben la
misma pila.
Inicia todos los hilos.
{
if (o==bodega) //revisa que el objeto que notifico es la pila.
{
ArrayList<Integer> elem=((pila)arg).getElementos();
jList1.setListData(elem.toArray());
}
}


Los problemas que aqu se presentan son los siguientes:
La bodega solo la puede usar un consumidor a la vez, si otro la necesita, debe esperar.
Si la bodega esta vaca, el consumidor debe esperar a que haya otro elemento y la bodega le
debe notificar al o a los consumidores que esperan que ya hay una existencia disponible. La
pregunta que hay que responder es como comunicar el hilo del productor y el consumidor y
como evitar que dos hilos no utilicen la bodega al tiempo?, para esto se utilizan syncronized,
wait y notify.
Para que un consumidor solo pueda sacar un producto de la pila a la vez se usa syncronized.
Un bloque de cdigo con la etiqueta syncronized solo puede ser usado por un hilo a la vez.
Para definir que un mtodo va a ser sincronizado se coloca la palabra syncronized despus del
modificador de acceso.

Este mtodo solo puede ser usado por un hilo a la vez.
Cuando un hilo consumidor llegue al mtodo sacarElemento, este debe esperar mientras la
pila este vacia, ese tiempo de espera lo implementamos con wait.

public synchronized void agregarElemento(int elem)
{
this.notify();
setChanged();

}
public synchronized int sacarElemento()
{
while(elementos.size()==0)
{
try {
this.wait();
} catch (InterruptedException ex) {
}
int elem=elementos.remove(0);
setChanged();
return elem;
}
Dentro de este while se espera
mientras la pila este vacia. Dentro
del while se llama a notify para
que la bodega ponga a esperar al
hilo que pase por este mtodo
Cuando se libera el hilo que usa
este mtodo (recuerde que la pila
no es un hilo, la usan los hilos de
consumidor y productor) saca el
elemento de la pila y lo retorna.


Cuando se debe liberar el hilo puesto a esperar con wait?. El hilo debe dejar de esperar cuando
haya un nuevo producto y esto pasa cuando se agrega un elemento a la pila con el mtodo
agregarElemento.

En resumen:
Syncronized no permite que dos hilo utilicen el mismo bloque de cdigo.
Wait pone al hilo a esperar.
Notify saca al hilo de esa espera.
Todo wait debe tener un notify ya que de no ser asi hilo tiene la posibilidad de nunca salir del
estado de espera o lo que se llama un DeadLock.
public synchronized void agregarElemento(int elem)
{
this.notify();
//----------------------------------------
setChanged();

}
Esta clase notifica al hilo que tiene
esperando que ya puede continuar
su ejecucin. Este mtodo saca al
hilo que espera de este estado y
como la pila ya tiene elementos el
while(elementos.size()==0) de
sacarElementos es falso y la
ejecucin continua

Notas de Clase Pai2

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Notas de Clase Pai2

Cargado por

Copyright:

Formatos disponibles

1 INTRODUCCION

2009-I, Versin 4(20 de Marzo)

También podría gustarte