DECIMAL: A requirements engineering tool for product families

Today, many software organizations are utilizing product families as a way of improving productivity, improving quality and reducing development time. When a new member is added to a product family, there must be a way to verify whether the new member\u27s specific requirements are met within the reuse constraints of its product family. The contribution of this paper is to demonstrate such a verification process by describing a requirements engineering tool called DECIMAL. DECIMAL is an interactive, automated, GUI driven verification tool that automatically checks for completeness (checking to see if all commonalities are satisfied) and consistency (checking to see if dependencies between variabilities are satisfied) of the new member\u27s requirements with the product family\u27s requirements. DECIMAL also checks that variabilities are within the range and data type specified for the product family. The approach is to perform the verification using a database as the underlying analysis engine. A pilot study of a virtual reality device driver product family is also described which investigates the feasibility of this approach by evaluating the tool

Spl needs an automatic holistic model for software reasoning with feature models

The number of features and their relations in a Software Product Line (SPL) may lead to have SPLs with a big number of potential products which may be difficult to manage. This number of potential products widely increases if, as well as functional features, extra–functional features are taken into account. There are several questions that a SPL engineer would like to ask to his SPL model such as: is it a valid model?, how many potential products a SPL has?, is there any product fulfilling the customer needs? and so forth. These types of questions are error prone to answer without an automatic support. The work reported in this position paper glipmses some misconceptions of previous related proposals: we uphold the need to have an holistic product line model were not distinction are made between functional and extra–functional features, we propose a model based on a formalism strong enough to support both type o features: contraint programming.Ministerio de Ciencia y Tecnología TIC2003-02737-C02-0

Empirical Study on the Effect of a Software Architecture Representation's Abstraction Level on the Architecture-Level Software Understanding

Abstract-Architectural component models represent high level designs and are frequently used as a central view of architectural descriptions of software systems. Using the architectural component model it is possible to perceive the interactions between the system's major parts and to understand the overall system's structure. In this paper we present a study that examines the effect of the level of abstraction of the software architecture representation on the architecture-level understandability of a software system. Three architectural representations of the same software system that differ in the level of abstraction (and hence in the number of components used in the architecture) are studied. Our results show that an architecture at the abstraction level that is sufficient to adequately maps the system's relevant functionalities to the corresponding architectural components (i.e., each component in the architecture corresponds to one system's relevant functionality) significantly improves the architecturelevel understanding of the software system, as compared to two other architectures that have a low and a high number of elements and hence tangles or scatters the system's relevant functionalities into several architectural components

Linha de produtos de software dinâmica direcionada por qualidade : o caso de redes de monitoração do corpo humano

Dissertação (mestrado)—Universidade de Brasília, Instituto de Ciências Exatas, Departamento de Ciência da Computação, 2012.Na atualidade, os indivíduos passam a ter uma posição mais ativa no processo de investigação de doenças querendo acompanhar o seu estado de saúde continuamente. Por ser é inviável manter um profissional de saúde para cada indivíduo, mais apoio da tecnologia tem sido requerido a fim de auxiliar esse processo de monitoração. Diante deste quadro, mais soluções automatizadas estão sendo propostas, em particular, Redes de Sensores do Corpo Humano (RSCH), no qual um indivíduo monitora suas atividades diárias e sinais vitais e o sistema o auxilia na prevenção e detecção de situações de emergência. Este trabalho explora como a metodologia de Linha de Produto de Software Dinâmica (LPSD) no contexto de RSCH gerencia e balanceia requisitos conflitantes, tais como disponibilidade e confiabilidade, de tal forma que quando o indivíduo estiver em uma situação normal de saúde, o sistema possa desativar alguns sensores ou funcionalidades visando economia de bateria e processamento; e por outro lado, quando o indivíduo desmaiar ou alterar seus batimentos cardíacos, o oposto deva acontecer com os sensores afim de se prover o melhor serviço para o indivíduo em uma situação de alto risco de saúde. Uma LPSD para RSCH se reconfigura baseando-se em mudanças de contexto, no caso, mudança na situação de saúde do indivíduo monitorado, afim de atingir um novo objetivo de qualidade para esta nova situação de risco. Neste trabalho, a situação de um indivíduo é especificada como um contrato de qualidade, provido por um especialista no domínio (médico). O contrato é modelado como uma máquina de estados, onde as transições entre estados são causadas por eventos de saúde (queda, desmaio, alteração de pressão) e os estados definem objetivos de qualidade. A verificação de não conformidade com o objetivo de qualidade motiva a reconfiguração do sistema. A confiabilidade de uma determinada configuração é medida como uma única fórmula, parametrizada com a presença e ausência das features da LPSD e das qualidades associadas a elas. Além de confiabilidade, exploram-se também parâmetros de qualidade tais como tempo de vida estimado para o sistema, taxa de amostragem, qualidade e quantidade de informação das configurações. As estratégias de cálculo de qualidade Simple MultiAttribute Rating Technique (SMART) e orientação a objetivos (GOAL) são comparadas no domínio de RSCH. Avaliou-se a abordagem proposta via simulações com dados reais de monitoração e obteve-se resultado favorável à utilização da metodologia proposta no contexto. _______________________________________________________________________________________________________________________________ ABSTRACTNowadays, individuals have a more active stance in the investigation of diseases in the sense that they want to monitor their health status continuously. Because it is not sustainable to have dedicated health professional for each individual, more technology support has been applied to assist this monitoring process. In this context, automatic solutions are being proposed, in particular Body Sensor Network (BSN), in which an individual monitors his vital signs and the system aids him in the prevention and detection of emergency situations. BSN must manage and balance conflicting requirements, such as availability and reliability, in a way that if the patient is in a normal or low health risk situation, the system can turn off some sensors or disable features to save power and processing. On the other hand, when the individual faints or changes its heartbeats dangerously, the opposite should happen with the sensors and features in order to provide the best service for this high risk situation. We explore how Dynamic Software Product Line (DSPL) achieves this goal. A DSPL reconfigures itself based on some context changes e.g., the persons' medical situation, to meet a new quality goal for that new situation, as specified by a reliability contract provided by the domain expert (a medical doctor). This contract is modeled as a state machine, whose transitions are medical events (e.g., fall, stroke) and states are target reliability goals, prompting a reconfiguration to meet it. The reliability of any given configuration is measured by a single formula, parametrizing over the features of the DSPL and related quality information. Besides reliability, we also explore other quality parameters such as lifetime, sensor sample rate, quality and amount of information. Strategies for calculating quality such as Simple MultiAttribute Rating Technique (SMART) and goal-oriented are compared in the BSN domain. We evaluated the proposed approach via simulations with real monitoring data and obtained favorable results with the use of the proposed methodology in the BSN context

Feature-based methodology for supporting architecture refactoring and maintenance of long-life software systems

Zusammenfassung Langlebige Software-Systeme durchlaufen viele bedeutende Veraenderungen im Laufe ihres Lebenszyklus, um der Weiterentwicklung der Problemdomaenen zu folgen. Normalerweise ist es schwierig eine Software-Systemarchitektur den schnellen Weiterentwicklungen einer Problemdomaene anzupassen und mit der Zeit wird der Unterschied zwischen der Problemdomaene und der Software-Systemarchitektur zu groß, um weitere Softwareentwicklung sinnvoll fortzufuehren. Fristgerechte Refactorings der Systemarchitektur sind notwendig, um dieses Problem zu vermeiden. Aufgrund des verhaeltnismaeßig hohen Gefahrenpotenzials und des zeitlich stark verzoegerten Nutzens von Refactorings, werden diese Maßnahmen normalerweise bis zum letztmoeglichen Zeitpunkt hinausgeschoben. In der Regel ist das Management abgeneigt Architektur-Refactorings zu akzeptieren, außer diese sind absolut notwendig. Die bevorzugte Vorgehensweise ist, neue Systemmerkmale ad hoc hinzuzufuegen und nach dem Motto ”Aendere nie etwas an einem funktionierenden System!” vorzugehen. Letztlich ist das Ergebnis ein Architekturzerfall (Architekturdrift). Die Notwendigkeit kleiner Refactoring-Schritte fuehrt zur Notwendigkeit des Architektur-Reengineerings. Im Gegensatz zum Refactoring, das eine normale Entwicklungstaetigkeit darstellt, ist Reengineering eine Form der Software- ”Revolution”. Reengineeringprojekte sind sehr riskant und kostspielig. Der Nutzen des Reengineerings ist normalerweise nicht so hoch wie erwartet. Wenn nach dem Reengineering schließlich die erforderlichen Architekturaenderungen statt.nden, kann dies zu spaet sein. Trotz der enormen in das Projekt gesteckten Bemuehungen erfuellen die Resultate des Reengineerings normalerweise nicht die Erwartungen. Es kann passieren, dass sehr bald ein neues, kostspieliges Reengineering erforderlich wird. In dieser Arbeit werden das Problem der Softwareevolution und der Zerfall von Softwarearchitekturen behandelt. Eine Methode wird vorgestellt, welche die Softwareentwicklung in ihrer entscheidenden Phase, dem Architekturrefactoring, unterstuetzt. Die Softwareentwicklung wird sowohl in technischer als auch organisatorischer Hinsicht unterstuetzt. Diese Arbeit hat neue Techniken entwickelt, welche die Reverse-Engineering-, Architecture-Recovery- und Architecture-Redesign-Taetigkeiten unterst uetzen. Sie schlaegt auch Aenderungen des Softwareentwicklungsprozesses vor, die fristgerechte Architekturrefactorings erzwingen koennen und damit die Notwendigkeit der Durchfuehrung eines Architektur- Reengineerings vermeiden. In dieser Arbeit wird die Merkmalmodellierung als Hauptinstrument verwendet. Merkmale werden genutzt, um die Abstraktionsluecke zwischen den Anforderungen der Problemdomaene und der Systemarchitektur zu fuellen. Merkmalmodelle werden auch als erster Grundriss fr die Wiederherstellung der verlorenen Systemarchitektur genutzt. Merkmalbasierte Analysen fuehren zu diversen, nuetzlichen Hinweisen fuer den erneuten Entwurf (das Re-Design) einer Architektur. Schließlich wird die Merkmalmodellierung als Kommunikationsmittel zwischen unterschiedlichen Projektbeteiligten (Stakeholdern) im Verlauf des Softwareengineering-Prozesses verwendet und auf dieser Grundlage wird ein neuer Anforderungsde.nitionsprozess vorgeschlagen, der die erforderlichen Architekturrefactorings erzwingt.The long-life software systems withstand many significant changes throughout their life-cycle in order to follow the evolution of the problem domains. Usually, the software system architecture can not follow the rapid evolution of a problem domain and with time, the diversion of the architecture in respect to the domain features becomes prohibiting for software evolution. For avoiding this problem, periodical refactorings of the system architecture are required. Usually, architecture refactorings are postponed until the very last moment, because of the relatively high risk involved and the lack of short-term profit. As a rule, the management is unwilling to accept architecture refactorings unless they become absolutely necessary. The preferred way of working is to add new system features in an ad-hoc manner and to keep the rule ”Never touch a running system!”. The final result is an architecture decay. The need of performing small refactoring activities turns into need for architecture reengineering. In contrast to refactoring, which is a normal evolutionary activity, reengineering is a kind of software ”revolution”. Reengineering projects are risky and expensive. The effectiveness of reengineering is also usually not as high as expected. When finally after reengineering the required architecture changes take place, it can be too late. Despite the enormous invested efforts, the results of the reengineering usually do not satisfy the expectations. It might happen that very soon a new expensive reengineering is required. This thesis deals with the problem of software evolution and the decay of software architectures. It presents a method, which assists software evolution in its crucial part, the architecture refactoring. The assistance is performed for both technical and organizational aspects of the software evolution. The thesis provides new techniques for supporting reverse engineering, architecture recovery and redesigning activities. It also proposes changes to the software engineering process, which can force timely architecture refactorings and thus avoid the need of performing architecture reengineering. For the work in this thesis feature modeling is utilized as a main asset. Features are used to fill the abstraction gap between domain requirements and system architecture. Feature models are also used as an outline for recovering of lost system architectures. Through feature-based analyses a number of useful hints and clues for architecture redesign are produced. Finally, feature modeling is used as a communication between different stakeholders of the software engineering process and on this basis a new requirements engineering process is proposed, which forces the needed architecture refactorings

Uma abordagem floor interaction para o apoio à aprendizagem e ao comportamento das crianças autistas

Autism is known as a disorder of psychological development, as it is classified as F84.0 according to ICD-10 (International Classification of Diseases) (Fernandes, 2010). Studies indicate that autism presents three major groups of disorders: the social, communicative and behavioral. The social development of these children is usually disturbed, especially in interpersonal development, because children tend to isolation or to behave improperly. The level of communication, it is estimated that about 50% of these children do not develop the language throughout his life, and the other 50% may deviate language semantic and pragmatic. Moreover, persons with autism typically exhibit repetitive and stereotyped patterns of behavior, but also complex body movements (Gadia, Tuchman, & Rotta, 2004) (FPA 2003). In this sense this thesis of Master in Computer Engineering was proposed by the Whale Museum and has as main objective to develop an application of one of the activities in the educational area of the museum, but with the particularity of being targeted for autistic children.O autismo é denominado de transtorno de desenvolvimento psicológico, visto ser classificado como F84.0, segundo a CID-10 (Classificação Internacional de Doenças)(Fernandes, 2010). Estudos indicam que o autismo apresenta três grandes grupos de perturbações, nomeadamente a nível do domínio social, comunicativo e comportamental. O desenvolvimento social destas crianças normalmente é perturbado, especialmente no desenvolvimento interpessoal, pois as crianças têm tendência ao isolamento ou a comportar-se de forma sociavelmente imprópria, ou seja, fora dos padrões habituais. A nível da comunicação, estima-se que cerca de 50% destas crianças não desenvolvam a linguagem durante toda a sua vida, sendo que dos outros 50% a linguagem poderá apresentar desvios semânticos e pragmáticos. Para além disso, as pessoas com autismo normalmente exibem padrões repetitivos e estereotipados de comportamento, como também, movimentos corporais complexos (Gadia, Tuchman, & Rotta, 2004)(FPA, 2003). Neste sentido o presente projeto de Mestrado em Engenharia Informática foi proposto pelo Museu da Baleia e tem como principal intuito desenvolver uma aplicação de uma das atividades realizadas na área pedagógica do respetivo museu, mas com a particularidade de ser direcionado para crianças autistas