Upload
lucia-caro
View
106
Download
0
Embed Size (px)
Citation preview
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
URJC/MOSTI/DASI/Tema2/Ejemplos4
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.
Gestión universitaria (req. funcionales)
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.
Gestión universitaria (req. funcionales)
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
URJC/MOSTI/DASI/Tema2/Ejemplos9
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
URJC/MOSTI/DASI/Tema2/Ejemplos10
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>”
<say> <dictum> <setUp context=“p1”> <new><interaction type=“practica::grupo”/></new> </setUp> </dictum></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>”
<say> <dictum> <setUp context=“p1”> <new><interaction type=“practica::grupo”/></new> </setUp> </dictum></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
URJC/MOSTI/DASI/Tema2/Ejemplos23
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
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
URJC/MOSTI/DASI/Tema2/Ejemplos26
Escenario (dinámica)
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”
Escenario (dinámica)
• 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}
:join{as=p2, context=t1}
:join{as=p3, context=t1}
:hand{state=shuffling}
hp1:player{next=hp2}
hp2:player{next=hp3}
hp2:player{next=hp4}
hp2:player{next=hp1}
:deck{size=13}
attempt
push
execute
play
:setUp
initiate
Escenario (dinámica)
• 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}
hp1:player{next=hp2}
hp2:player{next=hp3}
hp3:player{next=hp4}
hp4:player{next=hp1}
:deck{top=..., size=...}
:card
hole
:card
hole
:card
hole
:card
hole
pop
hole(hp2)=c1
p4:player{next=p1}
Escenario (dinámica)
• 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}
hp1:player{next=hp2}
hp2:player{next=hp3}
hp3:player{next=hp4}
hp4:player{next=hp1}
: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=...}
Escenario (dinámica)
• 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
t1:game{small_bet=20, big_bet=40}
: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}
hp1:player{next=hp2}
hp2:player{next=hp3}
hp3:player{next=hp4}
hp4:player{next=hp1}
:round{bet=..., last=rp3, turn=...}
rp3:player{bet=20} rp2:player
{bet=10}
rp4:player{bet=20} rp1:player
{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
Escenario (dinámica)
• 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
t1:game{small_bet=20, big_bet=40}
:hand{state=pre-flop, small_blind=hp2, big_blind=hp3, pot=...}
37
p3:player{next=p4}
p2:player{next=p3}
p1:player{next=p2}
hp1:player{next=hp2}
hp2:player{next=hp3}
hp3:player{next=hp4}
hp4:player{next=hp1}
:round{bet=20, last=rp3, turn=rp4}
rp3:player{bet=20} rp2:player
{bet=20}
rp4:player{bet=20} rp1:player
{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
Escenario (dinámica)
• 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
t1:game{small_bet=20, big_bet=40}
:hand{state=flop, pot=80, first=hp2}
39
p3:player{next=p4}
p2:player{next=p3}
p1:player{next=p2}
hp1:player{next=hp2}
hp2:player{next=hp3}
hp3:player{next=...}
hp4:player{next=hp1}
:round{bet=.., last=..., turn=..}
rp3:player{bet=..} rp2:player
{bet=..}
rp4:player{bet=0} rp1:player
{bet=..}
p4:player{next=p1}
:client{chips=...}
:client{chips=...}
:client{chips=...}
:client{chips=...}
:fold:call
:check:raise
flop
:card
:call
Escenario (dinámica)
• 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
t1:game{small_bet=20, big_bet=40}
:hand{state=turn, pot=140, first=hp2}
41
p3:player{next=p4}
p2:player{next=p3}
p1:player{next=p2}
hp1:player{next=hp2}
hp2:player{next=hp3}
hp3:player{next=hp1}
:round{bet=40, last=rp1, turn=rp2}
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
Escenario (dinámica)
• 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
t1:game{small_bet=20, big_bet=40}
:hand{state=river, pot=260, first=hp2}
43
p3:player{next=p4}
p2:player{next=p3}
p1:player{next=p2}
hp1:player{next=hp2}
hp2:player{next=hp3}
hp3:player{next=hp4}
:round{bet=0, last=rp1, turn=...}
rp3:player{bet=0} rp2:player
{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
Escenario (dinámica)
• 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
t1:game{small_bet=20, big_bet=40}
: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