Post on 12-Jan-2015
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
“¿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.