3.engenharia Web (WebE) - 1

Aplicações e
Serviços Web
Docente: Hélio Santana, Lic.

Sumário 1. Apresentação
2. Aplicações e Serviços na web
3. Engenharia web (WebE)
4. Arquitectura da web
5. Serviços web (Web Services)
6. Web Semântica
3. Engenharia Web
(WebE)
“Desenvolvimento Web é um adolescente ... Tal como a maioria dos
adolescentes, ela quer ser aceite como um adulto, enquanto ele
tenta se afastar de seus pais. Se ele está indo para atingir seu pleno
potencial, ele deve tomar algumas lições do mundo mais experiente
Web
Development
de desenvolvimento de software.”, Doug Wallace et al.
4
3. Engenharia Web | Fundamentos
Engenharia de Software
• Processo de análise dos requisitos do utilizador e, em

seguida, desenhar, construir e testar o software que irá
satisfazer esses requisitos;
• Preocupa-se com todos os aspectos da produção de
software;
• É a ciência e a arte de construir um software bom e eficiente
que está no prazo, dentro do orçamento, com operações
correctas, aceitável e com bom desempenho.
5
Ferramentas automatizadas ou
semi-automatizadas para apoio ao
desenvolvimento
Orientações técnicas Agrega as diversas

para a construção do tecnologias para a
software, compreendem construção de
uma série de software. Organiza
actividades, inclusive as tarefas, a
modelagem aplicação dos
métodos e o uso
de ferramentas.
Base de tudo, factor motivador para

a Engenharia de Software
6
Engenharia da Web
• Consiste no estudo de processos, conceitos, métodos e

técnicas utilizados para desenhar e construir aplicações web
de alta qualidade;
• É a aplicação de abordagens sistemáticas e computáveis
para análise de requisitos, desenho, implementação, teste,
operação e manutenção de aplicações web de alta
qualidade com custo reduzido;
7
Engenharia da Web – particularidades
• A engenharia da web é multidisciplinar, e não uma disciplina

única;
• O processo de desenvolvimento web é diferente e único;
• É uma experiência individual;
• A economia de curto prazo leva a problemas de longo prazo
na operação, manutenção, usabilidade, etc.
8
• Principais causas de uma mal projecto web:
• O desenvolvimento é "fácil“;
• A codificação como actividade principal;
• As técnicas que não devem ser usadas são mal
aplicadas;
• As técnicas que devem ser usadas não são;
• Notas importantes:
• A maioria dos projectos agora são baseados na web
(Web-based);
• Mais aplicações de "missão crítica" estão a migrar para
a web; 9
• Principais armadilhas dos projectos web:
• 84% - Falha em cumprir os objectivos de negócios;

• 79% - Atrasos no cronograma do projecto;
• 63% - Orçamento excedido;
• 53% - Falta de funcionalidades.
10
• Algumas soluções para projectos web:
• Metas e objectivos claramente definidos;

• Desenvolvimento sistemático em fases;
• Planeamento cuidadoso;
• Auditoria iterativa e contínua de todo o processo.
11
Etapas Típicas do Processo de Engenharia de Software
• Compreender natureza e propósito do produto

• Seleccionar o processo de desenvolvimento e criar um plano
• Desenho e construção do produto
• Entregar e manter o produto
• Recolher requisitos
• Testar o produto
12
Modelo em cascata
13
Modelos Evolutivos: Modelo em Espiral
14
Modelo incremental
15
Agilidade:
• Efectiva resposta a alterações (rápida e adaptativa);

• Efectiva comunicação com todos os intervenientes stakeholders;
• O cliente faz parte da equipa;
• Organização de equipas de forma a controlar efectivamente o
trabalho realizado;
resumindo …
• Entrega rápida e incremental do software
16
Processo Ágil:
• É orientado por descrições do cliente sobre o que é pretendido

(cenários)
• Reconhece que os planos têm uma “vida-curta”
• O software é desenvolvido iterativamente com ênfase nas
actividades de construção
• Entrega de múltiplos “incrementos de software”
• Adaptação à medida que as alterações ocorrem
17
O processo de WebE (Web Engineering):
● Deverá acomodar:
• Alterações frequentes
• Ciclos de desenvolvimento curtos, com entregas incrementais ou ciclos evolutivos
• Encorajar a criatividade e “independência” com a equipa de desenvolvimento
• Interacção forte entre todos os stakeholders
• Equipas de desenvolvimento pequenas
● Assim,
• Deverá ser usado em todas as situações um modelo incremental de
desenvolvimento de software
• Em muitas situações os modelos ágeis de desenvolvimento de software são os
mais apropriados.
18
19
Análise de negócios
Formulação
20
• Comunicação com o Cliente

• Análise de Negócio define o contexto de negócio /organizacional da
WebApp.
• Formulação actividade de recolha dos requisitos envolvendo todos os
stakeholders. O objectivo é a descrição do problema que a WebApp
pretende resolver.
• Planeamento
• Define um cronograma para cada um dos incrementos da WebApp,
estima o custo global do projecto e avalia os riscos associados..
21
• Modelação
• Modelo de Análise — estabelece a base para a fase de desenho
• Análise do Conteúdo (Content Analysis).
• Análise da Interacção (Interaction Analysis).
• Análise Funcional (Functional Analysis).
• Análise da Configuração (Configuration Analysis).
• Modelo de Desenho — representa os elementos essenciais de uma WebApp

• Desenho do Conteúdo (Content design))
• Desenho da arquitectura (Architectural design)
• Desenho da Interface (Interface design)
• Desenho da navegação (Navigation design)
• Desenho de Componentes (Component design)
22
• Construção
• As ferramentas e técnicas de WebE são aplicadas para a construção do que foi
modelado
• Após um novo incremento da WebApp são realizados testes de desenho (conteúdo,
arquitectura, navegação, interface…
• Avaliação e Entrega (Deployment)
• Configuração do ambiente operacional
• Entregue aos utilizadores finais e
• O retorno da avaliação é apresentado à equipa de WebE
• O incremento é modificado de acordo com o retorno (inicia-se o novo ciclo
incremental)
23
WebE – Questões básicas
• Quão importante é a home page da Web site?
• Qual é o esquema da página mais eficaz (por exemplo, o menu na parte superior, no lado direito ou
esquerdo?) Será que isso variar, dependendo do tipo de WebApp a ser desenvolvido?
• Quais as opções de mídia têm o maior impacto?
• Quanto trabalho podemos esperar que um utilizador possa fazer quando está à procura de
informações?
• Qual a importância de ajudas à navegação quando WebApps são complexas?
• Quão complexo pode ser formas de entrada para que não possa irritar o utilizador? Como podem ser
os formulários de entrada acelerada?
• Quão importante são os recursos de pesquisa?
• Será que o WebApp será desenvolvido de maneira que o torna acessível para aqueles que têm
deficiências físicas?
24
WebE – Boas práticas
• Leve o tempo necessário para perceber as necessidades de negócio e

especifique objectivos mesmo que os detalhes da WebApp sejam vagos;
• Descreva a interacção dos utilizadores com a WebApp através de
uma aproximação baseada em cenários;
• Elabore um plano mesmo que “rudimentar”.
25
WebE – Boas práticas
• Perca alguma tempo a modelar o que vai ser construído;

• Reveja a consistência e a qualidade dos modelos;
• Utilize ferramentas e tecnologia que lhe permitam construir a sua
WebApp com o máximo de componentes reutilizáveis;
• Não delegue no utilizador a tarefa de “debug” da WebApp – É
necessário desenhar testes e executá-los antes da sua entrega.
26
Análise de negócios
Formulação Plano de iteração 27
Formulação
• Identifique a necessidade de negócio;

• Passe para a descrição dos objectivos da WebApp;
• Defina as características e funcionalidades principais;
• Estabeleça uma actividade de recolha de requisitos que contribuirá
para o modelo de análise;
• Permita que os stakeholders e a equipa da engenharia de web
estabeleçam um conjunto de objectivos comuns para a construção da
WebApp.
28
Formulação - Questões
• Qual é a motivação principal para a (necessidade de negócio)

WebApp?
• Quais são os objectivos que a WebApp satisfaça?
• Quem é que vai utilizar a WebApp? As respostas
disponibilizam …
• Objectivos de conteúdo — indica a intenção de disponibilizar
conteúdos/informação específicos para o utilizador final
• Objectivos da aplicação — indica as tarefas que a WebApp deve
oferecer
29
WebE – Recolha de Requisitos
• Peça aos stakeholders para definirem as categorias de utilizadores e

descrições para cada categoria
• Comunique com os stakeholders para definir os requisitos de uma
WebApp
• Defina os casos de uso que descrevam cenários de interacção para
cada categoria de utilizador
30
Categoria de Utilizadores
• Qual é o objectivo global do utilizador quando utiliza a

WebApp?
• Qual é o background dos utilizadores relativamente ao
conteúdo e funcionalidade de uma WebApp?
• Como é que o utilizador acede à WebApp?
• Quais as características gerais da WebApp que o utilizador
aprecia/não aprecia?
• Solução possível: webapps favoritas ou menos favoritas
31
Comunicação com os Stakeholders
• Grupos de discussão tradicionais - moderador treinado reúne-se com um pequeno
grupo de representante de utilizadores finais (ou stakeholders internos no papel
de utilizadores finais).
• Grupos de discussão electrónicos - uma discussão moderada electrónica realizada
com um grupo de representante de utilizadores finais e as partes interessadas.
• Pesquisas Iterativas - uma série de pesquisas breve, dirigida aos utilizadores
representativos e as respostas pedindo para perguntas específicas sobre o
WebApp
• Pesquisas exploratórias - uma pesquisa baseada na Web que está vinculado a um
ou mais WebApps que os seus utilizadores são semelhantes aos que usarão o
WebApp a ser desenvolvido.
• Criação de cenários - utilizadores seleccionados são convidados a criar casos de
uso informais que descrevem interacções específicas com o WebApp. 32
Análise Preliminar
• Categorizar a informação recolhida por tipo de utilizador ou por tipo de transacção

• Desenvolver lista de …
• Objectos conteúdo
• Operações que são aplicadas aos objectos conteúdo durante uma transacção
• Funções (e.g., lógica, computacional, orientadas à ajuda, …. computacional, logical,
and help-oriented) disponibilizadas aos utilizadores finais pela WebApp
• Outros requisitos não funcionais
33
Casos de Uso
• Disponibilizam o detalhe necessário para a criação de um modelo de análise

• Ajudam a equipa de desenvolvimento a perceber como é que os utilizadores
interagem com a WebApp
• Ajudam a compartimentar o trabalho de engenharia
• Fornecem orientações importantes para quem vai testar a WebApp
34
Equipa de WebE
• Competências (skills)
• Engenharia de software baseado em componentes
• Sistemas e redes
• Desenho de arquitectura e de navegação
• Desenho de interfaces
• Linguagens e normas Internet
• Teste de Webapp
● Distribuídos pelos diversos membros que compõem uma equipa.
35
Equipa de WebE
• Papéis de uma equipa de WebE
• Developer/Providers de conteúdos
• Oriundos de áreas muito diversas

• Editor (Web Publisher)
• Responsável pela organização de conteúdos
• Actua como elemento de ligação entre equipa técnica de engenharia da Webapp e a equipa não técnica
• Engenheiro da Web (Web Engineer)

• Responsável em todas as actividades de desenvolvimento da Webapp: recolha de requisitos, análise, desenho da
arquitectura, navegação e da interface…
• Competências: arquitectura cliente/servidor, HTML/XML, tecnologias BD, segurança, …..
• Especialistas de negócio (Business domain experts)

• Especialistas de suporte (Support Specialist)
• Administrador (a.k.a. “Webmaster”) 36
“’O trabalho em equipa reúne forças,
experiências e conhecimentos”
37
Diferenças com os Projectos Tradicionais
38
Planeamento de WebApp
• Entender o escopo, as dimensões da mudança as restrições do projecto.

• Definir uma estratégia de projecto incremental.
• Realizar análise de risco.
• Desenvolver uma estimativa rápida.
• Selecione um conjunto de tarefas (descrição do processo).
• Estabelecer um cronograma.
• Definir mecanismos de monitoramento do projecto.
• Estabelecer uma abordagem de gestão de mudança.
39
WebE “As más práticas”
• Temos uma óptima ideia, então vamos começar a construir o WebApp –

agora.
• Coisas que mudam constantemente, então não há nenhum ponto em tentar
entender os requisitos WebApp.
• Programadores cuja experiência dominante tem sido no desenvolvimento de
software tradicional pode desenvolver WebApps imediatamente. Não é
necessário uma formação.
• Seja burocrática.
• Testar? Por que se preocupar?
40
Codificação
Teste de componentes
Modelo de desenho
• Conteúdo
Modelo de análise
• Arquitectura
• Conteúdo
• Navegação
• Iteração
Análise de negócios • Interface
• Função
Formulação Plano de iteração • Configuração 41
Modelo de Análise
42
Quando é que realizamos a Análise?
• Em algumas situações de WebE a fase de análise e desenho podem ser

agrupadas. No entanto, em certas situações é necessário realizar a
separação …
• a AppWeb é grande e complexa;
• o número de stakeholders é grande;
• o nº de engenheiros de AppWeb e outros é muito grande;
• Os objectivos e o sucesso da AppWeb têm consequências no sucesso do
negócio
43
Hierarquia de Utilizadores
• Categorias de utilizadores
• É aconselhável construir uma hierarquia
de utilizadores quando o número de
categorias aumenta
44
Diagrama de Casos de Uso
45
Modelo de Casos de Uso
• Os casos de uso são organizados em pacotes funcionais

• Cada pacote é avaliado para garantir que ele é:
• Compreensível
• todos os interessados a entender o propósito do pacote
• Coesa
• o pacote trata de funções que estão intimamente relacionados entre si
• Fracamente acoplada
• funções ou classes dentro do pacote colaboram um com o outro, mas a colaboração fora do pacote são mantidos
a um mínimo.
• Hierarquicamente rasa
• hierarquias funcionais profundas são difíceis de navegar e difícil para os utilizadores finais entenderem, portanto,
o número de níveis dentro de uma hierarquia de caso de uso deve ser minimizado sempre que possível.
46
Modelo de Conteúdos
• Identificar os objectos de conteúdo

• Analisar os cenários e respectivas referências directas e indirectas ao conteúdo
• Identifique atributos para cada objecto
• Identifique as relações entre os objectos ou construa uma hierarquia de conteúdos
mantidos pela AppWeb
• Relações — Diagrama Entidade/Associação ou UML
• Hierarquia — “Árvore de Dados” ou UML
47
Árvore de Dados (Data Tree)
48
Diagrama de Classes - UML
49
Modelo de Interacção
50
Modelo Funcional
• O modelo funcional engloba dois elementos de

processamento de uma AppWeb
• Funcionalidade observada pelos utilizadores
• As operações existentes no modelo de classes
• Os diagramas de actividades UML podem ser
utilizados para representar o fluxo de processamento
51
Diagrama de Actividade
52
Modelo de Configuração
• Do lado do Servidor
• Especificação do hardware do servidor e SO
• Realização de considerações sobre a interoperabilidade
• Especificação de protocolos de comunicação …
• Do lado do Cliente
• Identificação dos aspectos de configuração do Browser
● Definição dos requisitos de teste - apesar dos standards é
necessário especificar os requisitos específicos de cada
browser
53
Análise da Navegação
• Objectivo: identificar características e estabelecer relações que vão ter influência no desenho (design)
da navegação.
• Algumas questões chave:
• Existem elementos para os quais o acesso deverá ser mais fácil do que outros? (navegação exige menos etapas)
Qual é a prioridade de apresentação?
• Deverão realçar-se determinados elementos de forma a forçar os utilizadores a navegar na sua direcção?
• Como é que deverão ser tratados os erros de navegação?
• A navegação deverá ser realizada através de links, por meio de pesquisa, ou por outros meios?
• Certos elementos devem ser apresentados com base no contexto de anteriores acções de navegação?
• Deverá ser mantido um log de navegação para os utilizadores?
54
• O menu completo de navegação (em oposição a um “back” ou link direccionado)

deverá estar disponível em todos os pontos de interacção?
• O desenho da navegação deverá ser baseado no comportamento comum dos
utilizadores ou pela percepção da importância dos elementos definidos AppWeb?
• Para que categoria de utilizadores deverá ser desenhada a navegação óptima?
• Como é que devem ser geridos os links para o exterior da AppWeb? Sobrepondo
a janela já existente? Uma nova janela?
55
• O menu completo de navegação (em oposição a um “back” ou link direccionado)

deverá estar disponível em todos os pontos de interacção?
• O desenho da navegação deverá ser baseado no comportamento comum dos
utilizadores ou pela percepção da importância dos elementos definidos AppWeb?
• Para que categoria de utilizadores deverá ser desenhada a navegação óptima?
• Como é que devem ser geridos os links para o exterior da AppWeb? Sobrepondo
a janela já existente? Uma nova janela?
56
Desenho de WebApps
“Existem basicamente duas abordagens

básicas para desenho: O ideal artístico de
expressar-se e o ideal da engenharia de
resolver um problema de um cliente”
Jakob Nielsen
57
Design e Qualidade da WebAPP
• Segurança
• Exclusão a acessos não autorizados e ataques externos
• Assegurar privacidade dos utilizadores e clientes
• Disponibilidade
• % de tempo na qual a AppWeb está disponível
• Escalabilidade
• Capacidade de gerir uma variação significativa no número de utilizadores e
no volume de transações
• Time to Market 58
Dimensões da Qualidade para os utilizadores finais
• Tempo
• Quantas alterações desde o último upgrade do site Web?
• Como valoriza as partes que foram alteradas?
• Estrutura
• Todos os links internos e externos do site web estão a funcionar?
• Todas as imagens estão a funcionar?
• Existe alguma parte do Web site que não está a funcionar?
• Conteúdo
• O conteúdo das páginas criticas coincide com o que é suposto estar presente?
• A qualidade é mantida de vs para vs?
59
• e as páginas geradas dinamicamente?
Dimensões da Qualidade para os utilizadores finais
• Consistência/Correcção
• Quais as diferenças entre as cópias de informação descarregadas entre hoje e ontem?
• Qual a correcção da informação? Como é que o utilizador sabe?
• Tempo de Resposta
• Depois do SUBMIT e num contexto de comércio electrónico (E-commerce) qual o tempo de
resposta?
• Existe alguma parte do site Web que se releva tão lenta que o utilizador desiste de trabalhar?
• Desempenho
• A ligação Browser-Web-Web site-Web-Browser é suficientemente rápida?
• Em que medida o desempenho varia com o período do dia e com a carga de utilização?
• O desempenho é adequado para aplicações de comércio electrónico? 60
Objectivos – Desenho da Aplicação Web
• Simplicidade
• Consistência
• Identidade
• Estabelecer uma "identidade" que é apropriado para o propósito do negócio
• Robustez
• O utilizador espera que o conteúdo e as funções que são relevantes para as necessidades do utilizador sejam robusto
• Navegabilidade
• concebido de uma maneira que é intuitivo e previsível
• Apelo visual
• a aparência do conteúdo, layout da interface, coordenação de cores, o balanço de textos, gráficos e outros meios de
comunicação, mecanismos de navegação deve apelar aos utilizadores finais
• Compatibilidade
• Com todos os ambientes e configurações apropriadas 61
Desenho da Aplicação Web
• Desenho da interface (interface design)
• Estrutura e organização da interface do utilizador.
• Representação do layout, definição dos modos de interacção e descrição dos mecanismos de navegação
• Desenho da estética (graphic design)

• “Look and feel” da AppWeb
• Desenho do conteúdo (content design)

• Desenho da navegação (navigation design)
• Representação do fluxo de navegação entre objectos de conteúdo e para todas as funções da AppWeb
• Desenho da arquitectura (architecture design)

• Identifica toda a estrutura hipermédia para a AppWeb
• Desenho de componentes (component design)

• Detalhe do processamento lógico para implementar as componentes funcionais 62
Desenho de Objectos de Conteúdo
63
Desenho da Arquitectura
• Arquitectura de conteúdo ou da informação (Content architecture) relacionada

com a forma com estão estruturados os objectos de conteúdo (ou objectos
compostos como as páginas web) para a respectiva apresentação e navegação.
• Arquitectura da WebApp estrutura da aplicação para gerir a interacção com o
utilizador, tratamento de tarefas de processamento interno, efectuar a
navegação e apresentar conteúdos.
64
Arquitectura de conteúdo
65
Arquitectura de conteúdo
66
Arquitectura MVC
• MVC (Model-View-Controller)
• Objectivo: modelo de infraestrutura para AppWeb com separação da interface, da funcionalidade e
do conteúdo.
• O modelo contém o processamento lógico e o conteúdo específico aplicacional, incluindo:
• todos os objectos de conteúdo,
• acesso a dados externos/recursos de informação,
• todo o processamento específico da aplicação
• A vista contém todas as funções específicas da interface que permitem:

• a apresentação do conteúdo e do processamento lógico,
• Acesso aos dados externos/recursos de informação,
• todas as funcionalidades requeridas pelos utilizadores finais.
• O controlador gere o acesso entre o modelo e a vista e coordena o fluxo de informação entre eles.
67
Arquitectura MVC
68
Testes aplicados a WebAPP
69
Testes a WebAPP
• Testes de Conteúdo
• Testes para encontrar erros sintácticos, semânticos e estruturais no conteúdo estático
• Execuções para encontrar erros no conteúdo gerado dinamicamente a partir de repositórios de
informação.
• Testes da Interface de Utilizador
• Testar os mecanismos da interface
• Scripts de validação de formulários, links, html dinâmico, etc.
• Testar a semântica da interface

• Verificar se os casos de usos identificados são concretizáveis
• Testar a usabilidade
• Testar a compatibilidade
• Diferentes browsers, SO, monitores, …
70
Testes a WebAPP
• Testes de Componentes
• Testar os módulos
• Testes de Navegação
• Sintaxe – verificar que os links funcionam como pretendido
• Semântica – garantir que a navegação permite atingir os objectivos definidos pelos casos de uso para cada categoria de
utilizadores
• Testes de Configuração
• Do lado do servidor: compatibilidade com SO, sistemas de ficheiros, firewalls, etc.
• Do lado do cliente: hardware, SO, browser,…
• Testes de Segurança
• Testes de Desempenho
• Recursos no servidor, largura de banda inadequada, …
• Testes de desempenho, carga e stress.
71
Testes de aceitação
Entrada em Produção
Avaliação do Cliente Codificação
Teste de componentes
Incremento de Software
Modelo de desenho
• Conteúdo
Modelo de análise
• Arquitectura
• Conteúdo
• Navegação
• Iteração
Análise de negócios • Interface
• Função
Formulação Plano de iteração • Configuração 72
3. Engenharia Web (WebE) | Q&A
73
“Há Engenheiros de Software e
Pedreiros de Software”
74
Muito Obrigado !
75

3.engenharia Web (WebE) - 1

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

3.engenharia Web (WebE) - 1

Enviado por

Direitos autorais:

Formatos disponíveis

Aplicações e

Docente: Hélio Santana, Lic.

• Processo de análise dos requisitos do utilizador e, em

Orientações técnicas Agrega as diversas

Base de tudo, factor motivador para

• Consiste no estudo de processos, conceitos, métodos e

• A engenharia da web é multidisciplinar, e não uma disciplina

• Principais armadilhas dos projectos web:

• 84% - Falha em cumprir os objectivos de negócios;

• Algumas soluções para projectos web:

• Metas e objectivos claramente definidos;

• Compreender natureza e propósito do produto

• Efectiva resposta a alterações (rápida e adaptativa);

• É orientado por descrições do cliente sobre o que é pretendido

• Comunicação com o Cliente

• Modelo de Desenho — representa os elementos essenciais de uma WebApp

• Leve o tempo necessário para perceber as necessidades de negócio e

• Perca alguma tempo a modelar o que vai ser construído;

• Identifique a necessidade de negócio;

• Qual é a motivação principal para a (necessidade de negócio)

• Peça aos stakeholders para definirem as categorias de utilizadores e

• Qual é o objectivo global do utilizador quando utiliza a

• Categorizar a informação recolhida por tipo de utilizador ou por tipo de transacção

• Disponibilizam o detalhe necessário para a criação de um modelo de análise

• Oriundos de áreas muito diversas

• Engenheiro da Web (Web Engineer)

• Especialistas de negócio (Business domain experts)

• Entender o escopo, as dimensões da mudança as restrições do projecto.

• Temos uma óptima ideia, então vamos começar a construir o WebApp –

• Em algumas situações de WebE a fase de análise e desenho podem ser

• Os casos de uso são organizados em pacotes funcionais

• Identificar os objectos de conteúdo

• O modelo funcional engloba dois elementos de

• O menu completo de navegação (em oposição a um “back” ou link direccionado)

• O menu completo de navegação (em oposição a um “back” ou link direccionado)

“Existem basicamente duas abordagens

• Desenho da estética (graphic design)

• Desenho do conteúdo (content design)

• Desenho da arquitectura (architecture design)

• Desenho de componentes (component design)

• Arquitectura de conteúdo ou da informação (Content architecture) relacionada

• A vista contém todas as funções específicas da interface que permitem:

• Testar a semântica da interface

Você também pode gostar