Transcription
Modelo de contexto y de dominio para la ingeniería de requisitos de sistemas ubicuos151MODELO DE CONTEXTO Y DE DOMINIOPARA LA INGENIERÍA DE REQUISITOSDE SISTEMAS UBICUOSLiliana González Palacio*Germán Urrego Giraldo**Recibido: 06/08/2010Aceptado: 08/10/2010RESUMENEste artículo presenta los modelos de contexto y de dominio de un ambienteubicuo genérico, como instrumento para facilitar la transición del conocimiento de lafase de definición a la fase de análisis y servir de base para la obtención de los requisitos. El aporte es derivado de una investigación en metodologías para construcciónde ambientes ubicuos, enmarcada dentro del macroproyecto para la construcciónde una plataforma de cocreación de productos y servicios innovadores en el área detelecomunicaciones. Esta iniciativa hace parte del Centro de Excelencia ARTICA.Palabras clave: ingeniería de software, ingeniería de requisitos, metodologías,sistemas ubicuos, modelo de contexto, modelo de dominio.***Magíster en Ingeniería U. de A. Docente Ingeniería de Sistemas Universidad de Medellín. Estudiante de Doctorado en Ingeniería. MedellínColombia. Correo electrónico: ligonzalez@udem.edu.co.Ph. D. en Informática Universidad de París I. Profesor Departamento de Ingeniería de Sistemas Universidad de Antioquia. Medellín- Colombia. Correo electrónico: gaurrego@udea.edu.co.Revista Ingenierías Universidad de Medellín, vol. 9, No. 17, pp. 151-164 - ISSN 1692-3324 - julio-diciembre de 2010/228 p. Medellín, Colombia
152Liliana González Palacio - Germán Urrego GiraldoCONTEXT MODEL AND DOMAIN MODELFOR REQUIREMENTS ENGINEERING UBIQUITOUS SYSTEMSABSTRACTIn this paper, the context and domain models, as an instrument to facilitatethe knowledge transition between the definition phase and the analysis phase, andto serve as a basis to the requirements obtainment is presented. This contributionwas obtained from a research project of building methodologies ubiquitous environments, within the macro project of construction of a platform for the co-creationof products and innovation services in telecommunications area. This initiative ispart of the ARTICA excellence center.Key words: software engineering, requirements engineering, methodologies,ubiquitous systems, context model, domain model.Universidad de Medellín
Modelo de contexto y de dominio para la ingeniería de requisitos de sistemas ubicuosINTRODUCCIÓNEn cualquier lugar, en cualquier momento ya través de cualquier dispositivo es la definiciónmás sencilla para explicar el concepto de ubicuidad desde la perspectiva tecnológica, que ha demodificar la manera como el hombre experimentael mundo [1].Consecuentemente, los sistemas ubicuos (conocidos también como pervasivos) constituyenentornos donde los elementos tecnológicos soninvisibles para los usuarios pero su funcionalidadcontinúa proporcionándose, y a la vez, los dispositivos inteligentes se insertan en las tareas diarias,haciendo que la interacción usuario-sistema seanatural y desinhibida en todo tipo de situacionesy circunstancias [2].Una etapa inicial y muy importante en elproceso de desarrollo de cualquier sistema, incluyendo los denominados ubicuos, es la ingeniería derequisitos (IR), donde se llevaa cabo el proceso dedescubrir, analizar, escribir y verificar los serviciosy restricciones del nuevo sistema [3]. Su relevanciaradica en que de la definición de los requisitosdependerán las etapas subsecuentes del desarrollo.Si esta fase no se lleva a cabo con el debido rigorpuede provocar serios problemas en tiempos deentrega, aumento en presupuestos y expectativasinsatisfechas de los clientes, ya que el productofinal estará incompleto o poco funcional. De ahí elinterés y la importancia de proponer metodologíasque permitan la captura y tratamiento de requisitosde una manera sistemática y organizada.Para lograr el reconocimiento de los requisitoses fundamental caracterizar el dominio al quepertenece el tipo de sistema a construir, buscandogeneralizar el conocimiento y facilitar posterioresdesarrollos. En orden a cumplir este objetivo algunos autores [4] proponen la construcción de unmodelo de contexto de utilización y un modelo dedominio para recopilar información sobre los servicios típicos que ofrecen los sistemas enmarcadosen un determinado contexto de aplicación, y losagentes e interacciones que por defecto se presen-153tan al analizar un campo de conocimiento particular.La fase de IR en el caso de los ambientesubicuos se dificulta teniendo en cuenta algunaspropiedades particulares que poseen y situacionespresentadas durante su desarrollo [5].Como características relevantes vale la pena mencionar su orientación a la identificación, localización, detección deseñales, marcada comunicación entre dispositivos,requerimientos adicionales de memoria, adaptacióna cambios en el entorno donde están ubicados,entre otras [6], que aumentan el riesgo de construirsistemas ubicuos que proveen funcionalidades innecesarias con un consumo adicional de recursos,tan escasos en este dominio particular[7].De otro lado, algunas situaciones que complican el proceso de IR en este dominio particularse enuncian a continuación [8]: a) El proceso esrealizado por expertos en electrónica, pero alejadosdel uso de las metodologías de análisis y diseño desistemas. b) La ausencia de metodologías específicas, que son reemplazadas por aquellas de propósito general sin ninguna adaptación a este tipo desistemas. c) Las metodologías para construcciónde sistemas ubicuos no proporcionan bases y guíassólidas para la definición del sistema, fase en lacual se adquiere conocimiento fundamental para laposterior definición y representación de requisitos.d) El desarrollo de un sistema ubicuo o pervasivosupone el uso de diversas y cambiantes tecnologíaspara satisfacer los requisitos de los usuarios. Porel contrario, con los métodos actuales, durante elmodelamiento los desarrolladores quedan ligadosa aspectos tecnológicos fijos, que impiden la adopción de otras tecnologías conduciendo a una rápidaobsolescencia de las metodologías usadas y de lossistemas desarrollados con ellas.En la actualidad son pocas las investigacionesdedicadas a la Ingeniería de Requisitos para estetipo de sistemas, y los aportes en cuanto a desarrollo de metodologías y de procesos de desarrollo sonaún limitados [6-8, 11-13, 15, 16, 18, 19]. La mayoría de las iniciativas están centradas únicamente enRevista Ingenierías Universidad de Medellín, vol. 9, No. 17, pp. 151-164 - ISSN 1692-3324 - julio-diciembre de 2010/228 p. Medellín, Colombia
154la etapa de diseño, particularmente en el estudiode la interfaz persona-ordenador, de los factoreshumanos y en la elaboración de recomendacionesgenerales.Como una contribución al mejoramientode las tecnologías para el desarrollo de sistemasubicuos y de las limitaciones en su definición yanálisis, este artículo presenta los modelos de contexto y de dominio que proveen una base para lafase de definición de un sistema ubicuo genérico.Estos resultados provienen de un proyecto de investigación sobre la definición y conceptualizaronde sistemas ubicuos desarrollado en el marco deun macroproyecto denominado “Plataforma parala cocreación de productos y servicios innovadosen el área de telecomunicaciones”, perteneciente alCentro de Excelencia ARTICA.Este trabajo continúa con la generación deun modelo de requisitos y un modelo conceptualgenéricos para ambientes ubicuos, y su posteriorimplantación en la plataforma de cocreación, comomecanismo para garantizar el acceso sin limitantesde tiempo y acceso por parte de los participantes enel proceso de innovación. El resto del artículo estáconstituido por las siguientes secciones: Posteriora la introducción, en la sección 2 de materiales ymétodos se mencionan los conceptos relevantespara entender la problemática tratada, y algunasaproximaciones a la solución planteadas por otrosautores. Luego se presenta, en la sección 3 la propuesta objeto del artículo. La discusión de resultados ocupa la sección 4. En la quinta sección seenuncian las conclusiones. Por último se presentala bibliografía.1. MATERIALES Y MÉTODOSA continuación se presentan algunos conceptos básicos que permiten entender la problemáticaplanteada. Inicialmente se introduce la terminología relevante, y luego una breve revisión de laliteratura.Universidad de MedellínLiliana González Palacio - Germán Urrego Giraldo1.1 Revisión de términosEste artículo se fundamenta en dos pilares:los ambientes ubicuos y la ingeniería de requisitos.Cada una de las áreas mencionadas tiene una seriede conceptos particulares que vale la pena resaltar.La computación ubicua da nombre a un paradigma de computación novedoso en el que la tecnología aparece integrada en elementos cotidianosde la vida real y en el que la interacción usuariosistema se lleva a cabo de forma transparente.Estas características suponen un cambio tanto enla concepción de los sistemas a desarrollar comoen la forma de interactuar con éstos [8]. Se hablade ubicuidad por la posibilidad de acceso a losrecursos sin limitantes de tiempo, medio de accesoni lugar, y se acuña el término transparencia parareferirse a tecnologías que entran en la trama de lavida cotidiana hasta no distinguirse. Para soportarestas propiedades, el sistema pervasivo debe contarcon orientación a la identificación, mecanismosde localización de usuarios, detección de señalesprovenientes del ambiente, marcada comunicaciónentre dispositivos y variedad en estos (forma, tipode acceso, tipo de conexión a redes), requerimientos adicionales de hardware, adaptación a cambiosen el entorno donde están ubicados los usuarios,infraestructura provista de sensores, entre otras [9].La construcción de este tipo de sistemas involucra complejidades adicionales, debido a suscaracterísticas particulares [6], y desde la fase deingeniería de requisitos (que incluye actividadesde definición y análisis del sistema) deben existirmétodos y técnicas para incorporar los elementosya mencionados, garantizando de este modo quefuncionalidades y servicios propios de este dominiosean modelados correctamente y tenidos en cuentaen etapas tempranas del desarrollo.En la actividad de definición el sistema, previaa la captura de requisitos, se establecen los problemas a resolver, las fuentes de conocimiento quepueden ayudar en la búsqueda de las soluciones,los intereses y necesidades que aquellos interesados
155Modelo de contexto y de dominio para la ingeniería de requisitos de sistemas ubicuos(denominados en adelante agentes) desean resolvera partir de la implantación de la nueva aplicacióno sistema, y los servicios/funcionalidades típicaspara un dominio particular [10].Como apoyo para esta actividad existen los modelos de contexto de utilización y el de dominio [4].El primero representa las acciones e interaccionesde los agentes implicados en el funcionamiento delsistema, en tanto que el segundo, también denominado modelo de objetos y servicios del dominio,se constituye en un medio para sintetizar y hacerútil el conocimiento de un dominio con miras ala especificación de las funcionalidades y de losatributos de calidad de un sistema.El modelo de contexto de utilización se elaborahaciendo un inventario de agentes involucradosen el sistema, para luego identificar interaccionesentre ellos, y necesidades que deben suplir con laimplementación de la nueva solución.Los modelos mencionados aportan información importante para la posterior construcción delmodelo de requisitos y conceptual del sistema [4].Con este recorrido por el fundamento conceptual del artículo es posible ahora abordar la revisiónde la literatura.1.2 Revisión de la literaturaLa búsqueda de propuestas en el tema estuvoorientada a metodologías de ingeniería de requisitospara el desarrollo de ambientes ubicuos o pervasivos, pero dados los hallazgos, se tuvo que extender aaproximaciones de dominio general que incluyeranformalismos y modelos de soporte a la fase de definición de sistemas. La clasificación de propuestasencontradas se resume en la figura 1. Cabe aclararque para el alcance de este artículo solo se harámención de algunas conclusiones importantes sinentrar en el detalle de cada propuesta encontrada.Metodologías de ingenieríade requisitosSe clasifican enMetodologías aplicadas aldominio de los SistemasOblícuosMetodologías aplicadasa otros dominiosDivididas en:Divididas en:Metodologías enfocadasen el análisis del sistemaMetodologías orientadaspor metasMetodologías enfocadasen el diseño del sistemaMetodologías orientadaspor escenariosFigura 1. Clasificación de propuestas abordadas en la revisión de la literatura.Fuente: elaboración propia.Revista Ingenierías Universidad de Medellín, vol. 9, No. 17, pp. 151-164 - ISSN 1692-3324 - julio-diciembre de 2010/228 p. Medellín, Colombia
156En la rama de metodologías aplicadas al dominio de ambientes ubicuos vale la pena mencionarlas siguientes: la aproximación de Tandler [7]: ofreceuna arquitectura de software específica para ambientes de computación ubicua, y la valida mediante uncaso de estudio denominado BEACH (AmbienteBásico para Colaboración Activa con Hipermedia).En esta arquitectura se ofrecen nuevas formas deinteracción humano-computador, diferentes al usode dispositivos como el mouse o el teclado. Antesde plantear la arquitectura, el autor propone 5categorías de requisitos con sus respectivas subcategorías. También se incorpora una propuesta demodelo conceptual.La propuesta de Giner y Torres [8]: Los autores proponen una clasificación de requisitos y suposterior representación basada en modelos parasistemas ubicuos, además mencionan aspectosclave para caracterizar este tipo de ambientes, talescomo identificación de los elementos que participan en el sistema, heterogeneidad de interacción,Interoperabilidad entre sistemas. Posteriormentelos autores proponen un conjunto de modelos quefacilitan la representación de un ambiente ubicuo,y se complementan entre sí aportando informaciónrelevante de sistema.El método propuesto por Muñoz y otros [11]incluye un formalismo para especificación de requisitos funcionales de sistemas pervasivos o ubicuos,que posteriormente son mapeados a modelos PervML, los cuales permiten: a) generación rápida deprototipos para validar los requisitos; b) definiciónde transformaciones que proveen mecanismos detrazabilidad para llevar los requisitos a la implementación, y viceversa.Se adapta la técnica CTT(ConcurTaskTree) para representar y describir información relevante de los sistemas pervasivos (comoubicación física, adquisición de datos del ambiente,entre otras), y con dicha información los autores definen la transformación desde el modelo de requisitosbasado en tareas hasta PervML, que es un lenguajede dominio específico para la especificación de sistemas pervasivos independiente de la tecnología.Universidad de MedellínLiliana González Palacio - Germán Urrego GiraldoLa aproximación de Cetina [12] sigue el enfoque de desarrollo de software dirigido por modelosmediante el cual es posible la generación automática de código a partir de modelos para sistemas pervasivos.El autor se concentra en definir el lenguajede modelado al que da soporte la herramienta paraespecificar estos sistemas (PervML) y un frameworkde implementación que permite la ejecución delcódigo generado.Kranz y otros [13] proponen una clasificaciónpara sistemas de presencia ubicua de acuerdo con5 criterios de clasificación relacionados con laforma de adquirir información del ambiente, lasfuncionalidades de entrada y salida, el medio de comunicación soportado, la extensión de la presencia,el modo de comunicación. Posterior a este aporte,proponen un conjunto de guías para el diseño desistemas de presencia ubicua.Según el estudio realizado, la mayoría demetodologías halladas poseen una fuerte orientación a la fase de diseño y un énfasis más débilhacia la fase de análisis que se ocupa de hacer unaconceptualización del dominio de aplicación, y elposterior estudio de los requisitos que debe cumplir el ambiente ubicuo. Otro aspecto a resaltarde las metodologías encontradas es el hecho deque ofrecen pautas para tratar los requisitos luegode que han sido elicitados, pero no proporcionanherramientas para su captura, y esto también sedebe a su fuerte orientación a la fase de diseño.Aunque existen 3 metodologías que proponenmodelos de requisitos y algunas de ellas avanzanhasta la generación del modelo conceptual, seencuentra una desconexión entre los requisitosque se capturan y la forma en que se reflejan en elmodelo conceptual. Otra debilidad detectada en losaportes recopilados es la ausencia de formalismospara la definición del sistema, previa a la capturade requisitos. No se halló evidencia de modelos quefaciliten a los analistas y diseñadores de ambientesubicuos incorporar un vocabulario común paraeste dominio en el cual se identifiquen los agentesparticipantes, sus interacciones típicas, lo mismo
Modelo de contexto y de dominio para la ingeniería de requisitos de sistemas ubicuosque servicios y funcionalidades propias de este tipode sistemas.Las carencias detectadas marcaron la necesidadde explorar metodologías de IR aplicadas en otrosdominios, buscando una que pueda ser transformada y adaptada al dominio de los sistemas ubicuos.Las aproximaciones encontradas son clasificadasde diversas formas, pero, un número apreciable deellas están orientadas por escenarios o por metas,tal como se mostró en la figura 1 [14].Las metodologías orientadas por escenariosproporcionan una descripción parcial del comportamiento de un sistema en una situación particular,y permiten representar con ejemplos concretos loque el nuevo sistema hará. En las etapas tempranasde la ingeniería de requisitos, los escenarios sonusados para soportar la definición de requisitosa alto nivel [15, 16], facilitando colaboración yentendimiento entre el equipo de desarrollo, clientes, usuarios y demás interesados. Los escenarios,además, facilitan la recopilación y representaciónde información en una forma entendible para losinteresados.Haumer [17] propone una metodología deeste tipo al capturar los requisitos construyendoejemplos del mundo real, y para ello hace uso devídeos, entrevistas, esquemas, logrando un procesode abstracción que conduce a la definición de modelos conceptuales más transparentes y trazables.La metodología ScenIC [18] plantea un esquema de conocimiento relacionado con escenarioscompuesto por metas, objetivos, tareas, obstáculosy acciones llevadas a cabo por actores. El métodoexpresa los escenarios considerando si las metaspueden ser alcanzadas con las tareas definidas en elsistema, si los actores pueden realizar dichas tareasy cómo los obstáculos pueden impedir su normalejecución por parte de los actores. En resumen, estapropuesta hace un análisis de medios y fines paragarantizar que se cumplirán los requisitos.En SCRAM (método de análisis de requisitosbasado en escenarios) [19], los escenarios son combinados con prototipos tempranos para capturar157requisitos y elaborar un diseño preliminar, asegurando una comunicación activa entre usuarios ydiseñadores lo que permite una mejor validaciónde los requisitos. El método tiene cuatro fases:captura de requisitos iniciales y familiarización conel dominio; visión inicial del diseño a partir de losrequisitos; exploración de requisitos; validaciónde requisitos y prototipado. En el método no sepropone ningún modelo de requisitos.De otro lado, las metodologías basadas en metas proveen mecanismos para establecer la relaciónentre la funcionalidad esperada de un sistema ylos procesos de negocio a los que éste dará soporte, ayudando a los agentes organizacionales en larealización de sus tareas.Existen diversas propuestas metodológicas deeste tipo. Entre ellas destaca poderosamente la notación i* propuesta por Eric Yu en la primera mitadde la década de los 90 [14], que permite expresarde forma clara y sencilla las metas de los actoresque aparecen en los modelos y las dependenciasentre ellos. El uso de i* incorpora un riesgo quese descubre pronto, pues no existe una definiciónúnica del lenguaje, lo cual genera cierta libertad yambigüedad.GBRAM (Método de Análisis de RequisitosBasado en Metas) [20] propone una serie de actividades a seguir para la obtención de un documentode requisitos a partir de metas de la organización.Presenta un proceso en el que se identifican metasorganizacionales a partir de diversas fuentes (entrevistas, diagramas de flujo de trabajo, entre otros).Las metas se clasifican en metas de mantenimientoy metas de logro, y posteriormente se materializanen acciones del sistema.La metodología KAOS [21, 22] permite construir modelos de requisitos a partir de las metasorganizacionales. Esta aproximación está soportadapor un marco formal basado en lógica temporal yen técnicas de refinamiento de Inteligencia Artificial, que define cada término (metas, acciones,estados) de forma consistente y rigurosa. La principal contribución de KAOS es la demostración deRevista Ingenierías Universidad de Medellín, vol. 9, No. 17, pp. 151-164 - ISSN 1692-3324 - julio-diciembre de 2010/228 p. Medellín, Colombia
158que los requisitos se corresponden con las metasdefinidas para el sistema.La propuesta de Ericsson [23] orientada pormetas, postula que el modelado de negocio es unaactividad de aprendizaje que ayuda al desarrollo delsistema. Esto implica que la primera actividad seríael modelado de la porción del negocio soportadapor el sistema, lo cual ocasiona que cada nuevodesarrollo conlleve un nuevo modelado de partede la organización.La metodología ABC-Besoins [4] también estáorientada por metas, y además tiene involucradoel concepto de agente. Si los requisitos se capturan pensando en los agentes que intervienen seobtendrá un mayor entendimiento del problema aresolver, porque aún sin que el sistema exista, losagentes deben interactuar para realizar determinadas actividades, y al pensar en la automatización deesas actividades se encontrará lo que el sistema debehacer. Por su modelo para representar y utilizar elconocimiento del dominio, ABC-Besoins facilitala fase de captura de los requisitos. Se ofrecenpara tal efecto dos formalismos de representacióndenominados modelo de contexto de utilizacióny estructura de objetivos y servicios del dominio.Como último ejemplo de metodología orientada por metas, se encuentra B-SCP [24], un marcode ingeniería de requisitos basado en la conexión eintegración de los conceptos de estrategia, contextoy proceso para apoyar la captura de requisitos organizacionales y su validación contra una estrategia denegocio. Este enfoque tiene implícito el conceptode meta.1.3 Conclusiones de la revisión de literaturaLas metodologías orientadas al dominio de ambientes ubicuos presentan vacíos que son cubiertospor aproximaciones aplicadas actualmente en otrosdominios y, particularmente, las orientadas pormetas, que ofrecen propuestas claras para modelarel conocimiento de un dominio de aplicación determinado aportando instrumentos de tratamientode información en la fase de definición del sistema.Universidad de MedellínLiliana González Palacio - Germán Urrego Giraldo2. SOLUCIÓN PROPUESTATeniendo en cuenta la revisión efectuada, yorientada no solo a metodologías de IR aplicadasen el dominio de los sistemas ubicuos, sino, a metodologías usadas en otros dominios, se proponeintervenir la metodología ABC-Besoins [4], orientada por metas y agentes, que proporciona formalismos para representar el conocimiento básico deun dominio, información base para posteriormenteproceder a la educción de requisitos y su posterioranálisis, proporcionando continuidad en el procesode IR, desde la elicitación de requisitos hasta lageneración de un modelo conceptual y posteriorgeneración de un modelo de diseño.Los modelos de contexto y de domino propuestos en [4] no fueron concebidos para el ámbito deambientes ubicuos, por lo tanto, se deben adaptarpara que reflejen un conocimiento profundode este dominio de aplicación, incorporando elestudio de agentes y sus interacciones en orden alograr sus metas.A continuación se presentan los resultados dela adaptación.2.1 Modelo de contexto de utilización paraambientes ubicuosSe construye pensando en los agentes queinteractúan y necesitan hacer operaciones sin contartodavía con la existencia de un sistema ubicuo,pero con un objetivo claro de poder comunicarseen cualquier tiempo, lugar o circunstancia contodo tipo de medios y de posibilidades de acceso.Los agentes requieren comunicarse sin preocuparsepor asuntos como la distancia, el medio de acceso,la hora, y hacer manipulación de dispositivosacortando el concepto de distancia, por ejemplo,si se piensa en una mujer que es ama de casay también trabaja, ella desearía poder apagaro encender la estufa ubicada en la casa de unaforma remota desde su oficina. Si se piensa enla manipulación de dispositivos sin hacer uso deservicios ubicuos, los agentes tienen limitaciones
159Modelo de contexto y de dominio para la ingeniería de requisitos de sistemas ubicuospara controlarlos a distancia, pero en caso extremolo pueden hacer de forma local. Los agentes emisor/receptor y receptor/emisor, además, requierenhacer intercambio de mensajes para conocer susnecesidades. En la figura 2 se muestra el modeloadaptado.La lectura del diagrama se hará bajo dos escenarios: suponiendo la ausencia de un sistemaubicuo, es decir, indicando la forma en que losagentes emisor/receptor y receptor/emisor logransu objetivo de comunicarse por métodos tradicionales como contactar servicios de telefonía,mensajería instantánea, entre otros, y un segundoescenario en el cual se tiene incorporado el uso deun sistema ubicuo que facilite la comunicación deSolicitud serviciosubicuos (ej.: manipulaciónremota dispositivos, envío/recepción mensajes)PrestaciónAporte serviciosubicuosparámetrosconfiguraciónSolicitud informaciónpara configuraciónservicioAgente citud informaciónpara configuraciónservicioSolicitudSolicitud servicios de parámetrosinformación (ej.: alojamientode datos, reconstrucciónescenarios)Solicitud serviciosde informaciónSolicitud servicio(ej.: mensajeríade conexióninstantánea)telefónica fija o móvilEnvío de mensajesinformativosSolicitud activaciónmecanismo localizaciónPrestación servicioconexión telefónicafija o móvilProveedores serviciosde comunicaciónSolicitud serviciode conexiónde medios ción que soportaservicios de ubicuidadDevoluciónubicación exactadispositivosSolicitud serviciode localizaciónPrestación servicioconexión a mediosde comunicaciónlos agentes interesados. En este último escenarioentran nuevos agentes como las organizaciones queprestan servicios de ubicuidad.Para describir el primer escenario se cuentacon las siguientes interacciones:El agente emisor/receptor o receptor/emisorrequiere hacer la configuración de los dispositivosque interviene o solicitar un cambio de estado enel dispositivo (por ejemplo, de ocupado a disponible, o de apagado a encendido). Estas operacionesdeben hacerse de manera local si no se cuenta conservicios ubicuos. Los dispositivos manipulados, de acuerdocon la solicitud que reciben de otros agentes,envían mensajes de información que permitenEnvío defacturaAgente Emisor/ReceptorPrestación serviciosde informaciónPrestación deserviciosdemandadosProveedores serviciosde te deparámetrosSolicitud cambiode estadoEnvío defacturaConfiguraciónde propiedadesAdquisición tecnología adecuadaIncorporación de driverspara servicios ubicuosEspecificacióncaracterísticasservicios ubicuosEntrega dispositivosPrestación servicios post-ventaActualización dispositivospara incorporar nuevosservicios ubicuosIntercambio demensajesDispositivosa ción ciónAporte deparámetrosEstablecimiento decomunicaciónEnvío mensajesde confirmaciónAgente Receptor/EmisorOrganización que soportaservicios de ubicuidadSolicitud serviciosubicuos (ej.: manipulaciónremota dispositivos, envío/recepción mensajes)Solicitud post-servicios(Ej.: la grabación de llamadaspara reconstruir escenarios)Pago deservicioPago deservicioAgente Emisor/ReceptorAgente Receptor/EmisorEnvío mensajesde confirmaciónSolicitud cambiode estadoConfiguraciónde propiedadesIncorporación servicios de ubicuidad(ej.: medición factores de entorno)Fabricante/proveedorde dispositivosRetroalimentación de necesidadesdel medio en cuanto a serviciosubicuosOptimización serviciosubicuos existentesInvestigadores/creadoresde tecnologíaIncorporación servicios ubicuossegún necesidades del medioFigura 2. Modelo de contexto de utilización para ambientes ubicuos.Fuente: elaboración propia.Revista Ingenierías Universidad de Medellín, vol. 9, No. 17, pp. 151-164 - ISSN 1692-3324 - julio-diciembre de 2010/228 p. Medellín, Colombia
160verificar si la operación solicitada se llevó acabo o cuáles fueron los inconvenientes queimpidieron el cumplimiento de la petición porparte de otro agente. Los agentes emisor/receptor y receptor/emisorbuscando medios de comunicación contactana proveedores de servicios de comunicaciónpara solicitar servicios de conexión de todotipo (por ejemplo, telefónica móvil o fija). En respuesta a la solicitud hecha por los agentesemisor/receptor y receptor/emisor, los proveedores de servicios de comunicación prestan elservicio solicitado, y posterior a esto envíandetalles de cobro, que serán respondidos conel pago. En la misma búsqueda de formas de comunicación entre agentes emisor/receptor y receptor/emisor, se hace la solicitud de servicios talescomo mensajería instantánea y correo electrónico, que son aportados por los proveedoresde servicios de información, preguntandoalgunos parámetros de configuración como elnombre del correo electrónico, la contraseña,posteriormente aportados por los agentes comocondición para acceder al servicio.Bajo el segundo escenario se tienen las siguie
Modelo de contexto y de dominio para la ingeniería de requisitos de sistemas ubicuos 151 Revista Ingenierías Universidad de Medellín, vol. 9, No. 17, pp. 151-164 - ISSN 1692-3324 - julio-diciembre de 2010/228 p. Medellín, Colombia MODELO DE CONTEXTO Y DE DOMINIO PARA LA INGENIERÍA DE REQUISITOS DE SISTEMAS UBICUOS Liliana González Palacio*
