Walter de Tarso

Material de referência

TI – ICMS

Walter de Tarso

Versão 1

2012
Curso de TI

Sumário
1 Gerência de Projetos ....................................................................................................................... 1
1.1 Conceitos básicos ................................................................................................................................. 1
1.2 Processos do PMBOK .......................................................................................................................... 2
1.2.1 Áreas de conhecimento do PMBOK ............................................................................................................... 3
1.3 Planejamento e controle de métricas de projeto ............................................................................... 13
1.4 Métodos de gerenciamento do tempo do projeto .............................................................................. 14
1.5 Exercícios ........................................................................................................................................... 14
2 Gestão de Processos de Negócio (BPM) ....................................................................................... 18
2.1 BPMN - Modelagem de processos ..................................................................................................... 18
2.1.1 Elementos ................................................................................................................................................... 18
2.2 Técnicas de análise de processos ....................................................................................................... 20
2.2.1 Automação de processos .............................................................................................................................. 20
2.2.2 Fluxograma ................................................................................................................................................. 20
2.2.3 Service blueprint ......................................................................................................................................... 20
2.2.4 Mapa do serviço .......................................................................................................................................... 21
2.2.5 IDEF ........................................................................................................................................................... 21
2.2.6 Estrutura de processamento de clientes ........................................................................................................ 22
2.2.7 Walk-through-audit ..................................................................................................................................... 22
2.2.8 Análise da transação de serviço (STA – Service Transaction Analysis) ......................................................... 23
2.3 Exercícios ........................................................................................................................................... 23
3 Gerência de Serviços de TI ........................................................................................................... 25
3.1 Fundamentos da ITIL V2 .................................................................................................................. 26
3.1.1 Suporte a serviços ........................................................................................................................................ 26
3.1.2 Entrega de Serviço....................................................................................................................................... 27
3.2 Fundamentos de ITIL V3 .................................................................................................................. 28
3.2.1 Estratégia do serviço (Service Strategy) ....................................................................................................... 28
3.2.2 Desenho de serviço (Service Design) ........................................................................................................... 28
3.2.3 Transição do serviço (Service Transition) .................................................................................................... 29
3.2.4 Operação do serviço (Service Operation) ..................................................................................................... 29
3.2.5 Melhoria de serviço continuada (Continual Service Improvement) ............................................................... 29
3.3 Fundamentos de COBIT.................................................................................................................... 29
3.3.1 Planejar e Organizar .................................................................................................................................... 30
3.3.2 Adquirir e Implementar ............................................................................................................................... 30
3.3.3 Entregar e Dar Suporte ................................................................................................................................ 30
3.3.4 Monitorar e Avaliar ..................................................................................................................................... 31
3.4 Exercícios ........................................................................................................................................... 31
4 Engenharia de Software ............................................................................................................... 33
4.1 Software ............................................................................................................................................. 33
4.2 Ciclo de vida do software ................................................................................................................... 34
4.2.1 Fase de Definição ........................................................................................................................................ 34
4.2.2 Fase de Desenvolvimento ............................................................................................................................ 34
4.2.3 Fase de Operação ........................................................................................................................................ 35
4.2.4 Fase de retirada ........................................................................................................................................... 36
4.3 Metodologias de desenvolvimento de software. ................................................................................ 36
4.3.1 Modelo caótico ............................................................................................................................................ 36
4.3.2 Modelo Cascata ........................................................................................................................................... 36
4.4 Desenvolvimento ágil ......................................................................................................................... 38
4.5 Planejamento e avaliação de iterações .............................................................................................. 39

Pág. 2 de 143
 Walter de Tarso
4.6 Técnicas de avaliação de software ..................................................................................................... 40
4.6.1 Análise por Pontos de Função ...................................................................................................................... 40
4.6.2 Método COCOMO ...................................................................................................................................... 44
4.7 Gerência de Requisitos de Software .................................................................................................. 44
4.7.1 Conceitos de Requisitos ............................................................................................................................... 45
4.7.2 Requisitos Funcionais e Não-Funcionais ...................................................................................................... 46
4.8 Gerência de Configuração e Mudança .............................................................................................. 47
4.8.1 Conceitos de Gerência de Configuração e Mudança de software ................................................................... 47
4.8.2 Solicitações de Mudança.............................................................................................................................. 48
4.9 Testes e Avaliação de Qualidade de Software ................................................................................... 49
4.9.1 Qualidade de Software................................................................................................................................. 49
4.9.2 Teste de software......................................................................................................................................... 51
4.9.3 Documentos de Teste................................................................................................................................... 52
4.10 Exercícios ........................................................................................................................................ 53
5 Arquitetura de Software................................................................................................................ 59
5.1 Conceitos básicos ............................................................................................................................... 59
5.2 UML ................................................................................................................................................... 59
5.3 GED - Gerenciamento Eletrônico de Documentos e Workflow ....................................................... 61
5.3.1 Exercícios ................................................................................................................................................... 62
5.4 Arquitetura Orientada a Serviço (SOA) ........................................................................................... 63
5.4.1 Serviço ........................................................................................................................................................ 63
5.4.2 Processos .................................................................................................................................................... 63
5.4.3 Tecnologia .................................................................................................................................................. 63
5.4.4 Definições de SOA ...................................................................................................................................... 63
5.4.5 Web Services .............................................................................................................................................. 64
5.4.6 SOAP .......................................................................................................................................................... 66
5.4.7 WSDL ......................................................................................................................................................... 67
5.4.8 UDDI .......................................................................................................................................................... 67
5.4.9 Segurança.................................................................................................................................................... 68
5.4.10 Exercícios ................................................................................................................................................... 68
5.5 Portais corporativos e colaborativos ................................................................................................. 69
5.6 Exercícios ........................................................................................................................................... 70
6 Banco de Dados ............................................................................................................................ 73
6.1 Conceitos básicos ............................................................................................................................... 73
6.2 Modelagem de Dados Relacional ....................................................................................................... 73
6.2.1 Normalização .............................................................................................................................................. 74
6.2.2 Etapas de modelagem .................................................................................................................................. 75
6.2.3 Relacionamentos ......................................................................................................................................... 75
6.2.4 Transação .................................................................................................................................................... 76
6.3 Modelo Entidade Relacionamento..................................................................................................... 76
6.4 Modelagem de Dados Multidimensional ........................................................................................... 77
6.4.1 Sistemas Transacionais X Sistemas Analíticos ............................................................................................. 78
6.5 Conceitos de Datawarehouse e ETL .................................................................................................. 78
6.5.1 ETL ............................................................................................................................................................ 80
6.6 Conceitos de desenvolvimento em banco de dados SQL Server e Oracle ........................................ 80
6.6.1 SQL ............................................................................................................................................................ 80
6.6.2 Arquitetura de um Servidor Oracle............................................................................................................... 82
6.6.3 Arquitetura de um Servidor SQL Server ....................................................................................................... 83
6.7 Exercícios ........................................................................................................................................... 84
7 Programação de Sistemas ............................................................................................................. 90
7.1 Lógica de Programação ..................................................................................................................... 90
Curso de TI
7.1.1 Tipos de dados e variáveis ........................................................................................................................... 91
7.2 Programação orientada a objetos ...................................................................................................... 92
7.2.1 Objetos........................................................................................................................................................ 92
7.2.2 Classe ......................................................................................................................................................... 93
7.2.3 Persistência ................................................................................................................................................. 93
7.2.4 Métodos ...................................................................................................................................................... 93
7.2.5 Atributos ..................................................................................................................................................... 94
7.2.6 Mensagens .................................................................................................................................................. 94
7.2.7 Herança ....................................................................................................................................................... 94
7.2.8 Polimorfismo............................................................................................................................................... 94
7.2.9 Sobrecarga .................................................................................................................................................. 95
7.2.10 Interfaces .................................................................................................................................................... 95
7.2.11 Pacotes ........................................................................................................................................................ 95
7.3 Programação na WEB ....................................................................................................................... 95
7.3.1 Linguagem HTML ...................................................................................................................................... 96
7.3.2 Linguagens web de servidor......................................................................................................................... 97
7.3.3 XML ........................................................................................................................................................... 98
7.4 Conceitos de linguagem de programação Microsoft .NET ............................................................... 98
7.4.1 arquitetura da .Net ....................................................................................................................................... 99
7.4.2 Linguagens de programação ........................................................................................................................ 99
7.4.3 Common Language Specification (CLS) .................................................................................................... 100
7.4.4 Common Type System (CTS) .................................................................................................................... 100
7.4.5 Framework Class Library (FCL) ................................................................................................................ 100
7.4.6 Camada de apresentação ............................................................................................................................ 100
7.4.7 ADO.Net ................................................................................................................................................... 100
7.4.8 .Net Remoting ........................................................................................................................................... 100
7.4.9 Common Language Runtime (CLR)........................................................................................................... 101
7.4.10 Common Language Infrastructure (CLI) .................................................................................................... 101
7.4.11 Operating System (OS) .............................................................................................................................. 101
7.4.12 Outros detalhes da .Net .............................................................................................................................. 101
7.5 Exercícios ......................................................................................................................................... 102
8 Segurança da informação........................................................................................................... 106
8.1 Conceitos básicos ............................................................................................................................. 106
8.2 Plano de Continuidade de Negócio .................................................................................................. 108
8.3 Vulnerabilidade ............................................................................................................................... 108
8.4 Auditoria e conformidade ................................................................................................................ 109
8.5 Conhecimento sobre norma ISO 27001........................................................................................... 111
8.6 Exercícios ......................................................................................................................................... 111
9 Sistemas Operacionais ................................................................................................................ 115
9.1 Conceitos de administração de servidores em plataforma Windows ............................................. 115
9.2 Conceitos de administração de servidores em plataforma Linux ................................................... 115
9.2.1 Alguns comandos no Linux ....................................................................................................................... 115
9.2.2 Gerenciando a iniciação do Linux .............................................................................................................. 117
9.2.3 Fazendo Backups....................................................................................................................................... 117
9.2.4 Recompilando e Adaptando o Kernel ......................................................................................................... 117
9.2.5 Agendando Processos ................................................................................................................................ 117
9.2.6 Syslogd - A Caixa Preta do Linux .............................................................................................................. 117
9.2.7 Técnicas Básicas para Trabalhar com Redes (ifconfig, route) ..................................................................... 118
9.2.8 Gerenciando os Serviços - inetd ................................................................................................................. 118
9.2.9 Utilizando Ferramentas de Busca ............................................................................................................... 118
9.2.10 Instalando SSh / SShD .............................................................................................................................. 118
9.3 Conceitos de Virtualização .............................................................................................................. 119
9.4 Active Directory ............................................................................................................................... 121

Pág. 4 de 143
 Walter de Tarso
9.5 Exercícios ......................................................................................................................................... 122
10 Redes ....................................................................................................................................... 125
10.1 Conceito de rede ........................................................................................................................... 125
10.1.1 Configuração de redes TCP-IP ................................................................................................................... 125
10.2 Arquitetura de Rede ..................................................................................................................... 127
10.2.1 Camada Física ........................................................................................................................................... 128
10.2.2 Camada de Enlace ou Ligação de Dados .................................................................................................... 128
10.2.3 Camada de Rede ........................................................................................................................................ 128
10.2.4 Camada de Transporte ............................................................................................................................... 129
10.2.5 Camada de Sessão ..................................................................................................................................... 129
10.2.6 Camada de Apresentação ........................................................................................................................... 129
10.2.7 Camada de Aplicação ................................................................................................................................ 129
10.3 Noções de administração de redes................................................................................................ 130
10.4 Acesso Remoto .............................................................................................................................. 130
10.5 Rede Wireless ............................................................................................................................... 130
10.6 Exercícios ...................................................................................................................................... 131
11 Referências .............................................................................................................................. 135
12 Sobre o autor ........................................................................................................................... 136
13 Gabarito................................................................................................................................... 137

Sumário de imagens
Ilustração 1 Métricas .......................................................................................................................................... 13
Ilustração 2 Exemplo de Fluxo utilizando pool, lanes, evento de início e fim, tarefas e gateway ......................... 19
Ilustração 3 Símbolos BMPN utilizados no MS Visio .......................................................................................... 19
 TI para concursos

1 Gerência de Projetos

1.1 Conceitos básicos

1
Um projeto é um esforço temporário empreendido para criar um produto, não necessariamente
temporário, serviço ou resultado exclusivo. Os projetos e as operações diferem, principalmente, no fato
de que os projetos são temporários e exclusivos, enquanto as operações são contínuas e repetitivas.
Os projetos são normalmente autorizados como resultado de uma ou mais considerações estratégicas.
Estas podem ser uma demanda de mercado, necessidade organizacional, solicitação de um cliente,
avanço tecnológico ou requisito legal.
As principais características dos projetos são:
 temporários, possuem um início e um fim definidos.
 planejados, executado e controlado.
 entregam produtos, serviços ou resultados exclusivos.
 desenvolvidos em etapas e continuam por incremento com uma elaboração progressiva.
 realizados por pessoas.
 com recursos limitados.
Esse é um resumo da definição de projeto feita pelo Guia PMBOK®, um guia que identifica o
subconjunto do conjunto de conhecimentos em gerenciamento de projetos, amplamente reconhecido
como boa prática na maioria dos projetos na maior parte do tempo e utilizado como base pelo Project
Management Institute ( PMI®).
Gerência de projetos é a disciplina de manter os riscos de fracasso em um nível tão baixo quanto
necessário durante o ciclo de vida do projeto. Sua função é definir e alcançar objetivos ao mesmo
tempo em que se otimiza o uso de recursos (tempo, dinheiro, pessoas, espaço etc).2
Na abordagem tradicional, distinguimos cinco grupos de processos no desenvolvimento de um projeto:
 iniciação – autorização do projeto ou fase
 planejamento – são processos iterativos de definição e refinamento de objetivos e seleção dos
melhores caminhos para atingir os objetivos.
 execução – realização dos planos do projeto: coordenação de pessoas e outros recursos para
executar o plano
 controle – medição e monitoramento do desempenho do projeto. Garantem que os objetivos do
projeto são alcançados através do monitoramento e medição regular do progresso, de modo que
ações corretivas possam ser tomadas quando necessário.
 encerramento – aceitação formal do projeto (com verificação de escopo) ou fase para a sua
finalização.
Repetir os processos de iniciação antes da execução de cada fase é uma maneira de se avaliar se o
projeto continua cumprindo as necessidades de negócio. Envolver as partes interessadas no projeto em
cada uma das fases é uma maneira de aumentar as probabilidades de satisfação dos requisitos do
cliente.
O gerente de projetos precisa monitorar e comunicar o desempenho do projeto. Os resultados do
trabalho que estiverem abaixo de um nível de desempenho aceitável precisam ser ajustados com
ações corretivas para que o projeto volte a estar em conformidade com as linhas de base de custo,
prazo e escopo. A comunicação do desempenho do projeto é um dos principais elementos para o
gerenciamento de projetos bem sucedido.
O projeto ou empreendimento visa a satisfação de uma necessidade ou oportunidade, definida no texto
acima como fase inicial na qual existem muitas áreas e/ou pessoas envolvidas.
Um programa é um conjunto de projetos com um objetivo comum.
Em geral, existe mais do que uma solução ou alternativas para atender às mesmas necessidades. A
técnica usada para definir a solução final passa pelo desenvolvimento de alternativas extremas. A
primeira, de baixo custo, que atende as necessidades mínimas para ser funcional. A segunda tenta
atender a maior parte das as exigências das diversas áreas envolvidas no escopo, que resulta num
projeto com custo muito maior e pouco competitivo. A partir de ambas as alternativas é desenvolvida

1 http://pt.wikipedia.org/wiki/Projeto
2 http://pt.wikipedia.org/wiki/Gerência_de_projetos
1
 TI para concursos
uma solução intermediária entre as mesmas, que atende a uma boa parte das exigências com um
custo competitivo.
O gerenciamento de projetos tenta adquirir controle sobre as variáveis
 tempo - influencia o prazo até o termino do projeto. Uma restrição de tempo pode significar custos
aumentados e/ou escopo reduzido.
 custo - informa o valor monetário incluído no orçamento disponível para o projeto. Um orçamento
apertado pode significar tempo aumentado e/ou escopo reduzido.
 escopo - designa o que deve ser feito para produzir o resultado de fim do projeto. O escopo
aumentado pode significar o tempo aumentado e/ou o custo aumentado.
Na versão atual do PMBOK, tríplice restrição foi eliminada, passando a existir restrições do projeto que
são elas: Escopo, Qualidade, Cronograma, Orçamento, Recursos e Riscos. Portanto, qualquer
alteração em um desses itens certamente haverá restrições em um ou mais dos demais itens.
Para manter o controle sobre o projeto do início ao fim, um gerente de projetos utiliza várias técnicas,
dentre as quais se destacam:
 Planejamento de projeto
 Análise de valor agregado
 Gerenciamento de riscos de projeto
 Cronograma
 Melhoria de processo

1.2 Processos do PMBOK

O Guia PMBOK3 identifica um subconjunto do conjunto de conhecimentos em gerenciamento de
projetos, que é amplamente reconhecido como boa prática, sendo em razão disso, utilizado como base
pelo Project Management Institute (PMI). Uma boa prática não significa que o conhecimento e as
práticas devem ser aplicadas uniformemente a todos os projetos, sem considerar se são ou não
apropriados.
O Guia PMBOK também fornece e promove um vocabulário comum para se discutir, escrever e aplicar
o gerenciamento de projetos possibilitando o intercâmbio eficiente de informações entre os profissionais
de gerência de projetos.
O guia é baseado em processos e subprocessos para descrever de forma organizada o trabalho a ser
realizado durante o projeto. Essa abordagem se assemelha à empregada por outras normas como a
ISO 9000 e o Software Engineering Institute's, CMMI.
A versão 2008 do guia, cita 42 processos agrupados em cinco grupos e nove áreas de conhecimento.
O conhecimento de gerenciamento de projetos, descrito no Guia PMBOK consiste em:
 Definição do ciclo de vida e da organização de um projeto
 Descrição dos cinco grupos de processos de gerenciamento de projetos
 Grupo de processos de iniciação
 Grupo de processos de planejamento
 Grupo de processos de execução
 Grupo de processos de monitoramento e controle
 Grupo de processos de encerramento
 Descrição das nove áreas de conhecimento
Existem três documentos principais descritos no Guia PMBOK® e cada um deles possui um objetivo
específico:
 Termo de abertura do projeto. Autoriza formalmente o projeto.
 Declaração do escopo do projeto. Determina qual trabalho deverá ser realizado e quais entregas
precisam ser produzidas.
 Plano de gerenciamento do projeto. Determina como o trabalho será realizado.

3 http://pt.wikipedia.org/wiki/PMBOK
2
 TI para concursos

1.2.1 Áreas de conhecimento do PMBOK

Os quarenta e dois processos dos cinco grupos definidos pelo PMBOK podem ser classificados em
nove chamadas áreas de conhecimento.
Iniciação Planejamento Execução Monitoramento e controle Encerramento
Desenvolver o termo de Desenvolver o plano de Orientar e gerenciar a Monitorar e controlar o Encerrar o projeto
abertura do projeto gerenciamento de projeto execução do projeto trabalho do projeto
4 - Integração
Desenvolver o escopo Controle integrado de
preliminar do projeto mudanças
Planejamento do escopo Verificação do escopo
5 - Escopo Definição do escopo Controle do escopo
Criar EAP
Definição das atividades Controle do cronograma
Sequenciamento de
atividades
Estimativa de recursos das
6 - Tempo atividades
Estimativa de duração das
atividades
Desenvolvimento do
cronograma
Estimativa de custos Controle de custos
7 - Custo
Orçamentação
Planejamento da qualidade Realizar a garantia da Realizar o controle da
8 - Qualidade
qualidade qualidade
Planejamento de RH Controlar ou mobilizar a Gerenciar a equipe do
equipe do projeto projeto
9 - RH
Desenvolver a equipe do
projeto
Planejamento das Distribuição das Relatório de desempenho
10 - Comunicação comunicações informações Gerenciar as partes
interessadas
Planejamento de Monitoramento e controle
gerenciamento de riscos de riscos
Identificação dos riscos
Análise qualitativa dos
11 - Riscos riscos
Análise quantitativa dos
riscos
Planejamento de respostas
a riscos
Planejar compras e Solicitar respostas dos Administração de contratos Encerramentos de
12 - Aquisições aquisições fornecedores contratos
Planejar contratações Selecionar fornecedores

Os processos descritos se relacionam e interagem durante a condução do trabalho e a descrição de

cada um deles é feita em termos de:
 Entradas – documentos, planos, desenhos etc.
 Ferramentas e técnicas - que se aplicam as entradas
 Saidas – que podem ser entradas de outros processos

3
 TI para concursos
1.2.1.1 Integração de projetos
Núcleo do gerenciamento de projetos, é composto dos processos do dia-a-dia com os quais o gerente
de projetos conta para garantir que todas as partes do projeto funcionem juntas. É um processo
contínuo que o gerente completa para garantir que o projeto prossiga do início ao fim – é a atividade
diária de completar o trabalho do projeto..

4
 TI para concursos
1.2.1.2 Escopo de projetos
Garantir que o projeto inclui todo o trabalho requerido (requisitos), e somente o trabalho requerido.
 Destaca-se nesta área a criação da estrutura analítica de processos (EAP), ou Work Breakdown
Structure (WBS), uma ferramenta de decomposição do trabalho do projeto em partes manejáveis,
uma estrutura em forma de árvore exaustiva, hierárquica (de mais geral para mais específica) de
entregáveis (deliverables) e tarefas, genericamente pacotes, que precisam ser feitas para
completar um projeto. Um instrumento facilitador do planejamento de projeto que o desmembra em
atividades menores que podem ser mais facilmente dimensionadas em relação a tempo de
execução, recursos e custos.

5
 TI para concursos
1.2.1.3 Tempo de projetos
 Completar o projeto dentro do prazo.

6
 TI para concursos
1.2.1.4 Custo de projetos
 Completar o projeto dentro do orçamento.

7
 TI para concursos
1.2.1.5 Qualidade de projetos
 Garantir que o projeto vai satisfazer as necessidades pelas quais ele foi feito. Qualidade não é o
melhor resultado possível, mas o atendimento justo dos requisitos, do cronograma e orçamento.
 Qualidade é a totalidade de características de uma entidade que a torna capaz de satisfazer
necessidades declaradas ou implícitas .
 Um aspecto crítico da gerência da qualidade, no contexto do projeto, é a necessidade de traduzir
as necessidades implícitas em necessidades declaradas, através da gerência do escopo do
projeto

8
 TI para concursos
1.2.1.6 Recursos humanos de projetos
 Fazer o uso mais efetivo das pessoas envolvidas no projeto.

9
 TI para concursos
1.2.1.7 Comunicações de projetos
 Garantir rápida e adequada geração, coleção, disseminação, armazenamento e disposição final
das informações do projeto.

10
 TI para concursos
1.2.1.8 Riscos de projetos
 Identificar, analisar e responder aos riscos do projeto.

11
 TI para concursos
1.2.1.9 Aquisições de projetos
 Adquirir bens e serviços externos.

12
 TI para concursos

1.3 Planejamento e controle de métricas de projeto

Métricas são medidas quantitativas que podem produzir
informações usadas para minimizar atrasos e riscos, e para
avaliar a qualidade durante o desenvolvimento.
Definições:
 Medida - fornece uma indicação quantitativa da extensão,
quantidade, dimensão, capacidade ou tamanho de algum
atributo de um produto ou processo.
 Medição - ato de determinação de uma medida.
 Métrica - medida quantitativa do grau em que um sistema Ilustração 1 Métricas
se encontra em relação a um determinado atributo.
 Indicadores - métrica ou combinação de métricas que fornece uma compreensão de um processo,
projeto ou produto.
Tipos de métricas:
 Diretas - custo, esforço, linhas de código (LOC), velocidade de execução, memória utilizada,
defeitos reportados etc.
 Indiretas - qualidade, funcionalidade, complexidade, eficiência, confiabilidade, manutebilidade etc.
O planejamento de métricas pode ser feito em etapas.
 Fase 1 – caracterização dos indicadores
 Fase 2 – medição
 Fase 3 – tratamento estatístico
 Fase 4 – monitoramento e análise
 Fase 5 – gestão do processo
As tendências são mais importantes de serem monitoradas do que qualquer valor absoluto no tempo.
As métricas para determinados aspectos do projeto incluem:
Métrica Finalidade Exemplos de medidas/perspectivas
Andamento em termos Planejamento de iteração Número de classes
de tamanho e Abrangência SLOC
complexidade Pontos de função
Cenários
Casos de teste

Essas medidas também podem ser coletadas por classe e por pacote

Quantidade de retrabalho por iteração (número de classes)

Estabilidade em termos Convergência Número e tipo de mudanças (erro versus melhoria; interface versus implementação)
de taxa de mudança
nos requisitos ou
implementação, Essa medida também pode ser coletada por iteração e por pacote
tamanho ou
complexidade Quantidade de retrabalho por iteração

Adaptabilidade Convergência Média de pessoa-horas/mudança

"Retrabalho" de software
Essa medida também pode ser coletada por iteração e por pacote
Modularidade em Convergência Número de classes/categorias modificadas por mudança
termos do escopo de "Retalhamento" de software
mudança
Essa medida também pode ser coletada por iteração
Qualidade em termos Planejamento de iteração Número de erros
da quantidade e do tipo Indicador de retrabalho Taxa de detecção de defeitos
de erros Critério de release Densidade de defeitos
Profundidade da herança
Acoplamento de classes
Tamanho da interface (número de operações)
Número de métodos substituídos
Tamanho do método

13
 TI para concursos

Métrica Finalidade Exemplos de medidas/perspectivas

Essas medidas também podem ser coletadas por classe e por pacote
Maturidade em termos Adequação/cobertura de Falha/horas de teste e tipo de falha
da freqüência de erros teste
Resistência para uso
Essa medida também pode ser coletada por iteração e por pacote
Perfil de despesas do Visão financeira Pessoa-dias/classe
projeto versus Planejado versus real Equipe em tempo integral por mês
despesas planejadas Porcentagem do orçamento já gasta

1.4 Métodos de gerenciamento do tempo do projeto

Existem métodos que objetivam formas de comprimir as durações das atividades sem alteração no
escopo do projeto.
Crashing é usado para diminuir a duração total do cronograma do projeto pelo menor custo adicional,
como redução das durações ou aumento da atribuição de recursos nas atividades do cronograma.
Paralelismo ou fast tracking é usado para tentar programar atividades em paralelo (simultâneas), mas
costuma gerar retrabalho e aumenta os riscos. É uma técnica de compressão do cronograma de um
projeto específico que altera a lógica de rede para sobrepor fases que normalmente seriam realizadas
em seqüência, como a fase de projeto e a fase de construção, ou para realizar atividades do
cronograma em paralelo.
Uma simulação do projeto utiliza um modelo que traduz as incertezas especificadas em um nível
detalhado do projeto para seu impacto potencial nos objetivos do projeto. As simulações são
normalmente realizadas usando a técnica de Monte Carlo. Em uma simulação, o modelo do projeto é
calculado muitas vezes (iterado), sendo os valores das entradas randomizados a partir de uma função
de distribuição de probabilidades (por exemplo, custo dos elementos do projeto ou duração das
atividades do cronograma) escolhida para cada iteração a partir das distribuições de probabilidades de
cada variável. Uma distribuição de probabilidades (por exemplo, custo total ou data de término) é
calculada.

1.5 Exercícios
1. (ICMS-SP 2009) A respeito dos conceitos aplicados aos Projetos, segundo o PMBOK, é INCORRETO
1
afirmar:
(a) A equipe do projeto, como uma unidade de trabalho, raramente sobrevive ao projeto.
xx
(b) Um projeto é um esforço contínuo que visa manter um serviço em funcionamento.
(c) Geralmente, o termo "temporário" não se aplica ao produto, serviço ou resultado criado pelo projeto.
(d) Pode ser classificado como projeto aquele que é do tipo de pesquisa que desenvolve um conhecimento.
(e) Os projetos podem criar uma capacidade de realizar um serviço.
2
2. (ICMS-SP 2009) São entradas para o processo de Planejamento da Qualidade (PMBOK):
(a) Fatores ambientais da empresa, Ativos de processos organizacionais e Declaração do escopo do
xx
projeto.
(b) Análise de custo-benefício, Projeto de experimentos e Métricas de qualidade.
(c) Plano de melhorias no processo, Linha de base da qualidade e Métricas de qualidade.
(d) Plano de melhorias no processo, Fatores ambientais da empresa e Listas de verificação da qualidade.
(e) Plano de gerenciamento da qualidade, Fatores ambientais da empresa e Análise de custo-benefício.
3. (ICMS-SP 2009) No PMBOK, a técnica que compara as realizações técnicas durante a execução do projeto
com as do cronograma do plano de gerenciamento do projeto, podendo usar parâmetros técnicos
importantes do produto desenvolvido pelo projeto como uma métrica de qualidade, sendo que os valores
3
medidos fazem parte das informações sobre o desempenho do trabalho, é denominada
(a) Critical Chain Method.
(b) Probability and Impact Matrix.
(c) Work Performance Information.
(d) Performance Measurement Baseline.
xx
(e) Technical Performance Measurement.

14
 TI para concursos
4. (ICMS-SP 2009) Planos mais exatos e completos, resultantes de sucessivas iterações do processo de
planejamento e estimativas mais exatas, elaboradas à medida que o projeto se desenvolve, são produtos da
técnica aplicada para melhoria e detalhamento contínuos dos planos. Essa técnica, no PMBOK, é
4
denominada
(a) Loop de rede.
xx
(b) Elaboração progressiva.
(c) Estrutura Analítica dos Recursos.
(d) Gerenciamento de Portfólios.
(e) Estimativa paramétrica.
5. Segundo o PMBOK, as etapas de iniciação, planejamento, execução, monitoração/controle e encerramento
5
representam apenas o
(a) ciclo de vida dos projetos ou ciclo de gerenciamento de projetos.
(b) grupo de processos dos projetos ou ciclo de gerenciamento de projetos.
(c) grupo de processos dos projetos ou ciclo de vida dos projetos.
(d) grupo de processos do gerenciamento de projetos ou ciclo de vida dos projetos.
(e) grupo de processos do gerenciamento de projetos ou ciclo de gerenciamento de projetos.x
6. Os processos do PMBOK: criação da estrutura analítica do projeto (EAP) e verificação do escopo do projeto
6
devem ser realizados, respectivamente, nas etapas de
(a) planejamento e execução.
xx
(b) planejamento e monitoração/controle.
(c) iniciação e execução.
(d) iniciação e monitoração/controle.
(e) iniciação e encerramento.
7. Considere a seguinte definição com respeito à gerência de projetos: Ferramenta de decomposição do
trabalho do projeto em partes manejáveis. É uma estrutura em forma de árvore exaustiva, hierárquica (de
mais geral para mais específica ) de deliverables e tarefas que precisam ser feitas para completar um projeto.
7
Tal é a definição de
(a) Histogram.
(b) Workflow.
(c) Timesheet.
xx
(d) Work Breakdown Structure.
(e) Flowchart.
8. Um instrumento facilitador do planejamento de projeto que o desmembra em atividades menores que podem
8
ser mais facilmente dimensionadas em relação a tempo de execução, recursos e custos, é o
(a) Flowchart.
(b) Organization Chart.
(c) Workflow.
(d) Histogram.
xx
(e) Work Breakdown Structure.
9. De acordo com o corpo de conhecimento da gerência de projetos, as simulações para análise de risco de
9
prazos são possíveis utilizando
(a) o Arrow Diagramming Method.
xx
(b) a técnica Monte Carlo.
(c) o modelo WBS.
(d) a análise de custo/benefício.
(e) o Project Charter.
10
10. O WBS, Word Breakdown Structure, é a principal ferramenta de gerenciamento de
(a) escopo do projeto.xx
(b) integração dos elementos do projeto.
(c) pessoal envolvido com o projeto.
(d) comunicação das informações do projeto.
(e) qualidade do projeto.

11. Considere a seguinte figura:

No contexto da gerência de projetos de software, o
diagrama parcialmente mostrado na figura representa,
11
tipicamente,
(a) um PERT.
(b) um gráfico de Gantt.
xx
(c) uma Work Breakdown Structure.
(d) um Project Charter.
(e) um Flowchart.

15
 TI para concursos
12. De acordo com o corpo de conhecimento da gerência de projeto, a necessidade de traduzir as necessidades
12
implícitas em necessidades declaradas, através da gerência do escopo do projeto, é
xx
(a) um aspecto crítico da gerência da qualidade, no contexto do projeto.
(b) objeto de avaliação da gerência do custo do projeto.
(c) dispensada se for elaborado um planejamento de respostas aos riscos.
(d) destacada durante a medição de desempenho.
(e) um aspecto crítico da análise de precedência de tarefas.
13. De acordo com o corpo de conhecimento da gerência de projeto, para estimar os custos totais, quando ainda
existe uma quantidade limitada de informações detalhadas sobre o projeto (por exemplo, nas fases iniciais), é
13
freqüentemente
(a) elaborado um modelo paramétrico.
xx
(b) usada uma estimativa por analogia.
(c) usada uma estimativa bottom-up.
(d) elaborada uma análise de precedência.
(e) elaborada uma análise da variação.
14. Existem métodos que objetivam formas de comprimir as durações das atividades sem alteração no escopo
do projeto. Um deles é usado para quando existem negociações de agenda e custos para determinar como
(e se) fazer a maior compressão para o menor custo. Outro é usado para tentar programar atividades em
paralelo (simultâneas), mas costuma gerar retrabalho e aumenta os riscos. São usual e respectivamente
14
denominados de métodos
(a) crashing e what-if.
(b) de Monte Carlo e what-if.
(c) fast tracking e de Monte Carlo.
xx
(d) crashing e fast tracking.
(e) what-if e crashing.
15. Para um gerenciamento de projeto de informática bem sucedido, a ordem de execução das atividades deve
15
ser
(a) planejamento, integração, organização, medição e revisão.
xx
(b) planejamento, organização, integração, medição e revisão.
(c) organização, planejamento, integração, medição e revisão.
(d) organização, planejamento, medição, integração e revisão.
(e) planejamento, organização, medição, revisão e integração.
16
16. (ARCE FCC 2006) O fator de máximo desempenho de um projeto está diretamente relacionado ao fator de
(a) escopo limitado.
(b) escopo genérico.
(c) tempo reduzido.
xx
(d) custo alto.
(e) tempo excessivo.
17. (CVM FCC 2006) Dentre os fatores que afetam os projetos, o fator performance se aproxima do máximo, ou
17
ponto ótimo, quando relacionado ao fator
xx
(a) custo alto.
(b) tempo reduzido.
(c) tempo excessivo.
(d) escopo limitado.
(e) escopo genérico.
18. Duas atividades de um projeto podem ocorrer simultaneamente quando o inter-relacionamento das mesmas
18
é do tipo
(a) início para início (SS) ou término para início (FS).
(b) término para término (FF) ou término para início (FS).
xx
(c) início para início (SS) ou término para término (FF).
(d) início para término (SF) ou término para término (FF).
(e) término para início (FS) ou início para término (SF).
19
19. Os produtos a serem entregues no mais baixo nível da estrutura do projeto (WBS) geralmente são
xx
(a) pacotes de trabalho.
(b) planos do projeto.
(c) fases do projeto.
(d) recursos disponíveis.
(e) cronogramas do projeto.
20
20. Segundo o uso universal dos conceitos de gerenciamento de projetos, um programa é
(a) um empreendimento não repetitivo de eventos numa seqüência clara e lógica, com início, meio e fim.
(b) parte de um projeto ou subdivisão tática de fácil gerenciamento e controle.
(c) um subprojeto, desvinculado de um projeto, que pode ser terceirizado.
xx
(d) um conjunto integrado de projetos que tem missões e objetivos comuns.
(e) um conjunto de subprojetos, que podem ter vidas próprias isoladamente.

16
 TI para concursos
21. No ciclo da vida de um projeto, são aplicáveis todos os nove processos componentes da área de
21
gerenciamento de projetos somente na fase de
(a) iniciação.
(b) finalização.
xx
(c) planejamento.
(d) execução.
(e) controle.
22
22. Na determinação de cronogramas utilizando os modelos PERT e CPM, o caminho crítico representa
(a) a estimativa de tempo mais provável para o conjunto de tarefas do projeto.
(b) o término mais breve da cada tarefa do projeto.
(c) os limites de tempo que definem o início e o término da cada tarefa.
xx
(d) uma cadeia de tarefas que determina a duração do projeto.
(e) uma rede de todas as tarefas desde o começo até o final de um projeto.

17
 TI para concursos

2 Gestão de Processos de Negócio (BPM)

O Business Process Management (BPM) ou Gerenciamento de Processos de Negócio é um conceito
que une gestão de negócios e tecnologia da informação com foco na otimização dos resultados das
organizações através da melhoria dos processos de negócio. São utilizados métodos, técnicas e
ferramentas para analisar, modelar, publicar, otimizar e controlar processos envolvendo recursos
humanos, aplicações, documentos e outras fontes de informação. 4
Um processo de negócio é uma sequência de tarefas que, ao serem executadas, transforma insumos
em um resultado com valor agregado.
Distingue-se do conceito de BI (business intelligence), pois este monitora as informações que dão
suporte ao negócio, enquanto aquele monitora os processos que o compõe. O BI é uma ferramenta útil
à gestão de processos de negócios.

2.1 BPMN - Modelagem de processos

O Business Process Modeling Notation, em português Notação de Modelagem de Processos de
Negócio, é uma notação da metodologia de gerenciamento de processos de negócio e trata-se de uma
série de ícones padrões para o desenho de processos, o que facilita o entendimento do usuário.
A modelagem é uma etapa importante da automação, pois é nela que os processos são descobertos e
desenhados. É nela também que pode ser feita alguma alteração no percurso do processo visando a
sua otimização.
A notação também pode ser utilizada para a modelagem de Arquitetura de Processos.
O objetivo do BPMN é de apoiar a gestão de processos de negócios tanto para usuários técnicos e
usuários de negócios, fornecendo uma notação que é intuitiva para os usuários corporativos ainda
capaz de representar a semântica complexa do processo.

2.1.1 Elementos
A modelagem em BPMN é feita através de diagramas simples, com um pequeno conjunto de
elementos gráficos. Isto facilita que os usuários de negócio, bem como os desenvolvedores, entendam
o fluxo e o processo. As quatro categorias básicas de elementos são as seguintes:
 Objetos de Fluxo – definem o comporatmento do fluxo. Fazem a movimentação das informações
através de ações.
 Eventos – Qualquer coisa que acontece durante o fluxo. Ações (trigger) que interferem no fluxo
(result), tipicamente prazos, também podendo ser uma chamada de um sistema externo (web
service) ou alguma alteração no banco de dados (watching). Representado por um círculo. Há três
tipos de eventos: início, intermediário e fim.
 Atividades – Ações (sub-processos ou tarefas) realizadas pelos usuários, chamados de atores,
normalmente por tela de algum programa de computador. Representada por um retângulo
arredondado.
 Gateways – Controla a convergência e divergência da sequência de fluxos e atividades no fluxo.
Determina ramificações (branch), bifurcações (forking), mistura (merging) e junções (join) de
caminhos. Representado por um losango.
 Objetos de Conexão
 Fluxo de Sequência – seta em linha contínua ligando dois objetos, indica a ordem de execução
dos objetos.
 Fluxo de Mensagem – seta em linha tracejada indicando o fluxo de mensagens entre participantes
 Associação – linha ou seta em linha pontilhada indicando uma ligação entre uma informação,
normalmente uma anotação, e um artefato.
 Swim lane – uma área de agrupamento de objetos de fluxo representado por uma faixa que vai da
esquera à direita da página, com um nome para a faixa em seu lado esquerdo.
 Pool – indica um participante, setor, departamento ou qualquer lugar onde se encontram os atores.
Um pool pode apresentar detalhes internos do processo (white box) ou pode ter nenhum processo
(black box). A interação entre pools é feita através de fluxos de mensagens. Nenhum fluxo de
sequência pode ser associado a black boxes, mas os fluxos de mensagem podem ligá-los.
 Lane – subdivisão de uma pool.

4 http://pt.wikipedia.org/wiki/Business_Process_Management
18
 TI para concursos
 Dados – possuem informações que os objetos de fluxo necessitam para serem realizadas
 Objetos de dados – informações armazenadas
 Dados de entrada – informações solicitadas
 Dados de saída – informações produzidas em uma atividade ou evento
 Armazenamento – gravação dos dados
 Artefatos – informações adicionais sobre o fluxo
 Grupo – agrupamento de elementos de uma mesma categoria para fins de entendimento, sem
efeito sobre o fluxo. Representado por um retângulo arredondado tracejado.
 Anotação – uma observação para facilitar o entendimento do fluxo para o leitor. Represnetado por
uma linha de associação terminada por um colchete e o texto.
 Mensagem – informação enviada entre dois participantes. Representado por ícone de uma carta.
Estas quatro categorias de elementos nos dão a oportunidade de fazer um diagrama de processos de
negócio simples (BPD).

Ilustração 2 Exemplo de Fluxo utilizando pool, lanes, evento de início e fim, tarefas e gateway

Ilustração 3 Símbolos BMPN utilizados no MS Visio

19
 TI para concursos

2.2 Técnicas de análise de processos

2.2.1 Automação de processos

Realizada pelos BPMS, divide-se em modelagem, simulação, execução, controle e otimização.
Um aplicativo do tipo BPMS, tipicamente, inclui o mapeamento dos processos de negócio ponta-a-
ponta, desenho dos fluxos e formulários eletrônicos, definição de workflow, regras de negócio,
integradores, monitoração em tempo real das atividades e alertas. É uma poderosa ferramenta de
gestão, para garantir que os processos estão sendo efetivamente executados como modelados,
contribuindo para os objetivos da organização.
A modelagem de processos é feita no próprio BPMS. Alguns destes seguem a notação mais usada
atualmente, o BPMN (Business Process Modeling Notation). Esta notação trata-se de uma série de
ícones padrões para o desenho de processos, o que facilita o entendimento do usuário. A modelagem é
uma etapa importante da automação pois é nela que os processos são descobertos e desenhados. É
nela também que pode ser feita alguma alteração no percurso do processo visando a sua otimização.
Após o desenho e o estabelecimento dos usuários responsáveis pela conclusão de cada tarefa, pode
ser feita uma simulação, onde se pode testar se as regras pré-estabelecidas estão de acordo com o
objetivo da empresa e se as tarefas estão sendo encaminhadas para as pessoas corretas.
A execução do processo ocorre após as etapas anteriores já terem sido realizadas. O BPMS utilizado
faz com que as tarefas sejam enviadas para os seus devidos responsáveis, controlando o seu tempo
de execução por pessoa e pelo processo em geral. Podem ser utilizadas também regras de negócio
(Business Rules) pré-estabelecidas.
O controle ideal de BPM é aquele que está presente durante todas as etapas do processo: antes,
durante e depois. Desde o início da modelagem até a análise pós-conclusão da execução, o controle
deve ser realizado. Um tipo de controle que existe em alguns BPMS são relatórios de fluxos em
andamento, onde é fornecido o status do fluxo, com quem está parado, há quanto tempo está parado,
etc. Isso é importante para evitar que os erros sejam encontrados somente quando o processo é
concluído. Há também relatórios de fluxos concluídos, onde se pode ter uma noção geral de como se
desenvolveu o processo. Alguns softwares apresentam gráficos e relatórios com bastantes detalhes
dos processos.
A otimização tem crucial importância quando se trata de BPM. É essencial para que sejam feitas
melhorias nos processos de modo a alcançar resultados positivos mais rapidamente, melhorando o
serviço aos clientes e, possivelmente, com menores custos. Depende, obviamente, das etapas
anteriores, principalmente do controle, onde deve haver uma busca pela perfeição.5

2.2.2 Fluxograma
Diagrama que descreve a sequência de atividades de um processo empresarial através de uma
simbologia padronizada, utilizando retângulos para representar atividades, losangos para pontos de
decisão e setas para indicar o fluxo. Estes simbolos vêm acompanhado de textos explicativos.
Fácil de utilizar, mas pouco apropriado para representar processos de grande complexidade e
divergências.
O fluxograma considera o processo do ponto de vista da empresa.

2.2.3 Service blueprint

Técnica de mapeamenteo de serviços derivado do fluxograma que considera o aspecto de interação
com o cliente.
É um mapa de todas as transações que constituem o processo de entrega do serviço.
Divide-se em duas regiões separadas por uma linha, chamada de linha de visibilidade.
Na parte de cima da linha, é a área de evidências físicas percebida pelo cliente, as suas ações e
interações com os empregados. Na parte de baixo, encontram-se as ações dos empregados e os
processos de suporte que são invisíveis para o cliente.
As evidências físicas, mostradas na parte de cima, identificam elementos que o cliente pode usar como
indicador da qualidade do serviço. Cada conexão vertical através da linha de interação indica um ponto

5 http://pt.wikipedia.org/wiki/Gest%C3%A3o_de_processos_de_neg%C3%B3cio
20
 TI para concursos
de contato. Estes pontos funcionam como o “momento da verdade” de cada serviço e podem ser
usados como pontos de potencial falhas no sistema de serviço.

Fonte: http://www.lgti.ufsc.br/public/luciano.pdf
Apesar de ser mais evoluido do que os fluxogramas, também não consegue representar uma descrição
completa da experiência com o cliente. O foco está na tarefa e não no cliente.

2.2.4 Mapa do serviço

Forma visual de três elementos críticos de serviços: processso de entrega de serviço, os papéis dos
clientes e empregados e elementos visíveis de serviço. A criação do mapa requer a identificação de
evidências físicas do serviço, indicadores de qualidade, as pessoas envolvidas e o fluxo operacional de
atividades de entrega de serviços. Foca os serviços do ponto de vista do consumidor.
É uma evolução do service blueprint.
Logo acima da linha de visibilidade, há uma linha horizontal que indica o contato do cliente com os
empregados de atendimento. Abaixo da linha de visibilidade há outra que indica a relação entre o
suporte e o processso de entrega de serviço. Mais abaixo, outra linha separa a gerência do suporte.

O mapa pode ser lido horizontalmente para entender as ações ou passos realizados pelos clientes e
empregados, ou lido verticalmente para compreender as ações de suporte, os processos e estruturas.

2.2.5 IDEF
Família de métodos de estruturar e analisar uma empresa. Utilizam-se de diagramas para representar
os processos.

21
 TI para concursos
Cada tarefa é representada por um retângulo. Cada lado representa uma informação de entrada, saída
de produtos e/ou informações, recursos disponíveis e condições para ativação.
A ênfase não está na sequência, mas no conteúdo das atividades e nos recursos envolvidos no
processo. Exemplo:
Controle

Entradas Processo Saídas

Mecanismo

2.2.5.1 IDEF0
Método de modelagem funcional usado para processos associados a decisões, ações e atividades.

2.2.5.2 IDEF1
Método de modelagem de informação, para expressão dos requisitos de um sistema.

2.2.5.3 IDEF3
Método de captura da descrição do processo, que relaciona causa e efeito entre processos.

2.2.5.4 IDEF4
Método de desenho orientado a objeto, que auxilia no projeto de sistemas orientados a objetos.

2.2.5.5 IDEF5
Método de identificação de ontologias associadas aos processos e informações.

2.2.5.6 IDEF9
Método para auxiliar na identificação de restrições associadas a um sistema ou processo.

2.2.6 Estrutura de processamento de clientes

Modelo genérico de atividades-chave que são comuns à
maioria dos processos de serviços. Visa especificamente o
fluxo de clientes, indicando apenas atividades com eles.
São identificadas sete atividades-chave:
 seleção, cliente decide a escolha
 ponto de entrada, contato com a operação escolhida
 tempo de resposta, tempo de espera para que o sistema
responda
 ponto de impacto, cliente é atendido
 prestação de serviço, o serviço é prestado
 ponto de partida, o cliente sai do processo
 acompanhamento, atividades sobre o cliente após a
conclusão do serviço

2.2.7 Walk-through-audit
Método de auditoria, que consiste em uma série de questões dirigidas aos clientes, e gerentes de
serviços, para avaliação sistemática da visão do cliente sobre o serviço prestado.
Utilizam-se questões estruturadas que avaliam cada etapa do processo em uma escala de um a cinco,
respondidas durante ou imediatamente após o serviço, ou aplicadas em clientes da concorrência.

22
 TI para concursos
Além de avaliar a percepção do cliente, também permite analisar a lacuna entre a opinião do cliente e
da gerência e entre a empresa e a concorrência.
Funciona em conjunto com alguma outra técnica gráfica.

2.2.8 Análise da transação de serviço (STA – Service Transaction Analysis)

Método de avaliação do processo do ponto de vista do cliente, combinando quatro elementos: o
conceito do serviço, o processo do serviço, a avaliação da qualidade em cada transação e a
interpretação do serviço pelo cliente. Utiliza um formulário denominado “folha de análise da transação
de serviço”.
Pessoas fazendo papel de clientes caminham ao longo do processo para analisar como o cliente
poderia avaliar cada transação, usando uma mensagem curta e uma escala de três pontos: (-)
insatisfeito, (0) satisfeito ou (+) muito satisfeito.

2.3 Exercícios
23. (ICMS-SP 2009) No diagrama de fluxos de negócio (BPMN), para estabelecer "quem faz o que" devem ser
23
representados os fluxos de negócio agrupados em
(a) processes e tasks.
(b) events e gateways.
xx
(c) pools e lanes.
(d) pools e processes.
(e) lanes e tasks.
24. (ICMS-SP 2009) Na modelagem de processos de negócio (BPMN), NÃO se aplica um End Event no tipo de
24
trigger
(a) Exception.
(b) Link.
(c) Message.
(d) Multiple.
xx
(e) Timer.

23
 TI para concursos
25. (ICMS-SP 2009) Na modelagem de processos de negócio (BPMN), os Fluxos de Mensagem devem ser
25
desenhados
(a) entre white boxes.
xx
(b) entre black boxes.
(c) entre tasks.
(d) dentro de tasks.
(e) dentro de black boxes.

24
 TI para concursos

3 Gerência de Serviços de TI
A administração moderna de tecnologia de informação busca fundamentos em boas práticas de gerenciamento
alinhadas com objetivos do negócio.
Prática é uma maneira de trabalhar. Melhores práticas são atividades ou processos que tenham sido utilizados
com sucesso.
O conceito de Governança Tecnológica, do termo em inglês IT Governance, define que a TI é um fator essencial
para a gestão financeira e estratégica de uma organização. Governança Tecnológica é a metodologia (e seus
processos integrados) de gestão corporativa dos recursos de TI.6
A governança de TI trata da integração e uso de processos corporativos suportados pelos pacotes de gestão, por
exemplo: BI (Business Intelligence), CRM (Customer Relationship Management), ERP (Enterprise Resource
Planning) e SCM (Supply Chain Management).
De acordo com a ISO/IEC 38500, são seis princípios para governança de TI:7
 Responsabilidade – papéis e responsabilidades bem definidos na entrega de TI aos clientes e na
sua aquisição, e garantia de autoridade compatível para o exercício desses papéis.
 Estratégia – O desenvolvimento da estratégia de negócio considera a as capacidades atuais e
futuras de TI e o planejamento de TI busca atender às necessidades atuais e continuadas do
negócio da organização (alinhamento).
 Aquisições – As aquisições de TI são adequadamente motivadas por meio de análises apropriadas
e continuadas e de decisões claras e transparentes, de modo a garantir o alcance de equilíbrio
adequado entre benefícios, oportunidades, custos e riscos, tanto no curto como no longo prazo.
 Desempenho – A TI é estruturada para suportar adequadamente a organização e dispor serviços
com os níveis e com a qualidade necessários para responder aos requisitos atuais e futuros do
negócio.
 Conformidade – A TI está em conformidade com a legislação e regulamentos aplicáveis. As
políticas e as práticas estão claramente definidas, encontram-se implementadas e são aplicadas.
 Comportamento Humano – As políticas, práticas e decisões relativas ao uso e gestão da TI
consideram e respeitam o comportamento humano e incluem as necessidades atuais e a evolução
das necessidades de todas as pessoas envolvidas no processo.
ITIL é um framework, ou uma estrutura de gerência de serviços de TI. Em sua versão 2, o foco era a própria
prestação de serviços. Na versão 3, o ITIL mudou seu foco para a o alinhamento dos objetivos de serviços de TI
com os do negócio, mudando da abordagem operacional para uma visão mais estratégica do uso da tecnologia.
O COBIT é um guia de boas práticas para a gestão de tecnologia, não apenas serviços.

6 http://www.trainning.com.br/download/Apostila_ITIL_Cobit.pdf
7 http://www.geraldoloureiro.com/wiki/images/9/98/WGov_Palestra_ClaudioCruz.pdf
25
 TI para concursos

3.1 Fundamentos da ITIL V2

Estrutura abstrata (framework) de serviços de TI. Orienta o “como fazer” das funções do gerente de
tecnologia, dividindo estes serviços em dois grandes grupos – suporte a serviços e entrega de serviços
– unidos por uma central de atendimento (service desk).

3.1.1 Suporte a serviços

O suporte a serviços tem foco nos usuários da instituição, administrando incidentes, suas origens
(problema) e definindo formas de tratamento e de alterações necessárias para resolução.

3.1.1.1 Central de serviços (service desk)

Suporte de primeiro nível. Atendimento ao usuário.

3.1.1.2 Gerenciamento de incidentes (apaga incêndio)

Restaurar o serviço o mais rápido possível, para minimizar o impacto nos negócios e para garantir o
melhor nível de serviço, no tocante qualidade e disponibilidade.
Um incidente é um evento que não faz parte da operação padrão do serviço e que causa, ou poderá
causar uma interrupção, ou uma redução na qualidade do serviço.

3.1.1.3 Gerenciamento de problemas (desenvolvimento de soluções)

Buscar a causa raiz do incidente e sua conseqüente solução e prevenção.
Um Problema é um erro de causa desconhecida que pode causar um ou mais incidentes.
Um Problema poderá ser um Erro Conhecido (Known Error) quando a causa raiz (root cause) tornar
conhecida e uma Solução de Contorno (work-around) ou permanente for identificada e aplicada.
As soluções são registradas na gerência de configuração e as mudanças necessárias são requisitadas
à gerência de mudanças.

3.1.1.4 Gerenciamento de mudanças (implementação)

A partir de requisições de mudanças dos usuários ou do gerenciamento de problemas, implementa
mudanças aprovadas, de maneira eficiente, em um custo efetivo, com um mínimo risco à infra-estrutura
de TI existente e à nova.

3.1.1.5 Gerenciamento de liberação (implantação)

Libera e distribui a alteração autorizada. Implanta.
26
 TI para concursos
3.1.1.6 Gerenciamento de configuração (controle da infra-estrutura)
Gerenciar o banco de dados de todos os componentes necessários para fornecer serviços

3.1.2 Entrega de Serviço

A entrega de serviços volta-se para o cliente, preocupando-se em garantir uma qualidade ótima em
função da estratégia do negócio, além da efetividade do serviço prestado como resultado de uma
gestão de recursos tecnológicos (ativos) e financeiros.

3.1.2.1 Gerenciamento de nivel de serviço

A partir de um acordo do nível de serviço entre a TI e os usuários, contendo os requisitos do usuário,
gerencia a qualidade dos serviços oferecidos, procurando a maior qualidade em consonância com o
negócio da empresa.

3.1.2.2 Gerenciamento financeiro

Como JUSTIFICAR o orçamento? Necessidades da TI para o negócio planejados a partir dos
processos (Mudança, Nível, Capacidade e Disponibilidade) compõe o orçamento e acompanhamento
financeiro.

3.1.2.3 Gerenciamento de disponibilidade

Análise de riscos, oportunidades, satisfação, produtividade e tempo de manutenção e indisponibilidade.

3.1.2.4 Gerenciamento de capacidade

Confronto entre capacidade, demanda e satisfação do cliente. Taxa de utilização de recursos humanos
e sistemas.

3.1.2.5 Gerenciamento de continuidade de serviços de TI

Todo o esforço possível para evitar interrupções. Implementação de medidas preventivas, testes para
operar em ambientes de crise, redução do impacto dos incidentes, seguros.

27
 TI para concursos

3.2 Fundamentos de ITIL V38

O núcleo do ITIL V3 é composto de cinco processos baseados no ciclo de vida dos serviços:
 Estratégia do serviço (Service Strategy)
 Projeto de serviço ou Desenho de serviço (Service Design)
 Transição do serviço (Service Transition)
 Operação do serviço (Service Operation)
 Melhoria contínua do serviço (Continual Service Improvement)

Ilustração 4 Ciclo de vida do serviço - Núcleo do ITIL V3

3.2.1 Estratégia do serviço (Service Strategy)

Como ponto de origem do ciclo de vida de serviço ITIL, estratégia do serviço orienta sobre como tornar
mais claro e priorizar investimentos sobre provimento de serviços, desenhar, desenvolver e
implementar o gerenciamento de serviços.
Processos:
 geração de estratégia,
 gerenciamento de portfólio de serviços,
 gerenciamento de demandas,
 gerenciamento financeiro de TI.

3.2.2 Desenho de serviço (Service Design)

O desenho de serviço fornece orientações para o desenvolvimento de serviços e processos de
gerenciamento de serviços, incluindo mudanças e melhorias para aumentar ou manter o valor, para a
continuidade dos serviços, para o atingimento de níveis de serviço e para a conformidade às normas.
O trabalho de projetar um serviço de TI é agregado em pacote de projeto de serviços (Service Design
Package - SDP).
Processos de gerenciamento de:
 nível de serviço (Service Level Management - SLM)
 disponibilidade

8 http://pt.wikipedia.org/wiki/ITILv3
28
 TI para concursos
 capacidade
 continuidade de serviços
 segurança da informação
 fornecedores
 catálogo de serviços.

3.2.3 Transição do serviço (Service Transition)

Este volume é direcionado à entrega dos serviços necessários ao negócio no uso operacional, e
geralmente englobam o "projeto".
Processos:
 Planejamento de transição e suporte
 Avaliação
 Teste e validação
 Gerenciamento de configurações e ativos de serviço
 Gerenciamento de liberação e implantação (release and deployment)
 Gerenciamento de mudança (Change Management)
 Gerenciamento de conhecimento

3.2.4 Operação do serviço (Service Operation)

Parte do ciclo de vida onde serviços e valor são entregues diretamente. Assim, monitoramento de
problema e balanceamento entre disponibilidade de serviço e custo são considerados.
Processos:
 Cumprimento de requisição.
 Gerenciamento de eventos.
 Gerenciamento de incidentes.
 Gerenciamento de problemas.
 Gerenciamento de acesso, (service desk).
Funções:
 Central de serviços
 Gerenciamento técnico
 Gerenciamento de aplicativos
 Gerenciamento de operações de TI

3.2.5 Melhoria de serviço continuada (Continual Service Improvement)

A meta do CSI é ajustar e reajustar serviços de TI às mudanças contínuas do negócio através da
identificação e implementação de melhorias aos serviços de TI que apoiam processos negociais.
Utiliza um sistema cíclico de revisão baseado no modelo PDCA (Plan Do, Check and Act).
Processos:
 Medição de serviço
 Relato de serviço
 Sete passos de melhoria

3.3 Fundamentos de COBIT

O COBIT – Control Objectives for Information and Related Technology, tem por missão explícita
pesquisar, desenvolver, publicar e promover um conjunto atualizado de padrões internacionais de boas
práticas referentes ao uso corporativo da TI para os gerentes e auditores de tecnologia.
A metodologia COBIT foi criada pelo ISACA – Information Systems Audit and Control Association
através do IT Governance Institute, organização independente que desenvolveu a metodologia
considerada a base da governança tecnológica. O COBIT funciona como uma entidade de
padronização e estabelece métodos documentados para nortear a área de tecnologia das empresas,
incluindo qualidade de software, níveis de maturidade e segurança da informação.

29
 TI para concursos
Os documentos do COBIT definem Governança Tecnológica como sendo uma estrutura de
relacionamentos entre processos para direcionar e controlar uma empresa de modo a atingir objetivos
corporativos, através da agregação de valor e risco controlado pelo uso da tecnologia da informação e
de seus processos”.
COBIT é um guia de boas práticas, que podem servir como um modelo de referência para gestão da TI.
Inclui um sumário executivo, um "framework", controle de objetivos, mapas de auditoria, ferramentas
para a sua implementação e um guia com técnicas de gerenciamento.
Os domínios do COBIT são integrados da seguinte forma:
 A informação de uma empresa é gerada/modificada pelas atividades de TI.
 Esta informação é requisito para o domínio de Planejamento e Organização (PO).
 Os requisitos de saída do PO são requisitos de entrada de informação para o domínio de
Aquisição e Implementação (AI),
 As saídas de AI definem os requisitos de entrada para o domínio de Entrega e Suporte (DS).
 O domínio de Monitoração (M) utiliza as informações do DS nos seus processos e atividades
relacionadas.
Os requisitos da informação são dados por: efetividade, eficiência, confidencialidade, integridade,
disponibilidade, conformidade e confiabilidade.
Os recursos de TI são classificados como: pessoas, sistemas aplicativos, tecnologia, infraestrutura e
dados.
COBIT cobre os quatro domínios, os quais possuem 34 processos (dois objetivos de controle para cada
processo).

3.3.1 Planejar e Organizar

Uso de informação e tecnologia e como isso pode ser usado para que a empresa atinja seus objetivos
e metas. A forma organizacional e a infra-estrutura da TI deve ser considerada.
 PO1 Definir um Plano Estratégico de TI e Orientações
 PO2 Definir a Arquitetura de Informação
 PO3 Determinar o Gerenciamento Tecnológico
 PO4 Definir os Processos de TI, Organização e Relacionamentos
 PO5 Gerenciar o Investimento em TI
 PO6 Comunicar os Objetivos de Gerenciamento e Orientar
 PO7 Gerenciar os Recusos Humanos de TI
 PO8 Gerenciar a Qualidade
 PO9 Estimar e Gerenciar os Riscos de TI
 PO10 Gerenciar Projetos

3.3.2 Adquirir e Implementar

Requisitos de TI, aquisição de tecnologia e implementação dentro dos processos de negócios da
companhia.
Desenvolvimento do plano de manutenção que a companhia adota para prolongar a vida do sistema de
TI e seus componentes.
 AI1 Identificar Soluções Automatizadas
 AI2 Adquirir e Manter Software de Aplicação
 AI3 Adquirir e Manter Infraestrutura de Tecnologia
 AI4 Habilitar Operação e Uso
 AI5 Obter Recursos de TI
 AI6 Gerenciar Mudanças
 AI7 Instalar e Credenciar Soluções e Mudanças

3.3.3 Entregar e Dar Suporte

Entrega de tecnologia da informação. Cobre a execução de aplicações dentro do sistema de TI e seus
resultados, assim como o suporte dos processos, que incluem questões de segurança e treinamento e
habilitam a execução.

30
 TI para concursos
 DS1 Definir e Gerenciar Níveis de Serviço
 DS2 Gerenciar Serviços de Terceiros
 DS3 Gerenciar Performance e Capacidade
 DS4 Assegurar Serviço Contínuo
 DS5 Assegurar Segurança de Sistema
 DS6 Identificar e Alocar Recursos
 DS7 Treinar Usuários
 DS8 Gerenciar Serviços de Escritório e Incidentes
 DS9 Gerenciar a Configuração
 DS10 Gerenciar Problemas
 DS11 Gerenciar Dados
 DS12 Gerenciar o Ambiente Físico
 DS13 Gerenciar Operações

3.3.4 Monitorar e Avaliar

Estimativa estratégica das necessidades da companhia. Avalia se o atual sistema de TI atinge os
objetivos para o qual ele foi especificado e controla os requisitos para atender objetivos regulatórios.
Estimativa e capacidade de atingir os objetivos de negócio, controlando os processos internos da
companhia através de auditores internos e externos.
 M1 Monitorar os processos
 M2 Assegurar avaliação dos controles internos
 M3 Obter avaliação independente
 M4 Prover auditoria independente

3.4 Exercícios
26. (ICMS-SP 2009) NÃO se trata de elemento que deve ser considerado como parte do controle de mudanças
26
no gerenciamento de configuração:
xx
(a) revisões e auditoria das mudanças.
(b) confiabilidade das instalações das modificações.
(c) análise de impacto de mudanças.
(d) conjunto de modificações.
(e) pedido de modificações.
27. (ICMS-SP 2009) A rastreabilidade ou a história das mudanças de cada software, incluindo quem fez o que,
por que e quando, pode ser realizada no gerenciamento de configuração de software por meio do seu
27
componente:
(a) Acordo de nível de serviço.
(b) Configuração da construção.
(c) Identificação do item de software.
xx
(d) Controle de versão.
(e) Controle de mudanças.
28
28. (ICMS-SP 2009) Os objetivos de controle detalhados do COBIT estão diretamente associados
(a) aos domínios de governança.
(b) aos processos de TI.
xx
(c) às atividades de TI.
(d) aos recursos de TI.
(e) aos critérios de informação.
29
29. (ICMS-SP 2009) O processo Gerenciamento de Configurações está definido no COBIT dentro do domínio
(a) Monitoração & Avaliação.
(b) Verificação & Controle.
(c) Aquisição & Implementação.
(d) Planejamento & Organização.
xx
(e) Entrega & Suporte.
30
30. (ICMS-SP 2009) NÃO se trata de um princípio de governança de TI:
(a) Responsabilidade corporativa.
xx
(b) Objetivos do negócio.
(c) Prestação de contas.
(d) Transparência.
(e) Equidade.

31
 TI para concursos
31
31. Gerenciar Projetos, segundo o COBIT, é um processo de TI pertencente ao domínio de
xx
(a) Planejamento e Organização.
(b) Planejamento e Controle.
(c) Aquisição e Implementação.
(d) Entrega e Suporte.
(e) Monitoração e Controle.
32
32. (ICMS-SP 2009) No gerenciamento de serviços de TI, segundo o ITIL v.2, tem foco operacional o processo:
xx
(a) configuration management.
(b) capacity management.
(c) availability management.
(d) service level management.
(e) customer relationship management.
33. (ICMS-SP 2009) No gerenciamento de serviços de TI, segundo o ITIL v.2, tem foco tático ou estratégico o
33
processo:
(a) problem management.
(b) incident management.
(c) release management.
xx
(d) continuity management.
(e) change management.
34. (ICMS-SP 2009) O processo de gerenciamento de serviços Service Desk, segundo o ITIL v.2, NÃO
34
gerencia
(a) os contatos entre o provedor de serviços e os usuários.
(b) a comunicação com os usuários.
(c) os incidentes nos serviços.
xx
(d) os acordos de serviços.
(e) as requisições de serviços.
35. O processo de Gerenciamento de Problemas, segundo o ITIL, deve ser executado no estágio do ciclo de vida
35
de serviços denominado
(a) estratégia de serviços.
(b) projeto de serviços.
(c) transição de serviços.
xx
(d) operação de serviços.
(e) melhoria contínua de serviços.

32
 TI para concursos

4 Engenharia de Software
Engenharias da sistemas é um campo interdisciplinar da engenharia que foca no desenvolvimento e
organização de sistemas artificiais complexos. As técnicas de Engenharia de Sistemas podem ser
utilizadas em desenvolvimento de softwares.
Engenharia de produção é o ramo da engenharia que dedica-se à concepção, melhoria e
implementação de sistemas que envolvem pessoas, materiais, informações, equipamentos, energia e
maior de conhecimentos e habilidades, para especificar, prever e avaliar os resultados obtidos por tais
sistemas.
A Engenharia de processos é um ramo da engenharia que se preocupa, entre outras coisas, em
elaborar e executar projetos e estudos de formas de aproveitamento de mão-de-obra, máquinas e
equipamentos, para melhorar processos, para o aumento da qualidade do produto, redução de perdas
e maior produtividade.
Neste contexto, a engenharia de software aproveita diversas técnicas de engenharia de sistemas, de
produto e de processos para a produção de aplicativos com maior eficiência e eficácia.
Nos anos 40, grande parte dos esforços e custos era concentrada no desenvolvimento do hardware.
À medida que a tecnologia de hardware foi sendo dominada, as preocupações se voltaram, no início
dos anos 50, para o desenvolvimento dos sistemas operacionais e de linguagens de programação de
alto nível, como FORTRAN e COBOL.
No início dos anos 60, com o surgimento dos sistemas operacionais com características de
multiprogramação, a eficiência e utilidade dos sistemas computacionais tiveram um considerável
crescimento, surgindo a necessidade de desenvolver grandes sistemas de software em substituição
aos pequenos programas aplicativos utilizados até então.
Desta necessidade, surgiu um problema chamado de “crise do software”, que permitiu o nascimento do
termo “Engenharia de Software”.
Atualmente, o custo de desenvolvimento de software corresponde a uma percentagem cada vez maior
no custo global de um sistema informatizado.
A principal razão para isto é que a tecnologia de desenvolvimento de software implica em grande carga
de trabalho, envolvendo muitas pessoas num prazo relativamente longo de desenvolvimento.

4.1 Software9
Software é um conjunto de instruções, estruturas de dados e documentação destinados a resolver um
problema.
Em Engenharia de Software, o software deve ser visto como um produto a ser “vendido”.
Em sistemas simples, onde o usuário é o próprio autor, a documentação é pequena ou inexistente e a
preocupação com a existência de erros de execução não é um fator muito relevante, pode não haver
grandes dificuldades na detecção e correção de falhas, nem preocupação como a portabilidade, a
flexibilidade e a possibilidade de reutilização.
Um produto de software é destinado ao uso por pessoas outras que os seus programadores, a sua
interface é importante, reforçada com uma documentação rica em informações para que todos os
recursos oferecidos possam ser explorados de forma eficiente.
Produtos de software devem passar normalmente por uma exaustiva bateria de testes, dado que os
usuários não estarão de detectar e corrigir os eventuais erros de execução.
 o software é concebido e desenvolvido como resultado de um trabalho de engenharia e não
manufaturado no sentido clássico;
 o software não se desgasta, não aumenta a possibilidade de falhas à medida que o tempo passa;
 a maioria dos produtos de software é concebida inteiramente sob medida, sem a utilização de
componentes pré-existentes.
Em função destas características diferenciais, o processo de desenvolvimento de software pode
desembocar um conjunto de problemas, os quais terão influência direta na qualidade do produto.
O processo de desenvolvimento de software procura responder:

9 http://jalvesnicacio.files.wordpress.com/2010/03/engenharia-de-software.pdf
33
 TI para concursos
 por que o software demora tanto para ser concluído?
 por que os custos de produção têm sido tão elevados?
 por que não é possível detectar todos os erros antes que o software seja entregue ao cliente?
 por que é tão difícil medir o progresso durante o processo de desenvolvimento de software?

4.2 Ciclo de vida do software

O ciclo de vida de um software descreve as fases pelas quais o software passa desde a sua concepção
até ficar sem uso algum.10
Quatro fases que são delimitadas por eventos típicos em diversos ciclos de vida. Cada fase inclui um
conjunto de atividades ou disciplinas que devem ser realizadas pelas partes envolvidas.
 Definição
 Desenvolvimento
 Operação
 Retirada

4.2.1 Fase de Definição

A fase de definição do software ocorre em conjunto com outras atividades como a modelagem de
processos de negócios e análise de sistemas. Nesta atividade, diversos profissionais buscam o
conhecimento da situação atual e a identificação de problemas para que possam elaborar propostas de
solução de sistemas computacionais que resolvam tais problemas. Dentre as propostas apresentadas,
deve-se fazer um estudo de viabilidade, incluindo análise custo-benefício, para se decidir qual solução
será a escolhida.
O resultado desta atividade deve incluir a decisão da aquisição ou desenvolvimento do sistema,
indicando informações sobre hardware, software, pessoal, procedimentos, informação e documentação.
Caso seja decidido pelo desenvolvimento do sistema, no escopo da engenharia de software, é
necessário elaborar o documento de proposta de desenvolvimento de software. Esse documento pode
ser a base de um contrato de desenvolvimento.
Profissionais de engenharia de software atuam nesta atividade com o objetivo de identificar os
requisitos de software e modelos de domínio que serão utilizados na fase de desenvolvimento. Os
requisitos são também fundamentais para que o engenheiro possa elaborar um plano de
desenvolvimento de software, indicando em detalhes os recursos necessários (humanos e materiais),
bem como as estimativas de prazos e custos (cronograma e orçamento).
Não existe um consenso sobre o que caracteriza o final da fase de definição. Isto varia de acordo com
o modelo de processo adotado. Em algumas propostas, a fase de definição é considerada concluída
com a apresentação da proposta de desenvolvimento apenas. Outros modelos de processo, considera
que o software apenas está completamente definido com a especificação de requisitos e com a
elaboração do plano de desenvolvimento de software.
De acordo com o modelo de processo adotado, pode-se iniciar atividades da fase de desenvolvimento
mesmo que a fase de definição não esteja completamente concluída.

4.2.2 Fase de Desenvolvimento

A fase de desenvolvimento ou de produção do software inclui todas as atividades que tem por objetivo
a construção do produto. Ela inclui principalmente o design, a implementação e a verificação e
validação do software.

4.2.2.1 Design
A atividade de design compreende todo o esforço de concepção e modelagem que têm por objetivo
descrever como o software será implementado. O design inclui:
 Design conceitual
 Design da interface de usuário
 Design da arquitetura do software
 Design dos algoritmos e estruturas de dados

10 http://engenhariadesoftware.blogspot.com/2007/02/ciclo-de-vida-do-software-parte-1.html
34
 TI para concursos
O design conceitual envolve a elaboração das idéias e conceitos básicos que determinam os elementos
fundamentais do software em questão. Por exemplo, um software de correio eletrônico tradicional inclui
os conceitos: mensagem, caixa de entrada, caixa de saída, etc. A mensagem, por sua vez, inclui os
conceitos de para, cc, bcc, assunto, corpo, etc. Embora seja um design adotado pela maioria dos
software, novos modelos conceituais podem vir a ser adotados. O conceito de conversação do Gmail é
um exemplo.
O design conceitual exerce influência na interface de usuário e na arquitetura do software.
O design da interface de usuário envolve a elaboração da maneira como o usuário pode interagir para
realizar suas tarefas, a escolha dos objetos de interfaces (botões, menus, caixas de texto, etc.), o
layout de janelas e telas, etc. A interface deve garantir a boa usabilidade do software e é um
fundamental fator de sucesso do software.
O design de arquitetura de software deve elaborar uma visão macroscópica do software em termos de
componentes que interagem entre si. O conceito de componente em arquitetura varia de acordo com a
visão arquitetônica adotada. São exemplos de visões arquitetônicas, a visão conceitual, visão de
módulos, visão de código e visão de execução.
Na visão conceitual, os componentes de software são derivados do design conceitual. Estes
componentes são abstrações que devem definir outros elementos menos abstratos. Exemplos são
arquiteturas cliente-servidor e arquitetura em camadas. Na visão de código, deve-se determinar como
as classes e/ou funções estão organizadas e interagindo entre si. Estas classes implementam os
componentes abstratos ou conceituais. Na visão de módulos, deve-se determinar quais são os módulos
que serão utilizados na implementação e como eles organizam as classes e/ou funções. Na visão de
execução, a arquitetura deve descrever os diferentes processos que são ativados durante a execução
do software e como eles interagem entre si. Enquanto as anteriores oferecem uma visão estática, esta
é uma visão dinâmica do software.
O design de algoritmos e estrutura de dados, também conhecido como design detalhado, visa
determinar, de maneira independente da linguagem de programação adotada, as soluções algorítmicas
e as estruturas de dados associados. Deve-se decidir, por exemplo, como as informações podem ser
ordenadas (algoritmo de bolha ou quicksort) e em qual tipo de estrutura de dados (array, lista
encadeada) elas vão ser armazenados.

4.2.2.2 Implementação
A implementação envolve as atividades de codificação, compilação, integração e testes. A codificação
visa traduzir o design num programa, utilizando linguagens e ferramentas adequadas. A codificação
deve refletir a estrutura e o comportamento descrito no design. Os componentes arquiteturais devem
ser codificados de forma independente e depois integrados. Os testes podem ser iniciados durante a
fase de implementação. A depuração de erros ocorre durante a programação utilizando algumas
técnicas e ferramentas. É fundamental um controle e gerenciamento de versões para que se tenha um
controle correto de tudo o que está sendo codificado.

4.2.2.3 Verificação e validação

Verificação e validação destinam-se a mostrar que o sistema está de acordo com a especificação e que
ele atende às expectativas de clientes e usuários. A validação visa assegurar se o programa está
fazendo aquilo que foi definido na sua especificação (fazendo a coisa certa). A verificação visa verificar
se o programa está correto, isto é, não possui erros de execução (fazendo certo a coisa). Existem
diferentes formas de verificação e validação. Inspeção analítica e revisão de modelos, documentos e
código fonte são formas que podem ser usadas antes mesmo que o programa seja completamente
codificado. Os testes de correção, desempenho, confiabilidade, robustez, usabilidade, dentre outros,
visam avaliar diversos fatores de qualidade a partir da execução do software. Diferentes técnicas de
testes podem ser aplicadas para cada um destes fatores.

4.2.3 Fase de Operação

A fase de operação envolve diferentes tipos de atividades:
 Distribuição e entrega
 Instalação e configuração
 Utilização
 Manutenção

35
 TI para concursos
A distribuição e entrega pode ser feita diretamente pelo desenvolvedor (em caso de software
personalizado), ou em um pacote a ser vendido em prateleiras de lojas ou para ser baixado pela
Internet (em caso de software genéricos).
O processo de instalação e configuração, normalmente, pode ser feito com a ajuda de software de
instalação disponibilizados pelos fabricantes dos ambientes operacionais.
A atividade de utilização é o objeto do desenvolvimento do software. A qualidade da utilização é a
usabilidade do software.
A manutenção normalmente ocorre de duas formas: corretiva e evolutiva. A manutenção corretiva visa
a resolução de problemas referentes a qualidade do software (falhas, baixo desempenho, baixa
usabilidade, falta de confiabilidade etc.). A manutenção evolutiva ou adaptativa visa a produção de
novas versões do software de forma a atender a novos requisitos dos clientes, ou adaptar-se às novas
tecnologias que surgem (hardware, plataformas operacionais, linguagens, etc). Mudanças no domínio
de aplicação implicam em novos requisitos e incorporação de novas funcionalidades. Surgimento de
novas tecnologias de software e hardware e mudanças para uma plataforma mais avançada também
requerem evolução.

4.2.4 Fase de retirada

A fase retirada é um grande desafio para os tempos atuais. Diversos software que estão em
funcionamento em empresas possuem excelente níveis de confiabilidade e de correção. No entanto,
eles precisam evoluir para novas plataformas operacionais ou para a incorporação de novos requisitos.
A retirada desses software legados em uma empresa é sempre uma decisão difícil: como abrir mão
daquilo que é confiável e ao qual os funcionários estão acostumados, após anos de treinamento e
utilização?
Processos de reengenharia podem ser aplicados para viabilizar a transição ou migração de um
software legado para um novo software de forma a proporcionar uma retirada mais suave.

4.3 Metodologias de desenvolvimento de software.

4.3.1 Modelo caótico11

O produto é construído sem qualquer especificação ou projeto. O
produto é retrabalhado quantas vezes forem necessárias para
satisfazer o cliente. Este modelo pode funcionar razoavelmente
para micro projetos (até 400 homens.hora). No entanto para
projetos maiores ele é inadequado.

4.3.2 Modelo Cascata

Recomendado para sistemas onde a segurança e a confiabilidade tem grande importância.
Orientado para documentação, que abrange representações gráficas e simulações, e com uma
abordagem disciplinada, a cada fase são feitos procedimentos de verificação e validação (incluindo
testes), são liberadas definições da documentação e todos produtos são formalmente revisados.
Uma vez definido o modelo de ciclo de desenvolvimento, existem três abordagens para implementá-lo
 Cascata Pura
 Incremental
 Evolucionária

4.3.2.1 Abordagem Cascata Pura

Todas as fases do ciclo de desenvolvimento são executadas em sequência. As fases anteriores são
revisitadas para correções de erros ou para adaptações. Esta abordagem é adequada quando :
 existe um conjunto de Requisitos do Usuário estáveis e de alta qualidade
 a duração do projeto é pequena
 o sistema completo deve estar disponível de um única vez

11 http://www2.dem.inpe.br/ijar/CicoloVidaSoftPrado.html
36
 TI para concursos
4.3.2.2 Abordagem Incremental
Nesta abordagem o desenvolvedor executa múltiplas fases de PD, TR e OM. Dentro desta abordagem
está a abordagem cascata.
A abordagem incremental é adequada quando:
 a liberação do software deve estar de acordo com um conjunto de prioridades definidas nos
Requisitos do Usuário
 é necessário melhorar a eficiência da integração do software com outra partes de um sistema
maior
 são requeridas antecipadamente evidências de que o produto será aceito

 RU – Requisitos do usuário
 RS – Requisitos do software
 PA – Projeto da arquitetura
 PD – Projeto detalhado
 TR – Treinamento
 OM – Operação e Manutenção

4.3.2.3 Abordagem Evolucionária

Nesta abordagem, o desenvolvimento é formado por múltiplos ciclos da abordagem cascata pura,
ocorrendo sobreposição das fases da operação e manutenção do sistema anterior com o novo
desenvolvimento. Esta abordagem é adequada quando:
 é necessário alguma experiência do usuário para refinar e
completar requisitos
 algumas partes da implementação podem depender da existência
de tecnologia ainda não disponível
 existem requisitos do usuário não bem conhecidos
 alguns requisitos são muito mais difíceis de serem implementados
do que outros, decidindo-se não implementá-lo para não atrasar o
projeto

4.3.2.4 Modelo Espiral

Modelo em cascata onde cada fase é precedida

por uma análise de risco e sua execução é feita
evolucionariamente (ou incrementalmente).
A dimensão radial representa o custo acumulado
atualizado e a dimensão angular representa o
progresso através da espiral. Cada setor da espiral
corresponde a uma tarefa (fase)do
desenvolvimento.
Um ciclo se inicia com a tarefa "Determinação de
objetivos, alternativas e restrições", onde ocorre o
comprometimento dos envolvidos e o
estabelecimento de uma estratégia para alcançar
os objetivos.
Na tarefa "Avaliação de alternativas, identificação e
solução de riscos", executa-se uma análise de risco. Prototipação é uma boa ferramenta para tratar
riscos. Se o risco for considerado inaceitável, pode parar o projeto.
Na terceira tarefa ocorre o desenvolvimento do produto. Neste quadrante pode-se considerar o modelo
cascata.
Na quarta tarefa o produto é avaliado e se prepara para iniciar um novo ciclo.
Variações do modelo espiral consideram entre três e seis tarefas ou setores da espiral. Por exemplo, as
regiões:
37
 TI para concursos
 comunicação com o cliente
 planejamento
 análise de risco
 engenharia
 construção e liberação
 avaliação do cliente

4.4 Desenvolvimento ágil12

Desenvolvimento ágil de software (do inglês Agile software development) ou Método ágil é um conjunto
de metodologias de desenvolvimento de software. O desenvolvimento ágil, tal como qualquer
metodologia de software, providencia uma estrutura conceitual para reger projetos de engenharia de
software.
Existem inúmeros frameworks de processos para desenvolvimento de software. A maioria dos métodos
ágeis tenta minimizar o risco pelo desenvolvimento do software em curtos períodos, chamados de
iteração, os quais gastam tipicamente menos de uma semana a até quatro. Cada iteração é como um
projecto de software em miniatura de seu próprio, e inclui todas as tarefas necessárias para implantar o
mini-incremento da nova funcionalidade: planejamento, análise de requisitos, projeto, codificação, teste
e documentação. Enquanto em um processo convencional, cada iteração não está necessariamente
focada em adicionar um novo conjunto significativo de funcionalidades, um projecto de software ágil
busca a capacidade de implantar uma nova versão do software ao fim de cada iteração, etapa a qual a
equipe responsável reavalia as prioridades do projecto.
Métodos ágeis enfatizam comunicações em tempo real, preferencialmente face a face, a documentos
escritos. A maioria dos componentes de um grupo ágil deve estar agrupada em uma sala. Isso inclui
todas as pessoas necessárias para terminar o software: no mínimo, os programadores e seus clientes
(clientes são as pessoas que definem o produto, eles podem ser os gerentes, analistas de negócio, ou
realmente os clientes). Nesta sala devem também se encontrar os testadores, projectistas de iteração,
redactores técnicos e gerentes.
Métodos ágeis também enfatizam trabalho no software como uma medida primária de progresso.
Combinado com a comunicação face-a-face, métodos ágeis produzem pouca documentação em
relação a outros métodos, sendo este um dos pontos que podem ser considerados negativos. É
recomendada a produção de documentação que realmente será útil.
Os princípios do desenvolvimento ágil valorizam:
 Garantir a satisfação do consumidor entregando rapidamente e continuamente softwares
funcionais;
 Softwares funcionais são entregues frequentemente (semanas, ao invés de meses);
 Softwares funcionais são a principal medida de progresso do projecto;
 Até mesmo mudanças tardias de escopo no projecto são bem-vindas.
 Cooperação constante entre pessoas que entendem do negócio e desenvolvedores;
 Projetos surgem através de indivíduos motivados, entre os quais existe relação de confiança.
 Design do software deve prezar pela excelência técnica;
 Simplicidade;
 Rápida adaptação às mudanças;
 Indivíduos e interações mais do que processos e ferramentas;
 Software funcional mais do que documentação extensa;
 Colaboração com clientes mais do que negociação de contratos;
 Responder a mudanças mais do que seguir um plano.
A maioria dos métodos ágeis compartilha a ênfase no Desenvolvimento iterativo e incremental para a
construção de versões implantadas do software em curtos períodos de tempo. Métodos ágeis diferem
dos métodos iterativos porque seus períodos de tempo são medidos em semanas, ao invés de meses,
e a realização é efetuada de uma maneira altamente colaborativa. estendendo-se a tudo.
Algumas equipes ágeis usam o modelo em cascata em pequena escala, repetindo o ciclo de cascata
inteiro em cada iteração. Outras equipes, mais especificamente as equipes de Programação extrema,
trabalham com atividades simultaneamente.

12 http://pt.wikipedia.org/wiki/Desenvolvimento_Ágil_de_software
38
 TI para concursos
A codificação cowboy, também chamada de Modelo Balbúrdia, é a ausência de metodologias de
desenvolvimento de Software: os membros da equipe fazem o que eles sentem que é correto. Como os
desenvolvedores que utilizam métodos ágeis freqüentemente reavaliam os planos, enfatizam a
comunicação face a face e fazem o uso relativamente esparso de documentos, ocasionalmente levam
as pessoas a confundirem isto com codificação cowboy. Equipes ágeis, contudo, seguem o processo
definido (e freqüentemente de forma disciplinada e rigorosa).
Como em todas as metodologias, o conhecimento e a experiência dos usuários definem o grau de
sucesso e/ou fracasso de cada atividade. Os controles mais rígidos e sistematizados aplicados em um
processo implicam altos níveis de responsabilidade para os usuários. A degradação de procedimentos
bem-intencionados e organizados pode levar as atividades a serem caracterizadas como codificação
cowboy.
De uma perspectiva organizacional, a aplicabilidade pode ser expressa examinando três dimensões
chaves da organização: cultura, pessoal e comunicação. Em relação a estas áreas inúmeros fatores
chave do sucesso podem ser identificados (Cohen et al., 2004):[2]
 A cultura da organização deve apoiar a negociação.
 As pessoas devem ser confiantes.
 Poucas pessoas, mas competentes.
 A organização deve promover as decisões que os desenvolvedores tomam.
 A Organização necessita ter um ambiente que facilite a rápida comunicação entre os membros.
O fator mais importante é provavelmente o tamanho do projeto. Com o aumento do tamanho, a
comunicação face a face se torna mais difícil. Portanto, métodos ágeis são mais adequados para
projetos com pequenos times, com no máximo de 20 a 40 pessoas.
Ambiente ideal para o desenvolvimento ágil:
 Baixa criticidade
 Desenvolvedores senior
 Mudanças freqüente de requisitos
 Pequeno número de desenvolvedores
 Cultura que tem sucesso no caos.
Ambiente ideal para o desenvolvimento direcionado ao planejamento:
 Alta criticidade
 Desenvolvedores Junior
 Baixa mudança nos requisitos
 Grande número de desenvolvedores
 Cultura que procura a ordem.

4.5 Planejamento e avaliação de iterações

Uma iteração é um período de tempo definido dentro de um projeto em que você produz uma versão
estável e executável do produto, junto com toda a documentação de apoio, scripts de instalação e
similares, necessários para usar a liberação. É também conhecida como ciclo ou tempo definido.
A finalidade das iterações é produzir um executável que possa ser avaliado de forma que você possa
obter feedback e fazer correções de rumo. Este executável lhe coloca uma etapa mais perto do produto
final. As fases fornecem um foco para a equipe chegar a um determinado objetivo da gerência. O
OpenUP tem quatro fases, cada uma terminando com respostas a perguntas específicas:
 Concepção - Nós concordamos com o problema que estamos tentando resolver?
 Elaboração - Nós concordamos com toda a solução, e compreendemos os riscos, custos e
cronograma razoavelmente bem?
 Construção - Nós concordamos que temos um sistema que atende às principais necessidades dos
stakeholders?
 Transição - Nós concordamos que podemos liberar o sistema e terminar o projeto?
Em cada fase, você pode ter uma ou várias iterações, onde cada uma visa produzir os resultados
necessários para responder a estas perguntas. Por exemplo, para responder à pergunta da
Elaboração, nós necessitamos implementar e testar alguns aspectos chaves do sistema de modo que
possamos compreender qual arquitetura é necessária, que componentes comerciais (COTS)
necessitaremos, quais os principais riscos que enfrentamos e como direcioná-los, qual a eficácia da

39
 TI para concursos
equipe etc. Estas necessidades irão orientar a atribuição das prioridades ao que deve ser feito em uma
iteração de Elaboração.
Uma das principais vantagens da abordagem iterativa em relação à abordagem em cascata é o fato de
as iterações fornecerem marcos naturais para avaliar o progresso e os riscos prováveis. Na iteração, a
avaliação do progresso e do risco deverá continuar (se realizada informalmente) para garantir que as
dificuldades não desviem o projeto.
A Avaliação de Iteração captura o resultado de uma iteração, até que ponto os critérios de avaliação
foram respeitados e as mudanças que devem ser feitas.
Cada iteração é concluída por uma Avaliação de Iteração, na qual a organização de desenvolvimento
para para refletir sobre o que aconteceu, o que foi ou não alcançado e por quê, e as lições aprendidas.
Essa avaliação é uma etapa decisiva em uma iteração e não deve ser ignorada. Se a Avaliação de
Iteração não for feita corretamente, muitos dos benefícios oferecidos por uma abordagem iterativa
poderão se perder.
Algumas vezes, o procedimento correto nesta etapa é rever os critérios de avaliação, em vez de
retrabalhar o sistema. Às vezes, a vantagem da Avaliação de Iteração está em revelar que um
determinado requisito não é importante, é muito caro para ser implementado ou cria uma arquitetura
que não pode ser mantida. Nesses casos, uma análise de custo e benefício deve ser feita e uma
decisão de negócios deve ser tomada.
A métrica deve ser usada como base dessa avaliação.
Quase no final de cada iteração, a equipe central do projeto deverá se reunir para avaliar a iteração,
enfatizando o seguinte:
 A iteração obteve êxito no cumprimento de suas metas?
 Os riscos foram reduzidos ou eliminados?
 O release cumpriu suas metas de funcionalidade, qualidade, desempenho e capacidade?
 São necessárias mudanças no projeto e nos planos de iteração futuros?
 Alguma das descobertas capturadas no artefato, na avaliação da organização de desenvolvimento,
foi invalidada pelas mudanças durante a iteração e, como conseqüência, exige mudanças em outros
artefatos?
 Houve alguma dificuldade no processo de desenvolvimento durante a iteração?
 Que parte do release atual servirá como baseline? Sofrerá retrabalho?
 Novos riscos foram identificados?
 Houve mudanças externas (mudanças no mercado, na comunidade de usuários ou nos requisitos)?
Avalie os resultados da iteração com relação aos critérios de avaliação que foram estabelecidos para o
plano de iteração: funcionalidade, desempenho, capacidade, medidas de qualidade.
Use as métricas obtidas nas atividades de teste e no passo coletar métricas como a base da avaliação,
quando disponíveis, para quantificá-la. As medidas qualitativas são adequadas para a fase de iniciação
e talvez para a iteração inicial, enquanto as fases posteriores de elaboração, construção e transição
devem depender de medições de teste específicas para avaliar a qualidade, o desempenho, a
capacidade etc. Aborde outros problemas pendentes que foram capturados nas avaliações de status
durante a iteração e quaisquer outros problemas na lista de problemas do gerente de projeto.
Se todos os riscos tiverem sido reduzidos a níveis aceitáveis, toda a funcionalidade tiver sido
implementada e todos os objetivos de qualidade tiverem sido atingidos, o produto estará concluído. O
planejamento e a execução eficientes são vitais para isso ocorrer no final da fase de Transição.

4.6 Técnicas de avaliação de software

4.6.1 Análise por Pontos de Função

Análise de Pontos de Função (APF) é uma técnica para a medição de projetos de desenvolvimento de
software, visando estabelecer uma medida de tamanho, em Pontos de Função (PF), considerando a
funcionalidade implementada, sob o ponto de vista do usuário. A medida é independente da linguagem
13
de programação ou da tecnologia que será usada para implementação.

13 http://pt.wikipedia.org/wiki/An%C3%A1lise_de_pontos_de_fun%C3%A7%C3%A3o
40
 TI para concursos
Seus objetivos são:
 medir a funcionalidade solicitada pelo usuário, antes
do projeto de software, de forma a estimar seu
tamanho e seu custo
 medir projetos de desenvolvimento e manutenção de
software, independentemente da tecnologia utilizada
na implementação, de forma a acompanhar sua
evolução
 medir a funcionalidade recebida pelo usuário, após o
projeto de software, de forma verificar seu tamanho e
seu custo, comparando-os com o que foi originalmente
estimado
As organizações podem aplicar a Análise de Pontos por Função como:
 uma ferramenta para determinar o tamanho de pacotes de software adquiridos, através da
contagem de todos os Pontos por Função incluídos no pacote
 uma ferramenta para apoiar a análise da qualidade e da produtividade
 um mecanismo para estimar custos e recursos envolvidos em projetos de desenvolvimento e
manutenção de software
 um fator de normalização para comparação de software
O procedimento para contagem de PFs compreende:14
 Determinar o Tipo de Contagem
 projeto de desenvolvimento
 aplicações instaladas
 projetos de manutenção
 Identificar o Escopo de Contagem e Fronteira da Aplicação
 definir a parte do sistema (funcionalidades) a ser contada
 Determinar os PFs não ajustados
 Contagem das Funções
 dados - arquivos lógicos internos (ALI) e arquivos de interface externa (AIE)
 transacionais – entradas (EE), saídas (SE) e consultas (CE) externas
 Determinar o Fator de Ajuste
 o fator de ajuste é baseado em quatorze características gerais de sistemas, que avaliam a funcionalidade
geral da aplicação que está sendo contada, e seus níveis de influência. O nível de influência de uma
característica é determinado com base em uma escala de 0 (nenhuma influência) a 5 (forte influência).
 Calcular os PFs Ajustados

4.6.1.1 Contagem das Funções de Dados

O primeiro passo para a contagem das funções de dados consiste em identificar arquivos lógicos
internos (ALIs) e arquivos de interface externa (AIEs). Cada uma dessas funções de dados deve ser
classificada segundo sua complexidade funcional. Essa complexidade é definida com base nos
conceitos de registros lógicos e itens de dados.
Registros Lógicos são subconjuntos de dados dentro de um ALI/AIE, que foram reconhecidos pelo
usuário. Se o usuário não reconhecer subconjuntos de dados em um ALI/AIE, então se deve contar o
ALI/AIE como um registro lógico.
Um Item de Dados, por sua vez, é um campo reconhecido pelo usuário como único e não repetido.
Vale destacar que só devem ser contados os itens de dados utilizados pela aplicação em contagem.

14 http://www.inf.ufes.br/~falbo/download/aulas/es-g/2005-1/APF.pdf
41
 TI para concursos
Contando-se os registros lógicos e os itens de dados de um ALI/AIE, pode-se chegar à sua
complexidade, utilizando a tabela 1:

Número de Registros Número de Itens de Dados Referenciados

Lógicos 1 a 19 20 a 50 51 ou mais

Apenas 1 Simples Simples Média

2a5 Simples Média Complexa

6 ou mais Média Complexa Complexa

4.6.1.2 Contagem das Funções Transacionais

De maneira análoga à contagem das funções de dados, a contagem das funções transacionais envolve
a identificação de funções transacionais (entradas externas, saídas externas e consultas externas) e
sua classificação de acordo com a complexidade funcional envolvida (simples, média ou complexa). A
definição da complexidade funcional é feita com base no número de arquivos referenciados e dos itens
de dados manipulados pela função, utilizando as tabelas 2 para entradas externas e 3 para saídas e
consultas externas.
Nessas tabelas, um arquivo referenciado pode ser um ALI lido ou mantido pela função transacional, ou
um AIE lido pela função transacional. Já o número de itens de dados referenciados é calculado
considerando apenas os itens de dados efetivamente referenciados pela função transacional em
questão.
Tabela 2 para entradas externas:

Número de arquivos Número de Itens de Dados Referenciados

referenciados 1a4 5 a 15 16 ou mais

0 ou 1 Simples Simples Média

2 Simples Média Complexa

3 ou mais Média Complexa Complexa

Tabela 3 para saídas e consultas externas:

Número de arquivos Número de Itens de Dados Referenciados

referenciados 1a5 6 a 19 20 ou mais

0 ou 1 Simples Simples Média

2 ou 3 Simples Média Complexa

4 ou mais Média Complexa Complexa

4.6.1.3 Cálculo dos Pontos de Função Não Ajustados

Uma vez contadas as funções de dados e as funções transacionais, é possível calcular os PFs não
ajustados de uma aplicação. Esse cálculo é feito da seguinte forma:
1. Para cada um dos cinco tipos de função (ALI, AIE, EE, SE e CE), são computados os totais de
pontos de função (NPFi), segundo a seguinte expressão:

onde
 NCi,j = número funções do tipo i (i variando de 1 a 5, segundo os tipos de função existentes: ALI,
AIE, EE, SE e CE) que foram classificados na complexidade j (j variando de 1 a 3,
segundo os valores de complexidade: simples, média e complexa).

42
 TI para concursos
 Ci,j = valor da contribuição da complexidade j no cálculo dos pontos da função i, dado pela
tabela 4.
Tabela 4 – Contribuição das Funções na Contagem de PFs Não Ajustados.

Complexidade
Função
Simples Média Complexa

arquivos lógicos
7 10 16
internos - ALI

arquivos de interface
5 7 10
externa - AIE

entradas externas - SE 4 5 7

saídas externas - EE 3 4 6

consultas externas - CE 3 4 6

2. O total de pontos de função não ajustados (PFNA) é dado pelo somatório dos pontos das tabelas de
função:

sendo que i varia de 1 a 5, segundo os tipos de função existentes (AIL, AIE, EE, SE e CE).

4.6.1.4 Determinação do Fator de Ajuste

O fator de ajuste influencia os pontos de função não ajustados em +/- 35%, obtendo-se o número de
PFs ajustados. Para se calcular o fator de ajuste, são usadas 14 características gerais dos sistemas, a
saber:
 Comunicação de Dados
 Processamento de Dados Distribuído
 Desempenho
 Utilização do Equipamento (Restrições de Recursos Computacionais)
 Volume de Transações
 Entrada de Dados On-line
 Eficiência do Usuário Final (Usabilidade)
 Atualização On-line
 Processamento Complexo
 Reusabilidade
 Facilidade de Implantação
 Facilidade Operacional (Processos Operacionais, tais como Inicialização, Cópia de Segurança,
Recuperação etc)
 Múltiplos Locais e Organizações do Usuário
 Facilidade de Mudanças (Manutenibilidade)
Para cada uma dessas 14 características deve-se atribuir um valor de 0 (nenhuma influência) a 5 (forte
influência), dito grau ou nível de influência, que indica o quanto determinada característica tem
influência no sistema. Os 14 graus de influência (GIs) informados são somados, resultando no nível de
influência total (NIT):

Finalmente, o valor do fator de ajuste (VFA) é determinado, então, pela fórmula:

Considerando que o valor máximo do NIT é 14x5=70 e o mínimo é zero, então, o valor do VFA varia de
0,65 a 1,35.

43
 TI para concursos
4.6.1.5 Cálculo dos Pontos de Função Ajustados
Uma vez calculados os PF não ajustados e o fator de ajuste, é possível calcular os PFs ajustados. Esse
cálculo é feito de formas diferentes para cada tipo de contagem (projeto de desenvolvimento, projeto de
manutenção ou aplicações instaladas). Para projetos de desenvolvimento, o cálculo é dado por:
PF = PFNA * VFA
onde
 PFNA = Número de PFs não ajustados
 VFA = valor do fator de ajuste

4.6.2 Método COCOMO

O método COCOMO (ou COnstructive COst MOdel) é um modelo de estimativa do tempo de
desenvolvimento de um produto. Criado por Barry Boehm. É baseado no estudo de sessenta e três
projetos. Os programas examinaram de 2.000 a 100.000 linhas de código em linguagens de
programação de Assembly a PL/I.15
A partir de um conjunto de atributos, premissas e modos de desenvolvimento o COCOMO estima os
prazos, custos e recursos necessários para cada etapa do ciclo de vida do produto.
COCOMO consiste em três implementações:
 Básico - É um modelo estático que calcula o esforço de desenvolvimento de software e seu custo,
em função do tamanho de linhas de códigos desenvolvidas.
Cocomo básico é bom por ser rápido em estimativas e custos de software, mas sua exatidão é
limitada por causa de sua falta de fatores para explicar as diferenças entre ferramentas, qualidade
de pessoal e experiência, uso de ferramentas modernas e técnicas, e outros atributos de projeto que
influenciam nos custos de software.
 Intermediário - Calcula o esforço de desenvolvimento
de software em função do tamanho do programa, que
inclui custo, avaliação subjetiva do produto, hardware,
pessoal e atributos de projeto. O método intermediário
é uma extensão do método básico, mas com mais
categorias de controle como: atributos do produto,
atributos de hardware, atributos pessoais, atributos do
projeto.
 Avançado - São incorporadas características da
versão intermediária com uma avaliação de impacto
de custo em cada passo de todo o projeto.

4.7 Gerência de Requisitos de Software

A engenharia de requisitos16 é um processo que engloba todas as atividades que contribuem para a
produção de um documento de requisitos e sua manutenção ao longo do tempo.
O processo de engenharia de requisitos é composto por quatro atividades de alto nível:
 Identificação.
 Análise e negociação.
 Especificação e documentação.
 Validação.
A gestão dos requisitos faz parte deste processo, se incluirmos a fase de manutenção, sendo que as
alterações podem ser causadas pelos mais diversos fatores desde inovações tecnológicas a mudanças
na natureza do negócio.
A implementação de boas práticas de gerência de requisitos de software constitui uma das prioridades
na implantação de melhoria do processo de software.
O principal risco, que atinge 80% dos projetos de software, é o da Evolução de Requisitos. Os
indicadores de desempenho são formas de representação quantificáveis de características de produtos
e processos, sendo utilizados para acompanhar e melhorar os resultados ao longo do tempo.

15 http://pt.wikipedia.org/wiki/M%C3%A9todo_COCOMO
16 http://pt.wikipedia.org/wiki/Requisitos_de_Software
44
 TI para concursos

4.7.1 Conceitos de Requisitos

Um requisito é definido como "uma condição ou uma capacidade com a qual o sistema deve estar de
acordo".17
Os requisitos do utilizador destinam-se aos vários níveis hierárquicos da organização e são descritos
usando apenas linguagem natural, formulários e diagramas muito simples. Neste nível de
especificação, surgem algumas dificuldades:
 Ambiguidade: torna-se difícil descrever os requisitos de uma forma inequívoca sem tornar a sua
descrição muito longa ou de difícil compreensão.
 Confusão: ainda que possa não ser tão relevante do ponto de vista do cliente, a distinção entre
requisitos funcionais/não-funcionais e objetivos do sistema torna-se difícil.
 Agrupamento de requisitos: ao descrever as funcionalidades de um sistema, pode ser difícil
separar claramente os requisitos, o que leva a que vários requisitos sejam expressos como sendo
apenas um.
Algumas considerações:
 Usar o mesmo formato em todos os requisitos para evitar omissões e facilitar a verificação dos
requisitos.
 Distinguir claramente, através do uso de expressões, entre comportamentos esperados "O sistema
permitirá criar (...)" ou desejáveis "Deverá ser possível criar (...)". É importante deixar claro o que o
sistema tem de fazer e sugestões de como o deve fazer e, acima de tudo, usar este tipo de
expressões de forma consistente ao longo de todo o documento.
 Usar formatação de texto para salientar determinados aspectos do documento (negrito,
sublinhado, itálico).
 Evitar usar termos demasiado técnicos ou fora do âmbito do sistema, identificando e definindo de
uma forma clara quando for absolutamente necessário usá-los.
Os requisitos do sistema têm um carácter mais técnico, consistindo numa descrição detalhada dos
requisitos do utilizador recorrendo ao uso de linguagens estruturadas e notações gráficas. Estes
requisitos destinam-se aos utilizadores do sistema, às equipes de especificação de arquitetura do
sistema e de desenvolvimento.
O uso de linguagem natural levanta problemas:
 As mesmas palavras podem, de acordo com a interpretação de cada pessoa, designar conceitos
diferentes.
 O mesmo requisito pode ser descrito de formas diferentes, o que leva a que cada pessoa tenha de
saber quando é que descrições diferentes se referem ou não a requisitos diferentes.

4.7.1.1 Elicitação
Técnica de obtenção de dados junto aos usuários detententores das informações, principalmente para
a construção de um sistema ou um produto ou, ainda para melhorar um processo de trabalho.

4.7.1.2 Joint Application Development (JAD)18

Técnica para levantamento de requisitos desenvolvido pela IBM nos anos 70, que organiza reuniões
que discutem o processo de levantamento de requisitos gerenciamento do projeto.
Os princípios básicos:
 Ninguém é melhor para explicar um determinado processo do que as pessoas que trabalham com
ele.
 Os profissionais de TI são os mais preparados para identificar as possibilidades que a tecnologia
oferece, assim como suas limitações.
 Sistemas de informação e processos do negócio não são isolados.
 Os melhores sistemas de informação são resultado do trabalho conjunto de todas as pessoas
envolvidas: profissionais de TI, usuários, gestores, analistas de negócio etc.
O JAD orienta a condução das sessões a partir de alguns papéis.

17 http://www.wthreex.com/rup/portugues/process/workflow/requirem/co_req.htm
18 http://www.cos.ufrj.br/~targino/engsoft/JAD.pdf
45
 TI para concursos
O facilitador é neutro: ele não opina nos assuntos discutidos, mas pode direcionar os assuntos
conforme o planejamento inicial. Cabe a ele também evitar que determinados indivíduos dominem
reunião.
O anotador está dedicado a registrar os assuntos discutidos e decisões tomadas, liberando assim os
outros membros a participar das discuss ões sem perder tempo com anotações.
O gerenciador de tempo vai evitar que determinadas discussões demorem demasiadamente, evitando
assim que outros assuntos não sejam abordados.
O quadro do projeto serve para lembrar os assuntos em foco e os que estão fora do foco, impedindo
assim discussões infrutíferas.

4.7.1.3 Estudo etnográfico19

Estudo etnográfico é uma técnica, proveniente das disciplinas de Antropologia Social, que consiste no
estudo de um objeto por vivência direta da realidade onde este se insere, permitindo analisar a
componente social das tarefas desempenhadas numa dada organização tornam-se, no âmbito da
Engenharia de Requisitos, extremamente uteis para ultrapassar a dificuldade que existe na coleta dos
requisitos derivados de formas rotineiras e tácitas de trabalhar:
 modo como realmente as pessoas executam as suas funções que muitas vezes difere da forma
como as definições dos processos sugerem que elas devem fazer;
 cooperação e conhecimento das atividades de outras pessoas.
Para isso, um sociólogo, externo à organização em causa, passa algum tempo observando e
analisando a atividade das pessoas sem que estas necessitem explicar o seu trabalho (interações
implícitas), extraindo daí conclusões importantes acerca de fatores sociais e organizacionais. Desta
forma, é necessário assumir que as pessoas em estudo são competentes na realização do seu
trabalho.
Estes estudos têm mostrado que o trabalho das pessoas é, normalmente, mais rico e complexo do que
o descrito pelas definições dos processos e pelos modelos dos sistemas.
O principal problema da aplicação deste método é fruto da dificuldade na generalização dos resultados.
É um método qualitativo que se insere na corrente filosófica do Interpretivismo.

4.7.2 Requisitos Funcionais e Não-Funcionais

Os requisitos funcionais especificam ações que um sistema deve ser capaz de executar, sem levar em
consideração restrições físicas. Geralmente, isso é melhor descrito em um modelo de casos de uso. Os
requisitos funcionais especificam o comportamento de entrada e saída de um sistema. É aquilo que o
utilizador espera que o sistema ofereça, atendendo aos propósitos para qual o sistema será
desenvolvido.
 conjuntos de recursos
 habilidades
 segurança
Requisitos não-funcionais são restrições nas quais o sistema deve operar ou propriedades emergentes
do sistema. Vários requisitos não são funcionais e descrevem apenas atributos ou ambiente do
sistema. Alguns deles podem ser capturados em casos de uso, outros em Especificações
Suplementares.
 Usabilidade
 fatores humanos
 estética
 consistência na interface do usuário
 ajuda online e contextual
 assistentes e agentes
 documentação do usuário
 materiais de treinamento
 Confiabilidade
 freqüência e gravidade de falha
 possibilidade de recuperação
 possibilidade de previsão

19 http://pt.wikipedia.org/wiki/Estudo_etnogr%C3%A1fico
46
 TI para concursos
 exatidão
 tempo médio entre falhas (MTBF)
 Desempenho
 velocidade
 eficiência
 disponibilidade
 exatidão
 taxa de transferência
 tempo de resposta
 tempo de recuperação
 uso de recurso
 Suportabilidade
 possibilidade de teste
 extensibilidade
 adaptabilidade
 manutenibilidade
 compatibilidade
 possibilidade de configuração
 possibilidade de serviço
 possibilidade de instalação
 possibilidade de localização (internacionalização)
 restrições de design
 especifica ou restringe o design de um sistema
 requisitos de implementação
 padrões obrigatórios
 linguagens de implementação
 políticas de integridade de banco de dados
 limites de recursos
 ambientes operacionais
 requisitos de interface
 um item externo com o qual o sistema deve interagir
 restrições de formatos, tempos ou outros fatores usados por tal interação
 requisitos físicos
 material
 forma
 tamanho
 peso

4.8 Gerência de Configuração e Mudança

4.8.1 Conceitos de Gerência de Configuração e Mudança de software

Gerência de Configuração de Software é uma área da engenharia de software responsável por fornecer
o apoio para o desenvolvimento de software. Suas principais atribuições são o controle de versão, o
controle de mudança e a auditoria das configurações.20
Conjunto de atividades projetadas para controlar as mudanças pela identificação dos produtos do
trabalho que serão alterados, estabelecendo um relacionamento entre eles, definindo o mecanismo
para o gerenciamento de diferentes versões destes produtos, controlando as mudanças impostas, e
auditando e relatando as mudanças realizadas.
A Gerência de Configuração e Software é definida por quatro funções básicas:
 Identificação dos itens de configuração
 Documentação
 Controle
 Auditoria das mudanças

20 http://pt.wikipedia.org/wiki/Ger%C3%AAncia_de_Configura%C3%A7%C3%A3o_de_Software
47
 TI para concursos

4.8.2 Solicitações de Mudança

As mudanças nos artefatos de desenvolvimento são propostas através de Solicitações de Mudança
(CRs ou Change Requests), que são usadas para documentar e controlar defeitos, solicitações de
melhorias e qualquer outro tipo de solicitação de mudança no produto.
A vantagem das CRs é que elas fornecem um registro das decisões e, devido a seu processo de
21
avaliação, garantem que os impactos das mudanças sejam entendidos no projeto.
A necessidade de mudança parece ser inerente aos sistemas de software existentes e em
desenvolvimento. O Gerente de Controle de Mudança é responsável pela definição dos procedimentos
de Gerenciamento de Solicitações de Mudança e pela manutenção de CRs, garantindo que as
mudanças em um sistema sejam efetuadas de maneira controlada, para que seu efeito no sistema
possa ser previsto. As CRs podem ser usadas para documentar e controlar todos os tipos de
solicitações de mudanças no sistema, inclusive defeitos e solicitações de melhoria.
As solicitações de melhoria são usadas pelo Analista de Sistemas para determinar futuros recursos a
serem incluídos no produto. Serão usadas como base durante a coleta de solicitações dos principais
envolvidos (stakeholders) para que se possa compreender as necessidades dos investidores.
Um defeito é uma anomalia ou falha em um produto de trabalho liberado. Alguns exemplos são
omissões e imperfeições localizadas durante as fases iniciais do ciclo de vida e sintomas (falhas) de
erros contidos em softwares maduros o suficiente para teste e operação. Os defeitos também podem
incluir desvios das expectativas ou qualquer questão que precise ser controlada e resolvida.
A finalidade de um defeito é comunicar os detalhes da questão, permitindo a ação corretiva, a solução
e o acompanhamento.
As seguintes pessoas usam as CRs:
 O Analista de Sistemas usa as CRs identificadas como Solicitações de Melhoria para determinar
novos recursos do produto.
 O Gerente de Projetos usa CRs para atribuir trabalho.
 Os Testadores usam CRs para identificar e descrever os defeitos localizados no teste.
 O Implementador usa CRs para analisar o defeito e localizar os erros ou causas das CRs.
 O Designer de Teste usa CRs a fim de planejar o teste para verificar as CRs solucionadas e analisar
um conjunto de defeitos para medir a qualidade do software e do processo.
Os seguintes atributos são úteis para tomar uma decisão sobre qualquer CR enviada:
Tamanho
 Que volume de trabalho existente precisará ser alterado?
 Que volume de trabalho extra precisará ser adicionado?
Alternativas
 Existe alguma?
Complexidade
 A mudança proposta é fácil de ser efetuada?
 Quais são as possíveis ramificações provenientes dessa mudança?
Gravidade
 Qual é o impacto da não implementação desta solicitação?
 Há alguma perda de trabalho ou de dados envolvida?
 Esta é uma solicitação de melhoria?
 É um problema secundário?
Cronograma
 Quando a mudança é necessária?
 Ela é viável?
Impacto
 Quais as conseqüências de efetuar a mudança?
 Quais as conseqüências de não efetuar a mudança?

21 http://www.wthreex.com/rup/process/artifact/ar_crqst.htm
48
 TI para concursos
Custo
 Qual é a economia proveniente desta mudança?
 Relacionamento com Outras Mudanças
 Outras mudanças substituirão ou invalidarão esta ou isso depende de outras mudanças?
Teste
 Há algum requisito especial de teste?
As práticas de Gerenciamento de Mudanças normalmente são institucionalizadas ou estabelecidas no
início do ciclo de vida do projeto. Desse modo, as CRs, que integram o processo de mudança, podem
surgir a qualquer momento durante o curso do projeto.
A principal origem de defeitos consiste nos resultados da execução dos testes — integração, sistema e
desempenho. Contudo, os defeitos podem aparecer em qualquer ponto do ciclo de vida de
desenvolvimento do software e abranger a identificação de documentação, casos de teste ou casos de
uso ausentes ou incompletos.
Qualquer pessoa da equipe de projeto deve ser capaz de efetuar uma CR. No entanto, a CR precisa
ser revisada e aprovada pelo supervisor da pessoa que a efetuou. A arbitragem final sobre uma
Solicitação de Mudança é realizada por uma Equipe de Revisão ou um Comitê de Controle de Mudança
(CCB).
O Gerente de Controle de Mudança é responsável pela integridade do defeito, garantindo que:
 Sejam exatas todas as informações que identificam e descrevem o defeito e indicam como ele foi
descoberto.
 O defeito seja exclusivo ou que não seja outra ocorrência de um defeito já identificado.
Os campos e os dados reais necessários para identificar, descrever e controlar defeitos com precisão
são variados e dependem do sistema de controle de mudanças, das diretrizes e dos padrões
implementados.

4.9 Testes e Avaliação de Qualidade de Software

4.9.1 Qualidade de Software

Área de conhecimento da engenharia de software que objetiva garantir a qualidade do software através
da definição e normatização de processos de desenvolvimento. Apesar dos modelos aplicados na
garantia da qualidade de software atuarem principalmente no processo, o principal objetivo é garantir
um produto final que satisfaça às expectativas do cliente, dentro daquilo que foi acordado inicialmente.
A qualidade é o grau em que um conjunto de características inerentes a um produto, processo ou
sistema cumpre os requisitos inicialmente estipulados.22
A engenharia de software objetiva garantir a qualidade através da definição e normatização de
processos de desenvolvimento, com um produto final que satisfaça às expectativas do cliente.
Os atributos qualitativos previstos na norma ISO 9126 são:
 funcionalidade
 confiabilidade
 usabilidade
 eficiência
 manutenibilidade
 portabilidade.
Mensurar o bom funcionamento de um software envolve compará-lo com elementos como
especificações, outros softwares da mesma linha, versões anteriores do mesmo produto, inferências
pessoais, expectativas do cliente, normas relevantes, leis aplicáveis, entre outros.
A verificação compara o software com a especificação, enquanto que a validação compara com a
expectativa do cliente.
A melhoria de processos tem base em modelos tidos como eficientes, como por exemplo os SW-CMM,
SE-CMM, ISO 15504 e o mais conhecido CMMI.

4.9.1.1 CMM

22 http://pt.wikipedia.org/wiki/Qualidade_de_software
49
 TI para concursos
O "CMM - Capability Maturity Model for Software /SEI" é uma
estrutura (framework), que descreve os principais elementos
de um processo de desenvolvimento de software.
Organizações de software evoluem o seu ciclo de
desenvolvimento de software através de sua avaliação
contínua, identificação e ações corretivas dentro de uma
estratégia de melhoria dos processos. Este caminho de
melhoria é definido por cinco níveis de maturidade:
 inicial, ad hoc, sem ambiente estável de desenvolvimento
ou processos estruturados, que excedem prazos e
orçamentos.
 repetitivo, um minimo de disciplina nos processos para repetir sucessos anteriores, podendo utilizar
ferramentas de gerência de projetos para administrar custos e prazos, e status do projeto visíveis
(marcos e término).
 definido, um conjunto de processos padrão estabelecidos e melhorados periodicamente
 gerenciado, com utilização de indicadores de qualidade
 otimizado, com a procura constante de inovação e a realização de um processo controlado e
mensurado para melhoria contínua
O CMMI possui duas representações: "contínua" ou "por estágios". Estas representações permitem a
organização utilizar diferentes caminhos para a melhoria de acordo com seu interesse.
Representação Continua, que possibilita à organização utilizar a ordem de melhoria que melhor atende
os objetivos de negócio da empresa. É caracterizado por Níveis de Capacidade (Capability Levels):
 Nível 0: Incompleto (Ad-hoc)
 Nível 1: Executado (Definido)
 Nível 2: Gerenciado
 Nível 3: Definido
 Nível 4: Quantitativamente gerenciado
 Nível 5: Em otimização
Representação Por Estágios, que oferece uma seqüência pré-determinada para melhoria baseada em
estágios que não deve ser desconsiderada, pois cada estágio serve de base para o próximo. É
caracterizado por Níveis de Maturidade (Maturity Levels):
 Nível 1: Inicial (Ad-hoc)
 Nível 2: Gerenciado
 Nível 3: Definido
 Nível 4: Quantitativamente gerenciado
 Nível 5: Em otimização

4.9.1.2 Garantia de qualidade de software

A Garantia da Qualidade de Software (GQS) é a área-chave de processo do CMM cujo objetivo é
fornecer aos vários níveis de gerência a adequada visibilidade dos projetos, dos processos de
desenvolvimento e dos produtos gerados. A GQS atua como “guardiã”, fornecendo um retrato do uso
do Processo e não é responsável por executar testes de software ou inspeção em artefatos.23
Obtendo a visibilidade desejada, a gerência pode atuar de forma pontual no sentido de atingir os quatro
grandes objetivos de um projeto de desenvolvimento de software, quais sejam, desenvolver software de
alta qualidade, ter alta produtividade da equipe de desenvolvimento, cumprir o cronograma
estabelecido junto ao cliente e não necessitar de recursos adicionais não previstos.
Para conseguir esses objetivos a área-chave de processo GQS estimula a atuação das equipes
responsáveis pelo desenvolvimento de software em diversas frentes objetivando internalizar
comportamentos e ações, podendo-se destacar:
 o planejamento do projeto e o acompanhamento de resultados;
 o uso dos métodos e ferramentas padronizadas na organização;
 a adoção de Revisões Técnicas Formais;
 o estabelecimento e a monitoração de estratégias de testes;
 a revisão dos artefatos produzidos pelo processo de desenvolvimento;

23 http://pt.wikipedia.org/wiki/Qualidade_de_software
50
 TI para concursos
 a busca de conformidade com os padrões de desenvolvimento de software;
 a implantação de medições associadas a projeto, processo e produto;
 a utilização de mecanismos adequados de armazenamento e recuperação de dados relativos a
projetos, processos e produtos;
 a busca de uma melhoria contínua no processo de desenvolvimento de software.

4.9.2 Teste de software

O teste do software é a investigação do software a fim de fornecer informações sobre sua qualidade em
relação ao contexto em que ele deve operar. Isso inclui o processo de utilizar o produto para encontrar
seus defeitos.
O teste é um processo realizado pelo testador de software, que permeia outros processos da
engenharia de software, e que envolve ações que vão do levantamento de requisitos até a execução do
teste propriamente dito.
Não se pode garantir que todo software funcione corretamente, sem a presença de erros, visto que os
mesmos muitas vezes possuem um grande número de estados com fórmulas, atividades e algoritmos
complexos. O tamanho do projeto a ser desenvolvido e a quantidade de pessoas envolvidas no
processo aumentam ainda mais a complexidade. Idealmente, toda permutação possível do software
deveria ser testada. Entretanto, isso se torna impossível para a ampla maioria dos casos devido à
quantidade impraticável de possibilidades. A qualidade do teste acaba se relacionando à qualidade dos
profissionais envolvidos em filtrar as permutações relevantes.
Falhas podem ser originadas por diversos motivos. Por exemplo, a especificação pode estar errada ou
incompleta, ou pode conter requisitos impossíveis de serem implementados, devido à limitações de
hardware ou software. A implementação também pode estar errada ou incompleta, como um erro de
um algoritmo. Portanto, uma falha é o resultado de um ou mais defeitos em algum aspecto do sistema.
Todas as metodologias de desenvolvimento de software têm uma disciplina dedicada aos testes.
Atualmente esta é uma tarefa indispensável, porém muitas vezes efetuada de maneira ineficiente, seja
pelo subestimar dos que desenvolvem, pela falta de tempo ou mesmo pela falta de recursos humanos e
financeiros.
O gerenciamento de projetos define alguns princípios em relação aos testes: 24
 Testar é um exercício de gerência de risco
 Treinamento em teste reduz custos a longo prazo
 As estimativas de teste devem ser baseadas no risco do negócio
 A estratégia de teste deve ser elaborada através de um trabalho conjunto entre as áreas envolvidas
 É melhor encontrar um defeito nas primeiras fases do que em produção
Um plano de testes deve passar por alguns estágios:
 Planejamento
 Estratégia de Teste
 Cronograma básico
 Plano de Teste
 Cronograma final
 Análise de Risco
 Análise de Pontos deTeste
 Elaboração
 Elaborar Cenário de Teste
 Elaborar Caso de Teste
 Procedimento de Teste
 Implementar Teste
 Execução
 Casos de Teste
 Roteiros de Teste
 Controle
 Relatórios de Defeitos
 Relatórios de Progresso

24 http://www.iteste.com.br/Portals/0/Palestra%20Gerencia%20de%20Teste_1%20hora.pdf
51
 TI para concursos
As pessoas envolvidas nos testes podem assumir os papéis de:
 Líder ou Gerente de teste, responsável pela liderança de um projeto de teste específico
 Arquiteto de Teste, responsável pela montagem do ambiente de teste (infra-estrutura) e escolha das
ferramentas
 Analista de Teste, responsável pela modelagem e elaboração dos casos de testes e scripts de teste
 Testador, responsável pela execução dos casos de teste e scripts de teste
A definição de quem irá executar os testes dependerá do nível ou estágio do teste:
 Teste Unitário - Desenvolvedores
 Teste de Integração - Analistas de Sistemas
 Teste de Sistema - Analistas de Teste
 Teste de Aceitação - Usuários e Analistas de Teste
Existem técnicas de testes chamadas de funcionais, que verificam se o sistema faz o que deveria:25
 Teste de caixa-branca - Também chamado de teste estrutural ou orientado à lógica, avalia o
comportamento interno do componente de software. Essa técnica trabalha diretamente sobre o código fonte
do componente de software para avaliar aspectos tais como: teste de condição, teste de fluxo de dados,
teste de ciclos, teste de caminhos lógicos, códigos nunca executados.
 Teste de caixa-preta - Também chamado de teste funcional, orientado a dado ou orientado a entrada e
saída, avalia o comportamento externo do componente de software. Dados de entrada são fornecidos, o
teste é executado e o resultado obtido é comparado a um resultado esperado previamente conhecido.
Há, por outro lado, as técnicas não funcionais, que testam como a operação correta do sistema se
comporta em situações anormais, como casos de entradas inválidas ou inesperadas.
 teste de desempenho com teste de carga, verifica se o software consegue processar grandes quantidades
de dados nas especificações de tempo de processamento exigidas, o que determina a escalabilidade do
software.
 teste de usabilidade, necessário para verificar se a interface de usuário é fácil de se aprender e utilizar.
 teste de confiabilidade, usado para verificar se o software é pode assegurar o sigilo dos dados
armazenados e processados.
 teste de recuperação, usado para verificar a robustez do software em retornar a um estado estável de
execução após estar em um estado de falha.

4.9.3 Documentos de Teste

IEEE 829-1998, também conhecido como o Padrão 829 para Documentação de Teste de Software, é
um padrão IEEE que especifica a forma de uso de um conjunto de documentos em oito estágios
definidos de teste de software, cada estágio potencialmente produzindo seu próprio tipo de documento.
O padrão especifica o formato desses documentos mas não estipula se todos eles devem ser
produzidos, nem inclui qualquer critério de conteúdo para esses documentos.26
Documentação de Teste consiste em um conjunto de documentos relacionados ao teste das diversas
classes e seus relacionamentos no sistema. Dentre eles pdemos ter:27
 Plano de Teste, que prescreve o escopo, a abordagem, os recursos e o cronograma de testes. No
mínimo os seguintes tópicos devem ser tratados:
 Descrição do programa a ser testado: o que faz; estrutura
 Objetivo dos testes: por exemplo, se são testes caixa branca ou caixa preta, se são testes de integração ou
de unidade
 Escopo dos testes: que itens serão testados, quais não serão
 Projetos de Teste, que detalha o planejamento de testes e identifica os elementos a serem testados.
No caso de testes de unidades, cada unidade é um item. Definção das estruturas provisórias
(drivers, stubs, arquivos ou bancos de dados criados para os testes, entre outros) que serão usadas
nos testes.
 Casos de Teste especificados no projeto. A descrição de cada caso de teste deve conter os
seguintes tópicos:
 Identificação do caso de teste
 Itens a testar
 Entradas: valores dos campos de entrada
 Saídas esperadas: valores dos campos de saída

25 http://pt.wikipedia.org/wiki/Teste_de_software
26 http://se.inf.ethz.ch/teaching/ss2005/0050/exercises/REMOVED/IEEE%20Std%20829-1998%20test.pdf
27 http://www.ic.unicamp.br/~eliane/Cursos/Planos_Testes/Documentos/plantestes.doc.
52
 TI para concursos
 Ambiente: necessidade de hw, sw, ferramentas e estruturas provisórias que sejam específicas desse caso
de teste
 Procedimentos: identificação do procedimento de teste (dentre os já listados na seção anterior) que será
usado para executar o caso de teste
 Dependências: condições prévias para a execução do caso de teste, inclusive outros casos de teste que
devam ser executados obrigatoriamente antes deste
 Saídas observadas: resultados fornecidos pelo item em teste ou anomalias ocorridas durante a execução
 Impacto: consequências do incidente de teste (evento indesejável que tenha ocorrido durante os testes).
Como para a inspeção, classificá-los em categorias:
 MA: maior. Causa resultados errados/anomalia na execução do programa
 ME: menor. Causa outro tipo de problema que não afeta a execução do programa
 Procedimentos de Teste, que especifica os passos para execução. Definição dos procedimentos
associados ao conjunto de testes:
 Uma identificação do procedimento .
 O objetivo do procedimento.
 Os requisitos especiais para a execução do procedimento (por exemplo, usar o arquivo DadosTeste)
 O fluxo passo a passo do procedimento detalhado o suficiente para que possa ser executado manualmente
por um operador ou convertido em um script de teste.
 Descrição de cada um dos casos de teste gerado.
 Resultados do teste, contendo os registros dos testes realizados em ordem cronológica.
 Relatório de incidentes, contendo o registro dos problemas encontrados durante os testes que
mereçam ser investigados.
 Relatório de resumo dos teste, contendo um resumo dos resultados das atividades projetadas e
fornecendo avalições baseadas nestes resultados. O relatório fecha a etapa de testes realizada,
permitindo uma avaliação da eficácia dos mesmos, indicação do nível de qualidade do produto, se
há necessidade de testes adicionais ou a reconstrução de alguns itens sob teste. O relatório de
resumo pode conter:
 Identificador do relatório resumido
 Contexto: quais os itens testados, com respectivos números de versão e revisão
 Variações: descrever as possíveis variações dos testes realizados em relação ao previsto na especificação,
justifiando o motivo de tais variações
 Abrangência: avaliar se a cobertura foi suficiente, conforme o planejado. Indicar possíveis deficiências nos
testes, caso existam.
 Sumário dos resultados: resumir os incidentes ocorridos
 Avaliação: fornecer uma avaliação global da eficácia dos testes; uma base para isso pode ser o número de
defeitos classificados como MA que foram encontrados.
 Sumário das atividades: para cada item testado, indicar o tempo previsto e os efetivamente gastos para as
tarefas de teste
 Aprovações: indicar se o item testado foi considerado aprovado ou não.

4.10 Exercícios
36. (ICMS-SP 2009) Quanto aos requisitos de software, considere:
I. É importante que se estabeleçam práticas para encontrar, documentar, organizar e rastrear os requisitos
variáveis de um sistema.
II. Etnografia (observação e análise dos fluxos de trabalho) e sessões de JAD são práticas que podem ser
aplicadas na elicitação.
III. Elicitar significa descobrir os requisitos de um sistema por meio de entrevistas, de documentos do sistema
existente, de análise do domínio do problema ou de estudos do mercado.
36
Está correto o que se afirma em
(a) I, apenas.
(b) I e II, apenas.
xx
(c) I, II e III.
(d) II e III, apenas.
(e) III, apenas.

53
 TI para concursos
37. (ICMS-SP 2009) Considere:
"Os requisitos expressam as características e restrições do produto de software do ponto de vista de
satisfação das necessidades do usuário. Em geral, independem da tecnologia empregada na construção da
solução, sendo uma das partes mais críticas e propensas a erros no desenvolvimento de software”.
37
Quanto aos requisitos de software, a descrição acima está
(a) incoerente ao afirmar que expressam restrições.
(b) incoerente ao afirmar que independem da tecnologia.
(c) incoerente ao afirmar que expressam características do ponto de vista de satisfação das necessidades
do usuário.
xx
(d) totalmente coerente.
(e) incoerente ao afirmar que os requisitos são uma das partes mais críticas e propensas a erros.
(ICMS-SP 2009) Instruções: Para responder às duas próximas questões, considere:
“É necessário que o software calcule os salários dos diaristas e mensalistas e emita relatórios mensais
sumariados por tipo de salário. Entretanto, a base de dados deve estar protegida e com acesso restrito aos
usuários autorizados. De qualquer forma, o tempo de resposta das consultas não deve superar os quinze
segundos, pois inviabilizaria todo o investimento nesse sistema. Devo lembrar que os relatórios
individuais dos departamentos, nos quais constam os salários dos funcionários, devem ser emitidos
quinzenalmente em razão dos adiantamentos e vales que recebem. É fundamental que o software seja
operacionalizado usando código aberto. Necessito, ainda, forte gerenciamento de risco, prazo e custo,
porque a entrega do produto final não pode ultrapassar o prazo de oito meses a contar da data de início do
projeto. A frase acima, expressa por um funcionário do cliente, aborda alguns requisitos de software
especificados para um sistema de gestão de pessoal.
38
38. (ICMS-SP 2009) No texto, são requisitos não-funcionais:
(a) não pode ultrapassar o prazo de oito meses e necessário que o software calcule os salários dos
diaristas e mensalistas.
(b) os relatórios individuais dos departamentos, nos quais constam os salários dos funcionários, devem ser
emitidos quinzenalmente e em razão dos adiantamentos e vales que recebem.
(c) É fundamental que o software seja operacionalizado usando código aberto e os relatórios individuais dos
departamentos, nos quais constam os salários dos funcionários, devem ser emitidos quinzenalmente.
(d) tempo de resposta das consultas não deve superar os quinze segundos e entrega do produto final não
xx
pode ultrapassar o prazo de oito meses.
(e) pois inviabilizaria todo o investimento nesse sistema e em razão dos adiantamentos e vales que
recebem.
39
39. (ICMS-SP 2009) No texto, são requisitos funcionais:
(a) calcule os salários dos diaristas e mensalistas e os relatórios individuais dos departamentos, nos quais
xx
constam os salários dos funcionários, devem ser emitidos quinzenalmente.
(b) Necessito, ainda, forte gerenciamento de risco, prazo e custo e a base de dados deve estar protegida e
com acesso restrito aos usuários autorizados.
(c) é fundamental que o software seja operacionalizado usando código aberto e emita relatórios mensais
sumariados por tipo de salário.
(d) emita relatórios mensais sumariados por tipo de salário e necessito, ainda, forte gerenciamento de risco,
prazo e custo.
(e) a base de dados deve estar protegida e com acesso restrito aos usuários autorizados e entrega do
produto final não pode ultrapassar o prazo de oito meses.
40. (ICMS-SP 2009) O processo de confirmação que um software vai ao encontro das especificações de
40
software se trata de um conceito-chave de qualidade denominado
(a) Validação.
xx
(b) Verificação.
(c) Precisão.
(d) Acurácia.
(e) Confiabilidade.
41. (ICMS-SP 2009) Garantir que um ou mais componentes de um sistema combinados funcionam corretamente
41
é o objetivo do tipo de teste
(a) de sistema.
xx
(b) de integração.
(c) de configuração.
(d) operacional.
(e) funcional.
42. (ICMS-SP 2009) O teste de ameaça normalmente deve ser aplicado dentro de um projeto de software nas
42
etapas de
(a) desenvolvimento inicial e desenvolvimento intermediário.
(b) desenvolvimento intermediário e teste de aceitação.
(c) desenvolvimento intermediário e teste de sistema.
(d) teste de integração e teste de aceitação.
xx
(e) teste de integração e teste de sistema.

54
 TI para concursos
43. (ICMS-SP 2009) Na prática de garantia de qualidade de software, contrapondo com o controle de qualidade
43
de software, se aplica a atividade:
(a) executar teste de software.
(b) desenvolver casos de testes.
xx
(c) definir métricas e medição.
(d) definir estratégias de testes.
(e) definir planos de desenvolvimento de teste.
44. (ICMS-SP 2009) O processo de engenharia de software denominado ciclo de vida clássico refere-se ao
44
modelo
xx
(a) em cascata.
(b) incremental.
(c) evolucionário.
(d) prototipagem.
(e) de processo unificado
45. (ICMS-SP 2009) O conceito de sprint aplica-se ao modelo ágil do processo de engenharia de software
45
denominado
(a) XP.
(b) DAS.
(c) DSDM.
xx
(d) Scrum.
(e) Crystal.
46
46. (ICMS-SP 2009) A engenharia de software está inserida no contexto
(a) da engenharia de sistemas, apenas.
(b) das engenharias de processo e de produto, apenas.
(c) das engenharias de sistemas e de processo, apenas.
(d) das engenharias de sistemas e de produto, apenas.
xx
(e) das engenharias de sistemas, de processo e de produto.
47. (FCC - 2008 - TRT) A frase "o tempo médio de resposta do sistema não deve ultrapassar 5 segundos" indica
47

(a) uma funcionalidade do sistema.

(b) uma atividade do cronograma do sistema.
(c) uma função executada pelo usuário do sistema.
(d) uma possível definição de requisito não funcional.xx
(e) um ponto de controle nas etapas de desenvolvimento do sistema.
48. (FCC - 2008 – TCE AL) Em um sistema cujo objetivo principal seja emitir guias de cobrança de impostos e
48
fazer o controle de contribuintes, NÃO é um produto inerente ao trabalho de levantamento de requisitos
xx
(a) uma descrição da relação possível entre as linhas de código com os pontos de função.
(b) uma declaração da necessidade e da viabilidade.
(c) uma descrição do ambiente técnico do sistema.
(d) uma afirmação limitada do escopo do sistema.
(e) um conjunto de cenários que fornecem informações sobre o uso do sistema sob diferentes condições de
operação.
49
49. É correto afirmar que
(a) um relatório não é um artefato de sistema.
(b) segurança não é um requisito não funcional de sistema.
xx
(c) um executável é um artefato de sistema.
(d) os atributos de uma classe UML são especificações dos seus métodos.
(e) confiabilidade é um requisito funcional de sistema.
50. O modelo FURPS, para melhoria de qualidade de software, representa as dimensões, que são mais
50
relevantes para os clientes:
xx
(a) Funcionalidade, Usabilidade, Confiabilidade, Desempenho e Suportabilidade.
(b) Funcionalidade, Usabilidade, Reusabilidade, Pontualidade e Suportabilidade.
(c) Flexibilidade, Usabilidade, Conformidade, Desempenho e Atendimento.
(d) Flexibilidade, Usabilidade, Reusabilidade, Performance e Suportabilidade.
(e) Integridade, Usabilidade, Conformidade, Portabilidade e Atendimento.
51. Segundo o modelo CMM, migrar do nível 3 de maturidade para o nível 4 representa uma melhoria da
51
qualidade de processos
(a) otimizados para processos gerenciados.
(b) definidos para processos repetíveis.
xx
(c) definidos para processos gerenciados.
(d) gerenciados para processos otimizados.
(e) repetíveis para processos definidos.

55
 TI para concursos
52. O metamodelo CMMI contínuo define que cada área de processo é avaliada formalmente, com base em
52
metas e práticas específicas, e classificada de acordo com seis níveis de capacitação. O nível 3 é o
(a) Quantitativamente gerido.
(b) Realizado.
xx
(c) Definido.
(d) Gerido.
(e) Otimizado.
53
53. NÃO é um dos sete princípios (David Hooker) da Engenharia de Software:
(a) manter a coisa simples.
xx
(b) não especificar requisitos detalhadamente.
(c) estar aberto para o futuro.
(d) planejar o reúso com antecedência.
(e) manter a visão.
54. NÃO é uma das nove características em um tratamento detalhado das métricas de software (Whitmire) para o
54
modelo de projeto orientado a objeto:
xx
(a) o custo.
(b) o tamanho.
(c) a complexidade.
(d) o acoplamento.
(e) a coesão.
55. O método que busca medir esforço, prazo, tamanho de equipe e custo necessário para o desenvolvimento do
software, desde que se tenha a dimensão do mesmo, por meio de um modelo de estimativa de tamanho de
55
software (Boehm) é o
(a) Function Point Analysis.
(b) CoCoMo.xx
(c) Work Breakdown Structure.
(d) Benchmarking.
(e) Flowcharting.
(ICMS-SP 2009) Instruções: Para responder às três próximas questões, considere a tabela e os dados de
referência para os cálculos de pontos de função.

Pontuação por complexidade de função

Tipos Simples Médio Complexo
EE 3 4 6
SE 4 5 7
CE 3 4 6
ALI 7 10 15
AIE 5 7 10

56
 TI para concursos
Níveis de Influência:
0 − Nenhuma influência.
1 − Influência mínima.
2 − Influência moderada.
3 − Influência média.
4 − Influência significante.
5 − Influência forte.
Características Gerais de Sistema:
1. Comunicação de Dados.
2. Processamento de Dados Distribuído (Funções Distribuídas).
3. Performance.
4. Configuração do equipamento.
5. Volume de Transações.
6. Entrada de Dados On line.
7. Interface com o usuário.
8. Atualização On line.
9. Processamento Complexo.
10. Reusabilidade.
11. Facilidade de Implantação.
12. Facilidade Operacional.
13. Múltiplos Locais.
14. Facilidade de mudanças.
56. (ICMS-SP 2009) Durante o levantamento de requisitos de um sistema, foram apuradas as seguintes
56
informações, base para o cálculo de pontos de função:
Complexidade de:
− Entrada: 2 complexas , 4 médias e 5 simples.
− Saída: 10 médias e 3 simples.
− Arquivo mantido dentro da fronteira do sistema: 1 complexo e 2 médios.
Sem nenhuma influência, o resultado apurado foi
(a) 133
(b) 138
xx
(c) 140
(d) 149
(e) 161
57. (ICMS-SP 2009) Mantida a pontuação bruta obtida na questão de número 22 e considerando que as
influências por características gerais do sistema foram estimadas como:
− Forte em performance.
− Significante em entrada de dados on line e em processamento distribuído.
− Demais características sem influência.
57
O resultado final mais aproximado, após o ajuste, foi
(a) 98,0
(b) 107,8
(c) 110,6
xx
(d) 109,2
(e) 116,0
58. (ICMS-SP 2009) Após um levantamento mais apurado do sistema referido, funções foram modificadas,
adicionadas ou excluídas e, em razão das modificações sugeridas, chegou-se às seguintes e novas
informações:
Complexidade de:
− Consulta: 5 complexas, 10 médias e 11 simples.
− Arquivo mantido fora da fronteira do sistema: 1 complexo e 1 médio.
− Entrada: 2 complexas, 4 médias e 5 simples.
− Saída: 5 complexas, 10 médias e 3 simples.
− Arquivo mantido dentro da fronteira do sistema: 3 complexos, 1 médio e 4 simples.
As novas influências por características gerais do sistema foram estimadas como:
− Forte em performance.
− Significante em entrada de dados on line, em processamento distribuído, em facilidade de mudanças e em
interface com o usuário.
− Mínima em volume de transações.
− Moderada em comunicação de dados.
− Demais características sem influência.
58
Com base nessas novas informações levantadas, o resultado final mais aproximado, após o ajuste, foi
(a) 263,7
(b) 298,9
(c) 300,5
xx
(d) 305,3
(e) 432,8

57
 TI para concursos
59. Considere 1952 pontos por função brutos e a aplicação do valor 3 a todos os fatores de ajuste. Os pontos por
59
função ajustados são
(a) 1268,80.
(b) 1542,08.
(c) 1815,36.
xx
(d) 2088,64.
(e) 2635,00.
60. Durante a medição do grau de complexidade de um sistema foram apurados 550 pontos de função brutos.
Considerando que o somatório dos graus atribuídos aos fatores de ajuste foi 30, a medida final em pontos de
60
função foi
(a) 520
xx
(b) 522,5
(c) 552,5
(d) 580
(e) 585,5
61. Se em uma seqüência de atividades de um projeto todas elas tiverem retardo de zero dias em relação às
61
suas predecessoras
(a) o projeto é inviável.
(b) isso indica a ausência de caminho crítico.
xx
(c) essa seqüência é o caminho crítico.
(d) a seqüência está errada.
(e) o projeto deve ser desmembrado.
62. Um Plano de Projeto de Software é um documento gerencial que se destina a um público diverso e NÃO
62
deve conter
(a) a comunicação do escopo e dos recursos à administração, aos clientes e à equipe técnica.
(b) a definição dos principais requisitos e dos riscos com sugestões técnicas para, respectivamente,
atendêlos ou evitá-los.
(c) o desenho dos componentes do software para planejar a sua instalação e operacionalização.
xx
(d) a definição dos custos e dos prazos para as revisões administrativas do projeto.
(e) a apresentação de uma abordagem global do desenvolvimento do software para todas as pessoas
envolvidas no projeto.

58
 TI para concursos

5 Arquitetura de Software
5.1 Conceitos básicos
A arquitetura de software de um sistema consiste dos componentes de software, suas propriedades
externas e seus relacionamentos com outros softwares. O termo também se refere à documentação da
arquitetura de software do sistema. A documentação da arquitetura do software facilita a comunicação
entre os stakeholders, registra as decisões iniciais acerca do projeto de alto nível e permite o reuso do
projeto dos componentes e padrões entre projetos.28
A arquitetura de software é organizada em visões, que descrevem a arquitetura na perspectiva de um
conjunto de pessoas interessadas, como:
 Visão funcional/lógica
 Visão de código
 Visão de desenvolvimento/estrutural
 Visão de concorrência/processo/thread
 Visão física/evolutiva
 Visão de ação do usuário/feedback
Várias linguagens para descrição da arquitetura de software foram inventadas, mas nenhum consenso
foi ainda alcançado em relação a qual conjunto de símbolos ou sistema representação deve ser
adotado. Alguns acreditam que a UML irá estabelecer um padrão para representação de arquitetura de
software. Outros acreditam que os desenvolvimentos efetivos de software devem contar com a
compreensão única das restrições de cada problema, e notações tão universais são condenadas a um
final infeliz porque cada uma provê um notação diferenciada que necessariamente torna a notação inútil
ou perigosa para alguns conjuntos de tarefas. Eles apontam a proliferação de linguagens de
programação e a sucessão de tentativas falhas para impor uma simples 'linguagem universal' na
programação, como uma prova da tendência do software para a diversidade e não para padrões.
Há muitas formas comuns de projetar módulos de software de computador e suas comunicações, entre
elas:
 Cliente-Servidor
 Computação distribuída
 P2P
 Blackboard
 Criação implícita
 Pipes e filtros
 Plugin
 Sistema Monolítico
 Modelo em três camadas
 Analise de sistema estruturada (baseada em módulos, mas usualmente monolíticas em dentro dos
módulos)
 Arquitetura orientada a serviço
 Arquitetura orientada a busca

5.2 UML
A Unified Modeling Language (UML) é uma linguagem de modelagem não proprietária de terceira
geração que auxilia a visualizar o desenho e a comunicação entre objetos de um sistema de
29
informações.
Basicamente, a UML permite que desenvolvedores visualizem os produtos de seu trabalho em
diagramas padronizados. Junto com uma notação gráfica, a UML também especifica significados
(semântica).
RUP (Rational Unified Process) é um processo proprietário criado pela Rational Software Corporation,
adquirida pela IBM, ganhando um novo nome IRUP que agora é uma abreviação de IBM Rational
Unified Process, que usa a abordagem da orientação a objetos em sua concepção e é projetado e
documentado utilizando a notação UML para ilustrar os processos em ação.

28 http://pt.wikipedia.org/wiki/Arquitetura_de_software
29 http://pt.wikipedia.org/wiki/UML
59
 TI para concursos
Os objetivos da UML são: especificação, documentação, e estruturação para sub-visualização e maior
visualização lógica do desenvolvimento completo de um sistema de informação. A UML é um modo de
padronizar as formas de modelagem.
O UML se compõe de diversos diagramas, cada um para um tipo diferente de visão.
 Diagramas Comportamentais
 Diagrama de Caso de Uso - descreve a funcionalidade proposta para o novo sistema. Um desenho com
representação de um ator, humano ou entidade máquina, que interage (relação) com o sistema (casos de
uso) para executar um trabalho. Estes relacionamentos podem ser:
 associações entre atores e casos de uso. Define uma funcionalidade do sistema do ponto de vista do
usuário.
 generalizações entre os atores. Os casos de uso de um ator são também casos de uso do outro, que tem
seus próprios casos de uso.
 generalizações entre os casos de uso. O caso de uso B é um caso de uso A (A é uma generalização de
B, ou B é uma especialização de A). Um relacionamento entre um caso de uso genérico para um mais
específico, que herda todas as características de seu pai.
 extensões entre os casos de uso. Um relacionamento extend de um caso de uso B para um caso de uso
A indica que o caso de uso B pode ser acrescentado para descrever o comportamento de A (não é
essencial). A extensão é inserida em um ponto de extensão do caso de uso A.
 inclusões entre os casos de uso. Um relacionamento include de um caso de uso A para um caso de uso
B indica que B é essencial para o comportamento de A. Pode ser dito também que B is_part_of A ou que
A depende de B.
 Diagrama de transição de estados - representação do estado ou situação em que um objeto pode se
encontrar no decorrer da execução de processos de um sistema.
 Diagrama de atividade - mostra o fluxo de controle de uma atividade para outra.
 Diagramas Estruturais
 Diagrama de classes - representação da estrutura e relações das classes que servem de modelo para
objetos. Uma propriedade, atributo ou operação representada no diagrama de classes, que poderá ser vista
e usada apenas pela classe na qual foi declarada, bem como pelas suas classes descendentes, deve ser
definida com visibilidade descrita por meio da palavra-chave protected.
 Diagrama de objetos - mostra os objetos que foram instanciados das classes. Exibe um único conjunto de
objetos relacionados uns com os outros em um determinado momento
 Diagrama de componentes - utilizado para modelar os componentes do código fonte do software.
 Diagrama de instalação - descreve os componentes de hardware e software e sua interação com outros
elementos de suporte ao processamento.
 Diagrama de pacotes - descreve grupos de classes, de outros elementos ou pedaços do sistema divididos
em agrupamentos lógicos mostrando as dependências entre estes.
 Diagrama de estrutura - descreve a colaboração interna de classes, interfaces ou componentes para
especificar uma funcionalidade.
 Diagramas de Interação
 Diagrama de sequência - representa a sequência de mensagens passadas entre objetos num programa de
30
computador. Utiliza-se também o termo cenário associado com diagramas de seqüência.
 Diagrama de Interatividade – descreve o fluxo de atividades mostrando como elas trabalham em uma
sequência de eventos.
 Diagrama de colaboração ou comunicação - exibe uma interação, consistindo de um conjunto de objetos e
seus relacionamentos, incluindo as mensagens que podem ser trocadas entre eles.
 Diagrama de tempo - apresenta o comportamento dos objetos e sua interação em uma escala de tempo,
focalizando as condições que mudam no decorrer desse período.
Também se utiliza de elementos para sua representação:
 De estrutura:
 Classe
 Classe ativa
 Interface
 Componente
 Colaboração
 Nó (cubo) - objeto físico em tempo de execução que representa um recurso computacional, possuindo,
geralmente, pelo menos uma memória, bem como, uma capacidade de processo. Objetos em tempo de
execução e componentes podem residir em nó. Graficamente, um Nó é representado pelo desenho de um
Cubo.

30 http://www.macoratti.net/vb_uml2.htm
60
 TI para concursos
 De comportamento:
 Casos de uso
 Iteração
 Máquina de estados
 De agrupamento:
 Pacote
 Modelo
 Subsistema
 Framework
 De anotação:
 Notas
 De relacionamentos
 Associação (bidirecional ou unidirecional)
 Generalização
 Composição

5.3 GED - Gerenciamento Eletrônico de Documentos e Workflow31

GED é definido como a "tecnologia que facilita o armazenamento, localização e recuperação de
informações estruturadas ou não, em formato digital, durante todo o seu ciclo de vida". De forma geral,
essas soluções são compostas pelos módulos de Document Imaging, COLD/ERM e Document
Management:
Document Imaging (DI) – Gerenciamento de Imagens: esse módulo é responsável pela transformação
do documento papel em uma imagem digital, permitindo a sua manipulação nesse ambiente. Esse
processo abrange três etapas: a digitalização do documento por meio de um scanner, seu
armazenamento (gravação em CD-ROM, DVD, Disco Óptico ou Disk Array) e o gerenciamento
(consultas, pesquisas etc.) das informações em meio digital.

COLD/Enterprise Report Management - Gerenciamento de Relatórios Corporativos: COLD (Computer

Output to Laser Disk) substitui a tecnologia COM (Computer Output to Microfilm) como forma de
armazenar grandes volumes de dados provenientes de sistemas computadorizados (arquivos spool).
Em vez de serem impressos, os relatórios são gravados em mídia magnética/óptica e disponibilizados
aos usuários, para consulta, no vídeo, por meio de um visualizador próprio.
Document Management (DM) – Gerenciamento de Documentos: tem por objetivo o controle e
armazenamento de documentos produzidos por programas de computador, tais como: Word, Excel,
PowerPoint etc. Uma funcionalidade interessante de módulos desse tipo é a utilização de serviços de
biblioteca que possibilitam o controle das diversas versões de um documento.
Com o crescimento da Internet, surgiu o termo Web Content Management (WCM), que trata do
gerenciamento do conteúdo de informações e o que o diferencia do DM, da publicação desse conteúdo
na Web.
Uma vez organizada a informação na empresa, precisamos conhecer o fluxo do processo do negócio,
em outras palavras, o seu Workflow. Este é um conceito antigo que sempre existiu nas organizações. A
novidade está na automação do controle do fluxo dos processos e o Workflow funciona como elemento
aglutinador das ações pontuais de cada uma das etapas dos processos.
O foco principal reside em saber quem fez que parte do trabalho, em que ordem e sob quais condições
(os 3Rs do Workflow – Routes /Rotas, Roles/Papéis e Rules/ Regras). Para sua utilização é primordial
que o trâmite de documentos, com as etapas e atividades envolvidas, esteja completamente
sistematizado.
Podemos conceituar Workflow como o elemento responsável por gerenciar o fluxo dos processos da
empresa permitindo um controle automático de tarefas, eventos e prazos, com o intuito de atingir os
objetivos do negócio. As diversas soluções de Workflow podem ser grupadas nas seguintes classes:
 Produção: processos de missão crítica de relevante valor agregado, com alto grau de estruturação
nas regras de roteamento, controle e acompanhamento e com volume significativo de ocorrências
repetitivas.

31 http://www.serpro.gov.br/imprensa/publicacoes/tematec/2001/ttec57
61
 TI para concursos
 Colaborativo: coordenação das atividades de um grupo de pessoas, trabalhando juntas para a
execução de um projeto, porém com regras e fluxos de baixo grau de estruturação.
 Administrativo: processos administrativos com baixo valor agregado ao negócio e orientados para o
roteamento de formulários e de documentos com baixo grau de estruturação.
 Ad-hoc: processos eventuais com regras e fluxos com baixo grau de estruturação.
Enquanto em um sistema tradicional o trâmite do processo necessita de intervenção humana, ou seja,
é passivo, em um sistema de Workflow isso é realizado de forma automática. Para tal, os sistemas de
Workflow, independente de sua classe, abrangem diversas funções, dentre as quais podemos destacar:
 Seqüenciamento: controle da seqüência de execução das diversas atividades do processo;
 Controle de Tempo: estabelecimento de limites de tempo para a realização das tarefas;
 Roteamento: caminhos alternativos de execução das tarefas (seqüencial, paralelo e condicional);
 Atribuição de Papéis: capacidade de rotear uma ação para um papel/perfil de usuário quando uma
condição for satisfeita ou um prazo se esgotar;
 Monitoramento: facilidade de acompanhar a situação das tarefas e o trâmite das ações tomadas no
processo.
Os principais pontos positivos do uso dessas soluções são: o aumento de produtividade, a redução de
custo com papel, o aumento da segurança devido à eliminação do trâmite de documentos originais, a
redução do espaço de armazenamento, a mobilidade dos arquivos (contingência), a redução do tempo
de respostas para acesso às informações e a agilidade no tratamento de exceções (Workflow).
No que diz respeito às dificuldades encontradas, elas são referentes a barreiras culturais, à exigência
de mudança comportamental dos usuários que não dispõem mais do papel, à falta de sistematização e
padronização dos procedimentos da corporação e ao receio do desemprego, principalmente com a
implantação de aplicações de Workflow.
A utilização da tecnologia de Workflow deve ser considerada na implantação de sistemas tipicamente
processuais, cujo trâmite do processo possa ser automatizado, onde haja necessidade de controle do
tempo de execução das tarefas e com diversas pessoas participando do processo.
O Workflow evoluiu de sistemas que implementavam fluxos de documentos, para funcionar também
como integrador. Além disso, existe uma tendência crescente em se utilizar a Web para a entrada de
formulários, a distribuição de documentos e o envio de mensagens de alerta por e-mails. Na Internet,
onde mecanismos adicionais de segurança são preponderantes, surge a necessidade do uso de
criptografia e certificação digital para a execução de determinadas funções do fluxo do processo.
O Gerenciamento Eletrônico de Documentos está convergindo para Gerenciamento de Conteúdo
Corporativo (Enterprise Content Management), devendo gerir não apenas os documentos da empresa
como também os conteúdos provenientes de sistemas legados, bancos de dados, sistemas de imagem,
COLD, DM e qualquer outro arquivo digital, através de uma interface única baseada em browser.

5.3.1 Exercícios
63. (ICMS-SP 2009) A tecnologia de armazenamento de relatórios em discos óticos (COLD) envolvida no GED é
63
tratada como sinônimo de
(a) DI – Document Imaging.
(b) DM – Document Management.
(c) FP – Forms Management.
xx
(d) ERM – Enterprise Report Management.
(e) RIM – Records and Information Management.
64
64. (ICMS-SP 2009) Workflow é uma tecnologia aplicada no GED que está diretamente envolvida com
(a) KM.
xx
(b) BPM.
(c) ERP.
(d) CRM.
(e) SCM.

62
 TI para concursos

5.4 Arquitetura Orientada a Serviço (SOA)

Service-oriented architecture (SOA) é um estilo de arquitetura de software cujo princípio fundamental
preconiza que as funcionalidades implementadas pelas aplicações devem ser disponibilizadas na forma
de serviços. Freqüentemente estes serviços são organizados através de um "barramento de serviços"
(enterprise service bus, em inglês) que disponibiliza interfaces, ou contratos, acessíveis através de web
services ou outra forma de comunicação entre aplicações. A arquitetura SOA é baseada nos princípios
da computação distribuída e utiliza o paradigma request/reply para estabelecer a comunicação entre os
32
sistemas clientes e os sistemas que implementam os serviços.
Além da perspectiva estritamente técnica, a arquitetura orientada a serviços também se relaciona com
determinadas políticas e conjuntos de "boas práticas" que pretendem criar um processo para facilitar a
tarefa de encontrar, definir e gerenciar os serviços disponibilizados.
A arquitetura orientada a serviços também se insere em um processo de reorganização dos
departamentos de tecnologia da informação das organizações, permitindo um melhor relacionamento
entre as áreas que dão suporte tecnológico à empresa e as áreas responsáveis pelo negócio
propriamente dito, graças a maior agilidade na implementação de novos serviços e reutilização dos
ativos existentes.

5.4.1 Serviço
Um serviço, do ponto de vista da arquitetura SOA, é uma função de um sistema computacional que é
disponibilizado para outro sistema. Um serviço deve funcionar de forma independente do estado de
outros serviços, exceto nos casos de serviços compostos (composite services), e deve possuir uma
interface bem definida. Normalmente, a comunicação entre o sistema cliente e aquele que disponibiliza
o serviço é realizada através de web services.

5.4.2 Processos
A Arquitetura Orientada a Serviços pode ser bem representada a partir do seguinte processo, chamado
de "find-bind-execute paradigm" o que significa aproximadamente paradigma de "procura-consolida-
executa". Tal conceito é análogo a "Ciclo de Deming" aplicado aos serviços, que define o ciclo que
envolve o planejamento, a execução, o monitoramento e a tomada de ação pró-ativa para a melhoria
da qualidade.
Esquema adaptado do paradigma "find-bind-execute", tecnicamente falando, o processo preconiza que
os provedores de serviços registrem informações em um registro central, com suas características,
indicadores, e aspectos relevantes às tomadas de decisões. O registro é utilizado pelo cliente para
determinar as características dos serviços necessários, e se o mesmo estiver disponível no registro
central, como por exemplo por um catálogo de serviços, o cliente poderá utilizá-lo, sendo este
oficializado através de um contrato que enderece este serviço.

5.4.3 Tecnologia
O termo "Service-Oriented Architecture" (SOA) ou Arquitetura Orientada a Serviços expressa um
conceito no qual aplicativos ou rotinas são disponibilizadas como serviços em uma rede de
computadores (Internet ou Intranets) de forma independente e se comunicando através de padrões
abertos. A maior parte das implementações de SOA se utilizam de Web services (SOAP , REST e
WSDL). Entretanto, uma implementação de SOA pode se utilizar de qualquer tecnologia padronizada
baseada em web.

5.4.4 Definições de SOA

O SOA coloca a prestação de serviço como eixo de todo o negócio, dando destaque à gestão de
serviços e ao cliente.
 Serviço - É uma função independente, sem estado (stateless) que aceita uma ou mais requisições e
devolve uma ou mais respostas através de uma interface padronizada e bem definida. Serviços
podem também realizar partes discretas de um processo tal como editar ou processar uma
transação. Serviços não devem depender do estado de outras funções ou processos. A tecnologia
utilizada para prover o serviço, tal como uma linguagem de programação, não pode fazer parte da
definição do serviço.
 Orquestração - Processo de sequenciar serviços e prover uma lógica adicional para processar
dados. Não inclui uma representação de dados.

32 http://pt.wikipedia.org/wiki/Service-oriented_architecture
63
 TI para concursos

 Stateless Não depende de nenhuma condição pré-existente. Os serviços não devem

depender de condições de outros serviços. Eles recebem todas as informações necessárias para
prover uma resposta consistente. O objetivo de buscar a característica de stateless dos serviços é
possibilitar que o consumidor do serviço possa sequenciá-lo, ou seja, orquestrá-los em vários fluxos
(algumas vezes chamados de pipelines) para executar a lógica de uma aplicação.
 Provedor O recurso que executa o serviço em resposta a uma requisição de um consumidor.
 Consumidor - É quem consome ou pede o resultado de um serviço fornecido por um provedor.
 Descoberta - SOA se baseia na capacidade de identificar serviços e suas características.
Conseqüentemente, esta arquitetura depende de um diretório que descreva quais os serviços
disponíveis dentro de um domínio.
 Binding - A relação entre os serviços do provedor e do consumidor deve ser idealmente dinâmica;
ela é estabelecida em tempo de execução através de um mecanismo de binding.

5.4.5 Web Services

Web Service é um componente de software identificado por uma URI – Identificador de Recursos
Uniforme, uma cadeia de caracteres compacta usada para identificar ou denominar um recurso na
Internet – que independe de implementação ou de plataforma e pode ser descrito, publicado e invocado
sobre uma rede por meio de mensagens padrão XML. As mensagens XML são transportadas usando
protocolos padrões da Internet. Com web service é possível realizar a integração entre sistemas
desenvolvidos em diferentes linguagens e plataforma, e disponibilizar serviços interativos na Web. é
uma tecnologia de padrão aberto e padronizada pelo W3C.
A arquitetura do Web Service é constituída por três componentes básicos:
 o servidor de registro (broker server ou service registry)
 o provedor de serviços (service provider)
 o solicitante de serviços (service requestor). As interações entre esses componentes são de
busca, publicação e interação de operações.
Na operação de publicação o provedor publica a descrição do serviço de tal forma que um solicitante
possa localizá-la. Na operação de busca o solici-tante obtém a descrição do serviço diretamente ou
consulta o servidor de registro procurando pelo tipo de serviço desejado. Essa operação pode ser
executada em duas fases distintas: desenvolvimento ou execução. Na operação de interação o
solicitante chama ou inicia uma interação com o provedor, em tempo de ex-ecução, utilizando os
detalhes contidos na descrição do serviço para lo calizar, contactar e chamar o serviço. A figura 26.1
mostra os componentes e a interação entre eles.
O provedor de serviços representa a plataforma que hospeda o web service permitindo que os clientes
acessem o serviço. O provedor de serviços fornece o serviço e é responsável por publicar a descrição
do serviço que provê. O solic-itante de serviços é a aplicação que está procurando, invocando uma
interação com o web service, ou seja, requisita a execução de um serviço. O solicitante de serviço pode
ser uma pessoa acessando por meio do browser ou uma aplicação realizando uma invocação aos
métodos descritos na interface do web service. O servidor de registro é um repositório central que
contém a descrição (informação) de um web service, e é por meio do servidor de registro que essas
descrições são publicadas e disponibilizadas para localização.

Figura 26.1: Componentes básicos da arquitetura do Web Service

Os clientes buscam por serviços no servidor de registro e recuperam informações referentes à interface
de comunicação para os web service durante a fase de desenvolvimento ou durante a execução do
cliente, denominadas in-teração estática (static bind) e interação dinâmica (dinamic bind), respecti-
64
 TI para concursos
vamente. Na interação estática, o cliente recupera a assinatura do serviço, necessária à codificação.
Na interação dinâmica, o cliente recupera os valores de parâmetros e a localização do serviço.
O ciclo de vida de um web service compreende quatro estados distintos, figura 26.2:
Publicação processo, opcional, por meio do qual o fornecedor do web services dá a conhecer a
existência do seu serviço, efetuando o registro do mesmo no repositório do web service;
Descoberta processo, opcional, por meio do qual uma aplicação cliente toma conhecimento da
existência do web services pretendido pesquisando num repositório UDDI;
Descrição processo pelo qual o web service expõe a sua API (documento WSDL). Desta maneira a
aplicação cliente tem acesso a toda a interface do web service, onde encontram descritas todas as
funcionalidades por ele disponibilizadas;
Invocação (Mensagens) processo pelo qual o cliente e o servidor interagem, por meio do envio de
mensagens;
A conjugação desses quatro estados permite constituir o ciclo de vida de um web service:
O fornecedor constrói o serviço utilizando a linguagem de programação que entender;
 De seguida, especifica a interface/assinatura do serviço que definiu em WSDL;
 Após a conclusão dos dois primeiros passos, o fornecedor registra o serviço no UDDI;
 O utilizador (aplicação cliente) pesquisa num repositório UDDI e encontra o serviço;
 A aplicação cliente estabelece a ligação com o web service e estabelece um diálogo com este, via
mensagens SOAP.

Figura 26.2: Ciclo de vida do web service

A interação entre os web services se dá sob vários protocolos abertos, em diferentes níveis de
abstração. Os protocolos utilizados para realizar a comu-nicação são o: UDDI (Universal Description
Discovery and Integration), WSDL (Web Services Description Language), XML, SOAP (Simple Object
Access Pro-tocol) e o HTTP, conforme figura 26.3.

Figura 26.3: Protocolos de comunicação de Web services

As mensagens trocadas são formatadas no protocolo SOAP, o que permite a interoperabilidade entre
diferentes plataformas, em um processo denominado serialização XML. Porém, antes que as
mensagens SOAP sejam trocadas, suas características são explicitadas por meio de documentos
WSDL, que descrevem quais dados estarão sendo trocados, e como estes dados estarão organizados
nas mensagens SOAP. Adicionalmente, os serviços dos web services podem ser publicados através de
UDDI, que é um formato utilizado para seu armazenamento em repositórios disponíveis na Internet.
Assim, se um desenvolvedor precisar resolver uma determinada tarefa, pode encontrar o web service
que mais se adequar à sua necessidade.
Como os firewalls convencionais e proxies não bloqueiam a porta utilizada pelo protocolo HTTP, não
existem grandes restrições para o uso deste tipo de aplicação em redes de longa distância.

65
 TI para concursos
Pode-se definir, resumidamente, o web service como sendo um serviço de software disponibilizado na
Internet, descrito com um arquivo WSDL, registrado via UDDI, acessado utilizando SOAP e com dados
representados em XML sendo transmitidos via HTTP.
A disseminação no uso de web services nos últimos anos incentivou o mercado a oferecer uma grande
variedade de ferramentas e aplicações para prover suporte a essa tecnologia. Atualmente, as principais
plataformas para web services são:
Sun Microsystems, IBM, BEA, Apache, Systinet e Microsoft.

5.4.6 SOAP
Simple Object Access Protocol é um protocolo leve para troca de informações em um ambiente
descentralizado e distribuído que permite comunicação entre aplicações de forma simples e
completamente independente de sistema operacional, linguagem de programação ou plataforma. É o
protocolo de comunicação para os Web Services.
A comunicação é realizada por meio de trocas de mensagens, transmitidas em formato XML, incluindo
os parâmetros usados nas chamadas, bem como os dados de resultados. Também pode ser utilizado
para invocar, publicar e localizar web services no registro UDDI.
Parte da sua especificação é composta por um conjunto de regras de como utilizar o XML para
representar os dados. Outra parte define o formato de mensagens, convenções para representar as
chamadas de procedimento remoto (RPC – Remote Procedure Calls) utilizando o SOAP, e associações
ao protocolo HTTP. O protocolo HTTP é o único protocolo padronizado pelo SOAP, mas existem
algumas implementações que suportam outros protocolos como SMTP, TCP/IP, FTP e etc.
Uma mensagem SOAP é um fragmento XML bem formado, encapsulado por um par de elementos
SOAP. A mensagem SOAP consiste dos seguintes elementos:
 Envelope toda mensagem SOAP deve contê-lo. é o elemento raiz do do
cumento XML. Define o início e o fim das mensagens;
 Header é um cabeçalho opcional. Ele carrega informações adicionais, como
exemplo, se a mensagem deve ser processada por um nó intermediário.
Quando utilizado, o Header deve ser o primeiro elemento do envelope;
 Body é obrigatório e contém o payload, os dados em XML a serem
transportados. O elemento Body possui um campo opcional Fault, usado
para car-regar mensagens de status e erros retornadas pelos ”nós”ao pro
cessarem a mensagem;

Figura 26.4: Estrutura da mensagem SOAP

RPCs ou chamadas remotas de procedimento são chamadas locais a métodos de objetos (ou serviços)
remotos. Portanto, pode-se acessar os serviços de um objeto localizado em outro ponto da rede,
através de uma chamada local a este objeto. Cada chamada ou requisição exige uma resposta.
O pro cesso de uma chamada RPC: Antes de serem enviadas pela rede, as chamadas de RPC
(emitidas pela aplicação cliente) são encapsuladas (ou serial-izadas) segundo o padrão SOAP. O
serviço remoto, ao receber a mensagem faz o processo contrário, desencapsulando-a e extraindo as
chamadas de méto do. A aplicação servidora então processa esta chamada, e envia uma resposta ao
cliente. O processo então se repete: a resposta é também serializada e enviada pela rede. Na máquina
cliente, esta resposta é desencapsulada e é repassada para a aplicação cliente.
A especificação SOAP define as seguintes informações, como necessárias em toda chamada de RPC:
 A URI do objeto alvo;
 O nome do método;
 Os parâmetros do método (requisição ou resposta);
66
 TI para concursos
 Uma assinatura do método opcional;
 Um cabeçalho (header) opcional.

5.4.7 WSDL
O WSDL (Web Services Description Language) é uma linguagem baseada em XML, utilizada para
descrever um web service. Um web service deve definir todas as suas interfaces, operações,
esquemas de codificação, o conteúdo das mensagens, onde o serviço está disponível e quais os
protocolos de comunicação são usados para conversar com o serviço e entre outros neste documento.
Um documento WSDL define um XML Schema para descrever um web service.
A descrição de um serviço consiste de duas partes: definição de implementação do serviço e definição
da interface do serviço. A separação entre as duas camadas permite que elas sejam utilizadas
separadamente.

A parte de definição de interface do serviço descreve o web service, incluindo métodos que são
invocados e parâmetros que são enviados. A parte de definição de implementação de serviços
descreve como uma interface de serviço é im-plementada por um provedor: onde o serviço está
instalado e como pode ser acessado. As descrições dos elementos das duas partes:
 Binding descreve protocolos, formato de data, segurança e outros atributos para uma interface
(portType) em particular;
 Porttype informa elementos de operações do web service;
 Message define entrada e saída de dados referentes a operações;
 Type define tipos de dados complexos em uma mensagem;
 Service contém uma coleção de elementos port com elementos binding;
 Port é a combinação de um binding com endereço de rede, fornecendo o endereço alvo para a
comunicação dos serviços.
Tão logo o cliente tenha acesso à descrição do serviço a ser utilizado, a implementação do Web
Service pode ser feita em qualquer linguagem de pro-gramação. Normalmente são utilizadas linguagem
construídas para interação com a Web, como exemplo Java Servlets ou ASP, que, em seguida,
chamam um outro programa ou objeto.
Basicamente, quando o cliente deseja enviar uma mensagem para um deter-minado web service, ele
obtém a descrição do serviço (através da localização do respectivo documento WSDL), e em seguida
constrói a mensagem, passando os tipos de dados corretos (parâmetros, etc) de acordo com a
definição encontrada no documento. As duas partes envolvidas em uma interação web service pre-
cisam ter acesso à mesma descrição WSDL para conseguirem entender uma à outra. Em seguida, a
mensagem é enviada para o endereço onde o serviço está localizado, a fim de que possa ser
processada. O web service, quando recebe esta mensagem valida-a conforme as informações contidas
no documento WSDL. A partir de então, o serviço remoto sabe como tratar a mensagem, sabe como
processá-la (possivelmente enviando-a para outro programa) e como montar a resposta ao cliente.

5.4.8 UDDI
Para que um serviço seja utilizado é necessário que o cliente consiga localizá-lo, e essa localização
pode ser feita por meio do UDDI (Universal Description, Discovery and Integration), que é uma
especificação técnica para descrever, descobrir e publicar web services.
Uma implementação de UDDI corresponde a um registro web service, que provê um mecanismo para
busca e publicação de web services. Um registro UDDI contém informações categorizadas sobre os
serviços e as funcionalidades que eles oferecem, e permite a associação desses serviços com suas
informações técnicas, geralmente definidas usando WSDL.

67
 TI para concursos
O UDDI possui um componente central chamado UDDI Project, que ma-nipula um registro global e
público chamado business registry. A informação oferecida pelo bussines registry consiste de três
componentes: white pages, yel-low pages e green pages.
A informação fornecida por um registro UDDI pode ser comparada à uma lista telefônica. As páginas
brancas (white pages), fornecem informações tais como nome da organização, contato e
identificadores. As páginas amarelas (yellow pages) são compostas por um índice de serviços e pro
dutos e as páginas verdes (green pages) contém informações a respeito de transações, descrições de
serviço e invocação de aplicações.
As informações contidas em arquivos de descrição de serviço (WSDL) com-pletam aquelas que estão
no registro. No entanto, UDDI não fornece suporte a vários tipos de descrição de serviço, mas não
suporta a criação de descrições WSDL de forma direta.
Uma descrição WSDL completa consiste da combinação dos documentos de interface e de
implementação de serviço. A primeira é publicada no registro UDDI como businessservice e a segunda
como tmodel.

5.4.9 Segurança
A segurança no envio de mensagens SOAP é um tópico importante. Em um nível mais baixo,
mensagens SOAP podem ser trocadas pela rede utilizando HTTPS ao invés de HTTP. Como HTTPS
utiliza SSL no seu transporte, fica garantida a proteção contra possíveis intervenções. Além disso, o
cliente e servidor podem verificar cada um suas respectivas identidades.
Embora HTTPS resolva o problema de proteção das mensagens contra possíveis invasores, este não
ajuda muito quando se necessita da segurança necessária para a autenticação de usuários de web
services específicos. Estes serviços irão fornecer algum tipo de combinação de usuário/senha durante
a fase inicial de registro no serviço e então esta será utilizada para acessos futuros. Não há ainda um
padrão de autenticação para Web services, mas pode utilizar os firewalls, VPNs, NTFS, produtos de
single-in para oferecer a autenticação e autorização de usuários.

5.4.10 Exercícios
65. (ICMS-SP 2009) Uma vantagem que o Web Service oferece
I. em relação à empresa que desenvolve uma DLL é que não precisa distribuí-lo para todos os clientes, pois
estará armazenado em um único lugar de onde será acessado.
II. é o acesso a ele, sempre por meio de http, mas internamente existe uma string XML que está empacotada
em um protocolo SOAP (Simple Object Access Protocol).
III. é ser transparente para o Firewall de uma empresa, pois, como é uma string XML, é interpretado como
um arquivo "texto", não precisando pedir autorização do Firewall para entrar.
65
Está correto o que consta em
xx
(a) I, II e III.
(b) I e II, apenas.
(c) I e III, apenas.
(d) II e III, apenas.
(e) II, apenas.
66
66. (ICMS-SP 2009) Para uma Web Service síncrona, quem chamou a função
(a) deve esperar o retorno para prosseguir e, para uma Web Service assíncrona, não precisa esperar o
xx
retorno, podendo manter mais uma linha de execução no código.
(b) deve esperar o retorno para prosseguir e, para uma Web Service assíncrona, não precisa esperar o
retorno, não podendo manter mais uma linha de execução no código.
(c) não precisa esperar o retorno, podendo manter mais uma linha de execução no código e, para uma Web
Service assíncrona, deve esperar o retorno para prosseguir.
(d) não precisa esperar o retorno, não podendo manter mais uma linha de execução no código e, para uma
Web Service assíncrona, deve esperar o retorno para prosseguir.
(e) não precisa esperar o retorno, tal qual para uma Web Service assíncrona, porém, para a forma síncrona
pode manter mais uma linha de execução no código e para a forma assíncrona não pode.

68
 TI para concursos
67. (ICMS-SP 2009) A Service-Oriented Architecture – SOA trata-se de
I. um conjunto de produtos para implementar aplicativos dinâmicos e ágeis, do tipo loosely couple.
II. uma meta a ser alcançada, ou seja, disponibilizar uma metodologia de implementação que usa padrões e
protocolos de linguagem específicos para execução de aplicativos.
III. soluções que não requerem uma renovação completa de tecnologia e de processo de negócios, que
devem ser incrementais e baseadas nos investimentos atuais.
IV. uma abordagem de design de sistemas que orientam como os recursos do TI serão integrados e quais
serviços serão expostos para o uso.
67
Está correto o que consta APENAS em
(a) I e II.
(b) I e IV.
xx
(c) III e IV.
(d) II e III.
(e) II e IV.
68. (ICMS-SP 2009) O Service-Oriented Architecture – SOA tem foco tanto nos negócios quanto em tecnologia
68
da informação, sendo que o SOA com foco em negócios normalmente inclui
(a) pessoas, processo e conectividade.
xx
(b) pessoas, processos e informações.
(c) reusabilidade, pessoas e processos.
(d) conectividade, processos e informações.
(e) conectividade, reusabilidade e informações.

5.5 Portais corporativos e colaborativos

Um portal é um site na internet que funciona como centro aglomerador e distribuidor de conteúdo para
uma série de outros sites ou subsites dentro, e também fora, do domínio ou subdomínio da empresa
gestora do portal.33
Na sua estrutura mais comum, os portais constam de um motor de busca, um conjunto, por vezes
considerável, de áreas subordinadas com conteúdos próprios, uma área de notícias, um ou mais fóruns
e outros serviços de geração de comunidades e um diretório, podendo incluir ainda outros tipos de
conteúdos.
Para construir um portal é aconselhável utilizar ferramentas de gestão de conteúdo (CMS) em vez de
tradicionais editores de HTML. Estes recursos ajudam a concentrar o trabalho num nível mais abstrato,
na medida em que alguns aspectos tecnológicos já são automatizados. Uma das vantagens no uso
dessas ferramentas é o fato de, na maior parte dos casos, possibilitar a troca do modelo de página sem
que o conteúdo e a sua disposição no site sejam alterados; apenas a aparência é modificada.
Os Portais Corporativos têm entre suas características, a funcionalidade de oferecer acesso
simplificado às informações e às aplicações, por utilizar o ambiente Web como sua camada de
apresentação. Desta forma, a interação com o usuário se torna mais amigável e as informações
apresentadas de forma mais simples e compreensível.
Os Portais podem oferecer acesso a um grande número de colaboradores às informações estruturadas
(informações armazenadas em sistemas e bases de dados, como por exemplo, datawarehouses e
sistemas legados), assim como às informações não estruturadas (informações armazenadas em
arquivos de texto, planilhas eletrônicas, arquivos de e-mail, dentre outros). O acesso a estas
informações estruturadas ou não estruturadas se dá na maioria das vezes através do uso de APIs
(Application Program Interfaces), também chamadas de applets, portlets, adaptadores ou conectores,
sendo o acesso às informações estruturadas mais facilitado, pois através das linguagens de
programação pode-se utilizar de APIs que facilitem ao colaborador acessar as informações através de
interfaces intuitivas e amigáveis. Já para acessar as informações não estruturadas, é necessário
utilizar, em conjunto com as APIs, métodos de categorização e taxonomia, mecanismos de busca.
Os métodos de categorização e taxonomia visam organizar as informações, criando informações sobre
as informações (metadados) para assim, os mecanismos de busca retornarem as informações que o
usuário deseja de forma mais precisa.
Em linhas gerais, os Portais Corporativos (como ambiente de integração de informações e sistemas)
facilitam a busca por informações nas diversas fontes disponíveis, agiliza a tomada de decisão e pode
gerar mais produtividade com a redução no tempo dispendido na procura pelas informações.
O termo Portal Corporativo, em relação à internet, começou a ser utilizado para definir os Portais de
pesquisa, como Google e Yahoo. Depois de um certo tempo, os provedores de acesso à internet

33 http://pt.wikipedia.org/wiki/Portal_(internet)
69
 TI para concursos
passaram a oferecer conteúdo para seus assinantes, na tentativa de ter algum diferencial, já que o
acesso discado era “commodity”.34
Existem quatro tipos de portais:
 Portais Informativos - Portais que levam informações ao usuários;
 Portais Colaborativos - Portais que habilitam as equipes de trabalho estabelecerem áreas de
projetos virtuais ou comunidades através de ferramentas de colaboração;
 Portais Especialistas - Portais que conectam pessoas com base em suas experiências, interesses e
informações que precisam;
 Portais do Conhecimento - Portais que combinam todas as características dos anteriores para
prover conteúdo personalizado com base no que cada usuário faz..
Um Portal Corporativo ou um Enterprise Information Portal é um conceito para um website que serve
como interface ou canal único para a informação de uma companhia e sua base de conhecimento para
seus colaboradores e, possivelmente, para clientes, parceiros de negócios e também para o público em
geral.
Para se classificar um software como Portal Corporativo é necessário ter:
 Access/search (poderosos sistemas de busca e indexação);
 Categorization (categorização do conhecimento);
 Collaboration (aplicações para colaboração);
 Personalization (cada usuário é um usuário diferente);
 Expertise and profiling (perfis de acordo com competências);
 Application integration (integração com demais aplicações);
 Security (segurança para todas as aplicações e login único).
Outra característica muito comum em um Portal Corporativo, são os Portlets ou Gadgets, que são
utilizados para integração de aplicações ou para personalização. Cada Portlet pode ser um “pedaço” de
página e nele é possível aplicar configurações de segurança, personalização, etc. Colaboração é a
palavra de ordem em Intranets e Portais Corporativos.
Um Portal Colaborativo é um portal corporativo com forte exploração de recursos colaborativos, ou
seja, de recursos que permitem a colaboração entre funcionários de uma ou mais empresas. Um
ambiente de colaboração deve permitir que pessoas que não se conheçam e que mesmo vivam em
países diferentes possam trabalhar de forma colaborativa usufruindo de recursos do portal colaborativo.
Portlets de Colaboração geralmente estão disponíveis em boas ferramentas de gerenciamento de
Intranets e Portais Corporativos. Os mais comuns são: enquetes, forums, chats, workplaces, wikis,
dentre outros. Também softwares sociais e comunidades virtuais contribuem para a colaboração
corporativa.
Os softwares de portais corporativos devem fornecer soluções colaborativas e permitir a integração de
aplicativos corporativos que promovam e construam a colaboração corporativa. Um portal corporativo
pode ser considerado um portal colaborativo quando o uso de seus recursos colaborativos supera o
uso do conteúdo e páginas de conteúdo. O módulo de gerenciamento de conteúdo ou mesmo o
gerenciador de conteúdo pode contribuir na produção de conteúdo colaborativo ou pelo menos suportar
a colaboração através do gerenciamento de conteúdo aliado aos portlets (componentes) colaborativos.

5.6 Exercícios
69. (ICMS-SP 2009) As ferramentas de modelagem de análise, que utilizam a notação UML, fornecem
69
capacidade de desenvolver modelos baseados em
(a) cenários, fluxos e dados.
(b) cenários, classes e dados.
xx
(c) cenários, classes e objetos.
(d) classes, fluxos e objetos.
(e) classes, fluxos e dados.

34 http://www.portalcolaborativo.com.br/midias-sociais/home/comunidades-em-portais.html
70
 TI para concursos
70. (ICMS-SP 2009) No bloco de back-office da arquitetura de sistema encontram-se os pacotes integrados de
gestão empresarial, cujos dados são armazenados nas formas transacionais, com ênfase na integração de
70
processos, identificados pela sigla
(a) CRM.
(b) SAF.
(c) PRM.
(d) SCM.
xx
(e) ERP.
71. (ICMS-SP 2009) A área de BI – Business Intelligence está diretamente envolvida com os projetos de
71
implementação das aplicações de
(a) B2B, B2C e BSC.
(b) EAI, B2B e B2C.
(c) EAI, CRM e ERP.
xx
(d) CI, KMS e BSC.
(e) CRM, PRM e ERP.
72. (ICMS-SP 2009) A utilização de ferramentas de groupware e de workflow, cujas informações gerais são
apresentadas sob a forma de textos, memorandos, gráficos, e-mails, boletins informativos, páginas Web e
72
arquivos multimídia, caracterizam o tipo de portal de
(a) informações empresariais.
(b) suporte à decisão.
(c) especialista.
(d) conhecimento.
xx
(e) cooperação.
73. (ICMS-SP 2009) As empresas que implementam portais corporativos por meio dos quais estabelecem
relacionamentos de negócios, com um certo nível de acoplamento eletrônico entre os seus sistemas de
73
compras, vendas, logística, distribuição e outros, adotam uma forma de e-Business conhecida por
(a) B2C.
(b) B2G.
xx
(c) B2B.
(d) C2B.
(e) C2C.
74
74. (FCC – TRT – SP/2008 - Analista) Na UML, a multiplicidade
(a) é aplicada aos atributos, somente.
(b) aplicada a uma classe é o número de instâncias que esta pode ter.xx
(c) indica a quantidade de atributos herdados por uma classe-filha em uma hierarquia de classes.
(d) aplicada nas associações entre classes indica o número de atributos comuns às classes envolvidas.
(e) aplicada a uma classe concreta é o número de operações que esta pode ter.
75. Dos diagramas definidos na UML 2.0, é aplicado na modelagem do comportamento de uma interface, classe
75
ou colaboração, o Diagrama de
(a) Componente.
(b) Objeto.
(c) Estrutura Composta.
(d) Pacote.
(e) Estado de Máquina.xx
76
76. Em um diagrama de Caso de Uso são admitidos os relacionamentos
(a) dependência, somente.
(b) dependência e generalização, somente.
(c) dependência, generalização e associação.xx
(d) associação, somente.
(e) dependência e associação, somente.
77
77. Em um Caso de Uso, um relacionamento de inclusão é a estereotipação
(a) dos Casos de Uso aos quais se relaciona.
(b) de uma Generalização.
(c) de uma Extensão.
(d) de uma Agregação.
xx
(e) de um relacionamento de dependência.
78
78. No diagrama de casos de uso da UML, o relacionamento de generalização acontece entre
(a) atores, somente.
(b) casos de uso, somente.
(c) casos de uso e entre atores.xx
(d) casos de uso e atores, somente.
(e) casos de uso incluídos e estendidos, somente.

71
 TI para concursos
79
79. Um diagrama de objetos
(a) tem a mesma função que um diagrama de atividades diferenciando deste apenas na representação
gráfica.
(b) capta um conjunto de abstrações como um grupo de interesse e em tal contexto expõe sua semântica e
seus relacionamentos com outras abstrações existentes nesse grupo da mesma forma que em um
diagrama de classes
xx
(c) exibe um único conjunto de objetos relacionados uns com os outros em um determinado momento.
(d) mostra a seqüência de execução de atividades entre objetos relacionados, no tempo, e a duração de
cada objeto por meio de linhas de vida.
(e) exibe diversos conjuntos de objetos relacionados uns com os outros em um determinado momento.
80. Uma propriedade, atributo ou operação representada no diagrama de classes da UML, que poderá ser vista e
usada apenas pela classe na qual foi declarada, bem como pelas suas classes descendentes, deve ser
80
definida com visibilidade descrita por meio da palavra-chave
(a) package.
(b) public.
(c) private.
xx
(d) protected.
(e) local.
81. A representação gráfica de um diagrama de seqüências da UML é baseada em
I. uma dimensão horizontal que representa as mensagens trocadas no decorrer de um tempo de vida.
II. uma dimensão vertical que representa os objetos participantes das interações.
III. mensagens que correspondem a chamadas de serviços ou de operações dos objetos.
IV. objetos representados por retângulos alinhados no topo do diagrama, dos quais partem as linhas de vida
destes objetos.
81
Está correto o que consta em
(a) I, II, III e IV.
(b) I, II e IV, apenas.
(c) I, II e III, apenas.
xx
(d) III e IV, apenas.
(e) I e II, apenas.
82. Um cubo, graficamente na UML, é um elemento físico existente em tempo de execução que representa um
recurso computacional com pelo menos alguma memória, e, freqüentemente, com capacidade de
82
processamento. Trata-se de
(a) pacote.
(b) nó.xx
(c) interface.
(d) objeto.
(e) nota.
83. Na UML um nó é um elemento físico que existe em tempo de execução e representa um recurso
83
computacional. Graficamente, ele é representado por
(a) um losango.
(b) um cubo.xx
(c) um quadrado.
(d) uma seta vasada (triângulo).
(e) uma elipse.
84. A identificação do documento XML, como uma mensagem SOAP, está contida no elemento da estrutura
84
SOAP denominado
(a) root.
(b) body.
(c) envelope.xx
(d) fault.
(e) header.
85. NÃO é uma informação requerida para invocar um serviço de Web e encapsulada pelo WSDL na forma de
85
um documento XML:
(a) O local do serviço.
(b) As operações que o serviço apoia.
(c) Os parâmetros que o serviço espera.
(d) Os detalhes das mensagens do serviço.
(e) Os meios para publicar e localizar o serviço.xx

72
 TI para concursos

6 Banco de Dados
6.1 Conceitos básicos
Dentre diversas definições, dado é tudo que pode ser processado e as informações são dados que
descrevem um domínio físico ou abstrato. Registros são informações produzidas como subprodutos de
35
atividades comerciais ou transações e retidas em virtude do seu valor.
Entidade é qualquer coisa do mundo real, abstrata ou concreta, na qual se deseja guardar informações.
Atributo é tudo o que se pode relacionar como propriedade da entidade. Domínio é o conjunto de
valores possíveis do atributo. Em banco de dados, fisicamente, entidades são tabelas, atributos são as
colunas e domínio é o tipo de dado contido na coluna.
Um atributo é dito obrigatório quando não puder ter seu valor omitido. Ele é identificador quando for
capaz de identificar uma linha única da tabela, caso em que é chamado de chave candidata. Uma
tabela deve possuir pelo menos uma chave candidata para poder ser gerenciada, caso em que a
coluna será chamada de chave primária. Se houver mais do que uma chave candidata, uma deverá ser
escolhida para se a chave primária, enquanto que as outras serão chamadas de chaves alternativas.
Bancos de dados (ou bases de dados) são conjuntos de registros dispostos em estrutura regular que
possibilita a reorganização dos mesmos e produção de informação, usualmente mantido e acessado
36
por meio de um software conhecido como Sistema Gerenciador de Banco de Dados (SGBD).
Modelo de dados é forma como os dados são armazenados, que pode determinar a forma como as
informações podem ser processadas.
O modelo plano ou tabular consiste de tabelas, que são matrizes simples, bidimensionais, compostas
por elementos de dados: caracteres, números inteiros, reais etc. Este modelo plano é a base das
planilhas eletrônicas.
O modelo em rede permite que várias tabelas sejam usadas simultaneamente através do uso de
apontadores (ou referências). Algumas colunas contêm apontadores para outras tabelas ao invés de
dados. Assim, as tabelas são ligadas por referências, o que pode ser visto como uma rede. Uma
variação particular deste modelo em rede, o modelo hierárquico, limita as relações a uma estrutura
semelhante a uma árvore (hierarquia - tronco, galhos), ao invés do modelo mais geral direcionado por
grafos.

6.2 Modelagem de Dados Relacional

No modelo relacional, todos os dados estão guardados em tabelas. Toda sua definição é teórica e
baseada na lógica de predicados e na teoria dos conjuntos. Consiste, principalmente, de três
componentes:
 uma coleção de estruturas de dados, nomeadamente relações ou tabelas;
 uma coleção dos operadores, a álgebra e o cálculo relacionais;
 uma coleção de restrições da integridade, definindo o conjunto consistente de estados de base de
dados e de alterações de estados. As restrições de integridade podem ser dos tipos:
 domínio – indica os valores possíveis para os dados
 nulo ou atributo vazio – determina se o valor do dado pode ser indeterminado
 chave – define uma coluna ou grupo de colunas que caracterizam uma linha única de uma tabela
 chave primária – chave que identifica uma linha da própria tabela e não pode ter valor repetido nesta
 chave estrangeira – chave que identifica uma linha de outra tabela, que pode ser repetida nesta, mas
deve existir – o que se chama de integridade referencial – e não pode se repetir na outra tabela
Toda informação tem de ser representada como dados e qualquer tipo de atributo (coluna) representa
relações entre conjuntos de dados (linhas).
As bases de dados relacionais permitem aos utilizadores (incluindo programadores) escreverem
consultas (queries) que não foram antecipadas por quem projetou a base de dados. Como resultado,
bases de dados relacionais podem ser utilizadas por várias aplicações em formas que os projetistas
originais não previram, o que é especialmente importante em bases de dados que podem ser utilizadas
durante décadas. Isto tem tornado as bases de dados relacionais muito populares no meio empresarial.

35 http://pt.wikipedia.org/wiki/Informa%C3%A7%C3%A3o
36 http://pt.wikipedia.org/wiki/Banco_de_dados
73
 TI para concursos

6.2.1 Normalização
A normalização de dados é uma série de passos que se segue no projeto de um banco de dados que
permite um armazenamento consistente e um eficiente acesso aos dados em um banco de dados
relacional. Esses passos reduzem a redundância de dados e as chances dos dados se tornarem
37
inconsistentes.
No entanto, muitos SGBDs relacionais não têm separação suficiente entre o projeto lógico da base de
dados e a implementação física do banco de dados, e isso tem como conseqüência que as consultas
feitas a um banco de dados totalmente normalizado têm um mau desempenho. Nestes casos, usa-se
por vezes a desnormalização para melhorar o desempenho, com o custo de menores garantias de
consistência.
Dizemos que duas colunas de uma tabela têm dependência funcional quando a valor de uma determina
o valor da outra. Por exemplo, uma coluna com o número de matrícula e outra com o nome de um
aluno. Um número de matrícula só pode corresponder a uma aluno, portanto há dependência funcional
entre estas duas colunas.
Chamamos de chave a um conjunto de colunas que identifica unicamente cada linha da tabela. No
exemplo anterior, o número de matrícula do aluno é campo chave da tabela, supondo não poder haver
uma pessoa com dois números de matrícula. Em uma tabela contendo o número de matrícula do aluno,
o código da disciplina, a nota e frequência do aluno, as duas primeiras colunas formam uma chave da
tabela.
Se nossa tabela de exemplo contiver a coluna CPF e RG do aluno, teremos três números que
identificam de forma única nosso aluno, três chaves. Dizemos que o número de matrícula, o RG e o
CPF são chaves candidatas. Se escolhermos uma delas para identificar o aluno, esta será chamada de
chave primária.
Tirando as chaves, os demais campos são chamados de descritores.
Ao imprimir a lista de notas finais dos alunos, podemos ter:
Núm Matrícula Nome Núm Disc Disciplina Prova 1 Prova 2 Média Frequência
123456 Funalo de Tal 12 Matemática 5,0 7,0 6,0 95%
123456 Funalo de Tal 13 Português 8,0 9,0 8,5 100%
234567 Cicrano da Silva 12 Matemática 6,0 9,0 7,5 80%
234567 Cicrano da Silva 13 Português 3,0 8,0 5,5 70%

A chave da tabela é composta das colunas Núm Matrícula e Núm Disc. Dizemos que há dependência
parcial entre o nome a uma das colunas chave, entre o código e o nome da disciplina também.
Poderíamos preferir imprimir a lista sem repetir o nome de cada aluno:

Núm Matrícula Nome Núm Disc Disciplina Prova 1 Prova 2 Média Frequência
123456 Funalo de Tal
12 Matemática 5,0 7,0 6,0 95%

13 Português 8,0 9,0 8,5 100%

234567 Cicrano da Silva
12 Matemática 6,0 9,0 7,5 80%

13 Português 3,0 8,0 5,5 70%

Onde, para cada linha de um aluno, teríamos uma lista de disciplinas e notas. Dizemos que os campos
número de matrícula e nome possuem valores atômicos, um só valor por linha.
Os demais campos são chamados de multivalorados, pois são listas de valores para uma mesma linha
da tabela.
Diz-se que uma tabela num banco de dados relacional está numa certa forma normal se satisfaz certas
condições. Considera-se que as bases de dados estão normalizadas se aderirem à terceira forma
normal.
 Primeira Forma Normal (ou 1FN) requer que todos os valores de colunas em uma tabela, sejam atômicos
(um número é um átomo, enquanto uma lista ou um conjunto não o são). A normalização elimina grupos
repetidos pondo-os cada um em uma tabela separada, conectando-os com uma chave primária ou
estrangeira. Por exemplo, pessoas têm diversos números de telefones. Uma tabela conterá as pessoas e
outra tabela os telefones, ligadas pelo código da pessoa.

37 http://pt.wikipedia.org/wiki/Normaliza%C3%A7%C3%A3o_de_dados
74
 TI para concursos
 Segunda Forma Normal (ou 2FN) requer que não haja dependência funcional não-trivial de um atributo que
não seja a chave, em parte da chave candidata. Por exemplo, uma tabela de pedidos com o código do
pedido, chave primária, código do produto, chave estrangeira, e descrição do produto, campo dependente
funcional do código do produto, que não é chave primária. O correto é levar a descrição e código do produto
para outra tabela e deixar somente o código do produto na tabela de pedidos.
 Terceira Forma Normal (ou 3FN) requer não haver dependências funcionais não-triviais de atributos que
não sejam chave, em qualquer coisa exceto um superconjunto de uma chave candidata. Por exemplo, uma
coluna preço total, que é resultado do produto do valor da coluna quantidade pelo preço unitário e não
depende do código do pedido, chave primária. A coluna preço total deve ser eliminada, sendo o valor
calculado quando for necessário em relatórios.
 Forma Normal de Boyce-Codd (ou BCNF) requer que não exista nenhuma dependência funcional não-trivial
de atributos em algo mais do que um superconjunto de uma chave candidata. Neste estágio, todos os
atributos são dependentes de uma chave, de uma chave inteira e de nada mais que uma chave (excluindo
dependências triviais, como A->A).
 Quarta Forma Normal (ou 3FN) Uma relação está na 4ª forma normal, se está na Boyce-Codd, e se não
existem dependências multivalor
 Forma Normal (ou 3FN) Uma relação está na 5ª forma normal, se está na 4ª FN, e se não existem
dependências de junção.
As quarta e quinta formas normais são raras e difíceis de detectar.
Frequentemente considera-se que uma relação na 3ª forma normal ou Boyce-Codd está num nível de
normalização aceitável.

6.2.2 Etapas de modelagem

A construção de modelos relacionais envolve as etapas:38
 Modelo conceitual - Representa as regras de negócio sem limitações tecnológicas ou de
implementação:
 Visão Geral do negócio
 Facilitação do entendimento entre usuários e desenvolvedores
 Possui somente as entidades e atributos principais
 Pode conter relacionamentos n para m.
 Modelo Lógico - Leva em conta limites imposto por algum tipo de tecnologia de banco de dados:
 Deriva do modelo conceitual
 Possui entidades associativas em lugar de relacionamentos n:m
 Define as chaves primárias das entidades
 Normalização até a 3a. forma normal
 Adequação ao padrão de nomenclatura
 Entidades e atributos documentados
 Modelo Físico - Leva em consideração limites imposto pelo SGBD (Sistema Gerenciador de Banco
de dados) e pelos requisitos não funcionais dos programas que acessam os dados. Características:
 Elaborado a partir do modelo lógico
 Pode variar segundo o SGBD
 Pode ter tabelas físicas
 Pode ter colunas físicas

6.2.3 Relacionamentos
As tabelas podem ser relacionadas para compor uma consulta de informações, desde que a chave
primária de uma seja uma coluna da outra, onde será chamada de chave estrangeira. No modelo
lógico, este relacionamento pode se dar de três formas:
 A chave primária da primeira é chave estrangeira na segunda tabela, de forma que podem haver
diversas ocorrências de registros da primeira tabela na segunda, mas para cada linha da segunda
tabela só existirá uma linha correspondente na primeira. Chamamos isto de cardinalidade um para
ene (1:n). Por exemplo, uma tabela de clientes com o código do cliente e o nome, pode ser
relacionada com uma outra tabela de telefones contendo o código do telefone, o código do cliente e
o número do telefone.
 As chaves primárias de duas tabelas podem formar uma terceira tabela, criando uma nova entidade
chamada de relacionamento. Assim, diversas linhas da primeira tabela podem se relacionar com
outras linhas da segunda, em uma cardinalidade ene para eme (n:m). Por exemplo, uma tabela de

38 http://www.macoratti.net/cbmd1.htm
75
 TI para concursos
disciplinas, com o código da matéria e nome, pode se relacionar com uma tabela de alunos, com
código do aluno e nome, através de uma terceira tabela de matrículas com os dois códigos. Um
aluno pode se matricular em diversas matérias e uma matéria pode ter vários alunos.
 A chave primária de uma tabela pode compor duas colunas de uma tabela de relacionamento,
formando uma auto-relacionamento. Por exemplo, uma tabela de empregados pode se relacionar
com ela mesmo através de uma tabela de chefia, com o código do empregado na coluna
subordinado e de outro empregado, como chefe do primeiro, na coluna superior.

6.2.4 Transação
Conjunto de procedimentos que é executado num banco de dados, que para o usuário é visto como
uma única ação. A integridade de uma transação depende de 4 propriedades, conhecidas como ACID.
 Atomicidade - Todas as ações que compõem a unidade de trabalho da transação devem ser
concluídas com sucesso, para que seja efetivada. Qualquer ação que constitui falha na unidade de
trabalho e a transação deve ser desfeita (rollback). Quando todas as ações são efetuadas com
sucesso, a transação pode ser efetivada (commit).
 Consistência - Nenhuma operação do banco de dados de uma transação pode ser parcial. O status
de uma transação deve ser implementado na íntegra. Por exemplo, um pagamento de conta não
pode ser efetivado se o processo que debita o valor da conta corrente do usuário não for efetivado
antes, nem vice-versa.
 Isolamento - Cada transação funciona completamente à parte de outras estações. Todas as
operações são parte de uma transação única. O principio é que nenhuma outra transação, operando
no mesmo sistema, pode interferir no funcionamento da transação corrente (é um mecanismo de
controle). Outras transações não podem visualizar os resultados parciais das operações de uma
transação em andamento.
 Durabilidade - Os resultados de uma transação são permanentes e podem ser desfeitos somente
por uma transação subseqüente.
Controle de concorrência é um método usado para garantir que as transações são executadas de uma
forma segura e segue as regras ACID. Os SGBD devem ser capazes de assegurar que nenhuma ação
de transações completadas com sucesso (committed transactions) seja perdida ao desfazer transações
abortadas (rollback). Uma transação é uma unidade que preserva consistência.

6.3 Modelo Entidade Relacionamento

Modelo de Entidades e Relacionamentos é um modelo abstrato cuja finalidade é descrever, de maneira
conceitual, os dados a serem utilizados em um Sistema de Informações ou que pertencem a um
domínio. A principal ferramenta do modelo é sua representação gráfica, o Diagrama Entidade
Relacionamento. Normalmente o modelo e o diagrama são conhecidos por suas siglas: MER e DER.39
Existem muitas notações para Diagrama de Entidades e Relacionamentos. A notação original foi
proposta por Chen e é composta de entidades (retângulos), relacionamentos (losangos), atributos
(círculos) e linhas de conexão (linhas) que indicam a cardinalidade de uma entidade em um
relacionamento. Chen ainda propõe símbolos para entidades fracas e entidades associativas.
Toda a notação moderna tem como característica importante definir a cardinalidade mínima e máxima
em uma relação, não utilizar um símbolo especial para relacionamentos, mas sim a linha, e descrever
atributos dentro do símbolo de entidades.
Diagrama entidade relacionamento é um modelo diagramático que descreve o modelo de dados de um
sistema com alto nível de abstração. Ele é a principal representação do Modelo de Entidades e
Relacionamentos. É usado para representar o modelo conceitual do negócio.
Uma relação entre duas tabelas é chamada de binária, três tabelas de ternária, enquanto que um auto-
relacionamento, em que uma entidade se relaciona com ela mesma, é também chamado de relação
unária.
Os tipos de relações utilizadas neste diagrama são:
 Relação 1..1 (lê-se relação um para um) - indica que as tabelas têm relação unívoca entre si. Você
escolhe qual tabela vai receber a chave estrangeira;
 Relação 1..n (lê-se um para muitos) - a chave primária da tabela que tem o lado 1 vai para a tabela
do lado N. No lado N ela é chamada de chave estrangeira;

39 http://pt.wikipedia.org/wiki/Modelo_de_Entidades_e_Relacionamentos
76
 TI para concursos
 Relação n..n (lê-se muitos para muitos) - quando tabelas têm entre si relação n..n, é necessário criar
uma nova tabela com as chaves primárias das tabelas envolvidas, ficando assim uma chave
composta, ou seja, formada por diversos campos-chave de outras tabelas. A relação então se reduz
para uma relação 1..n, sendo que o lado n ficará com a nova tabela criada.

6.4 Modelagem de Dados Multidimensional

Na modelagem multidimensional os dados são de-normalizados e estruturados em diversas
dimensões.40
A finalidade de bases de dados multidimensionais (alguns autores chamam de dimensionais) é fornecer
subsídio para realização de análises. Para tanto, sua arquitetura e terminologia empregada são
distintas das utilizadas para bancos de dados transacionais. O fato de existirem diversas informações a
serem cruzadas (dimensões) permite a realização de pesquisas.
As análises sobre dados históricos envolvem uma série de possibilidades de cruzamentos e
agrupamentos de informações, com o uso dos seguintes termos:
 Dimensões: estabelecem a organização dos dados, determinando possíveis consultas/cruzamentos.
Por exemplo: região, tempo, canal de venda,... Cada dimensão pode ainda ter seus elementos,
chamados membros, organizados em diferentes níveis hierárquicos. A dimensão tempo, por
exemplo, pode possuir duas hierarquias: calendário gregoriano (com os níveis ano, mês e dia) e
calendário fiscal (com os níveis ano, semana e dia);
 Medidas: são os valores a serem analisados, como médias, totais e quantidades;
 Fatos: são os dados a serem agrupados, contendo os valores de cada medida para cada
combinação das dimensões existentes. O tamanho da tabela que contém os fatos merece atenção
especial do analista;
 Agregações: totalizações calculadas nos diversos níveis hierárquicos.
Esta forma de armazenamento é conhecida como ROLAP, ou Relational OLAP. Uma vez que os dados
já se encontram em um modelo apropriado, chamado multidimensional, basta processar as
agregações. Com isso obtém-se ganho de espaço de armazenamento, uma vez que os dados
permanecem apenas na base de origem (multidimensional), embora a criação de grandes quantidades
de agregações possa incorrer em explosão de dados.
Outra forma de armazenamento, cujo modelo matemático denomina-se hipercubos, apresenta a
característica de possuir armazenamento e indexação em estruturas de dados que otimizam consultas
ao invés de atualizações. Esta forma é erroneamente chamada MOLAP, ou Multidimensional OLAP. O
erro está no fato de que bases ROLAP também são multidimensionais.
Quando o modelo multidimensional é processado, nova base é gerada, desta vez contendo tanto os
dados quanto as agregações em formato próprio, utilizando-se de estruturas apropriadas para
pesquisas.
Aplicações analíticas possuem peculiaridades tais como manipulação de grandes volumes de dados e
baixa taxa de atualização. Essas características favorecem este modelo estrutural, mais rápido. Por
exemplo, Business Intelligence (BI) é um processo de gerenciamento de informações que pode ser
obtido por qualquer artefato, seja tecnológico ou não, que permita a extração de conhecimento a partir
de análises do negócio. A efetividade destas análises será maior se os dados estiverem disponíveis de
modo consistente e, preferencialmente, consolidado. 41
Soluções informatizadas de BI geralmente contém sistemas analíticos, que podem ser de diversos
tipos, dependendo do objetivo das análises e do perfil do usuário:
 Decision Support Systems (DSS), ou Sistemas de Apoio a Decisão (SAD): são baseados em
relatórios analíticos, normalmente utilizados por usuários de nível operacional;
 Management Information Systems (MIS), ou Sistemas de Informações Gerenciais (SIG): permitem
análises mais profundas, com a realização de simulações de cenários. São utilizados por analistas
de negócio no nível tático;
 Executive Information Systems (EIS), ou Sistemas de Informações Executivas (SIE): são voltados
para profissionais que atuam no nível estratégico das empresas, como diretores e presidência.
Oferecem, para tanto, um conjunto de indicadores chave de desempenho (KPI, ou Key Performance
Indicators).

40 http://pt.wikipedia.org/wiki/Modelagem_multidimensional
41 http://msdn.microsoft.com/pt-br/library/cc518031.aspx
77
 TI para concursos
 A Microsoft desenvolveu uma ferramenta em SQL Server, o MDX (Multidimensional Expressions),
que permite que você consulte objetos multidimensionais, como cubos, e retorna conjuntos de
células multidimensionais que contêm dados do cubo.

6.4.1 Sistemas Transacionais X Sistemas Analíticos

Sistemas transacionais, também conhecidos como sintéticos ou ainda OLTP – Online Transactional
Processing - são baseiados em transações. Por exemplo, Sistemas Contábeis, Aplicações de Cadastro,
Sistemas de Compra, Estoque, Inventário, ERPs, CRMs etc.
Os sistemas transacionais se caracterizam pela alta taxa de atualização, grande volumes de dados e
acessos pontuais, ou seja, pesquisas cujo resultado seja de pequeno volume.
Já os sistemas analíticos, ou OLAP – Online Analytical Processing – se caracterizam por fornecer
subsídio para tomadas de decisão, a partir de análises realizadas sobre bases de dados históricas, por
vezes com milhões de registros a serem totalizados. As atualizações não precisam ser tão freqüentes.
As análises geralmente agrupam informações, sendo tais agrupamentos mais importantes neste
contexto do que os dados detalhados.
As ferramentas OLAP (do inglês, Online Analytical Processing) são geralmente desenvolvidas para
trabalhar com banco de dados denormalizados, embora existam ferramentas que trabalham com
42
esquemas especiais de armazenamento, com dados (informações) normalizados.
Essas ferramentas são capazes de navegar pelos dados de um Data Warehouse, possuindo uma
estrutura adequada tanto para a realização de pesquisas como para a apresentação de informações.
Nas ferramentas de navegação OLAP, é possível navegar entre diferentes níveis de granularidades
(detalhamento) de um cubo de dados. Através de um processo chamado Drill o usuário pode aumentar
(Drill down) ou diminuir (Drill up) o nível de detalhamento dos dados. Por exemplo, se um relatório
estiver consolidado por países, fazendo um Drill down, os dados passarão a ser apresentados por
Estados, cidades, bairros e assim sucessivamente até o menor nível de detalhamento possível. O
processo contrário, o Drill up, faz com que os dados sejam consolidados em níveis superiores de
informação.
Outra possibilidade apresentada pela maioria das ferramentas de navegação OLAP é o recurso
chamado Slice and dice. Esse recurso é usado para criar visões dos dados por meio de sua
reorganização, de forma que eles possam ser examinados sob diferentes perspectivas.

6.5 Conceitos de Datawarehouse e ETL

Um Data Warehouse é uma base de dados, geralmente relacional, que consolida as informações
empresariais. Sua construção é um processo normalmente moroso e complexo, por diversos fatores,
dentre os quais a grande quantidade de dados, diversas fontes de informações com bases
heterogêneas e muitas vezes inconsistentes, envolvimento de várias áreas ou departamentos da
empresa. Um dos maiores desafios na construção do DW é a extração e consolidação dos dados
operacionais, pois:
 Pode haver várias fontes;
 Os dados precisam ser limpos;
 A granularidade precisa ser ajustada;
 Pode ser necessário resumir dados;
 Deve haver valores default e tratamento de NULL;
 É necessário componente temporal;
 Os relacionamentos nos dados de entrada precisam ser claros.
Algumas situações comuns entre as fontes de dados:
 Mesmos dados, nomes diferentes;
 Dados diferentes, mesmo nome;
 Dados exclusivos de uma aplicação;
 Chaves diferentes, mesmos dados.
Como métodos de construção, existem formalmente dois:
 Top-down, no qual é realizada a modelagem integral do DW, seguida pelas extrações de dados. A
principal vantagem é a criação de um modelo único. O revés fica por conta do maior tempo de
projeto;

42 http://pt.wikipedia.org/wiki/OLAP
78
 TI para concursos
 Bottom-up, onde o foco é em uma área por vez, com o crescimento gradual do DW. A vantagem é a
obtenção de resultados a intervalos mais curtos, garantindo muitas vezes sustentação ao projeto. A
desvantagem é a maior dificuldade de se consolidar informações entre as diversas áreas.
Uma alternativa às estratégias acima, denominada Middle-out, é aproveitar as vantagens de cada uma
por meio do desenvolvimento iterativo do DW:
 O modelo de dados corporativo é o primeiro a ser desenvolvido e é o responsável pela integração dos
demais;
 As primeiras tabelas da área de interesse escolhida são povoadas: primeiras análises;
 Povoamento de mais tabelas com dados históricos;
 Alguns dados passam a compor o DW, saindo da base operacional;
 Surgimento dos data marts (a seguir nesta seção);
 O ciclo se repete até que o DW esteja completo. Bases de produção contêm apenas dados operacionais.
Outro fator crítico para o sucesso de um DW é o gerenciamento do volume. Embora o conceito de DW
se aplique a grandes quantidades de dados, chegando atualmente a ordem de TB, sua capacidade não
é infinita, devendo ser utilizada sabiamente. Apenas dados relevantes deveriam constar do DW. Pode
ser que o horário de uma determinada transação seja importante quando o foco for o curto prazo, mas
que apenas um contexto de agrupamento seja suficiente para dados de cinco anos atrás. Questões
como essa devem ser consideradas durante o planejamento do DW, pois ajudam a dimensioná-lo.
A remoção de dados do DW é um assunto tratado com receio pelos DBAs e pelos analistas de negócio.
A rigor, tão importante quanto saber que dados armazenar, é saber quando e quais dados remover do
DW. Algumas estratégias são:
 Resumir dados mais antigos;
 Armazenar os dados antigos em meio mais barato (fita);
 Remover os dados do DW.
Tais estratégias não são excludentes, podendo ser utilizadas em conjunto.
A importância da remoção de dados está em manter o DW o mais enxuto possível, embora isso possa
parecer contraditório ao conceito de DW.
Com relação à granularidade, as bases de dados operacionais trabalham com o maior nível de detalhe
possível, ou seja, a maior granularidade. Já no DW pode haver diversos graus de agregação e resumo
dos dados. Por exemplo, os dados do ano corrente podem ser detalhados por item de pedidos, de um a
cinco anos, por total de cada pedido e, após isso, por total de pedidos por dia. A correta determinação
da granularidade exerce papel fundamental no planejamento de capacidade e desempenho do DW.
Ao contrário do que ocorre com as bases operacionais, o DW, por conter dados históricos, não
demanda alta taxa de atualização. Desse modo, pode ser atualizado a cada 24 horas ou até mesmo
uma vez por semana. Além disso, por sofrer poucas modificações, e de forma controlada (por
aplicações específicas para esse fim), seus relacionamentos podem ser implementados através de
entidades, embora isso não seja freqüente.
Data Marts (DM), são bancos de dados multidimensionais específicos por área de negócio para
realização de análises. Alguns conceitos sobre Data Marts não estão muito bem claros para o mercado.

79
 TI para concursos
Um DW construído iterativamente possui porções agrupadas por segmento de negócio, região ou
qualquer outra forma que seja adequada à empresa. Essas porções alimentam os Data Marts, que
podem ser então consultados por ferramentas de análise.

6.5.1 ETL
Extract, Transform and Load (Extração, Transformação e Carga) são ferramentas de software cuja
função é a extração de dados de diversos sistemas, transformação desses dados conforme regras de
negócios e carga dos dados em um data mart ou um data warehouse. É considerada uma das fases
mais críticas do Data Warehouse e/ou Data Mart.
Os projetos de data warehouse consolidam dados de diferentes fontes. A maioria dessas fontes tendem
a ser bancos de dados relacionais ou flat files (texto plano), mas podem existir outras fontes. Um
sistema ETL tem que ser capaz de se comunicar com as bases de dados e ler diversos formatos de
arquivos utilizados por toda a organização. Essa pode ser uma tarefa não trivial, e muitas fontes de
dados podem não ser acessadas muito facilmente.
Existem ferramentas ETL, mas ETL não são ferramentas, mas sim uma metodologia.

6.6 Conceitos de desenvolvimento em banco de dados SQL Server e Oracle

6.6.1 SQL
Structured Query Language, ou Linguagem de Consulta Estruturada ou SQL, é uma linguagem de
pesquisa declarativa para banco de dados relacional (base de dados relacional). Muitas das
características originais do SQL foram inspiradas na álgebra relacional.43
Uma consulta SQL especifica a forma do resultado e não o caminho para chegar a ele. Padronizado
pela ANSI e ISO, possui muitas variações e extensões produzidos pelos diferentes fabricantes de
sistemas gerenciadores de bases de dados. Tipicamente a linguagem pode ser migrada de plataforma
para plataforma sem mudanças estruturais principais.
O padrão do SQL (ANSI) utiliza operadores, funções de agregação e comandos, que dividem-se em
cinco subconjuntos. Os comandos podem ser escritos e executados por linhas de comando dentro de
algum aplicativo do próprio gerenciador de banco de dados, por lotes de comandos definidos dentro do
banco de dados (procedures) ou lotes de comandos por qualquer aplicativo com conexão com o banco
de dados.
A Microsoft oferece o MS SQL Server e a Oracle seu gerenciador de banco de dados de mesmo nome
obedecendo aos padrões ANSI e adicionando mais recursos para administração eficiente de dados.

6.6.1.1 DML - Linguagem de Manipulação de Dados

A DML (Data Manipulation Language) é um subconjunto da linguagem usada para inserir, atualizar e
apagar dados.
 INSERT - insere registros (linhas ou tuplas)
 UPDATE - altera valores de dados
 DELETE - remove linhas (registros ou tuplas)

6.6.1.2 DDL - Linguagem de Definição de Dados

DDL (Data Definition Language) permite definir tabelas e elementos associados.
 CREATE - cria um objeto (tabela, index, view etc.) dentro da base de dados.
 DROP - apaga um objeto do banco de dados
 ALTER TABLE - altera a estrutura de uma tabela, não é aceito por todos os gerenciadores de banco
de dados

6.6.1.3 DCL - Linguagem de Controle de Dados

DCL (Data Control Language) controla os usuários e direitos de acesso aos objetos dentro do banco de
dados.
 GRANT - autoriza ao usuário executar ou setar operações.
 REVOKE - remove ou restringe a capacidade de um usuário de executar operações.
 ALTER PASSWORD - altera senha

43 http://pt.wikipedia.org/wiki/SQL
80
 TI para concursos
 CREATE SYNONYM - cria sinônimos, nomes alternativos para os objetos

6.6.1.4 DTL - Linguagem de Transação de Dados

DTL (Data Transaction Language) define blocos de comandos – transações – que podem ser
efetivados ou não.
 BEGIN WORK (ou START TRANSACTION) - usado para marcar o começo de uma transação.
 COMMIT - confirma todas as ações, desde o comando begin, permanentemente.
 ROLLBACK faz com que os comandos de mudanças nos dados sejam descartados.
COMMIT e ROLLBACK interagem com áreas de controle como transação e locação. Ambos terminam
qualquer transação aberta e liberam qualquer bloqueio ligado a dados. Na ausência de um BEGIN
WORK ou uma declaração semelhante, a semântica de SQL é dependente da implementação.

6.6.1.5 DQL - Linguagem de Consulta de Dados

DQL (Data Query Langage) possui apenas um comando, para selecionar dados.
 SELECT - especifica uma consulta ("query") como uma descrição do resultado desejado. Esse
comando é composto de várias cláusulas e opções, possibilitando elaborar consultas das mais
simples às mais elaboradas.
As cláusulas são condições de modificação utilizadas para definir os dados que deseja selecionar ou
modificar em uma consulta.
 FROM - Utilizada para especificar a tabela que se vai selecionar os registros.
 WHERE – Utilizada para criar uma restrição, isto é, especificar as condições que devem reunir os registros
que serão selecionados.
 GROUP BY – Utilizada para separar os registros selecionados em grupos específicos.
 HAVING – Utilizada para expressar a condição que deve satisfazer cada grupo, criar uma restrição para o
grupo.
 ORDER BY – Utilizada para ordenar os registros selecionados com uma ordem especifica.
 DISTINCT – Utilizada para selecionar dados sem repetição.
 JOIN – utilizada para criar junções entre a tabelas, criando restrições ou atendendo a critérios, e permitindo
a seleção de colunas das tabelas envolvidas. O join pode ser definido de diversas formas:
 Sem a utilização da cláusula join, colocando os nomes das tabela logo depois da clausula from
separados por vírgulas, e com uma restrição de relacionamento após a cláusula where.


6.6.1.6 Operadores Lógicos

Operadores lógicos relacionam elementos de uma expressão lógica.
 AND – Avalia os termos e devolve um valor verdadeiro caso ambos sejam corretos.
 OR – Avalia termos e devolve um valor verdadeiro se algum for correto.
 NOT – Devolve o valor contrário da expressão.

6.6.1.7 Operadores Relacionais

Os operadores estabelecem critérios para uma expressão lógica.
 < – Menor que
 > – Maior que
 <> – Diferente de
 <= – Menor ou Igual que
 >= – Maior ou Igual que
 = – Igual a
 BETWEEN – Utilizado para especificar um intervalo de valores.
 LIKE – Utilizado na comparação de um modelo e para especificar registros de um banco de
dados."Like" + extensão % vai significar buscar todos resultados com o mesmo início da extensão.

6.6.1.8 Funções de Agregação

As funções de agregação, dentro de uma cláusula SELECT com cláusula GROUP BY, devolve valores
agregados de um grupo de registros.
 AVG – calcular a média dos valores de um campo numérico determinado.
81
 TI para concursos
 COUNT – devolve o número de registros da seleção.
 SUM – devolve a soma de todos os valores de um campo numérico determinado.
 MAX – devolve o valor mais alto de um campo especificado.
 MIN – devolve o valor mais baixo de um campo especificado.

6.6.1.9 Conjuntos de dados

Os dados de uma ou mais tabelas podem ser agrupados em um único conjunto de dados através de
operações de seleção (select) de diversos tipos:
 Junção – dois conjuntos de dados são concatenados de acordo com uma determinada condição de
relação e seleção.
 Restrição – condição que limita a seleção das linhas de uma relação.
 Projeção – uma ou mais colunas de uma relação são selecionadas formando um subconjunto
vertical.
 União – são selecionadas todas as linhas que aparecem em ambas as relações
 Intersecção – são selecionadas apenas aquelas linhas que existem em ambos os conjuntos.

6.6.1.10 Componentes de um banco de dados

Um banco de dados pode apresentar mais do que tabelas e dados em sua estrutura. Pode possuir
módulos programados e objetos que melhoram a manipulação dos dados.
 Tabelas – modelo abstrato de armazenamento de dados em forma de registros e campos em banco
de dados relacional. Cada tabela armazena informações de uma entidade modelada do banco de
dados.
 Views - ajuda a encapsular uma consulta em uma entidade relacional e facilita a visão de um dado
de uma ou mais tabelas em um banco de dados.
 Restrição - define regras a respeito de valores permitidos em colunas e é um mecanismo que
executa a integridade de dados
 Índices - oferece rápido acesso ao dado de uma tabela baseado em valores classificados em ordem
crescente ou decrescente. A chave primária de uma tabela é automaticamente indexada.
 Funções - pedaço de código que opera como uma unidade lógica. Uma função pode retornar tanto
uma tabela quanto um valor escalar. Qualquer código que deve executar a lógica incorporada em
uma função pode chamar a função, em vez de repetir a função lógica.
 Procedimento (Procedure) – lote (texto) de comandos (código) armazenado no banco de dados.
 Gatilho (Trigger) - procedimento que é executado quando ocorre um evento qualquer previsto para
um registro, campo ou para a própria tabela.

6.6.2 Arquitetura de um Servidor Oracle

Um banco de dados Oracle é composto por uma ou mais tablespaces. Uma tablespace contém um ou
mais arquivos no nível de sistema operacional. Cada tablespace pode ter um ou mais segmentos. Um
segmento é adicionado na tablespace quando uma tabela ou um índice é criado, ou seja, um segmento
é associado a cada objeto de banco de dados. é possível que um objeto seja atribuído a mais de um
segmento, mas, para isso, o usuário deverá particionar explicitamente o objeto. Várias tabelas ou
índices podem ser incluídos em um mesmo segmento através da criação de um objeto conhecido como
cluster.
A medida que um objeto de banco de dados necessita de mais espaço, é necessário que o segmento
aloque mais dados. O banco de dados procura, nos arquivos do tablespace, áreas contíguas de
tamanho pré-determinado para o armazenamento de novos dados. Essa área contígua é conhecida
como extensão (extent), que por sua vez é formada por diversos blocos de banco de dados. Cada
bloco de banco de dados possui um tamanho fixo determinado nos parâmetros de configuração, esse
tamanho fixo deve ser múltiplo do tamanho de um bloco do nível do sistema operacional. O tamanho
extent também pode ser configurado pelo usuário ou determinado automaticamente pelo Oracle.
A criação de um banco de dados pode ser realizada através de uma ferramenta gráfica conhecida
como Database Configuration Assistant. Com essa ferramenta também é possível configurar opções de
um banco de dados existente, deletar um banco de dados e gerenciar gabaritos de banco de dados.
Os tipos de usuários (papéis) variam de acordo com o lugar, mas podem ser divididos em
administadores de banco de dados, responsáveis pela segurança, administradores de rede,
desenvolvedores de aplicação, administradores de aplicação e usuários do banco de dados.

82
 TI para concursos
PL/SQL (Procedural Language/SQL) é uma extensão da linguagem padrão SQL para o Oracle. Permite
que a manipulação de dados seja incluída em unidades de programas. Blocos de PL/SQL são
passados e processados por uma PL/SQL Engine que pode estar dentro de uma ferramenta Oracle ou
do Server. A PL/SQL Engine filtra os comandos SQL e manda individualmente o comando SQL para o
SQL Statement Executor no Oracle Server, que processa o PL/SQL com os dados retornados do
Server. É a linguagem básica para criar programas complexos e poderosos, não só no banco de dados,
mas também em diversas ferramentas Oracle.44
A unidade básica em PL/SQL é um bloco. Todos os programas em PL/SQL são compostos por blocos,
que podem estar localizados uns dentro dos outros. Geralmente, cada bloco efetua uma ação lógica no
programa. Um bloco tem basicamente a seguinte estrutura:
DECLARE
Seção (opcional) para declaração de variáveis,tipos e subprogramas locais.
BEGIN
Seção Executável, nesta seção ficam as instruções procedurais e SQL. Esta é a única seção do bloco que é indispensável e obrigatória.
EXCEPTION
Seção/Setor (opcional) onde ficam as instruções de tratamento de erro.
END

6.6.3 Arquitetura de um Servidor SQL Server

Um banco de dados no SQL Server 2005 se refere a um grupamento físico de um conjunto de objetos
de esquema de um banco de dados em um ou mais arquivos físicos. Os bancos de dados podem ser
classificados como bancos de dados de sistemas e bancos de dados dos usuários. Os banco de dados
de sistema armazenam dados do sistema e também controlam o armazenamento temporário requerido
para os dados de aplicação.
Cada instância do SQL Server pode suportar vários bancos de dados. Além disso, pode haver várias
instâncias em um mesmo computador. Cada banco de dados pode suportar grupos de arquivos
(filegroups), que proveêm a funcionalidade de distribuir os dados fisicamente. Um banco de dados pode
possuir vários filegroups, mas o contrário não é possível. Após a criação do banco de dados, os
filegroups do banco de dados podem ser adicionados.
O SQL Server utiliza a unidade básica de IO fixo (página) em 8KB. Para organizar melhor os dados,
essas páginas são agrupadas em uma quantidade de oito contíguas entre si formando as chamadas
extensões (extents). O espaço é gerenciado em termos de extensões. Cada página pertence a um
objeto de um tipo (dado, índice etc), mas uma extensão pode pertencer a vários objetos.
Uma extensão em que as oito páginas pertencem ao mesmo objeto é considerada uma extensão
uniforme, caso contrário, trata-se de uma extensão mista.
O SQL Server utiliza os filegroups para controlar a alocação das tabelas e dos índices. Os dados
contidos em filegroup são proporcionalmente distribuídos entre os arquivos do filegroup. Se os
filegroups não estiverem definidos, os objetos do banco de dados serão armazenados em um filegroup
padrão que é implicitamente definido durante a criação do banco de dados.
Os segmentos utilizados no Oracle não são necessários no SQL Server. Em vez disso, o SQL Server
distribui os dados através de RAID suportado em hardware ou software (solução presente no Windows
ou em outro software).

44 http://pt.wikipedia.org/wiki/PL/SQL
83
 TI para concursos

6.7 Exercícios
86. (ICMS-SP 2009) A arquitetura ANSI/SPARC aplicada aos bancos de dados divide-os em níveis com as
seguintes características:
I. O que se ocupa do modo como os dados são fisicamente armazenados.
II. O que se ocupa do modo como os dados são vistos por usuários individuais.
III. Nível lógico de comunidade ou apenas lógico (mais abstrato que o físico e diferente da visão do usuário
individual).
86
Em um projeto arquitetural, os itens I, II e III são classificados, respectivamente, como níveis
(a) externo, conceitual e interno.
(b) externo, interno e conceitual.
xx
(c) interno, externo e conceitual.
(d) interno, conceitual e externo.
(e) conceitual, externo e interno.
87. (ICMS-SP 2009) A independência de dados física e a independência de dados lógica são possibilitadas de
87
forma ideal, respectivamente, por um
(a) ou mais mapeamentos conceituais/internos e por um ou mais mapeamentos internos/externos.
xx
(b) mapeamento conceitual/interno e por um ou mais mapeamentos externos/conceituais.
(c) mapeamento interno/externo e por um mapeamento conceitual/interno.
(d) ou mais mapeamentos internos/externos e por um mapeamento conceitual/interno.
(e) mapeamento conceitual/externo e por um mais mapeamentos conceituais/internos.
88. (ICMS-SP 2009) O procedimento em que se aplicam os ajustes apropriados na organização do sistema de
banco de dados, principalmente na ocorrência das mudanças de requisitos, visando à manutenção constante
88
do melhor desempenho para a empresa, é denominado
(a) schema.
(b) dumping.
(c) mapping.
(d) restart.
xx
(e) tuning.
89. (ICMS-SP 2009) No ambiente de desenvolvimento com SQL Server, uma sintaxe usada para definir objetos
multidimensionais, bem como para examinar e manipular dados multidimensionais, corresponde à
89
linguagem
xx
(a) MDX.
(b) RDL.
(c) WQL.
(d) XSL.
(e) SMDL.
90. (ICMS-SP 2009) Uma assinatura criada e administrada pelo Publicador, com SQL Server, trata-se de uma
90
assinatura
(a) pull.
xx
(b) push.
(c) anônima.
(d) de cliente.
(e) de servidor.
91. (ICMS-SP 2009) No SQL Server, uma única dimensão de banco de dados unida à tabela de fatos em uma
91
chave estrangeira diferente, para produzir várias dimensões de cubo, é denominada dimensão
(a) de fatos.
(b) de referência.
(c) compartilhada.
xx
(d) com função múltipla.
(e) muitos para muitos.
92
92. (ICMS-SP 2009) No formato de um bloco de dados do Oracle, um overhead é uma referência ao
(a) Header.
(b) Space free.
(c) Table directory.
(d) Space free e Row data, coletivamente.
xx
(e) Header, Table directory e Row directory, coletivamente.
93. (ICMS-SP 2009) NÃO é um conjunto de extensões do Oracle que contém todos os dados para uma estrutura
93
lógica de armazenamento dentro de uma tablespace:
(a) Automatic Undo Management.
xx
(b) Automatic Storage Management.
(c) Temporary Segments.
(d) Index Segments.
(e) Data Segments.

84
 TI para concursos
94
94. (ICMS-SP 2009) Um database Oracle é constituído de um ou mais
(a) datafiles, estruturas físicas de armazenamento, e cada datafile consiste de um ou mais tablespaces,
unidades lógicas de armazenamento.
(b) datafiles, unidades lógicas de armazenamento, e cada datafile consiste de um ou mais tablespaces,
estruturas físicas de armazenamento.
(c) tablespaces, unidades lógicas de armazenamento, e cada tablespace consiste de um ou mais datafiles,
xx
estruturas físicas de armazenamento.
(d) tablespaces, estruturas físicas de armazenamento, e cada tablespace consiste de um ou mais datafiles,
unidades lógicas de armazenamento.
(e) tablespaces, unidades lógicas de armazenamento, e cada tablespace consiste de um ou mais datafiles,
também unidades lógicas de armazenamento.
95. (ICMS-SP 2009) Considere a seguinte regra de Codd, aplicada aos bancos de dados relacionais:
A descrição do banco de dados é representada no nível lógico da mesma forma que os dados ordinários,
permitindo que usuários autorizados utilizem a mesma linguagem relacional aplicada aos dados regulares.
95
O sentido dessa regra diz respeito à
xx
(a) formação do catálogo.
(b) manipulação, por meio de visões.
(c) independência física.
(d) independência lógica.
(e) independência de distribuição.
96. (ICMS-SP 2009) Considere a afirmativa a seguir.
Uma tabela está na I , se e somente se ela estiver na II e os atributos não-chave forem III .
96
I, II e III podem ser corretamente preenchidos por:
(a) FNBC, 1FN, totalmente dependentes da totalidade da chave primária
(b) 3FN, 2FN, independentes da chave primária
(c) 3FN, 1FN, totalmente dependentes de parte da chave primária
(d) 2FN, 1FN, totalmente dependentes de parte da chave primária
xx
(e) 2FN, 1FN, totalmente dependentes da totalidade da chave primária
97. (ICMS-SP 2009) Considere a relação 1:N entre cliente e seus pedidos e a necessidade de exclusão de um
determinado cliente. A fim de manter informações históricas sobre pedidos já efetuados, independentemente
da existência do cliente que os fez, deseja-se que aqueles pedidos já efetuados pelo cliente excluído não
sejam apagados. As chaves primárias de ambas e em cada tabela são definidas como única. Em um banco
97
de dados relacional normalizado até a 3FN, o atendimento de tal requisito pode ser obtido por meio de
xx
(a) restrição de chave estrangeira on delete set null.
(b) colocação de uma constante (ex. ‘9999’) nas chaves primárias dos pedidos do cliente excluído.
(c) colocação de uma constante (ex. ‘9999’) nas chaves primárias de cada cliente excluído.
(d) não limpeza das chaves estrangeiras dos pedidos, existentes na tabela do cliente.
(e) restrição de chave estrangeira on delete cascade.
98. (ICMS-SP 2009) Em um banco de dados multidimensional, considere, por exemplo, que os dados podem ser
representados como um array de três dimensões, correspondendo a produtos, clientes e períodos de tempo.
Dessa forma, um determinado valor individual em uma célula pode representar a quantidade de um produto
98
vendido a um cliente em um dado momento. De acordo com essa consideração,
(a) produtos e clientes são variáveis independentes, e períodos de tempo e quantidade são variáveis
dependentes.
(b) produtos, clientes e períodos de tempo são variáveis dependentes, e quantidade é uma variável
independente.
(c) produtos, clientes e períodos de tempo são variáveis independentes, e quantidade é uma variável
xx
dependente.
(d) produtos são variáveis dependentes, e clientes, períodos de tempo e quantidade são variáveis
independentes.
(e) produtos são variáveis independentes, e clientes, períodos de tempo e quantidade são variáveis
dependentes.
99. (ICMS-SP 2009) As variáveis dimensionais aplicadas em um MOLAP estão frequentemente relacionadas em
hierarquias, que determinam meios para agregar dados das células a elas associados. Nesse contexto, os
operadores do processador que permitem percorrer (para acesso e não para criação) as hierarquias do nível
99
de agregação mais baixo para o mais alto executam a função
(a) snow flake.
(b) roll back.
(c) drill down.
(d) rolap.
xx
(e) drill up.

85
 TI para concursos
100. (ICMS-SP 2009) Se uma empresa de grande porte, com alto volume de transações e informações, resolver
iniciar um projeto usando o conceito de Data Mart (DM) em vez de Data Warehouse (DW),
independentemente disso ser ou não a melhor opção, os fatores que a levam a tal decisão podem ser
justificados por:
I. Possibilidade de extrair e preparar os dados diretamente de fontes de interesse específicas, fornecendo
acesso mais rápido pela não necessidade de sincronia com dados de outras fontes.
II. Menor risco quanto ao sucesso do projeto.
III. Necessidade imediata de informações organizacionais integradas.
100
Está correto o que consta em
(a) I, apenas.
xx
(b) I e II, apenas.
(c) I e III, apenas.
(d) I, II e III.
(e) II e III, apenas.
101. O grande desafio do profissional de TI que gerencia qualquer processo é a análise dos fatos relacionados à
função que exerce em uma organização. Essa análise deve ser feita com as ferramentas e os dados
disponíveis, permitindo aos executivos e gerentes detectar as tendências e tomar as decisões com eficiência
e eficácia. Devido a essa necessidade, surgiu o conceito de Business Intelligence – “BI”.
101
Assinale a alternativa que indique duas características dos atuais sistemas de Business Intelligence.
(a) procurar relações de causa e efeito / extrair e integrar dados de múltiplas fontes.xx
(b) evitar a utilização de ferramentas automatizadas / desprezar dados contextualizados.
(c) extrair e integrar dados de múltiplas fontes / evitar a utilização de ferramentas automatizadas.
(d) desprezar dados contextualizados / trabalhar exclusivamente com fatos reais e não hipotéticos.
(e) trabalhar exclusivamente com fatos reais e não hipotéticos / procurar relações de causa e efeito.
102. (TRT FCC 2008) No âmbito do OLAP, gráficos de produtos são generalizações da estrutura de ......
apresentada por HRU (Harinarayan, Rajaraman e Ullman), na qual as dimensões podem ter hierarquias
102
associadas. Preenche corretamente a lacuna:
(a) tabela.
(b) roll-up.
(c) data mart.
xx
(d) hipercubo.
(e) drill-down.
103. Uma das funcionalidades do OLAP, utilizada para realizar operações de projeção nas dimensões,
compreende a extração de informações sumarizadas de um cubo de dados e extração de um "subcubo", a
103
partir do valor de uma dimensão. Trata-se de
(a) sorting.
(b) pivot and sorting.
(c) drill-up.
(d) selection.
xx
(e) slice and dice.
104
104. Para eliminar a condição de existência de valores não atômicos em uma coluna de tabela relacional,
(a) deve ser aplicada, no mínimo, a primeira Forma Normal.xx
(b) devem ser aplicadas, no mínimo, as quatorze regras de Codd.
(c) deve ser aplicada, no mínimo, a Forma Normal Boyce-Codd.
(d) deve ser aplicada, no mínimo, a terceira Forma Normal.
(e) devem ser aplicadas, no mínimo, as regras de integridade referencial.
105
105. Um banco de dados relacional normalizado significa que as relações que o compõe atendem à
(a) 1FN, no máximo.
xx
(b) 3FN, no mínimo.
(c) 2FN, mas não necessariamente 1FN.
(d) 2FN, no máximo.
(e) 3FN, mas não necessariamente a 1FN e 2FN.
106
106. Uma relação estará na Segunda Forma Normal (2FN) se ela estiver na 1FN e todos os atributos
(a) não chave forem dependentes não transitivos da chave primária.
xx
(b) não chave forem totalmente dependentes da chave primária.
(c) chave forem dependentes não transitivos das chaves estrangeiras.
(d) chave forem totalmente dependentes das chaves estrangeiras.
(e) chave forem totalmente dependentes dos atributos não chave.
107
107. Em um modelo E-R, o tipo de associação unária é aquela em que
(a) uma entidade se relaciona unicamente com uma outra entidade.
(b) uma entidade se relaciona com ela própria.xx
(c) uma entidade não se relaciona com qualquer outra entidade, nem com ela própria.
(d) um relacionamento é do tipo 1:1, somente.
(e) um relacionamento é do tipo 1:1 ou N:1.

86
 TI para concursos
108. Sobre um modelo E-R, considere que uma chave primária
I. simples pode ser constituída de um atributo atômico ou de um atributo composto.
II. simples pode ser constituída de apenas um atributo atômico.
III. composta pode ser constituída de um atributo composto.
IV. composta pode ser constituída de dois ou mais atributos atômicos.
108
Está correto o que consta APENAS em
(a) III e IV.
(b) II e III.
(c) II e IV.
(d) I e II.
xx
(e) I e IV.
109. Um sistema de informação que fornece um arquivo para ser tratado pelo sistema objeto da modelagem,
109
utilizando DFD da análise estruturada, é caracterizado como
(a) fluxo de dados.
xx
(b) entidade externa.
(c) depósito de dados.
(d) processo funcional do sistema.
(e) processo do diagrama de contexto.
110
110. Na modelagem funcional
xx
(a) uma entidade externa pode enviar ou receber um fluxo de dados de uma função.
(b) uma função pode enviar, mas não receber um fluxo de dados de um depósito de dados.
(c) uma entidade externa representa a mesma coisa que uma entidade no modelo entidade relacionamento.
(d) uma entidade externa pode enviar, mas não receber um fluxo de dados de um depósito de dados.
(e) uma entidade externa pode receber, mas não enviar um fluxo de dados a um depósito de dados.
111. Quando dois conjuntos de dados são concatenados de acordo com uma determinada condição, representa o
111
resultado da operação relacional
(a) junção.xx
(b) união.
(c) restrição.
(d) projeção.
(e) intersecção.
112. Um comando SQL executa uma operação que exibe
I. certas colunas de uma relação, denominada subconjunto vertical.
II. todas as linhas que aparecem em ambas as relações.
III. apenas aquelas linhas que existem em ambos os conjuntos.
112
As definições acima correspondem, respectivamente, aos operadores relacionais
(a) união, projeção e intersecção.
(b) união, intersecção e projeção.
(c) intersecção, projeção e união.
xx
(d) projeção, união e intersecção.
(e) projeção, intersecção e união.
113
113. A linguagem PL/SQL, introduzida nos gerenciadores de banco de dados ORACLE,
(a) aumenta a capacidade não-procedural da SQL, oferecendo e combinando blocos de construtores
procedurais.xx
(b) constitui uma interface básica pela qual pode-se entrar e executar comandos SQL para manipulações
genéricas de um banco.
(c) trata-se de uma linguagem que identifica quais as informações necessárias e não como buscá-las.
(d) tem os seus comandos executados pelo executor de SQL do Kernel.
(e) tem os seus comandos enviados para serem processados pelo SGBD um por vez.
114. A linguagem PL/SQL é uma estrutura em blocos, compostos basicamente das partes declarativa, executável
114
e manipulação de exceções, as quais são, respectivamente, de uso
(a) opcional, para todas as partes.
(b) obrigatório, para todas as partes.
(c) opcional, obrigatório e obrigatório.
(d) obrigatório, obrigatório e opcional.
xx
(e) opcional, obrigatório e opcional.
115
115. Um bloco PL/SQL que está associado a um evento ocorrido no banco de dados Oracle é do tipo
(a) função.
xx
(b) gatilho.
(c) anônimo.
(d) procedimento.
(e) dinâmico.

87
 TI para concursos
116. A estrutura lógica de armazenamento nas bases de dados Oracle é representada na seqüência hierárquica
116
de
(a) segmentos, blocos de dados e extensões.
(b) segmentos, extensões e blocos de dados.xx
(c) extensões, segmentos e blocos de dados.
(d) extensões, blocos de dados e segmentos.
(e) blocos de dados, segmentos e extensões.
117
117. Na estrutura lógica do Oracle NÃO estão contidos
(a) extents.
(b) data blocks.
xx
(c) data files.
(d) schemas.
(e) tablespaces.
118
118. Todos os dados de uma tabela Oracle são armazenados em extents de um
xx
(a) data segment.
(b) index segment.
(c) temporary segment.
(d) rollback segment.
(e) redlog segment.
119
119. Quando um banco de dados Oracle é iniciado, será alocado para os processos background
(a) um schema.
(b) um ou mais redo log files.
(c) um ou mais control files.
(d) uma tablespace.
xx
(e) uma área global de sistema.
120
120. As cláusulas do comando de consulta da linguagem SQL devem ser escritas na seqüência
(a) SELECT, HAVING, FROM, WHERE, GROUP BY e ORDER BY.
(b) SELECT, HAVING, FROM, WHERE, ORDER BY e GROUP BY.
(c) SELECT, FROM, WHERE, ORDER BY, HAVING e GROUP BY.
(d) SELECT, FROM, WHERE, GROUP BY, HAVING e ORDER BY.xx
(e) SELECT, FROM, WHERE, GROUP BY, ORDER BY e HAVING.
121. Para mostrar a composição de peças e respectivos componentes (peças são compostas de peças), em um
121
DER, usa-se
(a) o grau de relacionamento quaternário.
(b) a cardinalidade ternária.
(c) a entidade fraca.
(d) a entidade associativa.
xx
(e) o auto-relacionamento.
122
122. Um relacionamento pode ser representado graficamente no diagrama de Entidade-Relacionamento por
(a) uma elipse.
(b) um retângulo.
(c) um círculo.
xx
(d) um losango.
(e) números da cardinalidade.
123. Considere, as definições abaixo:
I. Especificação do número de ocorrências de um objeto que pode ser relacionado ao número de ocorrências
de outro objeto.
II. Especificação da participação (ou não) do relacionamento de um objeto em particular.
123
Na modelagem de dados estas definições pertencem, respectivamente, a
(a) grau e cardinalidade.
(b) cardinalidade e grau.
xx
(c) cardinalidade e modalidade.
(d) modalidade e cardinalidade.
(e) modalidade e grau.
124. Em um banco de dados relacional, a operação de exclusão sobre a tabela referenciada se propaga para
124
todas as chaves estrangeiras correspondentes quando usada a expressão SQL ANSI on delete
(a) set default.
(b) spread.
(c) propagate.
(d) cascade.xx
(e) set null.

88
 TI para concursos
125. Uma transação executará qualquer operação somente depois que o gerenciador de banco de dados
125
conceder o bloqueio do dado por meio do
(a) gerenciador de arquivos.
(b) seletor de estratégia.
xx
(c) controlador de concorrência.
(d) gerenciador de recuperação.
(e) gerenciador de buffer.

89
 TI para concursos

7 Programação de Sistemas
7.1 Lógica de Programação
O computador, como todo componente eletrônico, só entende sinais de carga elétrica sequenciadas,
um choquinho após o outro. Dividido em diversos tipos de componentes físicos que se comportam de
forma diferente ao estímulo elétrico, pode-se determinar a ação de um equipamento eletrônico
alterando-se o sequenciamento destas peças pela ação de chaves (componentes eletrônicos) que
desviam o fluxo de energia. Esta definição da sequência de chaves, que determina por onde e quando
a corrente elétrica vai passar resultando em um comportamento previsto do sistema elétrico, é
chamada de programação.
Os primeiros programadores definiam e alteravam estas chaves diretamente com fios em placas. A
evolução permitiu que a programação pudesse ser feita por sequenciamento lógico de números que
poderiam ser transferidos para os computadores através de cartões perfurados ou textos digitados que
alteravam o estado das chaves sem o programador ter que manusear o equipamento diretamente.
Programas pré-concebidos traduziam palavras (em inglês), textos inteligíveis, em comandos em
linguagem da máquina (números). Estes programas são os compiladores. Endereços de memória que
contém dados recebem nomes pelo programador (variáveis). Programar passou, então, a ser redigir um
texto obedecendo certas regras de sintaxe, submeter o texto a um compilador que faz a tradução para
a linguagem que a máquina consegue processar.
Por certo tempo, programação consistia em sequenciar comandos e atribuir “endereços” (números ou
índices), a eles. Para se repetir uma sequencia de comandos, ou seja, fazer uma iteração, utilizava-se
um comando para desviar o processamento para o endereço do primeiro comando da sequencia. Os
comandos eram basicamente: leia, armazene na variável, faça a conta, grave (na tela, disco ou
impressora) e desvie para o endereço tal, além do comando de condição SE (IF - se o valor for tanto,
pule para o endereço tal). Era a programação indexada. Tudo era controlado por números e o
programador tinha que pensar como máquina. Um exemplo, era a linguagem Basic:
10 CLS
20 INPUT “DIGITE UM VALOR PARA A: “ A
30 INPUT “DIGITE UM VALOR DIFERENTE PARA B “ B
40 IF A=B GOTO 30
50 IF A>B GOTO 80
60 PRINT “O VALOR A E´ MENOR DO QUE B”
70 GOTO 90
80 PRINT “O VALOR A E´ MAIOR DO QUE B”
90 PRINT “FIM DE PROCESSAMENTO”
Com a criação dos comandos do tipo declaração (statement): enquanto (while), repita-até que (repeat
until), caso (case) e para-faça (for do); o sequenciamento de comandos passou a apresentar o formato
de uma contrução lógica, dispensando a numeração das linhas de programação. Os comandos
passaram a ser agrupados em blocos, chamados de sub-rotinas, ou procedimentos (procedures e
functions), que recebem um nome e podem ser utilizados como novos comandos. Esta era a
programação estruturada, procedural ou procedimental. O próprio programa passa a ser visto como um
grande bloco formado por blocos menores e comandos. Por exemplo, um programa para calcular
fatorial em linguagem turbo pascal.

90
 TI para concursos
Program Fatorial;
Var
Numero : integer;

Function Calcula_Fatorial(n: integer) : integer;

Begin
If n>1 then
Calcula_Fatorial := n*Calcula_Fatorial(n-1)
Else
Calcula_Fatorial := 1;
End;

Begin
repeat
Clrscr;
Write(‘Digite um número inteiro positivo (zero para terminar): ‘);
Readln(Numero);
If Numero>=0 then
Writeln(‘O fatorial de ‘, Numero, ‘ é ‘, Calcula_Fatorial(Numero))
Else
Writeln(‘Valor inválido’);
Until Numero=0;
Writeln(‘Fim de processamento.’);
End.
A grande revolução na arte da programação de computadores foi quando alguém percebeu que o
homem não deve pensar como máquina para escrever um programa, mas deve fazer o computador
comportar-se como gente e compreender comandos humanos. Criou-se uma técnica de raciocínio em
que o programa de computador podia ser visto como um objeto que se comporta como aquilo que
conhecemos na vida real.
 Tem qualidades, aspectos, características ou, genericamente, atributos.
 Tem comportamento. Pode ser móvel ou não, fazer coisas.
 É formado por objetos menores (até o átomo, ou menor) que possuem também atributos e
comportamentos
Quando esta técnica se transformou em uma linguagem, criou-se a programação orientada a objetos.
Ela utiliza uma nova forma de fazer programas, não jogou fora todos os aspectos positivos da
programaçao procedimental e estruturada, mas evoluiu estes conceitos. Os procedimentos e funções
são chamados de métodos quando estão dentro de um objeto. As variáveis internas ao objeto são
chamadas de propriedades ou atributos.
O conjunto de valores das propriedades formam o estado do objeto. Mensagens são ações de
dispositivos externos (teclado, mouse, placa de rede, scanner, outros programas) ou de outros objetos
que provocam mudanças de estado. Algumas mudanças do estado do objeto podem determinar uma
situação em que algum método deve ser executado (ação). Por exemplo, um clique do mouse sobre
um objeto botão muda a propriedade “Clicado” de falso para verdadeiro. O seu novo estado pode
desencadear uma sequencia de comandos ou métodos. Mudanças de estado que fazem uma ação são
chamadas de eventos. Neste exemplo, o clique do mouse aciona um evento chamado “OnClick” (se
existir).
A partir disto, um programa deixou de ser um simples sequenciamento de comandos para ser uma
série de ações que provocam mudanças de estado que podem desencadear outras ações.

7.1.1 Tipos de dados e variáveis

Durante o seu processamento, um programa deve necessitar de dados para efetuar cálculos e
tratamentos e devolver informação ao usuário. Estes dados são introduzidos por qualquer meio, como
digitação, envio de parâmetros por outro objeto ou leitura em um arquivo, depois armazenados em
áreas da memória do computador chamadas de variáveis. Os valores armazenados nas variáveis
podem ser utilizados através de seu endereço físico na memória (por apontadores ou pointers) ou, mais
comum, por um nome atribuído á variável.
Da mesma forma que não se somam bananas com maçãs, o programa não costuma misturar tipos
diferentes de dados em suas operações. O programador deve ter conhecimento dos tipos possíveis de
dados para não provocar erros no processamento. Linguagens de programação são ditas tipadas
quando exigem que as variáveis a serem utilizadas sejam pré-definidas como seu nome e tipo, como
no pascal. São não tipadas quando as variáveis são definidas no momento de sua utilização,
assumindo um determinado tipo de acordo com o valor atribuído a ela.

91
 TI para concursos
De forma geral, define-se como numérico os valores que serão utilizados para cálculos algébricos. São
de tipo lógico as variáveis que assumem apenas dois estados, verdadeiro ou falso, ou equivalente (0 ou
1, v ou t, sim ou não etc). São alfanuméricas as variáveis que não são destinadas a cálculos, mas
somente operações de comparações, buscas, concatenações ou simples exibição. São de tipo
apontador, variáveis que armazenam endereços de memória.
Dependendo da linguagem de programação, as variáveis numéricas podem se subdividir em reais ou
inteiras, e também em outras variações destes dois tipos, como inteiro não negativo, monetário, inteiro
longo etc. O tipo alfanumérico também pode receber variações como memorando (texto), ou texto
formatado.
Existem também outros tipos de armazenamento de dados na memória, que são agrupamentos de
variáveis:
 Vetor – conjunto de variáveis identificado por um nome e números inteiros positivos (começando em
zero) para cada elemento. A parte numérica do nome da variável fica entre parênteses ou colchetes
à direita do nome. Para se referir a uma posição do vetor, a parte numérica pode ser resultado de
uma operação matemática. Um vetor que utiliza mais do que um número (dimensões) para
identificar cada uma de suas posições (separados por vírgulas) é chamado de matriz.
 Registro – grupo de variáveis de vários tipos, identificado por um nome. Cada variável dentro de um
registro é chamada de campo.
 Lista – conjunto de registros ligados por apontadores, usado em conjunto de dados hierárquicos em
que a relação entre os dados não precisa ser representada em forma de matrizes, ou para
armazenar dados de uma tabela na memória para algum tratamento especial.
 Fila – sequência de dados ordenados, em que o primeiro dado que entra na fila deve ser o primeiro
a sair (FIFO – First in first out ou LILO - Last in last out)
 Deque – fila em que os elementos podem ser inseridos ou removidos de qualquer extremo.
 Pilha – sequência de dados em que o último valor adicionado deve ser o primeiro a sair (LIFO - Last
in first out ou FILO - First in last out)

7.2 Programação orientada a objetos

A análise e o projeto orientados a objetos têm como meta identificar o melhor conjunto de objetos para
descrever um sistema de software. O funcionamento deste sistema se dá por meio do relacionamento e
troca de mensagens entres os objetos.
As linguagens de programação que dão suporte a orientação a objetos são:
Smaltalk, Perl, Python, Ruby, PHP, ColdFusion, C++, Object Pascal, Java, JavaScript, ActionScript,
Delphi (object pascal) e C#.
Os conceitos mais importantes na programação orientada a objetos são:
 Objetos (instâncias) e encapsulamento
 Classes
 Persistência
 Métodos e propriedades
 Herança e classes hierárquicas
 Polimorfismo
 Interfaces
 Sobrecarga
Para uma linguagem ser considerada verdadeiramente orientada a objetos, a linguagem de
programação deve oferecer, no mínimo, as características de: encapsulamento, herança e
polimorfismo.

7.2.1 Objetos
Objeto é uma abstração do mundo real. Objetos de software são modelados de acordo com os objetos
do mundo real, ou seja, possuem estado e comportamento. Um objeto de software armazena seu
estado em variáveis e implementa seu comportamento com métodos. Estas variáveis e métodos são
formalmente chamados de variáveis de instância e métodos de instância a fim de distingui-los de
variáveis e métodos de classe.
As variáveis de um objeto fazem parte do seu núcleo (centro). Os métodos envolvem e escondem
(empacotam) o núcleo do objeto de outros componentes da aplicação. Empacotar as variáveis de um

92
 TI para concursos
objeto sobre proteção de seus métodos é chamado de encapsulamento. O encapsulamento é utilizado
para esconder detalhes de implementação. Este é um dos princípios fundamentais da programação
orientada a objetos.
Às vezes, por razões de eficiência ou implementação, um objeto deseja expor algumas de suas
variáveis ou esconder alguns de seus métodos. Esta capacidade de controlar quais componentes
podem acessar seus métodos e suas variáveis é chamada de Controle de Acesso.
Cada objeto tem sua identidade, o que significa que dois objetos são distintos mesmo que eles
apresentem exatamente as mesmas características (atributos iguais). Esta identificação de objeto deve
ser única, uniforme e independente do conteúdo do objeto.
Em geral, os objetos possuem, pelo menos, dois métodos:
 Construtor: define o comportamento no momento da criação de um objeto de uma classe;
 Destrutor: define o comportamento no momento da destruição do objeto de uma classe.
Normalmente utilizado para liberar recurso (memória) do sistema.

7.2.2 Classe
Objetos podem apresentar métodos e atributos (propriedades) idênticos. Em relação a estes elementos
em comum, dizemos que eles pertencem a uma mesma classe. Na programação orientada a objeto,
classe é uma abstração, enquanto que, neste contexto, objeto é considerado um elemento fático.
Uma classe é um modelo, ou protótipo, que define as variáveis (estado) e os métodos (comportamento)
comuns a todos os objetos do mesmo tipo. Na classe são definidas as variáveis e implementados os
métodos. Os objetos são criados a partir de suas classes.
Dois botões na tela pertencem à classe botão. Espera-se deles que respondam ao clique do mouse,
costumam ser cinzas, em alto-relevo e ficam em baixo-relevo ao clicar.
Por outro ponto de vista, podemos dizer que uma classe botão, cinza, em alto-relevo, com determinado
comportamento ao clicar, pode ter duas instâncias na tela. Definidas as características de um tipo de
botão, ao criar (instanciar) um objeto, por uma instrução determina-se que ele fará parte da classe, e
isto fará com que ele herde todas as características de um botão típico. Depois de instanciado, ações
poderão alterar seu estado, como sua aparência e comportamento.
Na programação orientada a objetos, implementa-se um conjunto de classes que definem os objetos
presentes no sistema de software. Cada classe determina o comportamento (métodos e eventos) e os
estados possíveis (valores dos atributos) de seus objetos, assim como o relacionamento com outros
objetos.
As classes não são diretamente suportadas em todas as linguagens de objetos, e não são necessárias
para que a linguagem seja orientada a objetos.
A classe define as características comuns e os objetos são instâncias dessa classe, com estado
próprio.

7.2.3 Persistência
Alguns objetos são criados, cumprem sua função e são destruidos logo em seguida. Outros objetos
continuam por tempo indeterminado e isto é chamado de persistência. Não faz sentido falar de
persistência de classes, somente de instâncias (objetos).

7.2.4 Métodos
Método é uma sub-rotina interna a um objeto, que pode ser executado por uma ação externa, isto é, ao
receber uma mensagem, ou por uma ação interna de um evento.

93
 TI para concursos

7.2.5 Atributos
Os atributos são os elementos que definem a estrutura de uma classe. Os atributos também são
conhecidos como variáveis de classe, e podem ser divididos em dois tipos básicos: atributos de
instância e de classe.
Os valores dos atributos de instância determinam o estado de cada objeto. Um atributo de classe
possui um estado que é compartilhado por todos os objetos de uma classe. Atributos de classe podem
ser chamados também de atributos estáticos ou constantes.

7.2.6 Mensagens
Objetos modificam seu estado por meio do recebimentos de mensagens. Alguns métodos de um objeto
que recebe a mensagem precisam de informações, os parâmetros, para saber exatamente o que fazer.
Assim, três componentes fazem parte de uma mensagem:
 o objeto para onde a mensagem é endereçada;
 o nome do método a realizar;
 parâmetro(s) necessários para realizar o método;

7.2.7 Herança
A herança é um mecanismo que permite criar novas classes a partir de classes já existentes,
aproveitando-se das características existentes na classe a ser extendida. Com a herança é possível
criar classes derivadas (sub-classes) a partir de classes bases (superclasses).
As subclasses herdam todas as características de suas superclasses, como suas variáveis (estado) e
seus métodos (comportamento). Entretanto, as subclasses não estão limitadas ao comportamento
herdado de sua super-classe. As subclasses podem adicionar variáveis e métodos a aqueles herdados.
As subclasses, também, podem redefinir (override) métodos herdados e oferecer implementações
especializadas para estes métodos. O conceito de herança pode ser aplicado para mais de um nível. A
árvore de herança, ou hierarquia de classe, pode ser tão profunda quanto necessário. Os métodos e
variáveis são herdados por meio dos níveis. Em geral, quanto mais baixa na hierarquia for a posição da
classe, mais específico é o seu comportamento.
Como benefícios do conceito de herança, podemos citar:
 Programadores podem definir classes abstratas que determinam comportamentos genéricos.
 Subclasses oferecem comportamentos especializados a partir de elementos básicos comuns,
oferecidos pela superclasse.
 A utilização de herança promove o reuso e reaproveitamento de código existente, tornando a
manutenção do código mais eficiente.
A superclasse define e pode implementar parcialmente o comportamento de uma classe, mas a maioria
das informações da classe fica indefinida ou não é implementada.
A herança múltipla ocorre quando uma classe pode estender características de várias outras classes ao
mesmo tempo, ou seja, quando a subclasse possui mais de uma superclasse. Algumas linguagens
evitam utilizar este mecanismo, pois pode levar uma codificação confusa o que dificulta a manutenção
do código. A linguagem Java não suporta herança múltipla, apenas herança simples. Já a linguagem
C++ oferece suporte à herança múltipla.
Uma linguagem ao utilizar herança múltipla está sujeita a dois problemas: colisão de nomes (nomes
idênticos nas classes superiores) e herança repetida (classe herda de uma classe superior que herda
de uma classe comum);

7.2.8 Polimorfismo
Segundo a terminologia de orientação a objetos, polimorfismo significa que uma mesma mensagem
enviada a diferentes objetos resulta em um comportamento que é dependente da natureza do objeto
que está recebendo a mensagem. Ou seja, duas ou mais classes derivadas de uma mesma super-
classe podem invocar métodos que têm a mesma assinatura (nome, lista de parâmetros e retorno),
mas comportamentos distintos, especializado para cada classe derivada, usando para tanto uma
referência a um objeto do tipo superclasse.
A decisão sobre qual método deve ser selecionado, de acordo com o tipo da classe derivada, é tomada
em tempo de execução por meio do mecanismo de ligação tardia. No caso do polimorfismo, é

94
 TI para concursos
necessário que os métodos tenham exatamente a mesma identificação, sendo utilizado o mecanismo
de redefinição de métodos.
Os benefícios do polimorfismo são: a clareza e manutenção do código, a divisão da complexidade e
aplicações flexíveis. Algumas linguagens promovem o polimorfismo principalmente por meio do uso de
classes abstratas e interfaces, como é o caso da linguagem Java.

7.2.9 Sobrecarga
A sobrecarga é um tipo de polimorfismo que permite a existência de vários métodos de mesmo nome,
porém com assinaturas levemente diferentes, ou seja, variando no número e tipo de argumentos e o
valor de retorno. Ficará a cargo de o compilador escolher de acordo com as listas de argumento os
procedimentos ou métodos a serem executados. Por exemplo:
public class Soma
{ public int Soma (int x, int y)
{return x+y;}

public String Soma (String x, String y)

{return x+y;}

public double Soma (double x, double y)

{return x+y;}
}

7.2.10 Interfaces
Interface é a relação de métodos, com seus parâmetros, das propriedades que podem ser acessados
por outros objetos e também pode incluir declarações de constantes.
Uma interface apresenta somente as definições de métodos, sem sua implementação. A classe que
implementa a interface deve implementar todos os métodos definidos na interface.

7.2.11 Pacotes
Para tornar as classes mais fáceis de serem encontradas e utilizadas, para evitar conflitos de nomes e
para controlar o acesso, pode-se agrupar classes relacionadas em pacotes (packages). Os pacotes
organizam as classes e as interfaces relacionadas. Cada pacote criado corresponde a um diretório, ou
seja, as classes e as interfaces de um mesmo pacote devem estar em um mesmo diretório.
A utilização de pacotes proporciona as seguintes vantagens:
 Fica mais fácil para outros programadores determinar quais classes e interfaces estão relacionadas.
 Os nomes das classes de um pacote não irão conflitar com nomes e classes de outros pacotes.
 Pode-se permitir que classes dentro de um mesmo pacote tenham acesso irrestrito entre si, e
restringir o acesso por parte de classes definidas fora do pacote.
Apenas os membros (classe, variáveis e métodos) públicos são acessíveis fora do pacote onde foram
definidos.

7.3 Programação na WEB

Visualizar uma página web ou outro recurso disponibilizado normalmente inicia ou ao digitar uma URL
no navegador ou seguindo (acessando) uma hiperligação. Primeiramente, a parte da URL referente ao
servidor web é separada e transformada em um endereço IP, por um banco de dados da Internet
chamado Domain Name System (DNS). O navegador estabelece então uma conexão TCP-IP com o
45
servidor web localizado no endereço IP retornado.
O próximo passo é o navegador enviar uma requisição HTTP ao servidor para obter o recurso indicado
pela parte restante da URL (retirando-se a parte do servidor). No caso de uma página web típica, o
texto HTML é recebido e interpretado pelo navegador, que realiza então requisições adicionais para
figuras, arquivos de formatação, arquivos de script e outros recursos que fazem parte da página.
O navegador então renderiza a página na tela do usuário, assim como descrita pelos arquivos que a
compõe.
A funcionalidade da Web é baseada em três padrões:

45 http://pt.wikipedia.org/wiki/World_Wide_Web
95
 TI para concursos
 URI, um sistema que especifica como cada página de informação recebe um "endereço" único onde
pode ser encontrada.
 HTTP, um protocolo que especifica como o navegador e servidor web comunicam entre si.
 HTML, uma linguagem de marcação para codificar a informação de modo que possa ser exibida em
uma grande quantidade de dispositivos.
Desta forma, programar para Web é escrever páginas em HTML. Para isto, o programador pode
escrever um texto em HTML puro e gravar este arquivo em um servidor web. Estes textos são
chamados de páginas estáticas. Elas só mudam quando o programador alterar o arquivo.
Porém, o servidor web utilizado pode ter instalado programas que geram páginas HTML no momento
em que a requisição chega. Neste caso, o texto requisitado não é um texto HTML, mas é um código em
alguma linguagem de programação que, ao ser processado pelo servidor, gera um texto HTML dentro
das especificações da requisição. Estes textos são chamados de páginas dinâmicas. Estas páginas
permitem a interação com o usuário e com gerenciadores de bancos de dados, podendo gerar páginas
HTML diferentes a cada instante.
Assim, ao projetar um site, o programador decide se vai usar páginas estáticas, dinâmicas ou as duas.

7.3.1 Linguagem HTML

HTML (acrônimo para a expressão inglesa HyperText Markup Language, que significa Linguagem de
Marcação de Hipertexto) é uma linguagem de marcação utilizada para produzir páginas na Web.
Documentos HTML podem ser interpretados por navegadores. A tecnologia é fruto do "casamento" dos
padrões HyTime e SGML.46
HyTime é um padrão para a representação estruturada de hipermédia e conteúdo baseado em tempo.
Um documento é visto como um conjunto de eventos concorrentes dependentes de tempo (como
áudio, vídeo, etc.), conectados por hiper-ligações. O padrão é independente de outros padrões de
processamento de texto em geral.
SGML é um padrão de formatação de textos. Não foi desenvolvido para hipertexto, mas tornou-se
conveniente para transformar documentos em hiper-objetos e para descrever as ligações.
Todo documento HTML apresenta tags (tags), elementos entre parênteses angulares (sinais de maior e
menor). Esses elementos são os comandos de formatação da linguagem. A maioria das tags tem sua
correspondente de fechamento:
<tag>...</ tag >
Isso é necessário porque as tags servem para definir a formatação de uma porção do documento, e
assim marcamos onde começa e termina o texto com a formatação especificada por ela. Alguns
elementos são chamados “vazios”, pois não marcam uma região de texto, apenas inserem algum
elemento no documento:
Uma tag é formada por comandos, atributos e valores. Os atributos modificam os resultados padrões
dos comandos e os valores caracterizam essa mudança.
A estrutura de um documento HTML apresenta os seguintes componentes:
<html>
<head>
<title>Título do Documento</title>
</head>

<body>
texto,
imagem,
links,
...
</body>
</html>
De uma maneira geral o HTML é um poderoso recurso, sendo uma linguagem de marcação muito
simples e acessível voltada para a produção e compartilhamento de documentos e imagens.
As tags HTML não são sensíveis à maiúsculas ou minúsculas, portanto tanto faz escrever <HTML>,
<Html>, <html> ou <HtMl>.
As tags básicas de HTML, cuja presença é altamente recomendada nas páginas são:

46 http://pt.wikipedia.org/wiki/HTML
96
 TI para concursos
 <html>: define o início de um documento HTML e indica ao navegador que todo conteúdo posterior
deve ser tratado como uma série de códigos HTML.
 <head>: define o cabeçalho de um documento HTML, que traz informações sobre o documento que
está sendo aberto.
 <body>: define o conteúdo principal, o corpo do documento. Esta é a parte do documento HTML que
é exibida no navegador. No corpo podem-se definir propriedades comuns a toda a página, como cor
de fundo, margens, e outras formatações.
Dentro do cabeçalho podemos encontrar os seguintes comandos:
 <title>: define o título da página, que é exibido na barra de título dos navegadores.
 <style>: define formatação em CSS (Cascading Style Sheets), uma linguagem de estilo utilizada
para definir a apresentação de documentos escritos em HTML ou XML.
 <script>: define programação de certas funções em página com scripts (códigos de programa) em
diversas linguagens web cliente, como Javascrip, Visual Basic Script, DHTML ou CSS.
Applets de Java
 <link>: define ligações da página com outros arquivos como feeds, CSS, scripts etc.
 <meta>: define propriedades da página, como codificação de caracteres, descrição da página, autor,
etc. São meta informações sobre documento. Tais campos são muitos usados por mecanismos de
busca (como o Google) para obterem mais informações sobre o documento, a fim de classificá-lo
melhor. Por exemplo, pode-se adicionar o código <meta name="description" content="descrição da
sua página" /> no documento HTML para indicar ao motor de busca que texto de descrição
apresentar junto com a ligação para o documento.
As tags <style> e <script> servem tanto para delimitar o espaço usados pelos códigos na página quanto
para invocar códigos existentes em outros arquivos externos.
Dentro do corpo podemos encontrar outras várias tags, como por exemplo:
 <h1>, <h2>,... <h6>: cabeçalhos e títulos no documento em diversos tamanhos. (quanto menor for o
número, maior sera o tamanho da letra)
 <p>: novo parágrafo.
 <br>: quebra de linha.
 <table>: cria uma tabela (linhas são criadas com <TR> e novas células com <TD>. Já os cabeçalhos
de coluna são criados com a tag <TH>.)
 <div>: determina uma divisão na página a qual pode possuir variadas formatações.
 <font>: altera a formatação (fonte, cor e tamanho) de um trecho do texto.
 <b>, <i>, <u> e <s>: negrito, itálico, sublinhado e riscado, respectivamente.
 <img>: imagem.
 <a>: hiper-ligação para um outro local, seja uma página, um e-mail ou outro serviço.
 <textarea>: caixa de texto (com mais de uma linha); estas caixas de texto são muito usadas em
blogs, elas podem ser auto selecionáveis e conter outros códigos a serem distribuídos.
 <acronym>: acrônimo (sigla)
 <cite>: citação
 <address>: endereço
Uma propriedade importante dos documentos HTML é a possibilidade de fazer hiperligações. Para isso
usa-se a tag <a> (do inglês, anchor). Esta tem os atributos: href que define o alvo da hiperligação (que
pode ser uma página de Internet, uma parte da mesma página ou um endereço de email) ou name que
define um alvo nessa página (a onde se pode fazer uma hiperligação usando a tag a com o atributo
href). Exemplos:
<a href="ht­tp://pt.wikipedia.org/">Clique aqui para aceder à página principal da Wikipédia em português.</a>
<a name="nome">texto</a>
Os caracteres especiais definem-se usando comandos que começam com & e terminam com um ;.
Alguns exemplos incluem &aacute; (á), &agrave; (à), &atilde; (ã), &acirc; (â), &auml; (ä) e &ccedil; (ç).
Qualquer outra vogal pode ser substituída pelo a destes exemplos, incluindo maiúsculas.

7.3.2 Linguagens web de servidor

Para a criação de páginas dinâmicas, existem diversas linguagens de programação que podem ser
configuradas no servidor, como, por exemplo, CGI (Common Gateway Interface), ASP (Active Server
Pages), PHP (Hypertext Preprocesor) ou JSP (Java Server Pages).
97
 TI para concursos

7.3.3 XML
O XML (eXtensible Markup Language) é um formato para a criação de documentos com dados
organizados de forma hierárquica, como se vê, frequentemente, em documentos de texto formatados,
imagens vetoriais ou bancos de dados.
É um subtipo de SGML (Standard Generalized Markup Language) capaz de descrever diversos tipos de
47
dados. Seu propósito principal é a facilidade de compartilhamento de informações através da Internet.
Pela sua portabilidade, já que é um formato que não depende das plataformas de hardware ou de
software, um banco de dados pode, através de uma aplicação, escrever em um arquivo XML, e um
outro banco distinto pode ler então estes mesmos dados.
Este exemplo demonstra a sintaxe flexível do XML sendo usada para descrever uma receita de pão:
<?xml version="1.0" encoding="ISO-8859-1"?>
<receita nome="pão" tempo_de_preparo="5 minutos" tempo_de_cozimento="1 hora">
<titulo>Pão simples</titulo>
<ingredientes>
<ingrediente quantidade="3" unidade="xícaras">Farinha</ingrediente>
<ingrediente quantidade="7" unidade="gramas">Fermento</ingrediente>
<ingrediente quantidade="1.5" unidade="xícaras" estado="morna">Água</ingrediente>
<ingrediente quantidade="1" unidade="colheres de chá">Sal</ingrediente>
</ingredientes>
<instrucoes>
<passo>Misture todos os ingredientes, e dissolva bem.</passo>
<passo>Cubra com um pano e deixe por uma hora em um local morno.</passo>
<passo>Misture novamente, coloque numa bandeja e asse num forno.</passo>
</instrucoes>
</receita>
Onde temos na primeira linha:
<Receita nome="pão" tempo_de_preparo="5 minutos" tempo_de_cozimento="1 hora">
"Receita" é o nome principal para o seu documento. Note que a semelhança entre XML e HTML é
grande, na 1ª linha abrimos a tag Receita e na última linha a fechamos, como em HTML, assim se
estendendo por todo o exemplo.
Assim como em HTML, os conteúdos são inseridos entre tags (marcadores) de mesmo nome, sendo
que a segunda tag tem uma barra (/) antes do nome.
O XML apresenta algumas regras básicas:
 Letras maiúsculas e minúsculas são diferentes.
<passo> é diferente de <Passo>
 Nenhuma tag pode ficar aberta. Toda <tag> deve ter uma </tag>.
<passo>Misture todos os ingredientes, e dissolva bem.</passo>
 As tags não podem ficar sobrepostas. Uma tag aberta dentro de outra tag deve ser fechada antes.
<instrucoes>
<passo>Misture todos os ingredientes, e dissolva bem.</passo>
</instrucoes>
 Os atributos devem estar entre aspas.
<ingrediente quantidade="3" unidade="xícaras">

7.4 Conceitos de linguagem de programação Microsoft .NET

No ano de 2000, a Microsoft apresentou ao mundo a plataforma .Net e seu novo ambiente de
desenvolvimento, o Visual Studio .Net.
A .Net, em sua essência, é muito similar ao J2EE (Java 2 Enterprise Edition).
Um compilador .Net gera um código intermediário, e quando é executado, o compilador JIT (Just in
Time) traduz este código intermediário para código nativo do processador, com um enorme ganho de
performance.
A .Net também oferece independência de plataforma, hardware e linguagem de programação.

47 http://pt.wikipedia.org/wiki/XML
98
 TI para concursos

7.4.1 arquitetura da .Net

Existem termos e conceitos que devem ser entendidos para se utilizar a .Net.

7.4.2 Linguagens de programação

Esta é a primeira camada da plataforma. Neste nível ficam as ferramentas de desenvolvimento e os
respectivos compiladores.
A .Net oferece independência de linguagem. Atualmente existem mais de trinta com suporte para .Net.
Todas as linguagens .Net obrigatoriamente devem seguir os padrões da plataforma. Quando dizemos
que uma linguagem é compatível com .Net, entendemos que ela usa o CLR e a FCL.
A Microsoft oferece quatro linguagens com sua plataforma:
 C# (leia-se C Sharp), com características herdadas do C++ e Java, mas muito mais fácil de
aprender e utilizar
 VB.Net, a versão do Visual Basic que foi reescrito para a plataforma
 C++ Embedded, a versão C++ da .Net, pouquíssimo usada
 J# (leia-se Jei Sharp), a versão Java da .Net, também muito pouco usada, cujo objetivo é apenas
facilitar a migração dos desenvolvedores Java para a .Net.
Oferece total compatibilidade com suas linguagens, onde códigos escritos numa determinada
linguagem podem ser executadas em outra sem nenhum problema. Ou seja, é possível escrever uma
classe em C#, herdá-la em VB.Net e usá-la no C++ Embedded (a versão C++ da .Net).
99
 TI para concursos

7.4.3 Common Language Specification (CLS)

A Microsoft liberou um conjunto de especificações que uma linguagem deve possuir para ser
considerada compatível com .Net. Como a IL (ou o assembly .Net) é uma linguagem muito rica, não é
necessário que sejam implementadas todas suas funcionalidades, basta uma parte dela para tornar a
linguagem compatível. Esta é a razão pela qual muitas linguagens, procedurais ou oop, já estão
executando sob o guarda-chuva da .Net. A CLS basicamente determina especificações de
desenvolvimento e estabelece certos padrões. Por exemplo, não pode haver declaração de funções
globais, acesso a ponteiros, herança múltipla e coisas deste tipo. Um detalhe importante é que, se seu
código está dentro das fronteiras estabelecidas pela CLS, é garantido que ele poderá ser utilizado por
qualquer outra linguagem da plataforma.

7.4.4 Common Type System (CTS)

Como a CLS, a Common Type System também é um conjunto de padrões que define os tipos de dados
básicos que a IL entende. Toda linguagem .Net deve mapear seus tipos primitivos para estes padrões.
Isto possibilita que as linguagens se comuniquem passando/recebendo parâmetros de uma para a
outra. Por exemplo, a CTS define um tipo Int32 como um inteiro de 32 bits (4 bytes), o qual é chamado
(ou mapeado) em C# como int e em VB.Net como integer. Mas pra .Net ambos são iguais, ou seja, um
Int32.

7.4.5 Framework Class Library (FCL)

A .Net oferece uma gigantesca biblioteca de classes básicas para as tarefas mais comuns e usuais. A
FCL contém milhares de classes para acesso a API do Windows e funções em geral, como
manipulação de strings, estrutura de dados, entrada/saída, fluxos, segurança, multi-tarefa,
programação em rede, Web, acesso a dados, etc. Ela é simplesmente a maior biblioteca padrão já
fornecida por qualquer linguagem de programação ou ambiente de desenvolvimento. A melhor parte da
FCL são seus padrões de desenvolvimento totalmente OOP, tornando seu acesso e utilização muito
simples e previsíveis. Você utiliza estas classes em seus programas como utilizaria qualquer outra,
inclusive aplicando herança e polimorfismo nelas. Esta biblioteca é organizada hierarquicamente numa
estrutura chamada namespace. Ao desenvolver qualquer software, ele precisa ser estruturado numa
namespace para que possa ser usado a partir de outro programa externo (veremos namespaces
oportunamente).

7.4.6 Camada de apresentação

Este nível define o tipo de interação do sistema com o usuário, que pode ser através de uma aplicação
Web (utilizando o ASP.Net e Web Forms), Windows (utilizando Windows Forms) ou console (utilizando
um prompt de comando, em modo caracter). Na minha opinião, os sistemas para Smart Devices (como
Pockets, celulares, etc) também deveriam ser considerados uma camada de apresentação diferente,
mas neste esquema eles foram incluídos com os Windows Forms.

7.4.7 ADO.Net
Esta camada é responsável pela comunicação das aplicações com os banco de dados. Basicamente, o
ADO.net trabalha de duas formas:
• Modo conectado: utilizando objetos das classes managed provider, que permitem que você se
conecte ao banco de dados e execute instruções SQL diretamente;
• Modo desconectado: neste modo, você armazena informações de um banco de dados localmente, na
memória do computador onde a aplicação está executando. Estas informações são armazenadas em
objetos das classes Dataset, que permitem qualquer operação aceita por um banco de dados, também
conhecida pela sigla CRUD (Create, Retrieve, Update, Delete) ou seja, criar, recuperar, atualizar e
excluir linhas (ou registros). Periodicamente, uma conexão é feita com o banco e as informações são
sincronizadas. Deste modo, você pode criar aplicações para Web ou dispositivos móveis (tipo Pocket
PC), que não tem uma conexão permanente com o banco, ou mesmo aplicações Windows rodando
numa rede local ou remota.

7.4.8 .Net Remoting

Remoting é o processo no qual programas ou componentes se interagem dentro de certos limites.
Estes contextos normalmente são máquinas ou processos diferentes. Na .NET Framework, esta
tecnologia fornece a base para aplicações distribuídas, ou seja, ela simplesmente substitui o DCOM.
• DCOM é a abreviatura de Distributed Component Object Model, uma extensão do COM (Component
Object Model) que permite que objetos se comuniquem em uma rede. Componentes COM tradicionais
100
 TI para concursos
somente executam esta comunicação entre processos na máquina local. O DCOM usa o mecanismo
RPC para enviar e receber informações entre componentes COM (clientes e servidores) na mesma
rede.
o RPC é a abreviatura para Remote Procedure Call, um tipo de protocolo que permite que um
programa num computador execute outro programa num servidor. Com esta técnica, o desenvolvedor
não precisa criar procedimentos específicos para o servidor. O programa cliente envia uma mensagem
ao servidor, com os argumentos apropriados, e o servidor retorna uma mensagem contendo o resultado
do programa executado.
o A rede a que nos referimos pode ser uma LAN, WAN ou a própria Internet (que não passa de uma
rede mundial gigantesca).
Implementações Remoting geralmente fazem distinção entre objetos remotos e objetos móveis.
• Objetos remotos: Remoting fornece a capacidade de executar métodos em servidores remotos,
passando parâmetros e recebendo valores de retorno. O objeto remoto sempre fica num servidor e as
outras máquinas apenas passam uma referência a ele.
• Objetos móveis: Neste caso os dados enviados são serializados (organizados) num formato que pode
ser binário ou legível para nós, como XML, e de-serializados no outro contexto envolvendo o processo.
Ambos, servidor e cliente, mantém cópias do mesmo objeto. Nestas cópias, os métodos são
executados no contexto local e nenhuma mensagem vai trafegar de volta a máquina que originou o
objeto. Na verdade, após a serialização e de-serialização os objetos copiados são idênticos aos objetos
locais normais, e não há distinção entre um objeto servidor e um objeto cliente.
A .NET expande este conceito para incluir a habilidade de definir contextos adicionais dentro de uma
aplicação em execução, e o acesso a estes objetos além dos seus limites também passarão pelo .NET
Remoting Framework.

7.4.9 Common Language Runtime (CLR)

O conceito mais importante da .Net Framework é a existência e funcionalidade do Common Language
Runtime (CLR), também conhecida como .Net Runtime ou máquina virtual .Net. Ele é uma camada do
framework que fica acima do sistema operacional e manipula a execução de todas as aplicações .Net.
Nossos programas não se comunicam diretamente com o sistema operacional, apenas através do CLR.
Ele é o responsável por chamar o compilador JIT (Just In Time, ou em tempo de execução) e
transformar o código MSIL (Microsoft Intermediate Language ou assembly), gerado pelos compiladores
.Net, em código nativo da plataforma onde está executando. Ou seja, quando você compila um
programa ou dll .Net você obtém um arquivo com a extensão .exe ou .dll mas estes arquivos não
executarão se o CLR não estiver instalado.
O CLR também contém o Garbage Collector (GC), ou coletor de lixo, o qual executa como uma tarefa
de baixa prioridade e verifica por espaços de memória não referenciados, alocados dinamicamente. Se
ele encontra algum dado que não é mais utilizado por nenhuma variável/referência, ele libera esta
memória para o sistema operacional usá-lo para outros programas, quando necessário. A presença do
GC libera o programador da tarefa de administrar estes dados pendendes, e que tanto inferniza a vida
dos desenvolvedores C++.

7.4.10 Common Language Infrastructure (CLI)

A especificação CLI é um padrão internacional para criar ambientes de desenvolvimento e execução no
qual linguagens e bibliotecas trabalham juntas. Ela descreve como aplicações escritas em múltiplas
linguagens de alto nível podem ser executadas em diferentes ambientes operacionais sem necessidade
de se reescrever a aplicação, para levar em conta as características destes ambientes. Na plataforma
.Net, a implementação da CLI é exatamente a CLR.

7.4.11 Operating System (OS)

No último nível, temos o sistema operacional (SO), responsável pela comunicação direta com os
dispositivos (hardware) do computador. Para que uma aplicação .Net funcione em vários ambientes
operacionais diferentes, deve haver uma CLR específica para cada um deles. Desta forma, uma vez
escrita e compilada, uma aplicação pode ser transportada de uma ambiente para outro sem nenhum
tipo de modificação (pelo menos, teoricamente).

7.4.12 Outros detalhes da .Net

• Assembly: Toda aplicação .Net, após compilada, é armazenada fisicamente numa unidade de códigos
chamada assembly. Uma aplicação pode ser composta por um ou mais assemblies, os quais aparecem
101
 TI para concursos
no sistema operacional como arquivos executáveis com a extensão .exe ou como bibliotecas dinâmicas
com a extensão .dll.
• Metadados: São conjuntos de instruções geradas no processo de compilação de um programa .Net,
junto com o MSIL, e que contém informações específicas da aplicação, que incluem, entre outras:
o Descrição de tipos: classes, estruturas, tipos enumerados, etc, que são usados no sistema, seja um
executável ou dll;
o Descrição dos membros: propriedades, métodos, eventos, etc;
o Descrição de cada assembly: que é usado na aplicação e é necessário para sua execução;
o Versão: permite que aplicações homônimas, mas com versões diferentes, executem no mesmo
computador sem conflitos.
Com as informações contidadas nos metadados, podemos dizer que uma aplicação .Net é auto-
explicativa, dispensando a utilização do registro do Windows, usado pela maioria dos programas. Desta
forma, a não ser que você crie chaves específicas no registro para seu uso, a instalação de um
programa .Net se resume em copiar os assemblies da aplicação para a máquina que irá executá-lo.

7.5 Exercícios
(ICMS-SP 2009) Instruções: Para responder às cinco próximas questões, utilize um computador hipotético
que tem um registrador R (valor inicial: R=10) e 5 posições de memória de M1 até M5 (valores iniciais:
M1=030, M2=005, M3=020, M4=015 e M5=010), com capacidade de 3 dígitos cada posição para armazenar
valores inteiros de −999 e +999, e que reconhece os seguintes tipos de instruções (cada instrução tem um
endereço “n” sequencial e termina com um ponto-e-vírgula):
INI; (= inicia o programa).
FIM; (= termina o programa).
IMP; (= imprime o conteúdo de R).
LER nnn; (= carrega em R o número “nnn” digitado pelo teclado).
CAR Mx; (= carrega em R o conteúdo de Mx).
CAR n; (= carrega em R o número “n”).
MOV Mx; (= move para Mx o conteúdo de R).
SOM Mx; (= soma Mx com R, o resultado fica em R).
SOM n; (= soma “n” com R, o resultado fica em R).
SUB Mx; (= subtrai Mx de R, o resultado fica em R).
SUB n; (= subtrai “n” de R, o resultado fica em R).
MUL Mx; (= multiplica Mx por R, o resultado fica em R).
DIV Mx; (= divide Mx por R, o resultado fica em R).
IRP n; (= ir para a instrução de endereço “n”).
SE condição instruções1 SENAO instruções2; (= se “condição” =VERDADEIRA executa “instruções1”, se
=FALSA executa “instruções2”).
126. (ICMS-SP 2009) Dado o programa:
1.INI; 2.LER 050; 3.SOM M3; 4.MOV M1; 5.SUB M5; 6.FIM;
126
Ao término da execução, os conteúdos de M1, M3 e M5 são, respectivamente,
xx
(a) 070, 020 e 010.
(b) 070, 070 e 060.
(c) 030, 020 e 010.
(d) 050, 020 e 010.
(e) 050, 070 e 060.
127. (ICMS-SP 2009) Dado o programa:
1.INI; 2.CAR M2; 3.CAR M4; 4.MOV M4; 5.MOV M2; 6.FIM;
127
Ao término da execução, os conteúdos de R, M2 e M4 são, respectivamente,
(a) 015, 005 e 015
(b) 015, 015 e 005
xx
(c) 015, 015 e 015
(d) 010, 015 e 005
(e) 010, 005 e 015
128. (ICMS-SP 2009) Dado o programa:
1.INI; 2.MOV M1; 3.SE M1=015 IRP 4 SENAO SOM 1 IRP 5; 4.SOM M1; 5.IMP; 6.FIM;
128
Ao término da execução, o conteúdo impresso será igual a
(a) 10
xx
(b) 11
(c) 15
(d) 25
(e) 30

102
 TI para concursos
129. (ICMS-SP 2009) A lógica principal do programa apresentado na questão anterior representa uma estrutura de
129
controle denominada estrutura
(a) sequence.
(b) de repetição do-until.
(c) de repetição do-while.
xx
(d) de seleção if-then-else.
(e) de seleção case.
130. (ICMS-SP 2009) Dado o programa:
1.INI; 2.CAR M1; 3.CAR M2; 4.CAR M3; 5.CAR M4; 6.CAR M5; 7.SUB M5; 8.FIM;
130
O programa que obtém o mesmo resultado final é:
(a) 1.INI; 2.SUB M5; 3.CAR M1; 4.CAR M2; 5.CAR M3; 6.CAR M4; 7.CAR M5; 8.FIM;
(b) 1.INI; 2.CAR M5; 3.CAR M4; 4.CAR M3; 5.CAR M2; 6.CAR M1; 7.SUB M5; 8.FIM;
(c) 1.INI; 2.SUB M5; 3.CAR M5; 4.CAR M4; 5.CAR M3; 6.CAR M2; 7.CAR M1; 8.FIM;
(d) 1.INI; 2.SUB M5; 3.CAR M5; 4.FIM;
xx
(e) 1.INI; 2.CAR M5; 3.SUB M5; 4.FIM;
131. (ICMS-SP 2009) Os valores das propriedades de um objeto em um determinado instante, que podem mudar
131
ao longo do tempo, representam
(a) a instância de uma classe.
(b) a identidade de um objeto.
xx
(c) o estado de um objeto.
(d) o comportamento de um objeto.
(e) as operações de uma classe.
132
132. (ICMS-SP 2009) Na orientação a objetos, ao nível de classe, são definidos os
(a) atributos e os valores dos atributos.
(b) atributos e a invocação das operações.
xx
(c) atributos e os métodos.
(d) métodos e os valores dos atributos.
(e) métodos e a invocação das operações.
133. (ICMS-SP 2009) Uma classe é uma abstração que ajuda a lidar com a complexidade e um bom exemplo de
133
abstração é
(a) um aluno e as disciplinas que está cursando.
(b) um professor e os cursos nos quais ministra aulas.
(c) um funcionário e o departamento em que trabalha.
xx
(d) uma pessoa e o número do seu CPF na Receita Federal.
(e) uma casa e a empresa que a projetou e construiu.
134. (ICMS-SP 2009) O método utilizado para inicializar objetos de uma classe quando estes são criados é
134
denominado
(a) void.
(b) interface.
(c) agregação.
(d) composição.
xx
(e) construtor.
135. (ICMS-SP 2009) Sobre a visibilidade dos métodos na orientação a objetos considere:
I. Os métodos públicos de uma classe definem a interface da classe.
II. Os métodos privativos de uma classe não fazem parte da interface da classe.
III. O nome dos métodos é a informação reconhecida como a assinatura dos métodos.
135
Está correto o que consta APENAS em
xx
(a) I e II.
(b) I e III.
(c) II e III.
(d) II.
(e) I.
136. (ICMS-SP 2009) A .NET Framework trata-se de uma arquitetura da estratégia Microsoft .NET
I. constituída das partes Common Language Runtime, bibliotecas de classes, ASP.NET e ADO.NET.
II. para construir, implementar e executar aplicações e webservices.
III. desenvolvida como um componente integral do Windows.
136
Está correto o que consta em
(a) I, apenas.
(b) II, apenas.
(c) I e II, apenas.
xx
(d) II e III, apenas.
(e) I, II e III.

103
 TI para concursos
137. (ICMS-SP 2009) NÃO é uma linguagem de programação do pacote Visual Studio 2005 que utiliza o mesmo
137
IDE e as funcionalidades da .NET Framework:
(a) Visual Basic.
xx
(b) Visual FoxPro.
(c) Visual C++.
(d) Visual C#.
(e) Visual J#.
138. (ICMS-SP 2009) A .NET Framework 3.0 é o modelo de programação de código gerenciado da Microsoft, que
138
integra os componentes da .NET Framework 2.0 às novas tecnologias
(a) WPF (Windows Presentation Foundation) e WCF (Windows Communication Foundation), apenas.
(b) WF (Windows Workflow Foundation) e Windows CardSpace, apenas.
(c) WPF, WCF e WF, apenas.
(d) WPF, WCF e Windows CardSpace, apenas.
xx
(e) WPF, WCF, WF e Windows CardSpace.
139. (ICMS-SP 2009) O IDE do Visual Studio 2005 fornece suporte completo para publicação de aplicativos e para
atualização de aplicativos implantados por meio diretamente do ClikOnce apenas para projetos criados
139
com
xx
(a) Visual Basic, Visual C# e Visual J#.
(b) Visual Basic, Visual FoxPro e Visual C++.
(c) Visual Basic e Visual FoxPro.
(d) Visual C# e Visual J#.
(e) Visual C# e Visual C++.
140. (ICMS-SP 2009) A opção de escolha no Visual Studio 2005 para usar Web Forms como interface de usuário
140
no desenvolvimento de um aplicativo indica que o aplicativo deverá ser implantado no
(a) servidor e que o .NET Framework deverá ser executado tanto no servidor quanto no computador cliente.
(b) servidor, que o .NET Framework deverá ser executado no servidor e que o computador cliente exigirá
xx
apenas um navegador.
(c) servidor e que o .NET Framework deverá ser executado apenas no computador cliente e não no
servidor.
(d) computador cliente e que o .NET Framework deverá ser executado apenas no computador cliente e não
no servidor.
(e) computador cliente e que o .NET Framework deverá ser executado tanto no servidor quanto no
computador cliente.
141. Uma ou mais instruções são executadas ou não, dependendo do resultado do teste efetuado. Esta afirmação
141
define uma estrutura de controle de programação do tipo
(a) pilha.
(b) seleção.xx
(c) fila.
(d) repetição.
(e) seqüência.
142. A estrutura de dados de iteração na qual uma ação será executada pelo menos uma vez, antes da avaliação
142
da condição, é implementada pelo comando básico
(a) condicional.
(b) faça enquanto.
(c) seqüencial.
xx
(d) de repetição.
(e) de seleção.
143. Em uma hierarquia de classes é possível especificar operações com a mesma assinatura em pontos
143
diferentes da hierarquia. Portanto, essas operações presentes nas classes-filha
(a) anulam o comportamento das operações existentes nas classes-mãe.xx
(b) herdam os atributos existentes nas classes-mãe.
(c) são composições de alguns atributos existentes nas classes-mãe.
(d) complementam o comportamento das operações existentes nas classes-mãe.
(e) agregam as operações existentes nas classes-mãe.
144
144. As instâncias de uma classe são
(a) seus atributos.
(b) suas superclasses.
(c) suas operações.
(d) seus objetos.xx
(e) seus relacionamentos.
145. A nomenclatura da linguagem C++ para Chamada de Função e Classe Base corresponde, respectivamente,
145
na programação orientada a objetos a
(a) Método e Subclasse.
(b) Método e Superclasse.
(c) Hereditariedade e Subclasse.
(d) Mensagem e Subclasse.
xx
(e) Mensagem e Superclasse.
104
 TI para concursos
146. Em um diagrama entidade relacionamento, uma situação de composição tal qual "empregado gerencia
146
empregado", geralmente é apresentada como
(a) entidade fraca.
(b) relacionamento associativo.
(c) auto relacionamento.xx
(d) relacionamento interativo.
(e) relacionamento restritivo.
147
147. A execução de uma expressão lógica obedece como prioridade a ordem dos operadores
(a) Or, And e Not.
(b) Not, And e Or.xx
(c) And, Not e Or.
(d) And, Or e Not.
(e) Not, Or e And.
148
148. Respeitando as ordens de inserção e de retirada dos dados, uma estrutura de
(a) fila é também denominada LIFO ou LILO.
(b) fila é também denominada FIFO ou FILO.
(c) fila é também denominada FIFO ou LIFO.
(d) pilha é também denominada FIFO ou FILO.
xx
(e) pilha é também denominada LIFO ou FILO.
149. Uma fila dupla que se trata de uma lista linear na qual os elementos podem ser inseridos ou removidos de
149
qualquer extremo denomina-se
(a) hashing.
(b) grafo.
xx
(c) deque.
(d) lista aberta.
(e) lista fechada.
150. Sobre a sintaxe XML, considere:
I. Um elemento <CALCULA> deve ter sempre uma tag de fechamento <FIMCALCULA>.
II. Uma tag <Lista> é diferente da tag <lista>.
III. Um elemento <A> aberto no interior do elemento <B> pode ser fechado fora do elemento <B>.
150
Está correto o que consta APENAS em
(a) III.
(b) II.xx
(c) II e III.
(d) I e III.
(e) I e II.
151
151. Em XML pode-se definir um atributo, como informação adicional ao elemento, conforme o exemplo abaixo:
(a) <funcionario> <sexo> masculino ...
(b) <funcionario sexo=masculino> ...
(c) <funcionario sexo="masculino">xx...
(d) <funcionario> <sexo> "masculino" ...
(e) <funcionario <sexo>= "masculino"> ...
152
152. NÃO é um tipo de dados considerado primitivo:
(a) real.
(b) inteiro.
(c) lógico.
(d) caracter.
xx
(e) matriz.

105
 TI para concursos

8 Segurança da informação
8.1 Conceitos básicos
Segurança da Informação é a proteção de um conjunto de dados, no sentido de preservar o valor que
possuem para um indivíduo ou uma organização.
O conceito de Segurança Informática ou Segurança de Computadores inclue a segurança dos
dados/informação e a dos sistemas em si.48
Entende-se por informação todo e qualquer conteúdo ou dado que tenha valor para alguma
organização ou pessoa. Ela pode estar guardada para uso restrito ou exposta ao público para consulta
ou aquisição.
Podem ser estabelecidas métricas para a definição do nível de segurança existente e, com isto, serem
estabelecidas as bases para análise da situação. A segurança de uma determinada informação pode
ser afetada por fatores comportamentais e de uso de quem se utiliza dela, pelo ambiente ou infra-
estrutura.
Os atributos básicos da segurança:
 Confidencialidade - propriedade que limita o acesso a informação às entidades legítimas, ou seja,
àquelas autorizadas pelo proprietário da informação.
 Integridade - propriedade que garante que a informação mantenha todas as características originais
estabelecidas pelo proprietário da informação, incluindo controle de mudanças e garantia do seu
ciclo de vida (nascimento, manutenção e destruição).
 Disponibilidade - propriedade que garante que a informação esteja sempre disponível para o uso
legítimo, ou seja, por aqueles usuários autorizados pelo proprietário da informação.
O nível de segurança desejado, pode se consubstanciar em uma "política de segurança" que é seguida
pela organização ou pessoa, para garantir que uma vez estabelecidos os princípios, aquele nível
desejado seja perseguido e mantido. Para a montagem desta política, deve-se levar em conta:
 Riscos associados à falta de segurança;
 Benefícios;
 Custos de implementação dos mecanismos.
O suporte para as recomendações de segurança pode ser encontrado em:
 Controles físicos: são barreiras que limitam o contato ou acesso direto a informação ou a infra-
estrutura que a suporta, como portas, trancas, paredes, blindagem, guardas etc.
 Controles lógicos: são barreiras que impedem ou limitam o acesso a informação, que está em
ambiente controlado, geralmente eletrônico.
 Mecanismos de criptografia. Permitem a transformação reversível da informação de forma a torná-la
ininteligível a terceiros. Utiliza-se para tal, algoritmos determinados e uma chave secreta para, a partir de
um conjunto de dados não criptografados, produzir uma sequência de dados criptografados. A operação
inversa é a decifração. Os algoritmos com chave dupla, ou chaves assimétricas, podem usar uma chave
pública para criptografar e uma chave diferente, privada, secreta, para decifrar.
 Assinatura digital. Um conjunto de dados criptografados, associados a um documento do qual são função,
garantindo a integridade do documento associado, mas não a sua confidencialidade.
 Mecanismos de garantia da integridade da informação. Usando funções de "Hashing" ou de checagem,
consistindo na adição.
 Mecanismos de controle de acesso. Palavras-chave, sistemas biométricos, firewalls, cartões inteligentes.
 Mecanismos de certificação. Atesta a validade de um documento.
 Integridade. Medida em que um serviço/informação é genuíno, isto é, está protegido contra a personificação
por intrusos.
 Honeypot: É o nome dado a um software, cuja função é detectar ou de impedir a ação de um cracker, de
um spammer, ou de qualquer agente externo estranho ao sistema, enganando-o, fazendo-o pensar que
esteja de fato explorando uma vulnerabilidade daquele sistema.
 Protocolos seguros: uso de protocolos que garantem um grau de segurança.
Existe hoje em dia um elevado número de ferramentas e sistemas que pretendem fornecer segurança.
Alguns exemplos são os detectores de intrusões, os anti-vírus, firewalls, firewalls locais, filtros anti-
spam, fuzzers, analisadores de código, etc.

48 http://pt.wikipedia.org/wiki/Seguran%C3%A7a_da_informa%C3%A7%C3%A3o
106
 TI para concursos
As ameaças à segurança da informação são relacionadas diretamente à perda de uma de suas três
características principais, quais sejam:
 Perda de Confidencialidade: quebra de sigilo de uma determinada informação (ex: a senha de um
usuário ou administrador de sistema) permitindo com que sejam expostas informações restritas as
quais seriam acessíveis apenas por um determinado grupo de usuários.
 Perda de Integridade: determinada informação fica exposta a manuseio por uma pessoa não
autorizada, que efetua alterações que não foram aprovadas e não estão sob o controle do
proprietário (corporativo ou privado) da informação.
 Perda de Disponibilidade: a informação deixa de estar acessível por quem necessita dela.
No caso de ameaças à rede de computadores ou a um sistema, estas podem vir de agentes
maliciosos, muitas vezes conhecidos como crackers (hackers não são agentes maliciosos, pois tentam
ajudar a encontrar possiveis falhas). Estas pessoas são motivadas para fazer esta ilegalidade por
vários motivos. Os principais são: notoriedade, auto-estima, vingança e o dinheiro. De acordo com
pesquisa elaborada pelo Computer Security Institute, mais de 70% dos ataques partem de usuários
legítimos de sistemas de informação (Insiders) -- o que motiva corporações a investir largamente em
controles de segurança para seus ambientes corporativos (intranet).
Depois de identificado o potencial de ataque, as organizações têm que decidir o nível de segurança a
estabelecer para uma rede ou sistema os recursos físicos e lógicos a necessitar de proteção. No nível
de segurança devem ser quantificados os custos associados aos ataques e os associados à
implementação de mecanismos de proteção para minimizar a probabilidade de ocorrência de um
ataque.
 Segurança física - Considera as ameaças físicas como incêndios, desabamentos, relâmpagos,
alagamento, acesso indevido de pessoas, forma inadequada de tratamento e manuseamento do
material.
 Segurança lógica - Atenta contra ameaças ocasionadas por vírus, acessos remotos à rede, backup
desatualizados, violação de senhas etc.
De acordo com o RFC 2196 (The Site Security Handbook), uma política de segurança consiste num
conjunto formal de regras que devem ser seguidas pelos utilizadores dos recursos de uma organização.
As políticas de segurança devem ter implementação realista, e definir claramente as áreas de
responsabilidade dos utilizadores, do pessoal de gestão de sistemas e redes e da direção. Deve
também adaptar-se a alterações na organização. As políticas de segurança fornecem um
enquadramento para a implementação de mecanismos de segurança, definem procedimentos de
segurança adequados, processos de auditoria à segurança e estabelecem uma base para
procedimentos legais na sequência de ataques.
O documento que define a política de segurança deve deixar de fora todos os aspectos técnicos de
implementação dos mecanismos de segurança, pois essa implementação pode variar ao longo do
tempo. Deve ser também um documento de fácil leitura e compreensão, além de resumido.
Algumas normas definem aspectos que devem ser levados em consideração ao elaborar políticas de
segurança. Entre essas normas estão a BS 7799 (elaborada pela British Standards Institution) e a NBR
ISO/IEC 17799 (a versão brasileira desta primeira). A ISO começou a publicar a série de normas
27000, em substituição à ISO 17799 (e por conseguinte à BS 7799), das quais a primeira, ISO 27001,
foi publicada em 2005.
Existem duas filosofias por trás de qualquer política de segurança: a proibitiva (tudo que não é
expressamente permitido é proibido) e a permissiva (tudo que não é proibido é permitido).
Os elementos da política de segurança devem ser considerados:
 Disponibilidade: o sistema deve estar disponível de forma que quando o usuário necessitar possa
usar. Dados críticos devem estar disponíveis ininterruptamente.
 Utilização: o sistema deve ser utilizado apenas para os determinados objetivos.
 Integridade: o sistema deve estar sempre íntegro e em condições de ser usado.
 Autenticidade: o sistema deve ter condições de verificar a identidade dos usuários, e este ter
condições de analisar a identidade do sistema.
 Confidencialidade: dados privados devem ser apresentados somente aos donos dos dados ou ao
grupo por ele liberado.

107
 TI para concursos

8.2 Plano de Continuidade de Negócio

Business Continuity Plan (BCP) é o desenvolvimento preventivo de um conjunto de estratégias e planos
de ação de maneira a garantir que os serviços essenciais sejam devidamente identificados e
preservados após a ocorrência de um desastre e até o retorno à situação normal de funcionamento da
empresa dentro do contexto do negócio do qual ela faz parte. Além disso, sob o ponto de vista do PCN,
o funcionamento de uma empresa deve-se a duas variáveis: os componentes e os processos.49
Os componentes são todas as variáveis utilizadas para realização dos processos: energia, pessoas,
telecomunicações, informática, infra-estrutura. Todas elas podem ser substituídas ou restauradas, de
acordo com suas características.
Já os processos são as atividades realizadas para operar os negócios da empresa.
O Plano de Continuidade de Negócios é constituído pelos seguintes planos:
 Plano de Administração de Crises (PAC)
 Plano de Recuperação de Desastres (PRD)
 Plano de Continuidade Operacional (PCO)
Todos estes planos têm como objetivo principal a formalização de ações a serem tomadas para que,
em momentos de crise, a recuperação, a continuidade e a retomada possam ser efetivas, evitando que
os processos críticos de negócio da organização sejam afetados, o que pode acarretar em perdas
financeiras.
No que diz respeito à necessidade de atualizações, o Plano de Continuidade de Negócios deve ser
revisado periodicamente, pois mudanças significativas em componentes, atividades ou processos
críticos de negócio podem fazer com que novas estratégias e planos de ação sejam previstos, evitando
assim com que eventuais desastres desestabilizem profundamente o andamento regular do negócio da
empresa.
Desastre pode ser entendido como qualquer situação que afete os processos críticos do negócio de
uma organização. Conseqüentemente, algumas ocorrências podem ser caracterizadas como sendo
desastres para uma determinada empresa, mas podem não ser caracterizadas como um desastre para
outra empresa.
As principais etapas de um plano de continuidade são:
 Analise de riscos - Analisa-se o grau de exposição a que o negócio pode estar exposto. Sejam
exposições de ação natural (vendaval, inundação, fogo) ou aquelas da ação do homem (sabotagem,
erro ou falha humana).
 Analise dos impactos no negócio - análise dos impactos da perda no negócio da organização. Neste
estudo devem-se identificar as aplicações mais criticas para o negócio e seu tempo de recuperação
necessário para a continuidade.
 Estratégia de recuperação - planejamento do maior número de possibilidades e formas de
recuperação, que seja rápida, eficiente e com baixo custo.

8.3 Vulnerabilidade
A vulnerabilidade na computação significa ter brecha em um sistema computacional, também
conhecida como bug. Esta mesma pode ser explorada em um determinado sistema ou serviço
vulnerável que esteja rodando na máquina.
As vulnerabilidades mais exploradas nos dias de hoje, são as do tipo buffer overflow, que muitas vezes
pode dar privilégios de administrador para o invasor, rodar códigos maliciosos remotamente, burlar
particularidades de cada sistema, ataques de Negação de Serviços (DDoS), e acesso irestrito ao
sistema.
Existem ferramentas específicas para se explorar as vulnerabilidades, cada ferramenta para a sua
respectiva vulnerabilidade a ser explorada (na maioria das vezes escritas em linguagem C e Assembly),
essas ferramentas são chamadas de exploits.
Um exploit, em segurança da informação, é um programa de computador, uma porção de dados ou
uma sequência de comandos que se aproveita das vulnerabilidades de um sistema computacional –
como o próprio sistema operacional ou serviços de interação de protocolos (ex: servidores Web). São
geralmente elaborados por hackers como programas de demonstração das vulnerabilidades, a fim de
que as falhas sejam corrigidas, ou por crackers a fim de ganhar acesso não autorizado a sistemas. Por

49 http://pt.wikipedia.org/wiki/Plano_de_continuidade_de_neg%C3%B3cios
108
 TI para concursos
isso muitos crackers não publicam seus exploits, conhecidos como 0days, e o seu uso massificado
deve-se aos script kiddies.
Até meados dos anos 90, acreditava-se que os exploits exploravam exclusivamente problemas em
aplicações e serviços para plataformas Unix. A partir do final da década, especialistas demonstraram a
capacidade de explorar vulnerabilidades em plataformas de uso massivo, por exemplo, sistemas
operacionais Win32 (Windows 9x, NT, 2000 e XP). Como exemplo temos o CodeRed, o MyDoom, o
Sasser em 2004 e o Zotob em 2005.
Para um exploit atacar, o sistema precisa ter uma vulnerabilidade, ou seja, um meio de comunicação
com a rede que possa ser usado para entrar, uma porta ou uma consola.
Um exploit muito usado é no sistema RPC do Windows:
 o usuário localiza a porta e envia à porta RPC uma sequência de bytes, que são interpretados como dados
pelo servidor
 quando são recebidos, estes dados deixam propositadamente o sistema em pane
 o sistema passa o controle a estes próprios dados que então são uma sequência de ordem para dominar a
CPU.
Desta forma esta sequência de informações toma conta do PC e abre-o para o hacker que aguarda na
outra ponta.
Ameaças à segurança das redes que fazem com que os micros infectados por esses tipos de vírus
formem redes de computadores "zumbis" que são comandados simultaneamente por seus invasores
para enviar mensagens indesejadas (spam), colocar sites fora do ar e promover fraudes são
categorizadas como botnet (robôs).
Keylogger é um programa capaz de capturar e armazenar as teclas digitadas pelo usuário no teclado
de um computador.
No sistema Linux, quando existem vulnerabilidades, sempre são publicadas, como já houve no sistema
Apache, Samba ou MySQL, que também apresentam vulnerabilidades e possibilita o controle do PC
por um hacker remoto. Com isso um hacker pode ter acesso a todos seus arquivos pessoais, Usando o
proprio CMD do windows.

8.4 Auditoria e conformidade

A Auditoria da TI é uma auditoria operacional, analisa a gestão de recursos, com o foco nos aspectos
de eficiência, eficácia, economia e efetividade. A abrangência desse tipo de auditoria pode ser o
ambiente de informática como um todo ou a organização do departamento de informática:50
 Ambiente de informática:
 Segurança dos outros controles;
 Segurança física;
 Segurança lógica;
 Planejamento de contingências;
 Operação do centro de processamento de dados.
 Organização do departamento de informática:
 Aspectos administrativos da organização;
 Políticas, padrões, procedimentos, responsabilidades organizacionais, gerência pessoal e planejamento de
capacidade;
 Banco de dados;
 Redes de comunicação e computadores;
 Controle sobre aplicativos:
 Desenvolvimento,
 Entradas, processamento e saídas.
Auditoria da tecnologia da informação é abrangente, engloba todos os controles que podem influenciar
a segurança de informação e o correto funcionamento dos sistemas de toda a organização:
 Controles organizacionais;
 De mudança;
 De operação de sistemas;
 Sobre Banco de Dados;

50 http://pucrs.campus2.br/~annes/sas_audit.doc
109
 TI para concursos
 Sobre microcomputadores;
 Sobre ambiente cliente-servidor.
Auditoria da segurança de informações determina a postura da organização com relação à segurança.
Avalia a política de segurança e controles relacionados com aspectos de segurança institucional mais
globais, faz parte da auditoria da TI. Seu escopo envolve:
 Avaliação da política de segurança;
 Controles de acesso lógico;
 Controles de acesso físicos;
 Controles ambientais;
 Planos de contingência e continuidade de serviços.
Auditoria de aplicativos verifica a segurança e o controle de aplicativos específicos, incluindo aspectos
intrínsecos à área a que o aplicativo atende:
 Controles sobre o desenvolvimento de sistemas aplicativos;
 Controles de entradas, processamento e saída de dados;
 Controle sobre conteúdo e funcionamento do aplicativo, com relação à área por ele atendida.
A natureza especializada da auditoria de sistemas de informação (SI) e a capacidade necessária para
realizar essas auditorias requerem o estabelecimento de normas que se apliquem especificamente à
auditoria de SI. 51
A Associação de Auditoria e Controle de Sistemas de Informação, ISACA, desenvolve normas
aplicáveis globalmente, de forma a suportar essa visão. A estrutura das Normas de Auditoria de SI
apresenta diversos níveis de orientação:
 Normas: definem requisitos obrigatórios para auditorias e relatórios de SI. Informam:
 Os auditores de SI sobre o nível mínimo de desempenho aceitável exigido para cumprir as
responsabilidades profissionais estabelecidas no Código de Ética Profissional
 A gestão e outras partes interessadas sobre as expectativas da profissão no que se refere às atividades
daqueles que a exercem
 Diretrizes: fornecem orientação para a aplicação das normas de auditoria de SI. O auditor de SI
deve levá-las em consideração para determinar como alcançar a implementação das normas,
utilizar a avaliação profissional na sua aplicação e estar preparado para justificar qualquer
divergência. O objetivo das Directrizes de Auditoria de SI é fornecer informações adicionais sobre
como cumprir as Normas de Auditoria de SI.
 Procedimentos: fornecem exemplos de procedimentos que um auditor de SI pode seguir durante a
realização de uma auditoria. Os documentos de procedimentos fornecem informações sobre como
cumprir as normas ao realizar a auditoria de SI, mas não estabelecem requisitos. O objetivo dos
Procedimentos de Auditoria de SI é fornecer informações adicionais sobre como cumprir as Normas
de Auditoria de SI.
As normas da ISACA contêm princípios básicos e procedimentos essenciais que são obrigatórios,
juntamente com orientações relacionadas com os mesmos, com o objetivo de estabelecer e fornecer
orientações sobre áreas de governança de TI que o auditor de SI deve considerar durante o processo
de auditoria.
 O auditor de SI deve analisar e avaliar:
 ambiente de controle da organização.
 conformidade com a organização: missão, visão, valores, qualidade de informações, objetivos e
estratégias.
 conformidade com as leis: ambientais, trabalhistas, fiduciárias e de segurança.
 eficiência e eficácia de SI, as suas realizações e os processos de gestão de desempenho.
 riscos que podem causar efeitos adversos no ambiente de SI.
 Diretrizes de auditoria de SI:
 Carta de auditoria
 Conceitos de materialidade para auditoria de sistemas de informações
 Relacionamento e independência organizacionais
 Uso da avaliação de riscos no planeamento de auditoria
 Planeamento - lista detalhada das tarefas
 Impacto de terceiros em controles de TI de uma organização

51 http://www.isaca.org/Template.cfm?Section=Home&Template=/ContentManagement/ContentDisplay.cfm&ContentFileID=10775
110
 TI para concursos
 Impacto de função de não auditoria na independência do auditor de SI

8.5 Conhecimento sobre norma ISO 27001

ISO/IEC 27001 é um padrão para sistema de gerência da segurança da informação (ISMS - Information
Security Management System) publicado em outubro de 2005 pelo International Organization for
Standardization e pelo International Electrotechnical Commision. Seu nome completo é ISO/IEC
27001:2005 - Tecnologia da informação - técnicas de segurança - sistemas de gerência da segurança
da informação - requisitos mas conhecido como "ISO 27001".52
Seu objetivo é ser usado em conjunto com ISO/IEC 17799, o código de práticas para gerência da
segurança da informação, o qual lista objetivos do controle de segurança e recomenda um conjunto de
especificações de controles de segurança. Organizações que implementam um ISMS de acordo com
as melhores práticas da ISO 17799 estão simultaneamente em acordo com os requisitos da ISO 27001,
mas uma certificação é totalmente opcional.
Este padrão é o primeiro da família de segurança da informação relacionado aos padrões ISO que
espera-se sejam agrupados à série 27000. Outros foram incluídos antecipadamente:
 ISO 27000 - Vocabulário de Gestão da Segurança da Informação (sem data de publicação);
 ISO 27001 - Esta norma foi publicada em Outubro de 2005 e substituiu a norma BS 7799-2 para
certificação de sistema de gestão de segurança da informação;
 ISO 27002 - Esta norma irá substituir em 2006/2007 o ISO 17799:2005 (Código de Boas Práticas);
 ISO 27003 - Esta norma abordará a gestão de risco, contendo recomendações para a definição e
implementação de um sistema de gestão de segurança da informação. Deverá ser publicada em
2006;
 ISO 27004 - Esta norma incidirá sobre os mecanismos de mediação e de relatório de um sistema de
gestão de segurança da informação. A sua publicação deverá ocorrer em 2007;
 ISO 27005 - Esta norma será constituída por indicações para implementação, monitoramento e
melhoria contínua do sistema de controles. O seu conteúdo deverá ser idêntico ao da norma BS
7799-3:2005 – “Information Security Management Systems - Guidelines for Information Security Risk
Management”, a publicar em finais de 2005. A publicação da norma ISO 27005 ocorreu em meados
de 2008;
 ISO 27006 - Esta norma será referente à recuperação e continuidade de negócio. Este documento
tem o título provisório de “Guidelines for information and communications technology disaster
recovery services”, não estando calendarizado a sua edição.
ISO 27001 foi baseado e substitui o BS 7799 parte 2, o qual não é mais válido.
A série ISO 27000 está de acordo com outros padrões de sistemas de gerência ISO, como ISO 9001
(sistemas de gerência da qualidade) e ISO 14001 (sistemas de gerência ambiental), ambos em acordo
com suas estruturas gerais e de natureza a combinar as melhores práticas com padrões de
certificação.
Certificações de organização com ISMS ISO/IEC 27001 é um meio de garantir que a organização
certificada implementou um sistema para gerência da segurança da informação de acordo com os
padrões. Credibilidade é a chave de ser certificado por uma terceira parte que é respeitada,
independente e competente. Esta garantia dá confiança à gerência, parceiros de negócios, clientes e
auditores que uma organização é séria sobre gerência de segurança da informação - não perfeita,
necessariamente, mas está rigorosamente no caminho certo de melhora contínua.

8.6 Exercícios
153. (ICMS-SP 2009) Segundo as normas ABNT sobre segurança da informação, o tratamento de risco está
153
inserido no processo de
xx
(a) gestão de riscos.
(b) aceitação do risco.
(c) análise de riscos.
(d) avaliação de riscos.
(e) análise/avaliação de riscos.

52 http://pt.wikipedia.org/wiki/ISO_27001
111
 TI para concursos
154. (ICMS-SP 2009) As ações a serem tomadas imediatamente após a ocorrência de um incidente que coloque
em risco as operações do negócio devem estar descritas no plano de continuidade de negócios como
154
procedimentos
(a) operacionais temporários.
(b) de ensaio geral.
(c) de recuperação.
(d) de restauração.
xx
(e) de emergência.
155. (ICMS-SP 2009) Se qualquer não-conformidade for encontrada como um resultado da análise crítica nas
áreas sobre o cumprimento das políticas e normas de segurança da informação, NÃO convém que os
155
gestores
(a) determinem as causas da não-conformidade.
(b) determinem e implementem ação corretiva apropriada.
(c) analisem criticamente a ação corretiva tomada.
xx
(d) avaliem a necessidade de ações para assegurar que a conformidade não se repita.
(e) registrem os resultados das análises e das ações corretivas e que esses registros sejam mantidos.
156. (ICMS-SP 2009) No modelo PDCA adotado para estruturar todos os processos do SGSI – Sistema de
Gestão de Segurança da Informação, os resultados das atividades da auditoria interna do SGSI estão
156
vinculados ao ciclo PDCA como entrada dos processos na etapa
(a) Plan (Planejar): estabelecer o SGSI.
(b) Do (Fazer): implementar e operar o SGSI.
(c) Check (Verificar): monitorar o SGSI.
(d) Control (Controlar): analisar criticamente o SGSI.
xx
(e) Act (Agir): manter e melhorar o SGSI.
157. No Brasil, a NBR ISO17799 constitui um padrão de recomendações para práticas na gestão de Segurança da
Informação. De acordo com o estabelecido nesse padrão, três termos assumem papel de importância capital:
confidencialidade, integridade e disponibilidade.
157
Nesse contexto, a confidencialidade tem por objetivo:
(a) salvaguardar a exatidão e a inteireza das informações e métodos de processamento.
(b) salvaguardar os dados gravados no backup por meio de software que utilize assinatura digital.
(c) permitir que os usuários tenham acesso aos arquivos de backup e aos métodos de criptografia
empregados.
(d) permitir que os usuários autorizados tenham acesso às informações e aos ativos associados, quando
necessário.
(e) garantir que as informações sejam acessíveis apenas para aqueles que estejam autorizados a acessá-
xx
las.
158. Para garantir a segurança da informação em uma rede de computadores, um sistema de autenticação típico
158
é composto apenas do código do usuário, uma senha e um
(a) processo de certificação.
(b) método de criptografia.
(c) sistema de detecção de intrusão.
(d) plano de recuperação.
xx
(e) firewall.
159
159. NÃO é um algoritmo de chave simétrica o sistema de criptografia de chave
(a) única.
(b) pública.xx
(c) secreta.
(d) simétrica.
(e) compartilhada.
160. Um conjunto de dados de computador, em observância à Recomendação Internacional ITUT X.509, que se
destina a registrar, de forma única, exclusiva e intransferível, a relação existente entre uma chave de
160
criptografia e uma pessoa física, jurídica, máquina ou aplicação é
(a) uma autoridade certificadora.
(b) uma trilha de auditoria.
(c) uma chave assimétrica.
(d) uma assinatura digital.
xx
(e) um certificado digital.

112
 TI para concursos
161. Considere a seguinte definição: "Evitar violação de qualquer lei criminal ou civil, estatutos, regulamentação
ou obrigações contratuais; evitar a violação de direitos autorais dos software - manter mecanismos de
controle dos softwares legalmente adquiridos". De acordo com as especificações das normas brasileiras de
161
segurança da informação, esta definição se inclui corretamente em
(a) Gestão de Incidentes e Segurança da Informação.
xx
(b) Conformidade.
(c) Controle de Acesso.
(d) Gestão da Continuidade do Negócio.
(e) Gestão de Ativos.
162
162. É um elemento biométrico de identificação
xx
(a) a impressão digital.
(b) o cartão bancário.
(c) a senha da internet.
(d) o certificado digital.
(e) a assinatura eletrônica.
163. Ameaças à segurança das redes que fazem com que os micros infectados por esses tipos de vírus formem
redes de computadores "zumbis" que são comandados simultaneamente por seus invasores para enviar
163
mensagens indesejadas (spam), colocar sites fora do ar e promover fraudes são categorizadas como.
(a) Advance Fee Fraud.
(b) Botnet.xx
(c) Hoax.
(d) Phishing.
(e) Rootkit.
164. Programa capaz de capturar e armazenar as teclas digitadas pelo usuário no teclado de um computador é o
164

(a) Worm.
(b) Spyware.
(c) Backdoor.
(d) Keylogger.xx
(e) Cavalo de Tróia.
165. Por meio da análise dos procedimentos para estabelecer e finalizar uma conexão utilizada para troca de
informações entre dois hosts, obtém-se informações que permitem uma prospecção sobre os serviços por
165
eles oferecidos. Essa técnica, utilizada para descobrir um possível ataque do tipo DoS, é denominada
(a) network security.
(b) file scan.
(c) packet sniffer.
(d) network scan.xx
(e) scan vírus.
166
166. A integridade de software é medida
(a) em defeitos por KLOC (milhares de linhas de código).
(b) por sua usabilidade.
(c) pelo mean-time-to-change - MTTC.
(d) por sua conectividade.
xx
(e) pela capacidade do sistema resistir a ataques à sua segurança.
167
167. Em relação aos conceitos de segurança, é correto afirmar:
(a) Confidencialidade é a propriedade que se refere ao fato de determinada informação não poder ser
alterada ou destruída de maneira não autorizada.
(b) Medidas físicas e organizacionais de proteção relacionam-se não apenas à proteção de hardware, mas
xx
também a elementos lógicos de um sistema.
(c) Umidade e temperatura não podem ser consideradas ameaças a uma rede de SI.
(d) Negação de uso é um ataque que visa atingir a integridade de um sistema computacional.
(e) Um firewall de rede tornou-se, em dias atuais, um equipamento desnecessário, desde que todos os
computadores da rede sejam dotados de antivírus ativos e atualizados.
168. A Disponibilidade do sistema, a Integridade dos dados e a Confidencialidade dos dados são objetivos de
168
segurança dos sistemas, respectivamente, sujeitos às ameaças de
(a) Adulteração dos dados, Recusa de serviço e Exposição aos dados.
(b) Recusa de serviço, Exposição aos dados e Adulteração dos dados.
(c) Exposição aos dados, Recusa de serviço e Adulteração dos dados.
xx
(d) Recusa de serviço, Adulteração dos dados e Exposição aos dados.
(e) Exposição aos dados, Adulteração dos dados e Recusa de serviço.
169. Na disciplina de segurança de redes e criptografia, a propriedade que traduz a confiança em que a
169
mensagem não tenha sido alterada desde o momento de criação é:
(a) autenticidade.
(b) criptologia.
(c) não-repúdio.
xx
(d) integridade.
(e) confidencialidade.
113
 TI para concursos
170. Os mecanismos de segurança para autenticação efetiva de um usuário devem ser baseados em:
I. Conhecimento individual.
II. Posse de alguma coisa.
III. Característica pessoal.
IV. Local em que se encontra.
170
É correto o que se afirma em
(a) I, II e III, apenas.
(b) I, II e IV, apenas.
(c) I, III e IV, apenas.
(d) II, III e IV, apenas.
xx
(e) I, II, III e IV.
171. Receber as solicitações de serviços, oriundas de clientes internos, e enviá-las para a rede externa como se
171
fosse o cliente de origem é uma função do
(a) criptógrafo.
(b) firewall.
xx
(c) proxy.
(d) soquete.
(e) broadcast.
172
172. Sobre segurança da informação, é correto afirmar que
(a) vulnerabilidades determinam controles de segurança.
(b) riscos são determinados pelas vulnerabilidades.
(c) controles de segurança eliminam os riscos.
xx
(d) ameaças exploram vulnerabilidades.
(e) vulnerabilidades provocam ameaças.
173. O controle de acesso lógico pode utilizar, para proteção aos arquivos de dados e de programas, uma senha
173
pessoal como recurso de
(a) permissão de acesso.
(b) direito de acesso.
(c) monitoração de acesso.
xx
(d) autenticação do usuário.
(e) identificação do usuário.

114
 TI para concursos

9 Sistemas Operacionais
9.1 Conceitos de administração de servidores em plataforma Windows
A administração de servidores Windows é feita sobre uma interface gráfica, com mouse, janelas e
botões. Nem por isto a tarefa se torna fácil. O usuário precisa saber em que ícones clicar e que
controles modificar.
Administrar servidores em plataforma Windows é instalar e manter em funcionamento os serviços que a
rede necessita. Este serviços são acessíveis a partir do Painel de Controle e do menu Ferramentas
administrativas.
O primeiro serviço que deve funcionar muito bem é administração de usuários, que consiste em criar
contas, que são identificadas por um nome de usuário (login) e atribuir direitos a eles. Para esta função,
utiliza-se o aplicativo “Contas de usuário”, no painel de controle. Usuários com direitos de
administradores, conforme a sua configuração, podem fazer tudo, enquanto que usuário comuns só
podem usar recursos definidos pelo administrador.
O Windows administra os recursos da rede dividindo-a em subredes chamadas de domínios. Em cada
domínio há uma lista distinta de usuários e um servidor para controlar.
Um servidor na rede que centraliza a configuração de usuários em um domínio é o Primary Domain
Controller (PDC), ou controlador primário de domínio. Em uma rede pode haver diversos servidores
Windows, mas apenas um servidor primário de domínio para cada domínio, sendo os demais Backup
Domain Controle (BDC), ou servidores de backup.
Os recursos oferecidos na rede estão, em geral, ligados a um computador. Este computador faz o
papel de servidor deste recurso, como serviço de impressão, de conexão internet (proxy e firewall), de
armazenamento de dados etc. Mas a permissão de acesso a todos os serviços passa pelo servidor
primário do domínio.
Dois domínios diferentes podem se comunicar e os usuários de um ser autorizado pelo outro. Para isto
o Windows utiliza o conceito de relação de confiança, que é estabelecido entre os dois domínios. Eles
passam a se comportar como um único domínio, mas com duas lista de usuários.
O Windows utiliza o recurso Active Directory para administrar os domínios como se fossem uma
estrutura de diretórios, agrupando domínios em árvores e estas em florestas.

9.2 Conceitos de administração de servidores em plataforma Linux

A administração de servidores Linux é feita, em geral, por linhas de comando digitadas em uma tela de
textos. Por isto, o administrador precisa saber os comandos e sua sitaxe. Existem programas que criam
interfaces gráficas, chamados de shells, que facilitam a vida de usuários inesperientes.
Os servidores Linux com serviços para internet são mais usados do que os demais sistemas por sua
estabilidade e confiabilidade. Assim são os servidores linux:
 apache, servidor http, que adminstra páginas de internet,
 proftpd, servidor ftp, para administrar transferências de arquivos
 Bind, serviço dns, para administração de nomes de domínios
 Squid, servidor proxy, para controlar a entrada da rede e os acessos externos (firewall)

9.2.1 Alguns comandos no Linux

 cp copia arquivos.
cp [opções] [origem] [destino]
 mv move ou renomeia arquivos e diretórios. O processo é semelhante ao do comando cp mas o
arquivo de origem é apagado após o término da cópia.
mv [opções] [origem] [destino]
 chown muda dono de um arquivo/diretório. Opcionalmente pode também ser usado para mudar o
grupo.
chown [opções] [dono.grupo] [diretório/arquivo]
 chmod é usado para alterar permissões de arquivos (ou ficheiros) e diretórios (directórios ou
pastas). Sua sintaxe é a seguinte:
chmod [permissões] arquivo

115
 TI para concursos
53
9.2.1.1 Gerenciando Usuários
Para adicionar um usuário:
adduser <usuário>
Em seguida é necessário definir uma senha para este usuário, utilizando o comando:
passwd <usuário>
Para remover um usuário e seu diretório home:
userdel -r usuário
Para obter as permissões de outros usuários:
su <usuário>
Se o campo <usuário> for omitido, o su intenderá como root. E para simular um login, executando os
scripts de inicialização do usuário acrescenta-se “- “ entre su e o <usuário> , como no exemplo:
su - vinicius

9.2.1.2 Diretório /etc

O diretório /etc contém todas as configurações do servidor, por isso deve-se conhecer todo o seu
conteúdo e também ter uma preocupação especial com as permissões de arquivos nele contidos:
 passwd - ficam os usuários cadastrados no sistema. Cada linha corresponde a um usuário e o
caracter “:” separa os campos. Analisando o exemplo abaixo:
vinic:x:1001:0:Vinicius Schmidt,,,:/home/vinic:/bin/bash
login:Senha:Id:Gid:Nome e Dados:Diretório:Shell
 Login: É a identificação do usuário que também pode ser usado para identificação do email.
 Senha: “ x “ informa que a senha está em outro arquivo mais seguro.
 Id: código único para o Linux identificar cada usuário. Nunca deve-se ter dois usuários com o mesmo
código.
 Gid: código do grupo primário que o usuário pertence.
 Nome e Dados: usado para armazenar informações sobre o usuário como nome, telefone, sala, etc.. Esses
dados são separados por “,” e devem obedecer um padrão.
 Diretório: informa qual é o directório home, do usuário.
 Shell: shell default do usuário. Para usuários que não precisam de shell deve-se colocar “/dev/null”.
 shadow - ficam gravadas todas as senhas (criptografadas) de acesso ao sistema.
 group - descreve quais são os grupos do sistema. O primeiro campo corresponde ao nome do
grupo, o segundo campo a senha, o terceiro é o chamado GID ou Group ID, e o próximo campo
são os usuários pertencentes a este grupo, observando que os mesmos são separados por “,“.
 Inittab - arquivo principal de inicialização do Linux, ele é quem dá inicio aos demais arquivos dentro
do diretório /etc/rc.d . O modo mais usado é o “3” que indica para iniciar todas as tarefas, mas
continuar no console. Existe também o modo “5” que entra com a tela de login já em modo gráfico.
Veja detalhes no Apêndice E, Níveis de Execução no Red Hat Linux .
 Fstab - configura os sistemas de arquivos montados durante o processo de inicialização do Linux.
Estabelece os pontos default de montagem do sistema. O arquivo /etc/fstab permite configurar o
sistema para montar partições, cdroms, disquetes e compartilhamentos de rede durante o boot.
Cada linha é responsável por um ponto de montagem.
 login.defs - É o arquivo de configurações do login, possui informações valiosas para melhorar a
segurança do seu ambiente. É um arquivo muito simples de configurar pois é baseado em
exemplos, e seus parâmetros são simples.
 Profile - Toda vez que um usuário loga, este arquivo é executado, por isso ele é usado para setar as
variáveis de ambiente globais, dentre outras coisas.
 hosts.deny - Hosts que não tem permissão para acessar a máquina.
 hosts.allow - Hosts que tem permissão para acessar a máquina.
 Services - Este arquivo descreve a relação entre os serviços e as portas mais comuns.

9.2.1.3 Diretórios mais importantes:

• /etc/rc.d - arquivos responsáveis pela carga dos daemons na inicialização do Linux.
• /etc/skel - arquivos que serão copiados para o home de um usuário recém criado.

53 http://apostilas.netsaber.com.br/apostilas/1662.pdf
116
 TI para concursos

9.2.2 Gerenciando a iniciação do Linux

O lilo e o grub disputam o posto de gerenciador de boot default entre as distribuições Linux. São os
responsáveis pela “carga” do kernel do Linux na memória. Sem o gerenciador de boot o sistema
simplesmente não inicializa.
Muitas distribuições permitem que você escolha entre usar o lilo ou o grub durante a instalação. Outras
usam um dos dois por padrão. O grub oferece mais opções e inclui um utilitário, o update-grub que gera
um arquivo de configuração básico automaticamente. Por outro lado, a sintaxe do arquivo de
configuração do grub é mais complexa o que o torna bem mais difícil de editar manualmente que o do
lilo.
O lilo utiliza um único arquivo de configuração, o /etc/lilo.conf. Ao fazer qualquer alteração neste
arquivo é preciso chamar o executável do lilo, o "/sbin/lilo" para que ele leia o arquivo e salve as
alterações..
O grub usa o arquivo de configuração /boot/grub/menu.lst. Este arquivo é lido a cada boot, por isso não
é necessário reinstalar o grub ao fazer alterações, como no caso do lilo.

9.2.3 Fazendo Backups

Realizar backups do sistema hoje em dia é uma tarefa essencial de todo administrador. No Linux pode-
se usar o comando tar para compactar os arquivos.
Sintaxe: tar [opções] [-f arquivo]
Opções:
x : descompactar.
t : lista o conteúdo de um arquivo.
v : mostra na tela o que está sendo feito.
z : descompacta arquivos que também estejam gzipados .
f : especifica o nome do arquivo.
c : cria um novo arquivo.
Exemplos:
 tar cvzf meu_backup.tgz ~ (faz o backup de sua área pessoal)
 tar cvzf backup.tgz /home (faz o backup da área dos usuários )
 tar xvzf /root/backup.tar.gz (descompacta o backup)

9.2.4 Recompilando e Adaptando o Kernel

Os administradores devem se preocupar em manter a máquina mais enxuta possível e para isso deve-
se recompilar o kernel apenas com o necessário. Uma sugestão é a separação em módulos, o que
sem dúvida reduzirá o “peso” da máquina. Para recompilar o kernel deve-se baixar o fonte de uma
versão estável no site http://www.kernel.org ou um mirror confiável.
O fonte deve ser descompactado no diretório /usr/src. No diretório /usr/src/linux devem ser feitos alguns
procedimentos:
 make menuconfig - Entra no modo de configuração do kernel. Um ambiente amigável de fácil compreensão
onde se pode marcar os pacotes que serão usados.
 make dep - Acerta as dependências das bibliotecas necessárias para a compilação.
 make - Compila o kernel.
 make modules - Compila os módulos.
 make install - Instala o kernel.
 make modules_install - Instala os módulos.

9.2.5 Agendando Processos

Para agendar processos muito demorados como o download de um arquivo muito grande, ou qualquer
outro processo que necessite de uma execução automática, deve-se usar basicamente dois comandos:
 at - agenda a execução de um comando e logo depois que esse processo ocorre este comando não será
mais executado
 crontab - agenda processos que devem rodar periodicamente.

9.2.6 Syslogd - A Caixa Preta do Linux

Para analisar o que vem ocorrendo ou já ocorreu no sistema, o linux possui o syslogd, que funciona
como uma caixa preta, guardando em arquivos, informações como: data e hora do boot, login de

117
 TI para concursos
usuário e outros dados importantes para analisar o servidor.
O arquivo responsável pelas configuração do syslogd é o /etc/syslog.conf .
Os registros deste arquivo são divididos em facility, priority e destino, podendo haver derivações como
dois conjuntos “facility.priority” para um mesmo destino.
As “facilities” podem ser: auth, auth-priv, cron, daemon, kern, lpr, mail, mark, news, security (mesmo
que auth), syslog, user, uucp e local0.
Já as “priorities” seguem em ordem crescente: debug, info, notice, warning, warn (memo que
warning), err, error (mesmo que err), crit, alert, emerg, panic (mesmo que emerg).
Um arquivo gerado na grande maioria dos sistemas *nix é o /var/log/messages, que contém
informações genéricas sobre todo o sistema.
Outro arquivo muito comum é o /var/log/debug que contém informações mais detalhadas.

9.2.7 Técnicas Básicas para Trabalhar com Redes (ifconfig, route)

O Linux é um sistema operacional totalmente compatível com redes, dos tipos mais heterogêneos.
Para listar as interfaces de rede usa-se o comando:
ifconfig -a
Para atribuir um endereço IP para uma interface usa-se:
ifconfig eth0 <endereço> broadcast <broadcast> netmask <mascara>
Também existem as rotas para o pacote IP poder sair para fora da rede local, caso haja um roteador.
Para exibir a tabela de rotas usa-se o comando:
route -n ou netstat -nr
Para adicionar uma rota:
route add default gw <Gateway> netmask 0.0.0.0 metric 1
E caso haja a necessidade de excluir uma rota usa-se:
route del <destino>

9.2.8 Gerenciando os Serviços - inetd

O inetd é um daemon que pode gerenciar outros daemons, tendo uma função de supervisor. Este
supervisor é executado sempre na carga do sistema, e busca a lista de serviços que devem passar
pelo inetd no arquivo /etc/inetd.conf.

9.2.9 Utilizando Ferramentas de Busca

Para deixar o sistema em dia, com pacotes sempre atualizados, sugere-se a pesquisa contínua nos
vários sites que oferecem tais pacotes.
Ex.: http://www.freshmeat.net

9.2.10 Instalando SSh / SShD

O telnet antigamente era muito usado para obter acesso remoto de um servidor, mas o grande
problema do telnet é que os pacotes de dados passam limpos (não criptografados) pela rede
possibilitando um ataque, captura de todos os pacotes que percorrem na rede, inclusive senhas,
números de cartão de crédito etc.
A solução encontrada pelos profissionais de segurança e administradores foi a substituição do telnet
por ssh, que criptografa os dados dos pacotes, impossibilitando a sua fácil compreensão.
Para instalar o SSh deve-se baixar o pacote de algum lugar, tendo o cuidado de se baixar o produto de
instituições com reconhecida credibilidade, pois do contrário, corre-se um sério risco de baixar “trojan
horse”. Depois de pegar o pacote:
tar xvzf ssh-1.2.27.tar.gz
Depois, apenas mais três comandos dentro do diretório do ssh-1.2.27:
./configure ; make ; make install
O SSh já está instalado agora para colocar seu daemon no /etc/rc.d/rc.local:

118
 TI para concursos
echo “/usr/local/sbin/sshd” >> /etc/rc.d/rc.local
rc.local: Este arquivo é executado sempre na hora do boot, como o Autoexec.bat do DOS

9.3 Conceitos de Virtualização

Virtualização é a técnica que permite particionar um único sistema computacional em vários outros
denominados de máquinas virtuais. Cada máquina virtual oferece um ambiente completo muito similar
a uma máquina física. Com isso, cada máquina virtual pode ter seu próprio sistema operacional,
aplicativos e serviços de rede (Internet). É possível ainda interconectar (virtualmente) cada uma dessas
máquinas através de interfaces de redes, switches, roteadores e firewalls virtuais, além do uso já
54
bastante difundido de VPN (Virtual Private Networks).
A virtualização pode auxiliar a se trabalhar em um ambiente onde haja uma diversidade de plataformas
de software (sistemas operacionais) sem ter um aumento no número de plataformas de hardware
(máquinas físicas). Assim, cada aplicação pode executar em uma máquina virtual própria,
possivelmente incluindo suas bibliotecas e seu sistema operacional que, por sua vez, executam em
uma plataforma de hardware comum.
Ao se executar múltiplas instâncias de máquinas virtuais em um mesmo hardware, também se está
proporcionando um uso eficiente de seu poder de processamento. Essa situação é comumente
denominada de consolidação de servidores e é especialmente interessante em data centers devido a
heterogeneidade de plataformas inerente ao próprio negócio. Além disso, em data centers, a
diminuição de máquinas físicas implica na redução de custos de infra-estrutura física como espaço,
energia elétrica, cabeamento, refrigeração, suporte e manutenção a vários sistemas.
A flexibilidade e a portabilidade das máquinas virtuais também tornam interessante o uso da
virtualização em desktops. É possível imaginar, por exemplo, o desenvolvimento de produtos de
software destinados a vários sistemas operacionais sem ter a necessidade de uma plataforma física
para desenvolver e testar cada um deles. Assim, as máquinas virtuais em desktops podem ser usadas
para se definir ambientes experimentais sem comprometer o sistema operacional original da máquina,
ou ainda, para compor plataformas distribuídas como clusters e grades computacionais.
As máquinas virtuais, por emularem um ambiente computacional sobre outro, impõem algumas
restrições de implementação e de desempenho. É aqui que entra o desenvolvimento dos produtos de
software para a virtualização.
As máquinas virtuais podem ser:
 máquina virtual de processo – aplicação sobre um sistema operacional
 hypervisor ou monitor de máquina virtual – camada de software posicionada entre o hardware da
máquina e o sistema operacional por duas técnicas:
 para-virtualização – o sistema hóspede é modificado para chamar a VMM sempre que for executada uma
instrução ou ação considerada sensível. Dessa forma, o teste por instrução não é necessário. Os
dispositivos de hardware são acessados por drivers da própria VMM. A substituição da chamada de uma
instrução sensível pela chamada a um tratador de interrupção de software (trap) é chamado de hypercall.
 virtualização total – réplica do hadware subjacente de tal forma que o sistema operacional e as aplicações
podem executar como se tivessem executando diretamente sobre o hardware original. A grande vantagem
dessa abordagem é que o sistema operacional hóspede não precisa ser modificado para executar sobre a
VMM.
Sistema operacional é a camada de software inserida entre o hardware e as aplicações que executam
tarefas para os usuários e cujo objetivo é tornar a utilização do computador, ao mesmo tempo, mais
eficiente e conveniente.
A utilização mais eficiente busca um maior retorno no investimento feito no hardware. Maior eficiência
significa mais trabalho obtido pelo mesmo hardware. Isso é obtido através da distribuição de seus
recursos (espaço em memória principal, processador, espaço em disco etc) entre diferentes programas.
Cada programa tem a ilusão de estar executando sozinho no computador quando na realidade ele está
compartilhando com os demais. Uma utilização mais conveniente do computador é obtida, escondendo-
se do usuário detalhes de hardware, em especial, dos periféricos de entrada e saída. Tipicamente, isso
é feito através da criação de recursos de mais alto nível oferecido através de interfaces gráficas. Por
exemplo, os usuários usam espaço em disco através do conceito de arquivos. Arquivos não existem no
hardware. Eles formam um recurso criado a partir do que o hardware oferece. Genericamente, isso é
denominado de virtualização de recursos.

54 http://www.gta.ufrj.br/ensino/CPE758/artigos-basicos/cap4-v2.pdf
119
 TI para concursos
O elemento central de um computador é seu processador. Cada processador tem um conjunto de
instruções de máquina que pode seguir um determinado padrão. Por exemplo, Intel e AMD, fabricam
processadores que implementam um mesmo padrão ISA, o Intel IA-32 (x86). Os projetistas de software
compilam seu programas para obter códigos binários para um determinado ISA. Portanto, o conjunto de
instruções (ISA) é uma interface entre o hardware e o software.
Tipicamente, um sistema de computação oferece três tipos de interfaces:
 instruções de máquina (privilegiadas) - interface que permite que apenas alguns programas, os com
privilégios especiais, como o sistema operacional, possam executar todas as instruções, entre elas, as de
manipulação de recursos de hardware, como entrada e saída e interrupções.
 instruções de máquina (não privilegiadas) e chamadas de sistema - interface que possibilita que um
programa de usuário execute instruções não-privilegiadas diretamente no processador, mas não permite o
acesso aos recursos de hardware (instruções privilegiadas). As chamadas de sistema são uma forma de
permitir que os programas de usuários acessem de forma indireta, e controlada, os recursos de hardware.
Através delas, os programas de usuário executam, após ter sido garantido a autenticidade e a validade da
operação, operações de acesso a recursos de hardware (tipicamente E/S).
 interface aplicativa de programação – mais conhecida como API (Application Program Interface), são
funções de biblioteca que fazem com que as chamadas de sistema sejam ocultadas.
Considerando essas interfaces, a implementação de máquinas virtuais pode ser feita de três modos:
 programa de aplicação que forneçe um ambiente de execução para outras aplicações. Esse
ambiente pode possuir um conjunto de instruções abstratas que são interpretadas para gerar as
instruções de máquinas não-privilegiadas, as chamadas de sistema e de API de bibliotecas que
correspondem à ação abstrata desejada. É o caso da máquina virtual java (JVM).
 programa de aplicação que emula chamadas de sistemas de outro sistema operacional, como
ocorre quando se executa Linux em sistemas Windows com a ferramenta VMware player . Esse tipo
de virtualização é o que se denomina de máquina virtual de processo.
 camada de software entre o hardware e o sistema operacional protegendo o acesso direto deste aos
recursos físicos da máquina. Essa camada oferece como interface ao sistema operacional um
conjunto de instruções de máquina que pode ser o mesmo do processador físico, ou um outro. O
ponto importante é que essa interface deve estar disponível sempre que o computador estiver ligado
e que ela possa ser usada simultaneamente por diferentes programas. O resultado final é que
possível ter diversos sistemas operacionais (programas) executando independentemente na mesma
plataforma. Genericamente, essa máquina virtual é referenciada como monitor de máquina virtual
(Virtual Machine Monitor ou VMM), também conhecido como hypervisor, ou ainda, máquina virtual
de sistema.
O processo ou sistema que executa sobre uma máquina virtual é denominado de hóspede, enquanto o
ambiente sobre o qual ele executa é chamado de hospedeiro.
Os fabricantes de processadores, AMD e Intel, desenvolveram extensões para a arquitetura x86 para
suportarem a virtualização:
 Pacífica – AMD-V (AMD-Virtualization), se aplica às arquiteturas x86 de 64 bits como o Athon,
Turion, Phenom e as linhas mais recentes. A AMD implementa funções especiais no processador
que são executadas por um hypervisor e que podem controlar, em seu nome, se determinados
acessos de um sistema hóspede são permitidos.
 Vanderpool – IVT (Intel Virtualization Technology) para as arquiteturas x86 de 32 e 64 bits. A Intel
introduziu mecanismos similares (virtual machines extensions) que complementam a idéia do
conceito de anéis de proteção com dois novos modos: root e não-root. Esses modos são
controlados pelo hypervisor (que executa em modo root) e que pode transferir a execução de um
sistema operacional hóspede para o modo não-root no qual instruções do anel zero são executadas
sem risco para o sistema.
As soluções da AMD e da Intel foram desenvolvidas independentemente uma da outra e são
incompatíveis, embora sirvam para o mesmo propósito.
Existem diversas soluções comerciais, gratuitas, em software livre ou integradas a sistemas
operacionais. Entre as mais conhecidas destacam-se o VMware e o Xen
O VMware é uma infra-estrutura de virtualização completa com produtos abrangendo desde desktops a
data centers organizados em três categorias:
 gestão e automatização, forma automatizada e centralizada de gerência de todos os recursos da
infra-estrutura virtual permitindo a monitoração do sistema, auxiliando na conversão de sistemas
físicos em virtuais, na recuperação de desastres, entre outros.

120
 TI para concursos
 infra-estrutura virtual, monitoração e alocação de recursos entre as máquinas virtuais de forma a
atender requisitos e regras de negócios. Soluções para alta disponibilidade, backup, migração de
máquinas virtuais e atualização de versões de software.
 virtualização de plataformas, destinado a criar máquinas virtuais.
O Xen é um monitor de máquina virtual (hypervisor ou VMM), em software livre, licenciado nos termos
da GNU General Public Licence (GPL), para arquiteturas x86, que permite vários sistemas operacionais
hóspedes serem executados em um mesmo sistema hospedeiro. O Xen é originário de um projeto de
pesquisa da universidade de Cambridge, que resultou em um empresa, a XenSource inc, adquirida
pela CitrixSystem em outubro 2007.
Os dois principais conceitos do Xen são:
 domínios - máquinas virtuais do Xen e são de dois tipos:
 privilegiada (domínio 0) - máquina virtual única que executa um núcleo linux modificado e que possuí
privilégios especiais para acessar os recursos físicos de entrada e saída e interagir com as demais
máquinas virtuais (domínios U). Por ser um sistema operacional modificado, possui os drivers de
dispositivos da máquina física e dois drivers especiais para tratar as requisições de acesso a rede e ao
disco efetuados pelas máquinas virtuais dos domínios U.
 não-privilegiada (domínio U)
 hypervisor - controla os recursos de comunicação, de memória e de processamento das máquinas
virtuais e não possui drivers de dispositivos. O hypervisor Xen não é capaz de suportar nenhum tipo
de interação com sistemas hóspedes, é necessário que exista um sistema inicial para ser invocado
pelo hypervisor. Esse sistema inicial é o domínio 0. As outras máquinas virtuais só podem ser
executadas depois que ele for iniciado. As máquinas virtuais de domínio U são criadas, iniciadas e
terminadas através do domínio 0.
O Virtual PC 2007 é uma máquina virtual para família Windows que pode ser configurada para executar
qualquer outro sistema operacional. O Virtual PC oferece mecanismos para interconectar logicamente
as diferentes máquinas virtuais. Cada máquina virtual tem seu próprio endereço MAC e endereço IP.
Além disso, o Virtual PC oferece um servidor de DHCP, um servidor NAT e switches virtuais. Dessa
forma, é possível construir cenários de rede usando máquinas virtuais. O virtual PC 2007 é disponível
para download, assim como um white paper que ensina a configurar as máquinas virtuais e um
ambiente de rede.
O Windows 2008 Server Hyper-V explora eficientemente as arquiteturas de 64 bits, processadores
multicore e meios de armazenamento e oferece todo um ambiente integrado de gerenciamento da
virtualização (monitoração, automatização de procedimentos, migração, recuperação de desastres etc).
Entre as principais vantagens do Windows 2008 Server Hyper-V estão várias ferramentas para
automatizar o processo de virtualização. Uma delas é o Manager Physical-to-virtual (P2V) que auxilia
na conversão de servidores físicos para virtuais. Há também o Volume Shadow Copy Services que
realiza automaticamente procedimentos de backup e de disponibilidade de forma que o sistema, como
um todo, opere de forma homogênea independente de falhas e de “picos” de carga. Isso é feito por
técnicas de migração de máquinas virtuais.

9.4 Active Directory

Software da Microsoft utilizado em ambientes Windows, o Active Directory é uma implementação de
serviço de diretório no protocolo LDAP que armazena informações sobre objetos em rede de
computadores e disponibiliza essas informações a usuários e administradores desta rede.55
O "diretório ativo" permite que os administradores atribuam à empresa políticas largas, ofereçam
programas a muitos computadores, e apliquem updates críticos a uma organização inteira. Uma
informação ativa e ajustes das lojas do diretório que relacionam-se a uma organização em uma central,
base de dados organizada, acessível.
O Active Directory está relacionado à:
 Gerenciamento centralizado
 GPO – Políticas de Grupo
 Catálogo Global
 Gerenciamento de Desktop Intellimiror
 Distribuição de Software Automática
 Interface de acesso ADSI

55 http://pt.wikipedia.org/wiki/Active_Directory
121
 TI para concursos
 Compatibilidade com sistemas operacionais MS Legados
 Administração Delegada
 Replicação Automática
O Active Directory (AD) surgiu da necessidade de se ter um único diretório – um banco de dados que
armazena as informações dos usuários, grupos, senhas, contas de computadores, relações de
confiança, informações sobre o domínio, unidades organizacionais etc – onde os usuários poderão ter
apenas uma senha para acessar todos os recursos disponíveis na rede.
Disponibiliza vários serviços, como: autenticação dos usuários, replicação do seu banco de dados,
pesquisa dos objetos disponíveis na rede, administração centralizada da segurança utilizando GPO,
entre outros serviços.
O AD é organizado de uma forma hierárquica, com o uso de domínios. Um domínio é um limite
administrativo com diferentes administradores e diferentes políticas de segurança.
Domínios baseados no AD pussuem os seguintes recursos:
 Logon único: com esse recurso, o usuário necessita fazer apenas um logon para acessar os
recursos em diversos servidores da rede, inclusive email e banco de dados.
 Conta de usuário única: os usuários possuem apenas um nome de usuário para acessar os
recursos da rede. As contas de usuários ficam armazenadas no banco de dados do AD.
 Gerenciamento centralizado: com os domínios baseados no AD, temos uma administração
centralizada. Todas as informações sobre contas de usuários, grupos e recursos da rede, podem
ser administradas a partir de um único local no domínio.
 Escalonabilidade: os domínios podem crescer a qualquer momento, sem limite de tamanho. A forma
de administração é a mesma para uma rede pequena ou grande.
Nos domínios baseados no AD, podemos ter dois tipos de servidores:
 Controlador de Domínio (DC – Domain Controller): é o servidor que possui o AD instalado. Em um
mesmo domínio podemos ter mais de um Controlador de Domínio. As alterações efetuadas em um
DC são replicadas para todos os outros DC’s. São os DC’s quem fazem a autenticação dos usuários
de um domínio. Um destes DC é eleito o controlador primário do domínio (PDC). Quando ele sai da
rede, um controlador secundário assume a função.
 Servidor Membro (Member Server) ou estação de trabalho (workstation): é um computador que não
possui uma cópia do AD, porém tem acesso aos objetos do AD. Não fazem a autenticação dos
usuários.
O AD utiliza o DNS para a nomeação de servidores e recursos, e também para resolução de nomes.
Esquema é um conjunto de regras que define as classes de objetos e atributos contidos no diretório, as
restrições e os limites das ocorrências desses objetos e o formato de seus nomes, que está incluído no
Active Directory.
Com a utilização de domínios, a rede pode refletir a estrutura de uma empresa. Diversos domínios
podem se interligar através do estabelecimento de relação de confiança, que permite aos usuários de
ambos os domínios acessar seus recursos. No Windows 2000, as relações de confianças são
bidirecionais e transitivas, ou seja, se o domínio X confia no domínio Y, e Y confia no domínio W, o
domínio X também confia no domínio W.
Algumas características próprias de cada domínio:
 Um domínio armazena informações somente dos objetos do próprio domínio.
 Um domínio possui suas próprias diretivas de segurança

9.5 Exercícios
174. (ICMS-SP 2009) Na arquitetura do sistema operacional Windows XP, o Executivo expõe serviços aos
174
processos usuários por meio
(a) dos Drivers de dispositivo.
(b) das DLL.
xx
(c) da API nativa.
(d) do Gerenciador de objeto.
(e) do Gerenciador de E/S.

122
 TI para concursos
175
175. (ICMS-SP 2009) NÃO é uma característica do Active Directory do Windows XP:
(a) Um serviço de rede que permite aos usuários compartilhar informações, recursos e objetos por meio de
rede.
(b) Serviços de diretório para objetos compartilhados em uma rede, por exemplo: arquivos, impressoras,
usuários etc.
xx
(c) Um serviço de acesso remoto que permite aos usuários se conectarem remotamente com uma LAN.
(d) O cliente LDAP – Protocolo Leve de Acesso a Diretório, para pesquisar e modificar diretórios de Internet,
pode acessar o Active Directory.
(e) As localizações dos objetos são transparentes, ou seja, os usuários não sabem o endereço de um
objeto.
176. (ICMS-SP 2009) Os mecanismos IPC disponíveis, tais como Sinais, Pipes, Soquetes, Mensagens, Memória
176
compartilhada e Semáforos de System V, são implementados no núcleo do Linux pelo subsistema primário
(a) Sistemas de arquivos.
xx
(b) Sistema de comunicação interprocessos.
(c) Gerenciador de processo.
(d) Gerenciador de memória.
(e) Gerenciador de E/S.
177. Para configurar e gerenciar o processo de inicialização (boot) de um computador com o sistema operacional
177
Linux, pode-se utilizar o LILO ou o
(a) INIT
(b) BOOT.
(c) LINX.
(d) LOAD
xx
(e) GRUB
178. O Windows Server 2003 fornece várias ferramentas que podem ser usadas para gerenciar arquivos e pastas.
A respeito das práticas recomendadas, quando se trata de pastas compartilhadas, analise as afirmativas a
seguir:
I. A atribuição de permissões a grupos simplifica o gerenciamento dos recursos compartilhados, pois se pode
adicionar ou remover usuários nos grupos sem precisar reatribuir as permissões.
II. As permissões compartilhadas se aplicam somente aos usuários que acessam os recursos compartilhados
na rede e não a usuários que fazem logon localmente.
III. Na implementação das ferramentas, a descentralização das pastas de dados facilita o backup dos dados
178
e o gerenciamento do compartilhamento.
Assinale:
(a) se somente a afirmativa I estiver correta.
xx
(b) se somente as afirmativas I e II estiverem corretas.
(c) se somente as afirmativas I e III estiverem corretas.
(d) se somente as afirmativas II e III estiverem corretas.
(e) se todas as afirmativas estiverem corretas.
179. Um conjunto de regras que define as classes de objetos e atributos contidos no diretório, as restrições e os
limites das ocorrências desses objetos e o formato de seus nomes, que está incluído no Active Directory,
179
denomina-se
(a) floresta.
(b) domínio.
(c) diretiva de grupo.
xx
(d) esquema.
(e) catálogo global.
180
180. Quando se elimina o nó raiz de uma estrutura em árvore, o que dela restar forma
(a) outra árvore.
xx
(b) uma floresta.
(c) uma árvore binária.
(d) uma sub-árvore.
(e) um conjunto de sub-árvores.
181
181. Obtidas as permissões de acesso a um arquivo GNU/Linux: rw-r-xr-x Trata-se de um arquivo do tipo
(a) normal, cuja execução é permitida ao dono, aos usuários do grupo user e aos outros usuários do
arquivo.
xx
(b) normal, cujas alteração ou "deleção" são permitidas apenas ao dono do arquivo.
(c) normal, cujas alteração ou "deleção" são permitidas ao dono do arquivo ou aos usuários do grupo user
do arquivo.
(d) diretório, cujas leitura, gravação e execução são permitidas apenas ao dono do arquivo.
(e) diretório, cujas leitura e execução são permitidas ao dono, aos usuários do grupo user e aos outros
usuários do arquivo.

123
 TI para concursos
182
182. O Kernel do Linux deve ser descompactado no diretório
xx
(a) /usr/src, após login como root.
(b) /root/src, após login como user.
(c) /sys/src, após login como root.
(d) /home, após login como wrapper.
(e) /boot, após login como kewl.
183. Para diversas partes de um programa serem executadas ao mesmo tempo, um sistema operacional utiliza
183
uma tecnologia de
(a) multitarefa.
(b) camadas.
xx
(c) threads.
(d) particionamento.
(e) multiprocessamento.

124
 TI para concursos

10 Redes
10.1 Conceito de rede
Rede de computadores é um conjunto de computadores interligados por qualquer meio e que se
comunicam por uma codificação determinada (protocolo de rede). Existem diversos protocolos de rede,
mas o mais utilizado atualmente é o protocolo TCP/IP, transfer control protocol – internet protocol.
Computadores que se comunicam em um sistema fechado, estão em uma rede local (LAN). Quando
duas ou mais redes se ligam em um espaço mais amplo, diz-se que estão em uma rede WAN. Existem
milhões de computadores no mundo interligados em rede por um protocolo chamado TCP/IP, formando
uma única rede chamada de internet.
O meio de ligação entre os computadores (estações de trabalho) e a forma da disposição das conexões
são camados de topologia da rede. Cabos metálicos, fibras óticas ou comunicação sem fios formam os
enlaces entre computadores, ou entre computadores e outros equipamentos que fazem o papel de nós
que recebem e distribuem os sinais na rede.
A topologia de uma rede de comunicação refere-se à forma como os enlaces físicos e os nós estão
organizados, determinando os caminhos físicos existentes e utilizáveis entre quaisquer pares de
estações conectadas a essa rede. A topologia de uma rede muitas vezes caracteriza o seu tipo,
eficiência e velocidade.
Malha (fully) - A interconexão é total garantindo alta confiabilidade, porém a complexidade da
implementação física e o custo inviabilizam seu uso comercial;
Estrela (star) - A conexão é feita através de um nó central que exerce controle sobre a comunicação.
Sua confiabilidade é limitada à confiabilidade do nó central, cujo mau funcionamento prejudica toda a
rede;
Barramento (bus) - As estações são conectadas através de um cabo com difusão da informação para
todos os nós. é necessária a adoção de um método de acesso para as estações em rede
compartilharem o meio de comunicação, evitando colisões. é de fácil expansão, mas de baixa
confiabilidade, pois qualquer problema no barramento impossibilita a comunicação em toda a rede;
Anel (ring) - O barramento toma a forma de um anel, com ligações unidirecionais ponto a ponto. A
mensagem é repetida de estação para estação até retornar à estação de origem, sendo então retirada
do anel. Como o sinal é recebido por um circuito e reproduzido por outro há a regeneração do sinal no
meio de comunicação; entretanto há também a inserção de um atraso a cada estação. O tráfego passa
por todas as estações do anel, sendo que somente a estação destino interpreta a mensagem;
Árvore (tree) - é a expansão da topologia em barra herdando suas capacidades e limitações. O
barramento ganha ramificações que mantêm as características de difusão das mensagens e
compartilhamento de meio entre as estações;
Mistas (mesh) - Combinam duas ou mais topologias simples. Alguns exemplos são o de estrelas
conectadas em anel e as árvores conectadas em barramento. Procuram explorar as melhores
características das topologias envolvidas, realizar a conexão em um barramento único de módulos
concentradores aos quais são ligadas as estações em configurações mais complexas e mais
confiáveis.

10.1.1 Configuração de redes TCP-IP

Em uma rede de computadores que utiliza o protocolo TCP-IP, existem determinadas práticas de
configuração que permitem que se usufrua da internet sem perder a rede local suas características e
segurança.

125
 TI para concursos
A cada equipamento conectado fisicamente na rede atribui-se um número chamado de endereço IP.
Este número é formado por quatro números de 0 a 255 separados por pontos. Por exemplo,
192.168.1.23 ou 10.10.0.128 são endereços IP válidos e 175.268.1.0 não é válido, pois contém um
número maior do que 255.
Estes números são, na verdade, uma representação decimal, pois a rede enxerga estes endereços
como quatro grupos de oito números binários (0 ou 1) ou octetos. Para transformar um número decimal
em binário, faz-se a divisão inteira daquele por sete vezes, então toma-se os restos das divisões em
ordem contrária:
Por exemplo, dividindo-se 244 por dois e guardando o resto da divisão:
div 2 sobra
244 0
122 0
61 1
30 0
15 1
7 1
3 1
1 1
temos que o número 244 do sistema decimal é representado por 11110100 no sistema binário.
Em uma rede local, sem conexão com outras redes que utilizam o protocolo TCP-IP, qualquer endereço
válido pode ser atribuída a qualquer computador. Porém, isto pode dificultar a sua manutenção e
prejudicar seu desempenho quando o número de computadores na rede aumentar.
O IP, elemento comum encontrado na internet pública, é descrito no documento RFC 791 (Request for
Comments) da IETF (Internet Engineering Task Force), que foi pela primeira vez publicado em
Setembro de 1981. Esta versão do protocolo é designada de versão 4, ou IPv4. O IPv6 tem
endereçamento de origem e destino de 128 bits, oferecendo mais endereçamentos que os 32 bits do
IPv4, com previsão de ser padrão na internet a partir de 2011.
Originalmente, o espaço do endereço IP foi dividido em poucas estruturas de tamanho fixo chamados
de "classes de endereço". As três principais são a classe A, classe B e classe C. Examinando os
primeiros bits de um endereço, o software do IP consegue determinar rapidamente qual a classe, e
logo, a estrutura do endereço.
 Classe A: Primeiro bit é 0 (zero)
00000000.00000000.00000000.00000000 até 01111111.11111111.11111111.11111111 ou 0.0.0.0 até 127.255.255.255
 Classe B: Primeiros dois bits são 10 (um, zero)
10000000.00000000.00000000.00000000 até 10111111.11111111.11111111.11111111 ou 128.0.0.0 até 191.255.255.255
 Classe C: Primeiros três bits são 110 (um, um, zero)
11000000.00000000.00000000.00000000 até 11011111.11111111.11111111.11111111 ou 192.0.0.0 até 223.255.255.255
 Classe D: (endereço multicast): Primeiros quatro bits são: 1110 (um, um, um, zero)
11000000.00000000.00000000.00000000 até 11011111.11111111.11111111.11111111 ou 224.0.0.0 até 239.255.255.255
 Classe E: (endereço especial reservado): Primeiros cinco bits são 11110 (um, um, um, um, zero)
11000000.00000000.00000000.00000000 até 11011111.11111111.11111111.11111111 ou 240.0.0.0 até 247.255.255.255
Existem classes especiais na Internet que não são consideradas públicas, não são consideradas como
endereçáveis.
 São reservados para a comunicação em uma rede privada os endereços que começam com 10.0.0.0, e
192.168.0.0 e os endereços na faixa 172.16.0.0 até 172.31.255.254.
 É reservado para representar o computador local ("localhost") a faixa de endereços 127.0.0.0 a
127.255.255.255. Um computador usa qualquer destes endereços para designar a ele mesmo, como o
pronome pessoal “eu”.
 É reservado para representar rede corrente o endereço 0.0.0.0. Um computador usa este endereço para
designar a própria rede.
A utilização destes endereços torna o computador inacessível por outros computadores na internet, o
que representa uma segurança. Por outro lado, para acessar a internet, a rede local precisa de pelo
menos um equipamento com um endereço público não reservado. Este equipamento pode fazer a
ligação entre a rede e a internet, ou roteamento. Pode ser um roteador ou um computador.
O endereço IP tem a função de identificar o computador, que chamamos de host, e também a rede em
que está conectado. O roteamento dos pacotes enviados na rede TCP/IP é feito procurando a rede e
depois o host (equipamento). Os bits à esquerda são utilizados para a rede. A quantidade de bits
utilizada é definida pelo administrador da rede por um número chamado de máscara de rede ou
netmask. O netmask é um conjunto de quatro octetos, como um endereço IP, iniciado por um grupo de
uns à esquerda e outro grupo com zeros à direita.
126
 TI para concursos
Uma rede com endereços que comece com 192.168 e netmask 255.255.0.0, por exemplo, pode ter até
255x255=65536 endereços. O primeiro (192.168.0.0) é reservado para identificar a própria rede e o
último (192.168.255.255) é usado para distribuir dados para toda a rede (broadcast), os demais 65534
endereços são para os hosts. Todas as informações de todos os computadores nesta rede vai ser
inviada para todos os computadores, gerando colisões que podem tornar a rede muito lenta.
Para minimizar este problema, uma rede pode ser dividida em várias subredes alterando-se o natmask.
Um netmask 255.255.255.0 vai reduzir o número de endereços em cada rede para apenas 256 (254
para hosts) e aumentar o número de redes em 256 vezes. Cada subrede recebe um endereço para ser
identificada e outro para o broadcast a partir de operações lógicas entre a máscara de rede (netmask) e
cada endereço de cada equipamento.
Por exemplo, uma net mask pode ser 11111111. 11111111. 11111111.00000000, representada por 255.255.255.0.
A identificação de rede de um endereço IP é dada pela operação lógica ^ (e/and) entre a máscara e o
endereço. Nesta operação, comparam-se os octetos posição a posição, sendo atribuido o valor zero se
um dos dígitos for zero, ou valor um em caso contrário.
Um endereço 192.168.1.101 E uma máscara 255.255.255.0 produz o endereço 192.168.1.0, que identifica a rede.
A identificação de rede do broadcast é obtido pelo operação lógica v (ou/or) entre a negação da
máscara e o endereço.
Um endereço 192.168.1.101 OU uma máscara 255.255.255.0 produz o endereço 192.168.1.255, que identifica o broadcast.
O netmask não precisa usar somente grupos completos de oito bits. Desde que não haja “buracos”,
pode-se tomar mais algums bits.
Uma net mask pode ser 11111111. 11111111. 11111111.10000000, representada por 255.255.255.128, e um endereço, por exemplo,
192.168.1.132/25, dentro desta subrede será representada com o número de bits da máscara à sua direita, neste caso 25 (8+8+8+1).
Neste exemplo, o número de endereços se reduziu para 128 (126 para hosts) e o número de redes aumentou em 128 vezes.
Assim, podem ser criadas subredes com 128 endereços (126 hosts), 64, 32, 16, 8, 4 ou 2 endereços
(que não seve para nada). A conta de quantos hosts podem haver em uma subnet é dois elevado ao
número de zeros na netmask menos dois: hosts=2n-2. O número de subredes é dois elevado ao
número de uns do octeto incompleto: redes=2n.
Na nossa net mask 11111111. 11111111. 11111111.10000000, com sete zeros, teremos 27-2=126 endereços para hosts e 21=2 para
subredes.
Em uma net mask 11111111. 11111111. 11111111.11100000, com cinco zeros, teremos 25-2=30 endereços para hosts e 23=8
subredes.
Com isto tudo, o acesso de um equipamento a outro na mesma subrede é direta e rápida, enquanto
que computadores em redes distintas só conseguem se comunicar de forma remota.

10.2 Arquitetura de Rede

Arquitetura de rede é como se designa um conjunto de camadas e protocolos de rede. A especificação
de uma arquitetura deve conter informações suficientes para permitir que um implementador
desenvolva programas ou construa o hardware de cada camada, de forma que ela obedeça
56
corretamente ao protocolo adequado.
ISO foi uma das primeiras organizações a definir formalmente uma forma comum de conectar
computadores. Sua arquitetura é chamada OSI (Open Systems Interconnection), Camadas OSI ou
57
Interconexão de Sistemas Abertos.
Esta arquitetura é um modelo que divide as redes de computadores em sete camadas, de forma a se
obter camadas de abstração. Cada protocolo implementa uma funcionalidade assinalada a uma
determinada camada.
 1 Camada física
 Subcamada MAC
 Subcamada LLC
 2 Camada de enlace
 3 Camada de rede
 4 Camada de transporte
 5 Camada de sessão
 6 Camada de apresentação

56 http://pt.wikipedia.org/wiki/Arquitetura_de_rede
57 http://pt.wikipedia.org/wiki/Modelo_OSI
127
 TI para concursos
 7 Camada de aplicação

10.2.1 Camada Física

A camada física define as características técnicas dos dispositivos elétricos (físicos) do sistema. Ela
contém os equipamentos de cabeamento ou outros canais de comunicação que se comunicam
diretamente com o controlador da interface de rede. Preocupa-se, portanto, em permitir uma
comunicação bastante simples e confiável, na maioria dos casos com controle de erros básico:
 Move bits (ou bytes, conforme a unidade de transmissão) através de um meio de transmissão.
 Define as características elétricas e mecânicas do meio, taxa de transferência dos bits, tensões etc.
 Controle de acesso ao meio.
 Controle da quantidade e velocidade de transmissão de informações na rede.
Os principais equipamentos relacionados à camada física são:
 Repeater ou repetidor - utilizado para interligação de redes idênticas, amplificam e regeneram
eletricamente os sinais transmitidos no meio físico. Recebe todos os pacotes de cada uma das
redes que ele interliga e os repete nas demais redes sem realizar qualquer tipo de tratamento sobre
os mesmos.
 HUB ou concentrador - concentra a ligação entre diversos computadores que estão em uma rede
local. Trabalha por broadcast, que envia a mesma informação dentro de uma rede para todas as
máquinas interligadas. Possui diversas portas que partilham o mesmo domínio de colisão.

10.2.2 Camada de Enlace ou Ligação de Dados

Detecta e, opcionalmente, corrige erros que possam acontecer no nível físico. É responsável pela
transmissão e recepção (delimitação) de quadros e pelo controle de fluxo. Estabelece um protocolo de
comunicação entre sistemas diretamente conectados, como PPP ou NetBios.
Esta camada é dividida em outras duas camadas:
 Controle de ligação lógica (LLC), que fornece uma interface para camada superior (rede).
 Controle de acesso ao meio físico (MAC), que acessa diretamente o meio físico e controla a
transmissão de dados.
Os principais equipamentos relacionados à camada de enlace são:
 Bridge ou ponte - dispositivo que liga redes com quaisquer protocolos ou dois segmentos da mesma
rede que usam o mesmo protocolo. Uma bridge ignora os protocolos utilizados nos dois segmentos
que liga, somente envia dados de acordo com o endereço do pacote. Este endereço não é o
endereço IP (internet protocol), mas o MAC (media access control) que é único para cada placa de
rede. Os únicos dados que são permitidos atravessar uma bridge são dados destinados a
endereços válidos no outro lado da ponte. Desta forma é possível utilizar uma bridge para manter
um segmento da rede livre dos dados que pertencem a outro segmento.
 Switch ou comutador – dispositivo que reencaminha frames entre os diversos nós e segmenta a
rede internamente. Possui diversas portas, cada uma corresponde um dominio de colisão diferente,
não havendo colisões entre pacotes de segmentos diferentes. Com um Switch gerenciável,
podemos criar VLANS, deste modo a rede gerenciada será divida em menores segmentos.
Protocolos: Ethernet e PPP.

10.2.3 Camada de Rede

A camada de Rede é responsável pelo endereçamento dos pacotes, convertendo endereços lógicos
(ou IP) em endereços físicos, de forma que os pacotes consigam chegar corretamente ao destino. Essa
camada também determina a rota que os pacotes irão seguir para atingir o destino, baseada em fatores
como condições de tráfego da rede e prioridades.
Essa camada é usada quando a rede possui mais de um segmento e, com isso, há mais de um
caminho para um pacote de dados percorrer da origem ao destino.
As funções da camada de rede são encaminhamento, endereçamento, interconexão de redes,
tratamento de erros, fragmentação de pacotes, controle de congestionamento e sequenciamento de
pacotes.
Movimenta pacotes a partir de sua fonte original até seu destino através de um ou mais enlaces. Define
como dispositivos de rede descobrem uns aos outros e como os pacotes são roteados até seu destino
final.
Dispositivo: Swith L3
128
 TI para concursos
Protocolo: IP.

10.2.4 Camada de Transporte

A camada de transporte é responsável por usar os dados enviados pela camada de Sessão e dividi-los
em pacotes que serão transmitidos para a camada de Rede. No receptor, a camada de Transporte é
responsável por pegar os pacotes recebidos da camada de Rede, remontar o dado original e assim
enviá-lo à camada de Sessão.
Isso inclui controle de fluxo, ordenação dos pacotes e a correção de erros, tipicamente enviando para o
transmissor uma informação de recebimento, informando que o pacote foi recebido com sucesso.
A camada de Transporte separa as camadas de nível de aplicação (camadas 5 a 7) das camadas de
nível físico (camadas de 1 a 3). A camada 4, Transporte, faz a ligação entre esses dois grupos e
determina a classe de serviço necessária como orientada a conexão e com controle de erro e serviço
de confirmação, sem conexões e nem confiabilidade.
O objetivo final da camada de transporte é proporcionar serviço eficiente, confiável e de baixo custo. O
hardware e/ou software dentro da camada de transporte e que faz o serviço é denominado entidade de
transporte.
A ISO define o protocolo de transporte para operar em dois modos:
 Orientado a conexão – usando o protocolo TCP, mais confiável.
 Não-Orientado a conexão – através do protocolo UDP, mais rápido.
Dispositivos: Swith L4.

10.2.5 Camada de Sessão

A camada de Sessão permite que duas aplicações em computadores diferentes estabeleçam uma
sessão de comunicação. Nesta sessão, essas aplicações definem como será feita a transmissão de
dados e coloca marcações nos dados que estão sendo transmitidos. Se porventura a rede falhar, os
computadores reiniciam a transmissão dos dados a partir da última marcação recebida pelo
computador receptor.
Disponibiliza serviços como pontos de controle periódicos a partir dos quais a comunicação pode ser
restabelecida em caso de pane na rede.
Abre portas (sockets) para que várias aplicações possam escalonar o uso da rede e aproveitar melhor
o tempo de uso. Por exemplo, um browser quando for fazer o download de várias imagens pode
requisitá-las juntas para que a conexão não fique ociosa em uma só imagem.
Protocolos: NetBIOS, IPX, Appletalk.

10.2.6 Camada de Apresentação

A camada de Apresentação, também chamada camada de tradução, converte o formato do dado
recebido pela camada de Aplicação em um formato comum a ser usado na transmissão desse dado, ou
seja, um formato entendido pelo protocolo usado. Um exemplo comum é a conversão do padrão de
caracteres (código de página) quando o dispositivo transmissor usa um padrão diferente do ASCII.
Pode ter outros usos, como compressão de dados e criptografia.
A compressão de dados pega os dados recebidos da camada sete e os comprime, e a camada 6 do
dispositivo receptor fica responsável por descompactar esses dados. A transmissão dos dados torna-se
mais rápida, já que haverá menos dados a serem transmitidos: os dados recebidos da camada 7 foram
"encolhidos" e enviados à camada 5.
Para aumentar a segurança, pode-se usar algum esquema de criptografia neste nível, sendo que os
dados só serão decodificados na camada 6 do dispositivo receptor.
Ela trabalha transformando os dados em um formato no qual a camada de aplicação possa aceitar.

10.2.7 Camada de Aplicação

A camada de aplicação faz a interface entre o protocolo de comunicação e o aplicativo que pediu ou
receberá a informação através da rede. Por exemplo, ao solicitar a recepção de e-mails através do
aplicativo de e-mail, este entrará em contato com a camada de Aplicação do protocolo de rede
efetuando tal solicitação. Tudo nesta camada é direcionado aos aplicativos. Telnet e FTP são exemplos
de aplicativos de rede que existem inteiramente na camada de aplicação.
Protocolos: SMTP, FTP, Telnet, SSH, IRC, http, POP3, VFRAD
129
 TI para concursos

10.3 Noções de administração de redes

O Administrador de Rede tem como atribuição principal o gerenciamento da rede local, bem como dos
58
recursos computacionais relacionados direta ou indiretamente.
Suas atribuições são:
 Instalação e ampliação da rede local;
 Acompanhar o processo de compra do material necessário para manutenção da rede local junto com o SAT
(Setor de Assistência Técnica), orientando o processo de compra e mantendo contato com os fornecedores
de equipamentos e materiais de informática;
 Instalar e configurar a máquina gateway da rede local seguindo as orientações "Normas de Utilização do
DIN";
 Orientar e/ou auxiliar os administradores das sub-redes na instalação/ampliação da sub-rede; manter em
funcionamento a rede local do DIN, disponibilizando e otimizando os recursos computacionais disponíveis;
 Executar serviços nas máquinas principais da rede local, tais como: gerenciamento de discos, fitas e
backup's, parametrização dos sistemas, atualização de versões dos sistemas operacionais e aplicativos,
aplicação de correções e patches;
 Realizar abertura, controle e fechamento de contas nas máquinas principais do domínio local, conforme
normas estabelecidas pelo DIN;
 Controlar e acompanhar a performance da rede local e sub-redes bem como dos equipamentos e sistemas
operacionais instalados;
 Propor a atualização dos recursos de software e hardware aos seus superiores;
 Manter atualizado os dados relativos ao DNS das máquinas da rede local;
 Divulgar informações de forma simples e clara sobre assuntos que afetem os usuários locais, tais como
mudança de serviços da rede, novas versões de software, etc.;
 Manter-se atualizado tecnicamente através de estudos, participação em cursos e treinamentos, listas de
discussão, etc.;
 Garantir a integridade e confidenciabilidade das informações sob seu gerenciamento e verificar ocorrências
de infrações e/ou segurança;
 Comunicar ao DIN qualquer ocorrência de segurança na rede local que possa afetar a rede local e/ou
Internet;
 Promover a utilização de conexão segura entre os usuários do seu domínio.
 Tendo como foco principal os serviços de Rede e equipamentos a qual a ele compete.
 Colocar em pratica a política de segurança de redes, além de desenvolvê-la.

10.4 Acesso Remoto

Acesso remoto é utilização de um computador através de outro por algum meio de comunicação.
Usualmente, o acesso remoto funciona como se o teclado e o mouse de um computador estivesse
ligado ao computador controlado e o monitor deste estivesse ligado no primeiro.
Existem diversos aplicativos que fazem este serviço, como o VNC, PCAnyWhere, Dameware, Conexão
de área de trabalho remota do Windows entre outros.
Muito utilizado em data centers para administrar diversos servidores com um só vídeo, teclado e
mouse.

10.5 Rede Wireless

Wi-Fi foi uma marca licenciada originalmente pela Wi-Fi Alliance para descrever a tecnologia de redes
sem fios embarcadas (WLAN) baseadas no padrão IEEE 802.11. O termo Wi-Fi é entendido como uma
tecnologia de interconexão entre dispositivos sem fios, usando o protocolo IEEE 802.11.59
O padrão Wi-Fi opera em faixas de freqüências que não necessitam de licença para instalação e/ou
operação. Este fato as tornam atrativas. No entanto, para uso comercial no Brasil é necessária licença
da Agência Nacional de Telecomunicações (Anatel).
Para se ter acesso à internet através de rede Wi-Fi deve-se estar no raio de ação ou área de
abrangência de um ponto de acesso (normalmente conhecido por hotspot) ou local público onde opere
rede sem fios e usar dispositivo móvel, como computador portátil, Tablet PC ou Assistente Pessoal
Digital com capacidade de comunicação sem fio.

58 http://pt.wikipedia.org/wiki/Administrador_de_rede
59 http://pt.wikipedia.org/wiki/Wi-Fi
130
 TI para concursos
Hotspot Wi-Fi existe para estabelecer ponto de acesso para conexão à internet. O ponto de acesso
transmite o sinal sem fios numa pequena distância – cerca de 100 metros. Quando um periférico que
permite "Wi-Fi", como um Pocket PC, encontra um hotspot, o periférico pode na mesma hora conectar-
se à rede sem fio. Muitos hotspots estão localizados em lugares que são acessíveis ao público, como
aeroportos, cafés, hotéis e livrarias. Muitas casas e escritórios também têm redes "Wi-Fi". Enquanto
alguns hotspots são gratuitos, a maioria das redes públicas é suportada por Provedores de Serviços de
Internet (Internet Service Provider - ISPs) que cobram uma taxa dos usuários para se conectarem.
Atualmente praticamente todos os computadores portáteis vêm de fábrica com dispositivos para rede
sem fio no padrão Wi-Fi (802.11 a, b, g ou n). O que antes era acessório está se tornando item
obrigatório, principalmente devido ao fato da redução do custo de fabricação.

10.6 Exercícios
184. (ICMS-SP 2009) As redes wireless utilizam os padrões IEEE 802.11 de conectividade sem fio para redes
locais, que determinam a velocidade, ou taxa de transmissão em Mbps, e a frequência, ou faixa de operação
184
em GHz. O padrão que tem as características de velocidade e frequência corretas corresponde a:
xx
(a) IEEE 802.11n 128 Mbps 5 GHz
(b) IEEE 802.11g 54 Mbps 5 GHz
(c) IEEE 802.11b 54 Mbps 5 GHz
(d) IEEE 802.11a 11 Mbps 2,4 GHz
(e) IEEE 802.11 11 Mbps 2,4 GHz.
185. (ICMS-SP 2009) A arquitetura OSI de 7 camadas (1. Física, 2. Enlace, 3. Rede, 4. Transporte, 5. Sessão, 6.
Apresentação e 7. Aplicação) pode funcionalmente representar um sistema de comunicação dividido em três
partes: redes (conectividade), transporte (ligação entre redes e aplicação) e aplicação (programas que
185
utilizam a rede). As camadas que representam as três partes são:
(a) Redes (camadas 1 e 2), Transporte (camadas 3 e 4) e Aplicação (camadas 5, 6 e 7).
xx
(b) Redes (camadas 1, 2 e 3), Transporte (camada 4) e Aplicação (camadas 5, 6 e 7).
(c) Redes (camadas 1 e 2), Transporte (camadas 3, 4 e 5) e Aplicação (camadas 6 e 7).
(d) Redes (camadas 1, 2 e 3), Transporte (camadas 4, 5 e 6) e Aplicação (camada 7).
(e) Redes (camada 1), Transporte (camadas 2, 3, 4 e 5) e Aplicação (camadas 6 e 7).
186. (ICMS-SP 2009) Em um modelo simplificado de gerenciamento de redes SNMP Internet, o programa
186
executado nas entidades a serem gerenciadas (hosts, hubs, roteadores etc.) é denominado
(a) MIB.
(b) SMI.
(c) SNMP.
xx
(d) Agente SNMP.
(e) Gerenciador SNMP.
187
187. Switches, Repetidores e Roteadores atuam respectivamente nas camadas
xx
(a) de enlace, física e de rede.
(b) de rede, de enlace e de transporte.
(c) física, de enlace e de rede.
(d) de enlace, de transporte e física.
(e) física, de rede e de enlace.
188. Entre os dispositivos utilizados para implementar fisicamente uma rede de computadores, pode-se citar o
__________ e o __________ , que operam, respectivamente, nas camadas 2 e 3 do modelo OSI. Assinale a
188
alternativa que completa, correta e respectivamente, as lacunas do texto.
(a) HUB ... Switch
(b) Roteador ... HUB
(c) Roteador ... Switch
(d) Switch ... HUB
xx
(e) Switch ... Roteador
189. No modelo de referência OSI, os pacotes e os quadros são unidades intercambiadas, respectivamente, pelas
189
camadas de
(a) enlace e de transporte.
(b) enlace e de rede.
(c) rede e física.
xx
(d) rede e de enlace.
(e) transporte e de enlace.
190. No modelo de referência TCP/IP, os protocolos IP, TCP e também aquele cujo objetivo é organizar máquinas
em domínios e mapear nomes de hosts em ambientes IP, são, respecivamente, partes integrantes das
190
camadas
(a) Inter-Redes, de Aplicação e de Transporte.
(b) Host/Rede, Inter-Redes e de Transporte.
(c) Inter-Redes, Host/Rede e de Aplicação.
xx
(d) Inter-Redes, de Transporte e de Aplicação.
(e) Host/Rede, de Transporte e de Aplicação.
131
 TI para concursos
191. Para testar o funcionamento de uma placa controladora de rede Ethernet, instalada em um computador
pessoal com sistema operacional Windows XP, pode-se, a partir desse computador, aplicar o comando ping
191
para o endereço IP
(a) 0.0.0.0
(b) 1.1.1.1
xx
(c) 127.0.0.1
(d) 255.0.0.0
(e) 255.255.255.0
192. A Internet utiliza a pilha de protocolos TCP/IP para prover todos os serviços. Nesse contexto, o TCP é
encarregado de possibilitar o __________ e o IP é encarregado do __________ . Assinale a alternativa que
192
completa, correta e respectivamente, as lacunas do texto.
(a) roteamento ... endereçamento
(b) roteamento ... transporte
(c) transporte ... empacotamento
xx
(d) transporte ... endereçamento
(e) transporte ... sequenciamento
193. O processo de navegação na Internet é facilitado pelo uso de endereços de domínio no lugar dos endereços
IPs (mais difíceis de memorizar e relacionar com os sites endereçados). O serviço que faz o relacionamento
193
entre o domínio e o IP é denominado
(a) DHCP.
xx
(b) DNS.
(c) IMAP.
(d) PPP.
(e) TCP/IP.
194. O equipamento de rede de computador utilizado para armazenar cópias (cache) de páginas mais visitadas e,
194
além disso, verificar o conteúdo dessas páginas, é denominado
xx
(a) Proxy.
(b) Bridge.
(c) Spyware.
(d) Firewall.
(e) Gateway.
195. TCP/IP (transmission control protocol/Internetprotocol) são os dois protocolos mais importantes de um
conjunto de protocolos que deram seus nomes à arquitetura. Deles, surge a Internet, uma rede pública de
comunicação de dados que, com controle descentralizado, utiliza esse conjunto de protocolos como base
para sua estrutura de comunicação e seus serviços de rede. A arquitetura TCP/IP não só fornece os
protocolos que habilitam a comunicação de dados entre redes, mas também define uma série de aplicações
que contribuem para a eficiência e sucesso da arquitetura. Tendo como referência inicial as informações
195
acima, assinale a opção correta a respeito de Internet, intranet e padrões de tecnologia Web.
(a) Uma intranet é a aplicação da tecnologia criada na Internet e do conjunto de protocolos de transporte e
de rede TCP/IP em uma rede semiprivada, interna a uma empresa. Nela, grande quantidade de
informações e aplicações é disponibilizada por meio dos sistemas Web (protocolo HTTP) e correio-
eletrônico, sendo, comumente, verificadas funcionalidades como informações dos empregados e dos
clientes que a acessam em busca de informações sobre andamento de pedidos.
(b) O protocolo OSPF (open shortest path first), que é embasado no paradigma de chaveamento de pacotes
(packetswitching), especifica o formato dos pacotes que são enviados e recebidos entre roteadores e
sistemas finais.
(c) Os protocolos UDP e SMTP podem ser utilizados na transferência de arquivos para um computador
remoto que também os execute e em qualquer estrutura de rede, seja ela simples, como uma ligação
ponto-a-ponto, seja ela uma rede de pacotes complexa.
(d) O DNS (domain name system) é um sistema de banco de dados distribuído implementado em uma
hierarquia de servidores de nome (servidores DNS) e em um protocolo de camada de aplicação que
xx
permite a hospedeiros consultarem o banco de dados distribuído.
(e) O ICMP (Internet control message protocol), que é um protocolo de roteamento exterior auxiliar ao IP e
cuja finalidade é conectar dois ou mais sistemas autônomos, pode operar em conjunto com os
protocolos EGP (exterior gateway protocol) e BGP (border gateway protocol), o que permite maior
confiabilidade à ligação entre dois sistemas autônomos.
196. Para acesso aos recursos da Internet, os browsers possibilitam o uso de endereços de sites na forma de
mnemônicos, como, por exemplo, no portal do Governo do Estado do Rio de Janeiro –
http://www.governo.rj.gov.br/, deixando para o sistema automatizado a tarefa de realizar as necessárias
196
conversões para os correspondentes endereços IP´s. Esse recurso é conhecido pela sigla:
(a) ARP.
xx
(b) DNS.
(c) ISP.
(d) NAT.
(e) NFS.

132
 TI para concursos
197. Dentre os recursos atualmente disponíveis no âmbito da tecnologia da informação, a Extranet constitui um
termo associado às facilidades de comunicação na busca do aumento da produtividade. Nesse sentido, a
197
Extranet é definida como:
(a) uma parte da Intranet que fica disponível à troca de informações com os funcionários de uma
organização, mas inibe todo tipo de acesso ao ambiente externo por meio do firewall.
(b) uma sub-rede sob sistema operacional Windows XP ou Linux que implementa recursos de VPN na sua
segurança, mas libera acesso por meio do firewall.
(c) uma parte da Intranet que fica disponível na Internet para interação com clientes e fornecedores de uma
xx
organização, mas com acesso autorizado, controlado e restrito.
(d) uma sub-rede que disponibiliza uma maior quantidade de microcomputadores com acesso à Internet por
meio da utilização do mecanismo NAT, mas restringe a intercomunicação com usuários indesejados à
organização.
(e) uma parte da Intranet que disponibiliza a comunicação com fornecedores e determinados clientes de
uma organização, mas inibe todo tipo de acesso ao ambiente interno por meio do firewall.
198. A Internet constitui o melhor exemplo de uma WAN operando por meio de uma infraestrutura baseada no
emprego de endereços IP´s para o roteamento dos pacotes de informações. Por definição na RFC 1918,
alguns endereços IP são reservados e não-roteáveis externamente, sendo somente usados para redes
internas, significando que nenhum computador conectado em rede local e usando qualquer uma das classes
desses endereços reservados conseguirá acessar a internet. A exceção ocorre se os microcomputadores
estiverem em rede e usando NAT (RFC 1631 – Network Address Translation). Para Intranets privadas, o
Internet Assigned Numbers Authority (IANA) reservou a faixa de endereços de 10.0.0.0 a 10.255.255.255
para a classe A e a de 172.16.0.0 a 172.16.255.255 para a classe B. Assinale a alternativa que apresente a
198
faixa de endereços reservada para a classe C.
(a) de 128.192.0.0 a 128.192.255.255
(b) de 128.146.0.0 a 128.146.255.255
(c) de 184.191.0.0 a 184.191.255.255
xx
(d) de 192.168.0.0 a 192.168.255.255
(e) de 198.162.0.0 a 198.162.255.255
199. Dada uma faixa de endereços que utilize a máscara de sub-rede 255.255.255.240, será possível atribuir
199
endereços IP para
(a) 2 redes e 62 estações em cada rede.
(b) 6 redes e 30 estações em cada rede.
xx
(c) 14 redes e 14 estações em cada rede.
(d) 30 redes e 6 estações em cada rede.
(e) 62 redes e 2 estações em cada rede.
200. Conecta segmentos de LAN que utilizam o mesmo protocolo de enlace de dados e de rede. Normalmente,
fornece portas para 4, 8, 16 ou 32 segmentos de LAN separados, permite que todas as portas estejam
simultaneamente em uso e pode conectar os mesmos ou diferentes tipos de cabo. Estas são características
200
de um
(a) concentrador.
(b) multiplexador.
xx
(c) comutador.
(d) modulador de amplitude.
(e) repetidor.
201. Padrão de protocolo da camada de transporte, sem conexão, não confiável, destinado a aplicações que não
querem controle de fluxo e nem manutenção da seqüência das mensagens enviadas, usado pelo TCP para
201
enviar mensagens curtas. Trata-se de
xx
(a) UDP.
(b) IP.
(c) SMTP.
(d) POP.
(e) Telnet.
202
202. As mensagens de correio eletrônico, a partir de um microcomputador pessoal, serão enviadas
(a) pelo protocolo SMTP, conectado pela porta 25, e serão recebidas pelos protocolos POP3 ou IMAP,
xx
conectado respectivamente pelas portas 110 ou 220.
(b) pelo protocolo SMTP, conectado pela porta 110, e serão recebidas pelos protocolos POP3 ou IMAP,
conectado respectivamente pelas portas 25 ou 220.
(c) pelos protocolos SMTP ou IMAP, conectado respectivamente pelas portas 25 ou 220, e serão recebidas
pelo protocolo POP3, conectado pela porta 110.
(d) pelos protocolos SMTP ou IMAP, conectado respectivamente pelas portas 110 ou 220, e serão
recebidas pelo protocolo POP3, conectado pela porta 25.
(e) pelo protocolo SMTP, conectado pela porta 110, serão recebidas pelo protocolo POP3, conectado pela
porta 25, e serão enviadas ou recebidas pelo protocolo IMAP, conectado pela porta 220.

133
 TI para concursos
203
203. O daemon de correio eletrônico que se comunica com o SMTP permanece em escuta na porta
(a) 21
xx
(b) 15
(c) 69
(d) 80
(e) 110
204. Controlar o acesso ao canal compartilhado é uma questão que as redes de difusão têm a resolver na camada
204
de enlace de dados. Para cuidar desse problema existe
(a) o roteador.
(b) a VPN.
xx
(c) a subcamada MAC.
(d) o protocolo IP.
(e) o protocolo HTTP.
205. Serviço que permite ao usuário entrar em outro computador ligado à internet, transformando sua máquina
205
local em um terminal do computador remoto é o
xx
(a) Telnet.
(b) FTP.
(c) Usenet.
(d) Intranet.
(e) IRC.
206
206. As camadas LLC e MAC da arquitetura de rede IEEE 802 correspondem no modelo OSI à camada de
(a) Rede.
(b) Sessão.
xx
(c) Enlace.
(d) Transporte.
(e) Aplicação.

134
 TI para concursos

11 Referências
Além das referências anotradas nos rodapés das páginas:
OBJECT Management Group, Inc. (OMG), Business Process Model and Notation (BPMN). Version 2.0 de
03/01/2011. Disponível em http://www.omg.org/spec/BPMN/2.0.
Acesso em 15/09/2012.
MAZZOLA, Vitório Bruno. “Engenharia de Software”. Disponível em
http://seriesloads.wordpress.com/2010/11/04/engenharia-de-software-vitorio-bruno-mazzola/ .
Acesso em 15/09/2012
PMI, Project Management Institute, Inc. “Um Guia do Conjunto de Conhecimentos em Gerenciamento de
Projetos (Guia PMBOK®)”. Terceira edição. ©2004.

135
 TI para concursos

12 Sobre o autor
Walter de Tarso Faria Santos de Campos foi aprovado no concurso de AFR ICMS-SP de 2009 e está alocado no
Centro de Desenvolvimento de Sistemas do Departamento de Tecnologia de Informações (CDS-DTI) da
Secretaria da Fazenda de São Paulo.
Este material foi um resumo de tudo de TI que estudou para esta prova.
Formado em licenciatura em química pela Universidade de São Paulo, lecionou informática básica para alunos
do ensino fundamental e médio no Colégio Rio Branco por doze anos.
Exerceu consultoria de informática e desenvolveu mais de trinta sistemas para diversas intituições públicas e
privadas por 25 anos, para FIPE, FIA, FIPECAFI, Secretaria do Meio Ambiente, CDHU, Convap Engenharia e
Construções, GMR Arquitetos Associados, Fundação Padre Anchieta, Fundação Osesp, ABEM, Souza Cruz,
entre outras.

136
 TI para concursos

13 Gabarito

47 94 141 188
(d) (c) (b) (e)
1 48 95 142 189
(b) (a) (a) (d) (d)
2 49 96 143 190
(a) (c) (e) (a) (d)
3 50 97 144 191
(e) (a) (a) (d) (c)
4 51 98 145 192
(b) (c) (c) (e) (d)
5 52 99 146 193
(e) (c) (e) (c) (b)
6 53 100 147 194
(b) (b) (b) (b) (a)
7 54 101 148 195
(d) (a) (a) (e) (d)
8 55 102 149 196
(e) (b) (d) (c) (b)
9 56 103 150 197
(b) (c) (e) (b) (c)
10 57 104 151 198
(a) (d) (a) (c) (d)
11 58 105 152 199
(c) (d) (b) (e) (c)
12 59 106 153 200
(a) (d) (b) (a) (c)
13 60 107 154 201
(b) (b) (b) (e) (a)
14 61 108 155 202
(d) (c) (e) (d) (a)
15 62 109 156 203
(b) (d) (b) (e) (b)
16 63 110 157 204
(d) (d) (a) (e) (c)
17 64 111 158 205
(a) (b) (a) (e) (a)
18 65 112 159 206
(c) (a) (d) (b) (c)
19 66 113 160
(a) (a) (a) (e)
20 67 114 161
(d) (c) (e) (b)
21 68 115 162
(c) (b) (b) (a)
22 69 116 163
(d) (c) (b) (b)
23 70 117 164
(c) (e) (c) (d)
24 71 118 165
(e) (d) (a) (d)
25 72 119 166
(b) (e) (e) (e)
26 73 120 167
(a) (c) (d) (b)
27 74 121 168
(d) (b) (e) (d)
28 75 122 169
(c) (e) (d) (d)
29 76 123 170
(e) (c) (c) (e)
30 77 124 171
(b) (e) (d) (c)
31 78 125 172
(a) (c) (c) (d)
32 79 126 173
(a) (c) (a) (d)
33 80 127 174
(d) (d) (c) (c)
34 81 128 175
(d) (d) (b) (c)
35 82 129 176
(d) (b) (d) (b)
36 83 130 177
(c) (b) (e) (e)
37 84 131 178
(d) (c) (c) (b)
38 85 132 179
(d) (e) (c) (d)
39 86 133 180
(a) (c) (d) (b)
40 87 134 181
(b) (b) (e) (b)
41 88 135 182
(b) (e) (a) (a)
42 89 136 183
(e) (a) (d) (c)
43 90 137 184
(c) (b) (b) (a)
44 91 138 185
(a) (d) (e) (b)
45 92 139 186
(d) (e) (a) (d)
46 93 140 187
(e) (b) (b) (a)
137