1 / 45

Desarrollo de aplicaciones para la sociedad de la información Tema 2- Middleware social Ejemplos

Desarrollo de aplicaciones para la sociedad de la información Tema 2- Middleware social Ejemplos. Máster Universitario en Sistemas Telemáticos e Informáticos Juan Manuel Serrano http://zenon.etsii.urjc.es/docencia/dasi. Content. Gestión universitaria. Casino online. Normativa de referencia.

starbuck
Download Presentation

Desarrollo de aplicaciones para la sociedad de la información Tema 2- Middleware social Ejemplos

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Desarrollo de aplicaciones para la sociedad de la informaciónTema 2- Middleware socialEjemplos Máster Universitario en Sistemas Telemáticos e Informáticos Juan Manuel Serrano http://zenon.etsii.urjc.es/docencia/dasi

  2. Content Gestiónuniversitaria Casino online URJC/MOSTI/DASI/Tema2/Ejemplos

  3. Normativa de referencia

  4. Normativa de referencia URJC/MOSTI/DASI/Tema2/Ejemplos

  5. Gestiónuniversitaria (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.

  6. Gestiónuniversitaria (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.

  7. Gestiónuniversitaria (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.

  8. :agente :agente :coordinador :profesor :PDI :CD :TU :alumno :alumno :alumno :alumno :alumno :alumno :alumno Escenario cam:comunidad :título urjc:universidad uah:universidad :sala gsyc:departamento dcc:departamento etsii:escuela :aula :despacho gii:grado hwsw:máster sti:máster libre:máster :asignatura :calificación :planEstudios 10-11:cursoAcadémico rasi:curso dasi:curso :prueba :calificación 2ª:práctica :foro 1ª:práctica :blog :tutoría 6/9/10:clase :enunciado :post :post :grupo :grupo :solución :evaluación :revisión

  9. Atributosgenéricos cam:comunidad a1: agente jms: agente state= suspended context= cam state= playing context= cam role=jms@dcc urjc:universidad gsyc: departamento dcc: departamento sti:máster {state=open, context=dcc,context=gsyc} a1@sti: alumno 10-11:curso_académico {state=open,context=sti ,subinteraction=dasi} jms@dcc:PDI state=suspended player=a1@cam context=sti state= playing player= jms@cam context= dcc dasi: curso {state=open, context=10-11, member=jms@dasi, ... participant=jms@dcc, participant=a1@sti, ... environment=p1, environment=t1, ...} : alumno jms@dasi:profesor state= playing player= jms@dcc context= dasi state= suspended player= a1@sti context= dasi state=created context=sti state=created context=dasi state=created context=dasi dasi:asignatura p1:prueba t1:tema1 URJC/MOSTI/DASI/Tema2/Ejemplos

  10. Atributosdependientes del dominio cam:comunidad a1: agente jms: agente nombre= “...” foto= .... nombre= “Juan” foto= .... urjc:universidad gsyc: departamento dcc: departamento sti:máster {plan_estudios=pe1, #egresados=???, ...} a1@sti: alumno 10-11:curso_académico {sala=170DII, ...} jms@dcc:PDI aprobó=rasi créditos=3 ... tutorías= L 15-18tutorías= X 16-19 imparte= dasi dasi: curso {asignatura=dasi, horario=L 18-20, ...} : alumno :profesor aprobó= p1 ... imparte=t1 imparte=t2 evalúa=p1 créditos=3 obligatoria=yes nombre=“.....” semana=1 nombre=“.....” tema=t1 tema=t2 tema=t3 peso=50% dasi:asignatura p1:prueba t1:tema1 URJC/MOSTI/DASI/Tema2/Ejemplos

  11. 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 elenunciado 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.

  12. 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 subinteractionde 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.

  13. 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.

  14. 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.

  15. 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).

  16. 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.

  17. Dinámica :curso :setUp {addressee=a2} p1:practica { fase= preparación } desarrollo :enunciado {entrega=15/11/10, revision=18/11/10} a3:alumno evaluación a1:alumno revisión :join :setUp :Grupo :setUp :calificación :leave :assign :close :join :invitation a4:alumno :alumno :alumno :Forbid :inviter :invitee :create a2:alumno :calificación :solución :calificación :alumno :create :evaluación :declare :calificación :declare p1:profesor :setUp :declare :create :close :profesor :revisión :alumno :evaluador :alumno :evaluador

  18. Procesamiento de attempts (unempowered) <say> <dictum> <setUp context=“p1”> <new><interaction type=“practica::grupo”/></new> </setUp> </dictum> </say> :attempt performer= a1 action=“<say>...</say>” :Component :curso p1:practica {prueba=pp1} :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” a1:Alumno aprobó(pp1)=true empowered (“<say>..”) =false

  19. Procesamiento de attempts (forbidden) <say> <dictum> <setUp context=“p1”> <new><interaction type=“practica::grupo”/></new> </setUp> </dictum> </say> :Attempt performer= a1 action=“<say>...</say>” :Component α1:SetUp state=pending new=g1 context=p1 performer=a1 permitted=false :curso state=forbidden p1:practica {fase=preparación} a1:Alumno :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” aprobó(pp1)=false empowered (“<say>..”) =true

  20. Procesamiento de attempts (successful) <say> <dictum> <setUp context=“p1”> <new><interaction type=“practica::grupo”/></new> </setUp> </dictum> </say> :attempt performer= a1, action=“<say>...</say>” :execute :Component α1:setUp state=pending new=g1 context=p1 performer=a1 permitted=true :curso state=executed p1:practica {fase=desarrollo} :Initiate g1:grupo {initiator=a1} a1:alumno aprobó(pp1)=false empowered (“<say>..”) =true

  21. 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 upa 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 Joina 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

  22. 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 Leavea 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

  23. Content Gestiónuniversitaria Casino online URJC/MOSTI/DASI/Tema2/Ejemplos

  24. Casino (requisitosfuncionales) 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 (smallbety bigbet). 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 pocketcards); 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 turny 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.

  25. :cliente Escenario (estática) :cajero :casino :cliente {fichas=100} p1:jugador p3:jugador {next=p4} p4:jugador {next=p1} p3:jugador p2:jugador p4:jugador p1:jugador {next=p3} :partida_póquer :partida_póquer {dealer=p4, small_bet=20, big_bet=40} :carta :carta :mano {fase=flop,bote=40} :carta :carta pocket flop :ronda {bet=20,turno=p3} p3:jugador {bet=0} p1:jugador {bet=20} p4:jugador {bet=20}

  26. Escenario (dinámica) URJC/MOSTI/DASI/Tema2/Ejemplos • 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

  27. Escenario (dinámica) :execute <<rule>> “el propósito de una declaración setUp es iniciar la nueva interacción en el contexto especificado” :attempt α:SetUp state=pending new=<…> context=c1 <<rule>> “Se permite crear una partida si el cliente no está participando ya en otra” :observe state=executed :say :component :component c1:casino <<rule>> “la ejecución de un acto de habla debe ser notificada a sus destinatarios” :Speaker a1:cliente :play <<rule>> “los clientes con suficiente dinero están capacitados para crear nuevas partidas” a2:cliente :initiate <<rule>> “la creación de un nuevo rol se notifica automáticamente a su player” i1:partida_póquer {small_bet=20, big_bet=40, …} <<rule>> “cuando un cliente inicia una partida entra a formar parte automáticamente de ella como jugador” p1:jugador <attempt> <performer>a1</performer> <action> <say> <dictum> <setUp> <new><partida_poquersmall_bet=20 big_bet=40/></new> </setUp> </dictum> <addressee>a2</addressee> </say> </action> <context>c1</context> </attempt>

  28. Escenario (dinámica) • Inicialmente, el casino tiene 4 clientes y ningunapartida en juego. Tambiéncontienelascartas y lasmanos de pókerválidas en el contexto del casino. • Uno de los clientes decide iniciarunapartida (attempt) mediante la correspondientedeclaración (set up). • Dado que no participaactualmente en ningunaotrapartida se ejecuta la declaración (execute) y se crea la partida (initiate) • El clienteentraautomáticamente a formar parte de ella (play). Se estableceque el dealer de la siguientemano sea él. • El resto de clientes del casino decidenunirse a la partidamediante la ejecución de lascorrespondientesdeclaraciones (join) • El orden de juego (atributo next) se define en función del orden de entrada en la partida (el valor de estosatributos se ha idoinicializando y actualizandoconformeentran los clientes a la partida) • Unavezlistostodos los jugadores, el dealer decide iniciar la mano (setUp). • Los jugadoresentran en la manoautomáticamente. • La mano se inicia en un estado de ‘barajeo’. En esteestado se crea la baraja (sin cartasaún). • Y se introducencartaselegidasaleatoriamente (push). • Hastaque la barajatienetrececartas.

  29. c1:casino attempt execute initiate :join {as=p2, context=t1} :setUp {new=t1, context=c1} :pokerHand :card t1:game {dealer=p1} play :setUp :hand {state=shuffling} p4:player {next=p1} p1:player {next=p2} :join {as=p3, context=t1} :join {as=p2, context=t1} push :deck {size=13} p3:player {next=p4} p2:player {next=p3} hp2:player {next=hp4} :client {chips=600} hp1:player {next=hp2} hp2:player {next=hp3} hp2:player {next=hp1} :client {chips=100} :client {chips=300} :client {chips=400}

  30. Escenario (dinámica) • En la siguientefase (reparto) se repartenlascartascomenzando con el jugadorsiguiente al ‘button’ (el dealer de la mano). • Las cartas se repartenextrayendo (pop) de la barajaunacarta • y asignándosela al jugadorcorrespondiente (generando el evento hole(..)=..) • Se repartenlassietecartasrestantessiguiendo el mismoprocedimiento

  31. c1:casino t1:game {dealer=p1} :hand {state=dealing, button=hp1, dealing_turn=...} :card :card :card :card pop :deck {top=..., size=...} hole hole hole(hp2)=c1 hole hole hp3:player {next=hp4} hp2:player {next=hp3} hp1:player {next=hp2} p1:player {next=p2} p2:player {next=p3} p3:player {next=p4} :client {chips=10} :client {chips=10} :client {chips=10} :client {chips=10} hp4:player {next=hp1} p4:player {next=p1}

  32. Escenario (dinámica) • Unavezrepartidaslascartas, la manoentra en la fase ‘pre-flop’, en la que los jugadores hp2 y hp3 actúancomo small y big blind, respectivamente. Al comienzo de estafase se inicializatambién el bote (a 0) y se determinaquiénes el jugadorinmediatamente a continuación del dealer (atributo first). • Inmediantemente, se creatambién la ronda de apuestas. La apuestamáxima actual se inicializa a 0, se determinaquiéntienequeempezar a hablar (turn) y quiéntienequeterminar (last). • Inmediatamentetambién, entranautomáticamente en la ronda los jugadores de la mano. La apuestarealizadaporcadauno de ellos se inicializa a 0.

  33. :casino t1:game {small_bet=20, big_bet=40} :hand {state=pre-flop, small_blind=hp2, big_blind=hp3, pot=0, first=hp2} :round {bet=0, last=rp3, turn=rp4} 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} rp2:player {bet=0} :client {chips=...} rp4:player {bet=0} rp1:player {bet=0} p4:player {next=p1} :client {chips=...} :client {chips=...} rp3:player {bet=0} :client {chips=...}

  34. Escenario (dinámica) • Se realizaautomáticamente la contribución del small y el big blind (post 10 y post 20). Como consecuencia de ello, los chips disponiblesparacadajugador se decrementan de acuerdo con la cantidadcontribuida (chips(...)=390, para el small blind). • Habla en primer lugar el siguientejugador al big blind, e iguala la apuestamáxima actual. La ejecución del acto de habla call resulta en unacontribución de 20 chips. • Ídem el jugador rp1

  35. :casino t1:game {small_bet=20, big_bet=40} :hand {state=pre-flop, small_blind=hp2, big_blind=hp3, pot=0} :round {bet=..., last=rp3, turn=...} :call :call post(20) post(20) rp4:player {bet=20} chips(..)=390 rp1:player {bet=20} post(10) rp3:player {bet=20} rp2:player {bet=10} post(20) p3:player {next=p4} p2:player {next=p3} p1:player {next=p2} hp1:player {next=hp2} :client {chips=...} :client {chips=...} hp3:player {next=hp4} :client {chips=...} p4:player {next=p1} hp2:player {next=hp3} :client {chips=...} hp4:player {next=hp1}

  36. Escenario (dinámica) • El small blind tambiéniguala la apuestamáxima (lo cualresultasolamente en unacontribución 10 chips, puestoqueyahabíaañadidoanteriormente 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 apuestasfinalizaautomáticamente (finish) • Forzando el abandono de los jugadores de la ronda (abandon) • Lo cualcausaque la cantidadapostadaporcadauno de ellospase a formar parte del bote de la mano. Tras el primer abandono el pot pasa a contener 20 chips. • El bote se incrementa en tresocasionesmás, terminando con un valor de 80 chips.

  37. :casino t1:game {small_bet=20, big_bet=40} pot(...)=20 pot(...)=40 pot(...)=60 pot(...)=80 :hand {state=pre-flop, small_blind=hp2, big_blind=hp3, pot=...} finish :round {bet=20, last=rp3, turn=rp4} abandon rp4:player {bet=20} rp1:player {bet=20} :check :call post(10) rp3:player {bet=20} rp2:player {bet=20} p3:player {next=p4} p2:player {next=p3} p1:player {next=p2} hp1:player {next=hp2} :client {chips=380} :client {chips=80} :client {chips=280} :client {chips=580} p4:player {next=p1} hp2:player {next=hp3} hp4:player {next=hp1} hp3:player {next=hp4}

  38. Escenario (dinámica) • Cuandofinaliza la ronda de apuestasdacomienzo la fase flop. • Primero se generanlastrescartas • 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 lassiguientesrondas de apuestases el jugadorinmediatamente a continuación del dealer, en estecaso hp2. El jugadorpasa (check). • El siguientejugadorapuesta, de talmaneraque el últimojugador en hablar (sinadiesube la apuesta) será rp2. • El siguienteabandona (fold). El bote de la mano se incrementa con lo apostadopor el jugador, en estecaso 0, con lo cual se quedaigual. • Y, automáticamente, abandonatambién la mano (aunque no la partida). El siguientejugador de hp3 pasa a ser hp1. • El siguientejugadoriguala la apuesta. • Y el último en hablar la igualatambién. • Con lo cualtermina la ronda de apuestas.

  39. :casino t1:game {small_bet=20, big_bet=40} :hand {state=flop, pot=80, first=hp2} :card flop :round {bet=.., last=..., turn=..} :fold :call :raise :check :call p3:player {next=p4} p2:player {next=p3} p1:player {next=p2} hp1:player {next=hp2} hp2:player {next=hp3} :client {chips=...} :client {chips=...} hp3:player {next=...} :client {chips=...} p4:player {next=p1} rp1:player {bet=..} hp4:player {next=hp1} rp2:player {bet=..} rp3:player {bet=..} :client {chips=...} rp4:player {bet=0}

  40. Escenario (dinámica) • Comienza la siguientefase (turn), con un incremento en el bote de 60 chips (lo apostado en total por los tresjugadores en la últimaronda). • En primer lugar se reparte la cuartacartacomunitaria (el turn) • A continuación se crea la ronda de apuestas y los jugadoresquetodavíaquedanactivos en la manopasan a formar parte de ella • Hablaprimero rp2 y apuesta (en estaronda y en la siguiente, lasapuestas son iguales al big_bet) • El siguientejugadoriguala la apuesta • Y el último en hablartambién. • Finaliza la ronda.

  41. :casino t1:game {small_bet=20, big_bet=40} :hand {state=turn, pot=140, first=hp2} :card :card flop turn :round {bet=40, last=rp1, turn=rp2} :call :call :raise hp3:player {next=hp1} rp3:player {bet=...} rp2:player {bet=...} p1:player {next=p2} p4:player {next=p1} :client {chips=...} p3:player {next=p4} :client {chips=...} :client {chips=...} p2:player {next=p3} hp1:player {next=hp2} hp2:player {next=hp3} :client {chips=...} rp1:player {bet=..}

  42. Escenario (dinámica) • Comienza la últimafase 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 hablarapuesta el big bet • El siguienteabandona la mano • Y el siguientetambién • En consecuencia, la ronda de apuestastermina.

  43. :casino t1:game {small_bet=20, big_bet=40} :hand {state=river, pot=260, first=hp2} :card :card :card river flop turn :round {bet=0, last=rp1, turn=...} :fold :fold :raise hp3:player {next=hp4} rp3:player {bet=0} rp2:player {bet=...} rp1:player {bet=0} p1:player {next=p2} :client {chips=10} hp2:player {next=hp3} :client {chips=10} :client {chips=10} p2:player {next=p3} p3:player {next=p4} hp1:player {next=hp2} :client {chips=10} p4:player {next=p1}

  44. Escenario (dinámica) • Llegados a estepunto, el bote se incrementa con los 40 chips apostados en la últimaronda. • Como sólamentequeda un jugador en la mano, se declara a éste el únicoganador, y sucuenta de chips se incrementa con las 300 unidades del bote. El saldo final del ganadores 580 chips (400 iniciales – 120 apostadosporél + 120 apostados + 180 apostadospor los demás). • Al declararse un ganador se termina la mano sin necesidad de pasar a la fase de showdown.

  45. :casino t1:game {small_bet=20, big_bet=40} :hand {pot=300,winner=p2} :card :card :card river flop turn chips(..)=580 :client {chips=...} :client {chips=...} p4:player {next=p1} hp2:player p1:player {next=p2} p2:player {next=p3} p3:player {next=p4} :client {chips=...} :client {chips=...}

More Related