Uma Abordagem para Integrar Técnicas de Reuso no Processo de Desenvolvimento Tradicional de Software

8PD$ERUGDJHPSDUD,QWHJUDU7pFQLFDVGH5HXVRQR3URFHVVRGH 'HVHQYROYLPHQWR7UDGLFLRQDOGH6RIWZDUH 0DUFR$)0RUDHV$OH[DQGUH0/9DVFRQFHORVH1HOVRQ65RVD Centro de Informática Universidade Federal de Pernambuco Av. Prof. Luiz Freire s/n, Recife PE, Brasil 50732-970 {mafm, amlv, nsr}@cin.ufpe.br

5HVXPR

Sistemas de software estão sendo construídos cada vez mais a partir do reuso de componentes pré-fabricados. Nesse contexto, destacam-se o desenvolvimento baseado em componentes (DBC), uso de PLGGOHZDUH e a adoção de arquitetura de software. Por outro lado, é importante também considerar a implementação (desenvolvimento tradicional) de partes do sistema que não sejam atendidas por tais componentes. Nesse cenário, surgem alguns desafios, tais como, a integração de técnicas de reuso no desenvolvimento tradicional. Para tratar deste aspecto, construímos o IUDPHZRUN ARCADE que integra técnicas de reuso no processo de desenvolvimento tradicional de software. Palavras-Chave: Reuso de Software; Arquitetura de Software; Desenvolvimento Baseado em Componentes; RUP (Rational Unified Process).

 ,QWURGXomR A necessidade de construção de sistemas de software a partir do reuso de componentes pré-fabricados (e.g., COTS [1]) tem aumentado consideravelmente. Nesse contexto, algumas áreas têm envolvido esforços, tais como, desenvolvimento baseado em componentes (DBC) [1,2,5,9], 0LGGOHZDUH [6,15] e Arquitetura de Software [3,4,16]. Por outro lado, deve-se também considerar a possibilidade da implementação (desenvolvimento tradicional) de outras partes do sistema não atendidas pelos componentes pré-fabricados. Neste cenário, surgem alguns problemas. Primeiro, de que forma combinar a necessidade de construção e reuso de componentes no desenvolvimento de software. Segundo, como guiar os desenvolvedores através dos níveis de abstração (requisitos-arquitetura-sistema), tratando aspectos como desenvolver/adquirir. Por fim, como integrar técnicas de reuso ao desenvolvimento tradicional, visando torná-las mais usáveis para os desenvolvedores. Pesquisas existentes têm investigado estes problemas. A etapa de requisitos-arquitetura têm sido tratada em [7], e a etapa arquitetura-sistema em [3,4]. O RUP [10], largamente utilizado pela indústria, fornece guias para tratar os níveis de abstração (requisitos-sistema). Por fim, estudos têm tratado da integração da arquitetura de software com o desenvolvimento tradicional [11]. Considerando estas abordagens, destacamos dois pontos principais. Primeiro, as técnicas de reuso geralmente agem isoladamente, não sendo integradas entre si e nem no processo de desenvolvimento. Finalmente, o RUP envolve todo o ciclo de desenvolvimento, mas tem uma visão de arquitetura diferente das definições tradicionais [3,16]. Neste artigo, apresentamos um IUDPHZRUN baseado em arquitetura de software denominado de ARCADE (6RIWZDUH$UFKLWHFWXUH%DVHG$QDOLV\VDQG'(VLJQ). O ARCADE foi elaborado com o objetivo de contribuir no tratamento dos problemas mencionados acima. Ele possui dois propósitos principais. Primeiro, integrar explicitamente arquitetura de software, DBC e PLGGOHZDUH no processo de desenvolvimento tradicional. Finalmente, combinar abordagens baseadas em arquitetura para auxiliar os desenvolvedores no tratamento dos níveis de abstração requisitos-arquitetura-sistema.

Este artigo está organizado da seguinte forma: Seção 2 apresenta as técnicas de reuso e o processo de desenvolvimento. Seção 3 apresenta o IUDPHZRUN ARCADE. Finalmente, a Seção 4 apresenta as conclusões e alguns trabalhos futuros.

 7pFQLFDVGH5HXVRH3URFHVVRGH'HVHQYROYLPHQWR As seguintes técnicas têm envolvido esforços para tratar do reuso de componentes na construção de software: Desenvolvimento Baseado em Componentes (DBC), 0LGGOHZDUH e Arquitetura de Software. O DBC adota uma estratégia onde o software é construído a partir da aquisição, composição e integração de produtos disponíveis no mercado (e.g., COTS [1]). Tal aspecto é diferente do desenvolvimento tradicional, onde o software é totalmente modelado e implementado. O DBC têm focado principalmente na estrutura, interface, e funcionalidade dos componentes. Por outro lado, um aspecto que tem sido destacado pela emergência da Internet e o aumento da necessidade de distribuição é a interação entre componentes [13].Nesse contexto, a arquitetura de software tem seu papel reconhecido pois destaca tanto a importância dos componentes quanto da forma que eles interagem (conectores). A arquitetura de software enfatiza a separação dos elementos de processamento (componentes) de seus mecanismos de interação (conectores). Neste ponto, destacamos que as tecnologias PLGGOHZDUH (e.g., CORBA [15]) têm sido utilizadas na implementação de conectores. Elas focam na infra-estrutura necessária para permitir que componentes interajam. Vale ressaltar que DBC e PLGGOHZDUH assumem um ambiente homogêneo, no qual todos os componentes aderem a um certo projeto, implementação, empacotamento e restrições de tempo de execução, prescrevendo um determinado tipo de interação. Por outro lado, a arquitetura de software não assume homogeneidade entre componentes e nem restringe os mecanismos de implementação de conectores permitidos. 3URFHVVRGH'HVHQYROYLPHQWRGH6RIWZDUH

Em um Processo de Desenvolvimento Baseado em Arquitetura (PDBA) [3], a arquitetura de software serve como base para as atividades de análise, projeto, implementação e gerenciamento da evolução do software. Aspectos como, foco na arquitetura do software, representação da arquitetura (e.g., ADL [12]) e tratamento explícito de conectores são considerados as principais características do PDBA. Estas características diferenciam o PDBA do desenvolvimento tradicional de software. Por exemplo, o tradicional 5DWLRQDO 8QLILHG 3URFHVV (RUP) trata a arquitetura do sistema de forma diferente ao PDBA. Por outro lado, devemos também considerar as vantagens do desenvolvimento tradicional, tais como, familiaridade entre profissionais da indústria, suporte oferecido por ferramentas disponíveis e uso de padrões (e.g., UML). Assim, uma integração entre o PDBA e o tradicional mostra-se viável, pois resultaria na adição das vantagens inerentes aos dois processos. Para efetuarmos a integração do PDBA com o RUP, comparamos os dois processos para identificar suas diferenças. Nesta comparação, as fases do PDBA foram relacionadas a alguns fluxos do RUP (ver Figura 1). O RUP organiza suas atividades em termos de subfluxos, os quais são usados para estruturar um fluxo (e.g., fluxo de Requisitos). O RUP tem como principais característica o fato de ser dirigido a casos de uso, centrado na arquitetura (esta característica é discutida adiante), iterativo e incremental.

)LJXUD5HODomRHQWUHDV)DVHVGR3'%$HRVIOX[RVGR583

Observamos que o RUP não trata da arquitetura de acordo ao PDBA. Ele considera a arquitetura como um artefato formado principalmente pelos modelos de casos de uso, análise e projeto. Desta forma, identificamos a necessidade da integração da arquitetura de software ao RUP. O fato do RUP adotar uma visão particular da arquitetura favorece a integração, pois ele dedica alguns subfluxos, atividades e passos para tratar a arquitetura.

 $$ERUGDJHP$5&$'( Nesta seção, apresentamos inicialmente as estratégias e decisões envolvidas na construção do IUDPHZRUN ARCADE (6RIWZDUH$UFKLWHFWXUH%DVHG$QDOLV\VDQG'(VLJQ). Em seguida, descrevemos cada subfluxo do IUDPHZRUN, onde identificamos seus propósitos, atividades e principais resultados obtidos.

9LVmR*HUDO

ARCADE é um IUDPHZRUN que integra arquitetura de software e o RUP, definindo como a arquitetura de software deve ser tratada no processo de desenvolvimento. O ARCADE tem como propósito principal assistir ao projeto da arquitetura, focando explicitamente sobre elementos arquiteturais (componentes e conectores). Este IUDPHZRUN adota os principais conceitos do RUP (fases, fluxo, subfluxos, atividades e artefatos), ao mesmo tempo, que preserva também as suas principais características (dirigido a casos de uso, iterativo e incremental). Um aspecto que nos ajudou a identificar os pontos de integração foi o fato do RUP envolver um tratamento de arquitetura, mesmo que diferente do PDBA. Este tratamento é efetuado no fluxo de Análise & Projeto, o qual é estruturado por seis subfluxos (ver Figura 2(a)). Contudo, verificamos que todos subfluxos deveriam ser modificados durante a construção do ARCADE (ver Figura 2(b)), tendo suas atividades elaboradas e definidas com base na arquitetura de software. Para isto, investigamos diversas abordagens que se completassem e atendessem a cada subfluxo do IUDPHZRUN. Uma outra decisão importante foi a combinação de arquitetura de software, DBC e PLGGOHZDUH. Para efetuar essa combinação, verificamos que a arquitetura de software guia o processo de desenvolvimento, dividindo o sistema em componentes e conectores. Os componentes podem ser implementados ou adquiridos (DBC) e os conectores também poderiam ser construídos ou adquiridos (e.g., PLGGOHZDUH). Observando este cenário, elaboramos mais dois subfluxos, um para a seleção de componentes e outro para seleção de conectores. Estes subfluxos tratam todos os fatores que implicam na incorporação de elementos existentes (e.g., custos, necessidade de adaptação).

(a)

(b)

)LJXUDD )OX[RGH$QiOLVHH3URMHWRGR583E )UDPHZRUN$5&$'(

Analisando a Figura 2 destacamos três aspectos principais. Primeiro, a inserção de subfluxos para tratar a arquitetura abstrata e projeto/seleção dos elementos arquiteturais (componentes e conectores). Segundo, a modificação do subfluxo que trata da arquitetura candidata. Finalmente, a remoção dos subfluxo Projetar Componente de Tempo Real e Projetar Banco de Dados que foram envolvidos pelo subfluxo Projetar Componentes. É válido ressaltar que, alguns subfluxos do ARCADE possuem o mesmo nome dos subfluxos do RUP, mas as atividades e diretrizes envolvidas são baseadas na arquitetura de software.

'HVFULomRGRV6XEIOX[RVGR$5&$'(

Nesta seção, apresentamos as estratégias, atividades e resultados obtidos de cada subfluxo do ARCADE. No subfluxo Selecionar uma Arquitetura Candidata, é elaborado um modelo intermediário da arquitetura contendo os componentes e conectores (elementos arquiteturais) do domínio através da abordagem CBSP [7]. Em seguida, relaciona-se esse modelo com estilos arquiteturais [16] para a obtenção de uma arquitetura candidata. As atividades desse subfluxo são: Relacionar o Domínio com a Arquitetura e Identificar Oportunidades de Reuso em Nível Arquitetural. Os principais resultados obtidos são o modelo intermediário, o vocabulário de elementos arquiteturais e as regras de configuração a serem usados. No subfluxo Definir a Arquitetura Abstrata, a etapa inicial é converter o modelo intermediário (produzido no subfluxo anterior) na arquitetura do sistema específico. Nessa conversão, os componentes e conectores do domínio são mapeados no vocabulário do estilo selecionado e depois dispostos através das regras de configuração, produzindo o modelo preliminar (arquitetura abstrata). Em seguida, utiliza-se UML para converter esse modelo preliminar na representação definitiva da arquitetura do software. As atividades desse subfluxo são: Mapear Vocabulário do Domínio sobre a Arquitetura Candidata, Modelar Elementos Arquiteturais, Representar a Arquitetura e Analisar a Arquitetura. Os principais resultados obtidos são a representação e análise da arquitetura abstrata do sistema. No subfluxo Refinar a Arquitetura, a arquitetura abstrata (produzida no subfluxo anterior) é submetida às regras de refinamento [14] para a obtenção de uma arquitetura concreta. Após

o refinamento, deve-se verificar se nenhuma restrição arquitetural foi violada (e.g., inserção de conexões na arquitetura concreta que não existiam na arquitetura abstrata). As atividades desse subfluxo são: Aplicar Regras de Refinamento e Revisar a Arquitetura. O principal resultado obtido é o estabelecimento de uma arquitetura concreta (refinada) que servirá como base para a etapa de realização da arquitetura. No subfluxo Analisar Comportamento, a preocupação é verificar se a funcionalidade inicial não foi alterada na arquitetura refinada. Para isso, construímos um diagrama para cada componente abstrato e um para cada componentes concreto. Em seguida, listamos os estados possíveis dos componentes abstratos e concretos. Caso a listagem dos estados possíveis dos componentes concretos esteja contida na listagem do componente abstrato, então o comportamento da arquitetura global não foi afetado pelo refinamento. As atividades desse subfluxo são: Modelar Comportamento e Analisar Modelo. O principal resultado obtido é a verificação de que as arquiteturas abstrata e concreta possuem o mesmo comportamento. No subfluxo Projetar Componentes, selecionam-se inicialmente os padrões de projeto [8] que forneçam uma solução para o problema no domínio. Em seguida, detalham-se as propriedades das classes (e.g, atributos, visibilidade) e dos casos de uso. Após a definição da estrutura e funcionalidade do componente, utiliza-se a OMG IDL (,QWHUIDFH 'HVFULSWLRQ /DQJXDJH) para especificar sua interface. As atividades desse subfluxo são: Efetuar Projeto Detalhado do Componente, Projetar Classes, Projetar Casos de Uso, Especificar a Interface do Componente e Projetar Componente de Dados. O principal resultado obtido é a especificação e documentação do componente. No subfluxo Selecionar Componentes, usamos o método CRE [1] para auxiliar o processo de seleção. Inicialmente, elabora-se um critério de seleção (e.g., Interface do Componente) e identificam-se os produtos candidatos que atendem a esse critério. Em seguida, os custos associados aos produtos candidatos são avaliados para a obtenção de um UDQNLQJ entre eles. Finalmente, a partir desse UDQNLQJ efetuam-se testes no primeiro colocado para confirmar sua integração ao sistema final. As atividades desse subfluxo são: Identificar, Descrever, Avaliar e Aceitar Produtos Candidatos. O principal resultado obtido é uma lista com os produtos selecionados, indicando qual integrará o sistema final. Caso nenhum produto seja selecionado, sugerimos a execução do subfluxo Projetar Componentes. No subfluxo Projetar Conectores, efetua-se inicialmente a especificação de todos os elementos do conector em nível concreto (e.g., código, infra-estrutura e políticas de uso). Em seguida, consultam-se os tipos básicos [13] para verificar quais deles atendem os elementos especificados. Caso nenhum dos tipos básicos atenda a tais elementos, eles são estendidos [17] para a produção de um novo conector. As atividades desse subfluxo são: Especificar Partes Concretas do Conector e Estender Tipo Básico. O principal resultado obtido é a especificação e documentação do conector. Estes aspectos são importantes para uma implementação correta do conector e para que o conector seja reusado em outros contextos. No subfluxo Selecionar Conectores, ocorre o mapeamento dos conectores em tecnologias PLGGOHZDUH (e.g.,CORBA). Para permitir a seleção de um PLGGOHZDUH adequado, elaboramos uma estratégia baseada em [1]. Inicialmente, identificam-se as tecnologias candidatas que atendam ao critério de seleção (e.g., suporte a múltiplas plataformas). Em seguida, cada tecnologia é avaliada de acordo com os custos envolvidos em sua adoção, obtendo-se assim um UDQNLQJ. Finalmente, o primeiro colocado no UDQNLQJ é testado, caso os resultados não sejam satisfatório, testa-se o segundo colocado, e assim por diante. As atividades desse subfluxo são: Identificar, Descrever, Avaliar e Aceitar Tecnologias Candidatas. O principal resultado obtido é uma lista com um ou mais tecnologias selecionadas, com a indicação da tecnologia PLGGOHZDUH que será integrada ao sistema final. Caso nenhuma tecnologia seja selecionada, sugerimos a execução do subfluxo Projetar Conectores.

 &RQFOXVmRH7UDEDOKRV)XWXURV

Este artigo apresentou o IUDPHZRUN ARCADE (6RIWZDUH $UFKLWHFWXUH%DVHG $QDOLV\V DQG 'HVLJQ) que define como combinar técnicas de reuso no processo de desenvolvimento tradicional, no caso o RUP. O ARCADE possui oito subfluxos: Selecionar uma arquitetura candidata, Definir a arquitetura abstrata, Refinar a arquitetura, Analisar Comportamento, Projetar Componentes, Projetar Conectores, Selecionar Componentes e Selecionar Conectores. Todos esses elementos são introduzidos para tratar explicitamente da arquitetura e dos elementos arquiteturais. Alguns desses subfluxos têm sido testados no projeto do sistema Web SIG@UFPE desenvolvido pelo Núcleo de Tecnologia da Informação (NTI) da Universidade Federal de Pernambuco (UFPE). Tal experimento tem nos permitido efetuar melhorias no ARCADE através da detecção de inconsistências na combinação das técnicas de reuso e da verificação da coerência das atividades e passos de cada subfluxo. As tarefas de determinar como e em que ponto as técnicas de reuso seriam combinadas foram facilitadas pela adoção de uma estratégia baseada em arquitetura. Por outro lado, a integração dessas técnicas no RUP foi trabalhosa em função da maneira diferente de ver a arquitetura no RUP. Logo, tivemos que elaborar e redefinir quase todas as atividades afetadas durante a integração. Esta modificação exigiu muito esforço, pois tivemos que investigar diversas abordagens que se completassem e atendessem a cada subfluxo do ARCADE. Esta integração não envolveu todo o processo de desenvolvimento, sendo assim devem-se examinar outras etapas do processo (e.g., fluxo de Implementação) que podem ter sido afetadas. Adicionalmente, a estrutura de todos os artefatos do ARCADE devem ser revisadas. Esses aspectos servirão de base para o desenvolvimento de pesquisas futuras.

5HIHUrQFLDV

[1]

[2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17]

C. Alves. Seleção de Produtos de Software Utilizando uma Abordagem Baseada em Engenharia de Requisitos. Dissertação de Mestrado. Universidade Federal de Pernambuco, Brasil, Mar, 2001. M.Ayoama. New Age of Software Development: How Component-Based Software Engineering Changes the Way of Software Development. International Workshop on CBSE, Apr.1998. L. Bass, P. Clements and R. Kazman. 6RIWZDUH$UFKLWHFWXUHLQ3UDFWLFHAddison-Wesley, 1998. F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, and M. Stal. 3DWWHUQ2ULHQWHG6RIWZDUH$UFKLWHFWXUH $6\VWHPRI3DWWHUQV. John Wiley and Sons, England, 1996. D. Carney. Assembling Large Systems from COTS Components: Opportunities, Cautions, and Complexities. SEI Monographs, Jun. 1997. E. Dashofy, N. Medvidovic and R. Taylor. Using Off-The-Shelf Middleware to Implement Connectors in Distributed Software Architectures. 1998 A. Egyed, P. Grunbacher, and N. Medvidovic. Refinement and Evolution Issues in Bridging Requirements and Architecture – The CBSP Approach. In 3URF. 675$:, Toronto, Canada, May 14, 2001. E. Gamma, R. Helm, R. Johnson and J. Vlissides. 3DGU}HVGH3URMHWR±6ROXo}HV5HXWLOL]iYHLVGH6RIWZDUH 2ULHQWDGRD2EMHWRV Porto Alegre: Bookman, 2000. G. Haines, D. Carney and J. Foreman. Component-Based Software Development/COTS Integration. Software Engineering Institute, Carnegie Mellon University, USA. Jan. 1997. P. Krutchen. 7KH8QLILHG6RIWZDUH'HYHORSPHQW3URFHVV$Q,QWURGXFWLRQ. Addison Wesley, 1999. N. Medvidovic, D. Rosenblum, J. Robbins and D. Redmiles. Modeling Software Architectures in the Unified Modeling Language. Technical Report. Aug, 2000. N. Medvidovic and R. Taylor. A Classification and Comparison Framework for Architecture Description Languages. ,(((7UDQVDFWLRQVRQ6RIWZDUH(QJLQHHULQJ, Vol 26. Nº 1, Jan, 2000. N. Mehta, N. Medvidovic, and S. Phadke. Towards a Taxonomy of Software Connectors. In 3URF. ,QWHUQDWLRQDO&RQIHUHQFHRQ6RIWZDUH(QJLQHHULQJ (ICSE’2000). M. Moriconi, X. Qian, and R. Riemenschneider. Correct Architecture Refinement. $SSHDUHG LQ ,((( 7UDQVDFWLRQVRQ6RIWZDUH(QJLQHHULQJ, April, 1995, Vol.21, Nº 4, pp. 356-372. R. Orfali, D. Harkey and J. Edwards. 7KH(VVHQWLDO'LVWULEXWHG2EMHFWV6XUYLYDO*XLGH. J.Wiley &Sons,1996. M. Shaw and D. Garlan. 6RIWZDUH$UFKLWHFWXUH3HUVSHFWLYHVRQDQ(PHUJLQJ'LVFLSOLQH. Prentice Hall,1996. B. Spitznagel and D. Garlan. A Compositional Approach for Constructing Connectors. In 3URF RI WKH :RUNLQJ,(((,),3&RQIHUHQFHRQ6RIWZDUH$UFKLWHFWXUH (WICSA’01), 2001.