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

Slides:



Advertisements
Presentaciones similares
U.M.L A/Gx. Diego Gutiérrez Application Analysis and Design.
Advertisements

Fundamentos de Diseño de Software INFT.1
TECNICATURA UNIVERSITARIA EN INFORMATICA
Diagrama de Clases Por: Ing. Juan Carlos Contreras Villegas
Tomado de:
UML 1.4 Peter Emerson Pinchao Solis.
Tutoriales UAM Biblioteca y Archivo.
Arquitectura CLARO-TECNOTREE
Programación Orientada a Objetos
Introducción a la Orientación a Objetos
POO Santiago, Mayo 2004 TRABAJO DE INVESTIGACIÓN POO Programación Orientada a Objetos CENAFOM Carolina Bravo V. Jaime Jofré B.
APRENDIZAJE COLABORATIVO EN BASIC SUPPORT FOR COOPERATIVE WORK
GENERACIONES DE LENGUAJES DE PROGRAMACIÓN
Aplicación del paradigma orientado a objetos
INTRODUCCIÓN A UML Oscar Miguel Alonso Moreno.
LENGUAJE UNIFICADO DE MODELADO UML
DIAGRAMAS DE CLASES Completando los diagramas de interacción, es posible identificar la especificación de las clases que participarán en la solución indicando.
Ingeniería del Software
UNIDAD 1: “ Introducción al Lenguaje Unificado de Modelado ”
PROGRAMACION ORIENTADA
UNIDAD II Modelo de Datos.
DIAGRAMA DE COMPONENTES INTEGRANTES Córdova Vásquez Giovanny Escobar Alvares Calixto Gomez Quinteros Adelaida Pinto Flores Yarmila.
Introducción y conceptos generales
Características del servicio de listas de distribución 1Jesús Torres Cejudo.
UNIVERSIDAD TECNOLÓGICA DE HERMOSILLO T.S.U. EN T.I.C., Área: Sistemas Informáticos Ing. José Padilla Duarte y estudiantes de Sistemas Informáticos Hermosillo,
Desarrollo de aplicaciones para la sociedad de la información Bloque II- Dominios de aplicaciones sociales Tema 3- Gestión de procesos de negocio Máster.
Análisis y Diseño orientado a objetos con UML.
PROGRAMACIÓN ORIENTADA A OBJETOS
Clases y objetos La unidad fundamental de programación OO son las clases. Conjunto de métodos y semántica Qué se va a hacer POO Clase: que define la implementación.
Modelado Arquitectónico
Viviana Poblete López Módulo: Modelo de Datos
Aplicación Web para Informes de Asignaturas de Trabajo en Grupo
UNIDAD 3: “Desarrollo Orientado a Objetos con UML”
DISEÑO DE SOFTWARE 1ª. Parte
Fundamentos de programación
Bases de Datos Modelamiento.
Unidad VI Documentación
APRENDIZ: SANDRA L. CAICEDO C. ORDEN: 20194
UML 2.0 Integrantes: Diana Carolina Valencia M. Jhon Fernando Lopez T. Carlos Alberto Castillo.
Ingeniería de software
Diagrama de Clases ACI 570.
Diseño De Sistemas Catedrático: Ing. Ezequiel Santillán A. Miércoles, Febrero09, 2011 T í t u l o: ANALISIS DE SISTEMAS (REQUERIMIENTOS)
Introducción a UML DIAGRAMA DE CLASES Departamento de Informática
El modelo de análisis tiene como objetivo generar una arquitectura de objetos que sirva como base para el diseño posterior del sistema. Dependiendo del.
TEMA 9: DIAGRAMA DE CLASE EN UML
Programación Orientada a Objeto
PROGRAMACION ORIENTADA A OBJETOS
Métrica v2.1 Técnicas: Modelado de datos (Parte 1)
Ingeniería de Software
ASIGNACIÓN DE ROLES.
Clasificación de Diagramas
Introducción a UML Departamento de Informática Universidad de Rancagua
Introducción a la Programación Orientada a Objetos (POO)
Introducción a UML Ing. José Manuel Poveda.
DIAGRAMA DE CLASES.
UML Casos de Uso (repaso) y Diagramas de Clase
Análisis y Diseño de Aplicaciones
Introducción al análisis de sistemas Universidad Católica.
UNIDAD 2: “Características del Modelado UML” CONTENDIDO Elaborado por: Ingeniero Harold Cabrera Meza Actualizado por: Ingeniero Nilson Albeiro Ferreira.
FUNDAMENTOS DE PROGRAMACION
Instituto Tecnológico de puebla Materia Desarrollo de aplicaciones para ambientes distribuidos Catedrático Dr. José Bernardo Parra Alumnos Cesar Mauricio.
Tipo de relación entre clases Es uno de los aspectos que distinguen el paradigma de orientación a objetos frente a otros paradigmas. Mecanismo que,
La Programación Orientado a Objetos
Introducción AOO. Contenido - Introducción - Repaso de Orientación a Objetos - UML - Casos de Uso.
Diagrama de Clases.
Fundamentos de Ingeniería de Software
Diccionario/Directorio de Datos
Modelado UML Diagrama de Clases
Entregables del Proyecto
Profesor: Jesús Chaparro Bachilleres: Perez, emibeliz Prada, Rainer Villahermosa, José Abril 2014.
Transcripción de la presentación:

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

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 socialesAtributosActos de hablaAcciones y eventosNormas 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 :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

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

Observaciones :Resource :Component :Agent :Observation

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

14 Jerarquías de roles vs. interacciones sociales... player role top-level 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 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

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

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

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

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 :cajero :jugador :carta :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 instancias urjc :universidad dcc : departamento gsyc : departamento libre :máster sti :máster dasi :curso :examen 14/11/11 :clase :cursoAcadémico dic : convocatoria :alumno :asignatura :plan :PDI :responsable: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.

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

Diagrama estático de tipos

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.

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