Graduação puc - aplicações de padrões de projeto no desenvolvimento de interfaces gráficas de dispositivos móveis

PONTIFÍCIA UNIVERSIDADE CATÓLICA DE MINAS GERAIS
Sistemas de Informação
APLICAÇÕES DE PADRÕES DE PROJETO NO DESENVOLVIMENTO
DE INTERFACES GRÁFICAS DE DISPOSITIVOS MÓVEIS
Wagner Tironi Pinto
Contagem
2005

Wagner Tironi Pinto
APLICAÇÕES DE PADRÕES DE PROJETO NO DESENVOLVIMENTO
Monografia de Conclusão do Curso de
Graduação Bacharel em Sistemas de
Informação da PUC-Minas Contagem.
Orientador: Esli de Almeida Rocha
Contagem
2005

2
AGRADECIMENTOS
Ao meu prezado orientador, Esli de Almeida Rocha, por me guiar até o destino com
segurança.
Aos meus pais e irmãs, Nívia e Silvia, pela ajuda, incentivo e crença.
A Tati, pelo amor e compreensão.
Ao Elis, pelas inúmeras impressões.
Ao João Pinto, pelas orações e eterna companhia.
Aos amigos, colegas, conhecidos e afins que de alguma forma contribuíram para
minha construção.
Obrigado.

3
“Minha vida, nossas vidas
Formam um só diamante,
Aprendi novas palavras e
Tornei outras mais belas”
Canção Amiga, Carlos Drummond de Andrade. (1902–1987)
“... ao vencedor, as batatas!”
Quincas Borbas, Machado de Assis. (1839-1908)

RESUMO
O principal objetivo deste trabalho é demonstrar as possíveis contribuições
da aplicação dos padrões de projeto no desenvolvimento de softwares para
dispositivos móveis na elaboração da interface gráfica. O dispositivo móvel alvo de
estudo deste trabalho é o Pocket PC, que utiliza o sistema operacional Windows
CE.
É abordado questões referentes à plataforma selecionada para o
desenvolvimento, a .NET e o paradigma de programação orientado a objetos e os
padrões de projeto.
Os padrões de projeto são utilizados para mostrar soluções abstratas para
problemas que surgem freqüentemente durante o projeto de sistemas orientado a
objetos. As soluções propostas permitem que compartilhem experiência entre
programadores avançados e novatos.
Os padrões de projeto selecionados foram o Singleton, Factory Method,
Decorator e State. A partir da escolha foram desenvolvidas propostas de soluções
para a construção de interfaces gráficas com base em um sistema de inventário.
A aplicação permitiu uma avaliação dos pontos positivos encontrados com a
utilização dos padrões de projeto para a elaboração de interfaces gráficas para
aplicativos móveis.
Palavras-chave: orientação a objetos; padrões de projeto; dispositivos
móveis.

5
SUMÁRIO
1 INTRODUÇÃO.................................................................................................. 8
1.1 CONSIDERAÇÕES INICIAIS.............................................................................. 8
1.2 MOTIVAÇÃO ............................................................................................... 10
1.3 OBJETIVOS ................................................................................................ 11
1.4 METODOLOGIA ........................................................................................... 12
2 REFERENCIAL TEÓRICO ............................................................................. 13
2.1 ORIENTAÇÃO A OBJETOS ............................................................................ 13
2.2 PADRÕES DE PROJETO ............................................................................... 14
2.3 INTERFACE GRÁFICA................................................................................... 19
3 DESENVOLVIMENTO .................................................................................... 22
3.1 DISPOSITIVOS MÓVEIS......................................................................... 22
3.1.1 Pocket PC......................................................................................... 22
3.1.2 Windows CE ..................................................................................... 24
3.2 PLATAFORMA DE DESENVOLVIMENTO .............................................. 28
3.2.1 Linguagem C#................................................................................... 28
3.3 PADRÕES DE PROJETO APLICADOS AO DESENVOLVIMENTO DE
INTERFACES GRÁFICAS DE DISPOSITIVOS MÓVEIS.................................... 31
3.3.1 Singleton........................................................................................... 33
3.3.2 Factory Method................................................................................. 35
3.3.3 Decorator.......................................................................................... 37
3.3.4 State ................................................................................................. 41
4 CONCLUSÃO ................................................................................................. 45
5 REFERÊNCIAS BIBLIOGRÁFICAS............................................................... 47

6
LISTA DE FIGURAS
FIGURA 1 - RELACIONAMENTO ENTRE OS PADRÕES DE PROJETO – FONTE [GAM+00] .... 17
FIGURA 2 - ALGUNS MODELOS DE POCKET PC – FONTE: [MCP03]............................... 23
FIGURA 3 - COLETOR PA962 – FONTE: [GOH03] ....................................................... 24
FIGURA 4 - LOGOMARCA DE PROJETO PEGASUS ......................................................... 26
FIGURA 5 - DIAGRAMA DO PADRÃO MVC.................................................................... 32
FIGURA 6 - DIAGRAMA DE CLASSE: SINGLETON - FONTE: [GAM+00].................. 33
FIGURA 7 - DIAGRAMA DE CLASSE: EXEMPLO DO SINGLETON ................................ 35
FIGURA 8 - DIAGRAMA DE CLASSE: FACTORY METHOD - FONTE: [GAM+00]..... 35
FIGURA 9 - DIAGRAMA DE CLASSE: EXEMPLO FACTORY METHOD........................... 37
FIGURA 10 - DIAGRAMA DE CLASSE: DECORATOR - FONTE: [GAM+00].............. 38
FIGURA 11 - DIAGRAMA DE CLASSE: EXEMPLO DECORATOR.................................. 40
FIGURA 12 - DIAGRAMA DE CLASSE: STATE - FONTE: [GAM+00]........................ 41
FIGURA 13 - DIAGRAMA DE CLASSE: EXEMPLO STATE......................................... 44

7
LISTA DE TABELAS
TABELA 1 - ORGANIZAÇÃO DOS PADRÕES DE PROJETO – FONTE [GAM+00].................. 18

1 INTRODUÇÃO
1.1 Considerações Iniciais
A mobilidade é hoje uma característica tecnológica cada vez mais presente
em nosso cotidiano. Neste segmento, surgem em períodos cada vez mais curtos,
dispositivos móveis menores e mais eficientes. Alguns recursos como: acesso à
internet, transmissão de dados, localização via GPS, captura de imagens, gravações
de vídeos e sons, são comuns nestes dispositivos.
A grande variedade de funcionalidades destes dispositivos tem despertado o
interesse de diversas organizações nos mais variados segmentos. Equipes de
vendas, médicos, acadêmicos vêm utilizando estes recursos na busca de ganhos de
produtividade e qualidade em suas atividades.
Existe uma diversidade de dispositivos móveis no mercado com
particularidades que os caracterizam. Entre tantos, destacam-se: o Pocket PC, que
utiliza o sistema operacional Windows CE; o Palm, que utiliza o Palm OS. Além
disto, cada dispositivo possui softwares e recursos próprios como editor de imagens,
navegadores web, teclados, mouse, entre outros.
Devido a estas características especificas dos dispositivos móveis e as
necessidades das organizações, os desenvolvedores de software tiveram que se
adequar a este cenário. A escolha da plataforma e da utilização de conceitos
modernos de desenvolvimento, como a orientação a objetos, tornou-se importante
para diminuir as dificuldades deste ambiente complexo.
A definição de uma plataforma para o desenvolvimento de aplicações para
dispositivos móveis, leva em conta diversos fatores. São necessários maior grau de
robustez e flexibilidade que dêem o devido suporte para o desenvolvimento de

9
aplicativos com qualidade. Além disto, contribuem para alcançar as necessidades
das organizações. Dentre as plataformas disponíveis no mercado, podemos citar o
.NET, com as linguagens C# e Visual Basic (VB) e o J2ME, com a linguagem Java.
A orientação a objeto está presente em ambas as plataformas.
A programação orientada a objetos (POO) é o paradigma de desenvolvimento
em que os componentes da programação são tratados como objetos. Estes objetos
são representações do mundo real, com suas propriedades, estados e
comportamentos próprios e que relacionam entre si.
A utilização da POO possibilita uma elevada produtividade. Conceitos como
herança, polimorfismo e encapsulamento, possibilitam a reutilização de código e
uma melhor compreensão dos conceitos que envolvem o sistema [MAR93].
A orientação a objetos possibilitou o surgimento dos padrões de projeto que
são boas práticas de desenvolvimento. Isto porque contribuem para a construção de
sistemas confiáveis, robustos, extensíveis e reutilizáveis. Os padrões de projeto
foram concebidos na década de 70, com base na proposta de Christopher Alexander
para padrões de arquitetura para construção em geral (casas, bairros, cidades, etc.).
A partir da década de 80, estes conceitos foram utilizados dentro da área de
computação para documentar padrões de projeto de programação.
Os padrões de projeto são utilizados para mostrar soluções abstratas para
problemas que surgem freqüentemente durante o projeto de sistemas orientado a
objetos. As soluções propostas permitem que compartilhem experiência entre
programadores avançados e novatos. Segundo Gamma [GAM+00], os padrões de
projeto descrevem soluções para problemas que ocorrem com freqüência no
desenvolvimento de software.

10
1.2 Motivação
Devido as especificidade dos padrões de projetos e dos dispositivos móveis, a
compreensão e aplicação das técnicas e métodos de desenvolvimento, requerem
uma maior investigação destas práticas. Em particular, o estudo das possibilidades
que a utilização de padrões de projeto pode oferecer para o desenvolvimento de
interfaces gráficas para aplicativos em dispositivos móveis. Por se tratar de técnicas
incipientes, diversos esforços têm sido realizados no sentido de mensurar possíveis
melhorias, com base em características da orientação objeto, como herança,
reutilização entre outros.
O ambiente para o desenvolvimento de aplicativos para dispositivos móveis é
distinto. A compreensão destas características que o compõe, contribuirá para que a
construção de softwares para esta plataforma seja mais transparente.
O fato da orientação a objetos estar caminhando para sua maturidade,
demonstra que os padrões de projeto é um esforço para este ponto. O estudo e
principalmente a utilização correta dos padrões de projeto, promovem uma melhor
utilização das técnicas de orientação a objetos.
Existe também uma motivação profissional importante. A empresa onde
trabalho atualmente, a Improtec Comercio e Indústria LTDA, desenvolve soluções de
coletores de informação em dispositivos móveis. Este trabalho é um desafio para a
minha capacitação para o desenvolvimento de aplicativos com a qualidade que os
clientes esperam.

11
1.3 Objetivos
O trabalho consiste em demonstrar as possíveis contribuições da aplicação
dos padrões de projeto no desenvolvimento de softwares para dispositivos móveis.
São abordados neste trabalho os padrões de projeto pertinentes ao problema da
elaboração da interface gráfica do aplicativo, com o objetivo de avaliar os padrões
de projeto que possam contribuir para construção de interfaces gráficas adequadas
ao usuário e ao dispositivo móvel. Detalhar como estes padrões devem ser
aplicados e demonstrar a aplicação através de exemplos em código fonte, a fim de
ilustrar sua aplicabilidade.
As observações realizadas durante o trabalho visam verificar as
características da orientação a objetos. Visam também mensurar como a
reusabilidade, encapsulamento e a abstração contribuem para diminuir a
complexidade envolvida neste ambiente.
O dispositivo móvel a ser utilizado neste trabalho é o Pocket PC, modelo
PA962 da Unitech Eletronics Co. Ltd. Serão identificadas as limitações deste
dispositivo e a compreensão de como os padrões de projeto podem contribuir para
amenizar estas dificuldades na elaboração do software. Tais contrbuições visam
possibilitar o desenvolvido de aplicativos de qualidade, oferecendo uma usabilidade
satisfatória para os usuários e respeitando os limites tecnológicos do equipamento.

12
1.4 Metodologia
A metodologia aplicada no desenvolvimento deste trabalho consiste na
experimentação dos padrões de projeto em trechos de código fonte, verificando
assim sua aplicabilidade. É apresentado trecho de código fonte em C#, com padrões
de projetos aplicados, demonstrando a utilidade e praticidade.
Foi adotada uma documentação indireta, já que se trata de uma pesquisa
bibliográfica e descritiva. Baseia-se em fontes secundárias como: livros, teses,
dissertações, artigos, relatórios de pesquisa, sítios de internet e outros documentos
que contribuíram para a concepção do mesmo.
Os exemplos práticos desenvolvidos demonstram possíveis aspectos
positivos e negativos dos padrões de projeto. Estão disponibilizados o código fonte e
os diagramas de classe dos padrões utilizados, tais como os resultados dos
exemplos desenvolvidos.

2 REFERENCIAL TEÓRICO
2.1 Orientação a Objetos
A orientação a objetos é um paradigma de desenvolvimento de software onde
os elementos do código fonte são tratados como objetos. É uma forma de diminuir a
complexidade, abstraindo para o ambiente de desenvolvimento o mundo real
[MAR93]. Todo o objeto tem em comum as característica que o determina, como
atributos e operações. São conceitos importantes para estes paradigmas de
desenvolvimento a identidade, classes, polimorfismo, herança e o encapsulamento.
Os atributos fornecem informações sobre o objeto e suas operações são
ações que podem ser realizadas. Um objeto deve possuir uma identidade para ser
diferenciado [MAR93]. Esta exclusividade garante ao objeto que este será invocado
unicamente. A classificação é utilizada para agrupar objetos que são semelhantes
ou tenham algum relacionamento em sua estrutura e comportamento. Os objetos
podem ser agrupados em classes e estas criam os objetos a serem utilizados.
Os objetos podem interagir com outros objetos. A comunicação entre os
objetos ocorre através de mensagens [MAR93]. Estas são definidas por métodos
que são as operações construídas a partir da especificação das classes.
Segundo Rumbaugh [RUM+94], o polimorfismo significa que a mesma
operação pode atuar de modos diversos em objetos de classes diferentes. A
operação de objetos distintos e com uma identificação igual, realiza ações ou tem
resultados diferentes de acordo com a implementação do método na classe
correspondente.

14
A herança é a capacidade de compartilhar a estrutura e comportamento com
outros objetos [MAR93]. Os métodos herdados podem ser reutilizados e estendidos
de acordo com a necessidade. O acesso e compartilhamento dos objetos dependem
da forma que são empacotados.
Este empacotamento ocorre através do encapsulamento. Um objeto pode ser
capaz de proteger o acesso de suas propriedades, sejam atributos ou métodos, de
outros objetos [RUM+94]. Isto garante a segurança do seu conteúdo que somente
será utilizado por quem realmente precisa e pode utilizar.
Entre algumas das vantagens diretas que podem ser observadas no
desenvolvimento orientado a objetos, está a possibilidade de reutilização de código,
evitando a necessidade de reescrever métodos. Para o desenvolvedor aumenta
capacidade de abstração dos problemas que envolvem o projeto a ser feito, devido
ao fato de caracterizar os componentes deste em objetos com suas propriedades
[MAR93].
Este paradigma também auxilia na comunicação entre equipes de
desenvolvimento e usuários com a utilização de termos menos técnicos. Proporciona
que seja utilizado um padrão conceitual único que nivela o conhecimento entre os
participantes do projeto de desenvolvimento [RUM+94].
2.2 Padrões de Projeto
Os padrões de projeto de software são soluções que podem ser reutilizados
em projetos de desenvolvimento de software orientados a objeto [GAM+00]. A idéia
de reutilizar soluções padronizadas surgiu na década de 70 com Christopher

15
Alexander, para construções de casas. A partir da década de 80, estes conceitos
foram adequados para desenvolvimento de software.
Os padrões de projeto são soluções que foram testadas repetidamente para
um determinado problema que também ocorre repetidamente. A solução é
documentada de uma forma genérica, para que seja reutilizada em problemas
relacionados. Sua utilização leva aos desenvolvedores a adoção de boas práticas de
programação. O conhecimento adquirido por desenvolvedores experientes é
transmitido aos demais, através das soluções padronizadas [GAM+00].
Um padrão de projeto para ser criado é necessário que haja uma
compreensão de um problema que ocorra frequentemente. A partir do entendimento,
possibilita definir a motivação para o padrão a ser utilizado e consequentemente
elaborar uma solução que consiga resolver o problema e também possa ser
reutilizada. Os elementos gerais, segundo a proposta de Gamma [GAM+00], de um
padrão são:
a) O nome do padrão: a identificação do padrão em um nome curto e claro;
b) Objetivo: é o que padrão propõe a fazer;
c) Também conhecido como: outras identificações possíveis para o padrão;
d) Motivação: a descrição do problema e as razões que levam a adoção do
padrão;
e) Aplicabilidade: descreve quando o padrão deve ser utilizado;
f) Estrutura: um diagrama conceitual de como ocorre o relacionamento de
classes e objetos do padrão;
g) Participantes: são as classes e objetos que estão presentes no padrão e
suas responsabilidades;

16
h) Colaborações: descrever como os objetivos serão cumpridos a partir da
relação dos participantes e suas responsabilidades;
i) Conseqüências: descreve os benefícios e possíveis problemas que podem
ser obtidos com a utilização do padrão.
A maior referencia de padrões de projeto é o livro da “gangue dos quatro”
(GoF) [GAM+00]. Descreve 23 padrões de projeto com exemplos dos códigos fonte
em C++ e Smalltalk. Já COOPER [COO02] descrevem os mesmos 23 padrões,
sendo que os exemplos são em código fonte C#.

17
Figura 1 - Relacionamento entre os padrões de projeto – Fonte [GAM+00]
Segundo Gamma [GAM+00], os padrões podem ser classificados de acordo
com suas características. Na Tabela 1 estão todos os 23 padrões e como estão
organizados de acordo com o propósito e escopo. A numeração utilizada ao lado
direito de cada padrão de projeto é a página onde este começa a ser descrita em
seu livro.

18
Propósito
Criação Estruturais Comportamento
Classes Factory Method
(83)
Adapter (108) Interpreter (191)
Template Method
(254)
Escopo
Objetos Abstract Factory
(68)
Builder (75)
Prototype (91)
Singleton (99)
Adapter (108)
Bridge (118)
Composite
(126)
Decorator (135)
Facade (143)
Proxy (161)
Chain of
Responsibility
(173)
Command (182)
Iterator (201)
Mediator (213)
Memento (221)
Flyweight (151)
Observer (229)
State (238)
Strategy (246)
Visitor (259)
Tabela 1 - Organização dos padrões de projeto – Fonte [GAM+00]
A adoção de padrões de projetos na concepção de software permite que seja
criada uma linguagem comum entre os desenvolvedores, difundindo assim a
experiência [GAM+00]. Evita um desperdício de tempo no entendimento do
problema e na elaboração de uma solução. Também facilita a elaboração da
documentação do código fonte resultante.

19
Uma conseqüência é o ganho de produtividade devido à concentração de
esforços nos problemas específicos do ambiente de desenvolvimento. Torna o
código bem elaborado e elegante favorecendo sua extensibilidade e
manutenibilidade [GAM+00], já que estas soluções foram concebidas por
desenvolvedores experientes.
A utilização de padrões de projeto demonstra o nível de maturidade do
desenvolvedor ao paradigma da orientação a objeto [GAM+00]. É necessário que se
conheça bem os padrões de projeto antes de aplicá-los. O uso incorreto resulta em
um código fonte confuso, não contribuindo para resolução do problema, o que
poderá prejudicar o software.
2.3 Interface Gráfica
Uma interface faz a junção de partes distintas, promovendo a integração. Em
um software são as partes nas quais os usuários podem ver, ouvir, tocar por meio do
hardware [GAL03]. A interface de usuário possui dois componentes: a entrada e
saída.
As entradas são como os usuários solicitam alguma tarefa ao computador.
Esta interatividade pode ocorrer de variados meios como o teclado, mouse, caneta
óptica, toque direto a tela (touchscreen) [GAL03].
As saídas são como os computadores respondem a estes estímulos. As
repostas podem ser visuais na tela do computador, auditíveis por dispositivos de
multimídia, analógicos por vibrações mecânicas entre outros meios [GAL03].
É com este paradigma que possibilita a utilização dos computadores, sendo
que todo estímulo do usuário, o computador responde de acordo. Esta relação, entre

20
computadores e usuários, é um campo de estudo conhecido como Humam-
Computer Interaction (HCI) ou interação homem-máquina [GAL03].
A principal preocupação da HCI é elaborar interfaces que não sejam
barreiras que impeçam o usuário de executar suas tarefas e com isto aceitar e
utilizar o aplicativo [GAL03]. Garantir que o usuário utilize confortável e
satisfatoriamente o software, são conceitos referentes à usabilidade do software.
Segundo Nielsen, a usabilidade pode ser definida como: “um atributo de qualidade
que avalia como interfaces de usuário são fáceis de ser utilizada. A palavra
'usabilidade' também se refere os métodos que melhoram o uso do software”
[NIE03B] (tradução nossa).
O conceito das propriedades da usabilidade envolve uma série de
características e ou aspectos para sua compreensão. Todos estes podem ser
mensurados através de testes onde será observado como o usuário está utilizando o
software, através de conversas com o usuário, entrevisto ou testes operacionais e
assim evidenciar a usabilidade. As propriedades da usabilidade, propostas por
Nielsen [NIE93A], são:
a) Facilidade de aprendizagem: é a propriedade que mede o quanto o
sistema é fácil de ser aprendida sua operação. Quanto mais fácil é um
sistema, mais rapidamente o usuário pode utilizá-lo adequadamente;
b) Eficiência: após o usuário ter aprendido suficiente no software, é medida a
sua produtividade;
c) Memorização: é a capacidade de usuários que já utilizaram o sistema e
podem, mesmo após um período sem utilizá-lo, voltar utilizar e
relembrarem de como é a operação;

21
d) Erros: é medido a numero de erros que desvie o usuário do seu objetivo.
São distinguidos os erros simples, nos quais o usuário mesmo o corrige e
os erros referentes a grandes impactos no software prejudicando a tarefa
do usuário;
e) Satisfação: é uma medida subjetiva, já que busca medir o quanto o
usuário considera agradável, confortável a utilização do software.
É necessário que uma interface gráfica bem elaborada auxilie o usuário em
sua tarefa. Seja claro em suas mensagens e informações. Que estimule o usuário a
aprender sobre o aplicativo e diminua o tempo gasto com treinamento e consulta a
manuais. O resultado final esperado é que a interface gráfica de qualidade proverá
uma produtividade elevada do usuário [GAL03].
Uma interface gráfica bem construída, devidamente separada da lógica do
negócio, e da persistência facilitam a manutenibilidade do software pelos
desenvolvedores. A independência proporcionada por esta separação, possibilita
que caso seja necessário modificações no layout da tela, internamente não seja
necessários grandes alterações na lógica do software [BUR97].
A interface gráfica tem uma contribuição fundamental, para o sucesso de um
software. A usabilidade é uma peça importante para este objetivo. Mas acima de
tudo, o importante é compreender o que e como o usuário deseja que software
atenda a sua necessidade [NIE93A].

3 DESENVOLVIMENTO
3.1 DISPOSITIVOS MÓVEIS
Os dispositivos móveis são computadores com características diferentes de
um desktop ou computador de mesa. As dimensões reduzidas, mas contanto com
recursos semelhantes a um computador comum, facilita o seu transporte e uso. Isto
o possibilita de ser utilizado em ambientes diversos e fora do escritório de trabalho.
O dispositivo a ser objeto de estudo deste trabalho será o Pocket PC. O
sistema operacional utilizado pelo Pocket PC é o Windows CE. Outros dispositivos,
como o Palm, Symbiam e seus respectivos sistemas operacionais, não serão
abordados neste trabalho.
3.1.1 Pocket PC
O Pocket PC é um de uma série de dispositivos que utilizam o Windows CE.
Conhecidos também como Handheld, estes dispositivos são fabricados por diversas
indústrias de tecnologia, como HP, Dell e Symbol. Variam em seu formato, tamanho
e recursos, tendo em comum apenas o fato de utilizarem o mesmo sistema
operacional.

23
Figura 2 - Alguns modelos de Pocket PC – Fonte: [MCP03]
O modelo deste estudo é o dispositivo PA962 da empresa Unitech Eletronics
Co. Ltd. Este coletor é mais simples que os modelos da figura acima. É voltado
especificamente para equipes de trabalho, como equipe de venda, indústria,
profissionais que atuam externamente da empresa, utilizando-o como coletores de
informação, como por exemplo: leitura de hidrômetro, consumo de energia elétrica
[GOH03].
A configuração deste coletor é: processador Intel 400MHz, memória Flash
ROM e SDRAM de 64 MB. A tela com dimensões de 240 X 320 pixels e saída de 8
amperes de fone de ouvido. Possuem um teclado alfanumérico de 19 teclas apenas
além das teclas de cursor, ativadores do leitor de código de barras, teclas FUNC,
Backspace, ESC e ENT.

24
Figura 3 - Coletor PA962 – Fonte: [GOH03]
O coletor PA962, como outros dispositivos móveis, possui o touchscreen,
utilizando uma caneta especial que acompanha o equipamento. Um diferencial deste
dispositivo é o seu leitor de código de barras a laser, capaz de identificar todos os
tipos de padrões de código de barra.
O coletor PA962 possui infravermelho integrado ao dispositivo. Possibilidade
de comunicação serial RS232, USB 1.0, comunicação sem fio, WLAN e Bluetooth.
Tem uma autonomia de utilização de aproximadamente de 72 horas.
3.1.2 Windows CE
O Windows CE é um sistema operacional da Microsoft Corporation para
computadores com recursos limitados de memória. Conhecido também com
Windows Mobile, está presente além dos Pocket PC, nos Handhelds e Smartfones,
que são aparelhos de celular com este sistema operacional e em coletores especiais
para atividades profissionais como o PA962.

25
A história do Windows CE começa em 1992, quando a Microsoft começou
desenvolver um sistema operacional para computadores móveis. O objetivo da
Microsoft era integrar estes computadores portáteis com os computadores de mesa
(desktop), ambos utilizando a plataforma WIN32.
Surgiu assim o Winpad. Não possuía um teclado e sim alguns botões, nos
quais fazia o reconhecimento das letras. Era possível fazer a sincronização das
informações do dispositivo móvel com o computador desktop, via comunicação
serial. Devido ao custo elevado, em torno de U$ 900,00 e a lentidão para o
reconhecimento das letras, inviabilizaram o projeto (A Brief History of Windows CE
18 Set 2005, Disponível em: http://www.hpcfactor.com/support/windowsce/).
A segunda tentativa da Microsoft para desenvolver o sistema operacional para
dispositivos móveis, veio com o projeto Pulsar em 1993. Desenvolver um “super
computador de mão”, era uma das metas deste projeto. O Pulsar foi um projeto
posicionado como um produto para consumidor e não para auxiliar nas tarefas
profissionais.
A ausência de teclado físico, já que existia um teclado virtual na tela e seu
pequeno tamanho foram apenas alguns problemas que contribuíram para o
insucesso deste projeto. Os consumidores também não estavam dispostos a pagar
uma taxa mensal de utilização do dispositivo e muito menos tinham a necessidade
de um dispositivo tão complexo.
No ano de 1994, a Microsoft decide reunir os esforços dos dois projetos
iniciais e o nomeia Pegasus. O objetivo é bem definido: este projeto se tornaria um
desdobramento móvel dos computadores desktop, utilizando a plataforma Windows.
Outros objetivos que podem ser destacados: o preço de comercialização já definido

26
que não ultrapassaria de U$ 500,00 e a criação de uma eficiente plataforma de
comunicação e desenvolvimento de aplicações.
Figura 4 - Logomarca de Projeto Pegasus
Fonte: A Brief History of Windows CE.
Disponível em: http://www.hpcfactor.com/support/windowsce/. Acessado em: 18/09/2005;
Dos projetos anteriores, não foi aproveitado o código fonte do Winpad no
Pegasus, para que o novo sistema operacional estivesse adequado à plataforma do
Win32. O código RISC e o Kernel, do projeto Pulsar, foram utilizados como base
para o desenvolvimento do novo projeto (A Brief History of Windows CE 18 Set
2005, Disponível em: http://www.hpcfactor.com/support/windowsce/).
A partir de 1995, o Pegasus passou a adotar a interface gráfica do Windows
95 e em 1996 surgem os primeiros protótipos para testes. Ao lançamento da versão
beta, os desenvolvedores começaram a construir aplicativos para esta plataforma.
Na feira americana de tecnologia, a Comdex, a Microsoft anuncia oficialmente o
projeto Pegasus que depois passou a ser conhecido como Windows CE em sua
versão 1.0.
Hoje, o Windows CE é conhecido como Windows Mobile e é utilizado nos
Pocket PC, Smartfones e Tables PC. Visualmente é semelhante a sistemas
operacionais Windows para desktop. Possui uma API própria e partes da API do
WIN32, presente em todas as versões do Windows de 32 bits e superiores. Além da

27
API, o Windows CE também tem características de multitarefas e
multiprocessamento.
Os desenvolvedores que escrevem programas desktop, em geral, não
encontram dificuldades em criar aplicativos para esta plataforma, devido a esta
familiaridade de plataformas [BAK97]. Porém, devem ser observadas as
particularidades do Windows CE, como o gerenciamento de memória e de arquivo.

3.2 PLATAFORMA DE DESENVOLVIMENTO
A plataforma escolhida para o desenvolvimento é a Visual Studio (VS) .NET.
Este produto desenvolvido pela Microsoft possui um suporte avançado no
desenvolvimento de projetos para dispositivos móveis. Esta característica contribui
para uma integração entre as aplicações dos dispositivos móveis e computadores
desktops da plataforma Windows.
A plataforma VS .NET possibilita a integração da equipe, controlando as
atividades, produtividade, componentes para criar interfaces gráficas, manipulação
de banco de dados e XML. Também oferece recursos para facilitar a criação de
instaladores com toda configuração e segurança oferecida pela plataforma [HUL05].
As principais linguagens da plataforma .NET são o C# e VB. Existe a
possibilidade de converter outras linguagens, como Java, para alguma das
linguagens existentes na plataforma. Neste trabalho, é detalhada a linguagem C#,
utilizada para ilustrar os exemplos de código fonte.
3.2.1 Linguagem C#
A linguagem C# (pronuncia-se como “C Sharp”), é uma linguagem de
programação, disponível na plataforma .NET que foi derivada das linguagens C/C++.
É orientada a objetos, ao desenvolvimento de componentes e fortemente tipada.
Possibilita utilização de ponteiros, na execução de código não gerenciado.
Originalmente, o C# começou a ser distribuído juntamente com Microsoft
Visual Studio e permitia o acesso a toda a plataforma do NGWS (Next Generation

29
Windows Services). Incluem a biblioteca de classes e um mecanismo de execução
comum da plataforma WIN32.
O C# é a linguagem nativa para Visual Studio .NET que possui o Common
Language Runtime (CLR). Este é o mecanismo de execução da plataforma .NET e
possibilita a convivência com diversas outras linguagens, desde que estejam
previamente especificadas pela Common Language Subset (CLS). Exemplificando,
caso uma classe base seja escrita em C#, pode ser utilizada em Visual Basic
[GAL05].
O .NET Common Language Runtime é um ambiente baseado em
componentes e o C# foi concebido com o intuito de facilitar o desenvolvimento
destes. A documentação pode ser descrita dentro dos próprios componentes e
posteriormente exportada para um arquivo XML, criando assim uma portabilidade
eficiente. O C# não requer as bibliotecas de tipo, arquivos de cabeçalho ou arquivos
IDL. Os componentes criados em C# são autodescritivos, não fazendo necessária à
necessidade do processo de registro.
No C#, ao contrário de linguagens também orientadas a objeto como o Java
ou o C++, os tipos de dados podem se interagir. Também fornece um sistema
unificado de tipos, onde todos são tratados como objetos, sem que ocorra alguma
perda de desempenho [GAL05].
Possui ainda: o coletor de lixo (Garbage Collection) que fornece o
gerenciamento automático de memória, exceções (Exceptions) que dispara erros
que podem ser tratados, segurança no tipo de dados (Type-safety) que assegura a
manipulação de variáveis e versão (Versioning), são alguns recursos encontrados na
linguagem para construção dessa categoria de software. Permite interoperabilidade

30
com XML, SOAP, componentes COM, DLL e qualquer outra linguagem da
plataforma .NET, mantendo integração com projetos existentes.
A plataforma do VS .NET possui recursos interessantes o para criação de
aplicativos nos diversos tipos de segmentos na plataforma Windows. A partir do
momento que se cria um novo projeto, seja para dispositivos móveis ou desktop, já
habilita um formulário em branco para ser desenvolvida a interface gráfica.
Os componentes gráficos como campos de edição, botões e outros, podem
ser organizados com facilidade pelo desenvolvedor no formulário.
Conseqüentemente, os comportamentos já podem ser adicionados aos
componentes selecionados. Estas características contribuem para a produtividade,
uma vez que estes recursos já estão disponíveis para utilização.

3.3 PADRÕES DE PROJETO APLICADOS AO DESENVOLVIMENTO
Um sistema de inventário será utilizado para exemplificar a aplicação dos
padrões de projeto. Este tipo de sistema faz o levantamento de todo equipamento de
uma organização, com o objetivo de controlar a utilização dos recursos pela equipe.
E como qualquer outro sistema a ser construído, possui desafios a serem
superados.
Uma das opções para diminuir as possíveis dificuldades na construção destes
aplicativos, é a escolha do paradigma de programação orientação a objetos. Esta
definição de desenvolvimento permitiu a utilização de padrões de projeto. A adoção
dos padrões de projeto, que são soluções comprovadas de boas práticas de
desenvolvimento, aproveita características positivas da orientação a objetos, como a
abstração e a reusabilidade.
A utilização de padrões de projeto no desenvolvimento de interface gráfica é o
objeto de estudo deste trabalho. É demonstrada a contribuição da utilização de
alguns dos 23 padrões propostos por Gamma [GAM+00], no desenvolvimento de
interfaces gráficas. Os padrões de projeto a serem utilizados, foram selecionados
criteriosamente após análise das características que melhor se adaptavam a este
cenário de desenvolvimento.
O padrão MVC (Model-View-Controller) [BUR97] foi utilizado no projeto
arquitetural. Este padrão divide o sistema em camadas, separando a interface
gráfica das regras de negócio e persistência. A separação em camadas
proporcionada pelo padrão MVC resulta em uma grande mobilidade no
desenvolvimento de aplicativos. As alterações podem ser feitas na camada da

32
interface gráfica ou apresentação, com pouco ou até mesmo nenhuma modificação
que necessite ser realizada no restante do sistema.
Figura 5 - Diagrama do Padrão MVC
A camada View é responsável pela apresentação do aplicativo onde a
interface gráfica será construída. É nesta camada que os padrões de projeto
selecionados para o trabalho serão aplicados.
Os padrões selecionados foram o Singleton, Factory Method, Decorator e
State. Alguns destes padrões contribuíram não somente com a construção da
interface gráfica, como também no controle de restrições que envolvem os
dispositivos móveis, em principal a limitação de memória.
Algumas características devem ser observadas na elaboração de interfaces
gráficas em dispositivos móveis. Existe a preocupação com a quantidade de
informações a serem exibidas. Deve se evitar que prejudique a usabilidade e
compreensão do usuário das informações do aplicativo. Também devem ser
observadas e respeitadas as limitações físicas da tela dos dispositivos móveis.
Os próximos itens deste trabalho descrevem os padrões de projeto
selecionados. É descrita a característica que motivou a escolha, o diagrama de
classe exibindo a estrutura do padrão e o exemplo de código fonte com o seu
respectivo diagrama de classe, demonstrado a aplicabilidade.

33
3.3.1 Singleton
Segundo Gamma [GAM+00], o objetivo do padrão Singleton é garantir que
uma classe tenha somente uma instância e fornecer o ponto global de acesso à
mesma. No que diz respeito ao desenvolvimento de interfaces gráficas, é de
interesse manter um único objeto correspondente à classe referente, pois esta é
constantemente atualizada exibindo informações ao usuário de quantos
equipamentos foram coletados, localização e o último equipamento lido.
A utilização deste padrão evita que sejam instanciados novos objetos de
interface gráfica na memória. Devido à limitação de memória dos Pocket PC, deve-
se evitar o desperdício de memória com a alocação de objetos, dispensando a
dependência explícita do coletor de lixo (Garbage Collection) para recolher objetos
que não estão sendo utilizados e assim liberar memória para utilização.
Singleton
-uniqueInstance:Singleton
#Singleton:void
+getInstance:Singleton return uniqueInstance;
Figura 6 - DIAGRAMA DE CLASSE: SINGLETON - Fonte: [GAM+00] (Adaptado)
O exemplo abaixo demonstra a utilização do padrão Singleton. A utilização do
método Instance(), garante que será utilizada uma única instância da classe
FrmInvent e disponibiliza um ponto global de acesso. Este método verifica se o

34
objeto está instanciado e em caso negativo, cria uma nova instancia. Caso o objeto
já esteja instanciado, retorna a instância atual para o solicitante para ser utilizada.
A classe FrmInvent é a definição do formulário principal do sistema de
inventário. Este formulário, durante a execução do aplicativo é atualizado ao fim de
cada operação de usuário. O padrão Singleton permite que a mesma instância do
objeto da classe FrmInvent seja utilizada e atualizada ate o encerramento do
software.
class FrmInvent {
private static FrmInvent frmInv;
protected FrmInvent()
{
}
public static FrmInvent Instance()
{
// Utilizando a inicializacao preguiçosa
// ou 'Lazy initialization'
if (frmInv == null)
{
frmInv = new FrmInvent();
}
return frmInv;
}
public void addInvent()
{
while (!sair)
{
// Utilizando o SINGLETON
FrmInvent frmTemp = getInstancia();
// A unica instancia: frmTemp
}
}
}
O padrão Singleton utilizada a técnica da inicialização tardia (lazy
initialization), permitindo que na instanciação verifique se o objeto já esta
instanciado. Abaixo, o diagrama da classe FrmInvent com o padrão de projeto
aplicado.

35
Figura 7 - DIAGRAMA DE CLASSE: Exemplo do Singleton
3.3.2 Factory Method
O padrão Factory Method tem como objetivo segundo Gamma [GAM+00],
definir uma interface para criar um objeto, mas deixar as subclasses decidirem que
classe instanciar. Este padrão possibilita que a instanciação de um objeto seja
adiada por uma subclasse e seja criado no momento mais apropriado.
A utilização permite delegar a responsabilidade pela criação dos objetos a
subclasses, já que estas o especificam, através de parâmetros. Com isto o padrão
pode gerenciar a criação dos objetos que estejam agrupados em uma hierarquia.
Figura 8 - DIAGRAMA DE CLASSE: FACTORY METHOD - Fonte: [GAM+00]

36
O exemplo a seguir utiliza o padrão Factory Method para construir
dinamicamente de telas informativas. Serão construídos utilizando o Message
Dialog, que são telas utilizadas para confirmar uma ação em um aplicativo. Será
solicitado ao usuário que confirme a ordem de inclusão ou exclusão de uma coleta já
realizada.
As Message Dialog serão selecionadas a partir do parâmetro informado na
chamada do método GetMsgDlg(int type). As subclasses passam a ser
responsáveis pela criação dos objetos, reunidos em um único ponto de criação. A
instanciação do objeto das subclasses de MsgDlg acontecerá no momento que for
realmente necessária. Após o código fonte de exemplo, encontra-se o diagrama de
classe correspondente, com o padrão de projeto aplicado.
Classe Factory
class FactoryMsgDlg{
public MsgDlg GetMsgDlg(int type)
{
switch(type) //Decide qual o objeto a ser criado
{
case 1:
return new MsgDlgExclude();
break;
case 2:
return new MsgDlgInclude();
break;
}
}
}
// Classe CREATOR
abstract class MsgDlg{
}
// Classes Concretas
class MsgDlgExclude : MsgDlg{
}
class MsgDlgInclude : MsgDlg{
}

37
class Cliente{
public static void Main(){
FactoryMsgDlg fact = new FactoryMsgDlg();
//Seleciona qual cx de dialogo deve ser produzida
MsgDlg md = fact.GetMsgDlg(2);
md.creatorMsgDlg();
}
}
FactoryMsgDlg
+GetMsgDlg:MsgDlg
MsgDlgExclude
MsgDlg
MsgDlgInclude Cliente
+Main:void
Figura 9 - DIAGRAMA DE CLASSE: Exemplo Factory Method
3.3.3 Decorator
A principal intenção do padrão Decorator é, segundo Gamma [GAM+00],
agregar dinamicamente responsabilidades adicionais a um objeto. É um importante
padrão de projeto no desenvolvimento de interfaces gráficas, em destaque nos
dispositivos móveis, para manter objetos enxutos, sem que haja a necessidade de
adicionar recursos desnecessários para uma classe.
As responsabilidades adicionadas podem ser removidas, quando não mais
necessárias. Esta característica proporciona uma maior flexibilidade e coerência já
que uma nova funcionalidade somente será implementada e utilizada quando for
realmente necessário.

38
A adição e remoção destas funcionalidades são transparentes para o cliente.
Estas ações não afetam o código contido no cliente e este continua trabalhando com
a interface gráfica fornecida inicialmente.
Figura 10 - DIAGRAMA DE CLASSE: DECORATOR - Fonte: [GAM+00]
No exemplo abaixo, é aplicado o padrão Decorator para manipularem
componentes a ser utilizado na classe Formulário. O método draw() é redefinido
por cada classe de um componente específico e na subclasse Decorator, herdando
assim as demais implementações [GAM+00].
abstract class Formulario{
public abstract void Draw();
}
class ConcreteComponent : Formulario{
public override void Draw(){
}
}

39
// Decorador
abstract class Decorator : Formulario{
protected Formulario form;
public void SetFormulario(Formulario form){
this.form = form;
}
if (form != null)
{
form.Draw();
}
}
}
class ProgressBar : Decorator{
private string valor;
}
public string getValor() {
}
}
class StatusBar : Decorator{
private string msg;
}
public void setMsg(string texto){
}
}
class MainApp{
static void Main() {
Formulario frm = new Formulario();
ProgressBar pbar = new ProgressBar();
StatusBar sbar = new StatusBar();
// Utilizando os decoradores
pbar.SetComponent(frm);
sbar.SetComponent(pbar);
sbar.Operation();
}
}

40
A aplicação do Decorator é realizada na classe MainApp. Após a criação dos
objetos das classes ConcFormulario, StatusBar e ProgressBar, os objetos podem
ser adicionados ao objeto componente (ConcFormulario) e quando necessários,
removidos. Abaixo, o diagrama de classe do código fonte do exemplo da aplicação
do padrão de projeto.
form
Decorator
#form:Formulario
+SetFormulario:void
+Draw:void
ConcFormulario
+Draw:void
ProgressBar
-valor:string
+Draw:void
+getValor:string
StatusBar
-msg:string
+Draw:void
+setMsg:void
Formulario
+Draw:void
Figura 11 - DIAGRAMA DE CLASSE: Exemplo Decorator
Os objetos definidos desta subclasse podem ter propriedade definida
dinamicamente, utilizando a característica do padrão Decorator. Devido esta
independência, os objetos podem ser instanciados diretamente e a propriedade é
transparente a possíveis clientes.

41
3.3.4 State
Segundo Gamma [GAM+00], o objetivo deste padrão é permitir a um objeto
alterar seu comportamento quando o seu estado interno muda. O cliente que esta
utilizando o objeto no momento, terá a impressão que este foi alterado para uma
outra classe.
A utilização deste padrão torna-o interessante para a construção de interfaces
gráficas. O formulário passa a ser construído de acordo com o estado que se
encontra. Esta característica facilita a manutenção dos estados. Outra característica
é que os objetos resultantes do padrão State podem ser compartilhados [GAM+00].
Figura 12 - DIAGRAMA DE CLASSE: STATE - Fonte: [GAM+00]
O exemplo abaixo demonstra a utilização do padrão State. Para o sistema de
inventário, existem dois tipos de usuários: os coletores que realizam a atividade de
coleta e os auditores que certificam as coletas realizadas. Os dois usuários utilizam
à mesma informação do sistema, mas em interfaces gráficas diferentes.
A criação de uma classe genérica State oferece um contrato para ser
utilizado na elaboração da interface gráfica. As classes concretas que herdam estas

42
características implementam de forma independente o que é necessário para a
interface gráfica do seu estado.
// A classe do Padrao STATE
abstract class State{
abstract public void Initialize();
abstract public void addField(State state);
abstract public void addDataGrid(State state);
abstract public void addRollBar(State state);
}
class Coletor : State{
public Coletor( State state) {
this.form = state.form;
Initialize();
}
override public void Initialize() {
// inicilizando campos
}
override public void addField( State state) {
// Adicionando campos para o formulario
}
override public void addRollBar( State state ) {
// Adicionando barra de rolagem ao formulario
}
override public void addDataGrid( State state ) {
// Adicionando DataGrid ao formulario
}
}

43
class Auditor : State{
public Auditor( State state ) {
this.form = state.form;
Initialize();
}
override public void Initialize() {
// inicilizando campos
}
override public void addField( State state ){
// Adicionando campos para o formulario
}
override public void addRollBar( State state ){
// Adicionando barra de rolagem ao formulario
}
override public void addDataGrid( State state ){
// Adicionando DataGrid ao formulario
}
}
class Formulario{
// Constructor, seleciona o STATE
public Formulario(State state){
this.state = state;
}
private State state;
public void Request(){
state.Initialize(this);
}
}
Após a seleção do estado de usuário a ser utilizado, é acionado o método
Request(). Este, por sua vez, aciona o método Initialize(), responsável pela
construção da interface gráfica referente. Abaixo, a representação no diagrama de
classe do exemplo do padrão de projeto.

44
Figura 13 - DIAGRAMA DE CLASSE: Exemplo STATE

4 CONCLUSÃO
A interface gráfica dever ser observada com sua devida importância. Deve
proporcionar ao usuário uma usabilidade satisfatória do aplicativo. Na ótica do
ambiente de dispositivos móveis, esta característica é rigorosa e importante. E estes
estão cada vez mais presentes no ambiente profissional. Em muitas organizações
passou a ser um recurso de trabalho fundamental.
Neste ambiente, torna favorável para que o desenvolvimento seja aprimorado
e incentivado. O universo da orientação a objetos favorece também uma
aproximação do mundo real com o computacional. Contribui para um
desenvolvimento seja mais próximo da realidade do usuário.
Aos desenvolvedores, cabe saber como se adequar à diversidade deste
ambiente. Os padrões de projetos é um bom caminho, como demonstrado no
trabalho, para diminuir as possíveis dificuldades e ganhar em produtividade no
desenvolvimento de aplicações. Contudo, devem ser utilizados com cuidado. Não
garantem que um aplicativo seja perfeito, independente da plataforma ou
equipamento disponível. São apenas propostas de soluções comprovadas que
podem ser utilizadas em software desenvolvido sobre o paradigma da orientação a
objetos.
A contribuição da utilização dos padrões de projeto contribui para diminuir
possíveis dificuldades encontradas no processo de construção de aplicativos.
Possibilita a transferência de conhecimento de desenvolvedores experientes para
novatos, proporcionando um nivelamento de conhecimento e comunicação entre os
envolvidos. O fato dos padrões de projeto ser soluções reutilizáveis é um
incentivador para um estudo profundo.

46
Neste trabalho, os padrões de projeto aplicados contribuíram na construção
de uma interface gráfica, flexível e enxuta. A preocupação com as limitações físicas
da tela e de memória foi levada em conta no estudo e testes realizados no decorrer
do trabalho.
O código fonte resultante dos padrões de projeto aplicados proporcionou uma
melhor legibilidade dos desenvolvedores envolvidos. A solução proposta
demonstrou-se útil neste paradigma de dispositivos móveis, em especial, na
construção de interfaces gráficas.
Sugiro, como continuidade deste trabalho, o estudo da utilização dos demais
padrões de projeto para a concepção de interfaces gráficas para dispositivos móveis.
Também identificamos como temática interessante para a evolução deste trabalho o
estudo do que a literatura chama de antipadrões para desenvolvimento de
aplicativos e sua aplicação em dispositivos móveis
Igualmente relevante para desenvolvimentos futuros deste trabalho seria a
abordagem de padrões de projeto por camadas. A semelhança da plataforma J2EE
deveríamos investigar se a separação de camadas influencia também a aplicação de
padrões de projeto para o desenvolvimento de sistemas móveis.

47
5 REFERÊNCIAS BIBLIOGRÁFICAS
[BAK97] BAKER, Jeff. Windows CE Application Programming. 1 ed. Indianapolis,
EUA: Macmillan Technical Publishing, 1997
[BER00] BERNREUTHER, M. A short introduction to GUI programming with the
MVC concept using wxWindows, 2000
[BRJ00] BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML: guia do
usuário. Tradução Fábio Freitas da Silva. Rio de Janeiro: Campus. 10 ed.
2000.
[BUR97] BURBECK, Steve. Applications Programming in Smalltalk-80(TM):
How to use Model-View-Controller (MVC). Disponível em: http://st-
www.cs.uiuc.edu/users/smarch/st-docs/mvc.html. Acessado em: 02/10/2005;
[CJR05] CAMPOS JR, Roberto de Oliveira. Padrões de Projetos aplicados ao
Desenvolvimento de Sistemas para Dispositivos Móveis. Monografia para
obtenção do título de bacharel em Sistema de Informação PUC-MG.
Contagem, 2005;
[CLE97] CORAM, Todd LEE, Jim. Experiences - A Pattern Language for User
Interface Design. Disponível em:
http://www.pobox.com/~tcoram/papers/experiences/Experiences.html.
Acessado em: 18/09/2005;
[COO02] COOPER, James W. Introduction to Design Patterns in C#. IBM T J
Watson Research Center. 2002;
[GAL03] GALITZ, Wilbert O. The Essential Guide to User Interface Design. Wiley
Publishing, Inc., Indianapolis, EUA. Second Edition, 2003;

48
[GAL05] GALUPPO, Fábio. Conhecendo C# - Lição 1 – Hello C#. Disponível em:
http://www.microsoft.com/brasil/msdn/Tecnologias/visualc/Default.mspx,
Acessado em: 23/09/2005;
[GAM+00] GAMMA, Erich, et al, Padrões de Projeto, Soluções Reutilizáveis de
Software Orientado a Objetos. Tradução Luiz Augusto Meirelles Salgado.
Porto Alegre: Bookman, 2000.
[GOH03] GOH, Yukiko. PA960 Operantion Manual. Manual do usuário do coletor
PA960. Unitech Electronics Co., Ltd, 2003.
[GOM05] GOMES, Wander Euclides Carneiro Pimentel. Uma Plataforma de
Desenvolvimento de Software Baseado em Componentes para
Dispositivos Móveis. Dissertação de Mestrado apresentada para obtenção
do título de Mestre em Engenharia Elétrica. Faculdade Computação
UNICAMP. Rio de Janeiro: 2005.
[HAD05] HADDAD, Renato.10 Razões para adotar o Visual Studio .NET 2005.
Disponível em:
http://www.microsoft.com/brasil/msdn/Tecnologias/vsnet/10RazoesParaAdotar
VS2005.mspx, Acessado em: 23/09/2005;
[HOL94] HOLANDA, Aurélio Buarque de. Dicionário Aurélio Básico da Língua
Portuguesa. Rio de Janeiro: Ed Nova Fronteira. 1994.
[HUL05] HULOT, Carlos. Visual Studio. Disponível em:
http://www.microsoft.com/brasil/msdn/Tecnologias/vsnet/VStudioCarlosHulot.
mspx Acessado em: 23/09/2005;
[KUT02] KUTOVA, Marcos. Interface Homem-Máquina. Apostila da disciplina de
Interface Homem Máquina do curso de Sistemas de Informação, PUC-MG.
Contagem, 2002;

49
[LAR04] LARMAN, Craig. Utilizando UML e padrões: uma introdução à análise e
ao projeto orientado a objetos e ao Processo Unificado. Tradução Luiz
Augusto Meirelles Salgado e João Tortello. Porto Alegre: Bookman. 2 ed.
2004.
[LAV03] LABERGE, Robert VUJOSEVIC, Srdjan. Building PDA Databases for
Wireless and Mobile Development. Wiley Publishing, Inc., Indianapolis,
EUA. 2003;
[MAR93] MARTIN, James. Princípios de Análise e Projeto Baseados em
Objetos. Tradução: Cristina Bazán. Rio de Janeiro: Campos. 6º Tiragem,
1993
[MCP03] MCPHERSON, Frank. How to Do Everything with Your Pocket PC. 3 ed.
California, EUA. 2003;
[MJR04] MOURÃO JR., Ernandes. Projeto de Aplicações Para Dispositivos
Móveis. Monografia para obtenção dos créditos da disciplina: Trabalho de
Conclusão, Curso do Centro de Ciências Tecnológicas da Universidade de
Fortaleza. Fortaleza: 2004;
[NIE03A] NIELSEN, Jakob. Usability Engineering. Academic Press. EUA. 1993;
[NIE03B] NIELSEN, Jakob. Usability 101: Introduction to Usability. AlertBox
Disponível em: http://www.useit.com/alertbox/20030825.html. Acessado em:
21/09/2005;
[RUM+94] RUMBAUGH, James, et al,. Modelagem e Projetos Baseados em
Objetos. Tradução Dalton Conde de Alencar. Rio de Janeiro: Campos. 11º
Tiragem, 1994;
[TSO05] T. de SOUZA, Gabriela et. Al, Aplicação de metapadrões e padrões em
desenvolvimento de software para sistemas de informação. 5º

50
Conferencia Latino-Americana em Linguagens de Padrões de Programação –
SugarloafPLoP. Campos do Jordão,16 a 19 de Agosto de 2005;
[WAK98] WAKE, William C. Patterns for Interactive Applications. Disponível em:
http://hillside.net/plop/plop98/final_submissions/P44.html Acessado em:
15/09/2005;
A Brief History of Windows CE. Disponível em:
http://www.hpcfactor.com/support/windowsce/. Acessado em: 18/09/2005;
Model-View-Controler. Disponível em:
http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/dnpatterns/html/DesMVC.asp. Acessado em: 02/10/2005;
Data & Object Factory - Design Patterns. Disponível em:
http://www.dofactory.com/Patterns/Patterns.aspx Acessado em: 04/09/2005;

Graduação puc - aplicações de padrões de projeto no desenvolvimento de interfaces gráficas de dispositivos móveis

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Andere mochten auch

Andere mochten auch (6)

Ähnlich wie Graduação puc - aplicações de padrões de projeto no desenvolvimento de interfaces gráficas de dispositivos móveis

Ähnlich wie Graduação puc - aplicações de padrões de projeto no desenvolvimento de interfaces gráficas de dispositivos móveis (20)

Graduação puc - aplicações de padrões de projeto no desenvolvimento de interfaces gráficas de dispositivos móveis