LUIS FELIPE RONQUI DE SOUZA CONCEITO DE PERSONALIZAÇÃO DE INTERFACE EM NÍVEL DE USUÁRIO UTILIZANDO PADRÕES DE PROJETO ASSIS SP

Transcrição

1 LUIS FELIPE RONQUI DE SOUZA CONCEITO DE PERSONALIZAÇÃO DE INTERFACE EM NÍVEL DE USUÁRIO UTILIZANDO PADRÕES DE PROJETO ASSIS SP 2013

2 LUIS FELIPE RONQUI DE SOUZA CONCEITO DE PERSONALIZAÇÃO DE INTERFACE EM NÍVEL DE USUÁRIO UTILIZANDO PADRÕES DE PROJETO Trabalho de Conclusão de Curso apresentado ao Curso de Bacharelado em Ciência da Computação do Instituto Municipal do Ensino Superior de Assis IMESA e Fundação Educacional do Município de Assis FEMA, como requisito para a obtenção do Certificado de Conclusão. Orientador: Me. Douglas Sanches da Cunha Área de Concentração: Informática ASSIS SP 2013

3 FICHA CATALOGRÁFICA SOUZA, Luis Felipe Ronqui de Conceito de Personalização de Interface em Nível de Usuário Utilizando Padrões de Projeto / Luis Felipe Ronqui de Souza. Fundação Educacional do Município de Assis FEMA Assis, p. Orientador: Prof. Me. Douglas Sanches da Cunha Trabalho de Conclusão de Curso Instituto Municipal de Ensino Superior de Assis IMESA 1. Padrões de Projeto 2. Protótipo 3. Personalização 4. Tempo de Execução CDD: Biblioteca da FEMA

4 DEDICÁTORIA Dedico este trabalho aos meus amigos, professores e familiares que me apoiaram e me incentivaram nessa jornada.

5 AGRADECIMENTOS A minha família por sempre confiar em minha capacidade e incentivar a realizar meus sonhos. A todos os professores da instituição que me ajudaram na construção de minha vida acadêmica, em especial ao meu orientador Douglas Sanches Cunha, que com sua paciência e conhecimento me ajudou a concluir este trabalho. Agradeço a todos os amigos que acreditaram e me apoiaram durante a composição e andamento deste trabalho.

6 RESUMO Os padrões de projeto são técnicas aplicadas no desenvolvimento de software que podem ajudar a ter uma melhor organização e gerenciamento de um sistema, mas que ainda são pouco utilizados devido à dificuldade de sua implantação e conhecimento, perdendo assim certas usabilidades da aplicação tanto para os desenvolvedores quanto para os usuários. Tendo como premissas a utilização dos padrões de projeto e oferecer uma personalização ativa e opcional para o usuário, este trabalho traz os conceitos de usabilidade e aplicabilidade dos padrões, onde foram utilizados para a criação de um protótipo, que oferece em tempo de execução a possibilidade de customização da interface, dando ao cliente final a capacidade de alterar seu layout dinamicamente sem precisar de ajuda externa ou manutenção do sistema. Palavras-Chave: Padrões de projeto, Protótipo, Personalização, Tempo de Execução.

7 ABSTRACT Design patterns are techniques applied in software development that can help you have a better system organization and management, but are still limited due to the difficulty of its implementation and knowledge, thereby losing certain usability of the application for developers such as for users. Having as premises the use of design patterns and providing an optional and active user personalization, this paper presents the concepts of usability and the applicability of the patterns, which were used for the creation of a prototype, which provides in runtime the possibility of interface customization, giving the end user the ability to dynamically change its layout without external assistance or maintenance. Key Words: Design Patterns, Prototype, Personalization, Runtime.

8 LISTA DE TABELAS Tabela 1 - Os tipos de padrões de projeto... 19

9 LISTA DE FIGURAS Figura 1 Tabelas do banco Figura 2 Estrutura do protótipo Figura 3 Tela de Login Figura 4 Cadastro de Usuários Figura 5 Tela Principal Figura 6 Cadastro de usuário padrão Figura 7 Exemplo de Interface Alterada Figura 8 Exemplo de Interface Alterada Fundo Escuro... 46

10 LISTA DE CÓDIGOS Código 1 - Classe conexão modelo padrão Singleton Código 2 - Código Verificação e Carregamento de Estado Código 3 Eventos mousedragged e MouseMoved... 49

11 SUMÁRIO 1 INTRODUÇÃO OBJETIVOS JUSTIFICATIVAS MOTIVAÇÃO PERSPECTIVAS DE CONTRIBUIÇÃO METODOLOGIAS DE PESQUISA PADRÕES DE PROJETO CARACTERÍSTICAS DE UM PADRÃO DE PROJETO CLASSIFICAÇÃO CRIAÇÃO a ABSTRACT FACTORY b BUILDER c FACTORY METHOD d PROTOTYPE e SINGLETON ESTRUTURAL a ADAPTER b BRIDGE c COMPOSITE d DECORATOR e FAÇADE f FLYWEIGHT g PROXY COMPORTAMENTAL a CHAIN OF RESPONSABILITY b COMMAND c INTERPRETER d ITERATOR e MEDIATOR f MEMENTO g OBSERVER h STATE i STRATEGY j TEMPLATE METHOD... 35

12 2.2.3.k VISITOR INTERFACE USABILIDADE DESENVOLVIMENTO DA PROPOSTA O BANCO DE DADOS PROTÓTIPO CICLO DO PROTÓTIPO FUNCIONAMENTO INTERNO DO SISTEMA CONCLUSÃO REFERÊNCIAS... 51

13 13 1 INTRODUÇÃO O padrão de projeto (denominado por outros de design de projeto ) é uma das principais áreas de estudos que consolidou a forma de criação de programas na área da informática, trazendo diferentes modelos que podem e consequentemente devem ser aplicados em diversos protótipos de softwares, fazendo uma base de como podem ser criados e estruturados de acordo com algumas regras simples. Um acréscimo para com estes diversos padrões seria a ideia de que o cliente poderia modificar/alterar o design final do software conforme seu gosto pessoal, mudando a interface de um jeito que seja mais agradável para a sua utilização, contudo, seguindo algumas predefinições inseridas na codificação do projeto, definida por certo padrão de interface adicional. Um padrão de projeto mostra determinada questão já enfrentada diversas vezes em um ambiente, mostrando suas respostas para que possam ser reutilizadas em outros cenários diversos [ALEXANDER, 1978]. Atualmente quando tem-se um projeto de criação de um software e/ou aplicativo, já é decidido ao decorrer dos planos um padrão de projeto que será empregado na construção do software, visando ter uma melhor compreensão e organização do código que o tornará mais fácil de ser trabalhado, prevenindo assim de futuras falhas. A opção de manuseio da interface pelo usuário poderia ser um acréscimo relativamente positivo, podendo gerar uma maior satisfação do cliente final, obviamente, sem alterar a parte fundamental, que é funcionamento e o desempenho da aplicação.

14 OBJETIVOS Este trabalho tem como objetivo pesquisar e idealizar uma proposta que poderá ser agregada aos diversos padrões de projeto atuais, acrescentando uma nova perspectiva além da estruturação e funcionalidade do projeto, mostrando uma maneira diferente de pensar em software, fornecendo ao usuário certa liberdade de alterar a interface do programa. A ideia que será desenvolvida é a de que os projetistas de software tenham em mente, que o cliente poderia ter uma melhor satisfação ao utilizar um software em que seria possível realizar algumas alterações no visual do programa, mudar a aparência como melhor lhe agrada (o usuário), sem ter o conhecimento específico de como isso realmente funcionaria internamente, mas plausível de resultado, o que poderia dar certa comodidade ao usuário em estar utilizando um software que ele ajudou a customizar. 1.2 JUSTIFICATIVAS Os softwares atuais possuem um layout fixo, o que deixa o usuário preso a tal interface durante sua utilização, algo que pode ser desconfortável, pois cada um possui seu gosto pessoal. Fornecer uma alternativa ao que já lhe foi imposto seria dar lhe um poder de deixar o ambiente ao qual está utilizando uma aparência relevante e única, podendo, assim, melhorar a usabilidade de tal aplicação e satisfação do cliente em ter desenvolvido seu próprio visual.

15 MOTIVAÇÃO Elaborar um novo conceito na área de personalização de software, e contribuir para que esta literatura cresça de um modo geral, tendo aspectos positivos e negativos a serem avaliados, gerando novas ideais no mundo da tecnologia, onde consequentemente, busca-se sempre a eficiência do programa e satisfação do cliente. Esta tentativa de introduzir um novo conceito para os desenvolvedores pode levar a uma mudança de atitude relativa, que será percebida na medida em que forem implantados os primeiros programas personalizáveis, algo ainda raramente praticado e pouco utilizado atualmente. 1.4 PERSPECTIVAS DE CONTRIBUIÇÃO Colaborar para uma idealização de uma concepção nos padrões de projeto atuais, visando também à possibilidade de ter uma área de design dentro do próprio software, onde o usuário poderia alterar a interface padrão em tempo de execução e continuar utilizando esta ou retornar ao padrão que lhe é oferecido. Tornar este trabalho futuramente um material de estudo para esta área e discussão sobre o mesmo.

16 METODOLOGIAS DE PESQUISA Serão utilizados livros, informações obtidas em dissertações, livros, teses, internet e artigos envolvendo os atuais padrões de projeto e assuntos relativos da área como usabilidade do sistema e interação do usuário com o sistema, buscando ampliar os conhecimentos sobre padrões de projeto e criação de interfaces.

17 17 2 PADRÕES DE PROJETO Os padrões de projeto nos mostram uma descrição de como resolver e aperfeiçoar determinados problemas que comumente podem acontecer no andamento de um projeto, não significando que teremos uma resposta definitiva para tal impasse. No entanto, temos que estudar e filtrar tais padrões e adaptá-los para que sejam aplicados com sucesso em nossos projetos de softwares. Serão retratados neste trabalho os padrões contidos na obra de referência Design Patterns: Elements of Reusable Object-Oriented Software (Gang of Four ou Gangue dos Quatro), que por sua vez, nos apresenta 23 (vinte e três) padrões de projeto que podem ser utilizados por praticamente qualquer projeto de qualquer linguagem, diferentemente dos padrões complementares apresentados pela Sun, que são focados na utilização da tecnologia J2EE (Java to Enterprise Edition). Dentro desses padrões, temos uma diferente classificação que nos mostra onde cada modelo atua e qual sua maior área de relevância. 2.1 CARACTERÍSTICAS DE UM PADRÃO DE PROJETO Como todo tipo de padrão, existe uma estrutura que nos mostra como é definido e descrito um padrão de projeto, mantendo-se assim uma norma básica do que é essencial saber sobre um determinado padrão. De uma forma resumida, os padrões necessitam no mínimo nos informar: Nome do padrão que seja prático e que faça referência simples ao problema que é aplicado e seu âmbito.

18 18 Problema descrever quando o padrão será aplicado, relatando o problema e seu contexto em si, podendo ter até condições a ser estabelecidas para que possa ser utilizado. Solução mostrar uma visão geral dos elementos que fazem parte da resolução de tal problema, como os relacionamentos, colaborações, responsabilidades (de classes e objetos), mostrando como a organização dos elementos viabiliza a resolução do problema chave. Consequências apresentar os resultados levantados a partir do método utilizado, mostrando também uma análise sobre os pontos positivos e negativos da aplicação. Um padrão de projeto precisa identificar a si mesmo e as características principais de um projeto, constatando seus recursos (classes, instâncias, ações) e assim fornecer onde e quando este pode ou não ser aplicado, mostrando também as restrições que podem ter e suas as consequências (benefícios e malefícios) [GAMMA et al, 2000]. 2.2 CLASSIFICAÇÃO Existem diversos padrões de projeto com diferentes finalidades, alguns possuem uma semelhança em que é visto claramente onde cada padrão está sendo mais objetivamente aplicado. Com base nisso, foram determinados três principais tipos de padrões, para que assim seja mais fácil localizar a sua área de atuação e buscar informações sobre tal [GAMMA et al, 2000]. Como a tabela a seguir demonstra, são divididos os tipos padrões de projetos de acordo com seu propósito e onde exerce sua atividade dentro do escopo.

19 19 PROPÓSITO Criação Estrutura Comportamento E S C O P O CLASSE O B J E T O Factory Method Class Adapter* Interpreter Template Method Builder Object Adapter* Chain of Responsibility Abstract Factory Bridge Command Prototype Composite Iterator Singleton Decorator Mediator Facade Memento Flyweight Observer Proxy State Strategy Visitor Tabela 1 Os tipos de padrões de projetos A Tabela 1 nos mostra todos os padrões de projetos apresentados pela GoF ( Gang of Four, em tradução livre Gangue dos Quatro ) apontando onde é mais aplicado seu escopo (se o foco é mais em classes ou objetos) e seus três grandes nichos: Criação, Estrutura e Comportamento. O padrão Adapter pode ser utilizado tanto para classes como para objetos por isso esta em ambos os escopos. A seguir é apresentada uma breve síntese sobre os tipos de padrões de projeto (Criação, Estrutural e Comportamental) e os padrões que ali estão qualificados, mostrando quando e como devem ser utilizados para que se tenha êxito em suas implementações CRIAÇÃO Os padrões de criação abstraem o processo de instanciação. Um padrão de criação de classe usa a herança para variar a classe que é instanciada, enquanto que um padrão de criação de objeto delegará a instanciação para outro objeto [GAMMA et al, 2000].

20 20 Deixa o sistema mais livre, no sentido de como será feito a criação, composição e representação de seus objetos, tais quais conseguem ter uma estrutura e funcionalidade muito vasta, podendo possuir uma configuração estática ou dinâmica, algo que ajuda e facilita na mudança de classes que definem um componente específico, tornando o projeto mais flexível [FREEMAN et al, 2007] a ABSTRACT FACTORY Segundo Gamma et al [2000], a intenção do Abstract Factory é fornecer uma interface para criação de famílias de objetos relacionados ou dependentes sem especificar suas classes concretas. Abstract Factory nos oferece uma solução de criação de uma classe pai abstrata que fornece a interface para os demais objetos contidos nela que podem ser utilizados durante a execução do programa, havendo então, as classes implementadoras, que por sua vez implementam essa interface mestre, o que pode oferecer diversos comportamentos para diferentes tipos de estilos (aparência ou comportamento dos objetos) que podem ser utilizados, fazendo com que a programação seja para uma interface e não para uma implementação [FREEMAN et al, 2007]. De acordo com o GoF, o padrão Abstract Factory pode ser usado quando: Um sistema deve ser independente de como seus produtos são criados; Um sistema deve ser configurado como um produto de uma família de múltiplos produtos; Uma família de objetos-produto for projetada para ser usada em conjunto, e é necessário garantir esta restrição; Precisa-se fornecer uma biblioteca de classes de produtos e quer revelar somente suas interfaces, não suas

21 21 implementações. (GAMMA et al, Padrões de Projeto Soluções Reutilizáveis de Software Orientado a Objetos. Porto Alegre. Bookman, 2000, p. 97) b BUILDER Um objeto pode ter várias representações para o mesmo método de construção do objeto, onde a criação do objeto pode passar por diversas conversões, gerando assim produtos distintos do objeto [GAMMA et al, 2000]. O padrão Builder trabalha com uma interface de criação abstrata, nos dando o controle da criação de cada parte do objeto (desse modo, saberemos mais detalhes da estrutura interna do produto resultante), tendo assim que simplesmente adicionar novos construtores caso precise de diferentes produtos finais. Segundo Freeman et al (2007) o padrão Builder pode ser aplicado para encapsular a construção de um produto e permitir que ele seja construído em etapas c FACTORY METHOD As subclasses decidem qual classe irá ser utilizada na criação de um objeto em determinada interface [GAMMA et al, 2000]. Este padrão toma como base o cuidado que se deve ter com o operador new na criação de um novo objeto, pois o mesmo apenas cria um novo objeto do tipo solicitado, não encapsulando sua criação.

22 22 O Factory Method pode retornar a mesma instância diversas vezes, ou pode retornar uma subclasse ao invés de um objeto do mesmo tipo, deixando o projeto mais personalizável. De acordo com o GoF, pode-se aplicar o padrão Factory Method quando: Uma classe não pode antecipar a classe de objetos que deve criar; Uma classe quer que suas subclasses especifiquem os objetos que criam; Classes delegam responsabilidade para uma dentre várias subclasses auxiliares, e você quer localizar o conhecimento de qual subclasse auxiliar que é a delegada. (GAMMA et al, Padrões de Projeto Soluções Reutilizáveis de Software Orientado a Objetos. Porto Alegre. Bookman, 2000, p. 113) d PROTOTYPE De acordo com Erich Gamma et al [2000] o padrão Prototype tem a intenção de especificar os tipos de objetos a serem criados usando uma instância protótipo e criar novos objetos pela cópia deste protótipo. O Prototype usa o conceito de criação de protótipos de classes que instanciam e requerem que os objetos/produtos adotantes desse modelo tenham a capacidade de clonagem, o que, dependendo da situação, pode ser difícil realizar a implantação [FREEMAN et al, 2007]. Desse modo, segue uma citação da GoF sobre a aplicabilidade do padrão Prototype. Use o padrão Prototype quando um sistema deve ser independente de como os seus produtos são criados, compostos e representados; e

23 23 Quando as classes a instanciar são especificadas em tempo de execução, por exemplo, por carga dinâmica; ou Para evitar a construção de uma hierarquia de classes de fábricas paralelas à hierarquia de classes de produto; ou Quando as instâncias de uma classe puderem ter uma dentre poucas combinações diferentes de estados [...]. (GAMMA et al, Padrões de Projeto Soluções Reutilizáveis de Software Orientado a Objetos. Porto Alegre. Bookman, 2000, p. 122, grifo do autor) e SINGLETON Focado no controle de acesso a uma determinada classe, onde esta só possua uma instância (salve exceções) e um modo global de acesso à mesma, podendo também permitir um número variável de instâncias, tendo que alterar apenas a operação que dá acesso à instancia para realizar o controle dos acessos, que neste caso são sempre limitados e monitorados [GAMMA et al, 2000]. Pode-se usar o padrão Singleton quando precisar ter apenas uma instância de classe de acesso, sendo esta bem acessível a todo o sistema; e quando precisar estender esta instância sem realizar quaisquer alteração no código dela [GAMMA et al, 2000] ESTRUTURAL Atenta-se à formação dos objetos e classes, como eles são compostos, podendo assim, criar estruturas maiores [GAMMA et al, 2000].

24 24 A herança é utilizada para compor novas interfaces ou implementações de classes (podendo ser até casos de heranças múltiplas, sem problemas), já os padrões estruturais de objetos, nos mostram diferentes métodos de se compor um objeto afim de que esses possam ter novas utilidades (o foco é dado na composição de objetos), que por sua vez tem a capacidade de alterar a composição em tempo de execução, diferentemente das estruturas de classes que são estáticas. Descreve como organizar classes e objetos de um jeito mais simples a ADAPTER O padrão Adapter possui a habilidade de converter uma interface de classe em outra interface, fazendo com que se torne compatível com a interface que será utilizada, tornando assim possível trabalhar com diferentes interfaces [GAMMA et al, 2000]. O adaptador implementa a interface do sistema já existente, realizando algumas alterações para se adaptar a nova classe que irá se comunicar, deixando possível que a classe (antiga) juntamente com o adaptador se encaixe nos requisitos da nova interface, atendendo as solicitações do mesmo [FREEMAN et al, 2007]. Pode-se usar o padrão Adapter quando precisar usar uma classe que possua interface diferente da requerida, bem como ter uma classe que pode trabalhar em conjunto com outras futuras classes de interfaces diversas [GAMMA et al, 2000].

25 b BRIDGE O padrão bridge nos concede uma maneira de mudar coincidentemente tanto a implementação quanto a abstração. Em tempo de execução pode-se alterar a implementação de objetos e abstrações [GAMMA et al, 2000]. Sobre sua aplicabilidade, segundo Freeman et al (2007) o padrão bridge é útil em sistemas gráficos e baseados em janela que precisam ser executados em múltiplas plataformas e também quando se precisa variar uma interface e uma implementação de diferentes maneiras c COMPOSITE O padrão Composite nos permite criar e alimentar objetos em uma estrutura de árvore, gerando uma declaração composta do objeto, fazendo com que sejam tradados de forma singular objetos compostos e objetos únicos [GAMMA et al, 2000]. De acordo com Gamma et al (2000) este padrão pode ser usado quando quiser representar hierarquias partes-todo de objetos; e quando quiser que os clientes sejam capazes de ignorar a diferença entre composições de objetos e objetos individuais.

26 d DECORATOR Tem a característica de envelopar um objeto (ou vários, de acordo com a agregação que será aplicada), concedendo a este, novas responsabilidades em tempo real, o que traz possibilidades versáteis do uso de subclasses para realizar a ampliação de funcionalidades [FREEMAN, 2007]. Abaixo uma citação de quando usar o padrão Decorator em um projeto. Use Decorator: Para acrescentar responsabilidades a objetos individuais de forma dinâmica e transparente, ou seja, sem afetar outros objetos; Para responsabilidades que podem ser removidas; Quando a extensão através do uso de subclasses não é prática. Às vezes, um grande número de extensões independentes é possível e isso poderia produzir uma explosão de subclasses para suportar cada combinação. Ou a definição de uma classe pode estar oculta ou não estar disponível para utilização de subclasses. (GAMMA et al, Padrões de Projeto Soluções Reutilizáveis de Software Orientado a Objetos. Porto Alegre. Bookman, 2000, p. 172) e FAÇADE Segundo Freeman et al (2007) o padrão Façade fornece uma interface unificada para um conjunto de interfaces em um subsistema. A fachada define uma interface de nível mais alto que facilita a utilização do subsistema.

27 27 É criada uma fachada (visão simplória) do sistema para os usuários (apenas os que precisam se aprofundar mais às agregações e aos subsistemas terão uma tarefa mais complicada, pois esta é uma fachada simples e não detalhada), onde esta tem a capacidade de encarregar as solicitações do cliente para os objetos do subsistema, estimulando assim a independência e portabilidade entre os subsistemas [GAMMA et al, 2000]. De acordo com Gamma et al (2000) pode ser usada quando necessitar fornecer uma interface simples para um subsistema complexo. [...] existirem muitas dependências entre os clientes e as classes de implementação de uma abstração. [...] desejar estruturar em camadas seus subsistemas f FLYWEIGHT É um padrão que pode economizar recursos de memória devido à virtualização da instância de objetos que acontece durante o andamento do sistema, reunindo também os estados desses objetos no mesmo local, facilitando assim o controle dessas instâncias [FREEMAN et al, 2007]. Abaixo uma referência de quando pode ser aplicado o padrão Flyweight. Aplique o padrão Flyweight quando todas as condições a seguir forem verdadeiras: Uma aplicação utiliza um grande número de objetos; Os custos de armazenamento são altos por causa da grande quantidade de objetos; A maioria dos estados pode ser tornada extrínseca; Muitos grupos de objetos podem ser substituídos por relativamente poucos objetos compartilhados, uma vez que estados extrínsecos são removidos; A aplicação não depende da identidade dos objetos. Uma vez que objetos Flyweights podem ser compartilhados, testes de

28 28 identidade produzirão o valor verdadeiro (true) para os objetos conceitualmente distintos. (GAMMA et al, Padrões de Projeto Soluções Reutilizáveis de Software Orientado a Objetos. Porto Alegre. Bookman, 2000, p ) g PROXY Fornece um substituto (surrogate) ou marcador da localização de outro objeto para controlar o acesso ao mesmo [GAMMA et al, 2000]. É criado um objeto que será utilizado como um apontador de acesso a outro objeto ou recurso, e este objeto fornece uma interface para o proxy (que por sua vez, contém uma interface idêntica do objeto final, tornando este o substituto do objeto final quando necessário) e para o objeto final por ele referenciado [FREEMAN, 2007]. Abaixo uma citação que explana melhor quando o padrão Proxy pode ser utilizado e seus quatro modelos. O padrão proxy é aplicável sempre que há necessidade de uma referencia mais versátil, ou sofisticada, do que um simples apontador para um objeto [...] situações comuns nas quais o padrão Proxy é aplicável: 1. Um remote proxy fornece um representante local para um objeto num espaço de endereçamento diferente [...] 2. Um virtual proxy cria objetos caros sob demanda [...] 3. Um protection proxy controla o acesso para o objeto original. Os proxies de proteção são úteis quando os objetos devem ter diferentes direitos de acesso [...] 4. Um smart reference é um substituto para um simples pointer que executa ações adicionais quando um objeto é acessado [...] (GAMMA et al, Padrões de Projeto Soluções Reutilizáveis de Software Orientado a Objetos. Porto Alegre. Bookman, 2000, p. 200)

29 COMPORTAMENTAL Focado na abstração do comportamento dos objetos e classes, onde é distribuído variadas responsabilidades as classes e objetos para que sejam realizadas as tarefas, mostrando assim, certos padrões de comunicação entre objetos e classes que nesse caso é a maior característica desse tipo de padrão. Centralizado na maneira de como os objetos colaboram entre si dentro do sistema. Os padrões comportamentais se preocupam com algoritmos e a atribuição de responsabilidades entre objetos. Eles afastam o foco do fluxo de controle para permitir que você se concentre somente na maneira como os objetos são interconectados [GAMMA et al, 2000] a CHAIN OF RESPONSABILITY Os objetos são ligados (como uma corrente) de modo que caso aconteça alguma solicitação, esta não precise informar especificadamente qual será o objeto que irá tratar de seu requerimento, pois caso o objeto não puder responder a esta solicitação adequadamente, ela é passada para o próximo objeto na corrente, até encontrar o receptor que pode atendê-la [GAMMA et al, 2000]. Todo objeto na corrente possui um objeto sucessor. Caso ele possa cuidar da solicitação, ele assim o faz, senão repassa para seu sucessor, permitindo também à manipulação dinâmica de responsabilidades dos objetos através da mudança de ordem da corrente [FREEMAN et al, 2007].

30 30 Pode ser usada quando vários objetos podem tratar a mesma solicitação (sendo estes objetos definidos em tempo de execução ou não), sem fazer uma ligação entre solicitação e qual será seu objeto receptor [GAMMA et al, 2000] b COMMAND Encapsula uma solicitação como um objeto vinculando um composto de ações, podendo esta ter solicitações distintas, possibilitando a parametrização destas com requisições distintas, fornecendo registro de outras solicitações, bem como o cancelamento de operações [FREEMAN et al, 2007]. Deve se usar o padrão Command quando necessitar de algum item abaixo. Parametrizar objetos por uma ação a ser executada [...] Especificar, enfileirar e executar solicitações em tempos diferentes [...] Suportar desfazer operações [...] Suportar o registro (logging) de mudanças de maneira que possam ser reaplicadas no caso de um queda de sistema [...] Estruturar um sistema em torno de operações de alto nível alto construídas sobre operações primitivas [...](GAMMA et al, Padrões de Projeto Soluções Reutilizáveis de Software Orientado a Objetos. Porto Alegre. Bookman, 2000, p )

31 c INTERPRETER Define a construção e trabalho de um interpretador de uma gramática, que possua característica de representar e interpretar a mesma [GAMMA et al, 2000]. A gramática fica representada em classes, facilitando a implementação da linguagem, mudanças que precisem ser feitas e expansão da mesma, o que pode trazer diversos comportamentos para esta quando alterado ou criado um método à estrutura de classes [FREEMAN et al, 2007]. Gamma et al (2000) aponta que o uso do padrão Interpreter é conveniente quando houver uma linguagem para interpretar e você puder representar sentenças da linguagem como árvores sintáticas abstratas. É mais bem aplicada quando a gramática é mais simplória, e não é tido como prioridade o quesito desempenho d ITERATOR Tanto Freeman et al (2007) como Gamma et al (2000) definem o padrão Iterator como tornar possível o acesso sequencial de elementos de objetos do tipo coleção (como listas, matrizes, hashtables...) sem revelar a próxima representação. É criada uma interface iteradora que irá fornecer a interface para todos os iteradores (objetos iteradores obviamente implementam esta interface) e também seu conjunto de métodos para o acesso das coleções, dando assim a responsabilidade de gerenciamento da posição atual para o objeto iterador [FREEMAN et al, 2007].

32 32 De acordo com Gamma et al (2000) é utilizado o padrão Iterator para acessar os conteúdos de um objeto agregado sem expor sua representação interna; para suportar múltiplos percursos de objetos agregados; para fornecer uma interface uniforme que percorra diferentes estruturas agregadas [...] e MEDIATOR O Mediator é utilizado para manter um melhor controle das interações entre objetos, centralizando as operações de comunicação e controle entre eles [FREEMAN et al, 2007]. Na utilização desse padrão, é criado um objeto que será o mediador dessas comunicações entre objetos em geral, o que deixa os objetos sem referência direta sobre outros objetos, tendo que obrigatoriamente passar pelo mediador e este então realiza o trabalho de comunicador e controlador dessas interações. Segundo Gamma et al (2000) aplica-se o uso do padrão Mediator quando Um conjunto de objetos se comunica de maneiras bem-definidas, porém complexas [...]; a reutilização de um objeto é difícil [...]; um comportamento que está distribuído entre várias classes deveria ser customizável [...] f MEMENTO Tanto Gamma et al (2000) quanto Freeman et al (2007) dizem que o padrão Memento tem o objetivo de guardar um estado de um objeto-chave do sistema, esperando que seja utilizado e/ou restaurado pelo sistema.

33 33 Este padrão é utilizado quando se necessita de um estado de um objeto que é importante ao sistema, ou quando uma interface poderia acabar com a encapsulação e expor detalhes da implementação [GAMMA et al, 2000] g OBSERVER Em formalidades, o padrão Observer define uma dependência de um-paramuitos entre objetos, onde quando tal objeto muda de estado, os dependentes do mesmo são avisados e renovados [GAMMA et al, 2000]. São criados dois tipos de interfaces, uma é o sujeito e o outro observador. O sujeito é aquele que terá seu estado alterado e informará as classes ligadas a ele quando isto acontecer, e os observadores são os que precisam saber das mudanças do sujeito. O sujeito ainda faz o controle dos seus observadores, atendendo pedidos de adição à sua rede (ou seja, adicionando mais observadores) e retirando observadores caso seja requisitado [FREEMAN et al, 2007]. O Observer pode ser aplicado quando acontece uma modificação de um objeto e por conta disso outros necessitam mudar e não se tem uma noção de quantos exatamente são; ou quando um objeto é fracamente acoplado e precisa notificar outros objetos; ou quando uma abstração possui dois aspectos e um depender do outro [GAMMA et al, 2000].

34 h STATE Padrão State permite que um objeto altere o seu comportamento quando o seu estado interno muda. O objeto parecerá ter mudado de classe [FREEMAN et al, 2007]. Nessa implementação são utilizadas de uma classe que pode ter vários estados internos diferentes (comumente nomeada de contexto) e de uma interface (nomeada de Estado) comum para todos os estados, devendo assim ser implementada em todos estados. A classe contexto altera seu estado interno e solicita um processo ao objeto estado, este recebe a solicitação e utiliza de suas implementações de acordo com os métodos que possuí para atender a solicitação do contexto, podendo assim, ter diferentes comportamentos dependendo do estado de contexto [GAMMA et al, 2000]. O padrão State poderá ser usado quando: O comportamento de um objeto depende do seu estado e ele pode mudar seu comportamento em tempo de execução, dependendo desse estado; Operações têm comandos condicionais grandes, de várias alternativas, que dependem do estado do objeto [...]. (GAMMA et al, Padrões de Projeto Soluções Reutilizáveis de Software Orientado a Objetos. Porto Alegre. Bookman, 2000, p. 285) i STRATEGY Strategy permite que o algoritmo varie independentemente dos clientes que o utilizam [GAMMA et al, 2000].

35 35 Para ser usado, é definida uma interface (chamada de compositor) para todos os algoritmos suportados, onde possuem classes diferentes que a implementam (algoritmos diferentes, novos objetos implementando o compositor), e assim o composition (que é a classe que repassa solicitações dos clientes para as estratégias) passa ao compositor a ação a ser feita, juntamente referenciando qual objeto compositor será utilizado. Convém ser usado quando necessitar de variantes de um algoritmo; ou quando várias classes relacionadas se comportam diferente; quando houver múltiplos comandos condicionais e precise preservar a exibição das estruturas de dados [GAMMA et al, 2000] j TEMPLATE METHOD O padrão Template Method (Gabarito de Método) faz com que um algoritmo possa ser parcialmente redefinido, onde uma classe mãe passa certas atribuições para as subclasses que serão chamadas para complementar a execução de tal algoritmo, podendo assim ter diferentes comportamentos finais (pois estas são feitas pelas subclasses), sem modificar a estrutura do algoritmo [GAMMA et al, 2000]. Seguindo as normativas da GoF, o padrão Template Method pode ser usado: Para implementar as partes invariantes de um algoritmo uma só vez e deixar para as subclasses a implementação do comportamento que pode variar. Quando o comportamento comum entre subclasses deve ser fatorado e concentrado numa classe comum para evitar a duplicação de código [...]. Para controlar extensões de subclasses [...]. (GAMMA et al, Padrões de Projeto Soluções Reutilizáveis de Software Orientado a Objetos. Porto Alegre. Bookman, 2000, p. 302)

36 k VISITOR Tem o objetivo de representar uma operação a ser executada nos elementos de uma estrutura de objetos. Visitor permite definir uma nova operação sem mudar as classes dos elementos sobre os quais opera [GAMMA et al, 2000]. De acordo com a GoF, deve-se usar o padrão Visitor quando: Uma estrutura de objetos contém muitas classes de objetos com interfaces que diferem e você deseja executar operações sobre estes objetos que dependem das suas classes concretas; Muitas operações distintas e não-relacionadas necessitam ser executadas sobre objetos de uma estrutura de objetos, e você deseja evitar a poluição das suas classes com estas operações [...]; As classes que definem a estrutura do objeto raramente mudam, porém, você frequentemente deseja definir novas operações sobre a estrutura [...].(GAMMA et al, Padrões de Projeto Soluções Reutilizáveis de Software Orientado a Objetos. Porto Alegre. Bookman, 2000, p. 308) O foco do padrão Visitor (visitante) é a funcionalidade abstrata que pode ser aplicada a uma hierarquia de objetos agregados. Uma nova funcionalidade pode ser adicionada à hierarquia da herança original, criando assim uma nova classe de visitantes [FREEMAN et al, 2007].

37 37 3 INTERFACE Uma interface é algo que torna possível a interação ou intercomunicação entre coisas distintas. É um determinado meio onde coisas diversas tem a capacidade de interação entre elas, podendo ser feita através de meio físico ou lógico [FERREIRA, 1986]. A interface, portanto, é o ponto no qual eles - o usuário, tarefa e ferramenta - comunicam-se, interagem e se tornam um único elemento [BRAGA, 2004]. Em computação, é utilizado tanto para usuários quanto para desenvolvedores um tipo de interface que permite um melhor controle ou ação sobre determinado sistema ou dispositivo, que podem ser do tipo GUI (Graphical User Interface, ou interface gráfica do usuário) ou do tipo CLI (Command Line Interface, ou interface de linha de comando). Um CLI é dado como uma interface de texto, onde o usuário é o responsável por digitar um comando válido para que o sistema realize alguma tarefa específica e resultando assim na resposta do computador. Necessita ter um pouco mais de conhecimento sobre o sistema em que se está utilizando para ter uma boa interação com o mesmo, por isso, geralmente é mais utilizável por usuários mais avançados [SILVA, 2010]. Uma interface gráfica do usuário (GUI) utiliza de combinações de tecnologia e dispositivos, fornecendo para o usuário uma plataforma com a qual possa interagir e utilizar dos recursos computacionais da máquina (ou software). Este tipo de interface é o mais utilizado atualmente para os usuários finais de sistemas, pois apresenta ao mesmo um ambiente amigável de interação, tentando trazer juntamente a facilidade de uso e produtividade. A interação entre usuário e o computador em teoria é de fácil entendimento, uma vez que ambos entram em um diálogo em comum, sabe-se que é para realizar uma tarefa em questão, e que os mecanismos usados neste diálogo são a composição da interface em si, tais como os dispositivos e programas que podem controlar esta comunicação [CARD, 1986].

38 38 Essas interações que ocorrem em diversos tipos de sistemas devem ser estudadas de modo único, pois cada software pode possuir uma variedade de interações que precisam de atenções e ações diferentes, fazendo com que o estudo da interação seja primordial para o desenvolvimento do sistema. Necessita-se de um conhecimento mais profundo de como será feita a interação de homem-computador para idealizarmos uma forma ideal de usabilidade. Porém, ao se estabelecer harmonia entre os componentes que participam da interação, é possível afirmar que foi alcançado o objetivo da usabilidade [SHACKEL, 2008]. 3.1 USABILIDADE A usabilidade é considerada um propósito que tem o objetivo de garantir que o produto (nesse caso, um software) seja fácil de usar, eficiente e agradável [PREECE et al, 2005]. Em contradição com a afirmação citada por Lima (2010), onde a usabilidade deve ser aplicada especialmente em sistemas em que o usuário espera por eficácia e eficiência em suas transações, deixando em segundo plano a procura por uma experiência estética e emocional, trataremos a estética também como chave da usabilidade, trazendo a estética e gosto pessoal do cliente à tona, deixando parte da responsabilidade de ter um sistema perfeito para o próprio usuário final. Segundo Bannon (2000), devemos mudar o modo como vemos os usuários, onde a equipe de design do sistema deve pensar substancialmente em como o sistema é gerido e utilizado por eles, e ao invés de caracterizarmo-los apenas como simples usuários. É preciso tratá-los como contribuintes na concepção do programa, visando ter essa colaboração deles para a criação de um sistema melhor.

39 39 Como a usabilidade tende a aperfeiçoar o uso de algo e proporcionar ao usuário um melhor ambiente agradável para se utilizar, é dado que se possuem metas de usabilidade. O sistema precisa deixar o usuário fazer tarefas que deseja (dentro do estipulado pelas limitações de seu trabalho) e também apresentar eficácia, eficiência e utilidade em sua utilização, sendo capaz de ajudar o usuário nas realizações de tarefas e concretizar essas tarefas com sucesso. Também é preciso que ofereça segurança em relação à proteção contra situações que podem ocorrer erroneamente por parte do usuário. Não esquecendo também a capacidade de aprendizagem que o sistema tende a oferecer e capacidade de memorização, pois quanto mais simples de se utilizar for, melhor para se lembrar de como fazer tal tarefa e mais rápido será a usabilidade e rendimento do usuário [PREECE et al,2005]. Seguindo esta linha de pensamento, tentaremos buscar um equilíbrio da usabilidade e sua perspectiva de sucesso. Passando a deixar o usuário desenvolver sua própria interface de utilização, espera-se que o nível de satisfação fique mais elevado, o que pode também alavancar os índices de produtividade. A eficiência e a facilidade no uso do sistema pode (e deve) ser alcançada seguindo certos padrões que atendam à necessidade do software, enquanto o termo agradável pode ser mais difícil de alcançar devido ao design definitivo (das telas) de um sistema que é imposto ao usuário final, obrigando-o a sempre ter que utilizar a mesma interface, sem ter a possibilidade de remanejar os itens de um modo que melhor lhe convenha.

40 40 4 DESENVOLVIMENTO DA PROPOSTA Aplicando os conhecimentos estudados sobre padrões de projeto, aliado à usabilidade de software, foi criado um protótipo de uma simples tela de cadastro de alunos para demonstrar a personalização da interface em tempo de execução feita pelo usuário. Para a criação do protótipo foi utilizada a tecnologia e linguagem de programação JAVA para a codificação, e o sistema de gerenciamento de banco de dados MySQL, para o armazenamento de dados necessários para o funcionamento do programa. A ideia foi fazer com que o usuário tivesse o controle de como sua interface de trabalho poderia ser reorganizada de acordo com seu próprio gosto, dando assim, a possibilidade de escolha da localidade dos campos, botões, imagem de fundo e tamanho da janela. 4.1 O BANCO DE DADOS Para o funcionamento das opções de personalização, foi criado um banco de dados com apenas duas tabelas, sendo elas Login e Estado. A seguir a Figura 1 nos mostra as duas tabelas e seus respectivos campos.

41 41 Figura 1 Tabelas do banco A tabela login é utilizada para a criação de novos usuários do protótipo, já a tabela estado é responsável por guardar as informações dos campos (qual o tamanho da janela, a posição dos campos na tela e imagem do fundo) possuindo a uma chave estrangeira com a tabela login para o relacionamento das mesmas. 4.2 PROTÓTIPO O protótipo foi desenvolvido utilizando a IDE (Integrated Development Environment, tradução livre para Ambiente Integrado de Desenvolvimento ) do Eclipse (Versão: Kepler Service Release 1) juntamente com a versão do JavaSE 1.7 e suas bibliotecas. A Figura 2 nos traz a divisão dos pacotes do software e seus respectivos conteúdos.

42 42 Figura 2 Estrutura do protótipo O desenvolvimento do protótipo foi baseado no modelo de software de 3 ou n camadas, onde foi separado o acesso dos dados da lógica de negócios e da apresentação do software, e neste caso, foram separadas também as classes de personalização e imagens. 4.3 CICLO DO PROTÓTIPO O ciclo do sistema é iniciado com a chamada da tela de Login para que o usuário possa entrar no sistema através de seu cadastro ou também há a possibilidade de criação de um novo usuário, ação que pode ser realizada clicando na área designada em destaque (tela ilustrada a seguir na Figura 3).

43 43 Figura 3 Tela de Login Foi criada uma tela para cadastrar novos usuários, onde é necessário o preenchimento dos campos usuário e senha (tela Cadastro de Usuário mostrada na abaixo Figura 4). Na criação desse novo usuário, é gerado no banco um novo cadastro na tabela de Login e também na tabela Estado, dando assim o valor padrão da tela de cadastro de aluno. Figura 4 Cadastro de Usuários Ao realizar o login no sistema é iniciada a tela principal, que nos fornece a opção de cadastrar um novo aluno ou encerrar o programa.

44 44 Figura 5 Tela Principal Ao entrar na opção de cadastro de novo aluno, é carregada a tela de Cadastro de Alunos com seu layout salvo, que no caso de um usuário novo é o default (ver Figura 6, layout pré-definido para novos usuários ou para os que não realizaram alterações) ou a interface personalizada definida e salva pelo usuário anteriormente. Figura 6 Cadastro de Aluno Padrão

45 45 O botão no canto superior esquerdo chamado Edição irá ativar/desativar as opções de customização da tela, fazendo com que os campos e botões fiquem desabilitados não podendo ser inseridos dados neles, mas sim fornecendo a habilidade de movimentação dos campos. Após realizar as alterações que desejar o usuário deverá pressionar o botão Ok para que a interface seja salva com suas configurações. A partir deste momento então, o sistema já estará com as propriedades definidas pelo usuário (ver Figura 7), não sendo necessário a reinicialização do sistema para que as alterações sejam feitas, provendo assim uma rápida e instantânea edição de interface para o cliente. Figura 7 Exemplo de Interface Alterada Também foi implementado um método para realizar a troca da cor da fonte dos campos. Caso o usuário escolha um fundo de cor escura, os labels mudam

46 46 para cores claras (ver Figura 8), fornecendo certa adaptabilidade para a interface. Figura 8 Exemplo de Interface Alterada Fundo Escuro 4.4 FUNCIONAMENTO INTERNO DO SISTEMA O protótipo foi criado com base na teoria de software em camadas, dividindo assim em pacotes o acesso ao banco, regra de negócios, formulários, imagens, dentre outros. O acesso à conexão com o banco de dados é feito a partir da classe Conexão do pacote banco (mostrado no Código 1). Essa conexão segue os conceitos do padrão Singleton, que oferece apenas um método de acesso a este objeto, nos garantindo assim uma única instância.

47 47 Código 1 Classe conexão modelo padrão Singleton Como é visto no código acima, é criado um objeto estático chamado instancia para guardar a única instância desta classe sendo que o construtor da mesma é privado, o que obriga apenas a esta classe poder acessa-la, e o método estático instanciar() que nos retorna a instância, caso não existir é instanciada a classe, garantindo apenas uma instância da classe conexão. A inserção e alteração no banco são feitas através de um método específico da classe (LoginDAL ou EstadoDAL) que recebe os valores por parâmetro e repassa ao PreparedStatement com uma conexão criada o comando SQL que será executado. A tela de Cadastro de Aluno (mostrada na Figura 7) foi construída seguindo alguns princípios do padrão Builder, mas não completamente, pois este padrão requer uma interface de criação abstrata para o objeto, o que neste caso não foi utilizado. Ao invés disso, foi aplicado o método padrão de criação de Jframe (estendendo a classe JFrame), mudando apenas os valores recebidos dos objetos contidos nela no momento do carregamento da tela, passando os valores de localização dos campos/botões e tamanho do Jframe.

48 48 Ao ser inicializada a tela de Cadastro de Aluno, são criados os campos com os valores e botões com os valores default da aplicação, e logo depois, é instanciado um objeto da classe EstadoDAO, para então armazenar o resultado da chamada do método verificaestado(int idlogin) em uma variável (neste caso chamada de carrega, conforme o Código 2 abaixo demonstra), que será utilizada para verificar se há dados salvos para aquele usuário. Código 2 Código Verificação e Carregamento de Estado Após a verificação, é feito o carregamento desses dados, utilizando o método carregaestado(int idestado), que nos retorna um objeto com os valores armazenados no banco, para assim então passar aos objetos as suas configurações que estão salvas para aquele determinado usuário. A movimentação dos campos se torna habilitada quando pressionada a opção Edição na tela de cadastro de Aluno (Figura 8), onde é chamado assim a classe de movimentação que implementa o MouseMotion Listener, onde é sobrescrito o método do evento de mouse mousemoved (para não realizar nada caso o mouse seja movido) e mousedragged, este último que utiliza o método converpoint() do SwingUtilities para pegar qual objeto foi selecionado, pontos de localização e parentesco e depois agregar os valores do objeto utilizando o método setbounds() (verificar o Código 3 abaixo).

49 49 Código 3 Eventos mousedragged e MouseMoved Os campos foram divididos em uma estrutura pré-definida, agrupando dentro de um JPanel os campos que estariam ligados, como por exemplo Nome, CPF e Data de Nascimento, Rua, nº, Bairro, CEP, Telefone, Celular, , Sexo e Curso, Período, Data de Matrícula. O evento de mousedragged e mousemoved foi aplicado para estes JPanel e JButton, dando assim a movimentação do objeto caso for clicado e arrastado nesses elementos dentro da tela. Vale lembrar que se pode também tentar a implementação do padrão Adapter para manter o sistema funcionando com seu novo layout ou pelo menos adaptá-lo para tal. O protótipo desenvolvido manteve suas funcionalidades, mas caso o usuário deixe algum campo ou botão fora de visão da tela ou por acaso o corte, o software poderia com essa implementação tentar se adaptar para não deixar o sistema inutilizável, aumentando seu tamanho e se adequando a interface definida pelo usuário. Também cabe a tentativa de se utilizar o padrão Composite para a criação dos objetos de personalização, dando uma possibilidade de trabalhar igualmente com objetos, sejam estes compostos ou não. O que poderia ser utilizado caso fosse deixar o usuário decidir quais campos se uniriam e poderiam se mover como um grupo (aplicando esse padrão em cima do JPanel). Caso não tenha problemas de entendimento e depuração o padrão Decorator pode ser aplicado para ampliar as funcionalidades de personalização, pois este padrão suporta composição múltipla e com isso pode adicionar comportamentos aos objetos em tempo de execução, algo que poderia dar uma gama imensa de novas possibilidades de customizações das interfaces.

50 50 5 CONCLUSÃO A utilização dos padrões de projeto torna o software melhor organizado e de simples administração, fornecendo uma possibilidade de manutenção do projeto, obtendo mais controle das diversas situações que podem vir a ocorrer. Além disso, traz uma confiabilidade do código e clareza de seu entendimento aos desenvolvedores, mas devem ser utilizados com cautela, sempre seguindo os critérios que alguns padrões requerem e avaliando se a necessidade é realmente válida e aplicável a tal situação, pois caso seja mal aplicado, pode prejudicar o funcionamento e qualidade do sistema. A personalização de interface em tempo real, que ainda é pouco utilizada, pode ser aplicada facilmente aos diversos projetos, porém é necessário primeiramente definir os limites que serão aplicados a esta área para não permitir que o sistema se torne ineficiente. Neste trabalho foram utilizadas algumas técnicas para a aplicação do padrão Singleton, que por sua vez torna o sistema melhor administrado. Porem também foram sugeridos alguns outros padrões que valem a tentativa de ser implementados em sistemas similares, deixando assim uma abertura para futuros trabalhos na área sobre padrões de projetos.