Modelagem de Requisitos para Aplicações Web e Móveis

Prévia do material em texto

3ºAula
Análise e modelagem de 
requisitos – Parte II
Objetivos de aprendizagem
Ao término desta aula, vocês serão capazes de: 
•	 entender os passos da modelagem de classes;
•	 saber como funciona a modelagem de comportamento;
•	 entender os aspectos relacionados a modelagem de requisitos para aplicações web e móveis.
Olá, pessoal, tudo bem? 
Continuando nossos estudos sobre a modelagem de 
requisitos, vamos estudar hoje os modelos baseados em classes 
e o modelo comportamental, que focam na estrutura dos dados 
do sistema (e os seus relacionamentos) e nos comportamentos 
do sistema.
Além disso, vamos mostrar nessa aula como seria uma 
modelagem de requisitos para aplicações Web e dispositivos 
móveis, devido ao contexto diferente desses sistemas.
Lembre-se que estamos sempre à disposição na área do 
aluno para resolver eventuais dúvidas.
Vamos lá?
Bons estudos!
Engenharia de Requisitos 18
Seções de estudo
1 - Modelagem baseada em Classes
2 - Modelagem de Comportamento
3 - Aspectos relacionados a modelagem de requisitos 
para aplicativos Web e aplicativos móveis
1 - Modelagem baseada em Classes
Vimos,	 na	 aula	 anterior,	 como	definir	 os	 cenários	 (ou	
casos de uso) que ocorrerão na execução do software. Mas 
isso é apenas um dos aspectos existentes em um projeto de 
software.
Existe	outro	aspecto	que	define	quais	são	as	entidades	
que serão utilizadas em um software. No paradigma 
procedimental, usando a Análise Estruturada (conforme 
vimos na disciplina Metodologia para Desenvolvimento de 
Software), esses dados são isolados, ou no máximo agrupados 
em registros.
Já no paradigma orientado a objetos, os dados se juntam 
às funções que manipulam esses dados, criando classes e 
objetos. Segundo Coad e Yourdon (apud PRESSMAN, 
MAXIM; 2016; p. 184), esses conceitos da orientação a 
objetos (classes, atributos, totalidade, parte, etc.) são conceitos 
que “aprendemos no jardim de infância”.
Por meio desses conceitos, podemos representar uma 
aplicação que pode ser entendida por uma pessoa que não 
entenda de desenvolvimento de software, e dessa representação 
podemos	evoluir	para	uma	especificação	que	será	usada	para	
desenvolver o sistema (PRESSMAN, MAXIM; 2016).
Para criarmos essa representação baseada em classes, 
usamos métodos que, com base nos requisitos, podemos 
detectar os objetos que o sistema vai usar, as operações que 
serão feitas, as relações e as colaborações que vão ocorrer entre 
os objetos. Isso se chama modelagem baseada em classes. 
Os resultados desses métodos são: classes (e seus 
objetos), atributos, operações, modelos CRC, diagramas de 
colaboração e pacotes. Nessa seção, vamos apresentar, de 
uma forma mais detalhada, os métodos que são utilizados 
para a detecção de classes e veremos o que são os modelos 
CRC.
1.1	-	Identificando	classes
Vimos, na disciplina Metodologia para Desenvolvimento 
de Software, um pequeno roteiro para que você possa 
descobrir classes, atributos, métodos e relacionamentos. 
Nessa seção, vamos destrinchar esse tema, esclarecendo 
alguns aspectos adicionais.
Primeiramente, vamos recapitular as etapas da descoberta 
de classes, que vocês viram na disciplina anterior. Ela consiste 
na leitura e interpretação dos casos de uso, seguindo os 
seguintes passos:
•	 Nomes, pronomes e frases substantivadas são 
grandes candidatas a serem classes e objetos. 
Nomes no singular (João, ele, ela, estação de 
trabalho) e nomes de referência direta (o sexto 
jogador, a transação) podem ser objetos. Já nomes 
no plural (pessoas, alunos, professores) são 
candidatas a serem classes;
•	 Além disso, alguns nomes podem representar 
propriedades (atributos) de um objeto, além de 
adjetivos e frases possessivas. Por exemplo, a idade 
da criança, o nível do rio, a quantidade de estoque 
de um produto;
•	 Verbos, como pagar, solicitar, emitir, por exemplo, 
são candidatas a serem serviços, ou seja, métodos 
dessas classes.
•	 Depois de selecionarmos estas situações, devemos 
eliminar alguns objetos essenciais “falsos”, através 
de	um	teste.	Para	cada	objeto	detectado,	verifique	
se	 encaixa	nas	 seguintes	definições:	 (I)	Ele	 é	uma	
entidade do mundo real?, (II) Ele é importante para a 
discussão dos requisitos?, (III) Ele não corresponde 
a nenhuma classe ou objeto que já selecionei antes? 
e	(IV)	Ele	tem	uma	fronteira	muito	bem	definida,	
ou	seja,	ele	pode	ser	definido	totalmente?
•	 No	final,	descobrimos	se	existe	alguma	relação	de	
hierarquia entre as classes, perguntando: “O objeto 
A é um objeto B?” e “O objeto B é um objeto A?”. 
Se as respostas forem sempre e às vezes (ou vice-
versa), existe uma relação de herança entre os dois 
objetos. Por exemplo: um cliente é sempre uma 
pessoa, mas uma pessoa nem sempre é um cliente.
O esquema que apresentamos é um passo a passo 
simplificado	de	como	encontrar	classes	no	sistema.	Podemos	
encorpar esse processo, fazendo uma análise dos papéis das 
prováveis	classes.	Existem	várias	 formas	de	classificar	esses	
papéis (das classes de análise). Uma delas é proposta por 
Pressman e Maxim (2016), e a descrevemos abaixo:
•	 entidades externas - produzem ou consomem 
informações a serem usadas pelo sistema (um 
grande exemplo são os sensores);
•	 coisas - itens que fazem parte do domínio de 
informações do problema (relatórios, sinais);
•	 eventos - situações que ocorrem durante a execução 
do sistema (chegada da encomenda);
•	 papéis - pessoas que desempenham funções no 
sistema (gerente);
•	 unidades organizacionais - setores relevantes para a 
organização (divisão);
•	 locais - estabelecem o contexto do problema (chão);
•	 estruturas	-	definem	uma	classe	de	objetos	ou	classes	
de objetos relacionados (computadores).
Além disso, os mesmos autores ressaltam que classes 
não são representadas por um nome procedural imperativo 
(um exemplo: inversão de imagem). Essas situações 
geralmente são entendidas como atributos de uma classe 
já existente.
Depois de catalogar os papéis, podemos fazer uma 
filtragem	para	verificar	quais	dos	substantivos	são	realmente	
classes ou não. Uma das formas é descrita por Coad e 
Yourdon. São elencadas seis condições para que um item seja 
aceito como uma classe. Sobre esses itens, descreveremos a 
19
seguir:
•	 Informações retidas. A classe em potencial 
será útil durante a análise apenas se as 
informações sobre ela tiverem de ser 
relembradas para que o sistema possa 
funcionar.
•	 Serviços necessários. A classe em potencial 
deve ter um conjunto de operações 
identificáveis	 capazes	 de	 modificar,	 de	
alguma forma, o valor de seus atributos.
•	 Atributos múltiplos. Durante a análise de 
requisitos, o foco deve ser nas informações 
“importantes”; uma classe com um único 
atributo poderia, na verdade ser útil 
durante o projeto; porém, provavelmente 
seria mais bem representada na forma de 
atributo de outra classe durante a atividade 
de análise.
•	 Atributos comuns. Um conjunto de atributos 
pode	 ser	 definido	 para	 a	 classe	 em	
potencial e esses atributos se aplicam a 
todas as instâncias da classe.
•	 Operações comuns. Um conjunto de 
operações	pode	ser	definido	para	a	classe	
em potencial e tais operações se aplicam a 
todas as instâncias da classe.
•	 Requisitos essenciais. Entidades externas 
que aparecem no espaço do problema e 
produzem ou consomem informações 
essenciais à operação de qualquer solução 
para o sistema, quase sempre serão 
definidas	 como	 classes	 no	 modelo	 de	
requisitos. (COAD, YOURDON; 1991 
apud PRESSMAN, MAXIM; 2016; p. 187)
•	 um cliente pode locar veículos, para isso, deve informar a sua 
CNH, seu RG, seu nome, seu endereço, seu CPF e seu número de 
dependentes;
•	 a locadora possui vários carros.	A	locadora	mantém	uma	ficha	
de cadastro dos carros, que inclui a placa do veículo, o nome, 
amarca, o modelo, o valor do seguro, o valor da locação e a sua 
cor. Sendo que o valor da locação do carro pode ser atualizado a 
qualquer momento.
•	 além disso, a locadora registra seus funcionários com os 
seguintes dados: CPF, RG, seu nome, seu endereço e seu cargo. 
Um funcionário pode ainda ser admitido ou demitido, para isso são 
registradas suas datas de admissão - contratação - e demissão.
•	 a locadora, além de realizar os cadastros, ela cadastra as locações 
de veículos. No momento da locação, a locadora registra o número 
do cliente e a placa do carro, além de atribuir a data da locação para 
o dia atual. No ato da devolução, o funcionário registra a data de 
devolução e a quilometragem percorrida, para que seja informado o 
preço a pagar pela locação.
•	 Qualquer funcionário pode registrar clientes, carros e locações. 
Mas, o funcionário na condição de supervisor é o único que tem a 
permissão de registrar e demitir funcionários - além de pode fazer o 
que um funcionário comum pode fazer.
•	 O funcionário deve estar cadastrado e logado para acessar os 
recursos do sistema.
Os itens sublinhados se referem a possíveis atributos e 
os itens em negrito a possíveis classes. Após uma análise, a 
analista criou o diagrama de classes a seguir:
Para facilitar seus estudos, vamos agora ver o que a 
analista do sistema da locadora fez para a modelagem de 
classes. Primeiro, ela analisou os requisitos preliminares do 
sistema, e sublinhou todas as palavras que interessaram:
Figura 1 - Diagrama de Classes de análise. Fonte: acervo Pessoal.
Engenharia de Requisitos 20
1.2 - Modelagem CRC
Desenvolvido por Rebecca Wirfs-Brock, a modelagem 
CRC (Classe-Responsabilidade-Colaborador) é uma técnica 
que	consiste	em	modelar	em	fichas	reais	as	classes	do	sistema	
e suas responsabilidades e colaborações. Nessa técnica deve 
se atentar a alguns detalhes:
•	 Cada	 classe	 do	 sistema	 representa	 uma	 ficha,	
podendo	 ser	 real	 (uma	ficha	 especificamente	 feita	
para isso, uma folha pautada dividida em duas, um 
post-it) ou virtual (veja nas nossas recomendações 
os sites “Criador de Cartão CRC” e “CRC Card 
Maker”. Você pode criá-los em um programa de 
fichas	eletrônicas	ou	em	um	programa	de	planilhas	
eletrônicas);
•	 Cada classe recebe um nome, uma descrição 
(colocada abaixo do nome da classe) e opcionalmente 
uma indicação de sua superclasse;
•	 Abaixo	 da	 descrição,	 a	 ficha	 é	 dividida	 em	 duas	
partes.	 Na	 parte	 esquerda	 da	 ficha	 ficam	 as	
responsabilidades da classe, e na parte da direita são 
elencados os colaboradores da classe;
•	 Responsabilidade é qualquer coisa que a classe saiba 
ou faz. Nessa parte são elencados itens que darão 
origem aos atributos (o que ela sabe) e os métodos 
(o que ela faz);
•	 Colaboradores são outras classes que fornecem 
informações que serão úteis para que a classe realize 
suas responsabilidades. Também pode ser classes 
que executa ações a pedido da classe.
Lee e Tepfenhart (2002) elencam as etapas que são 
realizadas na versão clássica, descritas a seguir:
•	 Em um cartão CRC, documente o nome da classe e 
liste as responsabilidades e os colaboradores;
•	 Identifique	objetos	e	classes	ausentes	que	deverão	
ser acrescentados ao conjunto de cartões existentes. 
Principalmente, procure responsabilidades que 
não podem ser alocados às classes já existentes e 
colaboradores que ainda não foram designados para 
uma classe. Essa revisão pode ser feita analisando os 
casos de uso em grupos.
A seguir, reproduziremos um modelo de cartão CRC, 
representando a classe Carro, do sistema da locadora.
Classe: Carro
Descrição: Define	um	carro	a	ser	locado	na	empresa
responsabilidades Colaboradores
Sabe	o	número	da	placa
Tem um nome, modelo, cor e marca
Tem um valor do seguro
Define	o	valor	da	locação
Figura 2 - Cartão CrC da classe Carro. Fonte: acervo Pessoal.
Na próxima seção, vamos estudar como funciona a 
modelagem comportamental do sistema. 
2 - Modelagem de Comportamento
Você viu em nossos últimos conteúdos como fazer a 
modelagem de cenários e de classes. Esses dois aspectos são 
denominados de aspectos estáticos do sistema. Mas muitos 
sistemas também possuem comportamentos dinâmicos. 
Assim, temos o modelo comportamental, que consiste em 
representar esse aspecto dinâmico do sistema.
Esse aspecto está relacionado aos estados onde um 
objeto de uma determinada classe vai passar no decorrer 
do seu ciclo de vida. Assim, as saídas desse processo de 
modelagem são diagramas de estado e diagramas de sequência 
(se for necessário).
Para detectarmos comportamento, seguimos os seguintes 
passos indicados por Pressman e Maxim (2016):
•	 avaliar os casos de uso para entender a sequência de 
interação do sistema;
•	 identificar	 eventos	 que	 controlam	 a	 sequência	 de	
interação do sistema e entender como esses eventos 
se	relacionam	com	objetos	específicos;
•	 criar uma sequência para cada caso de uso;
•	 criar um diagrama de estado para o sistema;
•	 examinar	o	modelo	comportamental	para	verificar	
exatidão e consistência.
Para ilustrar isso, vamos fazer um estudo do modelo 
comportamental para o nosso caso de uso da locadora. Após 
uma análise de todos os casos de uso e do entendimento das 
interações, a analista da empresa selecionou alguns trechos de 
alguns casos de uso do sistema, que reproduziremos a seguir:
Caso de Uso: cadastrar o carro
(...)	uma	vez	finalizado	o	cadastro	do	veículo,	o mesmo passa a estar 
disponível para futuras locações.
Caso de Uso: realizar locação
(...) o carro passa a ser marcado como indisponível e a locação é 
realizada.
Caso de Uso: finalizar Locação
Quando	o	funcionário	confirmar	a	operação,	o	valor	final	é	calculado	e	
o carro passa a ser marcado como disponível para uma nova locação.
Com isso, podemos ver que temos delineado certo 
conjunto de estados do sistema. E podemos ver que:
•	 quando um carro é cadastrado, o carro passa a ser 
disponível;
•	 quando uma locação é feita, o carro passa a estar 
indisponível;
•	 quando uma locação é encerrada, o carro passa a 
estar disponível novamente.
Podemos,	então,	afirmar	que	temos	um	ciclo	de	estados	
definidos	para	a	classe	Carro.	O	passo	seguinte	seria	a	criação	
de um diagrama de estados para esta classe, que reproduzimos 
a seguir. Note que criamos dois estados adicionais - “Cadastrar 
o Carro” e “Carro Indisponível”.
21
Figura 3 - Diagrama de estados da classe Carro. Fonte: acervo Pessoal.
Com isso, vimos os três aspectos que devem ser levados 
em conta na modelagem de requisitos. Mas existem certos 
sistemas, com outras particularidades e necessidades, que 
devem ser levadas em conta na modelagem de requisitos. 
Veremos sobre eles a seguir.
3 - Aspectos relacionados à 
modelagem de requisitos para 
aplicativos Web e aplicativos móveis
Nos últimos anos, com a expansão da Internet e a 
popularização dos smartphones, cresceu o número de softwares 
que são executados em navegadores (aplicações Web) e em 
dispositivos (denominados de aplicações móveis).
 Não houve somente crescimento, houve também 
uma	diversificação	nas	funções	desses	programas.	Agora	um	
usuário pode fazer quase tudo nessas plataformas.
 Com isso, pesquisadores que atuam na Engenharia 
de Software passaram a investigar como funciona a 
modelagem de requisitos para o desenvolvimento de 
aplicativos nessas plataformas. E, durante essa investigação, 
algumas peculiaridades foram descobertas. Nessa seção, 
vamos descrever quais são essas peculiaridades.
3.1 - Entrada e análise dos requisitos
Pressman	e	Maxim	(2016)	afirmam	que	dependendo	de	
onde o sistema será utilizado, uma descrição informal dos 
requisitos	 não	 é	 suficiente	 para	 caracterizar	 um	modelo	 de	
sistema. Nessas situações, eles recomendam que seja feita uma 
análise detalhada de cada caso deuso. Deve-se procurar por 
situações que não foram previstas, mas são importantes como: 
detalhes técnicos, comportamento inesperado, informações 
adicionais, layout dos botões, posicionamento etc.
Assim, deve-se atentar à seguinte pergunta: “Você 
entendeu todos os requisitos do problema?”. Se a resposta for 
não, é necessário mais trabalho para o entendimento desses 
requisitos. Vale lembrar que a descrição dos requisitos deve ser 
completa	o	suficiente	para	conduzir	o	projeto	sem	erros,	pois	
os custos de correção crescem à medida que o projeto avança.
3.2 - Saída da modelagem de 
requisitos
Devido às peculiaridades que existem nos aplicativos 
móveis e Web, existem mais aspectos que devem 
ser considerados na modelagem de requisitos (não 
desconsiderando os três aspectos tradicionais). Assim, são 
propostos outros modelos que devem ser levados em conta 
na modelagem de requisitos. Eles serão descritos a seguir:
Modelo de Conteúdo
Esse	modelo	 tem	como	função	“identificar	o	espectro	
completo do conteúdo a ser fornecido pela aplicação” 
(PRESSMAN; MAXIM, 2016; p. 215). Esse “conteúdo” 
pode ser entendido como qualquer item multimídia, como 
textos,	gráficos,	imagens	vídeos	etc.
Esse modelo contém elementos que dão uma visão 
de qual conteúdo deve ser colocado em uma aplicação. Ela 
relaciona os objetos de conteúdo com classes de análise (que 
são todas as entidades visíveis aos usuários, ou que são criadas 
e/ou manipuladas no decorrer do uso do sistema).
Objetos de conteúdo podem ser entendidos como 
algum elemento (implícito) que represente uma informação 
sobre algum outro elemento do software. Podemos citar como 
exemplos:
•	 uma foto em uma notícia;
•	 uma resposta em um fórum;
•	 um comentário em um texto etc.
Assim, o modelo de conteúdo serve para descrever as 
informações que estão agregadas a um objeto. Podemos 
descrevê-los através de uma lista simples, ou por um diagrama 
de árvore de dados (não é um diagrama da UML). Nesse 
exemplo, temos uma árvore de dados mostrando os dados 
que são agregados de um componente a venda de um site de 
segurança eletrônica.
Figura 4 - Exemplo de Árvore de Dados. Fonte: adaptado de PrESSMan, MaXiM; 
2016; p. 217.
Modelo de interação
Esse modelo tem como função descrever “a maneira 
como os usuários interagem com a aplicação” (PRESSMAN; 
MAXIM, 2016, p. 215). Assim, podemos entender como 
a descrição da interação do usuário com o sistema. Podem 
ser constituídos por meio de casos de uso, diagramas de 
sequência, diagrama de estados e protótipos.
Na maioria das vezes, um conjunto de casos de uso 
(criados através da modelagem baseada em cenários) já é 
suficiente.	Mas,	 se	 a	 interação	 for	 complexa,	 é	 importante	
aprofundar na elaboração desse modelo. 
Assim, podem ser criados protótipos demonstrando a 
interface do sistema, que será apresentado ao usuário. Muitas 
vezes um simples wireframe resolve.
Engenharia de Requisitos 22
•	 hierarquia de navegação;
•	 facilidade de acesso;
•	 tratamento de possíveis erros de navegação;
•	 como é obtida a navegação;
•	 otimização de navegação;
•	 como é apresentada a navegação;
•	 necessidade de apresentação prévia da navegação;
•	 entre outros aspectos.
Assim, terminamos a nossa aula e a parte de modelagem 
de requisitos. A seguir, vamos iniciar nossos estudos sobre 
Projeto de Software.
Retomando a aula
Chegamos	ao	final	da	terceira	aula.	Vamos	recordar	
os pontos principais?
1 - Modelagem baseada em Classes
Nessa seção, aprendemos como funciona a modelagem 
de	 classes.	 Usamos	 como	 base	 as	 especificações	 escritas,	
procurando verbos, substantivos e adjetivos para caracterizar 
os	possíveis	 itens	do	sistema.	Depois,	 refinamos,	com	base	
em vários métodos já feitos, para criar as classes de análise.
2 - Modelagem de Comportamento
Está relacionado aos estados onde um objeto de uma 
determinada classe vai passar no decorrer do seu ciclo de vida. 
Assim, as saídas desse processo de modelagem são diagramas 
de estado e diagramas de sequência. Seu procedimento 
envolve a análise de casos de uso, em busca de eventos.
3 - Aspectos relacionados a modelagem de requisitos 
para aplicativos Web e aplicativos móveis
Vimos que, devido às particularidades envolvidas 
nas aplicações Web e nos aplicativos móveis, existem mais 
alguns aspectos que devem ser considerados no projeto de 
software. Esses aspectos são o Modelo de Conteúdo, Modelo 
de	Interação,	Modelo	Funcional,	Modelo	de	Configuração	e	
Modelo de Navegação.
Vale a pena
DEBASTIANI, Carlos Alberto. Definindo Escopo em 
Projetos de Software. São Paulo: Novatec, 2015.
ENGHOLM JR, Hélio. Engenharia de Software na Prática. 
São Paulo: Novatec, 2010.
PRESSMAN, Roger S.; MAXIM, Bruce R. Engenharia 
de Software:	Uma	abordagem	profissional.	8	ed.	Porto	Alegre:	
Bookman, 2016. 
SOMMERVILLE, Ian. Engenharia de Software. 9 ed. São 
Paulo: Pearson, 2011.
Vale a pena ler
Wireframe
Wireframe é um esqueleto da interface que será implementada no 
programa. É um desenho bastante simples, onde o projetista não se 
atenta a detalhes de implementação, como cores, textos etc. É uma das 
ferramentas mais baratas para elaboração de protótipos de interfaces, 
pois você pode usar apenas papel e lápis para construir esses esboços.
Figura 5 - Exemplo de Wireframe de um site de um perfil de uma pessoa. Fonte: 
Disponível em: <https://pt.wikipedia.org/wiki/Website_wireframe#/media/
File:Profilewireframe.png>. Acesso em 08 mar. 2018.
Você	 pode	 usar	 também	 especificações	 mais	 completas,	 como	
veremos nas aulas posteriores.
Modelo funcional
Esse	 modelo	 se	 preocupa	 em	 definir	 “as	 operações	
que serão aplicadas para manipular o conteúdo e descreve 
outras funcionalidades de processamento, independentes do 
conteúdo, mas necessárias para o usuário” (PRESSMAN; 
MAXIM, 2016; p. 216). 
Assim, esse modelo trata em descrever as operações (assim 
como	as	 restrições	e	 as	 especificações)	que	 serão	executadas	
pelas funções disponibilizadas no sistema e as funções que serão 
usadas para compor o comportamento das classes de análise. 
Podemos usar um diagrama de atividades para representar 
detalhes do processamento a ser executado.
Modelo de Configuração
Esse	 modelo	 define	 o	 ambiente	 e	 a	 infraestrutura	 na	
qual a aplicação reside. Consiste na descrição da arquitetura 
onde	o	sistema	será	executado,	e	em	detalhes	de	configuração	
do sistema (por exemplo: sistema operacional, versão do 
banco	de	dados,	configuração	de	leitura	e	escrita	das	pastas,	
quantidade de memória disponível etc.).
Modelo de Navegação
Por	 fim,	 o	 modelo	 de	 navegação	 é	 a	 descrição	 da	
estratégia	 geral	 de	 navegação.	Nele,	 são	 definidos	 aspectos	
referentes à navegação, como:
23
CHEUNG, Eugene. CRC Card Maker. Disponível em: 
<https://echeung.me/crcmaker/>. Acesso em: 08 mar. 
2018.
FIRPO, Fernando. Custo de erros em projetos de 
desenvolvimento de software. [S.l.]: Análise de Requisitos, 2011. 
Disponível em: <http://analiserequisitos.blogspot.com.
br/2011/07/custo-de-erros-em-projetos-de.html>. Acesso 
em: 08 mar. 2018.
UEDA, Larissa Yuri. Criador de Cartão CRC. Disponível 
em: <http://www.inf.ufpr.br/andrey/ci162/crc/>. Acesso 
em: 08 mar. 2018.
ZEMEL, Tárcio. Wireframes para Web: Guia completo 
de desenvolvimento. [S.l.]: DPW, 2011. Disponível em: 
<http://desenvolvimentoparaweb.com/ux/wireframe-
web-guia-completo/>. Acesso em: 08 mar. 2018.
Vale a pena acessar
Minhas anotações