Embed Size (px)
Citation preview
Desarrollo de aplicaciones para la sociedad de la información
PARTE IIIEstilo arquitectónico para el desarrollo de aplicaciones sociales
Entidades sociales
Juan Manuel Serrano
Objetivo
Conocer y saber aplicar los distintos tipos de abstracciones sociales utilizadas por Speech para modelar el estado de un proceso social: interacciones, agentes, recursos, actos de habla, invocaciones y observaciones
Índice
Entidades sociales
Atributos
Actos de habla
Acciones y eventos
Normas sociales
Abstracciones sociales
Las abstracciones del lenguaje Speech permiten modelar las interacciones entre los participantes de un proceso social
ENTIDADES SOCIALES Permiten modelar el estado de las interacciones
entre los participantes de un proceso social ACCIONES Y EVENTOS
Ejecutan y representan el cambio de estado NORMAS SOCIALES
Modelan las reglas que gobiernan la estructura y la dinámica del proceso social
Entidades sociales
Las entidades sociales son abstracciones “con estado” e “identidad” Forman parte de las instantáneas del proceso social
Hay dos tipos de participantes: Personas, representadas por agentes Servicios computacionales y de información,
representados por recursos Hay cuatro tipos de interacciones:
Interacciones sociales Actos de habla Observaciones Invocaciones
Acciones sociales
Personas - Agentes Las personas que participan en un proceso son los usuarios de
la aplicación social Las personas interactúan a través de la aplicación mediante
componentes software a los que llamamos agentes software (porque actúan en representación de las personas)
Los agentes software son heterogéneos y pueden tener distintos grados de complejidad Simples interfaces de usuario (por ejemplo, un navegador web –
user agent) Componentes inteligentes (con sofisticados procesos para el
soporte a la toma de decisiones) En cualquier caso, los agentes software son autónomos: su
estado no puede ser modificado por ningún otro participante del proceso
En la modelización mediante Speech, las características particulares (o internas) del agente software no son relevantes
Servicios - Recursos Además de los agentes software, en el proceso también participan
otros componentes software que proporcionan distintos tipos de servicios al resto de participantes del proceso Estos componentes software participan en el proceso como recursos
Servicios de representación y almacenamiento de información – recursos informacionales
Servicios de procesamiento de información – recursos computacionales Los componentes software que actúan en calidad de recursos son
también heterogéneos al igual que los agentes bases de datos relacionales, noSQL, … componentes Java, Python, Prolog, Lisp, etc.
… pero no son autónomos Su estado sí puede verse afectado por el resto de participantes del
proceso En cualquier caso, al igual que en los agentes, las características
internas de los recursos son irrelevantes para la modelización
Interacciones - Acciones e interacciones sociales
Los agentes participan en el proceso con un propósito, y para conseguirlo pueden hablar, observar e invocar servicios de recursos computacionales Cuando hablamos, observamos o invocamos servicios realizamos distintas
acciones sociales: actos de habla, observaciones e invocaciones Las acciones sociales son mecanismos de interacción atómicos
Las interacciones sociales proporcionan un mecanismo que permite estructurar las interacciones entre los distintos participantes del proceso en base a una jerarquía de contextos sociales La jerarquía de contextos es un grafo dirigido acíclico (una interacción
puede tener más de un contexto social) Las acciones sociales siempre tienen lugar en el contexto de una
interacción social Los participantes del proceso social actúan como agentes y recursos
desde un contexto particular de la jerarquía Los agentes de un contexto dado son sus miembros Los recursos de un contexto dado conforman su entorno
Mecanismos de modularidad
Las jerarquías de interacciones sociales proporcionan un mecanismo de modularidad – una forma de descomponer el problema de modelización en partes con un alto grado de cohesión y mínimo acoplamiento entre ellas Tienen el objetivo de facilitar la reutilización, mantenibilidad y
modificabilidad, pruebas, el reparto de trabajo entre los modelizadores, mejorar la comprensión del modelo, etc., etc.
Si el propósito de un agente es lo suficientemente complejo, su actividad se puede estructurar en términos de una jerarquía de desempeño de roles Se trata de un mecanismo de modularidad adicional a las jerarquías de
interacciones sociales El agente raíz de la jerarquía se denomina el top-level rol Los roles de un agente pueden ser desempeñados en contextos
arbitrarios de la jerarquía de interacciones: en su mismo contexto, en alguna subinteracción, en alguna super-interacción, o en interacciones de otra rama de la jerarquía
Agentes y recursos
:SocialMiddleware:Java
:Resource
:Jason
:2APL
:Java
:Python
:Perl
:Agent
:Agent
:Resource
:Agent
:Resource
HeterogéneosNO autónomos
HeterogéneosAUTÓNOMOS
Interacciones sociales
Actos de hablaObservacionesInvocaciones
Interacciones sociales y actos de habla
:SocialMiddleware:Java
:Resource
:Jason
:2APL
:Java
:Python
:Perl
:Agent
:Agent
:Resource
:Agent
:SocialInteraction
:Resource
:SpeechAct
:SpeechAct
:SpeechAct
Observaciones
:Resource
:Component
:Component
:Component
:Component
:Agent
:Agent
:Agent
:Observation
:Observation
:Observation
Invocación de operaciones
:Resource :Component:Component:Agent
:SocialInteraction
:Resource
:Component
:Invocation
:Invocation
14
Jerarquías de roles vs. interacciones sociales
......
...
...
...
player
role
role
role
role
role
top-levelrole
role
Diagrama estático de instancias
Permiten describir la estructura (de parte) del proceso social en un instante determinado
Muestran el estado de todas las entidades sociales que forman parte del proceso en ese instante la jerarquía de interacciones sociales, junto con los
tipos de dichas interacciones las instancias de agentes, junto con sus tipos y
jerarquías de desempeño de roles las posibles instancias de recursos, junto con los tipos
de dichas instancias las instancias de acciones sociales
Puede incluir también los atributos de las entidades (se verá más adelante)
Diagrama estático de instancias
ICONO LEYENDA
Social middleware
instancia de interacción social de tipo T con identificador id (se omite normalmente)
instancia de recurso
instancia de agente
id : T
id : T
id : T
Diagrama estático de instancias
ICONO LEYENDA
relación de desempeño de roles
jerarquía de interacciones sociales
instancia de acto de habla
instancia de observación
instancia de invocación
:T
:T
:T
Diagrama estático de tipos
Describen la estructura de los tipos de interacciones sociales, agentes y recursos que forman parte del modelo de la aplicación
Los diagramas se llevarán a cabo mediante un perfil UML Diagramas de casos de uso
Estructura general de las jerarquías de interacciones sociales y agentes
Diagramas de clases (más adelante) Incluyen los atributos característicos de las
instancias pertenecientes a los tipos modelizados
Diagrama estático de tipos (casos de uso)
ICONO LEYENDA
Tipo de interacción social T
Tipo de agente T
Tipo de recurso T
Tipo de acto de habla T
Tipo de invocación T
Tipo de observación T
Diagrama estático de tipos (casos de uso)
ICONOS LEYENDA
Restricciones a los tipos de miembros, recursos del entorno y subinteracciones de un tipo de interacción social dado; la cardinalidad indica el número de instancias de ese tipo que pueden ser miembros, etc.
Restricciones a los tipos de roles que pueden ser desempeñados por un tipo de rol dado; la cardinalidad indica el número de roles de ese tipo que pueden ser desempeñados
Un casino proporciona a sus clientes la posibilidad de disputar partidas de póquer utilizando fichas que pueden comprar en el cajero del casino. Una partida de póquer se estructura en una serie de manos, y éstas en distintas rondas de apuestas. En el caso de la variedad Texas Holdem éstas se denominan pre-flop, flop, turn y river. En la primera ronda se reparten dos cartas de la baraja a cada jugador; en las rondas restantes, se repartirán cinco cartas más que serán compartidas por todos los jugadores. La cantidad total apostada en las distintas rondas se contabiliza en el bote de la mano. Llegado su turno, el jugador podrá igualar, pasar, subir la apuesta o abandonar la mano. Un jugador gana la mano cuando todos los demás abandonan o ningún otro jugador tiene mejor jugada que él.
Un casino proporciona a sus clientes la posibilidad de disputar partidas de póquer utilizando fichas que pueden comprar en el cajero del casino. Una partida de póquer se estructura en una serie de manos, y éstas en distintas rondas de apuestas. En el caso de la variedad Texas Holdem éstas se denominan pre-flop, flop, turn y river. En la primera ronda se reparten dos cartas de la baraja a cada jugador; en las rondas restantes, se repartirán cinco cartas más que serán compartidas por todos los jugadores. La cantidad total apostada en las distintas rondas se contabiliza en el bote de la mano. Llegado su turno, el jugador podrá igualar, pasar, subir la apuesta o abandonar la mano. Un jugador gana la mano cuando todos los demás abandonan o ningún otro jugador tiene mejor jugada que él.
Póquer – Texas Hold’em
Diagrama estático de instancias
:partida
:casino
:partida
:mano
:ronda
:cliente:cliente
:cajero
:jugador
:jugador:jugador
:jugador
:jugador :jugador
:jugador :jugador
:carta
:carta
:jugada:jugada
:carta:baraja
:pasar
:comprar
Diagrama estático de tipos
El máster de sistemas telemáticos e informáticos se imparte en la universidad Rey Juan Carlos por el personal docente e investigador (PDI) de distintos departamentos de dicha universidad. La responsable del máster es la profesora Eva Mª Castro. El plan de estudios del máster consta de 60 créditos repartidos entre una serie de asignaturas obligatorias y optativas, y un trabajo final de máster. A partir del curso académico 2011/12 el máster se imparte en el campus de Fuenlabrada. Los cursos para las distintas asignaturas se organizan por medio de clases semanales en horario de tarde. Los alumnos se examinan de las asignaturas en las que se encuentren matriculados en tres convocatorias de exámenes: diciembre, abril/mayo y junio.
Máster universitarios
El máster de sistemas telemáticos e informáticos se imparte en la universidad Rey Juan Carlos por el personal docente e investigador (PDI) de distintos departamentos de dicha universidad. El responsable del máster es el profesor Carlos Agüero. El plan de estudios del máster consta de 60 créditos repartidos entre una serie de asignaturas obligatorias y optativas, y un trabajo final de máster. A partir del curso académico 2011/12 el máster se imparte en el campus de Fuenlabrada. Los cursos para las distintas asignaturas se organizan por medio de clases semanales en horario de tarde. Los alumnos se examinan de las asignaturas en las que se encuentren matriculados en tres convocatorias de exámenes: diciembre, abril/mayo y junio.
Diagrama estático de instanciasurjc:universidad
dcc: departamento
gsyc: departamento
libre:máster sti:máster
dasi:curso
:examen 14/11/11:clase
10-11:cursoAcadémico
dic: convocatoria
:alumno
:alumno
:alumno
:asignatura
:plan
:PDI :PDI
:responsable
:profesor
:profesor
:tfm
:horario
Diagrama estático de tipos
Sistema de gestión de tickets
Las actividades a realizar en un proyecto de desarrollo software pueden clasificarse en distintas categorías: implementación de nuevos módulos software, resolución de incidencias o bugs, mejoras, etc. La decisión de realizar dichas actividades, denominadas tickets, puede ser tomada por cualquier programador miembro del proyecto, el cual pasa a considerarse su propietario. Éste puede tratar de asignar su realización a uno o varios miembros del proyecto, los cuales pueden aceptar o rechazar ser responsables de su ejecución. Para la resolución de los distintos tickets los programadores cuentan con compiladores y otras herramientas de desarrollo. Tanto en el contexto de cada uno de los tickets como en el contexto global del proyecto los programadores pueden mantener discusiones sobre distintos temas del proyecto.
Las actividades a realizar en un proyecto de desarrollo software pueden clasificarse en distintas categorías: implementación de nuevos módulos software, resolución de incidencias o bugs, mejoras, etc. La decisión de realizar dichas actividades, denominadas tickets, puede ser tomada por cualquier programador miembro del proyecto, el cual pasa a considerarse su propietario. Éste puede tratar de asignar su realización a uno o varios miembros del proyecto, los cuales pueden aceptar o rechazar ser responsables de su ejecución. Para la resolución de los distintos tickets los programadores cuentan con compiladores y otras herramientas de desarrollo. Tanto en el contexto de cada uno de los tickets como en el contexto global del proyecto los programadores pueden mantener discusiones sobre distintos temas del proyecto.
Diagrama estático de instancias
:proyecto
:ticket :discusión:mejora
:propietario
:compilador:programador
:discusión:ticket
:discusión:discusión
:discusión
:propietario:responsable:bug
:módulo
Diagrama estático de tipos
Twitter es una red de información formada por personas (tweeters) que pueden emitir mensajes (tweets) de forma pública a todos los miembros de la red, o de forma privada a determinados miembros. Las personas que tengan cuenta en la red pueden declararse seguidores (follower) de otros, de tal manera que todos los mensajes públicos que emitan éstos les serán remitidos de forma automática. Una persona puede re-enviar (re-tweet) los mensajes de cualquier miembro a los que haya tenido acceso, o responder a ellos. Los miembros de la red también pueden agrupar a otros miembros en listas personales.
miles: account
javi: account{blocked=isabel}
: tweet
:twitterer:follower
:twitterer
isabel: account:twitterer
jesus: account{private=true}
:twitterer
scala: list
:follower
: retwee
t
: reply
:follower:listed
: DM
: tweet
: retwee
t
: DM
: reply
:statistics
