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 Introducción.

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 Introducción."— 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 Introducción Juan Manuel serrano

2 Objetivo Modelar mediante Speech los requisitos funcionales de aplicaciones sociales que atañen a las interacciones entre los usuarios de la aplicación

3 Aplicaciones sociales Cualquier software diseñado con el propósito de permitir que las personas se comuniquen, colaboren o coordinen de una manera más efectiva en un contexto social determinado AKA social software, social apps versus aplicaciones gráficas software de red (TCP-IP) sistemas de gestión de base de datos etc.

4 Dominios cvc

5 Prácticas de cursos anteriores Agencia de viajes (2) Asociación de sordos Bomberos Conciertos musicales Concursos de fotografía Convocatorias de subvenciones Copa mundial FIFA Diccionarios colaborativos Elecciones generales Empresas aeronáuticas Encuestas Federación española de baloncesto Federación española de físicoculturismo y fitness Federación española de natación Fórmula 1 Gestión de emergencias sanitarias Gimnasios

6 Prácticas de cursos anteriores Grupos de discusión Hospitales Hoteles Liga de fútbol profesional Ligas de fútbol sala Mercados bursátiles Metro Periódicos digitales Playoffs de la NBA Policía nacional Recursos humanos: subidas y promociones Redes de innovación tecnológica Redes sociales musicales Seguimiento de incidencias Software Process Management Supermercados Tiendas de músicas Trabajos fin de máster

7 Objetivo Modelar mediante Speech los requisitos funcionales de aplicaciones sociales que atañen a las interacciones entre los usuarios de la aplicación

8 Requisitos funcionales Definen qué debe hacer la aplicación, las funciones esperadas por parte de sus usuarios, determinadas en base a sus necesidades, intereses y objetivos vs requisitos no funcionales (software qualities, quality requirements) Imponen restricciones sobre cómo debe proporcionarse dicha funcionalidad Ej. seguridad, rendimiento, fiabilidad, robustez, escalabilidad, privacidad, usabilidad, compromisos tecnológicos (hw/sw), etc.

9 Aproximaciones a la ingeniería de requisitos Aproximación tradicional Recopilar las funciones deseadas tal y como las describen los distintos stakeholders (actores involucrados de alguna forma u otra en el desarrollo de la aplicación): clientes y usuarios, principalmente Se centra en determinar cómo operará el sistema, y en comprobar la consistencia, completitud y no ambigüedad de los requisitos Aproximación s ocial Analizar primero (early requirements) los actores a los que la aplicación va a dar soporte: sus motivaciones, intereses, preocupaciones, necesidades, así como las relaciones que mantienen entre ellos (cooperación, colaboración, competencia) Analizar cómo trabajan los usuarios antes del sistema, y qué problemas hay desde las perspectivas de los distintos actores, y cómo el sistema va a alterar las relaciones entre dichos actores

10 Interacciones sociales vs. toma de decisiones En todo proceso social se pueden distinguir dos tipos de actividades: Las relativas a las interacciones que mantienen entre sí los individuos que participan en el proceso Las relativas a los procesos de toma de decisiones realizados por los individuos Una aplicación social podría estar destinada a dar soporte a ambos tipos de actividades o sólo a uno de ellos

11 Interacciones sociales vs. toma de decisiones

12 Ejemplo: el póquer Las interacciones entre los usuarios de la futura aplicación están regidas por las reglas del juego Los procesos de toma de decisiones pueden ser soportados (y automatizados) mediante algoritmos de búsqueda heurística; los requisitos funcionales vienen dados por heurísticas del juego Las reglas del juego son independientes (ortogonales) a las estrategias seguidas por los jugadores; podrían ser programas o personas

13 Educción de requisitos (requirements elicitation) Técnicas entrevistas casos de uso, escenarios, storyboards observación directa, inmersión prototipos brainstorming Fuentes documentales Páginas web Manuales de procesos o procedimientos etc.

14 Especificación de requisitos Técnicas Informal – impreciso Lenguaje natural Informal – preciso Modelos (UML use cases, BPMN, …) Formal – riguroso Lenguajes formales de especificación En cualquier caso, las descripciones se focalizan en el dominio de aplicación, no utilizan vocabulario relativo a la tecnología software a emplear para su desarrollo

15 The Trac Ticket System As the central project management element of Trac, tickets can be used for project tasks, feature requests, bug reports, software support issues among others. An issue is assigned to a person who must resolve it or reassign the ticket to someone else. All tickets can be edited, annotated, assigned, prioritized and discussed at any time. Many of the default ticket fields can be hidden from the ticket web interface simply by removing all the possible values through trac-admin. trac-admin

16 Twitter ¿Qué es esto de Twitter? Twitter es una red de información basada en mensajes de 140 caracteres llamados Tweets. Es una forma nueva y fácil de descubrir las últimas noticias ("qué pasa?") relacionadas con los temas que te interesan. ¿Cuál es su utilidad? Twitter contiene información que encontrarás valiosa. Los mensajes de los usuarios que eliges seguir aparecerán en tu página principal. https://support.twitter.com

17 Póquer In any basic poker game, players strategically wager using a number of actions available to them. The actions are as follows: CHECK - If there is no wager on the current betting round, a player may check. The act of checking passes the action to the next person, immediately clockwise from the player. A check does not forfeit interest in the pot, only the current right to bet. If all active players check during a round of betting, the round is considered complete. … Another meta-skill that should be part of a winning players poker strategy is avoiding tilt. Your opponents will use your emotions against you, but only if you let them. Emotional play results in poor decisions and lost money.

18 Elecciones generales El derecho de sufragio activo es derecho al voto y el derecho de sufragio pasivo es el derecho a presentarse como candidato y ser votado. En las Elecciones a Cortes Generales pueden votar todos los españoles mayores de edad inscritos en el Censo Electoral (tanto residentes en España como residentes en el extranjero). No podrán votar: * Los condenados por sentencia judicial firme a pena de privación del derecho de sufragio … Los electores y electoras ciegos o con discapacidad visual inscritos en el Censo Electoral que sepan utilizar el Braille … [pueden] solicitar el kit de votación accesible a la Administración General del Estado a través del teléfono gratuito del Ministerio del Interior

19 Más ejemplos Concurso fotográfico Las fotos a concurso se podrán presentar en cuatro categorías temáticas: cultura, indignación, informática y lobbies financieros. Las fotos deberán subirse al portal web en formato jpg, y no podrán tener un tamaño superior a 1 MB. SUMMA El SUMMA112 es el servicio de urgencias médicas de la Comunidad de Madrid. … El locutor y el personal de las ambulancias y demás unidades de atención se comunican a través del Trunking (sistema de radio)

20 Objetivo Modelar mediante Speech los requisitos funcionales de aplicaciones sociales que atañen a las interacciones entre los usuarios de la aplicación

21 Modelización Representación precisa, aunque no rigurosa, de la solución a un problema de diseño vs. programación, representación rigurosa (matemática) de la solución El modelo emplea abstracciones que destacan los aspectos principales del dominio y ocultan los menos relevantes Las abstracciones computacionales pueden organizarse en torno a distintos paradigmas objetos, mensajes, actores, funciones, …

22 ¿Cuándo es un modelo mejor que otro? design for change design for reuse design for understandability design for incremental development design for responsibility assignment design for testing … y por último: design for efficiency

23 Orientado a objetos

24 Tipos de modelos Estáticos vs. dinámicos Los modelos estáticos describen la estructura del dominio Los modelos dinámicos, su evolución a lo largo del tiempo Tipos vs. instancias Los modelos de tipos describen las clases de estructuras y comportamientos característicos del dominio de aplicación Los modelos de instancias describen la estructura concreta del sistema en un instante determinado o su evolución bajo un escenario determinado

25 Tipos de modelos: UML Modelos estáticos Tipos Diagramas de clases Instancias Diagramas de objetos Modelos dinámicos Tipos Diagramas de estado Diagramas de actividad Instancias Diagramas de secuencia Diagramas de comunicación

26 Póquer – Texas Holdem Un casino proporciona a sus clientes la posibilidad de disputar partidas de póquer utilizando fichas que pueden adquirir 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 mano de póquer que él.

27 Diagrama de clases

28 Diagrama de objetos

29 Diagrama de secuencia

30

31 Diagrama de comunicación

32 Objetivo Modelar mediante Speech los requisitos funcionales de aplicaciones sociales que atañen a las interacciones entre los usuarios de la aplicación

33 El lenguaje Speech Un lenguaje para la programación de aplicaciones sociales basado en abstracciones sociales Lenguaje específico de dominio Vs. Lenguaje de propósito general Un lenguaje para la programación de procesos sociales Lenguaje orientado a interacciones Lenguajes de programación de normativas en dominios de aplicación social arbitrarios Vs. Lenguaje para la programación de componentes (toma de decisiones, interfaces de usuario, etc.)

34 Functional requirements Three major concerns service specs decision - support req. normative & collaborative concern a.k.a interaction requirements a.k.a rules of the game a.k.a language game specs …

35 Interaction requirements The proper domain of Speech Which roles do the users play? Which things do they say ? Who is able to say/see what? When ? Which things they must do? Which things they must be notified of ? Which services are needed? Who is able to invoke these services? When ? ….

36 S PEECH A BSTRACTIONS Which roles do the users play? Which things do they say ? Who is able to say/see what? When ? Which things they must do? Which things they must be notified of ? Which services are needed? Who is able to invoke these services? When ? ….

37 Which roles do the users play? Which services are needed? People manipulate information ………..…….. Which things do they say ? People see things ………… People invoke services………………………. How are the interactions organised? ………. Who is able to say/see/invoke (do) what?.... in which circumstances ? Which things they must do? Which things they must be notified of ? agent (roles) computational resources (roles) informational resources (roles) speech acts observations invocations social interactions empowerment permission commitments monitoring rules S PEECH A BSTRACTIONS

38 Estilos arquitectónicos Las abstracciones de Speech ejemplifican un estilo arquitectónico para la modelización de aplicaciones sociales basado en sociedades computacionales Un estilo arquitectónico se define esencialmente en términos de un conjunto de mecanismos de interacción (conectores) que los componentes del sistema utilizan para comunicarse (transferencia de información), transferir control, facilitar y ordenar sus interacciones, etc.

39 Estilos arquitectónicos Arquitecturas orientadas a objetos Los componentes (objetos) interactúan mediante la invocación de métodos Arquitecturas pipe & filter Los componentes (filtros) interactúan a traves de pipes (mecanismos de transferencia de información unidireccionales) Arquitecturas publish & subscribe Los componentes (productores o consumidores de información) interactúan mediante canales de eventos Arquitecturas cliente-servidor Los componentes (proveedores de servicios y clientes) interactúan por medio de la petición de servicios Arquitecturas basadas en sociedades computacionales Los componentes (agentes software) interactúan a través de mecanismos de interacción social, diseñados como contrapartidas computacionales de los mecanismos utilizados en la sociedades humanas: normas (compromisos, permisos, etc.), actos de habla, conversaciones, grupos, organizaciones, contextos sociales, etc.


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

Presentaciones similares


Anuncios Google