Revista Perspectiva Amazônica
Ano 3 N° 5 p.109-118
ARQUITETURA EM CAMADAS: REUTILIZAÇÃO E ADAPTAÇÃO DE
COMPONENTES DE SOFTWARE NO DESENVOLVIMENTO DE UM SISTEMA
PARA GERENCIAR ATIVOS DE REDE
Luciano Parintins Viana¹, Rafael Brelaz², Antônio Fabrício
Guimarães de Sousa³, Amanda Monteiro Sizo Lino4
RESUMO
Este artigo descreve o processo de desenvolvimento de um sistema de controle de ativos de redes, o
SIAR, e como a reutilização de uma arquitetura de software consolidada interferiu na qualidade do
produto final. Como importante contribuição, o artigo apresenta uma análise a cerca das vantagens e
desvantagens alcançadas com a adaptação da Arquitetura da UFRN para a construção do sistema
citado.
ABSTRACT
This paper describes the process of developing a control system for active networks, the SIAR,
and as reuse of a software architecture consolidated interfered in final product quality. As major
contribution, the paper presents an analysis about the advantages and disadvantages achieved
with the adaptation of Architecture UFRN for the construction of system.
¹ Centro de Tecnologia da Informação e Comunicação (CTIC) – Universidade Federal do Oeste do Pará (UFOPA) Santarém – PA – Brasil; ² Centro de
Tecnologia da Informação e Comunicação (CTIC) – Universidade Federal do Oeste do Pará (UFOPA) Santarém – PA – Brasil; ³ Centro de Tecnologia da
Informação e Comunicação (CTIC) – Universidade Federal do Oeste do Pará (UFOPA) Santarém – PA – Brasil; 4 Centro de Tecnologia da Informação e
Comunicação (CTIC) – Universidade Federal do Oeste do Pará (UFOPA) Santarém – PA – Brasil.
109
Revista Perspectiva Amazônica
Ano 3 N° 5 p.109-118
I. Introdução
A reutilização de componentes (JACOBSON et al., 1997) tem sido tema de
crescente pesquisa como uma alternativa para as organizações reduzirem tempo e
custos envolvidos no processo de desenvolvimento de software. Nesse contexto,
diversas abordagens que tratam do reuso têm sido definidas como: Arquitetura de
Software (SHAW AND DARLAN, 1996), Middleware (DASHOFY, 1998),
Padrões de Projeto (GAMMA et al., 2000) e Desenvolvimento Baseado em
Componentes (ALVES, 2001), etc. Dentre essas abordagens a reutilização da
Arquitetura de Software merece atenção, pois permite reuso em níveis que vão
desde o estilo arquitetural até o padrão de projeto adotado.
De acordo com Vasconcelos (2004), a capacidade de reutilização vem
representando um fator de qualidade cada vez mais requerido em artefatos de
software, a fim de atender a construção de sistemas grandes e complexos,
compatíveis com as atuais exigências do mercado consumidor. Nesse contexto,
várias arquiteturas de software como Tiboni (2009) e Pinhão (2012) consolidaramse no meio acadêmico e corporativo e estão sendo largamente reutilizadas como
forma de atingir uma qualidade satisfatória no produto final.
Com essa visão, a UFOPA (Universidade Federal do Oeste do Pará) optou
por utilizar a arquitetura da UFRN (Universidade Federal do Rio Grande do Norte),
com algumas adaptações, para desenvolver um sistema de maneira rápida e segura
além de propiciar o estudo da arquitetura para melhor entendimento dos sistemas da
UFRN adquiridos pela UFOPA. Dessa forma, pretende-se prover interoperabilidade
entre os sistemas desenvolvidos na universidade e os demais sistemas
implementados nas instituições cooperadas, atendendo assim os requisitos de
interoperabilidade sugerida pelo governo federal, em e-PING (CEGE, 2012).
Para validar as alterações feitas na arquitetura foi desenvolvido um sistema
de controle de ativos de redes, o SIAR (Sistema de Ativos de Rede). Esse sistema
tem como objetivo gerenciar as informações sobre todos os componentes da rede
(servidores, usuários) e sua localização dentro da instituição, no caso a UFOPA.
Como principal contribuição, esse artigo apresenta uma avaliação
qualitativa sobre a influência na reutilização de uma arquitetura de software na
qualidade do produto final. Na parte final do artigo, os dois últimos tópicos mais
precisamente, são apresentadas algumas considerações em relação as vantagens e
desvantagens encontradas na utilização da arquitetura da UFRN para a criação do
SIAR e o que essa parceria contribuiu em termos profissionais e práticos para os
desenvolvedores que participaram desse processo.
II. Trabalhos correlatos
110
Segundo Simão (2002), a reutilização de módulos preexistentes pode
Revista Perspectiva Amazônica
substituir ou pelo menos, diminuir a atividade de construção desses módulos,
reduzindo o tempo e o custo do desenvolvimento, e aumentando a produtividade e a
qualidade. Essa opinião é compartilhada por muitos autores da área de reutilização,
Ano 3 N° 5 p.109-118
podendo ser encontrada em relatórios de empresas (BAUER, 1993; GRISS, 1994;
JOOS, 1994), “pesquisas informais” (FRAKES; ISODA, 1994) e estudos empíricos
(MORISIO et al., 2002; ROTHENBERGER et al., 2003). Todos esses trabalhos
mostraram que adotar um processo de reutilização pode ser uma maneira efetiva de
se alcançar benefícios na construção de software.
Algumas pesquisas apresentam arquiteturas de software que já são
amplamente reutilizadas, como a plataforma Demoiselle (TIBONE, 2009),
desenvolvido pelo SERPRO (Serviço Federal de Processamento de Dados) que é
uma arquitetura totalmente livre que visa garantir a interoperabilidade e facilidade de
manutenção dos sistemas das diferentes instituições do governo federal. No site da
plataforma Pinhão (PINHÃO, 2012) é descrita a arquitetura de software
desenvolvida na CELEPAR (Companhia de Informática do Paraná) que é composta
por uma metodologia de desenvolvimento baseada nos padrões de mercado e por
várias aplicações que tratam determinadas classes de problemas. Em Xavier (2001)
padrões arquiteturais são selecionados para um domínio comparando-se os atributos
de qualidade desejados no domínio com a probabilidade em se obter estes atributos
por meio da utilização de um determinado padrão arquitetural. Apesar de vasta
pesquisa na área, poucas foram as arquiteturas apresentadas no âmbito de instituições
de ensino, sendo a da UFRN a mais consolidada.
III. Reutilização da arquitetura de software
A Arquitetura de Software reutilizada nessa pesquisa permite abstrair a
complexidade da implementação de sistemas Java Enteprise Edition (JEE), como
também definir padrões de codificação, visualização, navegação para sistemas WEB.
A arquitetura reutilizada neste trabalho utiliza a abordagem de separação em
camadas. O intuito é não misturar as responsabilidades dos componentes dos
sistemas, onde cada componente deve ter suas responsabilidades bem definidas. As
camadas são utilizadas para realizar esta organização, agrupando os componentes
com funcionalidades afins em camadas semelhantes, conforme ilustra a FIGURA 1.
FIGURA 1
Arquitetura em camadas
111
Revista Perspectiva Amazônica
Ano 3 N° 5 p.109-118
As camadas são organizadas em forma de pilhas e obedecem uma hierarquia.
Em geral, as camadas mais acima da hierarquia dependem das camadas mais abaixo.
Apenas as camadas adjacentes podem se comunicar entre si e uma camada inferior
não pode depender de uma camada superior. De acordo com o Wiki ( 2012), cada
camada representa:
1. Apresentação: utilizada para a exibição de informações em janelas ou páginas
HTML. É nela que há a manipulação de requisições do usuário e de requisições
HTTP. Considerando os componentes do desenvolvimento web, podemos listar
Managed Bean, Actions, JSPs, Servlets;
2. Aplicação: delega trabalho da camada de apresentação para a camada de
domínio. Adiciona serviços (transações, por exemplo) ao sistema. Componentes:
Façades, EJB Commands;
3. Domínio/Negócio: representa a lógica de negócio dos sistemas. Componentes:
classes de domínio e processadores (realizam a persistência);
4. Persistência: permite a comunicação com a base de dados, disponibiliza serviços de
mensagens, etc.
Assim, espera-se alcançar a padronização de alguns
processos
e
procedimentos a partir da reutilização de código, pois todas as funcionalidades comuns
encontravam-se na arquitetura, alem do aumento da produtividade dos desenvolvedores
devido à abstração de complexidades e das regras de desenvolvimento.
III.1. Adaptação da arquitetura
Durante a fase de análise da arquitetura da UFRN foi verificado que não haviam
mecanismos que facilitassem a criação de novos módulos usando os componentes
arquiteturais disponíveis. Sendo assim foram necessárias algumas alterações na
arquitetura da UFRN para aproveitar parte de sua estrutura.
Conforme visto na FIGURA 1, a arquitetura da UFRN é composta por 4 (quatro)
camadas separadas de acordo com as responsabilidades definidas para cada uma. Para o
desenvolvimento do SIAR foram feitas algumas alterações visando aproveitar os
componentes da arquitetura do SIG da UFRN e diminuir sua complexidade. A figura 2
apresenta uma visão das camadas da arquitetura da UFRN juntamente com as adaptações
efetuadas na mesma afim de atender o esquema proposto na elaboração do SIAR.
O fluxo proposto na arquitetura da UFRN inicia na camada de Apresentação
onde é utilizado o padrão de projeto MVC (Model, View e Controller) (GLEEN 1988).
O usuário interage com a View e então o Controller faz a comunicação com o Model
para verificar as regras de negócio da aplicação. Na camada de Aplicação o comando é
112
recebido e então faz-se o preparo do movimento para a camada de negócio. O papel de
Controller fica a cargo da classe AbstractController. Essa classe possui funções para
controle de navegação e também de comunicação com a camada de Aplicação. Essa
comunicação é feita utilizando o padrão EJB Command (ALUR, 2003) que se encarrega
Revista Perspectiva Amazônica
de movimentar os comandos entre as camadas da arquitetura.
Ano 3 N° 5 p.109-118
FIGURA 2
Arquitetura adaptada e a Arquitetura do SIGs da UFRN
No modelo proposto para o
SIAR o fluxo da camada de
Apresentação, que é controlado pelos
Managed Beans que extendem a classe
AbstractController, se diferencia da
arquitetura da UFRN, pois ele não
utiliza o padrão EJB Command para
pegar o comando e fazer o movimento
pelas camadas. Desta forma, o SIAR
não utilizou a camada de Aplicação e
foi direto para a camada de
Domínio/Negócio, onde utilizou
apenas os componentes de Domínio já
que a parte do Negócio da arquitetura
da UFRN é encarregada justamente de
receber os comandos da camada de
Aplicação. Da camada de Domínio os
dados vão para a camada de
Persistência onde foram realizadas
algumas customizações nas classes
responsáveis pelos DAOs.
DAO (Data Access Object) é um padrão de projeto criado para fazer o
intermédio entre uma aplicação e uma base de dados, que pode ser de diferentes
origens. Ele encapsula e abstrai todo o acesso ao banco (ORACLE, 2012). Novos
DAO's foram criadas por conta da grande complexidade e da dificuldade em adequar o
código da arquitetura da UFRN à arquitetura do SIAR. Foram criados a classe
SiarGenericDAO e SiarFilter. A função da SiarGenericDAO é permitir a manipulação
dos dados de forma simples, fazendo as operações de salvar, atualizar, deletar e buscar
por determinada informação no banco.
O SiarFilter implementa o padrão OpenSessionInView (HIBERNATE, 2012).
Tivemos que refazer esta classe por conta também da complexidade e da grande
mudança que teríamos que fazer adequando código. Ele cuida em abrir uma Session
do Hibernate (BAUER, 2005) que é a classe responsável pelas transações com o
banco. A cada requisição feita pela página do SIAR é aberta uma Session e ao final da
requisição essa Session é fechada, para que esta sempre esteja disponível para
consultas no banco.
113
Revista Perspectiva Amazônica
Ano 3 N° 5 p.109-118
IV. Sistema de Ativos de Rede (SIAR)
O SIAR foi criado devido a uma demanda da coordenação de serviços do
Centro de Tecnologia da Informação e Comunicação (CTIC) da UFOPA para
gerenciar os ativos de rede da instituição. O contexto de desenvolvimento do
sistema, usando a arquitetura da UFRN, leva em conta a requisição dos clientes que
solicitaram o desenvolvimento do software juntamente com a necessidade da equipe
de desenvolvimento de sistemas da UFOPA em estudar e entender a arquitetura dos
SIGs adquiridos por meio do termo de cooperação com a UFRN, conforme
(DIÁRIO OFICIAL DA UNIÃO, 2010).
O objetivo do SIAR é controlar os ativos de rede da UFOPA armazenando
informações relativas aos servidores, serviços, senhas, bem como a localização
física, associações entre permissões/usuários/servidores, acessos ao sistema,
equipamentos, entre outras. Desta forma os funcionários dos setores de serviços e
rede podem gerenciar melhor seus equipamentos tendo facilmente acesso às
informações como localização, usuários responsáveis, informações adicionais
(como IP, máscara, identificação do tipo de servidor: virtual ou físico) dentre outras,
para administrar de maneira mais eficiente os ativos da Universidade. A FIGURA 3
apresenta a tela principal do SIAR, com os links para as várias funcionalidades do
sistema, onde o usuário tem acesso ao realizar o login.
FIGURA 3
Tela principal do SIAR
A FIGURA 4 é apresenta a página com a listagem dos usuários e algumas
informações como login, senha, tipo de permissão, bem como os acessos e
equipamentos associados a este. No lado direito podem ser vistos os ícones de
alteração, representado pelo item amarelo, e de deletar, caso seja preciso apagar o
registro inserido no SIAR juntamente com suas associações nas tabelas
correspondentes no banco de dados.
114
Revista Perspectiva Amazônica
FIGURA 4
Lista de usuários
Ano 3 N° 5 p.109-118
Vistas as permissões de acesso disponíveis para o usuário, é possível voltar à
tela anterior clicando no link Lista de Usuários próximo ao canto superior esquerdo
da página e então acessar a lista de equipamentos que o usuário em questão pode
gerenciar, administrar ou ter acesso, conforme pode ser visto na FIGURA 6. Neste
caso, o usuário seleciona os equipamentos e em seguida pode clicar no botão com as
setas para esquerda se quiser associar os equipamentos ao usuário, e caso queira
desfazer essa associação basta clicar no botão com setas para direita.
FIGURA 5
Lista de Acessos
V. Resultados
Com o desenvolvimento do SIAR por meio de uma arquitetura de software
consolidada foi possível obter alguns resultados como:
1. Reutilização de componentes: muitas funcionalidades e padrões de projeto
foram aproveitados, o que minimizou as chances de cometer erros em situações onde
já tinham sido encontradas soluções de projeto previamente analisadas;
2. Minimização do tempo gasto no desenvolvimento: devido ao fato de que
não foi necessário começar um sistema e sim partir de um ponto adiante, apenas
entendendo o que foi feito para desenvolver na plataforma já criada;
3. Aprendizado da estrutura arquitetural dos SIGs da UFRN: foi possível
115
Revista Perspectiva Amazônica
Ano 3 N° 5 p.109-118
entender melhor a arquitetura da UFRN e ter conhecimento prático de como
funcionam alguns de seus sub sistemas;
4. Um sistema de ativo de redes com uma base sólida e robusta que poderá ser
incorporado aos SIGs com alguns ajustes.
Em contra partida foram encontradas algumas dificuldades na utilização da
arquitetura, entre elas:
1. Falta de mecanismos apropriados para facilitar a incorporação de módulos aos
SIGs: foi necessário aprofundar as análises nas camadas inferiores para entender o
funcionamento da arquitetura como um todo e ir subindo para fazer alterações nas
camadas posteriores;
2. Análise de extensa documentação: esta dificuldade é decorrente da anterior
devido a ausência de meios para facilitar o uso da arquitetura.
As mudanças realizadas no fluxo entre as camadas foram realizadas para
tentar diminuir a complexidade no caminho dos dados, já que por se tratar de um
sistema relativamente pequeno em relação ao conjunto de funcionalidades
disponível nos SIGs não seria interessante adotar alguns padrões. O uso de padrões
de projeto em sistemas simples muitas vezes acaba por prejudicar o produto final
(GAMMA et al., 2000) ao invés de melhorá-lo, incrementando assim maior
complexidade e etapas desnecessárias.
VI. Considerações finais
A utilização de arquiteturas de software tende a ajudar bastante no
desenvolvimento evitando retrabalho e aproveitando soluções eficientes já
consolidadas e implantadas por meio de padrões de projeto para dar maior robustez
ao sistema. No entanto para que isso seja possível é necessário que a arquitetura
esteja preparada para atender as necessidades de seus usuários de um modo prático e
fácil com simples chamadas e incorporações de propriedades disponíveis, o que não
aconteceu nesta abordagem, visto que a arquitetura da UFRN não foi desenvolvida
com o objetivo de ser amplamente utilizada por outros sistemas e sim para servir de
plataforma para os SIGs que estão incorporados a ela.
O sistema desenvolvido com base na arquitetura da UFRN está em fase de
teste e finalização de algumas funcionalidades como geração de relatório e
gerenciamento de usuários. A experiência no desenvolvimento de software baseado
na arquitetura da UFRN foi interessante do ponto de vista profissional pois ajudou a
compreender melhor os sistemas que a UFOPA utiliza. Do ponto de vista prático, no
entanto, apresentou questões que dificultaram o uso da arquitetura devido ao fato
desta não ter sido criada propriamente para o fim que foi usada no SIAR, ou seja,
servir de base para qualquer sistema e não apenas sub sistemas da UFRN.
116
Revista Perspectiva Amazônica
Ano 3 N° 5 p.109-118
Agradecimentos
Agradecemos ao professor Mestre Enoque Calvino Melo Alves pela
proposta de utilizar a arquitetura da UFRN no desenvolvimento do SIAR para a
UFOPA, pois foi a partir desta que surgiu a ideia de elaborar o trabalho em questão. E
ao Mestre Davi Junio Silva de Oliveira por ter participado na elaboração dos
requisitos do sistema com a criação de diagramas de Banco de dados que ajudaram a
equipe de desenvolvimento do SIAR a entender melhor o problema a ser solucionado
com o software em questão.
Referências
ALUR, D.; CRUPI J.; MALKS D.
2003 Core J2EE Patterns: Best Practices and Design Strategies. Prentice Hall, 2ª Edição.
ALVES, C. E.
2001 Seleção de Produtos de Software Utilizando uma Abordagem Baseada em
Engenharia de Requisitos. Dissertação de Mestrado. Universidade Federal de
Pernambuco, Brasil.
BAUER C.; KING G.
2005 Hibernate In Action, Editora Manning.
BAUER, D.
1993 A reusable parts center. IBM Systems Journal, Vol. 32, n. 04.
CEGE, Executive Committee for Electronic Government
Disponível em:
http://www.governoeletronico.gov.br/o-gov.br/legislacao/portaria-no-05de-14-de julho-de-2005. Acesso em 11 Set. 2012.
DASHOFY, N.; MEDVIDOVIC AND R. TAYLOR
1998 Using Off-The-Shelf Middleware to Implement Connectors in Distributed
Software .
DIÁRIO OFICIAL DA UNIÃO
http://www.in.gov.br/imprensa/visualiza/index.jsp?jornal=3&pagina=80&
data=03/12/2010. Acessado em 27 Set. 2012.
FRAKES,W. B.; ISODA, S.
1994 Success factors of systematic software reuse”. IEEE Software, Vol.11, Nº1.
GAMMA, E.; HELM, R.; JOHNSON, R.; VLISSIDES, J.
2000 Padrões de Projeto: Soluções Reutilizáveis de Software Orientado a Objetos.
GRISS, M.
1994 Software reuse experience at Hewlett-Packard. In: 16th International
Conference on Software Engineering (ICSE). Sorrento, Italy: IEEE/CS Press.
HIBERNATE
Open Session in View: Hibernate Jboss Comunity.
https://community.jboss.org/wiki/OpenSessionInView. Acesso em 28 Set. 2012.
117
Revista Perspectiva Amazônica
Ano 3 N° 5 p.109-118
JACOBSON, M. GRISS AND P. JONSSON
1997 “Software Reuse – Architecture, Process and Organization for Business
Success”, Addison-Wesley.
JOOS R.
1994 Software reuse at Motorola. IEEE Software, Vol.11, n. 05.
ORACLE
Core J2EE Patterns: Data Access Object.
http://www.oracle.com/technetwork/java/dataaccessobject-138824.html.
Acesso em 27 Set. 2012
MORISIO, M.; EZRAN, M.; TULLY, C.
2002 Success and failure factors in software reuse. IEEE Transactions on Software
Engineering, Vol.28, n. 04.
PINHÃO
Sítio Oficial da Plataforma Pinhão Paraná. Disponível em:
http://www.frameworkpinhao.pr.gov.br/modules/conteudo/conteudo.php?
conteudo=5#pfc_CelRUP_arquitetura.pdf. Acesso em 10 Set. 2012
ROTHENBERGER, M. A. et al.
2003 Strategies for software reuse: A principal component analysis of reuse
practices”. IEEE Transactions on Software Engineering, Vol.29, n. 09.
SHAW, M.; D. GARLAN.
1996 Software Architecture: Perspectives on an Emerging Discipline. New Jersey:
Prentice Hall.
SIMÃO, R. P. S.
2002 Características de qualidade para componentes de software. Dissertação
apresentada ao curso de mestrado em informática aplicada da universidade de
Fortaleza.
TIBONI, A. C.; LISBOA, F. G. S.; MOTA, L. C.
2009 Uma plataforma livre para padronização do desenvolvimento de sistemas no
Governo Federal. In: XXIX Congresso da Sociedade Brasileira de Computação, I
Workshop de Computação Aplicada em Governo Eletrônico. Bento Gonçalves/
RS.
VASCONCELOS, A. P. V.
2004 Uma abordagem para recuperação de arquitetura de software visando sua
reutilização em domínios específicos. Exame de Qualificação, COPPE. Rio de
Janeiro: UFRJ.
WIKI
Arquitetura UFRN.
http://info.ufrn.br/wikisistemas/doku.php?id=desenvolvimento:arquitetura
:documentacao_desenvolvimento, Acesso em 05 Set. 2012.
XAVIER, J. R
2001 Criação e instanciação de arquiteturas de software específicas de domínio
no contexto de uma infra-estrutura de reutilização. Dissertação de mestrado do
Programa de Engenharia de Sistemas e Computação. Rio de Janeiro:
COPPE/UFRJ.
118