Resumo
Entre diversas metodologias e práticas de desenvolvimento de software existentes no mercado atual, muitas soluções e padrões de projeto não proporcionam o desenvolvimento rápido para sistemas complexos. Entretanto a componentização de software juntamente com bons padrões de projeto proporcionam uma solução capaz de gerenciar problemas complexos ligados ao reaproveitamento, não somente de código, mas também de funcionalidades e interfaces, independentemente de tecnologias ou plataformas, reduzindo tempo e recursos financeiros. Este trabalho sugere o uso de padrões de projetos relacionados com a engenharia de componentes para a criação de um sistema de academia de musculação, destacando as vantagens de tais metodologias e seu relacionamento com a capacidade do sistema crescer e evoluir com facilidade, através do uso destes processos.
1. Introdução
No ambiente de desenvolvimento de software, uma questão muito discutida é a produtividade. Os sistemas estão a cada dia mais complexos e muitos padrões de desenvolvimento ou gerenciamento de processos não atendem às expectativas da forma desejada. Com o desenvolvimento baseado em componentes, surge o conceito de "crie uma vez, use onde quiser". Desse modo é possível montar sistemas utilizando componentes já implementados, não sendo necessário escrever uma nova aplicação codificando linha após linha.
Para a implementação de componentes de software é necessário o forte uso de padrões em todo processo de desenvolvimento. Consequentemente há uma série de vantagens ao utilizar tais padrões, mencionado por Alur (2002) como sendo reutilizáveis, pois fornecem uma solução pronta que pode ser adaptada para diferentes problemas quando necessário. Os padrões refletem a experiência e conhecimento dos desenvolvedores que utilizaram estes padrões com sucesso em seu trabalho, formado um vocabulário comum para expressar grandes soluções sucintamente. Além de reduzir o tempo de aprendizado de uma determinada biblioteca de classes, também diminuem o retrabalho, pois quanto mais cedo são usados, menor será o retrabalho em etapas mais avançadas do projeto.
Este trabalho apresenta uma abordagem sobre alguns padrões de projetos associados ao conceito de software componentizado, que são capazes de proporcionar o desenvolvimento de software de forma rápida, resultando em aplicações capazes de crescerem e evoluírem com facilidade. Para aplicação destes padrões será utilizado o ambiente de uma academia de musculação onde o resultado final será um sistema que deverá ser utilizados tanto no ambiente WEB como desktop e com diversos tipos de persistência de dados.
2. Engenharia de Componentes e Padrões de Projeto
Segundo Friedrich Ludwig Bauer (1969, p. 231), "Engenharia de Software é a criação e a utilização de sólidos princípios de engenharia a fim de obter software de maneira econômica, que seja confiável e que trabalhe eficientemente em máquinas reais".
Outra definição para o conceito de engenharia de software é apresentada por Sommerville (2007) como uma disciplina de engenharia relacionada com todos os aspectos de produção de software, desde os estágios iniciais de especificação do sistema até a sua manutenção, ou seja, mesmo depois que este entrar em operação. Isso revela a importância da engenharia de software dentro de todo o projeto e sua forte ligação com o resultado final do produto.
Já a engenharia de software baseada em componentes (component-based software engineering, CBSE) é um processo que enfatiza o projeto e a construção de sistemas baseados em computador usando "componentes" de software reutilizáveis (PRESMMAN, 2002). A Engenharia de componentes é uma derivação da engenharia de software, focada na decomposição dos sistemas, em componentes funcionais e lógicos com interfaces bem definidas, usadas para comunicação entre os próprios componentes, que estão em um nível mais elevado de abstração do que os objetos, com isso a comunicação se dá por meio de mensagens.
A prática da tecnologia de software baseado em componentes, baseia-se no desenvolvimento através de componentes reutilizáveis, levando a redução de tempo de desenvolvimento, e facilitando as mudanças e a implantação de novas funcionalidades. Dessa forma, o processo de engenharia de software baseada em componentes tem mudado o modo pelo qual sistemas são desenvolvidos, pois desloca a ênfase da programação do software para a composição de sistema de software com base em componentes (PRESMMAN, 2002).
A engenharia baseada em componentes possui as etapas de coleta de requisitos e passa por um projeto arquitetural, da mesma forma que a engenharia se software tradicional. Porém a partir desse ponto começa se diferenciar, pois começa a ser analisado os requisitos com objetivo de buscar módulos que sejam mais adequados à composição, ao invés de iniciar a construção e partir para tarefas de projeto mais detalhadas.
Ao fazer essa análise dos subconjuntos ou módulos do sistema, pode se fazer o uso de componentes já existentes, sendo componentes próprios ou comerciais. Segundo Desmond D'Sousa (1998) um componente é um pacote coerente de artefatos de software que pode ser desenvolvido independentemente e entregue como unidade e que pode se composto, sem mudança, com outros componentes para construir algo maior.
O Reuso é o objetivo principal da engenharia de software baseada em componentes. Não se trata somente de reutilização de código, pois abrange também os artefatos envolvidos durante o todas as etapas de desenvolvimento.Com isso os riscos são menores ao usar um componente já existente em relação ao desenvolvimento de algo a partir do zero. Também ocorre o aumento da produtividade, tendo em vista a redução de esforços pela equipe de desenvolvimento. Seguindo a idéia “Crie uma vez, use onde quiser”. Por sua vez, a qualidade e confiabilidade do produto são maiores, pois o componente reutilizado já foi testado e aprovado.
Os Padrões de projeto são um grupo de práticas para definir o problema, a solução e em qual situação aplicar esta solução e suas consequências no desenvolvimento de software. Os padrões são desenvolvidos a partir de experiências práticas em projetos reais. É resultado da experiência de arquitetos com experiência, que aplicam usam estes padrões e experimentam o resultado em seus próprios problemas. A experiência desses arquitetos certamente proporciona a abordagem correta para um problema específico, da forma mais indicada.
Fazendo uso de tais padrões, temos como resultado uma qualidade de código, permitindo a reutilização de forma flexível e expansível. Por se tratar de questões que nasceram de um problema real, e a solução foi testada e documentada, os padrões aumentam de forma significativa a produtividade e qualidade, pois a solução já está definida.
3. Design do sistema
A proposta de sistema que será apresentado consiste em gerenciar um ambiente de academia de musculação, sendo de responsabilidade do sistema distribuir rotinas de exercícios conforme o tipo físico de cada aluno, que será determinado após um exame físico. Dessa forma não será necessário gerenciar treinos individuais para cada aluno da academia, pois todo aluno sempre será categorizado em um dos três tipos físicos existentes, sendo eles: ectomorfo (abaixo do peso), mesomorfo (peso ideal) e endomorfo (acima do peso).
Este sistema deverá ser independente de sistema operacional e poderá operar tanto em um ambiente desktop quanto web. Para isso é sugerido a utilização da tecnologia Java que além de suprir estes requisitos com facilidade, é uma tecnologia muito relevante no mercado atual. O sistema também deve permitir formas diferentes de persistência dos dados definidos em tempo de execução, podendo variar entre JPA, JDBC, EJB ou até mesmo persistência em memória. Através desses requisitos será abordada uma estrutura capaz de solucionar tais solicitações, fazendo o uso de alguns padrões de arquitetura, comportamentais, estruturais e criacionais.
A seguir será representado um diagrama de classe com a proposta de modelagem para este ambiente. Através do diagrama representado a seguir pela figura 1, consta uma entidade chamada pessoa, que foi criada após verificar semelhanças entre atributos de aluno e instrutor. Dessa forma a classe pode ser estendida pelo conceito de herança por demais entidades que caracterizam uma pessoa, que por ventura venham ser criadas, como por exemplo: funcionário ou usuário. Assim será aplicado o reaproveitamento da estrutura já existente.
O exame físico necessita de um aluno e um instrutor, e nele constam as medidas do aluno no momento do exame. Ao inserir um exame no sistema, automaticamente será analisado qual o tipo físico da pessoa, através de um cálculo simples de IMC (Índice de Massa Corporal). Com base neste cálculo o aluno receberá um programa específico para seu perfil em tempo de execução, através do conceito de interface.
Figura 1: Diagrama de classes
No diagrama acima, percebe-se que um programa é na verdade uma interface usada pelos três tipos físicos (ectomorfo, mesomorfo e endomorfo). O programa pode ter um ou mais treinos, que por sua vez possuem um ou mais exercícios. Cada exercício está vinculado com um tipo de exercício. Para uma melhor compreensão do programa, uma pessoa pode ser direcionada para o programa ectomorfo quando estiver abaixo do peso, mesomorfo quando estiver na média de peso, e endomorfo quando estiver acima do peso. Baseado neste escopo é possível à implementação dos padrões comportamentais Observer e Strategy, que serão descritos em maiores detalhes no capítulo seguinte.
Através do diagrama de pacote representado a seguir pela figura 2, pode-se observar o uso do modelo em camadas. Através deste modelo é possível modularizar o código proporcionando o reaproveitamento tanto na aplicação web como desktop. Dessa forma as regras de negócio e persistência dos dados não sofreram nenhuma alteração de um projeto para outro.
Figura 2: Diagrama de Classes e Pacotes
Na camada de Visão está presente um pacote “GUI” representando a interface do usuário, e um pacote “CTR” como controlador dessa interface e responsável pela comunicação com as demais camadas. Já na camada de negócio consta um pacote “DMP” utilizada para transporte dos obejtos e o pacote “BO”, contendo as regras desses objetos.
O controlador da camada de visão tem acesso a qualquer classe do pacote “BD”, mas as classes do pacote “DMP” não são acessadas diretamente, pois é somente o “DMP” que deve gerenciar os objetos de transporte. A camada de persistência é acessada por qualquer classe do pacote “BO”, porém, estes só terão acesso a “AcademiaPST” que é responsável por controlar toda a persistência. Esta acessa a factory de cada objeto para persistência pelo pacote “PST” (persistência utilizando JPA ou JDBC) ou pelo pacote “PSTEntity” (persistência utilizando EJB).
O pacote “PST” tem a comunicação estabelecida pelo “DatabasePersistenceFactory”. Da mesma forma, o pacote “PSTEntity” é acessado pelo “EntityPersistenceFactory”, que possui acesso a todas as entidades de persistência utilizando EJB.
4. Padrões Comportamentais, Estruturais e Criacionais
Os padrões de projetos descritos pelo GoF (Gang of Four) podem ser categorizados em três tipos: Criacionais (criar uma coleção de objetos de maneira flexível ou restrita), Estruturais (representar uma coleção de objetos relacionados), Comportamentais (captar comportamento em uma coleção de objetos).
Dentro dos padrões criacionais estão o Factory, Abstract Factory, Prototype, Builder e Singleton. Nos Estruturais são encontrados os padrões Adapter, Bridge, Composite, Decorator, Façade, Flyweight e Proxy. Por último, os padrões comportamentais: Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method, Visitor.
Alguns destes padrões podem ser aplicados em determinadas áreas deste sistema. A seguir será descrito os padrões mais relevantes para serem utilizados no projeto, sendo o Factory como criacional, Façade representando os estruturais, e o Strategy e Observer, ambos padrões comportamentais.
O padrão Observer pode ser inserido na implementação da Inserção de Exame Físico. O Observer teria a função de notificar um programa, para que seja processado e identificado qual o programa que melhor se encaixa na situação atual do aluno (mesomorfo, ectomorfo e endomorfo). Este processamento deve ocorrer dentro da camada de negócios do programa, fazendo uso do padrão Strategy. Conforme o IMC (Índice de massa corporal) do aluno, deverá ser instanciado em tempo de execução o programa que o aluno vai utilizar.
Já os padrões Façade e Factory podem ser aplicados na camada de persistência. Qualquer operação de persistência (Inserir, buscar, excluir e alterar) é solicitada a uma fachada para uma classe responsável por gerenciar a persistência de dados. Nesta classe deve existir uma factory de conexões, permitindo a conexão com EJB, JDBC ou JPA, sem a necessidade de implementações a parte. Ao instanciar a classe de exame físico, seu próprio construtor irá invocar a fachada de persistência com uma instancia da classe gerenciadora de persistência. Nesta classe a factory de conexões permite o uso de JDBC, EJB ou JPA, conforme o parâmetro recebido em seu construtor. Ou seja, em tempo de execução esta classe é capaz de gerenciar conexões distintas usando a mesma entidade. Através desse padrão utilizado, a persistência permanece encapsulada, sem a necessidade de alterações em outras entidades devido a troca do tipo de conexão da persistência.
5. Padrões Arquiteturais
A sugestão de padrão arquitetural para ser aplicado neste sistema é o MVC (Model View Controller). O conceito de dividir uma aplicação em camadas está bastante difundido entre os profissionais que trabalham no desenvolvimento de software. Basicamente as camadas do MVC estão separadas em: apresentação, lógica da aplicação e gestão dos recursos.
Aplicando o padrão MVC, a camada de apresentação pode ser dividida em tratamento e exibição, mas o mais importante é a separação entre apresentação e lógica da aplicação. No projeto a ser implementado, essa arquitetura é aplicada da seguinte maneira: A camada de modelo poder ser implementada por um projeto utilizando EJB e no pacote “presentation” (representado pelo diagrama de classes e pacotes no capítulo 3) seriam as camadas de visão e controle, cada um em seu respectivo pacote: “CTR” e “GUI”.
O fluxo entre as acamadas do MVC ocorre no seguinte sentido: Primeiramente o usuário interage com a interface do usuário de alguma maneira (por exemplo, o usuário aperta um botão). O Controlador manipula o evento de entrada da interface do usuário e em seguida acessa o modelo, possivelmente atualizando-o em uma forma adequada de ação do usuário. Por sua vez, a visão usa o modelo para gerar uma interface apropriada. A visão obtém seus próprios dados do modelo, mas o modelo não tem conhecimento direto da visão. Finalmente a interface do usuário aguarda interações do usuário adicionais, que começa o ciclo novamente.
Segundo ALUR (2002) para a construção de aplicações baseadas no MVC, existe uma série de padrões associados a este modelo, como por exemplo:
- Front Controller: Um módulo que atua como o ponto de entrada centralizada em um aplicativo Web, gerenciamento de processamento de solicitação, autenticação e executar os serviços de autorização e, finalmente, selecionar a visualização adequada.
- Data Access Object (DAO): Um mecanismo centralizado para abstrair e encapsular acesso a fontes de dados complexos, incluindo bancos de dados relacionais, LDA diretórios e objetos de negócio CORBA. O DAO funciona como um adaptador, que permite a interface externa permaneça constante, mesmo quando a estrutura das fontes de alterações de dados subjacentes.
- Service to Worker e Dispatcher View: Estratégias para a aplicação MVC onde o módulo controlador adia o processamento para um distribuidor que é selecionado com base no contexto da solicitação. No padrão Dispatcher View, o despachante realiza o processamento estático para selecionar a visualização de uma apresentação final. Já no padrão de Service to Worker, o processamento de despachante é mais dinâmico, traduzindo os nomes de função lógica em referências do módulo, permitindo que as tarefas executem um processamento complexo que determina o modo de exibição da apresentação final.
- Value List Handler: Um mecanismo de cache de resultados de consultas de banco de dados, apresentando subconjuntos desses resultados e fornecendo passagem iterativa através da sequência de subconjuntos.
- Intercepting Filter: Permite que filtros conectáveis sejam inseridos num "pipeline de solicitação" para o processamento por formulário anteriores ou posteriores a solicitações de entrada ou de saída. Esses filtros podem realizar serviços comuns necessários para a totalidade ou a maioria das tarefas do aplicativo, incluindo autenticação e log.
6. Considerações Finais e Trabalhos Futuros
Este trabalho apresenta uma proposta de desenvolvimento de software para uma academia de musculação, fazendo uso das características da engenharia de componentes e alguns dos padrões disponíveis nesse ambiente.
Os resultados descritos neste artigo confirmam os benefícios sobre a utilização da componentização de software, que frequentemente é destacado por grandes nomes da engenharia de software, como Sommerville (2007, p. 56), “uma das seis melhores práticas de engenharia de software recomendadas pelo RUP (Rational Unified Process) é o uso de arquiteturas baseadas em componentes, justamente por envolver uma abordagem orientada a reuso”.
Em trabalhos futuros, através da análise dos procedimentos aqui descritos, é possível a aplicação de novos padrões nas áreas que não foram abordadas neste trabalho, como o controle financeiro, controle presencial, identificação de alunos e professores, entre outras atividades de uma academia de musculação. Dessa forma seria ampliado o escopo do sistema e consequentemente outros padrões seriam agregados, valorizando ainda mais a arquitetura do projeto apresentado.
Referências Bibliográficas
- ALUR, Deepak; CRUPI, John; MALKS, Dan. “Core j2ee patterns: as melhores práticas e estratégias de design”. Rio de Janeiro: Campus, 2002.
- DEBU PANDA, REZA RAHMAN, DEREK LANE. “EJB3 em ação”. Alta Books, 2008.
- DESMOND D'Sousa. “Objects, Components, and Frameworks with UML: The Catalysis Approach”.1998.
- GONÇALVES, Edson. “Desenvolvendo aplicações web com jsp, servlets, javaserver faces, hibernate, ejb3 persistence e AJAX”. Editora Ciência Moderna: Rio de Janeiro, 2007.
- KOCH, Nora. “A UML-based Methodology for Hypermedia Design”. England. Out 2000.
- HORSTMANN, Cay S. “Core Java 2 - Vol.1:Fundamentos”.Editora Makron Books: São Paulo SP, 2000.
- MARINESCU, Floyd. “EJB design patterns: advanced patterns, processes, and idioms”. New York: John Wiley & Sons, 2002.
- MELO, Ana Cristina. “Desenvolvendo aplicações com UML 2.0: do conceitual à implementação - 2.ed”. Brasport. Rio de Janeiro, 2004.
- NATO Science Committee, Garmisch, Germany. Friedrich Ludwig BAUER. 7-11 Oct. 1968, Brussels, Scientific Affairs Division, NATO (1969) 231p.
- PRESSMAN, ROGER S. “Engenharia de Software. 5ª Ed”. Rio de Janeiro: McGraw- Hill, 2002.
- RUBIRA, Cecília Mary Fischer. “Desenvolvimento Baseado em Componentes e o Processo UML Components”. Unicamp. 2008. Acesso em 07 set. 2010.
- SOMMERVILLE, Ian. “Engenharia de Software.8.ed”. São Paulo. Pearson Addison-Wesley, 2007.
- SUN, Sun Microsystems. “Designing enterprise applications with the j2ee platform enterprise edition”. Acesso em: 28 out. 2010.
