IDENTIFICAÇÃO DE PADRÕES ARQUITETURAIS USANDO ENGENHARIA REVERSA Marcos Antonio Quináia 1,2 e Paulo Cézar Stadzisz 1 quinaia@cpgei.cefetpr.br e stadzisz@lit.cpdtt.cefetpr.br 1 Centro Federal de Educação Tecnológica do Paraná - CEFET-PR Programa de Pós-Graduação em Eng. Elétrica e Informática Industrial - CPGEI http://www.cpgei.cefetpr.br 2 Universidade Estadual do Centro-Oeste - UNICENTRO http://www.unicentro.br Resumo A engenharia reversa é o processo de análise de um sistema computacional que possibilita a criação de representações do sistema analisado em outra forma e/ou em outro nível de abstração. O objetivo da engenharia reversa é resgatar informações de valor, presentes nos sistemas computacionais, e representá-las de forma que seja possível o reuso posterior. Esse esforço visa não só melhorar a qualidade geral dos sistemas computacionais mas também aumentar a produtividade do processo de desenvolvimento de software. Este artigo apresenta um método para engenharia reversa que, aplicado a um conjunto de sistemas computacionais pertencentes a um mesmo domínio, gera a descrição de um padrão arquitetural que unifica os sistemas computacionais analisados. Abstract Reverse Engineering is the analysis process of a computational system which enables to create representations of the analyzed system in another form and/or abstraction level. The reverse engineering purpose is to recover valuable information present in the computational systems and represent them to enable its posterior reuse. This effort aims not only to improve the general quality of the computational systems, but also to increase the productivity of the software develment process. This article presents a method for reverse engineering that applied to a set of computational systems pertaining to a same domain generates a description of the architectural pattern which unifies the analyzed computational systems. 1. Introdução Como outros produtos, os sistemas computacionais também se tornam obsoletos ao longo do tempo. Essa obsolescência provoca a necessidade de freqüentes ajustes nos sistemas para adaptá-los às novas tecnologias e, principalmente, às exigências do negócio ou dos usuários [5]. Assim, faz-se necessário encontrar formas para facilitar a manutenção, evolução e reuso de software visando o prolongamento da vida útil dos sistemas computacionais. Uma das grandes dificuldades para a manutenção e reuso de software é a falta ou desatualização da documentação dos sistemas. Ao longo do tempo, todo o conhecimento sobre a arquitetura do software passa a estar contida unicamente no seu código. Neste tipo de cenário a evolução do sistema depende de um esforço de análise de sua documentação para extração de componentes e relações com o objetivo de redescobrir a arquitetura originalmente imaginada. Esta arquitetura de sistema, obtida através de um processo de engenharia reversa, poderá, então, permitir que mudanças ou reusos conscientes possam ser desenvolvidos. Neste artigo prõe-se aplicar um processo de engenharia reversa sobre um conjunto de sistemas computacionais similares (pertencentes a um mesmo domínio 1 ) com o objetivo de produzir um modelo único de arquitetura. Este modelo unifica as arquiteturas dos sistemas analisados em uma representação genérica aplicável a problemas recorrentes. Esta representação genérica é denominada padrão arquitetural. 1 Na engenharia de software, um Domínio abrange uma família de sistemas computacionais que compartilham um conjunto de requisitos comuns [2; 8].
O processo prosto parte da análise das interfaces e documentações disponíveis dos sistemas para: a) extrair os requisitos de cada sistema e criar um modelo de requisitos genérico; e b) extrair e analisar os modelos estruturais de cada sistema e criar o modelo de arquitetura do padrão arquitetural. O Padrão arquitetural sintetizado poderá ser reutilizado na instanciação de software para o domínio que o padrão representa, assim como as documentações obtidas servirão para a manutenção dos respectivos sistemas. 2. Resumo do Processo de Engenharia Reversa O processo prosto utiliza os princípios da Análise de Domínio. A Análise de Domínio é uma atividade que tem como objetivo fornecer suporte sistemático para reuso em larga escala através da identificação, captura e organização de partes semelhantes dos sistemas em um domínio, visando melhorar a eficiência do desenvolvimento e manutenção destes sistemas [6; 4; 3]. A aplicação do processo prosto deve considerar pelo menos três sistemas para se configurar a natureza de recorrência de um padrão relativo a um determinado domínio [1]. A Figura 1 mostra um resumo simplificado do processo para a identificação de um padrão. A parte superior da Figura 1 mostra um exemplo de domínio hipotético que é composto de n negócios. Cada negócio é composto por um conjunto de transações ou atividades agrupadas logicamente em encadeamentos aqui denominados serviços. O negócio N 2, por exemplo, é composto por seis serviços que são implementados em três sistemas computacionais (A, B e C). Deve-se notar que poderiam existir mais negócios (N n ) no domínio assim como mais serviços (S m ) no negócio e, também, mais sistemas computacionais que implementassem os serviços. Domínio N 1 N 2 N n Negócios S 1 S 2 S 3 S 4 S 5 S 6 S m Serviços Sistema A Sistema B Sistema C Sistema N Sistemas Computacionais Análise de Requisitos Requisitos dos Sistemas Análise de Arquitetura Análise de equivalência funcional Requisitos do Padrão Diferenciação dos requisitos Requisitos Iniantes Requisitos Variantes Requisitos Opcionais Requisitos Múltiplos Modelos Estruturais dos Sistemas Análise Estrutural Modelo estrutural do Padrão Modelos de Interações dos Sistemas Análise das Interações Modelo de Interações do Padrão Modelos de Estados dos Sistemas Análise dos Estados Modelo de Estados do Padrão Componentes específicos de cada sistema Núcleo do Padrão Figura 1 Identificação de padrão arquitetural em uma família de sistemas pertencentes a um domínio
A parte central da Figura 1 mostra duas etapas principais de análise: 1) Análise de Requisitos e 2) Análise de Arquiteturas. Na etapa de Análise de Requisitos procura-se extrair, analisar, classificar e descrever os requisitos que compõem o domínio de aplicação, representado pelo conjunto dos sistemas analisados, de forma que os requisitos genéricos do padrão arquitetural sejam evidenciados. Analisando-se os serviços que os sistemas A, B e C, da Figura 1, implementam, verifica-se que existem alguns serviços que são implementados exclusivamente por um dos três sistemas, outros serviços são implementados por dois sistemas e outros serviços são implementados pelos três sistemas computacionais (e. g. os serviços S 3 e S 4 ) e, portanto, constituem o núcleo do padrão arquitetural. Uma vez identificados esses requisitos, inicia-se a modelagem dos casos de uso, utilizando-se uma extensão da notação UML que está resumida na seção 3. Na etapa de Análise de Arquitetura procura-se verificar as estruturas dos sistemas e sintetizar os componentes estruturais que passarão a fazer parte do padrão arquitetural. As informações extraídas nas etapas de análise de requisitos e de arquitetura são sintetizadas na forma de um padrão arquitetural que representa uma solução genérica para reuso (parte inferior da Figura 1). 3. Extensão da Notação UML para Modelos de Casos de Uso A extensão para modelos de casos de uso, resumida nesta seção, é utilizada para especificar os requisitos funcionais de padrões arquiteturais extraídos mediante a análise de um conjunto de sistemas computacionais que pertençam a um domínio [7]. Tipologia Para Atores e Casos de Uso Esta extensão prosta apresenta a tipologia para atores e casos de uso genéricos identificados quando da modelagem dos requisitos do padrão arquitetural. Os atores e casos de uso clássicos definidos na UML [9] são também usados na modelagem de padrões. Eles representam, respectivamente, atores específicos (entidades externas) e casos de uso específicos (serviços ou funcionalidades do sistema) que estarão presentes em todas as instâncias do padrão arquitetural. Atores e Casos de Uso Opcionais Um ator cional é uma entidade externa ao sistema que pode ou não aparecer em instâncias do padrão (e. g. um administrador de sistema). Um caso de uso cional indica uma funcionalidade que pode ou não aparecer em um sistema que é modelado usando o padrão. (e. g. um diálogo de início de uma sessão. A notação adotada usa o rótulo e um retângulo em volta do ator para indicar que esse ator é cional. Para o caso de uso cional usa-se apenas o rótulo dentro da elipse que representa o caso de uso (Figura 2a). Ator e Caso de Uso Variante Um ator iante expressa uma entidade externa genérica do padrão arquitetural. Por Entidade Externa Genérica pode-se entender uma entidade que existe em toda instância do padrão, porém suas prriedades ou características iam entre as instâncias do padrão (e. g. um software externo implementado em diferentes versões). Um caso de uso iante representa um serviço ou uma funcionalidade genérica. Trata-se de uma abstração ou uma unificação de um conjunto de casos de uso similares. (e. g. um serviço para estabelecer conexão entre computadores por meio de uma rede que possa ser de tipos diferentes). A notação adotada para atores e casos de uso iantes aplica um rótulo ao lado do ícone correspondente (Figura 2b).
Ator e Caso de Uso Múltiplo Ator ou caso de uso múltiplo pode aparecer uma ou mais vezes nos sistemas computacionais projetados a partir do padrão. Um ator múltiplo expressa um conjunto de atores do mesmo tipo, isto é, esses atores têm papel similar com relação aos casos de uso aos quais estão associados. (e. g. usuários de um sistema ou as suas impressoras. Pode haver um ou vários usuários do sistema ou impressoras em um dado sistema). Um caso de uso múltiplo indica uma funcionalidade do padrão que pode ter múltiplas execuções independentes em várias threads ou em processadores diferentes, nas instâncias que utilizam o padrão. (e. g. um serviço de controle de dispositivo usado para controlar um certo número de dispositivos externos). A notação adotada para atores e casos de uso múltiplos é um fundo acinzentado no ícone correspondente (Figura 2c). Nome do ator Nome do caso de uso Nome do ator a) Atores e Casos de Usos b) Atores e Casos de Usos c) Atores e Casos de Usos Opcionais Variantes Múltiplos Figura 2 Notação da Extensão para Modelos de Casos de Uso Nome do caso de uso Nome do ator Nome do caso de uso Combinação de Tipos Os três tipos classificadores prostos (cional, iante e múltiplo) podem ser reunidos para permitir combinações desses tipos. Exemplos de combinações são: i) Ator e Caso de Uso Múltiplo e Opcional; ii) Ator e Caso de Uso Variante e Múltiplo; iii) Ator e Caso de Uso Opcional e Variante; iv) Ator e Caso de Uso Múltiplo, Variante e Opcional. 4. Identificação e Descrição de Padrão Arquitetural Os passos descritos a seguir têm o objetivo de servir como metodologia para as etapas de identificação e descrição de um padrão arquitetural. Buscar sistemas que implementam a solução para o domínio do problema Efetuar uma busca por sistemas computacionais e respectivas documentações já desenvolvidos e disponíveis que implementem a solução para a qual se deseja criar o padrão. Buscar, ainda, outras documentações disponíveis para a solução desejada. Análise dos Requisitos Compor uma tabela com as funcionalidades dos sistemas analisados Inicialmente, deve-se montar uma tabela para cada sistema contendo as suas funcionalidades. Essas tabelas (Tabela 1) devem ser exaustivas de modo a conter as funcionalidades de cada sistema. Durante a descrição das tarefas busca-se o agrupamento das funções em possíveis módulos do sistema. Entende-se por módulo uma parte de um sistema computacional que agrega algumas funções desse sistema. Busca-se ainda a identificação de possíveis atores do sistema. ATOR MÓDULO FUNÇÃO......... Tabela 1 - Módulos e funções de cada sistema
Uma vez completas as tabelas (Tabela 1) referentes a cada sistema, deve-se então mesclar essas tabelas retirando módulos e funcionalidades duplicados, formando-se assim uma tabela única (Tabela 2) que represente as funcionalidades de todos os sistemas analisados. Esta tarefa é bastante subjetiva e demanda muita atenção e conhecimento do domínio para mesclar corretamente as funcionalidades duplicadas que são consideradas importantes para o domínio. A nova tabela (Tabela 2), resultante do processo de mixagem das tabelas individuais de cada sistema, permite identificar as funcionalidades que são comuns a todos os sistemas e, também, aquelas que são específicas de algum ou alguns dos sistemas analisados. Ator Módulo Função Sistemas que implementam Bibliotecário Cadastro Cadastrar livro 1 2 3 4 5......... Atendente Movimentação / Circulação Emprestar exemplar 1 2 3 4 5 Consultar histórico de empréstimos de usuário 1 2 3 4 5 Devolver exemplar 1 2 3 4 5 Emitir aviso de devolução em atraso 1 4 Reno empréstimo 2 3 4 Reser obra 1 2 3 4 5 Cancelar reserva de obra 1 2 3 4 5 Consultar reserva 2 3 4 5 Emitir multa 1 2 3 4 5 Cancelar multa 1 2 3 4 5 Ler código de barras 1 2 3 4 5 Tabela 2 - Módulos e funções dos sistemas Os módulos que comporão o padrão arquitetural devem ser separados nessa tabela. Cada módulo deve conter as funcionalidades que lhe forem concernentes. Esse processo de análise, separação dos módulos e composição desta tabela única permite ainda a definição dos atores do padrão arquitetural. Os atores do padrão são definidos através da análise dos atores de cada sistema. Identificar atores e casos de uso genéricos (iantes, cionais e múltiplos) As funcionalidades descritas na Tabela 2 são transformadas nos casos de uso do Padrão Arquitetural. Assim cada funcionalidade torna-se um caso de uso. A análise dos casos de uso Opcionais é feita diretamente visualizando-se a Tabela 2. Os casos de uso implementados por todos os sistemas analisados são fortes candidatos a fazerem parte do núcleo do padrão arquitetural e, conseqüentemente, serem comuns (não cionais) a todos os sistemas. Os demais casos de uso, implementados por parte dos sistemas, são fortes candidatos a serem casos de uso cionais. Nas duas situações citadas, o projetista com sua experiência e vislumbrando alguma situação que requeira julgamento diferenciado poderá tomar a decisão. Cada caso de uso Variante é analisado à parte nos diferentes sistemas que o implementa, procurando-se por similaridades e diferenças que possam ou não caracterizar esse caso de uso como iante. Para essa tarefa usa-se a relação de equivalência funcional [10], através da qual se pode verificar as similaridades entre as funcionalidades dos sistemas analisados. Os casos de uso Múltiplos são elicitados procurando-se evidenciá-los a partir da observação das funcionalidades de cada sistema que os implementam.
Nesse processo de análise procura-se, ainda, identificar os atores genéricos concernentes aos vários casos de uso. Esses atores são identificados através da observação dos atores da cada sistema e o seu comportamento. A Figura 3a mostra um Modelo de Casos de Uso Genérico construído usando a extensão. Análise das Arquiteturas Analisar os diagramas de classes dos sistemas Caso existam, os diagramas de classes dos sistemas deverão ser analisados para a identificação de suas partes na composição do diagrama de classes do padrão arquitetural. Caso não existam esses diagramas de classes dos sistemas, pode-se efetuar um processo de engenharia reversa para cada sistema para extrair os modelos de classes correspondentes de cada sistema. Reser obra Cancelar reserva de obra Bibliotecário CIBibliotecário CCPagar- Multa CIImpressora Impressora InformeValorMulta() ValorMulta Atendente Consultar histórico de empréstimos de usuário Consultar reserva Reno empréstimo Emitir aviso de devolução em atraso Cancelar multa Emprestar exemplar Devolver exemplar Ler código de barras Emitir multa sgbd LeitorOtico SistemaEmail Impressora InformeFormaPagto() JanFormaPagto b) Diagrama de Seqüência evidenciando parte cional e iante FormaPagto FormaPagto ImprimeRecibo() Recibo Mostrando Janela Valor Multa /^CIBibliotecário.Inf ormarvalormulta Mostrando Janela Forma Pagto /^CIBibliotecário.Inf ormarformapagto a) Modelo Genérico de Casos de Uso Imprimindo Recibo c) Diagrama de Estados evidenciando parte cional e iante Figura 3 Diagramas genéricos do padrão arquitetural Desenvolver o diagrama de classes do padrão Nesta fase deverá ser composto o diagrama de classes do padrão arquitetural. Esse diagrama será sintetizado dos diagramas de classes de cada sistema analisado na fase anterior. Esta síntese é baseada em uma análise de equivalência das classes que é composta, basicamente, por quatro passos: 1) Levantamento das classes para cada caso de uso; 2) Definir uma tipologia para as classes baseada nos estereótipos (Controle, Interface e Entidade);
3) Para cada ator genérico criar uma classe de equivalência para os estereótipos da tipologia do passo 2; 4) Fazer a unificação ou integração das classes de equivalência para criar as classes genéricas do padrão. Desenvolver os diagramas de seqüência Os diagramas de seqüência para as partes comuns do padrão são desenvolvidos da maneira convencional, utilizando-se os recursos oferecidos pela UML. Já os diagramas de seqüência que representam partes cionais, iantes e múltiplas devem explicitar essas partes colocando nelas um retângulo para delimitá-la da parte comum, como o exemplo da Figura 3b. Desenvolver os diagramas de estados De maneira análoga aos diagramas de seqüência, os diagramas de estado são criados usando-se as convenções da UML. Para se descrever as partes genéricas usa-se um retângulo que evidencia essas partes, como ilustrado na Figura 3c. Desenvolver o diagrama de componentes O padrão arquitetural não deve ser construído como uma única peça. Constroem-se componentes que serão as partes do padrão. Esses componentes são definidos pelo projetista do padrão através da análise dos documentos obtidos dos sistemas que compõem o domínio e também da análise das tabelas e diagramas que compõem a descrição do padrão. Como um exemplo tem-se que, através da análise da Tabela 2 e demais diagramas, pode-se particionar o módulo de movimentação em quatro componentes como descrito na Figura 4a. Esta figura evidencia ainda os componentes cionais através da sigla OP colocada antes dos nomes dos componentes cionais. Este trabalho de criação dos componentes exige uma minuciosa análise, por parte do projetista, para identificar as funcionalidades que possuem características comuns para colocálas em um mesmo módulo. O conhecimento do domínio é importante nessa etapa. Multa + Cancelar multa + OP Emitir aviso de devolução em atraso + Emitir multa Servidor BD BD Sist Biblioteca Servidor Impressão Impressora Empréstimo Servidor de Aplicação + Consultar histórico de empréstimos de usuário + Devolver exemplar + Emprestar exemplar + OP Reno empréstimo Servidor WEB TCP/IP Sist Biblioteca Reserva + Cancelar reserva de obra + OP Consultar reserva + Reser obra CódigoDeBarras + Ler código de barras Navegador: Usuário «executable» Sistema de Biblioteca a) Diagrama de componentes b) Diagrama de Distribuição Figura 4 Diagramas de componentes e distribuição do padrão
Desenvolver o diagrama de distribuição O diagrama de distribuição é usado para definir a arquitetura de execução dos sistemas que forem instanciados do padrão arquitetural. Este diagrama apresenta a distribuição dos sistemas computacionais, instanciados do padrão arquitetural, dentro do ambiente de execução, representando dispositivos de hardware ou ambientes de execução de software. A Figura 4b mostra um exemplo aplicável para um sistema que é desenvolvido para WEB. 5. Conclusão e Contribuição Tendo em vista que os padrões de software são considerados como meios de reuso que possibilitam a produção de software em grande escala (produção industrial), pode-se concluir que os sistemas computacionais produzidos a partir de padrões de arquitetura de software tendem a ter maior facilidade de manutenção e evolução pois são baseados em arquiteturas desenvolvidas com maior consciência do domínio de aplicação no qual se inserem. Este trabalho apresenta uma contribuição para a busca, através da engenharia reversa, de informações importantes que contribuam para a construção de padrões de arquitetura de software com vistas ao reuso. O processo resumidamente apresentado nesse artigo tem por objetivo a produção de padrões de arquitetura de software a partir da engenharia reversa executada sobre um conjunto representativo de sistemas de um domínio de aplicação. Busca-se neste processo a elicitação das funcionalidades para a descrição dos requisitos genéricos que comporão o padrão arquitetural, bem como a criação dos componentes arquiteturais do padrão. Os padrões arquiteturais identificados com o processo poderão ser reutilizados em larga escala na composição de novos sistemas computacionais. A documentação obtida a partir do processo de engenharia reversa pode também ser utilizada para a manutenção dos sistemas do domínio analisado. 6. Referências [1] B. Appleton. Patterns and Software: Essential Concepts and Terminology. In: http://www.cmcrossroads.com/bradapp/docs/patterns-intro.html. Data de acesso: 07/06/2000. [2] E. V. Berard. Essays in Object-Oriented Software Engineering. Vol 1. Prentice Hall, 1992. [3] J. Foreman. Product Line Based Software Develment- Significant Results, Future Challenges. Software Technology Conference, Salt Lake City, UT, Abril, 1996. [4] I. Jacobson, M. Griss e P. Jonsson. Software Reuse: Architecture, process and Organization for Business Success. Addison Wesley Longman. 1997. [5] R. S. Pressman. Software Engineering: A Practitioner's Approach. McGraw-Hill 6 edition, 2004. [6] R. Prieto-Díaz. Domain Analysis: An Introduction. Software Engineering Notes 15, 2. Abril 1990. [7] M. A. Quináia e P. C. Stadzisz. A Use Case Extension for Architectural Patterns. In: CSITeA 03, Rio de Janeiro, 2003. [8] M. Z. Roseti e C. M. L. Werner. Aquisição de Conhecimento no Contexto de Análise de Domínio. In: SBES'99, Florianópolis, 1999. [9] J. Rumbaugh, I. Jacobson e G. Booch. Unified Modeling Language Reference Manual. Addison-Wesley. 1998. [10] P. C. Stadzisz. Contribuition à une Méthodologie de Conception Intégrée des Familles de Produits pour l Assemblage. L Universite de Franche-Comte. (Tese doutorado). 1997.