La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

Desarrollo de aplicaciones para la sociedad de la información PARTE III Estilo arquitectónico para el desarrollo de aplicaciones sociales Entidades sociales.

Presentaciones similares


Presentación del tema: "Desarrollo de aplicaciones para la sociedad de la información PARTE III Estilo arquitectónico para el desarrollo de aplicaciones sociales Entidades sociales."— Transcripción de la presentación:

1 Desarrollo de aplicaciones para la sociedad de la información PARTE III Estilo arquitectónico para el desarrollo de aplicaciones sociales Entidades sociales Juan Manuel Serrano

2 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

3 Índice Entidades socialesAtributosActos de hablaAcciones y eventosNormas sociales

4 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

5 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

6 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

7 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

8 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

9 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

10 Agentes y recursos :Java :Resource :Jason :2APL :Java :Python :Perl :Agent :Resource :Agent :Resource Heterogéneos NO autónomos Heterogéneos AUTÓNOMOS Interacciones sociales Actos de habla Observaciones Invocaciones Interacciones sociales Actos de habla Observaciones Invocaciones

11 Interacciones sociales y actos de habla :Java :Resource :Jason :2APL :Java :Python :Perl :Agent :Resource :Agent :SocialInteraction :Resource :SpeechAct

12 Observaciones :Resource :Component :Agent :Observation

13 Invocación de operaciones :Resource :Component :Agent :SocialInteraction :Resource :Component :Invocation

14 14 Jerarquías de roles vs. interacciones sociales... player role top-level role

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

16 Diagrama estático de instancias ICONOLEYENDA Social middleware instancia de interacción social de tipo T con identificador id (se omite normalmente) instancia de recurso instancia de agente id : T

17 Diagrama estático de instancias ICONOLEYENDA 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

18 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

19 Diagrama estático de tipos (casos de uso) ICONOLEYENDA 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

20 Diagrama estático de tipos (casos de uso) ICONOSLEYENDA 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

21 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

22 Diagrama estático de instancias :partida : casino :partida : mano : ronda :cliente :cajero :jugador :carta :jugada :carta :baraja : pasar :comprar

23 Diagrama estático de tipos

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

25 Diagrama estático de instancias urjc :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 :asignatura :plan :PDI :responsable:profesor :tfm:horario

26 Diagrama estático de tipos

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

28 Diagrama estático de instancias :proyecto :ticket :discusión :mejora :propietario :compilador :programador :discusión :ticket :discusión :propietario:responsable :bug:módulo

29 Diagrama estático de tipos

30 Twitter 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.

31 miles : account :twitter Twitter javi : account {blocked=isabel} : tweet :twitterer :follower :twitterer isabel : account :twitterer jesus : account {private=true} :twitterer scala : list :follower : retweet : reply :follower :listed : DM : tweet : retweet : DM : reply :statistics


Descargar ppt "Desarrollo de aplicaciones para la sociedad de la información PARTE III Estilo arquitectónico para el desarrollo de aplicaciones sociales Entidades sociales."

Presentaciones similares


Anuncios Google