Search

© 2012 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes,creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works. Dealing with non-functional requirements (NFRs) has posed a challenge onto software engineers for many years. Over the years, many methods and techniques have been proposed to improve their elicitation, documentation, and validation. Knowing more about the state of the practice on these topics may benefit both practitioners' and researchers' daily work. A few empirical studies have been conducted in the past, but none under the perspective of software architects, in spite of the great influence that NFRs have on daily architects' practices. This paper presents some of the findings of an empirical study based on 13 interviews with software architects. It addresses questions such as: who decides the NFRs, what types of NFRs matter to architects, how are NFRs documented, and how are NFRs validated. The results are contextualized with existing previous work.

Quality attributes and constraints are among the principal drivers in architectural decision making processes. Quality attributes are improved or damaged by architectural decisions, while constraints directly include or exclude parts of the architecture (e.g., logical components or technologies). We may determine the impact of an architectural decision in the software quality, or which parts of the architecture are a ected by a constraint, but the hard problem is to know if we are respecting the quality requirements (requirements over the quality attributes) and the imposed constraints with all the architectural decisions made. Currently, the most usual approach is that architects use their own experience to produce software architectures that comply with the expected quality requirements and imposed constraints, but at the end, especially for crucial decisions, the architect has to deal with complex tradeo s between quality attributes and juggle with possible incompatibilities raised by the imposed constraints. To facilitate this task and make architect's decision making processes more reliable and e ective, in this paper we present the Quark method to guide the architects in the software architecture design. Quark relies on a specialized ontology, Arteon, which is in charge of managing the architectural knowledge. The decisional part of Arteon is also presented in this paper.

Tight time-to-market needs pushes IT consulting firms (ITCFs) to continuously look for techniques to improve their IT services in general, and the design of software architectures in particular. The use of reference architectures allows ITCFs reusing architectural knowledge and components in a systematic way. In return, ITCFs face the need to assess these reference architectures in order to ensure their quality, return on investment and incremental improvement. Little support exists to help ITCFs to face this challenge. In this work-in-progress paper we present an empirical framework aimed to assess ITCFs’ reference architectures and their use in IT projects by harvesting relevant evidence from the wide spectrum of involved stakeholders. We are currently applying this framework in an ITCF and we report the issues found so far.

Quality attributes and constraints are among the principal drivers in architectural decision making processes. Quality attributes are improved or damaged by architectural decisions, while constraints directly include or exclude parts of the architecture (e.g., logical components or technologies). We may determine the impact of an architectural decision in the software quality, or which parts of the architecture are a ected by a constraint, but the hard problem is to know if we are respecting the quality requirements (requirements over the quality attributes) and the imposed constraints with all the architectural decisions made. Currently, the most usual approach is that architects use their own experience to produce software architectures that comply with the expected quality requirements and imposed constraints, but at the end, especially for crucial decisions, the architect has to deal with complex tradeo s between quality attributes and juggle with possible incompatibilities raised by the imposed constraints. To facilitate this task and make architect's decision making processes more reliable and e ective, in this paper we present the Quark method to guide the architects in the software architecture design. Quark relies on a specialized ontology, Arteon, which is in charge of managing the architectural knowledge. The decisional part of Arteon is also presented in this paper.

© 2012 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes,creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works. Researchers from requirements engineering and software architecture had emphasized the importance of NonFunctional Requirements and their influence in the architectural design process. To improve this process we have designed a tool, ArchiTech, which aims to support architects during the design process by suggesting alternative architectural decisions that can improve some types of non-functional requirements in a particular project, and facilitate the reuse of architectural knowledge shared between projects of the same architectural domain (e.g., web-based applications).

Presentació en power-point.

Sequence alignment is a fundamental instrument in Bioinformatics. In recent years, numerous proposals have been addressing the problem of accelerating this class of applications. This, due to the rapid growth of sequence databases in combination with the high computational demands imposed by the algorithms. In this paper we focus on the analysis of the progressive alignment in ClustalW, a widely used program for performing multiple sequence alignment. We have parallelized ClustalW for the Cell processor architecture and have carefully analyzed the scalability of its different phases with both the number of cores used and the input size. Experimental results show that computing profile scores scales well up to 16 SPE cores. With the increase of the input size, profiles initialization in the PPE core becomes the predominant bottleneck.

Software architecture This work introduces a flexible and reusable architecture designed to facilitate the development of remote sensing applications. Based on it, we are developing a helicopter system, called Red-Eye, devoted to the detection, control and analysis of wild land forest fires in the Mediterranean area. The design of the proposed system is composed of five main components. Each component will work collaboratively to constitute a platform of high added value. The general architecture designed for wildfire monitoring is being tailored for two relevant objectives within the particular Mediterranean scenario: tactical day/night fire front evolution, and post-fire hot-spot detection. The generalized integration of monitoring vehicles with the operation of other aerial resources (attack helicopter and airplanes) is an unsolved problem, both technically and methodologically. However, the operation of a monitoring helicopter during certain very well identified phases of the extinction process in highly plausible. High-level strategic monitoring is possible because no-conflicts will appear due to different flight levels; however, low-level tactical monitoring is a source of potentially dangerous in-flight traffic conflicts. In addition to monitoring the fire front evolution, detection of remaining post-fire hot-spots located at the perimeter of fire is the main application that has been foreseen. Just after a fire front is contained or even during the days following the fire extinction, the monitoring tasks have to be maintained because of the danger of fire reactivation. The cost of monitoring with ground teams or aerial means it is very expensive and consumes resources needed in other fronts or possibly concurrent fires. However, a helicopter equipped with thermal cameras, can flight over the area and generate a map of hot spots with higher precision at a smaller cost. It is crucial in this application that the hot spots are reported immediately to avoid having ground brigades wai- - ting for data for too long. Also, it is important to feedback the information in such a way it can be effectively consumed, not forcing ground brigades to walk around the forest without a clear operational scheme. Based on a Service Oriented Architecture (SOA) a heliborne hot-spot detection system is being developed. This paper describes the global architecture of the system, including the air segment, the ground control segment, and the interface with the squads operating on the fire area, etc. We also demonstrate how the available pre-defined modules in the SOA architecture have been reused to design this particular application, the additional subsystems required to implement specific hot-spot mission requirements, and the overall system / end-user interface.

This paper presents the system architecture of a Content- Based Image Retrieval system implemented as a web service. The proposed solution is composed of two parts, a client run- ning a graphical user interface for query formulation and a server where the search engine explores an image repository. The separation of the user interface and the search engine follows a Service as a Software (SaaS) model, a type of cloud computing design where a single core system is online and available to authorized clients. The proposed architecture follows the REST software architecture and HTTP proto- col for communications, two solutions that combined with metadata coded in RDF, make the proposed system ready for its integration in the semantic web. User queries are formulated by visual examples through a graphical inter- face and content is remotely accessed also through HTTP communication. Visual descriptors and similarity measures implemented in this work are mostly de ned in the MPEG-7 standard, while textual metadata is coded according to the Dublin Core speci cations.

La consideración de los requisitos no-funcionales (RNF) en el proceso de desarrollo de software dirigido por modelos (DSDM) impacta en la educción del estilo arquitectónico del sistema software resultante, así como en la selección de las tecnologías más apropiadas para su implementación. A partir de un análisis de dicho impacto, en este trabajo se enumeran, definen y relacionan los conceptos fundamentales que emergen en el tratamiento de los RNF en el proceso de DSDM, y se ilustra su rol en el proceso mediante un escenarios de uso. The consideration of non-functional requirements (NFR) in the Model-Driven Software development (MDSD) impacts in the elicitation of the architectural styles of the resulting software system as well as in the selection of the implementation technologies. Analyzing this impact, is this work, there are enumerated, defined and related the fundamental concepts that emerges from the treatment of NFR in the MDSD process. These concepts are illustrated using a scenario of use.

La consideración de los requisitos no-funcionales (RNF) en el proceso de desarrollo de software dirigido por modelos (DSDM) impacta en la educción del estilo arquitectónico del sistema software resultante, así como en la selección de las tecnologías más apropiadas para su implementación. A partir de un análisis de dicho impacto, en este trabajo se enumeran, definen y relacionan los conceptos fundamentales que emergen en el tratamiento de los RNF en el proceso de DSDM, y se ilustra su rol en el proceso mediante un escenarios de uso. The consideration of non-functional requirements (NFR) in the Model-Driven Software development (MDSD) impacts in the elicitation of the architectural styles of the resulting software system as well as in the selection of the implementation technologies. Analyzing this impact, is this work, there are enumerated, defined and related the fundamental concepts that emerges from the treatment of NFR in the MDSD process. These concepts are illustrated using a scenario of use.

Una de las principales actividades en el desarrollo de Sistemas de Información (SI) es la asignación de tratamientos a responsabilidades durante la etapa de diseño. En este artículo, presentamos el marco Responsibility Detection and Transformation (RDT) para la semiautomatización de este proceso aplicable al contexto del desarrollo dirigido por modelos (MDD). RDT ofrece la posibilidad de partir de diversos tipos de artefactos (especificaciones OO, interfaces gráficas, etc.) para describir el sistema software. Para llevar a cabo el proceso de asignación de tratamientos a responsabilidades, RDT selecciona el tratamiento más adecuado de un repositorio de tratamientos, en base a los requisitos no funcionales establecidos sobre el SI en desarrollo. A continuación, presentamos el prototipo actual de la implementación de RDT, llamado Assignment of Responsibilities in a 3-Layer architecture (AR3L), en el que usamos una plataforma de código abierto llamada AndroMDA para implementar el proceso, especificaciones en UML como artefacto a partir del que se extraen las responsabilidades, y arquitectura en tres capas como patrón arquitectónico del SI.

Una de las principales actividades en el desarrollo de Sistemas de Información (SI) es la asignación de tratamientos a responsabilidades durante la etapa de diseño. En este artículo, presentamos el marco Responsibility Detection and Transformation (RDT) para la semiautomatización de este proceso aplicable al contexto del desarrollo dirigido por modelos (MDD). RDT ofrece la posibilidad de partir de diversos tipos de artefactos (especificaciones OO, interfaces gráficas, etc.) para describir el sistema software. Para llevar a cabo el proceso de asignación de tratamientos a responsabilidades, RDT selecciona el tratamiento más adecuado de un repositorio de tratamientos, en base a los requisitos no funcionales establecidos sobre el SI en desarrollo. A continuación, presentamos el prototipo actual de la implementación de RDT, llamado Assignment of Responsibilities in a 3-Layer architecture (AR3L), en el que usamos una plataforma de código abierto llamada AndroMDA para implementar el proceso, especificaciones en UML como artefacto a partir del que se extraen las responsabilidades, y arquitectura en tres capas como patrón arquitectónico del SI.

(...) En este reporte se realiza un esfuerzo de crear una base de datos de áreas shapefile, nativa de programas de Sistemas de información Geográfica, como base para la construcción de modelos procedurales, que partirían de la extrusión de estas áreas vectoriales cerradas. Por la complejidad de este proceso este reporte solo contempla una etapa inicial, la detección de los contornos de los elementos arquitectónicos, de un contexto complejo como Vila Vella de Tossa de Mar, a través de técnicas de mallado, decimación, la detección de aristas y límites de las mallas.

Levantamiento arquitectónico a partir de modelos de nubes de puntos. La Tecnología Láser Escáner Terrestre en el modelado paramétrico de Vila Vela de Tossa de Mar.