desarrollo de aplicaciones para la sociedad de la información tema 2- middleware social ejemplos...

Desarrollo de aplicaciones para la sociedad de la informaciónTema 2- Middleware social

Ejemplos

Máster Universitario en Sistemas Telemáticos e Informáticos

Juan Manuel Serranohttp://zenon.etsii.urjc.es/docencia/dasi

Content

URJC/MOSTI/DASI/Tema2/Ejemplos2

Gestión universitaria

Casino online

Normativa de referencia

COMPROBACION DOCUMENTACION

COMPULSA O COTEJO SI PROCEDE

REGISTRO GENERALo REGISTROS AUXILIARES

RESGUARDO DE ENTREGA INTERESADO

ASIENTO REGISTRAL

RECEPCION DE ENTREGA

UNIDADES ADMINISTRATIVA

S

REGISTRO GENERAL

CERTIFICACION DOCUMENTACION

ARCHIVO RECEPCIONES

DOCUMENTO PARA REGISTRAR

COMPROBACION DOCUMENTACION

COMPULSA O COTEJO SI PROCEDE

REGISTRO GENERALo REGISTROS AUXILIARES

RESGUARDO DE ENTREGA INTERESADO

ASIENTO REGISTRAL

RECEPCION DE ENTREGA

UNIDADES ADMINISTRATIVA

S

REGISTRO GENERAL

CERTIFICACION DOCUMENTACION

ARCHIVO RECEPCIONES

DOCUMENTO PARA REGISTRAR


Normativa de referencia

Gestión universitaria (req. funcionales)

Las universidades son instituciones de enseñanza superior que ofertan títulos académicos de grado y postgrado en distintas áreas de conocimiento. Para conseguir un título universitario en un plan de estudios determinado los miembros de la comunidad deben matricularse como alumnos de la correspondiente carrera de grado o máster. Las carreras de grado son gestionadas por una escuela o facultad de la universidad. Los másteres son gestionados por las escuelas o facultades, así como por los departamentos de la universidad, siendo posible que un mismo máster esté gestionado por más de un departamento. Los planes de estudios de las distintas carreras (de grado o postgrado) se estructuran en varios niveles, cada uno de los cuales consta de varias asignaturas (obligatorias, optativas y de libre elección) con un número de créditos determinado. Para superar la carrera los alumnos deben obtener una calificación de apto en todas la asignaturas obligatorias y superar un número mínimo de créditos optativos y de libre elección.


Los departamentos o facultades pueden nombrar coordinadores para facilitar la gestión de las carreras. El coordinador deberá pertenecer al personal docente e investigador (PDI) de los departamentos o escuelas, es decir, ser Titular de Universidad (TU), Contratado Doctor (CD), etc. Cada curso académico, los alumnos se matriculan en los cursos donde se imparten las asignaturas que desean aprobar ese año. Para ello, los alumnos deberán ser calificados como aptos en las pruebas teóricas y prácticas especificadas por los profesores de la asignatura. Los profesores preparan a los alumnos para superar dichas pruebas por medio de clases teóricas y prácticas llevadas a cabo en las aulas docentes y laboratorios de las escuelas, salas de reuniones de los departamentos, etc. Asimismo, los alumnos (individualmente o en grupo) pueden celebrar tutorías con los profesores, normalmente de forma presencial en sus despachos.


Los alumnos también pueden expresar sus opiniones, o hacer comentarios personales sobre el desarrollo y el contenido de la asignatura en sus blogs particulares. Los cursos disponen, asimismo, de un foro de discusión abierto a todos sus miembros (profesores y alumnos). Para cada práctica y examen los profesores deben definir el enunciado que establece los objetivos a alcanzar por los alumnos así como las normas de evaluación de la prueba correspondiente (plazos de entrega, puntuaciones parciales, etc.). Las pruebas prácticas suelen ser realizadas por grupos de varios alumnos. Una vez realizadas, éstas son remitidas para su evaluación a los profesores responsables de la práctica. Una vez publicados los resultados de la evaluación (tanto de exámenes como prácticas), los alumnos disponen de un plazo de tiempo para solicitar la revisión de los mismos.

Escenario

uah:universidad

cam:comunidad

urjc:universidad

etsii:escuela gsyc:departamento dcc:departamento

gii:grado hwsw:máster libre:mástersti:máster

dasi:curso

2ª:práctica1ª:práctica

:evaluación

:revisión

:grupo

:blog 6/9/10:clase

:grupo

10-11:cursoAcadémico

rasi:curso

:agente

:alumno

:agente

:alumno:alumno

:alumno

:alumno

:título

:planEstudios:asignatura

:calificación

:prueba

:despacho

:enunciado

:calificación

:solución

:TU:CD :PDI

:coordinador

:profesor

:foro

:alumno

:post:post

:aula:sala

:tutoría:alumno

cam: comunidad

urjc: universidad

gsyc: departamento


Atributos genéricos

dcc: departamento

sti: máster{state=open, context=dcc, context=gsyc}

10-11: curso_académico{state=open, context=sti , subinteraction=dasi}

dasi: curso{state=open, context=10-11, member=jms@dasi, ...

participant=jms@dcc, participant=a1@sti, ...environment=p1, environment=t1, ...}

jms@dcc:PDI

p1:prueba

jms: agente

state= playingcontext= camrole= jms@dcc

jms@dasi:profesor dasi:asignaturastate=createdcontext=sti

state= playing player= jms@cam

context= dcc

t1:tema1state=createdcontext=dasi

a1: agente

state= suspended

context= cam

a1@sti: alumno

state=suspended

player=a1@cam

context=sti

: alumno

state= suspendedplayer= a1@sticontext= dasistate=created

context=dasi

state= playingplayer= jms@dcccontext= dasi

cam: comunidad

urjc: universidad

gsyc: departamento


Atributos dependientes del dominio

dcc: departamento

sti: máster{plan_estudios=pe1, #egresados=???, ...}

10-11: curso_académico{sala=170DII, ...}

dasi: curso{asignatura=dasi, horario=L 18-20, ...}

jms@dcc:PDI

p1:prueba

jms: agente

nombre= “Juan”

foto= ....

:profesorimparte=t

1imparte=t

2evalúa=p1

nombre=“.....”tema=t1tema=t2 tema=t3 peso=50%

dasi:asignaturacréditos=3

obligatoria=yes

tutorías= L 15-18 tutorías= X

16-19imparte= dasi

t1:tema1nombre=“.....”semana=1

a1: agente

nombre= “...”foto= ....

a1@sti: alumno

aprobó=rasicréditos=3

...

: alumno

aprobó= p1...

Dinámica

La actividad en un proceso de prácticas comienza en la fase de preparación. En esta fase, los profesores se encargan de redactar el enunciado de la prueba práctica, en el que se especifican, entre otros aspectos, los componentes de la solución y la fecha de entrega. Todos estos aspectos estarán especificados mediante atributos del tipo de recurso enunciado, y la creación del enunciado se llevará a cabo mediante una declaración del tipo create. Una vez creado, el profesor publica el enunciado para que los alumnos puedan comenzar el desarrollo de la práctica. La forma concreta en la que esta publicación se lleva a cabo es la siguiente: el profesor declara que la nueva fase del proceso es desarrollo y este cambio de fase es notificado automáticamente a todos los alumnos que tengan pendiente la aprobación de esta prueba práctica. En ese momento, los alumnos pueden comenzar el desarrollo de la práctica mediante la creación de los grupos de prácticas correspondientes.

Dinámica

En el escenario que estamos analizando, un alumno (a1) crea un grupo de prácticas y notifica a un compañero suyo (a2) esta creación. La creación del grupo de prácticas consiste básicamente en el inicio de una interacción del tipo correspondiente, por lo que esta acción se lleva a cabo mediante una declaración del tipo set up. La notificación a su compañero se realiza añadiéndole en el campo de destinatarios de la declaración. Tras la creación del grupo, el alumno que realizó la declaración pasa a formar parte de él automáticamente. No así el que recibe la notificación (a2), por lo que este alumno tiene libertad para unirse al nuevo grupo, a otro existente o crear el suyo propio. En este caso, una vez recibida la notificación, el alumno a2 decide unirse al grupo que se acaba de crear (mediante una declaración de tipo join). El número de alumnos por grupo debe ser tres, por lo que el grupo sigue abierto a nuevos miembros. El escenario muestra la consulta que realiza otro alumno del curso (a4) sobre los grupos disponibles para realizar la práctica. Esta consulta la realiza mediante una observación del atributo subinteraction de la interacción social p1 (que representa el proceso de prácticas), en la que se especifica que las subinteracciones consultadas son grupos de prácticas (es decir, del tipo grupo) con menos de tres alumnos.

Dinámica

Este alumno decide preguntar a los alumnos del grupo recién creado si puede realizar la práctica conjuntamente con ellos. Para realizar esta pregunta, el alumno simplemente trata de unirse al grupo mediante una declaración de tipo join; como este alumno no se encontraba entre los destinatarios de la declaración de creación del grupo, la declaración no se ejecuta inmediatamente sino que queda en suspenso (pending). Cuando los miembros del grupo son notificados de este intento de unión pueden permitir (allow) o prohibir (forbid) su ejecución. En el primer caso, la declaración del alumno finalizaría sin haberse podido ejecutar; en el segundo, la declaración se ejecutaría y el alumno pasaría a formar del grupo. En nuestro escenario, los miembros del grupo se habían comprometido previamente (out-of-band) con otro compañero (el alumno a3), por lo que rechazan su petición y proceden a invitar al nuevo compañero.

Dinámica

La invitación es un nuevo proceso por el cual se ofrece a uno o varios agentes la posibilidad de desempeñar un nuevo rol si así lo desean. El proceso de invitación a un alumno para formar parte del grupo de prácticas se crea mediante una declaración set up; en ese momento, el agente que creó el proceso pasa a formar parte de él como invitador y puede invitar a los alumnos que quiera, de uno en uno, hasta que uno de ellos acepte. La invitación se produce mediante la creación por parte del invitador de un rol (invitee) para el alumno al que se desea invitar. La invitación se realiza, por tanto, mediante una declaración estándar de tipo assign. El alumno que recibe una invitación tiene dos opciones: aceptarla o rechazarla. Lo segundo se puede realizar simplemente mediante el abandono del rol invitee; es decir, mediante la realización de un acto de habla de tipo leave. La aceptación se puede realizar mediante un acto de habla de tipo close, es decir, forzando el cierre del proceso de invitación. Esto es consistente con el propósito del proceso, dado que una vez que el alumno acepte la invitación no tiene sentido que siga existiendo. En nuestro escenario, el alumno a3 al que se dirigió inicialmente la invitación la rechaza finalmente, por lo que los miembros del grupo deciden invitar al alumno a4. Este alumno cierra el proceso de invitación, aceptando de esa manera formar parte del grupo.

Dinámica

La fase de desarrollo del proceso de prácticas finaliza automáticamente cuando vence la fecha especificada en el enunciado; en ese momento empieza la fase de evaluación. En cualquier momento hasta que se produzca este cambio de fase, los alumnos pueden crear una solución para la práctica y remitirla para su evaluación. La creación y modificación de la solución de la práctica se realiza mediante declaraciones de tipo create y declare. La entrega de la práctica conlleva crear un proceso de evaluación para ella, por lo que dicha entrega se puede realizar simplemente mediante una declaración de tipo set up. El inicio de un proceso de este tipo conlleva automáticamente la creación de un rol de evaluador para el profesor responsable de la práctica. Cuando los profesores terminen de corregir las prácticas y hayan creado las calificaciones correspondientes (create), declararán la nueva fase de revisión. Este cambio de fase será notificado a los alumnos, los cuales podrán a partir de ese momento acceder a sus calificaciones (mediante acciones observe).

Dinámica

Si los alumnos no están de acuerdo con la evaluación o quieren más detalles sobre la misma, pueden iniciar un proceso de revisión (set up) antes de determinada fecha límite (especificada también en el enunciado de la práctica). Si los alumnos no solicitan una revisión antes de dicha fecha, el proceso de evaluación finalizará automáticamente. El inicio de un proceso de revisión conlleva automáticamente la creación de un rol para el evaluador de la práctica. En este contexto, el evaluador podrá realizar cambios en la calificación mediante el acto de habla estándar declare, dirigido a determinados atributos como, por ejemplo, la nota. El proceso de revisión finalizará cuando el evaluador lo considere oportuno mediante una declaración de cierre (close). En ese momento, finalizará también el proceso de evaluación, dando por definitiva la calificación y generándose las calificaciones particulares para cada alumno del curso en la prueba práctica asociada al proceso. A su vez, la finalización del proceso de evaluación conlleva la finalización del grupo de prácticas. Por último, cuando finalicen todos los grupos de prácticas finalizará automáticamente el proceso de prácticas.

Dinámica

:curso

p1:practica{ fase= preparación }

:Grupo

:invitation

:evaluación

:alumno

:calificación

a2:alumno

a1:alumno

:inviter

:alumno

:invitee

:setUp{addressee=a2

}

a3:alumno

:assign

:join

:alumno

a4:alumno

:solución

:create

:revisión

:alumno

:evaluador

:evaluador

:close

:alumno

:setUp

:profesor

p1:profesor

:enunciado{entrega=15/11/10,revision=18/11/10}

:setUp

:Forbid

desarrolloevaluación

revisión

:create

:close

:setUp:leave

:declare

:calificación

:calificación

:calificación

:join

:declare

:declare

:create

Procesamiento de attempts (unempowered)

:curso

p1:practica{prueba=pp1}

a1:Alumno

:Component

:attempt performer= a1

action=“<say>...</say>”

<say> <dictum> <setUp context=“p1”> <new><interaction type=“practica::grupo”/></new> </setUp> </dictum></say>

:rule“Los alumnos que no hayan superado aún la prueba y no participen todavía en ningún grupo están capacitados para crear grupos de prácticas”

aprobó(pp1)=trueempowered (“<say>..” ) =false

Procesamiento de attempts (forbidden)

:curso

p1:practica{fase=preparación}

a1:Alumno

α1:SetUpstate=pendingnew=g1

context=p1

performer=a1

permitted=false

:Component

:Attempt performer= a1

action=“<say>...</say>”


aprobó(pp1)=false empowered (“<say>..” ) =true

state=forbidden

:rule“Se permite a un alumno crear un nuevo grupo de prácticas si el enunciado ha sido publicado y no ha vencido la fecha límite de entrega”

Procesamiento de attempts (successful)

:curso

p1:practica{fase=desarrollo}

g1:grupo{initiator=a1}

a1:alumno

α1:setUpstate=pendingnew=g1

context=p1

performer=a1

permitted=true

:Component

:attempt performer= a1, action=“<say>...</say>”


aprobó(pp1)=false empowered (“<say>..” ) =true

:Initiate

:execute

state=executed

Reglas de autorizaciones y permisos

ACTION EMPOWERMENTS PERMISSIONS

Join a course as a student

none -

Set up a tutoring meeting with a course teacher

Estudiantes del curso en el que imparte clase el profesor

El profesor es el tutor designado para el alumno

El estudiante no está participando actualmente en ninguna otra tutoría

Set up a working group within an assignment process

Estudiantes que no hayan aprobado aún la práctica y no participen todavía en ningún grupo

El enunciado de la práctica ha sido publicado y el plazo para la entrega de soluciones no ha expirado aún

Join a working group

Estudiantes que no hayan aprobado aún la práctica no participen todavía en ningún grupo

El plazo para la entrega de soluciones no ha expirado aún

El número actual de miembros del grupo es inferior al máximo permitido

Reglas de autorizaciones y permisos

ACTION EMPOWERMENTS PERMISSIONS

Alow/Forbid some student to join a working group

Estudiantes del grupo de prácticas

True (es decir, no hay restricciones de ningún tipo)

Leave a working group

El agente que desempeña el rol (condición predefinida)

Si la práctica no ha sido remitida aún

Close an assignment evaluation group

Cualquier profesor responsable de la práctica

True

Leave a student role played within a course

El agente que desempeña el rol (condición predefinida)

Si no ha remitido ninguna práctica o participado en alguna examinación

Content


Gestión universitaria

Casino online

Casino (requisitos funcionales)

Un casino proporciona a sus clientes la posibilidad de disputar partidas de póquer. Para ello, los clientes deben adquirir fichas en el cajero del casino, las cuales pueden cambiar de nuevo por dinero de curso legal cuando así lo deseen. El número mínimo de jugadores para una partida de póquer es dos. En la variedad Texas Holdem con límites fijos, las partidas deben especificar el tamaño de la apuesta pequeña y grande (small bet y big bet). Una partida de póquer se estructura en una serie de manos, en cada una de las cuales se reparten las cartas. El jugador que reparte la cartas (dealer) va rotando conforme avanza la partida. Las manos se estructuran en una serie de rondas de apuestas, que en el caso de la variedad Texas Holdem se denominan pre-flop, flop, turn y river. En la primera fase (pre-flop) se reparten dos cartas a cada jugador (denominadas pocket cards); en las rondas restantes, se repartirán cinco cartas más que serán compartidas por todos los jugadores (tres en la fase flop, y dos más en las fases turn y river). La cantidad total apostada en las distintas rondas se contabiliza en el bote de la mano. En una ronda concreta, los distintos jugadores habrán apostado una determinada cantidad (bet), que podrá ser inferior a la cantidad máxima apostada hasta el momento. Llegado su turno, el jugador podrá igualar o subir la apuesta, o abandonar.

Escenario (estática)

:partida_póquer

:casino

:partida_póquer{dealer=p4, small_bet=20,

big_bet=40}

:mano{fase=flop,bote=40}

:ronda{bet=20,turno=p3}

:cliente{fichas=100} :cliente:cajero

p1:jugador

p2:jugador p3:jugador

p4:jugador

p1:jugador{next=p3}

p4:jugador{next=p1}

p3:jugador{next=p4}

p1:jugador{bet=20}

p4:jugador{bet=20}

p3:jugador{bet=0}

:carta

:carta

:carta

:carta

pocket

flop

Escenario (dinámica)

La siguiente transparencia ilustra la dinámica del middleware social Speech mediante la respuesta del middleware ante el intento realizado por un componente de que su agente inicie una nueva partida de póquer

El componente pretende, asimismo, comunicar la ejecución de la declaración a otro cliente del casino En primer lugar, el middleware comprueba si el cliente que desempeña dicho componente está

capacitado para iniciar nuevas partidas Dado que el cliente tiene suficiente dinero, el middleware crea el acto de habla

La creación del acto de habla (un nuevo cambio de estado) conlleva una reacción del middleware encaminada a la comprobación de los permisos de ejecución

Dado que el cliente no está participando actualmente en ninguna otra parte, la declaración setUp se ejecuta

De acuerdo con el propósito especificado para este tipo de declaraciones, la ejecución de una acción setUp conlleva el inicio de la nueva interacción en el contexto de ejecución de la acción

Como resultado se generan dos eventos (cambios de estado): se ejecuta una acción social y se crea una nueva interacción

De acuerdo con las reglas de notificación estándar, la ejecución del acto de habla se notifica a sus destinatarios (y también a su realizador, aunque no se muestra en la animación)

El inicio de una nueva partida conlleva automáticamente la creación de un nuevo rol de jugador para el cliente que la inició

De acuerdo con las reglas de notificación estándar, la creación de un nuevo rol para un agente se le notifica automáticamente

Por último, la animación muestra cómo el componente de uno de los clientes puede observar los eventos recibidos por su agente, mediante la acción externa correspondiente



c1:casino

i1:partida_póquer{small_bet=20, big_bet=40, …}

a1:cliente

p1:jugador

:component

:Speaker

:attempt

:say

:initiate

α:SetUpstate=pendingnew=<…>context=c1

<<rule>>“los clientes con suficiente dinero están capacitados

para crear nuevas partidas”

<attempt> <performer>a1</performer> <action> <say> <dictum> <setUp> <new><partida_poquer small_bet=20 big_bet=40/></new> </setUp> </dictum> <addressee>a2</addressee> </say> </action> <context>c1</context></attempt>

state=executed

:execute<<rule>>

“el propósito de una declaración setUp es iniciar la nueva interacción en el contexto especificado”

<<rule>>“Se permite crear una partida si el cliente no está

participando ya en otra”

:play

<<rule>>“cuando un cliente inicia una partida entra a formar parte

automáticamente de ella como jugador”

a2:cliente

<<rule>>“la ejecución de un acto de habla

debe ser notificada a sus destinatarios”

:component

:observe

<<rule>>“la creación de un nuevo rol se notifica automáticamente a su

player”


• Inicialmente, el casino tiene 4 clientes y ninguna partida en juego. También contiene las cartas y las manos de póker válidas en el contexto del casino.

• Uno de los clientes decide iniciar una partida (attempt) mediante la correspondiente declaración (set up).

• Dado que no participa actualmente en ninguna otra partida se ejecuta la declaración (execute) y se crea la partida (initiate)

• El cliente entra automáticamente a formar parte de ella (play). Se establece que el dealer de la siguiente mano sea él.

• El resto de clientes del casino deciden unirse a la partida mediante la ejecución de las correspondientes declaraciones (join)

• El orden de juego (atributo next) se define en función del orden de entrada en la partida (el valor de estos atributos se ha ido inicializando y actualizando conforme entran los clientes a la partida)

• Una vez listos todos los jugadores, el dealer decide iniciar la mano (setUp). • Los jugadores entran en la mano automáticamente. • La mano se inicia en un estado de ‘barajeo’. En este estado se crea la baraja

(sin cartas aún).• Y se introducen cartas elegidas aleatoriamente (push).• Hasta que la baraja tiene trece cartas.

c1:casino

t1:game{dealer=p1}

29

:client{chips=100}

:client{chips=600}

p4:player{next=p1}

:card :pokerHand

:client{chips=400}

:client{chips=300}

p3:player{next=p4}

p2:player{next=p3}

p1:player{next=p2}

:setUp{new=t1, context=c1}

:join{as=p2, context=t1}



:hand{state=shuffling}

hp1:player{next=hp2}




:deck{size=13}

attempt

push

execute

play

:setUp

initiate


• En la siguiente fase (reparto) se reparten las cartas comenzando con el jugador siguiente al ‘button’ (el dealer de la mano).

• Las cartas se reparten extrayendo (pop) de la baraja una carta

• y asignándosela al jugador correspondiente (generando el evento hole(..)=..)

• Se reparten las siete cartas restantes siguiendo el mismo procedimiento

c1:casino

:client{chips=10}

:client{chips=10}

:client{chips=10}

:client{chips=10}

t1:game{dealer=p1}

:hand{state=dealing, button=hp1, dealing_turn=...}

31

p3:player{next=p4}

p2:player{next=p3}

p1:player{next=p2}





:deck{top=..., size=...}

:card

hole

:card

hole

:card

hole

:card

hole

pop

hole(hp2)=c1

p4:player{next=p1}


• Una vez repartidas las cartas, la mano entra en la fase ‘pre-flop’, en la que los jugadores hp2 y hp3 actúan como small y big blind, respectivamente. Al comienzo de esta fase se inicializa también el bote (a 0) y se determina quién es el jugador inmediatamente a continuación del dealer (atributo first).

• Inmediantemente, se crea también la ronda de apuestas. La apuesta máxima actual se inicializa a 0, se determina quién tiene que empezar a hablar (turn) y quién tiene que terminar (last).

• Inmediatamente también, entran automáticamente en la ronda los jugadores de la mano. La apuesta realizada por cada uno de ellos se inicializa a 0.

:casino

t1:game{small_bet=20, big_bet=40}

:hand{state=pre-flop, small_blind=hp2, big_blind=hp3, pot=0, first=hp2}

33

p3:player{next=p4}

p2:player{next=p3}

p1:player{next=p2}





:round{bet=0, last=rp3, turn=rp4}

rp3:player{bet=0}

rp2:player{bet=0}

rp4:player{bet=0}

rp1:player{bet=0}

p4:player{next=p1}

:client{chips=...}

:client{chips=...}

:client{chips=...}

:client{chips=...}


• Se realiza automáticamente la contribución del small y el big blind (post 10 y post 20). Como consecuencia de ello, los chips disponibles para cada jugador se decrementan de acuerdo con la cantidad contribuida (chips(...)=390, para el small blind).

• Habla en primer lugar el siguiente jugador al big blind, e iguala la apuesta máxima actual. La ejecución del acto de habla call resulta en una contribución de 20 chips.

• Ídem el jugador rp1

:casino


:hand{state=pre-flop, small_blind=hp2, big_blind=hp3, pot=0}

35

p3:player{next=p4}

p2:player{next=p3}

p1:player{next=p2}





:round{bet=..., last=rp3, turn=...}

rp3:player{bet=20} rp2:player

{bet=10}


{bet=20}

p4:player{next=p1}

:client{chips=...}

:client{chips=...}

:client{chips=...}

:client{chips=...}

:call:call

post(20)

post(20)post(20)

post(10)

chips(..)=390


• El small blind también iguala la apuesta máxima (lo cual resulta solamente en una contribución 10 chips, puesto que ya había añadido anteriormente los 10 de la small blind).

• Cuando le llega el turno al big blind, decide no incrementar la apuesta y pasa (check).

• Como el big blind era el último en hablar, la ronda de apuestas finaliza automáticamente (finish)

• Forzando el abandono de los jugadores de la ronda (abandon)

• Lo cual causa que la cantidad apostada por cada uno de ellos pase a formar parte del bote de la mano. Tras el primer abandono el pot pasa a contener 20 chips.

• El bote se incrementa en tres ocasiones más, terminando con un valor de 80 chips.

:casino


:hand{state=pre-flop, small_blind=hp2, big_blind=hp3, pot=...}

37

p3:player{next=p4}

p2:player{next=p3}

p1:player{next=p2}







{bet=20}


{bet=20}

p4:player{next=p1}

:client{chips=580}

:client{chips=280}

:client{chips=80}

:client{chips=380}

:call

post(10)

:check

pot(...)=20pot(...)=40

pot(...)=60pot(...)=80

finish

abandon


• Cuando finaliza la ronda de apuestas da comienzo la fase flop.• Primero se generan las tres cartas • Y a continuación se inicia la ronda de apuestas, pasando de nuevo a formar

parte de ella los jugadores de la mano.• El primero en hablar en esta y en las siguientes rondas de apuestas es el

jugador inmediatamente a continuación del dealer, en este caso hp2. El jugador pasa (check).

• El siguiente jugador apuesta, de tal manera que el último jugador en hablar (si nadie sube la apuesta) será rp2.

• El siguiente abandona (fold). El bote de la mano se incrementa con lo apostado por el jugador, en este caso 0, con lo cual se queda igual.

• Y, automáticamente, abandona también la mano (aunque no la partida). El siguiente jugador de hp3 pasa a ser hp1.

• El siguiente jugador iguala la apuesta. • Y el último en hablar la iguala también.• Con lo cual termina la ronda de apuestas.

:casino


:hand{state=flop, pot=80, first=hp2}

39

p3:player{next=p4}

p2:player{next=p3}

p1:player{next=p2}



hp3:player{next=...}


:round{bet=.., last=..., turn=..}

rp3:player{bet=..} rp2:player

{bet=..}


{bet=..}

p4:player{next=p1}

:client{chips=...}

:client{chips=...}

:client{chips=...}

:client{chips=...}

:fold:call

:check:raise

flop

:card

:call


• Comienza la siguiente fase (turn), con un incremento en el bote de 60 chips (lo apostado en total por los tres jugadores en la última ronda).

• En primer lugar se reparte la cuarta carta comunitaria (el turn)

• A continuación se crea la ronda de apuestas y los jugadores que todavía quedan activos en la mano pasan a formar parte de ella

• Habla primero rp2 y apuesta (en esta ronda y en la siguiente, las apuestas son iguales al big_bet)

• El siguiente jugador iguala la apuesta

• Y el último en hablar también.

• Finaliza la ronda.

:casino


:hand{state=turn, pot=140, first=hp2}

41

p3:player{next=p4}

p2:player{next=p3}

p1:player{next=p2}





rp3:player{bet=...} rp2:player

{bet=...}

rp1:player{bet=..}

p4:player{next=p1}

:client{chips=...}

:client{chips=...}

:client{chips=...}

:client{chips=...}:call

:raise:call

flop

:card :card

turn


• Comienza la última fase de apuestas (river) con un incremento en el bote de 120 chips.

• Se reparte el river

• Y se inicia la ronda de apuestas.

• El primero en hablar apuesta el big bet

• El siguiente abandona la mano

• Y el siguiente también

• En consecuencia, la ronda de apuestas termina.

:casino


:hand{state=river, pot=260, first=hp2}

43

p3:player{next=p4}

p2:player{next=p3}

p1:player{next=p2}




:round{bet=0, last=rp1, turn=...}


{bet=...}

rp1:player{bet=0}

p4:player{next=p1}

:client{chips=10}

:client{chips=10}

:client{chips=10}

:client{chips=10}:fold

:raise:fold

flop

:card :card

turn

:card

river


• Llegados a este punto, el bote se incrementa con los 40 chips apostados en la última ronda.

• Como sólamente queda un jugador en la mano, se declara a éste el único ganador, y su cuenta de chips se incrementa con las 300 unidades del bote. El saldo final del ganador es 580 chips (400 iniciales – 120 apostados por él + 120 apostados + 180 apostados por los demás).

• Al declararse un ganador se termina la mano sin necesidad de pasar a la fase de showdown.

:casino


:hand{pot=300,winner=p2}

45

p3:player{next=p4}

p2:player{next=p3}

p1:player{next=p2}

hp2:player

p4:player{next=p1}

:client{chips=...}

:client{chips=...}

:client{chips=...}

:client{chips=...}

flop

:card :card

turn

:card

river

chips(..)=580

desarrollo de aplicaciones para la sociedad de la información tema 2- middleware social ejemplos...

Documents