Reconstrução de arquiteturas de software

Apresentação em tema: "Reconstrução de arquiteturas de software"— Transcrição da apresentação:

1 Reconstrução de arquiteturas de software
José Diego da Silva Rafael Bernardo Rafael Carício

2 Motivação Aplicada quando se deseja mudar o software existente ou validar possibilidades de mudança; A atividade de reconstrução de SW (RAS) pode ser aplicada em vários cenários diferentes: Softwares que trabalham com linguagens de programação diferentes; Softwares com componentes binários; Extrai visões importantes para a avaliação do software;

3 Reconstrução de arquiteturas de software
A reconstrução de arquitetura de software é um processo de engenharia reversa que permite que seja resgatada decisões de projeto tomadas durante a construção do software (SW). Conhecimento sobre um SW existente Verificar conformidade com as descrições arquiteturais Dar suporte a melhoria/evolução do SW

4 Reconstrução de arquiteturas de software
As etapas da tarefa de RAS podem ser: Extração de dados; Construção da Base de Dados; Fusão de visões; Reconstrução Ferramentas usadas podem ser: Manual; Parcialmente automatizada; Totalmente automatizada.

5 Atividades de reconstrução

6 Extração das informações
O propósito desta atividade é extrair informações de várias fontes distintas.  Envolve análise do "design" existente e artefatos de implementação.  O resultado é um conjunto de informações inseridas em uma base de dados. Dos artefatos analisados é possível identificar e capturar elementos de interesse. Cada uma das relações entre os elementos fornece informações diferentes sobre o sistema.

7 Extração das informações
As relações de chamada entre métodos/funções ajuda a construir o gráfico de chamadas. As relações de uso entre os arquivos permite visualizar o  conjunto de dependências entre os arquivos do sistema.  Os acessos de leitura e escrita mostram como os dados são usado.

8 Extração das informações
[Software Architecture in Practice]

9 Construção da Base de Dados
A construção da base de dados envolve a coversão das informações para um formato padrão: Formatos específicos de alguma ferramenta; Banco de dados baseados em SQL. A escolha do formato da base de dados: Deve ser um modelo de armazenamento conhecido; Deve ser fácil de realizar consultas; Permitir uso de linguagens que possam expressar padrões arquiteturais; Deve ser simples de realizar junções de visões. O modelo de dados deve ser simples para permitir a realização consultas de forma fácil. Criar tabelas com dados previamente processados.

10 Fusão de visões Combina as informações do banco de dados para produzir uma visão coerente da arquitetura. Manipula dados previamente armazenados na base de dados para estabelecer conexões entre os elementos. Utiliza visões de diferentes níveis de granularidade.

11 Fusão de visões Realiza a fusão de visões para gerar uma representação coerente dos elementos.  Classes e respectivas sub-classes dependendo do nível de granularidade formam um ou mais elementos.

12 Reconstrução Nessa fase é feita um agrupamento de elementos
Visualização e iteração no grafico Definição e reconhecimento de padrões

13 Cenários Práticos

14 View-Set[1] Descrição: Identificação das visões arquiteturais que definem o sistema que definem suficientemente o sistema Contexto: Conjunto de visões arquiteturais(diferentes tipos/estilos) Problema: que visões arquiteturais utilizar com base na necessidade dos stakeholders

15 View-Set[2] Exemplo: O grupo de melhoria de processo de uma organização gostaria de avaliar uma empresa que produz software embarcado quando a conformidade de suas implementações com as especificações originais. Não existe uma arquitetura e é preciso fornecer visões arquiteturais que atestem essa conformidade.

16 View-Set[3] Solução desejada: Catalogar visões arquiteturais, notações e abordagens para habilitar decisões sobre a visão Varisos stakeholders: arquitetutus, testadores, desenvolvedores Varias representações: UML, Z, ACME Varias abordagens: sistemas OO, funcionais

17 Enforced-Architecture[1]
Descrição: Aborda o problema da necessidade de consistência entre a arquitetura do sistema construído e a arquitetura projetada para o mesmo. Cenário: não existem construções padrão nas linguagens de programação que capturem os conceitos presentes na definição de uma arquitetura. Assim uma implementação está sugeita a implementar de forma inapropriada ou pobre conceitos presentas na arquitetura. Uma análise de conformidade entre a arquitetura projetada e a arquitetura presente no sistema é necessária.

18 Enforced-Architecture[2]
Problema: ausência de um mapeamento relacione elementos da arquitetura com elementos de implementação Exemplo: Uma organização desenvolve um produto onde nem todos os seus componentes são desenvolvidos in-house. Erros inesperados ocorreram durante os testes de integração dos componentes externos com o restante do sistema; é decidido verificar se a arquitetura projetada para os componentes externos esta em conformidade com a arquitetura presente no sistema.

19 Enforced-Architecture[3]
Solução Desejada: Deve consistir de um método e ferramentas de suporte que forcem conformidade arquiteral que podem ser parte de um ferramenta geral de forward- engineering O método e ferramentas devem mensurar qual bem os componentes estão de acordo com a arquitetura definida. Benefício: Questões contratuais podem ser aferidas como no exemplo dado

20 The Quality-Attribute-Changes Scenario [1]
Exemplo: Uma empresa quer mudar seu sistema para WEB. Preocupações: como novos atributos de qualidade requeridos (ex: disponibilidade, segurança) impactam o sistema atual. Descrição de arquitetura não disponível. Reconstrução da arquitetura para saber o impacto de novos atributos de qualidade na arquitetura atual e que partes da arquitetura são afetadas por estes. Problema: Como determinar a relação entre atributos de qualidade e elementos arquiteturais.

21 The Quality-Attribute-Changes Scenario [2]
Descrição: Aborda como padrões arquiteturais são usados para satisfazer requisitos de qualidade e quais mudanças nestes requisitos impactam no sistema. Contexto: Decisões de Projeto são fortemente influenciadas pela necessidade de atingir metas de atributos de qualidade. tradeoff (ex: desempenho x extensibilidade). tradeoff deve avaliar valor de negócio.

22 The Quality-Attribute-Changes Scenario [3]
Solução: Método e ferramenta  para reconstrução das informações sobre como um sistema é impactado por um atributo particular de qualidade.

23 The Common and Variable Artifacts Scenario [1]
Descrição:LPS permite a redução de custos pelo reuso dos artefatos básicos. Este cenário provê modelo e técnica para análise de produtos em um domínio. Contexto: Linha de Produtos. Para avaliar a possibilidade da criação de uma nova LP de produtos existentes é necessário avaliar a arquitetura analizando variabilidade e partes comuns.

24 The Common and Variable Artifacts Scenario [2]
Problema: Como identificar partes comuns e variáveis em produtos similares. Exemplo: Uma empresa tem três times de desenvolvimento produzindo produtos similares. Um grupo avalia o potencial de reuso com o uso de LSP. A empresa deve realizar uma reconstrução da arquitetura pelos três representantes dos times a fim de revelar as partes de cada sistema comuns a todos.

25 The Common and Variable Artifacts Scenario [3]
Solução: Métodos e ferramentas para identificar e avaliar a variabilidade e partes comuns do sistema.

26 The Binary Components Scenario [1]
Descrição: Aborda a RAS usando descrições de componentes binários Contexto: A indústria de SW está rapidamente movendo seus sistemas baseados em componentes comerciais. A reconstrução de SW baseia-se nas descrições dos componentes, se abstraindo do código fonte. A eficácia desse processo depende do nível de detalhamento da interface dos componentes

27 The Binary Components Scenario [2]
Problema: conduzir a reconstrução quando são usados componentes binários Exemplo: uma empresa vai desenvolver uma aplicação que se comunica com um banco de dados, e usa dois componentes comerciais. O código fonte da aplicação está disponível, porém o dos componentes não.

28 The Binary Components Scenario [3]
Solução desejada: a abordagem consiste na criação de pequenos programas para explorar deficiências que podem comprometer o desenvolvimento dos produtos reais. Deve permitir que o arquiteto conheça as limitações destes componentes.

29 The Mixed-Language Scenario [1]
Descrição: demonstra a necessidade de modelos e técnicas que podem ser usadas para analisar SW que são desenvolvidos usando linguagens diferentes ou tipos de linguagens diferentes (procedural e orientadas a objeto) Contexto: Sistemas desenvolvidos em partes que se comunicam, porém que são implementados em linguagens de programação diferentes.

30 The Mixed-Language Scenario [2]
Problema: reconstruir o SW que foi implementado em mais de uma linguagem diferente Exemplo: Uma organização quer entender um sistema existente pois deseja integrar partes deste sistema com outro sistema que também já existe feito por outra organização; Não existe documentação do sistema existente e não existe ninguém na organização que saiba tudo sobre o sistema. Algumas pessoas entendem partes isoladas do sistema;

31 The Mixed-Language Scenario [3]
O sistema está implementado em diferentes linguagens de programação. Solução desejada: utilizar ferramentas previamente existentes, pois elas já estão habilitadas para extrair informação de linguagens de programação diferentes.

32 Abordagens e ferramentas

33 Reconstrução Manual 1. Crie uma visão alto-nível do sistema
2. Atribua unidades de código a cada parte da visão 3. Repita o passo 1 para cada parte da visão que não esta no nível de abstração necessário ao propósito da reconstrução Não usadas somente utilitários como Emacs e Grep.

34 Reconstrução Manual com suporte de ferramentas
Portable Bookshelf (PBS): suporte a geração(com ajuda de utilitários) e visualização do sistema em um formato web. Pode conter informações como código fonte, casos de teste, análise de performance e diagramas arquiteturais. Ex: Reconstrução da arquitetura do Linux cfx (c-code fact extractor): extrai relações entre elementos de baixa granularidade(funções, variáveis, estruturas) Manualmente: criação de uma árvore de subsitemas e atribuição de arquivos fonte a cada subsistema grok fact manipulator: identificar relações entre os subsistemas lsedit visualization: para visualização da estrutura

35 C488 Compilador Pascal-like language[1]

36 C488 Compilador Pascal-like language[2]

37 Rigi[1]  Ferramenta visual interativa que suporta que auxilia no entendimento e re-documentação do software  Regiedit: provê edição, manipulação, anotação e exploração da capacidades Parser: extração de artefatos do software Modelo de domínio: especifica tipos de entidade e relações de interesse. É usada como entrada para criação do gráfico inicial do sistema. Parser de muitas linguagens para Rigi Standard Format (RSF)

38 Rigi[2] É possível selecionar, filtrar, definir padrões e editar o gráfico para identificar pertinentes subsistemas

39 SHriMP Recebe como entrada um arquivo no formato RSF (Rigi Standard Format ) e gera uma visualização da informação estraida do sistema. Através de agregação manual é possivel agrupar elementos no grafico Menos poderoso que o Regi; pode ser usado em conjunto com este para prover uma forma alternativa de visualização

40 KLOCwork inSight Tool Implementa algoritmo de análise de código para extrair visões arquiteturais de código, interações, fluxo de controle e threads de execução diretamente do código fonte Não permite aplicação de padrões customizados para criação de abstrações maiores Permite seleção, visualização e criação de agrupamentos manualmente que formam abstrações de mais alto nível.

41 Conclusão É uma tarefa importante para extração de conhecimento de um sistema com uma deficiência de documentação Importante para validação da arquitetura implementada pelo SW. A utilização de ferramentas automatizadas aumenta a velocidade e precisão das informações extraídas.

42 REFERÊNCIAS BASS, L.; CLEMENTS, P.; KAZMAN, R. Software Architecture in Practice. Addison-Wesley, 2003. L O'Brien, C Stoermer, C Verhoef. Software Architecture Reconstruction: Practice Needs and Current Approaches, 2002. A Deursen, C Riva. Software Architecture Reconstruction. IEEE, 2004.