Notas de Aula - Modelagem de Sistemas - Unidade 02

Prévia do material em texto

Prof. Sérgio Luiz Tonsig 
1 
 
 
 
 
Unidade Curricular 02 
 
 
Prof. Sérgio Luiz Tonsig 
2 
 
 
 
 
 A unidade curricular 01 da Modelagem de Sistemas traz os conceitos sobre os modelos que 
podem ser criados, segundo uma perspectiva do sistema a ser criado. 
 É pressuposto que você já tenha entendido todo o conteúdo da unidade curricular 01, para 
ingressar agora na unidade 02. 
 Nessas notas de aula, você será conduzido na continuidade prática dos conceitos vistos na 
unidade anterior. Haverá a continuidade da aplicação da UML para abordagem da diagramação de 
outras perspectivas. 
 A unidade 02 também irá apresentar características de modelagem específicas para o 
ambiente Web, Mobile e IoT. 
 A complexidade atual dos sistemas e suas integrações, exigem um conhecimento profundo 
sobre a área de negócio onde serão utilizados. Esse conhecimento só é atingido com a exploração 
das várias perspectivas de uso de seus processos, através de modelagens adequadas. 
 
 
 
 
 
 
Prof. Sérgio Luiz Tonsig 
3 
Sumário 
1. Modelagem com a UML ..................................................................................................................... 5 
1.1. Visão lógica. ................................................................................................................................. 5 
1.1.1. Diagrama de Classes ............................................................................................................. 5 
1.1.2. Diagrama de Pacotes .......................................................................................................... 10 
1.1.3. Diagrama de Objetos. ......................................................................................................... 11 
1.2. Visão de Processo. ..................................................................................................................... 12 
1.2.1. Diagrama de Sequência ...................................................................................................... 12 
1.2.2. Diagrama de Estados .......................................................................................................... 13 
1.2. Visão de Implementação. .......................................................................................................... 15 
1.2.1. Diagrama de Componentes ................................................................................................ 15 
1.3. Visão de Implantação. ............................................................................................................... 16 
1.3.1. Diagrama de Implantação .................................................................................................. 16 
1.3.2. Diagrama de Tempo ........................................................................................................... 17 
1.9. Modelo M.V.C. e o Diagrama de Classes................................................................................... 19 
2. Modelagem para WEB .................................................................................................................. 21 
2.1. Modelagem UX ...................................................................................................................... 21 
2.1.1. O que é a experiência do usuário? ................................................................................ 21 
2.1.1. Como modelar para WEB. .................................................................................................. 22 
2.1.2. Arquitetura da modelagem. ............................................................................................... 23 
2.1.2. Fases na modelagem UX. ............................................................................................... 25 
2.2. API Web ................................................................................................................................. 26 
2.2.1. Representações. ............................................................................................................. 26 
2.2.2. Pré-requisitos. ................................................................................................................ 27 
2.2.3. Arquitetura REST (Transferência de Estado Representacional) ................................... 27 
2.2.4. Princípios para desenvolvimento de API REST .............................................................. 28 
2.2.5. Nível de Maturidade de APIs REST ................................................................................. 28 
2.2.6. Orientações Gerais sobre APIs. ...................................................................................... 29 
3. Modelagem de Sistemas para Dispositivos Móveis. .................................................................... 32 
3.2. Design WEB ............................................................................................................................... 33 
 
 
Prof. Sérgio Luiz Tonsig 
4 
3.3 O que é Design? .......................................................................................................................... 34 
3.3.1. UX e UI ................................................................................................................................ 34 
3.3.2. Design centrado no usuário. ............................................................................................... 35 
3.3.3. Analisar interface e interoperabilidade. ............................................................................. 36 
3.3.4. Elementos auxiliares no Design .......................................................................................... 38 
Referências Bibliográficas .................................................................................................................... 40 
 
 
 
 
Prof. Sérgio Luiz Tonsig 
5 
1. Modelagem com a UML 
 
 Na unidade 01 já havíamos visto a visão externa, sendo representada pelo diagrama de casos 
de uso. Agora vamos incrementar a demais visões: lógica, de processo, implementação e 
implantação. 
 
1.1. Visão lógica. 
 
 A visão lógica mostra um subconjunto do modelo de design significativo em termos de 
arquitetura, ou seja, um subconjunto das classes, subsistemas, pacotes e realizações de caso de uso. 
Os elementos da visão lógica também são conhecidos como diagramas estáticos ou estruturais, 
porque servem de base para a organização dos elementos e, são utilizados na modelagem dinâmica 
do sistema. 
 
1.1.1. Diagrama de Classes 
 
 Genericamente a figura 1 mostra uma definição de classe. 
 
Figura 1 – Classe 
 O nome da classe deve começar com a primeira letra em maiúsculo e as demais minúsculas. 
Se houve junção com outra palavra (concatenação), a primeira letra da segunda palavra deve ser 
maiúscula e as demais minúscula (exemplo: VendaItem). 
 Tanto atributos quanto métodos, devem ter nome em minúsculo. Se o nome for concatenado 
com outras palavras, a primeira letra dessas palavras devem ser em maiúsculo as demais minúsculo, 
como por exemplo: atualizarSaldo. 
 
 
Prof. Sérgio Luiz Tonsig 
6 
 Por padrão atributos tem visibilidade privada (representado pelo sinal: - ) e os métodos 
possuem visibilidade pública (representada pelo sinal: + ). Caso não se recorde sobre o que seja 
visibilidade, deve recorrer ao material da unidade curricular 01. 
 
 
1.1.1.1 Relacionamentos entre Classes 
 
Um relacionamento de herança entre classes mostra que a subclasse compartilha a estrutura 
ou comportamento definido de uma ou mais classe mãe. A notação de um relacionamento de 
generalização é mostrada na Figura 2. 
 
Figura 2 – Herança 
 Um relacionamento de dependência entre duas classes mostra que a existência de uma classe 
depende a existência da outra. Por exemplo, na Figura 3 o diagrama mostra que a classeDependente 
depende da classe Funcionário para existir. 
 
Figura 3 – Relacionamento de Dependência 
 
Um relacionamento de associação representa uma conexão semântica entre duas classes e é 
o relacionamento mais utilizado. É bidirecional e é representado por uma linha ligando as classes. A 
Figura 4 mostra um relacionamento de associação entre as classes Fornecedor e Pedido. 
 
 
Figura 4 – Relacionamento de Associação 
 
 
Prof. Sérgio Luiz Tonsig 
7 
Um relacionamento de agregação (figura 5) é uma forma especial de associação, que é usada 
para mostrar que um tipo de objeto é composto de outro objeto. Um relacionamento de agregação 
é também chamado de “todo-parte”. 
A agregação por valor (losango cheio), também chamada de composição ou agregação forte, 
indica que o tempo de vida das partes são dependentes do tempo de vida do todo. Um item de 
pedido existe se existe o pedido e vice-versa. 
Na agregação por referência (losango sem preenchimento), também chamada de agregação 
fraca, o tempo de vida das partes não são mutuamente dependentes do tempo de vida do todo. 
 
 
Figura 5 – Relacionamento de Agregação 
 
1.1.1.1.1. Multiplicidade nos Relacionamentos 
 
 Nos relacionamentos de associação e agregação é facultado acrescentar a multiplicidade, que 
especifica o número de instâncias de uma classe em relação a outra, através de números mínimos e 
máximos (tabela 01). 
Notação Significado 
0..1 Zero ou uma instância. 
1 Somente uma instância. 
0..* Zero ou mais instâncias. 
* Default, número mínimo e máximo de instâncias são 
ilimitados. 
1..* Uma ou mais instâncias. 
..* Número exato ou mais instâncias. 
Tabela 01 – Valores da Multiplicidade 
 
 
Prof. Sérgio Luiz Tonsig 
8 
 Na figura 6, é observado o uso da multiplicidade. 
 
Figura 6 - Multiplicidade 
 
 As leituras possíveis seriam: 
a) Um determinado aluno possui nenhuma até muitas matrículas. 
Isso as vezes pode não ter muito sentido. Como aluno não tem nenhuma matrícula? Para 
responder temos que pensar no tempo. Em um determinado momento no sistema de 
informação o aluno é cadastrado. Nesse momento, ele não tem registro de matrícula 
ainda. Outro detalhe é que foi colocado como fato máximo o símbolo para muitas. Poderia 
ser delimitado conforme a regra da instituição, se existir. Por exemplo, nessa instituição o 
aluno só pode estar, ao mesmo tempo, matriculado em dois cursos; então, ao invés de 
“*” se colocaria 2. 
b) Uma determinada matrícula pertence a um e somente um aluno. 
 
Veja que não foi colocado em aluno um número máximo, mínimo. Apenas 1. Ou seja, é 
um número absoluto. É o máximo e mínimo. Mas, a notação poderia sim estar: 1..1. 
 
Os dois pontos entre os números, se lê: até. 
 
1.1.1.1.2. Qualificadores 
 
 Um qualificador (figura 7) é um ou mais atributos presentes em uma associação, tal que, seus 
valores servem para restringir o conjunto de instâncias associadas nas classes envolvidas. 
 
 
Figura 7 – Qualificador 
 
 
 
Prof. Sérgio Luiz Tonsig 
9 
 Veja na imagem 7 a classe Matrícula. Os qualificadores estão representados por aqueles 
retângulos, à direita e esquerda, encostados na classe. Dentro que cada qualificador é especificado 
um atributo que deve existir na classe matrícula e na classe com a qual ela encontra-se associado. 
 Uma classe que possui o qualificado é uma classe dependente. Um objeto seu só conseguirá 
existir, se antes existir um objeto da classe com a qual está associada. No exemplo da figura 7, 
matrícula só existirá se, antes, existir aluno e também curso. 
 
1.1.1.2. Exemplo de um diagrama de classes 
 
 Para exemplificar um diagrama completo de classes, é apresentado abaixo um “enunciado”, 
onde consta o entendimento sobre matrículas em certa instituição, após ter sido realizado o 
levantamento de requisitos. 
 “Em uma instituição de ensino o aluno faz matrícula para um determinado curso. Um aluno 
pode matricular-se em até dois cursos diferentes. Cada curso possui um conjunto definido de 
disciplinas. Um curso pode ter diferentes turmas, que são definidas em função de uma quantidade 
máxima de matrículas permitidas. Caso não existam matrículas para um determinado um curso, o 
mesmo não é ministrado; porém, ele continua a existir”. 
 
 
Figura 8 – Diagrama de Classes 
 
 
 
Prof. Sérgio Luiz Tonsig 
10 
 Não existe uma única modelagem possível. Dado um certo problema, poderão haver vários 
caminhos para sua solução, todos igualmente válidos. O que pode ocorrer é que, em uma das 
soluções, haverá maior performance que em outra, ou mais restrições, etc. 
 Veja pode exemplo, no diagrama da figura 8. Se alguém perguntar: quais são os cursos que o 
“José da Silva” está matriculado? É possível extrair a resposta, pois a partir de um (ou mais) objeto 
aluno, cujo nome seja igual a “José da Silva”, se encontra seu correspondente código e, na sequência, 
busca-se as matrículas que possuem esse código de aluno e, então, se acessa a turma, que por sua 
vez, nos remete ao curso. Alguém poderia questionar essa trajetória e sugerir acrescentar um 
relacionamento de associação entre matrícula e curso. Então, teríamos uma variação dessa solução 
inicial e, não estaria errado. 
 
1.1.2. Diagrama de Pacotes 
 
Diagramas de pacotes são diagramas estruturais usados para mostrar, em uma forma de 
pacotes, a organização e disposição de vários elementos de modelos. 
Um pacote é um agrupamento de elementos UML relacionados, como diagramas, 
documentos, classes ou até mesmo outros pacotes. Cada elemento é colocado dentro do pacote e é 
representado como uma pasta de arquivo dentro do diagrama, e depois organizado 
hierarquicamente no diagrama. 
Diagramas de pacotes são bastante usados para proporcionar uma organização visual de uma 
arquitetura em camadas de qualquer classificador UML, por exemplo, um sistema de software. 
 
Figura 9 – Diagrama de Pacotes 
 
 
Figura 10 – Diagrama de Pacotes com classes 
 
 
 
Prof. Sérgio Luiz Tonsig 
11 
1.1.2.1. Benefícios de um Diagrama de Pacotes 
 
Um diagrama de pacotes bem projetado oferece inúmeros benefícios para quem precisa de 
uma visualização de seu sistema ou projeto UML. 
 O diagrama fornece uma visão clara da estrutura hierárquica dos variados elementos 
UML dentro de um determinado sistema. 
 Esses diagramas podem simplificar diagramas de classes complexos, criando 
elementos visuais organizados. 
 Eles oferecem uma ótima visibilidade geral de projetos e sistemas de grande escala. 
 Os diagramas de pacotes UML podem ser usados para esclarecer de forma visual uma 
grande variedade de projetos e sistemas. 
 Os elementos visuais podem ser atualizados com facilidade conforme a evolução dos 
sistemas e projetos. 
 
 
1.1.3. Diagrama de Objetos. 
 
 O diagrama de objetos (figura 11) consiste em uma variação do diagrama de classes onde, 
em vez de classes, são representadas instâncias e ligações entre instâncias. A finalidade é descrever 
um conjunto de objetos e seus relacionamentos em um momento no tempo. Esse diagrama não é 
normalmente incluído em um projeto de análise, pode servir para uma inspeção de aspectos da 
modelagem, uma vez que as instâncias podem dar uma visão mais concreta sobre a exatidão do 
diagrama de classes correspondente. 
 
 
 
Figura 11 – Diagrama de Objetos 
 
 
 
Prof. Sérgio Luiz Tonsig 
12 
 
1.2. Visão de Processo. 
 
1.2.1. Diagrama de Sequência 
 
 Como o próprio nome informa, o diagrama de sequência é empregado para demonstrar 
sequências de operações no tempo. Utilizando-se o diagrama para expressar as operações de um 
caso de uso, é possível estabelecer quais métodos devem ser acionados para quais ações realizadas 
pelo ator na interface. 
 Portanto, se consegue através do diagrama de sequência: 
 Mostrar a dinâmica da interação entre o Atore a Interface 
 Mostrar como a interface aciona os recursos necessários, quando o ator requisita 
 Mostrar a(s) classe(s) que conterão os recursos necessários 
 Mostrar possíveis trocas de mensagens entre as classes 
 Ajudar o analista a definir classes, casos elas não existam ainda. 
 
 
Figura 12 – Caso de Uso e Mockup de Tela 
 
 Considere a situação mostrada pela figura 12. Em um sistema hipotético, o analista definiu 
que tem que existir um caso de uso chamado “Cadastrar Cursos” e, para esse caso de uso, criou uma 
interface (tela). 
 Na tela há três campos. Imagine que o ator “Coordenação” digita o conteúdo dos três campos 
e depois clica no botão “Inserir” que está na tela. A pergunta é: O que vai acontecer? 
 Claro, qualquer um de nós, nesse exemplo, poderia dizer algo como “...ah, ele vai inserir os 
dados”. Certo. Onde? Como? 
 Percebe que para criação do programa que vai cuidar de realizar as ações definidas nos botões 
dessa tela, é necessário “enxergar um pouco além” ou “o que está por trás” dessa tela? 
 
 
Prof. Sérgio Luiz Tonsig 
13 
 O diagrama de sequência pode ser utilizado para essa finalidade. 
 
 
Figura 13 – Diagrama de Sequência 
 
 Na figura 13 há um diagrama de sequência que mostra as ações esperadas do sistema, quando 
o ator interagir com algum botão existente na tela. Inicialmente se vê o ator “Coordenação” enviando 
uma mensagem ( digitar ) para a tela. Essa mensagem está representando genericamente toda e 
qualquer ação do ator na tela. Poderia ter sido feito de outra forma, uma mensagem para cada campo 
a ser digitado, ou botão a ser clicado. 
 Ainda na figura 13, olhando a coluna do objeto “telaCadCurso”, há varias situações condições 
(chamada autodelegação), que tem o nome de um botão, se clicado, o procedimento correspondente 
é acionado. Então, para cada botão temos a visão exata de qual método será executado e, em qual 
classe ele está definido. 
 
1.2.2. Diagrama de Estados 
 
 O diagrama de estados demonstra o comportamento de um objeto através de um conjunto 
de transição de estados. 
 Um estado representa a situação que um objeto se encontra em um determinado momento, 
durante o período em que esse participa de algum processo. Um evento gera a transição de um 
estado para outro (figura 14). 
 
 
Prof. Sérgio Luiz Tonsig 
14 
 
Figura 14 – Estados 
 
 Na figura 15 observa-se a transição de estados possíveis para um pedido de compra em certa 
empresa. Veja que em outra empresa, o pedido de compra pode ter outro ciclo e outros estados; 
portanto, os estados dependem de regras de negócio da empresa. Há exceções, se for feito um 
diagrama de máquina de estados para um semáforo, por exemplo (não importa o município, ou 
qualquer outra questão, existe uma regra nacional de funcionamento). 
 
Figura 15 – Estados e um pedido de compra 
 
 
O diagrama de estado se inicia onde existe a imagem de um círculo preenchido e, finaliza na 
imagem com dois círculos concêntricos. Na figura 15, o diagrama possui em seu fluxo, dois símbolos 
de fim. 
 
 
 
 
 
 
 
 
Prof. Sérgio Luiz Tonsig 
15 
 
1.2. Visão de Implementação. 
 
1.2.1. Diagrama de Componentes 
 
 Um componente mostra a estrutura física pretendida para uma implementação. Um 
componente é uma estrutura física feita de bits e bytes. Exemplo: executáveis, bibliotecas (.dll, .jar), 
documentos, página HTML, um arquivo .txt, etc. 
 Visualmente um componente pode ter os aspectos conforme mostra a figura 16. 
 
Figura 16 – Componentes 
 
 Um componente expõe suas interfaces (métodos públicos) para o mundo externo. Interfaces 
esperadas se encontram com interfaces fornecidas (figura 17). 
 
 
Figura 17 – Interfaces dos Componentes 
 
 Um exemplo completo e intuitivo para um certo contexto pode ser visto na figura 18. 
 
Figura 18 – Diagrama de Componentes 
 
 
Prof. Sérgio Luiz Tonsig 
16 
 A interface que se parece como “um alfinete” representa a interface na qual um componente 
produz informações usadas pela interface necessária de outro componente. O outro tipo de interface 
com um traço e um semicírculo (que pode ser representado também através de uma seta com a linha 
tracejada) representa um componente que requer informações para executar uma função. 
 
1.3. Visão de Implantação. 
 
1.3.1. Diagrama de Implantação 
 
 O diagrama de implantação representa como será a distribuição do sistema através de “nós 
de hardware” (figura 19). 
 
Figura 19 – Nó de Hardware 
 
 Um diagrama de implantação modela o inter-relacionamento entre recursos de 
infraestrutura, rede e dispositivos. O foco do diagrama é a estrutura física sobre a qual o software 
irá ser executado. Cada nó é uma máquina física (figura 20). 
 
 
Figura 20 – Dois nós de Hardware 
 
 A figura 21 dá uma ideia de como pode ser representado os componentes de software nos 
respectivos hardwares onde irão ser executados. Essa visão é uma alternativa que se tem para 
mostrar a integração entre componentes e hardware que se planeja para um determinado sistema. 
 
 
Prof. Sérgio Luiz Tonsig 
17 
 
Figura 21 – Diagrama de Implantação 
 
 
 
1.3.2. Diagrama de Tempo 
 
Utilizados quando o propósito primário do diagrama é motivado pela análise do tempo. 
Os diagramas de tempo (figura 22) se concentram em condições que mudam dentro e 
entre linhas de vida ao longo de um eixo de tempo linear. 
 
Figura 22 – Diagrama de Tempo 
 
O diagrama de tempo permite a inserção de gatilhos que determinam no objeto alguma 
mudança decorrente do tempo, como por exemplo “A pessoa deve acordar entre as 5:40 da manhã 
e as 6 da manhã” (figura 23). No objeto pessoa, o gatilho que provoca uma mudança de estado, de 
“dormir” para “acordar”, é determinada pelo tempo. 
 
 
Figura 23 – Gatilho no Diagrama de Tempo 
 
 
 
Prof. Sérgio Luiz Tonsig 
18 
O diagrama da figura 24, mostra o vírus alterando seu estado entre o tempo de inatividade 
(dormência), propagação, desencadeamento e execução. A restrição de duração é mostrada como 
uma associação gráfica entre um intervalo de duração e as construções que ele restringe. 
 
 
Figura 24 – Estágios de um vírus de computador 
 
 
 
 
 
Prof. Sérgio Luiz Tonsig 
19 
1.9. Modelo M.V.C. e o Diagrama de Classes 
 
 MVC é o acrônimo de Model View Controller (Modelo, Visão e Controle). É um padrão de 
arquitetura de software (independentemente da linguagem de programação) e, a priori, não tem 
relação direta com a UML. 
 O objetivo da arquitetura MVC é separar a programação em camadas. A parte de interface 
(telas) é a View, também chamada de lógica da apresentação ou interface com o usuário. A parte do 
armazenamento de dados é o Model e o controle dessas duas camadas com a processamento 
propriamente dito é o Controller. 
 É uma arquitetura em três camadas; enquanto o client-server é uma arquitetura de duas 
camadas. A arquitetura MVC tem sido muito aplicada em desenvolvimentos web. 
 
 
Figura 25 – Arquitetura M.V.C. 
 
 Na UML foi padronizado uma visualização diferenciada para classes que venham a 
representar estereótipos da arquitetura MVC. O conceito de classe e sua estrutura não muda nada 
do que já foi visto. Apenas seu visual recebe uma “roupagem diferente” de acordo com a classificação 
no contexto MVC. 
Ao construir o diagrama de classes, mas com a intenção de que seja refletido o conceito de 
MVC, é possível estabelecer uma classificação através de três visuais para as classes estereotipadas, 
conforme pode ser visto na figura 26. 
 
 
Figura 26 – Classes Estereotipadas para MVC 
 Na figura 26, o primeiro elemento visual, sobre o qual tem-se > é um estereótipo 
para classes do tipo View; isto é, aquelas que irão tratar exclusivamente de trabalhar os elementos 
visuais da interface com o usuário; ou seja, tratada linha fronteiriça (fronteira) entre o sistema e o 
usuário. 
 
 
Prof. Sérgio Luiz Tonsig 
20 
 A classe do tipo > determinam classes que realizam a lógica do negócio, realizando 
cálculos e outros processamentos, fazendo também a intermediação com os outros dois tipos de 
classe. 
 A classe do tipo > representa o armazenamento de dados. Nessa classe se espera 
apenas as operações relativas a gravação, consulta, alteração ou exclusão de dados do modelo de 
armazenamento. 
 Assim, uma “classe normal” passaria ser representada por três (figura 27), formando uma 
totalização, só que cada uma dessas partes, teria um foco específico, com os correspondentes 
métodos e atributos; ou seja, por exemplo, o método gravar() estaria na classe do tipo model, um 
método maximizarTela(), estaria na classe do tipo view e, assim sucessivamente. 
 
 
Figura 27 – Modelo MVC nas Classes 
 
 
 
 
 
 
Prof. Sérgio Luiz Tonsig 
21 
2. Modelagem para WEB 
 
Atualmente há uma grande quantidade de propostas para modelagem web. Cada uma tem 
sua própria notação visual e regras. Portanto, sem uma metodologia padrão. Muitas dessas 
propostas utilizam recursos da UML, com inclusão de extensões visuais, aos componentes existentes. 
Algumas das notações que se apresentam como propostas para modelagem Web: 
 HDM 
 RMM 
 OOHDM 
 ARANEUS 
 STRUDEL 
 TIRAMISU 
 WebML 
 UML Web Application Extension 
 Engenharia Web baseada em UML (UWE) 
 ACE 
 WebArchitect 
 OO-H 
 
2.1. Modelagem UX 
 
A modelagem UX (User eXperience) tem total foco e uma busca constante em obter uma 
compreensão profunda dos usuários, (o que necessitam e o que eles avaliam, além também das suas 
limitações e suas habilidades). 
Um profissional de UX faz um trabalho com intuito de conhecer os objetivos dos clientes e 
dos negócios foco do trabalho. As melhores práticas de UX promovem o aperfeiçoamento da 
qualidade de interação dos usuários. 
 
2.1.1. O que é a experiência do usuário? 
 
Quando um produto está em desenvolvimento, é comum que pensemos em suas 
funcionalidades. A expressão “o que o produto faz” será à priori o foco e ideias para aprimorar as 
funções surgirão como tentativa de agradar ao máximo o público alvo. 
Não é um pensamento apenas dos desenvolvedores do produto, mas algo que se estende aos 
usuários. As principais críticas dos usuários que podem surgir são sempre destinadas ao mal 
funcionamento. Quando as críticas são devidas a não satisfação de expectativas, provavelmente 
 
 
Prof. Sérgio Luiz Tonsig 
22 
havia nos desejos do usuário funcionalidades que acabaram não existindo ou não cumprindo o que 
prometiam, ou seja, no meio de várias expectativas, muitas eram relacionadas a funcionalidade. 
A experiência do usuário dá ênfase a um outro lado, deixando o “o que isso faz” para ir ao 
“como isso funciona” e esse foco pode ser a diferença entre o sucesso e o fracasso do produto. 
De forma breve, experiência do usuário é a experiência que um produto cria a uma pessoa 
quando ela faz seu uso. Quando o usuário entra em contato com o produto que possui em suas mãos, 
a resposta das interações gera experiências ao usuário, como por exemplo, sensações e sentimentos, 
e essas são as chamadas experiências do usuário. 
As perguntas que se faz a um usuário e que estão ligadas a avaliação da experiência do usuário 
são todas aquelas voltadas ao o que ele sentiu durante a interação. Como foi usar o produto? Como 
você se sentiu ao interagir com ele? Foi simples? O que te fez se sentir angustiado ou irritado? Essas 
e demais perguntas podem nos fazer compreender um pouco mais do interesse da área e o que ela 
realmente é. 
 
2.1.1. Como modelar para WEB. 
 
Muitos consumidores já escolheram alguma vez um produto no lugar de outro pelo belo 
visual. 
A preferência por um produto de melhor aspecto visual acontece principalmente quando 
temos dois desses com a mesma função. Se nesse mesmo caso o público alvo for de pouca idade, 
aspectos visuais passam até mesmo a sobressair aos aspectos funcionais. Sendo assim, um produto 
bem elaborado também é um produto com belo visual. 
O desenvolvimento de um projeto que destina parte de seu tempo ao foco da experiência do 
usuário agrega boas vantagens. Pensar em experiência do usuário é pensar além do que a 
funcionalidade e visual podem proporcionar, tentando harmonizá-los com o contexto do produto e 
torná-lo natural. O conjunto visual e função corretamente unidos ao contexto não só do produto, 
mas também do usuário, podem fazer com que o usuário se sinta bem ao usá-lo, e não sofra com 
situações inesperadas. 
Com essa harmonia e naturalidade da interação do usuário com o produto, os erros são 
reduzidos, e assim, o usuário trabalhará mais rápido. Ou seja, tratar a experiência do usuário 
indiretamente influência na eficiência do produto, diferente da boa elaboração de funcionalidades 
que influenciam na eficácia. 
Agora, imagine uma cadeira com um belo visual, possuindo assento de couro e base de 
madeira, e que ela desempenhe sua função de ser sentada muito bem. 
Visualize agora que ela será usada em uma palestra de nutrição para ajuda de pessoas obesas 
a emagrecerem e que ela não está preparada para todo o contexto, já que só suporta pessoas até 80 
kg. Então, o belo visual e a boa funcionalidade não garantirão a experiência do usuário, muito pelo 
contrário, podem criar expectativas que serão destruídas com uma queda da pessoa. 
 
 
Prof. Sérgio Luiz Tonsig 
23 
Um produto bem projetado une a eficácia a eficiência. Um produto bem projetado foca em 
funcionalidades, no visual, mas também foca em aprimorar a experiência do usuário ao fazer uso das 
funções e ter os olhos agradados com um belo visual, sendo todos esses bem adaptados ao contexto 
de uso. 
 
2.1.2. Arquitetura da modelagem. 
 
 Na proposta de James Garret, há uma arquitetura de modelagem composta de cinco planos, 
conforme mostra a figura 28. 
 
Figura 28 – Modelagem UX 
 
 
a) Plano 01 - Necessidades do usuário. 
É uma fase de plano estratégico, uma etapa abstrata, ainda não sabemos o que será nosso 
produto e é nele que iremos definir nosso cenário atual e consequentemente, descobrir se o 
problema que queremos resolver realmente importa ou sequer existe. É aqui que devemos 
começar com as questões: O que? Para quê? Para quem? E com isso podemos fazer uma 
imersão nas dores de nosso usuário, ou melhor, necessidades do usuário. Partindo da ideia 
de que o produto que temos ou estamos criando é para resolver um problema, passamos a 
levantar hipóteses para saber como podemos resolvê-lo. É uma fase em que conversamos 
com os stalkeholders e alinhamos as necessidades que encontramos ao nosso objetivo de 
 
 
Prof. Sérgio Luiz Tonsig 
24 
negócio. Podemos encontrar as informações que precisamos através de entrevistas, 
pesquisas qualitativas e quantitativas. 
 
b) Plano 02 – Escopo. 
O plano de escopo pode ser tido por diferentes pontos de vistas, pois ele torna-se moldável 
ao fato de você estar desenvolvendo um produto novo, ou estar apenas lançando uma feature 
(release), por exemplo. 
Após o plano de estratégia, é hora de validar e entrar numa parte mais prática, que seria o 
papel do escopo. Nesta etapa já sabemos de forma mais concreta o problema que precisamos 
resolver e agora é hora de começar a materializar o plano anterior, e pensar em 
funcionalidades. O escopo pode ser dividido entre especificações funcionais e requisitos de 
conteúdo. As especificações funcionais consistem em uma função que nosso produto deverá 
atender. Já os requisitos de conteúdo, são as informações que precisamos para fornecer valor 
ao nosso usuário. 
Geralmente quando falamos em escopo, pensamos no início, meio e fim, porém na 
metodologia ágil, podemos deixar o escopo mais aberto, tornando possívelmodificar o que 
for necessário, neste processo, você também agrega valor ao seu produto. 
 
c) Plano 03 – Estrutura. 
Neste plano, temos que pensar em como o usuário irá interagir com o nosso produto, sendo 
assim, ele está dividido entre a parte de Design de Interação e Arquitetura de Informação. É 
nesta fase que serão mapeados todos os fluxos de navegação de nosso produto. No 
desenvolvimento de uma feature1, como é a árvore de navegação para que o usuário chegue 
até a funcionalidade que estamos propondo? Quais interações podemos prover para 
melhorar essa experiência? Tudo isso será definido aqui. 
 
d) Plano 04 – Esqueleto 
O esqueleto nada mais é do que nosso wireframe2. Já sabemos para quem e para que estamos 
construindo esse wireframe, e agora precisamos mostrar de uma forma mais abrangente, os 
resultados dos fluxos de navegação que encontramos nos planos anteriores. Nessa parte será 
definido o design de navegação, informação e a interface. 
 
e) Plano 05 – Superfície 
A superfície, pode ser desde interfaces, protótipos, até o produto final, uma provável solução 
do problema do usuário, que irá agregar valor ao produto. É considerada a parte concreta do 
 
1 Uma feature é uma funcionalidade do sistema que entrega um benefício ou resolve um problema do sistema. 
2 Um wireframe de site web ou website wireframe é um protótipo usado em design de interface para sugerir a estrutura de um site web e 
relacionamentos entre suas páginas. Um wireframe web é uma ilustração semelhante do layout de elementos fundamentais na interface. 
 
 
Prof. Sérgio Luiz Tonsig 
25 
produto, pois é onde o usuário terá de fato um contato com ele, baseado em tudo que foi 
levantado durante todo o processo de desenvolvimento. 
 
 
Figura 29 – Modelagem UX e a Arquitetura em Camadas. 
 
2.1.2. Fases na modelagem UX. 
 
Em termos de tempo na execução das tarefas da modelagem UX, considerando a arquitetura 
apresentada, se teria algo como mostra a figura 30. 
 
Figura 30 – Modelagem UX – Esforço no Tempo 
 
 
Prof. Sérgio Luiz Tonsig 
26 
2.2. API Web 
 
O acrônimo API - Application Programming Interface (Em português, significa Interface de 
Programação de Aplicações), trata-se de um conjunto de rotinas e padrões estabelecidos e 
documentados por uma aplicação A, para que outras aplicações consigam utilizar as funcionalidades 
desta aplicação A, sem precisar conhecer detalhes da implementação do software. 
APIs são extensamente aplicadas atualmente na Web como forma de interoperabilidade 
entre dispositivos móveis e sistemas de retaguarda. Um pequeno exemplo disso é o endpoint a 
seguir: viacep.com.br/ws/01001000/json/ (para ver funcionando, copie e cole no endereço do seu 
navegador, verá que ele retorna alguns dados do cep que corresponde a praça da Sé na cidade de 
São Paulo). 
 
 
 
Figura 31 – API na WEB 
 
2.2.1. Representações. 
 
Uma API permite a interoperabilidade entre aplicações, isso reforça ainda mais a importância 
de pensarmos em algo padronizado e, de preferência, de fácil representação e compreensão por 
humanos e máquinas, com relação ao uso e ao retorno de dados. Isso pode soar um pouco estranho 
mas veja a figura 30. 
 
Figura 32 – Tipos de representação de dados 
 
https://viacep.com.br/ws/01001000/json/
https://viacep.com.br/ws/01001000/json/
https://viacep.com.br/ws/01001000/json/
https://viacep.com.br/ws/01001000/json/
https://viacep.com.br/ws/01001000/json/
 
 
Prof. Sérgio Luiz Tonsig 
27 
Qual deles você escolheria para informar o endereço em uma carta? Provavelmente o último, 
por ser de fácil entendimento para humanos, não é mesmo? Contudo, as 3 representações são 
válidas, pois nosso entendimento final é o mesmo, ou seja, a semântica é a mesma. 
A primeira representação (formato XML) é mais verbosa, exigindo um esforço extra por parte 
de quem está escrevendo. No segundo exemplo (formato JSON) já é algo mais leve de se escrever. Já 
o último (formato YAML), é praticamente como escrevemos no dia a dia. 
Esse é o primeiro passo que precisamos dar para permitir a comunicação inter operável. E 
o mais legal é que essas 3 representações são válidas atualmente, ou seja, homens e máquinas 
podem ler, escrever e entender esses formatos. 
 
2.2.2. Pré-requisitos. 
 
Uma API da Web bem projetada deve observar: 
a) Independência da Plataforma. 
Qualquer cliente deve ser capaz de chamar a API, independentemente de como a API está 
implementada internamente. Isso requer o uso de protocolos padrão e um mecanismo 
pelo qual o cliente e o serviço Web possam entender os dados do serviço trocado. 
 
 
b) Evolução do Serviço. 
A API Web deve ser capaz de evoluir e adicionar funcionalidades, independentemente dos 
programas clientes. À medida em que a API evolui, aplicativos clientes existentes devem 
continuar a funcionar sem modificação. Todas as funcionalidades devem ser detectáveis 
para que os aplicativos clientes possam utilizá-las adequadamente. 
 
2.2.3. Arquitetura REST (Transferência de Estado Representacional) 
 
Arquitetura para criar serviços Web REST é um estilo arquitetural para a criação de sistemas 
distribuídos com base em hipermídia. A REST é independente de qualquer protocolo e não está 
necessariamente ligada a HTTP. No entanto, as implementações mais comuns de REST usam HTTP 
como o protocolo de aplicativo. 
Existe uma certa confusão quanto aos termos REST e RESTful. Entretanto, ambos 
representam os mesmos princípios. A diferença é apenas gramatical. Em outras palavras, sistemas 
que utilizam os princípios REST são chamados de RESTful. 
 
 
 
 
 
Prof. Sérgio Luiz Tonsig 
28 
2.2.4. Princípios para desenvolvimento de API REST 
 
a) APIs REST são projetadas para recursos, que se tratam de qualquer tipo de objeto, dados ou 
serviço que possa ser acessado pelo cliente. Um recurso tem um identificador, o qual se trata 
de um URI que identifica exclusivamente esse recurso. Por exemplo, o URI para um pedido 
determinada do cliente pode ser: https://meusistema.com/pedido/1 
 
b) Os softwares clientes interagem com um serviço por meio da troca de representações de 
recursos. Muitas APIs da Web usam JSON como o formato de troca. Por exemplo, uma 
solicitação GET para o URI listado acima poderia retornar este corpo de resposta: 
{"pedido":1, "valorUnit":99.90, "codProduto":1, "qtde":1} 
 
c) As APIs REST usam uma interface uniforme, o que ajuda a separar as implementações de 
cliente e de serviço. Para APIs REST baseadas em HTTP, a interface uniforme inclui o uso de 
verbos HTTP padrão para executar operações em recursos. As operações mais comuns são 
GET, POST, PUT, PATCH e DELETE. 
 
d) As APIs REST são orientadas por links de hipermídia contidos na representação. Por exemplo, 
a seguir é mostrada uma representação JSON de um pedido. Ela contém links para obter ou 
atualizar o cliente associado ao pedido. 
{ 
 “pedido":3, 
 “codProduto":2, 
 “qtde":4, 
 “vrUnitario":16.60, 
 "links": [ 
 {"rel":“cliente","href":"https://meusistema.com/clientes/3", "action":"GET" }, 
 {"rel":“cliente","href":"https://meusistema.com/clientes/3", "action":"PUT" } 
 ] 
} 
 
2.2.5. Nível de Maturidade de APIs REST 
 
As APIs, em função de suas estruturas, podem ser classificadas segundo um critério de 
maturidade, a saber: 
 Nível 0: defina um URI, e todas as operações são solicitações POST para esse URI. 
 Nível 1: crie URIs separados para recursos individuais. 
 Nível 2: use métodos HTTP para definir as operações nos recursos. 
 Nível 3: use hipermídia (HATEOAS - Hypermedia as the Engine of Application State). 
https://meusistema.com/pedido/1
 
 
Prof. Sérgio Luiz Tonsig 
29 
2.2.6. Orientações Gerais sobre APIs. 
 
a) Criar API em torno de cada recurso. Concentre-se nas entidades comerciaisque a API da Web 
se propõe a disponibilizar. Por exemplo, em um sistema de comércio eletrônico, haveriam 
clientes, produtos, vendas (carrinho) e recebimento. Atentar-se a semântica da chamada do 
recurso. 
 
 
b) O protocolo HTTP define vários métodos que atribuem significado semântico a uma 
solicitação. Os métodos HTTP comuns usados pelas APIs da Web mais RESTful são: 
 GET, que recupera uma representação do recurso no URI especificado. O corpo da 
mensagem de resposta contém os detalhes do recurso solicitado. 
 POST, que cria um novo recurso no URI especificado. O corpo da mensagem de solicitação 
fornece os detalhes do novo recurso. Observe que POST também pode ser usado para 
disparar operações que, na verdade, não criam recursos. 
 PUT, que cria ou substitui o recurso no URI especificado. O corpo da mensagem de 
solicitação especifica o recurso a ser criado ou atualizado. 
 PATCH, que realiza uma atualização parcial de um recurso. O corpo da solicitação 
especifica o conjunto de alterações a ser aplicado ao recurso. 
 DELETE, que remove o recurso do URI especificado. 
 
 
 
 
c) No protocolo HTTP, formatos são especificados por meio do uso de tipos de mídia, também 
chamados de tipos MIME. Para dados não binários, a maioria das APIs da Web oferecem 
suporte a JSON (tipo de mídia = application/json) e, possivelmente, a XML (tipo de mídia = 
application/xml). O cabeçalho Content-Type em uma solicitação ou resposta especifica o 
 
 
Prof. Sérgio Luiz Tonsig 
30 
formato da representação. Aqui está um exemplo de uma solicitação POST que inclui dados 
JSON: 
 
 
d) HATEOAS - Hipertexto como o Mecanismo de Estado do Aplicativo. 
{ 
 “codProduto":2, 
 “qtde":4, 
 “valorUnitario":16.60, 
 "links":[ 
 { 
 "rel":“cliente", 
 "href":"https://meusistema.com/clientes/3", 
 "action":"GET", 
 "types":["text/xml","application/json"] 
 }, 
 { 
 "rel":"cliente", 
 "href":"https://meusistema.com/clientes/3", 
 "action":"PUT", 
 "types":["application/x-www-form-urlencoded"] 
 }, 
 { 
 "rel":"cliente", 
 "href":"https://meusistema.com/clientes/3", 
 "action":"DELETE", 
 "types":[] 
 }] 
} 
 
 
 
 
Prof. Sérgio Luiz Tonsig 
31 
e) Controle de Versão. 
É muito improvável que uma API da Web permaneça estática. 
Uma das questões que envolvem o versionamento na WEB é a coexistência de mais de uma 
versão trabalhando sem problema, ao mesmo tempo. 
 
 
 
 
Prof. Sérgio Luiz Tonsig 
32 
3. Modelagem de Sistemas para Dispositivos Móveis. 
 
Para que se possa abordar o assunto dos dispositivos móveis e mobilidade de acesso à 
Internet, é necessário resgatar o histórico dos telefones celulares, que se tornaram equipamentos 
híbridos e grandes responsáveis pela transformação digital. Embora tenhamos outros dispositivos 
móveis (notebooks, tablets, etc.). 
A comunicação e as mídias foram impactadas como nunca, após a popularização de diversos 
equipamentos móveis que, por consequência, geraram outros desdobramentos tecnológicos 
essenciais para o funcionamento e desenvolvimento dos smartphones, os aplicativos. 
O aplicativo WhatsApp é um grande exemplo da evolução da comunicação móvel, pois se 
trata de um app híbrido de mensagem (SMS), gravação de áudio, vídeo, envio de fotos, chamadas 
via VoIP e por vídeo, e tudo isso em real time, que é a característica mais admirada pela nova 
geração. As pessoas se relacionam de maneira completamente diferente, tornaram-se 
produtoras de mídia com um equipamento em mãos, prontas para atuar e produzir 24 horas por 
dia, 7 dias por semana. 
 
 
Figura 33 – Celulares 
 
A evolução e, principalmente, a inclusão social dos dispositivos móveis, pode ser analisada nas duas 
imagens abaixo. 
 
2005 – Cerimônia posse papa Bento XVI 2013 – Cerimônia posse Papa Francisco 
Figura 34 – Cerimônias de posse de novos Papas e Dispositivos Móveis 
 
 
Prof. Sérgio Luiz Tonsig 
33 
 
 Fato curioso ainda sobre os dispositivos móveis é que em 2015 verificou-se que o volume 
deles passou a ser superior aos computadores desktop. 
 
 
Figura 35 – Desktop X Mobile 
 
3.2. Design WEB 
 
Projetar para mobile é diferente de projetar para web. O mesmo paradigma que existia 
quando surgiu a Web. Projetar para a Web não é a mesma coisa que projetar para desktop. 
O que funciona no desktop, com o usuário sentado na frente do computador, tem grande 
chance de não funcionar adequadamente nos vários contextos da Web ou mobile. Há muito tempo 
os dispositivos móveis já superaram em volume, os desktops; então, projetar Mobile First. Ou ainda, 
considerar um desenvolvimento específico. 
 
 
Figura 38 – Estratégias 
 
 
Prof. Sérgio Luiz Tonsig 
34 
3.3 O que é Design? 
 
 
 
3.3.1. UX e UI 
 
UX (User eXperience) ou Experiência do Usuário, é o estudo comportamental dos usuários, 
com o objetivo de entregar uma melhor experiência de uso nos produtos sendo eles digitais ou não. 
Busca compreender dificuldades e problemas do usuário no uso do produto e, procura entregar a 
solução mais amigável possível (fácil de usar e manusear). 
UI (User Interface) ou Interface do Usuário é o trabalho de criação de interfaces, que 
compreende o projeto visual do meio com o qual interagimos em aplicativos, sites e sistemas de uma 
forma geral. 
 
 
Figura 39 – UX e UI 
 
 
Prof. Sérgio Luiz Tonsig 
35 
UX é estratégia, não design (UI). UX não é uma etapa do projeto. Todas as etapas geram 
impacto na experiência do usuário (UX). Não adianta, por exemplo, o designer fazer a melhor 
usabilidade possível e o programador de front-end ou back-end não proporcionar performance ao 
carregar uma página. 
 
3.3.2. Design centrado no usuário. 
 
Design centrado no usuário é o processo onde mantemos o foco nas necessidade, desejos e 
limitações dos usuários durante todo o projeto, a cada tomada de decisão, desde a concepção até o 
lançamento do produto. Não projetamos interface sem considerar o contexto de uso da mesma. 
Desenho inicialmente centrado no usuário e suas necessidades e, não na tecnologia. Usuário deve 
ter: 
 Facilidade de uso (interface natural, de modo que não se perceba a tecnologia, voz, 
mão) 
 Facilidade de aprendizado (memorização fácil – não me faça pensar) 
 Produtividade na execução 
 Satisfação (resultado) 
A figura 36 mostra as etapas do desenvolvimento centrada no usuário. 
 
 
Figura 40 – Etapas desenvolvimento centrado no usuário 
 
 
 
 
 
Prof. Sérgio Luiz Tonsig 
36 
3.3.3. Analisar interface e interoperabilidade. 
 
A pergunte chave nesse ponto é: Como o usuário interage, na maior parte do tempo com o 
dispositivo? As respostas vão determinar alternativas que se terá para criação de uma interface 
adequada. 
 
 
Figura 41 – Interação do usuário com celular 
 
Várias interfaces de apps e páginas mobiles, usam aquele menu “hambuger” (aqueles três 
pauzinhos), no canto superior da tela que geralmente abre o menu de opções. Seria esse o melhor 
local para se colocar o recurso? Essa é uma das avaliações a serem realizadas quando se trata de 
interface com a melhor experiência para o usuário. 
 
 
Figura 42 – Troca de lugar dos recursos de menu 
 
 
Prof. Sérgio Luiz Tonsig 
37 
Outra questão envolve, por exemplo, recursos em lista. Normalmente fotos de produtos, ou 
qualquer informação em cards3. 
Não faz sentido criar uma lista horizontal com muito itens, dificilmente o usuário vai ficar 
“rolando para o lado” infinitamente. Se a lista for um pouco grande, adicione o botão “veja todos” 
ou “veja mais”. 
 
 
Figura 43 – Cards 
 
 Sobre tamanhos e proporções, procure seguir um padrão dentro de seu aplicativo 
especialmente referente a barras de títulos, espaços entre sessões,margens e bordas. 
 
 
Figura 44 – padrões 
 
3 Os cards são pedaços interativos de informação apresentados quase sempre num formato retangular. 
 
 
Prof. Sérgio Luiz Tonsig 
38 
 
Tome bastante cuidado ao projetar a área de toque, considere as recomendações que 
seguem: 
 Se menos de 7mm não se consegue interagir com o dedo. Pode utilizar o mouse, mas não 
o dedo. 
 Área com 10mm uma boa área. 
 Uma área excelente seria de 14mm. 
 
 
Figura 45 – Área para touchscreen 
 
3.3.4. Elementos auxiliares no Design 
 
Algumas atividades auxiliares podem contribuir para definir a melhor experiência do usuário, 
incluindo a navegabilidade da interface. 
 
a) StoryBoard. 
Para qualquer projeto mobile é muito difícil saber, quantas telas, funções e interações serão 
necessárias. 
Para conseguirmos dar um preço ou organizarmos um prazo, as alternativas são criar um 
storyboard, mapas de navegação e protótipos antes de realmente fazermos o desenho das 
telas. 
 
Figura 46 - Storyboard 
 
 
Prof. Sérgio Luiz Tonsig 
39 
b) Mapa de Navegação. 
Pode ser utilizado para desenhar todos os passos de navegação que o usuário poderá ter 
no aplicativo, dessa forma, usufruindo das funcionalidades disponíveis. Esse recurso é 
interessante também para eliminar-se etapas desnecessárias (não percebidas 
anteriormente) e, deixar mais fácil a usabilidade. 
 
 
 
Figura 47 – Navegabilidade entre recursos 
 
 
 
 
Prof. Sérgio Luiz Tonsig 
40 
 
Referências Bibliográficas 
 
FILHO, W.P.P. Engenharia de Software. LTC, 4ª. Ed., Volume 1, 2019. E-Book. 
FILHO, W.P.P. Engenharia de Software. LTC, 4ª. Ed., Volume 2, 2019. E-Book. 
LARMAN, C. Utilizando UML e Padrões. BookMan, 3ª. Ed., Porto Alegre, 2007. E-Book 
PRESSMAN, R.; MAXIM, B. Engenharia de Software – Uma abordagem profissional. BookMan, 8ª Ed., 
2016. E-Book. 
SOMMERVILLE, I. Engenharia de Software. Pearson, 9ª. Ed, São Paulo, 2011. 
TONSIG, S.L. Engenharia de Software – Análise e Projeto de Sistemas. Ciência Moderna, 2ª.Ed., Rio 
de Janeiro, 2008.