• Refine Query
  • Source
  • Publication year
  • to
  • Language
  • 1
  • 1
  • Tagged with
  • 2
  • 2
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • About
  • The Global ETD Search service is a free service for researchers to find electronic theses and dissertations. This service is provided by the Networked Digital Library of Theses and Dissertations.
    Our metadata is collected from universities around the world. If you manage a university/consortium/country archive and want to be added, details can be found on the NDLTD website.
1

[en] FROM REQUIREMENTS TO CODE: A PROCESS TO DEVELOP MORE TRANSPARENT SOFTWARE / [pt] DOS REQUISITOS AO CÓDIGO: UM PROCESSO PARA DESENVOLVIMENTO DE SOFTWARE MAIS TRANSPARENTE

EDUARDO KINDER ALMENTERO 15 July 2015 (has links)
[pt] Transparência, no sentido de translúcido, é um conceito presente em uma enorme variedade de âmbitos e, recentemente, tem sido explorado no contexto de software. Um software transparente é aquele que informa sobre si mesmo, disponibilizando informação sobre o que faz, como e porque o faz. A abordagem da transparência no contexto de software se iniciou através da instanciação de um catálogo de requisitos não funcionais (RNFs), que inicialmente foi desenvolvido para transparência de processos. Durante a construção deste catálogo, notou-se que os RNFs dependência, rastreabilidade e detalhamento, presentes no catálogo, estão relacionados a problemas clássicos da Engenharia de Software. Estes problemas são, respectivamente, a definição de critérios para modularização do software, rastreabilidade entre seus artefatos e entendimento do seu código. Neste trabalho, propomos estratégias para lidar especificamente com estes três problemas, contribuindo também para construção de softwares mais transparentes, uma vez que sua solução implica na satisfação de qualidades do catálogo. Estas estratégias foram estruturadas através de um processo de construção de software. Esse processo tem como escopo software para Web, utilizando arquitetura MVC, desenvolvido através do paradigma de programação procedural. A ideia central do processo é a utilização de dois artefatos de requisitos, Léxico Ampliado da Linguagem (LAL) e cenários, durante todo processo de construção do software. O LAL é utilizado na definição dos módulos do software. Os cenários são refinados em diferentes níveis de abstração, de modo que permeiam todo o processo, desde os requisitos até serem integrados ao código fonte do software. Os rastros entre os diferentes níveis de abstração dos cenários são mantidos. As operacionalizações propostas no processo foram anexadas ao catálogo de transparência de software, possibilitando futura reutilização orientada a qualidades. O processo e suas operacionalizações foram avaliados através de estudos empíricos envolvendo diversos sujeitos. O resultado das avaliações sugere que o processo contribui positivamente para as qualidades de detalhamento, dependência e rastreabilidade, presentes no catálogo de transparência. / [en] Transparency is a concept that permeates different disciplines, and recently has been explored in the context of software engineering. Transparent software aims to make information about it transparent and also aims to provide transparency on its behavior. The study of transparency in the context of software started by instantiating a catalog of non-functional requirements (NFRs). During the construction of this catalog, we realized that the NFRs of traceability, dependability and detailing are related to classical problems in software engineering. These problems are, respectively, the definition of software modules, traceability between its artifacts and the understanding of its source code. In this work we propose strategies to deal specifically with these three problems. As these problems are also related to the transparency catalog, then if we contribute to solving these problems, we will also be contributing to software transparency. These strategies were structured through a software construction process that has Web software as its main target. The process uses MVC architecture and procedural oriented programming languages. The central idea of this process is to use two requirements artifacts, the Language Extended Lexicon (LEL) and scenarios, throughout the construction process. The LEL is used in the definition of the software modules. The scenarios are refined at different levels of abstraction so that they permeate the entire development process, from requirements documentation until their integration with the software source code. The traces between these scenarios are maintained. The strategies proposed in the process were attached to the software transparency catalog to allow for quality based reuse. The process and its operationalizations were evaluated through empirical studies involving different subjects. The results of the evaluations suggest that the process contributes positively to the quality of detailing, dependency and traceability, present in the transparency catalog.
2

[pt] CATALOGANDO ANTIPADRÕES DE INJEÇÃO DE DEPENDÊNCIA EM SISTEMAS DE SOFTWARE / [en] CATALOGING DEPENDENCY INJECTION ANTI-PATTERNS IN SOFTWARE SYSTEMS

RODRIGO NUNES LAIGNER 19 June 2020 (has links)
[pt] Contexto Injeção de Dependência (DI) é um mecanismo comumente aplicado para desacoplar classes de suas dependências com o objetivo de prover uma melhor modularização do software. No contexto de Java, a existência de uma especificação de DI e frameworks populares, como o Spring, facilitam o emprego de DI em projetos de software. Entretanto, más práticas de implementação de DI podem trazer más consequências, como maior acoplamento, dificultando alcançar o principal objetivo de DI. Apesar de a literatura sugerir a existência de anti-padrões de DI, não há uma documentação detalhada de tais más práticas. Em adição, não há evidência da ocorrência e da percepção de utilidade dos mesmos do ponto de vista de desenvovedores. Objetivos Nosso objetivo é revisar os anti-padrões de DI reportados com o objetivo de analisar sua completude e propor um novo catálogo de anti-padrões de DI para Java. Método Nós propomos um catálogo contendo 12 anti-padrões de DI para Java. Nós selecionamos 4 projetos open-source e 2 projetos closed-source que adotam um framework de DI e desenvolvemos uma ferramenta que analisa estaticamente a ocorrência dos anti-padrões de DI candidatos no código fonte das aplicações. Em adição, nós conduzimos uma pesquisa por meio de entrevistas face a face com três desenvolvedores experientes que regularmente aplicam DI em seus projetos. Nós estendemos a pesquisa com o objetivo de obter a percepção de um conjunto de 15 desenvolvedores experientes e novatos por meio de um questionário online Resultados Ao menos 9 anti-padrões de DI apareceram frequentemente nos projetos de software analisados. Em adição, a avaliação recebida dos desenvolvedores confirmaram a relevância do catálogo. Por fim, os respondentes expressaram o desejo de refatorar as instâncias de antipadrões de DI propostas. Conclusões O catálogo contém anti-padrões de DI que ocorrem na prática e são úteis. Compartilhar com praticantes da indústria os permitirá evitar a introdução de anti-padrões em seus projetos de software. / [en] Background Dependency Injection (DI) is a commonly applied mechanism to decouple classes from their dependencies in order to provide better modularization of software. In the context of Java, the availability of a DI specification and popular frameworks, such as Spring, facilitate DI usage in software projects. However, bad DI implementation practices can have negative consequences, such as increasing coupling, hindering the achievement of DI s main goal. Even though the literature suggests the existence of DI anti-patterns, there is no detailed documentation of such bad practices. Moreover, there is no evidence on their occurrence and perceived usefulness from the developer s point of view. Aims Our goal is to review the reported DI anti-patterns in order to analyze their completeness and to propose and evaluate a novel catalog of Java DI anti-patterns. Method We propose a catalog containing 12 Java DI anti-patterns. We selected 4 opensource and 2 closed-source software projects that adopt a DI framework and developed a tool to statically analyze the occurrence of the candidate DI anti-patterns within their source code. Also, we conducted a survey through face to face interviews with three experienced developers that regularly apply DI. We extended the survey in order to gather the perception of a set of 15 expert and novice developers through an online questionnaire. Results At least 9 different DI anti-patterns appeared frequently in the analyzed projects. In addition, the feedback received from the developers confirmed the relevance of the catalog. Besides, the respondents expressed their willingness to refactor instances of anti-patterns from source code. Conclusions The catalog contains Java DI anti-patterns that occur in practice and are useful. Sharing it with practitioners may help them to avoid such anti-patterns.

Page generated in 0.0367 seconds