José Diego da SilvaRafael BernardoRafael Carício

Reconstrução de arquiteturas de software

MotivaçãoAplicada 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;

Reconstrução de arquiteturas de softwareA 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 existenteVerificar conformidade com as descrições

arquiteturaisDar suporte a melhoria/evolução do SW

Reconstrução de arquiteturas de softwareAs 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.

Atividades de reconstrução

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.

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.

Extração das informações

[Software Architecture in Practice]

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:o Formatos específicos de alguma ferramenta;o Banco de dados baseados em SQL.

• A escolha do formato da base de dados:o Deve ser um modelo de armazenamento conhecido;o Deve ser fácil de realizar consultas;o Permitir uso de linguagens que possam expressar padrões

arquiteturais; o 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.o Criar tabelas com dados previamente processados.

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.

Fusão de visões

• Realiza a fusão de visões para gerar uma representação coerente dos elementos.o  Classes e respectivas sub-classes dependendo do nível de

granularidade formam um ou mais elementos.

Reconstrução   

Nessa fase é feita um agrupamento de elementos 

Visualização e iteração no grafico

Definição e reconhecimento de padrões

Cenários Práticos

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

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.

View-Set[3]Solução desejada: Catalogar visões

arquiteturais, notações e abordagens para habilitar decisões sobre a visãoVarisos stakeholders: arquitetutus,

testadores, desenvolvedoresVarias representações: UML, Z, ACMEVarias abordagens: sistemas OO, funcionais

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.

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.

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

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.

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.

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.

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.

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.

The Common and Variable Artifacts Scenario [3]Solução: Métodos e ferramentas para

identificar e avaliar a variabilidade e partes comuns do sistema.

The Binary Components Scenario [1]Descrição: Aborda a RAS usando

descrições de componentes bináriosContexto: 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

The Binary Components Scenario [2]Problema: conduzir a reconstrução

quando são usados componentes bináriosExemplo: 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.

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.

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.

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;

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.

Abordagens e ferramentas

Reconstrução Manual

1. Crie uma visão alto-nível do sistema2. Atribua unidades de código a cada parte da

visão3. 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.

Reconstrução Manual com suporte de ferramentasPortable 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 Linuxcfx (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

C488 Compilador Pascal-like language[1]

C488 Compilador Pascal-like language[2]

http://swag.uwaterloo.ca/pbs/examples/C488/V1/html/parser.top.html

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 softwareModelo 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)

Rigi[2]

http://www.rigi.csc.uvic.ca/Pages/description/howitworks.html

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

SHriMPRecebe 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

KLOCwork inSight ToolImplementa 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.

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.

REFERÊNCIASBASS, 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.