Made available in DSpace on 2014-06-12T15:52:08Z (GMT). No. of bitstreams: 1 license.txt: 1748 bytes, checksum: 8a4605be74aa9ea9d79846c1fba20a33 (MD5) Previous issue date: 2008 / O projeto de software visa descrever os principais aspectos do sistema a ser construído através de mecanismos que ajudam a raciocinar sobre a complexidade. Dentre as ativi- dades do projeto de software, destaca-se a elaboração e documentação da arquitetura, um dos principais mecanismos para raciocinar e lidar com essa complexidade. Uma das principais metas do projeto da arquitetura é a modularizadão do sistema através do esta- belecimento de design rules que deverão ser obedecidas pelos desenvolvedores. Exemplos de design rules estabelecidas no projeto da arquitetura são os serviços disponibilizados pelos componentes e as regras de comunicação entre estes. A modularizacão dos sistemas de software também motivou o surgimento da Pro- gramação Orientada a Aspectos (POA). Entretanto estudos recentes mostraram que a utilização da POA apesar de ser um meio efetivo para modularizacão de interesses trans- versais, pode prejudicar a modularidade dos demais interesses se design rules não forem estabelecidas pelo projetista. Muitas das design rules necessárias para melhorar a modu- laridade de sistemas orientados a aspectos são definidas na fase de projeto da arquitetura do software. Para criação e documentação do projeto da arquitetura uma das principais abordagens é a utilização de Linguagens de Descrição de Arquitetura (LDA), que permitem descrever a arquitetura de forma clara e não ambígua, possibilitando a verificação de uma série de propriedades que antes são poderiam ser analisadas depois do implementação do software. O problema na utilização desta abordagem é que o modelo de arquitetura utilizado pela maioria das LDAs, formado por abstrações como componentes e conectores, é diferente do modelo baseado em objetos utilizado por muitas linguagens de programação, tornado difícil o mapeamento e a consistência entre essas fases do desenvolvimento. Entretanto, para garantir a modularidade do sistema e as propriedades arquiteturais obtidas através de uma LDA, é necessário apenas garantir que as design rules estabelecidas por esta são obedecidas pelo código desenvolvido. Neste trabalho propomos um mapeamento das design rules implicitamente definidas por uma linguagem de descrição arquitetural para uma linguagem de descrição de design rules, responsável por verificar se estas estão sendo obedecidas no código desenvolvido. A verificação das design rules permite garantir que a modularidade e as propriedades arqui- teturais obtidas através do projeto da arquitetura sejam válidas no código desenvolvido. A LDA escolhida foi a linguagem AspectualAcme, que utiliza os conceitos da orientação a aspectos, permitindo que as design rules geradas melhorem também a modularidade de sistemas orientados a aspectos. Para diminuir os custos com a tradução, também foi construída uma ferramenta capaz de gerar automaticamente, a partir de uma especificação válida em AspectualAcme, as regras na linguagem de descrição de design rules. Além da economia de tempo dos desenvolvedores, o suporte automático para tradução evita que erros sejam cometidos ou que design rules sejam esquecidas, garantindo dessa forma as propriedades verificadas no modelo arquitetura e a modularidade do sistema

Made available in DSpace on 2014-12-17T15:47:59Z (GMT). No. of bitstreams: 1 KeivilanyJLC_DISSERT.pdf: 3136956 bytes, checksum: 58f2931b21ff1ab0cd5e4e065e0d1aa4 (MD5) Previous issue date: 2012-02-06 / Conselho Nacional de Desenvolvimento Cient?fico e Tecnol?gico / The tracking between models of the requirements and architecture activities is a strategy that aims to prevent loss of information, reducing the gap between these two initial activities of the software life cycle. In the context of Software Product Lines (SPL), it is important to have this support, which allows the correspondence between this two activities, with management of variability. In order to address this issue, this paper presents a process of bidirectional mapping, defining transformation rules between elements of a goaloriented requirements model (described in PL-AOVgraph) and elements of an architectural description (defined in PL-AspectualACME). These mapping rules are evaluated using a case study: the GingaForAll LPS. To automate this transformation, we developed the MaRiPLA tool (Mapping Requirements to Product Line Architecture), through MDD techniques (Modeldriven Development), including Atlas Transformation Language (ATL) with specification of Ecore metamodels jointly with Xtext , a DSL definition framework, and Acceleo, a code generation tool, in Eclipse environment. Finally, the generated models are evaluated based on quality attributes such as variability, derivability, reusability, correctness, traceability, completeness, evolvability and maintainability, extracted from the CAF? Quality Model / O rastreamento entre modelos das atividades de requisitos e arquitetura ? uma estrat?gia que busca evitar a perda de informa??es, reduzindo o gap entre essas duas atividades iniciais do ciclo de vida do software. No contexto das Linhas de Produto de Software (LPS), ? importante que haja um suporte a esse rastreamento, que permita a correspond?ncia entre as duas atividades, com um gerenciamento satisfat?rio das variabilidades. Buscando atender a essa quest?o, este trabalho apresenta um processo de mapeamento bi-direcional, definindo regras de transforma??o entre elementos de modelo de requisitos orientado a objetivos (descrito em PL-AOVgraph) e elementos de descri??o arquitetural (definida em PL-AspectualACME). Essas regras de mapeamento s?o avaliadas em um estudo de caso: a LPS Ginga ForAll. Para automatizar essa transforma??o, implementamos a ferramenta MaRiPLA (Mapping Requirements to Product Line Architecture), atrav?s de t?cnicas do desenvolvimento dirigido a modelos (Model-driven Development MDD), incluindo a linguagem de transforma??es entre modelos Atlas Transformation Language (ATL) com especifica??o de metamodelos do tipo Ecore em conjunto com os frameworks Xtext, de defini??o DSL, e Acceleo, de gera??o de c?digo, em ambiente Eclipse. Por fim, os modelos gerados s?o avaliados, com base em atributos de qualidade como variabilidade, derivabilidade, reusabilidade, corretude, rastreabilidade, completude, evolutibilidade e manutenibilidade, extra?dos do Modelo de Qualidade CAF?