Desarrollo de aplicaciones para la sociedad de la información

PARTE IIIEstilo arquitectónico para el desarrollo de aplicaciones sociales

Introducción

Juan Manuel serrano

Objetivo

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

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.

Dominios

cvc

EntretenimientoBPM Web 2.0

.…eGovernment

Prácticas de cursos anteriores

Agencia de viajes (2)Asociación de sordosBomberosConciertos musicalesConcursos de fotografíaConvocatorias de subvencionesCopa mundial FIFADiccionarios colaborativosElecciones generalesEmpresas aeronáuticasEncuestasFederación española de baloncestoFederación española de físicoculturismo y fitnessFederación española de nataciónFórmula 1Gestión de emergencias sanitariasGimnasios

e-commerce

e-commerce

e-health

entertainment

e-government

e-government

e-government

Web 2.0

BPM

e-government

Web 2.0

entertainment

e-government

entertainment

Web 2.0

e-government

e-government

Prácticas de cursos anteriores

Grupos de discusiónHospitalesHotelesLiga de fútbol profesionalLigas de fútbol salaMercados bursátilesMetroPeriódicos digitalesPlayoffs de la NBAPolicía nacionalRecursos humanos: subidas y promocionesRedes de innovación tecnológicaRedes sociales musicalesSeguimiento de incidenciasSoftware Process ManagementSupermercadosTiendas de músicasTrabajos fin de máster

Web 2.0

e-commerce

e-commerce

BPM

BPM

Web 2.0

e-government

BPM

e-government

entertainment

media

e-government

e-commerce

entertainment

entertainment

BPM

e-government

e-government

Objetivo

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

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.

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

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

Interacciones sociales vs. toma de decisiones

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

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.

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

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

http://trac.edgewall.org/wiki/TracTickets

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

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 player’s 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.”

http://www.pokerstars.com/poker/games/rules/

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 900 150 000” http://elecciones.mir.es/generales2011/

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

Objetivo

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

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, …

¿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

Orientado a objetos

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

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

Póquer – Texas Hold’em

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.

Diagrama de clases

Diagrama de objetos

Diagrama de secuencia

Diagrama de secuencia

Diagrama de comunicación

Objetivo

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

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

Functional requirementsThree major concerns

service specsdecision-support req.

normative & collaborative concerna.k.a interaction requirements

a.k.a rules of the gamea.k.a language game specs

…

Interaction requirementsThe 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?….

SPEECH ABSTRACTIONS

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?….

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 actsobservationsinvocationssocial interactionsempowermentpermissioncommitmentsmonitoring rules

SPEECH ABSTRACTIONS

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.

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.