DESENVOLVIMENTO MOBILE

Aula 01

Ciclo de vida de desenvolvimento de

um aplicativo móvel e de um WebApp
por Marino Hilário Catarino

1
 Anotações do slide anterior

Bem-vindos à nossa segunda aula!

Nesta aula falaremos sobre o ciclo de vida de desenvolvimento de um aplicativo móvel e
de um WebApp.

2
Objetivo

Apresentar o ciclo de vida de desenvolvimento de um aplicativo móvel

e de um WebApp, passando pela modelagem de requisitos, pelo projeto
de arquitetura e pelo projeto de interface. Mostrar a aplicação desses
conceitos em um exemplo real.

3
 Anotações do slide anterior

Nesta aula iremos nos aprofundar sobre o desenvolvimento dos dispositivos móveis.
Apesar de não ser somente um sistema operacional, o ciclo de vida para o
desenvolvimento de um aplicativo para um dispositivo móvel é bem similar.
Veremos sobre a modelagem de requisitos e o projeto de arquitetura e abordaremos a
interface.
Ao fim da aula teremos uma aplicação dos conceitos e um exemplo real.

4
Conteúdo

Ciclo de vida de um desenvolvimento de um aplicativo móvel e app:

 Modelagem de requisitos para WebApps e aplicativos móveis:
modelo de conteúdo, modelo de interação, modelo funcional,
modelo de configuração e modelo de navegação.
 Projeto de arquitetura para WebApps e para aplicativos móveis.
 Projeto de interface para WebApps e para aplicativos móveis.

5
 Anotações do slide anterior

O conteúdo da aula foi organizado dessa forma a fim de alcançar o objetivo proposto. Ao
longo do estudo do ciclo iremos conhecer a modelagem de requisitos para WebApps e
aplicativos móveis: modelo de conteúdo, modelo de interação, modelo funcional, modelo
de configuração e modelo de navegação. Também veremos o projeto de arquitetura para
WebApps e para aplicativos móveis e o projeto de interface para WebApps e para
aplicativos móveis.

6
Ciclo de vida: modelagem de requisitos
para WebApps e aplicativos móveis

7
 Anotações do slide anterior

Nesta seção acompanharemos a modelagem de requisitos para WebApps e aplicativos

móveis e, para isso, conheceremos os diferentes modelos existentes: modelo de
conteúdo, modelo de interação, modelo funcional, modelo de configuração e modelo de
navegação.

8
Modelagem de requisitos
 Modelo de conteúdo;
ENTRADA
 Modelo de interação;
 Informações obtidas  Modelo funcional;
durante a atividade
de comunicação.  Modelo de navegação;
 Modelo de configuração.

SAÍDA

9
 Anotações do slide anterior
A análise de requisitos fornece um mecanismo disciplinado para representar e avaliar o
conteúdo e função de uma WebApp, os modos de interação que os usuários irão encontrar
e o ambiente e a infraestrutura em que a WebApp reside. Cada uma dessas características
pode ser representada como um conjunto de modelos que permite que os requisitos da
WebApp sejam analisados de maneira estruturada, embora os modelos específicos
dependam em grande parte da natureza da WebApp.
É mais custoso corrigir um software do que levantar os requisitos iniciais. Com isso a
modelagem de requisitos pode ser abordada considerando a entrada da modelagem de
requisitos e a saída.
Entrada da modelagem de requisitos
Em relação à entrada da modelagem de requisitos, temos que, apesar de a atividade de
comunicação ser fundamental para a elaboração de um projeto, são necessários
refinamentos dessa compreensão com interpretações adicionais. Conforme a evolução da
estrutura do problema devem surgir novas perguntas que precisam ser respondidas. O
preenchimento dessas lacunas é muito importante.
Em resumo temos que as entradas para o modelo de requisitos são as informações
obtidas e coletadas durante a atividade de comunicação, sendo essa atividade realizada
por uma descrição de projeto detalhada com cenários de uso e especificações de produto
completas até o conteúdo trocado por mensagens de e-mail.
Saídas da modelagem de requisitos
Devido à análise de requisitos, obtemos um mecanismo disciplinado que representa e
possibilita avaliar o conteúdo e a função de uma aplicação, além das interações entre os
usuários e o ambiente e a infraestrutura em que a aplicação se encontra. Conforme
Pressman (2011) temos que cada uma dessas características pode ser representada
como um conjunto de modelos que possibilitam uma análise de forma estruturada. Os
cinco modelos principais são (PRESSMAN, 2011):
• Modelo de conteúdo — identifica todo o conteúdo a ser fornecido pela WebApp, sendo
que o conteúdo pode ser texto, gráfico, imagem, vídeo e áudio.
• Modelo de interações — descreve a maneira pela qual os usuários interagem com a
WebApp.
• Modelo funcional — define as operações que serão aplicadas ao conteúdo da WebApp
e descreve outras funções de processamento independentes do conteúdo, mas
necessárias para o usuário final.
• Modelo de navegação — define a estratégia geral de navegação para a WebApp.
• Modelo de configuração — descreve o ambiente e a infraestrutura na qual a WebApp
reside.
10
Modelo de conteúdo:
 Apresenta todos os elementos que o
WebApp irá apresentar,
independentemente do tipo. Por
exemplo: imagem, gráfico, texto, aúdio;
 Os objetos de conteúdo (componentes)
podem ser definidos pelos casos de uso
do aplicativo;
 Pode ser representado por uma lista
dos componentes contendo uma
descrição de cada objeto;
 A elaboração pode ser antes, durante ou
depois que o WebApp foi desenvolvido.

11
 Anotações do slide anterior

Apresenta todos os objetos de conteúdo que se encontraram no WebApp. Esses objetos

de conteúdo são chamados de componentes e podem ser texto, vídeo, gráfico, de
qualquer forma. Ou seja, são os elementos estruturais que dão uma visão importante dos
requisitos de conteúdo para uma aplicação em plataforma web e plataforma para
aplicativos móveis.

O modelo de conteúdo tem como objetivo descrever o objeto de conteúdo Componente. A

representação pode ser bem simples, como uma lista dos componentes e uma breve
descrição deles. O modelo de conteúdo pode ser elaborado em qualquer etapa do
desenvolvimento do WebApp, antes, durante e depois, como manutenção.

Esse modelo contém os objetos de conteúdo e todas as classes de análise, que são as
entidades visíveis aos usuários, que conforme o usuário interage com o aplicativo, são
criadas e manipuladas.

O objeto de conteúdo pode ser identificado por meio de análises da descrição do cenário
para referências diretas e indiretas ao conteúdo e obtidos dos casos de uso.

12
Modelo de interações:
 Apresenta a forma com que o usuário
interage com o WebApp;
 Descrito por meio de casos de uso;
 Para interações mais complexas é
melhor apresentar de forma
esquemática: diagramas de sequência,
diagramas de estados e/ou protótipos
de interfaces do usuário.

13
 Anotações do slide anterior

O modelo de interação apresenta a forma com que o usuário se relaciona com o WebApp.
A grande maioria das WebApps possibilita um “diálogo” entre o usuário final e a
funcionalidade da aplicação, o conteúdo e o comportamento de uma aplicação. Esse
diálogo pode ser descrito por meio de um modelo de interações que pode ser composto
por um ou mais dos seguintes elementos: (1) casos de uso, (2) diagramas de sequência,
(3) diagramas de estados, e/ou (4) protótipos de interfaces do usuário.

Existem situações em que o conjunto de casos de uso é o suficiente para descrever a

interação em um nível de análise. Contudo em situações em que a sequência de interação
for mais complexa e também envolver várias classes de análise ou muitas tarefas, é
indicado fazer a representação usando uma forma esquemática mais rigorosa.

Para se criar um protótipo de interface devemos implementar os principais links de

navegação e então representar o layout da tela. Por exemplo, caso o sistema possua três
funcionalidades principais acessadas pelo usuário, então temos que ter um protótipo que
as represente, porque na aplicação final vai ser assim que o usuário vai ver o aplicativo. O
mesmo com o menu de navegação, com links, tudo deve estar representado no protótipo
como deve ficar na versão de produção.

14
Modelo funcional:
 São as funções que ocorrem conforme
o usuário interage com algum conteúdo
do WebApp, como exemplo reproduzir
um vídeo;
 Também apresenta funcionalidades
internas que estão relacionadas às
necessidades do usuário, porém sem
relação direta com algum conteúdo;
 Esse modelo trata de dois níveis de
funcionalidade: as acessíveis pelo
usuário e as internas, que se encontram
nas implementações.

15
 Anotações do slide anterior

Todas as funcionalidades observáveis pelos usuários englobam quaisquer funções de aplicativos móveis ocorre não na funcionalidade fornecida, mas na
processamento iniciadas diretamente pelo usuário. Um WebApp financeiro poderia natureza das informações que podem ser acessadas e nas
implementar uma série de funções financeiras (por exemplo, uma calculadora de crédito maneiras pelas quais podem ser manipuladas.
educativo para o ensino superior ou uma calculadora para planos de aposentadoria).
Essas funções poderiam, na verdade, ser implementadas usando-se operações dentro das • Uma aplicação da funcionalidade da Web CasaSegura poderia ocorrer com o
classes de análise, porém, do ponto de vista do usuário final, a função (mais desenvolvimento de um aplicativo móvel que desse acesso ao sistema CasaSegura a
precisamente, os dados fornecidos pela função) é o resultado visível. partir de um smartphone ou tablet.
• Os requisitos de conteúdo e funções de um aplicativo móvel para
CasaSegura poderiam ser semelhantes a um subconjunto daqueles
• Muitas aplicações em plataforma web e plataforma de aplicações móveis oferecem fornecidos pela web, mas requisitos de interface e segurança
uma ampla gama de funções computacionais que podem ser associadas diretamente específicos precisam ser estabelecidos.
ao conteúdo.
• Podemos identificar os elementos
• (1) Funcionalidade observável pelo usuário – engloba quaisquer
funções de processamento iniciadas diretamente por eles. Exemplo:
um aplicativo móvel financeiro poderia implementar uma variedade
de funções financeiras. Essas funções poderiam ser implementadas
usando-se operações dentro das classes de análise, porém, do
ponto de vista do usuário, a função é o resultado visível.
• (2) Operações contidas nas classes de análise que implementam
comportamentos associados à classe.
• Independentemente do nível de abstração procedural, o diagrama de atividades UML
pode ser utilizado para representar detalhes do processamento.
• No nível de análise, os diagramas de atividades devem ser usados
apenas quando a funcionalidade é relativamente complexa.
• Grande parte da complexidade de muitas aplicações web e

16
Modelo de navegação:
 A forma como o usuário irá navegar no
WebApp é tratada neste modelo. Como
ele vai de um componente para outro,
por exemplo;
 Todas as possibilidades do usuário
devem ser tratadas, inclusive
mensagens de erro;
 Pode apresentar um “mapa do WebApp”
ou um “tour guiado” percorrendo os
principais elementos.

17
 Anotações do slide anterior

O modelo de navegação considera a maneira como cada categoria de usuário irá navegar
de um elemento do WebApp (por exemplo, objeto de conteúdo) para outro. A mecânica de
navegação é definida como parte do projeto. Nesse estágio, devemos nos concentrar nos
requisitos gerais de navegação. Por exemplo, será fornecido um “mapa do site” para dar
aos usuários uma visão geral de toda a estrutura da WebApp? Será possível um usuário
fazer um “tour guiado” que destacará os elementos mais importantes (objetos de
conteúdo e funções) disponíveis?

18
Modelo de configuração:

 Descreve o ambiente e os requisitos de

infraestrutura necessários para o
WebApp;
 Pode utilizar o diagrama de
disponibilização da UML nos casos em
que a configuração for muito complexa.

19
 Anotações do slide anterior

Modelo de configuração: em alguns casos, o modelo de configuração nada mais é que

uma lista de atributos no servidor e no cliente. Entretanto, para WebApps mais complexos,
uma série de detalhes de configuração. (por exemplo, distribuição da carga entre vários
servidores, arquiteturas de caching, bancos de dados remotos, vários servidores
atendendo vários objetos na mesma página web) poderiam ter um impacto na análise e no
projeto. O diagrama de disponibilização da UML pode ser utilizado em situações em que
complexas arquiteturas de configuração têm de ser consideradas.

20
Ciclo de vida:
projeto de arquitetura e de interface

21
 Anotações do slide anterior

Nesta outra seção veremos sobre o projeto de arquitetura para WebApps e para
aplicativos móveis.

22
Projeto de Arquitetura para WebApp
Categoria Estilo de arquitetura
Comunicação Service-Oriented Architecture (SOA), Message-bus

Implantação Implantação distribuída e não distribuída, Client/server

Domínio Domain model (Domain Driven Design)

Interação Entradas e saídas
Soluções Arquitetura base e arquitetura candidata

Estrutura Component-Based, Object-oriented, Layered Architecture

23
 Anotações do slide anterior

O objetivo da arquitetura de software é atender aos objetivos de uma área de negócio e 1.2 - Message-bus
oferecer os recursos técnicos necessários para a construção de um sistema. Em relação
ao projeto de arquitetura, temos que um estilo de arquitetura é um conjunto de sistemas O Message-bus, em que o termo bus pode ser traduzido como barramento, refere-se à
que operam de uma determinada forma, estando organizadas dentro de uma estrutura troca de informações utilizando como base um ou mais canais de comunicação
específica. Existem diversos estilos arquitetônicos, como deployment, client/server, e (barramento). As aplicações podem interagir sem precisar utilizar informações
outras ramificações de comunicação, como Service-Oriented Architecture (SOA) e desnecessárias.
message-bus:

Algumas características do Message-bus:

1 – Comunicação
1.1 - Service-Oriented Architecture (SOA) • Comunicação orientada a mensagens nas quais a comunicação ocorre utilizando
esquemas já conhecidos;

Arquitetura orientada a serviços: tem como base a organização de serviços nos quais
vários sistemas que se comunicam por interoperabilidade. Nessa arquitetura a troca de
informações é feita através de protocolos entre os sistemas.
• Modificação de processamento lógico, ou seja, temos que as interações têm como base
que os esquemas e comandos são iguais, assim é simples incluir ou remover uma
aplicação e com isso alterar a lógica com a qual o serviço vai operar;
• Integração com ambientes diferentes por meio do uso do message-bus.

O SOA tem como características:

Além dessas, o message-bus possui outras vantagens, como escalabilidade, flexibilidade e
baixa complexidade.
• Autonomia, cada serviço atua de forma independente;
• Distribuição, na qual cada serviço pode estar alocado em uma parte específica do
sistema, em bases locais ou remotas. Nesse caso, a única especificação é que o serviço
alocado remotamente atenda aos requisitos dos protocolos de comunicação utilizados;
• Redução de acoplamento considerando a autonomia que permite que cada serviço pode
ser substituído ou alterado;
• Esquemas e protocolos compartilhados.

24
 Anotações do slide anterior
2 – Implantação
Independentemente do projeto ou sistema, este precisará ser implantado, com isso temos
outro estilo de arquitetura que é a implantação (deployment). A definição da estratégia de
implantação deve considerar as restrições do projeto. Para isso deve-se verificar o
seguinte:
1. Entender o ambiente físico de implantação;
2. Conhecer as limitações da arquitetura para o ambiente de implantação;
3. Saber sobre o impacto da segurança e da performance no ambiente de implantação.
2.1 - Implantação distribuída e não distribuída
A identificação referente à complexidade da aplicação é que vai definir se a implantação
será distribuída ou não. Caso a aplicação seja muito complexa o ideal é que a implantação
seja distribuída, caso contrário não. Com essa abordagem é possível otimizar a aplicação.
Com essa possibilidade também pode-se melhorar a segurança da aplicação, já que com
servidores específicos tem-se um controle melhor dos tipos de autenticação e autorização
entre eles.
2.2 - Client/server
O estilo arquitetônico client/server é quando um ou mais dispositivos “clientes” solicitam
informações a um “servidor” e este responde com as informações solicitadas. O
client/server utiliza camadas e filas.
Camadas são subdivisões de trabalhos que ocorrem no código de aplicação, tanto no
cliente quanto no servidor. A camada que fica mais próxima do usuário final recebe o
nome de camada de apresentação. A seguir temos a camada responsável pela lógica,
denominada de camada de negócios. Por fim temos a camada de acesso a dados, essa
camada realiza a comunicação com o banco de dados.
De modo similar às camadas temos as filas, que referem-se à escalabilidade, distribuindo
módulos do código em máquinas diferentes.
3 - Domínio
3.1 - Domain model
Domain model considera o domínio de negócios no desenvolvimento de um software. É
mais utilizado quando se tem um conhecimento muito grande do negócio. Normalmente
se encontra o arquiteto, o desenvolvedor e um especialista no negócio atuando em
conjunto.
Como a parte central do software é o modelo de domínio com uma linguagem comum
compartilhada, torna-se mais simples a identificação de lacunas, tendo uma comunicação
entre os elementos da sua melhor aplicação.
Devido ao custo, é recomendado utilizar esse modelo de arquitetura em aplicações
complexas.
25
 Anotações do slide anterior

Vantagens do Domain model: 1. Identificar os objetivos da arquitetura;

1. Comunicação, já que o código é compartilhado entre a equipe;
2. Extensibilidade, já que na maioria das vezes temos um desenvolvimento modular e
flexível, facilitando a atualização conforme os requisitos e as condições são alterados;
3. Facilidade de testes já que os objetos do modelo de domínio possuem baixo
acoplamento e alta coesão.
2. Identificar os principais cenários;
3. Criar uma visão geral do aplicativo afim de adequar o aplicativo ao seu objetivo;
4. Identificar os pontos principais utilizando os atributos de qualidade;
5. Definir as soluções atuando na melhora, solução e avaliação de cenários e problemas
de implementação.

4 - Interação

Por meio de técnicas interativas é possível melhorar a arquitetura, tornando-a próxima dos
seus objetivos.

4.1 - Entradas e saídas

As entradas formalizam os requerimentos e as restrições que a arquitetura deve conter,

tais como os requisitos funcionais, não funcionais, atributos de qualidade, segurança e
confiabilidade. Para isso devemos seguir as seguintes etapas:

26
Projeto de interface
Estilo Descrição
Linha (linguagem) Acesso direto à funcionalidade, permitindo melhor eficiência
de comando para o usuário mais experiente.
Valoriza a forma de comunicação, assim melhorando a
Linguagem natural
interação da aplicação com o usuário.
Apresenta um formato e um conjunto claro de opções para
Menu o usuário. Mais simples de usar.
Preenchimento Indicado quando temos diferentes categorias de dados que
de formulário devem ser fornecidos ao sistema.
Conceito visual de tarefa, por exemplo a ação de mover
Manipulação direta
arquivos de uma pasta para outra.

27
 Anotações do slide anterior

Os objetivos de uma interface para WebApp são: • Menu

• Estabelecer uma janela consistente para o conteúdo e a funcionalidade fornecidos
pela interface;
• Guiar o usuário através de uma série de interações com a WebApp;
• Organizar as opções de navegação e conteúdo disponíveis para o usuário.
• Preenchimento de formulário
A interface abrange diversas características com um ênfase maior no layout e na forma
que apresenta a navegação. Existem 5 estilos de interface, cada uma delas possui suas
vantagens e desvantagens. A seguir veremos as principais de cada uma:
• Vantagem: apresenta um formato e um conjunto claro de opções para o
usuário. Mais simples de usar.
• Desvantagem: conforme a quantidade de menus teremos a necessidade de
usar muito espaço de tela, além de poder gerar lentidão no aplicativo.
• Vantagem: indicado quando temos diferentes categorias de dados que devem
ser fornecidos ao sistema.
• Desvantagem: temos o espaço de tela necessário para que o formulário seja
inserido.

• Linha (linguagem) de comando • Manipulação direta

• Vantagem: acesso direto à funcionalidade permitindo melhor eficiência para o • Vantagem: conceito visual de tarefa, por exemplo a ação de mover arquivos
usuário mais experiente. de uma pasta para outra.
• Desvantagem: é necessário conhecer como são as sintaxes dos comandos, • Desvantagem: necessita que o usuário compreenda bem a representação
com isso necessita de um treinamento adicional. visual, caso contrário uma funcionalidade pode ser perdida ou
executada indevidamente.
• Linguagem natural
• Vantagem: valoriza a forma de comunicação, assim melhorando a interação
da aplicação com o usuário.
• Desvantagem: depende da existência do diálogo feito de forma correta, senão
pode gerar falhas de comunicação.

28
Exemplo prático – ciclo de vida de
desenvolvimento de um aplicativo móvel e de um
WebApp

29
 Anotações do slide anterior

Nesta aula, entendemos que o ciclo de vida de desenvolvimento de um aplicativo móvel e

de um WebApp se inicia pela modelagem de requisitos, com uma análise de todos os
requisitos necessários para atender o objetivo.

Vimos também que a entrada de uma modelagem de requisitos são as informações

obtidas durante a atividade de comunicação. E que obtemos como saída cinco modelos:
modelo de conteúdo; modelo de interação; modelo funcional; modelo de navegação e
modelo de configuração.

Observamos que a análise de requisitos fornece um mecanismo disciplinado para

representar e avaliar o conteúdo e uma função de uma aplicação, os modos de interação
que os usuários vão encontrar e o ambiente e a infraestrutura em que aplicações web ou
aplicativos móveis residem.

Para exemplificar, veremos a análise de requisitos considerando um dos modelos mais

relevantes, que é o modelo de conteúdo, que contém os elementos estruturais que dão
uma visão importante dos requisitos de conteúdo para a aplicação.

Para o modelo de conteúdo, exploraremos o exemplo de uma árvore de dados, extraído da

página 217 de Pressman e Maxim (2016).

30
Exemplo – Modelo de Conteúdo

Artefato de modelo
de conteúdo
Árvore de dados

Fonte: Pressman e Maxim (2011, p. 217).

31
 Anotações do slide anterior

Temos como foco o modelo de conteúdo, no qual exploraremos o exemplo de uma árvore
de dados, extraído de Pressman e Maxim (2016, p. 217).
Vimos nesta aula que o modelo de conteúdo contém elementos estruturais que dão uma
visão importante dos requisitos de conteúdo de uma aplicação e que o conteúdo pode ser
desenvolvido antes da implementação da aplicação, enquanto ela está sendo construída.
• Artefato de modelo de conteúdo – árvore de dados: ao analisarmos a figura, temos
uma árvore que representa uma hierarquia de informações usadas para descrever um
componente. Os dados simples ou compostos (um ou mais valores de dados) são
representados com retângulos de fundo branco. Os objetos de conteúdo são
representados com retângulos sombreados. A descrição é definida por cinco objetos
de conteúdo (os retângulos sombreados).

Os objetos de conteúdo podem ser determinados diretamente dos casos de uso,

examinando-se a descrição do cenário para referências diretas e indiretas ao conteúdo.
Para esse nosso exemplo, utilizaremos a aplicação web que oferece suporte ao aplicativo
CasaSegura. Aqui trataremos especificamente do caso de uso Comprando Componentes
Específicos do CasaSegura, que descreve o cenário necessário para adquirir um
componente do CasaSegura e contém a seguinte frase: Serei capaz de obter informações
descritivas e de preços para cada componente do produto.

O modelo de conteúdo deve ser capaz de descrever o objeto de conteúdo Componente. O

modelo de conteúdo proporciona que, a partir de uma lista de objetos de conteúdo, com
uma breve descrição de cada objeto seja suficiente para definir os requisitos para o
conteúdo a ser projetado e implementado. Entretanto, o modelo de conteúdo pode se
beneficiar de uma análise mais rica que ilustre graficamente as relações entre os objetos
de conteúdo e/ou a hierarquia do conteúdo mantido por uma aplicação web ou aplicativo
móvel.

Aqui utilizaremos um exemplo de forma gráfica (árvore de dados) para ilustrar as relações
para o objeto Componente.

32
Considerações finais

33
 Modelagem dos requisitos recebe como entrada as
informações e tem como saída cinco modelos para
analisar os requisitos.

 Os cinco modelos são: de conteúdo, de interação,

funcional, de configuração e modelo de navegação.

 O projeto de arquitetura visa atender aos objetivos e

recursos técnicos para a construção de um sistema.

 O projeto de interface está relacionado à forma

como o usuário interage com o WebApp.

34
 Anotações do slide anterior

Ao longo desta aula vimos em mais detalhes sobre os requisitos para o desenvolvimento
de aplicativos para dispositivos móveis:

• Aprendemos que a modelagem dos requisitos para dispositivos móveis é composta

por 5 modelos;
• Conhecemos detalhes de cada modelo: modelo de conteúdo, modelo de interação,
modelo funcional, modelo de configuração e modelo de navegação;
• Aprendemos sobre a arquitetura de desenvolvimento e o uso do MVC;
• Por fim aprendemos sobre o projeto de interface e que está relacionada com a forma
como o usuário interage com o WebApp.

35
Referências bibliográficas

FÉLIX, R. Arquitetura para computação móvel. São Paulo:

Pearson Education do Brasil, 2016.

SILVA, D. Desenvolvimento para dispositivos móveis.

São Paulo: Pearson Education do Brasil, 2016.

PRESSMAN, Roger; MAXIM, Bruce R. Engenharia de

software: uma abordagem profissional. 8. ed. São Paulo:
Editora McGraw Hill-Artmed, 2016.

36