O documento resume uma prova de recuperação para uma especialização em tecnologias para aplicações web, listando as disciplinas a serem cobradas e fornecendo informações sobre um curso de introdução ao gerenciamento de projetos, incluindo definições de projeto, ciclo de vida do projeto e partes interessadas.

1. 3ª Prova Pós Web - INGRESSO: 08/08/2014 - A sua prova presencial de Recuperação - ESPECIALIZAÇÃO EM
TECNOLOGIAS PARA APLICAÇÕES WEB ocorrera em:
Dia: 27/06/2015
Horario: 08:30 as 10:00 (Horario de Brasilia)
Disciplinas: PROJETOS ÁGEIS, ANÁLISE DE SISTEMAS, BANCO DE DADOS, DESIGN DE INTERFACES,
INTERAÇÃO HUMANO-COMPUTADOR
TECNOLOGIA EM ANÁLISE DE SISTEMAS
WEB AULA 1
Unidade 1 – INTRODUÇÃO AO GERENCIAMENTO DE PROJETOS
RESUMO:
O objetivo da presente unidade é apresentar os principais fundamentos
sobre gerenciamento de projetos. Nesse sentido,será abordado o ciclo de vida básico
de um projeto, suas principais tarefas e como esse processo contribui para o sucesso
de um projeto. Além disso, de forma resumida, será apresentado como estruturar
um projeto aplicando princípios básicos considerados boas práticas de gestão de
projetos. Ao final, será possível entender e aplicar ferramentas essenciais à gestão
eficiente de projetos desoftware.
DEFINIÇÃO DE PROJETO
Afinal de contas, o que é um projeto? Segundo o PMI (2008), projeto é “[...] um
esforço temporário empreendido para criar um produto, serviço ou resultado
exclusivo”. Ainda segundo o PMI:
 Temporário significa que todos os projetos possuem um início e um final
definidos. Embora não recomendado, muitos projetos ou não definem
claramente uma data de início ou terminam muito além do programado.
 Temporário não significa necessariamente de curta duração; muitos projetos
duram vários anos. Exemplo de projetos longos são as missões espaciais que
podem durar mais de uma década para serem concluídas.
 Temporário não se aplica ao resultado do projeto, que poderá perdurar por
muitos anos após a conclusão do projeto. As pirâmides do Egito são um
exemplo claro do resultado duradouro de um projeto.

2. O resultado de um projeto é exclusivo, único.
Saiba mais sobre os principais conceitos em gestão de
projetos:http://www.gestaodeprojeto.info/introducao
Mas o que pode ser administrado como um projeto?
Projetos surgem, por exemplo, de problemas ou oportunidades pessoais ou
organizacionais.Logo, projetos lidam com situações não muito comuns. Por exemplo,
uma empresa de software deseja implantar um novo procedimento de teste
de software. Nesse sentido, projetos envolvem muitas incertezas e geralmente geram
mudanças ao acrescentarem algo novo.
Então, projetos não lidam com situações do dia a dia, ou seja, projetos não
administram rotina. Rotinas geralmente não envolvem incertezas e o resultado é
previsível.

3. Muitas palavras novas? Baixe um pequeno dicionário de “Projetês” no
endereço:http://www.gestaodeprojeto.info/arquivos/PMBOK_Port_glossario.zip?attr
edirects=0
Entretanto, gerenciar por meio de projetos não se aplica somente no ambiente
organizacional, você pode administrar determinados objetivos pessoais por meio de
projetos. Por exemplo, o curso de especialização que você está fazendo poderia ser
administrado por meio de um projeto. Note que o curso é algo novo em sua vida, irá
acrescentar algo à sua vida profissional, deverá ser realizado num determinado
prazo, envolverá custos, riscos, ou seja, exigirá um planejamento que possibilite que
você atinja seu objetivo: ser um especialista em Desenvolvimento de Aplicações Web
Baseadas na Tecnologia JAVA.
Vídeo: o que é um projeto:
O quadro 1 apresenta algumas diferenças entre rotina e projeto.
Saiba mais:
Maximiano (2010, p. 4-13) apresenta uma visão geral sobre projetos.
CICLO DE VIDA DO PROJETO

4. Como os projetos são organizados? Projetos podem ser divididos em fases que
possibilitam melhor controle gerencial. O ciclo de vida do projeto define as fases que
conectam o início de um projeto ao seu final.
Segundo o PMI (2008), um ciclo de vida (vide figura 1) é um processo que determina
um conjunto de ações e atividades inter-relacionadas realizadas para obter um
conjunto pré-especificado de produtos, resultados ou serviços.
Cada uma das fases define um grupo de processos que são aplicados iterativamente
(de forma incremental) e repetitivamente. Segundo Trentim (2011), o grupo de
processo de Inicialização é responsável pela definição e autorização de um novo
projeto; o grupo de processos de Planejamento define o que será feito e como será
realizado; o grupo de processos de Execução coloca em prática o planejamento; o
grupo de processo de Monitoramento e Controle verifica se a execução está em
conformidade com o planejado e o grupo de processo de Encerramento é responsável
pela finalização do projeto.

5. Como pode ser percebido, o ciclo de vida do projeto ajuda a organizar todos os
processos necessários à realização do projeto. Ele estabelece uma sequência, agrupa
processos comuns, dá uma visão geral sobre todo o percurso que deverá ser realizado
entre o início e o término do projeto entre outras vantagens.
Então, o ciclo de vida de um projeto é um fatorimportante para o sucesso do projeto.
O ciclo de vida do projeto é similar a um mapa: um mapa indica o início, o destino,
a rota que conduz ao destino, os locais pelos quais deveremos passar, dá uma noção
do progresso, ou seja, onde estou no trajeto?
Ao pensar sobre o ciclo de vida de um determinado projeto, considere algumas
questões que deverão ser respondidas:
» Que trabalho técnico deve ser realizado em cada fase. Por exemplo, em qual fase
deve ser realizado o trabalho do Analista de Sistema, Programador, Administrador
do Banco de Dados (DBA), etc.
» Quando as entregas devem ser geradas em cada fase e como cada entrega é
revisada, verificada e validada. Por exemplo, quando o diagrama Entidade
Relacionamento (DER) deverá ser entregue? Quem irá revisá-lo? Quando será
revisado?

6. » Quem está envolvido em cada fase. Por exemplo, na fase de planejamento do
projeto deverá ser coletado os requisitos do software, então, quais são os
interessados (stakeholders)?
» Como controlar e aprovar cada fase. Por exemplo, quando sei que a atividade
Engenharia de Requisitos foi concluída, como saberei se a atividade está dentro do
prazo? Como saberei se realmente a atividade foi concluída? Quais critérios indicam
que a atividade foi concluída dentro das expectativas?
Saiba mais:
Ciclo de vida do projeto de software:
http://www.oficinadanet.com.br/artigo/1912/o_ciclo_de_vida_de_um_projeto_de_i
nformatica
Vídeo: ciclo de vida do projeto:
Normalmente um projeto envolve diretamente e indiretamente vários interessados
(stakeholders[1]) e saber quem está envolvido no projeto é um fatorimportantíssimo
para o sucesso do projeto. Por exemplo: imagine que você irá construir uma casa
nova para sua família. Esse projeto irá envolver diversas pessoas, principalmente sua
família. Então, imagine que você deixou de ouvir sua família sobre quais
características a casa deveria ter. O que você acha que aconteceria quando sua
família se mudasse para a nova casa? Será que eles a aprovariam? Bom, talvez sim,
ou talvez a desaprovassem por completo, ou talvez dissessem “acho que poderia ser
assim”, etc., etc.
Partes interessadas no projeto podem ser pessoas ou organizações ativamente
envolvidas no projeto ou cujos interesses podem ser afetados com o resultado da
execução ou do término do projeto. Eles podem também exercer influência (positiva
ou negativa) sobre os objetivos e resultados do projeto.
[1] Stakeholders é um termo em inglês muito utilizado na literatura. Nesse material, stakeholder será
empregado comointeressado.

7. Exemplo de interessados:
Clientes que comprarão e/ou usarão o produto resultante do projeto, órgãos ou
agências regulamentadoras que podem interferir no projeto, pessoas ou organizações
que disponibilizarão recursos ao projeto, pessoas ou organizações afetadas pelo
projeto, parceiros ou terceiros que participarão do projeto, equipe de Projeto,
fornecedores de produtos ou serviços ao projeto, competidores/concorrentes, etc.
Trentim (2011) apresenta um exemplo resumido no formato de uma tabela (vide
figura 2) de informações que poderiam ser registradas sobre as partes interessadas
no projeto. A tabela destaca, por exemplo, o interesse de cada parte interessada, a
influência dessa parte interessada no projeto e o impacto que essa parte poderia
provocar no projeto.

8. Quer saber mais sobre as partes interessadas? Acesse o endereço:
http://www.gestaodeprojeto.info/analise-dos-stakeholders
Gerente de Projeto
O gerente de projeto (ou GP) desempenha um papel fundamental no projeto, ele é o
responsável global por todo trabalho realizado no projeto. Além disso, o gerente atua
como um meio, uma interface, entre o projeto e os interessados nele. O GP é um
cargo temporário, ou seja, ele existe enquanto o projeto existir. Normalmente o
gerente é definido logo nas etapas iniciais do projeto.
Dentre tantas responsabilidades, o GP supervisiona o planejamento,
desenvolvimento e operação do projeto. Cleland; Ireland (2007) listam outras
responsabilidades atribuídas aos gerentes de projeto:
» redistribuem recursos conforme a necessidade do projeto;
» monitoram a competência da equipe do projeto;
» gerenciam mudanças;
» monitoram o prazo, custo, risco, qualidade, etc. do projeto;
» relatam o andamento do projeto aos interessados;

9. » motivam a equipe.
Saiba mais:
Ouça o PODCAST de Ricardo Vargas sobre as responsabilidade do
GP: http://www.ricardo-vargas.com/pt/podcasts/projectmanagerresponsibilities/
Vídeo: Perfil profissional do GP:
OS DESAFIOS DO PROJETO
Gerenciar projetos implica numa “batalha” diária entre algumas restrições: tempo,
custo, qualidade, escopo e satisfação do cliente. Note que essas variáveis reagem
quando se modifica uma delas.
Por exemplo, o que aconteceria se você percebesse que o projeto está atrasado e
que precisa recuperar o tempo para entregar no prazo? Bom, você poderia apontar
algumas alternativas, por exemplo: contratar mais pessoas ou trabalhar um pouco
mais (hora extra). Acredito que você tenha percebido que essas duas medidas podem

10. provocar um impacto na outra variável: o custo. Logo, para recuperar o tempo terei
que aumentar o custo.
Vamos assistir a vídeo aula 1
Outra alternativa para realizar o projeto dentro do tempo estimado sem aumentar o
custo seria deixar de realizar algumas tarefas. Entretanto, isso poderia impactar na
qualidade do projeto. Então, caberá ao gerente de projeto a árdua habilidade de
equilibrar essas variáveis, de decidir se aumentará o custo ou diminuirá a qualidade.
Ou melhor, qual o ponto de equilíbrio entre entre custo, tempo, qualidade e escopo
que resulte na satisfação do cliente.
PMI e PMBOK
Como você percebeu, gerenciar projetos envolve muito conhecimento, apresenta
muitos desafios e envolve muitos riscos. Logo, você poderia se perguntar, diante de
tanta complexidade, serei eu capaz de administrar um projeto? Realmente, é muito
difícil e quase sempre, diante de uma nova área, nos sentimos incapazes.
Entretanto, em 1969, na Pensilvânia (EUA), cinco voluntários também se depararam
com as mesmas questões.Então, eles decidiram fundar o PMI – Project Management
Institute (ou, em português, Instituto de Gerenciamento de Projetos). O PMI é uma
organização sem fins lucrativos e atualmente está presente em mais de 185 países
com mais de 650.000 membros associados.

11. O PMI está organizado em capítulos que são estabelecidos nos mais diferentes países.
São mais de 250 capítulos estabelecidos em todo mundo. No Brasil já foram
estabelecidos 13 capítulos. Segundo o PMI, essas comunidades, abertas a membros
do PMI e dirigidas por voluntários, dão suporte para a troca de conhecimento e para
redes de trabalho, pontos centrais da missão do PMI.
Saiba mais sobre o PMI:
Acesse o endereço: http://brasil.pmi.org
Entre os principais objetivos do PMI encontra-se o desenvolvimento de
conhecimentos para gerenciamento de projetos e, certamente, uma das principais
contribuições do PMI é o guia PMBOK – Project Management Body of Knowledge (ou,
em português, Guia para o Corpo de Conhecimento em Gerenciamento de Projetos).
PODCAST: PMBOK quarta edição:
http://www.ricardo-vargas.com/pt/podcasts/newpmbok/
Segundo o PMI (2008), o Guia PMBOK identifica um conjunto de conhecimento em
gerenciamento de projetos amplamente reconhecido como uma boa prática. O PMI
ainda enfatiza que “boa prática” significa que existe um consenso geral de que a
aplicação correta dessas habilidades, ferramentas e técnicas pode aumentar as
chances de sucesso em uma ampla gama de projetos.

12. Logo, o Guia PMBOK é uma fonte indispensável de conhecimento para quem pretende
gerenciar um projeto. Os conteúdos do Guia PMBOK estão separados por área de
conhecimento para as quais são definidos e explicados os processos necessários à
sua aplicação. Deve-se deixar claro, entretanto, que cabe ao usuário do Guia definir
como o conhecimento será aplicado, então, o Guia apenas sugere boas práticas e,
portanto, cabe ao usuário avaliar sua pertinência em relação ao projeto ao qual se
pretende aplicar as boas práticas propostas pelo Guia.
O Guia é constantemente atualizado e encontra-se atualmente em sua 4ª edição,
distribuída em 2008. Nessa edição, o conteúdo do Guia apresenta 42 processos. Os
42 processos podem ser divididos de duas formas (vide figura 3): agrupados por
áreas de conhecimento ou agrupados por grupos de processos.

13. Fonte:
http://www.pmtech.com.br/artigos/Processos_PMBOK_4a_Mauro_Sotille.pdf.
Na figura 3, do lado direito, pode-se observar uma legenda. Nessa legenda são
apresentadas as 9 áreas de conhecimento com sua respectiva cor e ícone:
Integração, Escopo, Tempo, Custos, Qualidade, RH (Recursos Humanos),
Comunicação, Riscos e Aquisição. Pode-se perceber ainda na figura 3 que os
processos (retângulos numerados) possuem uma cor e um ícone (Figura 4).
Considerando esses dados e tomando como exemplo o processo “4.1 Desenvolver o
termo de abertura do projeto” localizado no topo do lado esquerdo da figura,
podemos classificar esse processo na área de conhecimento Integração. Então, todo
retângulo na cor “amarelo claro” e que apresenta o ícone “estrela” é classificado como

14. um processo de Integração. Você perceberá que existem 6 processos de integração
espalhados pela figura.
Também perceberá que os processos espalhados pela figura, na verdade, estão
contidos dentro de uma divisão. Cada uma das divisões é um grupo de processos.
Tomando ainda como exemplo o processo 4.1 “Desenvolver o termo de abertura do
projeto”, você perceberá que ele está numa divisão intitulada “Processos de
Iniciação”. Você notará ainda que apenas dois processos são classificados como
processo de Iniciação.
Vídeo: Grupos de processos PMBOK:
Esses dois modos de visualizaros processos de gerenciamento sugeridos pelo PMBOK
estão relacionados e são úteis da seguinte forma, por exemplo: Se você estiver na
fase de Planejamento de um projeto, quais processos você poderia empregar para
planejar seu projeto? Considerando a figura 3, você perceberá que o PMBOK sugere
20 processos que podem ser realizados no planejamento de um projeto.
Quer saber mais sobre o PMI e PMBOK? Acesse o
endereço:http://www.linhadecodigo.com.br/artigo/974/iniciacao-ao-pmbok-no-
gerenciamento-de-projetos.aspx
Por outro lado, se você estiver avaliando os possíveis riscos de seu projeto, quais
processos poderiam ser realizados? Nesse caso você irá localizarna figura 3 todos os

15. seis processos que possuem o ícone “raio” (eles estão distribuídos em dois grupos de
processos: “Planejamento” e “Monitoramento e Controle”). Esses processos são
processos relacionados ao gerenciamento de riscos de um projeto.
O Guia PMBOK é um tema relativamente extenso. O propósito aqui foi propiciar uma
visão ampla sobre seu conteúdo e organização. Conhecer as boas práticas
apresentadas pelo Guia certamente é uma leitura recomendada para todos aqueles
que querem aprofundar seus conhecimentos em gerenciamento de projetos.
O Guia PMBOK é uma leitura obrigatória para quem tem interesse em gestão de
projetos.
Você pode obter mais informações sobre a aquisição do Guia PMBOK no
endereço:http://brasil.pmi.org/brazil/PMBOKGuideAndStandards.aspx
GRUPOS DE PROCESSO
Como apresentado anteriormente, os 42 processos do PMBOK estão agrupados em
5 grupos: Iniciação, Planejamento, Monitoramento e Controle, Execução e
Finalização. A intenção em agrupar os 42 processos é organizá-los e permitir que se
tenha uma visão do progresso do andamento do projeto.

16. Segundo o PMI (2008), cada grupo de processo possui, de modo geral, as seguintes
responsabilidades.
Grupo de Processos de inicialização: Os processos desse grupo têm por
objetivo definir, iniciar um novo projeto ou nova etapa do projeto. Uma vez o
projeto seja autorizado a iniciar, nessa etapa é definido o gerente do projeto,
identificadas as partes interessadas e alocado os recursos entre outros processos.
Grupo de processos de planejamento: Define o escopo do projeto, ou seja, o
que será responsabilidade do projeto, refina os objetivos e estabelece as ações que
conduzirão ao objetivo geral do projeto.
Grupo de processos de execução: é formado pelos processos responsáveis
pela execução do trabalho definido no planejamento.
Grupo de processos de monitoramento e controle: nesse grupo estão os
processos responsáveis pelo monitoramento do projeto, ou seja, averigua se tudo
está ocorrendo como previsto, realizado como planejado e, caso contrário, toma
medidas para contornar da melhor forma possível eventuais problemas.
Grupo de processos de encerramento: Agrupa os processos encarregados de
finalizar todos os procedimentos, documentar as lições aprendidas, registrar todas
as informações entre outros.
Definir os processos de um projeto é como um jogo de xadrez, cada projeto
(partida) exige uma estratégia diferente.
CERTIFICAÇÕES DO PMI
Para os interessados em gerenciamento de projetos, o PMI oferece seis certificações
profissionais que tem por objetivo demonstrar que o profissional possui

17. conhecimento, experiência e competências em determinadas áreas do gerenciamento
de projetos.
As certificações emitidas pelo PMI são reconhecidas mundialmente e os profissionais
que as possui são muito valorizados no mercado. Atualmente o PMI oferece seis
certificações.
 Certificação PMP – Profissional de Gerenciamento de Projetos (PMP).
 Certificação CAPM – Técnico Certificado em Gerenciamento de Projetos.
 Certificação PgMP – Profissional de Gerenciamento de Programas.
 Certificação PMI-SP – Profissional em Gerenciamento de Cronograma do PMI.
 Certificação PMI-RMP – Profissional em Gerenciamento de Riscos do PMI.
 Certificação PMI-ACP – Profissional Certificado em Métodos Ágeis do PMI.
PODCAST: Ouça o podcast sobre a certificação CAPM:
http://www.ricardo-vargas.com/pt/podcasts/capm-certification-part-1-of-2/
Para obter uma certificação do PMI, você deve primeiramente atender aos requisitos
de elegibilidade delineados no portal do PMI e detalhados nos manuais de

18. certificações. A seguir, você deve fazer três avaliações – a revisão da inscrição, o
exame da certificação e a avaliação múltipla.
Quer saber mais sobre as certificações do PMI? Acesse o
endereço:http://brasil.pmi.org/brazil/FAQ/CertificationFAQ.aspx
PROJETOS DE SUCESSO
Segundo o PMI (2008), o ciclo de vida do projeto apresenta algumas características
comuns entre diferentes projetos (Figura 6). Essas informações são valiosas
principalmente para quem está iniciando em gestão de projetos.
Vamos assistir a vídeo aula 2
Os níveis de custos e de pessoal são baixos no início, atingem o valor máximo durante
as fases intermediárias e caem rapidamente conforme o projeto é finalizado.
Ainda segundo o PMI (2008), a influência das partes interessadas, os riscos e as
incertezas são maiores durante o início do projeto (vide Figura 7). Esses fatores caem
ao longo da vida dele. O PMI ainda afirma que, a capacidade de influenciar as
características finais do produto do projeto, sem impacto significativo sobre os
custos, é mais alta no início. Por outro lado, mudanças no projeto já no curso final
do projeto podem provocar sérios impactos negativos ao projeto. Ou seja, os custos
das mudanças e correções de erros geralmente aumentam significativamente
conforme o projeto se aproxima do término.
Os níveis de custos e de pessoal são baixos no início, atingem o valor máximo durante
as fases intermediárias e caem rapidamente conforme o projeto é finalizado.

19. Para saber mais sobre a importância do planejamento, leia o artigo disponível em
Ainda segundo o PMI (2008), a influência das partes interessadas, os riscos e as
incertezas são maiores durante o início do projeto (vide Figura 7). Esses fatores caem
ao longo da vida dele. O PMI ainda afirma que, a capacidade de influenciar as
características finais do produto do projeto, sem impacto significativo sobre os
custos, é mais alta no início. Por outro lado, mudanças no projeto já no curso final
do projeto podem provocar sérios impactos negativos ao projeto. Ou seja, os custos
das mudanças e correções de erros geralmente aumentam significativamente
conforme o projeto se aproxima do término.
Segundo o PMI (2008), para que um projeto seja bem sucedido, a equipe deve:
» Selecionar processos adequados;
» Usar uma abordagem apropriada;
» Cumprir os requisitos dos interessados;
» Equilibrar as demandas (escopo, tempo, custo, qualidade e satisfação do cliente).
Vídeo: Obtendo resultados com Gerenciamento de Projetos:
.
RESUMO
Nessa unidade foi apresentado a definição de projeto, seus benefícios e aplicações e
diferenças em relação às rotinas. Assim como outras áreas, os projetos possuem um
ciclo de vida comum, genérico, composto pelas etapas: iniciação, planejamento,
execução, acompanhamento e controle e finalização. Também foi enfatizado que é
fundamental identificar todas as partes interessadas no projeto, bem como as
principais atribuições do responsável direto pelo projeto: o gerente de projeto. Além
disso, foi apresentado a norma internacional PMBOK, mantida pelo PMI, a qual
apresenta boas práticas em gestão de projetos. Também foi descrito como os
profissionais podem obter maior aceitação no mercado por meio de certificações
profissionais. Finalmente, foram destacadas algumas características gerais sobre
projetos e fatores de sucesso.
Primeiros passos, acesse o endereço: http://www.gestaodeprojeto.info/7passos

20. CLELAND, David, I.; IRELAND, Lewis R. Gerenciamento de projetos. Rio de
Janeiro: LTC, 2007.
MAXIMIANO, Antonio Cesar Amaru. Administração de projetos: como
transformar ideias em resultados. 4. ed. São Paulo: Atlas, 2010.
MOURA, Dácio Guimarães de; BARBOSA, Eduardo F. Trabalhando com
projetos: planejamento e gestão de projetos educacionais. 2. ed. Petrópolis: Vozes,
2007.
PROJECT MANAGEMENT INSTITUTE. Um guia do conhecimento em
gerenciamento de projetos, 4. ed. Newton Square, PA: PMI, 2008.
TRENTIM, Mário Henrique. Gerenciamento de projetos: guia para certificações
CAPM e PMP. São Paulo: Atlas, 2011.
TECNOLOGIA EM ANÁLISE DE SISTEMAS
WEB AULA 1
Unidade 2 – PLANEJANDO UM PROJETO
RESUMO:
O objetivo da presente unidade é apresentar os passos básicos
sobre o planejamento de um projeto e uma visão geral sobre métodos ágeis. Nesse
sentido, será discutido o objetivo do projeto e seu papel no planejamento do
projeto. Você também irá conhecer como definir as responsabilidades de um
projeto por meio da definição do escopo. Além disso, aprenderá como dividir todo o
trabalho necessário para realizar um projeto por meio da Estrutura Analítica do
Projeto (EAP). Também entenderá porque a EAP é um dos instrumentos
fundamentais para planejar um projeto: tempo, responsabilidades, estimativas de
custo, tarefas, etc. Finalmente, será apresentada uma visão geral sobre os métodos
ágeis e, em particular, uma visão um pouco mais aprofundada sobre a abordagem
ágil SCRUM.
INICIANDO UM PROJETO: O OBJETIVO

21. “Nenhum caminho adiantará se você não sabe aonde ir.”
Definir o objetivo do projeto certamente é um dos principais passos para um projeto.
Os objetivos são descrições concretas do que o projeto está tentando alcançar. Iniciar
um projeto sem tê-lo definido claramente é praticamente sentenciar o projeto ao
fracasso.
Os objetivos do projeto (geral e específico) devem incluir os critérios mensuráveis do
sucesso do projeto: técnicos, de negócios, custo, cronograma e qualidade. Isto é,
deve ser descrito de tal forma que seja possível verificar ao final do projeto se eles
foram ou não atingidos. Nesse sentido, os objetivos do projeto podem incluir metas
de custo, cronograma e qualidade. Ou seja, Um objetivo bem escrito será específico,
mensurável, alcançável/realizável, realístico e com uma clara indicação do tempo.
Um contraexemplo de escrita de um objetivo: “Melhorar a qualidade no
atendimento ao cliente por meio da implantação de um call center”. Nesse
contraexemplo não está claro como o objetivo poderá ser verificado, pois não faz
referência a custo, tempo, datas ou critérios de qualidade. Deste modo, não seria
possível verificar se o projeto atendeu aos critérios.

22. Agora, leia a escrita de um objetivo que contém elementos que podem ser
verificados: “O projeto objetiva entregar no prazo de 180 dias a contar a partir
da data de 01/10/2008, com custo de investimento de R$ 5 milhões dentro
do padrão internacional NPCS 3001 atualmente praticados pela
corporação um serviço de call center para suportar o atendimento à clientes
da rede de Lojas Fictícia”.
Note que na descrição do objetivo constam a entrega do projeto (sublinhado
contínuo) e elementos mensuráveis (sublinhado pontilhado), ou seja, possíveis de
serem verificados: valores, prazo, data e norma de qualidade. Portanto, um objetivo
atua como um farol para um navio, um ponto de referência para onde se quer chegar.
Logo, o objetivo deve ser escrito de tal forma que fique claro o resultado pretendido.
Ouça o PODCAST sobre objetivo de um projeto:
http://www.ricardo-vargas.com/pt/podcasts/smart_objective/
O objetivo do projeto pode ser subdividido em objetivos menores. Por exemplo,
imagine que você pretenda viajar para um determinado destino, você mora em São
Paulo e pretende ir para Osasco – SP (Figura 1). Por se tratar de um trajeto curto,
aproximadamente 23 Km, normalmente, você não se preocuparia muito, pois se trata
de um trajeto relativamente simples.

23. Agora, imagine que você pretende ir de São Paulo para Dourados no Mato Grosso do
Sul (Figura 2). Bom, agora você vai pensar, é uma rota relativamente extensa,
aproximadamente 1000 Km e, para complicar, você não conhece muito bem o
trajeto. Então, o que você faria? Provavelmente, você estabeleceria a rota, ou seja,
pontos intermediários até o ponto final: São Paulo a Ourinhos, Ourinhos a Presidente
Prudente, Presidente Prudente a Presidente Epitácio, Presidente Epitácio a Glória de
Dourados e, finalmente, Glória de Dourados a Dourados. Bom, por que você varia
dessa maneira? Porque seria mais seguro você alcançar seu destino final por meio
do alcance de destinos mais curtos. A soma dos objetivos mais curtos é igual à soma
de todo o trajeto até o destino final. Essa estratégia diminui a complexidade ao lidar
com problemas menores, você resolve um problema de cada vez e, ao resolver todos
os problemas menores, você teoricamente resolveria todo o problema.
Então, considerando o exemplo acima, o destino final é nosso objetivo geral, e os
destinos intermediários são nossos objetivos intermediários.
ESCOPO
Após definiro objetivo ou objetivos do projeto, devemos reunir todos os interessados
no projeto e tratar do escopo do projeto. Mas, o que é escopo? Segundo Maximiano

24. (2010), escopo do projeto é o produto ou conjunto de produtos que o projeto deve
entregar – a um cliente, patrocinador ou usuário.
Uma analogia: imagine que o escopo do projeto é como um quebra-cabeça de
montagem de peças. Somente estará completo e terá significado se todas as peças
estiverem no seu devido lugar. Agora, considere um exemplo real: é comum
empresas de software desenvolverem para um cliente um produto de software, mas
será apenas o software a única entrega do projeto? Acredito que na maioria dos casos
não. Por exemplo, não basta apenas entregar o software, em muitos casos é
necessário instalá-lo no ambiente do cliente, logo, a implantação/instalação
do software também é uma entrega do projeto. Outras possíveis entregas seriam:
treinamento dos usuários, entrega do manual do sistema, entrega do instalador,
migração de dados do sistema antigo para o novo sistema (quando se tratar de uma
atualização), etc.
Percebe-se, portanto, que a definição do escopo, ou seja, das entregas (em inglês,
no singular,delivery) é uma parte fundamental do processo de gerenciamento de
projetos. A definição incorreta do escopo pode provocar o fracasso de um projeto.
Pensar no escopo é definir realmente o deve ser entregue. Muitos projetos definem
entregas desnecessárias que não contribuem para o objetivo do projeto.
É comum na descrição do escopo do projeto, para torná-lo mais claro ainda, não só
a descrição das entregas, mas também a descrição do que NÃO será entregue, ou
seja, àquelas entregas que não farão parte do escopo. Por exemplo: não faz parte
do escopo do projeto:
» Fornecer licenças de qualquer tipo de software necessário ao funcionamento
do software objeto do projeto.
» Projetar, instalar e configurar qualquer tipo de infraestrutura de redes de
computadores.

25. » Fornecedor qualquer tipo de hardware necessário ao funcionamento
do software objeto do projeto.
» Realizar qualquer tipo de treinamento, exceto o treinamento de uso
do software objeto do projeto.
Saiba mais.
Veja um exemplo de declaração do escopo do projeto:
https://docs.google.com/viewer?a=v&pid=sites&srcid=Zmd2Z3AxMC5tYXVyaWNpb3ZpZWl
yYS5uZXR8bG9naXN0aWNhLXNhbHZhZG9yLTIwMTR8Z3g6NTU2NzE0MzU2NmY0NTU
ESTRUTURA ANALÍTICA DO PROJETO (EAP)
Relembrando a analogia do mapa, o projeto possui um objetivo geral que pode ser
subdividido em objetivos menores. Essa estratégia permite diminuir a complexidade
do projeto pois, geralmente, partes menores são mais fáceis de administrar. E, após
concluir cada uma das partes, a soma delas formaria o todo, ou seja, o projeto.
Segundo Trentim (2011, p. 99), EAP é o “Processo de subdivisão das entregas e do
trabalho do projeto em componentes menores de modo a facilitar as estimativas e o
gerenciamento do trabalho”.
A EAP permite decompor todo o trabalho do projeto em partes menores que serão
mais fáceis de estimar e gerenciar.
A EAP – Estrutura Analítica do Projeto (ou, em inglês, WBS – Work Breakdown
Structure) é uma abordagem que permite decompor todo o trabalho do projeto em
partes menores, mais fáceis de gerenciar. Existe diversas representações para a EAP,
mas a mais comum é na forma de uma árvore invertida (Figura 3).

26. Nessa representação, como pode ser observado na Figura 3, o primeiro nível pode
representar o produto final, ou serviço, ou ainda todo o trabalho do projeto. O
segundo nível representa a primeira decomposição do primeiro nível, ou seja, “Pintar
uma sala” foi dividida em: Preparação de materiais, preparação da sala, pintura da
sala e limpeza da sala. O terceiro nível representa a divisão de cada elemento do
segundo nível. Por exemplo, a “Preparação de materiais” ainda foi dividida em:
comprar tintas, comprar escada, comprar rolos e comprar removedor de papel de
parede.
Quer saber mais sobre a EAP? Leia o material disponível em:
http://pt.wikipedia.org/wiki/Estrutura_anal%C3%ADtica_do_projeto
A EAP pode ter vários níveis. Sua profundidade dependerá do nível de detalhamento
necessário que se deseja dar ao projeto. Alguns níveis podem ser mais detalhados
que outros, por exemplo, considerando a Figura 4, a qual apresenta uma outra forma

27. de representar uma EAP, “Pesquisa” e “Escrita” foram subdivididas para o terceiro
nível. Entretanto, a “Apresentação” não foi dividida.
A cada nível da EAP pode ser atribuído um número. Os números também obedecem
a hierarquia dos níveis (Figura 5). Como ainda pode ser percebido na Figura 5, uma
EAP também pode ser representada no formato textual. Você já percebeu, portanto,
que a divisão dos trabalhos acadêmicos normalmente empregam a abordagem da
EAP.
A EAP de um projeto pode ser representada em diversos formatos: gráfico, textual,
tabular, hierarquia, etc.
Regra dos 100%
A regra dos 100% é um princípio aplicado à EAP a qual define que a soma de cada
elemento imediatamente abaixo de um nível decomposto é igual a 100% do elemento
imediatamente acima. Segundo o PMI (2008), a aplicação desta regra vale para todos
os níveis na hierarquia: a soma de todo o trabalho dos níveis "filhos" deve ser igual
a 100% do trabalho representado pelo "pai" e a EAP não deve incluir qualquer
trabalho que saia do escopo existente do projeto, isto é, ele não pode incluir mais do
que 100% do trabalho...”.

28. Vídeo sobre EAP
http://www.ricardo-vargas.com/pt/videos/140/
Para ilustrar, considerando a Figura 7 (parte do exemplo apresentado na Figura 6),
você deve ter notado que o nível 1, “Trabalho da disciplina” representa o projeto
inteiro. Entretanto, todo esse projeto foi divididoem três partes. Cada uma das partes
representa uma porção do projeto inteiro, logo, a soma dessas partes deve ser igual
a todo o trabalho do projeto. Também deve ter notado que as partes possuem
quantidade de trabalho diferentes, ou seja, as partes não precisam ter a mesma
quantidade de trabalho, entretanto, a soma de trabalho dessas partes deve totalizar
100% do trabalho total.
Você também deve ter notado na Figura 6 que a regra dos 100% pode ser aplicada
para todos os níveis da EAP. Por exemplo, considerando a Figura 8, todo trabalho do
item “Pesquisa” foi dividido ainda em duas tarefas: “Resumo Livros” e “Resumo
Artigos”. Note que o trabalho “Pesquisa” representa 40% de todo o trabalho do
projeto. Entretanto, todo esse trabalho, ou seja, 100% do trabalho “pesquisa” foi
dividido em duas tarefas e cada uma delas representará 50% de todo o trabalho
“Pesquisa”. Nesse caso, o trabalho foi dividido em duas tarefas com a mesma
quantidade de trabalho. Esse raciocínio pode ser aplicado os demais níveis da EAP e
é o gerente de projeto junto ao interessado que deve definir o nível de detalhamento
da EAP, bem como as estimativas de trabalho de cada nível.

29. Até quando decompor a EAP?
Segundo o PMI (2008), os responsáveis pelo escopo devem “subdividir as entregas
do projeto em componentes menores e mais GERENCIÁVEIS, até que as entregas do
trabalho estejam definidas no nível de PACOTES DE TRABALHO” (PMBOK, 2004).
Saiba mais.
Ouça o PODCAST sobre EAP e uma técnica de decomposição:
http://www.ricardo-vargas.com/pt/podcasts/wbs/
E, o que é pacote de trabalho?
Segundo Maximiano (2010), pacote de trabalho é o “conjunto delimitado de
atividades do projeto […] atribuídas a uma pessoa ou unidade funcional”. Em outras
palavras, o pacote de trabalho é o último nível da EAP, a folha, e é sobre o pacote de
trabalho que se deve embasar o planejamento e estimativas do projeto.

30. Um nível, ao ser dividido, deve gerar pelo menos dois outros subníveis, ou seja, um
nível não pode ser subdividido em apenas mais um nível (veja contraexemplo na
Figura 9 – Nível 4). Mas a principal do pacote de trabalho é facilitar o planejamento.
Vamos assistir a vídeo aula 3
Para cada pacote de trabalho pode ser definido, por exemplo: objetivo, tarefa(s),
entrega(s), recurso(s), orçamento, duração e critérios de aceitação.
O pacote de trabalho é a unidade que permite estimar com mais precisão diversos
indicadores do projeto, como: tempo, custo, recursos, etc.
Quer saber mais? Ouça um PODCAST sobre como definir o tamanho de um pacote
de trabalho:
http://www.ricardo-vargas.com/pt/podcasts/when-much-sometimes-is-too-much/

31. Tomando como exemplo a Figura 11, que apresenta a EAP para uma coleta de dados,
teríamos seis pacotes de trabalho. Para cada um deles poderíamos definir: objetivo,
tarefa(s), entrega(s), recurso(s), entregas, orçamento, duração, critérios de
aceitação.
A Figura 12 ilustra o planejamento do pacote de trabalho “Roteiro” da EAP
apresentada na Figura 11. A EAP apresentada na Figura 11 associada ao
detalhamento do pacote de trabalho apresentado na Figura 12 pode ser utilizado
como referência para a elaboração do cronograma do projeto. O cronograma do
projeto é uma ferramenta indispensável que permite o controle e acompanhamento

32. do projeto pelo gerente do projeto. A Figura 13 apresenta um exemplo de
cronograma elaborado com base na EAP da Figura 11 e pacote de trabalho ilustrado
na Figura 12. Cada nó (item que é desmembrado) é transformado numa tarefa
agrupadora (tarefa resumo) e os pacotes de trabalho são transformados em tarefas
do projeto.
Saiba mais.
Ouça o PODCAST e saiba mais sobre EAP e Pacote de Trabalho:
http://www.ricardo-vargas.com/pt/podcasts/work_package_tasks_dictionary/
MÉTODOS ÁGEIS
Os método ágeis surgiram do encontro de 17 metodologistas, em 2001. O grupo
formou a Aliança Ágil. Com base em um manifesto, o grupo definiu um conjunto de
princípios que deveria dar uma resposta aos seguintes pontos:
» Aos chamados métodos pesados (ou peso pesados) que tornavam o
desenvolvimento desoftware moroso e complexo.
» Alto índice de fracasso dos projetos da área de TI.
» Distanciamento dos interessados, ou seja, as metodologias de desenvolvimento
mantinham os interessados distantes do processo de desenvolvimento de software.
» Paradigma comando e controle (gerência e equipe). Essa abordagem torna a equipe
apenas uma executora de tarefas.

33. Métodos ágeis foi a resposta que a comunidade encontrou como alternativa para o
gerenciamento de projetos mais flexível.
Pesquisas apontam (Figura 14) que os método ágeis são mais efetivos que os
métodos tradicionais. Pesquisa realizada pelo Standish Group apontou que 42% dos
projetos ágeis alcançaram sucesso frente a apenas 14% dos métodos tradicionais,
no caso, o método Cascata (Waterfall).
As abordagens tradicionais focam o tempo e custo e, como você sabe, quando nós
direcionamos maior prioridade para uma dessas variáveis, a outra ou outras variáveis
sofrem as consequências. Por exemplo, para cumprir os contratos principalmente em
relação ao custo e tempo, muitas empresas acabam por diminuir as entregas, ou
seja, o escopo. Então, o cliente recebe um produto bem menor que o combinado
inicialmente.

34. Os métodos ágeis buscam o equilíbrio das variáveis escopo, tempo e custo com foco maior
na variável escopo, ou seja, é uma abordagem orientada ao produto.
Diferentemente das abordagens tradicionais, os métodos ágeis focam o escopo, ou
seja, é dada a preferência para as entregas do projeto. Mas, você poderia perguntar?
Como fica o tempo e o custo? Bom, funciona assim: uma lista de necessidades por
ordem de prioridade é definida e, se o tempo ou o custo forem atingidos antes de
terminar a lista, teoricamente, todas as necessidades de maior prioridade foram
entregues ao cliente restando, portanto, as necessidades de menor prioridade.
Alguns dos principais métodos ágeis:
» Programação Extrema – eXtreme Programming (XP).
» Framework Scrum.
» Desenvolvimento Dirigido à Funcionalidade (FDD – Feature Driven Development).
» Método de desevolvimento de Sistemas Dinâmicos – DSDM (Dynamic Systems
Development Method).
» Desevolvimento Adaptável de Software – Adaptive Software Development.
» Crystal.
» Programação Pragmática – Pragmatic Programming.
» Desenvolvimento Dirigido a Teste – Test Driven Development.
» Modelagem ágil – Agile Modeling.
As abordagens ágeis são estruturadas segundo alguns valores (Figura 16) e princípios
estabelecidos pelos metodologistas no encontro de 2001. Esses valores, no total 4,
e princípios, no total 12, formam a base dessas metodologias.
Saiba mais sobre os princípios ágeis:

35. http://agilemanifesto.org/iso/ptbr/principles.html
Vamos assistir a vídeo aula 4
SCRUM
Scrum é um framework de gerenciamento ágil de projeto de software proposto por
Jeff Sutherland em 1993. Todo trabalho é dividido em pequenos ciclos de
desenvolvimento chamados Sprints. CadaSprint dura entre uma a quatro semanas.
Ao final de cada Sprint é entregue uma parte funcional do produto.
SCRUM aceita que inevitavelmente haverá mudanças no projeto.
O processo de gerenciamento proposto pelo Scrum é relativamente simples:
1. Inicialmente é eleito um responsável pelos requisitos, ou proprietário do produto
(product owner) que define a mantém atualizada uma lista com todos os requisitos
(product backlog) do usuário ou cliente.
2. Numa 1ª reunião (Sprint Planning Meeting), são selecionados o “mediador”
(Scrum Master) e os requisitos (prioridade e tempo).

36. 3. Numa 2ª reunião, a equipe (Scrum Team) calcula e divide as tarefas (sprint Backlog).
Essa porção de requisitos (interação) que será desenvolvida é chamada de sprint e
dura entre 1 e 4 semanas. Ao final de um sprint é entregue uma parte funcional do
produto.
4. Durante uma sprint são realizadas reuniões diárias com duração de 15 minutos. Ao
final da sprint é realizada a reunião de revisão e preparação para o próximo sprint.
Vídeo sobre a implantação do Scrum na Globo.com:
Equipe Scrum e seus Papéis
O Product Owner (proprietário do produto) é a única pessoa responsável pelo
gerenciamento doBacklog do Produto e por garantir o valor do trabalho realizado pelo
Time. O Product Owner (ou PO) pode ser o cliente, um gerente de produto, um
usuário, etc. É recomendado que o Product Owner conheça o produto que será
desenvolvido e que tenha uma boa interação com os demais interessados no projeto,
visto somente ele ser o responsável pelos requisitos do produto.

37. Times (multifuncionais) auto-organizados de desenvolvedores, analistas,
engenheiros, especialistaem banco de dados, etc. transformam o Backlog do Produto
em incrementos de funcionalidades potencialmente entregáveis em cada Sprint. É
importante destacar que os Times Scrum devem ser pequenos para que de fato
produzam resultados satisfatórios. Muitas experiências com Times grandes (com 10
ou mais integrantes) tem mostrado que a produtividade diminui significativamente.
Isto porque o Time Scrum deve se comunicar intensamente e, Times com muitos
integrantes tendem a ter dificuldades no processo de comunicação.
O Scrum Master é responsável por garantir que o Time Scrum esteja aderindo aos
valores do Scrum, às práticas e às regras. Ele não tem autoridade (no sentido de
chefe), mas é o responsável pela equipe, coordena os eventos, avalia os resultados
(produtividade), ou seja, é a interface da equipe perante os demais interessados,
assim como o Product Owner é a interface dos interessados (lado cliente/usuário).
TimeBox

38. Timebox (caixa do tempo) significa a delimitação no tempo de uma tarefa/evento.
Vários eventos no Scrum são limitados no tempo, por exemplo, uma Sprint deve ser
realizada entre 1 e quatro semanas e as reuniões tem duração entre 15 minutos a 4
horas (dependendo da reunião).
Quer saber mais sobre Timebox? Leia o artigo disponível em:
http://blog.myscrumhalf.com/2011/11/time-box-no-scrum/
Planejando a Sprint
Como você já deve ter percebido, Sprint (Figura 18) é uma porção de todo o processo
supostamente necessário para desenvolver o produto final. Geralmente, uma Sprint
deve durar entre duas e quatro semanas. As Sprints de um projeto devem ter a
mesma duração.
Vamos assistir a vídeo aula 5
Como você deve ter percebido na Figura 18, uma Sprint implementa uma parte dos
requisitos (ou histórias) listados no Product Backlog, essa porção de requisitos que
será implementado na Sprint é chamado de Sprint Backlog. Ao final de uma Sprint,
deve-se entregar o resultado planejado para a Sprint e, esse resultado, deve
acrescentar algo ao produto, incrementá-lo, além, é claro, de ser funcional.

39. Saiba mais sobre o que são histórias de usuários:
Antes de ser iniciada, a Sprint é planejada na Reunião de Planejamento 1. Nessa
reunião os requisitos ou histórias são selecionados de tal forma que caibam dentro
do tempo definido para a Sprint. Os requisitos ou histórias selecionados devem ser
sempre os de maior prioridade. A prioridade dos requisitos é definida pelo Product
Owner. Uma vez a lista esteja pronta (Sprint Backlog), é realizada a Reunião de
Planejamento 2. Essa reunião tem por objetivo subdividir os requisitos ou histórias
em tarefas. Os integrantes do Time selecionam as tarefas que desejam realizar.
Executando a Sprint
Uma vez definidas as tarefas e seus responsáveis, é iniciada a execução da Sprint. À
medida que aSprint é executada, o Time compara o planejado ao realizado.
Diariamente são realizadas reuniões pelo Time, os quais discutem o andamento e
impedimentos da Sprint. Essas reuniões, normalmente realizadas em pé, ocorrem no
início da manhã ou final da tarde e duram em média 15 minutos. A reunião aborda
os seguintes temas: 1) O que você fez ontem? 2) O que você fará hoje? E, 3) Há
impedimentos no seu caminho?

40. Finalizando a Sprint
Após o término da Sprint, é realizada a reunião de Revisão. Participam dessa reunião
o Time, Scrum Master (SM) e Product Owner (PO). O Time apresenta os resultados
ao PO que por sua vez avalia se os requisitos (histórias) foram implementadas
satisfatoriamente. Se não for aceito, os requisitos reprovados voltam para o Product
Backlog e farão parte de uma nova Sprint. Após o término da reunião de Revisão
também é realizada a reunião de Retrospectiva. Nessa reunião são discutidos os
pontos negativos e positivos da Sprint. São propostas melhorias que farão parte da
nova Sprint.
Quer saber mais?
Leia o glossário SCRUM:
http://blog.myscrumhalf.com/2011/08/aprendendo-os-termos-scrum-glossario/
RESUMO
Nessa unidade, nós discutimos um pouco sobre como iniciar um projeto, bem como
a importância sobre a definição clara, mensurável e precisa do objetivo do projeto.
Vimos também que todo projeto deve definir o escopo do projeto, ou seja, o que faz
e o que não faz parte do projeto. Aprendemos que a EAP ou Estrutura Analítica do
Projeto é um instrumento fundamental para descrever e planejar um projeto.
Finalmente, discutimos sobre um pouco sobre uma nova abordagem de gestão de
projeto: os métodos ágeis. Percebemos que os métodos ágeis tem apresentado, nos
últimos anos, resultados melhores que métodos tradicionais como o método Cascata.
Vimos também sobre o Scrum, uma abordagem ágil muito utilizada por empresas de
desenvolvimento de software. Finalmente, discutimos alguns detalhes sobre o
Scrum: valores, princípios, processo, papéis envolvidos e dinâmicas.

41. Revisão sobre o Scrum, Assista ao vídeo que apresenta um resumo sobre o
Scrum:
Visão geral
Apresentação da disciplina:
CURSO: especialização em Tecnologias para Aplicações WEB
DISCIPLINA: ANÁLISE DE SISTEMAS
DOCENTE: iolanda cláudia sanches catarino
Apresentação do Professor:
Sou a professora Iolanda, mestre em Ciência da Computação pela
UFSCar, docente da UNOPAR na graduação e pós-graduação desde
1996 e atuo na área de engenharia de software como analista de
sistemas.
Sejam bem-vindos à disciplina de Análise de Sistemas!
Primeiramente, abordarei uma contextualização do paradigma
orientado a objetos, daUnified Modeling Language (UML), do
Processo Unificado e uma visão geral da metodologia Enterprise
Knowledge Development (EKD) que é uma abordagem para a
modelagem organizacional, facilitando a compreensão do negócio
para iniciar a modelagem das atividades de Análise de Requisitos e
Análise.
Na sequência, trabalharemos com os dois principais diagramas da
atividade de Análise – o Diagrama de Casos de Uso e o Diagrama de
Classes, integrando-os com o Diagrama de Atividades que se aplica
a qualquer domínio de software.
Objetivos:
 Conhecer fundamentos sobre o paradigma orientado a
objetos;
 Conhecer a Linguagem de Modelagem Unificada – UML e suas
técnicas de modelagem;
 Conhecer e aplicar técnicas de modelagem da atividade de
análise de sistemas, priorizando os dois principais diagramas
da UML – Diagrama de Casos de Uso e Diagrama de Classes.
Conteúdo Programático:
 Paradigma Orientado a Objetos: histórico, características e
conceitos;
 A Linguagem de Modelagem Unificada - Unified Modeling
Language (UML): histórico e visão geral das técnicas de
modelagem;

42.  Modelo de Use Cases: Diagrama de Use Cases
e Documentação de Use Cases;
 Diagrama de Classes;
 Diagrama de Atividades;
 Diagrama de Sequência;
 Diagrama de Máquina de Estados;
 Especificação das técnicas de modelagem com
ferramenta CASE.
Metodologia:
Na unidade utilizaremos todos os recursos necessários e disponíveis
para o desenvolvimento da discussão do conteúdo, sendo assim,
faremos uso de:
 Textos da própria Web Aula e de outros sites que possam
contribuir para a discussão;
 Vídeos que possam esclarecer ou aprofundar determinados
conteúdos;
 Fóruns para discussão de tópicos onde seja possível a troca de
ideias e conteúdos entre os discentes e docentes;
 Avaliações virtuais onde será realizada a verificação do
aprendizado;
 Entre outros recursos que poderão ser utilizados visando
maior entendimento da matéria.
Avaliação Prevista:
Cada web aula conterá uma avaliação virtual composta de 5
questões (sendo assim, temos 2 web-aulas com 5 questões cada).
Quando houver fórum de discussão o aluno será avaliado quanto ao
conteúdo de sua postagem, onde deverá comentar o tópico
apresentando respostas completas e com nível crítico de avaliação
pertinente ao nível de pós-graduação.
Critérios para Participação dos Alunos
no Fórum:
Quando houver fórum de discussão o aluno será avaliado quanto ao
conteúdo de sua postagem, onde deverá comentar o tópico
apresentando respostas completas e com nível crítico de avaliação
pertinente ao nível de pós-graduação. Textos apenas concordando
ou discordando de comentários de outros participantes do fórum
sem a devida justificativa ou complementação não acrescentam em
nada ao debate da disciplina, sendo assim, devem ser evitados. Os
textos devem sempre vir acompanhados das justificativas para a
opinião do discente sobre o conteúdo discutido, para que assim,
possamos dar continuidade ao debate em nível adequado. Além
disso, podem ser utilizados citações de artigos, livros e outros
recursos que fundamentem a opinião ou deem sustentação a sua
posição crítica sobre o assunto. Deve ser respeitado o tópico

43. principal do fórum, evitando debates que não tem relação com o
tema selecionado pelo professor.
Habilidades e competências
Ampliar seus conhecimentos sobre os aspectos teóricos contidos nas
diversas correntes do pensamento sobre a temática discutida na
disciplina;
Compreender a importância dos temas trabalhados para a formação
profissional;
Articular a relação teoria e prática no exercício da profissão, por
meio do entendimento da visão do mundo moderno e globalizado.
1
TECNOLOGIAS PARA APLICAÇÕES WEB
WEB AULA 1
Unidade 1 – Análise de Sistemas
Atualmente, a transformação organizacional tem sido amplamente discutida e
praticada, pois a transição entre negócios e tecnologias de informação, bem como a
integração das funcionalidades de um Sistema de Informação (SI) com os requisitos
organizacionais tem sido o grande problema das organizações e da engenharia de
sistemas. Então, iniciamos esclarecendo dois conceitos: Engenharia de
Sistemas e Engenharia de Software!
Figura 1 – Engenharia de Sistemas.
Fonte: Thinkstock (2012).
A Engenharia de Sistemas contempla todos os aspectos relacionados ao
desenvolvimento de sistemas com base em computadores,
incluindo hardware, software e engenharia de processos, e aEngenharia de
Software é uma parte da Engenharia de Sistemas que se ocupa de todos os aspectos

44. da produção de software (SOMMERVILLE, 2003). Para Pressman (2002), a
Engenharia de Software abrange um conjunto de 3 elementos fundamentais
(métodos, ferramentas e procedimentos), que possibilita ao gerente o controle do
processo de desenvolvimento do software e oferece ao profissional uma base para
a construção de software de alta qualidade.
O método proporciona os detalhes de “como fazer” para construir o software.
Envolvem um amplo conjunto de tarefas que incluem: planejamento e estimativa de
projeto, análise de requisitos,análise e projeto, implementação e testes. Sommerville
(2003) define que um método é uma abordagem estruturada para o desenvolvimento
de software, para facilitar a produção de software de alta qualidade, apresentando
uma boa relação custo-benefício.
Todos os métodos apresentam modelos de um sistema (técnicas de modelagem) que
possam ser representados graficamente por diagramas, na maioria, ou de forma
descritiva, sendo que cada técnica de modelagem tem um objetivo e aplicabilidade
para melhor especificar o projeto. Na literatura, há vários métodos de
desenvolvimento renomados e reconhecidos pelo mercado. Não existe o método ideal
e diferentes métodos têm áreas de aplicação diversificada.
As ferramentas proporcionam apoio automatizado ou semi-automatizado aos
métodos de desenvolvimento de software, como por exemplo, as
ferramentas Computer Assited Software Engineering (CASE) - Engenharia
de Software Auxiliada por Computador, de modelagem, de banco de dados e de
linguagens de programação.
Os procedimentos definem o planejamento do projeto, a sequência de execução das
atividades, as técnicas de modelagem que são adotadas do método escolhido, a
sequência de execução das atividades e demais regras e padrões adotados no
desenvolvimento do software.
Podemos concluir que o desenvolvimento de um SI deve abranger a definição de uma
metodologia que contemple métodos, técnicas de modelagem, arquitetura e
tecnologias a serem adotados no desenvolvimento do sistema, visando
um software com qualidade que atenda plenamente os requisitos dos usuários e
assim, agregue inteligência ao negócio.
2
Os vários métodos e metodologias de desenvolvimento de sistemas dos paradigmas
Estruturado e Orientado a Objetos abrangem um conjunto de técnicas de modelagem
específicas para documentar as principais fases de um processo de desenvolvimento
– Levantamento de Dados, Análise, Projeto e Implementação, conforme ilustra a
figura a seguir.
Figura 2 – Processo de Desenvolvimento.

45. Fonte: Do autor (2012).
A atividade de Análise consiste em documentar o quê o sistema deve fazer em uma
visão lógica do negócio e independente de tecnologias de desenvolvimento.
Muitos modelos de requisitos existentes descrevem o ambiente organizacional por
meio de entidades e atividades, porém não representam as razões envolvidas nos
processos de decisões, o qual dificulta o desenvolvimento de um SI que atenda
plenamente os requisitos da organização. Assim, para garantir a identificação dos
requisitos de um SI, sugere-se adotar a modelagem organizacional, previamente,
visando identificar, definir e especificar os objetivos e processos próprios da
organização (CATARINO; CAZARINI, 2008).
A Modelagem Organizacional é um processo de modelagem complexa, pois envolve
questões que necessitam de conhecimentos específicos ou tácitos dos participantes
envolvidos nos processos de negócio, questões de gestão de pessoas e questões
técnicas relacionadas aos objetos ou serviços da organização. A
metodologia Enterprise Knowledge Development (EKD) (BUBENKO, 1998) é uma
abordagem para a Modelagem Organizacional que facilita a aquisição do
conhecimento da estrutura organizacional e estratégica, auxiliando na identificação
dos requisitos organizacionais para, assim, melhorar a compreensão do domínio e a
interação entre os usuários e o SI.

46. Para continuar aprendendo sobre EKD, acesse os links:
http://www.scielo.br/scielo.php?script=sci_arttext&pid=S0104-
530X2004000200006
http://www.teses.usp.br/teses/disponiveis/18/18135/tde-25112008-153952/pt-
br.php
3
1. Paradigma Orientado a Objetos
O paradigma Orientado a Objetos é uma abordagem para o desenvolvimento de
aplicações, ou seja, é uma estratégia de desenvolvimento de software que organiza
o software como uma coleção de objetos que contém tanto a estrutura dos dados
como o comportamento. É uma maneira de pensarnos problemas, utilizando modelos
organizados a partir de conceitos do mundo real.
A programação orientada a objetos teve início nos anos 1970 com a linguagem
SIMULA, parte da linguagem Smalltalk desenvolvida pela Xerox PARC, mas ganhou
grande visibilidade durante a década de 1980. Os conceitos básicos do
desenvolvimento de software orientado a objetos levaram mais de 10 anos para
amadurecerem. Da mesma forma que era difícil pensar em programação estruturada
quando as linguagens disponíveis eram Assembler e Fortran, também ficava difícil
pensar em programação orientada a objetos quando não se dispunha de linguagens
como C++, Ada e Java.
A abordagem orientada a objetos baseia-se nos conceitos da orientação a objetos,
apresentando melhorias significativas de qualidade e um aumento constante da
produtividade para o desenvolvimento de aplicações. A complexidade do
desenvolvimento de sistemas tem aumentado em função de mudanças tecnológicas
expressivas em poder de processamento e facilidade de uso, face à demanda por um
mercado competitivo e dinâmico. Sua principal característica é a uniformização dos
formalismos utilizados na análise, no projeto e na implementação. Outras
características se destacam, como:
a) Reusabilidade: refere-se à diminuição de custos por meio do reaproveitamento
(reutilização) de componentes de software e diminuição do tempo de
desenvolvimento do sistema. Segundo Booch; Jacobson e Rumbaugh (2000, p. 20),
“[...] os componentes são partes físicas e substituíveis de um sistema, que
proporcionam a realização de um conjunto de interfaces”;
b) Manutenibilidade: refere-se ao grau de impacto de alterações corretivas e
evolutivas, nosoftware , para realizar mudanças bem localizadas dos objetos, não
acarretando propagações descontroladas por todo o software;
c) Confiabilidade: refere-se a um controle de segurança e organização que é
estabelecido às classes de objetos, obtido pelo encapsulamento, tornando o acesso
às estruturas de dados privado aos objetos;
d) Extensibilidade: refere-se às partes do software que têm o seu uso estendido
a objetos pertencentes às classes criadas posteriormente. Classes genéricas podem

47. ser acrescidas de funcionalidades, gerando classes mais especializadas, aplicando o
conceito de herança.
Acompanhando a evolução das linguagens de programação orientadas a objetos, os
métodos de modelagem orientados a objeto surgiram entre meados da década de
1980 e 1990. Os métodos suportam os mesmos conceitos básicos da orientação a
objetos, apresentando técnicas de modelagem com notação e interpretação
particular dos elementos que compõem a técnica.
Os diversos métodos que surgiram para apoiar o paradigma orientado a objetos,
tiveram uma grande diversidade de autores. No início da década de 1990, os
pesquisadores James Rumbaugh, Ivar Jacobson e Grady Booch uniram as melhores
características destacadas em suas técnicas de modelagem e construíram um
padrão de referência para modelagem orientada a objetos, surgindo aUnified
Modeling Language (UML) – Linguagem de Modelagem Unificada.
4
O elemento principal da abordagem orientada a objetos é o conceito de objeto. Na
definição de Booch; Jacobson e Rumbaugh (2000, p. 456), um objeto é “[...] uma
entidade com uma fronteira bem-definida e uma identidade que encapsula o estado
e comportamento”. Para Rumbaugh (1994, p. 31), um objeto é “[...] um conceito,
uma abstração, algo com limites nítidos e significado em relação ao problema em
causa”. A figura a seguir ilustra um objeto.
Figura 3 – Exemplo de Objeto.
Fonte: Thinkstock (2012).
Podemos definir um objeto como sendo qualquer coisa concreta ou abstrata com
existência perceptível no mundo real que possa ser individualizado por possuir
características e comportamento próprio, ou seja, todos os objetos têm identidade
e são distinguíveis.
Para rever os conceitos da orientação a objetos, acesse o link:
http://books.google.com.br/books?id=BPVHsG17bAYC&printsec=frontcover&dq=co
nceitos+da+orienta%C3%A7%C3%A3o+a+objetos&hl=pt-
BR&sa=X&ei=TviYUNLgFIf28wSOpICYCw&ved=0CDkQ6AEwAQ#v=onepage&q=con
ceitos%20da%20orienta%C3%A7%C3%A3o%20a%20objetos&f=false

48. 2. Introdução à Unified Modeling Language (UML)
A UML consiste da fusão dos métodos de Booch, Rumbaugh (OMT- Object Modeling
Technique) e Jacobson (OOSE – Object-Oriented Software Engineering). A fusão
iniciou com o trabalho de Rumbaugh e Booch, que criaram um método a partir de
pontos fortes de cada um, surgindo o Unified Method – UM 0.8, apresentado ao
público em 1995. Logo a seguir, em meados de 1996, Jacobson integrou-se ao grupo
e lançaram a UML versão 0.9. A partir daí, criaram forças com cooperação de grandes
empresas, lançando no mercado com aprovação da Agência Americana de
Padrões – Object Management Group (OMG) em julho de 1997, considerando um
padrão mundial. A concretização da UML aconteceu em 1997.
Conforme Booch; Jacobson e Rumbaugh (2000, p. 13), a UML é “[...] uma linguagem
padrão para a elaboração da estrutura de projetos de software . A UML é uma
linguagem para visualização, especificação, construção e documentação de artefatos
que façam uso de sistemas complexos desoftware ”.
A UML contempla uma representação gráfica por meio das técnicas de modelagem
que especificam vários elementos (objetos, classes, atributos etc) da abordagem
orientada a objetos. A UML não se limita a um Modelo de Engenharia de Software e
não se vincula, exclusivamente, a uma etapa do processo de desenvolvimento, mas
se apoia no desenvolvimento incremental, por meio de modelos que podem evoluir
com a inclusão de novos detalhes.
VÍDEO 1
00:00
00:00
Atualmente, a OMG é a organização responsável em manter e administrar a UML.
Para mais informações sobre a OMG, acesse o link:
http://www.omg.org/
Segue-se um resumo da evolução da UML:
Quadro 1 – Cronograma de evolução da UML.
Ano Versão
1995 UML 0.8 (Booch e OMT)
1996 UML 0.9 (Booch, OMT e OOSE)
1997
UML 1.0 (padronizada pelo OMG – Object Management Group)
UML 1.1 (revisada e adotada pelo OMG)
1998 UML 1.3 (nova revisão)
2001 UML 1.4
2003 UML 1.5
2005 UML 2.0
2007 UML 2.1.1 (setembro)e 2.1.2 (novembro)

49. 2009 UML 2.2
2010 UML 2.3
2011 UML 2.4.1 (agosto)
Fonte: Do autor (2012).
Veja o vídeo a seguir que apresenta a evolução das tecnologias.
https://www.youtube.com/watch?v=WDFkHCfVe5Y
E a UML, porque evolui?
A UML contempla uma representação gráfica, por meio das técnicas de modelagem
que especificam vários elementos (objetos, classes, atributos etc) da abordagem
orientada a objetos. A UML não se limita a um Modelo de Engenharia de Software e
não se vincula, exclusivamente, a uma etapa do processo de desenvolvimento, mas
se apoia no desenvolvimento incremental, a partir de modelos que podem evoluir
com a inclusão de novos detalhes.
Um modelo é uma descrição simplificada da realidade, apresentado a partir de uma
perspectiva específica e criado para proporcionar uma melhor compreensão do
sistema. Cada modelo pode ser expresso em diferentes níveis de precisão,
constituindo um conjunto de diagramas consistentes entre si e acompanhados de
técnicas de modelagem textuais. Um diagrama é uma visão sobre um modelo, o qual
proporciona uma representação parcial do sistema.
Figura 4 – Modelo x Diagrama.
Fonte: Do autor (2012).
Booch, Jacobson e Rumbaugh (2000) consideram as principais características da
UML:
a) centrado na arquitetura: a arquitetura do sistema é utilizada como principal
artefato para a conceituação, construção, gerenciamento e evolução do sistema em
desenvolvimento, representando uma visão do projeto como um todo. O conceito de
arquitetura de software incorpora os aspectos estáticos e dinâmicos mais importantes
do sistema. A arquitetura é influenciada por muitos fatores, tais como a plataforma
de software sobre a qual o sistema vai rodar (sistema operacional, sistema
gerenciador de banco de dados, protocolos para comunicação em rede, etc.), blocos
de construção reutilizáveis (frameworks, componentes e patterns), considerações de
distribuição, sistemas legado e requisitos não funcionais;

50. b) orientado a Casos de Uso: os casos de uso são utilizados como o principal
artefato para o estabelecimento do comportamento desejado do sistema;
c) processo iterativo: contempla o gerenciamento de sequências de versões
executáveis e incrementais, sendo que cada nova versão incorpora os
aprimoramentos incrementais em relação às demais. Uma versão do sistema liberada
resulta em uma iteração concluída.
De uma forma geral, a UML privilegia a descrição de um sistema segundo três
perspectivas:estrutural – representa a visão estática do sistema; funcional –
representa as funcionalidades do sistema, ou seja, os serviços que o sistema
disponibiliza aos usuários; dinâmica – representa o comportamento dos objetos em
tempo de execução.
Para mais informações sobre a UML, acesse o link:
http://www.uml.org/
6
A UML 2.0 abrange quatorze técnicas de modelagem, classificadas em estrutural e
comportamental. As técnicas de modela Modularidade gem estruturais enfatizam a
estrutura dos elementos a partir da identificação dos objetos, colaborando para
modelagem estática do sistema. As técnicas de modelagem comportamentais
enfatizam o comportamento e a interação entre os elementos do sistema,
colaborando para modelagem dinâmica do sistema.
Quadro 2 – Relação das técnicas de modelagem da UML 2.0
Estruturais Comportamentais
Diagrama de Classes Diagrama de Casos de Uso
Diagrama de Objetos Documentação de Casos de Uso
Diagrama de Estruturas Compostas Diagrama de Atividade
Diagrama de Pacotes Diagrama de Máquina de Estados
Diagrama de Componentes Diagrama de Sequência
Diagrama de Implantação
Diagrama de Comunicação
Diagrama de Interação Geral
Diagrama de Tempo
Fonte: Do autor (2012).
Figura 5 – Técnicas de Modelagem da UML.

51. Fonte: Thinkstock (2012).
Para conhecer e saber mais sobre as técnicas de modelagem da UML,
acesse o link: .
A arquitetura da UML 2.0 é composta de duas bibliotecas, a Infrastructure –
metamodelo superior – e a Superstructure, que define os elementos que compõem
as notações de modelagem da UML, criadas pela extensão e acréscimo dos elementos
básicos definidos na Infrastructure. Para facilitara reutilização de um software , essa
arquitetura assegura que o projeto do software seja especificado com:
a) modularidade: organizam-se os elementos da modelagem em pacotes, ou
seja, em unidades pequenas, bem definidas e fáceis de usar;
b) camadas: representa o refinamento dos elementos de um modelo para
organizar e facilitar o uso, obtendo um refinamento dos modelos por meio da
abstração dos elementos;
c) extensibilidade: permite a personalização dos elementos existentes de um
modelo, para que, assim, novos elementos não tenham que ser criados para
solucionar novos problemas.
Para continuar aprendendo, acesse os links:
OMG Unified Modeling LanguageTM(OMG UML), Infrastructure:
http://www.omg.org/spec/UML/2.4.1/Infrastructure
OMG Unified Modeling LanguageTM(OMG UML), Superstructure:
http://www.omg.org/spec/UML/2.4/Superstructure
7
2.1 O Processo Unificado

52. O Unified Process (BOOCH, JACOBSON; RUMBAUGH, 2000) surgiu para apoiar o
desenvolvimento desoftware s orientado a objetos, fornecendo uma forma
sistemática e evolutiva de modelar sistemas com a UML.
O Processo Unificado consiste na repetição de uma série de ciclos durante o processo
de desenvolvimento de um sistema, permitindo uma gerência mais efetiva de
projetos complexos. Cada ciclo é concluído com uma versão do produto pronta para
distribuição e é subdividido em quatro fases sucessivas: Concepção, Elaboração,
Construção e Transição. Cada fase, por sua vez, é subdivida em iterações que
passam por todos os cincos workflows (fluxo de trabalho, atividades) do processo:
Requisitos, Análise e Projeto, Implementação e Teste.
As fases representam os aspectos dinâmicos do processo e tratam a dimensão do
tempo de execução. As atividades são executadas de forma incremental e evolutiva,
representando os aspectos estáticos do processo. A ênfase sobre as várias atividades
muda em cada fase do processo, como mostra a figura a seguir.
Figura 6 – Ciclo de vida do Processo Unificado.
Fonte: Adaptado de Medeiros (2010, p. 16).
Na fase de Concepção define-se a ideia inicial do negócio, o domínio do problema e
a delimitação do escopo do projeto. É feita a identificação dos atores que irão
interagir com o sistema, definindo a natureza dessa interação em uma perspectiva
de alto nível, destacando os principais casos de uso do sistema. Assim, esta fase
evidencia o planejamento, sendo necessário, posteriormente, identificar, definir e
analisaros requisitos do sistema. Ao término desta fase, são examinados os objetivos
do projeto para se decidir sobre a continuidade do desenvolvimento, ou seja, a
viabilidade do projeto.
A atividade principal da fase de Concepção está no entendimento dos requisitos e a
determinação do escopo do projeto.

53. Na fase de Elaboração define-se o comportamento funcional dos requisitos do
sistema, estabelecendo a arquitetura e mecanismos para tratar aspectos
abrangentes do sistema, conforme o domínio do problema. Assim consolida-se a fase
de concepção, agregando valor a cada iteração-incremento que sofre. As atividades
da fase de Elaboração asseguram que os requisitos, a arquitetura e os planos estão
suficientemente estáveis, podendo prever com precisão os custos e prazos para a
conclusão do desenvolvimento.
A atividade principal da fase de Elaboração é a definição e modelagem dos
requisitos, ainda que algum trabalho de projeto e implementação seja realizado
para prototipar uma versão dosoftware.
Na fase de Construção define-se uma arquitetura executável do sistema para
implementação, validação e testes do software.
As atividades principais da fase de Construção concentra-se no projeto e na
implementação, visando evoluir e melhorar o protótipo inicial, até obter o primeiro
produto operacional.
Na fase de Transição o sistema é disponibilizado à comunidade usuária com
acompanhamento constante, devido à demanda de novas funções ou ajustes do
sistema.
A atividade principal da fase de Transição é a de testes, visando garantir que o
sistema atenda os requisitos do usuário com qualidade. Além disso, usuários devem
ser treinados, características ajustadas e elementos esquecidos adicionados ao
projeto, fazendo a realimentação das atividades por fase.
Para mais informações sobre o Processo Unificado, acesse o link:
http://books.google.com.br/books?id=B1fy5scNtaIC&printsec=frontcover&hl=pt-
BR#v=onepage&q&f=false
8
3. Atividade: Análise de Requisitos
Nesta seção vamos abordar uma breve revisão da Engenharia de Requisitos para
relembrar o conceito de requisitos funcionais, que na atividade de Análise de
Requisitos ou apenas Requisitos é especificado como casos de uso.
A Engenharia de Requisitos (Requirements Engineering) preocupa-se com o quê deve
ser feito, ou seja, a compreensão do problema e não como fazer, considerando o
domínio do sistema. A Engenharia de Requisitos é o processo de descobrir, analisar,
documentar e verificar os serviços e restrições (SOMMERVILLE, 2011).
O domínio de um sistema engloba o contexto para o qual será provida uma solução,
sendo que o processo de reconhecimento do domínio caracteriza a definição de sua

54. fronteira. O conteúdo de um domínio compreende fatos, regras, necessidades,
conceitos, agentes etc.
Veja o vídeo a seguir:
https://www.youtube.com/user/IBMbrasil?v=LQ5RlWMNtB0
Como o projeto de um software pode atender plenamente as necessidades do
usuário?
Considerando um modelo de engenharia de software como o Processo Unificado, a
atividade de Análise de Requisitos ou, simplesmente, Requisitos visa identificar,
analisar, definir e especificar os requisitos do sistema. Os requisitos de um sistema
são as descrições do que o sistema deve fazer, os serviços que oferece e as restrições
a seu funcionamento (SOMMERVILLE, 2011).
Sommerville (2011) classifica previamente os requisitos de um sistema
em: requisitos de usuário erequisitos de sistema. Requisitos de usuário são
declarações em uma linguagem natural com complemento de diagramas ou não, de
quais serviços o sistema deverá fornecer a seus usuários e as restrições com as quais
este deve operar. Requisitos de sistema são descrições mais detalhadas das funções,
serviços e restrições operacionais do sistema de software, sendo que o documento
de requisito de sistema (especificação funcional) deve definirexatamente o que deve
ser implementado.
CONCLUINDO:
Requisitos de Usuário: expressa os requisitos abstratos de alto nível;
Requisitos de Sistema: expressa a descrição detalhada do quê o sistema deve
fazer.
Exemplo:
Os requisitos de sistema são classificados em dois tipos: Requisitos Funcionais (RF):
são declarações de serviços que o sistema deve fornecer, de como o sistema deve
reagir a entradas específicas e de como o sistema deve se comportar em
determinadas situações. Requisitos Não Funcionais (RNF): são restrições aos serviços

55. ou funções oferecidos pelo sistema. Incluem restrições de tempo, restrições no
processo de desenvolvimento e restrições impostas pelas normas organizacionais.
Muitas vezes, aplicam-se ao sistema com o um todo. Surgem por meio das
necessidades dos usuários, devido a restrições de orçamentos, políticas
organizacionais etc.
CONCLUINDO:
Requisitos Funcionais: descrevem o que o sistema deve fazer – funcionalidades;
Requisitos Não Funcionais: expressam restrições que o software deve atender
ou qualidades específicas que o software deve ter.
9
Exemplos de definição de requisitos em linguagem natural:
 O sistema deve prover um cadastro de cursos de extensão – RF;
 O sistema deve prover um cadastro de autores (professor responsável pelo
curso) dos cursos – RF;
 O sistema deve prover um cadastro dos candidatos (internos: alunos e
externos: pessoas da comunidade externa) – RF;
 O sistema deve prover um cadastro das inscrições para os cursos de extensão
– RF;
 O sistema deve prover um relatório de inscritos nos cursos de extensão
diariamente e por período – RF;
 O sistema deve prover um relatório dos cursos de extensão por situação
(Ativo, Confirmado, Encerrado ou Cancelado) – RF;
 O período mínimo de inscrições de um curso de extensão deve ser de 20 dias
– RNF;
 O cadastro de candidatos externos deve ser via Web – RNF;
 O cadastro das inscrições para um curso de extensão dever ser via Web –
RNF;
 O cadastro dos candidatos internos deve ser integrado com o sistema
acadêmico (cadastro de funcionários – professores) – RNF;
 O candidato ao se inscrever em um curso deve receber um e-mail de
confirmação como tempo máximo de 10 segundos após a transação – RNF.
Para modelar os requisitos funcionais de um sistema podemos adotar o Diagrama
de Casos de Uso que, posteriormente, guiará o processo de desenvolvimento,
conforme o Processo Unificado. Das técnicas da UML, o Diagrama de

56. Sequência também pode ser adotado para especificar o cenário de cada caso de
uso.
Para continuar aprendendo sobre Requisitos, acesse o link:
http://www2.dbd.puc-rio.br/pergamum/tesesabertas/0210666_06_cap_02.pdf
RESUMO:
Com a competitividade na era do conhecimento as organizações contam com
sistemas computacionais, principalmente, os Sistemas de Informação para prover
apoio à tomada de decisão de gestores táticos e estratégicos de forma que agregue
inteligência ao negócio. Esta Web Aula apresentou uma contextualização da
Engenharia de Sistemas, uma introdução da Unified Modeling Language (UML),
descrevendo seu histórico, principais características e técnicas de modelagem da UML
2.0, uma visão do Processo Unificado com suas fases e atividades de
desenvolvimento e uma introdução à atividade de Análise de Requisitos.
Vamos iniciar o nosso fórum!
As técnicas de modelagem da UML atendem a documentação de todos os
tipos de sistemas de software? Qual a sua opinião?
Figura 7 – Sistemas de Software.
Fonte: Thinkstock (2012).
BOOCH, Grady; JACOBSON, Ivar; RUMBAUGH, James. UML: guia do usuário. Rio de
Janeiro: Campus, 2000.

57. BUBENKO Janis; STIRNA, Janis; BRASH, Danny. EKD user guide. Dpt of computer
and systems sciences. Stockholm: Royal Institute of Technology, 1998.
CATARINO, I. C. S.; CAZARINI, E. W. Utilizando a metodologia enterprise knowledge
development no processo de desenvolvimento de sistemas de apoio à
decisão. UNOPAR Científica Ciências Exatas Tecnológicas. Londrina, v. 7, p. 77-
84, nov. 2008. Disponível em:. Aceso em: nov. 2012.
MEDEIROS, Ernani. Desenvolvendo software com UML 2.0 - definitivo. São
Paulo: Pearson Brasil, 2010.
PRESSMAN, Roger S. Engenharia de software. 5. ed. São Paulo: Makron Books,
2002.
SOMMERVILLE, Ian. Engenharia de software. 6. ed. São Paulo: Addison-Wesley,
2003.
SOMMERVILLE, Ian. Engenharia de software. 9. ed. São Paulo: Pearson, 2011.
THINKSTOCK. Logical graph webshop, online store, internet shop. 2012. Disponível
em: <http://www.thinkstockphotos.com/image/stock-photo-logical-graph-
webshop-online-store-
internet/140810423/popup?al=140810423&sq=140810423/c=431,253,632,254,93
,28,34,260,263,13,176,621,648,579,528,590,151,268,515,586,64,663,641,165,47
7,623,215,445,637,144,675,2,452,451,109,277,161,588,626,68,700,591,460,291,
696,344,629,614,647/f=PIHVX/s=DynamicRank>. Acesso em: nov. 2012.
THINKSTOCK. Smartphone with cloud of application icons. 2012. Disponível em:
<http://www.thinkstockphotos.com/image/stock-photo-smartphone-with-cloud-of-
application-
icons/131404860/popup?al=131404860&sq=131404860/f=PIHVX/s=DynamicRank
>. Acesso em: nov. 2012.
THINKSTOCK. Software architecture class diagram. 2012. Disponível em:
http://www.thinkstockphotos.com/image/stock-photo-software -architecture-class-
diagram/91568967/popup?al=91568967&sq=91568967/c=431,253,632,254,93,28,
34,260,263,13,176,621,648,579,528,590,151,268,515,586,64,663,641,165,477,62
3,215,445,637,144,675,2,452,451,109,277,161,588,626,68,700,591,460,291,696,
344,629,614,647/f=PIHVX/s=DynamicRank Acesso em: nov. 2012.
THINKSTOCK. Software architecture class diagram. Disponível
em:http://www.thinkstockphotos.com/image/stock-photo-software -architecture-
class-
diagram/91568967/popup?al=91568967&sq=91568967/c=431,253,632,254,93,28,
34,260,263,13,176,621,648,579,528,590,151,268,515,586,64,663,641,165,477,62
3,215,445,637,144,675,2,452,451,109,277,161,588,626,68,700,591,460,291,696,
344,629,614,647/f=PIHVX/s=DynamicRankAcesso em: nov. 2012.
THINKSTOCK. Software engineering word cloud. 2012. Disponível em:
SUGESTÕES DE LEITURA
BEZERRA, Eduardo. Princípios de análise e projeto de sistemas com UML. 2.
ed. Rio de Janeiro: Elsevier, 2007.
BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. The unified modeling
language: user guide. Massachussets: Longman, 2000.

58. BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML: guia do usuário. 2. ed.
Rio de Janeiro: Elsevier, 2006.
GUEDES, Gilleanes T. A. UML: uma abordagem prática. 3. ed. São Paulo: Novatec,
2008.
JACOBSON, Ivar; BOOCH, Grady; RUMBAUGH, James.The unified
software development process. New York: Addison-Wesley, 2000.
LARMAN, C. Utilizando UML e padrões: uma introdução à análise e ao projeto
orientados a objetos e ao desenvolvimento iterativo. 3. ed. Porto Alegre: Bookman,
2007.
MELO, Ana Cristina. Desenvolvendo aplicações com UML 2.2: do conceitual à
implementação. Rio de Janeiro: Brasport, 2010.
PENDER, Tom. UML, a bíblia. Rio de Janeiro: Elsevier, 2004.
RUMBAUGH, James et al. Modelagem e projetos baseados em objetos. Rio de
Janeiro: Campus, 1994.
TECNOLOGIAS PARA APLICAÇÕES WEB
WEB AULA 1
Unidade 2 – Análise de Sistemas
4. Atividade: Análise
A atividade de Análise consiste em documentar o quê o sistema deve fazer em uma
visão lógica do negócio e independente de tecnologias de desenvolvimento.
As técnicas de modelagem propostas pela UML não estão vinculadas, diretamente, a
uma atividade (Análise, Projeto, Implementação e Testes) do processo de
desenvolvimento de software e não dizem quem deve fazer o quê, quando e como.
Alguns autores como Ernani Medeiros (2010) e Bezerra (2007) sugerem a adoção do
Diagrama e Documentação de Casos de Uso, do Diagrama de Classes, do Diagrama
de Objetos e do Diagrama de Estruturas Compostas para modelar a atividade de
Análise e, posteriormente, fazer um refinamento dessas técnicas e complementar
com os diagramas de iteração para modelar a atividade de Projeto, representando
uma visão física de desenvolvimento.
Para mais informações sobre a UML acesse o catálogo da OMG:
http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UML
Na UML, os agrupamentos que organizam um modelo (conjunto de diagramas) são
chamados de pacotes. O Diagrama de Pacotes tem por objetivo representar os
subsistemas ou submódulos englobados por um sistema de forma a determinar as
partes que o compõem. Demonstra como os elementos estão organizados nos

59. pacotes e as dependências que existem entre os elementos e os próprios pacotes
(GUEDES, 2008).
A notação do Diagrama de Pacotes contempla a representação dos pacotes e da
dependência entre os pacotes. Pacotes são utilizados para agrupar elementos, para
modelar subsistemas e para a modelagem de subdivisões da arquitetura de uma
linguagem. Um Pacote pode se subdividir em outros pacotes. O nome do Pacote deve
ser representativo e único. Um relacionamento de Dependência representa as
dependências entre os pacotes, indicando que o elemento necessita, de alguma
forma, do elemento do qual depende. A Figura 8 exemplifica um Diagrama de
Pacotes.
Figura 8 – Exemplo de Diagrama de Pacotes:
Fonte: Do autor (2012).
1
4.1 Diagrama de Casos de Uso
Para melhorar a compreensão do domínio e garantir que um sistema atenda às reais
necessidades dos usuários, o Diagrama de Casos de Uso auxilia a fase de Análise
de Requisitos, ajudando a especificar, visualizar e documentar as características e
serviços do sistema. Na fase de Análise, o Diagrama de Casos de Uso representa um
refinamento dos requisitos funcionais do sistema. A técnica de modelagem de casos
de uso foi idealizada por Ivar Jacobson, na década de 1970.
Segundo Bezerra (2007), o Modelo de Casos de Uso (MCU) é uma representação
das funcionalidades externamente observáveis do sistema e dos elementos externos
ao sistema que interagem com ele. O MCU é um modelo de análise que representa
um refinamento dos requisitos funcionais do sistema em desenvolvimento.
Segundo Guedes (2008), o Diagrama de Casos de Uso demonstra o comportamento
externo do sistema, procurando apresentar o sistema por meio de uma perspectiva
do usuário, demonstrando as funções e serviços (casos de uso) oferecidos e quais
usuários (atores) poderão utilizar cada serviço. Para Booch; Jacobson e Rumbaugh
(2006), o Diagrama de Casos de Uso representa os aspectos dinâmicos do sistema,
tendo um papel central para a modelagem do comportamento de um sistema, de um

60. subsistema ou de uma classe. Cada um mostra um conjunto de casos de uso e atores
e seus relacionamentos.
O Diagrama de Casos de Uso representa as funcionalidades do sistema e os
elementos externos ao sistema que interagem com ele. É o diagrama mais abstrato,
flexível e informal da UML, sendo utilizado no início da modelagem do sistema, na
atividade de análise, embora venha a ser consultado e, possivelmente, modificado
durante todo o processo de engenharia do software. Apresenta uma linguagem
simples e de fácil compreensão para que os usuários possam ter uma ideia geral de
como o sistema irá se comportar, sendo um modelo com uma perspectiva externa
do sistema.
Um Diagrama de Casos de Uso é representado pelos elementos. Atores, Casos de
Uso eRelacionamentos. Um Diagrama de Casos de Uso deve ser feito com base na
especificação da fronteira do sistema, permitindo identificar um subsistema ou o
sistema completo, assim delimitando o contexto do sistema.
Atores: os Atores representam os papéis desempenhados pelos diversos usuários
que poderão utilizar ou interagir com os serviços (funcionalidades) do sistema, ou
seja, é qualquer elemento externo ao sistema que interage com ele. A interação
significa que um Ator troca informações com o sistema, enviando dados para o
sistema processar ou recebendo informações processadas. Normalmente, o Ator
inicia a interação com o sistema.
Eventualmente um Ator pode representar algum hardware especial ou mesmo um
outro software que interaja com o sistema. Assim, um ator pode ser qualquer
elemento externo que interaja com osoftware (GUEDES, 2008).
Os Atores são representados por símbolos de “bonecos magros”, contendo uma breve
descrição logo abaixo do seu símbolo que identifica qual o papel que o Ator assume
dentro do diagrama. Cada ator deve representar um único papel. A Figura 9 ilustra a
notação de Ator e a Figura 9 ilustra o exemplo de alguns Atores.
Figura 9 – Exemplo de Atores.
Fonte: Do autor (2012).
Casos de Uso: um Caso de Uso (use case) representa qualquer interação de serviços
entre um Ator e o sistema, sem revelar a estrutura e o comportamento interno do
sistema. Cada serviço deve ser representado, individualmente, como um Caso de
Uso. A Figura 10 ilustra o exemplo de alguns Casos de Uso.
Os Casos de Uso referem-se aos serviços, tarefas ou funções oferecidas pelo sistema.
São utilizados para expressar e documentar os comportamentos pretendidos para as
funções do sistema (GUEDES, 2008).
2
Os Casos de Uso são documentados, demonstrando o comportamento pretendido
para o Caso de Uso e quais funções ele executará quando for solicitado. Os Casos de

61. Uso são representados por uma elipse, contendo uma breve descrição dentro do seu
símbolo que identifica qual serviço o Caso de Uso assume. Recomenda-se nomear
um Caso de Uso com verbo no infinitivo mais substantivo(s). Exemplo: Cadastrar
Curso ou Manter Curso, Realizar Avaliação, Lançar Nota de Avaliação.
Figura 10 – Exemplo de Casos de Uso.
Fonte: Do autor (2012).
Relacionamentos: a interação entre um Ator e um Caso de Uso é representada por
um relacionamento. Os relacionamentos possíveis são: associação, generalização,
extensão e inclusão.
Associação: é um tipo de relacionamento entre os Atores que interagem com o sistema, entre os
Atores e os Casos de Uso ou os relacionamentos entre os Casos de Uso e outros Casos de Uso. Uma
associação entre um Ator e um Caso de Uso demonstra que o Ator utiliza-se, de alguma maneira, da
função representada pelo Caso de Uso (GUEDES, 2011).
Uma Associação é representada por uma reta, ligando o Ator ao Caso de Uso,
podendo indicar a Navegabilidade da Associação, que indica se as informações são
fornecidas pelo Ator ao Caso de Uso, se são transmitidas pelo Caso de Uso ao Ator
ou ambos (não indica a navegabilidade). Uma Associação pode possuiruma descrição
própria ou um nome, quando há necessidade de esclarecer alguma informação que
está sendo transmitida. A Figura 11 ilustra a notação de Associações e a Figura 12
ilustra o exemplo de associações entre os Atores e Casos de Uso.
No relacionamento de Associação entre um Ator e Caso de Uso pode-se indicar a
multiplicidade, o qual especifica o número de vezes que um Ator pode utilizar um
determinado Caso de Uso.
Figura 11 – Notação de Associação.
Fonte: Do autor (2012).
Figura 12 – Exemplo de Associação entre Atores e Casos de Uso.

62. Fonte: Do autor (2012).
3
Generalização é um tipo de relacionamento entre Casos de Uso ou entre Atores. A
Generalização de Atores é uma representação abstrata de papéis e a Generalização
de Casos de Uso representa dois ou mais Casos de Uso que apresentam
características semelhantes. Representa-se um Caso de Uso Geral (Generalização),
que descreve as características compartilhadas por todos os Casos de Uso
Especializados (Especialização). A estrutura do Caso de Uso Geral é herdada pelos
Casos de Usos Especializados. A Figura 13 ilustra o exemplo de Generalização de
Atores e Casos de Uso.
Figura 13 – Exemplo de Generalização entre Atores e Casos de Uso.
Fonte: Do autor (2012).
A Extensão representa um relacionamento estendido entre Casos de Uso, indicando
que o Caso de Uso “base” incorpora implicitamente o comportamento de outro Caso
de Uso em um local especificado pelo Caso de Uso “estendido”. Um relacionamento

63. estendido é utilizado para a modelagem da parte de um Caso de Uso que o usuário
poderá considerar como um comportamento opcional do sistema ou de um subfluxo
separado, que é executado somente sob determinada condição. O relacionamento de
dependência <<extend>> é representado por uma seta que parte do Caso de Uso
“estendido” para o Caso de Uso “base”. A Figura 14 ilustra um exemplo de Extensão
entre os Casos de Uso.
Às vezes, não está claro qual é a condição para que um Caso de Uso estendido seja
executado, assim, pode-se acrescentar uma Restrição. Restrições são representadas
por uma nota explicativa, contendo o texto que determina a condição entre chaves.
Figura 14 – Exemplo do Relacionamento de Extensão.
Fonte: Do autor (2012).
O relacionamento de Inclusão representa um relacionamento de dependência entre
Casos de Uso, indicado pelo estereótipo <<include>>. Esse relacionamento é
utilizado quando existe uma situação ou rotina comum a mais de um Caso de Uso. A
inclusão indica uma obrigatoriedade com outro Caso de Uso, sendo que a execução
do primeiro obriga também a execução do segundo. Um relacionamento de Inclusão
pode ser comparado à chamada de uma sub-rotina. O relacionamento de
dependência <<include>> é representado por uma seta que parte do Caso de Uso
“base” para o Caso de Uso “incluído”. A Figura 15 ilustra um exemplo de Inclusão
entre os Casos de Uso.
Figura 15 – Exemplo do Relacionamento de Inclusão.
Fonte: Do autor (2012).

64. Para mais informações sobre Use Cases acesse:
http://www.ivarjacobson.com/resource.aspx?id=1282
4
Após a criação do Diagrama de Casos de Uso, complementam-se os Casos de Uso
com uma documentação. O formato de documentação de um Caso de Uso é flexível,
permitindo que se documente o Caso de Uso da forma que se considerar melhor, até
mesmo pelo uso de pseudocódigo ou de código de uma linguagem de programação.
O formato usual é em cenários – principal e alternativos.
Para continuar aprendendo sobre Documentação de Casos de Uso, acesse
os links:
http://books.google.com/books?isbn=8574524441
http://books.google.com/books?isbn=8574522546
VÍDEO 2
00:00
00:00
4.2 Diagrama de Classes
Considerando que o Diagrama de Casos de Uso está concluído, a próxima etapa é
analisar os Casos de Uso para iniciar o trabalho de identificação das classes de
objetos, o qual se faz necessário compreender como o sistema está estruturado
internamente para que as funcionalidades sejam executadas. As classes de objetos
muitas vezes podem ser identificadas, também, como substantivos nas descrições
do domínio do problema.
A partir da elaboração de um primeiro estágio do Diagrama de Classes, o mesmo
evoluirá à medida que o sistema é desenvolvido, o qual o diagrama deve ser
incrementado com novos detalhes, assim tendo novos estágios refinados do
Diagrama de Classes.
O Diagrama de Classes representa a modelagem da parte estática do sistema,
representando um conjunto de Classes com seus atributos, operações e
relacionamentos.
O objetivo do Diagrama de Classes é permitir a visualização das classes utilizadas
pelo sistema e como estas se relacionam. Esse diagrama apresenta uma visão
estática de como as classes estão organizadas, preocupando-se em definir sua
estrutura lógica (GUEDES, 2008).
O Diagrama de Classes é a principal técnica de modelagem da UML, assim vamos
explorar nesta seção os principais componentes do Diagrama de Classes, tratando-o
como um diagrama da atividade Análise. Posteriormente, recomendo evoluir o
Diagrama de Classes em várias visões até obter um grau de refinamento com

65. detalhes de implementação, sendo considerado um Diagrama de Classes da atividade
Projeto.
A seguir apresentamos os principais elementos do Diagrama de Classes.
Classe: uma Classe é representada por um retângulo com, no máximo, três partes.
Na primeira parte (de cima para baixo) é exibido o nome da Classe. Por convenção,
o nome é apresentado no singular e com as palavras compostas começando por letra
maiúscula. Na segunda parte são declarados os atributos que correspondem aos
dados que um objeto armazena. Para cada atributo está associado um valor que esse
atributo pode assumir. E na terceira parte, são declaradas as operações que
correspondem às ações que um objeto sabe realizar, sendo que os objetos de uma
classe compartilham as mesmas operações.
O nome de um atributo é declarado por um substantivo ou expressão que representa
alguma propriedade da classe, tipicamente, em letra minúscula e, para palavras
compostas, usa-se concatená-las, sendo que a partir da segunda palavra inicia-se
com letra maiúscula, por exemplo,dataNascimento. O nome de uma operação é
declarado por um verbo ou uma locução verbal breve, usando a mesma convenção
de letras minúsculas e maiúsculas dos atributos. A Figura 16 ilustra a notação de
Classe e a Figura 17 ilustra alguns exemplos de representação de Classes.
Figura 16 – Notação de Classe.
Fonte: Do autor (2012).
Figura 17 – Exemplos de Classes com Notações Diferentes.
Fonte: Do autor (2012).
5
Relacionamentos: na UML, os modos pelos quais os itens podem estar conectados
a outros, isto é, logicamente ou fisicamente, são modelados como relacionamentos,

66. que permitem compartilhar informações e colaboram para a execução dos processos
pelo sistema (GUEDES, 2008).
Existem 4 tipos de relacionamentos:
a) Associações: são relacionamentos estruturais entre instâncias. Tipos de
associações: Unária (autoassociação ou reflexiva), binária, ternária, classe
associativa e agregação.
b) Generalizações: conectam classes generalizadas a outras mais especializadas,
o que é conhecido como relacionamento Generalização e Especialização;
c) Dependências: são relacionamentos de utilização entre casos de uso, classes,
pacotes e anotações;
d) Realizações: são relacionamentos que especificam um contrato de execução
entre classes e interfaces.
O relacionamento do tipo Associação é representado por uma reta, ligando as
classes envolvidas, podendo também possuir setas em suas extremidades para
indicar a navegabilidade da associação, o que representa o sentido em que as
informações são transmitidas entre os objetos das classes envolvidas. As Associações
podem também possuirnomes (títulos). A Figura 18 ilustra a notação de Associação.
Figura 18 – Notação de Associação
Fonte: Do autor (2012).
O atributo a ser transmitido na Associação é um atributo implícito, não sendo
apresentado na classe para a qual foi transmitido. Em cada extremidade da
associação deve ser definida a multiplicidade da associação.
A multiplicidade procura determinar o número mínimo e máximo de objetos
envolvidos em cada extremidade da Associação, especificando quantas instâncias de
uma classe relacionam-se a uma única instância de uma classe associada.
A multiplicidade depende de pressupostos e de como são definidas as fronteiras de
um problema, conforme as regras de negócio. O quadro a seguir ilustra os tipos de
multiplicidade.
Quadro 1 – Tipos de Multiplicidades.
Multiplicidade Significado
0..1
No mínimo zero (nenhum e no máximo um). Indica que os obje
classes associadas não precisam obrigatoriamente estar relacio
se houver relacionamento indica que apenas uma instância da
relaciona com as instâncias da outra classe.
1..1
Um e somente um. Indica que apenas um objeto da classe se r
com os objetos de outra classe.

67. 0..*
No mínimo nenhum e no máximo muitos. Indica que pode ou n
instâncias da classe participando do relacionamento.
*
Muitos. Indica que muitos objetos da classe estão envolvidos n
relacionamento.
1..*
No mínimo 1 e no máximo muitos. Indica que há pelo menos u
envolvido no relacionamento, podendo haver muitos objetos en
Intervalo
específico
Define-se um intervalo inicial e final, indicando que existem pe
um número específico inicial de instância envolvidas no relacion
com um número limite de instâncias.
Fonte: Do autor (2012).
6
A Associação Unária ou Reflexiva ocorre quando existe um relacionamento de um
objeto de uma classe com objetos da mesma classe. Cada objeto tem um papel
distinto nessa associação. A associação reflexiva é representada por uma linha,
iniciando e terminando na mesma classe. A Figura 19 ilustra um exemplo de
Associação Unária.
Figura 19 – Notação e Exemplo de Associação Unária.
Fonte: Do autor (2012).
A Associação Binária ocorre quando são identificados relacionamentos entre
objetos de duas classes.A existência de uma associação entre dois objetos possibilita
a troca de mensagens entre eles. Uma associação é representada por uma linha reta,
ligando as classes às quais pertencem os objetos relacionados. A Figura 20 ilustra
um exemplo de Associação Binária.
Figura 20 – Notação e Exemplo de Associação Binária.
Fonte: Do autor (2012).
A Associação Ternária ou N-ária ocorre quando conectam objetos de mais de
duas classes, ou seja, uma associação pode ter grau maior que dois. São
representadas por um losango para onde convergem todas as ligações da
Associação. A Figura 21 ilustra um exemplo de Associação Ternária.
Figura 21 – Notação e Exemplo de Associação Ternária.

68. Fonte: Do autor (2012).
A Classe Associativa também é chamada de classes de associação. É uma classe
que está ligada à associação, em vez de estar ligada a outras classes. Essa
associação, normalmente, aparece quando duas ou mais classes estão associadas e
é necessário manter características (atributos) específicas da Associação, sendo
que uma classe associativa pode participar de outros relacionamentos. Uma classe
associativa é representada por uma seta tracejada partindo do meio da associação
e atingindo uma classe. A Figura 22 ilustra um exemplo de Classe Associativa.
Figura 22 – Notação e Exemplo de Classe Associativa.
Fonte: Do autor (2012).
7
A Agregação demonstra que as informações de um objeto (chamado objeto-todo)
precisam ser complementadas pelas informações contidas em um ou mais objetos de
outra classe (chamados objeto-parte), essa associação é conhecida como “Todo-
Parte”. Ambas as classes podem “viver” de forma independente, ou seja, não existe
uma ligação forte entre as duas. O símbolo de Agregação difere do de Associação
por conter um losango na extremidade da classe que contém os objetos-todo.
Objetos da parte constituinte ou da parte agregado são independentes em termos de
vida, porém, são partes de um único todo. Essa análise dependerá do domínio do
problema em estudo.
O símbolo de Agregação difere do de Associação por conter um losango na
extremidade da classe que contém os objetos-todo. A Figura 23 ilustra um exemplo
de Agregação.
Figura 23 – Notação e Exemplo de Agregação.

69. Fonte: Do autor (2012).
Outro tipo de Agregação é a Composição. Segundo Guedes (2011) esta Associação
é uma variação da Agregação, onde é apresentado um vínculo mais forte entre
objetos-todo e os objetos-parte, procurando demonstrar que os objetos-parte têm
de estar associados a um único objeto-todo. Utiliza-se um losango preenchido para
indicar a Composição. A Figura 24 ilustra um exemplo de Associação Composição.
Ambas as classes “vivem” unidas de forma dependente, ou seja, existe uma ligação
forte entre as duas. Os objetos da classe parte são dependentes, em termos de
existência, da classe todo, ambas são partes de um único todo. Os objetos da classe
parte não podem viver quando o todo é destruído. Utiliza-se um losango preenchido
para indicar a Composição.
Figura 24 – Notação e Exemplo de Composição.
Fonte: Do autor (2012).
O relacionamento do tipo Generalização representa classes-mãe, chamadas gerais
e classes-filhas, chamadas especializadas, demonstrando a ocorrência de herança e
possivelmente de métodos polimórficos nas classes especializadas. A herança é a
possibilidade de uma classe utilizar os atributos e métodos de uma outra como se
fossem seus.
Na representação desse relacionamento, a classe generalizada é chamada de
“superclasse” e as classes especializadas são chamadas de “subclasses”. Ainda na
representação desse relacionamento pode ocorrer que uma subclasse herde atributos
e operações de duas ou mais superclasses, o qual indica uma herança múltipla. A
Figura 25 ilustra um exemplo de Herança e Herança Múltipla, o qual a
subclasse Extensão herda características das superclasses Curso e Evento.
VÍDEO 3
00:00
00:00
Figura 25 – Notação e Exemplo de Herança e Herança Múltipla.

70. Fonte: Do autor (2012).
Para completar a representação do relacionamento de Generalização deve-se indicar
a restrição ou discriminadores de classificação. Os discriminadores são utilizados para
definir melhor a semântica de classes especializadas derivadas de classes gerais,
sendo classificados em: Completa ou Total,Incompleta ou Parcial, Disjunção ou
Exclusiva, e Sobreposição. Os discriminadores são escritos entre chaves e próximos
à seta de generalização.
8
O discriminador do tipo Restrição Completa ou Total indica que qualquer instância da
superclasse (abstrata) será uma instância de uma das subclasses. Uma classe
abstrata não pode ser instanciada diretamente.
O discriminador do tipo Incompleta ou Parcial indica que o conjunto pode esperar
novas subclasses e uma instância de seu tipo pode não ser de uma de suas subclasses
e sim da própria superclasse (concreta). Uma classe concreta pode ser instanciada
diretamente.
O discriminador do tipo Disjunção ou Exclusiva indica que qualquer instância da
superclasse pode ser uma instância de apenas uma das subclasses, nunca poderá ser
mais do que uma e o discriminador do tipo Sobreposição indica que uma instância
pode pertencer a mais de uma subclasse.
O relacionamento do tipo Dependência é um relacionamento de utilização,
especificando que uma alteração na especificação de um item pode afetar outro item
que a utilize.
Uma dependência entre classes mostra que uma classe usa outra como argumento
na assinatura de uma operação. Se a classe utilizada for modificada, a operação da
outra classe será afetada. O relacionamento de dependência é representado por uma
reta tracejada entre duas classes, contendo uma seta apontando o item do qual o
outro depende, conforme ilustra o exemplo da Figura 26.
Figura 26 – Dependência entre Classes.
Fonte: Do autor (2012).
Uma Realização é um tipo de relacionamento especial que mistura características
dos relacionamentos de generalização e dependência, sendo usada para identificar
classes responsáveis por executar funções para classes que representam interfaces.

71. Esse tipo de relacionamento herda o comportamento de uma classe, mas não sua
estrutura.
O relacionamento de Realização é representado por uma seta tracejada contendo
uma seta vazia que aponta para a classe de interface, conforme ilustra o exemplo da
Figura 27.
Figura 27 – Relacionamento do Tipo Realização.
Fonte: Do autor (2012).
Neste exemplo, a classe Extensão herda valores da classe Curso e implementa a
interface intEvento.
No diagrama de classes da atividade de projeto, a indicação da Navegabilidade em
uma associação é representada por uma seta em uma das extremidades da
associação, identificando os sentidos em que as informações são transmitidas entre
os objetos das classes envolvidas, ou seja, o sentido em que os métodos poderão ser
disparados. Porém, a navegabilidade não é obrigatória, mesmo porque, se não
houver setas, significa que as informações podem trafegar entre os objetos de todas
as classes da associação (GUEDES, 2011).
Figura 28 – Associação com navegabilidade.
Fonte: Do autor (2012).
A figura acima indica que uma Inscrição tem a responsabilidade de lhe dizer qual é o
seu Participante, mas um Participante não tem a responsabilidade para dizer
que Inscrição ele tem. Ainda, uma Inscrição tem a responsabilidade de indicar qual
é o seu Curso, mas um Curso não tem a responsabilidade de indicar em
qual Inscrição está.
VÍDEO 4
00:00
00:00
9
CONCLUINDO:
Após a identificação das classes e atributos deve-se verificar a consistência entre as
classes e os casos de usos já definidos previamente e, assim, observar a necessidade
de novas classes ou eliminar incoerências e redundâncias. Considerando os diversos

72. elementos apresentados, é possível elaborar um primeiro estágio do Diagrama de
Classes, aplicando e respeitando as regras de negócio do domínio do problema e,
posteriormente, refiná-lo até obter um modelo ideal que atenda todos os requisitos
do sistema.
Concorda? Vamos discutir isso no fórum!
O próximo passo seria fazer o Diagrama de Objetos, porém, a utilização deste
diagrama é opcional. O Diagrama de Objetos é uma instância do Diagrama de
Classes. Cada classe mostra seu objeto em um determinado ponto de tempo. É
relevante adotá-lo para domínios complexos de software para facilitara compreensão
do sistema.
Para continuar aprendendo sobre o Diagrama de Objetos, acesse o link:
http://books.google.com/books?isbn=8574524441
Na sequência, recomenda-se documentar a atividade de Análise com o Diagrama
de Estruturas Compostas que é utilizado para representar Colaborações,
ilustrando o relacionamento entre os elementos participantes para executar uma
função. Uma Colaboração descreve uma visão de um conjunto de entidades
cooperativas interpretadas por instâncias que cooperam entre si para executar uma
função específica (GUEDES, 2008).
Ainda na atividade de Análise, recomendo especificar os casos de uso com
o Diagrama de Atividades. Um Diagrama de Atividades descreve uma sequência
de atividades. Uma atividade é composta por um conjunto de ações, ou seja, os
passos necessários para que as atividades sejam concluídas, assim representando a
execução de cada Caso de Uso.
Para saber mais sobre o Diagrama de Estruturas Compostas, Diagrama de
Atividades e os demais diagramas de interação, acesse os links:
.
http://books.google.com/books?isbn=8574524441
VÍDEO 5
00:00
00:00
RESUMO:
A UML não faz grande distinção entre a notação da atividade de Análise e da atividade
de Projeto. A atividade de Projeto é uma extensão dos diagramas criados na Análise
para implementação. Os diagramas criados durante a Análise são refinados com mais
detalhes, apresentando várias visões da especificação do sistema. O Diagrama de
Casos de Uso e o Diagrama de Classes são os dois principais diagramas que são
adotados na atividade de Análise.
10

73. BEZERRA, Eduardo. Princípios de análise e projeto de sistemas com UML. 2.
ed. Rio de Janeiro: Elsevier, 2007.
BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML: guia do usuário. 2. ed.
Rio de Janeiro: Elsevier, 2006.
GUEDES, Gilleanes T. A. UML: uma abordagem prática. São Paulo: Novatec, 2008.
______. UML2: uma abordagem prática. 2. ed. São Paulo: Novatec, 2011.
MEDEIROS, Ernani. Desenvolvendo software com UML 2.0 – definitivo. São
Paulo: Pearson Brasil, 2010.
SUGESTÕES DE LEITURA
BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. The unified modeling
language: user guide. Massachussets: Longman, 2000.
JACOBSON, Ivar; BOOCH, Grady; RUMBAUGH, James. The unified software
development process. New York: Addison-Wesley, 2000.
LARMAN, C. Utilizando UML e padrões: uma introdução à análise e ao projeto
orientados a objetos e ao desenvolvimento iterativo. 3. ed. Porto Alegre: Bookman,
2007.
MELO, Ana Cristina. Desenvolvendo aplicações com UML 2.2: do conceitual à
implementação. Rio de Janeiro: Brasport, 2010.
PENDER, Tom. UML, a bíblia. Rio de Janeiro: Elsevier, 2004.
RUMBAUGH, James et al. Modelagem e projetos baseados em objetos. Rio de
Janeiro: Campus, 1994.
Visão geral
Apresentação da disciplina:
A disciplina Banco de Dados na Web tem a finalidade de apresentar
os conceitos do modelo entidade relacionamento, modelo relacional
normalizado, debater sobre a importância destas etapas e também
conceitual os principais comandos padrão SQL com as operações
CRUD e as propriedades ACID de uma transação. Finalizamos com
os controles de acesso aos dados, que garantem a segurança da
informação.
Todas estas etapas são fundamentais pois os sistemas voltadas para
a Web necessitam de maior atenção por parte dos analistas de
sistemas e desenvolvedores, uma vez que este tipo de sistema é
muito diferente do modelo Cliente/Servidor.
Objetivos:

74. Conceituar ao aluno os principais pontos a serem observados no
item banco de dados durante o projeto e desenvolvimento de um
sistema voltado para a Web.
Conteúdo Programático:
Modelo Entidade Relacionamento.
- modelagem entidade relacionamento.
- diagrama entidade relacionamento.
Modelo Relacional Normalizado.
- 1ª Forma Normal.
- 2ª Forma Normal.
- 3ª Forma Normal.
- Boyce Codd Forma Normal.
- 4ª Forma Normal.
Operações CRUD (CERA).
- Create (Criar).
- Read (Recuperar).
- Update (Atualizar).
- Delete (Eliminar).
Estrutura de comandos SQL.
- tradutor de consultas.
- analisador de estratégia.
- dicionário de dados.
Propriedades ACID.
- Atomicidade.
- Consistência.
- Integridade.
- Durabilidade.
- conceitos de transação.
- operações DML.
Direitos de acesso.
- concessão de direitos (Grant).
- revogação de direitos (Revoke).
- papéis / perfis (Role).
Metodologia:
Na unidade utilizaremos todos os recursos necessários e disponíveis
para o desenvolvimento da discussão do conteúdo, sendo assim,
faremos uso de:
 Textos da própria web-aula e de outros sites que possam
contribuir para a discussão;

75.  Vídeos que podem esclarecer ou aprofundar determinados
conteúdos;
 Fóruns para discussão de tópicos onde seja possível a troca de
ideias e conteúdos entre os discentes e docentes;
 Avaliações virtuais onde será realizada a verificação do
aprendizado;
 Entre outros recursos que poderão ser utilizados visando
maior entendimento da matéria.
Avaliação Prevista:
Cada web-aula conterá uma avaliação virtual composta de 5
questões (sendo assim, temos 2 web-aulas com 5 questões cada).
Quando houver fórum de discussão o aluno será avaliado quanto ao
conteúdo de sua postagem, onde deverá comentar o tópico
apresentando respostas completas e com nível crítico de avaliação
pertinente ao nível de pós-graduação.
Critérios para Participação dos Alunos
no Fórum:
Quando houver fórum de discussão o aluno será avaliado quanto ao
conteúdo de sua postagem, onde deverá comentar o tópico
apresentando respostas completas e com nível crítico de avaliação
pertinente ao nível de pós-graduação. Textos apenas concordando
ou discordando de comentários de outros participantes do fórum
sem a devida justificativa ou complementação não acrescentam em
nada ao debate da disciplina, sendo assim, devem ser evitados. Os
textos devem sempre vir acompanhados das justificativas para a
opinião do discente sobre o conteúdo discutido, para que assim,
possamos dar continuidade ao debate em nível adequado. Além
disso, podem ser utilizados citações de artigos, livros e outros
recursos que fundamentem a opinião ou deem sustentação a sua
posição crítica sobre o assunto. Deve ser respeitado o tópico
principal do fórum, evitando debates que não tem relação com o
tema selecionado pelo professor.
Habilidades e competências
Espera-se que no final do curso os alunos possam:
Compreender a necessidade de uma boa modelagem de dados para
que o banco de dados possa ser o mais ágil e organizado possível.
Aplicar a normalização é fundamental para este passo.
Compreender os mecanismos de funcionamento nas operações
fundamentais e essenciais do banco de dados, uma vez que sistemas
voltados para ambiente Web são totalmente diferente em sua
arquitetura dos sistemas cliente servidor.
ESPECIALIZAÇÃO EM TECNOLOGIAS PARA APLICAÇÕES
WEB

76. Unidade 1 – Banco de Dados na Web
INTRODUÇÃO
Quando o assunto é sistemas voltados para o ambiente internet/web, o quesito banco
de dados toma uma importância de maior proporção, pois a segurança dos dados
torna-se fundamental além de um bom desempenho, é lógico.
Dividimos o nosso estudo em alguns capítulos que vão desde a modelagem de dados,
passando pelo processo de normalização até chegarmos a uma arquitetura de banco
de dados voltado para a web.
MODELO ENTIDADE RELACIONAMENTO
O modelo entidade relacionamento, que foi idealizado por Peter Chen, vem sendo
utilizado desde a década de 70.
Este modelo prega a identificação e organização dos dados que se pretende
armazenar, tudo isto obedecendo às regras do negócio em questão e que vão permitir
a integração e entrelaçamento dos dados.
O projeto de banco de dados envolve as etapas de construção do modelo conceitual
de dados, do modelo lógico de dados e do modelo físico de dados.
Estes modelos são projetados e desenhados com figuras geométricas pré-
estabelecidas, onde esta representação recebe o nome de diagrama entidade
relacionamento (DER).
As figuras geométricas utilizadas como padrão são:
- retângulo, representando as entidades;
- losango, representando os relacionamentos;
- elipses, representando os atributos;
- linhas, representando e unindo as figuras geométricas umas nas outras;

77. MODELO CONCEITUAL
Nesta fase inicial do projeto de banco de dados, devemos representar o nosso cenário
sistêmico o mais próximo da realidade do nosso usuário, sempre colocando o
armazenamento dos dados de uma forma que possa haver a compreensão ‘do que
se pretende guardar’ com ‘como será guardado’.
Podemos citar um exemplo onde o nosso usuário deseja armazenar as informações
e dados de um livro fiscal, ele apresenta o livro fiscal tradicional, e o analista de
sistemas tem que visualizar esta necessidade e criar uma estrutura de
armazenamento de forma lógica e que possa guardar de forma organizada e segura
todos estes dados.
Figura 1. Livro fiscal e o modelo de dados ‘livro_fiscal’
No modelo conceitual não devemos ou precisamos nos preocupar com qual Sistema
Gerenciador de Banco de Dados (SGBD) vai ser utilizado, pois esta necessidade será
debatida nas próximas fases do projeto de banco de dados.
O modelo conceitual nos permite em um único relacionamento a participação de três
ou mais entidades, uma vez que o levantamento de requisitos do sistema pode
apontar para uma regra de negócio que envolva ou apresente esta necessidade.
As ferramentas CASE (Computer Aided Software Enginneering) que trabalham a fase
de modelagem de dados, geralmente permitem a realização dos três modelos de
banco de dados (conceitual, lógico e físico). Inclusive, fazem a transformação de um
modelo para outro de forma automatizada e seguindo as regras do Modelo Relacional
Normalizado.
Aprofundando conhecimento
Podemos citar como exemplo de ferramentas CASE que trabalham com
banco de dados, o DBDesigner (empresa
fabFORCE.netWWW.fabforce.net ), o Rational System Architect (empresa
IBM WWW.ibm.com.br/software), o Designer 2000 (empresa
OracleWWW.oracle.com.br), o Erwin Data Modeler (empresa
CA WWW.ca.com).
No modelo conceitual nós tratamos apenas de entidades, relacionamentos, atributos
e as cardinalidades do relacionamento. Não tratamos de chaves primárias ou
estrangeiras, inicialmente são chamadas de ‘atributos identificadores’.

78. Os atributos são referenciados apenas como ‘caracteres’, ‘numéricos’, ‘alfanuméricos’
ou ‘datas’, ou seja, seus domínios não são totalmente especificados ainda. É possível
já acrescentar a quantidade/tamanho dos atributos também, mas nada, além disso.
MODELO LÓGICO
O Modelo Lógico já é mais voltado especificamente ao pessoal de tecnologia da
informação, pois o ‘tecniques’ ou ‘informatiques’ já fica mais evidente.
Ao invés de utilizarmos entidades, agora já chamamos de tabelas, os atributos são
chamados de campos ou colunas.
Começamos a pensar na obrigatoriedade ou não do campo, nos formatos possíveis,
nas representações que serão gravadas dentro do banco de dados.
Algumas ferramentas CASE já aproveitam para determinar qual é o SGBD a ser
utilizado e começam inclusive a trazer características e necessidades da parte física
para esta etapa.
No Modelo Lógico já não é mais possível representar um relacionamento ternário
entre três ou mais entidades/tabelas, com isto, apenas relacionamentos binários são
permitidos, levando a necessidade de normalizar o projeto de banco de dados antes.
Para transformar o Modelo Conceitual em um Modelo Lógico, algumas ferramentas
CASE já aplicam algumas regras pré-estabelecidas e resolvem alguns dos problemas
de modelagem, porém, algumas delas não fazem de forma tão automática assim,
sendo necessário a intervenção humana na sua resolução.
Somente relacionamentos binários são permitidos no Modelo Lógico, pois uma das
principais características do Modelo Entidade Relacionamento fica explicito neste
modelo.
O conceito de chave primária e chave estrangeira são estabelecidos, onde o principal
ponto da ‘integridade referencial’ é concretizado.
Este conceito diz que a chave primária de uma tabela é referenciada em outra tabela
como uma chave estrangeira, estabelecendo assim um relacionamento. A quebra
deste relacionamento compromete a integridade e a consistência dos dados das
tabelas envolvidas.
Do lado ‘chave primária’, sabemos que só pode haver uma ocorrência de um
determinado conteúdo, mas do lado ‘chave estrangeira’, a nulidade, a presença única
ou a presença de várias ocorrências vai depender da ‘regra de negócio’ estabelecida
pelo relacionamento, mas o SGBD vai seguir fielmente esta regra que for
implementada e vai garantir o cumprimento integral da mesma.
Aqui podemos apresentar algumas das regras que são inerentes a uma chave
primária ou uma chave estrangeira.

79. - o conteúdo de uma chave primária uma vez estabelecida, não pode ser modificado,
ou seja, sofrer um ‘update’.
- uma ocorrência da tabela (registro) só pode ser removida se a mesma não tiver
nenhum registro em outra tabela relacionada, ou seja, não possui referencia em
outras tabelas.
- se uma ocorrência da tabela (registro) tiver que ser removida, todos os registros
da tabela referenciada deverá ser removido também (chamamos de infanticídio ou
deleção em cascata) ou então a deleção original não poderá ser executada.
- uma ocorrência da tabela (registro) referenciada pode ser removida sem a
necessidade de nenhuma validação adicional (deletar um registro filho sem afetar o
registro pai ou os demais registros irmãos).
MODELO FÍSICO
Aqui estamos tratando já dos comandos padrão SQL para a criação física do banco
de dados, com as características e sintaxes apropriadas ao SGBD escolhido.
Em linhas gerais, o projeto físico contém uma série de comandos CREATE e ALTER.
Dependendo do SGBD adotado, ele pode ter uma sintaxe muito parecida com outro
SGBD, mas sempre que for necessário utilizar um projeto físico de um SGBD
específico em outro SGBD, uma revisão completa de sintaxe deve ser feita, senão
você corre o risco do seu projeto físico não funcionar de acordo com o esperado.
Normalmente como o Modelo Físico já esta ajustado sintaticamente para um SGBD,
caso o mesmo projeto seja utilizado em outro SGBD, provavelmente alguns trechos
e formatos dos comandos deverão ser ajustados. Isto faz com que um Modelo Físico
seja específico de um determinado banco de dados, em muitas situações até mesmo
a diferença de versão do mesmo SGBD faz com que o Modelo Físico seja ajustado.

80. Uma prática comum em empresas que desenvolvem software é manter um projeto
de banco de dados sempre no Modelo Lógico, que é independente de SGBD e na hora
de montar o seu Modelo Físico, adequar o software para o SGBD desejado e assim a
sintaxe gerada para o Modelo Físico será de acordo com o software desejado e na
versão correta também.
As ferramentas CASE permitem que no momento de transformar o seu Modelo Lógico
em um Modelo Físico, seja possível escolher o SGBD desejado e até mesmo a versão
do software, para que a sintaxe seja a mais próxima possível do que vai ser utilizado
e assim evitar erros de sintaxe ou mesmo a intervenção humana no script de criação.
<http://www.devmedia.com.br/conceitos-fundamentais-de-banco-de-dados-parte-
2/1678>.
00:00
00:00
VÍDEO AULA 01 – MODELAGEM
MODELO RELACIONAL NORMALIZADO
CONCEITO E NECESSIDADE DE NORMALIZAÇÃO
O Modelo Entidade Relacionamento tenta se aproximar o máximo possível da
representação do cenário sistêmico e por isso mesmo não está totalmente aderente
às melhores formas de garantir a integridade e consistência dos dados.

81. Por isso, uma série de situações pode levar o banco de dados a comprometer suas
principais características de funcionamento e validação ou até mesmo comprometer
o seu armazenamento de dados de forma organizada.
A consistência dos dados é fundamental para a confiabilidade do banco de dados.
Com isto, algumas regras foram desenvolvidas para refinar e melhorar a estrutura
de armazenamento dos dados. Estas regras receberam o nome de Formas Normais
e a sua aplicação e resultado final ficou conhecida como Modelo Relacional
Normalizado.
A execução ou o processo de aplicação das regras é referenciado como ‘Normalização
do banco de dados’ ou ‘Normatização do banco de dados’, para entender um pouco
mais do significado desta palavras, veja o seguinte link.
.
O seu modelo de dados sem nenhuma revisão é conhecido como ‘Modelo
Desnormalizado’, este é o seu ponto de partida.
A sua aplicação é sequencial do Modelo Desnormalizado para a Primeira Forma
Normal, depois da Primeira Forma Normal para a Segunda Forma Normal, depois
para a Terceira Forma Normal e se for necessário, passar pela Boyce Codd Forma
Normal e Quarta Forma Normal.
A 1ªFN, a 2ªFN e a 3ªFN são obrigatórias e resolvem praticamente todas as situações
de normalização. A BCNF e 4ªFN são necessárias apenas em situações especiais.
Alguns especialistas de banco de dados já pregam a Quinta Forma Normal (5ªFN),
porém são situações muito pontuais e especificas, nem sempre usual em sua
ocorrência.
PRIMEIRA FORMA NORMAL
Para transformarmos um modelo de dados da sua forma desnormalizada para a
Primeira Forma Normal, devemos procurar por atributos repetidos dentro das
entidades, ou seja, identificaros atributos que possuam o seu domínio repetido e que
demonstrem assim a existência de várias ocorrências do mesmo atributo na entidade.
Depois de identificar estes atributos, os mesmos devem ser removidos e separados
em uma nova entidade.
Nesta nova entidade, você não precisa colocar todas as repetições retiradas, apenas
uma destas ocorrências é o suficiente, uma vez que é necessário estabelecer um
relacionamento forte de 1-N, onde a chave primária da entidade forte vai ser uma
chave estrangeira na entidade fraca e também fará parte da chave primária desta
entidade fraca.

82. Desnormalizado Conceitual
Desnormalizado Lógico
1ª FN Conceitual

83. 1ª FN Lógico
SEGUNDA FORMA NORMAL
Na Segunda Forma Normal devemos identificar e eliminar todas as dependências
funcionais parciais, dos atributos não chave com partes da chave primária.
Os atributos que apresentarem esta dependência deverão ser separados em uma
nova entidade e um relacionamento forte deve ser estabelecido entre elas para que
a chave primária composta continue assim.
Uma observação importante pode ser afirmada com relação às entidades que
possuam chave primária simples, estas entidades não podem conter dependências
funcionais parciais da sua chave primária, portanto estas entidades já estão na
Segunda Forma Normal automaticamente.
2ª FN Conceitual
2ª FN Lógico

84. TERCEIRA FORMA NORMAL
A Terceira Forma Normal analisa a dependência funcional dos atributos não chave
com os outros atributos não chave, deixando a chave primária de fora desta vez.
As dependências que forem identificadas deverão ser transferidas para uma nova
entidade e o relacionamento que deverá ser estabelecido para manter esta nova
entidade, é um relacionamento fraco.
Outro ponto observado na Terceira Forma Normal é referente aos atributos
calculados. Atributos que tenham o seu valor determinado por uma ação imposta em
outras colunas não devem ser armazenados, pois podem ser calculados em tempo
real sempre que foram necessárias a sua apresentação.
O exemplo mais tradicional desta situação é o ‘valor total da nota fiscal’, pois é um
atributo que depende do valor individual de cada item da nota fiscal.
Para o exemplo, vamos acrescentar o atributo ‘nom_atendente’ dentro da comanda
e atributo ‘val_comanda’ na entidade Comanda e também o atributo ‘val_produto’ na
entidade Produto.
Após aplicar a 3ª FN

85. 3ª FN Conceitual
3ª FN Lógico
BOYCE CODD FORMA NORMAL
A situação tratada pela BCFN foi descoberta pelos irmãos Boyce, como as Formas
Normais já estavam todas definidas e difundidas, para não houvesse uma
‘renumeração’ ou ‘redistribuição’ das Formas Normais, uma vez que esta regra
deveria ser executada entre a Terceira Forma Normal e a Quarta Forma Normal,
convencionou-se chamar de Boyce Codd Forma Normal.
A BCNF verifica uma situação de dependência funcional entre chaves primárias
compostas, ou seja, quando uma parte de uma chave primária depende

86. funcionalmente de outra parte da chave primária, causando uma situação onde não
é possível identificar individualmente uma entidade dentro deste conjunto de
entidades semelhantes.
Isto significa que a chave primária composta precisa ser revisada, um novo atributo
deverá fazer parte desta chave primária composta ou então uma parte desta chave
primária composta deverá ser trocada ou substituída.
Em linhas gerais, significa que na fase onde as chaves eram tradas como chaves
candidatas, não houve uma escolha mais criteriosa ou então todas as possibilidades
de combinação não foram testadas.
Resumindo, a BCNF deve ser executada quando a chave primária composta não está
executando a sua função primordial de identificação individual.
Geralmente quando o analista cria um atributo ‘ID’ ou ‘COD’ e pensa num
identificador ou código, onde ele mesmo vai decidir e estabelecer qual é o domínio
deste identificador ou código, é porque ele não encontrou nenhum outro atributo na
entidade que permita ou possibilite a função de chave primária, com isto ele puxa a
responsabilidade de criar um atributo que vai conter um valor controlado e não
repetido. Assim a Boyce Codd Forma Normal acaba sendo desnecessária.
Ex. uma entidade Produto modelada para um pequeno comércio.
Veja que com os atributos ‘nome_produto’ e ‘descricao_produto’ escolhidos como
chave primária (atributos identificadores no modelo conceitual) podemos ter o
seguinte cenário:
- nome_produto = tota-tola
- descricao_produto = refrigerante gasoso sabor tola
- tipo_embalagem_produto = garrafa vidro
- peso_produto = 600 ml
- data_validade_produto = 31/12/2012
- valor_produto = 3,00
e um segundo produto com:
- nome_produto = tota-tola
- descricao_produto = refrigerante gasoso sabor tola
- tipo_embalagem_produto = lata alumínio
- peso_produto = 350 ml

87. - data_validade_produto = 31/12/2012
- valor_produto = 2,50
Veja que os produtos são iguais em nome e descrição, mas diferenciam-se no tipo
de embalagem, no peso e no valor.
Neste caso, fica evidente que os dois atributos escolhidos não são uma boa escolha.
A solução seria acrescentar mais um atributo como identificador ou então, fazer o
tradicional que é criar um novo atributo com a descrição de Identificador ou Código,
trazendo a responsabilidade do seu domínio para o sistema.
QUARTA FORMA NORMAL
A 4FN trata de relacionamentos ternários (multivalorados) que podem ser modelados
no plano conceitual.
Normalmente, no modelo conceitual podemos montar um relacionamento com mais
de duas entidades, este tipo de relacionamento recebe o nome de relacionamento
ternário ou n-ário.
Exemplo de relacionamento binário

88. Exemplo de relacionamento ternário com 3 entidades
Exemplo de relacionamento ternário com 4 entidades
No Modelo Lógico não podemos implementaro relacionamento ternário, então temos
que transformar todos os relacionamentos ternários em vários relacionamentos
binários, você pode montar quantos relacionamentos binários forem necessários para
que a sua regra de negócio seja mantida.
Exemplo de um relacionamento binário no modelo lógico

89. Exemplo do um relacionamento ternário transformado em vários binários
Exemplo de um relacionamento ternário transformado em vários binários
Este exemplo acima demonstra uma situação onde o relacionamento ternário inicial
foi desmembrado em 3 relacionamentos binários, uma situação que pode contemplar
a todas as necessidades de regras de negócio.
As cardinalidades neste caso não foram mantidas para efeito de demonstração, mas
no seu dia a dia, deve-se prestar muita atenção para não montar um looping de
relacionamento.
00:00
00:00
VÍDEO AULA 02 - MRN

90. Pessoal, vamos participar do fórum colocando suas opiniões, dúvidas, ponto de vista
e aproveitarmos o momento para troca de conhecimento.
QUESTÃO PARA REFLEXÃO UNIDADE I
Na unidade I da web aula, abordamos o modelo entidade relacionamento e depois o
modelo relacional normalizado.
Com este conteúdo foi possível compreender por que um projeto de banco de dados
não deve ser implementado diretamente sem que haja uma análise aprofundada
aplicando-se as regras de normalização.
Dentro deste sentido, os atributos calculados geralmente acabam gerando uma
polêmica, pois o MRN pede para eliminá-los, mas em prol da performance, alguns
analistas preferem mantê-los.
Qual a sua opinião sobre este ponto? Participe do fórum.
CHEN, Peter. Modelagem de dados. São Paulo: Mc Graw Hill/Makron, 1990.
HEUSER, Carlos Alberto. Projeto de banco de dados. Porto Alegre: Sagra Luzzato,
1999.
KROENKE, David M. Banco de dados. Rio de Janeiro: LTC, 1999.
NISHIMURA, Roberto Yukio. Banco de dados I. São Paulo: Pearson, 2009.
_______.Banco de dados II. São Paulo: Person, 2009.
SILBERSCHATZ, A & KORTH, H & SUDARSHAN, S. Sistemas de banco de dados.
São Paulo: Campus, 2012.

91. ESPECIALIZAÇÃO EM TECNOLOGIAS PARA APLICAÇÕES
WEB
Unidade 2 – Banco de Dados na Web
PADRÃO SQL
O padrão SQL (Structure Query Language – Linguagem de Consulta Estruturada )
nasceu dentro dos laboratórios de pesquisa da IBM na década de 70, mas foi na
década de 80 que ganhou força quando o Instituto Nacional Americano de Padrões
(ANSI) e a Organização Internacional de Padrões (ISO) estabeleceram uma versão
final do que ficou conhecido como Padrão SQL (ANSI,86) ou SQL-86.
Algumas revisões já foram realizadas acrescentando novos comandos e funções,
assim nasceram o SQL-92, o SQL-99 e o SQL-2003.
Sempre que o assunto SQL entra em cena, é enfatizada a semântica dos comandos
que facilitam muito a compreensão do que se pretende fazer, deixando assim o
comando com uma sintaxe muito intuitiva.
Muitos SGBDs de mercado adotaram a palavra SQL na sua nomenclatura, com o
intuito de reforçar a adoção do padrão SQL (ex. MS SQL-SERVER, MYSQL).
Porém, nenhum deles adota 100% da sintaxe padrão, sempre colocam pequenas
modificações na sua sintaxe para que caso o usuário queira trocar de SGBD, esta
operação não possa ser feita sem nenhuma modificação ou adaptação.
Os comandos utilizados no padrão SQL podem ser classificados em linhas básicas
como DML ou DDL.
Comandos DML fazem a manipulação dos dados onde à escolha do melhor caminho
pode ser feita pelo próprio usuário (DML procedural) ou pelo próprio SGBD (DML não
procedural).
Já os comandos DDL fazem a manipulação das estruturas de armazenamento e
acesso, definindo, alterando, modificando ou eliminando estes objetos do banco de
dados.

92. COMANDOS DML
Os comandos DML (Linguagem de Manipulação de Dados) permitem manipularmos
os dados das tabelas do banco de dados, seja incluindo novos dados, atualizando
dados que já estejam gravados no banco de dados, eliminando dados armazenados
e principalmente consultando dados armazenados.
Um comando DML procedural, o usuário deve especificar quais dados ele deseja
localizarno banco de dados e também precisa especificarno mesmo comando, como
fazer para chegar até estes dados. É conhecido entre os analistas e programadores
como ‘passar o HINT no comando select’, é quando o analista indica qual índice de
pesquisa ele deseja que seja utilizado, apenas lembrando que a responsabilidade de
escolher um índice correto passa para o analista e tira do banco de dados a
responsabilidade desta escolha.
Já o comando DML não procedural, é geralmente o mais utilizado no nosso dia a dia,
pois o usuário simplesmente especifica quais dados ele quer e a escolha do melhor
caminho para este acesso é passado para o banco de dados. O banco de dados por
sua vez faz acesso e utiliza os dados que estão armazenados no dicionário de dados,
mais especificamente na parte dos dados estatísticos para realizar a analise da
melhor estratégia de acesso.
ESTRUTURA DE COMANDO SQL
O SGBD pode interpretar os comandos SQL de duas formas, a primeira através de
alguma ferramenta que faça o acesso intrusivo no banco de dados onde geralmente
os comandos são interpretados e executados ou na segunda forma que é através de
objetos no próprio banco de dados, por exemplo: procedures de banco, triggers,
packages, funcionts.
Um comando SQL quando submetido à execução, passa por algumas fases.
- análise sintática – é quando o comando é analisado em sua estrutura léxica e
semântica, ou seja, é verificada cada parte do comando, se todos os itens necessários
para que o comando fique completo estão presentes, se não está faltando nenhum
símbolo ou que a gramática do comando esteja incompleta.
Ainda na análise sintática, os campos, tabelas e outros objetos são verificados no
dicionário de dados, confrontando e correlacionando os campos às tabelas, ou aos
índices, seus tipos de dados e tamanhos.
Esta fase é conhecida como PARSE.
Nesta fase, o SGBD aproveita para verificar se um comando semelhante a este não
foi executado recentemente e que esteja no buffer / cache do banco de dados, pois
isto pode influenciar na escolha do caminho uma vez que o comando foi executado
recentemente e a estratégia já foi escolhida.
Esta indicação é passada para a fase de análise estratégica.
É por isso que a adoção de uma padronização sintática de uso ajuda muito o SGBD.
Combinar com os analistas, coisas do tipo:
- Todos os comandos serão escritos em letras minúsculas, sejam comandos diretos
interativos ou comandos dentro de programas de computador.
- Estruturar os comandos como nos exemplos a seguir.

93. Apesar dos resultados serem os mesmos, será feitas duas análises distintas, com
provavelmente a indicação da mesma estratégia de acesso, mas isso não é 100%
garantido.
A economia parece pequena, mas se a consulta for executada milhares de vezes ao
dia, são muitas etapas de análise que podem ser economizadas.
- análise estratégica – é a fase onde o SGBD recebe o aval da análise sintática e de
posse do resultado desta análise, vai consultar o dicionário de dados e as estatísticas
do banco de dados para definir a sua estratégia e escolher qual é o melhor caminho
para chegar às informações solicitadas pelo comando em execução.
Para esta fase é importantíssimo que as informações estatísticas estejam
devidamente atualizadas, pois caso contrário, com informações antigas ou erradas,
é possível que o SGBD tome uma decisão errada na hora de montar o plano de acesso
aos dados.
- execução do comando – agora que o SGBD já definiu ‘como vai fazer’, o comando
é executado, ou seja, as ordens dentro do comando são executadas de acordo com
a sua recomendação.

94. Esta fase onde o comando SQL é estruturado é muito importante pois dois usuários
diferentes podem pedir a mesma solicitação de dados para o SGBD e receber
interpretações diferentes e consequentemente, ser executado por caminhos
diferentes com performances diferentes também.
COMANDO SELECT
O comando SELECT faz a leitura dos dados nas tabelas, procurando pela informação
solicitada e depois apresentando os resultados ao usuário solicitante.
O acesso pode ser feito em uma única tabela ou em várias tabelas ao mesmo tempo,
quando utilizamos duas ou mais tabelas, é conhecido como ‘join de tabelas’.
Um comando SELECT pode trazer como resposta uma linha de informação ou várias
linhas de informação, bem como pode não trazer linha nenhuma, ou seja, uma
resposta vazia (não encontrou nada que satisfizesse a consulta).
Veja que se o comando SELECT esta sintaticamente correta, o mesmo será
executado, mas a resposta vai depender diretamente dos dados que estiverem
armazenados dentro do banco de dados.
Por isso mesmo, um comando SELECT pode ter comportamento e resposta diferente
se for executado em dois bancos de dados com a mesma estrutura de tabelas, mas
com dados diferentes armazenados em cada um deles (é o famoso caso de banco de
produção e banco de teste, onde o comando tem um resultado no desenvolvimento
e outro na produção).
Alguns cuidados devem ser tomados no uso do comando SELECT como o uso correto
da cláusula WHERE, pois é a ‘peneira’ para que os dados sejam retornados de acordo
com a sua necessidade.
COMANDO INSERT
O comando INSERT permite que seja gravada uma informação nova dentro de uma
tabela.
A inserção é feita em uma tabela de cada vez, ou seja, na mesma sintaxe não é
possível (ainda) gravar dados em duas ou mais tabelas ao mesmo tempo.
Em cada inserção, é gravado apenas um registro de cada vez. Existem sintaxes que
permitem gravar dois ou mais registros num mesmo comando SQL, porém neste caso
fica evidente que o comando está fora do padrão SQL ANSI. Pode até ser que em
breve uma nova revisão do padrão SQL inclua esta nova sintaxe, mas no momento
está fora.
Quando é executado o comando INSERT, é verificada a validade dos dados em
questão, como por exemplo, se o conteúdo do campo chave primária é único ou não,
se existem atributos de preenchimento obrigatório, se existem valores de atributo
tipo DATA inválidos ou não, se existem atributos com valores pré-determinados /

95. definidos, se existem atributos que são chaves estrangeiras e a sua validade com a
chave primária correspondente.
Estas validações são conhecidas como regras de negócio ou ‘constraints’, como estas
validações são executadas pelo banco de dados, os programas aplicativos não
precisam programar estas regras em sua estrutura.
Caso ocorra algum problema, uma mensagem de erro é emitida e o comando não é
completado.
COMANDO UPDATE
O comando UPDATE possibilita substituir alguns dados previamente gravados nas
tabelas, independentemente do motivo da atualização, este comando regrava uma
nova informação sobrepondo a informação antiga.
A atualização é feita em uma única tabela de cada vez, porém a quantidade de
registros afetados depende diretamente da cláusula de seleção colocada na sintaxe
do comando.
Aqui vale a mesma observação feita para o comando SELECT, o comando UPDATE
pode afetar um ou vários registros e até mesmo nenhum registro, apresentando
resultados diferentes em bancos de dados diferentes também.
As regras de validação são equivalentes ao do comando INSERT, ou seja, validação
de chave estrangeira, tipos de atributos, preenchimento obrigatório ou não, valores
pré-determinados.
Um comando UPDATE não permite a troca da chave primária, neste caso o usuário
deverá apagar o registro por completo e depois criar um novo registro com o novo
valor de chave primária.
COMANDO DELETE
O comando DELETE permite apagar registros completos de uma tabela e o critério
de seleção é imprescindível para que não seja cometido algum erro.
A cláusula WHERE é fundamental para selecionar e apagar somente os registros
desejados, por isso mesmo, é recomendado que um comando SELECT com o mesmo
argumento de seleção WHERE seja aplicado antes do comando DELETE e os
resultados sejam verificados e validados, somente então, aplicaro comando DELETE.
00:00
00:00
VÍDEO AULA 03 – PADRÃO SQL - CRUD
PROPRIEDADES ACID
As propriedades ACID de um SGBD são os pontos essenciais para que um software
seja realmente considerado um SGBD ou um gerenciador de tabelas.
A confiabilidade de um SGBD está diretamente ligada à garantia de que as
propriedades ACID serão sempre executadas e em nenhum momento podem
apresentar falhas.
Transação é uma operação realizada no banco de dados que consiste em aplicação
de comandos que modificam os dados no banco de dados (gravação de um dado
novo, modificação de um dado existente ou eliminação de um dado existente).
Toda transação tem um significado lógico e consistente para a veracidade dos dados
armazenados.

96. A transação é determinada pelo analista de sistemas dentro dos programas
aplicativos ou do usuário de banco de dados que através de ferramentas apropriadas
realiza um acesso interativo junto ao banco de dados.
Toda transação é encerrada pelos comandos COMMIT ou ROLLBACK, que será
abordado mais adiante.
Atomicidade – uma transação de banco de dados é considerada indivisível, pode
conter várias operações em uma mesma transação e ao término da mesma, todas as
operações estarão garantidas, uma vez concretizadas, esta transação não pode ser
dividida em partes.
Consistência – a transação tem que respeitar todas as regras de negócio aplicadas
no banco com relação à consistência dos dados (campos tipo DATA, NUMERO,
CARACTER, preenchimento obrigatório, valores mínimos ou negativos, valores pré-
estipulados (sexo Masculino e Feminino), atributos que dependem do valor/conteúdo
de outros atributos).
Integridade – respeita todas as regras de negócio aplicadas no banco principalmente
aquelas que dizem respeito a relacionamentos (integridade referencial).
Durabilidade – não se perde com o tempo, ou seja, uma transação que foi efetivada
deve ser durável para sempre (embora para sempre seja muito tempo, devemos
pensar assim) até que outra transação integra e consistente venha modificar os
dados desta transação antiga. Uma transação que não sofra modificações em seus
dados não pode desaparecer do banco de dados com o passar dos anos, ou seja, o
banco de dados não pode ‘esquecer’ ou ‘perder’ os dados simplesmente porque
pertenciam a uma transação antiga.
00:00
00:00
VÍDEO AULA 04 – PROPRIEDADES ACID
COMANDO COMMIT
Uma transação de banco de dados pode conter diversas operações (Insert, Update
ou Delete) e este conjunto de operações precisa receber uma confirmação da
finalização da transação ou da desistência da transação.
A confirmação é feita pelo comando COMMIT, que neste momento verifica a execução
das propriedades ACID e em caso positivo, retorna para o usuário a confirmação OK
da sua transação, em seguida já inicia uma nova transação.
COMANDO ROLLBACK
Se uma operação for executada errada e você decidir descartar o resultado desta
operação (insert, update ou delete), é possível executar o comando ROLLBACK que
desfaz o resultado desta operação, porém todas as operações envolvidas nesta

97. transação também são desfeitas, ou seja, o banco de dados volta até o início da
transação corrente.
O comando ROLLBACK não permite desfazerapenas uma operação ou partes de uma
operação, ele desfaz TODAS as operações da transação.
COMANDOS DDL
Os comandos DDL (Linguagem de Definição de Dados) permitem manipularmos as
estruturas de armazenamento, ou seja as tabelas e os demais objetos do banco de
dados.
Em linhas gerais, podemos definir a criação de uma tabela nova, executar alterações
na estrutura de armazenamento das tabelas e até mesmo eliminartabelas existentes
no banco de dados.
COMANDO CREATE
O Comando CREATE é utilizado para a definição de novos objetos no banco de dados
(tabelas, índices, triggers, procedures, functions, etc).
Uma tabela nova é criada sempre vazia e já com todas as regras de integridade e
consistência ativadas. Se alguma coluna ficou esquecida ou foi definida com
características erradas, não é possível executar o comando Create para este mesmo
objeto, você tem que partir para o comando de alteração de objetos.
COMANDO ALTER
O Comando ALTER é utilizado para modificar uma tabela já existente dentro do banco
de dados, neste ponto é importante observar que existem situações onde mesmo à
sintaxe permitindo a execução, devido aos dados já armazenados na tabela, a
modificação não pode ser executada por ferir regras de integridade referencial ou
consistência.
Incluir uma nova coluna que a principio parece ser uma tarefa simples, depende
muito do tipo de inclusão que está sendo realizada.
Se incluir uma coluna nova sem propriedades de validação (not null, valores pré-
definidos ‘S/N’, ‘M/F’), está é uma operação executada na hora e sem erros.
Se incluir uma coluna nova com propriedades de validação (not null, valores pré-
definidos ‘S/N’, ‘M/F’), temos dois cenários, se a tabela estiver vazia (sem nenhum
registro) a alteração vai proceder normalmente, mas se a tabela estiver já populada
(com registros), provavelmente vai dar errado.
Como é possível incluir uma nova coluna com propriedade ‘not null’ se já existem
registros na tabela, esses registros receberiam uma coluna inicialmente vazia e isto
entra em contradição com a regra ‘not null’.
O que pode ser feito?
Incluir a nova coluna sem a regra ‘not null’, depois execute um comando Update
populando esta coluna nova em todos os registros da tabela e depois execute
novamente o comando Alter modificando a regra de validação de ‘null’ para ‘not null’.
Se a alteração envolver aumentar o tamanho de um campo, independentemente
deste campo ser numérico ou alfanumérico, esta é uma operação executada
tranquilamente.
Agora, se a alteração envolver diminuir o tamanho de um campo, tudo vai depender
dos dados que estejam armazenados neste campo na tabela.

98. Se a tabela estiver vazia, a alteração é executada na hora.
Se a tabela já possuir registros dentro, o impacto da modificação é feito antes,
analisando se a quantidade/tamanho da diminuição afeta algum registro já
armazenado ou não, por exemplo, um campo nome com 50 caracteres que vai ser
modificado para 40 caracteres, se em todos os registros armazenados os nomes
tiverem menos de 40 caracteres no nome, a modificação é processada na hora, mas
se existir um registro apenas cujo conteúdo do nome seja maior que 40 caracteres,
já vai dar errado e o comando não será processado.
O que fazer então, tem que ser analisado se os dados podem ser truncados ou não,
não é uma decisão que o analista de sistemas pode tomar sozinho, tem que ser
conversado com os usuários antes de qualquer decisão.
Uma modificação de tipo de dado então é mais complicada ainda.
Modificar uma coluna numérica para alfanumérica pode ser fácil, porém é preciso
lembrar que os números estão sempre alinhados pela direita e depois desta
modificação estarão alinhados pela esquerda.
Já modificar uma coluna alfanumérica para numérica, só vai dar certo se na coluna
original, todos os dados sejam números e não podemos esquecer-nos do alinhamento
à esquerda que passará a ser pela direita. Lembre-se que em um campo
alfanumérico, o zero a esquerda pode ser significativo (telefone 04333750000).
Quando modificamos o tipo do dado, se a tabela estiver vazia, o resultado é a hora,
mas se a tabela estiver populada, os dados precisam ser analisados antes.
Esta compreensão de cenário é muito importante porque é comum encontrarmos
analistas de sistemas dizendo:
‘no banco de testes deu certo, fiz todos os procedimentos e deu ok, mas quando
fomos aplicar as mesmas modificações no banco de produção, deu tudo errado’.
Onde está o erro? Banco de testes geralmente não tem a mesma ‘massa’ de dados
do banco de produção.
Por causa deste tipo de situação, em empresas cuja área de TI está bem estruturada,
geralmente tem no mínimo 3 ambientes, um banco de dados de produção (o
principal), um banco de dados de homologação (cópia da produção para testes, que
periodicamente é igualado ao de produção, para manter o retrato mais fiel possível
da produção) e um banco de dados de testes e desenvolvimento, onde são realizados
todos os testes iniciais.

99. COMANDO DROP
O comando DROP permite eliminar definitivamente uma tabela do banco de dados,
ou seja, além de todos os dados, a estrutura de armazenamento também é
eliminada.
Caso a tabela em questão seja parte de uma regra de integridade referencial, ou
seja, possui chave primária sendo doado para outra tabela, o comando não vai ser
executada de forma natural, uma mensagem de erro é emitida.
Você terá duas alternativas, a primeira é desativar a integridade referencial e depois
eliminar a tabela. E a segunda é eliminar a tabela acrescentando na sua sintaxe a
cláusula ‘CASCADE CONSTRAINTS’ que faz este papel de eliminar a integridade
referencial para você.
COMANDOS PARA CONTROLE DE ACESSOS

100. Quando os objetos do banco de dados (tabelas, índices, procedures, etc.) são
acessados pelo próprio dono destes objetos, não é necessário nenhum controle de
acesso, porém quando desejamos que outro usuário faça uso destes recursos,
precisamos e podemos controlar estes acessos.
Nestes casos chamamos de direito de acesso aos objetos do banco de dados que são
trabalhados no sentido de conceder o acesso (GRANT) e revogar o direito de acesso
(REVOKE).
COMANDO GRANT
O comando GRANT permite conceder o direito de acesso de um determinado objeto
do banco de dados para outro usuário do banco de dados.
Podemos controlar direitos de acessos como ‘SELECT, INSERT, UPDATE ou DELETE’.
Assim, para o usuário X é possível conceder o direito SELECT e INSERT na tabela
cliente.
Desta forma, o usuário X (que não é dono da tabela cliente) poderá gravar novos
clientes e consultaros clientes existentes, porém este usuário X não poderá modificar
os dados de nenhum cliente ou mesmo eliminar clientes cadastrados.
COMANDO REVOKE
O comando REVOKE permite revogar ou eliminar um determinado direito de acesso
que foi concedido para um usuário sobre um determinado objeto.
A revogação poderá ser total (ALL) ou parcial, especifico de um determinado tipo de
acesso.
COMANDO ROLE
Quando a quantidade de usuários nos sistemas aumenta muito, organizar e controlar
a concessão ou revogação de acessos aos objetos do banco de dados pode ficar
complicado ou gerando um trabalho enorme.
Imagine um sistema aplicativo com aproximadamente 1.000 usuários, ao incluirmos
uma nova tabela no sistema e ter que executar a liberação de acesso, serão 1.000
comandos no mínimo. Isto sem falar que dentro destes 1.000 usuários poderemos
ter diversos perfis de acesso (alguns só select, outros select e delete, outros select e
insert, outros tudo).
Para facilitar um pouco este tipo de controle, podemos agrupar os usuários pode
perfis de acesso ou ‘papéis de acesso’ dentro do sistema, que chamamos de ROLE.
Neste caso, os comandos GRANT e REVOKE seriam dados os ROLES e os usuários
incluídos dentro dos ROLES.
Se um usuário estiver dentro de mais de um ROLE, ele vai acumular os direitos, ou
seja, vira uma somatória.

101. QUESTÕES PARA REFLEXÃO
Para entendermos um melhor vamos apresentar um cenário com duas tabelas, uma
integridade referencial entre elas e dados que populem ambas as tabelas.
00:00
00:00
VÍDEO AULA 05 – DIRETIVAS DE ACESSO
O modelo conceitual apresenta a tabela Marca com os atributos id_marca e
nm_marca, que receberão dados das principais montadoras de veículo do Brasil.
A segunda tabela é o Modelo, com os atributos nm_modelo, tp_modelo e
tp_combustivel, que receberão dados dos principais veículos das montadoras
brasileiras.
O relacionamento é de 1-N, onde uma Marca possui vários Modelos e cada Modelo é
de uma única Marca.
Uma Marca cadastrada pode não ter nenhum Modelo ainda, mas todo Modelo deve
obrigatoriamente estar associado a uma Marca.
Justificando assim as cardinalidades mínimas e máximas de cada entidade.
Marca (1,1) – possui – (0,N) Modelo
Fonte: Nishimura (2012).
O modelo lógico já apresenta a integridade referencial estabelecida a nível lógico,
com a chave primária da tabela Marca como uma chave estrangeira e primária na
tabela Modelo compondo junto com o atributo nm_modelo, uma chave primária
composta (relacionamento forte).

102. Fonte: Nishimura (2012).
O modelo físico apresenta os comandos para a criação física destas tabelas e do
relacionamento.
Fonte: Nishimura (2012).
Tabela Marca
Fonte: Nishimura (2012).

103. Fonte: Nishimura (2012).
O que pode acontecer com os seguintes comandos?
1 ) INSERT INTO MARCA VALUES (7,’HYUNDAI’) ;
2 ) UPDATE MARCA SET ID_MARCA = 11 WHERE NM_MARCA = ‘FIAT’ ;
3 ) SELECT * FROM MARCA WHERE NM_MARCA = ‘KIA’ ;
4 ) DELETE MARCA WHERE ID_MARCA = 2 ;
5 ) DELETE MARCA WHERE NM_MARCA = ‘TOYOTA’ ;
6 ) INSERT INTO MODELO VALUES (11, ‘HB20’, ‘HATCH’, ‘F’);
7 ) DELETE MODELO WHERE NM_MODELO = ‘FOX’ ;
8 ) DELETE MODELO WHERE NM_MODELO = ‘307’ ;
9 ) INSERT INTO MODELO VALUES (2, ‘PUNTO’, ‘HATCH’, ‘F’) ;
10) UPDATE MODELO SET ID_MARCA = 1 WHERE NM_MODELO = ‘PUNTO’ ;
RESPOSTAS
1 ) Este comando apresentará erro pois o ID_MARCA com valor igual a 7 já existe
dentro da tabela, receberá mensagem de chave primária duplicada.
2 ) Este comando apresentará erro pois a troca de valores de campos chave primária
não são permitidos, seria necessário deletar o valor antigo e depois incluir o valor
novo.

104. 3 ) Sintaticamente este comando está correto e a resposta será ‘nenhum valor
encontrado’ pois a marca KIA ainda não está cadastrada na tabela MARCA.
4 ) Apesar deste comando estarsintaticamente correto, ele não poderá ser executado
pois o ID_MARCA = 2 tem registros referenciados na tabela MODELO, que não podem
ficar órfãos, é necessário remover os modelos primeiro.
5 ) Apesar deste comando estarsintaticamente correto, ele não poderá ser executado
pois o campo NM_MARCA apesar de não ser a chave primária da tabela MARCA, com
o conteúdo ‘TOYOTA’ possui registros na tabela MODELO que são referenciados pela
chave primária de forma automática (conhecido como integridade referencial).
6 ) Este comando está sintaticamente correto, porém faz o uso de um valor para
ID_MARCA = 11, e este valor não existe na tabela MARCA, por isso viola a integridade
referencial por fazer referencia a um valor inexistente.
7 ) Este comando está sintaticamente correto e a resposta será ‘nenhum registro
deletado’, pois na tabela MODELO não temos o valor ‘FOX’ em nenhuma das
ocorrências da tabela.
8 ) Este comando está sintaticamente correto e a resposta será ‘1 registro deletado’.
9 ) Este comando está sintaticamente correto e será executado ‘OK’, para o banco
de dados, ele não sabe que ‘PUNTO’ não é da ‘VOLKSWAGEM’ mas a partir deste
momento esta é uma informação verdadeira para o banco de dados.
10) Este comando está sintaticamente correto porém não pode ser executado pois
não é permitido alterar / atualizar valores em campos que sejam parte da chave
primária, como é o caso do ID_MARCA na tabela MODELO (é chave primária e chave
estrangeira ao mesmo tempo).
Estas foram apenas algumas dicas para demonstrar que o mundo do banco de dados
é bem organizado e a utilização do padrão SQL facilita muito o dia a dia.
A prática é o melhor caminho para o seu aperfeiçoamento e nunca se esqueça de que
‘o mesmo comando pode ser comportamento e resultados diferentes em bancos de
dados diferentes’.
ENCERRAMENTO
Chegamos ao final da nossa disciplina, espero que tenham gostado do nosso
conteúdo e compreendido que um banco de dados para web precisa de um cuidado
especial, principalmente porque o seu funcionamento é um pouco diferente do
modelo tradicional.
Questão para reflexão Unidade II
Na unidade II da web aula, o padrão SQL com as operações CRUD e propriedades
ACID é que foram os pontos de atenção.
Como a padronização de comandos entre softwares concorrentes pode ser
considerado algo vantajoso? Participe do fórum.

105. Usuário feliz Analista feliz
Obrigado
CHEN, Peter. Modelagem de dados. São Paulo: Mc Graw Hill/Makron, 1990.
HEUSER, Carlos Alberto. Projeto de banco de dados. Porto Alegre: Sagra Luzzato,
1999.
NISHIMURA, Roberto Yukio. Banco de dados I. São Paulo: Pearson, 2009.
_______.Banco de dados II. São Paulo: Person, 2009.
SILBERSCHATZ, A & KORTH, H & SUDARSHAN, S. Sistemas de banco de dados.
São Paulo: Campus, 2012.
SUGESTÕES DE LEITURA
KROENKE, David M. Banco de dados. Rio de Janeiro: LTC, 1999.
Visão geral
Apresentação da disciplina:
O estudo sobre Interação Humano-Computador (IHC) tem como
direcionamento facilitar a utilização de sistemas computacionais e
geralmente seu foco está relacionado com a satisfação do usuário a
partir das funcionalidades das aplicações. Essa satisfação pode ser
definida através da qualidade de uma interação entre o ser humano
e o computador. Para saber se uma interação possui boa qualidade,
existem direcionamentos e técnicas de avaliação de IHC que serão
apresentadas nesta disciplina.
Objetivos:
Trabalhar com princípios para concepção de interfaces com foco em
usabilidade e técnicas de avaliação de IHC.

106. Conteúdo Programático:
- Conceitos de Usabilidade
- Critérios Ergonômicos de Usabilidade
- Conceitos e definições de métodos e técnicas de avaliação de IHC.
Metodologia:
Na unidade utilizaremos todos os recursos necessários e disponíveis
para o desenvolvimento da discussão do conteúdo, sendo assim,
faremos uso de:
 Textos da própria web-aula e de outros sites que possam
contribuir para a discussão;
 Vídeos que podem esclarecer ou aprofundar determinados
conteúdos;
 Fóruns para discussão de tópicos onde seja possível a troca de
ideias e conteúdos entre os discentes e docentes;
 Avaliações virtuais onde será realizada a verificação do
aprendizado;
 Entre outros recursos que poderão ser utilizados visando
maior entendimento da matéria.
Avaliação Prevista:
Cada web aula conterá uma avaliação virtual composta de 5
questões (sendo assim, temos 2 web-aulas com 5 questões cada).
Quando houver fórum de discussão o aluno será avaliado quanto ao
conteúdo de sua postagem, onde deverá comentar o tópico
apresentando respostas completas e com nível crítico de avaliação
pertinente ao nível de pós-graduação.
Critérios para Participação dos Alunos
no Fórum:
Quando houver fórum de discussão o aluno será avaliado quanto ao
conteúdo de sua postagem, onde deverá comentar o tópico
apresentando respostas completas e com nível crítico de avaliação
pertinente ao nível de pós-graduação. Textos apenas concordando
ou discordando de comentários de outros participantes do fórum
sem a devida justificativa ou complementação não acrescentam em
nada ao debate da disciplina, sendo assim, devem ser evitados. Os
textos devem sempre vir acompanhados das justificativas para a
opinião do discente sobre o conteúdo discutido, para que assim,
possamos dar continuidade ao debate em nível adequado. Além
disso, podem ser utilizados citações de artigos, livros e outros
recursos que fundamentem a opinião ou deem sustentação a sua
posição crítica sobre o assunto. Deve ser respeitado o tópico

107. principal do fórum, evitando debates que não tem relação com o
tema selecionado pelo professor.
Habilidades e competências
Espera-se que no final do curso os alunos possam:
a) Desenvolver habilidades de análise em IHC (Interação Humano-
Computador)
b) Estimular a utilização dos conceitos de boas práticas de IHC
(Interação Humano-Computador) para desenvolvimento de
interfaces com boa qualidade de uso;
c) Propiciar ao profissional de informática, o entendimento de
diversos tipos de métodos e técnicas de avaliação de IHC (Interação
Humano-Computador) para apoio no desenvolvimento de
aplicações;
TECNOLOGIAS PARA APLICAÇÕES WEB
Olá!
Sou o professor Everson, sou mestre em Ciência da Computação e vou
trabalhar com você sobre conceitos que envolvem o campo de IHC
(Interação Humano-Computador).
Os aspectos abordados nos conteúdos serão em torno de métodos e técnicas
de avaliação de IHC.
Vamos, participe efetivamente!
RESUMO
O estudo sobre Interação Humano-Computador (IHC) na computação vem sendo
realizado há vários anos, visando facilitar a utilização de sistemas computacionais.
Devido ao número crescente dos sistemas computacionais interativos, esses estudos
foram-se intensificando.

108. Nesse contexto, a partir das funcionalidades das aplicações, o foco geralmente está
direcionado à satisfação do usuário. Essa satisfação pode ser definida através da
qualidade de uma interação entre o ser humano e o computador.
Para saber se uma interação possui boa qualidade, existem as técnicas de avaliação
de IHC. Nesse sentido esta unidade descreve os direcionamentos e técnicas de
avaliação de IHC.
WEB AULA 1
Unidade 1 – Interações Humano-Computador
INTRODUÇÃO
Ao iniciar o nosso estudo, vamos ver algumas definições de alguns autores sobre
Interação Humano-Computador (IHC).
A partir desse conceito, surgiram novas interpretações a respeito dos aspectos que
englobam interfaces. Segundo Moran (1981), “a interface de usuário deve ser

109. entendida como sendo uma parte do sistema computacional com a qual uma pessoa
entra em contato física, perceptiva e conceitualmente”.
Diante disso, Prates e Barbosa (2003, p. 246) complementam que a dimensão física
inclui os elementos de interface que o usuário pode manipular, enquanto a dimensão
perceptiva engloba aqueles que o usuário pode perceber.
A dimensão conceitual resulta de processos de interpretação e raciocínio do usuário,
desencadeados pela sua interação com o sistema, com base em suas características
físicas e cognitivas, seus objetivos e seu ambiente de trabalho.
Dessa forma, ao criar uma interface com boa qualidade de interação, devem
ser analisados além da proposta de software e hardware, os aspectos que
envolvem a ação e interpretação do ser humano.
Nesse sentido, vamos analisar uma representação gráfica de um modelo básico
de interação humano-computador (Figura 1):
Vamos à nossa Vídeo Aula 01
O Plugin Silverlight está desabilitado ou não foi instalado em seu browser, faça o download
clicando aqui ou ative o mesmo.
No contexto do processo de interação humano-computador, segundo Preece et al
(1994), o objetivo de IHC é produzir sistemas utilizáveis e seguros, como também
sistemas funcionais.
Para Preece et al (1994 apud Interacting with Computers, 1989, p. 3), essas metas
podem ser resumidas em desenvolver ou melhorar segurança, utilidade, efetividade,
eficiência, e usabilidade de sistemas no meio computacional.
Nesse caso, para alcançar as metas estabelecidas, é necessário que o processo de
interação humano-computador passe por um processo de avaliação, a fim de

110. identificar possíveis problemas, bem como servir de retroalimentação para o
desenvolvimento.
Veja o vídeo...
http://www.uxdesign.blog.br/usabilidade/usabilidade-por-luli-radfahrer/
Então, conseguiu perceber o direcionamento inicial para a construção
de uma interface com boa qualidade de interação?
O grande foco é pensar sempre que o usuário deve ter
uma interface amigável e para isso é necessário ter objetos que indiquem seu
caminho, como exemplo, uma estrada bem sinalizada. Outro ponto é manter o
usuário sempre informado do status da página, onde ele está e o que está
acontecendo...
Atualmente, existem muitos sites e softwares para web com várias abordagens e
com diferentes objetivos. Isso pode dificultara elaboração de uma interface com boa
qualidade de interação. Por isso, devemos sempre vincular dois itens básicos para a
construção de uma interface, sendo aqualidade de uso com seu objetivo.
Um importante início para a criação de uma página web é respeitar muito seu
principal objetivo.
Um grande exemplo de sucesso é a página da Google, sendo
uma página limpa direcionada para a pesquisa com vários subitens, mas
disponibilizados de forma discreta, não causando poluição da página.
www.google.com.br
Acesse a página e navegue com tranquilidade, é isso, o objetivo de uma boa
interface.
A grande responsável por deixar a página do Google limpa foi a Marissa Mayer (na
época vice-presidente da Google).

111. Sua iniciativa a levou para uma carreira de sucesso e atualmente, foi convidada para
assumir a presidência da Yahoo...
Vejam a reportagem:
São Paulo - A presidente-executiva do Yahoo, Marissa Mayer, apresentou nesta terça-
feira a nova versão do Yahoo Mail, popular serviço que ficará mais rápido e com um
visual mais "clean" e homogêneo para diferentes tipos de dispositivos.
Essa é a primeira reformulação de um produto do Yahoo durante a gestão da ex-
executiva do Google, reconhecida no Vale do Silício pelos práticos produtos de
Internet que criou.
O Yahoo é um dos sites mais populares do mundo e recebe quase 700 milhões de
visitas por mês, mas a receita caiu diante da concorrência com o Google e o
Facebook, além de transformações no mercado publicitário online, que pressionaram
as tarifas dos anúncios, essenciais para o Yahoo.
Marissa assumiu o cargo em julho, e desde então as ações da companhia acumulam
ganho de 25 por cento e estão no maior nível desde setembro de 2008, quando o co-
fundador Jerry Yang ainda era o presidente-executivo.
Fonte: http://info.abril.com.br/noticias/internet/marissa-mayer-
apresenta-nova-versao-de-e-mail-do-yahoo-11122012-26.shl
Para uma descontração... Mas também, lembrando que o usuário também
deve fazer a sua parte!
http://www.videosdehumor.com.br/teste-de-usabilidade-google/
Páginas Poluídas...
Por outro lado temos algumas páginas que considero poluídas e causam um cansaço
expressivo, como exemplo, encontramos algumas páginas de jornais.
Até entendo que o objetivo dessas páginas é de notícias e para atrair o usuário para
sua leitura é necessário mais informações do que a da Google, mas acho que é um
campo que merece um estudo maior sobre qualidade de uso.
Faça um teste, deixe uma tela de jornal aberta quando você não estiver utilizando o
computador e fique por perto a analisando, você vai perceber que causará certo
desconforto...

112. Estive pesquisando para montar esta aula e acessei algumas dessas páginas, como
exemplo a Folha de São Paulo, apresenta um excesso de informações e
animações o tempo todo, como disse, acho que está dentro do seu objetivo, mas
poderia ser melhor.
Uma fonte de pesquisa no Brasil importante para o campo de IHC é o Labiutil -
Laboratório de Utilizabilidade da UFSC.
Navegue e aproveite para estudar!
http://www.labiutil.inf.ufsc.br/
Qualidade de Uso...
Então, como alinhar os parâmetros de qualidade de uso
com os objetivos e interesses de cada software?
Para esse alinhamento é necessário entender melhor sobre os conceitos que
direcionam para uma interface com boa qualidade.
Iniciando vamos conhecer indicações de qualidade segundo a norma ISO 9241-11 de
1998, que foi criada pela International Standard Organization e consideradas como
requisitos ergonômicos para trabalho de escritórios com computadores.
Vamos ver as definições dos termos que envolvem a norma ISO 9241-11:

113. Usabilidade
É a medida na qual um produto pode ser usado por usuários específicos para alcançar
objetivos específicos com eficácia, eficiência esatisfação em um contexto
específico de uso.
Nesse contexto, a usabilidade deve ser entendida como um caminho que possibilita
ao usuário executar sua tarefa de forma ágil e intuitiva e ainda, sem erros ou
dificuldades provocadas ou direcionadas pela própria aplicação.
Acesse o link e faça a leitura do artigo...
http://www.labiutil.inf.ufsc.br/hiperdocumento/unidade1_2.html
Eficácia
Está ligada à acurácia e completude com as quais os usuários alcançam objetivos
específicos.
Acurácia: o quanto o usuário consegue chegar próximo ao seu objetivo.
Eficiência
Relaciona-se com o nível de eficácia alcançada no consumo de recursos relevantes,
como esforço mental ou físico, tempo, custos materiais ou financeiros.
No contexto em estudo consiste em alcançar o resultado com o menor
recurso possível.
Satisfação
Tem a ver com o conforto e com atitudes positivas em relação ao uso de um
produto, podendo ser medida pela avaliação subjetiva em escalas de desconforto
experimentado, gosto pelo produto, satisfaçãocom o uso do produto ou aceitação da
carga de trabalho, quando da realização de diferentes tarefas, ou a extensão dos
objetivos de usabilidade que foram alcançados.
Contexto de Uso
Refere-se a usuários, tarefas, equipamentos (hardware, software e materiais) e ao
ambiente físico e social no qual um produto é usado.
Sistema de Trabalho
Envolve o sistema, composto de usuários, equipamento, tarefas e o ambiente físico
e social, com o propósito de alcançar objetivos específicos.
Sua diferença entre o contexto de uso é porque a análise deve ser
direcionada ao alcance do objetivo proposto.
A partir desses termos, a ISO traz uma estrutura de usabilidade, ilustrado na seguinte
figura:

114. Vamos à nossa Vídeo Aula 02
O Plugin Silverlight está desabilitado ou não foi instalado em seu browser, faça o download
clicando aqui ou ative o mesmo.
Na especificação de usabilidade devem descrever os objetivos pretendidos e os
componentes do contexto de uso como usuários, tarefas, equipamento e ambientes,
detalhando-se os aspectos que influenciam a usabilidade e, descrevem-se, também
os valores reais ou desejados de eficácia, eficiência e satisfação para o objetivo do
contexto.
De acordo com a ISO 9241-11, no campo de usabilidade, é necessário ter as medidas
de eficácia, eficiência e satisfação, de acordo com o contexto de uso e das propostas.
O nível de detalhes de cada medida depende dos objetivos das partes envolvidas na
medição, devendo ser considerada a importância relativa de cada medida para os
objetivos.
Essas medidas podem ser especificadas para objetivos globais ou para objetivos
menores.
Um exemplo de objetivos globais é ilustrado na Tabela Exemplo de Medidas de
Usabilidade.

117. De acordo com a ISO 9241-11, as medidas de usabilidade dependem dos requisitos
do produto e das necessidades da organização.
Os objetivos de usabilidade podem ser: primários, menores, ou secundários, em que,
determinar objetivos menores pode permitir uma avaliação antecipada no processo
de desenvolvimento.
Em relação aos critérios, estes podem reduzir-se ao menor nível aceitável, ou para o
nível esperado de usabilidade, e seus valores para um grupo de usuários podem ser
uma média, para todos indivíduos ou para uma porcentagem de usuários, tomando-
se cuidado para que seja dado o peso apropriado para cada item de medida.
Acesse o link para aprofundar nos detalhes da Norma ISO 9241-
11:
TESTES FOCADOS NA USABILIDADE, COMUNICABILIDADE E
APLICABILIDADE
Para testar a usabilidade, são envolvidas as seguintes
questões: facilidade de aprendizado e uso, eficiência de uso e produtividade,
satisfação, flexibilidade, utilidade e segurança.
Dessa forma, objetiva-se quantificar o desempenho do usuário. Para a preparação
do teste, devem ser definidos os limites mínimos aceitáveis, os máximos possíveis
e, também, o valor almejado para a medida do projeto (PRATES E BARBOSA,
2003).
Cybis (2003), define que se deve propor a elaboração de um plano de testes de
usabilidade, cuja composição será uma seqüência estruturada de avaliação, com
base nos objetivos a serem atingidos, como se relata a seguir:
a) Constatar, observar e registrar, problemas efetivos de usabilidade durante a
interação;
b) Calcular métricas objetivas para eficácia, eficiência e produtividade do usuário
na interação com o sistema;

118. c) Diagnosticar as características do projeto que provavelmente atrapalhem a
interação por estarem em desconformidade com padrões implícitos e explícitos de
usabilidade;
d) Prever dificuldades de aprendizado na operação do sistema;
e) Prever os tempos de execução de tarefas informatizadas;
f) Conhecer a opinião do usuário em relação ao sistema;
g) Sugerir as ações de re-projeto mais evidentes em face dos problemas de
interação efetivos ou diagnosticados.
COMUNICABILIDADE
A Comunicabilidade baseia-se na capacidade de os usuários entenderem o design da
mesma maneira como é entendido pelos projetistas,possibilitando-lhes interagircom
o sistema e transmitir, de maneira eficaz, as intenções projetadas.
Segundo de Souza et al. (2001), a comunicabilidade de um sistema é a propriedade
de transmitir ao usuário, de forma eficaz e eficiente, as intenções e princípios de
interação que guiaram o seu design.
Da mesma forma, o objetivo da comunicabilidade é permitir que o usuário, através
da sua interação com a aplicação, seja capaz de compreender as premissas,
intenções e decisões tomadas pelo projetista durante o processo de design.
Quanto maior o conhecimento que o usuário, tem da lógica do designer que há na
aplicação, maiores são suas chances de conseguir fazer uso criativo, eficiente e
produtivo da aplicação.

119. PRATES E BARBOSA 2003, p.249 apud DE SOUZA et al, 1999; PRATES ET AL,
2000b
O objetivo da comunicabilidade é revelar qualitativamente as falhas de comunicação
potenciais, que podem ocorrer durante a interação.
Segundo Prates e Barbosa (2003), a análise dos dados é dividida em 3 passos:
Estas expressões são relacionadas com o usuário, como caracterizadas a
seguir:
 Onde está? O usuário sabe o que deseja executar, mas não o encontra de
imediato;
 E agora? O usuário não sabe o que significa e procura descobrir qual é o seu
próximo passo;

120.  O que é isto? O usuário não sabe o que significa um elemento na interface;
 Epa! O usuário realizou uma ação indesejada e percebe imediatamente;
 Onde estou? O usuário efetua operações que são apropriadas para outros
contextos, e não para o atual;
 Assim não dá! O usuário efetuou uma sequência longa de operações, antes
de perceber que estava seguindo um caminho improdutivo;
 Por que não funciona? A operação efetuada não produz o resultado
esperado, mas o usuário não entende;
 Ué, o que houve? O usuário não entende a resposta dada pelo sistema para
a sua ação;
 Para mim está bom... O usuário acha equivocadamente que concluiu uma
tarefa com sucesso;
 Desisto. O usuário não consegue fazer a tarefa e desiste;
 Vai de outro jeito. O usuário não consegue realizara tarefa como o projetista
gostaria, e resolve seguir outro caminho;
 Não, obrigado. O usuário já conhece a solução preferencial do designer, mas
opta por uma outra forma de interação;
 Socorro! O usuário não consegue realizar sua tarefa.
Como exemplo veja-se a seguinte classificação genérica de problemas
relacionados à interpretação:
 Execução: o usuário não consegue atingir o objetivo;
 Navegação: o usuário se perde durante a interação;
 Atribuição de significado: o usuário não é capaz de atribuir um significado
relevante a signos da interface;

121.  Percepção: o usuário não consegue perceber alguma resposta ou estado do
sistema;
 Incompreensão de affordance: o usuário não entende uma solução
oferecida pelo designer e executa de uma forma mais complicada;
 Recusa de affordance: o usuário entende a solução principal oferecida, mas
escolhe outra.
Assim, este passo acrescenta à avaliação os problemas
identificados, podendo fazer considerações sobre possíveis premissas de
design e conhecimentos táticos, a partir da representação do contexto da
aplicação.
Continuando nosso estudo!
Abaixo é apresentada uma tabela de associação entre expressões e classes de
problemas:
Associação entre expressões e classes de problemas
Expressão de
Comunicabilidade
Problemas de Interação
ExecuçãoNavegação
Atribuição
de
significado
Percepção
Incompreensão
de affordance
Onde está? X
E agora? X X X
O que é isto? X
Epa! X X
Onde estou? X X X

122. Assim não dá. X X X
Por que não
funciona?
X X
Ué, o que houve? X X
Para mim está bom. X X
Não, dá. X
Vai de outro jeito X
Não, obrigado.
Socorro! X X X
A tabela acima resume o direcionamento para as observações que devem ser
analisadas em uma aplicação, principalmente quando se trata de um software para
web.
Nesse caso, o usuário por estarlonge e não tem um fácil acesso ao suporte para tirar
dúvidas ou a uma capacitação.
Muitas vezes, criar um software parece estar ligado a simplesmente a codificação,
“ah isso é fácil”, “aquilo é mais difícil”, mas geralmente é deixado de lado a interação
com o usuário.
Cuidado!
Essa interação pode definir o sucesso de sua aplicação...
Assim, um projeto de interface de concepção mais próxima do processo
cognitivo do usuário, pode ter maior eficiência na comunicabilidade.
APLICABILIDADE
A qualidade dos sistemas que podem ser usados com
sucesso em uma ampla variedade de contextos, incluindo até mesmo aqueles em
que o objetivo do usuário não é o objetivo original concebido pelos seus designers,
depende da sua utilidade na resolução de problemas variados. Assim, Fischer (1998)
define a aplicabilidade.
Dentro desse conceito, para Prates e Barbosa (2003), a aplicabilidade permite
determinar:
a) Quanto o sistema é útil para o contexto para o qual foi projetado;
b) Em que outros contextos o sistema pode ser útil.

123. Segundo Fischer (1998), a idéia é aumentar a participação do usuário nas
decisões dos sistemas, para que ele tenha um sistema mais aberto, e seja mais
participativo, com maior poder de decisão.
Nesse caso, uma boa aplicabilidade está relacionada com aplicações de um sistema
que sejam mais condizentes com a realidade de um usuário.
Diversos pesquisadores afirmam que é necessário desenvolversistemas que ampliem
as capacidades dos usuários, em vez de tentar substituí-los, possibilitando que eles
ajam de forma mais inteligente e eficiente (PRATES e BARBOSA 2003 apud ADLER &
WINOGRAD, 1992).
Vamos à nossa Vídeo Aula 03
O Plugin Silverlight está desabilitado ou não foi instalado em seu browser, faça o download clicando aqui ou ative
o mesmo.
A baixa qualidade de uso de sistemas pode trazer diversos problemas,
destacados por Prates e Barbosa na seguinte figura:
O contexto estudado demonstra que a partir das funcionalidades das aplicações, o
foco geralmente está direcionado à satisfação do usuário.
Essa satisfação pode ser definida através da qualidade de uma interação entre o ser
humano e a aplicação, envolvendo partes físicas, emocionais e o contexto onde
acontece a atividade.
E para saber se uma interação possui boa qualidade, foram realizadas observâncias
em torno da qualidade de uso. Mas, para apoiar na construção de boas interfaces
podemos contar ainda com as técnicas de avaliação de IHC, que serão apresentadas
na nossa próxima aula.

124. Então... Conseguiu visualizar o caminho para uma boa qualidade de uso de
interação?
Continue estudando... Acesse o link e navegue:
http://www.labiutil.inf.ufsc.br/hiperdocumento/conteudo.html
Aproveite para um descanso e vamos para a próxima aula...
Participe do fórum de discussão! Alguns livros da biblioteca digital da
Pearson para sua consulta:
Projeto interface homem-computador (MORAIS, Everson Matias de; SOLER,
Luciano)
Interação Humano-Computador (David Benyon)
Como Criar Sites Persuasivos (Chak, Andrew)
[Airasian et al, 1977] Airasian, P. W. et al; Avaliação educacional: planejamento,
análise de dados, determinação de custos. Petrópolis: Vozes, 1977.
[Babbie, 1999] Babbie, E.; Métodos de Pesquisas de Survey. Belo Horizonte:
Editora da UFMG, 1999.
[Bastien e Scapin, 1993] Bastien, C.; Scapin, D.; Human factors criteria,
principles, and recommandations for HCI: methodological and
standardisation issues. Internal Repport - INRIA, 1993.
[Bastien e Scapin, 1997] Bastien, C.; Scapin, D.; Ergonomic criteria for
evaluating the ergonomic quality of interactive system. Behaviour and
Information Technology 16 (4/5): 220-231, 1997.
[Benyon , 1993] Benyon, D.; Adaptive Systems: A Solution to Usability
Problems. Computing Department, Open University, Milton Keynes, MK7 6AA UK,
1993.

125. [Cook e Campbell, 1979] Cook, T. D.; Campbell, D.T.; Quasi-experimentation:
design and analysis issues for field settings. Chicago: Rand Mc Nally, 1979.
[Cybis, 2003] Cybis, W. A.; Engenharia de Usabilidade: uma abordagem
ergonômica, Florianópolis: Universidade Federal de Santa Catarina, 2003.
[Cybis et al, 1998] Cybis, W. A. et al; Uma Abordagem Ergonômica para o
Desenvolvimento de Sistemas Interativos, Florianópolis: Universidade Federal
de Santa Catarina, 1998.
[de Souza et al, 2001] de Souza, C. S. et al; Projeto de Interfaces de Usuário –
Perspectivas Cognitivas e Semióticas. Rio de Janeiro, 2001.
[Erthal, 2003] Erthal, T. C.; Manual de Psicometria. Rio de Janeiro: Jorge Zahar
Ed., 2003.
[Fernandes et al, 1996] Fernandes, F. et al; Dicionário Brasileiro Globo. 43 ed.
São Paulo: Globo, 1996.
[Ferreira, 2004] Ferreira, A. B. H.; Novo Dicionário Aurélio da Língua
Portuguesa. 3 ed. Curitiba: Positivo, 2004.
[Fischer, 1998] Fischer, G.; "Beyond 'Couch Potatoes': From Consumers to
Designers", Proceedings of the 3rd Asia Pacific Computer Human Interaction
Conference, IEEE Computer Society, 1998.
[Hoelzel, 2004] Hoelzel, C. G. M.; Design Ergonômico de Interfaces Gráficas
Humano-Computador: Um Modelo de Processo,Florianópolis: Universidade
Federal de Santa Catarina, 2004.
[ISO, 2007] ISO 9241-11:1998; Ergonomic Requirements for Office Work with
Visual Display Terminals (VDTs), Part 11, Guidance on Usability. Disponível em:
< http://www.inf.ufsc.br/~cybis/pg2003/iso9241-11F2.pdf >; acesso em: Abr. 2007
[Kaplan, 1975] Kaplan, A.; A conduta na pesquisa: metodologia para as
ciências do comportamento. 2. ed. São Paulo: EPU, 1975.
[LabIUtil, 2006] Laboratório de Utilizabilidade, ErgoList, Universidade Federal de
Santa Catarina, < http://www.labiutil.inf.ufsc.br/ergolist/ >; acesso em: jan. 2006.
[Moran, 1981] Moran, T.; The Command Language Grammars: a
representation for the user interface of interactive computer systems.
International Journal of Machine Studies, 1981.
[Nevo, 1986] Nevo, D.; The conceptualization of educational evaluation: An
analytical review of the literature. House, Ernest R. (editor).New directions in
educational evaluation. Philadelphia, USA: The Falmer Press, 1986.
[Nielsen, 2007] Nielsen, J.; Severity Ratings for Usability Problems. Disponível
em: < http://www.useit.com/papers/heuristic/ severityrating.html >; acesso em: 5
jan. 2007.
[Nielsen, 2006] Nielsen, J.; Ten Usability Heuristics. Disponível em: <
http://www.useit.com/papers/heuristic/heuristic_list.html >; acesso em: 10 dez.
2006.
[Nielsen e Mack, 1994] Nielsen, J. & Mack, R.; Usability inspection methods. EUA:
John Wiley & Sons, 1994.
[Oliver, 2001] Oliver, H..; Contribution à l’évaluation des logiciels multimédias
pédagogiques, PhD Thesis, University of Technology of Compiegne, France, 2001.

126. [Pfleeger, 2004] Pfleeger, S. L.; Engenharia de Software: teoria e prática. 2. ed.
São Paulo: Prentice Hall, 2004.
[Prates e Barbosa, 2003] Prates, R.O.; Barbosa, S.D.J.; Avaliação de Interfaces de
Usuário – Conceitos e Métodos. Anais do XXIII Congresso Nacional da Sociedade
Brasileira de Computação. XXII Jornadas de Atualização em Informática (JAI).
SBC’2003. Agosto de 2003.
[Preece et al, 1994] Preece, J. et al; Human-Computer Interaction. Addison
Wesley Longman Limited, England, 1994.
[Raupp e Reichle, 2003] Raupp, M.; Reichle, A.; Avaliação: ferramenta para
melhores projetos. EDUNISC, Santa Cruz do Sul, 2003.
[Rocha e Baranauskas, 2000] Rocha, Heloisa V. da; Baranauskas, Maria C.
C.; Design e avaliação de interfaces humano-computador. IME-SP, São Paulo,
2000.
[Scriven, 1996] SCRIVEN, M.; Types of evaluation and types of evaluators.
Evaluation Pratice, v. 1, n.13, 1996, p.151-161.
[Sykes, 1990] Sykes, V.; Validity and Reliability in Qualitative Marketing
Research : a Review of Literature. Journal of the Market Research Society, Vol.
32, nº 3, July, 1990.
[Unicef, 1991] A UNICEF guide for monitoring and evaluation: making a
difference? Evaluation Office, 1991.
[Yin, 1989] Yin, R. K.; Case Study Research - Design and Methods. Newbury
Park. Sage Publications, 1989.
TECNOLOGIAS PARA APLICAÇÕES WEB
WEB AULA 1
Unidade 2 – Interação Humano-Computador
RESUMO
A partir do estudo realizado na Unidade 1 sobre o contexto qualidade de uso,
identificaremos nesta unidade questões relacionadas às técnicas de avaliação da
interação de um usuário com sua aplicação.
Para isso vamos identificar aspectos que envolvem as técnicas de avaliação de IHC
descritas por diferentes autores.

127. Para saber se uma interação possui boa qualidade, existem as técnicas de avaliação
de IHC. Nesse sentido esta unidade descreve os direcionamentos e técnicas de
avaliação de IHC.
Veja no exemplo do vídeo de Portugal, a importância da usabilidade...
http://www.dailymotion.com/video/xek2hn_design-vs-usabilidade-caso-
pratico_school
AVALIAÇÃO DE IHC...
Conforme já explanado, o campo de IHC está relacionado à qualidade de um
sistema de computador, ou seja, à qualidade de uso de um software.
Para medir essa qualidade, e identificar possíveis problemas de interação,
existem várias técnicas e métodos de diferentes aspectos.
Essas técnicas e métodos estão relacionados ao objetivo do contexto a ser
avaliado e permitem avaliar a qualidade de interação entre o usuário e a
aplicação.
Problemas de Interface!
Como identificá-los?
Um caminho... São as técnicas de avaliação de IHC...
Agora, vamos conhecer aspectos sobre as técnicas e métodos
mais utilizados pelos principais autores da área...

128. Técnicas Prospectivas: utiliza-se uma metodologia baseada na aplicação de
questionários e entrevistas com o usuário para avaliar sua satisfação em relação ao
sistema e a sua operação.
Essas técnicas podem ser empregadas para auxiliar nas avaliações analíticas.
Técnicas Diagnósticas: baseiam-se em verificações e inspeções realizadas por
especialistas e nas quais se dispensa a participação direta de usuários.
Como exemplo, temos as avaliações heurísticas e as inspeções ergonômicas
via checklists.
Técnicas Definitivas: referem-se basicamente aos ensaios de interação e às
sessões com sistemas espiões e contam com a participação direta de usuários.
Como exemplo, temos as técnicas de ensaios de interação e sistemas de
monitoramento.

129. Vamos à nossa Vídeo Aula 04
O Plugin Silverlight está desabilitado ou não foi instalado em seu browser, faça o
download clicandoaqui ou ative o mesmo.
MÉTODOS DE AVALIAÇÃO ANALÍTICOS
Seus objetivos, segundo Prates e Barbosa (2003 apud Mack &
Nielsen, 1994):
- Identificar, classificar e contar o número de problemas de usabilidade encontrados
durante a inspeção...
- Após identificar os problemas, a equipe de projeto deve reprojetar a interface para
corrigir o maior número possível de problemas. Os problemas a serem corrigidos são
priorizados de acordo com a gravidade do problema e o custo associado à correção.
As avaliações analíticas dispensam a participação direta de usuários nas avaliações
e inspeções, que se baseiam em verificações e inspeções de versões intermediárias

130. ou acabadas de softwares interativos, feitos pelos projetistas ou por especialistas em
usabilidade.
Avaliação Heurística
Representam um julgamento de valor sobre as qualidades ergonômicas das
interfaces e são realizadas por especialistas em ergonomia, que
diagnosticam problemas que o usuário poderá ter em uma interação (CYBIS
et al, 1998).
Heurísticas, segundo Nielsen (2006):
De visibilidade do status do sistema: o sistema precisa manter o usuário
informado sobre o que está acontecendo, fornecendo-lhe um feedback dentro de
um tempo razoável;
De compatibilidade do sistema com o mundo real: O sistema deve falar a
linguagem do usuário, com palavras, frases e conceitos familiares a ele, em vez de
usar termos técnicos. Deve seguir convenções do mundo real, dando-lhe uma
informação numa ordem natural e lógica;
De controle e liberdade do usuário: os usuários escolhem, freqüentemente e
por engano, funções do sistema e precisam ter saídas de emergência claramente
marcadas, para abandonar a operação sem ter que percorrer um extenso diálogo,
possibilitando funções undo eredo;
De consistência e padrões: os usuários não precisam saber que diferentes
palavras, situações ou ações significam a mesma coisa. Devem seguir convenções
de plataforma computacional;
De prevenção de erro: é melhor projetar um design cuidadoso, no qual se
previne o erro antes dele acontecer, do que, uma boa mensagem de erro;
De reconhecimento em vez de lembrança: minimize o uso da memória do
usuário, disponibilizando objetos, ações e opções visíveis. O usuário, na passagem
de uma operação para outra não precisa lembrar-se da informação anterior.
Instruções para uso do sistema devem estar visíveis e facilmente recuperáveis,
sempre que oportuna;
De flexibilidade e eficiência de uso: aceleradores não vistos por usuários
novatos podem acelerar freqüentemente a interação de usuários especialistas, de
modo que o sistema possa suprir necessidades de usuários sem experiência e
experientes. Permitir a usuários experientes costurar ações, freqüentemente;
Do design estético e minimalista: diálogos não devem conter informação

131. irrelevante ou utilizada raramente. Toda unidade extra de informação, em um
diálogo, compete com as unidades pertinentes de informação, e diminui a
visibilidade relativa;
Para ajudar os usuários a reconhecer, diagnosticar erros e recuperar-se
deles: mensagens de erro devem ser expressas em linguagem clara (sem código)
indicando precisamente o problema e sugerindo uma solução;
Ajuda e documentação: embora seja melhor um sistema que possa ser usado
sem documentação, seria bom disponibilizar ajuda e documentação. Essas
informações devem ser fáceis de encontrar, focalizadas na tarefa do usuário, com
uma lista de passos concretos, e não muito extensas.
Para auxiliar as heurísticas, ainda é necessário verificar sobre a severidade
de um problema de usabilidade que consiste na combinação de três fatores
(NIELSEN, 2007):
• Frequência com que o problema acontece: se é comum ou raro?
• Impacto do problema: será fácil ou difícil de solução caso aconteça?
• Persistência do problema: o problema não é superado, ou, ele causa
aborrecimento constante?
Para medir a severidade de um problema, Nielsen (2007) sugere a seguinte
escala:
0 = eu não concordo que este seja um problema de usabilidade.
1 = problema cosmético de usabilidade: não é necessário consertar o problema, a
menos que haja tempo disponível no projeto.
2 = problema de usabilidade secundário (sem importância): o conserto deste
problema não deve ser prioritário.
3 = problema de usabilidade principal (importante): o conserto deste problema é
de bastante prioridade.
4 = problema catastrófico de usabilidade: é imperativo consertar este problema
antes que o produto seja liberado.
Inspeções Ergonômicas via Checklists
São vistorias com base em listas de itens de verificação, para diagnosticar
problemas de interface.
Essas listas são usadas pelos avaliadores como roteiro de princípios básicos,
desejáveis em uma interface, para identificar problemas, reduzir a
subjetividade e custos.

132. Como em uma lista já estão presentes conhecimentos ergonômicos, não se
faz necessária à aplicação destes questionários por especialistas em
usabilidade e ergonomia.
Presteza: verifique se o sistema informa e conduz o usuário durante a interação;
Agrupamento por localização: verifique se a distribuição espacial dos itens
traduz as relações entre as informações;
Agrupamento por formato: verifique os formatos dos itens como meio de
transmitir associações e diferenças;
Feedback: avalie a qualidade do feedback imediato às ações do usuário;
Legibilidade: verifique a legibilidade das informações apresentadas nas telas do
sistema;
Concisão: verifique o tamanho dos códigos e termos apresentados e introduzidos
no sistema;
Ações mínimas: verifique a extensão dos diálogos estabelecidos para a realização
dos objetivos do usuário;
Densidade informacional: avalie a densidade informacional das telas
apresentadas pelo sistema;
Ações explícitas: verifique se é o usuário quem comanda explicitamente as ações
do sistema;
Controle do usuário: avalie as possibilidades do usuário controlar o
encadeamento e a realização das ações;
Flexibilidade: verifique se o sistema permite personalizar as apresentações e os
diálogos;
Experiência do usuário: avalie se usuários com diferentes níveis de experiência
têm iguais possibilidades de obter sucesso em seus objetivos;
Proteção contra erros: verifique se o sistema oferece as oportunidades para o
usuário prevenir eventuais erros;
Mensagens de erro: avalie a qualidade das mensagens de erro enviadas aos
usuários em dificuldades;
Correção de erros: verifique as facilidades oferecidas para que o usuário possa
corrigir os erros cometidos;

133. Consistência: avalie se é mantida uma coerência no projeto de códigos, telas e
diálogos com o usuário;
Significados: avalie se os códigos e denominações são claros e significativos para
os usuários do sistema;
Compatibilidade: verifique a compatibilidade do sistema com as expectativas e
necessidades do usuário em sua tarefa.
Percurso Cognitivo
Tem o objetivo de identificar problemas de usabilidade, para avaliar a
facilidade de aprendizado do sistema através da exploração do usuário,
direcionando as tarefas apenas quando requeridas em seu trabalho.
Esse método examina principalmente (PRATES E BARBOSA, 2003):
• A correspondência entre a conceitualização de uma tarefa dos usuários e a
dos designers;
• Escolha adequada ou não-adequada de termos ou do vocabulário utilizado;
• Feedback adequado ou não, para os resultados de uma ação.
De acordo com Prates e Barbosa (2003), nessa avaliação é necessária, uma fase de
preparação para a definição de:
• Hipóteses sobre os usuários e sobre o conhecimento que eles têm sobre a tarefa e
a interface;
• Cenários de tarefas, construídos a partir de uma seleção de tarefas importantes e
freqüentes;
• Sequência correta de ações para completar cada tarefa, definida pelo projetista;
• Proposta de design em papel ou protótipo ilustrando cada passo e indicando o
estado da interface antes e depois de cada passo.
Para o procedimento de uma execução dessa avaliação são relacionados os seguintes
passos (PRATES E BARBOSA, 2003):
a) O projetista apresenta uma proposta de design;
b) Os avaliadores constroem histórias sobre a interação de um usuário com a
interface, com base nos cenários de tarefas selecionados;
c) Os avaliadores simulam a execução da tarefa, efetuando uma série de perguntas
sobre cada passo;

134. d) Os avaliadores anotam pontos-chave, sobre os quais o usuário:
• Precisa saber antes de realizar a tarefa;
• Deve aprender ao realizar a tarefa.
São necessárias perguntas básicas, feitas pelos avaliadores, em cada passo das
tarefas as quais orientam para identificar problemas que poderiam ocorrer no
processo de interação (PRATES E BARBOSA, 2003):
a) O usuário tentará atingir a meta correta?
• Dada a decomposição de tarefa em subtarefas, o usuário saberá por onde começar
e qual é o próximo passo?
• O que o usuário vai tentar fazer a cada momento?
b) O usuário perceberá que a ação correta está disponível?
• Onde está o elemento de interface correspondente ao próximo passo?
• Que ações a interface torna disponíveis?
c) O usuário associará o elemento de interface correto à meta a ser atingida?
• O elemento de interface revela seu propósito e comportamento?
• O usuário consegue identificar os elementos de interface?
d) Se a ação correta é tomada, o usuário perceberá que progrediu em direção
à solução da tarefa?
• Como a interface apresenta o resultado de cada ação?
• O resultado apresentado tem correspondência com o objetivo do usuário?
De acordo com as descrições das etapas do percurso cognitivo, seu conceito
baseia-se em um processo em que os usuários aprendem por tentativas e
sem treinamento, sendo de fácil uso e de baixo custo.
MÉTODOS DE AVALIAÇÃO EMPÍRICOS
As avaliações empíricas são métodos baseados em
experiências que se relacionam basicamente aos ensaios de interação e a
monitoramentos (sistemas espiões). Geralmente essa técnica envolve a participação
de usuários na coleta de dados, dados que são diagnosticados por especialistas, a
fim de identificar problemas de usabilidade e comunicabilidade. As próximas seções
relatam as principais avaliações empíricas.

135. Os ensaios de interação consistem em uma simulação de uso do sistema,
envolvendo os usuários, que tentam fazer suas tarefas típicas, com uma
versão do sistema pretendido (CYBIS, 2003).
Na visão de Cybis (2003), para se ter uma noção da complexidade de cada teste, é
necessário fazer uma análise das seguintes características dos ensaios de interação:
a) O constrangimento é inerente aos testes e, portanto, algumas medidas devem ser
seguidas:
 Esclarecer o usuário sobre o teste, enfatizando a finalidade do ensaio e da
sua participação;
 Não pressionar os usuários a participar dos ensaios;
 Não expor os usuários a comentários de colegas;
 Caso o participante se sinta cansado ou constrangido diante de uma
determinada situação, é preferível parar a realização do ensaio de uma forma
tranqüila;
 Os ensaios devem ser planejados cuidadosamente quanto à divulgação dos
resultados, evitando-se invadir a privacidade dos participantes, realizando-se
de preferência, uma coleta anônima.
b) Para uma melhor informação faz-se necessário que o usuário verbalize durante
ou após a interação com o software, onde se identifica:
 Verbalização simultânea: é realizada durante o ensaio de interação, no qual
o analista deve controlar a verbalização de acordo com o que o usuário está
pensando, tentando fazer ou, lendo ou de acordo com a maneira como o
trabalho está sendo apresentado;
 Verbalização consecutiva: é feita uma entrevista com o usuário no final do
ensaio de interação e, se necessário, pode-se repassar a gravação do vídeo
que registrou o teste.
c) O local do teste pode ser no ambiente usual da tarefa, ou em um laboratório:
 Teste no local: é mais trabalhoso, mas pode trazer informações mais ricas
por estar no seu ambiente com as variantes do dia-a-dia, como, por exemplo,
parar para atender um telefonema, suportar pressão de superiores, entre
outras;

136.  Teste em laboratório: deve ser equipado com recursos e aparelhos
sofisticados, que permitiam observar a interação humano-computador de
forma contínua, possibilitando ao analista maior controle da situação.
Para softwares na fase de concepção, este tipo pode ser mais viável, pois o
analista pode testar uma função, fazer correções e testar o sistema.
d) Registro e coleta de dados: é recomendado utilizar câmeras de vídeo para o
registro de tudo, sem filmar o rosto do usuário, realizando o ensaio da forma mais
conveniente para o usuário e em local e horário que lhe seja mais favorável.
Para a montagem de um ensaio de interação contam-se várias etapas, desde a
análise preliminar até a realização dos ensaios.
Neste contexto Cybis (2003) descreve as etapas como seguem:
a) Na etapa de análise preliminar os especialistas tomam conhecimento da
composição do software, realizando duas fases:
 Reconhecimento de software: faz-se uma entrevista com a equipe que
desenvolveu o software, abrangendo questões como a população-alvo
do software, o tipo de tarefa que o software visa atender, as funções principais
do produto, quantas pessoas foram envolvidas no desenvolvimento e se houver
ergonomistas, o tempo de desenvolvimento, o ambiente de programação do
sistema, as versões, a situação na área comercial e também sobre o suporte;
 Pré-diagnóstico: pode ser obtido através de uma técnica de avaliação do tipo
heurística ou checklists para inspeção ergonômica, de que resulta um conjunto
de hipóteses sobre problemas de usabilidade que serão testados nos ensaios
de interação.
b) Nesta fase são definidos os scripts, os cenários e a amostra de usuários, a saber:
 Reconhecimento do perfil do usuário: os projetistas selecionam as pessoas
(público-alvo), que poderão vir a participar dos ensaios;
 Coleta de informações sobre o usuário e sua tarefa: o analista deve
elaborar questionários destinados a buscar os dados de uma amostra de
usuários. Estes questionários devem conter os dados a respeito dos recursos
disponíveis, do contexto da tarefa, do nível dos usuários, da utilização do
sistema;
 Definição dos scripts de tarefas para os ensaios: um script nasce a partir
da combinação dos parâmetros levantados, como os objetivos principais
do software, as hipóteses dos ergonomistas, as amostras de tarefa dos
usuários, a funcionalidade do sistema considerada mais e menos importante
pelo usuário e, também, as operações mais frequentes do usuário.
c) Enfim, a realização dos ensaios deve durar no máximo 1 hora, com a participação
do usuário, de 1 ou 2 ergonomistas observadores e de 1 assistente técnico
responsável pelo funcionamento dos equipamentos. Os ensaios são controlados pelos

137. ergonomistas que devem planejar como proceder nos casos de interrupções,
retomadas e encerramento precoce do teste e, também, fazer anotações em tempo
real sobre o desempenho do usuário, erros e incidentes.Na sequência complementa-
se a caracterização desta etapa:
 Obtenção da amostra dos usuários: é necessário selecionar alguém da
amostra de usuários que realiza efetivamente as tarefas dosscripts, e que seja
experiente na tarefa, alguém que realmente exerça suas atividades com o
auxílio do software, separando novatos de experientes.
 Ajustes nos scripts e cenários: com cada participante deve ser realizada
uma nova entrevista para buscar informações visando os ajustes nos scripts e
cenários.
 Planejamento dos ensaios: envolve a tomada de decisão e a adoção de
providências relativas ao local dos ensaios, ao equipamento para registro dos
acontecimentos, à escolha das técnicas de verbalização e à definição das
estratégias de intervenção, em caso de impasse. Para lidar com as situações,
sugere-se deixar o usuário tentar resolver sozinho qualquer tarefa, nunca ser
grosseiro, propor ao usuário a realização de uma tarefa alternativa na
persistência do impasse, e, caso os usuários se encontrem constrangidos ou
nervosos, os ensaios devem ser interrompidos.
 Análise e interpretação dos dados obtidos: a equipe de analistas deve
rever todas as gravações buscando dados relevantes que comprovem ou não
as hipóteses estabelecidas. Os resultados são relatados e entregues aos
projetistas do sistema, com a descrição dos incidentes havidos durante a
interação, relacionando-os com um aspecto do software e, também, definindo
a prioridade dos problemas.
Conclui-se que a utilização da técnica de ensaios de interação, por utilizar a
participação direta do usuário, se mostra capaz de identificar problemas
específicos referentes à realização das tarefas que por outras técnicas não
se conseguem identificar.
Esta técnica pode utilizar uma série de outras técnicas, como entrevistas,
questionários, checklists, sistemas espiões que, em conjunto, caminham
para um diagnóstico final que busca a satisfação do usuário.
São softwares “espiões” que permanecem na máquina do usuário simultâneos ao
aplicativo em teste, os quais capturam e registram aspectos das interações do
usuário com seu aplicativo em sua própria realidade de trabalho. (Cybis, 2003).

138. Esta técnica não causa constrangimento ao usuário e ao mesmo tempo captura as
interferências causadas por sua realidade de trabalho.
Na parte negativa, constata-se que não há como incentivar ou registrar as
verbalizações dos usuários que apresentam limitações de ordem técnica,
relacionadas principalmente à portabilidade das ferramentas de espionagem.
Assim, um sistema de monitoramento pode auxiliar outras técnicas de avaliações,
contribuindo para um melhor resultado de uma avaliação.
É um conjunto de qualidades ergonômicas definidos por Bastien e Scapin (1993), e
são formados por oito divisões que representam as características mínimas que um
sistema interativo deve ter para apresentar um nível razoável de usabilidade.
Suas divisões (Bastien e Scapin , 1997):
Condução
A condução refere-se aos meios disponíveis para aconselhar, orientar,
informar e conduzir o usuário na interação com o computador, por exemplo:
mensagens, alarmes, rótulos, etc. São necessários quatro critérios:
a) Presteza: relaciona-se com as informações que permitem ao usuário identificar
o estado ou contexto no qual se encontra, bem como as ferramentas de ajuda e o
modo de acesso, incluindo-se os mecanismos ou meios que permitem ao usuário
conhecer as alternativas, no que se refere a ações. Esse critério engloba os meios
utilizados para levar o usuário a realizar determinadas ações, como, por exemplo,
entrada de dados, na qual, sua finalidade é facilitar a navegação do aplicativo e
diminuir a ocorrência de erros;
b) Agrupamento/distinção de itens: diz respeito à organização visual dos itens
de informação, relacionados uns com os outros, mostrando se esses itens pertencem
ou não a uma classe, ou se indicam as diferenças entre as classes. Considera-se a
topologia e algumas características gráficas que podem indicar as relações entre os
itens, dependendo, da compreensão do usuário, entre outras coisas, da ordenação,
do posicionamento, e da distinção dos objetos de uma interface. Esse critério está
subdividido em outros 2 critérios elementares:
 Agrupamento/distinção por localização: tem relação com o
posicionamento relativo dos itens, indicando as diferenças entre as classes, se
os itens pertencem ou não a uma determinada classe, e o posicionamento
relativo dos itens de uma classe;
 Agrupamento/distinção por formato: está relacionado com as
características gráficas como, formato e cor e indicam se os itens pertencem
ou não a uma classe as distinções entre classes diferentes e as distinções entre
itens de uma classe.

139. c) Feedback imediato: a qualidade e rapidez do feedback são fatores importantes
para a satisfação e confiança do usuário. Esse critério diz respeito às respostas do
sistema às ações do usuário. Essas entradas podem ir do simples pressionar de uma
tecla até uma lista de comandos. As respostas do computador devem ser fornecidas,
de forma rápida, com um tempo de resposta condizente e consistente;
d) Legibilidade: no que tange às características cognitivas e perceptivas dos
usuários, a legibilidade diz respeito aos aspectos lexicais das informações
apresentadas na tela, que possam dificultar ou facilitar a leitura desta
informação. Citam-se como exemplo: brilho do caractere, contraste entre letra e
fundo, tamanho da fonte, espaçamento entre palavras, espaçamento entre linhas,
espaçamento de parágrafos, comprimento da linha, entre outros.
Carga de Trabalho
A carga de trabalho diz respeito a todos elementos da interface que têm um
papel importante na redução da carga cognitiva e perceptiva do usuário e
no aumento da eficiência do diálogo, e comporta:
a) Brevidade: corresponde ao objetivo de limitar a carga de trabalho de leitura e
entradas e o número de passos, com base na carga de trabalho perceptiva e
cognitiva, para as entradas e saídas ou para os conjuntos de entradas. Esse critério
supõe duas qualidades:
 Concisão: diz respeito à carga perceptiva e cognitiva de saídas e entradas
individuais, e por definição não se refere às mensagens de erro e feedback;
 Ações mínimas: procura-se limitar o número de passos pelos quais o usuário
deve passar para a realização de uma tarefa, tentando diminuir a carga de
trabalho e a probabilidade de ocorrência de erros.
b) Densidade informacional: essa qualidade relaciona-se com a carga de trabalho
do usuário, de um ponto de vista perceptivo e cognitivo, com relação ao conjunto
total de itens de informação apresentados aos usuários, e não ao item individual,
objetivando minimizar a carga de memorização.
Controle Explícito
O controle explícito refere-se tanto ao processamento das ações do usuário
pelo sistema, quanto ao controle que os usuários têm do processamento de
suas ações pelo sistema, e subdivide-se em dois critérios:
a) Ações explícitas do usuário: referem-se às relações entre o que se processa
pelo computador e as ações do usuário, devendo, o computador processar somente
aquelas ações solicitadas pelo usuário e somente quando solicitado a fazê-lo. Dessa
forma, o usuário aprende e entende melhor o funcionamento da aplicação, ficando
menos sujeito a erros;
b) Controle do usuário: os usários devem estar sempre no controle do sistema, ou
seja, eles podem interromper, cancelar, suspender e continuar uma determinada

140. ação. E cada ação possível do usuário deve ser antecipada, e disponibilizadas opções
apropriadas. Assim, o computador se torna mais previsível.
Adaptabilidade
A adaptabilidade de um sistema diz respeito a sua capacidade de reagir
conforme o contexto e conforme as necessidades e preferências do usuário.
Dois subcritérios constam na adaptabilidade:
a) Flexibilidade: corresponde aos meios colocados à disposição do usuário que
permitem personalizar a interface levando-se em conta as exigências da tarefa, de
suas estratégias ou seus hábitos de trabalho com vistas a possibilitar ao usuário
várias maneiras para alcançar seu objetivo;
b) Consideração da experiência do usuário: a interface deve ser concebida para
lidar com as variações dos níveis de experiência, de novatos a experientes. Através
dos meios implementados, as opções possíveis do sistema devem ser mostradas de
maneiras diferentes, de acordo com o tipo de usuário.
Gestão de Erros
A gestão de erros compreende todos os mecanismos que permitem evitar ou
reduzir a ocorrência de erros e, quando eles ocorrem, favorecer sua
correção.
Os erros são aqui considerados como entradas de dados incorretos, entradas
com formatos inadequados, entradas de comandos com sintaxes incorretas
etc. Três subcritérios participam da manutenção dos erros:
a) Proteção contra os erros: refere-se aos mecanismos empregados para detectar
e prevenir os erros de entradas de dados ou comandos, ou possíveis ações de
consequências desastrosas e/ou não sanáveis;
b) Qualidade das mensagens de erros: fundamenta-se na pertinência,
legibilidade e exatidão da informação dada ao usuário sobre a natureza do erro
cometido e sobre as ações que se devem executar para corrigi-lo. Este critério
favorece o aprendizado do sistema indicando ao usuário a razão ou a natureza do
erro cometido, o que ele fez de errado, o que ele deveria ter feito e o que ele deve
fazer;
c) Correção dos erros: diz respeito aos meios colocados à disposição do usuário
com o objetivo de permitir a correção de seus erros para tornar mais ágil essa
correção.
Consistência
O critério da consistência, também chamado de homogeneidade ou
coerência, refere-se à forma pela qual as escolhas, na concepção da
interface, são conservadas idênticas em contextos idênticos, e diferentes em
contextos diferentes.
Essas escolhas podem ser códigos, denominações, formatos, procedimentos
etc.
Significado dos Códigos e Denominações

141. O significado dos códigos e denominações diz respeito à adequação entre o
objeto ou a informação apresentada ou pedida e sua referência.
Códigos e denominações significativas possuem uma forte relação semântica com
seu referente.
Termos pouco expressivos para o usuário podem ocasionar problemas de
condução podendo ele ser levado a fazer uma opção errada.
Compatibilidade
A compatibilidade refere-se ao acordo que possa existir entre as
características do usuário, como: memória, percepção, hábitos,
competências, idade, expectativas etc.
As tarefas por um lado, e por outro a organização das saídas, das entradas
e do diálogo de uma dada aplicação. Diz respeito também ao grau de
similaridade entre diferentes ambientes e aplicações.
Vamos à nossa Vídeo Aula 05
O Plugin Silverlight está desabilitado ou não foi instalado em seu browser, faça o download
clicando aqui ou ative o mesmo.
Então, visualizaram o caminho para a construção de uma interface
amigável, a partir dos critérios de avaliação?
Participem do fórum!
QUANTO À ESCOLHA DAS TÉCNICAS!
Nas seções anteriores expressaram-se questões
essenciais sobre as técnicas de avaliações de IHC, mas não se pode esquecer que o
sucesso de uma avaliação depende, e muito, da escolha correta da técnica utilizada
no contexto a ser avaliado.
Para a determinação de uma técnica de avaliação, faz-se necessário o entendimento
do objetivo particular de um ambiente a ser avaliado, considerando-se os recursos
disponíveis e as expectativas dos resultados da avaliação.

142. Em Cybis (2003), são relatadas algumas características importantes para a
escolha de uma avaliação:
a) Efetividade: refere-se à quantidade de problemas sérios identificados - técnicas
indicadas: avaliação heurística e ensaios de interação;
b) Abrangência: refere-se à quantidade de problemas reais de todos os tipos
identificados – técnicas indicadas: inspeções por checklist e avaliação heurística;
c) Eficiência: é a razão da quantidade de problemas sérios identificados em, face da
quantidade de problemas reais identificados de todos os tipos – técnica indicada:
ensaios de interação;
d) Produtividade: refere-se à razão entre a quantidade de problemas reais de todos
os tipos identificados e a quantidade de recursos financeiros necessários;
e) Sistematização: para esta qualidade concorrem dois fatores igualmente
importantes: repetitividade e reproduzibilidade. Arepetitividade relaciona-se à
medida pela qual os resultados produzidos pela técnica se repetem, quando o mesmo
avaliador examina o mesmo software algum tempo depois da primeira avaliação.
A reproduzibilidade está relacionada com a medida pela qual dois avaliadores
diferentes, examinando um mesmo software, produzem os mesmos resultados –
técnica indicada: inspeções por checklist;
f) Facilidade de aplicação: refere-se à qualidade da técnica que não exige formação
ou competências específicas para a realização da tarefa - técnica indicada: inspeções
por checklist;
g) Poder de persuasão: refere-se a qualidade da técnica de produzir resultados
capazes de convencer os projetistas da gravidade dos problemas de usabilidade
identificados – técnicas indicadas: ensaios de interação e avaliações heurísticas;
h) Poder de desobstrução: refere-se à qualidade da técnica produzir indicações de
melhorias na usabilidade dos sistemas.
Para aprofundar seu conhecimento... Conheça o que diferentes autores
destacam em relação ao campo de IHC...
http://www.lits.dei.uminho.pt/tu.pdf
http://irlabr.wordpress.com/apostila-de-ihc/parte-1-ihc-na-pratica/6-usabilidade-e-
suas-metas/
Parabéns, você chegou ao fim de mais uma etapa do nosso estudo!
Nosso estudo continua no fórum de discussão...

143. WEBAULA 1
Unidade 1 – Introdução ao Design de Interfaces
O QUE É INTERFACE?
A wikipedia (goo.gl/Y66zU) diz que interface é todo e qualquer dispositivo que ofereça
interação entre dois sistemas diferentes. Ainda está
complicado, né? Vamos exemplificar: Um painel de um
carro, é uma interface.
O controle remoto é uma interface.
A tela do seu celular touchscreen é uma interface. E um site também é uma interface.
O QUE DEFINE UM BOM DESIGN?
Existem vários critérios para o desenvolvimento de design. Um dos mais básicos diz
que a forma deve seguir a função. Esse conceito vem sendo utilizado e discutido
desde a Bauhaus (1919 a 1933), e prega que se um objeto tem uma determinada
função, sua forma deve favorecer o seu uso.
Compliquei de novo?

144. Imagine uma cafeteira italiana, bico de um lado e alça do outro. Agora imagine se os
dois fossem do mesmo lado. Essa forma iria atrapalhar muito a sua função, e você,
provavelmente, se queimaria tentando usá-la.
Dessa forma, entendemos que cada elemento de um layout deve ter uma função
específica, para que não ocorram confusões na utilização da interface.
Mas o melhor de tudo é ver quem entende do assunto falando...
Aqui, você pode acompanhar Alexandre Wollner(pioneiro do design do Brasil) falando
sobre o que é design.
http://youtu.be/4RHf2jV3RPk
Nesse link, você verá o Luli Radfahrer falando um pouco sobre design.
Vale muito a pena cada segundo!
http://vimeo.com/56205628
E O DESIGN DE INTERFACES?
Primeiro devemos saber que ele é focado no usuário e não no sistema.
Seu objetivo é tornar a tarefa a ser realizada pelo usuário o mais simples e eficiente
possível.
O design de interfaces deve equilibrar a funcionalidade e elementos visuais de modo
a facilitar a tarefa do usuário sem chamar a atenção para si.
Eu acredito que o design não precisa necessariamente chamar a atenção.
Ele é apenas um meio, um condutor para a mensagem. Esta sim deve ser clara e
perfeitamente compreensível. Vendo desta forma:
Você encontra mais sobre design de interfaces:
http://pt.wikipedia.org/wiki/Design_de_interface_de_usuário

145. http://www.uxdesign.blog.br/design-de-interfaces/
Sendo assim, o designer de interfaces deve sempre conhecer o perfil do usuário que
utilizará o seu projeto.


Design de Interfaces – 1
APRESENTAÇÃO DO PROFESSOR:
Sou designer gráfico (UNOPAR, 2007), Especialista em Gestão do Design (UEL,
2009), sócio proprietário na Vallent Design (www.vallent.com.br) e docente no curso
de Desenho Industrial (Programação Visual e Projeto de Produto) e Design de
Interiores da UNOPAR, tendo ministrado as disciplinas: Ergonomia Visual; Interface
e Usabilidade; Tipografia; Empreendedorismo e Negócios; Composição gráfica;
Estudo e representação da Cor; Tópicos Especiais em Design I; Estágio
supervisionado; Gestão do Design aplicada a Projetos. Tenho 12 anos de experiência
no desenvolvimento e gerenciamento de projetos de design, utilizo meus
conhecimentos para auxiliar as empresas a atingirem suas metas estratégicas e
financeiras implementando o design e a inovação em suas ações.
RESUMO DA UNIDADE:

146. O objetivo desta unidade é apresentar noções básicas referentes à design de
interfaces. Desta forma, trataremos de assuntos relacionados com o tema, como
Interfaces, Cores, Tipografia, Gestalt, Composição Visual e Ergonomia.
Ao final deste módulo se terá conhecimento de técnicas e conceitos visuais capazes
de ajudar no desenvolvimento gráfico de interfaces.
PESQUISAS COM USUÁRIOS
Sempre que vamos desenvolver um projeto de design, precisamos
saber que vai utilizá-lo. Para isso servem as pesquisas.
É sempre importante saber sobre a cultura, o nível de escolaridade, os interesses e
as aptidões dos usuários. E o melhor jeito é realizando testes.
Por exemplo: quando uma empresa vai lançar um novo software, ela primeiro libera
uma versão beta para alguns usuários selecionados (beta testers) que darão
um feedback para que ela melhore o software antes de lançar a sua versão final.
Este processo pode se repedir diversas vezes, até que o resultado esteja satisfatório,
e o trabalho pode durar meses.
O usuário deve ter a perfeita noção do que está fazendo, pois em muitos casos, um
erro pode acarretar em problemas graves e grande prejuízos.
VÍDEO AULA 1
O Plugin Silverlight está desabilitado ou não foi instalado em seu browser, faça o download
clicando aqui ou ative o mesmo.
Você encontra um pouco mais sobre design centrado no usuário em:
http://goo.gl/0eJY4
FATORES ERGONÔMICOS BÁSICOS
João Gomes Filho (2003a) nos ensina que essas pesquisas devem levar alguns itens
em consideração.
REQUISITOS DO PROJETO:
Tarefa: O que o usuário terá que realizar para
fazer o sistema funcionar, por exemplo: “mover
o mouse e digitar comandos em um teclado”;
ou “puxar ou empurrar alavancas em
sequencias predeterminadas”; ou ainda
“movimentar-se em frente a um receptor” que

147. interprete seus movimentos e os transforme em
resultados gráficos.
Segurança: Utilização segura e confiável dos
objetos em relação à sua função. Sua
importância varia de projeto para projeto,
chegando a ser insignificante em alguns casos.
Conforto: É na verdade uma condição, mas
também pode ser vista como a sensação de
comodidade, bem-estar e segurança. Esse fator
está muito ligado ao de segurança, mas
também, e principalmente, a fatores pessoais,
como condições físicas, psicológicas,
experiência de vida e condições gerais do
usuário.
Estereótipo popular: Práticas de uso
consagradas e comuns, como a direção da
leitura ocidental, ou girar um botão de volume
no sentido horário para aumentar o som. Esse
fator também influencia diretamente o conforto
e a confiança nos resultados das ações
realizadas pelo usuário. Este fator é bastante
subjetivo, pois pode variar de acordo com o
grupo social do indivíduo. Por exemplo: No
Japão a leitura é da direita para a esquerda, e
na Inglaterra, o motorista fica do lado direito do
veículo.
Para que lado você giraria essa torneira?
Envoltórios de alcance físico: É o volume
espacial de objetos que devem estar ao alcance
do usuário para o manejo do sistema. Por
exemplo, para manusear um computador, ele
utilizará um mouse, um teclado, um monitor...
Todos esses objetos devem estar organizados
de modo que o usuário não precise realizar
movimentos que gastem uma energia
desnecessária, ou gere fadiga. Em interfaces,
isso é fundamental, pois a disposição dos

148. elementos determinará a movimentação do
usuário sempre que utilizá-la.
Postura: Posição do corpo do usuário no
momento da utilização. Uma postura incorreta
pode gerar fadiga, lesões e problemas de
articulação. Se houver algo possível para
melhorar a postura do usuário, devemos
sempre considerar!
Aplicação de força: Depende do manejo e do
controle dos objetos.
AÇÕES DE MANEJO:
Manuseio operacional: É o ato de utilização do objeto.
O ato de pegar, empurrar, puxar, torcer, esfregar e etc.
Para manter, ou fazer cessar o funcionamento de algo.
Normalmente relacionado à pega, empunhadura...
Não está muito relacionado ao design de interfaces
digitais, mas deve-se levar em consideração a utilização
dos periféricos dos computadores (mouse, teclado e
trackpad, em laptops) e de dispositivos móveis, como
smartphones e tablets.
Manutenção: Para objetos físicos, é necessário pensar na
facilidade de desmontagem e acesso às peças internas do
objeto. Já para interfaces digitais, podemos considerar a
plataforma de desenvolvimento, o código-fonte e a facilidade
de reparos nesses códigos, ou na modularidade dos layouts.

149. Arranjo espacial: Melhor distribuição dos elementos
dentro do espaço disponível, de modo a facilitar a
atividade do utilizador.
Um bom arranjo espacial pode facilitar o trabalho do
usuário, diminuindo o seu cansaço e aumentando a sua
produtividade.
Imagem retirada de wix.com. Layout de website modular
que é utilizado como base para desenvolvimento de sites
personalizados
AÇÕES DE PERCEPÇÃO:
VISUAL: A visão é o sentido mais usado na interação com interfaces digitais. Sendo
assim, precisamos tomar muito cuidado com dois fatores:
 Acuidade: É a capacidade de perceber os detalhes.
Pode ser bastante subjetiva, pois depende de fatores
referentes ao usuário, mas também existem cuidados
que podemos tomar durante o desenvolvimento de
projetos: As cores podem influenciar esta capacidade,
a iluminação também, assim como o contraste entre
figuras e fundos, e nos textos utilizados no layout.
 Legibilidade: Está ligada a como reconhecemos
informações que recebemos através de comparação
com o que já temos na memória. Resumindo, quanto
mais comum e bem organizada estiver a imagem
utilizada, mais legível ela será. E quanto mais incomum
e desorganizada (tamanho, cor, contraste...) ela estive,
menos legível será!
AUDITIVO: Os sinais auditivos reforçam (ou até substituem)
alguns sinais visuais. Por exemplo, o som se uma mensagem que chegou, ou foi
enviada com êxito. O cumprimento de uma tarefa com sucesso, ou um alerta para
uma correção.

150. Por favor, não coloque áudio em tudo o que acontece na interface, a não ser
que seja absolutamente necessário (para cegos, por exemplo), pois esta
pode acabar ficando muito chata para o usuário!
TÁTIL: É o contato direto com o tato, que é o sentido que
percebe contato, pressão, calor e dor. Você pode pensar nisso
se a sua interface utiliza uma tela sensível ao toque, ou à
pressão. Em dispositivos móveis, um sistema que consuma
muita energia, fará o seu processador aquecer, e isso será
percebido pelo usuário.
CINESTÉSICO: Cinestesia é o sentido de percepção dos
movimentos musculares ao longo do corpo. Utilizamos
esse sentido para executar tarefas sem um controle
visual, como, por exemplo, tocar um piano olhando a
partitura, digitar sem olhar o teclado, ou dirigir sem ter
que olhar os pedais do carro para frear ou acelerar.
Se a sua interface precisar da utilização de pedais, ou
de algo que necessite o movimento de partes diferentes
do corpo, esta é uma preocupação que se deve tomar.
Mais sobre ERGONOMIA:
http://pt.wikipedia.org/wiki/Ergonomia
http://www.abergo.org.br/
http://abcdesign.com.br/por-assunto/artigos/design-e-
ergonomia/
CÓDIGOS VISUAIS
Cromático: Com disse João Gomes Filho (2003b) “A cor é a parte simples mais
emotiva do processo visual”. Seu uso é de extrema importância para reforçar a
mensagem que se deseja transmitir.
Agora a coisa começa a ficar importante!
Aqui vão dicas que serão fundamentais para qualquer composição que você
venha a fazer no futuro:
COMBINE AS CORES: As cores não são escolhidas aleatoriamente
para compor um layout, normalmente elas seguem um padrão.
Podem ser compostas, análogas, complementares, tríade e de muitas outras formas.
O importante, é que isso seja feito corretamente.

151. Para sua sorte, a Adobe já pensou nisso e colocou GRÁTIS na internet, o
KULER https://kuler.adobe.com/
Lá você escolhe o tipo de combinação que deseja fazer, realiza os ajustes que achar
necessários e ele te dá uma palheta com 5 cores diferentes, mas harmônicas entre
si para que você possa utilizar em seu trabalho.
O VERMELHO CHEGA PRIMEIRO: As corres que enxergamos são
ondas com frequências diferentes para cada uma. E a amplitude de onda da cor
vermelha é a maior de todas, por isso ela chega primeiro aos nossos olhos.
Veja: uma imagem com o fundo vermelho e a figura azul causa estranheza aos olhos,
pois percebemos que o azul está acima do vermelho, mas este chega antes aos seus
olhos.
CORES QUENTES E FRIAS
As cores quentes, amarelo, laranja e vermelho, têm amplitude de onda
maior do que as cores frias, azuis e verdes.
Por isso sempre chegam primeiro aos nossos olhos.
Sabendo disso, utilizamos as cores quentes para elementos visuais que precisam de
destaque, como um aviso, ou algo do tipo.
Já as cores frias, são melhores para fundos e informações secundárias.
COR LUZ e COR PIGMENTO
Existem dois tipos de cores: Cor luz (emitida) e cor pigmento (refletida)
Nos monitores, o as cores que vemos é a luz emitida, e nos objetos ao nosso redor,
as cores são luz refletida. Isso significa, que se um objeto é verde, ele reflete o
espectro verde da luz que recebe, absorvendo os outros.
Já em um monitor, a luz é emitida e forma as cores de acordo com a combinação de
outras. Se somarmos todas as cores em forma de luz, o resultado será a cor branca
(lembre-se! Quanto mais luz, mais claro!).

152. Se misturarmos as tintas, a tendência é chegar ao preto (quanto mais pigmento,
mais escuro).
Vídeo bem didático sobre cores.
http://youtu.be/Zeo5ZXlUtTg
SIGNIFICADO DAS CORES
As cores possuem muitos significados, e muitas vezes nos fazem tomar decisões. Por
isso, podemos utilizá-las de acordo com as sensações que pretendemos transmitir!
Veja que interessante:
PRATA: Luar, alquimia, poderes espirituais,
mistério. Intelecto harmonia e
autoconhecimento (espelhos). Depende de
textura para diferenciar-se do cinza.
DOURADO: Tradicional cor do dinheiro e
uma das cores do Sol. Segurança e
abundância. Faz as pessoas se sentirem
relaxadas.
VERMELHO: Paixão, perigo, raiva, amor,
sexo, poder. Sentimentos fortes.
VERDE: Natureza, sorte, renovação, novos
começos (mudas, plantas), oxigênio,
dinheiro, prosperidade, cura, emprego,
fertilidade, sucesso, saúde, harmonia.
AZUL: Calma, frialdade, serenidade (A
Virgem Maria), Introspecção, sabedoria,
solidão, espaço, verdade, beleza, cálculo,
frigidez.
TURQUESA: Misticismo, exaltação,
generosidade, riquezas e expansividade.
Está para o Prata assim como púrpura para o
dourado.

153. MARROM: Dominado pelo vermelho, mas
complementa o azul e o verde. Terra,
madeira, solidez, estabilidade, calor.
VÍDEO AULA 2
O Plugin Silverlight está desabilitado ou não foi instalado em seu browser, faça o
download clicandoaqui ou ative o mesmo.
CÓDIGO VISUAL TIPOGRÁFICO
Quando falamos em tipografia, penso que poderíamos ter uma web aula só sobre
isso, pois o tema é extenso. Vou colocar algumas das dicas mais importantes para
vocês:
Quando Gutemberg começou a comercializar os tipos móveis (por volta do ano de
1500), as letras eram feitas de metal, de forma a se encaixarem umas nas outras
formando as palavras. Este sistema foi utilizado por muitos anos (até o século XIX).
Com o advento dos computadores, fez-se necessário o desenvolvimento de tipos
digitais. Estes tipos foram desenvolvidos para uso em tela, e seu desenho é modular
para facilitar a exposição nos pixels.
Para textos impressos mais longos, o ideal é utilizar fontes com serifa, como
Garamond, ou Times.
A serifa ajuda na fluidez da leitura de textos longos, e diminui o cansaço na vista
humana.
Para o desenvolvimento de interfaces digitais, dê preferencia a fontes desenvolvidas
para tela, normalmente sem serifas e com desenho mais moderno. Com isso a leitura
será mais fácil e os usuários entenderão mais rapidamente o que precisam fazer.
Alguns exemplos de fontes boas para tela:

154. Baixar fontes grátis:
http://www.dafont.com/
http://fontfabric.com/
http://www.searchfreefonts.com/
http://www.actionfonts.com/
http://www.google.com/webfonts
Não utilize textos em caixa alta (maiúsculas) para textos corridos. Este
formato é indicado apenas para títulos e destaques específicos.
Procure utilizar apenas uma família tipográfica em cada projeto. Isso trará
mais unidade visual e melhorará a imagem geral de sua apresentação.
http://fontstruct.com/
Para finalizar esta parte, vale a pena dar uma conferida no FONTSTRUCT.

155. Um software online para criação de fontes.
É necessário um pouco de conhecimento em tipografia, mas com ele você pode
desenvolver a sua própria fonte digital!
Código Visual Morfológico
Os códigos visuais morfológicos dizem respeito à organização visual geral do layout.
Vamos estudar melhor sobre isso mais adiante, quando falarmos de Gestalt.
ERGONOMIA DE INTERFACES
Assim como o design, a Ergonomia de Interfaces é uma ciência multidisciplinar, ou
seja, se vale do conhecimento e dos métodos de diversas áreas para realizar as suas
tarefas.
Seu principal objetivo é a adaptação das condições de trabalho das interfaces às
características físicas e psicológicas do homem, deixando as interfaces cada vez mais
amigáveis às necessidades das pessoas, para que haja uma interação eficiente, com
segurança, conforto e eficácia.
Ela verifica se o software atende às necessidades operacionais e funcionais para saber
se o mesmo é adequado à tarefa a que se propõe.
Para isso, precisamos primeiro entender a diferença entre os termos Utilidade e
Usabilidade.
VÍDEO: O ESTUDO DA ERGONOMIA
http://youtu.be/w0ybfmCmnXw
“Se facilidade de uso fosse o único requisito, estaríamos todos
usando triciclos.”
Douglas Engelbart, inventor do mouse

156. Nesta afirmação Engelbart nos mostra que usabilidade é a facilidade de uso, e
utilidade é para que o objeto se destina.
Então, podemos entender que quanto mais fácil de usar uma interface, melhor.
Porém, um usuário mais experiente já não precisará mais de todos os “apoios” e esta
interface pode acabar se tornando chata para ele.
Neste caso, o melhor a se fazer é pensar em como otimizar o processo para estes
usuários mais experientes.
Existem técnicas específicas de avaliação de interfaces, que vocês verão no próximo
modulo do curso, com o Professor Everson. Por enquanto ficaremos apenas com a
concepção visual, OK?
FALANDO MAIS ESPECIFICAMENTE SOBRE COGNIÇÃO
Cognição é a aquisição de conhecimento através da percepção. Envolve atenção,
memoria, raciocínio, juízo, imaginação, pensamento e linguagem.
Mas não adianta tentar falar sobre cognição sem falar de Gestalt.
O termo vem da palavra alemã Gestaltung, que significa o ato de configurar o que
é exposto ao olhar.
Esta teoria estuda a forma como se dá a percepção visual humana, que é exatamente
o que nos interessa quando vamos desenvolver uma interface interativa.
Segundo a Gestalt, nós percebemos primeiro o todo, depois as partes de um objeto
observado.
Explicando mais claramente, quando olhamos para algum objeto complexo (um
carro, por exemplo) primeiro percebemos o todo (É um carro!), depois as partes. Aí
identificamos a marca, o modelo, o tamanho, quantas portas, a cor, as rodas, os
faróis e assim por diante, até o menor detalhe, dependendo do tempo e da atenção
que vamos dispensar a este objeto.

157. Este é o ponto em que o designer de interfaces deve ter certeza do que se está
fazendo, pois poderá direcionar a atenção do seu usuário (observador) para onde
desejar, sem precisar usar artifícios simplórios, como simplesmente aumentar o
tamanho de uma letra ou de uma figura.
A Gestalt também é conhecida como psicologia da forma, e, para fins didáticos, foi
dividida em algumas categorias, mas é importante lembrar que várias categorias da
Gestalt podem estar presentes em cada objeto.
Vejamos a seguir algumas das principais categorias da Gestalt.
TEORIA GERAL DA GESTALT - Afirma que percebemos as coisas dentro de um
conjunto de relações (o todo). Isso pode até alterar a nossa percepção da realidade,
com fenômenos de ilusão de ótica, por exemplo. (Os mágicos sabem disso como
ninguém!)
UNIDADE - Um, ou mais de um elemento que constitui um objeto.
Podem ser agrupamentos de elementos que são percebidos em
conjunto ou parte de um todo maior. São percebidos através das
relações entre os elementos que fazem parte de sua constituição.
SEGREGAÇÃO - É a percepção de formação de unidades por
contrastes no campo visual ou na configuração o objeto. Estes
contrastes podem ser de Cores, Brilhos, Matizes, formas, movimento
e etc.
UNIFICAÇÃO – Diferente de unidade, a unificação é fundamentada
nos conceitos de Harmonia, Ordem e Equilíbrio Visual. A coerência
entre os elementos e sua linguagem, além de outros fatores como
proximidade e semelhança, geralmente ajudam a promover e reforçar
a unificação da figura.
FECHAMENTO – Através de nossa memoria visual, as imagens
tendem a seguir uma linha que se espera, o caminho natural, formando
as figuras que desejamos observar. Mesmo que a linha não exista
fisicamente, ela existirá na nossa mente na hora de formar a imagem.
CONTINUAÇÃO – É a organização das imagens, de modo a
acompanharem um movimento pré-estabelecido, formando um
“caminho visual” pelo qual é agradável deixar correr os olhos.
PROXIMIDADE – Elementos próximos entre si tendem a ser
percebidos juntos, e desse modo, acabam formando unidades.

158. SEMELHANÇA – Assim como a proximidade, a semelhança
também tende a formar unidades. Dois pares de objetos iguais formam
duas unidades.
PREGNÂNCIA DA FORMA – Quanto melhor for a organização
visual de uma forma, e mais rápida e fácil for a sua leitura e
entendimento, maior será o índice de pregnância.
VÍDEO AULA 3
O Plugin Silverlight está desabilitado ou não foi instalado em seu browser, faça o download
clicando aqui ou ative o mesmo.
GOMES FILHO, João. Ergonomia do Objeto: sistema técnico de Leitura ergonômica.
São Paulo: Escrituras, 2003a.
GOMES FILHO, João. Gestalt do Objeto: Sistema de Leitura Visual da Forma. São
Paulo: Escrituras, 2003b.
BIBLIOGRAFIA CONSULTADA
BONSIEPE, Gui. Design: do material ao digital. Tradução de Cláudio Dutra.
Florianópolis: FIESC/IEL, 1997.
CYBIS, Walter. BETIOL, Adriana Holtz; FAUST, Richard. Ergonomia e usabilidade:
conhecimentos, métodos e aplicações. 2. ed. São Paulo: Novatec, 2010.
FRASER, Tom; BANKS, Adam. O guia completo da cor. Tradução de Renata Bottini.
São Paulo: Senac, 2007.
JOHNSON, Steven. Cultura da Interface: como o computador transforma nossa
maneira de criar e comunicar. Tradução de Maria Luísa X. de A. Borges. Rio de
Janeiro; Jorge Zahar, 2001.
NIEMEYER, Lucy. Tipografia: uma apresentação. 3. ed. Rio de Janeiro: 2AB, 2003.

159. Design de Interfaces - 2
WEBAULA 1
Unidade 2 – Design de Interfaces
INTRODUÇÃO
Quando o projeto de software tem o perfil de
seus usuários definidos e limitados, é possível aplicar a ergonomia com foco nas
necessidades específicas desse público alvo. Por exemplo em um software para
clínicas odontológicas, os conceitos de ergonomia podem ser aplicados diretamente
ao segmento clínico, criando interfaces e diálogos específicos.
E quando for necessário criar projetos de software onde os usuários finais possuem
os mais diversos perfis?
Como por exemplo software para caixa eletrônico de banco.
Como aplicar os conceitos de ergonomia em projetos de softwares desse nível?
Apesar do esforço empreendido por muitos pesquisadores, é difícil encontrar um
direcionamento global que atenda diretamente todas as expectativas ou objetivos de
um designer ao construir uma interface.
Por isso, além do conhecimento das técnicas de interação, é necessário um
conhecimento aprofundado do campo de atuação do software que será criado, como
também, de seu público alvo.
TEORIA DAS FORMAS
Cada vez mais elementos gráficos e visuais fazem parte dos softwares, com o
objetivo de aumentar suas vendas e a produtividade de quem o utiliza.

160. Todo o trabalho está relacionado ao equilíbrio das formas, a sua harmonia, a
transparência e a segurança que os objetivos transmitem ao usuário.
O computador e sua interface representam uma ferramenta cognitiva, uma extensão da memória,
uma prótese cognitiva que permite tratar melhor a informação. É importante que se conheça como os
processos cognitivos humanos se desenvolvem para a concepção de próteses cognitivas compatíveis
com eles (CYBIS, 2003, p. 3).
Tomando como exemplo, as telas de inicialização das diversas versões do Windows,
que tiveram várias evoluções na riqueza das formas, cores e equilíbrio.

161. Um dos papéis do projetista de software é criar projetos no sentido de satisfazer as
necessidades dos seus usuários em relação harmonia visual.
Segundo Bonsiepe (1997, p. 59), a interface tem a função de “permitir ao usuário
obter uma visão panorâmica do conteúdo, navegar na massa de dados sem perder a
orientação, e por fim, mover-se no espaço informacional de acordo com seus
interesses”.
A teoria das formas é um assunto que deve ser considerado e explorado amplamente
pelos projetistas em seus projetos, pois seu objetivo é sempre aumentar a
usabilidade e a aplicabilidade do software para seu usuário.
FORMA
Forma, é tudo aquilo que compõe um objeto e que se torna um símbolo
representativo.
Figura 9 – Forma
FORMAS SIMÉTRICAS E ASSIMÉTRICAS
Formas simétricas são formas equilibradas, ou seja, se fizermos um corte ao meio
da forma, as partes são como um espelho, uma parte refletindo exatamente a outra
parte.
Formas assimétricas são formas que não possuem um centro definido no espaço, e
são formas mais próximas da realidade.
Figura 10 – Forma simétrica Figura 11 – Forma assimétrica

162. SINAIS E SÍMBOLOS
Uma imagem pode dizer mais do que mil palavras e por isso os sinais e símbolos são
utilizados desde as formas mais primitivas de comunicação.
Ao utilizar sinais e símbolos no desenvolvimento de software, procure observar se o
que está sendo utilizado transmite a mensagem com clareza ao usuário, por exemplo:
Sem dúvida a imagem da tesoura indica melhor o sentido a função recortar do que a
outra imagem.
PERCEPÇÃO
Percepção, são as nossas sensações, experiências e conceitos sobre algo, e como
utilizamos tudo isso de forma integrada para lidarmos com o mundo.
Perceber não é a assimilação de um componente figural, mas sim a assimilação da
figura e o contexto com seus diversos componentes. Koffka (1975, p. 186),
abordando a questão da significação explora o assunto da parte e do todo, dando
uma visão mais clara desta teoria quando afirma que:
[...] o problema da significação está intimamente vinculado ao problema da relação entre o todo e
suas partes. Já foi dito: o todo é mais do que a soma de suas partes. Seria mais correto dizer que o
todo é alguma outra coisa que a soma de suas partes, porque somar é um procedimento vazio de
significado, enquanto que a relação todo-parte é significativa.
Figura 13 – Taça ou rosto humano?
Penna (1966) relata a importância do trabalho do psicólogo Edgard Rubin. Rubin diz
respeito aos critérios dos componentes e caracterização do campo da percepção.
Pode-se resumir os critérios em oito itens:
a) A figura tem forma, mas o fundo não;

163. b) O contorno que define o limite entre a figura e o fundo faz parte da figura;
c) O fundo cria a impressão de estar sendo continuado por detrás da figura, não se
interrompendo ou perdendo sua unidade. Tal propriedade vai revelar-se de considerável
importância para a atividade exploratória;
d) A figura é visualizada sempre mais próxima da visão do perceptor.
e) As propriedades dos componentes figurais não são permanentes ou imutáveis.
f)Elas sobrevivem até o momento em que por um
processo de reversão, novas unidades figurais surgem.
g) Apreciadas em função do elemento cor e utilizadas as distinções que neste domínio
foram introduzidas por D. Katz, podemos caracterizar a figura em termos de cor de
superfície, exibindo-se o fundo com um colorido transparente ou cor filme.
h) A figura possui um efeito de destaque, sendo o elemento mais estável e bem
visto.
Para saber mais sobre percepção acesse:
http://pt.wikipedia.org/wiki/Percepção
http://geisasantos.com/tag/percepcao-humana/
http://www.infoescola.com/psicologia/cognicao-percepcao-e-
apercepcao/
BOA FORMA
É a forma ideal, que contém todos os elementos para uma boa apresentação, como:
simetria, estabilidade, equilíbrio e simplicidade.
“A figura abaixo ilustra a noção de boa forma. Normalmente percebemos o segmento
da reta A maior do que o segmento da reta B, mas isso é uma ilusão de ótica, pois
são idênticos” (BOCK; FURTADO; TEIXEIRA, 1996, p. 80).
Figura 15 – Setas que confundem a visão

164. Fonte: Adaptado de BOCK; FURTADO; TEIXEIRA (1996)
INSIGHT
“É a passagem súbita de um estado de desconhecimento ou de incompreensão para
um estado de conhecimento e resolução face a um problema” (GICK; LOCKHART,
1995, p. 197).
Na prática seria como se uma criança de que ainda não sabe ler e falar, mas ao ouvir
o som de um “plim...plim” sabe que irá começar o seu desenho preferido.
Ou ainda ao ver elementos visuais de uma marca de refrigerante, saber de qual
marca se trata.
Figura 16 – refrigerante
Langley e Jones (1988) têm a perspectiva face ao insight com base no modelo de
memória de ativação por propagação. Neste modelo, a memória é tomada como uma
imensa rede de conceitos e de ligações entre eles, sendo ativada a rede a partir de
uma informação exterior. Por exemplo, a palavra “verde” vai ativar um conceito
próximo como “semáforo”, e este ativará conceitos próximos como “siga em frente”
e assim sucessivamente.
ALGUNS PRINCÍPIOS DA TEORIA DAS FORMAS
a) Normalmente consideramos formas como figuras em primeiro plano, áreas
circundadas e áreas escuras;
b) É comum considerarmos fundo como formas em segundo plano;
c) As formas geométricas são mais importantes, visualmente, que as espontâneas
porque são compactas;

165. d) Não conseguimos visualizar todas as formas olhando para conjunto de imagens,
quando visualizamos uma forma, os outros objetos e formas automaticamente se
tornam parte do fundo.
e) Formas isoladas tem um destaque maior;
f) Formas verticais são mais grosseiras que as horizontais.
Quando um usuário pensa “Não gosto deste software”, mas não sabe explicar o
motivo, na realidade ele sabe, de forma inconsciente, o que há de errado! Seu
cérebro capta que existe divergências entre os objetos da interface, que alguns fora
do lugar, suas formas e cores não estão em harmonia, trazendo desconforto para
sua visão e percepção.
Estudar a teoria das formas pode oferecer aos designers de software a chance de
desenvolvermelhores layouts e permitir que seu usuário se sinta confortável e utilizá-
lo.
VÍDEO AULA 4
O Plugin Silverlight está desabilitado ou não foi instalado em seu browser, faça o download
clicando aqui ou ative o mesmo.
DIRETRIZES PARA CONSTRUÇÃO DE INTERFACES

166. As diretrizes para desenvolvimento de
interfaces levam em consideração detalhes como o equilíbrio na distribuição dos
elementos em tela, cores, menus, ícones e letras apropriadas, entre outras. Tudo
isso, torna-se importante na interação com o usuário, pois estamos pensando em
alguém que usará as nossas telas muitas horas por dia.
Então, é essencial possuirmos bom senso na escolha dos elementos que estarão nas
telas, também procurando seguir padrões entre essas. Para criar dessa maneira, uma
forma de comunicação direta com o usuário, convidando-o para navegar entre as
facetas do sistema.
Projetar interfaces por modelos conceituais resultam em melhor condução dos
caminhos que os usuários utilizarão nos sistemas. Aplicação de diretrizes torna o
software tão amigável quanto possível.
CONCEITOS DO DESIGN DE INTERAÇÃO
LINK: Para saber mais sobre maus projetos de interface com o usuário e seus
resultados, acesse o site: http://www.baddesigns.com/
Agora vamos fundamentar alguns conceitos sobre desenvolvimento de interfaces.
Estes servirão de base para as aplicações e testes das diretrizes. Podemos destacar
alguns, como:
a) Interface: “é uma superfície de contato que reflete as propriedades físicas das
partes que interagem, as funções a serem executadas e o balanço entre poder e
controle” (LAUREL, 1993 apud ROCHA; BARANAUSKAS, 2000, p. 8).
b) Interface Amigável: São elementos que estão dispostos na interface deixando-
a mais agradável do ponto de vista estético;
c) Interação: É como as pessoas utilizam o computador;
d) Usabilidade:
[...] é a qualidade que caracteriza o uso dos programas e aplicações. Segundo a ISO 9241 usabilidade
é a capacidade que um sistema interativo oferece a seu usuário, em determinado contexto da
operação, para a realização de tarefas de maneira eficaz, eficiente e agradável (CYBIS; BETIOL;
FAUST, 2007, p. 2).

167. e) Design de interação: “significa criar experiências que melhorem e estendam a
maneira como as pessoas trabalham, se comunicam e interagem” (PREECE;
ROGERS; SHARP, 2005, p. 35).
f) Modelo mental (MM): “representação dinâmica sobre qualquer sistema ou
objeto, que evolui naturalmente na mente de um sujeito” (NORMAN, 1985, p. 94
apud ROCHA; BARANAUSKAS, 2000, p. 91-92).
g) Modelo Conceitual: “tem haver com a análise das dificuldades no aprendizado
de programação, e propõe modelos mentais para auxiliar no contexto das
representações computacionais” (ROCHA; BARANAUSKAS, 2000, p. 97).
h) Ergonomia: visa eficácia e eficiência, bem-estar e saúde do usuário, através da
adaptação do trabalho ao homem.
i) Guidelines: recomendações para assegurar que produtos sejam utilizáveis
(PREECE; ROGERS; SHARP, 2005).
j) Heurística: refere-se a como determinar o que os usuários devem ver e fazer
quando realizam tarefas utilizando um produto interativo.
k) Semiótica:
[...] explica a relação entre o objeto, seu representante e o processo de interpretação, no plano dos
signos que encontramos ao nosso redor. Na perspectiva semiótica o papel do computador é
basicamente o de um medium – uma substância na qual signos podem ser manifestados para uso em
comunicação (ANDERSEN, 1997, p. 333).

168. l) Cognição: é o que acontece em nossas mentes quando
realizamos nossas atividades diárias, envolvendo processos cognitivos, tais como:
pensar, lembrar, aprender, fantasiar, tomar decisões, ver, ler, escrever e falar
(PREECE; ROGERS; SHARP, 2005).
m) Percepção: atividades diárias envolvendo processos, tais como
pensar, lembrar, aprender, fantasiar, ver, ler, escrever e falar(PREECE; ROGERS;
SHARP, 2005).
n) Feedback: É a forma de retornar ao
usuário informações sobre ação que foram tomadas.
o) Metáfora de Interface: este conceito provê às pessoas um esquema de
funcionamento da interface, prevendo desentendimentos. “Funcionam como modelos
naturais, permitindo usar conhecimento familiar de objetos concretos e experiências
para dar estrutura a conceitos mais abstratos” (CARROLL et al., 1988 apud
ROCHA; BARANAUSKAS, 2000, p. 12).
Segundo Rocha e Baranauskas (2000), interface e interação são conceitos
que não podem ser estabelecidos ou analisados independentemente, pois
isso seria uma perspectiva simplista desta realidade do desenvolvimento.

169. VÍDEO AULA 5
O Plugin Silverlight está desabilitado ou não foi instalado em seu browser, faça o
download clicandoaqui ou ative o mesmo.
HEURÍSTICAS PARA O DESIGN
Durante a atividade de design, de um projeto IHC, algumas
heurísticas devem ser levadas em consideração. Segundo Nielsen e Mack (1994),
heurísticas são regras gerais que objetivam descrever propriedades comuns de
interfaces usáveis.
a) Visibilidade do status do sistema: O sistema sempre mantém o usuário
informando sobre o que está acontecendo.
b) Compatibilidade do sistema com o mundo real: O sistema interage com o
usuário com linguagens que ele possa compreender.
c) Controle do usuário e liberdade: Permite ao usuário ter a liberdade de avançar
ou retroceder em etapas do sistema.
d) Consistência e padrões: Padroniza palavras e funções
para que tenham o mesmo sentido em qualquer momento do sistema.
e) Prevenção de erros: Procura antecipar-se a erros
f) Reconhecimento em vez de memorização: Procura auxiliar o usuário para que
ele tenha as instruções para uso do sistema sempre que necessário.

170. g) Flexibilidade e eficiência de uso: Permite usuário
com mais experiência a acessarem atalhos para que suas tarefas sejam realizadas
com mais rapidez.
h) Estética e design minimalista: Na comunicação com o usuário os diálogos
precisam conter informações objetivas e restritas ao que se deseja transmitir.
i) Ajudar os usuários a reconhecer, diagnosticar e recuperar-se de
erros: Erros precisam ser demonstrados aos usuários de forma objetiva e que
indique uma ou mais soluções.
j) Help e documentação: Ajuda pontual a cada etapa o sistema, facilita ao usuário
quando houver a necessidade de procurar uma documentação sobre a tarefa que se
deseja executar.

171. GUIDELINES PARA O DESIGN
Ainda, durante a atividade de design, de um projeto
IHC, algumas guidelines são essenciais para bons projetos de interação. A maneira
como projetamos a interface deve conter guidelines(recomendações), que visam
diminuir conflitos entre usuários envolvidos na aplicação (PREECE; ROGERS; SHARP,
2005). Segundo Shneiderman (1998) existem oito regras de ouro, a saber:
a) Esforce-se pela consistência: Posicione menus sempre no mesmo canto e do
mesmo lado da tela. Para cada ação que possa resultar em perda de dados, peça
confirmação da ação, e ofereça aos usuários a oportunidade de mudar de idéia.
b) Possibilite que usuários frequentes utilizem atalhos: Por
exemplo, em processadores de texto, os usuários podem se movimentar pelas
funções utilizando menus, teclas de atalho ou botões de funções.

172. c) Ofereça feedback informativo: Deixe claro o que o erro significa, considerando
os diferentes tipos de usuários e seus significados.
d) Projete diálogos para encerrar as ações: Deixe claro quando uma ação foi
realizada com sucesso.
e) Ofereça prevenção contra erros e manuseio fácil dos mesmos: Erros são
inevitáveis, e o sistema deve perdoar os cometidos e possibilitar que o usuário volte
atrás.
f) Permita uma reversão fácil das ações: Ofereça uma tecla desfazer
(undo) sempre que possível.
g) Forneça suporte para um local interno de controle: Os usuários se sentem
mais confortáveis se percebem que estão no controle da interação, ao invés da
máquina.
h) Reduza a carga de memória de curto prazo: Sempre ofereça aos usuários
opções, em vez de exigir que se lembrem das informações quando mudarem de uma
tela para outra. Como por exemplo, lembrando o que está em seu carrinho de
compras, enquanto procura outros itens para comprar no site.
Um recurso para essas informações é a utilização de Guidelines, que são orientações
que o sistema disponibiliza durante a sua execução. Com o uso deGuidelines a
interação de uma aplicação pode ser bem mais amigável.
Após projetar uma interface é importante submetê-la ao processo de avaliação, que
está detalhado com o professor Everson no próximo módulo.. Pois, estas certificam

173. que o software é utilizável, e também, se está de acordo com o que os usuários
desejam.
DIRETRIZES DE CONSTRUÇÃO DE INTERFACES PARA WEB
Segundo Nielsen e Loranger (2007) as interações fundamentais da web não mudam
com o passar do tempo. As pessoas continuam clicando em links para navegar pelas
páginas, e sua capacidade cognitiva na mudou.
A Web tinha menos de 10 milhões de sites em 2000. E, em 2007, a Web tinha 80
milhões de sites. Hoje a situação é esta: as pessoas simplesmente pressupõem que
a Web tem o que elas querem (NIELSEN; LORANGER, 2007).
Quando o usuário clica mais de três vezes para encontrar uma
informação em qualquer site ele sente-se desmotivado a
continuar navegando. E, geralmente não permanecerá mais
que 10 segundos navegando em outras partes do mesmo site.
Atualmente, a maioria dos projetos para a web leva em consideração, a observação
e a experiência do usuário no uso de interfaces. E a usabilidade beneficia o projeto,
pois apóia a divulgação dos negócios.
LINKS:
Para saber mais sobre usabilidade com o usuário e seus resultados, acesse o
site:http://www.useit.com/
USUÁRIOS
Segundo Chak (2004), o site pode ser projetado para quatro tipos
de usuários. Eles representam necessidades de quem navega, e principalmente de
quem toma as decisões. São estes: Navegadores, Avaliadores, Realizadores de
Transações e Clientes.
Os navegadores procuram por informações para atender suas necessidades,
especialmente aquelas que forneçam um contexto para a tomada de decisão.
Os avaliadores procuram por informações detalhadas sobre produtos e serviços
oferecidos pelo site em questão. Podendo selecionar produtos ou serviços, este tipo
de usuário realiza as avaliações dessas funcionalidades.
Já, os realizadores de transações tomam as decisões de compra pelo site.
Podendo oferecer segurança durante o processo, este tipo de usuário realiza as
transações.

174. Agora, os clientes são aqueles que já compraram e o interesse neste momento é
criar a fidelização destes, a fim de proporcionar outras compras.
DIRETRIZES PARA INTERFACES WEB
Neste momento, precisamos considerar que para o uso de interfaces web o tempo é
sempre diferente em relação ao uso de interfaces desktop. Os usuários têm menos
tolerância com as interfaces, pois desejam que a velocidade de carregamento das
páginas seja alta, e também com menos atrasos.
LINKS:
Para saber mais sobre técnicas e aplicações de usabilidade, acesse o
site:http://www.labiutil.inf.ufsc.br/
Mas, em compensação o usuário sente-se mais no controle da interação, se nas
páginas visitadas houver indicativos de links visitados ou não, ou ainda o caminho de
migalhas. Como também, permitir que o usuário possa voltar para a home page, a
partir de qualquer lugar que esteja navegando. Esses e outros padrões de interação
são descritos a seguir, juntamente com alguns exemplos de suas aplicações.
DIRETRIZES GERAIS DE PROJETOS WEB
Segundo Chak (2004), para criar sites persuasivos existem sete princípios, que foram
identificados por meio de observações empíricas, e servem como diretrizes
no design e teste de projetos Web.
O primeiro princípio diz “A sua concorrência inclui os sites do seu concorrente, a web
e o mundo off-line”. Isso significa que é preciso considerar seus concorrentes,
principalmente nos aspectos relativos à facilidade de localização e compra de
produtos. O autor ainda alerta que o mundo off-line é menos conveniente para os
clientes, então se seu site oferece bons conteúdos e boas funcionalidades você
poderá conquistar esta vantagem em relação a eles.
“Nem tudo pode ser vendido na Internet” diz respeito ao segundo
princípio. Entende-se que a entrega de produtos via web, aumenta o valor total pago
pelos clientes.E este fatorpode ser decisivo, no momento da compra. Principalmente

175. para aqueles clientes que tem urgência na aquisição dos produtos, e não desejam
pagar mais caro por isso.
Já o terceiro princípio diz: “Você deve conquistar o direito de fazer transações com o
usuário”. Este princípio preza pela consciência do projetista, de não exigir
“aproximação”, na forma de solicitar informações pessoais, quando é desnecessário.
Nem sempre os usuários estão dispostos ao preenchimento de cadastros,
simplesmente porque não é do interesse deles. E, na maioria das vezes é do interesse
apenas do projetista.
O quarto princípio descreve assim: “Você sabe tudo sobre o seu site, mas os seus
usuários não sabem nada”. Neste a complexidade do desenvolvimento de sistema
web é considerada. Pois, às vezes, as restrições como as de banco de dados é imposta
e os usuários nem sabem o que significa isso.
“Faça previsão dos erros e das variações com bastante antecedência”. Este princípio
identifica a preocupação com as situações não previstas durante o projeto do site.
Especialmente, as situações longe das idealizadas.
O princípio “Ou você faz o trabalho ou eles fazem” significa oferecer mecanismos no
site para que o usuário possa tomar decisões com mias segurança e realizando as
transações desejadas.
O último princípio listado pelo autor diz: “Ajude seus usuários a fazer o que você
deseja que eles façam”. E, significa que quanto mais guiar os passos dos usuários
mais satisfação em atendê-los você terá, pois estes se tornaram clientes e
realizadores de transações.
Assim, pode-se concluir que após conhecer algumas diretrizes para design web, é
possível aplicá-las em projetos reais. Sabe-se também que durante o processo de
desenvolvimento de sites é importante que o produto de trabalho seja avaliado. E,
se esses forem avaliados por usuários reais os resultados dos testes servem, muitas
vezes, como redesign do próprio site.
Para observarmos um pouco mais as possibilidades do design para web, separei
alguns sites interessantes. Alguns deles são sobre o assunto e alguns com estéticas
diferenciadas para que vocês possam se divertir e aprender mais sobre o tema.
Vejam:
http://www.dontclick.it/
http://www.w3c.br/Home/WebHome
https://www.youtube.com/watch?v=rrn1P-U8kMY
http://www.usabilidoido.com.br/
http://chocoladesign.com/o-que-faz-um-ux-designer
http://arquiteturadeinformacao.com/tag/ux-design/
http://www.similarsitesearch.com/pt/semelhante/arquiteturadeinformacao.com

176. ANDERSEN, Peter Bøgh. A theory of computer semiotic: semiotic approaches to
construction and assessment of computer systems. Cambridge: Cambridge
University Press, 1997.
ASSOCIAÇÃO BRASILEIRA DE ERGONOMIA. O que é ergonomia? Disponível em: <
http://www.abergo.org.br >. Acesso em: 18 abr. 2010.
ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. Requisitos ergonômicos para
trabalho de escritórios com computadores: parte 11: orientações sobre
usabilidade. Rio de Janeiro, 2002. Disponível em: <
http://www.inf.ufsc.br/~cybis/pg2003/iso9241-11F2.pdf >. Acesso em: 20 mar.
2009.
BASTIEN, J. M. Christian; SCAPIN, Dominique L. Human factors criteria,
principles, and recommandations for HCI: methodological and standardisation
issues. Rocquencourt: INRIA, 1993.
BENYON, Daniel. Adaptive systems: a solution to usability problems. User Modeling
and User-Adapted Interaction, Milton Keynes, v. 3, n. 1, p. 65-87, Mar. 1993.
BOCK, Ana Mercês Bahia; FURTADO, Odair; TEIXEIRA, Maria de Lourdes
Trassi. Psicologias: uma introdução ao estudo de psicologia. São Paulo: Saraiva,
1996.
BONSIEPE, Gui. Design: do material ao digital. Florianópolis: FIESC/IEL, 1997.
CHAK, Andrew. Como criar sites persuasivos: clique aqui. São Paulo: Pearson,
2004.
CYBIS, Walterde Abreu. Engenharia de usabilidade: uma abordagem ergonômica.
Florianópolis: Labiutil, 2003.
CYBIS, Walter; BETIOL, Adriana Holtz; FAUST, Richard. Ergonomia e usabilidade:
conhecimentos, métodos e aplicações. São Paulo: Novatec, 2007.
CYBIS, Walter de Abreu et al. Uma abordagem ergonômica para o desenvolvimento
de sistemas interativos. In: WORKSHOP BRASILEIRO DE FATORES HUMANOS EM
SISTEMAS COMPUTACIONAIS, 1., 1998, Maringá. Anais… Maringá, 1998. Disponível
em: < http://www.unicamp.br/~ihc99/Ihc99/AtasIHC99/AtasIHC98/Cybis.pdf >.
Acesso em: 15 mar. 2010.
FARINA, Modesto. Psicodonâmica das cores em comunicação. São Paulo: Edgard
Blücher, 1987.
FERNANDES, Francisco; LUFT, Celso Pedro; GUIMARÃES, F. Marques. Dicionário
brasileiro Globo. 43. ed. São Paulo: Globo, 1996.
FISCHER, Gehard. Beyond “couch potatoes”: from consumers to designers. In: ASIA
PACIFIC COMPUTER HUMAN INTERACTION CONFERENCE, 3., 1998, Hayama-
machi. Proceedings… [s.l.]: IEEE Computer Society, 1998.
GICK, Mary L.; LOCKHART, Robert S; Cognitive and affective components of insight.
In: STERNBERG, Robert J.; DAVIDSON, Janet E. (Ed.). The nature of insight.
Cambridge: MIT Press, 1995. p. 197-228.

177. GOMES FILHO, João. Ergonomia do objeto: sistema técnico da leitura ergonômica.
São Paulo: Escrituras, 2003.
GOMES FILHO, João. Gestalt do objeto: sistema de leitura visual da forma. São
Paulo: Escrituras, 2000.
HIX, Deborah; HARTSON, H. Rex. Developing user interfaces: ensuring usability
through product and process. Hoboken: John Wiley & Sons, 1993.
HOELZEL, Carlos Gustavo Martins. Design ergonômico de interfaces gráficas
humano-computador: um modelo de processo. 2004. Tese (Doutorado em
Engenharia da Produção) - Universidade Federal de Santa Catarina, Florianópolis,
2004.
KOFFKA, Kurt. Princípios da psicologia da Gestalt. São Paulo: Cultrix, 1975.
LABORATÓRIO DE UTILIZABILIDADE DA INFORMÁTICA. Menu de checklist.
Disponível em: < http://www.labiutil.inf.ufsc.br/ergolist/ >. Acesso em: 12 mar.
2010.
LANGLEY, Pat; JONES, Randolph. A computational model of scientific insight. In:
STERNBERG, Robert J. The nature of creativity: contemporary psychological
perspectives. Cambridge: Cambridge University Press, 1988. p. 177-201.
LAUREL, Brenda. The art of human-computer interface design. Reading:
Addison-Wesley Professional, 1990.
LEITE, Jair Cavalcanti; SOUZA, Clarisse Sieckenius de. Uma linguagem de
especificação para a engenharia semiótica de interfaces de usuário.
Disponível em < http://www.unicamp.br/~ihc99/Ihc99/AtasIHC99/art23.pdf >.
Acesso em: 26 mar. 2010.
MONTMOLLIN, M. Introducción a la ergonomía: los sistemas hombres-maquinas.
Madri: Aguillar, 1971.
MORAIS, Éverson Matias de. Um estudo sobre a validade e fidedignidade de
métodos de avaliação de interfaces. 2007. 114 f. Dissertação (Mestrado em
Ciência da Computação) – Universidade Estadual de Maringá, Maringá, 2007.
Disponível em: < http://www.din.uem.br/arquivos/pos-graduacao/mestrado-em-
ciencia-da-computacao/dissertacoes >. Acesso em: 15 mar. 2010.
MORAN, Thomas P. The command language grammars: a representation for the user
interface of interactive computer systems. International Journal of Man-Machine
Studies, London, v. 15, n. 1, p. 3-50, July 1981.
NEVO, David. The conceptualization of educational evaluation: An analytical review
of the literature.Review of Education Research, Washington, v. 53, n. 1, p. 117-
128, Spring 1983.
NIELSEN, Jakob. Ten usability heuristics. Disponível em: <
http://www.useit.com/papers/heuristic/heuristic_list.html >. Acesso em: 10 dez.
2009.
NIELSEN, Jakob; LORANGER, Hoa. Usabilidade na web: projetando websites com
qualidade. São Paulo: Campus. 2007.
NIELSEN, Jakob; MACK, Robert L. Usability inspection methods. Hoboken: John
Wiley & Sons, 1994.

178. PENNA, Antonio Gomes. Percepção e aprendizagem. Rio de Janeiro: Fundo de
Cultura, 1986.
PRATES, Raquel Oliveira; BARBOSA, Simone Diniz Junqueira. Avaliação de interfaces
de usuário: conceitos e métodos. In: CONGRESSO DA SOCIEDADE BRASILEIRA DE
COMPUTAÇÃO, 23., 2003, Campinas. Anais... Campinas: SBC, 2003. Disponível em:
< http://www.dimap.ufrn.br/~jair/piu/artigos/avaliacao.pdf >. Acesso em: 1 abr.
2010.
PREECE, Jenniferet al. Human-computer interaction: concepts and design. Essex:
Addison-Wesley Longman, 1994.
PREECE, Jennifer; ROGERS, Yvonne; SHARP, Helen. Design de interação: além da
interação homem-computador. Porto Alegre: Bookman, 2005.
PRESSMAN, Roger. Engenharia de software. Rio de Janeiro: Campus, 2007.
RAUPP, Magdala; REICHLE, Adriana. Avaliação: ferramenta para melhores projetos.
Santa Cruz do Sul: EDUNISC, 2003.
ROCHA, Heloisa Vieira da; BARANAUSKAS, Maria Cecília C. Design e avaliação de
interfaces humano-computador. São Paulo: IME-USP, 2000.
SANTOS, Venétia, ZAMBERLAN, Maria Cristina. Projeto ergonômico de salas de
controle. São Paulo: Fundación Mapfre, 1992.
SCAPIN, Dominique L.; BASTIEN, J. M. Christian. Ergonomic criteria for evaluating
the ergonomic quality of interactive system. Behaviour and Information
Technology, London, v. 16, n. 4/5, p. 220-231, July 1997.
SCRIVEN, Michael. Types of evaluation and types of evaluator. Evaluation Practice,
Saint Louis, v. 17, n. 2, p. 151-161, Summer 1996.
SHNEIDERMAN, Ben. Designing the user interface: strategies foreffective human-
computer interaction. 3. ed. Essex: Addison-Weslley, 1998.
SOMMERVILLE, Ian. Engenharia de software. São Paulo: Pearson Prentice Hall,
2007.
SOUZA, Clarisse Sieckenius de et al. Projeto de interfaces de usuário: perspectivas
cognitivas e semióticas. In: CONGRESSO DA SOCIEDADE BRASILEIRA DE
COMPUTAÇÃO, 19., 1999, Rio de Janeiro. Anais... Rio de Janeiro: SBC, 1999.
Disponível em: < http://www.dimap.ufrn.br/~jair/piu/JAI_Apostila.pdf >. Acesso
em: 15 mar. 2010.
SOUZA, Maria Carolina S; BUNHAM, Teresinha Fróes. Metáforas e EAD: em busca de
menores distâncias. In: JAMBEIRO, Othon; SILVA, Helena Pereira da
(Org.). Socializando informações, reduzindo distâncias. Salvador: EDUFBA,
2003. p. 87-125.
TEORIA das cores. Disponível em: <
http://www.tecelagemanual.com.br/Teoria%20das%20Cores.ppt >. Acesso em: 13
abr. 2010.
WISNER, Alain. Por dentro do trabalho: ergonomia: método e técnica. São Paulo:
FDT, 1987.
SUGESTÕES DE LEITURA

179. CYBIS, Walter de Abreu. A identificação dos objetos de interfaces home,-
computador em seus atributos ergonômicos. 1994. Tese (Doutorado em
Engenharia da Produção) - Universidade Federal de Santa Catarina, Florianópolis,
1994.
ERTHAL, Tereza Cristina. Manual de psicometria. Rio de Janeiro: Jorge Zahar,
2003.
JOHNSON, Steven. Cultura da interface: como o computador transforma nossa
maneira de criar e comunicar. Rio de Janeiro: Zahar, 2001.
MINICUCCI, Agostinho. Psicologia aplicada à administração. São Paulo: Atlas,
1992.
NIELSEN, Jakob. Severity ratings for usability problems. Disponível em: <
http://www.useit.com/papers/heuristic/severityrating.html >. Acesso em: 5 jan.
2010.
PERES, Cláudio Cezar. Ações de fiscalizações preventivas de LER/DORT na área do
comércio. Boletim da Saúde, Porto Alegre, v. 19, n. 1, p. 39-50, jan./jun. 2005.
Disponível em: <
http://www.mp.to.gov.br/portal/sites/default/files/Ações%20Coletivas%20para%2
0Prevenção%20de%20LER-DORT.pdf >. Acesso em: 11 abr. 2010.
PERES, Cláudio Cezar et al. A multiprofissionalidade e interinstitucinalidade
necessárias em uma ação ergômica complexa. In: CONGRESSO BRASILEIRO DE
ERGONOMIA, 10., 2000, Rio de Janeiro.Anais... Rio de Janeiro: ABERGO, 2000.
Disponível em: < http://www.ergonet.com.br/download/amultiprofissionalidade-
claudio_c_peres.pdf >. Acesso em: 15 mar. 2010.