Embed Size (px)
Citation preview
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
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
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, 2013.
52 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: 001.6
Biblioteca da FEMA
DEDICÁTORIA
Dedico este trabalho aos meus amigos,
professores e familiares que me
apoiaram e me incentivaram nessa
jornada.
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.
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.
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.
LISTA DE TABELAS
Tabela 1 - Os tipos de padrões de projeto ..................................................... 19
LISTA DE FIGURAS
Figura 1 – Tabelas do banco ........................................................................... 41
Figura 2 – Estrutura do protótipo ..................................................................... 42
Figura 3 – Tela de Login ................................................................................. 43
Figura 4 – Cadastro de Usuários ..................................................................... 43
Figura 5 – Tela Principal ................................................................................. 44
Figura 6 – Cadastro de usuário padrão ........................................................... 44
Figura 7 – Exemplo de Interface Alterada ....................................................... 45
Figura 8 – Exemplo de Interface Alterada Fundo Escuro ................................ 46
LISTA DE CÓDIGOS
Código 1 - Classe conexão modelo padrão Singleton ...................................... 47
Código 2 - Código Verificação e Carregamento de Estado .............................. 48
Código 3 – Eventos mouseDragged e MouseMoved ....................................... 49
SUMÁRIO
1 INTRODUÇÃO .............................................................................................. 13
1.1 OBJETIVOS ......................................................................................................................... 14
1.2 JUSTIFICATIVAS.................................................................................................................. 14
1.3 MOTIVAÇÃO ...................................................................................................................... 15
1.4 PERSPECTIVAS DE CONTRIBUIÇÃO .................................................................................... 15
1.5 METODOLOGIAS DE PESQUISA ......................................................................................... 16
2 PADRÕES DE PROJETO ............................................................................. 17
2.1 CARACTERÍSTICAS DE UM PADRÃO DE PROJETO .............................................................. 17
2.2 CLASSIFICAÇÃO .................................................................................................................. 18
2.2.1 CRIAÇÃO ......................................................................................................................... 19
2.2.1.a ABSTRACT FACTORY .................................................................................................... 20
2.2.1.b BUILDER ....................................................................................................................... 21
2.2.1.c FACTORY METHOD ...................................................................................................... 21
2.2.1.d PROTOTYPE ................................................................................................................. 22
2.2.1.e SINGLETON .................................................................................................................. 23
2.2.2 ESTRUTURAL ................................................................................................................... 23
2.2.2.a ADAPTER ...................................................................................................................... 24
2.2.2.b BRIDGE ........................................................................................................................ 25
2.2.2.c COMPOSITE ................................................................................................................. 25
2.2.2.d DECORATOR ................................................................................................................ 26
2.2.2.e FAÇADE ........................................................................................................................ 26
2.2.2.f FLYWEIGHT ................................................................................................................... 27
2.2.2.g PROXY .......................................................................................................................... 28
2.2.3 COMPORTAMENTAL ....................................................................................................... 29
2.2.3.a CHAIN OF RESPONSABILITY ......................................................................................... 29
2.2.3.b COMMAND .................................................................................................................. 30
2.2.3.c INTERPRETER ............................................................................................................... 31
2.2.3.d ITERATOR..................................................................................................................... 31
2.2.3.e MEDIATOR ................................................................................................................... 32
2.2.3.f MEMENTO .................................................................................................................... 32
2.2.3.g OBSERVER .................................................................................................................... 33
2.2.3.h STATE ........................................................................................................................... 34
2.2.3.i STRATEGY ..................................................................................................................... 34
2.2.3.j TEMPLATE METHOD ..................................................................................................... 35
2.2.3.k VISITOR ........................................................................................................................ 36
3 INTERFACE .................................................................................................. 37
3.1 USABILIDADE ..................................................................................................................... 38
4 DESENVOLVIMENTO DA PROPOSTA ........................................................ 40
4.1 O BANCO DE DADOS.......................................................................................................... 40
4.2 PROTÓTIPO ........................................................................................................................ 41
4.3 CICLO DO PROTÓTIPO ....................................................................................................... 42
4.4 FUNCIONAMENTO INTERNO DO SISTEMA ........................................................................ 46
5 CONCLUSÃO ................................................................................................ 50
REFERÊNCIAS ................................................................................................ 51
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
1.1 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
1.3 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
1.5 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
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
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
PROPÓSITO
Criação Estrutura Comportamento E
S C
O P
O
CLASSE Factory Method Class Adapter* Interpreter
Template Method
O B
J E
T O
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.
2.2.1 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
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].
2.2.1.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
implementações. (GAMMA et al, Padrões de Projeto –
Soluções Reutilizáveis de Software Orientado a Objetos.
Porto Alegre. Bookman, 2000, p. 97)
2.2.1.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”.
2.2.1.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
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)
2.2.1.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
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)
2.2.1.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].
2.2.2 ESTRUTURAL
Atenta-se à formação dos objetos e classes, como eles são compostos,
podendo assim, criar estruturas maiores [GAMMA et al, 2000].
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.
2.2.2.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
2.2.2.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.
2.2.2.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
2.2.2.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)
2.2.2.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
É 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”.
2.2.2.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
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. 190-191)
2.2.2.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
2.2.3 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].
2.2.3.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
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].
2.2.3.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. 224-
225)
31
2.2.3.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.
2.2.3.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
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 [...]” .
2.2.3.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 [...]”.
2.2.3.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
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].
2.2.3.g OBSERVER
Em formalidades, o padrão Observer define uma dependência de um-para-
muitos 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
2.2.3.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)
2.2.3.i STRATEGY
“Strategy permite que o algoritmo varie independentemente dos clientes que o
utilizam“ [GAMMA et al, 2000].
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].
2.2.3.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
2.2.3.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
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
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
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
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
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
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
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
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
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
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
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
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
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, Email”,
“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
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.
51
REFERÊNCIAS
ALEXANDER, Christopher. A Pattern Language, Oxford Press, Oxford, R. Unido, 1978. BANNON, Liam J. From human factors to human actors: the role of psychology and human-computer interaction studies in system design. En: Baecker, Ronald M. et al (eds.), paginás 205-214, 2000. Disponível em: < http://www.it.uu.se/edu/course/homepage/acsd/vt11/schema/Bannon.pdf>. Acesso em: 25 junho, 2013. BRAGA, Alexandre Santaella. Design de Interface – As origens do design e sua influência na produção da hipermídia. 2004. 135 f. Dissertação Mestrado (Comunicação e Semiótica) – Pontíficia Universidade Católica de São Paulo – PUC SP, São Paulo, 2004. [Orientador: Prof. Dr. Sérgio Bairon Blanco Sant’anna]. Disponível online em: <http://www.pucsp.br/~braga/dissertacao.pdf>. Acesso em: 06 junho, 2013. CARD, Stuart K; MORAN, Thomas P.; NEWEL, Allen. The Psychology of Human - Computer Interaction. New Edition. (February 1, 1986) Lawrence Erlbaum Associates, 1986. 469 p. Disponível em: <http://www.cs.colorado.edu/~martin/Csci6402/Papers/carroll97.pdf> FERREIRA, Aurélio B. de Hollanda. Novo Dicionário da Língua Portuguesa. 2. ed. Rio de Janeiro: Nova Fronteira, 1986. 1838 p. FREEMAN, Eric; FREEMAN, Elisabeth; SIERRA, Kathy; BATES, Bert; . Use a Cabeça! Padrões de Projeto. 2ª Edição Revisada. Rio de Janeiro: Alta Books, 2007. 494 p. GAMMA, Erich; HELM, Richard; JOHNSON, Ralph; VLISSIDES, John. Padrões de Projeto – Soluções Reutilizáveis de Software Orientado a Objetos. Porto Alegre: Bookman, 2000. 364p.
52
LIMA, Maíza M. R. Usabilidade nos tempos de hoje – A importância deste conceito no desenvolvimento de interfaces. 2010. 49 f. Trabalho de Conclusão de Curso (Bacharelado em Ciência da Computação) - Fundação Educacional do Município de Assis – FEMA, Assis, 2010. [Orientador: Prof. Dr. Luiz Ricardo Begosso]. Disponível online em: <http://fema.edu.br/images/arqTccs/0711270089.pdf>. Acesso em: 26 maio, 2013. MOLSKI, Fernando Ricardo. Customização de software com ênfase na arquitetura mvc e struts. DevMedia, s.d. . Disponível em <http://www.devmedia.com.br/customizacao-de-software-com-%C3%AAnfase-na-arquitetura-mvc-e-struts/8830>. Acesso em: 02 março, 2013. OLIVEIRA, Eric C. M. Introdução a Design Patterns. Linha de Código, publicado em 07 de junho de 2004. Disponível em: <http://www.linhadecodigo.com.br/ArtigoImpressao.aspx?id=345>. Acesso em: 27 fevereiro, 2013. PREECE, Jennifer; ROGERS, Yvonne; SHARP, Hellen. Design de Interação: Além da interação homem-computador. Trad. Viviane Possamai. Reimpressão 2007. Porto Alegre: Bookman, 2005.548p. SHACKEL, B., RICHARDSON, S. J. Human Factors for Informatics Usability. Cambridge University Press, 2008. 464 p. SILVA, Gleydson Mazioli da . Guia Foca GNU/Linux: Guia Iniciante. Versão 4.22, 2010. Disponível em: <http://www.guiafoca.org/cgs/guia/iniciante/index.html>. Acesso em: 19 junho, 2013. S/N. Source Making – Teaching IT Professionals. Factory Method Design Pattern. Disponível em: <http://sourcemaking.com/design_patterns/factory_method>. Acesso em: 15 maio, 2013.
